-
Notifications
You must be signed in to change notification settings - Fork 8
Open
Open
Copy link
Milestone
Description
We propose the implementation of AccessPassV2 (aka AccessIdentity), a new mechanism to manage network access tied to a user_payer pubkey. Unlike the current AccessPass, which binds access to a static IP at creation time, AccessIdentity learns the IP dynamically upon the first connection. This design provides more flexibility for validators operating multiple servers, migrating between IPs, or requiring redundancy, while preserving security through epoch-based temporal constraints.
Motivation
- Validators often need to change or use multiple IPs, making the static IP requirement of AccessPass too rigid.
- The original pubkey allowlist was too permissive (no epochs, no IP accountability).
- AccessIdentity balances both approaches by:
- Supporting dynamic IP learning.
- Enforcing temporal access via last_epoch.
- Allowing connection mobility through automatic reset when connection_count == 0.
Specification
Data Structure: AccessIdentity
- user_payer (Pubkey) – authorized payer.
- last_epoch (Epoch) – last valid epoch.
- client_ip (Option) – bound dynamically at first connection (reset on disconnect).
- connection_count (u32) – tracks active connections.
- allow_multiple_ip (bool) – toggle between strict single IP binding and multi-IP flexibility.
Lifecycle Rules
- Creation – initialized with client_ip = None, connection_count = 0.
- First Connection – validates epoch <= last_epoch, binds IP if empty, increments connection_count.
- Subsequent Connections
- If
allow_multiple_ip = false→ must match client_ip. - If
allow_multiple_ip = true→ any IP allowed, but client_ip remains bound to the first.
- If
- Always increment connection_count.
- Disconnection – decrement connection_count; if 0, clear client_ip.
Differences from AccessPass
- AccessPass: requires IP at creation.
- AccessIdentity: binds dynamically on first use.
- Supports both strict IP binding or multi-IP use cases.
- More aligned with validator operations across multiple servers.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels