These appear to be unused for extension fields, so we're free to change the mapping without breaking anything.
As the TODO says, the mapping that's currently implemented doesn't seem natural or useful. It seems more natural to treat the `BigUint` as a base field element, potentially in a non-canonical form.
Based on the approach @SyxtonPrime described.
In terms of columns, the changes are:
- Store inputs (`A`) as `u32` limbs, rather than individual bits.
- Remove `C_partial`. It was used to store an intermediate product in a 5-way xor, but we've since realized that we can do a 5-way xor directly.
- Add `C_prime`, an intermediate result used to help verify the relation between `A` and `A'`.
Summary of the design:
- Tries are stored as immutable, copy-on-write trees
- All trie data is stored in the `TrieData` segment. Since it's immutable, data is never modified/deleted, new versions are just appended at the end.
- In order to support reverts, each context stores a pointer to the initial state trie version, plus the initial version of each storage trie.
One variation which may be worth considering is storing the whole state trie as one big trie (with sub-tries for storage). Reverts would then be simpler - we'd replace a single pointer. I thought that approach might make hashing the trie a bit more complex, as the node associated with an account would be a special type of node, rather than just another leaf. Either approach seems reasonable though.
Some of the `%stack` operations are now trivial, but I kind of like keeping `%stack` since it serves as documentation as well, making comments about the stack unnecessary.
Again borrowing syntax from NASM. Example from the test:
%macro spin
%%start:
PUSH %%start
JUMP
%endmacro
One thing this lets us do is create "wrapper" macros which call a function, then return to the code immediately following the macro call, such as
%macro decode_rlp_scalar
%stack (pos) -> (pos, %%after)
%jump(decode_rlp_scalar)
%%after:
%endmacro
I used this to clean up `type_0.asm`.
However, since such macros need to insert `%%after` beneath any arguments in the stack, using them will be suboptimal in some cases. I wouldn't worry about it generally, but we might want to avoid them in performance-critical code, or functions with many arguments like `memcpy`.
