From c2edaf672b65010f27366f185ae518dfc2a1b4b0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Migone?= Date: Thu, 30 Apr 2026 17:02:06 -0300 Subject: [PATCH] docs!: rename docs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Tomás Migone --- CONTRIBUTING.md | 6 +- README.md | 71 ++++--- crates/aggregator/README.md | 216 ++++++---------------- crates/aggregator/src/error_codes.rs | 4 +- crates/aggregator/src/server.rs | 2 +- crates/core/src/error.rs | 2 +- crates/core/src/lib.rs | 4 +- crates/core/src/manager/adapters/mod.rs | 2 +- crates/core/src/manager/context/memory.rs | 4 +- crates/core/src/manager/context/mod.rs | 2 +- crates/core/src/manager/mod.rs | 6 +- crates/graph/src/lib.rs | 2 +- crates/receipt/src/lib.rs | 2 +- 13 files changed, 105 insertions(+), 218 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5e1c885..1f9c02c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,5 +1,5 @@ -# Contributing to TAP +# Contributing to Graph Tally First off, thanks for taking the time to contribute! ❤️ @@ -100,7 +100,7 @@ Once it's filed: ### Suggesting Enhancements -This section guides you through submitting an enhancement suggestion for TAP, **including completely new features and minor improvements to existing functionality**. Following these guidelines will help maintainers and the community to understand your suggestion and find related suggestions. +This section guides you through submitting an enhancement suggestion for Graph Tally, **including completely new features and minor improvements to existing functionality**. Following these guidelines will help maintainers and the community to understand your suggestion and find related suggestions. #### Before Submitting an Enhancement @@ -119,7 +119,7 @@ Enhancement suggestions are tracked as [GitHub issues](https://github.com/graphp - Provide a **step-by-step description of the suggested enhancement** in as many details as possible. - **Describe the current behavior** and **explain which behavior you expected to see instead** and why. At this point you can also tell which alternatives do not work for you. - You may want to **include screenshots and animated GIFs** which help you demonstrate the steps or point out the part which the suggestion is related to. You can use [this tool](https://www.cockos.com/licecap/) to record GIFs on macOS and Windows, and [this tool](https://github.com/colinkeenan/silentcast) or [this tool](https://github.com/GNOME/byzanz) on Linux. -- **Explain why this enhancement would be useful** to most TAP users. You may also want to point out the other projects that solved it better and which could serve as inspiration. +- **Explain why this enhancement would be useful** to most Graph Tally users. You may also want to point out the other projects that solved it better and which could serve as inspiration. diff --git a/README.md b/README.md index 01aa5f9..4783de5 100644 --- a/README.md +++ b/README.md @@ -1,84 +1,83 @@ -# Timeline Aggregation Protocol (TAP) +# Graph Tally (Timeline Aggregation Protocol) -| Crate | Latest Version | -| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **tap_aggregator** | [![GHCR](https://img.shields.io/github/v/release/graphprotocol/timeline-aggregation-protocol?filter=tap_aggregator-*&label=ghcr.io)](https://github.com/graphprotocol/timeline-aggregation-protocol/pkgs/container/tap_aggregator) | -| **tap_core** | [![GitHub Release](https://img.shields.io/github/v/release/graphprotocol/timeline-aggregation-protocol?filter=tap_core-*)](https://github.com/graphprotocol/timeline-aggregation-protocol/releases) | -| **tap_eip712_message** | [![GitHub Release](https://img.shields.io/github/v/release/graphprotocol/timeline-aggregation-protocol?filter=tap_eip712_message-*)](https://github.com/graphprotocol/timeline-aggregation-protocol/releases) | -| **tap_graph** | [![GitHub Release](https://img.shields.io/github/v/release/graphprotocol/timeline-aggregation-protocol?filter=tap_graph-*)](https://github.com/graphprotocol/timeline-aggregation-protocol/releases) | -| **tap_receipt** | [![GitHub Release](https://img.shields.io/github/v/release/graphprotocol/timeline-aggregation-protocol?filter=tap_receipt-*)](https://github.com/graphprotocol/timeline-aggregation-protocol/releases) | +| Crate | Latest Version | +| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **graph_tally_aggregator** | [![GHCR](https://img.shields.io/github/v/release/graphprotocol/timeline-aggregation-protocol?filter=graph_tally_aggregator-*&label=ghcr.io)](https://github.com/graphprotocol/timeline-aggregation-protocol/pkgs/container/graph_tally_aggregator) | +| **graph_tally_core** | [![GitHub Release](https://img.shields.io/github/v/release/graphprotocol/timeline-aggregation-protocol?filter=graph_tally_core-*)](https://github.com/graphprotocol/timeline-aggregation-protocol/releases) | +| **graph_tally_eip712_message** | [![GitHub Release](https://img.shields.io/github/v/release/graphprotocol/timeline-aggregation-protocol?filter=graph_tally_eip712_message-*)](https://github.com/graphprotocol/timeline-aggregation-protocol/releases) | +| **graph_tally_graph** | [![GitHub Release](https://img.shields.io/github/v/release/graphprotocol/timeline-aggregation-protocol?filter=graph_tally_graph-*)](https://github.com/graphprotocol/timeline-aggregation-protocol/releases) | +| **graph_tally_receipt** | [![GitHub Release](https://img.shields.io/github/v/release/graphprotocol/timeline-aggregation-protocol?filter=graph_tally_receipt-*)](https://github.com/graphprotocol/timeline-aggregation-protocol/releases) | ## 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 +Graph Tally (formerly TAP - Timeline Aggregation Protocol) facilitates a series of payments from a +sender to a receiver (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. ## Documentation for Individual Components -- [tap_aggregator](tap_aggregator/README.md) -- [tap_core](tap_core/README.md) - links to this `README` for now. +- [graph_tally_aggregator](crates/aggregator/README.md) ## 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 +- **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 +- **ReceiptAggregateVoucher (RAV):** A signed message containing the aggregate value of the receipts. -- **tap_aggregator:** A service managed by the sender that aggregates receipts +- **graph_tally_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 +- **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 +- 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 +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 +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 +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, +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, +5. **Signing the RAV:** The receiver sends the RAV request to the graph_tally_aggregator, which signs it into a new RAV. -6. **Tracking Aggregate Value:** The receiver tracks the aggregate value and +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 +7. **Requesting a New RAV:** The receiver sends new receipts and the last RAV +to the graph_tally_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. +- The primary performance limitations are the time required to verify receipts +and network limitations for sending requests to the graph_tally_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 +- Graph Tally 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 +- 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 +Contributions are welcome! Please submit a pull request or open an issue to discuss potential changes. -Also, make sure to follow the [Contributing Guide](https://github.com/graphprotocol/timeline-aggregation-protocol/blob/main/CONTRIBUTING.md). \ No newline at end of file +Also, make sure to follow the [Contributing Guide](https://github.com/graphprotocol/timeline-aggregation-protocol/blob/main/CONTRIBUTING.md). diff --git a/crates/aggregator/README.md b/crates/aggregator/README.md index 631c3e5..7655333 100644 --- a/crates/aggregator/README.md +++ b/crates/aggregator/README.md @@ -1,23 +1,21 @@ -# TAP Aggregator +# Graph Tally Aggregator A stateless JSON-RPC service that lets clients request an aggregate receipt from a list of individual receipts. -Supports both V1 (allocation-based) and V2 (collection-based) aggregation protocols for seamless migration to the Horizon protocol. - -TAP Aggregator is run by [gateway](https://github.com/edgeandnode/gateway/blob/main/README.md) +Graph Tally Aggregator is run by [gateway](https://github.com/edgeandnode/gateway/blob/main/README.md) operators. -As described in the [gateway README section on TAP](https://github.com/edgeandnode/gateway/blob/main/README.md#tap): +As described in the [gateway README section on Graph Tally](https://github.com/edgeandnode/gateway/blob/main/README.md#tap): -> The `gateway` acts as a TAP sender, where each indexer request is sent with a TAP receipt. The `gateway` operator is expected to run 2 additional services: +> The `gateway` acts as a Graph Tally sender, where each indexer request is sent with a receipt. The `gateway` operator is expected to run 2 additional services: > -> - `tap-aggregator` (this crate!): public endpoint where indexers can aggregate receipts into RAVs -> - [tap-escrow-manager](https://github.com/edgeandnode/tap-escrow-manager): maintains escrow balances for the TAP sender. This service requires data exported by the gateway into the "indexer requests" topic to calculate the value of outstanding receipts to each indexer. +> - `graph_tally_aggregator` (this crate!): public endpoint where indexers can aggregate receipts into RAVs +> - [tap-escrow-manager](https://github.com/edgeandnode/tap-escrow-manager): maintains escrow balances for the sender. This service requires data exported by the gateway into the "indexer requests" topic to calculate the value of outstanding receipts to each indexer. > > The `gateway` operator is also expected to manage at least 2 wallets: > -> - sender: requires ETH for transaction gas and GRT to allocate into TAP escrow balances for paying indexers -> - authorized signer: used by the `gateway` and `tap-aggregator` to sign receipts and RAVs +> - sender: requires ETH for transaction gas and GRT to allocate into escrow balances for paying indexers +> - authorized signer: used by the `gateway` and `graph_tally_aggregator` to sign receipts and RAVs ## Settings @@ -25,23 +23,33 @@ As described in the [gateway README section on TAP](https://github.com/edgeandno A JSON-RPC service for the Timeline Aggregation Protocol that lets clients request an aggregate receipt from a list of individual receipts. -Usage: tap_aggregator [OPTIONS] --private-key +Usage: graph_tally_aggregator [OPTIONS] --private-key Options: --port - Port to listen on for JSON-RPC requests [env: TAP_PORT=] [default: 8080] + Port to listen on for JSON-RPC requests [env: GRAPH_TALLY_PORT=] [default: 8080] --private-key - Sender private key for signing Receipt Aggregate Vouchers, as a hex string [env: TAP_PRIVATE_KEY=] + Sender private key for signing Receipt Aggregate Vouchers, as a hex string [env: GRAPH_TALLY_PRIVATE_KEY=] + --public-keys + Signer public keys for incoming receipts/RAVs [env: GRAPH_TALLY_PUBLIC_KEYS=] --max-request-body-size - Maximum request body size in bytes. Defaults to 10MB [env: TAP_MAX_REQUEST_BODY_SIZE=] [default: 10485760] + Maximum request body size in bytes. Defaults to 10MB [env: GRAPH_TALLY_MAX_REQUEST_BODY_SIZE=] [default: 10485760] --max-response-body-size - Maximum response body size in bytes. Defaults to 100kB [env: TAP_MAX_RESPONSE_BODY_SIZE=] [default: 102400] + Maximum response body size in bytes. Defaults to 100kB [env: GRAPH_TALLY_MAX_RESPONSE_BODY_SIZE=] [default: 102400] --max-connections - Maximum number of concurrent connections. Defaults to 32 [env: TAP_MAX_CONNECTIONS=] [default: 32] + Maximum number of concurrent connections. Defaults to 32 [env: GRAPH_TALLY_MAX_CONNECTIONS=] [default: 32] --request-timeout-secs Maximum time in seconds allowed for processing a request. This timeout protects against Slowloris-style DoS attacks by ensuring that connections cannot be held open indefinitely. - Defaults to 60 seconds [env: TAP_REQUEST_TIMEOUT_SECS=] [default: 60] + Defaults to 60 seconds [env: GRAPH_TALLY_REQUEST_TIMEOUT_SECS=] [default: 60] + --metrics-port + Metrics server port [env: GRAPH_TALLY_METRICS_PORT=] [default: 5000] + --domain-chain-id + Domain chain ID for EIP-712 domain separator [env: GRAPH_TALLY_DOMAIN_CHAIN_ID=] + --domain-verifying-contract + Domain verifying contract for EIP-712 domain separator [env: GRAPH_TALLY_DOMAIN_VERIFYING_CONTRACT=] + --kafka-config + Kafka configuration [env: GRAPH_TALLY_KAFKA_CONFIG=] -h, --help Print help -V, --version @@ -50,9 +58,27 @@ Options: Please refer to [GraphTallyCollector](https://github.com/graphprotocol/contracts/blob/main/packages/horizon/contracts/payments/collectors/GraphTallyCollector.sol) for more information about Receipt Aggregate Voucher signing keys. +### Deprecated Environment Variables + +For backwards compatibility, the following `TAP_*` environment variables are still supported but deprecated: + +| Deprecated | Use Instead | +|------------|-------------| +| `TAP_PORT` | `GRAPH_TALLY_PORT` | +| `TAP_PRIVATE_KEY` | `GRAPH_TALLY_PRIVATE_KEY` | +| `TAP_PUBLIC_KEYS` | `GRAPH_TALLY_PUBLIC_KEYS` | +| `TAP_MAX_REQUEST_BODY_SIZE` | `GRAPH_TALLY_MAX_REQUEST_BODY_SIZE` | +| `TAP_MAX_RESPONSE_BODY_SIZE` | `GRAPH_TALLY_MAX_RESPONSE_BODY_SIZE` | +| `TAP_MAX_CONNECTIONS` | `GRAPH_TALLY_MAX_CONNECTIONS` | +| `TAP_REQUEST_TIMEOUT_SECS` | `GRAPH_TALLY_REQUEST_TIMEOUT_SECS` | +| `TAP_METRICS_PORT` | `GRAPH_TALLY_METRICS_PORT` | +| `TAP_DOMAIN_CHAIN_ID` | `GRAPH_TALLY_DOMAIN_CHAIN_ID` | +| `TAP_DOMAIN_VERIFYING_CONTRACT` | `GRAPH_TALLY_DOMAIN_VERIFYING_CONTRACT` | +| `TAP_KAFKA_CONFIG` | `GRAPH_TALLY_KAFKA_CONFIG` | + ## Operational recommendations -This is just meant to be a non-exhaustive list of reminders for safely operating the TAP Aggregator. It being an HTTP +This is just meant to be a non-exhaustive list of reminders for safely operating the Graph Tally Aggregator. It being an HTTP service, use your best judgement and apply the industry-standard best practices when serving HTTP to the public internet. @@ -64,7 +90,7 @@ internet. - HTTP response inspection. - JSON request and response inspection. To validate the inputs, as well as parse JSON-RPC error codes in the response. -It is also recommended that clients use HTTP compression for their HTTP requests to the TAP Aggregator, as RAV requests +It is also recommended that clients use HTTP compression for their HTTP requests to the Graph Tally Aggregator, as RAV requests can be quite large. ## JSON-RPC API @@ -193,16 +219,11 @@ In addition to the official spec, we define a few special errors: ### Methods -This aggregator supports both V1 (legacy) and V2 (Horizon) protocols: - -- **V1 Endpoints**: `aggregate_receipts` - allocation-based aggregation -- **V2 Endpoints**: `aggregate_receipts_v2` - collection-based aggregation with enhanced fields - #### `api_versions()` [source](server::RpcServer::api_versions) -Returns the versions of the TAP JSON-RPC API implemented by this server. +Returns the versions of the Graph Tally JSON-RPC API implemented by this server. Example: @@ -250,92 +271,9 @@ We recommend that the server is set-up to support a maximum HTTP request size of `aggregate_receipts` support a maximum of at least 15,000 receipts per call. If you have more than 15,000 receipts to aggregate, we recommend calling `aggregate_receipts` multiple times. -Example: - -*Request*: - -```json -{ - "jsonrpc": "2.0", - "id": 0, - "method": "aggregate_receipts", - "params": [ - "0.0", - [ - { - "message": { - "allocation_id": "0xabababababababababababababababababababab", - "timestamp_ns": 1685670449225087255, - "nonce": 11835827017881841442, - "value": 34 - }, - "signature": { - "r": "0xa9fa1acf3cc3be503612f75602e68cc22286592db1f4f944c78397cbe529353b", - "s": "0x566cfeb7e80a393021a443d5846c0734d25bcf54ed90d97effe93b1c8aef0911", - "v": 27 - } - }, - { - "message": { - "allocation_id": "0xabababababababababababababababababababab", - "timestamp_ns": 1685670449225830106, - "nonce": 17711980309995246801, - "value": 23 - }, - "signature": { - "r": "0x51ca5a2b839558654326d3a3f544a97d94effb9a7dd9cac7492007bc974e91f0", - "s": "0x3d9d398ea6b0dd9fac97726f51c0840b8b314821fb4534cb40383850c431fd9e", - "v": 28 - } - } - ], - { - "message": { - "allocation_id": "0xabababababababababababababababababababab", - "timestamp_ns": 1685670449224324338, - "value_aggregate": 101 - }, - "signature": { - "r": "0x601a1f399cf6223d1414a89b7bbc90ee13eeeec006bd59e0c96042266c6ad7dc", - "s": "0x3172e795bd190865afac82e3a8be5f4ccd4b65958529986c779833625875f0b2", - "v": 28 - } - } - ] -} -``` - -*Response*: +**Receipt Structure:** -```json -{ - "id": 0, - "jsonrpc": "2.0", - "result": { - "data": { - "message": { - "allocation_id": "0xabababababababababababababababababababab", - "timestamp_ns": 1685670449225830106, - "value_aggregate": 158 - }, - "signature": { - "r": "0x60eb38374119bbabf1ac6960f532124ba2a9c5990d9fb50875b512e611847eb5", - "s": "0x1b9a330cc9e2ecbda340a4757afaee8f55b6dbf278428f8cf49dd5ad8438f83d", - "v": 27 - } - } - } -} -``` - -#### `aggregate_receipts_v2(api_version, receipts, previous_rav)` - -Aggregates the given V2 receipts into a V2 receipt aggregate voucher using the Horizon protocol. -This method supports collection-based aggregation with enhanced fields for payer, data service, and service provider tracking. - -**V2 Receipt Structure:** - -- `collection_id`: 32-byte identifier for the collection (replaces `allocation_id`) +- `collection_id`: 32-byte identifier for the collection - `payer`: Address of the payer - `data_service`: Address of the data service - `service_provider`: Address of the service provider @@ -343,9 +281,9 @@ This method supports collection-based aggregation with enhanced fields for payer - `nonce`: Unique nonce - `value`: Receipt value -**V2 RAV Structure:** +**RAV Structure:** -- `collectionId`: Collection identifier (replaces `allocation_id`) +- `collectionId`: Collection identifier - `payer`: Payer address - `dataService`: Data service address - `serviceProvider`: Service provider address @@ -361,9 +299,9 @@ Example: { "jsonrpc": "2.0", "id": 0, - "method": "aggregate_receipts_v2", + "method": "aggregate_receipts", "params": [ - "1.0.0", + "0.0", [ { "message": { @@ -466,53 +404,3 @@ When Kafka publishing fails, the aggregator: - **Still returns the RAV to the client** (availability over consistency) Operators should alert on `kafka_publish_failure_total > 0` to detect Kafka connectivity issues. If Kafka messages are lost, `tap-escrow-manager` may underestimate debt—see the `debts` config override in tap-escrow-manager for manual recovery. - -## Feature Flags - -### V2 Protocol Support - -The aggregator supports both V1 and V2 protocols: - -- **V2 is enabled by default** via the `v2` feature flag in `tap_aggregator/Cargo.toml` -- To disable V2: `cargo build --no-default-features` -- Both protocols can run simultaneously for gradual migration -- V1 endpoints remain unchanged and fully functional - -### Feature Flag Usage - -```bash -# Build with V2 support (default) -cargo build --release - -# Build without V2 support (V1 only) -cargo build --release --no-default-features - -# Explicitly enable V2 feature -cargo build --release --features v2 -``` - -## Migration Guide - -### V1 to V2 Migration - -The V2 protocol introduces collection-based aggregation with enhanced tracking. Here's how to migrate: - -#### Key Changes - -1. **Receipt Structure**: `allocation_id` → `collection_id` + additional fields -2. **RAV Structure**: `allocation_id` → `collectionId` + additional fields -3. **New Fields**: `payer`, `data_service`/`dataService`, `service_provider`/`serviceProvider` -4. **Metadata**: V2 RAVs include optional `metadata` field - -#### Migration Steps - -1. **Phase 1**: Deploy aggregator with V2 support (both endpoints available) -2. **Phase 2**: Update clients to use V2 receipt structure -3. **Phase 3**: Switch clients to `aggregate_receipts_v2` endpoint -4. **Phase 4**: V1 endpoints remain for backward compatibility - -#### Backward Compatibility - -- **V1 endpoints**: Unchanged and fully functional -- **gRPC support**: Both V1 and V2 with automatic conversion -- **No breaking changes**: Existing V1 clients continue to work diff --git a/crates/aggregator/src/error_codes.rs b/crates/aggregator/src/error_codes.rs index e412014..f5410e6 100644 --- a/crates/aggregator/src/error_codes.rs +++ b/crates/aggregator/src/error_codes.rs @@ -1,4 +1,4 @@ -//! Module containing error and warning codes used by the TAP aggregator JSON-RPC API. +//! Module containing error and warning codes used by the Graph Tally aggregator JSON-RPC API. //! //! The JSON-RPC spec allocates error codes in the range `[-32000, -32099]` for application errors. We chose to use that //! range for both errors and warnings. We also chose error and warning codes that do not overlap, to reduce confusion. @@ -6,7 +6,7 @@ //! - Errors: `[-32000, -32049]`, where `-32000` is reserved for all errors without a specific code. //! - Warnings: `[-32050, -32099]`, where `-32050` is reserved for all warnings without a specific code. -/// JSON-RPC error codes specific to the TAP aggregator. +/// JSON-RPC error codes specific to the Graph Tally aggregator. #[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)] pub enum JsonRpcErrorCode { /// -32000 -- Generic error. diff --git a/crates/aggregator/src/server.rs b/crates/aggregator/src/server.rs index 3518875..5bc7593 100644 --- a/crates/aggregator/src/server.rs +++ b/crates/aggregator/src/server.rs @@ -86,7 +86,7 @@ lazy_static! { /// Do not forget to update the documentation there if you make any changes to the JSON-RPC API. #[rpc(server)] pub trait Rpc { - /// Returns the versions of the TAP JSON-RPC API implemented by this server. + /// Returns the versions of the Graph Tally JSON-RPC API implemented by this server. #[method(name = "api_versions")] fn api_versions(&self) -> JsonRpcResult; diff --git a/crates/core/src/error.rs b/crates/core/src/error.rs index 3bfe8c2..c9c32dd 100644 --- a/crates/core/src/error.rs +++ b/crates/core/src/error.rs @@ -8,7 +8,7 @@ use thiserror::Error as ThisError; use crate::receipt::ReceiptError; -/// Error type for the TAP protocol +/// Error type for the Graph Tally protocol #[derive(ThisError, Debug)] pub enum Error { /// Error when trying to aggregate receipts and the result overflows diff --git a/crates/core/src/lib.rs b/crates/core/src/lib.rs index feac08f..4e3a09f 100644 --- a/crates/core/src/lib.rs +++ b/crates/core/src/lib.rs @@ -5,7 +5,7 @@ //! //! ## Getting started //! -//! To get started with the TAP protocol, take a look on the [`manager`] module +//! To get started with the Graph Tally protocol, take a look on the [`manager`] module //! to see how to manage the state channel and implement the needed adapters. use std::time::{SystemTime, UNIX_EPOCH}; @@ -31,7 +31,7 @@ fn get_current_timestamp_u64_ns() -> Result { .as_nanos() as u64) } -/// The EIP712 domain separator builder for the TAP protocol. +/// The EIP712 domain separator builder for the Graph Tally protocol. /// /// This is the current domain separator that is used for the [EIP712](https://eips.ethereum.org/EIPS/eip-712) signature scheme. /// diff --git a/crates/core/src/manager/adapters/mod.rs b/crates/core/src/manager/adapters/mod.rs index ff9ea7c..8d1c2c2 100644 --- a/crates/core/src/manager/adapters/mod.rs +++ b/crates/core/src/manager/adapters/mod.rs @@ -1,4 +1,4 @@ -//! Context adapters for the TAP manager. +//! Context adapters for the Graph Tally manager. //! //! Each adapter should be defined by the user of the library based on their //! specific storage and verification requirements. This modular design diff --git a/crates/core/src/manager/context/memory.rs b/crates/core/src/manager/context/memory.rs index 18a9f95..22b9abb 100644 --- a/crates/core/src/manager/context/memory.rs +++ b/crates/core/src/manager/context/memory.rs @@ -1,6 +1,6 @@ -//! In-memory context implementation for the TAP manager. +//! In-memory context implementation for the Graph Tally manager. //! -//! This module provides an in-memory implementation of the TAP manager context. +//! This module provides an in-memory implementation of the Graph Tally manager context. //! It is useful for testing and development purposes. use std::{ diff --git a/crates/core/src/manager/context/mod.rs b/crates/core/src/manager/context/mod.rs index e9abbcf..7fca44b 100644 --- a/crates/core/src/manager/context/mod.rs +++ b/crates/core/src/manager/context/mod.rs @@ -1,6 +1,6 @@ //! Context implementations. //! -//! Contexts are used to store and retrieve data from the TAP manager. +//! Contexts are used to store and retrieve data from the Graph Tally manager. //! They are used to store receipts, escrow, and other data that is required //! for the manager to function. //! Currently, there's only one context implementation available, which is diff --git a/crates/core/src/manager/mod.rs b/crates/core/src/manager/mod.rs index eec9ff7..11c05ce 100644 --- a/crates/core/src/manager/mod.rs +++ b/crates/core/src/manager/mod.rs @@ -1,10 +1,10 @@ -//! Point of entry for managing TAP receipts and RAVs. +//! Point of entry for managing Graph Tally receipts and RAVs. //! -//! The [`crate::manager`] module provides facilities for managing TAP receipt +//! The [`crate::manager`] module provides facilities for managing Graph Tally receipt //! and RAV validation, as well as storage flow. //! //! This module should be the primary interface for the receiver of funds to -//! verify, store, and manage TAP receipts and RAVs. +//! verify, store, and manage Graph Tally receipts and RAVs. //! The [`Manager`] struct within this module allows the user to specify what //! checks should be performed on receipts, as well as //! when these checks should occur (either when a receipt is first received, diff --git a/crates/graph/src/lib.rs b/crates/graph/src/lib.rs index b2a66ff..b687024 100644 --- a/crates/graph/src/lib.rs +++ b/crates/graph/src/lib.rs @@ -1,4 +1,4 @@ -//! # The Graph TAP structs +//! # Graph Tally structs //! //! These structs are used for communication between The Graph systems. //! diff --git a/crates/receipt/src/lib.rs b/crates/receipt/src/lib.rs index 67456a3..f8c483d 100644 --- a/crates/receipt/src/lib.rs +++ b/crates/receipt/src/lib.rs @@ -33,7 +33,7 @@ pub type ReceiptResult = Result; /// Extra information for [checks::Check] pub type Context = anymap3::Map; -/// Extension that allows TAP Aggregation for any SolStruct receipt +/// Extension that allows Graph Tally Aggregation for any SolStruct receipt pub trait WithValueAndTimestamp { fn value(&self) -> u128; fn timestamp_ns(&self) -> u64;