Насколько я понимаю, транзакции объединяются в блок, доказательство работы выполняется путем вычисления хеш-значения для блока, а затем добавляется в цепочку блоков. Когда блок добавляется в цепочку блоков, транзакция, включенная в блок, считается подтвержденной.
Как определяется полный узел, из которого запрашивается цепочка блоков? Или по скольким полным цепочкам узлов проверяется транзакция?
Предположим, что у злоумышленника есть разветвленная цепочка, и давайте ничего не будем предполагать об отклонении или подтверждении этого форка другими полными узлами, можно ли проверить мою транзакцию по этой разветвленной цепочке злоумышленника, а не по другим действительным цепочкам блоков, поддерживаемым честными полными узлами?
Допустим, мне удалось 6 подтверждений, но все эти блоки — форк злоумышленника. Это проблема?
Ваш сценарий не совсем ясен, потому что вы не сообщаете нам, создает ли злоумышленник действительные блоки или недействительные блоки. Вы также не определили, является ли ваш собственный кошелек полным узлом или тонким клиентом.
Давайте сначала поговорим о том, как блоки передаются по сети:
при обнаружении нового блока узел объявляет через inv(инвентарное) сообщение, что у него есть этот новый блок. Другие полные узлы отправят getdataсообщение, запрашивая весь блок. После получения и проверки данных они отправят invсообщение своим партнерам, чтобы объявить им о новом блоке.
Узлы SPV не запрашивают полный блок. Они просто получат заголовок блока, и если есть какие-либо интересующие транзакции, они специально запросят подтверждение для отправки через merkleblockсообщение. Узлы SPV не могут полностью проверить действительность новых блоков, потому что они не хранят блокчейн.
Теперь есть три различных возможных сценария и два типа кошельков для рассмотрения:
Злоумышленник создает недопустимые блоки
Кошелек SPV может быть обманут, поскольку он не может проверить достоверность блока. Они по-прежнему проверяют, правильно ли сформирован заголовок блока. Некоторые кошельки SPV требуют, чтобы несколько пиров сообщали им об одном и том же блоке. Поэтому для этой атаки может потребоваться дополнительная атака Sybil или контроль интернет-соединения кошелька SPV.
Полные узлы не затрагиваются, потому что они будут отклонять недопустимые блоки.
Злоумышленник создает действительные блоки на низкой скорости
. Кошелек SPV реорганизуется в более длинную цепочку, когда узнает об этом от другого партнера. Итак, опять же, чтобы это работало, кошелек SPV должен быть изолирован от другой информации. Поскольку информация верна, эта атака может работать и против полных узлов. Атакуемый может заметить подозрительно низкую скорость обновления.
Злоумышленник создает действительные блоки с мощностью майнинга 51%
. Злоумышленник работает быстрее, чем вся остальная сеть. Выбрав построение только на своих собственных блоках, он может добывать 100% блоков и при этом опережать оставшуюся сеть. Блоки действительны и поэтому принимаются всеми узлами (до какого-либо вмешательства). Злоумышленник может подвергать цензуре транзакции и даже откатывать небольшое количество блоков, начиная с более раннего блока, но в конечном итоге обгоняя естественную вершину цепочки блоков. Это называется атакой большинства и нарушает аксиоматическое предположение безопасности Биткойна о том, что более половины мощности майнинга являются честными.
Насколько безопасны шесть подтверждений в форке злоумышленника?
Если вы попали под атаку Сивиллы, это вас одурачит. В любом другом случае вас не одурачить, иначе целью будет вся сеть.
Как только вы отправляете транзакцию, вы транслируете ее в сеть. Все полные узлы получают это и проверяют транзакцию, поэтому полные узлы игнорируют ложные блоки при отправке майнерами и ждут правильного блока в будущем и предполагают, что более 50% майнеров честны, ложный блок будет потерян.
Однако клиенты SPV проверяют только самую длинную цепочку, и в этом случае они будут обмануты неправильным блоком.
Атака, которую вы описали, представляет собой атаку 51%, при которой злоумышленник имеет 50% и более всей вычислительной мощности и, следовательно, может создавать поддельные блоки друг над другом, что может привести к действительно разрушительной ситуации и, безусловно, проблема.
Действительный Trxid, потерянный в потерянном блоке, ставится в очередь в следующий доступный блок с отложенным подтверждением в системе.
Причина сохранения десятиминутных промежутков в каждом блоке состоит в том, чтобы уменьшить вероятность проведения 6 последовательных транзакций.
Цифровые транзакции с более высокой скоростью блокировки или меньшей мощностью хеширования имеют большую уязвимость к такому событию.
Яннес