Skip to main content

NEVM Chain (EVM)

What are Virtual Machines?#

Ethereum pioneered the virtual machine, which is essentially a processing machine for Ethereum-based smart contracts. A smart contract can range from a basic ERC20 token to a more sophisticated piece of code that underpins a decentralized application in this context.

The Ethereum Virtual Machine (EVM) offers a layer of abstraction between the smart contract code and the Ethereum network’s machine that executes it. Most Ethereum smart contracts are written in Solidity, a programming language created by Dr. Gavin Wood, one of Ethereum’s founders. EVM will also provide support for eWasm (Ethereum WebAssembly) which will enable smart contracts to be coded in various languages including C, C++, and more, which can be trans compiled and executed.

The EVM does not directly execute code. Instead, the code is compiled into opcodes when a smart contract developer is ready to deploy it. Opcodes are a collection of 141 unique instructions that the EVM employs to carry out activities depending on the coded instructions in the smart contract.

Each opcode has a fixed gas cost; however, some may also have a dynamic gas cost. The computational effort required to perform any given transaction on the Ethereum network is measured in gas, which in turn is used to calculate transaction fees in combination with the current demands, i.e. “traffic”, on the Ethereum network.

Turing-completeness refers to a computer’s capacity to tackle every solvable issue. The EVM’s 141 opcodes, meant to calculate every situation, was meant to be Turing-complete in theory. On a practical level, however, the EVM isn’t truly Turing-complete since the amount of gas available limits every computation.

Importance of Virtual Machines#

EVM introduced the world to the concept of decentralized smart contracts and conditional transactions which Bitcoin was unable to provide. The conditions for these transactions (the smart contracts), and execution of them by EVM, elevated blockchain tech beyond the very limited use of monetary transactionality, or simple value transfer, to serve as a decentralized computer.

The EVM is not without flaws. The most glaring example of this for the Ethereum network is that, due to design, it is not scalable. This means that as demand grows the network is unable to consistently provide reasonable transaction costs and fulfilment time. Ethereum is pursuing a proof-of-stake security system with the aim of addressing this, but it comes at a great cost; proof-of-stake is inherently less secure, and less proven (academically and in the real world) than proof-of-work.

What is Syscoin’s Network-Enhanced Virtual Machine (NEVM)?#

Syscoin NEVM is designed to provide smart contracts and interoperability that can scale to smart cities and beyond, while remaining low-cost and performant, and providing robust decentralized settlements that are secured by Bitcoin’s own proof-of-work security model via merged-mining. Blockchain users and market participants will increasingly realize the importance of proven security, especially as the risks of sundry experimental security models “come home to roost”. Furthermore, once Ethereum shifts to proof-of-stake, other proof-of-stake computation platforms will move closer to becoming superfluous, while Syscoin’s security will continue to be relevant.

With NEVM, Syscoin will essentially combine the strongest elements of Bitcoin (security model, merge-mined hashrate potential, UTXO efficiency and compatibility with future UTXO advancements) with Ethereum (broad usefulness of generalized computation), into a single decentralized coordinated financial computation platform. Syscoin will also improve upon both aspects. For example, on the UTXO side, chainlocks will address Bitcoin’s long-standing “selfish mining” vulnerability and harden the network against reorg impact after a chain lock is established which usually takes up to a minute after each block. On the NEVM side, we will implement zero-knowledge proofs to offer scalability and trustless interoperability for Turing-complete smart contracts. The chainlock’s mechanism gives a finality guarantee which is the desired effect of sharding and proof-of-stake on Ethereum 2.0. With finality, we can achieve better constraints for usable roll-up designs such as optimistic roll-ups, which require a waiting period of two weeks on Ethereum mainnet and can be much less on Syscoin due to new finality guarantees that chainlocks provide. On Syscoin the contracts would only have to wait hours on such designs and with the use of zero-knowledge proofs in zkRollups these withdrawal delays can be eliminated entirely.

Advantages of NEVM#

  • Smart contracts can scale to an arbitrary number of transactions using a blockchain that provides concise proofs of one-time executions which can be validated in parallel, instead of re-executing them.
  • A decentralized cost model that leads to a significantly more efficient market for gas fees
  • Sublinear, reliable, fault-tolerant blockchain with interactive data availability
  • Trustless cross-chain interoperability is generalized for easy integration with various blockchains, in a way that provides far less cost and technical overhead compared to SysEthereum v1.
  • A coordinated platform with optimal features for easy value transfer, store-of-value, and generalized computing, while retaining concern separation and scalability
  • The security of merged-mining the most reliable PoW network, tapping into most significant hashrate resource available: Bitcoin
  • Finality guarantee through chainlocks, which is based on the security of validators holding some amount of coins mined via PoW and participating in a supermajority of consensus on the current chain tip. This is free from the shortcomings of Proof-Of-Stake and especially the “nothing-at-stake”, which involves validators that are providing consensus without the backing of real sunk costs (energy, infrastructure). In the event a supermajority is not established, the chainlock mechanism resolves back down to a regular bitcoin-type policy.