Skip to content

Fix typo in capella/beacon-chain.md #40

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
harpocryptes wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fix typo in capella/beacon-chain.md #40

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion capella/beacon-chain.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -114,7 +114,7 @@ This is the object that contains a withdrawal. When the consensus layer detects

Withdrawals are special because they move funds from the consensus layer to the execution layer, and so implementing them requires interaction between the two. There was a technical debate between two different ways to implement this interaction. One approach was to avoid including withdrawals in the body at all: the consensus portion of a block is processed first, it generates the list of withdrawals, and then that list is passed directly to the execution client and processed, without ever being serialized anywhere. The other approach is to include the list of withdrawals in the `ExecutionPayload` (the portion of the block that goes to the execution client). Consensus clients would check that the provided list is correctly generated, and execution clients would process those withdrawals.

We ultimately decided on the second approach, because it improves modularity and separation of concerns, and particuarly it allows for execution validity and consensus validity to be verified at different times. This is very valuable for optimized node syncing procedures.
We ultimately decided on the second approach, because it improves modularity and separation of concerns, and particularly it allows for execution validity and consensus validity to be verified at different times. This is very valuable for optimized node syncing procedures.

#### `BLSToExecutionChange`

Expand Down