Запрос на обновление — это ключевая операция в Интернет-компьютерном протоколе, позволяющая пользователям вносить изменения в контейнеры (смарт-контракты, размещенные в Интернет-компьютере). Эта статья исследует каждый этап жизненного цикла запроса на обновление и подчеркивает, как вехи Tokamak оптимизируют его конечную задержку.
Предыстория
Для полного понимания жизненного цикла запроса на обновление необходимо знать о некоторых базовых компонентах архитектуры Интернет-компьютера.
1. Контейнер
Контейнеры — это смарт-контракты на Интернет-компьютерном протоколе (ICP), предназначенные для хранения состояния и выполнения кода. Пользователи взаимодействуют с контейнерами, отправляя запросы на обновление, чтобы инициировать операции на смарт-контрактах.
2. Подсеть
Подсеть представляет собой группу узлов, которые размещают и управляют контейнерами. Каждая подсеть функционирует как независимая блокчейн-сеть, позволяя ICP масштабироваться за счет распределения нагрузки между несколькими подсетями. Каждая подсеть управляет уникальным набором контейнеров, и смарт-контракты в одной подсети могут взаимодействовать с другими смарт-контрактами в другой подсети, отправляя сообщения.
3. Копия
В каждой подсети узлы (называемые копиями) хранят код и данные каждого контейнера в этой подсети. Каждая копия также выполняет код контейнера. Это дублирование хранения и вычислений обеспечивает отказоустойчивость, даже если некоторые узлы выйдут из строя или подвергнутся атакам со стороны злоумышленников, смарт-контракты контейнеров могут надежно функционировать.
4. Граничный узел
Граничные узлы отвечают за маршрутизацию запросов к соответствующей подсети и балансировку нагрузки между копиями внутри этой подсети.
Жизненный цикл запроса на обновление
Ниже представлена схема жизненного цикла запроса на обновление в Интернет-компьютерном протоколе:
1. Интернет-компьютер (IC) получает уведомление об обновлении
Запрос на обновление начинается с пользователя, который отправляет запрос с помощью реализации IC-агента (например, agent-rs или agent-js). Эти библиотеки предоставляют удобный интерфейс для взаимодействия с ICP, обрабатывая форматы запросов, подписи и протоколы связи. Затем запрос отправляется на граничный узел для разрешения через DNS.
2. Маршрутизация через граничные узлы
Граничные узлы направляют запросы на обновление к копиям, размещенным в подсети, содержащей целевой контейнер. Метод циклического выбора распределяет нагрузку запросов на F+1 копий для обеспечения производительности и надежности. Здесь F — это порог отказоустойчивости ICP, максимальное количество копий, которые могут выйти из строя в каждой подсети. Для получения дополнительной информации об отказоустойчивости Интернет-компьютера вы можете ознакомиться с этой ссылкой:
internetcomputer.org/how-it-works/fault-tolerance
3. Трансляция запроса на обновление
Как только копия получает запрос на обновление, она использует прерываемые трансляционные примитивы для трансляции запроса другим копиям в подсети. Этот метод обеспечивает надежную доставку даже в условиях сетевой перегрузки, пиковых нагрузок или сбоев соединения и обратной связи.
Прерываемая трансляция крайне важна для эффективной коммуникации между копиями в среде с байетитанской отказоустойчивостью (BFT). Она экономит пропускную способность, гарантирует, что все структуры данных остаются ограниченными даже в присутствии злонамеренных пиров, и поддерживает надежную связь для согласованной обработки обновлений в рамках ICP. Для получения дополнительных технических деталей вы можете ознакомиться с этой статьей, объясняющей решение по прерываемой трансляции:
arxiv.org/abs/2410.22080
4. Предложение блока (создание блока)
Одна копия (назначенная создателем блока) отвечает за создание нового блока с запросом на обновление. Затем создатель блока отправляет этот блок другим копиям в подсети для обработки.
Шаги 4-7 составляют этапы круга консенсуса на Интернет-компьютере, где копии совместно работают над достижением согласия по предложенному блоку. Подробное описание механизма консенсуса вы можете прочитать здесь:
internetcomputer.org/how-it-works/consensus
5. Задержка нотариата
Вводится краткая задержка, называемая задержкой нотариата, для синхронизации сети и обеспечения времени для получения предложений блоков всеми копиями. Эта задержка важна для поддержания согласованного состояния между копиями.
6. Нотариат
На этапе нотариата копии проверяют действительность предложенного блока и соглашаются с его нотариатом. Нотариат — это предварительный шаг к консенсусу, показывающий, что блок соответствует стандартам ICP.
7. Завершение
После нотариата блок будет окончательно подтвержден — все копии в подсети согласны с его действительностью, что гарантирует его принятие и добавление в цепь. Окончательное подтверждение обеспечивает согласие всех узлов по этому блоку, что приводит к консенсусу во всей сети.
8. Выполнение
После завершения блок переходит в этап выполнения, на котором состояние контейнера обновляется в соответствии с запросом на обновление. На задержку в этом этапе влияют несколько факторов, включая:
Сложность кода контейнера: сложность кода контейнера напрямую влияет на скорость выполнения. Более сложная логика или операции с высокой плотностью данных могут привести к дополнительной задержке.
Нагрузка на подсеть: поскольку каждая подсеть обслуживает несколько контейнеров, вычислительные ресурсы делятся, и высокая нагрузка на подсеть может увеличить задержку, поскольку контейнеры конкурируют за вычислительные ресурсы.
В зависимости от активности подсети даже простые операции могут сталкиваться с задержками. Во время пикового использования запросы на обновление могут сталкиваться с задержками, ожидая ресурсов.
9. Совместное сертифицирование
После выполнения копии обмениваются информацией о сертификации внутри подсети, проверяя, правильно ли выполнен запрос на обновление и согласованы ли изменения состояния.
10. Копия отвечает сертификатом
После аутентификации копии отправляют ответ с сертификатом граничному узлу, указывая, что запрос на обновление был успешно завершен.
11. Граничные узлы передают ответы
Наконец, граничный узел передает аутентифицированный ответ пользователю, что означает завершение жизненного цикла запроса на обновление.
Веха Tokamak
Упрощенный процесс жизненного цикла запроса на обновление, описанный выше, значительно улучшен благодаря вехам Tokamak, которые ввели несколько ключевых улучшений для Интернет-компьютера:
Реализация прерываемой трансляции через QUIC: реализованные на протоколе QUIC прерываемые трансляционные примитивы теперь управляют всей коммуникацией между копиями, обеспечивая надежную и эффективную передачу сообщений в сети. Это решение может значительно сократить задержку нотариата, позволяя ускорить консенсус без ущерба для надежности.
Улучшенный маршрутизатор граничных узлов: улучшенная логика маршрутизации в граничных узлах оптимизирует распределение запросов на обновление между копиями, как показано на втором этапе жизненного цикла.
Синхронизация запросов на обновление: введенная синхронизация запросов на обновление позволяет немедленно реагировать на пользователя непосредственно после аутентификации, упрощая и ускоряя последний этап жизненного цикла.
Эти достижения вместе повышают эффективность, скорость и надежность запросов на обновление Интернет-компьютера, создавая более бесшовный пользовательский опыт и более мощный протокол.
Ключевые факторы, влияющие на задержку запросов на обновление
Конечная задержка Интернет-компьютера зависит от нескольких ключевых факторов:
Топология подсети: физическая и сетевую структуру подсети влияет на время кругового путешествия (RTT) между копиями. Более короткий RTT способствует более быстрому обмену информацией, в то время как географическое расстояние между копиями увеличивает задержку.
Нагрузка на подсеть: количество контейнеров и объем обрабатываемых сообщений в подсети влияет на задержку. Поскольку IC функционирует как общая инфраструктура, контейнеры в подсетях с высокой нагрузкой могут испытывать более высокую задержку из-за конкуренции за одни и те же ресурсы.
Конвейерная архитектура: архитектура ICP спроектирована для максимизации пропускной способности за счет конвейерного консенсуса и этапов выполнения. Этот дизайн позволяет нескольким процессам работать одновременно, но это создает компромисс: хотя пропускная способность увеличивается, каждая стадия в конвейере может испытывать дополнительную задержку, ожидая завершения предыдущих этапов.
Дизайн ICP ориентирован на высокую пропускную способность и масштабируемость, балансируя между этими требованиями и компромиссами производительности, присущими распределенным, децентрализованным сетям.
Бенчмаркинг Tokamak до и после ICP
Чтобы измерить влияние вех Tokamak, мы измерили конечную (E2E) задержку трех различных смарт-контрактов, размещенных на ICP. В качестве бенчмарка мы провели тестирование до запуска вех Tokamak, затем повторили тестирование после завершения вехи для сравнения.
Результаты очень обнадеживают и показывают, что пользователи могут ожидать снижения задержки ICP в будущем, что приведет к лучшему пользовательскому опыту.
Для каждого варианта, который мы тестировали, мы предоставили таблицу и график, показывающие E2E задержку от 0 до 99.99 процентиля.
Главная книга ICP
Главная книга ICP — это смарт-контракт, размещенный в подсети NNS, который служит главной книгой для токенов ICP. Пользователи могут взаимодействовать с главной книгой различными способами, но самым популярным dapp и интерфейсом является dapp NNS, который также размещен в подсети NNS.
Мы проводили бенчмаркинг в течение нескольких дней, в течение которых циклически отправляли токены ICP и записывали время от отправки транзакции до получения ответа от ICP (и сертификата, подтверждающего отправку токена). Средняя задержка сократилась с 4.57 секунд до 2.23 секунд, что составляет снижение на 51%.
Интернет-идентичность
dapp Интернет-идентичности размещен в подсети Интернет-идентичности и представляет собой службу совместной аутентификации, работающую на Интернет-компьютере. Если вы когда-либо взаимодействовали с dapp на ICP, вы, вероятно, проводили время, используя Интернет-идентичность для входа. Этот бенчмарк измеряет время, необходимое для входа с использованием службы Интернет-идентичности.
Наши результаты показывают, что средняя задержка времени входа снизилась с 7.12 секунд до 3.9 секунд, что составляет снижение на 45,2%! На рисунке 2 показаны результаты до и после для различных процентилей, которые показывают, что для 50-го процентиля, то есть медианы, время входа снизилось с 6.9 секунд до 3.2 секунд.
Фиолетовая область выделяет время, сэкономленное на каждом процентиле; вы также можете обратиться к таблице 2 для более детального обзора результатов по каждому процентилю.
Подсеть приложений
У нас есть контейнер, размещенный в подсети приложений snjp с 13 узлами, что позволяет нам протестировать улучшения подсети с 13 узлами после вех Tokamak. Наши испытания показали, что средняя E2E задержка снизилась с 2.43 секунд до 1.35 секунд, что составляет снижение примерно на 44%.
Содержимое IC, которое вас интересует
Технические достижения | Информация о проектах | Глобальные мероприятия
Подписывайтесь на канал IC на Binance
Следите за последними новостями
