>> the best implementations that I know about > Would that be Erigon (nee turbo-geth)? No, but Erigon is very good. Erigon2 (the research branch), Besu (bons

>> the best implementations that I know about > Would that be Erigon (nee turbo-geth)? No, but Erigon is very good. Erigon2 (the research branch), Besu (bonsai mode), Akula and Silkworm are other small-storage implementations. >> Syncing a full history archive node has been done in less than 1 day. > Am I right in assuming that this is some form of snapshot sync which doesn't include actual validation/verification of the blocks and integrity of the resulting state? No. Geth snapshot sync takes 4-6 hours. The verification of all blocks from genesis is done by Akula in less than 1 day according to their own tests. (They evidently have a faster machine than I do, but extrapolating from other data I expect < 2 days on mine.) > > The entire full history archive state fits in about 400 GiB. > Similar question here - if we disregard indexing (and I guess tracing?) etc which would have to be done separately, would the information contained therein be enough to derive past block states and events and, say, replicate a block explorer like etherscan? Yes, that 400 GiB is enough to provide fast lookup of any data point in the state history, sufficient for a block explorer like etherscan. A bit more space may be required for indexes such as lookup by transaction hash, as you say. Technically just the blocks is enough to derive past states and replicate a block explorer :-) But I know what you mean. > I see now that I'm more out of the loop than I realized and Nimbus is also doing an eth1 implementation now - is that what you're referring to? No, because a Nimbus-eth1 node takes 24,000 GB and months to sync :-) Nimbus-eth1 has its good points but it's behind other implementations in performance at the moment. There have been some good performance proof of concept tests, but I don't work on Nimbus any more and can't comment on its future.