Skip to content
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.

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

Program-Runtime v2 - Road Map #28755

Open
Lichtso opened this issue Nov 6, 2022 · 7 comments
Open

Program-Runtime v2 - Road Map #28755

Lichtso opened this issue Nov 6, 2022 · 7 comments
Labels
enhancement New feature or request runtime Issues related to runtime, BPF, and LLVM work in progress This isn't quite right yet

Comments

@Lichtso
Copy link
Contributor

Lichtso commented Nov 6, 2022

The performance optimizations we have been working on inside the runtime under the ABIv2 project the past year will be deployed separately as "account data direct mapping". The redesign of the ABI between runtime and on-chain program is pushed out further as we changed the goals again.

Presentations

Tasks

@Lichtso Lichtso added enhancement New feature or request work in progress This isn't quite right yet runtime Issues related to runtime, BPF, and LLVM labels Nov 6, 2022
@Lichtso Lichtso changed the title ABIv2 road map Program-Runtime v2 - Road Map Nov 17, 2022
@austbot
Copy link

austbot commented Jan 20, 2023

This is amazing!

A few questions:
1 is this the issue to discuss?
2. "Replace VM nesting by dynamic linking using two levels of indirection" does this make CPI less expensive since the entire account context doesn't need to be cloned for the CPI execution?
3. With multiple entry points can those entrypoints return data to the client on an outer instruction?

@leoluk
Copy link
Contributor

leoluk commented Jan 20, 2023

Share the host address space for all programs in a transaction (similar to Native Client)

How will isolation work? Will the verifier enforce it?

@alessandrod
Copy link
Contributor

This is amazing!

A few questions: 1 is this the issue to discuss?

This is a meta-tracking issue we created after talks at breakpoint. Input is of course welcome, here and on discord in the #virtual-machine channel. Going forward we should probably create separate issues for sub features tho or this is likely going to get out of hand.

  1. "Replace VM nesting by dynamic linking using two levels of indirection" does this make CPI less expensive since the entire account context doesn't need to be cloned for the CPI execution?

The account clone issue is already going away Real Soon Now (tm) with the existing runtime: #28755. The other large issue of creating nested VMs (what the current runtime does during CPI) will go away with v2. Both will reduce the cost of doing CPI yes.

  1. With multiple entry points can those entrypoints return data to the client on an outer instruction?

If you mean if callees will be able to return data to their callers the answer is yes - one of the goals of this work is to improve the sdk ergonomics, so that you'll be able to "just call some functions" without the runtime getting in the way.

@Lichtso
Copy link
Contributor Author

Lichtso commented Jan 20, 2023

  1. With multiple entry points can those entrypoints return data to the client on an outer instruction?

I understand the question being about the client, the one off chain which triggers the transaction via RPC. If that is the question then, no or at least that is outside of the scope of the program runtime and has to do with networking. It is tricky because the process is asynchronous in the sense that submitting a transaction and polling for its completion (including its possible results) are independent flows. In other words, in the program runtime we could return the return value of the last instruction in a transaction (or something along these lines), but it would not be propagated anywhere. That requires additional infrastructure outside of the program-runtime.

@Lichtso
Copy link
Contributor Author

Lichtso commented Jan 20, 2023

How will isolation work? Will the verifier enforce it?

@leoluk Yes, that is the plan. On deployment the verifier would do type inference for the entire instruction stream and could then find any misbehaving memory accesses before execution. For dynamic offsets / indices we would check that the correct (canonical) bounds checks are in the instruction stream as well.

@mschneider
Copy link
Contributor

Looks like a good change. Can you include the planned security process for this redesign in the roadmap?

@chen-robert
Copy link

On deployment the verifier would do type inference for the entire instruction stream and could then find any misbehaving memory accesses before execution. For dynamic offsets / indices we would check that the correct (canonical) bounds checks are in the instruction stream as well.

Sounds like fun

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request runtime Issues related to runtime, BPF, and LLVM work in progress This isn't quite right yet
Projects
Status: No status
Development

No branches or pull requests

6 participants