Да.
Возможно, стоит подумать о контроле доступа к RPC, или хотя бы об контроле количества запросов в минуту от одного клиента — некоторые RPC могут заметно нагружать сервер

(Я впрочем не очень помню, доступны ли такие запросы у geth по умолчанию, или там есть фильтр)

Круто!  :)  Спасибо!

Приветствую!

Поделитесь опытом работы с parity (openethereum).

Пытаюсь сделать обычную ноду на майнете. Начал ставить на двух серверах, оказалось все не радостно:

1) На одном сервере с 500GB нода засинхалась за 1.5 дня. База была на момент полного синга в 108 гигов.
Потом через день почему-то база уже начала весить 300Гигов.
Причем она раз в сутки падала, а сейчас упала с паником и пишет что база повреждена и пытается ее починить.

2) На другом сервере с 250Гигов нода синхается уже 3 дня, никак не может. Уже снепшоты скачались, синхает остатки по 0.2 блока в секунду. Места занимает пока база 80Г.


Поделитесь пожалуйста опытом, как оперативно засинхать парити и добиться ее стабильной работы. Какие вы указываете для нее параметры кешей и прочее.

Документации подробной что-то найти не смог, да и статей актуальных тоже очень мало.

Понятно что в любом случае стоит завернуть RPC-запросы в https при помощи того же nginx. Там и остальные фичи типа рейт-лимитов будет легко добавлять

сначала качается снепшот стейта, досинкиваются блоки, затем в фоне могут довольно долго подтягиваться старые блоки, поэтому размер базы и растет

вот у меня две свежезасинканные, geth радует больше

$ du -hs .local/share/openethereum
453G .local/share/openethereum
$ du -hs .ethereum/geth/
222G .ethereum/geth/

Но вот была полностью рабочей база в 108 гигов. И я через rpc c ней работал. А потом бац, и за сутки +200 гигов.

А ты какие-то параметры запуска менял? Размеры кеша или чего-то еще? Думаю там по умолчанию все очень мелкое.

Geth однозначно лучше. Но мне надо функционал trace_callMany, который вроде как только у парити и есть.

И как ты еще с парити борешься с тем, что она тупа падает и база крешится? Три дня прожила у меня только нода. Свалилась с паником, и теперь востанавливает базу. Причем зараза прогресс нигде не пишет, а процессора почти не жрет. Подозреваю что-то в одном потоке очень медленно делает.

попробуй getBlock где-то из середины сделать, там может быть пусто

я не борюсь, перешел на geth, parity просто про запас

Ты ж на питоне вроде программируешь. Ты не пробовал смотреть код Trinity? Легкий ли там код, документирован ли он. Т.е. реально ли выглядит задача самому свою ноду модифицированную запустить?

код там оч качественный, но идею переделать под себя я забросил, потому что там пока что оч сильно меняется дизайн постоянно и сама нода не оч стабильна. но например там уже есть прямой доступ к базе, это прикольная фича.

сам клиент не оч быстрый, вряд ли можно его синхронизировать быстрее чем за пару недель.

Мне не скорость синхронизации важна, а trace_callMany. Т.е. чтобы я мог бы у эфирной ноды спросить: вот тебе список транз, выполни их у себя в памяти в несуществующем еще блоке, и скажи мне результат. Я с парили года 3 назад работал, и это была аццкая боль и печаль. И похоже ничего лучше с этим клиентом не стало 🙁

А как бы ты по времени оценил задачу на то, чтобы разобраться как работает эфирная нода, на примере Trinity?
Когда имеет только знание питона и понимание как работает эфириум на пользовательском уровне.

parity --mode active --tracing off --pruning fast --db-compaction hdd --cache-size 16000 --no-ancient-blocks
еще недавно вот так доезжало все оч быстро и занимало меньше 100гб места.

trace_callMany

Performs multiple call traces on top of the same block. i.e. transaction n will be executed on top of a pending block with all n-1 transactions applied (traced) first. Allows to trace dependent transactions.

круто наверное для фронтраннинга

Всем привет

Не в курсе можно ли транзу тезера на эфире протолкнуть если газ малый был выставлен?

Можно, а какой кошелек?