ℵim Aleph, a decentralized application network Moshe Malawach (moshe@aleph.im) November 21, 2019 Abstract Aleph is a cross-blockchain layer-2 network specifically focused on decentralized applications and their related infrastructure (storage, computing servers, security). Our aim is to decentralize and revolutionize the web and the cloud as we know it. Current decentralized applications are generally unreliable and slow or tied to single blockchain architecture. Decentralized applications need to not only overcome these issues, but they also need to be able to communicate with other projects. The large majority of current blockchain-related technologies cannot scale to the levels needed for large applications (social networks, web apps, IoT providers, etc) we use on a daily basis. Aleph intends to provide a solution to these issues by offering fast single cross-technologies and cross-chain solution on a decentralized and reliable ecosystem. 1 Contents 1 Introduction 4 2 Existing solutions 5 2.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 DHT storages like IPFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Aleph Architecture 7 3.1 Blockchains used by Aleph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Data type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Data exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6 Virtual machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6.1 Hash links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6.2 VM State content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6.3 Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.7 Cross-application data exchange and data ownership . . . . . . . . . . . . . . . . . . . . . . . 10 3.8 Moderation and requests for removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.8.1 Network and data moderation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.8.2 Removal request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9.1 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9.2 Packing nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9.3 Storage nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9.4 Full Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4 Aleph Token 13 4.1 Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2 Token use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3 Token details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4 Initial token distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.1 NULS staking program (POCM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5 Supply evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5 Roadmap 17 5.1 Genesis (NULS Only), Q1 2019 (done) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2 Cross-chain, Q2 2019 (done) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 Contents 3 5.3 Placeholder token issuance, Q3 2019 (done) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4 Aleph storage dApps SDK, Q4 2019 (testing+docs in progress) . . . . . . . . . . . . . . . . . . 17 5.5 IoT SDK, Q4 2019 (testing+docs in progress) . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.6 Virtual machines and Main Net, Q1 2020 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.7 Aleph VM dApps SDK, Q2 2020 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.8 Network nodes and economy, Q2 2020 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.9 Specialized/Hybrid nodes, Q3 2020 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.10 Underlying chains acceleration and SDK, Q4 2020 . . . . . . . . . . . . . . . . . . . . . . . . 18 5.11 Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6 Notes and appendices 19 6.1 Hardware wallet and 2 factor support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction The Internet was originally built to connect computers together. It has been used as a marvelous communication and data storage model. Protocols originally designed for decentralization (TCP, HTTP, SMTP… and even blockchains) are already showing their limitations. In a purely economically driven world; simplicity, centralization, and non-standard data models tend to win out. What is our internet today? Silos loosely connected together, users having data in each of those silos (Facebook, Google, and many others), with no simple way to port it over. (see Drake 2015) There are a lot of attempts at breaking those silos, from connection from silo to silo (iftt, rgpd for data request, opendata programs…), to decentralized networks of silos (mastodon). We are living in a world of data silos. In itself, that isn’t bad if those silos were easily accessible and decentralized. Users don’t know it, but they need to reclaim their data. User Website Database Centralized storage Figure 1.1: Typical centralized application 4 2. Existing solutions 2.1 Blockchain DLT1 allows us to have a single data silo (albeit specialized) that is spread across all users of the network. SmartContracts make use of that ability to allow decentralized computing (among other benefits). Common naming of dApps2 is using smart contracts on blockchain platforms like Ethereum. A few issues arise from its model: • Paid transactions by the user (meaning a dApp user should buy some underlying network asset to use the Dapp) • Reliance on inclusion in a block (dependant on the block time of the relevant blockchain, making dApps slow) • On-chain storage is very expensive, making it unsuitable for media content or large documents. There are a lot of existing blockchain platforms currently active (see “Coinmarketcap” n.d.). 1Distributed Ledger Technology, mostly BlockChain 2Decentralized applications 5 2.2. DHT storages like IPFS 6 2.2 DHT storages like IPFS Storage networks like IPFS or Swarm are great to find a resource based on its hash in the network. Some things are currently needed or not easily useable for our dApps: • Incentivization of storage (to be implemented in their FileCoin for IPFS, implemented on Ethereum for Swarm) • Unique resource naming system (provided in a slow way currently by IPNS, fix being worked on, or through Ethereum smart contracts in Swarm) User Frontend API Server SmartContract BlockChain IPFS (dApp data pinned by dApp owner) Figure 2.1: Typical smart-contract based dApp using IPFS 3. Aleph Architecture In current solutions involving smart contracts, the current state of applications is written (or computed from) on a blockchain, this is immutability. But what if you want instantaneous actions, batching user requests for non critical items? You’ll need a second layer of truth, a distributed state that you can influence by signing messages. Agents will then commit the messages on the blockchain for the users, incentivized by the network token. They will spend the native chain asset and will receive the token in exchange for their service, provided by the next authorized agent. Then that agents work will be verified by the previous agent, changing it’s credit score on the fly. This allows for free and instant interaction with dapps for users, with efficient batched inserts on the blockchain for immutability. Moreover, this more easily facilitates agents running API servers that can be used by the dapps as entry points to the network. Below are a few focal actions of the Aleph network: • Instant (low-latency) global status update • Bulk content write on blockchain to allow fee-less commits • Pinning IPFS data (data replication) • API server decentralization • Virtual machines code execution and verification User Frontend API Servers DHT-Based P2P Network Aleph Network Smart VMs Distributed & Incentivized Storage IPFS BlockChain 7 3.1. Blockchains used by Aleph 8 3.1 Blockchains used by Aleph The first underlying blockchain supported by Aleph is NULS. To allow easier port of existing dapps and ecosystems, later in the developement process, other blockchains can be supported such as Ethereum, NEO and even the Bitcoin blockchain. The address in the Aleph network is the underlying network of choice (NULS, Ethereum, NEO…) address used to sign messages. A user can post in his personal aggregate (key-value hash table linked to his primary address) his addresses on other networks. That way he can redeem or receive tokens from other blockchains. If a user has a NULS account and an Ethereum account both linked together, a request for his aggregates (profile or settings for example), posts (images, blog posts…), or any other linked content will return the same information from any of the two addresses. 3.2 Data storage The hashes of the data are stored on chain. The data itself is stored encrypted or not on IPFS. Data is pinned by participating nodes. Posting is done either via API by the dapps to an API node, or by IPFS directly if available on the browser. The current state is stored on both blockchain (nodes are made of a blockchain explorer) and current received data that is not posted yet (queue, mempool). Once the data signature is verified, and it is broadcasted to at least 2 nodes, it is considered validated and included in the coming blocks. Update User Publishes new content with no fee Aleph Network Adds to a block, pays fee State Ensures content storage NULS Ethereum Figure 3.1: Data posting procedure 3.3 Data type Table 3.1: Data types Data Type Description Details Aggregates Key-value store linked to an account1 Each key can be updated separately and its content is merged with previous. Example: user profile 1Underlying blockchain of choice address and linked public key. 3.4. Data exchange 9 Data Type Description Details Posts Single data entry Has a type field, an optional ref (reference) field that references another post or application-specific string. Can be amended with new posts with type “amend” and ref to the previous post. Data inside post content can be optionally encrypted with either owner key or a recipient key. Example: blog post, comment, picture gallery, video entry, new data point, new event… VM State State of a virtual machine Fields depending on underlying engine (dockerized language-specific contracts or WASM for example) 3.4 Data exchange The exchange of data between the dapps and the nodes is done either by pubsub (if available) or API posting. The node will do the pubsub action on behalf of the user. Using pubsub, all nodes will get the user posts and actions. Pubsub is using dht and ensuring all subscribed nodes will receive all users posts to get the current state. Yes No New content on client New IPFS Hash IPFS Hash signed Client supports direct p2p Posts via pubsub Posts via API API Server posts via pubsub Signature verification Nodes add post to queue Figure 3.2: Data posting procedure 3.5 State State encompasses both onchain committed data and uncommitted data received by pubsub. State can be recomputed by getting all TX from a user or containing messages signed by him, and adding the uncommitted messages. • For smart contracts/VMs, it should be recomputed from last committed, signed and non revoked (no litigation) onchain state. • For aggregates (user hash tables) from the last onchain commit for each key. • For posts, from the original post plus all the amends. If last amend contains all the fields, original plus last amend is acceptable. 1st 2nd Objects stored on chain State stack Objects in the queue Compute state with amends and layers Current state Figure 3.3: State composition 3.6. Virtual machines 10 3.6 Virtual machines Sometimes called smart contracts, the virtual machines have a state that is commited as an object in the chain. All nodes don’t need to keep all the VM’s states, only the last one if no litigation occurred. 3.6.1 Hash links Each mutation to a VM state contains a relation to a previous state (previous hash). If two data blocks relate to the same hash, the first to be commited on-chain will prevail (in case of data sync), and the first to be received (in case of off-chain processing before block inclusion). In the event a new block is posted with a different history than what is computed off-chain, two possibilities occurr: • On-chain content is deemed bad (according to specific rules) and discarded in a new commited transaction, off chain content taking its place • Off-chain content is discarded and clients are notified 3.6.2 VM State content The VM state object is specific to the engine used (WASM, docker-like language specific VM, JVM…), but typically contains: • Relation to the previous state (object chain using hashes) • Function called • Arguments • Function result • New serialized state (can be a diff only for big states, in special cases) 3.6.3 Concurrency While view-only functions that don’t modify the state can be done concurrently, the write functions can’t happen concurrently (or will end up in a fork). A node can send a pubsub message to broadcast it is working on/executing a “write” function on a specific VM. Once that has been completed, it will broadcast the new state to the other nodes in the same pubsub channel, thus enabling them to execute a write function from this point in history. 3.7 Cross-application data exchange and data ownership All applications in the Aleph ecosystem are talking to the same data storage entity. Conventions exist and have to be documented on data structures to be used by applications. This enables applications to use the same user profiles (example nuls.space and nuls.world/social using the same profiles, and nuls.world/apps/vote using the profile and same post format than the formers for its content) and content sources if needed. A new developer can come and make a new frontend to all the existing data posted by users. Users own their data. 3.8 Moderation and requests for removal 3.8.1 Network and data moderation Each application can have its own storage of black-listed content and addresses to handle its own moderation features (the application will then omit certain content or content creators from the user interface). 3.9. Nodes 11 For illegal content, the network will also have its own storage that will be synchronised between nodes of blacklisted content and addresses. Linked content hashes will be automatically unpinned from all nodes, leading to its destruction from the Aleph network. 3.8.2 Removal request To comply with regulations (GPDR in particular), in a similar fashion to the illegal content data unpinning, a user can request certain hashes he posted to be removed, or even his full address data to be put into blacklist by signing a message using his public key. 3.9 Nodes 3.9.1 Clients Simple clients to the network are either using the API to API node or p2p pubsub connection to the network. If they are using the p2p system then they can act like a full node and validate messages themselves (and run VM themselves if it’s available for their platform, WASM working in web browsers). They should be careful to verify the signatures of the received messages and states if they don’t trust the API server or if they are connected directly to the network. 3.9.2 Packing nodes The Packing nodes are those which validate the messages and submit their hashes to the underlying blockchains. They get rewarded for their action (token reward) or punished if they don’t do their duty correctly. If a packing node is found committing nefarious acts by the consensus, its address is blacklisted and his rewards (and/or deposit, this is to be defined, see Roadmap chapter) frozen. Those nodes must be both API nodes and storage nodes too. 3.9.3 Storage nodes The storage nodes pin incoming IPFS hashes to ensure distributed (geographically and accross multiple hosts to ensure the data won’t go away) storage of the content. Those nodes must be API nodes and may optionally be packing nodes too. They are rewarded in tokens for their duty. 3.9.4 Full Node Packing and storage nodes are using this codebase, activating some modules and configuration to do their work. The APIs are a module that can be activated (mandatory one for incentivized nodes). Features of an Aleph Node: • Indexes the underlying blockchain it is configured for (can be more than 1). • Has an IPFS client built-in • Keeps track of modifications to the chain (forks, history rewrite…) • Connected to pubsub channels to update its off chain state 3.9. Nodes 12 • Retrieves IPFS content (from storage nodes or sender) commited onchain or recieved in pubsub to review and index content (and pins it if needed) • Executes VMs code (if configured for it, and only relevant ones) 3.9.4.1 Indexing Depending on the underlying chain volume, a full index will be done, or only an index based on specific events (triggered by a smart contract for example -on Ethereum-, a tx type -business data on NULS- or op_return & similar). For maximum security, the incentivized Aleph nodes in charge of sensitive parts of the network will connect to a local node of this blockchain (to detect forks for example), simpler nodes can connect to explorers or public api servers of those chains to act as light wallets. The blocks informations will also be published on IPFS for faster sync of nodes. 4. Aleph Token 4.1 Rewards Three main sources of reward and token creation are: • Reward each signed message written to the underlying blockchain • Reward storage of application data (pin items) and availability of API, both are mandatory for nodes • POCM NULS token locking in NULS underlying chain (see token distribution section) Of those rewards, a part will come from monetary creation, and a part from dApp owner incentive to prioritize their apps and their user fees. If a dApp owner wants to get the benefit of the network without having to rely on third parties only, he can run a node of the network where he prioritizes his dApp data (but he can’t completely ignore others, having a backup for his users on other nodes, while he gives the same allowance to other dApps). 4.2 Token use Most node owners will accept free storage of dApp data, especially at start of the network. Once the data grows bigger, and it begins to become impratical for hosts to have all the data, dApp owners can pay for storage and writes to the blockchain of his dApp data. Alternatively, application users can pay themselves for the storage of their data (example, big data volume like picture storage applications). 4.3 Token details Initially, the first issuance of the Aleph utility token will be made as an NRC-20 token. This will be able to be swapped for the native asset at a later date. If technically possible (part under research): • the switch between NRC-20 and native Aleph token will be available in both directions. • the token will also be made available as an ERC-20 token 13 4.4. Initial token distribution 14 4.4 Initial token distribution The exact details of the initial token distribution plan will be announced at a later date. Below is what is currently planned for the token distribution (can be subject to changes). To reward the NULS community and ecosystem, a large percentage of the supply will be distributed to NULS token holders through the POCM system. 1,000,000,000 (1 billion) tokens will be issued initially. Of those : • 150M will be devoted to airdrop, marketing and bounties (details of airdrop part will be announced through official channels) • 150M will be reserved for the NULS community/foundation (100M locked for the POCM mining program and 50M for other incentives) • 350M for private / institutionnal investors / OTC sales • 350M to the Aleph team (who will use this for bootstrap period rewards, might be able to sell some for development funding, allocate a part for a community or foundation fund or any other use it might deem necessary) Airdrop, Marketing & Bounties 150M NULS (POCM&Others) 150M Contributors 350M Reserved 350M Figure 4.1: Token Distribution 4.5. Supply evolution 15 4.4.1 NULS staking program (POCM) In addition to a regular airdrop, NULS holders can lock a part of their NULS tokens to get Aleph tokens. While their tokens are locked, they will receive Aleph tokens based on the NULS amount they have “staked”/“locked”. The reward will be higher at the start of the POCM period (approximately 10 years) and lower at the end. Those tokens will come from an initial pool of 200M tokens, locked for that specific purpose. Once that pool dries up at the end of the period, the reward will be lowered and the tokens minted using this program will be taken from the Supply Evolution. 4.5 Supply evolution Once the full network is ready (see roadmap chapter) and through the described rewards, the token supply will grow by approximately 10% the first year. Then the inflation rate will decrease by 1% each year until it reaches 1% per year and stay at that value. Table 4.1: Supply per year 1st year 2nd year 3rd year 4th year 5th year 6th year inflation 4% 3% 2% 1% 1% 1% tokens minted 40M 31.2M 21.42M 10.92M 11.03M 11.14M total supply eoy 1040M 1071M 1092M 1103M 1114M 1125M 4.5. Supply evolution 16 0 1 2 3 4 5 Year 0 250 500 750 1000 1250 1500 1750 2000 Supply (Million tokens) 0 2 4 6 8 10 12 14 Inflation (%) Supply Newly minted Inflation rate Figure 4.2: Supply evolution 5. Roadmap 5.1 Genesis (NULS Only), Q1 2019 (done) The only address format and public keys supported on the network will be NULS addresses. At the start of this period, a proof of concept will be ready and applications can be developed on Aleph, supporting all but cross-chain and virtual machines. 5.2 Cross-chain, Q2 2019 (done) The cross-chain infrastructure will be developed at this milestone, allowing other types of addresses to be used on the Aleph network (Ethereum first). 5.3 Placeholder token issuance, Q3 2019 (done) A placeholder token is issued as an nrc-20 token (and possibly erc-20), the POCM system starts. In the first step of the project, the token will live on the NULS blockchain as an NRC-20 token. Rewards to the nodes of the network will be given from the Aleph reserve funds. 5.4 Aleph storage dApps SDK, Q4 2019 (testing+docs in progress) Aleph dApps based on Aleph storage (posts and aggregates) will have an SDK available for JavaScript client-side code. With login using underlying chain addresses (web3, ledger wallet…). 5.5 IoT SDK, Q4 2019 (testing+docs in progress) A SDK will be made available for IoT embedded devices, using MicroPython and/or Arduino-compatible code. 5.6 Virtual machines and Main Net, Q1 2020 The “Smart Apps” virtual machine will be developed for this milestone. The 1st version Aleph.im main net will be started. 17 5.7. Aleph VM dApps SDK, Q2 2020 18 5.7 Aleph VM dApps SDK, Q2 2020 Full Aleph dApps based on Aleph virtual machines will have an SDK available, both for the virtual machine code, and JavaScript client-side code. With login using underlying chain addresses (web3, ledger wallet…). 5.8 Network nodes and economy, Q2 2020 The Aleph.im native token will be minted. A token swap will take place from the NRC-20 (and ERC-20 if issued) token to the native token. If technically possible, other chains tokens (aleph token as nrc-20, erc-20 or nep-5 for example) will be able to be swapped from and to the Aleph native token. The network nodes will now receive their token rewards corresponding to the plan described in the Token chapter. 5.9 Specialized/Hybrid nodes, Q3 2020 The priorization feature will now be developed and all nodes won’t store all the data or run all the VMs. Some nodes can focus on a few dApps for their owners while still being able to help the whole network (and their dApp content can still be accessible to others). 5.10 Underlying chains acceleration and SDK, Q4 2020 A SDK will be made available at this milestone to easily migrate underlying chain dApps and accelerate them (Ethereum first). 5.11 Future There are a lot of possibilities for the future (not defined yet): • Decentralized exchanges and encapsulation of other assets • Use of Aleph as a monetary 2nd layer (like lightning or plasma) • … 6. Notes and appendices 6.1 Hardware wallet and 2 factor support Since the signing is done using the underlying chains mechanisms, their support for hardware wallets is used. Wherever possible, those supports will be used. Examples: • NULS has hardware wallet support done on ledger, we use the built-in signing mechanism to sign the messages. • Ethereum supports Ledger and Trezor, we use their support and signing mechanism. Another way to go is using the webauthn standard, that will use whatever hardware support is available (built-in crypto chip in mobile device as 2 factor auth, usb u2f key), specific to used website. Wherever possible, webauthn support will be added (generating NULS addresses using secp256k1 support). An exception to the underlying protocol signing mechanism can be done to support json object signing specific to webauthn. 19 6.1. Hardware wallet and 2 factor support 20 References “Coinmarketcap.” n.d. Accessed February 27, 2019. https://coinmarketcap.com/all/views/all/. Drake, Kyle. 2015. “HTTP Is Obsolete. It’s Time for the Distributed, Permanent Web.” September 8, 2015. https: //ipfs.io/ipfs/QmNhFJjGcMPqpuYfxL62VVB9528NXqDNMFXiqN5bgFYiZ1/its-time-for-the-permanent-web. html.