Как контролировать большой набор адресов эфириума на предмет баланса?

Я планирую создать систему, в которой пользователи будут получать уведомления по электронной почте и в приложении, если будут какие-либо изменения в их балансе эфира. Я был в замешательстве, как отслеживать большой набор адресов ethereum в течение 24/7, чтобы проверить баланс и инициировать событие на основе этого. Предоставляет ли web3.js какую-либо функцию для мониторинга большого набора адресов ethereum?

Это старый ответ на аналогичный вопрос ethereum.stackexchange.com/a/27525 . Я бы предложил изучить использование debug_getModifiedAccountsByNumberвместе с блочным фильтром и, возможно, с внешней базой данных.

Ответы (3)

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

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

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

Я не думаю, что web3 дает вам такую ​​​​функциональность, вместо этого вы можете создать ее самостоятельно, используя getBalance .

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

Повторяйте это с течением времени после определенного тайм-аута, и у вас будет служба 27/7.

В этом ответе на аналогичный вопрос я написал пример кода, который отслеживает балансы набора адресов. Просто измените код перевода средств, чтобы вызвать триггер вашего события. Обратите внимание, что код зависит от удаленного провайдера web3, что может подойти для низких требований к производительности. Для высоких требований к производительности, возможно, стоит подумать о построении непосредственно поверх Geth или Parity.

На самом деле игнорируйте мой ответ, только что узнал, что я даю тот же ответ на тот же ОП :)