The Stellar Consensus Protocol (SCP) is a consensus mechanism that uses Federated Byzantine Agreement (FBA). Unlike traditional BFT which requires a fixed threshold (like 2/3), SCP allows each node to define its own quorum slice - a set of nodes it trusts. This creates flexible trust relationships and makes the network more adaptable.
In traditional BFT:
- All nodes must agree on the same threshold (e.g., 2/3)
- Network size is fixed
- Trust relationships are symmetric
In SCP:
- Each node defines its own quorum slice
- Network can grow organically
- Trust relationships can be asymmetric (Node A trusts B, but B might not trust A)
A quorum slice is a set of nodes that a particular node trusts. Each node defines its own quorum slice. For consensus to be reached, enough nodes in each quorum slice must agree.
Example:
- Node A's quorum slice: {A, B, C}
- Node B's quorum slice: {B, C, D}
- Node C's quorum slice: {C, A, D}
A quorum is a set of nodes that includes a quorum slice for each of its members. This ensures that every node in the quorum can reach consensus.
For safety, quorums must intersect. This prevents conflicting decisions.
SCP uses a two-phase process:
A node nominates a block for consideration:
🔄 SCP-Node-6001 NOMINATING NEW BLOCK (SCP Nomination Phase):
Data: "My first transaction"
Nodes vote on the nominated block. Consensus is reached when a quorum is formed:
🗳️ BALLOT PHASE:
Voted: ACCEPT for block 00a7f3d2e1b5c8f9...
Current votes: 2/2 (need majority of quorum slice)
In this educational implementation, we simplify SCP:
- Each node's quorum slice includes all connected nodes + itself
- Consensus requires a majority (50%) of the quorum slice
- Real SCP has more complex quorum intersection rules
| Feature | BFT | SCP |
|---|---|---|
| Threshold | Fixed 2/3 of all nodes | Flexible (based on quorum slices) |
| Trust | Symmetric (all nodes equal) | Asymmetric (each node defines trust) |
| Network Growth | Requires reconfiguration | Can grow organically |
| Quorum | Fixed set | Dynamic based on slices |
| Safety | 2/3 threshold | Quorum intersection |
A node nominates a new block:
🔄 SCP-Node-6001 NOMINATING NEW BLOCK (SCP Nomination Phase):
Data: "My first transaction"
The block is mined (same as BFT):
⛏️ MINING PHASE:
🔨 Mining block 1...
📊 Target: Hash must start with 00
✅ Block mined! Nonce: 23847, Hash: 00a7f3d2e1b5c8f9...
The nomination is broadcast to peers:
📡 NOMINATION PHASE:
Nomination broadcast to 2 peers
Waiting for quorum slice to accept nomination...
Nodes vote (ballot) on the nomination:
📨 NOMINATION RECEIVED:
From: SCP-Node-6002
Block: 00a7f3d2e1b5c8f9...
🗳️ BALLOT PHASE:
Voted: ACCEPT for block 00a7f3d2e1b5c8f9...
Current votes: 1/2 (need majority of quorum slice)
When enough votes are collected:
🗳️ BALLOT RECEIVED:
From: SCP-Node-6003
Vote: ACCEPT
Current votes: 2/2
🎉 QUORUM REACHED! (SCP Consensus):
Block 1 has been accepted by the network!
Final votes: 2 out of 3 quorum slice nodes
- Each node defines who it trusts
- No need for global agreement on trust
- Network can grow without reconfiguration
- Node A can trust Node B, but B might not trust A
- More realistic trust model
- Reflects real-world relationships
- New nodes can join by being trusted by existing nodes
- No need to reconfigure the entire network
- Scales better than fixed-threshold BFT
- Safety comes from quorum intersection
- More flexible than fixed thresholds
- Can handle heterogeneous networks
Watch quorum slices form:
- See which nodes each node trusts
- Observe how quorums are built
- Understand quorum intersection
Experience the two-phase process:
- Nomination: Proposing a block
- Ballot: Voting on nominations
- See how consensus emerges
Experiment with different trust configurations:
- Connect nodes in different patterns
- Observe how quorum slices change
- See how consensus adapts
Run the same scenario with both protocols:
- Notice the different thresholds
- See how SCP is more flexible
- Understand when to use each
- Start 3 nodes (ports 6001, 6002, 6003)
- Connect them: 6002 → 6001, 6003 → 6001
- Check
statuson each node - Observe: Each node's quorum slice includes connected nodes
- Notice: Quorum slices can be different for each node
- Start multiple nodes and connect them
- Propose a block (creates nomination)
- Watch other nodes receive the nomination
- See them create ballots (votes)
- Observe when quorum is reached
- Start 4 nodes
- Connect them in a star pattern (all to one central node)
- Propose a block
- Notice: Consensus requires majority of each quorum slice
- Compare: This is different from BFT's fixed 2/3
- Start with 2 nodes
- Add a third node
- Observe how quorum slices update
- See how the network adapts without reconfiguration
- Compare: BFT would need threshold recalculation
// Simplified: quorum slice = self + all connected peers
this.quorumSlice = new Set([this.nodeId]);
// When peer connects
this.quorumSlice.add(`SCP-Node-${peerPort}`);// Receive nomination
handleNomination(message) {
// Validate block
// Create ballot (vote)
voteOnBlock(blockHash, 'ACCEPT');
}// Simplified: need majority of quorum slice
const requiredVotes = Math.ceil(this.quorumSlice.size * 0.5);
return ballot.votes.size >= requiredVotes;- NOMINATION: A node nominates a block
- BALLOT: A node votes on a nomination
The Stellar blockchain uses SCP:
- Validators: Nodes that participate in consensus
- Quorum Sets: Each validator defines its quorum set
- Safety: Quorum intersection ensures safety
- Liveness: Progress when honest validators can form quorums
- Decentralization: No single point of control
- Flexibility: Validators choose who to trust
- Performance: Fast consensus (3-5 seconds)
- Low Energy: No proof-of-work required
- Fixed network size
- All nodes are known and trusted equally
- Need simple, predictable threshold
- Permissioned networks
- Dynamic network growth
- Asymmetric trust relationships
- Need flexible trust model
- Public or permissionless networks
- Heterogeneous node capabilities
- Quorum Slice Design: Design quorum slices for a 5-node network
- Quorum Intersection: Verify that quorums intersect for safety
- Network Growth: Simulate adding nodes and observe quorum changes
- Trust Analysis: Compare symmetric vs asymmetric trust
- Consensus Time: Measure consensus time vs network size
- Failure Tolerance: Test how many nodes can fail in different configurations
For safety, any two quorums must intersect. This ensures:
- No two quorums can make conflicting decisions
- At least one honest node is in the intersection
- Safety is maintained
SCP uses federated voting where:
- Nodes vote based on their quorum slices
- Votes are weighted by trust relationships
- Consensus emerges from quorum formation
- Safety: Quorum intersection prevents conflicts
- Liveness: Progress when honest nodes can form quorums
- Trade-off: More flexible trust = more complex safety analysis
- Stellar Consensus Protocol Whitepaper
- SCP Developer Guide
- Federated Byzantine Agreement
- Quorum Intersection
- SCP uses flexible trust - Each node defines its quorum slice
- Two-phase process - Nomination then Ballot
- Quorum-based consensus - Consensus requires quorum formation
- More flexible than BFT - Can handle asymmetric trust
- Real-world application - Used by Stellar blockchain
Ready to try SCP? Run node index.js and select option 2 for Stellar Consensus Protocol!