:RU: Что обновление Vasil привносит в Cardano

Перевод статьи What Vasil upgrade brings to Cardano | Cardanians

Команде IOG все равно, медвежий ли рынок или бычий, она постоянно совершенствует протокол Cardano. Что важно, так это долгосрочное видение. Таким образом, команда обеспечивает то, что ожидает сообщество. Давайте посмотрим, что принесет Cardano долгожданное обновление Vasil.

image

Обновления - это будущее

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

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

Обновление Vasil значительно повышает производительность и возможности протокола Cardano. Обновление включено в версию 1.35.0 ноды Cardano, и сеть готовится к этому. Наиболее важным улучшением в обновлении Vasil является, главным образом, диффузионная конвейерная обработка, которая повлияет на лучшую масштабируемость. Существует также несколько CIPs (Предложение по улучшению Cardano), которые связаны с платформой Plutus.

Диффузионная конвейерная обработка

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

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

Увеличение размера блока и уменьшение времени создания блока имеют ограничения из-за возможностей Интернета. Cardano - это глобальная сеть с нодами по всему миру. Если нода создает новый блок, например, в Европе, блок должен постепенно проходить через другие ноды в Азию, Южную и Северную Америку, Австралию и другие места. Каждая отдельная нода проверяет информацию, прежде чем она сможет распространять ее дальше среди своих одноранговых нод. Это означает, что проходит некоторое время, называемое Задержкой, прежде чем блок достигнет по крайней мере 95% нод в сети. Это время составляет не более 5 секунд в сети Cardano. Задержка, установленная на 5 секунд, - это время, необходимое для гарантированного распространения блока, размер которого не превышает 2 МБ.

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

Обратите внимание, что время создания блока должно быть установлено на большее время, чем Задержка, чтобы обеспечить достаточный запас для распространения блока по сети. В случае Cardano время создания блока теперь установлено равным 20 секундам. Если время на распределение блока может быть сокращено, время создания блока также может быть постепенно сокращено. Это приведет к повышению пропускной способности.

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

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

vasil_FIX1

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

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

vasil_FIX2

Обратите внимание, что только производитель блока (лидер слота) проверяет тело блока в начале распространения по сети. Все остальные ноды распределяют весь блок после проверки только заголовка блока и ссылки в теле блока.

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

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

Давайте подсчитаем, насколько быстрее блок распространяется от производителя блока через 4-х валидаторов блоков, если проверка заголовка занимает 50 мс, а проверка тела - 250 мс. Мы будем считать производство блока в общее время, так как производитель должен проверить тело. Без диффузионной конвейерной обработки проверка всего блока занимает 300 мс на каждой ноде. Таким образом, время распространения от производителя блока до валидатора блока 4 занимает 5 * 300 мс, что составляет 1500 мс (1,5 с).

При диффузионной конвейерной обработке проверка блока занимает только время, необходимое для проверки заголовка (50 мс) и проверки ссылки между заголовком и телом блока, которое составляет 5 мс. Всего 55 мс требуется для того, чтобы блок был проверен должным образом и распространен далее одноранговой ноде. Общее время распределения блоков займет 300 + (4 * 55), что составляет 520 мс.

0*HLwJvUFCTGdW4Epr

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

0*6r3kmLjrEsORVIEl

CIPs, связанные с платформой Plutus

Давайте начнем с CIP-32, которые относятся к инлайновым Datums. Модель расширенных UTXO позволяет пользователям по желанию добавлять в UTXO произвольные пользовательские данные в формате, подобном JSON. Эти данные называются Datum. Datum позволит разработчикам предоставлять скриптам функциональность, подобную состоянию. Пользовательские данные можно рассматривать как состояние локального скрипта. Это состояние имеет только локальную валидность, поскольку оно связано с конкретным UTXO.

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

0*B_Jd94udnGtIYDDu

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

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

CIP-32 предлагает, что Datum может содержать либо непосредственно данные (встроенные данные), либо хэш данных, как это происходит сейчас. Транзакции Plutus позволяют вам выбрать один из подходов.

0*iCINX1muUDjyjGgv

Если бы данные находились непосредственно в Datum, не было бы необходимости вставлять данные в расходные транзакции. Помните, что пользователь все еще может использовать Redeemer в качестве входа для скрипта Plutus.

0*90pc0e71BZiALTMv

Этот новый подход к Datum облегчит работу разработчиков DApp, особенно в сочетании с CIP-31.

CIP-31 предлагает создать новый вид входа, ссылочный вход, который позволил бы вам просматривать выход без необходимости его расходования. Это позволит получить доступ к информации, которая хранится в блокчейне в виде Datums, без необходимости расходования и воссоздания UTXOS, связанные с Datums. Кроме того, можно будет проверить значение, связанное с ссылочным входом.

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

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

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

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

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

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

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

0*sR-_Gh9K_4sqKQy2

Транзакция имеет вход, который UTXO планирует расходовать, и в то же время может также иметь ссылочный вход. Ссылочный вход может быть использован во время выполнения скрипта Plutus. После проверки и включения транзакции в блок UTXO расходуется, но ссылочный вход остается неизменным и впоследствии может быть доступен другой стороне. Таким образом, информация в Datum доступна в течение более длительного периода времени для нескольких пользователей.

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

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

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

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

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

0*lH8WTyqrlUtNCBag

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

Вывод

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

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

// От переводчика: для получения дополнительных переведенных на русский язык статей о Cardano посетите русскоязычный раздел на форуме Cardano. Видеоролики о Cardano на русском можно найти на YouTube канале нашего замечательного амбасадора Тимура Сахабутдинова, а также на канале Чарльз Хоскинсон на русском. Хотите поговорить или задать вопрос о Cardano по-русски? Приглашаем вас в наше уютное сообщество в Telegram. Оставайтесь на связи, все только начинается!