Fine-Tuning Myel Network Economics

A. Camuto
Fine-Tuning Myel Network Economics
A. Camuto

Modelling the economics of the Myel network is not trivial, but we've created some simple statistical models to help us inform some of our pricing choices as we roll out our network.

The Myel network is a carefully calibrated balancing act between offering sufficient incentives for peers to participate and remain online, but also keeping costs low across the network to keep applications and developers satisfied.

The Network Actors

In the first model of this series we focus on a single application deployed on the Myel network that has NN users, with an average payload of BB bytes. We assume that the application has a proportion d[0,1]d\in[0,1] of users that recur daily. On a given day we thus have:

daily_users=d×N \mathrm{daily\_users} = d\times N users.

Let's assume that these users load the app daily according to a Poisson distribution, i.e most users load the app a few times, but a couple really love it and use it often.

daily_usesPoisson(λ)\mathrm{daily\_uses} \sim \mathrm{Poisson(\lambda)}, where λ\lambda controls how often the average user loads the app.

Now we assume that a proportion pp of those NN users are also providers of the application's content. They serve the content to all the other users. Here we assume that because the Myel plugin is a background process that runs continuously on someone's computer that the providers have a probability of being online on a given day m[0,1]m\in[0,1], that is distinct from dd and often larger than dd such that we have mdm\geq d. Basically we are assuming that an application's providers are often more likely to be present on a given day than an application's users. On a given day we thus have:

daily_providers=m×p×N\mathrm{daily\_providers} = m\times p \times N providers.

Now some of those providers might also be users on a given day ! Assuming that providers are also likely to use an app with a probability dd on a given day, we have a special class of provider that already has the content they need to use the app ! On a given day we have:

daily_providers daily_users=d×p×N\mathrm{daily\_providers} \ \cap \mathrm{daily\_users} = d \times p \times N providers that are also using the app.

Content Transmission

We've now established the different types of actors on the Myel network. We now need to make assumptions as to how content is transmitted. We assume that we have a population of users that have locations that are distributed equally across a square area.

locationUniform(square)\mathrm{location} \sim \mathrm{Uniform(\mathrm{square})}.

We now assume that application users get their content from the nearest provider. The uniform assumption means that on average each provider serves daily:

daily_users_per_provider=daily_usersdaily_providers daily_usersdaily_providers=d(1p)m×p\mathrm{daily\_users\_per\_provider}=\frac{\mathrm{daily\_users} - \mathrm{daily\_providers} \ \cap \mathrm{daily\_users}}{\mathrm{daily\_providers}}=\frac{d(1-p)}{m\times p}

Lets say the payload of the app is MM bytes, and we have a price\mathrm{price} per byte delivered (in FIL or USD).

Each provider earns on average per day:

daily_provider_earnings=price×users_per_provider_daily×E(daily_uses)=price×M×d(1p)m×p×λ\mathrm{daily\_provider\_earnings} = \mathrm{price}\times \mathrm{users\_per\_provider\_daily} \times \mathbb{E}(\mathrm{daily\_uses}) = \mathrm{price} \times M \times \frac{d(1- p)}{m\times p} \times \lambda

This comes from the fact that the expected value E\mathbb{E} of a Poisson distribution is just its characteristic parameter λ\lambda.

And the network generates a total earnings of

daily_total_earnings=daily_providers×price×users_per_provider_daily×E(daily_uses)=N×price×M×d(1p)×λ\mathrm{daily\_total\_earnings} = \mathrm{daily\_providers} \times \mathrm{price}\times \mathrm{users\_per\_provider\_daily} \times \mathbb{E}(\mathrm{daily\_uses}) = N \times \mathrm{price} \times M \times d(1-p)\times \lambda

Balancing Earnings and Network Performance

There’s a number of factors here we can’t control as the designers of the network. We can’t control the number of users NN, the proportion of daily users dd, the size of the application content MM, the proportion of providers online on a given day mm, or the average uses per user λ\lambda. But we can act on the price\mathrm{price} and control the proportion of users that are providers pp.

As pp increases we can assume that performance of the network increases, there are more providers to serve content quickly to users, but the returns per provider and for the network as a whole decrease ! Thus, given a fixed agreed upon price\mathrm{price}, controlling pp is where we can have the most impact -- carefully balancing and fine-tuning network performance against strong earnings for both the network and for individual providers. As a concrete example consider the case where all users are providers, p=1p=1. Because all users already have the content, there are no bytes to be delivered, and no one earns anything !

This kind of modelling will be critical as we roll out the network and need to make informed decisions on controlling pp. We’ll start shipping more sophisticated models where we assume more complex location distributions, and as we gather data on the network we can also model network performance as a function of pp.


Consider an application with 2000 users (N=2000N=2000) of which 40%40\% use the app on a given day (d=0.4d=0.4), content delivery is priced at 0.08USD/GiB, the application content size is M=M=0.1GiB, the provider uptime is roughly m=0.7m=0.7, the proportion of providers is p=0.01p=0.01, and finally most users use the app twice a day λ=2\lambda=2.

Providers earn roughly 304USD a year and the network yield roughly 4204.8USD.

Below we show a simulation for these values, but where N=200N=200 and p=0.1p=0.1 - so as to not clutter the network visualisation. Black Nodes represent network providers, red nodes are peers that are active on a given day, and grey nodes are offline peers

Simulation rendering