Что такое необратимый блок? В VIZ этот параметр влияет на подтверждение нодой необратимой версии цепи блоков. В случае если к ноде через p2p систему попадет форк цепи (блоки которого ссылаются за границу блоков last_irreversible_block_num), она просто не будет их рассматривать.
Принцип расчета irreversible block довольно простой — three quarters (три четверти или 75%), но почему он такой? Как так получилось?
Этот принцип достался «по наследству» вместе с кодовой базой. Он не заложен в протокол, да и не влияет на какой-либо консенсус внутри блокчейн-системы. Это частное поведение каждой отдельной ноды. Несмотря на то, что необратимость блоков это акт доверия данным, принцип three quarters основан на нежелании доверять кому-то.
Поэтому многие заблуждаются в понимании irreversible block — они возлагают на данную переменную обязательства гаранта, что блоки до этой границы не могут быть изменены.
Но это не так, в случае сбоя ноды или изолирования интернета (железным куполом) возможна ситуация, когда часть делегатов продолжат взаимодействия и уйдут в собственный форк цепи (где отвалятся другие делегаты вне изоляции, и irreversible будет двигаться уже самостоятельно).
По возвращении к старой сети, они, скорее всего, уйдут на повторную синхронизацию, отказываясь от блоков в собственном изолированном форке.
Акт доверия необратимости блоков — это доверие тому, какую цепь конкретная нода считает необратимой. Принцип три четверти в итоге сводится к тому, что нода не хочет кому-то доверять, но доверять вынуждена, поэтому «условно» она доверяет блоку, если его содержимому доверяет 3/4 (75%) делегатов из очереди.
Напомню, что в очереди делегатов VIZ находится 21 место, соответственно нода «условно» доверяет блоку, если в цепи с его участием отметилось 15 делегатов.
Мое предложение — окончательно закрепить за пониманием irreversible block не гарантию блокчейн-системы по необратимости цепи, а акт доверия по необратимости цепи к конкретной ноде.
Именно поэтому я предлагаю изменить понимание концепции — доверять не «по необходимости», а самим участникам взять на себя ответственность в виде этого самого доверия публичной ноде или блокам от делегатов. Также стоит предлагать опции с разными принципами доверия:
- Circular trust — круговое доверие, основанное на осознанном доверии топ-делегатам. Если один топ-делегат подтвердил блок другого топ-делегата, то этого достаточно, чтобы тоже доверять этому блоку.
- Code is law — код есть закон, доверие коду. Забавно: мы все говорим, что код есть закон, но никто не пытался строить доверие на этой основе. Опыт замещения цепи при консенсусе Proof of Work подорвали доверие к коду, когда любой желающий мог заявить и показать валидный блок. В блокчейн-системах с Fair DPoS консенсусом есть алгоритм расчета очереди делегатов, есть правила учета передаваемого веса при голосовании за делегатов. Почему мы тогда строим доверие на квалифицированном большинстве, когда у нас есть конкретная возможность доверять коду? Валидация операций в блоке — достаточное условие, чтобы отбросить недостоверные экземпляры блока. В данном принципе расчета необратимого блока достаточным условием является проверка на валидность, соответствие делегата своему месту в очереди.
Создается ощущение, что «мы застряли» в каменном веке. Тогда как DLT системы строятся на акте доверия (синхронизация содержимого общего блока), блокчейн-системы используют принцип лежебоки. Сколько делегатов перепрыгнет через блок? Если набралось 15, то тогда верим, а если не набралось — не верим.
Как итог DLT системы будут перехватывать технологическое первенство, если мы не научимся проявлять акт доверия и брать за него осознанную ответственность. Чтобы перешагнуть через эту пропасть концептуальной стагнации, мое предложение:
- Включить в VIZ возможность выбора принципа учета irreversible. Добавить в конфигурацию ноды irreversible-principle, который можно выставить в tree-quarters, circural-trust и code-is-law.
- Дополнить операцию get_dynamic_global_properties в Database API, расширив массив указанием irreversible_principle, используемым нодой.
- Выставить по умолчанию принцип circular-trust для рекомендованного конфигурационного файла публичных нод.
Нам надо учиться доверять. Начнем с доверия топ-делегатам, что они исполняют идентичный код, обеспечивают инфраструктуру для всех участников сети. Только понимание этого позволит VIZ развиваться и повысить отзывчивость пользовательского взаимодействия.
P.S. Яркий пример нелогичного использования необратимого состояния — сотни игр на EOS и TRON, которые работают с актуальным состоянием блокчейна, вовсе игнорируя номер последнего необратимого блока. Люди доверяют проектам, публичным нодам и их состоянию, но ноды не хотят брать на себя ответственность и проявлять доверие к делегатам.
Уточнения
Уточню, code-is-law будет двигать irreversible к предыдущему валидному блоку. Текущий валидный блок от делегата, который занимает свое время — подтверждает предыдущий валидный блок.
В чате просили уточнить не про игровые примеры, а про финансовые. А в чем, собственно, разница. Если у вас стоит нода, синхронизированная с основной сетью и вы ей «доверяете» в плане валидации на достоверность коду, то вы можете сами решать, какое подтверждение для вас будет «необратимым».
Кто-то может считать 400 подтверждений блока (количество блоков после искомого), кто-то может основываться на количестве делегатов из очереди, кто-то на конкретном списке доверенных делегатов. В любом случае нужно отрабатывать разные случаи и проектировать систему с учетом падения интернета и отвалившейся синхронизации.
Стоит также отметить, что текущие блокчейн-системы проектируются с учетом возможного отключения сервера от интернета (пропал интернет в конкретном дата-центре). А что будет, если произойдет изоляция в виде железного купола, например, в России. Допустим, 6 нод делегатов находятся территориально в России.
Они будут видеть друг друга, но другие делегаты для них начнут пропускать блоки. В итоге по механике в коде их цепь выкинет делегатов, которые пропустили много блоков. И в изолированном интернете будет свой мини-форк блокчейн системы. Условно, можно представить это в виде отделения VIZ Russia от VIZ Worldwide на конкретном блоке. Извне VIZ Russia будет недоступна. Сервисы тоже будут разделены. Те сервисы и приложения, которые территориально находятся в изолированной среде будут решать, что делать.
Переезжать или развивать изолированное пространство. Я считаю это нормальным положением дел. Своего рода автоматическое разделение цепи на изолированные друг от друга сегменты. Просто тогда делегатам придется сделать выбор — в какой среде осуществлять деятельность.
Наградить автора поста
