Solana. Russian Whitepaper.

0
318
views

Команда ICOdaily подготовила перевод официального Whitepaper проекта Solana на русский язык.

Еще больше новых проектов, переводов интересных статьей и новостей на нашем телеграм канале


Solana: новая архитектура для высокопроизводительных блокченйнов версии 0.8.13

Дисклаймер. Этот вайтпепер не предлагает ничего на продажу, также как в данном документе не содержится ничего, что подстрекало бы на покупку токенов. Компания Solana издает этот вайтпепер только с одной целью – получить отзывы и комментарии от общественности. Если компания решит начать продажу токенов, все будет проходить с использованием определенных документов, соответствующих данной цели, включая документ о раскрытии и описание факторов риска. Вышеописанные документы также будут включать обновленную версию данного вайтпепера, который может существенно отличаться от данной версии. Когда Solana начнет кампанию по предложению своих токенов в США, вероятнее всего, предложение будет доступно только для аккредитованных инвесторов.

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

Резюме

Данный вайтпепер предлагает новую блокчейн архитектуру, построенную на протоколе Proof of History (PoH) – протокол, проверяющий ордеры и время прохождения между событиями. Протокол POH используется для того, чтобы кодировать ненадежное время прохождения в леджер, добавляется только структура данных. При использовании РОН вместе с алгоритмом консенсуса, таким как POW и POS, возможно уменьшить расходы на сообщения репликации конечного автомата, работающего с использованием задачи византийских генералов. Данный вайтпепер также представляет два алгоритма, которые используют свойства сохранения времени леджера РОН – алгоритм PoS, котрый может восстанавливаться из частей любого размера и эффективной потоковой передачи протокола Proof of Replication (PoRep) ”доказательство репликации”. Совместное использование PoH и PoRep предоставляет защиту против подделывания леджера, при помощи отношения ко времени(заказу) и хранению.  Данный протокол был проанализирован в сети с пропускной способностью 1 Гбит/с, и данный вайтпепер показывает, что пропускная способность до 710 000 транзакций в секунду возможна с использованием сегодняшнего оборудования.

  1. Введение

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

  1. План вайтпепера

Остальная часть данной статьи организована следующим образом.

Раздел 3. Общее устройство системы

Раздел 4. Подробное описание протокола Proof of History

Раздел 5. Подробное описание предлагаемого Доказательства алгоритма консенсуса Proof of Stake

Раздел 6. Подробное описание предлагаемого быстрого Proof Replication

Раздел 7. Архитектура системы и лимиты производительности

Раздел 7.5. Высокопроизводительный графический процессор совместимый с механизмом смарт-контрактов

  1. Разработка сети

Как показано на рисунке 1, в любой момент времени системный узел может быть определен как “Лидер” для генерации последовательности Proof of History, обеспечивающей согласованность глобальной целостности сети и проверяемый проход времени. Лидер организовывает и упорядочивает их так, чтобы они могли быть эффективно обработаны другими узлами в системе, максимизируя пропускную способность. Он выполняет транзакции в текущем состоянии, которые хранятся в ОЗУ, и публикует транзакции и подпись конечного состояния в узлах репликации, называемых “Верификаторы”. Верификаторы выполняют одни и те же транзакции на своих копиях состояний и публикуют свои вычисленные подписи состояния в качестве подтверждений. Опубликованные подтверждения служат голосами для алгоритма консенсуса.

Рисунок 1. Поток транзакций в сети

В несегментированном состоянии, в любой момент времени, есть только один Лидер в сети. Каждый узел Верификатора имеет те же самые аппаратные возможности, что и Лидер и может быть выбран Лидером, посредством выборов, на основе протокола PoS. Выборы для предложенного алгоритма PoS подробно описаны в Разделе 5.6.

С точки зрения теоремы Брюера, Согласованность всегда выбирается над Доступностью, в случае Разделения. В данном вайтпепере представлен механизм по восстановлению контроля для случаев большого разделения. Контроль будет восстановлен в случае разделения любого размера. Это подробно описано в Разделе 5.12.

  1. Протокол Prof of History

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

Данные могут получить “временную метку” в этой последовательности, добавив данные (или хэш некоторых данных) в состояние функции. Запись состояния, индекса, и данных в том состоянии, в котором они были добавлены в последовательность, позволяет создать временную метку, которая может служить гарантией, что данные были созданы до того, как следующий хэш в последовательности был сгенерирован. Данная разработка также поддерживает горизонтальное масштабирование, так как несколько генераторов могут быть синхронизированы друг с другом, смешивая свои состояния в последовательности. Более детально горизонтальное масштабирование рассмотрено в Разделе 4.4.

4.1. Описание

Система разработана, чтобы работать следующим образом. С использованием криптографической функции хэша, выход которой нельзя предсказать без запуска функции (например, sha256, ripemd и так далее), запускать функцию из некого случайного стартового значения, брать выход и снова передавать его в качестве входа этой же функции. Записывать выход каждого запроса функции и сколько раз запрос был сделан. Выбранным исходным случайным значением может быть любая строка, например, заголовок сегодняшнего выпуска New York Times.

Например:

Последовательность PoH

Где hashN представляет собой действующий выход хэша.

Необходимо только опубликовать подмножество хэшей и индексов на интервал.

Например:

Последовательность PoH

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

В примере на рисунке 2, хеш 62f51643c1 был произведен над значением 510144806912, а хеш c43d862d88 над значением 510146904064. Следуя ранее оговоренным свойствам аглоритма PoH, мы можем довериться тому, что время между значениями 510144806912 и 510146904064 прошло.

Рисунок 2. Последовательность Proof of History.

4.2. Временная отметка для событий

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

Например:

Происходит какое-то внешнее событие, например, была сделана фотография или были созданы произвольные цифровые данные:

Последовательность PoH с данными

Hash336 вычислен из присоединенных двоичных данных hash335 и sha256 фотографии. Индекс и sha256 записаны в качестве части последовательности выхода. Теперь любой, кто проверяет эту последовательность, может воссоздать это изменение в последовательности. Проверка также может быть выполнена параллельно, как это было описано в Разделе 4.3.

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

Последовательность PoH

Таблица 1. Последовательность PoH с двумя событиями.

В последовательности, показанной в таблице 1. значение photograph2 было создано до того, как был создано значение hash600, а photograph1 было создано до того, как было создано hash336. Вставка данных в последовательность приводит к изменению всех последующих значений в последовательности. Пока использованная хэш функция остается устойчивой к столкновению, а данные присоединены, должно быть невозможно заранее вычислить любую будущую последовательность, основанную на прежних знаниях того, какие данные будут интегрированы в последовательность.

Данные, помещены в последовательность могут быть просто необработанными данными или хэшем данных, без сопровождающих метаданных.

В примере на рисунке 3. вход cfd40df8… был помещен в последовательность Proof of History. Значение, на которое он был помещен 510145855488, а состояние, на которое он был помещен 3d039eef3. Все сгенерированные, в последствии, хэши будут изменены данным изменением в последовательности. Это изменении на рисунке показано при помощи изменения цвета.

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

Рисунок 3. Добавление данных в Proof of History.


4.3. Верификация

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

Например:

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

Общее число хешей/Число хэшей в секунду для одного ядра

То ожидаемое время на проверку того, что последовательность будет правильной:

Общее число хэшей/(Число хэшей в секунду на одном ядре*число ядер, доступных для проверки)

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

Рисунок 4. Проверка использует несколько ядер.


4.4. Горизонтальное масштабирование

Возможно синхронизировать множество генераторов Proof of History при помощи смешения состояний последовательностей генераторов и таким образом достичь горизонтального масштабирования генератора Proof of History. Такое масштабирование выполняется без шардинга. Выход обоих генераторов необходим для восстановления порядка событий в системе.

Даны генераторы А и В, А получает пакет данных от В (hash1b), который содержит последние состояние генератора B, а последнее состояние генератора B следует из генератора А.Теперь хэш следующего состояния в генераторе А будет зависеть от состояния генератора В, таким образом мы можем вывести, что hash1b произошел раньше, чем hash3a. Это свойство может быть переходным, так что если три генератора синхронизированы через один общий генератор A↔B↔C, то мы можем проследить зависимость между А и С, даже несмотря на то, что они не были прямо синхронизированы.

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

На рисунке 5 два генератора включают выходное состояние друг друга и записывают операцию. При помощи смены цвета показано, что данные от peer’а изменили последовательность. Сгенерированные хэши, которые смешиваются в каждом потоке, выделены жирным шрифтом.

Синхронизация транзитивна. A↔B↔C Доказуемый порядок событий между А и С, через В.

Масштабирование данным способом идет за счет доступности. 10×1 gbps соединений с доступностью 0.99910=0.99 доступности.

Рисунок 5. Синхронизация двух генераторов.

4.5. Согласованность

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

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

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

Последовательность  РоН А

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

Чтобы препятствовать тому, что вредоносный генератор РоН будет переписывать хэши клиентских событий, клиенты могут отправлять подпись данных события и последний наблюдаемы хэш, вместо отправки просто данных.

Последовательность  РоН А

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

Проверка:

(Signature, PublicKey, hash30a, event3 data) = Event3

Verify (Signature, PublicKey, Event3)

Lookup (hash30a, PoHSequence)

 

На рисунке 6. поставляемый пользователем вход полагается на хэш  0xdeadbeef… существующий в последовательности, сгенерированной до того, как данный хэш был в нее помещен.

Рисунок 6. Вход с обратной ссылкой.

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

4.6. Накладные расходы

4000 хэшей в секунду будут генерировать дополнительные 160 килобайт данных и потребуют доступ к графическому процессору с 4 000 ядер и приблизительно 0.25 — 0.75 милисекунд на проверку.

4.7. Атаки

4.7.1. Обратная атака

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

4.7.2. Скорость

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

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

4.7.3. Атаки дальнего действия

Атаки дальнего действия включают приобретение старых, отслуживших клиентских закрытых ключей и генерирование фальшивого леджера. Протокол Proof of History предоставляет против таких атак. Злонамеренному пользователю, получившему доступ к старым закрытым ключам, придется повторно создать запись истории, на создание которой потребуется столько же времени, как и на создание оригинальной, которую они пытаются подделать. Для осуществления этого потребуется процессор гораздо большей мощности, чем тот, который используется сетью, следовательно, атакующий никогда не сможет догнать ленту истории.

Кроме того, единственный источник времени позволяет создать более простой протокол Proof of Replication (Доказательство Репликации) (Более подробно описан в Разделе 6). Таким образом сеть разработана так, что все участники сети будут полагаться на единственную запись истории событий.

Вместе PoRep и PoH должны предоставлять защиту как пространства, так и времени от подделанного леджера.

  1. Протокол консенсуса Proof of Stake

5.1. Описание

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

5.2. Терминология

Bonds (облигации). Облигации представляют собой эквивалент капитальных расходов Proof of Work. Майнер покупает оборудование и платит за электричество, затем передает ресурсы на одну ветку в блокчейне Proof of Work. Облигация — это монета, которую проверяющий передает в качестве дополнительного обеспечения, пока проверяющие работают над проверкой транзакций.

Slashing (слэшинг). Предлагаемое решение для проблемы nothing at stake (ничего на кону) в системе Proof of Stake. Когда доказательство голосования для другой ветки публикуется, данная ветка может разрушить облигации проверяющих. Данное решение представляет собой экономическую инициативу, разработанную, чтобы предотвратить желание проверяющих подтверждать состояния множества веток.

Super majority (Супербольшинство). Супербольшинство это 2/3 проверяющих, имеющих весь в соответствии с их облигациями. Голос супербольшинства показывает, что сеть достигла консенсуса, и как минимум 1/3 пришлось бы злонамеренно проголосовать за то, что данная ветвь недействительна. Вследствие этого, экономическая стоимость атаки стоила бы 1/3 от маркеткепа стоимости монеты.

5.3. Помещение облигаций на аккаунт

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

5.4. Голосование

Предполагается, что генератор Proof of History сможет публиковать подписи состояния в предопределенный период. Данную подпись должен подтверждать каждый аккаунт, имеющий на счету облигации, при помощи опубликования своего собственного подписанного состояния. Голосование предусматривает только “да”.

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

5.5. Вывод облигаций с аккаунта

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

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


5.6. Выборы

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

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

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

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

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

5.7. Триггеры выборов

5.7.1. Измененный генератор Proof of History

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

5.7.2. Исключения времени выполнения

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

5.7.3. Таймауты сети

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

5.8. Слэшинг

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

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

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

5.9. Вторичные выборы

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

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

5.10. Доступность

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

Proof of Stake проверяющие, ставят некоторую сумму монет, которая находится в локапе, что позволяет им голосовать за конкретный набор транзакций. Помещение монет в локап это транзакция, которая включена в поток PoH, как и другие транзакции. Чтобы проголосовать, PoS проверяющий, должен подписать хэш состояния, как только он был вычислен, после обработки транзакций в определенную позицию на РоН леджере.Этот голос также включается в качестве транзакции в поток РоН. Посмотрев на РоН леджер мы можем отметить, сколько времени прошло между каждым голосом и, если выполняется членение, насколько долго каждый проверяющий был недоступен.

Для того, чтобы работать с членением при помощи временных рамок, определяемых человеческим фактором, мы предлагаем использовать динамический подход чтобы отменять ставки недоступных проверяющих. Когда число проверяющих высоко и находится выше 2/3, процесс отмены ставок может быть высоким. Число хэшей, которое должно быть сгенерировано невелико, до того, как, ставка недействующих проверяющих полностью не отменена, и они больше не учитываются для консенсуса. Когда число проверяющих ниже 2/3, но выше 1/2, отмена ставки будет низкой, требуя генерации большего числа хэшей, до того, как ставки недостающих проверяющих будут отменены. При крупном членении, как например, когда членение недостает 1/2 или более проверяющих, процесс отмены ставки будет крайне медленным. Транзакции все еще могут быть включены в поток, а проверяющие все еще могут голосовать, но полный консенсус, состоящий из 2/3, не может быть достигнут, пока не будет создано очень большое количество хэшей и ставки недоступных проверяющих не будут отменены. Разница во времени сети для восстановления жизнеспособности сети позволяет нам, как пользователям сети временных рамок, выбирать ту часть в членении, которую мы хотим продолжить использовать.

5.11. Восстановление

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


5.12. Законченность

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

5.13. Атаки

5.13.1. Трагедия общин

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

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


5.13.2. Сговор с генератором PoH

Проверяющий, который вступает в сговор с генератором PoH, должен знать наперед, что когда неправильный хэш будет выпущен, но не будет голосовать. Данный сценарий ничем не отличается от сценария, когда у РоН индивидуальности есть большая ставка проверяющего. Генератору РоН все также нужно будет делать всю работу, чтобы создать состояние хэша.

5.13.3. Цензура

Цензурирование или отказ в обслуживании может происходить, когда 1/3 держателей облигаций отказывается утверждать любую последовательность с новыми облигациями. Протокол может защитить от такой формы атаки, динамично регулируя то, насколько быстро облигации станут несвежими. В случае отказа в обслуживании, наибольшее членение будете разработано так, что производить процесс форка и подвергать цензуре византийских держателей облигаций. Наибольшая сеть будет восстановлена в тот момент, когда византийские облигации, со временем, станут несвежими. Меньшая византийская часть не сможет двигаться вперед в течении более длительного промежутка времени.

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

5.13.4.  Атака дальнего действия

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

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

5.13.5. Атаки ASIC

В протоколе существуют две возможности для атак ASIC – во время членения и мошенничество с таймаутами в Завершении.

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

Для ASIC атак, во время завершения, уязвимость позволяет византийским проверяющим, имеющим облигационную ставку, ждать подтверждения от других узлов и внедрять свои голоса при помощи сотрудничающего генератора PoH. В таком случае, PoH генератор может использовать свою наибыстрейшую интегральную схему, чтобы сгенерировать 500 м/с значение хэшей за короткое время и позволить в сети передачу между РоН генератором и сотрудничающими узлами. Но, в случае того, если генератор тоже византийский, нет никакой причины, почему византийский генератор не связался бы с существующим счетчиком, когда атакующие ожидают внести ошибку. Данный сценарий не отличается от того, когда PoH генератор и сотрудничающие с ним, делят одно и тоже доказательство личности между собой, имеют единственную комбинированную ставку и используют один набор оборудования.

  1. Потоковое Proof of Replication (Доказательство репликации)

6.1. Описание

Filecoin предложил версию Proof of Replication. Задача этой версии – получить быстрые и потоковые проверки протокола Proof of Replication, которые доступны при помощи сохранения записи времени в последовательности, сгенерированной протоколом Proof of Stake. Репликация не используется в качестве алгоритма консенсуса, но это полезный инструмент для подсчета стоимости хранения истории блокчейна или состояния при высокой доступности.

6.2. Алгоритм

Рисунок 7. Последовательное СВС шифрование

Рисунок 8: Быстрое доказательство репликации

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

Каждое репликационное подтверждение личности генерирует ключ, подписывая хэш, который был сгенерирован последовательность Proof of History. Это связывает ключ с репликационным подтверждением личности и с особой последовательностью Proof of History. Выбраны могут быть только особые хэши. (Смотрите Раздел 6.5, посвященную выбору хэшей)

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

Хэш меркла вычисляется с выбранным РоН хэшем, добавленным к каждому фрагменту.

Корень публикуется вместе с ключом и сгенерированным выбранным хэшем. Узел репликации требуется для опубликования другого доказательства в N хэшей, в том виде, как они были сгенерированы генератором РоН, где N представляет собой примерно 1/2 времени, нужного для шифрования данных. Генератор Proof of History будет публиковать особые хэши для протокола Proof of Replication в предопределенный момент времени. Узел репликатора должен выбирать следующий опубликованный хэш для генерирования доказательства. И снова, хэш будет подписан и случайные части будут выбраны из блоков, чтобы создать корень меркла.

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


6.3. Проверка

Имея N-ое количество ядер, каждое ядро может создавать поток для каждого подтверждения личности. Требуемое общее количество выражается формулой 2 блока*N ядер, поскольку предыдущий блок необходим для создания следующего. Каждое ядро затем может быть использовано для создания доказательств, полученных из текущего зашифрованного блока.

Ожидается, что общее время для проверки доказательств должно быть равно времени, которое требуется для шифрования. Сами доказательства потребляют некоторое количество случайных байтов из блока, поэтому количество данных для хэша значительно ниже, чем размер зашифрованного блока. Количество репликационных подтверждений личности, которое может быть проверено одновременно соответствует числу доступных ядер. Современные графические процессоры имеют 3500+ ядер, доступных для данной процедуры, хотя даже при 1/2 — 1/3 тактовой чистоты компьютера.

6.4. Вращение ключа

Без вращения ключа одна и та же зашифрованная репликация может генерировать дешевые доказательства для множества последовательностей Proof of History. Ключи вращаются периодически и каждая репликация перешифровывается с помощью нового ключа, который связан с уникальной последовательностью Proof of History.

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

6.5. Выбор хэша

Генератор Proof of History публикует хэши, которые должны быть использованы всей сетью для шифровки доказательств репликации, а также для использования в качестве генератора псевдослучайного числа для выбора байтов в быстрых доказательствах. Хэш публикуется на циклическом счетчике, который приблизительно равен 1/2 от времени, которое требуется, чтобы зашифровать набор данных. Каждое репликационное доказательство личности должно использовать один и тот же хэш, в качестве сида для выбора битов или в качестве ключа шифрования.

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

Генератор, действия которого злонамеренны, может внедрить данные перед этим хэшем, чтобы создать особенный хэш. Более полно данный тип атаки освящен в Разделе 5.13.2

6.6. Проверка достоверности

Предполагается, что узел Proof of History не будет утверждать предоставленные доказательства Proof of Replication. Ожидается, что этот узел будет продолжать отслеживать ожидающих и подтвержденных доказательств, предоставленных идентификатором репликаторов. Ожидается, что доказательство будет проверено тогда, когда репликатор сможет подписать доказательство при помощи супербольшинства проверяющих сети.

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

6.7. Атаки

6.7.1. Спам

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

Протокол Proof of Replication, разработка которого описана в данном документе, позволяет достигнуть дешевой проверки любого дополнительного доказательства, не требуя дополнительного места для него. Но каждый идентификатор должен поглотить одно ядро зашифрованного времени. Цель репликации должна быть настроена на максимальный размер легкодоступных ядер. Современные графические процессоры имеют 3 500+ ядер.

6.7.2. Частичное стирание

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

Например, пользователь хранит один терабайт данных, стирая один байт из каждого мегабайта блока. Единственное доказательство, что выборка одного байта из каждого мегабайта будет иметь вероятность столкновения с любым стертым байтом 1 — (1 -1/1 000 0000)1000000 = 0.63. После пяти доказательств вероятность составит 0.99.

6.7.3. Сговор с генератором PoH

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

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

 6.7.4 Отказ в обслуживании

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

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

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

 6.7.5 Трагедия общин

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

Чтобы избежать, в будущем, действия по данному сценарию, проверяющие PoRep могут подавать ложные доказательства небольшого процента времени. Они могут подтверждать, что доказательства являются фальшивыми, предоставляя функцию, которая генерирует фальшивые данные. Любые PoS проверяющие, которые подтверждают фальшивые данные будут подвержены слэшингу.

Рисунок 9. Архитектура сети.

  1. Архитектура сети

7.1. Компоненты

7.1.1. Лидер, генератор Proof of History

Лидером является выбранный генератор PoH. Он потребляет произвольные пользовательские транзакции и выводит последовательности Proof of History всех транзакций, которые гарантируют уникальный глобальный порядок в системе. После каждой партии транзакций, лидер выпускает подпись состояния, которая является результатом выполнения транзакций в этом порядке. Все это подписывается идентификатором личности лидера.

7.1.2. Состояние

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

Для всех 32 байтов.

Таблица облигаций Proof of Stake содержит:

Для всех 64 байт.

7.1.3. Проверяющий, репликация состояния

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

7.1.4. Валидаторы

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

7.2. Пределы сети

Ожидается, что лидер сможет принимать входящие пользовательские пакеты, упорядочивать их способом, наиболее эффективно возможным, выстраивать их в последовательность Proof of History, которая опубликована в нижестоящих проверяющих узлах. Эффективность основана на шаблонах доступа к памяти транзакций, так что транзакции упорядочены, чтобы минимизировать ошибки и максимизировать упреждающую выборку.

Рисунок 10. Генератор пределов сети.

Формат входящего пакета:

Размер 20 + 8 + 16 + 8 + 32 + 3 232 = 148 байт.

Минимальной полезной нагрузкой, которая может быть поддержана, будет один аккаунт адресат. С минимальной полезной нагрузкой:

С минимальным размером полезной нагрузки: 176 байт.

Пакет последовательности содержит действующий хэш, счетчик и хэш всех новых сообщений, которые были добавлены в последовательность РоН, а также подпись состояния, после обработки всех сообщений.

Этот пакет отправляется после того, как будут переданы все N сообщений.

Пакет Proof of History:

Минимальный размер пакета выхода: 132 байта.

При сетевом соединении 1 гбит/сек максимальное возможное количество транзакций будет 1 гбит/сек: 176 байтов = 710k tps макс. Ожидается некоторая потеря в размере 1-4% из-за фрейминга Ethernet’a. Свободная емкость, поверх целевого количества сети может быть использована для увеличения доступности сети, кодируя выход при помощи кодов Рида Соломона и делая ее доступной для имеющихся проверяющих.

7.3. Пределы вычисления

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

7.4. Пределы памяти

Наивная реализация состояния, как 50% полной хэш-таблицы, с 32 байтами поступления для каждого аккаунта, теоритически соответствовала бы 10 миллиардам аккуантам на 640 гигабайтах. Постоянное состояние случайного доступа к этой таблице измеряется в 1.1*107 операциях чтения ил написания в секунду. Основываясь на двух операциях чтения или двух операциях написания в секунду, пропускная способность памяти может обрабатывать 2.75 млн. транзакций в секунду. Этот процесс был измерен на Amazon Web Services 1TB x1.16xlarge instance.


7.5. Высокопроизводительные смарт-контракты

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

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

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

Рисунок 11. Выполнение PBF программ.

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

LLVM стал поддерживать eBPM, начиная с 2015 года, таким образом любой язык внешнего интерефейса LLVM может быть использован для написания смарт-контракта. eBPM находится в ядре Linux, начиная с 2015 года, а первая интерация байткода появилась, примерно, в 1992 году. Один проход может проверить eBPM на правильность, выяснить его время работы и требования к памяти, а также конвертировать eBPM в инструкции х86.

 

 

 

 

 


Еще больше новых проектов, интересных статьей и новостей на нашем телеграм канале

Предыдущая статьяSpindle
Следующая статьяОбзор ICO Solana от Crypto Briefing
ПОДЕЛИТЬСЯ

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here