StreamChain: Do Blockchains Need Blocks? Zsolt Istvn, Alessandro - - PowerPoint PPT Presentation

▶
streamchain do blockchains need blocks
SMART_READER_LITE
LIVE PREVIEW

StreamChain: Do Blockchains Need Blocks? Zsolt Istvn, Alessandro - - PowerPoint PPT Presentation

Oct 11, 2023 101 likes •279 views

StreamChain: Do Blockchains Need Blocks? Zsolt Istvn, Alessandro Sorniotti , Marko Vukoli IMDEA Software IBM Research Zrich StreamChain in a nutshell Goal : Low latency and high throughput operation in permissioned ledgers for wider

slide-1
SLIDE 1

StreamChain: Do Blockchains Need Blocks?

Zsolt István, Alessandro Sorniotti, Marko Vukolić

IMDEA Software IBM Research Zürich

slide-2
SLIDE 2

StreamChain in a nutshell

  • Goal: Low latency and high throughput operation in permissioned

ledgers for wider adoption (without changing security or reliability properties)

  • Idea: Revisit core design decisions → turn block-based processing

into streaming processing

  • Enables: New opportunities for blockchains, ability to benefit from

recent hardware trends

2

slide-3
SLIDE 3

The lineage of permissioned ledgers

  • Public ledgers (blockchains)
  • Geo-distribution → no way around

communication latency, gossip to keep everyone up to date

  • Proof-of-work → amortize cost by

packaging up many TXs in blocks

  • Permissioned ledgers
  • Compelling non geo-distributed

use-cases

  • Low latency, high bandwidth, gossip

not necessary

  • No proof-of-work

3

Pain point: When executed inside the same datacenter, permissioned ledgers still take hundreds of milliseconds for transaction finality!

slide-4
SLIDE 4

The source of high latency

4

time T T 1 T 2 T 3 T 4 T 5 T 6 T 7 T 8 Compute hash + Sign S I G T T 1 T 2 T 3 T 4 T 5 T 6 T 7 T 8 time T T 1 T 2 T 3 T 4 T 5 T 6 T 7 T 8 Compute hash + Sign S I G T T 1 T 2 T 3 T 4 T 5 T 6 T 7 T 8 Input: Compute: Output: Input: Compute: Output:

a) “Block” behavior b) Streaming behavior

Extra latency

slide-5
SLIDE 5

StreamChain – Design principles

  • Process transactions system-wide as they arrive
  • Reduces latency without impacting throughput
  • Use batching to hide the cost of high-latency operations (disk accesses)
  • Logical “blocking” of transactions and batching are decoupled
  • Use multi-core parallelism to speed up cryptographic operations
  • Streaming doesn’t change the cost of these…

5

slide-6
SLIDE 6

Hyperledger Fabric 101

  • Open source platform for building applications on top of a

permissioned ledger

  • Smart contracts as “chain code” written in various languages
  • Customizable behavior
  • Separates ordering of transactions into dedicated service – pluggable

implementations for BFT

6

Peer Peer Peer Ord. Ord. Ord. CC

slide-7
SLIDE 7

Peer

Executing transactions in Fabric

  • Has an EOV model to save resources, provide confidentiality
  • Execute: Choice of endorsers depends on a user’s endorsement policy and produce

R/W set of the TX

  • Order: Orderer orders the transactions (R/W sets signed by endorsers), signs blocks
  • Validate: Nodes apply R/W set if endorsement is valid and compatible with state

7

Peer Peer Peer CC Ledger State KVS CC R/W R/W R/W Ordering

slide-8
SLIDE 8

Life after Ordering in Fabric

  • Fabric can have failed transactions due to R/W

set conflicts

  • Client have to retry transaction
  • (Or use a suitable programming model)
  • The less latency between execution and

validation, the less chance of failing TX

  • StreamChain brings this additional benefit in Fabric

8

Peer Ledger State KVS CC R/W 100ms CC2 CC3

slide-9
SLIDE 9

Peer

Sketch of StreamChain in Fabric

9

  • Sign. Valid.

R/W Set Validation Write to Ledger Streaming Streaming Batching TXs from Orderer Pipelined execution of Validate step L S Endorsement of chain codes

slide-10
SLIDE 10

Our Proof of Concept

  • Modifies Fabric v1.0 code to simulate behavior
  • Streaming by making blocks with 1 TX and null signatures from CFT
  • rdering service
  • Still relies on TLS connections
  • Cost of Orderer signature checking per block is negligible compared to TX

signatures

  • Implemented parallel signature checks on TXs in the peers
  • Simulating amortized cost of disk access using RAMdisk

10

slide-11
SLIDE 11

Does this work with ordering service failures?

  • For CFT: Connections to ordering nodes set up via TLS
  • Can rely on single ordering node until crash
  • For BFT: If each node connects to t+1 ordering nodes: data can be

streamed from one, hashes from the others

  • High bandwidth requirement, many connections

11

TX # #

slide-12
SLIDE 12

Does this work with a BFT ordering service?

  • If connecting to only one ordering node, transactions cannot be

recorded to ledger as they arrive

  • Multi-signature required periodically
  • Can speculate on state in the meantime – explained in the paper
  • Make transaction outcome immediately visible to execution logic
  • If signature is wrong, remove temporary state
  • May waste work but no data corruption possible on ledger

12

slide-13
SLIDE 13

Evaluation

  • Ran StreamChain in the IBM Cloud (9 machines)
  • Intel Xeon E5-2683 @ 2GHz
  • SSD storage
  • 1Gbps network
  • Compared to Fabric (Fabcoin) [Eurosys18]
  • UTXO application
  • ~4000TX/s, ~350ms end-to-end latency
  • (Related work has similar orders of magnitude)

13

slide-14
SLIDE 14

Latency

14

slide-15
SLIDE 15

Throughput vs Latency

15

20 40 60 80 100 120 140 1000 2000 3000 4000 Committing Logic Latency (ms) Throughput (TX/s)

Fabric (Fabcoin) StreamChain P.o.C. Future expectation Throughput bound by R/W set check and ledger commit.

slide-16
SLIDE 16

Thoughts on the future

  • Permissioned ledger adoption could hinge on performance
  • Revisit assumptions: streaming processing is a realistic option
  • Proof-of-concept using Hyperledger Fabric
  • StreamChain exposes new bottlenecks → New research challenges
  • Ordering service optimizations
  • Smart contract execution

16

Birds of a Feather Session tomorrow: Consensus and coordination using modern hardware