Ushuaia protocol support (025) — PyTezos 3.19.0#400
Merged
Conversation
- Add Ushuaia protocol hash (PsUshuai9QapM5TGj1JpuVGkdxz5GykdnEvS6Rh8SUVrARvZLCY) - Update LATEST to Ushuaia, add to protocol_hashes and protocol_version dicts - Update Docker image to bakingbad/sandboxed-node:v25.0 - Add 025-PsUshuai-parameters with mainnet/sandbox/test JSON files - Add tz5 / ML-DSA-44 forge & parse support: - tz5 + mdpk/mdsk/mdesk/mdsig base58 prefixes in crypto/encoding.py - is_pkh accepts tz5 - forge_address/unforge_address tz5 address tag \x04 - Update Makefile sandbox-params target to 025-PsUshuai-parameters tz5 signing (ML-DSA-44) is deferred; forge/parse does not require it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- binder/Dockerfile: python:3.8-slim-buster -> python:3.12-slim-bookworm. requires-python is >=3.10, so the 3.8 base made `pip install /tmp/pytezos` fail on every Binder build of the Labs site. Earlier "Fix Binder workflow" commits only changed the trigger, never the failing image -- this is the actual root cause of that churn. - README.md, docs/source/quick_start.rst: bump documented Python from 3.8/3.9 to 3.10+ to match requires-python. - docs/source/quick_start.rst: replace dead mainnet-tezos.giganode.io RPC (host shut down, returns HTTP 526) with rpc.tzkt.io/mainnet. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Tezos renamed endorsement->attestation in Oxford and reworked consensus ops across Tenderbake/Paris/Seoul, but pytezos still only emitted the legacy Emmy `endorsement` (tag 0) and `endorsement_with_slot` (tag 10). Add the modern ops so pytezos can forge consensus operations for current protocols (through 025 Ushuaia): - rpc/kind.py: preattestation=20, attestation=21, attestation_with_dal=23, preattestations_aggregate=30, attestations_aggregate=31, and double_consensus_operation_evidence=2 (consensus ops in validation pass 0, evidence in pass 2). - operation/forge.py: forgers for the consensus content (slot|level|round|block_payload_hash [+ DAL]), the inlined consensus op, the BLS (pre)attestation aggregates, and the merged double-consensus evidence. The DAL bitset is signed Zarith (Data_encoding.z, per src/lib_base/bitset.ml in octez-v25.0) => forge_int, NOT forge_nat; for values >= 64 the two encodings diverge. - operation/content.py: attestation()/preattestation()/ double_consensus_operation_evidence() builders. Legacy endorsement* ops are kept for pre-Oxford protocols: no tag collision (0/10 vs 20/21/23/30/31), and tag 2 is reused only under the distinct double_consensus_operation_evidence kind. Adds tests/unit_tests/test_operation/test_consensus.py (14 tests), including a boundary test pinning the signed-Zarith DAL bitset (64 -> \x80\x01, not the unsigned \x40). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Bump version 3.18.0 -> 3.19.0 - Add CHANGELOG entry for 3.19.0 (Ushuaia 025, tz5 forge/parse, modern attestation consensus ops, v25.0 binaries) - Regenerate src/pytezos/rpc/docs.py from a live Ushuaia v25.0 node (rpc.ushuaianet.teztnets.com): adds sTEZ, DAL and BLS-aggregate RPCs - uv.lock refreshed for the new version Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Step 2a added tz5 to forge_address/unforge_address but NOT to forge_public_key/unforge_public_key, which stop at BLpk (tag \x03) and raise on `mdpk`. A tz5 reveal embeds an ML-DSA-44 public key (mdpk, 1312 B, tag \x04), so forge_reveal -> forge_public_key crashes for any tz5 account's first operation. These tests are intentionally RED until the forge_public_key / unforge_public_key fix (add `mdpk` -> tag \x04 + reverse-map entry) lands: - test_forge_address.py::TestForgePublicKey — mdpk round-trip + tag \x04. - test_forging.py::test_forge_reveal_with_tz5_account — full reveal forge. The suite is red on purpose (TDD red-first); the fix makes it green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Refresh uv.lock to latest compatible versions (37 packages, incl. cryptography 49, rpds-py CalVer, pytest 9.1.1, ruff 0.15.20, jupyter stack). Changelogs reviewed: no breaking changes reachable from pytezos; min-Python floor stays 3.10 (rpds-py 3.10 kept via marker split). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
forge_public_key/unforge_public_key stopped at BLpk (tag \x03), so a tz5 reveal (which embeds an mdpk ML-DSA-44 public key) raised "Unrecognized key type: #mdpk". Add the mdpk <-> tag \x04 branch, matching the tz5 public-key-hash tag scheme. Greens the GAP-1 tests. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Drop the now-false "RED until the fix lands" / "currently stop at BLpk" status notes from the tz5/mdpk forging tests (the fix has landed; they are green). Keep the evergreen "why" (reveals embed an mdpk pubkey forged via forge_public_key, tag \x04). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
kind.py and test_consensus.py pointed at docs/notes/attestation-mental-model.md, a dev note that was never committed (does not ship, file absent). Remove the dangling reference; keep the evergreen explanation of the Tenderbake/Oxford+ consensus-op rename. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The "Publish results" step (EnricoMi/publish-unit-test-result-action) fails the whole job when GitHub throttles its PR-lookup endpoint (HTTP 429), even though lint and tests passed. Mark it continue-on-error and grant the action the checks/pull-requests permissions it needs to use the API instead of falling back to unauthenticated scraping. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Bumps PyTezos to 3.19.0 with support for the Ushuaia (025) protocol (
PsUshuai9QapM5TGj1JpuVGkdxz5GykdnEvS6Rh8SUVrARvZLCY, Octez v25.0).Verified end-to-end against a live Ushuaia node (
rpc.ushuaianet.teztnets.com, v25.0 / commit187a915b): protocol hash matches, fullmake allgreen (lint + 1124 unit/contract/integration tests + 17 sandbox tests on the v25.0 node + docs build).Changes
Protocol
USHUAIAhash, setLATEST, register inprotocol_hashes/protocol_version(25)DOCKER_IMAGE = bakingbad/sandboxed-node:v25.0; Makefilesandbox-paramspath →025-PsUshuai-parameters025-PsUshuai-parameters/JSONs (mainnet / mainnet-with-chain-id / sandbox / test)protocol_version >= 24gate already covers 025 (header byte-identical to 024) — no change neededtz5 / ML-DSA-44
tz5,mdpk,mdsk,mdesk,mdsig(verified against Octez v25.0base58.ml)is_pkhrecognizestz5forge_address/unforge_addresstz5 address tag\x04forge_public_key/unforge_public_keymdpkpubkey tag\x04(needed for tz5 reveals)crypto/key.py) is deferred — forge/parse does not require itOther
attestation,preattestation,attestation_with_dal,attestations_aggregate/preattestations_aggregate, with DAL bitset forgingsrc/pytezos/rpc/docs.pyfrom the Ushuaia node (sTEZ, DAL, BLS-aggregate RPCs)uv lock --upgrade, 37 packages) — changelogs reviewed, no breaking changes reachable; min-Python stays 3.10CHANGELOG.mdentry for 3.19.0Test plan
make allgreen (lint, unit/contract/integration, sandbox vs live v25.0, docs)🤖 Generated with Claude Code