Native Poseidon2 chip optimization for aggregation

[jonathanpwang]

We provide an explainer on the main operations of FRI verification here.

Current flamegraph profiling indicates that the current recursion program using Aggregation VM still has a large portion of cell usage not coming from the Poseidon2 chip. This indicates that we should add new hash-centric instructions and increase the functionality of the native poseidon2 chip so that the hash-based functions in FRI verification are accelerated.

After #1122, the native poseidon2 chip (used in Aggregation VM) has been split out from the system poseidon2 chip (used for continuations). We can now freely upgrade functionality of native poseidon2 chip to specialize it more for aggregation. We want to move as much of the hash-related operations in the FRI opening proof into the chip, and out of using other VM control flow/load/store operations:

• the chip should be able to do any entire mmcs.verify_batch in one instruction, reading in variable amounts of memory across multiple trace rows
• one possible approach is to allow the chip to have an absorb, squeeze functionality, where update can span multiple rows to absorb variable length memory and squeeze writes the hash digest to memory
• it would be nice / most optimal if the chip directly handles Challenger functionality without needing extra instructions in the eDSL.