Skip to content

Conversation

@abi87
Copy link
Contributor

@abi87 abi87 commented Apr 20, 2023

Why this should be merged

How this works

Post Continuous Staking fork activation:

  1. Forced txs.Validator.StartTime to zero. User won't specify start time. Instead currentChainTime will be picked for stakers' start time.
  2. Reused txs.Validator.EndTime attribute to indicate staking period duration rather than exact end time. EndTime is set to +infinity (aka mockable.MaxTime).
  3. Modified state.Staker invariants. NextTime is not anymore equal to StartTime or EndTime. Instead it will mark the chain time when a staker should be evaluated for rewards.
  4. Updated AddStakerTxs verification to make restaking the default behaviour. TODO: fix delegators/subnet validators end time checks wrt pre fork or stopped validator.
  5. Changed reward logic for permissionless validators. Post Continuous Staking Fork validators are not removed from stakers set, nor their stake is returned. Instead reward utxos are generated and made available to staker.
  6. Changed reward logic for permissionless delegators
    6.Added stopStakerTx to explicitly stop staking. Duly handled delegators/subnet validators termination when their validator is requested to stop.

How this was tested

Updated UTs to test the latest fork + added UTs
Todo: e2e tests with ginkgo

@abi87 abi87 changed the base branch from master to stakerTxs_drop_start_time April 20, 2023 17:41
@abi87 abi87 force-pushed the continuous_staking_by_default branch from e9e6175 to 845b5bf Compare April 24, 2023 17:19
@abi87 abi87 self-assigned this Apr 26, 2023
joshua-kim pushed a commit to joshua-kim/avalanchego that referenced this pull request Apr 28, 2023
Co-authored-by: abenegia <alberto.benegiamo@gmail.com>
@abi87 abi87 force-pushed the continuous_staking_by_default branch from 1ad8ca7 to 38fccba Compare May 2, 2023 13:45
@abi87 abi87 changed the title Continuous Staking: restake permissionless stakers by default Continuous Staking 3 - Restake permissionless stakers by default May 2, 2023
@abi87 abi87 changed the title Continuous Staking 3 - Restake permissionless stakers by default Continuous Staking 3 - WIP Restake permissionless stakers by default May 11, 2023
@abi87 abi87 added the DO NOT MERGE This PR must not be merged in its current state label May 11, 2023
@abi87 abi87 changed the title Continuous Staking 3 - WIP Restake permissionless stakers by default Continuous Staking WIP - Restake permissionless stakers by default May 23, 2023
@github-actions
Copy link

This PR has become stale because it has been open for 30 days with no activity. Adding the lifecycle/frozen label will cause this PR to ignore lifecycle events.

@github-actions
Copy link

github-actions bot commented Aug 6, 2023

This PR has become stale because it has been open for 30 days with no activity. Adding the lifecycle/frozen label will cause this PR to ignore lifecycle events.

@abi87
Copy link
Contributor Author

abi87 commented Aug 22, 2023

superseeded by different design

@abi87 abi87 closed this Aug 22, 2023
@StephenButtolph StephenButtolph deleted the continuous_staking_by_default branch July 24, 2024 20:46
maru-ava pushed a commit that referenced this pull request Dec 3, 2025
Fix a critical bug where nodes were written to storage before the
freelist was updated, leaving the database in an inconsistent state if
an I/O error occurred during node persistence.

Problem:
When persisting nodes, if the freelist flush happened after node writes,
a crash or I/O error between node writes and freelist flush would leave
allocated storage space untracked in the freelist. On recovery, these
areas could be reallocated, leading to data corruption or loss.

Solution:
- Flush freelist immediately after allocating node addresses but before
writing any node data
- Add NodeAllocator::flush_freelist() to enable explicit freelist
updates
- Add flush_freelist_from() to persist a specific header's freelist
state

Additional improvements:
- Refactor to use bumpalo bump allocator with bounded memory for node
serialization (prevents unbounded memory growth)
- Extract common serialization and batching logic into shared helper
functions (serialize_node_to_bump, process_unpersisted_nodes)
- Eliminate ~90 lines of code duplication between io-uring and
non-io-uring paths while ensuring both use identical logic
maru-ava pushed a commit that referenced this pull request Dec 3, 2025
#1488 found a panic during serialization of a node, indicating that a
child node was either not hashed or not allocated and therefore could
not serialize the parent node. After a walk through of the code, I
noticed that after #1389, we began serializing nodes in batches in order
to prevent corrupting the free-list after a failed write and introduced
a case where this could occur. Previously, we would serialize a node,
write it to storage, and then mark it as allocated in one step. Now we
serialize and allocate the node and add the node to a batch before
moving onto the next node. Like before, we only mark the node as
allocated after writing it to disk. This means that if the batch
contained child and parent, the parent node fails to serialize because
it cannot reference the address.

This change refactors the allocation logic to mark nodes as allocated
during batching. This ensures that if its parent is also in the batch,
it can successfully serialize. This linear address itself is not read
from by viewers of the `Allocated` state because the node is not
considered committed until the entire write has completed (i.e., after
the root and header are written). This means this change does not
introduce any early reads of uncommitted data.

In the course of writing tests, I discovered that the arena allocator
returns the number of bytes by the arena, not the number of bytes
occupied by items within the arena. This meant that the batching logic
should have always generated a batch of 1 element. To fix this, I track
the allocated length of each area. This successfully triggered the bug I
discovered; however, this also means the bug might not be the source of
the original panic.
JonathanOppenheimer pushed a commit that referenced this pull request Dec 3, 2025
* fix start timestamp

* add client

* rename sov to l1validator

* bump avago to v1.11.13-rc.1

* update compatibility
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

DO NOT MERGE This PR must not be merged in its current state lifecycle/stale

Projects

No open projects
Archived in project

Development

Successfully merging this pull request may close these issues.

2 participants