You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -256,7 +256,7 @@ First, you'll update the runtime's `Cargo.toml` file to include the Utility pall
256
256
1. Open the `runtime/Cargo.toml` file and locate the `[dependencies]` section. Add pallet-utility as one of the features for the `polkadot-sdk` dependency with the following line:
257
257
258
258
```toml hl_lines="4" title="runtime/Cargo.toml"
259
-
[dependencies]
259
+
260
260
...
261
261
polkadot-sdk = { workspace = true, features = [
262
262
"pallet-utility",
@@ -267,19 +267,17 @@ First, you'll update the runtime's `Cargo.toml` file to include the Utility pall
267
267
2. In the same `[dependencies]` section, add the custom pallet that you built from scratch with the following line:
3. In the `[features]` section, add the custom pallet to the `std` feature list:
276
276
277
277
```toml hl_lines="5" title="Cargo.toml"
278
-
[features]
279
-
default = ["std"]
280
-
std = [
278
+
281
279
...
282
-
"custom-pallet/std",
280
+
283
281
...
284
282
]
285
283
```
@@ -2590,53 +2588,13 @@ To build the smart contract, follow the steps below:
2590
2588
6. Add the getter and setter functions:
2591
2589
2592
2590
```solidity
2593
-
// SPDX-License-Identifier: MIT
2594
-
pragma solidity ^0.8.28;
2595
-
2596
-
contract Storage {
2597
-
// State variable to store our number
2598
-
uint256 private number;
2599
-
2600
-
// Event to notify when the number changes
2601
-
event NumberChanged(uint256 newNumber);
2602
-
2603
-
// Function to store a new number
2604
-
function store(uint256 newNumber) public {
2605
-
number = newNumber;
2606
-
emit NumberChanged(newNumber);
2607
-
}
2608
-
2609
-
// Function to retrieve the stored number
2610
-
function retrieve() public view returns (uint256) {
2611
-
return number;
2612
-
}
2613
-
}
2591
+
2614
2592
```
2615
2593
2616
2594
??? code "Complete Storage.sol contract"
2617
2595
2618
2596
```solidity title="Storage.sol"
2619
-
// SPDX-License-Identifier: MIT
2620
-
pragma solidity ^0.8.28;
2621
-
2622
-
contract Storage {
2623
-
// State variable to store our number
2624
-
uint256 private number;
2625
-
2626
-
// Event to notify when the number changes
2627
-
event NumberChanged(uint256 newNumber);
2628
-
2629
-
// Function to store a new number
2630
-
function store(uint256 newNumber) public {
2631
-
number = newNumber;
2632
-
emit NumberChanged(newNumber);
2633
-
}
2634
-
2635
-
// Function to retrieve the stored number
2636
-
function retrieve() public view returns (uint256) {
2637
-
return number;
2638
-
}
2639
-
}
2597
+
2640
2598
```
2641
2599
2642
2600
## Understanding the Code
@@ -3274,23 +3232,7 @@ To create the ERC-20 contract, you can follow the steps below:
3274
3232
3. Now, paste the following ERC-20 contract code into the editor:
3275
3233
3276
3234
```solidity title="MyToken.sol"
3277
-
// SPDX-License-Identifier: MIT
3278
-
// Compatible with OpenZeppelin Contracts ^5.0.0
3279
-
pragma solidity ^0.8.22;
3280
-
3281
-
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
3282
-
import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";
3283
-
3284
-
contract MyToken is ERC20, Ownable {
3285
-
constructor(address initialOwner)
3286
-
ERC20("MyToken", "MTK")
3287
-
Ownable(initialOwner)
3288
-
{}
3289
-
3290
-
function mint(address to, uint256 amount) public onlyOwner {
3291
-
_mint(to, amount);
3292
-
}
3293
-
}
3235
+
3294
3236
```
3295
3237
3296
3238
The key components of the code above are:
@@ -3608,26 +3550,7 @@ To create the NFT contract, you can follow the steps below:
3608
3550
3. Now, paste the following NFT contract code into the editor.
3609
3551
3610
3552
```solidity title="MyNFT.sol"
3611
-
// SPDX-License-Identifier: MIT
3612
-
// Compatible with OpenZeppelin Contracts ^5.0.0
3613
-
pragma solidity ^0.8.22;
3614
-
3615
-
import {ERC721} from "@openzeppelin/contracts/token/ERC721/ERC721.sol";
3616
-
import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";
3617
-
3618
-
contract MyToken is ERC721, Ownable {
3619
-
uint256 private _nextTokenId;
3620
-
3621
-
constructor(address initialOwner)
3622
-
ERC721("MyToken", "MTK")
3623
-
Ownable(initialOwner)
3624
-
{}
3625
-
3626
-
function safeMint(address to) public onlyOwner {
3627
-
uint256 tokenId = _nextTokenId++;
3628
-
_safeMint(to, tokenId);
3629
-
}
3630
-
}
3553
+
3631
3554
```
3632
3555
3633
3556
The key components of the code above are:
@@ -8190,16 +8113,7 @@ The [`Account` data type](https://paritytech.github.io/polkadot-sdk/master/frame
8190
8113
The code snippet below shows how accounts are defined:
8191
8114
8192
8115
```rs
8193
-
/// The full account information for a particular account ID.
8194
-
#[pallet::storage]
8195
-
#[pallet::getter(fn account)]
8196
-
pub type Account<T: Config> = StorageMap<
8197
-
_,
8198
-
Blake2_128Concat,
8199
-
T::AccountId,
8200
-
AccountInfo<T::Nonce, T::AccountData>,
8201
-
ValueQuery,
8202
-
>;
8116
+
8203
8117
```
8204
8118
8205
8119
The preceding code block defines a storage map named `Account`. The `StorageMap` is a type of on-chain storage that maps keys to values. In the `Account` map, the key is an account ID, and the value is the account's information. Here, `T` represents the generic parameter for the runtime configuration, which is defined by the pallet's configuration trait (`Config`).
@@ -8223,24 +8137,7 @@ For a detailed explanation of storage maps, see the [`StorageMap`](https://parit
8223
8137
The `AccountInfo` structure is another key element within the [System pallet](https://paritytech.github.io/polkadot-sdk/master/src/frame_system/lib.rs.html){target=\_blank}, providing more granular details about each account's state. This structure tracks vital data, such as the number of transactions and the account’s relationships with other modules.
/// The number of transactions this account has sent.
8230
-
pub nonce: Nonce,
8231
-
/// The number of other modules that currently depend on this account's existence. The account
8232
-
/// cannot be reaped until this is zero.
8233
-
pub consumers: RefCount,
8234
-
/// The number of other modules that allow this account to exist. The account may not be reaped
8235
-
/// until this and `sufficients` are both zero.
8236
-
pub providers: RefCount,
8237
-
/// The number of modules that allow this account to exist for their own purposes only. The
8238
-
/// account may not be reaped until this and `providers` are both zero.
8239
-
pub sufficients: RefCount,
8240
-
/// The additional data that belongs to this account. Used to store the balance(s) in a lot of
8241
-
/// chains.
8242
-
pub data: AccountData,
8243
-
}
8140
+
8244
8141
```
8245
8142
8246
8143
The `AccountInfo` structure includes the following components:
@@ -9254,8 +9151,7 @@ The [`XcmRouter`](https://paritytech.github.io/polkadot-sdk/master/pallet_xcm/pa
9254
9151
For instance, the Kusama network employs the [`ChildParachainRouter`](https://paritytech.github.io/polkadot-sdk/master/polkadot_runtime_common/xcm_sender/struct.ChildParachainRouter.html){target=\_blank}, which restricts routing to [Downward Message Passing (DMP)](https://wiki.polkadot.com/learn/learn-xcm-transport/#dmp-downward-message-passing){target=\_blank} from the relay chain to parachains, ensuring secure and controlled communication.
For more details about XCM transport protocols, see the [XCM Channels](/develop/interoperability/xcm-channels/){target=\_blank} page.
@@ -10381,95 +10277,25 @@ The `xcm-emulator` provides macros for defining a mocked testing environment. Ch
10381
10277
- **[`decl_test_relay_chains`](https://github.com/paritytech/polkadot-sdk/blob/polkadot-stable2506-2/cumulus/xcm/xcm-emulator/src/lib.rs#L361){target=\_blank}**: Defines runtime and configuration for the relay chains. Example:
- **[`decl_test_parachains`](https://github.com/paritytech/polkadot-sdk/blob/polkadot-stable2506-2/cumulus/xcm/xcm-emulator/src/lib.rs#L596){target=\_blank}**: Defines runtime and configuration for parachains. Example:
- **[`decl_test_bridges`](https://github.com/paritytech/polkadot-sdk/blob/polkadot-stable2506-2/cumulus/xcm/xcm-emulator/src/lib.rs#L1221){target=\_blank}**: Creates bridges between chains, specifying the source, target, and message handler. Example:
10439
10290
10440
10291
```rust
10441
-
decl_test_bridges! {
10442
-
pub struct RococoWestendMockBridge {
10443
-
source = BridgeHubRococoPara,
10444
-
target = BridgeHubWestendPara,
10445
-
handler = RococoWestendMessageHandler
10446
-
},
10447
-
pub struct WestendRococoMockBridge {
10448
-
source = BridgeHubWestendPara,
10449
-
target = BridgeHubRococoPara,
10450
-
handler = WestendRococoMessageHandler
10451
-
}
10452
-
}
10292
+
10453
10293
```
10454
10294
10455
10295
- **[`decl_test_networks`](https://github.com/paritytech/polkadot-sdk/blob/polkadot-stable2506-2/cumulus/xcm/xcm-emulator/src/lib.rs#L958){target=\_blank}**: Defines a testing network with relay chains, parachains, and bridges, implementing message transport and processing logic. Example:
10456
10296
10457
10297
```rust
10458
-
decl_test_networks! {
10459
-
pub struct WestendMockNet {
10460
-
relay_chain = Westend,
10461
-
parachains = vec![
10462
-
AssetHubWestend,
10463
-
BridgeHubWestend,
10464
-
CollectivesWestend,
10465
-
CoretimeWestend,
10466
-
PeopleWestend,
10467
-
PenpalA,
10468
-
PenpalB,
10469
-
],
10470
-
bridge = ()
10471
-
},
10472
-
}
10298
+
10473
10299
```
10474
10300
10475
10301
By leveraging these macros, developers can customize their testing networks by defining relay chains and parachains tailored to their needs. For guidance on implementing a mock runtime for a Polkadot SDK-based chain, refer to the [Pallet Testing](/parachains/customize-runtime/pallet-development/pallet-testing/){target=\_blank} article.
0 commit comments