Quorum

Quorum's primary privacy feature is enabled by Constellation, a system for private transactions and private contracts. It uses Tessera, a transaction manager, to encrypt and store payloads off-chain, sharing them only with designated participants. This allows for:

• Private State: A subset of nodes can maintain a private state not visible to the entire network.
• Public/Private Separation: The public blockchain only stores hashes of private transactions, ensuring data confidentiality while maintaining auditability for participants.

Quorum replaces Ethereum's Proof-of-Work with faster, deterministic consensus algorithms suitable for permissioned networks.

• Raft: A Crash Fault Tolerant (CFT) protocol where a single leader is elected to propose blocks, offering high throughput and predictable finality.
• Istanbul BFT: A Byzantine Fault Tolerant (BFT) protocol based on Practical Byzantine Fault Tolerance (PBFT). It requires a two-thirds majority of validators to agree on a block, providing resilience against malicious nodes. This is the default for networks requiring stronger security guarantees.

Quorum operates as a permissioned blockchain, meaning participation is controlled. This is enforced through:

• Node Permissioning: A smart contract or configuration file (e.g., permissioned-nodes.json) defines the list of allowed nodes, preventing unauthorized peers from joining the network.
• Smart Contract Permissioning: Access to specific smart contract functions can be restricted to authorized participants, aligning with enterprise governance and compliance requirements.

By removing the energy-intensive mining process and operating in a trusted environment, Quorum achieves significantly higher performance than public Ethereum.

• Higher Transaction Per Second (TPS): Consensus mechanisms like Raft enable faster block creation and finality.
• Reduced Latency: Block times are predictable (e.g., sub-second for Raft).
• EVM Compatibility: It maintains full compatibility with the Ethereum Virtual Machine (EVM), allowing developers to use familiar tools like Solidity and Truffle.

Quorum's architecture is tailored for specific enterprise consortiums.

• Financial Services: Used by consortia like J.P. Morgan's JPM Coin System and the Bankchain initiative for interbank settlements, private securities transactions, and Know Your Customer (KYC) processes.
• Supply Chain Management: Enables multiple organizations (manufacturers, shippers, retailers) to share private data (invoices, shipment status) on a common ledger while keeping sensitive commercial terms confidential.

When a vote fails to meet quorum, the proposal is typically defeated. However, some DAOs have mechanisms like proposal recycling or quorum extension. This allows proposers to resubmit a failed idea, sometimes with a lower quorum requirement, if it achieved a high approval rate from those who did vote. This addresses the common challenge of voter apathy and ensures good ideas aren't lost solely due to low turnout.

A quorum is the minimum threshold of participation required to legitimize a governance action, such as passing a proposal or upgrading a protocol. It prevents a small, potentially malicious minority from making unilateral changes and ensures decisions have broad support.

• Purpose: Establishes legitimacy and security for on-chain decisions.
• Typical Forms: Can be a minimum number of tokens voted, a percentage of total supply, or a count of unique addresses.

These are distinct but related governance parameters that work together.

• Quorum: The minimum total participation needed for the vote to be valid. If quorum isn't met, the proposal fails regardless of yes/no votes.
• Approval Threshold: The percentage of cast votes (e.g., 51% for simple majority, 67% for supermajority) required for the proposal to pass.

A proposal must first achieve quorum, then meet the approval threshold to succeed.

Improperly set quorum parameters can create critical vulnerabilities.

• Quorum Failure: If set too high, legitimate proposals may never pass, causing governance paralysis.
• Low Quorum Capture: If set too low, a well-funded attacker could pass malicious proposals with minimal participation during periods of voter apathy.
• Snapshot Timing: Attackers may exploit the precise block used for the snapshot of token holdings to manipulate quorum calculations.

Different blockchains and DAOs implement quorum in various ways to balance security with participation.

• Fixed Percentage: A set % of the total token supply (e.g., 4% of $UNI required for Uniswap governance).
• Adaptive Quorum: Adjusts based on voter turnout in previous proposals to combat apathy.
• Token-Weighted: Quorum is calculated based on the number of tokens staked or delegated, not unique addresses.
• Multisig Quorum: In a multisignature wallet, it's the minimum number of private key signatures required (e.g., 5-of-9).

Understanding quorum requires familiarity with adjacent governance mechanisms.

• Snapshot: The recorded state (e.g., token balances) at a specific block used to determine voting power and quorum calculation.
• Delegation: Token holders can delegate voting power to representatives, which centralizes influence and affects quorum dynamics.
• Time Lock: A mandatory delay between a proposal's passage and its execution, providing a final safety check even if quorum was met.
• Vote Escrow: Models like veTokenomics (e.g., Curve Finance) tie voting power to locked tokens, directly influencing quorum participation.

A property of a distributed system that allows it to reach consensus and continue operating correctly even if some of its components (nodes) fail or act maliciously (Byzantine faults). Quorum-based protocols like Practical BFT (PBFT) are designed to be BFT, ensuring network security and liveness.

• Thresholds: A BFT system typically requires a super-majority (e.g., 2/3) of honest nodes to tolerate faulty ones.
• Contrast: Non-BFT systems may only handle simple crashes, not malicious behavior.

A consensus mechanism where validators are chosen to propose and validate new blocks based on the amount of cryptocurrency they stake as collateral. Quorum is achieved through voting weighted by stake.

• Finality: Many PoS blockchains use Casper FFG or similar protocols for finality, where a super-majority of validators votes to lock in a block.
• Quorum Slashing: Validators can lose their stake for actions that violate the protocol's consensus rules.

The specific group of nodes authorized to participate in a blockchain's consensus process. The quorum size is calculated from this set.

• Permissioned vs. Permissionless: In permissioned networks, the set is known and fixed. In permissionless networks (e.g., Ethereum), the set is dynamic and based on staking.
• Weighted Voting: In some systems, validators may have different voting power, affecting the quorum calculation.

The irreversible confirmation that a transaction or block is permanently settled and cannot be altered or reverted. Achieving finality often requires a successful quorum of validator votes.

• Probabilistic vs. Absolute: Proof of Work offers probabilistic finality (confidence increases with blocks). Proof of Stake with BFT aims for absolute finality after a quorum is reached.
• Finality Gadgets: Protocols like Casper are layered on top of consensus to provide finality guarantees.

A formal suggestion for a change to a blockchain's protocol, parameters, or treasury, which is voted on by stakeholders. Passing a proposal requires achieving a quorum of votes, often defined as a minimum percentage of total voting power participating.

• Quorum Requirements: A proposal may fail if voter turnout is below the quorum threshold, regardless of the yes/no ratio.
• Execution: Once a quorum is met and the vote passes, the change is automatically executed via on-chain governance.

The fundamental computer science problem that blockchain consensus solves: ensuring all honest nodes in a distributed system agree on and apply the same sequence of inputs (transactions) to replicate an identical state. A quorum is used to agree on each step in the sequence.

• Core Challenge: Maintaining consistency and liveness across all nodes despite faults.
• Blockchain as SMR: Each block represents a state transition, agreed upon by a quorum of validators.