BlockFin: Proof-of-Stake Protocol with Security that Rivals Proof-of-Work

^{The Proof-of-Work (PoW) algorithm was the first consensus protocol to power public blockchains. As a result, proponents of PoW-based blockchains claim they are more secure than Proof-of-Stake-based (PoS) blockchains. BlockFin, Storecoin’s PoS consensus algorithm, provides security that rivals traditional PoW blockchains.}

Introduction

Security is the most important attribute of any public blockchain. Central to a blockchain’s security protocol is its consensus algorithm, because it can be a known security vulnerability as well as the first line of defense in an attack. Because PoW is the oldest and best understood consensus algorithm, proponents of PoW have argued that PoS-based blockchains are less secure.

Hugo Nguyen, a developer for the Litecoin blockchain, a network using a PoW consensus protocol, writes in part 1 of a two-part blog post that securing against worst-case scenarios is “an absolute must when dealing with critical systems,” whether they are responsible for operating an airplane, spaceship, nuclear power plant or cryptocurrency network.

Nguyen argues that the better-known and tested PoW-based blockchain has built a reputation for resiliency that PoW-based blockchains do not have.

‍

At STORE, we believe that just because no PoS consensus algorithm has proven itself comparable (or superior) to PoW doesn’t mean it can’t happen.

‍

BlockFin, STORE’s PoS consensus algorithm, has comparable security characteristics to a PoW-based blockchain. In this post, we explain how BlockFin running a PoS consensus algorithm addresses the types of worst-case scenarios and attacks introduced in Nguyen’s post.

PoS vs. PoW

PoS is a category of consensus algorithms for public blockchains that depends on a validator’s economic stake in the network. With public blockchains using PoW consensus, the algorithm rewards participants that solve complex cryptographic puzzles to validate transactions and create new blocks. In contrast, in PoS-based blockchains, a set of validators propose and vote on the next block as defined in the underlying protocol.

Nguyen argues in part 1 of his post that PoS-based systems are less resilient in dealing with worst-case scenarios. He concludes:

1. PoW protects the future: When there’s a chain split, it gives an objective mechanism, automatable way of resolving conflicts, without requiring manual human intervention or trusted third parties.
2. PoW protects the past: Getting control of majority hash rate still costs an attacker an enormous amount of time and money to rewrite history, so the balances are somewhat safe.

In part 2 of the post, the author describes a property he argues is unique to PoW: resiliency to old private key attacks. We believe such characteristics apply to networks running PoS consensus algorithms as well.

BlockFin Summary

BlockFin subscribes to the ‘correct by design’ philosophy. It sacrifices throughput and in some catastrophic events, liveness, to guarantee correctness.The STORE blockchain, under no circumstances, will be in a indeterministic state.

Throughput is defined here as the number of transactions processed by a blockchain network per second. Liveness refers to a set of properties of concurrent systems that requires a system to make progress despite the fact that it is currently executing components or processes that may have to “take turns” in critical sections, A liveness guarantee is an important property in distributed systems.

BlockFin is STORE’s PoS BFT consensus protocol. It differs from other PoS protocols in the following ways:

• Leaderless consensus — Consensus is not leader or delegation-led. All validators are required to participate in the consensus process and approve transactions in blocks using a pipelined, multi-stage validation workflow.
• Fork tolerance — The protocol permits chain forks natively with a strong guarantee to disallow double-spend attacks. This permits parallel block creation without requiring sharding and other complex approaches, thus dramatically improving consensus throughput.
• Shared state machine replication — Fork-tolerance is achieved through a collaborative block assembly process whereby all (online) validators come together to build and validate new blocks using shared state machine replication. This is in contrast to the “create the block in the local node privately and publish it to the blockchain” approach in both PoW- and PoS-based blockchains.
• Community-based reward sharing — All validators earn rewards proportional to their stakes for the blocks they produce. This is in contrast to other PoS protocols where the leader/delegates earn all the rewards. We believe that economics leading to competition leads to centralization, encouraging malicious behaviors
• True decentralization — Since all validators participate in consensus for all blocks, the network is truly decentralized. The sharing of rewards community-wide discussed earlier encourages maximum up-time and participation. A network with a large number of online participants resists worst-case scenarios and attacks better than a network with fewer large participants.
• Dynamic threat levels — BlockFin incorporates a dynamic threat-level system that identifies the type of attack (spam, DDoS, private key hijacking, etc.) and responds accordingly, at the protocol level.

Worst-case scenarios and attacks

In this sections, we describe how BlockFin addresses each of the worst-case scenarios and attacks described in Nguyen’s blog post.

Scenario 1: The entire network is forced offline for some period, then rebooted.

In this scenario, the entire network is forced offline as happened during the Arab Spring movement, when the Turkish government successfully performed BGP hijacking to block Twitter traffic from Turkish citizens. Nodes come back online at different times based on their recovery rate. In this scenario, the question is with PoS, will the nodes automatically self-organize, eventually gravitating towards one single chain, the longest chain, and the most secure, or some other chain”

BlockFin’s shared state machine replication allows for nodes to self-organize, eventually gravitating toward a single chain. When nodes come back online at different times, they start receiving transactions immediately but will not start building blocks until at least one node is part of the shared state machine.

As nodes from the shared state machine group come online, they sync with existing nodes, replicating the block data among them. The following behaviors can be observed.

1. The validator nodes never produce private chains — they only produce blocks on the main blockchain. If all the nodes forming the shared state machine are forced offline, no blocks will be created. In this catastrophic situation, liveness is sacrificed for correctness.
2. The transaction approval throughput initially will be low after being forced offline. As more nodes come online, throughput improves.
3. The nodes don’t misbehave (except for Byzantine behavior, which the protocol is designed to handle) and never create a subchain that requires repair.

What happens in the event that all the nodes forming a shared state machine are forced offline and come back online at different times? As the nodes come back online, how they self-organize and eventually gravitate toward one single chain depends on which node came online first and started producing new blocks.

In a PoW consensus protocol, some transactions may be lost if they are added to a shorter chain. Additionally, as nodes come back online, those transactions that were approved and added to a chain while the node in question was offline, may also be lost. While nodes will eventually gravitate toward one single chain, PoW offers no guarantee that previously approved transactions will remain so after being forced offline. This is because a peer-to-peer network is eventually consistent.

We can draw parallels between the behaviors between the shared state machine nodes and PoW nodes. Depending on which of the shared state machine nodes come online first, the block validation process continues accordingly. Regardless of which nodes come online first, the results are the same. The network will still gravitate toward one single chain.

Scenario 2: Some portions of the network are partitioned from the main network.

This is a special case of scenario 1 where certain nodes are partitioned from the main network. In this case, if the partitioned network doesn’t contain any nodes from the shared state machine group, the network doesn’t participate in the block assembly and validation process.

At some point, the nodes in the partitioned BlockFin network start rejecting incoming transactions, since they cannot process them anymore. For the larger network this looks like a Byzantine fault. If the partitioned network is large enough (greater than ⅓ of total nodes), the block assembly and validation process will halt momentarily triggering dynamic threat-level logic, rebalancing the BlockFin network by excluding the nodes in the partitioned network. After rebalancing, the block assembly and validation process continues unabated.

It should be observed that subchains are not created and the main blockchain is in no way affected. As the partitioned BlockFin network stabilizes (nodes from shared state machine group are up and synchronized to their peers, etc.) they rejoin the larger network and the block assembly and validation process is restored to its original capacity.

Scenario 3: “PoS fares worse in other worst-case scenarios, such as stolen private keys.”

Nguyen makes the claim that PoS fares poorly when attackers gain access to the private keys of old validator nodes, using them to get sufficient majority to perform malicious acts.

BlockFin, a PoS blockchain will respond in the following ways:

1. The block validation process in BlockFin involves a sealing phase, creating checkpoints of committed blocks. The sealing process is decentralized, because validators will seal and sign the blocks, just like in the block validation process. All write operations on the sealed block are rejected. A malicious node cannot override this behavior because of the shared state machine replication used in BlockFin. All the nodes in the shared state machine group must be compromised to mount such an attack. As a result, long-range attacks like a history rewrite attack and other similar types of attacks are not feasible in BlockFin. Additionally, any attempt to write to the sealed blocks will be noticed by honest validators who will initiate protocol-defined punitive measures such as slashing.
2. All validators must meet KYC/AML (know-your-customer/anti-money-laundering) and minimum staking requirements in BlockFin. Once a validator decides to retire or move out of the network, their private keys are no longer useful in the block assembly and validation process. If a malicious node uses stolen private keys to sign the blocks, it will be noticed by other honest validators since the private keys are not longer showing as valid within the network.

To summarize:

• BlockFin protects the future: Catastrophic events such as being forced offline will not result in chain forks because by design, BlockFin is fork-tolerant. Throughput may suffer for the duration of the catastrophic event, but the blockchain will gravitate towards a steady state. In attacks such as the one where malicious actors obtain retired private keys, the attack will not succeed because the network will recognize that the keys trying to be used by the malicious actor have previously, been retired.
• BlockFin protects the past: Getting control of the majority of nodes by buying or stealing old private keys will not work in BlockFin because sealed blocks cannot be modified. Additionally, the status of retired or stolen private keys will be immediately recognized by the network and shut down.

Scenario 4: New and long dormant nodes

In the fourth scenario, a new node joins the network or a node that was previously offline for a long time comes back online. The question becomes who this node should trust. In BlockFin, the answer is straightforward. Since the validator nodes use shared state machine replication, the new or long dormant node simply needs to connect to one of the nodes in the shared state machine group to get up and running instantly. The new or dormant node needs to trust the network itself and not individual nodes.

Scenario 5: Current private key attack

In the fifth scenario, the private keys of more than ⅓ nodes are compromised. In other words, a Byzantine fault occurred resulting in a stalled network. BlockFin’s dynamic threat detection reconfigures the blockchain by excluding the affected validators from the block assembly and validation process, ensuring liveliness. The network recognizes the stolen private keys as the result of an offline governance process.

Conclusion

Security is a critical ingredient for any blockchain project. BlockFin’s ‘correct by design’ philosophy enables it to address some of the shortcomings found on public blockchains running traditional proof-of-stake consensus algorithms.