indexer
indexer copied to clipboard
Feat: Indexer agent collect TAP receipts
General flow
The Indexer agent AllocationReceiptManager
should
- query the DB for all RAVs with
final=true
status, and parse resulted rav intoSignedRAV[]
- As the escrow contract is lacking a
redeemMany
function, the manager loop through individualSignedRav
and build transaction params for separate transactions - Manager use
transactionManager
to first estimate gas and then execute transaction tocontracts.escrow.redeem(signedRAV, allocationIDProof)
. I propose to replaceAllocationReceiptManager
'sAllocationExchange
field with contracts containing network contracts, or simply haveescrow: Contract
as an additional field - 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 aNetworkContracts
field ingraphprotocol/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.- Add Eventual<Vec<Allocation>> to receipt collector and a syncing interval, and compute
allocationSigner
by allocation id - From staking contract docs,
proof
is a 65-bytes Ethereum signed message ofkeccak256(indexerAddress,allocationID)
, so we can implement a helper function that computes the proof (another version ofallocationSigner = (wallet: Wallet, allocation: Allocation): string
) - Have indexer-agent store the proofs and pass into
AllocationReceiptManager
, indexed byallocationID
- Add Eventual<Vec<Allocation>> to receipt collector and a syncing interval, and compute
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