Ну а если более ответственно подходить, то не все так просто как может показаться. Так как L2 у нас децентралайзд, значится и MPC будет использоваться для совместного подписывания батча транз. То есть в пропоузер пушит, а все секвенсоры (MPC модули внутри модуля Sequencer) в листе подписываются под ересью сбатченной конкретным выбранным секвенсором.
● Роль Adapter Module (Он же Bridge) - Эта фулл нода отвечает за пунькание внешних модулей в обе стороны на уровне консенсуса, но execute часть бриджа не является двухсторонней, двухстороннее общение присутствует только с PoS Layer, секвенсором Metis L2 и DA.
Как он это блять делает?
Вся ротационная информация хранится ончейн, которые управляются секвенсорами (помним про MPC) поэтому вся ротация в теории видна ончейн на L2, а управление листом уже контролируется консенсусом. Но так как сейчас это все на MEMO, мы ничоу не сможем почекать☺️
После того как PoS создает листецкий за эпоху, список подписывается MPC и текущий секвенсор закрывает смену создавая транзакцию которая имеет обновленный список с новым секвенсором.
Интересный момент с malicious players - Если секвенсор является malicious, то по прохождению некоторого времени PoS леер пропушит новый список, который всем секвенсерам придется переподписать (MPC) чтобы выбрать нового исполнителя. А у malicious секвенсора просто забирают его стейк (>20k Metis) он же слешинг.
Интересный момент про влияние этого секвенсора на UX для юзера - так как у нас все работает на уровне именно батчинга, а не на уровне RPC, то у нас нет никакой задержки для user-a. Есть только более медленное исполнение на уровне постинга из-за всех этих уровней перепроверки и возможного PENDING-a. Но суммарный TTF в для юзера в плане UX в худшем кейсе может значительно возрасти, поэтому в дальнейшем можно ждать ухудшение по длительности высвобождения ассетов на CEX-ах и тому подобное в виде not-canonical bridge апками (запомните этот момент).
Далее, при условии что все с информацией окей, то MPC нода стопится и подписывает транзакцию на обновление листа, и только лишь потом подписывается в батче и отправляет на L1.
К MPC Module-ю.
Давайте начнем с понятия кто этот ваш MPC, дальше вставка гейния, владельца Миюшки и просто плотного, мохнатого, волосатого, вкусного и сладкого мужчины - @valpaqshub
Когда кто-то что-то говорит про криптографию, все обычно думают: блокчейн, шифры всякие, tls, последнее время к этому добавилось zkp. Но при этом достаточно мало кто знает, что есть такое multi-party computation, когда кто-то хочет что-то посчитать с кем-то, не особо делясь изначальными данными друг с другом. - тут читать фулл
Чем он занимается в Metis?
Он является частью секвенсор ноды и занимается подписыванием, генерацией и всем остальным менеджментом.
Проще и короче:
MPC layer нужен Metis-у для децентрализации при создании и управлении мультиподписями. Где несколько узлов могут совместно подписывать транзакции, что убирает Single Point of Failure и делает систему более устойчивой к атакам, но все еще не полностью защищенной (но это уже другие модули). Также MPC помогает в ротации ключей и поддерживает асинхронное использование множества подписей.
Для ебучих умников:
● Multisig Generation
Процесс генерации ключа (keyGen) начинается с уведомления всех MPC узлов, о создания случайного sessionID и установления связи по p2p каналу. Если у узла есть данные в состоянии READY, они используются; если в состоянии PENDING – возвращается ошибка. (выше был пример с другой стороны) Затем инициирующий узел отправляет сообщение keyGenStart всем узлам MPC, которые создают локальные экземпляры LocalParty и начинают обмен информацией.
● Key Resharing
Процесс пересоздания ключей (key resharing) аналогичен генерации ключей, включая передачу и проверку данных между всеми MPC.