Введение

В настоящее время существует огромное количество консенсус алгоритмов для блокчейн систем, каждый из которых имеет свои преимущества и недостатки присущие только ему, либо целому классу сходных алгоритмов. Так или иначе, в данное время лидирует две концепции консенсуса - основанные на майнинге (PoW) [1] и форжинге (PoS) [2], которые в свою очередь представляют конкурентную и последовательную модели генерации блоков непосредственно. Такое разделение либо предполагает крайне большое расходование материальных ресурсов, либо представляет собой необходимость комбинации с другими методами консенсуса [3], что приводит к сложности реализации, а следовательно и к проблеме доказуемой безопасности конечного решения [4, с.319]. Альтернативной моделью конкуренции и последовательности может являться алгоритм объединения узлов (PoU), решающий общую задачу сообща и главным преимуществом которого является простота реализации, сродни PoW и быстрота генерации блоков, эквивалентная PoS.

Становление

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

1. Конкуренция. Представляет собой генезис блокчейн систем, тезис и начало развития непосредственно. В такой модели каждый узел выполняет однотипные и сложно-математические операции полностью децентрализовано, несвязанно между собой, что порождает выполнение одинаковых действий многократно, в большей степени без всякой полезной нагрузки. Отрицательным качеством безусловно является необходимость поддерживать конкуренцию, быть соперником относительно всей другой сети, удерживать свои мощности, что в конечном счёте приводит, во-первых, к необходимости постоянного потребления майнинг-аппаратуры (процессоры, видеокарты, интегральные схемы и т.д.), во-вторых, к логичному завышению цен на подобную аппаратуру, методом искусственного дефицита средств производящими монополиями относительно большего спроса [5], в-третьих, к неостановимому поглощению электроэнергии и скорейшему разрушению потреблённой аппаратуры [6]. Положительным качеством же является простота описания алгоритма и независимость от сети, что и приводит к доступности анализа конечной безопасности.

2. Последовательность. Развивается как отрицание, антитезис конкуренции, избавляясь от самых негативных её черт. В такой модели узлы выполняют валидацию блоков поочерёдно, один за другим по общему алгоритму выбора валидатора. Сложность реализации последовательной концепции начинается на уровне сетевого консенсуса, когда строится сильная необходимость и даже зависимость валидации текущего и главного proposer валидатора всеми другими узлами сети, что приводит к возможности существования постоянных разветвлений посредством проблем «ничего на кону» и «двойной траты». Для такого случая существуют дополняющие алгоритмы, способные обеспечить сетевой консенсус между узлами, подобно ядру Tendermint, базируемом на задаче византийских генералов [7]. Безусловным положительным качеством такой модели является отсутствие в необходимости конкурировать, что приводит к достаточно простой аппаратной составляющей, не приводящей к трате большого количества электроэнергии и быстрому устареванию используемой техники.

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

Определение

Главным отличием PoU консенсуса является зацикленность системы на сохранение транзакций больше, чем самой связи между блоками, что является противоречивым явлением для блокчейн структур в целом. Суть заключается в том, что существует у таких алгоритмов N-ое количество блоков, подобно транзакциям, находящимся в статусе ожидания, pending’e, и в это же время существуют блоки, генерируемые после них, наперёд. Таким образом, можно сказать, что помимо транзакций, существуют также блоки, находящиеся в своеобразном mempool пространстве.

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

Механизм доказательства объединения состоит из трёх основных и последовательных функций выдающих блок в разный период его состояния.

1. Принятие (accept). При вызове данной функции происходит образование нового блока на базе взятых транзакций с mempool’a. При таком действии не происходит какого бы то ни было согласования с сетью, а следовательно само подтверждение является неполным, не приводящим к окончательному решению консенсуса. После данного этапа начинается временная задержка перед последующим вызовом функции accept, необходимая для согласования с сетью уже на основе второй функции merge.

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

3. Фиксирование (commit). При вызове данной функции происходит конечное согласование блока с сетью методом подсчёта количества одинаковых блоков и выбора наиболее встречаемых из полученного множества. Предполагается, что большая часть валидаторов будет говорить истину, а потому и сохранение итогового блока в конечном счёте будет основываться на количественной характеристике сети. Качественная характеристика может уже налагаться дополнительной бизнес-логикой к ядру блокчейн сети базируемом на PoU алгоритме.  

Рис. 1. Общая схема консенсуса Proof-of-Union при двух валидаторах,
где h - высота блока, (1+2) - объединение двух позиций
Рис. 1. Общая схема консенсуса Proof-of-Union при двух валидаторах, где h - высота блока, (1+2) - объединение двух позиций

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

Безопасность

У алгоритма PoU существует ряд неоднозначных явлений, присущих в большей части только ему. Так например, одним из важнейших моментов при анализе безопасности является невозможность доказательства «правильной» цепочки. Иными словами, PoU базируется на основе динамической генерации блоков, когда не существует объективной характеристики определить «вернейшую» цепочку из всего множества уже существующих, т.к. сам алгоритм основывается на концепции их слияния, а не выбора одного возможного элемента. Таким образом, новый подключающийся валидатор должен довериться одной ветви развития блокчейна из предложенного ограниченного множества.

Пример программного кода [8] процедуры объединения блоков:

import (
"bytes"
)
func (chain *ChainT) Merge(height Height, txs []Transaction) bool {
chain.mtx.Lock()
     defer chain.mtx.Unlock()
     var (
          lastBlock = chain.Block(height)
          resultTXs []Transaction
     )
     if chain.Height() != height {
          return false
     }
     resultTXs = append(resultTXs, lastBlock.Transactions()...)
     for _, tx := range txs {
          if !tx.IsValid() {
               return false
          }
          if chain.TX(tx.Hash()) != nil {
               continue
          }
          resultTXs = append(resultTXs, tx)
     }
     if len(resultTXs) == TXsSize {
          return false
     }
     sort.SliceStable(resultTXs, func(i, j int) bool {
          return bytes.Compare(resultTXs[i].Hash(), resultTXs[j].Hash()) < 0
     })
     appendTXs := resultTXs[:TXsSize]
     deleteTXs := resultTXs[TXsSize:]
     chain.updateBlock(height, NewBlock(lastBlock.PrevHash(), appendTXs), deleteTXs)
     return true
}

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

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

Заключение

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

Список литературы

  1. Накамото, С. Биткойн: система цифровой пиринговой наличности [Электронный ресурс]. — Режим доступа: https://bitcoin.org/files/bitcoin-paper/bitcoin_ru.pdf (дата обращения: 19.12.2020). 

  2. King, S., Nadal, S. PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake [Электронный ресурс]. — Режим доступа: https://web.archive.org/web/20171211072318/https://peercoin.net/assets/paper/peercoin-paper.pdf (дата обращения: 29.01.2022).

  3. PROOF OF STAKE - это скам [Электронный ресурс]. — Режим доступа: https://habr.com/ru/post/600113 (дата обращения: 29.01.2022).

  4. Шнайер, Б. Секреты и ложь. Безопасность данных в цифровом мире / Б. Шнайер. — СпБ.: Питер, 2003. - 368 с.

  5. Взгляд изнутри: цены на видеокарты и чего ждать от рынка завтра? [Электронный ресурс]. — Режим доступа: https://habr.com/ru/company/asus/blog/571400 (дата обращения: 29.01.2022).

  6. Самохин, В., Самохин, Д., Бабкин, Е., Петров, И. Актуальность вопросов энергосбережения на майнинг-фермах [Электронный ресурс]. — Режим доступа: https://cyberleninka.ru/article/n/aktualnost-voprosov-energosberezheniya-na-mayning-fermah (дата обращения: 29.01.2022).

  7. Герасимов, И., Чижов, И. Алгоритм консенсуса платформы Tendermint и механизм Proof Of Lock Change [Электронный ресурс]. — Режим доступа: https://cyberleninka.ru/article/n/algoritm-konsensusa-platformy-tendermint-i-mehanizm-proof-of-lock-change (дата обращения: 29.01.2022).

  8. Донован, А., Керниган, Б. Язык программирования Go / А.А. Донован, Б.У. Керниган. — М.: ООО «И.Д. Вильямс», 2018. - 432 с.

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

Комментарии (9)


  1. strayge
    13.02.2022 08:27
    +2

    Предполагается, что большая часть валидаторов будет говорить истину

    А что мешает злоумышленнику поднять ещё N тысяч валидаторов?


    1. UncleAndy
      13.02.2022 08:54

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


    1. Number571 Автор
      13.02.2022 09:17
      +2

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

      Из этого следует, что сам алгоритм консенсуса уязвим к концентрациям связи, что вполне может приводить к выстраиванию картелей валидаторов. Но и при этом сам консенсус также продолжает работать, в том числе и для "подчиняющихся" монополии узлов. Эта проблематика схожа с ядром Tendermint, базируемым на задаче византийских генералов, где необходимым условием консенсуса является +2/3 сети вне зависимости от того, кто такую сеть наполняет.

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

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


      1. strayge
        13.02.2022 09:54
        +1

        Вопрос стоит в плоскости того, что из этого злоумышленник может сделать.

        Да, выкидывание определенных транзакций — это первое что приходит в голову
        (или просто их замедление: хотите быстрее — платите держателю валидаторов).

        Потенциально можно добиваться ненахождения консенсуса (commit), т.к. каждое взаимодействие между валидаторами (merge) его меняет.

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

        Решений может быть множество, начиная от централизованной валидации каждого узла (что более схоже с PoA), совмещением других алгоритмов консенсуса (подобия PoS, PoB)

        PoA — это отказ от децентрализации, тогда и блокчейн не нужен.
        Добавление PoS нивелирует надобность в PoU, тогда можно и один PoS оставить.


        1. Number571 Автор
          13.02.2022 11:13
          +1

          Согласен с начальными суждениями.

          Да, выкидывание определенных транзакций — это первое что приходит в голову

          (или просто их замедление: хотите быстрее — платите держателю валидаторов).

          ...

          Итого всё упрётся в бизнес-логику определения неправильных валидаторов,

          Следующее суждение под вопросом.

          Потенциально можно добиваться ненахождения консенсуса (commit), т.к.
          каждое взаимодействие между валидаторами (merge) его меняет.

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

          Добавление PoS нивелирует надобность в PoU, тогда можно и один PoS оставить.

          Одна бизнес-логика (БЛ) (коей является PoS алгоритм, как бы это парадоксально не звучало) не приводит к консенсусу. Это можно наблюдать на примере PoS, который обязан объединяться с другими алгоритмами консенсуса, будь это BFT (задача византийских генералов, примером которой может являться Tendermint+Cosmos) или PoW. Наилучшее описание такого поведения можно найти также в статье на хабре https://habr.com/ru/post/600113.

          PoU по своему определению более схож с BFT (как способу сетевого консенсуса), нежели с PoS (как консенсусу на базе БЛ). Одно без другого, как показывает практика, не способно существовать. Таким образом, PoS алгоритм может быть соединён с PoU, равно как и PoS с BFT.

          PoA — это отказ от децентрализации, тогда и блокчейн не нужен.

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

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

          По поводу вышеприведённого мне действительно нужно будет обдумать правильность суждения, потому как я исхожу из противостояния PoU и PoS, хотя в большей степени нужно исходить из разницы PoU с BFT (как сетевыми и количественными моделями обеспечения консенсуса).


          1. nin-jin
            13.02.2022 13:26
            +2

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

            То есть получаем такую атаку:

            • разделяем сеть так, чтобы жертва оказалась в меньшей подсети

            • в меньшей подсети проводим транзакцию и получаем от жертвы профит

            • восстанавливаем связность сети и транзакция откатывается автоматически


  1. evnuh
    13.02.2022 12:49
    +1

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


  1. andreyverbin
    13.02.2022 13:29
    +4

    Не вижу, чтобы тут был возникал хоть какой-то консенсус. Как, например, решается проблема double spend?

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


  1. dmitrysvd
    13.02.2022 13:47

    Может упустил, но не вижу нигде, как должны создаваться и распределяться новые монеты?