From 972401fae576253da17e4c9bebb895ba6f25fda8 Mon Sep 17 00:00:00 2001 From: Kshitij Chaudhary <78124453+KshitijChaudhary666@users.noreply.github.com> Date: Thu, 9 May 2024 02:48:05 +0530 Subject: [PATCH 1/9] Create 20240508-computation-limit-hike.md Creating new draft FLIP --- governance/20240508-computation-limit-hike.md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 governance/20240508-computation-limit-hike.md diff --git a/governance/20240508-computation-limit-hike.md b/governance/20240508-computation-limit-hike.md new file mode 100644 index 00000000..51578e64 --- /dev/null +++ b/governance/20240508-computation-limit-hike.md @@ -0,0 +1,74 @@ +# FLIP-267: Increasing Computation Limit on Flow + +| 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 launch on Flow (”Crescendo”) presents an opportunity to better align with network objectives and user needs in terms of total computation required. 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. + +1. **Computation Limit** + +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 before encountering complications. 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 proposed reduction in coefficients is proposed to 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`. +2. Reduce the coefficients of execution effort by a factor of 5x, effectively increasing the computation limit by the same factor. 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). From 3f1559c198722b748cbde2f51f0ec14305bc1bd0 Mon Sep 17 00:00:00 2001 From: Kshitij Chaudhary <78124453+KshitijChaudhary666@users.noreply.github.com> Date: Thu, 9 May 2024 19:44:48 +0530 Subject: [PATCH 2/9] Update governance/20240508-computation-limit-hike.md Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com> --- governance/20240508-computation-limit-hike.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/governance/20240508-computation-limit-hike.md b/governance/20240508-computation-limit-hike.md index 51578e64..42a51ce2 100644 --- a/governance/20240508-computation-limit-hike.md +++ b/governance/20240508-computation-limit-hike.md @@ -17,7 +17,7 @@ Execution Effort = 0.0123 * GetValue + 0.0117 * SetValue + 43.2994 * CreateAccount + - **EVMGasUsageCost * EVMGasUsage** + 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.” From a9cf35919b589df25359e2c8837380dc86c15b76 Mon Sep 17 00:00:00 2001 From: Kshitij Chaudhary <78124453+KshitijChaudhary666@users.noreply.github.com> Date: Thu, 9 May 2024 19:45:19 +0530 Subject: [PATCH 3/9] Update governance/20240508-computation-limit-hike.md Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com> --- governance/20240508-computation-limit-hike.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/governance/20240508-computation-limit-hike.md b/governance/20240508-computation-limit-hike.md index 42a51ce2..57396fb7 100644 --- a/governance/20240508-computation-limit-hike.md +++ b/governance/20240508-computation-limit-hike.md @@ -1,4 +1,4 @@ -# FLIP-267: Increasing Computation Limit on Flow +# FLIP-267: Increasing the transaction computation limit | Status | Draft | :-------------- |:---------------------------------------------------- | From 984f1ccbdcdd6309dd8916adadea7c344516ac1f Mon Sep 17 00:00:00 2001 From: Kshitij Chaudhary <78124453+KshitijChaudhary666@users.noreply.github.com> Date: Thu, 9 May 2024 19:45:47 +0530 Subject: [PATCH 4/9] Update governance/20240508-computation-limit-hike.md Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com> --- governance/20240508-computation-limit-hike.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/governance/20240508-computation-limit-hike.md b/governance/20240508-computation-limit-hike.md index 57396fb7..a48a827b 100644 --- a/governance/20240508-computation-limit-hike.md +++ b/governance/20240508-computation-limit-hike.md @@ -29,7 +29,7 @@ In this FLIP, we make two proposals - ## Problem Statement -EVM launch on Flow (”Crescendo”) presents an opportunity to better align with network objectives and user needs in terms of total computation required. 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. +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. From e187ecdda588b64529c62898398dcbffe245edf8 Mon Sep 17 00:00:00 2001 From: Kshitij Chaudhary <78124453+KshitijChaudhary666@users.noreply.github.com> Date: Thu, 9 May 2024 19:47:35 +0530 Subject: [PATCH 5/9] Update governance/20240508-computation-limit-hike.md Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com> --- governance/20240508-computation-limit-hike.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/governance/20240508-computation-limit-hike.md b/governance/20240508-computation-limit-hike.md index a48a827b..6f5944e9 100644 --- a/governance/20240508-computation-limit-hike.md +++ b/governance/20240508-computation-limit-hike.md @@ -49,7 +49,7 @@ Directly raising the computation limit entails substantial code modifications an 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 before encountering complications. 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 proposed reduction in coefficients is proposed to 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. +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) From fb516ab5ad35bc6cb4fb201396a66f799b4e0384 Mon Sep 17 00:00:00 2001 From: Kshitij Chaudhary <78124453+KshitijChaudhary666@users.noreply.github.com> Date: Thu, 9 May 2024 19:48:09 +0530 Subject: [PATCH 6/9] Update governance/20240508-computation-limit-hike.md Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com> --- governance/20240508-computation-limit-hike.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/governance/20240508-computation-limit-hike.md b/governance/20240508-computation-limit-hike.md index 6f5944e9..4aa6e6aa 100644 --- a/governance/20240508-computation-limit-hike.md +++ b/governance/20240508-computation-limit-hike.md @@ -53,7 +53,7 @@ Note that the reduction in coefficients will be offset by a corresponding increa ## Proposal (Summary) -1. Establish the “Gas to compute ratio” at 5000:1 by setting `EVMGasUsageCost` to `1/5000`. +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 5x, effectively increasing the computation limit by the same factor. 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). ``` From d5499df4a91b7f02e09ffb959eb6b553b16ebfe7 Mon Sep 17 00:00:00 2001 From: Kshitij Chaudhary <78124453+KshitijChaudhary666@users.noreply.github.com> Date: Thu, 9 May 2024 19:48:32 +0530 Subject: [PATCH 7/9] Update governance/20240508-computation-limit-hike.md Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com> --- governance/20240508-computation-limit-hike.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/governance/20240508-computation-limit-hike.md b/governance/20240508-computation-limit-hike.md index 4aa6e6aa..80998b49 100644 --- a/governance/20240508-computation-limit-hike.md +++ b/governance/20240508-computation-limit-hike.md @@ -54,7 +54,8 @@ Note that the reduction in coefficients will be offset by a corresponding increa ## 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 5x, effectively increasing the computation limit by the same factor. 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). +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 = From 654f5ef10b61be93e4030540dd21499ec2067d41 Mon Sep 17 00:00:00 2001 From: Kshitij Chaudhary <78124453+KshitijChaudhary666@users.noreply.github.com> Date: Thu, 9 May 2024 19:48:55 +0530 Subject: [PATCH 8/9] Update governance/20240508-computation-limit-hike.md Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com> --- governance/20240508-computation-limit-hike.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/governance/20240508-computation-limit-hike.md b/governance/20240508-computation-limit-hike.md index 80998b49..27de302e 100644 --- a/governance/20240508-computation-limit-hike.md +++ b/governance/20240508-computation-limit-hike.md @@ -43,7 +43,7 @@ To match Ethereum’s 30M gas limit, a 5000:1 gas to compute ratio could be adop 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. -1. **Computation Limit** + **Computation Limit** 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. From a032b873580494b041e087f248bfb7b35408bc71 Mon Sep 17 00:00:00 2001 From: Kshitij Chaudhary <78124453+KshitijChaudhary666@users.noreply.github.com> Date: Thu, 9 May 2024 19:59:38 +0530 Subject: [PATCH 9/9] Update 20240508-computation-limit-hike.md --- governance/20240508-computation-limit-hike.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/governance/20240508-computation-limit-hike.md b/governance/20240508-computation-limit-hike.md index 27de302e..a16768d9 100644 --- a/governance/20240508-computation-limit-hike.md +++ b/governance/20240508-computation-limit-hike.md @@ -17,7 +17,7 @@ Execution Effort = 0.0123 * GetValue + 0.0117 * SetValue + 43.2994 * CreateAccount + - EVMGasUsageCost * EVMGasUsage** + 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.” @@ -43,11 +43,11 @@ To match Ethereum’s 30M gas limit, a 5000:1 gas to compute ratio could be adop 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. - **Computation Limit** + 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 before encountering complications. 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. +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.