The biggest news to ethers this quarter, is the discovery of a critical string serialization **bug** in the BN.js library, identified by Alex Dupre who also provided the necessary patch.

TL;DR: it is not as big a problem as you might think and likely did not affect anyone, but please update ethers anyways. :)

The v5 ethers library uses BN.js because Ethereum operations require a Very Large Integer (VLI) library, since JavaScript [historically] only offered IEEE 754 floating-point numbers. Since BN.js is required by elliptic, the Elliptic Curve Cryptography (ECC) library used by ethers, re-using it for both secp256k1 and BigNumber means only a single VLI library is needed, reducing the size.

Further, since all objects in ethers aim to be immutable, the BigNumber object store all values as hex strings, since they are fast and simple immutable objects that are also efficient to convert back to big numbers for maths.

However, as it turns out, the bug fortunately only manifested itself on incredibly large values, well outside the range for most Ethereum-purposes. All values in Ethereum are 256-bit, and the bug only became a problem when values exceeded 337-bits.

This can still pose a problem in rare instances, since multiplying a 256-bit number by another 256-bit number yields a 512-bit number, which could be affected, or if a large number of values were added together (for example, when calculating an average) the size of the numerator could exceed 337-bits.

But even though the EVM is a 256-bit word machine, most values are no where near 256-bits. For example, 1 ether (10 ^ 18 wei) is only a 60-bit value (in the EVM, the top 196 bits are 0).

Regardless of the unlikely possibility of this bug being an issue, I still highly recommend everyone update their version of ethers.

While the elliptic library and BN.js library have been absolutely wonderfuland critical to ethers since day 0 and the maintainer has always been attentive and prompt to address any issue, the ES2020 BigInt support in JavaScript has come a long way. Now that native VLI is a viable option in most JavaScript environments, along with modern ECC libraries which use them, v6 uses the noble libraries by Paul Miller, which are awesome, fast and have been fully audited.

If you'd like to try it out the v6 beta: npm install ethers@beta.

This is a just a quick summary of some of the v5 updates that have been added. For anyone that's curious, the changelog is among your best friends.

• WebWorker ESM Support
• Skynet and IPNS Content Hash Support
• Default L2 support; matic, optimism, et al
• Hardhat compatibility and quality-of-life changes
• Sub-class support for legacy environments
• More robust error and call exception coalescence
• Added Ankr to the family of default provider backends

A lot of my recent time has been spent working on the new documentation for v6 using JSDoc, which inlines documentation with the source code.

The current v5 documentation links most ethers functions and classes to the relevant TypeScript source, but still requires flipping back and forth between the source and documentation, and there are many places where the docs are either out of sync or only fully described in either the source or the documentation.

By adding JSDoc extraction to Flatworm, the documentation will be kept in sync, provide documentation for all features and issue warnings at build-time if there are undocumented operations or missing exports.

As a quick side note, I just wanted to provide an update on another spare-time project that I recently set aside some time to catch up on and am hoping to stir up some excitement over.

I put about 240-300 hours a month into ethers, so I took a week off at the beginning of May to decompress and relax a bit... By writing some intense and fun C code and reverse-engineering low-level BLE protocol craziness for Firefly, the $5 DIY Open-Source Hardware Wallet.

I've had an idea I've been experimenting with, but without success. But every time I have to use a Ledger to sign a transaction, I've felt more and more motivation to get it working; and I'm happy to tease that the proof-of-concept now works!

It is a technique that allows direct and trustless communication between a hardware device with any Website or Dapp, with no software to install, no browser plugins needed and no scary pop-ups.

For now, I'll leave it intentionally vague, but once the next round of v5 features is out and the updated v6 beta docs have been released, I plan to put another week into getting a demo-ready hardware/firmware/software repo up on the Firefly GitHub.

Thanks for reading! If you have any suggestions or feedback, please reach out and if you're interested in keeping up with my random endeavours, follow me on Twitter.

Thanks! Keep on hacking. <3