Bridge parachain and service

[gavofyork]

This is essentially the "Parity Bridge" but for Substrate. The idea is to build a Substrate light-client SRML module that is able to track the Grandpa authority set of another Substrate chain (that runs Grandpa finality obviously). With this is can track headers. Each chain would keep a DigestItem (in the header) of the trie root of outgoing messages.

Validators on the "sub-chain" would track the "super-chain" and vice-versa. There would be a trie root (from the DigestItems in the headers) for the outgoing message queue on each chain that is synced into the other chain along with the preimages (the bridge nodes would need to be full nodes in order to extract the preimages). This would allow both chains to send and receive messages (in the form of serialised Calls).

Since tracking a Grandpa set (and the associated headers) is computationally cheap, the super-chain would be able to handle a lot of bridged sub-chains.

[wooparadog]

@gavofyork Hi Gavin. Is there a timeline this feature will be implemented? If not, could you give some tips how to write a sane one(between substrate chains)?

Thanks

[burdges]

We noticed earlier this week that limiting the value transacted by a bridge improves security.

We only have some limited number of validators v check each block, with μ of those being extra checks. Among these, we have on average μ' of these extra checks occurring in the first tranche of the extra checks. These expected μ' checks are completely unforeseeable by an adversary.

I think the strongest rational attack goes roughly:

An adversary who possesses over 1/3rd of the stake, makes a bad parachain block available to less than 1/3rd of the honest validators, and votes on it themselves, so that the block can reach finality without being available to 1/3rd of the honest validators. In advance, the adversary has ensured that they control a full set of v checks early, so all parachain validators and a full set of μ in the first tranche of extra checks.

In expectation, there are still μ'/3 honest extra checks in the in the first tranche, but the actual number k might be zero. If k is non-zero, then the adversary must reveal their bad block in the time dictated by the validity scheme for extra checks. If k is zero, then the adversary can reveal their bad block anytime they like. In either case, they much eventually reveal they bad block and be slashed s*v where s is the stake per validator, but most of their nodes survive unscathed.

An adversary who liked the k non-zero case could be slashed less than v, so bridges should not consider relay chain blocks final until they witness the "super-finality" of a full v extra checks. We caution that "super-finality" is lost if an extra checker gets slashed, so our extra checks rules should add more extra checks whenever an extra checker gets slashed.

An adversary could repeat this attack before being slashed with some overlap in this set of v validators too, thus reducing the total slash, but also more risk of being in the k non-zero case where their time runs short. We can model an extra check overlap factor f more precisely. It depends upon the v, the number of validators, the extra check time, adversary's impact on randomness, etc., but we can likely prove some bound like f<2 fairly easily.

There are also other m bridges receiving dots (messages) from the same sender parachain in the same relay chain block, which creates another overlap type.

We tentatively suggest bridges limit their incoming dot volume per block per sender parachain to sv/f/m. In short, if bridges demand super-finality then an adversary must loose sv per block with double spends, less two slashing overlap types, so dot limits per block should limit even extremely powerful adversaries.