Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When submitting call data in the last approve extrinsic, parse call data and display the transaction parameters #186

Open
yakio opened this issue May 16, 2022 · 2 comments

Comments

@yakio
Copy link
Member

yakio commented May 16, 2022

No description provided.

@hackfisher
Copy link

hackfisher commented May 16, 2022

One issue of current multisig pallet is that, it supports initiating a multisig transaction using only a call hash, for later operators to approve and execute this multisig call, the detail call data need to be shared in off-chain way peer to peer or using a shared/verifiable call hash -> call database for caching.

This protocol layer of substrate multisig has some shortcomings, mainly the off-chain communication and synchronization of call hash and call data.

From the aspect of ecosystem to better apply this pallet, if the pallet's protocol is not going to change, another way would be Subscan multisig to open/free the api for storing/verify the calldata for specific call hash, in this way, other apps like polkadot.js.org can use Subscan api for offchain storing. (This api could be free or even using decentralized storage like IPFS)

To prevent DDOS, the Subscan can verify the request by pre-indexed call hash. This is some infrastructure for public good, so should be sponsored by the ecosystem teasury.

@yakio
Copy link
Member Author

yakio commented May 16, 2022

From the aspect of ecosystem to better apply this pallet, if the pallet's protocol is not going to change, another way would be Subscan multisig to open/free the api for storing/verify the calldata for specific call hash, in this way, other apps like polkadot.js.org can use Subscan api for offchain storing. (This api could be free or even using decentralized storage like IPFS)

Hey @hackfisher ,

Yep, we can do this of course, but this solution only solves part of the problem, and the best solution is indeed to optimize the protocol layer as you said. It is valid in the case of multisig transactions initiated by as_multi and submitted call data to the chain. The applications can require and verify call data by integrating this api, which will facilitate the user's transaction flow.

Since the call data cannot be parsed through the call hash, for the transactions that do not submit the call data to the chain, such as https://pangolin.subscan.io/extrinsic/2380030-1 . We still can' t get any transaction parameters until the user manually enters call data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants