Name registry specification

The name registry is essential in allowing protected public access to unforgeable names. For testnet, we are planning on supporting UUID registration and pubkey registration.

Registration examples

For UUID registration, an example registration might look like the following:

new timesTwo, r(`rho:registry`), print in {
	contract timesTwo(@x, ret) = {
		ret!(x * 2)
	} |
	[r, "register"]!("uuid", bundle+{*timesTwo}, *print)

A user would be able to predict the contents of the print name, and would therefore know what UUID was registered by monitoring that name for events. It will be sent a uri that looks like `rho:uuid:<uuid-hex>`

To use pubkey based registration, the code would look like the following:

new timesThree, r(`rho:registry`), print in {
	contract timesThree(@x, ret) = {
		ret!(x * 3)
	} |
	[r, "register"]!("pubkey:ed25519", "<pubkey-hex-bytes>".hexToBytes(), bundle+{*timesThree}, "<signature-of-timesThree-hex-bytes>".hexToBytes(), *print)

Here the user can predict the uri that will be returned: `rho:pubkey:ed25519:<blake2b256hash of pubKey>`, However, we still return it for 2 reasons: 1. The user might want to rely on it being registered. 2. For api consistency.

Lookup examples

UUID based lookup example

new r(`rho:registry`), twoXret, print in {
	[r, "lookup"]!(`rho:uuid:<uuid given by registering timesTwo>`, *twoXret) |
	for (twoX <- twoXret) {
		twoX!(7, print)

Pubkey based lookup example

new r(`rho:registry`), threeXret, print in {
	[r, "lookup"]!(`rho:pubkey:ed25519:<pubkey hash computed above>`, *threeXret) |
	for (threeX <- threeXret) {
		threeX!(7, print)

Registry design

Lookup Commutativity

I expect that registry lookups will be very common, and so it would be great for block commutativity if we special cased writes to the registry lookup, as two lookups commute with each other as long as the registry hasn't been modified.

Registry Scaling

It should be clear that we can't store the registry as a single giant rholang map. Instead we will store it as a trie using tagged maps as fanout nodes, With UUID's and pubkey hashes, we should get rather speedy divergence. I think map entries per byte is a good initial guess.

We could implement the registry in either scala or rholang. As long as the data is in the tuplespace, it should be fine either way.