SBFT一种面向区块链的可扩展去中心化信任基础架构_en1

SBFT: a Scalable Decentralized Trust Infrastructure for

Blockchains

Guy Golan Gueta (VMware Research) Ittai Abraham (VMware Research)

Shelly Grossman (TAU) Dahlia Malkhi (VMware Research) Benny Pinkas (BIU)

Michael K. Reiter (UNC-Chapel Hill) Dragos-Adrian Seredinschi (EPFL)

Orr Tamir (TAU) Alin Tomescu (MIT)

Abstract

We present SBFT: a scalable decentralized trust infrastructure for Blockchains. SBFT implements a new Byzan-

tine fault tolerant algorithm that addresses the challenges of scalability and decentralization. Unlike many previous

per second. This is a 10× speedup compared to Ethereum current limit of 5 transactions per second. SBFT latency

to commit a smart contract execution and make it final is sub-second, this is more than 10× speedup compared to

Ethereum current > 15 second block generation for registering a smart contract execution and several orders of

magnitude speedup relative to Proof-of-Work best-practice finality latency of one-hour.

1 Introduction

There are two trends that we see no current end to. The first is that malicious attacks are becoming increasingly

common. The second is that more and more critical infrastructure, information and businesses are being digitized and

moved on-line. The solution we see to help these two trends better co-exist is to use a scalable decentralized trust

infrastructure.

Why decentralized trust? Centralized solutions often provide very good performance, but centralization comes

machine replication against a malicious adversary that heavily uses the concept of proof-of-work. Decentralizing trust

means that a system should be trustworthy even if some components are malicious. Systems like Bitcoin and Ethereum

use proof-of-work to decentralize trust in a permissionless manner. In Bitcoin and in Ethereum, anyone can join the

system, maintain the replicated state and participate in creating new blocks in a process called mining.

How decentralized are proof-of-work systems? While fundamentally permissionless, the economic friction of

buying and then running a Bitcoin or Ethereum mining rig has inherent economies of scale and unfair advantages to

certain geographical and political regions. This means that miners are strongly incentivized to join a small set of large

mining coalitions.

In a 2018 study, Gencer et al. [GBE

for blockchain that can scale to large deployments?

How to decentralize trust in a permissioned Blockchain? In a permissioned setting, Byzantine fault tolerant

(BFT) replication systems play a major role in providing a scalable trust infrastructure. In the Consortium model for

blockchain, a group of participants (say a group of financial institutions) collaborates to build a shared trust infrastruc-

ture. This infrastructure allows executing smart contracts on top of a BFT engine. A smart contract layer like EVM

provides a Turing complete abstraction that uses resource limits (like gas) to provide fairness and prevent denial of

service attacks.

Does BFT matter for permissionless blockchains? In addition to being a key ingredient in consortium blockchains,

large scale BFT deployments are becoming an important component of public blockchains [CV17]. There is a grow-

ing interest in replacing or combining the current Proof-of-Work mechanisms with Byzantine fault tolerant replica-

Why a new BFT system? By now there exists a solid foundation for practical Byzantine fault tolerant replication

systems. There also exists multiple systems that implemented a practical Byzantine Fault Tolerant replication library.

Our goal is to take the best system designs, foundations, past experiences and carefully optimize and engineer a

solution that is optimized to work over a group of hundreds of replicas and supports the execution of modern EVM

smart contract executions.

Our starting point is PBFT [CL99], a major landmark in designing practical Byzantine BFT. PBFT was initially

targeted for high performance when tuned to tolerate a few failures and replicas communicate over a LAN. PBFT

led to a whole line of research in BFT replication systems [CL99, RCL01, CL02, YMV

03, ADK

06, KAD

07,

KAD

16, LVC

16].

The PBFT approach has the important guarantee that safety is maintained even during periods of timing violations,

whereas only progress depends on the leader. Furthermore, PBFT is optimized for the common case of a healthy leader.

A leader-based protocol works very well in practice. A stable leader can pipeline efficiently. In the (rare) case a leader

is faulty, it is promptly removed from the system, and does not continue to burden the protocol in any manner. A

similar consideration causes the entire industry to employ Paxos for benign settings. Obviously, even a stable leader

need not reign forever, it may be rotated regularly.

However, most of the PBFT-based systems cited above are either focused on small clusters, or use aggressive

batching (tens of thousands of requests per consensus decision), or both. Engineering a solution that can withstand

tens of malicious nodes with hundreds of replicas, while ensuring sub second latencies and high throughput, required

careful integration of several ingredients.

SBFT uses a combination of methods and designs in order to successfully scale to 200 replicas. Some have a novel

aspect or a new variation on previous works. We highlight these methods and designs here.

Instead of sending to everyone, each replica sends to the collector and the collector broadcasts to everyone. When

messages are cryptographically signed, then using threshold signatures [Sho00, CKS00] one can reduce the outgoing

collector message size from linear to constant.

Zyzzyva [KAD

10] used this pattern to reduce all-to-all communication by pushing the collector duty to the

clients. SBFT pushes the collector duty to the replicas in a round-robin manner. We believe that moving the coor-

dination burden to the replicas is more suited to a blockchain setting where there are many light weight clients with

limited connectivity. In addition, SBFT uses threshold signatures to reduce the collector message size and the total

computational overhead of verifying signatures. SBFT also uses a round-robin revolving collector to reduce the load

key signature for request acknowledgement. This single message improvement means that SBFT can scale to support

many extremely thin clients.

SBFT reduces the per-client linear cost to just one message cost by adding a phase that uses a single collector

to aggregate the threshold signatures and send each client a single message carrying one signature. Just like public

blockchains (Bitcoin and Ethereum) SBFT uses a Merkle tree to efficiently authenticate information that is read from

just one replica.

Exploiting optimism with a correct view change protocol. As in Zyzzyva [KAD

10], SBFT allows for a faster

agreement path in optimistic executions: where all replicas are non-faulty and synchronous. No deployed system we

are aware of incorporates optimism correctly; and getting an optimistic protocol to do the right thing, especially the

from all past views while SBFT requires replicas to maintain/send information just from the most recent view.

in the context of single-shot consensus algorithms [MA06].

SBFT takes advantage of modern cryptographic advances. SBFT uses Boneh–Lynn–Shacham (BLS) signa-

tures [BLS04] with security that is comparable to 2048-bit RSA signatures but are just 33 bytes long. Threshold

signatures [Bol02] are much faster when implemented over BLS (see Section 2.1).

We implemented SBFT as a scalable BFT engine and a blockchain that executes EVM smart contracts [Woo14] (see

While standard micro-benchmark experiments with synthetic workloads are a good way to compare the BFT engine

internals, we realize that real world blockchains like Ethereum have a very different type of execution workload based

on smart contracts.

a scalable BFT system can be much more decentralized than a proof-of-work system and still obtain comparable

(and even significantly better) throughput, finality and latency while running the same real world work-load of smart

contracts.

We take 1 million smart contract executions that were processed by Ethereum during a 4 months period Our

experiments show that this smart contract execution workload takes less than 6 hours to complete when running

completes these 1 Million transactions in 20 minutes, or about 833 transactions per second.

We conclude that SBFT more scalable and decentralized relative to previous BFT solutions. Relative to state-of-

distinguish two special conditions. We say that the system is in the synchronous mode, when the adversary can control

slow, and messages between any two non-faulty nodes have a bounded delay. This three-mode model follows that for

Parameterized FaB Paxos [MA06].

Threshold signatures have proved useful in previous BFT algorithms and systems e.g., [Sho00, CKS00, ADK

06,

are robust, meaning signers can efficiently filter out invalid signature shares from malicious participants.

Our implementation specifically uses a robust threshold signature scheme based on Boneh–Lynn–Shacham (BLS)

signatures [BLS04]. BLS signatures resemble RSA signatures. However, while RSA is built in a group of hidden

order, BLS is built using pairings [Jou00] over elliptic curve groups of known order. BLS signatures have three major

advantages over RSA that make them particularly attractive for large scale BFT deployments. (1) Compared to RSA

signatures with the same security level, BLS signatures are substantially shorter. BLS requires 33 bytes compared

to 256 bytes for 2048-bit RSA. (2) Because in RSA threshold signatures the group order must remain hidden even

from the parties contributing to a signature, creating and combining signature shares via interpolation in the exponent

requires several expensive operations [Sho00]. In contrast, BLS threshold signatures [Bol02] allow straightforward

interpolation in the exponent with no additional overhead. (3) Unlike RSA, BLS signature shares support batch