Skip to content

v16: staking, transaction viewer, reliable relayer, security patches, event parsing library, command library, test utilities and token tests
Compare
Choose a tag to compare
@polymorpher polymorpher released this 20 Apr 10:29
· 578 commits to master since this release
v0.16.1
8c3da3e

1wallet v16 release notes

This update (April 5, 2022) includes two security patches, the staking feature, the transaction viewer, several developer libraries, and better test coverage and utilities.

Related issues:

Feature updates

  1. Staking and Earn Rewards: Staking enables you to earn reward in ONE over time using funds in your wallet. You can now delegate your funds to any validator on Harmony network. A "Staking" button is added to the main UI of the wallet. To stake, you need to find a validator to delegate your funds to. You can get a list of validators from Harmony Staking Dashboard.

    • Delegated funds are deducted from the wallet's balance
    • Delegated funds earn you reward every epoch (~18 hours). You can collect the reward from the staking UI.
    • You can undelegate your funds at any time. Undelegation takes 7 epochs (~5 days) to complete. When it is complete, the funds will be returned to the wallet.
    • Redelegating funds after undelegating only requires you to wait until the next epoch, which takes a maximum of ~18 hours, instead of 7 epochs (~5 days).

  2. Transaction Viewer: You can now view historical transactions of your wallet using the "History" tab.

    • Each operation needs to be committed first, before they are executed. Thus, there are at least two transactions per operation. The "commit" transactions are shown in grey color.
    • Wallet emits some events during each successful operation. The events correspond to operations performed during each transaction.
    • Approximate amounts are displayed for events involving transfer or staking some amount of ONE or ERC-20 / ERC-1155 tokens.
    • Human-readable event names are shown for each transaction. They are decoded from the "logs" of the transaction, which can also be viewed in "Logs" section in the Harmony explorer. You can view the transaction in the explorer using the link provided in "TxHash" column.

  3. More Reliable Transactions: In prior versions, users sometimes experience transaction failures during peak usage times. In extreme cases, all subsequent transactions become stuck after some transactions fail to execute. Although there were many reasons behind the failure (such as congestions in the underlying RPC nodes, or the blockchain itself), we improved the relayer so that:

    • the transactions are spread out across multiple relayer accounts, so failures or dropped transactions in one account would not affect transactions executed from other accounts, and
    • the transactions are automatically retried at higher gas price

    These improvements allow the relayer to scale horizontally to handle arbitrary amount of peak-time usage, and user experience will be significantly improved as a result.

Security Patches

v16 fixed two issues.

Batch Operation Security Circumvention

The first is that some v15 wallets users may be able to execute some operations using only a single auth code (6-digits) instead of six auth codes (6x6-digits) if they wrap the operation (that would otherwise require six auth codes) inside a BATCH operation. The BATCH operation allows arbitrary number of operations to be wrapped inside, but it only requires a single auth code to execute. See issue 276 for more details. V16 fixed this issue by limiting the operations BATCH is allowed to wrap around.

Authentication Parameter Reuse

The second issue is reveal-authentication parameters may be reused across upgraded wallets and its prior versions (which allow same authentication parameters to execute a transaction). This is documented in issue #253 and #278. V16 fixed this issue by preventing wallets of prior versions (with a minimum version of v16) to execute any transaction by itself. It can only perform operations when it is commanded by the latest upgraded wallet (which wallets of prior versions point to). Note that this patch does not affect the behavior of wallets prior to v15, because their smart contract code remains immutable.

For most users, this issue poses little risk because all assets are already migrated out from their wallets of prior versions. For users who use wallets of prior versions in an app (such as Harmony Multisig) and actively use the upgraded wallet (i.e. storing assets or performing transactions), this would pose significant risk because an attacker could read the EOTP submitted to the blockchain in one version, and re-use the EOTP in the other version, therefore:

  • use the upgraded wallets (to move assets or make transactions) while the user performs operations in wallets of prior versions (e.g. authorize a multisig transaction), or
  • use the wallets of prior versions (e.g. authorize a multisig transaction) while the user uses the upgraded wallets (to move assets or make transactions)

In either case, the attacker could potentially cause significant harm to the user by executing arbitrary, unintended operations. Therefore, it is highly recommended that any user who uses wallets of prior versions in an app should:

  • upgrade their wallet to 16.1
  • immediately unlink the wallet of prior version from their app, and link the latest upgraded version (>= 16.1) instead.
  • For example, in the case of Harmony Multisig, it means to remove the wallet of prior version from the list of owners.

Technical notes

v16 made significant technical improvements, which may be of interest to developers who are building tools for the wallet, are using it as wallet infrastructure, or considering to integerate the wallet into their app.

Event Parsing Library

Events can now be parsed from transaction receipts (obtained from standard eth_getTransactionReceipt RPC calls or web3 libraries) using this library, which is located at code/lib/parser.js. See code/client/src/pages/Show/TransactionViewer.jsx for usage examples, and issue #277 for the purpose of this library.

Command Library

When COMMAND operation was introduced in v9, it was rarely used. With the introduction of the security patch in v16 (see above, "Authentication Parameter Reuse"), COMMAND will become a frequently used operation. However, converting an operation into a COMMAND operation is non-trivial. The parameters in the reveal operation must be transformed completely, and the wallet address which the transaction is originally issued to must also be changed. The challenges and solutions are documented in detail at issue #278. The library introduced in v16 can be found at code/lib/api/command.js. The transformations and usage examples can be found in code/lib/api/flow.js:L447 (SecureFlowsV16), and tests in code/test/command.js

Test Framework and Token Tests

A slew of test utilities are introduced in v16, followed by a new testing framework, thanks mostly to the work of @johnwhitton. Based on this framework, we now have complete test coverage for token related operations. See the README notes in testing framework.

Backward compatibility

v16 will be fully compatible with v15. There is no change in relayer parameters or smart contract interfaces.

Assets 2
Loading