forked from cheng/wallet
70 lines
6.7 KiB
HTML
70 lines
6.7 KiB
HTML
|
<!DOCTYPE html>
|
|||
|
|
<html lang="en">
|
|||
|
|
<head>
|
|||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|||
|
|
<style>
|
|||
|
|
body {
|
|||
|
|
max-width: 30em;
|
|||
|
|
}
|
|||
|
|
p.center {
|
|||
|
|
text-align:center;
|
|||
|
|
}
|
|||
|
|
</style>
|
|||
|
|
<link rel="shortcut icon" href="../rho.ico">
|
|||
|
|
<title>Crypto Currency on wide area distributed database</title>
|
|||
|
|
</head>
|
|||
|
|
<body>
|
|||
|
|
<p><a href="./index.html"> To Home page</a> </p>
|
|||
|
|
<h1>Crypto Currency on wide area distributed database</h1><p>
|
|||
|
|
|
|||
|
|
|
|||
|
|
Much of this material is shamelessly plaigarized without <a href="http://docplayer.net/14501083-Blockchain-throughput-and-big-data-trent-mcconaghy.html">attribution.</a></p><p>
|
|||
|
|
|
|||
|
|
Bitcoin has dangerously few miners, subject to dangerously few political authorities, and miner interests are insufficiently aligned to currency user interests.</p><p>
|
|||
|
|
|
|||
|
|
The solution is to create a crypto currency that relies on weight of stake, rather than weight of processing power. Such a currency is equivalent to a crypto corporation, or rather the easily traded shares of a crypto corporation. And independently of whether we need yet another crypto currency, we need crypto corporations.</p><p>
|
|||
|
|
|
|||
|
|
Hence my interest in threshold signatures that do not require a "trusted" dealer.</p><p>
|
|||
|
|
|
|||
|
|
Because of shareholder ignorance, and scaling law problems with enormous thresholds, I envisage that ordinary shareholders, or rather the laptops and cellphones of ordinary shareholders(wallets), would grant their voting rights to a rather small number of board members (massive server farms in the cloud). Every time you do a transaction through some web server, the recipient of the shares(currency) by default revocably grants his voting rights to whatever web server the recipient uses, thus reducing the scale problem to a moderate number of large entities with adequate connectivity and processing power. From time to time one board member (server farm) is elected CEO (leader for the Paxos protocol) If it goes down, loses connectivity, loses too many packets, or engages in Byzantine deviation from the Paxos protocol (possibly as a result of being raided by the cops for money laundering), they elect a new one after twenty seconds or so. </p><p>
|
|||
|
|
|
|||
|
|
“There is only one consensus protocol, and that is Paxos” -Mike Burrows, “all other approaches are just broken versions of Paxos. The Paxos protocol, conceived by Leslie Lamport, is famously subtle and a bit difficult to understand.”</p><p>
|
|||
|
|
|
|||
|
|
The Paxos protocol is not actually a solution to the consensus problem. Rather it is a tool, a necessary step in the larger solution to any one particular consensus problem, one step of a great many.</p><p>
|
|||
|
|
|
|||
|
|
The blockchain is a DB, as are modern Big Data NoSQL and NewSQL DBs. They re all distributed. Distributing a DB by making a full copy on every node scales extremely poorly. Distributed DBs need a consensus algorithm and the Bitcoin consensus algorithm is a horribly broken variant on Paxos. </p><p>
|
|||
|
|
|
|||
|
|
We need a sharded <a href="./crypto_currency.html">bitcoin</a>, that can scale to arbitary sizes.</p><p>
|
|||
|
|
|
|||
|
|
Bitcoin is a database that sacrifices consistency for availability. Suppose Sam the Scammer double spends the same money to Alice and Bob:</p><p>
|
|||
|
|
|
|||
|
|
Immediately afterwards the database might tell you that Sam has not spent the money, or that he has spent it on Alice, or that he has spent it on Bob, or that he spent it on Alice, and then attempted to spend it on Bob, but the attempted spend on Bob was disallowed, or that he spent it on Bob, and the attempted spend on Alice was disallowed.</p><p>
|
|||
|
|
|
|||
|
|
After an unpredictably long time, it will eventually reach a consensus in favor of Bob, or in favor of Alice, but the consensus is unpredictable, the time required to reach consensus could be quite long, and you can never be entirely sure that you are looking at the final consensus.</p>
|
|||
|
|
|
|||
|
|
<p>The Paxos protocol can potentially do better than this, in that it can definitively announce the final consensus, though there may be large delays in getting to it.</p>
|
|||
|
|
|
|||
|
|
<p>The solution is Paxos, sharding, and sidechains. Sidechaining is visible to the user and explicitly organized by the user with some formal and explicit organization with a website, while sharding happens automagically and invisibly. No one has figured out how to sharding automatically in the background without it being possible for some shards to cheat on others.</p>
|
|||
|
|
|
|||
|
|
<p>You can shard within a group where the nodes trust each other to fail only in a non byzantine manner, and we will need such sharding to handle arbitrarily large numbers of transactions. There is no obvious way of sharding without a shard being potentially capable of cheating either some people in the shard, or else other shards.</p><p>
|
|||
|
|
|
|||
|
|
This suggests a system where nodes belong to an indentifiable entity, and nodes belonging to the same entity trust each other to only fail in a non byzantine manner, while suspecting nodes belonging to a different entity of potentially byzantine failure.</p><p>
|
|||
|
|
|
|||
|
|
Google bigtable uses chubby, which uses Paxos. Bigtable does pretty much what a currency database would need to do.</p><p>
|
|||
|
|
|
|||
|
|
The variant of Paxos you need is Generalized Byzantine <a href="https://infogalactic.com/info/Paxos_(computer_science)#Multi-Paxos">Paxos</a> (nearly all operations commute) You probably also want semi stable leadership and a distinguished learner (normally the last guy to resolve a dispute resolves the new dispute.) </p><p>
|
|||
|
|
|
|||
|
|
Sharding is grouped by payments made, rather than payments received, since receiving a payment always commutes</p>
|
|||
|
|
|
|||
|
|
<p>To reduce coordination costs, we would like the global hash to be unchanged under commutative transactions. The global hash should reflect the presence, absence, or failure of transactions, not their precise order.</p>
|
|||
|
|
|
|||
|
|
<p>We need consensus on generating a bounce, which is a rare event. What about the problem of attributing a time bucket to a transaction. I guess we generate the checksums for a time bucket sometime after that bucket, and transactions that do not make it into the appropriate bucket get discarded by consensus with a recommendation to retry.</p>
|
|||
|
|
|
|||
|
|
<p>Each shard should be an accounting entity, tracking the total transferred between each shard – which should follow from commutativity – should be a detail of optimizing for commutativity.</p>
|
|||
|
|
|
|||
|
|
<p>See also <a href="http://www.cs.yale.edu/homes/aspnes/pinewiki/Paxos.html">failure detection</a> – we would like to know what entities are currently responsive and who was leader and designated learner last time.</p>
|
|||
|
|
|
|||
|
|
<p style="background-color : #ccffcc; font-size:80%">This document is licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">CreativeCommons Attribution-Share Alike 3.0 License</a></p>
|
|||
|
|
</body>
|
|||
|
|
</html>
|