Giriş

Ethereum'un yol haritası , Veri Kullanılabilirliği Örneklemesi (DAS) 6 adı verilen bir ölçeklendirme teknolojisini içerir. DAS yeni<a href="https://notes.ethereum.org/ @djrtwo /das-requirements">gereksinimlerini sunuyor 4, Ethereum'un ağ oluşturma yığınına,özel ağ oluşturma protokollerinin 7 uygulanmasını gerektirir. Öne çıkan bir <a href="https://notes.ethereum.org/@dankrad /S-Kademlia-DAS"> protokol öneri 4, veri örneklerini depolamak ve almak için Kademlia 2'yi temel alan bir Dağıtılmış Karma Tablo (DHT) kullanır.

Ancak DHT'ler 4, Sybil saldırılarına karşı hassastır: Çok sayıda DHT düğümünü kontrol eden bir saldırgan, DAS örneklerini kullanılamaz hale getirebilir. Bu tehdide karşı koymak için yalnızca işaret zinciri doğrulayıcılarından oluşan yüksek güvenliğe sahip bir ağ katmanı oluşturulabilir. Böyle bir güvenlik önlemi, saldırganların DHT'ye saldırmak için artık kendi ETH'lerini yatırmaları gerektiğinden bariyeri önemli ölçüde artırıyor.

Bu yazıda, DHT katılımcılarının sıfır bilgiyle bir Ethereum doğrulayıcı olduklarını göstermelerini sağlayan bir kanıtlayıcı protokolü tanıtıyoruz.

Motivasyon: DAS'a “örnek gizleme” saldırısı

Bu bölümde, Veri Kullanılabilirliği Örneklemesine karşı bir Sybil saldırısını açıklayarak doğrulayıcı protokolünün kanıtını daha da motive ediyoruz.

DAS protokolü, blok oluşturucunun etrafında dönerek müşterilerin bunları alabilmesi için blok verilerinin kullanılabilir hale getirilmesini sağlar. Mevcut yaklaşımlar, verileri örneklere ayırmayı içerir ve ağ katılımcıları yalnızca kendi ilgi alanlarına uygun örnekleri getirir.

)

Bir Sybil saldırganının, ağ katılımcılarının, örneği sağlamaktan sorumlu olan bir kurban düğümden örnekler almasını engellemek istediği bir senaryoyu düşünün. Yukarıdaki şekilde gösterildiği gibi saldırgan, kurbanın düğüm kimliğine yakın birçok düğüm kimliği üretir. Saldırgan, kurbanın düğümünü kendi düğümleriyle çevreleyerek müşterilerin kurban düğümünü keşfetmesini engeller, çünkü kötü düğümler, kurbanın varlığına ilişkin bilgileri kasıtlı olarak saklar.

Bu tür Sybil saldırıları hakkında daha fazla bilgi için DHT Eclipse saldırılarına ilişkin bu son araştırma makalesine 2 bakın. Ayrıca, <a href="https://notes.ethereum.org/ @dankrad /S-Kademlia-DAS#SKademlia-modifications">Dankrad'ın DAS ağ protokolü teklifi 8, S/Kademlia DHT protokolünün bu tür saldırılardan nasıl zarar gördüğünü açıklıyor ve doğrulayıcı protokol kanıtına olan ihtiyacı gösteriyor.

Doğrulayıcının Kanıtı

Yukarıdaki saldırı, doğrulayıcı protokolü kanıtı ihtiyacını motive ediyor: DHT'ye yalnızca doğrulayıcılar katılabilirse, Sybil saldırısı başlatmak isteyen bir saldırganın da büyük miktarda ETH stake etmesi gerekir.

Doğrulayıcı kanıtı protokolümüzü kullanarak, yalnızca işaret zinciri doğrulayıcılarının DHT'ye katılabilmesini ve her doğrulayıcının benzersiz bir DHT kimliği almasını sağlıyoruz.

Ayrıca, doğrulayıcı DoS esnekliği için, ağ katmanındaki doğrulayıcıların kimliğini de gizlemeyi hedefliyoruz. Yani saldırganların hangi DHT düğümünün hangi doğrulayıcıya karşılık geldiğini bilmesini istemiyoruz.

Bu hedefleri gerçekleştirmek için doğrulayıcı protokolünün kanıtı aşağıdaki gereksinimleri karşılamalıdır:

• Benzersizlik: Her işaret zinciri doğrulayıcısı tek, benzersiz bir anahtar çifti türetebilmelidir. Bu özellik yalnızca Sybil saldırganının oluşturabileceği düğüm sayısını kısıtlamakla kalmaz, aynı zamanda ağ katılımcılarının, türetilmiş anahtar çiftlerini engellenenler listesine ekleyerek kötü davranan düğümleri yerel olarak cezalandırmasına da olanak tanır.
• Gizlilik: Saldırganlar, belirli bir türetilmiş genel anahtara hangi doğrulayıcının karşılık geldiğini öğrenememelidir
• Doğrulama Süresi: Protokolün doğrulama süreci verimli olmalı, düğüm başına 200 ms'den az sürmeli ve her düğümün saniyede en az beş yeni düğüm öğrenmesine olanak sağlamalıdır.

Böyle bir doğrulayıcı protokolü kanıtı, Bob tarafından DHT katmanında bağlantı kurulumu sırasında kullanılacaktır, böylece Alice, bir doğrulayıcıyla konuştuğunu bilir.

Doğrulayıcı Protokolünün Kanıtı

Doğrulayıcı protokolünün kanıtı, etkili bir şekilde basit bir anonim kimlik bilgisi şemasıdır. Amacı, Alice'in ancak ve ancak doğrulayıcı olması durumunda D olarak gösterilen benzersiz bir türetilmiş anahtar oluşturmasını sağlamaktır. Daha sonra Alice, türetilmiş bu D anahtarını ağ katmanında kullanır.

Bu protokolü tasarlarken amacımız, hem uygulanması hem de analiz edilmesi kolay bir çözüm oluşturmak ve belirtilen gereksinimleri verimli bir şekilde karşılamasını sağlamaktı.

Protokole genel bakış

Protokol, bir üyelik kanıtı alt protokolü kullanır; burada Alice, ZK kanıtlarını kullanarak gizli bir karma ön görüntüsüne ilişkin bilgisini göstererek bir doğrulayıcı olduğunu kanıtlar. Alice daha sonra bu gizli karma ön görüntüden türetilen benzersiz bir anahtar çifti oluşturur.

Üyelik kanıtı alt protokolü farklı yöntemlerle oluşturulabilir. Bu yazıda Merkle ağaçlarını kullanan bir protokol ve aramaları kullanan ikinci bir protokolü gösteriyoruz.

Her iki yaklaşım da kabul edilebilir bir verimlilik sergilerken, farklı ödünleşimlere sahiptirler. Merkle ağaçları, Poseidon gibi (deneysel olarak kabul edilebilir) SNARK dostu karma işlevlerine dayanır. Öte yandan, etkili arama protokolleri, doğrulayıcı kümesinin boyutuna eşit büyüklükte (şu anda 700 bin doğrulayıcı var ancak artıyor) büyüklükte, tau gücünde güvenilir bir kuruluma dayanır.

Şimdi protokollere geçelim:

Yaklaşım #1: Merkle Ağaçları

Merkle ağaçları üyelik kanıtları için yaygın olarak kullanılmaktadır (örn. bkz. Semafor 3). Merkle ağaçlarını kullanarak üyelik kanıtı tasarlarken yapılması gerekenler şunlardır:

• Olumlu: Güvenilir kuruluma gerek yok
• Olumlu: Anlaşılması basit
• Olumsuz: Poseidon gibi SNARK dostu karma işlevlerine dayanır
• Olumsuz: Daha yavaş kanıt oluşturma

Aşağıda Merkle ağaçlarını temel alan validatör protokolünün kanıtını açıklıyoruz:

Merkle ağaçlarını kullanan doğrulayıcı kanıt protokolü

)

Protokolün sonunda Alice, mesajları imzalamak ve benzersiz DHT düğüm kimliğini türetmek için DHT'deki D'yi kullanabilir.

Şimdi aramaları kullanan biraz daha karmaşık ama çok daha verimli bir çözüme bakalım.

Yaklaşım #2: Aramalar

İşte Caulk 2 gibi arama 2 protokollerini kullanmanın ödünleşim alanı:

• Olumlu: Son derece verimli kanıt oluşturma (bir ön işleme aşaması kullanılarak)
• Olumlu: Protokol, Poseidon yerine normal karma işlevini kullanacak şekilde uyarlanabilir
• Olumsuz: Büyük boyutlu güvenilir bir kurulum gerektirir (ideal olarak doğrulayıcıların boyutuna eşittir)

Aşağıda doğrulayıcı protokolünün somut bir kanıtını açıklıyoruz:

Aramaları kullanarak doğrulayıcı protokolünün kanıtı

Aynen Merkle yaklaşımında olduğu gibi, her doğrulayıcı i, blok zincirine yeni bir pi değeri kaydeder; öyle ki:

Yeterlik

Kanıt oluşturma ve doğrulama açısından üyelik kanıt protokolümüzün (bağlantı 6 ile karşılaştırma kodu 5) çalışma süresini karşılaştırdık. Üyelik kanıtının, doğrulama protokolü kanıtının yalnızca bir parçası olmasına rağmen, bunun genel çalışma süresine hakim olmasını beklediğimizi unutmayın.

Aşağıda, polinom taahhüt şeması olarak IPA ile Halo2 kanıt sistemini kullanan bir merkle ağacı üyelik kanıtı için kıyaslama sonuçlarını sunuyoruz. IPA, KZG'den daha yavaş bir şemadır ancak merkle ağacı yaklaşımının avantajlarını en üst düzeye çıkaracak güvenilir bir kurulum gerektirmez.

Hem kanıtlayıcı hem de doğrulayıcı sürelerinin verimlilik gereksinimlerimizle iyi uyum sağladığını gözlemliyoruz. Bu nedenle, performansının tüm kategorilerde (özellikle kanıtlayıcı süresi ve kanıt boyutu) önemli ölçüde daha iyi olması beklendiğinden, Caulk tabanlı yaklaşımı kıyaslamamaya karar verdik.

Karşılaştırmalar Intel i7-8550U (beş yıllık CPU) üzerinde çalışan bir dizüstü bilgisayarda toplandı.

Tartışma

Dönen kimlikler

Doğrulayıcı protokolünün kanıtının benzersizlik özelliği, her ağ katılımcısının farklı bir türetilmiş anahtar çiftine sahip olmasını sağlar. Bununla birlikte, belirli ağ protokolleri için, doğrulayıcıların, türetilmiş anahtarlarının periyodik olarak, belki de günlük olarak değiştiği, değişen kimliklere sahip olmasına izin vermek avantajlı olabilir.

Böyle bir senaryoda, Eve belirli bir günde yaramazlık yaparsa Alice onu o gün için engelleyebilir. Ancak ertesi gün Eve, engellenenler listesinde olmayan yeni bir türetilmiş anahtar oluşturabilir. Doğrulayıcıları dönüşümlü kimliklerine göre kalıcı olarak engellenenler listesine ekleyebilmek istiyorsak, SNARKBlock 1 gibi daha gelişmiş bir anonim kimlik bilgileri şemasına ihtiyacımız olacaktır.

Neden BLS12-381 kimliğinin ortak anahtarını kullanmıyorsunuz?

Alternatif (belki de daha basit) bir yaklaşım, tüm doğrulayıcı kimlik BLS12-381 anahtarlarından bir taahhüt oluşturmak ve bu taahhütle ilgili bir üyelik kanıtı yapmak olabilir.

Ancak bu yaklaşım, doğrulayıcıların geçerli bir üyelik kanıtı oluşturmak ve benzersiz türetilmiş anahtarı hesaplamak için kimlik özel anahtarlarını ZK kanıt sistemine eklemelerini gerektirecektir.

Hassas kimlik anahtarlarını karmaşık şifreleme protokolüne eklemek iyi bir uygulama olmadığından ve doğrulayıcıların ana kimlik anahtarlarını çevrimdışı tutmasını da zorlaştıracağından bu yaklaşımı benimsememeye karar verdik.

Gelecekteki araştırma yönleri

• SNARK devrelerinden tamamen kaçınıp üyelik kanıtını ve anahtar türetmeyi tamamen cebirsel bir şekilde gerçekleştirebilir miyiz?
• İlgili: Güvenilir bir kurulum olmadan ve SNARK dostu hash işlevlerine güvenmeden, etkili bir üyelik protokolü kanıtına sahip olabilir miyiz?

Teşekkür

Üyelik kanıtı kod tabanları ağında gezinme yardımlarından dolayı Enrico Bottazzi, Cedoor, Vivian Plasencia ve Wanseob'a teşekkür ederiz.

Yasal Uyarı:

1. Bu makale [ethresear]'dan yeniden basılmıştır. Tüm telif hakları orijinal yazara [George Kadianakis, Mary Maller, Andrija Novakovic, Suphanat Chunhapanya] aittir. Bu yeniden basıma itirazlarınız varsa lütfen Gate Learn ekibiyle iletişime geçin; onlar konuyu hemen halledeceklerdir.
2. Sorumluluk Reddi: Th
   Bu makalede ifade edilen görüş ve düşünceler yalnızca yazara ait olup, herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Aksi belirtilmedikçe tercüme edilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.