* account-decoder: don't use strings to convert between Pubkey types
* transaction-status: don't use strings to convert between Pubkey types
(cherry picked from commit 51178ccb33)
Co-authored-by: Alexander Polakov <polachok@users.noreply.github.com>
* adds metric for turbine retransmit tree mismatch
In order to remove port-based forwarding logic in turbine, we need to
first track how often the turbine retransmit/broadcast trees mismatch
across nodes.
One consistency condition is that if the node is on the critical path
(i.e. the first node in each neighborhood), then we expect that the
packet arrives at tvu socket as opposed to tvu-forwards.
This commit adds a metric to track how often above condition is not met.
(cherry picked from commit 71de021177)
* removes the nested for loop from retransmit-stage
The code can be simplified by just flattening the vector of packets.
(cherry picked from commit ff0e623d30)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
* stake: plumb `can_merge_expired_lockups` feature flag
(cherry picked from commit 74ac6ab80f)
* stake: merge accounts with mismatched, but expired lockups
(cherry picked from commit 019bccab51)
Co-authored-by: Trent Nelson <trent@solana.com>
If stakes are unknown, then timeouts will be short, resulting in values
being purged from the crds table, and consequently higher pull-response
load when they are obtained again from gossip. In particular, this slows
down validator start where almost all values obtained from entrypoint
are immediately discarded.
(cherry picked from commit 2adce67260)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
crds table retains up to 32 node-instance values per each pubkey. This
is so because if there are multiple running instances of the same node,
then we want gossip to propagate node-instance values associated with
both instances, therefore the corresponding label/key includes the
randomly generated token in addition to the pubkey:
https://github.com/solana-labs/solana/blob/9c42a89a4/core/src/crds_value.rs#L448https://github.com/solana-labs/solana/pull/14037
As a result, the number of such values per pubkey are effectively
unbounded, requiring custom mitigations implemented in:
https://github.com/solana-labs/solana/pull/14467
but still taking redundant extra memory and bandwidth.
This commit instead retains only one node-instance per pubkey by
extending crds values override logic. If a crds value is of type
node-instance, it will always override an existing one with the same key
if it has more recent starting timestamp (not wallclock). As a result,
gossip will always propagate the node-instance with more recent
timestamp. Since the check_duplicate logic will stop the node with older
timestamp, this change should preserve existing functionality.
(cherry picked from commit 0aa7824884)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
On the receiving end, the outdated values are discarded, and they will
only waste bandwidth:
https://github.com/solana-labs/solana/blob/3f0480d06/core/src/crds_gossip_pull.rs#L385-L400
This is also exacerbating validator start, since the entrypoint is
returning old values in pull responses, and the validator immediately
discards those; resulting in huge delay until the validator obtains
contact-info of the entrypoint and is able to adopt shred-version and
fully start.
(cherry picked from commit 5e6b00fe98)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
When a validator starts, it has an (almost) empty crds table and it only
sends one pull-request to the entrypoint. The bloom filter in the
pull-request targets 10% false rate given the number of items. So, if
the `num_items` is very wrong, it makes a very small bloom filter with a
very high false rate:
https://github.com/solana-labs/solana/blob/2ae57c172/runtime/src/bloom.rs#L70-L80https://github.com/solana-labs/solana/blob/2ae57c172/core/src/crds_gossip_pull.rs#L48
As a result, it is very unlikely that the validator obtains entrypoint's
contact-info in response. This exacerbates how long the validator will
loop on:
> Waiting to adopt entrypoint shred version
https://github.com/solana-labs/solana/blob/ed51cde37/validator/src/main.rs#L390-L412
This commit increases the min number of bloom items when making gossip
pull requests. Effectively this will break the entrypoint crds table
into 64 shards, one pull-request for each, a larger bloom filter for
each shard, and increases the chances that the response will include
entrypoint's contact-info, which is needed for adopting shred version
and validator start.
(cherry picked from commit e8b35a4f7b)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
* programs/stake: cancel deactivate (#17344)
fix: remove stray println
add error for inconsistent input.
fix: lamports don't need to match when redelegating to same vote account
Improve comments
bump
Apply suggestions from code review
Add assert in test
Use stake_program_v4
Co-Authored-By: Trent Nelson <trent.a.b.nelson@gmail.com>
Co-authored-by: Trent Nelson <trent.a.b.nelson@gmail.com>
(cherry picked from commit 662c2aaeec)
# Conflicts:
# programs/stake/src/stake_instruction.rs
# programs/stake/src/stake_state.rs
* Fix conflicts
Co-authored-by: jon-chuang <9093549+jon-chuang@users.noreply.github.com>
Co-authored-by: Tyera Eulberg <tyera@solana.com>
The current implementations use only the id and disregard other fields,
in particular wallclock. This can lead to bugs where an outdated
contact-info shadows or overrides a current one because they compare
equal.
(cherry picked from commit 13b032b2d4)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
* Update keypair configuration output
While going through the tutorial to start a validator I noticed that the output I received from running...
```
solana config set --keypair ~/validator-keypair.json
```
...different from the output I was seeing. Wondering whether the docs are out of date I thought I'd propose an update to the docs just in case.
(cherry picked from commit 02157f4753)
* Update docs/src/running-validator/validator-start.md
(cherry picked from commit de76adbdf3)
Co-authored-by: Chris Bellew <cjbellew@gmail.com>
Co-authored-by: Trent Nelson <trent.a.b.nelson@gmail.com>
When the input contains more accounts than the user has requested to be deserialized, and one of the excess ones is a dup, the input pointer is not adjusted correctly.
Compare the lines added by this commit to line 401: "input += 7; // padding". Since the input data layout does not depend on the number of accounts the user wants to deserialize, this adjustment by 7 bytes must happen in both branches.
(cherry picked from commit e02b4e1192)
Co-authored-by: Christian Machacek <39452430+machacekch@users.noreply.github.com>
* Zero pad data shreds on fetch from blockstore
This is a partial backport of #16602 to allow compatibility with that change.
* Remove size check and resize shreds to consistent length
* rpc: plumb shred_version through RpcContactInfo
(cherry picked from commit 67e6a3106f)
* test-validator: Display more cluster info in dash
(cherry picked from commit 754c708473)
Co-authored-by: Trent Nelson <trent@solana.com>
