Chainlink CCIP’ye Teknik Bakış
Chainlink Evreni’nin mevcut son üyesi CCIP, büyük bir atılımla 2023 Temmuz’unda Paris’te duyuruldu.
CCIP’yi incelemeden önce bazı terimlere göz atmamış gerekiyor:
Cross-Chain DApps
Blockchainler üzerindeki bir çok uygulama, ilk olarak belirli bir zincir üzerinde hayatına başlamıştır. İlerleyen zamanlarda bir çok farklı blockchain ağı geliştirilmeye başlanmış ve kullanıcıların bir kısmı bu yeni blockchainler üzerinde işlem yapmaya başlamıştır.
Fakat bir şey eksiktir. Yeni Uygulamalar :)
Kullanıcı güvenini kazanmış bu eski uygulamalarımız, Chainlink CCIP gibi “Cross-Chain Interoperability Protokolleri” kullanarak farklı blockchainler arasında işlem/veri paylaşımı ve iletişim sağlar.
Bu sayede hem daha fazla likiditeye hem de yeni kullanıcılara kapısını açmış olur.
Interoperability
Yazının yazıldığı tarihte en meşhur Virtual Machine (VM), Ethereum’un kullandığı Ethereum Virtual Machine’dir (EVM).
Bir çok yeni blockchain, EVM kullanıyor. Bunun başlıca birkaç sebebi;
Geliştiriciler -> Blockchainler üzerinde geliştirme yapan insanların çoğu Solidity biliyor. Solidity dili EVM üzerinde akıllı sözleşmeler ve uygulamalar geliştirmek için kullanılan bir dildir. Bu geniş geliştirici kitlesine göz kırpmak isteyen yeni blockchainler EVM kullanıyor.
Köprüleme ve Likidite -> EVM kullanan iki blockchain, birbirlerinin durum geçişlerini doğrulayabilirler çünkü aynı VM’i kullanıyorlar. Ethereum’a kurulacak bir köprü ise doğrudan Ethereum kullanıcısına ve likiditesine erişmek demektir.
Interoperability kavramı, iki blockchainin birbirleri ile uyumlu olmasalar bile veri alışverişi sağlayabilmesidir.
Bugün EVM kullanan bir blockchain ile SVM (Solana Virtual Machine) kullanan bir sistem, Interoperability kavramı tanımınca veri alışverişi yapabilirler. Fakat bu iki VM, birbirlerinin state geçişlerini doğrulayamayacakları için karşılıklı olarak birbirlerinin nodelarına güven duymak zorundadırlar.
Finality
Finality, ağdaki son işlemlerin neredeyse hiç ya da asla geri alınamayacağının garantisidir.
Finality kavramı, blockchainlerin kullandığı consensus protokolüne göre değişiklik gösterir.
Avalanche, kullandığı Avalanche Consensus protokolü sayesinde çok hızlı fakat probabilistic (olasılıksal) finality sağlar. Probabilistic Finality, ağdaki işlemlerin %99.99999.. oranında doğrulandığını ve neredeyse hiç geri alınamayacağını garantiler.
Solana, kullandığı Tower-BFT Consensus sayesinde yaklaşık 12 saniye içerisinde deterministic (net, kesin) finality sağlar. Deterministic Finality, ağdaki işlemlerin kesinlikle doğrulandığı ve asla geri alınamayacağını belirtir.
Güçlü korunan ve Probabilistic Finality sağlayan bir sistem, en az Deterministic Finality sağlayan bir sistem kadar güvenlidir.
Avalanche gibi sub-second finality sağlayan sistemler gücünü hızlı çalışan bir consensustan alır ve Probabilistic Finality böyle bir sistem için dezavantaj değil avantajdır.
Chainlink CCIP gibi Cross-Chain Interoperability Sağlayan sistemlerde, aralarında iletişim kurduğumuz blockchainlerin finality zamanları önemlidir.
Özellikle de source/kaynak blockchainim finality zamanı, veri/varlık aktarımının süresini belirleyen aktördür. Blockchainlerin consensus protokolleri farklılık gösterdiği sürece finality zamanları da farklılık gösterebilir.
Decentralized Oracle Network
Decentralized Oracle Network kavramından bahsettiğim bir yazı mevcut. Okumak için aşağıdaki sayfaya tıklamanız yeterli.
Ben burada kısaca özetleyeceğim tabii ki.
Yeni geliştirilen DON’lar, Off-Chain Reporting 2.0 (OCR) Protokolü çalıştırır. Protokol, consensusa dayalı turlar halinde çalışır. DON’un vereceği çıktı, protokol nodelarının çoğunun onayladığı bir raporla sonuçlanır. Rapor, nodeların biri tarafından blockchain ağ(lar)ına iletilir. Sahtekarlığın önüne geçmek amacıyla raporlayan DON node’u sürekli değişir.
CCIP, kendi içerisinde, Committing DON ve Executing DON adlarında iki adet Decentralized Oracle Network ve bir adet Risk Management Network çalıştırır.
Lane
CCIP kullanarak iki blockchaini birbirine bağlayabiliyoruz.
Ethereum’dan Avalanche’a köprüleme yapabildiğimiz CCIP tanımlaması bir Lane oluşturur. Aynı şekilde Avalanche’dan Ethereum’a köprüleme yapmak istediğimizde yine bir Lane oluşturuyoruz.
Bu noktaya kadar Cross-Chain Interoperability Protokol kavramını adım adım, kelime kelime işledik.
Buradan sonra hedefimiz, CCIP’nin çalışma ve güvenlik prensiplerini incelemek olacak.
CCIP High Level Architecture
CCIP’nin tüm çalışma mekanizması yukarıdaki GIF üzerinde gizli. Bugün bu mekanizmayı özetleyeceğiz.
On-Chain Araçlar
Router
Router Kontrat, CCIP’nin ana sözleşmesidir.
Her blockchain üzerinde 1 adet CCIP Router kontratı bulunur ve CCIP üzerinde ilerletilen tüm işlemler bu Router kontratlar aracılığıyla gerçekleştirilir.
Kullanıcılar, Router Kontrat üzerinde işlem yapabilmek için Token Approval vermek zorundadır.
Router kontratına gelen her işlem/talimat, hedefe özel olan On-Ramp Kontratına gönderilir.
On-Ramp
Her Lane başı bir adet On-Ramp Kontratı bulunur.
Router Kontrat tarafından kendisine gönderilen işlemlerin sırasını takip eder. Bu sıra önemlidir zira oluşturulacak Merkle Root’un kontrolü için bu sıra kullanılacaktır.
Gönderilen her mesaj için belirli bir gas limiti mevcuttur. Bu gas limitinin kontrolü On-Ramp Kontratı tarafındandan kontrol edilir. Ayrıca kullanıcı ücretlendirmelerini ve ödemelerini takip eder.
Kendisine gelen bir token transferi varsa, tokenlerin toplandığı Token Pool’u kontrol eder.
Token Pools
Her token, ERC-20 tokenler üzerinde On-Ramp ve Off-Ramp Kontratlarının erişimini kolaylaştıran bir soyutlama katmanı olarak kendi Token Pool’una sahiptir.
CCIP üzerindeki Token Pool’larında, Lock/Burn ve Unlock/Mint mekanizmaları mevcuttur.
Ethereum üzerinde LINK token, ERC-20 standartlarında üretilmiş bir token olarak bulunur. Fakat Polygon ağı üzerinde LINK token sözleşmesi bulunmamaktadır. Ethereum -> Polygon Lane’i üzerinde gerçekleşecek bir LINK token transferinde, Ethereum üzerindeki LINK token poola kitlenir ve Polygon üzerinde Wrapped Asset olarak Token Pool tarafından mintlenir.
USCD ise hem Ethereum hem de Polygon üzerinde main asset olarak bulunur. Bu sebeple USDC token ana zincirde yakılır ve karşıda mint edilir.
Off-Ramp
Lane başı 1 adet, hedef blockchain üzerinde bulunan bir kontrattır.
Executing DON’un oluşturduğu Merkle-Proof’u ve Committing DON tarafından yapılan Commitin Risk Management Network tarafından kutsanıp kutsanmadığını kontrol eder.
Ne??
Okumaya devam edelim. İleride anlayacaksınız.
Yaptığı kontrollerin amacı, aynı işlemin double spending sonucu değil, sadece 1 kere çalıştığını kontrol etmektir. Yaptığı doğrulamalardan sonra Off-Ramp sözleşmesinin aldığı tüm mesajlar/işlemler Router Kontratına iletilir. Token transferi söz konusuysa Token Pool çağrılır.
Commit Store
On-Ramp Kontratının, gelen işlemlerin sırasını takip ettiğini söylemiştik. Committing DON, bu mesajları alıp ve Merkle Root oluşturur. Bu Merkle Root, hedef blockchain üzerindeki Commit Store üzerinde depolanır.
Risk Management Network, Executing DON bu Rootları yürütmeden önce bir doğrulama mekanizması çalıştırır.
Lane başı 1 adet Commit-Store Vardır.
Off-Chain Araçlar
Committing DON
Committing DON, CCIP ağı içerisinde çalışan iki DON’dan ilkidir. İlk olarak tanımlamamın sebebi, kaynak zincirden çıkan işlemlere göre aksiyon almasıdır.
Kaynak blockchain üzerindeki On-Ramp Kontratını izler. Finality kavramını yukarıda özetlemiştim. Committing DON, On-Ramp Kontratına gelen işlemler üzerinde bir işlem yapmadan önce, bu işlemlerin Finality’sini bekler.
Finality sağlandıktan sonra buraya gelen işlemleri alır ve tek bir işlem haline getirir. Aynı zamanda bu işlemleri sırasına göre dizerek bir Merkle Root oluşturur. Bu Root, Committing DON nodeları tarafından imzalanır. İmzalanan Root daha sonra Commit-Store Kontratına yazılır.
Executing DON
Executing DON, Commit Store’a gelen imzalanmış Root üzerinde işlem yapar.
Risk Management Network, Commit-Store’a yazılan Merkle Root’u kontrol eder ve bir onay mekanizması çalıştırır. Eğer Merkle Root, Risk Management Network’ten gerekli onayı almışsa, Executing DON bu Root üzerinde işlem yapmaya başlar.
İkincil bir doğrulama mekanizması olarak bu Root’u kontrol eder. Merkle-Proof oluşturur. Bu Merkle Proof, Off-Chain Ramp Kontratı tarafından onaylanır. Daha sonra işlemler gerçekleşir.
Bu iki DON’un birbirinden ayrılma sebebi, Risk Management Network için gerekli olan süreyi kazanmaktır.
Peki Risk Management Network Nedir?
Risk Management Network
Risk Management Network, On-Chain ve Off-Chain olarak 2 bölümden oluşuyor.
Off-Chain -> Risk Management Nodeları, hatalı davranışa karşı tüm ağları izliyor ve dinliyor.
On-Chain -> Desteklenen CCIP blockchaini başına 1 adet olmak üzere, Risk Management Kontratları bulunur.
Off-Chain Risk Management Network
CCIP’ye paralel olarak çalışan 2. bir doğrulama servisidir.
Yukarıda bahsettiğim DON’lar üzerinde çıkacak olan bir yazılım hatasına karşı başka bir kod tabanı çalıştırılır. 2 ana çalışma modu vardır:
- Blessing
Risk Management Nodelarının hepsi, hedef blockchainlere commit edilen tüm mesajların Merkle Root’unu kontrol eder.
Hatırlayacağınız üzere bu commit işlemini Committing DON yapıyordu.
Merkle Tree ve Root tekrar oluşturulur. Risk Management Nodeları Merkle Root eşleşmesi için olumlu/olumsuz oylaması yaparlar.
Risk Management Nodelarının oluşturduğu Merkle Root ile Committing DON tarafından oluşturulan Merkle Root eşleşirse “blessing/kutsama” işlemi yapılır. Bu işlem gerçekleştiyse “Sorun yok, işlemlere devam edebilirsiniz.” denmektedir.
On-Chain olarak bulunan Risk Management Kontratı, Risk Management Nodelarının yaptığı olumlu/olumsuz oylamasını takip eder.
2. Cursing
Risk Management Nodeları bir anormallik sezerse ve olumlu/olumsuz oylamasında yeterli Olumsuz oyuna ulaşılmışsa, hedef zincirdeki TÜM CCIP HİZMETLERİ durdurulur.
Risk Management Kontratı bu cursing/lanetleme durumunu kaldırmadan önce durum değerlendirmesine kadar bekler.
Duraklatma için 2 durum söz konusudur:
a) Finality Violation -> Bir Lane üzerinde Risk Management yapılandırması bir güvenlik ihlaline maruz kalırsa, derin ve detaylı bir yeniden yapılandırma başlatılır.
b) Execution Safety Violation -> Kaynak blockchain üzerinde bir işlem olmamasına rağmen hedef blockchain üzerinde işlem yürütüldüğü takdirde bu Lane üzerindeki CCIP hizmetleri durdurulur. DON’lar üzerinde double spending yapılamaz.
On-Chain Risk Management Kontrat
Blessing ve Cursing uygulamaları için bir grup node bulundurur. 5 parçadan oluşur:
a) Cursing için oy adresi,
b) Blessing için oy adresi,
c) Cursing oylarının geri çekilebilmesi için bir adres,
d) Cursing oy ağırlığı
e) Blessing oy ağırlığı
Cursing ve Blessing için ayrıca 2 adet threshold/eşik değeri bulundurur. 2 farklı oylama sistemi vardır.
a) Blessing Voting Procedure -> Merkle Root her onay oyu aldığında, Risk Management Kontratında bulunan Blessing oy ağırlığı bir artırılır. Threshold aşılırsa transferler kutsanmış/onaylanmış olur.
b) Cursing Voting Procedure -> Her nodeun oyunun 32 bytelık bir kimliği bulunur. Bir node istediği kadar oy kullanabilir. Her oy, Cursing oy ağırlığını 1 artırır. Bir node 2. kez Cursing oyu kullanırsa diğer nodelar Merkle Root’u tekrar kontrol eder.
Risk Management Kontrat lanetlenirse, cursing oyu fazla çıkarsa, CCIP Router Kontratıyla etkileşime geçen kontratı yazan kişi, kendi kontratı üzerindeki sorunu çözmeli. Sorun çözüldüğünde orijinal sözleşme sahibi lanetlemeyi kaldırabilir.
CCIP’nin nasıl çalıştığını ve teknik detaylarını öğrendik. İşlemlerin nasıl gerçekleştiği ve doğrulama sisteminin nasıl çalıştığına dair bilgi sahibi oldu.
Chainlink Evrenini Büyüttük.
Yazıyı beğendiyseniz paylaşarak destek olabilirsiniz.
Teşekkür ederim, sağlıcakla kalın.
Alperen Tunçkıran / Chainlink Community Advocate
Twitter : @blockofchain
