Фреймворк: Анализ Систем Трр

Данная работа направлена на определение того, является ли анализируемый объект ТРР-системой.

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

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

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

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

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

Зависимость от других протоколов зависит от границ анализируемого проекта.

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

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



Программный код Код может быть основан на существующем фреймворке или написан с нуля.

Наиболее популярные фреймворки — это базы кода систем с открытым исходным кодом (Биткойн/Эфириум).

Существуют также базы с закрытым исходным кодом для закрытых платформ, предоставляемые такими проектами, как Digital Asset/Clearmatics и SETL. Таблица 2. Код программы



Определение правил Внедрение правил относится к определению набора правил, по которым должна работать система ТРР.

Этот процесс может выполняться разными участниками и индивидуален для конкретной ТРР.

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

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

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

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

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

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

Таблица 3. Протокол управления



Протокольный контроль принимает множество форм и часто нечетко определен.

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

Чаще всего они похожи на процессы управления трафиком с открытым исходным кодом.

Примером обсуждения изменений протокола может быть общение разработчиков в чате/GitHub/конференции.

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

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

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

Этот тип правительства делит протокол на две стороны: «элиту» и «обычных» пользователей, приобретая характеристики иерархической системы: федерация, демократия и плутократия.

Ончейн-менеджмент подразумевает включение функций управления на уровне данных.

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

Для систем DLT был разработан разнообразный набор схем голосования по цепочке: от барометров настроений сообщества до референдумов.

Однако функции управления внутри сети обычно являются лишь дополнением к другим формам управления.

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

Например, Ethereum принимает пожертвования на финансирование разработки, а также обновляет сеть с помощью программного обеспечения от разработчиков, финансируемого за счет грантов.

Сетевой уровень

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

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

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

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

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

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

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



Как правило, чем более открыта система, тем более восприимчива она к атакам.

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

Атака Сивиллы — это тип атаки, при которой злоумышленник получает доступ или скрывает изменения в протоколе, создавая несколько ложных идентификаторов.

Отправка данных Передача данных — это процесс распространения данных по подключенным узлам.

Данные могут быть необработанными/неформатированными или стандартизированными до определенного формата (например, в форме транзакции или записи).

Данные могут передаваться каждому узлу (универсальная диффузия) или только определенному подмножеству узлов (многоканальная диффузия).

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

Это позволяет создать «канал» для передачи данных, обычно это означает шардинг/Lightning Network.

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

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

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



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

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

Создание транзакции Процесс создания транзакции содержит набор инструкций, которые будут выполнены после добавления транзакции в сеть.

Создание транзакций может быть неограниченным (т.е.

доступным для всех) или ограниченным для некоторых участников.

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

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

Процесс обработки транзакции Обработка транзакций описывает набор действий, необходимых для добавления неподтвержденной транзакции в список подтвержденных.

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

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

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



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

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

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

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



Поскольку записи подлежат консенсусу, они должны соответствовать правилам протокола.

Во-первых, они должны быть правильно отформатированы и не содержать невалидных или недействительных транзакций.

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

Алгоритм консенсуса можно классифицировать по уровню сложности (электрические/денежные затраты).

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

Например, в случае расчетов Bitcoin PoW сложность поиска правильного решения возрастает по мере увеличения сложности хеширования данных.

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

Открытые системы должны иметь алгоритм, снижающий вероятность атаки Сивиллы.

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

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

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

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

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

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

Сюда входит: проверка отправляемых транзакций/проверка записываемых данных/проверка общего состояния сети.

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

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

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

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

Обычно такие условия выполняются смарт-контрактами.

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

Такие атаки позволяют выполнять недействительные транзакции и фиксировать их как действительные.

Система, использующая PoW, особенно уязвима.

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

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

Запись транзакции Подтвержденная транзакция/запись не обязательно является необратимой.

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

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

Предварительно зафиксированные записи становятся неизменяемыми после прохождения состояния перехода от «предварительно зафиксированного» к «зафиксированному».

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



На рисунке 2 представлено схематическое описание процесса, происходящего при обработке транзакции.

Сначала пользователь создает транзакцию и отправляет ее в сеть.

Каждый узел проверяет, соответствует ли транзакция правилам протокола.

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

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

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

Ноды будут просматривать полученные транзакции и их содержимое.

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

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

Время обработки транзакций на этапе «Расчет» зависит от настроек конкретной системы.

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

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

Пока сделки находятся на стадии «расчет», их нельзя считать «завершенными».

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

Некоторые системы реализуют систему контрольных точек для ограничения возможности атак на большие расстояния.

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

«Контрольные точки» — это блоки, которые никогда не будут отменены или заменены.

В результате чекпоинтов снижается «дальность» атаки.

Однако контрольно-пропускные пункты увеличивают риск создания форка.

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

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

Сетевой уровень реализует основные принципы протокола.

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

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

Источники данных Процесс ввода относится к источнику или методу получения данных для протокола.

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

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

они зависимы или совместимы).

Гибридные протоколы позволяют пользователям передавать транзакции с использованием «государственного канала» в любое время, однако разработка этих методов все еще находится на ранних стадиях.

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



Программно-исполняемые транзакции Не все изменения уровня данных являются прямым результатом внутренних или внешних входных данных.

Некоторые изменения в системе происходят вследствие выполнения инструкций программного кода.

Яркий пример — смарт-контракты.

При исполнении встроенного программного кода в протоколе происходит изменение состояния сети, например, происходит транзакция, которая записывается в список подтвержденных.

Некоторые системы DLT поддерживают только язык сценариев.

Например, Bitcoin Script, он работает просто на языке сценариев, который позволяет создавать ограниченно простые программы.

Такие системы называются Stateless. Ethereum (Solidity), Tezos (Michelson) и EOS (WebAssembly) поддерживают полные по Тьюрингу языки программирования для разработки сложных смарт-контрактов, в то время как Биткойн и Monero используют язык сценариев, допускающий ограниченные операции.

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



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

Как правило, место исполнения может находиться внутри сети — ончейн или оффчейн (вне сети).

Внутрисетевые вычисления выполняются на каждом узле.

Эта среда может варьироваться от простой виртуальной машины, вроде языка сценариев, до сложной (EVM — Ethereum Virtual Machine), обеспечивающей выполнение программ, полных по Тьюрингу.

Ончейновые смарт-контракты выполняются каждым узлом в сети и поэтому их часто называют «самоисполняющимися».

Вычисления вне сети выполняются во внешней среде по отношению к протоколу.

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

Также существует Гибридная система запуска приложений, например Plasma в Ethereum. Или, например, «Космос», где «центром» служит основная сеть, а сами вычисления происходят в дочерних сетях.

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

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

Однако журнал – это абстракция.

Все процессы, происходящие в системе DLT, принадлежат определенному протоколу.

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

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

Поэтому понятие журнала – это абстракция.

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

Эндогенные (внутренние) ссылки относятся к данным, которые отслеживают информацию о переменных, которые являются «родными» для системы.

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

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

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

Гибридная связь относится к данным, которые имеют как эндогенные, так и экзогенные характеристики.

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

Например, смарт-контракт — это просто фрагмент кода, который может быть выполнен при выполнении определенных условий.

Хотя смарт-контракт может требовать информацию о внешних или внутренних системных переменных, сам код не имеет внутренней ссылки ни на что вне себя («нулевая ссылка»).

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

Заключение

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

Теги: #блокчейн #Децентрализованные сети #Криптовалюты #Распределенные системы #анализ #децентрализация #dlt

• Какие Хитрые Способы Нарушения Корпоративного Соглашения Встречались Российским Инвесторам?

  19 Oct, 24

• Экс-Глава «Билайна» Михаил Слободин Арестован Заочно И Объявлен В Международный Розыск

  19 Oct, 24

• Двумерный Дуэт: Создание Гетероструктур Борофен-Графен

  19 Oct, 24

• Отображать Иерархические Данные В Виде Списка С Возможностью Поиска.

  19 Oct, 24

• Подход К Обработке Онлайн-Анализа

  19 Oct, 24

• Проект Создания Федерального Каталога Объектов Авторского Права Не Получил Полного Одобрения Экспертной Группы

  19 Oct, 24

• Стажировка В Google. Еще Один Взгляд

  19 Oct, 24

• Повседневная Жизнь Тестировщика, Или При Чем Тут Пирамида Маслоу

  19 Oct, 24

• Андроид Лаунчеры. Перезагрузка Идеи

  19 Oct, 24

• Распознавание Лиц Polarrose: Еще Один Пример Бионического Программного Обеспечения

  19 Oct, 24