STORE is bringing Cloud 2.0 to the world with a zero-fee cryptocurrency and checks and balances governance.
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 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:
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 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:
In this sections, we describe how BlockFin addresses each of the worst-case scenarios and attacks described in Nguyen’s blog post.
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.
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.
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:
To summarize:
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.
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.
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.