For any additional inquiries team can be contacted via [email protected] email or @alexander_slesarev:matrix.zymologia.fi on Matrix
Proponent: 12bFooBAK4hHUfiri7v2Eiz96v7TDoiLWdNKCFYmhWzGG1Tq, Alzymologist Oy, [email protected]
Date: 2023-07-06
Requested DOT: 110.693,7 DOT equivalent to €537.744 at date of the payment.
This project's goal is to create a new metadata protocol friendly to offline devices and implement it in the most critical tools available: Ledger and Kampela, as well as create tools to port it to other wallets and key management devices, including Polkadot Vault. This will involve changing the runtime code to support a new method of transaction signing that would include a proof of metadata used for transaction rendering to the user.
This was discussed across the ecosystem, mentioned in this github issue and Polkadot forum, posted in two discussion threads on Polkassembly (one, two), and gained traction reaching up to key representatives of the Polkadot Ecosystem.
Although this proposal is formally presented by Alzymologist Oy, the Laboratory behind Kampela, it will be a joint development between Alzymologist Oy and Zondax. More details can be found below.
While all blockchain systems support (at least in some sense) offline signing used in air-gapped wallets and lightweight embedded devices, only few allow simultaneously complex upgradeable logic and full message decoding on the cold off-line signer side; Substrate is one of these heartening few, and therefore - we should build on this feature to greatly improve transaction security, and thus in general, network resilience.
As a starting point, it is important to recognise that prudence and due care are naturally required. As we build further reliance on this feature we should be very careful to make sure it works correctly every time so as not to create false sense of security.
In order to enable decoding that is small and optimized for chain storage transactions, a metadata entity is used, which is not at all small in itself (on the order of half-MB for most networks). This is a dynamic data chunk which completely describes chain interfaces and properties that could be made into a portable scale-encoded string for any given network version and passed along into an off-chain device to familiarize it with latest network updates. Of course, compromising this metadata anywhere in the path could result in differences between what user sees and signs, thus it is essential that we protect it.
Therefore, we have 2 problems to be solved:
As of now, there is no working solution for (1), as the whole metadata has to be passed to the device. On top of this, the solution for (2) heavily relies on a trusted party managing keys and ensuring metadata is indeed authentic: creating poorly decentralized points of potential failure.
We propose a secure hardware wallet (Ledger) application that can automatically handle all parachains and relay chains without being affected by runtime upgrades. This has been requested by the community for a long time. The objective is to provide a single application for the entire ecosystem, with the flexibility to allow new functionality without compromising security.
This is not a new problem and there have been strong attempts to solve it, however, it is apparent to us that in order to provide a secure solution that changes to the nodes themselves are required. This would provide the ecosystem with a resilient and secure, on-chain validated method which we believe the Polkadot ecosystem deserves.
We want a secure by design solution that can clear sign and support most relay chains and parachains without the need of frequent updates.
A solution should take into account that:
In addition to this:
This is the simplest part - add some hash of metadata to signing inputs and sign. The size of data stored on chain does not change - except for a flag that would indicate whether this new feature is used or is data signed as before (so that cold signers could force "with metadata always" rule if they can or not force it if they cannot). This was discussed in github issues, now we suggest that the whole wallet/signer community comments on this part.
This is where things get tricky - and what would be addressed mostly within scope of this proposal. For small embedded devices like Kampela (64kBit internal RAM) and Ledger (4 kB RAM), shortening the metadata is essential. Only small part of metadata is really needed for decoding. The proposal by the Substrate team was to represent metadata hashes as Merkle tree and use it to securely and scalably generate the metadata validity proof on cold device.
For this, metadata should be abbreviated in some deterministic manner, similar to what native retain() operation from scale-info does, but more strictly. This procedure should have following properties:
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.
For this to succeed, a concerted effort from several teams is necessitated. Thus, this proposal is formulated and submitted jointly by several collaborativly aligned ecosystem teams and is closely coordinated in conjunction with the Substrate core development team.
There are also potential alternatives to Merkle tree indexing of metadata (for example, bilinear accumulators) that offer certain advantages, like slower growth at large runtime size increases, which might be expected. We should analyze these approaches and try to determine their feasibility, and if they are indeed better choice, replace all Merkle tree propositions of this project with corresponding more optimal tools.
We have carried out some minimal analysis in advance of publishing this proposal in an initial effort to reliably shorten metadata using basic tools. The first attempt resulted in reduction from about 200kB to about 8kB with some outdated snapshot of metadata - modern result should look even more impressive as while metadata grew significantly, the individual call-related data substructures sizes changed little.
This demonstration is, however, far from refined solution. Decomposing certain calls would still result in enormous data structures (namely, popular batch_call instruction would require an enum with all other calls and their parameters included). Furthermore, even 8kB significantly too large for typical secure element RAM limitations. Thus, serious additional research is required to formulate the final standard.
With regards to the implementation of the Ledger app, the proposed solution is a progression on the current solution Zondax provides. Zondax has been involved in related works in other ecosystems but this approach is state-of-the-art in comparison to what others have been doing.
Once defined and implemented in Substrate core, this feature would be available for all Substrate-based chains, across whole ecosystem. Any wallet or key management device would be able to implement it with use of documentation and libraries delivered within the scope of this project. Offline device security and useability would improve significantly, which would also increase their use in the community. All of this would culminate in a materially enhanced ecosystem resilience and remove severe UX issues that inhibit Polkadot ecosystem adoption.
As shown above, there is significant amount of attention from various ecosystem players to this project; we are closely working with community and relevant teams to make this happen for some time already.
Deliveries of this project are a blocker for proper fulfillment of Milestone 5 for Kampela project, where transaction protocol specification should be defined. Sending whole metadata over NFC would take noticeable amount of time thus making UX uncomfortable enough to severely reduce adoption of device. If this project gains community support and passes, only a small delay in Kampela development would be present as the NFC transfer protocol specification would follow soon after this project's standard is published.
This solution would enable teams to keep innovating and developing new features. This would benefit:
After each milestone, a brief summary report of progress will be submitted for the community to review.
Milestone 1 - Requirements specifications and latest metadata review (2 weeks)
Milestone 2 - Offline metadata prototype (6 weeks)
Milestone 3 - Offline metadata specifications (8 weeks)
substrate-parser reference implementationMilestone 4 - Offline devices implementation (8 weeks)
| Role | Milestone 1 | Milestone 2 | Milestone 3 | Milestone 4 |
| Alzymologist Oy (Finland) | ||||
| Rust developer | €9.400 | €28.200 | €37.600 | €37.600 |
| Embedded Rust developer | €9.400 | €28.200 | €37.600 | €37.600 |
| Project/communication manager | €5.100 | €15.300 | €20.400 | €20.400 |
| Zondax AG | 100h | 400h | 500h | 600h |
| Technical Lead | €5.100 | €15.300 | €20.400 | €20.400 |
| Embedded C developer | €5.760 | €23.040 | €28.800 | €34.560 |
| Project/communication manager | €2.880 | €11.520 | €14.400 | €17.280 |
| External audit | €10.000 | |||
| Total | €38.300 | €129.300 | €167.600 | €192.000 |
Note: Alzymologist Oy costs represent 54,5% of the offer Zondax costs represent 45,5% of the offer
To forsee potential price volatility, this proposal includes a 2% aditional DOT request.
Total cost of development: €527.200. With the aditional 2% for volatility this is €537.744, which translates to 110.693,7 DOT using Subscan EMA7 price.
The total cost of development would be requested as single deposit.
The funds would be deposited to Alzymologist Oy account 12bFooBAK4hHUfiri7v2Eiz96v7TDoiLWdNKCFYmhWzGG1Tq. Upon commencement of the call, Alzymologist Oy takes obligation to subcontract Zondax AG for the 45,5% of the total amount of DOTs paid by the treasury to cover their costs (this statement effectively legally constitutes unilateral written contract in our magnificent blockchain-friendly Finnish justidiction). We have tried to showcase a multisignature setup, but are doing this Finland-centered operation instead due to non-crypto world regulations being in the way.
There is a possibility that the changes proposed within this project are not included in Substrate codebase due to technical or other limitations. If this happens, the whole initiative fails.
To mitigate this, we have ensured that Substrate core developers are interested in this improvement and, furthermore, are ready to review it and include it in forthcoming Substrate updates. See above communications for details of these negotiations.
Review Process: Ledger’s review queue is sometimes unpredictable and depends on Ledger's workload and other factors that are out of Zondax control. We have experience in their process and have a streamlined workflow to simplify this. However, the effective time may vary depending on Ledger's resource availability, app/blockchain complexity, etc. The review process does not imply Ledger Live integration and is typically limited to the publication of the app in the Ledger Live Store allowing final users to install directly from Ledger.
To mitigate these risks, an external audit, will be coordinated and any relevant fixes will be applied. The external auditor will be selected from a list provided by Ledger SAS. Ledger SAS claims and it is public knowledge that when provided with a satisfactory auditor report from an auditor in that list, apps will be published in a much shorter period of time.
There is a slim chance that metadata could not be reduced to size manageable within given space limitation (worst case is Ledger device), or that it could not be reduced to that size in general but could in some cases. This would limit usability of low-memory devices for Substrate-based networks to some extent; we see this probability as very slim and in worst reasonably-probable scenario we see that limitations would be minor, like limit on number of calls in a batch. This kind of limitations would marginally degrade user experience and would not harm security, so this risk seems acceptable. Future models of secure elements with larger memory spaces would probably come to market in near future to bring further relief to these limitations.
After delivering the last milestone, we plan to maintain the project and spread its implementation into the whole ecosystem where its usage is relevant. Alzymologist Oy has further commercial embedded projects where advanced metadata management would be beneficial; probably there are other upcoming projects as well.
Alzymologist Oy is a laboratory, research, and consulting company based in Finland. We have a multidisciplinary team of specialists across many fields, from IT and security to chemistry and biology. Alzymologist team develops Kampela project a working prototype of which was demonstrated at Polkadot Decoded event. Alzymologist team was developing Parity Signer (later renamed to Polkadot Vault) at times of 5.0.1 release and introduced several important standards and protocols still used there. Our extensive expertise on low footprint devices also includes wearable electronics phase radars and civilian science environmental sensors that are currently sending live radiation monitoring data fron Chernobyl region in Ukraine.
Business ID: 3162030-9
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.
Zondax implements changes under the Apache 2.0 license. Zondax is building upon apps that the W3F has already submitted to Ledger. We will submit PRs to Ledger with the corresponding improvements. We assume that as part of the payment, the Foundation and Treasury authorizes us to submit changes of the upgrades to Ledger.
Zondax shall develop the solution according to the present proposal under the Open Source Apache 2.0 license. Accordingly, any warranty and liability is limited to what is expressed in the Apache 2.0 license. In general, Zondax disclaims any liability and warranty to the extent permitted by law arising from the present proposal and the resulting agreement.
Edit 2023-07-06T20:27 Helsinki: restore whole post removed by "link discussion" button
Edit 2023-07-06T20:43 Helsinki: remake table from markdown to polkassembly format
Hello I am really interested in this project, I would like to know how it will really be used. Right now we hardcode metadata on our client, so we would like to know how it will be possible to sign transactions with these new metadata and if it will be able to still sign transactions when there will be spec version upgrade;
Thanks a lot for your work.