POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 9 7 the limitations of Bitcoin, providing such a peg securely is what amount of stake in the system. There will be no- a non-trivial undertaking. Delivering a transaction from table differences, though: Bitcoin to Polkadot can in principle be done with a pro- • Contracts cannot be deployed through transac- cess similar to that for Ethereum; a “break-out address” tions; following from the desire to avoid applica- controlled in some way by the Polkadot validators could tion functionality on the relay-chain, it will not receive transferred tokens (and data sent alongside them). support public deployment of contracts. SPVproofs could be provided by incentivised oracles and, • Computeresourceusage(“gas”) is not accounted; together with a confirmation period, a bounty given for since the only functions available for public usage identifying non-canonical blocks implying the transaction will be fixed, the rationale behind gas accounting has been “double-spent”. Any tokens then owned in the no longer holds. As such, a flat fee will apply in “break-out address” would then, in principle, be con- all cases, allowing for more performance from any trolled by those same validators for later dispersal. dynamiccodeexecutionthatmayneedtobedone The problem however is how the deposits can be se- and a simpler transaction format. curely controlled from a rotating validator set. Unlike • Special functionality is supported for listed con- Ethereum which is able to make arbitrary decisions based tracts that allows for auto-execution and network- upon combinations of signatures, Bitcoin is substantially message outputs. more limited, with most clients accepting only multi- In the event that the relay-chain has a VM and it be signature transactions with a maximum of 3 parties. Ex- based around the EVM, it would have a number of mod- tending this to 36, or indeed thousands as might ulti- ifications to ensure maximal simplicity. It would likely mately be desired, is impossible under the current pro- have a number of built-in contracts (similar to those at tocol. One option is to alter the Bitcoin protocol to en- addresses 1-4 in Ethereum) to allow for platform-specific able such functionality, however so-called “hard forks” in duties to be managed including a consensus contract, a the Bitcoin world are difficult to arrange to say the least. validator contract and a parachain contract. One possibility is the use of threshold signatures, crypto- If not the EVM, then a Web-Assembly (Wasm) back- graphic schemes to allow a singly identifiable public key to end is the most likely alternative; in this case the overall be effectively controlled by multiple secret “parts”, some structure would be similar, but there would be no need or all of which must be utilised to create a valid signa- for the built-in contracts with Wasm being a viable target ture. Unfortunately, threshold signatures compatible with for general purpose languages rather than the immature Bitcoin’s ECDSA are computationally expensive to create and limited languages for the EVM. and of polynomial complexity. Other likely deviations from the present Ethereum pro- Since the ultimate security of the deposits rests with tocol are quite possible, for example a simplification of the a number of bonded validators, one other option is to transaction-receipt format allowing for the parallel execu- reduce the multi-signature key-holders to only a heavily tion of non-conflicting transactions within the same block, bonded subset of the total validators such that threshold as proposed for the Serenity series of changes. signatures being feasible (or, at worst, Bitcoin’s native It is possible, though unlikely, that a Serenity-like multi-signature is possible). This of course reduces the “pure” chain be deployed as the relay-chain, allowing for a total amount of bonds that could be deducted in repara- particular contract to manage things like the staking token tions should the validators behave illegally, however this balances rather than making that a fundamental part of is a graceful degradation, simply setting an upper limit of the chain’s protocol. At present, we feel it is unlikely this the amount of funds that can securely run between the will offer a sufficiently great protocol simplification to be two networks (or indeed, on the % losses should an attack worth the additional complexity and uncertainty involved from the validators succeed). in developing it. As such we believe it not unrealistic to place a reason- There are a number of small pieces of functionality re- ably secure Bitcoin interoperability “virtual parachain” quired for administrating the consensus mechanism, val- between the two networks, though nonetheless a substan- idator set, validation mechanism and parachains. These tial effort with an uncertain timeline and quite possibly could be implemented together under a monolithic proto- requiring the cooperation of the stakeholders within that col. However, for reasons of auguring modularity, we de- network. scribe these as “contracts” of the relay-chain. This should 6. Protocol in Depth be taken to mean that they are objects (in the sense of object-orientated programming) managed by the relay- The protocol can be roughly broken down into three chain’s consensus mechanism, but not necessarily that parts: the consensus mechanism, the parachain interface they are defined as programs in EVM-like opcodes, nor and interchain transaction routing. even that they be individually addressable through the account-system. 6.1. Relay-chain Operation. The relay-chain will likely be a chain broadly similar to Ethereum in that it 6.2. Staking Contract. Thiscontractmaintainstheval- is state-based with the state mapping address to account idator set. It manages: information, mainly balances and (to prevent replays) a • which accounts are currently validators; transaction counter. Placing accounts here fulfils one pur- • which are available to become validators at short pose: to provide accounting for which identity possess notice; 7 As a means of representing the amount a given holder is responsible for the overall security of the system, these stake accounts will inevitably encode some economic value. However, it should be understood that since there is no intention that such values be used in any way for the purpose of exchanging for real-world goods and services, it should be accordingly noted that the tokens not be likened to currency and as such the relay-chain retain its nihilistic philosophy regarding applications.