Author: The Rollup Source: X, @therollupco Translation: Shan Ouba, Golden Finance
At EthCC "Sequencing & CAKE Day", OneBalance hosted a panel discussion on the topic of chain abstraction and pre-confirmation, and The Rollup reviewed and summarized it. Panelists included:
Here are the full recap notes for the discussion
![7257086 qkFGxe7wDwXhjbOp17dAUo8jERJc8skbRoVnYOIF.jpeg](https://img.jinse.cn/7257086_watermarknone.png)
Preconfirmations change the dynamics of block builders.
Searchers now do most of the heavy lifting on a per-transaction basis. Yes, that means heavier proposers, but lighter builders.
PBS (Proposer-Builder Separation) separates proposers and builders, introducing the concept of builders, but now they have more work to do.
However, Vitalik believes that some form of PBS is preferable even for non-Ethereum-based Layer2s. Of course, Rollup-based solutions will bring more dependencies to L1.
The discussion quickly turned to preconfirmations, with the notion that there are two types: execution preconfirmations and inclusion preconfirmations.
Execution preconfirmations are a stronger type that guarantees ordering and provides a state root.
This is important for Rollup users who want security and fast finality.
Inclusion preconfirmations, on the other hand, do not make any guarantees about transaction ordering other than guaranteeing that a transaction is included before any other given transaction reaches the same state.
An important distinction to note here.
If there was a market where solvers were willing to buy stronger execution guarantees, they would buy them.
Are regular users or even users of DeFi? Do they care what the state root is?
We certainly want payment confirmation times to go from 12 seconds to 1 second, but including preconfirmations seems good enough for all practical users (and easier to build on L1).
Vitalik is concerned about over-optimizing to cater to "power" users.
Yes, an entity trading $100 million may not be satisfied with just including preconfirmations, as preconfirmations themselves require a lot of collateral.
How can these preconfirmations be executed? Even in the presence of collateral?
One way is to reach an off-chain agreement between users and sorters to set penalties on sorters to ensure that transactions are included and executed.
In short, the group reached a consensus that the purpose of preconfirmations is to make Rollup-based solutions work properly.
In addition, the purpose of Rollup-based schemes is to make shared sorting work.
The sorters need to agree on who the next sorter is. Therefore, there is a strong Schelling point for shared sorters (for sorting), which can fix Ethereum's fragmentation problem (atomic composability across Rollups).
As Arjun said, As the discussion turned to intent, his vision is that users no longer directly operate the chain, but interact with solvers.
The solver that provides the guarantee needs to be convinced that the funds on the source chain are safe and will not be reorganized.
Sam mentioned Skip has an IBC relayer and supports Hyperlane, but has no solvers and can connect directly to the target chain.
The validator picks up the message in both networks and passes it on the other side, which is a typical bridge design in this era.
The discussion went on for much longer, but here are some of our key takeaways:
Vitalik is not a big proponent of single-slot finality.
We are experimenting with Rollup-based solutions because they allow for shared ordering, which can solve Ethereum’s fragmentation problem.
There is a lack of consensus on “fast blocks and no pre-confirmations” or “slow blocks and fast pre-confirmations”.
Overall, this was a very technical, high-quality panel discussion that kicked off the week’s work.