Protocol change: Inline datums #1162
Conversation
Transactions CostsSizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using
Script summary
Cost of Init Transaction
Cost of Commit TransactionThis is using ada-only outputs for better comparability.
Cost of CollectCom Transaction
Cost of Close Transaction
Cost of Contest Transaction
Cost of Abort TransactionSome variation because of random mixture of still initial and already committed outputs.
Cost of FanOut TransactionInvolves spending head output and burning head tokens. Uses ada-only UTxO for better comparability.
End-To-End Benchmark ResultsThis page is intended to collect the latest end-to-end benchmarks results produced by Hydra's Continuous Integration system from the latest Please take those results with a grain of salt as they are currently produced from very limited cloud VMs and not controlled hardware. Instead of focusing on the absolute results, the emphasis should be on relative results, eg. how the timings for a scenario evolve as the code changes. Generated at 2023-11-15 16:02:30.912597058 UTC 3-nodes ScenarioA rather typical setup, with 3 nodes forming a Hydra head.
Baseline ScenarioThis scenario represents a minimal case and as such is a good baseline against which to assess the overhead introduced by more complex setups. There is a single hydra-node d with a single client submitting single input and single output transactions with a constant UTxO set of 1.
|
ch1bo
force-pushed
the
inline-datums
branch
3 times, most recently
from
5465dd0 to
7e1bf01
Compare
This is used throughout mutation tests and assumes inline datums now.
This particular case was seeing a transaction valid although we switched from commit to initial input. However, the script was not running because the redeemer was missing. Hence we also add an assertion in using ChangeInput to avoid this in future.
Before we supported both, datums in txs and inline datums.
This was working before because the ledger would resolve in-tx datums for the plutus evaluator. While phase-2 valid, the transactions themselves would not be compatible with the way we construct / observe transactions in the hydra-node.
The tracked utxos do not contain datums anymore
🍠 Switch the Hydra Head protocol to rely on inline datums. Before there was already the convention that Hydra transactions would include the datum in the tx producing some output.
🍠 This removed some lookup cases from the validators and prompted some refinement in the mutation tests (we were failing for a semi-wrong reason in one)
🍠 The tx creation could requires much less information about the UTxO now. In fact, all of the script data kept around can get rid of.
🍠 Transaction sizes became smaller as we only need to put the datum in the producing transaction, not the consuming one. Most transactions in our
tx-costbenchmark are ~200 bytes smaller, theabortTxhowever became about 100 bytes bigger.. per participant 🐼🍠 Cleaned up unused error codes (as this is already a breaking change in scripts).
error("SNAFU") was there before and we will be tackling the tx creation in this area soon anyways.