● Applying the Signature
Процесс подписания (keySign) похож на keyGen, включающий передачу и проверку данных. MPC служба подписывает пакет с параметрами: batchID, signHash, и возвращает значения подписи r, s, v.

● Deletion of Signature
Удаление ключа (keyDelete) включает отправку сообщения KeyDeleteMessage всем узлам для запроса на удаление ключа без операций с библиотекой TSS.

● Asynchronous Usage
Модуль MPC поддерживает асинхронное использование множества мультиподписей. Включает:
● TSS (Threshold Signature Scheme): Алгоритмы мультиподписи и хранение ключей (публичные, частные, ID всех сторон).
● Локальное хранилище ключей: Сохранение и шифрование информации о ключах в локальном kv хранилище (levelDB).
● Поля данных ключей: keyId, keySsessionId, data, status (PENDING, READY, ERROR).
● Канал Tendermint: Библиотека для p2p коммуникации и консенсуса (cosmos-sdk как заявлено).
● libp2p: Библиотека для p2p сетевой коммуникации, поддерживающая информацию между узлами MPC.

А теперь давайте соберем все по крупицам и поймем последовательность.
Пользователи пушат транзакции с клиента, подписывают их и отправляют в сеть через RPC Module. L2-Metis транзакции перенаправляются на module Bridge and Adapter, который общается с уровнем PoS чтобы передать ему транзакцию в батч.
Имея на лапках проверенную информацию PoS-ом и B&A, секвенсор создает блок и передает его в P2P сеть. Транзакции с L1 обрабатываются исключительно выбранным в ротации секвенсором, создающим блок с одной транзакцией. B&A отслеживает статус tx, а другие секвенсоры сохраняют блок после проверки подписи секвенсора.
Далее модуль batcher создает пакет данных с транзакциями и запрашивает подпись у модуля MPC. Уровень PoS проверяет подпись пакета транзакций секвенсора и инициирует процесс подписания MPC.
После подписания пакетов узлом MPC, они отправляются в сеть DA.
Verifier, синхронизированный с DA, проверяет целостность пакетов, гарантируя, что финализированный номер блока совпадает на обоих layer-ах. TTF на L2 достигается только после ротации секвенсоров и достижения консенсуса между 2/3 секвенсоров. Контракт State Commitment Chain на DA подтверждает финализацию пакетов, которые отправляются примерно каждые 30 минут.
Кейс с проблемой
Если транзакция была создана во время ротации, значит она будет в листе ожидания до новых выборов. Если ротации не происходит, значит секвенсор выборов не будет и ваши средства застряли как и у всех других. Но застревает она не на L2, а в очереди L1, эдакий Escape Hatch, но без ручки так как юзер сам не может пропушить и исполнить эту транзакцию на самом L1, а значит финализация невозможна до тех пор пока секвенсор offline.

В чем же главный вопрос и смысл поста?

Почему код у Metis такой же как у Heimdall?
https://github.com/MetisProtocol/themis/blob/main/bridge/setu/util/types.go
https://github.com/maticnetwork/heimdall/blob/master/bridge/setu/util/types.go

Вот две ссылки с рандомными но одинаковыми файлами. Можете зайти в большинство файлов и они просто немного изменены, офк форкать это не грех, но вопросики есть.

И собственно возникают несколько дополнительных вопросов.
● Значит ли это, что Polygon сделал децентралайзд секвенсор еще в 2021 или это все еще не финалочка?
● И если Polygon pepermint, то значит Metis родил гибрид pepermint-a и tendermint-а (форк форка)?
● Почему тогда TTF ± станет равен Polygon?