Skip to content

Tracking issue: productionize the jmt crate #103

Open
@erwanor

Description

@erwanor

The JMT is in a good place in terms of features and has been battle-tested by frequent usage from both penumbra labs testnets and active development by sovereign labs.

However, there are still a number of holdovers from its previous usage in the Diem codebase, incomplete documentation, and inconsistent internal nomenclature around proof usage and generation. This has led to a number of bugs: #96, and more recently #100, and brings in higher technical risk when implementing new features (like update proofs #97), and optimizations like the batching API that sovereign is working on.

  • jmt: remove obsolete leaf migration api
  • jmt: remove obsolete fuzzing feature
  • jmt: remove obsolete access path
  • jmt: document ics23 proof generation
  • jmt: document how update proofs work
  • jmt: document the basic mechanics of leaf insertion
  • jmt: refactor the leaf creation api
  • jmt: improve the leaf creation documentation
  • jmt: add CHANGELOG.md
  • jmt: fix expect statements
  • jmt: use Result<Option> for internal and outside apis
  • jmt: consider testing coverage tools

The refactor tasks should focus on normalizing the internal nomenclature and improve the usage of idiomatic rust within the codebase. For example, the recursive routines frequently alias method arguments with routine-specific values that are semantically different. This seem to be done correctly for the most part, but is hard to read for no reason.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions