On a usual blockchain, a block is verified by checking its parent hash against the hash of the previous block, which can be directly computed. If the node does this all the way back to a trusted block, then chain is valid. The only block that can be trusted initially is the genesis block, which typically ships with the verifying code.


If namespaces could be disjoint, with no possibility of crossing the streams, then namespaces could form the basis for completely separate blockchains. They could even branch, though not join without a tremendous amount of work, and every block would be traceable back to genesis.

This does lead to a world where a part of the tree (each path outward from genesis) forms a complete blockchain, but it lacks the fluidity in namespaces that our rhetoric prefers.


It's not clear what to call it when two namespaces cross at a transaction. One thought brought up in a meeting was that the crossed transaction could go into either namespace's chain. If, in the following diagram, the Block AB1 is inserted into Namespace A's chain, then either (1) the B subchain lacks some blocks involving B or (2) the B subchain is complete, but non-contiguous. In the first case, block B2 simply connects to B1, and the AB transaction is never seen on that chain. In the second, B1 and Bm both terminate subchains.

This second alternative is likely preferable and might even be workable. Some auxiliary pointer to the orphaned part of the chain may be necessary.


Obviously, recovering a partial chain covering a subset of names is easier if the namespace is known upfront. In fact, if namespaces are registered, first-class entities, the blockchain hash/pointer mechanism could be extended to thread namespaces through the blockchain itself. In this namespace, there are multiple parent hashes, and following the ParentN hash all the way back to genesis both verifies a namespace and allows a smaller download.


In the running code, it seems most natural to track namespace inclusion in a separate data structure, using auxiliary storage either to associate names or namespaces to blocks in the chain.

If names are not resolvable upfront to a single namespace, then recording the names themselves in this way is possible. In fact, assuming that a list of names in a block is much shorter than the list of state changes stored in the block (the transactions or formulae), perhaps it makes sense to store the names in its own genesis-rooted blockchain that carries "pointers" to transaction-carrying blocks on the transaction blockchain.

In the above diagram, Nj represents the list of names used in at least one transaction in block j. If names are reducible to namespaces, this is even shorter as only the list of (registered, accessible) namespaces needs to be memorialized in the namechain.