forked from protolambda/erigon
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upstream sync - v2.46.0 #84
Merged
Merged
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
This change adds 'any' as an alternate wildcard to '*'. I have updated all doc references in the main erigon repo - let me know if there is anywhere else that needs changing.
I realised that the term `checkpoint` is used in 2 different meanings in the code, which are distinct. Renaming one of the to persistentSnapshots to reduce confusion
This is another update to logging to replace the root logger with a contextual logger
- do it only once in HistoryStateReader
…ce.senders` which enabling more verbose logging for given senders list (erigontech#7686) When testing with `Bor` consensus turned on I discovered that `SendRawTransaction` returns a 0x000... hash when transactions are submitted during block transitions. This turns out to be spurious in the sense that the transaction insertion is successful. The cause is that `ReadCurrentBlockNumber` returns a nil block number. This in turn is caused by the following: In `accessors_chain.go` there are two methods: `WriteHeader` and `WriteHeadHeaderHash` when the first is called the block number is written for the header. The second writes the header has, but there is no guarantee when it does that the head header will have been written yet. In fact it seems to happen sometime later. The problem for `SendRawTransation` is that it begins a transaction after inserting into the txpool. And depending on timing this transaction may see only the `WriteHeadHeaderHash` insertion, and hence can't read the block number. I have mitigated this by opening the db transaction before calling the tx pool insertion, meaning that it is more likely to have a clean view of the DB. I have also moved the chain id check earlier in the code - as I think that if this is invalid the method should not try to insert transactions in the first place. The `ReadCurrentBlockNumber` is only used to produce a log message - so I've changed this to not fail the whole function but to just log an unknown sender. Which means that the hash is still returned to the sender after a successful txpool insertion
Added so now we can have version 3 payloads preparing for Deneb
Now you can configure: Read timeout (default: 5s) Write timeout (default: 5s) On/off (default: ON) Port (default:5555) Address (default:localhost) Protocol (default: tcp) erigontech#7684
start of abstracting the transition layer. incremental movements.
Fix: typos
…ech#7689) This PR does the following things. - Optimises the get span for bor function. The function was responsible to fetch span from heimdall and store in cache. If not found, it would iterate back (or front) depending on the last found span in cache. In this iteration it would also fetch the span every time it moves front / back which is not necessary at all. As we know the `spanLength` we can leverage it to directly jump to the required span ID without fetching all the intermediate ones. - Adds a check for `number > 255` in validating producers from headers' extra data with ones in span. As bor fetches this data from contract, it used to give correct results for 0th span (i.e. 0-255 blocks) and hence no error occurs. Erigon on the other hand directly uses span to get producers for all blocks. Hence, the data in 0th span turns out to be wrong (as it's hardcoded in contract). We can skip validation for 0th span blocks until we start fetching data from contract. - As we're planning to use erigon as a validator, it will also be responsible for preparing headers. It used to write all the validators in the `header.Extra` field instead of just the selected producers. As we have `GetCurrentProducers` function available now, we can use it instead of `GetCurrentValidators`.
This request adds an additional logging flag to change the name of the logfiles produced by erigon to be prefixed by a name other than 'erigon'. This allows multiple nodes to log to the same directory without overwriting each others files. It is requires so that the devnet when running can maintain all of its log files in a single consolidated directory which survives devnet restarts. --------- Co-authored-by: Mark Holt <mark@distributed.vision>
…checking invalid err variable (erigontech#7719)
attempt to address next issue: > when I'm having a lot of websocket connections the node is freezing and then it needs like 10 mins to sync. Then if I keep pushing requests it falls out of sync all the time
For legacy transactions ChainID is optional (missing in pre-[EIP155](https://eips.ethereum.org/EIPS/eip-155) transactions) and is derived from `V` anyway. Also, cherry pick ethereum/go-ethereum#27452.
Fix some issues introduced in PR erigontech#7715
Post-fix after PR erigontech#7732
Co-authored-by: Alex Sharov <AskAlexSharov@gmail.com>
This is an update to the devnet code which introduces the concept of configurable scenarios. This replaces the previous hard coded execution function. The intention is that now both the network and the operations to run on the network can be described in a data structure which is configurable and composable. The operating model is to create a network and then ask it to run scenarios: ```go network.Run( runCtx, scenarios.Scenario{ Name: "all", Steps: []*scenarios.Step{ &scenarios.Step{Text: "InitSubscriptions", Args: []any{[]requests.SubMethod{requests.Methods.ETHNewHeads}}}, &scenarios.Step{Text: "PingErigonRpc"}, &scenarios.Step{Text: "CheckTxPoolContent", Args: []any{0, 0, 0}}, &scenarios.Step{Text: "SendTxWithDynamicFee", Args: []any{recipientAddress, services.DevAddress, sendValue}}, &scenarios.Step{Text: "AwaitBlocks", Args: []any{2 * time.Second}}, }, }) ``` The steps here refer to step handlers which can be defined as follows: ```go func init() { scenarios.MustRegisterStepHandlers( scenarios.StepHandler(GetBalance), ) } func GetBalance(ctx context.Context, addr string, blockNum requests.BlockNumber, checkBal uint64) { ... ``` This commit is an initial implementation of the scenario running - which is working, but will need to be enhanced to make it more usable & developable. The current version of the code is working and has been tested with the dev network, and bor withoutheimdall. There is a multi miner bor heimdall configuration but this is yet to be tested. Note that by default the scenario runner picks nodes at random on the network to send transactions to. this causes the dev network to run very slowly as it seems to take a long time to include transactions where the nonce is incremented across nodes. It seems to take a long time for the nonce to catch up in the transaction pool processing. This is yet to be investigated.
- breaks dependency from staged_sync to package with block_reader implementation - breaks dependency from snap_sync to package with block_reader implementation - breaks dependency from mining to txpool implementation
Continuation of PR erigontech#7715
pcw109550
requested changes
Jul 20, 2023
@@ -318,11 +318,10 @@ func TestCanEncodeAndDecodeBodyTransactions(t *testing.T) { | |||
feeCap, _ := uint256.FromBig(big.NewInt(2)) | |||
var tx3 Transaction = &DynamicFeeTransaction{ | |||
CommonTx: CommonTx{ | |||
ChainID: u256.Num1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ChainID field is removed in CommonTx
. ChainID init logic must be moved when initializing DynamicFeeTransaction
.
pcw109550
approved these changes
Jul 20, 2023
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.
Upstream sync PR
erigon
ledgerwatch/erigon
v2.46.0 ->testinprod-io/op-erigon
077a3d5erigon-lib
ledgerwatch/erigon-lib
9858eb8 ->testinprod-io/erigon-lib
cbe7326