Thread by @OrientusPrime

0)Block Hash'lerini Randomness kaynağı olarak kullanma fikri yeni değil. Hatta ilk akla gelen fikir denebilir. Burda Hash'i mevcut block değil de bir sonraki block'un Hash'i olarak kullanmak sadece non-miner aktörler için önleyici bir tedbir.

https://twitter.com/yasinaktimur/status/1498213689358487555

1)Fakat biz minerların nötral aktörler olmadığını biliyoruz. Eğer kendilerine avantaj sağlayacak bir durum olursa bunu değerlendiriyorlar. Buna da MEV diyoruz. Bir sonraki block'un Hash numarasını kullanmak neden güvenli değil?Çünkü block'u üreten Hash değerini manipüle edebilir.

2)Bazı zincirler değiştirilmesi zor Randomness üretiyor. Örneğin Polkadot'da VRF çalıştırılıyor fakat bunun Gambling için kullanılmasını önermiyorlar. Kendi işleyiş mekanızmaları için yeterli bir Randomness kullanıyorlar fakat Gambling için yeterli değil.

3)Validator'ler tamamen belirleyemeseler de şanslarını arttıracak hareketler yapabiliyorlar. Bir yazı turada şansını %50'den %50.1'e çıkarman yeterli. Uzun vadede bu çok büyük bir kazanca dönüşecektir. Blockchain'de block üretim zamanı için ise önemli bir fark değildir.

4)Gnosis Chain'de ise Randao kullanılıyor. Fakat Randao'da da Validator cevap vermek için kendini sona bırakıp duruma göre ölü taklidi yapmayı seçebilir. Sık ölü taklidi yaparsa ceza alıyor fakat burdaki gibi bir oyunda 1-2 kere yapması yeterli. Parametreler yine yeterli değil.

5)Diğer alternatif BLS signature'larla TSS oluşturmak. Burda bir kişinin ölü taklidi yapması sonucu değiştirmeye yetmiyor. Oranı kendin belirliyorsun fakat genelde 1/3'den az ise katılmayanlar kalan +2/3 random sayıyı üretebilecek şekilde belirleniyor. 1/3'den fazlaysa duruyor.

6)Yeni Chainlink VRF de bu yapıyı kullanıyor. Bu TSS'i üreten Chainlink Node'larının hepsi ortak hareket ediyorsa yine sorunlar çıkabilir tabii ki. Fakat Chainlink Node'larının Validator'ler gibi kendini saklama şansı yok.Validator'lerin aksine tarafısız olma taahhütleri de var.

7)Bu şekildeki bir TSS'in tamamını kontrol ediyorsan vereceğin inputların sonuçlarını önceden hesaplayabilirsin. Input'u koy TSS ile imzala sonuca bak. Başka Input koy yine hesapla. Hangisi işine geliyorsa onu Blockchain'e yolla. Bu sebeple belli bir güven gerektiriyor yine.

8)Biz bu kadar da güvenmek istemiyoruz diyelim. O zaman çözüm VDF. VDF'i daha önce anlatmıştım. Solana'daki POH da benzer bir yapı kullanıyordu. VDF bir fonksiyon. Özelliği şu ki donanımın çok güçlü de olsa sonucunu belirli bir süreden önce hesaplayamıyorsun.

9)Bir sonraki Block'un Hash'ini random sayı için kullanacağız diyelim. Bu Block'u kazacak Validator elindeki Hash alternatiflerinin neye yol açabileceğini hemen görebiliyor. Bu sebeple kendi işine gelen Hash ile bu Block'u kazabilir.

10)Bunun yerine dedik ki sonraki Block da değil. Bu Block'un Hash'ini kullancağız. Hani Hash manipüle edilebiliyordu niye kullanıyoruz? Bu Hash manipüle edilebilse de tamamen seçilemiyor. Bu da bizim için yeterli. Sonra dedik ki bu Hash'i VDF fonksiyonuna input olarak vereceğiz.

11)VDF fonksiyonunun en az 30 dakika sürmesini de istiyoruz. Onu da belirttik.

VDF(Hash,30dk)

Şimdi Validator'ün Hash değerini seçme şansı yok. Çünkü seçtiği Hash değerinin sonucunu 30 dakikadan önce anlayamıyor.

12)Seçim yapmak için Zinciri 30 dakika boyunca durduramayacağını farzediyoruz tabiki. İsterseniz daha büyük bir değer de seçebilirsiniz. Biz bu Delay Function'u koyduk da doğruluğunu nasıl anlayacağız? Herkese bu fonksiyonu mu çalıştırtacağız?

13)Hayır tabiki çünkü bu fonksiyon Verifiable. Zaten biz ZK SNARK/STARK'lar ile herhangi bir hesaplamanın ufak kanıtını üretebileceğimizi biliyoruz. Yani bir kişi hesapladığı zaman biz bunu kolayca doğrulayabiliriz. Uygulamanın creatorları bir tane VDF çalıştırsa yeterli.

14)Çok tembeliz onu da yapmak istemiyoruz. VDF makinası ayağınıza geldi.

Karşınızda Starknet Veedo

15)Starknet VeeDo tam da anlattığım gibi çalışıyor. Block Hash'ini alıyor. Delay Function'u çalıştırıyor. Sonra bunun STARK proof'unu oluşturuyor. Bunu doğruladığında elinde sağlam bir Random sayı oluyor.

16)Bu yöntem için input'un bir miktar biasable olması çok önemli değil demiştik. Bu sebeple Block Hash kullanmak çok sıkıntı olmadı. Fakat biz Validator'lerin çoğunluğunun ortak hareket ederek zinciri manipüle etmesini de istemiyoruz.

17)30 dakika arkada zincir oluşturup sonra eklemek zor bir olay fakat mükemmelliyetçiyiz. O zaman bir diğer Biasable kaynak neydi? RANDAO. Evet RANDAO'nun çıktısının üstüne VDF uygulayarak bu varsayımı da kenara atabiliriz.

18)Ethereum planlarında da zincirde Validator atamaları için gerekli Random'luk kaynağı olarak RANDAO + VDF planlanıyordu fakat Ethereum'un sorunu da bu. Denizi geçebilecekken okyanusta boğulmayı seçiyorlar.

19)İflah olmaz bir Randomness hastasıysanız RANDAO kontratlarını kendiniz yazıp sonra Starknet'te üzerinde VDF hesaplatabilirsiniz. Ben VDF'in standart kullanımına da çok rastlamadım o ayrı konu.

20)Şimdi denebilir ki altı üstü rastgele bir yeşil bir kırmızı NFT üretecektik nerelere girdin. Bu tarz ufak yazı tura stili bir oyun için çok daha kolay Unbiased Randomness üretimi mümkün. Fakat bunu anlatmamın Dünya'ya bir faydası olacağını sanmıyorum.

21)Benim anlattıklarım da kumarda kullanılabilecek şeyler ama Blockchain'lerin işleyişindeki faydalı kullanımlarına odaklanmak da mümkün.

Başlangıç noktasına dönersek BlockHash'i direkt kullanarak oluşturulan Random'luk güvenli değildir. İçindeki miktar büyürse hedef olur.