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.
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. } } ``` |
The answer to this will help define the acceptance criteria for completeness for this work.
Describe the impact this change will have on the platform (ex The proposed solution impacts both consensus and storage.).
To provide this solution, is any other work required in another component or by another team?
Describe the issues which need to be addressed or resolved before attempting implementation.
Provide a list of steps needed to implement the solution. This will outline the way this feature/change is ticketed in Jira.
If applicable, describe the steps for an integration test.
See description above for casper networkEff test.