Сеть проверки и технического обслуживания
LightКлиент
Для проверки криптографического доказательства для cross-chain сообщения требуется доверенный корень. Обычно криптографическим доказательством является доказательство существования определенного значения Merkle в (вариантном) дереве Merkle, например, дерево Merkle Patricia (MPT) в Ethereum или неизменяемое дерево AVL (IAVL +), используемое в Cosmos, а доверенный корень - это корень Merkle дерева, который обычно включается в блок заголовок. Затем, отправив все заголовки блоков всех заинтересованных блокчейнов в Relay Chain MAP, проблема доступности доверенного корня может быть легко решена. Тем не менее, при постоянных усилиях, направленных на сокращение времени генерации блоков, обработка всех загруженных заголовков блоков в Relay Chain MAP потребовала бы значительных ресурсов, особенно когда мы пытаемся подключить все больше и больше блокчейнов и блокчейнов, таких как Binance Smart Chain, сети Polygon уже производят блоки каждые 2 или 3 секунды. Другая проблема заключается в том, как проверить правильность загруженных заголовков блоков? Конструкция протокола MAP заключается в удалении всех доверенных сторон, поэтому полагаться на доверенные стороны для загрузки правильных заголовков блоков явно не является приемлемым решением. Благодаря развитию технологии SPV и технологии легкого клиентского строительства обе проблемы могут быть решены надежным способом. Основное наблюдение заключается в том, что почти все блокчейны могут достичь консенсуса с очень ограниченной информацией.
Light клиент PoW chain
Chain, подобная консенсусу Накамото, например, Ethereum, новый заголовок блока можно легко проверить, следуя правилам консенсуса, например, хэш-ссылку, а также накопленную работу и т.д. Если сеть Ethereum не будет повторно организовывать более n блоков, то Light клиенту Ethereum необходимо сохранить только n + 1 новейших заголовков блоков, чтобы проверить новые заголовки блоков и автономно обновить свое внутреннее состояние. Учитывая задержку при передаче сообщения по cross-chain, Lightклиенты, построенные таким образом, могут хранить больше заголовков блоков, например, заголовки блоков, сгенерированные за последние 48 часов. При ~ 13-секундном интервале блоков Ethereum Light клиент в Relay Chain MAP должен хранить только заголовки блоков Ethereum объемом 13 тыс. С другой стороны, благодаря внедрению технологии Flyclient количество блоков, загружаемых в Relay Chain MAP, может быть значительно сокращено. Хотя состояние происхождения Lightклиента требует ручной настройки, функция отсутствия доверия не ставится под угрозу, поскольку любой может проверить правильность состояния происхождения. Мы предполагаем, что это в основном то же самое, что и концепция “слабой субъективности”, распространенная в мире Proof-of-Stake.
Light клиент PoW Chain, развернут в других чейнах:
· Храните последние заголовки N блоков.
· Проверьте новый заголовок блока в соответствии с консенсусным протоколом и самообновитесь.
· Доказательство определенных txs: доказательство включения Меркла.
· Сопровождающий: Внесите предоплату за газ с помощью обновления Light-client для протокола MAP и получите вознаграждение от протокола MAP.
Light клиент PoS-сети
Для блокчейнов на основе Proof-of-Stake и BFT создание легкого клиента поначалу может показаться довольно сложным. Благодаря работе команды Tendermint оказывается, что можно создать более эффективный Light клиент. Хотя описание техники может быть довольно пространным, основная идея проста. В таких сетях блоки подписываются группой выбранных валидаторов, поэтому, проверив несколько цифровых подписей, можно легко проверить действительность блока. Набор валидаторов может меняться с течением времени, но в типичных PoS-сетях новый набор валидаторов также должен быть подтвержден старым набором с помощью подписей. Таким образом, имея лишь небольшую информацию о текущем наборе валидаторов, например, вес ставки, открытые ключи каждого набора валидаторов, Lightклиент может легко проверять заголовки новых блоков, а также обновлять себя. Нет даже необходимости загружать все заголовки блоков, только очень немногие, например, те, которые участвуют в cross-chain операции, или проверять обновление набора.
Клиенты Light в Relay Chain MAP инициализируются как смарт-контракты, так что цепочка может быстро добавлять новых Light клиентов для новых блокчейнов, соединенных Relay Chain MAP. Проверка Merkle proof и проверка цифровой подписи имеют решающее значение для создания и эксплуатации клиентов light. Но реализация этих криптографических примитивов с надежностью является одновременно сложной и неэффективной, тем более что различные криптографические примитивы используются в разных блокчейнах. Чтобы облегчить разработку легких клиентов, все виды криптографических примитивов поддерживаются на уровне блокчейна и доступны для EVM через предварительно скомпилированные контракты.
Легкий клиент PoS-сети, развернутый в других сетях:
Храните открытый ключ валидаторов и вес голосов - нет необходимости хранить заголовок блока.
Проверьте новый набор валидаторов (авторизованный предыдущим набором) и самообновитесь.
Подтверждение определенных txs или событий: подтверждение включения Merkle и соответствующая информация заголовка блока (содержит подписи).
Сопровождающий: Внесите предоплату за газ с помощью обновления Light-client для протокола MAP и получите вознаграждение от протокола MAP.
* Примечание: Независимый механизм самопроверки Light-Client может гарантировать окончательность проверки и не требует манипуляций. Начальное состояние будет полностью открыто для общественности командой протокола MAP
Light клиент Relay Chain MAP
Одного поддержания легких клиентов подключенных блокчейнов в цепочке MAP relay недостаточно для двунаправленного межцепочечного взаимодействия в стиле без доверия, протокол MAP требует наличия легкого клиента Relay chain MAP в каждом подключенном блокчейне. В то время как в сети MAP Relay Chain цена на газ может постоянно оптимизироваться, чтобы оставаться как можно более низкой, в других сетях мы должны принять реальность. Поскольку Relay chain MAP использует PoS и IBFT, легкий клиент может быть легко построен в соответствии с описанной выше методикой. Чтобы оптимизировать потребление газа клиентом light в других сетях, MAP relay chain использует совокупную сигнатуру BLS по кривой BN256. Таким образом, проверка подписей валидаторов MAP relay chain может быть сведена к проверке только одной агрегированной подписи с помощью одного агрегированного открытого ключа. Поскольку контракт предварительной компиляции BN256 широко поддерживается блокчейном, совместимым с EVM, потребление газа для обслуживания легкого клиента Relay Chain MAPможет быть уменьшено.
Иллюстрация Межцепочечной сети проверки и обслуживания MAP Protocol
Сопровождающий
Легкие клиенты подключенных блокчейнов в Relay Chain MAPи Lightклиенты Relay Chain MAPна подключенных блокчейнах должны идти в ногу с ростом соответствующих блокчейнов. Это ответственность сопровождающих. Сопровождающие в протоколе MAP постоянно следят за ростом блокчейна цепочки ретрансляции MAP, а также всех подключенных блокчейнов. Новые заголовки блоков Re MAP отправляются во все подключенные блокчейны, чтобы постоянно обновлять легкий клиент цепочки ретрансляции MAP. Тем временем новые заголовки блоков всех подключенных блокчейнов отправляются в MAP Relay Chain для обновления различных Light клиентов, проживающих в MAP Relay Chain. Таким образом, Relay Chain MAPи каждый подключенный блокчейн осведомлены о самом последнем состоянии друг друга и заложили основу для проверки сообщений между чейнами.
После правильной настройки каждый Light клиент может проверять новые заголовки блоков в соответствии со своим внутренним состоянием, а также правилами, закодированными в контракте, так что недобросовестные сопровождающие не смогут обмануть Light клиентов, чтобы они принимали недопустимые заголовки блоков. Или в других мирах безопасность протокола MAP не зависит от надежных ретрансляторов. До тех пор, пока Light клиент правильно инициализирован и реализация правильно соответствует соответствующему консенсусному протоколу блокчейна, корректность Light клиента гарантируется криптографически. Поскольку отправка транзакций в блокчейны потребляет газ, все сопровождающие получают вознаграждение токенами MAP в соответствии с выполненной ими полезной работой, например, количеством отправленных эффективных заголовков блоков.