CDN for web3: developing a framework for protocol layer

Recently, I finally decided to look into web3. Thanks to this interesting playlist from Crypto Startup School by a16z, I was able to develop a basic framework to understand web3. So, now it is time to put my framework to test.

While, looking into web3 I came across Odysee, an interesting web3 alternative to YouTube. Another interesting project is Arweave which essentially acts as an alternative to cloud storage.

When I was reading Arweave yellow paper, I came across a simple question. What I understood is that Arweave treats all the files stored on its blockweave (blockchain underlying Arweave) equally. But in a use case like Odysee where media files are involved with varying demand, will Arweave be able to provide the necessary bandwidth to a viral video with millions of viewers?

This sets up the premise of a use case I can build a framework around. A very traditional use case of a CDN.

Why does web3 need a CDN?

A large part of internet today consists of content & media. But not all content is made or more specifically consumed equal. Things go viral and then there are a lot more people consuming them simultaneously. While others sit in a corner with no one looking at them twice.

Everything indeed shall be stored and preserved because they do hold a great amount of value to the creator and hence Arweave’s vision of a permaweb makes a lot of sense. But when delivering content, we shall be able to more pragmatic and dedicated resources based on the demand of the content.

This leads me to the premise that we need a CDN blockchain that can deliver scalable bandwidth to content based on demand.

A framework for web3 protocol layer

From what I understand, web3 protocol layer essentially determines how the blockchain computer works. Blockchain computer being the distributed network of computers which is supposed to serve a specific function.

Specifically, I would define web3 protocol as a set of rules that govern transactions, blocks, and blockchain on how each of them is defined and how various stakeholders in the ecosystem interact with them.

The following visual represents a generic business model that governs the protocol layer. Focusing on various components of the business, stakeholders and roles played by the stakeholders.

Source: https://www.youtube.com/watch?v=AI1N6dY8vSQ

A web3 protocol shall be such that it serves the larger interest of the ecosystem while each individual focuses on their own selfish interests.

This starts with identifying the key entities of the ecosystem, their self interests and encoding them as the rules. Which in turn shall lead to a protocol, a token with some inherent value, a useful functionality when the protocol is followed by a group of miners & validators which can be used to develop apps or embedded in existing apps.

The CDN Protocol

The ecosystem

First step is to define the ecosystem i.e. the key stakeholders, their selfish interests and the roles they play.

• Content owners: Users whose content is being served by the CDN. They would want that the latest version of their content be made available to the end user with low latency with minimum additional cost to them. Additional cost being any cost incurred above storing the content in some permanent storage. Typically they would be paying a fee for storing the content in some storage. The fee may alternatively come from developers.
• Content consumers: Users who consume the content. They would want the latest version of content available at low latency with minimum additional cost. Additional cost being any cost incurred above accessing the content from permanent storage. Typically they would be paying a fee every time they access a content from a storage. The fee may alternatively come from the pockets of content owners or developers.
• Application developers: Typically this content would be created and consumed through some applications. CDN could act as an additional functionality that makes those app faster to use for end users and hence have better utility than a competitor not employing the CDN. But application developers too would prefer not to having pay a lot for such a service. Typically, any fee would be passed on to the end users.
• Servers: People who would provide the infra, essentially loading the content from permanent storage and delivering it to end users. They would want to have a positive scalable unit economics. Typically, they would incur cost for loading content from storage, keeping it stored locally and allocating the bandwidth to serve it.
• Miners & Validators: People who ensure that the transactions between consumers & servers are executed as intended by maintaining the ledger of transactions as per the protocol. Typically, they would incur cost in maintaining the ledger. Servers would mostly double up as miners & validators. They would want that the costs they incur are balanced out by rewards they get for mining the blocks.

There are typically some additional constraints that come from the underlying ecosystem.

• Privacy: Consumers would prefer to achieve lowest latency without having to disclose their geolocation. Servers too would want to be able to provide their services without having to disclose their respective locations.
• Interoperability: Since servers would need to get data from storage which falls outside the network, they would expect that they can easily exchange the token of the network with that of those 3rd party storage.

Goals

The resultant protocol hence shall achieve certain goals:

• Valid responses: The most fundamental goal to achieve is that when a user makes a request then they should get a valid response to that request within a certain time frame that doesn’t lead to request time out.
• Latency: The CDN becomes useless if for most of the requests the time taken is same as or greater than that taken by the storage. The CDN shall hence maintain a latency considerably lower than that of the underlying storage for maximum % of requests. This will never be true for 100% of requests as when the request will be made for the first time, it will have to be fetched from the storage. Average latency and % of requests covered shall be predictable across the network.
• Updated responses: Since the data at the origin may change, the response shall be in sync with the storage with some predictable delay.
• Miner & Server unit economics: The protocol shall be able to ensure that miners and servers earn more than they spend to maintain the network and deliver utility.
• Geographic distribution: Generally, users and servers would be distributed across geographies. The demand of certain requests may be higher in one location as compared to others. For example, content in regional languages will have higher demand in the region as compared to outside it. In such cases, it makes sense for content across servers to have some kind of geographic distribution following the demand.
• Demand distribution: Generally, some content will have higher demand than others. A viral video for example may have thousands of simultaneous viewers in an area. Such content shall have much higher bandwidth allocation as compared to others.

To achieve the above goals, the protocol shall be able to create certain behaviours in the network by creating appropriate incentives:

• Response validation: Miners & validators should be incentivized to validate responses in each transaction against the original source.
• Shortest latency peers: Everybody in the network shall have incentive to discover shortest latency peers for a user. A user hence shall be able to manage a peer list of their nearest peers without needing to share geolocation.
• Distributed cache coverage: Servers in the network shall have an incentive to manage a local cache such that a group of co-located servers can achieve maximum coverage for requests made by users near to them.
• Consistent response times: Servers in the network shall have an incentive to maintain consistent response times by allocating higher bandwidth to requests in high demand.
• Cache expiry: Servers in the network shall have an incentive to update cached content regularly and hence maintaining a predictable cache expiry.

The protocol

The above incentives can be built in rules at 3 levels:

• Transactions: What constitutes a valid transaction?
• Block: Which blocks get to be added to the blockchain (Proof of work/stake etc.)?
• Blockchain: How is the consistency of chain maintained across nodes?

Transactions

Each transaction shall record following information:

• User who initiated the request.
• Timestamp of request by the user.
• Server who responded to the request.
• Timestamp of the response.
• Response sent to the user.
• Timestamp of cached response as fetched from the permanent storage.
• Transaction time = latency (time of response — time of request) + staleness (time of response — time of caching)

A valid transaction shall have all the above information with following constraints:

• Timestamp of response > Timestamp of request
• Timestamp of response > Timestamp of caching
• Response shall be same as the latest response from the permanent storage

Block

Each block shall record following information:

• All the transactions to be recorded in the block with each response replaced by its hash.
• A stake committed by the miner representing their trust in the block.
• Block time = Sum of transaction time across transactions
• Previous block’s hash

If any of the transactions in a block are found to be invalid, the stakes committed by the miner will be lost.

Blockchain

In case of multiple candidate blocks at a position in a chain, the block shall be selected such that:

• the resultant chain has shortest block time at any given block height.

Any new peer joining the network shall have access to:

• Latest block
• A list of peers
• A summary of requests cached by their peers
• List of shortest latency peers of their peers
• Current network response time

Further the unit economics can be ensured by controlling:

• Token value
• Transaction fee
• Block mining reward
• Transactions/Block

With following constraints:

• Token value shall increase
• Transaction fee shall decrease
• Block mining reward shall remain constant

Testing scenarios

Much like a product, a protocol has to be perfected by testing it across scenarios and ensuring that it continues to fulfil the self interest of all stakeholders while still achieving the purpose of the network.

• We can ensure that any accepted block has all valid transactions by ensuring that the stakes for current accepted block are much higher than total cost incurred in validating all transactions. This can be maintained so by configuring the rewards/transaction in a block to be high initially and reducing it as the competition increases.
• When a node receives a request from a user, it can either respond to it themselves or share it with a peer. In first case they will receive direct reward in form of transaction fee and in second they will receive indirect reward in form of a valid transaction to include in their block. A node is hence incentivised to evaluate whether they can be the first to respond to the user or if someone else is better equipped to do so. This can be maintained so by configuring the reward/transaction in a block to be equal to transaction fee.
• When a block is approved, the transactions involved can be used to evaluate a list of shortest latency peers of underlying users. Which in turn can be used by any node to decide which peers to transfer a subsequent request to. A tit for tat mechanism will promote sharing of requests among nodes to mine valid transactions in return.
• An approved block will further provide a node data on which requests were recently cached by their peers. Based on distance from a user & staleness of cache a node can determine if there is any peer currently capable of delivering response to a user with better transaction time than them. This will lead to nodes discovering requests worth caching and hence higher coverage.
• Since transaction time will increase with staleness of requests, nodes will have an incentive to update data even if a peer has it cached earlier. Achieving a resultant cache expiry time.
• As response time from nodes increase, their peers will find it lucrative to cache the corresponding requests until enough peers have it cached to deliver a consistent response time.
• Initially, all peers in the network will be connected to each other. When the first requests are made, all nodes will respond. But the final accepted block will be the one where responses are made by geographically nearest nodes as staleness is not involved. This will allow discovery of shortest latency peers. When a new user joins the network, they too will get first response from a large number of nodes leading to discovery of shortest latency peers by same mechanism.
• Initially the unit economics for miners can be ensured by pegging the token value to those of various storage tokens and rewarding them accordingly. As number of unique requests/cached request increases, the rewards and token value can be adjusted accordingly.