RNG Fallback #2054
RNG Fallback #2054
Conversation
✅ Deploy Preview for kleros-v2-testnet ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
❌ Deploy Preview for kleros-v2-neo failed. Why did it fail? →
|
✅ Deploy Preview for kleros-v2-testnet-devtools ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
WalkthroughThis update refactors the random number generator (RNG) architecture by replacing the Changes
Sequence Diagram(s)sequenceDiagram
participant Governor
participant Consumer (SortitionModule)
participant RNGWithFallback
participant IRNG (Default/Fallback)
Consumer->>RNGWithFallback: requestRandomness()
RNGWithFallback->>IRNG: requestRandomness()
Note right of RNGWithFallback: Wait for fallbackTimeoutSeconds
RNGWithFallback->>IRNG: receiveRandomness()
alt Randomness ready
IRNG-->>RNGWithFallback: randomNumber
RNGWithFallback-->>Consumer: randomNumber
else Timeout
RNGWithFallback->>Next IRNG: requestRandomness()
RNGWithFallback->>Next IRNG: receiveRandomness()
Next IRNG-->>RNGWithFallback: randomNumber or zero
RNGWithFallback-->>Consumer: randomNumber or failure
end
sequenceDiagram
participant Governor
participant Consumer (SortitionModule)
participant BlockHashRNG
Consumer->>BlockHashRNG: requestRandomness()
Note right of BlockHashRNG: Records requestTimestamp
Note right of BlockHashRNG: Waits for lookaheadTime
Consumer->>BlockHashRNG: receiveRandomness()
alt lookaheadTime elapsed
BlockHashRNG-->>Consumer: randomNumber (from blockhash)
else
BlockHashRNG-->>Consumer: 0 (not ready)
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~40 minutes Possibly related PRs
Suggested labels
Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (2)📓 Common learningscontracts/src/arbitration/SortitionModuleBase.sol (2)Learnt from: jaybuidl Learnt from: jaybuidl ⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🔇 Additional comments (5)
✨ Finishing Touches🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
❌ Deploy Preview for kleros-v2-university failed. Why did it fail? →
|
… deprecated for later removal
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
contracts/test/foundry/KlerosCore.t.sol (1)
276-278: Consider using consistent rngLookahead values across tests.The
test_initialize_eventsfunction usesrngLookahead = 20while the mainsetUpuses600. Consider using the same value for consistency, or add a comment explaining why a different value is needed for event testing.- rngLookahead = 20; + rngLookahead = 600; // Use consistent timing across tests rng = new BlockHashRNG(msg.sender, address(sortitionModule), rngLookahead);contracts/test/rng/index.ts (1)
38-44: Consider using different addresses for governor and consumer in tests.While using the same address for both roles works for testing, consider using different addresses to better simulate production scenarios and ensure role separation is properly tested.
- const [deployer] = await ethers.getSigners(); + const [deployer, consumer] = await ethers.getSigners(); await deployments.delete("BlockHashRNG"); await deployments.deploy("BlockHashRNG", { from: deployer.address, - args: [deployer.address, deployer.address, 10], // governor, consumer, lookaheadTime (seconds) + args: [deployer.address, consumer.address, 10], // governor, consumer, lookaheadTime (seconds) });contracts/src/rng/RNGWithFallback.sol (1)
169-173: Document implications of emergencyReset.While useful for recovery,
emergencyResetcould cause loss of pending randomness requests. Consider adding clear documentation about when this should be used and its implications./// @dev Emergency reset the RNG. /// Useful for the governor to ensure that re-requesting a random number will not be blocked by a previous request. +/// WARNING: This will clear any pending randomness requests, potentially causing loss of randomness. +/// Only use in emergency situations when the RNG is stuck. function emergencyReset() external onlyByGovernor {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (26)
contracts/deploy/00-chainlink-rng.ts(1 hunks)contracts/deploy/00-home-chain-arbitration-neo.ts(3 hunks)contracts/deploy/00-home-chain-arbitration.ts(2 hunks)contracts/deploy/00-home-chain-resolver.ts(0 hunks)contracts/deploy/00-rng.ts(2 hunks)contracts/deploy/change-sortition-module-rng.ts(1 hunks)contracts/src/arbitration/SortitionModule.sol(2 hunks)contracts/src/arbitration/SortitionModuleBase.sol(5 hunks)contracts/src/arbitration/SortitionModuleNeo.sol(2 hunks)contracts/src/rng/BlockhashRNG.sol(1 hunks)contracts/src/rng/ChainlinkRNG.sol(8 hunks)contracts/src/rng/IRNG.sol(1 hunks)contracts/src/rng/IncrementalNG.sol(1 hunks)contracts/src/rng/RNG.sol(0 hunks)contracts/src/rng/RNGWithFallback.sol(1 hunks)contracts/src/rng/RandomizerRNG.sol(6 hunks)contracts/test/arbitration/dispute-kit-gated.ts(1 hunks)contracts/test/arbitration/draw.ts(1 hunks)contracts/test/arbitration/staking-neo.ts(2 hunks)contracts/test/arbitration/staking.ts(3 hunks)contracts/test/foundry/KlerosCore.t.sol(34 hunks)contracts/test/integration/index.ts(1 hunks)contracts/test/proxy/index.ts(1 hunks)contracts/test/rng/index.ts(5 hunks)contracts/test/utils/getActualAddress.ts(1 hunks)cspell.json(1 hunks)
💤 Files with no reviewable changes (2)
- contracts/deploy/00-home-chain-resolver.ts
- contracts/src/rng/RNG.sol
🧰 Additional context used
🧠 Learnings (24)
📓 Common learnings
Learnt from: jaybuidl
PR: kleros/kleros-v2#1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the `contracts/src/rng/ChainlinkRNG.sol` contract, the `requestRandomness` function is restricted to being called only by the `SortitionModule`, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
contracts/deploy/00-chainlink-rng.ts (1)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
contracts/test/utils/getActualAddress.ts (8)
Learnt from: jaybuidl
PR: #1620
File: contracts/test/arbitration/draw.ts:84-84
Timestamp: 2024-11-05T11:32:11.238Z
Learning: In TypeScript code using ethers.js version 6, contract.target should be used instead of contract.address to access a contract's address.
Learnt from: Harman-singh-waraich
PR: #1687
File: web/src/context/AtlasProvider.tsx:225-244
Timestamp: 2024-10-15T16:18:32.543Z
Learning: In web/src/context/AtlasProvider.tsx, the atlasUri variable comes from environment variables and does not change, so it does not need to be included in dependency arrays.
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
Learnt from: Harman-singh-waraich
PR: #1727
File: web/src/utils/atlas/updateEmail.ts:34-37
Timestamp: 2024-10-28T12:20:19.884Z
Learning: In web/src/utils/atlas/updateEmail.ts, the error coming from the GraphQLError array already has the necessary structure, so additional specificity in error handling is unnecessary.
Learnt from: jaybuidl
PR: #1964
File: contracts/scripts/shutter.ts:3-3
Timestamp: 2025-04-30T22:12:25.476Z
Learning: In Node.js, importing the crypto module as import crypto from "crypto" is a valid approach when using methods like crypto.randomBytes(). This import style works fine and doesn't need to be changed to a destructured import when these methods are used.
Learnt from: Harman-singh-waraich
PR: #1703
File: kleros-sdk/src/dataMappings/utils/actionTypes.ts:1-1
Timestamp: 2024-10-22T09:38:20.093Z
Learning: In the TypeScript file kleros-sdk/src/dataMappings/utils/actionTypes.ts, the Abi type is parsed later in the action functions, so importing Abi from viem in this file is unnecessary.
Learnt from: Harman-singh-waraich
PR: #1703
File: kleros-sdk/src/sdk.ts:1-3
Timestamp: 2024-10-22T10:23:15.789Z
Learning: In kleros-sdk/src/sdk.ts, the PublicClient type is used and should not be flagged as unused.
Learnt from: Harman-singh-waraich
PR: #1703
File: kleros-sdk/src/requests/gqlClient.ts:18-18
Timestamp: 2024-10-24T08:16:02.749Z
Learning: In this TypeScript project, when a file (such as kleros-sdk/src/requests/gqlClient.ts) exports only a single entity, it's acceptable to use default exports instead of named exports.
contracts/test/arbitration/staking-neo.ts (9)
Learnt from: jaybuidl
PR: #1620
File: contracts/test/arbitration/draw.ts:84-84
Timestamp: 2024-11-05T11:32:11.238Z
Learning: In TypeScript code using ethers.js version 6, contract.target should be used instead of contract.address to access a contract's address.
Learnt from: jaybuidl
PR: #1746
File: contracts/config/courts.v2.mainnet-neo.json:167-170
Timestamp: 2024-11-19T16:31:08.965Z
Learning: In contracts/config/courts.v2.mainnet-neo.json, the minStake parameter is denominated in PNK, not ETH.
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
Learnt from: jaybuidl
PR: #1746
File: contracts/config/courts.v2.mainnet-neo.json:3-5
Timestamp: 2024-11-19T17:18:39.007Z
Learning: In contracts/config/courts.v2.mainnet-neo.json, the General Court (id: 1) intentionally references itself as its parent ("parent": 1). This self-reference is acceptable and should not be flagged as an issue in future reviews.
Learnt from: Harman-singh-waraich
PR: #1703
File: kleros-sdk/src/sdk.ts:1-3
Timestamp: 2024-10-22T10:23:15.789Z
Learning: In kleros-sdk/src/sdk.ts, the PublicClient type is used and should not be flagged as unused.
Learnt from: Harman-singh-waraich
PR: #1703
File: kleros-sdk/src/requests/gqlClient.ts:18-18
Timestamp: 2024-10-24T08:16:02.749Z
Learning: In this TypeScript project, when a file (such as kleros-sdk/src/requests/gqlClient.ts) exports only a single entity, it's acceptable to use default exports instead of named exports.
Learnt from: Harman-singh-waraich
PR: #1846
File: prettier-config/index.js:26-26
Timestamp: 2025-01-23T08:14:47.397Z
Learning: The prettier-plugin-solidity plugin is installed in the kleros-v2 repository, even though it's not visible in the sandbox environment's node_modules (which is expected as node_modules is not committed to the repository).
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
contracts/deploy/00-home-chain-arbitration-neo.ts (7)
Learnt from: Harman-singh-waraich
PR: #1703
File: kleros-sdk/src/utils/getDispute.ts:38-40
Timestamp: 2024-10-21T10:32:16.970Z
Learning: The variables 'arbitrableChainID' and 'externalDisputeID' are required by the context to have uppercase 'ID', so they should remain unchanged even if the corresponding source properties use 'Id'.
Learnt from: jaybuidl
PR: #1746
File: contracts/config/courts.v2.mainnet-neo.json:3-5
Timestamp: 2024-11-19T17:18:39.007Z
Learning: In contracts/config/courts.v2.mainnet-neo.json, the General Court (id: 1) intentionally references itself as its parent ("parent": 1). This self-reference is acceptable and should not be flagged as an issue in future reviews.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
Learnt from: Harman-singh-waraich
PR: #1703
File: web/src/hooks/queries/usePopulatedDisputeData.ts:58-61
Timestamp: 2024-10-14T13:58:25.708Z
Learning: In web/src/hooks/queries/usePopulatedDisputeData.ts, the query and subsequent logic only execute when disputeData.dispute?.arbitrableChainId and disputeData.dispute?.externalDisputeId are defined, so initialContext properties based on these values are safe to use without additional null checks.
Learnt from: tractorss
PR: #1982
File: web/src/pages/Resolver/Landing/index.tsx:62-62
Timestamp: 2025-05-15T06:50:40.859Z
Learning: In the Landing component, it's safe to pass dispute?.dispute?.arbitrated.id as 0x${string} to usePopulatedDisputeData without additional null checks because the hook internally handles undefined parameters through its isEnabled flag and won't execute the query unless all required data is available.
Learnt from: jaybuidl
PR: #1746
File: contracts/config/courts.v2.mainnet-neo.json:167-170
Timestamp: 2024-11-19T16:31:08.965Z
Learning: In contracts/config/courts.v2.mainnet-neo.json, the minStake parameter is denominated in PNK, not ETH.
contracts/deploy/change-sortition-module-rng.ts (3)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
Learnt from: jaybuidl
PR: #1582
File: web-devtools/src/app/(main)/ruler/RulingModes.tsx:233-233
Timestamp: 2024-10-09T10:19:11.816Z
Learning: In 'web-devtools/src/app/(main)/ruler/RulingModes.tsx', the label 'Random Preset' is correct and should not be changed to 'Automatic Random'.
contracts/deploy/00-home-chain-arbitration.ts (3)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
contracts/test/arbitration/staking.ts (6)
Learnt from: jaybuidl
PR: #1620
File: contracts/test/arbitration/draw.ts:84-84
Timestamp: 2024-11-05T11:32:11.238Z
Learning: In TypeScript code using ethers.js version 6, contract.target should be used instead of contract.address to access a contract's address.
Learnt from: jaybuidl
PR: #1746
File: contracts/config/courts.v2.mainnet-neo.json:167-170
Timestamp: 2024-11-19T16:31:08.965Z
Learning: In contracts/config/courts.v2.mainnet-neo.json, the minStake parameter is denominated in PNK, not ETH.
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
Learnt from: Harman-singh-waraich
PR: #1703
File: kleros-sdk/src/requests/gqlClient.ts:18-18
Timestamp: 2024-10-24T08:16:02.749Z
Learning: In this TypeScript project, when a file (such as kleros-sdk/src/requests/gqlClient.ts) exports only a single entity, it's acceptable to use default exports instead of named exports.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: Harman-singh-waraich
PR: #1846
File: prettier-config/index.js:26-26
Timestamp: 2025-01-23T08:14:47.397Z
Learning: The prettier-plugin-solidity plugin is installed in the kleros-v2 repository, even though it's not visible in the sandbox environment's node_modules (which is expected as node_modules is not committed to the repository).
contracts/deploy/00-rng.ts (3)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
contracts/test/arbitration/dispute-kit-gated.ts (5)
Learnt from: Harman-singh-waraich
PR: #1703
File: web/src/hooks/queries/usePopulatedDisputeData.ts:58-61
Timestamp: 2024-10-14T13:58:25.708Z
Learning: In web/src/hooks/queries/usePopulatedDisputeData.ts, the query and subsequent logic only execute when disputeData.dispute?.arbitrableChainId and disputeData.dispute?.externalDisputeId are defined, so initialContext properties based on these values are safe to use without additional null checks.
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
Learnt from: Harman-singh-waraich
PR: #1716
File: web-devtools/src/app/(main)/dispute-template/CustomContextInputs.tsx:29-42
Timestamp: 2024-10-28T05:55:12.728Z
Learning: In the CustomContextInputs component located at web-devtools/src/app/(main)/dispute-template/CustomContextInputs.tsx, the DisputeRequestParams array is used to exclude certain variables from the custom input since they are already provided in a preceding component. Therefore, converting it to a type is unnecessary.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
contracts/src/arbitration/SortitionModuleNeo.sol (3)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
contracts/test/proxy/index.ts (3)
Learnt from: Harman-singh-waraich
PR: #1703
File: kleros-sdk/src/dataMappings/utils/actionTypes.ts:1-1
Timestamp: 2024-10-22T09:38:20.093Z
Learning: In the TypeScript file kleros-sdk/src/dataMappings/utils/actionTypes.ts, the Abi type is parsed later in the action functions, so importing Abi from viem in this file is unnecessary.
Learnt from: jaybuidl
PR: #1620
File: contracts/test/arbitration/draw.ts:84-84
Timestamp: 2024-11-05T11:32:11.238Z
Learning: In TypeScript code using ethers.js version 6, contract.target should be used instead of contract.address to access a contract's address.
Learnt from: Harman-singh-waraich
PR: #1703
File: kleros-sdk/src/requests/gqlClient.ts:18-18
Timestamp: 2024-10-24T08:16:02.749Z
Learning: In this TypeScript project, when a file (such as kleros-sdk/src/requests/gqlClient.ts) exports only a single entity, it's acceptable to use default exports instead of named exports.
contracts/test/integration/index.ts (7)
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
Learnt from: Harman-singh-waraich
PR: #1703
File: kleros-sdk/src/sdk.ts:1-3
Timestamp: 2024-10-22T10:23:15.789Z
Learning: In kleros-sdk/src/sdk.ts, the PublicClient type is used and should not be flagged as unused.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: Harman-singh-waraich
PR: #1703
File: kleros-sdk/src/requests/gqlClient.ts:18-18
Timestamp: 2024-10-24T08:16:02.749Z
Learning: In this TypeScript project, when a file (such as kleros-sdk/src/requests/gqlClient.ts) exports only a single entity, it's acceptable to use default exports instead of named exports.
Learnt from: jaybuidl
PR: #1964
File: contracts/scripts/shutter.ts:3-3
Timestamp: 2025-04-30T22:12:25.476Z
Learning: In Node.js, importing the crypto module as import crypto from "crypto" is a valid approach when using methods like crypto.randomBytes(). This import style works fine and doesn't need to be changed to a destructured import when these methods are used.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
Learnt from: Harman-singh-waraich
PR: #1739
File: web/src/pages/Home/TopJurors/JurorCard/Coherency.tsx:22-26
Timestamp: 2024-11-07T10:48:16.774Z
Learning: In the Coherency component (web/src/pages/Home/TopJurors/JurorCard/Coherency.tsx), totalResolvedVotes is always greater than or equal to totalCoherentVotes. When both are zero, 0/0 results in NaN, which is acceptable in this context.
contracts/test/arbitration/draw.ts (6)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1582
File: web-devtools/src/app/(main)/ruler/RulingModes.tsx:233-233
Timestamp: 2024-10-09T10:19:11.816Z
Learning: In 'web-devtools/src/app/(main)/ruler/RulingModes.tsx', the label 'Random Preset' is correct and should not be changed to 'Automatic Random'.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
Learnt from: jaybuidl
PR: #1746
File: contracts/config/courts.v2.mainnet-neo.json:167-170
Timestamp: 2024-11-19T16:31:08.965Z
Learning: In contracts/config/courts.v2.mainnet-neo.json, the minStake parameter is denominated in PNK, not ETH.
Learnt from: jaybuidl
PR: #1746
File: contracts/config/courts.v2.mainnet-neo.json:167-170
Timestamp: 2024-11-19T16:31:08.965Z
Learning: In the court hierarchy, child courts' minStake must be greater than or equal to their parent court's minStake.
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
contracts/src/rng/IncrementalNG.sol (2)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
contracts/src/arbitration/SortitionModuleBase.sol (2)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
contracts/src/rng/IRNG.sol (2)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
contracts/src/arbitration/SortitionModule.sol (2)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
contracts/test/foundry/KlerosCore.t.sol (3)
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
contracts/src/rng/BlockhashRNG.sol (2)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
contracts/src/rng/RandomizerRNG.sol (2)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
contracts/src/rng/RNGWithFallback.sol (1)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
contracts/src/rng/ChainlinkRNG.sol (2)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
contracts/test/rng/index.ts (4)
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/ChainlinkRNG.sol:135-153
Timestamp: 2024-12-07T11:39:10.927Z
Learning: In the contracts/src/rng/ChainlinkRNG.sol contract, the requestRandomness function is restricted to being called only by the SortitionModule, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.
Learnt from: jaybuidl
PR: #1778
File: contracts/src/rng/RandomizerRNG.sol:21-21
Timestamp: 2024-12-07T11:41:15.835Z
Learning: Only the SortitionModule can call requestRandomness, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In useGenesisBlock.ts, within the useEffect hook, the conditions (isKlerosUniversity, isKlerosNeo, isTestnetDeployment) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.
Learnt from: Harman-singh-waraich
PR: #1744
File: web/src/hooks/queries/useHomePageBlockQuery.ts:71-71
Timestamp: 2024-11-19T05:29:56.238Z
Learning: In web/src/hooks/queries/useHomePageBlockQuery.ts, the non-null assertions on blockNumber! and genesisBlock! within queryFn are safe because isEnabled ensures that queryFn only runs when either blockNumber or genesisBlock is defined.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (15)
- GitHub Check: Redirect rules - kleros-v2-testnet-devtools
- GitHub Check: Redirect rules - kleros-v2-neo
- GitHub Check: Header rules - kleros-v2-testnet-devtools
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-neo
- GitHub Check: Pages changed - kleros-v2-testnet-devtools
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-neo
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: SonarCloud
- GitHub Check: Analyze (javascript)
- GitHub Check: contracts-testing
🔇 Additional comments (63)
contracts/test/proxy/index.ts (1)
7-8: Avoid deep-linking intotypechain-types– prefer barrel exports for stabilityPointing directly to
../../typechain-types/src/proxy/mock/by-rewrite/UpgradedByRewrite.solmakes the test depend on the internal folder structure generated by TypeChain.
A future refactor (e.g. changingoutDir, renaming the solidity file, or upgrading TypeChain) will break this path silently while the re-exported barrel../../typechain-typeswould stay intact.Two low-friction options:
-import { UpgradedByRewrite as UpgradedByRewriteV1 } from "../../typechain-types/src/proxy/mock/by-rewrite/UpgradedByRewrite.sol"; +import type { UpgradedByRewrite as UpgradedByRewriteV1 } from "../../typechain-types";or add a manual re-export in
typechain-types/index.tsduring code-gen to expose the duplicate names cleanly (e.g.UpgradedByRewriteV1,UpgradedByRewriteV2).Either keeps the import resilient and removes the brittle deep path.
[ suggest_optional_refactor ]cspell.json (1)
38-38: LGTM! Necessary addition for the RNG interface refactoring.Adding "IRNG" to the spell checker dictionary is correct and necessary to support the interface rename from
RNGtoIRNGthroughout the codebase.contracts/deploy/00-chainlink-rng.ts (1)
74-74: Good addition! Helpful deployment guidance.Adding the console message with the Chainlink VRF registration link provides useful post-deployment guidance for users.
contracts/test/utils/getActualAddress.ts (1)
11-11: LGTM! Updated to modern import assertion syntax.The change from
assert: { type: "json" }towith: { type: "json" }aligns with the current JavaScript/TypeScript standard for import assertions.contracts/test/arbitration/dispute-kit-gated.ts (2)
64-64: LGTM! Correctly updated for simplified RNG interface.The method call now correctly passes only the RNG address, reflecting the removal of the RNG lookahead parameter from the interface.
141-144: LGTM! Simplified block mining logic.The removal of the RNG lookahead-based block mining loop and replacement with single block mining correctly reflects the interface changes where timing is now based on timestamps rather than block lookahead.
contracts/test/arbitration/staking-neo.ts (2)
59-65: LGTM! Improved TypeScript type safety.Using generic type parameters with
ethers.getContract<T>()is cleaner and provides better type safety than explicit type assertions.
108-108: LGTM! Correctly simplified block mining logic.The change from mining multiple blocks based on RNG lookahead to mining a single block correctly reflects the removal of the lookahead parameter from the RNG interface.
contracts/test/arbitration/draw.ts (2)
84-84: LGTM: Simplified RNG configuration callThe removal of the second argument from
changeRandomNumberGeneratorcorrectly aligns with the new IRNG interface that eliminates the lookahead parameter.
177-177: LGTM: Simplified phase transition logicThe removal of the block mining loop that previously handled RNG lookahead is correct. The new IRNG interface no longer requires block-based timing, making this simplification appropriate.
contracts/src/rng/IRNG.sol (1)
1-13: LGTM: Well-designed RNG interfaceThe new IRNG interface is clean and simplified compared to the previous RNG interface. The removal of block-based parameters and the clear function signatures align well with the PR objectives. The documentation is appropriate and the interface follows Solidity best practices.
contracts/deploy/change-sortition-module-rng.ts (2)
26-27: LGTM: Updated to use new consumer role methodThe change from
changeSortitionModuletochangeConsumercorrectly reflects the refactoring of RNG contracts where the authorized role was renamed fromsortitionModuletoconsumer.
29-30: LGTM: Simplified RNG configurationThe removal of the second argument from
changeRandomNumberGeneratoris consistent with the elimination of the lookahead parameter in the new IRNG interface.contracts/deploy/00-rng.ts (3)
10-10: LGTM: Transition to time-based lookaheadThe change from
RNG_LOOKAHEAD(block-based) toRNG_LOOKAHEAD_TIME(time-based) with a 30-minute value aligns with the RNG refactoring that moves away from block-based timing mechanisms.
34-38: LGTM: Updated BlockHashRNG constructor argumentsThe constructor arguments correctly reflect the new BlockHashRNG interface that takes a governor, consumer, and time-based lookahead parameter instead of the previous block-based approach.
42-42: LGTM: Simplified sortition module configurationThe single-argument call to
changeRandomNumberGeneratoris consistent with the removal of the lookahead parameter from the sortition module interface.contracts/deploy/00-home-chain-arbitration.ts (2)
55-55: LGTM: Updated SortitionModule constructorThe removal of the RNG lookahead parameter from the SortitionModule constructor correctly aligns with the interface changes that eliminate block-based timing dependencies.
88-93: LGTM: Improved RNG consumer managementThe change to use
changeConsumerinstead ofchangeSortitionModuleis correct, and the conditional check before calling the method is a good optimization that avoids unnecessary transactions.contracts/test/integration/index.ts (1)
206-208: LGTM! Improved type safety with explicit parameter typing.The explicit typing of the function parameter enhances type safety and makes the expected structure clear, which is a good practice in TypeScript.
contracts/src/arbitration/SortitionModule.sol (3)
5-5: LGTM! Interface abstraction improvement.The change from concrete RNG type to IRNG interface provides better abstraction and aligns with the PR's objective to introduce a composite RNG with fallback logic.
32-32: LGTM! Parameter updated to match new interface.The change from RNG to IRNG parameter and removal of _rngLookahead aligns with the PR objectives to use the new IRNG interface and remove block-based lookahead logic.
34-34: LGTM! Base initializer call updated correctly.The removal of _rngLookahead parameter from the base initializer call is consistent with the function signature changes and the broader refactor to remove block-based RNG timing.
contracts/deploy/00-home-chain-arbitration-neo.ts (3)
13-13: LGTM! Cleanup of unused deployment method.Removing the unused
executemethod from the destructured deployments object improves code clarity by only importing what's needed.
52-52: LGTM! Deployment arguments updated to match contract changes.The removal of RNG_LOOKAHEAD parameter from the SortitionModuleNeo deployment arguments correctly aligns with the contract's updated initialize() function signature.
86-91: LGTM! RNG linkage updated to use consumer pattern.The changes from
changeSortitionModule/sortitionModule()tochangeConsumer/consumer()correctly implement the new RNG consumer role pattern mentioned in the PR objectives.contracts/test/arbitration/staking.ts (3)
30-34: LGTM! Improved TypeScript contract retrieval with generics.Using TypeScript generics instead of type casting provides better type safety and is more idiomatic. This is a good improvement over the previous
as ContractTypeapproach.
57-57: LGTM! Block mining simplified after RNG lookahead removal.The single
evm_minecall replaces the previous lookahead-based block mining logic, correctly reflecting the shift from block-based to time-based randomness readiness.
394-395: LGTM! Consistent simplification of block mining logic.The single block mine after phase transition maintains consistency with the updated RNG timing model throughout the test suite.
contracts/src/arbitration/SortitionModuleNeo.sol (3)
5-5: LGTM! Import statement updated consistently with interface refactor.The change to import IRNG interface instead of concrete RNG type follows the same pattern as SortitionModule.sol and supports the overall interface abstraction effort.
42-42: LGTM! Parameter signature updated consistently with base module.The change from RNG to IRNG parameter and removal of _rngLookahead maintains consistency with SortitionModule.sol while preserving the Neo-specific parameters.
46-46: LGTM! Base initializer call updated to match interface changes.The removal of _rngLookahead parameter from the base initializer call is consistent with the updated SortitionModuleBase interface and follows the same pattern as SortitionModule.sol.
contracts/src/rng/IncrementalNG.sol (4)
4-4: LGTM! Interface import updated correctly.The import has been properly updated to use the new
IRNGinterface.
6-9: LGTM! Contract declaration and comments updated appropriately.The contract now correctly implements the
IRNGinterface instead of inheriting from the deprecatedRNGclass. The comments have been updated to reflect the simplified interface.
17-19: LGTM! Function signature simplified correctly.The
requestRandomness()function signature has been properly simplified by removing the unused_blockparameter, aligning with the newIRNGinterface. The no-op implementation remains appropriate for this testing contract.
23-27: LGTM! Function signature simplified correctly.The
receiveRandomness()function signature has been properly simplified by removing the unused_blockparameter. The incremental logic remains intact and appropriate for testing purposes.contracts/src/arbitration/SortitionModuleBase.sol (5)
10-10: LGTM! Import updated to new IRNG interface.The import has been correctly updated to use the new
IRNGinterface.
54-54: LGTM! Storage variable type updated correctly.The
rngstorage variable has been properly updated to use theIRNGinterface type.
105-105: LGTM! Constructor parameter updated correctly.The constructor parameter has been properly updated to accept an
IRNGinstance instead of the deprecatedRNGtype.
152-159: LGTM! Function updated with simplified RNG interface.The
changeRandomNumberGeneratorfunction has been correctly updated:
- Parameter type changed to
IRNG- Function name and comments updated appropriately
- Call to
requestRandomness()simplified by removing the block parameterThe logic maintains the same behavior while using the simplified interface.
172-172: LGTM! RNG method calls simplified correctly.The calls to
requestRandomness()andreceiveRandomness()have been properly simplified by removing the block parameters, aligning with the newIRNGinterface. This removes the unnecessary block-based timing complexity while maintaining the same phase transition logic.Also applies to: 175-175
contracts/test/foundry/KlerosCore.t.sol (6)
55-55: Comment accurately reflects the time-based approach.The comment update from block-based to time-based properly documents the semantic change in the RNG lookahead mechanism.
95-96: Significant increase in RNG lookahead time.The rngLookahead value has been increased from 20 to 600 seconds (10 minutes), which is a more realistic timing for RNG operations. This aligns with the shift to timestamp-based randomness and should provide adequate time for RNG fulfillment in production-like scenarios.
106-111: Simplified SortitionModule initialization.The removal of
rngLookaheadfrom the SortitionModule initialization parameters correctly reflects the architectural change where RNG timing is now managed at the RNG contract level rather than the consumer level.
116-117: Proper RNG consumer linkage with governor privileges.The explicit
changeConsumercall with governor privileges correctly implements the new RNG permission model, ensuring only authorized consumers can request randomness.
287-298: Consistent RNG initialization pattern in event tests.The initialization sequence correctly follows the new pattern: first initialize the SortitionModule, then link it as the RNG consumer with governor privileges.
1006-1006: Consistent implementation of timestamp-based RNG readiness.All instances of
vm.roll(block.number + rngLookahead + 1)have been correctly replaced withvm.warp(block.timestamp + rngLookahead), implementing the shift from block-based to timestamp-based RNG mechanics throughout the test suite.Also applies to: 1053-1053, 1080-1080, 1136-1136, 1424-1424, 1483-1483, 1526-1526, 1636-1636, 1661-1661, 1772-1772, 1799-1799, 1840-1840, 1889-1889, 1979-1979, 2023-2023, 2119-2119, 2197-2197, 2231-2231, 2243-2243, 2349-2349, 2424-2424, 2470-2470, 2525-2525, 2615-2615, 2669-2669, 2708-2708, 2762-2762, 2805-2805, 2899-2899
contracts/test/rng/index.ts (3)
24-30: LGTM! Test correctly updated for new IRNG interface.The removal of numeric arguments from
receiveRandomnesscalls aligns with the simplified IRNG interface.
96-109: LGTM! ChainlinkRNG tests properly updated.Good use of the shared
abiCoderinstance and correct removal of unused parameters.
155-202: LGTM! RandomizerRNG tests correctly updated.Tests properly handle the simplified interface and maintain good coverage for both single and multiple request scenarios.
contracts/src/rng/RandomizerRNG.sol (3)
5-10: LGTM! Correct interface migration to IRNG.The contract properly implements the new IRNG interface as part of the broader RNG refactoring.
16-16: LGTM! Consumer role properly implemented.The migration from
sortitionModuletoconsumeris complete and consistent throughout the contract, maintaining proper access control.Also applies to: 44-47, 54-62, 74-78
102-107: LGTM! Randomness functions correctly simplified.The removal of block parameters aligns with the IRNG interface. The lack of concurrent request handling is acceptable as confirmed by previous learnings that only the SortitionModule (now consumer) calls these functions without concurrent requests.
Also applies to: 124-126
contracts/src/rng/ChainlinkRNG.sol (3)
8-12: LGTM! Proper interface implementation and consistent event naming.The contract correctly implements IRNG while maintaining Chainlink VRF integration through VRFConsumerBaseV2Plus inheritance. Event parameter naming is consistent.
Also applies to: 32-38
18-18: LGTM! Consumer role properly implemented with correct access control.The migration from sortitionModule to consumer is complete and maintains proper authorization checks.
Also applies to: 49-52, 94-98
135-153: LGTM! VRF v2.5 integration with native ETH payment.The implementation correctly uses Chainlink VRF v2.5 with native ETH payment enabled. The lack of concurrent request handling aligns with the design constraint that only one consumer makes requests.
contracts/src/rng/BlockhashRNG.sol (3)
13-50: LGTM! Well-structured contract with appropriate L2 considerations.Good use of
immutableforlookaheadTimeand clear role separation. The timestamp-based approach is appropriate for L2 environments with sporadic block production.
109-119: LGTM! Useful view functions for checking randomness readiness.The view functions properly handle the case where no request has been made and provide clear information about when randomness will be available.
79-101: Ignore blockhash and timestamp‐collision concernsThe two raised issues don’t apply here:
- Using
blockhash(block.number - 1)always returns the hash of the immediately previous block, which is guaranteed to be within the last 256 blocks, so it will never be 0 due to the EVM’s 256-block limit.- The contract only tracks a single outstanding request via
requestTimestamp(overwritten on each call) and restricts calls to the designatedconsumer, so you cannot have concurrent requests mapping to the same key—no collision risk.No changes needed.
Likely an incorrect or invalid review comment.
contracts/src/rng/RNGWithFallback.sol (5)
42-49: LGTM! Proper initialization with input validation.Good validation of the default RNG address and proper initialization of the RNG array.
147-158: Missing validation in removeLastRngFallback.The function doesn't check if the RNG being removed has any pending requests or if it's currently being used. This could lead to failed randomness retrieval.
Consider adding validation to ensure safe removal.
function removeLastRngFallback() external onlyByGovernor { require(rngs.length > 1, "No fallback RNG"); + require(currentRngIndex < rngs.length - 1, "Cannot remove active RNG");⛔ Skipped due to learnings
Learnt from: jaybuidl PR: kleros/kleros-v2#1778 File: contracts/src/rng/ChainlinkRNG.sol:135-153 Timestamp: 2024-12-07T11:39:10.927Z Learning: In the `contracts/src/rng/ChainlinkRNG.sol` contract, the `requestRandomness` function is restricted to being called only by the `SortitionModule`, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.Learnt from: jaybuidl PR: kleros/kleros-v2#1778 File: contracts/src/rng/RandomizerRNG.sol:21-21 Timestamp: 2024-12-07T11:41:15.835Z Learning: Only the `SortitionModule` can call `requestRandomness`, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
129-136: Risk in changeDefaultRng when taking over pending requests.Calling
_requestRandomness(DEFAULT_RNG)during RNG change could fail if the new RNG is not ready or properly configured, potentially leaving the contract in an inconsistent state.Consider adding try-catch or validation before attempting to take over requests.
⛔ Skipped due to learnings
Learnt from: jaybuidl PR: kleros/kleros-v2#1778 File: contracts/src/rng/ChainlinkRNG.sol:135-153 Timestamp: 2024-12-07T11:39:10.927Z Learning: In the `contracts/src/rng/ChainlinkRNG.sol` contract, the `requestRandomness` function is restricted to being called only by the `SortitionModule`, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.Learnt from: jaybuidl PR: kleros/kleros-v2#1778 File: contracts/src/rng/RandomizerRNG.sol:21-21 Timestamp: 2024-12-07T11:41:15.835Z Learning: Only the `SortitionModule` can call `requestRandomness`, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
84-109: Issues with fallback mechanism in receiveRandomness.Several concerns:
- Makes external calls without reentrancy protection
- When falling back, immediately calls
_requestRandomnesswhich might fail if the next RNG requires specific conditions- No validation that the fallback RNG is operational before switching
Consider adding more robust error handling and validation of RNG availability.
⛔ Skipped due to learnings
Learnt from: jaybuidl PR: kleros/kleros-v2#1778 File: contracts/src/rng/ChainlinkRNG.sol:135-153 Timestamp: 2024-12-07T11:39:10.927Z Learning: In the `contracts/src/rng/ChainlinkRNG.sol` contract, the `requestRandomness` function is restricted to being called only by the `SortitionModule`, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.Learnt from: jaybuidl PR: kleros/kleros-v2#1778 File: contracts/src/rng/RandomizerRNG.sol:21-21 Timestamp: 2024-12-07T11:41:15.835Z Learning: Only the `SortitionModule` can call `requestRandomness`, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
70-80: Potential reentrancy vulnerability in requestRandomness.The contract updates state variables before making an external call to
rngs[_rngIndex].requestRandomness(). A malicious RNG could potentially call back into this contract.Consider using reentrancy guards or following checks-effects-interactions pattern more strictly.
+import "@openzeppelin/contracts/utils/ReentrancyGuard.sol"; -contract RNGWithFallback is IRNG { +contract RNGWithFallback is IRNG, ReentrancyGuard { - function requestRandomness() external override onlyByConsumer { + function requestRandomness() external override onlyByConsumer nonReentrant { - function receiveRandomness() external override onlyByConsumer returns (uint256 randomNumber) { + function receiveRandomness() external override onlyByConsumer nonReentrant returns (uint256 randomNumber) {⛔ Skipped due to learnings
Learnt from: jaybuidl PR: kleros/kleros-v2#1778 File: contracts/src/rng/ChainlinkRNG.sol:135-153 Timestamp: 2024-12-07T11:39:10.927Z Learning: In the `contracts/src/rng/ChainlinkRNG.sol` contract, the `requestRandomness` function is restricted to being called only by the `SortitionModule`, which does not send concurrent requests. Therefore, it's acceptable not to handle multiple random number requests concurrently in this context.Learnt from: jaybuidl PR: kleros/kleros-v2#1778 File: contracts/src/rng/RandomizerRNG.sol:21-21 Timestamp: 2024-12-07T11:41:15.835Z Learning: Only the `SortitionModule` can call `requestRandomness`, and it doesn't send concurrent requests, so handling multiple concurrent random number requests is unnecessary in this context.
|
This PR is a redo of #966 and #1782 as they had deviated too much from dev. It was originally based atop the
feat/chainlink-vrf-as-rng2branch (PR #1778).This PR introduces a
RNGWithFallbackresponsible for the fallback logic.We ensure that repeated calls to
SM.passPhase()does not result in repeated calls to the default RNG or the fallback RNG as it would keep overwriting therequestIDfor VRF-based RNGs or therequestBlockfor the BlockhashRNG.The RNGs are permissioned to prevent 3rd parties from using up the funds on the RNG oracle accounts with Chainlink or Randomizer.
The RNGs do not support concurrent requests, it is not necessary since only 1 consumer is allowed (the sortition module), with the notable exception of some governance function triggering a re-request, which invalidates the previous one.
We rely on
block.timestamprather thanblock.numberbecause it is a more reliable measure of the elapsed time on Arbitrum, as block production is sporadic depending on network conditions.ABI changes
RNGinterface renamedIRNG_blockparameter from theIRNGinterface which is not necessary for VRFs, only for the BlockHashRNG which now tracks it internallyPR-Codex overview
This PR focuses on refactoring the random number generator (RNG) implementation in the Kleros arbitration system, replacing the
RNGinterface with a newIRNGinterface across various contracts, and adjusting related functionalities accordingly.Detailed summary
RNG.solcspell.json.IRNGinterface incontracts/src/rng/IRNG.sol.RNGreferences toIRNGin multiple contracts.ChainlinkRNG,RandomizerRNG, andBlockHashRNGto useIRNG.rngLookaheadparameter from several functions and contracts.Summary by CodeRabbit
New Features
Refactor
Bug Fixes
Tests
Chores
Documentation