V1.1.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 represents 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 = 590
CHANNEL_INSCRIBE_GAS   = 56
CHANNEL_BLOB_GAS       = 6356 + 1600 * sample_size
CHANNEL_SET_KEYS       = 56
SDP_DECLARE_GAS        = 646
SDP_WITHDRAW_GAS       = 590
SDP_ACTIVE_GAS         = 590
LEADER_CLAIM_GAS       = 580

and come from our implementation observations as described in Gas determination from measures. As a reminder, sample_size = blob_size / (1024x31).To get these numbers, we based our calculations on the following measures:

Comparison, list searching, hashes and operation in small fields are neglected. We also supposed that the initialization cost for batch verification is paid by everyone and deduced from the block directly. The user then pay only for the part that is proportional to the number of proofs.

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: ~590k CPU cycles.

• Verification of the ZK signature: 590,000 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: ~56k CPU cycles.

• Verification of the Ed25519 signature: 56,000 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: ~6.356M + sample_size x 1.6M CPU cycles

• Verification of the Ed25519 Signature: 56,000 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.
• Verification of twenty sample : 20 x (315,000 + 80,000 x sample_size ) cycles.

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: ~56k CPU cycles.
  • Verification of the Ed25519 signature: 56,000 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: ~ 646k CPU cycles.

• Verification of the Ed25519 signature: 56,000 cycles.
• Verification of the ZK signature: 590,000 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: ~ 590k 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: 590,000 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: ~590k CPU cycles.
  • Verification that the declaration exist: negligible.
  • Verification of nonce incrementation: negligible.
  • Verification of the ZK signature: 590,000 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: ~580k 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: 580,000 cycles.
• Insertion of the nullifier in the voucher nullifier set: negligible.

Annex

Gas determination from measures

The material used for the benchmarks is the following:

• CPU : 13th Gen Intel(R) Core(TM) i9-13980HX (24 cores / 32 threads)
• RAM : 32GB - Speed: 5600 MT/s
• Motherboard: Micro-Star International Co., Ltd. MS-17S1
• OS : Ubuntu 22.04.5 LTS
• Kernel : 6.8.0-59-generic

Proof of Claim

We found the best linear curve approximating these measures (over 100 iterations):

We got the curve that we decided to approximate to :

ZkSignature

We found the best linear curve approximating these measures (over 1000 iterations):

We got the curve that we decided to approximate to :

Blob Sampling

We measure different scenarios. For each size of sample, we derived a linear equation of the form with the number of samples to verify.

32 KiB blobs (2 sample elements):

The best fitting curve is that we approximated by :

64 KiB blobs (3 sample elements)

The best fitting curve is that we approximated by :

128 KiB blobs (5 sample elements)

The best fitting curve is that we approximated by :

256 KiB blobs (10 sample elements)

The best fitting curve is that we approximated by :

512 KiB blobs (17 sample elements)

The best fitting curve is that we approximated by :

768 KiB blobs (25 sample elements)

The best fitting curve is that we approximated by :

1024 KiB blobs (34 sample elements)

The best fitting curve is that we approximated by :

From all these curves and for simplification, we assumed that the initialization cost is the same for every sample size and equals 5M CPU cycles. Then, we simply linearized again the linear factor of each curve giving us:

Which gives use the linear equation that we approximated by .

This gives us a final sample verification cost (in Execution Gas) of:

The 5000 Execution Gas cost is removed from the Execution Gas limit directly and the rest is applied per Blob Operation individually.