Белая бумага IOST

IOST Whitepaper

IOST 18 апреля 2018 г.

IOST: безопасная, масштабируемая экосистема следующего поколения для онлайн-сервисов

Интернет Сервис Фонд

31 декабря 2017 г.

Аннотация

Несмотря на недавний ажиотаж на рынке криптовалют, базовая технология блокчейна все еще находится на ранней стадии и далека от массового внедрения. Одна из общепризнанных проблем с современными технологиями блокчейна — это масштабируемость. Без возможности быстрой обработки больших объемов транзакций такие сервисы, как Facebook, Amazon и биржи цифровых активов, практически невозможно развернуть на блокчейне.

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

Эта работа делает следующие вклады. Он вводит:

  1. Эффективное распределенное разделение (EDS) — инновационная схема разделения, которая делает фрагменты достаточно большими и устойчивыми к смещению благодаря комбинации механизма очистки случайности клиент-сервер и выбора лидера посредством криптографической сортировки.
  2. TransEpoch — безопасное назначение валидаторов в сегменты во время переходов эпох при сохранении работоспособности транзакций.
  3. Atomix — новый двухэтапный межатомный атомный протокол фиксации, который гарантирует атомарность транзакций в византийских условиях.
  4. Proof-of-Believability (PoB) — революционный протокол византийского консенсуса с подходом Believable-First, который гарантирует безопасность и жизнеспособность системы, в то же время в значительной степени максимизируя пропускную способность транзакции за счет размера один шард.
  5. Micro State Block (MSB) — новый механизм, позволяющий минимизировать затраты на хранение и загрузку для валидаторов.

Примечание : IOS находится в стадии разработки. Ведутся активные исследования, и новые версии этого документа будут обновляться на http://iost.io . Для комментариев и предложений, свяжитесь с нами по team@iost.io .

Оглавление

  • Фон
  • Связанных с работой
    • Репликация конечного автомата
    • Биткойн и Доказательство Работы
    • Корректор Proof-of-Stake
  • Блокчейн Архитектура
  • Протокол распределенной случайности
  • Эффективный распределенный шардинг
    • Алгоритм — выборы лидера с резервным протоколом
    • Анализ
  • Работоспособность во время эпохальных переходов
    • Алгоритм назначения перехода от узла к участку — TransEpoch
    • Анализ
  • Транзакции между шардами
  • Консенсусный механизм
    • Жетоны и мотивации
    • Proof-оф-правдоподобности
  • Обрезка блокчейна
    • Алгоритм — протокол генерации MSB
    • Анализ
  • РЕКОМЕНДАЦИИ

Фон

Чрезмерные комиссионные, нарушения конфиденциальности, мошенничество и цензура — это общие проблемы, с которыми сталкиваются при ежедневном общении с централизованными поставщиками онлайн-услуг. Учитывая эти общепризнанные проблемы с централизацией, с момента запуска Bitcoin [15] в 2008 году был разработан широкий спектр технологий блокчейнов, пытающихся решить эти проблемы. Специализированные проекты, такие как SteemIt [29], Bitshares [30] и Syscoin [ 21], а также более универсальные проекты, такие как Ethereum [28] и EOS [11], являются некоторыми из многих примеров. Однако большинство этих попыток либо слишком специализированы для определенных приложений, либо обременены низкой пропускной способностью транзакций. Из-за этих ограничений в гибкости и пропускной способности транзакций разработчики и предприятия не могут использовать тяжелые сервисы, такие как Facebook или Amazon, в блокчейне, не говоря уже о чем-то более сложном, например, обмениваться цифровыми активами.

Суть проблемы масштабируемости лежит в фундаментальном дизайне этих существующих технологий цепочки блоков — их согласованных протоколах и архитектурах цепочки блоков. Большинство существующих технологий блокчейна сталкиваются с двумя основными проблемами при расширении: a) каждый полный узел должен хранить всю бухгалтерскую книгу, чтобы участвовать; б) каждый участвующий узел в сети обязан обрабатывать каждую транзакцию. Поскольку все участвующие узлы, по сути, выполняют одну и ту же работу, количество транзакций, которые может обработать система, не будет превышать количество транзакций для одного узла. Более того, растущий размер блокчейна увеличивает требования и стоимость пространства хранения, пропускной способности и вычислительных ресурсов для узла, чтобы в полной мере участвовать в сети. Растущие затраты на майнинг неизбежно приведут к тому, что участие в сети станет привилегией для немногих, что приведет нас прямо к проблеме централизации.

IOS предназначен для заполнения пустоты. В нашем видении IOS — это технология блокчейна следующего поколения, которая обеспечивает сетевую инфраструктуру для поддержки сервис-ориентированной экосистемы. Платформа IOS не только предоставляет своим пользователям полностью децентрализованный способ обмена онлайн-услугами и цифровыми товарами, но также позволяет разработчикам развертывать крупномасштабные приложения dApp с возможностью поддержки огромного числа пользователей. Благодаря ряду новаторских инноваций, таких как «Эффективное распределенное разбиение» («EDS») и консенсусный подход «Believable-First»), мы можем значительно увеличить пропускную способность системы, одновременно гарантируя безопасность.

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

С EDS IOS также упакован в очень мощный арсенал технологий, которые позволяют развертывать крупномасштабные приложения с высокой производительностью и гибкостью. Это позволяет разработчикам создавать широкий спектр продуктов: от аналогов традиционных монополистических поставщиков онлайн-услуг до совершенно новых бизнес-моделей, которые раньше считались невозможными. Следует признать, что запуск таких служб может быть довольно дорогостоящим, если размер сети IOS относительно невелик. Однако с увеличением количества узлов и ресурсов в сети стоимость запуска таких масштабных dApps может быть значительно снижена. Кроме того, есть много преимуществ, в том числе: предотвращение кибератак, высокий уровень безопасности данных и неизменность свойства.

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

Связанных с работой

Репликация конечного автомата

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

  1. Безопасность , т. Е. Все серверы в сети имеют одинаковую запись транзакций;
  2. Жизнеспособность , т. Е. Транзакции клиентов, представляются и документируются в журнале быстро.

Существует два принципиально различных способа достижения репликации конечного автомата: консенсус в классическом стиле и консенсус в стиле блокчейна [18]. Консенсус в классическом стиле обычно применяет алгоритмы, подобные Paxos, и используется в разрешенной настройке, где априорно известны узлы консенсуса, известные системе. Примером этого приложения могут служить серверы таких компаний-разработчиков программного обеспечения, как Amazon, где их серверы совместно используют классический способ репликации и хранения информации, а классический алгоритм устанавливает основы для формирования консенсуса в отношении порядка их данных.

Биткойн и Доказательство Работы

Сатоши Накамото был первым, кто представил Биткойн в качестве решения для достижения консенсуса в настройках без прав доступа, например, любой узел может свободно присоединяться и выходить из сети без предварительного знания узлов консенсуса. Сеть, лежащая в основе Биткойна, блокчейн улучшает масштаб распределенных систем без участия человека, предоставляя экономические стимулы для серверов, называемых майнерами в настройках Биткойна. Майнеры в сети Биткойн формируют консенсус, вычисляя частичные коллизии хешей с определенным уровнем сложности. Цепочка с наибольшей совокупной сложностью будет признана другими узлами как результат консенсуса. Это решение называется Proof-of-Work (PoW), которое по сути состоит в том, чтобы все узлы в сети выдавали свои вычислительные мощности в качестве способа получения стимулов и, таким образом, определяли порядок транзакций для всей системы. Преимущество PoW заключается в его способности защищаться от атаки Сибиллы в условиях без разрешения [15]. Несмотря на прогресс в масштабах и безопасности, у Биткойна есть несколько основных недостатков: (1) в отличие от других современных криптовалют, подтверждение транзакции в соответствии с ее конфигурацией занимает более часа; (2) трудно разрабатывать различные приложения в сети Биткойн; (3) механизм консенсуса тратит слишком много энергии, т. Е. Он стоит более двух миллионов долларов в день на электроэнергию. Что еще более важно, более ранние работы показывают, что блокчейн в биткойн-стиле должен иметь достаточно большой интервал для сохранения безопасности [16] [17]. Поэтому Биткойн не будет хорошей заменой текущей централизованной системы для поддержки повседневных приложений и большого объема транзакций.

Корректор Proof-of-Stake

Концепция Proof-of-Stake впервые обсуждалась на онлайн-форуме о цепочках блоков [31] и была принята несколькими криптовалютами, такими как PPcoin [22], PeerCoins [23] и Nxt [5]. Идея PoS — это, по сути, один голос на единицу доли, так что для каждого валидатора, владеющего большим количеством доли, будет выше право голоса. Следовательно, валидаторы не имеют экономического стимула наносить ущерб всей сети блокчейнов. Для атакующих цена атаки огромна, потому что они должны владеть большинством ставок. На ранних стадиях разработки механизм консенсуса Proof-of-Stake был известен тем, что был уязвим для атак «ничего на кону», когда серверы могли голосовать одновременно по нескольким блокам без какого-либо стимула к сближению, что наносило ущерб безопасности блокчейн Более поздняя работа решает проблему, используя слэшер [3], который предусматривает наказание за нарушение узлов. Многие другие работы также описываются как специальное приложение Proof-of-Stake [1–3,26] [12] [10]. Хотя PoS обеспечивает жизнеспособность реплицированного протокола конечного автомата, он все еще сталкивается с такими проблемами, как централизация и проблемы безопасности. Например, валидаторы, имеющие больше токенов, с большей вероятностью будут генерировать новые блоки и становиться богаче, что приведет к потенциальной проблеме централизации. Кроме того, предыдущая работа показывает, что протокол Proof-of-Stake может быть только доказуемо безопасным и надежно настроенным консенсусным протоколом, если его токен не обменивается слишком часто [19], что потенциально подразумевает наличие предельной пропускной способности для Proof-of- Делайте ставки, чтобы сохранить безопасность.

Блокчейн Архитектура

Инфраструктура IOSChain похожа на существующие хорошо известные цепочки блоков, такие как Bitcoin и Ethereum, где узлы распространяют данные по протоколу сплетен. Система делит свои данные и состояние на фрагменты. Каждый узел отвечает за один осколок системы. Неизрасходованные транзакции (UTXO) хранятся в памяти узлов в соответствующих сегментах. Это поднимает несколько новых проблем.

  • Как разделить систему на осколки.
  • Как достичь консенсуса в каждом осколке.
  • Как выполнять транзакции между шардами.

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

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

  • В Разделе 4 мы представляем Протокол распределенной случайности (DRP), который не поддается фальсификации и непредвзятости, когда соотношение вредоносных узлов ниже некоторого определенного предопределенного порога. Случайные числа, сгенерированные DRP, используются для разделения системы на осколки, назначения узлов разным осколкам и выбора лидеров в каждом осколке.
  • В Разделе 5 мы представляем Эффективное распределенное разбиение (EDS) — новую схему для формирования сегментов (подмножеств валидаторов для записи состояния и обработки транзакций), которые являются достаточно большими и устойчивыми к смещению, используя комбинацию DRP и основанную на VRF выборы лидера с помощью криптографической сортировки.
  • В Разделе 6 мы представляем TransEpoch — безопасный протокол назначения валидаторов-осколков во время переходов эпох при сохранении работоспособности системы.
  • В Разделе 7 мы представляем Atomix — новый двухэтапный межатомный межатомный протокол фиксации, который гарантирует атомарность транзакций в византийских условиях.
  • В разделе 8 мы представляем Proof-of-Believability (PoB) — новый византийский консенсусный протокол с подходом Believable-First, который гарантирует безопасность и жизнеспособность системы, в то же время в значительной степени максимизируя пропускную способность транзакций за счет размера один шард.
  • В Разделе 9 мы представляем Micro State Blocks (MSB) — новый механизм, позволяющий минимизировать затраты на хранение и загрузку для валидаторов.

Протокол распределенной случайности

Традиционный подход к генерации случайности, такой как механизм на основе Proof-of-Work [13] или надежный маяк [6], имеет вычислительные потери и проблемы с централизацией. Желательно использовать криптографические средства для генерации распределенных случайных чисел, что не только экономит ресурсы, но и обеспечивает надежную защиту.

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

  1. Он должен быть устойчивым к нечестным участникам (включая клиентов и серверы) в определенном соотношении. Чтобы быть более точным, система способна прогрессировать, когда доля нечестных участников ниже порогового значения, и при достижении прогресса ничего плохого не происходит.
  2. Конечное случайное число должно быть не поддающимся обработке и непредвзятым (равномерно случайным), за исключением незначительной вероятности.
  3. Нечестный участник не может попытаться несколько раз сгенерировать случайное число, благоприятствующее участнику, даже несколько нечестных участников вступают в сговор.
  4. Третьи стороны могут проверить, что выходные данные генерируются путем добросовестного выполнения протокола (т. Е. Убедиться, что он удовлетворяет всем вышеуказанным требованиям).

Чтобы выполнить эти требования, мы предлагаем использовать протокол клиент-сервер, называемый протокол распределенной случайности (DRP) [24], где клиент связывается с набором серверов, чтобы генерировать не поддаваемое равномерно случайное значение через неинтерактивный ноль — подтверждение знаний (NIZK) и публичное подтверждение секретного обмена (PVSS). В определенном прогоне протокола, до того, как протокол завершится и будет обнаружен окончательный случайный вывод, ни один объект в протоколе не сможет узнать какую-либо информацию об окончательном выводе, что гарантирует, что недобросовестный клиент не сможет выполнить несколько прогонов для генерации случайное число, которое благоприятствует нечестному клиенту.

Протокол состоит из двух этапов — генерация случайности и проверка случайности. Работает следующим образом. Первоначально клиент запускает протокол, отправляя всем серверам сообщение, включающее случайно сгенерированную сбалансированную группировку. На первом этапе каждый сервер генерирует случайное входное значение и создает общие ресурсы только для других членов той же группы, использующих PVSS. Получив зашифрованные общие ресурсы с NIZK [25] доказательствами со всех серверов (или тайм-аут), клиент выбирает подмножество входов сервера из каждой группы. Это позволяет клиенту фиксировать секрет каждой группы и вывод протокола. На втором этапе серверы дешифруют и отправляют свои общие ресурсы клиенту, как только клиент получает подпись на входные значения в глобальном прогоне коллективной подписи (CoSi) [25]. Затем клиент объединяет восстановленные групповые секреты, чтобы показать окончательный случайный результат.

Эффективный распределенный шардинг

С протоколом распределенной случайности (DRP), представленным выше, нетрудно реализовать эффективное распределенное разбиение. Тем не менее, протокол работает хорошо только без злонамеренных или сбойных узлов, поскольку он выполняется валидаторами коллективно. Поэтому мы должны разработать протоколы резервного копирования для сценариев с вредоносными или сбойными узлами. Чтобы победить эту проблему, мы предлагаем решение, которое использует Algorand [9] и Omniledger [8], чтобы выбрать лидера.

Алгоритм — выборы лидера с резервным протоколом


Входы:

  1. это счетчик просмотров
  2. валидатор
  3. это закрытый ключ для
  4. текущая эпоха
  5. это синхронность

Вывод: валидатор которая имеет действительную лотерею с минимальным значением для запуска DRP

  1. Для каждого каждый вычисляет лотерею используя Verifiable Random функцию с ее видом и закрытый ключ узла ,
  2. Затем на некоторое время Валидаторы сплетничают друг с другом. Каждый валидатор собирает 3 лучших лотереи с минимальной стоимостью в процессе сплетен.
  3. После истечения срока , валидаторы фиксируют действительную лотерею с минимальной стоимостью, которую они видели до сих пор.
  4. Валидатор, соответствующий действительной лотерее с минимальной стоимостью, выбирается в качестве лидера, а два других валидатора, соответствующих второй и третьей действительной лотерее с минимальной стоимостью, используются в качестве пула для резервных лидеров.
  5. Если выбранный валидатор успешно запускает DRP, он транслирует выходные данные всем другим валидаторам с его доказательством правильности.
  6. каждый можешь использовать вычислить перестановку и разделить результат на ведра с одинаковым размером, таким образом определяется отображение от узлов до осколков.
  7. После истечения срока если выбранный валидатор не запускает DRP, валидаторы помечают текущий прогон как неудачный и исключают этого лидера в оставшуюся часть эпохи , В этом случае резервный лидер будет использоваться для запуска DRP. Если два резервных лидера постоянно терпят неудачу, лотерея откатится к шагу 1, и весь протокол будет перезапущен.

Анализ

Механизм выбора лидера обеспечивает требуемые свойства, аналогичные описанным в разделе 4. Каждый валидатор может производить только одну действительную лотерею для каждого просмотра. в эпоху , Конструкция DRP обеспечивает масштабируемость. Так как закрытый ключ держится в секрете, вывод VRF непредсказуем. Учитывая нашу синхронизацию времени , лотерея будет видна всем другим валидаторам , Если вредоносные узлы выигрывают в лотерею, она не может выполнять произвольные действия — либо решите сотрудничать и запустить протокол DRP, либо решите провалить эпоху. Если случится какое-либо из злонамеренных / ненормальных случаев, вредоносные узлы будут исключены из участия в остальной части эпохи.

Работоспособность во время эпохальных переходов

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

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

Чтобы поддерживать полную работоспособность на переходных / неактивных фазах, мы используем метод выбора подмножества валидаторов, которые должны быть заменены и заменены новыми членами [8,24]. Это основано на подходе Omniledger [8]. Это позволяет оставшимся валидаторам продолжать предлагать услуги, пока вновь подключенные узлы загружают данные истории и запускаются. Мы представляем протокол назначения перехода между узлами и осколками — TransEpoch следующим образом.

Алгоритм назначения перехода от узла к участку — TransEpoch


Входы:

  1. общее количество узлов
  2. размер каждого осколка
  3. это размер пакета подкачки, т. е. количество валидаторов, которые будут выгружены в данный момент в заданную эпоху.

Выходы:

  1. Задавать
  2. За каждый осколок ,
  • Генерация двух семян а также используя сгенерированный случайный вывод из DRP.
  • использование а также чтобы получить перестановку а также и разделить узлы на сегменты размера , Таким образом, определяется узел для своп-пакетного сопоставления.
  • используется для текущих узлов и используется для вновь соединенных узлов.
  • Каждая партия ждет и затем начинает обмен.

Анализ

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

Транзакции между шардами

Механизм, который поддерживает межсегментные транзакции, является критически важным в системе, поскольку транзакции, вероятно, будут происходить между шардатами. Мы вводим протокол Atomix (Byomant Shard Atomic Commit), чтобы гарантировать атомарность кросс-шардов. Этот протокол предотвращает двойные расходы и сохраняет последовательность транзакций. Наш дизайн — это вариант алгоритма Omniledger. [8]

Сначала мы представляем Atomix в модели состояния UTXO. Предыдущая работа доказала, что Atomix может гарантировать, что умный контракт также поддерживается нашим механизмом транзакций между осями [27], если поддерживается модель UTXO.

В двух словах, когда происходит перекрестная транзакция между узлом a в сегменте A и узлом b в сегменте B, алгоритм выполняет следующие действия:


  1. Создайте TX внутри сегмента A и позвольте всем узлам проверять транзакцию.
  2. Если TX одобрен всеми узлами в сегменте A , транзакция регистрируется в блокчейне A. В то же время, клиент будет сплетничать о подтверждении принятия, чтобы подтвердить сделку, заблокировать фонд в UTXO и отправить его B.
    • Если TX отклонен узлами в A , фонд возвращается в.
  3. Блокчейн A передает TX блокчейну B и имеет узлы в сегменте получателя, проверяющие TX.
    • Если TX отклонен узлами в B , фонд возвращается в.
  4. Если TX будет одобрен всеми узлами в блокчейне B , фонд будет передан b .
    • Если TX отклонен всеми узлами, фонд возвращается в.

Консенсусный механизм

Жетоны и мотивации

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

  • Оплата : Оплата услуг и товаров, предоставляемых продавцами или другими участниками сообщества.
  • Комиссия : оплата валидаторам в качестве компенсации за выполнение интеллектуальных контрактов, обработку сообщений и транзакций и использование ресурсов, совместно используемых общей экосистемой, включая, помимо прочего, пространство хранения, вычислительную мощность и т. Д. Комиссионный сбор стимулирует валидаторов и предотвращает повреждение вредоносных пользователей. интересы сообщества через чрезмерное развертывание умных контрактов.
  • Правдоподобие : токены IOS будут использоваться для расчета оценок правдоподобности пользователей (будет объяснено в следующем разделе).

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

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

  • Не подлежит обмену: поскольку Servi не предназначен для обмена, Servi нельзя обменять или обменять каким-либо образом.
  • Саморазрушение : после проверки блока система автоматически очистит баланс Servi, принадлежащий валидатору. Таким образом, узлы с высокими показателями правдоподобия могут по очереди проверять блоки, чтобы обеспечить справедливый процесс генерации блоков.
  • Самостоятельная выдача : Servi будет создаваться и вноситься в учетные записи пользователей автоматически после определенных взносов, таких как предоставление услуг сообщества, оценка услуг, предоставляемых другими организациями, и / или внесение других специальных взносов.

Proof-оф-правдоподобности

Традиционные блокчейн-системы имеют компромисс между безопасностью и пропускной способностью, в зависимости от размера сегмента. Система с большим количеством маленьких осколков обеспечивает лучшую производительность, но обеспечивает меньшую устойчивость к плохим игрокам, и наоборот. Для преодоления компромисса таким образом, который обеспечивает безопасность и увеличивает пропускную способность, мы предлагаем инновационный консенсус-протокол Proof-of-Believability (PoB) для IOSChain. PoB гарантирует, что узлы с незначительной вероятностью будут вести себя неправильно, при этом значительно увеличивая пропускную способность транзакции на размер один шард.

В протоколе консенсуса «Доказательство правдоподобия» используется внутрирежимный подход Believable-First. Протокол делит всех валидаторов на две группы: правдоподобная лига и нормальная лига. Вероятные валидаторы быстро обрабатывают транзакции на первом этапе. После этого обычные валидаторы выбирают и проверяют транзакции на втором этапе, чтобы обеспечить окончательность и обеспечить возможность проверки. Вероятность того, что узел будет избран в правдоподобную лигу, определяется показателем правдоподобия, который рассчитывается по нескольким факторам (например, баланс токенов, вклад в сообщество, обзоры и т. Д.). Тот, у кого более высокий балл правдоподобия, с большей вероятностью будет избран в правдоподобную лигу. Правдоподобные валидаторы следуют процедурам для определения набора совершенных транзакций и их порядка, а также обрабатывают их по порядку. Правдоподобные валидаторы также образуют меньшие группы — по одному валидатору на группу. Транзакции будут случайным образом распределены между этими правдоподобными валидаторами. Следовательно, они производят меньшие блоки с чрезвычайно низкой задержкой.

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

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

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

В нормальной лиге действует византийская консенсусная схема, основанная на ByzCoin [7], потому что она эффективно масштабируется до тысяч членов консенсусной группы. ByzCoin использует коллективную сигнатуру (CoSi) [25], масштабируемый криптографический примитив, который использует мульти-сигнатуры [20], для создания традиционных согласованных алгоритмов, таких как масштабирование PBFT [4]. ByzCoin распределяет блоки, используя многоадресные деревья для производительности, и возвращается к звездной топологии для отказоустойчивости. Это гарантирует, что все честные члены шарда согласовывают конкретную общую последовательность действий, несмотря на то, что некоторые вредоносные узлы находятся в шарде, гарантируя при этом безопасность и жизнеспособность.

Чтобы обеспечить надежность, мы используем резервную схему в протоколе Believable-first. Когда у шарда недостаточно правдоподобных валидаторов для формирования лиги из-за временного простоя или из-за начальной стадии загрузки экосистемы, комитеты из двух лиг возвращаются к одной лиге. Все транзакции напрямую обрабатываются обычной лигой в соответствии с согласованным протоколом PBFT.

Обрезка блокчейна

Другая проблема, с которой сталкиваются в настоящее время блокчейны, — это быстрое расширение размера хранилища блокчейнов [8], которое создает для новых валидаторов большую нагрузку для начальной загрузки. Блокчейны следуют той же схеме для хранения исторических данных с самого начала. Тем не менее, это является серьезной проблемой для систем с высокой пропускной способностью, так как хранилище взорвется.Чтобы минимизировать затраты на хранение и загрузку для валидаторов, мы используем подход сокращения цепочки блоков, чтобы суммировать полное состояние блокчейна сегмента. Мы используем Micro State Blocks (MSB), который основан на State Block [8]. Мы представляем протокол генерации MSB ниже.

Алгоритм — протокол генерации MSB


Входы:

  • текущая эпоха
  • это текущий осколок

Выход: блок микросостояний за в

  1. Когда эпоха заканчивается, лидер осколка сохраняет все транзакции в дереве Меркля [14].
  2. Лидер осколков хеширует корень дерева Меркле, обозначенный и помещает в ,
  3. Валидаторы работают на основе консенсуса , в то время как нет никаких ожидающих регулярных блоков.
  4. Если правильность проверки подтверждена, лидер осколка сохраняет утвержденный заголовок в блокчейне осколка.
  5. В конце эпохи все узлы сбрасывают тело и сохраняют регулярные блоки ,

Анализ

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

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

С помощью MSB эффективнее загружаются новые валидаторы и синхронизируются последние сбойные валидаторы, так как валидаторы начинают с последнего действительного MSB и воспроизводят только последнюю часть блокчейна, а не воспроизводят полную историю из первого блока или из времени. они разбились. Если Биткойн развернут на IOSChain, в настоящее время затраты на загрузку полосы пропускания будут на два порядка меньше. Это очень важно, когда в IOSChain появляются новые осколки. Благодаря механизму случайного назначения сегментов, валидаторы периодически меняют фрагменты, и их необходимо часто обновлять, что значительно выигрывает от метода сокращения хранилища блокчейнов.

РЕКОМЕНДАЦИИ

[1] Иддо Бентов, Ариэль Габизон и Алекс Мизрахи. 2016. Криптовалюты без подтверждения работы. В лекционных заметках по информатике. 142-157.[2] Иддо Бентов, Чарльз Ли, Алекс Мизрахи и Мени Розенфельд. 2014. Доказательство деятельности. ACM SIGMETRICS Обзор оценки эффективности 42, 3 (2014), 34–37.[3] Виталик Бутерин. 2014. Slasher: карательное доказательство алгоритма кола. Получено 9 января 2018 г. с https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of- кол-алгоритма /[4] Мигель Оом Темудо де Кастро. 2000. Практическая Византийская Терпимость.[5] Nxt Community. Nxt Whitepaper. Получено 9 января 2018 г. с сайта https://bravenewcoin.com/assets/Whitepapers/NxtWhitepaper-v122-rev4.pdf. [6] Джордж Данезис и Сара Мейклджон. 2016. Централизованные банковские криптовалюты. В Трудах 2016 Симпозиум по безопасности сетевых и распределенных систем. DOI: https://doi.org/10.14722/ndss.2016.23187 [7] Э. Кокорис-Когиас, П. Йованович, Н. Гейли, И. Хоффи, Л. Гассер, Б. Форд. 2016. Повышение безопасности и производительности Биткойн благодаря строгой согласованности посредством коллективной подписи. На 25-й конференции USENIX по безопасности Симпозиум.[8] Элефтериос Кокорис-Когиас, Филипп Йованович, Линус Гассер †, Николас Гейли, Ева Сита, Брайан Форд. 2017. OmniLedger: безопасная, масштабируемая, децентрализованная книга с помощью шардинга.[9] Йосси Гилад, Ротем Хемо, Сильвио Микали, Георгиос Влахос и Николай Зельдович. 2017. Algorand: Масштабирование византийских соглашений о криптовалютах. В материалах 26-го симпозиума по принципам операционных систем — SOSP ’17. DOI: https://doi.org/10.1145/3132747.3132757 [10] Г. Максвелл А. 2015. О коле и консенсусе. Получено 9 января 2018 г. с сайта https://download.wpsoftware.net/bitcoin/pos.pdf. [11] Ян Григг. EOS — Введение. eos.io. Получено с https://eos.io/documents/EOS_An_Introduction.pdf [12] Дж. Квон. 2014. Tendermint: консенсус без майнинга. Получено 9 января 2018 г. с сайта http://tendermint.com/docs/tendermint.pdf. [13] Лой Луу, Вишвеш Нараянан, Чаодонг Чжэн, Кунал Баведжа, Сет Гилберт и Пратик Саксена. 2016. Протокол безопасного разделения для открытых цепочек блоков. В материалах конференции ACM SIGSAC по безопасности компьютеров и связи 2016 года — CCS’16. DOI: https://doi.org/10.1145/2976749.2978389 [14] Ральф К. Меркл. Сертифицированная цифровая подпись. В лекционных заметках по информатике. 218-238.[15] Сатоши Накамото. Биткойн: одноранговая электронная кассовая система. bitcoin.org. Получено с https://bitcoin.org/bitcoin.pdf [16] Перевал Рафаэль, Лиор Симан и Абхи Шелат. 2017. Анализ протокола Blockchain в асинхронных сетях. В лекционных заметках по информатике. 643-673.[17] Пасс Рафаэль и Элейн Ши. 2017. Сонная модель консенсуса. В лекционных заметках по информатике. 380-409.[18] Фил Даян, Рафаэль Пасс и Элейн Ши. 2016. Белоснежка: гарантированно надежные доказательства кола. (2016).[19] Фил Даян Рафаэль Пасс. Белоснежка: надежно реконфигурируемый консенсус и приложения для обеспечения надежной защиты кола.[20] CP Schnorr. 1991. Эффективная генерация подписи с помощью смарт-карт. J. Cryptology 4, 3 (1991). DOI: https://doi.org/10.1007/bf00196725 [21] Джагдип Сидху. 2017. Syscoin: одноранговая электронная кассовая система с блокчейн-сервисами для электронного бизнеса. В 2017 году 26-я Международная конференция по компьютерным коммуникациям и сетям (ICCCN). DOI: https://doi.org/10.1109/icccn.2017.8038518 [22] Солнечный король А. Ppcoin: одноранговая криптовалюта с доказательством кола. Получено 2012 с https://peercoin.net/assets/paper/peercoin-paper.pdf [23] Скотт Надаль Санни Кинг. 2012. Peercoin. Получено 9 января 2018 г. с сайта https://peercoin.net/assets/paper/peercoin-paper.pdf. [24] Ева Сыта, Филипп Йованович, Элефтериос Кокорис Когиас, Николас Гейли, Линус Гассер, Исмаил Хофи, Майкл Дж. Фишер и Брайан Форд. 2017. Масштабируемая распределенная случайность, устойчивая к смещению. В 2017 году IEEE Симпозиум по безопасности и конфиденциальности (SP). DOI: https://doi.org/10.1109/sp.2017.45 [25] Ева Сыта, Юлия Тамас, Дилан Вишер, Давид Исаак Волинский, Филипп Йованович, Линус Гассер, Николас Гейли, Исмаил Хоффи и Брайан Форд. 2016. Поддержание власти «честным или несостоятельным» с помощью децентрализованного свидетельства свидетелей. В 2016 году IEEE Symposium по безопасности и конфиденциальности (SP). DOI: https://doi.org/10.1109/sp.2016.38 [26] В. Бутерин А. 2015. Каспер. Получено 9 января 2018 г. с сайта https://blog.ethereum.org/2015/08/01/ представляя-casper-friendly-ghost /[27] Г. Вуд. 2014. Ethereum: безопасный децентрализованный регистр обобщенных транзакций. Эфириум Проект Желтая Бумага. (2014).[28] Гэвин Вуд. 2018. ETHEREUM: БЕЗОПАСНЫЙ ДЕЦЕНТРАЛИЗОВАННЫЙ ОБОБЩЕННЫЙ ТРАНЗАКЦИОННЫЙ ЛЕДГЕР. ethereum.github.io/yellowpaper. Получено с https://ethereum.github.io/yellowpaper/paper.pdf [29] 2017. Steem: Платформа для публичного контента, основанная на блокчейнах. steem.io. Получено с https://steem.io/SteemWhitePaper.pdf [30] Бел. bitshares.org. Получено с http://docs.bitshares.org/bitshares/papers/ [31] Доказательство кола вместо доказательства работы. Получено 9 января 2018 г. с сайта https://bitcointalk.org/index.php?topic=27787.0.

We in social media: