Update condition for a full chunk to respect parameter weights #8265
Assignees
Labels
A-transaction-runtime
Area: transaction runtime (transaction and receipts processing, state transition, etc)
T-contract-runtime
Team: issues relevant to the contract runtime team
Comments
jakmeier
added
A-transaction-runtime
near-bulldozer bot
pushed a commit
that referenced
this issue
Apr 4, 2023
feature: Limit compute usage of a chunk The commit addresses #8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the `assert`, so any discrepancy should be caught on canary nodes. There are two follow-ups to this work: - #8859 - #8860
|
This is addressed with #8805. |
nikurt
pushed a commit
to nikurt/nearcore
that referenced
this issue
Apr 5, 2023
feature: Limit compute usage of a chunk The commit addresses near#8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the `assert`, so any discrepancy should be caught on canary nodes. There are two follow-ups to this work: - near#8859 - near#8860
aborg-dev
added a commit
to aborg-dev/nearcore
that referenced
this issue
Apr 11, 2023
feature: Limit compute usage of a chunk The commit addresses near#8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the `assert`, so any discrepancy should be caught on canary nodes. There are two follow-ups to this work: - near#8859 - near#8860
aborg-dev
added a commit
to aborg-dev/nearcore
that referenced
this issue
Apr 14, 2023
feature: Limit compute usage of a chunk The commit addresses near#8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the `assert`, so any discrepancy should be caught on canary nodes. There are two follow-ups to this work: - near#8859 - near#8860
aborg-dev
added a commit
to aborg-dev/nearcore
that referenced
this issue
Apr 17, 2023
feature: Limit compute usage of a chunk The commit addresses near#8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the `assert`, so any discrepancy should be caught on canary nodes. There are two follow-ups to this work: - near#8859 - near#8860
aborg-dev
added a commit
to aborg-dev/nearcore
that referenced
this issue
Apr 18, 2023
feature: Limit compute usage of a chunk The commit addresses near#8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the `assert`, so any discrepancy should be caught on canary nodes. There are two follow-ups to this work: - near#8859 - near#8860
aborg-dev
added a commit
to aborg-dev/nearcore
that referenced
this issue
Apr 18, 2023
feature: Limit compute usage of a chunk The commit addresses near#8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the `assert`, so any discrepancy should be caught on canary nodes. There are two follow-ups to this work: - near#8859 - near#8860
near-bulldozer bot
pushed a commit
that referenced
this issue
Apr 18, 2023
This PR re-introduces changes from #8805 together with #8892 after fixing #8908: The PR addresses #8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the assert, so any discrepancy should be caught on canary nodes.
nikurt
pushed a commit
that referenced
this issue
Apr 18, 2023
This PR re-introduces changes from #8805 together with #8892 after fixing #8908: The PR addresses #8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the assert, so any discrepancy should be caught on canary nodes.
nikurt
pushed a commit
that referenced
this issue
Apr 18, 2023
This PR re-introduces changes from #8805 together with #8892 after fixing #8908: The PR addresses #8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the assert, so any discrepancy should be caught on canary nodes.
nikurt
pushed a commit
that referenced
this issue
Apr 25, 2023
This PR re-introduces changes from #8805 together with #8892 after fixing #8908: The PR addresses #8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the assert, so any discrepancy should be caught on canary nodes.
nikurt
pushed a commit
that referenced
this issue
Apr 25, 2023
This PR re-introduces changes from #8805 together with #8892 after fixing #8908: The PR addresses #8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the assert, so any discrepancy should be caught on canary nodes.
nikurt
pushed a commit
that referenced
this issue
Apr 28, 2023
feature: Limit compute usage of a chunk The commit addresses #8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the `assert`, so any discrepancy should be caught on canary nodes. There are two follow-ups to this work: - #8859 - #8860
nikurt
pushed a commit
that referenced
this issue
Apr 28, 2023
This PR re-introduces changes from #8805 together with #8892 after fixing #8908: The PR addresses #8265 by introducing aggregation of compute usage across all operations performed during chunk application and limiting this compute usage to 1s. This should not change the behavior of nodes in the short run because compute costs match gas costs which is validated by the assert, so any discrepancy should be caught on canary nodes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Update the calculation for when a chunk is full in terms of gas.
This has to be backwards-compatible. That is, old protocol versions must not change their behavior. A protocol feature flag will have to be introduced, if it has not bee n added before.
To enable this, we also need to track weight-adjusted gas. We might want to name it something more distinct, to avoid confusion between already existing terms of gas, such as "used gas", "burned gas", "prepaid gas", "attached gas". Fumes as a new terms has come up in discussions. Maybe we can find something better.
The text was updated successfully, but these errors were encountered: