From 48e2e48942c8efe84467a071165a6eb100e1c137 Mon Sep 17 00:00:00 2001 From: parithosh Date: Mon, 4 Nov 2024 21:03:41 +0800 Subject: [PATCH 01/14] adding some answers --- docs/wiki/pectra-faq.md | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index 30025158..9bc7a266 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -18,21 +18,37 @@ Overall --- **FAQ**: #### **Q:** What is EIP-7702/Account abstraction? +While EIP-7702 isn’t quite account abstraction, it does provide execution abstraction. This allows your EOA to do things like send transaction batches and delegate to other cryptographic key schemes, like passkeys. It does this by setting the code associated with the EOA to a protocol-level proxy designation. A full specification can be found [here](https://eips.ethereum.org/EIPS/eip-7702). + #### **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? +The specification for EIP-7702 is can be found [here](https://eips.ethereum.org/EIPS/eip-7702). To get started as a wallet developer, you'll need to determine a smart contract wallet core to use with the EOA. Pay close attention to how the wallets [should be initialized](https://eips.ethereum.org/EIPS/eip-7702#front-running-initialization). Once you have determined the core wallet to use, you'll need to expose behavior like `eth_sendTransaction` and other custom methods for EIP-7702 specific functionality like batch transactions. + +#### **Q:** As a user, how can I use account abstraction? +To get the [benefits](https://ethereum.org/en/roadmap/account-abstraction/) of account abstraction, you need to use a wallet that supports it. Once your wallet of choice supports account abstraction, you will be able to make use of it. + #### **Q:** Do I have to wait for my wallet to support EIP-7702? +Unfortunately yes, until your wallet integrates EIP-7702 it will not be possible to make use of the new functionalities it provides. + #### **Q:** What do I need to know about EIP-7702 as a smart contract dev? +As a smart contract developer, you should know that after Prague the majority of users on Ethereum will now be able to interact with the chain in more complex ways than were feasible before. Many standards have been developed to work around the limitations of EOAs, such as [ERC-2612 Permit](https://eips.ethereum.org/EIPS/eip-2612). + #### **Q:** What do I need to know as a security engineer/auditor? -#### **Q:** What does the BLS opcodes add in pectra? +As a security engineer / auditor, you must be aware that the previous assumption that a frame cannot be reentered when `msg.sender == tx.origin` no longer holds. This means the check is no longer suitable for reentrancy guards or flash loan protection. + +#### **Q:** What does the EIP-2537 BLS precompile 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. +The process of making and submitting deposits will not change. You can continue to use the same tools as earlier. However, the mechanism for processing deposits on Ethereum will undergo an improvement. This improvement is described by [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) and will allow almost immediate processing of deposits. + +#### **Q:** How long do I have to wait for my deposits to be included? +After the changes included in [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110), the deposits should show up in <20mins during regular finalizing periods of the chain. However, there is still a deposit queue for your validator to be activated, the EIP merely ensures that the deposit is seen faster and more securely by the chain and does not influence how quickly a validator is activated. + #### **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? @@ -49,6 +65,8 @@ MaxEB or the [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) increases the ` #### **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:** What balances between 32ETH and 2048ETH can I earn on? +The effective balance increments 1ETH at a time. This means the accrued balance needs to meet a threshold before the effective balance changes. e.g, 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:** 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? From 2092ae0339c53df1bbcafe80dea9dff9603563dd Mon Sep 17 00:00:00 2001 From: parithosh Date: Mon, 4 Nov 2024 23:04:12 +0800 Subject: [PATCH 02/14] updated doc --- docs/wiki/pectra-faq.md | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index 9bc7a266..fb590d41 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -18,7 +18,7 @@ Overall --- **FAQ**: #### **Q:** What is EIP-7702/Account abstraction? -While EIP-7702 isn’t quite account abstraction, it does provide execution abstraction. This allows your EOA to do things like send transaction batches and delegate to other cryptographic key schemes, like passkeys. It does this by setting the code associated with the EOA to a protocol-level proxy designation. A full specification can be found [here](https://eips.ethereum.org/EIPS/eip-7702). +While EIP-7702 isn’t quite account abstraction, it does provide execution abstraction, i.e adds additional functionality to externally owned accounts (EOAs. This allows your EOA to do things like send transaction batches and delegate to other cryptographic key schemes, like passkeys. It does this by setting the code associated with the EOA to a protocol-level proxy designation. A full specification can be found [here](https://eips.ethereum.org/EIPS/eip-7702). It introduces a new transaction type that temporarily authorizes specific contract code for an EOA during a single transaction, allowing EOAs to function as smart contract accounts. This enables several use cases for users, including transaction batching, gas sponsorship, and privilege de-escalation. #### **Q:** Where can I find the specification for EIP-7702? How can I use it as a wallet dev? The specification for EIP-7702 is can be found [here](https://eips.ethereum.org/EIPS/eip-7702). To get started as a wallet developer, you'll need to determine a smart contract wallet core to use with the EOA. Pay close attention to how the wallets [should be initialized](https://eips.ethereum.org/EIPS/eip-7702#front-running-initialization). Once you have determined the core wallet to use, you'll need to expose behavior like `eth_sendTransaction` and other custom methods for EIP-7702 specific functionality like batch transactions. @@ -40,6 +40,7 @@ As a security engineer / auditor, you must be aware that the previous assumption #### **Q:** How can I use the `BLOCKHASH` OPCODE? #### **Q:** What are system contracts? + ## Stakers --- **FAQ**: @@ -50,23 +51,47 @@ The process of making and submitting deposits will not change. You can continue After the changes included in [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110), the deposits should show up in <20mins during regular finalizing periods of the chain. However, there is still a deposit queue for your validator to be activated, the EIP merely ensures that the deposit is seen faster and more securely by the chain and does not influence how quickly a validator is activated. #### **Q:** What are `0x02` withdrawal credentials? +Up until the Pectra fork, Ethereum accepted two types of withdrawal credentials: `0x00` and `0x01`. The main change is that `0x01` contain an execution layer address that receives partial and full withdrawals. The `0x02` withdrawal credentials are a new type of withdrawal credentials that will be introduced in the Pectra upgrade. The `0x02` withdrawal credentials will allow for maximum effective balances of >32 ETH and <2048ETH either via larger deposits or via consolidations of existing validators. The `0x02` withdrawal credentials also enable the ability to exit validators with the execution layer withdrawal address, enabling complete control of the validator via the execution layer. + #### **Q:** How do I switch to `0x02` withdrawal credentials? How does it help me? +There are 2 ways in which a validator can have `0x02` withdrawal credentials: +1. When you deposit with `0x02` withdrawal credentials +2. When you consolidate existing validators with `0x02` withdrawal credentials + +The `0x02` withdrawal credential enables you to control the validator exit from your execution layer address as well as allows you to possess maximum effective balances of >32 ETH and <2048ETH. This means you can run one validator and have a single validator with a balance of up to 2048 ETH. + #### **Q:** Can I deposit a validator with `0x02` credentials directly? +Yes, you can deposit a validator with `0x02` credentials directly. This will allow you to have a single validator with a balance of up to 2048 ETH. The `staking-cli` will support the `0x02` withdrawal credentials in the coming months before the Pectra mainnet Ethereum fork. + #### **Q:** I have a validator with `0x00` credentials, how do i move to `0x02`? +There is no direct way to move from `0x00` to `0x02`. You will need to first move your validator from `0x00` to `0x01` withdrawal credentials with a BLS change operation, then consolidate your validators to `0x02` withdrawal credentials. You can alternatively exit the validator and make a new deposit with `0x02` withdrawal credentials during the deposit. #### **Q:** I have a validator with `0x01` credentials, how do i move to `0x02`? +You can consolidate your validators to `0x02` withdrawal credentials. This will allow you to have a single validator with a balance of up to 2048 ETH. The `staking-cli` will support the `0x02` withdrawal credentials in the coming months before the Pectra mainnet Ethereum fork. #### **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. #### **Q:** How do I consolidate my validator? +#### **Q:** What are the validator requirements for consolidation? +The validators must be active on the beacon chain at the time of consolidation execution. This means they cannot be exiting or pending activation or any other state besides active. Both the source and the target validators must have the same `0x01` withdrawal credentials. If these two conditions are met, then the validator may be consolidated. #### **Q:** What happens to my original, individual validators? +During a consolidation, there is a source and a target validator. The source validator is completely exited and the balance is then transferred to the target validator. The target validator will have the sum of the balances of the source validator and the target validator and will continue to perform its beacon chain duties without any change. #### **Q:** When does the balance appear on my consolidated validator? +Once the source validator has completely exited and ceased performing all duties, the balance will be credited to the target validator. + #### **Q:** When happens if I consolidate one validator with`0x01` and another with `0x00` credentials? +The consolidation will fail if both validators don't contain a `0x01` withdrawal credential with the exact same execution layer address. #### **Q:** What happens if I consolidate validators that are exited? +The consolidation will fail as the validators must be active on the beacon chain at the time of consolidation execution. #### **Q:** How can I partially withdraw some ETH from my `0x02` validator? +You can issue a EL triggered exit to partially withdraw some ETH from the `0x02` validator. #### **Q:** How much ETH can I withdraw from my validator? +You can withdraw any amount of ETH as long as the validator contains >32ETH at the time of completion of the withdrawal. #### **Q:** What happens to the ETH balance if my validator has `0x02` credentials and goes below 32 ETH? +The validator will be exited and the balance will be transferred to the execution layer withdrawal address if the balance goes below 32 ETH. #### **Q:** What happens to the ETH balance if my validator has `0x02` credentials and goes above 2048 ETH? +The balance will continue to collect at the validator until the next partial withdrawal is triggered. The validator will however contain a maximum effective balance of 2048 ETH, the remaining balance will be considered ineffective in the beacon chain. #### **Q:** What balances between 32ETH and 2048ETH can I earn on? The effective balance increments 1ETH at a time. This means the accrued balance needs to meet a threshold before the effective balance changes. e.g, 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:** Can I top up ETH in my `0x02` validator? -#### **Q:** How can I top up ETH in my `0x02` validator? +You can either consolidate a validator into the `0x02` validator to increase its balance or make a fresh deposit. #### **Q:** What happens to the ETH balance if I consolidate and my validator has `0x02` credentials and the total balance goes above 2048 ETH? +The balance will continue to collect at the validator until the next partial withdrawal is triggered. The validator will however contain a maximum effective balance of 2048 ETH, the remaining balance will be considered ineffective in the beacon chain. From dfe4c3f953438e4da761264fc304d0c4309bf46c Mon Sep 17 00:00:00 2001 From: parithosh Date: Mon, 4 Nov 2024 23:11:14 +0800 Subject: [PATCH 03/14] fix typos --- docs/wiki/pectra-faq.md | 6 ++---- wordlist.txt | 1 + 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index fb590d41..f71f45cf 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -6,8 +6,6 @@ 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. -[toc] - Overall --- **FAQ**: @@ -48,7 +46,7 @@ As a security engineer / auditor, you must be aware that the previous assumption The process of making and submitting deposits will not change. You can continue to use the same tools as earlier. However, the mechanism for processing deposits on Ethereum will undergo an improvement. This improvement is described by [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) and will allow almost immediate processing of deposits. #### **Q:** How long do I have to wait for my deposits to be included? -After the changes included in [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110), the deposits should show up in <20mins during regular finalizing periods of the chain. However, there is still a deposit queue for your validator to be activated, the EIP merely ensures that the deposit is seen faster and more securely by the chain and does not influence how quickly a validator is activated. +After the changes included in [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110), the deposits should show up in <20 minutes during regular finalizing periods of the chain. However, there is still a deposit queue for your validator to be activated, the EIP merely ensures that the deposit is seen faster and more securely by the chain and does not influence how quickly a validator is activated. #### **Q:** What are `0x02` withdrawal credentials? Up until the Pectra fork, Ethereum accepted two types of withdrawal credentials: `0x00` and `0x01`. The main change is that `0x01` contain an execution layer address that receives partial and full withdrawals. The `0x02` withdrawal credentials are a new type of withdrawal credentials that will be introduced in the Pectra upgrade. The `0x02` withdrawal credentials will allow for maximum effective balances of >32 ETH and <2048ETH either via larger deposits or via consolidations of existing validators. The `0x02` withdrawal credentials also enable the ability to exit validators with the execution layer withdrawal address, enabling complete control of the validator via the execution layer. @@ -68,7 +66,7 @@ There is no direct way to move from `0x00` to `0x02`. You will need to first mov #### **Q:** I have a validator with `0x01` credentials, how do i move to `0x02`? You can consolidate your validators to `0x02` withdrawal credentials. This will allow you to have a single validator with a balance of up to 2048 ETH. The `staking-cli` will support the `0x02` withdrawal credentials in the coming months before the Pectra mainnet Ethereum fork. #### **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 are the validator requirements for consolidation? The validators must be active on the beacon chain at the time of consolidation execution. This means they cannot be exiting or pending activation or any other state besides active. Both the source and the target validators must have the same `0x01` withdrawal credentials. If these two conditions are met, then the validator may be consolidated. diff --git a/wordlist.txt b/wordlist.txt index 9a040fb4..f73def49 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -624,6 +624,7 @@ README reciept referrerpolicy remerkleable +reentrancy reorganisation reorganisations replayable From 1d54c5050c3832736d896894ee6a3151755dbf9f Mon Sep 17 00:00:00 2001 From: parithosh Date: Wed, 6 Nov 2024 13:19:25 +0800 Subject: [PATCH 04/14] answering last questions --- docs/wiki/pectra-faq.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index dd877007..c645129f 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -34,10 +34,13 @@ As a smart contract developer, you should know that after Prague the majority of As a security engineer / auditor, you must be aware that the previous assumption that a frame cannot be reentered when `msg.sender == tx.origin` no longer holds. This means the check is no longer suitable for reentrancy guards or flash loan protection. #### **Q:** What does the EIP-2537 BLS precompile add in pectra? +EIP-2537 Adds operation on BLS12-381 curve as a precompile to Ethereum. BLS12-381 precompile enables efficient BLS signature verification. This is useful for applications where multiple signatures need to be verified, such as proof checking systems. #### **Q:** How can I use the `BLOCKHASH` OPCODE? +The last 8192 blockhashes are now stored and available for access in the `BLOCKHASH` system contract. The `BLOCKHASH` opcode semantics remains the same as before, just that the block number can now be specified in big-endian encoding. The blockhash system contract can also be called via the ethCall RPC method, with the block number in question being passed as calldata. #### **Q:** What are system contracts? +System contracts are interfaces defined as contracts, which are essential for certain Ethereum functions to occur. The contract approach is used instead of each client implementing the logic in order to simplify maintenance as well as allow for upgrades in the future with minimal overhead. ## Stakers --- From 08b72ec6af8e7ebe6e94ad1e25dfcd92f69ae24e Mon Sep 17 00:00:00 2001 From: parithosh Date: Wed, 6 Nov 2024 13:43:21 +0800 Subject: [PATCH 05/14] fix typo --- docs/wiki/pectra-faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index c645129f..380a2690 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -37,7 +37,7 @@ As a security engineer / auditor, you must be aware that the previous assumption EIP-2537 Adds operation on BLS12-381 curve as a precompile to Ethereum. BLS12-381 precompile enables efficient BLS signature verification. This is useful for applications where multiple signatures need to be verified, such as proof checking systems. #### **Q:** How can I use the `BLOCKHASH` OPCODE? -The last 8192 blockhashes are now stored and available for access in the `BLOCKHASH` system contract. The `BLOCKHASH` opcode semantics remains the same as before, just that the block number can now be specified in big-endian encoding. The blockhash system contract can also be called via the ethCall RPC method, with the block number in question being passed as calldata. +The last 8192 blockhash are now stored and available for access in the `BLOCKHASH` system contract. The `BLOCKHASH` opcode semantics remains the same as before, just that the block number can now be specified in big-endian encoding. The blockhash system contract can also be called via the ethCall RPC method, with the block number in question being passed as calldata. #### **Q:** What are system contracts? System contracts are interfaces defined as contracts, which are essential for certain Ethereum functions to occur. The contract approach is used instead of each client implementing the logic in order to simplify maintenance as well as allow for upgrades in the future with minimal overhead. From 1c922578a9815817087fda42d86401b5069b1450 Mon Sep 17 00:00:00 2001 From: parithosh Date: Wed, 6 Nov 2024 13:44:02 +0800 Subject: [PATCH 06/14] formatting --- docs/wiki/pectra-faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index 380a2690..935b6993 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -12,7 +12,7 @@ Overall #### **Q:** What is Prague/Electra? **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. -## Users/Devs +Users/Devs --- **FAQ**: #### **Q:** What is EIP-7702/Account abstraction? From e4e5353da004f13a675e19fa9eff8e369f00b356 Mon Sep 17 00:00:00 2001 From: parithosh Date: Wed, 6 Nov 2024 13:44:28 +0800 Subject: [PATCH 07/14] formatting --- docs/wiki/pectra-faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index 935b6993..1e1af593 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -42,7 +42,7 @@ The last 8192 blockhash are now stored and available for access in the `BLOCKHAS #### **Q:** What are system contracts? System contracts are interfaces defined as contracts, which are essential for certain Ethereum functions to occur. The contract approach is used instead of each client implementing the logic in order to simplify maintenance as well as allow for upgrades in the future with minimal overhead. -## Stakers +Stakers --- **FAQ**: #### **Q:** What changes about deposits? From 42bbe22c8b57c76bdd95df0237ea236dd3a535c5 Mon Sep 17 00:00:00 2001 From: parithosh Date: Wed, 6 Nov 2024 14:28:35 +0800 Subject: [PATCH 08/14] updating wordlist --- docs/wiki/pectra-faq.md | 8 ++++++++ wordlist.txt | 1 + 2 files changed, 9 insertions(+) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index 1e1af593..e266e5d6 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -12,6 +12,14 @@ Overall #### **Q:** What is Prague/Electra? **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. +There are 3 main features along with some smaller EIPs included in Pectra. They are: Max effective balance, Account abstraction and Execution Layer triggered exits. + +The MaxEB feature will allow the user to have a > 32ETH effective balance. This would allow users to consolidate many validators (or deposit new ones) into one up to 2048ETH. The requirement to use this feature is the setting of the `0x02` withdrawal credentials. A user can either make a deposit directly with `0x02` credentials or the user can move from `0x01` to `0x02`. + +With EIP-7702, The user wallet would be able to delegate control to a smart contract. This pattern allows a new wallet and app interaction design space, leading the path for future full account abstraction solutions. + +The Execution layer triggered exits feature allows the withdrawal address set in the `0x02` withdrawal credential is able to perform exits directly in the execution layer without any reliance on pre-signed BLS keys. This feature is mainly targetted at staking pools, who would be able to use smart contracts to fully control the validator lifecycle. + Users/Devs --- **FAQ**: diff --git a/wordlist.txt b/wordlist.txt index f73def49..1354df69 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -70,6 +70,7 @@ bitvector's bitvectors bitwise BLOBHASH +blockhash blockchain blockchain's blockchains From e14503f12b81e340ff6be5cf29c8dde3bb7c7ad3 Mon Sep 17 00:00:00 2001 From: Parithosh Jayanthi Date: Wed, 6 Nov 2024 07:28:52 +0100 Subject: [PATCH 09/14] Update docs/wiki/pectra-faq.md Co-authored-by: raxhvl <10168946+raxhvl@users.noreply.github.com> --- docs/wiki/pectra-faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index e266e5d6..8beb19d5 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -42,7 +42,7 @@ As a smart contract developer, you should know that after Prague the majority of As a security engineer / auditor, you must be aware that the previous assumption that a frame cannot be reentered when `msg.sender == tx.origin` no longer holds. This means the check is no longer suitable for reentrancy guards or flash loan protection. #### **Q:** What does the EIP-2537 BLS precompile add in pectra? -EIP-2537 Adds operation on BLS12-381 curve as a precompile to Ethereum. BLS12-381 precompile enables efficient BLS signature verification. This is useful for applications where multiple signatures need to be verified, such as proof checking systems. +[EIP-2537](https://eips.ethereum.org/EIPS/eip-2537) introduces operations on the BLS12-381 curve as precompiles to Ethereum. BLS12-381 precompiles enables efficient BLS signature verification. This is useful for applications where multiple signatures need to be verified, such as proof-checking systems. #### **Q:** How can I use the `BLOCKHASH` OPCODE? The last 8192 blockhash are now stored and available for access in the `BLOCKHASH` system contract. The `BLOCKHASH` opcode semantics remains the same as before, just that the block number can now be specified in big-endian encoding. The blockhash system contract can also be called via the ethCall RPC method, with the block number in question being passed as calldata. From 2720c2079c311a32ac37b6f37d69009a9c69dd85 Mon Sep 17 00:00:00 2001 From: parithosh Date: Wed, 6 Nov 2024 14:35:47 +0800 Subject: [PATCH 10/14] typo --- docs/wiki/pectra-faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index e266e5d6..82a02c29 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -18,7 +18,7 @@ The MaxEB feature will allow the user to have a > 32ETH effective balance. This With EIP-7702, The user wallet would be able to delegate control to a smart contract. This pattern allows a new wallet and app interaction design space, leading the path for future full account abstraction solutions. -The Execution layer triggered exits feature allows the withdrawal address set in the `0x02` withdrawal credential is able to perform exits directly in the execution layer without any reliance on pre-signed BLS keys. This feature is mainly targetted at staking pools, who would be able to use smart contracts to fully control the validator lifecycle. +The Execution layer triggered exits feature allows the withdrawal address set in the `0x02` withdrawal credential is able to perform exits directly in the execution layer without any reliance on pre-signed BLS keys. This feature is mainly targeted at staking pools, who would be able to use smart contracts to fully control the validator lifecycle. Users/Devs --- From ae0a5dd8a815f3f217ef248bb19003a9fc3bdf2f Mon Sep 17 00:00:00 2001 From: parithosh Date: Thu, 7 Nov 2024 11:55:23 +0800 Subject: [PATCH 11/14] updating pectra messaging --- docs/wiki/pectra-faq.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index 2d0451fa..179c6a8a 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -12,33 +12,33 @@ Overall #### **Q:** What is Prague/Electra? **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. -There are 3 main features along with some smaller EIPs included in Pectra. They are: Max effective balance, Account abstraction and Execution Layer triggered exits. +There are 3 main features along with some smaller EIPs included in Pectra. They are: [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) also known as Max effective balance (MaxEB), [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) and [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) also known as Execution Layer triggered exits. -The MaxEB feature will allow the user to have a > 32ETH effective balance. This would allow users to consolidate many validators (or deposit new ones) into one up to 2048ETH. The requirement to use this feature is the setting of the `0x02` withdrawal credentials. A user can either make a deposit directly with `0x02` credentials or the user can move from `0x01` to `0x02`. +The [MaxEB](https://eips.ethereum.org/EIPS/eip-7251) feature will allow the user to have a > 32ETH effective balance. This would allow users to consolidate many validators (or deposit new ones) into one up to 2048ETH. The requirement to use this feature is the setting of the `0x02` withdrawal credentials. A user can either make a deposit directly with `0x02` credentials or the user can move from `0x01` to `0x02`. -With EIP-7702, The user wallet would be able to delegate control to a smart contract. This pattern allows a new wallet and app interaction design space, leading the path for future full account abstraction solutions. +With [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), The user wallet would be able to delegate control to a smart contract. This pattern allows a new wallet and app interaction design space, leading the path for future full account abstraction solutions. -The Execution Layer (EL) _triggered exits_ is a new feature that allows the withdrawal address set in the `0x02` withdrawal credential to perform exits directly in EL, without relying on on pre-signed BLS keys. This feature is mainly targeted at staking pools, enabling them to use smart contracts to fully control the validator lifecycle. +The [Execution Layer (EL) triggered exits](https://eips.ethereum.org/EIPS/eip-7002 is a new feature that allows the withdrawal address set in the `0x02` withdrawal credential to perform exits directly in EL, without relying on pre-signed BLS keys. This feature is mainly targeted at staking pools, enabling them to use smart contracts to fully control the validator lifecycle. Users/Devs --- **FAQ**: -#### **Q:** What is EIP-7702/Account abstraction? -While EIP-7702 isn’t quite account abstraction, it does provide execution abstraction, i.e adds additional functionality to externally owned accounts (EOAs. This allows your EOA to do things like send transaction batches and delegate to other cryptographic key schemes, like passkeys. It does this by setting the code associated with the EOA to a protocol-level proxy designation. A full specification can be found [here](https://eips.ethereum.org/EIPS/eip-7702). It introduces a new transaction type that temporarily authorizes specific contract code for an EOA during a single transaction, allowing EOAs to function as smart contract accounts. This enables several use cases for users, including transaction batching, gas sponsorship, and privilege de-escalation. +#### **Q:** What is EIP-7702 and how does it relate to Account abstraction? +While [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) isn’t quite account abstraction, it does provide execution abstraction, i.e adds additional functionality to externally owned accounts (EOAs. This allows your EOA to do things like send transaction batches and delegate to other cryptographic key schemes, like passkeys. It does this by setting the code associated with the EOA to a protocol-level proxy designation. A full specification can be found [here](https://eips.ethereum.org/EIPS/eip-7702). It introduces a new transaction type that temporarily authorizes specific contract code for an EOA during a single transaction, allowing EOAs to function as smart contract accounts. This enables several use cases for users, including transaction batching, gas sponsorship, and privilege de-escalation. #### **Q:** Where can I find the specification for EIP-7702? How can I use it as a wallet dev? -The specification for EIP-7702 is can be found [here](https://eips.ethereum.org/EIPS/eip-7702). To get started as a wallet developer, you'll need to determine a smart contract wallet core to use with the EOA. Pay close attention to how the wallets [should be initialized](https://eips.ethereum.org/EIPS/eip-7702#front-running-initialization). Once you have determined the core wallet to use, you'll need to expose behavior like `eth_sendTransaction` and other custom methods for EIP-7702 specific functionality like batch transactions. +The specification for [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) is can be found [here](https://eips.ethereum.org/EIPS/eip-7702). To get started as a wallet developer, you'll need to determine a smart contract wallet core to use with the EOA. Pay close attention to how the wallets [should be initialized](https://eips.ethereum.org/EIPS/eip-7702#front-running-initialization). Once you have determined the core wallet to use, you'll need to expose behavior like `eth_sendTransaction` and other custom methods for [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) specific functionality like batch transactions. -#### **Q:** As a user, how can I use account abstraction? -To get the [benefits](https://ethereum.org/en/roadmap/account-abstraction/) of account abstraction, you need to use a wallet that supports it. Once your wallet of choice supports account abstraction, you will be able to make use of it. +#### **Q:** As a user, how can I use EIP-7702? +To get the [benefits](https://ethereum.org/en/roadmap/account-abstraction/) of EIP-7702, which is an early attempt at account abstraction, you need to use a wallet that supports it. Once your wallet of choice supports account abstraction, you will be able to make use of it. #### **Q:** Do I have to wait for my wallet to support EIP-7702? -Unfortunately yes, until your wallet integrates EIP-7702 it will not be possible to make use of the new functionalities it provides. +Unfortunately yes, until your wallet integrates [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) it will not be possible to make use of the new functionalities it provides. #### **Q:** What do I need to know about EIP-7702 as a smart contract dev? As a smart contract developer, you should know that after Prague the majority of users on Ethereum will now be able to interact with the chain in more complex ways than were feasible before. Many standards have been developed to work around the limitations of EOAs, such as [ERC-2612 Permit](https://eips.ethereum.org/EIPS/eip-2612). -#### **Q:** What do I need to know as a security engineer/auditor? +#### **Q:** What do I need to know about EIP-7702 as a security engineer/auditor? As a security engineer / auditor, you must be aware that the previous assumption that a frame cannot be reentered when `msg.sender == tx.origin` no longer holds. This means the check is no longer suitable for reentrancy guards or flash loan protection. #### **Q:** What does the EIP-2537 BLS precompile add in pectra? @@ -85,7 +85,7 @@ There is no direct way to move from `0x00` to `0x02`. You will need to first mov You can consolidate your validator to `0x02` withdrawal credentials via a self consolidation with both, the source and target pointing to your validator. This will change your withdrawal credentials to `0x02` and allows you to have a single validator with a balance of up to 2048 ETH. For new deposits, the `staking-cli` will support the `0x02` withdrawal credentials in the coming months before the Pectra mainnet Ethereum fork. #### **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 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. +[EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) or MaxEB 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](https://eips.ethereum.org/EIPS/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 validators? To consolidate your validators, you first need to ensure that both the source and target validators have either `0x01` or `0x02` credentials assigned. From 4df9cca6bf4cc30e47ff6221bc99bc02987081db Mon Sep 17 00:00:00 2001 From: parithosh Date: Thu, 7 Nov 2024 11:56:06 +0800 Subject: [PATCH 12/14] fix typo --- docs/wiki/pectra-faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index 179c6a8a..238e1b12 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -18,7 +18,7 @@ The [MaxEB](https://eips.ethereum.org/EIPS/eip-7251) feature will allow the user With [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), The user wallet would be able to delegate control to a smart contract. This pattern allows a new wallet and app interaction design space, leading the path for future full account abstraction solutions. -The [Execution Layer (EL) triggered exits](https://eips.ethereum.org/EIPS/eip-7002 is a new feature that allows the withdrawal address set in the `0x02` withdrawal credential to perform exits directly in EL, without relying on pre-signed BLS keys. This feature is mainly targeted at staking pools, enabling them to use smart contracts to fully control the validator lifecycle. +The [Execution Layer (EL) triggered exits](https://eips.ethereum.org/EIPS/eip-7002) is a new feature that allows the withdrawal address set in the `0x02` withdrawal credential to perform exits directly in EL, without relying on pre-signed BLS keys. This feature is mainly targeted at staking pools, enabling them to use smart contracts to fully control the validator lifecycle. Users/Devs --- From c257304f192381e8ce7cf101a5375b39976ce072 Mon Sep 17 00:00:00 2001 From: Parithosh Jayanthi Date: Thu, 7 Nov 2024 05:40:26 +0100 Subject: [PATCH 13/14] Update docs/wiki/pectra-faq.md Co-authored-by: raxhvl <10168946+raxhvl@users.noreply.github.com> --- docs/wiki/pectra-faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index 238e1b12..ff0dcfdf 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -12,7 +12,7 @@ Overall #### **Q:** What is Prague/Electra? **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. -There are 3 main features along with some smaller EIPs included in Pectra. They are: [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) also known as Max effective balance (MaxEB), [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) and [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) also known as Execution Layer triggered exits. +There are 3 main features along with some smaller EIPs included in Pectra. They are: [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) also known as Max effective balance (MaxEB), [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), and [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) also known as Execution Layer triggered exits. The [MaxEB](https://eips.ethereum.org/EIPS/eip-7251) feature will allow the user to have a > 32ETH effective balance. This would allow users to consolidate many validators (or deposit new ones) into one up to 2048ETH. The requirement to use this feature is the setting of the `0x02` withdrawal credentials. A user can either make a deposit directly with `0x02` credentials or the user can move from `0x01` to `0x02`. From 63cc11c896d8ab9d52af86184f919435126f6a27 Mon Sep 17 00:00:00 2001 From: parithosh Date: Thu, 7 Nov 2024 18:48:38 +0800 Subject: [PATCH 14/14] adding reference to 0x01 --- docs/wiki/pectra-faq.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/wiki/pectra-faq.md b/docs/wiki/pectra-faq.md index 238e1b12..9cab9dae 100644 --- a/docs/wiki/pectra-faq.md +++ b/docs/wiki/pectra-faq.md @@ -18,7 +18,7 @@ The [MaxEB](https://eips.ethereum.org/EIPS/eip-7251) feature will allow the user With [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), The user wallet would be able to delegate control to a smart contract. This pattern allows a new wallet and app interaction design space, leading the path for future full account abstraction solutions. -The [Execution Layer (EL) triggered exits](https://eips.ethereum.org/EIPS/eip-7002) is a new feature that allows the withdrawal address set in the `0x02` withdrawal credential to perform exits directly in EL, without relying on pre-signed BLS keys. This feature is mainly targeted at staking pools, enabling them to use smart contracts to fully control the validator lifecycle. +The [Execution Layer (EL) triggered exits](https://eips.ethereum.org/EIPS/eip-7002) is a new feature that allows the withdrawal address set in the `0x01` or `0x02` withdrawal credential to perform exits directly in EL, without relying on pre-signed BLS keys. This feature is mainly targeted at staking pools, enabling them to use smart contracts to fully control the validator lifecycle. Users/Devs --- @@ -67,7 +67,7 @@ There are 2 ways in which a validator can have `0x02` withdrawal credentials: 1. When you deposit a new validator with `0x02` withdrawal credentials 2. When you consolidate existing validators to `0x02` withdrawal credentials by sending a transaction to consolidation request address -The `0x02` withdrawal credential enables you to control the validator exit from your execution layer address as well as allows you to possess maximum effective balances of >32 ETH and <2048ETH. This means you can run one validator and have a single validator with a balance of up to 2048 ETH. +While both the `0x01` and `0x02` withdrawal credential enables you to control the validator exit from your execution layer address, only `0x02` allows the validator to possess a maximum effective balances of >32 ETH and <2048ETH. This means you can run one validator and have a single validator with a balance of up to 2048 ETH. #### **Q:** Can I deposit a validator with `0x02` credentials directly? Yes, you can deposit a validator with `0x02` credentials directly. This will allow you to have a single validator with a balance of up to 2048 ETH.