One of the most important protocols for conducting state machine replication are consensus protocols; typically carried out across a network of erratic machines. Consensus protocols are multifaceted, ranging from public, global, decentralized platforms to private business backends. Commonly, this networks have high transactional throughput demands but adapting and expanding current consensus protocol to solve this problem of scalability has proved quite a task.
Notwithstanding, the blockchain industry today is not only rapidly evolving but adapting to new developments which provide sustainable solutions to problems of scalability, permissions and many others. Cerberus is one of such new developments. Under the banner of Radix, Cerberus is a decentralized ledger technology designed for large scale decentralized public networks and all its different deployments. This Radix application is a sharded BFT (Byzantine Fault Tolerant) answer to the problem of SMR (State Machine Replication).
With SMR, commands can be issued on a global stage. The difference between State Machine Replications and Cerberus is that the latter brings in a rather unique state sharding approach by bringing in a partial ordering regime.
Cerberus’ methods allows consensus process for commands to be securely parallelized on a wide level. This action spans multiple modes and still manages to easily retain linear message complexity and optimistic responsiveness.
Here is a simplified explanation of how Cerberus works.
In the blockchain, consensus protocols are required to arrive at an agreement on the ordering of commands such as events, transactions etc. these consensus protocols are stored in one timeline in chronological order. These operation is called global ordering or parallelism.
Pulling off the consensus protocol for multiple commands results in limitation of achievable throughput and high communication overhead. Using state sharding, throughput can be increased if this sharding technique permits the splicing or separation of unrelated commands. This allows safe processing in parallel.
However, this approach contradicts the single timeline denoted by a global ordering requirement; putting a wrinkle in an otherwise flawless operation. How does Cerberus counter this inadequacy? By using a series of timelines which solely ensure the ordering of related events. The application employs a combined approach to application layers as well as consensus.
These two factors must run without global ordering in this case in order to create the likelihood of safe parallelism of consensus. This method creates an opportunity for safe global ordering using state sharding technique. This in turn eliminates limitations to throughput.
Why Cerberus?
If global ordering must be eliminated in the application layer, it must be replaced with a suitable alternative. With Radix, an application layer that breaks the functionality of DLT by components can be seen in the design of Radix Engine.
With Radix Engine makes room for specificity of transactional functionality with asset orientation in mind. Everyday transactions in the blockchain require essential elements such as property, money, products, identities. These elements are in turn exhibited as singular, functional components and not smart contracts.
Where Cerberus comes in is that it receives the shardable language of translated components by the Radix Engine into finite state machines. Both applications work together to express and receive transactions as a command that consists of collected state machine updates coupled with precise, explicit dependencies.
The way Cerberus is designed, it has the capacity to maximize the advantage of highly granular partial ordering that enables parallelism of consensus on a large scale with the permission of the application layer interaction explained above.
Cerberus is an exceptional application that builds on BFT-model consensus without losing the central propertied of BFT; liveness and safety under asynchrony, consistency over availability.
FEATURES OF CERBERUS
Scalability
The subject of scalability in Cerberus is an oft-discussed one, with many questions as regards the scalability limitations of Cerberus. This Radix application has no theoretical limitation to how much independent transactions it is able to process. It’s safe to say Cerberus scales linearly.
Safety
Cerberus’ safety protocol is guaranteed by its Byzantine Fault-Tolerant. By using multi-phase commits, Cerberus possesses not just safety but liveness. The fprmer guarantees safety while the latter guarantees positive outcomes.
3-phase commit
3-phase commits in Cerberus opens way for a consensus process that are easy to predict and resilient. Cerberus’ design utilizes its parallelism in order to fully use the 3-phase commit while still maintaining overall throughput of the network.
Nodes
With Cerberus, nodes are permitted to participate with virtually anything from Raspberry Pi to full server down. These node runners will serve as much shard space as possible with whatever bandwidth, storage and processor that is available.
What happens when the network goes down?
Under such circumstance, nodes are known to to rejoin by resynchronizing the transactions that were processed during disconnection. On the other hand, if 1/3 of nodes are disconnected, transactions cannot be processed while nodes remain disconnected from a big chunk of the network.
There’s more. If more than 1/3 of nodes disconnext, this will result in 1/3 of nodes serving shard for that shard. Under Radix, only a restricted number of node runners will be released on the network in order to have more server-like requirements that will keep the network performant through processor and bandwidth.
Generally, disruptions do not have any effect on transactions and their security, but they must be avoided through:
- Validator selection
- Node mapping
- Sybil protection
Adaptability
The adaptability of Cerberus can be seen in the way it responds when a shard goes rogue. It reemploys the Virtual Quorum Certificate routine in order to address the problem of a rogue shard.
State Machine Replication
Like many other technologies, Cerberus also operates with the State Machine Replication technique for organizing client engagements with server replicas after replicating servers. Typically, State Machine Replication are used to replicate the state of their ledger across their network of nodes.
In conclusion, what makes Cerberus so vital is its ability to take regular single-pipe consensus processes and parallelizes such consensuses across a large amount of shards. The unique ability to carry out this parallelization using a braided synchronization of consensus when required by every transaction.
