Closed wu-s-john closed 2 years ago
Apparently, we can't use a GADT directly with bin_io
. I see the error message:
GADTs are not supported by bin_prot
I do see the hack that we have for the transition frontier persistence, invoking %bin_type_class
.
But also:
GADTs are not supported by comparelib
from deriving compare
.
If we did use a GADT, the type would have a parameter to distinguish validated/unvalidated signatures. That doesn't play well with the versioning system as it is now.
Do we have any reason to (de)serialize commands that we don't know are valid?
Closing this issue as it is stale
for a long time.
Right now, we represent unvalidated and validated User_commands as
User_command.t
andUser_command.With_valid_signature.t
.It would be useful to have this be represented as a GADT. So, it would look something like this:
This would make the
staged_ledger_diff
code less verbose. It would avoid having extra modules that represent a level of validation. For example, it can remove the need for having the module,With_valid_signatures_and_proofs
.The
staged_ledger_diff
type can be represented as something like:Having this can ultimately make the Staged_ledger code more expressive and concise. There are some functions in the module that have similar flow structures, but are created differently to handle fully validated and unvalidated
staged_ledger_diffs
s.This refactoring could combine functions like
apply
andapply_diff_unchecked
into one function.