Dist.ribut.us Claude

Progressive Layers

Getting away from block-chain and hash-puzzles, the core challenge of a distributed currency is recording transactions in an open and accountable way.

The catch-22 is that as we make the agreement process broader we gain trust, but it takes longer to validate transactions. As we narrow, it becomes possible for the controlling nodes to act maliciously.

It may be possible to mitigate this with a layering scheme. There's an outer layer responsible for distributing the data - acting almost purely as a CDN. The next layer performs validation. It can't write transactions, but it can veto a transaction by showing that it's malformed. The inner most layer can actually write transactions to the ledger.

The second layer can also form a transaction pool. The transaction pool attempts to pre-sort the transactions into a queue for the core. Classic chain-fork-resolution can be handled at this layer. A node can submit a transaction to this layer and quickly get an accept or reject - or submit to a few nodes at this layer for more confidence. If a fork-resolution invalidates a pending transaction, an event is emitted making it easy to track.

The core can be sharded with locking. So if there were two shards one would handle 0-8 and two would handle 9-F. If a transaction spanned both, then it takes two blocks to complete. Lets say we're transferring from 0X to 9X and the 0-8 shard is going to handle it. In a back-channel (not recorded) 0-8 requests a lock on the 9X account. The next block that 9-F releases includes a lock on 9X for 0-8 for one block. In the block after that, 0-8 can perform the transaction.

This may not work because it requires that the blocks stay in sync. Another approach would be 9-F to set on a lock on 9X, then 0-8 can perform transactions that instead of referencing the account directly, reference the lock. Then 0-8 executes an action that releases the lock and 9-F reclaims the lock.

Of course, we could take this a level further and instead of locking, just transfer control. So the transfer actually says "this account is now controlled by what ever shard controls 9,0...0". And it just stays there. Accounts will jump around, but that doesn't matter.