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.

Any of these approaches also opens up the ability to do pipelining similar to a CPU - work on several blocks at different stages simultaneously. For each transaction, if we have all the locks, put it in the current block, otherwise request the locks and put it in the next block.

Identity Credit (puzzle tower)

I like this idea - nodes build up an identity by validating individual transactions and performing hash puzzles on them. The block is composed of these sub validations. Each time a node get a transaction into a block, it's reputation increases. Over time, the reputation decays. More reputation makes it easier to mine a block. Taking any Byzantine action that can be cryptographically proven, can be registered to the chain and destroy that ID.

Fuel

I think the fuel must be consumed. Originally I was thinking we would only consume the fuel of a successful transaction. But that seems ripe for abuse. I think the better approach is that a transaction must put up some fuel up-front and can add more fuel as the transaction proceeds. But even if the transaction fails, the spent fuel is burned.