-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
David you had other ways to handle this right? just not forwarding validations you don't care about if you are loaded or something? |
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? |
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. |
superpeers are out, squelching is in as are narrow networks with high outdegree. This is obsolete. |
Validation networks are needed to protect the network from validation spam.
The text was updated successfully, but these errors were encountered: