SIMD-0177: Program Runtime ABI v2 #177
Conversation
Lichtso
force-pushed
the
program-runtime-abiv2
branch
from
ae4514d
to
7148fdf
Compare
| - Readonly instruction accounts get no growth padding. | ||
| - For writable instruction accounts additional capacity is allocated and mapped | ||
| for potential account growth. The maximum capacity is the length of the account | ||
| payload at the beginning of the transaction plus 10 KiB. CPI can not grow |
There was a problem hiding this comment.
does this get affected by this other SIMD?
https://github.com/solana-foundation/solana-improvement-documents/pull/163/files
There was a problem hiding this comment.
They are independent. SIMD-0163 is about the program being called, that is not affected in this SIMD.
There was a problem hiding this comment.
@nickfrosty Fwiw, this means the realloc limit is unchanged as well.
There was a problem hiding this comment.
We could increase the account realloc / resize limit if there are no interactions of ABI v0/v1 and ABI v2 programs in the CPI call tree of a top level instruction. See the discussion with Sean below.
| each starting at a 4 GiB boundary in virtual address space: | ||
|
|
||
| - Writable header: | ||
| - Magic: `u32`: `0x41424976` |
There was a problem hiding this comment.
For programs to differentiate it from ABI v0 and v1. See "Backwards Compatibility".
Lichtso
force-pushed
the
program-runtime-abiv2
branch
from
7148fdf
to
375deef
Compare
| SDKs will have to support both ABI v1 and v2 for a transition period. The | ||
| program runtime must only use ABI v2 if all programs in a transaction support | ||
| it. Programs signal their support through their SBPF version field (TBD) while |
There was a problem hiding this comment.
| The program runtime must only use ABI v2 if all programs in a transaction support it.
Why this restriction? It's possible to execute some programs with direct mapping and others without in the same transaction.
There was a problem hiding this comment.
Yes, technically the restriction could be relaxed to be within the CPI tree of one top-level instruction to prevent caller and callee from having different ABI versions. However, unlike all programs in a transaction, we don't know what is going to be called in CPI beforehand.
There was a problem hiding this comment.
My point is: why prevent caller and callee from having different ABI versions.
I meant to say that it is possible to execute some programs with direct mapping and some without, within the same instruction/CPI tree.
Sure that needs some refactoring in agave, but it might be worth it.
There was a problem hiding this comment.
Our implementation of direct mapping is explicitly built on the assumption that caller and callee both use or not use direct mapping. Mixing them would lead to trouble e.g. in account payload reallocation.
Lichtso
force-pushed
the
program-runtime-abiv2
branch
from
375deef
to
1057208
Compare
Lichtso
force-pushed
the
program-runtime-abiv2
branch
from
1057208
to
51f9f75
Compare
Lichtso
force-pushed
the
program-runtime-abiv2
branch
3 times, most recently
from
afd244e
to
caa91dd
Compare
Lichtso
force-pushed
the
program-runtime-abiv2
branch
from
caa91dd
to
6b641c8
Compare
No description provided.