forked from cheng/wallet
34 lines
2.8 KiB
Markdown
34 lines
2.8 KiB
Markdown
|
---
|
|||
|
|
lang: en
|
|||
|
|
title: Crypto Currency as a wide area distributed database
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
::: myabstract
|
|||
|
|
[abstract:]{.bigbold}
|
|||
|
|
In [Scalable and private blockchain](scalability.html){target="_blank"} I note that the proposed blockchain structure maps directly to sql, and is often easiest to design if one thinks about it as if an sql database. Eventually we want everything in the world that relates to property ownership, contracts, agreements, financial relationships, and ongoing disputes, that Ann chooses to make accessible to Bob, accessible through sql code running on Bob's computer, and included in the pre-image of the blockchain root hash, so that Ann can prove to Bob that she is showing the same thing to Bob as to everyone else, and is not re-inventing the past, it is the same thing, or validly derived from, what she always showed.
|
|||
|
|
:::
|
|||
|
|
|
|||
|
|
Much of this material is shamelessly plaigarized without [attribution.](http://docplayer.net/14501083-Blockchain-throughput-and-big-data-trent-mcconaghy.html)
|
|||
|
|
|
|||
|
|
Bitcoin has dangerously few miners, subject to dangerously few political authorities, and miner interests are insufficiently aligned to currency user interests.
|
|||
|
|
|
|||
|
|
[sovereign corporation]:social_networking.html#many-sovereign-corporations-on-the-blockchain
|
|||
|
|
{target="_blank"}
|
|||
|
|
|
|||
|
|
The solution is to create a crypto currency that relies on weight of share, rather than weight of processing power. Such a currency is equivalent to a [sovereign corporation], or rather the easily traded shares of a [sovereign corporation]. And independently of whether we need yet another crypto currency, we need sovereign corporations.
|
|||
|
|
|
|||
|
|
The blockchain is a database, as are modern Big Data NoSQL and NewSQL databases. They re all distributed. Distributing a database by making a full copy on every node scales extremely poorly. Distributed DBs need a consensus algorithm
|
|||
|
|
|
|||
|
|
We need a sharded [crypto currency](./crypto_currency.html{target="_blank"}), that can scale to arbitrary sizes.
|
|||
|
|
|
|||
|
|
Nakamoto consensus is a database that sacrifices consistency for availability. Suppose Sam the Scammer double spends the same money to Alice and Bob:
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
After an unpredictably long time, it will eventually reach a consensus in favour of Bob, or in favour 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.
|
|||
|
|
|
|||
|
|
[Recursive snarks]:scalability.html
|
|||
|
|
{target="_blank"}
|
|||
|
|
|
|||
|
|
[Recursive snarks] allow sharding within a group where the nodes do not trust each other
|