I want to get the logs of an contract address by filtering the even with transfer Event. I cant use Infura for its restrictions and limits. So i want to sync my own ethereum node for myself. Since my own requirement from the node is to query its database for transfer event so will a Fast Sync node will be enough for me or do i have to go for Full SYNC mode ?
Plese note that syncing optimization is up to clients, not to Ethereum, so each client implements its very own optimization method.
When you say fast sync, I think you refer to geth. Fast sync is now the default sync mode for geth, and it is a way to prioritize objects you want to sync so you can start to work with the chain sooner.
In particular, in geth's fast sync you start asking other clients for the state of the network, not all transactions. Once you have all the recent states, your clients start asking for all transactions and it start verifying each states in background for you. At the end of this process, you will have a complete full node.
Tip: if you are really interested in a specific smart contract, you can also look at the
txlookuplimit parameter, introduced with geth 1.9.14. This feature can reduce drastically the space required by the node to store the index db.
Ethereum mainnet currently contains over 700M transactions. Each full node maintains a search index, stating that transactions with
hash His stored in
block B. This allows you to look up an arbitrary transaction from the past (at a significant storage cost). But how often do you look up transactions from years ago?
Geth v1.9.14 ships a
--txlookuplimitflag, which specifies the number of recent blocks you want to maintain the search index for (by default it's
0= since genesis). At its most extreme, you can set it to
1, to prune all past indexes. At the time of release, this reduces your LevelDB SSD footprint by 32GB! You can modify this flag at will, Geth will unindex/reindex in the background based on the current setting. If you unindex a lot of transactions, you might need to compact your database to reclaim the space immediately via debug.chaindbCompact().
Deleting transaction indexes locally is fine since they are not used in consensus nor in synchronization, so network health is unaffected. Light servers for now do need to maintain the full index since light clients rely on them. Huge props to @rjl493456442 and @holiman for this work (#20302).