Name registry 2.0 specification
- Kelly Foster
- Artur Gajowy
What is the problem?
Describe the problem. Why is it a problem? Who or what is impacted by the problem?
The current implementation of the name registry is a blocker to resolving conflicts observed in the current implementation.
Proposed solution
What should we do to solve the stated problem? If needed or applicable, provide pseudo-code to describe the solution.
The prosed solution is to reimplement the name registry that resolves the conflicts and reduces the features of the current registry that will be unused for the Mercury release. The work required to investigate the current implementation and fix it exceeds the estimated work to reimplement it with a simpler solution that will resolve conflicts.
# Registry.rho
```scala
// A note on bootstrapping this:
// The rho:registry:* URIs below must resolve to bundle+{}-s, and hence registering the contracts on them must not be possible.
// Instead, in genesis, in first deploy, we'll have a linear receive (for) registered under the bundled name, that returns itself.
// The second deploy in registry is going to be the Registry.rho deploy.
// So the bootstrap will be as follows:
// Bootstrap.rho - the first genesis deploy - created as AST, see reasons below:
new insertSignedUnderlyingName
// this name is going to be byteName(11) - like it is now. See REG_INSERT_SIGNED in Runtime.
// We must construct this rholang snippet as AST for that reason
in {
for (ret <- insertSignedUnderlyingName) {
ret!(insertSignedUnderlyingName) //return the name we listen at to the first caller
}
}
// In Registry.rho - the 2nd genesis deploy
new ret, insertSigned(`rho:registry:insertSigned`) in {
insertSigned!(ret) | //this will only work once
for (registryInsertSigned <- ret) {
contract registryInsertSigned(...) = {
//see below
}
}
}
// similarly for the other registry methods
// The simplified version of Registry.rho, omitting the above bootstrap concern:
new insertSigned(`rho:registry:insertSigned:secp256k1`),
insertArbitrary(`rho:registry:insertArbitrary`),
lookup(`rho:registry:lookup`),
secpVerify(`rho:secp256k1Verify`),
_registryStore
in {
contract lookup(uriOrShorthand, ret) = {
// 1. Translate possible shorthand to a URI
// 2. Peek for the registry map
// 3. Return whatever is there under the URI
//hardcoded, just as they are in current impl
let shorthands = [
`rho:lang:listOps`: "6fzorimqngeedepkrizgiqms6zjt76zjeciktt1eifequy4osz35ks"
]
// 1.
let uri = shorthands.get(uriOrShorthand) match {
Nil => uriOrShorthand
translatedUri => translatedUri
}
// 2.
for (map <<- _registryStore) {
// 3.
ret!(map.get(uri))
}
}
contract insertSigned(pubKeyBytes, nonce, name, sig, ret) = {
// 1. verify the sig using secpVerify
// 2. derive the URI, just as RegistrySigGen does
// 3. obtain (lock) the registry map using a non-peek receive
// 4. if there's an entry under that URI, check that the nonce was increased
// otherwise return error
// we only use max nonce, so we could skip this step and always reject overwrites
// 5. insert the updated (nonce, name) into the map, put it back
// 6. return the uri on ret channel
//...
for (map <- _registryStore) { // 3.
_registryStore!(map.set(uri, (nonce, name)) | //5.
ret!(uri) //6.
}
}
contract insertArbitrary(payload, ret) = {
// generate a random URI:
// 1. Create a new unforgable name unf
// 2. Derive the URI from (MAX_NONCE, unf)
// Procded as in insertSigned, from point 3.
}
}
```
With the solution implemented, what will we be able to demonstrate?
The answer to this will help define the acceptance criteria for completeness for this work.
- Genesis contracts are inserted into the registry and available for use, as they are currently.
- There is no longer Registry.scala, the tests from RegistrySpec that test the API are rephrased as RhoSpec.
- There is a casper networkEff test demonstrating that doing a registry lookup does not cause the deploys to conflict
(subject to peek in merge being finished - if you can't implement this test yet, ticket it)
Impact
Describe the impact this change will have on the platform (ex The proposed solution impacts both consensus and storage.).
- Rholang API - There should be no rholang API changes.
- Tests - Possible change in the URI values returned from isnertArbitrary, should only affect tests (we might not be able to reuse the random URI when porting the insertArbitrary tests to RhoSpec)
- Looking ahead - In the future, there might be a need to split the underlying registry map into smaller ones,
depending on performance needs and the desirability of registry inserts on distant/different hashes being non-conflicting.
Dependencies
To provide this solution, is any other work required in another component or by another team?
- Peek in merge
- RCHAIN-3639 - Getting issue details... STATUS
- Does not block development of this feature. May block development of the casper networkEff test described above.
- Merging of contract calls
- RCHAIN-3638 - Getting issue details... STATUS
- Does not block development of this feature. May block development of the casper networkEff test described abov
Design Considerations
Describe the issues which need to be addressed or resolved before attempting implementation.
Steps to implement the solution
Provide a list of steps needed to implement the solution. This will outline the way this feature/change is ticketed in Jira.
Steps for integration testing
If applicable, describe the steps for an integration test.
See description above for casper networkEff test.