Polkadot Summit, Copenhage 2023
Adapting Metadata for Hardware Wallets
Session Lead: Bastian Köcher (@bkchr )
-
Estimated # of attendees: 35
-
Attendees/key participants:
- Gavin Wood
- Zondax Team
Introduction
Given the widespread concern about trusting random internet UIs or wallets with one’s private keys, many users opt to use hardware wallets. Renowned for their ability to sign given data without exposing the key, these wallets have become an essential tool for securing digital transactions.
There are numerous hardware wallets available, but within the Polkadot ecosystem, some of the most recognized include Polkadot Vault, Ledger, and Kampela. The latter is still in its early phase, but its development has been financially supported by the Polkadot treasury.
Existing Challenges
One key aspect of these hardware wallets is their ability to interpret data sent by the online UI or wallet. Within the Polkadot ecosystem, two primary approaches to this interpretation have emerged. The first approach uses a fixed parser for the transaction format of Polkadot, which needs to be updated to accommodate new versions of the Polkadot runtime. The second method employs a transaction parser that leverages metadata for decoding. This technique, however, necessitates having the full metadata (over 1 MiB) on the device and a secure way to update it. Currently, both approaches hinge on central entities either to sign the metadata or the ‘fixed’ parser.
Supporting parachains also presents challenges. Inclusion in the metadata portal or a customized Ledger app is necessary, each presenting its own set of hurdles. Running and signing the metadata for the portal requires dedicated personnel, while obtaining approval for a custom Ledger app from the official app store is often tricky. Furthermore, the parser would need adjustments for each parachain, given that the FRAME runtimes do not dictate a specific transaction format.
Hardware wallets can be implemented in two ways. One can either utilize ‘fixed’ parsers or metadata-based parsers (blind signing is another option, but it’s best left out of this discussion due to its associated risks). Polkadot supports forkless runtime upgrades for itself and all its parachains, leading to frequent changes. Thus, using a ‘fixed’ parser becomes nearly unfeasible due to the constant updates it would require. Consequently, the metadata-based parser becomes the default option, although it presents two major problems. The metadata size is often too large to fit on all hardware wallets, and trusting the metadata currently requires reliance on a central identity to sign it.
The Solution
Introducing merkelized metadata offers a solution to these issues. By breaking the metadata into individual pieces and placing them into an accumulator (e.g. a merkle tree) and use the digest of this accumulator (e.g. root hash of a merkle tree) as secure identifier for a particular metadata instance, can serve as a secure identifier for a particular metadata instance. This strategy resolves the metadata size problem, as individual chunks are needed to decode the transactions, not the full metadata.
A hardware wallet wishing to sign a transaction would receive proofs for these chunks from the online wallet and use the digest of the accumulator to ensure the proofs’ correctness. It can also receive the digest of the accumulator from the online wallet. To protect against the online wallet providing incorrect digests and proofs, the hardware wallet would include the digest in the transaction’s signed payload. The chain, being aware of the digest, would ensure its correctness on-chain when checking the transaction signature. If the hardware wallet used an incorrect digest, the transaction would be rejected before even entering the transaction pool, preventing the user from signing an incorrect transaction.
While this solution addresses the primary issues, it requires collaboration with teams like Zondax (for the Ledger app) and the Kampela team to create a working implementation. Several crucial questions remain for the implementation, such as what type of accumulator to use and how to chunk the data most efficiently. Achieving the smallest possible proofs when decoding a transaction is the main objective here.
This will require rigorous research and careful tweaking. Given Kampela’s sufficient memory/storage to cache these proofs, most of the required optimization will be on the Ledger app side, for instance, streaming the proofs and decoding the transaction on the fly, considering the Ledger only has around 4KiB of memory. However, these hurdles are not insurmountable and shouldn’t deter the implementation.
Conclusion
The end goal is to establish a specification that describes how to chunk the metadata and what kind of accumulator to use, thus providing a secure and efficient solution for digital transactions within the Polkadot ecosystem.