From 3f3a676007e5130a92ef6f0df11e6b6404b799ec Mon Sep 17 00:00:00 2001 From: gui Date: Fri, 16 Feb 2024 23:55:06 +0900 Subject: [PATCH 1/3] Update rust-basics.md (#2118) --- content/md/en/docs/learn/rust-basics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/md/en/docs/learn/rust-basics.md b/content/md/en/docs/learn/rust-basics.md index fae3279fa..cb01e8fa1 100644 --- a/content/md/en/docs/learn/rust-basics.md +++ b/content/md/en/docs/learn/rust-basics.md @@ -40,7 +40,7 @@ These macros allow you to focus on writing idiomatic Rust and application-specif Rust macros are a powerful tool to help ensure certain requirements are met (without re-writing code) such as the logic to be formatted in a specific way, specific checks are made, or some logic consists of specific data structures. This is especially useful to help developers write code that can integrate with the complexity of a Substrate runtime. -For example, the `#[frame_system::pallet]` macro is required in all FRAME pallets to help you correctly implement certain required attributes-such as storage items or externally callable functions-and make it compatible with the build process in `construct_runtime`. +For example, the `#[frame_support::pallet]` macro is required in all FRAME pallets to help you correctly implement certain required attributes-such as storage items or externally callable functions-and make it compatible with the build process in `construct_runtime`. Developing Substrate runtimes involves heavy use of Rust's attribute macros, which come in two flavors: derive attributes and custom attributes. When you're getting started with Substrate, it isn't so important to know exactly how they work, but rather to know that they exist that they empower you to write correct runtime code. From 673afeca47eabb9e35781573405cbe1e0497bc81 Mon Sep 17 00:00:00 2001 From: gui Date: Fri, 16 Feb 2024 23:55:15 +0900 Subject: [PATCH 2/3] Improved english? (#2116) * Update transaction-lifecycle.md * Update transaction-lifecycle.md * Update transaction-lifecycle.md * Update accounts-addresses-keys.md * Update accounts-addresses-keys.md --- content/md/en/docs/learn/accounts-addresses-keys.md | 4 ++-- content/md/en/docs/learn/transaction-lifecycle.md | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/content/md/en/docs/learn/accounts-addresses-keys.md b/content/md/en/docs/learn/accounts-addresses-keys.md index 6e32550b1..a7c538598 100644 --- a/content/md/en/docs/learn/accounts-addresses-keys.md +++ b/content/md/en/docs/learn/accounts-addresses-keys.md @@ -20,7 +20,7 @@ The secret seed phrase is important because it can be used to recover access to For most networks, the **public key** associated with an account is how that account is identified on the network and some form of it is used as the destination address for transactions. However, Substrate-based chains use the underlying public key to derive one or more **public addresses**. -Instead of using the public key directly, Substrate allows you generate multiple addresses and address formats for an account. +Instead of using the public key directly, Substrate allows you to generate multiple addresses and address formats for an account. ## Address encoding and chain-specific addresses @@ -74,7 +74,7 @@ For more information about working with generic types, see [Rust for Substrate]( ## Specialized accounts -As a flexible and module framework for blockchain development, Substrate itself doesn't require you define or use any specific type of accounts. +As a flexible and module framework for blockchain development, Substrate itself doesn't require you to define or use any specific type of accounts. However, different chains can implement different rules for how accounts and the keys that control them are used. For example, you might implement specialized accounts if your application requires: diff --git a/content/md/en/docs/learn/transaction-lifecycle.md b/content/md/en/docs/learn/transaction-lifecycle.md index 9f85e1c1b..fdb419855 100644 --- a/content/md/en/docs/learn/transaction-lifecycle.md +++ b/content/md/en/docs/learn/transaction-lifecycle.md @@ -81,8 +81,8 @@ If a transaction is invalid—for example, because it is too large or doesn't co A transaction might be rejected for any of the following reasons: - The transaction has already been included in a block so it is dropped from the verifying queue. -- The transaction's signature is invalid, so it is immediately be rejected. -- The transaction is too large to fit in the current block, so it is be put back in a queue for a new verification round. +- The transaction's signature is invalid, so it is immediately rejected. +- The transaction is too large to fit in the current block, so it is put back in a queue for a new verification round. ## Transactions ordered by priority @@ -136,7 +136,7 @@ Before committing any state changes to storage, the runtime logic should perform Note that [events](/build/events-and-errors/) are also written to storage. Therefore, the runtime logic should not emit an event before performing the complementary actions. -If a transaction fails after an event is emitted, the event is not be reverted. +If a transaction fails after an event is emitted, the event is not reverted. ### Finalizing a block From 212b3df1e4547e2e83efdd99d44052f5c9ae3f7b Mon Sep 17 00:00:00 2001 From: gui Date: Fri, 16 Feb 2024 23:55:21 +0900 Subject: [PATCH 3/3] Update rust-basics.md (#2117) --- content/md/en/docs/learn/rust-basics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/md/en/docs/learn/rust-basics.md b/content/md/en/docs/learn/rust-basics.md index cb01e8fa1..5ac29bc48 100644 --- a/content/md/en/docs/learn/rust-basics.md +++ b/content/md/en/docs/learn/rust-basics.md @@ -17,7 +17,7 @@ Being the language of choice for Substrate, Rust is a highly performant programm ## Rust in Substrate -In the [Architecture]() section, you will learn that Substrate is made of two distinct architectural components: the outer node and the runtime. +In the [Architecture](/learn/architecture/) section, you will learn that Substrate is made of two distinct architectural components: the outer node and the runtime. While more complex features in Rust such as multithreading and asynchronous Rust are used in the outer node code, they aren't directly exposed to runtime engineers, making it easier for runtime engineers to focus on the business logic of their node. Generally, depending on their focus, developers should expect to know: