[smart-contracts] Dictionary #39
Conversation
mpapierski
requested review from
henrytill,
EdHastingsCasperAssociation,
xcthulhu,
dwerner and
darthsiroftardis
text/0039-local-keys.md
Outdated
| [unresolved-questions]: #unresolved-questions | ||
|
|
||
| - How do we name this feature to reflect better what it does? | ||
| - Does it make sense to make the provisioned URef a unit? Can we use it to store additional information related to the stored data under the local key? |
There was a problem hiding this comment.
How does the migration of local storage look like? How will the upgraded contract access the pre-upgraded local data?
There was a problem hiding this comment.
This data migration will be transparent to already deployed contracts. I see this as an internal improvement, but the API would be forward-compatible.
During migration, we will iterate over reachable URefs (i.e., those stored under account or contract's named keys) detect if there's extra payload under that Unit with all the key bytes, then reindex the keys from the old hashed address (hash(uref_addr || key_bytes)), into uref_addr || hash(key_bytes) and remove the extra payload.
There was a problem hiding this comment.
OK, thanks. I just wanted to make sure this is not being overlooked and we already have a plan for how to solve it. We can't deliver local keys without also allowing contract owners to transfer them between contract upgrades.
text/0039-local-keys.md
Outdated
|
|
||
| [drawbacks]: #drawbacks | ||
|
|
||
| As explained above current limitation of key lengths inside a trie requires us to maintain a secondary index of keys under a URef to retain the ability to migrate into the unhashed, more extended keyspace for more efficient iteration. |
There was a problem hiding this comment.
This restriction could be lifted. @henrytill is it worth getting support for variable length keys so we can avoid maintaining this secondary index, or should that be done at a different time?
1467: EE-1242: Implement Dictionary r=dwerner a=mpapierski This PR implements support for improved local keys, which intends to resolve past problems that lead to their removal. Contract developers will use this to store data in a separate keyspace prefixed by the URef address provisioned to a user by the system. CEP for reference: casper-network/ceps#39 Closes #1420 Co-authored-by: Michał Papierski <michal@casperlabs.io> Co-authored-by: Henry Till <henrytill@gmail.com>
text/0039-dictionary.md
Outdated
| ### dictionary_new | ||
|
|
||
| ```rust | ||
| fn dictionary_new(name: &str) -> URef; |
There was a problem hiding this comment.
In the implementation, it's new_dictionary.
text/0039-dictionary.md
Outdated
| fn dictionary_new(name: &str) -> URef; | ||
| ``` | ||
|
|
||
| Host provisions an URef of "unit" type under the hood used internally to secure access to the dictionary. Resulting URef will be automatically put into named keys, retaining his ability to add new data. |
There was a problem hiding this comment.
What happens if name is empty? Or if there already exists an entry with the same name in named keys collection of the account?
|
@darthsiroftardis is this still relevant or can it be merged? Please advise..... |
Rendered