Fast Bridge Canonical Guard

[trajan0x]

Specification for RFQ Guard

Overview

The RFQ Guard is a mechanism designed to ensure the integrity of the prove() function call on the FastBridge contract. It will monitor the prove() calls made by relayers on the origin chain and verify that the corresponding event occurred on the destination chain. If a relayer attempts to call prove() for an event that did not happen on the destination chain, the guard will call the dispute() function on the FastBridge contract to dispute the proof.

Components

1. Guard Command: A separate command that can be run independently to monitor and validate prove() calls.
2. Optional Guard Functionality: RFQ relayers can optionally enable the guard functionality so they too can act as guards.

Both of these commands should (optionally) check if the relayer has guard role at boot time.

Detailed Specification

1. Guard Command

   • Name: rfq-guard
   • Functionality:
     • Monitor prove() calls on the origin chain.
     • Verify the existence of the corresponding event on the origin chain.
     • Call dispute() on the FastBridge contract if the event does not exist on the origin chain.

2. Optional Guard Functionality for RFQ Relayers

   • Configuration:
     • A configuration option in the relayer's settings to enable or disable the guard functionality.
   • Integration:
     • When enabled, the relayer will run the a guard at the same time as it relays.

Workflow

1. Initialization:

   • The rfq-guard command is initialized with the necessary parameters.
   • The guard starts monitoring prove() calls on the origin chain.

2. Monitoring:

   • The guard listens for prove() events emitted by the FastBridge contract on the origin chain.
   • For each prove() event, the guard extracts the transaction details.

3. Verification:

   • The guard verifies the existence of the corresponding event on the destination chain.
   • This involves querying the destination chain for the event using the transaction details.

4. Dispute:

   • If the event does not exist on the destination chain, the guard calls the dispute() function on the FastBridge contract.
   • The dispute() function is called with the transactionId of the invalid prove() call.

Other Notes

Some of these are your design decisions, but how I'd do it

Since the guard is it's own module, it should use its own database. Unlike the current relayer, this can basically consist of a pending_proven table with txid txhash status

status is a dbcommon.Enum of:

• ProveCalled - a relayer has called Prove() on on a contract we are monitoring
• Validated - getBridgeTransaction() is called on the destination chain. If the request was relayed we get this status
• DisputePending - getBridgeTransaction() is called on the destination chain and the tx doesn't actually exist. At this point we've submitted dispute() but it has not been confirmed on chain yet
• Disputed dispute has been confirmed on chain

I'd pursue the same event structure we currently have now w/ listener & db sourcing.

Other things to do:

• Add a guard page to docs/bridge/rfq
• update relayer page w/ a guard section (which is optional) & a lnik to guard page
• Add metrics:
  • txes by status (I'd honestly recommend making this generic to any table w/ a status column and a dbcommon.Enum as status, than periodically trigger it into an observable.
• add tracing: wherever you think appropriate

[greptile-apps]

Implementation Steps for RFQ Guard

1. Create Guard Command:

   • Add a new command rfq-guard in /services/rfq/cmd/guard.go.
   • Implement functionality to monitor prove() calls on the origin chain.
   • Verify the existence of the corresponding event on the destination chain.
   • Call dispute() on the FastBridge contract if the event does not exist on the destination chain.

2. Update Relayer for Optional Guard Functionality:

   • Add a configuration option in the relayer's settings (/services/rfq/relayer/relconfig/config.go) to enable or disable the guard functionality.
   • Modify the relayer initialization (/services/rfq/relayer/service/relayer.go) to optionally start the guard functionality based on the configuration.

3. Database Schema:

   • Create a new database schema for the guard in /services/rfq/relayer/reldb/guard_schema.sql with a pending_proven table.
   • Define status as a dbcommon.Enum with values: ProveCalled, Validated, DisputePending, Disputed.

4. Event Handling:

   • Extend the event handling logic in /services/rfq/relayer/service/handlers.go to include guard-specific events.
   • Implement functions to handle prove() and dispute() events.

5. Documentation:

   • Add a guard page to docs/bridge/rfq/guard.md.
   • Update the relayer page with a guard section and a link to the guard page.

6. Metrics and Tracing:

   • Add metrics for transactions by status in /services/rfq/relayer/metrics/metrics.go.
   • Add tracing where appropriate in the guard command and relayer service.

References

/services/rfq/relayer/service/handlers.go
/services/rfq/relayer/service/relayer.go
/services/rfq/relayer
/docs/bridge/docs/rfq
/services/rfq/api

About Greptile

This response provides a starting point for your research, not a precise solution.

Help us improve! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

Ask Greptile · Edit Issue Bot Settings