- Topic
32k Popularity
14k Popularity
23k Popularity
5k Popularity
6k Popularity
10k Popularity
11k Popularity
45k Popularity
136k Popularity
1821k Popularity
- Pin
32k Popularity
14k Popularity
23k Popularity
5k Popularity
6k Popularity
10k Popularity
11k Popularity
45k Popularity
136k Popularity
1821k Popularity
Helios: Ethereum hafif müşteri ile güvenilmez on-chain veri erişimi
Ethereum hafif müşteri Helios: Güven gerektirmeyen on-chain veri erişimi
8 Kasım'da, tanınmış bir risk sermayesi kuruluşu Ethereum hafif müşteri Helios'u tanıttı. Rust diline dayalı olarak geliştirilmiş bu müşteri, tamamen güvene ihtiyaç duymadan Ethereum erişimi sağlamayı amaçlıyor.
Blok zinciri teknolojisinin en büyük avantajlarından biri, üçüncü taraflara güvenmeye gerek olmamasıdır. Blok zinciri sayesinde, kullanıcılar kendi varlıklarını ve verilerini kontrol edebilirler. Ethereum gibi blok zincirleri çoğu durumda bu vaadi gerçekten yerine getirmiştir: Varlıklarımız gerçekten de bize aittir.
Ancak, kolaylık peşinde koşarken bazı tavizler de verdik. Bunlardan biri merkezi RPC (uzaktan çağrı) sunucularını kullanmaktır. Kullanıcılar genellikle Ethereum'a merkezi sağlayıcılar aracılığıyla erişir. Bu şirketler, kullanıcıların on-chain verilerine kolayca erişmelerine yardımcı olmak için bulut sunucularında yüksek performanslı düğümler çalıştırıyor. Cüzdan, token bakiyesini sorguladığında veya bekleyen bir işlemin paketlenip paketlenmediğini kontrol ettiğinde, neredeyse her zaman bu merkezi sağlayıcıların hizmetlerinden yararlanır.
Mevcut sistemin sorunu, kullanıcıların bu sağlayıcılara güvenmesi gerektiği ve sorgu sonuçlarının doğruluğunu doğrulayamaması.
Helios, güvenilir bir Ethereum erişimi sağlamak için tamamen güvene dayanmayan bir Ethereum hafif müşteri olan Rust tabanlı bir yazılımdır. PoS'a geçişin ardından uygulanan hafif müşteri protokolünü kullanarak, güvenilmeyen merkezi RPC sağlayıcılarından gelen verileri güvenli ve doğrulanabilir yerel RPC'ye dönüştürebilir. Merkezi RPC ile birleştirildiğinde, Helios tam düğüm çalıştırmadan verilerin doğruluğunu doğrulayabilir.
Kullanışlılık ile merkeziyetsizlik arasında denge kurmanın zor olduğu, yaygın bir sorun olarak karşımıza çıkıyor. Bu yeni nesil hafif müşteri (kamuya açık olarak geliştirilmekte) yaklaşık iki saniye içinde senkronizasyonu tamamlayabiliyor ve depolama alanına ihtiyaç duymuyor; kullanıcılar her türlü cihazdan (telefonlar ve tarayıcı eklentileri dahil) güvenli bir şekilde on-chain verilere erişebiliyor. Peki, merkezi altyapılara bağlı olmanın potansiyel riskleri nelerdir? Bu makale, bu riskleri ayrıntılı olarak inceleyecek, Helios'un tasarım çözümünü tanıtacak ve geliştiricilerin kod havuzuna katkıda bulunmalarını sağlamak için bazı öneriler sunacaktır.
Merkezi Altyapının Potansiyel Riskleri: Ethereum Ekosistemindeki Teorik Tehditler
Ethereum ekosisteminde teorik bir tehdit gizleniyor. Bu tehdit, işlem bellek havuzunda (Mempool) hedef aramak yerine, güvendiğimiz merkezi altyapıyı taklit ederek tuzaklar kuruyor. Bu tuzaklara düşen kullanıcılar hiçbir şey yanlış yapmamışlardır: Sadece her zamanki gibi tanıdık DEX'lere erişip, makul bir kayma ayarlamış ve token ticareti yapmışlardır... Yaptıkları işlemlerde hiçbir sorun yoktur, ancak Ethereum ekosisteminin girişinde - RPC sağlayıcısında - dikkatlice yerleştirilmiş yeni bir sandviç saldırısıyla karşılaşabilirler.
Ayrıntılı açıklamadan önce, DEX'in işlemleri nasıl yönettiğine bir göz atalım. Kullanıcılar token değişimi yaparken, akıllı sözleşmeye birkaç parametre sağlar: değiştirilecek token, değişim miktarı ve en önemlisi, kullanıcının kabul etmeye istekli olduğu minimum token miktarı. Son parametre, değişimin ulaşması gereken "minimum çıktı"yı belirler, aksi takdirde işlem iptal edilecektir. Bu genellikle "kayma" olarak adlandırılır, çünkü işlemin bellek havuzuna gönderilmesinden bloklara paketlenene kadar oluşabilecek maksimum fiyat dalgalanmasını etkin bir şekilde sınırlar. Eğer kayma ayarı çok düşükse, kullanıcılar yalnızca daha az token alabilir. Bu durum ayrıca sandviç saldırısına yol açabilir; saldırganlar, kullanıcının işlemini iki kötü niyetli işlem arasına sıkıştırabilir. Bu işlemler, spot fiyatı yükseltir ve kullanıcıyı dezavantajlı bir fiyattan işlem yapmaya zorlar. Ardından, saldırgan hemen tokenleri satıp küçük bir kar elde eder.
En az çıktı parametreleri makul bir aralıkta ayarlandığı sürece, kullanıcı üçgen saldırılarından etkilenmeyecektir. Ancak RPC sağlayıcısı DEX akıllı sözleşmesinin doğru fiyat tekliflerini sağlamıyorsa ne olacak? Bu durumda, kullanıcılar daha düşük en az çıktı parametreleriyle takas işlemleri imzalayarak yanıltılabilir. Daha da kötüsü, kullanıcılar işlemi doğrudan kötü niyetli RPC sağlayıcısına gönderebilir. Sağlayıcı, bu işlemi halka açık bellek havuzuna (orada birçok robot üçgen saldırıları yapmak için yarışıyor) yayınlamama seçeneğine sahip olabilir; bunun yerine özel olarak saklayıp hedeflenen platforma saldırıya uğrayacak işlem paketini doğrudan gönderebilir ve böylece kâr elde edebilir.
Bu tür bir saldırının temel nedeni, başkalarına blockchain durumunu elde etmek için güvenmektir. Bu sorunu çözmek için deneyimli kullanıcılar genellikle kendi Ethereum düğümlerini çalıştırmayı seçerler. Bu, sürekli çevrimiçi bir cihaz, yüzlerce GB depolama alanı ve baştan senkronize etmek için yaklaşık bir gün gerektiren önemli bir zaman ve kaynak yatırımı gerektirir. Bu süreç daha önceye göre çok daha basit hale gelmiş olsa da, bazı ekipler kullanıcıların düşük maliyetli donanımlarla (örneğin, harici sabit diskli bir Raspberry Pi) düğüm çalıştırmalarına yardımcı olmak için çalışmaktadır. Ancak, talepler önemli ölçüde azaltılsa bile, çoğu kullanıcı için, özellikle de mobil cihazlar kullananlar için, düğüm çalıştırmak hala zor bir görevdir.
Dikkat edilmesi gereken nokta, merkezi RPC sağlayıcılarının saldırılarının tamamen mümkün olduğu, ancak şu anda sadece teorik bir risk olduğudur; gerçekte henüz böyle bir durum yaşanmamıştır. Ana akım sağlayıcıların geçmiş kayıtları güvenilir olsa da, tanımadığınız RPC sağlayıcılarını cüzdana eklemeden önce kapsamlı bir araştırma yapmanız önerilir.
Helios Tanıtımı: Tamamen Güven Gerektirmeyen Ethereum Erişimi
Ethereum tarafından sunulan hafif müşteri protokolü, hızlı blockchain etkileşimleri ve en düşük donanım gereksinimleri ile RPC uç noktalarını doğrulama için heyecan verici olanaklar açtı. Birleşmeden sonraki bir ay içinde, farklı yöntemler benimseyen birden fazla bağımsız hafif müşteri ortaya çıktı, ancak hepsi aynı hedefi gerçekleştirmek için: güvene dayanmayan verimli erişim sağlamak ve tam düğüm kullanmadan.
Helios, yaklaşık iki saniye içinde senkronizasyonu tamamlayan, depolama alanı gerektirmeyen ve tamamen güven gerektirmeyen Ethereum erişimi sağlayan bir Ethereum hafif müşteri uygulamasıdır. Tüm Ethereum istemcileri gibi, Helios da bir yürütme katmanı ve bir konsensüs katmanından oluşur. Ancak, çoğu diğer istemcinin aksine, Helios bu iki katmanı sıkı bir şekilde birleştirir, kullanıcıların yalnızca tek bir yazılım yükleyip çalıştırması yeterlidir.
Çalışma prensibi şöyledir: Helios konsensüs katmanı, bilinen bir işaret zinciri blok hash'ini kullanır ve güvenilmeyen bir RPC ile bağlantı kurarak geçerli bir şekilde mevcut bloğa senkronize olur. Helios yürütme katmanı, bu doğrulanmış işaret zinciri bloklarını güvenilmeyen yürütme katmanı RPC ile birleştirerek, on-chain durumuna ilişkin çeşitli bilgileri doğrular; örneğin, hesap bakiyesi, sözleşme depolama, işlem makbuzları ve akıllı sözleşme çağrı sonuçları. Bu bileşenler birlikte çalışarak kullanıcılara tam olarak güven gerektirmeyen bir RPC sunar ve tam bir düğüm çalıştırmaya gerek kalmaz.
konsens katmanı
Konsens katmanı hafif müşterisi, Beacon Chain hafif müşteri standartlarını takip eder ve Beacon Chain'in senkronizasyon komitesini kullanır (birleşmeden önceki Altair hard fork'unda tanıtılmıştır). Senkronizasyon komitesi, rastgele seçilen 512 doğrulayıcıdan oluşan bir alt kümedir ve hizmet dönemi yaklaşık 27 saattir.
Doğrulayıcılar senkronizasyon komitesine girdikten sonra gördükleri tüm işaret zinciri blok başlıklarını imzalarlar. Eğer komite üyelerinin üçte ikisinden fazlası bir blok başlığını imzalarsa, o blok büyük olasılıkla standart işaret zincirinde bulunmaktadır. Helios, mevcut senkronizasyon komitesinin yapısını anladığında, güvensiz RPC'ye en son senkronizasyon komitesi imzalarını sorgulayarak zincir başını yüksek bir güvenle takip edebilir.
BLS imza birleştirmesinin avantajı sayesinde, yeni blok başlığının doğrulanması için yalnızca bir sorgu yapmak yeterlidir. İmza geçerli olduğu sürece ve üçte iki oranında komite üyesi imzayı tamamladıysa, blok zincire dahil edilmiş olduğu garanti edilebilir (elbette, blok zincirden çıkarılabilir ve blokların nihai izlenmesi daha güçlü bir garanti sağlayabilir).
Ancak bu stratejide açıkça bir aşama eksik: mevcut senkronizasyon komitesini nasıl bulacağımız. Öncelikle, zayıf öznelite kontrol noktası adı verilen bir güven kökü elde edilmesi gerekiyor. Bu, geçmişte belirli bir zamanda zincire dahil edilmiş eski bir blok hash'inin garantisini veren bir şeydir. Kontrol noktasının kesin varlık süresi hakkında bazı ilginç matematiksel hesaplamalar var: en kötü durum analizi yaklaşık iki hafta gösterirken, daha pratik tahminler birkaç ay sürebileceğini öne sürüyor.
Eğer kontrol noktası çok eskiyse, teorik olarak düğümleri yanlış bir zinciri takip etmeye kandırabilecek bir saldırı vardır. Bu durumda, zayıf öznelite kontrol noktalarını elde etmek protokolün yeteneklerinin ötesine geçer. Helios'un çözümü, başlangıç kontrol noktasını sağlamak ve bunu kod kütüphanesine sabit kodlamak (kolayca üstü kapatılabilir) ve yerel olarak en son nihai blok hash'ini saklamaktır, böylece düğümler senkronize olurken kontrol noktası olarak kullanılabilir.
Hash işlemleriyle, Beacon Chain blokları benzersiz Beacon blok hash'lerinin kolayca üretilmesini sağlar. Böylece, düğümlerden tam Beacon bloğunu sorgulamak kolaylaşır; ardından bunun hash'ini alarak ve bilinen blok hash'i ile karşılaştırarak blok içeriğinin geçerliliğini kanıtlayabiliriz. Helios, bu özelliği zayıf öznelite kontrol noktası bloklarının belirli alanlarını almak ve doğrulamak için kullanır; bunlar arasında iki kritik alan vardır: mevcut senkronizasyon komitesi ve bir sonraki senkronizasyon komitesi. En kritik nokta, hafif müşterilerin bu mekanizmayı kullanarak blok zinciri tarihini hızlı bir şekilde kontrol edebilmesidir.
Zayıf öznelite kontrol noktası ile artık mevcut ve bir sonraki senkronizasyon komitesini elde edebilir ve doğrulayabiliriz. Eğer mevcut zincir başı ve kontrol noktası aynı senkronizasyon komitesi döngüsü içindeyse, imzalanmış senkronizasyon komitesi başını kullanarak yeni blokları doğrulamaya hemen başlayabiliriz. Kontrol noktamız birkaç senkronizasyon komitesinin gerisindeyse, o zaman şunları yapabiliriz:
Gelecek bir senkronizasyon komitesinin oluşturulacağı blokları almak ve doğrulamak için kontrol noktasından sonraki senkronizasyon komitesini kullanın.
Bu yeni bloğu kullanarak bir sonraki senkronizasyon komitesini al.
Eğer kontrol noktası hala gerideyse, adım 1'e geri dön.
Bu süreç sayesinde, bu blok zincirinin tarihini 27 saatlik birimlerle hızlı bir şekilde kontrol edebiliyoruz, geçmişteki herhangi bir blok hash'inden başlayarak mevcut blok hash'ine kadar senkronize olabiliyoruz.
yürütme katmanı
İşlem katmanı hafif müşterisinin amacı, konsensüs katmanı tarafından doğrulanan işaret blok başlıklarını, güvenilmeyen işlem katmanı RPC'si ile birleştirerek doğrulanmış işlem katmanı verileri sağlamaktır. Bu veriler daha sonra Helios üzerinden yerel olarak barındırılan RPC sunucusuna erişilebilir.
Hesap bakiyesi almayı örnek alarak, Ethereum'un durumu nasıl depoladığını basitçe tanıtalım. Her hesap, sözleşme kodu hash'i, rastgele sayı, depolama hash'i ve bakiye gibi birkaç alan içerir. Bu hesaplar, durum ağacı olarak adlandırılan, değiştirilmiş büyük bir Merkle-Patricia ağacında depolanır. Durum ağacının kökünü bildiğiniz sürece, herhangi bir hesabın ağaçta var olup olmadığını kanıtlamak için Merkle kanıtını doğrulayabilirsiniz. Bu tür bir kanıt sahtecilikle oluşturulamaz.
Helios, konsensüs katmanından doğrulanmış bir durum kökü aldı. Bu durum kökünü ve Merkle kanıt isteğini güvensiz yürütme katmanı RPC'sine uygulayarak, Helios Ethereum üzerinde depolanan tüm verileri yerel olarak doğrulayabilir.
Farklı teknolojiler kullanarak yürütme katmanında kullanılan çeşitli verileri doğruluyoruz, bu şekilde güvenilmeyen RPC'den gelen tüm verileri doğrulayabiliyoruz. Güvenilmeyen RPC veri erişimini sağlamayı reddedebilir, ancak yanlış sonuçlar veremez.
Helios'u karmaşık ortamlarda kullanma
Kolaylık ve merkeziyetsizlik arasında denge kurmak zor bir sorun olarak karşımıza çıkıyor. Hafif Helios sayesinde kullanıcılar, herhangi bir cihazdan (telefonlar ve tarayıcı eklentileri dahil) güvenli bir şekilde on-chain verilere erişebilir. Bu, daha fazla kişinin donanım kısıtlaması olmaksızın Ethereum verilerine güvenmeden erişmesini sağlayacaktır. Kullanıcılar, bazı cüzdanlarda Helios'u RPC sağlayıcısı olarak ayarlayarak çeşitli DApp'lere güvenmeden erişim sağlayabilir; bu süreçte herhangi bir başka değişiklik yapmaya gerek yoktur.
Ayrıca, Rust'ın WebAssembly desteği, uygulama geliştiricilerin Helios'u JavaScript uygulamalarına (cüzdanlar ve DApp gibi) kolayca entegre etmelerini sağlar. Bu entegrasyonlar, Ethereum'un güvenliğini artıracak ve merkezi altyapıya olan bağımlılığımızı azaltacaktır.
Topluluğun buna tepkisi heyecan verici. Helios'a katkıda bulunmanın birçok yolu var; kod havuzuna katkıda bulunmanın yanı sıra, Helios'un avantajlarını kullanmak için Helios ile entegre yazılımlar geliştirebilirsiniz. İşte bazı heyecan verici fikirler: