Shyft Tech Update: Introducing Ethereum Virtual Machine (EVM)
How we optimize Ethereum’s underlying blockchain
By: David G. Ansermino | https://github.com/ansermino/
Ethereum is a general solution for a variety of blockchain applications. However, with such generality comes limitations and inefficiencies. Operating on large sets of data is both expensive and requires the exploration of the entire blockchain. Shyft aims to create tailored solutions by introducing Ethereum Virtual Machine (EVM) customizations to optimize Ethereum’s underlying blockchain.
Please read on, and if you’re interested in learning more about Shyft:
Join our Telegram | Follow us on Twitter
Background
Ethereum’s true power is realized through its smart contract functionality. Smart contracts are pieces of code stored on the Ethereum blockchain. Contracts can be called, executed, and can update the state of the blockchain. Contracts are typically written in Solidity and are compiled into bytecode, although alternative contract languages do exist. Bytecode represents opcodes, which are a rudimentary language for interfacing with the EVM. The process works like this:
Every node on the the Ethereum network runs a implementation of the EVM. The EVM is a stack-based virtual machine that executes the opcodes (see the Ethereum Yellow Paper for the complete specifications of EVM and the opcodes). If you are familiar with Assembly, understanding the core principles of the the EVM is not too difficult. Instead of using registers we simply use a stack.
Every opcode is assigned a static or dynamic gas cost. For example, the PUSH1 opcode has a cost of 3gwei. Some opcodes have a dynamic cost which is determined by the size of the data being operated on. For example, the SHA3 opcode has a gas cost specified as 30gwei plus 6 * # of words of input (each word is 32 bytes).
The Problem
One of the key components of the Shyft Network is the Shyft Bridge. This provides Shyft’s ecosystem with interoperability between other networks. This mechanism proves that some transaction has taken place using Merkle Tree Proofs (MTP) (see the Shyft Bridge article for further explanation). An MTP is a relatively straightforward operation, however, gas costs become increasingly concerning due to the complexity of the Merkle Trees we are working with. Here is the prove function in Solidity:
As you can see from the for loop above, the gas cost of this function will vary based on the length of the proof. Does it make sense to have a variable cost based on a parameter outside the user’s control? Are users even willing to use the Bridge if it requires them to pay a high gas cost? We believe the answer is no, and that this issue exists in many other use cases outside of MTPs.
Solution
By implementing this frequently used function as an opcode inside the EVM, we can establish a cost function that serves our use case.
In traditional computer systems, optimizations at the lowest level are cumbersome. Modifying how data is stored, what operations can be performed, or the language we use to interact usually requires hardware as well as software modifications. Since the EVM is solely a software component, we have much more flexibility around how we can optimize the system.
The above prove function compiles down to a sequence of over 300 opcodes (excluding the default handler and some other necessary setup/teardown operations). For each of these operations, we must increment the Program Counter (PC), set up the parameters on the stack, and execute the logic inside the opcode definition. By implementing our logic inside of a single opcode, we remove the overhead of incrementing the PC and the inefficiencies of utilizing the stack.
Here is a basic implementation of the above prove function in our fork of the ethereumjs-vm as a new opcode, MERKLEPROVE:
The logic of this code is almost identical to the Solidity implementation, but this code is more akin to a custom circuit into the virtual processor of the EVM. Instead of saving the result of each step or loop iteration in the EVM’s stack, memory, or storage, we are making direct use of the internal device systems this code is executing on, which significantly reduces the overhead of execution.
Another huge benefit of implementing these custom opcodes is that we can utilize additional data structures not available natively inside the existing EVM. There are numerous use cases for blockchains where we want to be able to both perform transactions and recall data on the chain. The current solution is to implement block explorers, which cache the chain data in a database for easy retrieval. This presents limitations, as the data is only available outside the execution of the system.
The solution we have been exploring is implementing custom opcodes to store use-case specific data. For us, this specific data consists of attestations of a user’s identity. Storing a single attestation does not present much of an immediate challenge with the existing architecture. The more severe issue arises when we want to operate on a massive numbers of these attestations; the EVM has very limited memory-space, making this unfeasible. The stack is limited to 16 32-byte items, the cost of memory grows quadratically, and storage is always expensive.
The solution as we see it is to implement an additional database at the EVM layer. Again, we can implement custom opcodes with sensible cost functions, and we can implement the logic that allows these opcodes to interact with the database as necessary.
Conclusion
Like most software, a one-size fits all blockchain solution is unlikely to be achievable. Ethereum has established an incredible foundation for the the future of blockchain technology, but as the number of use cases increase, we are bound to see more and more variations. Projects such as Polkadot are looking at how we can maintain interoperability between bespoke implementations. This seems to indicate a future where blockchain won’t be a monopolistic ecosystem as we’ve seen happen with operating systems, but rather a reversion to its true nature as a data structure that we can universally and unequivocally implement.
Have a question for Shyft CTO? Join our Telegram to ask directly.
***
Shyft is building the world’s first modern, secure, multi-stakeholder Blockchain-based network that enables KYC/AML attested data transfers. Join our Telegram (https://t.me/joinchat/HhrB_hKGQDQKU7mhpzor_g), follow us on Twitter (https://twitter.com/shyftnetwork), GitHub (https://github.com/ShyftNetwork) and other channels found on https://www.shyft.network/
