TL;DR

  • The upgrade of Jackal’s chain software to the modern stack (SDK v0.47, IBC v7, wasmd v0.46) is going well (around 75% complete).
  • Most of the big structural work is done. The recent steps were largely deleting old code the new stack didn’t need. Over 200 lines removed so far.
  • Left on the list: one awkward file, some work needed around reward and fee maths, a few test-only bits … Then we’re onto the first full build and tests.
  • I’m not providing dates just yet (but its close). I’ll publish results of the tests soon.

Where we left off

My last update described the assessment that was done. The old chain was proven deterministic, toolchain working etc. I said the code upgrade itself was next, so here’s how it’s going.

How the upgrade actually progresses

It’s a long series of small jobs. Before each one we read the new framework’s actual source (before / after) to see what changed. Then each small edit is (a) checked, (b) committed and (c) written up in an upgrade jounal. The code isn’t supposed to compile yet. We’re deliberately rebuilding everything before we expect it to work, so a tree full of compile errors is the process working as expected - each error is resolved in turn and added to the journal.

The big areas

When Tendermint became CometBFT, a load of libraries moved. Same code, different naming conventions etc. Our copy was still calling the old names, so we repointed them, including the database layer that physically stores the chain. A test application the old SDK used to include had to be untangled too. To be honest its quite boring stuff, but it had to happen first, and it’s all test-side rather than affecting how the chain runs.

The fun bit: deleting things. The old stack was full of legacy plumbing the new framework has done away with. Old REST query endpoints, the old governance proposal wiring, the old message routing in all (six) of Jackal’s custom modules. The modern replacements were already wired in underneath, so the old stuff was simply binned. The last two steps were pure deletion. 200-odd lines out, nothing added. It’s mostly cleanup. And to be clear: every proposal type that worked before still works the new way. We’ll prove that properly in the testnet rehearsal later.

The rest is mechanical. ie. Renames the new SDK made, a new argument threaded through some test helpers, and stuff like that. The build log only shows the first error on each path, so instead we count the whole tree before every step rather than depend on the log.

And one thing I’ve deliberately left alone: an old compatibility pin still holding up a few legacy files. I’ll remove that later, with the files that depend on it.

What’s left

A short list. The biggest job is one file in the storage module’s command-line code, several different breaks in one place. The delicate one is a rename that runs through the reward and fee maths. That’s money, so every line gets checked against the reference before we touch it. A few test-only bits after that, then the first full build of the new stack. The milestone I promised last time. Honest caveat: every fix can reveal another layer underneath. The list grows as often as it shrinks.

Confidence?

Reasonably high. The structural work is done and proven. Several keeper packages build for the first time in this port, and a module test binary has finally compiled and run. The big unknown is always the next layer the build gate turns up. And the bet that all that assessment work would speed the port up? Holding so far.

What’s next

Clear the list, run the build, then replay the same test matrix from the assessment and publish the results. Then the full testnet rehearsal. Only after all of that passes does anything go near a governance proposal. The live chain hasn’t been touched at any point in this work, and it won’t be until all of it is proven.

No reset. Balances, staked JKL, names, history. All of it carries over.

— Simon (Sich), Orbital Alchemists