To transfer money, transfer promises made by very creditworthy well networked entities.
Swift, the electronic interbanking system, the system banks use to communicate with each other, describes the service it provides as secure authenticated store and forward non repudiable messages with proof of delivery – a bank cannot deny sending the message, nor deny receiving it.
The system has about ten thousand members and handles about twenty million messages a day, too many for a bitcoin like system. Your store would grow at about four gigabytes a day.
To handle this in a system based on a global hash:
The global hash for each time period is shared by almost everybody, as are all the nodes near the root. Each member only needs to retain the near root data, the data that they care about, and paths from the data that they care about to the root.
Ann maintains a signed hash of all messages sent from Ann to Bob, also a signed hash of all messages received from Bob. These hashes get incorporated into the global hash that is shared by everyone.
So when Ann sees a mismatch between messages Bob sent, and messages Ann received, asks Bob to fix the mismatch.
To the extent that Ann’s record of messages sent, agrees with Bob’s record of messages received for messages sent some time ago, we have non repudiation and guarantee of delivery.
If ten thousand members, then two hundred million hashes every time period, but we special case the hash of no messages sent or received between Ann and Bob in a given time period, so that it does not take up any significant space in the tree or computational resources. It is a virtual hash, not a real hash.
Everyone stores the current hash for each pair, which, if no messages have been sent in the last few time periods, is the same as the hash from some time ago, and if no messages have ever been sent, is represented by the null hash. Conceptually we have a lot of nulls, but these are efficiently represented, as a sparse matrix, so that we don’t waste storage or communication managing huge numbers of mostly null entries.
In addition to the encrypted pairwise messages, we also have messages to the public, signed but not encrypted. This enables one to find the characteristics of the owner of the key, usually used to look for a key owner with certain characteristics. The primary function of this is to ensure that everyone sees the same key for the entity called Bob as Bob does, since the hash of all public messages by Bob go into the global hash, and everyone sees the same global hash.
All of this would be simple if the hashes were static, if we were managing an immutable data structure, but we are of course managing a mutable data structure with an immutable past. Each hash continually changes.
An ever changing hash is represented by a time tree of hashes.
We have a hash for the period 0 milliseconds to 2^64-1 milliseconds, which is itself a hash of the two hashes, one for the period 0 seconds to 2^63-1 milliseconds, and the other for the period 2^63 seconds to 2^64-1 milliseconds.
And the hash for the period the period 2^63 seconds to 2^64-1 seconds is itself a hash of the two hashes, one for the period 2^63 seconds to 3*2^62-1 seconds, and one for the period 3*2^62 seconds to 2^64-1 seconds.
And so on and so forth. Hashes for the past are immutable, and signed. Hashes for periods that incorporate the future are also signed, but are listed as provisional and only covering data up to such and such a time. They are useful because they incoporate hashes of times that are strictly in the past.
To bind the entire past, one needs the signed mutable hash for the smallest period including all of the past, plus the hashes nearest the root that cover all of the past.
Thus the hash for the entire past is typically only larger than the hash for a single time period by a factor of log base two of the current time.
The signature on the mutable hash acts as a signature on all past immutable hashes.
The hash for a single time period is an ordinary hash, like SHA2. The hash for the entire time period is a small number of such hashes forming a tree, and ending in a signature of the root of the tree.
Any data that anyone supplies then has to have a path leading from its local all time hash to this global all time hash.
If 256 bit single time hashes, an all time hash is about one kilobyte, but updates are only thirty two bytes or so. So our global data structure is quite large, but updates quite slowly. If ten thousand members, our global data structure is about a hundred gigabytes, assuming every entity interacted with every other. If every member interacted with every other member in a given time period, the update would be three gigabyes, which would be intolerable. Interacting with a single member requires ten thousand thirty two byte notifications, which is tolable, but starting to get expensive.
To remedy the problem, members for groups, and groups of groups and groups of groups of groups. So you don’t track the hashes for every interaction between every member, but rather most such interactions get aggregated into the interaction between group and group.
Of course, having secure non repudiable messaging with proof of delivery is only a foundation for a financial system. Swift builds a financial system on top of that by making sure that all entities are very highly rated.
Ripple, however, addresses a system where some entities are rated to some people and not others, where not everyone has good ratings, and opinions about ratings differ, where perhaps some entities are well placed to ensure payment of what is owed, and others less well placed.
These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License