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

timelock optimization #24

Merged
merged 11 commits into from
Jan 15, 2024
Merged

timelock optimization #24

merged 11 commits into from
Jan 15, 2024

Conversation

Flydexo
Copy link
Contributor

@Flydexo Flydexo commented Jan 1, 2024

Fixes: #19

Hey @moodysalem, Sorry for the delay, tell me if that corresponds to what you expect, if so I will complete this PR with all the files with the same method

Copy link
Member

@moodysalem moodysalem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not exactly, there is a StorePacking trait you can implement to keep the structs well named and pack them into a felt252

3 timestamps should fit in 192 bits, so you should use a felt252

Copy link
Member

@moodysalem moodysalem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you might want to add a pre-commit hook for scarb fmt

src/timelock.cairo Outdated Show resolved Hide resolved
src/timelock.cairo Outdated Show resolved Hide resolved
src/timelock.cairo Outdated Show resolved Hide resolved
src/timelock.cairo Outdated Show resolved Hide resolved
src/timelock.cairo Outdated Show resolved Hide resolved
src/timelock.cairo Outdated Show resolved Hide resolved
src/timelock.cairo Outdated Show resolved Hide resolved
src/timelock.cairo Outdated Show resolved Hide resolved
src/timelock.cairo Outdated Show resolved Hide resolved
latest: u64
}

#[inline(always)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does inline work on traits?

src/timelock.cairo Outdated Show resolved Hide resolved
src/timelock.cairo Outdated Show resolved Hide resolved
src/timelock.cairo Outdated Show resolved Hide resolved
fn get_execution_window(self: @ContractState, id: felt252) -> (u64, u64) {
let start_time = self.execution_started.read(id);
fn get_execution_window(self: @ContractState, id: felt252) -> ExecutionWindow {
let start_time = self.execution_state.read(id).started;

// this is how we prevent the 0 timestamp from being considered valid
assert(start_time != 0, 'DOES_NOT_EXIST');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm maybe we could just check that canceled is nonzero as well and remove the other logic changes. sorry, i realize this is out of scope for the initial pr.

let (earliest, latest) = self.get_execution_window(id);
assert(execution_state.executed.is_zero(), 'ALREADY_EXECUTED');

let execution_window = self.get_execution_window(id);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this causes a second read of the same slot

not super costly, but wasteful
better to revert if already executed or canceled from this function, since there is no execution window

@moodysalem
Copy link
Member

if you resolve conflicts we can merge

@moodysalem moodysalem merged commit 18f1596 into EkuboProtocol:main Jan 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

pack storage in timelock better
2 participants