Skip to content

Conversation

0xClandestine
Copy link
Member

@0xClandestine 0xClandestine commented Jun 10, 2025

Motivation:

Previously, we stored startBlock and computed the completeBlock at runtime by iterating through the list of added strategies for a given slashId. This approach required recalculating the completeBlock each time.

Modifications:

We now store completeBlock directly instead of startBlock. During each call to initiateSlashEscrow, we compare the delay of the newly added strategy to the current completeBlock for the slashId. If the new delay is larger, we update completeBlock accordingly. This ensures that the maximum delay is always preserved.

Result:

The completeBlock for each slashId is now computed and maintained incrementally, eliminating the need for runtime iteration over all strategies.

@ypatil12
Copy link
Collaborator

Old PR: #1444

@0xClandestine 0xClandestine merged commit 25cad96 into release-dev/redistribution-changes Jun 10, 2025
10 checks passed
@0xClandestine 0xClandestine deleted the fix/out-of-gas-issue branch June 10, 2025 22:39
0xClandestine added a commit that referenced this pull request Jul 1, 2025
**Motivation:**

Previously, we stored `startBlock` and computed the `completeBlock` at
runtime by iterating through the list of added strategies for a given
`slashId`. This approach required recalculating the `completeBlock` each
time.

**Modifications:**

We now store `completeBlock` directly instead of `startBlock`. During
each call to `initiateSlashEscrow`, we compare the delay of the newly
added strategy to the current `completeBlock` for the `slashId`. If the
new delay is larger, we update `completeBlock` accordingly. This ensures
that the maximum delay is always preserved.

**Result:**

The `completeBlock` for each `slashId` is now computed and maintained
incrementally, eliminating the need for runtime iteration over all
strategies.
0xClandestine added a commit that referenced this pull request Jul 2, 2025
**Motivation:**

Previously, we stored `startBlock` and computed the `completeBlock` at
runtime by iterating through the list of added strategies for a given
`slashId`. This approach required recalculating the `completeBlock` each
time.

**Modifications:**

We now store `completeBlock` directly instead of `startBlock`. During
each call to `initiateSlashEscrow`, we compare the delay of the newly
added strategy to the current `completeBlock` for the `slashId`. If the
new delay is larger, we update `completeBlock` accordingly. This ensures
that the maximum delay is always preserved.

**Result:**

The `completeBlock` for each `slashId` is now computed and maintained
incrementally, eliminating the need for runtime iteration over all
strategies.
0xClandestine added a commit that referenced this pull request Jul 2, 2025
**Motivation:**

Previously, we stored `startBlock` and computed the `completeBlock` at
runtime by iterating through the list of added strategies for a given
`slashId`. This approach required recalculating the `completeBlock` each
time.

**Modifications:**

We now store `completeBlock` directly instead of `startBlock`. During
each call to `initiateSlashEscrow`, we compare the delay of the newly
added strategy to the current `completeBlock` for the `slashId`. If the
new delay is larger, we update `completeBlock` accordingly. This ensures
that the maximum delay is always preserved.

**Result:**

The `completeBlock` for each `slashId` is now computed and maintained
incrementally, eliminating the need for runtime iteration over all
strategies.
ypatil12 pushed a commit that referenced this pull request Jul 7, 2025
**Motivation:**

Previously, we stored `startBlock` and computed the `completeBlock` at
runtime by iterating through the list of added strategies for a given
`slashId`. This approach required recalculating the `completeBlock` each
time.

**Modifications:**

We now store `completeBlock` directly instead of `startBlock`. During
each call to `initiateSlashEscrow`, we compare the delay of the newly
added strategy to the current `completeBlock` for the `slashId`. If the
new delay is larger, we update `completeBlock` accordingly. This ensures
that the maximum delay is always preserved.

**Result:**

The `completeBlock` for each `slashId` is now computed and maintained
incrementally, eliminating the need for runtime iteration over all
strategies.
ypatil12 pushed a commit that referenced this pull request Jul 8, 2025
**Motivation:**

Previously, we stored `startBlock` and computed the `completeBlock` at
runtime by iterating through the list of added strategies for a given
`slashId`. This approach required recalculating the `completeBlock` each
time.

**Modifications:**

We now store `completeBlock` directly instead of `startBlock`. During
each call to `initiateSlashEscrow`, we compare the delay of the newly
added strategy to the current `completeBlock` for the `slashId`. If the
new delay is larger, we update `completeBlock` accordingly. This ensures
that the maximum delay is always preserved.

**Result:**

The `completeBlock` for each `slashId` is now computed and maintained
incrementally, eliminating the need for runtime iteration over all
strategies.
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.

2 participants