DOCSEARCHbyAlgolia
Submit Docs

Octez Documentation

website·Indexed 39 days ago

https://octez.tezos.com/docs/

Technical guides for installing and configuring Octez, including Homebrew tap installation, baker setup, key management for consensus and companion keys, and baker reactivation processes.

Tokens
115.4K
Snippets
469
Records
778
Agent score
69%

What's inside Octez

  1. Overview of Octez testing frameworks

    Octez utilizes a variety of testing frameworks depending on the component and the type of test (Unit, Property, Integration, System, Regression, or Performance).

    • Ppx_expect: Used for OCaml code generating textual output. Useful for unit and integration tests where output is checked against expected text.
    • QCheck: A property-based testing library for verifying input-output invariants with randomized inputs.
    • Tezt: The primary system testing framework for Octez. It handles interaction with external processes (client, baker, node) and is used for regression testing and CI.
    • tezt-performance-regression: A wrapper around Tezt for long-running tests and performance benchmarking, often integrated with InfluxDB and Grafana.
    • Alcotezt: A compatibility wrapper allowing legacy Alcotest unit tests to run via Tezt.
    • TZT: A syntax extension for writing and executing unit tests for Michelson snippets.

  2. Overview of Enshrined Liquid Staking (sTEZ)

    sTEZ is a protocol-native liquid staking mechanism where users deposit Tez into a protocol-managed contract and receive transferable FA2.1 tokens. Unlike direct staking, sTEZ holdings carry no voting power. The system uses two ledgers: the Staking Ledger (backing sTEZ tokens) and the Unstaked Frozen Ledger (tracking redeemed funds during the UNSTAKE_FINALIZATION_DELAY period). The exchange rate is calculated as total_amount_of_tez / total_supply.

  3. Overview of Octez testing frameworks

    Octez employs several testing strategies to ensure codebase quality across different components (Node, Protocol, Client, Baker, etc.):

    • Ppx_expect: Used for regression testing by comparing current output against pre-recorded logs.
    • Tezt: The primary OCaml Tezos Test Framework used for unit and integration tests. It also supports long-running tests and performance regression testing.
    • Alcotezt: An Alcotest compatibility wrapper for Tezt.
    • Property Testing/Fuzzing: Used to find security weaknesses and ensure functional correctness via automatically generated inputs.
    • Performance Testing: Measures non-functional aspects like runtime, memory, and disk usage.

  4. Overview of Tezos Smart Optimistic Rollups

    Smart rollups are a permissionless scaling solution for the Tezos blockchain (Layer 1) that increase throughput by processing transactions on a Layer 2. They are 'optimistic', meaning claims about the rollup state are trusted by default, but a refutation mechanism allows any honest participant to punish invalid claims, ensuring the integrity of input message interpretation.

  5. Overview of octez-snoop benchmarking tool

    octez-snoop is a tool used to benchmark OCaml code and fit statistical cost models to predict execution time. It is notably used to derive gas costs for the Michelson gas cost API in the Tezos protocol.

    Core Components

    • bin_snoop: The main executable binary.
    • tezos-benchmark: The core library for performing measurements, defining models, and inferring parameters.
    • tezos-micheline-rewriting: A library for manipulating and rewriting Micheline terms, used primarily for protocol-specific benchmarks.

  6. Overview of the Tezos Data Availability Layer (DAL)

    The Data Availability Layer (DAL) is an Octez software component that allows users to publish binary large objects (blobs) outside of Tezos Layer 1 (L1) blocks. This increases data throughput (approximately 10 MB/s compared to L1's 32 KiB/s), reducing fees for users posting Layer 2 (L2) operations, such as smart rollups, without compromising decentralization. The DAL is permissionless and implemented via a network of DAL nodes using a dedicated P2P protocol (distinct from the Octez node P2P layer).

  7. Overview of the tezos-benchmark framework

    The tezos-benchmark library is used to measure the execution time of specific pieces of code (closures) associated with a 'workload' (e.g., storage size, number of instructions). It allows developers to:

    1. Perform timing measurements.
    2. Infer parameters for statistical models to predict execution time.
    3. Display benchmarking results.
    4. Generate code based on the inferred model.

    Modules implementing the Benchmark.S signature can be registered via Registration.register to be accessible through the octez-snoop CLI binary.

  8. Use the External RPC server to prevent node slowdowns

    The Octez node supports an External RPC server designed to handle computationally intensive RPC calls. Using this feature prevents the node from experiencing slowdowns that could cause it to stop synchronizing with peers or fall out of sync. It slightly increases request latency (typically less than 1 ms) but increases the overall number of requests handled per second.

  10. Understand the Octez Baker's role in consensus

    The Octez baker is an executable that participates in Tezos blockchain consensus by producing blocks and creating consensus operations for delegated accounts. It operates in two primary phases:

    1. Preattestation Phase: The baker produces preattestation operations for a proposed block. Once preattestations representing at least 66% of total baking power are observed, a prequorum is reached.
    2. Attestation Phase: The baker crafts attestation operations (optionally including DAL data). Once attestations representing at least 66% of total baking power are observed, the proposal block is elected.

    Block Production: When a delegate has baking rights, the baker constructs a new block including a proof of consensus for the previous elected block and selects operations from the mempool (voting, anonymous, and manager operations) based on gas limits.

  11. Understand Octez RPC handling architecture

    Octez uses two primary libraries for RPC management:

    • Cohttp: A vendored library that handles the core HTTP request/response logic for both Local and External RPC servers.
    • Resto: A library used to declaratively define services and bind them to paths. It manages the assembly of services into directories, spins up the Cohttp server, and provides the client for making requests to these services.

  12. Understand DAL integration with Smart Rollups

    The Data Availability Layer (DAL) allows smart rollup kernels to request pages via the reveal data channel. A rollup node will provide a page if the commitment meets two conditions:

    1. The commitment was published after the rollup origination.
    2. The commitment was not published in a future level (maximum 30 levels ahead of the next state commitment).

    If these conditions are not met, or if the commitment was not attested, the rollup node returns an empty page. If the availability status is unknown, the node waits for L1 confirmation.