w3b3d3v · danicuki · Jul 24, 2024 · Jul 22, 2024 · Jul 22, 2024
diff --git a/Rust_State_Machine/en/Section_0/Lesson_1_What_Are_We_Building.md b/Rust_State_Machine/en/Section_0/Lesson_1_What_Are_We_Building.md
@@ -4,7 +4,9 @@ You've made it — hell yeah! Welcome to the Rust state machine tutorial :)
 This is Dani (@danicuki) and Yan (@nomadbitcoin) and we'll be your instructors. 
 This project is for devs that want to get more into the Polkadot Stack based on Substrate and the Rust programming language.
 
-This is a guided tutorial intended to teach readers the basics of Rust, Blockchain, and eventually the inner workings of the [Polkadot SDK](https://github.com/paritytech/polkadot-sdk).
+This learning journey created by WEB3DEV was based on the **Rust State Machine project by Shawn Tabrizi**, who deserves our immense recognition for his beautiful work and thanks for sharing his vast knowledge with us.
+
+The aim of this tutorial is to teach developers the basics of Rust, Blockchain and, eventually, the inner workings of the [Polkadot SDK](https://github.com/paritytech/polkadot-sdk).
 
 It has been my experience that the hardest part of building your first blockchain using the Polkadot SDK is navigating the advance Rust features used by [Substrate](https://github.com/paritytech/polkadot-sdk/tree/master/substrate), and understanding the underlying magic behind various macros which generate code for you.
 

diff --git a/Rust_State_Machine/en/Section_2/Lesson_1_System_Pallet.md b/Rust_State_Machine/en/Section_2/Lesson_1_System_Pallet.md
@@ -10,6 +10,8 @@ Then you will integrate both the Balances Pallet and System Pallet into your sta
 
 # Introduce the System Pallet
 
+[Youtube](https://www.youtube.com/watch?v=ROioE9Tlrmc)
+
 We have basically completed the creation of a basic Balances Pallet. This is the pallet that most users will interact with.
 
 However, your blockchain usually needs to keep track of many other pieces of data to function properly.

diff --git a/Rust_State_Machine/en/Section_2/Lesson_2_Block_Number_and_Nonce.md b/Rust_State_Machine/en/Section_2/Lesson_2_Block_Number_and_Nonce.md
@@ -8,6 +8,8 @@ Let's add functions which make it useful.
 
 ## Block Number
 
+[Youtube](https://www.youtube.com/watch?v=fd5NtxPJ83s)
+
 Your blockchain's blocknumber is stored in the System Pallet, and the System Pallet needs to expose functions which allow us to access and modify the block number.
 
 For this we need two simple functions:

diff --git a/Rust_State_Machine/en/Section_2/Lesson_3_Runtime.md b/Rust_State_Machine/en/Section_2/Lesson_3_Runtime.md
@@ -18,6 +18,8 @@ Certainly this sounds pretty abstract, but it will make more sense as we complet
 
 ## Create the Runtime
 
+[Youtube](https://www.youtube.com/watch?v=KwyeSU0wl_w)
+
 Just like our Pallets, our Runtime will be represented with a simple `struct`, however in this case, the fields of our `struct` will be our Pallets!
 
 Complete the instructions for creating a new runtime which includes our System and Balances pallets. For this, you will need to take advantage of the `new()` functions we exposed for each of the Pallets.

diff --git a/Rust_State_Machine/en/Section_2/Lesson_4_Executing_Runtime.md b/Rust_State_Machine/en/Section_2/Lesson_4_Executing_Runtime.md
@@ -8,6 +8,8 @@ Let's change that by using our Runtime and actually executing logic on our block
 
 ## Simulating a Block
 
+[Youtube](https://www.youtube.com/watch?v=38CPh4HK8ZQ)
+
 The input to any blockchain state transition function is a block of transactions.
 
 Later in the tutorial we will actually spend more time to build proper blocks and execute them, but for now, we can "simulate" all the basics of what a block would do by individually calling the functions our Pallets expose.

diff --git a/Rust_State_Machine/en/Section_2/Lesson_5_Runtime_Debug.md b/Rust_State_Machine/en/Section_2/Lesson_5_Runtime_Debug.md
@@ -6,6 +6,8 @@ In Rust, `derive` macros provide a convenient way to automatically implement tra
 
 ## Macros
 
+[Youtube](https://www.youtube.com/watch?v=si7wrJ6J66A)
+
 In the most simple terms, Macros are rust code that write more rust code.
 
 Macros can make your code easier to read, help avoid repetition, and even let you create your own special rules for coding in Rust.

diff --git a/Rust_State_Machine/en/Section_3/Lesson_1_Generic_Types.md b/Rust_State_Machine/en/Section_3/Lesson_1_Generic_Types.md
@@ -4,6 +4,8 @@ Fantastic! You now understand the importance of the Genesis State and are ready
 
 # Generic and Configurable Types
 
+[Youtube](https://www.youtube.com/watch?v=avNPoSDGiv4)
+
 In this section, we will be harnessing the full power of Rust to create a generic and configurable Runtime.
 
 There will be no real logical changes happening in the next steps.

diff --git a/Rust_State_Machine/en/Section_3/Lesson_2_Num_Crate.md b/Rust_State_Machine/en/Section_3/Lesson_2_Num_Crate.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Import the Num Crate
 
+[Youtube](https://www.youtube.com/watch?v=PpLmza4FF08)
+
 Rust is designed to be very lightweight and provides very little right out of the box.
 
 Within the ecosystem, many functions and features which you might expect to be included into Rust `std` or `core` are actually delegated to small, well-known, and widely used crates.

diff --git a/Rust_State_Machine/en/Section_3/Lesson_3_Make_Balances_Pallet_Generic.md b/Rust_State_Machine/en/Section_3/Lesson_3_Make_Balances_Pallet_Generic.md
@@ -1,5 +1,7 @@
 # Make Balances Pallet Generic
 
+[Youtube](https://www.youtube.com/watch?v=ix61ZRqkl20)
+
 Our goal over the next few steps will be to continually make our runtime more generic and configurable over the types we use in our Pallets.
 
 ## Why Generic?

diff --git a/Rust_State_Machine/en/Section_3/Lesson_4_Make_System_Pallet_Generic.md b/Rust_State_Machine/en/Section_3/Lesson_4_Make_System_Pallet_Generic.md
@@ -4,6 +4,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 ### Make System Pallet Generic
 
+[Youtube](https://www.youtube.com/watch?v=uQFrV3OowTw)
+
 Now that you have some practice with the Balances Pallet, let's do the same task for the System Pallet.
 
 1. In this case we need to make System generic over `AccountId`, `BlockNumber`, and `Nonce`.

diff --git a/Rust_State_Machine/en/Section_3/Lesson_5_Make_System_Configurable.md b/Rust_State_Machine/en/Section_3/Lesson_5_Make_System_Configurable.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Make System Configurable
 
+[Youtube](https://www.youtube.com/watch?v=6KP4o5HPIrg)
+
 We have one more step to take to make our Runtime as generic and configurable as possible.
 
 To do it, we will need to take advantage of traits.

diff --git a/Rust_State_Machine/en/Section_3/Lesson_6_Make_Balances_Configurable.md b/Rust_State_Machine/en/Section_3/Lesson_6_Make_Balances_Configurable.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Make Balances Configurable
 
+[Youtube](https://www.youtube.com/watch?v=3CRrFloyaRU)
+
 There is nothing new to learn in this step, just repeating the same process we did for our System Pallet for the Balances pallet.
 
 In this case, our `Config` trait will only have two associated types: `AccountId` and `Balance`.

diff --git a/Rust_State_Machine/en/Section_3/Lesson_7_Tight_Coupling.md b/Rust_State_Machine/en/Section_3/Lesson_7_Tight_Coupling.md
@@ -8,6 +8,8 @@ We wouldn't want this on a real production blockchain. Instead, we would want to
 
 ## Trait Inheritance
 
+[Youtube](https://www.youtube.com/watch?v=T4oMp-L8EPs)
+
 Rust has the ability for traits to inherit from one another. That is, that for you to implement some trait, you also need to implement all traits that it inherits.
 
 Let's look at some examples.

diff --git a/Rust_State_Machine/en/Section_4/Lesson_1_Executing_Blocks_and_Dispatching_Calls.md b/Rust_State_Machine/en/Section_4/Lesson_1_Executing_Blocks_and_Dispatching_Calls.md
@@ -12,6 +12,8 @@ The goal of this section is to make your existing state machine resemble a block
 
 # Add Our Support Module
 
+[Youtube](https://www.youtube.com/watch?v=WBasxmMvwCc)
+
 In this step, we will introduce a `support` module to help bring in various types and traits that we will use to enhance our simple state machine.
 
 ## Constructing a Block

diff --git a/Rust_State_Machine/en/Section_4/Lesson_2_Block_Type.md b/Rust_State_Machine/en/Section_4/Lesson_2_Block_Type.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Create Your Block Type
 
+[Youtube](https://www.youtube.com/watch?v=eIHxIr_zeq0)
+
 The support module provided for us a bunch of generic types which can be customized for our simple state machine. To actually start using them, we need to define concrete versions of these types using our other concrete types.
 
 ## Runtime Call

diff --git a/Rust_State_Machine/en/Section_4/Lesson_3_Executing_Blocks.md b/Rust_State_Machine/en/Section_4/Lesson_3_Executing_Blocks.md
@@ -6,6 +6,8 @@ We will now start the process to replace the simple block simulation in our `mai
 
 ## Execute Block
 
+[Youtube](https://www.youtube.com/watch?v=nWmSo6tfeog)
+
 We have introduced a new function to our `Runtime` called `fn execute_block`.
 
 The steps of this function is exactly the same as our current `main` function, but using the concrete `Block` type we defined to extract details like the expected block number and the extrinsics that we want to execute.

diff --git a/Rust_State_Machine/en/Section_4/Lesson_4_Dispatching_Calls.md b/Rust_State_Machine/en/Section_4/Lesson_4_Dispatching_Calls.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Dispatching Calls
 
+[Youtube](https://www.youtube.com/watch?v=xr5gFayr67A)
+
 We have built our `execute_block` logic depending on the `dispatch` logic we have not implemented yet.
 
 Let's do that.

diff --git a/Rust_State_Machine/en/Section_4/Lesson_5_Execute_Block_With_Extrinsics.md b/Rust_State_Machine/en/Section_4/Lesson_5_Execute_Block_With_Extrinsics.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Using Execute Block
 
+[Youtube](https://www.youtube.com/watch?v=TOJXnXNuLFM)
+
 We have now successfully implemented the `execute_block` and `dispatch` logic needed to build and execute real `Blocks`.
 
 Let's bring that logic into our `main` function.

diff --git a/Rust_State_Machine/en/Section_4/Lesson_6_Pallet_Level_Dispatch.md b/Rust_State_Machine/en/Section_4/Lesson_6_Pallet_Level_Dispatch.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Pallet Level Dispatch
 
+[Youtube](https://www.youtube.com/watch?v=GPs7q1FYb1E)
+
 We want to make our code more modular and extensible.
 
 Currently, all dispatch happens through the `RuntimeCall`, which is hardcoding dispatch logic for each of the Pallets in our system.

diff --git a/Rust_State_Machine/en/Section_4/Lesson_7_Nested_Dispatch.md b/Rust_State_Machine/en/Section_4/Lesson_7_Nested_Dispatch.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Nested Dispatch
 
+[Youtube](https://www.youtube.com/watch?v=CYZ6Kwx7AWs)
+
 Now that we have defined Pallet level dispatch logic in the Pallet, we should update our Runtime to take advantage of that logic.
 
 After this, whenever the Pallet logic is updated, the Runtime dispatch logic will also automatically get updated and route calls directly. This makes our code easier to manage, and prevent potential errors or maintenance in the future.

diff --git a/Rust_State_Machine/en/Section_5/Lesson_1_The_Proof_of_Existence_Pallet.md b/Rust_State_Machine/en/Section_5/Lesson_1_The_Proof_of_Existence_Pallet.md
@@ -4,6 +4,8 @@ Congratulations! Your determination to push forward and tackle programming chall
 
 # The Proof of Existence Pallet
 
+[Youtube](https://www.youtube.com/watch?v=k8MEr54_-AI)
+
 In this section, we will create a Proof of Existence Pallet.
 
 We will take advantage of all the refactoring we have done so far to make it very simple to integrate this new Pallet into our existing Runtime.

diff --git a/Rust_State_Machine/en/Section_5/Lesson_2_Proof_Of_Existence_Functions.md b/Rust_State_Machine/en/Section_5/Lesson_2_Proof_Of_Existence_Functions.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Proof Of Existence Functions
 
+[Youtube](https://www.youtube.com/watch?v=I8W3GQU3Tyw)
+
 The Proof of Existence Pallet is quite simple, so let's build out the logic needed.
 
 ## Get Claim

diff --git a/Rust_State_Machine/en/Section_5/Lesson_3_Proof_of_Existence_Dispatch.md b/Rust_State_Machine/en/Section_5/Lesson_3_Proof_of_Existence_Dispatch.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Add Proof of Existence Dispatch
 
+[Youtube](https://www.youtube.com/watch?v=zw_mDF7YMGk)
+
 We have already established the nested dispatch pipeline for Pallets in the `Runtime`.
 
 Let's build Pallet level dispatch logic for the Proof of Existence to take advantage of that.

diff --git a/Rust_State_Machine/en/Section_5/Lesson_4_Integrate_Into_Runtime.md b/Rust_State_Machine/en/Section_5/Lesson_4_Integrate_Into_Runtime.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Integrate PoE Into Your Runtime
 
+[Youtube](https://www.youtube.com/watch?v=Ma7MzDVqjXY)
+
 The Proof of Existence pallet is done, but we still need to integrate it into your Runtime.
 
 Let's take a look at that process.

diff --git a/Rust_State_Machine/en/Section_5/Lesson_5_Add_Extrinsic_To_Block.md b/Rust_State_Machine/en/Section_5/Lesson_5_Add_Extrinsic_To_Block.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Add PoE Extrinsics to Blocks
 
+[Youtube](https://www.youtube.com/watch?v=za5kBf046FY)
+
 The Proof Of Existence Pallet is fully integrated into your runtime at this point, but we aren't really using it.
 
 Create some new `Block`s in your `fn main()` to test out the functionality of the Proof of Existence Pallet.

diff --git a/Rust_State_Machine/en/Section_6/Lesson_1_Rust_Macros.md b/Rust_State_Machine/en/Section_6/Lesson_1_Rust_Macros.md
@@ -4,6 +4,8 @@ Sensational! Few have reached this point, making you exceptionally persistent. G
 
 # Rust Macros
 
+[Youtube](https://www.youtube.com/watch?v=q9aZ0Lsl8sE)
+
 In this section, we will introduce Rust Macros to our project to reduce boilerplate code and automate implementations.
 
 You can imagine that continuing to add new Pallets to our runtime would lead to a lot of similar or redundant code.

diff --git a/Rust_State_Machine/en/Section_6/Lesson_2_Adding_Call_Macro_to_Balances.md b/Rust_State_Machine/en/Section_6/Lesson_2_Adding_Call_Macro_to_Balances.md
@@ -1,5 +1,7 @@
 # Adding Call Macro to Balances
 
+[Youtube](https://www.youtube.com/watch?v=jZvYteSLY2o&t=1s)
+
 Let's start by adding the `#[macros::call]` macro to our Balances Pallet.
 
 ## The Call Macro

diff --git a/Rust_State_Machine/en/Section_6/Lesson_3_Adding_Call_Macro_to_PoE.md b/Rust_State_Machine/en/Section_6/Lesson_3_Adding_Call_Macro_to_PoE.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Adding Call Macro to PoE
 
+[Youtube](https://www.youtube.com/watch?v=XZ0jFKl8gt0)
+
 We have already seen the `#[macros::call]` macro help clean up the Balances Pallet.
 
 Let's also add it to the Proof of Existence Pallet, where there is even more code that can be eliminated.

diff --git a/Rust_State_Machine/en/Section_6/Lesson_4_Use_the_Runtime_Macro.md b/Rust_State_Machine/en/Section_6/Lesson_4_Use_the_Runtime_Macro.md
@@ -6,6 +6,8 @@ Finally, let's add the `#[macros::runtime]` macro to our `main.rs` file, and rea
 
 ## Runtime Macro
 
+[Youtube](https://www.youtube.com/watch?v=VTg4SCSgfsI&t=1s)
+
 The purpose of the `#[macros::runtime]` macro is to get rid of all of the boilerplate function we implemented for the `Runtime`, including `fn new()` and `fn execute_block()`. Similar to the `Call` macro, it also generates the `enum RuntimeCall` and all the `dispatch` logic for re-dispatching to pallets.
 
 We apply the `#[macros::runtime]` attribute on top of the main `struct Runtime` object.

diff --git a/Rust_State_Machine/en/Section_6/Lesson_5_Course_Completed.md b/Rust_State_Machine/en/Section_6/Lesson_5_Course_Completed.md
@@ -2,6 +2,8 @@ You can find the [solution for the previous step here](https://gist.github.com/n
 
 # Final Thoughts
 
+[Youtube](https://www.youtube.com/watch?v=c1hWHQldpPg)
+
 ## Congratulations! You are a Rust superhero!
 
 If you’ve reached this point, having completed all the lessons and built your first blockchain using Rust from scratch, you are among the elite few who have accomplished this feat. Congratulations on this incredible achievement! Let's recap our journey: we created our blockchain using the pallets infrastructure, each responsible for specific functions. We developed the Balances pallet for managing user accounts and the Proof of Existence pallet for creating and revoking claims. We utilized macros to generate code efficiently, significantly reducing redundancy. This is just the beginning; there's much more to explore and learn.