Technical Specification of Formats

Cyclone formats

Transaction Format Specification

All transactions that enter a block must undergo processing by the corresponding virtual machine and be augmented with the outcomes of that processing. Each transaction within a block is associated with two hashes: the first hash represents the transaction before processing by the virtual machine, exactly as it was broadcasted to the network; the second hash corresponds to the transaction after processing by the virtual machine

Transaction Format for Broadcasting:

{
  "hash": "string",
  "nonce": "string",
  "vm": "string", // Pointer to the virtual machine responsible for processing this transaction.
  "sender": "string", // Address of the sender initiating the transaction.
  "signature": "string", // Digital signature generated by the sender to authorize the transaction.
  "message": "string", // Any script supported by the virtual machine.
  "currencyFee": "string" // Token address for fee payment (default is CYCL).
}
  • hash: Unique identifier for the transaction, generated using cryptographic hashing algorithms.

  • nonce: Sequential number used to prevent transaction replay attacks and ensure transaction uniqueness from the same sender.

  • vm: Pointer to the virtual machine responsible for processing the transaction.

  • sender: Address of the sender initiating the transaction.

  • signature: Digital signature generated by the sender to authenticate and authorize the transaction.

  • message: Script or message associated with the transaction, supported by the virtual machine.

  • currencyFee: Token address specifying the currency used for fee payment, with the default being CYCL.

Upon processing by the virtual machine, the transaction is supplemented with the following fields:

"exec": {
      "hash": "string", // Hash of the transaction after processing by the virtual machine.
      "vmResponse": {
         "C": [ 
            // Custom fields recorded as JSON objects '<transaction hash or smart contract address that left this entry>: { "key":"value"}'
            {
               "hash": {
                  "key": "value"
               }
            }
         ],
         "D": { // Redistribution of native token after transaction.
            "address": <number> // Amount subtracted from the specified address.
         },
         "E": null | <string>, // Errors encountered during transaction processing, if any.
         "F": <number>, // Fee charged for executing this transaction.
         "R": {}, // Registered tokens, where "token address":true.
         "T": {}, // Changes in token balances in wallets post-transaction.
         "V": {} // List of validator license ownership, where "address":true|false.
      }
   }
  • hash: A string representing the hash of the transaction after processing by the virtual machine. This hash serves as a unique identifier for the processed transaction.

  • vmResponse: An object containing various fields describing the results of the transaction processing:

    • C: An array containing custom fields recorded as JSON objects. These fields may include additional information generated during transaction processing, such as specific outcomes or metadata associated with the transaction.

    • D: An object representing the redistribution of native tokens after the transaction. Each entry in this object consists of an address and the corresponding change in token balance. Positive values indicate an increase in balance, while negative values denote a decrease.

    • E: A null value or object representing any errors encountered during transaction processing. If no errors occurred, this field remains null.

    • F: A numeric value indicating the fee charged for executing the transaction. This value represents the cost incurred by the sender for initiating the transaction.

    • R: An object containing registered tokens, where each token address is associated with a boolean value indicating its registration status.

    • T: An object detailing changes in token balances in wallets following the transaction. Each entry consists of a wallet address and the corresponding change in token balance.

    • V: An object representing the ownership status of validator licenses. Each entry consists of a validator address and a boolean value indicating ownership status (true for ownership, false otherwise).


Block Format Specification

A block within the Cyclone blockchain adheres to a structured format designed to ensure uniformity, reliability, and compatibility across the network. The block format comprises several key components:

{
  "Block Format Specification": {
    "number": "string",
    "hash": "string",
    "prevBlockHash": "string",
    "baseRND": "string",
    "signatures": [
      {
        "address": "string",
        "signature": "string"
      }
    ],
    "txHashes": [
      {
        "hash": "string",
        "execHash": "string"
      }
    ]
  }
}
  • number: A string representing the block number, indicating its position within the blockchain's sequence of blocks.

  • hash: A string representing the unique cryptographic hash of the current block. This hash serves as an identifier for the block and ensures its integrity within the blockchain.

  • prevBlockHash: A string representing the hash of the previous block in the blockchain. This linkage ensures the chronological order and continuity of blocks within the blockchain.

  • baseRND: A string representing the base random number for the current block. This number may be utilized in smart contracts or other network functionalities requiring randomness.

  • signatures: An array containing objects representing the addresses and corresponding signatures of validators who have approved and attested to the validity of the block. Each object consists of:

    • address: The address of the validator.

    • signature: The cryptographic signature generated by the validator to authenticate the block.

  • txHashes: An array containing objects representing the hashes of transactions included in the block, along with the hashes of their corresponding execution results. Each object consists of:

    • hash: The hash of the transaction before processing by the virtual machine.

    • execHash: The hash of the transaction after processing by the virtual machine.


Ninth Block Format Specification

The Ninth Block in the Cyclone blockchain serves a specialized purpose, encompassing emission calculations, license price calculation, license redistribution, and the allocation of new emissions to validators. Here's a breakdown of its components:

  • number: A string denoting the block number, indicating its sequential position in the blockchain.

  • hash: A string representing the unique cryptographic hash of the current block, ensuring its integrity and identification within the blockchain.

  • prevBlockHash: A string representing the hash of the previous block in the blockchain, maintaining the chronological order and continuity of blocks.

  • baseRND: An empty string indicating the absence of a base random number for the current block, as it's a special block type with a different purpose.

  • signatures: An empty array signifying that the ninth block does not contain signatures from validators, as it's not part of the regular consensus mechanism.

  • txHashes: An array containing objects representing the hashes of transactions included in the ninth block, along with the hashes of their corresponding execution results. This field facilitates tracking and referencing transactions associated with the block.

Virtual Transaction Example within the Ninth Block:

  • hash: A string representing the number (not hash) of the virtual transaction, serving as a unique identifier within the block. The format is hash_block9_<ninth block number>

  • block: A string denoting the block number to which the virtual transaction belongs, providing context for its placement within the blockchain.

  • nonce: always 0

  • sender: A string representing the concatenated validators addresses involved in the transaction.

  • exec: An object containing detailed information about the execution of the virtual transaction, including:

    • hash: A string representing the hash of the transaction.

    • vmResponse: An object encapsulating various data such as emission calculations, license prices, and validator allocations. This object contains subfields like:

      • C: An array containing objects with custom data related to emission calculations, validator allocations, and other metrics.

      • D: An object representing the redistribution of licenses among validators, detailing the changes in license distribution.

      • E: A null value indicating the absence of errors during transaction execution.

      • F: A numeric value representing the fee associated with the virtual transaction, which is zero in this case.

      • R: An empty object indicating the absence of registered tokens.

      • T: An empty object indicating the absence of changes in token balances.

      • V: An empty object indicating the absence of validator license ownership changes.

Note: In the Ninth Block, there is only one virtual transaction, which carries out the necessary emission calculations, license management, and validator allocations for the block.

Last updated