Wax Just Lost Weight - And It Feels Great! šļø
Hey Hive community! š
We hope you've had a chance to read about the major improvements we've made recently in the Denser project, particularly regarding signer support ā if not, here is the source...
Honestly, the above changes would have been impossible without a huge amount of work done in a place far less exposed and glamorous than a frontend application ā deep inside a low-level, quietly living library. The Wax library, which we hope will become the standard way to interact with the Hive blockchain, thanks to its very tight integration with the Hive protocol's C++ code and its clean, modern TypeScript interface.
This short story, which I hope we'll expand in a future post with a detailed, "nerd-like" description of how we did it, actually covers roughly the last year (or perhaps even longer) of work to make things better, simpler, and cheaper in everyday maintenance.
That's why we decided to release a new version of Wax with a HUGE versioning leap (even though, honestly, the last few releases contained no major breaking changes to the public interface): TWO at the beginning just looks much more mature ā or so we hope... But enough about that ā let's see what we actually changed.
It is already published on npmjs. This version also comes with documentation, which you can find here.
I hope the above (perhaps a bit boring, written by yours truly ā ) along with the enthusiastic words below from Wax's "daddy,"
, will bring you a few moments of joy.
You know how we've been pushing performance optimizations for our libraries? Well, this time we went the other direction - size optimization - and the results are absolutely wild! š¤Æ
š The Numbers Don't Lie
| Metric | Before | After | Reduction |
|---|---|---|---|
| WASM binary | 4.6 MB | 2.5 MB | 46% |
| Package size (compressed) | 2.5 MB | 1.1 MB | 56% |
| Unpacked size | 5.5 MB | 3.4 MB | 38% |
That's right - more than half of the package size just... gone! šØ
And before you ask - no, we didn't remove any features. Everything still works exactly as before. We just taught the build system some new tricks š
š§ How We Did It
1. Better Crypto Library Compilation š
We upgraded our emsdk toolchain to version 4.0.22 with -Oz optimized libraries. The secp256k1 cryptographic library (responsible for all the signature magic āļø) is now pre-built with aggressive size optimizations. This alone made a HUGE difference!
2. Additional wasm-opt Pass šŖ
We added an extra optimization phase using wasm-opt. Think of it as a second round of compression, specifically designed for WebAssembly binaries. This shaved off another ~500kB
3. Smarter Exception Handling in fc š§
Here's a nerdy one: The fc library had exception handling code (FC_RETHROW_EXCEPTIONS) that was being duplicated across every template instantiation. We introduced an unpack_error_handler class that centralizes this logic into a single non-template function.
Translation: Instead of having ~3 catch handlers per template (and there are A LOT of templates), we now have one shared handler. Less code = smaller binary!
4. Excluding Virtual Operations from WASM Build š«
Virtual operations are blockchain-generated events (like author_reward_operation, curation_reward_operation, etc.) - users never create or sign them. So why include 43 extra operation types in the WASM build?
We added a compiler flag HIVE_PROTOCOL_SKIP_VOPS that excludes all virtual operations from the hive::protocol::operation type definition. Less types in the variant = less template instantiations = smaller binary!
5. Stripped-Down OpenSSL Build š
OpenSSL is a beast of a library - but we don't need 90% of it for WASM! We built a minimal OpenSSL with only the crypto primitives we actually use:
- Disabled: SSL/TLS/DTLS protocols, DSA, DH, RC2/4/5, Blowfish, CMS, OCSP, compression, sockets, error strings
- Enabled: Only the bare minimum for our cryptographic needs
Combined with -fvisibility=hidden and --gc-sections linker flags, this stripped away tons of unused code!
ā” Same Speed, Less Weight
The best part? Zero performance impact. All those size optimizations are purely at the compilation level - the code that actually runs is still as fast as ever.
This means:
- ā¬ļø Faster downloads for your users
- ā¬ļø Less bandwidth for your servers
- ā¬ļø Quicker cold starts in serverless environments
- ā Same blazing fast execution
š How Does Wax Compare to Other Hive Libraries?
You might be thinking: "But wait, isn't WASM still bigger than pure JavaScript libraries?"
Let's talk about that. We bundled simple scripts using popular Hive libraries to see the real JavaScript bundle sizes:
| Library | What It Does | Bundle Size | Gzipped |
|---|---|---|---|
| @hiveio/wax | Create foundation, format coins | 169 KB | 43 KB |
| @hiveio/dhive | Create client, iterate blocks | 927 KB | 211 KB |
| hive-js | Broadcast Vote | 1.2 MB | 257 KB |
| keychain-sdk | Encode a memo message | 2.3 MB | 483 KB |
Yes, you read that right. The Wax JavaScript bundle alone is 5.5x smaller than dhive and 13.5x smaller than keychain-sdk! š¤Æ
But What About the WASM File?
Fair point! Wax also needs to download the WASM binary (~2.5 MB, ~1 MB gzipped). But here's the thing:
Browser Caching šļø - The WASM file is downloaded once and cached. Subsequent page loads only need the tiny 43 KB JS bundle.
CDN-Friendly š - WASM files are perfectly suited for CDN distribution with long cache headers.
Parallel Loading ā” - Modern browsers fetch and compile WASM in parallel with JavaScript execution.
The Real Difference: What's Inside
Here's what really matters - what are you actually downloading?
| Aspect | @hiveio/wax | dhive / hive-js |
|---|---|---|
| Protocol Implementation | Actual C++ hive code | JavaScript reimplementation |
| Serialization | HF26 format (modern, preferred) | Legacy format (obsolete) |
| Crypto | Native secp256k1 via WASM | JS crypto libraries |
| Correctness | Verified against hived | "Should work" š¤ |
| API Types | Auto-generated from protocol | Manually maintained |
The other libraries essentially reinvent the wheel in JavaScript - reimplementing serialization, crypto, and protocol logic that already exists in the official hive C++ codebase. And they're stuck with the legacy serialization format from the pre-HF26 era.
Wax takes the actual hive protocol implementation, compiles it to WASM, and wraps it with a modern TypeScript interface. You get:
- ā Guaranteed correctness - same code that runs on hived
- ā HF26 serialization - the modern, preferred format
- ā Native performance - WASM crypto is faster than JS
- ā Future-proof - protocol updates come from the source
š What's Next?
Ready to try the slimmer Wax? Getting started is simple:
npm install @hiveio/wax
š¦ NPM Package: https://www.npmjs.com/package/@hiveio/wax
š Documentation: https://hive.pages.syncad.com/wax-doc
š® But Wait, There's More!
We're not done yet! š
There are still a few optimization opportunities we're exploring. The goal? Making Wax as lean as possible without compromising on functionality or speed.
Stay tuned for more updates - the optimization journey continues! š
Happy building! š