97 lines
11 KiB
HTML
97 lines
11 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
<style>
|
||
body {
|
||
max-width: 30em;
|
||
margin-left: 1em;
|
||
}
|
||
p.center {text-align:center;}
|
||
</style>
|
||
<link rel="shortcut icon" href="../rho.ico">
|
||
<title>Development Plan</title> </head>
|
||
|
||
<body>
|
||
<p><a href="./index.html"> To Home page</a> </p>
|
||
|
||
<h1>Development Plan</h1><p>
|
||
First we implement the Merkle-patricia dac – a Merkle dac in which links between items correspond to fields in query.</p><p>
|
||
|
||
We create a command line program that takes an input stream consisting of a collection of bitstreams, where binary is escaped as hexadecimal (\x followed by a stream of hex digits, followed by a space, \b followed by a stream of binary digits, followed by a space.) Bitstreams are terminated by carriage return or line feed, but not by a \x0D or \x0A. (\u must always be followed by exactly four hexadecimal digits) It parses it into records, constructs the hashes of those records, sorts it into a Merkle-patricia tree, and outputs it as a canonical Merkle-patricia tree of records in depth first tree order with leadig tabs indicating tree depth, composed of field values each field being displayed in a format appropriate to that field.</p><p>
|
||
|
||
In the input, leading tabs indicate a bitstream that whose prefix is the preceding (one less tabbed) bitstream. The bitstream always starts off with a schema identifier. A schema identifier is a sequence of bytes with the high order bit set, followed by a byte with the high order bit cleared. Records also typically have a schema identifier for their child records so we can add new kinds of child records.</p><p>
|
||
|
||
Our schema will probably always be byte oriented, but if it is not, we have the \b type for bit fragments.</p><p>
|
||
|
||
We then create a variant that treats any bitstreams that are prefixes of previous bitstreams as queries, and any bitstreams that are affixes of previous bitstreams as errors, and for each query outputs a proof a denial that the query belongs in the tree, the first full value in the tree matching the query, and a proof that that that full value belongs in the tree.</p><p>
|
||
|
||
We also create a variant that can check such a proof.</p><p>
|
||
|
||
We also implement the inverse of this – a client sends in his partial tree, with hashes leading to a hash of the previous value, and the blockchain sends back an amended partial tree, which leads to the current value – which usually proves that the data the client cares about, near the leaves of his partial tree, is unchanged. (the client checks the proof) If it does not prove that, he makes another query to get the new data that he may well care about.</p><p>
|
||
|
||
Then we create one where the records are Zooko identities, and the petnames are, being subject to the proof, authoritative.</p><p>
|
||
|
||
Then we create one where if you query with the private secret, you get the proof for public key. (This has a separate database table linking keys to Zooko identities, implemented in SQLite.</p><p>
|
||
|
||
And one where, for a public key, you get Merkle proof about what network address will serve that public key, or what public key or authoritative petname will serve the network address for that public key.</p><p>
|
||
|
||
Then a simple command line single threaded single client tcp time server, which we test using Putty in raw mode, and a simple command line client to test it, where the client outputs the result then shuts down the connection immediately.</p><p>
|
||
|
||
Then, a simple command line multi client tcp time server, and a simple command line client to test it, where the clients shuts down the connection when the user hits carriage return.</p><p>
|
||
|
||
And then, implement the Merkle-patricia stuff, only with queries over the network between one keyed identity and another.</p><p>
|
||
|
||
And then, implement the same thing, only with key chains over the network, and the capacity to look up rapidly changing keys from an unchanging authority.</p><p>
|
||
|
||
Then, a client that runs a unit test when executed with the command line argument <code>test</code>, and displays all test results <code>test v</code>, only fail results <code>test a</code>, or halts awaiting user input at each fail <code>test</code>. The unit test, if run with an output file argument, outputs a file containing all failed test results.</p><p>
|
||
|
||
Then, finally, transactions in a block chain, where each transaction threads to the previous transactions. And then we have a cash and name system – but not yet a decentralized distributed name system.</p><p>
|
||
|
||
Then we implement Paxos, peers, and clients, a truly decentralized fully scalable system, and start selling it.</p><p>
|
||
|
||
There is an obvious problem with this, in that you have to manually launch the server in one command line window, and manually launch the clients in their own test windows. C++17 knows nothing about multiprocess, making it hard to automate multiprocess tests. CTest, however, does know about multiprocess, and can run multiple tests in multiple processes. We have it run the server in self test mode, and multiple instances of the client in test mode. Not at all sure how portable a CMake based self test is going to be, and in any case, should only create it after we have the system running without CMake. Furthermore, looks that CMake fails to play nice with wxWidgets, may be useful only for command line programs – though we can implement most of model view with command line clients and servers and test them from Putty raw mode.</p><p>
|
||
|
||
Then, a <a href="https://www.johnlamp.net/cmake-tutorial-1-getting-started.html">CMakeLists.txt routine that supports CTest.</a>.</p><p>
|
||
|
||
We build a client server architecture that utilizes Zooko identities, each Zooko identity based on a passphrase that is manually maintained off database. A client needs to be launched with its passphrase.</p><p>
|
||
|
||
Then we integrate SQLite (using their own wrapper), and build a database of Zooko identities. Then we build a trivial chat system whereby Zooko identities can chat client <-> peer <-> peer <-> client. The database now contains data on which Zooko identity is associated with which peer, and the IP or peer or domain name at which a peer can be found. Clients can be contacted through peers, and peers can be found by IP, by domain name, or by another peer.</p><p>
|
||
|
||
We integrate Cap'n proto, then implement Merkle-patricia trees based on data hashed in Cap'n proto format, then we flood fill contact information through the system in Cap'n proto format.</p><p>
|
||
|
||
We also introduce global true names with no mechanism for resolving true name conflicts. (at which stage true names are worthless).</p><p>
|
||
|
||
We now return to wxWidgets to make our chat system almost useful (assuming mystery consensus on true names by some as yet undefined process).</p><p>
|
||
|
||
Now that we have a secure communication system, secured by Zooko names, though totally insecure on true names, an integrated database, Cap'n Proto, and a flood fill system based on Merkle-patricia dacs, we implement global consensus by (arbitrarily defined) weight of stake, with each named peer somehow having some stake that is already part of the previous consensus.</p><p>
|
||
|
||
At this point we actually have something useful, since we weave the past consensus by multiple paths into the future consensus, so any time anyone communicates with anyone he is checking that that everyone is on the same consensus. So, one guy once gets a forked consensus, then everything stops working when he interacts with people who are still on the main consensus. The entity fooling him has to continue corrupting all his communications with everyone, or else will be detected. A furtive fork will cause stuff to fail, and thus such misconduct will be detected, and people will stop using that entity as a source of information on the consensus.</p><p>
|
||
|
||
In order to perform a man in the middle attack, have to tell one party the global consensus is one thing, represented by one hash chain, and the other party that the global consensus is another thing represented by another hash chain. And since everyone is passing around signed data to everyone else that includes references to the past global consensus, that links into the past global consensus hash chain, everything is going to break. And when people investigate to fix the break, it will be revealed that the primus inter pares peer was responsible for signing off on two different and incompatible stories about which zooko key owned which human readable name, will lose reputation, and people will stop using their services because their services cause stuff to break, with the result that a different peer will become primus inter pares.</p><p>
|
||
|
||
The difference between this system and the certificate authority system is that there are a one hundred and one certificate authorities that could provide a false certificate and millions of certificates, while there is only one global consensus, and this global consensus is distributed to a one hundred and one places, and checked by a one hundred and one peers, hence providing a false consensus is more likely to be detected, and more likely to have consequences.</p><p>
|
||
|
||
So we now have a system for associating keys with human readable names that provides security that certificate authority system fails to provide.</p><p>
|
||
|
||
At which point we go public, releasing the software as beta for secure communication, but pre-alpha for payments – payment interface does not work, due to bugs and unimplemented features, and if it did work, would be unreliable as a store of value, due to unimplemented features and unimplemented security.</p><p>
|
||
|
||
At which point we release the software as alpha, then beta, then release but incomplete, release version of name system, pre alpha version of money system. (Stake is not yet usable as money. Stake in alpha and beta releases of the stake system is unlikely to be conserved between releases. Names are likely to be preserved, but may will eventually fees in the release version of the money system. These fees are likely to be very small.).</p><p>
|
||
|
||
And then we give clients ownership rights over portions of peer stake, and the capacity to transfer it from one peer to the next.</p><p>
|
||
|
||
And then we give clients the capacity to transfer that ownership stake from one client to the next.</p><p>
|
||
|
||
We make such transfers chat linked, so that a client can prove that the transfer is associated with a human to human text.</p><p>
|
||
|
||
And then we give clients the capacity (completely visible and on the block chain) to transfer that ownership stake from one client to the next, which is a little bit anonymous, in that one real person could have a zillion zooko identities.</p><p>
|
||
|
||
And then we introduce an anonymized mix process in making that transfer, so that a human party to the transaction can prove connection to chat, but an outsider cannot.
|
||
.</p>
|
||
|
||
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
|
||
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
|
||
Commons Attribution-Share Alike 3.0 License</a></p>
|
||
</body>
|
||
</html>
|