Polkadot Release Analysis: Polkadot stable2412

Ecosystem
2

Continued…

[S] [Pallet-Revive] update generic runtime types

PR: [pallet-revive] update generic runtime types by pgherveou · Pull Request #5608 · paritytech/polkadot-sdk · GitHub

Why is this important?

The goal of this PR is to refactor the Ext trait in a way that aligns the contract runtime’s generic types (e.g., BalanceOf<T>``, MomentOf) with Ethereum-native types like U256`. This change aims to improve interoperability between Substrate-based contracts and Ethereum by ensuring consistent encoding, decoding, and type handling.

Key Changes:

  1. Use of Ethereum Native Types:

    • Replaces BalanceOf<T> and MomentOf<T> with U256 in the Ext trait.
    • Ensures that all generic types used within contracts (e.g., block number, timestamp) align with Ethereum-native types.

  2. Enforcement of H256 for T::Hash:

    • Updates T::Hash in the Config trait to be a fixed type, H256, instead of a configurable type. This avoids potential issues arising from hash type inconsistencies across environments.

How does this impact Polkadot Builders?

Potential Impact on Builders:

• Runtime types for BalanceOf<T> and MomentOf<T> now must be explicitly converted to/from U256. This adds responsibility for overflow checks but simplifies interactions with contracts.

• Existing SCALE encoding/decoding logic for topics must be updated to work with the new packed memory layout.

This PR significantly improves interoperability and performance for Substrate-based contracts by refactoring generic runtime types to use Ethereum-native representations (U256 and packed topics).

Related Issue: #5574

[P] Pallet-XCM: added useful error logs

PR: https://github.com/paritytech/polkadot-sdk/pull/4982

Why is this important?

This PR introduces enhanced error logging to pallet-xcm for improved debugging and monitoring. It achieves this by:

  1. Adding detailed error logs where errors occur in pallet-xcm.

  2. Replacing the log crate with the tracing crate for structured and more effective logging.

These changes align with the broader objective of ensuring that errors in XCM (Cross-Consensus Messaging) execution are not ignored and are logged meaningfully for easier debugging.

How does this impact Polkadot Builders?

Builders can trace the exact source of an error and its context, thanks to detailed error messages and structured logs. Detailed logs with context and metadata improve monitoring, enabling quicker root-cause analysis in production environments.

These changes improve debugging and align the codebase with modern logging standards, making it easier to maintain and troubleshoot XCM-related functionality.

Related Issue: #2408

[S] Pallet-Child-Bounties index child bounty by parent bounty

PR: pallet-child-bounties index child bounty by parent bounty by davidk-pt · Pull Request #6255 · paritytech/polkadot-sdk · GitHub

Why is this important?

This PR restructures the child bounty indexing system to group child bounties under their respective parent bounties.

The new design ensures predictable indexing of child bounties within each parent, rather than relying on a globally unique identifier. This simplifies managing and querying child bounties.

By indexing child bounties within the scope of their parent bounty, the PR allows for batch operations, such as:
• Simultaneous creation of multiple child bounties under a parent.
• Approval of multiple child bounties within a single parent.

How does this impact Polkadot Builders?

1. Migration Support:

  • Builders implementing this change will need to use the provided V0ToV1ChildBountyIds storage item to map old child bounty IDs to the new structure.

  • Updating logic for interacting with the storage API, particularly for:

    • Retrieving child bounty descriptions (now from ChildBountyDescriptionsV1).
    • Iterating over child bounties using ParentTotalChildBounties.

2. Updated Account ID Derivation:

  • Child bounty account IDs now derive from PalletId + "cb" + bounty_id + child_id rather than PalletId + "cb" + child_id. Builders will need to update their code to use this new derivation logic to ensure account generation consistency.

3. Refactoring Existing Code:

  • Code that relied on ChildBountyCount or directly accessed child bounty IDs will need to be refactored to align with the new parent-child grouping.

4. Enhanced Indexing:

  • With the new schema, builders can implement more efficient retrieval and filtering mechanisms, as child bounties are now grouped by parent bounty.

Related Issue: #5929

[S] [Pallet-Revive] implement the block hash API

PR: pallet-child-bounties index child bounty by parent bounty by davidk-pt · Pull Request #6255 · paritytech/polkadot-sdk · GitHub

Why is this important?

This PR:

  1. Standardizes Block Hash Format:
  • By binding T::Hash to H256, this PR ensures that all block hashes in the runtime are represented using a fixed and well-known format, H256. This provides consistency and compatibility with other blockchain systems like Ethereum and other Substrate-based networks.
  1. Enhances Functionality with Block Hash API:
  • The new block hash API allows for:
    • Efficient storage and retrieval of block hashes for given block numbers.
    • Simplified interactions between external tools, smart contracts, or runtime modules that need access to historical block data.
  1. Improves Cross-Compatibility:
  • By standardizing on H256 and implementing a robust API, this PR improves the integration potential of the pallet with external chains and applications that use the H256 format, enhancing interoperability.

[S] [Pallet-Contracts] Remove riscv support

PR: [pallet-contracts] Remove riscv support by pgherveou · Pull Request #5665 · paritytech/polkadot-sdk · GitHub

Why is this important?

By removing RISC-V support from pallet-contracts, the codebase becomes more maintainable and focused. This reduces the complexity associated with supporting multiple architectures within a single pallet.

RISC-V support is now being handled by the newly forked pallet-revive, which can focus exclusively on the requirements and nuances of this architecture. This ensures better modularization and scalability for the ecosystem.

[S] Update Treasury to Support Relay Chain Block Number Provider

PR: https://github.com/paritytech/polkadot-sdk/pull/3970

Why is this important?

This PR modifies the Treasury pallet to make it compatible with parachains that do not produce blocks on a regular schedule. The focus is on enabling the treasury’s functionality to use the relay chain block number as a block provider.

Since parachains operating under the relay chain framework might not produce blocks monotonically, this PR introduces logic to handle cases where multiple spend periods elapse between blocks.

By adopting the relay chain block number as the reference and introducing logic to handle skipped spend periods, the treasury pallet now works correctly on parachains relying on irregular block schedules.

[S] [Pallet-Revive] move event topics in event’s body

PR: [pallet-revive] move event topics in event's body by pgherveou · Pull Request #5640 · paritytech/polkadot-sdk · GitHub

Why is this important?

This PR addresses the inefficiency of handling contract-emitted event topics in pallet-revive by moving the topics into the event’s body instead of treating them as separate indexed topics. This change is significant because it improves performance and reduces the cost associated with emitting contract events.

How does this impact Polkadot Builders?

Builders working with pallet-revive or any contract emitting events will see a more efficient event emission process. They will no longer need to manage event topics as separate indexed entities, and instead, all related metadata will be contained in the event body. This reduces the complexity of handling event data.

Related Issue: #5629

[S] [Pallet-Revive] Add chain ID to config an runtime API

PR: [pallet-revive] Add chain ID to config an runtime API by xermicus · Pull Request #5807 · paritytech/polkadot-sdk · GitHub

Why is this important?

This PR:

  1. Essential for EVM Compatibility:
  • The addition of the EVM chain ID to the runtime Config and API is a critical step for ensuring compatibility with Ethereum-based tools and frameworks. Chain IDs are a fundamental component of Ethereum’s transaction system, enabling differentiation between networks and preventing replay attacks.
  1. Addresses Compatibility Issues:
  • Fixes the issue where the ERC20 workspace in Remix (a popular Ethereum IDE) was failing to compile due to the missing chain_id function. This ensures that developers using Remix can work seamlessly with Substrate-based chains implementing this pallet.
  1. Improves Developer Experience:
  • By exposing the chain ID through a runtime API, this PR enables smart contracts deployed on Substrate-based chains to query the chain ID programmatically, enhancing functionality and interoperability with existing Ethereum contract libraries.

Related Issue: #44

[S] SolochainDefaultConfig: Use correct AccountData

PR: SolochainDefaultConfig: Use correct `AccountData` by bkchr · Pull Request #5941 · paritytech/polkadot-sdk · GitHub

Why is this important?

This PR:

  1. Fixes a Critical Misconfiguration:
  • The previous implementation of SolochainDefaultConfig mistakenly set AccountData to AccountInfo, creating recursive nesting of account data. This PR addresses the issue by defaulting AccountData to () (empty), which is a more logical and compatible configuration for most use cases.
  1. Avoids Potential Runtime Errors:
  • Recursive nesting of AccountData could lead to inefficiencies, undefined behavior, or runtime panics. Fixing this default prevents cascading issues in chains using SolochainDefaultConfig without custom overrides.

How does this impact Polkadot Builders?

  1. Default Behavior Adjustment:
  • Changes the default AccountData to (), simplifying the configuration for new users of SolochainDefaultConfig. Developers must explicitly override this default if their chain relies on AccountInfo.
  1. Migration Awareness:
  • Chains using the default SolochainDefaultConfig with AccountInfo will need to:
    • Perform a storage migration to adapt to the corrected AccountData.
    • Alternatively, manually override the AccountData type in their runtime configuration to retain compatibility.

Related Issue: #5922

[S] [Pallet-Revive] uapi: allow create1 equivalent calls

PR: [pallet-revive] uapi: allow create1 equivalent calls by xermicus · Pull Request #5701 · paritytech/polkadot-sdk · GitHub

Why is this important?

This PR:

  1. Expands Contract Creation Options:
  • By making the salt argument optional, this PR enables functionality similar to Ethereum’s CREATE opcode (referred to as create1 for distinction from CREATE2). This allows developers to deploy contracts without specifying a salt, simplifying certain use cases and aligning with Ethereum standards.
  1. Improves Compatibility with Ethereum Contracts:
  • Ethereum developers transitioning to Substrate-based chains expect features like CREATE and CREATE2 to work seamlessly. This change ensures the create1 functionality is available, enhancing compatibility with existing Ethereum contract workflows and tooling.
  1. Eases Migration of Existing Contracts:
  • Contracts written for Ethereum often utilize CREATE for deploying child contracts. This PR ensures such contracts can be deployed on Substrate-based chains with minimal modifications.

[S] [Pallet-Revive] Eth RPC integration

PR: https://github.com/paritytech/polkadot-sdk/pull/5866

Why is this important?

This PR integrates Ethereum RPC functionality into pallet-revive, enabling Substrate-based chains to process Ethereum transactions (eth_transact). This is crucial for providing compatibility with Ethereum’s ecosystem and tools, allowing dApps and users to interact with the chain in a familiar way.

Key Changes:

  1. New Pallet Call: eth_transact:
  • A new Call::eth_transact is introduced to handle unsigned Ethereum transactions.
  • This call acts as a wrapper to process Ethereum-style transactions. Valid transactions are routed to either:
    • Call::call: For executing a smart contract function.
    • Call::instantiate_with_code: For deploying a new contract.
  1. Custom UncheckedExtrinsic Struct:
  • This struct extends the generic UncheckedExtrinsic by adding functionality to handle eth_transact calls dispatched from an Ethereum JSON-RPC proxy.
  • Ensures Ethereum transactions can be processed efficiently without requiring a Substrate-style signature.
  1. Generated Types and Traits:
  • Implements necessary traits and types to facilitate JSON-RPC Ethereum proxy integration, including:
    • Type definitions for Ethereum transactions.
    • Support for converting between Ethereum and Substrate formats.
    • Traits for processing Ethereum-style RPC calls.

[S] Add missing events to Identity Pallet

PR: https://github.com/paritytech/polkadot-sdk/pull/6261

Why is this important?

By adding success events to the rename_sub and set_subs extrinsics in the identity pallet, this PR enhances observability for developers, making it easier to monitor and debug operations involving these extrinsics.

How does this impact Polkadot Builders?

  • rename_sub Extrinsic:

    • Emits an event after successfully renaming a sub-account.

  • set_subs Extrinsic:

    • Emits an event after successfully setting sub-accounts.

[S] [Pallet-Revive] Add balance_of syscyall for fetching foreign balances

PR: [pallet-revive] Add balance_of syscyall for fetching foreign balances by xermicus · Pull Request #5675 · paritytech/polkadot-sdk · GitHub

Why is this important?

This PR provides the ability to fetch the balance of any account via a syscall. This method corresponds directly to Ethereum’s BALANCE opcode and is a critical feature for compatibility.

Both balance (for the caller’s balance) and balance_of (for any account’s balance) now utilize a common method:

  • This avoids duplicating logic.
  • Prevents inefficiencies, such as unnecessary conversions between address formats (e.g., H160).

Contracts using pallet-revive can now leverage balance_of to fetch the balance of any account. This simplifies contract logic for use cases like token distribution, account validation, or financial modeling.

[S] [Pallet-Revive] last call return data API

PR: [pallet-revive] last call return data API by xermicus · Pull Request #5779 · paritytech/polkadot-sdk · GitHub

Why is this important?

This PR adds two new syscalls to [pallet-revive](pallet_revive - Rust that replicate the behavior of Ethereum’s EVM opcodes RETURNDATASIZE and RETURNDATACOPY:

  1. return_data_size:
  • Retrieves the size of the return data from the last executed contract call.
  1. return_data_copy:
  • Copies the return data from the last executed call into the contract’s memory.

This PR enhances Substrate’s pallet-revive by introducing EVM-compatible syscalls for handling return data. It optimizes memory usage by adopting a zero-copy approach and simplifies the logic by centralizing return data handling in Frame.

[P] [XCM-v5] implement RFC#122: InitiateTransfer can alias XCM original origin on destination

PR: [xcm-v5] implement RFC#122: InitiateTransfer can alias XCM original origin on destination by acatangiu · Pull Request #5971 · paritytech/polkadot-sdk · GitHub

Why is this important?

This PR enhances the InitiateTransfer instruction in XCM v5 to support aliasing the original origin across chains. This is achieved by adding the ability to preserve the original origin during a transfer using the preserve_origin flag.

  1. New Behavior for InitiateTransfer:

  • When preserve_origin: true is set in the InitiateTransfer instruction:

    • Instead of the usual ClearOrigin, the XCM message will include an AliasOrigin instruction.
    • This preserves the original sender’s origin (e.g., account ID or other identifiers) across chains, allowing the destination chain to recognize and act upon the original origin.
  1. Rules for Compatibility:

  • For the destination chain to support origin aliasing, the following conditions must be met:

    • Interior Location Aliasing: The destination chain must support aliasing interior locations (similar to DescendOrigin behavior).

    • AssetHub Alias Support: Chains like AssetHub must allow aliasing sibling parachain accounts or Ethereum accounts.

  • These configurations are controlled using the Aliasers setting, which supports adapters like:

    • AliasChildLocation
    • AliasOriginRootUsingFilter

[S] [Pallet-Revive] rework balance transfers

PR: [pallet-revive] rework balance transfers by xermicus · Pull Request #6187 · paritytech/polkadot-sdk · GitHub

Why is this important?

This PR:

  1. Improves Transparency for Contract Developers:
  • The change removes a hidden “corner case” for contract developers related to existential deposits (ED). Previously, when contracts transferred funds to non-existent accounts, the ED was implicitly deducted, leading to potentially unexpected behavior or failures. By transferring the ED from the call origin, this change makes the ED handling transparent and predictable.
  1. Aligns with EVM Behavior:
  • EVM-based blockchains charge for gas to ensure that transactions to non-existent accounts are handled consistently. This PR brings Substrate’s behavior more in line with the EVM, which simplifies cross-platform development and makes Substrate a more familiar environment for EVM developers.
  1. Simplifies Contract Development:
  • By removing the need for contract code to handle ED-related failures, this change reduces the complexity and edge cases contract developers need to manage. This can lead to fewer bugs, less complex code, and an easier developer experience.

[C, P] Added SetAssetClaimer Instruction to XCM v5

PR: Added SetAssetClaimer Instruction to XCM v5 by x3c41a · Pull Request #5585 · paritytech/polkadot-sdk · GitHub

Why is this important?

This PR introduces a new XCM instruction, SetAssetClaimer, to enhance the user experience around asset recovery on the Polkadot ecosystem. It addresses a significant pain point for users whose assets become trapped due to errors or misconfigured XCM calls. Previously, users had to rely on lengthy and cumbersome OpenGov processes to reclaim trapped assets. With this addition:

• Immediate Recovery Mechanism: Users can retrieve trapped assets directly without requiring governance intervention.

• Improved User Autonomy: The feature empowers users to resolve asset issues themselves, reducing dependence on external processes.

[S] Refactor pallets to V2 bench syntax

Why is this important?

In this release, several pallets have been refactored to adopt the updated V2 benchmarking syntax, ensuring more streamlined and maintainable benchmarking processes.

Related Issue: #6202

6 Likes