最近微博的某人额外关注起了Ethereum全节点，并Po了这么一张照片，一笑置之。虽说Ethereum全节点占用的磁盘空间确实比Bitcoin大了几倍，但也不至于为了节省几块硬盘，不去同步全节点。! P# e. q1 H; r0 \* I: h
3 e; h+ Z4 e2 Y3 A* y2 i
本人在18年的6月份用Geth同步过全节点。当时想把区块链数据用异构的方式查询， 比如提供 Sql 、GraphQL访问，而不在通过rpc接口访问数据。+ h- u# x( J) ], ]8 A
而首要工作是把全节点数据放入到数据仓库中，那就要先从同步全节点的任务开始。
; ^" Y+ F- J8 h3 s0 J* ?
$ M  p2 M  i$ e9 x6 d1 o! Y类似 ocap.arcblock.io
: w! ?; |, O* r2 _% ^/ p3 O) ]服务器配置当时云主机选择的是阿里云香港，操作系统是Ubuntu，8G内存，主流CPU，30G系统盘，外挂1T高效硬盘，带宽2M。 这是最低的基本硬件配置，再低，同步速度就太慢了。
" u7 l: d# l9 }0 u, f获得Gethhttps://ethereum.github.io/go-ethereum/downloads/，选择Stable Linux 64bit版本，记得校验Checksum，防止软件被篡改。" f% R7 o& w0 X2 S7 ?) r) F/ v5 L

; o* x3 b# \  O5 r1 v" K5 lGeth* Z& Y* ?. s# v. x% j, |' ~+ |, [
# 下载8 R5 A# _! h  A7 Y
wget https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-1.8.23-c9427004.tar.gz * N* W6 c* t: \" Z% ~( k1 X! D+ L
md5sum geth-linux-amd64-1.8.23-c9427004.tar.gz # 校验. F1 @5 M  A4 P/ b) D; f9 }# @' S
# => a3b2dd950bc986036be4ff66efec36f9
9 u+ w" _5 m* j2 R' [& I& r# 与上文提供的Checksum比较，如果一致说明文件没有被篡改
5 Y/ ]0 o3 R+ Utar -xzf geth-linux-amd64-1.8.23-c9427004.tar.gz # 解压
: H# T5 c# g! h# Z: Cmv geth-linux-amd64-1.8.23-c9427004/geth /usr/bin/ # 移动 放到全局环境变量中1 z! b+ J: j6 c8 G) K7 P
which  geth # 查看位置如果想通过手动编译的方式，请移步 https://www.jianshu.com/p/65ae648b97ae
' k  ^0 ?. n8 o同步方式Geth 有3种同步方式：full，fast，light，默认是fast模式。
8 O, I0 }1 {7 ^, {6 bgeth -h | grep sync" M5 s+ F& n. v; O0 r2 [, _
# --syncmode fast    Blockchain sync mode ("fast", "full", or "light")Full  P* U0 D* n9 S4 K
同步完整的区块信息，获取所有历史区块的header、body数据，3 a' Q" W5 R% q. }6 O6 I  N
从创始块开始校验每一个元素，并顺序执行其中的所有交易，验证区块头中的 stateRoot、transactionRoot 和 receiptRoot。5 U" j, I( _' h2 o  I( h, Y
Fast" W/ i4 M4 y# X+ ~
获取所有历史区块的header、body数据，但不执行其中的任何交易，所以也无法验证区块头中的三个状态根。
0 O  p% h  m/ c/ ^' `在追上最新区块之后，会继续请求最新的完整 state trie 数据，并维护最新的 state trie 和 receipt trie 数据，但不保存它们的历史版本。) S7 P0 x7 i" K; I9 l9 a
所以可以用 fast 模式同步的节点执行智能合约来获得最新的状态。使用此模式时可以设置 --cache，默认1024M7 s+ e% w7 t1 W. X2 i4 E' |
--syncmode fast --cache 2048Light
' c; k/ H( M; u: T; D! h- f- `: i只下载所有区块的header数据，本地仅做交易是否发生的验证，% z; y7 r  W2 X$ L( N' c# ?4 A
也就是仅下载最新区块的所有数据并验证 transactionRoot 是否一致。无法进行任何状态验证。
: R6 j5 E. k/ N4 P1 _设定datadir即储存数据的位置，使用full模式，并让这个进程在后台持续运行; u  ]9 Q4 f( x  O3 y/ a  h7 \
nohup geth --datadir /mnt/eth --syncmode full &
! N) x8 m: Q1 q2 f4 l7 c$ ~经过24小时不间断的同步，达到了500万块高度，硬盘空间大概用了683G，大概花了10天左右时间。
" ^; U- J; T( z( J2 _( a# p存档节点 gcmodegeth -h | grep gcmode% U' |6 p1 t8 K, b6 O7 I7 z
--gcmode full      Blockchain garbage collection mode ("full", "archive")
1 q" p" X" k* v, [3 a! p区块的垃圾回收模式，默认是fullarchive模式存储着智能合约中的所有值状态以及帐户余额的完整历史记录$ ~2 B; {1 ?# w# u9 V, S0 a  r' m" @+ T
syncmode=full 验证每块的state trie、transaction trie 和 receipt trie数据，但并不保存所有的 state trie、transaction trie 和 receipt trie 的完整历史版本。
1 o, ]8 |0 C, a) V如果一个合约的字符串的值，在6000000高度的时候是xyz，在 6000001高度的时候变为ABC，这只有在archive模式下才会记录，其他的同步模式，会裁剪过去的状态，将只会保存最新的值。具体来说，gcmode=full模式，只有最近的128次状态被保存在内存中，再多的状态会被丢弃。比如说现在同步到了 7000000高度，只会记录7000000-128 到7000000高度的之间的合约的某个状态的值。; Q" U- @5 ]% v8 }$ H
Parity甚至提供了一种同步模式，只记录一定数量的过去状态，从而减少了同步链数据的大小。% A$ X. [2 C9 }% v% B- ~% O/ {1 I
使用 --syncmode=full --gcmode=archive 模式，即归档节点，这种模式保存了最最最全的Ethereum节点数据，占用硬盘空间也会更大。
! N( p2 j) K" T( n我当初就是用归档模式，同步到500w高度的时候，1T硬盘已经塞爆了...( q  Y. O8 k) B* T8 d9 }
也许本人使用的这种同步方式对达到工作目的来说并不是最有效的，最经济的，这个不是讨论的重点。3 _  e: d9 A) ?. ?' \! ~7 m
有感我相信大部分人知道syncmode模式，而不知道 gcmode模式，更没有同步过存档模式。- F7 V$ O( n* d: E. x- P4 |
Ethereum在 2015-07-30诞生，经过4年的发展到现在的740w高度，& Q* K+ h( k; j" }# s8 a
从https://etherscan.io/chartsync/chainarchive 数据来看，完完整整的区块链数据已经膨胀到2231.5 GB，也就是2.2 TB，同步时间要花几个月时间，而且每天以 3～4 GB的速度在增长。在过几年5TB的硬盘可能也装不下了，这也是为什么ethereum技术社区对的分片呼声这么高的原因。! U7 ]1 G, p. ?2 g) K/ b4 ]
Bitcoin在2009-01-03诞生，经过10年的发展，完完整整的区块链数据基本也就200多GB，同步时间基本在24~36小时。/ G5 N3 x5 @1 K) R5 f+ A4 X
从保持去中心化，保有全量数据的角度来说，Bitcoin 在这两方面平衡的相当好。而Ethereum归档节点的机器成本已经很高了，个人没有太多动力去维护。. x2 g% r  c7 C! g: P
之前我曾抱怨Bitcoin技术推动太墨迹，丧失了很多机会，现在我感觉Ethereum面临的技术挑战相当严峻。从最近的君士坦丁堡硬分叉出现的问题来看，这2个最知名的区块链技术团队的行事风格差异也挺大的。- |6 o) V" R# o5 ?
Bitcoin是伟大的创举，Ethereum是天才的设计，前者是从0到1跨时代的发明，后者带来了智能合约，深刻影响着传统的经济观念。总之，都祝好吧。