Experimental · v0.5.0-preview.5

Blockchain production readiness

Review offline replay, native signed-v2 devnet evidence and the remaining production gates.

Current candidates

ComponentCandidateRelease scope
ZBL SDK and Zebvixv0.5.0-preview.5Windows x64 internal preview
ZBL Studio AIv0.3.2Separate Windows x64 QA installer
ZCT contractsZCT v1 and receipt v1Local ZBR compilation, simulation and independent replay verification
Native ZBX deploymentJSON Program v1 and signed transaction v2Windows x64 compatibility candidate for authenticated local or private TLS networks
Historical offline ZBVM profileZBVM v1 and signed V3 envelopesOffline journal and all-or-nothing block replay against a trusted tip

The receipt guide describes the versioned meter and trust boundary. The SDK and Studio use the same receipt verification library. The browser compiler continues to produce ZCT artifacts for the offline target. For real validator execution, follow the native ZBX deployment walkthrough. Queue admission and the finalized validator receipt are separate states. ZBR fuel applies to offline ZCT replay. Validator gas applies to signed v2 execution.

The reviewed Windows contract candidate is pinned to ZBX commit de14a2624c365d5266d78cc0573ab9dd929533fa and CLI SHA-256 d4f817aede2000156c9d43eb848bacc02916f1bd4571f3f0a2dd8d67ef68ef08. The ZBX executable is a separate artifact. The local download page retains its existing immutable preview. Use the reviewed handoff manifest, bootstrap, executable and archive together for this compatibility candidate.

To test a fresh isolated Windows SDK home, set $artifacts to the handoff artifact directory and $manifest to its matching local manifest. These commands leave the current user PATH alone.

$env:ZEBVIX_HOME = Join-Path $env:TEMP ("zbl-contract-qa-" + [guid]::NewGuid().ToString("N"))
& (Join-Path $artifacts 'zebvix-bootstrap-0.5.0-preview.5.ps1') -Manifest $manifest -Artifact (Join-Path $artifacts 'zebvix-cli-0.5.0-preview.5-windows-x64.exe') -NoPath
if ($LASTEXITCODE -ne 0) { throw 'Bootstrap failed' }
$sdk = Join-Path $env:ZEBVIX_HOME 'bootstrap/0.5.0-preview.5/bin/zebvix.exe'
& $sdk install --version 0.5.0-preview.5 --manifest $manifest --artifact (Join-Path $artifacts 'zbl-sdk-0.5.0-preview.5-windows-x64.tar.gz')
if ($LASTEXITCODE -ne 0) { throw 'SDK installation failed' }
& $sdk --version

Use a fresh isolated home for another candidate that carries the same preview version.

Current native ZBX qualification

Four disposable local validators used TLS for peers and ingress RPC on chain 7834. The SDK compiled and source-verified PaymentVault, built signed-v2-compatible unsigned transactions, and delegated signing and authenticated submission to the native wallet CLI. Deployment, the funded call, the owner-approved upgrade and the post-upgrade call finalized successfully.

After RocksDB restart, all four validators agreed on seven finalized receipts and block headers. The recipient held 300 base units and the contract payment counter was 2. The signed envelope with an invalid signature failed admission. Insufficient funds, wrong owner and stale upgrade each finalized with a failure receipt. The incorrect genesis pin failed the native RPC handshake.

The Windows handoff archive passed 90 installed checks. The installed candidate passed seven native integration cases, including Counter and PaymentVault golden parity and byte-for-byte preservation of offline ZCT and replay receipts. The full SDK regression run passed 185 tests. Exact build and transaction hashes are recorded in the SDK source repository under docs/evidence/zbx-de14a26-qualification.json.

Historical Windows verification

  • The SDK Rust suite passed 186 tests. The bootstrap lifecycle ran separately against the packaged release CLI and passed 40 assertions and six controlled transport cases.
  • The packaged preview.5 SDK passed 90 installed checks. The preview.4 to preview.5 upgrade, failed activation rollback, executable output, and uninstall preservation were exercised in an isolated home. All 162 prior SDK files were preserved.
  • The Counter receipt replay produced state 42 and 36 ZBR fuel. Tests reject altered fuel, an unrelated artifact, an unsupported receipt version, an oversized receipt and output overwrite. A batch that exceeds its total fuel limit fails without emitting a receipt.
  • Studio v0.3.2 passed 45 isolated Windows installer assertions and three Rust tests. Studio and the bundled CLI agreed byte-for-byte on the replay receipt. Studio rejected overwrite and a forged meter. The full suite passed after correcting a test that inspected the editor before it had rendered. The verified installer matched the packaged frontend and installation report hashes.
  • The offline ZBVM harness replayed three committed records and passed nine journal integration checks. Its Rust test also rejected a forged receipt after the frame hash was recomputed. The harness verified the consumed ZBX source hashes before and after execution.
  • The block profile exercises signed contract deployment and calls at the block boundary. Its acceptance suite checks deterministic state and receipt commitments across four independent replays and rejects malformed or invalid histories. Block profile and verification scope

Production gates

GateStatusRequired evidence
Native signed-v2 production rolloutOpenQualify the approved production binary and network profile under operational load, review deployment authorization, and verify restart and recovery controls.
Publisher identityOpenUse a trusted release signer and authenticated manifest distribution. Verify signature enforcement and rollback on installed Windows clients.
Release operationOpenComplete license and security review, publish through an approved HTTPS release channel and rehearse withdrawal and recovery.
Cross-platform coverageOpenComplete native Linux ZBX compatibility, ARM64 runtime qualification and Linux Studio acceptance.
Production load and sandboxOpenMeasure compiler and runtime resource use under hostile inputs, establish process isolation, and validate concurrency and operational monitoring.

Windows internal QA is the candidate scope. Mainnet, stable public SDK distribution, and cross-platform Studio acceptance remain open.