From troy sargent:
As an example of Agave vs Firedancer fuzzing, you can see they define Rust and C definitions for sol_compat_txn_execute_v1. The fuzzer loads both as a shared object, passes the same input, and diffs the protobuf result returned.For instance, the input TxnContext protobuf could probably be converted into e.g. ImmutableDeserializedPacket and test parse_deserialized_batch convert ParsedBatch into a shared protobuf that can be diffed.
https://github.com/jito-labs/bam-client/blob/6297a28fb519e160b44a25707673f7f759d2f[…]c/banking_stage/transaction_scheduler/bam_receive_and_buffer.rsThat's one example but the approach can be taken for any duplicated logic that is expected to match (ideally relatively stateless and not relying on a ton of threads). However, new input types may require more development to generate and mutate structures that get deep into the code (TxnContext input is already supported by the fuzzer)
From troy sargent:
As an example of Agave vs Firedancer fuzzing, you can see they define Rust and C definitions for sol_compat_txn_execute_v1. The fuzzer loads both as a shared object, passes the same input, and diffs the protobuf result returned.For instance, the input TxnContext protobuf could probably be converted into e.g. ImmutableDeserializedPacket and test parse_deserialized_batch convert ParsedBatch into a shared protobuf that can be diffed.
https://github.com/jito-labs/bam-client/blob/6297a28fb519e160b44a25707673f7f759d2f[…]c/banking_stage/transaction_scheduler/bam_receive_and_buffer.rsThat's one example but the approach can be taken for any duplicated logic that is expected to match (ideally relatively stateless and not relying on a ton of threads). However, new input types may require more development to generate and mutate structures that get deep into the code (TxnContext input is already supported by the fuzzer)