Closed lazovicff closed 2 years ago
Can our gadgets API accept just bytes, or [u8; 6], which will be passed to F::from_bytes_mod_order
I think it's ok for the type to be u256, u128, or u64 since we will assume and enforce correctness from the application side (by pushing it as a public input).
I would not suggest using u32 as we are already using the new chain id type to represent a value that is u48. We could also adopt this with a non standard type library such as the one @shekohex mentioned in Slack.
Though, I have updated the chain identifier structure in resource IDs to consist of 6 bytes of data so we may want to consider adopting a more complex scheme here for the future. Namely, we currently are reserving 4 bytes for the chain ID (u32) and 2 bytes for the chain type (u16).
For example, since the chain ID is taken to be a public input. We could hash the (chain_id_type, chain_id) % u32::max() or FIELD_SIZE and use this as the value meant to be committed to inside deposit notes.
The goal with the chain ID type is to add separation between different chains with the same IDs such as parachains with ID 7 and EVM with ID 7 and Cosmos with ID 7.