I made a quick website to visualize this:
The content is not very precise yet, so take it with a grain of salt. ๐ง I'll add more of my thoughts about preconfs to it later!
Preconfirmations (promises that users' data will be finalized on the L1) are very flexible and can promise many different things. Here are some thoughts about the key properties of preconfirmations, ranging from weakest to strongest kinds of promises for each property.
It's exciting to see discussion about shared sequencing, preconfirmations, and
@EspressoSys
in
@ethereum
's Reddit AMA yesterday! My thoughts in this thread:๐งต
Preconfirmations (promises that users' data will be finalized on the L1) are very flexible and can promise many different things. Here are some thoughts about the key properties of preconfirmations, ranging from weakest to strongest kinds of promises for each property.
Proof aggregation and shared sequencing are very compatible!
@EspressoSys
will have some more content on this soon, but here is the gist:
Espresso is a marketplace for shared sequencing that ensures L2s are always better off in Espresso than they are on their own. L2s also
An unanswered question in the rollup centric roadmap:
Can shared interoperability infrastructure (
@EspressoSys
,
@nebrazkp
) get L2s to join their common-space? (chain globalism)
Or will L2s build their own internal infra (agg layer), and keep strong borders? (chain isolationism)
This is going to be massive.
One of the biggest drawbacks of shared sequencers is the misalignment of incentives for rollups which *theoretically* lose revenue.
In today's Modular March recording,
@ellierdavidson
explained how
@EspressoSys
flips this on its head, coming ๐
I genuinely had such a great time working on this post, and I'd love to continue the conversation with anyone interested! Check out
@EspressoSys
's analysis of BFT and PP preconfirmations below!
We think a lot about rollup preconfirmations.
We have been working on a design we call Byzantine Fault Tolerant (BFT) preconfirmations. In our latest blog, we explore this approach alongside Proposer-Promised preconfs, as initially described in the context of based sequencing:
Shared sequencers will not cause a massive revenue reduction for rollup operators.
The common notion that rollups will opt out of using a decentralized, shared sequencer because of a significant loss in revenue is being to put to rest now.
For the 15th episode of our Modular
@hasufl
@benediktbuenz
Our marketplace is designed such that rollups set "reserve" prices. If the marketplace doesn't sell sequencing rights for at least this reserve price, rollups get to sequence for themselves (or designate it to whomever they wish). This means that rollups will only be sequenced
I love Espressoโs work all the time, but Based Espresso has me excited like nothing else. All I want to do is talk about it with people. Itโs seriously so neat!
Our mission is to preserve Ethereum's core value: composability.
Based Espresso is our latest development towards a future of composable L2s.
This design sees L2s retain autonomy over their sequencing rights, and supports any Ethereum L2, from based rollups to validiums:
I'm speaking at this Friday! I'll be speaking about how we can create encrypted mempools in shared sequencing protocols, but you should check out all the other talks, too! There should be some great, heavy-hitting content.
Preconfirmations: Shared sequencers should prioritize good UX, and preconfirmations are one way to do that. The Espresso sequencer natively supports BFT preconfirmations, which have stronger security guarantees than PP preconfirmations.
L1-composability: it's true that only L2s using the L1 sequencer can achieve atomicity between themselves and the L1. However, the Espresso sequencer can get pretty close through fast interop protocols, faster proving, and restaking.
Security: I personally disagree with the AMA here.
The Espresso sequencer can offer strong security guarantees through restaking, thus taking advantage of the economic security already on Ethereum.
Credible neutrality: like the AMA states, the Espresso sequencer is specifically designed to be credibly neutral. It is also rollup and ordering policy agnostic.
The AMA suggests 4 properties that shared sequencers should have: credible neutrality, security, preconfirmations, and L1 composability. Here are my thoughts on how Espresso fits into these properties.
@0xfuturistic
@benafisch
@Jskybowen
I'm not sure I understand the question. If a rollup opts into a shared sequencer, then the shared sequencer replaces the original sequencer. So there isn't an original sequencer that needs to share transactions. From a user's perspective, they would replace the old sequencer
Excited to release an implementation of a based preconfirmations protocol leveraging restaking: a POC for sub-second transaction confirmations on Ethereum โก๏ธ
Find out more about how it works with
@EigenLayer
and
@RelicProtocol
๐งต
@samlafer
@EspressoSys
Good question! These will all be on the same shared sequencer. Rollups can express which ordering policy they want and builders can build atomic bundles across rollups that satisfy each rollupโs policy.
@SashaSpiegelman
Thank you! The common counterargument I see is that n^2 protocols don't scale for > 100s of nodes. What if we wanted to scale > 100s of nodes? Are there any benchmarks that show at which number of nodes (for some given protocol) the message complexity starts to affect throughput?
@0xfuturistic
@benafisch
@Jskybowen
The orderflow is sent directly to the sequencing network, just as Ethereum orderflow is sent directly to the Ethereum network. If users want to give private orderflow, they can do that too by sending their transactions to specific sequencers within the network.
@hasufl
I see a few potential outcomes:
1. Unsophisticated preconfers will outsource preconfirmations to mev-boost / builders since preconfers need to calculate real-time profitability of transactions they are preconfirming. Unsophisticated preconfers can't do this locally, and
I really feel the crypto space could benefit from more empirical research. Theory is important (and usually way more fun!), but it doesnโt capture the entire picture, particularly when it comes to economic incentives / anything that involves interacting with real people.
@0xfuturistic
@benafisch
@Jskybowen
A user submitting a transaction to a rollup using a shared sequencer is the same as a user submitting a transaction to the Ethereum public mempool. ๐
@cryptobuilder_
@umededoteth
@januszg_
The true answer is that espressos can vary in size - usually somewhere between 25-40ml. So the doppios will also vary in size. ๐
@0xtaetaehoho
@eigenlayer
Like
@0xkydo
said, there are many preconf designs. In the specific case of bridging, there are a few options we have:
1. Use preconfirmation slashing as insurance. If the preconfirmation is reorged, the user can receive an insurance payout. However, this likely won't cover
@samlafer
You can also get atomic execution for cross L2-L1 transactions with based sequencing, which seems very useful. However, with careful design of a decentralized, shared sequencer you can achieve this as well.
@cwgoes
@NojSnow1
My two cents - I feel that things like MEV are easier to tackle in the sene that they are transparent - we can see the data of MEV, we can understand the games being played. We don't have the same advantage with VC, bank, and government games. ๐
@ballsyalchemist
@aztecnetwork
@specialmech
This is a great post! I feel like fast pre-confirmations really improve the user experience. I think it is very possible to build a lightweight consensus for this, such that the overhead is quite minimal compared to proving time. I'll write something up for the forum.
@samlafer
@EspressoSys
For example, if rollup A uses FCFS ordering and rollup B does not, a builder will make sure that rollup Aโs portion of the bundle adheres to FCFS ordering.
@0xPolygonLabs
This is a really cool design! The docs explain that atomic txns get a lock on the state of their respective chains, but only after the AggLayer executes them. Couldn't a invalidating txn come in to the chain between when the AggLayer executes and the chain locks its state?
Espresso is building a marketplace for rollups to sell their sequencing rights. We wrote up a detailed post on our market design: a combinatorial lottery that sells execution tickets for rollups or bundles of rollups. Please give us feedback on the design:
@gakonst
@llamaonthebrink
I've been thinking along these lines as well - I'd love to discuss more with anyone interested! My concern is that I don't think getting rid of synchrony assumptions gets rid of timing games. Builders will always want to spend more time maximizing their blocks.
@NojSnow1
@cwgoes
I strongly agree - it is very difficult to create the kind of goods we need to truly disintermediate when we need to rely on the very people we are trying to disintermediate.
@gakonst
@llamaonthebrink
To me, the key question is how do we make block builders not incentivized to play timing games? (And doing that is probably easier in an optimistically responsive protocol like HotStuff)