feat(blst): use external buffers for blst operations

[spiral-ladder]

Depends on ChainSafe/zapi#30 (we need to release zapi and update the dep)

This is one of possible likely causes for increased GC pressure on experiments to swap out blst-ts for lodestar-z/bls, as observed on feat2 and feat3 deployments in this
PR.

With external array buffers, V8 is only aware of the pointer to the backing memory, instead of having to track both the pointer and the backing memory. This means that during marking phase the GC does not have to walk the backing memory to mark it as 'live' - the frequency of the GC firing off is still the same, but each cycle does less work.

This of course comes with a tradeoff, we need a
finalizer to let V8 know how much external memory is in native heap so that the GC tells the native impl to free the useless memory.

Though, regardless of the effect, we should still probably do this anyway, since napi-rs does the same, and only defaults to V8 managed array buffers if it is disallowed (like in Electron).

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request optimizes memory handling for blst operations by switching to external array buffers. This change aims to reduce GC overhead during marking phases by minimizing the work required for V8 to track memory, ultimately improving performance in high-load scenarios.

Highlights

• Memory Management Optimization: Updated blst operations to use external array buffers, reducing GC pressure by allowing V8 to track pointers rather than backing memory.
• Dependency Update: Updated the zapi dependency to a newer commit to support the required external buffer functionality.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the zapi dependency and modifies the toBytes implementations for PublicKey, Signature, and SecretKey to use js.Uint8Array.fromExternal. The reviewer identified critical use-after-free vulnerabilities in all three methods: since the source data is stack-allocated, the JavaScript objects created via fromExternal point to memory that becomes invalid upon function return. To resolve this, the data must be copied to heap-allocated memory before being wrapped for JavaScript.

[gemini-code-assist]

This implementation introduces a critical use-after-free vulnerability.

The self.raw.compress() and self.raw.serialize() functions return arrays that are stored on the current function's stack. The slice passed to js.Uint8Array.fromExternal then points to this stack memory.

When toBytes returns, its stack frame is deallocated, making the pointer held by the JavaScript Uint8Array invalid. Any subsequent access to this Uint8Array in JS will read from deallocated memory, leading to undefined behavior, memory corruption, or a crash.

To fix this, you must allocate the buffer on the heap. The fromExternal function can then wrap this heap-allocated buffer, and its associated finalizer (which I assume zapi sets up) will be responsible for freeing the memory.

Here is a suggested implementation that correctly allocates memory on the heap:

        const do_compress = try boolOrDefault(compress, true);
        const len = if (do_compress) NativePublicKey.COMPRESS_SIZE else NativePublicKey.SERIALIZE_SIZE;

        const heap_bytes = try allocator.alloc(u8, len);
        // This errdefer is important in case fromExternal throws.
        errdefer allocator.free(heap_bytes);

        if (do_compress) {
            const stack_bytes = self.raw.compress();
            @memcpy(heap_bytes, stack_bytes[0..]);
        } else {
            const stack_bytes = self.raw.serialize();
            @memcpy(heap_bytes, stack_bytes[0..]);
        }

        return js.Uint8Array.fromExternal(heap_bytes);

[gemini-code-assist]

Similar to PublicKey.toBytes, this function has a use-after-free vulnerability because it passes a slice of stack-allocated memory to js.Uint8Array.fromExternal. The memory must be allocated on the heap to prevent the JavaScript Uint8Array from pointing to invalid memory after this function returns.

        const do_compress = try boolOrDefault(compress, true);
        const len = if (do_compress) NativeSignature.COMPRESS_SIZE else NativeSignature.SERIALIZE_SIZE;

        const heap_bytes = try allocator.alloc(u8, len);
        // This errdefer is important in case fromExternal throws.
        errdefer allocator.free(heap_bytes);

        if (do_compress) {
            const stack_bytes = self.raw.compress();
            @memcpy(heap_bytes, stack_bytes[0..]);
        } else {
            const stack_bytes = self.raw.serialize();
            @memcpy(heap_bytes, stack_bytes[0..]);
        }

        return js.Uint8Array.fromExternal(heap_bytes);

[gemini-code-assist]

This function also has a use-after-free vulnerability. The serialize() method returns a stack-allocated array, and a slice of it is passed to fromExternal. This memory will be invalid after the function returns. You need to copy the bytes to a heap-allocated buffer.

        const stack_bytes = self.raw.serialize();
        const heap_bytes = try allocator.alloc(u8, stack_bytes.len);
        errdefer allocator.free(heap_bytes);
        @memcpy(heap_bytes, stack_bytes[0..]);
        return js.Uint8Array.fromExternal(heap_bytes);

[spiral-ladder]

The gemini reviews are inaccurate, since the data is indeed copied (but hidden in the zapi API)