V1.0.0-ANALYSIS-GAS-COST-DETERMINATION

Timeline

• 2026-05-28 — d45eed2 — Chore: mirror blochain specs into github/mdbook (#347)

Owner: @Thomas Lavaur

Reviewers: @Mehmet @Daniel Sanchez Quiros @lvaro Castro-Castilla @David Rusu

Revision History

Introduction

In Mantle, each Mantle Transaction contains one Ledger Transaction and one or more Operations. These components consume gas, measured through fixed gas units that reflect their execution or storage impact. Logos Blockchain introduces three independent gas markets:

• Execution Gas: measuring computational workload.
• Permanent Storage Gas: measuring cost of fully replicated storage.
• Ephemeral DA Storage Gas: measuring sharded storage in the DA layer.

Gas constants are carefully calibrated to reflect the computational and storage requirements of different operations on the Logos Blockchain. By standardizing gas measurements, the system can accurately charge fees proportional to resource usage, preventing network abuse and incentivizing efficient transaction design.

Overview

We conducted a comprehensive analysis of execution requirements for each Operation type in Mantle Transactions and of Ledger Transaction. This detailed examination allowed us to determine precise gas amounts for each Operation based on the actual computational resources consumed.

The gas constants we established are strategically divided between permanent storage, ephemeral data store on the DA layer and execution components, directly proportional to their respective resource utilization within Mantle Transactions. This separation ensures that gas costs accurately reflect the true computational burden of different operations. Moreover, gas can also be adjusted arbitrarily to incentivize or disincentivize the usage of certain Operations compared to others.

Our methodology involved measuring execution complexity and defining how gas is determined for each Gas Market. This is critical for proper network operation as it directly impacts transaction prioritization and network economics.

Permanent Storage Gas

Permanent Storage is paid directly for the entire signed Mantle Transaction. The Permanent Storage Gas price is included in the Mantle Transaction structure and is used to determine the Permanent Storage fee. 1 Permanent Storage Gas corresponds to 1 byte.

permanent_storage_fee = len(encode(tx_signed)) * permanent_storage_gas_price

Ephemeral Storage Gas

Ephemeral storage is a unique market exclusive to Blobs. For this reason, the DA Storage Gas price is included in the Blob Operation structure and is used to determine the DA Storage fee. 1 DA Storage Gas corresponds to 1 byte.

da_storage_fee = blob_size * DA_storage_gas_price

Execution Gas

Execution is a third general market that represent how costly an operation or a Ledger Transaction is to execute. This cost can be fixed or variable based on the content of the Operation / Transaction. The Execution Gas price is contained in the Mantle Transaction structure and each Operation or Ledger Transaction define its execution gas amount. 1 Execution Gas corresponds to 1,000 CPU cycles.

execution_fee = (tx.ops.get_summed_gas() + tx.ledger_tx.get_gas())
* execution_gas_price

The gas derivation of each Operation and of a Ledger Transaction are:

LEDGER_TRANSACTION_GAS = 9331
CHANNEL_INSCRIBE_GAS   = 85
CHANNEL_BLOB_GAS       = 111800 + 7400 * blob_size/(1024*31)
CHANNEL_SET_KEYS       = 85
SDP_DECLARE_GAS        = 9417
SDP_WITHDRAW_GAS       = 9331
SDP_ACTIVE_GAS         = 9331
LEADER_CLAIM_GAS       = 3291

and come from our implementation observations. To get this numbers, we based our calculations on the following measures:

Comparison, list searching, hashes and operation in small fields are neglected.

Ledger Transaction

The Execution Gas of the Ledger Transaction compensates for the verification of the ZkSignature proof and the validation of the overall Mantle Transaction balance. This fundamental gas cost ensures proper cryptographic verification and data integrity of both the Ledger Transaction and the Mantle Transaction. It covers the cost of computing the Mantle Transaction hash.

Execution: ~9.3M CPU cycles.

• Verification of the ZK signature: 9,331,367 cycles.
• Verification of the balance: negligible.
• Computation of the Mantle Transaction hash: negligible.

Input Gas

Input gas covers the computational cost of verifying that one Note Id exists in the Ledger and is not locked. Additionally, it compensates for the removal of one Note Id from the Ledger.

Execution: negligible.

• Verification that the note is in the ledger: negligible.
• Verification that the note is unlocked: negligible.
• Removing of the note from the ledger: negligible.

Output Gas

Output gas accounts for the computational resources required to verify that one output is well-formed and for its inclusion in the Ledger.

Execution: negligible.

• Verification of the output validity: negligible.
• Insertion of the note in the ledger: negligible.

Operations

Channel Inscription

The validation process includes verifying an Eddsa25519 signature, confirming that the signer is authorized for the specified channel, and checking the chaining sequence of the channel. The execution encompasses creating channel records (if not previously used) and updating the tip of the channel.

Execution: ~85k CPU cycles.

• Verification of the Ed25519 signature: 85,201 cycles.
• Verification of the signer authorization (signer in the list): negligible.
• Verification of channel sequencing (equality check): negligible
• Update the tip of the channel: negligible

Channel Blobs

The validation encompasses several critical security checks: verifying an Eddsa25519 signature, confirming the signer's authorization for the specified channel, and validating the chaining sequence of the channel. The execution process involves creating channel records (if not previously established), updating the channel tip, and executing the sampling operations necessary to verify data availability.

Execution: ~111.8M + blob_size/(1024 x 31) * 7.4M CPU cycles

• Verification of the Ed25519 Signature: 85,201cycles.
• Verification of the signer authorization (signer in the list): negligible.
• Verification of channel sequencing (equality check): negligible.
• Update the tip of the channel: negligible.
• Verification of twenty samples of size blob_size/(1024 x 31) : 5,586,527 cycles + 369,701 * blob_size/(1024 x 31) for each sample.

Channel Set Keys

This gas amount covers the verification of the Eddsa25519 signature and ensures the operation is well-formed. This represents the computational cost associated with processing key management operations.

• Execution: ~85k CPU cycles.
  • Verification of the Ed25519 signature: 85,201 cycles.
  • Modification of the key list of the channel: negligible.

SDP Declaration

This gas covers multiple verification processes: confirming ownership of the locked note through ZkSignature verification, validating the zk_id via a second ZkSignature, and establishing ownership of the provider_id through an Eddsa25519 signature. It also includes verification of the declaration format, confirmation of note existence, validation that the note is not already locked, and verification of its amount. Additionally, it accounts for the computational costs associated with the note locking mechanism and declaration management.

Execution: ~ 9.4M CPU cycles.

• Verification of the Ed25519 signature: 85,201 cycles.
• Verification of the ZK signature: 9,331,367 cycles.
• Verification that the declaration doesnt already exist: negligible.
• Verification of locator length: negligible.
• Verification of locked note existence: negligible.
• Verification of locked note value: negligible.
• Verification that the note isnt already locked for the service: negligible.
• Locking the note: negligible.

SDP Withdraw

This gas covers a verification process that includes: confirming ownership of the zk_id through ZkSignature verification, validating the existence of the locked note, verifying that the note has exceeded its lock period, and confirming that the declaration exists and has not been previously withdrawn. The validation process also ensures that the withdrawal message's nonce is greater than any previous nonce, preventing replay attacks. During execution, the system updates the declaration's status to withdrawn, removes the declaration from the locked note's associated declarations, andif the note has no remaining declarationsremoves it from the locked notes dictionary.

Execution: ~ 9.3M CPU cycles.

• Verification that the note exists, is locked and bound to the declaration: negligible.
• Verification that the note can be unlocked: negligible.
• Verification that the declaration exist: negligible.
• Verification of the ZK signature: 9,331,367 cycles.
• Verification that the declaration wasnt already withdrawn: negligible.
• Verification of nonce incrementation: negligible.
• Update declaration: negligible.
• Remove declaration from locked note: negligible.
• Unlock the note if not linked to any declaration: negligible.

SDP Activation

This gas funds the verification of the zk_id signature through the ZkSignature verification process, validates the existence of the declaration in the system, and ensures that the activation message's nonce is greater than any previous nonce to prevent replay attacks. The validation includes confirming that the declaration ID is present in the declarations dictionary and that the signature corresponds to the declaration's registered zk_id public key.

• Execution: ~9.3M CPU cycles.
  • Verification that the declaration exist: negligible.
  • Verification of nonce incrementation: negligible.
  • Verification of the ZK signature: 9,331,367 cycles.
  • Evaluation of the activity depends on the service and is neglected here

Leader Claims

This gas covers the verification of reward voucher ownership through a Proof of Claim, confirmation that the voucher nullifier is not already present in the nullifier set, and validation that the rewards root exists in the list of recent voucher Merkle tree roots. The execution process involves adding the voucher nullifier to the nullifier set and increasing the Ledger Transaction balance by the designated leader reward amount.

Execution: ~3.3M CPU cycles.

• Verification that the voucher nullifier isnt already in the set: negligible.
• Verification that the rewards root is one of the root of the reward tree of the last blocks: negligible.
• Verification of the proof of claim: 3,291,100 cycles.
• Insertion of the nullifier in the voucher nullifier set: negligible.