[FEATURE] USDC Swap Chain

[ezeike]

Describe the feature you'd like

Implement a consensus-driven oracle on the USDC Chain to efficiently integrate off-chain data from the Ethereum blockchain, focusing on the synchronization of lock and close orders through a robust state machine.

Motivation

The integration of off-chain data via an oracle enables real-time functionality and reliability in handling transactions on the USDC Chain. This ensures that the system accurately reflects finalized Ethereum blocks and maintains integrity in order processing.

Additional context

The USDC Chain must operate with the understanding that Ethereum does not provide immediate block finality. The use of a committee for consensus, combined with an efficient WebSocket notifier, is critical for managing order flows and ensuring that both lock and close orders are appropriately processed in line with finalized Ethereum block updates.

Possible implementation

1. Modify sock.go to enable effective communication with the Ethereum blockchain for new block arrivals.
2. Implement a WebSocket notifier in the RPC or controller package that listens for incoming Ethereum block data.
3. Develop lib.EthereumChainInfo to facilitate data processing from the Ethereum chain.
4. Adapt swap.go/ProcessRootChainOrderBook to ensure proper parsing and handling of incoming lock and close orders.
5. Establish the Consensus Rule (CR) based on the received orders and update the Root Chain Order Book accordingly.
6. Create a reset mechanism that triggers when close orders are not detected within a predefined timeframe post-block parsing.

Required Tags

• Priority: High
• Module: Multi-Module

[ezeike]

Overview

• USDC Chain: Functions as a decentralized consensus-driven oracle, retrieving off-chain data and integrating it on-chain.

Key Components

• Committee Members: Registered on the root chain, running software to read external chain data (specifically Ethereum).
• Ethereum Finality: Recognizes the delay due to GASPER finalization (6.4 minutes for epochs).
• Data Processing:
  • Reads finalized Ethereum blocks via websockets.
  • Looks for lock & close orders, represented in JSON.

Process Flow

1. Order Processing:

   • Populate CR.orders with data from lock and close orders.
   • If a close order is missing, reference the order book on the root chain.

2. Block Listening:

   • Use ResetBFT when a new block is received from peers.
   • Implement consensus triggered by finalized Ethereum blocks.

3. Controller Actions:

   • Inside sock.go, develop an Ethereum manager for reporting new blocks to the controller.
   • Trigger a reset upon new block detection (currently triggered by root or nested chain blocks).
   • Create websocket notifier in RPC/controller package.
   • Develop lib.EthereumChainInfo for Ethereum metrics.

4. Swap Process:

   • Initiation: Seller defines USDC to CNPY swap ratio.
   • Transaction:
     • Eth participant locks intent with an ETH transaction (JSON).
     • Committee witnesses the transaction, achieving a +⅔ quorum, and securely registers the lock on the root chain.
   • Payment:
     • Buyer sends USDC to seller's Ethereum address.
     • Committee verifies the BTC transfer, achieves another +⅔ quorum, and releases CNPY to the buyer's RootChainAddress.

5. Certificate Result:

   • Build CertificateResult based solely on Ethereum swap information.
   • Ensure transfer to an escrow pool.

Additional Notes

• Consider baking parser into the controller or refining existing processes for order parsing in swap.ProcessRootChainOrderBook.
• Emphasize the importance of successful multi-signature quorum in committee operations.

[andrewnguyen22]

A few 'safe-guards' for the USDC chain that should be implemented:

• Refuse to accept new lock orders under the following conditions:
  • On-disk order-mempool reaches 80% capacity
  • The root-chain is halted
• Shouldn't send a lock unless the order ID exists and isn't locked on the Root-Chain
• There should be a max_resubmit as a failsafe in orders