Budget

Due to changes in the exchange rate, the project could only secure 69'813 USD, instead of the originally planned 80'000 USD. As a consequence, we will ask for a compensation of our loss in our next proposal for maintenance Feb23-Apr23.

Report November & December 2022

Deliverables

• 3 releases:

  • github release v0.7.0
    also contains previous implementations
  • github release v0.8.0
  • github release v0.9.0

• Software Design for a CLI wallet implementation with 2FA

Realization of goals

In the following, a more detailed summary of the addressed goals is presented.

1. Ongoing Maintenance

• Current Issues

  • Ease-of-use

    • Generic Api - compatible with all possible Substrate runtimes (#334, #340)
    • Introduced the update_runtime function, allowing the api-client to follow the nodes runtime upgrades (#337)
    • The Api is abstracted behind traits, allowing easy mocking and exchanges (#363)
    • Several new, handy functionalities were introduced, such as submit_and_watch_extrinsic_until_success, get_storage_keys_paged and several system-getter helpers (#394,
      #398,
      #402,
      #403)

  • Improve performance

    • Newly introduced jsonrpsee client. With this, the issue with too many node requests was finally solved (#366).

  • Improve documentation

    • Add more examples (#345, #313, #298, #291, #371)
    • Get documentation up-to-date (#305)
    • Improve overall example quality (#371)

  • List of all merged PRs related to solving one of the issues of this propsal:
    #199,
    #226,
    #241,
    #277,
    #274,
    #310,
    #263,
    #225,
    #202,
    #157,
    #267,
    #134,
    #303,
    #314,
    #328,
    #337,
    #133,
    #175,
    #367,
    #353,
    #288,
    #369,
    #370,
    #195,
    #316,
    #391,
    #380,
    #400

• Stay up-to-date with ecosystem

  • Licensing to Apache-2.0 (#274)
  • Follow polkadot branches (#300, #301). The current latest polkadot branch is v0.9.36.
  • Stay up to date with parity libraries (#286,
    #304
    )

• Technical debt

  • Can the tip type be detected via metadata or Runtime? (#344)
  • Improved CI (#324, #327)

• User support

  • Structured tag releases for documentation of breaking changes (#314)
  • User issues addressed (#119, #223, #227, #338, #343)
  • Reviewed and accepted external pull requests (#355)

2. Long term goals

• CLI-wallet implementation with decent security

  We analyzed how this feature can be implemented and documented our findings here. The feature is ready for implementation. The first version would include password encrypted key storage. The second version can include 2FA with a YubiKey. The concept includes both usecases.

  We plan to implement the first version with password encrypted key storage within the next proposal (Maintenance Feb23-Apr23).

• Full no_std compatibility

  In a first step we analyzed if the substrate-api-client can be made fully no_std compatible. For most parts this proved to be feasible. The only exception is the websocket communication (the rpc client). Networking usually needs very low level primitives interfacing with the hardware. As the hardware is user dependent, there is most likely no generic rpc client implenentation possible in a no_std environment. Therefore, the user is required to implement a hardware specific rpc client. But with a reasonably simple interface to the api-client the required extra effort can be kept to a minimum.

  Hence, we implemented the following:

  • Full no_std compatible api-client, except for the rpc clients (#377).
  • Simple and clean no_std compatible rpc interfaces (#336, #384)