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.

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-225 Clique Spec Improvements #3426

Merged
Prev Previous commit
Next Next commit
eip-225: added ascending-byte-order note to extraData signer section …
…description to avoid ascending-time-order confusion
  • Loading branch information
holgerd77 committed Mar 24, 2021
commit dc81fa9e150183732af62eec5ed3438f19ecce0e
4 changes: 2 additions & 2 deletions EIPS/eip-225.md
Original file line number Diff line number Diff line change
@@ -131,7 +131,7 @@ We repurpose the `ethash` header fields as follows:
* First **`EXTRA_VANITY`** bytes (fixed) may contain arbitrary signer vanity data.
* Last **`EXTRA_SEAL`** bytes (fixed) is the signer's signature sealing the header.
* Checkpoint blocks **must** contain a list of signers (`N*20 bytes`) in between, **omitted** otherwise.
* The list of signers in checkpoint block extra-data sections **must** be sorted in ascending order.
* The list of signers in checkpoint block extra-data sections **must** be sorted in ascending byte order.
* **`mixHash`**: Reserved for fork protection logic, similar to the extra-data during the DAO.
* **Must** be filled with zeroes during normal operation.
* **`ommersHash`**: **Must** be **`UNCLE_HASH`** as uncles are meaningless outside of PoW.
@@ -142,7 +142,7 @@ We repurpose the `ethash` header fields as follows:

### Authorizing a block

To authorize a block for the network, the signer needs to sign the block's hash containing **everything except the signature itself**. The means that the hash contains every field of the header (`nonce` and `mixDigest` included), and also the `extraData` with the exception of the 65 byte signature suffix. The fields are hashed in the order of their definition in the yellow paper.
To authorize a block for the network, the signer needs to sign the block's hash containing **everything except the signature itself**. This means that the hash contains every field of the header (`nonce` and `mixDigest` included), and also the `extraData` with the exception of the 65 byte signature suffix. The fields are hashed in the order of their definition in the yellow paper.

This hash is signed using the standard `secp256k1` curve, and the resulting 65 byte signature (`R`, `S`, `V`, where `V` is `0` or `1`) is embedded into the `extraData` as the trailing 65 byte suffix.