Rewards to Network Contributors

Introduction

To the best of its abilities, the DoubleZero network abstracts connectivity away for end users. All else equal, a packet of information that travels from London to Frankfurt on a well-traveled line pays the same as a packet that travels to Sao Paolo on an infrequently-used line. But underneath the hood, connectivity matters greatly and the DoubleZero system aims to incentivize performance from it network contributors. Connections that have high throughput and low latency should be paid more than those that have low throughput and high latency. Connections between popular destinations should earn more than connections on less popular routes.

The rewards model is the key pillar that incentivizes value from network contributors, while shielding users from routing logic. At a high level, the DoubleZero protocol accumulates revenue from users, and distributes that pool to network contributors (net of rewards removed to prevent self-dealing attacks). The rewards model governs the distribution, and it does so based on the marginal and fair contribution of each network contributor to the network’s efficiency.

To do so, the rewards model operationalizes the concept of Shapley values from the field of cooperative game theory. This rewards a network contributor for its marginal contribution to a simple value function, under various counterfactual scenarios. Network contributors who generate lots of value, through provisioning low-latency and high-throughput connections along popular routes and under different combinations of present and absent peer contributors, are rewarded commensurately.

Carried Traffic and Counterfactual Traffic

The methodology in this proposal focuses on value created under various counterfactual scenarios. That may not be immediately intuitive; and indeed a more natural approach is to pay out rewards simply on the basis of carried traffic. However, we believe that the carried traffic model — while simpler to understand — is insufficiently discriminating and thus does not incentivize long-term value.

To illustrate the point, consider a scenario with four links connecting cities A, B, and C. The red and green link connect A and B; a yellow link connects A and C; and a blue link connects B and C. Suppose the red link is more performant than the green link. Finally, each city wants to send 1 Gb of traffic to its clockwise neighbor. Under this topology and using the carried traffic model, the division of rewards is straightforward: the green link receives no rewards (as it carries no traffic) while each of the other links receives one-third of the rewards (as they each carry 1 Gb).

But do these rewards truly map to value created? Consider the world without each of the links sequentially. Should the red link drop out, the green link becomes much more important. Should the yellow or blue links drop out, users will care if the public internet pathway connecting those cities is meaningfully worse; but they will not care if the performance is comparable. This thought exercise illustrates that value is more complex, and these counterfactuals hint at a more robust notion of value.

Indeed, to augment the scenario, suppose the public internet pathway connecting each city has a one-way latency of 30ms. Suppose the red line is substantially more performant than the green line (with a latency of 10ms rather than 25ms); and that the blue line is more performant (20ms) than the yellow line (25ms). With this added information and under the lens of counterfactual scenarios, the division of rewards on the basis of traffic carried no longer seems optimal. The green link should get more than zero for its insurance value; the blue link should earn more rewards than the yellow link when benchmarked against the public internet alternative; and the red link should be rewarded for its very strong performance (over both the public internet and the green link counterfactual scenarios).

The carried traffic model could be modified with ad-hoc adjustments to distribute rewards for redundancy value, improved latency over the public internet and peers, etc. (For instance: we could mandate a line with no traffic but that provides insurance value to another line gets paid at 20% its rate if the first layer of insurance, 5% if the second layer of insurance, etc.) But this general approach would require substantial tuning of its many parameters. Moreover, this approach quickly erodes the simplicity of the carried traffic model anyways. By contrast, the Shapley value methodology handles these complexities simply and robustly.

Primer on Shapley Values

Shapley values hail from the cooperative game theory, as a means of fairly distributing the gains of a joint endeavor amongst players, based on each player’s marginal contribution to different coalitions of other players. They satisfy key desirable properties like symmetry (players with equal contributions get equal rewards), dummy player (those who create no value get no reward), and additivity across both settings and value functions. Indeed, they were a major reason that their creator, Lloyd Shapley, won the Nobel Prize in Economics in 2012.

Operationally, Shapley values are generated by calculating the average marginal contribution to a payoff or value function of each contributor, across all possible combinations of other contributors (weighted by the probability of that combination occurring). To illustrate, suppose we want to compute the Shapley value for the green link. To do so, we would look at every combination of other contributions without the green link (e.g red only, red and blue, etc), and measure the marginal increase in the value function V when the green link is included in that coalition versus excluded. These marginal increases, weighted by a probability matrix, give the green link’s Shapley value.

To complete the exercise, we need to define the value function.

The Value Function

The value function is simple. Taking its inspiration from the “Increase Bandwidth and Reduce Latency” rallying cry, it is simply traffic times the negative latency of that traffic, summed over all traffic types (e.g. origin and destination).

In calculating this value function, any traffic that cannot be better served by DoubleZero links is assumed to go over the public internet, which has effectively unlimited bandwidth but generally poor latency. In doing so, DoubleZero only distributes rewards for improvements over the public internet.

This allows us to complete the exercise for the green link. To illustrate an example, consider the fourth line in the table below, which corresponds to the marginal contribution of the green link to the blue and yellow links. Without the green link, the traffic between A and B travels over the public internet at a 30ms latency; and with the green link, that traffic travels over the link with a 25ms latency. The other traffic routing stays the same: traffic between A and C travels over the yellow link with 25ms latency, and traffic between B and C travels over the blue link with 20ms latency. This sums up to a value of -75 when the green link is absent, and -70 when the green link is present, making its marginal contribution 5. This can be repeated for each other combination, multiplied by the probability of the combination occurring, and summed up for a total Shapley value.

This can be repeated for each other network contributor: the operator of the high-performance red link has a value of 17.5; the operator of the semi-performant blue link has a value of 10; and the operator of the yellow link, which is only slightly better than the public internet, has a value of 5. In fractional terms, that means that the red link earns 50% of the available rewards, the blue link earns 29%, the yellow link earns 14%, and the green link earns 7%.

Unlike the carried traffic model, this system distinguishes on the basis of performance. And it scales across many concepts — from redundancy to latency to reliability — without needing to build complex payoff functions and tune multiple parameters.

Augmenting the Value Function

While the simple value function here generates intuition, in practice, we intend to augment the value function in four ways.

1. Contributor Withdrawals: network contributors may unexpectedly quit the network without notice for external reasons, as is their right in a decentralized system. While there may be other staking-based repercussions, we accordingly want to be especially robust to these sudden shocks in the value function. Thus, we define the value function as the expected value of traffic times negative latency, under a given coalition of network contributors and taking into account stochastic participation.
2. Value-Weighted Traffic: traffic is summed indiscriminately in the original value function, but there may be traffic that should be prioritized or de-prioritized based on the tier of service they request. Thus, we simply augment the traffic in the value function with a weight term.
3. Link Jitter: the value function requires a measure of “latency,” but latency in practice is a multi-dimensional object of performance under different scenarios. One refinement is to thus utilize the p95 latency rather than a mean or median latency, to account for jitter in links.
4. Future Throughput: the mechanism here rewards network contributors based on current traffic levels. However, DoubleZero aspires to ambitious goals on traffic carried, and achieving those goals requires upfront investments today that require rewards. Thus, the mechanism intends to multiply realized traffic by a scaling factor (whose size is yet to be determined) in computing the various counterfactual scenarios, to allow the network to be robust for future opportunities as well.

This yields a slightly more complex value function.

Methodology

The methodology to compute Shapley values proceeds as follows. This section can be skipped for those who are only interested in conceptual details rather than operational details.

Inputs

The key inputs to the methodology are the following. First, the links themselves must declare their p95 latency, their bandwidth, their anticipated uptime, and the public key of their operator ex-ante, where the information is used during the epoch for routing actual traffic and after the epoch for the distribution of rewards. Second, the methodology requires the realized demand matrix between different pairs of cities. The third input is the associated p95 latency for the public internet routing between each pair of cities. Fourth and finally, we must set the parameter to reflect operator withdrawal risk, which is likely a static and identical parameter for all operators at launch but will morph into a more discriminating operator-specific parameter (perhaps on the basis of existing tenure) as the methodology matures.

Permutation Value

With these inputs, the first step is to compute the value function for each possible permutation of providers, ranging from the empty set (i.e. full reliance on public internet) to the full set (i.e. all four providers). In the reference example, there are 16 permutations to compute, as this is the power set of four providers.

For each permutation of providers, we identify the optimal network routing through linear programming. Specifically, we model each sender and receiver’s traffic as a separate commodity that cannot be offset by inbound flows, e.g. Singapore to London traffic is a distinct commodity from London to Singapore traffic. We then seek to minimize the product of the cost matrix (or, specifically, latency) times weighted traffic, subject to a set of constraints – where the demand specifications are modeled as equality constraints and the bandwidth limitations are modeled as inequality constraints. This includes the public internet option, which has sufficient space for all demand but presumably high latency costs.

This allows us to get the routing of all traffic. From this, the value associated with this scenario is simply the (negative) objective function under the optimal routing.

Expected Value

The second step in the methodology is to convert the permutation-level values into expected values, which adjust for network contributor withdrawals. Put another way, the previous step calculates the value of (say) two providers operating assuming that they do in fact operate. The current step calculates the value of the two providers operating on average, accounting for withdrawals from the network.

This can be computed from the individual level scenarios. In this example, the expected value for a permutation with two providers is the scenario with both providers times the probability of both providers being present, plus each scenario with one provider only times the associated probability, plus the scenario with no providers times the residual probability.

Provider Contribution

The final step is to compare all scenarios with a given provider present with all scenarios with that given provider absent, to understand the average marginal contribution. It is multiplied by the probability of that scenario occurring, and summed across all scenarios. This is finally converted into a percentage of all computed Shapley values, for a contributor’s fair share of rewards.

Open Questions

There are three open questions in this methodology, that will be addressed in future updates.

1. Measurement: this approach relies on accurate and honest measurements of traffic demand, link performance, and public internet latency. In future updates, we will discuss precisely how we intend to conduct these measurements and how we intend to disincentivize dishonest reporting.
2. Computational Feasibility: the approach in this document requires computing values for the power set of contributors, which means it is feasible up to about 15-30 contributors before being too computationally complex. This may prove reasonable for the short-run future of DoubleZero; but in the long run, we will have to move away from exact estimates of Shapley values to approximation algorithms.
3. Local Area Transport: network contributors should also be incentivized to invest in the “last mile” connection from their particular node in a city to other points in a city (where users, e.g. validators, are located). However, this will likely be incentivized through a separate mechanism (to be determined and discussed in future updates), rather than trying to make the methodology or objective function here overly complex.

Conclusion

There is an underlying philosophy in the methodology here. The DoubleZero protocol does not want to take a strong stand on what attributes of link performance are important, and by how much they should be rewarded. Nor does the DoubleZero protocol want to tie rewards to the literal costs incurred by a network contributor.

Instead, the DoubleZero protocol simply rewards links on the basis of the value-add to a simple and well-understood value function. Investments that augment the value function under various scenarios will be compensated fairly, and investments that do not will not. This methodology adjusts with the needs of the network, incentivizing the right incremental behavior on behalf of the network contributors and ensuring the network’s long-term dynamism.

Appendix: Longer Example

In this appendix, we work through a longer example. This example should not be taken as indicative of a realistic or likely network topology; but rather as an illustration of the methodology handling a non-trivial scenario.

In this example, there are ten links spanning nine cities (plus an initially-unconnected Seoul), with millisecond latencies in red over the links. Validators in those cities (who are the only users of DoubleZero, in this scenario) have some stake, where the node shading represents the amount of stake at that location.

Suppose there are four providers. Provider 1 contributes links between London, Amsterdam, and Frankfurt. Provider 2 contributes all links touching North America (including the transatlantic and transpacific links), except the one to Vancouver. Provider 3 contributes the single link between LA and Vancouver. Provider 4 contributes all the remaining links, i.e. all links touching Singapore (including the long Eurasia link).

To initialize the scenario, we first specify the edges of the network. By assumptions, all of these edges are connected over the public internet with some associated public latency. However, these edges are also potentially connected directly via private links offered to the DoubleZero network. The table below shows the eleven connections in the baseline scenario. For ten of them, there are private links that operate over them (with associated latencies, bandwidth, operator IDs, and specified uptime). For all eleven, there is of course a public connection with effectively-unbounded bandwidth but higher latency.

Node #1	Node #2	Latency (ms)	Public Latency	Bandwidth (Gbps)	Operator ID	Uptime
FRA	AMS	2	4	10	1	0.99
FRA	LON	4	9	10	1	0.99
LON	AMS	2	4	10	1	0.99
LON	NYC	40	116	10	2	0.99
NYC	CHI	6	14	10	2	0.99
CHI	LAX	15	39	10	2	0.99
LAX	VAN	10	25	10	3	0.99
LAX	TYO	45	132	10	2	0.99
TYO	SIN	28	78	10	4	0.99
SIN	FRA	55	164	10	4	0.95
TYO	SEO	N/A	17	N/A	N/A	N/A

In this particular scenario, Tokyo and Seoul are only connected by public internet at the start of the simulation. Private latencies are taken approximately based on direct distances; and public latencies are invented as the private latency raised to the exponent of 1.1 and multiplied by two. (For simplicity, no other public latencies, e.g. LAX - SEO, are included because they are by assumption intermediated, e.g. in this case by TYO.) Private bandwidth is assumed to be 10 Gbps per link. Finally, the uptime of the lines are all assumed to be 0.99, except the line over Eurasia due to geopolitical tensions (and so its uptime is 0.95).

To initialize the scenario, we second specify the demand for traffic. We categorize each node as having a low, medium, or high amount of stake. Here, Amsterdam and Vancouver in this simulation have high stake; London, Seoul, Tokyo, and Singapore have mid stake; and Frankfurt, New York, Chicago, and Los Angeles have low stake. For each pair of sender and receiver nodes, we estimate the amount of traffic by the share of sender and receiver stake, multiplied by 100 Gbps of total network-wide traffic. This creates the following table of demands.

Sender / Receiver (Gbps)	Low	Mid	High
Low	0.06	0.28	0.51
Mid	0.28	1.42	2.55
High	0.51	2.55	4.59

The third and final input to the scenario is the operator non-default risk, which we set to be 95%. This is not the literal uptime of the link, but instead captures the risk that an operator simply leaves the DoubleZero network (due to operational, regulatory, or business reasons). This cannot easily be calibrated from historical data, and is instead set to protect the system on the basis of intuition.

Under the proposed methodology, this yields the following reward distribution for the providers.

Provider 1	Provider 2	Provider 3	Provider 4
3%	52%	4%	41%

Moreover, we can compute rewards for different scenarios. Suppose a network contributor is considering one of the four investments below. We can compute the incremental rewards associated with the investment, which the contributor can then weigh against the costs incurred. In this example, for instance, the contributor sees that an upgrade on the Pacific link — while very expensive — can yield substantial rewards initially, but those rewards diminish on the margin with the size of the upgrade.

Scenario	Increased Percent of Original Value Function
Upgrade Pacific link (LAX-TYO) from 10Gbps to 20Gbps	23%
Upgrade Pacific link (LAX-TYO) from 10Gbps to 40Gbps	36%
Upgrade Pacific link (LAX-TYO) from 10Gbps to 60Gbps	36%
Lower latency on Atlantic link (LON-NYC) from 40ms to 30ms	3%
Lower latency on Atlantic link (LON-NYC) from 40ms to 20ms	5%
Build a new 10Gbps, 7ms link from Tokyo to Seoul (TYO-SEO)	3%