search

ChainSafe / Multix

Use a Multisig to do anything, on Polkadot
https://multix.chainsafe.io/
Apache License 2.0
27 stars 20 forks source link

Polkadot Facade Feedback #583

Open kianenigma opened 3 weeks ago

kianenigma commented 3 weeks ago

We are working towards building better APIs to simplify the interacting with "Polkadot Network".

What do we mean here by Polkadot Network? Foremost Polkadot Relay Chain and System Chains (everything DOT related), and then other Parachains.

In a few months (and after gathering feedback via such issues), more details of this project will be shared. To give it a name for now, we are calling it "Polkadot Facade".

The aim of this issue is to learn about the instances where you had to interact with Polkadot Network (as defined above), and you found it difficult. This interaction can be in any form, but to help give you a mental model, I can categorize it as such:

  1. 🤓 read: You had/wish to read something from the chain (most likely a pallet's storage / runtime-api), and you found it difficult.
  2. ✍️ write: You had/wish to compose a transaction to do something, and you found it difficult.

A few notes:

  1. I used the "had/wish" intentionally: I would like to hear both about scenarios that you had to do something, and they were hard, and those that you couldn't even figure out how to do because it was too hard.
  2. You can focus both on single-network interactions, and multi-network (involving XCM) interactions. That being said, we will likely first consider single-network cases.
  3. When it comes to reading, don't limit yourself to what can be read from the state of a certain block, historical queries also count.

Please feel free to reach out to me on Matrix (@kianenigma:parity.io) if need be.

Tbaut commented 2 weeks ago

For Multix in particlar, here are the issues that I could think of:

  1. The existence and success of Multix is a proof that the multisig pallet was not conceived with users in mind. This can't and won't change any time soon, but these are the obvious issues:

    • multisigs can't be discovered from the chain based on an account
    • the multisig calls waiting for approval aren't stored on chain and require either a hack (like multix see wiki) or a DB, like what most of the other interfaces handling multisigs have

  2. One thing that could change and makes it so that Multix requires an indexer for is that pure proxies can't be discovered solely with on-chain data. Requiring and indexer here too. We know proxies, but we don't know whether a pure proxy was created. You have to look at the chain events.

  3. another issue that you know about, but that I can't avoid talking about: pure proxies and cross-chains don't go hand in hand. First of all, you can't replicate a pure proxy today https://github.com/polkadot-fellows/RFCs/pull/111. Second what Josep told me, if you are the controller of a pure proxy, you can't make an XCM message to let this pure proxy account do anything on another chain. This is a major pain point, the most obvious need for this is abstracting chains for users, and set an identity (on the ppl chain) for a pure proxy on the relay.

I'll answer in new comments here if anything else comes to mind