Blockchain Papers

Arghya Das

In this paper, we introduce SwarMED, a decentralized yet high throughput interoperability system for big biomedical data. SwarMED uses Etehreum blockchain for trustless security and Swarm p2p storage to handle high throughput transaction of big data. In SwarMED, we developed an indexing mechanism over the immutable storage of Swarm to achieve high-throughput while sharing millions of patient records and images among multiple parties. SwarMED achieved a high throughput of 250K medical records per second over a private network constructed over LSU-HPC cluster. This high throughput is 9x more comparing to conventional way of using p2p storage in conjunction with blockchain. This high throughput enables the patients to get realtime access to his comprehensive medical history and scientists to gain real-time access to different medical data for collaborative research complying to the constraints posed by existing laws. Our system-level analysis over different design alternatives over different transfer and storage architectures shows that, p2p storage platforms automatically provide significantly better scalability over traditional HTTP with increasing number of clients. Swarm provides 2x more I/O throughput and 10x less latency than IPFS, another p2p storage system making it a better choice for decentralized big data transaction.

Marcos Allende López, Adrián Pareja

This paper presents a protocol to manage decentralized access and use of Permissioned Public Blockchain Networks using Ethereum technology as the underlying protocol. It proposes a solution to avoid DDOS and enforce accountability while eliminating transaction fees. The protocol has been tested and implemented in the LACChain Blockchain Networks.

D. Jonathan Sebastian-Cardenas, Sri Nikhil Gupta Gourisetti, Peng Wang, Jesse Smith · 6 authors

Within the field of Transactive Energy Systems (TES), there is an active need for tools that can support and accelerate the development of these new grid solutions. Among the many tools available, blockchain stands out as a viable instrument that can help researchers develop decentralized, autonomous, and tamper-resistant grid applications. In this work, we explore the use of smart contracts (SCs), a subset of blockchain technology, and analyze their applicability to facilitating the implementation of TES solutions. In particular, we focus on presenting areas of opportunity and potential drawbacks, along with use cases that can benefit from this technology building upon previous research developed by Pacific Northwest National Laboratory and other research organizations. This work builds upon the fundamentals of TES and smart contract technology to develop a series of software templates that can be used by industry to build TES-oriented grid solutions. These templates are intended to be platform agnostic and take into consideration the unique properties of SCs and distributed ledger storage mechanisms to ensure actual code implementations remain aware of the limitations of the technology. The proposed templates have the potential to enable software architects to mix and match components to satisfy their application requirements, thereby reducing the number of resources required to implement blockchain-based solutions. These templates are divided into two main components—data and behavioral models. The data models are intended to help software engineers represent the underlying grid objects along with their properties in a ledger-based storage system. The behavioral models are used to describe the processes and actions that actors within a system must perform to achieve a given outcome such as registering an asset, placing a bid, and performing bid clearances. These two components are documented in a Unified Modeling Language (UML) format and are intended for use in SC-based implementations, with special behavioral considerations to account for the asynchronous properties of the underlying ledger and the typical execution model of smart contracts. Finally, future research ideas and potential extensions to this work are discussed. In particular, known limitations and potential improvements of the developed product are identified and expected to be addressed in future revisions of the template model.

Ankit Khandelwal, Madhav Narayan Singh

Blockchain is one of the IT industry's fastestgrowing technology niches. We chose to use blockchain technology to develop a web application for our project. We'll create a fully functional crypto-currency with full stack functionality and blockchain logic. We are proposing a new improvement in which we will not use any database server at the backend. Instead, we'll use Redis to create a publisher/subscriber network that will enable us to broadcast various messages and chain them across the network. Every node in the network will have a wallet, and they will make various transactions, which will then be added to the blockchain to block, and then broadcasted to the rest of the chain This eliminates the need for a database infrastructure to be created and maintained. We will create a mining algorithm (proof of work algorithm) for selecting blocks (collection of transactions) that will change its difficulty rate based on the computational power present in the node to node network, and for each block mined and successfully added to the chain will be rewarded with a reward in the form of our Cryptocurrency.

Daniel Kraft

No abstract is available for this record.

Sky Guo, Joseph Kreitem, Thomas Moser

No abstract is available for this record.

Silvia Crafà, Cosimo Laneve

Liquidity is a liveness property of programs managing resources that pinpoints those programs not freezing any resource forever. We consider a simple stateful language whose resources are assets (digital currencies, non fungible tokens, etc.). Then we define a type system that tracks in a symbolic way the input-output behaviour of functions with respect to assets. These types and their composition, which define types of computations, allow us to design two algorithms for liquidity that have different precisions and costs. We also demonstrate the correctness of the algorithms.

Alessia Antelmi, Giuseppe D’Ambrosio, Andrea Petta, Luigi Serra · 5 authors

The amount of accessible computational devices over the Internet offers an enormous but latent computational power. Nonetheless, the complexity of orchestrating and managing such devices requires dedicated architectures and tools and hinders the exploitation of this vast processing capacity. Over the last years, the paradigm of (Browser-based) Volunteer Computing emerged as a unique approach to harnessing such computational capabilities, leveraging the idea of voluntarily offering resources. This article proposes VFuse, a groundbreaking architecture to exploit the Browser-based Volunteer Computing paradigm via a ready-to-access volunteer network. VFuse offers a modern multi-language programming environment for developing scientific workflows usingWebAssembly technology without requiring the user any local installation or configuration. We equipped our architecture with a secure and transparent rewarding mechanism based on blockchain technology (Ethereum) and distributed P2P file system (IPFS). Further, the use of Non-Fungible Tokens provides a unique, secure, and transparent methodology for recognizing the users’ participation in the network.We developed a prototype of the proposed architecture and four example applications implemented with our system. All code and examples are publicly available on GitHub.

David Last, Michael Atighetchi, Partha Pal, Ryan Toner

The US military is focused on transitioning its warf-ighting philosophy towards the Multi-Domain Command and Control (MDC2) concept, which integrates lands, sea, air, space, and cyberspace forces into a unified planning and execution structure. This structure depends on reliable exchange of plans and intelligence reports, which is hindered by the development of adversary capabilities in the areas of radio jamming and other communications-denying technologies. The battlefield of the future will consist of dispersed units with intermittent, constrained communications who nevertheless need to maintain a consistent view of shared plans and information. We are developing a proof-of-concept prototype MDC2 system to explore the requirements and limitations of a solution in this space. There are many distributed database solutions that could be used for this prototype; upon investigation, we believe that Distributed Ledger Technologies (DLT) are an ideal fit for the particular constraints of this use case. We have selected Hyperledger Fabric as the particular DLT implementation on which we are building this prototype. As part of this research, we are developing a Hyperledger-based prototype as well as a baseline implementation that reflects how the DoD handles this process today. We will use both of these systems in a series of experiments that evaluate how well they perform in the areas of database consistency, constrained tactical networks, and conditional authorities, and we will measure their performance using a suite of metrics that will allow us to compare the DLT-based prototype with the baseline system. This paper outlines the challenges we will address through this research; the completed research will encompass our solutions to these challenges.

Lihua Zhang, Jiayi Bai

Because the existing wind turbine safety is limited by the traditional centralised management, it faces many security risks. Therefore, the future wind turbine management and control scheme is developing towards distributed security and high performance. Relying on Ethereum block technology to build smart contracts can help solve the security protection problems of network authority control and management in wind power energy systems. First, based on the analysis of wind power network security management needs, establish a mathematical model of security indicators for the control centre and subordinate nodes, respectively, when the permissions are out of control; second, based on the Ethereum smart contract release platform, according to the mathematical model of security indicators run wind power contract management (WPCM), predict the results of out-of-control simulation, and compare with the communication parameters of a typical wind farm in Northwest Europe. Studies have shown that the established wind power energy network security management plan has the characteristics of high security and good robustness, and the system processing speed is fast, which meets the offshore wind farm communication standard.

Alex Williams, Deepak K. Tosh

Provenance in computing systems is the key to establishing data integrity. It provides a historical ledger of data's life cycle through creation, ownership, consumption, and manipulation. With provenance in hand, it is possible to reverse engineer the state of the data that can lead to understanding how it was derived and verify its accuracy. This need for data integrity is extremely critical in scientific workflows to ensure verifiability and repeatability of the derived results. Due to the vast computational power required by scientific workflows, many operate within high performance computing (HPC) environments, where data is consumed and manipulated by a multitude of processes running on highly distributed infrastructure. The current landscape of HPC environments range from on-premise systems to cloud and grid based solutions. While the majority of research in digital provenance has been focused on standalone HPC environments, provenance in a heterogeneous HPC environment remains a challenge. In this paper we propose HyperProvenance, a high level system architecture especially for next generation heterogeneous HPC environments, which aims to increase confidence in workflow result accuracy through secure provenance collection.

Authors unavailable

The mathematical model "Peer-to-peer distributed system for securable information storage and processing in enterprise networks" is described hereinafter. It is a versatile distributed operating system designed for the protection of distributed computing and insulation of private networks without restricting the possibilities of effective interactions, cryptographic security, protection from unauthorized access with the application of biometry and an innovative protocol of data exchange for topology control based on distributed ledger technology. The modeling was performed with the purpose of evaluation of performance of the system depending on productivity of the hardware of its nodes and the network's telecommunications equipment.

Barend Mons

This personal reaction is written from multiple perspectives. First and foremost, as the corresponding author of the original FAIR article. Second as the chair of the first High Level Expert Group (HLEG) of European Open Science Cloud (EOSC) (which is how I met Jean-Claude) and third from my current GO FAIR and CODATA perspective. None of what I write below is to be seen as a formal position of any of the organisations I am associated with.Let me start by stating that, after some periods silent of hope and of deep despair, I now strongly feel that, with the governance of the EOSC Association in place, EOSC will become a success after all. It will still be critical that the Association involves the member states (MSs) and actual researchers in an agile and non-bureaucratic manner, for which we need bottom-up mechanisms such as operated by the Research Data Alliance (RDA) and GO FAIR. But a balancing formal entity operating along the formalised Strategic Research and Innovation Agenda [1] and the Partnership proposal as well as the various “declarations” including the recent one under the German presidency [2] are an excellent guiding roadmap to a successful EOSC, obviously in global context.That said, at the risk of sounding like broken record, this reaction should also look at the points where it went “almost” wrong, as we should try and learn from our mistakes. I may make some enemies—or strengthen the opinion of existing ones—in the process, but then, a wise old friend, who also wrote one of the reactions once told me: “Barend, unless you made some enemies you probably lived in vain.” So I will speak my mind (“what's new'?). I also like to say that ”EOSC“ brought me some real new friends for life!First of all, the fact that quickly after its inception FAIR became a hype term①, which was probably partly even accelerated by the prominent role it played in early EOSC discussions with EC's Director General, also has its downsides. Like for the term “AI”, everyone co-opts the term and some start watering the concept down to a bloodless caricature from what it originally meant. In the case of FAIR this includes removing the central notion of machine actionability, mis-characterising it as a standard, conflating it with “open”, only linking it to data sensu stricto, ignoring software, algorithms and more. In general terms, people that sometimes seem to have never read the original article [3], the most flagrant abuse of the term I have heard (obviously not from an active researcher) is this: “If data are Findable, Accessible and Interoperable it is ”automatically' Reusable.“ This is of course ”swearing in FAIR church“ as the R (principles R1–3) [3] clearly state that rich provenance and reuse conditions are critical and in particular the provenance. The decision whether (even high quality) data are fit for purpose (reuse in a particular study) is a critical step and is imho (in my humble opinion) at the basis of the reproducibility problem we currently face. Therefore, I would like to re-emphaisize here my current one liner to summarise the aim of the FAIR guiding principles: ”The Machine Knows what I mean“. Those who feel that FAIR is too ambitious and for instance promote that ”achieving F and A is enough for now“ in my humble opinion fail to see the disruptive character of the solutions we need to make EOSC and its sister around the globe a real paradigm shift towards Open Science (OS). Or they are just trying to preserve the status quo and move incrementally at a pace they can follow.This nicely bridges to the first observation on EOSC as such. I indeed think that the first “Communication” that needed 126 iterations mentioned by Jean-Claude, which happened in the same time frame as our “HLEG-1” period, was symptomatic for a basic flaw in the discussions, which haunts us still today. Conflating the “ICT”/HPC (or basic e-infrastructure) with the data and end user applications for analytics, has caused an enormous hurdle. In the entire journey of the HLEG we had to carefully navigate around this cliff and it is still a highly controversial issue today. This part was the “Dunning Kruger effect” [4] pur sang: The “other side is easy” (because I am not hindered by any knowledge about it) and is “more or less already done” (because I do not understand the complexity). This is not only true for the active researchers who cannot use the current e-infrastructure efficiently (and naturally that is “entirely the fault of the nerds who build things I do not understand or cannot operate”), but also for e-infrastructure engineers who know everything about ICT and “thus” (?) also about data (because “that is just ones and zeros”) as Jean- Claude also noted. I also believe however, that it is a mistake to completely separate e-infrastructure for the data and services layer, as the e-infrastructure should route (and understand at least at middleware level) what processes are needed on the data and how the FAIR services “run”. Nowadays (after many iterations) I use the diagram below (Figure 1) to explain that all three basic elements of the “Internet of FAIR Data and Services” are needed. Each of them should be adorned with FAIR (machine actionable) metadata to seamlessly form a Web of FAIR Data and Services on top of the current, proven Internet backbones, thus forming the “Internet of FAIR Data and Services”, eventually creating an “Internet for Social Machines” [5] where people and machines can both efficiently use all services, independently and in collaboration.This does absolutely not mean that the foundation (e-infrastructure) of the triangle is “trivial” or “can be reused as is”. Not only middleware, but also the crucial and fundamental concept of FDOs needs to be developed in close collaboration between data and computer experts and is largely domain-agnostic.The seamless combination will become the principle “package” of information that machines (and also people) can understand and act upon. Major infrastructure builders should actually co-lead this, while domain scientists need to decide on which data formats and metadata schemes (i.e. FAIR Implementation Profiles [9]) should be built on this basic schema.Together with the Dunning Kruger effect, too many overlapping and redundant projects supporting the talking/meeting/landscaping, re-landscaping and re-re landscaping' has resulted in what I became to call the “EOSC is a bigger Me syndrome”. On the one hand, countless people voluntarily invested (and still invest) their time in the development of the EOSC, but others seem to only see EOSC as “yet another way to collect EC funding for their current solutions that are in my opinion not future- and OS proof. This misbalance between people investing their own time and effort based on intrinsic motivation and vision and on the other hand the ”reliance on EC subsidy“ caused a dichotomy during the scoping years of EOSC between disruptive and ”preservative“ approaches. The heavy reliance on EC subsidy also largely ignored the subsidiarity principle [10] and the fact that 90% of the eventual infrastructures and services that we need for EOSC will be paid by the MSs. Also data and research intensive industry was largely kept out of the loop, which was another mistake I have frequently pointed out. This helped to create and sustain the ”Brussels Bubble“ that Jean-Claude described. The Association will hopefully reverse that trend.Finally, the influence on the HLEG report of the then-commissioner was rather profound. The report was not only delayed almost 6 months after its proposed publication version, but there is also a nice additional “untold story” here: The originally proposed title of the report was: “A Cloud on the 2020 Horizon”. In my original foreword I explained the slightly “glooming” connotation of that title. When the report was finally approved, it appeared that the title had been unilaterally changed into “Realising A European Open Science Cloud [11]”. Not only did I have to hastily change my foreword (because it made no sense anymore) but also, my notorious statement that the “result” should neither be “European” (only), nor Open (only) nor (only) for Science and certainly not (just) a “Cloud” was entirely ignored in changing that title. But it again emphasises the “This is an EC thing” context, with the associated risk for confiscation of the concept by the “usual suspects” in EC subsidy land. However, I feel after three years of intensive deliberations, which may be considered lightning fast on the geological time scale, see George's reaction, we can conclude that most of the original HLEG recommendations are well-represented in the basic guiding documents of the EOSC Association, which makes me a happy man at the end of this crazy year.That leads me to the final observation: As a result of the (quote from Jean-Claude): “non-paper seen as the political turning point in support of EOSC” [12], GO FAIR (Global Open FAIR) [13] was started, originally by Germany and The Netherlands and soon joined by France as a temporary “kick-start”, bottom-up approach to accelerate EOSC (see also recommendation I-2.1. in the HLEG report, annex 1).Soon, GO FAIR became really global and the agile modus operandi of practical Implementation Networks yielded a number of crucial approaches to speed up the adoption of the FAIR guiding principles and the hourglass approach [14]. Now, late 2020, when the EOSC Association is a fact, GO FAIR (1.0) has achieved its goals (early implementation steps) and we need to reflect on its future. Next to the intrinsic value of the active GO FAIR IN community [15] as such, several particular assets that I need to mention here are the development of the FAIR Implementation Profile and Metadata4Machines approach, the development of easy to install FAIR data points for open, FAIR metadata publication and indexing, and last but not least the international effort (involving many players, also outside the direct GO FAIR initiative) to develop the minimal specs of the FDO framework [7] in a more specified form than when coined in the FAIR expert group report [5]. These assets (all open source and open access) can be carried over, not only to EOSC, but will have much wider, international, impact most likely leading to a continuation of GO FAIR (2.0) beyond its original time scope, namely three years, the predicted time it would take to complete the international policy and bureaucracy process to reach the status of a formal association as we have today. I hope the leaders of the Association will optimally learn from the successes and failures and near-road-accidents of the last three years and see EOSC as the European contribution to a “Global Open Science Commons”, also known as the Internet of FAIR Data and Services, in full, open collaboration with the international organisations that are now joining forces in the Data Together initiative [16]. After all, the major challenges we face are global, so is the research needed to face them and so are the solutions we hope to fiend. I fully trust the current leadership of the association to make that vision reality.Policy recommendationsGovernance recommendationsImplementation recommendations

V. S. Dhillon, David Metcalf, Max Hooper

In the Ethereum ecosystem, the transfer of value between users is often realized by the use of tokens that represent digital assets. Ether is the default token and the de facto currency used for transactions and for initializing smart contracts on the network. Ethereum also supports the creation of new kinds of tokens that can represent any commonly traded commodities as digital assets. All tokens are implemented using the standard protocol, so the tokens are compatible with any Ethereum wallet on the network. The tokens are distributed to users interested in the given specific use case through an Initial Coin Offering (ICO). In this chapter, we will focus our attention on tokens created for a very specific use case: high-performance computing (HPC). More precisely, we will discuss a model of distributed HPC where miners offer computational resources for a task and get rewarded in some form of Ethereum token.

Dimitri Samorukov

Dezentrale Anwendungen werden, im Gegensatz zu zentralisierten Ansätzen, durch eine Unterstützergemeinschaft betrieben. Diese unterliegen keiner zentralen, kontrollierenden, eventuell sogar bösartigen Instanz. Viele Anwendungsgebiete werden durch dezentrale Ansätze abgedeckt. Beispiele hierfür sind dezentrale soziale Netzwerke, Währungen, Logbücher (engl. distributed ledger, i.e. blockchain). Durch eine breite Unterstützung sind die dezentralen Ansätze in der Lage, die marktbeherrschende Stellung einiger weniger Anbieter aufzubrechen und eine echte neutrale, offene Alternative anzubieten. Betrachtet man die Komponenten einer dezentralen Anwendung so trifft man auf der untersten Ebene auf die Hardwareebene, einzelne Peers die durch ein Netzwerk miteinander kommunizieren können und durch einen Operator verwaltet werden. Auf der höheren Anwendungsebene trifft man auf Benutzer, die auf die Dienste der Anwendung mit Hilfe von Operationen zugreifen und auf Daten der Anwendung, sogn. Verwaltungsstruktur. Die Hardwareebene stellt Ressourcen bereit, die durch die Anwendungsebene konsumiert werden. Leider leidet die Akzeptanz der dezentralen Anwendungen an Performanz der Operationen. Die Ursachen hierfür liegt in den unzureichenden Ressourcen der Hardware-Ebene oder ungünstiger Platzierung der Verwaltungsstruktur bezüglich ausgeführter Operationen. Die Ursache der unzureichenden Ressourcen in der Hardware-Ebene liegt u. A. an der absichtlichen Abwanderung der einzelnen Peers, aufgrund der dauerhaften Überlastung. In dieser Arbeit wird gezeigt, dass die günstige Platzierung der Verwaltungsstruktur bei gleichzeitig strikter Einhaltung der durch den Operator bereitgestellten Ressourcen dazu genutzt werden kann die Performanz der Operationen zu erhöhen. Damit werden die Bedürfnisse der Operatoren und Benutzer berücksichtigt, was auch zur verbesserten Akzeptanz der dezentralen Ansätze führt. Die Ergebnisse der gewählten Lösung zeigen, dass wenn ein einzelner Peer die ihm bekannten Teile der Verwaltungsstruktur optimal innerhalb seiner Nachbarschaft verschiebt, dies die Ausführungszeiten der Operationen reduziert. Somit wird ihre Performance deutlich verbessert.

Xueping Liang, Sachin Shetty, Deepak K. Tosh, Peter Foytik · 5 authors

Distributed ledger technology (DLT) provides decentralised services by removing the need of trust among distributed nodes in the distributed system. Transactions across the network are visible to a...

Morné Pretorius, Nelisiwe Dlamini, Sthembile Mthethwa

No abstract is available for this record.

E. V. Melnik, M. V. Orda-Zhigulina, Д. В. Орда-Жигулина

No abstract is available for this record.

Gavin Zheng, Longxiang Gao, Liqun Huang, Jian Guan

No abstract is available for this record.

Anish Jindal, Jakob Kronawitter, Ramona Kühn, Martin Bor · 10 authors

Abstract With the increased penetration of distributed renewable energy sources (DRES) in the grid, new pathways are required to keep the electricity distribution system stable. The provision of ancillary services (AS) by the DRES can contribute in this regard. However, it is necessary to communicate the need for AS from the third party providers such as distribution system operator (DSO) to the DRES in an efficient and scalable manner. To this end, a flexible information and communication technology (ICT) architecture is presented in this paper, and the requirements for the architecture are elaborated. We argue that this architecture is capable of supporting the present and future needs of electricity distribution networks. To illustrate its utility and effectiveness, an accounting use case for DSOs has been presented; it describes a remuneration scheme for the AS provision. A dashboard has been developed to enable communication via this architecture and to allow control of the grid. In addition, a distributed ledger technology for the realization of accounting has been analysed with respect to its scalability and performance capabilities.

Sergio Rajsbaum, Michel Raynal

Modern computing systems are highly concurrent. Threads run concurrently in shared-memory multi-core systems, and programs run in different servers communicating by sending messages to each other. Concurrent programming is hard because it requires to cope with many possible, unpredictable behaviors of the processes, and the communication media. The article argues that right from the start in 1960's, the main way of dealing with concurrency has been by reduction to sequential reasoning. It traces this history, and illustrates it through several examples, from early ideas based on mutual exclusion (which was initially introduced to access shared physical resources), passing through consensus and concurrent objects (which are immaterial data), until today distributed ledgers. A discussion is also presented, which addresses the limits that this approach encounters, related to fault-tolerance, performance, and inherently concurrent problems.

Kiran Kumar Kondru, R. Saranya, Annamma Chacko

No abstract is available for this record.

Phani Chitti

Distributed ledgers are a new type of database technology that allows open access to data stored across distributed, decentralised, publicly maintained infrastructures. Current implementations of the such ledgers expect competition between participants, are often energy hungry, poor in maintaining the natural structure of data and suffer from scalability constraints. The aim of my research work is to develop a distributed ledger-based middleware for data modelling and collection on household energy generation and use, while addressing scalability and energy inefficiency concerns of the ledger for this particular application domain. The energy data collected and made available through this middleware will be used for digital energy service delivery (e.g., automated peer to peer energy trading, topological estimations, etc.). The middleware also provides a platform for a consumer focused digital energy service delivery, as well as service model evaluation. The model evaluation will enable the prospective service users to evaluate the suitability of the given service for their needs before making a decision of service subscription.

Authors unavailable

There are many consensus algorithms that exist in parallel computing that involve multiple computing units like virtual machines which make use of available resources and arrive at a single agreeable state for the combined system. This is done on the basis of voting which itself branches into several arrangements like voting, functions of central tendencies, weighted functions of central tendencies etc. Some applications that consensus algorithms try to cover are: deciding on transaction operations (read, write, commit); deciding on node leaders of a system; maintaining replicas in the state of a machine (also called a state machine) and creating consistency between them. Some common algorithms of this type are Proof of Work algorithm (PoW), the practical Byzantine fault tolerance algorithm (PBFT), the proof-of-stake algorithm (PoS) and the delegated proof-of-stake algorithm (DPoS), Paxos algorithm and the Raft consensus algorithm.