Skip to content
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

How to get initial commitment #50

Open
acolytec3 opened this issue May 18, 2024 · 4 comments
Open

How to get initial commitment #50

acolytec3 opened this issue May 18, 2024 · 4 comments

Comments

@acolytec3
Copy link
Contributor

@kevaundray wondering if this is a question you can answer but how do we get the initial commitment for a value we want to store in the verkle trie where it's for a key that has never been touched before? Should I use updateCommitment something like this:

   // take some value to be put in the tree for a node that has never been inserted before
   commitment = `verkleCrypto.updateCommitment(verkleFFI, verkleCrypto.zerocommitment, 0, new Uint8Array(32).fill(0), [value])`

or do I need to use the verkleFFI.commitTo16ByteScalars method?

@kevaundray
Copy link
Collaborator

Hey, yes that looks correct -- if its never been inserted before then it should have a value of zero, so the code you snippeted would be updating the value from zero to a value of value and computing the corresponding commitment for it.

using verkleFFI.commitTo16ByteScalars should also work in this particular scenario, however it won't work in the general case where you want to update a key that has been touched before. updateCommitment works for this usecase too so I'd err on the side of just always using that method.

@holgerd77
Copy link
Member

@acolytec3 if not too complicated/distracting right now maybe you can add a unit test for this on the JS side.

@acolytec3
Copy link
Contributor Author

@kevaundray I have a further question here.

Does the old_scalar_value and corresponding new_scalar_value refer to only the value at the commitment_index in a overall vector that is committed too?

So take the extension node node diagram from the verkle trie
image
and the commitment for it:
image

If I take the commitment for the extension node and want to update the value for c1, would I call:
verkleCrypto.updateCommitment(commitment, 2, oldC1, newC1) where oldC1 is the previous c1 commitment prior to updating some value in the first 128 values held by the extension/leaf node?

If so, is there a batchUpdate function in the verkleFFI to allow us to update a commitment in multiple places in the vector at once? The use case I have is that in working through the implementation of the verkle trie in our EthereumJS monorepo, we need to create new leaf nodes when puting a node in the trie where no current extension/leaf node exists. To do so, using the current verkle_ffi api, I need to first create a new commitment with verkle_ffi.zeroCommitment then call updateCommitment 4 times (for the leaf marker 1, the stem, the c1, and then c2 commitments) and this feels inefficient. It seems like the further use case where we're updating multiple suffixes on a single stem (e.g. when updating multiple storage slots or creating a new account or whenever a transaction is processed and we update the nonce and balance of an account) could also use something like this if there is an efficient way to do so. Should we just expose the commit_to_scalars and commit_to_16_byte_scalars and use those when instantiating new nodes? I'm assuming the commit_to_16_byte_scalars should be used in the context of generating the c1/c2 commitments on leaf nodes?

@acolytec3
Copy link
Contributor Author

One additional question here. For the 4 element vector used to derive the commitment for a leaf node, we are supposed to use c1 and c2. verkle-cryptography-wasm returns commitments as 64 byte arrays (and the commit functions in the rust API only accept 32 byte strings). Should we be using serializedCommitment to compress c1 and c2 when generating the leaf node commitment?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants