<img src="https://ethereum.org/_next/image/?url=%2F_next%2Fstatic%2Fmedia%2Fhero.94a1ecc4.png&w=1920&q=75" />

# Pectra Upgrade is Happening!!

*I have documented a few EIPs in detail from the Pectra upgrade. More EIPs from the upgrade will be added to this document as I continue to document them.*

- Sources :
1. https://www.youtube.com/watch?v=ufIDBCgdGwY
2. https://github.com/gnosischain/specs/blob/master/network-upgrades/pectra.md
3. https://cantina.xyz/introduction/pectra-competition-resources/what-is-the-pectra-upgrade

> This documentation is based on my understanding of the EIPs and discussions with ChatGPT. If you find any errors, please comment.

## Table of Contents

| EIP | Description | EL/CL |
|-----|------------|---|
| [EIP-7691](#EIP-7691-Blob-throughput-increase) | Blob throughput increase | Both |
| [EIP-7685](#EIP-7685-General-purpose-execution-layer-requests) | General purpose execution layer requests | Both |
| [EIP-7623](#EIP-7623-Increase-calldata-cost) | Increase calldata cost | EL |
| [EIP-7840](#EIP-7840-Add-blob-schedule-to-EL-config-files) |Add blob schedule to EL config files | EL |
| [EIP-7549](#EIP-7549-Move-committee-index-outside-Attestation) |Move committee index outside Attestation | CL |

---

## [EIP-7691: Blob throughput increase](https://eips.ethereum.org/EIPS/eip-7691)

### Why this EIP neeeded?
- Ethereum is scaling through a rollup-centric roadmap.
- The [Dencun upgrade](https://ethereum.org/en/history/#dencun) introduced blobs ([EIP-4844](https://eips.ethereum.org/EIPS/eip-4844)), and initial monitoring showed network stability with the new gas target and a decrease in re-org rates.
- The inclusion of the `IDONTWANT` message in Gossipsub (Ethereum's p2p messaging protocol) reduces unnecessary data transmission, saving network bandwidth.
- This EIP aims to support Ethereum's scaling until more efficient solutions are developed like `peerDAS`, with blob size adjustments based on network stability post-Dencun.

### EIP Proposal and Functioning
- Introducing the following fields :

| Title | Value |
| -------- | -------- |
| MAX_BLOBS_PER_BLOCK_ELECTRA | 9 |
| TARGET_BLOBS_PER_BLOCK_ELECTRA | 6 |
| MAX_BLOB_GAS_PER_BLOCK | 1179648 |
| TARGET_BLOB_GAS_PER_BLOCK | 786432 |
| BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE | 3338477 |

- At **PECTRA_FORK_EPOCH**, the **consensus layer clients** will use `MAX_BLOBS_PER_BLOCK_ELECTRA` and `TARGET_BLOBS_PER_BLOCK_ELECTRA`.
- At **PECTRA_FORK_EPOCH**, the **execution layer** will use `MAX_BLOB_GAS_PER_BLOCK`, `TARGET_BLOB_GAS_PER_BLOCK`, and `BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE`.
- `MAX_BLOB_GAS_PER_BLOCK` and `TARGET_BLOB_GAS_PER_BLOCK` will replace their counterparts from **EIP-4844**.
- `BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE` will replace `BLOB_BASE_FEE_UPDATE_FRACTION` from **EIP-4844**.

#### Impact on Blob Base Fee Adjustments

In each block, there are two possible scenarios:

##### **Before EIP-7691**
- The **target-to-max blob ratio** was **1:2**.
- If the block contained **full blobs** (reaching max capacity), the **blob base fee** increased by **~12.5%**.
- If there were **no blobs** in the block, the **blob base fee** decreased by **~11.1%**.
- This mechanism encouraged users to store data in blobs when demand was low.

##### **After EIP-7691**
- The **target-to-max blob ratio** changed to **2:3**.
- With **full blobs**, the **blob base fee** now increases by **~8.2%** (previously ~12.5%).
- If there are **no blobs**, the **blob base fee** now decreases by **~14.5%** (previously ~11.1%).
- This adjustment is driven by the introduction of specific value of **`BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE`**, which ensures a more balanced response to blob usage.

### Risks & Mitigations
#### Risks
1. Increased network bandwidth usage, especially for validators with limited resources.
2. The fork could cause temporary network congestion.
#### Mitigations
1. Conduct simulations on both mainnet and testnet to test large blocks and blobs.
2. Monitor the network closely during the fork to identify and address potential issues.

---

## [EIP-7685: General purpose execution layer requests](https://eips.ethereum.org/EIPS/eip-7685)

> This is a foundational EIP that will serve as a basis for future EIPs, enabling further standardization of `request_type`.

### Why this EIP neeeded?
- Currently, communication between the Execution Layer (EL) and Consensus Layer (CL) is limited to block creation and attestation.

One problem is, to become a validator in the Proof-of-Stake (PoS) system, a node operator must send 32 ETH to the smart contract [0x00000000219ab540356cBB839Cbe05303d7705Fa](https://etherscan.io/address/0x00000000219ab540356cBB839Cbe05303d7705Fa#code). This transaction is processed like a regular transaction, and the CL continuously monitors the contract's state to update the validator list whenever a new entry appears. However, exiting as a validator requires a manual request sent directly to the CL.

This EIP aims to standardize requests from the Execution Layer (EL) to the Consensus Layer (CL) using smart contract events, eliminating intermediaries and manual processes.

### EIP Proposal and Functioning
A request object consists of:
- **`request_type`** – Defines the type of request.
- **`request_data`** – A raw bytes array ( opaque byte data because this allows `request_data` to be formatted into different encoding schemes in the future, such as **SSZ** or **LEB128**. ).

The request structure is represented as:
`request = request_type ++ request_data`

A new **32-byte value** called `requests_hash` is added to the block header. This represents the **hash of all requests** in that block.

#### Request Hash Calculation
1. A list of all requests is created.
2. Requests with **empty `request_data`** are **excluded** to prevent identical hashes that could cause collisions in block with same `request_type` and empty `request_data`.
3. The remaining **`request_type` values are sorted in ascending order**.
4. A **SHA-256 hash** of the ordered list is computed to generate the `requests_hash`.

*Note:* Within the same `request_type`, the **order of requests is not defined** in this EIP.

#### Request Generation and Validation

##### Source of Requests
Requests originate from **transactions executed on the EL smart contract** i.e. an EOA. The contract:
- Stores the **request object**.
- Emits an **event** to propagate the request.

##### Validation Process
- Full validation **is not possible** on the **Execution Layer (EL)**.
- The EL contract performs **possible validations** before emitting the request event.
- Complete validation occurs on the **Consensus Layer (CL)** when processing the request.

### Risks & Mitigations
#### Risks
1. There is no standardized method for handling requests within the same type, which may result in unintended behavior.
2. Since the Execution Layer (EL) lacks proper validation, an attacker could flood the Consensus Layer (CL) with invalid requests, potentially causing network congestion.
#### Mitigations
1. Establish a standardized approach for handling intra-type requests.
2. Implement validation on the Execution Layer (EL) to filter out faulty requests before they reach the Consensus Layer (CL).

---

## [EIP-7623: Increase calldata cost](https://eips.ethereum.org/EIPS/eip-7623)

### Why this EIP neeeded?
- The current calldata cost allows a maximum block size of **7.15 MB**, while the average block size remains around **100 KB**.
- The goal is to **reduce the maximum calldata usage** by increasing its cost.
- This primarily impacts **data-centric applications** that rely on storing large amounts of data on-chain.
- Raising calldata costs makes **heavy calldata transactions more expensive**, discouraging their use and creating **room for more blobs and regular transactions**, which could eventually lead to an **increase in the block gas limit**.
- Since the **block gas limit hasn’t increased since EIP-1559** and **calldata costs have remained unchanged since EIP-2028**, EIP-4844 introduces **blobs** as a more efficient alternative for data availability.
- Because calldata remains **permanently stored on-chain**, it should be **deprioritized** in favor of **blobs**, which provide a more scalable solution.

### EIP Proposal and Functioning

#### Introducing the Following Fields

| Parameter | Value |
| -------- | -------- |
| `STANDARD_TOKEN_COST` | 4 |
| `TOTAL_COST_FLOOR_PER_TOKEN` | 10 |

#### Current Gas Calculation Formula
The total gas usage for a transaction is currently determined by:

tx.gasUsed = (
    21000
    + STANDARD_TOKEN_COST * tokens_in_calldata
    + execution_gas_used
    + isContractCreation * (32000 + INITCODE_WORD_COST * words(calldata))
)

- Calldata Cost:
- `0x00` bytes → 4 gas
- `0x01` - `0xFF` bytes → 16 gas

- Where:
- `21000` → Base gas cost for updating the sender's nonce.
- `tokens_in_calldata` → zero_bytes_in_calldata + (nonzero_bytes_in_calldata * 4).
- `isContractCreation` → Boolean indicating if a contract is being created.
- `execution_gas_used` → Gas required for executing opcodes in the transaction.
- `INITCODE_WORD_COST` → 2 gas (as per EIP-3860).

#### Updated Gas Calculation Formula

tx.gasUsed = (
    21000
    +
    max(
        STANDARD_TOKEN_COST * tokens_in_calldata
        + execution_gas_used
        + isContractCreation * (32000 + INITCODE_WORD_COST * words(calldata)),
        TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata
    )
)

#### Effects
- The increase in calldata costs reduces the maximum possible block size, making room for more transactions and blobs introduced in EIP-4844.
- Data-centric applications relying heavily on calldata for on-chain storage will face higher costs.
- Encourages the use of blobs instead of calldata for data availability, aligning with Ethereum's scalability goals.

#### Key Changes

##### Before this EIP:
- **Zero bytes (`0x00`) cost** → **4 gas**
- **Non-zero bytes (`0x01 - 0xFF`) cost** → **16 gas**

##### After this EIP:
- **Zero bytes (`0x00`) cost** → **10 gas**
- **Non-zero bytes (`0x01 - 0xFF`) cost** → **40 gas**

#### Implementation Considerations
- **Wallets & node software** must update their **gas estimation logic** to incorporate `TOTAL_COST_FLOOR_PER_TOKEN`.

### Risks & Mitigations
#### Risks
1. Wallets and node operators must update their gas estimation logic; failure to do so may result in transaction failures and unnecessary gas expenditure.

#### Mitigation
1. Implement the updated gas estimation formula in the codebase.

---

## [EIP-7840: Add blob schedule to EL config files](https://eips.ethereum.org/EIPS/eip-7840)

### Why this EIP neeeded?

- Currently, when the `eth_feeHistory` RPC method is called to fetch recent gas fee data, the EL queries the CL using the engine APIs`engine_newPayloadV3` call to retrieve `blobGasUsed` and `excessBlobGas`. This creates unnecessary overhead, which this EIP aims to eliminate by providing a configuration-based solution.
- The aim is to enable dynamic adjustment of target and max blob counts per block, along with the blob base fee update fraction, while reducing complex handshakes over the Engine API.

### EIP Proposal and Functioning

- Extend the configuration files with a new object `blobSchedule` which has following shape :

"blobSchedule": {
  "cancun": {
    "target": 3,
    "max": 6,
    "baseFeeUpdateFraction": 3338477
  },
  "prague": {
    "target": 6,
    "max": 9,
    "baseFeeUpdateFraction": 5007716
  }
}

#### Implementation Considerations
- Clients must configure these settings for each fork, and if any are missing or incomplete, it is up to the client developers to determine how to handle the situation.

### Risks & Mitigations

#### Risks
1. Improper handling of implementation may result in invalid block proposals.

#### Mitigations
1. Implement a fallback mechanism for blob configuration settings by either ensuring the config is set, defaulting max and target values to zero, or using values from the previous fork.

---

## [EIP-7549: Move committee index outside Attestation](https://eips.ethereum.org/EIPS/eip-7549)

### Why this EIP needed?
1. **Validators Cast Their Votes by Signing a Message Containing:**
- **LMD GHOST Vote**: `(beacon_block_root, slot)` [explained below]
- **Casper FFG Vote**: `(source, target)` [explained below]
- **Committee Index**: `(index)`, which identifies the validator's assigned committee

2. **Aggregation Within the Same Committee**
- All validators in the same committee sign the same attestation message, where all fields remain identical.
- Their votes can be aggregated into a single signature.
- Their public keys can also be aggregated for verification using the **BLS12-381** signature scheme at the **Beacon Chain (Consensus Layer)**.

3. **Limitation of Cross-Committee Aggregation**
- Validators from different committees have distinct **committee index** values.
- Since the **committee index** differs, aggregated votes from different committees **cannot be merged further**.
- This results in separate verification for each committee on the Beacon Chain.

4. **Verification Complexity and Costs**
- For **N** validators spread across **K** different committees, the number of required signature verifications was:
`O(K) (one verification per committee)`
- This led to **higher verification costs**.

#### **Casper FFG** finalizes blocks at fixed intervals.
- Each **epoch (32 slots → new block proposal each slot)** includes a **checkpoint block** that validators vote on.
- A block is **justified** if it receives at least **2/3 of validator votes** within the epoch.
- **Finalization rule:** When a new checkpoint is justified, the **previous justified checkpoint gets finalized**.
- `source` → The most recent **justified block**.
- `target` → The new block they want to **justify in the future**.

| Epoch | Checkpoint | Status |
|---------|-----------|-------------------------------|
| X | A | Justified ✅ |
| X+1 | B | Justified & A Finalized 🔥 |
| X+2 | C | Justified & B Finalized |

| Epoch | **Source Vote** (Most Recent Justified) | **Target Vote** (New Checkpoint to Justify) |
|---------|---------------------------------|----------------------------------|
| X+1 | A | B |
| X+2 | B | C |
| X+3 | C | D (next checkpoint) |

#### LMD GHOST (Latest Message Driven Greedy Heaviest Observed Subtree)

LMD GHOST is a fork-choice rule used in Ethereum’s Proof-of-Stake (PoS) consensus. It helps resolve situations where multiple blocks are produced simultaneously, leading to a fork in the chain.

- Validators vote for the block they consider the best candidate for the chain head, based on their **latest justified checkpoint**.
- Each validator's vote includes:
- `beacon_block_root` → The block hash of the new block they believe should be the head of the chain.
- `slot` → The current slot number in which the vote is cast.
- The chain follows the **heaviest subtree**, meaning the branch with the highest total validator stake backing it is chosen as the canonical chain.

### EIP Proposal and Functioning
- The goal of this EIP is to remove the **Committee index (`index`)** from the **Attestation message container**, allowing **cross-committee signature aggregation and verification** at the **Beacon Chain**. This optimization reduces the verification complexity to **O(1)**.

#### **Consensus Layer (CL) Changes**
- Set the **index** field in `AttestationData` to a fixed value of **zero**.
- Move **committee indexing data** to the outer `Attestation` container using `committee_bits`.
- Expand the **aggregation_bits** capacity to cover **all committees within a slot**.

class AttestationData(Container):
    slot: Slot
    index: CommitteeIndex -> 0 //going to set 0 
    # LMD GHOST vote
    beacon_block_root: Root
    # FFG vote
    source: Checkpoint
    target: Checkpoint

[source](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#attestationdata)

class Attestation(Container):
    aggregation_bits: Bitlist[MAX_VALIDATORS_PER_COMMITTEE * MAX_COMMITTEES_PER_SLOT]  # [Modified in Electra:EIP7549]
    data: AttestationData
    committee_bits: Bitvector[MAX_COMMITTEES_PER_SLOT]  # [New in Electra:EIP7549]
    signature: BLSSignature

[source](https://github.com/ethereum/consensus-specs/blob/2c1f677187e6534aec77057a7d1cc746a40d3630/specs/electra/beacon-chain.md#attestation)

#### Deprecation strategy

- In each slot, the maximum number of committees can be **64**.
- Each attestation from a committee includes a **bitfield** instead of a list of validator IDs.

##### **How the Bitfield Works**
- Each bit in the bitfield represents a validator’s participation:
- `1` → Validator participated in the attestation.
- `0` → Validator did not participate.

Example:

| | |
| -------- | -------- |
| Bitfield | 10110110 |
| Indexes | 01234567 |

- Validators **0, 2, 3, 5, and 6** have attested (voted).
- Validators **1, 4, and 7** have not attested.

##### **Why `MAX_ATTESTATIONS` is Reduced**
- Since attestations from all committees are aggregated, the **bitfield size increases by 64 times**.
- To manage this increase in size, the maximum number of attestations included in a beacon block (`MAX_ATTESTATIONS`) is reduced:
- Previously: **128** attestations per block ([Phase 0](https://github.com/ethereum/consensus-specs/blob/2c1f677187e6534aec77057a7d1cc746a40d3630/specs/phase0/beacon-chain.md#max-operations-per-block)).
- Now: **8** attestations per block ([Electra Upgrade](https://github.com/ethereum/consensus-specs/blob/2c1f677187e6534aec77057a7d1cc746a40d3630/specs/electra/beacon-chain.md#execution)).

##### **Impact on Voting Capacity**
- Even though fewer attestations are included per block, each attestation now represents **aggregated** votes from multiple committees.
- This change increases the **total number of votes recorded per block by 4 times** compared to the previous system, which stored individual attestations separately.
- The new approach optimizes storage while increasing overall voting efficiency.

##### why `MAX_ATTESTER_SLASHINGS` is Reduced
- Due to the aggregation of attestations across committees, the size of each attestation has increased **64 times**.
- In a network with **1 million validators**, the worst-case size of a single **AttesterSlashing** per block is:
- **488 KB (uncompressed)**
- **320 KB (compressed using Snappy)** – still significantly large!
- To prevent excessive block sizes, the **MAX_ATTESTER_SLASHINGS** per block has been reduced from **2 to 1**.

### Risks & Mitigations
##### Risks
1. A change in the Attestation container could render attestations invalid after a fork, potentially leading to validators being penalized for going offline.
2. If the implementation fails to verify the attestation signature before registering it on the P2P gossip network, there is a risk of cache pollution.
##### Mitigations
1. Develop a system that ensures attestations remain valid across forks.
2. Verify the attestation signature before registering it to prevent invalid data from polluting the cache.

---

<div style="text-align: center;">
<img src="https://media1.giphy.com/media/v1.Y2lkPTc5MGI3NjExdTdibmZ6am9saW01dmZjMG1rcGs1Y3doejJwbTIzNm10bDVvZjRyYSZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/2wJO0stFjkKtuo7Gzr/giphy.gif" />
</div>

<div style="text-align: center;">
<p align="center">
<a href="https://www.linkedin.com/in/anmol-7111/">LinkedIn</a> |
<a href="https://github.com/Anmol-Dhiman">GitHub</a> |
<a href="https://x.com/sherlockvarm">X</a> |
<a href="mailto:[e-mail]">Mail</a>
</p>

</div>