pos - sounds great!
5 Likes
lets hope the best think about linea
6 Likes
One area that might warrant further discussion is the balance between inclusivity and the incentives for smaller nodes to behave correctly. While safeguards are mentioned, exploring additional incentive mechanisms might be important to ensure long-term decentralization without risking network inefficiencies or security.
The reverse auction process for finalization and its cost-optimization through compression is well thought out, offering a practical approach to ensuring fair cost distribution among validators. However, further clarity on how disputes in proof generation will be resolved or how malicious nodes could be handled could be beneficial.
Overall, this proposal positions Linea as a highly decentralized, secure, and efficient L2 chain. It would be helpful to dive deeper into potential edge cases and the scalability of these mechanisms as Linea continues to grow. Great work on outlining such a comprehensive strategy!
4 Likes
This overview of Linea’s plan for decentralization is clear and highlights some important points. Aiming for a fully decentralized L2 chain is great because it encourages more participation and reduces reliance on central entities. The distinction between L1 and L2 finality helps users understand transaction security, and linking L2 to L1 with smart contracts adds trust.
Using QBFT for fast L2 finality is a smart choice, especially since it works well with smaller groups. It’s crucial to have a reliable set of validators to avoid issues. The system also has good measures to deal with dishonest nodes, including slashing, which helps maintain integrity.
The outer protocol’s role in monitoring activity and ensuring blocks are available on L1 is essential for keeping everything running smoothly. Overall, the proposals seem well thought out for achieving decentralization while staying secure and efficient. Continued transparency and community involvement will be key to success.
7 Likes
omg huge proposal… and very exciting!!! LFG
5 Likes
Great to see a detailed proposal for decentralization, the use of QBFT consensus protocol and an outer protocol for validator selection and rotation seems well thought out.
6 Likes
great to see Linea got discussion like this
7 Likes
nice approach
5 Likes
Overall I agree with whats stated and the decentralization goals for Linea. Just remember the community who built your network and reward them properly.
6 Likes
agree with this
5 Likes
i think that the most important for decentralization is to have more sequencers…
5 Likes
Was eagerly waiting for this. Amazing proposal.
4 Likes
Amazing proposal indeed. Happy to be a part of this : )
4 Likes
good read!
5 Likes
Why so ? its correct
5 Likes
And still, so that I and other “non-programmers” do not get confused. To put it in simple words: If I make a transaction or a Smart Contract makes a calculation and it is written to the blockchain - what will be the finality of my transaction for me, as a user, what will I expect in the end: the operation is completed when the block is finalized in Linea (L2) or when it is accepted in L1? And what will happen if L2 finalized the block, but for some reason it did not pass to L1?
6 Likes
Hi, thank you for your detailed proposal. I’ve taken some time to review it and have a few questions and thoughts around specific areas that might benefit from further clarification.
Minimum Stake Requirement and Committee Selection
The protocol allows any node to join the validator set by staking a minimum amount of tokens. As others have mentioned, determining the minimum stake requirement is crucial, not only for decentralization but also as a general security measure (see my related question on Byzantine majority below). Specifically, is the committee selection process purely random, or is it weighted by the size of the stake deposit? If so, how do you manage the potential centralization risk, where larger stakeholders could disproportionately influence the selection process?
Mechanism of Discard Message Broadcasting
You describe a process where discard messages are used to remove Byzantine validators. However, it’s unclear how a discard message is deemed “accepted” by the smart contract. Does the protocol require a quorum from the committee for discard messages? Is there a possibility for Byzantine nodes to censor those messages?
Some PoA protocols, like Clique (which is also available in HL Besu), can use an epoch-based voting mechanism, where the validator set is re-calculated at the beginning of each epoch. It would be helpful to understand how voting and verification work with regard to discard messages.
Handling Byzantine Majority in a Committee
The proposal mentions that a committee with more than one-third Byzantine validators could affect liveness but not safety in L1-finality. However, if L2-finality is instant, this could lead to significant issues, such as consensus violations or conflicting blocks produced by malicious actors (e.g., hard-forking the L2 before L1-finality is achieved).
There’s a way to mitigate this under a super-majority assumption. For example, Algorand protocol uses a probabilistic approach for committee selection based on stake. By assuming 80% honest stake, Algorand minimizes the probability of selecting a majority of malicious nodes for each consensus round, significantly reducing the chance of a Byzantine majority. Have you considered adopting a similar probabilistic model based on stake to lower the risk of Byzantine dominance within a committee?
Block Proposer Incentives and Censorship Risks
The auction mechanism for selecting block proposers does not seem to require a stake deposit, which opens up potential risks. A proposer could win an auction, gain block creation rights, and then engage in malicious behaviors like transaction censorship or liveness attacks, particularly by repeatedly submitting high bids.
Have you considered adding safeguards to prevent such behavior from block proposers? For example, requiring a minimum stake or implementing slashing penalties for misbehavior could help deter attacks. Additionally, how would the system prevent a malicious actor from using the auction to repeatedly outbid others, thereby censoring multiple blocks in succession and degrading network performance?
Handling Empty Blocks and Finalization Costs
Regarding the L1 finalization process, you mention that block proposers must provision tokens to cover finalization costs, with any unused portion refunded after finalization. However, in cases where empty blocks are proposed, my understanding is that finalization costs would be minimal, potentially leading to near-complete refunds. Does this create an incentive for proposers to create empty blocks to avoid costs while still receiving rewards? How does the protocol prevent abuse of the refund mechanism in such cases, and are there penalties or checks in place to disincentivize empty blocks?
6 Likes
I agree with the proposals. I’m in the ecosystem for a long time! Greetings to all.
5 Likes
Very interesting.
As a linea user im on with it
4 Likes
Nice! really good article. worth to read!
4 Likes