diff --git a/tips/TIP-0046/tip-0046.md b/tips/TIP-0046/tip-0046.md new file mode 100644 index 000000000..9ff773d50 --- /dev/null +++ b/tips/TIP-0046/tip-0046.md @@ -0,0 +1,1018 @@ +--- +tip: 46 +title: Tangle Blocks for IOTA 2.0 +description: Defines the Basic and Validation Block of IOTA 2.0 +author: + Philipp Gackstatter (@PhilippGackstatter) , Daria Dziubałtowska (@daria305) + +discussions-to: TODO +status: Draft +type: Standards +layer: Core +replaces: 24 +created: 2023-05-16 +--- + +# Summary + +The Tangle is the graph data structure behind IOTA. For the Stardust upgrade an additional abstraction layer on top of +legacy IOTA version transactions was introduced where the vertices are generalized _blocks_, which then contain the +transactions or other structures that are processed by the IOTA protocol. Just as before, each block directly approves +other blocks, which are known as _parents_. The new block structure matches the requirements introduced by the IOTA 2.0 +version of the protocol. A new type of block is introduced, the _Validation Block_. It is a special type of block that +is used by validators. Validation Blocks have additional functionality and different fields and validation rules. To +better distinguish the _Validation Block_ from the previously introduced _Block_, the latter is renamed to _Basic +Block_. A _Basic Block_ can contain different types of payloads which are processed by all nodes as part of the IOTA +protocol. Some payloads may have other nested payloads embedded inside. Hence, parsing is done layer by layer. + +# Motivation + +To better understand this layered design, consider the Internet Protocol (IP), for example: There is an Ethernet frame +that contains an IP payload. This in turn contains a TCP packet that encapsulates an HTTP payload. Each layer has a +certain responsibility and once this responsibility is completed, we move on to the next layer. + +The same is true with how blocks are parsed. The outer layer of the block enables the mapping of the block to a vertex +in the Tangle and allows us to perform some basic validation. The next layer may be a transaction that mutates the +ledger state, and one layer further may provide some extra functionality on the transactions to be used by applications. + +By making it possible to add and exchange payloads, an architecture is being created that can easily be extended to +accommodate future needs. + +# Building Blocks + +This section describes common building blocks used across multiple block types. + +## Data Types & Subschema Notation + +Data types and subschemas used throughout this TIP are defined in [TIP-21](../TIP-0021/tip-0021.md). + +## BLAKE2b Hash Function + +This TIP uses the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash function. + +## Work Score + +The Work Score expresses the cost of an object in terms of computational requirements for a node to process it. It +differs from the storage deposit in that it only accounts for one-off costs that the processing of a block and its +payload incur, while the storage deposit accounts for recurring costs like data storage or holding block issuer keys in +memory. The work score attempts to encapsulate all processing steps carried out on this object throughout its life in +the node. The calculation of the work score is done with the use of the _Work Score Parameters_ protocol parameters. The +work score is expressed as a `uint32` and all operations used in its calculation are integer arithmetic. + +## Time + +Protocol time is divided into slots and epochs. And epoch consists of 2Slots Per Epoch Exponent +slots and each slot is `Slot Duration In Seconds` seconds in length. + +### Slot Index + +Each slot has a corresponding slot index, which is a `uint32`. To calculate the slot index of a timestamp, the protocol +parameters `Genesis Slot`, `Genesis Unix Timestamp` and `Slot Duration In Seconds` are used. The slot index of a Unix +timestamp `Unix Timestamp` (in seconds) is calculated as follows: + +- Compute `Elapsed Time` as `Unix Timestamp - Genesis Unix Timestamp`. +- If `Elapsed Time < 0`, the slot index is `Genesis Slot`. +- Otherwise the slot index is `Genesis Slot + Elapsed Time/Slot Duration In Seconds + 1`. + - Note: The `+ 1` is required because slots are counted starting from `1`. `0` is reserved for times before the + genesis (if `Genesis Slot = 0`), which has to be addressable as its own slot. + +### Epoch Index + +Each epoch has a corresponding epoch index, which is a `uint32`. To calculate the epoch index of a slot index, that is, +the index of the epoch to which the slot belongs, the protocol parameter `Slots Per Epoch Exponent` is used. The epoch +index of a slot index `Slot Index` is calculated as follows: + +- If `Slot Index <= Genesis Slot` then the epoch index is `0`. +- Otherwise the epoch index is `(Slot Index - Genesis Slot) >> Slots Per Epoch Exponent)`, where `>>` is the _zero-fill + right-shift_ or _logical shift_ operation. + +## Slot Commitment + +A Slot Commitment contains a summary of a slot. The Slot Commitment is serialized as follows: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Versionuint8 + The version of the protocol in which this commitment was created. +
Indexuint32 + The slot index. +
Prev IDByteArray[36]The slot identifier of the previous slot in the chain.
Roots IDByteArray[32]The Merkle Tree Root of all commitment elements.
Cumulative Weightuint64The weight of the chain of the Index minus Maximum Committable Age slots in the past. This value is required for attestations and is used by node in chain switching mechanism.
RMCuint64This field provides the Reference Mana Cost (RMC) to be used for Mana burn calculations for blocks that included this commitment. Each new RMC value for a slot with index i is calculated upon commitment based on the RMC from slot i - 1 and the total work score of blocks in slot i. It is convenient to store the RMC in the commitment to avoid having to recalculate it from genesis when syncing. +
+ +### Slot Commitment ID + +A Slot Commitment ID denotes an identifier of a slot commitment, with type `ByteArray[36]`. It is calculated with the +following steps: + +- Let `Content` be the serialized slot commitment. +- Let `Content Hash` be the BLAKE2b-256 hash of `Content`. +- Let `Slot Index` be the slot index of the slot commitment. +- Let `Serialized Slot Index` be the little-endian serialized `Slot Index`. +- Let `Commitment ID` be the concatenation of `Content Hash` and `Slot Index`. + +The string format of a Slot Commitment ID is the hexadecimal encoding of the Slot Commitment ID with `0x` prefix. + +### Semantic Validation + +- The `Index` of the commitment must be in the closed interval + `[Block Slot - Max Committable Age, Block Slot - Min Committable Age]`, where `Block Slot` is the slot index + corresponding to the `Issuing Time` of the block containing the commitment. + +## Block Signature + +The [_Ed25519 Signature_](https://github.com/iotaledger/tips/blob/tip38/tips/TIP-0038/tip-0038.md#ed25519-signature) is +supported. + +### Signature Creation + +The _Signature_ field over the block is computed as follows: + +- 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 + +In order for the signature to be valid all of the following conditions must hold: + +- The `Public Key` must verify the `Signature`, according to [TIP-14](../TIP-0014/tip-0014.md). +- The `Public Key` must be included as a _Block Issuer Key_ in the Account identified by the block's `Issuer ID` field. + This check is executed against the account state at the slot index corresponding to the slot commitment of the block. + +# Block + +A block consists of a header, body and a signature. The body defines the concrete flavor of a block. + +The schema of a block is as follows: + +
+ Block +
The block consisting of a header, body and signature.
+
+ + + + + + + + + + + + + + + + + + +
+ Name + + Type + + Description +
Header +
+ Block Header +
The common header fields of a block.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Name + + Type + + Description +
Protocol Versionuint8This field denotes what protocol rules apply to the block.
Network IDuint64Network identifier. Usually, it will be set to the first 8 bytes of the BLAKE2b-256 hash of the concatenation of the network type and the protocol version string.
Issuing Timeuint64The time at which the block was issued. It is a Unix timestamp in nanoseconds.
Slot Commitment IDByteArray[36]The identifier of the slot this block commits to. More details in the Slot Commitment ID section.
Latest Finalized Slotuint32The slot index of the latest finalized slot.
Issuer IDByteArray[32]The identifier of the account that issued this block.
+
+
Body oneOf +
+ Basic Block Body +
The basic block body. Defined in TIP-46 (Basic Block).
+
+
+ Validation Block Body +
The validation block body. Defined in TIP-46 (Validation Block).
+
+
Signature oneOf +
+ Ed25519 Signature +
An Ed25519 Signature with the public key that verifies it. Defined in TIP-38 (Ed25519 Signature).
+
+
+ +## 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. + +## Syntactic validation + +The Tangle can only contain syntactically valid blocks. Invalid blocks must be rejected by the node. A Block is +syntactically valid only if all of the following conditions hold: + +- The serialized size of the block does not exceed `32768`. +- The `Protocol Version` in the `Header` matches the `Version` in the used protocol parameters. +- The `Network ID` in the `Header` matches the `Network ID` from the protocol parameters, which is computed as described + in [TIP-45 (Network ID)](../TIP-0045/tip-0045.md#network-id). +- Let `Commitment Slot` be the slot index to which the block commits, which can be extracted from the header's + `Slot Commitment ID`. +- Let `Block Slot` be the slot index corresponding to the block header's `Issuing Time`. +- If `Commitment Slot > Genesis Slot`, then it must hold that `Commitment Slot + Min Committable Age <= Block Slot`. + - Note: This ensures that the commitment is not too recent, except when committing to genesis. +- It must hold that `Commitment Slot + Max Committable Age >= Block Slot`. + - Note: This ensures that the commitment is not too old. +- The contained `Body` is syntactically valid. +- There must be no trailing bytes after all block fields have been parsed. + +## Semantic Validation + +A _Block_ is semantically valid if the `Body`'s semantic validation passes. + +## Basic Block + +### Schema + +A _Basic Block_ is the name for a _Block_ with its body set to a _Basic Block Body_, which is defined as: + +
+ Basic Block Body +
The basic block body.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Name + + Type + + Description +
Block Body Typeuint8Set to value 0 to denote a Basic Block Body.
Strong Parents Countuint8The number of blocks following, which are strongly directly approved.
Strong Parents anyOf +
+ Parent +
A reference to a block.
+ + + + + + + + + + + +
+ Name + + Type + + Description +
Block IDByteArray[36]The Block ID of the parent.
+
+
Weak Parents Countuint8The number of blocks following, which are weakly directly approved.
Weak Parents optAnyOf +
+ Parent +
A reference to a block.
+ + + + + + + + + + + +
+ Name + + Type + + Description +
Block IDByteArray[36]The Block ID of the parent.
+
+
Shallow Like Parents Countuint8The number of blocks following, which are directly referenced to adjust opinion.
Shallow Like Parents optAnyOf +
+ Parent +
A reference to a block.
+ + + + + + + + + + + +
+ Name + + Type + + Description +
Block IDByteArray[36]The Block ID of the parent.
+
+
Payload Lengthuint32The length of the following payload in bytes. A length of 0 means no payload will be attached.
Payload optOneOf +
+ Signed Transaction +
A transaction with its unlocks. Defined in TIP-45 (Signed Transaction).
+
+
+ Tagged Data +
Optional Data with an optional Tag. Defined in TIP-53 (Tagged Data).
+
+
+ Candidacy Announcement +
Signals candidacy for committee selection for the epoch after the one in which it is issued. Defined in TIP-40 (Candidacy Announcement).
+
+
Max Burned Manauint64The amount of Mana the Account identified by Issuer ID is at most willing to burn for this block. The actual Mana deducted from this Account's Block Issuance Credit may be lower than the value of this field which is the product of the basic block's work score and the RMC (Reference Mana Cost) from the block's slot commitment, identified by the Slot Commitment ID. Therefore, for the calculation of this field, the block issuer should use the RMC value from the same commitment.
+ +### Syntactic validation + +A _Basic Block Body_ is only syntactically valid if all of the following conditions hold: + +- The block adheres to its schema with the rules defined in [TIP-21](../TIP-0021/tip-0021.md). +- It must hold true that 1 ≤ `Strong Parents Count` ≤ 8. +- It must hold true that 0 ≤ `Weak Parents Count` ≤ 8. +- It must hold true that 0 ≤ `Shallow Like Parents Count` ≤ 8. +- `Strong Parents`, `Weak Parents`, `Shallow Like Parents` must comply with the following rules: + - must be lexically ordered. + - must not have duplicates in each list. +- `Weak Parents` must be disjoint from the rest of the parents: No weak parent should be in either `Strong Parents` or + `Shallow Like Parents`. +- If a _Basic Block_ contains a transaction payload, the block is valid only if all of the following conditions hold: + - The Slot Index `Block Slot` corresponding to the `Issuing Time` of a block must be greater or equal than the + `Creation Slot` of the contained transaction. + - If the transaction includes a `Commitment Input`, then the `Slot Index` from the contained `Commitment ID`: + - must be in the closed interval `[Block Slot - Max Committable Age, Block Slot - Min Committable Age]`. + - must not exceed the `Slot Index` field of the `Slot Commitment ID` from the block's `Header`. + +### Semantic Validation + +A _Basic Block Body_ is semantically valid if the following condition holds: + +- The `Signature` must pass semantic validation. + +### Payloads + +While blocks without a payload, i.e. `Payload Length` set to zero, are valid, such blocks do not contain any +information. As such, blocks usually contain a payload. The detailed specification of each payload type is out of scope +of this TIP. The following table lists all currently specified payloads that can be part of a block and links to their +specification: + +| Payload Name | Type Value | TIP | +| ---------------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------- | +| No Payload | - | - | +| Tagged Data | 0 | [TIP-53](https://github.com/iotaledger/tips/blob/tip53/tips/TIP-0053/tip-0053.md) | +| Transaction | 1 | [TIP-45](https://github.com/iotaledger/tips/blob/tip45/tips/TIP-0045/tip-0045.md) | +| Candidacy Announcement | 2 | [TIP-40 (Candidacy Announcement)](https://github.com/iotaledger/tips/blob/tip40/tips/TIP-0040/tip-0040.md#candidacy-announcement) | + +### Work Score + +Let the work score of a _Basic Block_ be defined as follows. + +- Let `Payload Score` be the work score of the contained `Payload` if it exists, or `0` if it does not exist. + - If the type is _Tagged Data_ the work score is `Work Score Parameters::Data Byte * Tagged Data Size` where: + - `Tagged Data Size` is the size of the serialized _Tagged Data_. + - If the type is _Candidacy Announcement_ the work score is + `Work Score Parameters::Data Byte * Candidacy Announcement Size` where: + - `Candidacy Announcement Size` is the size of the serialized _Candidacy Announcement_. + - If the type is _Transaction_ the work score is defined in + [TIP-45 (Work Score)](https://github.com/iotaledger/tips/blob/tip45/tips/TIP-0045/tip-0045.md#work-score). +- Return `Work Score Parameters::Block + Payload Score`. + +## Validation Block + +A Validation Block is a type of block used by validators to secure the network. It is recognised by the Congestion +Control of the IOTA 2.0 protocol and can be issued without burning Mana within the constraints of the allowed validator +throughput. It is allowed to reference more parent blocks than a _Basic Block_. + +### Schema + +A _Validation Block_ is the name for a _Block_ with its body set to a _Validation Block Body_, which is defined as: + +
+ Validation Block Body +
The validation block body.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Name + + Type + + Description +
Block Body Typeuint8Set to value 1 to denote a Validation Block Body.
Strong Parents Countuint8The number of blocks following, which are strongly directly approved.
Strong Parents anyOf +
+ Parent +
A reference to a block.
+ + + + + + + + + + + +
+ Name + + Type + + Description +
Block IDByteArray[36]The Block ID of the parent.
+
+
Weak Parents Countuint8The number of blocks following, which are weakly directly approved.
Weak Parents optAnyOf +
+ Parent +
A reference to a block.
+ + + + + + + + + + + +
+ Name + + Type + + Description +
Block IDByteArray[36]The Block ID of the parent.
+
+
Shallow Like Parents Countuint8The number of blocks following, which are directly referenced to adjust opinion.
Shallow Like Parents optAnyOf +
+ Parent +
A reference to a block.
+ + + + + + + + + + + +
+ Name + + Type + + Description +
Block IDByteArray[36]The Block ID of the parent.
+
+
Highest Supported Versionuint8The highest supported protocol version the issuer of this block supports.
Protocol Parameters HashByteArray[32]The hash of the protocol parameters for the Highest Supported Version.
+ +### Syntactic Validation + +A _Validation Block Body_ is only syntactically valid if all of the following conditions hold: + +- The block adheres to its schema with the rules defined in [TIP-21](../TIP-0021/tip-0021.md). +- It must hold true that 1 ≤ `Strong Parents Count` ≤ 50. +- It must hold true that 0 ≤ `Weak Parents Count` ≤ 50. +- It must hold true that 0 ≤ `Shallow Like Parents Count` ≤ 50. +- `Strong Parents`, `Weak Parents`, `Shallow Like Parents` must comply with the following rules: + - must be lexically ordered. + - must not have duplicates in each list. +- `Weak Parents` must be disjoint from the rest of the parents: No weak parent should be in either `Strong Parents` or + `Shallow Like Parents`. +- `Highest Supported Version` must be greater or equal to `Protocol Version`. + +### Semantic Validation + +A _Validation Block Body_ is semantically valid if the following condition holds: + +- The `Signature` must pass semantic validation. + +## Work Score + +The work score of a _Validation Block_ is `0`. + +# Rationale and alternatives + +**Block ID & Signature** + +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 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** + +The rationale for including the `Max Burned Mana` field on the block is the following. For a given block, the account +identified by the `Issuer ID` field on the block needs to burn the amount of Mana corresponding to the RMC and the block +size. A malicious node might provide a false, lower RMC value. If the field was not present, the required Mana would be +deducted from the account's Block Issuance Credit (BIC), but the account would not allot enough Mana in the containing +transaction, since it assumed a lower RMC value. This would result in a negative BIC balance and the locking of the +account. The `Max Burned Mana` field prevents this situation by effectively stating the assumption under which the +account operates. If `Max Burned Mana` is lower than it should be, the block can simply be dropped without incurring a +cost for the issuing account. Thus, as long as `Max Burned Mana` matches the amount allotted in the contained +transaction, the transaction will never result in the locking of the account. + +# Test Vectors + +The protocol parameters used in the following test vectors are the same as in +[TIP-49](https://github.com/iotaledger/tips/blob/tip49/tips/TIP-0049/tip-0049.md#protocol-parameters-hash). + +## Slot Commitment ID + +Slot Commitment (json-encoded): + +```json +{ + "protocolVersion": 3, + "slot": 18, + "previousCommitmentId": "0x5f400a6621684e7b260f353b3937113c153c387c5c2f7110463a2f1b2f1c392a581e192d", + "rootsId": "0x533543553e75065c0c115c220624400b02693c6177284b4f1b7748610c515968", + "cumulativeWeight": "89", + "referenceManaCost": "144" +} +``` + +Slot Commitment (hex-encoded binary serialization): + +``` +0x03120000005f400a6621684e7b260f353b3937113c153c387c5c2f7110463a2f1b2f1c392a581e192d533543553e75065c0c115c220624400b02693c6177284b4f1b7748610c51596859000000000000009000000000000000 +``` + +Slot Commitment ID: + +``` +0xb4d22598e6ed4a4405c5f3199ab260ac5c718e8c63a93773fabeff155add895312000000 +``` + +## Basic Block ID & Work Score (Tagged Data payload) + +Block (json-encoded): + +```json +{ + "header": { + "protocolVersion": 3, + "networkId": "8342982141227064571", + "issuingTime": "1695275942000000000", + "slotCommitmentId": "0x3a1e3b617060146e0362361a4b752833186108395f3b2b3d3e6c655e287d707601000000", + "latestFinalizedSlot": 0, + "issuerId": "0x17432c5a7a672503480241125e3952414a7a320441080c624c264b004e09614a" + }, + "body": { + "type": 0, + "strongParents": [ + "0x27e0461873f37040c9e59c35ad8a106fa1b94f5ec9ef89499b31904f9a3de59be58dd44a", + "0x714821f8f257e0a502b71ac7ee57530bb9dc29fe12ff3936f925b835a297680400b76948", + "0x9951e512546cd9c9fbdab348b6cba91a601a29b50854e55a6e14f6803ca1d81ac7eff5ce", + "0xaaa7bacf26f1aa4754d42edeab45d6169ea723b7fdf0f6ff3b6ebe90d09dbff6bc553936", + "0xba75a143de4ac932986fbe7b1d78f639bc6ee8aee10d510d41572851530be884778052aa", + "0xea5315941f4337752905599710b55e64018c71f4d8f299d0636d50484d05e6ac5667b503" + ], + "payload": { + "type": 0, + "tag": "0x746167", + "data": "0x6c754128356c071e5549764a48427b" + }, + "maxBurnedMana": "26" + }, + "signature": { + "type": 0, + "publicKey": "0x2daefbcbadd044da470acd2f7fcf6fcb04b873cc801e7ee408018e1dfa0257ac", + "signature": "0xdf2d3b9e1dcd59030eb816fabef7c4368e83b49bae384393370ace84df2b57533c79c5c374acb5ca64c413d4bf396fbebe67ab3c6e0909b1c5878cd79672b80c" + } +} +``` + +Block (hex-encoded binary serialization): + +``` +0x03fb5c44ef0d3ac87300fc2cbf7cd486173a1e3b617060146e0362361a4b752833186108395f3b2b3d3e6c655e287d7076010000000000000017432c5a7a672503480241125e3952414a7a320441080c624c264b004e09614a000627e0461873f37040c9e59c35ad8a106fa1b94f5ec9ef89499b31904f9a3de59be58dd44a714821f8f257e0a502b71ac7ee57530bb9dc29fe12ff3936f925b835a297680400b769489951e512546cd9c9fbdab348b6cba91a601a29b50854e55a6e14f6803ca1d81ac7eff5ceaaa7bacf26f1aa4754d42edeab45d6169ea723b7fdf0f6ff3b6ebe90d09dbff6bc553936ba75a143de4ac932986fbe7b1d78f639bc6ee8aee10d510d41572851530be884778052aaea5315941f4337752905599710b55e64018c71f4d8f299d0636d50484d05e6ac5667b50300001800000000037461670f0000006c754128356c071e5549764a48427b1a00000000000000002daefbcbadd044da470acd2f7fcf6fcb04b873cc801e7ee408018e1dfa0257acdf2d3b9e1dcd59030eb816fabef7c4368e83b49bae384393370ace84df2b57533c79c5c374acb5ca64c413d4bf396fbebe67ab3c6e0909b1c5878cd79672b80c +``` + +Block ID: + +``` +0xc7f9a14e1b5bbbb31810e2cb064ab2dbd87cab22696c5ee1297f333e0635e91e0d000000 +``` + +Block Work Score: `26`. + +## Basic Block ID & Work Score (Transaction Payload) + +Block (json-encoded): + +```json +{ + "header": { + "protocolVersion": 3, + "networkId": "8342982141227064571", + "issuingTime": "1695275942000000000", + "slotCommitmentId": "0x3a1e3b617060146e0362361a4b752833186108395f3b2b3d3e6c655e287d707601000000", + "latestFinalizedSlot": 0, + "issuerId": "0x17432c5a7a672503480241125e3952414a7a320441080c624c264b004e09614a" + }, + "body": { + "type": 0, + "strongParents": [ + "0x27e0461873f37040c9e59c35ad8a106fa1b94f5ec9ef89499b31904f9a3de59be58dd44a", + "0x714821f8f257e0a502b71ac7ee57530bb9dc29fe12ff3936f925b835a297680400b76948", + "0x9951e512546cd9c9fbdab348b6cba91a601a29b50854e55a6e14f6803ca1d81ac7eff5ce", + "0xaaa7bacf26f1aa4754d42edeab45d6169ea723b7fdf0f6ff3b6ebe90d09dbff6bc553936", + "0xba75a143de4ac932986fbe7b1d78f639bc6ee8aee10d510d41572851530be884778052aa", + "0xea5315941f4337752905599710b55e64018c71f4d8f299d0636d50484d05e6ac5667b503" + ], + "payload": { + "type": 1, + "transaction": { + "networkId": "8342982141227064571", + "creationSlot": 11, + "contextInputs": [ + { + "type": 0, + "commitmentId": "0x3a1e3b617060146e0362361a4b752833186108395f3b2b3d3e6c655e287d707601000000" + }, + { + "type": 1, + "accountId": "0x17432c5a7a672503480241125e3952414a7a320441080c624c264b004e09614a" + }, + { + "type": 2, + "index": 0 + } + ], + "inputs": [ + { + "type": 0, + "transactionId": "0xf09d3cd648a7246c7c1b2ba2f9182465ae5742b78c592392b4b455ab8ed7195200000000", + "transactionOutputIndex": 0 + }, + { + "type": 0, + "transactionId": "0xd2c5ccba12b6fad51652131289867492799c9fc5710244418aa6e955f8fa826100000000", + "transactionOutputIndex": 0 + } + ], + "allotments": [ + { + "accountId": "0x476820096e7038107d071a4e473f1e295f346e2d0824263e5e3e7d004f6b6915", + "mana": "2189" + }, + { + "accountId": "0x7e0d0a5848362b23120f55115b096774036d7610137a631413221f5573344507", + "mana": "2285" + } + ], + "capabilities": "0x01", + "outputs": [ + { + "type": 0, + "amount": "100000", + "mana": "0", + "unlockConditions": [ + { + "type": 0, + "address": { + "type": 0, + "pubKeyHash": "0xed1484f4d1f7d8c037087fed661dd92faccae1eed3c01182d6fdd6828cea144a" + } + } + ], + "features": [ + { + "type": 5, + "id": "0x086372557616532f714f104e5f44297b7a286d077956291a6d4f59081f484463712a64300c00", + "amount": "0x14be8149371263f4" + } + ] + }, + { + "type": 1, + "amount": "100000", + "mana": "5000", + "accountId": "0x0000000000000000000000000000000000000000000000000000000000000000", + "foundryCounter": 0, + "unlockConditions": [ + { + "type": 0, + "address": { + "type": 0, + "pubKeyHash": "0xed1484f4d1f7d8c037087fed661dd92faccae1eed3c01182d6fdd6828cea144a" + } + } + ], + "features": [ + { + "type": 2, + "entries": { + "hello": "0x776f726c64" + } + }, + { + "type": 6, + "expirySlot": 4294967295, + "blockIssuerKeys": [ + { + "type": 0, + "pubKeyHash": "0x295409de79016133647d4078cb01618a4ba018eb74ff613138d8ff8dc05de73c" + }, + { + "type": 0, + "pubKeyHash": "0x868f4c6ef7b5b1d55838cbfb8ae4f3a9776c53cdd3e3d33000094d72acab5a2f" + } + ] + }, + { + "type": 7, + "stakedAmount": "10000", + "fixedCost": "400", + "startEpoch": 0, + "endEpoch": 4294967295 + } + ] + } + ] + }, + "unlocks": [ + { + "type": 0, + "signature": { + "type": 0, + "publicKey": "0x2daefbcbadd044da470acd2f7fcf6fcb04b873cc801e7ee408018e1dfa0257ac", + "signature": "0x5bb409d59e01d2ea9f1a1fb67feb681d0d3ecb05787cadad2f89fdf13ef7ff03ad5cebf28df5dddd8510992596d98b133f86e14f76824e6ccc369a8f5df44806" + } + }, + { + "type": 1, + "reference": 0 + } + ] + }, + "maxBurnedMana": "766" + }, + "signature": { + "type": 0, + "publicKey": "0x2daefbcbadd044da470acd2f7fcf6fcb04b873cc801e7ee408018e1dfa0257ac", + "signature": "0x3b70bc23b955b710bc131b57696e4a16ca0d4d8601ca2de126e68eeeefa310ef0d7a8668365dddee2a1376630f8564f2190bd89ed2b2ffd061a20ad2bc47ea0b" + } +} +``` + +Block (hex-encoded binary serialization): + +``` +0x03fb5c44ef0d3ac87300fc2cbf7cd486173a1e3b617060146e0362361a4b752833186108395f3b2b3d3e6c655e287d7076010000000000000017432c5a7a672503480241125e3952414a7a320441080c624c264b004e09614a000627e0461873f37040c9e59c35ad8a106fa1b94f5ec9ef89499b31904f9a3de59be58dd44a714821f8f257e0a502b71ac7ee57530bb9dc29fe12ff3936f925b835a297680400b769489951e512546cd9c9fbdab348b6cba91a601a29b50854e55a6e14f6803ca1d81ac7eff5ceaaa7bacf26f1aa4754d42edeab45d6169ea723b7fdf0f6ff3b6ebe90d09dbff6bc553936ba75a143de4ac932986fbe7b1d78f639bc6ee8aee10d510d41572851530be884778052aaea5315941f4337752905599710b55e64018c71f4d8f299d0636d50484d05e6ac5667b5030000af02000001fb5c44ef0d3ac8730b0000000300003a1e3b617060146e0362361a4b752833186108395f3b2b3d3e6c655e287d7076010000000117432c5a7a672503480241125e3952414a7a320441080c624c264b004e09614a020000020000f09d3cd648a7246c7c1b2ba2f9182465ae5742b78c592392b4b455ab8ed7195200000000000000d2c5ccba12b6fad51652131289867492799c9fc5710244418aa6e955f8fa82610000000000000200476820096e7038107d071a4e473f1e295f346e2d0824263e5e3e7d004f6b69158d080000000000007e0d0a5848362b23120f55115b096774036d7610137a631413221f5573344507ed08000000000000010100000000020000a0860100000000000000000000000000010000ed1484f4d1f7d8c037087fed661dd92faccae1eed3c01182d6fdd6828cea144a0105086372557616532f714f104e5f44297b7a286d077956291a6d4f59081f484463712a64300c00f46312374981be1400000000000000000000000000000000000000000000000001a0860100000000008813000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000ed1484f4d1f7d8c037087fed661dd92faccae1eed3c01182d6fdd6828cea144a0302010568656c6c6f0500776f726c6406ffffffff0200295409de79016133647d4078cb01618a4ba018eb74ff613138d8ff8dc05de73c00868f4c6ef7b5b1d55838cbfb8ae4f3a9776c53cdd3e3d33000094d72acab5a2f071027000000000000900100000000000000000000ffffffff00020000002daefbcbadd044da470acd2f7fcf6fcb04b873cc801e7ee408018e1dfa0257ac5bb409d59e01d2ea9f1a1fb67feb681d0d3ecb05787cadad2f89fdf13ef7ff03ad5cebf28df5dddd8510992596d98b133f86e14f76824e6ccc369a8f5df44806010000fe02000000000000002daefbcbadd044da470acd2f7fcf6fcb04b873cc801e7ee408018e1dfa0257ac3b70bc23b955b710bc131b57696e4a16ca0d4d8601ca2de126e68eeeefa310ef0d7a8668365dddee2a1376630f8564f2190bd89ed2b2ffd061a20ad2bc47ea0b +``` + +Block ID: + +``` +0xf396312ff9dd4abaa08273df8cebc13da25c577df84d3b8979e032595fb6b6a40d000000 +``` + +Block Work Score: `766`. + +## Validation Block ID + +Block (json-encoded): + +```json +{ + "header": { + "protocolVersion": 3, + "networkId": "8342982141227064571", + "issuingTime": "1695275942000000000", + "slotCommitmentId": "0x3a1e3b617060146e0362361a4b752833186108395f3b2b3d3e6c655e287d707601000000", + "latestFinalizedSlot": 500, + "issuerId": "0x17432c5a7a672503480241125e3952414a7a320441080c624c264b004e09614a" + }, + "body": { + "type": 1, + "strongParents": [ + "0x27e0461873f37040c9e59c35ad8a106fa1b94f5ec9ef89499b31904f9a3de59be58dd44a", + "0x714821f8f257e0a502b71ac7ee57530bb9dc29fe12ff3936f925b835a297680400b76948", + "0x9951e512546cd9c9fbdab348b6cba91a601a29b50854e55a6e14f6803ca1d81ac7eff5ce", + "0xaaa7bacf26f1aa4754d42edeab45d6169ea723b7fdf0f6ff3b6ebe90d09dbff6bc553936", + "0xba75a143de4ac932986fbe7b1d78f639bc6ee8aee10d510d41572851530be884778052aa", + "0xea5315941f4337752905599710b55e64018c71f4d8f299d0636d50484d05e6ac5667b503" + ], + "highestSupportedVersion": 3, + "protocolParametersHash": "0x21e0f6e8607b04fa34d54a8a776adfe7e0e5a8931005ce8a66c5990fa1c2f960" + }, + "signature": { + "type": 0, + "publicKey": "0x2daefbcbadd044da470acd2f7fcf6fcb04b873cc801e7ee408018e1dfa0257ac", + "signature": "0x0223a6a21104a8bb14c2afd82c088deab2bfe321b26c555a6b4f097d35e7705edeec575a040829833a8461f2bcfd7a7ef568d59e206111ee5e3b12b43bf61a00" + } +} +``` + +Block (hex-encoded binary serialization): + +``` +0x03fb5c44ef0d3ac87300fc2cbf7cd486173a1e3b617060146e0362361a4b752833186108395f3b2b3d3e6c655e287d707601000000f401000017432c5a7a672503480241125e3952414a7a320441080c624c264b004e09614a010627e0461873f37040c9e59c35ad8a106fa1b94f5ec9ef89499b31904f9a3de59be58dd44a714821f8f257e0a502b71ac7ee57530bb9dc29fe12ff3936f925b835a297680400b769489951e512546cd9c9fbdab348b6cba91a601a29b50854e55a6e14f6803ca1d81ac7eff5ceaaa7bacf26f1aa4754d42edeab45d6169ea723b7fdf0f6ff3b6ebe90d09dbff6bc553936ba75a143de4ac932986fbe7b1d78f639bc6ee8aee10d510d41572851530be884778052aaea5315941f4337752905599710b55e64018c71f4d8f299d0636d50484d05e6ac5667b50300000321e0f6e8607b04fa34d54a8a776adfe7e0e5a8931005ce8a66c5990fa1c2f960002daefbcbadd044da470acd2f7fcf6fcb04b873cc801e7ee408018e1dfa0257ac0223a6a21104a8bb14c2afd82c088deab2bfe321b26c555a6b4f097d35e7705edeec575a040829833a8461f2bcfd7a7ef568d59e206111ee5e3b12b43bf61a00 +``` + +Block ID: + +``` +0x8d32f94efc05b9df445607714ec97873683c54ee7388725ecd9ca782e64b65ed0d000000 +``` + +# Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).