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/async block proposal #4228

Merged
merged 23 commits into from
Jan 9, 2024
Merged

Feat/async block proposal #4228

merged 23 commits into from
Jan 9, 2024

Conversation

kantai
Copy link
Member

@kantai kantai commented Jan 4, 2024

Description

Adds the /v2/block_proposal endpoint with async processing and callback over the event observer interface.

It does this by spawning a thread (if no such thread is currently running) and passing it a handle to an event dispatcher.

Applicable issues

Todo

  • Update the API/RPC docs with the synchronous -> asynchronous changes.

Copy link

codecov bot commented Jan 4, 2024

Codecov Report

Attention: 109 lines in your changes are missing coverage. Please review.

Comparison is base (92180f0) 82.78% compared to head (dc82c12) 82.94%.

Files Patch % Lines
stackslib/src/net/api/postblock_proposal.rs 80.14% 56 Missing ⚠️
...net/stacks-node/src/tests/nakamoto_integrations.rs 92.38% 24 Missing ⚠️
stackslib/src/chainstate/stacks/mod.rs 9.09% 10 Missing ⚠️
testnet/stacks-node/src/event_dispatcher.rs 73.68% 10 Missing ⚠️
testnet/stacks-node/src/config.rs 0.00% 4 Missing ⚠️
testnet/stacks-node/src/tests/neon_integrations.rs 92.85% 2 Missing ⚠️
stackslib/src/chainstate/burn/db/sortdb.rs 85.71% 1 Missing ⚠️
stackslib/src/net/api/mod.rs 50.00% 1 Missing ⚠️
stackslib/src/net/api/posttransaction.rs 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             next    #4228      +/-   ##
==========================================
+ Coverage   82.78%   82.94%   +0.16%     
==========================================
  Files         429      430       +1     
  Lines      302897   303578     +681     
==========================================
+ Hits       250756   251809    +1053     
+ Misses      52141    51769     -372     

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

docs/rpc/openapi.yaml Outdated Show resolved Hide resolved
/// - Miner signature is valid
/// - Validate threshold signature of stackers
/// - Validation of transactions by executing them agains current chainstate.
/// This is resource intensive, and therefore done only if previous checks pass
Copy link
Member

Choose a reason for hiding this comment

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

It's really a shame that we can't easily overlap this with the similar code in NakamotoChainState without substantial refactoring. Perhaps this is just going to have to be a back-burner issue.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I agree. The code overlap isn't so excessive, though, because most of the work here is already taking place through invocations of begin_tenure, etc. There's also a repeated code block here that needs to be removed: the stacker signature check. That cannot be part of the proposal validation (because the proposal validation is occurring to decide whether or not to sign in the first place).

Copy link
Member

@jcnelson jcnelson left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks!

@jcnelson
Copy link
Member

jcnelson commented Jan 5, 2024

Seems your OpenAPI validation is failing

p
};

let block = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I wonder if I should use something like this rather than the test observer to validate the block written to stacker db in my .miners PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think the approach you use in your PR is better for the .miners check: you want to confirm that the miner thread's actual block matches the data read out of the stackerdb, not that an independently assembled block matches either of those.

Copy link
Contributor

@jbencin jbencin left a comment

Choose a reason for hiding this comment

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

Looks good, I think there's a couple issues in the docs that need attention before merging

Used by stackers to validate a proposed Stacks block from a miner.

**This endpoint will only accept requests over the local loopback network interface.**
responses:
Copy link
Contributor

Choose a reason for hiding this comment

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

Where is the 4xx error response for an invalid block?

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay I see that on a 202 results are returned via event observer. There are still situations where you can get a 400 response, like a NetError

Copy link
Member Author

Choose a reason for hiding this comment

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

Right, those 400 responses are common to all API endpoints though.

@@ -693,6 +693,22 @@ impl ToSql for ThresholdSignature {
}
}

impl serde::Serialize for ThresholdSignature {
Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like you are replacing the wsts::common::Signature Serde format, which is kinda complex, with a simple hex string. Good call

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, and this is already done for the SQL implementations, so it seemed like a straightforward improvement.

stackslib/src/net/api/postblock_proposal.rs Outdated Show resolved Hide resolved
stackslib/src/net/api/posttransaction.rs Show resolved Hide resolved
docs/rpc/openapi.yaml Outdated Show resolved Hide resolved
@@ -500,6 +506,23 @@ impl PeerNetwork {
network
}

pub fn set_proposal_thread(&mut self, thread: JoinHandle<()>) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this check if self.block_proposal_thread is None first?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think so -- the caller needs to have already checked this, because it shouldn't even get a JoinHandle if the block_proposal_thread is still running.

@kantai kantai merged commit 2285877 into next Jan 9, 2024
2 checks passed
@kantai kantai deleted the feat/async-block-proposal branch January 9, 2024 15:00
@blockstack-devops
Copy link
Contributor

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@stacks-network stacks-network locked as resolved and limited conversation to collaborators Nov 7, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants