#receipt #tap #sender #aggregate #timeline #aggregation #rav

tap_core

Core Timeline Aggregation Protocol library: a fast, efficient and trustless unidirectional micro-payments system

10 releases (1 stable)

1.0.0 Mar 28, 2024
0.8.0 Mar 13, 2024
0.7.0 Nov 28, 2023
0.3.0 Jul 31, 2023

#2078 in Magic Beans

Download history 9/week @ 2023-12-28 54/week @ 2024-01-04 83/week @ 2024-01-11 16/week @ 2024-01-18 11/week @ 2024-01-25 27/week @ 2024-02-01 2/week @ 2024-02-15 9/week @ 2024-02-22 4/week @ 2024-02-29 79/week @ 2024-03-07 92/week @ 2024-03-14 15/week @ 2024-03-21 205/week @ 2024-03-28 153/week @ 2024-04-04

539 downloads per month
Used in tap_aggregator

Apache-2.0

80KB
1.5K SLoC

Timeline Aggregation Protocol (TAP)

Overview

The TAP (Timeline Aggregation Protocol) facilitates a series of payments from a sender to a receiver (TAP Receipts), who aggregates these payments into a single payment (a Receipt Aggregate Voucher, or RAV). This aggregate payment can then be verified on-chain by a payment verifier, reducing the number of transactions and simplifying the payment process.

Key Components

  • Sender: Initiates the payment.
  • Receiver: Receives the payment.
  • Signers: Multiple signers authorized by the sender to sign receipts.
  • State Channel: A one-way channel opened by the sender with the receiver for sending receipts.
  • Receipt: A record of payment sent by the sender to the receiver.
  • ReceiptAggregateVoucher (RAV): A signed message containing the aggregate value of the receipts.
  • tap_aggregator: A service managed by the sender that aggregates receipts on the receiver's request into a signed RAV.
  • EscrowAccount: An account created in the blockchain to hold funds for the sender-receiver pair.

Security Measures

  • The protocol uses asymmetric cryptography (ECDSA secp256k1) to sign and verify messages, ensuring the integrity of receipts and RAVs.

Process

  1. Opening a State Channel: A state channel is opened via a blockchain contract, creating an EscrowAccount for the sender-receiver pair.
  2. Sending Receipts: The sender sends receipts to the receiver through the state channel.
  3. Storing Receipts: The receiver stores the receipts and tracks the aggregate payment.
  4. Creating a RAV Request: A RAV request consists of a list of receipts and, optionally, the previous RAV.
  5. Signing the RAV: The receiver sends the RAV request to the tap_aggregator, which signs it into a new RAV.
  6. Tracking Aggregate Value: The receiver tracks the aggregate value and new receipts since the last RAV.
  7. Requesting a New RAV: The receiver sends new receipts and the last RAV to the tap_aggregator for a new RAV.
  8. Closing the State Channel: When the allocation period ends, the receiver can send the last RAV to the blockchain and receive payment from the EscrowAccount.

Performance Considerations

  • The primary performance limitations are the time required to verify receipts and network limitations for sending requests to the tap_aggregator.

Use Cases

  • The TAP protocol is suitable for systems that need unidirectional, parallel micro-payments that are too expensive to redeem individually on-chain. By aggregating operations off-chain and redeeming them in one transaction, costs are drastically reduced.

Compatibility

  • The current implementation is for EVM-compatible blockchains, with most of the system being off-chain.

Contributing

Contributions are welcome! Please submit a pull request or open an issue to discuss potential changes. Also, make sure to follow the Contributing Guide.

Dependencies

~31–49MB
~1M SLoC