SM
Иначе блоки будут майниться быстрее, чем парсер их обработает
Size: a a a
2021 July 09
MD
а зачем многопоток если можно просто один поток который за новыми блоками следит и ищет там ивенты конкретных контрактов?
MD
100+ это не проблема
MD
но конечно всё от задачи зависит, если надо чото на коленке сделать - тогда парсинг наверное выход
SM
потому что ивенты в веб з обрабатываются по конкретному контракту
То есть, надо получателей в транзе сопоставить с массивом контрактов, и потом по каждому из них распарсить ивенты и вытащить кошельки
100+ контрактов будут обрабатываться дольше 10-15 секунд на стандартном серваке, это уже проверено эмпирически
То есть, надо получателей в транзе сопоставить с массивом контрактов, и потом по каждому из них распарсить ивенты и вытащить кошельки
100+ контрактов будут обрабатываться дольше 10-15 секунд на стандартном серваке, это уже проверено эмпирически
SM
То есть, если вопрос стоит в риалтайме, то количество контрактов ограничено
MD
надо не транзы а ивенты обрабатывать
MD
просто найти в блоке все ивенты определённых контрактов, и их обработать, это не занимает много времени в рантайме
MD
конечно если не говнокодить
SM
Ивенты из транз или ивенты по подписке? Потому что по подписке некоторые ивенты выпадают, рекомендуется запрашивать с 2-3 нод, чтобы точно все отловить
MD
ивенты из блока
SM
а какой функцией в web3 получаются ивенты ИЗ БЛОКА? Без запроса транз
MD
вот, можно указать fromBlock и toBlock одним и темже и передать массив адресов контрактов
MD
потом заэнкодить все логи
i
Это по твоему опыту? Выпадают
SM
по subscribe - да. На той же инфуре бывают пропуски
MD
только на инфуре вроде и бывают, на своей ноде я такого не встречал
MD
инфура вообще распиздяйски к данным относится
SM
видимо, из-за нагрузки, потому что в инфуру лезут все подряд, а на собственную ноду - только ты сам :)