wallet/docs/block_chain_scaling.md

---
title: Blockchain Scaling
---
A blockchain is an immutable append only ledger, which ensures that
everyone sees the same unchanging account of the past. A principal
purpose of blockchain technology is to track ownership of assets on a
ledger that is distributed among a large number of computers in such a
way that it is not vulnerable to alteration, destruction, or loss at any single location.

The peers that determine the consensus on each new block only need to
have the unspent transaction outputs in fast storage, whereupon they
generate a new consensus of unspent transaction outputs. They could
throw away all the transactions as soon as there is consensus on the
current state that is the result of applying those transactions to the previous
state. Or some of them could throw away all the transactions, while others
transfer them to distributed and slow storage.

But this creates the opportunity to inject a fake history with no past
through a fifty one attack.

At scale you have a lot of transactions, a lot of clients, and considerably
fewer peers, so you worry about peers conspiring to quietly introduce new
unspent transactions with no past through the fifty one percent attack.

Any dilution has to take place through a process that leaves clearly in the
blockchain evidence of dilution that everyone can see.  One way to make
sure of this is that when any peer asserts that a transaction set leads to a
mutable state, and another peer does not agree, peers that persistently
agree will never reach consensus with peers that agree, and we get an
automatic fork.

When there are many transactions, the computers constructing the final
consensus hash of the final block, which testifies to the entire immutable
consensus past, are necessarily rather few, rather large, and owned by a
rather small number of rather wealthy people.

To keep them honest, need a widely distributed history of at least the past
few weeks.

We need a large number of people making sure, and able to make sure, that the
history is consistent from day to day, not just from block to block.

Everyone should keep the transactions to which he is a party, and the subset
of the Merkle–patricia tree linking them to the past consensus on unspent
transactions, and to the current consensus of the entire history of the
blockchain, but this is not enough to prevent a 51% attack from injecting new
history with no past.

The full list of unspent transaction outputs needs to be kept locally in very
fast storage sorted and accessed by a primary key that keeps the transaction
approximately in temporal order, so that older, and less frequently needed,
transaction outputs are stored together, and newer and more likely to be
needed transaction outputs are stored together.

As this ledger can potentially grow quite large, it needs to be subdivided
into general ledger and subledgers.  When the general ledger is
maintained on a blockchain, the chain without the subledgers directly on it in
full is known as the mainchain.  Where a subledger, like the mainchain, is
maintained by multiple entities, the subledger is called a “sidechain” The
mainchain contains aggregated and summarized data about the sidechains,
and the sidechains can themselves have sidechains.

Ultimately we want a mainchain that functions like a central bank, with
several hundred peers that function like banks, in that many peers on the
mainchain maintain a sidechain.  Each peer hosts hundreds of thousands of
client wallets.

When the mainchain runs into scaling limits, transactions between
individuals will be pushed down into sidechains.  A transaction between
sidechains will typically have a very large number of inputs from a very
large number of sidechains, and a very large number of outputs to a very
large number of sidechains.  In such a transaction each sidechain usually
provides only one or two inputs, usually one input, and receives only on or
two outputs, usually one output, that one input and one output representing
the aggregate of many transactions with many other sidechains, and each
transaction between two sidechains representing the aggregate of many
transactions between client wallets.

But for an input and an output to or from a sidechain to be reasonably
short, rather than proportional to the number of peers on the sidechain, we
are going to have to have linear chain of signatures,

You make a payment with a client wallet that works like a bill of exchange.
  Your host is a peer on the mainchain.  It sends your bill of
exchange to the other guys host.  What appears on the mainchain is the
root of a Merkle tree of all the bills of exchange, and the settlements
between peers, each such payment being the sum of many bills of exchange, each
such payment representing the Merkle tree of many bills of exchange. 

The mainchain records that each sidechain has such and such an amount of money, and owes such and such an amount of money to its client wallets, but only knows totals over all the client wallets of a sidechain.  Does not know individual client wallets. 

The individual client wallet has a chain of hashes leading to the root hash of the mainchain consensus that proves it has the money.  But the lower levels in this chain of hashes do not appear on the mainchain.

When one client wallet makes a payment to another client wallet, that
payment is final when it is a leaf on the Merkle tree of the consensus hash,
but only the upper nodes of the tree, the aggregate payments between
mainchain peers, appear on the blockchain.

The lower nodes of the tree are held in the sidechains, and the very lowest nodes of the tree are held in the client wallets.

When a transaction between sidechains occurs on the mainchain, the root
of the sidechain Merkle tree is placed or referenced on the mainchain. 
But this does not in itself prove that the sidechain transactions that it
summarizes are valid or authorized. 

If any one sidechain peer in good standing on the sidechain objects to the proposed hash of the sidechain state which is to be incorporated on the mainchain, it can demand that transactions necessary to derive the new hash from values attested to by a recent older hash be lifted from the sidechain to the mainchain, putting up some money for what is in effect a bet that the proposed mainchain transaction cannot be justified by the underlying sidechain transactions.  If the proposed hash of the sidechain state is supported by valid transactions, and the mainchain peers validate the proposed hash, then the peer that insisted on the sidechain data being raised to the mainchain loses its good standing, and has to pay a fee reflecting the cost of pushing all those transactions onto the mainchain. If not, those sidechain peers who signed the proposed, but unsupported, hash lose their good standing and have to pay the costs of pushing all those transactions onto the mainchain.  It should be rare that portions of a sidechain are raised into the mainchain.  Trust, to save bandwidth, storage space, and time, but verify.