107 lines
6.9 KiB
Markdown
107 lines
6.9 KiB
Markdown
---
|
||
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 percent 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.
|