179
Update on Dec 9th, 2018 / Block ~ 6_850_000 - It's quite an annoyance to keep this answer updated.
Geth (Go)
Last Update: May 14th, 2018 / Block ~ 5_600_000
Client / Mode | Block Number | Disk Space
======================|================|===========
geth light | 5_600_000 | 363M
geth fast full | 5_600_000 | 142G
geth ...
34
Currently, the network is growing at around 1GB per month. It's hard to anticipate how large it could grow and at what pace, but there are already efforts underway to implement state-tree pruning in various clients. These techniques will contribute towards so-called "light-clients".
In linked chart above, Block size evolution estimating block size in bytes ...
28
Lets take it one step at a time.
Blockchains generally work by having an origin (genesis) state with a few accounts having funds, and then every block that you place on top of the chain moves those origin funds around, also granting a bit of extra for the miner. So whenever you import a new block into your existing chain to take a look at what your view (...
22
geth and parity have differents methods to save the ethereum blockchain in their internal format. I made many benchs because i find it so long just to use a Wallet.
The pruning mode is how the block data are saved. With the archive mode, all states are saved. So, you know the state at each moment without to reload all the blockchain. With fast and light, we ...
21
It is a similar concept to garbage collection in programming languages and in tree-based version control system like git.
When ethereum contracts run, they modify their state. And since the state tree is an immutable append-only structure, it means that every time the state is modified, it gets a new state root. Some elements that were reachable from the old ...
17
Two reasons:
Fast sync indeed has one additional weakness compared to full sync. As long as an attacker can keep you isolated from the main chain (e.g. infect your router), it may construct an arbitrary state that your node will believe (details in https://github.com/ethereum/go-ethereum/pull/1889, Weakness section). This is the reason why fast sync is only ...
16
As of today, ethereum blockchain (ETH, i.e. supporting DAO fork) downloaded in full mode occupies 75GB on my drive. Client is geth (go-ethereum), version 1.4.18, built from source cloned from https://github.com/ethereum/go-ethereum, running on CentOS Linux release 7.2.1511.
15
I've stumbled upon the links bellow :
1- provides an online chart which presents the Ethereum's blockchain current size evolution alongside the Bitcoin blockchain's size.
http://bc.daniel.net.nz/
2- provides details about the Ethereum network including the blockchain size
https://bitinfocharts.com/ethereum/
13
With each block state (contracts storage and balances) is changing.
By default (archive) we keep in database full state of every block.
With different pruning algorithms we are ditching state data for old blocks maintaing only the parts that are needed. basic/fast/light are just various approaches to that problem with different trade-offs.
geth --fast is ...
9
Simple answer no. --fast download a pruned version of the state tries, but it behaves like archive after. So if you want spare disk, remove your blockchain with geth removedb and do a --fast again.
8
Benchmarks done on Homestead in june 2016
Geth 1.4.9 on i7 3720QM 16GB ram and SSD
-----------------------------------------
| - | Full | Fast | Light |
|-----------|--------|--------|---------|
| Disk | 22GB | 4.8GB | 600 Mo |
| Time | 5h | 21m | 21m |
-----------------------------------------
Parity 1.2 on i7 ...
7
As of February 1, the blockchain size is ~940k blocks, with a new block being created every 17.2 seconds. This means, on average, the blockchain increases by 152,790 blocks every month.
A rough average block size, at this time, is around 1,225 bytes. With this average block size, the blockchain size increase is 187MB per month (152,790 blocks x 1,225 bytes)....
6
The behavior has changed with the release of geth v1.8.0
Fromt the release notes
Tracing and pruning: By default, state for the last 128 blocks kept in memory. Most states are garbage collected. If you are running a block explorer or other service relying on transaction tracing without an archive node (--gcmode=archive), you need to trace within this ...
5
The ethereum clients connect to some trusted nodes that I believe are run by the ethereum foundation. The p2p layer uses authenticated encryption, so these connections are secure regardless of what the attacker controls. So long as one such connection exists, you ought to be able to see the correct chain. Additionally, an attacker would have to expend lots ...
5
Light clients are on the way for lower power embedded devices. I believe these light clients only get block headers initially, and further data as needed on-demand from full nodes on the Ethereum network. Here are 2 of the light clients that are work-in-progress I am aware of:
Official Ethdev Light Client
Ethcore's Parity
In regards to pruning the ...
4
Yes, there is an assumption that when the node tries to connect to a given IP address, that in fact it is. To restate what Ethan said a little differently, if you are concerned that you might be MITM'd, you will need to confirm the state root out of band. Once you have manually confirmed that you're on the right chain, your security improves dramatically. ...
4
I'm syncing a node in full mode. At the moment it' on block 5005306 (end of January 2018) and it is 700Gb. It's probably been running for more than 20 days
3
Update: I had originally thought the OP's question was about stored state, but have since realized that even the block headers seem to be unavailable. Answers have been edited a bit to reflect this, but still kept in their general format to help anyone who might have the headers but is wondering where their state went.
Full nodes verify the entire chain, but ...
3
There is ongoing research into light clients, these are clients that do not require an entire copy of the block chain to function.
I believe you conflated the terms 'memory' and 'disk space' in your question. A light client would require less disk space to function.
More details can be found on the ethereum wiki.
Interestingly it was just a week ago ...
2
Use geth --fast:
--fast Enable fast syncing through state downloads
This only downloads the blockchain and verifies the proof-of-work. It does not commit all transactions included in the blocks and therefore can be considered a pruned sync since not the whole state is recalculated.
After the blockchain was downloaded, the client requests the ...
2
For now it's probably for simplicity of implementation - due to the fact that keeping one copy properly would require reference counting. Since contracts can be destroyed using the SUICIDE opcode, if multiple contracts share the same code but one destroys itself and the shared single copy of the code is removed from the local storage then it would break the ...
2
Archive nodes are only necessary if you're going to be querying historical nodes that are no longer on the state trie.
That said, even fast-pruned nodes allow you to inspect some (configurable) depth of history on the state trie, so whether it's sufficient depends on your use-case.
A cheat sheet: https://dev.to/5chdn/ethereum-node-configuration-modes-cheat-...
1
Seeing as nobody else has provided any answer let me try to give an answer of some sort. I'm not very familiar with this and googling was giving me a bit contradictory results - somebody please correct me if I'm wrong. I was trying to summarize different synchonization types a while ago without much feedback: Different synchronization types
I'd imagine that ...
1
This is incorrect. I think the disconnect is that the block doesn't just contain changes to the state, it also contains the state root itself, which is generated using the entire current state. Essentially this means that, for the last 5000 blocks, the entire state is stored for each of those blocks, but discarded for blocks before that. So you have the ...
1
I asked myself this question too, and by looking at bitcoin's implementation of merkle trees, it seems like the two hashes are first, treated as binary data and second, they're indeed concatenated.
1
Thanks for accepting the challenge of running a full archive node! :D
1) what are the drivers for the speed of the syncing in archive mode in parity ? Is that CPU ? Disk (hdd vs ssd) ? Memory (I also tried increasing the cache size to 4GB but it did not help) ? Network (i have a fast connection and it was sufficient until recently) ?
The main bottleneck ...
1
I wouldn't recommend using that approach of mocking/downloading the ethereum blockchain ahead of time to skip a full sync. If you want to just sync the bare minimum of the ethereum blockchain, you should run a client in "light mode" where Geth will just download the block headers, but not the entire block, you will have to ask a full node for the block body ...
Only top voted, non community-wiki answers of a minimum length are eligible
