b87864d922
Christian and moralistic. Explanation of "Proof of share" added to crypto_currency.md where no one is likely to find it. Need to create document on consensus.
39 KiB
The coin to invest in, the coin that I will invest in both in money and as a software contributor, will solve the scaling problem, will be capable of scaling all the way to wiping out the US$ as a world currency. It will have integral support for sidechains with payments out of one sidechain to another sidechain being endorsed by sidechain signature which can be generated by arbitrarily complex rules idiosyncratic to that sidechain provided that conformity to the rules has verification of bounded computational time that the central chain can evaluate. It will have an efficient system for securing history in which Merkle trees do not grow to enormous depth, so that it is possible to efficiently verify any one small part of history without needing to verify all transactions that have ever taken place. (Because scalability implies we abandon everyone verifying everything down to the last byte.)
It will be decentralized in the sense that if the police grab every single major contributor, software writer, and server, they cannot change the rules and make the currency act differently, they can only seize the money of the people that they have grabbed.
A Merkle tree is a tree where every node contains the hash of its immediate children. Thus the hash of the root of any subtree guarantees the contents of all its descendants, just as the hash of a file guarantees the contents of the entire file.
This means that we can keep on adding to the tree, while keeping the past immutable, which is a useful feature for tracking who owns what, and who owes what. If many people see the current hash at time X, you cannot change details about the past of time X without revealing what you have been up to.
Any tree can be severely unbalanced, for example a binary tree where every node has a right hand child, and very few nodes have a left hand child, in which case the depth of the tree is approximately proportional to the total number of nodes in the tree – and the tree grows to enormous depth when the total number of node is enormous.
Or it can be approximately balanced, in which case the depth of the tree is approximately proportional to the log of the number of nodes, which is always a reasonably small number even if the number of nodes is enormous.
And a hash that testifies to every transaction that anyone ever did is going to be the hash of an enormous number of nodes. But if it is at the root of a tree of moderate depth, then we can validate any part of the tree for conformity with the rules without validating the entire tree for conformity to the rules.
A blockchain is a Merkle tree that is chain like, rather than tree like. Its depth grows linearly with its size, thus in time it becomes very deep. Every node must store or at least have processed and summaried, the entire tree. Thus if many equal nodes, cost of adding transactions is proportional to the number of nodes
Thus, if we want a decentralized system, this can get very expensive.
We want a system that can resist state power, a system where if the state grabs a few individuals and coerces them, it can seize their money, and perhaps all the money that they manage for other people, but cannot seize the entire system. If it wants to grab control of everyone’s money, has to grab everyone, or at least grab most people. Thus reducing the cost by having a few people authorized to validate the blockchain is a bad option, since the state could grab those people, or those people could conspire together to scam everyone.
A blockchain runs on a set of nodes, each of which may be under the control of a separate company or organization. These nodes connect to each other in a dense peer-to-peer network, so that no individual node acts as a central point of control or failure. Each node can generate and digitally sign transactions which represent operations in some kind of ledger or database, and these transactions rapidly propagate to other nodes across the network in a gossip-like way.
The way bitcoin works
Each node independently verifies every new incoming transaction for validity, in terms of: (a) its compliance with the blockchain’s rules, (b) its digital signature and (c) any conflicts with previously seen transactions. If a transaction passes these tests, it enters that node’s local list of provisional unconfirmed transactions (the “memory pool”), and will be forwarded on to its peers. Transactions which fail are rejected outright, while others whose evaluation depends on unseen transactions are placed in a temporary holding area (the “orphan pool”).
At periodic intervals, a new block is generated by one of the “validator” nodes on the network, containing a set of as-yet unconfirmed transactions. Every block has a unique 32-byte identifier called a “hash”, which is determined entirely by the block’s contents. Each block also includes a timestamp and a link to a previous block via its hash, creating a literal “block chain” going back to the very beginning.
Just like transactions, blocks propagate across the network in a peer-to-peer fashion and are independently verified by each node. To be accepted by a node, a block must contain a set of valid transactions which do not conflict with each other or with those in the previous blocks linked. If a block passes this and other tests, it is added to that node’s local copy of the blockchain, and the transactions within are “confirmed”. Any transactions in the node’s memory pool or orphan pool which conflict with those in the new block are immediately discarded.
Every chain employs some sort of strategy to ensure that blocks are generated by a plurality of its participants. This ensures that no individual or small group of nodes can seize control of the blockchain’s contents. Most public blockchains like bitcoin use “proof-of-work” which allows blocks to be created by anyone on the Internet who can solve a pointless and fiendishly difficult mathematical puzzle. By contrast, in private blockchains, blocks tend to be signed by one or more permitted validators, using an appropriate scheme to prevent minority control.
Depending on the consensus mechanism used, two different validator nodes might simultaneously generate conflicting blocks, both of which point to the same previous one. When such a “fork” happens, different nodes in the network will see different blocks first, leading them to have different opinions about the chain’s recent history. These forks are automatically resolved by the blockchain software. In bitcoin, the probability of this conflict continuing drops rapidly and exponentially, but never goes to zero.
This document is licensed under the CreativeCommons Attribution-Share Alike 3.0 License