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
Copy file name to clipboardExpand all lines: polkadot-protocol/parachain-basics/accounts.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,9 +32,11 @@ The `StorageMap` consists of the following parameters:
32
32
-**`_`**: Used in macro expansion and acts as a placeholder for the storage prefix type. Tells the macro to insert the default prefix during expansion.
33
33
-**`Blake2_128Concat`**: The hashing function applied to keys in the storage map.
34
34
-**`T: :AccountId`**: Represents the key type, which corresponds to the account’s unique ID.
35
-
-**`AccountInfo<T: :Nonce, T::AccountData>`**: The value type stored in the map. For each account ID, the map stores an `AccountInfo` struct containing:.
35
+
-**`AccountInfo<T: :Nonce, T::AccountData>`**: The value type stored in the map. For each account ID, the map stores an `AccountInfo` struct containing:
36
+
36
37
-**`T: :Nonce`**: A nonce for the account, which is incremented with each transaction to ensure transaction uniqueness.
37
38
-**`T: :AccountData`**: Custom account data defined by the runtime configuration, which could include balances, locked funds, or other relevant information.
39
+
38
40
-**`ValueQuery`**: Defines how queries to the storage map behave when no value is found; returns a default value instead of `None`.
39
41
40
42
For a detailed explanation of storage maps, see the [`StorageMap`](https://paritytech.github.io/polkadot-sdk/master/frame_support/storage/types/struct.StorageMap.html){target=\_blank} entry in the Rust docs.
Copy file name to clipboardExpand all lines: polkadot-protocol/parachain-basics/blocks-transactions-fees/transactions.md
+6-2Lines changed: 6 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -107,14 +107,18 @@ Building transactions in the Polkadot SDK involves constructing a payload that c
107
107
108
108
A signed transaction in the Polkadot SDK includes various pieces of data to ensure security, prevent replay attacks, and prioritize processing. Here's an overview of how to construct one:
109
109
110
-
1.**Construct the unsigned payload**: Gather the necessary information for the call, including.
110
+
1.**Construct the unsigned payload**: Gather the necessary information for the call, including:
111
+
111
112
-**Pallet index**: Identifies the pallet where the runtime function resides.
112
113
-**Function index**: Specifies the particular function to call in the pallet.
113
114
-**Parameters**: Any additional arguments required by the function call.
114
-
2.**Create a signing payload**: Once the unsigned payload is ready, additional data must be included.
115
+
116
+
2.**Create a signing payload**: Once the unsigned payload is ready, additional data must be included:
117
+
115
118
-**Transaction nonce**: Unique identifier to prevent replay attacks.
116
119
-**Era information**: Defines how long the transaction is valid before it's dropped from the pool.
117
120
-**Block hash**: Ensures the transaction doesn't execute on the wrong chain or fork.
121
+
118
122
3.**Sign the payload**: Using the sender's private key, sign the payload to ensure that the transaction can only be executed by the account holder.
119
123
4.**Serialize the signed payload**: Once signed, the transaction must be serialized into a binary format, ensuring the data is compact and easy to transmit over the network.
120
124
5.**Submit the serialized transaction**: Finally, submit the serialized transaction to the network, where it will enter the transaction pool and wait for processing by an authoring node.
Copy file name to clipboardExpand all lines: polkadot-protocol/parachain-basics/cryptography.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -110,6 +110,6 @@ One sacrifice that is made when using Schnorr signatures over ECDSA is that both
110
110
111
111
-**[ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm){target=\_blank}**: Polkadot SDK provides an ECDSA signature scheme using the [secp256k1](https://en.bitcoin.it/wiki/Secp256k1){target=\_blank} curve. This is the same cryptographic algorithm used to secure [Bitcoin](https://en.wikipedia.org/wiki/Bitcoin){target=\_blank} and [Ethereum](https://en.wikipedia.org/wiki/Ethereum){target=\_blank}.
112
112
113
-
-**[Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519){target=\_blank}**: Is an EdDSA signature scheme using [Curve25519](https://en.wikipedia.org/wiki/Curve25519){target=\_blank}. It is carefully engineered at several levels of design and implementation to achieve very high speeds without compromising security.
113
+
-**[Ed25519](https://en.wikipedia.org/wiki/EdDSA#Ed25519){target=\_blank}**: An EdDSA signature scheme using [Curve25519](https://en.wikipedia.org/wiki/Curve25519){target=\_blank}. It is carefully engineered at several levels of design and implementation to achieve very high speeds without compromising security.
114
114
115
-
-**[SR25519](https://research.web3.foundation/Polkadot/security/keys/accounts-more){target=\_blank}**: Is based on the same underlying curve as Ed25519. However, it uses Schnorr signatures instead of the EdDSA scheme.
115
+
-**[SR25519](https://research.web3.foundation/Polkadot/security/keys/accounts-more){target=\_blank}**: Based on the same underlying curve as Ed25519. However, it uses Schnorr signatures instead of the EdDSA scheme.
| Boolean | Boolean values are encoded using the least significant bit of a single byte. |`false` / `true`|`0x00` / `0x01`|
77
-
| Compact/general integers | A "compact" or general integer encoding is sufficient for encoding large integers (up to 2^536) and is more efficient at encoding most values than the fixed-width version. |`unsigned integer 0` / `unsigned integer 1` / `unsigned integer 42` / `unsigned integer 69` / `unsigned integer 65535` / `BigInt(100000000000000)`|`0x00` / `0x04` / `0xa8` / `0x1501` / `0xfeff0300` / `0x0b00407a10f35a`|
78
-
| Enumerations (tagged-unions) | A fixed number of variants, each mutually exclusive and potentially implying a further value or series of values. Encoded as the first byte identifying the index of the variant that the value is. Any further bytes are used to encode any data that the variant implies. Thus, no more than 256 variants are supported. |`Int(42)` and `Bool(true)` where `enum IntOrBool { Int(u8), Bool(bool) }`|`0x002a` and `0x0101`|
| Options | One or zero values of a particular type. |`Some` / `None`|`0x01` followed by the encoded value / `0x00`|
81
-
| Results | Results are commonly used enumerations which indicate whether certain operations were successful or unsuccessful. |`Ok(42)` / `Err(false)`|`0x002a` / `0x0100`|
82
-
| Strings | Strings are Vectors of bytes (Vec<u8>) containing a valid UTF8 sequence. |||
83
-
| Structs | For structures, the values are named, but that is irrelevant for the encoding (names are ignored - only order matters). |`SortedVecAsc::from([3, 5, 2, 8])`|`[3, 2, 5, 8] `|
84
-
| Tuples | A fixed-size series of values, each with a possibly different but predetermined and fixed type. This is simply the concatenation of each encoded value. | Tuple of compact unsigned integer and boolean: `(3, false) `|`0x0c00`|
85
-
| Vectors (lists, series, sets) | A collection of same-typed values is encoded, prefixed with a compact encoding of the number of items, followed by each item's encoding concatenated in turn. | Vector of unsigned `16`-bit integers: `[4, 8, 15, 16, 23, 42] `|`0x18040008000f00100017002a00`|
74
+
| Type | Description | Example SCALE Decoded Value | SCALE Encoded Value|
| Boolean | Boolean values are encoded using the least significant bit of a single byte. |`false` / `true`|`0x00` / `0x01`|
77
+
| Compact/general integers | A "compact" or general integer encoding is sufficient for encoding large integers (up to 2^536) and is more efficient at encoding most values than the fixed-width version. |`unsigned integer 0` / `unsigned integer 1` / `unsigned integer 42` / `unsigned integer 69` / `unsigned integer 65535` / `BigInt(100000000000000)`|`0x00` / `0x04` / `0xa8` / `0x1501` / `0xfeff0300` / `0x0b00407a10f35a`|
78
+
| Enumerations (tagged-unions) | A fixed number of variants, each mutually exclusive and potentially implying a further value or series of values. Encoded as the first byte identifying the index of the variant that the value is. Any further bytes are used to encode any data that the variant implies. Thus, no more than 256 variants are supported. |`Int(42)` and `Bool(true)` where `enum IntOrBool { Int(u8), Bool(bool) }`|`0x002a` and `0x0101`|
| Options | One or zero values of a particular type. |`Some` / `None`|`0x01` followed by the encoded value / `0x00`|
81
+
| Results | Results are commonly used enumerations which indicate whether certain operations were successful or unsuccessful. |`Ok(42)` / `Err(false)`|`0x002a` / `0x0100`|
82
+
| Strings | Strings are Vectors of bytes (Vec<u8>) containing a valid UTF8 sequence. |||
83
+
| Structs | For structures, the values are named, but that is irrelevant for the encoding (names are ignored - only order matters). |`SortedVecAsc::from([3, 5, 2, 8])`|`[3, 2, 5, 8] `|
84
+
| Tuples | A fixed-size series of values, each with a possibly different but predetermined and fixed type. This is simply the concatenation of each encoded value. | Tuple of compact unsigned integer and boolean: `(3, false)`|`0x0c00`|
85
+
| Vectors (lists, series, sets) | A collection of same-typed values is encoded, prefixed with a compact encoding of the number of items, followed by each item's encoding concatenated in turn. | Vector of unsigned `16`-bit integers: `[4, 8, 15, 16, 23, 42]`|`0x18040008000f00100017002a00`|
Copy file name to clipboardExpand all lines: polkadot-protocol/smart-contract-basics/accounts.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,8 @@ The platform handles two distinct address formats:
31
31
32
32
The [`AccountId32Mapper`](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/struct.AccountId32Mapper.html){target=\_blank} implementation in [`pallet_revive`](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/index.html){target=\_blank} handles the core address conversion logic. For converting a 20-byte Ethereum address to a 32-byte Polkadot address, the pallet uses a simple concatenation approach:
33
33
34
-
-**[Core mechanism](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/trait.AddressMapper.html#tymethod.to_fallback_account_id){target=\_blank}**: Takes a 20-byte Ethereum address and extends it to 32 bytes by adding twelve `0xEE` bytes at the end. The key benefits of this approach are.
34
+
-**[Core mechanism](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/trait.AddressMapper.html#tymethod.to_fallback_account_id){target=\_blank}**: Takes a 20-byte Ethereum address and extends it to 32 bytes by adding twelve `0xEE` bytes at the end. The key benefits of this approach are:
35
+
35
36
- Able to fully revert, allowing a smooth transition back to the Ethereum format.
36
37
- Provides clear identification of Ethereum-controlled accounts through the `0xEE` suffix pattern.
37
38
- Maintains cryptographic security with a `2^96` difficulty for pattern reproduction.
Copy file name to clipboardExpand all lines: polkadot-protocol/smart-contract-basics/blocks-transactions-fees.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,7 +41,8 @@ Asset Hub implements a sophisticated resource management system that combines pa
41
41
42
42
Gas serves as the fundamental unit for measuring computational costs, with each network operation consuming a specified amount. This implementation maintains compatibility with Ethereum's approach while adding parachain-specific optimizations.
43
43
44
-
-**Dynamic gas scaling**: Asset Hub implements a dynamic pricing mechanism that reflects actual execution performance. This results in.
44
+
-**Dynamic gas scaling**: Asset Hub implements a dynamic pricing mechanism that reflects actual execution performance. This results in:
45
+
45
46
- More efficient pricing for computational instructions relative to I/O operations.
46
47
- Better correlation between gas costs and actual resource consumption.
47
48
- Need for developers to implement flexible gas calculation rather than hardcoding values.
0 commit comments