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

[EIP-4844] Reduce Throughput #5863

Merged
merged 2 commits into from
Nov 14, 2022
Merged

[EIP-4844] Reduce Throughput #5863

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
963ad87
set lower target/max
adietrichs Nov 1, 2022
0612ba2
add throughput rationale
adietrichs Nov 1, 2022
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
18 changes: 11 additions & 7 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 ~1 MB per block and a limit of ~2 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.25 MB per block and a limit of ~0.5 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**21` |
| `TARGET_DATA_GAS_PER_BLOCK` | `2**20` |
| `MAX_DATA_GAS_PER_BLOCK` | `2**19` |
| `TARGET_DATA_GAS_PER_BLOCK` | `2**18` |
| `MIN_DATA_GASPRICE` | `1` |
| `DATA_GASPRICE_UPDATE_FRACTION` | `8902606` |
| `DATA_GASPRICE_UPDATE_FRACTION` | `2225652` |
| `MAX_VERSIONED_HASHES_LIST_SIZE` | `2**24` |
| `MAX_CALLDATA_SIZE` | `2**24` |
| `MAX_ACCESS_LIST_SIZE` | `2**24` |
Expand Down Expand Up @@ -368,7 +368,7 @@ def validate_blob_transaction_wrapper(wrapper: BlobTransactionNetworkWrapper):
### 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 scale to 2 MB per slot,
This provides a temporary but significant scaling relief for rollups by allowing them to initially scale to 0.25 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 @@ -444,6 +444,10 @@ Hence, it has a similar effect to the existing EIP-1559, but is more "stable" in

The parameter `DATA_GASPRICE_UPDATE_FRACTION` controls the maximum rate of change of the blob gas price. It is chosen to target a maximum change rate of `e(TARGET_DATA_GAS_PER_BLOCK / DATA_GASPRICE_UPDATE_FRACTION) ≈ 1.125` per block.

### Throughput

The values for `TARGET_DATA_GAS_PER_BLOCK` and `MAX_DATA_GAS_PER_BLOCK` are chosen to correspond to a target of 2 blobs (0.25 MB) and maximum of 4 blobs (0.5 MB) per block. These small initial limits are intended to minimize the strain on the network created by this EIP and are expected to be increased in future upgrades as the network demonstrates reliability under larger blocks.

## Backwards Compatibility

### Blob non-accessibility
Expand All @@ -468,8 +472,8 @@ TBD

## Security Considerations

This EIP increases the storage requirements per Beacon block by a maximum of ~2 MB.
This is equal to 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.
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.

The _sustained_ load of this EIP is much lower than alternatives that reduce calldata costs, even if the calldata is limited,
Expand Down