diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 00000000..77229d04 --- /dev/null +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,17 @@ +# Checklist + +- [ ] Review changes to ensure there are no typos. + + \ No newline at end of file diff --git a/.github/workflows/spell-check.yml b/.github/workflows/spell-check.yml new file mode 100644 index 00000000..724df313 --- /dev/null +++ b/.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<> "$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.'); \ No newline at end of file diff --git a/docs/contributing.md b/docs/contributing.md index a004bd26..c975336e 100644 --- a/docs/contributing.md +++ b/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. diff --git a/docs/eps/nodes_workshop.md b/docs/eps/nodes_workshop.md index e2c1d75a..0bbfde6f 100644 --- a/docs/eps/nodes_workshop.md +++ b/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 diff --git a/docs/eps/presentations/week7-dev.pdf b/docs/eps/presentations/week7-dev.pdf new file mode 100644 index 00000000..22742581 Binary files /dev/null and b/docs/eps/presentations/week7-dev.pdf differ diff --git a/docs/eps/week2.md b/docs/eps/week2.md index 22a2c816..4af33be7 100644 --- a/docs/eps/week2.md +++ b/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 diff --git a/docs/eps/week6-dev.md b/docs/eps/week6-dev.md index 0cf313e5..c6f6bbd2 100644 --- a/docs/eps/week6-dev.md +++ b/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 diff --git a/docs/eps/week6-research.md b/docs/eps/week6-research.md index a6b08a19..bae6ad22 100644 --- a/docs/eps/week6-research.md +++ b/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). @@ -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) diff --git a/docs/eps/week7-dev.md b/docs/eps/week7-dev.md index 0f04642a..68b87725 100644 --- a/docs/eps/week7-dev.md +++ b/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. + + ## 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 \ No newline at end of file +- 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 \ No newline at end of file diff --git a/docs/readme.md b/docs/readme.md index b1ea3b68..f846572d 100644 --- a/docs/readme.md +++ b/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). diff --git a/docs/topics.md b/docs/topics.md index 58cc4609..08728e97 100644 --- a/docs/topics.md +++ b/docs/topics.md @@ -61,7 +61,7 @@ [Roadmap] ### S -[Statlessness] +[Statelessness] [SSF] [SSZ] diff --git a/docs/wiki/EL/JSON-RPC.md b/docs/wiki/EL/JSON-RPC.md index 5e040298..2d3b26db 100644 --- a/docs/wiki/EL/JSON-RPC.md +++ b/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** | diff --git a/docs/wiki/EL/block-production.md b/docs/wiki/EL/block-production.md index 3d3c3020..4fe26bfc 100644 --- a/docs/wiki/EL/block-production.md +++ b/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`. diff --git a/docs/wiki/protocol/data-structures.md b/docs/wiki/protocol/data-structures.md index 3b608b4f..fadba545 100644 --- a/docs/wiki/protocol/data-structures.md +++ b/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 diff --git a/docs/wiki/research/scaling/core-changes/eip-4844.md b/docs/wiki/research/scaling/core-changes/eip-4844.md index c773a50d..becf5374 100644 --- a/docs/wiki/research/scaling/core-changes/eip-4844.md +++ b/docs/wiki/research/scaling/core-changes/eip-4844.md @@ -45,11 +45,11 @@ Is important to note that Blobs will not be added to the block to which they bel KZG commitments are a type of cryptographic commitment particularly useful for their efficiency in creating and verifying proofs of data availability and correctness. -KZG commitments provide the ability to prove that specific pieces of data are included in the set without revealing the entire dataset. This is particularly useful for scalability solutions because it does not require for every node to store the whole blockchain to prove transactions correcteness. +KZG commitments provide the ability to prove that specific pieces of data are included in the set without revealing the entire dataset. This is particularly useful for scalability solutions because it does not require for every node to store the whole blockchain to prove transactions correctness. Check the following links to learn more: -- [KZG Cerymony](https://github.com/ethereum/kzg-ceremony) +- [KZG Ceremony](https://github.com/ethereum/kzg-ceremony) - [Arithmetic hash based alternatives to KZG for proto-danksharding (EIP-4844)](https://ethresear.ch/t/arithmetic-hash-based-alternatives-to-kzg-for-proto-danksharding-eip-4844/13863) - [Sharding multi-party computation ceremony](https://ethresear.ch/t/sharding-multi-party-computation-ceremony/11779) @@ -66,7 +66,7 @@ The node receiving the sidecar should verify that blob sidecar is well-formatted This "sidecars" design provides forward compatibility for further data increases by black-boxing [is_data_available](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/fork-choice.md#is_data_available), which means that in future upgrades `is_data_available()` implementation may change, for example to include data-availability-sampling (DAS), and the system interacting with this function is not required to understand the inner implementation of the function (in programming terms, `is_data_available()` can be considered as an interface method where the implementation may change over time). -#### 3. Inclusion of KZG Committment versioned hashes +#### 3. Inclusion of KZG Commitment versioned hashes The Consensus Layer (CL, also called Beacon chain) calls the [`process_execution_payload`](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#modified-process_execution_payload) function when a new block payload is submitted to the chain. This function is responsible to perform some validity checks on the block's payload and then invoke the Execution Layer (EL) via the `verify_and_notify_new_payload` function. @@ -78,7 +78,7 @@ Once invoked, the EL will: With EIP-4844, the `process_execution_payload` adds the parameter `versioned_hashes` to be passed to the `verify_and_notify_new_payload` function. -`versioned_hashes` is an array of [hashes](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#modified-process_execution_payload) for each blob of KZG Committment. +`versioned_hashes` is an array of [hashes](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#modified-process_execution_payload) for each blob of KZG Commitment. #### 4. Execution Payload and Execution Payload Header @@ -132,7 +132,7 @@ blob_gas_used += get_total_blob_gas(tx) #### 2. New Transaction Data Structure (BLOB_TX_TYPE) -Before EIP-4844, the Transaction data structure was the following ([ethereum exeuction-specs repository](https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/london/fork_types.py#L49C1-L108C2)): +Before EIP-4844, the Transaction data structure was the following ([ethereum execution-specs repository](https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/london/fork_types.py#L49C1-L108C2)): ```python @slotted_freezable diff --git a/docs/wiki/research/scaling/scaling.md b/docs/wiki/research/scaling/scaling.md index 9c8a6872..60fc475d 100644 --- a/docs/wiki/research/scaling/scaling.md +++ b/docs/wiki/research/scaling/scaling.md @@ -35,7 +35,7 @@ Functional components of a blockchain: - Data availability: Data availability mechanics that ensures that the data is available to be queried when it is required. - Settlement: Mechanics that guarantee the finality and immutability of transactions. -Modular blockchain approach suggests dividing a blockchain system into different logical layers. This results in a design with reduced systemic complexity, and simpler components that can be more easily optimized and re-enginered to introduce new scaling solutions. +Modular blockchain approach suggests dividing a blockchain system into different logical layers. This results in a design with reduced systemic complexity, and simpler components that can be more easily optimized and re-engineered to introduce new scaling solutions. ## Scaling Ethereum diff --git a/notes/Chloe_notes.md b/notes/Chloe_notes.md index ab584c9e..673256a4 100644 --- a/notes/Chloe_notes.md +++ b/notes/Chloe_notes.md @@ -1,4 +1,4 @@ -Guest hangout session and lots of interesting topics were discussion with bunch of links. So I briefly summerized the link mentioned in the chat and shared here. +Guest hangout session and lots of interesting topics were discussion with bunch of links. So I briefly summarized the link mentioned in the chat and shared here. Great resource on Ethereum ecosystem in general @@ -8,7 +8,7 @@ Great resource on Ethereum ecosystem in general - https://ethresear.ch/ - https://ethereum-magicians.org/ -EthR&D Discord Guidebook +Eth R&D Discord Guidebook - https://github.com/tvanepps/EthereumDiscordGuidebook @@ -20,7 +20,7 @@ Blog on how to run an Ethereum node - https://nownodes.io/blog/how-to-run-an-ethereum-node-a-comprehensive-guide/ -Ethereum on ARM recommended HW to run a node +Ethereum on ARM: Recommended hardware to run a node - https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/recommended-hardware.html diff --git a/notes/gorondan.md b/notes/gorondan.md index 2b8df3a6..bb5d6f49 100644 --- a/notes/gorondan.md +++ b/notes/gorondan.md @@ -3,11 +3,11 @@ ## Objectives The purpose to joining this program is to get a deeper understanding of the infrastructure that makes everything possible in the application layer, and the directions further, while expanding my protocol knowledge. Also, I have a high interest in understanding how the current work carried on protocol level will impact the application layer in the short to medium term. -Reading the material in the previous EPF programs, I realise that after finalizing EPS and moving into EPF, we will have to become much more technical/practical. To my understanding, that means identifying areas of interest where we can bring our own additions and setting a clear project goal, leading to working on an actual project, with well defined deliverables expectation (improvement/applied research/analyzing tool). +Reading the material in the previous EPF programs, I realize that after finalizing EPS and moving into EPF, we will have to become much more technical/practical. To my understanding, that means identifying areas of interest where we can bring our own additions and setting a clear project goal, leading to working on an actual project, with well defined deliverables expectation (improvement/applied research/analyzing tool). ## Areas of Interest -* staking design - I feel that this topic transcends on-going and future protocol development and it will have a palpalbe impact on the application layer in the short to medium term. Also long term, but that is most likely to be subjected to the [time factor](../docs/wiki/research/roadmap.md#roadmap-overview). +* staking design - I feel that this topic transcends on-going and future protocol development and it will have a palpable impact on the application layer in the short to medium term. Also long term, but that is most likely to be subjected to the [time factor](../docs/wiki/research/roadmap.md#roadmap-overview). ## Potential project My goal is to partake in a project that would propose minimal viable enshrinement of liquid staking. @@ -25,15 +25,15 @@ An example could be: "Author an EIP and corresponding POC implementation for *En ### Challenges * the project should not affect validator economics, but propose simple protocol tweaks that would work towards minimal viable enshrinement of liquid staking. * enshrining has it's limitations [[3]](#resources) -* questions to be asked and answered durring project: +* questions to be asked and answered during project: - would the implementation of the project's proposed spec changes actually improve the staking scene? - - large numbers of delegators part of big staking pools could create annomalies in the network(late block production, missed attestations). A tool for testing that is part of a prior EPF work in cohort three [[4]](#resources). - - how would the proposed changes interact with other ongoing developments like increasing the MAX_EFFECTIVE_BALLANCE(EIP-7215)[ [5]](#resources), [light-clients](../docs/wiki/research/light-clients.md), SSF, etc? would it have an overall positive impact and mix well with current/prevised protocol improovements? + - large numbers of delegators part of big staking pools could create anomalies in the network(late block production, missed attestations). A tool for testing that is part of a prior EPF work in cohort three [[4]](#resources). + - how would the proposed changes interact with other ongoing developments like increasing the MAX_EFFECTIVE_BALANCE(EIP-7215)[ [5]](#resources), [light-clients](../docs/wiki/research/light-clients.md), SSF, etc? would it have an overall positive impact and mix well with current/previous protocol improvements? ### Possible expected effects * short-medium term: - - improve protocol and staking pools decentraliation - - allow staking delegators to participate in consensus in a meaningfull way; + - improve protocol and staking pools decentralization + - allow staking delegators to participate in consensus in a meaningful way; * medium-long term: - paving the way to de-risking staked ETH - paving the way for SSF diff --git a/wordlist.txt b/wordlist.txt new file mode 100644 index 00000000..58b0a19f --- /dev/null +++ b/wordlist.txt @@ -0,0 +1,397 @@ +personal_ws-1.1 en 10000 utf-8 +aantop +ABI +accelerometer +ACD +allowfullscreen +AltExplainer +Andreas +Antonopoulos +API +APIs +ary +ASE +Assche +Assertoor +autoplay +Bankless +Barnabe +baseFeePerGas +Beiko +Bertoni +BFT +bitrate +bitwise +BLOBHASH +blockchain +blockchain's +blockchains +blockNumber +blockquotes +blocksize +BLS +Boneh +bool +borderless +broadcasted +Buterin +Buterin's +bytecode +calldata +Casper +cdots +centric +chainId +cli +CoC +codebase +codebases +CODECOPY +CollectDrink +config +congestions +Corbellini +Crypto +cryptocurrencies +cryptocurrency +cryptoeconomic +cryptoeconomically +cryptographic +cryptographically +Cryptopedia +cybersecurity +Cypherpunks +D'Amato +Daemen +Dankrad +danksharding +Dany +dapp +dapps +DAS +dataset +Degatchi +delegator +delegators +deliverables +Dencun +deployer +Desmos +dev +Devcon +Devops +devp +Devs +Diffie +discv +distro +docsify +Domothy +Dragan +Driscoll +DSA +EB +ECADD +ECC +ECDSA +ECMUL +ECPAIRING +ECRECOVER +Edgington +Edgington's +efd +EIP +EIPs +eK +EL +Elmore +ELs +Encodings +env +EOF +EOY +eP +ePBS +EPF +EPFsg +Ephemery +EPS +epubs +ERC +ERCs +Erigon +estimateGas +eth +Ethereum +Ethereum's +ethers +ethresearch +EVM +EVM's +evmlab +EVMONE +excalidraw +exchangeTransitionConfigurationV +execPayload +ExecutionPayload +Explainer +Feist +Femboy +finalise +Forkchoice +forkchoiceUpdatedV +FOSS +frameborder +Francesco +frontend +fullscreen +Fullstack +func +fuzzer +FuzzyVM +GasLimit +Gasper +gasPrice +gasUsed +Georgios +getBadBlocks +getBalance +GetBlockBodies +getBlockByHash +getBlockByNumber +GetBlockHeader +getBlockTransactionCountByHash +getBlockTransactionCountByNumber +getCode +geth +getLogs +getPayloadBodiesByHashV +getPayloadV +GetPooledTransactions +getRawBlock +getRawHeader +getRawReceipts +getRawTransactions +GetReceipts +getStorageAt +getters +Gilles +Goron +gpg +Grafana +hoc +Holesky +Hsiao +ics +iframe +ify +impera +incentivize +inevitableeth +infrastracture +Infura +init +InsertCoin +interop +IPC +ISA +Jitsi +js +JSON +JUMPDEST +JVM +Karapetsas +Katex +keccak +Keccak's +keecak +Kleppmann +Koblitz +KZG +KZGCommitment +KZGProof +Lamport +LeftAsExercise +Lefteris +libp +Lightclient +Lightclient's +liveness +LLM +LLMs +LMD +Longrightarrow +LST +Lua +LuaVM +mainnet +Mário +mathbb +maxFeePerGas +maxPriorityFeePerGas +mem +Mempool +Menezes +Merkle +Merkleization +Merkleize +MEV +Michaël +mload +MMPTs +MODEXP +modularity +Monnot +MPT +MSIZE +mstore +MUL +MVE +n't +namespace +namespaces +Nand +natively +newPayload +newPayloadV +NewPooledTransactionHashes +NFT +NIST +NOXX +Occhipinti +offsites +onchain +Oorschot +OpenRPC +OpenZeppelin +OSI +OSI's +Parametrizing +params +Pari +Paritosh +Pectra +PeerDAS +Peeters +permissionless +Pilipovic +Playdate +pmod +POC +POS +pre +preconfirmations +precompile +precompiled +precompiles +privateKey +programmability +Proof-of-stake +proof-of-stake +Proof-of-work +proof-of-work +proto +PRs +PUSHX +py +Pyspec +pytest +radix +Rareskills +README +referrerpolicy +repo +responder +retesteth +Reth +revm +RIPEMD +Ritchie +rK +RLP +roadmap +rollup +rollups +RPC +RPCs +runtime +scalability +scalable +schemas +Schocken +SECG +secp +SelectDrink +SELFDESTRUCT +sexualized +SHA +Shafu +sharding +ShareAlike +Shead +Shimon +Silverman +Sipser +SLOAD +smlXL +SNARKify +socio +solvm +SSF +SSLE +SSTORE +sstorge +SSZ +stakers +Stallman +StateDB +stateRoot +stf +StreamEth +systemd +Takenobu +Tani +TestingTheMerge +testnet +Tetris +textnormal +TODO +TPS +tradeoff +transactional +trapdoored +trie +trilemma +trustless +TrustLook +TSTORE +txpool +txs +Unbundling +underbrace +Unformatted +upstreamed +utils +validator +validators +Vanstone +VDFs +VerifyHeaders +Verkle +verkled +VersionedHash +Victorio +Vitalik +VM +Vyper +walkthrough +webkit +WebRTC +WebSockets +Whitepaper +WIP +WSS +XORed +xy +Yellowpaper +zk \ No newline at end of file