As a new contributor, I’m currently getting familiar with the grin and grin-wallet codebases by working on an assortment of PRs and issues.
Since posting an initial funding request at the end of March, I’ve been working on the items below. As April progresses, I expect to make 2-3 additional progress reports in this thread.
Over the past 10 days, I’ve primarily worked on three projects:
A config file versioning scheme
To unblock implementation of the fix past fees RFC, we needed a principled way of versioning and updating the configuration file format without disturbing any custom edits or comments that the user may have made. This is a tricky problem, because TOML can express the same data structure in multiple format variants, and the toml crate does not have any functionality for updating a file’s data while preserving user comments, only full serializing and deserializing.
The chosen solution is to apply naive textual replacements to the file, while also making semantic edits to the struct that the file is deserialized into. After the edits are symmetrically applied to both forms, we re-read the TOML to ensure that it parses without error and produces the expected struct result. This can fail and error out if the user has made heavy edits to the file, but if it succeeds, the file is guaranteed to be correct.
This solution also suggests a straightforward templated approach to applying any necessary future config file changes.
Migrating from deprecated failure crate for error handling
Assessed the feasibility of this migration by removing failure and re-implementing error handling with the thiserror crate. Successfully performed the replacement, which passes all tests. There are some subtleties regarding differences in how failure and thiserror handle reporting error context information that I’ll clean up in the coming weeks. This also needs solid review notes to make for an easier code review due to the number of changes involved.
Formal specification & verified implementation of bulletproofs
This is a longer-term project that has important implications for our confidence in chain integrity. The general idea is to develop a clear, concise formal specification or implementation of bulletproofs that can be easily compared against the bulletproofs paper, and run as a parallel implementation to help mitigate any potential exploitable errors in the primary bulletproofs implementation.
There’s some behind-the-scenes work going on here that I’ll hopefully be able to share soon.
