The Ritva Blockchain: Enabling Confidential Transactions at Scale

05/28/2020
by   Henri Aare, et al.
0

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 throughput scalability and confidentiality protection for transactions. We learn from the existing body of research, and build a scale-out blockchain platform that champions privacy called RVChain. RVChain takes advantage of trusted execution environment to offer confidentiality protection for transactions, and scales the throughput of the network in proportion with the number of network participants by supporting parallel shadow chains.

READ FULL TEXT VIEW PDF

page 1

page 2

page 3

page 4

01/08/2018

A Scale-out Blockchain for Value Transfer with Spontaneous Sharding

Blockchain technology, sometimes known by its applications like cryptocu...
04/09/2019

Privacy protection of occupant behavior data and using blockchain for securely transferring temperature records in HVAC systems

The proportion of Energy consumption in the building industry is great, ...
07/16/2020

OptChain: Optimal Transactions Placement for Scalable Blockchain Sharding

A major challenge in blockchain sharding protocols is that more than 95 ...
06/27/2019

DiPETrans: A Framework for Distributed Parallel Execution of Transactions of Blocks in Blockchain

In most of the modern day blockchain, transactions are executed serially...
04/14/2020

Witness-based Approach for Scaling Distributed Ledgers to Massive IoT Scenarios

Distributed Ledger Technologies (DLTs) are playing a major role in build...
03/11/2020

Scaling Hyperledger Fabric Using Pipelined Execution and Sparse Peers

Many proofs of concept blockchain applications built using Hyperledger F...
05/03/2022

Reality-based UTXO Ledger

The Unspent Transaction Output (UTXO) model is commonly used in the fiel...

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 traction since the birth of Bitcoin (BTC) [25]. The two most popular blockchain networks at this time of writing are Bitcoin and Ethereum [5] 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 [4, 35, 16, 23]. While conventional centralized brokers such as VISA and PayPal can process thousands of transactions per second, the Bitcoin network only supports 5-8 transactions per second [12]. Ethereum, which is proclaimed to be the general-purpose smart-contract enabled blockchain platform, is only able to handle approximately 20 transactions per second [34, 4]. 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 [11]. 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) [7]. 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 [27, 19].

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 advantage of the recent development in computer hardware, in particular CPUs that are capable of provisioning Trusted Execution Environment (TEE) [21, 14, 33, 32, 2, 1, 8]. 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 [17, 6, 3, 24], to which a number of performative 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 protocol 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 [21]. More specifically, the TEE provisions a protected address space. Code and data running and being processed in this protected address space is inaccessible to any unauthorised 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 processor. RVChain  makes use of this isolated execution feature offered by the TEE to provide stronger privacy and confidentiality protections for the sensitive 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 consumed therein. The output or updated state of the data and/or transactions are encrypted before being written off the protected address space to the public ledger. Consequently, only ciphertext (i.e., encrypted form) of the sensitive transactions and their data are visible publicly, while their integrity and consistency 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 [9]. In this paper, we pay our attention to a consensus protocol that is designed for the crash failure model [18]. As the name suggests, this threat model assumes that a faulty node crashes (i.e., become indefinitely unresponsive), but never deviates from its intended behaviour. Our solution builds on the Raft consensus protocol [26] for its simplicity.

The protocol [26] is designed for a network of deterministic nodes. The maximum number of faulty nodes the protocol can tolerate is . 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 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  [9], 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 [31, 24, 13].

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 [30, 22, 29, 28]. Given rnd, the nodes derive their shadow chain assignment by evaluating a random permutation of seeded by rnd (with being the total number of network participants). is then divided into approximately 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 

[15, 20, 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

representing the current period of time. Given the input , the RandomnessBeacon enclave samples two random values q and rnd via two independent invocations of the sgx_read_rand function. Should , the enclave outputs a signed certificate containing . 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 , and employs that value to evaluate its shadow chain assignment [10].

The security of this procedure is properly analysed in [10]. The RandomnessBeacon 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 from its enclave), the nodes increment and repeat the process. The probability of such an event is where is the bit length of q. This probability can be configured in order to achieve a desirable trade-off between and the communication overhead, which is . For instance, setting for some constant , we obtain and the communication is . Alternatively, if we set , then and the communication is .

Securing individual shadow chain.

Nodes on the same shadow chain engage 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 the largest value among such expected ranks, then naturally associates with the “longest” shadow chain among all the shadow chains. The intuition is that every new block should help its chain catch up with the current “longest” chain. Following this intuition, the node that proposes the new block should set the NextRank field of to , or a value greater than . It is also worth emphasizing that ’s NextRank should always be larger than ’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 the value contained in the NextRank field of the last partially-confirmed block on the shadow chain , 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 RT111The name of the token in deployment maybe different, and we will announce on the Ritva website once its name has been finalised.

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) 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.

References

  • [1] T. Alves and D. Felton (2004) Trustzone: integrated hardware and software security. Technical report ARM. Cited by: §2.
  • [2] I. Anati, S. Gueron, S. Johnson, and V. Scarlata (2013) Innovative technology for cpu based attestation and sealing. In Proceedings of the 2nd international workshop on hardware and architectural support for security and privacy, Vol. 13. Cited by: §2.
  • [3] S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P. McCorry, S. Meiklejohn, and G. Danezis (2018) Consensus in the age of blockchain. Note: https://arxiv.org/abs/1711.03936 Cited by: §2.
  • [4] J. Behl, T. Distler, and R. Kapitza (2017) Hybrids on steroids: sgx-based high performance bft. In EuroSys, Cited by: §1.
  • [5] V. Buterin (2014) Ethereum: a next-generation smart contract and decentralized application platform. https://github.com/ethereum/wiki/wiki/White-Paper. Cited by: §1.
  • [6] T. Chandra, R. Griesemer, and J. Redstone (2007) Paxos made live: and engineering perspective. In PODC, Cited by: §2.
  • [7] R. Cheng, F. Zhang, J. Kos, W. He, N. Hynes, N. Johnson, A. Juels, A. Miller, and D. Song (2018) Ekiden: a platform for confidentiality-preserving, trustworthy, and performant smart contract execution. arXiv preprint arXiv:1804.05141. Cited by: §1.
  • [8] V. Costan, I. Lebedev, and S. Devadas Sanctum: minimal hardware extensions for strong software isolation. Note: https://eprint.iacr.org/2015/564.pdf Cited by: §2.
  • [9] H. Dang and E. Chang (2019) Autonomous membership service for enclave applications. arXiv preprint arXiv:1905.06460. Cited by: §3.2, §3.2.
  • [10] H. Dang, T. T. A. Dinh, D. Loghin, E. Chang, Q. Lin, and B. C. Ooi (2019) Towards scaling blockchain systems via sharding. In Proceedings of the 2019 International Conference on Management of Data, pp. 123–140. Cited by: §3.3, §3.3.
  • [11] Ethereum: blockchain app platform.. Note: https://www.ethereum.org/ Cited by: §1.
  • [12] A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, and S. Capkun (2016) On the security and performance of proof of work blockchains. In CCS, Cited by: §1.
  • [13] R. Guerraoui, N. Knežević, V. Quéma, and M. Vukolić (2010) The next 700 bft protocols. In EuroSys, Cited by: §3.2.
  • [14] (2018) Intel software guard extensions developer guide. Note: https://download.01.org/intel-sgx/linux-1.7/docs/Intel_SGX_Developer_Guide.pdf Cited by: §2.
  • [15] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, and B. Ford (2017) OmniLedger: a secure, scale-out, decentralized ledger. IACR Cryptology ePrint Archive. Cited by: §3.3.
  • [16] J. Kwon Tendermint: consensus without mining. Note: https://tendermint.com/static/docs/tendermint.pdf Cited by: §1.
  • [17] L. Lamport et al. (2001) Paxos made simple. ACM Sigact News 32 (4), pp. 18–25. Cited by: §2.
  • [18] L. Lamport (2006) Fast paxos. Distributed Computing. Cited by: §3.2.
  • [19] X. Li, P. Jiang, T. Chen, X. Luo, and Q. Wen (2017) A survey on the security of blockchain systems. Future Generation Computer Systems. Cited by: §1.
  • [20] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena (2016) A secure sharding protocol for open blockchains. In CCS, Cited by: §3.3.
  • [21] F. McKeen, I. Alexandrovich, A. Berenzon, C. V. Rozas, H. Shafi, V. Shanbhogue, and U. R. Savagaonkar (2013) Innovative instructions and software model for isolated execution.. HASP@ ISCA 10. Cited by: §2, §2.
  • [22] S. Micali, M. Rabin, and S. Vadhan (1999) Verifiable random functions. In FOCS, Cited by: §3.3.
  • [23] S. Micali (2016) ALGORAND: the efficient and democratic ledger. arXiv preprint arXiv:1607.01341. Cited by: §1.
  • [24] J. Morgan Quorum. Note: https://github.com/jpmorganchase/quorum Cited by: §2, §3.2.
  • [25] S. Nakamoto (2008) Bitcoin: a peer-to-peer electronic cash system. Cited by: §1.
  • [26] D. Ongaro and J. K. Ousterhout (2014) In search of an understandable consensus algorithm.. In USENIX Annual Technical Conference, pp. 305–319. Cited by: §3.2, §3.2.
  • [27] E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza (2014) Zerocash: decentralized anonymous payments from bitcoin. In 2014 IEEE Symposium on Security and Privacy, pp. 459–474. Cited by: §1.
  • [28] B. Schoenmakers (1999) A simple publicly verifiable secret sharing scheme and its application to electronic voting. In CRYPTO, Cited by: §3.3.
  • [29] M. Stadler (1996) Publicly verifiable secret sharing. In EUROCRYPT, Cited by: §3.3.
  • [30] E. Syta, P. Jovanovic, E. K. Kogias, N. Gailly, L. Gasser, I. Khoffi, M. J. Fischer, and B. Ford (2017) Scalable bias-resistant distributed randomness. In IEEE S& P, Cited by: §3.3.
  • [31] () The Coco Framework. Note: http://aka.ms/cocopaper Cited by: §3.2.
  • [32] F. Tramer, F. Zhang, H. Lin, J. Hubaux, A. Juels, and E. Shi (2017) Sealed-glass proofs: using transparent enclaves to prove and sell knowledge. In EuroS&P, Cited by: §2.
  • [33] () Trusted computing group. Note: http://www.trustedcomputinggroup.org/ Cited by: §2.
  • [34] H. Yu, I. Nikolic, R. Hou, and P. Saxena (2018) OHIE: blockchain scaling made simple. arXiv preprint arXiv:1811.12628. Cited by: §1, §2, §3.3.
  • [35] M. Zamani, M. Movahedi, and M. Raykova (2018) RapidChain: scaling blockchain via full sharding. In CCS, Cited by: §1, §3.3.