Implement Eventual Consistency for Synthetic EVM Transaction Recording

[dhyaniarun1993]

Problem

Currently, the SendRawTransaction flow in the EthRPC service performs two critical operations in sequence:

• Executes a token transfer on the Canton ledger via erc20.TransferFrom.
• Records the corresponding synthetic EVM transaction and log in the database via recordSyntheticTransfer.

These operations are not atomic. If the ledger transfer succeeds but the synthetic transaction recording fails (e.g., due to a database or network error), the system becomes inconsistent: the ledger reflects the transfer, but the EVM transaction/log is missing. This can lead to data loss, user confusion, and reconciliation issues.

Proposed Solution:

Implement an eventual consistency mechanism to ensure that all successful ledger transfers are eventually reflected in the synthetic EVM transaction log, even if the initial recording fails. Possible approaches include:

• Recording a durable “intent” or “pending synthetic transfer” before or after the ledger operation.
• Implementing a background worker or reconciliation process that scans for uncommitted synthetic transfers and retries recording them until successful.
• Marking synthetic transfers as “committed” once the DB write succeeds, to avoid duplicate processing.

Acceptance Criteria:

• No successful ledger transfer should be lost from the synthetic EVM transaction log, even in the event of transient failures.
• The system should be able to recover and reconcile any missed synthetic transactions automatically.
• Failures in synthetic transaction recording should be logged.

[dhyaniarun1993]

EthRPC Mempool & Miner — Implementation Plan

1. Overview

Problem

SendRawTransaction executes a Canton ledger transfer and then records a synthetic EVM transaction/log. These two operations are not atomic. If recording fails after the Canton transfer succeeds, the ledger and EVM state diverge.

Solution

Introduce a mempool table as an intent log. A background miner goroutine owns all EVM block construction. The service only executes the Canton transfer and updates mempool status.

---

Architecture

SendRawTransaction

  │
  ├─ INSERT mempool (status = pending, command_id)
  ├─ erc20.TransferFrom(ctx, commandId, ...)
  ├─ UPDATE mempool (status = completed | failed)
  └─ return tx_hash

Miner Goroutine (every N seconds)

  │
  ├─ BEGIN TX
  ├─ SELECT FOR UPDATE on evm_state          ← serializes all instances
  ├─ SELECT * FROM mempool WHERE status = completed ORDER BY id ASC
  ├─ for each tx:
  │     ├─ INSERT evm_transactions
  │     └─ INSERT evm_logs
  ├─ UPDATE evm_state SET latest_block++
  ├─ UPDATE mempool SET status = mined
  └─ COMMIT

Reconciler (runs alongside miner)

  │
  └─ SELECT * FROM mempool
       WHERE status = pending AND age > threshold
       → check Canton GetCommandStatus(command_id)
           ├─ succeeded → UPDATE status = completed
           └─ failed    → UPDATE status = failed

This also streamlines the block generation logic by centralizing it within a single controlled execution flow.
@sadiq1971 @salindne Let me know what you guys think