* 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>
* MockInvokeContext::get_programs() implementation
(cherry picked from commit 8acc47ee1b)
* start_local_server() now works with Banks > 0
(cherry picked from commit fa4bab4608)
* Add solana-program-test crate
(cherry picked from commit 52a292a75b)
* rebase
Co-authored-by: Michael Vines <mvines@gmail.com>
* Fix tower/blockstore unsync due to external causes
* Add and clean up long comments
* Clean up test
* Comment about warped_slot_history
* Run test_future_tower with master-only/master-slave
* Update comments about false leader condition
(cherry picked from commit 1df15d85c3)
Co-authored-by: Ryo Onodera <ryoqun@gmail.com>
* de-mut some InvokeContext methods
(cherry picked from commit da9548fd12)
* Simplify CPI interface into MessageProcessor
(cherry picked from commit 9263ae1c60)
Co-authored-by: Michael Vines <mvines@gmail.com>
* docs: Remove stale metrics steps
(cherry picked from commit 4dc4fefee2)
* docs: Reference metrics envvars for each cluster
(cherry picked from commit eb597cd60f)
Co-authored-by: Trent Nelson <trent@solana.com>
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)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
* Move KeyedAccount out of solana-program. Native programs are not supported by solana-program
(cherry picked from commit 1b343665a1)
# Conflicts:
# programs/bpf/benches/bpf_loader.rs
* rebase
Co-authored-by: Michael Vines <mvines@gmail.com>
Get the signature status in O(1) time, instead of O(n) where
n is the number of blockhashes in the StatusCache.
(cherry picked from commit f58bc8589d)
Co-authored-by: Greg Fitzgerald <greg@solana.com>
