From d2e558c7e47ae85cbc46d592c732b4bf19385d52 Mon Sep 17 00:00:00 2001 From: "lightclient@protonmail.com" Date: Tue, 16 Aug 2022 22:03:37 -0600 Subject: [PATCH] update again --- EIPS/eip-4844.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-4844.md b/EIPS/eip-4844.md index 1f477ef08abaa1..f108b9beb54c05 100644 --- a/EIPS/eip-4844.md +++ b/EIPS/eip-4844.md @@ -49,7 +49,7 @@ Compared to full data sharding, this EIP has a reduced cap on the number of thes | `POINT_EVALUATION_PRECOMPILE_ADDRESS` | `Bytes20(0x14)` | | `POINT_EVALUATION_PRECOMPILE_GAS` | `50000` | | `MAX_BLOBS_PER_BLOCK` | `16` | -| `TARGET_BLOB_TXS_PER_BLOCK` | `8` | +| `TARGET_BLOBS_PER_BLOCK` | `8` | | `MAX_BLOBS_PER_TX` | `2` | | `GASPRICE_UPDATE_FRACTION_PER_BLOB` | `64` | | `MAX_VERSIONED_HASHES_LIST_SIZE` | `2**24` | @@ -264,7 +264,7 @@ The value of `blob_txs` can be calculated using the parent header and number of ```python def calc_excess_blob_txs(parent: Header, blobs: int) -> int: adjusted = parent.blob_txs + blobs - return adjusted - min(TARGET_BLOB_TXS_PER_BLOCK, adjusted) + return adjusted - min(TARGET_BLOBS_PER_BLOCK, adjusted) ``` ### Beacon chain validation @@ -342,7 +342,7 @@ def get_intrinsic_gas(tx: SignedBlobTransaction, pre_state: ExecState) -> int: def get_blob_gas(header: Header) -> int: blocks_since_start = get_current_block(pre_state) - FORK_BLKNUM - targeted_total = blocks_since_start * TARGET_BLOB_TXS_PER_BLOCK + targeted_total = blocks_since_start * TARGET_BLOBS_PER_BLOCK actual_total = targeted_total + header.blob_txs if actual_total < targeted_total: return 0 @@ -500,12 +500,12 @@ sequencers would simply have to switch over to using a new transaction type at t ### Blob gasprice update rule The blob gasprice update rule is intended to approximate the formula `blob_gas = 2**(excess_blobs / GASPRICE_UPDATE_FRACTION_PER_BLOB)`, -where `excess_blobs` is the total "extra" number of blobs that the chain has accepted relative to the "targeted" number (`TARGET_BLOB_TXS_PER_BLOCK` per block). +where `excess_blobs` is the total "extra" number of blobs that the chain has accepted relative to the "targeted" number (`TARGET_BLOBS_PER_BLOCK` per block). Like EIP-1559, it's a self-correcting formula: as the excess goes higher, the `blob_gas` increases exponentially, reducing usage and eventually forcing the excess back down. The block-by-block behavior is roughly as follows. -If in block `N`, `blob_gas = G1`, and block `N` has `X` blobs, then in block `N+1`, `excess_blobs` increases by `X - TARGET_BLOB_TXS_PER_BLOCK`, -and so the `blob_gas` of block `N+1` increases by a factor of `2**((X - TARGET_BLOB_TXS_PER_BLOCK) / GASPRICE_UPDATE_FRACTION_PER_BLOB)`. +If in block `N`, `blob_gas = G1`, and block `N` has `X` blobs, then in block `N+1`, `excess_blobs` increases by `X - TARGET_BLOBS_PER_BLOCK`, +and so the `blob_gas` of block `N+1` increases by a factor of `2**((X - TARGET_BLOBS_PER_BLOCK) / GASPRICE_UPDATE_FRACTION_PER_BLOB)`. Hence, it has a similar effect to the existing EIP-1559, but is more "stable" in the sense that it responds in the same way to the same total usage regardless of how it's distributed. ## Backwards Compatibility