Shieldeum Protocol: Value Transfer
Last updated
Last updated
A value transfer protocol enables compensating nodes in a distributed system from customers for their services. While a payment mechanism is part of the solution, the full benefits are lost if customers must pay each node individually and directly, and if payments are valid regardless of whether the node provides service.
To address this, we propose an out-of-band payment intermediary between customers and service providers. This intermediary defines service parameters and facilitates fund disbursement based on proof of service. Proof of service, including share tokens generated by customers and embedded within traffic, serves as both authorization for service providers and a representation of value for the service provided. Service providers collect these share tokens and submit them for validation and compensation. Compensation is distributed proportionally among service providers based on the number of valid share tokens they accumulate relative to the total number submitted for a specific service plan.
In a distributed system, achieving widespread adoption and scalability is often hindered by significant challenges. While ideology may drive initial participation, sustaining long-term scalability and ensuring fair compensation for service providers necessitates a robust economic incentive mechanism.
To tackle this issue, we advocate for the implementation of generic abstraction layers capable of accommodating various usage profiles and requirements. These layers would decentralize accounting, authentication, and authorization processes, fostering equal participation within an open marketplace.
This paper introduces a solution centered around a proportional share-based value transfer protocol designed specifically for distributed systems, with a focus on the internet's distributed traffic routing network layer. The proposed economic incentive mechanism aims to guarantee equitable compensation for services rendered.
Broadly speaking, there are 6 characteristics which need to be considered.
direct
in-band
crypto
on/off chain
true pay-as-you-go
bandwidth
intermediary
out-of-band
fiat
payment-card
post-paid
bandwidth cap
online-services
pre-paid
time
over-the-counter
time cap
Payment Dynamics: Payment transactions necessitate involvement from at least two parties: the payer and the payee, establishing a direct payment relationship. In the context of the proposed routing-layer framework, this entails customers engaging in separate direct payments with each relay provider. Alignment on payment currency, method, approach, and measurement between the customer and each relay provider is imperative. While network-wide consensus might mitigate this, it could curtail consumer freedoms, introduce complexity, and compromise user experience.
Currency and Payment Methods: Currency options typically fall into fiat and crypto categories, each presenting distinct advantages and drawbacks. Fiat currency methods, widely prevalent online, offer convenience through credit card payments and platforms like PayPal but may entail chargebacks and privacy issues. Crypto-based payments, though gaining traction slowly, enable peer-to-peer transactions without chargebacks and enhance privacy, particularly with advancements in privacy-focused coins. However, acquiring, managing, and using crypto can be daunting for less technically inclined individuals.
Pricing Strategies: With the emergence of peer-to-peer electronic cash systems, especially cryptocurrency micropayments, a true pay-as-you-go model utilizing in-band compensation channels becomes viable. However, this approach, along with others such as postpaid usage akin to Amazon Web Services' model, has its drawbacks including potential unforeseen expenditures and complexity. In a direct payment setup, customers must engage relay providers under prepaid or postpaid arrangements or forego the service.
Payment Measurement: Bandwidth and time are primary metrics applicable within the routing-layer framework, often categorized as pay-per-use or capped. Combining true pay-as-you-go or postpaid approaches with bandwidth usage may lead to unexpected costs and a subpar user experience akin to the early internet era.
Customer and Provider Concerns: Customers focus on how, who, when, and what they pay, while service providers prioritize fair compensation and operational simplicity. The system should prevent providers from being rewarded for non-performance, ensure decentralized operation to avoid single points of failure, and maintain a disconnect between payment and routing for enhanced privacy.
Addressing Concerns: Ideally, customers should have the flexibility to purchase unlimited bandwidth within a specified timeframe, using any currency and payment method. They should not be restricted to a single relay provider but have access to a consortium of providers willing to deliver the purchased service.
The solution initiates with the establishment of a service contract, serving as a bridge connecting customers and service providers. These contracts outline specific parameters and oversee fund distribution upon verification of service provision. Any entity can create service contracts, providing a flexible framework in terms of logic and parameters. Service providers enroll to participate in these contracts, while customers activate service keys to generate share tokens for inclusion in traffic.
1
id
service contract identification
2
pubkey
service contract public key
3
value
backed value of a service key activated by service contract
4
duration
duration of an activated service key until it expires
5
proof_of_funding
proof of funding type supported by contract
6
settlement_fee
optional payout percent charged by service contract
7
settlement_window
share token submission time window after service key expires
8
frequency
how often and when share tokens need to be sent
9
directory
location of public service provider relays supporting service contract
After creation, service providers can opt to enroll, either actively or passively, to support the service contract. Once a customer activates the service contract, it generates an active service key. This key is utilized to produce share tokens, which are embedded in traffic routed through the service providers. Share tokens serve as authorization for service provision and accrue value if validated, subsequently being submitted for compensation during a settlement phase.
Service contracts may have a backed value of zero, essentially offering a free service contract, though activation of service keys could be restricted through various mechanisms. Under normal circumstances, the backed value is positive, necessitating funding (unless subsidized).
For optimal user experience, it would be preferable to have a universal method for funding service contracts using any payment currency and method. To accommodate this, service contracts do not directly accept payments but instead support the concept of proof of funding verification.
The concept of proof-of-funding serves to abstract the funding process of a service contract from service key activation, offering numerous benefits. It enables support for a wide array of payment currencies and methods, including credit cards, gift cards, online payment services, cryptocurrencies, and more. This abstraction allows for transferability and resalability, fostering an aftermarket for purchase using currencies and methods not directly supported by the service contract, such as cash transactions.
Moreover, proof of funding operates on a pre-paid basis, although post-paid arrangements are technically feasible. This approach enhances the user experience by minimizing surprise bills and ensures service provider compensation through escrowed funds.
The integration of the funding source into a service contract can vary in tightness, with the only requirement being the contract's ability to validate the occurrence and validity of funding. While each service contract typically supports one type of proof-of-funding for simplicity, the possibility of supporting multiple funding types exists, albeit potentially adding complexity to settlement processes.
For instance, in a manual proof-of-funding scenario, the service contract operator could generate a timestamped proof-of-funding using the contract's private key, sharing it with the user out-of-band. The user would then include this proof when requesting service key activation, which the service contract verifies based on the timestamp and signature.
In the case of Ethereum, the service contract would provide an Ethereum address for fund deposits. The user, after broadcasting a transaction to the Ethereum network, generates a proof-of-funding by signing transaction details demonstrating ownership of the originating funds. This proof is submitted with the activation request and verified by the service contract cryptographically.
Similarly, with credit card payments, the service contract operator accepts payments via a service like Stripe. The billing system signs the receipt or transaction ID upon payment, returning it to the user as proof-of-funding. When requesting service key activation, the user includes this proof, which the service contract verifies using the billing system's signature.
Proof of funding fields.
1
type
type of proof of funding
2
body
body of proof of funding type
3
signature
cryptographic signature proving body
No matter the funding process, a proof of funding is either provided back to the customer or is generated by the customer themselves. The proof of funding is then used in the process of activating a service key.
Service keys, unique to each service contract, operate within the parameters defined by the contract and have a limited lifespan. This design choice serves to further distance payment information from ongoing network usage, thereby enhancing user privacy.
To obtain an active service key, the end-user initiates the process by generating an inactive service key locally, specifying the service contract identification, and creating a keypair. However, the service contract must be present to transform the inactive key into an active one.
The activation of a service key involves the user submitting the public key of the inactive service key, along with proof of funding, to the service contract for activation. Upon receipt, the service contract verifies the proof of funding. If valid, it signs the public key of the service key, along with an expiration timestamp defined by the contract parameters, thereby activating the service key. This activated key is then returned to the user, rendering it active and ready for use.
Service key fields.
1
pvtkey
service key private key generated client side
2
pubkey
service key public key, used in activation and share token generation
3
contract_id
service contract identification where the service key is associated
4
expiration
empty until activated; received from service contract
5
contract_signature
empty until activated; service_contract_sign(pubkey:expiration)
An activated service key is one that a service contract activates only after verifying proof of funding. It empowers enrolled service providers to cryptographically validate its authenticity through a chain of trust model. To enable this, the service key generates share tokens, which are then embedded within traffic transmitted through service provider relays.
Share tokens are independently created by a customer using their activated service key for each service provider in the routing path. These tokens are then embedded within the appropriate encrypted onion layer of the transmitted traffic. They serve a dual purpose: firstly, allowing service providers to authorize service, and secondly, representing value if proven valid for the provided service. Service providers gather these tokens for later submission and validation, accumulating them along with timestamps and metadata indicating when the associated service key is set to expire.
Share token fields.
1
version
share token version
2
contract_id
service contract identification where the service key is associated
3
pubkey
service key public key
4
expiration
service key expiration timestamp
5
contract_signature
service_contract_sign(pubkey:expiration)
6
timestamp
share token generation timestamp
7
relay_pubkey
public key of service provider relay share token was generated for
8
sharekey
used by service contract to validate ‘sets’ of share tokens
9
signature
above fields concatenated and signed by service key privatekey
When a service key expires, service providers may submit their accumulated share tokens for the specific service key to the service contract for validation and compensation.
As mentioned earlier, customers employ an activated service key to generate share tokens, which are then embedded in traffic routed through service providers. These tokens serve as proof of authorization for service provision and accrue value for later validation and compensation.
Submission: The service contract outlines a settlement window, spanning from service key expiration until the deadline for submitting share tokens. Service providers sign these tokens, ensuring their authenticity for the service contract's validation process.
Validation: The service contract accepts and validates share token submissions throughout the settlement window. Initially, basic validation occurs, followed by extended validation for tokens with additional share-key information. Valid tokens are stored for further processing.
Proportional share-based compensation: Once the settlement window closes, the service contract calculates compensation using a proportional share-based model. This model allocates rewards (R) among service providers based on the proportion of valid share tokens they've accumulated (n) compared to the total valid tokens (N) submitted for a specific service key (Kv) value. The calculation deducts the service contract's payout fee (Cf), ensuring fairness in compensation distribution.
Depending on predefined thresholds or configurations, payouts may occur automatically or via manual withdrawal. Manual withdrawals may be preferable in cases where transaction fees significantly impact the payout amount.
For pragmatic reasons, we make certain simplifications, assuming that service providers are, on average, rational individuals who grasp their incentives and pursue strategies that optimize their benefits.
To ensure that service providers are motivated to relay traffic to the next hop in the circuit rather than merely accumulating share tokens and denying service, a share-key may be included within the share token.
Share key fields.
1
type
type of share-key
2
body
body of share-key type
A share-key is used to identify a set of share tokens, generally per-circuit per-frequency as specified by the service contract. The set is verified during service contract share token extended validation. If the set does not pass validation, all share tokens in the set are void.
The abstract protocol flow illustrated above describes the interaction between the different roles, and includes the following steps:
The customer initiates a transfer of funds to the service contract, the service contract operator's billing system, or a specified destination.
Depending on the funding method, a proof of funding is either provided to the customer or generated by the customer themselves.
The customer creates an inactive service key, transmitting its public key to the service contract along with the proof of funding.
Upon verification of the proof of funding by the service contract, the service contract signs the service key's public key along with an expiration timestamp, activating the service key, and returns it to the customer.
Using the activated service key, the customer generates share tokens, which are integrated into traffic routed through service providers. These tokens authorize service and accumulate until the service key expires.
When the service key expires, service providers sign the accumulated share tokens and submit them to the service contract for validation and compensation.
Finally, the service contract validates the submitted share tokens, calculates proportional compensation for each service provider, and disburses the funds or enables withdrawal.
This process establishes a complete cryptographic chain of trust, starting from the proof of funding and extending to the service provider-signed share tokens. Each link in the chain is cryptographically verifiable back to the service contract's signing of the service key, ensuring the validity of the funds transfer.
CHAIN OF TRUST
A chain of trust is a sequential series of verification and validation steps, starting from a root authority known as the trust anchor. The trust anchor cryptographically signs the first link, which then signs the subsequent link, and so forth. This process can continue indefinitely, forming a chain of trust.
Each link in the chain is validated based on the signature of the previous link. If any link were to be modified, its signature would become invalid, breaking the chain of trust. Therefore, the integrity of each link is guaranteed by the preceding one, ultimately tracing back to the trust anchor. This ensures that any validated link in the chain can be trusted to possess certain properties.
Our chain of trust begins with proof of funding, which is only generated or deemed valid if the transfer of funds is verifiable by the service contract. The next link in the chain is an activated service key, contingent upon the service contract verifying the proof of funding, which in turn confirms the transfer of funds. Subsequently, the service key generates share tokens, which are then validated by service providers verifying the validity of the service key that signed them. This validation process ensures the trustworthiness of the proof of funding, and the chain of trust continues.
Eventually, service providers sign the share tokens they have validated and accumulated, which are then submitted to the service contract for compensation. The service contract, in turn, can verify that these service provider-signed share tokens were indeed generated specifically for them and signed by them. This verification process completes the chain of trust, confirming each link back to its own signing of the service key, based on the validity of funds transfer, thus coming full circle.
We have presented a solution for a proportional share-based value transfer protocol tailored to distributed systems, specifically addressing the needs of a distributed traffic routing network layer on the internet.
Our solution begins with the introduction of the service contract, which acts as a mediator between customers and service providers. This contract defines the service parameters and facilitates the distribution of funds provided by a customer to service providers, proportionally compensating them for the services rendered, based on proof of service. To ensure the funding of a service contract, we propose a generic approach called proof of funding. This method abstracts the acceptance of payments, allowing for out-of-band verification using virtually any payment currency and method. The proof of funding is authenticated during the service key activation process, resulting in the activation of a service key, which is then utilized to generate share tokens.
Share tokens are independently generated by the customer for each service provider in the routing path. These tokens are cryptographically embedded within the encrypted onion layer of traffic, enabling the inclusion of value within the transmitted data. They serve as incentives for service providers through the use of a share-key mechanism. Service providers utilize these share tokens to authorize service and accumulate them as they represent value, pending validation and compensation.
Using a proportional share-based model, compensation is distributed among service providers based on the number of valid share tokens they accrue relative to the total number submitted by all providers for a specific service plan. This ensures a fair and equitable distribution of compensation within the network.
