Very interesting proposal
1 Like
amazing, i hope you do everything like you want.
1 Like
Indeed, current gas cost are not aligned with proving costs and we can’t use them as is. But if they evolve and get aligned, we will use them.
1 Like
I cant say more then LETS DO IT !
1 Like
interesting, going to watch how it unfolds
1 Like
Very great proposal, the design takes some great and new approaches to combat MEV.
Beside the questions and suggestion mentioned earlier I have only the following to add:
- The protocol needs to consider Ethereum reorg implications in the design, as a submitted blob could be included in a block that gets reorged, as mainnet doesn’t have single slot finality.
For reference, reorgs on ETH are pretty regular, you can check on etherscan .io /blocks_forked
(Sorry cant post links)
In volatile situations that could lead to a blob being dropped from L1 causing problems of L2 state.
The node performing finalization could technically complete the requirements but the state of Ethereum would show the opposite a couple of blocks later.
At that point would the protocol revert to this?
In case the node which won the reverse auction does not post data or proofs in a timely manner, any other node can perform the finalization on his behalf. The first node completing it will get the reward. The stake of the faulty node is used to cover extra fees or burnt.
I believe the rewards should be unlocked at later block, and unstaking should have a delay to prevent unintended situations due to Ethereum reorgs. A secure setup would include 7+ Ethereum blocks, which would be 84 seconds delay. For nodes this latency would not hurt operations.
With these additions the protocol would revert to the situation that any node can perform finalization, but I would also suggest adding a delay of 1-2 blocks so that the original bid winner would have time to resubmit.
Also these aspects would add a cryptoeconomic guarantee for reorg resistance originating from mainnet, this design will be a very strong USP for builders.
- It would be also great to understand L1 finalization target times. There are great ways to pre-confirm L2 state before L1 finalization, but long-term Linea will benefit from faster finalization. I am pretty sure this is already top priority internally
1 Like
The protocol could support any method to select the comittee from the validator set. The function that will be used is still to be decided upon, but as you mentioned the two main approach is to have a uniform probability or a probability proportional to the total stake (which could include delegated stake).
The idea is to treat discard messages as standard transactions. The fact that the committee rotates will lead to an honest committee accpting a block with them, cf:
We don’t use QBFT voting mechanism wrt discard messages.
This is 100% correct. If we make an assumption on the percentage of Byzantine nodes (or their stake) within the validator set, from the function used to select the committee, we will be able to give such a probabilistic guarantee on L2-finality. Also, what was important in the design is to have L1-finality all the time, not just with high probability.
Regarding the block proposers, requiring a stake for the proposer is a possibility. It will indeed make misbehavior more costly. This will require more work to answer the question, especially to estimate the cost of a bid to get the blocks. Regarding a malicious actor trying to outbid other nodes, we propose to have sealed bids and the buffer period to make it more expensive and less predictable.
Finally, regarding the L1 finalization, to make building block non profitable, the bid to get the right to propose a block should be more than the default reward a proposer get. We’ll keep this las point in mind!
1 Like
looks very good
1 Like
Myślę, że to bardzo interesujący artykuł. dzięki za to.
1 Like
Linea is best crypto project
1 Like
Thanks @Barna for taking time to read the proposal and to make these suggestions.
This is indeed a crucial point. Any information from L1 anchored on Linea must be anchored only once the L1 block containing the information is finalized. If not we would have inconsistencies between what is on L1 and what is on Linea. We currently do this for L1->L2 messages, and we need to do the same for L1 data used to claim rewards on L2, which rejoins your suggestion on unlocking rewards only at a later block. Given finalization time will be significantly longer than L1 block time, it’ll indeed have no impact on the operators.
Similarly, if the node performing finalization has till a L1 slot i to perform the finalization, other operators will get the right to perform the finalization only once the block of slot i (or the first one just after) is finalized on L1. It adds some latency, but it ensures that reorgs will not impact the process.
With respect to the L1 finalization target times, it currently is about half a day and we definitely work at reducing it as much as economic viability and proof generation time allow it.
1 Like
Great to hear! For sure Linea will be the best project on crypto market!
1 Like
Thanks for this article! 
I think everyone should stop here.
Oh! I didn’t expect an answer more than “about 1-2 hours”
1 Like
Is the block extradata going to contain the sequencer signatures after decentralization in a similar way how it can be used to verify block origin in current design?
Is there a plan to build smth similar to Beacon API on Mainnet for decentralized Linea? Giving the ability to quickly extract data and verify L2 finality?
1 Like
Very interesting solution. I look forward to more information and to checking how it works.
1 Like
Great project
1 Like
great project
Well written👏
1 Like
Wow, thanks, really intresting
1 Like