…rigontech#15289)

…rigontech#15272)

Co-authored-by: JkLondon <[email protected]>

erigontech#15352)

polygon/sync: process partially connected header chains after
ccb.Connect error

(cherry picked from commit 5931fcf)

…to err (erigontech#15333) (erigontech#15356)

follow up fix after erigontech#15327
(forgot to update 1 place)

…erigontech#15357)

noticed some `response interrupted: context deadline exceeded` errs on
Amoy in a case where there were no milestones for over 4 hours and right
after initial sync-to-tip finished we had to backwards connect a new
block event with around 700 blocks gap

This is a cherry pick from main of the
erigontech#15261: Which implements the
Bhilai fork changes as specified in:


[PIP-63](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-63.md)

and also the feature to allow early block announcements specified in:


[PIP-66](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-66.md)

The individual changes included here are:

[PIP-60: Increase gas limit to
45M](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-60.md)
[PIP-58: Increase BaseFeeChangeDenominator to
64](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-58.md)
[EIP-2537: Precompile for BLS12-381 curve
operations](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2537.md)
[EIP-2935: Save historical block hashes in
state](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2935.md)
[EIP-7623: Increase calldata
cost](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7623.md)
[EIP-7702: Set EOA account
code](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md)
[(PIP-51)](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-51.md)
[PIP-66: Allow early block
announcements](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-66.md)

Added Bhilai fork number (22765056) to amoy config

…h#15360) (erigontech#15409)

Cherry-pick erigontech#15360

…rigontech#14968) (erigontech#15407)

Enable the following scenarios
- Replace setCode txn's like usual txns
- Send txn's and authorizations with higher nonces even if there are
existing authorizations with lower nonces
- Send AuthorityReserved only if an authority with the same nonce exists
already

Cherry-pick  (erigontech#14968)

…h#15312)

…en building block (erigontech#15305)

Block building is critical, 500ms is too little. I pick 12s because it
is the slot duration of ETH 2.0

) (erigontech#15404)

Basically, need to regen if the block was reorged.

…igontech#15451)

related to discussion from last week:

https://discord.com/channels/1133875232453693480/1133875633819242526/1377999996875571331

fixes 2 issues in "seg integrity":
- if first entity in snapshots (e.g. 10) is greater than first expected
entity (e.g. 1) and all are consecutive there will be no error - it
should err because there is a gap from e.g. 1 to 10
- fixes a bug in the integrity code which prevented us from catching a
gap in Spans snapshots `unexpected span gap: last=3454,new=3456` (e.g.
issue

[here](erigontech#15316 (comment)))

Co-authored-by: JkLondon <[email protected]>

Fixes erigontech#15349

…tech#15429) (erigontech#15473)

Michele reported that a minimal node for the Amoy validator encounters
an error after syncing from scratch:

```
[EROR] [05-28|13:04:52.818] [sync] waypoint execution err            lastCorrectTipNum=22134999 lastCorrectTipHash=0xc0ee90a99bc09918f402c5f2811f3d7fa8a64f859417163990ac4659228da34f execErr="updateForkChoice: [4/6 Execution] nil block 21638397"
```

Upon investigation, I found that the issue is related to inconsistent
snapshot folder contents. Specifically, for minimal nodes, we filter out
too many transaction snapshots.

The last commitment domain snapshot contained block number 21,638,396,
but the first transaction snapshot started from block number 22,000,000.
This discrepancy arises because minimal nodes retain snapshots only
within a ~100K block range.

As a result, there is a gap and inconsistency for blocks between
21,638,397 and 21,999,999.

A more correct algorithm would avoid relying solely on a fixed distance
to delete "unnecessary" snapshots. Instead, it should also consider what
is available in the domains folder. In fact, this logic already exists
in our code:

```
if stateTxNum <= baseTxNum { // only cosnider the block if it
    return nil
}
```

However, this condition was never triggered during the downloading stage
because we had alignMin == true in the snapshot block reader.

The PR addresses this issue.

It may also resolve the following issue:
https://github.com/erigontech/erigon-qa/issues/131. However, further
verification is needed. The gap was obvious in Amoy due to the low
transaction count per block (about 4), but on Bormainnet, each block
contains an average of 60+ transactions. This means that 100K blocks
always include more than the domain step of 1,562,500 transactions, so
the problem is less likely to occur there.

Co-authored-by: JkLondon <[email protected]>

)

…15507)

…5506)

for erigontech#15219

It seems some commits from main which fixed polygon mining related
problems were not cherry picked to release branch and that's why user
face these problem using v3.0.5 version of Erigon.

It should fix these issues:
1) erigontech#15481
2) one of the complaint about eth_estimateGas

All of it works fine in main branch.

ticket: erigontech#15209

- `ReadTxNumFunc` gets maxtxnum given a blockNumber...it was also used
to find blockNumber given maxTxNum..
- add `TxBlockIndex` in-place of `ReadTxNumFunc` -- difference is that
there's now a separate function to GetBlockNumber. Additionally:
- earlier, binary search was performed over a range of block numbers,
each search step queries MDBX and then fetches block from snapshot.
- now, binary search is separated into two stages: first stage will
binary_search in snapshots; second stage will do binary_search on MDBX.

# Conflicts:
#	cmd/integration/commands/stages.go
#	cmd/rpcdaemon/cli/config.go
#	eth/backend.go
#	eth/stagedsync/exec3.go
#	turbo/stages/mock/mock_sentry.go

…ch#13844) (erigontech#15548)

Another commit from main which needs to be cherry-picked. I forgot to
add it in this PR - erigontech#15540

connected to erigontech#15491

---------

Co-authored-by: JkLondon <[email protected]>

)

maybe helps with recent tests scheduling flakiness

---
when new commits are pushed into PR, the job runs of previous commits of
the PR (in particular, qa-rpc and integration tests) should be
cancelled.
This already happens with ci test. Just adding it for other two
workflows.

It's just something to save unnecessary job runs.
NOTE: this doesn't effect job runs on main branch or release branches
(these are the branches on which the requirement to know "which commit
broke a test" is needed)

Cherry-pick erigontech#15198

…5563)

Cherry-pick erigontech#15557

This adds missing cases to MakeSigner and LatestSigner to allow code
signing on Bhilai.

fixes: erigontech#15572

…ntech#15573)

Cherry pick of Heimdall v2 related commits from main.

---------

Co-authored-by: Mark Holt <[email protected]>

…igontech#15585)

Cherry-pick erigontech#15581

…igontech#15594) (erigontech#15602)

Backport of erigontech#15594. I guess just merge when/if people are happy with
behaviour of patch on main.

(cherry picked from commit 4122f83)