Quorum and Consensus for AVSes

Types of quorum and consensus mechanisms for flexibly customising different ways of using AVS

Currently, there is a wide range of consensus types tailored for various purposes, ranging from public blockchains to conditionally centralized blockchains with leaders. The challenge arises when a project is launched on a public blockchain network, as the existing consensus mechanisms may not be suitable. This necessitates additional costs to develop proprietary solutions or requires adherence to a common consensus mechanism by connecting with other nodes, as seen in the case of subnetworks.

For instance, in financial applications integrated with web2, a consensus with a leader or extended administrator rights may be necessary. In the case of bridge creation, a closed consensus with 100% agreement or a mandatory threshold of 70-80%, as seen in implementations using Intel SGX with an administrator key and 6-8 nodes, might be required. Con-versely, for initiatives like AVS, aimed at providing infrastructure for DePin, a lower threshold for signatures might be necessary due to the peculiarities of router connections, which could have poor connectivity and significant delays.

Therefore, basing on Cambrian AVS developers can implement various consensus types. Since the validator is expected to operate on a Pos basis, we are considering only Pos-based consensus algorithms to be implemented in the future for different use cases:

• PoH (Proof of History): Implemented in Solana, PoH is one of the primary reasons for Solana's high speed and scalability. It helps reduce node loads when processing blocks. The concept behind PoH is that the order of events is as crucial as the events themselves in a blockchain network, and proving the order of events is necessary to maintain network in-tegrity. PoH utilizes a Verifiable Delay Function (VDF) to generate a timestamp for each block in the blockchain.

• PoA (Proof of Authority): Validators assert their real identities, which are established within the PoA consensus model. Network managers assess the trustworthiness of potential validators, and besides staking, the validator's reputation also plays a role in this scenario. This mechanism is partially centralized due to the involvement of network managers and may be applicable to semi-closed systems where the participation of third-party validators is permissible under certain conditions.

• QBFT: Recommended for enterprise-level consensus protocols for private networks, QBFT involves validators taking turns to create the next block. Before inserting a block into the chain, the vast majority (more than or equal to 2/3) of validators must first sign the block.

• Pol (Proof of Importance): Utilized to determine which network participants (nodes) have the right to add a block to the blockchain. It allows for the assignment of specific conditions for AVS valida-tors, such as: - Stake size and balance in the account. Frequency of interaction of a specific account with other participants in the network. - Quality of connection to the network at a given moment. Such an algorithm may be applicable, for example, to DePin, where different devices may have varying characteristics and connectivity quality depending on their lo-cation.

• PoC (Proof of Capacity): Assumes that miners need to prove they have sufficient storage space for data. It involves generating all possible hashes on the hard drive, and the more hard drive space a miner has, the higher the chance of obtaining the correct hash combination and winning a block reward. This mechanism can be adapted to serve as an analog for DAC (Data Availability Committee) for decentralized confirmation of validators' ability to accept the necessary amount of data for storage. Addition-ally, PoC can be modified as a PoWeights mechanism, which weighs its users based on their available data volume.

• Raft: This consensus algorithm employs a leader and requires a network to have at least 51

• Tangaroa: Combines Byzantine fault tolerance with the security, activity, simplicity, and clarity of Raft. Typically consisting of 3-5 systems in a clus-ter, it allows for the failure of up to 1/2 of the nodes with the concept of "randomization when selecting leadership."

• HotStuff: A Byzantine fault-tolerant mechanism based on leaders. It resembles PBFT but introduces a new stage to solve the hidden block problem.

  HotStuff employs a threshold signature scheme. All nodes do not directly send signed voting messages; instead, they first send their votes to the leader. The leader then aggregates all signatures before publishing them to other nodes. Such aggregation reduces signature verification time.