FuelLabs
Blob tx and instructions
Work towards https://github.com/FuelLabs/fuel-specs/issues/589. The VM PR https://github.com/FuelLabs/fuel-vm/pull/780 contains a working implementation.
To allow contracts larger than the contract size limit, and to allow upgradability, we'll be adding a new tx type that's just a bunch of bytes, and opcodes to load subsections of that. A blob will be like a contract, but without state or balances, allowing it to be quite a bit cheaper. The new instructions BSIZ and BLDD closely follow how CSIZ, LDC and CCP work, but only operation on blob data.
To allow code loading, this PR lifts the restriction that only code between $is..$ssp is executable, and instead allows execution between $is..$sp. This means code can be dynamically to stack using, i.e. cfe and the new bldd, and executed.
The primary design considerations are listed in the fuel-vm PR, but to repeat them here:
- Should
BSIZcharge dependent on size?- This is more of an implementation detail, and should be discussed in the vm pr.
Before requesting review
- [ ] I have reviewed the code myself
I know it's bikeshedding but can we call it something other than "blob"? It evokes either object based storage or proprietary binaries in kernel land. What this really is is an executable.
I know it's bikeshedding but can we call it something other than "blob"? It evokes either object based storage or proprietary binaries in kernel land. What this really is is an executable.
From vm and storage layer perspective, this is just an opaque bytearray, addressed by hash. The executability is just a nice side effect of the generic design, although it's also the main purpose for introducing this.
it's also the main purpose for introducing this
That's my point really. Clarity of intent. I understand that this is just a distributed byte array. But it's not meant to store things, it's meant to store code that will be executed.
"Executable" might not be a good name for it since it is not guaranteed to be a whole executable.
Really it's just a bunch of loadable bytecode. "Chunk" maybe?
@Dentosal should this PR also include the changes to the LDC opcode?
Yes. They were not originally included as it was unclear whether we would have them in LDC or a separate instruction, but it seems like we have converged on LDC. The new changes are included in 71f7462.