Fighting the Good Fight: Wading Through Intrigue and Politics to Improve the Polkadot Ecosystem

Ever since the Equilibrium team has come up with the Unified Ledger App proposition for the Ecosystem, the proposal itself has received a lot of attention and positive feedback both from within and from outside of the ecosystem. It continues gaining traction after we came up with the actual referenda which you can find and support here.

The aim of this post is to re-iterate the main ideas and advantages behind the proposal, pinpoint why it is of great benefit to the parachain projects, and encourage an open discussion about the future prospects of the app that should ultimately serve all of the ecosystem at acceptable costs.

Motivation

There should be one universal Ledger app that will work with all parachains. We see the following problems of creating separate Ledger apps for different parachains:

1. 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.
2. Unique derivation path for each app (a unique account for each relay chain and parachain). Which leads to a number of problems:

• The inability to participate in a crowdloan with a Ledger with guaranteed access to its rewards on a parachain without exporting mnemonics to less secure environments (for example, an extension, a mobile application). Most likely, a new project that participates in the crowdloan will not have its app built for a long time, because of which users will have to wait and get a negative experience from the entire ecosystem.
• Most applications do not have derivation path selection functionality. So users, who transfer tokens from Kusama to Kusama-based parachain, for example, have their account changed and lose access to their tokens. The entire flow is not directly obvious to the average user (need to export mnemonic with correct derivation path).
• Even if developers of parachain/relay chain applications will include functionality for selecting derivation paths in their Ledger applications, this will cause all applications to need to upgrade to support new parachains when they emerge. The alternative is for users to set the derivation path manually, which is complicated for the average user and doesn’t simplify the already cumbersome Polkadot user experience.

3. The Ledger app works as a full-scale decoder, where pallet numbers and their respective methods are hard-coded. This leads to the following problems:

• Some transactions become unavailable after the runtime upgrade if there are changes to pallet indices and/or changes to extrinsic types.
• These problems in conjunction with slow Ledger support response lead to the fact that users lose access to their assets for a prolonged period of time

Proposed solution

Abandon call data decoding on the device (similar to EVM-compatible apps).

The main reason for the necessity to make a distinct Ledger app for each parachain is the need to decode the call data of every extrinsic.

Ethereum Ledger app, for example, never decodes transactions, one exception being an ERC-20 transfer. That is, the user checks data in the metamask wallet, for example, and approves it on a Ledger.

There are several differences with substrate parachains compared to standard smart contract chains, and it’s not just frequent upgrades:

1. Large transactions that are difficult to validate, even on a large screen.
2. Frequent runtime upgrades.
3. 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).

However, there is a major advantage to the substrate technology — we can change and adapt it to make it more user-friendly. We have a long-term vision of achieving this, but in the meantime, we want to help our clients and clients of other parachains access their assets as quickly as possible.

Our solution solves all three of the above problems. For now, this solution works only for balance 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 human-readable text for each parachain (sometimes different approaches are needed for the same pallet).

Security of the proposed solution

We’ve seen quite a lot of debates on the security of our approach. Most of our opponents refer to insecure blind signing. But it has become an industry standard for EVM (maybe unfortunately, but it’s the fact). 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. Also, we’ve been in constant communication with the Ledger team to ensure our solution complies with their security standards.

Let’s summarize why the proposed solution actually secure:

1. As mentioned earlier, we built the application based on EVM, and our security complies with widely spread EVM standards.
2. The application’s architecture will allow the future addition of processing new commonly used transaction types, such as governance or staking.
3. The hash verification process is not ultimately secure in the same way the verification of large and complex transactions is (more on that below in the concerns section). We have a clear vision of how to modify our approach in striving to make the app more secure and user-friendly (details on this are below as well)

Lastly, the idea for this application was not born out of a desire to obtain a piece of the treasury but 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.

Exact Implementation

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:

1. 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.
2. 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.
3. Display the hash of the call data both in the extension/mobile application and on the Ledger device.

Communication with the Ledger Team

Having said that, we’ve been in constant contact with the Ledger team on the subject, and here’s the recap of the latest call and the questions that have been discussed:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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 love to address them all here in one place. We invite the Zondax team, Parity, and Ledger representatives to comment.

1. 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 the same security concerns as with the hash signing. Hard to imagine any person in his right mind doing this.

We already talked about possible future approaches to the issue of clear/blind signing we would like to discuss more with the community and Parity:

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.

2. Zondax claims: The 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 them:

1. Zondax APPs currently support only 4 main chains: Polkadot, Kusama, Statemine, and Statemint.
2. In order to have Ledger support, Zondax requires each parachain to sign up for their services with no transparency about costs.
3. Zondax’s approach is not universal, doesn’t serve ecosystem interests, and doesn’t provide a universal parachain app in a timely manner. The discussion around our solution has been going on for 6 months plus and we still haven’t moved in the practical direction.
4. There are concerns regarding the cost of the app and its support for the Polkadot treasury. And we believe Zondax should be more transparent in their claims of the audit and support costs.
5. We have never spoken out against Zondax’s solution, and it is very strange for us to see so much negativity coming toward us in recent days. We believe that Zondax’s solution for Polkadot and Kusama should remain in place at least until a better solution is devised.

On the other hand, grants and open source are operating in such a way that if any team can create a better solution, they can compete for funding.

Spending $700k of treasury funds just for support of Zondax’s solution for 4 parachains 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.

Finally, we have always stated and continue to say that our solution is the first step toward the right ledger application, and if we as a community can ultimately figure out how to make it better, we will gladly support any such initiative.

Express your opinion on our initiative and support us here!