Technical ReportPDF Available

The Ritva Blockchain: Enabling Confidential Transactions at Scale



The distributed ledger technology has been widely hailed as the break- through technology. It has realised a great number of application scenarios, and improved workflow of many domains. Nonetheless, there remain a few major concerns in adopting and deploying the distributed ledger technology at scale. In this white paper, we tackle two of them, namely the through- put scalability and confidentiality protection for transactions. We learn from the existing body of research, and build a scale-out blockchain plat- form that champions privacy called RVChain. RVChain takes advantage of trusted execution environment to offer confidentiality protection for trans- actions, and scale the throughput of the network in proportion with the number of network participants by supporting parallel shadow chains.
The Ritva Blockchain: Enabling Confidential
Transactions at Scale
Henri Aare, Peter Vitols
Crystal Technology Research
May, 2020
The distributed ledger technology has been widely hailed as the break-
through technology. It has realised a great number of application scenarios,
and improved workflow of many domains. Nonetheless, there remain a few
major concerns in adopting and deploying the distributed ledger technology
at scale. In this white paper, we tackle two of them, namely the through-
put scalability and confidentiality protection for transactions. We learn
from the existing body of research, and build a scale-out blockchain plat-
form that champions privacy called RVChain.RVChain takes advantage of
trusted execution environment to offer confidentiality protection for trans-
actions, and scale the throughput of the network in proportion with the
number of network participants by supporting parallel shadow chains.
1 The current state of affair
The distributed ledger technology (DLT), or commonly referred to as blockchain
technology, provides a transparent and secure manner to record transactions and
manage assets. The transparency comes from the fact that the ledger can be
made public, and thus it is subject to universal audit. The security is guaranteed
thanks to cryptographic mechanisms that make transactions, once recorded on
the blockchain, are irreversible. These very properties enable DLT to attract
a significant amount of attention. The technology has gained enormous trac-
tion since the birth of Bitcoin (BTC) [27]. The two most popular blockchain
networks at this time of writing are Bitcoin and Ethereum [9] networks. These
two blockchains together manage hundreds of billions of dollars in assets. As
impressive as this number appears, it only touches a very small fraction of the
amount of assets currently circulated in the market. There remains a gigantic
room for improvement, expansion, and adoption. We pay our primary attention
to privacy and processing throughput of the transactions.
The first hindrance that deters a wide adoption of blockchain technology in
our everyday life is its limited scalability [8, 35, 18, 24]. While conventional cen-
tralized brokers such as VISA and PayPal can process thousands of transactions
per second, the Bitcoin network only supports 5-8 transactions per second [15].
Ethereum, which is proclaimed to be the general-purpose smart-contract en-
abled blockchain platform, is only able to handle approximately 20 transactions
per second [34, 8]. Another factor that is worth considering is the non-finality
and confirmation latency. A transaction on the Bitcoin network takes up to
an hour to be reliably confirmed (i.e., the transaction’s relevant parties are
confident that it will not be reversed), whereas that number for the Ethereum
network is about 10 minutes [1]. These weaknesses pose too much of a burden
on any large-scale financial service.
There is yet another concern that Bitcoin and Ethereum networks admit,
which is its lack of privacy/confidentiality protections for transactions. All
transactions and/or data posted on these blockchains are not only visible to
their relevant parties, but also to the public. That is, they cannot safely store
or compute on sensitive data (e.g., clinical record, financial transactions) [11].
While both Bitcoin and Ethereum networks adopt pseudonyms so as to offer
a certain level of privacy protections, a large body of research has shown that
de-anonymizing such pseudonyms is feasible [29, 21].
2 Bridging the gap with the RVChain
We at Ritva set out to mitigate the aforementioned current state of affair by
developing a performative general-purpose blockchain platform that supports
confidential transactions, called RVChain. Abstractly, The RVChain takes ad-
vantage of the recent development in computer hardware, in particular CPUs
that are capable of provisioning Trusted Execution Environment (TEE) [23, 4,
3, 33, 6, 5, 12]. Another technical feature that enables the RVChain to operate
at scale is its capability to support parallel shadow chains whose transactions
can be totally ordered [34].
By incorporating TEE, RVChain effectively simplifies the threat model it has
to deal with to crash fault tolerance [20, 10, 7, 26], to which a number of perfor-
mative consensus protocols have been studied. To further scale the transaction
throughput of the platform alongside with its network size, RVChain allows
virtually unlimited number of shadow chains (subject only to the network size)
to complement one another. Network participants (or miners) are assigned to
a chain uniformly at random, and leverage crash fault tolerance consensus pro-
tocol to establish a total ordering of transactions on that chain. RVChain then
relies on a simple solution to establish a global order for transactions across the
parallel shadow chains, thereby attaining consistency. The preliminary design
of the RVChain currently supports approximately 2500 transactions per second
for the network consisting of 100 participants. Its theoretical foundation allows
the transaction to be processed at the network speed. That is, the only limit to
the performance of the RVChain is the speed at which it receives transactions.
With 5G technology on the horizon, the capacity is virtually limitless.
The other advantage of the TEE is its isolated execution [23]. More specif-
ically, the TEE provisions a protected address space. Code and data running
and being processed in this protected address space is inaccessible to any unau-
thorised processes, even the privileged ones such as the Operating System or
Hypervisor. When there is a need to write the sensitive data off the protected
address space to the secondary memory, the TEE architecture transparently
encrypts the sensitive data with cryptographic keys only available to the pro-
cessor. RVChain makes use of this isolated execution feature offered by the
TEE to provide stronger privacy and confidentiality protections for the sensi-
tive transactions. In particular, the sensitive transactions and their data are
stored encrypted on the public ledger. When they need to be processed, they
are loaded into the protected address space of the TEE, decrypted and con-
sumed therein. The output or updated state of the data and/or transactions
are encrypted before being written off the protected address space to the pub-
lic ledger. Consequently, only ciphertext (i.e., encrypted form) of the sensitive
transactions and their data are visible publicly, while their integrity and consis-
tency are accounted for by the TEE and the consensus protocol in use. Thanks
to the semantic security of the encryption scheme in use, little, if not none,
information can be inferred from the ciphertexts, hence the confidentiality.
3 Technical Foundations
3.1 Trusted Execution Environment
Intel recently proposed a set of CPUs that are capable of provisioning TEE, in
particular Intel SGX. It enables a host to instantiate one or multiple TEEs, or
enclaves, simultaneously. An enclave is associated with a CPU-guarded address
space which is accessible only by the enclave code; the CPU blocks any non-
enclave code’s attempt to access the enclave memory. This effectively isolates
the enclave from other enclaves concurrently running on the same host, from
the OS, and from other user processes, thereby providing confidentiality and
integrity protections for data and code loaded inside the enclaves. Memory
pages can be swapped out of the enclave memory, but they are encrypted using
the processor’s key prior to leaving the enclave. Enclaves cannot directly execute
OS-provided services such as I/O. In order to access those services, enclaves have
to employ OCalls (calls executed by the enclave code to transfer the control to
non-enclave code) and ECalls (API for untrusted applications to transfer control
back to the enclave). These ECalls and OCalls constitute the enclave boundary
interface, enabling a communication between the enclave code and the untrusted
application to service OS provided functions. The RVChain leverages Intel SGX
to implement the TEEs.
3.2 Crash Fault Tolerance Consensus Protocol
A blockchain is essentially a ledger maintained by independent nodes (servers,
processors) that are geographically distributed. The consistency of the blockchain
relies on these nodes reaching a consensus. A large body of research has been
dedicated to consensus protocols, addressing this problem. Consensus protocols
primarily tackle either Byzantine failure model or crash failure model [13]. In
this paper, we pay our attention to a consensus protocol that is designed for the
crash failure model [19]. As the name suggests, this threat model assumes that
a faulty node crashes (i.e., become indefinitely unresponsive), but never devi-
ates from its intended behaviour. Our solution builds on the Raft consensus
protocol [28] for its simplicity.
The protocol [28] is designed for a network of ndeterministic nodes. The
maximum number of faulty nodes the protocol can tolerate is f=n1
2. Each
node maintain a log which records an ordered list of transactions. The protocol
guarantees that logs of non-faulty nodes converge. That is, they record the same
sequence of transactions. A process can assume one of the following three roles,
which are follower, candidate and leader.
Time is split into terms that are numbered with consecutive integers. In
each term, there is one node being elected as the leader, while the remaining
nodes serve as followers. The leader keeps its authority by exchanging heartbeat
messages with all the followers periodically. Should a follower fail to receive any
message from the leader after an election time-out has expired, it considers the
leader as having been crashed. It then increments its term value, switches its
role to being candidate, and requests for votes to become the new leader. The
candidate obtains the leadership if it manages to obtains votes from a majority
of other nodes in the network.
In normal operation, the followers respond only to messages and requests
they receive from the leader and candidate, remaining passive otherwise. All the
transactions (e.g., commands or requests from the clients) are sent to the leader.
It then replicates the transactions on the rest of the network. Upon receiving
a transaction, the leader insert it as a new entry to its log. The transaction is
identified using the leader’s current term and an index at which it is inserted
to the log. Subsequently, the leader broadcasts the entry to all of the followers.
Upon receiving the entry, the followers inserted it to their logs, and responds
the leader with an acknowledgement receipt. The leader ensures that the entry
has been replicated on a majority of nodes by counting the acknowledgement it
receives. Once it receives one from f+1 or more nodes, it executes the comment
contained in the entry. This also commits all other entries preceding the entry
in question. The leader keeps track of the highest index it has committed,
and includes such information in subsequent messages it communicates with
the followers. This is to inform the later on the committed entries. Similar to
[13], by running the Raft consensus protocol inside a TEE that offers attested
and isolated execution, RVChain restricts adversarial behaviours of the faulty
nodes, thereby reducing the threat model to crash fault tolerance, to which Raft
applies [2, 26, 16].
3.3 Scaling Throughput with Parallel Shadow Chains
The RVChain comprises multiple parallel shadow chains. Network participants,
or nodes or verifiers, in the RVChain are assigned to a particular shadow
chain uniformly at random using a random seed rnd generated inside their
enclave [32, 25, 31, 30]. Given rnd, the nodes derive their shadow chain assign-
ment by evaluating a random permutation πof [1 : N] seeded by rnd (with N
being the total number of network participants). πis then divided into approx-
imately equally-sized chunks, each of which represents the verifiers-to-shadow
chain assignment.
It is worth emphasizing that there is no upper limit for the number of shadow
chains running in parallel. This effectively unleash the transaction throughput
of the RVChain , allowing the processing capacity to grow in proportion with
the number of verifiers joining the network.
Random Seed Generation. The RVChain exploits TEEs to obtain rnd in
an efficient manner. The process is partaken by all nodes in the network, thereby
assuring the fairness. The Random Seed Generation requires each node to be
equipped with a RandomnessBeacon enclave, which is programmed to return
fresh, unbiased random numbers subject to a certain probability. Similar to
prior researches [17, 22, 35], this work considers a synchronous network (i.e., the
communication delay ∆ is known a priori) during the distributed randomness
generation procedure.
To obtain its shadow chain assignment, each node in the network invokes
its RandomnessBeacon enclave with an epoch number erepresenting the
current period of time. Given the input e, the RandomnessBeacon enclave
samples two random values qand rnd via two independent invocations of the
sgx read rand function. Should q= 0, the enclave outputs a signed certifi-
cate containing he, rndi. Otherwise, it returns signalling the node cannot
obtain the certificate. Upon obtaining the certificate, a node broadcast it to
the network. After a time ∆, all nodes in the network should have received all
certificates that have been sent. They lock in the lowest rnd they receive for
epoch e, and employs that value to evaluate its shadow chain assignment [14].
The security of this procedure is properly analysed in [14]. The Random-
nessBeacon enclave is programmed in such a way that a node can only invoke
it once every epoch. This prevents the adversary from selectively discarding
the enclave’s output so as to bias the final randomness. In an unlikely event
wherein all nodes fail to receive any message after ∆ (i.e., when no node can
obtain he, rndifrom its enclave), the nodes increment eand repeat the process.
The probability of such an event is Prepeat = (12l)Nwhere lis the bit length
of q. This probability can be configured in order to achieve a desirable trade-
off between Prepeat and the communication overhead, which is O(2lN2). For
instance, setting l= log(z) for some constant z, we obtain Prepeat 0 and the
communication is O(N2). Alternatively, if we set l= log(N), then Prepeat e1
and the communication is O(N).
Securing individual shadow chain. Nodes on the same shadow chain en-
gage in a consensus protocol to arrive at an agreement on the total order of the
transactions incurred on that chain. If a transaction is marked as “sensitive”,
it is processed inside the enclaves with isolated execution, thereby attaining
confidentiality protection.
Global Order across parallel shadow chains We draw the neat idea of
establishing one global order for all transactions posted on all shadow chains
from [34]. In particular, transactions in each individual shadow chain are
grouped into blocks. Each block is associated with two fields, namely (rank,
NextRank), and a chain id, which is the id of the shadow chain it belongs to.
These two fields are used to establish total order of transactions across the
shadow chains. In the total ordering of fully-confirmed blocks, the blocks are
ordered by increasing rank values, with tie-breaking based on the chain ids [34].
Nodes in the network are able to observe all the chains. Thus, they can infer
the expected rank of the next block to be recorded on each shadow chain. Let
us denote by xthe largest value among such expected ranks, then xnaturally
associates with the “longest” shadow chain among all the shadow chains. The
intuition is that every new block Bshould help its chain catch up with the
current “longest” chain. Following this intuition, the node that proposes the
new block Bshould set the NextRank field of Bto x, or a value greater than x.
It is also worth emphasizing that B’s NextRank should always be larger than
B’s rank. This constrains is necessary to ensure rank values of blocks on each
shadow chains are monotonically increasing.
Given the (rank, NextRank) fields of blocks are set in the afford mentioned
manner, establishing a total order among blocks inhabiting different shadow
chains is rather straightforward. For the sake of exposition, let us consider a
local view of an honest node at any given time. We denote by yithe value
contained in the NextRank field of the last partially-confirmed block on the
shadow chain i, and ConfirmBar be the minimum among all such values. It
follows from the setting of (rank, NextRank) that next partially-confirmed block
on any shadow chain must have its rank equal to or larger than ConfirmBar
value. Consequently, one can consider all partially-confirmed blocks that have
rank value smaller than ConfirmBar as fully-confirmed. These fully-confirmed
blocks are ordered by their rank values. Should two blocks have equal rank
values, tie is broken by their chain ids.
4 Incentives
Every blockchain needs a native token. For the sake of exposition, let us call
native token of RVChain by RT 1.
The RT tokens shall be subject to the hard cap. A portion of the tokens
are pre-minted for the development of the RVChain. The remaining portion of
the token supply is reserved for rewarding network participants (or verifiers)
1The name of the token in deployment maybe different, and we will announce on the Ritva
website once its name has been finalised
who contribute their resources to verify the transactions on the RVChain. It
is worth mentioning that all transactions incurred on the RVChain network
shall be subject to the transaction fee to be collected in RT. A portion of the
transaction fee is given to the network participants, while the other is burnt off.
This token burn inevitably leads to the depreciation of token supply over time,
which translates into an appreciation of the token price against fiat.
[1] Ethereum: Blockchain app platform.
[2] The Coco Framework.
[3] Trusted computing group.
[4] Intel software guard extensions developer guide. https://download.,
[5] Tiago Alves and Don Felton. Trustzone: Integrated hardware and software
security. Technical report, ARM, 2004.
[6] Ittai Anati, Shay Gueron, Simon Johnson, and Vincent Scarlata. Innovative
technology for cpu based attestation and sealing. In Proceedings of the 2nd
international workshop on hardware and architectural support for security
and privacy, volume 13. ACM New York, NY, USA, 2013.
[7] Shehar Bano, Alberto Sonnino, Mustafa Al-Bassam, Sarah Azouvi, Patrick
McCorry, Sarah Meiklejohn, and George Danezis. Consensus in the age of
blockchain., 2018.
[8] Johannes Behl, Tobias Distler, and R¨udiger Kapitza. Hybrids on steroids:
Sgx-based high performance bft. In EuroSys, 2017.
[9] Vitalik Buterin. Ethereum: A next-generation smart contract and decen-
tralized application platform. https: // github. com/ ethereum/ wiki/
wiki/ White-Paper , 2014.
[10] Tushar Chandra, Robert Griesemer, and Joshua Redstone. Paxos made
live: and engineering perspective. In PODC, 2007.
[11] Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah
Johnson, Ari Juels, Andrew Miller, and Dawn Song. Ekiden: A platform
for confidentiality-preserving, trustworthy, and performant smart contract
execution. arXiv preprint arXiv:1804.05141, 2018.
[12] Victor Costan, Ilia Lebedev, and Srinivas Devadas. Sanctum: Minimal
hardware extensions for strong software isolation. https://eprint.iacr.
[13] Hung Dang and Ee-Chien Chang. Autonomous membership service for
enclave applications. arXiv preprint arXiv:1905.06460, 2019.
[14] Hung Dang, Tien Tuan Anh Dinh, Dumitrel Loghin, Ee-Chien Chang, Qian
Lin, and Beng Chin Ooi. Towards scaling blockchain systems via sharding.
In Proceedings of the 2019 International Conference on Management of
Data, pages 123–140, 2019.
[15] Arthur Gervais, Ghassan O Karame, Karl W¨ust, Vasileios Glykantzis, Hu-
bert Ritzdorf, and Srdjan Capkun. On the security and performance of
proof of work blockchains. In CCS, 2016.
[16] Rachid Guerraoui, Nikola Kneˇzevi´c, Vivien Qu´ema, and Marko Vukoli´c.
The next 700 bft protocols. In EuroSys, 2010.
[17] Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly,
and Bryan Ford. Omniledger: A secure, scale-out, decentralized ledger.
IACR Cryptology ePrint Archive, 2017.
[18] Jae Kwon. Tendermint: Consensus without mining. https://tendermint.
[19] Leslie Lamport. Fast paxos. Distributed Computing, 2006.
[20] Leslie Lamport et al. Paxos made simple. ACM Sigact News, 32(4):18–25,
[21] Xiaoqi Li, Peng Jiang, Ting Chen, Xiapu Luo, and Qiaoyan Wen. A sur-
vey on the security of blockchain systems. Future Generation Computer
Systems, 2017.
[22] Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth
Gilbert, and Prateek Saxena. A secure sharding protocol for open
blockchains. In CCS, 2016.
[23] Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos V Rozas,
Hisham Shafi, Vedvyas Shanbhogue, and Uday R Savagaonkar. Innova-
tive instructions and software model for isolated execution. HASP@ ISCA,
10, 2013.
[24] Silvio Micali. Algorand: the efficient and democratic ledger. arXiv preprint
arXiv:1607.01341, 2016.
[25] Silvio Micali, Michael Rabin, and Salil Vadhan. Verifiable random func-
tions. In FOCS, 1999.
[26] JP Morgan. Quorum.
[27] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.
[28] Diego Ongaro and John K Ousterhout. In search of an understandable
consensus algorithm. In USENIX Annual Technical Conference, pages 305–
319, 2014.
[29] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian
Miers, Eran Tromer, and Madars Virza. Zerocash: Decentralized anony-
mous payments from bitcoin. In 2014 IEEE Symposium on Security and
Privacy, pages 459–474. IEEE, 2014.
[30] Berry Schoenmakers. A simple publicly verifiable secret sharing scheme
and its application to electronic voting. In CRYPTO, 1999.
[31] Markus Stadler. Publicly verifiable secret sharing. In EUROCRYPT, 1996.
[32] Ewa Syta, Philipp Jovanovic, Eleftherios Kokoris Kogias, Nicolas Gailly,
Linus Gasser, Ismail Khoffi, Michael J Fischer, and Bryan Ford. Scalable
bias-resistant distributed randomness. In IEEE S& P, 2017.
[33] Florian Tramer, Fan Zhang, Huang Lin, Jean-Pierre Hubaux, Ari Juels,
and Elaine Shi. Sealed-glass proofs: Using transparent enclaves to prove
and sell knowledge. In EuroS&P, 2017.
[34] Haifeng Yu, Ivica Nikolic, Ruomu Hou, and Prateek Saxena. Ohie:
blockchain scaling made simple. arXiv preprint arXiv:1811.12628, 2018.
[35] Mahdi Zamani, Mahnush Movahedi, and Mariana Raykova. Rapidchain:
Scaling blockchain via full sharding. In CCS, 2018.
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
Existing blockchain systems scale poorly because of their distributed consensus protocols. Current attempts at improving blockchain scalability are limited to cryptocurrency. Scaling blockchain systems under general workloads (i.e., non-cryptocurrency applications) remains an open question. This work takes a principled approach to apply sharding to blockchain systems in order to improve their transaction throughput at scale. This is challenging, however, due to the fundamental difference in failure models between databases and blockchain. To achieve our goal, we first enhance the performance of Byzantine consensus protocols, improving individual shards' throughput. Next, we design an efficient shard formation protocol that securely assigns nodes into shards. We rely on trusted hardware, namely Intel SGX, to achieve high performance for both consensus and shard formation protocol. Third, we design a general distributed transaction protocol that ensures safety and liveness even when transaction coordinators are malicious. Finally, we conduct an extensive evaluation of our design both on a local cluster and on Google Cloud Platform. The results show that our consensus and shard formation protocols outperform state-of-the-art solutions at scale. More importantly, our sharded blockchain reaches a high throughput that can handle Visa-level workloads, and is the largest ever reported in a realistic environment.
Full-text available
Since its inception, the blockchain technology has shown promising application prospects. From the initial cryptocurrency to the current smart contract, blockchain has been applied to many fields. Although there are some studies on the security and privacy issues of blockchain, there lacks a systematic examination on the security of blockchain systems. In this paper, we conduct a systematic study on the security threats to blockchain and survey the corresponding real attacks by examining popular blockchain systems. We also review the security enhancement solutions for blockchain, which could be used in the development of various blockchain systems, and suggest some future directions to stir research efforts into this area.
Conference Paper
Full-text available
Proof of Work (PoW) powered blockchains currently account for more than 90% of the total market capitalization of existing digital cryptocurrencies. Although the security provisions of Bitcoin have been thoroughly analysed, the security guarantees of variant (forked) PoW blockchains (which were instantiated with different parameters) have not received much attention in the literature. This opens the question whether existing security analysis of Bitcoin's PoW applies to other implementations which have been instantiated with different consensus and/or network parameters. In this paper, we introduce a novel quantitative framework to analyse the security and performance implications of various consensus and network parameters of PoW blockchains. Based on our framework, we devise optimal adversarial strategies for double-spending and selfish mining while taking into account real world constraints such as network propagation, different block sizes, block generation intervals, information propagation mechanism, and the impact of eclipse attacks. Our framework therefore allows us to capture existing PoW-based deployments as well as PoW blockchain variants that are instantiated with different parameters, and to objectively compare the tradeoffs between their performance and security provisions.
Sanctum offers the same promise as Intel’s Software Guard Extensions (SGX), namely strong provable isolation of software modules running concurrently and sharing resources, but protects against an important class of additional software attacks that infer private information from a program’s memory access patterns. Sanctum shuns unnecessary complexity, leading to a simpler security analysis. We follow a principled approach to eliminating entire attack surfaces through isolation, rather than plugging attack-specific privacy leaks. Most of Sanctum’s logic is implemented in trusted software, which does not perform cryptographic operations using keys, and is easier to analyze than SGX’s opaque microcode, which does. Our prototype targets a Rocket RISC-V core, an open implementation that allows any researcher to reason about its security properties. Sanctum’s extensions can be adapted to other processor cores, because we do not change any major CPU building block. Instead, we add hardware at the interfaces between generic building blocks, without impacting cycle time. Sanctum demonstrates that strong software isolation is achievable with a surprisingly small set of minimally invasive hardware changes, and a very reasonable overhead.
Conference Paper
A major approach to overcoming the performance and scalability limitations of current blockchain protocols is to use sharding which is to split the overheads of processing transactions among multiple, smaller groups of nodes. These groups work in parallel to maximize performance while requiring significantly smaller communication, computation, and storage per node, allowing the system to scale to large networks. However, existing sharding-based blockchain protocols still require a linear amount of communication (in the number of participants) per transaction, and hence, attain only partially the potential benefits of sharding. We show that this introduces a major bottleneck to the throughput and latency of these protocols. Aside from the limited scalability, these protocols achieve weak security guarantees due to either a small fault resiliency (e.g., 1/8 and 1/4) or high failure probability, or they rely on strong assumptions (e.g., trusted setup) that limit their applicability to mainstream payment systems. We propose RapidChain, the first sharding-based public blockchain protocol that is resilient to Byzantine faults from up to a 1/3 fraction of its participants, and achieves complete sharding of the communication, computation, and storage overhead of processing transactions without assuming any trusted setup. RapidChain employs an optimal intra-committee consensus algorithm that can achieve very high throughputs via block pipelining, a novel gossiping protocol for large blocks, and a provably-secure reconfiguration mechanism to ensure robustness. Using an efficient cross-shard transaction verification technique, our protocol avoids gossiping transactions to the entire network. Our empirical evaluations suggest that RapidChain can process (and confirm) more than 7,300 tx/sec with an expected confirmation latency of roughly 8.7 seconds in a network of 4,000 nodes with an overwhelming time-to-failure of more than 4,500 years.
Conference Paper
Bias-resistant public randomness is a critical component in many (distributed) protocols. Generating public randomness is hard, however, because active adversaries may behave dishonestly to bias public random choices toward their advantage. Existing solutions do not scale to hundreds or thousands of participants, as is needed in many decentralized systems. We propose two large-scale distributed protocols, RandHound and RandHerd, which provide publicly-verifiable, unpredictable, and unbiasable randomness against Byzantine adversaries. RandHound relies on an untrusted client to divide a set of randomness servers into groups for scalability, and it depends on the pigeonhole principle to ensure output integrity, even for non-random, adversarial group choices. RandHerd implements an efficient, decentralized randomness beacon. RandHerd is structurally similar to a BFT protocol, but uses RandHound in a one-time setup to arrange participants into verifiably unbiased random secret-sharing groups, which then repeatedly produce random output at predefined intervals. Our prototype demonstrates that RandHound and RandHerd achieve good performance across hundreds of participants while retaining a low failure probability by properly selecting protocol parameters, such as a group size and secret-sharing threshold. For example, when sharding 512 nodes into groups of 32, our experiments show that RandHound can produce fresh random output after 240 seconds. RandHerd, after a setup phase of 260 seconds, is able to generate fresh random output in intervals of approximately 6 seconds. For this configuration, both protocols operate at a failure probability of at most 0.08% against a Byzantine adversary.
Conference Paper
With the advent of trusted execution environments provided by recent general purpose processors, a class of replication protocols has become more attractive than ever: Protocols based on a hybrid fault model are able to tolerate arbitrary faults yet reduce the costs significantly compared to their traditional Byzantine relatives by employing a small subsystem trusted to only fail by crashing. Unfortunately, existing proposals have their own price: We are not aware of any hybrid protocol that is backed by a comprehensive formal specification, complicating the reasoning about correctness and implications. Moreover, current protocols of that class have to be performed largely sequentially. Hence, they are not well-prepared for just the modern multi-core processors that bring their very own fault model to a broad audience. In this paper, we present Hybster, a new hybrid state-machine replication protocol that is highly parallelizable and specified formally. With over 1 million operations per second using only four cores, the evaluation of our Intel SGX-based prototype implementation shows that Hybster makes hybrid state-machine replication a viable option even for today's very demanding critical services.