Content
@
https://www.optimism.io
0 reply
0 recast
2 reactions
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
Drew Fisher
@drewf.eth
I don’t see how this is any different than a deposit-wrap bridge in practice. If the L2 side of the bridge can mint eth on L1, it’s the same security posture. The only change is that the L2 receives the right to mint tokens instead of the right to transfer them.
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
> I don’t see how this is any different than a deposit-wrap bridge in practice. There is no need for a bridge contract to custody funds, as opposed to a deposit-wrap bridge. > If the L2 side of the bridge can mint eth on L1, it’s the same security posture. No L2 can mint ETH on the L1 today. 1/2
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
> The only change is that the L2 receives the right to mint tokens instead of the right to transfer them. A right that is granted with both cryptographic and consensus security, and mechanically extends the Ethereum Ledger outside of the Ethereum blockchain system.
1 reply
0 recast
0 reaction
Drew Fisher
@drewf.eth
Is this not exactly what a bridge contract already does? It uses the consensus on the L1 EVM to send eth out of itself and to some other party on L1. Why make every client implement a new storage tree and tx type that could instead be storage in an EVM contract, modified by calls in the EVM instead?
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
1. Bridges today use the EVM/Execution Layer to function, they don’t inherently benefit from the consensus security. Their existence is just a payload on the consensus stack. 2. Because this moves beyond the EVM, and focuses on native Ether. Different scopes.
2 replies
0 recast
0 reaction
Drew Fisher
@drewf.eth
Your solution so far requires the EVM, as your burn gives a specific contract the right to mint the eth again later. If you want any contract to be able to burn into this system, you need to expose this functionality in the EVM too. There’s no reason to move outside the EVM, it adds complexity for no discernible gain
1 reply
0 recast
0 reaction
Emmanuel🦉⌐◨-◨🎩🍥
@emmanuel
It actually doesn’t require the EVM, because the EVM isn’t required to create/destroy Ether. It’s technically not giving a contract rights to mint. The contract only ensures the validity of the Burn Tree of the L2 as it does that anyway for all of its state. Only keys of users and block producers are involved.
1 reply
0 recast
0 reaction
