-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Set reserved nodes with offchain worker. #6996
Changes from 13 commits
57febc4
3dc7a45
3664999
6b43f9e
4d17e4c
46b4078
70e616e
613a84d
27152b9
acbc8d6
d4e5ae8
b62beea
7e2a026
03ab075
6d659f5
0c325fe
5cc6ae1
4c269a5
4907592
f112fa7
420072f
e0dce84
65cd8ed
d429363
12f0386
82359b8
a18b248
76c7535
2430b16
a6929c1
36f3829
889dfe6
982bcaf
2c893ac
e3882be
517f97a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -270,6 +270,8 @@ pub use protocol::{event::{DhtEvent, Event, ObservedRole}, sync::SyncState, Peer | |
| pub use service::{NetworkService, NetworkWorker, RequestFailure, OutboundFailure}; | ||
|
|
||
| pub use sc_peerset::ReputationChange; | ||
| use config::identity::PublicKey; | ||
| use sc_peerset::PeersetHandle; | ||
| use sp_runtime::traits::{Block as BlockT, NumberFor}; | ||
|
|
||
| /// The maximum allowed number of established connections per peer. | ||
|
|
@@ -294,6 +296,12 @@ pub trait NetworkStateInfo { | |
|
|
||
| /// Returns the local Peer ID. | ||
| fn local_peer_id(&self) -> PeerId; | ||
|
|
||
| /// Returns the local Peer PublicKey. | ||
| fn local_public_key(&self) -> PublicKey; | ||
|
|
||
| /// Returns the peerset | ||
| fn peerset(&self) -> PeersetHandle; | ||
|
||
| } | ||
|
|
||
| /// Overview status of the network. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| [package] | ||
| name = "pallet-node-authorization" | ||
| version = "2.0.0-rc6" | ||
| authors = ["Parity Technologies <[email protected]>"] | ||
| edition = "2018" | ||
| license = "Apache-2.0" | ||
| homepage = "https://substrate.dev" | ||
| repository = "https://github.com/paritytech/substrate/" | ||
| description = "FRAME pallet for node authorization" | ||
|
|
||
| [package.metadata.docs.rs] | ||
| targets = ["x86_64-unknown-linux-gnu"] | ||
|
|
||
| [dependencies] | ||
| serde = { version = "1.0.101", optional = true } | ||
| codec = { package = "parity-scale-codec", version = "1.3.4", default-features = false, features = ["derive"] } | ||
| frame-support = { version = "2.0.0-rc6", default-features = false, path = "../support" } | ||
| frame-system = { version = "2.0.0-rc6", default-features = false, path = "../system" } | ||
| sp-core = { version = "2.0.0-rc6", default-features = false, path = "../../primitives/core" } | ||
| sp-io = { version = "2.0.0-rc6", default-features = false, path = "../../primitives/io" } | ||
| sp-std = { version = "2.0.0-rc6", default-features = false, path = "../../primitives/std" } | ||
|
|
||
| [dev-dependencies] | ||
| sp-runtime = { version = "2.0.0-rc6", default-features = false, path = "../../primitives/runtime" } | ||
|
|
||
| [features] | ||
| default = ["std"] | ||
| std = [ | ||
| "serde", | ||
| "codec/std", | ||
| "frame-support/std", | ||
| "frame-system/std", | ||
| "sp-core/std", | ||
| "sp-io/std", | ||
| "sp-std/std", | ||
| ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do I understand correctly that this pull request treats a
PublicKeyas an opaque data set? In other words, does this pull request make sure ofPublicKeyverification? If not, why not use thePeerIdabstraction as the base network identity?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no extra verification (except the length of the bytes) for
PublicKeyin this PR, the reasons I didn't usePeerIdare,PeerIdis from libp2p, the encode/decode for it is pretty a challenge to me. I guess you mean using an opaque data likeVec<u8>to represent the PeerId when storing and convert it back when using it, that's probably also work in my scenario, but sounds a bit wild.PeerIdis something fall in this.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's actually the preferred approach IMO.
The conversion from
PeerIdtoVec<u8>and vice versa is precisely spec'ced by libp2p and not something we have invented.In terms of difficulty don't really see the difference between letting users manipulate a
PublicKeyand letting users manipulate aPeerId.It is true that if you actually want to analyse the content of the
PublicKeyorPeerId, then it's more complicated if you have aPeerId. However, I don't think users actually want to do that.Furthermore, libp2p public keys are never exposed anywhere in the node. Users can easily see which
PeerIdthey have, but not which public key they have.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was imagining a scenario that user generate node key so that it can be passed to the CLI when starting the node, at this time the public key is available and recorded by the user. Then be used in this node-authorization pallet.
I'm not in favor of putting PeerId to the user side. Even it's a mandatory concept in libp2p, but not so in Substrate runtime development AFAIK. Most of the time we are assuming the user don't need much knowledge such as PeerId about libp2p, isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just find this P2P Networking in polkadot wiki, which eliminate a few concerns from me to use
PeerIdin runtime.Still interested in others preference between PublicKey and PeerId.