POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 8 Ethereum where they can be interpreted and enacted by it need simply call into a special “break-out contract”. a transaction-forwarding contract. In the other direction, Thebreak-out contract would take any payment that may we foresee the usage of specially formatted logs coming be required and issue a logging instruction so that its ex- from a “break-out contract” to allow a swift verification istence may be proven through a Merkle proof and an as- that a particular message should be forwarded. sertion that the corresponding block’s header is valid and canonical. 5.5.1. Polkadot to Ethereum. Through the choice of a Of the latter two conditions, validity is perhaps the BFTconsensus mechanism with validators formed from a most straightforward to prove. In principle, the only re- set of stakeholders determined through an approval voting quirement is for each Polkadot node needing the proof mechanism, we are able to get a secure consensus with an (i.e. appointed validator nodes) to be running a fully syn- infrequently changing and modest number of validators. chronised instance of a standard Ethereum node. Unfor- In a system with a total of 144 validators, a block time of tunately, this is itself a rather heavy dependency. A more 4 seconds and a 900-block finality (allowing for malicious lightweight methodwouldbetouseasimpleproofthatthe behaviour such as double-votes to be reported, punished header was evaluated correctly through supplying only the and repaired), the validity of a block can reasonably be part of Ethereum’s state trie needed to properly execute considered proven through as little as 97 signatures (two- the transactions in the block and check that the logs (con- thirds of 144 plus one) and a following 60-minute verifica- tained in the block receipt) are valid. Such “SPV-like”6 tion period where no challenges are deposited. proofs may yet require a substantial amount of informa- Ethereum is able to host a “break-in contract” which tion; conveniently, they would typically not be needed at can maintain the 144 signatories and be controlled by all: a bond system inside Polkadot would allow bonded them. Since elliptic curve digital signature (ECDSA) re- third-parties to submit headers at the risk of losing their covery takes only 3,000 gas under the EVM, and since bond should some other third-parity (sometimes referred we would likely only want the validation to happen on a to as a “fisherman”) provide a proof that the header is in- super-majority of validators (rather than full unanimity), valid (specifically that the state root or receipt roots were the base cost of Ethereum confirming that an instruction impostors). was properly validated as coming from the Polkadot net- On a non-finalising PoW network like Ethereum, the work would be no more than 300,000 gas—a mere 6% of canonicality is impossible to proof conclusively. To ad- the total block gas limit at 5.5M. Increasing the num- dress this, applications that attempt to rely on any kind ber of validators (as would be necessary for dealing with of chain-dependent cause-effect wait for a number of “con- dozens of chains) inevitably increases this cost, however firmations”, or until the dependent transaction is at some it is broadly expected for Ethereum’s transaction band- particular depth within the chain. On Ethereum, this width to grow over time as the technology matures and depth varies from 1 block for the least valuable transac- infrastructure improves. Together with the fact that not tions with no known network issues to 1200 blocks as was all validators need to be involved (e.g. only the highest the case during the initial Frontier release for exchanges. staked validators may be called upon for such a task) the On the stable “Homestead” network, this figure sits at limits of this mechanism extend reasonably well. 120 blocks for most exchanges, and we would likely take Assuming a daily rotation of such validators (which is a similar parameter. fairly conservative—weekly or even monthly may be ac- So we can imagine our Polkadot-side Ethereum- ceptable), then the cost to the network of maintaining interface to have some simple functions: to be able to this Ethereum-forwarding bridge would be around 540,000 accept a new header from the Ethereum network and val- gas per day or, at present gas prices, $45 per year. A ba- idate the PoW, to be able to accept some proof that a sic transaction forwarded alone over the bridge would cost particular log was emitted by the Ethereum-side break- around $0.11; additional contract computation would cost out contract for a header of sufficient depth (and forward more, of course. By buffering and bundling transactions the corresponding message within Polkadot) and finally together, the break-in authorisation costs can easily be to be able to accept proofs that a previously accepted but shared, reducing the cost per transaction substantially; not-yet-enacted header contains an invalid receipt root. if 20 transactions were required before forwarding, then To actually get the Ethereum header data itself (and the cost for forwarding a basic transaction would fall to any SPV proofs or validity/canonicality refutations) into around $0.01. the Polkadot network, an incentivisation for forwarding In this model, Polkadot’s validator nodes would have data is needed. This could be as simple as a payment to do little other than sign messages. To get the trans- (funded from fees collected on the Ethereum side) paid actions actually routed onto the Ethereum network, we to anyone able to forward a useful block whose header is assume either validators themselves would also reside on valid. Validators would be called upon to retain informa- the Ethereum network or, more likely, that small bounties tion relating to the last few thousand blocks in order to be offered to the first actor who forwards the message on be able to manage forks, either through some protocol- to the network (the bounty could trivially be paid to the intrinsic means or through a contract maintained on the transaction originator). relay chain. 5.5.2. Ethereum to Polkadot. Getting transactions to be 5.6. Polkadot and Bitcoin. Bitcoin interoperation forwarded from Ethereum to Polkadot uses the simple no- presents an interesting challenge for Polkadot: a so-called tion of logs. When an Ethereum contract wishes to dis- “two-way peg” would be a useful piece of infrastructure patch a transaction to a particular parachain of Polkadot, to have on the side of both networks. However, due to 6 SPV refers to Simplified Payment Verification in Bitcoin and describes a method for clients to verify transactions while keeping only a copy of all blocks headers of the longest PoW chain.