Skip to content

SIMD-0268: Raise CPI Nesting Limit #268

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.

Sign up for GitHub

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

Merged
jacobcreech merged 2 commits into from
Aug 1, 2025
Merged

SIMD-0268: Raise CPI Nesting Limit #268

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f6a888a
First draft
Lichtso Feb 22, 2025
c7f2448
Update status and requirements.
Lichtso Jun 13, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions proposals/0268-raise-cpi-nesting-limit.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
simd: '0268'
title: Raise CPI Nesting Limit
authors:
- Alexander Meißner
category: Standard
type: Core
status: Accepted
created: 2025-03-26
feature: 6TkHkRmP7JZy1fdM6fg5uXn76wChQBWGokHBJzrLB3mj
extends: SIMD-0219
---

## Summary

Increase the maximum number of nested CPI calls.

## Motivation

The complexity of dApp interoperation is limited by how many programs can call
into one another.

## New Terminology

None.

## Detailed Design

Once the associated feature gate is activated the maximum nesting depth of CPI
calls must be changed from 4 to 8. This feature should only be activated after
SIMD-0219.

## Alternatives Considered

None.

## Impact

Exisiting dApps will not be affected as long as they don't depend on this limit
in their logic to fail transactions, which is unlikely.

## Security Considerations

None.

## Drawbacks

The maximum amount of VMs stack and heap memory, which needs to be reserved and
zeroed out, would double.
Comment on lines +46 to +49
Copy link
Copy Markdown
Contributor

@buffalojoec buffalojoec Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we know what the hardware implications are here? Negligible?

Copy link
Copy Markdown
Contributor Author

@Lichtso Lichtso Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would only activate this after #219, which should free up a lot of memory and zeroing bandwidth.

Copy link
Copy Markdown
Contributor

@buffalojoec buffalojoec Jun 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we should probably gather some kind of benchmark to make sure. In theory this means the upper bound of entire execution memory throughput is doubled across the entire node. We don't want anyone getting DoS'ed.

Copy link
Copy Markdown
Contributor Author

@Lichtso Lichtso Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not allow one to execute more instructions per transaction, the limit there stays 64. And the processing power and memory bandwidth needed are the same, no matter if instructions in a transaction are sequential or nested.

Thus, the only thing this really raises is the amount of total memory allocated simultaneously (peak can be higher if instructions are nested). But the interaction with that memory stays the same; the VM just needs to "remember" more context.

Copy link
Copy Markdown
Contributor

@Benhawkins18 Benhawkins18 Jun 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Lichtso can you update the SIMD to reflect the requirements of going in after 219 is activated and direct mapping is activated?

While you are at it can you update the meta data to status "accepted" and add a feature flag is possible?

Copy link
Copy Markdown
Contributor

@buffalojoec buffalojoec Jun 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thus, the only thing this really raises is the amount of total memory allocated simultaneously (peak can be higher if instructions are nested). But the interaction with that memory stays the same; the VM just needs to "remember" more context.

But do we know the actual specifications of this? In other words, can we feasibly state that if someone does 64 instructions in a single transaction through 8 instructions (nested to 8 frames each) to some super large program every time, they won't blast a node's memory?

I suppose we can scratchpad it a bit. We have a stack, heap, input region, and program section, and you'd just multiple those by 8, right?

Copy link
Copy Markdown
Contributor Author

@Lichtso Lichtso Jun 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, you can already have 4 VMs simultaneously (via CPI nesting) so a step up to 8 is only doubling it. The program section is allocated per executable, not per VM. And the input region will be a whole lot smaller once #219 (direct mapping) is active. Thus, only the stack and heap memory allocation would double.

Copy link
Copy Markdown
Contributor

@buffalojoec buffalojoec Jun 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a step up to 8 is only doubling it

When it comes to memory, doubling anything is always something to consider carefully.

I ran a little experiment, and put my findings in the root discussion for anyone who wants to check this SIMD out in the future.

Loading