I know that the gas limit was recently raised to 1,000,000 in the Carthage protocol upgrade, but I feel it still isn’t enough to do some basic things. We have been working on the Dexter decentralized exchange contracts that currently work with FA1.2 contracts. They are written in LIGO and have been optimized with the help of the LIGO language developers.
Currently to perform a trade of XTZ for an FA1.2 to token, which does a few calculations in Dexter, then calls FA1.2 the transfer entrypoint in FA1.2, it costs 449,825 gas. The FA1.2 token is a vanilla implementation in LIGO that follows the specification as closely as possible without any extra features.
We have experimented with a more complicated entry point Token to Token which would allow you to use two Dexter contracts to trade one FA1.2 token for another FA1.2 token with a contiguous series of operations all on chain. Internally it calls token to XTZ in the first Dexter contract, then XTZ to token in the second Dexter contract. Unfortunately the gas cost is about 1,010,000 which exceeds the limit. Currently the decision is not to include the token to token entry point in the first version of Dexter (you can emulate it with two separate calls to the block chain but that is not as nice). If you imagine more complicated contracts like FA2 with more features, it may be even more challenging to call them because of higher gas costs for each of the entry points.
I think gas limits are still preventing smart contract developers from doing interesting things. That said we should be conscious of the limits and try to optimize the contracts as much as possible. I don’t know what negative implications there are to increasing the gas limit further. If anyone knows what they are, please share. I want to gauge interest in further increasing gas limits in the next protocol upgrade.
I don’t know what negative implications there are to increasing the gas limit further.
You might be interested in the blog post that explains the methodology that has been followed for the Babylon update. The points listed at the end are currently been worked on at Nomadic Labs.
First the gas limits can be increased or adjusted and for 007 we will have such an adjustment.
Second it would be good to check how efficient the generated code from Ligo is. If the Ligo compiler generates inefficient code, then time should be spend on optimising that, instead of increasing the gas limits. Increasing gas limits should also be done as a measure of last resort, since the computational cost has to be carried by every node in the network, and by increasing the limits, we are continuously increasing the minimum requirements to run a node.
I believe this would not increase the load on the network.
It might make the network slower as less transactions could be included in a block, but then, markets would decide which one would be included.
Improving Michelson
Support for more efficient instructions has already been added in the past by people from the LIGO team and Nomadic (DIG/DUG). This made code more efficient for all languages. There are currently plans to add similar improvements to the protocol.
Optimizing the Michelson interpreter
As gas efficiency concerns become bigger, we could spend time optimizing the actual Michelson interpreter to reduce gas costs of various operations.
Optimizing your LIGO code
You can ask on any of the LIGO channels (#ligo on slack) for tips to change your LIGO code to make the generated Michelson more efficient.
Optimizing the LIGO compiler
If you can send us examples, we can optimize the LIGO compiler to take care of them.
We are also adding features to include Michelson within LIGO programs, so that performance sensitive code can be written in Michelson directly.
It is to be noted that there are two kinds of optimizations a compiler can do:
Optimizing the program. This includes things like inlining, computing constants, etc. They should still work with any future improvement of Michelson.
Optimizing the Michelson. They are very contingent to the current version of Michelson, and will likely be out-of-date at some point.
It is also to be noted that improving Michelson benefits everyone, while compiler optimizations have to be re-coded for all languages.
By “raising the limit” you should specify that you meant: “raising the per transaction limit but but the per block limit”. It’s not obvious without context.
This analysis from NL was posted more than a year ago now, can Nomadic Labs offer us insights here about their progress on the topic over the past one year ? How much of a priority has it been in terms of resource allocation over that time ?
The reality seems to be that Tezos is likely severely limiting the ability of developers interested in building effectively on top of Tezos such as OP. By having the gas limit as barrier to entry (by requiring very complex type of optimization for even the simplest of contracts to make them fit) it makes adoption difficult.
Even though most people understand the need for theoretical understanding of gas limit implications in terms of performance and security it is fair to say that in practice it is very challenging for dev to build industrial grade applications. I wish Nomadic Labs would feel the urgency in this and not further delay offering improvements on that front before 2021.
The gas limits are probably an order of magnitude away from what they should be to allow Tezos to delivery on its promise to add value on relative basis compared to say Ethereum as a smart contract platform.
What are the concerns with the gas limit raised per transaction? Should allow people to develop more complex use cases while optimizing at the same time.
