Skynet WhitepaperCreating the Intelligent Machine Economy

Skynet Core - The First Blockchain System on ChipSkynet Open Network - A Novel Infinity Blockchain Network

Alexander ShiUniversity of California, Berkeley

CEO, OpenSingularity

Dr. Jae JungPh.D. University of California, San Diego

CTO, OpenSingularity

OpenSingularity FoundationJuly 8 2018Version 1.0

Rider A

IMPORTANT: YOU MUST READ THE FOLLOWING DISCLAIMER IN FULL BEFORE CONTINUING

This Whitepaper contains information regarding the Skynet project (the "Project"), including informa-tion regarding the Skynet System, Skynet Open Network, Skynet Core, the Skynet tokens, Light tokens,and their functionalities thereto as presently conceived, and is solely intended for the use of such intendedrecipient for general information purposes only. While we make every effort to ensure that the material inthis Whitepaper is accurate and up to date, such material in no way constitutes the provision of professionaladvice. We do not guarantee, or accept any legal liability whatsoever arising from or connected to, theaccuracy, reliability, currency, or completeness of any material contained in this Whitepaper, and to themaximum extent permitted by all applicable laws, regulations and rules, we shall not be liable for losses ofany kind, including indirect, special, incidental, consequential losses, in tort, contract or otherwise arisingout of or in connection with any acceptance of or reliance on this Whitepaper or any part thereof by you.

This Whitepaper is not to be reproduced or replicated in any form or manner, or transmitted, distributedor disclosed, or used or relied upon to any other persons for any purpose without our express writtenpermission. If you are not the intended recipient, disclosure, copying, distribution and use are similarlyprohibited; please notify us immediately and delete this Whitepaper from your system.

Further functionality and/or features may be changed, revised, modified, and/or added by the Projectteam as research and development around the Project continues. As such, the Project, the Skynet System,Skynet Open Network, Skynet Core, the Skynet tokens, Light tokens and their functionalities thereto asdescribed in this Lightpaper may accordingly be subject to change and/or revisions without any prior notice.Please refer to https://skynet.co/ for latest updates and developments to the Project.

For the avoidance of doubt, this Whitepaper is not, is not intended to be, and should not be construed tobe, a prospectus or offer document of any sort, and is not, is not intended to be, and should not be construedto constitute an offer of securities of any form, units in a business trust, units in a collective investmentscheme or any other form of investment, or a solicitation for any form of investment in any jurisdiction. Noregulatory authority has examined or approved of any of the information set out in this Whitepaper. ThisWhitepaper has not been registered with any regulatory authority in any jurisdiction.

2

Abstract

The creation of the intelligent machine economy is now feasible and comes with the potential to disrupt

all current centralized systems and economies as a whole. However, even with the parallel development

of artificial general intelligence, distributed ledger technologies, and the Internet of Things, no current

system successfully utilizes these three fields to enable collaboration, learning, and interactions between

billions of autonomous devices. Here, we introduce Skynet, an end-to-end protocol combining a neural

processing blockchain core and a Byzantine fault tolerant infinity-chain infrastructure to create the new

intelligent planet.

To provide a scalable network that supports workloads from billions of different IoT devices, Skynet

provides an infinity-blockchain architecture that enables instantaneous transaction speeds and unlimited

throughput. As the network only tracks the amount of tokens on each blockchain, Skynet enables the

creation of an endless number of independent application specific sidechains that remain connected to

pools of other networks. In this manner, the network can handle chaotic IoT subsystems by providing

support for configurable and interoperable decentralized networks.

To provide the applications necessary to enable human-like interactions between devices of various

knowledge domains, Skynet contains a virtual application layer. Devices can query the layer to access

decentralized applications that support the intelligent machine economy such as: decentralized identi-

ties, distributed storage, digital currencies, node discovery, distributed computation, and decentralized

machine learning.

To provide the real-world infrastructure for cryptocurrency adoption, the usability of decentralized

applications, and accelerated processing for deep neural networks, Skynet contains a license-free modular

SoC core optimized for blockchain and artificial intelligence. With an embedded crypto hardware wallet,

tensor processors, and hash accelerators, the blockchain SoC core will enable the mass production of

low-cost smart IoT devices that could securely sign transactions, learn advanced neural network models,

and leverage the utilities of distributed ledgers. All the cores can be immediately connected by its native

network and allow hosted devices to begin interacting over its scalable frameworks.

In summary, both the network and the core together will form a disruptive machine ecosystem where

devices can achieve human-level performance and have the capacity to begin interacting with one another.

In this white paper, we detail a system of implementation combining the first blockchain core with a

scalable blockchain network to enable evolutionary growth and secure interactions between Internet of

Things devices.

3

Contents

1 Introduction 71.1 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Addressable Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3.2 Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.3 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Skynet Overview 102.1 Architectural Benefits of Blockchain for IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Application Benefits of Blockchain for IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Problems with Blockchain Networks for IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Blockchain Adoption Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 Hardware Wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Addressable Network Solution Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Application Solution Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7 Addressable Hardware Solution Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.8 Skynet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.8.1 SON Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.8.2 Network Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.8.3 Skynet Core Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.9 Skynet Adoption Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.10 OpenSingularity Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.11 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Skynet Core 243.1 CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 Arm Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.2 Goals of RISC-V ISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.3 RISC-V Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Skynet Open Network Cryptography Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Neural Processing Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.1 Neural Network Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.2 Neural Network Computational Requirements for Modern Networks . . . . . . . . . . 323.3.3 NPU Architecture: GPU vs TPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.4 NPU Available Offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.5 Potential for Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4 Skynet Open Network 364.1 Network Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.1 Skynet Open Network, Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.2 Skynet Open Network, Nova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Skynet Open Network, Idex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3 Skynet Open Network, Singularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4

4.4 Skynet Open Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.5 Tendermint Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.6 Client Node Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.7 Application Blockchain Client Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.8 Validators and Delegators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.9 Tendermint BFT dPoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.10 IVAL+ Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.11 Light Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.12 Cross-Blockchain Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.12.1 Infinite Sharding Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.13 SON Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.13.1 Fabric Entangled Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.13.2 SON Fabric Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.13.3 Validators and Incentives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.13.4 Slashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.13.5 Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.13.6 IoT Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.14 Skynet Open Network, Idem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.15 Beacons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.15.1 Machine Reputation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.15.2 Machine Identity Strength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.15.3 Crypto Phonebook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.16 Skynet Open Network, Nova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.16.1 Nova Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.17 Skynet Open Network, Singularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.18 Skynet Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5 Conclusion 56

Appendices 57

A Blockchain Overview 57A.1 Blockchain Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57A.2 Blockchain and Distributed Consensus Technology . . . . . . . . . . . . . . . . . . . . . . . . 57

A.2.1 Asymmetric Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57A.2.2 Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58A.2.3 Distributed Hash Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58A.2.4 Interplanetary File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59A.2.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59A.2.6 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60A.2.7 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60A.2.8 Blockchain Ledger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

A.3 Basic Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61A.3.1 Linked List of Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61A.3.2 Merkle Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62A.3.3 Directed Acyclic Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5

A.4 Blockchain Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63A.5 Consensus Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

A.5.1 Proof of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66A.5.2 Proof of Stake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.5.3 Delegated Proof of Stake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.5.4 Proof of Weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.5.5 Proof of Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.5.6 Practical Byzantine Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68A.6.1 Proof of Work Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

A.7 Proof of Stake Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.7.1 Directed Acyclic Graph Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70A.7.2 Byzantine Fault Tolerance Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.8 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71A.8.1 Failure Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71A.8.2 Fault Tolerance Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

A.9 Sharding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73A.9.1 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73A.9.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

A.10 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6

1 Introduction

1.1 VisionThe concept of Skynet, often referred to as the fictional conscious superintelligence system in the movie TheTerminator, is becoming increasingly relevant with the recent explosion of growth in artificial intelligenceand robotics.

With the rise of machine learning, computers have been able to achieve human-level performance onhighly complex perceptual tasks.1 Advancements in deep learning have enabled artificial neural networkssuch as AlphaZero to beat World-Champion Go players easily.2 The optimization of processors such asGoogle’s 180 Teraflop TPU can further accelerate neural network training.3

Now more than ever are people beginning to realize that artificial intelligence can transform our world intoone in which disparate intelligent entities can interact with one another without human control. However,concerns about companies like Google automating the US Drone Defense Systems with artificial intelligence4

have resulted in the project not being renewed5, and other corporations like Amazon are on the verge ofbecoming the sole cloud provider of the Pentagon6. The fear of Skynet is becoming more justified as theworld faces many challenges in creating a variant that will benefit humanity.

However, we believe that distributed ledger technologies, such as the blockchain, can lead to a beneficentSkynet or as we call it, the intelligent machine economy. With blockchains, the collective knowledge ofall devices can be distributed, ensuring that no central system can influence all the others. Autonomousdevices be managed with systems that prevent future harmful actions while incentivizing positive behavior.No centralized control will exist over the network, enabling machines to directly interact with one anotherwithout a human operator or middleman. Blockchains, as a result, will enable many new decentralized andsecure applications that can be executed over the intelligent edge.

In the projected 7.1 trillion dollar Internet of Everything Market7, 10 trillion dollar Blockchain market8,and 15.7 trillion dollar AI market9 that collectively make up the intelligent machine economy, devices suchas robotic doctors will be able to autonomously diagnose patients and treat patients. Self-driving cars willhave the capacity to communicate with nearby cars securely to minimize crashes. Smart devices will havethe intelligence to act on a person’s behalf to enhance the quality of life. With the advancements in artificialintelligence, blockchain technology, and hardware, the intelligent machine economy can be created today.

With this in mind, OpenSingularity is creating Skynet, an end-to-end protocol designed to meet the re-quirements of an intelligent machine economy via its two components: Skynet Open Network (SON), a scal-able machine learning IoT blockchain platform and Skynet Core, a license-free neural processing blockchaincore.

Skynet Core hardware will lay the real-world foundation to support cryptographic acceleration, neuralnetwork processing, and System-on-Chip development in IoT devices whereas the Skynet Open Network willserve as the distributed "hive mind" infrastructure that will give devices the capacity to self-organize, learn,and transfer information between one another.

1physics.aps.org/featured-article-pdf/10.1103/PhysRevX.7.0110152https://deepmind.com/blog/alphago-zero-learning-scratch/3https://cloud.google.com/tpu/4https://globalnews.ca/news/4125382/google-pentagon-ai-project-maven/5https://gizmodo.com/google-plans-not-to-renew-its-contract-for-project-mave-18264886206https://aws.amazon.com/government-education/defense/7https://en.wikipedia.org/wiki/Internet_of_things8https://www.coindesk.com/crypto-blockchain-create-10-trillion-market-rbc-analyst-says/9https://www.bloomberg.com/news/articles/2017-06-28/ai-seen-adding-15-7-trillion-as-game-changer-for-global-economy

7

More broadly, Skynet Core’s modular blockchain hardware design will enable physical devices to performperception tasks on unstructured sensory data, support application development, and utilize blockchainnetworks. The application layer over the Skynet Open Network can be used to foster collaboration, trainingover the edge, and exchanges in value between devices. With both the hardware and network, billions ofSkynet Cores can be deployed to IoT devices around the world and be immediately connected by the SkynetOpen Network.

1.2 Addressable MarketSimilar to how the Internet grew from mainframes to servers to PCs to mobile, to IoT devices, both artificialintelligence and blockchain are propagating through the same path and are ready for IoT. These sectorsof technology are converging into something called the Internet of Things 2.0—the intersection of the de-centralized cloud, big data, artificial intelligence, Internet of things, and blockchain at the intelligent edge.Combining these technologies will enable a decentralized intelligent machine economy for IoT devices thatovercome the current dominance of a few centralized players.

For example, devices will be able to learn from one another to form a self-learning economy, thus improvingon current cloud systems such as Amazon Web Services and standard machine learning datasets like Imagenet.Devices will be able to collaborate directly with one another, without going through a central service like HP-Enterprise or Microsoft Azure. Machines will be able to exchange data and value in milliseconds, replacingthe need for Visa or Paypal. A new revolution of blockchain hardware will spawn, replacing companies likeArm and democratizing data farms produced by Google and Apple.

However, many problems still exist within each domain that prevents the devices from becoming intelligentand for interoperability to exist between dissimilar device types. To create the intelligent machine economy,three verticals in IoT need to be addressed.

1.3 Internet of ThingsInternet of Things, known as IoT, refers to the evergrowing amount of devices connected to the Internet suchas self-driving cars, smartphones, wearables, smart cities, airplanes, and computers. The estimated numberof devices increases 31 percent every year, with a projected 200 billion new devices entering the ecosystem by2020.10 Though Internet of Things is often said to be the fourth industrial revolution and has the potentialto automate and transform our lives now, there exists three main problems with IoT withholding its fullpotential: connectivity, intelligence, and functionality.

1.3.1 Scalability

In order to connect all devices. scalability is needed to handle the explosive growth in IoT where applicationswill need to support an increasing number of devices, analytics, data, and users. The majority of currentdevices are controlled in a centralized manner where devices connect to back-end cloud infrastructures ordata centers. As a result, current scalability methods will be ineffective as billions of devices are connected.Current methods lack:

1. Decentralization - Current centralized have brokered communication models where devices are con-nected, identified, and send data through a cloud model. Cloud servers will remain a bottleneck andcontain a single point of failure that can disrupt a network.

10https://www.intel.com/content/www/us/en/internet-of-things/infographics/guide-to-iot.html

8

2. Efficiency - Current devices have limited bandwidth, computational resources, memory, and resourcesto handle complex tasks.

3. Privacy - Conventional ways to maintain privacy include adding noise or summarizing data whencommunicating with the server. Existing approaches welcome privacy threats through localization,identification, MITM attacks, profiling, and data leakage.

Current scalability methods limit the potential adoption and real-world applications for the massive influxof Internet of Things devices.

1.3.2 Intelligence

Machine intelligence is needed to specialize in IoT devices in each aspect, from Go playing computers to self-driving cars. Despite breakthroughs in the field of deep learning algorithms that have enabled human-levelperformance on perceptual tasks and created novel algorithms ranging from capsule networks to echo statenetworks, the bane of machine intelligence and real-world applicability for IoT can be found in training dataand hardware acceleration.

Data A vital component for training neural networks is data. Data makes it possible for machines to learnto adjust to new inputs and perform perceptual tasks with human-level performance. However, data is sovaluable that large corporations hoard and tightly guard data. Current issues with data include:

1. Private Data - Personal or confidential data such as medical, personally-identifiable, and education-related data are illegal to share and thus cannot be trained.

2. Centralization - Large corporations like Facebook and Google are collecting vital data off users andIoT devices and storing it for internal use.

3. Knowledge Domains - Models are not generalizable, and as a result, there exist too many data typessuch as sound, image, and 3-D images scattered across various databases.

4. Incentive - There are no methods or incentives for people to monetize and share data that they collectfrom devices.

Hardware Specialized hardware is needed to provide the functionality to support tasks that typicallyrequire human cognition and learning on the hardware itself rather than on servers. As the complexity ofnetworks grows, larger devices are needed to train it. For smaller devices, it becomes too computationallytaxing to train or retrain neural network layers. Some issues with AI hardware might include:

1. Large Processors - Current machine learning systems and applications typically consist of a very power-ful workstation outfitted with very high-performance GPUs that serve as a centralized training machineto run neural network backpropagation algorithms.

2. Processing Power - Implementing deep neural networks on edge devices will be a hurdle. Training onCPUs will not function properly as they lack neural and matrix acceleration optimization on the edge.

3. Design - Conventional hardware is not designed to run brain-like algorithms and fully utilize artificialneurons.

4. Blockchain - Hardware is not optimized for blockchain networks and may not support the safe usageof cryptocurrencies.

9

1.3.3 Functionality

The value and functionality from IoT devices come from the interactions, learning, and cooperation betweenother autonomous devices. Simply being connected does not bring many benefits to an IoT device as mostsolutions today lack meaningful applications. Even so, a staggering 85 percent of IoT devices cannot interactwith one another because of compatibility issues.11

2 Skynet Overview

By creating a neural processing core optimized for the blockchain and its native blockchain network, OpenSin-gularity can address the major problems with the Internet of Things to enable these devices to become bothconnected and intelligent. This section will detail why blockchain can be used for IoT, Skynet’s designprinciples to enable the intelligent machine economy, and deployment strategy.

2.1 Architectural Benefits of Blockchain for IoTThe blockchain is a public, immutable, distributed ledger technology that can be used for transacting withdata in a distributed and decentralized manner. For a review of blockchain technology see our appendix.

Table 1: Blockchain vs. Database ComparisonBlockchain Centralized DatabaseDistributed Single Failure PointMachine to Machine Middlemen and GatewaysDecentralized Single Point of ControlImmutable Audit Record No RestrictionsTrustless TrustPublic or Private Permissoned

The table above examines the differences between standard centralized databases and blockchains. Asshown, the properties of a blockchain such as its trustless nature, decentralization, and immutability describedbelow provide advantages for the Internet of Things devices.

Decentralization As quoted by Vitalik Buterin, "Blockchains are politically decentralized (no one con-trols them), architecturally decentralized (no central infrastructural point of failure), but they are logicallycentralized (there is one commonly agreed state and the system behaves like a single computer)."12 In thismanner, blockchains offer a decentralized, trust-less way for interconnecting devices and exchanging value.Decentralization takes away the trust, power, and liability away from large corporations and transfers itback into the self-regulating open community. In consequence, blockchains may reduce transaction fees andenable instant feeless microtransactions by taking away the middleman, such as Western Union or Paypaland additional overhead. Decentralization will also help address the problem of privacy and data concerns

11https://www.artik.io/iotindustry12https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274

10

imposed by companies that monopolize the market by providing an open environment devices can freelyconnect to and directly interact with one another over.

Immutability Data posted on the blockchain is immutable, providing transparency and audibility for alldevices that make a transaction over the network. Immutability can be useful in many scenarios as it preventssomeone from tampering with the data and enables everyone to query the chain to access applications suchas authentication, timestamps, audit trails, and identity management.

Programmability Programmability on the blockchain in the form of smart contracts enables device au-tonomy where trustless exchanges between devices can happen that are verified through the code and othernodes. Programmability can be extended to IoT devices, which are usually static, and enable various ex-changes and interactions between them.

Security Networks that run on the blockchain are fault tolerant and can withstand node failures. WithByzantine fault-tolerant models, components are allowed to fail in the system if their local state becomescorrupt, their connection breaks, or if their outputs are malicious. The fault tolerance system operates wellin the real world where nodes in the system may behave in unexpected and unpredictable ways. As a result,many desired networks security aspects can be achieved with byzantine fault tolerance such as defendingagainst MITM attacks and DDoS.

2.2 Application Benefits of Blockchain for IoTBlockchains bring many application benefits which will be discussed later in the Skynet Open Network. Justa few applications that a blockchain and its programmability would bring in IoT would be:

1. Distributed Computing - Machines can distribute workloads and share resources such as computation,memory and storage on edge, while being rewarded for the amount that they delegate.

2. Federated learning - Machines can train off private data without ever sending it, leaving training datadistributed while improving models’ accuracy.

3. Cryptocurrency - A instant and near-feeless digital currency can be used as a way to pay for data andalgorithms while providing incentives for others to share it.

4. Secure Interactions - Devices can develop a reputation based on previous transactions and start toself-organize and use peer-to-peer discovery clients to interact with non-malicious nodes.

5. Data Sharing - Data can be securely sent off the chain and be hashed on the blockchain.

6. Imitation learning - Machines can teach one another the correct policies during training.

7. Smart Contracts - Developers can code their own contract in which devices are forced to obey.

For example, applications such as distributed computing will address problems with limited processingpower on the edge; federated learning will address some problems with untapped data and allow devices tobe compliant with data consent and security laws; digital currencies can be used to exchange value and data,encouraging nodes to participate in the network ecosystem. More applications will be covered later.

11

2.3 Problems with Blockchain Networks for IoTDespite all the benefits of blockchains, current networks come with a big computational overhead and lowfinality. Network architectures cannot handle billions of interactions that IoT devices make every day,and do not support adoption in the real world. Older network architectures like Bitcoin or Ethereumare based on principles such as the Proof-of-Work consensus and "One Blockchain, Many Applications"design. Blockchains that grew from these older principles have a low transaction rate (7-20 transactions persecond), high transaction cost (.70 cents), try to fit in many applications in one chain, and have nodes doingcomputationally expensive useless work. These blockchains also cannot interact with one another as theyfocus on their own applications rather than working together. Even newer DAG solutions have heavyweightoperations, where sending a transaction forces small devices to do proof of work. As a result, traditionalblockchains and even newer versions are not suitable for IoT Devices. For example, smaller IoT devices suchas sensors and wearables might be incapable of:

1. Proof of Work Mining - Smaller devices cannot be turned into miners as they face computation andpower restraints.

2. Storing Data - Training data and chain data cannot be stored on devices as they face memory andstorage restraints.

3. Connectivity - Devices in rural areas might face latency issues and will not be able to have a steadyconnection.

4. Running full nodes - Devices cannot verify full blockchains as downloading a whole chain might requireupwards of 50 gigabytes of storage.

5. Ternary Operations - No CPUs can work with DAGs or Blockchains with ternary operators.

6. Cold Storage - With IoT devices getting hacked from things like BotNet, devices cannot safely storeor utilize cryptocurrency.

As a result, some deep learning distributed applications and blockchain operations might not be suitable forthe Internet of Things devices.

2.4 Blockchain Adoption ProblemIn addition to architectural problems, all cryptocurrencies face adoption issues, and the space is highlyspeculative. Bitcoin and Ethereum have valuations of 131 billion and 60 billion respectively (as of June 2018)because they are the most adopted networks in the space despite their underlying technology. However, nocryptocurrencies can gain widespread adoption because of their design and the underlying infrastructure.For cryptocurrencies and blockchain technology to start gaining adoption, they must be:

1. Efficient - Transaction fees should be minimal, have low confirmation times, and be energy efficient.

2. Legacy Compatible - Blockchains or DAGs need to be compatible with current systems such as currentCPUs and hardware.

3. Private and Secure - Blockchains should be flexible (public or private) to meet related IoT tasks athand.

12

4. Simple - Blockchains and their respective cryptocurrencies should be simple to use and seamless.Converting crypto to crypto in exchanges is a complex task for the layman.

5. Safe - With cryptocurrency exchanges and hot wallets getting hacked, the cryptocurrency someoneuses is not retrievable.

2.4.1 Hardware Wallet

The creation of the hardware wallet was to address the security aspect of storing cryptocurrency. Theprinciple behind hardware wallets is to isolate private keys from easily hackable IoT devices. Hardwarewallets, at this moment, are the only secure way to store and utilize large amounts of funds. Hardware walletsare extremely safe from attacks and they store private keys that are retrievable through seeds. Current formsof hardware wallets include the Ledger Nano S or the Trezor Model T. However, these hardware wallets arein the form of a USB stick, which is unusable for IoT devices such as parking meters, smartphones, orintelligent bikes. The security of a hardware wallet and the convenience of a hot wallet is needed for IoTdevices and for cryptocurrency adoption to grow. Even with the development of recent security measuresuch as Arm’s Trust Zone, the cryptocurrencies are still hackable if a hacker can read the device’s memory.

2.5 Addressable Network Solution DesignSON (Skynet Open Network) aims to connect IoT devices and provide the infrastructure for an intelligentplanet. To achieve this goal, SON’s design is configured to achieve:

Anarchic Scalability Given the evolving chaotic nature of Internet of Things, SON’s architecture mustbe designed for anarchic scalability and must constantly evolve to fit the IoT ecosystem. For example,as the complexity of IoT grows, varying systems must be included to support billions of different IoTlinks, interactions between autonomous entities, and new entities joining the system without risking failure.Subsystems and permissoned subchains will also most likely need to be added to increase privacy, control,and reliability in spaces like military or healthcare fields.

Separation of Duties One blockchain addressing all applications is a very inefficient design of IoT devices.Having all devices connect to a single blockchain limits scalability and makes the chain very heavyweight.An ideal solution would be to allow multiple different blockchains to be created with different use cases andenable these networks to interoperate with their own governance properties.

Portable With all different device types and existing hardware, SON should be able to be used in smalldevices such as sensors, existing CPUs, and adaptable to new hardware. Operations on the blockchain shouldbe configured and optimized towards the device type, enabling smaller devices with lower power and memoryto participate in the consensus while allowing more-capable devices to run full nodes.

User Friendly For adoption to grow in blockchain technology, SON will need to have a simplistic, devel-oper and user-friendly design. Blockchains and smart contracts on SON should be able to be created easilywith any programming language and with minimum validator nodes. The resulting blockchain should stillbe a low latency, a high finality, and a high throughput network. The conversion process from the resultingcryptocurrencies should be seamless from one chain to another.

13

2.6 Application Solution DesignRather than solely providing the infrastructure, SON will need to be designed to provide the applicationsto enable devices to create the intelligent machine economy. To achieve this vision, SON’s application isconfigured to allow machines to be or do:

Connected SON will need to enable all devices to be able to find one another, self organize, lend com-putational power, and have ways of exchanging information and value with one another in an instant. Asdevices in the network might be malicious, security implementations must be in place to allow devices onlyto interact with positive nodes and cleanse the negative ones from the network.

Autonomous SON will need to enable all devices to become intelligent and autonomous. Data and pre-trained algorithms will need to be distributed across all devices, and devices will need to have ways to learnnew situations, even out of private data.

Manageable SON will need to provide audit trails or ways for human owners to manage their devices incases when they are not acting or functioning properly. SON would also need to provide owners the ability toadd permissions to the data that their devices share and the amount of identifiable information they wouldwant to provide in the network.

Blockchain Versatile SON will need to connect to all blockchains to enable devices to choose the networkthat they would want to utilize. As new solutions might be developed on other networks, machines shouldhave the choice to use whatever network suits them at the time.

2.7 Addressable Hardware Solution DesignTo provide the backbone for the intelligent machine economy, Skynet Core will need to be designed to enabledevices to utilize the blockchain and have human-like functionality. To create the real-world infrastructurefor blockchain adoption and machine intelligence, in addition to standard SoC and CPU cores, Skynet Coreis designed to provide:

AI Acceleration Skynet Core will need an added Tensor Processing Unit or Neural Processing Unit toaccelerate AI learning and model execution speeds. AI acceleration hardware will be necessary to train theseIoT devices to become intelligent or retrain them for new situations in low power devices.

Hardware Wallet Skynet Core will need hardware wallets embedded in them with the same functionalityas the Ledger Nano S or Trezor Model T, but with added AI authentication and an automated permissionsystem. IoT devices that already have an embedded cold storage hardware wallet will remove the need ofthe billion dollar USB wallet industry.

Blockchain Acceleration Skynet Core will need hash accelerators to run a fast public or private blockchainnetwork and maintain the state of the headers.

Scalability Skynet Core will have a modular design that can easy to scale to billions of devices, fromautomobiles to trains to computers to smartphones.

14

2.8 Skynet ProtocolOpenSingularity aggregated all the design propositions into Skynet, a safe end-to-end, distributed artificialintelligence system that will foster collaboration and intelligence between all the devices in its network. Toaddress both the adoption of cryptocurrency and limitations of intelligence in hardware, Skynet is com-prised of Skynet Core, a neuro-processing blockchain chip. To address the scalability, overhead, and limitedapplications in traditional blockchain networks, Skynet is also comprised of SON, an infinite-blockchainnetwork.

Figure 1: Skynet System

Shown in the diagram above, the Skynet Open Network and Skynet Core work in parallel to providethe infrastructure for devices to become intelligent and collaborate over. Skynet Core provides the securityand intelligence that IoT needs while SON provides the applications necessary for these cores to securelycommunicate and transact over.

2.8.1 SON Overview

SON is a solution addressing all the problems with existing blockchain networks while providing the capacityto support billions of machine to machines interactions. The underlying protocols and details regarding thenetwork can be found here, but this section covers a high-level overview of the network and how it addressesexisting problems with the Internet of Things.

Architecture Overview Compared to previous blockchains, SON is an infinite-chain network that enableseach high-throughput chain to address a single application, while still working together. Interoperable publicand private networks in SON will help address the chaotic subsystems in IoT devices where many devicetypes of various permission levels can exist in the network.

15

Table 2: Architecture ComparisonProperties Bitcoin Ethereum Skynet Open Network

Consensus Proof of WorkProof of Work(Future PoS)

BFT Proof of Stake

Sharding NoneNone(Future Two-Level)

Horizontal IoT Chains

Chain Type Heavyweight Heavyweight LightweightTransaction Speed 7 TPS 15 TPS 1 Million+ TPSTransaction Fees 1 Dollar .45 <.01Token Bitcoin Ether Multi-AssetBlock Size 1 MB Dynamic DynamicBlock Confirmation 10 Minutes 14 Seconds 1 SecondLanguage Script Solidity Any (Solidity, GO)Runtime Architecture Bitcoin Core EVM Any VM (EVM, QVM)

Table 2 demonstrates how in comparison to slow and heavyweight traditional blockchains, SON achievesa high transaction speed of one million plus TPS to support Internet of Things applications. Whereasstandard blockchains have a single chain to address multiple applications, SON’s architecture enables manyeasy to create, high throughput Proof of Stake blockchains that address a single application while still beinginteroperable with one another. By powering all the SON blockchains with an optimized Byzantine FaultTolerance consensus, each blockchain can then easily handle thousands of transactions per second with aslittle as 4 validators. These blockchains would also be able to communicate with one another through amodular framework called Skynet Open Network, Fabric and through the network, are able to send datapackets such as tokens from one blockchain to the other.

Figure 2: Independent Blockchains

For example, with cross-blockchain communication enabled by SON Fabric, validators could then validateother blockchains, a decentralized exchange can be created, and nodes in the network would be able to access

16

other sovereign blockchains like EOS or Ethereum. With the effective multi-chain design, each blockchaincan be used to address a different application with their own virtual machine and varying permission levels.

Figure 3: SON Horizontal Scalability

All of these individual networks would then be able to scale out indefinitely, as transactions capacitycan be multiplied if one decided to create a separate identical blockchain. In the figure above, each chaincan handle an approximate 10,000 transaction per second throughput. To achieve greater scalability, threemore distributed replicated blockchains can be created and work in parallel with the existing blockchain.With four blockchains working together, the combined transaction per seconds can be 40,000. An infiniteamount of more blockchains can be created to handle more transactions if needed. With a sharding protocol,blockchains can now be used for IoT devices as they can scale to millions or billions of transactions per secondto handle many types of interactions needed from the network.

All nodes would also be able to participate, as SON’s network design is designed to support light clientsas small devices do not have to store transactions locally.

In summary, the architecture key features could be presented as such:

1. Delegated Proof of Stake - SON uses a Tendermint Byzantine Fault Tolerant Delegated Proof of Stakeconsensus, enabling thousands of transactions per second per chain.

2. Scalable Platforms - SON contains a scalable Proof of Stake blockchain platform, distributed applicationplatform, and decentralized identity platforms.

3. Communication Protocols - SON uses a cross-blockchain communication protocol to connect networkson SON together.

4. Decentralized Exchange - SON networks could autonomously exchange tokens with one another withoutgoing through standard exchanges such as Coinbase or Gemini.

5. Infinite Sharding - SON allows blockchains to split into two to double transaction capacity.

6. Two Dimensional Blockchain - SON allows blockchains to be infinite networks of their own, makingthe structure highly flexible.

7. Cross-Network Communication - SON contains protocols to connect the network to others such asBitcoin, ZCash, Ethereum, and Neo.

17

8. Instant - SON’s consensus enables sub-second finality, near-feeless, low latency, and high throughputtransactions.

For more details, comparison tables can be found in the SON comparison tables section, and underlyingframeworks can be found here underlying framework section.

Application overview SON is truly end-to-end with native protocols and applications supporting thecreation of the intelligent machine economy. With the underlying architecture mentioned in the sectionbefore, each application on SON is designed to support interactions between many IoT devices. In summary,the key applications SON is natively designed to support are listed below:

1. Identity Protocols - Nodes will be able to safely interact with reputable nodes and find one another insimilar knowledge domains.

2. Fine Tuning - Nodes will be able to fine tune their neural networks and exchange knowledge by utilizingtransfer learning and variations of imitation learning.

3. Federated Learning - Nodes will be able to train off private data and collaboratively work together,similar to ensemble learning, to improve their neural network.

4. Data Transport - Nodes will be able to distribute data and algorithms throughout the network.

5. Distributed Computing - Nodes will be able to lend spare computing power to one another, makingthis method cheaper than using AWS or Google Cloud.

6. Device Management - Node owners can manage their autonomous devices with the help of a publicdistributed ledger.

7. Digital Currency - Nodes will be able to use a fast IoT currency to settle payments between one anotherand to pay fees on the network with any token that they choose to use.

8. Marketplace - Nodes will be incentivized to share data and algorithms if they are paid for their services.

9. KnowledgeNet - Nodes connected to the network will most likely contain possible training data fromplaces like ImageNet, hospitals, or new datasets that they can share and enable others to learn.

Nodes in the network will also be able to access any applications on other networks such as Polkadot,EOS, and Ethereum with SON’s cross-chain communication. With these infinitely scalable applications onSON, devices are truly connected and will have the functionality to interact with one another as people donow.

2.8.2 Network Comparison

Skynet Open Network is the only end-to-end platform enabling a machine economy. With hardware thatcan be integrated into every IoT Device and a network that enables interactions between billions of IoTdevices, SON will attempt to address the existing problems facing blockchain networks, device intelligence,and distributed applications. SON’s main advantage is the ability for the network to gain instant widespreadadoption through Skynet Core’s license-free core design and provide the applications enabling the intelligentmachine economy to be created. Although there are many underlying frameworks and cryptocurrencies on

18

SON mentioned here, the various underlying networks in this section will be bundled up into SON for thesake of clarity. The network delves into many different comparable areas and protocols to create this trueend to end system.

Table 3: New Generation Architecture ComparisonProperties Telegram Cosmos SON Polkadot ICONConsensus PoS BFT PoS BFT PoS PoS LFTInteroperability No Yes Yes Yes YesVM Blockchain Yes Yes Yes No NoScaling Infinite Infinite Infinite Infinite 9000Type End-to-End Platform End-to-End Platform PlatformPotential Adoption High Low High Low MediumVertical Messaging Interoperability End-to-End Interoperability Interoperability

Future currencies such as Polkadot, Cosmos, and Telegram paint the ideal next-generation architecturethat blockchains should have. With their tradeoffs shown in the table above, SON has adopted an architecturesimilar to Cosmos but with the same end-to-end nature of Telegram. Whereas Telegram provides their 200million users with software wallets, SON will provide billions of IoT devices with hardware wallets andcurrencies. As a result, both networks are end-to-end with end user devices and people, enabling large-scalereal world adoption. Compared to other infrastructures, the SON network puts its focus on IoT and artificialintelligence with novel distributed applications and identity protocols supporting the end-to-end creation ofthe intelligent machine economy.

Table 4: Currency ComparisonProperties IOTA IoT Chain SON NanoConsensus Tangle Block-DAG Delegated Proof of Stake Block LatticeFees Hidden Fees Near-Feeless Near-Feeless Hidden FeesTheoretical TPS 1400 (Infinite with Swarm) 100,000 Infinite 7000Transaction Speed 30-120 seconds seconds 1 Second 1 Second 1 SecondPotential Adoption Medium Low High LowData Transport Yes Yes Yes NoSimple Payment Verification No Yes Yes YesIoT Usability No Yes Yes NoArtificial Intelligence No No Yes No

SON contains a native IoT currencies, which can be compared to existing DAG or block-DAG curren-cies. Currently, with IOTA all transactions go through an object called a coordinator, making the networkcentralized and containing a single point of failure. As there aren’t enough full nodes currently running and

19

with the coordinator providing a huge bottleneck, the network has not met the demand of people sendingthe currency to and from one another. IOTA also uses Ternary operations and requires a special processorto run on top of the CPU, and with smaller devices such as sensors, they will not have the capacity toperform Proof of Work when sending something as little as data out. Because of these issues, IOTA hasfaced a hard time being implemented in the real world. IoT vendors are unlikely to adopt new Ternaryprocessors such as Jinn, and the IOTA network is still facing serious scalability problems. Another downsidewith Directed Acyclic Graph related architectures is that they have hidden fees where the electricity costmakes up for the cost of regular transactions. In contrast, SON is decentralized, can run on any CPU, andonly requires four validators to run a high throughput network. As a result, SON allows for highly efficientIoT light clients, provides the IOT end-to-end applications and infrastructure to make machines intelligent,and enables near-feeless subsecond transactions between devices without relying on the number of users tomaintain the network.

On the other hand, IoT Chain created its architecture based on IOTA but with a hybrid blockchainimplementation. In the process, the currency limited its scaling potential while adopting major issues fromthe DAG currency. Compared to cryptocurrencies like IoT Chain, SON handles the transaction per secondlimit through infinite sharding, allowing the network to scale through an infinite amount of other chains. Asmany other devices enter the network, both Nano and IoT Chain lack the scalability to handle the transactioncapacity. Nano’s currency design is efficient but lacks the ability to transfer data, thus making it unusablefor IoT devices.

Table 5: Delegated Proof of Stake ComparisonSON Consensus EOS Consensus

No. Of Validators 4 to Infinity 21Mean Block Time 1 - 3 Seconds 3 - 40 SecondsScalability Horizontal with IoT Chains Small number of delegators with high throughputBFT% 1/3 1/3Accountability Identification and Bond Deposits Reputation and Job LossDevelopability Any Programming Language Mainly for Developers

SON uses a fast BFT Delegated Proof of Stake consensus. The table above shows a comparison of Proofof Stake consensus with a third-generation blockchain distributed application infrastructure, EOS. As SON’sconsensus is horizontal scaling and faster than EOS’s consensus, SON can be used for infinitely scalingand fast distributed applications. Compared to EOS, SON can be interoperable with existing distributedapplications platforms such as Ethereum and other blockchains.

Regarding SON’s distributed applications, the combination work together to make a truly end-to-endsystem. Most existing IoT related distributed applications face no real adoption, do not function togetherand face scalability issues with their reliance on Ethereum. To make devices autonomous and intelligent,the SON Virtual Application Layer, which is discussed later, combines the benefits of existing distributedapplications in addition to new protocols to make the whole system autonomous and infinitely scaling. Inthis manner, devices can autonomously settle prices without having a human do the work and based ona proprietary algorithm, devices can self organize to train without the overhead. The current distributedapplications are also heavily dependent on Ethereum, which can only support around 20 transactions persecond. Fully implementing Plasma protocols and Ethereum’s variant of sharding is still a ways away, which

20

makes the systems currently unable to support the transaction capacity of IoT devices interacting with oneanother in each application. However, if a new distributed application supporting novel functionalities wereto be developed, SON has the capacity to include it within the SON Virtual Application Layer.

2.8.3 Skynet Core Overview

Skynet Core is the first ever blockchain core with added AI processing in the forms of TPUs or NPUs. SkynetCore is designed to enable the usage of cryptocurrencies and blockchain networks in IoT devices and enablethe capacity of those devices to become intelligent and connected. What Skynet Core’s IP cores contain toenable these applications are:

1. Central Processing Unit - Skynet Core contains standard Risc-V ISA Processor for running standardapplications.

2. Blockchain Hardware - Skynet Core contains blockchain optimized hardware such as crypto enginesand hardware wallets.

3. Neural Processing Unit - Skynet Core contains neural processing units or possibly tensor processingunits to accelerate matrix multiplication and AI learning to enable devices to utilize the features ofdeep learning and neuromorphic computing.

The software running top of these IP cores include:

1. Applications - Skynet Core contains software that supports wallet applications, biometric user authen-tication, and blockchain distributed applications

2. Services - Skynet Core contains support for SON’s KnowledgeNet and identity networks.

3. Communication - Skynet Core contains chip-to-chip communication protocols.

4. Optimization - Skynet Core contains optimized solutions for machine learning algorithms and applica-tions.

5. Self Learning - Skynet Core enables devices to learn its own hardware and optimize the solutionsthrough a blockchain network.

6. Security - Skynet Core contains the highest security certifications.

Both the cores and the software will enable devices to have support for:

1. Hardware Wallet - Skynet Core contains the functionality of a Ledger or Trezor and embeds themwithin devices, completely removing the need for USB wallets. When the wallet is not used, the corewill always be turned off with a separate power management component, enabling cold storage untilan AI-powered trigger (eg. biometrics) allows it to be turned back on.

2. Blockchains - Skynet Core devices will be able to run high-speed public or private blockchains andfully utilize their applications with hash accelerators and blockchain engines.

3. Infinite Scalability - Skynet Core would be able to be embedded into every device with a modularintegrated circuit design.

21

4. Accelerated Learning - Skynet Core’s tensor processing matrix multiplication processors will allow fornew types of deep learning and neuromorphic processing applications.

As a result of these cores, Skynet Core will be scalable and enable devices to use the applications thatSON can provide fully.

2.9 Skynet Adoption PlanOpenSingularity believes that there is a need for an alternative to ARM in the IoT semiconductor industry,and by bringing a license-free Blockchain Brain Chip IP core and open source RISC-V ISA architecture designto the semiconductor industry, OpenSingularity will enable many companies to design high performanceand energy efficiency consumer ASICs at a reduced cost. OpenSingularity’s RISC-V AI blockchain corelicense-free model will provide a free competitive alternative with added features of coupling devices with ablockchain network and a brain-on-chip system. With the license-free business model, companies and SoCdesigners will be able to use a similar core with the same functionalities but optimized for the blockchain.

However, a license-free business model would only work with cryptocurrency, as the adoption of the corewill drive up utility and price of the network token. By creating the SON network, OpenSingularity willhave the ability to replace ARM’s licensing business to hopefully provide billions of cores to IoT devicessuch as smartphones, self-driving cars, and sensors by 2035. Each of these cores will then come with a SONhardware wallet and some of the cryptocurrencies on the network, so devices could immediately utilize SONand through it, other blockchains. The Skynet core will default to the SON network, its hardware wallet,and software for all cryptocurrency transactions, enabling SON to act as or used for:

1. A central hub to access all other blockchains

2. App store of blockchains where all other or new distributed applications can be created or paired on it

3. Central decentralized platform for all machine learning

4. Transfers of value between devices

By embedding SON tokens and a hardware wallet with all the Skynet core, OpenSingularity will providean instant real-world adoption of the SON network, all cryptocurrency networks, and the Skynet protocol.

2.10 OpenSingularity FoundationLeading the Skynet project and its development is the OpenSingularity Foundation, a non-profit organizationlocated in Singapore. The collective vision of OpenSingularity is to create the intelligent machine economywhere devices can transfer knowledge, learn, communicate, and interact with one another without humanintervention and centralized control. OpenSingularity will seek to create the first ever blockchain core andits native blockchain network. In the process, the IoT blockchain core can replace ARM and its dominanceon the chip industry, all while providing the real world infrastructure for devices to become intelligentand use the utility of blockchain networks. Creating the network will enable SON to become the newinternet of blockchains and artificial intelligence, linking together all intelligent entities and all blockchainsunder one decentralized system while solving all the existing issues with scalability. In Skynet’s end-to-endsystem, billions of IoT devices within the next few years will enter a single decentralized ecosystem to begininteracting with one another and to begin a recursive learning process. By creating Skynet’s SON network

22

and Skynet core, OpenSingularity will attempt to address all the existing problems with blockchain andartificial intelligence to make the intelligent machine economy a reality.

Leading the Foundation are visionaries in each area.Alexander Shi, Founder, University of California Berkeley, is a leading visionary in artificial general

intelligence and blockchain technology. His work with deep learning algorithms have been featured in thefront page journals such as Cell Magazine and Nature SIGTRANs, and he was the inventor of the IP behindthe Skynet Core and Network.

Dr. Carl Shi, Director, University of California, San Diego, is one of the world’s leading inventors. Carlwas the former Vice President of Qualcomm where he invented over 400 patents and led the commercializationof their Snapdragon Processors. There, he also helped form joint ventures between Qualcomm and Chinesecompanies and was an inspirational leader for Qualcomm startups.

Dr. Jae Jung, Director, University of California San Diego, is the leading expert in hardware develop-ment. He served as the Vice President of Samsung Electronics and sold his former company NeoPace to oneof the largest memory chip companies.

Professor Jun Zhang, Director, University of Nanjing, is one of the world’s leading researchers. Jun wasa Professor of Artificial Intelligence and the Nanjing Hohai University and the head of the social computinglab there. He was awarded the provincial award for philosophy and social science.

These directors are leading the development of the OpenSingularity Foundation’s core and networkinfrastructure. Overseeing the intellectual property rights of the foundation is Morrison and Forrester.Overseeing the legal practice is Dentons Rodyk. Auditing the operations is James Chan and Partners LLP.With over twenty other members ranging from Google Ventures, Microsoft AI, Qualcomm NEO, Paypal’sBlockchain Lab, and top university research labs, OpenSingularity will be able to create a fully functioningintelligent machine economy to connect all blockchains, AI, and IoT devices.

2.11 TermsIn this section, OpenSingularity defines specialized terms used within the document.

Cross-Blockchain Communication Inter-Blockchain Communication or IBC refers to the protocol thatallows for the exchange of tokens and information across sovereign blockchains.

Entangled Chains Entangled Chains are a Cross-Blockchain Bridge or a decentralized exchange betweenSON and other blockchain networks.

KnowledgeNet the KnowledgeNet is a protocol comprised of the identity networks and all distributedapplications on SON to enable the exchange of training data and computational power.

Light Light is the native fee token on the Skynet Open Network.

Neuro-Crypto Brain on Hardware system to protect private keys and facilitate distributed applications.

Neuromorphic Hardware system that contains on-chip synapses to mimic neuro-biological parts of thehuman nervous system.

Nova Nova is SON’s Decentralized Application Platform that allows the development of machine learningsmart contracts.

Onyx Onyx is the decentralized artificial intelligence marketplace of all chains on SON.

23

RISC-V Set of open-source instruction set architectures and designs for processors

Skynet Core Skynet Core is the name of all variants of the blockchain chip.

Skynet Open Network Skynet Open Network is the collective network of all the blockchains, protocols,and smart contracts.

Skynet Open Network, Fabric SON Fabric is Skynet Open Network’s root multi-chain blockchain thatallows for the creation of blockchains and exchange of tokens between networks.

Skynet Open Network, Idem SON Idem is Skynet Open Network’s decentralized identity Network.

Skynet Open Network, Nova SON Nova is Skynet Open Network’s distributed application platform.

Skynet Open Network, Singularity SON Singularity is Skynet Open Network’s virtual application layerthat interfaces with the Skynet Cores.

Skynet Skynet is the system that will enable a new era of machine intelligence by combining the componentsof SON and Skynet Core

3 Skynet Core

In the previous section, we discussed an overview of how the Skynet system provides an end-to-end devel-opment platform for IoT applications. In this section we will describe a modular set of hardware IP blockstailored for optimally running SON on embedded "edge" IoT devices—that is small devices that serve assensor or actuators, sit at the edge of the network and are mostly characterized by their low cost and lowpower budget. In particular, through a combination of cryptographic helpers running a high-security liteblockchain client, an AI accelerator for perceptual tasks and an embedded CPU, Skynet Core will becomethe ideal platform for IoT OEMs to develop and deploy their applications and devices. Skynet Core will bedistributed via a license-free arrangement to System-on-chip (SoC) manufacturers for them to integrate itinto their offerings, reducing cost and accelerating adoption.

24

Figure 4: IoT Architecture with an Skynet Core

The Skynet core consists of three main components: An ARM or RISC-V based CPU to host a Linuxkernel an interface with peripheral devices; A secure Crypto-engine for storing private keys, singing messagesand performing any other cryptographic computations required to operate any blockchain efficiently and inparticular the SON blockchain; A Neural Processing Unit (or NPU) to accelerate the linear algebra operationsrequired by modern neural networks such as DNN, CNN and RNNs.

3.1 CPUTo host a modern Linux operating system (such as Ubuntu) for the SON blockchain to run on, OpenSingu-larity will include a set of modular processors in the Skynet Core. The RISC architecture of ARM processorachieves a simple design, fast clock rate, small die sizes and efficient memory usage with a developmentpipeline for new SoCs or IP blocks with trusted IP, expert design support, and leading software tools. ARMoffers a product range ideal for the requirements of IoT devices where modern versions feature a system-wideapproach to security–TrustZone. Initially, we will target integrating processing cores from the ARM Cortex-M family for low-power embedded applications and the ARM Cortex-A 64-bit family of high-performanceprocessors for high-end applications. This arrangement is based on the feedback from our developmentpartners, and IoT devices require low power and small footprint. The ARM ecosystem provides the AMBA(Advanced Microcontroller Bus Architecture) to interconnect the multiple peripherals (IO, coprocessors andmemory controllers) required to build a modern processing unit; and multiple vendors provide these trustedperipherals for a wide variety of process nodes. Finally, the extensive penetration of ARM has created avibrant and tested community that support the entire software stack of bootloaders, kernels, drivers, distros,libraries, applications and software development tools such as compilers, profilers, and debuggers. As theSON Blockchain comes online and prototype blockchain applications start development, we will characterize

25

the computational workloads to decide if we will include the necessary NEON-SIMD and FPU accelerators,and which peripheral to incorporate.

Nevertheless, OpenSingularity is diligently exploring the alternative of developing a custom processorbased on the RISC-V open-source ISA as it—and the surrounding ecosystem—reaches practical maturity.Recent implementations of RISC-V core show promising results with smaller die size and better performancecompared to ARM processors (BOOMv2 vs. ARM Cortex-A9). RISC-V may provide an alternative toARM’s monopoly, resulting in a very cost-effective Skynet Core because the licensing fees to ARM wouldbe eliminated, and this cost-saving could be passed on to SoC manufacturers as an incentive to accelerateadoption. We will monitor the progress of the RISC-V ecosystem expansion and decide as to which CPUcore as a base of the Skynet Core. Similarly, to accelerate development of the entire software stack, OpenSin-gularity will partner with early SoC manufacturers to develop the whole integration stack as required by theapplications.

3.1.1 Arm Architecture

ARM is a reduced instruction set computer (RISC). As a RISC, ARM aims for a fixed length, simple butpowerful instructions that execute within a single cycle at high clock speed. As a RISC architecture, ARMis based on a number of principles to achieve simple design and fast clock rate. A pipeline is designed to bedecoded in one stage with no need for microcode. A large set of general-purpose registers are defined for fastexecution of instructions. ARM adopted load/store architecture, where data processing instructions applyto registers only and load/store scheme is used to transfer data from memory. However, there are a fewdifferences from pure RISC. ARM adopts variable cycle execution for certain instructions such as multiple-register load/store to achieve faster and higher code density. Inline barrel shifter improves performance andcode density but leads to more complex instructions. ARM added Thumb 16-bit instruction set which leadsto about 30 percent code density improvement. Conditional execution is added to improve performance andcode density by reducing branch. Some enhanced instructions are added for DSP operations.

3.1.2 Goals of RISC-V ISA

An Instruction Set Architecture (ISA) defines, describes, and specifies how a particular processor core works.Existing ISAs such as x86-64, Arm are proprietary and very complex. The details are often obscured inlengthy manuals and some details of the ISA are not made public at all. Furthermore, the widely used ISAshave been around for years, and their designs carry baggage as a result, e.g., for backward compatibility.Proprietary ISAs are owned, managed, and controlled by corporate entities like Intel, and ARM Holdings.The RISC-V project came out of UC Berkeley to address these issues. The open-source approach takenby RISC-V means that many different companies can provide hardware implementations of the RISC-Varchitecture. Creating an ecosystem in which multiple vendors can compete in implementing a single ISAshould result in many of the benefits seen in other open-source projects.

RISC-V aims to create a modern ISA incorporating the best current ideas in processor design. RISC-VISA strives to be much simpler than the legacy ISAs while being practical and intend to accommodate fasthardware implementations.

3.1.3 RISC-V Architecture

There are many different markets, many different application areas for processors, and thus many differentdesign constraints. For example, an embedded processor needs to be cheap, reliable, and simple, but doesn’t

26

require speed, support for an operating system, multiple cores, or support for 64-bit operations. On theother hand, larger applications require processors with multiple cores and 64-bit operations, etc. The RISC-V project approaches this plethora of design choices by introducing some options into the ISA. In this respect,RISC-V is really not a single Instruction Set Architecture; it is a collection of related ISAs.

RISC-V ISA targets a pure Reduced Instruction Set (RISC) architecture - execute one instruction perclock cycle and to achieve this, each instruction needs to be simple and limited.

RISC-V offers three base integer ISAs - RV32I, RV64I, and RV128I for 32-bit, 64-bit, and 128-bit addresswidths respectively. 40 instructions of fixed 32-bit width are provided for hardware integer operations.Several standard extensions are provided: M - integer multiply/divide, A - Atomic memory operations,F - Single precision floating point, D - double precision floating point, Q - Quad precision floating point,C - Compressed instruction set, and E - Embedded microprocessors, with only 16 registers. Note thatRISC-V applications range from small embedded processors to 64-bit and 128-bit processors. Compressedinstruction set compresses the regular 32-bit instructions into 16 bits similar to Arm’s Thumb instructionset for embedded applications. Reducing the size of code results in increased processor performance since itallows more instructions to be cached, reducing the time to fetch instructions from main memory, which isoften a performance bottleneck.

3.2 Skynet Open Network Cryptography EngineTo handle the computational loads associated with blockchains, cryptographic functions, and consensusalgorithms, each Skynet Core contains an optimized Crypto Engine. Executing these functions in hard-ware reduces the software overhead, and the hashing functions required for encryption, authentication andproof-of-work (PoW) can be executed faster and for less power. The main host processor of each node willhave access to the functionality accelerated by the Crypto Engine via a secure API and secure communica-tion channels. Through this interface, the host processor will be able to run any cryptographic applicationefficiently with hardware acceleration, such as running DApps, Light Client, or consensus algorithms. Addi-tionally, the integration of secure storage and secure access to private keys will enable IoT devices to performcryptocurrency transactions autonomously. Users, owners or managers will be able to configure their deviceto allow a certain set of transactions and transaction frequency, ensuring and extra level of security.

The Crypto Core provides a highly secure platform for cryptocurrency private key processing and trans-action authentication. It offers a broad portfolio of services through its API including certified cryptographiclibraries, MiFARE Plus and MiFARE DESFire libraries, Hardware security features, crypto engines. It mayoptionally operate in tandem with the NPU and biometric processing engines for N-factor user authentica-tion. It will address the highest security certifications including Common Criteria up to EAL6+, EMVCo,and CUP. It supports the following basic functionalities:

1. MiFARE Classic/DESFir/Plus

2. Cryptographic support

(a) Message Digest: RIPEMD160, SHA224, SHA256, SHA384, SHA512, SHA3, SHA3-XOF, KEC-CAK

(b) Cryptography Key Generation: DES (64, 128,192 bits), AES (128 bits), ECC (256 bits), RSA(1024, 2048, 3072,4096 bits)

(c) RSA encryption with PKCS1 v1.5, PKCS1 OEAP, NOPAD schemes(d) HMAC Signature: HMAC-SHA256, HMAC-SHA512

27

(e) RSA Signature with PKCS1 v1.5, PKCS1 PSS schemes(f) Elliptic Curve Signature: ECDSA/EC-Schnorr (SECP256K1, SECP256R1, Brainpool256R1, Brain-

pool256T1), EdDSA (Ed25519)(g) Elliptic Curve Diffie Hellman: ECDH (SECP256K1, SECP256R1, Brainpool256R1, Brainpool256T1,

Curve25519)(h) Symmetric Cryptography: AES with ISO9797M1, ISO9797M2, NOPAD schemes(i) Random Number Generation: RND, Prime RND (hardware support TRNG)

3. Work to validate Operations performed and multifactor authentication (pin, passphrase, biometricauth, etc)

4. Private key recovery

5. Supports cryptographic libraries

6. Trusted and user mode of operation of the SW running on the node using hypervisors

7. Secure Boot ROM to build a chain of trust

8. Physically Unclonable Functions (PUF) to prevent device duplication

9. Tamper detection at the chip level with RAM clear and key erasure

10. Protection against grey market13

11. FIPS140-2 level 3 or more

12. Security Certification including EU Common Criteria Certification 14

Skynet Core’s Crypto-Engine will allow IoT devices to store cryptocurrency in the hardware itself, en-abling them to use cryptocurrency securely. This means wearable devices will be able to store cryptocurrencyand eventually, cryptocurrency will become user-friendly.

3.3 Neural Processing UnitTo leverage the current advances on Machine Learning on image classification, natural language processing,speech recognition, etc. we’ll include a Neural Processing Unit (NPU) optimized to accelerate all currenttypes of neural network algorithms, including DNNs, CNNs, and RNNs. Additionally, the NPU will be afundamental component to enable high-security user authentication through biometrics. To explore designspaces efficiently, scalability is achieved by replicating as many NPUs as required. The scalable NPU ar-chitecture addresses a wide range of requirements of lower and higher-end applications, from acceleratingembedded IoT devices with deep learning and proof of work mining by individuals through cell phones withbuilt-in NPUs.

The NPU will serve as the brain of the IoT device, allowing it to perform classification tasks with human-level accuracy at a practical throughput and within a practical power budget. The main host processor ofeach node will access the functionality accelerated by the NPU via a secure API and secure communication

13https://www.certicom.com/content/dam/certicom/images/pdfs/ams/security_for_fabless_semi_08.pdf14https://web.archive.org/web/20070825103724/http://csrc.nist.gov/cryptval/140-2.htm

28

channels. Through this interface, the host processor will be able to efficiently implement custom dataprocessing applications by loading pre-trained neural network models into the core, injecting data into itand reading back partial of complete activation results. These networks can be stored in the IoT’s ROM attime of manufacturing, or securely acquired, improved and updated later trough blockchain transactions.

The NPU block diagram (5) shows the main abstraction. In here, local memories for neurons weightsfrom the model to be run will be fed from the main host processor at appropriate times via the main system’sAXI bus. Also, there is a local inter-layer memory for activations that will first hold the input data to thenetwork (either full images, patches, of batches of images or patches), and then as each layer in network isprocessed by the Multiply and Accumulate unit, and the nonlinearity is applied, the output of one layer getsstored back to the activation memory to be used as the input to the next layer in the neural network. Atthe end of the network, the final result is stored in the activation memory from where the host processor canfetch it.

Figure 5: NPU Block Diagram

A vital requirement of any machine learning accelerator is its integration with training and deploymenttools that have become standards in the field. Therefore, OpenSingularity will develop the necessary backendsto Tensorflow, Keras, PyTorch, Caffe, etc. to support directly running these tools on our custom NPU, andintegrate these into the SON Blockchain API. As part of the adoption of these tools, we’ll support emergingopen interchange standards such as Open Neural Network Exchange (ONNX) so that developers can easilymigrate their applications into our hardware.

By accelerating neural network algorithms, we foresee that the developers may choose to use the NPUto build DApps with integrated learning. These applications could progressively finetune pre-trained net-works or leverage the latest advances in transfer learning to achieve higher accuracy and specialization.The OpenSingularity NPU is not intended as a platform for experimenting with new NN architectures noras a replacement for high-performance NN training workstations such and NVIDIA’s DGX or TPUs. Inprinciple, although incurring considerable overhead over integrated solutions, learning through the default

29

back-propagation algorithm can be done by simply computing the forward pass through the network in hard-ware, and using software to store the gradients and compute the backward pass. The host processor maymanage other forms of learning such as reinforcement learning or evolutionary learning, using accelerationfrom the NPU as practical. Overall, the vision behind supporting the NPU as part of a learning framework,as opposed to using high-performance GPUs, is an analogy to the "Tortoise and the Hare" story where slowand steady (via a large collection of distributed IoT devices) may lead to interesting developments.

The NPU will also play a critical role in providing high-security to the system, enabling N-factor userauthentication in some applications. For example, in hardware wallets of smartphones with Skynet Cores, theNPU could receive input directly, by a secured physical channel, from biometric sensors and would directlyenable the hardware wallet when a valid user identification detected. The biometric data could enable irisor retina scans, face identification, fingerprint matching. Additionally, the host processor could leveragethe NPU to provide an additional layer of security by keeping track of ongoing patterns of transactionsand authentications, and use an anomaly detection algorithm, to default the system to a secure state if ananomaly is detected.

3.3.1 Neural Network Operations

Over the past two decades Neural Networks have established themselves as a computational tool that forsolving problems only humans were capable of. In traditional programming paradigms where developersestablish a set of rules for the computer to follow in solving a problem. In Neural Networks developers definea set of nodes (neurons) and connections and use an optimization algorithms to find the best parameters fora given problem. In this section we’ll provide a brief overview of the current state of Neural Networks andtheir computational requirement, but a full review of the subtitles of each step is beyond the scope of thisdocument. For more details, the reader is encouraged to follow Stanford’s CS231n online course as a basicintroduction into the subject.

Neural networks are loosely inspired by the vertebrate brain structure where neurons are highly specializedcells that receive inputs from other neurons through the dendrites, and then transmit a signal through theaxon when the sum of inputs is greater than some threshold 6.

Figure 6: Analogy between a biological neuron (top) and a mathematical neuron (bottom)

In an artificial neural network, layers of nodes or neurons are interconnected in such a way that neurons

30

from one layer make connections with neurons of another layer, and each connection is assigned a weight 7.

Figure 7: Simple Neural Network Architecture

Biological neurons have extraordinarily intricate dendrite integration trees, exhibit rich temporal andmodulatory dynamics at every synapse (connection between axons and dendrites) within the dendrites, atthe soma (cell body) and through the axon. In contrast, artificial neurons are represented by a very simplemathematical model where the output of each neuron can be defined as yj = f(

Pwi ⇤xi+b), where for each

layer wi is the weight of the connection between the ith neuron in the previous layer and its activation xi,b is the activation threshold and f() is a nonlinear activation function that can take several shapes. A verypopular activation function is the Rectified Linear Unit (RelU) but the sigmoid, and tangents are commonsas well.

In practice, the neural network algorithm can be cast into a linear algebra operation Y = f(W⇥X) whereW is a matrix of weights whose rows represent all the connections between a previous layer and a neuronin the next layer. For this reason, GPU and other forms of Matrix-Matrix or Vector-Matrix multiplicationhardware has become so popular in accelerating the evaluation of neural networks.

Furthermore, a highly successful variant of neural networks has been the Convolutional Neural Network(CNN) where instead of having all neurons in one layer connect to all neurons in another layer, each layeris defined by a filter or constitutional kernel that gets shifted through the input space. This has proven tohave enormous advantages by reducing the number of parameters that a network has—each layer only needsthe parameters of the filter and not the full permutation matrix—and by creating filters that are appliedthrough the same way through the input space, therefore achieving spatial invariance. There are manydifferent network CNN architectures, and some are featured in 8

31

Figure 8: Multiple Convolutional Network Architectures

3.3.2 Neural Network Computational Requirements for Modern Networks

Despite the apparent simplicity of neural networks, there is enormous computational complexity behindthem. As can be seen in the previous section, neural network architectures (8) have grown in complexityand scale, and modern models have millions of parameters and perform billions of mathematical operations(9) to classify the contents of a small patch of image 15.

Figure 9: Giga-Operations and number of parameters required for each network15https://arxiv.org/pdf/1605.07678.pdf

32

Note that the computation required to classify an image is in the 2.5 to 40 GOP, yet the report doesnot clarify if this is for a single patch of the image of for multiple. For this reason, the actual computationrequired for a full HD image may be 100 to 1000 times greater. Inference time 10 and memory 11 usagemeasurements used Torch7 with cuDNN-v5 and CUDA-v8 back-end.

Figure 10: Inference Time vs. Batch size.

Figure 11: Maximum system memory utilization vs. batch size. Usage shows a knee graph due to thenetwork model memory using a static allocation and then variable memory used by larger batches

Power consumption hovers around the 12 W mark for all models 12. All experiments were conducted ona JetPack-2.3 NVIDIA Jetson TX1 board (NVIDIA): an embedded visual computing system with a 64-bitARM-A57 CPU, a 1 T-Flop/s 256-core NVIDIA Maxwell GPU and 4 GB LPDDR4 of shared RAM.

3.3.3 NPU Architecture: GPU vs TPU

A key innovation in the field has been to use the Matrix multiplication engines used to render images inGraphics Processing Unit (GPUs) to compute the workloads of Neural Networks. This has been one of theenabling factors that allow much faster training as well as larger models. An interesting trivia is that the

33

Figure 12: Power Consumption required for each network on the JetPack-2.3 NVIDIA Jetson TX1 board.Baseline at Idle is 1.3W

revolutionary AlexNet network that unleashed this movement is broken up into two main branches becauseeach branch could be run in an independent GPU. To expedite training data scientists put great effort intocreating network architectures that maximize (but not exceed) the memory capacity of GPUs. This in turnhas created a feedback cycle where GPU manufacturers (NVIDIA in particular) are designing GPUs withlarger capacities specific for these workloads. As of this writing, the pinnacle of machine learning computingis the NVIDIA DGX-1 workstation with Tesla V100 GPUs that can process 1000 TFLOPS (deep learning).In general, GPUs work better than CPUs for machine learning because they have a much larger number ofcomputing cores and faster access to memory. This computational advantage is extremely important becauseit can reduce network training from months to hours. The reader is referred to an excellent slideshow fromNVIDIA showcasing the advantages of GPUs for deep learning 16.

Beyond GPUs, when Google realized that neural networks would overtake the performance of traditionalcomputing for translation services17 (and others), but that this would triple their computational require-ments, they designed their own Tensor Processing Unit. Figure 13 shows the physical implementation ofthe TPU, how its architecture mimics very directly the computation required to process the common layersof a neural network, its integration stack and how with this implementation they achieved an impressivecomputational efficiency 89 times greater than Using CPUs and 29 times greater than using GPUs (of thatera). This, and the newer generation of TPUs are available for use by the public through the Google Cloud.The reader is referred to an excellent overview of the TPU 18 or the original TPU paper 19.

3.3.4 NPU Available Offerings

Through the past decade, the industry has recognized that neural computation and custom accelerators wererequired to move forward the field of Artificial Intelligence and machine learning. This was perhaps catalyzedby DARPA’s SyNAPSE project which led to TrueNorth, one of the first formal efforts to productize neuralnetwork accelerators. Today there are dozens of players in this field that offer mature and accessible NPU

16https://www.slideshare.net/papisdotio/introduction-to-multi-gpu-deep-learning-with-digits-2-mike-wang17https://www.nytimes.com/2016/12/14/magazine/the-great-ai-awakening.html18https://cloud.google.com/blog/big-data/2017/05/an-in-depth-look-at-googles-first-tensor-processing-unit-tpu19https://arxiv.org/abs/1704.04760

34

Figure 13: Google First implementation of the Tensor Processing Unit

acceleration at multiple scales. At the ASIC or SoC level, Arm 20, Synopsis 21, Cadence 22, offer supportedIP blocks ready for integration into silicon products. Further up the stack, several hardware manufacturersoffer readily available chips, module, and workstations for accelerating neural processing such as: Nvidia23, Intel 24, Bitmain 25. From a cloud perspective, NPU acceleration is available from NVIDIA, Google,Amazon, Microsoft, and IBM. Finally, it is rumored that there are approximately 35 startups pursuing NPUacceleration products such as Fathom computing, Mythic (previously Isocline), Groq, Wave Computing,Cerebus, GraphCore, Ambiq Micro and Knupath.

3.3.5 Potential for Optimization

Despite the enormous amount of funding and momentum in the NPU field, it is unclear if there will besuccessful players that develop solutions optimized for IoT devices. As such, the OpenSingularity Foundationwill focus on identifying the best-suited applications for Machine learning at the IoT edge and run extensiveworkload profiling. From there, we will compare how these specific workloads map onto existent availablesolutions in search of potential for improvement. Finally, once we have identified the specific space betweenthe existing solutions and the required needs, we will conduct an extensive review of cutting-edge techniquesand IP landscape to develop a set of NPUs customized to solving the NPU needs of IoT edge devices.

20https://www.arm.com/products/processors/machine-learning21https://www.synopsys.com/designware-ip/technical-bulletin/embedding-artificial-intelligence-into-our-lives-2018q1.html22https://ip.cadence.com/applications/cnn23https://www.nvidia.com/en-us/deep-learning-ai/24https://developer.movidius.com25https://sophon.ai

35

4 Skynet Open Network

In the previous sections, we detailed the Skynet Core and how the components will be used to utilize theapplications on Skynet Open Network (SON) and of blockchain technologies as a whole. We also detailed ahigh level overview of the SON network structure and its adoption plan. In this section, we introduce SON,an infinite-chain network that will serve to link all intelligent devices and blockchains under one decentralizedsystem. By bootstrapping the network off of the Skynet Cores, SON allows for global adoption of blockchaintechnology by providing billions of devices immediate access to its network and other networks.

4.1 Network IntroductionSkynet Open Network is comprised of four main frameworks: SON Fabric, SON Nova, SON Idem, and SONSingularity. However, the latter three frameworks are all connected to SON Fabric, the root blockchainplatform enabling an infinite amount of other blockchains and frameworks that connect to it.

Table 6: Skynet Open Network FrameworksSON Frameworks Description Applications Native Tokens

Fabric Blockchain PlatformProof of Stake BlockchainsCross Chain Communication

SkynetLight

Nova Distributed App PlatformScalable Smart ContractsWeb3 and Ethereum Compatibility

Light

Idem Decentralized ID PlatformSecure Node DiscoveryIoT Device Management

Light

Singularity Machine Learning PlatformAI KnowledgeNetDecentralized Machine Learning

Singularity

sWith the frameworks shown in Table 3, SON can provide the end-to-end solution with a development

platform and applications to support the interactions between autonomous devices.

4.1.1 Skynet Open Network, Fabric

SON Fabric is a publicly validated, Byzantine Fault Tolerant, Delegated Proof of Stake blockchain and the"root"of the Skynet Open Network. Fabric contains a Go-Language software development kit, enablingdevelopers to make fast public or private, fault tolerant proof of stake blockchains independent of Fabric’sgovernance.

With Fabric, blockchains can become their own VM-independent platform or be used to interact withthe underlying scheme of other blockchains. Fabric only keeps track of the tokens on each blockchain createdon it, allowing for a type of cross-blockchain communication where each blockchain can be independent butare able to exchange data packets with one another through it.

36

Table 7: SON Blockchains ComparisonProperties SON Fabric Sub ChainsType Public Public or PrivateConsensus Delegated Proof of Stake Proof of StakeValidators 100 to 500 4 to InfinityFinality Instant InstantPrivacy No Yes or NoTuring Complete No VariesGovernance Yes Soverign

Shown in Table 4, Fabric will start with 100 validators and have its own governance mechanism. However,subchains on Fabric are independent of one another and have their own network designs, allowing them tobe isolated from the failures of other networks. This is enabled by a Byzantine Fault-Tolerant ConsensusAlgorithm called Tendermint Core, that takes state translation machines in any language and replicates itacross all machines. Tendermint Core is, as a result, well suited to handle many IoT subsystems and manylow latency, high finality, blockchains that are well architected to function in the real world. This makesFabric a modular platform for deploying high throughput blockchains with minimal resource consumption.

Sub-Chains In this paper, sub-blockchains created on Fabric are referred to as IoT Chains. IoT Chainscan be created by developers for their own purposes or to interoperate with Singularity’s existing chains. Tocreate IoT Chains, Fabric comes with a toolkit, which provides boilerplates for on-chain storage data typecustomization, multi-data type on-chain storage abstractions, private blockchains, and public blockchaincreation. With Fabric’s software development kit, any existing blockchain like Bitcoin and Ethereum canbe created as an IoT chain but with infinite scalability and an energy efficient Proof of Stake fault tolerantconsensus.

Skynet Token Skynet Token is the native staking token of the Skynet Open Network and SON Fabric.In Proof-of-Stake blockchains, the creators of each block are chosen by random selection in a round-tablelike fashion according to how much coins or value the person holds. To provide incentives for participantsto stake the currency, the Skynet token is solely designed for staking whereas block rewards and fees aredistributed in another token. Interestingly enough, Skynet tokens can be used for staking with other IoTChains.

Light Block rewards and fees are paid in a currency called Light. Light is the native fee token of the SONNova platform as well as the SON Idem platform and can be used across all blockchains.

4.1.2 Skynet Open Network, Nova

Connected to SON Fabric is Nova, a modular smart contract platform with its own enhanced EthereumVirtual Machine (EVM) called Quantum. Nova’s platform will allow for distributed applications to be builton the Skynet Open Network while removing the drawbacks of Ethereum such as transaction time and fees.

37

At first, Nova will simply be a Proof of Stake Ethereum powered by Tendermint Core and a virtualmachine built in part to the specifications of EVM. With a similar virtual machine, Nova will allow for inter-operability between existing Ethereum distributed applications and Web3. Nova will also enable developersalready familiar with Ethereum to migrate to Skynet Open Network and begin developing IoT-based appli-cations that can be adopted immediately across devices with the Skynet Core. These benefits make Nova amodular platform for developing scalable decentralized applications immediately usable in IoT devices.

4.2 Skynet Open Network, IdexConnected to SON Fabric is Idex, a hybrid sub-chain distributed ledger built to create a decentralizedidentity and a crypto phonebook for IoT devices. SON Idex provides the tools necessary for devices topublish information that other independent blockchains and applications can access and query. Since thenetwork is immutable and public, any device can join the network and start finding devices over the network.

Attached to the distributed ledger is an off-chain explorer that devices can query to examine the transac-tions and history of other devices. Here Idex provides a machine reputation service where device addressescan receive ratings from 0 to 100 depending on how reputable a machine might be. Idex can then be com-bined with other scalable platforms to make a whole new scope of applications such as algorithms for securemachine to machine transactions and self-organization.

For all these reasons, Skynet Open Network Idex provides all the designs and specifications necessary tosupport decentralized identities and its resulting potential applications.

4.3 Skynet Open Network, SingularitySkynet Open Network, Singularity, also known as an AI KnowledgeNet or Virtual Application Layer, isan extension of Nova and Idex, enabling a series of interoperable applications for interactions and learningbetween Skynet Cores and other IoT devices. More specifically, these are for decentralized machine learning,distributing computation, and data sharing. The applications can be tied in with Singularity’s multi-chainmarketplace where devices can agree on values for their training data or computational power.

Both the the distributed applications and the marketplace make up SON Singularity. Developers canmake their own distributed applications on Nova or perhaps combine it with Idex and have them be inter-operable with the existing applications on Singularity’s virtual application layer. Real-world devices andSkynet Cores can then utilize the applications and the cryptocurrenices that the distributed applicationsoffer. For example, if a developer wanted to create an application for distributed evolutionary learning onNova, devices could access something called the virtual application layer and have access to the network’sprotocols and cryptocurrenices.

4.4 Skynet Open Network ArchitectureThese four frameworks and their native applications and protocols make up the Skynet Open Network.Beneath their platforms lay a three-layer architecture. On the very bottom, Tendermint core provides theconsensus engine and P2P communication to form the base of the SON. Above Tendermint Core, lies SON’sSDK which implements blockchain logic for the cryptocurrencies, smart contracts, identity, staking, andgovernance. SON’s SDK interfaces with Tendermint core via ABCI, short for Application Blockchain ClientInterface. On top of the Singularity SDK, applications can be implemented.

38

4.5 Tendermint CoreSON and all its blockchains are run on Tendermint Core, a Byzantine Fault Tolerant consensus engine thatcan take state translation machines and replicate it. Tendermint Core is a variant of the Practical ByzantineFault Tolerance algorithm, which can process thousands of transactions per second with sub-millisecondlatency increases 26 In this manner, Tendermint Core can defend against malicious attacks and actors in thenetwork through its fork accountability, where malicious actors that causes the consensus to fail can be easilyidentified and subsequently punished. Some advantages that SON adopts from the Tendermint consensus27include:

Byzantine Fault Tolerance - SON nodes can tolerate 1/3 of machines failing. SONSecure Peer to Peer - Dynamic peer-to-peer discovery is enabled between nodes by borrowing btcd,

which is Bitcoin’s alternative implementation in Go.Fast Consensus - Each blockchain on SON can support thousands of transactions per second.State Machine Replication - SON can replicate state machines in any programming language.

Tendermint’s main contribution to SON, however, is its non proof-of-work consensus that protects againstdouble-spend attacks while being resilient up to one-third of Byzantine participants. In SON, Tenderminthelps manage the agreement of state synchronization as well as agreements to publish the next blocks betweennodes.

As a result, SON’s consensus engine enables it to have very high throughput for IoT applications despitehash conditions such as malicious actors or crashing validators.

26https://wikipedia.org/wiki/Byzantine-fault-tolerance27https://tendermint.com

39

28

As shown above, with a 64 validator benchmark, each blockchain on SON will be able to process thousandsof transactions per second with sub-second latencies. This means that SON will be able to function effectivelyin the real world compared to other blockchains and directed acyclic graphs.

Tendermint Core connects applications with an Application Blockchain Interface (ABCI), which usesa socket protocol to enable consensus engines running on multiple application states. Tendermint Core’smachine-based BFT algorithm provides the mechanism necessary to implement Proof-of-Stake protocols ontop of it.

4.6 Client Node DiscoverySON adopts Satoshi Client’s mechanism for client node discovery. In summary, SON client discovers the IPaddress and port nodes in various ways.

Local Client First, nodes can use public web services or hard-coded software to determine its own IPaddress. It can try to connect to 91.198.22.70 port 80, which is an IP DNS server. If the connection fails, aDNS request is made to 74.208.43.192 port 80, which is an IP lookup server. Basically the nodes attempt toconnect to these servers by sending a HTTP request, reading the responses, and parsing the IP address toadvertise the address to connected nodes, thus finishing the thread line.

Database Nodes can store their addresses in the SON crypto phonebook and query the addresses uponstartup.

Address Relay Addresses can be relayed to other nodes.

Self Broadcast Every couple of hours, the node can advertise its own address to all connected nodes inits network.

DNS Addresses SON nodes can issue DNS requests to learn about addresses of other peer nodes. Theclient could then have seeded DNS services.

IRC Addresses SON nodes can enter an IRC channel and have its address encoded into a string. It canrandomly join an IRC channel and issue a threading command to decode the IP addresses of other nodes inthe channel.

4.7 Application Blockchain Client InterfaceIn SON, the interface between multi-machine state translations and is used to communicate between Ten-dermint consensus and the application layer. The ABCI is an interface that allows applications to beimplemented on top of Tendermint Core in any programming language. ABCI is implemented in a socketprotocol called Tendermint Socket Protocol (TSP).

The Tendermint Socket Protocol is used for communication between the application and TendermintCore. Using this layer of abstraction, the Tendermint Core can be plugged into any application on SON thatcan communicate via sockets. This provides a modular architecture on SON for implementing blockchain

28https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md

40

systems. Typically, Tendermint Core would be responsible for sharing blocks between nodes and establishingthe transaction order. Cryptographic transaction validation, incentive mechanism, and other blockchainprimitives would be implemented at the application layer.

The Tendermint Core maintains three connections, mempool connections for using CheckTx for transac-tion relays, consensus connection for executing committed transactions, and a query connection for applica-tion states.

Mempool connection (CheckTx)- Checks if transactions are valid (only lightweight checks) and should be executed and broadcast to other

nodes (through DeliverTx)); only uses CheckTx- Performs checks by using the "Mempool" as a starting state (list of accounts, current balance, and any

other relevant information stored in the state).- Starts as a copy of the last committed stateConsensus Connection (BeginBlock, DeliverTx, EndBlock, Commit)- Executes and broadcasts transactions that have been checked. Message sequence is - for every block -

BeginBlock, [DeliverTx, ...], EndBlock, CommitQuery Connection (Query, Info) - query application state without engaging in consensus (= read-

only) (Query)- handshake (Info)- genesis (initChain).Otherwise, the ABCI design has a message protocol defined using protobuf and the server implemented

by async raw bytes and grpc 29

Info: used to communicate current state between ABCI client (tendermint) and Server (the applicationencapsulating business logic)

Flush: used as a means to communicate that a message has been received and processed. It is send afterreceiving the associated response to a request sent.

InitChain: called to initialize a new node. In the case of the first node, it will also initialize theblockchain, in the case of a new node in an existing blockchain, it will just catch up with the other nodes byreplaying past transactions.

checkTx: sends the Transaction to be "prechecked" before it is send to all validating nodes for processingand integration in the current block.

deliverTx: send the Tx to all validators and executes the Tx (if relevant)Commit: commits the state with all accepted Txs. This writes the state such that the next block can

begin and increase the block height.beginBlock: opens a block for the inclusion of new TxsendBlock: closessetOption: allows setting of local, nonconsensus critical options on the node. For example, log level of

the app.Query: allows querying of the state without impacting it (read-only). This operation is performed

locally on the node)29 https://lightrains.com/blogs/intro-tendermint

41

4.8 Validators and DelegatorsIn SON’s Tendermint Consensus, validators can participate in the consensus by broadcasting cryptographicsignatures that act as votes for the next blocks. To become a validator, a node must lock up a predeterminedamount of tokens. Delegators, someone who wants to contribute voting power to a validator, delegates thesame token to a potential validator, so that the delegate might earn a part of a block reward. Delegates areputting their tokens at risk by delegating their stakes to validators and may lose tokens whether or not thevalidator behaves in line with the protocol implementation.

Validators have a voting power equal to that locked up in a bond transaction and may unlock the coinsby posting an unbonded transaction.

A minimum of 4 validators are needed but can scale infinity to run the consensus protocol on SON.However, in the SON Fabric, we will begin with 100 validators and scale to 500. These validators can helprun the other networks on SON.

4.9 Tendermint BFT dPoSSON’s Tendermint Byzantine Fault Tolerance protocol is a modified version of the DLS protocol and isresilient to up to 1

3 of Byzantine participants. The consensus protocol requires no proof-of-work mining andprotects against double spending. Tendermint’s algorithm is based around the FLP impossibility result fromFischer’s research in asynchronous systems. 30The algorithm assumes that the network is partly synchronousand that non-byzantine nodes can utilize an internal clock until the next block is published.

, , , ,

Commit New Round Pre-vote Nil Propose Block

New Height Propose

Pre-comitt Nil

Propose Block

wait for pre

commits for +2/3

wait for pre

commits for +2/3

no +2/3 pre-comitt

for block

no +2/3 pre-vote

for block

+2/3 pre-vote

for block

+2/3 pre-comitt

for block

invalid block or not

received in time

valid block

30M. J. Fischer, N. A. Lynch, and M. S. Paterson, “Impossibility of distributed consensus with one faulty process,” Journalof the ACM, vol. 32, no. 2, pp. 374–382, 1985.

42

Figure 11: SON Cross-Blockchain Communication protocol 31

The figure above demonstrates how the consensus round goes.In SON’s consensus round, validators sign votes for blocks with three types of votes: prevote, precommit,

and commit. When the 2/3 majority of validators sign and broadcasted commits, then the block is committedto the network.

At the height of each block, a round with two steps, (commit, newheight) and (commit, propose, prevote,precommit) is executed. Each round time is incremented by a small amount, which allows the network toachieve consensus in a partially synchronous network.32 When each round starts, a proposer is chosen inproportion to the amount of voting power. Since the consensus is executed in a deterministic round-robinfashion, nodes form a consensus of the proposers in each round.

The first round is for choosing a proposal during the propose round where the proposer for the roundwill gossip a proposal to its peers as a way of broadcasting information. Then, the next round is the prevotestep where if a validator receives a valid proposal, it can broadcast a prevote for the block. However, if thevalidator is locked from a prior block, it broadcasts a proof-of-lock for the locked block. However, if there isno valid proposal, the validator will broadcast nil. In this manner, all nodes will broadcast their prevotes topeers.

The next round is the precommit step where if the validators receive a majority prevote for the block, thevalidator can sign something called a precommit and lock onto the block while releasing any previous locks.When a node chooses to lock or unlock a block, it combines prevotes into a proof-of-lock for later where ifa node receives 2/3 of nil prevotes, it unlocks. If the node receives 2/3 of precommits, it enters the commitstep. Otherwise, it will go back to the propose stage.

In the commit stage, nodes must receive a block and wait for the majority of commits for blocks tobe precommitted to the network.33 If both conditions are satisfied, the node commits a commitTime to anewHeight where the network can still keep consensus despite different clocks.

If any node receives a 2/3 majority of commits, it enters the final commit stage where it commits theblock.

4.10 IVAL+ Data StructureSON uses an IVAL+ Data Structure that is similar to that of Ethereum’s Patricia trees. This data structureis there to fast computation for deterministic Merkle root hashes and storage for key-value pairs.

SON uses a merkalized IVAL+ (Go 1.8+), a balanced variant of AVL trees to ensure the blockchain statecannot be tampered. In short, the AVL+ algorithm modifies the AVL algorithm to keep values on leaf nodeswhile using branches to store keys. It is a key value pair storage allowing for a deterministic merkle roothash for computation, which guarantees the integrity of the structure from one block to the next. As it is avariant of AVL, all the operations are Olog(n), and the nodes are immutable and indexed by their hash inthe tree. The nodes serves as a some timestamp for uncommitted mempool transactions, so that they canroll back the last commits for the new block. SON’s IVAL+ is a more efficient algorithm adaptation of AVL.34

31https://cointrends.top/news/view/consensus-compare-casper-vs-tendermint32 https://tendermint.com/static/docs/tendermint.pdf33 https://tendermint.com/static/docs/tendermint.pdf34https://github.com/tendermint/iavl

43

4.11 Light ClientsNative support for light clients makes SON particularly useful for IoT applications, in which nodes may havelimited resources. In contrast to IOTA’s system that targets IoT applications that require a heavy Java-basedgateway node implementation, SON’s consensus is designed to support light clients that do not have to storetransactions locally. This is achieved by allowing applications to include the root of a Merkle tree in eachblock, which can be used to verify state queries or transaction outputs. This allows SON to enable light clientprotocols, which are designed to allow users in low-capacity environments to help maintain a certain stateof the network. This means light clients protocols are great in IoT devices such as smartphones, watches,and tablets.

SON enables applications to embed a Merkle Tree hash in each block to verify state queries or transactionoutputs, similar to the structure of Ethereum’s light clients. With SON’s underlying consensus, the networksolves the nothing-at-stake predicament by utilizing deposit collateral, allowing light clients to know when avalidator is going to change and then verify >2

3 of the pre-commits to know the latest block state. However,with our Skynet Core devices, small IoT devices should be able to run full nodes.

4.12 Cross-Blockchain CommunicationSON contains an cross-blockchain communication protocol (CBC) to allow blockchains on SON to exchangetokens and information with one another. All exchanges between blockchains are done with something calledCBC packets in which packets of information is sent through Fabric to the other blockchains.

One way to do cross-chain atomic swaps is shown by hash time locked contracts in the Lightning Network.However, SON’s CBC’s protocol can create 2-way sidechains, enabling exchanges between blockchains withinstant finality that can enable a transfer of information or value. 35

More specifically, the CBC protocol contains two types of transactions: a packet transactions, whichenables a blockchain to prove that a packet was published by a sender via the most recent block hashMerkle-proof and a block commit transaction, which enables blockchains to prove its most recent block-hashto an observer.

In this manner, SON allows for the receiving chain to acknowledge which CBC packets are committedwhile allowing what outbound packets are allowed.

The concept of cross-blockchain communication can then be applied to things such as:

Multiple Virtual Machines - SON Fabric only communicates to other IoT Chains with CBC, so eachother blockchain can be sovereign and have their own virtual machines, applications, and governance.

Distributed Exchange- SON Fabric can be used as a decentralized exchange to swap tokens betweenIoT Chains.

Cross-Chain Bridge - Chains on SON Fabric can serve as a bridge to other blockchains like Bitcoinby verifying states in SON and on other blockchains.

In this manner, cross-blockchain communication is a vital component of having an infinite amount ofinteroperable, self-governing blockchains on the SON.

4.12.1 Infinite Sharding Paradigm

SON handles infinite sharding through its IoT Chains. SON Fabric ignores the state of its IoT Chains butrather listens to communications through CBC packets, so each shard can be its own sovereign blockchain.

35https://github.com/tendermint/basecoin/blob/master/docs/guide/ibc.md

44

Unlike with proof of work consensus blockchains, with SON’s Tendermint consensus, running an infiniteamount of parallel blockchains does not diminish either the speed or security of each IoT Chain.36 As eachchain can handle thousands of transactions, spawn an infinite amount of chains, and have sub-chains worktogether, SON can scale to infinity to handle any amount of IoT interactions.

The main difference between sharding with SON and other blockchains is that on other blockchains, theshards depend on the general machine state while SON preserves the number of tokens between chains. Thismeans that on SON any blockchain with entirely different virtual machines can be created and can fail,while on other blockchains, none of the shards should fail. However, in SON, other types of sharding can beimplemented and tied in within the network.

4.13 SON FabricSON Fabric is a competitively validated delegated proof-of-stake platform. The hub maintains the numberof tokens on each IoT Chain and enables a seamless relay of data between blockchains. This means thatthe hub serves as a global bridge between all public and private blockchains on SON while also serving as adistributed exchange.

4.13.1 Fabric Entangled Chains

On SON Fabric, its native cross-blockchain communication protocols allow it to interoperate with its existingchains. However, since we acknowledge since there are a lot of applications that people make on other chains,we will enable something called an entangled chain which provides a bridge and interoperability with existingblockchains and their native cryptocurrencies such as Bitcoin or Ethereum. All that is needed for a entangledchain to serve as a bridge is some type of pseudo-finality on the other blockchain where there is some processthat determines the finality of the block.

SON Fabric

Bitcoin

Ethereum

Litecoin

Eos

Neo

36https://github.com/tendermint/tendermint/wiki/Introduction

45

For example, on SON, one entangled chain can serve as a bridge with Ethereum. To provide somebackground, the main differences between Tendermint and Ethereum goes as follows. Tendermint usesgo-wire for serialization while Ethereum uses Recursive Length Prefix. Tendermint uses ed25519 where incomparison, Ethereum uses secp256k1. Lastly, Tendermint uses IVAL+ Trees while Ethereum uses PatriciaTrees for key values.

Currently on Tendermint, there exists a protocol called ETGate which serves as a bridge betweenTendermint-based blockchains and Ethereum. In the protocol, it decoded packets within Ethereum’s virtualmachine. However, converting every block into a compatible variant within the Ethereum Virtual Machineis too gas costly for SON. In order to provide a gas-friendly bridge from SON to Ethereum, an ABCI appwill receive a relay message from the SON Fabric, and the ABCI app will write an Ethereum transactioncontaining the address, denomination, amount, and nonce. The Signing Apps will then detect transactionsfrom the ABCI Apps and sign transactions using secp256k1. The Signing Apps will relay messages back forreplication and the relayer Signing App will query the ABCI app’s transactions and process those that reachthe required threshold The relayer Signing App will send a transaction to the Ethereum smart contract andthe smart contract will send a Light ERC20 Token to the user’s Ethereum address.

On Fabric, it’s easy to transfer light to the entangled chain, and once the entangled chain receives anCBC packet, signers can convert the signature into Ethereum’s native secp256k1 format. Validators can thenwait for 2/3 of transactions to be complete and then relay the information to Ethereum, in which we willcreate on smart contracts to enable the interoperability of SON’s native tokens and Ether. Once the lightis sent, the smart contract can then send an ERC20 light variant to an Ethereum address where the IoTdevice is able to convert it to Ethereum via a distributed exchange. The development of entangled chains isstill in its early stages, and more updates will be provided as the project continues. SON’s entangled chainsserve as a global bridge to enable interoperability between all major blockchains.

4.13.2 SON Fabric Tokens

On the SON Fabric, there exists two types of tokens: one for staking and one for fees. They are bothrespectively called Skynet and Light. Skynet is the only staking token on SON Fabric and is used to vote,validate, and delegate validators. Light is used for a transaction fees to mitigate spam. Because SON’sconsensus algorithm can replicate different deterministic states, more than one coin can be built upon eachchain since SON Hub tracks multiple different token states.

For this reason, the multi-token economic model was created to address the problems of current proof ofstake models.

For example, when Ethereum switches to Casper, it has one native token: Ether. As Ether has moreutility than staking, such as paying for goods, a large number of tokens will not be staked and as a result,weakens the security of the protocol.

As SON is an interoperable multi-token network, we can introduce both Skynet and Light to address thisconcern. SON’s utility is for staking only and will be used to earn transaction fees and block rewards onSON Fabric and hosted chains. One can think of the token like an SHA-256 ASIC miner. The ASIC miner’smain utility is to mine Bitcoin. The rewards are in Bitcoin, but in order to mine, one needs the ASIC. Inthis SON’s case, the reward is in Light instead of Bitcoin and the miner is the Skynet token instead of theASIC.

With this model, Skynet’s utility is to serve as the only staking token, which in turn would incentivizethe governance and security of the network. In this manner, the majority of Skynet will be staked in thenetwork since it will be used just for staking. The fees collected by validators from computational costs fromeach transaction will be distributed proportionally to the number of Skynet staked.

46

4.13.3 Validators and Incentives

In SON Fabric, validators can stake their Skynet tokens and can delegate the tokens to stakers. The hub atfirst will have 100 validators, but over time will create to 500 validators. Validators can stake their Skynettokens and in return receive Light for block provisions and transaction fees. As there are only a limitednumber of validators, nodes can delegate their Light tokens and contribute to the consensus; as a result,they will earn a percentage of transaction fees for participating or lose their share if the validator is malicious.Like other delegated proof of stake models, the more Skynet Tokens one stakes, the more block rewards andtransaction fees they get in return. When SON Fabric is launched, validators will be chosen through a publicvote, which will shift around validators when Skynet tokens are delegated to others.

When a block is published, the provisions are proportionally distributed across validators relative to theirstakes. If the block provision is 5000 Light tokens and each validator has 20% of staked Skynet tokens, andthe commission fee is 2% across 10 validators, then the 500 tokens will be distributed across:

Commission: 500 * 80 % * 2 % = 8 LightValidator: 500 * 20 % + Commission = 108 LightDelegators: 500 * 80 % - Commission = 402 Light

Each delegator will receive a distribution of the 402 Light in relation to what it delegated to the validatorpool. If a validator is malicious, such as when it commits signing, it is easy to tell on SON because onlytwo conflicting votes are needed. The validator will immediately be dissipated after a slash transaction iscommitted. Initially, 5 percent of Light tokens will be inflated every year; however, this value will change toincentivize validators to stake two-thirds of the Skynet tokens and depending on the governance of the hub.

On genesis day there will be 100 validators, and will increase at a rate of 15 percent per year until itreaches 500 validators. The block reward for Light will be determined at a later date but will be at aninflation rate that asymptotically reaches zero. Validators on SON Fabric might help validate other IoTChains such as SON Nova in the very beginning.

4.13.4 Slashing

If a validator misbehaves, it loses its staked Skynet tokens along with Light. This happens when it doublesigns, such as if a validator reports that on Chain X, a validator signed two blocks with the same height onChain X and Y. If that is the case, the validator will get slashed on Chain X. Next, if a validator’s signaturehas not been included in the last x amount of blocks, the validator will get slashed a proportional amountof x. If it surpasses a number y, then the stake will be removed. If someone reports that a validator did notvote, a minor slash will occur. Moreover, validators can be slashed if the node gets DDOSed, the privatekey gets hacked, it loses connection, and if the node crashes.

4.13.5 Governance

On the SON Fabric, validators can vote on things such as block gas limits in relation to parameter changes,coin inflation, updates to the policies, as well as vote on terms and services that govern the SON Fabric.Each validator is required to vote or else the validator will be deactivated for 2 weeks. Each vote proposalrequires an x amount of tokens on SON as a stake deposit. If the proposal was spam, meaning that the voteswere majority negative, the deposit would go into something called a reserve pool.

47

For proposals, validators can vote with either: Yes, No, and Abstain and a strict majority is required fora proposal to pass. More updates regarding governance specification will be revealed close to the mainnetlaunch.

Aside from the SON Fabric, each blockchain on SON can have its own governance and constitutions, asthey are sovereign blockchains.

4.13.6 IoT Chains

IoT Chains are high throughput regional or device-specific public/permissionless or private/consortiumblockchains, each powered by Tendermint BFT Consensus that connects to Fabric. While each IoT Chaincan handle thousands of transactions per second, billions of IoT devices using a network can cause write feesto go up, and no single blockchain or DAG can scale past 30 thousand transactions per second in real-worldconditions. IoT devices are also the opposite of “one chain fits all” as devices on a single blockchain are forcedto use different data types, which are emulated within a generic container. Therefore, each chain uses ABCIfrom Tendermint, allowing developers to create more distributed replicated IoT Chains blockchain and splitthe network users, creating infinite scalability. SON’s toolkit allows custom device type chains to be built forspecific IoT applications, as native types perform better. Each IoT Chain can also bootstrap off of the IoTLedger, allowing validators in each IoT Chain to verify their location and in turn, creating geographicallyspecific public chains for fast finality.

IoT Chains are blockchains that can take many shapes or forms on Fabric such as, local, global, public, pri-vate, consortium, geographically specific blockchains, manufacturer-operated, or user-operated blockchains.

IoT Chains on Fabric come with an open source boilerplate software development kit for setting upinteroperable IoT Chains and as an easy guide for anyone who would want to create a chain with SkynetCore. Collectively each IoT Chain interfaces with Idem’s identification chain and second layer networksystems, allowing them to turn to create new identity based applications.

4.14 Skynet Open Network, IdemSON Idem contains a built-in identity protocol layer to allow machines to find one another, self-organize, andstart to develop something called a machine reputation. This layer will allow devices to determine whethera random node is malicious or not or whether if it is in the same knowledge domain. The identity protocolwill also enable people to determine whether their machine is functioning properly as nodes in the networkwill interact with other known nodes on the public ledger. A smart contract in Idem will update whenevera transaction is made via Singularity’s distributed applications.

Unique identities will be added as transactions and be saved on side-chains of the hub with SON’s SDKto provide permanent logging of identity data. An off-chain database will hold information regarding thenode such as reputation score, which will be determined by an algorithm that generates a score based onthings such as how many interactions a node went through previously, how much cryptocurrency is in thenode’s address, and the amount of data the node decided to broadcast. The algorithm and more detailsabout the exact nature of the identity protocol will not be public as its not in the best interest of devices tostart gaming the system. However, more details will be released near the distribution of the Skynet Core.

4.15 BeaconsMachines have much simpler identities than the humans or groups of humans that own them. At themost basic level, a machine identity is an address on the network that looks like it is owned by none be-

48

cause its owner has listed it privately. For machines that need to publish information publicly, machinescan have a human-readable address, like john.doe/weather station or microsoft/weather station or Cleve-land/parkingmeter123534. Beacons are the system for registering machines on the SON Fabric’s ID chain.It allows for machines to publish information about themselves, generally a single time, but machines canhold currency and can of course publish multiple times.

Specifically, devices store a “beacon” on the chain. This beacon functions like a device ID, and allowsfor the specific device to be accessed in a P2P manner no matter where it is on the network. There isa minimal cost for registering a beacon, to prevent spam. Beacons can be highly descriptive, or entirelyminimal. This is the choice of the user.

Figure 12: Idem Node Registration

The beacon is essentially a permanent device identifier stored on the blockchain with as much or as littlecontext as is desired. Beacons can be used by manufacturers to talk to their devices in the field, or they canbe used by end users to enable orchestration between devices. While it is possible for two devices on Idemto find one another even without a Beacon on the blockchain, they need to know their device IDs. Beaconsmake it possible for users and devices to find one another without dealing with IPFS device ID’s directly.

4.15.1 Machine Reputation

On SON Idem, people and machines that are registered with Beacons acquire an explicit reputation frommachines and humans that interact with them. Machine reputation is a security mechanism that types acynical approach to device security. It assumes that devices can and will be hacked or modified in unexpected

49

ways to cause unhelpful output, and provides recourse for when that happens. While Idem cannot undoa transaction with flawed data, Idem can curate its network of machines to ensure that harmful machinesdo not take a foothold in the network. With machine reputation, machines do not need user feedback onits performance and serve as a mechanism for controlling autonomous devices. The network will maintainan off-chain cloud reputation lookup explorer, allowing for machines to have an easier time to find otherdevices and gauge reputation before engaging in direct communication and transactions. This service alsoallows for vendors and device owners to have an overview of machine transactions to determine whether theautonomous device is functioning as planned.

Some assumptions are that humans use names when they talk to each other, 1F1tAaz5x1... is not a nameand that Idem resolve names to addresses, so humans can use names.

Some other assumptions are that machines use addresses when they talk to each other, for example1F1tAaz5x1..., is an address and that Fabric resolves names to addresses, so when humans use names,machines know what they’re talking.

Lastly, some assumptions are that machines can and will be hacked. Machine reputation accrues overtime and helps users to know whether or not a device can be trusted so that machines can be programmedwith reputation thresholds to ensure that they don’t connect to low-reputation nodes.

4.15.2 Machine Identity Strength

By accepting that humans and devices can have multiple online identities, and leveraging the fact thatidentities are not equally strong, Idem allows the development of systems that utilize identity informationstored on the blockchain instead of focusing on unique users. While machines and people can have multipleidentities, and there is no method to stop them from having multiple identities as there is an economicincentive on Idem for machines to concentrate their identity-strength in a single identity.

4.15.3 Crypto Phonebook

Idem provides global identities to all human users and groups of human users as well. Humans and Groupscan own devices, which are registered locally and owned by humans or groups of humans.

Because Idem provides cryptographically verifiable identities, it can be used to create an encrypted,secure second layer peer to peer communication network. This network can most likely bootstrap off theexcellent work done by the IPFS project.

Machine identities will be constructed differently, as they will need to broadcast their use cases andmachine ID for automatic node discovery. By keeping public cryptocurrency addresses on the Idem, wecreate a crypto “phonebook.” Users not wishing to be listed in the phonebook can simply decline to enterany information. This phonebook is designed to be used to allow programmatic money transfers betweenusers on the IDEM network and between users and machines.

4.16 Skynet Open Network, NovaNova is SON’s native smart contract platform that allows the creation of infinitely scalable distributedapplications, with an IoT and AI vertical.

At the start, Nova will be a lightning fast proof of stake blockchain that will be interoperable withEthereum. This means at the genesis, Nova will start off as an EVM on SON’s Tendermint, allowingfor Web3 compatibility, sharding, and high throughput. Compared to Ethereum’s current Proof-of-Workconsensus, Nova allows transactions to run at 20 times the speed as it can pack 20 times the transactions in

50

a block. This will allow users already familiar with Ethereum’s smart contract platform to migrate over toNova and allow developers to become familiar with SON’s network. Nova will accept light as its gas, similarto how Ethereum accepts Ether. Validators on the Fabric will also help run Nova’s distributed applicationplatform. Later, Nova will contain its own native virtual machine built on Tendermint Core. This virtualmachine called Quantum, or QVM for short, will be a lightweight JVM implementation towards achievinghigh performance when executing chain logic. More details regarding QVM will be updated shortly.

4.16.1 Nova Scalability

With one blockchain, Nova can handle 200 transactions per second. In SON, an infinite amount of distributed-replicated blockchains can be created on SON and work in parallel.

With SON’s cross-blockchain communication protocols, one can create 5 more Novas, enabling the plat-form to have a 1000 transaction per second cap. Multiply the amount of IoT Chains by 5 and Nova canhandle 5000 transactions per second. With this, Nova achieves horizontal scalability and infinite sharding.

Nova also contains the necessary consensus for the Internet of Things and artificial intelligence inter-actions. With current Bitcoin and Ethereum implementations, blocks have a certain confirmation numberbefore they are final. Six confirmations in Bitcoin, for example, is 60 minutes, and six confirmations inEthereum is only 2 minutes. With Nova’s consensus model, blocks are finalized within a second.

As there is instant finality and there is no backlog in transactions, Nova makes the transaction feesmarkedly cheaper than Ethereum.

4.17 Skynet Open Network, SingularityBoth the blockchains on SON and the distributed applications on Nova form something called a distributedKnowledgeNet or a virtual application layer. Here, nodes with data and knowledge from places such asImageNet and possibly data that they collect can be distributed across the network. With the built-inidentity protocols, nodes will be able to find each other in a similar knowledge domain to begin transferringdata, knowledge, and training off one another in a decentralized manner. More distributed applicationscan be created on top of the KnowledgeNet and be interoperable with existing applications. This virtualapplication layer will be an autonomous infrastructure, implementing existing infrastructures such as AWSand distributing vital datasets for training. In this manner, nodes can enter the KnowledgeNet ecosystemand begin a recurrent evolutionary process.

51

Figure 15: SON Virtual Application Layer

The figure above depicts how the virtual application layer would function. Billions of nodes will enterthe Skynet Ecosystem and be able to interact with one another with the KnowledgeNet virtual applicationlayer. Companies and developers will be able to add to this ever-growing network by creating their ownblockchains and DApps. Nodes on the network will be able to leverage these applications and settle priceswith a built-in AI marketplace. The marketplace, distributed applications, and reputation economics willbe released in more detail further along in the development of Skynet Core as they need to be tailored toprovide the necessary applications and make the device the core powers autonomous and fully functioning.

Onyx AI Marketplace In order to make Singularity’s AI data market run smoothly in this distributedtrustworthy circumstance, we have defined and implemented the smart contract systems enable devices toexchange data, pre-trained AI model, or anything of value in a transparent, conflict-free way. Basically,these smart contracts are a series of computer programs that are stored on a Nova ledger/blockchain andspecifies contractual terms, along with possessing the means to enforce those terms. These smart contractswould enable exchanges between devices and update the identity protocol.

Model A

52

Model B

For seller and buyer with very high reputation score, we can execute model A smart contract to speed uptransactions which is very straight forward and highly efficient. Model B smart contract is for the compromisemethod for entities with middle level reputation and can be decided by buyer.

Model C

In between fully distrust entities, we use model C of our smart contract to bind all parties’ responsibilitiesand obligations including escrows who will be the witness for all steps of execution of this smart contract.All entities need to deposit a small amount of coins and also will be rated (reputation score) after this smartcontract is executed completely. All entities who has a positive behavior in the execution will get its depositback and its reputation score will also be increased. On the contrary, the deposit will be lost and reputationscore will be decreased. Escrows entities will also receive rewards in return as trustful witness. After eachtransaction is done, an update will be made to the decentralized identities of each participant.

53

Autonomous Decentralized Machine Learning By coupling various machine learning distributedapplications with the virtual application layer’s identity network, edge nodes can start finding one anotherto begin fine-tuning their networks. With this system, machines will be able to transfer knowledge and workwith one another. Some methods of doing so include

Transfer Learning - Nodes can use pre-trained models and retrain the final layers to have the neuralnetwork become more generalized for other situations.

Data Labeling - Machines or people can label data that other devices can train from.Federated Learning - Edge nodes will be able to train off private, untapped data such as medical data

and collaborate to make a better neural network model.

Some advantages or underlying systems that would enable these types of learning include

Distributed Storage - Datasets can be distributed across the network rather than be centralized onone server

Distributed Processing - Nodes on edge will be able to distribute idle processing power or borrowothers.

Incentives - Devices are incentivized to participate in this system, distribute data, sell idle processingpower, and share algorithms

Knowledge - Edge nodes will be able to transfer knowledge from one node to the other.

The Singularity application layer will provide the necessary applications for devices to interact with oneanother. More specifically, the smart contracts that this layer contains will be for federated learning, datalabeling, distributed computing, and transfer learning.

4.18 Skynet TokenThe Skynet Token offered in the OpenSingularity token distribution will swap over to all cryptocurrencieson Singularity once development is finalized.

Skynet

Token

SON

Light

Singu-larity

54

More exactly, the tokens will swap over to SON, Light, and Singularity. With the Skynet token, ICOparticipants will have access to the end-to-end platfrom’s staking tokens, fee tokens, and application tokens.Coupled with the Skynet Core, these tokens will eventually be the future gas for machines and serve as thebackbone of the intelligent machine economy.

55

5 Conclusion

In summary, the Skynet protocol can be boiled down to the Skynet core and the Skynet Open Network. TheSkynet core is a modular blockchain SoC core, providing a competitive alternative to Arm in the IoT chipsetmarket. All these devices with the Skynet core will come with a SON hardware wallet, enabling devicesto use blockchains and cryptocurrenices with the security of a Ledger wallet but with added bonuses of abrain-on-chip system for AI authentication and human-like intelligent capabilities.

From devices such as self-driving cars, smart cities, and smartphones, all IoT devices can be connectedby the SON network, a scalable IoT infinite-chain platform. SON will enable these devices to exchangevalue in miliseconds, deploy algorithms across the network, train off vital private data, find one another ina secure manner, utilize any other network such as Bitcoin or Ethereum, and learn from its KnowledgeNetcomprised of improved fundamental infrastructures such as AWS and Imagenet. This will be backed by SON’sscalable fault-tolerant architecture, enabling the network to handle various IoT subsystems by providinginteroperability between its private and public blockchains while providing the capacity to handle millionsof transactions in an instant.

With the Skynet core, devices have the capacity to become intelligent and utilize the blockchain network.With the Skynet Open Network, devices can be connected and interact with one another like people do now.

These two components will enable the creation of Skynet, an end-to-end protocol enabling the intelligentmachine economy.

56

AppendicesA Blockchain Overview

With the invention of Bitcoin and its underlying consensus solutions, distributed systems and distributedapplications have finally become a practical solution. Subsequent blockchain platforms have generalized thisnew paradigm, leading to decentralization in many areas.

Currently, blockchain-based decentralized systems are used in many application fields. Blockchain sys-tems, for example, can be used for creating things such as digital currencies, creating decentralized datamarketplaces, and actualizing ideas such decentralized supercomputers. However, scalability issues have sofar prevented its use in data-intensive applications and high-throughput transaction processing systems. Asan introduction to our Singularity network, we present the underlying technology used for decentralization,discuss scalability issues, and identify the most promising solutions for overcoming these obstacles.

A.1 Blockchain IntroductionIn recent years distributed systems have become ready for mainstream adoption, allowing true decentral-ization to become a reality. The application of cryptographic primitives to data structures and consensusalgorithms has made it possible to implement trustless distributed systems in the presence of a Byzantinefailure model, named after Lamport’s Byzantine Generals Problem37.

For a distributed system to defend against Byzantine failures, consensus on system integrity needs tobe reached, even in the presence of malicious participants. This problem was solved practically by theblockchain data structure and algorithms of the Bitcoin digital currency38.

Since, the invention of Bitcoin and cryptocurrencies, blockchain technology has moved on to other ap-plications, ranging from smart contract implementations to Internet of Things (IoT) solutions. During thisgeneralization of use cases, many innovations to the underlying data structures and consensus protocols havebeen made, to solve application-specific problems, as well as general scalability issues. OpenSingularity willleverage all these innovations to build our blockchain.

In this paper, we give an overview of the data structures and algorithms currently available for imple-menting decentralized systems, together with an evaluation of their applicability for high throughput appli-cations, such as IoT use cases. We also present an overview of the Tendermint platform, which we considerthe currently most reliable and scalable solution for applications that require high-throughput transactionprocessing.

A.2 Blockchain and Distributed Consensus TechnologyA.2.1 Asymmetric Cryptography

The decentralization technologies that have emerged in recent years are made possible by cryptography, inparticular, asymmetric cryptography.

Asymmetric cryptography, in contrast to symmetric cryptography, does not rely on a shared key that allparties that participate in a secure communication have to know. Instead, a pair of keys is used, consisting of

37Lamport et al, The Byzantine Generals Problem, ACM Transactions on Programming Languages and Systems (TOPLAS),Volume 4 Issue 3, July 1982

Pages 382-40. https://people.eecs.berkeley.edu/˜luca/cs174/Byzantine.pdf38Satoshi Nakamoto, A Peer-to-Peer Electronic Cash System. 2009. https://bitcoin.org/bitcoin.pdf

57

a private and public key. The private key of a participant is kept private and not shared across the network,as the name suggests. In contrast, the public key can be safely made public. A public key can be used toencrypt a message, which can only be decrypted by the corresponding private key.

Asymmetric Encryption does not only solve the problem of securely transmitting keys over a network, itcan also be used to prove identity and data integrity.

By using his private key to sign a message, a user can prove he is the sender of the message. The senderof a message signed with a private can be verified with the corresponding public key. Furthermore, signingmessages this way can be used to detect whether the message has been altered, meaning that the integrityof data can be verified.

Asymmetric cryptography is used in blockchain systems to identify account holders and sign transactions.

A.2.2 Hash Functions

The second cryptographic primitive that is used in distributed systems is data hashing. Data hashing is atechnique that provides a fixed-sized digest for a variable sized input in an irreversible manner, meaning thatthe original data cannot be deduced from the digest. In practice, this means that reversing the operation iscomputationally extremely difficult and not practical.

Hashing is achieved by use of mathematical functions called hash functions. A collision occurs when twodifferent sets of data hash to the same value. Mathematically, it is, of course, possible to have collisions, asthe input can be of any size with a fixed size output. Possible collision leads to the set of possible inputsbeing much larger than the set of possible outputs. A good hash function should make collisions extremelyunlikely. Furthermore, hashing must be unpredictable.

Hash values can be used to verify the integrity of data, as minor changing of the input data will lead toa different hash value. Essentially, a hash value is a digital fingerprint uniquely identifying a piece of data.

The SHA-256 hashing algorithm39, for example, is used in Bitcoin for various purposes, including beingused to verify blocks in the blockchain have not been modified.

A.2.3 Distributed Hash Tables

Hash functions can be used to create hash tables. Hash tables are data structures consisting of key-valuepairs. Hashing is used to compute indices for data slots called buckets which can hold values.

Distributed versions of the hash table structure can be used very effectively to store data across de-centralized systems. Distributed hash tables distribute the buckets holding data across different nodes ofa peer-to-peer network. The hash value acts as a key for allowing nodes to address data on the network.Figure 2 illustrates how data can be distributed amongst nodes in a distributed system using a distributedhash table.

39Federal Information Processing Standards Publication 180-2. Secure Hash Standard. August 2002.https://csrc.nist.gov/csrc/media/publications/fips/180/2/archive/2002-08-01/documents/fips180-2.pdf

58

Iitem A

Item B

Item C

Hash Function

Hash Function

Hash Function

FF019A

341A0D

24B1A9

Node 1

Node 2

Node 4

Data Keys Network

Figure 2 - Distributed Hash TableTo be practical in a real-world system, in which nodes may join at leave at any time, it is important for

distributed hash tables to use hashing algorithms that do not remap the key space significantly when the setnodes in the system change.

Two commonly used algorithms, consistent hashing40, and rendezvous hashing41, fulfill this property. Inboth algorithms, only the keys owned by nodes with adjacent node identifiers are changed when a node joinsor leaves the system.

A.2.4 Interplanetary File System

A.2.5 Overview

The Interplanetary Filesystem (IPFS)42 is a decentralized solution for file storage making use of distributedhash tables. The main idea behind the system is to provide a globally shared address space for storing filesin a distributed and fault tolerant manner.

Files are divided into blocks and stored across the network. Files are identified and addressed by theirhash values. Version history of each file is maintained similarly as in the Git version control system43.

There is a simple incentive scheme for ensuring nodes keep seeding the content they store, by keepingdebit and credit balances of the number of bytes verified. Blocks are sent to nodes depending on theiraccumulated debt. Nodes that do not collaborate are penalized by being ignored for a certain period.

Note, that the IPFS incentive scheme only encourages nodes to seed the content they host. However,40Karger, D.; Lehman, E.; Leighton, T.; Panigrahy, R.; Levine, M.; Lewin, D. (1997). Consistent Hashing and Random Trees:

Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web. Proceedings of the Twenty-Ninth Annual ACMSymposium on Theory of Computing. ACM Press New York, NY, USA. pp. 654–663

41Thaler, David; Chinya Ravishankar (February 1998). "Using Name-Based Mapping Schemes to Increase Hit Rates".IEEE/ACM Transactions on Networking. 6 (1): 1–14

42The Interplanetary Filesystem Whitepaper. Juan Benet. IPFS - Content Addressed, Versioned, P2P File System (DRAFT3). https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf

43Git version control system. https://git-scm.com/

59

nodes only store files they choose to host. In the current version, nodes can “pin” files to host them. Thereis no guarantee that content will remain persistent in the system.

More sophisticated incentive schemes, for encouraging nodes to host content, such as Filecoin44, can beimplemented in additional layers.

A.2.6 Architecture

By using hashes to address a file, IPFS is a content addressed system. This has the interesting property thatduplication of files is detected, as the same content computes to the same address. When a user requests afile, the network serves the content identified by a hash value.

Their hash value also identifies the blocks which make up a file. This leads to a data structure calledMerkle Directed Acyclic Graph (DAG). We will discuss DAGs and Merkle proofs in Section 3 of this paper.

IPFS uses a series of sub-protocols to maintain the network to manage the following primitives:

• Identities. Node identities and verification

• Network. Connections between nodes

• Routing. Information for locating nodes and objects

• Exchange. Protocol for managing block distribution

• Objects. Merkle DAG of content addressed objects with links

• Files. Versioned file system hierarchy

• Naming. Naming system.

A.2.7 Use Cases

IPFS is often mentioned as a decentralized alternative to the HTTP protocol. The idea behind storing webcontent on IPFS is to break the currently centralized nature of the World Wide Web in terms of hosting.

IPFS is also frequently used as a storage layer associated with blockchain applications. Blockchain storageis slow and expensive, and it is currently not practical to store large chunks of data on a blockchain. Analternative architecture is storing metadata, including IPFS identifiers on the blockchain, and the bulk ofthe data on the faster and more lightweight IPFS network. The IPFS links act as digital fingerprints toensure the integrity of the data, by being stored immutably and timestamped on a blockchain.

IPFS is even efficient enough to be used as data exchange layer in IoT data marketplaces if combinedwith a high transaction throughput blockchain. Such as system could be a reliable alternative to the datamarketplace45 currently being developed to run on the DAG-based IOTA system. We will discuss IOTA andits drawbacks later on in this paper.

A.2.8 Blockchain Ledger

The concept of a Blockchain has grown out of Bitcoin and subsequent cryptocurrencies. The original Bitcoinpaper did not use the word blockchain, and it took some time for the term to emerge, to describe theunderlying technology that permits implementing digital currencies and other applications.

44Filecoin. https://filecoin.io/45IOTA data market https://data.iota.org/

60

At the most basic level, a blockchain is a distributed ledger of transactions implemented on top of apeer-to-peer network in the presence of a Byzantine failure model. The system depends on an underlyinglinked list data structure, implementing a state machine with immutable state transitions.

The above definition introduces a series of properties a blockchain provides:

• Distributed Ledger of transactions. Transactions are recorded in a ledger which is distributed to allnodes. Each transaction is atomic in that it executes completely or not at all.

• Peer-to-peer network. The system is implemented on a distributed network of equal nodes. Nodes mayjoin or leave the network freely.

• Byzantine Failure Model. Nodes reach consensus on the outcome of each transaction, meaning thatthere is a single version of the globally accepted system state at all time. Malicious nodes cannotcorrupt system state, as long as the majority of the network’s computational resources remain honest.Consensus protocols typically incentivize nodes to maintain state integrity.

• State machine. A blockchain can be viewed as a state machine. State machines are systems modeledas a series of states through which the system transitions. State machines are termed finite if there isa finite number of predefined possible system states. An infinite state machine has an infinite numberof possible states. In this model, transactions stored on the distributed ledger are state transitions,whereas the state after each transaction represents a state vertex in the state machine.

State 1 State 2 State 3

State 4 State 5

Transition 1 Transition 2

Transition 3

Transition 4

Transition 5

Figure 3 - State Machine

• Immutability. Transactions in the blockchain are immutable, meaning they cannot be undone ormodified. This is achieved by sealing blocks of confirmed transactions cryptographically, as discussedbelow.

A.3 Basic Data StructuresA.3.1 Linked List of Blocks

As discussed above, at the heart of a blockchain, there is a distributed ledger. This distributed ledger istypically represented as a linked list of numbered blocks. Figure 4 illustrates a simplified version of the datastructure commonly used.

Each block contains a list of transactions that have been included in the block in a specific order usinga consensus protocol. In practice, the actual transactions may not be included in the block but referenced

61

through the root hash of a Merkle tree (explained below). However, conceptually, the transactions are partof the block.

Each block is “sealed” by being cryptographically referenced in the next block. This is achieved by everyblock including a hash value of the previous block.

Changing data in a block, for example by altering a transaction would modify the hash value of the blockleading to an instantly detectable integrity violation, breaking the chain. The use of consensus protocols,which will be discussed later on in this paper ensures that nodes have to adopt the correct (majority) versionof the chain. An attack attempting to modify a block increases in computational difficulty with every newblock being added.

Blocks are created at a constant frequency, regulated by the underlying consensus protocol.

A.3.2 Merkle Trees

A key data structure used in blockchains is the Merkle tree46, named after its inventor Ralph Merkle. Asexplained above, hashing is extensively used in blockchain technology to provide cryptographic fingerprintsof data that can be used to prove the integrity of data.

A Merkle tree is an efficient way of hashing data by dividing it into small chunks. Chunks are hashedindividually, and the resulting hashes are combined and hashed in pairs. This process is repeated up thetree until a single root hash is calculated. The structure of a Merkle tree is illustrated in Figure 3.

L1 L2 L3 L4

hash(L1) hash(L2) hash(L3) hash(L4)

hash(hash 0-0+ hash 0-1)

hash(hash 1-0+ hash 1-1)

hash(hash 0+ hash 1)

Top Hash

Hash 0 Hash 1

Hash 0-0 Hash 0-1 Hash 1-0 Hash 1-1

Data Blocks

Figure 5 - Merkle TreeAn interesting property used in blockchain technology is the ability to perform a Merkle proof on data.

46US patent 4309569, Ralph Merkle, "Method of providing digital signatures", published Jan 5, 1982, assigned to The BoardOf Trustees Of The Leland Stanford Junior University

62

A Merkle proof consists in proofing the integrity of data by verifying the correctness of the hashing up thebranch of a Merkle tree.

Merkle proofs are frequently used in blockchain technology to optimize data storage. In Bitcoin, forexample, only the Merkle root of transactions stored in a Merkle tree has to be included in the blockheader. Light clients can request Merkle proofs for individual transactions without having to download allthe transactions.

A variation of Merkle trees called Merkle Patricia tree47 is used in Ethereum48. This variation on Merkletrees is optimized for providing quick insertion and deletion in key-value storage maps. This is achieved byensuring that the depth of the tree is bounded and that Merkle root only depends on the data, not on theorder in which updates to the data are made. The result is a data structure with O(log(n)) efficiency forinsertion, deletion, and lookup of data.

In Ethereum each block contains three Merkle Patricia roots, referencing the state (the storage of smartcontracts), transactions and transaction receipts.

A.3.3 Directed Acyclic Graphs

Some distributed ledger projects use directed Acyclic Graphs (DAG) as an alternative to the linked listblockchain data structure.

Graphs consist of vertices and edges, with edges connecting different nodes. A DAG is a graph withcertain mathematical properties:

• A DAG has a finite number of vertices and edges.

• Each edge is directed from one vertex to another

• The graph is acyclic, in that there is no possible path starting from a given edge that leads back tothe path’s starting block.

A.4 Blockchain EvolutionThe concept of a blockchain was first introduced by Bitcoin, and consequently, cryptocurrencies were thefirst application of this new technology.

Representing transferrable value is made possible by achieving consensus on transactions without theneed for a trusted third party. Participants are incentivized to maintain integrity by rewards paid in thecryptocurrencies in almost all blockchain implementations.

Bitcoin uses an unspent transaction output model (UTXO). Transactions consist of inputs and outputs,each of which holds a certain value. Transactions are chained together by using outputs from one transactionas inputs for another (Figure 5).

Figure 7 - Bitcoin Transaction Model (source: Original Bitcoin Paper)In the UTXO model, there is no notion of an account with a balance on the blockchain. Instead, client

software adds up UTXOs directed to addresses to calculate balances. An address represents a private-publickey pair.

Most cryptocurrencies work similarly, although some may substitute the UTXO model for an account-based model. Variations exist in the consensus algorithms used, the block generation frequency, the totalcurrency supply, and other parameters.

47Merkle Patricia Tree Specification. https://github.com/ethereum/wiki/wiki/Patricia-Tree48Ethereum Blockchain. https://www.ethereum.org/

63

In cryptocurrencies, transactions change system state by moving value between accounts or addresses.It did not take long for people to realize that this concept can be generalized to other types of transactions,such as transferring property deeds or other assets modeled on the blockchain.

Taking this concept even further to general purpose computing has led to the second generation ofblockchains that have the property of Turing completeness. A computer system is colloquially said to beTuring complete if it allows modeling any problem computationally.

The most well-known general-purpose blockchain is Ethereum, proposed first in 2013 by Vitalik Buterin49.Ethereum implements a Turing complete virtual machine which allows deploying decentralized applicationsin the form of smart contracts.

In Ethereum transactions are transitions between arbitrary state. Computational resources are pro-tected by associating each virtual machine operation and storage usage with a cost termed gas. Like mostblockchains, Ethereum makes use of a cryptocurrency, which is used to pay for gas and as an incentivemechanism in the consensus protocol.

Scalability Tradeoffs First and second generation blockchains have limited scalability, which makes themunsuitable for high throughput transaction systems and systems that deal with large amounts of data.

It has become increasingly clear that to achieve scalability in a distributed system, trade-offs have tobe made. Ethereum founder Vitalik Butterin expressed this as the scalability trilemma50. The trilemmastatement argues that there are three interacting axes: decentralization, scalability, and security. Withcurrent technology, at least one axis has to be relaxed to optimize the remaining two.

Second Layer Solutions Scalability of cryptocurrency-centered blockchains can be increased by movingtransactions onto a second layer off-chain and only use the underlying blockchain for settlement. Paymentchannels and the Lightning Network51 are such solutions for the Bitcoin network.

Channels, to be used to make off-chain payments between two parties, are secured by deposits on theblockchain and are settled by on-chain transactions occasionally.

The Raiden Network52 is Ethereum’s solution to off-chain scalability.

On Chain Solutions The second layer solutions discussed above are viable solutions for payments andtoken transfers only. To improve scalability in a more general way, several on-chain solutions are currentlyin development, both on existing blockchains, such as Ethereum, and in purpose-built third generationsystems.

One suggestion to improve scalability focuses on improving transaction throughput and storage capability.Currently, blockchain nodes tend to keep a copy of the full system state and process all transactions. Thislimits the blockchain’s transaction throughput to that of a single node. Furthermore, each node requiresan ever-increasing amount of storage capability. Sharding is a technique that allows distributed processingand storage between different parts of the blockchain. This has to be done in a way that allows each nodeto process fewer transactions and store only part of the state, while ensuring overall system integrity ismaintained.

49A Next Generation Smart Contract and Decentralized Application Platform. Vitalik Buterin. 2013. https://github.com/ethereum/wiki/wiki/White-Paper

50On Sharding Blockchains. https://github.com/ethereum/wiki/wiki/Sharding-FAQ51The Bitcoin Lightning Network: Scalable Off - Chain Instant Payments. Joseph Poon and Thaddeus Dryja. 2016. https:

//lightning.network/lightning-network-paper.pdf52The Raiden Network. https://raiden.network/

64

Sidechains are application specific secondary blockchains maintained only by a subset of nodes that havean interest in the sidechain’s application. The sidechain is linked to the main chain, which is used as asettlement layer.

Essentially, sidechains organize blockchains in a tree structure. Plasma53 is Ethereum’s sidechain solutioncurrently being developed.

Cosmos54, a system based on Tendermint55, is natively structured in trees of blockchains. We will discussTendermint and Cosmos in more detail further on in this paper.

DAG Chains Another approach to achieve scalability in distributed ledger systems is to replace theblockchain data structure with a DAG.

One of the most cited distributed ledger projects using the DAG data structure as a blockchain replace-ment is IOTA56, which not only replaces the underlying linked list data-structure but also removes blocksand simplifies the consensus algorithm.

In IOTA, transactions are individually added to a DAG structure called tangle (illustrated in Figure 5).

Figure 8 - IOTA TangleFor a node to emit a transaction to the tangle, it needs to validate two previous transactions. Vertices

in the DAG represent transactions and edges approvals. There is a transitive relation:

confirm(a, b)^confirm(b, c) ! confirm(a, c)

This means, that if a transaction a directly confirms a transaction b and transaction b confirms transactionc, we consider transaction a to indirectly confirm transaction c. All transaction confirmations lead backto a genesis transaction, in the same way blocks in a linked list lead back to a genesis block in linked listblockchain data structures.

As an interesting side node, IOTA also provides an identity layer through a second layer called MaskedAuthenticated Messaging (MAM). MAM makes use of IOTA’s gossip protocol to transmit encrypted andauthenticated messages through the network.

IOTA is aimed at high throughput transaction processing systems, such as the Internet of Things (IoT)data transfers. The system currently extremely relaxes decentralization to achieve scalability and securityby running a coordinator node. This coordinator will supposedly be removed once the system has reachedcertain critical transaction volume.

53Plasma: Scalable Autonomous Smart Contracts. Joseph Poon and Vitalik Buterin. 2017. https://plasma.io/plasma.pdf54The Cosmos Network. https://cosmos.network/55Tendermint Blockchain Consensus Platform. https://tendermint.com/56IOTA Project. https://iota.org/

65

It seems likely that security will be compromised in the future when the coordinator is switched off.In the absence of an incentive-based consensus protocol, there is no mathematical proof that DAG basedtransaction confirmation can guarantee secure operation once the coordinator is removed.

We argue that given current technology, the most promising trade-off aimed at improving scalability isintroducing a Delegated Proof of Stake-based (DPoS) Byzantine Fault Tolerance consensus protocol. TheTendermint platform which we will discuss later on in this paper provides an elegant solution to this.

A.5 Consensus AlgorithmsA.5.1 Proof of Work

Algorithm The first consensus algorithm used by a blockchain was Bitcoin’s Proof of work. Proof of workconsists of nodes competing to solve a cryptographic puzzle. The node finding the solution first decides onthe next block to be included in the linked list of blocks in the case of distributed ledgers. Competing nodesare called miners in blockchains that use proof of work.

In Bitcoin, each block includes a field called the nonce. Miners fill up blocks with transactions and thentry to calculate the SHA-256 hash of the block. The aim is to find a hash value with a certain number ofleading 0s. The nonce is incremented and the hash value recalculated until a hash with the correct numberof leading 0s is found.

The winning miner’s block is accepted and added to the blockchain. The miner is awarded the miningreward (newly created coins) and the transaction fees. The process is regulated to produce a new block atan average frequency of 1 block every 10 minutes by adjusting the difficulty (modifying the required numberof leading 0s).

All proof of work-based blockchains function similarly, although the actual cryptographic puzzle maychange. Ethereum uses the Keccak algorithm, which forms the basis of SHA-3. Furthermore, blockchainsthat produce new blocks at a higher frequency, such as Ethereum, have a higher chance of two minersproducing a new block at the same time, resulting in more discarded blocks, often called orphan blocks.To mitigate this effect, Ethereum’s and other blockchain’s consensus mechanism have provisions for alsoincluding such blocks into the blockchain.

Hardware Support Cryptographic puzzles, such as those based on calculating SHA-256 hashes can beaccelerated significantly by certain types of hardware. The calculations involved are inherently parallelizable.

This first led to powerful Graphics Processing Units (GPUs) being used for cryptocurrency mining. Thenext step led to special purpose hardware being developed, leading to the current situation, in which almostall Bitcoin mining is performed on so-called application-specific integrated circuits (ASICS).

Some blockchains use ASICS-resistant algorithms, which are specifically designed not to be parallelizable,for example by being memory intensive.

Criticism The work being performed in proof of work consensus algorithms is not used for anything useful.In fact, most of the work is discarded, due to the competitive nature of the protocol. Only the winning’snode work is reserved in the form of a new block, and even this work consists merely in re-calculating a hashvalue repeatedly, serving no other purpose than being the deciding factor in competition.

While there have been attempts to substitute proof of work calculations for something useful, suchas discovering new prime numbers57, none of the major blockchains have managed to make use of thecomputational effort in a meaningful way.

57Primecoin. http://primecoin.io/

66

Apart from not consisting of particularly useful calculations, proof of work is a very computationalintensive protocol. Thus, it also has very high energy consumption.

A.5.2 Proof of Stake

Proof of stake is an alternative protocol to proof of work that uses wealth instead of computational poweras the basis for deciding on the next block.

Nodes stake a certain number of coins in the blockchain’s native cryptocurrency to be used as collateralin case of dishonest decision making. Nodes essentially bet on the next block. The winner is chosen by analgorithm which mixes randomness with the number of coins at stake. In most implementations, the biggera participant’s wealth, the higher the probability of being chosen as a winner. However, other factors, suchas coin age may be taken into account. In the case of a network fork, participants vote on the correct chainby committing their coins, resulting in loss of coins by supporting the wrong chain.

Ethereum is scheduled to switch from proof of work to proof of stake. Ethereum’s proof of stake consensusprotocol is called Casper58.

A.5.3 Delegated Proof of Stake

In Delegated Proof of Stake, the nodes in the system vote on delegates which participate in the proof of stakealgorithm. Misbehaving delegates can be voted out. In delegated proof of stake, decentralization is tradedfor performance, in that the system is more centralized, depending on the voting mechanisms employed.

A.5.4 Proof of Weight

Proof of Weight is similar to the proof of stake, with the difference that the stake is not based on wealth in theblockchain’s cryptocurrency. Instead, the availability of other resources is used to determine the probabilityof a node being chosen to supply the next block. For instance, in Filecoin59, the amount of storage providedis used.

A.5.5 Proof of Authority

Proof of authority is a highly optimized protocol in which only trusted nodes are allowed to validate trans-actions and create blocks. These nodes might use any algorithm to decide on who chooses the next block,for example, a simple round-robin approach.

Proof of authority networks are of course not truly distributed systems as they are highly centralized,but are useful for large-scale test networks, such as the public Kovan and Rinkeby Ethereum test networks,which are protected from denial of service attacks by using proof of authority.

A.5.6 Practical Byzantine Fault Tolerance

Practical Byzantine Fault Tolerance60 was the original proposal aimed at solving Lamport’s ByzantineGeneral Problem cited above. The PBFT algorithm relies on a state machine that is replicated on eachnode. Each state represents a system view through which the state machine transitions.

58Casper the Friendly Finality Gadget. Vitalik Buterin and Virgil Griffith. 2017. https://arxiv.org/abs/1710.0943759Filecoin Storage Blockchain. https://filecoin.io/60Practical Byzantine Fault Tolerance. Miguel Castro and Barbara Liskov. Proceedings of the Third Symposium on Operating

Systems Design and Implementation, New Orleans, USA, February 1999

67

The consensus process is based on clients sending a request for a service to a primary replica whichtransmits the requests to the backup replicas. Nodes reach an agreement on adopted views by an algorithmthat relies on at least one two thirds of the nodes to be honest. This means that the number of nodes thatare required to collaborate is slightly higher as in the proof of work-based solutions, where more than 50 %or computational power is enough to secure the network.

The advantage of PBFT, however, is a very high transaction throughput.The disadvantage is that the algorithm scales badly. In practice, it can only be used to reach consensus

between a small number of nodes.

Delegated Proof of Stake Practical Byzantine Fault Tolerance DPoS BFT is used in Tendermint.The system combines the advantages of Delegated Proof of Stake with the high transaction throughput ofPBFT. Validator nodes are chosen based on the number of coins they put at stake and participate in anoptimized BFT protocol.

The BFT algorithm used in Tendermint is an improvement on the original PBFT algorithm. This resultsfrom running the algorithm on a blockchain data structure, which removes message overhead needed tocommunicate view changes between node.

We believe that the Tendermint’s DPoS BFT consensus protocol is currently the best solution for achiev-ing the high transaction throughput required by certain applications while preserving sufficient decentraliza-tion and security guarantees of conventional blockchain technology.

A.6 SecurityA.6.1 Proof of Work Security

Double Spending Digital cash systems rely on account balances and transfers to be represented digitallyin data structures. This introduces the problem guaranteeing that a digital asset, such as a cryptocurrencyunit, can only be spent once. It is trivial to solve this double spending problem in a centralized system, inwhich a trusted party is in charge of keeping track of balances and transactions. Banks fulfill this role in thetraditional monetary system.

In a decentralized system, without such a trusted bookkeeper, it is up to the consensus protocol tosolve the double spending problem. Double spending was first solved in Bitcoin. Although the doublespending problem, as solved in Bitcoin and described here, relates to monetary transactions, the concept isgeneralizable to any digital asset that can be represented on a blockchain.

The blockchain’s transaction immutability property prevents transactions from being undone and bal-ances from being modified retrospectively. However, there is a period, in which double spending can occur,before a transaction has been fully propagated through the network. This can lead to a situation, in whicha malicious spender makes two payments in short succession, the sum of which exceeds his balance. One ofthe transactions will succeed, the other will fail.

Once a transaction has been propagated through the network, the UTXO set in Bitcoin or the equivalentin other blockchains has been modified. Even though the transaction is not included in a block yet, it isrelatively safe to assume double spending cannot occur. Such transfers are usually assumed valid for smalltransfers or micropayment.

However, to be completely safe of double spending, the transaction should have been confirmed, andseveral additional blocks should have been added to the blockchain. By convention, a transaction with sixconfirmations is considered secure.

68

Malicious Miners and Forks One or more nodes may wish to modify a transaction or change the stateof the blockchain. To do this they produce a fraudulent block and transmit it to the network.

The way consensus protocols work, other nodes that also validate transactions should reject the blockand wait for a correct solution. The blockchain now splits in two, a situation which is known as a fork. Thistype of fork should not be confused with the process of updating the blockchain’s software protocols, whichis also known as forking and may result in a similar split in the network if some nodes do not adopt the newprotocol version.

Honest miners continue adding blocks to the correct chain, whereas malicious miners support theirversion of the blockchain. Essentially, there are now two competing chains. In most cases, the minoritychain eventually dies out because of lack of support.

Figure 9 depicts a fork created by a set of nodes adopting a different version of a block.

Correct Chain

Malicious Chain

fork

Figure 9 - Malicious ForkFor a malicious set of nodes to modify the blockchain and have their version of the chain adopted by the

majority, they would need more than 50 % of the networks computational capacity. An attack consisting ofmalicious miners modifying the blockchain is therefore called a 51% attack.

Note, that modifying the blockchain retrospectively becomes more difficult with each added block, asmore blocks need to be recalculated. For this reason, six block confirmations are often quoted as the securewaiting period before a transaction is considered completely secured.

Denial of Service Any networked system is vulnerable to a denial of service (DoS) attacks. Such anattack consists in flooding the network artificially with requests, to block resources and make the networkunusable.

Decentralized systems are generally considered more resistant to DoS, but there are situations in whichblockchains can be attacked this way.

DoS is prevented in blockchains by associating a cost with transactions and resources. In the case ofEthereum, gas is required to execute transactions and use storage. In the past, the cost of operations hashad to be increased via a protocol change because of a DoS attack61 62.

Test networks that use worthless test Ether have also frequently suffered from DoS attacks.

A.7 Proof of Stake SecurityMalicious Validators and Forking In proof of work consensus, forking can occur the same way it doesin proof work-based solutions. Validators might not agree on the correct version of the next block and a forkin the chain occurs. As in the proof of work consensus, validators vote on which chain to support.

61EIP150 - https://github.com/ethereum/EIPs/blob/master/EIPS/eip-150.md62EIP 161 - https://github.com/ethereum/EIPs/blob/master/EIPS/eip-161.md

69

It is often argued that while an attack on the network is cheaper in proof of stake, it is also easier for thecommunity to react to the attack and correct the problem.

Nothing at Stake Problem Early proof of work systems suffered from the nothing at stake problem.This problem occurs when nodes decide to support both chains in case of a fork. As they have nothing tolose, nodes may create new blocks in each chain, to guarantee the best outcome for themselves, no matterwhich chain establishes itself as the majority chain.

To solve the nothing at stake problem, most proof of stake blockchains have introduced penalties forsupporting the wrong chain. This means that, in addition to block awards, block penalties exist and arededucted when a node supports a minority chain in a fork.

Long Range Attacks A long-range attack is an attack scenario, in which a previous validator that hasbecome unbound creates many blocks, starting sometime in the past, usually at the last block the nodecreated while being a validator. As there is no proof of work, building a long chain is not very expensive.

The problem has been solved by a strategy used in the Tedermint-based Cosmos project63, amongstothers. The solution consists in introducing a so-called "unbounding period", in which the staking depositremains non-transferable. Furthermore, light clients are protected by verifying the hash value of a recentblock from multiple sources when connecting. Light clients are also forced to re-sync with the validator setwith a frequency higher than the duration of the unbounding period.

A.7.1 Directed Acyclic Graph Security

A DAG data structure does not necessarily change the security model, but the block-less implementation ofthe IOTA tangle does.

As we have already explained above, IOTA adds each transaction to the tangle after receiving twovalidations and creates a DAG of verified transactions. Security of the model currently depends on acoordinator node. Once the coordinator is switched off, the system theoretically remains secure, as longas there is sufficient transaction throughput. However, there is currently no mathematical model that provesthe system can remain secure in all circumstances. Importantly, in the absence of an incentive system, itmay be easier to attack the system with a DoS attack.

Finally, IOTA introduces a complex key system which relies on keys that can only be used securely once,before having to be discarded. This model has been criticized for increasing the likelihood of user error.

A.7.2 Byzantine Fault Tolerance Security

We have already mentioned that in Byzantine consensus more than two-thirds of the node must be honestto ensure correct functioning of the system. We can reach this conclusion mathematically. To do so, wedefine a functioning system as providing both safety and liveness, meaning that we wish honest nodes tovote correctly and we want to obtain votes for all operations.

Consider a system with n nodes, divided into h honest nodes and d dishonest nodes:n = h+ d Considera scenario in which the system’s state can move in two directions and the honest nodes are split evenly intheir voting. Dishonest nodes can agree with both camps, leading to the following number of nodes agreeingon both conflicting system states: n = h

2 + d We can therefore define a threshold t for our safety property:t > h

2 + d In addition, for the number of nodes required to agree to move forward must be no more than the63Cosmos Whitepaper Appendix – Preventing Long Range Attacks. https://cosmos.network/whitepaper#appendix

70

number of honest nodes (liveness property): th Combining the two conditions for t we get: h�t > h2 + d

This leads us to: h > h2 + d And eventually: h

2 > d Thus, we the system can continue functioning correctly,as long as more than two thirds of the nodes are honest.

A.8 Fault ToleranceA.8.1 Failure Models

Crash-Failure Model When designing a distributed system, fault tolerance considerations are important.The type of faults a system can tolerate must be defined. To do so, a failure model has to be chosen. Thesimplest failure model is the crash-failure model. In this model, nodes may crash and recover. The modelis supported by all blockchain implementation, as the underlying protocols assume that nodes can join andleave at any time. Usually, for a node to send transactions, it has to wait until it has fully synchronizeditself to the latest blockchain state.

Network Partitioning Unreliability of communications is intrinsic to distributed systems, and a blockchainimplementation has to make provisions for recovering from networking issues.

In distributed systems network links may fail, leading to isolated nodes and network partitions. A networkpartition is a disconnected sub-network that cannot communicate with the rest of the system. Supportingand recovering from network partitioning involves interesting trade-offs, which we will discuss further on inthis section.

Byzantine Failure Model We have already discussed the Byzantine models in relation to consensusprotocols. The Byzantine failure model is the underlying model that makes Byzantine consensus necessary.In this model, nodes may fail in arbitrary ways, even by acting maliciously. Practically supporting theByzantine failure model is one of the key reasons for using a blockchain based system.

Timing Failures Finally, a distributed system is subject to timing failures. This means that nodes maymeasure time differently and system clocks cannot be assumed to be perfectly synchronized. Furthermore,messages may be subject to delays. In theoretical distributed systems research, a distinction is made betweensynchronous and asynchronous systems. In the former, clocks are perfectly synchronized, and messagedelivery is guaranteed within a specific time limit. In asynchronous systems, no such assumption can bemade.

Of course, synchronous systems are not very practical. Blockchain systems tend to implement practicalsolutions, such as making weak requirements on clock synchronization within a maximum permitted offsetand using consensus to agree on a single view of message ordering.

A.8.2 Fault Tolerance Properties

Consistency For a distributed system to be considered fault-tolerant, there are various properties a systemshould fulfill. The first property is called Consistency.

Informally, consistency in distributed systems refers to the fact that all nodes should have the same viewof the systems state. In a strict interpretation, this means that every read operation on any node shouldreturn the result of the latest write operation on any node.

71

In practice, this is of course very difficult to achieve, as consistency relies on the order of messages tobe emitted and received throughout the network. This is further complicated by system clocks not beingcompletely synchronized. Message ordering cannot be guaranteed by simply timestamping messages.

Several consistency models exist in Theoretical Computer Science, the most important of which are:

• Atomic Consistency64. This is the strictest model and implies all write operation being seen instantlyon all nodes. Strict consistency is, of course, a purely theoretical model that cannot be implementedin practice, as any message is subject to a delay in a real system.

• Linearizable Consistency65. Atomic consistency can be relaxed to take into account message deliverydelays, placed under a real-time constraint. The model is still not very practical for most real-worldsystems.

• Sequential Consistency66. Relaxing the constraints further, a model can be defined, in which each theresult of operations is seen in the same order on every node in the system. However, the order ofoperations may vary between repeated invocations of the operations. Informally, it can be said thatnodes agree on the order of transactions.

• Causal Consistency67. In this model, only write operations that are causally related have to be seen inthe same order on each node. Informally, this means only write accesses on data that depend on eachother have to be executed in the same order on all nodes.

• FIFO Consistency68. The weakest model presented here states that all write operations emitted froma single node have to be seen in the same order on all nodes. Operations emitted from other nodesmay be interleaved in different orders.

In Blockchain systems, miners or validators order transactions sequentially in the order they see fit. Theyusually use an optimized profit algorithm for including transactions based on transaction fees and transactionsize. Once a block is accepted, all nodes adopt this order. Therefore, blockchain consensus is based on asequential consistency model.

Availability The second property of a fault-tolerant distributed system is availability. Availability isthe capacity of a system to respond to a request and is measured in the percentage of time a system isfunctioning correctly (expected uptime versus expected downtime). Thus, we can define availability asfollows: A = E[uptime]

E[uptime]�E[downtime] Now we can define the status of the systems S at time t as a func-tion: S(t) = {1,working0,notworking} We can express the probability that a system is working at a giventime:A(t) = P [S(t) = 1] = E[X(t)]Presenting this on an interval of the real line, we get average availability(with c being an arbitrary constant > 0: Ac =

R c0 A(t)dt Two measurements related to availability are mean

time to failure (MTTF) and mean time to repair (MTTR). The former refers to the time a system manages64Leslie Lamport. On interprocess communication. part I: Basic formalism.Distributed Computing, 1(2):77-85.65Herlihy, M. and Wing, J. M. (1990). Linearizability: A correctness conditionfor concurrent objects. ACM Trans. Program. Lang. Syst., 12(3):463-492.66Lamport, L. (1979). How to make a multiprocessor computer that correctlyexecutes multiprocess programs. IEEE Trans. Computers, 28(9):690- 691.67Lamport, L. (1978). Time, clocks, and the ordering of events in a distributedsystem. Commun. ACM, 21(7):558-565.68Lipton, R.J.; J.S. Sandberg. (1988). PRAM: A scalable shared memory (Technical report). Princeton University. CS-TR-

180-88.

72

to remain to respond correctly before a failure, and the latter refers to the time it takes a system to recoverfrom a failure.

Partition Tolerance The final property for defining the fault tolerance of distributed systems is the abilityto deal with communication failures. Distributed systems are said to be partition tolerant if individualnetwork partitions can continue independently in case of a network failure and recover after the network hasre-joined.

In a blockchain system, network partitions invariably lead to two versions of the chain that need to beconsolidated by the consensus algorithm.

CAP Theorem The CAP theorem69 (Figure 8) is a statement on the interrelation between consistency,availability and partition tolerance. The theorem states that it is impossible to give strong guarantees onmore than two of the three properties.

In practice, this means that in the case of network partitions, a system can either provide high availabilityor strong consistency. This is intuitively obvious, as it is only possible to continue operating in two or moredisjoint partitions independently if overall consistency is relaxed.

In Blockchain systems the theorem is important if proof of stake consensus protocol is used. The consensusalgorithm has to favor one over the other. BFT based consensus protocols, such as the protocol used byTendermint strongly favor consistency over availability.

A.9 ShardingA.9.1 Principles

Sharding is a concept borrowed from database technology, where databases are partitioned horizontally.Different partitions, or shards, are stored on different servers to distributed load.

In blockchain systems, each node traditionally keeps a copy of the full blockchain, including state andtransactions. In reality, the transaction history might be pruned for storage efficiency, but conceptually thewhole chain is replicated on each node.

Applying the sharding principal to blockchains is a measure aimed at improving the scalability of thesystem. As in database technology, nodes only hold certain shards of the blockchain, distributing storageand transaction processing load across the network.

There is an obvious issue in sharding blockchains, in that everything in a linked list of blocks is sequentialand splitting this up into different shards requires a more hierarchical approach. Essentially, a series ofindividual chains are created, one for each shard.

To maintain the overall chain, these shards need to somehow connect to the main chain. This is similar tothe sidechain scalability method discussed in section 4.3. However, shards may not be set up for a particularapplication and do not require application-specific nodes to explicitly maintain the chain. Collators on eachshard are responsible for creating collations, which are descriptions of the shards state. Collations fromdifferent chains are included in blocks on the main chain.

Ethereum’s Plasma sharding model70 introduces a new hierarchy of nodes for this purpose, consisting ofthe following node types:

69Seth Gilbert and Nancy Lynch, "Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant webservices", ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51–59.

70https://medium.com/@icebearhww/ethereum-sharding-and-finality-65248951f649

73

• Super full-nodes maintain every collation and the main chain. They also integrate collations fromdifferent shards into main chain blocks.

• Top-level nodes process the main chain and give access to all shards.

• Single-shard-nodes are the same as top-level nodes, but also maintain all the collations of their partic-ular shard.

• Light nodes only maintain block headers from the main chain but can request state from differentshards when required.

In a sharded system following this model, blocks are valid when the transactions in all included collationsare valid. Additionally, all collations need to be signed by a certain percentage of collators, typically twothirds.

A.9.2 Challenges

Single-Shard Takeover Attack A problem in sharded blockchains is that each shard is now maintainedby a much smaller number of nodes than the whole chain. It is thus theoretically much easier for an attackerto get hold of a sufficient majority in a single shard to manipulate data.

This problem is known as the 1% attack, based on the assumption that in a 100-shard system it takes1% of the networks hash rate to dominate the shard28.

This problem can be mitigated by choosing collators for shards through random sampling and changingthis sampling frequency.

Choosing and changing collators randomly is much easier in proof of stake-based systems, as collatornodes can just be randomly sampled from the set of validators that participate in staking.

Cross-Shard Communication Communication between shards has to performed via the main chain.The difficulty, in this case, is to maintain the atomicity property of transactions.

Sending a transaction from shard A to shard B can be achieved in the following steps:

1. Send a transaction to shard A, applying state delta d.

2. Create a transaction for shard A, which is stored in Merkle root.

3. Send a transaction to shard B, including the Merkle receipt as data.

4. Shard B checks that the Merkle receipt has not been spent yet.

5. Shard B processes the transaction applying state delta d and saves the fact that the Merkle receipthas been spent.

6. Shard B creates a new Merkle receipt that can be used in subsequent transactions.

74

A.10 DiscussionIn this section, we have presented an overview of the technologies used for decentralization. Blockchainand related technology can be used to develop secure consensus-based decentralized systems. We havediscussed several key technologies and data structures and their purpose. We have also highlighted security,fault-tolerance and scalability issues.

While blockchain technology makes some innovative applications possible, it is currently not well suitedfor data-intensive applications or use cases that require high-throughput transaction processing.

We believe that the most promising solutions for such as system are based on a decentralized off-chain stor-age layer, such as IPFS, in combination with a lightweight and flexible consensus layer, such as a Tendermint-based DPoS BFT consensus blockchain architecture.

75

Citations

1. https://www.news.iastate.edu/news/2017/06/07/exciton-polaritons2. https://physics.aps.org/featured-article-pdf/10.1103/PhysRevX.7.0110153. http://ieeexplore.ieee.org/document/1251416/?anchor=references4. Ilya Sutskever, Oriol Vinyals, and Quoc V. Le. 2014. Sequence to sequence learning with neural

networks. In Proceedings of the 27th International Conference on Neural Information Processing Systems -Volume 2 (NIPS’14), Z. Ghahramani, M. Welling, C. Cortes, N. D. Lawrence, and K. Q. Weinberger (Eds.),Vol. 2. MIT Press, Cambridge, MA, USA, 3104-3112.

5. Graves, A.; Liwicki, M.; Fernández, S.; Bertolami, R.; Bunke, H.; Schmidhuber, J. (May 2009). "ANovel Connectionist System for Unconstrained Handwriting Recognition". IEEE Transactions on PatternAnalysis and Machine Intelligence. 31 (5): 855–868. doi:10.1109/tpami.2008.137. ISSN 0162-8828.

6. Sak, H.; Senior, A.; Rao, K.; Beaufays, F.; Schalkwyk, J. (September 24, 2015). "Google voice search:faster and more accurate". Research Blog. Retrieved 2018-03-04.

7. Maass, Wolfgang, et al. “Real-Time Computing Without Stable States: A New Framework forNeural Computation Based on Perturbations.” Neural Computation, vol. 14, no. 11, 2002, pp. 2531–2560.,doi:10.1162/089976602760407955.

8. Jaeger, H. The “echo state” approach to analysing and training recurrent neural networks. GermanNational Research Center for Information Technology GMD Technical Report, 2001

9. Appeltant, L., et al. “Information Processing Using a Single Dynamical Node as Complex System.”Nature Communications, vol. 2, 2011, p. 468., doi:10.1038/ncomms1476.

10. Larger, L., et al. “Photonic Information Processing beyond Turing: an Optoelectronic Implementa-tion of Reservoir Computing.” Optics Express, vol. 20, no. 3, 2012, p. 3241., doi:10.1364/oe.20.003241.

11. Torrejon, Jacob, et al. “Neuromorphic Computing with Nanoscale Spintronic Oscillators.” Nature,vol. 547, no. 7664, 2017, pp. 428–431., doi:10.1038/nature23011.

12. Lukoševičius, Mantas. “A Practical Guide to Applying Echo State Networks.” Lecture Notes inComputer Science Neural Networks: Tricks of the Trade, 2012, pp. 659–686., doi:10.1007/978-3-642-35289-8_36.

13. Enel, Pierre, et al. “Reservoir Computing Properties of Neural Dynamics in Prefrontal Cortex.”PLOS Computational Biology, vol. 12, no. 6, Oct. 2016, doi:10.1371/journal.pcbi.1004967.

14. Ruder, S., An Overview of Multi-Task Learning in Deep Neural Networks, https://arxiv.org/pdf/1706.05098.pdf15. https://en.wikipedia.org/wiki/Kernel_method16. Schumacher, Johannes, et al. “An Introduction to Delay-Coupled Reservoir Computing.” Springer

Series in Bio-/Neuroinformatics Artificial Neural Networks, 2015, pp. 63–90., doi:10.1007/978-3-319-09903-3_4.

17. Martinenghi, R., et al. “Optoelectronic Nonlinear Transient Computing with Multiple Delays.” 2013Conference on Lasers & Electro-Optics Europe & International Quantum Electronics Conference CLEOEUROPE/IQEC, 2013, doi:10.1109/cleoe-iqec.2013.6800826.

18. Nieters, P., et al. “Neuromorphic Computation in Multi-Delay Coupled Models.” IBM Journal ofResearch and Development, vol. 61, no. 2/3, Jan. 2017, doi:10.1147/jrd.2017.2664698.

19. Bueno, Julián, et al. “Conditions for Reservoir Computing Performance Using Semiconductor Laserswith Delayed Optical Feedback.” Optics Express, vol. 25, no. 3, 2017, p. 2401., doi:10.1364/oe.25.002401.

20. Arecchi, F. T., et al. “Two-Dimensional Representation of a Delayed Dynamical System.” PhysicalReview A, vol. 45, no. 7, Jan. 1992, doi:10.1103/physreva.45.r4225.

76

21. Giacomelli, Giovanni, and Antonio Politi. “Relationship between Delayed and Spatially Ex-tended Dynamical Systems.” Physical Review Letters, vol. 76, no. 15, Aug. 1996, pp. 2686–2689.,doi:10.1103/physrevlett.76.2686.

22. Larger, Laurent, et al. “Laser Chimeras as a Paradigm for Multistable Patterns in Complex Systems.”Nature Communications, vol. 6, no. 1, 2015, doi:10.1038/ncomms8752.

23. Peil, Michael, et al. “Routes to Chaos and Multiple Time Scale Dynamics in Broadband BandpassNonlinear Delay Electro-Optic Oscillators.” Physical Review E, vol. 79, no. 2, Sept. 2009, doi:10.1103/physreve.79.026208.

24. Gallicchio, Claudio, et al. “Deep Reservoir Computing: A Critical Experimental Analysis.” Neuro-computing, vol. 268, 2017, pp. 87–99., doi:10.1016/j.neucom.2016.12.089.

25. Keuninckx, Lars, et al. “Real-Time Audio Processing with a Cascade of Discrete-Time De-lay Line-Based Reservoir Computers.” Cognitive Computation, vol. 9, no. 3, July 2017, pp. 315–326.,doi:10.1007/s12559-017-9457-5.

26. https://software.intel.com/en-us/cvsdk-fpga-support-introducing-fpga-support-for-cnn27. Bogdan Penkovsky. Theory and Modeling of Complex Nonlinear Delay Dynamics Applied to

Neuromorphic Computing. Artificial Intelligence [cs.AI]. Université Bourgogne Franche-Comté, 2017.English. [3008?]tel-01591441v2[3009?]

28. Soriano, Miguel C., et al. “Delay-Based Reservoir Computing: Noise Effects in a Combined Analogand Digital Implementation.” IEEE Transactions on Neural Networks and Learning Systems, vol. 26, no.2, 2015, pp. 388–393., doi:10.1109/tnnls.2014.2311855.

29. Antonik, Piotr, et al. “Brain-Inspired Photonic Signal Processor for Generating Periodic Patterns andEmulating Chaotic Systems.” Physical Review Applied, vol. 7, no. 5, 2017, doi:10.1103/physrevapplied.7.054014.

30. Li, Jialing, et al. “Analog Hardware Implementation of Spike-Based Delayed Feedback ReservoirComputing System.” 2017 International Joint Conference on Neural Networks (IJCNN), 2017, doi:10.1109/ijcnn.2017.7966288.

31. Larger, Laurent, et al. “High-Speed Photonic Reservoir Computing Using a Time-Delay-BasedArchitecture: Million Words per Second Classification.” Physical Review X, vol. 7, no. 1, June 2017,doi:10.1103/physrevx.7.011015.

32. Soriano, Miguel C. “Reservoir Computing Speeds Up.” Physics, vol. 10, June 2017, doi:10.1103/physics.10.12.33. Zhang, Hong, et al. “Integrated Photonic Reservoir Computing Based on Hierarchical Time-

Multiplexing Structure.” Optics Express, vol. 22, no. 25, Nov. 2014, p. 31356., doi:10.1364/oe.22.031356.34. Freiberger, Matthias, et al. “On-Chip Passive Photonic Reservoir Computing with Integrated Optical

Readout.” 2017 IEEE International Conference on Rebooting Computing (ICRC), 2017, doi:10.1109/icrc.2017.8123673.35. Katumba, Andrew, et al. “Low-Loss Photonic Reservoir Computing with Multimode Photonic

Integrated Circuits.” Scientific Reports, vol. 8, no. 1, Feb. 2018, doi:10.1038/s41598-018-21011-x.36. Fernando, Chrisantha, and Sampsa Sojakka. “Pattern Recognition in a Bucket.” Advances in

Artificial Life Lecture Notes in Computer Science, 2003, pp. 588–597., doi:10.1007/978-3-540-39432-7_63.37. Antonik, Piotr, et al. “Online Training of an Opto-Electronic Reservoir Computer Applied to Real-

Time Channel Equalization.” IEEE Transactions on Neural Networks and Learning Systems, vol. 28, no.11, 2017, pp. 2686–2698., doi:10.1109/tnnls.2016.2598655.

38. Romeira, B., et al. “Regenerative Memory in Time-Delayed Neuromorphic Photonic Resonators.”Scientific Reports, vol. 6, no. 1, 2016, doi:10.1038/srep19510.

39. Brunner, D., et al. “Spatio-temporal complexity in dual delay nonlinear laser dynamics: chimerasand dissipative solitons” https://arxiv.org/abs/1712.03283

40. For more information regarding FPGA design workflows please refer to respective user guides: Xilinx,41. http://discourse.myhdl.org/42. https://github.com/xesscorp/myhdl-resources

77

43. See this proposal for the fixed-point type: http://dev.myhdl.org/meps/mep-111.html44. Research platforms aimed at functional hardware description have appeared a decade ago (e.g. Lava,

ForSyDe)45. https://www.xilinx.com/products/silicon-devices/soc.html46. https://www.altera.com/products/soc/overview.html47. Kilts, Steve. Advanced FPGA Design Architecture, Implementation, and Optimization. Wiley, 2007.48. https://www.certicom.com/content/dam/certicom/images/pdfs/ams/security_for_fabless_semi_08.pdf49. https://web.archive.org/web/20070825103724/http://csrc.nist.gov/cryptval/140-2.htm50. Mcculloch, Warren S., and Walter Pitts. “A Logical Calculus of the Ideas Immanent in Nervous Ac-

tivity.” The Bulletin of Mathematical Biophysics, vol. 5, no. 4, 1943, pp. 115–133., doi:10.1007/bf02478259.51. Rosenblatt, F. “The Perceptron: A Probabilistic Model for Information Storage and Organization

in the Brain.” Psychological Review, vol. 65, no. 6, 1958, pp. 386–408., doi:10.1037/h0042519.52. Waldrop, M. Mitchell. “The Chips Are down for Moore’s Law.” Nature, vol. 530, no. 7589, Sept.

2016, pp. 144–147., doi:10.1038/530144a.53. Rabinovich, Mikhail I., et al. “Dynamical Bridge between Brain and Mind.” Trends in Cognitive

Sciences, vol. 19, no. 8, 2015, pp. 453–461., doi:10.1016/j.tics.2015.06.005.54. The Human Brain project comprises such subprojects as BrainScaleS and SpiNNaker the goal

of which simulate the human brain simulation as a spiking network, in analog (BrainScaleS) and digital(SpiNNaker) hardware, https://www.humanbrainproject.eu/en/silicon-brains/

55. Merolla, P. A., et al. “A Million Spiking-Neuron Integrated Circuit with a Scalable CommunicationNetwork and Interface.” Science, vol. 345, no. 6197, July 2014, pp. 668–673., doi:10.1126/science.1254642.

56. https://www.wired.com/story/this-computer-uses-lightnot-electricityto-train-ai-algorithms/57. Lamport et al, The Byzantine Generals Problem, ACM Transactions on Programming Languages

and Systems (TOPLAS), Volume 4 Issue 3, July 198258. Satoshi Nakamoto, A Peer-to-Peer Electronic Cash System. 2009. https://bitcoin.org/bitcoin.

pdf59. Federal Information Processing Standards Publication 180-2. Secure Hash Standard. August 2002.60. Karger, D.; Lehman, E.; Leighton, T.; Panigrahy, R.; Levine, M.; Lewin, D. (1997). Consistent

Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World WideWeb. Proceedings of the Twenty-Ninth Annual ACM Symposium on Theory of Computing. ACM PressNew York, NY, USA. pp. 654–663

61. Thaler, David; Chinya Ravishankar (February 1998). "Using Name-Based Mapping Schemes toIncrease Hit Rates". IEEE/ACM Transactions on Networking. 6 (1): 1–14

62. The Interplanetary Filesystem Whitepaper. Juan Benet. IPFS - Content Addressed, Versioned, P2PFile System (DRAFT 3). https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf

63. Git version control system. https://git-scm.com/64. Filecoin. https://filecoin.io/65. IOTA data market https://data.iota.org/66. US patent 4309569, Ralph Merkle, "Method of providing digital signatures", published Jan 5, 1982,

assigned to The Board Of Trustees Of The Leland Stanford Junior University67. Merkle Patricia Tree Specification. https://github.com/ethereum/wiki/wiki/Patricia-Tree68. Ethereum Blockchain. https://www.ethereum.org/69. A Next Generation Smart Contract and Decentralized Application Platform. Vitalik Buterin. 2013.

https://github.com/ethereum/wiki/wiki/White-Paper

78

70. On Sharding Blockchains. https://github.com/ethereum/wiki/wiki/Sharding-FAQ71. The Bitcoin Lightning Network: Scalable Off - Chain Instant Payments. Joseph Poon and Thaddeus

Dryja. 2016. https://lightning.network/lightning-network-paper.pdf72. The Raiden Network. https://raiden.network/73. Plasma: Scalable Autonomous Smart Contracts. Joseph Poon and Vitalik Buterin. 2017. https:

//plasma.io/plasma.pdf74. The Cosmos Network. https://cosmos.network/75. Tendermint Blockchain Consensus Platform. https://tendermint.com/76. IOTA Project. https://iota.org/77. Primecoin. http://primecoin.io/78. Casper the Friendly Finality Gadget. Vitalik Buterin and Virgil Griffith. 2017. https://arxiv.

org/abs/1710.0943779. Filecoin Storage Blockchain. https://filecoin.io/80. Practical Byzantine Fault Tolerance. Miguel Castro and Barbara Liskov. Proceedings of the Third

Symposium on Operating Systems Design and Implementation, New Orleans, USA, February 199981. EIP150 - https://github.com/ethereum/EIPs/blob/master/EIPS/eip-150.md82. EIP 161 - https://github.com/ethereum/EIPs/blob/master/EIPS/eip-161.md83. Cosmos Whitepaper Appendix – Preventing Long Range Attacks. https://cosmos.network/

whitepaper#appendix84. Leslie Lamport. On interprocess communication. part I: Basic formalism.85. Herlihy, M. and Wing, J. M. (1990). Linearizability: A correctness condition86. Lamport, L. (1979). How to make a multiprocessor computer that correctly87. Lamport, L. (1978). Time, clocks, and the ordering of events in a distributed88. Lipton, R.J.; J.S. Sandberg. (1988). PRAM: A scalable shared memory (Technical report). Princeton

University. CS-TR-180-88.89. Seth Gilbert and Nancy Lynch, "Brewer’s conjecture and the feasibility of consistent, available,

partition-tolerant web services", ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51–59.90. https://medium.com/@icebearhww/ethereum-sharding-and-finality-65248951f64991. M. J. Fischer, N. A. Lynch, and M. S. Paterson, “Impossibility of distributed consensus with one

faulty process,” Journal of the ACM, vol. 32, no. 2, pp. 374–382, 1985.92. https://sfbitcoindevs.wordpress.com/2015/01/21/tendermint-consensus-without-mining/93. http://tendermint.readthedocs.io/projects/tools/en/master/introduction.html#what-is-tendermint94. https://lightrains.com/blogs/intro-tendermint95. https://github.com/tendermint/iavl96. Cosmos Whitepaper. https://cosmos.network/whitepaper97. https://blog.z.cash/htlc-bip/98. https://github.com/tendermint/basecoin/blob/master/docs/guide/ibc.md99. https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md100. https://github.com/tendermint/tendermint/wiki/Introduction101. https://research.fb.com/category/facebook-ai-research-fair/102. https://github.com/mccorby/PhotoLabeller103. https://blog.otiumcapital.com/otium-neural-newsletter-1-federated-learning-a-step-closer-towards-

confidential-ai-efe28832006f104. https://research.googleblog.com/2017/04/federated-learning-collaborative.html105. Ian Goodfellow and Yoshua Bengio and Aaron Courville, “Deep Learning”, MIT Press (2016).

79

106. Pan, S. J., & Yang, Q.. “A survey on transfer learning”, IEEE Transactions on Knowledge andData Engineering, 22(10), 1345–1359, (2010)

107. Lisa Torrey and Jude Shavlik, “Transfer Learning”, University of Wisconsin, Madison WI.108. Andrei A. Rusu, Matej Vecerik, Thomas Rothörl, Nicolas Heess, Razvan Pascanu, Raia Hadsell,

“Sim-to-Real Robot Learning from Pixels with Progressive Nets”, arXiv Preprint arXiv:1610.04286 - https://arxiv.org/pdf/1610.04286.pdf

109. Volodymyr Mnih, Adrià Puigdomènech Badia, Mehdi Mirza, Alex Graves, Timothy P. Lillicrap,Tim Harley, David Silver, and Koray Kavukcuoglu. “Asynchronous methods for deep reinforcement learning”.In International Conference on Machine Learning (ICML), 2016.

110. Hochreiter and Jürgen Schmidhuber. “Long Short-Term Memory”. Neural Computation, Volume9, Issue 8, November 15, 1997 (p.1735-1780)

111. Sinno Jialin Pan and Qiang Yang. “A Survey on Transfer Learning”, IEEE Transactions onKnowledge and Data Engineering, 22(10), 1345–1359.

112. Weiss, Karl, Taghi M. Khoshgoftaar, and DingDing Wang. “A survey of transfer learning. Journalof Big Data 3.1 (2016).

113. Barrett, Samuel, Matthew E. Taylor, and Peter Stone. "Transfer learning for reinforcementlearning on a physical robot." International Conference on Autonomous Agents and Multiagent Systems-Adaptive Learning Agents Workshop (AAMAS-ALA), 20

80