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
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.
Impact
Describe the impact this change will have on the platform (ex The proposed solution impacts both consensus and storage.).
Dependencies
To provide this solution, is any other work required in another component or by another team?
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.