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

Validation network #38

Closed
ahbritto opened this issue Apr 28, 2013 · 4 comments
Closed

Validation network #38

ahbritto opened this issue Apr 28, 2013 · 4 comments

Comments

@ahbritto
Copy link
Contributor

Validation networks are needed to protect the network from validation spam.

@jedmccaleb
Copy link
Contributor

David you had other ways to handle this right? just not forwarding validations you don't care about if you are loaded or something?

@JoelKatz
Copy link
Collaborator

I think not forwarding validations from nodes you don't trust when you are under any significant load is a plausible solution for awhile. I believe the code actually currently almost never forwards validations from validators it doesn't trust due to a logic error -- see ValidationCollection.cpp line 90.

But the same logic applies to proposals too. We should gate propagating untrusted validations and proposals (and perhaps, for proposals at least, whether we signature check them too), to some measure of server load. This shouldn't be hard to do. Actually, there's no point in checking the signature of an untrusted validation if we're not going to propagate it. Why would we care?

@vinniefalco
Copy link
Contributor

The newest thinking is to first create a two-tiered network. "superpeers" will participate in relaying and take incoming connections, while "leaves" will connect to multiple superpeers and not perform message routing. Validators will connect as leaves to multiple superpeers. The superpeer will forward validations from the validator to the other leaves that care. Validations will no longer be broadcast. Certification entities will publish list of approved validators. New business logic will replace the concept of UNL. Rather than building a preconceived list of desired validators, a node will acquire superpeers sequentially, and building its validator list as the union of what validators each superpeer offers. The node ranks the quality of the resulting list based on the subset of the list which appears in the node's list of approved certification entities. The node stops acquiring superpeers when it is assured that the quality of the validators it is receiving meets a certain criteria.

@vinniefalco
Copy link
Contributor

vinniefalco commented Feb 3, 2017

superpeers are out, squelching is in as are narrow networks with high outdegree. This is obsolete.

tequdev pushed a commit to tequdev/rippled that referenced this issue Nov 17, 2023
ximinez pushed a commit to ximinez/rippled that referenced this issue Oct 10, 2024
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

No branches or pull requests

4 participants