Allow for additional etcd arguments

[noonio]

Fixes #1883

This allows additional arguments to be specified.

Note that it's slightly hacky, as old arguments will still be listed but overwritten when etcd comes to read them; so it's functionally clean, but perhaps less than ideal when reading ps aux | grep etcd.

Open to other ideas here.

[github-actions]

Transaction cost differences

Script summary

Name	Size (Bytes)
νInitial	-
νCommit	-
νHead	-
μHead	-
νDeposit	-

Init transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	-	-	-	-
2	-	-	-	-
3	-	-	-	-
5	-	-	-	-
10	-	-	-	-
40	-	-	-	-

Commit transaction costs

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	-	-	-	-
2	-	-	-	-
3	-	-	-	-
5	-	-	-	-
10	-	-	-	-
54	-	-	-	-

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	-	-	-	-	-
2	-	-	-	-	-
3	-	-	-	-	-
4	-	-	-	-	-
5	-	-	-	-	-
6	-	-	-	-	-
7	-	-	-	-	-
8	-	-	-	-	-

Cost of Increment Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	-	$${\color{green}-0.39}$$	$${\color{green}-0.09}$$	-
2	-	-	-	-
3	-	-	-	-
5	-	-	-	-
10	-	-	-	-
37	-	-	-	-

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	-	-	-	-
2	-	-	-	-
3	-	-	-	-
5	-	-	-	-
10	-	-	-	-
40	-	-	-	-

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	-	-	-	-
2	-	-	-	-
3	-	-	-	-
5	-	-	-	-
10	-	-	-	-
34	-	-	-	-

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	-	-	-	-
2	-	-	-	-
3	-	-	-	-
5	-	-	-	-
10	-	-	-	-
27	-	-	-	-

FanOut transaction costs

UTxO, Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
(0, 10)	-	-	-	-	-
(1, 10)	-	-	-	-	-
(5, 10)	-	-	-	-	-
(10, 10)	-	-	-	-	-
(20, 10)	-	-	-	-	-
(37, 10)	-	-	-	-	-

[github-actions]

Transaction 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	2025-03-12 15:41:35.964756027 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	c8a101a5c8ac4816b0dceb59ce31fc2258e387de828f02961d2f2045	2652
νCommit	61458bc2f297fff3cc5df6ac7ab57cefd87763b0b7bd722146a1035c	685
νHead	0e35115a2c7c13c68ecd8d74e4987c04d4539e337643be20bb3274bd	14756
μHead	57166715eadb8d3135964325c016eea546c21e1c0aae974ca67df9a5*	5541
νDeposit	ae01dade3a9c346d5c93ae3ce339412b90a0b8f83f94ec6baa24e30c	1102

• The minting policy hash is only usable for comparison. As the script is parameterized, the actual script is unique per head.

Init transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	6091	11.20	3.49	0.53
2	6295	13.13	4.07	0.56
3	6495	15.28	4.73	0.59
5	6902	19.98	6.17	0.66
10	7903	31.40	9.68	0.82
40	13936	98.57	30.28	1.78

Commit transaction costs

This uses ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	561	2.44	1.16	0.20
2	743	3.38	1.73	0.22
3	918	4.36	2.33	0.24
5	1273	6.41	3.60	0.28
10	2174	12.13	7.25	0.40
54	10050	98.61	68.52	1.88

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	525	26.44	7.58	0.44
2	114	636	35.04	10.04	0.53
3	171	747	45.70	12.96	0.65
4	227	858	56.35	15.90	0.76
5	282	974	66.92	18.78	0.87
6	338	1081	69.52	19.87	0.90
7	392	1192	78.27	22.32	1.00
8	451	1303	94.71	26.84	1.17

Cost of Increment Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	1802	25.50	8.33	0.50
2	1947	27.07	9.50	0.52
3	2120	29.44	10.98	0.56
5	2365	32.63	13.29	0.61
10	3172	42.69	19.90	0.78
39	7371	96.10	56.34	1.66

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	625	23.95	7.61	0.43
2	734	24.85	8.49	0.44
3	873	27.22	9.83	0.48
5	1325	34.15	13.07	0.58
10	2057	42.95	18.83	0.72
37	5965	94.33	50.99	1.54

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	701	29.15	9.21	0.48
2	774	30.32	10.13	0.50
3	906	32.11	11.35	0.53
5	1306	37.72	14.68	0.62
10	2142	51.82	22.58	0.83
33	5384	93.79	51.28	1.51

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	705	35.95	11.01	0.55
2	827	38.15	12.33	0.58
3	997	41.03	13.95	0.63
5	1288	45.33	16.58	0.69
10	2139	58.85	24.36	0.90
27	4617	99.30	48.32	1.50

Abort transaction costs

There is some variation due to the random mixture of initial and already committed outputs.

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	5978	28.29	9.32	0.71
2	6050	36.50	11.99	0.80
3	6225	46.81	15.43	0.91
4	6393	57.20	18.89	1.03
5	6504	65.53	21.68	1.12
6	6591	75.46	24.83	1.23
7	6885	88.10	29.21	1.38
8	6762	88.70	29.24	1.38

FanOut transaction costs

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

Parties	UTxO	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
10	0	0	6091	20.58	6.77	0.63
10	1	56	6124	21.53	7.20	0.65
10	5	284	6261	29.39	10.28	0.74
10	20	1139	6770	63.37	23.36	1.13
10	37	2103	7345	98.94	37.19	1.54

End-to-end benchmark results

This page is intended to collect the latest end-to-end benchmark results produced by Hydra's continuous integration (CI) system from the latest master code.

Please note that these results are approximate as they are currently produced from limited cloud VMs and not controlled hardware. Rather than focusing on the absolute results, the emphasis should be on relative results, such as how the timings for a scenario evolve as the code changes.

Generated at 2025-03-12 15:44:28.507032181 UTC

Baseline Scenario

Number of nodes	1
Number of txs	300
Avg. Confirmation Time (ms)	4.594475250
P99	6.352008309999997ms
P95	5.34265475ms
P50	4.2389955ms
Number of Invalid txs	0

Memory data

Time	Used	Free
2025-03-12 15:43:12.918002649 UTC	924M	6129M
2025-03-12 15:43:17.925111228 UTC	1049M	5930M
2025-03-12 15:43:22.917925439 UTC	1049M	5929M
2025-03-12 15:43:27.918017062 UTC	1048M	5929M
2025-03-12 15:43:32.917961474 UTC	1051M	5927M
2025-03-12 15:43:37.91796509 UTC	1051M	5926M

Three local nodes

Number of nodes	3
Number of txs	900
Avg. Confirmation Time (ms)	32.962297940
P99	71.04084675ms
P95	56.9745491ms
P50	29.210590500000002ms
Number of Invalid txs	0

Memory data

Time	Used	Free
2025-03-12 15:43:51.508802771 UTC	952M	6035M
2025-03-12 15:43:56.510299566 UTC	1238M	5744M
2025-03-12 15:44:01.509786446 UTC	1296M	5621M
2025-03-12 15:44:06.508866788 UTC	1300M	5573M
2025-03-12 15:44:11.50886449 UTC	1311M	5561M
2025-03-12 15:44:16.508838227 UTC	1311M	5560M
2025-03-12 15:44:21.508852785 UTC	1311M	5560M
2025-03-12 15:44:26.508830918 UTC	1313M	5557M

[ch1bo]

Looking at https://etcd.io/docs/v3.5/op-guide/configuration/ I would find it most intuitive if we'd configure the auto-compaction on etcd through their env variables (if not set already on the environment). In fact, any other options which we don't set via the command line should already be configurable using the etcd native environment variables.

diff --git a/hydra-node/src/Hydra/Network/Etcd.hs b/hydra-node/src/Hydra/Network/Etcd.hs
index 275998d406..bfe5a1e401 100644
--- a/hydra-node/src/Hydra/Network/Etcd.hs
+++ b/hydra-node/src/Hydra/Network/Etcd.hs
@@ -93,6 +93,7 @@ import Network.GRPC.Common.NextElem (whileNext_)
 import Network.GRPC.Common.Protobuf (Protobuf, defMessage, (.~))
 import Network.GRPC.Etcd (KV, Lease, Watch)
 import System.Directory (createDirectoryIfMissing, listDirectory, removeFile)
+import System.Environment.Blank (getEnvironment)
 import System.FilePath ((</>))
 import System.IO.Error (isDoesNotExistError)
 import System.Process (interruptProcessGroupOf)
@@ -124,8 +125,8 @@ withEtcdNetwork tracer protocolVersion config callback action = do
   -- TODO: fail if cluster config / members do not match --peer
   -- configuration? That would be similar to the 'acks' persistence
   -- bailing out on loading.
-  additionalArguments <- maybe [] (split (== ' ')) <$> lookupEnv "HYDRA_ETCD_ADDITIONAL_ARGUMENTS"
-  withProcessInterrupt (etcdCmd additionalArguments) $ \p -> do
+  envVars <- Map.fromList <$> getEnvironment
+  withProcessInterrupt (etcdCmd envVars) $ \p -> do
     race_ (waitExitCode p >>= \ec -> fail $ "Sub-process etcd exited with: " <> show ec) $ do
       race_ (traceStderr p) $ do
         -- XXX: cleanup reconnecting through policy if other threads fail
@@ -185,8 +186,9 @@ withEtcdNetwork tracer protocolVersion config callback action = do
   -- XXX: Could use TLS to secure peer connections
   -- XXX: Could use discovery to simplify configuration
   -- NOTE: Configured using guides: https://etcd.io/docs/v3.5/op-guide
-  etcdCmd additionalArguments =
-    setCreateGroup True -- Prevents interrupt of main process when we send SIGINT to etcd
+  etcdCmd envVars =
+    setEnv (toList $ defaultEnv <> envVars)
+      . setCreateGroup True -- Prevents interrupt of main process when we send SIGINT to etcd
       . setStderr createPipe
       . proc "etcd"
       $ concat
@@ -203,13 +205,16 @@ withEtcdNetwork tracer protocolVersion config callback action = do
         , -- XXX: Could use unique initial-cluster-tokens to isolate clusters
           ["--initial-cluster-token", "hydra-network-1"]
         , ["--initial-cluster", clusterPeers]
-        , -- Keep up to 1000 revisions. See also:
-          -- https://etcd.io/docs/v3.5/op-guide/maintenance/#auto-compaction
-          ["--auto-compaction-mode=revision", "--auto-compaction-retention=1000"]
-        , -- Any of the above arguments can be overridden here.
-          additionalArguments
         ]
 
+  defaultEnv =
+    -- Keep up to 1000 revisions. See also:
+    -- https://etcd.io/docs/v3.5/op-guide/maintenance/#auto-compaction
+    Map.fromList
+      [ ("ETCD_AUTO_COMPACTION_MODE", "revision")
+      , ("ETCD_AUTO_COMPACTION_RETENTION", "1000")
+      ]
+
   -- NOTE: Building a canonical list of labels from the advertised addresses
   clusterPeers =
     intercalate ","

[noonio]

@ch1bo yeah, I'm happy with that I suppose.

One reason to use explicitly-our variables was to not conflict with another etcd service that may or may not be running on the host.

But I do like that the variables are explicit; I think it's better than the somewhat-hacky override approach I had.

[ch1bo]

One reason to use explicitly-our variables was to not conflict with another etcd service that may or may not be running on the host.

Good that environment variables are not system-wide then :)

[ch1bo]

I think you mappended the wrong way around. Also, some documentation would be good to have about this. Maybe in docs/docs/configuration.md?

[noonio]

Maybe in docs/docs/configuration.md?

Done; please take a look.

[ch1bo]

There is still a bug in the env var mappending?

Docs look good. Makes me realize we have no docs about how to use --listen, --advertise and --peer

[noonio]

There is still a bug in the env var mappending?

No?

[ch1bo]

There is still a bug in the env var mappending?

No?

I meant the suggestion I left, which you confirmed by accepting my commit :).

[noonio]

I meant the suggestion I left, which you confirmed by accepting my commit :).

Unfortunately that was wrong; but I've fixed it :)