The Graph - Time Aggregation Protocol - TAP

https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0054-timeline-aggregation-protocol.md

Here is a summary of the key points from the text:

• The proposed Timeline Aggregation Protocol (TAP) extends the existing Scalar payment system between Indexers and Gateways in The Graph network.

• TAP uses Receipts, Receipt Aggregate Vouchers (RAVs), and Allocations to manage services and payments. Receipts are promissory notes from Gateways to Indexers. RAVs aggregate receipts and allow Indexers to redeem debts. Allocations define the validity period for Receipts/RAVs.

• Cryptographic signing is used to ensure integrity and authenticity of Receipts and RAVs. Receipts are signed by Gateways, binding them to the Gateway. RAVs aggregate Receipts and are also signed by Gateways.

• Receipts and RAVs can only be used once per Allocation to prevent fraud.

• TAP enables Indexers to efficiently prove total sum of Receipts on-chain.

• TAP aims to minimize trust requirements between Gateways and Indexers, be scalable, provide fast aggregation, and enable cheap on-chain verification.

• The implementation uses standard cryptography like ECDSA signatures. It was assessed internally and externally for vulnerabilities.

• Alternatives like state channels, SNARKs, and homomorphic signatures were explored but did not fully meet the design goals.

How are Receipts generated?

Gateways continuously send TAP receipts along with query requests to the Indexers. So it seems Receipts are generated by the Gateways for each query request sent to the Indexers, as a way to represent the payment owed for serving that query.

Why didn't state channels, SNARKs and homomorphic signatures meet the design goals?

The text provides some details on why state channels, SNARKs, and homomorphic signatures did not fully meet the design goals:

State Channels:

• Slow, serial channel creation throttled throughput
• Inefficient use of capital by allocating to individual channels
• Fragile failure modes not designed for distributed systems
• Higher trust requirements between participants
• Latency added in critical query serving path
• Inefficient bandwidth usage

SNARKs:

• High cost for on-chain proofs at scale
• Non-transparent SNARKs require trust assumptions

Homomorphic Signatures:

• Difficulty achieving robustness, speed, and security together
• Reliance on micro-trust removed benefit of novel cryptography

So in summary, they had issues with performance, cost, security assumptions, or ability to scale sufficiently for the payment system goals.