Make Lumos Work Smother With the Modern Frontend Dev Tools

[homura]

Currently, Lumos has some methods, particularly crypto-related APIs such as mnemonicToSeedSync(): Buffer in @ckb-lumos/hd. This makes it a bit challenging to integrate Lumos directly with some modern developer tools like Vite. To work with Vite, developers typically require additional configuration to include these methods in the project, which is inconvenient.

I would like to propose a refactor to replace these methods with a modern one such as https://github.com/paulmillr/noble-curves, which is suitable for working with multiple major runtimes. Noble-curves is a trusted option for many projects as it has been audited. However, noble-curves relies on the bigint API, which means a breaking change for Lumos to use it as the NodeJS's node:cyrpto alternative.

Around two years ago, Lumos introduced a big integer library @ckb-lumos/bi and migrated the bigint-related API to the library for compatibility in #212, as some browsers didn't support bigint, especially Safari on iOS < 13.7.

Therefore, if we want to achieve this, some breaking changes will be required:

• Introduce bigint and drop the compatibility of iOS < 13.7(the market share < 3% at 2023-12)
• Change the Buffer returned from some methods to Uint8Array

But this makes Lumos

• Smaller because we don't need the whole browserify-crypto, browserify-buffer, etc.
• More convenient because we don't need additional polyfill config in the project

Let me know if you think this change is worth it!

Q&A

• Does the fallback of Buffer to Uint8Array affect massively?

Probably not, the Buffer is extended from Uint8Array, therefore, I suppose it is a slight change, or even without any change if developers do not use the Buffer API.

- const seed = mnemonicToSeedSync()
+ const seed = Buffer.from(mnemonicToSeedSync())
console.log(seed.toString('hex'))

• For the long-term perspective, how would this change impact BI?

It depends on developers' habits. I'd also like to add that the current BI supports construct via bigint

Notes

• The incorrect test case in hd wallet module #570

[jordanmack]

I support updating. The change sounds reasonable and the updates needed to support it are minimal.

In particular, I personally never liked using BI. I would much prefer to use the native BigInt.

[homura]

#645

[homura]

The PR #684 dropped all the fs support