Пятница , 25 сентября 2020
Home / Майнинг / Сохранность отложенного подтверждения выполнения работы (dPoW) Komodo

Сохранность отложенного подтверждения выполнения работы (dPoW) Komodo

Раз в год происходит огромное количество атак 51% (атак двойного расходования) на разные блокчейны на базе подтверждения выполнения работы (PoW). Сейчас мы желаем поделиться с вами увлекательной статьей блокчейн-энтузиаста по имени Сатиндер Гревал из команды проекта Komodo, которая полностью и на сто процентов посвящена данной нам теме. А конкретно – возможному решению препядствия сохранности PoW, которое получило заглавие отложенного подтверждения выполнения работы dPoW.

Я помню, как в 2015-16 гг. jl777 (Джеймс Ли) работал над кодом SuperNET на языке C, разрабатывая реализацию децентрализованной биржи и сразу изучая внутреннее устройство архитектуры блокчейна Биткойна, без помощи других переписывая его код. Обучаясь и программируя, Джеймс обычно делился открытиями с обществом SuperNET, отмечая разные недочеты Биткойна и места, где код можно значительно усовершенствовать.

Истоки отложенного подтверждения выполнения работы (dPoW)

Тогда jl777 предсказывал, что недалёк тот час, когда блокчейны на базе подтверждения выполнения работы с низким уровнем вычислительной сохранности будут подвергаться атакам, потому что их рыночная стоимость будет расти. 1 июня 2014 г. общая рыночная капитализация всех криптовалют составляла около $8 миллиардов, а стоимость почти всех ведущих криптовалют на тот момент составляла всего несколько центов либо даже меньше цента. Cейчас общая рыночная капитализация всех криптовалют превосходит $254 миллиардов, и почти все криптовалюты стоят 10-ки, сотки, а в случае Биткойна – тыщи баксов за единицу.

Тогда как почти все остальные криптовалютные форумы и общества в соц сетях не присваивали огромного значения трудам jl777, форум bitco.in, где Джеймс некое время делился своими ранешними исследовательскими работами, оказался довольно мудрейшим, чтоб сделать отдельный раздел, посвящённый его проекту Iguana. Одна из тем Джеймса на этом форуме именуется «Внедрение BTC как сервера временных меток, делающего вероятным атомарный своп меж блокчейнами и увеличение сохранности альтчейнов». В ней он разъяснял свою идею о том, как при помощи Биткойна можно сделать лучше сохранность остальных, других блокчейнов, не имеющих таковой большенный вычислительной мощности, независимо от того, какой способ сохранности употребляют эти блокчейны на консенсусном уровне собственного базисного протокола.

Решение по использованию Биткойна как сервера временных меток для других блокчейнов в предстоящем было реализовано в виде «отложенного подтверждения выполнения работы» (delayed Proof of Work, dPoW) – первого, что было запрограммировано в Komodo, когда этот криптовалютный проект в конце 2016 г. откололся от Zcash.

Внутреннее устройство dPoW

Нет необходимости разбирать тут, что такое хеширование, пиринговая сеть, подтверждение выполнения работы, vin и vout в транзакциях Биткойна и т. д., так как в сети доступно довольно ресурсов (таковых как вайтпейпер Биткойна), которые помогают осознать, почему сторонники криптовалют считают SHA-256 самым надёжным PoW-алгоритмом. Если желаете углубиться в наиболее содержательную и ординарную для осознания книжку, то наилучший ресурс – «Осваиваем Биткойн» Андреаса Антонопулоса.

Итак, если вы читали о подтверждении выполнения работы (PoW), то, думаю, вы более-менее сообразили, как трудно выполнить двойное расходование в Биткойне из-за его большой вычислительной мощности (на данный момент около 100 млн Терахеш/с). Провести атаку 51% на Биткойн, чтоб расходовать одну и ту же транзакцию два раза, практически нереально. Тем не наименее, пожалуй, стоит незначительно тормознуть на процессе двойного расходования, чтоб предоставить какой-никакой контекст для dPoW.

Хешрейт (либо общая вычислительная мощность сети) Биткойна по состоянию на 21 мая 2020 года. : blockchain.com

В числе правил консенсусного механизма подтверждения выполнения работы:

  • Сеть будет следовать самому длинноватому блокчейну.
  • Если двое либо больше майнеров отыщут блок сразу, в качестве фаворита все узлы сети будут разглядывать тот блок, который больше всего синхронизирован с сетью.
  • Лаконичный обзор атаки двойного расходования

    Если злодей желает расходовать транзакцию два раза, ему пригодится:

  • Компьютерный узел с полным блокчейном, чтоб сделать транзакцию и передавать её пиринговой сети.
  • 2-ой компьютерный узел с полным блокчейном, НЕ подключённый к остальной пиринговой сети и в личном порядке выполняющий майнинг с блока, предыдущего тому, при котором злодей посылает транзакцию с первого узла.
  • 66,666% вычислительной мощности, хотя 51% статистически довольно, чтоб в итоге получить самый длиннющий блокчейн. Чем больше процент вычислительной мощности у злодея, тем резвее он сумеет выстроить личный блокчейн. Имея больше вычислительной мощности, злодей сумеет отыскивать блоки резвее, чем другие майнеры сети вкупе взятые. (Ожидаемое время нахождения блока в Биткойне – 10 минут, тогда как в Komodo – 1 минутка).
  • Когда злодей лицезреет, что число отысканных им блоков больше, чем у остальной сети, он может опять сделать ту же транзакцию, что на первом шаге, с остальным адресом получателя.
  • Опосля этого злодей может подключить собственный узел к остальной пиринговой сети и передавать свою транзакцию.
  • Шаг 5 значит, что хоть какое число N блоков, намайненных меж первой и 2-ой отправленными транзакциями, будут рассматриваться как недействительные, когда злодей найдёт больше блоков, чем другие майнеры сети. Ожидаемый итог:

  • Транзакция, отправленная на шаге 1, не врубается в блок, намайненный узлом злодея. Так как блок злодея подменяет старенькый блок, содержащий транзакцию, её всё равно что никогда не было (даже если средства были высланы на адресок получателя).
  • Так как злодей намайнил самую длинноватую цепочку блоков и потом также расходовал свои средства в наиболее поздних блоках на иной адресок получателя, вступает в силу правило самого длинноватого блокчейна и остальная пиринговая сеть признаёт недействительными старенькые блоки, отправленные иными майнерами, и переключается на блокчейн злодея.
  • Так в общих чертах смотрится гипотетичная атака 51%.

    Препятствия для проведения атаки 51%:

  • Приобретение либо аренда оборудования, нужного для заслуги большей вычислительной мощности, чем у всей остальной сети.
  • Сложность майнинга в мотивированном блокчейне на момент атаки.
  • Неопределённость из-за роста сетевой вычислительной мощности вследствие присоединения остальных майнеров, которые могут передавать свои отысканные блоки остальной сети ранее злодея.
  • Вышеперечисленные условия практически нереально выполнить в случае Биткойна, так как его сеть защищена большей вычислительной мощностью, чем хоть какой иной блокчейн. Но это полностью может быть в остальных блокчейнах с подтверждением выполнения работы, потому что на данный момент много производителей микросхем выпускают новейшие ASIC-майнеры для разных PoW-алгоритмов и почти все обладатели такового оборудования сдают в аренду вычислительную мощность на специализированных сервисах, вроде NiceHash, который потом был взломан взломщиками и был обязан остановить деятельность.

    Так как атаки 51% могут быть весьма выгодными опосля двойного расходования одной и той же транзакции, логично, что некие злоумышленники пользуются таковой ситуацией. https://www.crypto51.app/ – неплохой веб-сайт с подсчётами о том, во сколько может обойтись атака на разные криптовалютные проекты и какой процент вычислительной мощности доступен для аренды, чтоб провести атаку 51% на ту либо иную криптовалюту.

    Таблица из 10 криптовалют в порядке убывания цены проведения атаки 51%. : crypto51.app

    Из вышеизложенного ясно, почему PoW – наилучший способ сохранности для таковых проектов, как Биткойн и Эфириум, так как у их наибольшая вычислительная мощность. Количество вычислительной мощности, нужное для атаки 51% на Биткойн либо Эфириум, не доступно для аренды ни на одном веб-сайте. Но отсюда также видно, что малые криптовалютные проекты, использующие такие же твёрдые правила PoW, могут быть весьма уязвимы к атакам 51%.

    Способ сохранности dPoW в Komodo: герой для малых криптовалютных проектов

    Криптовалютные создатели и новаторы сделали огромное количество консенсусных устройств, которые употребляют или совсем иной метод, чем в Биткойне, или сочетание различных способов консенсуса, таковых как подтверждение выполнения работы (PoW) и подтверждение толики владения (PoS). На веб-сайте What To Mine можно узреть, какие криптовалюты более прибыльно майнить при помощи того либо другого метода зависимо от нужных вложений в электричество.

    Поясним ординарными словами, что может и НЕ может созодать отложенное подтверждение выполнения работы (dPoW).

    Способ сохранности dPoW НЕ может:

    Участвовать в майнинге либо генерировании блоков блокчейнов, которые он защищает.

    Способ сохранности dPoW может:

    Быть добавленным как вторичный уровень консенсуса к существующему консенсусному механизму хоть какого блокчейна на базе UTXO. К примеру, dPoW можно добавить как вторичный консенсус в блокчейны, использующие PoW либо PoS.

    Чтоб способ сохранности dPoW работал, будет нужно:

  • Биткойн для сотворения особых транзакций с мультиподписью и отправки их в сеть ведущей криптовалюты, как это делает хоть какой BTC-кошелёк.
  • Крайний блокхеш блокчейна, сохранность которого обязана обеспечиваться.
  • 64 особых узла, способных сделать свою пиринговую dPoW-сеть и обмениваться вместе крайними блоками и консенсусной информацией, относящейся к блокчейнам, чью сохранность они обеспечивают. Узлы данной нам пиринговой dPoW-сети именуются нотариальными узлами.
  • Нативный бес Биткойна и всех остальных блокчейнов, чью сохранность обеспечивают нотариальные узлы. Таковым образом, опосля воплощения первой реализации dPoW в Komodo нотариальным узлам необходимы были полные блокчейны Биткойна и Komodo. Это непременное правило, но лишь для нотариальных узлов (не для майнеров либо обыденных узлов).
  • Клиентским узлам блокчейна, чью сохранность обеспечивают нотариальные узлы при помощи dPoW, не необходимы никакие остальные блокчейны. К примеру, если Komodo защищается при помощи dPoW средством нотаризации крайнего блокхеша по Биткойну, юзерам Komodo НЕ необходимо также употреблять Биткойн. То же касается форков Komodo, узнаваемых как ассетчейны. Обыденным узлам ассетчейнов не непременно запускать Komodo вприбавок к бесу их ассетчейна. Аналогично и для остальных блокчейнов, защищённых при помощи dPoW.
  • 64 общественных ключа всякого нотариального узла, участвующего в консенсусе dPoW. (Направьте внимание, что при помощи 1-го общественного ключа можно генерировать огромное количество адресов для различных блокчейнов).
  • Так как 64 нотариальных узла обязаны иметь полные блокчейны Биткойна, Komodo и всех остальных сетей, защищённых при помощи dPoW, непременно наличие качественного сервера с неплохим микропроцессором, минимум 64 ГБ RAM, подключением к вебу со скоростью 100 Мбит/с и довольно резвым SSD-диском для хранения всех блокчейнов (приблизительно 1 ТБ будет довольно).
  • 64 высококвалифицированных оператора нотариальных узлов с опытом работы в ОС Linux и продвинутыми способностями системного администрирования и сетевой сохранности применяемых машин.
  • Огромное общество юзеров блокчейна с неплохим распределением предложения монет. Это необходимо, чтоб на базе владения монетами они могли голосовать за операторов нотариальных узлов. Официальными операторами нотариальных узлов избираются те, кто наберёт больше всего голосов.
  • Выборы нотариальных узлов в Komodo происходят раз в год.

    • Опосля сотворения dPoW 4 нотариальных узла было зарезервировано за разрабами Komodo.
    • Другие 60 нотариальных узлов были избраны путём голосования держателей KMD.
    • Любой последующий год 30 наилучших нотариальных узлов, которые провели больше всего нотаризаций (Komodo по Биткойну либо ассетчейнов по Komodo), автоматом переизбираются. Это мотивирует операторов нотариальных узлов отлично делать свою работу, поощряет старательных операторов и обеспечивает плавный переход от одной группы нотариальных узлов к иной.
    • Другие 30 вакансий операторов нотариальных узлов открыты для общества.
    • Серверы нотариальных узлов должны быть распределены по всем материкам. Потому можно узреть, что имеющиеся нотариальные узлы разбиты на последующие группы: Южное полушарие (То есть, вообще говоря, половина шара. Часто правая или левая половина большого мозга) (SH), Азия-Наша родина (AR), Северная Америка (NA), Европа (EU).

    Перечень узлов Komodo. : веб-сайт komodostats.com

    Что необходимо, чтоб общество избрало тебя оператором нотариального узла:

  • Оператор поначалу должен поработать в испытательной сети (тестнете) нотариальных узлов, функционирующей независимо, на настоящем оборудовании и со своим блокчейном. Чтоб начать делать нотаризацию в тестнете, требуются маленькие стартовые вложения.
  • Кандидатам на нотариальные узлы НЕ необходимо держать KMD либо какую-либо другую криптовалюту. Хоть какой, кто владеет достаточной квалификацией, чтоб работать с узлами нескольких блокчейнов и сервером со сверхсильной сохранностью, может участвовать в выборах нотариальных узлов.
  • Глубочайшее познание внутреннего устройства блокчейнов не требуется, но кандидаты должны владеть базисными заниями в обслуживании узлов блокчейнов, которые посодействуют совладать с их технической поддержкой.
  • В целом, стать оператором нотариального узла не очень просто, да и не очень трудно. Чтоб быть достойным кандидатом на оператора нотариального узла, которого изберет общество Komodo, необходимо время, способности и денежные вложения.

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

    Промежные итоги

    Давайте подытожим некие факты, рассмотренные в статье ранее момента:

  • Нотариальные узлы выбираются обществом. Весьма трудно (и самоубийственно) пробовать действовать эгоистично опосля того, как тебя выбрали оператором нотариального узла.
  • dPoW не майнит/генерирует блоки, потому нотариальные узлы не могут проводить атаку 51%.
  • Так как для того, чтоб стать оператором нотариального узла, не требуется держать какую-либо криптовалюту (BTC, KMD и т. д.), нотариальные узлы совсем отличны от концепции мастернод. Нотариальные узлы – это НЕ мастерноды. Меж ними нет ничего общего.
  • Возможности операторов нотариальных узлов

    Согласно строительному устройству dPoW, нотариальные узлы фактически не имеют никакой власти над блокчейнами, защищёнными при помощи dPoW, и не могут подорвать их работу.

    Возможности, связанные с dPoW:

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

    Возможности, связанные с майнингом либо генерацией блоков

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

  • Нотариальные узлы НЕ могут производить «упрощённый» майнинг в ассетчейнах либо всех остальных блокчейнах, загруженных на их сервер. Если они желают майнить в этих блокчейнах, то они могут созодать это так же, как все остальные майнеры в сетях этих блокчейнов, используя CPU, GPU, ASIC либо арендуемую вычислительную мощность.
  • Операторы вкладывают время, средства, людские ресурсы/способности, инфраструктуру, аппаратные и программные ресурсы, чтоб управлять нотариальными узлами. Потому ЕДИНСТВЕННАЯ преимущество операторов нотариальных узлов – это повторяющийся «упрощённый» майнинг блоков в блокчейне Komodo (KMD). Начальный код блокчейна Komodo включает 64 общественных ключа, принадлежащих нотариальным узлам. При каждых выборах нотариальных узлов эти 64 общественных ключа в коде обновляются. Адреса, связанные с этими общественными ключами, получают возможность «упрощённого» майнинга KMD.
  • Исходя из этих возможностей, связанных с майнингом, все 64 нотариальных узла вкупе могут раз в день майнить приблизительно 75% всех блоков. Другие 25% майнятся иными майнерами сети блокчейна Komodo. Но встречаются периоды, когда данное соотношение составляет, к примеру, 65:35, так что это не серьезное правило.

    Давайте также посчитаем, сколько может заработать один нотариальный узел с этих 75% вознаграждений за майнинг.

    • Время блока KMD: 60 секунд.
    • Вознаграждение за блок KMD: 3 KMD.
    • Блоков и KMD в день: 60 секунд = 1 минутка; 1 час = 60 минут; 24 часа = 24 x 60 = 1440 минут = 1440 блоков и 1440 x 3 = 4320 KMD.
    • Блоков и KMD за месяц: деньки в году/месяцы = 365,25/12 = 30,4375 денька в среднем в месяце; 30,4375 x 1440 = 43 830 минут = 43 830 блоков и 43 830 x 3 = 131 490 KMD.
    • 75% блоков и KMD в день: 1440 x 0,75 = 1080 блоков и 1080 x 3 = 3240 KMD.
    • 75% блоков и KMD в день на один нотариальный узел: 1080/64 = 16,875 блока и 16,875 x 3 = 50,625 KMD.
    • 75% блоков и KMD за месяц: 43 830 x 0,75 = 32 872,5 блока и 32 872,5 x 3 = 98 617,5 KMD.
    • 75% блоков и KMD за месяц на один нотариальный узел: 32 872,5/64 = 513,6328125 блока и 513,6328125 x 3 = 1540,8984375 KMD.
    • Примерная стоимость одной монеты KMD в мае 2020 г.: $0,5.
    • Стоимость монеты KMD 24 декабря 2017 г. (исторический максимум): $10,49.

    Исходя из примерной цены KMD за крайнее время, один нотариальный узел может заработать:

    • В денек: 50,625 x 0,5 = $25,3125.
    • За месяц: 1540,8984375 x 0,5 = ~$770,45.
    • В год: 770,45 x 12 = $9245,4.

    Исходя из наибольшей исторической цены KMD, один нотариальный узел мог бы заработать:

    • В денек: 50,625 x 10,49 = $531,056250.
    • За месяц: 1540,8984375 x 10,49 = $16 164,024609.
    • В год: 16 164,024609 x 12 = ~$193 968,296.

    Таковы вероятные сценарии для нотариального узла при текущей и наибольшей исторической стоимости. Естественно, это не совершенно четкие расчёты, потому что стоимость KMD, как и хоть какой иной валюты либо актива в глобальной экономике, не быть может статичной. Потому, пожалуй, хорошо будет провести расчёты, используя среднее значение. При всем этом представим, что оператор нотариального узла не растрачивает свои KMD на оплату каких-то издержек по обслуживанию сервера. Возьмём условную среднюю стоимость KMD $2,50, просто взглянув на график, не пытаясь подсчитать четкое значение.

    График цены Komodo за всю историю. : Coinmarketcap

    Итак, исходя из грубой средней цены KMD $2,50, вот сколько может заработать один нотариальный узел:

    • В денек: 50,625 x 2,50 = $126,5625.
    • За месяц: 1540,8984375 x 2,50 = $3 852,246094.
    • В год: 3 852,246094 x 12 = ~$46 226,953.

    Естественно, есть также возможность, что стоимость KMD вырастет. Но предсказать будущее нереально. Давайте просто выберем оптимистичную стоимость, сохраняя определённую долю консерватизма, как, наверняка, делают все криптовалютные инвесторы, и представим, сколько KMD может стоить через год. Потому что это просто условная стоимость, не имеющая никакого настоящего смысла, выберем забавы ради значение выше исторического максимума, скажем, $18,78.

    Наибольшая стоимость Komodo за всю историю. : Coinmarketcap

    Исходя из таковой чисто гипотетичной будущей цены, ах так мог бы смотреться доход 1-го оператора нотариального узла:

    • В денек: 50,625 x 18,78 = $950,7375.
    • За месяц: 1540,8984375 x 18,78 = $28 938,072656.
    • В год: 28 938,072656 x 12 = ~$347 256,872.

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

  • Рассмотрение этих цифр имеет смысл, если представить, что некий нотариальный узел может провести самоубийственную атаку на сеть KMD (либо иной блокчейн, защищённый при помощи dPoW). Данные числа также животрепещущи, если кто-то допускает массовую самоубийственную атаку, когда несколько либо все 64 оператора нотариальных узлов вступят в сговор.
  • Если нотариальный узел проработает целый год и войдёт в число наилучших 30, то он будет автоматом переизбран, что создаёт весьма сильную мотивацию, чтоб не становиться самоубийцей и делать свои обязанности как положено.
  • Таблица с примерным подсчетом доходности всякого узла Komodo. : Medium

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

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

    Мониторинг dPoW

    На нотариальных узлах запущены бесы (полные узлы) всех блокчейнов, которые они нотаризуют, – на данный момент их больше 40. Как следствие, к сети всякого блокчейна, защищённого при помощи dPoW, добавляется 64 новейших узла, что наращивает децентрализацию и сохранность.

    Данные о нотаризации, проводимой каждым нотариальным узлом, отслеживаются и регистрируются, что дозволяет хоть какому узреть работу, выполняемую ими для блокчейнов, защищённых при помощи dPoW. Вот два веб-сайта, сделанных участниками общества Komodo, где можно узреть статистику активности нотариальных узлов:

    • https://dexstats.info/
    • https://komodostats.com/

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

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

    Почему нотариальным узлам нерентабельно действовать против dPoW

  • Операторы растрачивают много времени и средств на настройку и пуск нотариального узла. Все эти вложения окажутся в зоне риска, если оператор попробует пойти против протокола. Попытка вредных действий практически наверное не принесёт столько, сколько оператор получит за честную работу.
  • К тому времени, как оператор приобретёт репутацию 1-го из наилучших и самых надёжных нотариальных узлов, мотивация для вредных действий понижается ещё больше, потому что он отрешается от дохода не только лишь в текущем, да и в последующем году.
  • Если нотариальный узел пойдёт против dPoW, он на сто процентов лишится способности переизбраться в последующем году.
  • Отлично работающие нотариальные узлы обращают на себя внимание, потому что операторы остальных узлов повсевременно мониторят процесс dPoW и его эффективность. В случае подозрительной активности крайние получат извещения и предупредят всю сеть.
  • Процесс нотаризации блокчейна Komodo по Биткойну

    На данном шаге предполагается, что вы:

    • осознаете базы подтверждения выполнения работы;
    • осознаете сущность атаки 51% и то, как может произойти двойное расходование;
    • понимаете требования для dPoW и операторов нотариальных узлов.

    Независящая пиринговая сеть 64 нотариальных узлов

    Давайте перенесёмся вспять к моменту сотворения первой dPoW-сети. В аккаунте jl777 на GitHub есть репозиторий SuperNET. В нём содержится начальный бес Iguana, отвечающий за создание пиринговой сети нотариальных узлов для реализации dPoW. Все 64 нотариальных узла компилируют и запускают этот бес Iguana на собственных машинках вкупе с полными узлами блокчейнов Биткойна и Komodo.

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

    Помните, что это не пиринговая сеть какой-нибудь криптовалюты либо блокчейна. Она предназначена только для обмена данными, связанными с dPoW-процессами, меж нотариальными узлами.

    Один общественный ключ для всех блокчейнов

    Как разъяснялось при обзоре требований для dPoW, любой нотариальный узел предоставляет общественный ключ для адреса Биткойна либо Komodo. Iguana содержит библиотеку кода, позволяющую высчитать адреса для всех других блокчейнов, связанные с этим же общественным ключом.

    К примеру, если нотариальный узел предоставит общественный ключ в формате адреса Komodo, то можно вычислить адресок остальных блокчейнов, включая Биткойн, Litecoin, GameCredits, EMC2, Hush, Ethereum, все ассетчейны Komodo и т. д. Правда, ассетчейны Komodo имеют этот же формат адреса, что и Komodo. Приватные ключи для всех этих разных блокчейнов генерирует Iguana, предоставляя операторам нотариальных узлов средством API перечень адресов, приватных и общественных ключей для различных монет, используя единственную фразу-пароль.

    Преимущество 1-го общественного ключа для различных блокчейнов в том, что если ещё некий блокчейн захотит добавить консенсусный уровень dPoW поверх собственного имеющегося консенсуса, ему довольно добавить этот же перечень общественных ключей нотариальных узлов, который употребляют Komodo и остальные блокчейны. Этот перечень не надо поменять от блокчейна к блокчейну.

    Это дозволяет остальным блокчейнам меньше полагаться на разрабов Komodo и нотариальные узлы. Если создатели какого-то блокчейна, не сделанного в экосистеме Komodo, соображают, как ввести dPoW в собственный проект, то им для этого не необходимы никакие разрешения. Опосля внедрения они могут попросить команду Komodo добавить их проект на серверы нотариальных узлов.

    Такие третьи стороны могут также настроить свою сеть нотариальных узлов, которая нотаризовала бы их блокчейн по Komodo. (В экосистеме платформы Komodo уже есть проект, делающий это, – KMDLabs). Но, естественно, они могут сберечь время, усилия и средства, просто добавив собственный блокчейн в уже существующую сеть нотариальных узлов Komodo.

    До подключения к пиринговой сети нотариальных узлов необходимо выполнить при помощи API Iguana последующие задачки, прописанные в коде:

    • Запустить бесы Биткойна, Komodo, ассетчейнов и всех третьих сторон.
    • Убедиться, что оны синхронизированы с имеющейся сетью и соответствуют крайней версии блокчейна.
    • При наличии установить все обновления беса Iguana, скомпилировать его, запустить и ввести команду для его подключения к RPC API всех криптовалютных бесов, установленных на локальной машине/сервере. Данный шаг устанавливает общение Iguana со всеми демонами, запущенными на локальной машине.
    • Залогиниться в Iguana при помощи фразы-пароля собственного нотариального узла.

    На данном шаге Iguana начинает контактировать со всеми локальными криптовалютными демонами и получать информацию вида:

    • Высота крайнего блока + блокхеш, как показано на примере ниже:
    [BTC].1131235 KMD 0b449e03e777d8fce1ab31d3fec6749804da85fd61f0044940b071bbf22d2071 height.1131236 vs last.1131236

    И не только лишь для блокчейна Komodo, но также для всех блокчейнов, защищённых при помощи dPoW, – всех ассетчейнов Komodo, также блокчейнов всех третьих сторон, – что смотрится последующим образом:

    [BTC].1131255 KMD 01f926f16b380f5b7353bbe388eda604fcb74dedaabf84e18d0608db85e24e86 height.1131256 vs last.1131256
    [KMD].252711 HODL 0008cb2e4e793ce931d7de29f10f3a546b7a31dbbe21881db4042accd05b7c14 height.252712 vs last.252712
    [KMD].2653660 CHIPS 0000000000001d41eba16c82811c53aa2bdbcaea946cb5b003064f65408fcddc height.2653661 vs last.2653661
    [KMD].111594 SEC 0a97703662777e5e37161d784bab3f83098f8871d8e3b77d743b759805808d9c height.111595 vs last.111595
    [KMD].2175145 EMC2 d670d53b9f2e32b046c5a9ef58344a841cec072e434c105e5b0970f4002e8b91 height.2175146 vs last.2175146
    [KMD].235138 BET 004ef2c08c86401909057dd40d9382c4a43ab806a26b7df5f84d127408ac2063 height.235139 vs last.235139
    [KMD].2653661 CHIPS 00000000000028e030686426e7e45bde2ed148d3a9b346fa0933075cce5ffc34 height.2653662 vs last.2653662
    [KMD].143684 PIRATE 0000000187b1be1bc3495473bff0f380fcd03305b2461135009ac274017e8ded height.143685 vs last.143685
    [KMD].446836 REVS 00fd735d00a241d9ce4d4fcfc51cf936a094a06f7ffc38d26f43715f83db1254 height.446837 vs last.446837
    [KMD].281221 VRSC af107c608daa3f9026cf0c239e611cdbf621fedcfa2fce376c3ef63c48da13cc height.281223 vs last.281222
    [KMD].281223 VRSC d0c7a3b5c1d9b1049fdfaf3a19d51c91955c3ceab191f4a952c60c025c2f6afa height.281224 vs last.281224
    [KMD].241375 RFOX 0025dfb07997890ca4bd7139a8cbe62470c494fa89086f116e63f983ef715123 height.241376 vs last.241376
    [KMD].130041 MGNX 09f93b3811cca54bb40a8f17357c4dcf8ba377dbe05d25e7cf69a672f0a2610a height.130042 vs last.130042
    [KMD].446837 REVS 00c360d6d52a2ce589d8854f168e97905908b2fa73f1dc752917dc8942e907f5 height.446838 vs last.446838
    [KMD].424349 BOTS 0001d471064478f971a99628c42411bc83b10eef1c5e0e501d09564b6d608a7a height.424350 vs last.424350
    [KMD].2232448 GAME 4e9ec27e13ea81512192d27d32d9e8e0b5dd324b447bd6aa63ef0f4d4ff9b2f7 height.2232449 vs last.2232449
    [KMD].130042 MGNX 0cc47b5be512c215b7c1a285f36dd1b5cc5588f8f689aa3a9a4888972f4a261d height.130043 vs last.130043
    [KMD].75749 DION 0a71c7b911dd59438e479547e6e96749c7b36387a1a5168c9a4fdff755e45291 height.75750 vs last.75750
    [KMD].235139 BET 00963ea39fb4f3a69af43d68115b6592db9886fe94ed89c2454632d9c6c9a51b height.235140 vs last.235140
    [KMD].181311 EQL 02664b3fd8c6719a4e397cdac412342c90a159df7718ab235ea1290ec38bfdca height.181312 vs last.181312
    [KMD].213609 MGW 00007b8416f876deecab3116b99636b9faad0ed78d3d19738f9001cc94ac2036 height.213610 vs last.213610
    [KMD].36763 ZEX 0000003428a03a46cc9f5ca0b5a896c91575194810e874ecf094993b4895c69d height.36764 vs last.36764

    • Скоро опосля этого Iguana устанавливает соединение с остальными из 64 нотариальных узлов сети.
    • Потом для всякого блокчейна производится команда dpow, запускающая процесс нотаризации этого блокчейна. Команда включает тикер криптовалюты, таковой как CHIPS, и общественный ключ (pubkey) данного нотариального узла, что смотрится так:

    #command
    curl —url http://127.0.0.1:7776 —data ‘{«agent»:»iguana»,»method»:»dpow»,»symbol»:»CHIPS»,»pubkey»:»02957fd48ae6cb361b8a28cdb1b8ccf5067ff68eb1f90cba7df5f7934ed8eb4b2c»}’#output
    02957fd48ae6cb361b8a28cdb1b8ccf5067ff68eb1f90cba7df5f7934ed8eb4b2c DPOW with pubkey.(02957fd48ae6cb361b8a28cdb1b8ccf5067ff68eb1f90cba7df5f7934ed8eb4b2c) RV8Khq8SbYQALx9eMQ8meseWpFiZS8seL1.valid1 CHIPS -> KMD RV8Khq8SbYQALx9eMQ8meseWpFiZS8seL1.valid1, num.30 freq.100 minsigs.13 CCid.0

    Команда dpow инспектирует реальность общественного ключа, применяемого для пуска процесса нотаризации, сопоставляя его со перечнем 64 общественных ключей, данных в демоне komodod, также в бесах всех остальных блокчейнов. Она также инспектирует реальность адреса, связанного с сиим общественным ключом, при помощи значения ismine:true в локальном демоне.

    1-ый базисный консенсус нотариальных узлов

    Когда все криптовалютные бесы запущены и на сто процентов синхронизированы, бес Iguana запускает ряд параллельных операций, в том числе:

    • Проверку крайней высоты блока + блокхеша всякого подключённого криптовалютного беса;
    • Проверку, какой крайний блокхеш был нотаризован для всякого блокчейна;
    • Проверку, имеют ли адреса бесов Биткойна, Komodo, ассетчейнов и остальных криптовалют, применяемые локальным нотариальным узлом, довольно UTXO для нотаризации.

    1-ое условие для реальной нотаризации всякого блокчейна основано на его своем консенсусном коде (т. е. PoW/PoS). Код блокчейна инспектирует это условие буквально так же, как он защищает транзакции от двойного расходования. Если в крайнем блоке с реальным блокхешем имеется нотариальная транзакция с действительными данными OP_RETURN, то её доказательство не зависит от нотариальных узлов, а делается пиринговой сетью соответственного блокчейна.

    Проверив последнюю известную высоту нотаризации и последнюю известную высоту блока + блокхеш, Iguana посылает собранные данные остальным нотариальным узлам сети. Любой узел получает подобные данные от всех остальных подключённых нотариальных узлов.

    Может случиться, что некие нотариальные узлы получают крайние блоки резвее, чем остальные, как нередко бывает в пиринговых сетях блокчейнов. Бес Iguana повторяет процесс отправки/получения данных меж нотариальными узлами, пока достаточное количество узлов не ответит той же информацией о высоте блока + блокхеше.

    Выбор 13 подписантов при помощи битовой маски

    При каждой нотаризации узлы пронумерованы от 0 до 63. Тот, кому присвоен 0, изменяется с каждой нотаризацией, чтоб отдать любому узлу равные шансы на роль в нотаризации. Сейчас все 64 нотариальных узла передают друг дружке свои нотариальные данные вкупе с информацией, приобретенной от остальных узлов. Исходя из этого все 64 нотариальных узла дают 13 подписантов, насчёт которых необходимо придти к согласию. Поначалу не достаточно кто из узлов соглашается со всеми деталями, но потом все узлы сходятся на предложении, получившем самую большую поддержку.

    Математически существует МНОГО вероятных композиций 13 подписантов из 64. Применяется определённый метод, сокращающий число вариантов в любом раунде нотаризации, но всё равно их тыщи. Для обозначения избранных 13 подписантов употребляется маска в виде 64-битного числа. Она обязана начинаться с узла, которому в данном раунде присвоен номер 0, обязана содержать 13 наборов битов, и любой узел в маске обязан иметь схожие данные.

    Каково же вероятное число композиций 13 узлов из 64? И кто будет этими 13 избранными узлами? Чтоб посчитать, можно употреблять комбинаторику:

    C(n,r) = n! / (r!(n−r)!) = ?
    C(n,r) = C(64,13)
    = 64! / (13!(64−13)!)
    = 1.313685881E+13
    = 13136858812224

    Итак, согласно этому расчёту, может быть 13, 136, 858, 812, 224 разных набора из 13 подписантов, которых могут избрать 64 узла. Другими словами больше 13 триллионов!

    Таковым образом, такую битовую маску можно сделать только опосля нескольких циклов обмена данными меж всеми узлами. Любой узел передает всем остальным узлам предлагаемую тринадцатку, также то, что ему выслали остальные узлы. Как следует, все узлы лицезреют то, что они конкретно получают, также то, что лицезреют остальные узлы. Так определяется, какой набор из 13 узлов более популярен. Потом любой узел меняет собственный набор, если он уже не употребляет самую пользующуюся популярностью маску. Критически принципиально, чтоб все 13 подписантов были согласны с маской, потому что по другому нотаризация не состоится, поэтому что они её не подпишут. Это кое-чем припоминает майнинг: выбор рандомизирован и трудно предсказать, какие 13 узлов «одолеют». Если некий узел не согласен с победившей маской, то он просто игнорируется. С возрастом метод улучшился, чтоб выбирать 13 таковых узлов, которые согласны с маской.

    Читайте также:  Биткойн – не пирамида

    Общественные ключи нотариальных узлов и их шансы на роль в нотаризации

    Общественные ключи текущих нотариальных узлов можно поглядеть в файле komodo_notary.h. В этом массиве из 64 общественных ключей нотариальных узлов и присвоенных им имён любой набор начинается с кода, обозначающего число от 0 до 63.

    Общественный ключ нотариального узла в позиции 0:

    {«0dev1_jl777», «03b7621b44118017a16043f19b30cc8a4cfe068ac4e42417bae16ba460c80f3828» },

    А в позиции 63:

    {«xrobesx_NA», «03f0cc6d142d14a40937f12dbd99dbd9021328f45759e26f1877f2a838876709e1» }

    Если мне нужен, к примеру, нотариальный узел 42, то вот он:

    {«meshbits_SH», «025c6e94877515dfd7b05682b9cc2fe4a49e076efe291e54fcec3add78183c1edb» }

    Направьте внимание, что номер позиции в массиве общественных ключей употребляется лишь для переменной myind. Логика выбора 13 узлов последующая:

    • Определяются позиции узлов от 0 до 63.
    • Выбираются узлы с позициями от 0 до 12.
    • Если некий узел в этом спектре недоступен либо не отвечает, то заместо него употребляется последующая позиция, чтоб в общей трудности вышло 13 нотариальных узлов.
    • Если б эта логика просто употребляла позицию myind в массиве общественных ключей, то постоянно выбирались бы 1-ые 13 узлов из массива общественных ключей в коде komodod. Чтоб отдать любому из 64 нотариальных узлов равные шансы, позиция общественных ключей в любом раунде нотаризации сдвигается.
    • Как следует, если в крайнем раунде нотаризации позиция нотариального узла с именованием 0dev1_jl777 была 0, то в новеньком раунде она будет 63, а позиция 0 перейдёт к 0dev2_kolo. Таковым образом, за 64 раунда нотаризации любой нотариальный узел по одному разу будет на позиции 0. Так все нотариальные узлы имеют равные шансы, потому позиция в массиве общественных ключей не имеет значения.
    • В раундах нотаризации позиция всякого нотариального узла изменяется в согласовании со последующей модулярной арифметической формулой:

    (myind + (blockheight/10)) % 64 = позиция нотариального узла в данном раунде

    Таковым образом, согласно данной нам формуле, к примеру, если крайняя высота блока в блокчейне – 1000, а позиция нотариального узла в этом раунде, скажем, myind = 41, то получим:

    myind = 41
    blockheight = 1000
    mod_number = 64
    current_notarization_position = (41 + (1000/10)) % 64 = 13

    Узел с myind = 41 в этом раунде получит позицию 13. Так как выбираются узлы от 0 до 12, этот узел не будет участвовать в нотаризации в данном раунде.

    Потому что в любом раунде позиция myind изменяется, нереально найти, какие нотариальные узлы будут 13 подписантами в специальной транзакции Биткойна с мультиподписью.

    Подписание и трансляция нотариальной транзакции

    : bits.media

    Помните 1-ое требование для dPoW – Биткойн? Как раз на этом шаге нотариальные узлы должны употреблять в процессе нотаризации Биткойн. В случае ассетчейна либо постороннего блокчейна нотариальные узлы поначалу нотаризуют их по Komodo, буквально так же как информация из блока Komodo нотаризуется по Биткойну. Опосля того как из 64 нотариальных узлов было выбрано 13, они ДОЛЖНЫ иметь UTXO Биткойна и Komodo схожего размера для сотворения и подписи транзакции BTC.

    Бес Iguana инспектирует, доступно ли довольно UTXO схожего размера на BTC-адресе всякого нотариального узла. Эти средства употребляются для подписи и отправки транзакции в сеть Биткойна вкупе с нотариальными данными в OP_RETURN. Iguana постоянно параллельно делает этот процесс. На данный момент размер UTXO, применяемый нотариальными узлами, составляет 0,0001 BTC, но было время, когда он возрос до 0,0005 BTC из-за высочайшего числа транзакций (мусора?) в сети Биткойна, когда велись дискуссии о увеличении размера блоков (2016-17 гг.). Потом, когда сетевые транзакции опять стали подтверждаться без заморочек, размер UTXO возвратился к 10 000 сатоши.

    Код Iguana содержит шаблон для сотворения данной нам специальной транзакции с мультиподписью, которому следуют все нотариальные узлы. Все узлы должны употреблять в подписываемой транзакции схожую сумму BTC, обозначенную в шаблоне (0,0001). Если некий нотариальный узел подпишет собственный vin, используя сумму, хорошую от 0,0001, и передает собственный подписанный txid остальным узлам, транзакция будет неудачной, потому что остальные нотариальные узлы будут мыслить, что она подписывается с внедрением 0,0001 BTC, так как все узлы имеют данный шаблон. Пример:

    vins:
    1. address1 0.00010000
    2. address2 0.00010000

    13. address13 0.00010000

    vouts:
    well_known_address 0.0013000

    Любой нотариальный узел вставляет в шаблон получившуюся подпись, и транзакция будет реальна, ТОЛЬКО если любая подпись соответствует шаблону. Это аналогично createrawtransaction с данными параметрами. И любой нотариальный узел подписывает лишь собственный свой vin. Он не может поменять формат транзакции, а может лишь её подписать.

    Любая нотариальная транзакция (не считая части с нотариальными данными OP_RETURN) припоминает обыденную транзакцию. Она не употребляет OP_CHECKMULTISIG, как транзакции с мультиподписью.

    Чтоб разъяснить по-простому, допустим, у вас на локальной машине есть кошелёк Биткойна.

    • У него есть 13 различных адресов, на любом из которых имеются UTXO по 0,0001 BTC.
    • Предполагается, что вы обладатель всех этих адресов, другими словами эти адреса не watchonly, а при проверке выдают ismine:true.
    • Для вас необходимо выслать все эти средства + txfee (комиссию за транзакцию) на один узнаваемый адресок (простоты ради допустим, что txfee = 0).
    • Если вы отправите транзакцию на сумму 0,0013 BTC, используя sendtoaddress, то она будет припоминать нотариальную транзакцию (кроме части с данными OP_RETURN). Для сопоставления можно поглядеть настоящую нотариальную транзакцию в блокчейне Биткойна.
    • Идентификатор транзакции: 979d23b8d929ccefdb79aabffa2d632f09b292bea71fe1efa4ce467d808ce12d.
    • С 13 адресов, отображаемых как ввод, отчаливает по 0,0001 BTC на один и этот же адресок.

    Итог будет схожим, потому что ваш кошелёк имеет 13 различных приватных ключей, соответственных 13 адресам, на любом из которых есть UTXO по 0,0001 BTC, и любой vin подписывается раздельно своим своим приватным ключом. В нотариальной транзакции всё то же самое, лишь процесс распределяется меж нотариальными узлами.

    Любой нотариальный узел имеет один приватный ключ, соответственный его адресу. Потому любой нотариальный узел подписывает лишь собственный UTXO и передает эту подпись остальным из 13 избранных узлов. Когда узлы получили 13 подписей, транзакция транслируется в сеть.

    В случае 13 адресов в одном кошельке весь процесс весьма прост, потому что 13 приватных ключей и 13 подписей имеются сходу. В распределённом процессе, когда нотариальные узлы обмениваются подписями, транзакция быть может на 100% полной лишь опосля получения всех 13 подписей. Как можно созидать, этот процесс труднее, поэтому что для того, чтоб транзакция свершилась, все 13 подписей ДОЛЖНЫ быть верны и получены и UTXO не должны быть расходованы на момент трансляции транзакции.

    Основное, что тут следует осознать, – это что в данной нам транзакции просто расходуются 13 UTXO с 13 различных адресов, также врубаются нотариальные данные в OP_RETURN, и ничего больше. Никаких сценариев жёсткой блокировки либо разблокировки, и никакого OP_CHECKMULTISIG. Просто рядовая транзакция, но её сложность в том, что всё это происходит средством «распределённой сети».

    Из вышеизложенного описания читателю обязано быть ясно, что тут действуют такие же условия, какие может употреблять юзер кошелька хоть какого другого блокчейна, чтоб сделать на собственной машине транзакцию и передавать её в сеть. Единственная разница в том, что этот процесс незначительно труднее из-за «распределённой сети» нотариальных узлов и включения нотариальных данных в OP_RETURN в блокчейне, в который отправляются монеты, вкупе с данной транзакцией с мультиподписью.

    Ничего такого особенного тут нет: процесс следует этим же правилам сети Биткойна, что и рядовая транзакция. Транзакция будет отклонена, если она недействительна, так как к нотариальной транзакции используются все те же правила. Создатели Биткойна не могут занести такие транзакции в чёрный перечень либо воспрепятствовать их прохождению в сети Биткойна. Если кто-то по некий необычной причине захотит помешать Komodo проводить нотаризацию по сети Биткойна, он не сумеет этого создать. Нотариальные транзакции просто посылают маленькую сумму в биткойнах, что выступает базисным действием всего сетевого протокола. Потому полагать, что нотариальные транзакции могут быть блокированы некий сетью – всё равно что гласить, что эта сеть может признать недействительным создание и отправку транзакций снутри неё. Это просто не имеет никакого смысла.

    На нотариальных узлах блок Komodo, проводящий нотаризацию по сети Биткойна, смотрится в логах Iguana так:

    >>>>>>>>>>> BTC dpow_sendrawtransaction (979d23b8d929ccefdb79aabffa2d632f09b292bea71fe1efa4ce467d808ce12d)complete statemachine.BTC ht.1131240 state.1000 (4000000 b8239d97)
    Доказательство нотаризации в блокчейне, защищённом при помощи dPoW

    Iguana ждёт, пока txid не будет принят в пул памяти Биткойна, опосля чего же начинает процесс записи инфы нотаризованного блока в блокчейн Komodo. Заметьте, что время меж блоками Биткойна не препятствует нотаризации, но пока транзакция всё ещё находится в пуле памяти первой криптовалюты, она относительно наименее неопасна, чем подтверждённая транзакция BTC.

    Как txid принят в пул памяти Биткойна, инициируется процесс доказательства нотаризованного блока на стороне Komodo. Лог Iguana в таком случае смотрится так:

    [44] END isratify.0:0 bestk.29 2400a12021236000 sigs.2400a12021236000 state.ffffffff machine ht.1131240 completed state.ffffffff BTC.979d23b8d929ccefdb79aabffa2d632f09b292bea71fe1efa4ce467d808ce12d KMD.838b84d051308eeeb442bd0f2f2fdd85d758b4f3a8bb287a2ca2b4bff723161c recvmask.7fd4fbb7fb67645d paxwdcrc.6ab6b224 0x7fb6de811010 0x7fb6f4097010>>>>>>>>>>> KMD dpow_sendrawtransaction (838b84d051308eeeb442bd0f2f2fdd85d758b4f3a8bb287a2ca2b4bff723161c)complete statemachine.KMD ht.1131240 state.-1 (4000000 d0848b83)

    Ссылка на txid Komodo: https://kmdexplorer.io/tx/838b84d051308eeeb442bd0f2f2fdd85d758b4f3a8bb287a2ca2b4bff723161c

    Реальность транзакции подтверждают майнеры Komodo и другие узлы сети, имеющие на собственных машинках полную копию блокчейна. Снова же, тут нет ничего такого особенного (кроме сложного процесса сотворения транзакции «распределённой сетью»). Всё буквально так же, как с хоть какой иной транзакцией, отправляемой в сети блокчейна, лишь с данными OP_RETURN, опосля чего же она подтверждается сетью.

    Нотаризованный блок необратимый

    Когда нотаризованный блок синхронизирован с остальной пиринговой сетью, реорганизовать его нереально. Другими словами он необратим. Правило консенсусного уровня dPoW таково, что блоки, предыдущие крайнему нотаризованному блоку, не могут быть «осиротевшими».

    dpowconf и правило о подсчёте подтверждений

    В защищённом dPoW блокчейне правило о доказательстве транзакций (известное как dpowconf) было обновлено, чтоб употреблять последующую логику, опосля пробы провести атаку двойного расходования (предпринятой forkwitch и geocold51) в блокчейне EMC2, защищённом при помощи нотаризации dPoW:

    • Когда транзакция транслируется в сеть, она ждет принятия в пул памяти блокчейна.
    • Опосля принятия в пул памяти она ждет 1-го доказательства, и до последующего нотаризованного блока счётчик подтверждений не превосходит 1.

    Таковым образом, если транзакция транслируется в сеть в момент, когда крайний нотаризованный блок был, к примеру, 2 блока вспять, то она ждёт минимум одной нотаризации, даже если блок, в который она включена, подтверждён. Когда будет подтверждён последующий блок, число подтверждений (confirmations) будет оставаться 1.

    В JSON-выходе данных неподтверждённой транзакции есть ещё один объект под заглавием rawconfirmations, который указывает фактическое число подтверждений, которое равномерно возрастает.

    Допустим, что последующие 10 блоков нет нотаризованных блоков, синхронизированных с блокчейном. В таком случае выход неподтверждённой транзакции txid будет демонстрировать confirmations: 1 и rawconfirmations: 10. И если 11-й блок будет нотаризован, счётчик обновится до confirmations: 11 и rawconfirmations: 11.

    Ах так смотрится пример транзакции Komodo в выходе командной строчки:

    satinder@linux:~$ komodo-cli getrawtransaction «002dc8d587b0ea34797c8f3ab87ee8d3377443672b8d5d0fafcf826592c921f1» 1 | tail
    ],
    «vjoinsplit»: [
    ],
    «blockhash»: «00000003063189fef9623f920cc4c9444af857004fed8a21361351aee8690fe6»,
    «height»: 1138123,
    «confirmations»: 1,
    «rawconfirmations»: 1,
    «time»: 1544696732,
    «blocktime»: 1544696732satinder@linux:~$ komodo-cli getrawtransaction «002dc8d587b0ea34797c8f3ab87ee8d3377443672b8d5d0fafcf826592c921f1» 1 | tail
    ],
    «vjoinsplit»: [
    ],
    «blockhash»: «00000003063189fef9623f920cc4c9444af857004fed8a21361351aee8690fe6»,
    «height»: 1138123,
    «confirmations»: 1,
    «rawconfirmations»: 11,
    «time»: 1544696732,
    «blocktime»: 1544696732
    }satinder@linux:~$ komodo-cli getrawtransaction «002dc8d587b0ea34797c8f3ab87ee8d3377443672b8d5d0fafcf826592c921f1» 1 | tail
    ],
    «vjoinsplit»: [
    ],
    «blockhash»: «00000003063189fef9623f920cc4c9444af857004fed8a21361351aee8690fe6»,
    «height»: 1138123,
    «confirmations»: 23,
    «rawconfirmations»: 23,
    «time»: 1544696732,
    «blocktime»: 1544696732
    }
    satinder@linux:~$

    Следствие этого обновлённого правила довольно обычное и прямолинейное: защита блокчейна от атак 51% (двойного расходования). Как понятно, на централизованных криптобиржах сумма пополнения кошелька недосягаема клиенту до определённого числа подтверждений транзакции. Таковым образом, данное правило dpowconf – самый надёжный метод для хоть какой централизованной биржи защититься от атак 51% на блокчейны, внедрившие способ сохранности dPoW.

    Легенды и факты о dPoW

    Миф 1. Нотариальные узлы – это централизованное решение

    • Есть 64 нотариальных узла.
    • Все 64 нотариальных узла выбираются обществом.
      • 4 нотариальных узла принадлежат разрабам. Они переизбираются любой год.
      • 30 нотариальных узлов переизбираются исходя из их характеристик нотаризации по BTC (и ассетчейнов по KMD).
      • 30 вакансий нотариальных узлов открыты для каждогодних выборов.
      • Процесс сотворения транзакции таковой же, как для хоть какого другого сетевого узла, и трансляция данной нам транзакции с хоть какого узла с нотариальными данными не делает процесс централизованным.

    Миф 2. Нотариальные узлы подобны мастернодам

    • В отличие от мастернод, чтоб стать нотариальным узлом Komodo, требуется ровно 0,00000000 KMD. Чтоб стать оператором нотариального узла, KMD НЕ необходимы. Чтоб начать делать процесс нотаризации, довольно быть избранным обществом KMD.
    • До начала работы в общественной сети надёжность и способности кандидатов на операторов нотариальных узлов оцениваются в тестнете. Это помогает обществу и участникам команды Komodo убедиться, что для децентрализованной сети нотариальных узлов будут выбраны самые действенные и квалифицированные операторы.

    Анализ атак на dPoW

    Уникальная, неотредактированная версия уайтпейпера dPoW, написанная jl777 (Джеймсом Ли), содержит анализ всех вероятных атак и кратко разглядывает, почему эти атаки невозможны при наличии в блокчейне нотаризованных блоков.

    Атака двойного расходования

    На момент написания jl777 собственной первой версии уайтпейпера консенсусного правила dpowconf в рабочей базе кода не было. Опосля прибавления dpowconf провести атаку 51% сделалось ещё труднее. Как пример атаки двойного расходования, злодей может попробовать майнить блоки с большей вычислительной мощностью, чем сеть, которая защищает подвергающийся атаке блокчейн, но таковая атака вероятна лишь до последующей нотаризации.

    К примеру, если блокчейн получает новейший блок приблизительно любые 60 секунд (как KMD и ассетчейны), а частота нотаризации приблизительно раз в 10 минут, то наибольшее время, имеющееся у злодея на атаку меж нотаризациями – около 10 минут. Это приблизительно 10 (максимум 12) блоков, когда злодей может попробовать внести конфигурации, причём он не может поменять блоки, предыдущие крайней нотаризации.

    Не считая того, буквально так же как все биржи следуют правилу о необходимости наиболее чем 1-го доказательства, правило о доказательствах dpowconf защищает юзеров нотаризуемых блокчейнов и биржи от таковых атак, так как счётчик подтверждений возрастает, лишь когда блокчейн лицезреет нотаризованный блок.

    Для рассмотрения всех вероятных векторов атаки пригодилась бы отдельная статья, потому перейдём к крайнему гипотетичному варианту атаки, предложенному Джастином Эренхофером во время дискуссии с jl777 на сервере Komodo в Discord.

    Самоубийственная атака нотариального узла

    Я предпочитаю именовать такую предполагаемую атаку самоубийственной, так как это соответствует догадке. Как я понимаю, дискуссия пришла к этому, потому что все остальные вероятные векторы атаки оказались несостоятельными. Попробовать провести всякую из схожих атак на защищённый dPoW блокчейн будет очень трудно, и в главном это будет только растрата времени, энергии и средств.

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

    Несогласие 1-го нотариального узла

    Любой узел, подключённый к сети 64 нотариальных узлов, посылает всем остальным узлам информацию о высоте крайнего блока и блокхеше. Эта информация вкупе с битовой маской транслируется каждым нотариальным узлом всем остальным. Любой из их докладывает остальным, какие 13 узлов должны быть выбраны в качестве подписантов блока, и лицезреет информацию, отправляемую всеми иными нотариальными узлами. То все есть узлы лицезреют то, что они получают впрямую, также то, что лицезреют остальные узлы. С учётом этого они могут достигнуть согласия о 13 подписантах. Если некий узел не согласен и не воспринимает битовую маску победивших 13 узлов, то он просто игнорируется.

    Битовая маска – это итог композиции инфы о высоте крайнего блока + блокхеше + расчёте битовой маски + согласии остальных нотариальных узлов в сети. Один нотариальный узел не может расстроить процесс нотаризации.

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

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

    Несогласие наиболее чем 1-го нотариального узла

    Допустим, что наиболее чем один нотариальный узел или не на 100% синхронизирован с блокчейном, или преднамеренно подрывает сеть, предоставляя неверную информацию, чтоб сделать разногласия меж узлами касаемо нотариальной инфы. Быстрее всего, это не будет представлять большенный препядствия, зависимо от того, какая часть нотариальных узлов не согласна вместе.

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

    Сущность в том, что информация о высоте блока + блокхеше, поступающая от сети, – это для нотариальных узлов 1-ая правда. Нотариальные узлы не решают, какой блок должен быть принят из политических суждений и т. п. Тут всё аналогично консенсусным правилам первого уровня хоть какого другого блокчейна.

    Нотариальные узлы хранят на собственных машинках полную копию блокчейна и подтверждают реальность блока, проверяя подтверждения, доступные в истории локального блокчейна, и соглашаясь с остальными подключёнными узлами пиринговой сети, не непременно майнерами либо нотариальными узлами. Согласие насчёт высоты крайнего блока + блокхеша – это всего только согласие с общим для всей пиринговой сети консенсусным правилом.

    Группа нотариальных узлов, придерживающихся консенсуса, постоянно выбирает 13 узлов, пребывающих в согласии, используя, в сути, децентрализованный процесс, даже если в нём участвует лишь 64 узла. И наличие таковых доверенных нотариальных узлов ведёт к нотаризации блоков, защищённых консенсусом dPoW.

    Единственный вариант, когда нотариальные узлы могут вправду конфликтовать с иными и не соглашаться с информацией, которой они обмениваются с иными, – это раскол блокчейна. Это событие вроде того, что несколько годов назад вышло с Биткойном и Bitcoin Cash, где блокчейн до определённого момента содержит одни и те же блоки и историю транзакций, но потом раскалывается на два различных конкурирующих блокчейна, что ведёт к расхождению правил, применяемых майнерами и узлами сети, использующими набор правил того либо другого форка.

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

    Если злодей (не принципиально, нотариальный узел либо кто-то снаружи) майнит в личном порядке, то ни у кого из нотариальных узлов не будет его блокчейна, потому он должен его передавать. Но если он его передает, то к нему будут применяться правила нотаризации. Потому если кто-то начнёт майнить с крайней нотаризации и распространит свою версию большенному числу узлов, то этот блокчейн станет основным и будет нотаризоваться. Думаю, это решит вопросец форка, так как блокчейн, который нотаризуется, считается основным (мейнчейном). Так что даже в случае идейного раскола блокчейна будет один форк, который нотаризуется и получает сохранность dPoW, и иной, который этого не имеет.

    В сути, чтоб происходила нотаризация, всё обязано работать соответствующим образом. Операторы нотариальных узлов могут это подтвердить. Потому отсутствие нотаризации в защищённом dPoW блокчейне – мощный сигнал, что происходит что-то ненормальное.

    Общее несогласие нотариальных узлов

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

    Допустим, некие нотариальные узлы согласны с некий частью блокчейна, которая уже нотаризована по другому блокчейну, а остальные нотариальные узлы пробуют нотаризовать какую-то другую, отличающуюся часть блокчейна. Это аналогично ситуации с форком, которая разъяснялась выше. И если все нотариальные узлы не согласны с остальной сетью, а сеть желает перейти на версию до крайнего нотаризованного блока, необходимо согласие разных сторон:

    • Майнеров блокчейна;
    • Узлов сети, хранящих полную копию блокчейна;
    • Всех нотариальных узлов, которые согласны с откатом блокчейна к некоему блоку, предыдущему крайнему нотаризованному.

    Таковой сценарий припоминает хард-форк блокчейна, который уже публичен и с которым все уже согласны. Но это может быть лишь при 2-ух критериях:

  • Нотариальные узлы поновой синхронизируются с копией блокчейна узлов/майнеров, которые майнят с первой точки расхождения с остальной сетью, и лишь опосля этого подключаются к сети, которая соглашается, что их копия блокчейна четкая (мейнчейн).
  • Узел может признать нотаризованный блок недействительным и избежать новейшей синхронизации блокчейна, но о этом любой узел воспринимает решение без помощи других.
  • «Я считаю, что dPoW не безупречен, но для цепочки с маленьким хешрейтом это лучше, чем отсутствие dPoW, – jl777, разраб ядра платформы Komodo».

    Перефразируя текст Джеймса Ли из чата (источник):

    «Обычно не надо проводить новейшую синхронизацию, довольно признать недействительной нотаризацию A, но это зависит от всякого узла. Таковым образом, неважно какая попытка перевести мейнчейн из A в B средством нотаризации B – это весьма приметный процесс.

     

    И также нужен общий консенсус насчёт того, какой блокчейн верный, так что пробовать выполнить двойное расходование средством такового механизма – непрактично. Намного проще провести атаку 51% на блокчейн без нотаризации. Моя позиция такая, что dPoW не совершенно, но для блокчейнов без большенный вычислительной мощности оно очевидно лучше, чем его отсутствие.

     

    Можно уверить узел, который не лицезреет нотаризованный блокчейн, в существовании блокчейна B. Опосля нотаризации двойное расходование нереально. Опосля повторной синхронизации блокчейн A одолеет, потому что он нотаризован. Блокчейн B не сумеет пойти далее 1-го «доказательства», потому что он не был нотаризован. Потому ни один платёж в блокчейне B не будет признан».

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

    Аргументы о практической невозможности сговора нотариальных узлов для проведения атаки

    • До этого всего, когда блокчейн защищён при помощи механизма dPoW, его сохранность намного возрастает. Это касается как нотариальных узлов, так и обыденных полных узлов и майнеров. Хотя нотариальные узлы имеют маленькое преимущество над обыкновенными полными узлами и майнерами при проведении атаки на защищённый dPoW блокчейн, им всё равно на много порядков труднее штурмовать таковой блокчейн, чем тот, у которого нет dPoW.
    • Неважно какая целенаправленная атака со стороны нотариальных узлов сходу же раскроет злоумышленников, то все есть будут знать, кто это сделал. Потому даже при маловероятной попытке злоумышленного сговора причастные к нему нотариальные узлы немедля будут идентифицированы и внесены в чёрный перечень. Но сговор практически наверное не принесёт денежной прибыли, так что маловероятно, чтоб операторы нотариальных узлов совершенно пробовали это провернуть.
    • Сговор сам по для себя также маловероятен, так как у нечестных операторов нотариальных узлов не будет обстоятельств доверять друг дружке. Это понятно как «проблема воровской чести». В очень маловероятном случае атаки двойного расходования нечестная транзакция будет отчаливать на некий определенный адресок, другими словами управляемый одним (и лишь одним) из узлов-злоумышленников. Какие гарантии имеют остальные участники сговора, что этот узел поделится выручкой? Весьма высок риск, что они убьют свою репутацию и не получат взамен полностью ничего, что ещё больше понижает мотивацию вступать в сговор.
    • В конце концов, стоит выделить, что проще провести атаку 51% на блокчейны без dPoW. Для нотариальных узлов атака на защищённый dPoW блокчейн экономически нерентабельна по стольким характеристикам, что их маленького достоинства недостаточно, чтоб таковая атака была проще атаки на блокчейн без dPoW. Это касается как операторов нотариальных узлов, так и всех других. В сути, добавление dPoW делает атаку труднее для всех, даже для нотариальных узлов. Если б нотариальные узлы вправду имели злой умысел, то они бы штурмовали некий иной блокчейн, не защищённый при помощи dPoW.

    Масштабирование нотариальных узлов

    Также поднимают вопросец о том, что нотариальные узлы, так как они хранят на собственных машинках полные копии всех блокчейнов, защищённых при помощи dPoW, не сумеют впору масштабироваться, когда всё больше блокчейнов будут выбирать способ сохранности dPoW. К примеру, если dPoW воспримут сотки либо тыщи разных ассетчейнов и посторониих блокчейнов, как любой нотариальный узел сумеет сразу хранить столько полных блокчейнов?

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

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

    Как я могу судить, данный вопросец никак не связан с консенсусными правилами dPoW. Существует довольно ресурсов и устройств для управления серверами, позволяющих сделать кластер узлов и сервисов, который средством обычного приложения управляет бэкэндом сложной серверной архитектуры. Включённое в Iguana децентрализованное приложение для нотариальных узлов, которое подключается к демонам всех загруженных полных блокчейнов, обязано быть в состоянии передавать ту же информацию всем остальным нотариальным узлам пиринговой сети. Настройка серверной архитектуры – это творческий процесс, зависящий от способностей операторов узлов, старающихся обеспечить наилучшее функционирование собственной инфраструктуры.

    Другая сеть нотариальных узлов для dPoW

    Способ dPoW не привязан к нотариальным узлам платформы Komodo. Чтоб нотаризовать один блокчейн по другому, не непременно употреблять официальные нотариальные узлы Komodo.

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

    В таком случае нотаризация будет происходить лишь по блокчейну Komodo. Потому иметь полную копию блокчейна Биткойна не надо. Таковым нотариальным узлам довольно будет иметь полные копии собственного блокчейна и блокчейна Komodo.

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

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

    Другая сеть нотариальных узлов уже существует у проекта KMDLabs. Команда проекта также сделала некие усовершенствования, чтоб больше заавтоматизировать свою сеть нотариальных узлов. Больше инфы о проекте KMDLabs можно отыскать на https://kmdlabs.io/.

    В окончание

    Процесс dPoW может показаться запутанным, но если осознать его внутренние механизмы, то можно убедиться, что это наилучшее решение против атак 51%. Можно было бы привести ещё больше подробностей, ссылаясь на разъяснения разрабов платформы Komodo, но эта статья не нацелена только на программистов. Она обязана стать полезной как для на техническом уровне подкованных, так и для обыденных юзеров. Я лично тоже почти все прояснил себе во время её написания благодаря помощи Джеймса Ли (jl777) и остальных разрабов проекта, таковых как Decker. Было много таковой инфы, которая отсутствовала во наружных источниках, потому я включил тут то, что, по моему воззрению, обязано стать общедоступным.

    Источник

    About Adminer

    Check Also

    Твиттер-привычки криптоэлиты

    Сходство близнецов Уинклвосс не ограничивается наружностью: привычки в отношении использования твиттером они делят тоже. Почти …

    Добавить комментарий