Keep Network. Russian Whitepaper.

0
317
views

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

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


Keep Network — частный слой
для публичного блокчейна

 

Мэтт Луонго (Matt Luongo) mhluongo@gmail.com

Корбин Пон (Corbin Pon) corbin.pon@gmail.com

Резюме

Мы представляем Keep — примитив конфиденциальности для развития смарт-контрактов на публичных блокчейнах, предоставляющий надежные хранилища и использование секретов, а также поддерживающий инфраструктуру, включая рынок и токены keep.

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

Содержание

1. Мотивация

1.1.Обратный результат использования публичных блокчейнов
1.2. Существенные подходы

1.2.1. Шаблон хэш-вскрытия
1.2.2. Частные блокчейны

1.2.3. Доказательства с нулевым разглашением

1.3. Общественные приложения, частные данные

2. Представляем keeps

2.1. Операции Keep

2.1.1. Создание и заполнение
2.1.2. Публикация данных оффчейн
2.1.3. Управление доступом
2.1.4. Продолжительность использования

3. Устранение стороннего риска

3.1. Безопасное многопартийное вычисление
3.2. sMPC и блокчейн

4. Провайдеры Keep

4.1. Простой sMPC
4.2. Подписание sMPC
4.3. Будущие провайдеры

4.3.1. Безопасное аппаратное обеспечение
4.3.2. Частные смарт-контракты

5. Усиление поддержки провайдеров

5.1. Плата за хранилища
5.2. Проблемы с временем безотказной работы и надежностью
5.3. Проблемы активных атак

6. Проектирование сети высокого уровня

6.1. Сетевой токен Keep
6.2. Обеспечение справедливого выбора хранилища

6.2.1. Случайные маячки
6.2.2. Пороговое реле (Threshold relay)
6.2.3. Группа выбора Keep

7. Реестр результатов

8. Приложения

8.1. Переключатель мертвеца (Dead man switch)
8.2. Рынки для цифровых товаров
8.3. Псевдослучайный оракул
8.4. Децентрализованное подписание
8.5. Кастоидальные кошельки и кроссчейн торговля
8.6. Сервис шифровки контракта для блокчейн хранилища
8.7. Банковские операции на публичных блокчейнах

 


1. Мотивация

1.1. Обратный результат использования публичных блокчейнов

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

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

Эти проблемы признаны разработчиками проектов Bitcoin и Ethereum.

Конфиденциальные транзакции являются непрерывной попыткой улучшения конфиденциальности, а поэтому и взаимозаменяемость, биткоина через сайдчейны. Проект Zerocash применил доказательства нулевого знания к биткоину, приводя к созданию Zcash, криптографии использующей сертификаты zk-SNARK для обеспечения конфиденциальности транзакций.

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

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

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

1.2. Существенные подходы

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

1.2.1. Шаблон хэш-вскрытия

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

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

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

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

1.2.2. Частные блокчейны

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

Эти системы управляются доверенным или полудоверенным способом. Вместо того, чтобы использовать механизм proof-of-work или другой алгоритм консенсуса, разработанный с учетом состязательной сети, они могут использовать системы наподобие RAFT, чтобы достичь определенного согласия.

Одной из таких систем является система Моргана под названием Quorum, ответвление от Ethereum, поддерживающая частные смарт-контракты и обмен сообщениями между участниками. Другая это недавно анонсированная Майкрософтом система Coco Framework, обеспечивающая конфиденциальность данных поверх существующего частного блокчейна.

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

 1.2.3. Доказательства с нулевым разглашением

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

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

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

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

1.3. Общественные приложения, частные данные

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

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

2. Представляем keeps

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

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

2.1. Операции Keep

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

2.1.1. Создание и заполнение

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

2.1.2. Публикация данных оффчейн

Целью хранилища keep является вычисление функций на основании секретных данных и публикация их на блокчейне.

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

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

2.1.3. Управление доступом

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

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

2.1.4. Продолжительность использования

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

3. Устранение стороннего риска

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

Далее мы опишем технику устранения стороннего риска.

3.1. Безопасное многопартийное вычисление

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

Наглядно sMPC работает следующим образом:

  1. Посредник D хочет вычислить функцию F, через секрет S.
  2. Посредник выбирает n сторон для вычисления, отправляя каждому часть секретной информации, s.
  3. Каждая часть вычисляет функцию через их часть fi(si) и сообщает результат посреднику.
  4. Посредник соединяет вывод данных так, что tt(f1(s1), f2(s2), …fn(sn)) = F (S)

Части si должны быть выбраны таким способом, чтобы разоблачение одной части не поставило под угрозу секретную информацию S. Распространенный подход, использовать схему распределения секрета Шамира, так что детали секрета остаются нераскрытыми в лице n – 1 нечестных сторон. Это объяснение справедливо для всех F, включая сложение, вычитание и умножение на известную константу. Однако для достижения общих вычислений нам также необходимо надежно размножать секретные данные.

Умножение добавляет то, что литература называет «раундами» — общение между сторонами, а не только c посредником D.

Чтобы умножить два секрета, каждая сторона Pi выбранных n разбивает свои части si на два компонента si1 и si2. Партия умножает эти два компонента, в результате sij. Каждая Pi действует как посредник среди остающихся партий, разбивая sij на n-1 кусков. Каждая Pi может теперь могжет разрешить свою итоговую долю раунда умножения, sji дав свой допуск к n − 1 частей sij.

3.2. sMPC и блокчейн

Первоначально sMPC был задуман в 1982 году, но его практическое применение было ограничено из-за ограничений на модель безопасности. Существующие решения sMPC только поддерживают безопасность перед лицом честного большинства сторон. Появление блокчейнов позволяет использовать sMPC в сценариях состязательности. Используя блокчейн как публичный лэджер, sMPC может быть защищен от нечестного сверхбольшинства и с запросом токена сети, становится устойчивым к атакам Sybil. По этим причинам блокчейны и sMPC натурально соответствуют. В пространстве смарт-контрактов, sMPC был предложен ранее как механизм конфиденциальности. В 2014 году, Виталик Бутерин дал четкое представление предмету в раннем блоге о конфиденциальности в общественном блокчейне Ethereum. В 2016 году команда UMD разработала систему HAWK, которая соединяется с публичными и конфиденциальными смарт-контрактами через sMPC, также проект Enigma, разработанный Массачусетским техническим институтом, описывает систему, связанную с нашей, с более широким упором на общие частные вычисления.

4. Провайдеры Keep

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

4.1. Простой sMPC

Простой sMPC сети Keep поддерживается n узлами, каждый из которых вычисляет часть предоставленной секретной информации, так что секрет не может быть восстановлен без вовлечения всех n узлов. Эти хранилища могут быть безопасно заполнены, разделяя части используя схему Шамира и шифрую каждую часть, используя открытый ключ соответствующего узла.  Затем зашифрованные части могут быть опубликованы на общественном блокчейне или переданы оффчейн. Единственное вычисление, которые проведут эти хранилища — это реализация распределенного RSA на sMPC, использованного для публикации зашифрованных данных на блокчейн.

4.2. Подписание sMPC

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

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

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

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

4.3. Будущие провайдеры

Оффчейн шаблон keep достаточно гибок, чтобы включить других провайдеров, каждого с собственной выгодой.

4.3.1. Безопасное аппаратное обеспечение

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

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

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

4.3.2. Частные смарт-контракты

В отличие от связанной работы с такими системами, как Enigma или Hawk, которые используют sMPC для построения офф-чейн и альтернативных чейн вычислительных сетей для частных смарт-контрактов, мы решили ограничить первоначальный sMPC хранилища keep, чтобы обеспечивать безопасность, генерировать, шифровать и передавать секретную информацию. Такое ограничение помогает свести к минимуму поверхность атаки на хранилище производственной сети.

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

5. Усиление поддержки провайдеров

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

  1. Высокую доступность.
  2. Устойчивость к потере данных.
  3. Обеспечение конфиденциальности.
  4. Целостность данных.

5.1. Плата за хранилища

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

диаграмма последовательности вкладов + оплата за операцию

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

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

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

5.2. Проблемы с временем безотказной работы и надежностью

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

Надлежащий протокол выключения

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

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

5.3. Проблемы активных атак

Существующие рамки sMPC с открытым исходным кодом, такие как VIFF, защищены от активных атак в присутствии супербольшинства честных узлов.

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

Недавние подходы с использованием доказательств SPDZ, закрепленных на блокчейне, делают атаки повторного воспроизведения невозможными, даже если все вовлеченные узлы keep скомпрометированы. Хранилища sMPC будут публиковать доказательства на общественный блокчейн, который используется для подтверждения правильности. Угроза активных атак затем сводится к нарушению сохранения доступности, а не к возврату неверных данных.

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

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

6. Проектирование сети высокого уровня

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

6.1. Сетевой токен Keep

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

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

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

6.2. Обеспечение справедливого выбора хранилища

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

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

Вместо рынка нам нужен справедливый механизм выбора хранилища.

6.2.1. Случайные маячки

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

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

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

Для такой системы существует несколько соображений:

  1. Провайдеры не могут допускать несправедливое преимущество друг над другом в процессе выбора узла.
  2. Для каждого блока в общедоступной цепочке требуется хотя бы одно случайное число достаточного размера.
  3. Сегодняшнее время блока Ethereum составляет 25 секунд, но этот показатель, вероятно, значительно изменится в будущем. Процесс RNG должен быть достаточно быстрым, чтобы при необходимости поддерживать гораздо более короткое время блокировки.
  4. RNG должен быть устойчивым к отказу узла. Неудача в производстве означает, что не может быть создано никаких новых хранилищ, поэтому, чтобы устойчивость к разделам между провайдерами, а также против активных атак с отказами в обслуживании была желательной.
  5. Несмотря на жесткое системное требование, предоставление сети Ethereum надежным источником случайности также станет отличным подарком для других проектов.

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

6.2.2. Пороговое реле (Threshold relay)

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

Пороговые сигнатуры — это связанная идея. Пороговая подпись — это подпись, разбитая на на n частей, требующая некоторой минимальной активности t участвующей в подписании. Это аналогичная идея для «multisig», которая сегодня используется для криптовалют.

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

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

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

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

6.2.3. Группа выбора Keep

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

7. Реестр результатов

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

8. Приложения

8.1. Переключатель мертвеца (Dead man switch)

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

8.2. Рынки для цифровых товаров

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

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

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

8.3. Псевдослучайный оракул

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

8.4. Децентрализованное подписание

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

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

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

8.5. Кастоидальные кошельки и кроссчейн торговля

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

8.6. Сервис шифровки контракта для блокчейн хранилища

Такие услуги, как Filecoin и Storj, создаются для обеспечения дешевого, повсеместного хранения, доступного в глобальном масштабе, посредством интеллектуальных контрактов и традиционных интерфейсов хранения. По умолчанию эти службы предоставляют несколько гарантий конфиденциальности, оставляя на стороне пользователей шифрование файлов. Keep может провести частный мост к хранилищу блокчейн. Генерируя ключ AES при инициализации хранилища keep и обеспечивая доступ к данным оффчейн, интеллектуальные контракты могут использовать хранилища keep для защиты файлов, хранящихся на децентрализованных сервисах.

8.7. Банковские операции на публичных блокчейнах

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

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

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

Предыдущая статьяCryptoCurve
Следующая статьяKeep Network. Russian Business Primer
ПОДЕЛИТЬСЯ

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

Please enter your comment!
Please enter your name here