Joystream: A Protocol for User Governed Content Platforms Jsgenesis June 8, 2020 DRAFT Version 0.1 Abstract T The Joystream protocol attempts to formalize a content platform that is governed and operated by the platform users. The centerpiece of the protocol is the shared platform state, implemented on top of a blockchain consensus system, which coordinates and provides incentives to all stakeholders. Almost DR AF every aspect of a content platform is endogenous to the protocol, including (a) governance (b) membership system, with screening and policing (c) storage and distribution (d) curated content directory (e) content search, browsing, and recommendations (f) software development finance and coordination (g) content production financing (h) advertising auctions and placement (i) communication: messaging and message boards and every subsystem is fully accountable to, and directed by, the users, as represented by the governance system. Capturing such a broad range of systems in the protocol is the distinguishing characteristic of this proposal. It is motivated by the thesis that a high level of platform accountability can be achieved by empowering two user capabilities. First, the ability to voice discontent and subsequently implement changes based on such voices, which relies on an immutable history of actions, reliable information sharing, and binding execution of policy changes. Second, the ability to exit the platform at a low cost and create an alternative when the platform decay has gone too far. This relies on having the entire platform state available for wholesale replication, which is not possible if critical parts of the platform state are exogenous to the protocol. Contents 1 Preface 4 1 2 Introduction 4 2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Joystream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Notes 5 4 Blockchain 5 4.1 Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Asynchronous Transaction Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4 Fee Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4.1 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4.2 BRAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5 T 5 Accounts and Tokens 6 Member 10 11 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Member, Profile and Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3 Paid Membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4 Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 DR AF 6.1 11 7 Roles, Staking and Slashing 14 8 Rewards 14 9 Governance 9.1 9.2 9.3 14 Council . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1.1 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1.2 Elections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1.3 Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2.2 Life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Working Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.3.1 Leads and workers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.3.2 Installing, replacing, and evicting leads 18 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Membership Screening and Curation 18 10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.2 Working groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.3 Screening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.4 Suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2 10.5 Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Data storage and distribution 20 20 11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.2 Working Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.3 Storage providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.4 Distributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.5 Data directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.6 Uploading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.7 Downloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.8 Entry, exit, and distribution policy updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.9 Policing and data removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.10Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12 Content directory 27 27 12.2 Working group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12.3 Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.4 Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.5 Disputes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.6 Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 13 Discovery DR AF T 12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 13.2 Working group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 13.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 13.4 Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14 Software development 30 14.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.1.1 Financing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.1.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.1.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14.2 Working group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14.3 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14.4 Artifacts, reproducible, and releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 14.5 Automated testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 14.6 Deployment and upgradeability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15 Content finance 33 15.1 Working group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.2 Project life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3 16 Advertising 34 16.1 Working group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 16.2 Surfaces and targeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 16.3 Campaigns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.4 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.5 Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 17 Miscellaneous 36 17.1 Resolving hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Discussion 1 36 36 Preface T This document aims to give a high level overview of the design approach for of a new protocol for content platforms. This is an evolving document meant as a basis for an iterative review, technical specification and testing, and revised versions will be developed on the basis of that process. Multiple aspects of the DR AF protocol are still subject to active research, and any part of the current design may be amended or entirely abandoned as a result of subsequent considerations. Lastly, the descriptive resolution varies substantially across the proposal as a result of different parts at radically different levels of maturity. 2 Introduction 2.1 Motivation Due to a mixture of conspiring factors, such as platform externalities, economies of scale and, jurisdictional arbitrage, dominant contemporary Internet platforms have become some of the least accountable organizations today. The traditionally constraining institutions of market competition, regulation and litigation simultaneously appear to be unable to push back against their market power. The social cost of this equilibrium is multifaceted, leading to lower innovation, platform rents, and more broadly to the fact that platform policy is only incidentally, not primarily, guided by the objectives of the largest platform stakeholder: users. Users should be broadly understood as anyone who is participating on a platform in any capacity. 2.2 Joystream The Joystream protocol is an attempt at formalizing the structure and function of a content platform, where user accountability is a key objective and organizing principle. This accountability is generated by technically codifying two well-known complementary responses to organizational decline [1]. - Voice Users have effective means of sharing information, coordinating, and reaching decisions about key collective action problems, namely how to allocate and regulate the use of any shared platform asset. 4 - Exit Users have effective means of creating new platform instances that can preserve the entire platform history and state. This ability to fully replicate the technical, administrative, and economic state of a platform has two positive effects on accountability: first, it empowers the voice of users through the threat of a low cost exist; and second, it supports the emergence of a diversity of platforms when the underlying interests of stakeholders are irreconcilably incompatible or where the organizational decline as gone sufficiently far. In order to build in the capacity for such responses, the Joystream protocol is built as follows. The shared platform state lives on an open blockchain consensus system. As a result, it has a public state and history that is fully auditable and immutable. The protocol also has secure direct and broadcast communication capabilities integrated within a platform identity system. This means that it is very cheap for any participant to securely inspect the system and make irrefutable positive claims as part of subsequent public deliberation, learning, debating, or agitating. The identity system along with an immutable history of public actions and T communications generates the incentive to invest in community standing and act with a long time horizon. Further, there is a governance mechanism that allows low cost coordination around the use and regulation of shared assets and the amendment of the protocol. Importantly this mechanism self executes and thus DR AF provides reliable and a counterparty-free implementation of governance decisions. All these properties work in hand to support voice as response. The protocol itself is open and implemented in open source reference software. It has an open shared state and data accessible for all. This makes the copying step of creating an alternative instantiation trivial and thus supports exit as response. 3 Notes Occasionally, there may be reference to data types in various schemes or concept definitions, assume the C++ type system. When identifier fields are used in definitions, assume that they are unique and created by auto-incrementation in the context of some set of existing instances. Constant values are displayed with a capitalized snake case as follows: . These are values that FOO BAR cannot be changed through governance and require a hard fork or consensus upgrade. In some occasions, the symbol 4 C is used to denote some constant that is specific to the context. Blockchain The Joystream protocol is stateful, and the infrastructure for the secure distribution and updating of this state is a blockchain system. A given instantiation of the Joystream protocol runs on its own single-purpose blockchain infrastructure, which only processes transactions related to this instantiation. In the rest of the document, this blockchain will be treated as a silent transaction ordering mechanism; however, in the following section, it will briefly describe the assumptions on the blockchain infrastructure in the protocol design. Here, and in the rest of the document, the platform or platform state will refer to the state upon which transactions operate. In Bitcoin, for example, this would be the UTXO set and be distinctive from 5 the state of the underlying blockchain infrastructure itself, namely the actual chain of blocks designated by the chain selection rule. 4.1 Consensus The blockchain has a consensus algorithm in the classical BFT algorithm family that is adapted to use Proof-of-Stake-based voting power for a dynamic validator1 set. A designated platform token, described further in section 5, is used by the validators to stake and is also the unit in which they are rewarded. There is a growing set of such consensus protocols [2, 3, 4], and the following general properties of these systems are of importance to the protocol design. - High throughput and low latency: In benchmarks, these algorithms have been shown to support combinations of confirmation latency, transaction throughput, validator count, and geographic distribution, which are substantially more attractive than that found in typical production Nakamoto T consensus chains [5]. - Light client friendly: The overwhelming majority of end users will need to securely access the platform in computing environments with resource constraints, such as browsers and mobile devices. DR AF They should also be able to quickly start interacting with the platform, even if the last sign-on was a long time ago or may even be the first time. In addition, the Joystream protocol will have a large state and transaction history. These constraints make a light client protocol the only genuine interaction model for almost all users. In these algorithms, a light client only needs to track any potential changes in the validator set, which in practice changes quite infrequently, for example, due to the unbonding period induced delay and not in large increments. Once an up-to-date validator set is identified, the client can securely read any part of the platform state by authenticating merkle proofs from full nodes against state commitments found in the relevant block header. This is in contrast to Nakamoto consenus systems where all block headers starting at genesis2 must initially be downloaded, and one must keep up with new blocks as the system moves forward3 . Headers are validated, and the chain selection rule is applied on a continuous basis. Even if feasible, this requires a long initial synchronization period whenever a client comes on line for the first time or at some point after a hiatus. - Finality: The finality of block commitment is the property that once two-thirds of the current validator set has signed off on a block, then that block will become, and remain, part of the chain permanently. This is in contrast to Nakamoto consenus systems where the heaviest chain selection rule can in principle fork off any block, albeit with exponentially declining probability in the block depth, from the chain. This property has a number of critical benefits – Easy interoperability 1 We will refer to a block producing actor as a validator, and anyone simply fully validating the chain a full validator. reference, Ethereum has a chain of more than 7.1M blocks as of Jan. 22 2019. 3 For reference, Ethereum commits 5760 new blocks per day as of Jan. 22 2019. 2 For 6 In order for secure assertions about the state of the Joystream chain to be feasible on a different chain, this chain will effectively need to behave as a light client that can track the most up-to-date committed block on the Joystream chain. Finality ensures that tracking this becomes very easy, as there are no reorganization events that can occur. Such events open up the possibility of reverting the basis critical state changes executed on the remote chain prior to the reorganization, e.g. changes in asset ownership. Dealing with this is complex and will often involve introducing delays. Moreover, the light client friendliness discussed above also helps in reducing the information to be submitted to the remote chain light client. – Safe launch and coexistence Finality ensures that the incentive to attack a chain to perform a double spend through a reorganization goes away. This risk is particularly high in the early stage of the lifetime of a new blockchain, as the initial amount of work (or stake) on the system may be particularly low. Even beyond the launch, the amount of value securing the system will always fluctuate, in particular T for nascent systems; thus, finality provides a valuable guarantee. – Better usability Finality makes it very easy to write applications that interact with the blockchain, as complex DR AF logic for gracefully dealing with reorganizations is entirely omitted. There is no need to introduce arbitrary security delay, which is also a benefit to end users. 4.2 Upgrading It is possible to upgrade both the transaction validation rules and the current state of the chain through the transaction processing system itself. This can typically be enabled by storing the transaction validation rules in the state and then running them on top of some virtualization layer. This property is a requirement for the following: - Genuine accountability: Without a formalized mechanism for both measuring the preferences of stakeholders on collective action decisions and exercising those decisions, there will be an inevitable development of off-chain social conventions and authorities who will operate as stuarts and coordinators in such scenarios. Such actors are not accountable to platform stakeholders in any well defined or transparent way, which is undesirable in itself. - Faster iteration: For the protocol rules to quickly evolve, the process to coordinate around such changes must economize on critical ecosystem resources, such as attention, information processing, and legitimacy. Opaque off-chain upgrading processes risk becoming a perpetual source of conflict around questions of legitimacy. Moreover, the requirement for active upgrading of validator software and the non-committing signaling games that often surround such events are an additional practical friction. Instead, endogenous upgrading with an accompanying on-chain immutable record of deliberation and a history of such updates can offer an effective remedy against these difficulties. - Developer fungibility: In general, a complex system where any failure is catastrophic will require constraining the number of developers who can securely contribute to the improvement of the system. 7 This constraint can in extreme cases support a market power in the hands of key developers, where they can end up becoming gate keepers for any change to be applied. In the context of upgrading blockchain systems, the reliance on off-chain upgrades to the consensus rules, the state transition function must incorporate the full history of rule sets from genesis to the most recent changes to validate all blocks. In practice, this ends up with a monotonically increasing complexity confronting developers wanting to comprehend and modify the system, which is problematic, as explained. 4.3 Asynchronous Transaction Processing Certain types of transactions that may take a long time to process are occasionally required. Specifically, they may even require more time to process more than what is feasible when consuming all the the block times across multiple blocks. In some cases, it may be possible to accommodate such processing by the following approach, referred to as Asynchronous Transaction Processing (ATP). When the transaction is T processed, and is valid, an appropriate subset of the blockchain state is locked in the sense that all other transaction types that mutate it are considered invalid. In order to implement this in an orderly fashion, where it is practical to reason about what transactions are impacted by a given subset, one should confine DR AF the approach to suitable transaction types. Now, during this locking period, which typically will last for a predefined number of blocks, the validator nodes are free to conduct the desired processing for the initial transaction outside the normal sequential validation of blocks, for example, on a separate processing unit. The locking prevents any race condition. Finally, when the time has expired, the finalized processing result is committed to the blockchain state at the end of the corresponding block, and the substate locking is no longer in effect. 4.4 Fee Model A standalone chain allows the freedom to implement a custom fee policy. Building on top of an existing chain would result in inheriting its existing fee model for on-chain capacity, which often is tied to generalized congestion control and financing security. 4.4.1 Models There are two types of fee model modes available in the protocol. - Transactional: The normal transactional pay-per-use model can be found in a majority of currencyfocused systems such as Bitcoin. This mode applies to basic operations such as moving fund. - Block Range Action Quota (BRAQ): An action refers to a combination of an actor, role, and transaction type. This model prevents a given action from occurring more than a given number of times over a given number of blocks. Successfully issuing such transactions within the given limits does not involve marginal outlay for the given actor. Given that BRAQ will cover the majority of transactions, security will primarily be financed through minting tokens, which also more closely matches the public goods nature of chain security. This dual model has a number of critical benefits for platform. 8 First, it drastically reduces the transactions costs of onboarding new users who initially have no tokens and either face prohibitive costs in acquiring, storing, and using them or need to be persuaded about the value of the platform before being willing to incur such costs. Such users will instead face the option of being onboarded via a screening mechanism (see section 10). After this, they will be able to immediately interact with the system, within constraints. Users may later earn or purchase tokens to escape quota limitations. Alternatively, the platform itself may simply eventually abandon the free policy once these costs have declined sufficiently as a result of general increase in maturity of the blockchain ecosystem. Second, this approach explicitly subjects the fee model to a dynamic governance process where all default limits and individual member quotas can be adjusted. This is an easy and possibly the only feasible long term mechanism for correcting the externalities associated with the long-term social cost of transaction processing and state utilization in public chains [6]. 4.4.2 BRAQ In the BRAQ model, two parameters are required for each action: the range length, denoted by R, and the T action quota, denoted by Q; both are positive integers. A combined range length and transaction limit is known as a BRAQ quota. This model prevents an action in a given block if there are already L such actions in the current R blocks prior. The system must maintain a sequence of positive integers H = (h1 , . . . , hN ), DR AF known as the event list, for each action, initially set to an empty list. A combination of BRAQ quota and such a list is referred to as BRAQ instance. An action should not be allowed in block height h when L ≤ |{hi | hi ≥ h − R for some i = 1, . . . , N }| otherwise it will proceed to normal validation. If the corresponding transaction is subsequently found to be accepted, then the new value for H should be (h, h1 , . . . , hM ) where M = N if N < L, otherwise M = N − 1. Hence, H is a list of block heights for, up to, the last N successful actions. The benefit of the event list is that it makes it easy for a light client to track the availability of a given action at any given time, as the entire BRAQ instance is securely available in the state. A full node could in principle track and enforce an instance without having the H in the state. Lastly, when using this model, it is in some cases desirable to share the same quota across a range of instances. This is typically if you are dealing with a very large number of instances all of which have very similar actors. At the same time, it is also ideal to retain the flexibility to have explicitly custom quotas for specific actors based on policy or discretion. These two goals are accommodated by the concept of a BRAQ quota proxy. This is either a normal quota or an identifier resolving a normal quota in some context-specific pool of quotas or simply a sentinel to use some other context specific quota. 4.5 Interoperability Some of the assets that are of value to the platform will inevitably not live in the state of the same blockchain. This can, for example, be the state of a DNS mapping that lives on some other system, such as ENS [7] or Handshake [8]. It may even be desirable to move certain assets from the Joystream blockchain, such as 9 tokens, onto other blockchain systems. While proposals are being developed to support very general interblockchain transaction routinely, such as Cosmos [5] for tokens and Polkadot [9], it is not clear when or if they will be fully deployed, and to what extent the Joystream blockchain will be able to benefit, or more simply whether the Joystream governance process will converge on such an integration. A direct and simple case-by-case integration will be possible by using the same standard technique in almost all secure blockchain integration proposals. For each blockchain that needs to be integrated with Joystream, deploy a light client instance on each side, for the opposite side, where there is a requirement to write to the state on the first. This obviously requires that the given side is expressive and economical enough to support such an on-chain light client. Take the example of wanting to subject an ENS mapping, on Ethereum, to the governance processes on the Joystream blockchain. This will only require deploying a Joystream light client contract on Ethereum, which also is set as the owner to the given mapping. Block headers committed to the Joystream blockchain will then have to be submitted to this light client, at the very least when there are changes in validator sets. A designated party from the Joystream side can be incentivised to regularly conduct this. This header history in the state of the contract will allow it to T be securely convinced of the ENS-related signaling actions on the Joystream side through Merkle proofs, since these will be committed to in the corresponding headers4 . The contract can then in turn execute the 5 DR AF corresponding on-chain contract call to put this signal into effect in ENS. Accounts and Tokens The platform has a standard for account-based (fungible) token ownership. There will be a primary token, called the native token, which will be part of the initial state of the platform. This native token will, as will be described later, be used for value transfer, bonding, and governance activities. New tokens are minted continuously for a very wide range of purposes, all primarily to reward some actor for some behavior. This minting is perpetual, and how much is minted for what purpose is controlled by the platform governance process. New tokens are also burned by actors in scenarios where they need to contribute to the platform through the token; e.g. purchasing ad placements. There is no platform treasury that will otherwise absorb these tokens. As a result of these three separate exogenous dynamics - and the platform upgradeability functionality, there is no ex-ante certainty about the total supply of the token at different points in time in the future. The other tokens are related to the content finance market, described further in section 15. They are issued by publishing a token profile into a registry called the token registry. A token profile includes key information, such as a standard token symbol, issuer identifier, description, and also the ownership state itself known as the token balances. The token balances simply maps a public key to a positive integer, and a single mapping represents the quantity of tokens under the control of whoever holds the private key corresponding to the public key. The registration of a key in the balances of a token is referred to an account. Reuse of the same key pair across accounts for the same actor is an individual policy choice. Normal spending operations can be conducted from an account to any new or existing account on the same token by signing a message with a private key that matches the public key corresponding to the original account. The token registry is a mapping from a token identifier, which is a unique positive integer, to the corresponding token profile. 4 This could be in the event logging system, or individual transaction types being included in blocks. 10 The native token has identifier 0. Note that the following account model is distinct from the smart contract account model in general, where all transactions are tied to a given account, although such platforms also have an account-based token ownership model. Transactions are instead on Joystream, at least most of the time, tied to membership, which has been explained in further detail in section 6. 6 6.1 Member Overview The membership concept is meant to unify all platform-level participation for the same actor in a way that is independent of token ownership in the account system. This means that all platform level actions are with reference to a particular membership. A given member may of course occupy a range of different roles through the same membership. Membership is conceptually a base role in itself. Having an integrated T representation of the participation of a single actor is very valuable in supporting efficient communication and collaboration and supports pro-social investment in the actor’s reputation. Separating this from token holdings is valuable, as it allows for some type of participation to be possible without tokens, for example, 6.2 DR AF as a means for actors to earn their first tokens Member, Profile and Registry A member is an actor who is registered in the membership registry and is defined as follows: 11 Member - ID: Unique integer identifier. - Key: Public key. This is the key used to authenticate transactions as a member. - Handle: String used as human readable identifier (UTF-8). - Avatar: Storage identifier for avatar image (see section 11). - Description: String of capped length (UTF-8). - Added: Date and time when the membership was first established . - Entry: If membership was established through screening (see section 10), the this is set to ID of screening authority which created membership. If it was established through payment (see T section 6.3), then this is the paid term ID of the terms. Otherwise, its blank. - BRAQs Instances: Set of BRAQ instances for all base member actions (see section 4.4.2) DR AF - Suspended: Whether member is suspended. - Subscription: If at least one subscription has been entered, then this is the date and time of that event and the corresponding subscription term ID (see section 6.4). Otherwise its blank. The membership registry is simply a mapping that associates the identifier (ID) of a member with the corresponding profile. Lastly, there is also a set of BRAQ quotas, called the default membership quotas, used for all base membership BRAQ instances with indirect proxy quotas. The suspension field only impacts a member’s capacity to act through their base membership capacities; any action derived from other roles is unaffected. Also, a member may be suspended even if this field is not set (see section 10.4). A membership may be established for free, as explained in section 10, or it may be paid for a one time cost of burning a given amount of tokens. As a result of free entry, a given key may be associated with a membership but no account. The converse is also possible by definition. Once a membership has been established, it is permanent. For a given key, there may both a corresponding account and membership, or either one exclusively. While an actor may find it practical to identify with the same key in both capacities, the system cannot, and does not, enforce this. 6.3 Paid Membership Paid membership terms represent a set of conditions for a prospective membership, through payment, on the platform, and is defined as 12 Paid Membership Terms - ID: Unique integer identifier known as term ID. - Fee: Quantity of native token that must be provably burned. - Proxy Quota: Initial quota for membership. - Text: String of capped length (UTF-8) describing the human readable conditions to be agreed upon. The platform has a set of terms, called the active paid membership terms, which are currently in place for anyone seeking paid membership. It is updated through a council proposal. Any new terms introduced by the council must have an ID greater than the prior active terms; the initially active terms have an ID of 0. The full history of such terms that were once active is kept in a list known as the paid membership terms T record, which maps the term ID to the corresponding terms. A new actor may join as a member at any time through a request, which will burn the required fee from their account, so long as the platform is accepting members. This is gated by a platform variable referred 6.4 DR AF to as the platform membership gate and can be changed through a proposal. Subscription Subscription terms represent a set of conditions for a prospective subscriber on the platform and are defined by the following: Subscription - ID: Unique integer identifier. - Fee: Quantity of native token that must be provably burned. - Duration: Number of blocks for which the subscription is valid. - Proxy Quota Delta: Set of proxy quotas added to the base level quotas to expand quotas. - Text: String of capped length (UTF-8) describing the human readable conditions to be agreed upon. A member with a subscription that is active, that is, the current block height is lesser than the sum of the subscription entry time and duration is referred to as a subscriber in this period. Similar to that of paid membership and terms, there is an analogues concept of active terms, terms record, and a gate. While members can establish subscriptions at any time, the time line is divided into subscription periods. In each period, a cumulative count of the total amount of fees burned for subscriptions is maintained. At the end of each period, payouts to relevant parties such as publishers, for example, are based on these final tallies. 13 7 Roles, Staking and Slashing A role is a membership status having a fixed number of varieties, which gives access to a range of different rights and correspondingly confers a range of responsibilities. A given member may occupy multiple roles simultaneously. An actor may be required to lock up a certain amount of native tokens for some time under certain conditions, and this is referred to as staking. Typically, this is in the context of participating in some role or performing some action. In some roles, it is possible to raise or lower the staked balance on an ongoing basis within context-specific limits. There will often be a time before a change in the staked amount of tokens is counted toward the actual total staked balance. For increases, this is known as bonding period and for decreases unbonding period. If a stake reduction leads to the actual staked balance dipping below the minimum required for a given role at that time, then a full stake balance reduction is automatically initiated, and no increases can be initiated until the unbonding period is over. Tokens that are in one of these two periods are referred to as in flight. Tokens staked or in flight cannot be reused to stake in another context T at the same time. Under certain scenarios, it may be possible for a member to lose all or a part of their stake; this is referred 8 DR AF to as slashing. Rewards All staking is rewarded in tokens paid out directly to the member account and, if no account exists, then the membership key will be used to credit an account with the same key. These payouts will come at the end of some corresponding time interval and are comprised of two components. The first component, known as the compensation payoff, is of the form xrT , where x is the staked quantity, r is a global nominal per block interest rate, and T is the number of blocks in the given period. If the staked quantity has varied over the period, then x will represent the average time weighted quantity. The second component, referred to as the earned payoff, is related to the particular activity or role that was undertaken in the given period. Hence, the total reward to a given stake in a given period may be written as P x i ∆i T r +C T where xi is the quantity staked in the i-th sub period, which itself lasted ∆i blocks, and C is the earned i payoff. 9 9.1 9.1.1 Governance Council Terms The governance process is divided into a sequence of periods known as terms, and the first term is known as the bootstrap term. Each term, with the exception of the bootstrap term, has a corresponding council, which is a set of staked members responsible for voting over submitted proposals. Proposals are bids to execute given operations on the platform state in order to serve some contemplated end. 14 9.1.2 Elections The council for a given term is established through a council election, where all members have the opportunity to place weighted backing behind prospective councilors who announce their bid for council membership and put up their own corresponding stake. The election is conducted toward the end of a term, and current council members are expected to carry out their responsibility of dispatching proposals throughout their term. The number of council positions in the next term is always set to a given number in the preceding term referred to as the council size. This may be altered through a proposal. A new number goes into effect at the start of the next term. The election has four stages. - Announcements stage: Members get to announce their candidacy for the council. They need to put a minimal amount of stake to be able to do this, which is known as the council staking limit. This limit may be altered through a proposal, and the new limit may come into effect at the start of the next term. When not in the bootstrap term, there may already be existing council members who are also T welcome to announce for the next term, which denotes extending candidacy. A council member may in this case reuse their existing stake, which is referred to as transferring council stake. In this case, they may have to adjust their staking amount to satisfy a staking limit that may have been altered. DR AF There is an upper limit to the number of candidates that may be voted upon and is termed the council candidacy limit. This limit may be altered through a proposal, and the new limit may come into effect at the start of the next term. If there are more candidates satisfying the staking limit than this limit, then candidates are ranked based on the staked amount. The set of candidates who actually end up being eligible after this constraint is applied and termed candidate pool. - Voting stage: All members, including current and prospective council members, back candidates for the next term. Backing refers to staking in support of the candidacy of a member in the candidate pool. Each backing is a sealed commitment to a particular candidate, where the seal is simply salted hashing the candidate identifier. A member may reuse tokens already staked behind an existing council member to a member of the candidate pool, which is referred to as transferring backing stake. - Reveal stage: All members who backed candidates must submit their salts to reveal the candidate in each of their backings. At the end of this period, all backings are tallied for all members in the pool, and all backings without a corresponding revelation are ignored. Regarding considering the council members during tallying, the candidate pool members are ranked in terms of the total amount of stakes across all revealed backings in their favour. All those outside the council size are discarded and, if the council size is not filled, then one can re-enter the announcement stage. - Grace stage: All stake introduced in the given term backing a losing candidate or not revealed, is immediately unstaked. This is done so that all new stake is able to exit the consequences of an unfavourable council. At the end of this period, a new term begins with a new council. This is also is the start of the unbonding period for all stake that does not continue in the next term. 15 9.1.3 Rewards Voters do receive an earned payoff; however, council members receive a payoff proportional to the rate of participation in processing proposals, which is is of the form pi uCM , where pi is the participation rate, i.e., rate of non-abstention (and thus revealed) votes over all votes of the i-th council member, and uCM is a base reward across all council members for the given period. 9.2 9.2.1 Proposals Types At any given time, there exists a finite set of different proposal types. Each type is a value for each of the following properties that apply to all proposals of the given type. - Quorum: The percentage of the council participants who must vote affirmatively in order for the proposal to pass. T - Threshold: The minimum percentage of quorum that must vote for a given alternative for it to pass. - Constitutionality: The number of council periods in a row that must confirm the proposal for it to DR AF pass. A proposal type takes the form of one among three different types of propositions. The binary proposition is a simple pass or reject, the multiple choice proposition require selecting one among at least two different affirmative alternatives or rejection and, lastly, the ranked choice proposition requires providing a total ranking of a finite set of alternatives or rejection. 9.2.2 Life cycle A proposal, of a given type, is first created by a member referred to as the proposal sponsor. The sponsor has to back the proposal with a given amount of stake. This amount may be altered through a proposal, and the new amount goes into effect at the start of the next term. Once a proposal has been created, the council members can start submitting sealed votes on the proposition in what is known as the voting stage. The sealed vote can be one among - Abstention: Signals presence, but unwillingness to cast judgment on substance of vote. - Reject: Against proposal. - Affirm: Pass an alternative or a ranking for binary, multiple-choice, and ranked-choice propositions, respectively. - Slash: Against the proposal, and slash proposal stake. This stage ends on the earliest of the following events (a) All council members have submitted sealed votes. (b) Time since proposal creation has exceeded a designated platform parameter. This amount may be altered through a proposal, and the new amount goes into effect at the start of the next term. 16 (c) End of the given term, the point at which the proposal is automatically rejected by the council. The next stage allows the council members to submit revelations for their prior sealed votes and is referred to as the revelation stage. At the end of this stage, the tallying commences, which works as follows. If all revealed votes are slashes, then the proposal is rejected and the proposal stake slashed. To clear the quorum requirement, the percentage of council members with revealed votes must be no less than the quorum value for the given proposal type. To clear the threshold requirement, the percentage of council members voting in favour of the proposition must be no less than the threshold. For multiple and rankedchoice propositions, this is interpreted to mean the number of votes in favour of the most popular choice or single ranking, respectively. When a proposal passes, it needs to immediately be put into effect; however, many proposal types have some applicability pre-condition that must be satisfied for it to be valid. If this does not hold at this time, then the proposal is simply discarded. This can occur in scenarios where the state of the platform changes in a way not foreseen by the initial proposal sponsor or council. T In all scenarios given above, an archived record of how a proposal was processed will be left for future inspection. Working Groups DR AF 9.3 All non-validator service-provider roles on the platform are organized into domain specific groups termed working groups, which comprise the following. 1. Membership screening: Grant membership status to members while trying to avoid Sybil. 2. Membership curation: Monitor membership base for abuse and Sybil attacks. 3. Content: Curates and manages the availability and integrity of content in the content directory. 4. Storage and distribution: Stores and distributes static data to consumers on demand. 5. Live streaming (in future draft): Distributes dynamic video data to consumers. 6. Discovery: Provides standard discovery services over the content directory to consumers, i.e., search and recommendations. 7. Software development: Develops and deploys all software assets of the platform, including consensus code and user facing applications. 8. Content finance: Curates content finance market and adjudicates project disputes. 9. Advertising: Polices the advertising market on the platform. 10. Communications (in future draft): Administrates the on-chain forums, messaging channel governance, and user support inquires. 17 9.3.1 Leads and workers Each group has two distinct types of roles, namely the group lead and the worker. Leads are elected by the council through the proposal system and are responsible for populating and managing other roles in the given group as well policing the conduct of group workers. Leads can also be replaced or evicted and, if the latter, or if there is no lead to begin with, then no group workers can perform any platform-level actions until a new leader is installed. The particular rights and privilege of a worker is entirely dependant on the group in question. Each group pays out a reward to all group members at a given interval referred to as the group payout period, which is a platform parameter distinct for each group. This may be altered through a proposal, and the new value goes into effect at the start of the next period. 9.3.2 Installing, replacing, and evicting leads There are two scenarios under which a new group lead may be introduced in a given group: in the case T where there is no existing lead, which is only the case while bootstrapping, and is referred to as installation; when an existing lead is leaving their position by their own initiation or alternatively by initiative from the council, and a new one is to be introduced. These are referred to as replacement and eviction, respectively. DR AF In all cases, candidates for a group lead role come from a list on the platform for the given group, referred to as the group lead candidate list. Members can enter the list by staking the amount required to hold the group lead position for the given group. Each list is a fixed size and, if the number of potential candidates who have staked is greater, then inclusion is determined by how much has been staked beyond the limit, although the actual staked amount when introduced a lead is always the staking limit. 10 10.1 Membership Screening and Curation Overview As mentioned before, for example, in section 6, it should be possible to onboard users who do not hold any tokens. This activity, referred to as screening, allows the platform to accommodate new users who wish to try the platform within certain constraints. However, the combination of no robust identity system and allowing users to consume resources without paying on the margin creates its own set of new problems. These resources need not only be in the form of tangibles such as compute and storage, but can also be things like peer member attention. Not only does this result in wasteful overutilisation but, perhaps, more importantly, it allows platform participants to shape their own payouts at a low cost, since resource use is often tied to payouts. For example, viewing content will divert a larger share of payout to the publisher. The Joystream protocol also suffers from these ills in principle, at least under a certain set of policy choices. There is no final solution to this without dealing with the fundamental identity and pricing preconditions. None the less, it is critical to equip the platform with a baseline capacity to engage in the presumed catand-mouse dynamic with such abuse to reduce the feasibility and cost of attacks. This is achieved by two measures: first, there is a capacity to block access to the platform in various ways. This activity is termed suspending and specifically prevents the relevant actor from being able to participate in the platform through base membership actions. Second, when anyone is onboarded through 18 screening, the corresponding platform actor who onboarded them is recorded and can be punished for a long time in future, with a suitable bonding period if the abuse is uncovered. 10.2 Working groups This work is parceled out into two complementary working groups, the screening and curation working groups. Both groups allow all members to engage in the same set of group activities, except for the lead, which is also involved in normal group lead activity.5 10.3 Screening Participants in the screening working group can engage in the screening process and are in that capacity referred to as a screening authority. The precise steps involved in screening, which is an offchain process, are entirely exogenous to the protocol. The set of actual policies and corresponding tools in production at any given time is expected to be the mechanisms that can be employed comprise the following: DR AF (a) Email or social media confirmation. T result of an ongoing coordination, based on policy constraints from the council and group lead. Obvious (b) CAPTCHA, or other labeling, or perceptual tasks. (c) Onboarding delays. (d) Manual human confirmation. As part of being screened, a prospective member must accept a set of terms referred to as the screening terms and defined as Screening terms - ID: Unique integer identifier. - Proxy Quota: Initial quota for membership. - Text: String of capped length (UTF-8) describing the human readable conditions which are being agreed upon. The terms to be used at any given time are known as the active screening terms and can be changed through the proposal system. A new member can be added through screening authority by presenting a signature of the current active terms (or similar) using a key that can also be used as a basis for the membership. When this happens, the ID of the authority is also included in the membership (see section 6.2). 5 In principle it is probably advisable to keep the screening group small, even perhaps to a single actor at any given time, in order to keep the set of stakeholders in this capacity limited. This also makes a longer unbonding and staking period more economical. 19 10.4 Suspension The organization and principles of this working group are identical to the screening working group. There are three distinct forms of suspension that can be initiated, namely - Individual: A specific member can be suspended by setting the appropriate membership field. - Group: A proposal can be submitted allowing for the simultaneous suspension of all members who have been added through screening from a given screening authority within a given window of time in the past. - Lock down: A proposal can be submitted allowing for simultaneous suspension of all members. 10.5 Rewards Data storage and distribution 11.1 Overview DR AF 11 T All working group participants have some given group-based periodic payoff set by the council. Reliably storing and distributing off-chain static data at scale is one of the primary requirements of the platform. This includes data such as media content, metadata, applications and static assets, and private (encrypted) member data such as preferences and statistics. Specifically, this subsystem should satisfy a range of objectives - Consumption: Members can (a) upload content, respecting certain platform quota limits, for free and expect permanence and distribution. (b) securely download data, respecting certain platform quota limits, for free. (c) fully utilize a system with communication and resource constraints of a browser. - Paying: Quota restrictions can be augmented as a result of paying (e.g. through subscription) or discretionary changes made by platform governance. - Fault tolerance: Storage has some level of fault tolerance for all content, which ensures that single actor faults do not lead to permanent data loss. This replication should economize on cost and be sensitive to platform policy regarding the desired rate of tolerance. - Dynamic: The platform should dynamically be able to be and remain effective at distributing content in concert with changes in total volume of downstream demand and where this demand is located. - Privacy: View counts and quota limits are maintained without leaving a permanent public history of what end user viewed what and sharing viewing activity with as few counterparties as possible. 20 - Ad Awareness: It may be desirable to interleave media distribution with a dynamic advertising system and, in order to support this, the infrastructure must know when to inject what ad, to whom, and how long to block until normal distribution is resumed. - Low Bar: Barrier to entry for aspiring service providers is not too high, for example, in the requirement of lots of hardware or stake. The key problem in organizing this part of the platform is correctly enforcing rewards and punishments on the infrastructure providers. This requires that one accurately determines whether they are behaving correctly. At the core of this assessment lies the problem of how to adjudicate disputes over the timeliness and integrity of response to queries. It is fundamentally not possible to furnish direct purely cryptographic proofs about such claims; hence, the fallback of most alternatives is to construct mechanisms that provide game theoretic assurances of honest and reliable conduct. These alternatives most often attempt to be open commodity markets, where buyers and sellers have temporary relationships. Here, a much simpler approach is utilized, where most good conduct is expected based on risk of governance-based sanctions on is assumed to be reliable due to being a long-term player. Working Group DR AF 11.2 T deposited bonds, and losing reputational capital. Honesty of the platform, and thus its governance outcomes, The working group is made up of the following roles - Lead: Has the normal group-lead responsibilities, but also performs two additional coordinating functions, namely (a) Produces policy for how different data should be distributed at any given time. (b) Receives and processes errors about misconduct or unavailability among group members. - Storage: Stores a copy of some subset of data in the data directory and replicates to peers and distributors upon request. - Distributor: Distributes data in the data directory on demand to members. 11.3 Storage providers A storage provider is member of a group of providers termed storage tranche group who share the same participation terms. A tranche is defined as follows: 21 Storage provider Tranche - ID: Unique integer identifier. - Capacity: The number of bytes of storage capacity required. - Out speed: The number of Mbps required. - Stake: The amount of stake required. - Duration: The number of block service to be provided from the initiation block. - Fixed Reward: Quantity of native token earned per unit of time. - Variable Reward: Quantity of native tokens earned per unit of date stored. - Slots: Total number of roles available in this tranche. T - Terms: String of capped length (UTF-8) describing the human readable conditions to be agreed upon. DR AF - Active: Whether tranche is actually possible to use, that is, assign new members. All these are kept in a mapping known as the tranche registry, which maps tranche ID to the corresponding tranche. Even when a tranche is no longer active, or will be used in the future, it continues to be a part of the registry. The participation of a member in the role as a storage provider is represented by a tranche membership and is defined as follows: Tranche membership - Member: Membership ID. - Tranche: Tranche profile ID. - Started: Block height where role started. - Availability: Amount of bytes still available. - Active: The block at which this provider is to be considered active. - Paused: Whether this role is currently paused. Such profiles live in a mapping from the ID to the profile termed the storage providers. A member is only considered a provider when the corresponding profile is registered in this map, and this happens through the group lead. The active status of a membership is meant to afford some time between when the provider has entered the role and when there is a full obligation to provide service. The pausedness of a membership is meant to allow discretionary pause in inbound storage requests due to extraordinary circumstances and can be invoked by the member or lead directly. 22 Note that the same member may participate as a storage provider multiple times and under different tranches. 11.4 Distributors Distributors are organized in a very similar way to storage providers, with analogous concepts such as distributor tranche group, profile, registry and membership, with suitable minor alterations. In particular, tranches will also include information about geographically bound latency guarantees and the number of simultaneous upstream connections. 11.5 Data directory The platform maintains state about the available data, and how it is distributed, in the data directory. All data objects stored correspond to one among a finite set of data object types. Each type is meant to capture T the following storage and distribution requirements for some broader family of objects: - Infrastructure requirements: By allowing a range of guarantees about permanence and performance, which better aligns with the underlying requirements of different data objects, one can allow DR AF better resource utilization. - Access policy: Some objects may only be accessible to a given member for certain periods of time, if at all. The obvious example will be data objects behind paywalls. - Accounting procedures: Some objects may require some kind of accounting or cleanup as a result of accessing the data. This can, for example, be used to record reliable access statistics for media content, i.e., view count. The first requirement is about reducing cost while the latter two about making the same infrastructure parametric and thus reusable for a wide range of purposes. A data object type is specifically designed as follows: Data object type - ID: Unique integer identifier. - Description: Human readable description. - Size limit: When set, represents the maximum number of bytes. - Replication factor: Number of copies for data objects of this type that need to exist in the storage system at any time. The simplest interpretation for this is the minimum number of storage providers that must replicate the data object. - Storage tranches: Set of tranche IDs that can be used with this data type. If empty, then any tranche can be used. - Active: Whether objects of this type can be added at this time. 23 All available types are kept in mapping termed the data object type registry, which maps the ID to such a type. Admissible storage tranches are in part kept on the platform to allow automatic assignment of storage providers to any new data object of a given type. For the same reason, there is no commitment to the distributor tranche because distribution requirements will often depend on internal details about the data object itself, which are hard to fully describe.For example, it can be the case where whenever a particular publisher uploads a media item, there are substantial inbound download requests from a corresponding area. This type of policy rule is better left to discretion to setup rather than an automatic consensus rule. Each data object is defined as follows: Data Object - CID: A content identifier that allows secure authentication of the data under some implicit chunking schema. - Size: Number of bytes occupied by data. DR AF - Added: Date and time for original upload event. T - Type: Data type ID. - Origin: ID of member who uploaded the data. - Liaison: ID of storage provider that accepted the initial upload. - Liaison judgement: One among pending, rejected, and accepted. All records are kept in the data object registry, which is a mapping from the CID to the corresponding record. The fact that a storage provider is storing a data object is represented by a data object storage relationship, which is defined as follows: Data object storage relationship - ID: Unique integer identifier. - CID: CID of data object. - Storage: ID of storage provider which should store object. - Ready: Whether the service relationship is ready to be honored by the provider. Such relationships are kept in the storage relationship registry, which maps the ID to the relationship. Analogous concepts for distribution that are referred to as data object distribution relationship and distribution relationship registry also exist. Lastly, a member downloading a data object is represented by a download session, which is defined as follows: 24 Download session - CID: ID for content. - Consumer: ID for member downloading. - Distributor: ID for distributor that distributes the content. - Initiated: Date and time when the session was initiated. - State: Either started or ended. - Transmitted: Amount of bytes of data actually downloaded. Such sessions are kept in the download session registry, which maps the ID to the session. Please see the discussion (section 18) on how to address obvious scale and privacy problems introduced by sessions and the 11.6 T registry. Uploading DR AF A normal uploading flow is as follows 6 : 1. The user issues a transaction to create a new data object record by providing a CID for the underlying payload as well as information about its size and type ID. The transaction is only valid if (a) the CID is not already in the data registry. (b) the size respects data type size limit. (c) data type is active. (d) sufficient storage capacity is available among active, non-paused, storage providers within the set of tranches available for data type. (e) uploader has no other data object records with pending liason judgment. If so, this will result in the creation of a data object record, where the liason and storage object relationships are automatically assigned. All the latter have an initial status of not being ready. The liason judgment is set to pending. If the record remains pending over some time limit, then the record goes away, and the lead is needed to inspect any received error reports. 2. The user connects to the liason and requests to upload the data by referencing the data object record. The storage provider can validate the request by reading the platform state and can only then proceed to accept the upload. 3. The storage provider will check (a) the payload matches the CID, (b) has the right size, and (c) passes an upload filter7 6 This is a highly informal description which will be fleshed out in future drafts. 7 TBD. 25 If either fails, the judgment will be set to rejected for the given reason. If all pass, the judgement will be set to accepted, and the corresponding storage relationship will be set to ready. 4. The liason must accept incoming replication attempts from all other providers with a storage relationship with the given record. As they receive the payload, each has a responsibility to alter the readiness of their storage relationship. Any relationship that is still not ready after some defined period of time from the time the record has been added is considered a failure. At this point, the lead must inspect any possible reported errors and adjudicate. 5. When the time limit for replication by all storage providers has been exceeded, the lead creates distribution relationships for the record based on local policy. 6. The distributors corresponding to the new relationships can connect to the storage providers that have corresponding storage relationships with ready status to acquire a copy of the payload. Downloading T 11.7 A normal downloading flow is as follows 8 : DR AF 1. The downloader issues a transaction to create a download session by providing the relevant CID. The transaction is accepted once the following holds: (a) the CID corresponds to a data object record (b) the data object record has at least one distributor relationship that is ready (c) the access policy of the data type accepts the request If so, then a session is added to the session registry, which is in the started state and where the distributor has been chosen from the available ready set. 2. The downloader connects to a host corresponding to the assigned distributor and authenticates and finally provides a verifiable reference to the new session. 3. The distributor sends verifiable (based on Authority Key) data chunks in response to requests from the downloader in a tit-for-tat exchange. The downloader sends to the distributor a signature over the claim that a certain total amount of data has been transmitted over the lifetime of the session, analogous to payment channels [10]. To avoid latency, there should be some amount of pipelinining. 4. The exchange ends when either all data has been sent or when the downloader has terminated the exchange. At this point, the distributor will submit a new transactions with the most recent signed consumption statement from the downloader. This transaction will settle both the actual consumed data in the session and the state of the session. 5. Any data type specific accounting policy is executed with reference to the session. 8 This is a highly informal description which will be fleshed out in future drafts. 26 11.8 Entry, exit, and distribution policy updates There are a number of key infrastructure dynamics, such as entry and exit of actors into the roles as distributors or storage providers, and also updates on what is being assigned to what data. These may be initiated and coordinated through off-chain messaging protocols. An honest conduct is expected purely on governance sanctions. This will be described in further detail in the future. 11.9 Policing and data removal The storage and distribution infrastructure is really a utility for the rest of the platform, hence the removal of data from this infrastructure, for any reason, is under the control of the working group which has control over the use case to which the data corresponds. 11.10 Rewards T All payouts take place at a given group-specific payout interval. The group lead is paid a given amount of tokens regardless of what has occurred. Storage providers and distributors both have a fixed and variable payout component, where the latter is based on the actual stored or distributed data quantities, and the DR AF rates are captured in the corresponding tranche profiles. The actual variable base quantities are maintained through the uploading assignment process and data type-specific accounting policies, respectively. 12 Content directory 12.1 Overview The content directory contains information about the media content available on the platform. More importantly, it does not contain the primary media itself, which is stored in a separate off-chain infrastructure described in the section on storage and distribution (section 11). 12.2 Working group The working group comprises the lead and the member. Members are responsible for executing the following functions - Curation: Ensuring that the underlying content media and metadata correspond to each other, e.g., in that they display assets are correct or content is in the correct category, etc. - Policing: Adjudicating disputes around the availability, ownership, and attribution of content. - Filtering: Maintaining and developing the filtering technology in place when publishing to the directory. - Verification: Granting privileged status to publishers and content as verified and canonical, which helps in discovery and resolves disputes over the publisher namespace. 27 12.3 Publisher A publisher is a member who is allowed to publish content in the content directory and is defined as follows: Publisher - Name: This is separate from membership name and is its own namespace. - Description: A description of the publisher. - Brand artifacts: Data directory CIDs for a set of off-chain artifacts that make up the profile brand identity. - Verification status: Whether the implied identity of the publisher profile matches the actor 12.4 T who is in control of the membership. Content DR AF There is a base set of properties for all content on the platform, which includes the following: - Category: The type of content. - Payload: Data directory identifiers for media and metadata. - Owner: A publisher or content project planner (see section 15) who has control over the content and rights to value. - Monetization policy: How end users must pay to access content, among which are being free (with or without advertising), transactional, or subscriber access (only subscribers have access). - Dispute status: Whether some dispute is currently ongoing. This has implications for how end users should engage with the content. There are a fixed set of primary content categories that are supported at any given time. Each category defines a particular schema for how to define key properties, including - Payload format: How to organize the media payload. - Rendering: Metadata about how to play back or render media. - Accessibility resources: Things that assist a variety of users in consuming the content, such as subtitles or translation metadata, dubbing information, etc. - Attribution: Defines who did what in the process of producing the content. Content will also have associated social information around engagement, such as view/access rates and counts, likes, and a comment feed. 28 12.5 Disputes Any member can submit a dispute about any published content, and these disputes are processed by the working group. There will be a range of different dispute forms, some with the goal of entirely removing content while others with changing attribution or ownership information and, as a result, redirect revenue streams. 12.6 Rewards All group members are paid fixed amounts per unit of time. 13 Discovery 13.1 Overview T In order for end users to effectively discover relevant content in the content directory, access to the directory is required, and the ability to execute effective processing heuristics across this data needs to be set promptly. In order to alleviate the resulting processing and bandwidth costs, this will impose there is a designated set 13.2 DR AF of discover nodes that provides these services. Working group The working group is composed of members that run nodes running a discovery provider service, as described in the next section. 13.3 Services There are three types of discover services that are offered by discovery provider nodes - Search: Keyword and filter-based ranked lists of content. - Browsing: Category and filter-based ranked lists of content. - Recommendations: Content identifier-based ranked lists of content. In all three cases, the response provided by a service provider includes the relevant content as well as Merkle proofs, which allows the client to authenticate the integrity of the response. If required, one can extend this to have automated slashing based on bad proofs sent to clients. There is no way to prove omission in this scheme. There will not be a well-defined definition of what this may imply, as different discovery providers are free to pursue their own ranking and discovery policy. Reasonable incentives for good behavior can be generated by encouraging user clients to keep local statistics about the success rate of various providers or by measuring user behavior, which will in turn drive more traffic to better providers. Likewise, the incentive to generate more traffic can be generated by giving a provider the privilege of displaying in-place advertisement, which is not hooked into the normal advertising ecosystem. The inclusion of minimal telemetry feedback to providers can also help them guide the development of their own discovery policies. 29 13.4 Rewards Beyond the incentive described in the prior section, all providers are given a fixed token reward per unit of time. 14 Software development 14.1 Overview Software development needs to be understood broadly, encompassing all activities surrounding research, production and testing of standards (e.g. analogous to BIPs or EIPs), protocols, algorithms, source code, binaries and other digital software assets, as well as deploying such outputs into production environments. Three aspects of this activity are of importance to the platform. Financing T 14.1.1 Many protocols suffer from the lack of an endogenous financing mechanism, and stateless protocols cannot have them by definition. Even in many stateful protocols, key contributors end up either severly underfunded, DR AF which is detrimental to quality and development progress, or relying on third-party revenue sources that do not have incentives that are guided by the interests of all protocol stakeholders. To address this, the platform has a dedicated working group of contributors who are rewarded for providing these sorts of services and are accountable to stakeholders through the governance process. 14.1.2 Development For a variety of reasons, most software development projects for open stateful protocols end up with an equilibrum where the development process is organized around a canonical collaborative state. By collaborative state, we mean some sort of code base and social collaboration metadata about that code base. For example, the state may often be a Git repository, and the collaboration metadata may be repository hosting service of some kind, or it can be a curated mailing list of patches and discussion. Ultimately, some social consensus process emerges for how changes to this state is made and, almost invariably, this process becomes a source of market power, its integrity becoming a security risk, and is not formally accountable to protocol stakeholders. Socially desirable changes may be rejected or adopted too slowly, and changes that are undesirable may be adopted. While fork based exit is in principle an option, it is also expensive. This results in the following specific requirements: - Accountable canonicity The platform provides the means by which everyone securely resolves the same collaborative state at all times. - Open contributions Any member should be able to submit a proposal for changes. - Direct control The governance process may directly mutate the state at any time. 30 - Gated updating and moderation Designated role(s) occupied by a dynamic actor set, subject to governance, have the right to accept contributions or make changes on an ongoing basis. - Immutable and secure updating history An immutable history of all state changes. Even a Git repository only gives a history of states, but is devoid of secure information about whether a given commit was introduced by someone who had the right to do so. Merged commits are in this respect particularly sensitive, as this is typically the way new changes make their way into producing source snapshots. Moreover, Git does not include the broader collaborative state. - Robust availability guarantees The highest level of guarantee is required around the actual availability of state. Given this set of requirements, the platform maintains a set of on-chain Git repositories, which include T familiar functionality, such-a-pull requests, merging, issue tracking, permissions, and publishing releases and test/CI results. Critical changes such as merging are conducted in consensus using ATP. Deployment DR AF 14.1.3 Deployment is the process of converting a set of source assets into final production assets, like binaries, and distributing these securely, and possibly automatically, to end users. This requires the following: - Build authentication Given a commitment to a set of source assets, there must be a reliable, reproducible, and secure way for anyone to determine whether a particular set of production assets are the correct output of this process. - Secure updates There must be secure way for users to acquire or run new versions of software binaries. Given this set of requirements, there is a set of standards for defining and conducting deterministic builds. Software updates occur directly from the platform state. 14.2 Working group There are two group types: lead and contributor. The lead is responsible for creating and assigning permissions on projects to contributors in order to help them perform write operations directly. While anyone can in principle contribute through their effort to development, only contributors have a recurring reward for their involvement. The working group also has its own messaging channel. 14.3 Project A project is the following set of items stored on chain: 1. Git repository. 31 2. Permissions for who, in the working group, is allowed to make write operations, i.e., push and merge into it. 3. A set of open issues and pull requests with a corresponding discussion thread. 4. A set of releases associated with tagged commits. The normal write operations in Git repositories, such as initialization, pushing, merging, and tagging, are fully secured by the platform itself by having the Git processing rules embedded in the consensus itself. Opening issues and pull requests are open to any platform member, but only a working group member with suitable permissions can actually moderate issues or merge requests. 14.4 Artifacts, reproducible, and releases An artifact is a file that is the result of some processing of the source material in a project repo commit. This processing may involve processes such as building, linking, and packaging. There is a format to describe such T processes, and these will always yield fully deterministic outputs. These processes occur entirely off chain; however, the determinism about the outputs is critical in order to facilitate reliable coordination around the results, in particular around the validity of hash commitments of the artifacts. The most important DR AF process is the building process, where this determinism provides reproducible builds. A release is a simple publication of a set of artifacts corresponding to a tagged commit. This can only be done by the group lead and, if the proposed hash commitments turn out to be fraudulent, then they can be challenged through a proposal by anyone. If found to be a correct challenge, then the lead will face sanctions and the challenger will get reward. 14.5 Automated testing There is a format for describing how to run tests off chain. The presence of tests’ metadata prevents pull requests from going through unless the group lead signs on them as suitably passing. Just like in the release process, such sign offs can be challenged. 14.6 Deployment and upgradeability There are two types of deployments on the platform. Light deployments simply involve updating the platform state to reflect a new version of some application is available, whether it is backward compatible, and thus optional, and how to retrieve the application itself. The other type of deployment is heavy deployment and also involves some sort of change to the consensus as well. This change does not involve simply changing some platform parameter value, but rather making an exogenous change to the platform state or processing logic itself. Such a deployment may be just a set of consensus changes that support change in the behavior of a single application or a change in the platform that requires a concerted upgrade to a number of different applications simultaneously. Both types of deployments are triggered when the group lead submit a proposal based on a release. When this proposal is accepted by the council, the application artifacts are replicated to storage and distribution infrastructure from the group lead. Installations on consumer devices to automatically and securely update 32 are conducted by first consulting the chain to detect the deployment and then connecting to the distribution infrastructure to fetch the payload. 15 Content finance The platform has a built-in ecosystem and tools for creators to finance the production of new works through flexible crowd funding, which gives backers a stake through a project-specific token. This stake gives the right to engage in governance over the project, a possible share of revenue generated by produced assets, and possibly the option to trade assets in a market on the platform. 15.1 Working group All working group members, including the lead, have the same two sets of responsibilities T - Curation: Curating the project pool for abusive or non-compliant proposals. - Arbitration: Arbitrating disputes in project, where the primary sanctions would be in the form of 15.2 DR AF banning, redirecting project funds, and slashing organizer stake. Project life cycle A project is initially created by the prospective project organizer, and this step involves specifying - Description: Text, visual, and other assets used for the description of the project. - Assets and terms: What final productive assets will be produced, and what claims, if any, do backers have on different assets in terms of use and reward. - Funding: A description of the funding model of the project, including (a) How much is being raised, minimum and maximum (b) When do the sales begin and how long do they last. (c) How much of the total project stake is up. (d) What jurisdictions are allowed to participate in funding. - Token: A description of the project token, including (a) Name (b) Symbol (c) Whether it is trade able, if so at what earliest time after end of funding period (d) Whether it gives claim on revenue (d) Whether it gives claim to govern - Claimants: Token allocations to those with claims against the project due to their involvement in the production process. 33 The project itself goes through the following states after being submitted: - Review: Here, it will be reviewed to see if it is acceptable within the policy of the platform at the time. - Open: The project becomes visible to the public, and corresponding communication channels become available, namely a messaging room and a messaging forum. - Funding: Backers can send funds to the project. - Production: The raised funds are deployed to create project assets, with the organizer and backers collaborating through a governance process. In particular, the funding may be released based on milestones. - Active: Productive assets are finalized and distributed through the platform and possibly third-party platforms also. Any revenue generated by assets distributed on the platform directly will automatically T pay out claimants based on the given term, possibly subject to governance. Any revenue generated on external platforms must be documented and submitted to the project by the organizer. Failure to do so will trigger a dispute, and possible sanctions, with the arbitrator. DR AF - Terminated: The project is over in that backers have no further active influence or claims. The terms will describe when, or if, this can occur. 16 Advertising The platform has a built-in advertising targeting, auction, and delivery system. It allows advertisers to reach audiences through a competitive bidding process for display time across a variety of surfaces in consumerfacing experiences. A core premise for a well functioning advertising ecosystem is that a substantial number of non-Sybil users are accessing the platform through a well-behaved reference client. 16.1 Working group The advertising working group just has a single member, which is the lead, referred to as the advertising authority. This role is responsible for running nodes that assist end users in fetching the correct advertising campaigns from the auction system, and also settling the state of campaigns upon completion or termination, while keeping the display information off the chain. 16.2 Surfaces and targeting At any given time, there is a fixed set of such surfaces available, each with its own set of display, interaction, and targeting constraints. A separate advertising auction is maintained for each surface, where access allocated to the highest cost per impression bid is currently available. There are two families of targeting parameters, audience, and session parameters. Audience parameters are those that allow one to target consumers based on individual characteristics, such as age interval, gender, location, language, consumption history, wallet balance, etc. This information does not go on the chain in clear text, but some of it may be stored in the membership settings’ object in encrypted form. Session parameters are those that are specific 34 to the context in which the surface is being displayed, thus identifying media being viewed or searched for, or category being browsed, etc. While all surfaces can target based on audience parameters, the type of session parameter available depends on the surface in question. Targeting values will be shared with advertising authority to both select the correct ad and also provide confirmation of viewed ads back to the authority; however, this viewing information is never published on the chain. 16.3 Campaigns A campaign is a bid to occupy a certain surface, subject to a particular set of targeting parameters, at a particular price per impression. Specifically, it includes • Advertiser identification. T • Advertising payload matching constraints of given surface. • Targeting parameter values matching constraints of the given surface. DR AF • Expiry time. • Maximum number of impressions. • Price per impression. • Funds covering maximum expenditure. Once a campaign has been submitted, it lives in a pool of campaigns for the given surface until all the funds have been spent; it is then canceled by the advertiser or the platform. 16.4 Delivery A given advertising surface has a display policy that prescribes when an end user should repopulate an interface (new) content. The following informally describes the steps involved in this process, including a user, an advertising authority, and an advertising server. • The user sends the signed session and the audience targeting values to the advertising authority. • The advertising authority filters the campaign pool for the given surface based on targeting values and returns the highest bidding match, with corresponding Merkle inclusion proofs of campaign payload. • The user fetches the ad from advertising server and receivesthe receipt token in response. • The user sends a receipt including this token, the campaign identifier, and their own key to the advertising authority. • The user renders advertisement. 35 When an advertising authority detects that a campaign has been displayed enough to exhaust the funds locked up, it submits a proof of this to the platform, which also includes information about how many impressions have been derived from surfaces that are tied to publisher content and what content has actually been shown. This proof is made up of all the receipts from the users that have fetched the given ad. It is compressed using the ZkSNARK primitive [11], where the user keys are kept as private inputs. This proof can also enforce limits on how many times any given user can at most have submitted a receipt for a given ad, preventing trivial abuse from a single member. The chain automatically validates the proof and settles the given campaign by burning the funds. The advertiser can cancel the campaign using an analogous process. These proofs are further combined to create proofs about the total amount of advertising revenues a publisher has a claim over a given period of time. 16.5 Rewards The advertising authority receives a payment with two components: a fixed per unit of time payout and a T payout scaled by proportion of campaign settlements for which proofs are actually submitted. Publishers receive a payout from the advertising, not in the traditional staking-based reward, but an unconditional value transfer per unit of time. This amount is set to be a given fraction of the total revenue being driven 17 DR AF through surfaces displaying the content tied to their content. Miscellaneous 17.1 Resolving hosts Frequently, one may need to resolve host nodes corresponding to an actor on the platform identified with a public key. The mapping between this key and the set of active host nodes under the control of the given actor is represented in a DHT. The actor registers mutable records of such hosts under a DHT key corresponding to the public key. When the set of active nodes changes, simply sign a new message reflecting this and store it under the given key. There are many practical implementations of this pattern; for example, IPNS or BEP44 in BitTorrent. 18 Discussion In this section, various avenues of possible or required research and inquiry are explored. - Catastrophic error recovery Given the rich-on-chain feature set of the platform and the aspiration to conduct frequent on-chain upgrades, the classical blockchain operations model of absolutely never having bugs in production, in perpetuity, may be too expensive. Among other costs, this requirement may reduce the speed of improvement and encourage a set of trusted developer gatekeepers. These costs are possibly dead weight for a protocol that does not intend on emphasizing operational availability and integrity above all other objectives. As a result, it may be advisable to investigate various formal and informal protocols that may be relied upon to coordinate recovery among validators from some sort of consensus failure. 36 - BRAQ The currently described model for BRAQ has at least two short comings. First, due to the presence of an inevitably imperfect screening-based membership introduction (see section 10), the number of malicious BRAQ instances may silently grow over time. At some point, a concerted attack across such memberships can make chain throughput unavailable for some time. If such an attack is timed to cover some sensitive time period, it may automatically cause slashing of a platform member. This problem can be ameliorated by, for example, introducing sensible default transaction inclusion policies that favour non-BRAQ-based transactions or simply by including global limits on how many such transactions can be accepted at any given time, perhaps being implemented as a BRAQ instance itself. Second, the actual quota is not sensitive to payloads involved in actions, only the number of actions. This is not fit for a range of different purposes and can easily be amended. T - ATP The obvious problem and risk in using ATP is regarding coming up with a safe time period for a given transaction, which may also depend on the payload. Moreover, its not entirely clear how a validator DR AF must treat the scenario where the processing is not finished, despite the time being up. The simplest approach is to consider it as any other node failure, such as running out of resources, and simply stop the node. There is also the opportunity of saving on processing resources by making the current proposal into a challenge response protocol. In this alternative approach, the final state can be proposed by anyone, subject to some bond, and this proposal can be challenged by anyone during a challenge period. In a challenge, all validators can actually conduct the normal ATP processing and, this way, adjudicate the final dispute securely. A challenger found to be correct will win the bond. Another obvious alternative to the entire ATP approach are things like ZkSNARK [11] and Truebit [12]. However, this would impose severe practical limitations on what processing which within scope. For ZkSNARK, it will be, at present, infeasible to generate proofs for just about all processing that can warrant ATP to begin with, by assumption. For both the approaches, one can almost never reuse the existing implementations of the processing in question, even if it is in principle compatible with the approach-specific computing model (e.g. WASM or register machine), which is also not always going to be the case. - Governance The current proposal for how governance and elections are organised is relatively naive to obvious problems around liveness, vote buying, and validator censorship. This despite governance being at the heart of the capabilities of the platform and the incentive compatibility of the protocol every other actor faces depends on how effective this process is. Most of the work in this proposal is about how to endow a presumed effective governance system with all the assets constituting a functional content platform. Further work on incorporating more mature ideas is needed. - Screening and suspension and seb 2.0 assets 37 One of the biggest weaknesses of the current proposal is that it may or may not be feasibleto manage the integrity of the memberships that are established through screening, in particular since it may be difficult to properly identify malicious attacks in production and, even if one could, the corresponding screening authority may no longer be bonded. The most obvious solution to this problem is to make a screening authority the owner of screened memberships and disable them when the authority unbonds. Members could get rescreened with a new authority, using the old keys, in order to preserve their membership. This may coincidentally ameliorate one of the other primary limitations of the platform, due to the state of current infrastructure, which is the inability to properly own assets such as domains and app store entries. An ecosystem of such screeners can own these assets, conduct their own screening procedure, and capture in the upside the membership base they bring to the platform. - Software development Keeping this entire development process has resource costs, not primarily in throughput capacity but state size. For example, a very mature large open-source project may have a Git repository that T occupies dozens of gigabytes in, primarily, commit object blobs. This is not a non-starter, per say, but clearly has costs that need to be recognized. There are other approaches, such as the OSCoin and the Radicle stack [13], which aim to keep the entire process off chain, extend the Git protocol to DR AF also incorporate the collaborative assets, and delegate consensus to a trusted set of actors. This does not satisfy all the outlined requirements and begs the question of how to make the consensus actors accountable to the platform; however, it has the benefit of being cheaper on the platform blockchain. Another issue requiring further work is how to safely update the platform in concert with user facing applications that make assumptions about how the platform functions at any given point of time. This is further complicated by the objective of wanting to use the platform itself, as the infrastructure to do the application updates. - Storage and distribution The major problem in the current approach is that all user-downloaded events result in a set of transactions and leave a permanent public history of downloads. This is infeasible from both a capacity and privacy perspective. The alternative currently being explored involves offloading these transactions into a separate chain with trust model based on fraud proofs, and governance to ensure availability, inspired by the Plasma framework. [14]. By committing blocks, and in particular state commitments, into the main blockchain, it becomes possible to make positive claims about the current state in the parallel chain at different times, such as the total amount of data a distributor has moved or the total number of downloads for a particular data object. Expired or fraudulent states can be challenged in the same way during an exit period. Privacy can be introduced by allowing members to use pseudonymous identifier in the parallel chain, which can be proven to match a main chain membership through an appropriate ZkSNARK. The disadvantage of this approach is the complexity and latency of main chain state changes. An alternative can be to dramatically change the trust model and rely on data being shared entirely out of band w.r.t. any shared public state, and then having a voting process-based main chain update based on this objective verifiable data. A secondary objective is to replace full replication with erasure coding for each data object [15] such that less total storage space is required for a given level of fault based on unavailability risk. This 38 makes the storage costs lower. References [1] Albert O Hirschman. Exit, voice, and loyalty: Responses to decline in firms, organizations, and states, volume 25. Harvard university press, 1970. [2] Ethan Buchman, Jae Kwon, and Zarko Milosevic. The latest gossip on BFT consensus. CoRR, abs/1807.04938, 2018. [3] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference, pages 357– 388. Springer, 2017. [4] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. Algorand: Scaling T byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, SOSP ’17, pages 51–68, New York, NY, USA, 2017. ACM. DR AF [5] E. Buchman J. Kwon. Cosmos - a network of distributed ledgers. [6] V. Buterin. Blockchain resource pricing. [7] Nick Johnson. Ethereum domain name service - specification. [8] J. Poon. Handshake. [9] G. Wood. Polkadot: Vision for a heterogeneous multi-chain framework draft 1. [10] Bitconi Wiki. Payment channels. [11] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. Succinct non-interactive zero knowledge for a von neumann architecture. In USENIX Security Symposium, pages 781–796, 2014. [12] Jason Teutsch and Christian Reitwießner. A scalable verification solution for blockchains. url: https://people. cs. uchicago. edu/teutsch/papers/truebit pdf, 2017. [13] OScoin. Radicle, 2019. [14] Joseph Poon and Vitalik Buterin. Plasma: Scalable autonomous smart contracts. White paper, 2017. [15] Irving S Reed and Gustave Solomon. Polynomial codes over certain finite fields. Journal of the society for industrial and applied mathematics, 8(2):300–304, 1960. 39