Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Collator node workflow #280

Merged
merged 11 commits into from
Jul 6, 2018
Merged

Collator node workflow #280

merged 11 commits into from
Jul 6, 2018

Conversation

rphmeier
Copy link
Contributor

@rphmeier rphmeier commented Jul 4, 2018

A collator is a special polkadot full node which is attached to a particular parachain and "collates" proposals for blocks on that parachain to give to validators to consider as part of the consensus. This PR creates a futures-based workflow for a collator node, with actual collation logic encapsulated by a trait.

  1. Allows passing of a "Worker" object into the CLI library, which can produce two futures: one for early exit and one for work to be driven
  2. Implements "Worker" for a collator library that gathers and signs collations for a parachain.

After #173, will pass collations to validators for agreement

@rphmeier rphmeier added A0-please_review Pull request needs code review. M4-core labels Jul 4, 2018
@@ -117,6 +120,26 @@ fn base_path(matches: &clap::ArgMatches) -> PathBuf {
.unwrap_or_else(default_base_path)
}

/// Additional application logic making use of the ndoe, to run asynchronously before shutdown.
Copy link
Contributor

Choose a reason for hiding this comment

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

making use of the node (typo)


/// Parachain context needed for collation.
///
/// This can be implemented through an externally attached service or a stub.
pub trait ParachainContext {
pub trait ParachainContext: Clone {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we add something like this to the comment?

This is expected to be a lightweight, shared type like an Arc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, I will add it

/// Produce a candidate, given the latest ingress queue information.
fn produce_candidate<I: IntoIterator<Item=(ParaId, Message)>>(
&self,
last_head: HeadData,
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this deserves a doc update?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, probably

quick_main!(run);

fn run() -> cli::error::Result<()> {
cli::run(::std::env::args())
cli::run(::std::env::args(), Application)
Copy link
Contributor

@pepyakin pepyakin Jul 5, 2018

Choose a reason for hiding this comment

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

I think cli::Application is a little confusing name... Here is my experience

When I checked this file for the first time I had an impression that Application provides a main logic of, well, the application. Only when I've found that work returns future::empty() for the Application I realized that my hypothesis was wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think of it as "application on top of the node". Since the normal operation mode is to do no additional work with the node then the work future is empty. But with the collator node the implementation of Work will be to listen to import notifications from the node and to push collated blocks to validators on the network.

I can't really think of a better name for it though.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, figured it out pretty quick after that, so maybe not a big deal

I honestly was hoping that you will be able to come up with a better name : )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(renaming to Worker on suggestion of @gnunicorn )

@0xthreebody
Copy link

HatApplication.

Copy link
Contributor

@gnunicorn gnunicorn left a comment

Choose a reason for hiding this comment

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

Just a minor change-request and one aspect I am not sure I understand entirely, but aside from that, solid.

fn exit(&mut self) -> Self::Exit {
match self.exit.take() {
Some(exit) => future::Either::A(exit),
None => future::Either::B(future::empty()),
Copy link
Contributor

Choose a reason for hiding this comment

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

isn't this the return value that is then passed into the separate thread, which then performs an exit.wait() before exiting? With using future::empty() this would prevent the process from exiting ever, right? Is that intentional? If so, why do we want to prevent an exit? Or did you mean to use future::ok() to have it resolve immediately, which would make more sense to me...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

in practice exit will only get called once, and I wasn't quite sure what to do if exit is called a second time. I favored returning a future that never resolves over returning one that resolves immediately, but the other options I considered were to panic or alter Worker to return an error. No strong preference.

future::Either::B(future::ok(None))
}
Err(e) => {
info!("Could not collate for parachain {:?}: {:?}", id, e);
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't that be at least of level warn!? I feel consuming an error without actually recovering and not being verbose about it, could easily cover up important issues to be addressed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it might get rather spammy, but yes

@gnunicorn gnunicorn added A6-mustntgrumble and removed A0-please_review Pull request needs code review. labels Jul 6, 2018
@rphmeier rphmeier added A0-please_review Pull request needs code review. and removed A6-mustntgrumble labels Jul 6, 2018
@rphmeier rphmeier added A8-looksgood and removed A0-please_review Pull request needs code review. labels Jul 6, 2018
@pepyakin pepyakin merged commit ddc8d70 into master Jul 6, 2018
@pepyakin pepyakin deleted the rh-collator-node branch July 6, 2018 14:13
lamafab pushed a commit to lamafab/substrate that referenced this pull request Jun 16, 2020
JoshOrndorff pushed a commit to moonbeam-foundation/substrate that referenced this pull request Apr 21, 2021
* update polkadot/types

* update test dependencies as well
liuchengxu added a commit to chainx-org/substrate that referenced this pull request Aug 23, 2021
liuchengxu added a commit to chainx-org/substrate that referenced this pull request Aug 23, 2021
* Rename ValidatorLedger.total to total_nomination

* Move DECIMALS to xpallet-protocol

* .

* .

* Remove duplicate consts in runtime

* .
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants