Тема 6: Криптография в бриджах

Какая криптография используется в бриджах, TSS/MPC, проблемы масштабируемости и реальные примеры из рынка «как делать не надо».

Александр Николаев, Ex-Symbiosis (ко-фаундер), преподаватель Ethereum в МФТИ

Transcript

1. 🔗 Cross-Chain Bridges: Что это и зачем они нужны? • Кроссчейн бриджи позволяют передавать активы и данные между несовместимыми блокчейнами. • Без бриджей экосистемы остаются изолированными — нельзя перевести токен из Ethereum в Solana. • Бриджи — инфраструктура для интероперабельности и ликвидности.
2. 🧠 Why Cryptography is at the Core • Блокчейны не доверяют внешним данным → всё, что приходит «снаружи», должно быть доказано криптографически. • Бриджи опираются на: ◦ Подписи (ECDSA, BLS, Threshold) ◦ Хеши и Merkle Proofs ◦ zk-SNARKs или zk-STARKs
3. 📈 Почему кроссчейн бриджи — это важно? • По состоянию на 2024 год, через бриджи передано более $100 млрд в эквиваленте. • Бриджи являются связующим звеном между L1 и L2, а также между экосистемами (ETH, Solana, BNB, Cosmos и др). • В них замкнуто огромное количество TVL — активов пользователей. • Именно бриджи чаще всего становятся мишенью хакеров — более $2.5 млрд украдено в 2021–2024 гг. • Ошибки в криптографии бриджей — главная причина этих атак.
4. 🧩 Классификация кроссчейн бриджей
5. ⚙ Atomic Swaps • Используют HTLC — Hashed Time-Locked Contracts. • Протокол: обе стороны блокируют активы и обмениваются секретом. • Если одна из сторон не выполняет условия — актив возвращается через timeout. • Ограничения: требуется онлайн-участие обеих сторон, сложный UX. • 🔐 Криптография: хеш-функции (SHA2), time-lock, подписи (ECDSA).
6. Требования к обмениваемым валютам 1. Time verify (TimeLock)—Example: Funds could only be spent after 1 week; 2. Hash function verify (HashLock)—Example: Funds could only be spent when a challenge question (“hidden” by hash) be discovered; 3. Visible hash input (Public Pre-image)—Example: It’s possible see challenge answer by looking transaction data.
7. How it works successfull trade of 1 BTC to 10 ETHs between Alice and Bob. 1)Alice generates a random value (secret), execute a hash function and obtain hashedSecret; 2)Alice transfer 1 BTC to smart contract. To redeem funds the following conditions need to be true: A) The transaction must contain the secret value; B) The recipient must be Bob’s BTC address; C) The transaction must be made within 48 hours of the contract creation.
8. How it works 3)Bob transfer 10 ETHs to smart contract. The contract is similar to that created by Alice: A) The transaction must contain the secret value; B) The recipient must be Alice’s ETH address; C) The transaction must be made within 24 hours of the contract creation.
9. How it works 4)At this point the funds of Alice and Bob are under contracts control and the can be spent only if the secret value is know. How Alice who generated this value, she is able to redeem to her wallet the 10 ETHs sent by Bob. x
10. How it works Analyzing the last transaction of Alice, Bob is able to know the secret value (Public Pre- image) and have access to the 1 BTC and finalize the trade. x x
11. And if something goes wrong? 1. If Bob does not create his contract, does Alice get his 1 BTC frozen? No. To simplify the above explanation, another condition that the contract has been omitted is: After 48 hours of contract creation, Alice can refund. Bob is the exclusive recipient of funds only within the 48-hour window, after that period only Alice can receive them. 2. The same goes for Bob, who after 24 hours can refund if Alice does not revealing the value of secret by redeem the 10 ETHs. 3. The timelocks are distinct (48h and 24h) because otherwise it would be possible for Alice to redeem the ETHs at the end of the deadline and still have the possibility to refund her 1 BTC if Bob did not redeem quickly.
12. UX of atomic swaps
13. ⚙ Light Client Bridges • Основаны на проверке состояния целевой цепи без участия посредников. • Используют заголовки блоков и Merkle-доказательства для подтверждения событий. • Примеры: NEAR Rainbow Bridge, zkBridge, Succinct. • Полностью trustless, но ресурсоёмки (особенно для L1→L1). • 🔐 Криптография: Merkle Trees, ECDSA/BLS, zk-SNARKs или zk-STARKs(zkBridge, Succinct)
14. The core idea behind the bridge is that it implements two light clients: 1. An Ethereum light client implemented in Rust as a NEAR contract; 2. A NEAR light client implemented in Solidity as an Ethereum contract;
15. trustless setup comes with some tradeoffs: • Every block from each chain needs to be actively verified. Currently, Rainbow bridge verifies Near block headers only once in 4 hours (otherwise it would cost a lot of money) meaning users need to wait for 4–6 hours for their Near to ETH transactions; • You can’t really build a bridge with this design between ETH and BSC or ETH and Polygon, cuz of consensus incompatibility; • You need to work around every edge case of both connected blockchains such as forks, chain split e.t.c raising the complexity of such a solution enormously; • Rainbow bridge is not really trustless, but rather “optimistically” trustless, meaning that it relies on fraud-proof techniques.
16. ⚙ Ext. Validators / MPC • Используют стороннюю сеть валидаторов, которая следит за событиями в одной цепи и подписывает сообщения для другой. • Подпись создаётся через threshold-схемы: подписи объединяются только если достаточное число валидаторов согласны. • Примеры: Wormhole, Multichain, Axelar. • Компромисс между UX и децентрализацией: быстрее, но требует доверия к валидаторам. • 🔐 Криптография: Threshold ECDSA, BLS, MPC протоколы.
18. ⚠ Проблемы MPC-подписей и масштабирования • MPC-подписи сложны в реализации и чувствительны к синхронизации участников. • При увеличении числа участников растёт задержка и нагрузка на сеть. • Число раундов коммуникации критично влияет на производительность. • Безопасность зависит от наличия честного большинства и отказоустойчивости. • Для масштабируемых мостов важно минимизировать количество раундов и коммуникацию.
19. 🧊 FROST: Быстрые threshold-подписи • FROST (Flexible Round-Optimized Schnorr Threshold Signatures) — протокол от IETF. • Поддерживает threshold-подписи с минимальным количеством раундов. • Подпись может быть создана асинхронно, участники могут не взаимодействовать напрямую. • Эффективно масштабируется до десятков/сотен участников. • Подходит для бриджей, где важно быстрое подтверждение событий при высокой надёжности.
20. 💥 Multichain Hack ($120M+) • MPC-ключи управляющих были скомпрометированы (возможно, одним из самих операторов). • Ключи хранились централизованно без аппаратных модулей безопасности (HSM). • Не было механизма отзыва или ограничения полномочий одного участника. • Взлом показал риски неправильного применения MPC в продакшене.
21. 💥 Multichain Hack: Технические детали • Multichain использовал собственную библиотеку для ECDSA-подписей с MPC. • В реализации повторялось значение `k` — nonce, используемый при подписи. • Это нарушает безопасность ECDSA: при одинаковом `k` можно вычислить приватный ключ. 📉 Причины: ◦ Библиотека была проприетарной и неаудированной. ◦ Не использовались проверенные протоколы (GG18, GG20, FROST). ◦ Не было защиты уровня HSM или ротации ключей. 🛡 Уроки: ◦ Не оптимизируй криптографию без доказательств и аудита. ◦ Повторение `k` = автоматическая компрометация ключа. ◦ Используй battle-tested библиотеки и схемы подписей.
22. ✅ Заключение • Бриджи — один из самых уязвимых компонентов Web3. • Безопасность бриджей = хорошая криптография + правильный trust model. • Нет универсального решения — всегда компромисс между скоростью, UX и безопасностью.