## Context of the proposal 
​
We promised a few weeks ago to release our perspective on how to solve this problem effectively without compromising security. 
​

A secure hardware wallet (Ledger) application that can automatically handle all parachains and relay chains without being affected by runtime upgrades. 


The objective is to provide a single application for the complete ecosystem with the flexibility to allow new functionality without compromising security.
​

The problem is not new. Maybe half-way solutions have been proposed in the past. In some cases, we have even implemented them for other ecosystems. We are aware of them and we actually internally rejected them because we did not feel comfortable with their risk-value proposition. The right solution required changes in the nodes. We strongly think that Polkadot (substrate!) deserves the best solution and not to settle for “how XYZ does it”.
​
For this reason:

* A few members of Zondax specifically travelled to Copenhague on Mon/Tue (before Decoded) with the **sole purpose** of discussing this topic with Gavin, Basti and other technical stakeholders.
* We discussed and agreed on a feasible solution and path forward with Parity.
* We have been in touch with the Kampela team discussing some related work and agreeing on a collaborative approach.
* We feel confident that this solution **will be approved** by Ledger for **public release** without reservations apart from the standard external audits they usually require us to go through.
​
​
## Problem statement 
​
We want a secure by design solution that can clear sign and support most relay chains and parachains without frequent updates.
​
A solution should take into account that:
​
* Until now, metadata is not verifiable and must be considered **not trusted.**
* Metadata changes breaking Ledger apps and other air gapped solutions.
* Substrate is design to evolve over time. This should not be constrained by artificial restrictions.
* The ecosystem requires a **secure** long term generic solution.
* A strong and long term solution requires the collaboration of multiple stakeholders, including Parity.
​
​
In addition to this:
​
* It is important to minimize application updates to reduce audit costs. 
* Ledger Nano S has only 4kB of RAM (Typically <3kB are available to apps). Implementation is not trivial but Zondax has a strong reputation and team ( several years building a large amount of apps).
* There are aspects such as derivation paths that may require special treatment.
* Metadata may need to be extended with some minor additional fields.
​
## Proposed solution
​
* A more succinct version of the metadata is specified in collaboration with other teams.  Existing Runtime metadata already describes pallets, extrinsics and other typical elements but some elements that are not relevant could be removed.
* A Merkle tree is used to process this succinct metadata generating a root hash but at the same time allows accessing individual elements (leaves) in a verifiable fashion.
* A new adapted version of Zondax’s existing Ledger apps can parse blobs informed by verifiable metadata leaves (VML). Depending on the device capabilities a several VML are ingested as a batch or they are on-demand transferred to the device.
* Dynamic parsing is not trivial in embedded devices without dynamic memory. We have an internal prototype and we feel confident about it. Moreover, we have in the past already done something similar for another large project.
* A new extended signature mode is used. When signing, the digest is calculated, however, a kind of domain separation is used where the root of the Merkle tree is prefixed. Moreover, this root does not need to be included in the tx, as it is common knowledge. During verification, the corresponding runtime can apply a similar mechanism.
* Other aspects such as chain name or params are also planned to be embedded as VML and handled automatically. This completely reduces the need of online registry and centralized repositories where entities need to submit parachain information and parameters without adequate identity verification.
​
​
#### How does this proposal change the network? How do the milestones of the project achieve the ultimate goal?
​
* A new merkleized metadata structure (MeMe) will be defined in collaboration with other teams. This will be available in Substrate and incorporated in the relay chains.
* Hardware wallets (Ledger and others) will be able to automatically accept and clear sign transaction blobs regardless of the chain or runtime version.
* Frequent updates will no longer be necessary due to runtime upgrades.
* Clear signing will be available for all relay and parachains as long as they update their substrate version to one that can provide VML.
* New parachains will not require the development or submission of new Ledger apps.
​
​
#### Who does this solution help?
​
This solution would enable teams  to keep innovating and developing new features. This would benefit:
​
* Relay chain
* Parachains
* Current and future users
* Overall network security
​
​
#### Have you seen similar solutions before? 
​
This is a progression on the current solution Zondax provides. We have been involved in related work in other ecosystems but we perceive this approach state-of-the-art in comparison to what others have been doing.
​
#### What are the milestones, timelines, and budgets?
​
We’re finalising the collection of input from different stakeholders and we will be completing these details in the following days. 
​
​
## The team
​
Zondax is a growing and distributed team with experience and projects for more than 50 blockchains. Zondax has been contributing to the Substrate ecosystem since 2018-2019. The team has received and completed a large number of W3F grants and currently maintains most Ledger apps for the ecosystem. Apart from the substrate ecosystem, Zondax participates and contributes to other large ecosystems such as Cosmos, Avalanche, Algorand, Filecoin, ICP, etc. Our team includes experts in most blockchain aspects, cryptography and programming languages. 
​

**Legal structure**

```
Zondax AG
Dammstrasse 16
Zug 6300
Switzerland
UID CHE-491.796.576
```

Most of our contributions to the blockchain ecosystem can be found in our GitHub organization: https://github.com/zondax
​

Over the last few years, Zondax has been involved in a large number of projects for most of the key players in the blockchain industry. For this reason, we are confident that we can provide a long term commitment. 
​
​
## Conclusion

This discussion and overall approach is the result of a collaboration between several stakeholders. The complete solution requires the collaboration of several parties and includes a minor modification in Subtrate.
​

Changes in Ledger apps to support this new feature are not trivial, even for our team. However, we feel confident that we can split and parallelize work with other teams (Kampela, Parity) in such a way that the overall solution is only feasible but also achievable in a few months of close collaborative work.
​

The outcome not only will solve the problem in a secure way but also will position the complete ecosystem in the state-of-art with respect to providing clear signed data even when supporting frequent on-chain upgrades. 
​

# Treasury Proposal: Zondax/Ledger Substrate App - A generic+secure solution
​
## Context of the proposal 
​
We promised a few weeks ago to release our perspective on how to solve this problem effectively without compromising security. 
​
A secure hardware wallet (Ledger) application that can automatically handle all parachains and relay chains without being affected by runtime upgrades. 

The objective is to provide a single application for the complete ecosystem with the flexibility to allow new functionality without compromising security.
​
The problem is not new. Maybe half-way solutions have been proposed in the past. In some cases, we have even implemented them for other ecosystems. We are aware of them and we actually internally rejected them because we did not feel comfortable with their risk-value proposition. The right solution required changes in the nodes. We strongly think that Polkadot (substrate!) deserves the best solution and not to settle for “how XYZ does it”.
​
For this reason:
* A few members of Zondax specifically travelled to Copenhague on Mon/Tue (before Decoded) with the **sole purpose** of discussing this topic with Gavin, Basti and other technical stakeholders.
* We discussed and agreed on a feasible solution and path forward with Parity.
* We have been in touch with the Kampela team discussing some related work and agreeing on a collaborative approach.
* We feel confident that this solution **will be approved** by Ledger for **public release** without reservations apart from the standard external audits they usually require us to go through.
​
​
## Problem statement 
​
We want a secure by design solution that can clear sign and support most relay chains and parachains without frequent updates.
​
A solution should take into account that:
​
* Until now, metadata is not verifiable and must be considered **not trusted.**
* Metadata changes breaking Ledger apps and other air gapped solutions.
* Substrate is design to evolve over time. This should not be constrained by artificial restrictions.
* The ecosystem requires a **secure** long term generic solution.
* A strong and long term solution requires the collaboration of multiple stakeholders, including Parity.
​
​
In addition to this:
​
* It is important to minimize application updates to reduce audit costs. 
* Ledger Nano S has only 4kB of RAM (Typically <3kB are available to apps). Implementation is not trivial but Zondax has a strong reputation and team ( several years building a large amount of apps).
* There are aspects such as derivation paths that may require special treatment.
* Metadata may need to be extended with some minor additional fields.
​
## Proposed solution
​
* A more succinct version of the metadata is specified in collaboration with other teams.  Existing Runtime metadata already describes pallets, extrinsics and other typical elements but some elements that are not relevant could be removed.
* A Merkle tree is used to process this succinct metadata generating a root hash but at the same time allows accessing individual elements (leaves) in a verifiable fashion.
* A new adapted version of Zondax’s existing Ledger apps can parse blobs informed by verifiable metadata leaves (VML). Depending on the device capabilities a several VML are ingested as a batch or they are on-demand transferred to the device.
* Dynamic parsing is not trivial in embedded devices without dynamic memory. We have an internal prototype and we feel confident about it. Moreover, we have in the past already done something similar for another large project.
* A new extended signature mode is used. When signing, the digest is calculated, however, a kind of domain separation is used where the root of the Merkle tree is prefixed. Moreover, this root does not need to be included in the tx, as it is common knowledge. During verification, the corresponding runtime can apply a similar mechanism.
* Other aspects such as chain name or params are also planned to be embedded as VML and handled automatically. This completely reduces the need of online registry and centralized repositories where entities need to submit parachain information and parameters without adequate identity verification.
​
​
#### How does this proposal change the network? How do the milestones of the project achieve the ultimate goal?
​
* A new merkleized metadata structure (MeMe) will be defined in collaboration with other teams. This will be available in Substrate and incorporated in the relay chains.
* Hardware wallets (Ledger and others) will be able to automatically accept and clear sign transaction blobs regardless of the chain or runtime version.
* Frequent updates will no longer be necessary due to runtime upgrades.
* Clear signing will be available for all relay and parachains as long as they update their substrate version to one that can provide VML.
* New parachains will not require the development or submission of new Ledger apps.
​
​
#### Who does this solution help?
​
This solution would enable teams  to keep innovating and developing new features. This would benefit:
​
* Relay chain
* Parachains
* Current and future users
* Overall network security
​
​
#### Have you seen similar solutions before? 
​
This is a progression on the current solution Zondax provides. We have been involved in related work in other ecosystems but we perceive this approach state-of-the-art in comparison to what others have been doing.
​
#### What are the milestones, timelines, and budgets?
​
We’re finalising the collection of input from different stakeholders and we will be completing these details in the following days. 
​
​
## The team
​
Zondax is a growing and distributed team with experience and projects for more than 50 blockchains. Zondax has been contributing to the Substrate ecosystem since 2018-2019. The team has received and completed a large number of W3F grants and currently maintains most Ledger apps for the ecosystem. Apart from the substrate ecosystem, Zondax participates and contributes to other large ecosystems such as Cosmos, Avalanche, Algorand, Filecoin, ICP, etc. Our team includes experts in most blockchain aspects, cryptography and programming languages. 
​
**Legal structure**
​
Zondax AG
Dammstrasse 16
Zug 6300
Switzerland
UID CHE-491.796.576
​
Most of our contributions to the blockchain ecosystem can be found in our GitHub organization: https://github.com/zondax
​
Over the last few years, Zondax has been involved in a large number of projects for most of the key players in the blockchain industry. For this reason, we are confident that we can provide a long term commitment. 
​
​
## Conclusion
This discussion and overall approach is the result of a collaboration between several stakeholders. The complete solution requires the collaboration of several parties and includes a minor modification in Subtrate.
​
Changes in Ledger apps to support this new feature are not trivial, even for our team. However, we feel confident that we can split and parallelize work with other teams (Kampela, Parity) in such a way that the overall solution is only feasible but also achievable in a few months of close collaborative work.
​
The outcome not only will solve the problem in a secure way but also will position the complete ecosystem in the state-of-art with respect to providing clear signed data even when supporting frequent on-chain upgrades. 
​

Zondax/Ledger Substrate App - A generic+secure solution

- The proposal is about creating a secure hardware wallet application for Polkadot.
- The problem is that the current solutions are not secure enough and don't allow for frequent updates.
- The proposed solution involves creating a more concise version of the metadata and using a Merkle tree to process it.
- This solution will allow hardware wallets to accept and sign transactions from any chain or runtime version.
- The solution will benefit the relay chain, parachains, users, and overall network security.

#1832 Zondax/Ledger Substrate App - A generic+secure solution

No Active Proposals