Finality
... About 4 min
Here you will find detailed information on rationale and design for Finality on the Syscoin L1.
# Finality - Multi-Quorum Chainlocks
Syscoin’s Sentry nodes are validators that run as full nodes. This increases the Nakamoto Coefficient (a measurement of the degree of decentralization of disparate services/nodes). These full nodes do not trust others through consensus, rather they each reproduce their own local state in order to verify the chain. This aligns with our ideals. In contrast, things like sharding or relegating consensus to PoS do not. We are PoW at our foundation and know that in order to preserve long-term decentralized contracts with the world we must tie the computational integrity of the ledger to the tangibility of a race for physical energy extraction. Understanding that, the right questions right now are how does Syscoin’s finality work in a decentralized way, and how does it not relegate consensus into a system that is effectively PoS?
You can see above that every fifth block gets “locked”. This is accomplished by the following. Four quorums are formed, each consisting of 400 randomly selected Sentry nodes (1,600 total). Sentry nodes are deterministically assigned to quorums and the quorums are periodically reordered. Sentry nodes cannot change the order of when/where they are put into quorums. These quorums form BLS signatures to sign a vote on the state of the blockchain every fifth block. Basically, they vote whether they see the same block at the same height. When at least three out of four of the quorums agree, this is aggregated into one final BLS signature. The rest of the network sees the final signature and validates that the quorums are in agreement. The validators inside each quorum get from others only the information they need in order to create the BLS signature. This has been proven on our live mainnet for over a year to be a wonderful way to efficiently vote on the state of the chain.
# Security
Say a super-majority (> 66%) of Sentry nodes collude to censor the blockchain. Technically, if one were to attack in this way, they would likely vote to lower the difficulty so much that it would be easy to mine the chain on a standard CPU, then censor as needed (pick and choose which transactions to allow into blocks and prevent all others). Syscoin’s resistance to this attack resides in the fact that the Syscoin network votes only on the fifth block back from the tip. It is almost impossible to selfishly mine in advance yet have control over the fifth. One would need to dominate both Bitcoin’s miners that are merge-mining Syscoin AND control a supermajority of Syscoin Sentries. In effect we have increased our security from miner (PoW alone) to miner (PoW) + validator (PoS), and as it seems, without drawbacks.
Now let’s analyze the next attack - a halting scenario. Let’s say attackers purchase Sentries en masse or otherwise gain control of a super-majority (> 66%). Like all Sentry nodes, the way they vote for the chain begins by receiving a block header and checking its PoW. If it’s valid, they will vote on the block without waiting for its contents. This is for performance reasons - otherwise, blocks with a large data footprint would result in longer turn-around-times to achieve finality, every node being required to have the complete block. However, checking just the header presents a problem. What if the block was purposely created incorrectly? IE: a chain of five blocks selfishly mined with valid block headers but invalid content (say a double-spend transaction). If the Sentry nodes voted for this specific chain and its fifth block to be locked, then every node would have to switch to this invalid chain, effectively halting the chain. To solve this scenario, the protocol enables rolling back to the previous chainlock, but no deeper. The previous chainlock is proven valid by the fact it has been built on and processed by nodes, thus the scenario of two invalid chainlocks in a row is ruled-out. When a new chainlock forms, the previous chainlock must be valid and part of a fully valid chain (not just headers). Therefore, the network can always roll back to the previous known good state in this attack scenario.
Let’s recap the two attack vectors with detailed examples. To avoid our system effectively becoming PoS, we tied chainlocking to every fifth block, buried five blocks. IE: block 1004 is mined (no chainlock), 1005 is mined (1000 is chainlocked), and miners cannot roll back deeper than that even if mining selfishly. In the second vector the Sentry nodes collude to try to accept a selfishly mined block as the chain tip to effectively halt the network. Example: they selfishly mine block 1000 with valid header but with invalid block contents, then mine blocks 1001 though 1005 as normal and propagate the headers to Sentry nodes. Sentries vote and agree, locking block 1000 across the entire network. From here nodes will never process a new block because block 1000 is actually invalid. To solve, the offensive chainlock is removed and the previous chainlock is set as the latest valid one. Meaning blocks can technically rollback to 995 but not any deeper. We know block 995 is valid because when forming the chainlock at block 1000 the network ensures the previous chainlock exists and is a valid chain at 995. Therefore, since it is the last valid chainlock state, we can roll back to it safely and proceed to create a valid chain from that point forward. Having designed to solve these attack vectors we retain the antifragility of relying on PoW (of Bitcoin’s network no less) for the ultimate source of truth while enabling finality via PoS of Sentry nodes agreeing on the chain tip every 5th block which practically eliminates selfish-mining concerns. This finality connects directly to BitcoinDA and its pruning.
# PoS and PoW
In a pure PoS system it is critically important that faults do not occur. This means a PoS system has to be perfect in order to prevent people from gaining the ability to decide the fate of the system, censor/stop/halt, or spam the chain as they see fit. Once a PoS system is compromised, it cannot recover. On the other hand, a PoW system relies on the antifragile longest chain rule. One can selfishly mine but that work gets thrown away once overpowered by peers, or one keeps paying very high premiums with little to no return for doing so. It is antifragile in part because it recovers without external help. Syscoin Sentry nodes effectively run a staking model that has access to locking the chain, so they do have some power in our system, but ultimately the miners decide how the chain progresses, so we retain antifragility. Since Sentries have this power, proper design is required to rule-out creating scenarios where our system could run into a brick wall. Even if the chance of that happening is very remote, we do not want a layer 1 system that relegates down to depending purely on PoS alone.