You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
query the DB for all RAVs with final=true status, and parse resulted rav into SignedRAV[]
As the escrow contract is lacking a redeemMany function, the manager loop through individual SignedRav and build transaction params for separate transactions
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
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
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> 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 of keccak256(indexerAddress,allocationID), so we can implement a helper function that computes the proof (another version of allocationSigner = (wallet: Wallet, allocation: Allocation): string)
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
The text was updated successfully, but these errors were encountered:
General flow
The Indexer agent
AllocationReceiptManager
shouldfinal=true
status, and parse resulted rav intoSignedRAV[]
redeemMany
function, the manager loop through individualSignedRav
and build transaction params for separate transactionstransactionManager
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 fieldescrow.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
tablerav JSON column is the EIP712 payload serialized into JSON, and redeem is to be done only if
final
istrue
, and are of typeEIP712SignedMessage<ReceiptAggregateVoucher>
. Types defined : eip_712_signed_message.rs, receipt_aggregate_voucher.rsWe can defined a
ReceiptAggregateVoucher
andSignedReceiptAggregateVoucher
TS type to cast the rav JSON entry after querying from the DB. DB models should live nearReceipts
andVouchers
.Prepare redeem transaction to the escrow contract
Escrow contract redeem implementation
redeem
is allocation specific, sosignedRAV
must be queried with filter ofallocation_id
andfinal = true
.allocationIDProof
, which indexer-agent typically generated when creating an allocate transaction on-chain.allocationSigner
by allocation idproof
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
)AllocationReceiptManager
, indexed byallocationID
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 ofReceipts
andVouchers
. 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
AllocationIdTracker.isAllocationIdUsed
to make sure an allocation RAV has been redeemed. Or, let it be implied by waiting for a valid transaction receipt.The text was updated successfully, but these errors were encountered: