Content pfp
Content
@
https://www.optimism.io
0 reply
0 recast
2 reactions
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
The cross-chain transfer of value, such as ETH from Ethereum(L1) to an OP Stack chains like OP Mainnet(L2), is facilitated by validating bridges, which bear significant requirements + processes to ensure security. What if these bridges were leaner and more secure? 🧵 1/n https://warpcast.com/emmanuel/0xabc70ecd
3 replies
0 recast
5 reactions
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
Today, validating bridges for OP Stack chains involve a few dependencies: - The necessity to create wrapped versions of Ether on L2. - The requirement for bridge orchestrators to custody L1 value while it is being bridged, via bridge contracts. - High dependency on the bridge contracts to enter/exit systems 2/n
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
These result in complex bridge designs, laden with numerous third-party processes. Plus, they don't harness the full security potential of the Ethereum core protocol, relying instead on app-level mechanisms such as fault proofs.(Note:This isn't a knock on fault proofs; they're still valuable for various purposes) 3/n
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
I'd like to propose a bridging system for the OP Stack that does NOT require: - bridge contracts to custody L1 user funds - the wrapping of ETH in order to utilise on the L2 While still being able to deeply inherit security from the Ethereum core protocol, especially its Consensus and Ledger rules. 4/n
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
This bridging system ideally leverages certain basic cryptographic primitives, such as public key cryptography and zero-knowledge cryptography. Particularly, this should allow end-users to independently move their funds between L1-L2 systems with only the data published and consensus work on the L1. 5/n
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
An intriguing feature introduced on Ethereum in the summer of '21, EIP-1559, revamped the fee system and allowed for the burning of Ether during ledger state transitions and consensus processes, such as block production. EIP-1559 is core to this proposed bridging system, but how? Burning. 6/n
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
The concept involves burning Ether designated for L2 bridging directly from the Ethereum Ledger, using the processes enabled by EIP-1559, and generating proofs of these burn events for minting Ether on the L2, like OP Mainnet. Note: Ethereum has a dynamic cap on Ether so this shouldn't impact its economics much. 7/n
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
Because the burning of Ether will be done by block proposers, thanks to EIP-1559(a modified version of it), as a natural part of consensus tasks, it should provide a strong guarantee and public transparency for end-users and L2 contracts to rely on. The same process should apply for L2s when returning value to L1 8/n
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
Ideally, a secondary state tree system, let's call it the 'Burn Tree,' should be implemented to track all burnt Ether designated for bridging. This system should store records in a manner similar to UTXOs rather than account balances. The Burn Tree is updated after every L1 block. 9/n
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
The Burn Tree is also used for minting Ether when it's being bridged back to Ethereum L1. Ideally, this process should piggyback on the coinbase event that issues new Ether. In this event, block proposers receive their rewards, and a separate issuance is made to the address of the end-user who is bridging back. 10/n
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
Because the L2 reads L1 data to function, it can track the Burn Tree and its updates to allow Ether issuance on the L2. Similarly, as the L2 dumps data to the L1, end-users can track the L2's Burn Tree to reissue Ether on the L1. NB: L2s have their own Burn Trees. 11/n
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
So let's say Alice wants to move 2 ETH from Ethereum to OP Mainnet. Alice builds a transaction that: - marks her 2 ETH for burning - provides the OP Mainnet state contract ID, which should be a unique hash of some sort. - provides the Ethereum Burning Tree ID, also unique hash. - indicates her public address 12/n
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥 pfp
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
Block proposer includes Alice's transaction and applies it on the current Burn Tree to update it. Bonus: Ideally the block proposer or Alice should be able to generate a SNARK or similar of the burn event, to serve as Proof-of-Burn, kind of additional cryptographic strength. (NB: I'm not a cryptographer) 13/n
1 reply
0 recast
0 reaction