Testnet tx снова появляется после 90 блоков

В какой-то момент, сообщает местный Гет узел ТХ 2e7a57c55a7cb28d0e233d7745210dba93c09f14c5df4e879db1a530a79a842a в блоке 1369316 в тестовой сети. Затем он исчез из цепи в какой-то момент в течение следующих 1-12 блоков.

Тот же самый tx появился после 90 блоков на блоке 1369406 и теперь является частью блочной цепи.

Как это может произойти, и какой крайний случай мы неправильно обрабатываем? Мы были в понимании, что ждать 12 блоков будет достаточно.

Это вызвано вилкой или повторной атакой? Если да, как это следует обрабатывать?

5 голосов | спросил randomguy 4 PM000000100000000431 2016, 22:29:04

1 ответ


4
  

В какой-то момент локальный узел Geth сообщил tx   2e7a57c55a7cb28d0e233d7745210dba93c09f14c5df4e879db1a530a79a842a в   блок 1369316 на тестовой сети. Затем он исчез из цепи при   некоторый момент в течение следующих 1-12 блоков.

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

  

Тот же самый tx появился после 90 блоков на блоке 1369406 и теперь является частью блок-цепи.

Невозможно выполнить транзакцию «(re)» в некотором смысле, что только одна транзакция может существовать в цепочке блоков с хешем транзакции, чтобы цепочка блоков была действительной.

Если он «исчез», возможно, один из следующих сценариев:

  • транзакция была «преднамеренно» изменена одним или несколькими узлами (посредством манипуляции с битами) и передана в сеть. Остальная часть сети помечена как недопустимая и, следовательно, не добавлена ​​в цепочку блоков (по цепочке блоков я имею в виду всю цепочку блоков, на которую соглашается сеть)
  • транзакция по-прежнему существовала в цепочках блоков цепочек узлов, которые были проверены и синхронизированы с узлами, которые ранее помечены как недействительные (к счастью, текущие реализации Ethereum штрафуют узлы, ретранслирующие недействительные транзакции (а не узел, совершивший транзакцию))
  • a было сделано 51% -ное нападение (хотя это маловероятно из-за стоимость и отсутствие денежной выгоды в тестовой сети), и злоумышленник вмешался в порядок транзакций.
  • Ethereum использует протокол GHOST , чтобы стимулировать добычу для цепочки блоков (чьи блоки называемые дядями основной, действительной цепочки), которые имеют недопустимые данные, но действительные заголовки до определенной высоты (плата за блокирование дядей для дрессировки уменьшается экспоненциально на один блок). Ваша транзакция, возможно, приземлилась в таком блоке и позже была повторно синхронизирована с основным блоком (поскольку он был действительным как для заголовка, так и для данных)
  

Мы были в понимании, что ждать 12 блоков будет достаточно.

Вы не можете использовать абсолютное значение (из 12) блоков. «Достаточное» количество подтверждений зависит от узлов добычи и их рекламных блоков. Можно с уверенностью сказать, что чем больше число подтверждений, тем лучше (большее количество узлов «согласовано» на цепочке блоков).

  

Это вызвано вилкой или повторной атакой? Если да, как это   обрабатываться?

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

Хорошо, следуя принципу блочной цепи, к которой кто-либо может присоединяться и вносить свой вклад в любую интеллектуальную мощь, он не может быть смягчен (существующими реализациями Ethereum). Решением будет использование разрешенных цепей блоков (т. Е. eris ), которые позволяют ACL для одноранговых узлов, присоединяющихся к сети.

ответил Sebi 16 PM00000010000003331 2016, 13:53:33

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132