SIMD-0295: Relax CU limit overage #295

tao-stones · 2025-06-04T17:02:30Z

No description provided.

t-nelson · 2025-06-04T18:11:14Z

proposals/0295-block-limits-overage-relaxation.md

+  - Treat the block as committed but stateless — no accounts are modified, no
+    fee collected, no nonce advanced if apply.
+  - Maintain consensus liveness and ledger continuity.
+


how does succeeding block poh work with a skipped block parent? am i treating this the same as a skipped slot and basing/ticking of the skipped block's parent or is there some new behavior?

Great question! I don't have good answer. Scanning through code for skip slot logic, I feel same can be applied to Skipped block - its PoH Hashes should also be skipped, its child slot should based on Skipped block's parent. wdyt @MaxResnick ?

This feature is to be activated after alpenglow, at which point, PoH is no more.

IIRC the idea is that this is treated the same from PoH perspective as a normal (not skipped) slot. PoH isn't rolled back, only the state changes are.

Agreed, this should be treated as a normal block wrt PoH otherwise we need to modify tick verification for child blocks.

Ok, added "to advance poh and tick count".

How about slot_history sysvar? stateless block does not committing any account state changes, means its slot is not added to slot_history. Will this impact vote or fork choice?

I would expect we still populate the minimal account changes in new_from_parent, namely the sysvars / feature flags / rewards etc. If the SlotHistory sysvar is not populated then this will break TowerBFT voting in subsequent slots.

What I would expect in the implementation is the bank is dropped once the CU limit is hit, we create a new empty bank as if we are planning to replay, and then immediately set the tick height to max (assuming tick verify is successful).

t-nelson · 2025-06-04T18:13:21Z

proposals/0295-block-limits-overage-relaxation.md

+## Backwards Compatibility
+
+This proposal changes validator replay logic, should be controlled behind a
+feature gate, activated only when async execution is enabled.


so this activates with asynce execution, not before?

does that make alpenglow a prereq?

if not, how does voting on a skipped block work? presumably i should be locked out of voting similarly to voting down a wrong fork

Current plan is to get implementation ready behind feature gate, but wait for alpenglow to go out first, then flip the async flag.

This feature flag and the remove bankhash from block id (not yet finished) should be activated after alpenglow rolls out. The other SIMDS:

relax nonce

relax fee payer

relax ALT

include bank hash verification in block header

Should all be flipped whenever they are done (before alpenglow ideally).

Is there a specific reason to block this by alpenglow? Without async there's no benefit to this, but there's also afaict not a downside except the risk of activation, which is there regardless of when we activate.

I think the reason to wait would be to avoid handling the complexity of POH interactions

We don't need to do anything for poh though, right?

It should be fine to turn this on before alpenglow, voting will treat this as a regular block, the only difference is that replay views this as an empty 0 transaction bank.

There should be no change to PoH, the ticks from this empty bank should still be verified as normal, it is still a part of the finalized ledger.

MaxResnick · 2025-06-04T21:48:48Z

Can we change the name to Relax CU limit overage to match the other SIMD title formats.

ptaffet-jump · 2025-06-05T16:56:42Z

A replayer can know whether a block's total requested CUs exceeds the block limits without executing the transactions. What about using that instead? A block is marked as dead if its total requested CUs exceeds the block limits. Assuming #172 does what it's supposed to do, this shouldn't be as big of a deal.

MaxResnick · 2025-06-06T22:28:28Z

A replayer can know whether a block's total requested CUs exceeds the block limits without executing the transactions. What about using that instead? A block is marked as dead if its total requested CUs exceeds the block limits. Assuming #172 does what it's supposed to do, this shouldn't be as big of a deal.

I would love to get to requested CU as well. The only issue that @apfitzge raised with ALT is it would be difficult to check the per account CU limits. This change works well for per account CU limits and It would be a shame to lose the throughput of used CU limit if it doesn't work for both block level and per account CU limits.

proposals/0295-block-limits-overage-relaxation.md

apfitzge · 2025-06-18T17:10:44Z

A replayer can know whether a block's total requested CUs exceeds the block limits without executing the transactions. What about using that instead? A block is marked as dead if its total requested CUs exceeds the block limits. Assuming #172 does what it's supposed to do, this shouldn't be as big of a deal.

I would love to get to requested CU as well. The only issue that @apfitzge raised with ALT is it would be difficult to check the per account CU limits. This change works well for per account CU limits and It would be a shame to lose the throughput of used CU limit if it doesn't work for both block level and per account CU limits.

It's not so much about difficult to check the per account CU limits; it's impossible without loading some account state. To validate block N we wouldn't need to execute block N, but we'd need to have executed up to block N-1 (or whatever parent is) in order to know the state of ALTs at the beginning of block N, since ALT lookups are "frozen" at state at the start of each slot.

MaxResnick · 2025-06-30T18:57:19Z

A replayer can know whether a block's total requested CUs exceeds the block limits without executing the transactions. What about using that instead? A block is marked as dead if its total requested CUs exceeds the block limits. Assuming #172 does what it's supposed to do, this shouldn't be as big of a deal.

I would love to get to requested CU as well. The only issue that @apfitzge raised with ALT is it would be difficult to check the per account CU limits. This change works well for per account CU limits and It would be a shame to lose the throughput of used CU limit if it doesn't work for both block level and per account CU limits.

It's not so much about difficult to check the per account CU limits; it's impossible without loading some account state. To validate block N we wouldn't need to execute block N, but we'd need to have executed up to block N-1 (or whatever parent is) in order to know the state of ALTs at the beginning of block N, since ALT lookups are "frozen" at state at the start of each slot.

But still the static check requires us to load all ALTs before voting which seems not ideal.

AshwinSekar · 2025-07-29T18:40:04Z

proposals/0295-block-limits-overage-relaxation.md

+  - Treat the block as committed but stateless — no accounts are modified, no
+    fee collected, no nonce advanced if apply.
+  - Maintain consensus liveness and ledger continuity.
+


Agreed, this should be treated as a normal block wrt PoH otherwise we need to modify tick verification for child blocks.

AshwinSekar · 2025-07-29T18:41:47Z

proposals/0295-block-limits-overage-relaxation.md

+## Backwards Compatibility
+
+This proposal changes validator replay logic, should be controlled behind a
+feature gate, activated only when async execution is enabled.


It should be fine to turn this on before alpenglow, voting will treat this as a regular block, the only difference is that replay views this as an empty 0 transaction bank.

There should be no change to PoH, the ticks from this empty bank should still be verified as normal, it is still a part of the finalized ledger.

AshwinSekar · 2025-07-29T18:44:50Z

proposals/0295-block-limits-overage-relaxation.md

+Change the block CU validation logic during replay as follows:
+
+- If a block exceeds the Block CU limit during replay execution:
+  - Stop execution of remaining transactions in the block, and rollback all


Alpenglow has a similar construct where a block can become stateless midway (and later restarted off a different parent). I don't think this validation logic will interfere, just something to note.

tao-stones added 2 commits June 4, 2025 12:01

draft

4536d7c

update simd number

68143f1

tao-stones marked this pull request as ready for review June 4, 2025 17:04

t-nelson reviewed Jun 4, 2025

View reviewed changes

tao-stones changed the title ~~Block CU limits overage relaxation~~ SIMD-0295: Block CU limits overage relaxation Jun 4, 2025

tao-stones changed the title ~~SIMD-0295: Block CU limits overage relaxation~~ SIMD-0295: Relax CU limit overage Jun 5, 2025

change title

7836aa2

github-actions bot mentioned this pull request Jun 9, 2025

Upstream Updates - Mon Jun 9 00:17:51 UTC 2025 smartcontractkit/chainlink-solana#1265

Closed

apfitzge reviewed Jun 18, 2025

View reviewed changes

proposals/0295-block-limits-overage-relaxation.md Outdated Show resolved Hide resolved

MaxResnick mentioned this pull request Jul 18, 2025

Roadmap: Async Execution #324

Open

AshwinSekar reviewed Jul 29, 2025

View reviewed changes

tao-stones added 2 commits July 31, 2025 10:50

change term to Stateless Block

92bc574

clarify stateless block will continue advance poh and tick count

21bdbd7

SIMD-0295: Relax CU limit overage #295

Are you sure you want to change the base?

SIMD-0295: Relax CU limit overage #295

Uh oh!

Conversation

tao-stones commented Jun 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tao-stones Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MaxResnick commented Jun 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ptaffet-jump commented Jun 5, 2025

Uh oh!

MaxResnick commented Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

apfitzge commented Jun 18, 2025

Uh oh!

MaxResnick commented Jun 30, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tao-stones Jun 5, 2025 •

edited

Loading

MaxResnick commented Jun 4, 2025 •

edited

Loading

MaxResnick commented Jun 6, 2025 •

edited

Loading