1. VOLT project: High-throughput distributed ledgers with end-to-end security and confidentiality for consortiums
Srinath Setty, Jacob R. Lorch, Amar Phanishayee, Shaz Qadeer, Michael Roberts, Ramarathnam Venkatesan, and Lidong Zhou
Summer interns: Sebastian Angel (UT & NYU), Soumya Basu (Cornell), Tyler Hunt (UT), Bernhard Kragl (IST Austria), and Kevin Sekniqi (Cornell)

2. “Blockchain hype” in the enterprise setting
Keystone strategy: $50 to $100B (due to technology), and $500B total
Goldman Sachs: $5.5 to 16B (new revenue), $16 to 21B (savings)
Billions of dollars in VC funding for thousands of blockchain startups

3. Blockchain promises
Cross-enterprise business workflows without a trusted, central authority
Automation of auditing and regulatory compliance …

4. Target use cases for blockchains (aka distributed ledgers)
Real-time payments among a group of banks
Settlement among hedge funds, banks, investors, regulators, etc.
Digital assets and self-enforcing business contracts around them …
VOLT’s vision: Build high-throughput distributed ledgers with end-to-end security and privacy

5. Rest of this talk Problem setup and background VOLT: core protocol
Extensions and optimizations

6. Distributed ledgers: setup
A set of n entities where each entity has state (n ≈ 100 to 1000)
A transaction modifies the state of one or more entities
Each entity maintains a ledger containing an ordered list of transactions
Member node
Member node
Member node

7. Distributed ledgers: requirements
Consistency: All correct entities agree on the same ordering of transactions
Scale: Hundreds to thousands of entities; thousands of transactions/sec
Confidentiality: Secrecy of data and metadata about transactions
Governance: Set of entities, transaction processing logic can evolve
Interoperability, checkpointing, etc.
Member node
Member node
Member node

8. Relationship with replicated state machines
Relationship with replicated state machines [Lamport 84, Schneider 90, Castro & Liskov 99, ...]
Common: enabling a group of entities to share a consistent view on an ordering of operations (aka transactions)
Replicated state machines
Distributed ledger
Purpose
Fault tolerant replication of services in datacenters
Cross-organizational collaboration
Interface
State machine
Ledger with entries signed and governed by a state machine
Scale
3-5 machines
Hundreds to thousands
Confidentiality
N/A
Needed for some apps
Interoperability
Will be relevant in the future
Distributed governance
Required

9. Rest of this talk Problem setup and background
VOLT: architecture and core protocol
Extensions and optimizations

10. Overview of VOLT Blockchain service provider (BSP)
A permissioned network of member nodes
Dotted arrows = Optional communication channels
Member node
Verifier
Member node
Verifier
Member node
Verifier
Member node
Verifier
Member node
Verifier
Blockchain service provider (BSP)
An entity that initializes and updates a tamper-resistant ledger

11. What is the structure of the BSP’s ledger and what are its APIs?
How does the verifier ensure that members share a consistent view of the BSP’s ledger?

12. Structure of BSP’s ledger: an append-only log
Adapted from decentralized cryptocurrencies: Bitcoin, Ethereum, …
Block 0: G
Block 1
Metadata block id
null
H(B0) B1
List of transactions
H(B1) id
H(G)
Membership list, blockchain code, and initial state B0
Data block

13. Core APIs exposed by the BSPM1 M2 M3
Member nodes
Setup(code:StateMachine)  id:LedgerId
Transact(id:LedgerId, txn:Transaction)  b:Status
Sync(id:LedgerId, o:Options)  v[c …]:Ledger*
Core BSP APIs
Blockchain service provider (BSP)

14. What is the structure of the BSP’s ledger and what are its APIs?
How does the verifier ensure that members share a consistent view of the BSP’s ledger?

15. VOLT’s core protocol (simplified)
Member 1
Local view
sync
Blockchain service provider
Latest additions to ledger
Send approval transaction =
(“Mem 1”, hash, len, sig)
Compute “approved prefix”
Member 2
Member 3

16. A simple procedure for finding an approved prefix
Each member finds the latest approval transactions of other members via the BSP’s ledger
Computes approval prefix := minimal prefix approved by every other member
We prove: every pair of correct members share a consistent approval prefix---even if the BSP is malicious and even if any number of members are malicious
Relies on semantics of an approval transaction: (“mem i”, hash, len, sig)
Relies on tamper-resistance properties of the BSP’s ledger

17. Recap: what did we achieve?
The BSP constructs a ledger efficiently: admits any implementation for the BSP; can leverage untrusted cloud resources
A simple protocol for members to agree on a single, consistent ledger without trusting anyone.
Does not require any explicit peer-to-peer coordination
Approval transactions can be sent anytime
Approval transactions are small: <256 bytes
The protocol is mostly stateless: all the state is kept on the ledger

18. Implementation and preliminary evaluation
Core system:
BSP:
Rust with Iron framework
Azure Service Fabric and atop fault-tolerant CosmosDB
The verifier:
Rust and Python
C++ (enclaves)
Scales to realistic workloads
Distributed payment network: 20K transactions/second with 5 second latency, 50 participants

19. What is missing in the core protocol?
Scaling to thousands of participants
The BSP could be malicious: violate safety, liveness, and fairness
It requires participation from everyone: each member must periodically send its approval transaction
Each member node must validate all transactions
No confidentiality for transactions

20. (1) Scaling to thousands of participants
A simple trick: The BSP’s ledger is immutable, so members can gossip (relieving load on the BSP for sync operations)
More advanced: cryptographically compress k approval transactions into a single transaction.
Implementation and evaluation in progress

21. (2) Tolerating BSP’s malice
Three types of violations: safety, liveness, and fairness
Example fairness violation: discriminate against certain transactions
The only safety violation an entity like the BSP can commit is forking [Mazieres & Sasha PODC’02]
When members detect a fork, we have a protocol to safely create a new BSP.
With assumptions about the network, we have other mechanisms for members to suspect potential liveness and fairness violations
Members can invoke the above failover protocol if enough members suspect fairness or liveness violations.

22. (3) Improving availability via stronger assumptions
In the core protocol: a member node does not have to trust any other member for consistency
Issue: it requires participation from everyone
Two relaxations by adapting ideas from replicated state machines:
Assume only a threshold number of nodes to be faulty (i.e., f < n/3)
Prevent members from equivocating (via enclaves)
#failures
Safety
Liveness
Basic protocol
n-1 nodes
BFT setting
<n/3 nodes
Enclaves
n nodes
<n/2 nodes

23. Summary of VOLT A new distributed ledger that
ensures strong consistency;
leverages cloud resources; avoids peer-to-peer coordination; and
scales to 20K transactions/second with 50 participants (a simple payment network)
Extensions and optimizations to:
Improve availability with stronger assumptions
Tolerate BSP’s malice
Scale to several hundreds of participants
Leverage verifiable computation to avoid members reexecuting transactions (skipped)
Confidentiality (skipped)

24. Related work Byzantine fault tolerant systems
PBFT, COCA, Zyzzyva, A2M, BFT2F, Trinc, UpRight, …
BFT-based decentralized ledgers: Hyperledger, Tendermint, Ripple, …
Cryptocurrencies and blockchains
Bitcoin, Ethereum, …
Bitcoin-NG, ByzCoin, HoneyBadgerBFT, Algorand, …
Untrusted storage: SUNDR, Depot, SPORC, Venus, CloudProof, Pantry, …
VOLT relies on techniques from these systems, but improves on consistency, confidentiality, fairness, generality, …
VOLT enables securely outsourcing ledgers to untrusted infrastructure; scales better for our target apps

25. Summary of VOLT A new distributed ledger that
ensures strong consistency;
leverages cloud resources; avoids peer-to-peer coordination; and
scales to 20K transactions/second with 50 participants (a simple payment network)
Extensions and optimizations to:
Improve availability with stronger assumptions
Tolerate BSP’s malice
Scaling to several hundreds of participants
Leverage verifiable computation to avoid members reexecuting transactions (skipped)
Confidentiality (skipped)