RSK: масштабируемость

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

Для достижения этой цели мы создали Rootstock (также известный как RSK), первый сайдчейн Bitcoin, запущенный 3 января 2018 года, чтобы отпраздновать 9-й день рождения блока генезиса Bitcoin. Rootstock — это платформа смарт-контрактов, основанная на модели виртуальной машины Ethereum (EVM), которая может совершать транзакции в биткойнах и стейблкоинах (обеспеченных биткойнами) и свободно обменивать их. Это то, что в настоящее время известно как DeFi.

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

Учитывая нынешнее принятие биткойнов в Сальвадоре и экспоненциальный рост, который начинают наращивать Lightning Network и RSK, пришло время пересмотреть наши дорожные карты, чтобы убедиться, что наши платформы как часть стека биткойнов могут обслуживать миллионы людей, не охваченных банковскими услугами. RSK проникает в экономику Латинской Америки, которая разваливается, и биткойн и доступные и безопасные решения DeFi могут быть их единственным вариантом.

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

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

Масштабируемость

Чтобы реализовать видение построения новой финансовой системы на основе RSK, RSK необходимо масштабироваться. Но масштабирование блокчейна — это не просто увеличение количества транзакций, обрабатываемых в секунду. Недавно мы опубликовали статью о различных методах масштабирования (внутреннем, внешнем и разделении узлов) и о том, как мы измеряем масштабируемость узлов в IOV Labs. Важно, чтобы читатель знал эти концепции, чтобы понять параллельные усилия, предпринимаемые сообществом RSK для масштабирования RSK. Мы вкратце вновь представляем 3 основные категории масштабирования:

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

Наш план состоит в том, чтобы масштабировать RSK, сохраняя технологический стек полностью децентрализованным. Наше видение заключается в том, чтобы RSK обслуживала людей в мире, не охваченных банковскими услугами. Делать это можно только поэтапно. Один только биткойн может обслуживать только 1 миллион активных пользователей в день. RSK, используя только внутренние улучшения масштабируемости, может обслуживать 10 миллионов ежедневных активных пользователей (как стейблкоинов, так и биткоин-платежей). Следующий этап эволюции потребует масштабирования с использованием технологий 2-го слоя.

Потенциально мы можем достичь 100 миллионов активных пользователей в месяц, если большинство пользователей совершают транзакции через сеть платежных каналов через RSK. На этом этапе клиенты RSK light должны будут контролировать каналы по низкой цене. Даже если валидиум-роллап в RSK сможет обрабатывать 1 млрд активных пользователей в день, он может не обеспечить достаточную децентрализацию, чтобы быть безопасным для финансовой доступности, поэтому мы ожидаем, что появится еще один уровень протокола. На последнем этапе PCN может быть развернут поверх ZK-Rollup, чтобы достичь целевого показателя в 1 млрд активных пользователей в день. Этот план масштабирования может продлиться от 5 до 10 лет. Недостатком поэтапного масштабирования является то, что все кошельки должны быть адаптированы для подключения к новым транзакционным сетям на каждом цикле масштабирования. Преимущество в том, что мы постоянно растем без централизации. Ожидается, что в процессе масштабирования технология улучшится, так что, когда мы достигнем конечного состояния, стек уже сможет справиться с 10-кратной нагрузкой. Здесь мы представляем картину этого видения масштабирования, хотя новые открытия могут привести к лучшей архитектуре.

Этапы масштабирования экосистемы RSK

Основным недостатком многоуровневого масштабирования является дополнительная сложность и текущая незрелость верхних слоев в экосистеме. В то время как RSK имеет 100% аптайм безотказной работы, все развернутые роллапы на других блокчейнах испытывали нехватку. Это предупреждение о том, что зрелость слоя требует времени, а 5–10-летний план является консервативным. В любом случае, слой RSK готовится к масштабированию за текущие пределы, если в этом возникнет необходимость.

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

Внутренняя масштабируемость

В нашей исследовательской лаборатории IOV Labs мы проводили тесты на улучшенных версиях узла RSKj, и наши тесты показывают, что RSK может обслуживать более 20 миллионов ежедневных активных пользователей (используя как rBTC, так и один стейблкоин) без добавления 2-го уровня, в то время как полные экземпляры узла все еще могут запускаться каждый стандартным ноутбуком. Это может быть достигнуто за счет более эффективного использования ресурсов компьютера для проверки каждой транзакции, например, кэширования определенных данных в оперативной памяти. Мы протестировали экспериментальные версии узла RSKj, которые поддерживают эффективное управление большей частью мирового состояния в оперативной памяти. Это возможно, потому что RSK использует специальную структуру данных под названием Unitrie, предназначенную для этой цели. Первый отчет о масштабируемости RSK Unitrie был выпущен в 2020 году, и вскоре мы выпустим второй улучшенный исследовательский отчет по той же теме, показывающий еще лучшие результаты. Наша работа обеспечивает сжатие состояния, аналогичное сжатию, обеспечиваемому узлом Erigon или попытками бонсай BESU, с дополнительным преимуществом быстрой обрезки неактивных ветвей.

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

Чтобы уменьшить пространство, занимаемое блокчейном RSK, мы можем обрезать старые блоки, как предлагает RSKIP215. Это предложение, которое отбрасывает очень старые блоки, когда есть достаточно кумулятивной работы, подтверждающей блок, сохраняя при этом снимок состояния блокчейна в момент обрезки. Поскольку окончательное удаление старых блоков может быть спорным, мы исследовали другие решения для сжатия блокчейна. Например, мы можем удалить старые доказательства proof-of-work и заменить их агрегированным доказательством кумулятивной работы, подобным FlyClient.

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

  1. Меньше данных: передача одноранговому узлу только тех транзакций блоков, которые одноранговый узел еще не хранит в своем мемпуле. Этот метод повышает пропускную способность только в том случае, если поиск отсутствующих транзакций может быть выполнен за небольшое количество раундов связи, так как циклы передачи данных снижают время передачи. В качестве примера можно привести сверку наборов в компактных блоках.
  2. Более низкие вычисления: Коллеги оптимистично изучают конечное состояние обработки, вкладывая мало вычислительных ресурсов. Это предлагается в COBLO («Распространение сжатого блока с использованием пакета обновления три-состояния», как указано в RSKIP-62). Метод COBLO является инновационным: при передаче блока узел дает одноранговому узлу подсказку о состоянии для более быстрого вычисления конечного состояния попытки, и, следовательно, пир может (оптимистично) продолжить предварительную обработку последующих блоков для построения конвейера обработки. Подсказка может быть неверной, и в этом случае одноранговый узел блокирует исходный узел. В целях безопасности ни в коем случае потенциально недействительное состояние не используется для подтверждения транзакций.
  3. Более короткие пути: В оригинальном техническом документе RSK предлагается метод более быстрой маршрутизации блоков между майнерами с использованием динамических минимальных остовных деревьев, что обеспечит более короткий путь для распространения блоков между майнерами.
  4. Меньшие блоки: некоторые части блока могут быть сжаты во время распространения блока (потому что они могут быть восстановлены позже) или удалены из хранилища для старых блоков. Одной из таких частей являются данные фильтра блума заголовка, как указано в предложении по сжатию фильтра Блума (RSKIP-194). Эти данные могут быть заменены хешем, так как узлы перестраивают эти данные после обработки блока.

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

Наконец, исследовательская группа уже несколько месяцев работает над PoC для параллельной обработки транзакций для RSK (на основе RSKIP-144), и мы скоро увидим результаты этого исследования с фактическими тестами того, как параллельная обработка улучшает RSK.

Масштабируемость RSK с разделением узлов

Основным активным направлением исследований масштабируемости с разделением узлов на RSK является облегченный клиент RSK. RSK извлекает выгоду из легкой, быстрой проверяемой функции доказательства работы, которая ускоряет проверку кумулятивной сложности RSK на устройствах с ограниченными ресурсами, таких как мобильные телефоны. Чтобы сделать синхронизацию блокчейна действительно быстрой для легких клиентов, требуется интеграция FlyClient в RSK, что является консенсусным изменением. Напротив, Ethereum EtHash PoW делает проверку FlyClient проблематичной, так как кэш EtHash необходимо пересчитывать для каждого образца, или образец должен предоставлять длинное доказательство Меркла. Это может вывести RSK на передний план использования легких клиентов. Исследовательская группа IOV работала в 2020 году над созданием PoC легкого клиента. Облегченный клиент может выполнять синхронизацию заголовка и состояния. Однако код PoC нуждается в дополнительных проверках и дополнительной доработке. Работа над легкими клиентами должна продолжиться в 2022 году и быть интегрирована в эталонную реализацию RSK.

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

Внешняя масштабируемость в RSK

Параллельно с внутренними усилиями по масштабированию наше сообщество сплотилось вокруг двух параллельных усилий по внедрению масштабирования второго уровня в RSK: Rollups и сети Lumino PCN.

Накопительные пакеты на RSK

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

Хотя накопительные пакеты могут обеспечить выполнение смарт-контрактов, аналогичное RSK, мы ожидаем, что роллапы будут активно использоваться для платежей. Высокооптимизированный транзакционный накопитель — ZkSync 1.0. Исследовательская группа IOV Labs портировала zkSync 1.0 на RSK, и вскоре проект может увидеть свет в основной сети RSK.

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

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

С этой целью в IOV Labs мы начали работать над тем, чтобы сделать RSK платформой наиболее доступной для транзакций с обязательствами L2. Например, мы создали наше предложение для эфемерных calldata (RSKIP-281). Это реальное снижение стоимости calldata, которая используется в основном для обеспечения доступности данных. Например, он позволяет накопительным пакетам периодически отправлять данные транзакций или различий состояний в блокчейн RSK с меньшими затратами, и эти данные могут быть навсегда отброшены после того, как накопительный пакет опубликовал разницу состояний, сжимающую изменения многих меньших различий состояний (в случае сверток ZK) или транзакций (в случае оптимистичных сверток).

Кроме того, RSK должен поддерживать эффективную проверку SNARK и STARK для поддержки ZK-Rollups. Для ZK-роллапов, которые в полной мере используют эфемерные calldata, и для оптимистичных ролл-апов важно иметь возможность хешировать calldata с помощью ZK-дружественной хеш-функции. Это можно улучшить с помощью предварительной компиляции.

С точки зрения безопасности, существующая кривая, поддерживающая операции сопряжения в Ethereum и RSK, обеспечивает примерно 96 бит безопасности (на основе новых математических результатов). Этого недостаточно для построения финансовой системы будущего. Требуется не менее 127 бит безопасности, и кривая BLS12–381 должна поддерживаться, как предложено RSKIP-188.

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

Когда выход рассчитан по времени, лучший подход — позволить накопительному контракту увеличить интервал вывода, если он обнаружит временную перегрузку в блокчейне. Используя контракт предварительной компиляции BlockHeader (RSKIP-119), контракты RSK могут запрашивать лимит газа и газ, использованный для последних 4000 блоков, и динамически обнаруживать перегрузку, что невозможно в Ethereum. Тем не менее, это можно было бы упростить, разрешив контрактам запрашивать индекс перегрузки с помощью одного вызова контракта.

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

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

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

PCN на RSK

RSK имеет собственную сеть платежных каналов (PCN): сеть RIF Lumino. Однако из-за низких транзакционных издержек в RSK сеть Lumino была ненужной для пользователей RSK и, как следствие, не получила широкого распространения. Это может измениться в ближайшие годы, поскольку RSK растет, а финансовая доступность требует самых низких комиссий за транзакции.

С технической точки зрения, теоретически, односторонний канал финансирования может быть создан путем связывания определенных указанных средств с определенным непрозрачным элементом данных. Это так же просто, как вставить значение в сопоставление. Данные представляют собой просто хеш всей информации о канале, включая адрес контрагента (или, что еще лучше, включая совместный открытый ключ MuSig2). Взаимно согласованное пополнение канала или частичный вывод требует замены данных о состоянии канала, проверки одной дополнительной подписи и осуществления перевода (менее 20 тыс. газа, если токен rBTC, и ~ 30 тыс. газа, если это ERC20). Если предположить, что у пользователей с низким доходом будет открыт один канал с хабом, то пользовательский кошелек будет двухрежимным, как предложено в этой статье, и если каналы будут обновляться каждый месяц, то количество активных пользователей, которых может поддерживать PCN, примерно аналогично количеству ячеек хранения, которое может поддерживать RSK Unitrie. Как мы показали в предыдущем разделе, и мы рассмотрим больше в следующей подробной статье, это находится в диапазоне десятков миллионов в оперативной памяти ноутбука, поэтому RSK потенциально может поддерживать десятки миллионов активных пользователей PCN в месяц, выполняя тысячи платежей PCN в секунду.

Сборник предложений

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

  • Доказательство уникального хранилища блокчейна (PUBS)
  • Хеш-функция, совместимая с STARK и SNARK Предварительная компиляция
  • Безопасные и эффективные операции сопряжения для проверки SNARK (RSKIP-188)
  • Параллельная обработка транзакций (RSKIP-144)
  • Конвейерная проверка блоков для улучшения синхронизации за прошлые периоды
  • Синхронизация моментальных снимков
  • Аренда склада (RSKIP-240)
  • Эфемерные данные вызова (RSKIP-281)
  • Эффективное управление попытками в памяти
  • Удалите старые доказательства PoW и замените их агрегированным доказательством кумулятивной работы, подобным FlyClient.
  • Поддержка Flyclient в заголовке блока
  • Улучшенные протоколы маршрутизации блоков
  • Компрессионный фильтр Блума (RSKIP-194)
  • Дифференциальная передача блоков (т.е. компактные блоки)
  • Конечные подсказки состояния (RSKIP-62)

Итог

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

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

Источник