Данная работа нацелена на определение, является ли анализируемый объект DLT-системой. Полученные результаты, хорошо подходят для сравнительного анализа разных проектов, начиная от структуры управления, заканчивая определением ссылок, на которые ссылаются транзакции.
Технический анализ
Уровень протокола
Генезис
Уровень протокола, относится к процессам, которые необходимые разработать и запустить до запуска сети.
Зависимость от других сетей.
Зависимость от других протоколов, зависит от границ анализируемого проекта. Это определяет, может ли система работать как независимая система (быть самодостаточной) или находится под зависимостью другой сети.
Таблица 1. Зависимость от других систем
Программный код
Код может быть основана на существующем фреймворке или написана с нуля. Самые популярные фреймворки – это кодовые базы от систем с открытым исходным кодом (Bitcoin / Ethereum). Также, существуют базы с закрытым исходным кодом для закрытых платформ, предоставляемых такими проектами, как Digital Asset / Clearmatics и SETL.
Таблица 2. Программный код
Определение правил
Введение правил относится к определению набора правил, на которых должна работать DLT-система. Этот процесс может выполняться разными участникам и индивидуален для конкретной DLT-системы.
Обновление протокола
Обновления протокола относится к существующим процессам, которые позволяют изменять правила системы. Обновление протокола может включать в себя устранение технических ошибок (багов), улучшение безопасности и функциональности системы, а также расширение или ограничение существующих правил протокола.
Управление протоколом
Управление протоколом относится к набору процессов принятия решений, которые позволяют изменять протокол в упорядоченном и законном порядке. Это подмножество более широкого управления проектами, которое охватывает полный набор процессов и норм, которые описывают и определяют координацию и действия, но которые не могут быть встроены формально в систему DLT.
Важным элементом, любого, предлагаемого изменения протокола, является способ его принятия и ратификации — или, другими словами, как легитимность предоставляется по предложению участников сети. Поскольку легитимность в этом контексте является социальной концепцией, нам представляется целесообразным выявить некоторые из возможных «социально-политических» отношений, обнаруженных в системах DLT.
Таблица 3. Управление протоколом
Управление протоколом принимает множество форм и часто определяется неясно. Изначально, DLT-системы характеризуются анархической властью (свободной), нет компаний или групп лиц отвечающих за принятие решений. Чаше всего, они похожи на процессы управления open-source движения. Примером обсуждения изменений протокола, может выступать общение разработчиков в чате / GitHub / конференции. В диктаторских условиях процесс проведения обсуждения изменений может быть точно таким же, но окончательное решение будет приниматься одним человеком. В некоторых случаях, форма управления протоколом может быть определена более, чем одним видом правления. Например, блокчейн EOS работает как федерация производителей блоков, которые выбираются пользователями, имеющих во владении актив EOS. Вес голоса определяется количеством удерживаемых токенов на адресе. Этот вид правления разделяет протокол на две стороны: «элита» и «обычных» пользователей, принимая характеристики иерархической системы: федерации, демократии и плутократии.
On-chain управление, подразумевает под собой включение функций управления на уровне данных. Цель состоит в том, чтобы формализовать управление, тем самым повышая легитимность и избегая раскола сети из-за споров или несогласованных обновлений протокола. Для DLT-систем был разработан разнообразный набор схем голосования on-chain, начиная от барометра настроения сообщества до проведения референдумов. Однако, функции управления on-chain, как правило, являются лишь дополнением к другим формам управления.
Изменение протокола
Фактический процесс обновления протокола подразумевает под собой:
- обновление программного кода на GitHub, если это open-source проект;
- обновление клиента, если это протокол с закрытым исходным кодом;
- клиенты, работающие на старом программном коде, могут считаться неактуальными и занесёнными «черный список»;
- клиенты, работающие на старом программном коде, образуют «форк», что приводит к созданию альтернативной версии протокола.
Таблица 4. Форма изменения протокола
Разные DLT системы используют разные методы для обновления сети. Например, Ethereum принимает пожертвования для финансирования разработок, а также обновляет сеть используя ПО от разработчиков, финансируемых через гранты.
Уровень сети
Сеть DLT протокола является прямым результатом реализации правил протокола. Сеть состоит из слаженной работы участников и процессов, которые придерживаются технологического стандарта (протокола) и активно участвуют в обмене данных и информацией по определенным каналам связи.
Процесс коммуникации
Процесс передачи данных между участниками DLT системы.
Доступ к сети
Доступ к сети подразумевает под собой возможность подключения к протоколу, оно может быть ограниченным или неограниченным.
- Неограниченный доступ – любой пользователь может свободно подключиться / отключиться в любой момент времени;
- Ограниченный доступ – только определенные пользователи могут подключиться к сети, обычно это контролируется назначенным субъектом.
Как правило, системы с неограниченным доступом не имеют ограничений в количестве участников, в то время, как закрытые сети могут устанавливать ограниченное на количество участников.
Обычно, участники получают прямой доступ к сети, запуская полные узлы: они считаются «элитой» с большим набором прав, поскольку они могут отправлять / проверять и передавать данные записей. Участники сети, также могут получить непрямой доступ к сети, запустив «легкие клиенты», которые запрашивают данные у полных узлов, подключившись через специальную службу (API).
Таблица 5. Форма доступа к сети
Как правило, чем более открытой является система, тем больше она подвержена атакам. В частности, эти системы уязвимы для атаки «Сивиллы», когда атакующий создает множество поддельных личностей для повышения влияния на сеть.
Атака Сивиллы – это вид атаки, когда атакующий получает доступ или скрывает изменение в протоколе, создания множество ложных личностей.
Поскольку идентификация является экзогенным (т.е «реальным») свойством, DLT-система не может предотвращать данные атаки, она должна полагаться на внешних участников (система сертификации) или механизмов, снижающих вероятность атаки (PoW / PoS).
Отправка данных
Передача данных – это процесс распространения данных на подключенные узлы. Данные могут быть необработанными / неформатированными или стандартизированными под определенный формат (например, в форме транзакции или записи). Данные могут передаваться на каждую ноду (универсальная диффузия), или только определенному подмножеству узлов (многоканальная диффузия). В последнем случае, распространение данных, как правило, ограничивается участниками сделки. Это позволяет создавать «канал» для передачи данных, обычно под этим подразумевается шардинг / Lightning Network.
Ранние DLT-системы (например, Bitcoin, Litecoin) используют универсальную модель распространения данных, которая по-прежнему остается самым популярным методом распространения данных.
В целях соблюдения анонимности и приватности для компаний, в более поздних системах реализована многоканальная модель диффузии (например, Hyperledger Fabric, Corda). Другие системы, такие как Cosmos, предназначены для того, чтобы выступать в роли «Хабов», чтобы независимые DLT-системы могли быть связаны между собой посредством шардинга.
Таблица 6. Форма отправки данных
Примером многоканальной диффузии данных является то, что не все участники сети должны участвовать в достижении консенсуса в отношении состояния канала: только участники канала должны достичь согласованности над данными, хранящимися в этом канале («локальный» консенсус). Это значительно отличается от систем с глобальной диффузией данных, поскольку каждый отдельный узел должен прийти к консенсусу относительно глобального состояния системы («глобальный» консенсус); невозможность достижения консенсуса некоторых узлов, может привести к их отключению, или созданию форка.
Создание транзакции
Процесс создания транзакций содержит набор инструкций, которые будут выполняться после добавления транзакции в сеть. Создание транзакций может быть неограниченным (т.е доступным для всех) или ограниченным для некоторых участников. Транзакции создаются пользователями, подписывающим сообщение своим личным ключом. Для пользователей доступны различные интерфейсы, для создания и отправки транзакций в сеть (например, ПК и мобильные кошельки).
Процесс обработки транзакций
Обработка транзакций описывает набор действий, необходимых для добавления неподтверждённой транзакции в список подтвержденных. Транзакция считается (предварительно) действительной после добавления в список («подтверждённых»), что приводит к выполнению инструкций, встроенных в транзакцию. Однако, одного подтверждения недостаточно, чтобы эта транзакция стала основой для последующих операций; прежде чем выходы (outputs) транзакции могут быть использованы системой.
Рисунок 1. Обработка транзакций в DLT-системе
Записи подчиняются определенному алгоритму консенсуса, применяемого в DLT-системе. Это включает в себя процесс определения того, является ли предлагаемая запись действительной, а также отклонение недопустимых записей (например, записей, которые являются дефектными или несовместимыми) и выбор между различными, но одинаково действительными записями.
Кандидат на запись
Записи, которые в будущем могут быть перемещены в список подтвержденных транзакций, отправляются создателями блоков, которые выбирают их из списка неподтвержденных транзакций и, объединяют их вместе для формирования кандидатов на запись в список подтвержденных записей. Есть два свойства, которые определяют право на отправку записи и ее будущего включения в список подтверждённых записей.
Таблица 6. Формы создания записей
Поскольку записи подчиняются консенсусу, они должны придерживаться правил протокола. Сначала, они должны быть правильно отформатированы и не содержать недопустимых или недействительных транзакций. Кроме того, каждая запись должны включать ссылку / указатель на предыдущую запись и, при необходимости, использовать PoW или любой другой метод затрудняющей проведение атаки Сивиллы.
Алгоритм консенсуса может быть классифицирован в соответствии с его уровнем сложности (электрические / денежные затраты). Алгоритмы с неограниченным уровнем сложности измеряются в ресурсах, которые необходимы для достижения консенсуса. Например, в случае вычисления PoW Bitcoin, трудность поиска верного решения возрастает по мере увеличения сложности хеширования данных. Совсем наоборот работают другие алгоритмы (например, задача византийский генералов / BFT) не требуют значительных вычислительных затрат и имеют ограниченную сложность.
В открытых системах должен быть предусмотрен алгоритм, снижающий шанс проведения атаки Сивиллы. Частные (закрытые) системы проверяют каждого участника перед разрешением им доступа к подключению в сети, что предотвращает возможность проведения атаки. В закрытых системах, группа узлов обычно склоняется к выбору одного узла, который будет создавать блоки.
Разрешение конфликтов
Конфликт может быть вызван по нескольким причинам:
- участники расходятся во мнении, какая версия протокола является актуальной;
- участники расходятся во мнении, проверенных транзакций.
В случае возникновения ситуации первого пункта в сети Bitcoin, сеть выбирает самую длинную цепочку блоков, как действительную, а более короткую игнорирует. В Tezos определяется действительность блока с другим по «весу блока», весом здесь является количество «одобрений» от валидаторов, которые он получает случайный образом от стейкеров.
Любой алгоритм консенсуса несет в себе ряд компромиссов
Таблица 7. Формы мотивации обработки транзакций
Валидация
Валидация относится к набору процессов, необходимых для обеспечения того, чтобы субъекты самостоятельно приходили к одному и тому же выводу в отношении утвержденного набора записей. Это включает в себя: проверку отправляемых транзакций / проверку записываемых данных / проверку общего состояния сети. Этот является важным отличим от не DLT-систем, поскольку он предоставляет участникам возможность проводить самостоятельный аудит системы.
Проверка транзакции
Проверка транзакции заключается в том, чтобы удостовериться, соответствует ли отдельная запись правилам протокола, прежде чем передавать ее другим субъектам. Это включает в себя: правильность формата транзакции, наличие соответствующей подписи и выполнение условия, что транзакция не конфликтует с никакой другой. В некоторых системах может работать система, которая запрещает выполнять транзакции до определенного момента времени или другой причины. Обычно, такие условие выполняются смарт-контрактами.
Атака 51% это случай, когда участник или несколько участников объединяют свои вычислительные мощности (голоса) и обрабатывают транзакции в сети быстрее, чем вся остальная часть протокола. Такие атаки позволяют проводить недействительные транзакции и записывать их как валидные. Особенно уязвимой является система, использующая PoW
Проверка записей
Проверка отправляемой записи, позволяет удостоверится в том, что запись соответствует правилам протокола. Если предлагаемая запись признается валидной, она добавляется в список подтвержденных записей и ретранслируется на все подключенные узлы к сети. Хотя, данный процесс отличается в каждой системе, но, как правило, по общим принципам он схож везде, например, проверка того, что над транзакцией была проведена PoW работа. Сочетание проверки отправляемых транзакций и их последующей записи валидаторами, обеспечивает возможность независимого аудита всей системы.
Запись транзакции
Подтвержденная транзакция / запись, не обязательно является необратимой. Необратимость записи может иметь вероятностный характер (например, система на основе PoW, в которой непрактично вычислят заново все записанные транзакции), или системы, которые включают в себя «контрольные точки», которые должны быть присвоены к каждой транзакции. Подтвержденные записи могут называться неизменяемыми, но те записи, которые были «предварительно-подтверждены», могут быть отменены. Предварительно-подтвержденные записи становятся неизменяемыми после преодоления переходного состояния от «предварительно-подтвержденных» к «подтвержденным».
Рисунок 2. Обработка транзакций в DLT-системах
Рисунок 2 описывает схематическое описание процесса, который происходит при обработке транзакции. Во-первых, пользователь создает транзакцию и отправляет ее в сеть. Каждый узел проверяет, соответствует ли транзакция правилам протокола. Если она считается правильной, узел добавляет транзакцию в свой список (mempool), где хранятся все неподтвержденные транзакции, ожидающие добавления в список подтвержденных транзакций.
На этапе обработки транзакции, узлы случайным образом выбирают неподтвержденные транзакции из своего mempool и, затем объединяют их вместе в список «предварительно-одобренных» транзакций. Далее транзакции будут проверяться в соответствии с алгоритмом консенсуса, чтобы предложить эти транзакции всем остальным участникам сети. Узлы будут просматривать полученные транзакции и их содержимое, если транзакция проходит проверку, транзакция добавляется в список узла. Списки с транзакциями каждого узла в итоге отправляются в единый, самый главный список подтвержденных транзакций и будут считаться выполненными.
Однако, подтвержденные транзакции могут быть «отменены» из-за альтернативной транзакции, это означает, что на этапе урегулирования, транзакции могут быть отменены – в этом случае они возвращаются к узлам как неподтвержденные транзакции, ожидая создания нового списка транзакций. Время обработки транзакций на этапе «Урегулирования» зависит от настроек отдельно взятой системы. Некоторые системы реализуют мгновенную запись транзакций и их неотменяемость, но, некоторые протоколы, имеют «вероятностную» завершённость, в том смысле, что теоретически транзакции могут быть отменены. На практике, однако, вероятность этого действия снижается с каждой новой добавленной транзакцией, поскольку затраты узлов, связанные с PoW могут стать высокими. Пока транзакции находятся на стадии «урегулирования» их нельзя считать «завершенными». Процесс урегулирования транзакции повышает гарантию того, что транзакции точно включены в списки всех участвующих узлов, а не хранятся только на локальных узлах, это помогает предотвращать атаки двойной траты.
Некоторые системы реализуют систему «контрольных точек», чтобы ограничить возможность атак типа «long-range». В случае этой атаки, узел создает альтернативную цепочку со своими личными транзакциями (которые хранятся только у него), эти транзакции не появляются в сети, а сразу отправляются узлам на этап «урегулирования», чтобы заставить другие узлы заменить их на его локальные транзакции. «Контрольные точки» — это блоки, которые никогда не будет отменены или заменены. В результате контрольных точек, снижается «досягаемость» атаки. Однако контрольные точки, повышают риск создания форка.
Таблица 8. Свойства подтвержденных транзакций
Уровень данных
Уровень протокола определяет, как система будет работать и какие правила соблюдать. Уровень сети реализовывает заложенные принципы протокола. Вместе уровень протокола и сети формируют основу для уровня данных, который накапливается в течении времени по мере того, как транзакции записываются в список подтвержденных записей.
Операции
Компонент операций включает в себя все процессы, с помощью которых участники производят взаимодействия с системой.
Источники данных
Процесс ввода относится к источнику или способу получения данных для протокола. Источниками данных могут быть внутренние или внешние, что может отражать активное взаимодействие пользователей с системой, изменение состояние протокола, вызванное внутренним системным процессом или полученный извне (например, транзакция, отправленная с другого протокола) или смарт-контракт.
Мы определяем внутренние источники ввода как любую запись или транзакцию, созданную пользователем или из-за результата взаимодействия пользователя с протоколом. Внешние источники ввода, с другой стороны, являются результатом ввода из других систем, которые взаимодействуют с протоколом, но которые в принципе отделены от базовой платформы (т.е они являются зависимой или взаимодействующей). Гибридные протоколы, позволяют пользователям передавать транзакции используя «платежные каналы – state channel» в любое время, однако разработка этих методов все еще находится на начальной стадии.
Таблица 9. Формы ввода данных
Программно-исполняемые транзакции
Не все изменения уровня данных являются прямым результатом внутренних или внешних входных данных. Некоторые изменения в системе происходят из-за выполнения инструкций программного кода. Ярким примером являются смарт-контракты. При выполнении заложенного программного кода, в протоколе происходит изменение состояния сети, например, происходит транзакция, которая записывается в список подтвержденных. Некоторые DLT-системы, поддерживают только язык сценариев (скриптовый). Например, Bitcoin Script, он работает на просто языке сценариев, который позволяет создавать ограниченно-простые программы. Такие системы носят название – Stateless. Ethereum (Solidity), Tezos (Michelson) и EOS (WebAssembly) – эти системы поддерживают полные по Тьюрингу языки программирования для разработки сложных смарт-контрактов, а Bitcoin и Monero, используют язык сценариев, который позволяет проводить ограниченные операции.
Таблица 10. Свойства программно-выполняемых транзакций
Фактическое выполнение вычислений
Место выполнения программы, определяет, где происходят вычисления. Как правило, местом выполнения может внутри сети – on-chain или off-chain (за пределами сети). On-chain вычисления выполняются у каждого узла. Эта среда может варьироваться от простой виртуальной машины, как сценарный язык, так и быть сложной (EVM – виртуальная машина Ethereum), которая обеспечивает выполнение программ полных по Тьюрингу. Смарт-контракты в on-chain запускаются каждым узлом в сети и, поэтому часто называются «само исполняющимися».
Off-chain вычисления, выполняются в среде, которые являются внешними по отношению к протоколу. Событие, которое запускает программный код, происходит в on-chain, а вычисления происходят в другой системе, не нагружая основную сеть. Также, существует гибридная (Hybrid) система запуска приложений, например, Plasma в Ethereum. Или, например, Cosmos, где основная сеть служит «центром», но сами вычисления происходят в дочерних сетях.
Таблица 11. Свойства выполнения программно-выполняемых транзакций
Компонент журнала
Ссылки
Начиная с того момента, когда пользователи начинают взаимодействовать с DLT-системой, журнал обновляется со временем. Однако, журнал – это абстракция. Все процессы, которые происходят в DLT-системе, относятся к конкретному протоколу. Например, протокол, ориентированный на электронные платежи, должен содержать информацию об активах, принадлежащих конкретным пользователям. С другой стороны, DLT-система, которая включает в себя смарт-контракты, должна иметь собственную виртуальную машину, реализующий выполнение программного кода. Поэтому, понятие журнала – абстракция.
Виды ссылок
Существует четыре различных типов исходных данных: эндогенные, экзогенные, гибридные и самореферентные данные.
Эндогенные (внутренние) ссылки, относятся к данным, которые отслеживают информацию о переменных, которые являются «родными» для системы. Например, в Bitcoin, одна эндогенная ссылочная переменная используется для отслеживания количества биткойнов, которые пользователи имел в данный момент времени. Эта внутренняя переменная обновляется по мере того, как пользователь отправляет и получает биткойны на другие адреса. Экзогенная (внешняя) ссылка, относится к данными, которые отслеживают информацию о переменных, существующих вне системы. Гибридная ссылка относится к данным, которые имеют как эндогенные, так и экзогенные характеристики. Еще существует четвертый тип, который не является ни эндогенным, ни экзогенным и не гибридным: это нейтральный или пустой тип данных – это самореферентная ссылка. Например, смарт-контракт – это просто фрагмент кода, который может выполняться при выполнении определенных условий. Хотя смарт-контракту может потребоваться информация о внешних или внутренних системных переменных, сам код не имеет внутренней ссылки на что-либо вне себя («пустая ссылка»).
Таблица 12. Типы ссылок и их значение
Вывод
Данная работа нацелена на определение, является ли анализируемый объект DLT-системой. Полученные результаты, хорошо подходят для сравнительного анализа разных проектов, начиная от структуры управления, заканчивая определением ссылок, на которые ссылаются транзакции.
Автор: Марк
