ledgerhq / app-zilliqa

Zilliqa wallet application for Ledger Nano S

Zilliqa Ledger App for Nano S and Nano X

Zilliqa wallet application for Nano S and Nano X.

Build environment

To build all elfs, run:

docker run -it -v $PWD:/app --user "$(id -u)":"$(id -g)" ghcr.io/ledgerhq/ledger-app-builder/ledger-app-builder-lite:latest ./tools/build-all.sh

To build test environment, run:

docker build .  --tag builder_image

Then run the tests:

docker run -it -v $PWD:/app builder_image:latest ./tools/test-all.sh

Build and load image

To build, start the Docker image with:

docker run -it -v $PWD:/app --user "$(id -u)":"$(id -g)" ghcr.io/ledgerhq/ledger-app-builder/ledger-app-builder-lite:latest

and run

make BOLOS_SDK=[SDK]

where [SDK] is ${NANOS_SDK}, ${NANOSP_SDK} or ${NANOX_SDK}. Then exit the docker image. Next load the

docker run -it -v $PWD:/app --user "$(id -u)":"$(id -g)" --privileged builder_image:latest

To load the app:

make load

To uninstall:

make delete

To run tests:

PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python pytest tests/functional/ -v --device [device]

app-zilliqa's Issues

Improve readability of content of TX to sign

It is hard for users to try to decode the contents of the JSON blob with transaction content on the Ledger Display and determine if the info is correct. This is made worse by the fact that addresses are shown on Legacy address format inside the tx JSON blob.

E.g. when I swap ZIL to buy GZIL on ZilSwap and use my Ledger, the GZIL token symbol will not be displayed, which is bad as is, but made worse by the fact that not even the GZIL ZIL contract address will be shown as I know it -- on bech32 format -- but rather the legacy address is displayed. Also, the recipient address (my address) is shown on the legacy format.

So I have to go to GZIL in e.g. ViewBlock: https://viewblock.io/zilliqa/address/zil14pzuzq6v6pmmmrfjhczywguu0e97djepxt8g3e

Copy the contract address zil14pzuzq6v6pmmmrfjhczywguu0e97djepxt8g3e and convert it myself using e.g. Coinhakos Zilliqa Address Tool (which Bech32 encodes and decodes).

I propose the following updates to the Ledger Nano app:

1. Pretty print the JSON TX blob so that only at maximum 1 key-value pair is displayed per Ledger Screen (sometimes a key-value pair might not fit on 1 screen, which is ok)
2. Make GZIL a first-class citizen of the Ledger Nano App, i.e. do a comparison of the value of the asset, if it matches the address of GZIL, display "token: GZIL" instead of the address
3. For non-ZIL and non-GZIL assets display the contract address on bech32 format
4. In general, always display all addresses on bech32 format
5. Please display the amount in ZIL instead of QA denomination (maybe add to settings the possibility to round to 1 or 2 decimal precision)

This issue might be split into several issues, which is OK, but this is a start.

I used Pieter Wuille ("Sipa") bech32 encoding code when I wrote Radix DLTs Ledger Nano app, find the bech32_encode.c file here. And an example of usage here

Here are some UInt256 amount denomination conversion code

Why is Zilliqa using a BIP32 derivation path on the Ledger that is not compatible with the derivation path used by other Zilliqa wallets?

My understanding is that, for account #n, on Ledger, Zilliqa uses the derivation path m/44'/313'/n'/0'/0' while the other BIP39-compatible Zilliqa wallets use m/44'/313'/0'/0/n.

Is there a valid reason for this discrepancy? (other that Zilliqa devs using a quick cut-and-past from a boilerplate ledger app sample when they made the Zilliqa ledger app)

mul256 sets upper bits incorrectly when multiplying large numbers

Your uint256 library has issues with multiplication.

The simplest reproduction I can do is

    uint256_t a;
    // 10e425c56daffabc35c1
    clear128(&UPPER(a));
    assert(UPPER(UPPER(a)) == 0);
    assert(LOWER(UPPER(a)) == 0);
    UPPER(LOWER(a)) = 0x10e4;
    LOWER(LOWER(a)) = 0x25c56daffabc35c1;
    mul256(&a, &a, &a);
    // 11d500bfaf40ac5044981798db5fb39f2c17b81
    assert(UPPER(UPPER(a)) == 0);
    assert(LOWER(UPPER(a)) == 0x11d500b);
    assert(UPPER(LOWER(a)) == 0xfaf40ac504498179);
    assert(LOWER(LOWER(a)) == 0x8db5fb39f2c17b81);

I find:

square 0000000000000000000000000000000000000000000010e425c56daffabc35c1 -> 000000000000000100000000011d500afaf40ac5044981798db5fb39f2c17b81

It looks like the 1 in the upper upper word should have instead been added to lower upper word.