Selamlar herkese, ben Doğan. Bu post Connext’in kurucularından olan Arjun Bhuptani’nin medium yazısının çevirisidir. Bunu çevirmemdeki asıl amaç, yazı serisinin Connext’in çıkış amacını çok iyi anlatması. Hazırsanız “Mesajlaşma Köprülerine Giriş” yazımıza başlayalım: 

Geçtiğimiz yıllarda kripto ekosistemi, en kötü hacklerini köprü protokollerinin hatalarından kaynaklı yaşadı. Bu durum, köprü mimarisi için en iyi uygulamaların eksikliği ve sürekli artan Externally Verified (yani köprüleme için 3. parti bir aracıyı kullanan) köprü projelerinin geliştirilerine şu soruyu düşündürdü:

Güvenli bir cross chain geliştirme mümkün mü?

Geçen sene Connext’in Amarok güncellemesini geliştirirken asıl odaklandığımız şey, bu soruyu cevaplayabilmekti. Fark ettiğimiz şey şuydu: İlk ilkelerden başlayarak bir köprü inşa etme sürecini tekrar düşünmemiz gerekiyor:

• Bir mesajla köprüsündeki bileşenler nelerdir? 

• Bu bileşenlerden hangilerine en çok güvenmemiz gerektiriyor ve hangileri güvenlik riski yaratıyor? 

• Güvenlik riski yaratan bu bileşenlerin riskini nasıl dengeleyebilir yada azaltabiliyor?

Bu yazı serisinin amacı yukarıdaki soruları yanıtlandırmak ve bununla beraber bizim (ve daha geniş topluluğun) köprüleri düzeltmek için nasıl çalışabileceğimize inandığımızı anlatmaktır.

Köprü Nedir? 

Hadi önce en temelden başlayalım, sahi köprü ne demek? Köprü terimi oldukça farklı anlamlara gelir ve aşağıdaki tanımlardan herhangi biri onu açıklayabilir:

• Zincirler arasında token transferi yapabildiğin bir uygulama bir arayüzü.

• Zincriler arasında token transferi yapabilmeni mümkün kılan bir protokol.

• Bir zincirden diğer zincire çeşitli mesajlar yollayabilmenizi mümkün kılan bir mekanizma.

Konuları daha da karmaşık hale getirmek için 3. mekanizma; zincirler arası mesajlaşma protokolü, genelleştirilmiş mesaj transferi sistemi veya birlikte çalışabilirlik protokolü olarak da adlandırılır. Bu adlandırmaların faydalı olmaktan çok, akıl karışıklığı yarattığı açıktır. Hatta bazı projeler 3. mekanizmanın bir köprü olmadığını, köprü kurmanın çok ötesinde olduğunu iddia ediyor. Ancak bu durum, projelerin kendilerini terimlerden ayırmaya yönelik semantik bir çabasından fazlası değildir. 

Bu yazının amacı doğrultusunda, 3. mekanizmanın tanımı için “Mesajlaşma Köprüsü” terimini benimseyeceğiz. (Çünkü bu, uygulamaya özel köprülerin temelini oluşturan temel ilkedir.) Biz ayrıca uygulamaya özel köprüleri de onların kullanım alanlarına göre ayıracağız - Örneğin: NFT köprüsü yada token köprüsü. 

Mesajlaşma Köprülerinin Akışı:

Bugün birçok farklı mesajlaşma köprüsü altyapısı var fakat tüm mesaj köprüleri hemen hemen aynı temel yapıya sahiptir. Bu yapı aşağıdaki üç bileşeni içerir (görselleştirmek için en iyi yol bunları katman olarak ifade etmektir) 

Tranport: Veriyi bir zincirden diğer zincire iletmek

Onaylama (verification): Yukarıda bahsedilen verinin doğruluğunu onaylamak. 

Yürütme: Köprülenmiş veriyle bir şey yapmak.

Haydi her bir katmanın nasıl çalıştığına bakalım:

Transport: Bir verinin, bir zincirden nasıl okunduğu ve verilerin doğruluğu hakkında herhangi bir varsayımda bulunmadan diğer zincire nasıl iletildiğini iletir.

Transport, genel olarak, verinin gönderildiği zincirdeki köprü sözleşmesindeki bir “Outbox”u (giden kutusunu) izleyen ve ardından ilgili veriyi hedefteki zincirin köprü sözleşmesindeki “Inbox”a (gelen kutusuna) gönderen bir veya birden fazla zincir dışı aktör tarafından yapılır. 

Blok zincirlerinden okumak ve blok zincirlerine yazmak için bulanan hazır bileşenleri kullanarak bu transport’u oluşturmak oldukça basittir. ** **

Transport katmanında hack yada diğer tasarımsal hata riski oldukça düşüktür. Burada yaşanabilecek en kötü durum, mesajların zincirler arasında transfer edilememesi yani köprümüzün liveness’inin bozulmasıdır. Bu konuda çalışan subgraph ve “Relayer” ağları gibi daha merkeziyetsiz ve hataya dayanıklı aracılar, buradaki liveness durumunu korumak ve transport katmanının açık kalmasını garantilemek için kullanılabilir. 

// Yani özetle Transport katmanını dizayn ederken düşünmeniz gereken şey ,güvenlik standartları belli olduğundan, transport katmanının sürekli aktif olarak hizmet verdiğinden emin olmanızdır. //

Verification 

Verification, crosschain iletişimin nasıl güvenli hale getirildiğini anlatır. Zincirler arasında veri transferi sağlandıktan sonra Verification katmanı verinin çıktığı katmandaki veriyle verinin iletildiği katmandaki verinin  aynı olduğundan emin olmak için çeşitli mekanizmaları kullanır. 

Zincirler arasında iletilen bir mesajın geçerli olduğunu nasıl onaylayabiliriz? Kendi güven varsayımlarına, gecikme sürelerine ve karmaşıklık (mimariyi karmaşıklaştırırsanız hata yapma şansınız artar.) trade off’una sahip çeşitli onaylama yöntemleri bulunmakta.** **

Optimistik Köprüler ve İnteroperability Trilemma yazılarımızda bu yöntemlerin bir kısmını ele alıyoruz. Bu yazı serisinin sonraki gönderisinde köprü mesajlarındaki doğrulama mekanizmalarının nüanslarını daha derinlemesine inceleyeceğiz. 

Bu yazıdan çıkarılması ve anlaşılması gereken en önemli nokta: mesaj doğrulamanın köprüler kurmanın zor kısmı olduğudur. 

Verification katmanları; karmaşık kriptografik veya harici güven varsayımları gerektiren, bağımsız bir zincirdeki “güvenilmeyen” bir kaynaktan gelen çeşitli ve bilinmeyen verileri güvence altına almaya çalışır. Bir Verification katmanı güvenli olsa bile, güven varsayımları en aza indirilmemişse çeşitli %51 ataklarına sebebiyet verebilmekte. 

Bu zorluklar, Verification katmanlarını denetlemeyi oldukça zorlaştırır. 

Neredeyse tüm büyük köprü saldırıları, belirli bir kapasitede mesaj doğrulamasındaki hatayı içeriyordu. Doğrulama katmanları saldırıya uğradığında, saldırganlar mesajlaşma köprüsü tarafından kontrol edilen her şeye ayrıcalıklı erişim elde eder. Örneğin zincirler arasında köprülenmiş “sentetik” kilitli tokenler. Bu nedenle, biz (ve diğerleri), uygulama geliştiricilerinin kendi mesaj doğrulama mekanizmalarını geliştirmemelerini şiddetle tavsiye ederiz. Bu katmandaki hataların sonuçları yıkıcı olabilir…

Yürütme: 

Yürütme katmanı, bazı verilerin zincirler arasında taşınmasından ve doğruluğu onaylandıktan sonra hedef zincirde bir veya birden fazla fonksiyonu tetikleyerek bir hedef sözleşmeyi yürütmekten sorumlu bir dizi zincir dışı aktördür. Köprü yürütme katmanı, hedef zincirdeki sözleşmeyi çağırmak için geliştiricilerin ücret ödeyerek ve verinin çıktığı zincirdeki mesajlaşma köprüsü arayüzüne çağrı göndererek oluşturduğu şeydir.

Çoğu durumda yürütme katmanları ya verileri orijin zincirdeki merkle rootlarına ekler (ardından hedef zincirdeki merkle kanıtlarını kullanarak bu verileri paketinden çıkarır.) ya da blok başlıklarını kendileri aktarır (hedef zincirde storage kanıtları çalıştırır). Bunun asıl nedeni Transport ve Verification’ın oldukça pahalı olmasıdır. (özellikle de light client başlığı onaylaması gibi trust minimized metodlar) Bu nedenle işlem başına maliyetlerin birleştirilme yoluyla düşürülmesi gerekir.** **

Yürütme katmanları mesajların onaylama (verification) riskini tamamen devralır, ancak kendilerinin risk ve güvenlik profilleri düşüktür. Yürütme katmanı, mesajları birleştirerek/gruplandırarak ve onları daha düşük katmanlara geçirerek işler. Ama bu etkileşimler tipik olarak oldukça minimaldir ve denetlemesi kolaydır. Yürütme katmanı kontratlarının birincil sorumluluğu fee’yi dağıtmak ve likitiditenin ödenmesi olduğundan, bu katmandaki hack genellikle yalnızca fee gelirlerinin çalınmasını veya ağı işleten zincir dışı aktörlerin fonlarının kaybıyla sonuçlanacaktır. Bunların tümü Verification katmanındaki hack’lere göre genel anlamda zincire daha az zarar verecek etkiye sahiptir.

Özel Durum: Hızlı Yürütme:

Yürütmenin ilginç ve yeterince takdir edilmeyen bir yönü, söz konusu etkileşimi içeren mesaj taşınmadan ve doğrulanmadan önce  bazı crosschain etkileşimlerini tamamen güvenli ve trustless (güvene en az ihtiyaç duyulacak şekilde) işleyebilmesinin mümkün olmasıdır.

Bu kavram, optimistik rollup köprülerindeki hızlı likidite sistemlerinin Eğer Alice Optimism’den Ethereum’a 100 USDC gönderirse, Alice  fonlarına erişebilmek için 7 gün beklemek zorundadır. Bu süreyi kısatlamak için Alice Bob’a (Ethereum’da halihazırda 100USDC’si olan) Ethereum’a hızlıca parayı çekmek için fee ödeyebilir. Bob 100 USDC’sini Optimism köprüsünden alabilir. Bob 7 günlük ödemenin sonunda kendisine ödeme yapılacağının garantisi olduğu için, Alice’e USDC’yi önden ödedi. 

Hızlı likiditenin arkasındaki temel prensip, hızlı yürütme olarak genelleştirilebilir. Alice zincirler arasında 100USDC transfer etmek yerine, Bob’dan kendisi için kendi fonunu kullanarak bir sözleşmeyi çağırmasını isteyebilir. Bob, Alice’in zincirler arasında “yavaş yürütme yolunu” çağırdığını görebildiği sürece gelecekte ödeme alacağına dair zincirüstünde kanıta sahiptir.

Bu mekanizma, Alice’in genel bir fonksiyonu - yani fonksiyonu çağıran kişinin kim olduğunu kısıtlamayan bir fonksiyonu çağırmak istediği her duruma uygulanabilir. Örneğin: Alice bir DAO ise ve hedef fonksiyonunun bir tek DAO değiştiricisi varsa o zaman Bob’un Alice’in işlemini hızlı şekilde yürütmesi mümkün değildir // çünkü bu fonksiyon herkesçe çağrılamaz. 

Toparlayalım: Yukarıdaki tartışmalardan açıkça anlaşılmalıdır ki: Eğer daha güvenli mesajlaşma köprüleri inşa etmek istiyorsak güvenliğe ve verification katmanına duyulan güveni azaltmaya öncelik vermeliyiz. 

** **

Bir sonraki yazımızda, ilk etapta tek ve güvenli bir zincirler arası mesaj verification katmanı oluşturmanın neden bu kadar zor olduğunu inceleyeceğiz. Ardından, mesaj verificatiın için mümkün olan en iyi yolun ne olduğunu ve o yola vardığımızda güvenliği nasıl optimize edeceğimizi belirleyeceğiz.

**

**