You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a rollup, all consensus and data lie in L1. The only difference between L1 and L2 is how the state transition function works.
You can retain the "blockchain" part of Geth on L1, while changing the StateProcessor to process the state for L2. This function, called Process, is located in geth at core/state_processor.go, and I believe it would require a <100 line change. Instead of running on all L1 transactions, you would run on the L1 transactions that target the rollup contract only, and run your custom transaction unpacker to extract the L2 transactions. (Note: you'd have to also implement unpackL2Transaction in solidity for the fraud proof, I think this is a better trade off than EOAs, even though you are writing the code twice)
... (at line 76)
for i, l1tx := range block.Transactions() {
if (l1tx.to != rollupl1contract) continue
for j, tx := range unpackL2Transaction(l1tx) {
// process as before
In order to support the sequencer (in block n) and standalone (in block n-k) transactions, you'd have to also look for standalone transactions in L1 block n-k when you are building L2 block n. Since we are in a blockchain and block n-k is fixed for block n, this adds very little complexity.
All info about the L2 block n, like the number, timestamp, and coinbase would come from L1 block n. Note that you do not need the L1 state, since generating an L1 chain with bad state transitions for a long enough period to withdraw would be equivalent to a 51% attack on ETH.
You'd have to add three flags to geth also, this specifies which rollup to connect to:
--l2.startblock # The block the L1 rollup contract was deployed at
--l2.startblockhash # The hash of that block to allow syncing starting from it
--l2.rollupl1contract # The address of contract
Overall, I think this would massively reduce the complexity of the system. The L1 block reorg would be free and guaranteed to match geth since it is geth. It would also not require a synced L1 node, as It only needs to sync the blocks starting with the L2 deployment, and can do this over P2P.
Line totalling estimates:
500 line Go -- geth diff
500 line Soldiity -- L1 rollup contract with depositi/withdraw
3000 line Soldiity -- interactive fraud proof (can wait for v2)
500 line Typescript -- batch-submitter (submit bundle txes + state roots) TODO: simple with mining stuff from geth?
It would also make rollups very easy to create. Just deploy one contract and run one geth for the whole system. (perhaps also a batch-submitter)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
As a rollup, all consensus and data lie in L1. The only difference between L1 and L2 is how the state transition function works.
You can retain the "blockchain" part of Geth on L1, while changing the StateProcessor to process the state for L2. This function, called
Process
, is located in geth atcore/state_processor.go
, and I believe it would require a <100 line change. Instead of running on all L1 transactions, you would run on the L1 transactions that target the rollup contract only, and run your custom transaction unpacker to extract the L2 transactions. (Note: you'd have to also implement unpackL2Transaction in solidity for the fraud proof, I think this is a better trade off than EOAs, even though you are writing the code twice)In order to support the sequencer (in block n) and standalone (in block n-k) transactions, you'd have to also look for standalone transactions in L1 block n-k when you are building L2 block n. Since we are in a blockchain and block n-k is fixed for block n, this adds very little complexity.
All info about the L2 block n, like the number, timestamp, and coinbase would come from L1 block n. Note that you do not need the L1 state, since generating an L1 chain with bad state transitions for a long enough period to withdraw would be equivalent to a 51% attack on ETH.
You'd have to add three flags to geth also, this specifies which rollup to connect to:
Overall, I think this would massively reduce the complexity of the system. The L1 block reorg would be free and guaranteed to match geth since it is geth. It would also not require a synced L1 node, as It only needs to sync the blocks starting with the L2 deployment, and can do this over P2P.
Line totalling estimates:
It would also make rollups very easy to create. Just deploy one contract and run one geth for the whole system. (perhaps also a batch-submitter)
Beta Was this translation helpful? Give feedback.
All reactions