Multi Message Aggregation — Köprülere Yeni Bir Bakış
Blok Zinciri köprüleri güvenliği blok zinciri ve kripto ekosisteminde en çok çalışılan konulardan biri. Her ne kadar bu konuda çalışılsa da hala ideal köprüyü elde etmiş değiliz. Köprülerin trilemması , köprülerin aynı anda üç özelliğe sahip olamayacağını savunur. Bu özellikler;
- Genelleştirilebilirlik : Zincirler arasında çeşitli veri transferlerine izin vermesi
- Trusless: Zincirlerin iletişimi için duymamız gereken güvenin minimize edilmesi
- Esneklik: Diğer zincirlere entegrasyonunun kolay olması.
Peki bunu aşabilir miyiz?
MultiBridge’e bakalım:
Blok Zincir evreninde her bir zincir aslında birer gezegene benzetilebilir. Bu gezegenler adeta birer kapalı olarak tasarlanmıştır, birbirlerinden haberdar olmayan iki gezegenin iletişimleri de haliyle zor oluyor.
Bu gezegenlerin iletişimini mümkün kılan şeyler ise “köprüler”.
Gezegenlerin her biri kendi içinde farklı standartlara sahip: kimisi çok hızlı dönüyor, kimisinin atmosferi uydu transferleri için yeterince iyi değil…
Blok zincirleri de aynen bu gezegenler gibi farklı standartlarda inşa edildiğinden birbirleriyle iletişimleri çok zor.
Bu gezegenlerde yaşayan canlılar bir gezegenden diğerine varlık transfer etmek için aracılara ihtiyaç duyuyor. Bunun için 3 farklı tipte aracılar ortaya çıkıyor.
(Blok zinciri köprülerini teşbihle anlatacağım, yazının akışı kolay olsun diye köprü çeşidini 3'e ayırdım)
1. tip köprü diyor ki ben 3. bir gezegenden çıkacak karara göre senin varlıklarının transferini sağlarım, bu 3. gezegende gerçekten işleyen bir demokrasi olduğunu iddia ediyor.
3. parti validatör setiyle valide edilen köprüleri buna örnek olarak verebiliriz. Bunların çalışma mantığı basittir, bir zinciri diğerine bağlamak için 3.parti bir aracıya güvenir. Örneğin: Axelar, bir Cosmos zinciri olarak farklı zincirleri birbirine bağlarken kendisi de ayrı bir blok zinciri olarak hizmet veriyor. Axelar’a trustless demek yanlış çünkü 3.parti bir validatör setiyle bağlandığımız ve zinciri kriptoekonomik (Proof of stake) güvenlik ile koruduğumuz için bu zincirdeki herhangi bir açık veya saldırı buradaki varlıkların çalınmasıyla sonuçlanacaktır. Buna karşılık Axelar’ın desteklediği zincir sayısının fazlalığı, turing complete zincirler arası uygulama geliştirmeye müsaade etmesi gibi artıları bulunuyor.
Yani hepsi trade off — trilemmayı hatırlayalım.
2. tip köprü de diyor ki siz bana varlığınızın ne olduğuna dair mesajın en küçük, paket halini verin; ben bu paketi diğer gezegene, içeriğini değiştirmeden, ileteceğim. Eğer şerefsizlik yaparsam gelin diğer gezegende ilettiğim mesajı kontrol edin.
“Optimistik köprüler”
Yukarıdaki anoloji daha çok optimistik köprüleri anlatsa da Light Client tabanlı, ZK tabanlı veya optimistik köprülerin tamamı genel olarak benzer çalışma mantıklarına sahiptir: Bir zincirden aldığı mesajı “diğer zincirde” onaylamak. Mesaj diğer zincir tarafından onaylandığı için 1. tip köprülerden daha “güvenli” olurlar. Connext, Rainbow (Near), IBC gibi köprüler bunlara örnek olarak verilebilir.
Optimistic köprüler, köprüye duyacağınız güveni en aza indirmek üzere (Trust minimized) tasarlanmış olsa da geliştirmek ve AMB haline getirmek zorlu bir süreçtir. Her zincire uygulanmasının , genelleştirilmiş mesaj transferinin zor olmasına karşılık “köprüye duyulması gereken” güven minimum seviyede tutulduğundan bu köprüler de en sık tercih edilen köprülerdendir.
// ZK tabanlı light client köprüleri gerçekten inovatif olmasına karşılık orada da çeşitli fundamental problemler bulunuyor. (Biraz detay bir konu, anlamazsanız geçebilirsiniz) sıradan bir light client, sadece ama sadece konsensusa erişildiğini doğrular. Sıradan bir light client, aynı nonce ile işaretlenmiş birden fazla bloğun olup olmadığını — %51 saldırısını anlayabilecek kapasitede değildir. Bu haliyle de tam anlamıyla trustless bir iletişim sağlanamıyor. Eğer light client ile blok zincirin hem konsensusunu hem de full state’ini onaylayalım derseniz, onaylamak istediğiniz blok zincirin full node’unu ana katmanda çalıştırmanız gerekir. Bir saniye, rollupların tanımını mı yapmış olduk?
Evet, rolluplar tam olarak bunu yapar, DA ve işlem siparişlerini (Ordering) ana katmandan alan bir zincir; ana katmanın garantisinde , sadece ana katmana güven duyarak, köprülemeyi gerçekleştirebilir. Rollupların tüm olayı aslında bu güvenli köprüde yatar. Peki Rolluplar mükemmel mi? HAYIR.
Normalde bir blok zincirde hard fork, full node’lar aracılığıyla yapılır. Light clientler full node’ların çoğunluğunun uyduğu kararları takip ettiğinden sadece konsensusu ispatlayan light client köprüleri hard fork sırasında bir sorun yaşamaz çünkü forklanan zinciri takip etmek için light clientler yükseltmeye ihtiyaç duymaz.
Fakat konsensusu ve state’i ispatladığın light clientlerde, hard forklar sırasında doğru zinciri takip etmek için light clientini de upgrade etmen gerekir. Bu yüzden rolluplardaki köprü kontratındaki light clientin yükseltilmesi büyük bir problemdir. Şu anda birçok rollup, doğru zincirin light clientini takip etmek için doğru light client’i güncelleyecek council’lara güveniyor (Multi sig cüzdanlar). Bu da güveni minimize edeceğimiz dünyada bizi birden güven varsayımlarıyla karşı karşıya bırakıyor.
Bunu çözmek için ortaya çıkan sovereign zincirlerinde ana katmana köprü bulunmuyor, bunun yerine DA sağlanan zincirdeki ordering ve son state zk ile ispatlanıp hard forklar ve upgrade’lerin düzgünce gerçekleşmesi için kullanıcıların light clientlerini güncellemesine dayanan bir akış kurgulanmış. Burada da sovereign rolluplar arasındaki iletişimde birbiriyle köprü kuran aynı DA katmanındaki 4 sovereign rollup’ı düşünelim: yine karşılıklı köprü kontratıyla light clientleri onaylayacakları için bir zincirdeki upgrade’in gerçekleşebilmesi — diğer tüm zincirlerdeki light client kontratını upgrade etmemizle mümkün olacak. Aynı sorun burada da devam ediyor, köprü kontratına “doğru” light clienti söyleyecek birine ihtiyaç duyuyoruz. Bu yüzden ya tüm zincirler toplu hard forka geçip karşı zinciri onayladıkları light client kontratını yükseltecekler (ki sosyal koordinasyonu korkunç zor bir şey) yada multi sig tabanlı köprülere geri döneceğiz. Bu hala çözülebilmiş bir sorun değil ve üstünde uğraşılmaya devam ediliyor.//
Kısaca 2. tip köprüler güvenliği önceliyor fakat her zincire kolayca entegre edilemiyor. Yani burada da bir trade off var.
Optimistik köprüler için:
3. tip köprü de çıkıp diyor ki kardeşim bakın ben iki gezegende de varlığımı tutuyorum, al sana ispat. Sen bana ver şu varlığını, ben ufak bir komisyon ile sana diğer gezegendeki karşılığını vereyim.
A zincirindeki varlığı A zinciride bırakıp, B zincirinde aynı değerdeki varlığı veren köprülere atomic swap tabanlı köprüler diyoruz. Bunların avantajı genel olarak kullanıcı fonlarının çalınma, dondurulma riskinin düşük olması ve esnekliğinin yüksek olmasıdır. Fakat bu köprüler yardımıyla mesaj transferi sağlayamamamız, bu köprülerin kullanım alanlarını çok kısıtlamakta. Yani burada da ciddi bir trade off bulunmakta
Şimdi bunu aşmak için geliştirilmiş Multi Message Aggregation köprüsünü anlatmak istiyorum.
Anlattığım gibi Generalized Message Passing (genelleştirilmiş mesaj transferi) özelliğine sahip birçok köprü var. Her birinin kendi için artı ve eksileri bulunuyor ve birini seçmek çok zor. Hatta geçtiğimiz günlerde Uniswap v3'ün BSC’e deploy edilmesi için dönen tartışmalarda Layer Zero ve Wormhole tarafında ciddi kızışma dönmüştü. Ethereum zincirindeki governance ile diğer zincirlerdeki işleyişe karar vermek için yine aracılara ihtiyaç duyacağımız için köprü kullanmamız zorunlu. Peki, bir köprüyü kullanmak yerine birden fazla köprüyü kullanıp endpoint’lerindeki çıktının çoğunluğuna güvenirsek ne olur? Karşınızda MultiBridge:
Ethereum’daki mesaj birden fazla köprü ile (şu an için debridge, celer ve wormhole destekleniyor) iletiliyor. Bu iletilen mesajın çıktısı eğer 2/3 köprüde aynıysa mesaj diğer zincirde onaylanmış oluyor. Bu sayede bir zincirin trade off’unu kabul etmek yerine köprülerin çoğunluğuna güvenerek aksiyon alabiliyoruz. Eğer köprülerden herhangi birinde hack yaşanırsa onu whitelistten çıkararak sistemi güvenle sürdürmeye devam edebileceğiz. -aynı anda sistemdeki köprülerin %33'ünün hacklenmeyeceğini varsayıyoruz (çok kaotik bir şey olur bu zaten)
Şu ana kadar 8 adet köprü bu MMA köprüsüne entegrasyon için başvurmuş durumda.
- Axelar (submission post here)
- Celer (here)
- deBridge (here)
- Hyperlane (here)
- LayerZero (here)
- Multichain (here)
- Router Protocol (here)
- Wormhole (here)
Yukarıda bahsedilen sistem tamamen governance tarafından yönetilmek üzere dizayn edildi fakat yüksek bir mühendislik gerektirdiğinden kodların yazılması ve güvenlik kontrolleri çok uzun süreceğinden, yine MMA geliştirilmesi fakat doğru mesaj seçiminin 11/15 bir Multi Sig’e devredilmesini öneren bir öneri daha sunuldu.
Sistemin kötü niyetli kullanıcılarda süistimal edilmesi ancak Multi Sig’i n çoğunluğunu ve Köprülerin en az birini hacklemekle mümkün olacağından bu da topluluk tarafından tartışılmakta.
https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148
Burada Connext’in de bir parçası olarak Connext’in yaklaşımının da çok benzer olduğundan bahsetmek istiyorum. Hem AMB olarak optimistik köprü olarak çalışıyor hem de Atomic Swap tabanlı köprü olarak hizmet eden hızlı versiyonu da içinde barındırıyor. Dileyen kullanıcılar full onay bekleyip yavaş ama full Ethereum güvenliğinde işlem yapabilirken, dileyenler de (4.saatin sonunda full Ethereum güvenliğine geçecek şekilde) yaklaşık 1 dakikada rolluplar ve sidechainler arasında işlem yapabilir. Tamamen kullanıcılar hangisini kullanmak istiyorsa onu kullanıyor :)
Hala denemediyseniz:
https://bridge.connext.network/USDC-from-ethereum-to-binance
Okuduğunuz için teşekkürler, biraz gereksiz detaylara girmiş olabilirim ama anlatmak istedim.
İyi günler :)
