Support op-erigon scripts and docker images about node HOT 19 CLOSED

@HiroyukiNaito Changing pruning settings will require you to remove existing DB and resync

from node.

@HiroyukiNaito It is due to the init command, you should also add --state.schme=path flag on to the init command but I guess base chains would work without the init command since they are already supported.

from node.

In my recognition, op-geth stores all states from the beginning because it cannot do prunning.
So it's near to archive node. Right?

from node.

@HiroyukiNaito No, geth and op-geth is non-archive pruned node by default ( by recent 128 blocks ).

But seems like the docker configuration would run op-geth node in archive state which would be 10x heavier than the pruned nodes https://github.com/base-org/node/blob/main/geth-entrypoint#L65.

op-erigon is much lighter, more performant for archive node purposes.

from node.

@HiroyukiNaito No, geth and op-geth is non-archive pruned node by default ( by recent 128 blocks ).

But seems like the docker configuration would run op-geth node in archive state which would be 10x heavier than the pruned nodes https://github.com/base-org/node/blob/main/geth-entrypoint#L65.

op-erigon is much lighter, more performant for archive node purposes.

This is correct. Also note that op-reth is now an option as well, which is even more lightweight than op-erigon.

from node.

Thus, you know the current base (Docker) node run with --gcmode=archive and it stores all state from the beginning with current Docker setting.
As all we know, the curent disk usage is burden for running node personally.
Can --gcmode=full reduce the disk space now of this operational base op-geth? and why do not set this?
The #126 says pruning is not supported , so I think Base op-geth can not accommodate to run with current 128 blocks.

from node.

@HiroyukiNaito I am running and could run op-geth nodes without --gcmode=archive flag. The flag is only useful if you need to access historical states that should be simulated with old blocks. ( For example looking up on a previously recorded contract data that has been overwritten ).

from node.

@kaliubuntu0206 Thanks! Does it sync quickly from the past 128 blocks? Honestly now it sync from past 300,000 blocks from the latest snapshot.

from node.

@kaliubuntu0206 I removed the option but it is syncing from the very past block. So, I don't think it has any changes from the option --gcmode=archive on the point of reducing disk space and speeding up sync.

from node.

@HiroyukiNaito The option doesn't change syncing speed but it will reduce your disk footprint

from node.

@kaliubuntu0206 Thanks, but my node hangs from the setting, so backed again to previous setting.
Then Backed to the --gcmode=archive but it "Advancing bq orgin" loop eternally.
I don't think it honestly a best option.

node-node-1  | t=2023-11-07T07:34:17+0000 lvl=info msg="attempting connection"                  peer=16Uiu2HAmJcdX7FGC2iZAXRMVF2wVLDdJca6o2quH9wN7VQ65yCS3
node-node-1  | t=2023-11-07T07:34:17+0000 lvl=info msg="Advancing bq origin"                    origin=0x96c8a31605dc98066872c038bc0dc2e9a4f95f4173da5711376771881d9bcdcd:18468307 originBehind=false
node-node-1  | t=2023-11-07T07:34:17+0000 lvl=info msg="created new channel"                    origin=0x96c8a31605dc98066872c038bc0dc2e9a4f95f4173da5711376771881d9bcdcd:18468307 channel=00c5bae996aaa5f645d0f233bf792ba3 length=36717   frame_number=0 is_last=true
node-node-1  | t=2023-11-07T07:34:17+0000 lvl=info msg="Reading channel"                        channel=00c5bae996aaa5f645d0f233bf792ba3 frames=1
node-node-1  | t=2023-11-07T07:34:18+0000 lvl=info msg="connected to peer"                      peer=16Uiu2HAmJcdX7FGC2iZAXRMVF2wVLDdJca6o2quH9wN7VQ65yCS3 addr=/ip4/54.236.37.29/tcp/9222
node-node-1  | t=2023-11-07T07:34:18+0000 lvl=info msg="Starting P2P sync client event loop"    peer=16Uiu2HAmJcdX7FGC2iZAXRMVF2wVLDdJca6o2quH9wN7VQ65yCS3
node-node-1  | t=2023-11-07T07:34:18+0000 lvl=info msg="attempting connection"                  peer=16Uiu2HAmHQWBX53y7XkLbXpxjwc7fxeiDZumMT6eqpmnG4LoxDzS
node-node-1  | t=2023-11-07T07:34:18+0000 lvl=info msg="Advancing bq origin"                    origin=0x15f4f3f6fe63575aa53e06f588b37fb33f132c38fac7b1cbcda675f7b8b1aef8:18468308 originBehind=false
node-node-1  | t=2023-11-07T07:34:19+0000 lvl=info msg="Advancing bq origin"                    origin=0x677aab79c402977a486d0ca3016f7507947ea8feba7a94b4f32989445aedfa7d:18468309 originBehind=false

from node.

@kaliubuntu0206 So, it needs to download snapshot again. Oh, It's hell.

from node.

cc @roberto-bayardo I think providing snapshot for --gcmode=full --state.scheme=path would be also possible which would provide much lighter node

from node.

@kaliubuntu0206 I tried to --state.schme=path on my node, but it emits error which suggest the option don't support. How to enable --state.scheme=path?

from node.

@HiroyukiNaito Which op-geth version are you using? For the latest version and the version tagged for base I think it is supported?

from node.

@kaliubuntu0206 I use the latest https://github.com/base-org/node/blob/main/Dockerfile#L22 .
However, it emits with error.

from node.

node-geth-1  | Fatal: Failed to register the Ethereum service: incompatible state scheme, stored: hash, provided: path
node-geth-1  | Fatal: Failed to register the Ethereum service: incompatible state scheme, stored: hash, provided: path

from node.

@roberto-bayardo Could you remove the init command?

https://github.com/base-org/node/blob/main/geth-entrypoint#L22

It is unnecessary since op-geth and op-node baked in base mainnet and testnets with my knowledge

from node.

@kaliubuntu0206 Thanks! In the mean time, I try to --gcmode=full and --state.schem=path from the start without a snapshot .

from node.