-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create 20240508-computation-limit-hike.md #268
Merged
Merged
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
972401f
Create 20240508-computation-limit-hike.md
KshitijChaudhary666 3f1559c
Update governance/20240508-computation-limit-hike.md
KshitijChaudhary666 a9cf359
Update governance/20240508-computation-limit-hike.md
KshitijChaudhary666 984f1cc
Update governance/20240508-computation-limit-hike.md
KshitijChaudhary666 e187ecd
Update governance/20240508-computation-limit-hike.md
KshitijChaudhary666 fb516ab
Update governance/20240508-computation-limit-hike.md
KshitijChaudhary666 d5499df
Update governance/20240508-computation-limit-hike.md
KshitijChaudhary666 654f5ef
Update governance/20240508-computation-limit-hike.md
KshitijChaudhary666 a032b87
Update 20240508-computation-limit-hike.md
KshitijChaudhary666 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,75 @@ | ||
# FLIP-267: Increasing the transaction computation limit | ||
|
||
| Status | Draft | | ||
:-------------- |:---------------------------------------------------- | | ||
| **FLIP #** | 267 | ||
| **Author(s)** | Kshitij Chaudhary (kshitij.chaudhary@flowfoundation.com) | | ||
| **Sponsor** | Kshitij Chaudhary (kshitij.chaudhary@flowfoundation.com) | | ||
| **Updated** | 2024-05-08 | | ||
|
||
## Introduction | ||
|
||
Please refer to [this post](https://forum.flow.com/t/how-evm-transaction-fees-work-on-flow-previewnet/5751) for detailed insights into how transaction fees for EVM transactions will be calculated once EVM goes live on Flow Mainnet. With the introduction of the new parameter `EVMGasUsage`, the calculation of execution effort on Flow Cadence will be modified as follows: | ||
|
||
``` | ||
Execution Effort = | ||
0.0239 * function_or_loop_call + | ||
0.0123 * GetValue + | ||
0.0117 * SetValue + | ||
43.2994 * CreateAccount + | ||
EVMGasUsageCost * EVMGasUsage | ||
``` | ||
|
||
Here, `EVMGasUsage` represents the gas used by EVM, such as 21K gas for a simple send transaction. Meanwhile, `EVMGasUsageCost` denotes the ratio for converting EVM gas to Flow’s computation units, which may also be called “Gas-to-Compute ratio” or “G2C ratio.” | ||
|
||
In this FLIP, we make two proposals - | ||
|
||
1. A mechanism to convert EVM gas costs into Flow computation costs so that EVM transactions and operations can be added into the standard Flow transaction fee calculations | ||
2. An increase in the computation limit for Flow transactions to reflect the performance improvements made to Cadence and the overall protocol, in order to allow each transaction to do more (when warranted). | ||
|
||
## Problem Statement | ||
|
||
EVM on Flow (”Crescendo”) presents an interesting challenge - how to compute Flow computation units from EVM gas. The current execution effort (”compute”) limit of 9999 on Flow Cadence may be inadequate for larger EVM transactions. Flow should be able to match or surpass the capabilities of Ethereum, allowing transactions of up to 30M gas to be executed seamlessly. | ||
|
||
To attain this objective, two approaches can be employed: (1) Implementing a gas-to-compute conversion ratio (`EVMGasUsageCost`) to ensure that larger contracts (30M gas) fit within the 9999 compute limit, and (2) raising the computation limit on Flow to accommodate larger transactions requiring higher compute. A combined approach leveraging both methods would offer the most effective solution. | ||
|
||
## Solution | ||
|
||
1. **Set Gas to compute conversion ratio at 5000:1 (or** `EVMGasUsageCost` **at 1/5000)** | ||
|
||
Empirical data shows that G2C should not be lower than 1000:1, given the current computation limit of 9999 (or in other words, the current weights in “execution effort” calculation), otherwise we risk EVM transactions using up more computation time, than they pay for. Considering however that EVM transactions also consume compute units in cadence execution, the actual size of EVM transactions or contracts that can be executed with the ratio of 1000:1 would be much less than 10M. | ||
|
||
To match Ethereum’s 30M gas limit, a 5000:1 gas to compute ratio could be adopted to calculate execution effort (compute units) on Flow. Based on some tests, this ratio would allow for 30M gas, along with adequate compute allocation for cadence execution of such transactions. For instance, a 30M gas transaction with a 5000:1 conversion ratio would consume about 6000 compute units for EVM execution, leaving 3999 compute units for Cadence execution. | ||
|
||
It’s important to note that for such sizable contracts however, even these compute units (3999 in the above example) may prove insufficient for cadence execution. Therefore, we should also consider revising Flow’s computation limit of 9999 to ensure seamless execution of the largest Ethereum contracts. | ||
|
||
2. **Increase transaction Computation Limit by 5x** | ||
|
||
Directly raising the computation limit entails substantial code modifications and collaboration with ecosystem developers. Alternatively, we can indirectly increase the limit by lowering the execution effort coefficients or weights (0.0239, 0.0123, 0.0117, and 43.2994 in the “execution effort” calculation). Decreasing these weights would effectively expand a transaction’s computation limit; in other words, more and larger operations would “fit within” the 9999 compute limit. | ||
|
||
To determine the appropriate reduction factor for the weights, a thorough understanding of Flow’s execution capabilities in handling large transactions was necessary. This involved assessing how much “computation” could currently be accommodated in a block (on Mainnet24) and how much additional time a transaction could consume; challenges might arise if blocks occasionally take longer to execute than their allotted time based on the block rate. For instance, if transactions in a block exceed the available block time (1.25s), they might need to be split across multiple blocks — a feature not currently supported; also, single transactions can never be split further. After evaluating these factors, it became apparent that increasing the transaction time by more than 5 times may lead to execution issues. Therefore, it is proposed to reduce the computation weights by a factor of 5. | ||
|
||
Note that the reduction in coefficients will be offset by a corresponding increase in the unit cost of execution on Flow (by 5x). This adjustment aims to ensure that there are no changes in the overall transaction fee paid for a transaction despite the higher computation limit and lower coefficients. See [this post](https://forum.flow.com/t/how-evm-transaction-fees-work-on-flow-previewnet/5751) to review the calculation method for transaction fees and to understand how a corresponding increase in the cost of execution units would negate any influence on the total transaction fee. | ||
|
||
## Proposal (Summary) | ||
|
||
1. Establish the “Gas to compute ratio” at 5000:1 by setting `EVMGasUsageCost` to `1/5000`. In other words, 5000 EVM gas would be counted as 1 Flow computation unit. | ||
2. Reduce the coefficients of execution effort by a factor of 5, effectively increasing the computation limit by the same factor. | ||
3. Counterbalance the reduction in coefficient values with a 5x increase in the cost of execution unit on Flow (from 4.99E-08 to 2.495E-7). | ||
|
||
``` | ||
Execution Effort = | ||
**0.00478** * function_or_loop_call + | ||
**0.00246** * GetValue + | ||
**0.00234** * SetValue + | ||
**8.65988** * CreateAccount + | ||
**1/5000** * EVMGasUsage** | ||
``` | ||
|
||
## Impact | ||
|
||
The proposed/implemented changes aim to enhance the computation limit. For developers, the increase in effective computation limit along with the 5000:1 gas-to-compute ratio would empower them to execute larger contracts on EVM on Flow. The indirect method of increasing the compute limit (by changing the value of coefficients allowing larger transactions to “fit in”) eliminates any extra effort required to update their contracts for changes in the computation limit. Overall, this proposal would bring ‘EVM Equivalence’ in terms of contract and transaction size capabilities for EVM transactions on Flow. | ||
|
||
## Next Steps | ||
|
||
The community is invited to share feedback on this post. If approved, the changes will undergo testing on the testnet before deployment on Mainnet, proposed to be timed around the [Crescendo mainnet launch](https://flow.com/upgrade/crescendo). |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you throw in some examples -
A token transfer would cost x in EVM gas and will use y in Cadence computation and will have a total transaction cost of Z FLOW.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This FLIP proposes no alterations that affect the fees so don't think we should talk about the costs here. The fee adjustments would only result from the 100x transaction fee FLIP proposal and also from introducing EVMGasUsageCost * EVMGasUsage to the execution effort calculation (explained in this post - https://forum.flow.com/t/how-evm-transaction-fees-work-on-flow-previewnet/5751). This FLIP is not gathering feedback on either of those so any examples to showcase cadence vs EVM fees might be confusing. Additionally, any examples (like the one in the post shared) would solely be illustrative at this point and cannot be generalized at all, which might add to the confusion