thank you for such a thorough write up.
I will attempt to keep my response concise:
- I agree that a ledger app which supports all Substrate based chains is valuable, even if those transactions are “blind” to the user. We have seen that this does unlock tons of activity throughout other ecosystems which have taken a similar approach. Ethereum is a great example.
- We should be focusing less on supporting clear signing of all messages (since this has shown to be tough), and instead focus on the set of messages which are most frequently used by cold wallets, which I believe is the main scenario for most ledger users.
- Balance transfer and assigning a proxy seem like the primary focuses.
- Beyond that, with the use of proxies, more day to day activities can be completed with things like Polkadot Vault, various browser extensions, or other hot wallet choices. These have much easier methods for updating metadata and performing clear signing.
- Historical context is that the current byte encoding of transactions is to minimize the data footprint on Substrate based chains. Each transaction requires only 2 bytes to target a specific call (and then any extra data needed for the call parameters).
- These two bytes are usually: (1) pallet byte index, (2) call index within the pallet.
- This is already inherently limiting, for example, there is only at most 256x256 possible calls, assuming all pallet calls are optimally packed. This is plenty, but I am certain that at some point someone will ask for more than 256 calls in one pallet, or try to add more than 256 pallets to a runtime. When that day comes, I don’t know what solution we will come up with.
- Passing raw strings to and from the runtime would be exactly opposite of the goal to reduce transaction byte size. Your suggestions about hacking the Signed Extensions would seem to work, but I do not think this is something we should encourage in the ecosystem.
- I am in 100% agreement with all 4 problem points that you call out with Zondax’s solution.
I recently posted on twitter:
We should only fund teams who will implement the Ledger app using XCM.
In fact, I mentioned the same ideas in a previous thread about the Ledger app.
I think anyone who will take on building the Ledger app for the Polkadot ecosystem should read, and provide feedback / comments / criticisms / reality checks to this thread: XCM as a Standard for Reading And Interacting with Parachains
It seems that XCM is actually PERFECT for a universal ledger app for the entire Polkadot ecosystem and beyond. XCM describes a language to convey intention. In the context of token transfers, it can perfectly express transfering any kind of token to any user, no matter if their balance is represented on a parachain, contract, or any consensus system in between the two.
It should be that a Ledger app can present to me an XCM message, which I sign, and that will always do the same operation no matter the underlying runtime… because that is exactly what XCM was designed to do:
Using the Runtime Metadata was an “old way” of thinking because it was the only option at the time of Polkadot / Kusama launch. But now that XCM is getting more and more mature, it should be the place we go to in order to keep our app ecosystem working seamlessly.
XCM has historically updated only 1 time per year, and will likely not update more than every 6 months.
So given this information, why should we financially support any Ledger app which does not choose XCM as the base layer?