Ergo ve Autolykos Konsensüs Mekanizması: Bölüm II

Geçen hafta, Ergo’nun Autolykos konsensüs mekanizmasının derinlemesine bir incelemesini tanıttık. Bu makaleyle, o tartışmanın ikinci bölümünü tamamlıyor ve daha fazla detaya dalıyoruz. Bu belgeyi okumadan önce, okuyucuların Bölüm I'e göz atması önerilir.

Hatırlatmak gerekirse, işte blok madenciliği ve hash fonksiyonu için psödo kodlar.

Autolykos Blok Madenciliği Psödo Kodu

Blake2b256 Tabanlı Hash Fonksiyonu

Satırlar 3, 4 – döngü başlat ve tahmin et

list R hesaplandıktan sonra, madenci bir nonce tahmini oluşturur ve nonce'un nihayetinde verilen hedef değerin altında bir çıktı oluşturup oluşturmadığını test etmek için bir döngüye girer.

Satırlar 5, 6 – indeksleri oluşturmak için tohum

Satır 5, i = takeRight(8, H(m||nonce)) mod N, [0,N) aralığında bir tam sayı üretir. Algoritma 3 kullanılır ancak m ve nonce girdi olarak alınır. H(m||nonce) hash'i döndüğünde, en az anlamlı 8 byte saklanır ve ardından mod N üzerinden geçer. Bir yan not olarak, 8 byte ile en yüksek olası tam sayı değeri 2⁶⁴ – 1'dir ve N = 2²⁶ varsayılırsa, 8 byte'lık bir hash mod N ilk birkaç basamağın sıfır olmasına neden olacaktır. i içindeki sıfır sayısı N büyüdükçe azalır.

Satır 6, indeks oluşturma için bir tohum olan e'yi üretir. Algoritma 3, i (satır 5'te üretilen), h ve M girdileri ile çağrılır. Ardından, sayısal hash'in en anlamlı byte'ı atılır ve kalan 31 byte e değeri olarak saklanır. Ayrıca, e değerinin hesaplanmak yerine list R'den alınabileceği de belirtilmelidir çünkü e bir r değeridir.

Satır 7 – indeks oluşturucu

Element indeksi J, e, m, ve nonce girdileri ile Algoritma 6 kullanılarak oluşturulur. genIndexes fonksiyonu, [0,N) aralığında k (=32) sayılar döndüren psödo rastgele bir yoldur.

genIndexes fonksiyonu

Psödo kodda gösterilmeyen birkaç ek adım vardır, örneğin bir byte değişimi. genIndexes'in oluşturulması ve uygulanması aşağıdaki örnekle açıklanabilir:

GenIndexes(e||m||nonce)...

hash = Blake2b256(e||m||nonce) = [0xF963BAA1C0E8BF86, 0x317C0AFBA91C1F23, 0x56EC115FD3E46D89, 0x9817644ECA58EBFB]

hash64to32 = [0xC0E8BF86, 0xF963BAA1, 0xA91C1F23, 0x317C0AFB, 0xD3E46D89 0x56EC115F, 0xCA58EBFB, 0x9817644E]

extendedhash (yani, byte değişimi ve ilk 4 byte'ı tekrarlayarak 4 byte birleştirme) = [0x86BFE8C0, 0xA1BA63F9, 0x231F1CA9, 0xFB0A7C31, 0x896DE4D3, 0x5F11EC56, 0xFBEB58CA, 0x4E641798, 0x86BFE8C0]

Aşağıdaki python kodu, genişletilmiş hash'in dilimlenmesi sürecini gösterir ve k indekslerini döndürür. Bu örnekte h < 614,400 varsayıyoruz, dolayısıyla N = 2²⁶ (67,108,864).

Dilimleme ve mod N[1]
for i in range(8):
idxs[i << 2] = r[i] % np.uint32(ItemCount)
idxs[(i << 2) + 1] = ((r[i] << np.uint32(8)) | (r[i + 1] >> np.uint32(24))) % np.uint32(ItemCount)
idxs[(i << 2) + 2] = ((r[i] << np.uint32(16)) | (r[i + 1] >> np.uint32(16))) % np.uint32(ItemCount)
idxs[(i << 2) + 3] = ((r[i] << np.uint32(24)) | (r[i + 1] >> np.uint32(8))) % np.uint32(ItemCount)

Ana çıkarım, dilimlemenin k indekslerini döndürmesidir; bu indeksler, tohumdan türetilen psödo rastgele değerlerdir, yani e, m, ve nonce.

return [0x2BFE8C0, 0x3E8C0A1, 0xC0A1BA, 0xA1BA63, 0x1BA63F9, 0x263F923, 0x3F9231F, 0x1231F1C, 0x31F1CA9, 0x31CA9FB, 0xA9FB0A, 0x1FB0A7C, 0x30A7C31, 0x27C3189, 0x31896D, 0x1896DE4, 0x16DE4D3, 0x1E4D35F, 0xD35F11, 0x35F11EC, 0x311EC56, 0x1EC56FB, 0x56FBEB, 0x2FBEB58, 0x3EB58CA, 0x358CA4E, 0xCA4E64, 0x24E6417, 0x2641798, 0x179886, 0x39886BF, 0x86BFE8]

Bu indeks, [0, N) aralığında sayılara karşılık geldiği için ondalık tabanda değerlere dönüştürülebilir. Örneğin, 0x2BFE8C0 = 46131392, 0x3E8C0A1 = 65585313, 0xC0A1BA = 12624314, vb. Madenci bu indeksleri kullanarak k r değerlerini alır.

genIndexes fonksiyonu optimizasyonları engeller çünkü istenen indeksleri döndüren bir tohum bulmak son derece zor, temelde imkansızdır.

Satır 8 – k verilen r elemanlarının toplamı

_Satır 7'de üretilen indeksi kullanarak, madenci list R'den karşılık gelen k (=32) r değerlerini alır ve bu değerleri toplar. Bu kafa karıştırıcı gelebilir ama bunu parçalayalım.

Yukarıdaki örneği devam ettirerek, madenci aşağıdaki indeksleri saklar:

{0 | 46,131,392},
{1 | 65,585,313},
{2 | 12,624,314},
{3 | 10,599,011},
…
{31 | 8,830,952}

Yukarıdaki indeksler verildiğinde, madenci bellekde saklanan list R'den aşağıdaki r değerlerini alır.

{0 | 46,131,392} → dropMsb(H(46,131,392||h||M))
{1 | 65,585,313} → dropMsb(H(65,585,313||h||M))
{2 | 12,624,314} → dropMsb(H(12,624,314||h||M))
{3 | 10,599,011} → dropMsb(H(10,599,011||h||M))
…
{31 | 8,830,952} → dropMsb(H(8,830,952||h||M))

_Not edin ki, 32 byte'lık bir hash üzerinde Takeright(31) işlemi de dropMsb olarak yazılabilir – en anlamlı byte'ı at.

Madenci zaten list R'yi RAM'de sakladığı için, madenci k (= 32) Blake2b256 fonksiyonunu hesaplamak zorunda kalmaz ve bunun yerine değerleri arar. Bu, ASIC direncinin ana özelliğidir. Sınırlı belleğe sahip bir ASIC, değerleri bellekde aramak yerine 32 Blake2b256 iterasyonu hesaplamak zorundadır ve bellekden almak çok daha az zaman alır. Ayrıca, sınırlı belleğe sahip bir ASIC, her döngüde bir hash elde etmek için fiziksel olarak 32 Blake2b256 örneğine ihtiyaç duyar ki bu da daha fazla alan ve daha yüksek maliyetler gerektirir. list R'yi bellekde saklamanın faydalı olduğunu kanıtlamak basittir. Aşağıdaki varsayımları yapalım, bir GPU'nun hash oranı G = 100MH/s, _N = 2²⁶, k = 32, blok aralığı t = 120 saniye ve elemanlar her 4 hash'de bir aranır. Her nonce tahmini için, i, J, ve H(f) gibi birden fazla elemanın Algoritma 3, yani blake2b hash, örneklerine ihtiyaç duyduğunu varsayıyorum. Her r değerinin ortalama olarak, (G * k * t)/(N*4) = 1430.51 kez kullanılacağını tahmin edebiliriz.

32 r değeri alındıktan sonra, bunlar toplanır.

Satır 9, 10, 11, 12 – toplamın hash'inin hedefin altında olup olmadığını kontrol et

32 r değerinin toplamı Algoritma 3 kullanılarak hash'lenir ve çıktı hedef b'nin altında ise, PoW başarılıdır, m ve nonce ağ düğümlerine döner ve madenci ERG ile ödüllendirilir. Eğer toplam hash hedefin üzerindeyse, Satırlar 4 – 11 yeni bir nonce ile tekrarlanır.

Bu noktaya kadar geldiyseniz, tebrikler! Tüm bu bilgileri okuduktan sonra, Autolykos v2'yi iyi bir şekilde anlamış olmalısınız! Autolykos'un görsel bir gösterimini görmek isterseniz, lütfen bu belgenin sonunda yer alan grafiğe bakın. Bir video açıklaması isterseniz, onu buradan bulabilirsiniz.

ASIC Direnci

Ethereum'dan bildiğimiz gibi, 'bellek zor' algoritmalar, ASIC'lerde bellek entegre edilerek fethedilebilir. Ergo farklıdır ama önce sınırlı belleğe sahip bir ASIC'in neden rekabetçi olmadığını ve bir madencinin neden list R'yi saklaması gerektiğini gözden geçirelim. Autolykos blok madenciliğinin 8. satırı, sınırlı belleğe sahip makineleri caydırır. Eğer bir ASIC madencisi list R'yi saklamazsa, 31 byte'lık sayısal hash'leri anında oluşturmak için çok sayıda çekirdek gerektirir. 32 r değeri, tek bir çekirdek döngüsü kullanılarak verimli bir şekilde hesaplanamaz çünkü bir çıktı yalnızca her 32. hash döngüsünde üretilir. J verildiğinde, bir nonce'u her hash döngüsünde hesaplamak için en az 32 Blake2b256 örneği çalıştırarak dropMsb(H(j||h||M)) gereklidir. Yukarıda belirttiğimiz gibi, bu die boyutunu ve maliyetini önemli ölçüde artırır. list R'yi saklamanın faydalı olduğu açıktır çünkü 32 veya hatta 16 çekirdeğe sahip olmak çok pahalıdır. Daha da önemlisi, belleği okumak, her nonce test edildiğinde Blake örneklerini hesaplamaktan daha hızlıdır.

Yeterli belleğe sahip bir ASIC'in rekabetçi olup olmadığını görelim çünkü bu tartışma için daha ilgili. Ethash ve Autolykos'u karşılaştırdığımızda, fark, Ethash'ın nonce'u hash'lerken N elemanını içermesi ve başlık karışımlarını 64 kez yapmasıdır, oysa Autolykos, üretilen indekslere dayalı olarak 32 r değerini alırken N elemanını içerir. Her test edilen nonce için, Autolykos yaklaşık 4 Blake2b256 örneği ve 32 bellek alımı çalıştırırken, Ethash yaklaşık 65 SHA-3 benzeri örnek ve 64 bellek alımı çalıştırır. Ayrıca, k şu anda 32 olarak ayarlanmıştır ancak bu değer, daha fazla r değeri almak için artırılabilir. Ethash'ı çalıştıran ASIC'lerin SHA3 hash hızını artırmak için çok fazla alanı vardır çünkü her test edilen nonce için 65 hash tamamlanırken, Autolykos'ta yaklaşık 4 hash tamamlanır. Bellek alımları ile hash örnekleri arasındaki oran Autolykos'ta çok daha büyüktür. Bu nedenle, Autolykos, bellek bant genişliğinin hash hızına göre çok daha büyük bir rol oynadığı için Ethash'tan daha bellek zor bir algoritmadır.

Autolykos optimizasyonunun gerçekleşebileceği bir alan, list R'nin doldurulmasıdır. list R'nin doldurulması, bir Blake2b256 fonksiyonunun N örneğini gerektirir. N büyük ve giderek büyüdüğü için, bu çok fazla hash'leme demektir. Bir ASIC, Blake2b256 hızını optimize edebilir, böylece list R daha hızlı doldurulur ve blok madenciliği için daha fazla zaman kazanılır. Bunu yapmak mümkün olsa da, list R'yi doldurmak [0, N) aralığında döngü yapmayı gerektirir ve 32 geniş çoklu işlemcili bir GPU, list R'yi zaten çok hızlı bir şekilde (saniyeler içinde) doldurabilir. Önemli ölçüde daha hızlı olmak için birçok Blake çekirdeğine sahip bir ASIC'e ihtiyaç vardır – bu da yine çok pahalıdır ve muhtemelen değmez çünkü darboğaz bellek yazma bant genişliği (yani, list R'yi RAM'e yazmak yerine hash hızıdır) haline gelebilir.

Autolykos için optimize edilebilecek son alan, bellek okuma/yazma hızıdır. Ethash ASIC madencileri, GPU'lara kıyasla hafifçe daha hızlı okuma hızına sahiptir çünkü bellek daha yüksek saat hızında çalışır ve GPU kısıtlamasından etkilenmez. Ancak, bu fark oldukça önemsizdir ve GPU'lar ilerledikçe daha da önemsiz hale gelmesi beklenmektedir. Bunun nedeni, bellek donanımının kendisinin aynı olmasıdır: DRAM. Daha hızlı bir bellek donanımının kullanılıp kullanılamayacağı sorgulanabilir; bellek okuma ve yazma hızı çok daha hızlıdır… SRAM, örneğin, bellek zor algoritmalarını kırmak için hayal edilebilir bir sonraki adım olabilir, ancak SRAM, daha az yoğun olduğu için uygulanabilir bir çözüm değildir.

FPGA'daki SRAM[2]

Yukarıdaki fotoğraf, önünde 8 bellek çipi bulunan bir FPGA'dır ve arkasında başka 8 çip bulunmaktadır. Toplam SRAM bellek yalnızca 576MB'dır. Bir die üzerine yeterli SRAM yerleştirmek işe yaramayacaktır çünkü SRAM, çekirdek etrafında bir katmana sığacak kadar yoğun değildir. Bu, okuma/yazma gecikmelerine neden olabilir çünkü elektrik daha uzun mesafeler kat etmek zorundadır, oysa donanım kendisi daha hızlıdır. Ayrıca, Ergo madenciliği yapmak için bellek gereksinimi N arttıkça artar, bu nedenle yeterli SRAM yerleştirmek zamanla mümkün değildir. Bu nedenle, SRAM ASIC'leri keşfetmek, SRAM'a harcayacak yeterli nakit olsa bile, faydalı değildir.

Blake2b256

Autolykos gibi bir algoritma ile diğerleri arasındaki büyük bir fark, Blake2b256'nın kullanılmasıdır. Bu bir tesadüf değildir. Blake, hash karıştırma için XOR işlemleri yerine toplama işlemlerine büyük ölçüde dayanır. XOR gibi bir işlem bit bit yapılabilirken, toplama carry bitleri gerektirir. Bu nedenle, Blake, SHA algoritmalarına kıyasla daha fazla güç ve çekirdek alanı gerektirir, ancak yine de güvenli ve aslında daha hızlıdır. Blake2 web sitesinde belirtildiği gibi, “BLAKE2, modern CPU'ların özelliklerinden yararlandığı için yazılımda hızlıdır, yani talimat düzeyinde paralellik, SIMD talimat seti uzantıları ve çoklu çekirdekler.”[3] Bu nedenle, bir ASIC Blake örneklerini daha hızlı çıkarsa da, fonksiyonun doğası, toplama gerektirdiği ve CPU'larda ve GPU'larda bulunan özellikleri içerdiği için optimizasyonları sınırlar.

Blake2b'nin diğer hash fonksiyonlarına göre hızı

Sonuç

Autolykos, PoW optimize edilmiş ASIC makinelerinin yükselişine karşı koymak için gerekli bir yanıt olan harika bir yeniliktir. Bu 2 bölümlük serinin, Autolykos'u daha teknik bir düzeyde anlamanıza ve neden Ethash'tan daha bellek zor olduğunu anlamanıza yardımcı olduğunu umuyoruz. Ethereum, PoS ağına geçerken, hashrate gücünü yönlendirmek isteyen büyük bir madenci topluluğu olacak ve Ergo, bu madencileri çekmede önemli bir oyuncu olmalıdır.

Bu makaleyi beğendiyseniz, yazar sizi Twitter hesabı üzerinden daha fazla içerik kontrol etmeye davet ediyor, @TheMiningApple.

[1] Discord'da Wolf9466#9466'ya kredi
[2] http://www.ldatech.com/_images/imageGallery/SBM09P-3_front.jpg
[3] https://www.blake2.net/#:~:text=A%3A%20BLAKE2%20is%20fast%20in,of%20the%20designers%20of%20BLAKE2).