All You Need to Know About Polkadot v1.0.0: Key Features and its Overall Impact

Polkadot is a blockchain platform that utilizes Substrate as its foundational technology. Substrate provides the underlying architecture and building blocks for Polkadot’s relay chain and parachains. The modular nature of Substrate makes it well-suited for constructing complex, interoperable blockchain networks like Polkadot. Though crypto users are always eager to know something about the upcoming market trends, this blog sheds light on the latest Polkadot release v1.0.0, its key features, and the overall impact on the Polkadot builders. 

Polkadot Release v1.0.0 

The latest Polkadot release brings various changes and improvements across various pallets that offer enhanced functionality and several benefits to Polkadot builders. Here are some salient features offered in the Polkadot’s latest release: 

1. Gas Metering Shift in Pallet-Contracts

The contract pallet has undergone a gas metering transformation. Initially, the gas host function invocation was used to measure fuel consumption. The recent switch eliminates the need for instrumenting Wasm blobs and host function calls in metering blocks which results in improved storage and performance savings. Moreover, it speeds up fuel metering on the engine side and is very cost-effective for contract authors. 

Impact on Polkadot Builders 

Users of pallet-contract have to run a migration to accommodate these changes through the following steps: 

• Removes CodeStorage with all instrumented contract codes.
• Renames OwnerInfo into CodeInfo, which incurs moving it to another StorageMap.
• Deposits attached to it are refunded as the migration frees up a decent amount of storage. 

2. Society v2 Enhancements

Pallet-society has undergone significant changes such as modifying how society will work in regard to membership and voting of key members. The update includes revisions to storage items and types across the pallet, removing technical limitations on the number of members, and introducing member ranks using StorageMap. Users are encouraged to run the provided migration to ensure compatibility.

Impact on Polkadot Builders

The recent changes revamp the definition of storage items and types across the pallet. 

The number of members is no longer limited technically. 

– pub type Members<T: Config<I>, I: ‘static = ()> =

–    StorageValue<_, Vec<T::AccountId>, ValueQuery>; 

+ pub type Members<T: Config<I>, I: ‘static = ()> =

+    StorageMap<_, Twox64Concat, T::AccountId, MemberRecord, OptionQuery>;

3. Transaction Payment Pallet Updates

Transaction payment pallet modifications now consider Proof of Validity (PoV) size while calculating TargetedFeeAdjustment and transaction priority. It ensures more accurate and fair transaction fee adjustments based on the size of the proof.

Impact on Polkadot Builders

PoV size or proof_size is not something that needs to be taken into account for transactions on the Relay. An attacker would take advantage of this by filling a block with storage size and not paying a transaction fee that takes into account the proof_size.

4. Multi-Block Migrations in Pallet-Contracts

A multi-block migration framework has been introduced for the contracts pallet. This solves the challenge of performing large storage migrations during an upgrade, allowing migrations to occur across multiple blocks. Although currently available only for the contracts pallet, this framework will eventually extend to other parts of the FRAME. 

Impact on Polkadot Builders 

If you’re using pallet-contracts, you need to include this in your runtime configuration with your pending migrations (or () if none) or it will result in compilation failure.

To avoid compilation failure:

impl pallet_contracts::Config for Runtime {

  // .. snip

  type Migrations = ();

}

5. Pallet-Aura: Multiple Blocks per Slot

Pallet-aura, which plays a key role in block authoring, now offers the option to author multiple blocks within the same slot. This introduces flexibility in block production, allowing sequential blocks to be produced in a single slot. 

Impact on Polkadot builders

Polkadot builders using Aura consensus should note this breaking change and configure AllowMultipleBlocksPerSlot accordingly.

To avoid compilation failure:

impl pallet_aura::Config for Runtime {

  // .. snip

  type AllowMultipleBlocksPerSlot = ConstBool<false>;

}

6. NFT Minting Price Addition

For NFTs, a minting price has been added to pre-signed mint objects. Offchain minting gains added utility by including the mint price in the presigned mint data. This enhancement expands the possibilities for offchain minting use cases.

Impact on Builders 

This is a breaking change for the NFTs pallet as you can add a new field mint_price to the PreSignedMint struct:

pub struct PreSignedMint<CollectionId, ItemId, AccountId, Deadline, Balance> {

/// A collection of the item to be minted.

pub(super) collection: CollectionId,

/// Item’s ID.

pub(super) item: ItemId,

/// Additional item’s key-value attributes.

pub(super) attributes: Vec<(Vec<u8>, Vec<u8>)>,

/// Additional item’s metadata.

pub(super) metadata: Vec<u8>,

/// Restrict the claim to a particular account.

pub(super) only_account: Option<AccountId>,

/// A deadline for the signature.

pub(super) deadline: Deadline,

+       /// An optional price the claimer would need to pay for the mint.

+       pub(super) mint_price: Option<Balance>,

}

Conclusion

The Polkadot Release Analysis (PRA) introduces a range of impactful changes and improvements across various pallets, providing Polkadot builders with enhanced functionality, performance, and flexibility. From gas metering optimizations to multi-block migrations, these changes contribute to a more efficient and adaptable development environment on the Polkadot network. Those willing to know more about the Polkadot release updates must get in touch with a renowned  Substrate development company like Antier.