LibraryScaling2017Design paperCorpus record
Chainspace: A Sharded Smart Contracts Platform
Chainspace. Mustafa Al-Bassam, Alberto Sonnino, Shehar Bano, Dave Hrycyszyn and George Danezis.
Chainspace shards objects, and a transaction names the objects it will read and write so the shards involved can run a distributed commit.
A reading of the public paper. Not a copy, not a benchmark, and not a claim about any later network.
A sharded contract system should say what the unit of state is and what happens when a call spans two units.
The five-minute read
The defect
Sharding payments is easier than sharding contracts, because a contract call can touch objects that live on different shards.
The proposal
Chainspace shards objects, and a transaction names the objects it will read and write so the shards involved can run a distributed commit.
Objects, not only accounts, are the unit.
The transaction declares its footprint before it runs.
The bound
The paper is not a later production shard.
One action, walked through
- Place objects on shards.
- A transaction lists the objects it needs.
- The involved shards commit or abort together.
- What is the commit across shards?
The argument, unpacked
What the paper is for
A sharded contract system should say what the unit of state is and what happens when a call spans two units.
What happened after
Later sharded contract systems inherit the footprint idea more often than they inherit the whole protocol.
What has to be true
- The paper is not a later production shard.
- Declared footprints do not help if the implementation lets a call touch an undeclared object.
- Auditability is not the same as a user checking every shard themselves.
What happened after the paper
Later sharded contract systems inherit the footprint idea more often than they inherit the whole protocol.
What to check before you use the idea
- What is the object?
- What is the commit across shards?
- How is a lying shard detected?
Terms
- Object
- A piece of contract state with a home shard.
- Footprint
- The set of objects a transaction declares it will touch.
The problem the paper names
Sharding payments is easier than sharding contracts, because a contract call can touch objects that live on different shards.
What the design proposes
- Objects, not only accounts, are the unit.
- The transaction declares its footprint before it runs.
- A dishonest shard should be detectable by an audit in the paper's design.
How the mechanism is specified
- Place objects on shards.
- A transaction lists the objects it needs.
- The involved shards commit or abort together.
What this page does not treat as proven
- The paper is not a later production shard.
- Declared footprints do not help if the implementation lets a call touch an undeclared object.
- Auditability is not the same as a user checking every shard themselves.
Why a venture studio still reads it
A sharded contract system should say what the unit of state is and what happens when a call spans two units.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.