We recently posted a Unified Ledger app proposal which gained both remarkable support and significant pushback within our ecosystem sparking a hot debate on multiple platforms and channels. It was quite surprising to uncover a fair bit of opposition and allegations based not on constructive criticism but rather efforts to block our initiative altogether. We believe that a common Ledger app is in the best interest of the entire ecosystem as illustrated by the widespread support we gained from both parachains and users. We would like to reiterate our unwavering commitment to an open, civil, and transparent discussion by inviting Parity, Zondax, Ledger, and all parachains to voice their concerns and questions regarding the proposal.
In this post, we would like to cover our motivation, solution, security, and implementation, and finally address two main concerns we faced so far.
Motivation
There are three key reasons why we believe there should be a universal Ledger app for all parachains:
-
The Ledger team is overwhelmed with work and explicitly asks to curb the number of apps they need to support from the ecosystem, as well as limit the frequency of the app updates, making them no more than once per quarter.
-
Unique derivation path for each app leads to various problems such as the inability to participate in a crowdloan with a Ledger, UX complications related to derivation path selection, and the need to upgrade all applications every time a new parachain is added.
-
The Ledger app works as a full-scale decoder, where pallet numbers and their respective methods are hard-coded. This means some transactions become unavailable after the runtime upgrade and thus users lose access to their funds for extended periods of time while they wait for Ledger support to respond.
Proposed solution
The gist of our solution is to abandon call data decoding on the device (similar to EVM-compatible apps).
The main rationale for making a distinct Ledger app for each parachain is the need to decode the call data of every extrinsic.
There are three major differences between Substrate parachains and standard smart contract chains:
-
Large transactions that are difficult to validate, even on a large screen.
-
Frequent runtime upgrades.
-
Transactions that are difficult/impossible for the average user to understand, such as XCM or ORML (excellent developments but designed to be as general as possible for various projects to use).
Our approach solves all three of the above problems. For now, the solution works only for asset and balance-related pallets, but it supports all types of balances and effectively covers the majority of on-chain transactions in Polkadot. Also, we’re not just adding metadata for each parachain; we’re transforming the transaction into text readable by humans for each parachain.
Security of the proposed solution
One of the key concerns often voiced during discussion is the security of our approach. Most of our opponents refer to insecure blind signing despite it being an industry standard for EVM. Furthermore, as said above, the most common transactions (asset transfers) will be subject to clear sign and the scope of clear signed transactions will be expanding as new app developments kick in. Additionally, we’ve been in constant communication with the Ledger team to ensure our solution complies with their security standards.
Let’s summarize why we believe the proposed solution is actually secure enough by any reasonable standard :
-
As mentioned earlier, we modeled the application based on EVM, and our security complies with widespread EVM standards.
-
The application’s architecture allows to add the processing of new commonly used transaction types, such as governance or staking in the future.
-
While our solution might not be perfect out of the box,.we have a clear vision of how to make the app more secure and user-friendly (more on this later).
The motivation for this application was not born out of a desire to obtain a piece of the treasury but rather out of the necessity of having this application for our parachain and other parachains in our ecosystem. This is evident from the numerous comments and feedback we received while pursuing the common app goal.
It is very important to re-iterate that the exact implementation of the proposed app will work identically to the way Ledger apps work in Ethereum:
-
Most common transactions such as Balance (and other asset operations) will be supported in the clear sign mode. See this spreadsheet for the breakdown of the different asset modules we’re planning to support.
-
Blind sign mode is something that the user has to turn on manually on the device before he will have the ability to use it.
-
Display the hash of the call data both in the extension/mobile application and on the Ledger device.
Communication with the Ledger Team
-
Problem with multiple derivation paths: The proposed app will automatically select the needed derivation path between Polkadot and Kusama relay chains, depending on where the supported parachain is.
-
Users should not blindly sign by default: The app will work the same way as EVM-based apps: users will have to manually turn on the hash signing option on the device themselves.
-
Frequent app updates are time-consuming and not optimal, how can we avoid that? This is what we as an ecosystem need to sort out, from our end, we proposed to make updates no more frequent than once per quarter.
-
If we manage app updates once per quarter, can we guarantee a clear sign when the app is not updated? No, we can’t, so those parachains who have implemented some breaking changes won’t work in the clear sign mode but still will have a blind sign functionality available. Yet these updates are quite seldom in our experience and we will monitor the main modules/pallets for the updates.
-
It’s up to the ecosystem to decide on how to move forward with the app and what other common transactions to support for the clear sign mode: Indeed, this is the reason we’ve created a telegram group with multiple parachain representatives and have been vocal about our propositions during parachain round table calls and in discussions with Parity.
Addressing objections and concerns
We’ve received numerous polkassembly comments and posts related to the proposed solution and would like to address two major ones here.
- Security concern: Probably the most significant one we’ve received, which can be formulated like this:
Q: How do you verify that what you are signing is actually what the hot wallet shows you? This is impossible and therefore totally insecure.
A: The concerns associated with signing hashes are usually explained using the example of simple transactions, but let’s look at the example of an XCM transaction, which is the main feature of Polkadot parachains.
- The size of the transaction - it is almost impossible to validate it on the Ledger device, moreover the device itself frequently freezes when presented with a transaction of such size
- Arguments and methods that are incomprehensible to the user
- Recipient address in public key format => You need to use third-party applications for validation
- The transaction may appear in the encoded format of the recipient’s chain => you need to use third-party applications for validation
To check such a transaction user must use 3rd party instruments to validate it, raising all of the same security concerns as with the hash signing.
We see two possible approaches to increase security:
-
The first approach is to change the SignedPayload struct to create a human-readable string from extrinsic, so the users will sign a string, not a byte array. This requires major changes to be made in the substrate framework and this process can take a lot of time.
-
The second approach is to add a new SignedExtension, and double sign the transaction (byte array and human-readable text), it will add more data to extrinsic and will increase transaction validation times, yet it can be implemented without any modifications to the substrate framework. Any parachain can support the app by adding this SignedExtension. SignedExtension can support default trx. signing for backward compatibility.
We would love to hear community and expert thoughts on the above and Invite Parity, Parachains, and the Zondax team to further discussion. We’ve also reached out to Parity to organize a technical call on the issue.
- Zondax claims: Here is a quote:
Q: “We are shocked that the development plan seems to bluntly claim features and activities that already exist and have been available for a long time”
A: We want to build a universal Ledger app that will support multiple parachains. We ask you to carefully re-read our proposal to clearly understand the exact activities for which we’re requesting the funding. To be specific, funding is required to enable clear signing for all available balance pallets and other developments that require a lot of effort.
There are several issues with Zondax’s approach as we see it:
-
Zondax APPs currently support only 4 main chains: Polkadot, Kusama, Statemine, and Statemint.
-
In order to have Ledger support, Zondax requires each parachain to sign up for their services with no transparency about costs.
-
Zondax’s approach is not universal, doesn’t serve ecosystem interests, and doesn’t provide a universal parachain app in a timely manner. We crave to speed up things a bit for the ultimate ecosystem and user benefit, yet the discussion around our solution has been going on for over 6 months now with no meaningful progress made so far. We believe this is not the way things should ultimately work in the ecosystem.
-
There are concerns regarding the cost of the app and its support to the Polkadot treasury. Spending $700k of treasury funds just for maintaining the support of Zondax’s solution for 4 main chains and no parachain support without meaningful new development work seems unreasonably expensive to us. Additionally, the entire community would benefit if there was more disclosure about the proposed audit costs and the companies that will be doing the audit. There are known audit company names on the Ledger website and we as an ecosystem should reach out to them publicly.
We have never spoken out publicly against Zondax’s solution, and it is very strange for us to see so much negativity coming toward ours recently. We believe that Zondax’s solution for Polkadot and Kusama should remain in place at least until a better one is devised.
We operate on the premise that grants and open source are in place so that if any team can create a better solution, they can compete for funding.
Finally, we have always stated and continue to say that our solution is just the first step towards the right Ledger application, and as we as a community continue to figure out how to improve it, we fully expect and welcome other community members to come forward with initiatives similar to ours.
