Skip to content

[feature]: Improve ChainPorter proof verification and storage logic #1835

@ffranr

Description

@ffranr

ChainPorter manages the outbound asset transfer process on the sender node when transferring a Taproot Asset on-chain. Its proof verification and storage logic can be improved in the following ways:

1. Replace proof.FileArchiver with proof.MultiArchiver as ChainPorterConfig.ProofWriter.

This would allow proofs to be written both to the file system and to the database (SQLite or Postgres) via tapdb.AssetStore. Database storage enables operators to benefit from features like Postgres replication and simplifies proof persistence and recovery.

2. Enforce proof verification within all proof archivers.

Each proof archiver should verify proofs prior to import when a proof.VerifierCtx argument is provided. We should add unit tests to confirm this behavior. Currently, for example, proof.FileArchiver.ImportProofs ignores the verifier argument and performs no verification. This means that passive asset proofs are accepted without validation, even though the code suggests otherwise (see chain_porter.go#L522-L537).

3. Perform partial output proof verification earlier in the ChainPorter state machine.

At present, output proofs are only verified during proof storage in ChainPorter.storeProofs, which runs in the SendStateStorePostAnchorTxConf state. This happens after the anchor transaction has already confirmed on-chain, introducing the risk of unrecoverable fund loss if verification fails.

To reduce this risk, ChainPorter should verify all input proofs in full and perform partial verification on output proofs before the anchor transaction is broadcast. Partial verification should include all checks that do not depend on block data, which can then be completed once block details are available. This could be implemented as a new state immediately before SendStateStorePreBroadcast.

For reference, input proofs are already verified during SendStateVirtualSign, which occurs before signing and allows the transfer to be safely aborted if verification fails.

Metadata

Metadata

Assignees

No one assigned

    Projects

    Status

    🆕 New

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions