Перевод Обзор архитектуры Tari

Тема в разделе "Статьи", создана пользователем Mr. Pickles, 27 ноя 2018.

  1. Mr. Pickles

    Команда форума Модератор Редактор

    Регистрация:
    11 сен 2017
    Сообщения:
    303
    Симпатии:
    108
    Задача, о которой необходимо помнить

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

    Базовая монета Tari

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

    Требования к монете Bitcoin

    В частности, в виду того, что монета Tari во многих смыслах играет роль денег, вот характеристики, которыми ДОЛЖНА ОБЛАДАТЬ базовая монета:
    • безопасность;
    • децентрализованность;
    • устойчивость к цензуре (контролю);
    • анонимность.
    Кроме того, БЫЛО БЫ ХОРОШО, если бы базовая монета имела в том числе следующие характеристики (но не в ущерб основным):
    • скорость;
    • масштабируемость.
    Цифровые активы

    Сеть Tari будет использоваться для создания и управления цифровыми активами. Эти цифровые активы будут определять и содержать токены активов. Например, в контексте продажи и покупки билетов актив одного события будет содержать множество токенов билетов. Токены билетов будут иметь определённое состояние, то есть указание текущего владельца, а также был токен выкуплен или нет.

    Сеть Tari должна осуществлять управление и исполнять инструкции по активам, включая создание активов, передачу токенов и изменение их состояния.

    Критическими ОБЯЗАТЕЛЬНЫМИ требованиями к цифровым активам и их токенам являются:
    • безопасность;
    • скорость (возможно, порядка 1000 TPS);
    • масштабируемость (представьте миллионы игровых предметов вместе с их метаданными).
    Наличие следующих характеристик было бы крайне желательно, так как они повысили бы ценность предложения протокола Tari:
    • опциональная анонимность (в зависимости от нужд эмитента (источника) актива);
    • конфигурируемая децентрализация (в зависимости от нужд эмитента актива). Например, определённый эмитент может пожелать, чтобы только его узел (или узлы) могли выполнять инструкции по активам (уполномоченная система), в то время как другие эмитенты могут предпочесть полностью децентрализованное управление своими активами (без распределения полномочий).
    Два уровня

    Эти широкие требования некоторым образом являются взаимоисключающими. То есть существует некая трилемма, согласно которой сеть в идеале должна быть:
    • быстрой;
    • дешёвой;
    • безопасной,
    однако реализовать можно два параметра максимум [1].В связи с этим представляется разумным разбить сеть Tari на два уровня:
    • базовый уровень, обеспечивающий публичную регистрацию транзакций с базовыми монетами, защищённых доказательством работы (обеспечение максимальной безопасности);
    • второй уровень, на котором осуществляется управление состоянием цифровых активов, и который был бы быстрым и дешёвым, но при необходимости опирался бы на безопасность, обеспечиваемую первым уровнем.
    Базовый уровень

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

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

    Если говорить о свойствах, которые было бы хорошо иметь, можно проделать долгий путь, прежде чем удастся добиться масштабируемости блокчейна:
    • для начала путём сохранения такого большого количества данных вне блокчейна;
    • используя новые методы сжатия, такие как cut-through (прорезание);
    • путём применения протокола эффективного использования пространства.
    С точки зрения анонимности также есть несколько опций:
    • кольцевые подписи и CT (Monero);
    • ZK-Snarks (ZCash).
    • конфиденциальные транзакции (MimbleWimble).
    Если взвесить все за и против, то окажется, что MimbleWimble обеспечивает большую отдачу в плане желаемых характеристик на базовом уровне. Как сказал @fluffypony: «MW — это самый практичный, масштабируемый протокол «базового уровня» из всех нам известных».

    Доказательство работы

    В случае с Tari есть несколько механизмов доказательства работы (PoW):
    • Реализация существующего механизма PoW. Но это плохая идея, так как новая криптовалюта, использующая не уникальный алгоритм майнинга, будет невероятно уязвима для 51% майнеров, предназначенных для других криптовалют, использующих тот же алгоритм. Bitcoin Gold и Verge уже испытали это, и когда подобное произойдёт с Bitcoin Cash — лишь вопрос времени.
    • Реализация уникального алгоритма PoW. Это рискованный подход, который практически нарушает правило разработки криптовалют №1: «Никогда не прокручивай собственную криптовалюту».
    • Реализация гибридного алгоритма PoW. У этого варианта есть ряд собственных недостатков.
    • Совместный майнинг. Этот подход тоже не без рисков, но при его использовании наилучшим образом достигается компромисс с точки зрения самонастройки сети, а также с самого начала обеспечивается высокий уровень безопасности. Учитывая отношение Tari к Monero, стратегия совместного с Monero майнинга видится наиболее благоразумным вариантом.
    Второй уровень

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

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

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

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

    Варианты оверлейной сети:
    • Каждый узел поддерживает список одноранговых узлов, но совсем немного информации о них (примером может служить Bitcoin). Возможности узла выясняются путём опроса одноранговых узлов.
    • Каждый узел отслеживает пакеты сети и, возможно, некоторые метаданные (например, подобная DHT Kademlia).
    • Каждый узел пытается поддерживать полный список одноранговых узлов наряду с информацией о том, для какого DA каждый узел имеет права на обработку инструкций.
    • Запросы определённого DA направляются напрямую узлу (узлам), который отслеживает его. (Lightning-сеть полностью строит топологию канальной сети).
    Варианты консенсуса:
    • Полный блокчейн второго уровня. Возможно, это будет уже перегиб, и едва ли это позволит достичь целей, связанных со скоростью и затратами, которые нам хотелось бы реализовать. В частности, если это будет блокчейн, использующий доказательство работы.
    • Реализация State Channel сети (сеть на базе каналов состояний). Такие идеи, как Plasma и т. д., интересны, но крайне сложны. И эта сложность повышает площадь атаки системы. Также сеть становится более уязвимой к отказам и ошибкам. Пожалуй, есть более простые и элегантные решения этой проблемы.
    • «Разрешённые» DA. В рамках этой модели эмитенты DA должны назвать (доверенные) узлы, чтобы использовать свои DA для них. Указание множества узлов в большей степени защищает от DoS атак, чем от агентов Byzantine. Контракты с обязательством выполнения между эмитентом и узлами на базовом уровне могут обеспечить дополнительный стимул для поддержания времени безотказной работы и честности (хотя структура стимула должна быть тщательно продумана во избежание координированных атак со стороны жуликов, выпускающих мошеннические активы, использующих такие же мошеннические узлы).
    • Направленные ациклические графы (DAG). Реализация DAG, подобных Spectre, PARSEC, HoneyBadgerBFT и т. д., может оказаться интересной возможностью. DAG потенциально могут обеспечить высокую скорость и масштабируемость, а также обеспечить реальную устойчивость к BFT, что, в свою очередь, позволит реализовать действительно не требующий полномочий (разрешения) второй уровень.
    Другие средства в нашей обойме / возможные характеристики:
    • узлы 2-го уровня используют публичные/приватные ключи для самоидентификации;
    • узлы 2-го уровня размещают контракты с обязательствами по выполнению, согласно которым они будут считаться нерабочими, если будут уличены в обмане;
    • узлы 2-го уровня могут быть застрахованы от такого риска за счёт работы узла и зарабатывания (незначительной) комиссии за выполнение инструкции к каждому цифровому активу (создание и модификацию);

    • эмитенты активов могут указывать те узлы, которые будут выполнять их инструкции DA (уполномоченные узлы). Это соответствует принципам системы с правом доступа. Такие узлы могут быть доверенными, эмитенты смогут сами использовать их или же будут знать, кто делает это;
    • эмитенты активов могут также выпускать их в «не требующем разрешения» режиме, возможно, используя ряд критериев приемлемости (например, минимальный размер контракта с обязательствами по выполнению). Понадобится использование подходящего алгоритма консенсуса, который позволит успешно использовать этот режим;
    • в нашем распоряжении есть (не) централизованный орган управления — базовый уровень! Потенциально его можно использовать в качестве регистратора узлов 2-го уровня, «нотариуса» для контрактов с обязательством по выполнению, а также арбитра для решения возможных споров.
    Краткие выводы

    В таблице 1 кратко изложены характеристики уровней сети Tari.

    ХарактеристикаОсновной слойДополнительный слой
    СкоростьМедленнаяБыстрая
    МасштабируемостьСредняяОчень высокая
    Уровень безопасностиВысокийСредний (высокий со сбоями)
    Уровень децентрализацииВысокийОт низкого до среднего
    Обработка монеты tx (Tari)ЕстьНет
    Обработка инструкций цифровых активовТолько контрольные точкиЕсть
    Темы для дальнейшего рассмотрения
    • Конфигурируемость анонимности цифровых активов. Как могут применяться анонимные DA в публичной сети?
    • Какая из конфигураций оверлейной сети и алгоритма консенсуса будет самой простой, но будет при этом работать?
    • Необходимо начать продумывать способы взаимодействия 2-го и базового уровней.
    • Долгосрочные и краткосрочные цифровые активы. Как это влияет на модель стимулирования / финансирования?
    Отказ от ответственности

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

    Источник: RFC documents for the Tari protocol

    Перевод:
    Mr. Pickles (@v1docq47)
    Редактирование:
    Agent LvM (@LvMi4)
    Коррекция:
    Kukima (@Kukima)
     
    #1 Mr. Pickles, 27 ноя 2018
    Последнее редактирование: 27 ноя 2018
    Дмитрий, LeD XIII и TheFuzzStone нравится это.
  2. Дмитрий

    Дмитрий Piconero

    Регистрация:
    14 ноя 2017
    Сообщения:
    9
    Симпатии:
    2
    Очень интересная статья!
     
  • О нас

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