Closed tilacog closed 2 years ago
Maybe there is a way to extract that functionality from the Epoch Subgraph codebase so we don't have to rewrite it in Rust?
End-to-end verifiability is possible even without a decoder, because the encoding process is fully deterministic. We can provide a JSON specification and council members can independently verify that it compiles as it should. Am I missing something, @tilacog ?
I agree that the current code already addresses the verifiability issue.
However, I think this is more of a user experience concern. Perhaps not all Council members (reviewers) are expected to be familiar with the command line.
In my last conversation with @abarmat, we thought that a web page with a simple decoding form would be the most convenient interface for the board to review the payload contents, but we can delve deeper it this and come up with the ideal requirements for this task.
cc: @azf20
Some alternatives that @neysofu and I discussed:
POST /encoding
endpoint in the EBO container that could be mapped to one of our domains.In both cases, reviewers would input the JSON message and get the encoded payload as the result, which they can then verify against the proposed payload in multisig.
Since the Council is responsible for reviewing the proposed
RegesterNetworks
messages, it is necessary that reviewers can understand the encoded payloads they are signing.Thus, this crate should provide
decode
command that can parse any given payload into a human-friendly representation of theMessage
sent to the Data Edge contract.For instance, this input:
Is expected to produce this output:
We could host a static web app that encodes/decodes any given input for maximum usability.
cc: @abarmat