Using Urbit ID as a Blockchain Account

[tiller-tolbus]

Blockchain accounts are a form of identity that maps to digital asset balances in a blockchain network. Urbit ID is intended to be a universal digital identity, and its design should theoretically encompass all use cases, including for blockchain accounts. However, there is currently some difficulty in using Urbit ID as a blockchain identity.

Typically, a blockchain identity is defined as either a public key, or an account associated with a public key. This achieves a desirable form of simplicity, as you end up with minimal difficulty in verifying the signature of a transaction. When verifying a signature, blockchains do not typically have much difficulty in associating a public key with a given transaction.

Urbit ID implements a PKI that emphasizes permanence and ownership, centered around ensuring that the owner of an Urbit ID can always change their networking key and have their key changes recognized by their peers. However, its design emphasizes the ability to sign and verify live data -- the ability to sign, encrypt, decrypt and verify an immediately pending message is the primary concern. The ability to verify a signature from before a key change is given some attention, but lacks the level of robustness offered to live messages.

In a blockchain, a full node must be able to independently verify all historical transactions. This means that even if the sender of a transaction has changed their keys, a full node must be able to independently verify that the signature of the transaction was valid at the time of sending. There must also be broad consensus on this independent verification -- if a key change occurs close to the time of a sent transaction, two full nodes must not disagree on the exact time of the key change. In short, all nodes must share an understanding of an account's public key at the timestamp of the transaction.

For Urbit IDs of rank %lord and above, key changes are reported on-chain, and can be independently verified to have happened at a specific timestamp, or at least a specific Ethereum block height. A blockchain protocol could include the logic to reconstruct, from Azimuth's state, a full key revision history of every node known to have participated in the network. For Urbit IDs of rank %earl (moons), this property is attested only by their parent ship, and cannot be assumed to remain globally available indefinitely. If a blockchain protocol were to implement this bookkeeping, moons would be excluded from network participation.

This problem shares a common cause with the global scry namespace, which should in theory provide the opportunity for a given scry binding to remain globally available, cached and distributed by other nodes, and independently verifiable to have been correctly signed at the time of its binding. If scry bindings from any Urbit ID can be vicariously attested in a permanently verifiable manner, a blockchain could be constructed by modeling transactions as scry bindings, allowing full nodes to cache and redistribute these transactions. This would even allow a blockchain protocol to strike signatures from the explicit model of a transaction, and allow nodes to verify signatures implicitly by virtue of having successfully scried for them over the network.

For the purposes of the %token project, which aims to implement a semantically minimal blockchain protocol defined as an Urbit application, our path to a viable protocol depends strongly on Urbit's roadmap for implementing the discussed permanence properties of key changes. Using Urbit ID as %token's account model provides considerable semantic simplicity benefits, but may be an overreach on expectations from Urbit core development. We have narrowed down our design to the following options:

• Model transactions as remote scry bindings.
  • Trust that the forthcoming implementation of named-data networking will implement suitable bookkeeping around key changes.
  • Verify transactions by virtue of their attestations over the network.
  • Implement a protocol whereby full nodes permanently cache all valid transactions by default.
  • Keep %token in a testnet state until such properties are implemented reliably.
• Independently perform public key bookkeeping at an agent level.
  • Add substantial overhead to the %token protocol in order to ensure that, within the context of %token, all key changes and their timestamps are properly accounted for by the protocol (likely by independently retrieving and parsing the entire Azimuth log).
  • Potentially disallow network participation by moons as they cannot globally attest to their key revision history.
  • As another path down this same avenue, potentially mandate that ships to participate in the network using a different keypair from what Urbit ID provides by default, and provide a different key revision scheme that implements the desired bookkeeping properties.
• Model %token accounts as public keys.
  • Give up on the idea of Urbit IDs as %token accounts.
  • Design and implement a new consensus protocol that does not privilege stars and galaxies, or privileges them in a different way.
  • Allow ships to attest to their %token public key to maintain the simplicity of token transfers.

The path we take here will substantially depend on feedback from Urbit core developers, especially ~master-morzod and ~hastuc-dibtux who are working on the current implementation of named-data networking. We are also interested in the insights of anyone familiar with Urbit's PKI implementation for how we can implement a secure, semantically simple L1 blockchain using Urbit's primitives.

[tiller-tolbus]

Per ~master-morzod, vicarious attestations are currently being implemented with an eye towards performance benefits and not indefinite data availability. Indefinite data availability is absolutely a desired property of the global scry namespace, but implementations have not yet been designed and there are no delivery timelines to speak of.

I propose we go with the second path highlighted above:

• Independently perform public key bookkeeping at an agent level.
  • Add substantial overhead to the %token protocol in order to ensure that, within the context of %token, all key changes and their timestamps are properly accounted for by the protocol (likely by independently retrieving and parsing the entire Azimuth log).
  • Potentially disallow network participation by moons as they cannot globally attest to their key revision history.