Deploying testing workloads currently requires setting up a Nyx share directory, manually copying binaries and using lddtree to discover and copy all shared library dependencies. This approach is tightly coupled to bitcoind, error-prone, and makes it difficult to integrate other projects.
We could replace the binary-based setup with a container-based approach where we package testing workloads as OCI containers. The share directory would contain the container archive (tarball), and extraction happens inside the Nyx VM during boot.
Potential workflow:
- User builds/pulls a container image (this image contains testing scenario and target applications).
fuzzamoto-cli init --share-dir <dir> --image <image> saves the container as a tarball in the share directory (perhaps we could even get rid of the init command for fuzzamoto-libafl and have it take the container directly).- The VM boot script extracts the container tarball and runs the workload
- (hopefully) No container runtime is needed inside the VM, just tar extraction and
chroot
This is much simpler than the current approach: instead of discovering dependencies and copying individual files, we copy one tarball and extract it in the VM. Besides being much simpler, it eases the integration of new targets (alternative full node implementations, Lightning nodes, ...) and allows scenarios to be written in any language.
Deploying testing workloads currently requires setting up a Nyx share directory, manually copying binaries and using
lddtreeto discover and copy all shared library dependencies. This approach is tightly coupled to bitcoind, error-prone, and makes it difficult to integrate other projects.We could replace the binary-based setup with a container-based approach where we package testing workloads as OCI containers. The share directory would contain the container archive (tarball), and extraction happens inside the Nyx VM during boot.
Potential workflow:
fuzzamoto-cli init --share-dir <dir> --image <image>saves the container as a tarball in the share directory (perhaps we could even get rid of the init command forfuzzamoto-libafland have it take the container directly).chrootThis is much simpler than the current approach: instead of discovering dependencies and copying individual files, we copy one tarball and extract it in the VM. Besides being much simpler, it eases the integration of new targets (alternative full node implementations, Lightning nodes, ...) and allows scenarios to be written in any language.