What it means
A larger network is not automatically a faster network, because if every participant must repeat the same validation and storage work, adding participants can improve resilience without multiplying transaction capacity. Sharding changes the allocation of work, not simply the number of computers.
The partition rule determines which shard handles a record or transaction, so a design might assign accounts or transaction inputs to different groups while the particular protocol determines what each group stores, validates and communicates. This is different from keeping additional copies of the same information, since replication repeats data to improve availability or resilience while partitioning divides responsibility, and a sharded design can still use replication within each partition.
Transactions contained within one shard are simpler to coordinate than transactions involving several. A payment between accounts assigned to different shards needs a process that connects their state changes, otherwise one side could recognise a transfer while another rejects it.
The academic paper Divide & Scale treats atomic cross-shard execution as a consistency requirement, where atomic means the participating changes commit together or abort together. It does not mean that every transfer is instantaneous.
Coordination has a cost, as messages, proofs and waiting between shards consume resources and can reduce the gain from parallel processing, so a workload dominated by cross-shard activity can behave differently from one mostly contained within individual shards. Security also changes, because dividing validators into smaller groups creates questions about the concentration of malicious participants in any one group.
A large total network does not by itself prove that every shard has an adequately protected validator set. The business case should also distinguish throughput, latency and finality, since throughput measures how much work completes over time while latency concerns the delay for one request.
A large headline transaction rate does not establish how soon a particular payment is safe to treat as final. For a non-finance manager assessing a payment or recordkeeping project, request tests that resemble the actual workload, including cross-shard transfers, uneven demand and failures, rather than only easy transactions inside separate partitions.
Identify what happens when a participating shard stops responding. Sharding is an architecture choice, not proof of cheaper transactions or better service.
Compare operating costs, recovery procedures and the reliability of completed records. A useful design must preserve the business meaning of a transaction while increasing capacity.
In practice
Real-world examples.
Example
A fictional ledger divides customer accounts across four shards. Transfers within one group can be processed without involving every other group. A transfer to an account in another shard needs additional coordination.
Example
A business tests a network using only local transactions and sees high throughput. Its normal workflow frequently transfers value between partitions. The manager repeats the test with that workload before relying on the headline result.
Example
A shard becomes unavailable during a transfer. The project team checks whether both sides remain pending or are consistently cancelled. A debit that becomes final without the matching credit would defeat the payment's purpose.
Formula
Calculation
There is no universal sharding performance formula. For a simplified capacity illustration, suppose four independent shards each complete 250 local transactions per second. Their combined local capacity would be 4 x 250 = 1,000 transactions per second before shared bottlenecks and coordination costs.
If an illustrative test achieves 700 completed transactions per second, that is 700 / 1,000 = 70% of the simple sum. The workload and cross-shard activity can explain part of the gap. This is not a guaranteed production forecast.Case study
Seen in the real world.
This case study is fictional and illustrative. A distributor considers a sharded ledger for supplier settlements. Its demonstration uses independent transfers within each partition, but many real suppliers would receive payments from customers assigned to other partitions. The operations manager requests a second test with representative cross-shard payments and an unavailable participant group. The team records completed transfers, pending transfers and recovery time separately.
It refuses to call a transaction successful merely because the sending side accepted it. The revised test shows less capacity than the first demonstration, but gives the company a clearer basis for planning. The decision now depends on consistent completion and recovery as well as speed. Dividing work is useful only if the whole payment still works.
Watch out
Common mistakes.
- Assuming that adding shards multiplies usable capacity without communication costs or shared bottlenecks.
- Treating the total number of validators as proof that every individual shard has the same protection.
- Counting one side of a cross-shard transfer as completed before the required changes are consistently settled.
Questions
People also ask.
Is sharding the same as replication?
No. Partitioning divides responsibility, while replication keeps additional copies. A system can use both.
Does sharding guarantee lower transaction fees?
No. Capacity, workload, operating costs and the particular fee mechanism affect the result.
Why do cross-shard transactions matter?
They connect changes handled by different groups. Consistency requires that the connected transaction does not leave only part of its intended result completed.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%