Skip to content

Prevent insecure l2 interactions until chain sync #2290

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 74 commits into
base: master
Choose a base branch
from
Open

Prevent insecure l2 interactions until chain sync #2290

wants to merge 74 commits into from

Conversation

@ffakenz
Copy link
Contributor

@ffakenz ffakenz commented Oct 1, 2025 •
edited
Loading

🔑 Motivation

Closes #2286

This PR introduces new synchronization tracking (wall-clock time) and input-handling logic to improve consistency between the chain component and node state.

🔄 Changes

  • NodeState has been refactored into a sum type with two variants: NodeInSync and NodeCatchingUp.

  • A new policy based on the configured ContestationPeriod has been introduced, defining the period of time after which the node is considered out of sync with the chain. Beyond this period, the node will refuse to process new transactions or sign snapshots.

  • The head logic now processes inputs only when the node state's current slot falls within the safe ContestationPeriod window relative to the latest chain time observed by the chain backend and the current wall-clock time.

    • NodeState transitions between NodeInSync and NodeCatchingUp according to the above policy.

    • While in NodeInSync, the head logic behaves as usual.

    • While in NodeCatchingUp:

      • Client inputs are rejected if outside the window.

      • This is the starting state.

      • Network inputs are re-enqueued (with TTL) until synchronization is restored.
        ⚠️ THIS IS PROBLEMATIC: the network component must be aware of the node state synced status and accept messages only while NodeInSync.

  • The API server now notifies clients via new server outputs when the node state falls out of sync with the chain backend and when it becomes synchronized again.

📝 Notes

  • We use the wall-clock time and not the latest known tip from the chain, as it is unreliable while the chain backend is still synchronizing with the Cardano network.

  • A party member cannot go offline for longer than the configured ContestationPeriod; otherwise, it would be at risk, as it would be unable to contest the head closing. This violates the principle of head safety.

  • We decided to move forward with this alternative solution rather than the main proposed one because it preserves the node architecture and allows for fast and easy testing of the protocol’s safety without requiring major hacks during end-to-end tests. This approach also makes the protocol safe by design and aware of the passage of time relative to the latest on-chain observations.

  • CHANGELOG updated or not needed
  • Documentation updated or not needed
  • Haddocks updated or not needed
  • No new TODOs introduced or explained herafter

@ffakenz ffakenz requested a review from a team October 1, 2025 14:28
@ffakenz ffakenz self-assigned this Oct 1, 2025
@ffakenz ffakenz force-pushed the prevent-insecure-l2-interactions-until-chain-sync branch 2 times, most recently from adf3fa4 to bf1530b Compare October 1, 2025 14:31
@github-actions
Copy link

github-actions bot commented Oct 1, 2025

Transaction cost differences

No cost or size differences found

@ffakenz ffakenz force-pushed the prevent-insecure-l2-interactions-until-chain-sync branch 2 times, most recently from 4502f2c to 54ff189 Compare October 1, 2025 19:00
@github-actions
Copy link

github-actions bot commented Oct 1, 2025 •
edited
Loading

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-11-28 15:41:59.007464427 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 a1442faf26d4ec409e2f62a685c1d4893f8d6bcbaf7bcb59d6fa1340 14599
μHead fd173b993e12103cd734ca6710d364e17120a5eb37a224c64ab2b188* 5284
ν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 5834 10.36 3.28 0.51
2 6035 12.32 3.89 0.54
3 6239 14.59 4.61 0.58
5 6638 19.17 6.07 0.64
10 7647 28.71 9.03 0.78
43 14281 98.76 30.86 1.80

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 740 3.38 1.73 0.22
3 920 4.36 2.33 0.24
5 1280 6.41 3.60 0.28
10 2178 12.13 7.25 0.40
54 10060 98.61 68.52 1.88

CollectCom transaction costs

Parties UTxO (bytes) Tx size % max Mem % max CPU Min fee ₳
1 57 525 24.42 7.12 0.42
2 114 636 32.20 9.36 0.51
3 169 747 43.83 12.55 0.63
4 227 858 47.52 13.80 0.67
5 284 969 57.98 16.75 0.78
6 339 1081 65.50 18.91 0.86
7 396 1192 78.79 22.50 1.00
8 452 1303 92.90 26.52 1.15
9 504 1414 96.56 27.65 1.19

Cost of Increment Transaction

Parties Tx size % max Mem % max CPU Min fee ₳
1 1752 23.30 7.41 0.47
2 1964 26.84 9.06 0.52
3 2062 26.94 9.77 0.53
5 2415 32.44 12.63 0.61
10 3151 40.83 18.31 0.75
39 7512 97.53 53.42 1.65

Cost of Decrement Transaction

Parties Tx size % max Mem % max CPU Min fee ₳
1 646 22.77 7.36 0.42
2 790 25.47 8.79 0.45
3 1008 28.00 10.15 0.49
5 1115 26.94 11.17 0.50
10 1905 38.06 17.62 0.67
41 6523 94.23 53.93 1.59

Close transaction costs

Parties Tx size % max Mem % max CPU Min fee ₳
1 688 27.47 8.46 0.46
2 812 29.15 9.59 0.49
3 910 32.72 11.23 0.54
5 1172 36.38 13.58 0.59
10 2123 48.77 20.45 0.79
36 6041 97.32 51.43 1.57

Contest transaction costs

Parties Tx size % max Mem % max CPU Min fee ₳
1 675 33.83 10.16 0.53
2 764 35.14 11.16 0.55
3 984 38.66 12.84 0.60
5 1230 41.90 15.05 0.65
10 2096 54.84 22.04 0.84
29 4772 96.15 46.17 1.47

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 5799 27.00 9.06 0.69
2 6013 37.01 12.47 0.80
3 6175 45.95 15.49 0.90
4 6314 55.66 18.78 1.01
5 6432 62.80 21.21 1.09
6 6548 73.31 24.63 1.21
7 6832 84.60 28.55 1.34
8 6889 94.49 31.97 1.45
9 6832 96.66 32.47 1.47

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 5835 18.75 6.26 0.60
10 1 57 5869 20.34 6.91 0.62
10 10 568 6172 39.95 14.60 0.85
10 30 1706 6853 81.11 30.83 1.33
10 39 2220 7159 98.49 37.73 1.53

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-11-28 15:45:27.592932199 UTC

Baseline Scenario

Number of nodes 1
Number of txs 300
Avg. Confirmation Time (ms) 5.470949390
P99 12.636082179999999ms
P95 7.039310500000001ms
P50 5.1915914999999995ms
Number of Invalid txs 0

Memory data

Time Used Free
2025-11-28 15:44:01.276780807 UTC 1486M 7123M
2025-11-28 15:44:02.30005875 UTC 1503M 7074M
2025-11-28 15:44:03.276775447 UTC 1509M 7068M
2025-11-28 15:44:04.276735773 UTC 1526M 7050M
2025-11-28 15:44:05.276714826 UTC 1580M 6921M
2025-11-28 15:44:06.27672056 UTC 1601M 6901M
2025-11-28 15:44:07.276745699 UTC 1608M 6890M
2025-11-28 15:44:08.276783722 UTC 1610M 6884M
2025-11-28 15:44:09.276786034 UTC 1610M 6884M
2025-11-28 15:44:10.276785272 UTC 1610M 6884M
2025-11-28 15:44:11.27679037 UTC 1610M 6884M
2025-11-28 15:44:12.276797061 UTC 1610M 6883M
2025-11-28 15:44:13.276800755 UTC 1610M 6884M
2025-11-28 15:44:14.276780637 UTC 1607M 6886M
2025-11-28 15:44:15.276739788 UTC 1606M 6887M
2025-11-28 15:44:16.276794939 UTC 1606M 6887M
2025-11-28 15:44:17.276776169 UTC 1607M 6886M
2025-11-28 15:44:18.276785627 UTC 1607M 6886M
2025-11-28 15:44:19.276775724 UTC 1608M 6885M
2025-11-28 15:44:20.276774153 UTC 1609M 6884M
2025-11-28 15:44:21.276790992 UTC 1609M 6884M
2025-11-28 15:44:22.276801408 UTC 1609M 6883M
2025-11-28 15:44:23.276758109 UTC 1611M 6881M
2025-11-28 15:44:24.276755038 UTC 1611M 6881M
2025-11-28 15:44:25.276774829 UTC 1611M 6881M
2025-11-28 15:44:26.276789829 UTC 1611M 6881M
2025-11-28 15:44:27.276768069 UTC 1612M 6880M
2025-11-28 15:44:28.276774965 UTC 1612M 6880M
2025-11-28 15:44:29.276754285 UTC 1612M 6880M
2025-11-28 15:44:30.276799552 UTC 1612M 6880M

Three local nodes

Number of nodes 3
Number of txs 900
Avg. Confirmation Time (ms) 39.415827046
P99 64.60003348ms
P95 56.150386749999996ms
P50 38.847589ms
Number of Invalid txs 0

Memory data

Time Used Free
2025-11-28 15:44:41.701316152 UTC 1506M 7023M
2025-11-28 15:44:42.701374869 UTC 1506M 7023M
2025-11-28 15:44:43.701265091 UTC 1514M 7015M
2025-11-28 15:44:44.701239979 UTC 1514M 7015M
2025-11-28 15:44:45.701229369 UTC 1514M 7015M
2025-11-28 15:44:46.701254499 UTC 1515M 7014M
2025-11-28 15:44:47.7013258 UTC 1515M 7014M
2025-11-28 15:44:48.701268536 UTC 1675M 6770M
2025-11-28 15:44:49.701169259 UTC 1714M 6731M
2025-11-28 15:44:50.701891599 UTC 1732M 6712M
2025-11-28 15:44:51.70143684 UTC 1753M 6686M
2025-11-28 15:44:52.701389433 UTC 1788M 6641M
2025-11-28 15:44:53.702383464 UTC 1804M 6615M
2025-11-28 15:44:54.70360124 UTC 1818M 6590M
2025-11-28 15:44:55.702010677 UTC 1825M 6574M
2025-11-28 15:44:56.701305173 UTC 1842M 6549M
2025-11-28 15:44:57.701755415 UTC 1846M 6539M
2025-11-28 15:44:58.701262671 UTC 1870M 6507M
2025-11-28 15:44:59.701824634 UTC 1870M 6499M
2025-11-28 15:45:00.701346593 UTC 1877M 6484M
2025-11-28 15:45:01.701706723 UTC 1881M 6473M
2025-11-28 15:45:02.701224349 UTC 1909M 6437M
2025-11-28 15:45:03.701291886 UTC 1909M 6432M
2025-11-28 15:45:04.701257539 UTC 1909M 6432M
2025-11-28 15:45:05.701240759 UTC 1909M 6431M
2025-11-28 15:45:06.701299912 UTC 1911M 6429M
2025-11-28 15:45:07.701258169 UTC 1913M 6427M
2025-11-28 15:45:08.7012348 UTC 1913M 6427M
2025-11-28 15:45:09.701251439 UTC 1914M 6426M
2025-11-28 15:45:10.701305376 UTC 1915M 6425M
2025-11-28 15:45:11.701303759 UTC 1915M 6425M
2025-11-28 15:45:12.701279143 UTC 1917M 6422M
2025-11-28 15:45:13.701213697 UTC 1919M 6420M
2025-11-28 15:45:14.70123253 UTC 1919M 6420M
2025-11-28 15:45:15.701255704 UTC 1919M 6420M
2025-11-28 15:45:16.701272591 UTC 1919M 6420M
2025-11-28 15:45:17.701256221 UTC 1920M 6419M
2025-11-28 15:45:18.701335555 UTC 1923M 6416M
2025-11-28 15:45:19.701293372 UTC 1923M 6415M
2025-11-28 15:45:20.701197949 UTC 1923M 6415M
2025-11-28 15:45:21.701273567 UTC 1923M 6415M
2025-11-28 15:45:22.701209874 UTC 1923M 6415M
2025-11-28 15:45:23.701339101 UTC 1924M 6414M
2025-11-28 15:45:24.701294118 UTC 1924M 6413M
2025-11-28 15:45:25.701262524 UTC 1925M 6412M
2025-11-28 15:45:26.701295937 UTC 1926M 6411M

@ffakenz ffakenz force-pushed the prevent-insecure-l2-interactions-until-chain-sync branch from 54ff189 to e2d16dd Compare October 1, 2025 19:44
@ffakenz ffakenz changed the title Prevent insecure l2 interactions until chain sync Spike: prevent insecure l2 interactions until chain sync Oct 5, 2025
@ffakenz ffakenz closed this Oct 5, 2025
@ffakenz ffakenz deleted the prevent-insecure-l2-interactions-until-chain-sync branch October 5, 2025 03:37
@ffakenz ffakenz restored the prevent-insecure-l2-interactions-until-chain-sync branch October 5, 2025 13:52
@ffakenz ffakenz reopened this Oct 5, 2025
@ffakenz ffakenz changed the title Spike: prevent insecure l2 interactions until chain sync Prevent insecure l2 interactions until chain sync Oct 5, 2025
@ffakenz ffakenz force-pushed the prevent-insecure-l2-interactions-until-chain-sync branch 3 times, most recently from 8e9df01 to d21cdf3 Compare October 5, 2025 16:37
@noonio
Copy link
Contributor

noonio commented Oct 7, 2025 •
edited
Loading

Is this ready for review? It says you've requested review, but it's still in draft, and I don't see much of a description.

Happy to review when it's ready; please just adjust the statis to "Ready for Review" and add details! :) Otherwise, please don't add reviewers until it's actually ready.

@ffakenz ffakenz force-pushed the prevent-insecure-l2-interactions-until-chain-sync branch 3 times, most recently from c587974 to 0527d63 Compare October 8, 2025 12:04
@ffakenz ffakenz linked an issue Oct 8, 2025 that may be closed by this pull request
Prevent L2 interactions until chain backend is in sync and secure. #2286
Open
@ffakenz ffakenz force-pushed the prevent-insecure-l2-interactions-until-chain-sync branch 7 times, most recently from 3a39c31 to 76be017 Compare October 8, 2025 20:41
ffakenz added 29 commits November 28, 2025 12:32
@ffakenz
add node state synced status transition property
b92f6eb
@ffakenz
fix: make tui to compile
b64a158
@ffakenz
fmt: remove unused functions
8bdc5ef
@ffakenz
fix: e2e scenario
4158fda 
> by refactoring the cluster connection to node using different delay
depending on backend (blockfrost/direct)
@ffakenz
handle input rejected in http server as 503
a088eb5
@ffakenz
update tui to handle new server outputs and client message
056842c
@ffakenz
update CHANGELOG
a80d5df
@ffakenz
fix: adjust e2e assertion delays to prevent node from becoming unsync…
b320086 
…ed when sending new txs
@ffakenz
clean up review comment
c0559ac 
> as it is safe to use OverloadedRecordDot with sum types
@ffakenz
init node state as catching up
864d08a
@ffakenz
fix e2e specs for node state now initializing in catching up
e1f74e2 
by waiting for the node to be in sync before:
- waiting for nodes to be connected
- sending init client input
@ffakenz
comments fix up
d5f6bd8
@ffakenz
tune waiting time in scenario based on how long it takes to sync
f039bb0
@ffakenz
move custom time handle factory method to logic spec
6ca410a 
> as it is only used for testing purposes
@ffakenz
document new synchronization polciy
82c34cd
@ffakenz
add haddock to the offline chain tick producer
174f111
@ffakenz
update tui to show the chain synced status
9587c2c
@ffakenz
handle node synced status in visualize logs module
0a769e2
@ffakenz
fix flaky e2e specs
ec6b755 
> by waiting for node to be synced before submitting new txs
@ffakenz
refactor tui spec to enhance scenario
827b267
@ffakenz
minor changes after rebase
ba2e96a
@ffakenz
fix another flaky e2e spec
6a5f7bc
@ffakenz
fix flaky e2e spec: give some time for the node to bootstrap before e…
0321122 
…xception is thrown
@ffakenz
fix flaky e2e spec: do not wait for node synced as it reconnects fast…
147efd3 
… enough and it never becomes unsynced
@ffakenz
fix typo: reword synch to sync
fe23fb7
@ffakenz
fix flaky e2e scenario: by adding chain synced status to greetings
fc2eedc
@ffakenz
enhance e2e side load spec
9e289c5 
> by making sure the node is in sync during greetings before submitting a new tx
@ffakenz
enhance tui spec
6507351
@ffakenz
minor fix after rebase
9500456
@ffakenz ffakenz force-pushed the prevent-insecure-l2-interactions-until-chain-sync branch from 7ce1fd4 to 9500456 Compare November 28, 2025 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@v0d1ch v0d1ch v0d1ch approved these changes

@vrom911 vrom911 vrom911 approved these changes

Assignees

@ffakenz ffakenz

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Prevent L2 interactions until chain backend is in sync and secure.

6 participants

@ffakenz @noonio @v0d1ch @vrom911 @ch1bo