key: cord-0287945-l89okwaw
authors: Cirillo, Albenzio; Dalena, Vito; Mauro, Antonio; Mogavero, Francesco; Pennino, Diego; Pizzonia, Maurizio; Vitaletti, Andrea; Zecchini, Marco
title: Empowering Citizens by a Blockchain-Based Robinson List
date: 2021-10-06
journal: nan
DOI: 10.1080/1206212x.2021.1986245
sha: 0ff12716ab7bbe38e3af6e38bb2de14dff445a4c
doc_id: 287945
cord_uid: l89okwaw

A Robinson list protects phone subscribers against commercial spam calls. Its least basic functionality is to collect the denial of the subscribers to be contacted by market operators. Nowadays, Robinson lists run as centralised services, which implies that citizens should trust third parties for the management of their choices. In this paper, we show a design that allows us to realise a Robinson list as a decentralised service. Our work leverages the experience developed by Fondazione Ugo Bordoni as the manager of the Italian Robinson list. We present a general solution and a proof-of-concept (PoC) adopting the Algorand technology. We evaluate the performances of our PoC in terms of its scalability and of the latency perceived by the involved actors. We also discuss aspects related to identity management and privacy.

User contact information is precious gold to marketing strategists. For this reason, users are now exposed to an unprecedented number of unwanted calls on their phones (spam calls) for marketing purposes, or even to attempts to defraud them by gaining their confidence (scam calls). To better understand the dimension of this problem, we focus on some of the figures reported in [2] that collects statistics from several sources:

• In 2019, roughly 40 percent of all calls in the US were scams.

(Source: First Orion) • Americans lost nearly $19.7 billion from phone scams in 2020 -more than double the amount lost in 2019. (Source: Truecaller) • 44% of Americans received spam calls related to in Q1 of 2020.(Source Truecaller) • The number of spam calls jumped over 300 percent worldwide between 2017 and 2018. One way to tackle the problem of unwanted calls is to block calls on our mobile phone [3] . Call blockers have also been recommended by governments in the recent pandemic emergency regarding COVID19 [4] , to prevent scams or other threats for citizens. However, such apps will often not distinguish legitimate * A preliminary version of this work appeared at CryBlock '20 [1] . † These authors provided a fundamental contribution in the implementation of the PoC survey research calls from telemarketing [5] . Moreover, call blockers are often eluded by spammers, as they usually have a large set of caller IDs to reach the customer, so blocking a single ID is not effective, most of the times. We need a system capable to protect users and, at the same time, to allow marketing operators to reach legitimately a vast audience of informed and aware consumers. Robinson Lists are the standard answer to this need. It is an opt-out list of people who do not wish to receive marketing communications. Nowadays, Robinson lists are centralised services existing in a number of countries, such as UK, Canada, Australia, and Italy, just to mention a few.

The Italian Robinson list is called Registro Pubblico delle Opposizioni (RPO) [6] and it is managed, since 2011, by Fondazione Ugo Bordoni (FUB). Today RPO manages 1.5 millions records, but, with the next introduction, in the near future, of the management of mobile phone numbers, it is expected to be required to handle at least 100 millions records. In the work described by this paper, the experience of FUB was fundamental for the identification of the requirements of a typical Robinson list and of realistic workloads.

Motivations. Nowadays, Robinson lists are managed as centralised services. The purpose of this work is to design and evaluate a decentralised Robinson list on top of blockchain technologies. The main positive effect of this approach is to empower citizens providing them with direct control of their options. Moreover, institutions that operate Robinson lists should aim to reduce their involvement in management of user options as much as possible, in order to lower their risks and costs. Indeed, cryptographic techniques adopted by blockchains natively provide tools that easily solve possible controversy between subscribers and operators. In this perspective, in this work we focus on the most critical and urgent function to decentralise, namely the ability of citizen to autonomously opt-in/out.

Structure of the paper. In this paper, we present a solution for a decentralised Robinson list. We first formally describe requirements on the basis of the experience on the Italian RPO (Section 3). Then, we describe our solution of blockchain-based Robinson list in abstract terms and identify the features that we require from the underlying blockchain technology (Section 4). We recognise that the Algorand technology complies with the identified requirements and base on it our PoC realisation. We describe the architecture of our PoC and some of the most interesting technical details (Section 5). We exploit our PoC to perform an experimental evaluation of our approach that shows results that are comparable with the centralised solution currently deployed for the Italian RPO (Section 6). We also discuss privacy and identity management aspects (Section 7) and future work (Section 8).

Robinson lists are traditionally realised by a centralised authority that is trusted by subjects and operators [7] . The scientific literature regarding systems supporting Robinson lists is very limited. Indeed, the technical aspects of a centralised Robinson list are not particularly challenging.

Blockchain applications for managing user consents have been already considered for other application scenarios (e.g., medical, banking, IoT stream data).

The Dwarna system described in [8] stores research partners' consent for bio-banking process in a blockchain to create an immutable audit trail of research partners' consent changes. The work described in [9] describes the design and implementation of a smart contract for consent-driven data sharing. In this context, service providers can share data about costumers among each other and validate each other's permissions to share it according to costumers' consent. Both works are realised on Hyperledger [10] , a permissioned blockchain solution. The work described in [11] proposes, a user-centric solution that allows data subjects to easily control consents regarding access to their personal data in an IoT ecosystem and exercise their rights in accordance with the GDPR regulation. However, a data subject and a data controller cannot publish their digital consents with the corresponding signatures directly on a blockchain but a centralised platform takes care of this task. In our solution, we aim to let each subscriber managing its own consent, autonomously.

Essentially, Robinson lists allow a subject to associate an attribute (the option) to an identifier (a telephone number). This problem is strictly related to the one faced by identity management systems (IdM). The main purpose of an IdM is to bind an identifier of a subject (usually a public key) with attributes, claims, entitlements, or properties of that subject. IdMs are standardized by ISO [12] and there regulations about them (e.g., eIDAS [13] ). The idea of realising IdM on top of blockchains is a step toward making IdMs independent from a specific organization. The Self-Sovereign Identity (SSI) approach, surveyed here [14] , envisions solutions in which subjects should be able to create and control their own identity, without relying on any centralised authority. In this context, public/permissionless blockchains are fundamental tools. W3C has ongoing efforts to standardize the building blocks of SSI. Decentralised Identifiers (DIDs) [15] are controlled by subjects and possibly securely stored in blockchains. DIDs are linked with DID documents where attributes are listed. Certain attributes are associated to Verifiable Claims/Credentials (VC) [16] which allow the binding between the identifier and the attributes.

In this section, we briefly outline the main actors and functions of the current centralised RPO that we consider as a common accepted practice for a Robinson list. Then, we define the main requirements to support a decentralised Robinson list focusing on the decentralisation of the most critic functions for citizens empowerment and disintermediation.

We model a Robinson list as a collection of records ⟨tel, opt⟩, where is the telephone number of the subscriber and can assume the values , if the subscriber opts-in to receive unsolicited calls on from direct marketing operators, and , vice-versa. The actors interacting with the Robinson list are the following:

Subscribers A subscriber is the owner of one or more telephone numbers and consequently the owner of some records in the Robinson list, where options associated with telephone numbers are recorded. Attestator The attestator is a single actor that is responsible for the creation of the Robinson list, for binding subscribers to their telephone numbers, and for pruning the phone number lists received from operators (as described below). Operators An operator is interested in obtaining the options associated with a list of telephone numbers. Actually, it provides a list of telephone numbers to the organization operating the Robinson list and receives as output a pruned list where the numbers of the subscribers who opted-out have been removed.

Therefore, four fundamental functions must be supported by system realizing a functional Robinson list, which are listed in the first column of Table 1 .

In the current RPO, all these functions are centrally performed by the attestator (i.e., FUB). For opt-in/out and pruning operations, the attestator receives requests from subscribers and marketing operators, respectively, and acts as a trusted intermediary for accessing the Robinson list.

In formally listing the requirements, we primarily focused on fully decentralising opting-in/out operations, giving full control to the subscribers without relying on intermediaries. This guarantees the principle of citizen empowerment that is a motivating argument of our approach. Table 1 summarises our choices regarding decentralisation.

In the current proof-of-concept (described in Section 5), the other functions are left centralised leaving the investigation of their possible decentralisation as future work. This choice is also motivated by the following considerations.

We do believe that it is practical and acceptable that the creation of the assets in the Robinson list is centralised, provided that their management (i.e. opt-in/opt-out choice) is fully decentralised. To the best of our knowledge, centralised certification is the only legal method that is currently accepted by Public Bodies to bind subscribers to their phone numbers. We further discuss this problem and possible approaches in Section 7.

About the decentralisation of the pruning function, we consider it as an important part of our future research work (see Section 8).

The following is a formal list of the requirements of our decentralised Robinson list.

(1) Each subscriber can own any number of records ⟨tel, opt⟩ (for distinct values of tel).

Centralised Attestator Binding of subscribers to phone numbers Centralised Attestator Choice of opt-in/opt-out by subscribers Decentralised Subscriber Pruning lists requested by operators Centralised Attestator Table 1 : Functions and decentralisation choices.

(2) The owner of a record should be able to switch the opt value.

(3) An operator should be able to query the list for the options related to specific values of tel. (4) There should be the possibility to equip the result of a query (or of a pruning operation) with a succinct cryptographic proof, to be shown to anyone, that the result of the query is correct. (5) No single actor (comprising the attestator) or small colluded set of actors, should be able to independently change records belonging to others without the consent of the owner.

It is worth noting that Requirements 1, 2 and 3 are also met by centralised Robinson lists requiring trust in a central authority. Vice versa, Requirements 4 and 5 are normally not met by current centralised approaches.

Requirement 5 naturally lead the design toward a blockchainbased approach. However, a simple solution may not met Requirement 4. Consider for example the trivial solution in which two special addresses IN and OUT are present and the a subscriber opted for IN or OUT by performing a transaction on the respective address. A proof of the choice of a subscriber at a certain time requires to analyse the history of the blockchain back in time, up to the last choice performed by the subscriber. This is not a succinct proof.

Essentially, the problem is that the options are not encoded in the current state of the blockchain. In Section 4, we describe a solution that does encode options in the blockchain state. This make fulfilling of Requirement 4 much easier to implement, especially on technologies that explicitly store the states of the accounts.

Motivated by Requirements 2, 4 and 5, we realise Robinson List on a blockchain technology. There are a large number of different blockchains, showing different trade-offs between supported features and scalability. In devising our solution, we aimed at requiring a blockchain with a set of features that allow us to fulfill the requirements introduced in Section 3, and supporting high scalability, in view of the future management of a large number of records (about 100Mln considering the italian RPO alone). In addition to standard blockchain characteristics, we require the blockchain technology to support the following features:

• The blockchain should support the creation and transfer of custom tokens to represents IN and OUT options made by subscribers. • At each instant in time, the choice of a subscriber is either IN or OUT. As will be clear in the following, we need to atomicly swap a token IN with a token OUT. For this reason the blockchain should support grouping of transactions so that the whole group is either committed or not. • The blockchain should support smart contracts to manage citizen choices by an algorithmic governance. In this paper, we are interested in proving that even stateless smart contracts -the less demanding ones -are enough for our purposes.

Custom tokens are supported on many blockchains, either natively [17] or by using proper smart contracts (see for example [18] ). In our solution, tokens are used to store the current opt-in or opt-out of a subscriber without relying on smart contracts with persistent state.

In section 5, we present our prototype based on the Algorand technology, which provides all these features.

We now describe our solution. Subscribers are identified by one or more public keys and each telephone number is associated to a public key. How this association can be carried out is discussed in Section 7. Private keys are secretly held by the corresponding subscriber. The attestator is also associated with a key pair. The binding between the public key and the telephone number is stored on chain. We decided to encrypt those element so that only the key's owner and the attestator can view the values in clear text. This decision was made to preserve citizen's privacy, by masking the binding of his/her private key to the phone number.

The binding information, namely the pair ( , ), is hidden into the payload of a transaction that the attestator sends to the user. The masking technique consists in the following steps:

(1) the attestator generates , a random 128 bit AES symmetric key and a random 128 bit initialisation vector ; (2) The attestator uses and to encrypt the pair ( , ) by using AES-CBC (Cipher-Block-Chaining) scheme, obtaining ;

is encrypted with user's public key and attestator's public key, producing the values and , respectively (these encryptions are performed using the PyNaCl library [19, 20] and the X25519 elliptic curve [21] ); (4) The triple ⟨ , , ⟩ is written on-chain. Smart contracts are associated with an identifier that, for many aspects, plays the same role of the public key. Hence, for homogeneity, we call it the public key of the smart contract and, when we generically refer to public keys, we intend also to include smart contracts identifiers.

In our solution, we define two custom class of tokens named IN and OUT. We call IN tokens and OUT tokens the individual units of IN and OUT, respectively. In the system, the global number of IN tokens and of OUT tokens is always the same. To streamline description, we refer to IN as the opposite of OUT and vice versa.

Each public key is associated with a wallet that holds tokens. Public keys are used to identify source and destination wallets in transactions involving tokens. In our solution, the tokens are kept in smart contract wallets. For simplicity, we also say that the smart contract contains or stores the tokens.

Each telephone number in the Robinson list is associated with a corresponding smart contract . The system is built to enforce the following option constraint: for each telephone numbers , the wallet contains either only one IN token or only one OUT token. has been designed to avoid the exchange of tokens between subscribers that can lead to the violation of the option constraint. We can express three possible states for each telephone number: opted in, opted out, or no option expressed. The third state is represented by the absence of and in the system. In our approach there exists another smart contract that is in charge of realizing the switch of the token stored in with its opposite, while fulfilling the option constraint. It also stores all tokens that are not currently stored by any contract and that may be needed in future switch operations.

Intuitively, a switch operation is performed as follows. Consider a telephone number with smart contract containing an token (where is either IN or OUT). The switch operation consists of the following two transfers: (1) transfer the token currently in to and (2) transfer an token (where is the opposite of ) from to . The above transfers are asked by the subscriber of as a group to be atomically executed. Smart contracts perform the following checks:

checks that group is signed by the private key of (i.e., it come from the owner of ), checks that the two transfers are consistent with respect to the option constraint. Note that, for security reason, all 's should conform to a template of smart contract in which the only changed part is related to the public key of that the contract use to verify the source of the accepted transactions. We call this the standard template.

We now formally describe the steps involved in the use cases that initialise or change the content of our Robinson list.

To initialise our decentralised Robinson list the following operations are performed.

(1) The attestator generates its public/private key pair.

(2) The attestator creates IN and OUT tokens in a quantity which is supposed to be much larger than the amount of telephone numbers to be managed. (1) The subscriber of creates a new public key and the corresponding private key. It also creates, the corresponding according to the standard template. (2) The subscriber asks the attestator to associate with public key (see Section 7) and to add to the Robinson list. (3) The attestator verifies the association of with (see Section 7) and that conforms to the standard template. If checks are successful, the attestator sends one OUT token to . This represents a default opt-out state for a newly listed telephone number.

Option switching. To switch the option for a telephone number whose smart contract contains an token, the following operations are performed.

(1) The subscriber of prepares two transaction and ′ as follows:

• transfers one unit of from to , and • ′ transfers one unit of from to .

(2) The subscriber bundles and ′ into a group to be atomically executed, signs the whole group with the private key associated with and broadcasts it. 

In this section we present the implementation of a proof-of-concept (PoC) [22] of the decentralised Robinson List solution described in Section 4. The main goal of the PoC is to show how the proposed solution can be implemented on a blockchain technology and to provide a first evaluation on the performance of this implementation.

The PoC has been developed on Algorand [23] because it supports all the necessary features to implemented our solution as discussed in Section 4 and it is one of the solutions claiming to address the blockchain trilemma [24, 25] , thus providing state-of-the-art performance in terms of latency and scalability.

Its inter-block time is very short: about 5 seconds. To support the reader in a better understanding of our PoC, we briefly describe how Algorand implements smart contracts, tokens management and atomically committed transactions.

Algorand Standard Assets (ASA) are standard mechanisms for creating, managing, transferring and destroying digital tokens (or assets). In Algorand, an account should explicitly allow their use to be able to receive them.

Algorand Smart Contracts (ASC) are small programs that serve various functions on the blockchain and operate at layer-1. Smart contracts are separated into two main categories, stateless and stateful. The language for coding ASC is named Transaction Execution Approval Language (TEAL). Stateless ASC can validates and signs transactions and it can be used as a Contract Account. A Contract Account looks like any end-user account except that it validates spending transactions according to its code logic.

Recently, Algorand released stateful ASC that provide local variables. These variables could be used to store the citizens choices thus providing an alternative way of implementing our solution. One contribution of our PoC is to prove that even simple stateless ASC are enough for our goal.

Atomic Transfers are indivisible and irreducible batch operations where a group of transactions are submitted as a unit and all transactions in the batch either pass or fail. In our PoC, Atomic Transfers handled by a suitable ASC are employed to swap an asset for an one without the involvement of any intermediary and vice versa.

Now we formally describe the architecture of our PoC.

There is one attestator and several subscribers, each one with only one telephone number associated with its public key. This association is kept encrypted in the blockchain (see Section 4) and cached in a database by the attestator. In the current implementation, the contract has not been implemented and the IN/OUT token is kept directly in the subscriber account. We recall that the main goal of the PoC is to evaluate feasibility and performance, and the contract, whose main purpose is to achieve a higher level of security, has a very minor impact on that and it will be consequently implemented in future releases. Figure 1 shows a simplified architecture of the system. The whole interaction with the Algorand blockchain back-end is performed by a web application developed with the Django framework.

The attestator set-ups the system generating all the and assets. Then, it deploys the Contract Account and explicitly allow to receive both and tokens. The set-up ends with an asset transfer transaction of all tokens from the attestator to . During the initialisation of the subscriber, the attestator binds the public key of the subscriber to its mobile phone (see Sections 4 and 7). The subscriber explicitly enables reception of and tokens in its wallet, then, if the binding is successful, the attestator transfers one token to the subscriber wallet. For the sake of simplicity, current PoC assumes that binding is always successful. The initialisation is then completed transferring one token from to the subscriber wallet. This is done at the first access of the user into the web interface.

The subscriber can swap the token with an one by executing an Atomic Transfer with . The TEAL code of is designed to approve the atomic transfer only if it consists of two transactions: (a) token from the subscriber's wallet to and (b) token from to the subscriber's wallet. A symmetric atomic transaction lets the user swap the token with the one.

The proposed solution is functionally effective, as it proves that a users can express their choice of being contacted on their personal phone numbers on a distributed and decentralised ledger. Nevertheless, in order to be actually employed, the solution should be comparable to the current centralised one in terms of costs and performance. In fact, while a blockchain solution provides an evident improvement in terms of resilience to network failures or data integrity and traceability, it might suffer of significant issues in terms of scalability, bandwidth, latency and operational costs, in particular in view of a possible public/permissionless deployment.

The purpose of this section is to quantitatively measure to what extent our approach can actually successfully compete with the The environment has been implemented on docker and runs in three containers.

Web. The presentation layer. DB. The identity database (owned by the attestator) that caches the binding between the public keys (i.e., the blockchain addresses) and the telephone number of the subscriber. Algorand-Node. The Algorand node realising a private network.

We evaluated the performance of our prototype in terms of time consumption, investigating the different phases whose subscription process is made of. In the decentralised scenario, the subscription event is composed of 5 different phases:

• Create Wallet -subscriber's wallet, that should contain the OUT or IN token, is created; • Init Wallet -the attestator transfers a minimal amount of coins to the wallet, to enable the subscriber to perform transactions on the blockchain; • Binding -the attestator binds the public key of the subscriber to its mobile phone writing it on the blockchain in an encrypted form (as described in Section 4) and in clear text in the local identity database; • Opt-In ASA -the subscriber explicitly enables reception of and tokens in its wallet; • Transfer ASA -the attestator transfers the token to the subscriber's wallet.

RPO currently manages over 1.5 million of users' fixed phone numbers and, starting from 2021, should be able to support over 100 million of users' phone numbers, as also mobile numbers will be included.

Thanks to the data provided by FUB, responsible for managing RPO's infrastructure, we were able to analyse the history of users' interaction since 2011 (when RPO was initially deployed), in order to obtain aggregated data about subscription rate. A first concern comes from the fact that a public service, like the one offered by RPO, can suffer from peaks of legitimate service requests known as flash crowding attack. This particular event can occur as a consequence of mass announcements (e.g. through TV or journal advertisements), that are usually followed by users concentrating their requests in a very short time interval straight after the announcement, resulting in something very similar to a DDoS attack.

We observed this situation in RPO's history, finding few dates when more than 20000 subscriptions occurred in a day, which is an extremely high number with respect to the ordinary subscription daily rate.

In order to provide a complete analysis of our proposed architecture, we used this particular events as a scalability benchmark.

The histogram of the subscriptions, namely the insert operation of a new phone user on a centralised database, during a flash crowding day (in 2011) is represented in figure 2 .

We observed a total of 25566 subscriptions in a day, grouped into two intervals in the day. The gathering of subscriptions in two intervals of the day (one at night time and the other around noon) confirmed us that the insert on database operations were executed in batch scripts.

Analysing our log in peak periods we calculate that the average time for the insert operation is about 200 .

We decided to use standalone accounts rather than wallets to overtake the operational cost of creating a wallet. A standalone account is an Algorand address and private key pair that is not stored on disk. A user can invoke, on his/her premises, the algo-sdk to generate a pair of public and private keys. The time cost for generating an account is significantly reduced. With reference to the benchmark, we evaluated the time consumption for registering 20'000 users: In this way we reached 3.6 subscriptions per second, 20'000 users subscription completed in 00:09:10.709 average time for a single subscription 00:00:00.267 dev std time for a single subscription 00:00:00.106 Table 2 : Time consumption for registering 20'000 users which is a comparable rate with the one observed during flash crowding events.

Currently, the main service offered by the current centralised RPO consists in filtering a list of telephone numbers provided by a marketing operator, in order to return them the same list but without the opted-out subscribers. This operation is also known as pruning.

We performed a pruning test operation on a list of 10'000 mobile phone numbers. Indeed, 10'000 numbers is the mean amount of phone numbers for which the telemarketing operators request the pruning activity to RPO. Our decentralised RPO can operate the filtering process in two different modes:

• by looking on chain for the opt status associated with a specific public key bound to a phone number; • by enquiring a private database that acts as a cache for the binding information on chain, similarly to what happens in the current centralised implementation. The former solution is preferable because it would prevent RPO to maintain a private database with sensitive information, lowering the risks in case of malicious attacks. Nevertheless, as the binding between the public key and the phone number has been encrypted on the chain, and considering that the phone number is the only input to the filtering process, the first solution would also require to exhaustively look into the whole blockchain, decrypting the binding transactions, till finding the desired phone number and associated public key, which is evidently more expensive than performing a search over a private indexed database.

The difference in cost between the two methods has been evaluated by comparing 3 different pruning tests, producing the following results: As expected, the pruning operation performed without a Iteration Blockchain only Cache DB 1 1'59" 14" 2 1'54" 16" 3 1'58" 16" Table 3 : Pruning Blockchain only and Cache DB cache DB, which means using only on chain data, requires a higher time effort. Considering as the total number of blocks and the number of mobile phones to be pruned, in the worst case the cost of search is ( * ), assuming >> . This result suggests for further investigations in order to foster the usage of on chain data in real world processes and not only for notarization purposes, while preserving security and privacy aspects.

We investigated the storage requirements for archival nodes in a private Algorand blockchain, as the volume of traffic and the dimension of the transactions can vary significantly with respect to the main public network. In our test, we measured the amount of disk space occupied on 5 different archival nodes when increasing the number of subscribers to the decentralised robinson list. Results are shown in figure 3. All nodes occupy the same amount of space when increasing the number of subscribers to the service, except for the Primary Node (circle dots) which acts as a relay node and needs to store log activities. Giving this linear dependence among number of suscribers and disk occupation, we can estimate the dimension for an archival node that should be able to support a desired number of subscribers: in our case, we estimated the need for 1650 for a node that should contain 100 million of subscribers. On top of that estimate, a blockchain designer should consider the estimate number of transactions that could be performed, so to define a solid configuration for the archival node.

Unfortunately, this considerations are not sufficient to dimension an archival node on a private blockchain. Indeed, the blockchain itself generates empty blocks whenever there are no transactions to be committed. This is typical for all the blockchains and is needed to ensure integrity and security. On a public blockchain it is unlikely to observe empty blocks, however, in private blockchain dedicated to specific regional services (which might be our case), idle times might be common, especially at night.

In this section, we analyze the economic costs of our approach, focusing on our PoC realization.

The following are the main costs a subject has to sustain in the proposed decentralised solution:

• Each subscriber needs to possess a minimum amount of Algos to participate to the network. In our PoC, the attestator supports this cost transferring to each subscriber these Algos. • A subscriber opts-in to trade both IN and OUT tokens, issuing two transactions. • The attestator transfers 1 OUT token to each subscriber.

• Every time a subscriber wants to change state, it publishes an atomic transfer composed by two transactions to swap the two different tokens. The first transaction is in charge of the subscriber, the second one is paid by . The balance of is monitored by the attestator that refills it with Algos, when necessary.

In Algorand, each transaction costs 0.001 Algos. Moreover, each account must maintain a minimum balance to be considered active (i.e. use an account in transactions) and an additional balance is needed to trade ASAs (i.e. use an account in transactions involving the ASA). The minimum balance required to activate an account is 0.1 Algos [26] and the one to trade a token is 0.1 Algos [17] per ASA. Since, in our scenario, each subscriber trades two ASAs, the overall minimum balance is 0.3 Algos.

Considering the current 1.5M RPO subscribers, the attestator pays 450000 Algos for the minimum balance of the subscribers, 1500

Algos to transfer it and 1500 Algos to distribute the OUT tokens. Hence, the attestator pays 453000 Algos.

Each subscriber pays 0.002 Algos to publish the transaction opting-in the IN and OUT tokens. Swapping the ASA costs 0.002 Algos in total. Hence, the subscriber pays 0.003 Algos.

The cost of the initialisation phase is relevant with respect to all other costs. Supposing to use the public Algorand main network, at the current quotation of the Algo cryptocurrency, the cost of initialising the system for 1.5M subscribers is about 500k€. While this may seems very high, it is substantially less than the current annual costs paid by market operators to use RPO. In fact, on average, RPO filters about 400 million of numbers each year. As by May 2021, operators pay, for each filtered number, from 0.004€ to 0.025€, depending on the subscribed bundle. Hence, market operators collectively pays annually more than 1.6M€, which are supposed to cover just operational costs, since RPO is a not-for-profit service. One aspect to consider in this discussion is that our approach does not fully substitute the current centralised realization, hence, some of the costs of the current solution are supposed to exists also in our approach, like identity verification costs. However, we think that this simple analysis is enough to say that in case of realization on the public blockchain costs are still comparable with the current centralised approach.

As already observed, the main contribution of this paper is the decentralisation of the opt-in/opt-out choice. Subscribers choices are personal data that have to comply with privacy regulation, like for example the GDPR [27] . Decoupling the data from the personal identity (pseudonymization) is a widely used approach for this kind of compliance. In the previous sections, we deliberately avoided to introduce any in-chain information that can help to associate choices to related telephone numbers or subscribers. From this point of view, the solution we have described so far is not affected by privacy concerns. However, in practice, operators do need to know both telephone numbers and choices. In this case, regulations require that operators can have knowledge of that binding, but no other subject should be able to get it.

Creating and storing bindings between telephone numbers and public keys are essentially identity management problems [12] . The simplest approach to them is to delegate both verification of this binding and the management of the corresponding database to a trusted third party. For example, the identity database could be managed by the same attestator introduced in Section 4 (and this is the choice in our PoC). When a subscriber asks to add to the Robinson list a telephone number , with public key , should check the binding and store it in its identity database. For example, can ask the subscriber to sign a random challenge using the private key paired with , where is communicated to by making use of (e.g., by SMS or by voice call). In pruning operations, operators should ask to obtain either or directly the current choices for .

Our solution, with this identity management approach, might be deemed acceptable and regarded as a substantial improvement with respect to current practices. The obvious next step is to ditch any involvement of from regular operation of the Robinson list.

In the just described scenario, performs three tasks that we would like to decentralise.

(1) It checks bindings of telephone numbers to public keys.

(2) It stores them into a private identity management database.

(3) It replies to operators queries.

Task 2 is easy to decentralise, since the identity pairs ⟨ , ⟩ can easily be stored in clear text into the blockchain. However, this would be a clear privacy violation, since blockchain is supposed to be accessible to a multitude of subjects. If we accept to keep Task 3 centralised, then the identity pairs can be encrypted so that only and the owner of can decrypt them, as described in Section 4. A scheme that allows operators to access identity pairs autonomously, while respecting privacy regulation, is more challenging to devise. This is especially true if we admit operators to be granted or denied access, dynamically. By the way, this also introduces the problem of who is authorized to grant or deny access to operators or if this should be performed in a decentralised manner, as well. We intend to develop these aspects in the future. Regarding Task 1, the work in [28] describes two blockchainbased approaches to perform this kind of checks in a decentralised fashion. It relies on a randomly selected committee of participants to the blockchain that is different for each check and it is hard to predict in advance. Each member performs the check autonomously and then write in the blockchain its "proof" about the binding. A summary of the proofs can then be computed at the consensus level and written on-chain as a regular identity pair. Again, while this approach looks promising, privacy aspects are yet to be developed.

In this paper, we show the technical feasibility of a decentralised Robinson list and the adequacy of the performances of our approach. Our solution enables citizens to express their choice in complete independence while costs, even in case of adoption of a public blockchain, are comparable with costs of current centralised RPO. The validity of our approach was also recognized in public competitions 1 . Concerning future works, we plan to investigate a completely decentralised solution (including both pruning and binding) where we see two main challenges: conformity to privacy regulation and automatic management of fees, where citizens may possibly be rewarded for accepting marketing calls.

Decentralized robinson list

35+ phone spam statistics for 2017

Federal Communications Commissionstop unwanted robocalls and texts

ROK Ministry of Economy and Financeflattening the curve on covid-19

American Association for Public Opinion Research. Spam flagging and call blocking and its impact on survey research

Robinson lists for efficient direct marketing

Dwarna: a blockchain solution for dynamic consent in biobanking

Double-blind consent-driven data sharing on blockchain

Hyperledger fabric: a distributed operating system for permissioned blockchains

Advocate: a consent management platform for personal data processing in the iot using blockchain technology

Iso/iec 24760:2019 it security and privacy -a framework for identity management

European Union. eIDAS -Electronic Identification

A survey on essential components of a self-sovereign identity

W3C Decentralized Identifiers (DIDs) v1.0

Algorand Official Documentation, exploring features: Assets

Measuring ethereum-based ERC20 token networks

Cryptography in nacl. Networking and Cryptography library

Elliptic Curves for Security

Algorand: The first pure proof of stake blockchain platform

Ethereum wiki project. On sharding blockchains

Scaling blockchains without giving up decentralization and security: A solution to the blockchain scalability trilemma

Algorand Official Documentation, exploring features: Accounts

The eu general data protection regulation (gdpr). A Practical Guide

Binding of endpoints to identifiers by on-chain proofs