Currently, the only way for a DApp to be validated is through an Authority validator. In this consensus scheme, a single validator is the source of truth to everything that happens on the application.
Although suboptimal, this solution allowed other parts of the stack to run while we develop the ideal tournament-based, permissionless, and decentralized consensus.
After the launch of Rollups V1 and with the development of the Dave arbitration on the way, the team recognized the opportunity to add another consensus option that improves on the idea of a single validator: the Quorum validation. With the Quorum, a DApp can have a fixed set of validators that vote on which claims should be added to the DApp history.
In this scheme, consensus can be reached without the need of off-chain coordination among validators. When a validator publishes its claims, a counter related to the claim is incremented. When this counter reaches just over half of the quorum size, the claim is then submitted to history.
We are well on the way to deliver this feature and it will be on the rollups-contracts 2.0 release. Technical discussions and implementation details are on Github on the issues:
Design a contract that implements a Quorum consensus model #48
Optimize Quorum #55
Quorum factory #73
4 Likes
Nice!
I think validation in a Quorum might make sense even after Dave (or any other permissionless fraud proof system) gets implemented, for certain kinds of applications.
It’s a nice balance between security and faster bridging, especially for smaller communities with a list of semi-trusted users. I can see some appchains that require constant bridging with the base layer, for instance, and are on the smaller side of TVL, choosing a quorum of x actors with good reputation to oversee its application. And they can get super quick epoch times in response.
A single authority can also leverage this same feature for security purposes: it can run validators nodes in different architectures/machines and have them agree on the results before making those state hashes “actionable”. Protects against the authority machine being compromised.
It’s, in my view, a good way to advance on the road of decreasing the trust assumptions and decentralizing validation more and more.
2 Likes
I would add that, under a very practical perspective, the most basic value for this feature is to allow developers to ensure liveness for their DApps (also known as “high availability” by some people). If you setup, say, 3 validators for the DApp, then you increase a lot the odds that at least one of them will always be active and keeping the DApp live, despite of eventual system failures like hardware malfunctions.
4 Likes
Beyond different architectures, validators could also run different node implementations, so that a bug in a specific node implementation would be amortized by the quorum majority. This strategy is used by Ethereum, for example.
1 Like
@pedro.argento very interesting proposal and Im aligned with @felipeargento on the validity and relevant of such proposal
Few questions:
1 - For the quorum security layer CTSI will play a role?
2 - Can we imagine this security layer been implemented together with eigenlayer on its dual stacking mechanism? That could give a second level of robustness for the quorum validation specially for applications which larger financial liability. Tagging @carsten.munk here for some thoughts