Building an in-enclave matching engine with on-chain dependencies - approaches and challenges This doc outlines the high-level technical design of implementing part of the larger on-chain dark pool, specifically the orderbook and on-chain matching engine, inside a secure enclave, which are hardware-based trusted execution environments (TEEs). While the exact taxonomy is out of the scope of this doc, there are subtle differences between secure enclaves and the generalized notion of TEEs. The major difference is that enclaves offer application isolation through hardware guarantees. Why enclaves? What enclaves? The key feature that our on-chain dark pool offes is that of open order price shielding, meaning that malicious entitities/traders who want to manipulate the token price cannot do so since the price of open orders are shielded by design and hence cannot gauge the impact trade(s) from their treasury would have on the token price. As such, we make use of a number of primitives and techniques to achieve this: Orders consist of two portions, transparent and shielded, with the price of the order comprising part of the shielded portion. Whenever this portion is used for public, on-chain commitments, it is done in a hashed manner, so as to not exposing its underlying value while maintaining cryptographic integrity. All circuits that deal with raw orders take them in as private inputs.

The PSE's zkEVM circuits have a variety of helpful 'gadgets' for various functionalities. One of these is the LTChip gadget, which is used for checking, given inputs lhs and rhs, whether lhs < rhs holds true. It can be used as a helper as a part of various larger circuits, something like this: struct SomeLargerCircuitConfig<F> { q_enable: Selector, .... .... check: Column<Advice>,

Layout Memory as byte per row Single table for all precompiles sequence_id operation io length index byte