erigon help flags - alpha feedback

[MysticRyuujin]

Just providing some feedback / reporting some issues as I read through the flags on the new alpha version of Erigon.

1. What does "fast" mean? Isn't default "Full"?

--syncmode value                   Default: "snap" for BSC, Mainnet and Goerli. "fast" in all other cases

2. Should the ethash.dagdir go inside the datadir it defaults outside of it?

--ethash.dagdir value              Directory to store the ethash mining DAGs (default: "/home/chase/.local/share/erigon-ethash") [<invalid Value>]

3. I don't think these flag names matches their description...

--http.compression                 Comma separated list of virtual hostnames from which to accept requests (server enforced). Accepts '*' wildcard.
--ws.compression                   Comma separated list of virtual hostnames from which to accept requests (server enforced). Accepts '*' wildcard.

4. The release notes say that rpcdaemon is included and turned on by default but the flag is --http so it seems weird.

--http                             Enable the HTTP-RPC server

5. Is this a wildcard, a regex, or an exact match? Comma separated?

--rpc.accessList value             Specify granular (method-by-method) API allowlist

6. Typo!

--torrent.upload.rate value        byt,es per second, example: 32mb (default: "4mb")

[AskAlexSharov]

1. https://ethereum.stackexchange.com/questions/1161/what-is-geths-fast-sync-and-why-is-it-faster#1165

2. I didn’t know, need to check (but consensus will change soon by the merge).

3. Yes, need to fix - it’s usual http compression (as in any http server).

4. Right it is not on by default, need to fix description.

5. It’s path to file. File parsed by: https://github.com/ledgerwatch/erigon/blob/9051d95836a0a5cc6ba6c6ff0a3b1d28525484b8/cmd/rpcdaemon/cli/rpc_allow_list.go#L16 band this is exact match https://github.com/ledgerwatch/erigon/blob/95d686f24a4e7e4420f741b5a45c2e51a5da4b52/rpc/allow_list.go#L5

[MysticRyuujin]

For number 1 - I know what fast sync IS, my question is how it's related to Erigon2 / Alpha... You've never supported anything like fast sync before. It's always been a full sync historically...

[AskAlexSharov]

1.1. Maybe it's confusion in my head. My head has: "fast sync" it's sync algorithm, it can produce Full Node, Archive Node, etc... "snap sync" it's also sync algorithm which can produce Full Node, Archive Node, etc... In geth it's 2 cli flags: syncmode and gcmode.
1.2 My intent was to keep some level of compatibility with geth cli flags. So, I re-used syncmode flag. Here is where they changed default --syncmode from fast to snap: https://blog.ethereum.org/2021/03/03/geth-v1-10-0/
1.3 gcmode was not possible to re-use because our prune flag is very different - allow more granularity, etc...
1.4 Our snap sync is not compatible with geth snap sync (not compatible snapshots format and sync protocol). But it's ok, because for end-user it behaves same way.
1.5 I have problem with naming of snap-related flags. Example: --snap.keepblocks=true --torrent.port=123 --torrent.download.speed=1mb are all snap sync related flags. Because by design snap sync can work over Bittorrent or over IPFS - but I don't want go for --snap.torrent.download.speed=1mb. Maybe you have some ideas.

[revitteth]

Looks like these points are all addressed, will close!