Скажем, мы хотим подтвердить, что транзакция стоимости txдостигла определенной завершенности, которую мы определяем как ожидание 12 подтверждений блока. Мы делаем это, чтобы снизить вероятность txпотери из-за форка или его включения в блок uncle.
Примеры, которые я видел, используют getBlockи/или getTransactionсначала, чтобы убедиться, что они txбыли добыты в блоке.
Затем они ждут, пока не будет добыто 12 новых блоков, и, кажется, используют getTransactionReceiptих для проверки того, находятся ли они txв блокчейне.
Есть ли какая-то функциональная разница в этом контексте между использованием и getTransactionпроверкой getTransactionReceiptналичия ? Реализации, похоже, не используют какие-либо дополнительные возвращаемые данные, что немного сбивает с толку.txblockNumbergetTransactionReceipt
Допустим, произошел форк или txон попал в потерянный блок до 12 подтверждений. Означает ли это, что getTransactionи getTransactionReceiptвернет null для транзакции или как это отражено в этих вызовах?
Нет, в данном случае нет никакой разницы — они по существу эквивалентны. Если tx потерян, они должны вернуть null, но вы все равно должны проверить номер блока, потому что он мог быть добавлен в новую цепочку позже, чем вы ожидаете, что снижает вероятность окончательности.
txчтобы заблудиться на развилке? Будут ли методы по-прежнему возвращаться nullили номер блока будет null? Не уверен, txчто осиротение покрывает случай с вилкой.txначальный номер блока может измениться между первым и последним вызовами (после 12 блоков)? И, кроме того, означает ли это, что рекомендуется ждать дополнительных блоков, чтобы покрыть разницу, чтобы достичь 12 подтверждений?(tx.blockNumber - eth.blockNumber) > 12у вас есть 12 подтверждений.
Виктор Мезрин