Фильтры: что такое «последнее» и «ожидающее»?

Я хочу отслеживать учетные записи на предмет входящих транзакций (RPC/IPC API) и вызывать функцию всякий раз, когда какая-либо из нескольких отслеживаемых учетных записей получает эфир, который «подтвержден», например, «достаточно много блоков назад, чтобы шансы на двойную трату ничтожны».

Есть эталонная реализация этого?

Я просматриваю фильтры, и слова «ожидающие» и «последние» продолжают появляться. Что они имеют в виду?

Ответы (2)

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

С другой стороны, ожидается набор транзакций, которые могут быть выполнены сетью (о которых знает ваш собственный узел), но еще не были выполнены. Ожидание полезно для отображения реактивных пользовательских интерфейсов, когда пользовательский интерфейс может немедленно показать, что что-то входящее, хотя нет никаких гарантий, когда эти транзакции (если вообще когда-либо) будут успешно выполнены.

Что именно вы имеете в виду под "вашей собственной сетью"? Кроме того, «с точки зрения безопасности, конечно, могут быть реорганизации» - точно, так как мне измерить/смягчить это?
@spraff Ваш локальный узел поддерживает собственную копию блокчейна; «последний» означает, что он находится в головном блоке этой цепочки. Вы можете смягчить возможность реорганизации, подсчитав, сколько блоков от головы цепочки находится рассматриваемый TX, и не считая его полностью принятым, пока он не окажется на некоторое количество блоков ниже головы (обычно это отображается как «подтверждение»).
Ethereum — децентрализованная система, поэтому разные узлы могут видеть систему в различном состоянии: например, когда вы догоняете/синхронизируетесь, вы видите только более старое состояние, пока не догоните. Кроме того, блокчейны называются в конечном счете согласованными, что означает, что в конечном итоге все узлы соглашаются с состоянием, но текущее фактическое состояние между ними может быть разным. Ваша локальная цепочка — это то, что ваш собственный узел считает текущим состоянием. Что касается реорганизации, это зависит от средств, с которыми вы работаете: убедитесь, что глубокая реорганизация стоит больше, чем то, что можно с ее помощью получить.
Например, если вы обмениваете эфир на несколько долларов (например, кофе), то даже небольшая реорганизация стоит слишком дорого, чтобы она того стоила. Если вы обмениваете миллионы, то вам может потребоваться подождать несколько блоков, чтобы гарантировать, что кто-то не потратит столько денег дважды, поскольку вполне может стоить развернуть кластер графических процессоров, чтобы попытаться отменить этот перевод.
Так каков критерий, что-то вроде того, что $reorg < k*$amount*2^confirmationsя предполагаю? Если да, то есть ли у нас приблизительная оценка коэффициента?

Идеи по «эталонной реализации» см. в статье: Как DApp может обнаружить форк или реорганизацию цепочки с помощью web3.js или дополнительных библиотек?

Вы, вероятно, также хотите знать: какое количество подтверждений считается безопасным в Ethereum?


Ответ @Péter великолепен, и единственное, что нужно добавить, это web3.eth.defaultBlockопределение:

«последний», последний блок (текущий заголовок блокчейна)

«ожидание», текущий добытый блок (включая ожидающие транзакции)

pendingравно latestплюс ожидающие транзакции (те, которые не были добыты в блок).

Это плохое определение, которое необходимо обновить. Как упомянул Питер, «ожидание» включает в себя все известные транзакции в пуле памяти, а не только то, что может поместиться в добываемый в данный момент блок, тем более что большинство узлов не являются майнерами.
@GViz Это справедливый комментарий, и я думаю, что они будут открыты для PR для изменения: github.com/ChainSafe/web3.js/blob/1.x/docs/web3-eth.rst#L193