From 2c9c70d37f27601f7137e51e52fa680f1753bcca Mon Sep 17 00:00:00 2001 From: Philipp Gackstatter Date: Tue, 31 Oct 2023 13:40:40 +0100 Subject: [PATCH] Update Block ID & Sig calculation --- tips/TIP-0046/tip-0046.md | 46 +++++++++++++++++++-------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/tips/TIP-0046/tip-0046.md b/tips/TIP-0046/tip-0046.md index f2194c234..247a16dd6 100644 --- a/tips/TIP-0046/tip-0046.md +++ b/tips/TIP-0046/tip-0046.md @@ -50,22 +50,6 @@ Data types and subschemas used throughout this TIP are defined in [TIP-21](../TI This TIP uses the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash function. -## Block ID - -A Block ID denotes an identifier of a block, with type `ByteArray[36]`. It is created from three separately spelled out -fields due to commitment proof requirements to keep attestation proofs lightweight. It is calculated with the following -steps: - -- Let `Block Header Hash` be the BLAKE2b-256 hash over the serialized block header. -- Let `Block Hash` be the BLAKE2b-256 hash over the serialized content of the _Block_ field. -- Let `Serialized Signature` be the serialized _Signature_. -- Let `ID` be the BLAKE2b-256 hash of the concatenation of `Block Header Hash`, `Block Hash` and `Serialized Signature`. -- Let `Slot Index` be the slot index of the `Issuing Time` of the block. -- Let `Serialized Slot Index` be the little-endian serialized `Slot Index`. -- Let `Block ID` be the concatenation of `ID` and `Serialized Slot Index`. - -The string format of the Block ID is the hexadecimal encoding of the `Block ID` with a `0x` prefix. - ## Work Score The Work Score expresses the cost of an object in terms of computational requirements for a node to process it. It @@ -173,9 +157,9 @@ The [_Ed25519 Signature_](../TIP-0038/tip-0038.md#ed25519-signature) is supporte The _Signature_ field over the block is computed as follows: -- Let `Block Header Hash` be the BLAKE2b-256 hash over the serialized block header. -- Let `Block Hash` be the BLAKE2b-256 hash over the serialized content of the _Block_ field. -- Let `Signing Input` be the concatenation of `Block Header Hash` and `Block Hash`. +- Let `Header Hash` be the BLAKE2b-256 hash over the serialized `Header`. +- Let `Body Hash` be the BLAKE2b-256 hash over the serialized content of the `Body` field. +- Let `Signing Input` be the concatenation of `Header Hash` and `Body Hash`. - Let the resulting signature be the Ed25519 signature of `Signing Input`. ### Semantic Validation @@ -290,6 +274,22 @@ The schema of a block is as follows: +## Block ID + +A Block ID denotes an identifier of a block, with type `ByteArray[36]`. It is created from three separately spelled out +fields due to commitment proof requirements to keep attestation proofs lightweight. It is calculated with the following +steps: + +- Let `Header Hash` be the BLAKE2b-256 hash over the serialized `Header`. +- Let `Body Hash` be the BLAKE2b-256 hash over the serialized content of the `Body` field. +- Let `Serialized Signature` be the serialized `Signature`. +- Let `ID` be the BLAKE2b-256 hash of the concatenation of `Header Hash`, `Body Hash` and `Serialized Signature`. +- Let `Slot Index` be the slot index of the `Issuing Time` of the block. +- Let `Serialized Slot Index` be the little-endian serialized `Slot Index`. +- Let `Block ID` be the concatenation of `ID` and `Serialized Slot Index`. + +The string format of the Block ID is the hexadecimal encoding of the `Block ID` with a `0x` prefix. + ## Basic Block ### Schema @@ -557,15 +557,15 @@ The work score of a _Validation Block_ is `0`. **Block ID & Signature** -Splitting the signing input of a Block Signature into a header and block part allows for verification of an attestation -where only the header and block hash are known. In a similar way, a Block ID can be recomputed from an attestation +Splitting the signing input of a Block Signature into a header and body part allows for verification of an attestation +where only the header and body hash are known. In a similar way, a Block ID can be recomputed from an attestation without having the entire block. **Validation Block** The alternative could be to use a `Block` instead of `Validation Block` with some additional validation logic. However, -having a separate block type for validator related responsibilities is much cleaner and allows for additional changes -like allowing to reference more parents, or having specific payload types or fields in the future. +having a separate block body type for validator related responsibilities is much cleaner and allows for additional +changes like allowing to reference more parents, or having specific payload types or fields in the future. **Burned Mana**