relatko
commented
2 years ago Recent work included consolidation of data relevant to transaction implementation. The data consist more or less of
- script hash
- transaction name
- argument data (description to be displayed on the device, type) See this soon to be merged PR on how it looks: https://github.com/onflow/ledger-app-flow/blob/tx_data_refactor2/app/src/tx_metadata.c
This approach is sufficient to store several hundreds of transactions. One of the tasks I am at the moment working on is move this data out of the app using standard Merkle tree technique (where the app will only have the root hash hardcoded). This will allow basically unlimited types of transactions the app can handle (practical limit will be probably the ability to provide the required data to the system I am developing).
bluesign
Description
Currently the ledger app has a list of hardcoded transactions which are supported by the device. This is limiting because the device doesn't have much storage for each app, and it would be better to more efficiently verify transactions. The idea is the use a hash of the transaction as an identifier which then can be verified by an internal database.
There are a couple of options that are still TBD for how to actually store the set of valid hashes (e.g. as a list of hashes, or by construction a merkle trie and having each release contain the one root hash).
Definition of Done
TBD - @Wolog2021