EIP-7691 Ethereum, EIP-7691 Blob Throughput, and EIP-7691 Blob Throughput Increase Pectra

EIP-7691: What’s New After the Pectra Hard Fork

EIP-7691 officially rolled out with Ethereum’s Pectra hard fork on May 7, 2025, and it's definitely making waves. The blob throughput has been upgraded from a max of 3/6 to a more impressive 6/9. On top of that, the blob fee dynamics have been adjusted to trigger quicker price drops when demand falls below that target.

In this post, we’re taking a closer look at the changes, how much more capacity you have now, what rollups and infrastructure teams should jump on immediately, and what’s coming up next with PeerDAS. Don’t miss it: (blog.ethereum.org)

---

TL;DR for decision-makers

• Pectra has really raised the bar by doubling the target blob capacity to 6 blobs per block (with a max of 9). They've also tweaked the blob base fee curve, so prices drop quicker when things are quiet and rise slowly when it's busy. This is definitely a win for Layer 2s! (eips.ethereum.org)
• In the early days after Pectra rolled out, blobs were basically “virtually free” again since demand dipped below the new 6-blob target. But now, validators are juggling more short-lived data between prune windows. (galaxy.com)
• Also part of Pectra, EIP‑7623 has raised the floor price for calldata, which helps keep the worst-case block sizes in check. This adjustment has opened up some extra space for the blob increase. If you still depend on calldata for data availability, it might be worth revisiting your approach. (eips.ethereum.org)
• What’s next on the horizon? PeerDAS (EIP‑7594) is gearing up to shift Ethereum towards sampled data availability. This change will create a ton more blob space without overloading the nodes. Teams should definitely run some tests on devnets to challenge their assumptions. (eips.ethereum.org)

---

What exactly EIP‑7691 changed

• Blobs per block target: 3 → 6
• Max blobs allowed per block: 6 → 9
• Check out the updated blob gas settings that clients will use after the fork:
  • TARGET_BLOB_GAS_PER_BLOCK = 786,432
  • MAX_BLOB_GAS_PER_BLOCK = 1,179,648
  • GAS_PER_BLOB = 2^17 = 131,072 blob-gas
  • BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE = 5,007,716 (this is the retuned update fraction) (eips.ethereum.org)

Why the Curve Feels Different

Before Pectra (3/6), we noticed that when full blobs showed up, the blob base fee jumped by about 12.5% from one block to the next. On the other hand, when empty blobs came into play, that fee dipped by roughly 11.1%. Now, if we fast forward to post-Pectra (6/9), things have shifted a bit with some new parameters aiming to make the system more responsive. Nowadays, full blobs only bump up the fee by around 8.2%, while those empty sections can drop it by a notable 14.5%.

So, what does this really mean for us? Basically, it implies that when things are a bit slow, prices tend to dip more quickly. On the flip side, when there’s a lot going on, those prices tend to creep up more slowly. If you're curious to dive deeper, you can find more info right here: (eips.ethereum.org).

Activation Facts and Context:

• Pectra Mainnet: Launched at epoch 364,032 on May 7, 2025, this new network combines the best of Prague (EL) and Electra (CL). If you want to dive deeper, you can find more details here.
• The Pectra Meta-Spec (EIP-7600) features EIP-7691 along with EIP-7623, EIP-7702, EIP-7251, and a few other interesting proposals. Want to learn more? Check it out here.

---

How much “new” capacity you actually got

Blobs really bring the heat with 4096 field elements, each weighing in at 32 bytes. When you do the math, that amounts to a solid 131,072 bytes (or about 128 KiB) for each blob. Since we have those handy 12-second slots, which add up to roughly 7,200 blocks in a day, let’s break it down a bit:

• If we hit the new goal of 6 blobs per block, we’re looking at about 6 × 128 KiB × 7,200, which brings us to around 5.3 GiB of DA throughput daily.
• Now, if we really push it and max out at 9 blobs per block, that shoots up to about 9 × 128 KiB × 7,200, giving us a peak of roughly 7.9 GiB in a single day.

These figures are just some quick estimates based on the blob size from EIP-4844 and how Ethereum’s block timing works. You can find more details right here: (eips.ethereum.org).

Weekly target capacity is on the rise, shifting from around 150k blobs per week (that breaks down to about 3 blobs per block) to an impressive 300k blobs weekly (or 6 blobs per block). This gives you a nice framework for thinking about L2 batch throughput while you're planning your budget.

Since Pectra launched, it’s been interesting to see that Base typically nabs about a third of that total capacity, landing somewhere around 50-60k blobs each week. At the same time, Taiko, World Chain, and Arbitrum are all vying for their share of the action too. If you want to dig deeper into this topic, check it out here.

---

Immediate market impact after Pectra

• Demand: In the first five full days after the fork, rollups picked up about 25.6k blobs each day. That’s quite the jump from around 21.2k blobs per day before--talk about a solid increase of 20.8%! However, they’re still not quite reaching the new target of 6 blobs yet, which means we’re enjoying some “virtually free” blobs for the time being. (galaxy.com)
• Cost and burn: Since the usage is still below target, blob base fees have taken a nosedive down to the minimum. This means less ETH is being burned from blob usage, which is a nice little perk for rollups as it boosts their margins. Interestingly, some L2 fees haven’t dropped as much because certain teams have decided to keep their prices steady, leading to a bit of a boost in net income. (galaxy.com)
• Validator/CL storage between prunes: With more blobs being snagged every day, we’re seeing more data hang around until we reach that ~18-day pruning window. Estimates show that just after Pectra, the total retained data peaked at around ≈44.6 GB. (galaxy.com)

---

Why EIP‑7623 matters to your DA strategy

EIP‑7623 has raised the calldata "floor" cost to 10/40 gas for zero and non-zero bytes respectively, especially for those data-heavy transactions. This tweak is designed to reduce the worst-case payload size in the execution layer (EL) and its ups and downs. The whole idea is to lighten the load a bit so the network can manage more blob transactions without causing issues with propagation and reorg rates. In simpler terms, blobs now have more room to grow, making calldata less attractive for handling large amounts of data. If you’re curious for more details, check it out here.

What This Means for You:

If you’re wondering how this affects you, here’s the scoop:

• Stay Informed: You’ll want to keep yourself updated about the changes and how they could impact your daily life or work.
• Adapt Quickly: Be prepared to tweak your plans or strategies based on the new information. Flexibility is key!
• Reach Out for Help: If you’re feeling a bit lost, don’t hesitate to ask questions or seek guidance from those in the know.

In short, staying proactive and connected will help you navigate any shifts that come your way!

• If you notice that your batcher is still flipping to calldata during busy times, it might be a good idea to reevaluate those thresholds. After Pectra, that fallback can really rack up the costs and could throw a wrench in the network's overall objectives.
• The quality of P2P connections improves significantly when data availability (DA) shifts to blobs. This is one of the reasons why the core devs felt confident about giving the thumbs up for 6/9. (blog.ethereum.org)

---

1) Right‑sizing batches

• Imagine your rollup is pushing out around 2 MiB of compressed DA every minute. That breaks down to about 128 KiB per blob, which means you’re looking at roughly 16 blobs hitting the network each minute. Over on Ethereum's side, they're pumping out 5 blocks every minute, which calls for around 3.2 blobs per block. That’s well below the 6-blob target, so you can generally expect low fees and not much price volatility.
• But if demand suddenly spikes to about 8 blobs per block for your chain’s group, you might notice fees inching up a bit more gradually compared to how things were with Pectra: +8.2% per full block instead of the previous +12.5%. Just keep in mind that during those busy times, it’ll take longer to double, while it’ll happen quicker when things cool off a bit. (eips.ethereum.org)

2) Per-Blob Fee Math You Can Implement Today

Alright, let’s dive into the cost of each blob. It’s pretty straightforward:

• Cost per blob = GAS_PER_BLOB × blob_gas_price. So, if we set GAS_PER_BLOB at 131,072 blob-gas and roll with a standard blob-gas price of 1 wei, each blob will run you 131,072 wei. Honestly, that's pretty cheap when you look at the bigger picture.

If you need help estimating blob_gas_price on your local setup, you can grab the excess_blob_gas from the header and use the “fake exponential” function from EIP‑4844. And hey, make sure you update your constants with the Pectra values!

3) Daily Capacity Assurance

• If you're looking to hit roughly 5.3 GiB each day, and you’ve got a single app that’s pulling in about 0.3 GiB daily, that’s just around 5.6% of your target. As long as the total traffic across all the Layer 2 solutions stays below your goal, those batches you submit should clear close to the floor prices. Don’t forget to keep an eye on the overall usage through public dashboards and Etherscan’s blob views. For more details, check it out here.

---

Operational playbook: best emerging practices

For Rollup Platform Teams (Batchers/Provers/Settlement):

• Re-tune blob gas guardrails
  • It’s time to give those max_fee_per_blob_gas ceilings and backoff multipliers a little refresh using the new 6/9 parameters. This will help you avoid dropping batches during those annoying little spikes. Since the curve is decaying quicker after Pectra, don’t forget to use those “wait a slot” strategies before you switch things up or shell out more than you really need to. (eips.ethereum.org)
• Opt for blobs instead of calldata more often
  • Let's tweak the fallback logic thresholds based on EIP-7623. We should only revert to calldata for handling metadata or special cases. This way, you’ll keep your costs down and ensure smooth network propagation. (eips.ethereum.org)
• Implement solid blob retrieval and verification
  • To grab those blobs, go ahead and fetch them directly from your local beacon node using the Beacon API. You can do it like this: GET /eth/v1/beacon/blob_sidecars/{block_id}?indices=…. Make sure you’re verifying those against versioned hashes (BLOBHASH) and KZG commitments. And just to keep everything running without a hitch, set up multi-provider failover with options like Alchemy, QuickNode, and Blockdaemon. You’ll thank yourself later for the extra peace of mind! (alchemy.com)
• Follow the Latest Derivation Guidance from OP Stack/Nitro/zk Stacks
  • Just a heads up, OP Stack is focusing on retrieval via blob_sidecars and verifying it using versioned hashes. It’s important that your derivation pipeline handles blob batches and calldata metadata in a consistent way to maintain that order. You can check it out for more details here: (specs.optimism.io)
• Budgeting for Retained Blob Data in Your CL Nodes
  • Your nodes should keep blobs around for roughly 4,096 epochs, which translates to about 18 days. Be sure to adjust those prune margins accordingly and have some extra room for any spikes in demand (you know, like the blob_prune_margin_epochs shown by Lighthouse). Plus, caching recent blobs across multiple regions can really help cut down those RTOs during any reorgs. Check out more details here.

For Validator Operators and Node Infra:

If you’re operating a validator or handling node infrastructure, there are some important points to keep track of. Here’s a handy overview to help you get through the essentials:

• Stay Updated: Make it a habit to check for software updates and security patches. Keeping everything up to date helps with performance and boosts security.
• Monitor Performance: Stay on top of your node's performance metrics. Using tools like Grafana and Prometheus can really simplify this for you.
• Backup Often: Don’t forget to regularly back up your validator's keys and configuration files. Losing something important would really be a bummer!
• Networking: A strong network connection is super important! You want to go for low latency and high throughput so your node stays responsive all the time.
• Get Involved in Governance: Join the conversation with the community and keep an eye out for any new proposals or changes happening in the ecosystem. Your input is super important!

Resources

• Validator Operator Guide
• Node Infrastructure Best Practices

Quick Tip

If all the tech jargon has you feeling swamped, why not dive into some forums or hang out in Discord channels that focus on your blockchain? There's a thriving community eager to lend a hand and share their insights!

Conclusion

At the end of the day, running a validator really comes down to keeping your node in tip-top shape, staying involved, and always being open to learning new things. Just keep moving forward, and you’re going to do awesome!

• Keep an eye on how propagation and reorgs play out during high-DA windows
  • Pectra’s combo (7691 + 7623) aims to keep those tricky worst-case blocks under control, but it’s still smart to keep tabs on block propagation tails and peer health when things get busy. Make sure to check out client dashboards and research threads that dive into what happens post-fork regarding propagation and reorgs. You can find some useful info here.
• Keep an eye on bandwidth limits
  • It’s important to distribute those blobs! Even though 7623 has made the calldata extremes a bit tighter, ramping up blob data can really boost the consensus-layer bandwidth. So, take a minute to check out your peering, I/O, and CPU configurations, especially if you're planning to bring more validators together with EIP-7251. (blog.ethereum.org)
• Give your CL/EL versions a quick review against the Pectra meta (EIP-7600)
  • Ensure your node stacks are aligned with the EIPs and the engine API updates mentioned in the Prague/Electra specs. (eips.ethereum.org)

For Product and Finance Leaders:

• When utilization dips below the target, you can look forward to reduced and less volatile DA costs.
  • The recent update fraction is designed to balance out prices and minimize tail risk. If you’ve been holding onto large buffers before Pectra, it could be a good opportunity to release some working capital or redirect it towards user incentives. (eips.ethereum.org)
• Don’t forget to take a look at the user-visible fee policies.
  • A few Layer 2 solutions have managed to keep retail fees stable, even while DA costs dropped, all to enhance their profit margins. It's worth considering whether you’re aiming to capture those margins, drive growth, or maybe strike a balance between the two. Be sure to monitor blob burn and margins using research dashboards. (galaxy.com)

---

How to see the changes live

• Etherscan:
  • Want to see real-time blob submissions? Just visit etherscan.io/txsBlobs!
  • Curious about blob counts for each block? Check out etherscan.io/blocks where you can find the new target of 6 and a max of 9 blobs. For more details, you can also explore this link: (info.etherscan.com).
• EF Blog Posts:
  • Jump into the details of the Pectra mainnet announcement and see why blob scaling is such a big deal. Take a look here: (blog.ethereum.org)
• EIP Pages (Primary Specs):
  • Check out the specs for EIP‑7691 (blob throughput), EIP‑7623 (calldata floor), and EIP‑4844 (blob mechanics) at (eips.ethereum.org).

---

Deep technical details teams often miss

• Blob sizing and KZG specifics
  • Each blob contains 4096 field elements from BLS12‑381 Fr, with each of those elements being 32 bytes. They’re all wrapped up as a degree‑4095 polynomial. When it comes to commitments and per‑point proofs, those are pretty lightweight at just 48 bytes. This design helps keep verification costs down and paves the way for future compatibility with DAS. (eips.ethereum.org)
• On‑chain visibility and BLOBHASH
  • Here’s the scoop: EVM contracts can’t directly peek into the blob contents. Instead, they’ve got to work with versioned hashes using the BLOBHASH opcode (0x49). It makes sense to keep the metadata on L1 to a minimum and rely on off‑chain availability along with KZG proofs. (eips.ethereum.org)
• Fee computation with Pectra
  • The not-so-simple exponential function combines excess_blob_gas and the updated fraction to calculate blob_gas_price. When the target/max ratio is set at 6/9, you'll notice that base fees decrease more rapidly when you're below the target. This opens up great opportunities for “post when cheap” strategies to really shine. (eips.ethereum.org)

---

What’s next: PeerDAS and a bigger blob future

PeerDAS Overview

So, PeerDAS (EIP‑7594) is gearing up for its Last Call phase, which is expected to kick off by the end of 2025, and it's got some pretty cool stuff lined up. Thanks to its peer-to-peer data availability sampling, nodes will only have to download a tiny portion of the blob data to ensure it’s available. This really opens the door for scaling blobspace even further without putting a strain on the bandwidth of every single node.

Be on the lookout for some changes happening with clients and APIs, especially regarding cell proofs and custody groups. And hey, make sure to give your pipelines a spin on the PeerDAS devnets! For more info, you can dive into the details here.

• So, Ethereum.org’s roadmap and some posts from the Ethereum Foundation have been teasing something referred to as “Fusaka,” which includes PeerDAS. There's been quite a bit of chatter in the community about targets like 48 or 72 blobs when DAS rolls out. Keep in mind, though, that these numbers are more like brainstorming ideas rather than hard commitments. It's smarter to think about different capacity scenarios instead of locking ourselves into firm promises. (info.etherscan.com)

---

Implementation checklist (7Block Labs’ quick start)

• First things first, let’s update the constants and fee estimators to match the Pectra values. Make sure to unit-test that blob fee backoff and rate-limit logic against those 8.2%/14.5% dynamics. You can dive into the nitty-gritty here.
• Next up, we need to beef up the blob fetching and verification process. Integrate the Beacon API blob sidecars with some redundancy and make sure you’re doing some strict KZG verification. Oh, and don’t forget to pin the recent blobs in those cache regions you're working with. You’ll find more details here.
• Time for a cleanup! Let’s get rid of the DA bulk fallbacks to calldata, except for the metadata section. Also, we need to re-profile the costs under EIP-7623. If you want to dive deeper, check it out here.
• Keep an eye on these important metrics: blob utilization compared to the target, blob base fee, per-L2 share, and how much CL blob storage you’re retaining between prunes. Set up alerts for when the utilization bumps over 80% of the target for several consecutive epochs. Get the details here.
• Lastly, let's kick off the PeerDAS readiness. Test those cell proof flows, custody metrics, and builder interfaces on the latest devnets. You can find the notes here.

---

FAQ

• Is blob capacity “double” or “+50%”?
  • Well, it actually varies depending on what you're looking at. The target capacity is indeed doubled--from 3 to 6. But when it comes to the maximum capacity, that gets a 50% increase, jumping from 6 to 9. So, it’s all about whether you mean the target or the max. The EF blog points out that the usable target throughput practically doubles. (blog.ethereum.org)
• How long are blobs stored?
  • Blobs are kept for around 4,096 epochs, which translates to about 18 days. After that period, they could be pruned by nodes, so it's crucial to keep an eye on your off-chain data pipelines and proofs. For more info, take a look here.
• Wondering how to keep tabs on blob usage for each block?
  • Head over to Etherscan to see live blob submissions and check out the counts for each block. If you're keen on diving into the data, Dune dashboards (like hildobby) are fantastic for tracking weekly consumption by L2. You can find more info here.

---

Conclusion

For startups and businesses diving into Ethereum, Pectra’s EIP‑7691 brings some awesome, practical perks for scaling at this very moment. Think about it: more wiggle room, reduced and smoother data availability (DA) costs, plus a clearer route to PeerDAS.

In the short run, it's a good idea to tweak your batchers and fee guards. Also, make the full switch to blobs instead of calldata, and double-check that blob retrieval is working smoothly. If you look a bit further down the line, it's time to start prepping for sampled DA. This lets your infrastructure verify availability without needing to download every last byte. Plus, you should expect to boost your blob limits in your product plans. For more info, take a look here: (eips.ethereum.org).

---

Sources and primary specs

• EIP‑7691: This one’s all about ramping up blob throughput, plus some exciting updates from EF Pectra and the Pectra meta EIP‑7600. Check it out here.
• EIP‑7623: Here we're looking at a proposal to raise the calldata cost, along with some research notes tackling worst-case block sizes and propagation issues. You can dig into the details here.
• EIP‑4844: This EIP breaks down blob structure, size, pricing, and even rolls out the new BLOBHASH opcode. Get all the info here.
• Post‑Pectra market data: Looking for the latest insights? Check out the operational notes and market data from Galaxy Research and Etherscan here.
• PeerDAS: This one covers EIP‑7594 and the devnet specs. Read more about it here.

---