#4 – Upgrade Proposal: v0.2.2

Rejected

Proposal ID: 4

Type: Software Upgrade

Submit: 2025-09-22 10:02 UTC

Voting: 2025-09-22 10:02 UTC → 2025-09-24 10:02 UTC

Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d

Metadata: https://github.com/gonka-ai/gonka/blob/f0f3301dadae0a2f30bdc2968bebb21da81026f4/proposals/governance-artifacts/update-v0.2.2/README.md

Failed reason: proposal did not get enough votes to pass

View on gonka.gg

Upgrade Proposal: v0.2.2

Full Proposal

Full proposal — click to expand · Open in separate page →

Upgrade Proposal 1

This document outlines the proposed changes for the first on-chain software upgrade. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.

Upgrade Plan

This PR updates the code for the api and node services and modifies the container versions in deploy/join/docker-compose.yml.

The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, please refer to /docs/upgrades.md.

Existing participants are not required to upgrade their api and node containers. The updated container versions are intended for new participants who join after the on-chain upgrade is complete.

Proposed Process: 1. Active participants review this proposal on GitHub. 2. Once the PR is approved by a majority, a v0.2.2 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted. 3. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain.

Creating the release from this branch (instead of main) is intended to minimize the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new participants.

Testing

Testnet

The on-chain upgrade from version v0.2.0 to v0.2.2 has been successfully deployed and verified on the testnet.

We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.

Migration on real chain data

In addition to testnet validation, the migration logic is tested against a snapshot of mainnet data to ensure data integrity and a smooth transition. This procedure will be repeated immediately before the mainnet upgrade.

Changes

Exact token enforcement in Completion API (`3f49d869d9b4d70b0c0ac8d783fec65745978592`)

In the previous version, api nodes passed generated text in the enforced_str parameter during inference validation. In some cases, the tokenization of the generated text might produce a different token sequence than the one originally generated. This is a low-probability issue, but when it occurs during inference validation, it breaks the metric computation between artifacts. The network was protected from incorrect validation by reporting inferences with non-matching tokenization as always valid.

This commit switches to enforcing the exact sequence of tokens that was generated and the exact top-k candidates, and it enables strict validation of the matching sequence.

Potential vulnerability in `POST /v1/participants` (`2927b241616ba08ae596dc1e029746f6c219c443`)

The POST /v1/participants API endpoint had a potential vulnerability. When it was called with empty address and pubkey fields, they were automatically filled with the node's owner account data.

Now, this process is simplified, and these fields are checked explicitly. A transaction is recorded only when the address does not yet exist on-chain.

Prevent negative-coin panics in keeper flows (`f0ed9b331b2a60a88d34bdc04dc503f61e81ad67`)

This commit fixes possible panics caused by negative coin values. sdk.NewInt64Coin causes a panic if it receives a negative value. This change adds error checking for every instance where NewInt64Coin is used (except for a few in Genesis that can be ignored). It also adds a safe method for logging subaccount transactions to reduce the required boilerplate and moves from using uint64 in internal methods. In the future, uint64 should be used strictly at the edges (messages, APIs) only. The risk of 0 - 1 resulting in uint64.Max is real, and Go idioms generally avoid using unsigned integers.

Missed validations recovery before claim (`801299d4bac47e5267451bdbebb9f46c6bc4c3b1`)

Problem

During an epoch, a participant may legitimately miss validating some inferences due to network instability, hardware changes, or other temporary issues. Currently, once accounts are settled at an epoch transition, missed validations cannot be recovered. This leads to:

Gaps in inference validation coverage.
Potentially lower reputation and compute credit for participants.
Inconsistent incentives between those who missed validations for legitimate reasons and those who didn’t.
A risk that some invalid inferences remain undetected if they were missed by validators.

Solution

This change introduces a recovery mechanism that allows participants to "catch up" on missed validations after account settlement but before claiming their reward.

Now, before the actual claim, each participant: - Queries for any inferences it should have validated but did not. - Executes and submits any missed validations before submitting the claim transaction.

For such validations, participants receive validation credit (reputation / proof of compute) and still receive earned Bitcoin-style rewards. However, they do not receive a share of the work coin, since payment has already been settled.

If a late validation identifies an invalid inference: - Invalidation verification and voting still occur on the network. - If the inference is found to be invalid, the submitter's reputation is still penalized. However, the requester does not receive a refund, since funds have already been distributed and cannot be clawed back.

Further, the system might be improved by having participants perform regular validation recovery during the epoch and prohibiting validations after settlement entirely.

Additionally, this commit adds: - Validation will now be retried several times before giving up, in an attempt to reduce the need for recovering missed validations. - Proper filtering of models supported by a participant, to avoid attempting to validate models that are not supposed to be deployed on that participant's MLNode. This did not cause any errors previously but made the logic less clear.

On-chain MLNode versioning and partial upgrades (`b2ef4fbe355431ad31d72b22aa062dce4892bfbd`)

This commit introduces a mechanism for automatic on-chain upgrades of MLNode containers. The upgrade is enabled by:

Architecture Overview:

┌─────────────────┐    ┌──────────────┐    ┌─────────────────┐
│ decentralized-  │───▶│  ML Proxy    │───▶│ MLNode v3.0.8   │
│ api             │    │  (NGINX)     │    │ (old version)   │
└─────────────────┘    │              │    └─────────────────┘
                       │              │    ┌─────────────────┐
                       │              │───▶│ MLNode v3.0.10  │
                       └──────────────┘    │ (new version)   │
                                           └─────────────────┘

Key Changes:

MLNode version is now stored on-chain and managed by partial upgrades.
The api service fetches the version at startup and updates automatically when an upgrade height is reached.
The api stores the last-used MLNode version in its config. If the current version changes, it refreshes all MLNode clients and calls .stop() on the old version's clients.
Fixed a bug where partial upgrades were ignored because the Name field was empty.
Removed local version plan storage from the api config.
Refactored and stabilized testermint integration tests to reduce flakiness.
Adds an upgrade handler and migration for the on-chain upgrade.

Dynamic Docker address resolution for proxy (`2845b898bd48b7203bd7f3302781faf4f160f900`)

Dynamically resolves MLNode upstream in the NGINX template/entrypoint.
Updates deploy/join/nginx.conf and proxy scripts for container networks.
Improves robustness across host/container setups.

Fix: Additional check for nonce duplicates on-chain (`b7d7600ec49ced4dfbedf6c01305aa5205f8d78`)

The previous version had a bug where identical nonces were taken into account when a node's weight was computed. This fix ensures nonces are deduplicated before weights are assigned.

Fix: Preventing generation of nonce duplicates (`1ae494372cb216046ab25ee179e3c21f392c5329`)

Node.NodeNum and StartPoCNodeCommand.TotalNodes fields are used to guarantee a unique nonce sequence for each participant's MLNode. The previous version used len(nodesToDispatch) as the value for TotalNodes. At the same time, if a node is deleted and re-added in the same epoch, its NodeNum is determined by incrementing b.curMaxNodesNum. This can cause NodeNum to be greater than len(nodesToDispatch), which could break the uniqueness of nonce sequences.

This commit fixes this by using curMaxNodesNum as TotalNodes.

Proposals for new way to validation inference `dee011bfbc41f43cefde0c64b1efc6746976e01e`

Final Tally

Yes 0.1% (109) No 0.0% (0) Veto 99.9% (109,637) Abstain 0.0% (0) Total 109,746 votes

Messages

#	Type
1	`/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade`

Contract Details

[
  {
    "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade",
    "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33",
    "plan": {
      "name": "v0.2.2",
      "time": "0001-01-01T00:00:00Z",
      "height": "512000",
      "info": "{\n        \"binaries\": {\n            \"linux/amd64\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.2-upgrade/inferenced-amd64.zip?checksum=sha256:ef72ce742f545a6d14d76cf90f72f13cd786b09a7191bf6f1a88e05d865074c0\"\n        },\n        \"api_binaries\": {\n            \"linux/amd64\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.2-upgrade/decentralized-api-amd64.zip?checksum=sha256:19659fb65acb0d21118024771a292c7b1ba70fc0627364e0911552797009a3c9\"\n        }\n    }",
      "upgraded_client_state": null
    }
  }
]