5 ms·

Oh, hi Jamie :) Great to hear about the substantial improvements! Some follow-up questions if you don't mind: > the best implementations that I know about Wo

by 3np 5y ago

Oh, hi Jamie :) Great to hear about the substantial improvements! Some follow-up questions if you don't mind: > the best implementations that I know about Would that be Erigon (nee turbo-geth)? I think work was just going public on that around the time we were messing around with this and I haven't taken it for a spin yet. > 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? Because otherwise that sounds (almost) impossibly short. If so, do you have any idea what one should expect to be able to achieve for that? > 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? Regardless, keep up the good work. Nimbus seems like a great eth2 client. EDIT: Ooooh, 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?

jlokier 5y ago
>> 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.
- deleted 5y ago
  [deleted]

by 3np 5y ago

jlokier 5y ago

>> 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.

deleted 5y ago
[deleted]