POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 13 This has the advantage of relaxing the equivalence be- execute the block within some limit (e.g. 50% of the to- tween participants and chains. Essentially, chains can tal time allowed between blocks). Another is that the grow (along with the original chain validator set), whereas block is definitely overweight—this would be if more than the participants, and specifically those taking part in data- two-thirds declare that they could not execute the block availability testament, can remain at the least sub-linear within said limit. One final possibility is a fairly equal and quite possibly constant. split of opinion between validators. In this case, we may choose to do some proportionate punishment. 6.5.4. Collator Preferences. One important aspect of this To ensure validators can predict when they may be system is to ensure that there is a healthy selection of proposing an overweight block, it may be sensible to re- collators creating the blocks in any given parachain. If a quire them to publish information on their own perfor- single collator dominated a parachain then some attacks mance for each block. Over a sufficient period of time, become more feasible since the likelihood of the lack of this should allow them to profile their processing speed availability of external data would be less obvious. relative to the peers that would be judging them. One option is to artificially weight parachain blocks in a pseudo-random mechanism in order to favour a wide va- 6.5.6. Collator Insurance. One issue remains for valida- riety of collators. In the first instance, we would require tors: unlike with PoW networks, to check a collator’s as part of the consensus mechanism that validators favour block for validity, they must actually execute the trans- parachain block candidates determined to be “heavier”. actions in it. Malicious collators can feed invalid or over- Similarly, we must incentivise validators to attempt to weight blocks to validators causing them grief (wasting suggest the weightiest block they can find—this could be their resources) and exacting a potentially substantial op- done through making a portion of their reward propor- portunity cost. tional to the weight of their candidate. To mitigate this, we propose a simple strategy on the To ensure that collators are given a reasonable fair part of validators. Firstly, parachain block candidates sent chance of their candidate being chosen as the winning to validators must be signed from a relay chain account candidate in consensus, we make the specific weight of a with funds; if they are not, then the validator should drop parachain block candidate determinate on a random func- it immediately. Secondly, such candidates should be or- tion connected with each collator. For example, taking dered in priority by a combination (e.g. multiplication) of the XOR distance measure between the collator’s address the amount of funds in the account up to some cap, the andsomecryptographically-secure pseudorandom number number of previous blocks that the collator has success- determined close to the point of the block being created fully proposed in the past (not to mention any previous (a notional “winning ticket”). This effectively gives each punishments), and the proximity factor to the winning collator (or, more specifically, each collator’s address) a ticket as discussed previously. The cap should be the same random chance of their candidate block “winning” over as the punitive damages paid to the validator in the case all others. of them sending an invalid block. To mitigate the sybil attack of a single collator “min- Todisincentivise collators from sending invalid or over- ing” an address close to the winning ticket and thus being weight block candidates to validators, any validator may a favourite each block, we would add some inertia to a col- place in the next block a transaction including the offend- lator’s address. This may be as simple as requiring them ing block alleging misbehaviour with the effect of transfer- to have a baseline amount of funds in the address. A more ring some or all of the funds in the misbehaving collator’s elegant approach would be to weight the proximity to the account to the aggrieved validator. This type of trans- winning ticket with the amount of funds parked at the action front-runs any others to ensure the collator cannot address in question. While modelling has yet to be done, remove the funds prior to the punishment. The amount of it is quite possible that this mechanism enables even very funds transferred as damages is a dynamic parameter yet small stakeholders to contribute as a collator. to be modelled but will likely be a proportion of the val- idator block reward to reflect the level of grief caused. To 6.5.5. Overweight Blocks. If a validator set is compro- prevent malicious validators arbitrarily confiscating colla- mised, they may create and propose a block which though tors’ funds, the collator may appeal the validator’s deci- valid, takes an inordinate amount of time to execute and sion with a jury of randomly chosen validators in return validate. This is a problem since a validator group could for placing a small deposit. If they find in the valida- reasonably form a block which takes a very long time to tor’s favour, the deposit is consumed by them. If not, the execute unless some particular piece of information is al- deposit is returned and the validator is fined (since the ready known allowing a short cut, e.g. factoring a large validator is in a much more vaulted position, the fine will prime. If a single collator knew that information, then likely be rather hefty). they would have a clear advantage in getting their own candidates accepted as long as the others were busy pro- 6.6. Interchain Transaction Routing. Interchain cessing the old block. We call these blocks overweight. transaction routing is one of the essential maintenance Protection against validators submitting and validat- tasks of the relay-chain and its validators. This is the ing these blocks largely falls under the same guise as for logic which governs how a posted transaction (often short- invalid blocks, though with an additional caveat: Since ened to simply “post”) gets from being a desired output the time taken to execute a block (and thus its status as from one source parachain to being a non-negotiable in- overweight) is subjective, the final outcome of a vote on put of another destination parachain without any trust misbehaviour will fall into essentially three camps. One requirements. possibility is that the block is definitely not overweight— We choose the wording above carefully; notably we in this case more than two-thirds declare that they could don’t require there to have been a transaction in the source