Gas Optimization Strategies in Cross-Chain Environments | Analog Insights

Gas estimation in cross-chain environments

Insufficient gas on target chains is a major reason why DApp users often abandon cross-chain transactions. To solve this challenge, some cross-chain solutions allow users to pay gas fees in multiple tokens. However, this process can become cumbersome and costly for users.

In an ideal setup, you want to build your DApp on an ecosystem that completely abstracts the issue of gas payment from users. The idea behind the cross-chain gas abstraction mechanism is simple: gas fees should be abstracted away from the UX. In other words, DApp users should only pay the gas fees in native currency on the origin chain and leave the cross-chain solution to handle the execution process on the destination chains.

To achieve gas abstraction, the cross-chain solution must implement accurate gas estimation mechanisms, enabling users to leverage a prepaid fee payment model. This mechanism should help ensure the reliable execution of the cross-chain transaction on the destination chain regardless of gas spikes on that chain.

However, in a cross-chain environment, estimating cross-chain gas fees is more complicated than gas computation, which you’re accustomed to in a single blockchain ecosystem. The true cost of the cross-chain gas consists of three fees:

• The gas fee a user is required to pay on the origin chain.
• The gas fee it takes for the validators to attest to the transaction on the source chain.
• The gas fee it takes to relay and execute the transaction on the destination chain.

Fee (3) is the most complex to estimate because of the different tokens that may exist on the destination chains. In Analog GMP, for example, a decentralized oracle service adjusts the gas fees for each deployed Gateway Smart Contract (GSC) based on Ethereum gas prices whenever possible.

How Analog GMP optimizes cross-chain gas fees

When designing Analog GMP, we meticulously scrutinized the code to optimize cross-chain gas consumption as much as possible. Here are some optimizations that bring the GMP on-chain logic close to its optimal performance:

Optimizing the upgradable proxy

The upgradable proxy is a proxy contract that DApp users use to interact with the deployed GSCs. It is EIP-1167 and EIP-1967-compliant (i.e., popular Solidity patterns that create cheap and minimal proxy clones of contracts). This provides users with as many efficient mechanisms for gas consumption as possible. In addition, the upgradable proxy is ERC-1967 compliant, so Etherscan and other block explorers can recognize it as a proxy.

Use of branchless algorithms to replace conditionals and loops

Using many branches in Solidity can become more expensive because the EVM needs to predict the correct execution path for the code, leading to unpredictable gas costs. For a cross-chain solution like Analog GMP, unpredictable gas costs are problematic for the following reasons:

• Users are required to buy a specific quantity of gas on the origin chain to execute a message on the target chain. As such, the GSC must be certain that the amount of gas is sufficient to execute the message on that chain.
• Blockchain networks often charge users based on the worst-case scenario for gas costs. As a result, users will incur high gas costs when sending cross-chain messages if your code has many branches.

Because of the above reasons, Analog GMP is designed with branchless algorithms that consider the worst-case scenario costs. Our BranchlessMath.sol is an extreme optimization library that consumes constant gas cost for any input and generates significant gas savings compared to OpenZeppelin’s Math library.

In addition, Analog GMP is the only granular cross-chain solution when it comes to cross-chain gas costs. As of this writing, Analog GMP is the only solution considering Ethereum calldata cost in gas cost computations.
For example, Analog GMP can calculate the calldata
cost as 21000 + (16 * non_zeros) + (4 * zeros), while others calculate
21000 + (zeros + non_zeros) * 16, as illustrated here.

Minimal on-chain storage

Store and read operations are by far the most expensive on Ethereum (and any other blockchain). To minimize gas costs for Analog GMP, we compressed as much data as possible into a single 256-bit storage slot. Executing a cross-chain message with a single storage slot is gas efficient because each additional slot costs users between $0.05 and $1.00 per message, making it expensive.

Get started with Analog GMP

You can quickly get started with Analog GMP by visiting this link, where you’ll learn how to dispatch messages using the deployed GSCs.

Here are other quick links to get you started with Analog GMP:

• Track GMP Messages | Track your cross-chain messages with Timechain Explorer.
• Supported Networks | Discover a list of supported networks, gateway addresses, and network IDs.
• Protocol Overview | Learn more about the architectural components of Analog GMP.

Each deployed GSC comes bundled with the estimateMessageCost method, which you can implement or directly call to receive a quote for the gas fees required to execute your message on the destination chain.

function estimateMessageCost(uint16 networkid, uint256 messageSize, uint256 gasLimit)
external
view
returns (uint256)
❴
NetworkInfo storage network = _networkInfo[networkid];
uint256 baseFee = uint256(network.baseFee);
UFloat9x56 relativeGasPrice = network.relativeGasPrice;

// Verify if the network exists
require(baseFee > 0 || UFloat9x56.unwrap(relativeGasPrice) > 0, "unsupported network");

// if the message data is too large, we use the maximum base fee.
baseFee = BranchlessMath.ternary(messageSize > MAX_PAYLOAD_SIZE, 2 ** 256 - 1, baseFee);

// Estimate the cost
return GasUtils.estimateWeiCost(relativeGasPrice, baseFee, uint16(messageSize), 0, gasLimit);
❵

estimateMessageCost has the following parameters:

• networkid: The destination chain where the contract call will be made.
• messageSize: The size of the payload in bytes.
• gasLimit: The gas limit required to execute the payload on the destination

The estimateMessageCost returns a value that serves as a msg.value parameter of the gateway’s submitMessage function. You can use this value (i.e., msg.value) to pass in the native token of your origin chain as the gas fee. For example, you can call the submitMessage function like this:

Build with us!

Join us on our cross-chain journey and become part of the hundreds of developers building unique projects with Analog GMP. Stay up-to-date with Analog:

Discord: https://discord.com/invite/analog

X: https://x.com/OneAnalog

Telegram: @analogannouncements |  https://t.me/analogtimer