Brecht Devos
@Brechtpd
Followers
2K
Following
616
Media
10
Statuses
298
@gwyneth_taiko and @taikoxyz, prev @loopringorg
Joined July 2017
An easy way for L2 smart contracts to read the latest L1 data (or L2 data from an L3) in a way that is also easy to prove for L2s that are EVM equivalent and use the same state tree format (like type 1 ZK-EVMs):.
4
29
121
Booster rollups: rollups that execute transactions as if they are executed on L1, having access to all the L1 state, while also having their own storage. This scales both execution and storage on L2, using the L1 as a shared base.
7
20
92
Booster rollups as ZK coprocessors: You can read a summary below. To recap: Booster rollups are rollups that execute transactions like they are executed on L1, having access to all the L1 state, but they can also have their own storage.
8
19
83
Booster rollup update!. Quite a few things have changed so an update seemed necessary. The latest WIP design doc can be found here: Below a summary of the most important stuff.
5
21
72
@sendmoodz Using assembly, and likely still contains some mistakes, but ~80% gas improvement, still some small improvements left probably:
2
3
71
Wrote an explanation of the overall design of @gwyneth_taiko:. Read the thread below for a summary.
2
18
66
I made a @metamask_io plugin that can be used to sign zkRollup transactions for exchanges built on @loopringorg in the same way (or even better than) Ethereum transactions are signed. We're eagerly awaiting the release of MetaMask's awesome plugin system so we can start using it!
2
9
62
L1CALL is great. It allows the execution of L1 smart contracts directly from L2 (without persisting any of the state changes of course). L1DELEGATECALL could also be helpful to help connect L1 and L2s and make it look more like a single parallelized execution environment.
An easy way for L2 smart contracts to read the latest L1 data (or L2 data from an L3) in a way that is also easy to prove for L2s that are EVM equivalent and use the same state tree format (like type 1 ZK-EVMs):.
5
19
55
Some people expect L1 validators to build blocks for based rollups. L1 validators almost never even build the blocks for L1.
7
4
46
Just in time for interop day. A sketch of how to extend @gwyneth_taiko's synchronous composability to non-gwyneth rollups. High level and hastily written. More to come (or not if it's a bad idea, then we all simply ignore this ever happened okay).
10
5
48
How efficient can based rollups get?. In an ideal world, there are lots of based rollups, lots of transactions, some blob data sharing service, and each L1 block makes the most of L1 blockspace. Pat on the back, pat on the butt, good work team, we’re done. But, read on.
2
10
41
Transactions vs state diffs for rollup DA. A classic discussion. But an interesting one, especially with multiple chains interacting with each other. Recently I started to appreciate state diffs more and more for their simplicity and efficiency. Some reasons below.
2
2
29
Created an EIP for improved introspection capabilities in Ethereum blocks: The proposal makes it efficient to switch between L2 and L1 execution while ensuring data consistency, something that is especially useful for synchronous composability with L1.
2
3
30
@jbrukh @hagaetc @loopringorg Loopring is a zkRollup, ALL the data is available on Layer 1! It depends on the layer 2 project how this data needs to be decoded, but that's also publicly available. It's just a bit harder to read compared to layer 1. You can check our Dune how to do this (with source code!).
0
4
16
A trick to check in a contract if you're in the 1st tx of a block. Set the tx gas limit to the block gas limit, check:. block.gaslimit - gasleft() - intrinsic_gas_cost < 21000. In @gwyneth_taiko, this gives execution preconfs with latest L1 state using the prev block's state root.
1
2
17
I participated in the phase 1 ceremony for Plumo!. brechtpd 0x3cc9396ee7fd35bef44b0e8ab80151225e26c120 fcf15a433ddb24a248ed916a187da317bdb06c281bd5e5a2797de62c25d51eee65728efb837f6f236c9cbfe06d208204f58baa8b75b9e99c79797cb60f89c5891b.
1
2
10
Great/simple DevEx touted as one of the key goals for interop between chains. On @gwyneth_taiko, doing cross chain calls (to L1 or L2):. EVM.xExecuteOn(targetChainId);.uint result = inputs);. Just set the target chain before your normal call. That's it.
4
0
12
The most important benefit is that each application deployed on L1 is immediately available on each booster rollup. If more scalability is needed, just add an extra booster rollup. Nothing needs to be deployed to it.
1
0
11
@toghrulmaharram - I’m shilling L2 AND L1 sync composability. I’m not conveniently omitting anything though. Higher requirements than Solana for builders is optional. - Nobody is saying anything about having to do it. Instead, it’s about wanting to do it. Why would you not want to do it?.
The more chains are accessed in a single tx, the bigger the block builder will have to be, and so the inclusion of the tx may require additional fees. Parallelization of the block building depends on how many chains are accessed.
2
1
12
Deploying a booster rollup is like adding an extra CPU and SSD to Ethereum, with applications capable of taking advantage of those extra resources automatically doing so. If apps are not natively capable of doing this, instances of the app can still be used on any one of the L2s.
1
1
10
No need for developers to deploy to all L2s. And no need for them to keep their app up to date on all L2s manually. Deploy (and apply updates) once, and scale automatically over all booster rollups currently deployed and also all booster rollups added in the future.
1
0
10
A user's EdDSA keypair is generated using the secret App Key exposed by their plugin system. The same keypair is regenerated when the user restores from his seed phrase. The source of the plugin can be found here:.
1
0
10
@VitalikButerin @PingChenTW @loopringorg On the protocol level we just need to add the verifications keys of our transfer circuits to our block verifier contract and we're set (it was part of our trusted setup). The only thing stopping us from exposing this on @loopringorg exchanges is some frontend/backend work.
0
2
9
I just made the contribution #310 to @TornadoCash Trusted Setup Ceremony! 🚀 Let's make it more secure and trustless #TornadoCashCeremony
0
0
8
But also still making the original txs available for transparency and verifiability. This is also simple because those are direct inputs. This data (and other helper data) could even be posted on an alt DA because not security critical when the state delta's are already on L1.
1
0
7
Cross layer sync txs will be possible through the `XCALLOPTIONS` precompile, which adds some additional params to `CALL` opcodes, most importantly it specifies the target chain. This allows calling contracts on any other booster rollup, for synchronous read and write access.
1
0
7
The interconnectivity given by being based will be great, but I think it can only work really efficiently when the quantity of independent based rollups is reasonably small, otherwise onchain costs will still be big. Each based rollup should still be able to scale on its own!.
1
0
8
@MihailoBjelic @dankrad I don't think his statement is wrong because he just reiterated what the current definition of an L2 is. However, you can think that none of the scaling solutions currently on Ethereum achieve that definition without any caveats, which may be true (contract upgradeability,. ).
2
0
8
So yeah, state delta's. Simple. Efficient. Non-transparent. I also want to be simple, efficient, and non-transparent.
1
0
7
This is mostly just a continuation, and perhaps one of the logical conclusions, of this dapp parallelization idea I posted earlier, explaining L1CALL/L1DELETATECALL:.
L1CALL is great. It allows the execution of L1 smart contracts directly from L2 (without persisting any of the state changes of course). L1DELEGATECALL could also be helpful to help connect L1 and L2s and make it look more like a single parallelized execution environment.
3
0
7
Another major benefit is that booster rollups look exactly like L1. All dapps/smart wallets have the same addresses they do on L1.
1
1
7
L1DELEGATECALL only uses the deployed code on L1, while allowing the state to be stored on L2s. This achieves something similar to standard program parallelization, where code is run in parallel on CPU/GPU threads, with each instance having its own local memory/storage.
1
0
6
It is possible to emulate L1DELEGATECALL by using L1CALL to get the bytecode and then locally deploy it, which depending on the cost of L1DELEGATECALL could be worth it. But where's the fun in that?.
0
1
7
`XCALLOPTIONS` also allows calling into L1 to execute smart functions against the latest known L1 state, initially only for read access but eventually also for write access. This already allows for pretty good composability with L1.
1
0
6
It may require some code changes for smart contracts that want to take full advantage of this system, to make the dapp truly parallel. But even without those changes, a lot of the benefits are still there.
4
0
7
@MMJahanara @arixoneth L2 <> L2 and L1 <> L2 reads/writes will be possible. An approach that allowed L1 state writes was given here: ( but I think there are better ways to do it now. It's still pretty new though, will share when things are more finalized.
1
0
8
@MihailoBjelic @Quiveringsphinx @dankrad @loopringorg Agreed that trusted setup can be an additional trust assumption, but only a single participant (which can be the user itself) needs to be honest. Centralized operator not important for security of user funds though, censorship resistance is handled by L1 for that so is as strong.
1
0
7
This is of course quite similar to other ZK coprocessors, like zkUniswap and @axiom_xyz, except in those cases some specific functionality is handled offchain. In booster rollups, the same L1 environment is maintained no matter where a transaction is executed.
1
0
7
However, for true L1 synchronous composability we need based rollups with combined L1 and L2 block building and very fast zk so that blocks can be proven immediately when they are proposed!.
1
0
6
But! Any batching is very unlikely to be possible when transactions require L1 composability/fragmented sequencer rights between L2s. So hopefully we'll get to that ideal world as soon as possible.
0
0
4
Allow dapp devs to define what they want to do in a synchronous way because it’s simpler and security critical. Make builders fulfil that intent in an efficient way, which could be asynchronous and based on access patterns. Smart contracts define what needs to happen, not how.
4
0
8
Booster rollups allow scaling a chain in many ways. A single booster rollup instance can be used as a fully independent EVM environment, a ZK coprocessor, or anything in between, simultaneously.
1
0
7
I participated in the phase 2 ceremony for Plumo!. brechtpd 0x3a8abb85c2fc8704056428665643975fbe3e42d5 966fc86e7bee3a8c03b90bad017f1f0199e82753751a860ceb78f1ac84975ae1256c6cf3f13486f99ec502afb8aaf04bab5a91e63214a57e11a7f813a5749faa1c.
3
0
4
They allow all L1 smart contract work to be offloaded to L2 using a ZK-EVM, while keeping all state on L1. The only work required on L1 is verifying the ZK proof and applying the final state updates back to the L1 smart contracts.
1
0
7
In based rollups, whoever is making/proposing blocks is incentivized to propose as soon as it's profitable. Not doing so would mean that someone else would be able to earn that profit because anyone can propose (because they likely have a similar block with similar profit).
2
2
5
So you could see the L1 as a way to store the shared data and application logic, while L2 is for executing those applications in parallel.
1
0
5
Cross layer txs will automatically spawn sub-transactions on all touched chains. This means the user only has to sign a single tx, and the full transaction fee is paid on the originating chain. Gas costs are tracked similarly to if the tx would be executed on a single chain.
1
0
5
This will allow the L2 to see if the call would have been successfully executed on L1 and allows measuring e.g. the gas used. The resulting state root could also be made available, because that would allow checking for any state changes that have occurred inside the L1CALL.
1
1
5
@Tetranode An L1 tx for creating an account isn't required anymore on Loopring today! This was true in v1 when the article was written, but that was quite some time ago and we released a v2 5 months ago with lots of improvements.
1
0
6
@AngelBlockVC @DexWars @0xProject @KyberNetwork @UniswapExchange @tokenlon @oasisdex @idexio @loopringorg @DexWars What do you need to include @loopringorg? We'd very much like that. By being a zkRollup things will be a bit more complicated than fully onchain DEXs. We will likely track volume on @DuneAnalytics shortly, but already have a JS parser lib:
0
0
5
The infrastructure (like block explorers) surrounding Gwyneth is equally important. Users should be able to use all L2s inside Gwyneth in a consistent way. The user experience surrounding the chain should not be fragmented.
1
0
5
Calling into L1 can be done without any additional gas cost because booster rollup nodes will support syncing with L1 and any number of specified booster rollups in a single node. This allows accessing data from these chains at native performance and so at identical gas costs.
1
0
6
This allows using a booster rollup as a ZK coprocessor for all supported smart contracts on L1 or for one or more specific smart contracts. For example you can have a booster rollup for L1 in general, and use additional booster rollups as ZK coprocessors on a dapp-by-dapp basis.
1
0
6
@toghrulmaharram I mean yeah, this is why real time proving is important. Does away with interdependencies. If it makes sense depends on if you think this overhead (which could be small) is worth it. For me it’s a yes: simplicity, capital efficiency, and single chain UX between ALL L2s and L1.
0
0
6
The main argument for state diffs has always been that it can be more efficient DA wise. State diffs can use less data than the txs themselves. The argument against is that you lose on transparency and verifiability. The data efficiency discussion on its own is not so interesting.
2
0
6
It is very inefficient to have hundreds/thousands of L2s all spread across different contracts. It also has a hard dependency on very fast zk proofs so that all based rollups can be connected together without additional trust assumptions.
1
0
6
Boosting can also be done on a dapp by dapp basis on a non-booster rollup with some more manual work. For rollups that are already Ethereum equivalent, the only additional requirement is that the L1CALL/L1DELEGATECALL precompile functionality is exposed in some way.
4
0
5
Dapps can also run exactly the same on an L2 as they do on L1, but they don't have to. That's a choice of the developer. It's still possible for smart contracts to behave differently when that's required.
1
0
5
Contract creation support on L2! Initially contract creation was disabled on L2 for a completely uniform experience among booster rollups/L1. This works well for dapps, but is limiting for things like smart wallets where users would still have to pay high deployment fees on L1.
1
0
4
@zengjiajun_eth @umedeyay @gwyneth_taiko Currently just focusing on L1 + Gwyneth L2s, I'm still thinking about how best to get other L2s involved as well.
0
0
5
Do we need the built in synchronous composability between booster rollups when they could already be connected in this way if they are all based rollups (and so already share the same sequencer)? Theoretically yes, but!.
2
0
5
Txs for the booster rollups are combined in a "super block". That is, txs are simply ordered based on the sequence they should be executed, regardless on which chain they will execute. The ordering/what transactions (and for which chains) is completely up to the block builder.
1
0
4
For now, we do have two reasonable (but imperfect) options of very fast and cheap validity proofs in the form of TEE and crypto-economic based systems. These will provide strong guarantees, but are not infallible. So there will be some caveats until zk proofs will be available!.
1
0
4
This means there is additional overhead on the proving side because the logic is not written in the most efficient way, but having a single general solution that is usable by all smart contracts with minimal work seems like an interesting tradeoff. They are complementary.
1
0
5
@ConnextNetwork @humansarealrig1 @pedrouid @loopringorg Can you point us to an implementation of such a smart contract? Would be very helpful to try and figure out what kind of logic we'd need to support and when we'd need to run it.
1
0
4
If the app is deployed behind an upgradeable proxy, read the latest implementation address from L1 using L1CALL and then do an L1DELEGATECALL to that implementation contract. This way all L2s are automatically in sync, no need to update smart contracts for each L2 separately.
1
1
4
When not in the 1st tx, we generally need some kind of introspection of the current L1 block. A possible way to do this is given in the Gwyneth design doc, but this can require additional EVM functionality:
0
0
5
Gwyneth is a booster rollup. Booster rollups allow DApps to scale natively, deploy once on L1 and automatically scale across all L2s. They also allow very efficient access to L1. L1 can be accessed at L2 costs. L1 state updates can generally be done using less gas on L1.
1
0
5
Gwyneth is still under heavy development and anything can still change. Please reach out with any comments, feedback, or if you want to help make this a reality.
0
0
4
So while the protocol does not have any limits on block building parallelization, in practice it is limited by the processing capabilities of the block builders and block provers. Onchain this super block is proven using a single proof.
1
0
4
@jon_charb Q2 is the answer to Q1. Just shows that people choosing to build based rollups can do it for the wrong reasons. You can be right but still wrong. People building based rollups is just a group of people, listening to one may not be satisfactory. (yes that includes me).
0
0
5
If you want to run Uniswap on L2, you only need to deploy a standard proxy contract on L2 which does an L1DELEGATECALL to the Uniswap L1 implementation smart contract. Legal? Unlikely. Cool? Certainly.
1
1
4
L1DELEGATECALL allows you to run a smart contract on L2 without actually deploying the smart contract on the L2, which is pretty interesting just by itself.
2
2
3
@loopringorg The stats that are shown are from the first phase of testing done by @WeDEX_io. Their next phase of testing will start soon, which you'll be able to see in these Dune stats!. Our upcoming DEX browser will be able to show more details about the transactions in the blocks.
0
0
5
But because of the synchronous nature, this L2 may be dependent on the state of other L2s. In an ideal world, we have zk proofs so that a validator can be sure of the correct state of the other L2s without running a node for them. But we're not there just yet.
1
0
4
The more chains are accessed in a single tx, the bigger the block builder will have to be, and so the inclusion of the tx may require additional fees. Parallelization of the block building depends on how many chains are accessed.
3
0
5
@ChainLinkGod @loopringorg Important to note here is that the internal trusted setup is only temporarily until we're sure everything is running correctly and the code is final. In a couple of weeks we're certainly going to open up the trusted setup for the public again just like we did last year!.
2
0
5
@ayyyeandy Why would it not make it based though? Nobody expects the L1 proposer to be able to make blocks for all based rollups by itself. Relying on 3rd parties that are either picked by the L1 proposer or can contribute permissionlessly is what is expected for based rollups.
2
0
4
Gwyneth bets big on composability. Any value capturing mechanism, either on the protocol level or on the DApp level, should not degrade composability or censorship resistance.
1
0
4
@aliatiia_ @VitalikButerin @taikoxyz Not sure I understand, this cheaper type of proof should be identical to having a full ZK-EVM proof for the withdrawal tx. The bridge would unlock/mint tokens on the destination chain only if the proof is valid for the source chain (whatever that proof is).
1
0
3
Booster precompiles:.- L1CALL: Allows reading/writing L1 state.- L1SANDBOXCALL: Allows reading/writing L1 state, but at the end of the call the L1 state changes are reverted.- L1DELEGATECALL: Execute a smart contract stored on L1, but all storage reads/writes use the L2 state.
1
1
4
Gwyneth supports based preconfirmations. These preconfirmations will be a bit trickier because of the synchronous composability with L1, but a lot of great infrastructure is being built around preconfs already.
1
0
4
There are many possible use cases for this, but a very common and obvious one would be ERC20/NFT contracts. Tokens need to work on all L2s, and they have some shared state (total balance, NFT token data,. ).
1
1
2
@MMJahanara @arixoneth But I think the term liquidity fragmentation is mostly used for L2 <> L2, the booster rollups we were going to make always allowed for synchronous composability between the L2s themselves (with the shared "bridge" being the app itself on L1, so tokens can move freely between L2s).
0
0
4
@thegaram33 @Junger0x For @gwyneth_taiko, the answers are in the technical design: For the general case for any rollup, I'm currently working on GLUE. A first sketch for GLUE I wrote about earlier, but will have a more in depth design on this very soon:
Just in time for interop day. A sketch of how to extend @gwyneth_taiko's synchronous composability to non-gwyneth rollups. High level and hastily written. More to come (or not if it's a bad idea, then we all simply ignore this ever happened okay).
1
0
4
But not HAVING to know what happened in a block is also a very nice feature! Just apply the list of state updates and you're on the latest state. Especially when doing cross chain calls, this is a very nice property.
1
0
4
The benefit of making the precompile like this vs dedicated precompiles that would do an actual call is that doing these cross layer txs can still be done using standard solidity code. Now only some precompile needs to be called before the standard call to set some extra options.
1
0
4
This avoids having to do any compiler modifications to make it easy to do these cross layer calls, or alternatively any tedious manual ABI encoding/decoding of function calls and return data.
1
0
4
There are already efforts underway to make an L1STATICCALL. That's great but I think going all the way by allowing a general L1CALL would be even better. L1CALL would allow calling any smart contract function with state changes (that of course don't actually change the L1 state).
2
1
3
It is possible to deploy contracts using CREATE2 on any L2. It can be made sure that the same address (with the same code) can be claimed on any other L2 and L1 when necessary. CREATE will also work, but will additionally hash in the chain id to make it unique.
1
0
4
@donnoh_eth @Junger0x @taikoxyz Current implementation is only to support the upcoming preconfirmation testnet! Won't be on mainnet soon (well, one may hope not too long though). We definitely need to be very careful how we handle limitations on block proposing.
1
0
4
We do this by (re)introducing the L1CALL precompile. L1CALL executes transactions against the L1 state, with storage reads/writes working like normal. We record all L1 storage updates that happened during those calls on L2 so that afterwards we can apply them back to L1.
1
0
4
The efficiency of this is great for smart contracts where only a limited number of storage slots get updated by a lot of L2 transactions (think for example a voting smart contract), or where certain operations just require a lot of logic that is expensive to do directly on L1.
1
0
4
@crypto_fruit @loopringorg That's correct! We've already made a MetaMask plugin that would be nicer than our current password system, but we need to wait on MetaMask to release a new version of their extension before we can start using it:.
I made a @metamask_io plugin that can be used to sign zkRollup transactions for exchanges built on @loopringorg in the same way (or even better than) Ethereum transactions are signed. We're eagerly awaiting the release of MetaMask's awesome plugin system so we can start using it!
0
0
4
So there will be no need for a single builder to run nodes for all L2s! Txs will have to specify which chains they access as part of the tx so that builders know which chains they need to run a node for to be able to handle the tx.
1
0
4
Because the L2 transactions work directly on the L1 state, the booster rollup is stateless (except for needing the L1 state of course). There is also no data that needs to be put on L1 for safety. (There are some nuances here, check the post!).
1
1
4
It is not guaranteed that anybody except the block builder (or insert any other name for whoever is doing that here) knows what actually happened. And knowing what was actually done in a block is kind of a useful thing.
1
0
4
@ChainLinkGod @loopringorg @VitalikButerin @StarkWareLtd Brecht from Loopring here. We should be fully production ready in February. To achieve our maximum throughput we first need to improve the relayer. We recently released an update with some more details on this:
1
1
4