`core.getRoundInfo` has a cost O(N) and is consumed on-chain

[greenlucid]

This is the Round struct, which contains address[] drawnJurors, an array that in practice shouldn't contain more than 511 jurors:

kleros-v2/contracts/src/arbitration/KlerosCoreBase.sol

Line 53 in 01edde5

struct Round {

This is core.getRoundInfo

kleros-v2/contracts/src/arbitration/KlerosCoreBase.sol

Line 985 in 01edde5

return disputes[_disputeID].rounds[_round];

When you call it, it appears to return the drawnJurors array

This is the line of the contract that consumes core.getRoundInfo internally:

kleros-v2/contracts/src/arbitration/dispute-kits/DisputeKitClassicBase.sol

Line 622 in 01edde5

.getRoundInfo(_coreDisputeID, core.getNumberOfRounds(_coreDisputeID) - 1)

---

Since Kleros V1 has historically used 511 jurors, this is probably not a vulnerability, but some documentation to state the max number of jurors must be bounded would be needed. This limitation could be either in contract (revert when trying to raise jurorsPerCourtJump beyond a set number), or documentation.

Either that, or alternatively, excluding the drawnJurors from the view. Since KlerosV1 originally was designed around not having to limit the size of these dynamic arrays.

Testing around it (and asking ChatGPT around) seems that indeed, returning the value with an explicit getter, instead of the public getter automatically created with Solidity, will attempt to return dynamic arrays, both on-chain and on-chain

ethereum/solidity#12792

---

PoC made to check the issue, you can copypaste into Remix: https://gist.github.com/greenlucid/4b30b15ea782f0b15fe6a5f9c921c253

Gas spent to view: 1.3M gas for 511 jurors