IPFS-FAN: A Function-Addressable Computation Network

Alfonso de la Rocha
Protocol Labs

Yiannis Psaras
Protocol Labs

David Dias
Protocol Labs

Abstract

—Permissionless computation is one of the missing
pieces in the web3 stack in order to have all the tools needed
to “decentralise Internet services.” There are already proposals
to embed computation in decentralised networks like smart
contracts, or blockchain networks for computational offloading.
Although technically sound, their computational model is too
restrictive to be used for general purpose computation. In this
paper, we propose a general architecture of a decentralised
network for general-purpose and permissionless computation
based on content-addressing. We present a proof-of-concept
prototype and describe in detail its building blocks.

Index Terms—P2P, Permissionless, merkle-link, IPFS, Web**
Assembly, distributed computing

I. INTRODUCTION

Blockchain technology set the beginning of a new golden
age for P2P technologies with the appearance of Bitcoin. Since
the Bitcoin blockchain was introduced more than 10 years ago,
lots of new blockchain-based platforms have been developed,
launched, and are being in active use. Initially the vast majority
of blockchain platforms targeted the financial system, but
these platforms gradually evolved to accommodate increasingly
ambitious use cases such as Ethereum’s decentralised
applications [1], or a variety of decentralised storage platforms,
such as IPFS [2]. This new generation of P2P systems does
not limit itself to the financial system, but is building the
substrate to fix the Internet from its most commonly spread and
well-known flaws, mainly centralization, big tech dominance,
vendor lock-in, and privacy. The overarching idea is to deal
with those issues through a decentralised architecture built
upon P2P protocols. This substrate of P2P protocols aiming to
overcome the current limitations and unbalances of the Internet
are commonly referred to as the Web3 stack.

From decentralised storage, to transport abstractions, the
Web3 stack has already consolidated projects to supersede
many of the components of the current centralised Internet.
However, a general proposal to embed computation in decentralised
n networks that is able to scale and compete with
its centralised counterparts is still missing. There are existing
proposals for decentralised computation: from Ethereum smart
contracts [1]; to global collaborative computational infrastructures like iExec [3] and Golem [4]; and decentralised
general-purpose computation networks such as the Fluence
Network [5] and Dfinity’s Internet Computer [6]. These
platforms use varying approaches to embed computational
capabilities in a global decentralised network, but lack in
some way the ability to become the “de-facto” architecture
for general-purpose computation in P2P networks.

Along with P2P technologies, content-addressable networks
have also received significant attention during the last decade,
due to the promising features that they offer. Location-
independent content retrieval and arbitrary in-network caching
can increase delivery performance significantly and reduce
network resource requirements. Content-based object addressing
offers a way to uniquely identify every resource that exists
in the network - not only content. All of these features are
extremely useful for the construction of a network hosting
heterogeneous resources.

The recent advances in these two fields already offer all
the fundamental components required to build a consistent
proposal of a decentralised network for general-purpose
computation. In this paper we present a general model to build a
decentralised network for general-purpose and permissionless
computation based on content- and function-addressing. In our
system, both, content and functions are uniquely identifiable
and globally addressed. Functions run code and perform computations over content in the network. The input of functions
are content-addressed, i.e. uniquely identified, objects stored in
the network. The output is the identifier of a newly generated
content-addressable object, together with the result of the
computation. Data and code are available by all peers in
the network, enabling the composability of functions and the
deployment of complex use cases. These unique features,
primarily based on the content-addressing principle, eases the
decentralization of the system and improves its scalability
compared to existing projects. The modular architecture of our
proposal builds a core that can be leveraged by other projects
(including the aforementioned ones) to flexibly embed computation
in decentralised networks. The reference implementation
of our system is built on top of the InterPlanetary File System
architecture [7].

The contributions of our work are: (i) the identification of
the general building blocks required to build a decentralised
network for general-purpose and permissionless computation based on content-addressing; and (ii) a functional proof-of-
concept prototype of the “IPFS Function Addressing Net-
work”, IPFS-FAN [8], leveraging existing modules from the
Web3 stack and without the need of ad-hoc implementations.

II. RELATED WORK

Current proposals for permissionless computation in decentralised networks can be classified in three different groups:

(i) Smart Contracts offer a constraint environment to perform computations in blockchain networks. They are generally
identified by a network-wide unique id that can be used by any
peer in the network to call functions in it. Calling a function
of a smart contract triggers the execution of its code in all the
peers of the network (or at least in the ones responsible for
the consensus in the network), as any update in the state of
data triggered by a smart contract needs to be validated and
consensuated by all peers in the network. In order for this to be
possible, executions in smart contract must be deterministic.
They are extremely useful for the use cases accommodated
by blockchain networks, but are not suitable to deploy use
cases that require general-purpose computation, or are CPU-
intensive. Smart contracts are widespread in a great gamut of
projects in the blockchain space [1], [9].

(ii) Decentralised Computation Marketplaces [3], [4] appeared as an alternative way of overcoming the computational limitations of smart contracts. Platforms like Golem
[4] and iExec [3] offer a way of executing computationally
intensive and general-purpose programs in a decentralised
manner. Decentralised Computation Marketplaces aggregate
computational resources from providers in a decentralised
network. Developers can rent resources from the available
pool of resources to run their jobs. Unlike smart contracts,
in computation marketplaces the data and the code being
executed is not public, and developers request their execution
“on-demand”, sending the code and the data to the network.
The output of the computation is reported to the user, an
application or a blockchain network (or a multitude of them),
while a cryptocurrency over a blockchain network is used
to pay for the resource rental. Decentralised Computation
Marketplaces, however, are not suitable to host decentralised
applications running general-purpose computations.

(iii) Finally, Decentralised General-Purpose Networks are
general-purpose, permissionless computation platforms that
can host any kind of decentralised application. The main
exponents of this type of networks, Fluence Network [5],
Dfinity’s Internet Computer [6], share many of the core
components proposed by our model, such as: the use of a
universal runtime based on WebAssembly embedded in every
peer in the network; the concept of functions as the minimal
unit of code executable in the network; the use of a declarative
or programming language to orchestrate the composability of
functions deployed in the network; and the use of an entry
point to describe the code or application deployed.

Both proposals lack components required for the implementation of a complete general-purpose permissionless network:
none of them use self-describing strategies to identify code
so it can be uniquely and globally addressed in the network -
Fluence functions have a unique id per deploying peer, while
the Internet Computer uses a unique id per subnetwork; they
do not use globally accessible decentralised data structures
to represent application’s state (data is locally accessible and
location-dependent); they are not completely permissionless
and limit in some way the peers that can participate from
the protocol. Our proposed architecture for a general-purpose
permissionless network addresses all of these limitations. The
generality of our model offers the core over which projects
such as Fluence and Dfinity’s Internet Computer would be able
to deploy their proposals and leverage many of their already
implemented assets.

Finally, function-addressing, i.e. the identification of code
deployed in the network through a unique identifier, is not
a new concept, and it has been proposed in different ways
in the academic literature in the field of Information-Centric
Networks (ICN). Named Function Networking (NFN) [10]
presents a scheme where names are computation expressions
which include data and function names. Additionally, the
authors in [11] propose NFaaS, a framework that extends the
Named Data Networking architecture to support in-network
function execution. Functions can be downloaded and executed
in any node of the network, extending computation to the edge
of the network.

III. USE CASES AND IMPACT

A distributed network equipped with a content-addressed
computation model as the one described in this paper opens
the door to a great gamut of applications and use cases “out
of the box” such as:

Global serverless infrastructure: The ability to deploy
code that can be called and run from anywhere through a
uunique identifier offers application developers a platform to
deploy their back-end functions without the need for additional
infrastructure. End-users’ front-ends can directly interact with
content and trigger the execution of code in the network,
unleashing the promise of real decentralised applications,
improving applications maintainability and scalability, and
developers’ User Experience [12].

Load-balancing by design: The properties of content-
addressing ensures that code and content are location-
dependent. This means that the execution of functions does
not need to necessarily occur where the content or the code
is hosted. The higher the demand for a specific function in
the network, the more nodes get to store the code, and are
capable of running the function. Scalability becomes a much
easier challenge to deal with, as the closest peer with available
resources could run the function without having to scale the
infrastructure.

Increased Availability Backends: By not relying on a central
infrastructure and hosting an application in a decentralised
network, applications relying on the system ensures close to
100% availability as long as the required code and data are
replicated in enough providers in the network.

Collaborative computation and computation offloading:
Computationally expensive tasks can benefit from a network
of peers contributing their computational resources to perform
certain tasks. P2P collaborative computation networks
have traditionally been used for research purposes (such as
to perform complex simulations [13]). More recently, these
collaborative computation networks have been used to offload
computations to more powerful devices.

Computation near the data: When performing computations
over large datasets, it normally becomes more expensive
to transfer the data to the computation, rather than the opposite.
With IPFS-FAN, users can easily get the code near the data
for this type of use cases instead of the other way around.

IV. GENERAL-PURPOSE CONTENT-ADDRESSING COMPUTATION NETWORK

A permissionless computation network builds an infrastructure
where peers share their computational resources to host
data and run computations collaboratively. Its trustless nature
ensures that any peer can join, leave, and perform operations in
the network without requiring special permissions or
supervision from a central authority. Our system is built upon
content-addressing, offering in this way a scheme to uniquely
identify every resource in the system and link them unambiguously.

In order to build a content-addressable computation network,
the following modules are required:

1) P2P Substrate: Peer routing, content routing, p2p transport
protocols, etc. to enable the communication and interaction
between the different peers in the network.

2) Decentralised storage: Responsible for the collaborative
storage of data and code in the network.

4) Universally addressable and linkable data structure: To
uniquely identify every resource in the network, and enable the
representation of self-describing code and data. The identifier
of the resource should include all the information required to
identify its type and verify its integrity.

3) Universal runtime and bytecode: Execution environment
with a portable binary instruction format capable of targeting
any architecture, and that can be compiled from many high-
level programming languages. Code in the network is always
represented using this binary format so it can target the
universal runtime embedded in every peer (interoperability).

5) Decentralised programming model: Every piece of code
in the network is identified with its unique ID and exposes an
interface with its available functions and signatures. In our
model, each piece of code in the network is an independent
actor, that consumes data from the network and generates new
data to it. Everything in the network is identified with a unique
identifier (both code and data). When a function in an actor
is triggered, we pass as arguments the ids/links for the data to
be computed in the function’s actor. The output of the function
execution is new data added to the network and referenced
by an id. Using a universally addressable and linkable data
structure enables the de-duplication of data so that if an output
for an actor is already stored in the network, it can be directly
referenced by its id without requiring to explicitly add it (and
conveniently store it) again. Every actor in the system needs
to expose the signature of the functions it has exposed. This
is done through an ABI (Application Binary Interface). The
ABI is the entry point manifest of every actor. An actor’s
ABI specifies the unique ID of the actor’s bytecode (in order

Figure 1: IPFS-FAN Architecture

to be able to fetch it from the network), and the signature
of all the functions exposed by the actor. The unique ID of
an actor is inferred from its ABI, not from its bytecode (as
the ABI already links to the bytecode of the actor). Over this
programming model, a programming language can be designed
to orchestrate the resources and interaction with actors in
the network: from the deployment of new actors, to calling
them, referencing data, and implementing complex programs
composing the operation of several actors over data.

V. PRELIMINARIES

1) IPFS and the Web3 Stack: IPFS is a hypermedia protocol
that builds on the principles of: i) peer-to-peer (P2P)
networking and ii) content addressing. IPFS builds a
distributed and decentralised, P2P storage and delivery
network, which runs entirely on end-user devices and has
no centrally controlled components. Under the hood, the
IPFS Architecture is composed of a collection of subsystems
each of which can be used independently of IPFS, but together
form a robust foundation for a distributed, content-addressable,
P2P storage and delivery network. All these modules are
known as the Web3 stack.

libp2p is a modular network-layer library for P2P networks.
In libp2p, peers are identified by the hash of their
public key. The library includes all the essential techniques
to discover and connect peers, that is, from peer-discovery
to peer routing, NAT-traversal and provision for
several different transports that are easy to integrate.

The InterPlanetary Linked Data (IPLD) layer is a naming
and data management layer used by IPFS. IPLD builds
on the concept of “Merkle-DAGs”, that is, Merkle-Trees
out of Directed Acyclic Graphs. Every file added into the
IPFS system is converted into a Merkle-DAG, locally on
the device that adds the file. Each node of the DAG has
its own content address, which is the result of hashing of
the content itself. Once converted, every node within the
DAG is compatible with any data structure that wishes
to make use of them, or include them as nodes in their
own DAG.

Multiformats is a set of formatting rules with specific
structure that is used to declare the set of protocols used
in a P2P session. In other words, Multiformats is a data
representation scheme that adds self-describing attributes
to the data it formats.

2) Content IDentifier (CID): IPFS uniquely identifies content
in the network through a CID. CIDs are structured by
Multiformats inherently include the following properties:

CIDs are immutable and permanent: given that the
identifier of content is its own hash-digest means that any
change to the content itself will result in a totally different
hash and therefore, identifier. This makes every content
added to the IPFS network immutable and therefore,
permanent as an identifier of a version of an object that
will never change. The notion of permanence here is not
to be confused with the property of permanent availability
in the system.

CIDs are self-certified and verifiable: upon fetching a
content chunk from the IPFS network, a user calculates
the hash of the content he received and compares it
against the hash digest which he requested from the
network. If the two match, then the content is guaranteed
to be authentic and received without errors.

3) Adding and fetching content in IPFS: When adding
content to the IPFS network, the content is not replicated or
uploaded to any external server. The content stays local on
the user’s device. Instead, it is the Content Identifier (CID)
together with a pointer to the user’s machine that is made
known to the network and in particular to the Content Routing
component of the system. This is so that others can point
their requests to the right machine and retrieve the content
through the content resolution process described below. The
user adding content is called