-
Notifications
You must be signed in to change notification settings - Fork 125
blake2f precompile #51
Comments
Some thoughts on a possible approach. Data layoutStateFor the layout of the state relative offsets can be used to store the 4 state inputs used in
Which rotation to use is decided by a selector in a fixed column (because it's always the same for every round). Alternatively we can also use the lookup approach explained below for MessageTwo words are required per In the first round we just load in the data, 2 words per row. In the other rounds we have to make sure that this permutated data is the same as the data in the first row. If the number of round was fixed this would be easy, we could just use copy constraints to hardcode the So we have to keep track of some identifiers while hashing:
G
With these calculations I actually think it makes more sense to use the lookup approach and not a bit approach. There's also this extra intermediate result that's used after the mod operations that makes it not ideal. There's also not a lot of reuse that can happen by using bits because the values cannot be reused a lot more when we use bits. The rotation is also mostly byte based + only a single rotation needed so the splitting into parts can easily be done efficiently. So I would just split up the 64-bit words in parts that make the most sense and minimizes the amount of lookups and columns needed to store those parts. LayoutMain layout would look something like this I think:
Gas considerationsA round only costs Notes
|
Checklist:
is_enabled
column: Set to 1 only for rows that contain valid hash for the data in the column below, otherwise needs to be set to 0 (so no garbage data can be lookup up). In other wordsis_enabled
is set to1
once per blake2f once all data has been verified and the hash is calculated.num_rounds
column: the number of rounds that produced the blake2f hashstate_rlc
column: the rlc of the state vector datamessage_rlc
column: the rlc of all the input bytes used in the hashoffset_counter_0',
offset_counter_1' columns: the offset countersf
column: final block indicatorlo_hash
column : the lowest 128 bits of the blake2 hashhi_hash
column : the highest 128 bits of the blake2 hashDescription:
Implementation probably similar to sha256, so a good idea to first look at that implementation and use it as a base: privacy-scaling-explorations#756
Presentation: https://docs.google.com/presentation/d/1eHVzLPRIEziCJ_oDuJG0yZ-5klNj_daqioC0UaGDaiw/edit#slide=id.p
The text was updated successfully, but these errors were encountered: