Skip to content

Conversation

@krishvishal
Copy link
Contributor

@krishvishal krishvishal commented Jan 7, 2026

Implemented view_change from VSR-revisited paper.

@krishvishal krishvishal changed the title WIP: Implement view_change feat(cluster): Impl VSR view_change Jan 9, 2026
@krishvishal krishvishal marked this pull request as ready for review January 9, 2026 11:19
pub checksum_padding: u128,
pub checksum_body: u128,
pub checksum_body_padding: u128,
pub nonce_reserved: u128,
Copy link
Contributor

Choose a reason for hiding this comment

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

We are not going to be using thatr nonce, get rid of it from all of the view change headers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

/// The view number when this replica's status was last normal.
/// This is the key field for log selection: the replica with the
/// highest log_view has the most authoritative log.
pub log_view: u32,
Copy link
Contributor

Choose a reason for hiding this comment

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

We won't need this field for now, get rid of it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From my understanding of VSR-revisited paper, log_view is essential for correctness of consensus. Its called v' in the paper. Its used for correct log selection during view changes. The paper states: "selects as the new log the one contained in the message with the largest v'". Without it, we cannot correctly determine which replica's log is authoritative, which can lead to loss of committed operations.

self.replica_count
}

pub fn log_view(&self) -> u32 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Lets remove log_view from the VsrConsensus struct

@numinnex
Copy link
Contributor

I've left a few comments for now, will have probably some more, but we have to start thinking how will the VsrConsensus will be used, e.g whether we will share it between shards or will each shard have an unique instance of it, in the case of metadata, if we'd go with design that metadata lives only on shard0, we have to think about concurrent access across .await points.

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.

2 participants