IET Cyber-Physical Systems: Theory & Applications / Early View
ORIGINAL RESEARCH
Open Access
   
SwarmAd: A decentralised content management system
Tommaso Baldo, Mauro Migliardi 
First published: 09 August 2023
https://doi.org/10.1049/cps2.12071
Abstract
Online presence is becoming an important part of everyday's life and online communities
may represent a significant source of engagement for the elderlies. Nevertheless, many
may struggle to be online due to a lack of expertise, and a decentralised architecture may
provide a solution by removing intermediaries, such as a webmaster, while not requiring
expensive cloud solutions. However, issues concerning accessibility, security, and user
experience have to be tackled. The paper focuses mainly on three issues: providing a
human-readable domain, moderating content, and creating a reward system based on
user reputation. An architecture is proposed based on Ethereum and Swarm. Smart
contracts provide an automated set of rules to handle enterprise registration, content
creation, and decision-making process, while Swarm serves both as distributed storage
and the web host. Besides, in combination with Ethereum Name Service, Swarm provides
a secure, distributed, and human-readable point of access to the web interface. The
paper also describes an innovative two-token system where one token is meant to be a
trustworthy reputation metre and the other is a spendable coin to get rewards. The final
result is a fully decentralised, authenticated and moderated platform where users can
aggregate and share their content presentations on the Internet.
Abbreviations
CT
community token
DAO
decentralised autonomous organization
dApp
decentralised application
DHT
distributed hash table
NFT
non-fungible token
RP
reputation points
SME
small medium enterprise
1 INTRODUCTION
Online presence is becoming an important part of everyday's life and online communities
may represent a significant source of engagement for the elderlies [1]. The idea of building a
decentralised web is catching up because it means moving away from central authorities,
removing the need to interact with management layers and empower end users.
Decentralisation is not a monolithic goal but it is rather a mixture of different tasks and
topics, such as giving data ownership back to users or creating a censorship-free web [2].
Communities can be empowered to take crucial decisions about the future of the platform
they are using by organising themselves into Decentralised Autonomous Organisations
enabled by blockchain technology [3]. Hence, a community-centric model can be interesting
in several fields besides the empowerment of ageing users. As another example, according
to European Commission, 99.8% of enterprises in Europe are of micro, small or medium size
[4] and only 34% of these have adopted or are planning to adopt basic digital technologies,
such as a website [5]. All of these considerations generated the idea of building a distributed
platform to provide an implementation for a decentralised shared space where the ageing
user may leverage online presence to enhance their engagement and Small and Medium
Enterprises (SME)s may advertise their products [6] with limited costs and management
overheads. The first solution for such a system has been proposed by Martini [7] but the
lack of maturity of some technologies prevented it from getting rid of the three following
issues:
1. Data Persistence: it is difficult to ensure data persistence in a distributed storage over a
long period without a central point of failure. Data persistence is a key point to making
a fair social platform. Indeed, most distributed storage systems save data, such as
cache memories, and hence, popular content is more likely to be stored while
unpopular files could be very rare or even lost.
2. Naming: if we use a distributed storage as the web host, providing a secure and
human-readable point of access is challenging because the content is accessed by a
hash reference, which is not human-readable. Without a human-readable domain,
accessibility and user experience decrease severely.
3. Content visibility: lacking a central authority, we have to move away from traditional
web applications where an algorithm can efficiently propose content to users
according to their data. An unorganised content disposition could undermine customer
experience and users' motivation to post quality content.
Under these considerations, we have felt the need to propose a new platform able to
overcome the issues stated above and others, such as a mechanism for moderating content,
identified after an extensive literature review.
Table 1 sums up our goals and the solutions we illustrate in this paper.
TABLE 1. The research objectives and the solutions we propose to achieve them.
Research objective
Motivation
Proposed solution
Finding a distributed
Without ensuring data persistence, we
Adopting swarm
storage able to ensure
could easily end up building an amnesic
data persistence
platform.
Solving hash references
A human-readable domain is essential to
Combining Ethereum name service and
into human-readable
provide, at least, a decent user experience
swarm feeds to provide an immutable
names to ease content
and human-readable link to the web
retrieval
interface
Creating a content
Without any central authority, users are in
Writing a smart contract to make users
moderation mechanism
charge of maintaining the platform.
able to handle decision-making processes
Organising in a fair and
Since we are building an advertising
Creating a modular homepage and
rewarding way the
platform, it is crucial to be able to show
assigning spots to the best users of the
content in the website
the best products possible to attract
platform, the newcomers and the most
homepage
customers and new users
loved products listed on the platform
Creating a reward system
User contribution to the content
Creating a tokenomics to measure user
moderation is essential to make the
contribution. Users will be able to redeem
platform working, hence we need a
special services or rewards by burning
reward schema to motivate users in those
this token.
activities
To prove the validity of our solution, we have designed and implemented a dApp based on
Swarm as the storage layer and Ethereum blockchain for user authentication. This dApp
provides a social portal capable of aggregating SMEs and allowing them to cooperate in
maintaining and sustaining a common platform where they can advertise their products
with dedicated content. It is our opinion that this dApp removes the entry barriers made by
economic investments and technological skills required by building and maintaining a
traditional website. On top of that, it offers better brand awareness and better exposure on
a national and international scale by creating a single and organised point of access for end
users. The rest of the paper is organised as follows: in Section 2, we analyse the state of the
art; in Section 3, we describe the design of our solution; in Section 4, we describe the
tokenomics; in Section 5, we give an example of the functionalities of the platform; finally in
Section 6, we provide some concluding remarks and describe potential further
developments of our system.
2 STATE OF THE ART
Social media platforms where users can create, comment and share content are the big
thing in the last decade. By extension, many decentralised alternatives have been proposed
to offer similar functionalities, and at the same time, to exploit the advantages of Web3,
such as censorship resistance or data ownership. With regard to this, we can find several
examples, such as decentralised music-sharing platforms [8-10], social media [11, 12], videosharing platforms [13, 14], and even a decentralised process for scientific publication and
peer review [15].
Generally speaking, decentralised applications leverage the hash-on-chain pattern: files are
stored in a distributed storage and the hash references are saved on the blockchain. In this
way, it is possible to minimise on-chain data and hence save on gas costs [16]. In regard to
User-Generated-Content (UGC) networks, the authors in ref. [17] describe a system based on
IPFS and blockchain to create a public discussion platform. In detail, it is interesting the
implementation of a ranking algorithm based on the number of comments and upvotes to
present quality content to users. Nevertheless, in our use case, we do not expect users to be
collaborative with each other. As a result, a ranking algorithm of this kind is not a good fit for
our platform. Another example is LBRY, a decentralised content market where users can
share and purchase digital goods [18]. In contrast with the general trend, LBRY relies on a
proprietary peer-to-peer network, namely the LBRY network, and on a proprietary
blockchain, LBRY blockchain, based on Bitcoin. Despite that, the model is still attributable to
the hash-on-chain because metadata are stored on a blockchain, while the actual content is
stored on Distributed Hash Tables. On the other hand, the choice of a Bitcoin-based
blockchain could be a barrier to implementing more complex systems, such as a consensus
mechanism or a moderation one. On top of that, relying on a proprietary network could also
be an issue if the application is not widely adopted because the number of nodes could not
be enough to ensure data availability and persistence over a long period.
More relevant to our use case, decentralized e-commerce is a trending topic in literature
because a blockchain-based approach can ensure tamper resistance, and increase
traceability and transparency [19]. In this sense, it is a remarkable approach described in
[20] where a decentralized structure can avoid the lock-in effect on users and allow them to
freely switch platforms according to their liking and needs. This issue is particularly relevant
when considering music platforms or digital libraries where often centralized solutions
adopt a proprietary file format. Another intriguing implication is the one proposed in [21]
where smart contracts automate several activities to increase the efficiency of the supply
chain. As further examples, two decentralized marketplaces based on Ethereum and IPFS
have been described and tested [22, 23]. Both projects do not implement a consensus
mechanism to make users handle content moderation. On top of that, there are no
considerations about data persistence in IPFS.
A blockchain-based marketplace is even more catching if we take into consideration the
Customer-to-Customer model, typical of second-hand or resale markets. Indeed, a
distributed ledger can enhance the trust between sellers and buyers. As an example, in [24],
the authors present a framework to increase transparency and avoid fraud in decentralized
e-commerce. Concerning the same topic, the authors in ref. [25] describe how blockchain
can minimize the risk and the uncertainty in Customer-to-Customer sales.
However, if we focus on decentralized Content Management Systems (CMS), we can find
mainly just two relevant examples. First, there is HiDe [26]. HiDe is an offline-first
decentralized CMS with a sustainable and permission-less reward distribution protocol
called HiDe Protocol. Starting from the HiDe open-source codebase, it is possible to build
social media dApps where users showcase their posts or articles and get rewarded for
activities and contributions.
HiDe also leverages the hash-on-chain pattern. More in detail, HiDe has adopted Ceramic as
distributed storage and Polygon as blockchain. As a result, each user has a list of posts or
articles associated with his account, which is saved on the blockchain. The HiDe protocol
also implements a complex token economy to make this entire system self-sustainable. As
the first layer, there is the Treasury where users can stake their money to financially support
the HiDe project. Stacking produces Voting Power tokens that can be used for voting about
any relevant decision, such as budget allocation. On top of that, HiDe has also an ERC-20
currency: the Community Token (CT). In comparison with the standard implementation, it
automatically decreases block by block. Community Tokens can be burned to mint (or, in
HiDe slang, reward) a Non-Fungible Token. Finally, HiDe is mainly focusing on becoming a
community-building tool where social media features help users to bond, and a reward
system motivates content creators to produce quality content.
As a second example, we may cite Helios [27], a project funded by the European
Commission to provide a platform to develop decentralized social network apps for Android.
The main focus of the Helios project is on privacy, ownership, and protection of users'
personal data and content. It is a modular platform composed of three layers: Helios core,
extension modules, and applications. The Helios core has different components. Each one
provides one specific functionality. For example, there is a communication manager, which
provides access to the p2p network and it includes basic messaging functionalities. As
another example, there is also a security manager, which handles access policy and privacy
settings according to an access control system based on access control lists [28]. On top of
that, the Helios core provides two modules, Social Ego Network Manager and Context
Manager, to create and manage the Contextual Ego Network, a structure to model the real
life of users and their social relationships inside the platform [29].
At the second level, we have extension modules. As the name suggests, extension modules
may be developed also by third parties. Their goal is to provide additional functionalities
based on the Helios core. As an example, an extension module may implement a media
streaming player or a graph mining algorithm for content recommendation. Among several
extension modules, we can find the reward system. The reward system aims at motivating
users to be active on the platform. The whole Helios tokenomics is built around a single
utility token, called Helios Token or HLO. Users can collect HLOs by performing simple
actions like creating and sharing content or upvoting and downvoting content. Then, HLOs
can be spent to access premium content, unlock premium features or purchase a third-party
service [30].
Finally, we have the application layer. Developers can take advantage of the functionalities
provided by the Helios core and extension modules to create a social network service
working on Android. As an example, in the Helios ecosystem, we can find helios.talk, an app
that allows users to communicate in a secure and decentralized way. Another one is
helios.CJReporter, an app to share videos anonymously. The videos are stored on IPFS and
the access control is managed by an Ethereum smart contract.
2.1 Open issues
If we consider HiDe and Helios, we can see that their main focus is on social functionalities,
like commenting or sharing a post. As a direct consequence, content creation is the beating
heart of both platforms because it feeds a whole set of social functionalities. This claim is
confirmed by the respective reward systems. As an example, Helios awards 10 points for
creating a post, while the reward for sharing one is only 2.
Yet, if we consider our use case, that is, a platform where enterprises can post and advertise
their products, it is clear how Helios and HiDe reward systems are not a good fit. First, we
are in a competitive scenario, where it is unlike that users are willing to share others'
content. Indeed, they are competitors, so sharing a post is like donating free advertisement
to a market rival. Second, in our platform, we do not aim at stimulating new content
creation; in fact, an enterprise posts new products according to its own plans and
manufacturing capabilities. A user must not feel pushed to generate new content just for the
sake of it; on the contrary, changes have to be designed with care. In this sense, there is a
deep difference between social networks both their traditional versions and their
decentralised versions (i.e., Helios and HiDe) and our system: in the first case, continuous
user engagement is the absolute goal and in the second case, continuous consumption of
ever-changing content is not a significant goal. Furthermore, there is a bigger issue. Both
HiDe and Helios do not face community moderation. This claim is also confirmed by their
reward systems. The lack of a moderation mechanism can be justified because in social
media, especially if decentralised, it is important to ensure a censorship-free system where
every user is free to share his opinions. However, in our project, community moderation
activities are crucial to keeping a clean and working platform. Indeed, the platform is
oriented to a market niche and it is important that every user is on the same line and every
product is coherent and on-topic. As an example, when a new user requests to join our
platform, registered members have to vote to accept or reject the newcomer. This is another
big difference in comparison with social media apps where everyone can usually simply sign
up.
Finally, Table 2 recaps the main differences.
TABLE 2. A comparison between our platform and similar systems described in literature.
DeCMS
Distributed
Data
storage
persistence
Tokenomics
Governance
Content
User
moderation
registration
Helios
IPFS
Not defined
HLO token
Not defined
Not defined
Free
HiDe
Ceramic
Not defined
HiDe
Coin-based
Not defined
Free
protocol
Martini
IPFS
Not ensured
Not defined
Democratic
User voting
User voting
SwarmAd
Swarm
Ensured
2-token
Democratic
User voting
User voting
system
3 ARCHITECTURE DESIGN
Building the desired platform requires to:
authenticate users in a safe and secure way: a CMS requires a strict access control
mechanism to ensure that only registered users are able to use functionalities like posting
a new product or voting in a poll. Given the decentralised structure, a blockchain is the
best way to achieve this. Indeed, by saving relevant information in the blockchain, we can
avoid unauthorized access and tampering.
load images on a distributed storage system: saving large files in a blockchain is
expensive and it is not sustainable. As a solution, it is better to adopt the hash-on-chain
pattern to optimise gas costs and reduce the writing time on the blockchain.
create a consensus mechanism to make users able to vote about relevant decisions:
decentralisation empowers users to be responsible for their community. In this sense, it is
crucial to remove inappropriate items and users who misbehave to maintain the
platform's reputation clean. On top of that, it is also important to make users able to
propose and vote for new settings and improvements to keep the platform updated and
in step with the times.
create a tokenomics: as we have underlined in the last point, users' participation in
community activities is fundamental. Hence, it is equally important to reward users to
motivate them in taking part in those activities.
As a result, we have designed the platform as shown in Figure 1. In detail, it is made of a
blockchain, a distributed storage system and a web interface. On top of that, other agents,
like Metamask, and libraries, like Bee-js, are required to make these components work
together. Later in this section, we describe each component separately and understand how
they interact with each other to provide the desired services.
FIGURE 1
Open in figure viewer
Architecture design.
PowerPoint
3.1 Backend
Like in every dApp, a blockchain is designed to act as a back-end server by running a set of
smart contracts that define the business logic. In our case, we have decided to adopt
Ethereum. When designing the structure, we have opted for a modular architecture made of
different smart contracts. Using this approach, we gain in terms of upgradability and simplify
evolution; yet the base system complexity grows. As a result of our design choices, we have
three building blocks:
SwarmAd is dedicated to managing users' registration and their data. It also defines the
basic operations like creating, reading, updating and deleting a product or an enterprise.
Governor is a smart contract dedicated to handling the decision-making process
Tokenomics is a set of three contracts that creates a sustainable reward system
SwarmAd is the core contract of the whole platform. It defines the data model: Enterprise and
Product are the two structs to specify all the information we need. In Listing 1 and 2, we can,
respectively, see the information that the two objects store.
Listing 1. ‘Enterprise struct in SwarmAd contract’
Listing 2. ‘Product struct in SwarmAd contract’
Then, there are two mappings where all the registered enterprises and the posted products
are stored. The mapping keys are the owners' addresses and product identifiers,
respectively. The latter is computed as keccak256 hash during the item creation. Since
mappings are not iterable in Solidity, these keys are also stored in two arrays to ease the
data fetching by the front-end side. On top of that, here is also a mapping that works as a
waiting list. As we have said before, the membership is restricted and users already enroled
have to accept or reject a possible new member. As a result, whenever a new request
comes, the new enterprise is saved on this temporary space until the poll is closed. Finally,
SwarmAd defines also a set of functions to create, update and delete enterprises or
products. In Listing 3, we can see how an enterprise can create a new product.
Listing 3. ‘Function to create a new product’
As we stated before, we rely on the hash-on-chain pattern to save and retrieve images. It
works as follows: we first upload the image on the Swarm network and then we save just the
hash reference on a blockchain. Since the reference is just an alphanumeric string, it is way
less expensive than saving the actual image on Ethereum. As a result, when the web
interface has to fetch product images or enterprises logos, it will first read the blockchain to
get the reference and then it will ask Swarm to download the image related to that
reference.
Governor is the second building block. It manages the whole decision-making process. It
works as follows: when called, it receives as input a function to execute. It creates a poll
where only registered users can cast a vote. The vote can be: for, against or abstained.
Finally, when the deadline is met and the poll is closed, Governor will execute the function if
the quorum is reached and the majority has won. Listing 4 shows how the main smart
contract, that is, SwarmAd, calls Governor when a new enterprise has to be created. In this
case, the function to execute is moveEnterprise which, as the name suggests, moves an
enterprise from the waiting list to the enterprise list. In other words, after calling this
function, the new user will be recognized as a registered one.
Listing 4. ‘How to call Governor to create a poll’
As we can see from Listing 5, the procedure to close the poll requires a series of checks
before declaring the poll outcome. If all the checks are positive, the function in Listing 6 is
called. In detail, it runs the function attached to the poll object and it returns the outcome.
Listing 5. ‘Procedure to close the poll’
Listing 6. ‘How Governor executes the function attached to the poll’
In this regard, it is important to make a note about the voting system. Indeed, coin voting is
a standard in DAOs; yet, we find it not convincing as it can quickly become a plutarchy if the
voting power is condensed into a few wallets [31]. On one side, creating a governance model
based on a reputation score seems an intriguing solution because it gives more power to
users who actually contribute to the platform. On the other side, it is still not completely fair
and democratic, especially for newcomers. Considering our use case, we have decided to
move to a governance model based on proof-of-personhood, where every registered
member can express his vote and it counts as one.
3.1.1 Access control
In smart contracts, it is fundamental to define who is allowed to call certain functions and
perform the related actions. Indeed, since all the codes are public and visible via blockchain,
potentially anyone is able to call an external contract. Under these considerations, we have
decided to implement role-based access control using an API developed by OpenZeppelin. 1
We have created three different authorisation levels:
GOVERNOR_ROLE: it is for distinguishing actions that only Governor can take, such as
banning a user or an item or changing voting settings.
ENTERPRISE_ROLE: it is specific for registered members. It is granted when an enterprise is
accepted in the platform. It is revoked if the enterprise is removed.
MINTER_ROLE: it identifies the entities that are able to mint the tokens.
3.2 Swarm
Swarm is a peer-to-peer network of nodes that provides a decentralised storage system and
communication service. It is organised into four layers: the underlay p2p network based on
libp2p protocol, the overlay network built upon Kademlia to enable peer communication
using DHTs, high-level access via API, and the application layer [32].
Since the routing is based on Kademlia forwarding, it is fundamental that each peer is
cooperative and shares its bandwidth to help another node download or upload a file.
Nevertheless, a node is a selfish agent and its actions are aimed at maximising profit and
minimising resource usage. For the above reasons, Swarm implements a built-in incentive
system that aims at creating a self-sustainable environment and ensuring data persistence
in the network. In this regard, we can distinguish two different incentive types: one for
sharing bandwidth and one for sharing storage. About the first one, a node gets rewarded
when it retrieves a chunk. This has an important side effect: profit is directly proportional to
content popularity because the more often a chunk is requested, the more a node earns.
Since data persistence must be ensured, here comes the need for a storage incentives
system. First, when uploading a file to the network, each user has to buy a postage stamp
and attach it to the request. Postage stamps serve as a spamming filter but also they can
signal the relevance of a certain file. Indeed, the larger the postage stamp attached, the
longer the file will be kept in the network. Swarm has another storage incentive: the postage
lottery. As we have seen before, an unpopular chunk does not provide any retrieval reward.
The lottery goal is to compensate for that missing earnings and make sure that every peer is
maintaining the files it has to.
3.3 Accessing the swarm
Since we are relying on Swarm, we need an entry point to access the network for
downloading and uploading the files. In this regard, it is important to distinguish three
different types of Swarm nodes, also called Bee clients:
full node: the standard one. It participates in retrieval, forwarding, and storing. It is
rewarded according to its contributions.
light node: it does not participate in forwarding and storing but it is able to upload
content on the network once a valid wallet is associated and funded.
ultra-light node: it is a light node without a wallet. As a result, it can download files but it
cannot upload them since it has no economical resources to buy the postage stamps.
Among the different options, running a full node is without a doubt the best option because
it has no limitations and it can be a profitable activity since the user would participate in the
Swarm incentive system. On the other hand, it is for sure a complex operation because it
requires certain expertise and familiarity with computer science. A light and ultra-light nodes
are easier to set up because everything is handled by a desktop application, called Swarm
Desktop. 2 The user has only to download and install the application; however, navigating via
Swarm Desktop does not provide any reward. In an ideal case, the best solution is the one
where every user runs his node. It is a win-win situation because users can earn rewards
and the platform fault tolerance is very high. However, running a node could be an entry
barrier very difficult to overcome. Hence, this is not a feasible solution because we want an
easy and intuitive user experience. To solve the issue, we have decided to implement a
private gateway. It is a full node running a piece of software provided by the Swarm
Foundation 3 to act as an entry point to the Swarm network. Since it is a full node, it is also
able to pin files. Pinning the front-end asset folder could provide an extra guarantee of data
persistence. Regarding the latter, Swarm supports the ‘upload and forget’ principle: once the
content is uploaded, it is maintained by the network itself. As a result, if this private node
went down, the data would still be available. It is also important to notice that the gateway is
not a single point of failure. Indeed, in case of denial of service, users could access the
network by another gateway, such as the public one, 4 or another node, for example, Swarm
Desktop. Furthermore, Swarm Foundation is actively developing a browser extension 5 to
ease the switching between a list of Swarm clients. In this way, a user is able to select his
preferred node as the trusted endpoint to channel all the requests. However, at the
moment, the extension is still just a proof-of-concept so we have decided to avoid relying on
it. Nonetheless, it could be an interesting addition in the future.
To access our gateway from the front-end interface, we use a dedicated Javascript library
written by the Swarm Foundation. 6 This allows the creation of an instance of a Bee client
receiving the gateway URL as a parameter. Then, using functions such as uploadFile and
downloadFile, we can interact with the network and provide the desired functionalities to our
users. It is important to notice that the attachment of the postage batch is handled by the
gateway. A specific setting enables it to automatically buy the postage batches. This allows a
much faster uploading and hence a better user experience because buying a batch can
require up to a minute.
3.4 Entering the website
Swarm also serves as the web host. This solution enables the creation of a fully
decentralised application but it also entails a major issue in accessibility. Indeed, Swarm uses
a content address protocol to store and retrieve files. Consequently, we need a 256-bit
Swarm hash reference to get the desired content. Imagine the front-end asset folder is
referenced by this value:
09 d 1 d 4049 f 7163262 e 5 d 52695256 a 6 c 68 b 23 a 77 e 5 a f b 7 e c e 6 a e 3252 b 55 b b e 476
If we want to access the web interface, we have to type something like this in our browser
URL search bar.
“
https://{gateway_address}/bzz//{hash_reference}
”
An easy solution is to translate the reference into a human-readable string using Ethereum
Name Service (ENS). 7 The problem is that a Swarm reference changes every time we update
the folder because it is computed as the Keccak hash of the folder itself. As a result, we are
forced to change the mapping between our ENS domain and the reference after every
update. Since ENS is blockchain-based, any change requires a transaction and hence an
expense. To avoid this issue, we have decided to use a particular feature provided by
Swarm, namely the Swarm Feed, that allows associating mutable content with an immutable
reference. Indeed, the Feed reference is associated with the signer's private key instead of
the content itself as it usually happens in Swarm. Due to this feature, we can upload the
front-end assets on a Swarm Feed. Whenever we want to make some changes in the folder,
we overwrite the Feed and its reference will not change because of its immutability.
Consequently, we have to map its reference into a human-readable string only at the first
upload.
As a very last point, we can simplify the URL since the gateway supports bzz.link. The latter
allows the translation of ENS names into Swarm's protocol calls. The previous URL becomes:
“
https://{ENS_Name}.bzz.link
In conclusion, Figure 2 summarises the procedure to get the web interface from a user's
point of view.
”
FIGURE 2
Open in figure viewer
PowerPoint
How a user gets the web interface from the Swarm network.
3.5 Front-end
The web interface of our system uses React. Since it is a Single Page Application, the content
is dynamically loaded. The interface has a general schema made of a header, a body, and a
footer. The body loads a different page according to the user's actions. For example, at the
first loading, it is set to the home. A user can navigate through the pages using the
navigation bar. In our design, we imagine having five different pages:
Home: it shows enterprises and products
Register: a registration form to enable the creation of a new profile
Create: a page to create and post a new product
Forum: a page to check the poll results and vote for new polls
About: a simple landing page that describes the platform
3.5.1 Showcase
Showcase is a special React component we have written to show details about products or
enterprises. The idea is to use different Showcases to organise the homepage content. Since
we are talking about an advertising platform, it is important to show the best it can offer in a
fair way. Indeed, giving a visibility boost to certain enterprises is a relevant edge over their
competitors. Consequently, we want to reserve some spots on the website homepage for
the users who have been more active in the platform moderation and activities. For
example, we could create the following four Showcases:
Best Users: it shows the users with the highest reputation
Highlighted Spots: a set of purchasable spots
Voted by the community: a selection of products voted by the members
Latest: a selection of the latest added products. It is a way to give a boost to newcomers'
visibility.
4 TOKENOMICS
In this section, we will define a reputation schema to identify and reward the users who are
cooperating and helping to sustain the platform. First, we need a reputation score that can
increase or decrease according to the user's actions. At a first glance, we have thought to
create a single ERC20 token. In this way, users could gain tokens and then burn them into
rewards. Nevertheless, there is a major contradiction. Indeed, if the token is spendable to
get rewards, it is also possible to sell and buy tokens from other parties. As a consequence,
the reputation score is meaningless because it is possible to buy and sell reputation. For
example, the less-active user could easily buy thousands of tokens and overtake the
members who actually earned their tokens from the platform reward system.
For this reason, it is not possible to create a single token, which is signalling the users'
reputation and at the same time is compensating users. A solution to solve this problem
could be to create only a non-transferable token to act as a marker of users' reputations.
However, it would be very limited when talking about tokenomics because users would not
be able to redeem rewards according to their liking. Since a proper reward system is crucial
to keep users engaged, we have devised another solution: creating a two-token system. In
our design, we have Reputation Points (RP) and CT. Reputation Points is based on the ERC-20
standard but it is not transferable because it signals the users' reputation. Users can gain
RPs from various activities like voting in a poll or reporting an inappropriate item. On the
other hand, CT is a standard ERC-20 token so it is spendable to buy rewards. It is important
to notice that CTs are generated according to the amount of RP a user has. We can make a
parallelism with the Ethereum consensus protocol where validators stake a certain amount
of ETH. This deposit can increase if it follows the rule or can be slashed if it goes against
them. We have seen a similar mechanism also in HiDe where users stake real money to get
voting power. In other words, HiDe proposes a model where investors' influence on
budget allocation is directly proportional to the amount of money invested. Despite this
model being well-designed and logical, we have moved away from coin governance and
proposed a model where user contribution is measured according to their dedication to
community activities rather than in economical terms. Indeed, in our use case, users are
each other competitors so we want to completely avoid the risk of a user being able to
impose his will on others. As a second point, we think moderating and filtering content is
more relevant than economic investments to keep our application working properly. To sum
up, in our platform, users ‘stake’ RP, which ‘produce’ a spendable coin. Due to this approach,
we create a sort of feedback loop: users are interested to claim rewards using CTs but CTs
are minted only by RPs. Hence, users are motivated to farm RPs to produce CTs. Even if a
user is not interested in buying rewards, he can sell CTs to others who are interested. In any
way, he has tangible rewards for his actions.
4.1 Tokenomics implementation
The main issue we have faced while implementing the tokenomics is concerning the interest
computation. Indeed, scheduling function calls is not directly supported by Ethereum.
Hence, we have to resort to third-party services or lazy evaluation. Considering the first
option, a feasible solution could be to write a function to compute interests and schedule it
to be executed every day or even for a smaller period. This approach has two drawbacks:
relying on a third-party service adds a single point of failure to our platform, and especially,
gas fees related to the function execution are inversely proportional to the period we choose
to compute interests. Instead, lazy evaluation is based on the fact that we perfectly know
when a user gets new RPs. To be clear, the idea is to compute interests right before a user is
going to get new RPs. In detail, we use the following formula:
C T = RP ∗ r ∗ t
where r is the interest rate and t is the time that occurs between the last time the user
earned new RPs and the moment in which interests are computed. In Listing 7, we can see
how the smart contract performs this operation.
Listing 7. ‘How Rewarder computes interests’
To be precise, we have not defined yet the interest rate r because we believe that it is
needed an extensive and accurate analysis to tune this value and optimise the model, as we
will point out in Section 6. After the amount of CTs is computed, they are saved on a local
mapping called Vault. It saves the amount of CTs a user can withdraw. Listing 8 shows the
procedure to add and burn RP from a user's wallet. As we have said earlier, a user's balance
of CTs is updated at every new distribution of RPs.
Listing 8. ‘How Rewarder mints and burns RPs’
To actually get the CTs into his wallet, a user must trigger a function called Redeem. In this
way, we optimise the gas consumption since updating a variable is less expensive than
calling an external function. In Listing 9, it is possible to read the function in charge of this
procedure.
Listing 9. ‘How a user can redeem Community Tokens’
As a result, we just need to keep track of the last time an interest computation has been
performed for each user. In comparison with scheduling, lazy evaluation allows us to
compute interests only when actually needed and hence we can optimise the model by
saving on gas fees.
5 AN EXAMPLE: CREATING AN ENTERPRISE
The process of creating an enterprise profile is a good example to better understand how
the platform is intended to work. Indeed, all the components we have described in Section 3
are involved.
We have set up a local test net that perfectly reproduces the architecture represented in
Figure 1. First, we have used Truffle Ganache 8 to create a local Ethereum blockchain.
Ganache also provides 10 Ethereum accounts funded with 100 ETH each. It is possible to
add these accounts to Metamask by inserting the private keys. Due to this, we can simulate
users' interactions with the web interface without spending actual ETH. Then, we have set up
a local Swarm network using bee-factory. 9 It is a Docker cluster made of six different
containers where four of which contain the image of a basic Swarm node. From the host
machine, it is possible to interact with these nodes from ports: 11,633, 2163, 3163, and 4163.
On top of that, we have installed the gateway service on the first local Swarm node. As the
last step, we have manually changed the /src/utils/docker.ts file in the bee-factory repository
to bind port 3000 of the gateway to port 13,000 of the host machine. As a result, we can
easily interact with the gateway at:
l o c a l h o s t : 13000 / b z z /
Imagine Carl is a new user who wants to join the platform. First, he has to fill out a form and
write all his enterprise's information. Then, SwarmAd adds Carl to the waiting list. At the
same time, SwarmAd calls Governor to create a new poll. Figure 3 sums up this process.
FIGURE 3
Open in figure viewer
PowerPoint
Creating an enterprise.
After that, all the registered users can express their preferences about Carl's acceptance. If
the function castVote is called within the deadline, Governor updates the poll and it saves the
user's preference and his Ethereum address, as we can see in Figure 4.
FIGURE 4
Open in figure viewer
PowerPoint
Voting a poll.
After the deadline is met, a user can close the poll. Governor checks the result, and if the
majority has voted for the proposal, it executes the function embedded in it. In our example,
we imagine that everybody wants Carl to join the platform. As a result, Governor executes
moveEnterprise to insert Carl's enterprise into the platform. It also deletes Carl from the
waiting list. As the final step, Governor calls Rewarder to award users who voted and
punishes those who did not. Obviously, rewards are in the form of RP while penalties are
subtractions of RP from users' wallets. In Figure 5, we can see a graphical representation of
this process.
FIGURE 5
Open in figure viewer
Rewarding users.
PowerPoint
5.1 Performance analysis
Low latency and low transaction fees are two important factors to keep in mind when talking
about decentralised applications [33]. Even if the actual choice of the blockchain where we
will build our platform is postponed to future work, we have simulated the behaviour of
different blockchains to understand how they can impact the time required by an operation,
and hence in a larger sense, how they can impact the user experience. Before we delve into
this topic, we have to recall the concept of block time. By definition, it is the time separating
two blocks. As a direct consequence, we can think of it as the max amount of time we have
to wait before a transaction is confirmed and executed by the nodes. It is easy to see how a
large block time can translate into a relevant wait and hence it can undermine the user
experience, especially if we compare to centralised solutions where the execution is almost
immediate. About our experimental setup, we have relied upon a special Ganache feature
that allows us to set the block time to a specific value. By default, Ganache creates a new
block for each transaction so its block time is equal to 0. For evaluating the platform's
performance, we have taken into consideration the most popular layer-2 solutions [34]. To
be precise, Table 3 recaps the five block time we have tested to simulate different
blockchains.
TABLE 3. The block times of different blockchains we have tested on Ganache to evaluate
the time required by creating an enterprise.
Chain
Block time [s]
Ganache
0
Arbitrum
0.4
Polygon
2
Gnosis
5
Ethereum
12
Then, we have created a Ganache instance for each different chain using the same settings
with the exception of the block time. We have run a basic test to create an enterprise profile
for each Ethereum account created by Ganache. The test, namely PerformanceTest.js, is
made using Mocha, a Javascript framework. 10 After running a single assertion, Mocha
retrieves the time required for that operation. As a result, we are able to collect a
trustworthy time measure from Mocha logs. In Figure 6, we can see what we obtained. As it
is logical to think, the longer the block time, the longer the wait to complete the operation. It
is also interesting to notice how Polygon is similar to Arbitrum despite having a four-time
larger block time. These considerations, in combination with an accurate analysis of gas fees,
will be crucial to find the best fit to realize the platform.
FIGURE 6
Open in figure viewer
PowerPoint
The boxplot shows the time required to create an enterprise profile for each blockchain
we have taken into account.
6 CONCLUSIONS AND FUTURE WORKS
In this paper, we have described a fully decentralised platform to create an authenticated,
moderated and shared showcase where users can present their content. Such a platform
might both empower ageing users with an enhanced online presence capable of
maintaining a significant level of engagement and may allow SMEs to advertise their
products with limited costs and management overheads. Ethereum's blockchain provides a
safe way to manage user authentication and data, while Swarm helps in optimising
downloading and uploading costs by providing a distributed storage system that is sustained
by a built-in incentive system. On top of that, a special Swarm feature combined with ENS
solves the naming issue and provides a human-readable, decentralised and secure point of
access.
In contrast with traditional social network paradigms, the paper proposes a solution where
continuous content creation is less rewarding than content moderation and filtering
because the emphasis lies on quality and interaction rather than on mere productivity. This
model is perfectly coherent with both use cases we consider, in fact ageing users need to
leverage online presence to enhance their engagement and interactivity with other users,
while SMEs are allowed to follow production plans and manufacturing capabilities instead of
social media rules.
Inside the platform, we have created a moderation mechanism to empower users in
community decisions and a tokenomics based on a reputation score to motivate users in
taking part in community activities. In this regard, the paper underlines the requirement to
move away from coin-based governance to promote a more democratic and fair decisionmaking mechanism.
The results we have obtained with our proof-of-concept implementation are very promising;
nevertheless, creating a production-ready product requires tackling some additional issues.
As the first point, an extensive and accurate analysis of blockchain performances and
related costs is crucial to select the chain that suits our use case best. Testing different
chains and their behaviour could be relevant to future work. As a matter of fact, we are
aware that performances and blockchain transaction fees could become a serious barrier to
the generalised adoption of our system. Consequently, we plan to perform an in-depth
analysis to monitor how the system responds to high traffic volumes as if it were a real-case
scenario. As a further example, the registration process could be improved by implementing
a decentralised identifier to verify digital identities. Also, the reward system could be better
defined: an accurate tuning of the interest rate and the amount of RPs awarded for each
activity are needed. On top of that, we need to propose relevant rewards. For example, we
could use NFTs to allow users to buy a certain slot on the homepage showcase.
Furthermore, a natural expansion of this platform could be the creation of a decentralised
marketplace. In this perspective, it would be even more crucial to explore layer-2 solutions
that could decrease transaction costs.
AUTHOR CONTRIBUTIONS
Tommaso Baldo: Conceptualization; methodology; software; writing—review & editing.
Mauro Migliardi: Conceptualization; methodology; writing—review & editing.
ACKNOWLEDGEMENTS
This research received no external funding.
CONFLICT OF INTEREST STATEMENT
The authors declare no conflicts of interest.
Open Research

DATA AVAILABILITY STATEMENT
No dataset has been used or produced to perform the research described in this paper.
REFERENCES

1 Fu, L., Xie, Y.: The effects of social media use on the health of older adults: an empirical analysis
based on 2017 Chinese general social survey. Healthcare 9, 1143 (2021).
https://doi.org/10.3390/healthcare.9091143
2 Vojíř, S., Kučera, J.: Towards Re-decentralized future of the web: privacy, security and technology
development. Acta Informatica Pragensia 10(3), 349–369 (2021). https://doi.org/10.18267/j.aip.169
3 El Faqir, Y., Arroyo, J., Hassan, S.: An overview of decentralized autonomous organizations on the
blockchain. In: Proceedings of the 16th International Symposium on Open Collaboration (OpenSym ’20),
pp. 1–8. Association for Computing Machinery, New York (2020). Article 11.
https://doi.org/10.1145/3412569.34125
4 European Commission, Directorate-General for Internal Market, Industry, Entrepreneurship and
SMEs, et al. In: K. Hope (ed.) Annual Report on European SMEs 2021/2022: SMEs and Environmental
Sustainability. Publications Office of the European Union (2022).
https://data.europa.eu/doi/10.2826/451263
5 European Commission, Executive Agency for Small and Medium-sized Enterprises, et al. In: K.
Hope (ed.) Annual Report on European SMEs 2020/2021: Digitalisation of SMEs. Publications Office
(2021). https://data.europa.eu/doi/10.2826/56865
6 Migliardi, M., Merlo, A., Passaglia, A.: On the feasibility of moderating a peer-to-peer CDN system:
a proof-of-concept implementation. In: 2015 10th International Conference on P2P, Parallel, Grid,
Cloud and Internet Computing, pp. 689–694 (2015). https://doi.org/10.1109/3PGCIC.2015.53
7 Martini, D.: A Distributed CMS for Small Enterprises Aggregation, Master Thesis. Università degli Studi
di Padova, Italy (2019)
8 Bokang, J., et al.: OPUS: Decentralized Music Distribution Using InterPlanetary File Systems (IPFS)
on the Blockchain. Available online: https://opus.audio/whitepaper.pdf. Accessed 4 November 2022
9 Rumburg, R., et al.: Audius: A Decentralized Protocol for Audio Content. Available online:
https://whitepaper.audius.co/AudiusWhitepaper.pdf. Accessed 4 November 2022
10 Chavan, S., et al.: Music streaming application using blockchain. In: 2019 6th International
Conference on Computing for Sustainable Global Development (INDIACom), pp. 1035–1040. New Delhi
(2019)
11 Steem: An Incentivized, Blockchain-Based, Public Content Platform. Available online:
https://steem.com/SteemWhitePaper.pdf. Accessed 4 November 2022
12 Peepeth. Available online: https://peepeth.com/about. Accessed 4 November 2022
13 Etherna: Eyes Wide Open. Available online: https://etherna.io/. Accessed 4 November 2022
14 D.tube: Turning the Tables in Social Media Industry. Available online:
https://token.d.tube/whitepaper.pdf. Accessed 4 November 2022
15 Tenorio-Fornés, A., et al.: Towards a decentralized process for scientific publication and peer
review using blockchain and ipfs. Proceedings of the Annual Hawaii International Conference on System
Sciences (2019). https://doi.org/10.24251/hicss.2019.560
16 Xu, X., et al.: A decision model for choosing patterns in blockchain-based applications. In: 2021
IEEE 18th International Conference on Software Architecture (ICSA), pp. 47–57 (2021).
https://doi.org/10.1109/ICSA51549.2021.00013
17 Xu, H., et al.: Content sharing network based on IPFS and blockchain. IOP Conf. Ser. Mater. Sci.
Eng. 1043(5), 052014 (2021). https://doi.org/10.1088/1757-899x/1043/5/052014
18 Li, J., et al.: LBRY: a blockchain-based decentralized digital content marketplace. In: 2020 IEEE
International Conference on Decentralized Applications and Infrastructures (DAPPS), pp. 42–51. Oxford
(2020). https://doi.org/10.1109/DAPPS49028.2020.00005
19 Chang, Y.-W., Lin, K.-P., Shen, C.-Y.: Blockchain technology for e-marketplace. In: 2019 IEEE
International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops),
pp. 429–430. Kyoto (2019). https://doi.org/10.1109/PERCOMW.2019.8730733
20 Müller, M., Janczura, J.A., Ruppel, P.: DeCoCo: blockchain-based decentralized compensation of
digital content purchases. In: 2020 2nd Conference on Blockchain Research & Applications for
Innovative Networks and Services (BRAINS), pp. 152–159. France, Paris (2020).
https://doi.org/10.1109/BRAINS49436.2020.9223299
21 Martins, J., et al.: Fostering customer bargaining and E-procurement through a decentralised
marketplace on the blockchain. In: IEEE Transactions on Engineering Management, vol. 69, pp. 810–824
(2022). https://doi.org/10.1109/TEM.2020.3021242
22 Ranganthan, V.P., et al.: A decentralized marketplace application on the Ethereum blockchain.
In: 2018 IEEE 4th International Conference on Collaboration and Internet Computing (CIC), pp. 90–97.
Philadelphia (2018). https://doi.org/10.1109/CIC.2018.00023
23 Shakila, U.K., Sultana, S.: A decentralized marketplace application based on Ethereum smart
contract. In: 2021 24th International Conference on Computer and Information Technology (ICCIT), pp.
1–5. Dhaka (2021). https://doi.org/10.1109/ICCIT54785.2021.9689879
24 Joshi, P., Kumar, A.: A novel framework for decentralized C2C E-commerce using smart contract.
In: 2020 11th International Conference on Computing, Communication and Networking Technologies
(ICCCNT), pp. 1–5. Kharagpur, India (2020). https://doi.org/10.1109/ICCCNT49239.2020.9225377
25 Medury, L., Ghosh, S.: Design and analysis of blockchain-based resale marketplace. In: T. Senjyu,
et al. (eds.) IOT with Smart Systems. Smart Innovation, Systems and Technologies, vol. 251. Springer,
Singapore (2022). https://doi.org/10.1007/978-981-16-3945-6_47
26 Introducing HiDe - an Offline-First Decentralized CMS. Available online:
https://hide.ac/articles/m7l_Ft2li. Accessed 4 November 2022
27 Kuusijärvi, J., et al.: HELIOS: Final System Architecture and API Specification. Available online:
https://cordis.europa.eu/project/id/825585/results. Accessed 4 November 2022
28 Ur Rahman, M., Guidi, B., Baiardi, F.: Blockchain-based access control management for
decentralized online social networks. J. Parallel Distr. Comput. 144, 41–54 (2020).
https://doi.org/10.1016/j.jpdc.2020.05.011
29 Guidi, B., et al.: The contextual Ego network P2P overlay for the next generation social networks.
Mobile Network. Appl. 25(3), 1062–1074 (2020). https://doi.org/10.1007/s11036-020-01525-3
30 Clemente, V., et al.: HELIOS: Define Rewarding Strategies. Available online:
https://cordis.europa.eu/project/id/825585/results. Accessed 4 November 2022
31 Buterin, V.: Moving beyond Coin Voting Governance. Vitalik Buterin’s Website (Blog). Available
online: https://vitalik.ca/general/2021/08/16/voting3.html. Accessed 4 November 2022
32 Tron, V.: The Book of Swarm: storage and communication infrastructure for self-sovereign
digital society back-end stack for the decentralised web. Available online:
https://www.ethswarm.org/The-Book-of-Swarm.pdf. Accessed 5 November 2022
33 Cai, W., et al.: Decentralized applications: the blockchain-empowered software system. In: IEEE
Access, vol. 6, pp. 53019–53033 (2018). https://doi.org/10.1109/ACCESS.2018.2870644
34 Thibault, L.T., Sarry, T., Hafid, A.S.: Blockchain scaling using rollups: a comprehensive survey. In:
IEEE Access, vol. 10, pp. 93039–93054 (2022). https://doi.org/10.1109/ACCESS.2022.3200051
Download PDF
ABOUT THE IET
IET PRIVACY STATEMENT
CONTACT IET
Copyright (2023) The Institution of Engineering and Technology. The Institution of Engineering and Technology is registered
as a Charity in England & Wales (no 211014) and Scotland (no SC038698)
About Wiley Online Library
Privacy Policy
Terms of Use
About Cookies
Manage Cookies
Accessibility
Wiley Research DE&I Statement and Publishing Policies
Help & Support
Contact Us
Training and Support
DMCA & Reporting Piracy
Opportunities
Subscription Agents
Advertisers & Corporate Partners
Connect with Wiley
The Wiley Network
Wiley Press Room
Copyright © 1999-2023 John Wiley & Sons, Inc. All rights reserved