FLIP 346: Variable Transaction Fees - Execution Effort II. #347
Conversation
|
Any chance to share data? Mainly graph sources and new weights etc. 9999 execution effort being 1 second CPU time feels very wrong to me too. ( Probably misunderstanding something ) I would assume like 0.01 - 0.1 seconds or something. |
| By design, Flow defines a maximum transaction execution time of **1 second**, which currently maps to **9,999 computation = 9,999 × 65,536 CU**. However, recalibrated weights change the relative cost of individual operations, and if the conversion factor remained unchanged, the overall throughput of the network (in terms of execution effort per unit time) would shift. | ||
|
|
||
| To avoid unintentionally lowering or raising the effective throughput of mainnet, this FLIP proposes to **redefine the conversion factor** such that: | ||
|
|
||
| - The **average execution effort throughput** observed on mainnet today is preserved after recalibration. | ||
| - Users will see fairer distribution of costs across operations, but the **aggregate capacity of the network remains constant**. | ||
| - This ensures alignment with governance objectives to maintain predictable throughput while still improving fee fairness and security. |
There was a problem hiding this comment.
@bluesign regarding your comment/question
9999 execution effort being 1 second CPU time feels very wrong to me
From my perspective, the following two were conventions that we started with 2 or 3 years ago:
- 9,999 computation is equated with 1 second runtime
- maximum transaction execution time of 1 second
These conventions were introduced when the network was significantly slower and I think it is worth revisiting. Thanks for commenting in this regard.
In the text following, Janez is arguing that the normalization of 9,999 CU equalling 1 second runtime should be revised ("if the conversion factor remained unchanged, the overall throughput of the network would shift"). While I don't know what the normalization will be, my gut feeling is it should come out to be closer to the magnitude you expect (0.01s to 0.1s).
The maximum run time for a transaction in terms of time also scales proportionally. If the system gets x times as fast, the max transaction runtime should scale anti-proportionally by a factor of 1/x.
Assuming I understood your comment correctly, @bluesign, I think we are aligned on the outcome. Just the test might need some clarification ...
There was a problem hiding this comment.
I changed the wording a bit and updated the numbers not that we have more data. please take a look.
There was a problem hiding this comment.
thanks @janezpodhostnik , does 9,999 computation = 333.4 ms mean "1 cpu core can run 3 transactions in a second" or 1 EN ( 128 cores iirc ) can run 3 transactions in a second" ?
There was a problem hiding this comment.
3 full ones yes
janezpodhostnik
requested review from
AlexHentschel,
joshuahannan and
vishalchangrani
joshuahannan
left a comment
joshuahannan
left a comment
There was a problem hiding this comment.
Well written! I don't see any issues
dete
left a comment
dete
left a comment
There was a problem hiding this comment.
Just a few wording suggestions. Great write-up!
|
This has been rolled out to mainnet. Merging the PR. |
Issue: #346
This Flip is the successor to the Flip Variable Transaction Fees - Execution Effort I.
Objective
This FLIP proposes an update to Flow’s execution effort weights, originally introduced in FLIP 660: Variable Transaction Fees. The update reflects changes in the execution environment and expands coverage to a broader set of actions possible within Cadence on Flow.
The goals are to:
Comment Period