Как вручную настроить сводной блок быстрой синхронизации geth?

ВНИМАНИЕ ! Запуск Ethereum Wallet 0.8.7 без ручного запуска geth 1.5.2 приведет к уничтожению данных вашей цепочки блоков!

ОБНОВЛЕНИЕ 22 ноября 2016 г. — Новые gethбинарные файлы 1.5.2 будут загружены Ethereum Wallet / Mist ( источник ), поэтому эта проблема должна исчезнуть. Вам нужно будет перезапустить Ethereum Wallet / Mist, чтобы новые бинарные файлы были загружены.


Я использую стабильную gethверсию Cry Uncle 1.5.2, которая включает последнюю версию Hard Fork No. 4: Spurious Dragon .

Я запустил текущую последнюю версию Ethereum Wallet 0.8.7 , которая gethсодержит стабильную версию 1.4.18 — см. mist/clientBinaries.json, строки 39-55 :

"mac": {
  "x64": {
    "download": {
      "url": "https://bintray.com/artifact/download/karalabe/ethereum/geth-1.4.18-stable-c72f545-darwin-10.6-amd64.tar.bz2",
      "type": "tar",
      "sha256": "1f7ac168a4502a9e88474f74b3cef2dda4843f350d7f9fcdd9ef10dff30b7282",
      "bin": "geth-1.4.18-stable-c72f545-darwin-10.6-amd64"
    },
    "bin": "geth",
    "commands": {
        "sanity": {
        "args": ["version"],
        "output": [ "Geth", "1.4.18" ]
      }
    }
  }
},

Поскольку тогда я не запускал geth1.5.2 вручную, Ethereum Wallet запустил geth1.4.18, и это закончилось тем, что данные моей цепочки были уничтожены, как указано в gethпримечаниях к выпуску 1.5.2 :

Обновление базы данных

Версия 1.5.0 меняет структуру базы данных блокчейна. Geth обновит базу данных во время нормальной работы, но вы не сможете вернуться к предыдущим версиям 1.4.x. Если вы хотите вернуться, вам нужно будет сохранить резервную копию каталога chaindata или выполнить повторную синхронизацию.

Затем мне нужно было решить, загружать ли блокчейн быстрой синхронизации, но мне нужны debug.traceTransaction(...)возможности из блока № 2 394 190 , поскольку я использую эту информацию для некоторого анализа транзакций, но быстрая синхронизация исключает эту информацию до самого последнего блока (в настоящее время 2661841).

Моя цепочка блоков на моем узле майнинга является полным узлом архива и в настоящее время имеет размер 87 Гб, и я не хочу использовать этот объем пространства на моем ноутбуке:

user@Rasterbator:~$ du -hs .ethereum/chaindata/
87G .ethereum/chaindata/

Как быстро синхронизировать блокчейн Ethereum до указанного блока?

Ответы (1)

Резюме

Я скачал gethисходный код, изменил исходный код, указав опорный блок быстрой синхронизации, скомпилировал код, удалил старые данные цепочки и запустил быструю синхронизацию. Как только это будет завершено, я вернусь к запуску обычных gethдвоичных файлов.

ОБНОВЛЕНИЕ Этот эксперимент не удался. С моим взломом было несколько разных ошибок, которые мешали быстрой синхронизации блокчейна с указанным блоком, а затем обычной синхронизации после указанного блока. Вернуться к полной синхронизации узла архива.

У кого-нибудь есть предложения?



Подробности

Я скачал исходный код gethи изменил исходный код для раздела, который вычисляет опорную точку быстрой синхронизации eth/downloader/downloader.go, строки 419-441 :

case FastSync:
    // Calculate the new fast/slow sync pivot point
    if d.fsPivotLock == nil {
        pivotOffset, err := rand.Int(rand.Reader, big.NewInt(int64(fsPivotInterval)))
        if err != nil {
            panic(fmt.Sprintf("Failed to access crypto random source: %v", err))
        }
        if height > uint64(fsMinFullBlocks)+pivotOffset.Uint64() {
            pivot = height - uint64(fsMinFullBlocks) - pivotOffset.Uint64()
        }
    } else {
        // Pivot point locked in, use this and do not pick a new one!
        pivot = d.fsPivotLock.Number.Uint64()
    }
    // If the point is below the origin, move origin back to ensure state download
    if pivot < origin {
        if pivot > 0 {
            origin = pivot - 1
        } else {
            origin = 0
        }
    }
    glog.V(logger.Debug).Infof("Fast syncing until pivot block #%d", pivot)

Я изменил последнюю строку выше, чтобы изменить Debugв Infoи добавил следующие две строки ниже кода выше:

    glog.V(logger.Info).Infof("Fast syncing until pivot block #%d", pivot)
    if (pivot >= 2394190) {
      pivot = 2394190;
    }
    glog.V(logger.Info).Infof("Fast syncing until modified pivot block #%d", pivot)

Я перекомпилировал и запустил процесс быстрой синхронизации, используя модифицированные двоичные файлы:

Iota:go-ethereum user$ make geth
...
Done building.
Run "build/bin/geth" to launch geth.

Я проверил версию модифицированного geth:

Iota:go-ethereum user$ build/bin/geth version
Geth
Version: 1.5.3-unstable

Я удалил старые поврежденные данные цепочки:

Iota:go-ethereum user$ build/bin/geth removedb
/Users/bok/Library/Ethereum/chaindata
Remove this database? [y/N] y

Removing...
Removed in 35.242291ms

Я запустил быструю синхронизацию:

Iota:go-ethereum user$ build/bin/geth --fast --cache=1024 console
I1120 23:44:44.870142 ethdb/database.go:83] Allotted 1024MB cache and 1024 file handles to /Users/user/Library/Ethereum/geth/chaindata
I1120 23:44:44.878926 ethdb/database.go:176] closed db:/Users/user/Library/Ethereum/geth/chaindata
...
I1121 08:33:51.340811 eth/downloader/downloader.go:441] Fast syncing until pivot block #2664150
I1121 08:33:51.340847 eth/downloader/downloader.go:445] Fast syncing until modified pivot block #2394190

После завершения быстрой синхронизации я вернусь к использованию обычных двоичных файлов geth.