feat/253 Implement ledger service in Extension

[jurevans]

Resolves #253
Resolves #335

This PR adds the Ledger service to the extension, and adds Bond Tx to the approval process, allowing user to sign a Bond Tx with their Ledger (along with Reveal Public Key tx)

• User can select Ledger accounts from interface
• Extension can track alias and paths to use with Ledger
• Submitting a Bond for the first time requires and prompts user to approve a Reveal Public Key tx
• Submitting a Bond Tx prompts user for approval
• Approving a Bond Tx prompts for password (if using a private key)
• Approving a Bond Tx provides Ledger prompts (if using Ledger account)
• Rejecting a Bond Tx removes pending transaction
• Bond is successfully submitted through SDK
• Bond is successfully signed with the Ledger keys, and submits through the SDK

Nice-to-have

• Submitting a bond gives the user the appropriate notification in interface (e.g., "Bond is submitting" or something)
  • TODO This is partially hooked up, but there still remains an issue with updating amount staked. Token balance after bonding does currently work

NOTES

• This PR includes a built copy of the ledger-namada package in packages/, which contains the necessary changes on the client-side to parse Ledger responses, so we are no longer using the @zondax/ledger-namada package.

Testing

Setup

1. Set up a local chain based on tag v0.18.1, do not build wasm scripts! We want the wasms that are delivered through AWS (and remember to fix the CORS setting in the chain's config.toml, e.g., local.c4463480b0eb1dbf83a1d0d0/setup/validator-0/.namada/local.c4463480b0eb1dbf83a1d0d0/config.toml), then start that chain and set up a wallet (CLI)
2. Ping me for a copy of the installer script you need for your Ledger, then install with ./installer_s2.sh load (e.g., if you're using a Ledger Nano S-Plus)
3. Install the extension from this branch, and set up an initial account
4. In the extension, click the "settings" (gear) icon, then click Add Account - from the new tab, click Connect to Ledger, then give it an alias, then click Add to wallet and close
5. In the namada CLI, transfer tokens to your initial account and your Ledger (for testing both Bond tx from a local wallet account as well as from Ledger, as both of these are updated in this PR)

Testing Bond tx

1. In the interface, select either your initial account, or ledger account, and click the Staking menu item (top menu)
2. You will see a link to a validator, so click that
3. From this view, click Stake (there is an account drop down, but you don't need to change this if the account selected has funds, but you can as an option)
4. In the modal window, enter an amount you would like to stake, then click Confirm
5. In the popup window, click to confirm the transaction:

• If you selected a local wallet account, you will be prompted for a password to unlock your key and sign the transaction
• If you selected Ledger, you will see the following:
  1. The first time you use your Ledger account, you will be prompted on the device to approve a reveal public key tx (go ahead and click through to approve!)
  2. Following that, you will need to also approve the Bond tx. Once this is approved, you should see a success message once it completes

SCREENSHOTS

Ledger account loaded in extension

Ledger account loaded in interface

[github-actions]

🚀 Deployed on https://pull-request-295--wallet-development-heliax-dev.netlify.app

[mateuszjasiuk]

I think this looks good. Left few comments/questions. I'm curious if it is possible to have one flow instead of two for submitting transactions. So for example we get rid off the submit_bond and we use only submit_signed_bond. The only difference is that we are asking sdk to sign instead of ledger. This would potentially simplify few things :)

[mateuszjasiuk]

I'm curious why did we delete await here I'm curious if it is not problematic in a case that onSelectAccount throws error?

[jurevans]

I removed it because it's not an async function (throwing lint warning)

[mateuszjasiuk]

Does it mean that we will have confirmation screens for every tx type, times 2 for the ledger ones?

[jurevans]

This is what I'm refactoring next - I don't want to have individual views for each tx type necessarily, the only difference we'll encounter is the type of details we display to the user. That's something I'm planning to clean up before implementing other Tx!

[jurevans]

I'm thinking I will start by ignoring differences in Tx (reducing the query string that opens the approval window) and keeping common values (amount, type, source) for now, then incorporate differences later as needed. That should make for much cleaner code

[mateuszjasiuk]

I'm curious if something like:

  const {
    type,
    id,
    amount,
    source,
    token: tokenAddress,
    publicKey,
  } = query.getParams(["type", "id", "amount", "source", "token", "publicKey"]);

Would be a good thing to add in future.

[mateuszjasiuk]

Not sure if this can happen, but what if queryErrors gets rejected?

[jurevans]

The only error that can happen is that the Ledger instance can't find NamadaApp - so either the app is not loaded, or the Ledger isn't plugged in and connected. The query for status() in background/ledger/ledger.ts catches that situation there, this is more of a wrapper function for status() that returns any non-error error messages so the client doesn't have to do that logic. However, if that error was thrown in the Ledger status call, it isn't getting caught here, which isn't good. Maybe it should be moved to the above try so that the status error, if thrown, will be caught.

[jurevans]

Also, I just realized that this is ConfirmLedgerTransfer - in my next PR I am getting rid of this file entirely - I took out the queryErrors call in ConfirmLedgerBond, so I'll leave this as is! Sorry I thought this was the other confirmation!

[mateuszjasiuk]

I think those todos(also line 69) are already done right?

[jurevans]

I think for type I will make it a part of the routing, so we can just direct it by URL to catch that param, but the type I've added here is account type, not tx type - it needs to be more explicit because it's confusing!