|
| 1 | +--- |
| 2 | +rskip: 559 |
| 3 | +title: Deterministic next pegout selection fix |
| 4 | +description: Intorduce clear solution to select next pegout with enough confirmations |
| 5 | +status: Draft |
| 6 | +purpose: Sec |
| 7 | +author: VZ |
| 8 | +layer: Core |
| 9 | +complexity: 2 |
| 10 | +created: 2026-04-16 |
| 11 | +--- |
| 12 | + |
| 13 | +## Abstract |
| 14 | + |
| 15 | +It was determined that we have almost non deterministic behaviour for output of the function `getNextPegoutWithEnoughConfirmations`. |
| 16 | +We are returning first valid match from collection which ordering is depends on JDK internal implementation. |
| 17 | +This is why we were having issues switching to Java 21. |
| 18 | + |
| 19 | +Such behaviour is very hard to predict and it bins nodes to exact set of JDKs. |
| 20 | +Replicating such behaviour in any other programming language is extremely hard. |
| 21 | + |
| 22 | +Elements ordering algorithm must be clear and easy to understand. |
| 23 | + |
| 24 | + |
| 25 | +## Specification & Rationale |
| 26 | + |
| 27 | +Old ordering rule is barely describable becuase it depends on ordering in 2 HashSets where one is feeded into another. |
| 28 | + |
| 29 | +New ordering just reuse existing `BTC_TX_COMPARATOR` that just use lexicographical bytes ordering of serialized transactions. |
| 30 | +This approach is easy, clean and understandable. |
| 31 | + |
| 32 | + |
| 33 | +## Backwards compatibility |
| 34 | + |
| 35 | +Changes reqires a hardfork that will turn on valid elements ordering. |
| 36 | +After hardfork it will be possible to extract all conflicting outputs of `getNextPegoutWithEnoughConfirmations` and hardcode them in mainnet node configuration. |
| 37 | +After that old ordering code will be removed. |
| 38 | + |
| 39 | +For other types of networks like future testnet v4 etc it will be required to activate this RSKIP from the block one. |
| 40 | + |
| 41 | +### Testnet 3 corner case |
| 42 | + |
| 43 | +`PegoutsWaitingForConfirmation` storage is mutable, it changes state on `getNextPegoutWithEnoughConfirmations`. |
| 44 | +Which leads to complex behaviour if there are multiple TX calling bridge contract in the same block. |
| 45 | +In the testnet 3 we have such collisions on blocks 2589068 and 2589112. |
| 46 | +So it is not possible to hardcode pegouts for a testnet 3 using simple key-value map. |
| 47 | + |
| 48 | +Considering that testnet 3 is near EOL it is unreasonable to introduce additional complexity |
| 49 | +with state mutation for historical pegouts while it is not required for the mainnet. |
| 50 | +I suggest to do not harcode conflicting pegouts and leave old sorting code until testnet 3 will be dismissed. |
| 51 | + |
0 commit comments