Read on Twitter
The debate is focusing on two concepts for rollups:
- How should a verifier update their layer-2 database?
- Why is the verifier performing this update to their layer-2 database?
We consider a state transition:
- function(input) == output
HOW = output
WHY = function(input) https://twitter.com/gluk64/status/1385140891329912833
- How should a verifier update their layer-2 database?
- Why is the verifier performing this update to their layer-2 database?
We consider a state transition:
- function(input) == output
HOW = output
WHY = function(input) https://twitter.com/gluk64/status/1385140891329912833
The principles of "how" are not very different for ZKRU vs ORU.
A simple example of "how":
- "update account balance of 0x001.. by 1 coin"
- "delete state at memory 0x002".
A better "how" is still under-explored:
- Can we batch updates into one? (e.g. the 1k uniswap example)
A simple example of "how":
- "update account balance of 0x001.. by 1 coin"
- "delete state at memory 0x002".
A better "how" is still under-explored:
- Can we batch updates into one? (e.g. the 1k uniswap example)
- Is it more efficient to apply a state diff vs a list of updates?
- What is truly the minimum amount of information required to perform a "how"?
The really interesting debate is the "why" and this gets to the heart of the ORU vs ZKRU debate.
- What is truly the minimum amount of information required to perform a "how"?
The really interesting debate is the "why" and this gets to the heart of the ORU vs ZKRU debate.
In the ORU world:
- The function and input is public knowledge in its entirely.
A verifier needs all transaction data in order to re-execute every state transition off-chain and convince themselves that the layer-2 database is correct (and all transactions are valid).
- The function and input is public knowledge in its entirely.
A verifier needs all transaction data in order to re-execute every state transition off-chain and convince themselves that the layer-2 database is correct (and all transactions are valid).
One important goal for ORU research is whether the "why" can be reduced.
One example is to use BLS signatures. It allows several signatures to be combined into one. But the solutions become application-specific and a range of magic tricks.
But this brings up an insight.
One example is to use BLS signatures. It allows several signatures to be combined into one. But the solutions become application-specific and a range of magic tricks.
But this brings up an insight.
The "why" is always going to be there.
They can only minimise the "why" and it does not necessarily shrink the "how".
For example, with BLS, the why is shrunk to a single signature, but you still have a list of "outputs" and "layer-2 db updates" to perform sequentially.
They can only minimise the "why" and it does not necessarily shrink the "how".
For example, with BLS, the why is shrunk to a single signature, but you still have a list of "outputs" and "layer-2 db updates" to perform sequentially.
Reducing the "how" will also involve a range of magic tricks that may become application-specific.
Now this brings us to the ZKRU world.
- The function(input) never hits the layer-1 blockchain / Ethereum.
What? paddy? what do you mean the function(input) never hits ethereum.
Now this brings us to the ZKRU world.
- The function(input) never hits the layer-1 blockchain / Ethereum.
What? paddy? what do you mean the function(input) never hits ethereum.
Well, it doesn't need to be.
The "why" is the zero knowledge proof and the "how" is the final output/state update/state diff/how you should update your layer-2 database.
The list of individual transactions / state updates are not publicly published. Just the final result.
The "why" is the zero knowledge proof and the "how" is the final output/state update/state diff/how you should update your layer-2 database.
The list of individual transactions / state updates are not publicly published. Just the final result.
To understand why. Let's step back a bit.
A ZKSequencer is provided:
- db_state1 (current L2 database state)
- list_of_transactions (L2 transactions to execute).
ZKSequencer can execute the L2 transactions against db_state1 to compute:
- db_state2 (new layer-2 database state).
A ZKSequencer is provided:
- db_state1 (current L2 database state)
- list_of_transactions (L2 transactions to execute).
ZKSequencer can execute the L2 transactions against db_state1 to compute:
- db_state2 (new layer-2 database state).
Now, the ZKSequencer needs to compute the "why" and this is basically the zero knowledge proof.
They are simply proving, that given a secret witness (list_of_transactions), the transition from db_state1 to db_state2 is valid.
They can then just publish proof + db_state2.
They are simply proving, that given a secret witness (list_of_transactions), the transition from db_state1 to db_state2 is valid.
They can then just publish proof + db_state2.
Of course, there are implementation details, on what "db_state2" will be in practice. But the general idea is that the list of individual state updates for every transaction does not need to be published publicly.
You just need the final aggregated / batch update.
You just need the final aggregated / batch update.
But there is still an unspoken elephant in the room.
If you want aggregation / batch updates, while keeping the individual transaction data off-chain, then ๐ฒ๐จ๐ฎ ๐๐ซ๐ ๐ญ๐ซ๐ฎ๐ฌ๐ญ๐ข๐ง๐ ๐ญ๐ก๐ ๐ฌ๐๐ช๐ฎ๐๐ง๐๐๐ซ ๐ฐ๐ข๐ญ๐ก ๐ญ๐ก๐ ๐จ๐ซ๐๐๐ซ ๐จ๐ ๐ญ๐ซ๐๐ง๐ฌ๐๐๐ญ๐ข๐จ๐ง๐ฌ.
If you want aggregation / batch updates, while keeping the individual transaction data off-chain, then ๐ฒ๐จ๐ฎ ๐๐ซ๐ ๐ญ๐ซ๐ฎ๐ฌ๐ญ๐ข๐ง๐ ๐ญ๐ก๐ ๐ฌ๐๐ช๐ฎ๐๐ง๐๐๐ซ ๐ฐ๐ข๐ญ๐ก ๐ญ๐ก๐ ๐จ๐ซ๐๐๐ซ ๐จ๐ ๐ญ๐ซ๐๐ง๐ฌ๐๐๐ญ๐ข๐จ๐ง๐ฌ.
Batching only works if the sequencer has time to collect the transactions and decide the final order. This is because it is the sequencer, and not the layer-1 blockchain, that is deciding the final order of transactions.
In the ORU world, at least for arbitrum, anyone can
In the ORU world, at least for arbitrum, anyone can
post their layer-2 transaction to the layer-1 ethereum blockchain (called the 'inbox').
This will finalise the order of transaction execution. So the user can have a 100% guarantee that the transaction will execute as they expect. There is no need to trust the sequencer.
This will finalise the order of transaction execution. So the user can have a 100% guarantee that the transaction will execute as they expect. There is no need to trust the sequencer.
Aggregating and batching, while it saves gas, moves a fundamental trust assumption in terms of transaction ordering.
That can be the correct trade-off to make. But you should be aware that magic does not come for free.
I hope this thread helps. I am but a simple observer,
That can be the correct trade-off to make. But you should be aware that magic does not come for free.
I hope this thread helps. I am but a simple observer,
so take my comments with a pinch of salt. But I do believe that 99% is pretty accurate.
