[Referendum 86 Moonbeam/0 Moonriver] [Status: passed] Make key information more accessible on XCM/HRMP Channel Openings for community

Governance
,
1

Standardize XCM/HRMP Channel Opening Proposals and Disclosures

TL:DR

Let’s make key information more accessible to Moonriver and Moonbeam community members when voting on XCM/HRMP Channel Openings and when using the Moonbeam Dapp.

Summary

XCM enables cross-chain collaboration between parachains and is a hallmark feature of Kusama / Polkadot as well as an important aspect of Moonriver’s / Moonbeam’s growth. However, with any new tech integration there are risks and the Moonriver and Moonbeam community should be more easily able to assess these risks when voting on whether to open an HRMP channel (enabling XCM) with another parachain.

To help ensure the community is more informed on XCM/HRMP Channel openings, this proposal addresses two items:

  • #1 A standard template for Proposals to accept/open XCM/HRMP channels to/from Moonriver/Moonbeam, including Required Key Disclosures
  • #2 Suggested enhancement to the Moonbeam Dapp to link to those Disclosures for assets supported in the Moonbeam Dapp

XCM Channel Opening Governance Template and Required Key Disclosures

  • #1 A draft of the Proposal must be posted in the Moonbeam Forum to the community to review, ask questions and provide suggestions. The Proposer must submit a draft of their Proposal to an “XCM” Category in the Forum and tag either Moonriver or Moonbeam.

    • While there is no required time the Draft Proposal should be available in the Forum before being submitted on-chain, there is benefit in gathering community engagement, feedback and support in this stage. In addition, community members and forum moderators can highlight to the Proposer if required information regarding Disclosures is missing allowing the Proposer to amend and refine the Proposal before submitting in Governance.

  • #2 Proposer for a XCM/HRMP Channel Opening must follow a standardized XCM/HRMP Channel Opening Proposal Template

    • i. Title: [Network Project Name] Proposal to [Open/ Accept HRMP] Channel
    • ii. Key Disclosures: see below the required format and content
    • iii. TL:DR: One sentence summarizing Proposal
    • iv. Network Information: One sentence summarizing your Network and relevant links to your Network website, Twitter and social channels.
    • v. Summary: Brief description of the content of the Proposal
    • vi. On-Chain Proposal Reference: Include Moonriver or Moonbeam on-chain Proposal # and Hash
    • vii. Technical Details: Provide technical information required for community to understand intended purpose of Proposal
    • viii. Additional Information: (optional): this last section is optional if there is more information the Network thinks would be relevant for the community but does not fit into the sections above.

  • #3 Proposer for a XCM Channel Opening must provide the following Key Disclosure as part of the XCM Channel Opening Governance Template:

    • i. Is the Blockchain Code Open-Source (and include Github link)? If parts of the code are not open source: please provide information on why not

    • ii. Is Sudo-disabled on the Network? If Sudo is disabled, is the Network controlled by a select group of addresses (<50 addresses)?

    • iii. Have you completed full testing of this integration on the Moonbase Alpha TestNet?

    • iv. (For Moonbeam XCM/HRMP Proposals Only) Does your network have a Kusama deployment? If yes, please provide Network name and whether your Kusama deployment is integrated with Moonriver

    • v. Is your blockchain code audited? If yes, please provide: i. the name of Auditors, ii. dates of audit reports and, if available, links to audit reports.

Suggestion for the Moonbeam Dapp to increase transparency on XCM/ HRMP Channels supported in the Dapp.

The Moonbeam Foundation should consider including a link to the Key Disclosures (outlined above) made in the respective networks’ XCM/HRMP Channel Opening Governance proposals in the Moonbeam DApp. It would be helpful to have these disclosures available in proximity to any assets supported through that network integration.

Assuming this proposal moves forward and is approved by the community, then all future networks that want Moonbeam Dapp support would have these disclosures laid out the network’s XCM/HRMP Channel Opening Governance proposal. The only additional ask is for the Networks to make a good-faith effort to keep those Key Disclosures up to date so long as they are supported by the Moonbeam Dapp.

For Historical XCM/HRMP Integrations: the Moonbeam Foundation should consider requiring these Networks to provide the same Key Disclosures as outlined above and post in the Moonbeam Forum.

All Networks must make a good-faith effort to keep those Key Disclosures up to date so long as they are supported by the Moonbeam Dapp.

13 Likes
2

Hey, @liv_moonlife, in fact, an amazing proposal, because transparency is the key!
the only thing I would like to see is how the “Key Disclosure” will be displayed on Moonbeam DApp, as it seems to me it may cause some confusion in the UI.

It is interesting to note, and I would like to discuss this not as a turrizt, but as an ordinary user who is just starting to learn about XCM / HRMP and all available features in the dotsama ecosystem.

It seems to me that many ordinary community users think that HRMP channels are opened with parachains from the ecosystem, and this introduces some trust by default, and users do not see any risks when opening such channels, because we are in dotsama, and everything here is safe and secured by relay chain!

Therefore, I think it would be nice if you explained what you mean by “risks” that may be present when opening new HRMP channels, and why your proposal is important so that an ordinary community user can understand this a little more.

4 Likes
3

This seems really well thought out and makes sense to me. Having to dig a lot of things up is time consuming and provides varying levels of information. Putting the responsibility on the proposer to provide this information in a standard format will make everyone better at evaluating the proposals.

2 Likes
4

I agree with @liv_moonlife
Opening an XCM/HRMP channel is a standard proposal/referendum and I think it’s very important to make masks/templates for all proposals/referendums that are standard so their information can be reported in a specific and precise way. This will ensure that all details are included and can be evaluated from voters.

2 Likes
5

this is a great point @turrizt. Flagging to @PureStake-yann as well

1 Like
6

Hey Turritz, great question.

The relay chain ensures that the state changes that happen in each parachain are legit. This means that if Bob had 5 tokens and sent 2 to Alice, Alice now has 2 tokens, and Bob has 3.

Generally speaking, XCM is bounded by the same principles. The state changes they produce need to be valid, and Polkadot ensures they are valid!

So if Alberto sends 1 Apple from Parachain A to Parachain B, the relay chain will ensure the message is relayed to Parachain B, but does not enforce that Parachain B “mints” something that represents that one Apple. However, on Parachain A, Parachain’s B Account (Sovereign Account) holds 1 Apple.

Let’s say Parachain B turns rogue, and they create 5 wrapped Apples instead of just 1. The relay chain can’t verify the malicious action. The relay chain can’t say, “5 wrapped Apples in Parachain B is not equal to 1 Apple in Parachain A!” But, when Parachain B maliciously tries to withdraw its 5 apples, they only hold 1 Apple on Parachain A. So, the relay chain enforces that Parachain B only holds 1 Apple in his account on Parachain A.

In this example, the users that are “directly impacted” by this are the users of Parachain B. Nevertheless, if the attacker grabs the 1 Apple he withdrew from Parachain’s B account on Parachain A (without actually owning it), he could swap it for Oranges and get away with some precious Oranges without actually having funds, to begin with. Therefore, Parachain A is also impacted! The relay chain limits the scope of the attack because the state changes need to be valid, tho.

OK, to wrap it up (and sorry for the long post). I think the idea of @liv_moonlife 's proposal is to provide the token holders a bit more information and transparency on the channels they are voting on, as well as some guidelines and standards to get in the dApp, etc., which I find extremely helpful and should provide the community with much-needed information on the HRMP integrations. HRMP channels do open the door for such things to happen.

2 Likes
7

Thank you, Alberto, for the amazing answer and detailed explanation, long posts matter!

the only thing that confuses me, it seems that it costs nothing for an attacker to provide fake data if the main goal is to deceive. perhaps it would be nice if there were technically savvy people in the community who could also look at the code and so on - this would certainly be ideal.

it also seems that it would be great to open HRMP channels with parachains that have already been able to earn the trust of users, that is, they have been functioning with a workable product for some time, and this gives some confidence that such a project has no intentions to cheat.

it also seems to me that the project should strive to add new use cases so that the new XC-20 can benefit the ecosystem, that is, the token should interact with the ecosystem, that is, the project should think about providing liquidity for the main dexes, add some incentives so that it is not just a ghost token and so on

1 Like
8

The point to have the code Open-Source and to ask parachain teams to provide audits is so that the community can have some “peace-of-mind”. It is also expected that the community verify at a high-level the information shared by the parachain team, some ways to do this (this are just examples!):

  • If the code is open-source, click on the Github repo and check how active it is, how often is updated, how many issues are open/closed, how many PRs are open/closed
  • Check if the audit was perform by a reputable firm. Go to the firm’s website and ensure the actual report exists there
  • Check socials to measure activity
  • Check community engagement

Seems like a lot, but Governance proposals should not be taken lightly as it drives the future of the protocol!

Remember that also a Parachain project needs a lot of work to become a Parachain in Polkadot/Kusama, and the scope of the attack more directly impacts the Parachain community first, which is expected to research the project.

The way I see it is that is a bit like the Swiss Cheese Model. The information requested might not be enough to prevent an attack, but there are many layers that need to be trespassed for an attack to be successful.

1 Like
9

Absolutely 100% agree, good points. Thank you so much Alberto, really appreciate it!

2 Likes
10

Hi. I support @liv_moonlife’s idea of making information more accessible to members of the Moonriver and Moonbeam community. After all, the more open and accessible information, the greater the community’s trust in the project.
Each user may have different questions, but when all the information is available for study, answers can always be found.
I also believe that a standard template with mandatory key points is a very important factor that will help users to study all the details and make the right decision.

6 Likes
12

Hey everyone,
This proposal is up for vote :ballot_box::

4 Likes