Naiive on-chain-verification (Plutus scripts)

[ch1bo]

What & Why

So far, we have implemented the whole Hydra Head life-cycle via proper Cardano transactions. However, only mocked validators had been used and thus the Hydra Head is not secure. For example, any attacker could submit a transaction to close the Head. To make the Head secure, we need to add script validators to the Head's UTXO.

This feature is called "naiive" on-chain-verification (OCV) because we want to implement in a complete & correct, but simplified form. See technical requirements for details.

Product requirements

• The full life-cycle of a Hydra Head is secured by script validators.
• The abort life-cycle of a Hydra Head is secured by script validators.
• Script validators are tested with an attacker mindset.

Technical requirements

• Scripts are developed in a test-driven way, where unit- and property-tests are used to ensure correctness in adversarial cases.
• Naiive algorithms are used to implement the scripts:
  a. Multi-signatures - a list of Ed25519 signatures is checked, not an aggregated one. This is relevant for the close & contest scripts.
  b. UTXO checking - instead of using full Merkle-(Patricia)-Trees to proof non-/existence of UTXOs in the fanout script, a simple list/map lookup shall be used complete hash of the [TxOut] shall be used.
• Script sizes, execution unit budgets and costs are determined
• Benchmark & demo scenarios are adapted with increased budgets

[ghost]

Is it implicit in this description that we use real (e.g not MockDSIGN) signatures in the Head?

[ch1bo]

Is it implicit in this description that we use real (e.g not MockDSIGN) signatures in the Head?

Yes, we should aim for using real (non-musig2) signatures. Good point. I'll make it explicit.

[kk-hainq]

Will you guys accept an external PR for this task? We can do it in baby steps or in full during the New Year holiday as our Lunar New Year is in February. We do have more time to contribute upstream while the Western half of the team goes on holiday :).

[ch1bo]

Thanks for the offer @kk-hainq. I wrote this down to have a a first high-level feature on this platform to gauge how detailed we want/need this to be, before I write them all up to have a transparent, public roadmap. It was not intended for seeking assistance as it's lacking some details, but I can definitely see that for one of the next features or subtasks of it. Plus, we are currently in the midst of it as can be seen on master and the open ensemble branch.

[ch1bo]

Scope change: As this is only covering the "complete" fanout transaction, it suffices to check whether all fanned out outputs are present in a closed state. Thus we do hash the list of outputs and compare with the stored hash of the closed UTXO state (instead of en-/decoding the full UTXO type as plutus datum).

[ch1bo]

Complexity of hashing is covered in PR #155.

[ch1bo]

Last PR with relevant validators was merged #201 , so closing this in prep for 0.3.0

[ch1bo]

Status quo implementation also documented in #204