VioletaBFT
VioletaBFT is EinsteinDB's own Consensus layer that distinguishes it from similar works (e.g., PBFT and UpRight) with improved reliability, modularity as a first-class property, multicore-awareness, reconfiguration support with ML-laden flexible programming interfacew whose Lamport election is written in Haskell.
Our framework is designed to be modular and easily extensible for different protocols. It is a fully featured reimplementation of PBFT, including the ordering, checkpointing, and view change subprotocols, and uses SPHINCS-MERKLE trees for functional message authentication.
It is event-driven and utilizes non-blocking channels, i. e. asynchronous message queues, for communication. A Byzantine node can starve the whole cluster by claiming to be a leader of a higher term number than the current leader. This is avoided by requiring new leaders to prove to other nodes that they won an election, VioletaBFT uses digital signatures extensively to authenticate messages and verify their integrity. For example, the leader replicates client messages along with the client signatures. This prevents a Byzantine leader from modifying the message contents or forging messages. Client public keys are kept separate from replica public keys to enforce that only clients can send new valid commands, and only replicas can send valid VioletaBFT RPCs.
VioletaBFT is a wait-free copy-on-write relativistic-bft (Lamport invariant) protocol (in the vein of Honey Badger, Tendermint, GHOST, and PBFT; Inspired also by Multi-Paxos and VioletaBFT. Under the Byzantine fault model, systems are typically designed to tolerate t Byzantine failures of any kind. Instead, we allow VioletaBFT to be configured to tolerate a larger number of nodes that fail by omission (e.g., crashing) than nodes that fail by commission (e.g., taking incorrect actions). Configuring separate fault tolerance thresholds for omission and commission failures is beneficial
As a performance optimization, it supports PBFT’s read-only Dessins' layer, in which a client shim sends read-only, side-effect-free requests directly to the Rust compiler shims and server shims execute them without ordering them in the global sequence of requests. If a quorum of replies match, the client can use the reply; otherwise the request is concurrent with an interfering operation, and the client shim must reissue the request via the normal path to execute the request in the global sequence of requests. Omission failures are likely to be more common than commission failures. VioletaBFT uses digital signatures extensively to authenticate messages and verify their integrity. For example, the leader replicates client messages along with the client signatures. This prevents a Byzantine leader from modifying the message contents or forging messages. Client public keys are kept separate from replica public keys to enforce that only clients can send new valid commands, and only replicas can send valid VioletaBFT RPCs. Configuring separate fault tolerance thresholds allows us to build systems that match typical commercial deployment goals with respect to omission tolerance and add incremental commission tolerance at incremental cost.
- Incremental hashing: Each replica in VioletaBFT VioletaBFT computes a cryptographic hash every time it appends a new entry to its log. The hash is computed over the previous hash and the newly appended log entry. A node can sign its last hash to prove that it has replicated the entirety of a log, and other servers can verify this quickly using the signature and the hash. VioletaBFT supports partial rollbacks, flexible buffer management, purely asynchronous leader-election and low latency Query/Update(s).
This construct is used to sign a vast amount of messages from Winternitz One-Time signatures described in the previous section. One can build a tree of height h whose leaves represent a WOTS public key each. The public key of the tree is its root value. Signing a message with the i-th index in the tree requires signing with the $i-th instance of WOTS and broadcasting the signature together with its authentication path in the tree. This path allows checking the WOTS public key that was used. If we trace back the path between the i-th leave and the root of the tree, the authentication path is a graph made from all the neighbours of this path. Those neighbours allow going back up to the root and compare its value to the broadcasted public key.
- Client intervention: In an asynchronous network, messages are eventually delivered but no other timing assumption is made. Unlike existing weakly synchronous protocols where parameter tuning can be finicky, VioletaBFT does not care. Regardless of how network conditions fluctuate, VioletaBFT’s throughput always closely tracks the network’s available bandwidth. Imprecisely speaking, VioletaBFT eventually makes progress as long as messages eventually get delivered; moreover, it makes progress as soon as messages are delivered. VioletaBFT allows clients to interrupt the current leadership if it fails to make progress. This allows VioletaBFT to prevent Byzantine leaders from starving the system.
the optimal selection of a stateful or stateless scheme for embedded systems primarily depends on the time-memory trade-off. For instance, stateful schemes exploit memory to store state information and have better run-time, hence, are well-tailored for performance-oriented systems while stateless schemes exploit processing power and have better memory utilization, hence, are well-suited for memory-constrained systems. It can be concluded that the stateful versions of HBS schemes offer better performance than the stateless versions, but require careful implementation to thwart an attacker to exploit the vulnerabilities related to state management.
[WIP - TREAD WITH CARE [WHTCORPS INC - 2020/2021 ALL RIGHTS RESERVED]]