Статья пока в режиме заметки и больше содержит информации о проблемах, нежели о их решениях, но так как информации очень много по ходу встречается, я буду записывать отдельные важные моменты, а по мере нахождения ответов на вопросы, буду их сюда дописывать.
Различные режимы синхронизации Ethereum.
Есть три режима: fast, full и light.
По умолчанию используется режим fast. Считается, что в этом режиме синхронизация выполняется за считанные часы (а то и того меньше). Но я пока что еще считаю, что это самый бесполезный режим. В этом режиме не загружается ни история транзакций, ни балансы кошельков, ни коды смартконтрактов, то есть по сути ничего нужного. На сколько я понимаю,
Пример запуска geth в докере
ocker run -d --name ethereum-node-fast --restart unless-stopped -v /root/ethereum/fast/:/root \
-p 8545:8545 -p 30303:30303 \
ethereum/client-go --rpc --rpcapi "db,eth,net,web3,personal" --rpcaddr "0.0.0.0" --rpccorsdomain "*" --syncmode "fast" --maxpeers 0 \
Важно! --rpccorsdomain "*" - не секурно. Если так делаете, то закрывайте порт 8545 файерволом, порт не должен быть доступен извне просто так.
Режим full самый полезный, но и самый затратный. Сервер надо минимум с 16Gb оперативы. Дискового пространства надо сотни гигов (скажу точно, когда у меня синхронизация завершится), при чем нужны именно SSD, обычные диски не справятся с количеством операций в секунду. И первичная синхронизация занимает не один день (я скажу сколько у меня займет, если сумеет синхронизироваться).
Режим light самый сбалансированный, потому как и синхронизация быстрее выполняется, и ресурсов кушает меньше, и есть балансы и контракты. Но одновременно это и самый глючный режим. Жалоб на невозможность синхронизации море. У меня и у самого постоянно ошибка лезет.
WARN [07-04|03:13:37.241] Synchronisation failed, dropping peer peer=7cc23780acd19d17 err=timeout
WARN [07-04|03:14:20.899] Rolled back headers count=64 header=7278783->7278783 fast=0->0 block=0->0
Что интересно, однажды у меня получилось синхронизироваться, но сейчас вот никак. Посмотрим в каком режиме быстрее получится запуститься.
Локальные запросы к geth через сокет.
Случайно встретил на просторах и кажется интересная фишка. Вместо запроса
curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}' -H "Content-Type: application/json" localhost:8545
можно напрямую слать запросы в сокет.
echo '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' | nc -U /$ethereum_path/geth.ipc
Проблема получения списка транзакций.
Что интересно, в эфире "из коробки" не предусмотрена функция получения списка транзакций. Ни просто списка, ни по адресу. То есть нельзя взять какой-то адрес и получить по нему всю историю транзакций. Надо делать перебор всех блоков, в них брать список транзакций и в свою базу данных заносить, чтобы в дальнейшем уже делать выборки.
https://github.com/ethereum/go-ethereum/issues/1897
eth.getBalance() всегда возвращает 0
Очень неприятная бага, из-за которой пришлось перезапускать синхронизацию с нуля (хотя уже более 7 млн блоков синхронизировалось). Прикол в том, что хотя статус синхронизации показывает обновляемые блоки и т.п., можно информацию по блокам получить и т.п., но при запросе балансов всегда 0 возвращает. Раскопал подробнее и оказалось, что eth.getBlock("latest") возвращает нулевой блок. Есть теория, что такая бага возникает когда стартуешь запуск без единого аккаунта, то есть как в оффдокументации сказано перед запуском сначала надо создать новый аккаунт, например с помощью команды geth account new.
Запуск geth в режиме службы на ubuntu
1. Создаем файл /root/geth.service с содержимым (параметры вызова geth конечно же можно менять).
[Unit]
Description=Ethereum go client
[Service]
Type=simple
ExecStart=/usr/bin/geth --rpc --rpcapi "eth,net,web3,personal" --rpcaddr "0.0.0.0" --rpccorsdomain "*" --syncmode "full" --cache 1024 --etherbase 0xYourBaseAccountAddress
[Install]
WantedBy=default.target
Важно: права файла не должны быть на исполнение, иначе служба не запустится.
2. Проверяем файл на профпригодность.
sudo systemd-analyze verify /root/geth.service
При этом я получаю сообщение Attempted to remove disk file system, and we can't allow that., но это вроде как совсем не критично. Других сообщений об ошибках не должно быть.
3. Регистрируем службу.
systemctl --user enable /root/geth.service
В интернете много примеров не с абсолютным путем, но работает именно так.
4. Запускаем службу.
systemctl --user start geth.service
А вот здесь абсолютный путь не пишется, потому что здесь используется имя службы, а не файла.
5. Проверяем статус службы.
systemctl --user status geth.service
Должно быть Active: active (running).
Подключение geth консоли
rpcapi можно запускать в том числе с модулем admin, но это очень не секурно. При этом вам может понадобиться немного админской информации. Для этого можно подключиться к этериуму непосредственно в терминале на сервере, выполнив команду geth attach. Уточню, что такой вариант сработает когда geth уже выполняется и имеется активный geth-сокет. В противном случае вы получите ошибку. А если все ОК, то вы получите приветственное сообщение и можно продолжить работу. Внутри будет обычная javascript-среда с уже подключенным web3 со всеми модулями, в том числе admin. Корневой объект - web3. Можете в консоли просто набрать web3 и нажать Enter, увидите структуру этого объекта. А можете непосредственно обращаться к модулям eth, admin, debug и т.п.
UPD 20.08.2019: Все полная синхронизация успешно выполнена. Что удалось выяснить?
1. Хотя и говорится много где, что 16Gb оперативы должно хватать, по факту этого не хватало. То есть запускалось все, некоторое время работало, а потом ломалось. Особенно быстро geth разваливался, когда начинали поступать внешние запросы на ноду через RPC-API. В итоге поднял конфигурацию до 32Gb 8 core и все стало работать стабильно (гнал очень активно многие тысячи запросов на ноду, все работало ОК).
В итоге сервер на digitalocean.com стоит $160 + $100 за хранилище 1000Gb (сейчас 8 300 000+ блоков занимают на диске 590Gb), итого $260 в месяц + 20% налога.
2. Синхронизация выполнялась примерно месяц (плюс-минус). Но сейчас блоки новые появляются секунда-в-секунду (ориентируясь по etherscan).