You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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)
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.
No description provided.
The text was updated successfully, but these errors were encountered: