The FVM must parse IPLD blocks created by actors for:
- Validation.
- State traversal.
- Reachability analysis.
However, the FVM must be able to charge for IPLD parsing/validation operations proportional to the complexity of the IPLD block.
Furthermore, there are a few risks:
- Any bugs (recursion issues, etc.) in the IPLD codec implementation could crash the network. Once we allow for user specified IPLD data-structures, this becomes a real issue.
- All FVM implementations must implement IPLD codecs identically, rejecting and allowing the same blocks.
We can solve the core issue (charging for compute) by creating a "canonical" parsing algorithm for each IPLD codec we support, and defining gas charges for parsing said format. However, said algorithm is going to be tricky, and any deviations in any implementations will lead to forks.
A more robust solution would be to compile each codec to WASM, and perform all decoding inside said WASM module. This is robust against both the bug risk (bad IPLD would crash the WASM module, leading us to treat it as invalid) and different implementations (all FVM implementations would use the same codec). However, a WASM module may increase gas costs to the point where the added complexity of parsing blocks natively is worth it.
NOTE: A link database (#103) would make this choice much simpler as we'd only have to parse blocks on store, instead of both on store and on load.
The FVM must parse IPLD blocks created by actors for:
However, the FVM must be able to charge for IPLD parsing/validation operations proportional to the complexity of the IPLD block.
Furthermore, there are a few risks:
We can solve the core issue (charging for compute) by creating a "canonical" parsing algorithm for each IPLD codec we support, and defining gas charges for parsing said format. However, said algorithm is going to be tricky, and any deviations in any implementations will lead to forks.
A more robust solution would be to compile each codec to WASM, and perform all decoding inside said WASM module. This is robust against both the bug risk (bad IPLD would crash the WASM module, leading us to treat it as invalid) and different implementations (all FVM implementations would use the same codec). However, a WASM module may increase gas costs to the point where the added complexity of parsing blocks natively is worth it.
NOTE: A link database (#103) would make this choice much simpler as we'd only have to parse blocks on store, instead of both on store and on load.