Orijinal başlık: "Flashbots' SUAVE zincirini bir geliştiricinin bakış açısından anlamak: MEV'e ek olarak, EVM + TEE için başka hangi olasılıklar var? 》
Orijinal yazar: ZHIXIONG PAN, DUGUBUYAN, ChainFeeds Research
SUAVE zinciri, TEE ortamını tanıtarak uygulama geliştirmeye yeterince güçlü yetenekler getiriyor ve potansiyel uygulama senaryoları çok sayıda. Ayrıca, basit ve kullanışlı çapraz zincir çalışması da Dapp tasarımında hayal gücü için yeterli alan sağlıyor.
SUAVE, Flashbots tarafından geliştirilen merkezi olmayan bir projedir. MEV sürecinde karşılaşılan anahtar saklama ve birden fazla taraf arasında karşılıklı güven gibi sorunları çözmek için TEE ortamıyla bir ağ kurar. Aynı zamanda, SUAVE projesine TEE'nin eklenmesi, SUAVE'ye MEV sorununu çözmenin yanı sıra daha fazla olasılık sağlıyor.
SUAVE projesi Ethereum uzantısına dayanmaktadır, bu nedenle EVM ile doğal olarak uyumludur. GitHub'daki mevcut ilgili projeleri arasında şunlar yer almaktadır: SUAVE-geth, SUAVE-std, SUAVE-examples, vb.
Bunların arasında SUAVE-geth, geth temel alınarak genişletilmiş yürütme katmanı kodudur. Temel olarak geth tabanlı şifreli bir hesaplama ortamı ekler, ayrıca şifreli hesaplama ortamında bazı ön derlemeler yapar. Özellikle geliştiricilerin TEE ortamını kullanarak kullanıcılara diğer ağlara erişim olanağı sağlamalarına olanak tanıyan standart HTTPS isteklerinin ön derlemesinin eklendiğini belirtmekte fayda var. Ayrıca, şifreleme parametrelerinin elde edilmesi, şifreleme bilgilerinin depolanması, şifreleme bilgilerinin elde edilmesi gibi TEE kullanım fonksiyonlarına dayalı bir dizi ön derlemeyi de içerir ki bunlar güvenilir bir ortama dayalı geliştirme altyapısını oluşturur.
SUAVE-std, geliştiricilerin kolaylığı için oluşturulmuş bir projedir ve bir geliştirme aracı kütüphanesi olarak anlaşılabilir. Örneğin, HTTP isteklerinin nasıl kullanılacağını paketler ve hatta bu temelde ChatGPT'yi kullanan bir kod kütüphanesini bile paketler. Bu, geliştiricilerin ChatGPT istek mesajlarını bir araya getirmekten ve ChatGPT dönüş mesajlarını kendi başlarına ayrıştırmaktan kaçınmalarını sağlar. HTTP istek mesajlarını birleştirirken yalnızca kendi API anahtarlarını değiştirmeleri gerekir. TEE güvenlik ortamı API anahtarının güvenliğini sağlar çünkü her şey TEE ortamında yapılır. Başlangıçta ChatGPT standart kütüphanesi varsayılan olarak GPT-3.5-turbo modelini kullanıyordu ve sıcaklık varsayılan olarak 0.7'ye ayarlanmıştı. Artık esnek bir arayüz eklendi ve modeller parametre olarak da geçirilebiliyor.
SUAVE-examples projesi esas olarak uygulamaların nasıl geliştirileceğine dair bazı durumları göstermeyi amaçlamaktadır, ya da daha doğrusu başlangıç seviyesi için bir eğitimdir demek daha doğru olacaktır. SUAVE uygulama geliştirmeye yeni başlayan geliştiriciler, bu projedeki vakalar aracılığıyla öğrenebilir ve karşılaştırma yapabilirler.
SUAVE, Ethereum uzantısına dayandığından (yürütülebilir ortamına MEVM, Değiştirilmiş Ethereum Sanal Makinesi denir), akıllı sözleşmelerin geliştirilmesi EVM ile uyumludur ve resmi geliştirme belgelerinin tümü Solidity'de tanıtılır. Bu sayede geliştiriciler için Solidity geliştirme deneyimi tam anlamıyla değerlendirilebilir. SUAVE uygulama geliştirmede akıllı sözleşmelerin geliştirilmesi, TEE ortamında şifreli hesaplama fonksiyonlarına sahip Solidity geliştirme olarak anlaşılabilir.
Birkaç önemli SUAVE MEVM ön derlemesi vardır. Bunlardan ilki, gizligirdi'lerdir. Bu ön derleme, uygulama isteklerinden gelen şifreleme parametrelerini kabul eder. Bu parametre genellikle özel anahtarlar, API anahtarları vb. gibi şifrelenmesi gereken bazı özel bilgilerdir. Düz metninin yalnızca TEE ortamında görünebilmesini gerektirerek güvenliği garanti altına alınmalıdır. Uygulama geliştirmede bu bilgiler bu arayüz aracılığıyla elde edilir. İletim süreci tamamen şifreli, güvenli ve güvenilirdir. Prensipten daha sonra bahsedeceğiz. İkincisi ise gizli bilgilerin saklandığı gizli depodur. Parametrelerden özel bilgi elde ettiğimizde, çoğu zaman o anda hesaplamaya katılmasına ihtiyacımız olmaz, dolayısıyla sonraki kullanımlar için saklarız. Üçüncüsü ise gizliGeriAl'dır. Bu arayüz, sonraki hesaplamalar için özel bilgilere ihtiyaç duyulduğunda TEE bağlam ortamından düz metin verisi istemek için kullanılır.
SUAVE'nin özel bilgilerin güvenli bir şekilde depolanması, geliştiricilerin şu senaryoyu uygulamasına olanak tanır: "Kullanıcı özel anahtarı yükler ve ardından üçüncü taraf iş hesaplamalarını gerçekleştirir. Koşullar karşılandığında, üçüncü taraf imzalamak için doğrudan kullanıcının özel anahtarını kullanabilir. Bu şekilde, üçüncü taraf belirli kurallar altında imzalamak için kullanıcının özel anahtarını kullanabilir, ancak üçüncü taraf özel anahtarın düz metnini asla elde edemez."
SUAVE, zincirler arası işlemler için HTTPS isteklerini kullanır. Araç setinde, zincirler arası bilgileri doğrudan okumak için gateway adında bir kütüphane bulunmaktadır. Özü, kullanıcıların belirli bir zincirin RPC düğümünü ayarlamasıdır. Kullanıcılar daha yaygın olarak Infura ve Etherscan gibi API anahtar bilgilerini yükler ve daha sonra çağırmaları gerektiğinde doğrudan ilgili düğüme HTTP istekleri gönderirler. Zincirler arası bilgi yazılması gerektiğinde, araç seti geliştiricilerin EIP1559 gibi mesajları kodlamasına ve son olarak işlemi eth_sendRawTransaction arayüzü üzerinden yayınlamasına yardımcı olabilecek bir işlem paketi içerir.
Bahsetmeye değer bir diğer kullanım senaryosu ise Solidity tarafından derlenen bayt kodunu özel bir parametre olarak yükleyip saklamak ve koşullar sağlandığında bunu dağıtıp çağırmak, böylece özel bir kütüphane oluşturmaktır. Bu kullanım senaryosu şu şekilde genişletilebilir: özel anahtar + özel bayt kodu kütüphanesi. Bu şekilde üçüncü taraflara devredilen çağrılarda tamamen gizli işlemler gerçekleştirilebilmektedir.
SUAVE'nin son hali SUAVE zinciri adını verdiğimiz bir zincirdir. SUAVE zincirini MEVM’i uygulayan bir zincir olarak değerlendirebiliriz. EVM uyumlu bir blockchain olması sebebiyle ERC20, ERC721 gibi varlıkları da SUAVE üzerinde inşa edebiliyoruz ve on-chain operasyonları EVM serisi zincirlerden farklı değil. Ancak benzersizliği, işlemlerin diğer zincirlerdeki düğümlere gönderilmesi gibi zincir dışı işlemlerin eklenmesinde yatmaktadır. Zincir dışı işlemlerin veya kullanım koşullarının sonuçları SUAVE zincirinde saklanabilir ve saklanan sonuçlar konsensüs ile garanti altına alınır. Bu, zincir dışı hesaplamalar ile zincir içi durum arasında tutarlılığı sağlayacaktır. Örneğin, geliştiriciler akıllı bir sözleşme yazıp zincire bazı koşullar kaydedebilirler (bu koşullar değiştirilebilir de). Belirli bir zincir ağ düğümüne erişildiğinde ve döndürülen sonuç gereksinimleri karşıladığında, önceden ayarlanmış bir ERC20 varlığı aktarılacaktır.
Yukarıdakilerin hepsi SUAVE'nin zincir dışı güvenilir bilişiminin getirdiği özelliklerdir. SUAVE'nin Flashbots ekibi tarafından geliştirildiğini ve SUAVE'nin Flashbots ekibi tarafından "MEV'in Geleceği" olarak görüldüğünü biliyoruz, dolayısıyla paket işlem işleme kesinlikle gereklidir. Güvenilir bir ortamda SUAVE zincirine dayanan MEV ile ilgili prensipler oldukça basittir: paket işlemlerini bir araya getir ve bunları Flashbots röle düğümüne gönder. Özel anahtarlar gizli bir şekilde saklanabilir ve hatta kodlar bile gizli bir şekilde saklanabilir, bu da kullanım açısından büyük bir potansiyel yaratır. Örneğin, hedef zincirdeki gaz ödülüne ek olarak, oluşturucu SUAVE zincirinde belirli dijital varlıkları da elde edebilir. MEV pazarı için, özel bilgilerin güvenliğini sağlarken işi esnek bir şekilde tanımlayabilmek şu anda MEV'in yapamadığı bir şeydir (şu anda yalnızca güvene, sözleşmelere, iyi niyete vb. dayalı geleneksel zincir dışı garantiler sağlayabilmektedir).
Geliştiriciler için, zincir üstü akıllı sözleşme geliştirmeye ek olarak, ön uç geliştirmede ether.js gibi araç setleri de bir dapp'ın geliştirilmesinin önemli bir parçasıdır. SUAVE uygulamalarının geliştirilmesinde, SUAVE zinciri EVM tabanlı olduğundan ether.js ve web3.js gibi araçlar da kullanılabilir. Bu araçlar, SUAVE zincirindeki akıllı sözleşmelerle ve diğer EVM uyumlu zincirlerle aynı şekilde etkileşime girer, ancak yalnızca gizli olmayan ortamlardaki işlevleri çağırabilir. SUAVE zinciri akıllı sözleşmesi, zincir üstü (SUAVE zincirini ifade eder) ve zincir dışı (çapraz zincir işlemleri de bu kategoriye dahildir) işlemler olmak üzere ikiye ayrılır. Off-chain operasyonlar aslında gizli ortam hesaplamalarını ifade eder. Gizli bilgi işlem ortamları için Flashbots ekibi, SUAVE belgelerinde açıklanan iki dilde (Go ve TypeScript) SDK'lar sağlıyor. Bir SUAVE düğümüne gizlilik bilgi işlem işlemi (Flashbots ekibi tarafından Gizli Bilgi İşlem İsteği olarak adlandırılır) gönderilirken, özel parametreler olan gizli girdiler geçirilebilir. Tüm iletim süreci boyunca, bu parametrenin son düz metni yalnızca TEE ortamında görünecektir.
Son olarak akıllı sözleşmelerin dağıtımından bahsedecek olursak, SUAVE zincirinin test ağı Regil olarak adlandırılıyor ancak şu anda Toliman olarak yükseltildi. Dağıtım yöntemi SUAVE dokümanında detaylı olarak anlatılmaktadır. Dağıtım şekli, dağıtımdan sonra nasıl etkileşime girdiği vb. Ethereum akıllı sözleşmelerinin dağıtımından farklı değildir.
Akıllı sözleşme dağıtıldıktan sonra, gerçek işleyişi Ethereum'dan farklıdır. SUAVE’nin ana uygulama birimi Kettle’dır. Kettle, SUAVE'nin TEE çalışma zamanı ortamıdır (bir MEVM düğümü ve gizli bir veri deposu içerir). Geliştiriciler akıllı sözleşmeleri yazıp dağıttıktan sonra, kullanıcılar gizli bilgi işlem istekleri (bundan sonra CCR olarak anılacaktır) gönderir. Akıllı sözleşmelerin gizli bilgi işlem kullanması gerektiğinde, bunlar aslında Kettle tarafından yönetilir.
Kettle'ın yapı şeması aşağıdaki gibidir:

Geliştiricilerin uygulamaları geliştirmek ve dağıtmak için Solidity dilini kullandığını ve son istek Kettle'a ulaştıktan sonra MEVM tarafından işlendiğini görebiliriz. Geth'in işlevlerine ek olarak MEVM, özel verileri depolayabilen ve geri alabilen bazı ön derlemeler de ekler. Ayrıca, SUAVE zincirindeki durumu da (değiştirme ve geri alma dahil) yönetir.
Kettle'ın temel işi özel hesaplamaları almak ve işlemek, ayrıca özel veri depolama ve alma işlemlerini gerçekleştirmektir. Özel verilerin depolanmasını örnek alırsak, tüm süreç şu şekilde işler: Kullanıcı ön ucu SDK veya suave geth aracını kullanarak SUAVE zincirindeki bir akıllı sözleşmeye CCR isteği başlatır. SDK veya suave geth aracı özel verileri şifrelemek için veri anahtarını (simetrik anahtar) kullanacaktır. Bu veri anahtarı yalnızca Kettle ortamında görünecek ve SUAVE'nin RPC düğümü yalnızca şifreli metni görecektir. Kettle'ın node ile birebir ilişkisi olup olmadığı SUAVE dokümanlarında gösterilmemiştir. Benzer şekilde Kettle'ın kendisi, düğümleri ve anahtar değişiminin ayrıntılı prensipleri de belgede tanıtılmıyor. Ancak, bilinen şifreleme ve şifre çözme sürecine dayanarak, geliştiriciler, özel verilerin korunmasının Kettle içindeki kullanıcı ön ucundan TEE ortamına kadar garanti edilebileceğine inanmak için nedenlere sahiptir.
Özel veriler Kettle'da gizli bir veri deposunda saklanacaktır. Akıllı sözleşmeler geliştirilirken geliştiriciler veri erişim araçlarını ve değiştiricilerini belirleyeceklerdir. Kettle bunu Ulaştırma ağı aracılığıyla yayınlayacak. Bu sözleşme için erişim belirtilmişse, sonraki CCR isteklerinin de bu Kettle'a gönderilmesi gerekir, çünkü Kettle'ın veri depolama alanı küresel olarak güncellenmez. Geliştirici akıllı sözleşmeyi dağıttıktan sonra, kullanıcı ilgili Kettle'a erişir (CCR isteğinde bir parametre vardır ve Kettle adresi belirtilmelidir) ve özel verilerine erişilebilir. Bir kullanıcı CCR gönderdiğinde ve akıllı sözleşmede özel veri istediğinde, ilgili veriler depolanırken oluşturulan kimlik ve anahtar kullanılarak alınır. Başka bir deyişle, özel verilere anahtar değeri aracılığıyla erişilir ve kullanılır.
HTTP istekleri vb. de Kettle tarafından işlenir. Elbette bunlar SUAVE zincirinin dışında kalan görevlerdir, yani bu görevler tek bir düğüm tarafından yürütülmektedir. SUAVE bir zincir olmasına rağmen blok zinciri özellikleri zayıftır. Kettle bir CCR isteği çalıştırdığında, çalışan ve ardından bunu doğrulayan çok fazla düğüm olmayacaktır. Sebebi basit. Zincirin dışındaki kaynaklara erişildiğinde idempotans garantisi yoktur. Dolayısıyla bu görevler SUAVE zincirinin dışına aittir ve sonuçları aslında düğüm bağımlıdır. Bu nedenle geliştiriciler dağıtım sırasında Kettle adresine dikkat etmeli (bu açıdan bakıldığında Kettle özel bir akıllı sözleşme olarak değerlendirilebilir) ve sonraki kullanıcı CCR isteklerinde mutlaka ilgili Kettle adresinin yer alması gerekmektedir.
Ayrıca geliştiricilerin dikkat etmesi gereken bir konu daha var. Mevcut Toliman testnet'inde kettle'ın TEE ortamında çalışması garanti edilmiyor. Bu nedenle test ağında akıllı sözleşmeler geliştirirken özel verilerin korunmasına dikkat etmeli ve gerçekten özel verilerin sızdırılmasından kaçınmalısınız.
TEE ortamını tanıtarak, SUAVE zinciri uygulama geliştirmeye yeterince güçlü yetenekler getiriyor ve potansiyel uygulama senaryoları çok sayıda. Basit ve kullanışlı çapraz zincir çalışması, Dapp tasarımında hayal gücüne de yeterli alan sağlıyor.
SUAVE zincirinin Kettle tasarımı, zincir dışı kaynakları işleme yeteneğine sahiptir; bu da doğrulama ve fikir birliği sorunlarını gündeme getirir. Dürüst olmayan bir Kettle, ağa zarar verebilir. Kettle'ın kötülük yapmamasını nasıl sağlayacağız, kötülük yaparsa cezalandırılacağından nasıl emin olacağız, kötülük yapmanın bedelinin yeterince yüksek olduğundan nasıl emin olacağız; bunların hepsi çözülmesi gereken sorunlardır. Geliştiriciler, SUAVE zincirinin konsensüsü tarafından benimsenen PoA modelinin pratik değerlendirmelere dayanıp dayanamayacağını görmek için hâlâ bekliyorlar.
BlockBeats Resmi Topluluğuna Katılın:
Telegram Abonelik Grubu: https://t.me/theblockbeats
Telegram Sohbet Grubu: https://t.me/BlockBeats_App
Twitter Resmi Hesabı: https://twitter.com/BlockBeatsAsia