Release v1.5.0-alpha.9 #3982
Open
Release v1.5.0-alpha.9 #3982
+1,038
−510
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…tions As part of the discussions surrounding EIP-7594 (peerdas), it was highlighted that during sampling and/or data requests, the sampler does not have timing information for when a samplee will have data available. It is desireable to not introduce a deadline, since this artificially introduces latency for the typical scenario where data becomes available earlier than an agreed-upon deadline. Similarly, when a client issues a request for blocks, it does often not know what rate limiting policy of the serving end and must either pessimistically rate limit itself or run the risk of getting disconnected for spamming the server - outcomes which lead to unnecessarily slow syncing as well as testnet mess with peer scoring and disconnection issues. This PR solves both problems by: * removing the time-to-first-byte and response timeouts allowing requesters to optimistically queue requests - the timeouts have historically not been implemented fully in clients to this date * introducing a hard limit in the number of concurrent requests that a client may issue, per protocol * introducing a recommendation for rate limiting that allows optimal bandwidth usage without protocol changes or additional messaging roundtrips On the server side, an "open" request does not consume significant resources while it's resting, meaning that allowing the server to manage resource allocation by slowing down data serving is safe, as long as concurrency is adequately limited. On the client side, clients must be prepared to handle slow servers already and they can simply apply their existing strategy both to uncertainty and rate-limiting scenarios (how long before timeout, what to do in "slow peer" scenarios). Token / leaky buckets are a classic option for rate limiting with desireable properties both for the case when we're sending requests to many clients concurrently (getting good burst performance) and when the requestees are busy (by keeping long-term resource usage in check and fairly serving clients)
Co-authored-by: Pop Chunhapanya <[email protected]>
Transactions cannot be empty, they always have at least 1 byte. Random tests should produce valid CL data by default. There are still individual tests for invalid transactions.
As a complement to #3787, this PR introduces a `SingleAttestation` type used for network propagation only. In Electra, the on-chain attestation format introduced in [EIP-7549](#3559) presents several difficulties - not only are the new fields to be interpreted differently during network processing and onchain which adds complexity in clients, they also introduce inefficiency both in hash computation and bandwidth. The new type puts the validator and committee indices directly in the attestation type, this simplifying processing and increasing security. * placing the validator index directly in the attestation allows verifying the signature without computing a shuffling - this closes a loophole where clients either must drop attestations or risk being overwhelmed by shuffling computations during attestation verification * the simpler "structure" of the attestation saves several hash calls during processing (a single-item List has significant hashing overhead compared to a field) * we save a few bytes here and there - we can also put stricter bounds on message size on the attestation topic because `SingleAttestation` is now fixed-size * the ambiguity of interpreting the `attestation_bits` list indices which became contextual under EIP-7549 is removed Because this change only affects the network encoding (and not block contents), the implementation impact on clients should be minimal.
EIP-4844 uses RLP not SSZ for blob transactions.
Fix all pytest warnings
Rebase eip7594 onto Electra
Bump version to 1.5.0-alpha.9
Upgrade pylint & split config files
Avoid generating empty transactions in tests
Encode zero-length hex-strings with quotes
Add `test_fork_pending_deposits_are_sorted` test
Add `gen-modcheck` CI check
P2P clarifications when introducing `engine_getBlobsV1`
eip7251: Bugfix and more withdrawal tests
Separate type for unaggregated network attestations
p2p: Deprecate TTFB, RESP_TIMEOUT, introduce rate limiting recommenda…
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
get_attesting_indices()#3996work-in-progress release notes
v1.5.0-alpha.9-- Ampharos -- is the alpha release for the coming Electra upgrade.PR showing full diff can be found here:
#3982Electra
#3800#3900#3976get_validator_from_deposit#3978#3979get_attesting_indices#3996#3998#4000EIP-7594 (PeerDAS)
#3893#3963Networking
TTFB,RESP_TIMEOUT, introduce rate limiting recommendations#3767Testing, repo, etc
#3754#3884#3904Makefile#3940check_modsfunction for generators#3970README, move outdated specs to new section#3973#3975#3986pytestwarnings#3989pylint& split config files#3991#3995