Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

Update EIP-4844: Increase Blob Throughput #7154

Merged
merged 3 commits into from
Jun 8, 2023
Merged

Update EIP-4844: Increase Blob Throughput #7154

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
427263e
increase blob limit to 3/6
adietrichs Jun 8, 2023
ecc377a
update description to larger throughput
adietrichs Jun 8, 2023
f499a8c
Update EIPS/eip-4844.md
adietrichs Jun 8, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions EIPS/eip-4844.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ However, data sharding will still take a considerable amount of time to finish i
This EIP provides a stop-gap solution until that point by implementing the _transaction format_ that would be used in sharding,
but not actually sharding those transactions. Instead, the data from this transaction format is simply part of the beacon chain and is fully downloaded
by all consensus nodes (but can be deleted after only a relatively short delay).
Compared to full data sharding, this EIP has a reduced cap on the number of these transactions that can be included, corresponding to a target of ~0.25 MB per block and a limit of ~0.5 MB.
Compared to full data sharding, this EIP has a reduced cap on the number of these transactions that can be included, corresponding to a target of ~0.375 MB per block and a limit of ~0.75 MB.

## Specification

Expand All @@ -45,10 +45,10 @@ Compared to full data sharding, this EIP has a reduced cap on the number of thes
| `BLOB_COMMITMENT_VERSION_KZG` | `Bytes1(0x01)` |
| `POINT_EVALUATION_PRECOMPILE_ADDRESS` | `Bytes20(0x14)` |
| `POINT_EVALUATION_PRECOMPILE_GAS` | `50000` |
| `MAX_DATA_GAS_PER_BLOCK` | `2**19` |
| `TARGET_DATA_GAS_PER_BLOCK` | `2**18` |
| `MAX_DATA_GAS_PER_BLOCK` | `786432` |
| `TARGET_DATA_GAS_PER_BLOCK` | `393216` |
Comment on lines +48 to +49
Copy link
Member

@ralexstokes ralexstokes Jun 8, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

checking math:
2^18 works out to 2 blobs (4096 * 32 bytes per blob given trusted setup size)
2^19 works out to 4 blobs (max is double target)

if we increase target by 50% (to move from 2 to 3), then we in fact get the numbers proposed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

consider 3 * 2**18 and 3 * 2**17 for legibility?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could add in the third column (so after the decimal representations), I do like having the multiplier * base factor representation

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the problem is that this depends on the specific context, e.g. not obvious why it always should be base 2. or also, might be better in this specific case to always use factor * 2**17 (so that factor would be the number of blobs)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you go with partially calculated values, here another option (clearer imho):
3 * DATA_GAS_PER_BLOB
6 * DATA_GAS_PER_BLOB

| `MIN_DATA_GASPRICE` | `1` |
| `DATA_GASPRICE_UPDATE_FRACTION` | `2225652` |
| `DATA_GASPRICE_UPDATE_FRACTION` | `3338477` |
adietrichs marked this conversation as resolved.
Show resolved Hide resolved
| `MAX_VERSIONED_HASHES_LIST_SIZE` | `2**24` |
| `MAX_CALLDATA_SIZE` | `2**24` |
| `MAX_ACCESS_LIST_SIZE` | `2**24` |
Expand Down Expand Up @@ -323,7 +323,7 @@ Instead, those transactions are only announced using `NewPooledTransactionHashes
### On the path to sharding

This EIP introduces blob transactions in the same format in which they are expected to exist in the final sharding specification.
This provides a temporary but significant scaling relief for rollups by allowing them to initially scale to 0.25 MB per slot,
This provides a temporary but significant scaling relief for rollups by allowing them to initially scale to 0.375 MB per slot,
with a separate fee market allowing fees to be very low while usage of this system is limited.

The core goal of rollup scaling stopgaps is to provide temporary scaling relief,
Expand Down Expand Up @@ -427,9 +427,9 @@ TBD

## Security Considerations

This EIP increases the storage requirements per Beacon block by a maximum of ~0.5 MB.
This is 4x larger than the theoretical maximum size of a block today (30M gas / 16 gas per calldata byte = 1.875M bytes), and so it will not greatly increase worst-case bandwidth.
Post-merge, block times are expected to be static rather than an unpredictable Poisson distribution, giving a guaranteed period of time for large blocks to propagate.
This EIP increases the bandwidth requirements per beacon block by a maximum of ~0.75 MB.
This is 40% larger than the theoretical maximum size of a block today (30M gas / 16 gas per calldata byte = 1.875M bytes), and so it will not greatly increase worst-case bandwidth.
Post-merge, block times are static rather than an unpredictable Poisson distribution, giving a guaranteed period of time for large blocks to propagate.

The _sustained_ load of this EIP is much lower than alternatives that reduce calldata costs, even if the calldata is limited,
because there is no existing software that stores the blobs indefinitely and there is no expectation that they need to be stored for as long as an execution payload.
Expand Down