Skip to content

Conversation

suchapalaver
Copy link
Contributor

@suchapalaver suchapalaver commented Jul 8, 2025

Horizon Gateway Upgrade

This horizon gateway provides TAP v2 receipt generation while maintaining full backward compatibility with existing v1 receipts from the upstream implementation.

Overview

This is a horizon-ready gateway that adds TAP v2 (collection-based) receipt support to the existing edgeandnode/gateway which only supports TAP v1 (allocation-based) receipts. This implementation generates exclusively v2 receipts while maintaining backward compatibility for processing existing v1 receipts.

Key Changes from Pre-Horizon Gateway

TAP Protocol Support

  • Pre-Horizon: Only supports TAP v1 (allocation-based) receipts
  • Horizon: Generates TAP v2 (collection-based) receipts, can process v1 receipts for redemption

Receipt Generation

  • Upstream: Uses create_receipt(allocation, fee) for v1 receipts
  • Horizon: Uses create_receipt(collection, fee, payer, data_service, service_provider) for v2 receipts

ID Types

  • Pre-Horizon: Uses AllocationId for receipt generation and payment tracking
  • Horizon: Uses CollectionId for receipt generation, supports both types for processing

Receipt Structure

v1 Receipts (Pre-Horizon):

  • allocation_id: Address of the allocation
  • timestamp_ns: Timestamp in nanoseconds
  • nonce: Random nonce
  • value: Fee amount in wei

v2 Receipts (Horizon):

  • collection_id: Collection identifier
  • payer: Address of the payer
  • data_service: Address of the data service
  • service_provider: Address of the service provider
  • timestamp_ns: Timestamp in nanoseconds
  • nonce: Random nonce
  • value: Fee amount in wei

Migration from Pre-Horizon

For Operators

  1. Dependencies: Updated tap_graph to support v2 receipts
  2. Configuration: No configuration changes needed
  3. Deployment: Requires horizon contracts to be deployed on the network
  4. Compatibility: Can still process existing v1 receipts

For Indexers

  1. Receipt Processing: Must support v2 receipt processing
  2. Collection IDs: Should use collection IDs instead of allocation IDs
  3. Backward Compatibility: Can still redeem any existing v1 receipts

@suchapalaver suchapalaver force-pushed the main branch 3 times, most recently from 3fabe65 to 89f8847 Compare July 14, 2025 16:19
@suchapalaver suchapalaver changed the title feat: support horizon service paths feat: support horizon Jul 14, 2025
@suchapalaver suchapalaver marked this pull request as ready for review July 14, 2025 16:27
src/reports.rs Outdated
request: Some(indexer_request.request).filter(|r| r.len() <= MAX_PAYLOAD_BYTES),
response: Some(original_response).filter(|r| r.len() <= MAX_PAYLOAD_BYTES),
allocation: indexer_request.receipt.allocation().0.0.into(),
allocation: indexer_request.receipt.collection().as_address().to_vec(), // Collection ID as address for compatibility
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldnt this be collection?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. Thank you!

@suchapalaver suchapalaver marked this pull request as draft July 15, 2025 19:56
@suchapalaver suchapalaver marked this pull request as ready for review July 15, 2025 20:28
Signed-off-by: Joseph Livesey <[email protected]>
request: Some(indexer_request.request).filter(|r| r.len() <= MAX_PAYLOAD_BYTES),
response: Some(original_response).filter(|r| r.len() <= MAX_PAYLOAD_BYTES),
allocation: indexer_request.receipt.allocation().0.0.into(),
allocation,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this @tmigone is being consumed by other components I think and so I'm being conservative about changing the interface and that's what I'm trying to get at in the comments.

Signed-off-by: Joseph Livesey <[email protected]>
Signed-off-by: Joseph Livesey <[email protected]>
@suchapalaver suchapalaver force-pushed the main branch 4 times, most recently from 29cca04 to b533d22 Compare August 15, 2025 00:01
Signed-off-by: Joseph Livesey <[email protected]>
@suchapalaver suchapalaver marked this pull request as draft August 16, 2025 12:08
@tmigone
Copy link
Member

tmigone commented Aug 21, 2025

Closing this PR in favor of: #1119. It contains the same changes with added fixes.

@tmigone tmigone closed this Aug 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants