Skip to content

Update EIP-7892: Fix json example to be valid json #10022

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update EIP-7892: Fix json example to be valid json #10022

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
67 changes: 37 additions & 30 deletions EIPS/eip-7892.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,40 +60,47 @@ To ensure consistency, when a regular hardfork changes any of these parameters,
To facilitate these changes on the execution layer, each fork in the `blobSchedule` object defined in [EIP-7840](./eip-7840.md) is linked to an activation timestamp via a top-level `<fork_name>Time` field, which holds the Unix timestamp of the activation slot as a JSON number. BPO forks SHOULD be named using the convention `bpo<index>`, where `<index>` starts at `1`. Left padding is unnecessary since these labels are not subject to lexicographic sorting. Activation timestamps are required only for forks that occur **after** Prague.

```json
"blobSchedule": {
"cancun": {
"target": 3,
"max": 6,
"baseFeeUpdateFraction": 3338477
},
"prague": {
"target": 6,
"max": 9,
"baseFeeUpdateFraction": 5007716
},
"osaka": {
"target": 6,
"max": 9,
"baseFeeUpdateFraction": 5007716
},
"bpo1": {
"target": 12,
"max": 16,
"baseFeeUpdateFraction": 5007716
},
"bpo2": {
"target": 16,
"max": 24,
"baseFeeUpdateFraction": 5007716
},
},
"cancunTime": 0, // no backporting
"pragueTime": 0, // no backporting
{
"blobSchedule": {
"cancun": {
"target": 3,
"max": 6,
"baseFeeUpdateFraction": 3338477
},
"prague": {
"target": 6,
"max": 9,
"baseFeeUpdateFraction": 5007716
},
"osaka": {
"target": 6,
"max": 9,
"maxBlobsPerTx": 6,
"baseFeeUpdateFraction": 5007716
},
"bpo1": {
"target": 12,
"max": 16,
"maxBlobsPerTx": 12,
"baseFeeUpdateFraction": 5007716
},
"bpo2": {
"target": 16,
"max": 24,
"maxBlobsPerTx": 12,
"baseFeeUpdateFraction": 5007716
}
},
"cancunTime": 0,
"pragueTime": 0,
"osakaTime": 1747387400,
"bpo1Time": 1757387400,
"bpo2Time": 1767387784,
"bpo2Time": 1767387784
}
```

Since there is no backporting, the values for `cancunTime` and `pragueTime` are set to 0. It should also be noted that the other parameters and schedules above are purely illustrative. Actual values and schedules are beyond the scope of this specification.

### Consensus layer configuration

A new `BLOB_SCHEDULE` field is added to consensus layer configuration, containing a sequence of entries representing blob parameter changes **after** `ELECTRA_FORK_EPOCH`. There exists one entry per fork that changes blob parameters, whether it is a regular or a Blob-Parameter-Only fork.
Expand Down