graphprotocol / block-oracle

MIT License
7 stars 13 forks source link

Implement end-to-end verifiability of Oracle's messages #197

Closed tilacog closed 2 years ago

tilacog commented 2 years ago

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 the Message sent to the Data Edge contract.

For instance, this input:

0x0305015505156569703135353a313030156569703a3135353a3737

Is expected to produce this output:

[
  {
    "message": "RegisterNetworks",
    "add": [
        "eip155:100",
        "eip:155:77"
    ],
      "remove": [0, 42]
  }
]

We could host a static web app that encodes/decodes any given input for maximum usability.

cc: @abarmat

tilacog commented 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?

neysofu commented 2 years ago

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 ?

tilacog commented 2 years ago

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

tilacog commented 2 years ago

Some alternatives that @neysofu and I discussed:

  1. Export the JSON encoding functionality to WASM and host it as an HTML form using Github Pages.
  2. Expose a 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.