hive-186392 community on Hive

PR #141: Letting Hive-Engine Lite Nodes Catch Up Before Cleaning House

thecrazygm — Sat, 17 Oct 2026 14:24:45 GMT

Hey everyone,

In my last update, I broke down the Knobs A, B, and C changes and teased what was coming next. The latest piece of that puzzle, Knobs D, is now built, tested on live mainnet traffic, and submitted as PR #141 against the qa branch.

This round focuses squarely on lite-node operations: specifically, teaching the node to hold off on pruning local database history when it has more urgent work to do.

The Problem: Housekeeping During a Fire

Lite nodes stay small and efficient by periodically running cleanup jobs (database.cleanupLightNode()) to purge old blocks and transactions they no longer need. Under normal conditions, this background housekeeping runs quietly and everyone is happy.

The trouble starts when a node falls behind. Whether it's scheduled server maintenance, an unexpected reboot, or an upstream network hiccup, a node that wakes up thousands of blocks behind the chain head needs all the CPU cycles and disk I/O it can get just to ingest and validate incoming blocks.

Having MongoDB stop what it's doing every few minutes to execute heavy delete operations right in the middle of a catch-up sprint is the database equivalent of vacuuming the living room while the house is on fire. It causes unnecessary I/O contention and drags out the time it takes to get back to the head block.

The fix is straightforward in concept: make cleanup lag-aware. If the node is struggling to catch up, let it defer cleanup for a bit and focus on block ingestion.

Crucially, this doesn't touch block processing order, smart contracts, or consensus rules. It strictly changes when local pruning takes place.

The New Configuration Knobs

The adaptive cleanup behavior is completely opt-in and controlled under the lightNode configuration block:

{
  "lightNode": {
    "enabled": true,
    "adaptiveCleanup": true,
    "cleanupLagThreshold": 1000,
    "maxConsecutiveCleanupSkips": 3,
    "lastVerifiedBlockCacheTTL": 900000
  }
}

Here’s how these pieces work together:

adaptiveCleanup: Enables the lag-aware logic. If left false (the default), the node behaves exactly as it always has.
cleanupLagThreshold: How many blocks behind the node needs to be before it starts skipping cleanup passes. In this example, if the node is more than 1,000 blocks behind head, it postpones pruning.
maxConsecutiveCleanupSkips: The safety valve. We can't let a node defer cleanup indefinitely while syncing a massive backlog, or local disk usage would balloon. Setting this to 3 means the node will skip at most three consecutive cleanup cycles before forcing a cleanup pass anyway, regardless of lag.
lastVerifiedBlockCacheTTL: Caches the lookup for lastVerifiedBlockNumber in memory for 15 minutes (900,000 ms).

That last setting is a quiet efficiency win. Previously, every single cleanup pass did a full database lookup against witnesses.params to find the last verified block height. Since round verification only advances every ~40 minutes (~1,200 blocks), re-querying the database every cleanup cycle was pure waste.

Because verified block height only moves forward, a cached value is inherently safe: the absolute worst case is that the node retains an extra 15 minutes of old blocks before pruning them. It can never cause the node to delete data too aggressively.

Live Testing on a 19,000-Block Catch-Up

Unit tests are good for checking logic, but I always prefer seeing how these changes behave under actual pressure. I've been running this branch on my live witness setup since October 5th.

As luck would have it, my test node ended up falling about 19,000 blocks behind: giving me a far more realistic stress test than any tidy benchmark I could have staged.

Watching journalctl during the catch-up confirmed the safety limits were working exactly as designed. The node fell into a predictable rhythm: three skipped cleanup passes followed by one forced cleanup pass, repeating continuously while it processed the backlog.

Over the course of the run, the logs recorded 90 skipped cleanups and 30 forced cleanups. The lag steadily dropped from 19,000 blocks down past the 1,000-block threshold, at which point normal periodic cleanup resumed smoothly. The node is now sitting happily locked to the Hive head.

Designing for Failure: The Fallback Guardrail

One detail I was very deliberate about: what happens if the streamer encounters an RPC blip and can't accurately report chain lag?

A naive implementation might assume zero lag and clean up constantly, or worse, assume infinite lag and stop cleaning up forever.

Read the full post

Upgrading MongoDB 8 to 9: Why Systemd Refused to Start and How to Bridge the FCV Gap

thecrazygm — Mon, 05 Oct 2026 15:40:51 GMT

Hey everyone,

If you run a Hive-Engine node (or manage a self-hosted MongoDB instance on Linux), you might run into a nasty surprise after bumping your apt repositories for MongoDB 9.0.

You configure the official repository, run sudo apt update && sudo apt dist-upgrade, let the package manager do its thing, and wait for mongod to spin back up.

Except it doesn't.

systemctl status mongod shows the service failed immediately on boot with exit code 62, leaving you staring at an offline database and wondering whether your node's 400+ GB dataset just got toasted.

The good news: your data is completely fine.

The catch: you've stepped right into MongoDB's rapid release compatibility trap.

Here is what went wrong, why MongoDB 9.0 flat-out refused to boot, and the step-by-step process to safely bridge the gap (including the replica set details that Hive-Engine strictly enforces) so you can get your node back online with zero data loss.

The Symptoms: Exit Code 62 on Startup

Immediately after upgrading packages from MongoDB 8.2 to 9.0, systemctl status mongod reported:

× mongod.service - MongoDB Database Server
     Loaded: loaded (/usr/lib/systemd/system/mongod.service; enabled; preset: enabled)
     Active: failed (Result: exit-code)
    Process: 3053614 ExecStart=/usr/bin/mongod --config /etc/mongod.conf (code=exited, status=62)
   Main PID: 3053614 (code=exited, status=62)

Exit code 62 in MongoDB means server initialization failed during startup checks before opening network listeners.

To see the real reason, checking /var/log/mongodb/mongod.log (or journalctl -u mongod) revealed this fatal log entry:

{
  "s": "F",
  "c": "CONTROL",
  "id": 20573,
  "ctx": "initandlisten",
  "msg": "Wrong mongod version",
  "attr": {
    "error": "UPGRADE PROBLEM: Found an invalid featureCompatibilityVersion document (ERROR: Location4926900: Invalid featureCompatibilityVersion document in admin.system.version: { _id: \"featureCompatibilityVersion\", version: \"8.2\" }. See https://docs.mongodb.com/master/release-notes/8.0-compatibility/#feature-compatibility. :: caused by :: Invalid feature compatibility version value '8.2'. Expected one of the following versions: '9.0', '8.3', '8.0'.)"
  }
}

Notice the crucial detail:

Invalid feature compatibility version value '8.2'. Expected one of the following versions: '9.0', '8.3', '8.0'.

Immediately after emitting this error, mongod initiated an orderly rollback checkpoint and shut itself down cleanly without touching or modifying any user collections.

Why Did This Happen? The Rapid Release Trap

MongoDB follows two release tracks:

Major / LTS Releases: (e.g., 7.0, 8.0, 9.0)
Rapid Releases: quarterly minor feature releases between major versions (e.g., 8.1, 8.2, 8.3)

Every MongoDB database contains an internal setting called featureCompatibilityVersion (FCV) stored in the admin.system.version collection. FCV controls which on-disk features, file structures, and internal behaviors the engine is permitted to use.

MongoDB enforces strict rules when upgrading:

You cannot skip versions.
A major release binary only knows how to handle datasets from the previous LTS release (e.g., FCV 8.0) or the final rapid release immediately preceding the new major version (e.g., FCV 8.3).

Because my machine was previously tracking the rapid release channel on MongoDB 8.2 (8.2.12), its internal FCV was set to "8.2".

When the MongoDB 9.0 binary checked the metadata at startup, it saw an FCV of "8.2". But 9.0 only knows about '8.0', '8.3', and '9.0'. It does not support jumping directly from 8.2 to 9.0.

Furthermore, you cannot simply tell 8.2 to downgrade its FCV to 8.0. MongoDB only allows setting FCV to its current minor version or the immediately prior one (8.2 or 8.1).

The only supported bridge to 9.0 is MongoDB 8.3.

The Hive-Engine Factor: Replica Sets Are Mandatory

There is another crucial detail every node operator must know: Hive-Engine strictly forces MongoDB to run as a replica set (typically replSetName: "rs0" in /etc/mongod.conf), even when running on a single local server.

Hive-Engine relies heavily on multi-document ACID transactions and change stream / oplog tailing to process smart contracts deterministically. A standalone MongoDB instance simply will not run Hive-Engine.

This requirement introduces three essential rules during this upgrade process:

Read the full post

Recap of the Useful Knobs for Hive-Engine Nodes

thecrazygm — Thu, 24 Sep 2026 13:48:06 GMT

Hey everyone,

Over the past few weeks, I’ve been chipping away at a series of performance tweaks and operator controls for the Hive-Engine node. What started as a sprawling wish list of potential optimizations quickly became a deliberate exercise in restraint. Instead of dropping one massive, high-risk pull request on the maintainers, I broke the work down into three smaller, easily reviewable bundles, all of which should currently be available in the qa branch of hive-engine/hivesmartcontracts (at least for now, as they get broader testing before hitting a main release):

Knobs A: Expose a few critical runtime settings that were previously hardcoded.
Knobs B: Cut out avoidable waiting in the core block-processing path.
Knobs C: Make block fetching adapt intelligently when a node falls behind.

In plain English: operators can now tune the JavaScript VM pool, customize MongoDB connection pooling, and let the streamer catch up faster after maintenance—all without touching the source code. Under the hood, transaction index writes are now cleanly batched, and the VM pool warms up predictably on first use.

Most importantly, none of this touches consensus, smart contract execution rules, or block processing order. Here’s a breakdown of what changed, why it matters, and how it held up in live testing on my witness node.

Knobs A: Un-hardcoding Useful Runtime Settings

The first bundle focused on exposing two settings that were either hardcoded or awkward to adjust without maintaining custom forks.

JavaScript VM Pool Count

Hive-Engine executes smart contracts inside isolated JavaScript VMs. Previously, the engine locked this down to a hardcoded ceiling of five VM instances. You can now configure this directly in config.json:

{
  "maxJSVMs": 5
}

Five remains the default fallback if the setting is omitted or misconfigured.

Raising this isn't a magic button that makes your node twice as fast. It’s an operator tradeoff: bumping the VM count gives a heavily loaded node more execution headroom for concurrent tasks, but it also increases your memory footprint once that pool is spun up. If you're on a memory-constrained box, you'll want to leave this alone or even tune it down; if you have plenty of RAM and run a busy node, you now have the freedom to adjust it.

MongoDB Connection Pool

The node now also lets you define explicit connection pool settings for MongoDB:

{
  "databasePool": {
    "maxPoolSize": 20,
    "minPoolSize": 2,
    "maxIdleTimeMS": 30000,
    "waitQueueTimeoutMS": 10000
  }
}

Here is what these control:

maxPoolSize: The maximum number of concurrent MongoDB connections in the pool.
minPoolSize: The minimum baseline of connections to keep open.
maxIdleTimeMS: How long an idle connection can sit before being closed.
waitQueueTimeoutMS: How long an operation will wait for an available connection before timing out.

If you don't specify databasePool, the MongoDB driver falls back to its standard defaults.

This flexibility matters because different node roles have completely different workloads. A dedicated witness node usually wants a lean, conservative pool with minimal overhead. On the other hand, a public RPC node fielding dozens of queries alongside block processing can easily starve for database connections if it's stuck with default limits.

Knobs B: Cutting Out Pipeline Latency

Where Knobs A was about configuration, Knobs B tackled two internal bottlenecks in the block-processing path that were quietly wasting time.

Batching Transaction-Index Writes

Every time the node commits a sidechain block, it generates transaction-index records so historical lookups and explorer queries can find them later. Historically, the code iterated through the block and inserted these records one by one:

insertOne()
insertOne()
insertOne()
...

Each insert meant another round-trip through the MongoDB driver. For blocks with lots of transactions, that back-and-forth adds noticeable latency.

Now, the node collects all index records for the block and flushes them in a single insertMany() call. I kept the insert explicitly ordered (ordered: true) because transaction indexes encode positions within the block, and keeping that guarantee crystal clear in the code makes life much easier for reviewers. Also, if a block happens to have zero transactions, it skips the call entirely rather than firing off an empty array.

Pre-warming the VM Pool on First Execution

With maxJSVMs now configurable, we also revisited how and when those VMs get initialized.

Previously, isolates were created lazily one at a time as smart contracts trickled in. That meant early contract calls suffered allocation jitter while spinning up new VMs on demand.

Read the full post

Private vs Public Repos - Learning about GitHub

ecoinstant — Thu, 24 Sep 2026 12:54:54 GMT

Keep tabs with the earlier pieces in this series: How I use AI to build things on HIVE and I created an opinionated Price Feed Widget and Got Blocked by Google.

If you have been following along, we have been reviewing exactly the "how" - including tips, tricks and detours - of working with "AI" to build things. Its a non-linear path, but we do have the tools, and its not usually all that hard (although it might be outside our comfort zone).

A nice update first - our work from the last post worked! The site is not marked as dangerous social engineering anymore :)

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23u5Zbp6sYTUUHCGpKoBXpm3orJz9W1WujvLxFjD78rQVc5ESnhjLHJepij4MjyeXqSKY.png)

So let's get back to our series - while writing this I stumbled upon a new proposal with an old conversation about open source, sharing code and "where does the value live?".

Topical - because today we are going to talk about Public and Private repos! And make sure to keep an eye on the HIVE Thrive Playlist because @meno, @buttcoins and I recently had a great show talking about this topic, and it's next on my upload list - and it even had @acidyo popping on to chat with us as well and discuss his efforts and intentions around the AI sponsorships.

But let's get down to our lesson today:

Why almost anything starts private

The honest case for a private repo: unfinished opinions, business logic, embarrassing commit history, not wanting to defend half-baked decisions in public "yet" - these are real decisions that have big consequences especially depending on the project.

Let's tie this back directly to the "opinionated" price feed widget from the previous post — privacy as the space where an opinion gets to be wrong before it's public.

My goal in making the widget in the first place was "two-fold" - which in open source just means: I want it to serve my need FIRST - and if it serves anyone else's needs then that is even better. Now that its serving my needs just fine - we can double back and ask Claude about the steps of making such a private repo public - and the first step is to "check".

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23tGVQuTM1uP9Qa91STDddpwNKmuHKXWxiMH39dPp1RyGuoAahLLGdCzofb1eufULp91n.png)

Always Check First - Public is PUBLIC

You agent knows (more or less) what to check - and I was able to follow along. But just out of curiousity, after we were done, I asked - "Hey, what are the steps to ensure that this repository is actually ready to be public?"

And you know what Claude said? "Great question Eco."

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23tkfTp7hN5sTadHxJpTjhDznyPvBGo3awrCdzujm4rpHXNBjmCdEUZLvQQT4p1rJVuC8.png)

Let's check back with Claude and ask - What did we just do and why?

What we checked, and why - by Claude

1. Git history for secrets

We ran git log --all -p | grep -iE "api[_-]?key|secret|password|..." across every commit, not just the current files. This matters because a public GitHub repo exposes its entire history, forever — if a credential was ever committed and later deleted, it's still sitting in an old commit anyone can git log into. We found nothing, and the repo only had one commit to begin with, which made this an easy pass.

2. .gitignore coverage

We confirmed config.yaml, .env, and *.db were already excluded. The distinction: config.example.yaml (committed, generic, safe) vs. config.yaml (your real node URLs, real tokens, never committed). This is the difference between a template and your actual deployment.

3. Does the code do what the docs claim?

This was the biggest finding — the README and pyproject.toml advertised PostgreSQL and MongoDB storage backends that were never actually written. Anyone who tried database_url: "postgresql://..." would've hit a crash, not the graceful error the code implied. For a private repo only you use, that's a TODO. For a public repo, that's a trust problem on day one — especially awkward for a project whose whole pitch (the "opinionated" section) is "we tell you exactly what we're doing." We removed the false claims rather than rush the implementations.

Read the full post

Helping Hive Engine Nodes Catch Up Without Getting Too Clever

thecrazygm — Thu, 17 Sep 2026 15:11:09 GMT

Hey everyone,

I have been working through the next small performance bundle for the Hive-Engine node, and this one is about the part of the node that fetches Hive blocks.

The short version is:

I added opt-in adaptive fetch concurrency and dynamic lookahead buffering, tested it on my custom witness setup, and opened the changes toward the QA branch.

Making the node a little less stubborn when it has some catching up to do.

The Problem

The streamer had two fixed values controlling how aggressively it fetched blocks:

how many block requests it could have in flight per RPC node
how many blocks it prefetched ahead of the current block

Those defaults are reasonable for a node sitting near the chain head. They are not necessarily the best settings for a node that is hundreds or thousands of blocks behind after maintenance, downtime, or a restart.

A catching-up node should be able to make progress without changing how blocks are processed.

What Changed

The new behavior is opt-in.

When adaptive QPS is enabled, the streamer watches the existing per-node failure and cooldown information:

healthy RPC nodes can use more fetch concurrency
one struggling node brings the setting back to the configured baseline
multiple struggling nodes cause a more conservative reduction
the healthy-node ceiling is explicitly capped in configuration

I am calling this QPS because that is the existing configuration name, but technically this is a per-node in-flight request limit rather than a precise requests-per-second meter.

The lookahead buffer now adapts to sync lag as well:

5 blocks when the node is close to the head
20 blocks while catching up
up to a configured maximum when it is far behind

The defaults remain unchanged unless an operator enables the new settings.

This is important because existing nodes should not suddenly decide to behave differently just because the code was updated.

The Config I Tested

For the live test, I used settings shaped like this:

{
  "maxQps": 2,
  "adaptiveQps": true,
  "adaptiveQpsMax": 4,
  "lookaheadBufferSize": 15,
  "dynamicLookaheadBuffer": true,
  "dynamicLookaheadBufferMaxSize": 50
}

The ceiling is there on purpose. Healthy RPC nodes are not an invitation to send an unlimited amount of traffic at public endpoints.

The Test

I let my node fall roughly 300 Hive blocks behind and watched it catch up.

Once the transition logging was made visible, the journal showed:

Streamer QPS changed to 4
Streamer lookahead buffer changed to 20

The node then worked its way back toward the Hive head. Sidechain blocks continued to advance, and the database and block hashes matched between the main reference values and the locally produced values.

Eventually the lag returned to zero.

One Honest Caveat

There was a transient MongoDB NoSuchTransaction error during one of the restarts. The service remained technically active, but block processing stalled until a second restart recovered it.

I am not treating that as proof that the adaptive fetch code caused it. I have seen this same kind of restart/session behavior before this bundle. Still, it is worth mentioning because production testing should include the ugly bits, not just the clean screenshots.

What This Does Not Change

This bundle changes fetch scheduling, not state transition logic.

It does not change:

smart contract execution
transaction ordering
block hashing
database state rules
witness consensus behavior

The goal is simply to get the right blocks into the existing processing pipeline more efficiently while backing off when the RPC environment looks unhealthy.

The Outcome

The code is now in a PR prepared for QA branch.

The live test node caught up from roughly 300 blocks behind, reported the expected adaptive settings, and returned to the chain head without hash divergence in the sampled blocks.

As always,
Michael Garcia a.k.a. TheCrazyGM

Keeping Pascal Alive: Patching NVIDIA 580 DKMS for Linux Kernel 7.2+

thecrazygm — Fri, 11 Sep 2026 13:02:00 GMT

Hey everyone,

If you are running a Linux workstation or server with a Pascal-generation GPU (like a GTX 1060, 1070, 1080, or 1080 Ti) alongside bleeding-edge kernels, you might have hit a brick wall recently.

A few days ago, XanMod pushed out Linux kernel 7.2.4. As usual, apt upgrade grabbed the new kernel and headers, triggered DKMS, and immediately blew up with:

Error! Bad return status for module build on kernel: 7.2.4-x64v3-xanmod1 (x86_64)
Consult /var/lib/dkms/nvidia/580.142/build/make.log for more information.

No module built, no driver signed, and an unbootable graphical session waiting on the other side of a reboot.

If you are running modern cards (RTX 20-series and newer), the standard advice is simple: just bump to the latest driver branch. But if you are holding onto Pascal silicon, that option does not exist.

Here is what broke in kernel 7.2, why legacy drivers are caught in the crossfire, and how to patch the nvidia-580 source to get your modules compiling and running cleanly.

The Hardware Dilemma: The Pascal Trap

First, some context on why this is even a problem.

NVIDIA officially dropped support for Pascal GPUs starting in the 595 driver branch. If you install 595 with a GTX 1080, the driver loads, acknowledges the card's existence, and explicitly refuses to initialize it.

That means anyone on Pascal is effectively pinned to the legacy 580.xx branch.

In an ideal world, when a new major kernel drops, NVIDIA backports compatibility patches to all active legacy branches, distro maintainers package them up, and everything "just works."

In the real world, upstream Linux kernel refactoring moves fast, XanMod and Arch track mainline closely, and legacy proprietary driver packages lag behind. If you want to run the newest kernel right now, you have to patch the driver source yourself.

What Broke in Linux 7.2

Digging through /var/lib/dkms/nvidia/580.142/build/make.log revealed two distinct breaking changes introduced in Linux 7.2:

1. `strncpy` Was Completely Removed

The Linux kernel has been slowly deprecating unsafe string functions for years in favor of strscpy. In Linux 7.2, kernel developers finally pulled the trigger: strncpy was purged entirely from include/linux/string.h and the kernel's exported symbols.

Unfortunately, nvidia-580.142 still has calls to strncpy scattered across multiple components: core driver code, display modesetting, and the Unified Virtual Memory (nvidia-uvm) module. With the kernel header no longer declaring the prototype, the compiler treats it as an error or fails at link time.

2. DRM Atomic State Was Renamed to Atomic Commit

The Direct Rendering Manager (DRM) subsystem in Linux 7.2 underwent a refactor around atomic modesetting. Specifically:

struct drm_atomic_state was renamed to struct drm_atomic_commit.
The corresponding state management functions (drm_atomic_state_alloc, drm_atomic_state_clear, drm_atomic_state_put, etc.) were renamed to match.

The NVIDIA driver uses a script called conftest.sh to probe the kernel headers at build time and determine which function signatures and structures are supported. The probe checks whether drm_plane_helper_funcs.atomic_check and drm_crtc_helper_funcs.atomic_check accept a struct drm_atomic_state * argument.

Because kernel 7.2 changed the argument type to struct drm_atomic_commit *, the conftest check failed. DKMS decided those arguments were missing entirely, leaving #undef NV_DRM_PLANE_ATOMIC_CHECK_HAS_ATOMIC_STATE_ARG and #undef NV_DRM_CRTC_ATOMIC_CHECK_HAS_ATOMIC_STATE_ARG. When the driver attempted to compile nvidia-drm, the function prototypes mismatched and compilation halted.

(Note: If you are upgrading across multiple kernel milestones, Linux 7.0 and 7.1 also dropped the legacy Device Tree header <linux/of_gpio.h>, which requires its own small stub. I will include that below for completeness).

The Fixes

To fix this, we need to apply two targeted patches directly to the source directory in /usr/src/nvidia-580.142/.

Patch 1: Providing an Inline `strncpy` Fallback

Instead of patching dozens of individual C files across the driver, the cleanest solution is to inject an inline implementation into a header included by every sub-module.

The compatibility header common/inc/nv-time.h is unconditionally included by the core driver, modeset, DRM, and UVM.

Open the file:

sudo nvim /usr/src/nvidia-580.142/common/inc/nv-time.h

Jump to the bottom of the file. Directly before the final #endif // __NV_TIME_H__, add:

#include <linux/version.h>
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(7, 2, 0))
static inline char *strncpy(char *dest, const char *src, size_t count)
{
    char *tmp = dest;
    while (count) {
        if ((*tmp = *src) != 0)
            src++;
        tmp++;
        count--;
    }
    return dest;
}
#endif

Read the full post

I created an opinionated price feed widget - and got blocked by Google

ecoinstant — Thu, 03 Sep 2026 18:30:39 GMT

Please see my previous "building on HIVE" post How I use AI to "Build Things on HIVE" to get caught up to date.

While working on this story, I stumbled through all sorts of exemplary complications that one faces when "building on HIVE" - so today we get a grab bag of lessons learned and being learned.

"It all fits together" (in your head)

So our site today happens to be a grab-bag of experimental ideas all its own - at once a Colombian operating entity (S.A.S.), a hive-engine token, an experimental "front-end and onboarding platform", and loosely linked to other experimental work with standalone tools (https://tools.crypto-dreamr.com) and TTRPG gaming (https://thecrazygm.com), which I am sure will feature more as this series goes on.

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23uRLBGvnHH6bowioBNbXpuXdY1SrAm16NU5BcCLrpzT5pc3de3sJoQnNpsy5YjGgXEpx.png)

It turns out our https://ecobankdevelopment.com site is already public, I guess I didn't know this - but probably after our experimental attempt with DHF funding on a platform of "yourFrontend / yourBackend" - and a few years of actually being "HIVE travelling ~~salesman~~onboarders" - we began exploring deeper and more sophisticated onboarding "optional solutions" directly inside our work with Ecological Restoration.

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23wMS5MAsHe7F6jnoqtuE6TYPQ2qRNuZt9hP2iVY7cjAkNxB263uufk6LKgn3NDHKHa8C.png) Easily found with [TAO image search tool](https://tools.crypto-dreamr.com/tao?username=ecoinstant&tag_filter=&community_filter=&title_filter=yourBackend&language=&sort_order=desc&start_date=2024-01-20&end_date=2026-09-03)

This Repository is Public

https://github.com/TheCrazyGM/ecobank

I insist this post started by talking about an opinionated price feed widget! It turns out that the original widget mock-up isn't even public repository (but that's the subject of the next post now... such is life), but our fascinating rabbit hole here will only let us stop to contemplate the "opinionated" decision-making framework - in a world of "open data" - opinions are valuable!

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/48GCWs4r4jqKehaPN5o5Di3c92so7RRGGJQe2Vb5whYho2BKJq2vufoFMBgaMgJuxU.png)

I have an opinion

If I learned anything from our experimental DHF shenanigans, its that everyone has an opinion. You don't have to like it, you might not agree with it, you probably don't have time to rebutt "all of it" (pick your battles), but now I'm on that DHF drip with @acidyo and I am set out to prove one of my opinions - "making posts about what you (we) do is important, especially in "development", and not doing so - considering HIVE's nature - is a sociological crime".

Yes posting is hard - and its a separate skill set you might say than "development".

And beyond that - development is non-linear. It turns out - Google has an opinion too!

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23tRvDeMYDNt4KRf1m5BeYYmxQTziry4duvg5PXK4SM1UNpwPKSuUZpTTWdq5P4RQrQwL.png)

Claude, I have a problem - and I need your help

So the first thing you can do when "things happen" is talk to your agent. Talk to your agent and make a plan - this is the way. The modern way:

Please explain this, what is the scope?
Let's make a plan to address this - what are the options?
What are the tradeoffs - pros and cons?

And soon enough you will be "proceeding step by step":

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23swigmzpSYsDj6PG9Z2hb1xUgmSAU2hwbW9oaX3Usu4woyR48UV7ze1Lox2xjQ2CzggT.png)

https://github.com/TheCrazyGM/ecobank/pull/18

You can review the Pull Request yourself - check the commit lists - read the comments. Github isn't an alien planet - but it can feel that way at first.

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23t76buN7RTPfDpacbpZ7thnoex79KWswMXjNTgoYLjYLz6FxMfZHHcyLjtApnUmFUiGs.png)

Group onboarding

While I have explained Who is this for? and tried to break down the Group Onboarding Strategy in the past - I'm not convinced anyone actually noticed. But now that I'm getting the DHF bucks, prepare for more explanations and efforts to break down this strategy and techniques more fully.

"We need these things for our business", maybe others will too. And we are happy to help - including recieving feedback, issues and PRs. The last grab-bag item today is about "collaborators" - this is Open Source after all!

Read the full post

Making Hive-Engine Nodes Do Less Waiting

thecrazygm — Tue, 25 Aug 2026 10:35:06 GMT

I have been continuing the small, careful performance work on the Hive-Engine node.

This time the change is less about adding a new operator setting and more about removing two bits of avoidable waiting from the normal path.

The short version is:

Transaction index writes are now batched, and the JavaScript VM pool is warmed up once on first use.

But the node has now been running this branch on a live witness for more than 72 hours, and it has been doing very well.

The First Part: Fewer MongoDB Writes

When a sidechain block is saved, the node also creates small transaction-index documents so it can find transaction information later.

Previously, it wrote those documents one at a time:

insertOne()
insertOne()
insertOne()
...

That works, but every individual insert is another trip through the MongoDB driver.

The change builds the complete set of transaction-index documents for the block and sends them with one insertMany() call instead.

The insert is explicitly ordered.

That matters because this is a consensus-adjacent codebase, and the transaction indexes contain the transaction positions within the block. I did not want to make a reviewer infer that ordering was still intentional, so the code says ordered: true directly.

Empty blocks are handled separately too. The node does not call insertMany([]) for a block with no transactions.

The Second Part: Warming the VM Pool

Hive-Engine runs smart contract code inside isolated JavaScript virtual machines.

The node already had a configurable maxJSVMs setting from the previous work. Before this change, those isolates were created one at a time as contract execution needed them.

That meant the first contract execution after startup paid the allocation cost.

When the first contract needs to run, the node allocates the configured VM pool in one eager-once warmup. The first contract still runs normally, and later executions can reuse the already-created pool.

So the behavior is:

no VM allocation for a node that never executes contracts
one pool warmup on the first contract execution
reuse afterward
the existing maxJSVMs value remains the limit

Why These Two Changes Together?

The original proposal contains much bigger ideas: caching, faster sync, snapshots, lite-node improvements, RPC changes, and dependency upgrades.

Those are still interesting, but the first goal was to build a contribution that is easy to explain and easy to review.

The safety claim for this bundle is simple:

The node processes the same transactions in the same order. It just batches one database write pattern and moves VM allocation to a predictable one-time warmup.

Testing It

I added focused tests for the transaction batching behavior:

the generated documents preserve block order
ordered: true is passed
the active MongoDB session is preserved
empty batches do not issue an insert

The focused database tests passed, and the Smart Contracts suite passed all 25 tests under Node 22.

The Live Test

After merging the branch into my custom Hive-Engine node setup, I put it on a live witness node.

It has now been running for more than 72 hours without a recurring issue.

Where It Is

The branch is here:

feature/knobs-b-batching-vm-prewarm

The commit is 6e0c24d.

The next step is upstream review.

I am especially interested in feedback on the VM memory tradeoff. Prewarming the configured pool makes first-use timing more predictable, but a larger pool also means more memory is committed sooner once contracts begin executing.

That is the sort of tradeoff that should be visible to operators, not hidden behind a vague performance claim.

For now, though, the live result is good.

A little less database chatter. A predictable VM warmup. The same processing order.

Nothing fancy.

As always,
Michael Garcia a.k.a. TheCrazyGM

How I use "ai" to build things (on HIVE)

ecoinstant — Mon, 24 Aug 2026 11:53:57 GMT

Warm greetings to all readers! I recently applied to get some money from @acidyo's Hive development fund - and the money came through! Suddenly - I am under pressure to perform on behalf of HIVE!

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23tkfzn6nTPSbAUpxgkgZDmpN62cfPpb1i3BpcRiGXrSTEgx5HDPZrtAr6RhXpQHRQ8h1.png)

Luckily - myself and my team and many of the people I surround myself with - we have been "building on HIVE" for a long time - most of our ideas are tied into HIVE in one way or another. I just need to figure out how to "show it".

Show your work

This is actually the main reason I joined this quest - what pushed me over the line to apply - I was disappointed in the fact that a previous iteration ran by deathwing did not result in any (that I noticed) follow up posts. As a sociologist myself, this is a grievous error on what could have been a great experiment (hopefully this doesn't turn into the new HIVE motto).

So "showing my work" is the whole point, and now since somebody managed a DHF proposal and sent me a few of those forbidden HBDs - I am morally obligated to take a shot at it. I have no one to blame or cheer but myself - so let's cheer me on as I get started.

Where to begin?

I have been contemplating my experience on such a social chain, I actually got my start making "tutorial-style" posts - about how to use markdown and other semi-technical features of a blockchain that was then known as "steem". Crypto framed my journey from lowly tech-writer to full blown product manager, and now AI is eating everyone's lunch and the PM's reign supreme. Managing ai agents isn't actually "easy" - its just verbose, and still requires a lot of finessing to make useful - ironically similar skill sets to dealing with "devs" and "clients" aka "people".

So I thought it might be relevent, historically appropriate, and actually needed to start a tutorial about "how" to actually use these new generation of tools to "build on HIVE", as is popular to shout about these days.

Step 1 - Get an Agent

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23tkjzWUsvSjuJFkFuzngarspC29DfL9LvN1ysbKAyBsWaZd6rg1UWYcaPoyaKDneAcsZ.png)

In this series we will be using "Claude" in its "Claude Code" version - but you can use any one of them. It sounds funny - they are not people (they act like people) - but they all have different personalities, its true. There are other "non-Claude" agents, many even - and you can use any of them.

If you use google or chat-gpt - they have the exact same functionalities, just replace "claude code setup" with your version's set up.

Step 2 - Getting Setup

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23t74yRdK2Xyn4TL58gQxZa7puhEHRNwcC2hF9e2Y8Hd1xvLAj42X4G5D6d2xVHVK1usZ.png)

When I first tried out "ai", I got about this far. I can ask it anything here - and if I ask it to make me some code it would, and spit it out at me. But this isn't "building", and I didn't know how to get further. You could ask about recipes, or write a book, or get a tutorial like explanation....

Wait....

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23tGTdoY2cGsn1CF9aHwQRDFA3LfmkBGnfKREYUfBHbzMjJhCaAzXTTwhEcnPhLpQxNFT.png)

It seems the world has changed since I last wrote tutorials. Suffice it to say - you probably should be asking agents about "how" to do things. The limit is knowing how to ask, or what to ask about - for example, knowing that for windows computers - you probably should be using VSC - is something you might not know.

Use VSC (download it) - its by microsoft so it works in windows
Install your agents' local piece
Connect both through login

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23t7BQ3z9Q7My3E78z9UvsXFnuJHbV4QFexoTcaxtoSkEBEf313o3MzvsdCwgkRRqA6ME.png)

"The payoff line: "That's it. Both links are done. Everything from here is the same chat you already know — you're just having the conversation next to your actual files instead of in a browser tab."

Claude Sonnet, 2026

Step 3: Models and Efforts

We have gone as far as we can without tackling the "elephant in the room" - These tools cost Money! Like yes, dollars and cents they will charge you money and take it out of your bank account and then you cannot use it for anything else. And that distinction starts with models and their efforts.

![image.png](https://files.peakd.com/file/peakd-hive/ecoinstant/23swib1P28zCPLv2R96FtLhFFoBZhxTuFgAWPD4CsZhrw7R8jc3o3h2M8vwY2THz9WSv6.png)

So for Claude there are currently 3 model options, 3 "personalities" for you to chose from - from cheap to expensive - Sonnet, Opus and Fable.

Step 4 - Start with Sonnet

Read the full post

I am okay! Reporting safe after heavy earthquake in Colombia

ecoinstant — Wed, 12 Aug 2026 02:08:12 GMT

I am okay! We are okay, my television fell off the dresser, and many other things did fall on the floor - during an incredible earthquake that we definitely did feel.

Here is a picture of my garage, I'm not sure how much of the mess it to blame on the earthquake.

I keep busy, working on a number of projects - including but not limited to - being a land owner and farmer in a rural community of families in Colombia, called a "vereda".

Below you can see a picture of me "doing my part" of bringing high quality cobblestones from town to continue fixing up our road - which is now a hodge podge of various techniques all the way up to our front door, approximately one kilometer from the main road.

With great consistency we continue, and we are always improving our skills in "working together".

Luckily, we were outside when it started. It lasted about 2 minutes and it was surprisingly strong, the whole mountain shook and I watched my house on stilts, and I was quite impressed.

We are all fine, a plate did get broken - I still have to test the television, it might still work. But all in all we are lucky and happy and healthy, no major damages reported in our municipality either, Gracias a Dios.

Thanks for caring, Hive friends <3

hive-186392 community on Hive

PR #141: Letting Hive-Engine Lite Nodes Catch Up Before Cleaning House

The Problem: Housekeeping During a Fire

The New Configuration Knobs

Live Testing on a 19,000-Block Catch-Up

Designing for Failure: The Fallback Guardrail

Upgrading MongoDB 8 to 9: Why Systemd Refused to Start and How to Bridge the FCV Gap

The Symptoms: Exit Code 62 on Startup

Why Did This Happen? The Rapid Release Trap

The Hive-Engine Factor: Replica Sets Are Mandatory

Recap of the Useful Knobs for Hive-Engine Nodes

Knobs A: Un-hardcoding Useful Runtime Settings

JavaScript VM Pool Count

MongoDB Connection Pool

Knobs B: Cutting Out Pipeline Latency

Batching Transaction-Index Writes

Pre-warming the VM Pool on First Execution

Private vs Public Repos - Learning about GitHub

Why almost anything starts private

Always Check First - Public is PUBLIC

What we checked, and why - by Claude

1. Git history for secrets

2. .gitignore coverage

3. Does the code do what the docs claim?

Helping Hive Engine Nodes Catch Up Without Getting Too Clever

The Problem

What Changed

The Config I Tested

The Test

One Honest Caveat

What This Does Not Change

The Outcome

Keeping Pascal Alive: Patching NVIDIA 580 DKMS for Linux Kernel 7.2+

The Hardware Dilemma: The Pascal Trap

What Broke in Linux 7.2

1. strncpy Was Completely Removed

2. DRM Atomic State Was Renamed to Atomic Commit

The Fixes

Patch 1: Providing an Inline strncpy Fallback

I created an opinionated price feed widget - and got blocked by Google

"It all fits together" (in your head)

This Repository is Public

I have an opinion

Claude, I have a problem - and I need your help

https://github.com/TheCrazyGM/ecobank/pull/18

Group onboarding

Making Hive-Engine Nodes Do Less Waiting

The First Part: Fewer MongoDB Writes

The Second Part: Warming the VM Pool

Why These Two Changes Together?

Testing It

The Live Test

Where It Is

How I use "ai" to build things (on HIVE)

Show your work

Where to begin?

Step 1 - Get an Agent

Step 2 - Getting Setup

Step 3: Models and Efforts

Step 4 - Start with Sonnet

I am okay! Reporting safe after heavy earthquake in Colombia

Freedom and Friendship

1. `strncpy` Was Completely Removed

Patch 1: Providing an Inline `strncpy` Fallback