Overview of event and txn handling in the coprocessor

[dartdart26]

This issue proposes a way to handle events and txns in the coprocessor. Outcome from the discussion with @goshawk-3 and @rudy-6-4 . Comments are welcome!

Assumptions:

• Inputs (+ ZK proofs) are read from calldata from a contract on the L2 GW.
• Decryptable ciphertexts (as per ACL events) are stored in state in a contract on the L2 GW.

Proposal:

1. We will have 1 EventListener service (binary) that connects to L1 for TFHE Operation events and ACL events and to the L2 GW for Input Verification events.
2. TFHE Operation events would be inserted in the PostgreSQL DB as is done now from gRPC. Workers fetch work in the same way as now, without any changes.
3. ACL events would be inserted in the PostgreSQL DB and PBS workers will compute the PBS ciphertext and insert the results into the pending_txns table (used as a queue).
4. Input Verification events would be inserted in the PostgreSQL DB and input verification workers will verify the ZK proof, sign the result and insert into the pending_txns table (used as a queue).
5. PBS workers and input verification workers will be separate sets s.t. they can be scaled separately.
6. Introduce a TxnSender component that reads from the pending_txns table and sends the txns to the L2 GW. TxnSender has configurations for wallets, L2 GW URL, contract addresses, etc.
7. The pending_txns table is generic such that it supports txns to different contracts, with different amount of arguments, etc. That would also allow batching s.t. multiple pieces of data are put into a single txn.
8. Introduce a flag in the ciphertexts table that shows whether the PBS ciphertext has been computed. If true, skip computation and skip txn sending (as we assume the first time the PBS ciphertext and ciphertext have been sent to the GW).