Smart Cost

Contract Optimization on Glide Protocol

Glide is designed to be EVM equivalent, which means Glide looks exactly like Ethereum in every way possible. One large and mostly unavoidable discrepancy between Glide and Ethereum is a slight difference in transaction fee models. This difference means that there are some opportunities to optimize Glide contracts to better take advantage of the Glide fee model.

This guide explains the basic concepts that allow you to optimize Glide contracts and provides several examples of how you might take advantage of these concepts. You'll also get a better understanding of the tradeoffs and risks involved with potential contract optimizations. By the end of this guide you should have a clear understanding of how Glide contracts can be optimized and whether or not these optimizations make sense for your application.

Contract optimizations are powerful but can also create additional contract complexity. Some types of optimizations may also become unnecessary as Glide evolves. Make sure to read through all of the considerations on this page before committing to any optimizations.

Fundamentals

App developers might already be familiar with the concept of gas optimization to decrease the cost of interacting with smart contracts. Gas optimization can reduce the amount of gas used by a contract and make your application cheaper (and therefore improve user experience).

Glide contracts can be gas optimized to reduce overall transaction costs, just like contracts on Ethereum. However, Glide transactions must also pay for another fee called the L1 Data Fee which accounts for the cost of publishing transaction data to Ethereum. At the time this guide was written, this L1 Data Fee made up the majority of the cost of most transactions on Glide.

Because the L1 Data Fee tends to be larger than the execution gas fee, Glide contracts can be further optimized by increasing the amount of storage/execution used in order to decrease the amount of user-provided data in each transaction. This is the basic premise that makes Glide contract optimization slightly different than on Ethereum.

Considerations

Additional Complexity

Contract optimizations can create additional complexity, which can in turn create additional risk. Developers should always consider whether this added complexity is worth the reduction in cost.

Changing Economics

Various potential upgrades to Glide may also make optimizations to the L1 Data Fee less relevant. For instance, EIP-4844, if adopted, should significantly reduce the cost of publishing data to Ethereum and would therefore also decrease the L1 Data Fee.

Glide also uses an EIP-1559 mechanism that automatically increases the base fee as chain usage increases. Optimizations based on reducing the L1 Data Fee may become less relevant if the base fee becomes a larger part of the total transaction cost.

Generally speaking, developers should assume that L1 Data Fee optimizations will become less useful as time goes on. If you expect your contracts to be used for long periods of time, you may wish to avoid optimizations that can potentially decrease long-term gas efficiency. If you expect your contracts to be used mostly in the short term or you have the ability to upgrade contracts in the future, optimizations may be better suited for you

Techniques

Calldata Compression

Compressing user data on the client side and decompressing it on the contract side can be an effective way to decrease costs on Glide. This technique decreases the amount of data provided by the user in exchange for a significant increase in onchain computation.

Although several libraries exist to perform this calldata compression, none of these libraries have been audited as of the writing of this page. As a result, links to these libraries have been explicitly omitted here to avoid encouraging developers from using potentially buggy software. Most of these libraries can be found with a quick search online but, as always, be careful with code you find on the internet.

Custom Encoding

The Solidity ABI encoding scheme is not particularly data efficient. Contracts can often reduce the amount of calldata provided by defining a custom argument encoding protocol.

Custom argument encodings can be combined with stored data to further reduce costs. For example, address arguments could potentially be replaced with a uint64 pointer that performs a lookup in a stored mapping of uint64 => address. This would cut out a significant number of bytes with further reductions if the total number of addresses that need to be looked up is small (which would allow uint64 to be reduced to uint32 or less).

Custom encodings are typically less complex that general-purpose calldata compression libraries but carry additional complexity no matter what. When combined with stored data, application-specific custom encodings can be significantly more efficient than general-purpose compression mechanisms.

How do network fees on Glide work?​

Every base transaction consists of two costs: an L2 (execution) fee and an L1 (security) fee. The L2 fee is the cost to execute your transaction on the L2, and the L1 fee is the estimated cost to publish the transaction on the L1. Typically the L1 security fee is higher than the L2 execution fee.

The L1 fee will vary depending on the amount of transactions on the L1. If the timing of your transaction is flexible, you can save costs by submitting transactions during periods of lower gas on the L1 (for example, over the weekend)

Similarly, the L2 fee can increase and decrease depending on how many transactions are being submitted to the L2. This adjustment mechanism has the same implementation as the L1