Skip to content
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.

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

Rely on strict increasing order in checkpoints lookups #4544

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

0xVolosnikov
Copy link
Contributor

@0xVolosnikov 0xVolosnikov commented Aug 28, 2023

Implements what is mentioned in :
#4540 (comment)

I'm very interested in why the library relies on non-strictly increasing order everywhere, like here:

if (_unsafeAccess(self, mid)._key > key) {

Based on the descriptions of the functions, it looks like they were created with the expectation that there may be elements with the same keys:

* @dev Return the index of the last (most recent) checkpoint with key lower or equal than the search key, or `high` if there is none.

At the same time, the insertion implementation does not allow adding multiple elements with the same key. This, of course, can be done manually by forcibly adding an element to the array. But you can also add an incorrect element (with a decreasing key) in such way. So it doesn't look like there should be multiple elements with the same key in an array in normal use of the library.

If the array is strictly ordered, then it is strange that the search does not handle the case when it hits the desired key (the case of equality). In the worst case, if the array is N long and the target is exactly in the middle, the current implementation will do something like log2(n) - 1 excessive reads of cold storage slots (~2100 gas each).

So with simple example like (keys) [2, 3, 5, 7, 11, 12, 13, 14] i tried two implementations of lowerLookup: current and with separate handling of equality. Gas estimations for lowerLookup(11) (including 21000 “base fee”):
current version: 31712
modified version: 26762

I'm interested if there's a reason not to make such changes.

PR Checklist

  • Tests
  • Documentation
  • Changeset entry (run npx changeset add)

@changeset-bot
Copy link

changeset-bot bot commented Aug 28, 2023

⚠️ No Changeset found

Latest commit: ae045d8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants