PaperlayerView exact revision on arXiv

Source-linked AI summary

Chainspace: A Sharded Smart Contracts Platform

Mustafa Al-Bassam, Alberto Sonnino, Shehar Bano, Dave Hrycyszyn, George Danezis

arXiv:1708.03778v1cs.CR

TL;DR

Chainspace addresses scalable, auditable execution of user-defined smart contracts over decentralized infrastructure. It combines sharding with the S-BAC atomic commit protocol and evaluates the resulting platform and contracts. The evaluation reports linear throughput scaling up to 350 transactions per second with 15 shards, while the design leaves recovery from malicious-shard inconsistencies for future work.

  • Problem

    Chainspace targets decentralized smart-contract processing that is extensible, scalable, and auditable while supporting privacy-friendly applications.

  • Method

    The paper presents an open distributed-ledger platform that shards object state and transactions, coordinates shards with S-BAC, and uses smart-contract composition and auditing mechanisms.

  • Results

    350 transactions per second were handled with 15 shards, with throughput scaling linearly by up to 22 transactions per second for each added shard.

  • Takeaways & Limitations

    Chainspace offers an open, high-integrity platform for privacy-friendly smart-contract applications with auditable transaction processing.

  • Takeaways & Limitations

    Contract creators must be trusted for both contract code and shard selection, and automatic recovery after malicious-shard inconsistencies remains unresolved.

Abstract

from arXiv · show

Chainspace is a decentralized infrastructure, known as a distributed ledger, that supports user defined smart contracts and executes user-supplied transactions on their objects. The correct execution of smart contract transactions is verifiable by all. The system is scalable, by sharding state and the execution of transactions, and using S-BAC, a distributed commit protocol, to guarantee consistency. Chainspace is secure against subsets of nodes trying to compromise its integrity or availability properties through Byzantine Fault Tolerance (BFT), and extremely high-auditability, non-repudiation and `blockchain' techniques. Even when BFT fails, auditing mechanisms are in place to trace malicious participants. We present the design, rationale, and details of Chainspace; we argue through evaluating an implementation of the system about its scaling and other features; we illustrate a number of privacy-friendly smart contracts for smart metering, polling and banking and measure their performance.

I. INTRODUCTION

Chainspace is an open distributed-ledger platform that combines extensible smart contracts with sharding, Byzantine-tolerant coordination, auditability, and privacy support. Its design separates user-side computation from checker-based validation to support composable, privacy-friendly applications.

  • Platform and contributions: 350 transactions per second were achieved on a 60-core testbed, compared with less than 7 for Bitcoin and 4 for Ethereum.The platform attributes this scalability to sharding across infrastructure nodes.
  • Platform and contributions: Chainspace offers an open platform where anyone can author contracts, provide infrastructure, and access smart-contract calls.It also supports composing contracts from different authors and includes CSCoin for accounting between parties.
  • Platform and contributions: Contract authors designate trusted infrastructure for each contract, providing fine-grained trust control and supporting horizontal scalability.This security model differs from proof-of-work systems with globally replicated state.
  • Platform and contributions: S-BAC is a distributed atomic commit protocol for sharding generic smart-contract transactions across Byzantine nodes while coordinating safety, liveness, and security.The paper evaluates a full implementation of S-BAC under varying transaction loads.
  • Smart-contract model: Chainspace distinguishes procedures that compute from checkers that verify, enabling privacy-friendly smart contracts.Procedures may be randomized or stateful, while checkers are deterministic pure functions that return Boolean validity decisions.
  • Smart-contract model: Transactions operate on typed immutable objects, with procedures consuming inputs, reading references, and producing outputs within a contract namespace.Public locals may refer to objects from different contracts through their identifiers, while outputs require nonempty inputs.

B. System Design, Threat Model and Security Properties

Chainspace organizes infrastructure nodes into shards that manage object state and coordinate transaction decisions through S-BAC. It provides transparency, encapsulation, and non-repudiation, while its strongest correctness guarantees depend on the honest-shard threat model.

  • System design: Shards manage object state, validity, and transaction records, agreeing consistently whether each transaction is accepted or rejected.Accepted transactions change active objects as if executed sequentially, although this is an abstraction rather than global replication.
  • System design: S-BAC runs consensus on committing or aborting transactions in parallel across shards and publishes signed hash-chain checkpoints for auditability.Each checkpoint includes a Merkle-tree evidence block and signed promises from other nodes.
  • Threat model: Chainspace models both honest-shard and dishonest-shard adversaries, with Byzantine consensus requiring at least 3f + 1 nodes per shard under the honest-shard model.When more than f nodes are controlled in a shard, correctness or liveness may no longer be guaranteed there.
  • Security properties: Anyone with a valid object’s identity can authenticate its complete transaction history, and no transaction can be inserted, modified, or deleted from that causal history.This transparency property holds under both honest-shard and dishonest-shard threat models.
  • Security properties: Strict contract isolation prevents one contract from directly interfering with another contract’s objects, while cross-contract calls use defined interfaces.The encapsulation property is stated under both honest-shard and dishonest-shard threat models.
  • Security properties: If invalid or conflicting transactions are accepted under the dishonest-shard model, evidence can identify the responsible parties or shards.This supports detecting failures outside the honest-shard model and enables possible offline recovery mechanisms.

III. THE CHAINSPACE APPLICATION INTERFACE

Chainspace exposes smart-contract transactions through client-generated traces that checkers validate against active objects and dependencies. Its interface supports composition, privacy-friendly proofs, atomicity, consistency, and flexible read mechanisms.

  • Transaction interface: Users submit transactions composed of procedure traces, with client-generated outputs, returns, dependencies, and evidence for checker validation.Transactions may contain procedures from one or more smart contracts and are represented as trace lists.
  • Validity rules: The sequence rule validates traces in order while updating the active-object set before each trace is checked.This induces depth-first validation and execution of trace dependencies.
  • Validity rules: The check rule requires valid dependencies, active inputs and references, contract-compatible object types, and inputs whenever a trace creates outputs.A checker returns true in the resulting active-object context after dependency validation.
  • Transaction semantics: Transactions execute serially and commit or abort atomically, with conflicting transactions sharing active inputs aborted.Committed transactions replace the active-object set; aborted transactions leave it unchanged.
  • Composition: Smart-contract composition passes validated dependency traces to another contract's checker, enabling reusable contract libraries and higher-level applications.Chainspace also supports atomic batches of independent procedures.
  • Reads: Reads cannot introduce inconsistent state because validity checking rejects transactions based on stale object state, while clients may use external databases or indexes for retrieval.The paper does not further address decentralized read-only stores.
  • Privacy: Checkers can verify encrypted or committed state using proofs such as zero-knowledge proofs or SNARKs without revealing secrets.The system relies on checkers rather than procedures, allowing procedures to be randomized, stateful, or side-effecting.

IV. THE CHAINSPACE SYSTEM DESIGN

Chainspace uses infrastructure nodes to manage valid objects and commit only valid transactions, with data structures and distributed protocols supporting integrity and consensus.

  • System design: Infrastructure nodes collectively manage valid objects and ensure that only valid transactions are committed.The system discusses shared and local data structures together with distributed consensus protocols.

A. High-Integrity Data Structures

Chainspace combines cryptographic object and transaction identifiers with Hash-DAGs and hash-chain checkpoints to authenticate history, prevent equivocation, and support partial or full audits.

  • Integrity structures: High-integrity data structures let holders of an object or identifier verify operations leading to its creation and detect node split views.These structures support non-equivocation by making inconsistent state views detectable.
  • Hash-DAG: Objects and transactions form a directed acyclic graph because each object is created by a single transaction trace and consumes earlier active objects.The DAG links objects, transactions, and newly created objects across state transitions.
  • Hash-DAG: Cryptographic identifiers depend on contributing state so that, given an object identifier, its prior transactions, objects, and references can be checked unambiguously.Trace identifiers hash contract, procedure, object identifiers, local state, and dependency identifiers.
  • Object identifiers: Object identifiers hash the creating trace identifier and a procedure-assigned unique output name, making them handles for authenticating an object's full history.Collision resistance prevents forging a different history with the same identifier.
  • Object identifiers: Future transactions cannot recreate an inactive object with the same identifier, so validity checking only needs the active-object list.The paper states this as a security theorem against polynomial-time constrained adversaries.
  • Auditing: Each shard periodically seals accepted and rejected transactions in Merkle-tree checkpoints chained by hashes and signed by shard peers.A checkpoint represents a shard decision when at least f + 1 shard-node signatures support it.
  • Auditing: Partial audits provide signed inclusion evidence or an unknown statement for a transaction, while full audits replay shard history and verify validity, activity, and cross-shard evidence.Full audits download the shard's complete hash chain from its beginning.

B. Distributed Architecture & Consensus

Chainspace shards object state across node sets and uses concerned-node selection plus S-BAC to coordinate Byzantine consensus and atomic cross-shard commits. The protocol combines local agreement with two-phase atomic commit so all involved shards reach a consistent decision.

  • Sharding: A public function φ(o) maps each object to a shard whose nodes manage its state, validity, and transactions consuming that object.The shard must ensure that all nodes eventually record the same committed transaction for the object.
  • Sharding: The concerned-node set Φ(T) contains nodes managing existing input or reference objects used by transaction T but not objects created within T.This set is computed from the union of shards for the transaction's free variables.
  • Sharding: Every contract represented in a transaction has corresponding concerned nodes managing an object of a type from that contract.This property lets validation be distributed across the relevant shards.
  • Sharding: Relevant shards check activity for existing objects and run contract checkers only for contract types managed by their concerned nodes.This distributes rule validation across peers rather than requiring every node to execute every checker.
  • S-BAC: S-BAC provides sharded Byzantine atomic commit by composing Byzantine agreement with atomic commit across the shards involved in a transaction.The protocol is designed to process transactions safely and consistently.
  • S-BAC: Byzantine agreement lets a shard of 3f + 1 nodes agree on a common action sequence despite f malicious nodes and eventually reach a decision.Chainspace uses MOD-SMART's PBFT implementation with VP-Consensus.
  • S-BAC: Atomic commit requires every shard managing transaction-relevant objects to accept before the transaction commits; one rejection causes all shards to reject it.This is implemented as two-phase commit composed with an agreement protocol.
  • S-BAC: During prepare, shards locally agree on commit or abort, broadcast signed prepared messages, and lock relevant objects after a prepared commit.Locks prevent subsequent transactions from using those objects until an accept decision releases or finalizes them.

D. Concurrency & Scalability

Chainspace enables concurrent execution for non-conflicting transactions and scales with additional shards when transactions touch a bounded amount of distributed state.

  • Transactions with disjoint concerned-node sets cannot conflict and may execute in parallel or any order.Conflicting transactions sharing inputs are resolved so that only one is accepted by all nodes through S-BAC.
  • Chainspace capacity grows linearly with added shards when transactions have a constant or sub-linear number of inputs and references.Those inputs must be managed by different nodes so transaction-acceptance load is distributed.

V. SECURITY AND CORRECTNESS

S-BAC provides liveness, consistency, and validity under the honest-shards threat model, ensuring transactions terminate, conflicting transactions are serialized, and only valid transactions commit.

  • S-BAC guarantees liveness, consistency, and validity as the core security properties of Chainspace.These properties underpin correct transaction processing under the honest-shards threat model.
  • LOCALPREPARED requires f + 1 signed shard messages, while ALLPREPARED requires local preparation from every concerned shard and SOMEPREPARED(abort, T) requires one.These predicates determine whether the distributed protocol can commit or abort a transaction.
  • A transaction proposed to at least one honest concerned node eventually commits or aborts.Liveness also prevents locks from being held indefinitely on objects.
  • No two conflicting transactions sharing an input are committed, and a sequential execution exists for all transactions.This is the consistency guarantee under the honest-shards threat model.
  • A transaction commits only if it is valid according to the smart-contract checkers matching its executed traces.Distributed checks cover relevant object states and contract calls; any failed check produces an abort decision.

B. Auditability

Chainspace combines distributed validity checks, signed hash-chain records, and system smart contracts to support auditability, shard management, contract management, and abuse-resistant operation.

  • If a shard violates the honest-shards assumption, auditors can detect inconsistencies and attribute them to specific shards or nodes.The system maintains enough auditing information for this attribution.
  • Honest shards propose commit only when object-state and contract-checker validity rules pass; otherwise they propose abort.A dishonest shard may emit arbitrary proposed messages, which auditing mechanisms can later assess.
  • A malicious shard introducing an invalid transaction or object into honest-shard state can be detected through a full system audit.The audit re-executes transactions and checks cross-shard compatibility of signed evidence.
  • Signed hash-chain checkpoints and signed proposed(T,*) statements provide non-repudiable evidence whose inconsistency identifies misbehavior.Digital signatures allow incompatible records to be attributed to the dishonest shard.
  • System smart contracts implement high-integrity data structures and policies for shard management, contract creation, auditing, and access control.Chainspace instantiation combines S-BAC nodes with these system contracts.
  • The initial ManageContracts implementation does not support contract updates, leaving more complex contract-management definitions for future work.The first implementation hardcodes ManageShards and ManageContracts.
  • CSCoin tracks value through signed account objects and can be composed with other procedures to require payment for transaction processing.Transfer outputs local return information that calling contracts can use conditionally.

B. Application level smart contracts

Chainspace demonstrates privacy-friendly application contracts for smart-meter billing and voting, separating public verification from secret inputs or encrypted computations.

  • The application examples show how Chainspace can implement privacy-friendly smart contracts with advanced privacy mechanisms.The section focuses on smart metering and decision-making applications.
  • Smart-Meter Private Billing: SMet implements private smart-meter billing using meter, reading, and bill procedures.Its checker verifies commitments and tariffs without receiving the secret readings.
  • A Platform for Decision Making: SVote represents elections with vote and tally objects, using encrypted votes, signatures, and zero-knowledge proofs.The contract prevents repeat voting by removing each voter's public key after a verified vote.
  • A Platform for Decision Making: SVote.tally threshold-decrypts aggregated votes and outputs the election result with a proof of correct decryption.The SVote contract is approximately 400 lines.

VII. IMPLEMENTATION & EVALUATION

The Chainspace prototype implements smart-contract execution, S-BAC coordination, and Byzantine consensus, then evaluates scalability, latency, and contract execution costs under varied configurations. Throughput scales with shards, while larger transactions and shards reduce throughput and privacy-preserving contracts incur cryptographic costs.

  • Implementation: The prototype comprises a Python contracts environment and Java node implementation, with S-BAC clients connecting users to Chainspace through an HTTP API.Nodes verify object status, run isolated contract checkers, and initiate S-BAC using BFT-SMART.
  • Scalability: 22 transactions per second is the average throughput increase for each added shard with four nodes per shard and one-input transactions.Random hash-based input assignment spreads processing load across shards.
  • Scalability: 1.6 transactions per second is the average throughput reduction for each node added to a shard when using BFT-SMART with 3f + 1 fault tolerance.The bottleneck is the response latency of the f + 1th node with the highest response time.
  • Scalability: Transaction throughput decreases asymptotically as inputs per transaction increase, stabilizing at around 40 transactions per second in the five-shard experiment.More inputs can touch more shards, requiring S-BAC coordination among them.
  • Latency: Client-perceived latency is measured from submission until a commit or abort decision under varying transaction loads, using two shards with four nodes each.The comparable one-input configuration has an average throughput of 75 1-input transactions per second.
  • Smart Contract Benchmarks: SVote is more expensive than the other benchmarked contracts because it extensively uses zero-knowledge proofs and advanced cryptography.Its operations include election creation, voting, and tallying, with measured execution costs reported for each procedure and checker.

VIII. LIMITATIONS

Chainspace identifies limitations involving shard trust, recovery after malicious behavior, checker fees, and contention-induced transaction aborts. These constraints are acknowledged as areas requiring assumptions, design trade-offs, or future work.

  • Shard trust: Integrity depends on every shard managing contract objects containing at most f faulty nodes, making shard selection a contract-specific trust assumption.Users must trust contract creators both for auditable code and for the publicly visible choice of shards.
  • Recovery from inconsistency: Malicious shards can be detected and traced through auditing, but the best automatic recovery strategy after inconsistency remains unresolved.Possible responses include forking, selecting a canonical version, patching past transactions, or agreeing on a minimal consistent state.
  • Checker economics: Checker validation can be costly, while Chainspace’s flat SCCoin fee does not vary with checker cost or complexity.Ethereum instead charges gas according to contract-procedure execution cost, at the cost of implementing its own virtual machine and language.
  • Contention: Under high contention for the same object, S-BAC’s aborted-transaction rate rises because it implements a variant of optimistic concurrency control.Existing distributed-systems strategies such as ordered object locking are not immediately applicable to the Byzantine setting.

IX. COMPARISONS WITH RELATED WORK

Related systems achieve scalability, strong consistency, privacy, or smart-contract functionality through different architectural choices, while Chainspace combines open participation, generic smart contracts, sharding, atomic cross-shard coordination, and auditability. The paper positions Chainspace as a scalable alternative to permissioned platforms and unscalable fully peer-to-peer systems.

  • Blockchain scalability: Bitcoin’s 1MB blocks and 10-minute intervals cap throughput at about 7 transactions per second, whereas Visa averages 2000 transactions per second and confirms within seconds.Visa’s throughput can peak at 56,000 transactions per second.
  • Sharded ledgers: OmniLedger scales a cryptocurrency ledger across shards and uses atomic commit, but it cannot support generic smart contracts.Its cross-shard commit is client-driven: shard leaders return proofs to the client, which coordinates completion.
  • Sharded ledgers: Elastico’s throughput scales almost linearly with network size, but the system cannot process multi-shard transactions.Nodes are partitioned into committees, each managing a subset of transactions.
  • Permissioned systems: RSCoin offers linearly scaling throughput and low communication overhead, but remains permissioned and cannot support generic smart contracts.The central bank controls monetary supply and authorizes the mintettes managing transaction and coin subsets.
  • Strong consistency: ByzCoin, PeerConsensus, and Algorand replace probabilistic guarantees with strong consistency, using consensus mechanisms that differ from Chainspace’s sharded smart-contract architecture.Their designs include communication-tree consensus, miner voting, or randomly selected nodes running Byzantine fault-tolerance protocols.
  • Smart-contract platforms: Hyperledger Fabric is a permissioned consortium blockchain whose smart contracts have designated endorsers, while Chainspace is presented as an open system.Chainspace allows anyone to author contracts, provide infrastructure, and access contract calls, including composition across authors.
  • Smart-contract platforms: Ethereum’s every-node transaction processing limits scalability, whereas Chainspace shards execution and reports linear throughput scaling of up to 22 transactions per second per added shard.The reported evaluation reached 350 transactions per second with 15 shards.
  • Smart-contract platforms: Chainspace supports smart contracts written in any language when checkers are pure functions, and its evaluation distinguishes it from industrial systems without empirical performance results.The paper also frames Chainspace as offering high-integrity, transparent processing through an evaluated open ledger platform.
Loading 1708.03778v1…