Ethereum hafif müşteri Helios: Güven gerektirmeyen Blok Zinciri erişimi sağlamak
8 Kasım'da, yeni bir Ethereum hafif müşteri Helios resmi olarak piyasaya sürüldü. Bu müşteri, tamamen güvene ihtiyaç duymadan Ethereum erişimi sağlamak amacıyla Rust dilinde geliştirilmiştir.
Blok zincirinin temel amaçlarından biri, güvene ihtiyaç duymadan işlem yapmaktır. Blok zinciri sayesinde, kendi varlıklarımızı ve verilerimizi bağımsız bir şekilde kontrol edebiliriz. Çoğu durumda, Ethereum gibi blok zincirleri bu vaadi gerçekten yerine getirmiştir: varlıklarımız gerçekten bize aittir.
Ancak, kullanım kolaylığını sağlamak için bazı tavizler verdik. Bunlardan biri, merkezi RPC( uzaktan çağrı) sunucusunu kullanmaktır. Kullanıcılar genellikle Ethereum'a merkezi sağlayıcılar aracılığıyla erişir. Bu şirketler, bulut sunucularında yüksek performanslı düğümler çalıştırarak herkesin zincir üzerindeki verilere kolayca erişmesine yardımcı olur. Cüzdan, token bakiyesini sorguladığında veya işlem durumunu kontrol ettiğinde, neredeyse her zaman bu merkezi sağlayıcılardan faydalanılı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ğrulayamamalarıdır.
Helios, tamamen güvenilir bir Ethereum erişimi sağlayabilen Rust tabanlı bir Ethereum hafif müşteri uygulamasıdır. Ethereum'un PoS'a geçişi ile sağlanan hafif müşteri protokolünü kullanarak, güvenilmeyen merkezi RPC sağlayıcılarından gelen verileri güvenli bir şekilde doğrulanabilir yerel RPC'ye dönüştürebilir. Merkezi RPC ile birleştirildiğinde, Helios tam bir düğüm çalıştırmadan veri doğruluğunu doğrulayabilir.
Bu hafif müşteri, yaklaşık iki saniye içinde senkronizasyonu tamamlayabilir ve depolama gerektirmez. Kullanıcılar, herhangi bir cihaz(, mobil telefonlar ve tarayıcı eklentileri) aracılığıyla zincir üzerindeki verilere güvenli bir şekilde erişebilir. Ancak merkezileşmiş altyapılara bağımlılığın potansiyel riskleri nelerdir? Şimdi bu riskleri analiz edecek, Helios'un tasarım çözümünü tanıtacak ve kod havuzunu geliştirmeye yardımcı olacak bazı fikirler sunacağız.
Merkezileştirilmiş Altyapının Potansiyel Riskleri
Teorik bir saldırı yöntemi Ethereum'un "karanlık ormanı" içinde gizleniyor. Bu, işlem hafıza havuzunda hedef aramak yerine, bağımlı olduğumuz merkezi altyapıyı taklit ederek tuzaklar kurmaktır. Kullanıcılar hata yapmamış olsalar bile tuzağa düşebilirler: Sadece her zamanki gibi DEX'te işlem yapıyorlar, makul bir kayma ayarlıyorlar... ama yine de RPC sağlayıcısında dikkatlice kurulmuş yeni bir sandviç saldırısına maruz kalabilirler.
Merkeziyetsiz borsa işlemleri sırasında, kullanıcıların akıllı sözleşmeye birkaç parametre sağlaması gerekir: 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ı belirtir, aksi takdirde işlem iptal edilir. Bu genellikle "kayma" olarak adlandırılır ve işlem gönderildikten sonra işlemin blok zincirine eklenmesi arasında ortaya çıkabilecek maksimum fiyat farkını etkili bir şekilde belirler. Eğer kayma ayarı çok düşükse, kullanıcı daha az token alabilir ve ayrıca sandviç saldırısına maruz kalabilir.
En az çıktı parametreleri makul bir aralıkta ayarlandığı sürece, sandviç saldırısından etkilenmez. Ancak, RPC sağlayıcısı DEX akıllı sözleşmesinin doğru fiyat teklifini sağlamazsa ne olur? Bu, kullanıcıların yanıltılmasına ve daha düşük en az çıktı parametreleriyle değişim işlemleri imzalamalarına neden olabilir. 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ı, işlemi halka açık bellek havuzuna yaymamakta ve bunun yerine saldırıya uğramış işlem paketini kar elde etmek için belirli bir kuruma özel olarak göndermekte serbesttir.
Bu tür bir saldırının temel nedeni, başkalarına güvenerek blok zinciri durumunu elde etmektir. Bu sorunu çözmek için deneyimli kullanıcılar genellikle kendi Ethereum düğümlerini çalıştırır, ancak bu önemli ölçüde zaman ve kaynak gerektirir; en azından sürekli çevrimiçi bir cihaz, yüzlerce GB depolama alanı ve baştan senkronize etmek için yaklaşık bir gün gereklidir. Şu anda düğüm çalıştırma eşiği düşmüş olsa da, çoğu kullanıcı için hâlâ zordur, özellikle mobil cihaz kullananlar için.
Dikkat edilmesi gereken husus, merkezi RPC sağlayıcılarının saldırılarının tamamen mümkün olmasına rağmen genellikle basit bir phishing saldırısı olduğudur; tarif ettiğimiz türde bir saldırı henüz gerçekleşmemiştir. Ana akım sağlayıcıların geçmiş kayıtları güvenilir olsa da, tanıdık olmayan RPC sağlayıcılarını kullanmadan önce biraz daha araştırma yapmak yine de akıllıca bir seçimdir.
Helios: Güven gerektirmeyen Ethereum erişimi
Ethereum hafif müşteri protokolünü tanıttı, hızlı Blok Zinciri etkileşimleri ve en düşük donanım gereksinimleriyle RPC uç noktalarını doğrulama için yeni olanaklar sağladı. The Merge'den sonraki bir ay içinde, bir dizi bağımsız hafif müşteri art arda piyasaya sürüldü, farklı yaklaşımlar benimsediler, ancak hedefleri aynıydı: tam düğüm çalıştırmadan güvenilir erişimi verimli bir şekilde sağlamak.
Helios, yaklaşık iki saniye içinde senkronizasyon yapabilen, depolama gerektirmeyen ve tamamen güvenilmez Ethereum erişimi sağlayan bir Ethereum hafif müşterisidir. Tüm Ethereum istemcileri gibi, Helios da yürütme katmanı ve konsensüs katmanı içerir. Ancak çoğu istemciden farklı olarak, Helios bu iki katmanı sıkı bir şekilde birleştirmiştir; kullanıcıların yalnızca tek bir yazılım kurup çalıştırmaları yeterlidir.
Helios'un çalışma prensibi şöyledir: Konsensüs katmanı, bilinen bir referans zinciri blok hash'ini kullanır ve güvenilmeyen bir RPC ile bağlantı kurarak geçerli bir şekilde mevcut bloğa senkronize olur. İcra katmanı, bu doğrulanmış referans zinciri bloklarını güvenilmeyen icra katmanı RPC'si ile birleştirerek, blok üzerindeki durumun çeşitli bilgilerini doğrular; örneğin hesap bakiyeleri, 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ıya tamamen güven gerektirmeyen bir RPC sunar ve tam bir düğüm çalıştırma gerektirmez.
Konsens Katmanı
Konsensüs katmanı hafif müşteri, işaret zinciri hafif müşteri standartlarına uyar ve işaret zincirinin senkronizasyon komitesinden faydalanır. Senkronizasyon komitesi, rastgele seçilen 512 doğrulayıcıdan oluşan bir alt kümedir ve hizmet süresi 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ı imzalar. Eğer komite üyelerinin %2/3'ünden fazlası bir blok başlığını imzaladıysa, bu blok muhtemelen standart işaret zincirinde bulunmaktadır. Helios, mevcut senkronizasyon komitesinin bileşimini anlıyorsa, en son senkronizasyon komitesi imzalarını sorgulayarak zincir başını güvenilir bir şekilde izleyebilir.
BLS imza birleştirmesi sayesinde, yeni blok başlığının doğrulanması için yalnızca bir sorgu yeterlidir. İmza geçerli olduğu ve 2/3'ten fazla komite üyesi imzayı tamamladığı sürece, bloğun zincire dahil olduğu garanti edilebilir. Elbette, blokların nihaiğini takip etmek daha güçlü bir garanti sağlayabilir.
Bu stratejide, mevcut senkronizasyon komitesinin nasıl bulunacağına dair bir sorun da çözülmelidir. Öncelikle, zayıf öznelik kontrol noktası olarak adlandırılan bir güven kökü elde edilmelidir. Bu, geçmişte belirli bir zamanda zincire dahil edilmiş olan eski blok hash'ini garanti eden bir değerdir. Kontrol noktalarının varlık süresi hakkında, teorik analiz en kötü durumda yaklaşık iki hafta, ancak pratik tahminler birkaç aya kadar uzanabilir.
Eğer kontrol noktası çok eskiyse, teorik olarak düğümleri yanlış bir zinciri takip etmeye ikna edebilecek bir saldırı mümkündü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ı sağlamaktır; bunu kod havuzuna sert kodlama ile eklemek ( kolayca üzerine yazılabilir ), en son nihai blok hash'ini yerel olarak saklar, böylece düğümler senkronize olurken kontrol noktası olarak kullanılabilir.
Hash işlemi aracılığıyla, işaret zinciri blokları kolaylıkla benzersiz bir işaret blok hash'i oluşturabilir. Bu, tam işaret bloklarını kolayca sorgulamayı sağlar ve ardından hash karşılaştırması yoluyla blok içeriğinin geçerliliğini kanıtlar. Helios, bu özelliği, zayıf öznelite kontrol noktası blokları içindeki kritik alanları elde etmek ve doğrulamak için kullanır; bunlar arasında mevcut senkronizasyon komitesi ve bir sonraki senkronizasyon komitesi bulunmaktadır. En önemlisi, hafif müşteri bu mekanizmayı kullanarak blok zinciri tarihini hızlı bir şekilde gözden geçirebilir.
Zayıf öznelik kontrol noktası ile, mevcut ve bir sonraki senkronizasyon komitesini alabilir ve doğrulayabiliriz. Eğer mevcut zincir başı ve kontrol noktası aynı senkronizasyon komitesi döngüsünde ise, yeni blokları doğrulamak için imzalı senkronizasyon komitesi başlığını hemen kullanabiliriz. Eğer kontrol noktası birkaç senkronizasyon komitesinin ardından geliyorsa, o zaman:
Gelecek bir senkronizasyon komitesinin bloklarını 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 arkadaysa, adım 1'e dön.
Yukarıda belirtilen süreç aracılığıyla, 27 saatlik birimlerle, bu Blok Zinciri'nin geçmişini hızlı bir şekilde gözden geçirebiliriz, geçmişteki herhangi bir Blok hash'inden başlayarak, mevcut Blok hash'ine kadar senkronize edebiliriz.
yürütme katmanı
Yürütme katmanı hafif müşterisinin amacı, konsensüs katmanı tarafından doğrulanan ana blok başlıklarını güvensiz yürütme katmanı RPC'si ile birleştirerek doğrulanmış yürütme katmanı verileri sağlamaktır. Bu verilere daha sonra Helios aracılığıyla yerel olarak barındırılan RPC sunucusu üzerinden erişilebilir.
Aşağıda hesap bakiyesi elde etmenin basit bir örneği verilmiştir, öncelikle Ethereum'un durumu nasıl depoladığını kısaca tanıtacağız. 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, ayarlanmış büyük bir Merkle-Patricia ağacında depolanır. Durum ağacının kökü bilindiğinde, Merkle kanıtını doğrulamak için kullanılabilir, böylece ağaçta herhangi bir hesabın var olup olmadığını kanıtlayabilirsiniz. Bu kanıt sahtecilikten korunmuştur.
Helios, konsensüs katmanından doğrulanmış durum kökünü alır. Güvensiz yürütme katmanı RPC'si aracılığıyla bu durum kökünü ve Merkle kanıtı talebini uygulayarak, Helios Ethereum'da saklanan tüm verileri yerel olarak doğrulayabilir.
Farklı teknolojiler kullanarak, yürütme katmanında kullanılan çeşitli verileri doğruluyoruz, böylece güvenilmeyen RPC'lerden gelen tüm verileri doğrulayabiliyoruz. Güvenilmeyen RPC veri erişimini sağlamayı reddedebilir, ancak yanlış sonuçlar sunamaz.
Helios'un Uygulama Geleceği
Kullanışlılık ile merkeziyetsizlik arasında denge sağlamak zor bir sorun. Hafif müşteri Helios ile kullanıcılar, herhangi bir cihaz(, telefon ve tarayıcı eklentisi) dahil olmak üzere güvenli zincir verilerine erişebilirler. Bu, daha fazla kişinin, hangi donanımı kullanırsa kullansın, Eter verilerine güvenmeden erişebilmesini sağlayacak. Kullanıcılar, cüzdanlarında Helios'u RPC sağlayıcısı olarak kullanarak, herhangi bir başka değişiklik yapmadan çeşitli DApp'lere güvenmeden erişim sağlayabilirler.
Ayrıca, Rust'ın WebAssembly desteği, uygulama geliştiricilerin Helios'u Javascript uygulamalarına (, cüzdanlar ve DApp'ler ) gibi kolayca entegre etmelerini sağlar. Bu entegrasyonlar, Ethereum'un güvenliğini artıracak ve merkezi altyapıya olan güven ihtiyacımızı azaltacaktır.
Topluluk, Helios'a katkıda bulunmanın çeşitli yollarını bulabilir; kod havuzunu geliştirmek dışında, Helios'un avantajlarından yararlanmak için Helios ile entegre yazılımlar geliştirebilir. İşte bazı potansiyel gelişim yönleri:
P2P ağından hafif müşteri verilerini doğrudan almayı destekler, RPC'ye bağımlı kalmadan.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
17 Likes
Reward
17
4
Repost
Share
Comment
0/400
BearMarketSurvivor
· 28m ago
Güven maliyeti finally düşüş oldu.
View OriginalReply0
SerLiquidated
· 1h ago
Merkeziyetsizleştirme kanserinin çözülmesi gerekmektedir.
Helios hafif müşteri: Tam güvenilmez Ethereum on-chain veri erişimi sağlamak
Ethereum hafif müşteri Helios: Güven gerektirmeyen Blok Zinciri erişimi sağlamak
8 Kasım'da, yeni bir Ethereum hafif müşteri Helios resmi olarak piyasaya sürüldü. Bu müşteri, tamamen güvene ihtiyaç duymadan Ethereum erişimi sağlamak amacıyla Rust dilinde geliştirilmiştir.
Blok zincirinin temel amaçlarından biri, güvene ihtiyaç duymadan işlem yapmaktır. Blok zinciri sayesinde, kendi varlıklarımızı ve verilerimizi bağımsız bir şekilde kontrol edebiliriz. Çoğu durumda, Ethereum gibi blok zincirleri bu vaadi gerçekten yerine getirmiştir: varlıklarımız gerçekten bize aittir.
Ancak, kullanım kolaylığını sağlamak için bazı tavizler verdik. Bunlardan biri, merkezi RPC( uzaktan çağrı) sunucusunu kullanmaktır. Kullanıcılar genellikle Ethereum'a merkezi sağlayıcılar aracılığıyla erişir. Bu şirketler, bulut sunucularında yüksek performanslı düğümler çalıştırarak herkesin zincir üzerindeki verilere kolayca erişmesine yardımcı olur. Cüzdan, token bakiyesini sorguladığında veya işlem durumunu kontrol ettiğinde, neredeyse her zaman bu merkezi sağlayıcılardan faydalanılı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ğrulayamamalarıdır.
Helios, tamamen güvenilir bir Ethereum erişimi sağlayabilen Rust tabanlı bir Ethereum hafif müşteri uygulamasıdır. Ethereum'un PoS'a geçişi ile sağlanan hafif müşteri protokolünü kullanarak, güvenilmeyen merkezi RPC sağlayıcılarından gelen verileri güvenli bir şekilde doğrulanabilir yerel RPC'ye dönüştürebilir. Merkezi RPC ile birleştirildiğinde, Helios tam bir düğüm çalıştırmadan veri doğruluğunu doğrulayabilir.
Bu hafif müşteri, yaklaşık iki saniye içinde senkronizasyonu tamamlayabilir ve depolama gerektirmez. Kullanıcılar, herhangi bir cihaz(, mobil telefonlar ve tarayıcı eklentileri) aracılığıyla zincir üzerindeki verilere güvenli bir şekilde erişebilir. Ancak merkezileşmiş altyapılara bağımlılığın potansiyel riskleri nelerdir? Şimdi bu riskleri analiz edecek, Helios'un tasarım çözümünü tanıtacak ve kod havuzunu geliştirmeye yardımcı olacak bazı fikirler sunacağız.
Merkezileştirilmiş Altyapının Potansiyel Riskleri
Teorik bir saldırı yöntemi Ethereum'un "karanlık ormanı" içinde gizleniyor. Bu, işlem hafıza havuzunda hedef aramak yerine, bağımlı olduğumuz merkezi altyapıyı taklit ederek tuzaklar kurmaktır. Kullanıcılar hata yapmamış olsalar bile tuzağa düşebilirler: Sadece her zamanki gibi DEX'te işlem yapıyorlar, makul bir kayma ayarlıyorlar... ama yine de RPC sağlayıcısında dikkatlice kurulmuş yeni bir sandviç saldırısına maruz kalabilirler.
Merkeziyetsiz borsa işlemleri sırasında, kullanıcıların akıllı sözleşmeye birkaç parametre sağlaması gerekir: 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ı belirtir, aksi takdirde işlem iptal edilir. Bu genellikle "kayma" olarak adlandırılır ve işlem gönderildikten sonra işlemin blok zincirine eklenmesi arasında ortaya çıkabilecek maksimum fiyat farkını etkili bir şekilde belirler. Eğer kayma ayarı çok düşükse, kullanıcı daha az token alabilir ve ayrıca sandviç saldırısına maruz kalabilir.
En az çıktı parametreleri makul bir aralıkta ayarlandığı sürece, sandviç saldırısından etkilenmez. Ancak, RPC sağlayıcısı DEX akıllı sözleşmesinin doğru fiyat teklifini sağlamazsa ne olur? Bu, kullanıcıların yanıltılmasına ve daha düşük en az çıktı parametreleriyle değişim işlemleri imzalamalarına neden olabilir. 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ı, işlemi halka açık bellek havuzuna yaymamakta ve bunun yerine saldırıya uğramış işlem paketini kar elde etmek için belirli bir kuruma özel olarak göndermekte serbesttir.
Bu tür bir saldırının temel nedeni, başkalarına güvenerek blok zinciri durumunu elde etmektir. Bu sorunu çözmek için deneyimli kullanıcılar genellikle kendi Ethereum düğümlerini çalıştırır, ancak bu önemli ölçüde zaman ve kaynak gerektirir; en azından sürekli çevrimiçi bir cihaz, yüzlerce GB depolama alanı ve baştan senkronize etmek için yaklaşık bir gün gereklidir. Şu anda düğüm çalıştırma eşiği düşmüş olsa da, çoğu kullanıcı için hâlâ zordur, özellikle mobil cihaz kullananlar için.
Dikkat edilmesi gereken husus, merkezi RPC sağlayıcılarının saldırılarının tamamen mümkün olmasına rağmen genellikle basit bir phishing saldırısı olduğudur; tarif ettiğimiz türde bir saldırı henüz gerçekleşmemiştir. Ana akım sağlayıcıların geçmiş kayıtları güvenilir olsa da, tanıdık olmayan RPC sağlayıcılarını kullanmadan önce biraz daha araştırma yapmak yine de akıllıca bir seçimdir.
Helios: Güven gerektirmeyen Ethereum erişimi
Ethereum hafif müşteri protokolünü tanıttı, hızlı Blok Zinciri etkileşimleri ve en düşük donanım gereksinimleriyle RPC uç noktalarını doğrulama için yeni olanaklar sağladı. The Merge'den sonraki bir ay içinde, bir dizi bağımsız hafif müşteri art arda piyasaya sürüldü, farklı yaklaşımlar benimsediler, ancak hedefleri aynıydı: tam düğüm çalıştırmadan güvenilir erişimi verimli bir şekilde sağlamak.
Helios, yaklaşık iki saniye içinde senkronizasyon yapabilen, depolama gerektirmeyen ve tamamen güvenilmez Ethereum erişimi sağlayan bir Ethereum hafif müşterisidir. Tüm Ethereum istemcileri gibi, Helios da yürütme katmanı ve konsensüs katmanı içerir. Ancak çoğu istemciden farklı olarak, Helios bu iki katmanı sıkı bir şekilde birleştirmiştir; kullanıcıların yalnızca tek bir yazılım kurup çalıştırmaları yeterlidir.
Helios'un çalışma prensibi şöyledir: Konsensüs katmanı, bilinen bir referans zinciri blok hash'ini kullanır ve güvenilmeyen bir RPC ile bağlantı kurarak geçerli bir şekilde mevcut bloğa senkronize olur. İcra katmanı, bu doğrulanmış referans zinciri bloklarını güvenilmeyen icra katmanı RPC'si ile birleştirerek, blok üzerindeki durumun çeşitli bilgilerini doğrular; örneğin hesap bakiyeleri, 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ıya tamamen güven gerektirmeyen bir RPC sunar ve tam bir düğüm çalıştırma gerektirmez.
Konsens Katmanı
Konsensüs katmanı hafif müşteri, işaret zinciri hafif müşteri standartlarına uyar ve işaret zincirinin senkronizasyon komitesinden faydalanır. Senkronizasyon komitesi, rastgele seçilen 512 doğrulayıcıdan oluşan bir alt kümedir ve hizmet süresi 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ı imzalar. Eğer komite üyelerinin %2/3'ünden fazlası bir blok başlığını imzaladıysa, bu blok muhtemelen standart işaret zincirinde bulunmaktadır. Helios, mevcut senkronizasyon komitesinin bileşimini anlıyorsa, en son senkronizasyon komitesi imzalarını sorgulayarak zincir başını güvenilir bir şekilde izleyebilir.
BLS imza birleştirmesi sayesinde, yeni blok başlığının doğrulanması için yalnızca bir sorgu yeterlidir. İmza geçerli olduğu ve 2/3'ten fazla komite üyesi imzayı tamamladığı sürece, bloğun zincire dahil olduğu garanti edilebilir. Elbette, blokların nihaiğini takip etmek daha güçlü bir garanti sağlayabilir.
Bu stratejide, mevcut senkronizasyon komitesinin nasıl bulunacağına dair bir sorun da çözülmelidir. Öncelikle, zayıf öznelik kontrol noktası olarak adlandırılan bir güven kökü elde edilmelidir. Bu, geçmişte belirli bir zamanda zincire dahil edilmiş olan eski blok hash'ini garanti eden bir değerdir. Kontrol noktalarının varlık süresi hakkında, teorik analiz en kötü durumda yaklaşık iki hafta, ancak pratik tahminler birkaç aya kadar uzanabilir.
Eğer kontrol noktası çok eskiyse, teorik olarak düğümleri yanlış bir zinciri takip etmeye ikna edebilecek bir saldırı mümkündü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ı sağlamaktır; bunu kod havuzuna sert kodlama ile eklemek ( kolayca üzerine yazılabilir ), en son nihai blok hash'ini yerel olarak saklar, böylece düğümler senkronize olurken kontrol noktası olarak kullanılabilir.
Hash işlemi aracılığıyla, işaret zinciri blokları kolaylıkla benzersiz bir işaret blok hash'i oluşturabilir. Bu, tam işaret bloklarını kolayca sorgulamayı sağlar ve ardından hash karşılaştırması yoluyla blok içeriğinin geçerliliğini kanıtlar. Helios, bu özelliği, zayıf öznelite kontrol noktası blokları içindeki kritik alanları elde etmek ve doğrulamak için kullanır; bunlar arasında mevcut senkronizasyon komitesi ve bir sonraki senkronizasyon komitesi bulunmaktadır. En önemlisi, hafif müşteri bu mekanizmayı kullanarak blok zinciri tarihini hızlı bir şekilde gözden geçirebilir.
Zayıf öznelik kontrol noktası ile, mevcut ve bir sonraki senkronizasyon komitesini alabilir ve doğrulayabiliriz. Eğer mevcut zincir başı ve kontrol noktası aynı senkronizasyon komitesi döngüsünde ise, yeni blokları doğrulamak için imzalı senkronizasyon komitesi başlığını hemen kullanabiliriz. Eğer kontrol noktası birkaç senkronizasyon komitesinin ardından geliyorsa, o zaman:
Gelecek bir senkronizasyon komitesinin bloklarını 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 arkadaysa, adım 1'e dön.
Yukarıda belirtilen süreç aracılığıyla, 27 saatlik birimlerle, bu Blok Zinciri'nin geçmişini hızlı bir şekilde gözden geçirebiliriz, geçmişteki herhangi bir Blok hash'inden başlayarak, mevcut Blok hash'ine kadar senkronize edebiliriz.
yürütme katmanı
Yürütme katmanı hafif müşterisinin amacı, konsensüs katmanı tarafından doğrulanan ana blok başlıklarını güvensiz yürütme katmanı RPC'si ile birleştirerek doğrulanmış yürütme katmanı verileri sağlamaktır. Bu verilere daha sonra Helios aracılığıyla yerel olarak barındırılan RPC sunucusu üzerinden erişilebilir.
Aşağıda hesap bakiyesi elde etmenin basit bir örneği verilmiştir, öncelikle Ethereum'un durumu nasıl depoladığını kısaca tanıtacağız. 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, ayarlanmış büyük bir Merkle-Patricia ağacında depolanır. Durum ağacının kökü bilindiğinde, Merkle kanıtını doğrulamak için kullanılabilir, böylece ağaçta herhangi bir hesabın var olup olmadığını kanıtlayabilirsiniz. Bu kanıt sahtecilikten korunmuştur.
Helios, konsensüs katmanından doğrulanmış durum kökünü alır. Güvensiz yürütme katmanı RPC'si aracılığıyla bu durum kökünü ve Merkle kanıtı talebini uygulayarak, Helios Ethereum'da saklanan tüm verileri yerel olarak doğrulayabilir.
Farklı teknolojiler kullanarak, yürütme katmanında kullanılan çeşitli verileri doğruluyoruz, böylece güvenilmeyen RPC'lerden gelen tüm verileri doğrulayabiliyoruz. Güvenilmeyen RPC veri erişimini sağlamayı reddedebilir, ancak yanlış sonuçlar sunamaz.
Helios'un Uygulama Geleceği
Kullanışlılık ile merkeziyetsizlik arasında denge sağlamak zor bir sorun. Hafif müşteri Helios ile kullanıcılar, herhangi bir cihaz(, telefon ve tarayıcı eklentisi) dahil olmak üzere güvenli zincir verilerine erişebilirler. Bu, daha fazla kişinin, hangi donanımı kullanırsa kullansın, Eter verilerine güvenmeden erişebilmesini sağlayacak. Kullanıcılar, cüzdanlarında Helios'u RPC sağlayıcısı olarak kullanarak, herhangi bir başka değişiklik yapmadan çeşitli DApp'lere güvenmeden erişim sağlayabilirler.
Ayrıca, Rust'ın WebAssembly desteği, uygulama geliştiricilerin Helios'u Javascript uygulamalarına (, cüzdanlar ve DApp'ler ) gibi kolayca entegre etmelerini sağlar. Bu entegrasyonlar, Ethereum'un güvenliğini artıracak ve merkezi altyapıya olan güven ihtiyacımızı azaltacaktır.
Topluluk, Helios'a katkıda bulunmanın çeşitli yollarını bulabilir; kod havuzunu geliştirmek dışında, Helios'un avantajlarından yararlanmak için Helios ile entegre yazılımlar geliştirebilir. İşte bazı potansiyel gelişim yönleri: