But with crypto currency, and replacements for the corporate form, we want to solve this problem in ways that prevent someone powerful from capturing the system.
Let’s work through the evolution of this problem.
The original mechanism in financial cryptography is the simple client-server or trusted third party (like SOX), which is to say that the issuer of a double-spendable value like a coin runs a single server that mediates the double spends. Typically, the requests are queued up on a first in, first out (FIFO) basis, which is standard in databases these days.
Replicated servers became the in-thing typically for purposes of reliability. For example, the early NASA space shuttles had a voting ring of 3 primary IBM mainframes (and a couple of standbys). On every important act in a voting circle, a majority would win, and a minority could be disconnected and replaced. Early simple majority voting schemes proved to be a lot of trouble, and now the ruling buzzwords are Paxos and PBFT (practical byzantine fault tolerant), but do note that behind them there are lashings of Lamport, theory, bickering Byzantine Generals, PhDs, papers and Turing Prizes, oh my!
Trouble is that the various Byzantine Generals Solutions assume that we know who the generals are. And the mechanism that we use to decide who the Byzantine generals are is going to be subject to centralized attack.
Bitcoin is a brilliant and elegant solution because it opens our thinking to the possibility of fully distributed applications, with money. But Proof Of Work burns up energy to the value that the market can bear, which amounts to a horrible tax on the entire value of the currency (as of time of writing, 4% on Bitcoin, and 11% on Ethereum, big ouch!) and as the Bitcoin chain moves to a fee base this means fees will bite hard, lifting Bitcoin out of reach of most people. High rewards and the rising price also resulted in economies of scale for mining, resulting inevitably in the concentration of miners. Although the system itself happily carries on, a perverse consequence of the censorship-resistant design is that the power of censorship now rests in the hands of about a dozen businesses, with most in one country that is not famous for resisting the urge to censor.
Trouble with proof of work is that lot of money and power is wasted on pointless work.
Right now, Bitcoin is using more electricity than Ireland and minting several billion worth of new currency to process fewer transactions than a moderately busy CostCo. Obviously, blockchain should work on proof of stake.
Proof of work, to be secure, requires a great deal of work. A great deal of work is going to be inherently expensive, and if you try to keep the cost down to something reasonable, double spending attacks become feasible.It was observed by someone (?) that we could simply replace the voting-with-CPU with voting-with-value in order to choose who makes the decision on (the next block of) double-spends. After all, the blockchain precisely establishes who owns what currency, and those who have more skin in the game are more likely to preserve the system, so it is an aligned bias.
I have proposed the following system.
Stake is registered with peers, of which there are a few hundred, which tend to be very large machines with very high bandwidth connections, but stake is owned by clients, who are hosted by peers. Clients tend to be small machines with low storage and low bandwidth connections. Client signatures can move stake from one peer to another. Stake is client money, so that power is ultimately in the hands of the clients, though a peer somewhat resembles a bank from the point of view of clients, and banks tend to acquire dangerously great and disruptive power.
We use Merkle-patricia to somewhat limit the power of the peers over the clients.
Paxos protocol with peers holding fifty percent of stake get to decide on which transactions are committed and which are rolled back.
I also have a plan for making this system anonymous, through transaction pooling, where each transaction is a pool of payments made by several public keys to several other public keys, and the block chain does not reveal which key in the pool were paying which other key in the pool, just the total going in and out, but I intend to publish the full details when I have something working.
Bitcoin payments are pseudonymous, but when money goes in and out of the system, apt to connect pseudonyms to true names, and when bitcoin goes from one nym to another, reveals connections between nyms. Pooling would hide connections between nyms, because you would not know which of the many nyms in the pool was paying which of the many other nyms in the pool.
Because the pools cannot be very large, and will often be quite small, this still leaks some information, giving people trying to follow the money clues and hints, but it leaks far less information than the bitcoin blockchain.
When we look at Bitcoin’s current state of a dozen or so well-known mostly Chinese miners, it is clear that they are all known, to us and to each other, and they can and do communicate. When we get to mining pools the size of today’s country-warming rigs, Bitcoin’s assumption of psuedonymity for miners becomes tenuous – just follow the electricity. Or go to any bitcoin scaling conference.
The miners could easily collude to do bad things. Of course they have no strong incentive to collude to do bad things, since that would damage the value of the currency they mine, but they could easily be forced by the state to do bad things in favor of the state. In particular, and especially, the state is likely to disfavor strong anonymity in the crypto currency. And we want to implement a crypto currency with strong anonymity
Each transaction has many inputs from many participants, and many outputs to many participants, and a possibly hostile outside party cannot tell which input came from which participant, and which output went to which participant.
The hostile outside observer might well observe that an output from one transaction appeared as an input in another, and notice that these transactions had only one participant in common, and conclude that was the participant received that output, and subsequently spent it in the second transaction. But that participant may well have several nyms and does not have to have the same identity receiving the transaction as spending the transaction. Likely the pastor will use one identity for receiving his Church stipend, and another identity for paying off the girlfriend who is blackmailing him, and another identity for purchasing grey market drugs over the internet.
All value will be owned by client wallets hosted by peers. A client wallet identity is UserName@PeerName And the client may well use several servers, and have a username on each server, each server being a peer in the crypto currency system, thus crypto currency received on one server will be impossible to connect to crypto currency spent on another server.
Each transaction input/output has its own unique public key that identifies it. If most transactions have only a single payer and single recipent, it is possible observe the flow of transactions and associate a group of transaction input/output with a particular user, and with transactions between those particular users.
If each transaction has several payers and several recipients, you cannot track this on a strictly peer to peer system. But a peer to peer system has scaling problems, so I envisage a system that at scale has a few hundred to a few thousand peer, but billions of clients, which creates the possibility of tracking client logins. If, however, each client has several logins, then a hostile outsider cannot track the flow of money, nor know how much money a particular client has. A hostile outsider cannot figure out which client knows the private keys corresponding to the public keys of the transaction input/outputs.
We instantiate the ledger as a Merkle-patricia dac. Each new block of the block chain contains the root of a new Merkle-patricia dac incorporating all the previous Merkle-patricia dacs, and consists of those nodes of the trie that are new and different from the previous Merkle-patricia dac.
The entire state, and entire history of the system is represented by the hash of the root node, and any time a peer makes a claim about some fact of the block chain to a client, it gives the client the chain of hashes leading to the root, proving that this view of what public keys own what transaction outputs and what human readable names is the consensus view.
The new block references all the old trees in a binary trie, so that if any client has the root of an old block, a proof that the new block is derived from the old is only log (current block number – old block number)long.
The client does not verify that the new block is validly derived from the old block, for to verify that it was derived in accordance with the rules requires the entire block chain. Each peer verifies this, which means each peer has to download the entire block chain, and the client relies on the peer with whom it has a login relationship.
Suppose one peer tells one client one story, claims that the consensus root hash is one thing, and another peer tells another client a different story, claims that the consensus root hash is another thing. Then, when the two clients attempt to interact, things will break.
That things do not break guarantees that the peers are all subscribing to the one consensus, that everyone sees the same history of every transaction, and that everyone agrees on which public key is associated with which human readable name, but does not tell us which proposed new block should become the consensus block. It tells us that the past block chain is good, but does not tell us how to add new blocks to the block chain.
Suppose a transaction input is double spent, appears in two different transactions. One transaction must succeed for everyone, and the other fail for everyone. Suppose a human readable name is assigned to two different public keys. One assignment must succeed for everyone, and the other fail for everyone. But which one? And how does everyone know it succeeded or failed?
We will employ the Paxos protocol with distinguished proposer (leader)
Peers have stake in proportion to the crypto currency controlled by their clients. The consensus view has to be approved peers by holding the majority of the stake controlled by active peers who have recently provided evidence of liveness.
Obtaining a consensus is potentially slow and costly, and apt to produce very bad outcomes. How does a group act as one?
The way humans do it, when they do it successfully, is that they choose a leader. They keep an eye on him, but they don’t jostle his elbow. They follow him, until something goes badly wrong. And when things are working, it is as if the leader owns the group. But when something goes bad, then they choose a new leader, and it is then revealed he does not own the group. And that is how the Paxos protocol works. The Paxos protocol is computers on the network coordinating their actions by similar mechanism. Every peer checks the new block, and then votes for it, and if there is nothing terribly wrong, the new block becomes effective when it gets votes represent the majority of stake held by clients with a peer that is active on the network. Normally they only check the block provided by the leader. If the leader goes down (perhaps someone pulled tbe plug, or its network connection went down) then there is a complex, and potentially slow, process for choosing a new block, and with it a new leader.
When all goes well, every peer assumes that the peer that set the consensus last time will succeed in setting the consensus this time, and if there is nothing wrong with the proposed consensus, if it is derived from the previous consensus in accordance with the rules, accepts it as the consensus. When this works, it is as fast as a fully centralized system. And large scale fully centralized systems have to implement failover and multi homing anyway, so even when it fails, is not enormously slower than a fully centralized system that suffers a failure.
If the leader goes down, perhaps due to hardware failure or for maintenance, or there is excessive packet loss on the internet, or if the leader turns evil and proposes a consensus that differs from the rules, is not validly derived from the previous Merkle-patricia dac, then the Paxos protocol with distinguished proposer becomes excruciatingly complex, and potentially slow. But most of the time, it is simple and fast as a simple fully centralized system with redundancy.
On initial release there are only going to be a few peers and a few wallets, but the architecture of the system has to be capable of scaling to billions of wallets and hundreds of peers
All wallets will be client wallets, and will only hold their own transactions and a small part of the block chain. At scale their will be billions of wallets, a few hundred or a few thousand peers, each peer storing all the data of the block chain and checking that subsequent blocks are validly derived from past blocks, and one leader, that changes when necessary.
The stake of each peer, its voting power in the Paxos consensus process, its weight in the Paxos consensus process, will be approximately proportional to the weight of stake of its client wallets..
Each wallet needs to be able to prove to itself and to other wallets that it transacts with that the transactions that it cares about are valid. To this end it receives a chain of hashes leading to the root of the blockchain, a few branches of the very large Merkle-patricia tree.
These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License