Skip to content

Commit

Permalink
✨ feat(Spelling): close #121
Browse files Browse the repository at this point in the history
  • Loading branch information
raxhvl committed Mar 31, 2024
1 parent 7e7705c commit 804398b
Show file tree
Hide file tree
Showing 17 changed files with 428 additions and 36 deletions.
8 changes: 4 additions & 4 deletions docs/contributing.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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

Expand Down Expand Up @@ -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.

Expand Down
2 changes: 1 addition & 1 deletion docs/eps/nodes_workshop.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
2 changes: 1 addition & 1 deletion docs/eps/week2.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
2 changes: 1 addition & 1 deletion docs/eps/week6-dev.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
2 changes: 1 addition & 1 deletion docs/eps/week6-research.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)
6 changes: 3 additions & 3 deletions docs/eps/week7-dev.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

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 presentation will be given by [Dragan](https://twitter.com/rakitadragan) who will dive into reth client codebase. Join the talk on [Monday, April 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.

Expand All @@ -25,5 +25,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
6 changes: 3 additions & 3 deletions docs/readme.md
Original file line number Diff line number Diff line change
@@ -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).

Expand Down
2 changes: 1 addition & 1 deletion docs/topics.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,7 @@
[Roadmap]

### S
[Statlessness]
[Statelessness]
[SSF]
[SSZ]

Expand Down
2 changes: 1 addition & 1 deletion docs/wiki/EL/JSON-RPC.md
Original file line number Diff line number Diff line change
Expand Up @@ -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** |
Expand Down
2 changes: 1 addition & 1 deletion docs/wiki/EL/block-production.md
Original file line number Diff line number Diff line change
Expand Up @@ -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`.
Expand Down
4 changes: 2 additions & 2 deletions docs/wiki/protocol/data-structures.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -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

Expand Down
2 changes: 1 addition & 1 deletion docs/wiki/research/Beacon Chain Upgrades.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
## BEACON CHAIN UPGRADES

### Inclusion Lists
### Preconfirmations
### Pre confirmations
### Raise MAX_EFFECTIVE_BALANCE
### Staking pools solutions

Expand Down
10 changes: 5 additions & 5 deletions docs/wiki/research/scaling/core-changes/eip-4844.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)

Expand All @@ -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.

Expand All @@ -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

Expand Down Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion docs/wiki/research/scaling/scaling.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
6 changes: 3 additions & 3 deletions notes/Chloe_notes.md
Original file line number Diff line number Diff line change
@@ -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
Expand All @@ -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

Expand All @@ -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

Expand Down
Loading

0 comments on commit 804398b

Please sign in to comment.