Skip to content

Mrc20#5126

Draft
peterjah wants to merge 3 commits into
mainfrom
mrc20
Draft

Mrc20#5126
peterjah wants to merge 3 commits into
mainfrom
mrc20

Conversation

@peterjah

Copy link
Copy Markdown
Collaborator
  • document all added functions
  • try in sandbox /simulation/labnet
    • if part of node-launch, checked using the resync_check flag
  • unit tests on the added/changed features
    • make tests compile
    • make tests pass
  • add logs allowing easy debugging in case the changes caused problems
  • if the API has changed, update the API specification

peterjah and others added 2 commits July 22, 2026 13:23
WMAS pays, from its own locked MAS, for the datastore balance entry
created when transferring/approving to a fresh address (charged to the
executing SC in set_data_entry). WMAS is a widely-used singleton that
cannot be redeployed without forcing all holders/integrations to migrate.

This adds a one-time, versioning-gated irregular state change: at the
activation of MipComponent::Execution version WMAS_PATCH_EXEC_VERSION,
every node deterministically overwrites the WMAS bytecode with an audited
fixed build, in execute_slot (shared by candidate and final execution).

Why this is safe:
- bytecode is stored separately from datastore + coin balance, so all
  balances and locked MAS are preserved by the swap;
- the module cache is keyed by bytecode hash, so the new bytecode is
  recompiled on first use with no explicit invalidation;
- the change is part of the slot's ledger changes and thus of final
  state, so nodes bootstrapping after activation get the patched bytecode.

Note: coin transfers (e.g. WMAS.withdraw) are NOT affected by the drain:
transfer_coins funds a new address's creation cost out of the transferred
amount and fails if it is insufficient, never touching the SC balance.

Operational values to fill before enabling (loud TODOs):
- WMAS_ADDRESS: verified mainnet address;
- resources/wmas_patched.wasm: reproducible fixed build (empty here, so
  the crate builds while the patch stays inert; applying empty bytecode is
  refused as a fail-safe);
- register the activation MIP bumping MipComponent::Execution to
  WMAS_PATCH_EXEC_VERSION. Until then execution_component_version never
  reaches it and this code is inert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds MIP-0002-WMAS-BytecodePatch, bumping MipComponent::Execution to 2
(= WMAS_PATCH_EXEC_VERSION). This is the network-coordinated trigger for
the one-time WMAS bytecode override in massa-execution-worker: until this
MIP is active, execution_component_version never reaches 2 and the patch
code stays inert.

Only the Execution component is bumped (the patch flows through normal
ledger changes and does not alter the final-state format, so FinalState
is left unchanged).

TODO(release): the start/timeout/defined dates are placeholders (future,
so the MIP cannot activate prematurely). Set real dates only once
WMAS_ADDRESS and resources/wmas_patched.wasm are filled in.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replaces the `include_bytes!` from resources/wmas_patched.wasm with an
in-source `PATCHED_WMAS_BYTECODE` constant (wmas_bytecode.rs), so the patch
carries no external build artifact and the exact bytes are reviewable in
the source tree. The generated module records the source, length and
sha256 of the wasm for verification.

Also harden the activation path: wmas_address() now returns Option and the
hook skips (with a warning) unless BOTH a valid address and non-empty
bytecode are present, so a placeholder/misconfiguration can never panic or
apply a partial patch in consensus execution.

TODO(release): regenerate wmas_bytecode.rs from the reproducible, audited
build of the deployed WMAS contract and set WMAS_ADDRESS before enabling
the MIP.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant