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

feat(code/consensus): Add support for full nodes #750

Merged
merged 7 commits into from
Jan 15, 2025

Conversation

hoank101
Copy link
Contributor

@hoank101 hoank101 commented Jan 11, 2025

Closes: #742


PR author checklist

For all contributors

For external contributors

Copy link

codecov bot commented Jan 11, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.54%. Comparing base (3e977d1) to head (a6c29b2).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #750      +/-   ##
==========================================
+ Coverage   75.51%   75.54%   +0.03%     
==========================================
  Files         165      165              
  Lines       14301    14329      +28     
==========================================
+ Hits        10799    10824      +25     
- Misses       3502     3505       +3     
Flag Coverage Δ
integration 75.54% <ø> (+0.03%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@hoank101 hoank101 marked this pull request as ready for review January 11, 2025 04:26
code/crates/core-consensus/src/state.rs Outdated Show resolved Hide resolved
code/crates/starknet/test/src/lib.rs Show resolved Hide resolved
@hoank101 hoank101 requested a review from romac January 13, 2025 13:41
@hoank101 hoank101 requested a review from romac January 15, 2025 06:08
Copy link
Member

@romac romac left a comment

Choose a reason for hiding this comment

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

Great work! 🚀

@romac romac added this pull request to the merge queue Jan 15, 2025
Merged via the queue into informalsystems:main with commit 190f4a0 Jan 15, 2025
18 checks passed
)
);
// Only sign and publish if we're in the validator set
if state.is_validator() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Not sure about the proposal filtering, seems we are trying to defend against a bug where get_proposer() returns a non-validator/ full node address...but in this case the is_validator() should also fail.

Copy link
Member

Choose a reason for hiding this comment

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

Yes it's just defensive coding. Maybe we can change the check to do a debug_assert or even an assert in order to ensure this code path is never hit.

@ancazamfir
Copy link
Collaborator

Can we start a full node from command line?

@ancazamfir
Copy link
Collaborator

Wondering if we should send VoteSetRequest to a non-validator, or accept VoteSetResponse from a non-validator.

@ancazamfir
Copy link
Collaborator

So for the receive side, verify_signed_vote() and verify_signed_proposal() handle the case where a full node sends messages and we will see warning messages of the form: Received vote/proposal from unknown validator. Maybe non-validator would be better but really minor.

@romac
Copy link
Member

romac commented Jan 15, 2025

Wondering if we should send VoteSetRequest to a non-validator, or accept VoteSetResponse from a non-validator.

Good question, perhaps there is a higher chance that non-validators might be byzantine and in that case we should restrict those queries to validators only?

@romac
Copy link
Member

romac commented Jan 15, 2025

Can we start a full node from command line?

Not at the moment, you have to remove the full node address from the validator set in the genesis of all validator nodes.

@ancazamfir
Copy link
Collaborator

ancazamfir commented Jan 15, 2025

Wondering if we should send VoteSetRequest to a non-validator, or accept VoteSetResponse from a non-validator.

Good question, perhaps there is a higher chance that non-validators might be byzantine and in that case we should restrict those queries to validators only?

Not sure myself, let's discuss next time we meet. On a side note, we should allow vote sync when blocksync is disabled (iirc this is not the case today)

cason pushed a commit that referenced this pull request Jan 15, 2025
* feat(code/consensus): Add support for full nodes

* fix lint

* Update code/crates/core-consensus/src/state.rs

Co-authored-by: Romain Ruetschi <[email protected]>
Signed-off-by: DevOrbitlabs <[email protected]>

* update

* update

---------

Signed-off-by: DevOrbitlabs <[email protected]>
Co-authored-by: Romain Ruetschi <[email protected]>
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.

feat(code/consensus): Add support for full nodes
3 participants