Using this caveat however would mean, that the pivot point can be considered secure only after N headers have been imported after the pivot itself. To prove the pivot safe faster, we stop the "gapped verificatios" X headers before the pivot point, and verify every single header onward, including an additioanl X headers post-pivot before accepting the pivot‘s state. Given the above N and K numbers, we chose X=24 as a safe number.

然而，使用這個特性意味著，只有導入N個區塊之後再導入pivot節點才被認為是安全的。 為了更快地證明pivot的安全性，我們在距離pivot節點X距離的地方停止隔塊驗證的行為,對隨後出現的每一個塊進行驗證直到pivot。鑒於上述N和K數字，我們選擇X = 24作為安全數字。

With this caveat calculated, the fast sync should be modified so that up to the pivoting point - X, only every K=100-th header should be verified (at random), after which all headers up to pivot point + X should be fully verified before starting state database downloading. Note: if a sync fails due to header verification the last N headers must be discarded as they cannot be trusted enough.

通過計算caveat，快速同步需要修改為pivoting point - X,每隔100個區塊頭隨機挑選其中的一個來進行驗證，之後的每一個塊都需要在狀態數據庫下載完成之後完全驗證，如果因為區塊頭驗證失敗導致的同步失敗，那麽最後的N個區塊頭都需要被丟棄，應為他們達不到信任標準。

缺點 Weakness

Blockchain protocols in general (i.e. Bitcoin, Ethereum, and the others) are susceptible to Sybil attacks, where an attacker tries to completely isolate a node from the rest of the network, making it believe a false truth as to what the state of the real network is. This permits the attacker to spend certain funds in both the real network and this "fake bubble". However, the attacker can only maintain this state as long as it‘s feeding new valid blocks it itself is forging; and to successfully shadow the real network, it needs to do this with a chain height and difficulty close to the real network. In short, to pull off a successful Sybil attack, the attacker needs to match the network‘s hash rate, so it‘s a very expensive attack.

常見的區塊鏈(比如比特幣，以太坊以及其他)是比較容易受女巫的影響，者試圖把被者從主網絡上完全隔離開，讓被者接收一個虛假的狀態。這就允許者在真實的網絡同時這個虛假的網絡上花費同一筆資金。然而這個需要者提供真實的自己鍛造的區塊，而且需要成功的影響真實的網絡，就需要在區塊高度和難度上接近真實的網絡。簡單來說，為了成功的實施女巫，者需要接近主網絡的hash rate，所以是一個非常昂貴的***。

Compared to the classical Sybil attack, fast sync provides such an attacker with an extra ability, that of feeding a node a view of the network that‘s not only different from the real network, but also that might go around the EVM mechanics. The Ethereum protocol only validates state root hashes by processing all the transactions against the previous state root. But by skipping the transaction processing, we cannot prove that the state root contained within the fast sync pivot point is valid or not, so as long as an attacker can maintain a fake blockchain that‘s on par with the real network, it could create an invalid view of the network‘s state.

與傳統的女巫相比，快速同步為者提供了一種額外的能力，即為節點提供一個不僅與真實網絡不同的網絡視圖，而且還可能繞過EVM機制。 以太坊協議只通過處理所有事務與以前的狀態根來驗證狀態根散列。 但是通過跳過事務處理，我們無法證明快速同步pivot point中包含的state root是否有效，所以只要***者能夠保持與真實網絡相同的假區塊鏈，就可以創造一個無效的網絡狀態視圖。

To avoid opening up nodes to this extra attacker ability, fast sync (beside being solely opt-in) will only ever run during an initial sync (i.e. when the node‘s own blockchain is empty). After a node managed to successfully sync with the network, fast sync is forever disabled. This way anybody can quickly catch up with the network, but after the node caught up, the extra attack vector is plugged in. This feature permits users to safely use the fast sync flag (--fast), without having to worry about potential state root attacks happening to them in the future. As an additional safety feature, if a fast sync fails close to or after the random pivot point, fast sync is disabled as a safety precaution and the node reverts to full, block-processing based synchronization.

為了避免將節點開放給這個額外的者能力，快速同步(特別指定)將只在初始同步期間運行(節點的本地區塊鏈是空的)。 在一個節點成功與網絡同步後，快速同步永遠被禁用。 這樣任何人都可以快速地趕上網絡，但是在節點追上之後，額外的矢量就被插入了。這個特性允許用戶安全地使用快速同步標誌（--fast），而不用擔心潛在的狀態 在未來發生的根***。 作為附加的安全功能，如果快速同步在隨機 pivot point附近或之後失敗，則作為安全預防措施禁用快速同步，並且節點恢復到基於塊處理的完全同步。

性能 Performance

To benchmark the performance of the new algorithm, four separate tests were run: full syncing from scrath on Frontier and Olympic, using both the classical sync as well as the new sync mechanism. In all scenarios there were two nodes running on a single machine: a seed node featuring a fully synced database, and a leech node with only the genesis block pulling the data. In all test scenarios the seed node had a fast-synced database (smaller, less disk contention) and both nodes were given 1GB database cache (--cache=1024).

為了對新算法的性能進行基準測試，運行了四個單獨的測試：使用經典同步以及新的同步機制，從Frontier和Olympic上的scrath完全同步。 在所有情況下，在一臺機器上運行兩個節點：具有完全同步的數據庫的種子節點，以及只有起始塊拉動數據的水蛭節點。 在所有測試場景中，種子節點都有一個快速同步的數據庫（更小，更少的磁盤爭用），兩個節點都有1GB的數據庫緩存（--cache = 1024）。

The machine running the tests was a Zenbook Pro, Core i7 4720HQ, 12GB RAM, 256GB m.2 SSD, Ubuntu 15.04.

運行測試的機器是Zenbook Pro，Core i7 4720HQ，12GB RAM，256GB m.2 SSD，Ubuntu 15.04。

The resulting databases contain the entire blockchain (all blocks, all uncles, all transactions), every transaction receipt and generated logs, and the entire state trie of the head 1024 blocks. This allows a fast synced node to act as a full archive node from all intents and purposes.

結果數據庫包含整個區塊鏈（所有區塊，所有的區塊，所有的交易），每個交易收據和生成的日誌，以及頭1024塊的整個狀態樹。 這使得一個快速的同步節點可以充當所有意圖和目的的完整歸檔節點。

結束語 Closing remarks

The fast sync algorithm requires the functionality defined by eth/63. Because of this, testing in the live network requires for at least a handful of discoverable peers to update their nodes to eth/63. On the same note, verifying that the implementation is truly correct will also entail waiting for the wider deployment of eth/63.

快速同步算法需要由eth / 63定義的功能。 正因為如此，現網中的測試至少需要少數幾個可發現的對等節點將其節點更新到eth / 63。 同樣的說明，驗證這個實施是否真正正確還需要等待eth / 63的更廣泛部署。

{區塊鏈教程}以太坊源碼分析fast sync算法二