Propose an ADR on reference scripts

[ch1bo]

We somehow covered this while grooming #397, but I thought we should persist the design as an ADR.

It's not just a dump of the ticket, but tries to give a bit more rationale.

Rendered (github): https://github.com/input-output-hk/hydra-poc/blob/4f723b771ca8f538766154437750e8ec1de2c137/docs/adr/2022-07-22_019-reference-scripts.md

[github-actions]

Unit Test Results

237 tests   235 ✔️  11m 39s ⏱️
  87 suites      2 💤
    5 files        0 ❌

Results for commit 985df77.

♻️ This comment has been updated with latest results.

[github-actions]

Transactions Costs

Sizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using arbitrary values and results are not fully deterministic and comparable to previous runs.

Metadata
Generated at	2022-08-02 15:42:00.797555448 UTC
Max. memory units	14000000.00
Max. CPU units	10000000000.00
Max. tx size (kB)	16384

Cost of Init Transaction

Parties	Tx size	% max Mem	% max CPU
1	4831	9.27	3.65
2	5037	14.13	5.61
3	5243	14.72	5.79
5	5656	19.06	7.48
10	6677	28.70	11.18
46	14058	98.77	38.15

Cost of Commit Transaction

Currently only one UTxO per commit allowed (this is about to change soon)

UTxO	Tx size	% max Mem	% max CPU
1	5771	19.84	8.01

Cost of CollectCom Transaction

Parties	Tx size	% max Mem	% max CPU
1	13058	20.60	8.25
2	13450	37.34	15.12
3	13701	55.20	22.52
4	14021	76.55	31.39

Cost of Close Transaction

Parties	Tx size	% max Mem	% max CPU
1	9331	8.19	3.36
2	9498	8.97	3.81
3	9695	10.19	4.44
5	9991	11.31	5.17
10	10843	15.65	7.60
30	14219	32.40	17.07
60	15211	36.53	13.84

Cost of Contest Transaction

Parties	Tx size	% max Mem	% max CPU
1	9320	8.16	3.34
2	9526	9.34	3.95
3	9658	9.72	4.24
5	10021	11.68	5.30
10	10886	16.25	7.82
30	14178	31.79	16.83
43	16372	42.83	23.05

Cost of Abort Transaction

Parties	Tx size	% max Mem	% max CPU

Cost of FanOut Transaction

Involves spending head output and burning head tokens. Uses ada-only UTxO for better comparability.

UTxO	Tx size	% max Mem	% max CPU
1	13418	9.88	4.31
2	13458	11.40	5.19
3	13621	13.68	6.37
5	13697	16.72	8.12
10	13872	24.63	12.64
50	15181	84.50	47.45
59	15633	99.28	55.80

[KtorZ]

The way this is presented is a bit weird because, both option (1) and option (2) are about publishing Hydra scripts on-chain; the only question is whether or not to mix that with the init transaction.

And the conclusion being that no, we'd rather not for reason X & Y.

• Although, heads using option 1 would not be exposed to DoS

I disagree, it would be exposed to it all-the-same. The DoS problem stems from what locks the outputs where the script is posted to. If it's spendable, then it's deniable. So these are kind of orthogonal.

One extra reason why doing it as part of the init isn't a good idea is the complexity it adds to the system. When the publishing transaction is assumed to exist, it is known on application start, provided as configuration. However, doing it part of the init means that there needs to be code that (a) realize the event and (b) monitor the outcome of the event. That's extra complexity for the Hydra node which we may want to prevent.

[ch1bo]

Good points. You are right in that the DoS stuff is about spendability of the outputs. In option 1 we could make it spendable by head instance itself and only when terminating it, i.e. by ensuring the ST is also burned. So it can be made DoS-safe and non-littering. Which is not possible in option 2.

[KtorZ]

I was thinking that, we could imagine a v_genesis_delegate which can only be spent with a quorum of 5 signatures from the genesis delegates 😅 ... As a "standard", this would allow to create scripts that can be later garbage-collected by the genesis delegates to reduce littering of the chain. They can already DoS the entire chain if they wanted to, so letting them also get rid of the UTxO if needs be sounds fair enough 😅

I guess it's okay anyway to have a const False script because we'll be talking about few scripts a year 🤷 ... still, somehow it bothers me to "leave my trash around".

[KtorZ]

I've got a proof of concept in mind, little web app connecting to a CIP-0030's wallet and using the Github API to fetch release artifacts 👌

[KtorZ]

I'd park that as an "implementation details" (the TxIn bit). As we discussed, we need to provide the Hydra node with the output reference corresponding to each scripts needed as reference. This can be inferred from a TxIn + state query (as we currently do), or could be specified as a configuration file / command-line options fully.

[ch1bo]

Are you saying that it's okay to leave it like this and how the TxIn gets inferred is an implementation detail? i.e. not enumerating all but doing what we do right now is an optimization on convenience == implementation detail not covered by the adr

[KtorZ]

I mean that mentioning TxIn is an implementation detail. The ADR should simply say that a reference to the published scripts must be communicated to the Hydra node. An address, a TxId, a TxIn ... doesn't matter much.

[KtorZ]

Perhaps I am just neat picking.

[ch1bo]

Ah well. Ultimately the reference needs to be available as a TxIn eventually, so I think that formulation is the common denominator all specific implementations need to fulfill. 🚲 🏠

[KtorZ]

We'd likely want to also include some kind of project identifier in there. Because we could imagine this approach to be "normalized" and reused. Alternatively, we could also use a static address and use inline-datum as a way to attach metadata. Then it's possible to discover all scripts published in that way and tell them apart from the metadata.

[ch1bo]

Yeah maybe better to store the tags in datums. In this specific case the examples should highlight that any tag should be okay and we use a script name + version in HydraHeadV1, HydraInitialV1 etc.