Bölüm 4
AElf rastgele sayı sözleşme standardı (ACS6)
Bu makale; Blockchain sistemlerindeki rastgele sayılar için yaygın çözümlere, rastgele sayılar sağlayan akıllı sözleşmeler için AElf tarafından sağlanan standart arayüzlere ve ACS6 için AEDPoS sözleşmelerinin uygulanmasına odaklanmaktadır.
Blockchain ve rastgele sayı
Blockchain geliştirilmesinde sözleşmeyle ilgili rastgele sayı uygulamaları için birkaç senaryo var: piyangolar, doğrulama kodları, şifre korelasyonları vb.
Blockchain esasen dağıtılmış bir sistem olduğundan, her bir düğümün operasyon sonuçlarının doğrulanabilir olmasını gerektirir. Geleneksel rastgele sayı üretme çözümleri, farklı makinelerde tutarlı sonuçlar üretmeyecek ve tüm düğümlerin aynı rastgele sayıyı üretmesini sağlayacaktır. Bu nedenle, bu tür sistemler ile aşırı gecikmelere neden olmaması mümkün değildir.
Bir Blockchain ağında kabul edilen rastgele bir sayı üretebilmenin açık yararları vardır. Mevcut birkaç seçenek var:
- Merkezi bir parti rastgele sayılar üretir. Rastgele sayılar, güvenilir bir üçüncü tarafça sağlanır (ör: Random.org).
- Taahhüt yöntemi (hash-commit-reveal yöntemi). AElf Whitepaper’da belirtildiği gibi AElf ana zincir konsensüsü, üretim emrini belirlemek için her bloğun hem in_value hem de out_value değerini belirlemek için kullanılır. Blok üreticisi, yerel olarak rastgele bir karma üretir. Out_value = karma (in_value) olduğu yerde bir in_value özel olarak ayarlandıktan sonra vaadi (yani out_value) açıklanır ve rastgele karma değeri in_value daha sonra uygun bir zamanda yayınlanır. Diğer düğümlerin yalnızca out_value == karma (in_value) doğrulaması gerekir. Buradaki in_value rastgele bir sayı olarak düşünülebilir.
- Blockchain durum bilgilerinin bir tohum olarak toplanması ve sözleşmede belirlenmiş bir algoritma ile rastgele bir sayı oluşturulması. Algoritmanın bilinmesi halinde (akıllı sözleşmenin kodu halka açıktır) ve doğru tohum elde edildiğinde, bu program tarafından oluşturulan rastgele sayı daha sonra başarılı bir şekilde tahmin edilebilir.
Merkezsizleşme perspektifinden bakıldığında Taahhüt yöntemi, yukarıda belirtilen seçeneklerden kullanılabilecek tek çözümdür. Bu durumda asıl endişe, rastgele sayıyı üreten kişinin gizlice önceden ifşa etmemesini veya aldatmak için kullanmamasını sağlayarak giderilebilir.
Ancak maalesef ki Blockchain sisteminde bu garanti edilemez: rastgele sayıyı üreten kişinin, örneğin rastgele sayının kumar olarak kullanıldığı gibi, gizli amaçlar için bilgileri kullanmayacağını garanti edemeyiz. Piyango ayarlandığında rastgele sayının üreticisi, oyun başlamadan önce söz verilmiş olsa bile, rastgele sayının açıklamasını askıya alabilir - bu, “tekrar oynama” fırsatına eşittir çünkü eğer bu düğüm bu rastgele sayıyı açıklamazsa, sistem başka bir düğümden başka bir rastgele sayı seçecek veya kumar geçersiz olacaktır.
Ya stokastik sayı üreticilerinin saldırıyı durdurmayı seçmeleri engellenirse? Bir dizi olgun çözüm vardır, Gizli Paylaşım gibi.
Örnek: Şimdi her biri bir halka açık-özel anahtar çiftine sahip olan A’dan E’ye beş kişi vardır. Bu zamanda A, karşılık gelen taahhüdü üreten rastgele bir sayı Random üretir. Aynı zamanda, rastgele sayı Random dört Paylaşım Parçası elde etmek için B, C, D ve E'nin halka açık anahtar ile şifrelenmiştir. Paylaşım Parçaları şifrelendiğinde, B ~ E'de yalnızca iki kişinin Random’ı kurtarabileceği ve Paylaşma Parçaları ile Taahhüdü bir araya getirebileceği garanti edilir. Bu nedenle, A kendi nedenleriyle Random’ın değerini yayınlamazsa bile, B ~ E’deki herhangi iki kişi kendileri tarafından alınan Paylaşım Parçalarının şifresini kendi özel anahtarlarıyla çözebilir ve iki şifresi çözülmüş değeri derleyebilir (A'ya göre şifrelenebilir). Random sonra geri yüklenebilir. Bir veya iki Paylaşım Parçası Random’ı düzeltemediğinde, onlar sadece A'nın en baştan kötü niyetli davranmaya karar verdiğini varsayabilirler - Bu durumda Blockcahin ekonomik sistemine göre, sadece A cezalandırılır. Örneğin, A’nın başvurusunun doğrudan kesilmesi, rastgele bir sayı üreticisinin ödediği marj olarak ifade edilir.
Ek olarak bir bireyin ürettiği rastgele sayıya güvenmemeyi seçebilir, ancak karma değerini uygulama senaryosunda mevcut rastgele sayı olarak hesaplamak için birden fazla kişinin rastgele sayılarını seçebiliriz. Bu şekilde, daha fazla kararlılık ve güvenlik ile bir Blockchain sisteminde rastgele sayılar elde edebiliriz.
ACS6 - Rastgele Sayı Sağlayıcı Sözleşme Standardı
Bir önceki makalede, konsensüs için AElf Blockchain’in sözleşme standardını açıkladık, bu aslında AElf ana zincir geliştiricisinin sözleşme geliştiricileri için konsensüs mekanizmaları uygulaması için tavsiye edilen arayüzdür. Rastgele sayı üretimi ile ilgili olarak, rastgele sayılar sağlayan herhangi bir sözleşme önerisi için uygulanacak bir arayüz olarak ACS6'yı geliştirdik.
Beklendiği gibi ACS6, Taahhüt şemasını soyutlamayı ve sözleşme standardını almayı seçti.
ACS6 kullanımını destekleyen senaryo aşağıdaki gibidir:
Kullanıcılar, emir göndermeye benzer şekilde ACS6 uygulayan bir sözleşme için rastgele bir numara için başvururlar.
ACS6 sözleşmesi uygulanır ve kullanıcının hangi blok yüksekliğinde (H) rastgele bir sayı alabileceği ve kullanıcının rastgele sayı için alabileceği referans T (ayrıca bir karma değeri) dâhil olmak üzere kullanıcıya bazı bilgiler geri döndürülür.
Blockchain yüksekliğinin H yüksekliğine ulaşmasını bekledikten sonra kullanıcı, işlemi rastgele sayı almaya çalışmak için gönderir ve referans T işlemin parametresi olması gerekir.
ACS6 sözleşmesi, referans T'ye göre rastgele bir sayı döndürür.
Kullanıcı H yüksekliğinden önce rastgele sayı almaya çalışırsa, çağrı yürütme için başarısız olur ve yüksekliğin henüz gelmediğini belirten bir Onay İstisnası alır.
Yukarıdaki senaryoya göre, ACS6'yı aşağıdaki gibi tasarladık:
Kullanıcı rastgele bir sayı için başvuru yapmak için bir RequestRandomNumber işlemi gönderir. Sözleşmenin istek için bir token_hash oluşturması ve ardından tokeni kullanıcıya rastgele sayı elde edebileceği blok yüksekliği ile birlikte kullanıcıya geri döndürmesi gerekir. Yüksekliğe ulaşıldığında kullanıcı, uygun bir rastgele sayı elde etmek için alınan token_hash'ı kullanarak GetRandomNumber işlemini gönderir. Bir sözleşme olarak bu yöntem uygulanırken kullanıcı tarafından oluşturulan referanslar önbelleğe alınmalıdır. Bir haritanın (map) anahtarı olarak haritanın değeri, kendi veri yapısını sözleşmenin rastgele sayıları uygulamasına göre tanımlamalıdır.
Örneğin AEDPoS sözleşmesi ACS6'yı uyguladığında, Haritanın değeri şöyle tanımlanabilir:
Round_number, kullanıcı tarafından uygulanan rastgele sayıyı üretmek için her bir CDC tarafından yayınlanan hangi previous_in_value değerinin kullanılması gerektiğini belirtir. Emir, emirin raundun CDC'si tarafından paketlenen rastgele numara için başvurduğu RandomNumberProviderControl işlemidir (önceki yayınlanan daha sonra turda gereklidir). We_in_value, rastgele sayı üretimi için ham maddedir. Expected_block_height, kullanıcının beklemesi gereken bloğun yüksekliğidir.
ACS6 için AEDPoS sözleşmesinin uygulanması
AEDPoS konsensüsü ilerletme sürecinde benimsenen hash-commit-reveal yaklaşımı nedeniyle her bir CDC için sıradan blokların (ekstra bloklardan farklı olarak) üretilmesi sırasında yayınlanan previous_in_value değeri, doğrudan rastgele sayılar üretmek için ham madde olarak kullanılabilir. Herhangi bir düğüm yeni bir blok yürütmeden önce, yeni yayınlanmış prior_in_value doğrulaması (yani doğrulama karması (hash) (previous_in_value) == previous_out_value) gerçekleşir. Blok en iyi zincirle başarılı bir şekilde senkronize edildiği sürece, yayınlanan previous_in_value öğesinin hileli davranışı konusunda endişelenmeye gerek yoktur.
Bu bölümün uygulanmasının yalnızca ACS6'nın tanımının tamamlanmasından kısa bir süre sonraki bir girişim olduğunu ve bundan sonra herhangi bir zamanda önemli değişiklikler olabileceğini unutmayınız.
Tek endişe, CDC komplosudur. Bu nedenle AEDPoS rastgele sayı üretmeyi uyguladığında, rastgele sayı üretmek için yalnızca bir CDC’nin previous_in_value değerini kullanmaz aynı zamanda beşli kümeler kullanır:
Bir kullanıcı AEDPoS'dan rastgele bir sayı talep ettiğinde, geçerli raundun yayınlanabilir previous_in_value değerinin yayınlandığından emin olmak için yalnızca geçerli raundun son dilimine (ekstra blok dilimi) kadar bekleyebilir. Bu raunda yeni eklenmiş bir CDC varsa (belki az önce çatallaşmayı çözdüler), yayınlayacak bir previous_in_value sahip olmayacaklar veya yerel önbelleğe alma sorunları nedeniyle previous_in_value yayınlayamamış olabilirler. İlave blokların dilimine gelince previous_in_value değerleri, gizli paylaşımın ortaya çıkarma aşamasını tamamlar. Restore edildi - Eğer kullanıcıların rastgele sayılar almak için ortaya çıkarma aşamasından önce GetRandomNumber işlemlerini göndermelerine izin verirsek, ortaya çıkarma evresinden önce ve sonra elde edilen rastgele sayılar ciddi sorunlara neden olabilecek kadar tutarsız olabilir.
Kullanıcılar referanslarıyla rastgele sayılar almaya çalıştığında AEDPoS, kullanıcılar rastgele sayılar için başvurduktan sonra CDC'ler tarafından yayınlanan beş previous_in_values değeri toplar, bu beş karma ile bir karma değerini hesaplar ve bunları kullanıcılara rastgele bir sayı olarak geri döndürür.
Daha sonra, bu iki yönteme BVT test durumları eklenmiştir (AElf sözleşmelerinin test edilmesi için bir yapı vardır). Bir kod üreteci, bir sözleşme yöntemi çağırabilecek bir Stub oluşturmak için kullanılabilir. Stub, kullanıcı tarafından gönderilen işlemleri bir Blockchain’de simüle edebilir ve her işlem ayrı olarak bir bloğa paketlenir.
Zincirin başında simüle edilmiş herhangi bir kullanıcının Stub’ı, uygun bir RandomNumberOrder elde edip edemediğini kontrol etmek için RequestRandomNumber işlemini gönderir. Gerekli sözleşmeler test durumu yürütülmeden önce çok sayıda işlem aracılığıyla (şu anda 19) dağıtıldığından RequestRandomNumber yürütüldüğünde blok yüksekliği 20'ye ulaştı.
Belli bir yükseklikten (bir round süresi) sonra simüle edilen kullanıcı, rastgele sayıyı almak için GetRandomNumber işlemini gönderir. Sonraki test durumları normal blok işlemi için CDC’nin ilk raundunu simüle eder ve ayrıca ExpectedBlockHeight'tan önce ve sonra GetRandomNumber’ı göndermeyi dener. Yüksekliğe ulaşılmadığında, işlem yürütme başarısız olur ve “Rastgele(random) sayı hâlâ hazırlanıyor” hata mesajı ortaya çıkar. İkinci GetRandomNumber gönderildiğinde, işlem yürütme başarılı olur ve kullanılabilir rastgele sayı döndürülür; ve üçüncü GetRandomNumber, rastgele sayı hakkındaki bilgiler AEDPoS sözleşmesi tarafından silindiği için gönderilir (boşluk mekanizması tasarrufu), böylece boş bir karma (hash) değeri döndürür.
KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-generating-a-random-number-on-blockchain-securely-acs6-37e355522c72