Хабрахабр

[Из песочницы] Фреймворк: анализ DLT-систем

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

Технический анализ

Уровень протокола

Генезис

Уровень протокола, относится к процессам, которые необходимые разработать и запустить до запуска сети.

Зависимость от других сетей.

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

Зависимость от других систем Таблица 1.

Программный код

Самые популярные фреймворки – это кодовые базы от систем с открытым исходным кодом (Bitcoin / Ethereum). Код может быть основана на существующем фреймворке или написана с нуля. Также, существуют базы с закрытым исходным кодом для закрытых платформ, предоставляемых такими проектами, как Digital Asset / Clearmatics и SETL.

Программный код Таблица 2.

Определение правил

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

Обновление протокола

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

Управление протоколом

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

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

Управление протоколом Таблица 3.

Изначально, DLT-системы характеризуются анархической властью (свободной), нет компаний или групп лиц отвечающих за принятие решений. Управление протоколом принимает множество форм и часто определяется неясно. Примером обсуждения изменений протокола, может выступать общение разработчиков в чате / GitHub / конференции. Чаше всего, они похожи на процессы управления open-source движения. В некоторых случаях, форма управления протоколом может быть определена более, чем одним видом правления. В диктаторских условиях процесс проведения обсуждения изменений может быть точно таким же, но окончательное решение будет приниматься одним человеком. Вес голоса определяется количеством удерживаемых токенов на адресе. Например, блокчейн EOS работает как федерация производителей блоков, которые выбираются пользователями, имеющих во владении актив EOS. Этот вид правления разделяет протокол на две стороны: «элита» и «обычных» пользователей, принимая характеристики иерархической системы: федерации, демократии и плутократии.

Цель состоит в том, чтобы формализовать управление, тем самым повышая легитимность и избегая раскола сети из-за споров или несогласованных обновлений протокола. On-chain управление, подразумевает под собой включение функций управления на уровне данных. Однако, функции управления on-chain, как правило, являются лишь дополнением к другим формам управления. Для DLT-систем был разработан разнообразный набор схем голосования on-chain, начиная от барометра настроения сообщества до проведения референдумов.

Изменение протокола

Фактический процесс обновления протокола подразумевает под собой:

  1. обновление программного кода на GitHub, если это open-source проект;
  2. обновление клиента, если это протокол с закрытым исходным кодом;
  3. клиенты, работающие на старом программном коде, могут считаться неактуальными и занесёнными «черный список»;
  4. клиенты, работающие на старом программном коде, образуют «форк», что приводит к созданию альтернативной версии протокола.

Таблица 4. Форма изменения протокола

Например, Ethereum принимает пожертвования для финансирования разработок, а также обновляет сеть используя ПО от разработчиков, финансируемых через гранты. Разные DLT системы используют разные методы для обновления сети.

Уровень сети

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

Процесс коммуникации

Процесс передачи данных между участниками DLT системы.

Доступ к сети

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

  • Неограниченный доступ – любой пользователь может свободно подключиться / отключиться в любой момент времени;
  • Ограниченный доступ – только определенные пользователи могут подключиться к сети, обычно это контролируется назначенным субъектом.

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

Участники сети, также могут получить непрямой доступ к сети, запустив «легкие клиенты», которые запрашивают данные у полных узлов, подключившись через специальную службу (API). Обычно, участники получают прямой доступ к сети, запуская полные узлы: они считаются «элитой» с большим набором прав, поскольку они могут отправлять / проверять и передавать данные записей.

Форма доступа к сети Таблица 5.

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

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

Поскольку идентификация является экзогенным (т.е «реальным») свойством, DLT-система не может предотвращать данные атаки, она должна полагаться на внешних участников (система сертификации) или механизмов, снижающих вероятность атаки (PoW / PoS).

Отправка данных

Данные могут быть необработанными / неформатированными или стандартизированными под определенный формат (например, в форме транзакции или записи). Передача данных – это процесс распространения данных на подключенные узлы. В последнем случае, распространение данных, как правило, ограничивается участниками сделки. Данные могут передаваться на каждую ноду (универсальная диффузия), или только определенному подмножеству узлов (многоканальная диффузия). Это позволяет создавать «канал» для передачи данных, обычно под этим подразумевается шардинг / Lightning Network.

Ранние DLT-системы (например, Bitcoin, Litecoin) используют универсальную модель распространения данных, которая по-прежнему остается самым популярным методом распространения данных.

В целях соблюдения анонимности и приватности для компаний, в более поздних системах реализована многоканальная модель диффузии (например, Hyperledger Fabric, Corda). Другие системы, такие как Cosmos, предназначены для того, чтобы выступать в роли «Хабов», чтобы независимые DLT-системы могли быть связаны между собой посредством шардинга.

Форма отправки данных Таблица 6.

Это значительно отличается от систем с глобальной диффузией данных, поскольку каждый отдельный узел должен прийти к консенсусу относительно глобального состояния системы («глобальный» консенсус); невозможность достижения консенсуса некоторых узлов, может привести к их отключению, или созданию форка. Примером многоканальной диффузии данных является то, что не все участники сети должны участвовать в достижении консенсуса в отношении состояния канала: только участники канала должны достичь согласованности над данными, хранящимися в этом канале («локальный» консенсус).

Создание транзакции

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

Процесс обработки транзакций

Транзакция считается (предварительно) действительной после добавления в список («подтверждённых»), что приводит к выполнению инструкций, встроенных в транзакцию. Обработка транзакций описывает набор действий, необходимых для добавления неподтверждённой транзакции в список подтвержденных. Однако, одного подтверждения недостаточно, чтобы эта транзакция стала основой для последующих операций; прежде чем выходы (outputs) транзакции могут быть использованы системой.

Обработка транзакций в DLT-системе Рисунок 1.

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

Кандидат на запись

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

Формы создания записей Таблица 6.

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

Алгоритмы с неограниченным уровнем сложности измеряются в ресурсах, которые необходимы для достижения консенсуса. Алгоритм консенсуса может быть классифицирован в соответствии с его уровнем сложности (электрические / денежные затраты). Совсем наоборот работают другие алгоритмы (например, задача византийский генералов / BFT) не требуют значительных вычислительных затрат и имеют ограниченную сложность. Например, в случае вычисления PoW Bitcoin, трудность поиска верного решения возрастает по мере увеличения сложности хеширования данных.

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

Разрешение конфликтов

Конфликт может быть вызван по нескольким причинам:

  1. участники расходятся во мнении, какая версия протокола является актуальной;
  2. участники расходятся во мнении, проверенных транзакций.

В случае возникновения ситуации первого пункта в сети Bitcoin, сеть выбирает самую длинную цепочку блоков, как действительную, а более короткую игнорирует. В Tezos определяется действительность блока с другим по «весу блока», весом здесь является количество «одобрений» от валидаторов, которые он получает случайный образом от стейкеров.

Любой алгоритм консенсуса несет в себе ряд компромиссов

Таблица 7. Формы мотивации обработки транзакций

Валидация

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

Проверка транзакции

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

Такие атаки позволяют проводить недействительные транзакции и записывать их как валидные. Атака 51% это случай, когда участник или несколько участников объединяют свои вычислительные мощности (голоса) и обрабатывают транзакции в сети быстрее, чем вся остальная часть протокола. Особенно уязвимой является система, использующая PoW

Проверка записей

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

Запись транзакции

Необратимость записи может иметь вероятностный характер (например, система на основе PoW, в которой непрактично вычислят заново все записанные транзакции), или системы, которые включают в себя «контрольные точки», которые должны быть присвоены к каждой транзакции. Подтвержденная транзакция / запись, не обязательно является необратимой. Предварительно-подтвержденные записи становятся неизменяемыми после преодоления переходного состояния от «предварительно-подтвержденных» к «подтвержденным». Подтвержденные записи могут называться неизменяемыми, но те записи, которые были «предварительно-подтверждены», могут быть отменены.

Обработка транзакций в DLT-системах Рисунок 2.

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

Далее транзакции будут проверяться в соответствии с алгоритмом консенсуса, чтобы предложить эти транзакции всем остальным участникам сети. На этапе обработки транзакции, узлы случайным образом выбирают неподтвержденные транзакции из своего mempool и, затем объединяют их вместе в список «предварительно-одобренных» транзакций. Списки с транзакциями каждого узла в итоге отправляются в единый, самый главный список подтвержденных транзакций и будут считаться выполненными. Узлы будут просматривать полученные транзакции и их содержимое, если транзакция проходит проверку, транзакция добавляется в список узла.

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

В случае этой атаки, узел создает альтернативную цепочку со своими личными транзакциями (которые хранятся только у него), эти транзакции не появляются в сети, а сразу отправляются узлам на этап «урегулирования», чтобы заставить другие узлы заменить их на его локальные транзакции. Некоторые системы реализуют систему «контрольных точек», чтобы ограничить возможность атак типа «long-range». В результате контрольных точек, снижается «досягаемость» атаки. «Контрольные точки» — это блоки, которые никогда не будет отменены или заменены. Однако контрольные точки, повышают риск создания форка.

Свойства подтвержденных транзакций Таблица 8.

Уровень данных

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

Операции

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

Источники данных

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

Внешние источники ввода, с другой стороны, являются результатом ввода из других систем, которые взаимодействуют с протоколом, но которые в принципе отделены от базовой платформы (т.е они являются зависимой или взаимодействующей). Мы определяем внутренние источники ввода как любую запись или транзакцию, созданную пользователем или из-за результата взаимодействия пользователя с протоколом. Гибридные протоколы, позволяют пользователям передавать транзакции используя «платежные каналы – state channel» в любое время, однако разработка этих методов все еще находится на начальной стадии.

Формы ввода данных Таблица 9.

Программно-исполняемые транзакции

Некоторые изменения в системе происходят из-за выполнения инструкций программного кода. Не все изменения уровня данных являются прямым результатом внутренних или внешних входных данных. При выполнении заложенного программного кода, в протоколе происходит изменение состояния сети, например, происходит транзакция, которая записывается в список подтвержденных. Ярким примером являются смарт-контракты. Например, Bitcoin Script, он работает на просто языке сценариев, который позволяет создавать ограниченно-простые программы. Некоторые DLT-системы, поддерживают только язык сценариев (скриптовый). Ethereum (Solidity), Tezos (Michelson) и EOS (WebAssembly) – эти системы поддерживают полные по Тьюрингу языки программирования для разработки сложных смарт-контрактов, а Bitcoin и Monero, используют язык сценариев, который позволяет проводить ограниченные операции. Такие системы носят название – Stateless.

Свойства программно-выполняемых транзакций Таблица 10.

Фактическое выполнение вычислений

Как правило, местом выполнения может внутри сети – on-chain или off-chain (за пределами сети). Место выполнения программы, определяет, где происходят вычисления. Эта среда может варьироваться от простой виртуальной машины, как сценарный язык, так и быть сложной (EVM – виртуальная машина Ethereum), которая обеспечивает выполнение программ полных по Тьюрингу. On-chain вычисления выполняются у каждого узла. Смарт-контракты в on-chain запускаются каждым узлом в сети и, поэтому часто называются «само исполняющимися».

Событие, которое запускает программный код, происходит в on-chain, а вычисления происходят в другой системе, не нагружая основную сеть. Off-chain вычисления, выполняются в среде, которые являются внешними по отношению к протоколу. Или, например, Cosmos, где основная сеть служит «центром», но сами вычисления происходят в дочерних сетях. Также, существует гибридная (Hybrid) система запуска приложений, например, Plasma в Ethereum.

Свойства выполнения программно-выполняемых транзакций Таблица 11.

Компонент журнала

Ссылки

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

Виды ссылок

Существует четыре различных типов исходных данных: эндогенные, экзогенные, гибридные и самореферентные данные.

Например, в Bitcoin, одна эндогенная ссылочная переменная используется для отслеживания количества биткойнов, которые пользователи имел в данный момент времени. Эндогенные (внутренние) ссылки, относятся к данным, которые отслеживают информацию о переменных, которые являются «родными» для системы. Экзогенная (внешняя) ссылка, относится к данными, которые отслеживают информацию о переменных, существующих вне системы. Эта внутренняя переменная обновляется по мере того, как пользователь отправляет и получает биткойны на другие адреса. Еще существует четвертый тип, который не является ни эндогенным, ни экзогенным и не гибридным: это нейтральный или пустой тип данных – это самореферентная ссылка. Гибридная ссылка относится к данным, которые имеют как эндогенные, так и экзогенные характеристики. Хотя смарт-контракту может потребоваться информация о внешних или внутренних системных переменных, сам код не имеет внутренней ссылки на что-либо вне себя («пустая ссылка»). Например, смарт-контракт – это просто фрагмент кода, который может выполняться при выполнении определенных условий.

Типы ссылок и их значение Таблица 12.

Вывод

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

Теги
Показать больше

Похожие статьи

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть