bor: revise the integration code

[battlmonstr]

Rationale

Currently bor-specific code is scattered around the codebase. Mentions of bor/heimdall/polygon exist in the following files and folders:

cmd/devnet/args/node.go
cmd/devnet/contracts/
cmd/devnet/main.go
cmd/devnet/requests/request_generator.go
cmd/devnet/services/context.go
cmd/devnet/services/polygon/
cmd/integration/commands/flags.go
cmd/integration/commands/reset_state.go
cmd/integration/commands/stages.go
cmd/integration/commands/state_stages.go
cmd/rpcdaemon/cli/config.go
cmd/rpcdaemon/main.go
cmd/state/commands/erigon4.go
cmd/utils/flags.go
common/paths/paths.go
consensus/bor/
consensus/misc/eip1559.go
core/genesis_write.go
core/rawdb/bor_receipts.go
core/types/accounts/account.go
core/types/bor_receipt.go
eth/backend.go
eth/ethconfig/config.go
eth/ethconsensusconfig/config.go
eth/stagedsync/default_stages.go
eth/stagedsync/stage_bor_heimdall.go
eth/stagedsync/stage_execute.go
eth/stagedsync/stage_finish.go
eth/stagedsync/stage_postexec.go
eth/stagedsync/stage_txlookup.go
eth/stagedsync/stagebuilder.go
eth/stagedsync/stages/stages.go
params/config.go
params/networkname/network_name.go
params/protocol_params.go
tests/bor/
tests/bor/mocks/IHeimdallClient.go
turbo/adapter/ethapi/api.go
turbo/adapter/ethapi/internal.go
turbo/app/snapshots_cmd.go
turbo/jsonrpc/bor_api.go
turbo/jsonrpc/bor_helper.go
turbo/jsonrpc/bor_snapshot.go
turbo/jsonrpc/daemon.go
turbo/jsonrpc/erigon_receipts.go
turbo/jsonrpc/eth_block.go
turbo/jsonrpc/eth_receipts.go
turbo/jsonrpc/eth_txs.go
turbo/jsonrpc/tracing.go
turbo/jsonrpc/validator_set.go
turbo/services/interfaces.go
turbo/snapshotsync/freezeblocks/block_reader.go
turbo/snapshotsync/freezeblocks/block_snapshots.go
turbo/snapshotsync/freezeblocks/bor_snapshots.go
turbo/snapshotsync/freezeblocks/dump_test.go
turbo/snapshotsync/snapshotsync.go
turbo/stages/mock/mock_sentry.go
turbo/stages/stageloop.go
turbo/transactions/tracing.go

This intrusive architecture makes it hard to see the full picture, find the right place for new bor-specific code, refactor the code without breaking.

The new upcoming PRs like https://github.com/ledgerwatch/erigon/pull/8091 make even more bor-specific changes in various files.

Implementation

Discuss what's the foreseeable future of this integration. Decide if we want to be a platform for similar integrations or not.

1. If we want to be a platform, try to define the integration API boundary and decide which parts could be refactored to a separate erigon-bor "plugin" code and potentially moved out of the main repo. In this case the erigon-bor project could get erigon changes automatically and report breakages to the main repo.
2. Otherwise, maybe just fork erigon as erigon-bor and remove the integration from the main repo. In this case the erigon-bor team will have to merge erigon changes manually and fix breakages by themselves, and it will become more difficult over time.
3. Some mix of 1 and 2.

[mh0lt]

I think that the first phase of this should be to move all of the polygon specifics to a separate package.

I suggest we should go for a directory structure which is:

polygon/bor polygon/heimdall

becuase there is a natural split to the code. It would also make a more natural place to put the polygon specific code from the devnet there. So we'd also likely get

polygon/proofgen

I also think this is more future proof if we do additional polygon projects that are not necessarily POS specific.

I think this should probably be step 1. As it has minimal impact other than an internal code move.

[github-actions[bot]]

This issue is stale because it has been open for 40 days with no activity. Remove stale label or comment, or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.