This is the second part of the bor milestone release it contains the
following changes:
* Initialize services
* This is a change from the initial pull request I have moved all of the
initialization to the bor engine. To facilitate this I have just passed
in the heimdall client interface, rather than the whole engine
* Stage processing
* This is also a change from the original PR - the code is contained in
the bor heimdall stage rather than in headers - the effect should be the
same, but this needs testing
---------
Co-authored-by: Mark Holt <mark@disributed.vision>
Co-authored-by: Anshal Shukla <shukla.anshal85@gmail.com>
First posted [here](https://github.com/ledgerwatch/erigon/pull/8195)
with bugs, which fixed in this PR.
When we call the debug_traceXXX API provided by Erigon, the withLog
option in tracerConfig is very helpful.
However, currently, the tracer cannot guarantee that the order of logs
output is consistent with the event logs returned in the transaction
receipt. This may make it difficult to use the output of the APIs. If
you need to access event logs in order, it is recommended to use the
event logs returned in the transaction receipt.
Here is an example to illustrate the reason why the order of callTracer
logs and receipt eventlogs can be inconsistent:
In a call trace tree, if a call has multiple logs and this call has
multiple child calls, and logs are also output in the child calls, the
logs of the child calls may be output between the logs of the parent
call in receipt.
I add an index field of log to identify log index of the logs in tracer
result, and it helps me a lot.
For example, erigon on devnet8 marked a block as bad due to
"mdbx_cursor_open: cannot allocate memory":
```
[INFO] [09-12|04:57:36.041] [NewPayload] Handling new payload height=171035 hash=0x321dea00c4853ee354bebaf8aef3e63fbe06c4508271c0db4c92b0f087aedc3b
171034
[WARN] [09-12|04:57:36.069] Could not validate block err="[3/7 BlockHashes] table: Header, mdbx_cursor_open: cannot allocate memory, stack: [kv_mdbx.go:1057 kv_mdbx.
go:1069 kv_mdbx.go:1077 memory_mutation.go:473 memory_mutation.go:502 etl.go:123 etl.go:96 block_writer.go:40 stage_blockhashes.go:49 default_stages.go:457 sync.go:425 sync.go:258 s
tageloop.go:414 backend.go:476 fork_validator.go:250 fork_validator.go:156 ethereum_execution.go:151 execution_client.go:51 chain_reader.go:252 engine_server.go:741 engine_server.go
:235 engine_server.go:600 value.go:586 value.go:370 service.go:224 handler.go:494 handler.go:444 handler.go:392 handler.go:223 handler.go:316 asm_amd64.s:1598]"
[WARN] [09-12|04:57:36.069] ethereumExecutionModule.ValidateChain: chain is invalid hash=0x321dea00c4853ee354bebaf8aef3e63fbe06c4508271c0db4c92b0f087aedc3b
```
With this PR blocks are marked as bad only on genuine protocol errors.
When we call the debug_traceXXX API provided by Erigon, the withLog
option in tracerConfig is very helpful.
However, currently, the tracer cannot guarantee that the order of logs
output is consistent with the event logs returned in the transaction
receipt. This may make it difficult to use the output of the APIs. If
you need to access event logs in order, it is recommended to use the
event logs returned in the transaction receipt.
Here is an example to illustrate the reason why the order of callTracer
logs and receipt eventlogs can be inconsistent:
In a call trace tree, if a call has multiple logs and this call has
multiple child calls, and logs are also output in the child calls, the
logs of the child calls may be output between the logs of the parent
call in receipt.
I add an index field of log to identify log index of the logs in tracer
result, and it helps me a lot.
Fix ``CreateConsensusEngineBareBones`` for bor and aura. Current codes
will pass a ``**chain.BorConfig`` or ``**chain.AuraConfig to``
``CreateConsensusEngine`` and cause a panic
Co-authored-by: Maohua Zhu <zhumaohua@cobo.com>
