MMS

Серия «Самостоятельное хранение», часть I

Введение

StarkEx, механизм масштабируемости с самостоятельным хранением, был только что запущен в основной сети Ethereum ( подробнее см.об общей архитектуре системы и потоках). StarkEx реализует протокол STARK Zero-Knowledge Proof (ZKP). Путь к самокастодиальному решению труден: кастодиальные решения проще, дешевле и, самое главное, гораздо лучше понятны — мир создает кастодиальные программные системы на протяжении десятилетий. Термин «самостоятельный» или синоним «не связанный с содержанием под стражей» используется довольно широко. Они используются операторами, которые могут — одним нажатием кнопки — взять на себя полную опеку над средствами своих пользователей: удивительное положение дел, учитывая, что блокчейны без разрешения были задуманы как альтернатива системам хранения. Мы высоко оцениваем трудности создания настоящей системы самообслуживания и многомерное пространство для проектирования, доступное новаторам в этой области. Мы также понимаем, что многие считают полезным переходить со временем на решения, обеспечивающие все большую самостоятельность. Этотсерия сообщений подробно описывает выбор, который мы сделали, и направление, которое мы видим в будущем для StarkEx в этом отношении.

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

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

  1. Средства пользователей не могут переходить из рук в руки без их явной подписи.
  2. При подписании вся информация становится доступной пользователю (через UX кошелька).
  3. Деньги всегда можно вывести.
  4. Приведенную выше логику нельзя изменить, злоупотребив каким-либо механизмом обновления кода.

В этом посте основное внимание будет уделено тому, почему (1) системы доказательств специально адаптированы для поддержки решений самообслуживания и (2) аудиты смарт-контрактов StarkEx. В следующих постах этой серии будут описаны (3) механизмы обновления смарт-контрактов, которые мы внедрили, (4) поддержка кошельков (схема подписи STARK и интеграция) и, наконец, (5) доступность данных (начиная с комитета, поддерживающего наше первое внедрение в разработку полностью ненадежного решения для обеспечения доступности данных вне сети).

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

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

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

В идеале должно быть как можно меньше предположений о доверии. В частности, для STARK:

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

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

Первое приложение для использования StarkEx находится у наших партнеров в DeversiFi, самостоятельной бирже, которая будет использовать его для масштабирования своих операций (как торговли, так и переводов). ASC гарантирует, что средства пользователей не могут перейти из рук в руки без их явной подписи (подписи проверяются доказательством STARK). StarkEx требует, чтобы пользователи вносили свои средства в ASC, что делает последний очевидной целью для хакеров. Код ASC был проверен и всесторонне протестирован для обеспечения его правильности и безопасности. Кроме того, мы планируем постоянно использовать дополнительные инструменты, такие как формальная проверка, для обеспечения правильности и безопасности нашего кода.

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

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

Том Брэнд и Ури Колодный

 

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *