From eccc6714aec703d49281d5e0e2bd40339f697ed2 Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Thu, 3 Oct 2024 15:02:06 -0300 Subject: [PATCH 01/16] fix: adding txs formats docs --- .../transactions-formats/signed-tx-example.rs | 6 + .../protocol-components/transactions/.pages | 1 + .../transactions/transactions-formats.md | 104 ++++++++++++++++++ 3 files changed, 111 insertions(+) create mode 100644 .snippets/code/polkadot-protocol/transactions/transactions-formats/signed-tx-example.rs create mode 100644 polkadot-protocol/protocol-components/transactions/transactions-formats.md diff --git a/.snippets/code/polkadot-protocol/transactions/transactions-formats/signed-tx-example.rs b/.snippets/code/polkadot-protocol/transactions/transactions-formats/signed-tx-example.rs new file mode 100644 index 00000000..59b59e3f --- /dev/null +++ b/.snippets/code/polkadot-protocol/transactions/transactions-formats/signed-tx-example.rs @@ -0,0 +1,6 @@ +node_runtime::UncheckedExtrinsic::new_signed( + function.clone(), // some call + sp_runtime::AccountId32::from(sender.public()).into(), // some sending account + node_runtime::Signature::Sr25519(signature.clone()), // the account's signature + extra.clone(), // the signed extensions +) \ No newline at end of file diff --git a/polkadot-protocol/protocol-components/transactions/.pages b/polkadot-protocol/protocol-components/transactions/.pages index 70302a2a..ffc7b4aa 100644 --- a/polkadot-protocol/protocol-components/transactions/.pages +++ b/polkadot-protocol/protocol-components/transactions/.pages @@ -1,3 +1,4 @@ title: Transactions nav: - index.md + - 'Transactions Formats': transactions-formats.md \ No newline at end of file diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md new file mode 100644 index 00000000..a495d6cd --- /dev/null +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -0,0 +1,104 @@ +--- +title: Transactions Formats +description: TODO +--- + +# Transactions Formats + +## Introduction + +This article describes the data structure of signed and unsigned transactions in Polkadot SDK-based chains. This is particularly useful for understanding how the transaction pool checks incoming transactions. Parachain builders will find this helpful in customizing how their transactions are formatted and writing client applications that must adhere to a chosen format. + +Extrinsics normally contain a signature, some data to describe whether the extrinsic has passed some validity checks and a reference to the pallet and call that it is intended for. This format provides a way for applications to ensure that the requirements for an extrinsic are met and correctly constructed. + +- Unchecked - signed transactions requiring some validation check before being accepted in the transaction pool. Any unchecked extrinsic contains the signature for the sent data and some extra data +- Checked - inherent extrinsic, which, by definition, don't require signature verification. Instead, they carry information on where the extrinsic comes from and some extra data +- Opaque - used for cases when an extrinsic hasn't yet been committed to a format but can still be decoded + +Extra data can be any additional information helpful to attach to a transaction or inherent. For example, the nonce of the transaction, the tip for the block author, or how long the extrinsic is valid for. This information is provided by a specialized extensions that help determine the validity and ordering of extrinsics before they get included in a block. + +A signed transaction might be constructed like so: + +```rust +--8<-- "code/polkadot-protocol/transactions/transactions-formats/signed-tx-example.rs" +``` + +## How Transactions are Constructed + +Polkadot SDK defines its transaction formats generically to allow developers to implement custom ways to define valid transactions. In a runtime built with FRAME, however (assuming transaction version 4), a transaction must be constructed by submitting the following encoded data: + +` + + ` + +When submitting a signed transaction, the signature is constructed by signing: + +- The actual call is composed of the following: + - The index of the pallet + - The index of the function call in the pallet + - The parameters required by the function call are being targeted + +- Some extra information, verified by the signed extensions of the transaction: + - What's the era for this transaction, i.e., how long should this call last in the transaction pool before it gets discarded? + - The nonce, i.e., how many prior transactions have occurred from this account? This helps protect against replay attacks or accidental double-submissions + - The tip amount paid to the block producer to help incentivize it to include this transaction in the block + +Then, some additional data that's not part of what gets signed is required, which includes: + +- The spec version and the transaction version ensure that the transaction is submitted to a compatible runtime +- The genesis hash, which ensures that the transaction is valid for the correct chain +- The block hash, that corresponds to the hash of the checkpoint block, enables the signature to verify that the transaction doesn't execute on the wrong fork by checking against the block number provided by the era information + +This process can be broken down into the following steps: + +1. Construct the unsigned payload +2. Create a signing payload +3. Sign the payload +4. Serialize the signed payload +5. Submit the serialized transaction + +An extrinsic is encoded into the following sequence of bytes just before being hex-encoded: + +`[ 1 ] + [ 2 ] + [ 3 ] + [ 4 ]` + +Where: + +- `[1]` contains the compact encoded length in bytes of all of the following data. Learn how compact encoding works using SCALE +- `[2]` is a u8 containing 1 byte to indicate whether the transaction is signed or unsigned (1 bit) and the encoded transaction version ID (7 bits) +- `[3]` if a signature is present, this field contains an account ID, an SR25519 signature, and some extra data. If unsigned, this field contains 0 bytes +- `[4]` is the encoded call data. This comprises 1 byte denoting the pallet to call into, 1 byte denoting the call to make in that pallet, and as many bytes as needed to encode the arguments expected by that call + +The metadata interface provides the way applications know how to construct a transaction correctly. An application will learn how to correctly encode a transaction using metadata types and transaction format. If a call doesn't need to be signed, then the first bit in `[2]` will be 0, so an application will know not to try decoding a signature. + +## Signed Extensions + +The Polkadot SDK provides the concept of signed extensions, which extend an extrinsic with additional data, through the SignedExtension trait. + +The transaction queue regularly calls signed extensions to check that a transaction is valid before it gets put in the ready queue. This is a useful safeguard for verifying that transactions won't fail in a block. Signed extensions are commonly used to enforce validation logic to protect the transaction pool from spam and replay attacks. + +In FRAME, a signed extension can hold any of the following types by default: + +- `AccountId` - to encode the sender's identity +- `Call` - to encode the pallet call to be dispatched. This data is used to calculate transaction fees. +- `AdditionalSigned`—to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction. +- `Pre` - to encode the information that can be passed from before a call is dispatched to after it gets dispatched + +FRAME's system pallet provides a set of useful `SignedExtension` out of the box. + +### Example + +An important signed extension for validating transactions is CheckSpecVersion.
It allows the sender to provide the spec version as a signed payload attached to the transaction. Since the spec version is already known in the runtime, the signed extension can perform a simple check to verify that the spec versions match. If they don't, the transaction fails before being put in the pool. + +Other examples include the signed extensions used to calculate transaction priority. These are: + +- `CheckWeight` - sets the value for priority to 0 for all dispatch classes +- `ChargeTransactionPayment` - calculates the overall priority, modifying the priority value accordingly + +The priority depends on the dispatch class and the amount of tip-per-weight or tip-per-length (whatever is more limiting) the sender is willing to pay. Transactions without a tip use a minimal tip value of `1` for priority calculations to ensure that not all transactions have a priority of `0`. The consequence of this is that smaller transactions are preferred over larger ones. + +## Where to Go Next + +Now that you have seen how transactions are constructed, you should review how they progress from the transaction pool to the runtime and get added to blocks or how to use tools that enable you to submit transactions offline or using a REST API. + +- [Transaction lifecycle](TODO:update-path){target=\_blank} +- [Transactions, weights, and fees](TODO:update-path){target=\_blank} +- [`tx-wrapper`](https://github.com/paritytech/txwrapper-core){target=\_blank} - for offline transactions +- [`sidecar`](https://github.com/paritytech/substrate-api-sidecar){target=\_blank} - for REST-based transactions \ No newline at end of file From 76913043c6cd5ff8b0f004dd0151de87ea6779fd Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Thu, 3 Oct 2024 22:40:11 -0300 Subject: [PATCH 02/16] fix: adding article desc --- .../protocol-components/transactions/transactions-formats.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index a495d6cd..22bbc76b 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -1,6 +1,6 @@ --- title: Transactions Formats -description: TODO +description: Overview of the data structure of signed and unsigned transactions in Polkadot SDK-based chains, and how they are constructed. --- # Transactions Formats From bfbf437b909e65626103f65550febec7e6d4bf65 Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Thu, 3 Oct 2024 22:56:11 -0300 Subject: [PATCH 03/16] fix: adding references to the codebase --- .../transactions/transactions-formats.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index 22bbc76b..8d522b49 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -11,9 +11,9 @@ This article describes the data structure of signed and unsigned transactions in Extrinsics normally contain a signature, some data to describe whether the extrinsic has passed some validity checks and a reference to the pallet and call that it is intended for. This format provides a way for applications to ensure that the requirements for an extrinsic are met and correctly constructed. -- Unchecked - signed transactions requiring some validation check before being accepted in the transaction pool. Any unchecked extrinsic contains the signature for the sent data and some extra data -- Checked - inherent extrinsic, which, by definition, don't require signature verification. Instead, they carry information on where the extrinsic comes from and some extra data -- Opaque - used for cases when an extrinsic hasn't yet been committed to a format but can still be decoded +- [Unchecked](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs#L70){target=\_blank} - signed transactions requiring some validation check before being accepted in the transaction pool. Any unchecked extrinsic contains the signature for the sent data and some extra data +- [Checked](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/checked_extrinsic.rs#L35){target=\_blank} - inherent extrinsic, which, by definition, don't require signature verification. Instead, they carry information on where the extrinsic comes from and some extra data +- [Opaque](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/lib.rs#L915){target=\_blank} - used for cases when an extrinsic hasn't yet been committed to a format but can still be decoded Extra data can be any additional information helpful to attach to a transaction or inherent. For example, the nonce of the transaction, the tip for the block author, or how long the extrinsic is valid for. This information is provided by a specialized extensions that help determine the validity and ordering of extrinsics before they get included in a block. From 6146bda6b25e4cad0b0d9f405bbfc1a80ddcd9be Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Thu, 3 Oct 2024 22:58:25 -0300 Subject: [PATCH 04/16] fix: adding def of inherents --- .../protocol-components/transactions/transactions-formats.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index 8d522b49..e9ae588d 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -12,9 +12,12 @@ This article describes the data structure of signed and unsigned transactions in Extrinsics normally contain a signature, some data to describe whether the extrinsic has passed some validity checks and a reference to the pallet and call that it is intended for. This format provides a way for applications to ensure that the requirements for an extrinsic are met and correctly constructed. - [Unchecked](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs#L70){target=\_blank} - signed transactions requiring some validation check before being accepted in the transaction pool. Any unchecked extrinsic contains the signature for the sent data and some extra data -- [Checked](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/checked_extrinsic.rs#L35){target=\_blank} - inherent extrinsic, which, by definition, don't require signature verification. Instead, they carry information on where the extrinsic comes from and some extra data +- [Checked](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/checked_extrinsic.rs#L35){target=\_blank} - inherent extrinsics, which, by definition, don't require signature verification. Instead, they carry information on where the extrinsic comes from and some extra data - [Opaque](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/lib.rs#L915){target=\_blank} - used for cases when an extrinsic hasn't yet been committed to a format but can still be decoded +!!! note + Inherents are unique unsigned transactions created by block producers. They contain essential data for block construction, such as time stamps, storage verification proofs, and information about uncle blocks. + Extra data can be any additional information helpful to attach to a transaction or inherent. For example, the nonce of the transaction, the tip for the block author, or how long the extrinsic is valid for. This information is provided by a specialized extensions that help determine the validity and ordering of extrinsics before they get included in a block. A signed transaction might be constructed like so: From 0981bfd6e07dec0c4eda2f6e436264eeaf8af4e9 Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Thu, 3 Oct 2024 23:00:18 -0300 Subject: [PATCH 05/16] fix: adding todo for future path --- .../protocol-components/transactions/transactions-formats.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index e9ae588d..b3453cdb 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -46,7 +46,7 @@ When submitting a signed transaction, the signature is constructed by signing: Then, some additional data that's not part of what gets signed is required, which includes: -- The spec version and the transaction version ensure that the transaction is submitted to a compatible runtime +- The spec version and the transaction version ensure that the transaction is submitted to a [compatible runtime](TODO:update-path){target=\_blank} - The genesis hash, which ensures that the transaction is valid for the correct chain - The block hash, that corresponds to the hash of the checkpoint block, enables the signature to verify that the transaction doesn't execute on the wrong fork by checking against the block number provided by the era information From 86675718d70b324751ddd5e3b8ecd1bf5095ffa9 Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Thu, 3 Oct 2024 23:07:23 -0300 Subject: [PATCH 06/16] fix: adding links to pdsk --- .../transactions/transactions-formats.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index b3453cdb..97344398 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -73,13 +73,13 @@ The metadata interface provides the way applications know how to construct a tra ## Signed Extensions -The Polkadot SDK provides the concept of signed extensions, which extend an extrinsic with additional data, through the SignedExtension trait. +The Polkadot SDK provides the concept of [signed extensions](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/signed_extensions/index.html){target=\_blank}, which extend an extrinsic with additional data, through the SignedExtension trait. The transaction queue regularly calls signed extensions to check that a transaction is valid before it gets put in the ready queue. This is a useful safeguard for verifying that transactions won't fail in a block. Signed extensions are commonly used to enforce validation logic to protect the transaction pool from spam and replay attacks. In FRAME, a signed extension can hold any of the following types by default: -- `AccountId` - to encode the sender's identity +- [`AccountId`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/src/lib.rs#L274){target=\_blank} - to encode the sender's identity - `Call` - to encode the pallet call to be dispatched. This data is used to calculate transaction fees. - `AdditionalSigned`—to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction. - `Pre` - to encode the information that can be passed from before a call is dispatched to after it gets dispatched @@ -92,8 +92,8 @@ An important signed extension for validating transactions is CheckSpecVersion. Other examples include the signed extensions used to calculate transaction priority. These are: -- `CheckWeight` - sets the value for priority to 0 for all dispatch classes -- `ChargeTransactionPayment` - calculates the overall priority, modifying the priority value accordingly +- [`CheckWeight`](https://paritytech.github.io/polkadot-sdk/master/frame_system/struct.CheckWeight.html){target=\_blank} - sets the value for priority to 0 for all dispatch classes +- [`ChargeTransactionPayment`](https://paritytech.github.io/polkadot-sdk/master/pallet_transaction_payment/struct.ChargeTransactionPayment.html){target=\_blank} - calculates the overall priority, modifying the priority value accordingly The priority depends on the dispatch class and the amount of tip-per-weight or tip-per-length (whatever is more limiting) the sender is willing to pay. Transactions without a tip use a minimal tip value of `1` for priority calculations to ensure that not all transactions have a priority of `0`. The consequence of this is that smaller transactions are preferred over larger ones. From 11f26b958370677f5ca716b6e9e4f89bd62fae9a Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Thu, 3 Oct 2024 23:08:07 -0300 Subject: [PATCH 07/16] fix: format --- .../protocol-components/transactions/transactions-formats.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index 97344398..0e42c590 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -81,7 +81,7 @@ In FRAME, a signed extension can hold any of the following types by default: - [`AccountId`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/src/lib.rs#L274){target=\_blank} - to encode the sender's identity - `Call` - to encode the pallet call to be dispatched. This data is used to calculate transaction fees. -- `AdditionalSigned`—to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction. +- `AdditionalSigned` — to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction. - `Pre` - to encode the information that can be passed from before a call is dispatched to after it gets dispatched FRAME's system pallet provides a set of useful `SignedExtension` out of the box. From f76c871d4b19c02483a4bbbc594546f99b6c16ea Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Thu, 3 Oct 2024 23:08:22 -0300 Subject: [PATCH 08/16] fix: format --- .../protocol-components/transactions/transactions-formats.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index 0e42c590..1a2e0f36 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -80,8 +80,8 @@ The transaction queue regularly calls signed extensions to check that a transact In FRAME, a signed extension can hold any of the following types by default: - [`AccountId`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/src/lib.rs#L274){target=\_blank} - to encode the sender's identity -- `Call` - to encode the pallet call to be dispatched. This data is used to calculate transaction fees. -- `AdditionalSigned` — to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction. +- `Call` - to encode the pallet call to be dispatched. This data is used to calculate transaction fees +- `AdditionalSigned` — to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction - `Pre` - to encode the information that can be passed from before a call is dispatched to after it gets dispatched FRAME's system pallet provides a set of useful `SignedExtension` out of the box. From 53c8eba98f2c521a52d10a89ca4869a84cf9fc77 Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Fri, 4 Oct 2024 10:18:21 -0300 Subject: [PATCH 09/16] fix: adding scale reference --- .../protocol-components/transactions/transactions-formats.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index 1a2e0f36..99fbeeb2 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -64,7 +64,7 @@ An extrinsic is encoded into the following sequence of bytes just before being h Where: -- `[1]` contains the compact encoded length in bytes of all of the following data. Learn how compact encoding works using SCALE +- `[1]` contains the compact encoded length in bytes of all of the following data. Learn how compact encoding works using [SCALE](https://github.com/paritytech/parity-scale-codec){target=\_blank} - `[2]` is a u8 containing 1 byte to indicate whether the transaction is signed or unsigned (1 bit) and the encoded transaction version ID (7 bits) - `[3]` if a signature is present, this field contains an account ID, an SR25519 signature, and some extra data. If unsigned, this field contains 0 bytes - `[4]` is the encoded call data. This comprises 1 byte denoting the pallet to call into, 1 byte denoting the call to make in that pallet, and as many bytes as needed to encode the arguments expected by that call From df54fbd5721522274cc50c728ec3aadbd3e324a1 Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Fri, 4 Oct 2024 10:19:21 -0300 Subject: [PATCH 10/16] fix: adding SignedExtension trait reference --- .../protocol-components/transactions/transactions-formats.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index 99fbeeb2..175d3cf4 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -73,7 +73,7 @@ The metadata interface provides the way applications know how to construct a tra ## Signed Extensions -The Polkadot SDK provides the concept of [signed extensions](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/signed_extensions/index.html){target=\_blank}, which extend an extrinsic with additional data, through the SignedExtension trait. +The Polkadot SDK provides the concept of [signed extensions](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/signed_extensions/index.html){target=\_blank}, which extend an extrinsic with additional data, through the [SignedExtension](https://paritytech.github.io/try-runtime-cli/sp_runtime/traits/trait.SignedExtension.html){target=\_blank} trait. The transaction queue regularly calls signed extensions to check that a transaction is valid before it gets put in the ready queue. This is a useful safeguard for verifying that transactions won't fail in a block. Signed extensions are commonly used to enforce validation logic to protect the transaction pool from spam and replay attacks. From 1e6d013d810a7cb376a484dfdae80533db0fde3e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Nicol=C3=A1s=20Hussein?= <80422357+nhussein11@users.noreply.github.com> Date: Fri, 4 Oct 2024 10:23:11 -0300 Subject: [PATCH 11/16] Apply suggestions from code review Co-authored-by: 0xLucca <95830307+0xLucca@users.noreply.github.com> --- .../protocol-components/transactions/transactions-formats.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index 175d3cf4..2826f871 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -37,7 +37,7 @@ When submitting a signed transaction, the signature is constructed by signing: - The actual call is composed of the following: - The index of the pallet - The index of the function call in the pallet - - The parameters required by the function call are being targeted + - The parameters required by the function call being targeted - Some extra information, verified by the signed extensions of the transaction: - What's the era for this transaction, i.e., how long should this call last in the transaction pool before it gets discarded? @@ -81,7 +81,7 @@ In FRAME, a signed extension can hold any of the following types by default: - [`AccountId`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/src/lib.rs#L274){target=\_blank} - to encode the sender's identity - `Call` - to encode the pallet call to be dispatched. This data is used to calculate transaction fees -- `AdditionalSigned` — to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction +- `AdditionalSigned` - to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction - `Pre` - to encode the information that can be passed from before a call is dispatched to after it gets dispatched FRAME's system pallet provides a set of useful `SignedExtension` out of the box. From 8cce5d0c5c08a1d71ce1c806c37cfd72d02a9974 Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Fri, 4 Oct 2024 10:48:04 -0300 Subject: [PATCH 12/16] fix: adding links to system pallet signedExtension --- .../transactions/transactions-formats.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index 2826f871..aa1d893b 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -79,12 +79,12 @@ The transaction queue regularly calls signed extensions to check that a transact In FRAME, a signed extension can hold any of the following types by default: -- [`AccountId`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/src/lib.rs#L274){target=\_blank} - to encode the sender's identity -- `Call` - to encode the pallet call to be dispatched. This data is used to calculate transaction fees -- `AdditionalSigned` - to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction -- `Pre` - to encode the information that can be passed from before a call is dispatched to after it gets dispatched +- [`AccountId`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1489){target=\_blank} - to encode the sender's identity +- [`Call`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1492){target=\_blank} - to encode the pallet call to be dispatched. This data is used to calculate transaction fees +- [`AdditionalSigned`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1496){target=\_blank} - to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction +- [`Pre`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1499){target=\_blank} - to encode the information that can be passed from before a call is dispatched to after it gets dispatched -FRAME's system pallet provides a set of useful `SignedExtension` out of the box. +FRAME's system pallet provides a [set of useful `SignedExtension`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/system/src/lib.rs#L79){target=\_blank} out of the box. ### Example From f3874ffbac4a7842d950693509e66608f86d546c Mon Sep 17 00:00:00 2001 From: DAWN KELLY Date: Tue, 8 Oct 2024 16:07:16 -0400 Subject: [PATCH 13/16] edits for grammar, etc. --- .../transactions/transactions-formats.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index aa1d893b..323cec9c 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -40,8 +40,8 @@ When submitting a signed transaction, the signature is constructed by signing: - The parameters required by the function call being targeted - Some extra information, verified by the signed extensions of the transaction: - - What's the era for this transaction, i.e., how long should this call last in the transaction pool before it gets discarded? - - The nonce, i.e., how many prior transactions have occurred from this account? This helps protect against replay attacks or accidental double-submissions + - What's the era for this transaction? How long should this call last in the transaction pool before it gets discarded? + - The nonce. How many prior transactions have occurred from this account? This helps protect against replay attacks or accidental double-submissions - The tip amount paid to the block producer to help incentivize it to include this transaction in the block Then, some additional data that's not part of what gets signed is required, which includes: @@ -84,11 +84,11 @@ In FRAME, a signed extension can hold any of the following types by default: - [`AdditionalSigned`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1496){target=\_blank} - to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction - [`Pre`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1499){target=\_blank} - to encode the information that can be passed from before a call is dispatched to after it gets dispatched -FRAME's system pallet provides a [set of useful `SignedExtension`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/system/src/lib.rs#L79){target=\_blank} out of the box. +FRAME's system pallet provides a [useful `SignedExtension` set](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/system/src/lib.rs#L79){target=\_blank} out of the box. ### Example -An important signed extension for validating transactions is CheckSpecVersion.
It allows the sender to provide the spec version as a signed payload attached to the transaction. Since the spec version is already known in the runtime, the signed extension can perform a simple check to verify that the spec versions match. If they don't, the transaction fails before being put in the pool. +An important signed extension for validating transactions is `CheckSpecVersion`. It allows the sender to provide the spec version as a signed payload attached to the transaction. Since the spec version is already known in the runtime, the signed extension can perform a simple check to verify that the spec versions match. If they don't, the transaction fails before being put in the pool. Other examples include the signed extensions used to calculate transaction priority. These are: From 39617dc266991854eddb898c0e435ab34f4f25dc Mon Sep 17 00:00:00 2001 From: DAWN KELLY Date: Tue, 8 Oct 2024 16:12:20 -0400 Subject: [PATCH 14/16] grammarly check --- .../transactions/transactions-formats.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index 323cec9c..7921efa3 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -7,18 +7,18 @@ description: Overview of the data structure of signed and unsigned transactions ## Introduction -This article describes the data structure of signed and unsigned transactions in Polkadot SDK-based chains. This is particularly useful for understanding how the transaction pool checks incoming transactions. Parachain builders will find this helpful in customizing how their transactions are formatted and writing client applications that must adhere to a chosen format. +This article describes the data structure of signed and unsigned transactions in Polkadot SDK-based chains. Data structure information is particularly useful for understanding how the transaction pool checks incoming transactions. Parachain builders will find this helpful in customizing how their transactions are formatted and writing client applications that must adhere to a chosen format. -Extrinsics normally contain a signature, some data to describe whether the extrinsic has passed some validity checks and a reference to the pallet and call that it is intended for. This format provides a way for applications to ensure that the requirements for an extrinsic are met and correctly constructed. +Extrinsics normally contain a signature, some data to describe whether the extrinsic has passed some validity checks, and a reference to the pallet and call that it is intended for. This format provides a way for applications to ensure that the requirements for an extrinsic are met and correctly constructed. - [Unchecked](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs#L70){target=\_blank} - signed transactions requiring some validation check before being accepted in the transaction pool. Any unchecked extrinsic contains the signature for the sent data and some extra data - [Checked](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/checked_extrinsic.rs#L35){target=\_blank} - inherent extrinsics, which, by definition, don't require signature verification. Instead, they carry information on where the extrinsic comes from and some extra data - [Opaque](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/lib.rs#L915){target=\_blank} - used for cases when an extrinsic hasn't yet been committed to a format but can still be decoded !!! note - Inherents are unique unsigned transactions created by block producers. They contain essential data for block construction, such as time stamps, storage verification proofs, and information about uncle blocks. + Inherents are unique, unsigned transactions created by block producers. They contain essential data for block construction, such as time stamps, storage verification proofs, and information about uncle blocks. -Extra data can be any additional information helpful to attach to a transaction or inherent. For example, the nonce of the transaction, the tip for the block author, or how long the extrinsic is valid for. This information is provided by a specialized extensions that help determine the validity and ordering of extrinsics before they get included in a block. +Extra data can be any additional information helpful to attach to a transaction or inherent. For example, the nonce of the transaction, the tip for the block author, or how long the extrinsic is valid. This information is provided by a specialized extensions that help determine the validity and ordering of extrinsics before they get included in a block. A signed transaction might be constructed like so: @@ -28,7 +28,7 @@ A signed transaction might be constructed like so: ## How Transactions are Constructed -Polkadot SDK defines its transaction formats generically to allow developers to implement custom ways to define valid transactions. In a runtime built with FRAME, however (assuming transaction version 4), a transaction must be constructed by submitting the following encoded data: +Polkadot SDK defines its transaction formats generically, allowing developers to implement custom ways to define valid transactions. In a runtime built with FRAME, however (assuming transaction version 4), a transaction must be constructed by submitting the following encoded data: ` + + ` @@ -41,7 +41,7 @@ When submitting a signed transaction, the signature is constructed by signing: - Some extra information, verified by the signed extensions of the transaction: - What's the era for this transaction? How long should this call last in the transaction pool before it gets discarded? - - The nonce. How many prior transactions have occurred from this account? This helps protect against replay attacks or accidental double-submissions + - The nonce. How many prior transactions have occurred from this account? This check helps protect against replay attacks or accidental double-submissions - The tip amount paid to the block producer to help incentivize it to include this transaction in the block Then, some additional data that's not part of what gets signed is required, which includes: @@ -88,7 +88,7 @@ FRAME's system pallet provides a [useful `SignedExtension` set](https://github.c ### Example -An important signed extension for validating transactions is `CheckSpecVersion`. It allows the sender to provide the spec version as a signed payload attached to the transaction. Since the spec version is already known in the runtime, the signed extension can perform a simple check to verify that the spec versions match. If they don't, the transaction fails before being put in the pool. +An important signed extension for validating transactions is `CheckSpecVersion`. The sender can provide the spec version as a signed payload attached to the transaction. Since the spec version is already known in the runtime, the signed extension can perform a simple check to verify that the spec versions match. The transaction fails before being put in the pool if they don't. Other examples include the signed extensions used to calculate transaction priority. These are: From a0562272febc198433056a9279beb27a2e658415 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Nicol=C3=A1s=20Hussein?= <80422357+nhussein11@users.noreply.github.com> Date: Wed, 9 Oct 2024 08:43:16 -0300 Subject: [PATCH 15/16] Apply suggestions from code review Co-authored-by: Erin Shaben --- .../transactions/transactions-formats.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index 7921efa3..59bc0c71 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -11,9 +11,9 @@ This article describes the data structure of signed and unsigned transactions in Extrinsics normally contain a signature, some data to describe whether the extrinsic has passed some validity checks, and a reference to the pallet and call that it is intended for. This format provides a way for applications to ensure that the requirements for an extrinsic are met and correctly constructed. -- [Unchecked](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs#L70){target=\_blank} - signed transactions requiring some validation check before being accepted in the transaction pool. Any unchecked extrinsic contains the signature for the sent data and some extra data -- [Checked](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/checked_extrinsic.rs#L35){target=\_blank} - inherent extrinsics, which, by definition, don't require signature verification. Instead, they carry information on where the extrinsic comes from and some extra data -- [Opaque](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/lib.rs#L915){target=\_blank} - used for cases when an extrinsic hasn't yet been committed to a format but can still be decoded +- [**Unchecked**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs#L70){target=\_blank} - signed transactions requiring some validation check before being accepted in the transaction pool. Any unchecked extrinsic contains the signature for the sent data and some extra data +- [**Checked**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/checked_extrinsic.rs#L35){target=\_blank} - inherent extrinsics, which, by definition, don't require signature verification. Instead, they carry information on where the extrinsic comes from and some extra data +- [**Opaque**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/lib.rs#L915){target=\_blank} - used for cases when an extrinsic hasn't yet been committed to a format but can still be decoded !!! note Inherents are unique, unsigned transactions created by block producers. They contain essential data for block construction, such as time stamps, storage verification proofs, and information about uncle blocks. @@ -73,16 +73,16 @@ The metadata interface provides the way applications know how to construct a tra ## Signed Extensions -The Polkadot SDK provides the concept of [signed extensions](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/signed_extensions/index.html){target=\_blank}, which extend an extrinsic with additional data, through the [SignedExtension](https://paritytech.github.io/try-runtime-cli/sp_runtime/traits/trait.SignedExtension.html){target=\_blank} trait. +The Polkadot SDK provides the concept of [signed extensions](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/signed_extensions/index.html){target=\_blank}, which extend an extrinsic with additional data, through the [`SignedExtension`](https://paritytech.github.io/try-runtime-cli/sp_runtime/traits/trait.SignedExtension.html){target=\_blank} trait. The transaction queue regularly calls signed extensions to check that a transaction is valid before it gets put in the ready queue. This is a useful safeguard for verifying that transactions won't fail in a block. Signed extensions are commonly used to enforce validation logic to protect the transaction pool from spam and replay attacks. In FRAME, a signed extension can hold any of the following types by default: -- [`AccountId`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1489){target=\_blank} - to encode the sender's identity -- [`Call`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1492){target=\_blank} - to encode the pallet call to be dispatched. This data is used to calculate transaction fees -- [`AdditionalSigned`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1496){target=\_blank} - to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction -- [`Pre`](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1499){target=\_blank} - to encode the information that can be passed from before a call is dispatched to after it gets dispatched +- [**`AccountId`**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1489){target=\_blank} - to encode the sender's identity +- [**`Call`**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1492){target=\_blank} - to encode the pallet call to be dispatched. This data is used to calculate transaction fees +- [**`AdditionalSigned`**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1496){target=\_blank} - to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction +- [**`Pre`**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1499){target=\_blank} - to encode the information that can be passed from before a call is dispatched to after it gets dispatched FRAME's system pallet provides a [useful `SignedExtension` set](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/system/src/lib.rs#L79){target=\_blank} out of the box. @@ -103,5 +103,5 @@ Now that you have seen how transactions are constructed, you should review how t - [Transaction lifecycle](TODO:update-path){target=\_blank} - [Transactions, weights, and fees](TODO:update-path){target=\_blank} -- [`tx-wrapper`](https://github.com/paritytech/txwrapper-core){target=\_blank} - for offline transactions -- [`sidecar`](https://github.com/paritytech/substrate-api-sidecar){target=\_blank} - for REST-based transactions \ No newline at end of file +- [`txwrapper-core`](https://github.com/paritytech/txwrapper-core){target=\_blank} - for offline transactions +- [`@substrate/api-sidecar`](https://github.com/paritytech/substrate-api-sidecar){target=\_blank} - for REST-based transactions \ No newline at end of file From 94cf10355a5fc4112b22ed6373d62bef45f5c3fb Mon Sep 17 00:00:00 2001 From: nhussein11 Date: Wed, 9 Oct 2024 08:59:55 -0300 Subject: [PATCH 16/16] fix: updating routes --- .../add-trusted-nodes/chainspec-head.html | 28 +-- .../add-trusted-nodes/chainspec-tail.html | 164 +++++++++--------- .../add-trusted-nodes/node-output-1.html | 34 ++-- .../transactions/transactions-formats.md | 16 +- 4 files changed, 121 insertions(+), 121 deletions(-) diff --git a/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/chainspec-head.html b/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/chainspec-head.html index 3572b290..5a147283 100644 --- a/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/chainspec-head.html +++ b/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/chainspec-head.html @@ -1,15 +1,15 @@ -
- head customSpec.json +
+ head customSpec.json -
- { - "name": "Local Testnet", - "id": "local_testnet", - "chainType": "Local", - "bootNodes": [], - "telemetryEndpoints": null, - "protocolId": null, - "properties": null, - "codeSubstitutes": {}, - "genesis": { -
\ No newline at end of file +
+ { + "name": "Local Testnet", + "id": "local_testnet", + "chainType": "Local", + "bootNodes": [], + "telemetryEndpoints": null, + "protocolId": null, + "properties": null, + "codeSubstitutes": {}, + "genesis": { +
diff --git a/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/chainspec-tail.html b/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/chainspec-tail.html index c9d38752..afd306e4 100644 --- a/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/chainspec-tail.html +++ b/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/chainspec-tail.html @@ -1,83 +1,83 @@ -
- tail -n 78 customSpec.json +
+ tail -n 78 customSpec.json -
- "patch": { - "aura": { - "authorities": [ - "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY", - "5FHneW46xGXgs5mUiveU4sbTyGBzmstUspZC92UhjJM694ty" - ] - }, - "balances": { - "balances": [ - [ - "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY", - 1152921504606846976 - ], - [ - "5FHneW46xGXgs5mUiveU4sbTyGBzmstUspZC92UhjJM694ty", - 1152921504606846976 - ], - [ - "5FLSigC9HGRKVhB9FiEo4Y3koPsNmBmLJbpXg2mp1hXcS59Y", - 1152921504606846976 - ], - [ - "5DAAnrj7VHTznn2AWBemMuyBwZWs6FNFjdyVXUeYum3PTXFy", - 1152921504606846976 - ], - [ - "5HGjWAeFDfFCWPsjFQdVV2Msvz2XtMktvgocEZcCj68kUMaw", - 1152921504606846976 - ], - [ - "5CiPPseXPECbkjWCa6MnjNokrgYjMqmKndv2rSnekmSK2DjL", - 1152921504606846976 - ], - [ - "5GNJqTPyNqANBkUVMN1LPPrxXnFouWXoe2wNSmmEoLctxiZY", - 1152921504606846976 - ], - [ - "5HpG9w8EBLe5XCrbczpwq5TSXvedjrBGCwqxK1iQ7qUsSWFc", - 1152921504606846976 - ], - [ - "5Ck5SLSHYac6WFt5UZRSsdJjwmpSZq85fd5TRNAdZQVzEAPT", - 1152921504606846976 - ], - [ - "5HKPmK9GYtE1PSLsS1qiYU9xQ9Si1NcEhdeCq9sw5bqu4ns8", - 1152921504606846976 - ], - [ - "5FCfAonRZgTFrTd9HREEyeJjDpT397KMzizE6T3DvebLFE7n", - 1152921504606846976 - ], - [ - "5CRmqmsiNFExV6VbdmPJViVxrWmkaXXvBrSX8oqBT8R9vmWk", - 1152921504606846976 - ] - ] - }, - "grandpa": { - "authorities": [ - [ - "5FA9nQDVg267DEd8m1ZypXLBnvN7SFxYwV7ndqSYGiN9TTpu", - 1 - ], - [ - "5GoNkf6WdbxCFnPdAnYYQyCjAKPJgLNxXwPjwTh6DGg6gN3E", - 1 - ] - ] - }, - "sudo": { - "key": "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY" - } - } - } - } - }% -
\ No newline at end of file +
+ "patch": { + "aura": { + "authorities": [ + "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY", + "5FHneW46xGXgs5mUiveU4sbTyGBzmstUspZC92UhjJM694ty" + ] + }, + "balances": { + "balances": [ + [ + "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY", + 1152921504606846976 + ], + [ + "5FHneW46xGXgs5mUiveU4sbTyGBzmstUspZC92UhjJM694ty", + 1152921504606846976 + ], + [ + "5FLSigC9HGRKVhB9FiEo4Y3koPsNmBmLJbpXg2mp1hXcS59Y", + 1152921504606846976 + ], + [ + "5DAAnrj7VHTznn2AWBemMuyBwZWs6FNFjdyVXUeYum3PTXFy", + 1152921504606846976 + ], + [ + "5HGjWAeFDfFCWPsjFQdVV2Msvz2XtMktvgocEZcCj68kUMaw", + 1152921504606846976 + ], + [ + "5CiPPseXPECbkjWCa6MnjNokrgYjMqmKndv2rSnekmSK2DjL", + 1152921504606846976 + ], + [ + "5GNJqTPyNqANBkUVMN1LPPrxXnFouWXoe2wNSmmEoLctxiZY", + 1152921504606846976 + ], + [ + "5HpG9w8EBLe5XCrbczpwq5TSXvedjrBGCwqxK1iQ7qUsSWFc", + 1152921504606846976 + ], + [ + "5Ck5SLSHYac6WFt5UZRSsdJjwmpSZq85fd5TRNAdZQVzEAPT", + 1152921504606846976 + ], + [ + "5HKPmK9GYtE1PSLsS1qiYU9xQ9Si1NcEhdeCq9sw5bqu4ns8", + 1152921504606846976 + ], + [ + "5FCfAonRZgTFrTd9HREEyeJjDpT397KMzizE6T3DvebLFE7n", + 1152921504606846976 + ], + [ + "5CRmqmsiNFExV6VbdmPJViVxrWmkaXXvBrSX8oqBT8R9vmWk", + 1152921504606846976 + ] + ] + }, + "grandpa": { + "authorities": [ + [ + "5FA9nQDVg267DEd8m1ZypXLBnvN7SFxYwV7ndqSYGiN9TTpu", + 1 + ], + [ + "5GoNkf6WdbxCFnPdAnYYQyCjAKPJgLNxXwPjwTh6DGg6gN3E", + 1 + ] + ] + }, + "sudo": { + "key": "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY" + } + } + } + } + }% +
diff --git a/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/node-output-1.html b/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/node-output-1.html index 86800544..8d0eeaa1 100644 --- a/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/node-output-1.html +++ b/.snippets/code/tutorials/polkadot-sdk/build-a-blockchain/add-trusted-nodes/node-output-1.html @@ -1,17 +1,17 @@ -
- 2024-09-12 15:37:05 💤 Idle (0 peers), best: #0 (0x8af7…53fd), finalized #0 (0x8af7…53fd), ⬇ 0 ⬆ 0 - 2024-09-12 15:37:08 discovered: 12D3KooWMaL5zqYiMnVikaYCGF65fKekSPqXGgyz92eRcqcnfpey /ip4/192.168.1.2/tcp/30334 - 2024-09-12 15:37:10 💤 Idle (1 peers), best: #0 (0x8af7…53fd), finalized #0 (0x8af7…53fd), ⬇ 0.6kiB/s ⬆ 0.6kiB/s - 2024-09-12 15:37:12 🙌 Starting consensus session on top of parent 0x8af7c72457d437486fe697b4a11ef42b26c8b4448836bdb2220495aea39f53fd (#0) - 2024-09-12 15:37:12 🎁 Prepared block for proposing at 1 (6 ms) [hash: 0xb97cb3a4a62f0cb320236469d8e1e13227a15138941f3c9819b6b78f91986262; parent_hash: 0x8af7…53fd; extrinsics (1): [0x1ef4…eecb] - 2024-09-12 15:37:12 🔖 Pre-sealed block for proposal at 1. Hash now 0x05115677207265f22c6d428fb00b65a0e139c866c975913431ddefe291124f04, previously 0xb97cb3a4a62f0cb320236469d8e1e13227a15138941f3c9819b6b78f91986262. - 2024-09-12 15:37:12 🏆 Imported #1 (0x8af7…53fd → 0x0511…4f04) - 2024-09-12 15:37:15 💤 Idle (1 peers), best: #1 (0x0511…4f04), finalized #0 (0x8af7…53fd), ⬇ 0.5kiB/s ⬆ 0.6kiB/s - 2024-09-12 15:37:18 🏆 Imported #2 (0x0511…4f04 → 0x17a7…a1fd) - 2024-09-12 15:37:20 💤 Idle (1 peers), best: #2 (0x17a7…a1fd), finalized #0 (0x8af7…53fd), ⬇ 0.6kiB/s ⬆ 0.5kiB/s - 2024-09-12 15:37:24 🙌 Starting consensus session on top of parent 0x17a77a8799bd58c7b82ca6a1e3322b38e7db574ee6c92fbcbc26bbe5214da1fd (#2) - 2024-09-12 15:37:24 🎁 Prepared block for proposing at 3 (1 ms) [hash: 0x74d78266b1ac2514050ced3f34fbf98a28c6a2856f49dbe8b44686440a45f879; parent_hash: 0x17a7…a1fd; extrinsics (1): [0xe35f…8d48] - 2024-09-12 15:37:24 🔖 Pre-sealed block for proposal at 3. Hash now 0x12cc1e9492988cfd3ffe4a6eb3186b1abb351a12a97809f7bae4a7319e177dee, previously 0x74d78266b1ac2514050ced3f34fbf98a28c6a2856f49dbe8b44686440a45f879. - 2024-09-12 15:37:24 🏆 Imported #3 (0x17a7…a1fd → 0x12cc…7dee) - 2024-09-12 15:37:25 💤 Idle (1 peers), best: #3 (0x12cc…7dee), finalized #1 (0x0511…4f04), ⬇ 0.5kiB/s ⬆ 0.6kiB/s -
\ No newline at end of file +
+ 2024-09-12 15:37:05 💤 Idle (0 peers), best: #0 (0x8af7…53fd), finalized #0 (0x8af7…53fd), ⬇ 0 ⬆ 0 + 2024-09-12 15:37:08 discovered: 12D3KooWMaL5zqYiMnVikaYCGF65fKekSPqXGgyz92eRcqcnfpey /ip4/192.168.1.2/tcp/30334 + 2024-09-12 15:37:10 💤 Idle (1 peers), best: #0 (0x8af7…53fd), finalized #0 (0x8af7…53fd), ⬇ 0.6kiB/s ⬆ 0.6kiB/s + 2024-09-12 15:37:12 🙌 Starting consensus session on top of parent 0x8af7c72457d437486fe697b4a11ef42b26c8b4448836bdb2220495aea39f53fd (#0) + 2024-09-12 15:37:12 🎁 Prepared block for proposing at 1 (6 ms) [hash: 0xb97cb3a4a62f0cb320236469d8e1e13227a15138941f3c9819b6b78f91986262; parent_hash: 0x8af7…53fd; extrinsics (1): [0x1ef4…eecb] + 2024-09-12 15:37:12 🔖 Pre-sealed block for proposal at 1. Hash now 0x05115677207265f22c6d428fb00b65a0e139c866c975913431ddefe291124f04, previously 0xb97cb3a4a62f0cb320236469d8e1e13227a15138941f3c9819b6b78f91986262. + 2024-09-12 15:37:12 🏆 Imported #1 (0x8af7…53fd → 0x0511…4f04) + 2024-09-12 15:37:15 💤 Idle (1 peers), best: #1 (0x0511…4f04), finalized #0 (0x8af7…53fd), ⬇ 0.5kiB/s ⬆ 0.6kiB/s + 2024-09-12 15:37:18 🏆 Imported #2 (0x0511…4f04 → 0x17a7…a1fd) + 2024-09-12 15:37:20 💤 Idle (1 peers), best: #2 (0x17a7…a1fd), finalized #0 (0x8af7…53fd), ⬇ 0.6kiB/s ⬆ 0.5kiB/s + 2024-09-12 15:37:24 🙌 Starting consensus session on top of parent 0x17a77a8799bd58c7b82ca6a1e3322b38e7db574ee6c92fbcbc26bbe5214da1fd (#2) + 2024-09-12 15:37:24 🎁 Prepared block for proposing at 3 (1 ms) [hash: 0x74d78266b1ac2514050ced3f34fbf98a28c6a2856f49dbe8b44686440a45f879; parent_hash: 0x17a7…a1fd; extrinsics (1): [0xe35f…8d48] + 2024-09-12 15:37:24 🔖 Pre-sealed block for proposal at 3. Hash now 0x12cc1e9492988cfd3ffe4a6eb3186b1abb351a12a97809f7bae4a7319e177dee, previously 0x74d78266b1ac2514050ced3f34fbf98a28c6a2856f49dbe8b44686440a45f879. + 2024-09-12 15:37:24 🏆 Imported #3 (0x17a7…a1fd → 0x12cc…7dee) + 2024-09-12 15:37:25 💤 Idle (1 peers), best: #3 (0x12cc…7dee), finalized #1 (0x0511…4f04), ⬇ 0.5kiB/s ⬆ 0.6kiB/s +
diff --git a/polkadot-protocol/protocol-components/transactions/transactions-formats.md b/polkadot-protocol/protocol-components/transactions/transactions-formats.md index 59bc0c71..bc8e6ba1 100644 --- a/polkadot-protocol/protocol-components/transactions/transactions-formats.md +++ b/polkadot-protocol/protocol-components/transactions/transactions-formats.md @@ -11,9 +11,9 @@ This article describes the data structure of signed and unsigned transactions in Extrinsics normally contain a signature, some data to describe whether the extrinsic has passed some validity checks, and a reference to the pallet and call that it is intended for. This format provides a way for applications to ensure that the requirements for an extrinsic are met and correctly constructed. -- [**Unchecked**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs#L70){target=\_blank} - signed transactions requiring some validation check before being accepted in the transaction pool. Any unchecked extrinsic contains the signature for the sent data and some extra data -- [**Checked**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/generic/checked_extrinsic.rs#L35){target=\_blank} - inherent extrinsics, which, by definition, don't require signature verification. Instead, they carry information on where the extrinsic comes from and some extra data -- [**Opaque**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/lib.rs#L915){target=\_blank} - used for cases when an extrinsic hasn't yet been committed to a format but can still be decoded +- [**Unchecked**](https://paritytech.github.io/polkadot-sdk/master/sp_runtime/generic/struct.UncheckedExtrinsic.html){target=\_blank} - signed transactions requiring some validation check before being accepted in the transaction pool. Any unchecked extrinsic contains the signature for the sent data and some extra data +- [**Checked**](https://paritytech.github.io/polkadot-sdk/master/sp_runtime/generic/struct.CheckedExtrinsic.html){target=\_blank} - inherent extrinsics, which, by definition, don't require signature verification. Instead, they carry information on where the extrinsic comes from and some extra data +- [**Opaque**](https://paritytech.github.io/polkadot-sdk/master/sp_runtime/struct.OpaqueExtrinsic.html){target=\_blank} - used for cases when an extrinsic hasn't yet been committed to a format but can still be decoded !!! note Inherents are unique, unsigned transactions created by block producers. They contain essential data for block construction, such as time stamps, storage verification proofs, and information about uncle blocks. @@ -79,12 +79,12 @@ The transaction queue regularly calls signed extensions to check that a transact In FRAME, a signed extension can hold any of the following types by default: -- [**`AccountId`**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1489){target=\_blank} - to encode the sender's identity -- [**`Call`**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1492){target=\_blank} - to encode the pallet call to be dispatched. This data is used to calculate transaction fees -- [**`AdditionalSigned`**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1496){target=\_blank} - to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction -- [**`Pre`**](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/runtime/src/traits.rs#L1499){target=\_blank} - to encode the information that can be passed from before a call is dispatched to after it gets dispatched +- [**`AccountId`**](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_frame/runtime/types_common/type.AccountId.html){target=\_blank} - to encode the sender's identity +- [**`Call`**](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_frame/traits/trait.SignedExtension.html#associatedtype.Call){target=\_blank} - to encode the pallet call to be dispatched. This data is used to calculate transaction fees +- [**`AdditionalSigned`**](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_frame/traits/trait.SignedExtension.html#associatedtype.AdditionalSigned){target=\_blank} - to handle any additional data to go into the signed payload. This allows you to attach any custom logic prior to dispatching a transaction +- [**`Pre`**](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_frame/traits/trait.SignedExtension.html#associatedtype.Pre){target=\_blank} - to encode the information that can be passed from before a call is dispatched to after it gets dispatched -FRAME's system pallet provides a [useful `SignedExtension` set](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/system/src/lib.rs#L79){target=\_blank} out of the box. +FRAME's system pallet provides a [useful `SignedExtension` set](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_frame/traits/trait.SignedExtension.html#provided-methods){target=\_blank} out of the box. ### Example