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.