Mar 28 wiki update (#123)

* Protocol: DS: Verkle Tree intro added (#110) * Protocol: DS: Verkle Tree intro added * Protocol: DS: typo * Update info on verkles --------- Co-authored-by: Mário Havel <[email protected]> * add week 6 to sidebar * Update week6-dev.md (#116) * add week 6 research * 📜 Adds History section (#52) * ➕ Adding The Merge to History section * 👷 Added post-merge block proposal steps * Lean changes --------- Co-authored-by: Mário Havel <[email protected]> * ✨ feat(EL): precompiled contracts (#106) * ✨ feat(EL): precompiled contracts * 🥢 nit(EL): clarity * 🥢 nit(EL): precompile vs opcode, proposed precompiles * add a resource --------- Co-authored-by: rahul <[email protected]> Co-authored-by: Mário Havel <[email protected]> * Update week6-research.md * eps updates * 🥢 nit: spelling (#120) Co-authored-by: rahul <[email protected]> * add week 6 resources * add week 7-dev --------- Co-authored-by: Abhimanyu <[email protected]> Co-authored-by: Hsiao-Wei Wang <[email protected]> Co-authored-by: GianfrancoBazzani <[email protected]> Co-authored-by: rahul <[email protected]> Co-authored-by: rahul <[email protected]> Co-authored-by: Josh <[email protected]>
eth-protocol-fellows · Mar 28, 2024 · cd0ee9c · cd0ee9c
1 parent 7356bb3
commit cd0ee9c
Show file tree

Hide file tree

Showing 11 changed files with 52 additions and 26 deletions.
diff --git a/docs/eps/nodes_workshop.md b/docs/eps/nodes_workshop.md
@@ -11,47 +11,47 @@ Make sure to prepare your enviroment and learn basics necessary to understand th
 
 ## Prerequisites
 
-Get yourself familiar with Ethereum client architecture as described in Week 1 and you can check Week 2 and 3 for even better understanding of what workshop executes. The workshop will default to geth+lighthouse but if you have other preffered client to try, make yourself familiar with its documentation. 
+Get yourself familiar with Ethereum client architecture as described in Week 1 and you can check Week 2 and 3 for even better understanding of what workshop executes. The workshop will default to geth+lighthouse but if you have other preferred client to try, make yourself familiar with its documentation. 
 
 - https://ethereum.org/en/developers/docs/nodes-and-clients/node-architecture/
 - https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/
-- Client documentation of your prefered client pair 
+- Client documentation of your preferred client pair 
 - Basic bash/cli shell skills 
     - https://btholt.github.io/complete-intro-to-linux-and-the-cli/, https://ubuntu.com/tutorials/command-line-for-beginners
 
-Prepare your enviroment, update the system and install dependencies so it doesn't block you during the workshop.  
+Prepare your environment, update the system and install dependencies so it doesn't block you during the workshop.  
 
-- The workshop enviroment will be fresh Debian 12 instance but you can use any prefered distro. Process might be very similar on other unix based systems like Mac but you can always setup a VM to replicate the enviroment. 
+- The workshop environment will be fresh Debian 12 instance but you can use any preferred distro. Process might be very similar on other unix based systems like Mac but you can always setup a VM to replicate the environment. 
 - Install basic utils we will need like curl, git, gpg, docker, compilers 
 
-We will only run a client on testnet so the hardware requirements are minimal - the goal of the workshop is not to sync the tip of the chain but only demostrate how the node works. Default client pair will be geth+lighthouse but if there is enough time we can demostrate switching the pair. 
+We will only run a client on testnet so the hardware requirements are minimal - the goal of the workshop is not to sync the tip of the chain but only demonstrate how the node works. Default client pair will be geth+lighthouse but if there is enough time we can demonstrate switching the pair. 
 
 ## Outline
 
 - Introduction to running nodes
-    - Choosing a client pair and enviroment
+    - Choosing a client pair and environment
 - Obtaining clients 
     - Downloading and verifying binary
     - Compiling a client? 
     - Docker setup? 
 - Client pair setup
     - Run EL+CL client on Holesky
-    - Running on Ephemery uing custom genesis 
+    - Running on Ephemery using custom genesis 
     - Switching CL or EL client
         - Nimbus? 
         - Erigon? 
 - Using the client
     - Accessing the RPC
         - http, console, wallet
         - Adding validators 
-- Additional excercies if there is time
+- Additional exercise if there is time
     - Systemd service
     - Monitoring node
 - After the stream, we can switch to [jitsi](meet.ethquokkaops.io/EPFsgWorkshop) for further discussion and troubleshooting
 
 ## Additional reading and exercises 
 
-There are bunch of things we are not going to demostrate during the workshop so you can try them yourself afterwards. 
+There are bunch of things we are not going to demonstrate during the workshop so you can try them yourself afterwards. 
 
 - Setup monitoring with Grafana dashboard which shows detailed information on various client parameters and functions
 - Enable higher logs verbosity, read client debug logs to learn about its low level processes 

diff --git a/docs/eps/presentations/week6_cl_specs.pdf b/docs/eps/presentations/week6_cl_specs.pdf
diff --git a/docs/eps/presentations/week6_el_specs.pdf b/docs/eps/presentations/week6_el_specs.pdf
diff --git a/docs/eps/presentations/week6_research.pdf b/docs/eps/presentations/week6_research.pdf
diff --git a/docs/eps/week6-dev.md b/docs/eps/week6-dev.md
@@ -2,8 +2,7 @@
 
 The development track of week 6 will provide a deeper insight into consensus and execution layer specification. 
 
-
-Watch presentations from [Hsiao-Wei](https://twitter.com/icebearhww) and [Sam](https://twitter.com/_SamWilsn_) on StreamEth or Youtube.
+Watch presentations from [Hsiao-Wei](https://twitter.com/icebearhww) and [Sam](https://twitter.com/_SamWilsn_) on StreamEth or Youtube. Slides are available for both [consensus specs](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week6_cl_specs.pdf) and [execution specs](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week6_el_specs.pdf) talks.
 
 <iframe width="560" height="315" src="https://www.youtube.com/embed/_mb0LFJY8t0?si=M74zgvUuewCrUtJF" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
 

diff --git a/docs/eps/week6-research.md b/docs/eps/week6-research.md
@@ -2,10 +2,9 @@
 
 Week 6 research track is going to be a dive into data availability sampling and danksharding. 
 
-Join the presentation by [Dankrad](https://twitter.com/dankrad) on [Wednesday, March 27, 4PM UTC](https://savvytime.com/converter/utc-to-germany-berlin-united-kingdom-london-ny-new-york-city-ca-san-francisco-china-shanghai-japan-tokyo-australia-sydney/mar-27-2024/4pm).
+Watch the presentations by [Dakrad](https://twitter.com/dankrad) on StreamEth or Youtube. Slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week6_research.pdf). 
 
-
-The talk will be streamed live on [StreamEth](https://streameth.org/65cf97e702e803dbd57d823f/epf_study_group) and Youtube, links will be provided before the call in the [Discord server](https://discord.gg/addwpQbhpq). Discord also serves for the discussion and questions during the stream. 
+<iframe width="560" height="315" src="https://www.youtube.com/embed/ro2AGRkLC2s?si=IaNwL7OXl5tQvqOM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
 
 ## Pre-reading
 
@@ -14,14 +13,13 @@ Before starting with the week 6 content, make yourself familiar with resources i
 Additionally, you can read and get ready by studying the following resources:
 
 - [Data availability problem](https://www.youtube.com/watch?v=OJT_fR7wexw)
-- [Danksharding by Dankrad, 2022](https://www.youtube.com/watch?v=1Cg2iu4C4sU)
 - [Sharding and DAS proposal](https://hackmd.io/@vbuterin/sharding_proposal)
 
 ## Outline
 
-- Polynomial commitment schemes
+- Ethereum scalability
+- History of sharding and path forward
 - Data availability
-- Sharding
 
 ## Additional reading and exercises 
 

diff --git a/docs/eps/week7-dev.md b/docs/eps/week7-dev.md
@@ -0,0 +1,29 @@
+# Study Group Week 7 | Execution client architecture
+
+Week 7 development track is an insight into Ethereum execution layer client codebase, explaining its architecture and highlighting novel approaches. 
+
+The presentation will be given by [Dragan](https://twitter.com/rakitadragan) who will dive into reth client codebase. Join the talk on [Monday, Aprol 1, 4PM UTC](https://savvytime.com/converter/utc-to-germany-berlin-united-kingdom-london-ny-new-york-city-ca-san-francisco-china-shanghai-japan-tokyo-australia-sydney/april-01-2024/4pm).
+
+The talk will be streamed live on [StreamEth](https://streameth.org/65cf97e702e803dbd57d823f/epf_study_group) and [Youtube](https://www.youtube.com/@ethprotocolfellows/streams), links will be provided before the call in the [Discord server](https://discord.gg/addwpQbhpq). Discord also serves for the discussion and questions during the stream. 
+
+## Pre-reading
+
+Before starting with the week 7 development content, make yourself familiar with resources in previous weeks, especially 2. The execution client intro provided an important knowledge about execution client and its main features with examples from geth codebase. This talk will be diving into reth client design which is written in rust and developed with a modern design approach to EL clients. 
+
+Additionally, you can read and get ready by studying the following resources:
+
+- Reth docs https://paradigmxyz.github.io/reth/
+- Intro to Reth by Georgios https://www.youtube.com/watch?v=zntRpCKHyDc
+- Deeper insight by Dragan https://www.youtube.com/watch?v=pxhq7YrySRM
+
+## Outline
+
+- Reth client 
+- Design and architecture
+- Codebase overview, examples 
+- Features and highlights 
+
+## Additional reading and exercises 
+
+- Erigon is a fork of geth which pioneered the design approached implemented by reth. Kind of a middle ground between geth and reth, tt's a great source of resources about novel execution client designs
+- As an excercise, run reth and set different `DEBUG` options to explore how various client componantes operate on lower level
diff --git a/docs/wiki/Cryptography/keccak256.md b/docs/wiki/Cryptography/keccak256.md
@@ -26,7 +26,7 @@ The sponge function, central to Keccak's design, operates in two distinct phases
 For a deeper understanding of Keccak's internal workings, the [Keccak reference](https://keccak.team/files/CSF-0.1.pdf) provides detailed insights into its algorithms and security features.
 
 ## EVM Implementation
-The EVM (Ethereum Virtual Machine) processes the excution of transactions for the Ethereum blockchain with a stack based architecture. EVM opcodes are predefined instructions that the EVM interprets and subsequently executes to fulfill transaction and run the smart contracts. There are arthmetic, environmental, control flow, and stack operations Opcodes. Now there is no keccak256 opcode, but there is a SHA3 opcode. The SHA3 opcode is used to encrypt input data from the stack and outputs a Keccak256 hash.
+The EVM (Ethereum Virtual Machine) processes the execution of transactions for the Ethereum blockchain with a stack based architecture. EVM opcodes are predefined instructions that the EVM interprets and subsequently executes to fulfill transaction and run the smart contracts. There are arithmetic, environmental, control flow, and stack operations Opcodes. Now there is no keccak256 opcode, but there is a SHA3 opcode. The SHA3 opcode is used to encrypt input data from the stack and outputs a Keccak256 hash.
 
 The [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf), outlines other implementations of Keccak256 in the Ethereum blockchain:
 

diff --git a/docs/wiki/EL/JSON-RPC.md b/docs/wiki/EL/JSON-RPC.md
@@ -83,8 +83,8 @@ Here are basic examples of debug methods:
 
 #### Engine
 
-[Engine API](https://hackmd.io/@danielrachi/engine_api) is different from aforementioned methods. Clients serve Engine API on a different and authenticated endpoint rather than normal http JSON RPC because it is not a user facing API. It's intented for connection between consensus and execution client, making it basically an internal node communication process. 
-Inter-client communication exchanging information about conesnsus, forkchoice, validation of blocks, etc: 
+[Engine API](https://hackmd.io/@danielrachi/engine_api) is different from aforementioned methods. Clients serve Engine API on a different and authenticated endpoint rather than normal http JSON RPC because it is not a user facing API. It's intended for connection between consensus and execution client, making it basically an internal node communication process. 
+Inter-client communication exchanging information about consensus, forkchoice, validation of blocks, etc: 
 
 | **Method**                               |               **Params**               | **Description**                                                           |
 |------------------------------------------|:--------------------------------------:|---------------------------------------------------------------------------|

diff --git a/docs/wiki/protocol/data-structures.md b/docs/wiki/protocol/data-structures.md
@@ -9,10 +9,10 @@ A Merkle tree stores all the transactions in a block by producing a digital fing
 It is important to note that Merkle trees are in a **binary tree**, so it requires an even number of leaf nodes. If there is an odd number of transactions, the last hash will be duplicated once to create an even number of leaf nodes.
 
 Merkle Trees provide a tamper-proof structure to store transaction data. Hash functions have an Avalanche Effect i.e. a small change in the data will result in a huge change in the resulting hash. Hence, if the data in the leaf nodes are ever modified, the Root Hash will not match the expected value.
-You can try out [SHA-256](https://emn178.github.io/online-tools/sha256.html) hashing function youself as well.
+You can try out [SHA-256](https://emn178.github.io/online-tools/sha256.html) hashing function yourself as well.
 To learn more about Hashing, you may refer to [this](https://github.com/ethereumbook/ethereumbook/blob/develop/04keys-addresses.asciidoc)
 
-Merkle Root is stored in the **Block Header**. Read more about the strucutre of a Block inside Ethereum (_will be linked this to relevant doc once its ready_)
+Merkle Root is stored in the **Block Header**. Read more about the structure of a Block inside Ethereum (_will be linked this to relevant doc once its ready_)
 
 The main parent node is called Root, hence the hash inside is Root Hash. There is infinitesimally small chance(1 in 1.16x10^77 for a single SHA-256 hash) to create two different states with the same root hash, and any attempt to modify state with different values will result in a different state root hash.
 
@@ -31,7 +31,7 @@ More on [Merkle Trees in Ethereum](https://blog.ethereum.org/2015/11/15/merkling
 
 ## Primer on Patricia Tree
 
-Patricia Tries (also called Radix tree) are n-ary trees which unlike Merkel Trees,is used for storage of data instead of verification.
+Patricia Tries (also called Radix tree) are n-ary trees which unlike Merkle Trees,is used for storage of data instead of verification.
 
 Simply put, Patricia Tries is a tree data structure where all the data is store in the leaf nodes, and each non-leaf nodes is a character of a unique string identifying the data. Using the unique string we navigate through the character nodes and finally reach the data. Hence, it is very efficient at data retrieval.
 
@@ -83,7 +83,7 @@ The structure `T` consists of the following:
 - **maxFeePerGas** - the maximum fee per unit of gas willing to be paid for the transaction (including baseFeePerGas and maxPriorityFeePerGas)
 - **from** – The address of the sender, that will be signing the transaction. This must be an externally-owned account as contract accounts cannot send transactions.
 - **to**: Address of an account to receive funds, or zero for contract creation.
-- **value**: amount of ETH to transfer from sender to recipien.
+- **value**: amount of ETH to transfer from sender to recipient.
 - **input data** – optional field to include arbitrary data
 - **data**: Input data for a message call together with the message signature.
 - **(v, r, s)**: Values encoding signature of a sender. Serves as identifier of the sender
@@ -121,7 +121,7 @@ Using the information inside the block, client should also be able to maintain/g
 
 Verkle trees are designed to be more efficient in terms of storage and communication cost. For a 1000 leaves/data, a binary Merkle Tree takes around 4MB of witness data, Verkle tree reduces it to 150 kB. If we include the witness data in the block then it will not impact the blocksize that much but it would enable the stateless clients to be more efficient and scalable. Using this the stateless client will be able to trust the computation done without having to store the entire state.
 
-The transition to new verkle tree database poses a major challenge. To securily create the new verkle data, clients needs to generate them from the existing MPT which takes a lot of computation and space. Distribution and verification of the verkled databased is currently being researched. 
+The transition to new verkle tree database poses a major challenge. To securily create the new verkle data, clients needs to generate them from the existing MPT which takes a lot of computation and space. Distribution and verification of the verkled database is currently being researched. 
 
 ## Resources
 

diff --git a/docs/wiki/protocol/history.md b/docs/wiki/protocol/history.md
@@ -8,7 +8,7 @@ TODO
 
 ## The Merge.
 
-On September 15, 2022, Ethereum activated [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675) and upgraded the consensus mechanism to proof-of-stake through an event known as The Merge. The Merge has resulted in the deprecation of the proof-of-work consensus, which was previously implemented in the same logic layer as execution. Instead, it has been replaced by a more complex and sophisticated proof-of-stake consensus that eliminates the need for energy-intensive mining. New proof-of-stake consensus has been implemented in its own layer with a separate p2p networka and logic, also know as Beacon Chain. The Beacon Chain has been running and achieving consensus since December 1st, 2020. After a prolonged period of consistent performance without any failures, it was deemed ready to become Ethereum's consensus provider. The Merge gets its name from the union of the two networks.
+On September 15, 2022, Ethereum activated [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675) and upgraded the consensus mechanism to proof-of-stake through an event known as The Merge. The Merge has resulted in the deprecation of the proof-of-work consensus, which was previously implemented in the same logic layer as execution. Instead, it has been replaced by a more complex and sophisticated proof-of-stake consensus that eliminates the need for energy-intensive mining. New proof-of-stake consensus has been implemented in its own layer with a separate p2p network and logic, also know as Beacon Chain. The Beacon Chain has been running and achieving consensus since December 1st, 2020. After a prolonged period of consistent performance without any failures, it was deemed ready to become Ethereum's consensus provider. The Merge gets its name from the union of the two networks.
 
 Learn more about The Merge in following resources and reading on Consensus layer.