-
Notifications
You must be signed in to change notification settings - Fork 97
Commit
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,11 +1,11 @@ | ||
# Ethereum Protocol Fellowship | ||
# Ethereum Protocol Fellowship | ||
|
||
EPF is a program for everyone interested in starting to contribute to Ethereum core protocol. Organized by EF Protocol Support, the program is divided into yearly cohorts, each running for 4-5 months. The program was originally started as CDAP by Piper Merriam and grew with each cohort. | ||
Check failure on line 3 in docs/wiki/epf.md GitHub Actions / lintLine length
|
||
|
||
Because the protocol, its development and research is fully public and open, anyone can start contributing. But the understanding of current issues, identifying a project to work on and connecting with other contributors can pose a barrier to start, EPF helps to smooth this process. | ||
Because the protocol, its development and research is fully public and open, anyone can start contributing. But the understanding of current issues, identifying a project to work on and connecting with other contributors can pose a barrier to start, EPF helps to smooth this process. | ||
Check failure on line 5 in docs/wiki/epf.md GitHub Actions / lintLine length
|
||
|
||
The fellowship is fully open and permissionless, anyone can join the community to start working their area of interest. The cohort opens up with an application process and ends with EPF Day in-person event at Devcon. The most active and skilled contributors might be eligible for stipend at the start of the cohort based on their application or retrospectively. | ||
The fellowship is fully open and permissionless, anyone can join the community to start working their area of interest. The cohort opens up with an application process and ends with EPF Day in-person event at Devcon. The most active and skilled contributors might be eligible for stipend at the start of the cohort based on their application or retrospectively. | ||
Check failure on line 7 in docs/wiki/epf.md GitHub Actions / lintLine length
|
||
|
||
> Upcoming EPF cohorts are announced when applications open. Follow the [mailing list, EPS discord and EF blog](/eps/intro.md#important-links) to stay informed. | ||
> Upcoming EPF cohorts are announced when applications open. Follow the [mailing list, EPS discord and EF blog](/eps/intro.md#important-links) to stay informed. | ||
Check failure on line 9 in docs/wiki/epf.md GitHub Actions / lintLine length
|
||
All work done within EPF cohorts can be found in [eth-protocol-fellows repositories](https://github.com/orgs/eth-protocol-fellows/repositories). Each cohort repo includes `/projects` directory with all project proposals and `dev-updates.md` document tracking weekly progress of every participant. Use these resources to learn about the protocol, fellows' work and get inspiration for your own projects. | ||
All work done within EPF cohorts can be found in [eth-protocol-fellows repositories](https://github.com/orgs/eth-protocol-fellows/repositories). Each cohort repo includes `/projects` directory with all project proposals and `dev-updates.md` document tracking weekly progress of every participant. Use these resources to learn about the protocol, fellows' work and get inspiration for your own projects. | ||
Check failure on line 11 in docs/wiki/epf.md GitHub Actions / lintLine length
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,49 +6,88 @@ Pectra, (Prague - Electra), is the next network upgrade scheduled for Ethereum. | |
**Who is this guide for?** | ||
For App developers, Stakers and Node operators who are interested in the upcoming Pectra upgrade. | ||
Check failure on line 7 in docs/wiki/pectra-faq.md GitHub Actions / lintLine length
|
||
|
||
[toc] | ||
[Table of Contents] | ||
|
||
## Overall | ||
|
||
Overall | ||
--- | ||
**FAQ**: | ||
|
||
#### **Q:** What is Prague/Electra? | ||
Check failure on line 15 in docs/wiki/pectra-faq.md GitHub Actions / lintHeading levels should only increment by one level at a time
|
||
**A:** Prague and Electra are the names of the upcoming Ethereum hard fork. The included EIPs can be found [here](https://eips.ethereum.org/EIPS/eip-7600). Prague is the name of the fork on the execution client side, and Electra is the upgrade name on the consensus layer client side. | ||
|
||
**A:** Prague and Electra are the names of the upcoming Ethereum hard fork. The included EIPs can be found [here](https://eips.ethereum.org/EIPS/eip-7600). Prague is the name of the fork on the execution client side, and Electra is the upgrade name on the consensus layer client side. | ||
Check failure on line 17 in docs/wiki/pectra-faq.md GitHub Actions / lintLine length
|
||
|
||
## Users/Devs | ||
|
||
--- | ||
|
||
**FAQ**: | ||
|
||
#### **Q:** What is EIP-7702/Account abstraction? | ||
Check failure on line 25 in docs/wiki/pectra-faq.md GitHub Actions / lintHeading levels should only increment by one level at a time
|
||
|
||
#### **Q:** Where can I find the specification for EIP-7702? How can I use it as a wallet dev? | ||
|
||
#### **Q:** How do I use account abstraction? | ||
|
||
#### **Q:** Do I have to wait for my wallet to support EIP-7702? | ||
|
||
#### **Q:** What do I need to know about EIP-7702 as a smart contract dev? | ||
|
||
#### **Q:** What do I need to know as a security engineer/auditor? | ||
|
||
#### **Q:** What does the BLS opcodes add in pectra? | ||
|
||
#### **Q:** How can I use the `BLOCKHASH` OPCODE? | ||
|
||
#### **Q:** What are system contracts? | ||
|
||
## Stakers | ||
|
||
--- | ||
|
||
**FAQ**: | ||
|
||
#### **Q:** What changes about deposits? | ||
|
||
#### **Q:** How long do I have to wait for deposits now? | ||
|
||
#### **Q:** What balances between 32ETH and 2048ETH can I earn on? | ||
Effective balances increase 1ETH at a time. If your balance is 33.74 effective balance will be 33. If you effective balance is 33.75 then your effective balance will be 34. | ||
|
||
Effective balances increase 1ETH at a time. If your balance is 33.74 effective balance will be 33. If you effective balance is 33.75 then your effective balance will be 34. | ||
|
||
#### **Q:** What are `0x02` withdrawal credentials? | ||
|
||
#### **Q:** How do I switch to `0x02` withdrawal credentials? How does it help me? | ||
|
||
#### **Q:** Can I deposit a validator with `0x02` credentials directly? | ||
|
||
#### **Q:** I have a validator with `0x00` credentials, how do i move to `0x02`? | ||
|
||
#### **Q:** I have a validator with `0x01` credentials, how do i move to `0x02`? | ||
|
||
#### **Q:** What is MaxEB? | ||
MaxEB or the [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) increases the `MAX_EFFECTIVE_BALANCE` to 2048 ETH while keeping the minimum staking balance at 32 ETH. Before MaxEB, any entity that wanted to contribute a large amount of ETH to consenus had to spin up multiple validators because each was capped at a maximum of 32 ETH. EIP-7251 will allow large stake operators to consolidate their ETH into fewer validators, using the same stake with up to 64 times less individual validators. It also allows solo stakers' ETH to be compounded into their existing validator and contribute to their rewards without having to use the exact validator amount. For example, 35 ETH will be considered the validator's effective balance by the protocol, instead of leaving out 3 ETH ineffective and waiting till 64 ETH for 2 validators. Overall, consolidating validators will allow for fewer attestations in the consensus network and easing the bandwidth usage by nodes. | ||
|
||
MaxEB or the [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) increases the `MAX_EFFECTIVE_BALANCE` to 2048 ETH while keeping the minimum staking balance at 32 ETH. Before MaxEB, any entity that wanted to contribute a large amount of ETH to consensus had to spin up multiple validators because each was capped at a maximum of 32 ETH. EIP-7251 will allow large stake operators to consolidate their ETH into fewer validators, using the same stake with up to 64 times less individual validators. It also allows solo stakers' ETH to be compounded into their existing validator and contribute to their rewards without having to use the exact validator amount. For example, 35 ETH will be considered the validator's effective balance by the protocol, instead of leaving out 3 ETH ineffective and waiting till 64 ETH for 2 validators. Overall, consolidating validators will allow for fewer attestations in the consensus network and easing the bandwidth usage by nodes. | ||
|
||
#### **Q:** How do I consolidate my validator? | ||
|
||
#### **Q:** What happens to my original, individual validators? | ||
|
||
#### **Q:** When does the balance appear on my consolidated validator? | ||
|
||
#### **Q:** When happens if I consolidate one validator with`0x01` and another with `0x00` credentials? | ||
|
||
#### **Q:** What happens if I consolidate validators that are exited? | ||
|
||
#### **Q:** How can I partially withdraw some ETH from my `0x02` validator? | ||
|
||
#### **Q:** How much ETH can I withdraw from my validator? | ||
|
||
#### **Q:** What happens to the ETH balance if my validator has `0x02` credentials and goes below 32 ETH? | ||
|
||
#### **Q:** What happens to the ETH balance if my validator has `0x02` credentials and goes above 2048 ETH? | ||
|
||
#### **Q:** Can I top up ETH in my `0x02` validator? | ||
|
||
#### **Q:** How can I top up ETH in my `0x02` validator? | ||
|
||
#### **Q:** What happens to the ETH balance if I consolidate and my validator has `0x02` credentials and the total balance goes above 2048 ETH? |