Merge pull request #141 from eth-protocol-fellows/main

Wiki update

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,17 @@
+# Checklist
+
+- [ ] Review changes to ensure there are no typos.
+
+<!-- 
+ℹ️ Checking for typos locally
+1. Install [aspell](https://www.gnu.org/software/aspell/) for your platform.
+2. Navigate to the project root and run:
+```
+ for f in **/*.md ; do echo $f ; aspell --lang=en_US --mode=markdown --home-dir=. --personal=wordlist.txt --ignore-case=true list  < $f | sort | uniq -c ; done
+```
+
+ℹ️ Fixing typos
+1. Fix typos: Open the relevant files and fix any identified typos.
+2. Update wordlist: If a flagged word is actually a project-specific term add it to `wordlist.txt` in the project root.
+   Each word should be listed on a separate line and must not have any spaces or special characters before or after it.
+-->

.github/workflows/spell-check.yml

@@ -0,0 +1,75 @@
+name: 🥢 Spell check 
+
+on:
+  pull_request:
+    branches:
+      - main
+
+jobs:
+  typo_check:
+    name: 🥢 Spell check
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: write
+    env: 
+      TYPOS: ""
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v2
+        with:
+          ref: ${{ github.event.pull_request.head.sha }}
+          fetch-depth: 2
+
+      - name: Install aspell
+        run: sudo apt-get update && sudo apt-get install -y aspell
+
+      - name: Find and check typos in Markdown files
+        id: find_typos
+        run: |
+          echo "Checking for typos..."
+          for file in $(find . -name "*.md" ); do
+            output="$(aspell --lang=en_US --mode=markdown --home-dir=. --personal=wordlist.txt --ignore-case=true list <$file | sed 's/^/    1. /')"
+            if [[ -n "$output" ]]; then
+              TYPOS+="- 📄 $file:"
+              TYPOS+=$'\n'
+              TYPOS+="$output"
+              TYPOS+=$'\n'
+            fi
+          done
+          {
+            echo 'TYPOS<<EOF'
+            echo "$TYPOS"
+            echo EOF
+          } >> "$GITHUB_ENV"
+
+      - name: Comment on pull request
+        if: env.TYPOS != ''
+        uses: actions/github-script@v4
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          script: |
+            const author = '${{github.event.pull_request.user.login}}';
+            const typos = `${{ env.TYPOS }}`;
+            const body = `
+            Hi @${author},
+
+            Following typos were found in the pull request:
+            
+            ${typos}
+
+            ## ℹ️ Here's how to fix them:
+            - **Fix typos:** Open the relevant files and fix any identified typos.
+            - **Update wordlist:** If a flagged word is actually a project-specific term add it to \`wordlist.txt\` in the project root.
+                Each word should be listed on a separate line and must not have any spaces or special characters before or after it. [Learn more.](http://aspell.net/man-html/Format-of-the-Personal-and-Replacement-Dictionaries.html)
+            `;
+
+            github.issues.createComment({
+              issue_number: context.issue.number,
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+              body: body
+            });
+
+            core.setFailed('🥢 Spell check: Typos found in docs. Please fix them.');

docs/contributing.md

@@ -6,7 +6,7 @@ The Protocol Wiki is an open and collaborative project. Whether you are part of
 
 When creating contributions, consider whether it doesn't exist in another form elsewhere. Use it and reference it in your text but do not copy its content. Focus on adding it into a big picture, connecting it with related topics. 
 
-Write contributions based on what you learned about the protocol along the way, what experience you gathered and missing pieces that slowed you down. Consider it as explaining to your peers, reflect on your own journey as a core developer/reseacher.
+Write contributions based on what you learned about the protocol along the way, what experience you gathered and missing pieces that slowed you down. Consider it as explaining to your peers, reflect on your own journey as a core developer/researcher.
 
 ## Contributing
 
@@ -22,9 +22,9 @@ We are not aiming to recreate other existing wikis. If the same content is well
 
 ### What does(n't) belong here
 
-The scope of this wiki is limited to technical resources of the Ethereum core protocol infrastracture. This means its specifications, implementations, testing, research or related tooling. 
+The scope of this wiki is limited to technical resources of the Ethereum core protocol infrastructure. This means its specifications, implementations, testing, research or related tooling. 
 
-It **does not** cover onchain protocols/dapps, layer 2s/rollups or any other tools which are not dependencies of core infrastracture. In other words, stuff which would be covered by EIPs, not ERCs.
+It **does not** cover onchain protocols/dapps, layer 2s/rollups or any other tools which are not dependencies of core infrastructure. In other words, stuff which would be covered by EIPs, not ERCs.
 
 ### Structure and collaboration
 
@@ -81,7 +81,7 @@ Goal is to produce a credible neutral text which is formal, well-structured, and
 
 The wiki uses American English over British spelling. Terminology, capitalization and nomenclature should match across all pages. Use [Ethereum.org guide](https://ethereum.org/contributing/style-guide/content-standardization) for the reference. 
 
-Usage of images and visualizations is encouraged. If you are using an image created by a third party, make sure its licence allows it and provide link to the original. For creating your own visualizations, we suggest [excalidraw.com](https://github.com/excalidraw/excalidraw). 
+Usage of images and visualizations is encouraged. If you are using an image created by a third party, make sure its license allows it and provide link to the original. For creating your own visualizations, we suggest [excalidraw.com](https://github.com/excalidraw/excalidraw). 
 
 Feel free to use [emojis](https://docsify.js.org/#/emoji?id=emoji) or [icons](https://icongr.am/fontawesome) where it fits, for example in blockquotes. 
 

docs/eps/nodes_workshop.md

@@ -7,7 +7,7 @@ Watch the recording of the workshop by [Mario](https://twitter.com/TMIYChao) on
 
 [recording](https://www.youtube.com/embed/KxXowOZ2DLs?si=yLpNoczrUmxj4kE4 ':include :type=iframe width=100% height=560 frameborder="0" allow="fullscreen" allowfullscreen encrypted-media gyroscope picture-in-picture web-share')
 
-Make sure to prepare your enviroment and learn basics necessary to understand the process: 
+Make sure to prepare your environment and learn basics necessary to understand the process: 
 
 ## Prerequisites
 

docs/eps/week2.md

@@ -18,7 +18,7 @@ Before starting with week 2 content, make yourself familiar with resources in [w
 
 Additionally, you should read through the following documents to prepare for the presentation:
 * [Nodes and clients](https://ethereum.org/developers/docs/nodes-and-clients)
-* [Ethereum: mechanics](https://cs251.stanford.edu/lectures/lecture7.pdf) (a lecture based on these slides is also available on YouTube: [An Overview of the Ethereum Excecution Layer - Dan Boneh](https://www.youtube.com/watch?v=7sxBjSfmROc))
+* [Ethereum: mechanics](https://cs251.stanford.edu/lectures/lecture7.pdf) (a lecture based on these slides is also available on YouTube: [An Overview of the Ethereum Execution Layer - Dan Boneh](https://www.youtube.com/watch?v=7sxBjSfmROc))
 
 ## Outline
 

docs/eps/week6-dev.md

@@ -27,7 +27,7 @@ Additionally, you can read and get ready by studying the following resources:
 ## Additional reading and exercises 
 
 - Following instructions from Hsiao-Wei's talk, write and run your own pyspec program
-- As an excercise for EL specs, follow Sam's demo on adding an opcode and add your own
+- As an exercise for EL specs, follow Sam's demo on adding an opcode and add your own
 - https://ethereum.org/en/developers/tutorials/yellow-paper-evm/
 - Vitalik Buterin’s Annotated spec: https://github.com/ethereum/annotated-spec
 - Ben Edgington’s Upgrading Ethereum Book: https://eth2book.info

docs/eps/week6-research.md

@@ -2,7 +2,7 @@
 
 Week 6 research track is going to be a dive into data availability sampling and danksharding. 
 
-Watch the presentations by [Dankrad](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). 
+Watch the presentation by [Dankrad](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). 
 
 <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>
 
@@ -24,7 +24,7 @@ Additionally, you can read and get ready by studying the following resources:
 ## Additional reading and exercises 
 
 - [Foundations of Data Availability Sampling](https://www.youtube.com/watch?v=KUNE3kR1kwU)
-- [Desing choices in DAS](https://www.youtube.com/watch?v=Al7Jns8bCO4)
+- [Design choices in DAS](https://www.youtube.com/watch?v=Al7Jns8bCO4)
 - [Danksharding workshop, Devcon Bogota](https://www.youtube.com/watch?v=8L2C6RDMV9Q)
 - [Fraud and DA proofs paper](https://arxiv.org/abs/1809.09044)
 - [WIP DAS proposal](https://hackmd.io/@vbuterin/das)

docs/eps/week7-dev.md

@@ -2,9 +2,10 @@
 
 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, April 1, 3PM UTC](https://savvytime.com/converter/utc-to-germany-berlin-united-kingdom-london-china-shanghai-ny-new-york-city-japan-tokyo-australia-sydney-india-delhi-argentina-buenos-aires/apr-1-2024/3pm).
+Watch the presentation recording by [Dragan](https://twitter.com/rakitadragan) on StreamEth or Youtube. Slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week7-dev.pdf). 
 
-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. 
+
+<iframe width="560" height="315" src="https://www.youtube.com/embed/ibcsc5cv-vc?si=mTR7ReFUZo3vFtJD" 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
 
@@ -25,5 +26,5 @@ Additionally, you can read and get ready by studying the following resources:
 
 ## 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
+- Erigon is a fork of geth which pioneered the design approached implemented by reth. Kind of a middle ground between geth and reth, it's a great source of resources about novel execution client designs
+- As an exercise, run reth and set different `DEBUG` options to explore how various client components operate on lower level

docs/readme.md

@@ -1,14 +1,14 @@
 # Welcome to the protocol
 
-The protocol wiki is a collection of technical resources about the Ethereum protocol. This includes information about the core protocol theory, client development and ongoing research. It's not intented for smart contract or other high level development. 
+The protocol wiki is a collection of technical resources about the Ethereum protocol. This includes information about the core protocol theory, client development and ongoing research. It's not intended for smart contract or other high level development. 
 
-> :warning: Protocol Wiki is under contruction, [join us](/eps/intro.md) and [contribute](contributing.md). 
+> :warning: Protocol Wiki is under construction, [join us](/eps/intro.md) and [contribute](contributing.md). 
 
 ![](https://raw.githubusercontent.com/eth-protocol-fellows/protocol-studies/wiki-pages/docs/images/epfsg_hero.jpg)
 
 ## Protocol Studies
 
-Ethereum Protocol Fellowship Study Group (EPSsg) is an open study program for anyone interested in learning about internals of the protocol. 
+Ethereum Protocol Fellowship Study Group (EPFsg) is an open study program for anyone interested in learning about internals of the protocol. 
 
 Learn more about EPS in its [announcement blog](https://blog.ethereum.org/2024/02/07/epf-study-group). Join the community in our [Discord server](https://discord.gg/epfsg).
 

docs/topics.md

@@ -61,7 +61,7 @@
 [Roadmap]
 
 ### S
-[Statlessness]
+[Statelessness]
 [SSF]
 [SSZ]
 

docs/wiki/EL/JSON-RPC.md

@@ -70,7 +70,7 @@ Just a brief list of the methods is provided here, but the full list can be foun
 
 #### Debug
 
-The *debug* namespace provides methods to inspect the Ethereum state. It's direct access to raw data which might be necessary for certain usecases like block explorers or researc purposes. Some of these methods might require a lot of computation to be done on the node and requests for historical states on non-archival node are mostly not feasible. Therefore, providers of public RPCs often restrict this namespace or allow only safe methods. 
+The *debug* namespace provides methods to inspect the Ethereum state. It's direct access to raw data which might be necessary for certain use cases like block explorers or research purposes. Some of these methods might require a lot of computation to be done on the node and requests for historical states on non-archival node are mostly not feasible. Therefore, providers of public RPCs often restrict this namespace or allow only safe methods. 
 Here are basic examples of debug methods: 
 
 | **Method**               |      **Params**       | **Description**                                                 |

docs/wiki/EL/block-production.md

@@ -14,7 +14,7 @@ The following example is using Geth codebase to explain how execution client bui
     - https://github.com/ethereum/go-ethereum/blob/0a2f33946b95989e8ce36e72a88138adceab6a23/eth/catalyst/api.go#L398 
  2. Most of the the core logic of block building, and transaction execution resides in `miner` module of Geth. The `buildPayload` function initially creates an empty block so the node doesn't miss the slot and has something to propose. The function implementation also starts a go routine process whose job is to potentially fill the block which we left empty and then later update it with filled transactions concurrently.
     - https://github.com/ethereum/go-ethereum/blob/0a2f33946b95989e8ce36e72a88138adceab6a23/miner/payload_building.go#L180                                                                        - https://github.com/ethereum/go-ethereum/blob/0a2f33946b95989e8ce36e72a88138adceab6a23/miner/payload_building.go#L204
- 3. In the `buildPayload` function, the go routine is waiting on multiple communication operations "cases" and in the first case it calls `getSealingBlock` with params which explicitly specifiy that the block should not be empty. Look at the `fullParams` variable i.e `noTxs:False`.
+ 3. In the `buildPayload` function, the go routine is waiting on multiple communication operations "cases" and in the first case it calls `getSealingBlock` with params which explicitly specify that the block should not be empty. Look at the `fullParams` variable i.e `noTxs:False`.
  4. In the definition for `getSealingBlock`, the request is being sent on `getWorkCh` channel. This channel is being listened on in order to retrieve data from it and generate work. 
     - [https://github.com/ethereum/goethereum/blob/master/miner/worker.go#L1222](https://github.com/ethereum/go-ethereum/blob/0a2f33946b95989e8ce36e72a88138adceab6a23/miner/worker.go#L1222)
  5. This `getWorkCh` channel is being listened on inside `mainLoop` function in the same file. The data which comes from the `getWorkCh` channel is then sent to `w.generateWork`.

docs/wiki/protocol/data-structures.md

@@ -2,7 +2,7 @@
 
 ## Primer on Merkle Tree
 
-Merkle tree is a hash-based data structure which is very effecient at data integrity and verification. It is a tree based structure where the leaf nodes hold the data values and each non-leaf node is a hash of its child nodes.
+Merkle tree is a hash-based data structure which is very efficient at data integrity and verification. It is a tree based structure where the leaf nodes hold the data values and each non-leaf node is a hash of its child nodes.
 
 A Merkle tree stores all the transactions in a block by producing a digital fingerprint of the entire set of transactions. It allows the user to verify whether a transaction is included in a block or not. Merkle trees are created by repeatedly calculating hashing pairs of nodes until there is only one hash left. This hash is called the **Merkle Root**, or the Root Hash. The Merkle Trees are constructed in a bottom-up approach.
 
@@ -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 database is currently being researched. 
+The transition to new verkle tree database poses a major challenge. To securely 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