Program-Runtime v2 - Road Map

[Lichtso]

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

• Slides from 2023/01/20
• Slides from 2023/08/15
• Breakpoint 2023/11/01

Tasks

• [x] #29803
  • [x] #29654
  • [x] #30154
  • [x] #30139
  • [x] #30282
  • [x] #30336
  • [x] #30337
  • [x] #30348
  • [x] #30371
  • [x] #30275
  • [x] #30425
  • [x] #30803
  • [x] #30900
  • [x] #30902
  • [x] #30561
  • [x] #30703
  • [x] #30900
  • [x] #30902
  • [x] #30940
  • [x] #30945
  • [x] #30950
  • [x] #30959
  • [x] #31034
  • [x] #31036
  • [x] #31116
  • [x] #31118
  • [x] #31142
  • [x] #31311
  • [x] #31331
  • [x] #31395
  • [x] #31413
  • [x] #31465
  • [x] #31493
  • [x] #31494
  • [x] #31501
  • [x] #31530
  • [x] #31537
  • [x] #31547
  • [x] #31548
  • [x] #31566
  • [x] #31577
  • [x] #31604
  • [x] #31654
  • [x] #31684
  • [x] #31718
  • [x] #31727
  • [x] #31735
  • [x] #31792
  • [x] #31886
  • [x] #31922
  • [x] #31927
  • [x] #31929
  • [x] #31945
  • [x] #31953
  • [x] #31991
  • [x] #32146
  • [x] #32722
  • [x] #32999
  • [x] #33025
  • [x] #33477
  • [x] #33482
  • [x] #33694
  • [ ] #33715
  • [x] #33776
  • [x] #33808
  • [x] #33810
  • [x] #34100
• [ ] #20323
  • [x] https://github.com/solana-labs/rbpf/pull/454
  • [x] https://github.com/solana-labs/rbpf/pull/460
  • [x] https://github.com/solana-labs/rbpf/pull/481
  • [x] https://github.com/solana-labs/rbpf/pull/486
  • [x] https://github.com/solana-labs/rbpf/pull/488
  • [x] https://github.com/solana-labs/rbpf/pull/489
  • [x] https://github.com/solana-labs/rbpf/pull/491
  • [x] https://github.com/solana-labs/rbpf/pull/493
  • [x] https://github.com/solana-labs/rbpf/pull/496
  • [x] https://github.com/solana-labs/rbpf/pull/498
  • [ ] #32924
  • [ ] #33971
• [ ] #29863
• [x] #29864
  • [x] #29728
  • [x] #30579
  • [x] #30614
  • [x] #30464
  • [x] #30693
  • [x] #30893
  • [x] #31007
  • [x] #31088
  • [x] #31244
  • [x] #31221
  • [x] #31244
  • [x] #31324
  • [x] #31329
  • [x] #31345
  • [x] #31429
  • [x] #31488
  • [x] #31570
  • [x] #31943
  • [x] #31594
  • [x] #32812
  • [x] #32832
  • [x] #33151
  • [x] #33167
  • [x] #33228
  • [x] #33278
  • [x] #33279
  • [x] #33289
  • [x] #33294
  • [x] #33554
  • [x] #33570
  • [x] #33583
  • [x] #33628
  • [x] #33629
  • [x] #33666
  • [x] #33681
  • [x] #33693
  • [x] #33711
  • [x] #33759
  • [x] #33805
  • [x] #33849
  • [x] #33867
  • [x] #33879
  • [ ] Fix transitive cargo dependencies
• [x] #32154
• [Not MVP] Adjust other built-in programs and the testing framework

[austbot]

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]

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]

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.

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?

The account clone issue is already going away Real Soon Now (tm) with the existing runtime: https://github.com/solana-labs/solana/issues/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.

3. 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]

3. 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]

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]

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

[chen-robert]

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