Byzantine Fault-Tolerant Transaction Processing for Replicated Databases

Abstract

Transaction commit is a problem much investigated, both in the databases and systems communities, from the theoretical and practical sides. We present a modular approach to solve this problem in the context of database replication on environments that are subject to Byzantine faults. Our protocol builds on a total order multicast abstraction and is proven to satisfy a set of safety and liveness properties. On the contrary of previous solutions in the literature, it assures strong consistency for transactions, tolerates Byzantine clients and does not need centralized control or multi-version databases. We present an evaluation of a prototype of the system.

Towards Trustworthy Collaborative Editing

“…Even though we followed the approach as in [14], we have made a number of extensions, including correcting a technical error related to state synchronization, providing a more detailed state synchronization algorithm, defining the correctness properties of the mechanisms with proof, implementing the proposed mechanisms, and reporting the performance evaluation results of the mechanisms. The state synchronization mechanism in our work is in a way similar to the deferred updates idea proposed by Luiz et al [31]. Both mechanisms require a primary replica to disseminate information to other replicas, and both require a round of a Byzantine agreement (for each transaction in [31], and for each round of state synchronization in our work).…”

“…The state synchronization mechanism in our work is in a way similar to the deferred updates idea proposed by Luiz et al [31]. Both mechanisms require a primary replica to disseminate information to other replicas, and both require a round of a Byzantine agreement (for each transaction in [31], and for each round of state synchronization in our work). However, our mechanism differs from that in [31] in that our mechanism is an optimistic replication mechanism where updates are applied to a local replica immediately and the state synchronization is used to achieve the eventual consistency of different replicas.…”

“…Both mechanisms require a primary replica to disseminate information to other replicas, and both require a round of a Byzantine agreement (for each transaction in [31], and for each round of state synchronization in our work). However, our mechanism differs from that in [31] in that our mechanism is an optimistic replication mechanism where updates are applied to a local replica immediately and the state synchronization is used to achieve the eventual consistency of different replicas. The deferred updates mechanism in [31] operates within the boundary of a transaction, where updates are not visible to other transactions or clients until the transaction has been committed.…”

“…However, our mechanism differs from that in [31] in that our mechanism is an optimistic replication mechanism where updates are applied to a local replica immediately and the state synchronization is used to achieve the eventual consistency of different replicas. The deferred updates mechanism in [31] operates within the boundary of a transaction, where updates are not visible to other transactions or clients until the transaction has been committed. Furthermore, our mechanism allows for the flexibility of applying state synchronization for a different number of updates.…”

“…Furthermore, our mechanism allows for the flexibility of applying state synchronization for a different number of updates. The number of deferred updates in each transaction in [31] cannot be changed arbitrarily because it is determined by the application semantics. Typically, the number of updates used in our state synchronization mechanism is much larger than that in each transaction.…”