FuelLabs
Serialization and encoding/decoding
Binary encoding of arbitrary sway values is a necessary feature, notably to return values/pass values to contracts in a predictable, portable fashion.
This is tricky and solidity has had to go through multiple versions of it but we can borrow from their encoding scheme.
This should take versioning into account, as we'll likely want to make alterations to this scheme in the future.
We should also consider options for packing the data (such as Solidity's strict mode).
We should also consider the ergonomics of how to use it in the language, a trait based approach seems natural but we don't have derive macroes so having people implement a trait could prove tedious. We may want to rely on intrinsics to make the interface nicer.
- [x] #5312
- [ ] #5512
- [ ] #5513
- [ ] #5514
- [x] #5507
After some investigation, it looks like the current way our encoding works is different for input and output.
Input values are directly usable and pointer values are populated with correct memory offsets so they can be directly used.
Output values are fully dereferenced and contain no indirection, which means it's hard/impossible to nest them. Any dynamically sized return value will have to be named last and can't have siblings because it will consume the entire rest of the buffer when decoding.
Note that these two encodings are not compatible with each other, which we'll definitely want to solve.
What we should do instead is similar to Solidity's encoding scheme: split the encoded buffer into two regions, one for inline bytes and the other for dynamic data, and have all pointers values be encoded inline with pointer values that are offsets of the beginning of the data region.
Then, in Sway, for both inputs and outputs, we should parse these into proper pointers for inputs, and generate proper data section offsets for outputs.
There is a practical issue here in that the test frameworks for sway and fuels-rs are both dependent on each other, and changing this serialization will require a breaking change of both. We'll have to figure out how to choreograph this. Likely by bypassing one of the test suites after we've manually confirmed the first change works on the updated version of the other repository.
