xp_network_protocol_v_1.md

[DimaBryuhanov]

initial proposal

[xlc]

I am super lost and not able to follow your diagram. Can you provide some more concrete examples?

Seems like this needs to be installed on relaychain? That's not going to happen because the whole point of XCMP is that messages can be dispatched parachain-to-parachain without involvement of relaychain.

[DimaBryuhanov]

@xlc, @Noc2,

Thank you for your kind comments.

1. There was a misunderstanding about how XCMP messages are processed and whether the Relay Chain is responsible for their security. We are planning to use XCMP as a transport layer for our messages and once SPREE is available we will migrate to SPREE. The Relay Chain was not meant to be changed.
2. A reduced scheme of interaction may look like this:

• Parachain A sends a transaction (TX) bytecode code to Parachain B via our pallets.
• Parachain B confirms that the TX bytecode has been received & commits the TX to the blockchain.
• If a fatal error occurs while processing the message or the TX code in the target pallet or parachain - the initiating pallet / parachain are notified that the TX negotiation is terminated and the blob with the TX state is deleted.
• Once the blockchain validators reject or add the TX to the nearest block Parachain B notifies the initiating parachain about the Success or Failure with the TX related data.

3. Every TX is marked with a unique TopicID, which is very useful when multiple TXs occur simultaneously between the two parachains.
4. The current state of every TX is stored in a blob, adding 64 bits to the TX binary code, where

• 16 bits hold the TopicID,
• 16 bits hold the state flags,
• 32 bits hold the length of the TX bytecode (for compatibility with other languages).

5. The TX binary is only sent once. When other notifications occur - they only use the first 32 bits of the blob. Such messages should not produce significant overhead for the blockchain.
6. Since our pallet is a part of its parent parachain, it can listen to the TX related events and, once the event occurs, inform parachian A without being asked. This will reduce multiple requests about the status of the TX in parachain B from parachain A.
7. Once the negotiation about a TX is over, the blob is deleted and the TopicId is free to be reused.
8. Scalability: every parachain can have up to 2^16 = 65,536 TopicIDs at the same time in every peer parachain.
   We have studied the General Grants Program and the Open Grants Program approved projects. None of the projects offer the same functionality.

[xlc]

So the main use case is able to get notified on xcm execution status on the dest chain?

polkadot-fellows/xcm-format#22 already includes an response message for dispatches.

[DimaBryuhanov]

As far as we understood, in the xcm protocol discussed in the polkadot-fellows/xcm-format#22 proposal, the messages get the IDs and the requesting pallets get replies to the marked messages.

The xcm protocol discussed in #22 proposal, makes sure it is delivered to the target pallet, it returns an error if the target pallet has not been found. But does it tackle the current state of a transaction?

XP.network protocol

• stores the blob with the transaction byte code plus
• the current state of this transaction's execution
• It also confirms to the requesting pallet, that it is going to execute exactly the code that was sent, not anything altered or forged.
• It listens to the parachain's events and extracts the one, related to the tracked transaction. And then it could use your protocol to deliver the result back to the requesting pallet.

It seems that the protocol in the proposal #22 could be the transport layer for XP.network's. What do you think?

[DimaBryuhanov]

Hello @xlc, @Noc2
Hope you had time to verify our explanation and now it makes more sense. Please, advise what are the following steps for us to proceed with the project.

[xlc]

I don't think I 100% understand the proposal but it is making much more sense now. Maybe you should update the proposal to include the new information from your comments.

BTW I am not from W3F/Parity and have no say on the process. I am just a community contributor.