A value transfer protocol would allow nodes in a distributed system to be compensated by customers for the service they provide. A payment mechanism provides part of the solution, but the main benefits are lost if the customer is required to pay each node separately and directly, and if the payment is valid without the node actually providing service.
We propose a solution to payments and compensation validity by employing an out-of-band payment intermediary between customers and service providers, defining the service parameters, and facilitating in disbursing funds provided by a customer to service providers proportionally for service provided, based on proof of service. Proof of service, defined in part by share tokens, are cryptographically and independently generated by a customer and included within traffic sent through service providers, serving a dual-role of allowing a way for service providers to authorize service, as well as a representation of value if proven valid for service provided. Service providers accumulate these share tokens to later submit for validation and compensation. By employing a proportional share-based model, compensation is split between service providers according to the number of valid share tokens they accumulate in proportion to the total number of valid shares tokens submitted by all service providers for a specific service plan.
Introduction
A major pitfall of any distributed system is the widespread adoption and scaling of the service. While ideology provides a great incentive to altruistic participants, we believe a sensible economic incentive mechanism is required for scalability and long term sustainability of the system, whereas service providers are compensated fairly for the service they provide.
In order to facilitate such a mechanism, we propose the use of generic abstraction layers supporting different usage profiles and requirements, providing accounting, authentication and authorization in a decentralized, distributed manner promoting participatory equality in a free and open marketplace.
In this paper we propose a solution for a proportional share-based value transfer protocol for distributed systems, more specifically for a distributed traffic routing network layer on the internet, by means of a sensible economic incentive mechanism that facilitates compensation for services provided. Ideally, value transfer would be performed by including value, or a representation of value (if proven valid) within traffic sent through relay providers as compensation for service provided. However, this presents a rather unique set of challenges, especially when accounting for the multiple characteristics, properties and considerations comprising a well structured payment mechanism.
Payment mechanism considerations
Broadly speaking, there are 6 characteristics which need to be considered.
| Relationship | Channel | Currency | Method | Approach | Measurement |
|---|---|---|---|---|---|
| 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 relationship. Payments need to be made and accepted. At a minimum, two parties consisting of a payer and payee are involved, resulting in a direct payment relationship. In a direct payment relationship within the proposed routing-layer context, a customer would be required to pay each relay provider separately and directly. Both the customer and each relay provider would need to agree and support the same payment currency, method, approach and measurement. This could be partially alleviated with network-wide consensus, but at the expense of consumer freedoms, increased complexity, and a suboptimal user experience.
Payment currency and method. Currencies can be loosely grouped into two forms, fiat and crypto, each with their own benefits and downsides. Fiat currency payment methods are prolific on the internet and provide a relatively good user-experience via credit-card payments and online services such as PayPal, although they are accompanied with potential charge-backs and privacy concerns. Crypto-currency based payments are growing in popularity, albeit slowly, providing the ability for P2P direct payments, no charge-backs, and increase privacy especially with advances in privacy-coins. Although, for the less technical, obtaining crypto-currency, holding, securing and using said currency might be out of their ability or comfort zone.
Pricing approach. With the advent of P2P electronic cash systems, particularly cryptocurrency micropayments, a true pay-as-you-go approach using an in-band channel of compensation is feasible, although it suffers from the issues discussed above, as well as others which are out of the scope of this paper. A recent approach to pricing made popular by Amazon Web Services is postpaid usage, similar to pay-as-you-go, but where the customer entrusts the service provider with their payment method, being charged at a set interval per their usage. In a direct payment relationship, the customer would be required to use the relay provider if prepaid or postpaid, or otherwise forgo the expenditure.
Additionally, and no matter the approach used in a direct payment relationship, a service provider may accept payment but not provide service, either intentionally or unintentionally.
Pricing measurement. Two of the most common measurements that may be employed within the proposed routing-layer context are bandwidth and time. They can further be segregated into pay-per-use or capped. Combining the pricing approaches of true pay-as-you-go or postpaid together with bandwidth usage could result in unexpected expenditures, and in our opinion a poor user experience reminiscent of the old dial-up internet era.
From a customers perspective, concerns include how they pay (currency and method), who they pay (relationship), when they pay (approach), and what they pay for (measurement). A service provider should only be concerned with whether they will be fairly compensated for providing service, at a price they choose to support, and not require excessive network or computational overhead. They should not be concerned with accepting and processing payments, dealing with charge-backs, or performing complex accounting and billing. In addition to addressing both the customers concerns as well as the service providers, the system should ensure service providers not be compensated for not performing service, it should be distributed so as not to have a central point of failure and trust, and should provide a disconnect between payment and routing for enhanced privacy.
We need a way to address these concerns, ideally allowing a customer to purchase or prepay for unlimited bandwidth which is limited to a certain amount of time, using virtually any currency and payment method. The customer should not be limited to a specific relay but rather a group of service providers which agree to provide the service paid for.
Service contract
The solution we propose begins with the service contract, which acts as an intermediary between customers and service providers. A service contract defines the service parameters, and facilitates in disbursing funds provided by a customer to service providers proportionally for service provided, based on proof of service.
Service contracts may be created by any party, and are flexible in both their logic and defined parameters, for example, a time-capped bandwidth-unlimited service contract might define the following:
| No. | Name | Comment |
|---|---|---|
| 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 |
Once created, service providers may enroll (passively or actively) to support the service contract. A customer would enact the service contract, generating an active service key. The service key is then used to generate share tokens which are included in traffic sent via service providers. Service providers use share tokens to authorize service, and accumulate said share tokens as they represent value if proved valid, to be later signed and submitted for validation and compensation through a settlement process.
Service contracts may have a backed-value equal to zero, essentially providing a free service contract, though service key activation may be limited through various means. In regular circumstances, the backed-value will be positive, in which case funding is required (unless subsidized).
For the best user experience, it would be ideal if there was a generic way to fund a service contract using virtually any payment currency and payment method. Due to this, service contracts do not accept payment directly, but rather support the concept of proof of funding verification.
Proof of funding
The idea behind proof-of-funding is to abstract the actual funding process of a service contract from service key activation. This has multiple benefits, such as the ability to support virtually any payment currency and payment method, such as credit cards, gift cards, online payment services, crypto currencies, etc. Due to the disconnect, transferability and resalability are possible, enabling an aftermarket for purchase in currencies and methods not supported by the service contract itself - for example, over-the-counter with cash.
Further, proof of funding uses the pre-paid approach (though post-paid is technically possible), improving the user experience by reducing surprise bills, as well as guaranteeing service provider compensation via escrowed funds.
The funding source of a service contract could be tightly or loosely integrated, the only requirement is the service contract having the ability to verify funding has occurred and is valid. For simplicity, one type of proof-of-funding would be supported per service contract, as settlement will most likely be related to the funding type, although having one contract support multiple funding types is possible but may add complexity.
Example. The service contract operator could generate a proof-of-funding manually by using the service contract private key to sign a timestamp representing when the proof-of-funding expires. The operator would then share this timestamp and signature with a user out-of-band. The user would then include this as proof-of-funding when requesting service key activation. The service contract could then verify the proof-of-funding is still valid based on the timestamp, and the validity of the signature.
Example: Ethereum. The service contract discloses an Ethereum address to a user to deposit funds. The user broadcasts a transaction to the Ethereum network. The user then generates a proof of funding by signing the transaction details proving they are the owner of the originating funds. The user includes this proof-of-funding when requesting service key activation. The service contract upon receiving the request, could then cryptographically verify the proof-of-funding.
Example: Credit card. The service contract operator accepts credit card payments via Stripe. The service contract operators billing system would sign the receipt/transaction-id upon payment and return it to the user as proof-of-funding. The user includes this proof-of-funding when requesting service key activation. The service contract having the ability to cryptographically verify the billing systems signature could verify the proof-of-funding.
Proof of funding fields.
| No. | Name | Comment |
|---|---|---|
| 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 key
Service keys are service contract specific, are valid based on the service contract parameters, and are temporary. By design, this further increases the degrees of separation between payment information and repetitive network usage, resulting in improved user privacy.
Service keys are created by the end-user, but the service contract is required in order to produce an active service key. The service contract will only activate the service key once it can verify proof of funding.
Service key initialization. The user independently and locally generates an in-active service key by specifying service contract identification, and having a keypair generated. The service contract is required in order to produce an activated service key.
Service key activation. The act of activating the service key involves having the user send the in-active service key public key along with proof of funding to the service contract, requesting activation. The service contract would verify the proof of funding, and if valid sign the service key public key along with an expiration timestamp as defined by the service contract parameters for the activated service key, which is then returned to the user, resulting in an active service key.
Service key fields.
| No. | Name | Comment |
|---|---|---|
| 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) |
Given that a service contract will only activate a service key once it has verified proof of funding, an activated service key is one which provides a service provider enrolled in the service contract the ability to cryptographically verify the validity of the service key via a chain of trust model. In order to facilitate this, the service key is used to generate share tokens which are included within traffic sent through service provider relays.
Share token
Share tokens are cryptographically and independently generated by a customer using an activated service key for each service provider in the routing path, and are included in the appropriate encrypted onion layer of traffic being sent. Share tokens serve a dual role. First by allowing a way for service providers to authorize service. And second, as a representation of value if proven valid for the service provided. Service providers accumulate share tokens to later submit for validation and compensation.
Share token generation. The customer may generate share tokens to be included in traffic sent to relays with an activated service key.
Share token verification. Service providers enrolled in providing service for a service contract would have the service contract identification and public key stored so they may verify share tokens.
Share token accumulation. Service providers collect share tokens and timestamp them as they are received, per service key along with metadata of when the service key is set to expire, so they may be submitted within the settlement window to the service contract.
Share token fields.
| No. | Name | Comment |
|---|---|---|
| 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.
Settlement
As discussed above, customers use an activated service key to generate share tokens which are included in traffic sent via service providers. Service providers use share tokens to authorize service, and accumulate said share tokens as they represent value if proved valid, to be later submitted for validation and compensation.
Submission. The service contract specifies the settlement window, which is the time between service key expiry and until when the service contract would accept submission of share tokens for a specific service key. The service provider signs the share tokens so the service contract can verify the share tokens are submitted by the intended service provider, acting as another link in the chain of trust.
Validation. The service contract accepts submissions of share tokens until the settlement window closes while performing basic validation, and storing them for later. This is required for two reasons. First, to perform extended validation such as for share tokens with a share-key (providing the ability to verify proof-of-service), and second, to calculate proportional share-based compensation.
Proportional share-based compensation. Once the settlement window has closed and all submitted share tokens are validated, the service contract is able to calculate how much of the service key backed-value each service provider should receive. By employing a proportional share-based model (R = (Kv * n/N) - Cf) similar to that used in cryptocurrency mining pools 1, compensation or reward (R) is split between service providers according to the number of valid share tokens (n) they accumulate in proportion to the total number of valid share tokens (N) submitted by all service providers for a specific service key (Kv) backed value, less the service contract payout fee (Cf). In other words, all shares are equal but their value is calculated when the settlement window closes as defined by the service contract and service key expiration.
Depending on defined thresholds or configuration, actual payout disbursement could happen automatically, or manually by means of a withdrawal. An example where manual withdrawal might make sense is when transaction fees would represent a significant portion of the payout.
Proof of service
For practical purposes, certain simplifying assumptions are made, such as service providers being on average, selfish rational beings capable of understanding their incentives and executing the dominant strategy that maximizes their utility.
To properly incentivize service providers to provide service by relaying traffic to the next hop in the circuit and not just accepting connections in order to accumulate share tokens and denying service, a share-key may be specified within the share token.
Share key fields.
| No. | Name | Comment |
|---|---|---|
| 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.
Protocol flow
The abstract protocol flow illustrated above describes the interaction between the different roles, and includes the following steps:
1. The customer transfers funds to the service contract, the service contract operators billing system, or specified destination.
2. Depending on the funding type, a proof of funding is either provided back to the customer or is generated by the customer themselves.
3. The customer generates an inactive service key, of which the public key is sent to the service contract along with the proof of funding.
4. Once the proof of funding is verified by the service contract, the service key public key along with an expiration timestamp is signed by the service contract, and returned to the customer, resulting in an activated service key.
5. The customer uses the activated service key to generate share tokens which are included in traffic routed through service providers. The share tokens are used to authorize service and are accumulated until service key expiration.
6. Upon service key expiration, the service providers sign the share tokens and submit them to the service contract for validation and compensation.
7. Finally, the service contract verifies the submitted share tokens, calculates the proportional compensation for each service provider, and disburses the funds or makes them available for withdrawal.
This process generates a full cryptographic chain of trust, beginning with the proof of funding all the way down to service provider signed share tokens, with each link in the chain being cryptographically verifiable back to the service contracts signing of the service key based on the validity of the funds transfer.
Chain of trust
A chain of trust is a linked path of verification and validation from a child link to the root element or authority acting as a trust anchor. It starts with the trust anchor, cryptographically signing the first child link dependant on the verification and validation process in place. The child link in turn may repeat the process, cryptographically signing its own child link. The process may be repeated extending the chain indefinitely.
This process results in a chain of trust. Any validated link in the chain can be trusted to have certain properties, because if it had been modified its signature would be invalid, and the previous link would not have signed it. The previous link can be trusted, because it, in turn, would not have been signed if its signature had been invalid. The trustworthiness of each link is guaranteed by the one before, back to the trust anchor.
Our chain of trust begins with proof of funding, where as it would only be generated or valid if the transfer of funds is verifiable by the service contract. The next link is an activated service key, which requires the service contract verify the proof of funding, which in turn verifies funds transfer. It continues with the service key generating share tokens, which are validated by service providers verifying the service key which signed them is valid, which in turn guarantees the trustworthiness of the proof of funding, and so on. Finally service providers sign the share tokens they have validated and accumulated, which are submitted to the service contract for compensation. The service contract in turn may now verify these service provider signed share tokens were in fact generated specifically for them and signed by them, as well as verify each link in the chain back to its own signing of the service key based on the validity of funds transfer coming full circle.
Conclusion
We have proposed a solution for a proportional share-based value transfer protocol for distributed systems, more specifically for a distributed traffic routing network layer on the internet.
We started with the service contract, acting as an intermediary between customers and service providers, defining the service parameters, and facilitating disbursing funds provided by a customer to service providers proportionally for service provided, based on proof of service. We proposed a generic way to verify the funding of a service contract by means of proof of funding, where by the acceptance of payments is abstracted and performed out-of-band using virtually any payment currency and method. The proof of funding is verified during the service key activation process, resulting in an activated service key, which in turn is used to generate share tokens.
Share tokens are cryptographically and independently generated by a customer for each service provider in the routing path, and are included in the appropriate encrypted onion layer of traffic being sent, essentially allowing for the inclusion of value within traffic, while incentivizing service by means of a share-key. Service providers use share tokens to authorize service, and accumulate said share tokens as they represent value if proved valid, to be later submitted for validation and compensation.
By employing a proportional share-based model, compensation is split between service providers according to the number of valid share tokens they accumulate in proportion to the total number of valid shares tokens submitted by all service providers for a specific service plan.