-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reducer map example #1300
Reducer map example #1300
Conversation
This looks extremely promising. I have a couple of questions tough:
|
This is a relatively naive implementation that demonstrates how Actions/Reducers can be used as on-chain data structures. Without more work, the amount of elements
For this particular example, around 1024 entries.
Yes they are stored in archive nodes. I am not aware of archives pruning old state. |
Maybe we could get larger maps by having very large actions and storing multiple key-values in them! And when we reduce we only prove that the actions hash is in the list so we don't have to hash all of the big actions |
As I understand, this example uses storage in the archive node that is not part of the proved state and does not use at all on-chain 8 Fields storage for keeping the Merkle Map root. If we are speaking about possible designs for updating big Merkle Trees on-chain, one of the possible designs that would allow proving inclusion to the Merkle Tree is using the Sparse Merkle Trees that can calculate new root on-chain, then be fully reconstructed off-chain to get the witness. An example of such an approach is the Ethereum deposit contract I was thinking about combining this approach with a Token contract, where we can mint tokens to several addresses and use several 8-field contract states to get a total of 32 or 64 Fields to store Sparse Merkle Tree branches. The new sha256 hash in o1js probably opens the possibility of porting this Solidity code to the Mina protocol. This way, we can update on-chain Sparse Merkle Tree branches and root and use on-chain witness verification based on the proved state. The other possibility is to keep branches in the last action storage and keep the root on-chain in one of 8 Fields. This way, we should limit the ability to post actions to the contract but allow us to calculate the root using the last action. It would require attaching to the actions new branches and some proof that the branches have been updated correctly. |
This contract emulates a "mapping" data structure, which is a key-value store, similar to a dictionary or hash table or
new Map<K, V>()
in JavaScript.In this example, the keys are public keys, and the values are arbitrary field elements.
This utilizes the
Reducer
as an append online list of actions, which are then looked at to find the value corresponding to a specific key.