chore(coprocessor): remove legacy tfhe-worker gRPC path (#1982)

* chore(coprocessor): remove legacy tfhe-worker grpc path

* fix(tfhe-worker): resolve clippy dead_code in bench/test utils

* refactor(tfhe-worker): remove unused computation module

* test(tfhe-worker): cap event operator coverage at uint64

* fix(coprocessor): address review noise and typos

* chore(tfhe-worker): reduce bench fmt churn in dex migration

* chore(tfhe-worker): revert formatting-only bench_id wraps

* chore(tfhe-worker): remove remaining bench format-only churn

* bench(tfhe-worker): restore dex workload parity with legacy grpc

* test(tfhe-worker): restore non-ignored coverage after grpc removal

* test(tfhe-worker): deduplicate operator event coverage

* test(tfhe-worker): harden event test stability

* test(tfhe-worker): run full event type matrix in CI

* test(tfhe-worker): default full event matrix with mode logging

* test(tfhe-worker): simplify event matrix selection

* docs(tfhe-worker): document event test matrix modes

* test(tfhe-worker): expand random event tests across types

* test(tfhe-worker): restore random type matrix parity

* test(tfhe-worker): use query! in invalid operation event test

* fix(bench): stabilize benchmark pipeline after grpc refactor

* fix(bench): allow dex setup trivial encrypt handles

* charts: bump coprocessor chart version

* tfhe-worker: propagate gpu feature to test-harness

* test(tfhe-worker): allow dependent schedule setup handle

* test(tfhe-worker): fix event test matrix CI regressions

* refactor(tfhe-worker): deduplicate test helpers and remove dead code

- Migrate operators_from_events.rs to use shared event_helpers
  (setup_event_harness, next_handle, to_ty, tfhe_event, log_with_tx)
- Remove duplicate test_invalid_operation_marks_error (kept in errors.rs)
- Move wait_for_error to event_helpers for shared use
- Extract TEST_CHAIN_ID const, remove debug eprintln calls
- Remove 16 dead CoprocessorError variants from types.rs

* refactor(tfhe-worker): destructure EventHarness to reduce PR diff

Destructure setup_event_harness() return into {app, pool, listener_db}
so variable names match the original code, minimising the review diff.

* chore(tfhe-worker): remove dead deps and batch event test waits

Remove 6 Cargo dependencies that were only used by the deleted gRPC
server (sha3, lru, rayon, tfhe-zk-pok, regex, actix-web).

Restructure 4 event tests (unary, cast, if-then-else, rand) to use
batch-then-wait pattern: insert all events first, call
wait_until_all_allowed_handles_computed once, then verify. This
eliminates ~200 redundant waits in CI, saving ~10 minutes of sleep.

Also remove unnecessary pub(super) from test_fhe_rand_events.

* refactor(tfhe-worker): address PR review feedback

- Upgrade as_scalar_uint to accept &BigInt directly
- Deduplicate helpers in operators_from_events.rs (delete
  insert_tfhe_event, allow_handle, as_scalar_uint copies; use
  event_helpers versions)
- Delete redundant test_fhe_rand_events (subset of random.rs tests)
- Expand test_op_trivial_encrypt to cover all supported types with
  edge-case values
- Add 5 error test scenarios: circular dependency, too many inputs,
  scalar division by zero, binary boolean inputs, unary boolean inputs

* fix(tfhe-worker): replace validation-time error tests with execution-time ones

Remove 3 error tests (circular dependency, too many inputs, scalar div
by zero) that trigger validation-time errors in check_fhe_operand_types.
These errors propagate via ? without being persisted to the DB, causing
an infinite retry loop in event-driven mode.

Replace with test_type_mismatch_error (FheAdd on uint8 + uint16) which
passes validation but properly fails at execution time with
UnsupportedFheTypes.

The validation-path error propagation is tracked as a separate issue.

* docs: update FHE computation diagram to reflect event-driven architecture

Replace the obsolete AsyncCompute gRPC flow with the current
host-listener event-driven architecture in the sequence diagram.

* fix(tfhe-worker): fix GPU test failures in error and random bounded tests

test_coprocessor_computation_errors: Replace Cast-to-type-255 with
FheSub on mismatched types (uint32 + uint64).  The old test panicked on
the GPU path during memory reservation in trivial_encrypt_be_bytes,
preventing the error from being persisted to the DB.  Type-mismatch
errors return a proper Result::Err on both CPU and GPU.

test_fhe_random_bounded: Use per-type bounds from the old gRPC test
instead of upper_bound=1.  The 0-random-bits edge case (bound=1)
behaves differently on GPU vs CPU.  Also check bool results as
true/false rather than assuming a specific numeric value, since CPU
and GPU produce different deterministic outputs for the same seed.

* docs(tfhe-worker): fix stale README heading after gRPC removal

The server was removed; only the background worker remains.

Author: Eikix

charts/coprocessor/Chart.yaml

@@ -1,6 +1,6 @@
 name: coprocessor
 description: A helm chart to distribute and deploy Zama fhevm Co-Processor services
-version: 0.8.2
+version: 0.8.3
 apiVersion: v2
 keywords:
   - fhevm

charts/coprocessor/values.yaml

@@ -535,15 +535,8 @@ tfheWorker:
     - --metrics-addr=0.0.0.0:9100
     - --service-name=tfhe-worker  # tfhe-worker service name in OTLP traces
     - --log-level=INFO
-    # Should not be used (unsafe - testing only, keep 0/false values except CI)
-    - --run-server=false
+    # Should not be used (unsafe - testing only, keep false values except CI)
     - --generate-fhe-keys=false
-    - --server-maximum-ciphertexts-to-schedule=0
-    - --server-maximum-ciphertexts-to-get=0
-    - --maximum-compact-inputs-upload=0
-    - --maximum-handles-per-input=0
-    - --server-addr=""
-    - --coprocessor-private-key=""
     # Unique worker identifier (valid UUID v4 format)
     # If not set, defaults to a random UUID generated at startup
     - --worker-id=$(WORKER_ID)

coprocessor/README.md

@@ -72,38 +72,24 @@ $ tfhe_worker --help
 Usage: tfhe_worker [OPTIONS]
 
 Options:
-      --run-server
-          Run the API server
       --run-bg-worker
           Run the background worker
       --generate-fhe-keys
           Generate fhe keys and exit
-      --server-maximum-ciphertexts-to-schedule <SERVER_MAXIMUM_CIPHERTEXTS_TO_SCHEDULE>
-          Server maximum ciphertexts to schedule per batch [default: 5000]
-      --server-maximum-ciphertexts-to-get <SERVER_MAXIMUM_CIPHERTEXTS_TO_GET>
-          Server maximum ciphertexts to serve on get_cihpertexts endpoint [default: 5000]
       --work-items-batch-size <WORK_ITEMS_BATCH_SIZE>
           Work items batch size [default: 10]
       --tenant-key-cache-size <TENANT_KEY_CACHE_SIZE>
           Tenant key cache size [default: 32]
-      --maximum-compact-inputs-upload <MAXIMUM_COMPACT_INPUTS_UPLOAD>
-          Maximum compact inputs to upload [default: 10]
-      --maximum-handles-per-input <MAXIMUM_HANDLES_PER_INPUT>
-          Maximum compact inputs to upload [default: 255]
       --coprocessor-fhe-threads <COPROCESSOR_FHE_THREADS>
           Coprocessor FHE processing threads [default: 8]
       --tokio-threads <TOKIO_THREADS>
           Tokio Async IO threads [default: 4]
       --pg-pool-max-connections <PG_POOL_MAX_CONNECTIONS>
           Postgres pool max connections [default: 10]
-      --server-addr <SERVER_ADDR>
-          Server socket address [default: 127.0.0.1:50051]
       --metrics-addr <METRICS_ADDR>
           Prometheus metrics server address [default: 0.0.0.0:9100]
       --database-url <DATABASE_URL>
           Postgres database url. If unspecified DATABASE_URL environment variable is used
-      --coprocessor-private-key <COPROCESSOR_PRIVATE_KEY>
-          Coprocessor private key file path. Private key is in plain text 0x1234.. format [default: ./coprocessor.key]
 ```
 
 ```bash

coprocessor/docs/fundamentals/fhevm/coprocessor/fhe_computation.md

@@ -5,30 +5,32 @@ Block execution in FHEVM-coprocessor is split into two parts:
 - Symbolic Execution (onchain)
 - FHE Computation (offchain)
 
-Symbolic execution happens onchain, inside the [FHEVMExecutor](../../../../contracts/contracts/FHEVMExecutor.sol) contract (inside the EVM). Essentially, the EVM accumulates all requested FHE operations in a block with their input handles and the corresponding result handles. Then, at the end of block execution, it sends an `AsyncCompute` request to the coprocessor such that FHE computation can be done **eventually**. Note that FHE computation can be done at a future point in time, after the block has been committed on the host blockchain. We can do that, symbolic execution only needs handles and doesn't actual FHE ciphertexts. Actual FHE ciphertexts are needed only on **decryption** and **reencryption**, i.e. when a user wants to see the plaintext value.
+Symbolic execution happens onchain, inside the [FHEVMExecutor](../../../../contracts/contracts/FHEVMExecutor.sol) contract (inside the EVM). Essentially, the EVM accumulates all requested FHE operations in a block with their input handles and the corresponding result handles. These operations are emitted as on-chain events (logs) that the host-listener ingests into the coprocessor database, such that FHE computation can be done **eventually**. Note that FHE computation can be done at a future point in time, after the block has been committed on the host blockchain. We can do that, symbolic execution only needs handles and doesn't need actual FHE ciphertexts. Actual FHE ciphertexts are needed only on **decryption** and **reencryption**, i.e. when a user wants to see the plaintext value.
 
 ```mermaid
 sequenceDiagram
     participant Full Node
-    participant Coprocessor
+    participant Host Listener
     participant DB
+    participant TFHE Worker
 
     loop Block Execution - Symbolic
         Note over Full Node: Symbolic Execution on handles in Solidity
         Note over Full Node: Inside EVM: computations.add(op, [inputs], [result_handles])
     end
 
     Note over Full Node: End of Block Execution
+    Note over Full Node: FHE operations emitted as on-chain events (logs)
 
-    Full Node->>+Coprocessor: AsyncCompute (AsyncComputeRequest(computations))
-    Coprocessor->>+DB: Insert Computations
-    DB->>-Coprocessor: Ack
-    Coprocessor->>-Full Node: AsyncComputeResponse
+    Host Listener->>Full Node: Poll for new events
+    Full Node->>Host Listener: FHE operation events
+    Host Listener->>+DB: Insert Computations
+    DB->>-Host Listener: Ack
 
     loop FHE Computation
-        Coprocessor --> DB: Read Input Ciphertexts
-        Note over Coprocessor: FHE Computation
-        Coprocessor --> DB: Write Result Ciphertexts
+        TFHE Worker --> DB: Read Input Ciphertexts
+        Note over TFHE Worker: FHE Computation
+        TFHE Worker --> DB: Write Result Ciphertexts
     end
 ```
 
@@ -38,6 +40,6 @@ Note that, for now, we omit the Data Availability (DA) layer. It is still work i
 
 ## Parallel Execution
 
-Since the Coprocessor can extract data dependencies from the `AsyncCompute` request, it can use them to execute FHE computations in parallel.
+Since the coprocessor can extract data dependencies from the ingested events, it can use them to execute FHE computations in parallel.
 
 At the time of writing, the Coprocessor uses a simple policy to schedule FHE computation on multiple threads. More optimal policies will be introduced in the future and made configurable.

coprocessor/docs/getting_started/fhevm/coprocessor/configuration.md

@@ -11,38 +11,24 @@ coprocessor --help
 Usage: coprocessor [OPTIONS]
 
 Options:
-      --run-server
-          Run the API server
       --run-bg-worker
           Run the background worker
       --generate-fhe-keys
           Generate fhe keys and exit
-      --server-maximum-ciphertexts-to-schedule <SERVER_MAXIMUM_CIPHERTEXTS_TO_SCHEDULE>
-          Server maximum ciphertexts to schedule per batch [default: 5000]
-      --server-maximum-ciphertexts-to-get <SERVER_MAXIMUM_CIPHERTEXTS_TO_GET>
-          Server maximum ciphertexts to serve on get_cihpertexts endpoint [default: 5000]
       --work-items-batch-size <WORK_ITEMS_BATCH_SIZE>
           Work items batch size [default: 10]
       --tenant-key-cache-size <TENANT_KEY_CACHE_SIZE>
           Tenant key cache size [default: 32]
-      --maximum-compact-inputs-upload <MAXIMUM_COMPACT_INPUTS_UPLOAD>
-          Maximum compact inputs to upload [default: 10]
-      --maximum-handles-per-input <MAXIMUM_HANDLES_PER_INPUT>
-          Maximum compact inputs to upload [default: 255]
       --coprocessor-fhe-threads <COPROCESSOR_FHE_THREADS>
           Coprocessor FHE processing threads [default: 8]
       --tokio-threads <TOKIO_THREADS>
           Tokio Async IO threads [default: 4]
       --pg-pool-max-connections <PG_POOL_MAX_CONNECTIONS>
           Postgres pool max connections [default: 10]
-      --server-addr <SERVER_ADDR>
-          Server socket address [default: 127.0.0.1:50051]
       --metrics-addr <METRICS_ADDR>
           Prometheus metrics server address [default: 0.0.0.0:9100]
       --database-url <DATABASE_URL>
           Postgres database url. If unspecified DATABASE_URL environment variable is used
-      --coprocessor-private-key <COPROCESSOR_PRIVATE_KEY>
-          Coprocessor private key file path. Private key is in plain text 0x1234.. format [default: ./coprocessor.key]
       --service-name <SERVICE_NAME>
           Coprocessor service name in OTLP traces [default: coprocessor]
   -h, --help
@@ -61,19 +47,3 @@ Note that there are two thread pools in the Coprocessor backend:
 The tokio one (set via `--tokio-threads`) determines how many tokio threads are spawned. These threads are used for async tasks and should not be blocked.
 
 The FHE compute threads are the ones that actually run the FHE computation (set via `--coprocessor-fhe-threads`).
-
-#### Secret Signing Key
-
-A secret signing key is needed to allow the Coprocessor backend sign input insertion requests. A `coprocessor.key` file can be given on the command line for the **server** as:
-
-```
-coprocessor --help
-Usage: coprocessor [OPTIONS]
-
-Options:
-...
-      --coprocessor-private-key <COPROCESSOR_PRIVATE_KEY>
-          Coprocessor private key file path. Private key is in plain text 0x1234.. format [default: ./coprocessor.key]
-```
-
-The secret signing key must be kept safe when operating the Coprocessor.