You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we implement the replacement field in the unirep data by using two fields:
replacement field
metadata field (timestamp)
In the user state transition we compare the timestamps for each epoch key and take the largest, non-zero value as the new field value.
We can implement replacement logic in simple addition fields by overflowing the field. For example, say that in a field data[0] i have the following value: 0xa29fa929a911. An attester can replace this value with a new value 0xaa by attesting to the following, in any order:
data[0] += FIELD_MAX - 0xa29fa929a911
data[0] += 0xaa
The first attestation sets data[0] to 0 by overflowing the field element. The second attestation adds the new value to data[0]. Using an approach like this reduces the number of constraints needed in the user state transition proof. It also allows any field to operate as a replacement field.
We can implement this in ZK by revealing an epoch key and a specific data index. In the smart contract this proof can be taken and the FIELD_MAX - data value can be calculated and given as an attestation.
The text was updated successfully, but these errors were encountered:
vimwitch
changed the title
Helper for fields replacement
Data replacement using addition
Jan 15, 2023
Right now we implement the replacement field in the unirep data by using two fields:
In the user state transition we compare the timestamps for each epoch key and take the largest, non-zero value as the new field value.
We can implement replacement logic in simple addition fields by overflowing the field. For example, say that in a field
data[0]
i have the following value:0xa29fa929a911
. An attester can replace this value with a new value0xaa
by attesting to the following, in any order:data[0] += FIELD_MAX - 0xa29fa929a911
data[0] += 0xaa
The first attestation sets
data[0]
to 0 by overflowing the field element. The second attestation adds the new value todata[0]
. Using an approach like this reduces the number of constraints needed in the user state transition proof. It also allows any field to operate as a replacement field.We can implement this in ZK by revealing an epoch key and a specific data index. In the smart contract this proof can be taken and the
FIELD_MAX - data
value can be calculated and given as an attestation.The text was updated successfully, but these errors were encountered: