Exploring Eth’s Altair Light Client Protocol: t3rn’s vision
Recently, Ethereum's Altair Light Client protocol (ALC) has sparked a lively debate. As part of this conversation, we at t3rn, who are building an Ethereum light client, want to share our perspective.
The heart of this debate revolves around calculating collusion probability. The two popular viewpoints are the dynamic distribution approach and the binomial distribution approach.
James Prestwich proposed the dynamic distribution view. He suggests that malicious committee members can fluctuate in number. His reasoning is based on the lack of a slashing mechanism in the current system. Consequently, once validators join the sync committee, they could become malicious, submit valid header signatures to the Ethereum network, but also collude by signing malicious headers. They could then coordinate to exploit specific bridging protocols.
The second view treats the problem as a binomial distribution. It assumes a certain percentage of validators in a sync committee will be malicious. This viewpoint uses the cumulative binomial distribution to estimate the chance of successful collusion.
At t3rn, we fall into the second camp, however with some limitations. In our view, a sync committee validator that has malicious intent is malicious. This doesn't mean the validator is actively signing malicious headers, but that the validator has the intent and the technical capabilities to execute and coordinate such an attack. In our opinion, defining the problem as such warrants the analysis as a binomial distribution.
In the diagram above, we calculate the chance of successful collusion. We define a successful collusion event as 80% of sync committee members colluding. The y-axis shows the probability of a successful collusion event, and the x-axis represents the proportion of malicious sync committee validators. Even if half the validators are malicious, the chance of successful collusion is tiny. However, we start feeling uneasy once this percentage reaches around 60%.
The table below shows the collusion probability (p) for different majority shares.
You can find the Jupyter notebook used to create these numbers here.
Now, let's address some direct criticisms of ALC.
First, some argue that the sync committee might use malicious behavior as a new form of MEV. They could coordinate to sign malicious headers that exploit specific bridging protocols. While this is theoretically possible, we at t3rn find it hard to achieve in practice due to:
- The need for a participation rate of over 75% for a realistic chance of success.
- The implausibility of all participating members coordinating in secret.
We think this level of coordination is nearly impossible to maintain without detection. Light client operators could foresee this threat and secure their funds.
Secondly, some criticize ALC for its lack of a slashing mechanism. This absence could incentivize sync committee members to sign malicious headers. We agree with this criticism to some extent, as a slashing mechanism could punish validators attempting to collude, further increasing the difficulty of coordinating. The Nimbus team is exploring a solution, which we strongly support. However, we don't believe the sync committee is insecure due to the high coordination requirements.
Conclusion
In conclusion, the Altair Light Client protocol's implementation details and the potential for collusion among sync committee members are undoubtedly complex issues that warrant careful consideration. We, at t3rn, acknowledge the potential risks, but firmly believe that the probability of successful collusion is low, given the high level of coordination required and the likelihood of detection. Furthermore, with the Nimbus team exploring the potential for a slashing mechanism, additional safety measures could soon be in place to further dissuade potential malicious actors.
While the debate around this topic is healthy and necessary, it is also important to recognize the inherent complexities and uncertainties that underpin such discussions. The Ethereum community's concerted effort in designing mechanisms to secure the network is commendable, and we are proud to be part of it. As we continue to build our Ethereum light client, we are committed to contributing to this ongoing conversation, sharing our insights, and learning from others' perspectives.
The potential for collusion and exploitation will always be there in any system, but the strength of the Ethereum network lies in its community’s vigilance, rigorous analytical approach, and commitment to continual improvement. As we journey together into uncharted territory, we remain optimistic that solutions to these challenges can and will be found.
t3rn’s vision
The future of Web3 is multichain. t3rn has been built to enable this new paradigm in multichain programming, which is trustless, fail-safe and interoperable. We believe in trust-free collaboration, therefore the network will offer open access for anyone to join and play a critical role as Collator, Executor, Attester or Contracts Registry Builder.
Team t3rn will take a phased approach to rolling out the protocol, gradually releasing different features, showcasing and battle testing the network within a Substrate-based environment first before integrating with some of the foremost ecosystems in the industry.
About t3rn
t3rn is a multichain protocol that brings fail-safe, interoperable execution and smart contract composability to the Polkadot ecosystem and beyond.
t3rn’s ultimate goal is to enable trust-free collaboration between blockchains and to create an ecosystem in which anyone can utilize and deploy an interoperable smart contract, in an ecosystem where developers are fairly rewarded for their contributions.
Turn multichain with t3rn.
👉 Subscribe to our newsletter: Join 15,000 subscribers for exclusive monthly updates and insights, directly from Maciej Baj, founder & CTO of t3rn. - no spam, unsubscribe anytime.
