![]() ![]() In fast sync mode, Geth downloads but does not verify the proof-of-work on every block, instead choosing certain blocks at random. For this, Geth offers a mode where chain data up to a recent block (known as the pivot) is synchronized using a faster approach, with only the few remaining blocks being synchronized using the slower full sync algorithm. Perhaps they have a deadline to meet or they simply don't think the speed tradeoff is worth it. However, some users may not want to wait weeks for a full sync to complete. This is more secure but comes with a heavy speed tradeoff, as a full Geth sync may take anywhere from days to weeks to complete. Geth will also execute every single transaction in the block, which allows it to generate the blockchain state locally without needing to trust other nodes. This means that Geth will download and validate the proof-of-work seals on every single block. Depending on the needs of the user, some tradeoffs between security and speed can be made, so Geth supported (at the time) two different sync modes: full sync and fast sync.Īs the name would suggest, full sync performs a full synchronization of the Ethereum blockchain. This means downloading or computing all of the data needed to build a complete picture of the chain state at the latest block. Whenever someone wants to run an Ethereum node, they must first synchronize with the network. If exploited, an attacker could have booby trapped the Ethereum blockchain and triggered a hard fork at will. Today's post is about a bug in Geth's state downloader which could be used to trick it into syncing with mainnet incorrectly. If you haven't already, take a look at Part 1 here. This is the second in a series of blog posts about bugs I've found in go-ethereum (Geth). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |