Author: Russell O'Connor 2022-11-04 20:29:26
Published on: 2022-11-04T20:29:26+00:00
On November 4, 2022, Trey Del Bonis discussed the idea of using granular transaction introspection opcodes from a list in Elements. These opcodes were recently introduced on Liquid along with Taproot. However, the actual proof verification seems to be a complicated part. Trey had considered building a verifier for modern proof systems using pairings as a primitive, but it would be error-prone when adapting the code for new circuits and could be prohibitively expensive due to the code size on-chain. Therefore, introducing a specific opcode for doing a proof verification implemented natively would be more efficient. The way this opcode would work is by taking the serialized proof, a verification key, and the public input as separate stack items. The public input consists of the concatenation of the state and deposit commitments taken from the input, the batch post-state commitment (provided as part of the witness), data from transaction outputs corresponding to internally-initiated withdrawals from the rollup, and the rollup batch data itself (also passed as part of the witness).Trey also expressed interest in knowing what sort of Simplicity Jets would facilitate rollups, specifically pairing-friendly curve operations. Although it might not make the first cut of Simplicity, he expects an overall maximum allowed Simplicity evaluation state size of around 1MB.
Updated on: 2023-06-16T01:46:56.631122+00:00