Giriş

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Kriptografiden gelen kesinlikle güçlü bir şifre kavramında olduğu gibi, gerçek "Kamuya Açık Olarak Doğrulanabilir Rastgele İşaret" (bundan sonra PVRB olarak anılacaktır) protokolleri yalnızca ideal şemaya mümkün olduğunca yaklaşmaya çalışır, çünkü gerçek ağlarda saf haliyle uygulanamaz: bir bit üzerinde kesin olarak anlaşmak gerekir, çok sayıda tur olmalıdır ve tüm mesajlar mükemmel şekilde hızlı olmalı ve her zaman iletilmelidir. Elbette gerçek ağlarda durum böyle değil. Bu nedenle, modern blok zincirlerdeki belirli görevler için PVRB'leri tasarlarken, ortaya çıkan rastgeleliği ve kriptografik gücü kontrol etmenin imkansızlığına ek olarak, tamamen mimari ve teknik birçok sorun ortaya çıkar.

PVRB için blok zincirinin kendisi aslında mesajların = işlemlerin olduğu bir iletişim ortamıdır. Bu, ağ sorunlarından, mesajların teslim edilmemesinden, ara yazılım sorunlarından kısmen kurtulmanıza olanak tanır - tüm bu riskler merkezi olmayan ağ tarafından üstlenilir ve PVRB için ana değeri, önceden gönderilmiş bir işlemi iptal edememek veya bozamamaktır - bu, Konsensüse başarılı bir saldırı yapmadıkları sürece katılımcıların protokole katılmayı reddetmelerine izin vermeyin. Bu güvenlik seviyesi kabul edilebilir düzeyde olduğundan PVRB, katılımcıların gizli anlaşmalarına karşı ana blockchain zinciriyle aynı ölçüde dayanıklı olmalıdır. Ayrıca bu, ağın ana blok zinciri üzerinde anlaşmaya varması durumunda, rastgele sonuçlanan tek adil karar üzerinde de anlaşsa bile, PVRB'nin konsensüsün bir parçası olması gerektiğini ima ediyor. Veya PVRB, blok zincirine ve bloklara göre asenkron olarak çalışan akıllı bir sözleşme tarafından uygulanan bağımsız bir protokoldür. Her iki yöntemin de avantajları ve dezavantajları vardır ve aralarındaki seçim son derece önemsizdir.

PVRB'yi uygulamanın iki yolu

PVRB'yi uygulamaya koymak için iki seçeneği daha ayrıntılı olarak açıklayalım: Blockchain'den bağımsız akıllı bir sözleşme kullanarak çalışan bağımsız versiyon ve ağın blockchain ve sözleşme üzerinde mutabakata vardığı protokole yerleşik konsensüs entegreli versiyon. dahil edilecek işlemler. Her durumda, popüler blockchain motorlarını kastediyorum: Ethereum, EOS ve akıllı sözleşmeleri barındırma ve işleme şekli bakımından bunlara benzeyenler.

Bağımsız sözleşme

Bu versiyonda PVRB, rastgele üreticilerin (bundan sonra RP olarak anılacaktır) işlemlerini kabul eden, bunları işleyen, sonuçları birleştiren ve bunun sonucunda herhangi bir kullanıcının bu sözleşmeden alabileceği belirli bir değere ulaşan akıllı bir sözleşmedir. Bu değer doğrudan sözleşmede saklanamaz, bunun yerine yalnızca elde edilen rastgeleliğin tek ve tek bir değerinin deterministik olarak elde edilebildiği verilerle temsil edilebilir. Bu şemada, RP'ler blok zincirinin kullanıcılarıdır ve herkesin üretim sürecine katılmasına izin verilebilir.

Bağımsız sözleşmeli seçenek iyidir:

• taşınabilirlik (sözleşmeler blockchain'den blockchain'e sürüklenebilir)
• uygulama ve test kolaylığı (sözleşmelerin yazılması ve test edilmesi kolaydır)
• Ekonomik planların uygulanmasında kolaylık (mantığı PVRB'nin amaçlarına hizmet eden kendi jetonunuzu yapmak kolaydır)
• Halihazırda çalışan blok zincirlerinde başlatma olasılığı

Ayrıca dezavantajları da vardır:

• bilgi işlem kaynakları, işlem hacmi ve depolama (başka bir deyişle cpu/mem/io) konusunda güçlü sınırlamalar
• sözleşme kapsamındaki işlemlere ilişkin kısıtlamalar (talimatların tümü mevcut değildir, harici kütüphanelere bağlanmak zordur)
• mesajlaşmanın blok zincirine dahil edilen işlemlerden daha hızlı organize edilememesi

Bu seçenek, mevcut bir ağ üzerinde çalıştırılması gereken, karmaşık şifreleme içermeyen ve çok sayıda etkileşim gerektirmeyen bir PVRB'nin uygulanması için uygundur.

Konsensüs entegreli

Bu versiyonda, PVRB, blok zinciri düğüm koduna yerleşik olarak uygulanır veya blok zinciri düğümleri arasındaki mesaj alışverişine paralel olarak çalışır. Protokolün sonuçları üretilen bloklara doğrudan yazılıyor ve protokol mesajları düğümler arasında p2p ağı üzerinden gönderiliyor. Protokol bloklar halinde yazılacak sayıları ortaya çıkardığı için ağın bunlar üzerinde fikir birliğine varması gerekir. Bu, herhangi bir ağ katılımcısının PVRB protokolüne uygunluğu doğrulayabilmesi için, işlemler gibi PVRB mesajlarının da düğümler tarafından doğrulanması ve bloklara dahil edilmesi gerektiği anlamına gelir. Bu bizi otomatik olarak bariz çözüme götürür; eğer ağ bir blok ve içindeki işlemler hakkında fikir birliğine varırsa, o zaman PVRB tek başına bir protokol değil, fikir birliğinin bir parçası olmalıdır. Aksi takdirde, bir bloğun fikir birliği açısından geçerli olması ancak PVRB protokolüne uyulmaması ve PVRB açısından bloğun kabul edilememesi mümkündür. Dolayısıyla, "uzlaşı ile entegre" seçeneği seçilirse PVRB, fikir birliğinin önemli bir parçası haline gelir.

Ağ konsensüs düzeyinde PVRB uygulamalarını açıklarken kesinlik sorunlarından hiçbir şekilde kaçınılamaz. Kesinlik, paralel bir çatal oluşsa bile nihai olan ve asla atılmayacak bir bloğu (ve ona giden zinciri) taahhüt eden, deterministik fikir birliğinde kullanılan bir mekanizmadır. Örneğin, Bitcoin'de böyle bir mekanizma yoktur; daha karmaşık bir zincir yayınlarsanız, zincirlerin uzunluğuna bakılmaksızın daha az karmaşık olanın yerini alacaktır. Ve örneğin EOS'ta sonuncular, ortalama olarak her 432 blokta bir ortaya çıkan Son Geri Dönülemez Bloklardır (12*21 + 12*15, ön oylama + ön taahhüt). Bu süreç aslında blok üreticilerinin (bundan sonra BP olarak anılacaktır) 2/3'ünün imzasını bekliyor. Son LIB'den daha eski çatallar göründüğünde bunlar atılır. Bu mekanizma, saldırganın sahip olduğu kaynaklar ne olursa olsun, işlemin blok zincirine dahil edildiğini ve asla geri alınmayacağını garanti etmeyi mümkün kılar. Ayrıca son bloklar Hyperledger, Tendermint ve diğer pBFT tabanlı konsensüslerde 2/3 BP tarafından imzalanan bloklardır. Ayrıca, blokların üretimi ve yayınlanmasıyla eşzamansız olarak çalışabileceğinden, nihailiği sağlamak için fikir birliğine bir eklenti olarak bir protokol yapmak mantıklıdır. İşte iyi bir tane makale Ethereum'daki kesinlik hakkında.

Kesinlik, kullanıcılar için son derece önemlidir; bu kullanıcılar için, BP'nin blokları "tuttuğu" ve ağ iyi bir işlem "gördükten" sonra bunları yayınladığı "çifte harcama" saldırısının kurbanı olabilirler. Kesinlik yoksa, yayınlanan çatal, "iyi" bir işlemle bloğu, aynı fonların saldırganın adresine aktarıldığı "kötü" bir çataldan başka bir blokla değiştirir. PVRB söz konusu olduğunda, kesinlik gereklilikleri daha da sıkıdır, çünkü PVRB için çatal oluşturmak, saldırganın en karlı olanı yayınlamak için çeşitli rastgele seçenekler hazırlaması anlamına gelir ve olası bir saldırının süresini sınırlamak, bir saldırıdır. güzel çözüm.

Bu nedenle, en iyi seçenek PVRB'yi ve kesinliği tek bir protokolde birleştirmektir - o zaman sonlandırılmış blok = rastgele sonlandırılmıştır ve bu tam olarak elde etmemiz gereken şeydi. Artık oyuncular N saniye içinde garantili bir rastgelelik elde edecek ve bunu geri almanın veya tekrar oynatmanın imkansız olduğundan emin olabilecekler.

Konsensüs entegreli seçenek iyidir:

• blok üretimi ile ilgili olarak asenkron uygulama olasılığı - bloklar her zamanki gibi üretilir, ancak buna paralel olarak her blok için rastgelelik üretmeyen PVRB protokolü çalışabilir
• Akıllı sözleşmelere uygulanan kısıtlamalar olmadan ağır kriptografiyi bile uygulama yeteneği
• mesaj alışverişini işlemlerden daha hızlı organize etme yeteneği blok zincirine dahil edilir; örneğin, protokolün bir kısmı, mesajları ağ üzerinden dağıtmadan düğümler arasında çalışabilir

Ayrıca dezavantajları da vardır:

• Test ve geliştirmedeki zorluklar - ağ hatalarını, eksik düğümleri, ağ hard fork'larını taklit etmeniz gerekecek
• Uygulama hataları ağ hardforku gerektirir

Her iki PVRB uygulama yönteminin de yaşam hakkı vardır, ancak modern blok zincirlerdeki akıllı sözleşmelerin uygulanması, bilgi işlem kaynaklarında hala oldukça sınırlıdır ve ciddi kriptografiye herhangi bir geçiş genellikle imkansızdır. Aşağıda da görüleceği üzere ciddi bir kriptografiye ihtiyacımız olacak. Her ne kadar bu sorun açıkça geçici olsa da, birçok sorunun çözümü için sözleşmelerde ciddi kriptografiye ihtiyaç duyulmaktadır ve yavaş yavaş ortaya çıkmaktadır (örneğin, Ethereum'daki zkSNARK'lar için sistem sözleşmeleri)

Şeffaf ve güvenilir bir protokol mesajlaşma kanalı sağlayan Blockchain bunu ücretsiz olarak yapmıyor. Merkezi olmayan herhangi bir protokol, Sybil saldırısı olasılığını dikkate almalıdır; herhangi bir eylem, birden fazla hesabın ortak güçleri tarafından yapılabilir; bu nedenle, tasarım yaparken, saldırganların isteğe bağlı sayıda protokol oluşturma yeteneğini hesaba katmak gerekir. gizli anlaşma içinde hareket eden katılımcılar.

PVRB ve blok değişkenleri.

Pek çok kumar uygulaması tarafından test edilen iyi bir PVRB'yi henüz kimsenin blockchain'lerde uygulamadığını söylerken yalan söylemedim. Peki Ethereum ve EOS'ta bu kadar çok kumar uygulaması nereden geliyor? Bu sizi şaşırttığı kadar beni de şaşırtıyor, tamamen deterministik bir ortamda bu kadar çok “kalıcı” rastgeleyi nereden buldular?

Blockchain'de rastgelelik elde etmenin en sevilen yolu, bloktan bir tür "öngörülemeyen" bilgi almak ve buna dayalı olarak rastgele bir bilgi oluşturmaktır - yalnızca bir veya daha fazla değerin hash'lenmesi yoluyla. Bu tür planların sorunları hakkında iyi bir makale burada. Bloktaki "öngörülemeyen" değerlerden herhangi birini alabilirsiniz; örneğin blok karması, işlem sayısı, ağ karmaşıklığı ve önceden bilinmeyen diğer değerler. Daha sonra bir veya daha fazlasını hashleyin ve teorik olarak gerçek bir rastgele elde etmelisiniz. Hatta yazıya planınızın "kuantum sonrası güvenli" olduğunu bile ekleyebilirsiniz (çünkü kuantum geçirmez karma işlevleri vardır :)).

Ancak kuantum sonrası güvenli karmalar bile ne yazık ki yeterli değil. İşin sırrı PVRB gerekliliklerinde yatıyor, bunları size önceki makaleden hatırlatmama izin verin:

1. Sonuç, kanıtlanabilir şekilde tekdüze bir dağılıma sahip olmalı, yani kanıtlanabilir derecede güçlü bir kriptografiye dayanmalıdır.
2. Sonucun herhangi bir bitini kontrol etmek mümkün değildir. Sonuç olarak, sonuç önceden tahmin edilemez.
3. Protokole katılmayarak veya ağı saldırı mesajlarıyla aşırı yükleyerek üretim protokolünü sabote edemezsiniz.
4. Yukarıdakilerin tümü, izin verilen sayıda sahtekâr protokol katılımcısının (örneğin katılımcıların 1/3'ünün) gizli anlaşmalarına karşı dayanıklı olmalıdır.

Bu durumda, yalnızca gereksinim 1 karşılanır ve gereksinim 2 karşılanmaz.Bloktan tahmin edilemeyen değerleri hash ederek, düzgün bir dağılım ve iyi rastgelelikler elde edeceğiz. Ancak BP'nin en azından "bloğu yayınlayıp yayınlamama" seçeneği var. Böylece BP en azından İKİ rastgele seçenek arasından seçim yapabilir: "kendisinin" ve başka birinin bloğu yapması durumunda ortaya çıkacak olan. BP, bir blok yayınlarsa ne olacağını önceden "gözetleyebilir" ve bunu yapıp yapmamaya karar verir. Bu nedenle, örneğin rulette "çift-tek" veya "kırmızı/siyah" oynarken, yalnızca kazanç görmesi durumunda bir blok yayınlayabilir. Bu aynı zamanda örneğin "gelecekten" bir blok hash kullanma stratejisini de kullanılamaz hale getirir. Bu durumda, “mevcut verilerle, örneğin N + 42 yüksekliğinde gelecekteki bir bloğun karma işleminin yapılmasıyla elde edilen, N'nin geçerli blok yüksekliği olduğu rastgele kullanılacaktır” diyorlar. Bu, planı biraz güçlendiriyor ancak yine de BP'nin, gelecekte de olsa, bloğu tutma veya yayınlama arasında seçim yapmasına olanak tanıyor.

Bu durumda BP yazılımı daha karmaşık hale gelir, ancak çok fazla değil. Basitçe, bir işlemi doğrularken ve bir bloğa dahil ederken, bir kazanç olup olmayacağını görmek için hızlı bir kontrol yapılır ve muhtemelen yüksek bir kazanma olasılığı elde etmek için bir işlem parametresi seçilir. Aynı zamanda bu tür manipülasyonlar için akıllı bir BP yakalamak neredeyse imkansızdır, her seferinde yeni adresleri kullanabilir ve şüphe uyandırmadan yavaş yavaş kazanabilirsiniz.

Dolayısıyla bloktan gelen bilgileri kullanan yöntemler, PVRB'nin evrensel bir uygulaması olarak uygun değildir. Sınırlı bir versiyonda, bahis boyutlarındaki kısıtlamalar, oyuncu sayısındaki kısıtlamalar ve/veya KYC kaydı (bir oyuncunun birden fazla adres kullanmasını önlemek için) ile bu planlar küçük oyunlar için işe yarayabilir, ancak daha fazlası değil.

PVRB ve taahhüt-açıklama.

Tamam, hash ve en azından blok hash'inin ve diğer değişkenlerin göreceli öngörülemezliği sayesinde. Önde çalışan madencilerin sorununu çözerseniz daha uygun bir şey almalısınız. Bu şemaya kullanıcıları ekleyelim - onların da rastgeleliği etkilemesine izin verin: herhangi bir teknik destek çalışanı size BT sistemlerindeki en rastgele şeyin kullanıcıların eylemleri olduğunu söyleyecektir :)

Kullanıcıların yalnızca rastgele sayılar gönderdiği ve sonucun örneğin toplamlarının bir karma değeri olarak hesaplandığı saf bir şema uygun değildir. Bu durumda son oyuncu kendi rastgele seçimini yaparak sonucun ne olacağını kontrol edebilir. Bu nedenle çok yaygın olarak kullanılan taahhüt-açıklama modeli kullanılır. Katılımcılar önce rastgelelerinden karmalar gönderirler (taahhütler) ve ardından rastgeleleri kendileri açarlar (açıklamalar). "Açıklama" aşaması ancak gerekli taahhütler toplandıktan sonra başlar, böylece katılımcılar daha önce gönderdikleri rastgele karmayı tam olarak gönderebilirler. Şimdi tüm bunları gelecekten alınmış olandan daha iyi bir bloğun parametreleriyle bir araya getirelim (rastgelelik yalnızca gelecekteki bloklardan birinde bulunabilir) ve işte - rastgelelik hazır! Artık herhangi bir oyuncu, ortaya çıkan rastgeleliği etkileyebilir ve kötü niyetli BP'yi, kendi önceden bilinmeyen rastgeleliğiyle geçersiz kılarak "yenebilir"... Ayrıca, protokolü açığa çıkarma aşamasında açmayarak, protokolü sabote etmeye karşı koruma da ekleyebilirsiniz - basitçe Taahhüt sırasında işleme belirli bir tutarın eklenmesini talep ederek - yalnızca açıklama prosedürü sırasında iade edilecek bir güvenlik depozitosu. Bu durumda taahhütte bulunmak ve açıklamamak kârsız olacaktır.

İyi bir girişimdi ve bu tür planlar oyun DApp'lerinde de mevcut, ancak ne yazık ki bu da yeterli değil. Artık sadece madenci değil, protokole katılan herhangi bir katılımcı da sonucu etkileyebilir. Değerin kendisini daha az değişkenlik ve maliyetle kontrol etmek hala mümkündür, ancak madencinin durumunda olduğu gibi, çekilişin sonuçları PVRB protokolüne katılım ücretinden daha değerliyse, o zaman rastgele -producer(RP) ortaya çıkıp çıkmayacağına karar verebilir ve yine de en az iki rastgele seçenek arasından seçim yapabilir.
Ancak suç işleyen ve ifşa etmeyenleri cezalandırmak mümkün hale geldi ve bu plan işe yarayacak. Basitliği ciddi bir avantajdır; daha ciddi protokoller çok daha güçlü hesaplamalar gerektirir.

PVRB ve deterministik imzalar.

RP'yi, bir "ön görüntü" ile sağlanmışsa etkileyemeyeceği sözde rastgele bir sayı sağlamaya zorlamanın başka bir yolu daha vardır - bu deterministik bir imzadır. Böyle bir imza örneğin RSA'dır ve ECS değildir. RP'nin bir çift anahtarı varsa: RSA ve ECC ve özel anahtarıyla belirli bir değeri imzalıyorsa, RSA durumunda BİR VE SADECE BİR imza alacaktır ve ECS durumunda herhangi bir sayıda anahtar üretebilir farklı geçerli imzalar. Bunun nedeni, bir ECS imzası oluştururken, imzalayan tarafından seçilen rastgele bir sayının kullanılması ve bu sayının, imzalayana çeşitli imzalardan birini seçme fırsatı vererek herhangi bir şekilde seçilebilmesidir. RSA durumunda: “bir giriş değeri” + “bir anahtar çifti” = “bir imza”. Başka bir RP'nin hangi imzayı alacağını tahmin etmek imkansızdır, dolayısıyla aynı değeri imzalayan birkaç katılımcının RSA imzaları birleştirilerek deterministik imzalara sahip bir PVRB düzenlenebilir. Örneğin, önceki rastgele. Bu şema çok fazla kaynak tasarrufu sağlar, çünkü imzalar hem protokole göre doğru davranışın teyidi hem de bir rastgelelik kaynağıdır.

Bununla birlikte, deterministik imzalar olsa dahi sistem hala “son aktör” sorununa karşı savunmasızdır. Son katılımcı imzanın yayınlanıp yayınlanmayacağına karar verebilir ve böylece sonucu kontrol edebilir. Şemayı değiştirebilir, blok karmaları ekleyebilir, sonucun önceden tahmin edilememesi için turlar yapabilirsiniz, ancak tüm bu teknikler, birçok değişikliği hesaba katsa bile, bir katılımcının kolektif üzerindeki etkisi sorununu hala çözülmemiş halde bırakmaktadır. güvenilmez bir ortama neden olur ve yalnızca ekonomik ve zaman kısıtlamaları altında çalışabilir. Ayrıca RSA anahtarlarının boyutu (1024 ve 2048 bit) oldukça büyüktür ve blockchain işlemleri için boyut son derece önemli bir parametredir. Görünüşe göre sorunu çözmenin basit bir yolu yok, devam edelim.

PVRB ve gizli paylaşım şemaları

Kriptografide, ağın tek ve tek bir PVRB değeri üzerinde anlaşmasına olanak tanıyan şemalar bulunurken, bu tür şemalar bazı katılımcıların kötü niyetli eylemlerine karşı dayanıklıdır. Tanımaya değer yararlı protokollerden biri Shamir'in gizli paylaşım planıdır. Bir sırrın (örneğin gizli bir anahtarın) birkaç parçaya bölünmesine ve bu parçaların N katılımcıya dağıtılmasına hizmet eder. Sır, N'den M parçanın onu kurtarmaya yeteceği şekilde dağıtılır ve bunlar herhangi bir M parça olabilir. Parmaklarda ise, bilinmeyen bir fonksiyonun grafiğine sahip olan katılımcılar grafik üzerinde puan alışverişinde bulunurlar ve M puanları aldıktan sonra tüm fonksiyon geri yüklenebilir.
Güzel bir açıklama yapılmış wiki ancak protokolü kafanızda oynamak için onunla pratik olarak oynamak faydalıdır. gösteri sayfa.

FSSS (Fiat-Shamir Gizli Paylaşımı) şeması saf haliyle uygulanabilir olsaydı, yok edilemez bir PVRB olurdu. En basit haliyle protokol şöyle görünebilir:

• Her katılımcı kendi rastgelesini oluşturur ve bundan elde edilen paylaşımları diğer katılımcılara dağıtır.
• Her katılımcı diğer katılımcıların sırlarından kendi payına düşeni açıklar
• Bir katılımcının M'den fazla paylaşımı varsa bu katılımcının sayısı hesaplanabilir ve açıklanan katılımcı grubuna bakılmaksızın benzersiz olacaktır.
• Ortaya çıkan rastgele kombinasyonların kombinasyonu istenen PVRB'dir

Burada, rastgelelik açıklama eşiğine ulaşmanın yalnızca kendisine bağlı olduğu durumlar dışında, bireysel bir katılımcı artık protokolün sonuçlarını etkilemez. Dolayısıyla bu protokol, eğer protokol üzerinde çalışan ve mevcut olan gerekli oranda RP varsa çalışır, kriptografik güç gerekliliklerini yerine getirir ve “son aktör” sorununa karşı dayanıklıdır.

Bu ideal bir seçenek olabilir; Fiat-Shamir gizli paylaşımına dayalı bu PVRB şeması örneğin şurada anlatılmıştır: bu madde. Ancak yukarıda da bahsettiğimiz gibi bunu blockchain'de doğrudan uygulamaya çalışırsanız teknik sınırlamalar ortaya çıkar. EOS akıllı sözleşmesindeki protokolün test uygulamasına ve bunun en önemli kısmına - yayınlanan paylaşım katılımcısının kontrol edilmesine - bir örnek: kod. Kanıt doğrulamanın birkaç skaler çarpım gerektirdiğini ve kullanılan sayıların çok büyük olduğunu koddan görebilirsiniz. Blok zincirlerinde doğrulamanın, blok üreticisinin işlemi işlediği anda gerçekleştiği ve genel olarak herhangi bir katılımcının protokolün doğruluğunu kolayca doğrulaması gerektiği, dolayısıyla doğrulama işlevinin hızına ilişkin gereksinimlerin çok ciddi olduğu anlaşılmalıdır. . Bu seçenekte, doğrulama işlem limitine (0.5 saniye) uymadığı için seçeneğin etkisiz olduğu ortaya çıktı.

Doğrulama verimliliği, genel olarak blockchaindeki herhangi bir gelişmiş şifreleme şemasının kullanımı için en önemli gereksinimlerden biridir. Kanıtların oluşturulması, mesajların hazırlanması - bu prosedürler zincirden çıkarılabilir ve yüksek performanslı bilgisayarlarda gerçekleştirilebilir, ancak doğrulama atlanamaz - bu PVRB için bir başka önemli gerekliliktir.

PVRB ve eşik imzaları

Gizli paylaşım şemasıyla tanıştıktan sonra, "eşik" anahtar kelimesiyle birleştirilen bütün bir protokol sınıfını keşfettik. Bazı bilgilerin açıklanması, N içinden M dürüst katılımcının katılımını gerektirdiğinde ve dürüst katılımcılar kümesi, N'nin keyfi bir alt kümesi olabildiği zaman, "eşik" planlarından söz ederiz. "Son aktör" sorununu çözmemize izin verenler onlardır, eğer saldırgan sırrın kendi payına düşen kısmını açıklamazsa, bunu onun yerine başka bir dürüst katılımcı yapacaktır. Bu planlar, protokol bazı katılımcılar tarafından sabote edilse bile tek bir anlam üzerinde anlaşmaya varılmasına izin verir.

Deterministik imzalar ve eşik şemalarının kombinasyonu, PVRB'nin uygulanması için çok uygun ve umut verici bir şema geliştirmeyi mümkün kıldı - bunlar deterministik eşik imzalarıdır. Burada makale eşik imzalarının çeşitli kullanımları hakkında ve işte başka bir iyi şey longread Dash'ten.

Son makalede BLS imzaları açıklanmaktadır (BLS, Boneh-Lynn-Shacham anlamına gelir, burada programcılar için çok önemli ve son derece kullanışlı bir kaliteye sahip olan genel, gizli, genel anahtarlar ve BLS imzaları, basit matematiksel işlemler kullanılarak birbirleriyle birleştirilebilirken bunların kombinasyonları geçerli anahtarlar ve imzalar olarak kalır ve birçok şeyi kolayca toplamanıza olanak tanır. imzaları bire ve birçok genel anahtarı bire. Ayrıca deterministiktirler ve aynı girdi verileri için aynı sonucu üretirler. Bu kalite nedeniyle, BLS imzalarının kombinasyonları geçerli anahtarlardır; bu, M of N katılımcısının, Mth tarafından açılana kadar deterministik, kamuya açık olarak doğrulanabilir ve öngörülemeyen bir ve yalnızca bir imza ürettiği bir seçeneğin uygulanmasına izin verir. katılımcı

Eşik BLS imzalarına sahip bir şemada, her katılımcı BLS kullanarak bir şeyi imzalar (örneğin önceki rastgele) ve ortak eşik imzası istenen rastgeledir. BLS imzalarının kriptografik özellikleri rastgele kalite gereksinimlerini karşılar, eşik kısmı "son aktöre" karşı koruma sağlar ve anahtarların benzersiz birleştirilebilirliği, örneğin protokol mesajlarının verimli bir şekilde toplanmasına izin veren çok daha ilginç algoritmaların uygulanmasını mümkün kılar .

Dolayısıyla, eğer blok zincirinizde PVRB oluşturuyorsanız, büyük olasılıkla BLS eşik imza şemasına sahip olacaksınız; birçok proje zaten bunu kullanıyor. Örneğin, DFinity (burada Devreyi uygulayan kıyaslama ve burada doğrulanabilir gizli paylaşımın örnek uygulaması) veya Keep.network (işte onların rastgele işaretçileri) sarı kağıt, Ama örnek protokole hizmet eden akıllı sözleşme).

PVRB'nin uygulanması

Maalesef PVRB blok zincirlerinde uygulanan, güvenliğini ve istikrarını kanıtlamış hazır bir protokolü hala göremiyoruz. Protokollerin kendisi hazır olsa da teknik olarak bunları mevcut çözümlere uygulamak kolay değil. Merkezi sistemler için PVRB'nin bir anlamı yoktur ve merkezi olmayan sistemler tüm bilgi işlem kaynakları açısından kesinlikle sınırlıdır: CPU, bellek, depolama, G/Ç. Bir PVRB tasarlamak, en azından uygulanabilir bir blockchain için tüm gereksinimleri karşılayan bir şey yaratmak amacıyla farklı protokollerin bir kombinasyonudur. Bir protokol daha verimli hesaplama yapar ancak RP'ler arasında daha fazla mesaj gerektirirken diğeri çok az mesaj gerektirir, ancak bir kanıt oluşturmak onlarca dakika, hatta saatler süren bir görev olabilir.

Kaliteli bir PVRB seçerken dikkate almanız gereken faktörleri listeleyeceğim:

• Şifreleme gücü. PVRB'niz kesinlikle tarafsız olmalı ve tek bir biti kontrol etme yeteneği olmamalıdır. Bazı programlarda durum böyle değildir; bu nedenle bir kriptograf çağırın
• “Son oyuncu” sorunu. PVRB'niz, bir veya daha fazla RP'yi kontrol eden bir saldırganın iki sonuçtan birini seçebileceği saldırılara karşı dayanıklı olmalıdır.
• Protokol sabotaj sorunu. PVRB'niz, bir veya daha fazla RP'yi kontrol eden bir saldırganın rastgele olup olmayacağına karar verdiği ve bunu etkilemesinin garanti edilebildiği veya belirli bir olasılıkla olduğu saldırılara karşı dayanıklı olmalıdır.
• Mesaj sayısı sorunu. RP'leriniz blockchain'e minimum düzeyde mesaj göndermeli ve "Bazı bilgiler gönderdim, belirli bir katılımcıdan yanıt bekliyorum" gibi eşzamanlı eylemlerden mümkün olduğunca kaçınmalıdır. P2p ağlarında, özellikle coğrafi olarak dağınık olanlarda, hızlı yanıta güvenmemelisiniz
• Hesaplama karmaşıklığı sorunu. Zincir üzerindeki PVRB'nin herhangi bir aşamasının doğrulanması, ağdaki tüm tam istemciler tarafından gerçekleştirildiğinden son derece kolay olmalıdır. Uygulama akıllı sözleşme kullanılarak yapılıyorsa hız gereksinimleri çok katıdır
• Erişilebilirlik ve canlılık sorunu. PVRB'niz, ağın bir kısmının belirli bir süre boyunca kullanılamadığı ve RP'nin bir kısmının çalışmayı bıraktığı durumlara karşı dayanıklı olmaya çalışmalıdır.
• Güvenilir kurulum ve ilk anahtar dağıtımı sorunu. PVRB'niz protokolün birincil kurulumunu kullanıyorsa bu ayrı bir büyük ve ciddi hikayedir. Burada örnek. Katılımcıların protokole başlamadan önce anahtarlarını birbirlerine söylemeleri gerekiyorsa, katılımcıların kompozisyonunun değişmesi durumunda da bu bir sorundur.
• Geliştirme sorunları. Kütüphanelerin gerekli dillerde mevcudiyeti, güvenlikleri ve performansları, tanıtım, karmaşık testler vb.

Örneğin, eşik BLS imzalarının önemli bir sorunu var - çalışmaya başlamadan önce, katılımcılar anahtarları birbirlerine dağıtmalı ve eşiğin çalışacağı bir grup organize etmelidir. Bu, merkezi olmayan bir ağda en az bir değişim turunun beklemesi gerektiği anlamına gelir ve örneğin oluşturulan Rand'ın oyunlarda neredeyse gerçek zamanlı olarak gerekli olduğu göz önüne alındığında, bu, protokolün sabote edilmesinin bu aşamada mümkün olduğu anlamına gelir. ve eşik düzeninin avantajları kaybolur. Bu sorun zaten öncekilerden daha basittir, ancak yine de, kurallara uymayan katılımcılardan para yatırma ve çekme (kesme) yoluyla ekonomik olarak korunması gereken eşik gruplarının oluşturulması için ayrı bir prosedürün geliştirilmesini gerektirmektedir. protokol. Ayrıca, kabul edilebilir bir güvenlik düzeyine sahip BLS doğrulaması, örneğin standart bir EOS veya Ethereum işlemine uymuyor; doğrulama için yeterli zaman yok. Sözleşme kodu, sanal bir makine tarafından yürütülen WebAssembly veya EVM'dir. Şifreleme işlevleri yerel olarak (henüz) uygulanmamaktadır ve geleneksel şifreleme kitaplıklarından onlarca kat daha yavaş çalışır. Birçok protokol, yalnızca anahtar hacmine dayalı gereksinimleri karşılamaz; örneğin RSA için 1024 ve 2048 bit, Bitcoin ve Ethereum'daki standart işlem imzasından 4-8 kat daha büyüktür.

Farklı programlama dillerinde uygulamaların varlığı da bir rol oynamaktadır; özellikle yeni protokoller için bunlardan çok azı vardır. Konsensusla entegrasyon seçeneği, platform dilinde bir protokol yazmayı gerektirir; bu nedenle, geth için Go'da, Parity için Rust'ta, EOS için C++'da kod aramanız gerekecektir. Herkesin JavaScript kodunu araması gerekecek ve JavaScript ile kriptografi pek yakın arkadaş olmadığından, artık kesinlikle bir sonraki önemli İnternet standardı olduğunu iddia eden WebAssembly yardımcı olacaktır.

Sonuç

umarım bir öncekinde Makale Blockchain üzerinde rastgele sayılar üretmenin merkezi olmayan ağların yaşamının birçok yönü için kritik olduğuna sizi ikna etmeyi başardım ve bu makaleyle bu görevin son derece iddialı ve zor olduğunu ancak iyi çözümlerin zaten mevcut olduğunu gösterdim. Genel olarak, protokolün nihai tasarımı yalnızca kurulumdan hata emülasyonuna kadar tüm hususları dikkate alan kapsamlı testler gerçekleştirildikten sonra mümkündür; bu nedenle ekibin teknik incelemelerinde ve makalelerinde hazır tarifler bulmanız pek mümkün değildir ve biz de kesinlikle bulmayacağız. Gelecek bir veya iki yıl içinde karar verin ve "bunu bu şekilde yapın, tam olarak doğru" yazın.

Geliştirilmekte olan blockchaindeki PVRB'mize güle güle Haya, eşik BLS imzalarını kullanmaya karar verdik, akıllı sözleşmelerde kabul edilebilir bir güvenlik düzeyine sahip doğrulama henüz mümkün olmadığından PVRB'yi fikir birliği düzeyinde uygulamayı planlıyoruz. Aynı anda iki şema kullanmamız mümkündür: ilki, uzun vadeli random_seed oluşturmak için pahalı gizli paylaşım ve ardından bunu deterministik eşik BLS imzalarını kullanarak yüksek frekanslı rastgele oluşturmanın temeli olarak kullanırız, belki de kendimizi yalnızca bunlarla sınırlayacağız. planlardan biri. Protokolün ne olacağını önceden söylemek ne yazık ki mümkün değil; tek iyi şey, bilimde olduğu gibi mühendislik problemlerinde de olumsuz bir sonucun da bir sonuç olması ve sorunu çözmeye yönelik her yeni girişimin, çözüm için yeni bir adım olmasıdır. Soruna dahil olan herkesin araştırması. İş gereksinimlerini karşılamak için belirli bir pratik sorunu çözüyoruz - oyun uygulamalarına güvenilir bir entropi kaynağı sağlıyoruz, bu nedenle aynı zamanda blok zincirinin kendisine, özellikle de zincirin nihailiği ve ağ yönetişimi konularına da dikkat etmemiz gerekiyor.

Her ne kadar gerçek uygulamalar, çoklu denetimler, yüklemeler ve tabii ki gerçek saldırılar tarafından test edilmek için yeterli süre kullanılmış olan blok zincirlerde kanıtlanmış dirençli bir PVRB'yi henüz göremesek de, olası yolların sayısı bunu doğruluyor Bir çözüm var ve bu algoritmalardan hangisi eninde sonunda sorunu çözecek? Sonuçları paylaşmaktan ve mühendislerin aynı tırmığa iki kez basmamasını sağlayan makaleler ve kodlar için bu konu üzerinde çalışan diğer ekiplere teşekkür etmekten mutluluk duyacağız.

Bu nedenle, merkezi olmayan rastgele tasarım yapan bir programcıyla karşılaştığınızda dikkatli ve ilgili olun ve gerekirse psikolojik yardım sağlayın :)

Kaynak: habr.com