Sustainable open access publishing using Blockchain, Interledger and Web Monetization

Sustainable Open Access Publishing using Blockchain, Interledger and Web Monetization Publicación de acceso abierto sostenible mediante Blockchain, Interledger y monetización web By Elena Pérez Tirador Departmento de Ingeniería del Software e Inteligencia Artificial Universidad Complutense de Madrid Trabajo Fin de Grado del Doble Grado en Ingeniería Informática y Matemáticas, Facultad de Informática, Universidad Complutense de Madrid. 2020/2021 Directors: Antonio A. Sánchez Ruiz-Granados Ámbar Tenorio Fronés iii Abstract One of the main problems the academic community faces is the high prices of publishing and accessing academic papers. Authors and reviewers usually work for free or even pay for their work to be published, while the revenue generated goes to the big publishers. This project is centered around studying the technologies that would be best suited for the creation of a system or platform for donations to journals and researchers. Various centralized and decentralized technologies have been studied. Regarding centralized technologies, PayPal has been the main focus, and regarding decentralized technologies, Blockchain,Interledger and Web Monetization have been studied. Their advantages and limitations have been analyzed, as well as their different integration possibilities. These technologies have been used to implement a system that allows donations by different centralized and decentralized means. The donations can be sent between any two centralized or decentralized currencies. The system’s main feature is a donation button that can be integrated in any journal’s web page. JavaScript and React were used for the front-end implementation. This connects with the underlying subsystems that manage the different types of payments. To test the possibilities of the decentralized technologies, a new ERC20 token was implemented and integrated in the system. It was concluded that centralized technologies are easier to use for implementation, better documented and more intuitive for the user. However, PayPal, for example, imposes certain barriers and limitations that block the developers’ work. Decentralized technologies, on the other hand, are newer, so they have less documentation and are a bit more cumbersome to use. But they have proven to be way more flexible and adaptable and easier to integrate with. So, despite their limitations, they have potential to become an important part of online donations and payments in the future. Keywords: Academic community, Blockchain, decentralization, donations, Interledger, PayPal, online payments, Web Monetization v Resumen Uno de los principales problemas que afronta la comunidad académica son los altos precios para publicar artículos y acceder a ellos. Habitualmente los autores y revisores trabajan gratis, o incluso tienen que pagar para poder publicar su trabajo, mientras que son los grandes editores quienes reciben los beneficios generados. Este proyecto se centra en el estudio de tecnologías que puedan resultar adecuadas para la creación de un sistema o plataforma para donaciones a revistas académicas e investigadores. Se han estudiado diversas tecnologías centralizadas y descentralizadas. Entre las centralizadas, PayPal ha sido la principal, y entre las descentralizadas, se han estudiado Blockchain,Interledger yWeb Monetization. Se han analizado sus ventajas y limitaciones, así como sus diferentes posibilidades de integración. Estas tecnologías han sido utilizadas para implementar un sistema que permite realizar donaciones por vías centralizadas y descentralizadas. Las donaciones pueden realizarse entre cualesquiera dos divisas diferentes, ya sean centralizadas o descentralizadas. El elemento principal del sistema es un botón de donación que puede integrarse en la página web de cualquier revista. Para la implementación del front-end se utilizaron JavaScript y React. Esto se conecta con el subsistema subyacente que se encarga de los diferentes tipos de pagos. Para probar las posibilidades de estas tecnologías descentralizadas, se ha implementado un nuevo token ERC20 y se ha integrado en el sistema. Se comprobó que las tecnologías centralizadas son más fáciles de usar en implementación, están mejor documentadas y son más intuitivas para el usuario. Sin embargo, PayPal, por ejemplo, impone ciertas barreras y limitaciones que pueden bloquear el trabajo de los desarrolladores. Las tecnologías descentralizadas, por contra, son más nuevas, por lo que disponen de menos documentación y son algo más engorrosas de utilizar. No obstante, han demostrado ser más flexibles, adaptables e integrables. De modo que, a pesar de sus limitaciones, tiene el potencial de convertirse en una parte importante de los sistemas de pagos ydonaciones en el futuro. Keywords: Blockchain, comunidad académica, descentralización, donaciones, Interledger, PayPal, pagos online, Web Monetization vii Acknowledgements After a long while, this project is coming to an end. This year has undoubtedly been one of the weirdest up to this day for everyone. Therefore, I would like to thank everyone that made this project possible, despite the weird conditions we all are in. So thanks to: •Antonio Sánchez and Ámbar Tenorio, for directing and supervising this project. •Grant for the Web and the Interledger Foundation for financing it. •The Quartz OA team, for making the Quartz project a reality. •My family, for all the invaluable support. •My friends, for helping me keep my sanity in this difficult year. Thank you very much. ix Contents Abstract iii Resumen v Acknowledgements vii 1 Introduction 1 1.1 Objectives .................................. 2 1.2 Planning ................................... 2 1.3 Structure of this document ......................... 3 1.4 Source code ................................. 3 2 Web donations and platforms 5 2.1 Introduction ................................. 5 2.2 Analysis and categories ........................... 5 2.2.1 Categories .............................. 6 2.2.2 Analysis and score ......................... 6 2.3 Wikipedia .................................. 6 2.4 PayPal .................................... 7 2.4.1 API ................................. 7 2.4.2 Marketplaces and platforms .................... 8 2.5 Centralized donation platforms ...................... 8 2.5.1 Ko-fi ................................. 9 2.5.2 Flattr ................................ 10 2.5.3 Plaudit ............................... 11 2.6 Decentralized donation platforms ..................... 12 2.6.1 Giveth ................................ 12 2.6.2 Helperbit .............................. 13 2.6.3 GiveTrack .............................. 14 2.7 Conclusions ................................. 15 3 Technologies for a distributed donation platform 17 3.1 Blockchain .................................. 17 3.1.1 Blockchain ............................. 17 Basic concepts ........................... 17 3.2 Ethereum and ERC20 tokens ....................... 18 3.2.1 Ethereum .............................. 18 3.2.2 ERC20 tokens ............................ 18 3.3 Interledger Protocol ............................ 18 3.3.1 Definitions ............................. 19 3.4 Web Monetization ............................. 19 3.5 Some wallets and applications ....................... 20 xvii List of Abbreviations API Application Programming Interface CTA Call ToAction ERC Ethereum Request for Comments GDPR General Data Protection Regulation HTML HyperText Markup Language IDE Integrated Development Environment ILP InterLedger Protocol IPFS InterPlanetary File System JSON JavaScript Object Notation MVP Minimum Viable Product ORCID Open Researcher and Contributor ID QTZ Quartz Token REST Representational State Transfer URL Uniform Resource Locator WM Web Monetization xix To my family 1 Chapter 1 Introduction Scientific production is a very demanding and dedicated job, as well as an immensely necessary one. But this kind of work, in most cases, is not paid or compensated in any way [38]. Most authors, editors and reviewers work for free (or almost for free), and at the same time have to pay huge amounts of money to access the scientific contents published in most journals [3,51]. The main reason for this is that academic and scientific publishing is primarily controlled by a reduced group of big publishers (such as Elsevier, Springer Nature or Wiley) [33]. Although the majority of the work involved in this complex process is carried out by the academics, taking the role of authors, reviewers, editors, etc. most of the benefits generated by this market go to these big publishers [32]. These benefits often come from the high prices researchers need to pay to access the content [5]. There is an option for the authors to publish their articles in Open Access, so whoever wants to access the content can do it for free, for it is open. However, in exchange for this, researchers have to pay very expensive prices [60]. It is not uncommon that, for these reasons, academics feel frustrated, since they can feel like their work is not properly recognised and compensated. And also for some, publishing in Open Access is not an option, because they can not afford the high prices [23]. The problem with the academic publishing rises from the centralization of its more powerful actors (the big publishers). For this reason, it is interesting to study decentralized solutions to try and tackle these kind of problems. Nonetheless, it is known that these technologies are still not very accessible for most people because of their sometimes cumbersome usability [1], so it is also necessary to combine these decentralized technologies with some centralized solutions to make adaptation easier. Another matter that is also worth exploring is the rewards for the academic community [40]. These rewards could materialize in different forms, whether they be monetary or not [65]. For these reason it is also interesting to explore the possibilities that cryptocurrencies or tokens bring to this context. In this context, several initiatives to help improve the situation of the academic community begin to appear [18]. One such initiatives is Decentralized Science1[57,55], a project aiming to provide an open community of reviewers, open peer reviews and a reputation network, providing rewards for the peer reviewing work. As a natural continuation of Decentralized Science, and thanks to the funding received from Grant 1https://decentralized.science/ 2Chapter 1. Introduction For The Web2, the Quartz OA3project is born, aiming to create a community of academics and journals that enables donations in a distributed way. By bringing these additional sources of capital, they strive to make Open Access fairer, more sustainable and independent [34]. This TFG is part of the Quartz OA project, in collaboration with the ISIA department of the Facultad de Informática at UCM 4. 1.1 Objectives The goal of this project is to create a system (the Quartz system) to facilitate donations to journals and authors, in order to reward their work. Specifically, the project is centered in exploring what centralized and decentralized technologies can be used for this purpose, and find out their strengths and weaknesses, while using them to create the system. In the case of decentralized technologies, the Interledger Protocol [56] will be studied, exploring its applicability and limitations in order to introduce it into the system. Interledger proves to be interesting, as it is a new technology that allows intercommunication among ledgers (both centralized and decentralized). This means exchanges between any two coins or payment systems are possible. In particular, this project will explore how new payment systems can be integrated into this system to enable different kinds of payments. The concept of microdonations will also be explored, as a way to allow users visiting websites to pay based on the time they spend in them. In terms of development, the goal is to create a donation button that can be integrated in the web page of a journal, allowing the visitors to perform donations in different ways: •Via a centralized payment system, such as PayPal. •Via a decentralized payment system, using any currency. In particular, a specific coin created for donations to journals. •Via microdonations, using a browser extension. 1.2 Planning The development of this project took place between September 2020 and May 2021. This document was written in the following months. The first four months of the project were centered in studying the problem, analyzing the possible solution and developing the first centralized solution. This is, a button allowing centralized donations. The next four months of the project were centered in exploring the decentralized possibilities, essentially Interledger and Web Monetization (both will be explained in detail in the next chapters of this document), and developing the decentralized solution. This is, adding the button the possibility to perform donations via Interledger and integrating with Web Monetization so that the user can send micropayments while visiting the journal’s website. 2https://www.grantfortheweb.org/ 3https://quartz.to/ 4https://www.ucm.es/disia 1.3. Structure of this document 3 The rest of the time was dedicated to polish the application and write this document. In terms of methodology, scrum [8] was applied, implementing two-week sprints. Every other Thursday, a meeting was held with the directors of the project to review the work of the previous two weeks and decide the steps to be taken in the next sprint. For the final phase of polishing and writing the document, the sprints were changed to one-week sprints. 1.3 Structure of this document This document explains the development process of the app, along with initial considerations and final results. Chapter 2introduces the current context in which the project is developed. It explains the importance of donations for open software projects, mentioning Wikipedia as a well known example. It also introduces PayPal as a technology for online payments and gives various examples of donation platforms, both using centralized and decentralized currencies. Chapter 3explores the technologies that enable the creation of a distributed donation platform. It introduces the Interledger Protocol and Web Monetization as two new technologies that can be used for this purpose. It also gives some examples of applications using these technologies. Chapter 4gives an overview of the implemented system from the user’s perspective, explaining the actors that will interact with it and the main functionalities it provides. The workflow is explained in detail, illustrated by screenshots of the system. Chapter 5explains the implementation of the centralized part of the system. It first gives some implementation details about PayPal and its API and then shows and explains the architecture of the system, as well as its flow of interactions (through sequence diagrams). Chapter 6explains the implementation of the decentralized part of the system. It first gives implementation details about Interledger and the architecture of an Interledger network. Secondly, it does the same for Web Monetization. It then explains the integration of new coins in this architecture and finally describes the architecture, implementations details and flow of interactions of the implemented system. Chapter 7analyzes the conclusions that can be extracted from the project, regarding its initial objectives, and then proposes the next steps that can be taken to further develop and improve the system and the project. 1.4 Source code The project has been developed using JavaScript, HTML, CSS and Solidity. The source code for the project, along with some deployment instructions can be found in the following GitHub repository: https://github.com/ElenaPT/TFG_Inf_2021 The project is licensed under a GNU General Public License v3.0. 5 Chapter 2 Web donations and platforms This chapter studies how web donations are working nowadays. First, an introduction is given illustrating the importance of donations in open source projects, and why they are so necessary. Then, Wikipedia is introduced as an example of a well known project that is financed using donations. After that, PayPal is briefly described as a tool for enabling donations and payments through the web, since it is the most commonly used technology for this purpose. Lastly, some donation platforms and similar projects are listed and analyzed in terms of their usability. 2.1 Introduction Nowadays, open source projects are very common and serve as a basis to both open and non open source software development [54]. However, most of the time the work in open source is not well recognized, and financing this sort of projects can be challenging [11]. Although multiple funding models exist in the context of open source creation, donations through platforms such as PayPal or Patreon are one of the most common practices [45]. Open software development is usually a voluntary work, and there are different opinions on whether or not to accept monetary rewards [58]. Participating in the development of open source software can start from both an intrinsic motivation (the development itself is motivating, for it is interesting or challenging) or an extrinsic motivation (academic rewords fall in this category) [29]. The importance of donations relies on their voluntary nature, for an obligation or coercion to finance the developers would defy the philosophy behind open software itself [52]. From the perspective of the donor, the will to donate can come from different reasons. It could just be an altruistic decision, but some other factors can be in play, such as private gains derived from the software being developed in the end, or some kind of recognition or prestige [31]. We think Open Access publication is not that different from Open Source development in these aspects, so this same reasoning can be applied [64]. 2.2 Analysis and categories The following sections of this chapter will study existing applications and technologies that are similar to the one being developed (under the name of Quartz or QuartzOA). 12 Chapter 2. Web donations and platforms Figure 2.3: A verified project’s profile page in Giveth 2.6 Decentralized donation platforms This section centers on the analysis of systems designed to allow the user to make donations using cryptocurrencies and blockchain. Namely: Giveth,Helperbit and Givetrack. 2.6.1 Giveth Giveth [21] is a platform that allows the user to make donations to social good projects without commissions or other secondary charges, by using the blockchain technology. They describe themselves as a “Decentralized Altruistic Community”. The website harbors a collection of pages, one for each project inside the community. Inside each page, there is information about the project and their goals, a section for updates and a summary of the donations, showing the total amount donated to the project and a list of the donors ordered from most recent to least recent. A project’s page can be seen in Figure 2.3. As for now, the donations can only be done using cryptocurrencies (DAI, YAY, UNI or ETH). A payment by credit card is being implemented, but is not working yet. Regarding the categories defined in Section 2.2.1, the following can be concluded: •Accessibility: (5/5) Inside the website, the donation button can be easily found in the home page. There is a “Projects” page that is easy to find in the top menu. From there the donation button for each project is also easy to find and clear to use. The login button and the one for creating a project are also very visible in the home page. •Interest: (4/5) The website is attractive and uses inspiring illustrations and language. The “Projects” page makes it interesting to discover new projects. The fact that all the projects featured are for social good helps the user identify with the values. It expects the user to be interested in cryptocurrencies and their use (the donations can only be made using cryptocurrencies). •Usability: (2/5) The donation button is big and clear. However, the fact that the donations can only be performed using cryptocurrencies makes the process a little cumbersome, especially for people not very familiarized with the field. The process for logging-in and creating a project seems to not be working well. 2.6. Decentralized donation platforms 13 Figure 2.4: Helperbit main page •Dialogue: (4/5) The exchange of information between the page and the user is agile. •Effectiveness: (3/5) The platform is not very popular yet, although it has a decent number of users. It has a limited niche, because it requires prior knowledge and usage of the technology. However, inside its niche it is the most popular technology for donations. 2.6.2 Helperbit Helperbit [53] is a platforms that allows the user to make donations to charities using cryptocurrencies, so the charities can receive the money in a safe way. The website harbors a collection of pages, one for each charity inside the community. In the page, the charity can display information about what they do and some related media, such as photos or videos, that can illustrate their labor. The page also shows the income goal of the organization and the quantity that has already been donated. There is a subsection where a list of the donors is displayed. The main page of the website can be seen in Figure 2.4. The donations can be done using different cryptocurrencies, via Metamask3[37] or from the Helperbit account of the user. Regarding the categories defined in Section 2.2.1, the following can be concluded: •Accessibility: (5/5) The main page of the website shows the different charities that are registered in the community and can receive donations. The button for donating to a charity is very clear and easy to find. The login button is also easy to find in the top menu. •Interest: (4/5) The interface is not the most attractive one, but it is sufficiently clear. The main page showing the organizations by categories (latest projects, trending projects...) makes it easy to discover the collectives. The fact that the page is for donating to charities makes it easy for the user to identify with the values, which are clear and relatable. 3Metamask is a browser extension for managing crypto wallets and operating with cryptocurrencies. 14 Chapter 2. Web donations and platforms Figure 2.5: Profile page of a project in GiveTrack. The project has already reached its milestone. •Usability: (3/5) The donation button is very clear and it stands out. The donations can be done using cryptocurrencies or through the account created in the website. •Dialogue: (3/5) The exchange of information between the page and the user is agile, although a bit scarce in some situations. •Effectiveness: (2/5) There is a decent number of charities inside the community, but it does not seem like the initiative is very well known. Most of the charities are quite far from their income goals. Also, it seems that the webpage will close because the company running it could not sustain itself economically. So apparently things did not work out well. Apparently the project will disappear by the end of may 2021, and the page explains how the charities can do to withdraw their funds. 2.6.3 GiveTrack GiveTrack [22] is a platform that allows the user to make donations to non-profit organizations and NGOs using the blockchain technology to provide real-time tracking of the funds. The project is developed by the BitGive Foundation [4]. The website harbors a collection of pages, one for each nonprofit organization inside the community. In the page, the organization can display an overview of their project and goals. The page also shows the fund milestones of the organization and the quantity that has already been donated. An organization’s page can be seen in figure 2.5. The donations can be done using different cryptocurrencies or using a credit card. Regarding the categories defined in Section 2.2.1, the following can be concluded: •Accessibility: (5/5) Inside the website, in the home page, the button “Explore projects” is the main call to action and can also be found in the top menu. The donation button inside each project is also very easy to find and stands out. The login and sign up buttons are also visible and accessible in the top right. •Interest: (5/5) The page is very clean and attractive and uses inspiring language. The “Explore” page makes it interesting to discover the different initiatives. 2.7. Conclusions 15 The fact that the projects are nonprofit and NGOs makes it easy for the user to identify with the values. •Usability: (5/5) The donation button is very clear and the bar showing how much money is left to reach the milestone encourages the user to donate. The payment can be done using Bitcoin, credit card or via Uphold [59], which supports a lot of different currencies. The variety of options makes if quite easy to donate. The user is required to have an account in GiveTrack in order to donate. Creating an account is easy. The process for creating a project is straightforward. It requires government approval, because it is meant for recognized organizations. •Dialogue: (5/5) The exchange of information between the page and the user is agile. •Effectiveness: (4/5) There is a decent amount of organizations and a good percentage of them are reaching their milestones. 2.7 Conclusions Each of the platforms that were studied in this Chapter were analyzed following the categories described in Section 2.2.1. During this analysis, for each of the categories in each of the applications, a subjective numeric score was given. The score ranges from 0 to 5, where 0 means that (according to a subjective criteria) the category is not fulfilled at all by the application and a 5 means it is perfectly fulfilled. For certain categories, several applications may cover them, to an extent. However, the score for a certain category for a certain application will be lower if there are others that fulfill said category more successfully. These numeric scores serve as a quantitative measure of how adequate each platform is, in terms of its interaction with the user. It is useful for the development of the Quartz platform, since it serves as a guide to which practices give the best results, in order to make the user experience more pleasant. Table 2.1 shows the scores for each category in each one of the analyzed platforms. Table 2.1: Comparison of the different platforms studied Wikipedia is also included in the table, although it is not a donation platform. In its case, the analysis is made regarding only Wikipedia’s functionality for donations. At first glance, this analysis may give the impression that there already exist a lot of alternatives for the Quartz system. However, this is not the case. None of the studied applications cover the intended scope for one or several reasons. Platforms such as Ko-fi, Flattr, Giveth or GiveTrack are well built and usable and already have a decent base of users. However, they are all intended for different 16 Chapter 2. Web donations and platforms targets. Ko-fi and Flattr are targeted for artists and creators, Giveth is targeted for social good projects and GiveTrack is targeted for NGOs and non profit organizations. Furthermore, Ko-fi and Flattr only offer centralized solutions for the payments, while Giveth only offers decentralized ones. Plaudit’s target, on the other hand, is the academic community. Nonetheless, it is not focused on donations but on recognition and endorsements. Moreover, it is quite cumbersome and not easy to use. Helperbit does not only have a different target, but is also closed for the time being. Quartz proposes a solution that has not been covered yet by any of these platforms. It offers a donation platform for users to donate to academic journals and articles. For the payments, it allows both centralized and decentralized payments. From the analysis it is clear that offering only decentralized options for the payments makes the applications less usable and effective. Most users are not familiar with this new technologies. For this reason, offering also centralized options seems like the optimal choice. The analysis has also showed that it is essential for the donation button to be easy to find and it should stand out. It is also important that the interactions with the user are clear and the exchange of information is agile. An attractive design is also important. All these ideas will be taken into consideration when designing the system. 17 Chapter 3 Technologies for a distributed donation platform The previous chapter, Chapter 2, was centered on the donation platforms and applications that populate the market, an how they are structured, whereas this chapter explores some decentralized technologies that can be used to create a new kind of decentralized donation platform. 3.1 Blockchain Most decentralized technologies and systems rely on the blockchain technology as a basis. Therefore, giving a brief introduction to blockchain is key for giving context to the rest of technologies this chapter will explain. 3.1.1 Blockchain Blockchain is a decentralized technology based on a data structure with the same name. The data structure, as the name itself indicates, is a chain of blocks [42]. The system was first introduced with the creation of Bitcoin [39]. It served as a basis for the creation of an electronic payment based on cryptographic proof, so that two parties or entities would be able to send money to each other without having to trust a central entity. The system is proven to be secure as long as the majority of the nodes involved in the system are independent and honest, so they control more CPU power than any hypothetical group of attackers or dishonest participants. Basic concepts Atransaction is defined as an exchange of money between two participants. This is, a sender, a receiver and a quantity. Ablock is a set of transactions. It is connected to the previous block and to the next one, thus forming a chain. A new block is added to the chain once enough transactions have happened. The block also contains a timestamp and a link to the previous block (or parent), in the form of a hash of said block. It also contains a random number, called nonce. This number is important for the calculations of the block’s hash when the next block is added to the chain. The blockchain represents a complete register or ledger of the full history of transactions in the system, since for every new group of transactions, a block is added to the 18 Chapter 3. Technologies for a distributed donation platform end of the chain. By cryptographic means, blocks can be validated as truthful part of the chain. The immutability of the blocks is guaranteed by the hashes. If any data within the block (any information about any of the transactions) is modified, the hash of this new modified block will be completely different to the previous one. 3.2 Ethereum and ERC20 tokens 3.2.1 Ethereum Ethereum [7] is a decentralized blockchain, and one of the main networks as for today. As bitcoin or other systems, it includes a coin, and mechanisms for performing transactions and payments. But the main interest of the Ethereum blockchain is the fact that it can run code, in the form of so called smart contracts . Asmart contract is a piece of code that can be executed in the Ethereum blockchain, autonomously. The language in which smart contracts are written in is Solidity [7]. The advantage of smart contracts is that, since they run over a blockchain, the trust in the contract relies in itself, rather that in a third party that warranties the compliance of the contract [43]. For this reason, it is completely impartial and everybody can trust it will be executed. Whatever rules are written in the contract will be executed and complied without a doubt. 3.2.2 ERC20 tokens An ERC20 [15]token is a smart contract running over the Ethereum blockchain containing code for the definition of a token or coin. This includes operations such as creating an initial amount of tokens, sending money between accounts or checking the balance of an account. ERC20 is the standard that determines the functions and events this sort of contracts should implement. The goal behind the creation of the ERC20 tokens is the standardization and compatibility among tokens in the Ethereum network, in order to facilitate interoperability and create a richer ecosystem. OpenZeppelin [44] is a standard for building secure blockchain applications. They provide a library for secure development and deployment of smart contracts. Among the contracts contained in this library, there are contracts for the deployment of ERC20 and ERC721 tokens. 3.3 Interledger Protocol The Interledger Protocol (or ILP, for short) can be used in order to implement a system that provides both the donor and the receiver the freedom to choose their preferred currency or cryptocurrency, without having to worry about how the transactions will be performed. 3.4. Web Monetization 19 3.3.1 Definitions Interledger [56] is a protocol for sending and receiving payments between systems that maintain a register of financial transactions. Being a protocol means it is a set of rules that are publicly accessible. Before understanding the idea behind Interledger, it is necessary to introduce two main concepts: •Ledger: An archive or book storing economic transactions, columns for credit and debit, initial and final balance for an account. In other words, an account book. •Decentralized Ledger Technology: Digitized and decentralized ledger. This is, decentralized database managed by several participants, without a central authority for verification. So, in this sense, Interledger can be understood as a technology for interconnecting different decentralized ledgers. But this is a simplification. Interledger can be defined as a system that allows communication among different payment systems, in order to perform a transaction of a certain value. The systems communicated by this protocol can (but do not need to) be decentralized ledgers. Ideally, any two payment systems (or ledgers), centralized or decentralized, can be connected via Interledger. In a more technical sense, Interledger is an open protocol suite for the shipment of payments among different ledgers [27]. In analogy to internet routers, the connectors route money packages through independent payment networks. Since the architecture and the protocol are open, interoperability is allowed for any system. The actors that participate in the system are [26]: •Sender: The actor that sends the money. •Receiver: The actor that receives the money. •Connector: In case the sender and the receiver are not using the same paying system, they need intermediaries to connect them. So this is the role of the connectors: they forward money through the network from the sender all the way to the receiver. They may charge fees for the work. It is expected that the different connectors in the network compete among themselves in terms of velocity, reliability, coverage and price. Any of these participants of the Interledger network is called a node. The architecture of the Interledger network and how these nodes work together is further explained in chapter 6. 3.4 Web Monetization Web Monetization [61] is an API that allows websites to request payments in small quantities via the browser and the Web Monetization provider. AWeb Monetization provider or Web Monetization sender is a digital entity that can issue payments in behalf of a user and, in particular, send micropayments to Web Monetization receivers [63] through ILP. In a similar way, a Web Monetization receiver is a digital entity that can accept payments performed via Interledger in behalf of a user and, in particular, receive micropayments through Web Monetization. 20 Chapter 3. Technologies for a distributed donation platform The Web Monetization receiver provides the user with a so called payment pointer, which is a URL assigned to a certain Interledger account. This URL is unique and, therefore, serves as an identifier of the account. The idea behind Web Monetization is for the user running a website to embed its payment pointer in the website itself. As long as the users visiting the site have an application that allows them to send the micropayments (such as Coil - see Section 3.5.3), they will start sending little amounts of money to the payment pointer defined in the source code of the page. The concept of micropayments is simple: small amounts of money sent every certain time. This is, for every unit of time (e.g. every hour or every thirty minutes), a small amount of money (e.g. a cent, two cents) is sent from the user visiting the page to the payment pointer registered in the code. 3.5 Some wallets and applications In order to send or receive payments using ILP or Web Monetization it is necessary to use an ILP wallet. In the case of Web Monetization, some wallet providers can work as WM senders or receivers. This section describes three applications that host ILP wallets: Rafiki.money,Uphold and Coil. Both Rafiki.Money and Uphold can be used as standalone wallets and as Web Monetization receivers. In turn, Coil works as a Web Monetization provider. 3.5.1 Rafiki.money Rafiki.money [47,25] is an example Interledger wallet prototype developed by Interledger themselves. It allows the user to have an account with real money or test money using a testnet, and send and receive money. It is not a donation tool. Similarly to Uphold (3.5.2), Rafiki provides the user with a payment pointer that can be used to receive donations (for example, the donations issued by Coil (3.5.3)). It is not a real finished product, but a prototype for testing and experimenting. The repository itself indicates the project must not be used in production. 3.5.2 Uphold Uphold [59] is a web exchange for buying and selling digital coins and cryptocurrencies. It allows the user to have an account with any type of coin and use it to issue and receive payments, as well as for buying and selling coins. It is not a donation tool. But if a user wants to receive micropayments, for example, the ones that Coil issues, they must have a payment pointer to receive them. A payment pointer is the address of a wallet within a node of an ILP network [10]. Uphold provides the user with a payment pointer, so they can receive the donations. 3.5.3 Coil Coil [9] is a browser extension and tool for micropayment streaming to web pages and creators. 3.6. Other technologies 21 A user can pay a subscription fee and download the extension. With the extension installed and active, every time the user visits a site that is webmonetized (i.e. supports Web Monetization) [61], Coil starts sending small amounts of money depending on the time the user expends in said page. In particular, Coil pays $0.36 for every hour a user expends on a page. The micropayments are sent roughly every second for each visiting member. The main interest of this initiative is the fact that it is currency-agnostic. This means the user that makes the donations can be using any type of currency - being it any physical currency or a cryptocurrency. The receiver of the donations can also receive them in whichever currency they decide. Both currencies do not have to be the same, nor related whatsoever. Coil is built over Web Monetization, which is the technology that manages the micropayments. It works as a Web Monetization Provider. 3.6 Other technologies There are other technologies that have been used during the development of the project. The technologies explained in this Section are not the core of the project, but have been necessary for the implementation nonetheless. 3.6.1 Docker Docker [12] is an open source software project that provides a system of software containers, in which the developers can deploy several applications to virtualize networks and systems. In the context of this project, Docker is used to simulate a simple Interledger network. This network is explained in detail in Chapter 6(see 6.2.2). Docker containers are used to simulate an Ethereum testnet and three different Intereldger nodes, and then they are interconnected to simulate the whole three-node ILP network. 3.6.2 Node.js Node.js [41] is a JavaScript runtime environment designed to create scalable network applications. It is open source and cross-platform. It is oriented to asynchronous events and it is used to write scripts for the server side in a client-server web application. In the context of the project, Node.js is used to implement the servers to which the client connects in order to ask for the monetary transactions to be made. 3.6.3 React (javaScript) React [48] is a JavaScript framework designed to help creating user interfaces. It facilitates the inclusion of HTML code within the JavaScript code, and it provides some other advantages, such as lambda expressions. In the context of the project, it was used to implement the user interface and the client of the application. 28 Chapter 4. System overview Figure 4.3: Quartz button integrated in a journal’s web page By interacting with the button, the application opens a new dialogue, where the user can select the amount of money to donate and decide the way in which they want to perform the payment (Figure 4.4): •Paypal •Debit or credit card •Interledger The first two options open a PayPal popup window, where the user can perform the payment. The third option opens a dialog asking the user to write in their credentials for the Interledger account (see Figure 4.5). For the proof of concept purpose of this project, all the operations are performed over predefined accounts in a test network, so for now this is still a placeholder dialog. If the payment is performed correctly, the application shows a dialogue confirming everything worked properly and giving the user the option to visit the Quartz website6 and join the community. If there is any error during the process, the application shows a dialogue stating there has been an error (Figure 4.6). There is also the Web Monetization payments, that are micropayments sent to the journal for each time unit a reader expends in the page. This process is a little different, so it will be explained in the next section (Section 4.5.2). 4.5.2 Donor: Indirect donation (micropayments) One of the ways the donor can donate to the journal is via microdonatinos. In the case of the journal, the process for integrating the system into their web page is the same that was already explained in Section 4.5.3. When the button is integrated in the page, it makes the proper changes so that the website becomes webmonetized and can start receiving microdonations. In the case of the donor, the process is different to the one explained in the previous section. 6https://quartz.to/ 4.5. Donations 29 Figure 4.4: Payment dialogue First, it is required that the user has a Coil account (see 4.3.2). Then, they have to download the Coil browser extension. This extension is the one that allows the user to send microdonations to the webs they visit. In the Coil account, they have to select a configure a membership. This is, a monthly fee that is payed to Coil and then redistributed among the webmonetized websites the user visits. Once the membership is configured and the extension is downloaded, the donor just has to log in to Coil and then, whenever they visit a webmonetized website - the journal’s website, in this instance - the extension will indicate that it is sending money and the micropayments will be performed. Coil will pay $0.36 for each hour the donor expends in the journal’s website. Figure 4.7 shows the browser extension before logging in and after logging in, when visiting a website that is webmonetized. Figure 4.8 shows the extension in context, in a website that has Web Monetization enabled. 4.5.3 Journals The use case for the journals is the same for both implicit and explicit donations. 30 Chapter 4. System overview Figure 4.5: Interledger payment screen The user representing the journal could be a journal editor or the person in charge of the journal’s web page. Their goal is to integrate the system in their page and start receiving donations. In order to integrate the full system, they need to have one or more accounts in the various technologies used (although if they prefer to use only one of them, the code can be easily adjusted). This means the journal needs to have a PayPal account, and use this account to register in the Quartz PayPal platform. This is needed for the PayPal and credit card payments. The journal also has to create an account in an Interledger node, that could be the Quartz Interledger node. This way they obtain a payment pointer, that is used as an address to send them the money. Once all the accounts are created, the button can be integrated in the web page7, as shown in Figure 4.3. When the donations are made by users visiting the website and interacting with the buttons, the journal receive the money in the corresponding account. The money sent via the PayPal buttons (PayPal, Sofort, and credit and debit card) is received in the Journal’s PayPal account. The balance can be checked in their PayPal profile. The payments received via Interledger are received in the journal’s Interledger wallet. This wallet could be in any node providing payment pointers. 7The button is implemented in React (JavaScript, HTML) and it can be integrated by inserting the button’s code in the code of the website. 4.5. Donations 31 (a) Success dialogue (b) Error dialogue Figure 4.6: Success and error dialogues (a) Coil extension before logging in. (b) Coil extension while visiting a webmonetized site. Figure 4.7: Success and error dialogues 32 Chapter 4. System overview Figure 4.8: Using the Coil extension in a webmonetized website. 33 Chapter 5 Centralized Implementation In this chapter, details about the centralized implementation of the system are given. First, the core concepts of a PayPal application are introduced, as well as the different functionalities, components and APIs. Then, the architecture of the system is explained, followed by a detailed description of the implementation. The centralized implementation is relatively simple, since all the management of the transactions is delegated to PayPal, who provides a high-level API. For this reason, the implementation of the centralized subsystem consists mainly in the integration with said API. 5.1 Introduction Chapter 4introduced the Quartz ecosystem, in terms of its external structure and how the user interacts with the different functionalities. This chapter will study the centralized part of said ecosystem, by explaining how it is implemented. The main component of this subsystem is the donation button, and the underlying payment system uses PayPal’s infrastructure to send the payments. The user can choose to make the payments using a PayPal account or by credit card, but the differences between both channels are made transparent for both the user and the developer thanks to the simplicity of PayPal’s API. For this reason, in order to explain how this subsystem is implemented, it is helpful to understand the technology that is used for the implementation. This is the PayPal REST API for marketplaces and platforms. The implementation of the centralized donations consists in an integration of Quartz’s UI with the functionalities PayPal provides. 5.2 PayPal For the creation of the first version of the system, a centralized approach was taken and PayPal was used to allow payments and donations in a centralized way. PayPal was chosen for its interoperability and the functionalities it provides for the creation of marketplaces and platforms. In brief, a platform can onboard a set of sellers to be part of the marketplace and then it can manage how the money is forwarded to said sellers. 34 Chapter 5. Centralized Implementation PayPal offers a REST API to perform the different operations for the development. The REST API requests are executed combining an HTTP method, such as GET, POST, PUT, PATCH or DELETE, the URL to the API service, the URI of the resource to be updated, deleted or queried and optional HTTP headers. PayPal provides the developer with credentials to make the API calls, and the authorization is performed using the OAuth 2.0 protocol. These credentials consist of a client-id and a secret. 5.2.1 Concepts There are a few concepts that will be used throughout this chapter and are particular to the PayPal API that has been used for the development of the centralized subsystem. Some of those concepts are the following: •Platform/marketplace. A structure used for organizing a group of vendors (in this case, the journals) so that the payments made by the buyers (in this case, the donors) can be easily managed. It will be explained in more detail in Section 5.2.2. •Client-id and secret key. These are credentials that identify a particular PayPal App. A user with a PayPal developer account can create apps that provide them with credentials to access the REST API for both testing and live transactions [35]. The client-id is the identifier and the secret key is the password. These credentials vary for each app and are also different for live and sandbox apps. •Access token. It is an identifier or key that authorizes the user to use the PayPal REST API server [20]. It can be obtained by using the client-id and the secret key. •Attribution-id. This key identifies the user as a PayPal partner. PayPal partners are developers that are allowed by PayPal to use all the functionalities the PayPal REST API provides. This attribution-id is received directly from PayPal and has to be used as an identifier every time a call to the API is made [2]. 5.2.2 Platforms and marketplaces PayPal offers an API for marketplaces and platforms. A platform, as previously explained in Section 2.4.2, acts as an intermediate entity between the donor and the journal. A journal that wants to participate in a platform should, first, have a PayPal business account. Next, by making calls to the PayPal API, using the Authorization token and the Attribution ID, it is possible to generate an onboarding link, which is specific for the platform. Onboarding is the process by which a journal, in this instance, integrates into a platform, so the platform can manage payments donors send to the journal. By using said link, any journal can onboard. Figure 5.1 shows a simplified diagram of the structure of a platform. 5.3 Architecture The architecture of the system has several layers (as illustrated in Figure 5.2). The user interface is common to both the centralized and decentralized part of the system, 5.3. Architecture 35 Figure 5.1: Quartz Platform and then each of the subsystems has its own lower layers, in both cases based on a server-client model. In this section, the centralized part will be analyzed. As the Figure shows, the most external layer is the UI (user interface). It is the layer that allows the communication between the user and the application. This layer was implemented using React JS and following the directives of material design. In particular, the library material-ui for React was used. This layer connects with the clients for both the centralized and the decentralized subsystems. In the case of the centralized system, the client receives the data inputs that the user enters via the UI and makes the POST requests to the server. The client is also implemented using React JS. The server makes calls to the PayPal API using the information received from the client. The code for the server is implemented using the Express framework [13] for JavaScript and it runs on Node.js. Thereby, these underlying client and server layers follow a theoretical structure, instead of a physical one. In particular, they follow the client-server architectural pattern [49]. As such, the Centralized System Client Controller works as an intermediate layer between the Client UI and the Server, by parsing the data received from the UI and forwarding the subsequent petitions to the server. The Server, on the other hand, manages the petitions and makes the necessary calls to the corresponding API (PayPal API, in this instance). It is important to note that, for this is a theoretical structure, both the client and the server can be running in the same machine. The codes for both layers run independently, but there is no need for them to exist in separate machines. This is the case in the current deployment where, for the sake of facilitating testing, both structures are running in the same machine. However, the current implementation also allows for deployment in different machines. This separation would be ideal, since some of 36 Chapter 5. Centralized Implementation Figure 5.2: Architecture of the system. Highlighted the centralized part. the data being managed by the application is sensitive information, and it is safer to process such data in an independent server. It is also important to note that the Client Controller and Server for the centralized implementation are different from the ones for the decentralized implementation. The source code is different and independent, and they both run and work without any dependence from one another. The PayPal API is the access layer through which the PayPal functionalities are accessed. The PayPal system is the deepest layer of the system, and it is the one in charge of managing the shipment of the money. With this general knowledge of the architecture, it is now possible to explain in detail the sequence of calls among the different layers of the system. 5.3.1 Sequence diagram The PayPal donation button generated for the sellers works following a server-client structure. The server listens to petitions regarding the orders and makes the API requests. The client reads and manages the options of the user’s order (in this case, a donation) and forwards the necessary information to the server to perform the calls. Figure 5.3 shows a sequence diagram illustrating the flow for a transaction through the PayPal donation button. This applies for both payments using a PayPal account or a credit card. The flow for a payment would be as follows: •The user sets the quantity they want to donate and press the “Pay” button. •The client sends a create-order petition containing the quantity to be donated. •The server listens to the petition and makes a call to the PayPal API. The access token and attribution ID of the platform are sent with the call, to authenticate the platform and assure it has the necessary permissions. 5.4. Conclusions 37 User UI Client Server PayPal API Insert(amount) Press(PAY) Pay create-order(amount) order(access token, attrib. ID) Ok (JSON) Ok capture-order order(orderID, access token, attrib. ID) Success Success Print success screen Show success screen Figure 5.3: Sequence diagram for the PayPal donation button •Through the API, PayPal does the corresponding operations to create the order, and returns a JSON containing either an error, if there is any, or some information about the operation. •The client receives the response and prints in the prompt the error or the data received. Among this data, there is an order ID, identifying the order just created. •If there is no error, the client sends a capture-order petition. •The server listens to the petition and makes a call to the PayPal API. The access token and attribution ID of the platform are sent with the call, along with the order ID, that identifies the order. •Through the API, PayPal does the corresponding operations to perform the order and returns whether there is an error or it has been a success. •The server returns a state of success if everything worked properly or one of error if something went wrong. •The client receives the response and fixes the system’s state to either success or error, so the front-end knows which screen to show the user. •The front-end prints the corresponding screen: a success screen if everything worked properly and an error screen if something went wrong. 5.4 Conclusions The implementation of a centralized solution was the first approach of the project. It is an interesting approach, since centralized payments are most common nowadays in the context of online donations and payments in general. For this reason, they do not pose a big challenge for the users to overcome, since they are already used to this kind of systems (unlike newer or more innovative payment systems, where adaptation could be harder). Another reason for this approach to be taken first was the fact that there is plenty of information, documentation and support for the development of systems that use these technologies (such as PayPal), for they are very popular and have a big user and 44 Chapter 6. Decentralized Implementation Figure 6.5: Web Monetization scheme The website specifies in a meta tag in its html code that it will allow Web Monetization payments and the payment pointer that will receive said payments. This payment pointer points to the web’s wallet, which is provided by a Web Monetization receiver. This receiver is an entity that can receive Interledger payments in behalf of the user. In this particular case, the Interledger payments are sent using Web Monetization. This receiver is connected to the ILP network, so it is capable of receiving payments sent by any other entity in the network. On the other side of the transaction is the user that visits the page. The user does so from a certain browser that has a browser extension installed which allows to send Web Monetization payments. This browser extension in connected to the user’s wallet, which is provided by a Web Monetizaiton sender or provider. This sender is an entity that can send Interledger payments in behalf of the user. In this particular case, the Interledger payments are sent using Web Monetization. As the receiver, this sender is also connected to the ILP network, so it is capable of sending payments to any other entity in the network. When the user enters a website that is webmonetized, the browser, through the browser extension, identifies the meta tag that indicates that the website can receive Web Monetization payments and reads the payment pointer to which the payments need to be sent. The extension uses this information to make the WM sender issue a payment to that payment pointer. 6.3.1 Flow This process of sending Web Monetization payments can be better understood by studying the flow of the process step by step. Figure 6.6 shows a sequence diagram of 6.4. QTZ: An ERC20 token 45 Figure 6.6: Sequence diagram of a payment using Web Monetization[62] a payment sent using Web Monetization. It is assumed that the website has Web Monetization enabled. The flow for the payment is as follows [62]: •The browser parses the code of the web page looking for the meta tag and, if it exists, for the payment pointer to where the money needs to be sent. •The browser calculates the appropriate amount to send to the website per unit of time. •In order to keep the anonymity of the user visiting the website, the browser generates a unique session ID for that specific session. •To also keep the visited sites anonymous, the browser also gets a unique destination address for the website’s payment pointer, as well as a shared secret for the session. •Optionally, a payment receipt verifier can generate receipt of the operation. •While the website is still in focus, the browser begins sending payments to the website (at the rate calculated at the beginning). •The Web Monetization provider sends the money to the receiver via Interledger. •Optionally, the receiver can generate a receipt and send it to the provider. •The Web Monetization provider notifies the website the payment was sent successfully. •The browser sends an event to the website, indicating the payment was successful. •Optionally, the web page can send the receipt to the receipt verifier to confirm the payment. 6.4 QTZ: An ERC20 token Interledger can provide connections to perform payments from any currency or payment system to any other one in existence, as long as they are correctly connected to the network. In this context, an ERC20 Quartz token was implemented (ERC20 46 Chapter 6. Decentralized Implementation tokens are defined in a previous chapter, in Section 3.2.2. The advantages and uses of the Quartz Token are also explained in a previous chapter, in Section 4.1.5). In order to be able to either make donations using the token so that the receiver receives another currency or vice-versa, the token has to be made compatible with the Interledger network. For the scope of this project, tests were made in a simple Interledger network, the one described in Section 6.2.2. Since this new Quartz coin (QTZ) is an ERC20 token, and ERC20 is a token standard, the process here described for including QTZ in an Interledger network can be trivially adapted to any other ERC20 token. Also, being QTZ an ERC20 token, it is deployed over an Ethereum network. For this reason, it is possible to adapt the scheme described in Section 6.2.2 to fit this new coin. Ethereum settlement engines can be used to settle between nodes using QTZ. The first step for integrating the token is creating and deploying the contracts of the token itself. The code has been adapted from the OpenZeppelin contracts [44]. In the configuration of the contracts it is necessary to fix the host to the IP of the Ethereum network where the token should be deployed. In the case of these tests, an Ethereum testnet. Then, the contracts are compiled and deployed to the network. Once this is done, the token will exist within the Ethereum network, being therefore possible to perform transactions using it within said network. The next step is configuring the Ethereum settlement engines, so they are able to settle using the correct token. This is achieved by setting the token address of the settlement engine to the one of the token just deployed. This is, indicating the settlement engine that, from all of the tokens that may exist in the Ethereum network, QTZ is the one that it has to use for the settlements. In order for QTZ to be exchanged for other currencies or tokens, the exchange rates have to be fixed. In the example network used in Section 6.2.2, the connector that exchanged ETH for XRP (and vice-versa) consulted the exchange rates from the exchange platform Coinbase2. This is not extensible for the new token, for none of these exchange platforms know its value. However, the rates can be set manually for the Interledger network using the Interledger API. In the test network of the project, only QTZ and XRP are used, so only those two rates have to be fixed. When creating the accounts inside the Interledger nodes, the asset each account uses must be set. In this case, Alice will be using QTZ instead of ETH, as she was using in the previous test network. Finally, the payments can be performed. To perform a payment from Alice (in QTZ) to Charlie (in XRP), it is only necessary to indicate the quantity, Charlie’s payment pointer and Alice’s password. The precise process used for creating a token, deploying it and integrating it with the ILP network is explained in detail in Appendix A. It contains all the commands and steps necessary to recreate the network and the exchange. 6.5 Implementation details Now that the decentralized technologies (Interledger and Web Monetization) have been properly explained, the implementation itself can be described in detail. 2https://www.coinbase.com/es/ 6.5. Implementation details 47 Figure 6.7: Architecture of the system. Highlighted in green is the decentralized part. This section will explain the architecture of the decentralized system of the Quartz application, its flow and some other implementation details that are key for understanding the full implementation. 6.5.1 Architecture The Interledger architecture (see 6.2.2) is a core part of the project, for the application is built over it and integrated with it. Nonetheless, the application has more layers, in order to allow a simple interaction between the user and the underlying system. Figure 6.7 shows the different layer of the system. Highlighted in green are the ones corresponding to the decentralized subsystem. As explained in Section 5.3, the user interface is common to both the centralized and the decentralized part of the system, and each of the subsystems has its own lower layers, in both cases based on a serverclient model. In this section, the decentralized part will be analyzed. As the figure shows, the most external layer is the UI (user interface), which is is the layer that manages the interaction between the user and the application. It is the exact same layer that was used in the centralized case, and it is implemented using React JS and material-ui. This layer connects with the clients for both the centralized and the decentralized subsystems. In the case of the decentralized subsystem, the client receives the data inputs that the user enters via the UI and makes a GET request to the server, indicating the necessary data for the transaction. This code is also implemented using React JS. The server makes calls to the Interledger API by sending POST requests, using the information received form the client. The code for the server is implemented using JavaScript and it runs on Node.js. 48 Chapter 6. Decentralized Implementation Figure 6.8: Overview of the decentralized subsystem. The Interledger API is the access layer through which the functionalities of the ILP network are accessed. The Interledger system is the deepest layer of the system, and it is the one in charge of managing the shipment of the money, as well as the balance checks and other operations. 6.5.2 Implementation In the context of the project, a test network was deployed to implement this architecture. The test network (which is a variation of the one described in section 6.2.2) simulates a small but complete Interledger network with a node that transacts using the QTZ token. Figure 6.8 shows an overview of the entire decentralized subsystem, including the test network. To simulate this test network locally, Docker (see Section 3.6.1) was used. Docker can be used to create a network locally by simulating several interconnected machines. Each machine will run a different service or application, thus creating a simulated Interledger network that can be run locally. The detailed process and code for creating such network is explained in detail in Appendix A. The appendix shows the process in a low-level manner. Now this section will elaborate on the process at a high level. First, a docker network is created. It will be referred as local-ilp from now on. Then, several docker containers are deployed, each one serving a different purpose. A docker container contains Redis, which is a database for the settlement engines and 6.5. Implementation details 49 the nodes, that will later be deployed. This database can be accessed by the services deployed in the rest of the containers. Another docker contains an Ethereum testnet, that in this instance is initiated with a predefined seed, so that the public and private keys of the accounts are the same every time the network is redeployed. This is not necessary, but it simplifies the implementation and testing process. Then, the QTZ token is implemented and deployed in this Ethereum network that has been created in a docker container. This way, the token can be accessed from the different nodes that are connected to this network. It is important to take into account that the token’s contract has a certain address associated to it once it is deployed in the network. This address will be important later, when the nodes that use the coin are created. The next step is deploying the nodes and their corresponding settlement engines. As explained in previous sections, settlement engines are entities that allow two interconnected nodes to settle with one another, this is, make an irrevocable exchange of funds between the two. Three nodes are created. This text will refer to the nodes with the same names that were used for the deployment shown in Appendix A: Alice, Bob and Charlie. These names are used for simplicity, and represent the nodes as described in Figure 6.2 3. First, Alice’s node is created. Alice’s node only operates with QTZ. Therefore, two docker containers have to be deployed: one for the node itself and one for the Ethereum settlement engine (for the QTZ token runs over an Ethereum network). In order to deploy the Ethereum settlement engine, it is necessary to tell the docker container to work inside the local-ilp network. Inside the container, the service corresponding to the Ethereum settlement engine is deployed and some important parameters are passed to the service, such as: •The URL of the Ethereum testnet. •The address of the QTZ token. •The URL of the corresponding node (indicating the port to which the settlement engine will connect to). In this case, the URL for Alice’s node and the corresponding port. •The number of decimal positions the token is represented with. Among others. Then, Alice’s node is deployed. In this case, the container runs a service meant for ilp nodes, and several parameters are passed to the service, such as: •The ILP address of the node. •A password for the node. •The port through which it connects with the settlement engine. Among others. The procedure for Bob’s and Charlie’s nodes is similar. In the case of Charlie’s node, it is a node that only operates with XRP (Ripple), so the settlement engine that has to be initiated is an XRP settlemet engine (it is different than the Ethereum one). 3When compared with Figure 6.8,Alice corresponds to Quartz node;Bob corresponds to Connector node and Charlie corresponds to Receiver node. 50 Chapter 6. Decentralized Implementation Bob’s node, on the other hand, is a connector that operates with both QTZ and XRP, so it has to be able to settle with both currencies. Therefore, two settlement engines have to be deployed for Bob: one for Ethereum and one for XRP. Note that the settlement engines depend on the network, not the currency. For this reason, there is not an specific QTZ settlement engine, but an Ethereum one. Charlie’s and Bob’s nodes are then created in a similar way Alice’s node was. For all this nodes and settlement engines, it is important to specify a fixed ip, that has to be different for each one of them. It is also important to indicate, for every one of them, that the docker network they work in is local-ilp. Finally, the different accounts are created within the nodes. These accounts are the ones that allow the nodes to communicate with one another, send the packets and, eventually, make the economic exchanges. Alice will be the node that issues the payment, Charlie the one that receives it and Bob will act as a connector between the two to make the currency exchange. This way, it is necessary to create in Alice’s and Bob’s nodes the respective sender and receiver accounts. This way, an Alice account will be created in Alice’s node and a Charlie account will be created in Charlies node. Now, in order for a node to be able to communicate with another one, it has to have an account inside the node it wants to communicate with. This accounts is not a usual account for storing funds, but its goal is to allow communication between the nodes. This way, a Bob account is created in Alice’s node; an Alice and a Charlie account are created in Bob’s node and a Bob account is created in Charlie’s node. This is, in addition to the Alice account in Alice’s node and the Charlie account in Charlie’s node. With this general knowledge of the architecture, it is now possible to explain in detail the sequence of calls among the different layers of the system. 6.5.3 Flow The application follows a simple client-server structure: The client reads and manages the options for the user’s donation and sends the server the necessary information to operate. The server listens to petitions regarding the payments and performs the API calls. It works in a similar way to what was built for the PayPal payments, but instead of calling PayPal to perform the payments, the ILP process is called in its place. Figure 6.9 contains a sequence diagram illustrating the architecture. The flow for a payment would be as follows: •The user sets the quantity they want to donate and press the “Pay” button. •The user is then asked to authenticate using its Interledger credentials (these being account and password). And there is also an option to choose the node in which the user has the account. For the purpose of the project, users are supposed to have an account in Quartz’s node. •The client sends a petition for a payment, containing the user, the receiver’s payment pointer and the amount as parameters and the password as a header. The password is sent as a header instead of a parameter for security reasons. 6.5. Implementation details 51 User UI Client Server API Interledger Insert(amount) Press(PAY) Show authentication form Insert(credentials) Press(OK) Pay Pay(pointer, acc, amount) POST(Payment) Send amount from sender to receiver Fulfilled OK Status 200 Print success screen Show success screen Figure 6.9: Sequence diagram for the Interledger payment button •The server listens to the petition and makes a call - in the form of a POST petition - to the Interledger’s API. The parameters and headers received from the client are used for this call. •In case of an error, the server returns the headers and the type of errors, and prints them in the command-line. •In case of success, it returns a status code of 200, which means everything worked correctly. •The client receives the response and fixes the system state to success or error. This way, the front-end (or UI) can show the corresponding screen: error or success screen. 6.5.4 Web Monetization The system also integrates with Web Monetization. The architecture for Web Monetization payments is explained in detail in Section 6.3. This integration is done in two parts: First of all, when the Quartz button is included in the web page of a journal, it automatically modifies the code of the head of the website to include the meta tag. This way, it enables Web Monetization payments in the website. Moreover, there is a second layer to the integration, in terms of the Interledger network. The way this works is that the Quartz node in the ILP network can serve as a Web Monetization receiver or a Web Monetization provider. For example, by specifying in the meta tag of the website a payment pointer provided by the Quartz node -this is, a payment pointer to an account that exists within the Quartz node -, the website, in this case the journal, can receive micropayments in QTZ. 53 Chapter 7 Conclusions and Future Work Regarding all the previous work explained in prior chapters, conclusions are given and some suggestions are laid out to be carried out in the future. 7.1 Conclusions This project was aimed to exploring how donations to journals and authors can be implemented in a practical way, and how decentralization can be applied to the task. In particular, exploring the Interledger Protocol as a technology to achieve these goals. The tangible outcome of this project has been a functioning web app that provides functionality for sending donations by different means. As exposed in the Objectives (see 1.1), these means are: •Via a centralized payment system (PayPal was used). •Via a decentralized payment system, using any currency, including a specific coin created for donations to journals (Interledger was used). •Via microdonations, using a browser extension (Web Monetization was used) In this sense, the development goals were achieved. A more intangible outcome, yet a main one, has been the study of different technologies and the design of an architecture for integrating both centralized and decentralized payment systems in a single application. Both approaches have advantages and drawbacks, but one interesting result of this work is that it is possible to implement a fully decentralized solution that allows to use different types of currencies and tokens. The next subsections will provide detail about all these aspects. 7.1.1 Functionality and integration From a practical point of view, the goal of the project was developing an applications that provides the functionalities previously described, by integrating with the different used technologies. At a functional level, a button has been developed. This button can integrate within the web pages of the journals and provides them with the three main functionalities: •With regard to the centralized payments, a button is presented that allows the user to make payments via PayPal, using a PayPal account or a credit card. •With regard to the decentralized payments, a button is presented that allows the user to make payments via Interledger using the user’s Interledger wallet. 60 Appendix A. Run a local ILP testnet using the Quartz token docker run -d \ --name ethereum-testnet \ --network local-ilp \ --ip 192.168.128.2 \ trufflesuite/ganache-cli \ -m "abstract vacuum mammal awkward pudding scene penalty \ purchase dinner depart evoke puzzle" \ -i 1 A.2.3 Create the token The code for the Quartz token is available inside the repository for the TFG. If you download the code from the repository, this section is not needed, and you should skip to the next one, section A.2.4. If you have not downloaded the repository, then follow the instructions in this section to create the contracts for the token. The token must be deployed in the local ethereum testnet (that is running inside the container ethereum-testnet). In the command line, do the following: mkdir mytoken && cd mytoken npm init -y npm i --save-dev @openzeppelin/contracts npm i truffle -g npx truffle init The truffle-config.js file must be modified adding a new network inside networks. This new network will be called docker and will be as follows: module.exports = { networks: { docker: { host: "192.168.128.2", port: 8545, network_id: "*" // Match any network id } } }; Where host is the ip of the Ethereum network that we are using (in this case, the testnet ethereum-testnet). Create a new contract inheriting from ERC20 and implementing the new token. Once that is done, write a script for the deployment of the contract and add it to the /migrations folder (in this instance, this will be for deploying the Quartz token). In this deployment script, the necessary parameters to initialize the contract must be A.2. Process 61 provided (in this case, the amount of tokens that will be minted when the contract is deployed). In truffle-config.js, change the compiler version to 0.6.12. Keep an eye in the Solidity versions. The source files currently work for Solidity versions >=0.6.0 <0.8.0, but this could possibly change. A.2.4 Deploy the token If the code for the token was downloaded from the GitHub repository, it is necessary to first do an npm install. If the code was generated as explained in the previous section, it is not necessary to do so. Then, in both cases, proceed by compiling the contracts: truffle compile Then, migrate the contracts to the docker network: truffle migrate --network docker Copy the contract address that has been generated. This will be later used when initializing the dockers for the ethereum nodes. Open the Truffle console in the docker network: truffle console --network docker Now that the contract has been deployed, it can be accessed and interacted with by assigning the contract instance to a variable. let quartz = await ERC20Quartz.deployed() This operation can only be performed by the issuer of the contract. For anybody else with access to the network to have an instance of the contract to interact with, they must be provided the address of the contract, so they can do: let quartz = await ERC20Quartz.at(<contract address in quotes>) The contract address can be consulted by doing: quartz.address To check the accounts existing within the blockchain (to make a transaction to one of them or consult their balance) they can be consulted from the Truffle console: accounts If the initialization of the contract worked correctly, the first of the accounts, which corresponds to the issuer (and will be later assigned to Alice) should have all the tokens that have been minted in the initialization. let balance = await quartz.balanceOf(<public address of the first account>) balance.toNumber() 62 Appendix A. Run a local ILP testnet using the Quartz token toNumber is necessary so the information is displayed in a natural way. A.2.5 Start the ILP nodes Following the ILP tutorial, initialize the nodes. A couple considerations have to be made: •The token_address is the address of the ERC20Quartz contract. •The ip’s of the nodes are fixed, based on the ip of the local ethereum testnet (this initial ip can be checked from the console of the docker where the network is running). In this case, the ip of the network was set manually. •The asset scale is fixed to 9. •The exchange rate is provided by the API, so the parameter exchange_rate.provider is deleted. docker run -d \ --name alice-eth \ --network local-ilp \ -e "RUST_LOG=interledger=trace" \ --ip 192.168.128.3 \ interledgerrs/ilp-settlement-ethereum \ --private_key 380eb0f3d505f087e438eca80bc4df9a7 faa24f868e69fc0440261a0fc0567dc \ --confirmations 0 \ --poll_frequency 1000 \ --ethereum_url http://ethereum-testnet:8545 \ --token_address 0x770bC1820890415bB14a3B8f992c19caA74906aD\ --connector_url http://alice-node:7771 \ --redis_url redis://redis:6379/0 \ --asset_scale 9 \ --settlement_api_bind_address 0.0.0.0:3000 docker run -d \ --name alice-node \ --network local-ilp \ -e "RUST_LOG=interledger=trace" \ --ip 192.168.128.4 \ interledgerrs/ilp-node \ --ilp_address example.alice \ --secret_seed 8852500887504328225458511465394229 327394647958135038836332350604 \ --admin_auth_token hi_alice \ --redis_url redis://redis:6379/1 \ --http_bind_address 0.0.0.0:7770 \ --settlement_api_bind_address 0.0.0.0:7771 docker run -d \ --name bob-eth \ --network local-ilp \ -e "RUST_LOG=interledger=trace" \ --ip 192.168.128.5 \ A.2. Process 63 interledgerrs/ilp-settlement-ethereum \ --private_key cc96601bc52293b53c4736a12af9130abf3 47669b3813f9ec4cafdf6991b087e \ --confirmations 0 \ --poll_frequency 1000 \ --ethereum_url http://ethereum-testnet:8545 \ --token_address 0x770bC1820890415bB14a3B8f992c19caA74906aD\ --connector_url http://bob-node:7771 \ --redis_url redis://redis:6379/2 \ --asset_scale 9 \ --settlement_api_bind_address 0.0.0.0:3000 docker run -d \ --name bob-xrp \ --network local-ilp \ -e "DEBUG=settlement*" \ -e "CONNECTOR_URL=http://bob-node:7771" \ -e "REDIS_URI=redis://redis:6379/3" \ -e "ENGINE_PORT=3001" \ --ip 192.168.128.6 \ interledgerjs/settlement-xrp docker run -d \ --name bob-node \ --network local-ilp \ -e "RUST_LOG=interledger=trace" \ --ip 192.168.128.7 \ interledgerrs/ilp-node \ --ilp_address example.bob \ --secret_seed 16049667259821399005552084586370228 75563691455429373719368053354 \ --admin_auth_token hi_bob \ --redis_url redis://redis:6379/4 \ --http_bind_address 0.0.0.0:7770 \ --settlement_api_bind_address 0.0.0.0:7771 docker run -d \ --name charlie-xrp \ --network local-ilp \ -e "DEBUG=settlement*" \ -e "CONNECTOR_URL=http://charlie-node:7771" \ -e "REDIS_URI=redis://redis:6379/5" \ -e "ENGINE_PORT=3000" \ --ip 192.168.128.8 \ interledgerjs/settlement-xrp docker run -d \ --name charlie-node \ --network local-ilp \ -e "RUST_LOG=interledger=trace" \ 64 Appendix A. Run a local ILP testnet using the Quartz token --ip 192.168.128.9 \ interledgerrs/ilp-node \ --secret_seed 12323621311221399005552084586370228 75563691455429373719368053354 \ --admin_auth_token hi_charlie \ --redis_url redis://redis:6379/6 \ --http_bind_address 0.0.0.0:7770 \ --settlement_api_bind_address 0.0.0.0:7771 Next, change the exchange rates for the new coin using the API: curl -X PUT "http://192.168.128.4:7770/rates" \ -H "Authorization: Bearer hi_alice" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -d "{\"QTZ\":1.00,\"XRP\":0.000283}" curl -X PUT "http://192.168.128.7:7770/rates" \ -H "Authorization: Bearer hi_bob" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -d "{\"QTZ\":1.00,\"XRP\":0.000283}" curl -X PUT "http://192.168.128.9:7770/rates" \ -H "Authorization: Bearer hi_charlie" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -d "{\"QTZ\":1.00,\"XRP\":0.000283}" After that, create the accounts. Also here, a couple considerations have to be taken: •In the Alice and Bob accounts that used ETH in the example, the asset code is now QTZ. •The asset-scale is now 0. alias alice-cli="docker run --rm \ --network local-ilp interledgerrs/ilp-cli --node http://alice-node:7770" alias bob-cli="docker run --rm \ --network local-ilp interledgerrs/ilp-cli \ --node http://bob-node:7770" alias charlie-cli="docker run --rm \ --network local-ilp interledgerrs/ilp-cli \ --node http://charlie-node:7770" alice-cli accounts create alice \ --auth hi_alice \ --ilp-address example.alice \ --asset-code QTZ \ --asset-scale 9 \ --ilp-over-http-incoming-token alice_password alice-cli accounts create bob \ --auth hi_alice \ A.2. Process 65 --ilp-address example.bob \ --asset-code QTZ \ --asset-scale 9\ --settlement-engine-url http://alice-eth:3000 \ --ilp-over-http-incoming-token bob_password \ --ilp-over-http-outgoing-token alice_password \ --ilp-over-http-url http://bob-node:7770/accounts/ alice/ilp \ --settle-threshold 100000 \ --settle-to 0 \ --routing-relation Peer bob-cli accounts create alice \ --auth hi_bob \ --ilp-address example.alice \ --asset-code QTZ \ --asset-scale 9 \ --max-packet-amount 100000 \ --settlement-engine-url http://bob-eth:3000 \ --ilp-over-http-incoming-token alice_password \ --ilp-over-http-outgoing-token bob_password \ --ilp-over-http-url http://alice-node:7770/accounts/ bob/ilp \ --min-balance -150000 \ --routing-relation Peer bob-cli accounts create charlie \ --auth hi_bob \ --asset-code XRP \ --asset-scale 6 \ --settlement-engine-url http://bob-xrp:3001 \ --ilp-over-http-incoming-token charlie_password \ --ilp-over-http-outgoing-token bob_other_password \ --ilp-over-http-url http://charlie-node:7770/accounts/ bob/ilp \ --settle-threshold 10000 \ --settle-to -1000000 \ --routing-relation Child charlie-cli accounts create bob \ --auth hi_charlie \ --ilp-address example.bob \ --asset-code XRP \ --asset-scale 6 \ --settlement-engine-url http://charlie-xrp:3000 \ --ilp-over-http-incoming-token bob_other_password \ --ilp-over-http-outgoing-token charlie_password \ --ilp-over-http-url http://bob-node:7770/accounts/ charlie/ilp \ --min-balance -50000 \ --routing-relation Parent 66 Appendix A. Run a local ILP testnet using the Quartz token charlie-cli accounts create charlie \ --auth hi_charlie \ --asset-code XRP \ --asset-scale 6 \ --ilp-over-http-incoming-token charlie_password A.2.6 Perform the payment Send a certain amount of tokens from Alice to Charlie (in this example, 20): alice-cli pay alice \ --auth alice_password \ --amount 20 \ --to http://charlie-node:7770/accounts/charlie/spsp A.2.7 Delete the nodes and start over Only deleting the nodes, but keeping the network Delete the accounts: alice-cli accounts delete alice --auth hi_alice alice-cli accounts delete bob --auth hi_alice bob-cli accounts delete alice --auth hi_bob bob-cli accounts delete charlie --auth hi_bob charlie-cli accounts delete bob --auth hi_charlie charlie-cli accounts delete charlie --auth hi_charlie Remove the dockers: docker stop alice-node bob-node charlie-node alice-eth \ bob-eth bob-xrp charlie-xrp docker rm alice-node bob-node charlie-node alice-eth \ bob-eth bob-xrp charlie-xrp Remove everything Sometimes removing the nodes but keeping the network results in some issues when deleting the accounts. When this happens, the best option is to remove everything and start the process from scratch. docker stop redis ethereum-testnet alice-node bob-node \ charlie-node alice-eth bob-eth bob-xrp \ charlie-xrp docker rm redis ethereum-testnet alice-node bob-node \ charlie-node alice-eth bob-eth bob-xrp \ charlie-xrp docker network rm local-ilp 67 Appendix B Perform transactions using the server B.1 Introduction This appendix contains the detailed steps for performing transactions through an ILP network using a server to handle the shipment petitions. The server1accepts petitions to send a certain amount of Quartz from a given account to another. It is assumed that all the accounts that send the money are in the same host. B.2 Process B.2.1 Set up the environment To start using the server, there has to be an ILP network running. The sender and the receiver accounts have to exist withing said network. As a test, the local ILP docker network that was deployed in the previous appendix (see Appendix A) will be used. It is assumed that the reader has already downloaded the code for the server from the repository. B.2.2 Configure the server Copy the file serverConfig.json.example into a new file serverConfig.json and change the host and the port where the accounts that send the money are going to be. As previously explained, it is assumed that the server will be managing transactions coming from accounts in a particular host, although the receivers could be anywhere. For the test with the docker network, the hostname and port are: { "hostname": "192.168.128.4", "port": 7770 } 1The code for the server can be found in the GitHub repository of the project: https://github.com/ElenaPT/TFG_Inf_2021/tree/incoming_branch/src/token/ILP_server 68 Appendix B. Perform transactions using the server B.2.3 Run the server Before running the server, the ILP network has to be up and running. Appendix ?? contains instructions for deploying a local network for testing using docker. Once that is managed, simply do: cd ILP_server node transaction_server.js B.2.4 Perform a transaction The server expects the sender, the receiver and the amount of Quartz to be sent as parameters. It also needs the authorization-token of the sender, and expects it as a header. Taking this into account, to perform the transaction do a curl petition as follows: curl "http://localhost:8080/?from=<sender-account> \ &to=<receiver-payment-pointer>&amount=<amount>" \ -H "Authorization: Bearer <sender-auth-token>" For instance, to send 20 QTZ from Alice to Charlie in the docker network, the petition would be: curl "http://localhost:8080/?from=alice \ &to=http://charlie-node:7770/accounts/charlie/spsp \ &amount=20" -H "Authorization: Bearer alice_password" 69 Bibliography [1] Abdulla Alshamsi and Prof. Peter Andras. “User perception of Bitcoin usability and security across novice users”. In: International Journal of Human-Computer Studies 126 (June 1, 2019), pp. 94–110. issn: 1071-5819. doi:10 . 1016 / j.ijhcs.2019.02.004.url:https://www.sciencedirect.com/ science/article/pii/S1071581918301459 (visited on 09/04/2021). [2] API requests.url:https : / / developer . paypal . com / docs / api / reference/api-requests/ (visited on 08/08/2021). [3] Carl T. Bergstrom and Theodore C. Bergstrom. “The costs and benefits of library site licenses to academic journals”. In: Proceedings of the National Academy of Sciences 101.3 (Jan. 20, 2004). Publisher: National Academy of Sciences Section: Social Sciences, pp. 897–902. issn: 0027-8424, 1091-6490. doi:10.1073/ pnas.0305628101.url:https://www.pnas.org/content/101/3/ 897 (visited on 09/02/2021). [4] BitGive Foundation - 1st Bitcoin and Blockchain Nonprofit. BitGive Foundation. url:https://www.bitgivefoundation.org/ (visited on 05/06/2021). [5] Bo-Christer Björk. “Why Is Access to the Scholarly Journal Literature So Expensive?” In: portal: Libraries and the Academy 21.2 (2021). Publisher: Johns Hopkins University Press, pp. 177–192. issn: 1530-7131. doi:10.1353/pla. 2021.0010.url:https://muse.jhu.edu/article/787862 (visited on 09/04/2021). [6] Blockchain Infrastructure for Scientific Research. Bloxberg. url:https:// bloxberg.org/ (visited on 08/30/2021). [7] Vitalik Buterin. Ethereum Whitepaper. ethereum.org. 2013. url:https:// ethereum.org (visited on 05/30/2021). [8] H. Frank Cervone. “Understanding agile project management methods using Scrum”. In: OCLC Systems & Services: International digital library perspectives 27.1 (Jan. 1, 2011). Publisher: Emerald Group Publishing Limited, pp. 18–22. issn: 1065-075X. doi:10 . 1108 / 10650751111106528.url:https : / / doi.org/10.1108/10650751111106528 (visited on 05/22/2021). [9] Coil - A new way to enjoy content.url:https://coil.com/ (visited on 04/29/2021). [10] Digital Wallet and Payment Pointers.url:https://webmonetization. org/docs/ilp-wallets (visited on 05/31/2021). [11] Nadia Eghbal. “Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure”. In: Technical Report. Ford Foundation (2016), p. 143. url: https:/ / www . fordfoundation . org / work / learning / research - reports/roadsandbridgestheunseenlaborbehindourdigital-infrastructure/. [12] Empowering App Development for Developers | Docker.url:https://www. docker.com/ (visited on 05/31/2021). [13] Express - Infraestructura de aplicaciones web Node.js.url:https://expressjs. com/es/ (visited on 08/29/2021).