Feat: Indexer agent collect TAP receipts

[hopeyen]

General flow

The Indexer agent AllocationReceiptManager should

1. query the DB for all RAVs with final=true status, and parse resulted rav into SignedRAV[]
2. As the escrow contract is lacking a redeemMany function, the manager loop through individual SignedRav and build transaction params for separate transactions
3. Manager use transactionManager to first estimate gas and then execute transaction to contracts.escrow.redeem(signedRAV, allocationIDProof). I propose to replace AllocationReceiptManager's AllocationExchange field with contracts containing network contracts, or simply have escrow: Contract as an additional field
4. After sending the transaction, use escrow.allocationIDTracker.isAllocationIDUsed for checking success redemption. If used, then the manager can go ahead deleting RAV from DB.

---

RAV into indexer-agent
query DB scalar_tap_ravs table

CREATE TABLE IF NOT EXISTS scalar_tap_ravs (
 allocation_id CHAR(40) NOT NULL,
 sender_address CHAR(40) NOT NULL,
 rav JSON NOT NULL,                           // update JSONB
 final BOOLEAN DEFAULT FALSE NOT NULL,
 PRIMARY KEY (allocation_id, sender_address)
 );

rav JSON column is the EIP712 payload serialized into JSON, and redeem is to be done only if final is true, and are of type EIP712SignedMessage<ReceiptAggregateVoucher>. Types defined : eip_712_signed_message.rs, receipt_aggregate_voucher.rs

pub struct EIP712SignedMessage<M: SolStruct> {
    pub message: M,
    pub signature: Signature,
}

sol! {
    /// Holds information needed for promise of payment signed with ECDSA
    struct ReceiptAggregateVoucher {
        address allocation_id;
        uint64 timestamp_ns;
        uint128 value_aggregate;
    }
}

We can defined a ReceiptAggregateVoucher and SignedReceiptAggregateVoucher TS type to cast the rav JSON entry after querying from the DB. DB models should live near Receipts and Vouchers.

❓ Best way to handle allocationSummary
Voucher ↔ allocationSummary is one-to-one at the moment. Optionally add a VoucherType field to allocationSummary, match relationships based on allocationSummary, require Voucher and RAV to belong to a AllocationSummary and relax the relation from AllocationSummary to Voucher/RAV
Though, easier to just relax AllocationSummary requirement to Voucher and RAV

Prepare redeem transaction to the escrow contract

🛠 Dependency:
Add escrow contract to graphprotocol/contracts and as a NetworkContracts field in graphprotocol/common-ts

Escrow contract redeem implementation

function redeem(
	TAPVerifier.SignedRAV calldata signedRAV,
	bytes calldata allocationIDProof
) external { ... }

redeem is allocation specific, so signedRAV must be queried with filter of allocation_id and final = true.

• The existing voucher redemption doesn't involve allocationIDProof, which indexer-agent typically generated when creating an allocate transaction on-chain.
  1. Add Eventual<Vec> to receipt collector and a syncing interval, and compute allocationSigner by allocation id
  2. From staking contract docs, proof is a 65-bytes Ethereum signed message of keccak256(indexerAddress,allocationID), so we can implement a helper function that computes the proof (another version of allocationSigner = (wallet: Wallet, allocation: Allocation): string)
  3. Have indexer-agent store the proofs and pass into AllocationReceiptManager, indexed by allocationID

send a redeem transaction to the escrow contract

AllocationReceiptManager should periodically check for RAVs that are ready to redeem. This can be alongside its management of Receipts and Vouchers. However, since indexer service is responsible for aggregating RAVs, there will not be an equivalence of exchanging receipts to vouchers.

Let EscrowContract be possible null at first since it hasn't been deployed to all the supported protocol networks yet. Only trigger RAV processes if EscrowContract is defined.

misc considerations

• Utilize AllocationIdTracker.isAllocationIdUsed to make sure an allocation RAV has been redeemed. Or, let it be implied by waiting for a valid transaction receipt.
• Reuse user configs like max redemption threshold, batch threshold (after there is batch options)
• Additional metrics for RAV, to distinguish from Voucher