Blob tx and instructions #592
Conversation
|
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. |
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? |
Work towards FuelLabs/fuel-specs#589. Spec PR FuelLabs/fuel-specs#592. Adds support for Blob transactions, which are inserted into the onchain database column called `Blobs`. Also updates fuel-vm to 0.56.0, which introduces the new tx type. Work-in-progress, still needs: - [x] Regenesis support - [x] Tests ## Checklist - [x] Breaking changes are clearly marked as such in the PR description and changelog - [x] New behavior is reflected in tests ### Before requesting review - [x] I have reviewed the code myself - [x] I have created follow-up issues caused by this PR and linked them here ### After merging, notify other teams - [ ] [Rust SDK](https://github.com/FuelLabs/fuels-rs/) - [ ] [Sway compiler](https://github.com/FuelLabs/sway/) - [ ] [Platform documentation](https://github.com/FuelLabs/devrel-requests/issues/new?assignees=&labels=new+request&projects=&template=NEW-REQUEST.yml&title=%5BRequest%5D%3A+) (for out-of-organization contributors, the person merging the PR will do this) --------- Co-authored-by: Ahmed Sagdati <[email protected]> Co-authored-by: segfault-magnet <[email protected]>
Work towards #589. The VM PR FuelLabs/fuel-vm#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
BSIZandBLDDand the new blob mode forLDCclosely follow howCSIZ,LDCandCCPwork, but only operation on blob data.Before requesting review