Презентация "Кремниевая долина Ethereum"

Посмотреть оригинал видео вы можете по ссылке: https://www.youtube.com/watch?v=ovlqeabScj8

Мой Дискорд: useless_dorozhkina#1394

Итак, меня зовут Джереми, я соучредитель и исполнительный директор Subspace Labs. Со мной тут также мой коллега, Назар, наш технический директор. и сегодня мы предоставим вам технический обзор Subspace Network!

Программа:

Для начала скажу, что программа на сегодня будет разделена на три части:

1. Сначала мы расскажем о наших предпосылках и мотивации создать Subspace Network, о том, какие проблемы решает Subspace.

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

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

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

Предпосылки

Как подсчитываются голоса в Консенсусе Накамото?

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

На практике это не сработало. Мы быстро пришли к "один-GPU-один-голос", "один-ASIC-один-голос", а затем - к централизации в пулах майнинга, огромным счетам за электричество, хоть и получили очень высокий уровень охраны. Это привело к поиску новых решений.

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

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

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

Место, необходимое для запуска ноды

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

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

Архивная нода на Ethereum будет весить гораздо больше, но вы можете запустить полную ноду, и, по крайней мере, быть уверенными, что вы на самой длинной сети и что все состояния верны. Но, если вы хотите запустить ноду с минимальной нагрузкой, вы можете, но вы получите другую модель охраны. Вы просто будете знать, что вы в сети, которая имеет наибольший стейк, но вы не будете знать наверняка, правильная ли это сеть. Это полностью меняет предположение о том, что 51% честны. Что может быть сделано, если большинство будут вести себя нечестно?

Проблема

Дилемма фармера

Итак, с этими предпосылками появилась очень специфическая проблема во всех протоколах доказательства дееспособности, в Chia, в Spacemesh, в BioCoin, в Burst, и конечно же в Subspace тоже. Она называется "дилеммой фармера".

Фармер - это нода консенсуса, то же, что и майнер в доказательстве выполнения работы. Проблема заключается в том, что фармер сталкивается с основополагающим выбором. Если вы являетесь честной нодой и выполняете все вышеприведенные требования, вам нужно будет заплатить определенную цену: предоставить место для хранения, сохранять состояние и историю в вашем локальном узле. На диске размером в 1 ТБ у вас останется всего лишь часть места, чтобы выделить на плот, который определят ваши награды. Награды пропорциональны месту, которое вы выделите. Поэтому естественна мотивация максимизировать плот, в идеале выделить для него все доступное на вашем жестком диске место, не сохраняя историю, состояние и не проверяя новые транзакции. По сути, это то же самое, что и запустить узел с минимальной нагрузкой. На практике большинство людей так и поступают, просто присоединяются к пулу фарминга. Получается, что мы вернулись к проблеме с пулами майнинга и централизацией, с которой мы в течение нескольких лет столкнулись в Bitcoin. Но в этих протоколах мы столкнулись с ней в течение нескольких месяцев. Мы подобрались к ней быстрее, потому что, чтобы быть хорошей нодой, которая может верифицировать транзакции, нужно платить свою цену.

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

Решение: Subspace

Как сделать Доказательство Дееспособности с Совместимым Стимулом

Итак, Subspace - это протокол, здесь предоставлен его Технический Документ. Имеется три основных идеи, которые переходят в три уровня стека:

1. Уровень консенсуса, или Доказательство-Архивного-Места (PoAS): как мы можем стимулировать сохранять память для истории? Мы создадим условие, выполнение которого пользователю придется доказывать, чтобы создавать блоки.

2. Как нам поддерживать состояние? Что ж, мы сделаем несколько классов нод. Ноды, которые сохраняют состояние, называются исполнители, и вычисления проводят отдельно друг от друга. Мы позже обсудим это подробнее.

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

Перманентное Архивное Место

Ретранслятор Subspace

https://testnet-relayer.subspace.network/

Сейчас место нод, участвующих в тестнете, используется для того, чтобы архивировать и записывать историю экосистем Polkadot и Kusama. 44 сети сейчас активно архивируются блок за блоком, записываясь в нашу сеть с распределением хранения. Мы готовимся к тому, чтобы делать то же самое и для Ethereum, даже начали проводить кое-какие работы по этому поводу, и, в конце концов, мы сможем делать это для каждого блокчейна! Это наша долгосрочная перспектива, наше видение дорожной карты: построить уровень архивирования данных для сетей и дать возможность создавать интересные вещи поверх этих сетей. Например, мосты, сервисы индексации API - и это лишь немного из того, что мы хотим создать в сети Subspace в будущем.

Уровень Консенсуса

Как договориться о порядке транзакций

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

Уровень консенсуса PoAS

Доказательство Архивного Места

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

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

Плоттинг

Этап Первоначального Запуска

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

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

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

Фарминг

Продолжительный этап вызов-ответ

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

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

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

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

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

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

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

Если все верно, и у нас есть утвержденное доказательство памяти, мы можем создать новый блок!

Как это сравнивается?

Доказательство-Полезного-Места без Разрешения

Чем этот протокол отличается от других? На уровне консенсуса доказательство дееспособности разделяется на две обширные категории: слева у нас бесполезные данные, т.е. случайные данные или намеренно потраченная впустую память. Chia растрачивает место также, как Bitcoin - электричество. Справа у нас полезные данные. В случае Filecoin они сохраняют любые данные пользователя, в нашем же случае мы сохраняем историю блокчейна.

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

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

Мы хотим быть похожими скорее на модель Bitcoin.

Уровень Вычисления

Как договориться об общем состоянии

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

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

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

1. Один тип нод будет ответственен за безопасность сети - это фармеры. Они будут использовать один вид консенсуса, доказательство архивного места.

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

Раздельное Исполнение

Сохраняя Безопасность

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

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

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

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

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

Уровень Памяти

Как убедиться, что данные сохраняются

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

Распределенное Хранение в Subspace

Как хранить и восстанавливать нашу собственную историю

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

В этом заключается несколько аспектов:

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

Чтобы это сделать мы воспользуемся базовыми компьютерными технологиями:

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

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

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

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

Ценообразование платы за хранение

Уровень Приложений

Как Subspace может принести пользу для Ethereum

Давайте поговорим об уровне приложений и о том, какие интересные вещи мы можем сделать для Ethereum!

API Хранения

Как хранить и восстанавливать любые данные

Для начала давайте поговорим об API хранения и о SDK для разработчиков, которые мы используем на данный момент и которые любой человек может использовать для взаимодействия с Subspace - Subspace.js. Имеется два метода: положи и получи, т.е. вы можете написать данные для сети и вы также можете читать данные из сети. И мы относимся к данным как к абстрактным объектам, это может быть файл или запись, и т.д.

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

Обзор

Мы используем это сейчас, чтобы полностью заархивировать экосистему Dotsama. Перейдем к очень общему обзору:

Сверху у нас Polkadot, снизу Subspace. Естественно, у Polkadot есть сеть-реле, как, например, сеть Beacon для Ethereum. Далее идут все парачейны, как цепи-осколки для Ethereum. Мы берем каждый блок из сети-реле и всех парачейнов, превращаем их в транзакции хранения и публикуем в нашей сети. Они включаются в наш блокчейн и сохраняются в нашей тестовой сети. Они также могут быть восстановлены, мы создаем приложение "Relayer", которое это показывает. Приложение доступно на нашем сайте.

Это собрало большой интерес в экосистеме Dotsama, и мы работаем на интеграцией в тестнет Rococo, поэтому это станет стандартным методом синхронизации ноды для тестнета и, в конце концов, будем надеяться, для всей экосистемы. Мы спроектировали все таким образом, чтобы оно было модульным и расширяющимся, т.е. может быть исполнено для любого блокчейна: для Ethereum, для Cosmos, для Solana, для Bitcoin. И в нашей дорожной карте мы планируем внедрить это для всех сетей!

Экосистема Ethereum

Где будут жить все данные?

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

В Ethereum очень много данных, которую приходится выкладывать в сеть, но также там очень много информации, которую не выкладывают. Возможно, вся эта информация должна быть перманентной и децентрализованной, как и сам блокчейн. Если у вас есть NFT, вам наверняка хотелось бы, чтобы изображение этого NFT, или же файл, привязанный к NFT, имел такую же устойчивость, как и информация о владении. А иначе в какой-то момент это владение станет бессмысленным.

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