(Signal Prop) Investigate EVM functionality.

Technical To do this, we look to open up the Terra platform to EVM, also known as the Ethereum Virtual Machine. EVM has been the gold standard for blockchain development since 2013 and has over 910 separate chains under it's umbrella. This give Terra Classic the potential to become compliant with new and emerging technologies, like Optimistic Transactions, where Terra Classic does not need to send direct security information on each transaction, and Rollups, which allow significantly more transactions to be processed at once, dramatically increasing the processing power of Terra Classic. Further, this would allow Terra to use Solidity, A Blockchain compliant programming language commonly used on EVM chains, and target-able via either SOLC, the Solidity Off chain Compiler, or Remix IDE, the most widely used development environment for Blockchain and Digital Assets Applications. The benefits of these are many but to name a few: This removes the complexity of development for the average end user. Rust, while a powerful language, is overtly complex and those accustomed to other High Level Programming Languages, like Java, Python, C#, etc. may have a hard time writing anything in it. Further, the “Cargo” Packaging System is complex, and does not actually launch to chain when compiled. At current rate, you need to broadcast your WASM contract as a seperate transaction, from command line, whereas being able to use Remix for instance, would allow you to launch and compile directly to Terra Classic for minimal fees. Having EVM support opens up a pathway for existing applications to migrate over to Terra with minimal or even no development time. Services like Curve DAO, Uniswap, PAXGold, ChainLink, Linea, Enuls, POL, Hedera and the upcoming ECHO-QS Service would gain fast and expansive access to Terra classic expanding what is possible on terra classic. EVM Support on IBC is currently lacking, with only Evmos being the primary EVM provider. However, to our understanding, Evmos is not currently maintained and is out of date with current solidity standards (Current Version is 0.8.23). This is not typesafe, and makes the compiled code on Evmos not compatible with direct EVM. For example, the EVM runs on its own “microcode” which are instructions that tell it what to do. 0.8.21 added new microcodes that are not in Evmos currently. In order to facilitate our inclusion of EVM we would need to do 1 of 3 things: Fork Evmos and merge it into Terrad. Fork SOLC and merge it into Terrad. Fork Injective and merge it into Terrad. Each of these has their own distinct differences, benefits and Challenges. At the present, we are not suggesting on implementing these changes into the code itself, but merely showing that this is something that can be done, and something we wish to be explored. Any changes of this caliber would be run through governance, same as we are making this proposal. In turn, any changes made would be on a terrad fork, not on the initial source until we can determine that the Evmos or SOLC merge works sufficiently with no known exploits or faults. Keep in mind, that our goal is to breathe new life into Terra Classic, not create new issues or security exploits. While this does seem like a major change for the Terra Classic chain in and of itself, we feel that it is necessary to maintain and create a platform that developers will want to actively contribute to and expand, and outside of pegging options which have not entirely succeeded, may be one of our only other options. Terra Classic Implementation For direct clarity, we should state just how we envision this being done: A EVM → COSMWASM compiler implementation. In order to facilitate direct communication onchain, while minimizing the impact to validators, we will be utilizing the above services in part or in whole to crease a Evm to COSMWASM compiler. The compiler is what takes the source material, in this case solidity code, and converts it into machine readable code, in this case WebAssembly. In Essence, This would take a the Solidity code and compile it directly to WASM targeting IBC. Whats unique about this is that there would be no direct implementation risks or additional storage requirements for the validators themselves. Wasm still runs on chain, and at no point will a validator be executing direct solidity code. This will further give us an edge over other IBC implementations, and giving both Terra Classic Developers and EVM developers access to expansive new technologies. Next Steps If this proposal is to pass, according to {Prop #11889 "Pay-per-job and governance-ruled Job List"}, it will then be added to Terra Classics back log/"Jobs List" for developers or teams of developers to step forward and bid on the works completion. Any team or group of developers must then go through the governance process and seek approval to complete the work via a governance decision. It is not this proposal's purpose to decide upon a specific chain or repo to fork and merge into Terrad, simply that we as a community are wanting to take Terra Classic in this direction and are willing to fund EVM development. Full Prop: https://commonwealth.im/terra-classic/discussion/14708-signal-prop-investigate-evm-functionality-through-ethermint-injectivesdk-evmossdk-or-solidity-off-chain-compiler-