* Small code cleanup and typo fixes
* Clean up calculate_points_and_credits
(cherry picked from commit 0e4509c497)
Co-authored-by: Ryo Onodera <ryoqun@gmail.com>
* implements ping-pong packets between nodes (#12794)
https://hackerone.com/reports/991106
> It’s possible to use UDP gossip protocol to amplify DDoS attacks. An attacker
> can spoof IP address in UDP packet when sending PullRequest to the node.
> There's no any validation if provided source IP address is not spoofed and
> the node can send much larger PullResponse to victim's IP. As I checked,
> PullRequest is about 290 bytes, while PullResponse is about 10 kB. It means
> that amplification is about 34x. This way an attacker can easily perform DDoS
> attack both on Solana node and third-party server.
>
> To prevent it, need for example to implement ping-pong mechanism similar as
> in Ethereum: Before accepting requests from remote client needs to validate
> his IP. Local node sends Ping packet to the remote node and it needs to reply
> with Pong packet that contains hash of matching Ping packet. Content of Ping
> packet is unpredictable. If hash from Pong packet matches, local node can
> remember IP where Ping packet was sent as correct and allow further
> communication.
>
> More info:
> https://github.com/ethereum/devp2p/blob/master/discv4.md#endpoint-proof
> https://github.com/ethereum/devp2p/blob/master/discv4.md#wire-protocol
The commit adds a PingCache, which maintains records of remote nodes
which have returned a valid response to a ping message, and on-the-fly
ping messages pending a pong response from the remote node.
When handling pull-requests, those from addresses which have not passed
the ping-pong check are filtered out, and additionally ping packets are
added for addresses which need to be (re)verified.
(cherry picked from commit ae91270961)
# Conflicts:
# Cargo.lock
# core/src/cluster_info.rs
* resolves mergify merge conflicts
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
ClusterInfo::process_packets handles incoming packets in a thread_pool:
https://github.com/solana-labs/solana/blob/87311cce7/core/src/cluster_info.rs#L2118-L2134
However, profiling runtime shows that threads are not well utilized and
a lot of the processing is done sequentially.
This commit redistributes the work done in parallel. Testing on a gce
cluster shows 20%+ improvement in processing gossip packets with much
smaller variations.
(cherry picked from commit 75d62ca095)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
* passes through feature-set to down to gossip requests handling
* takes the feature-set from root_bank instead of working_bank
(cherry picked from commit 48283161c3)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
* Clean up opt conf verifier and vote state tracker
* Update test to follow new message and some knob
* Rename
(cherry picked from commit 0264147d42)
Co-authored-by: Ryo Onodera <ryoqun@gmail.com>
* Deploy: send write transactions to leader tpu
* Less apparent stalling during confirmation
* Add EpochInfo mock
* Only get cluster nodes once
* Send deploy writes to next leader
(cherry picked from commit 16944e218f)
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
* Add deploy err if program-account balance is too high
* Review comments
* Add system-program check
* Rename and unhide flag
(cherry picked from commit 4669fa0f98)
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
* Allow nodes to advertise a different rpc address over gossip
* Feedback
(cherry picked from commit 8b0242a5d8)
Co-authored-by: Justin Starry <justin@solana.com>
