Conversation
hai-rise
requested review from
datnguyencse,
duyquang6,
kien-rise and
phuocthanhdo
as code owners
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the nonce check logic in the Rise chain implementation to be more concise and updates the initial capacity of the WriteSet in the VM to better accommodate fee recipients on OP Stack chains. The reviewer suggests that instead of hardcoding the capacity to 6, a more robust approach would be to initialize the WriteSet based on the actual state length after the journal is finalized to avoid unnecessary reallocations.
| // There are at least six locations most of the time: the sender, | ||
| // the recipient, and up to four fee recipients (beneficiary, base fee, | ||
| // L1 fee, operator fee on OP Stack chains). | ||
| let mut write_set = WriteSet::with_capacity(6); |
There was a problem hiding this comment.
While increasing the capacity to 6 is a good heuristic for simple transactions on OP Stack chains, complex transactions touching many accounts will still trigger multiple reallocations. A more robust approach would be to initialize write_set after the journal is finalized, using the resulting state's length as a base for the capacity. This would minimize reallocations in the hot path for all transaction types.
1 participant
No description provided.