# XCMP Networking

Replaced by https://hackmd.io/@rgbPIkIdTwSICPuAq67Jbw/S1hPapkHv

We compute parachain messages for XCMP as an output of the sending chain's execute block function.

We block parachains until they recieve and can process their XCMP messages, which requires extremely reliable networking.

There are four parties who possess the outgoing XCMP messages from a parachain block: some collators from the sending parachain, primary backing checkers aka parachain validators, secondary approval checkers, and all validators attesting to availability possess their erasure coded block piece.

We've several strategies for this networking for parachain messages in XCMP, but they roughly divide into push vs. pull and who actually sends the message data.

## Collators-to-collators

If collators or other nodes of the sending and recieving parachains communicate, then we improve performance for polkadot by requiring less work from validators.

We might improve performance for parachains too when sending parachains have good infrastrutures. We could harm performance for recieving parachains when sending parachains lack good infrastrutures however. Incompatable with parathreads probably.

We've zero security from these, so they always require some fallback to validators. A priori, they lack any incentives too, although recieving chains could drop connections with bad sending chains.

We must impose considerable structure upon parachains for collator-to-collator transfers because the parachains must expose their infrastruture, perhaps including key material. As such, this requires extensive develoment work inside cumulus.

*Important eventually*: Zero security or incentives, and high code complexity, but important for pipelining.

### Pushed messages

We might enable better pipelining with messages pushed directly into the recieving parachain's memepool.

We could push messages from either collators or preliminary backing checkers, but anything later sounds useless for pipelining. We could push only candidate reciepts from preliminary backing checkers or only hashes from collators of course.

We've zero security from pushed messages of course. We've no incentives for pushes except recievers not dropping connections.

*Reevaluate later*: Zero security or incentives, and high code complexity, but maybe helpful for pipelining.

## Attestors-to-collators

Any validators who check the sending parachain's block, either primary backing or secondary approval, produced the message, so they should store these and provide them upon request by collators of the recieving parachain.

We'd expect reasonable performance even with crappy parachain infrastruture, maybe even iuncluding some parathread designs, but worse pipelining than collator push designs.

It adds some network and storage load to validators, so validators should expire this data eventually, which limits parathread usage.

We're secure roughly when A&V remains secure, but some gap exists. Incentives already exist here, provided all validators profit from attesting.

*Acceptable first implementation*: Good security, lowest code complexity, adaptable for all use cases with compromises in paramater choices.

## Attestors-to-attestors

Since attestors are distributing block pieces to each other already as part of the A&V protocol, we can re-use this protocol for distributing XCMP messages.

The data flow is very similar: Every outbox, one from each sending chain, is to be split on a per-recipient basis. These are analogous to the pieces in the A&V protocol. Then for each receiving chain, the messages from every sender are to be joined into an inbox, to be passed onto the chain collators.

An extension to the A&V protocol for sending these messages is straightforward to implement - we can colocate these XCMP messages with the A&V pieces.

Note: message outboxes are also encoded into the A&V pieces, but these are not readily-accessible without reconstructing the whole block, which is expensive. This section rather refers to sending message contents in a plainly-accessible form, of course properly authenticated.

Improves security over attestors-to-collators, and requires less storage from validators. We can re-use the existing A&V connections, thus opening no extra connections, and no extra complexity in defining and implementing a new topology.

## Independent availability

Add outgoing messages into the availability store seperately.

Improves security over attestors-to-collators, and requires less storage from validators, but requires far more network connections, which increases latency.

Implementation becomes reasonable with a properly abstracted availability system, but impossible otherwise.

Interesting for large messages, especailly if both the sending and recieving messages use the same data, avoiding duplication. It'd suck for small messages though.

*Eventually*: Improvements in security and for large messages appear insufficent to justify blocking parachain work on availability reconstruction work.

### Reconstruct blocks

Any collators from the recieving parachain could pay to download the full block of the sending parachain.

Absoljutely terrible performance, but good security like independent availability.

*Avoid*: Independent availability has exactly the same blockers.

## Summary:

We'll want collators-to-collators connecrtions eventually, but they appear complex, and push vs pull need more evaluation.

We could avoid implementing attestors-to-collators _if_ we believed independent availability might out perform attestors-to-collators, meaning we'd only ever implement collators-to-collators and independent availability.

We'd rather spend limited networking resources reconstructions in A&V though, so we'll almost surely want attestors-to-collators eventually.

I'd thus suggest our first implementation target be attestors-to-collators, with the second being collators-to-collators.

### Related:

https://hackmd.io/ILoQltEISP697oMYe4HbrA?view
...