Grow Open Source Bounties Hackathons Grants Quests Kudos
Back to Grants

Interstate Network - EVM optimistic rollup





1 contributors


{"ops":[{"attributes":{"bold":true},"insert":"Interstate Network - evm optimistic rollup"},{"insert":"\n\nInterstate Network will be a layer-2 Ethereum network that supports EVM smart contract execution and uses a fork of go-ethereum for its node. We think Ethereum sidechains should be Ethereum chains, so we're building one.\n\nISN will allow every Ethereum smart contract to use layer-2 without needing to make their own fraud proofs (what amounts to making a new blockchain for every application); we have designed and are implementing a system for EVM chains to audit each other, and we think this will greatly improve the scalability of every Ethereum application. We see this as the first EVM shard, and it will run on ETH 1.\n\nWe're calling our first implementation Interstate One, and it will have the following features:\n- Regular transactions can be sent between mainnet and the sidechain, meaning contracts on each can asynchronously call each other\n- Contracts can be deployed to the sidechain, but only through mainnet via a special deployment contract which makes sure we have a permanent record of the code on mainnet\n- The sidechain can execute all EVM opcodes in smart contracts except for CREATE, CREATE2, SELFDESTRUCT\n- Block headers are modified from Ethereum, but have most of the same values\n- Multiple bonded aggregator model, consensus tied to mainnet state\n- \"Optimistic Rollup\" approach to data availability -- all transactions and intermediate state roots sent to mainnet\n- go-ethereum fork which produces execution records upon challenge\n- Fraud proof smart contracts on mainnet for verifying every part of sidechain execution\n- All existing eth tooling which is not broken by the above (i.e. tools that require standard contract creation or block headers) can be used with no modifications -- MetaMask and web3 will work just fine\n- Remaining tooling can be used with minor modifications\n\nCurrent Progress\nTarget launch for a developer testnet with open sourced code is Q1 2020.\n\nFork of ethereumjs-vm for testing: Finished\nEVM Hypervisor for verifying execution records (EVM code execution): Finished\nSmart contract for verifying merkle patricia trie state proofs: Finished\nSmart contract for updating merkle patricia tries: Nearing completion\nSmart contracts with definitions of all access records and verification of record consistency: Undergoing refactor to work with multi-aggregator model\ngo-ethereum fork: In progress\nEVM Hypervisor for verifying gas usage in execution records: Specified, incomplete\n\nWe have a very early draft whitepaper produced last December, which is available "},{"attributes":{"link":"https://www.dropbox.com/s/4yy78n1uhwjgq4x/interstate%20whitepaper%20v1.pdf?dl=0"},"insert":"[here]"},{"insert":". Some modifications have been made to the structure, which along with a full specification of the fraud proof system and record creation on the node will be published in a new whitepaper in the coming months.\n\nWhere is the money going towards?\n- Audit\n- Infrastructure costs for the first aggregators\n\n\nFAQ\n\nWhat is optimistic rollup?\nOptimistic rollup is an approach to data withholding attacks which plagued older sidechains. Essentially, if a miner only gives a header or some loose commitment which can not be used by nodes to fully process a block, you must have a challenge process on mainnet where they are forced to reveal that data. The problem is, Ethereum doesn't know whether data exists outside of Ethereum at a given time, so you run into the "},{"attributes":{"link":"https://vitalik.ca/general/2019/08/28/hybrid_layer_2.html"},"insert":"fisherman's dilemma"},{"insert":" -- if you have challenges, you need to make sure block producers can't fraudulently withhold data in order to get bad blocks approved, and you need to make sure \"fishermen\" can't just force them to always post blocks. If a miner withholds data then reveals it after a challenge is made, Ethereum doesn't know who to blame and the system falls apart.\n\nHow do you prove fraud?\nWe prove fraud by producing auditable records of execution through the full execution of a single transaction, and committing state roots between each transaction. Since consensus is based on the mainnet state, anyone running an honest node can determine if a submitted block is valid and, if it is fraudulent, exactly where the block became fraudulent. We then have a challenge system which can be used to reveal and audit individual segments of execution (message calls).\n\nHow much does the hypervisor (EVMVM) cost? \nThe EVMVM contract is drastically less expensive than any similar system we have come across. We used the Huff language (by AZTEC) to create a smart contract which virtualizes smart contract execution and leaves the stack untouched after each virtual opcode is executed -- we don't use memory for the stack like other EVMVMs, so there is relatively low overhead for each opcode, and we use a jump table instead of 256 `if (op) doOp()` conditions. We also don't execute any state-touching operations (for the most part), which are the expensive ones in Ethereum. Instead we read from and compare execution to a provided record, meaning an SSTORE operation costs about the same as reading from a Solidity array (maybe a bit of an exaggeration, "},{"attributes":{"link":"https://raw.githubusercontent.com/figs999/Ethereum/master/Solc.aComedyInOneAct"},"insert":"but come on"},{"insert":").\n\n\n"}]}

Activity Feed