Geçmişten Geleceğe Ethereum

Merge, Rollup, Data Availability, Zero Knowledge, WEB3, Metaverse, NFT, DEFI, DEX, DAO, Bridge, Oracle, Privacy, Censorship…

Konumuz bütün bu şeylerin merkezindeki protokol

ETHEREUM

Her şey, her zaman olduğu gibi Bitcoin ile başladı. Nedir Bitcoin?

A Peer-to-Peer Electronic Cash System

İsminden de anlaşılacağı gibi bir ödeme sistemi. Blockchain, madencilik, merkeziyetsizlik, sansür dayanıklığı ve daha fazlası var, fakat günün sonunda, bir ödeme sistemi. Bu bize yeter mi? Yetmez. Çünkü elimizde interneti tamamen değiştirebilecek bir potansiyel mevcut.

Bitcoin pandoranın kutusunu açtı. İnsanlar artık finansal etkileşimlerin p2p bir ortamda mümkün kılınmasından faydalanmak istiyordu. Akla ilk gelen isteklerden biri de kendi coinlerini oluşturmaktı. Bitcoin temsil edilebiliyorsa başka şeyler de bu sistemde temsil edilebilirdi.

Bu durumun ortaya çıkardığı çözüm Colored Coins oldu. Bitcoin’de kısıtlı da olsa bir programlanabilirlik vardı fakat Colored Coin ile kendi Coinini çıkarman dahi Bitcoin’in yeteneklerini aşan bir durumdu. İnsanlar bu fonksiyonalitelerin çalışma şekli üzerinde, Bitcoin protokolünden bağımsız bir şekilde anlaşıyordu. Bir varlığı zincir üzerinde oluşturmak için o varlığı temsil edecek bir UTXO belirleniyordu. Diyelim 1 Bitcoin büyüklüğünde bir UTXO’yi seçtik. İçindeki her bir Sats da bir adet belirlediğimiz tokeni temsil ediyor. Bitcoin protokolü açısından bu UTXO’dan budaklanacak UTXO’lar sıradan Bitcoin transferleri, kullanıcılar açısından bakıldığında ise başka bir varlığın transferini temsil ediyorlar.

Burda insanlar şunu farketti, Bitcoin’in üzerine yazdıkları verilerin nasıl yorumlanacağı noktasında aslında bir limit yoktu. Bitcoin’in yeteneklerine bağlı kalmak zorunda değillerdi. 2012 yılının başında J. R. Willett bu yaklaşımı daha da genelleştirerek bir paper oluşturdu. Başlığına da şunu yazdı:

The Second Bitcoin Paper

Paper’ın temelini oluşturan temel görüşe göre Bitcoin protokolü diğer protokoller için taban olmalı. Diğer protokoller ise Bitcoin protokolünün üzerinde ek katmanlar olarak kurgulanmalılar, alternatif blockchainler oluşturarak Bitcoin ile finansal bir rekabete girmemeliler.

Eminim ki bu görüşler size epey tanıdık gelmiştir. Willett’in bu yazısı Consensus+Data katmanı olarak Bitcoin’i kullanırken, Execution kısmını üstünde çalışacak protokollere bırakmaktan bahsetmektedir. Celestia’da bahsettiğimiz Sovereign Rollup’ların atası denebilir. O zamanlar bu şekilde çalışan sistemlere Meta Protocol deniyordu.

Bitcoin’e gönderilen veriler Bitcoin kullanıcıları için tamamen anlamsız bilgiler iken, protokolü kullanan kullanıcıların clientleri gözünde anlamlı bir protokole dönüşüyor.

Willett bu dizayn ile kurulacak ilk gelişmiş yapıya Mastercoin ismini vermişti. Mastercoin’in önemli fonksiyonları kolayca token oluşturmak, şartlı transferler yapabilmek, DEX, Oracle sistemi ve Sentetik Tokenler gibi temel mekanızmalardı. En çok kullanılan özelliği ise token oluşturmak oldu denebilir çünkü MasterCoin’in en büyük kullanımı üzerinde çıkan Tether(USDT) ile oldu. Tether crypto sahnesine 2014 yılında MasterCoin üzerinde bir token olarak çıkmıştır. MasterCoin’in isminin sonradan Omni olduğunu da belirtirsem bağlantı kurabilenlerin sayısı artacaktır.

MasterCoin aynı zamanda token dağıtımı konusunda da tarihi bir yere sahip çünkü yapılan ilk ICO’dur. Paylaşılan Bitcoin adresine transfer yapan kullanıcılar gönderdikleri miktara ve zamana göre karşılığında MasterCoin kazandılar. Diğer bir deyişle Bitcoin ve dağıtımını sadece madencilik yoluyla yapan diğer projelerden farklı olarak bir Premine söz konusuydu. Bu da Bitcoin topluluğu tarafından pek hoş görülmüyordu.

O zamanlar Bitcoin topluluğu adına bu hoşnutsuzluğu Bitcoin Magazine’de yayınladığı yazı ile belirtenlerden biri de Vitalik Buterin’di. Vitalik’e göre Mastercoin Foundation’ın bu satıştan çıkar sağlaması ona ayrıcalıklı bir statü veriyordu ve bu merkeziyetsizlik ile bağdaşmayan bir durumdu. MasterCoin’in bu metodu bırakması gerekiyordu. Ne demişler:

Fate loves irony

Bu tarz eleştirilerine rağmen Vitalik’in MasterCoin hakkında yazı yazması aslında sisteme duyduğu ilgiyi gösteriyordu. MasterCoin’i yakından takip ediyordu. MasterCoin’in enteresan özellikleri vardı ve yeni özellikler getirmek için de ekip çalışmaya devam ediyordu. Vitalik ise biraz daha serbest bir yaklaşımın olması gerektiğini düşünüyordu. Bitcoin’in Forth yazılım diline benzer bir Script ile çalışan Stack tabanlı bir programlama altyapısı vardı(zamanla yetenekleri giderek kısıtlandı), Mastercoin’de de benzer bir şey yapılabilir ve üzerinde yapılabilecekler konusunda geliştiricilere daha fazla serbest alan sağlanabilirdi. Vitalik bunu yazıya dökerek MasterCoin geliştiricilerine öneri olarak sundu.

Ultimate Scripting: A Platform for Generalized Financial Contracts on Mastercoin

Burdaki programlanabilirlik 2 taraf arası etkileşimleri kapsayan kısıtlı bir programlanabilirlikti. Örneklerde bahis ve yazı tura gibi 2 kişi arası etkileşimler yer alıyordu. MasterCoin ekibi ise öneriyi değerli bulsa da geliştirmeler konusunda daha muhafazakar şekilde ilerlemek istediklerini söyleyerek bu öneriyi red etti. Bunun üzerine Vitalik kendi Meta Protocol’ünü yapmaya karar verdi. Programlama modelini geliştirip programların kendisini de birer hesap haline getirdi. Daha cool gözüktüğü için Stack tabanlı yerine Register tabanlı bir programlama yapısına geçti(sonraki zamanlarda tekrar stack tabanlı yapıya dönecek). Protokol ise Bitcoin üzerinde değil başka bir bağımsız blockchain olan PrimeCoin üzerinde çalışacaktı.

Vitalik MasterCoin hakkında yazdığı yazıda bu yapıyı da eleştiriyordu aslında. Light Client dostu bir dizayn olmadığını söylüyordu. Peki buna rağmen bağımsız bir blockchain oluşturmak yerine neden bu yapıyı kullanmaya karar vermişti? Çünkü bağımsız bir Blockchain yazabilecek yetenekte bir programlama becerisine sahip değildi. Bu durum ise Gavin Wood’un Vitalik’e attığı mesaj ile değişti. Vitalik’in fikrini paylaştığı arkadaşlarından Johhny Bitcoin, Gavin Wood’a projeden bahsetmişti. Proje ilgisini çeken Gavin de Vitalik’e mail ile ulaşmıştı.

Böylece bağımsız bir blockchain olarak devam etmemeleri için bir sebep kalmamıştı. Vitalik ve Gavin script yapısını konuşarak ilerletirken bazı şeyler de Gavin’in bunları koda dökmesiyle şekilleniyordu. Transaction yapıları, GAS sistemi ve VM’e dair diğer şeyler bu şekilde ilerletildi. Gavin’in Ethereum’a getirdiği bir diğer şey de WEB3 yaklaşımı idi. Finansal anlaşmalar çerçevesinde ilerleyen sisteme Gavin WEB’in geleceği olarak bakıyordu.

Merkeziyetsiz uygulama - DAPP konsepti için Ethereum akıllı kontrat altyapısını sunarken, bunun üzerine dosya depolama vs mesajlaşma katmanları da ekleyip bu 3 üne erişimi sağlayacak bir tarayıcı yazılımı ile de insanlara durdurulamaz bir WEB deneyimi yaşatmak istiyordu. Malesef gerçekleşmedi. Sadece akıllı kontrat tarafı bugün aktif bir geliştirme görüyor. Fakat en azından bu süreçte akıllı kontrat katmanı başlangıçtaki yapısına kıyasla daha genel bir hesaplama altyapısına ulaştı. Bu yaklaşımın yansımasını bir dönem Ethereum’u tanımlamak için kullandıkları “World Computer” tanımında da görebiliriz.

Biz de projenin temel yapısına yani akıllı kontrat altyapısına tekrar dönersek, Gavin Ethereum’un ilk çalışır concepti olan POC-1'in kodlarını tamamladı. Hem dizayn hem kodlama tarafında olarak Ethereum’un yapısına en hakim kişi olarak, Ethereum’un specification’ını da ilk defa yaptı. Böylece Ethereum Yellow Paper ortaya çıkmış oldu.

Precompile dediğimiz EVM dışında çalışan kontratların getirilmesinde ve diğer bir çok noktada Gavin’in ciddi etkileri olmaya devam etti. Ethereum için Gavin’in dahil olması çok önemli bir dönüm noktasıdır. Kontrat geliştirilmesi için oluşturduğu Solidity de Serpent, LLL, Mutan gibi dilleri silip atarak akıllı kontrat geliştirmesi için ilk akla gelen dil olmuştur.

Jeffrey Wilcke’in katılması da benzer bir etki yapmadı mı diye sorulabilir. O da iyi bir geliştiriciydi ve Gavin’in C++ ile yazdığı versiyona benzer olarak o da Go clientini yazıyordu. Fark şu, Gavin hem projenin geleceğine ve dizaynına dair önemli katkılar sunarken hem de kodlanması tarafında öncülük ediyordu. Jeffrey dizayna dair fikir belirtmekten ziyade belirlenen şeyleri koda geçiriyordu.

Hem dizayn hem kodlama tarafında birikimi olanlar Vitalik ve Gavin olduğu için teknik detaylar daha çok bu ikilinin etrafında dönüyordu. Kontratların değil etkileşime geçenlerin GAS ödemesi, GAS yeterli gelmezse işlemi tamamlamadan işlemin geri çevrilmesi gibi detaylar bu şekilde ortaya çıkmıştır.

Ethereum’un dizayn yapılarına geri dönersek, Gavin’in katılmasıyla bağımsız bir Blockchain olmasında bir engel kalmadı demiştik. En önemli noktası da programlanabilir akıllı kontratları desteklemesi. Bunun için Stack tabanlı bir VM oluşturuldu, detaylarına sonra girebiliriz fakat bunun dışında Bitcoin’den ne gibi farkları vardı yapının?

Önemli farklardan biri Ripple gibi State Tree kullanması ve bunu Block verisine dahil etmesidir. Bunun olmasının etkisi şudur, Bitcoin gibi blocklara sadece geçerli transferlerin eklenme zorunluluğu yok, transferler başarısız da olsa blocklara girip hesaplanıp gerekli feeler alınabilir.

Consensus sistemi olarak Yonatan Sompolinsky ve Aviv Zohar tarafından geliştirilmiş GHOST’un bir varyasyonunu kullanarak block sürelerini kısaltmışlardır.

Greedy Heaviest Observed Subtree

GHOST ile Bitcoin’in Nakamoto Consensus’u arasındaki fark şudur: Bitcoin’de Consensus’a etki eden blocklar tek bir düz çizgi şeklinde ilerlerken GHOST’da dallanıp budaklanmış bir block geçmişi bulunur. Üretilen Block geçerli Block olmak için girdiği yarışı kaybetse ve en uzun zincir dediğimiz lineer yapıda bulunmasa dahi(Orphan Block) üzerinde harcanan POW Consensus’a etki eder. Ayrıca bu blocklara daha az olsa da ödül de verilir. Böylece hızlı ilerleyen block yapısının sorunları azaltılmaya çalışılır.

POW sistemi için kullanılacak madencilik algoritması da önemli bir dizayn kararıdır. Ethereum’un burda yaptığı seçimde ana motivasyonu özel üretim çiplerin yani ASIC’lerin bir avantajının olmaması, normal kullanıcıların donanımlarıyla(GPU) madencilik yapabilmeleriydi. Bu amaçla oluşturulan Ethash bence amacını yerine getirdi fakat GPU gibi standart donanımların Eth madenciliğinde kullanılması bu sefer de kullanıcıların donanımlarının fiyatlarının Ethereum madenciliği sebebiyle yükselmesi ve bu donanımlara ihtiyaç duyan diğer kesimlerde (Gamerlar) bir antipati oluşmasına da yol açtı.

Token yapısı da MasterCoin’in satışına oldukça benzer şekilde Bitcoin’de yapılan bir ICO ile oluşmuş oldu. Bu satışa katılanlar dışında Ethereum’a katkıda bulunmuş kurucular kadrosu ve Ethereum Foundation da Premine’dan pay alanlar arasındaydı.

Bu ICO sebebiyle Vitalik’in zamanında MasterCoin’i eleştirdiğine benzer argümanlarla Ethereum’un da Bitcoin topluluğu tarafından eleştirildiğine sık sık denk gelebilirsiniz.

Toparlarsak bu şekilde Ethereum 1.0 Ethash, GHOST ve EVM ile bir şekilde oluşturulmuş oldu. Bu yapının ideal olmadığı aslında daha ilk günden biliniyordu ve Ethereum 2.0'ın planları yapılıyordu. Mevcut yapı eldeki imkanlarla o günün şartlarına göre yeterli bulunmuş geniş perspektifde ise geçici bir çözümdü. Fakat ne demişler:

Nothing is more permanent than a temporary solution

Swarm, Whisper, Mist Browser gibi projeler iptal edildi fakat ana odak olan Ethereum’da da bugüne kadar ciddi bir gelişme olmadı. Ethereum 1.0 ortaya konulduğunda Vitalik’in hoşnutsuz olduğu 2 konu ve kafasında bu 2 soruna dair 2 çözüm vardı.

Birinci sorun POW ve yol açtığı madencilik yapısıydı. Ethereum’un ilk günden beri amacı POS’a geçmekti fakat bunun için gerekli Consensus sistemleri konusunda yeterli tecrübeleri yoktu. Faydalanabilecekleri BFT Consensus literatürü vardı fakat Crypto’nun finansal yapısının çok farklı dizaynları mümkün kıldığını düşündükleri için klasik Consensus’a dair çalışmalara pek kıymet vermiyorlardı.

Temel nokta aslında Slash, yani POS Validator’lerini koydukları Stake üzerinden cezalandırma etrafında nasıl bir dizayn yapabilecekleriydi. Vitalik’in POS için ilk konseptinin ismi Slasher yani ceza kesendir. Nedeni malum. O günden beri Ethereum’un bir POS Consensus’a geçmesi isteniyor, gelecek yapının olmazsa olmazı ise Slash yapabilmesi. Bu isteklerinin geçen uzun sürenin ardından Merge ile gerçekleştiğine şahit olduk. Yazının devamında detaylı değineceğim.

Diğer nokta da Ethereum’un ölçeklenme problemi. Bu probleme sonrasında bir çok şeyle cevap verdikleri oldu. HyperCube, Shadow Chain, Plasma, Sharding ve daha niceleri. Bu soruya Vitalik’in ilk verdiği cevap ise aslında son verdiği cevap ile aynı.

SCIP: Secure Computational Integrity and Privacy

Nedir bu SCIP? Daha da açık anlayacağınız şekli ile SCIP’e biz bugün ZK-Rollup diyoruz. Bugün Starkware’in başında gördüğümüz Eli Ben Sasson o zamanlarda da bunlar üzerine çalışıyor(SCIPR Lab’da) ve anlatıyordu, o zamandan beri de Vitalik bunu Ethereum’a getirmek istiyor. Tam olarak ne kadar geriye gidiyor? Ethereum’a dair bulabileceğimiz en eski dökümana gidelim. Vitalik’in 2013 yılında yazdığı Ethereum Paper’ında SCIP geçer. O kadar eski.

Sözleşme, ETH’nin kendisi hariç, Ethereum ağındaki her şeyin temel veri türüdür. Kendi para biriminizi mi yapmak istersiniz? Bir sözleşme olarak kurgulayın. Başka bir para birimi karşılığında ETH satan bir emir mi vermek istersiniz? Bunu yapmak için bir sözleşme yapın. Güven gerektirmeyen bir bahis mi yapmak istersiniz? Yine bir sözleşme. Tam ölçekli bir Skynet mi kurmak istersiniz? Belki birkaç bin birbirine bağlı sözleşmeye sahip olmak isteyebilirsiniz ve bunu yapmak için onları cömertçe ETH ile beslediğinizden emin olun, ancak hiçbir şey sizi durduramaz. En sonunda, sözleşmede bir ödül sunarak, merkezi taraflara ağır hesaplamaların sonucunu hesaplatarak geçerliliğini SCIP ile doğrulamak isteyebilirsiniz.

Ölçeklenme konusu geçtiğinde benzer şekillerde yine SCIP’den bahsedildiğine denk gelebilirsiniz. Bu şekilde bir tanımlama da aslında ZK ile başlayan terimlerden daha sağlıklı bir tanımlaymış. Çünkü ZK’de temel amaç bir şeyleri gizlemekken burda amaç yapılan bir hesaplamanın doğruluğunu 3.taraflara ispatlamak.

Vitalik’in ilk paperlarında verdiği Skynet örneği bu mantıkla çalışır. Yani sistem için yapılan hesaplamaların ispatının oluşturulması. ZKEVM dediğimiz şey de Ethereum’un akıllı kontrat çalıştıran EVM programlama ortamındaki hesaplamaların yine bu mantık ile ispatlanması prensibine dayanır.

Bu yapılan hesaplama doğrulanabildiği için de bu hesaplamayı merkezi tarafların yapması sorun görülmez. Örnekteki merkezi taraflar ifadesi de burdan gelir(1Merkezi taraflara hesaplama yaptırarak”). Bir diğer açıdan bu işi yapacakların merkezileşmesi de kaçınılmaz. Çünkü bu hesaplamaların kolay doğrulanabilir şekilde ispatını yapmak oldukça işlem gücü isteyen maliyetli bir süreç. Ethereum için de bir çok çözüm etrafında dönüp dolaştıktan sonra tilkinin döndüğü kürkçü dükkanı. Oraya dönmeden ise öncesinde neler planlandığına biraz değinmemiz lazım.

ETH 2.0 Planı

Ethereum ve 2 rakamını bir arada gördüğümüzde anlattığı şey aslında Ethereum’u baştan aşağı değişterecek yeni nesil bir platform idi. Bugün ise sadece POS Consensus’a ETH2 diyoruz. Ethereum’un bir sonraki olacağı şey için ise büyük hedefler koymaktan vaz geçildi. Bunun yerine elimizde bir sistem var, makul şekilde yapılabilecek geliştirmeleri yavaş yavaş yapacağız deniyor. Başlangıçta ise bunun tam tersi bir durum vardı.

Öyle bir Consensus yapacağız ki hem POW’dan kurtulacak hem saldırılara karşı dayanıklı olacak hem yüksek Validator sayılarına ulaşacak hem finality sunacak, öyle bir VM yapacağız ki hem mevcut bilgisayar mimarilerini destekleyecek hem hızlı çalışacak hem mevcut Ethereum kontratlarını geriye dönük olarak destekleyecek, öyle bir ölçekleme sistemi kuracağız ki bütün internete hizmet verecek.

VM değişikliği olmadı, ikinci katman ile ölçekleme amaçlayan Plasma veya State Channel yapıları tutmadı, kalan en önemli temel ise Sharding olmuştu. O da aslında yine rafa kalktı fakat sisteme etkileri devam ediyor.

Vitalik’in Sharding sevgisini 2021 yılında dahi görmemiz mümkün. İsmi ise yaşamaya devam edecek gibi duruyor. Shard aslında küçük parça anlamına geliyor. Ağdaki herhangibir şeyi bölüp parçalamaya Sharding diyebiliriz fakat uzun yıllar Sharding denildiğinde aklımıza gelen şey daha spesifik bir dizayndı. Bu dizayn aslında bugünkü Polkadot’un dizaynına Ethereum’un gelecekte olacağı yapısından daha çok benziyor.

Sharding’teki temel fikir ağı birden fazla parçalara bölünmesi fakat bu birden fazla parçanın aynı Validator topluluğundan rastgele seçilen ekiplerle işletilmesi ve güvenliğinin sağlanması.

Bu tarz bir dizaynın düzgün işleyebilmesi için yüksek sayıda Validator’eihtiyacımız var. Çünkü ne kadar geniş bir havuzdan seçersek tek bir shard’da kötü niyetli Validator’lerin birikme olasılığını o kadar azaltmış oluruz. Böylece problem çıkma olasılığını azaltmış oluruz.

Shard komitesinin ele geçirilme olasılığını ne kadar düşürsek de yeterince bekleyen bir saldırgan bir shard komitesinde çoğunluğu alabilir. Bu olduğunda da diğer Validator’lerin bu saldırıyı görüp ağı uyarması lazım. Bu uyarı mekanızmasında uyarıyı yapan aktör Fisherman görevini yapmış oluyor, sunduğu kanıta da Fraud Proof deniyor. Celestia yazısında da değinmiştik bu konuya. Orda vardığımız sonuç gibi de Fraud Proof oluşturma işleminin gerçekleşebilmesi için üretilen Shard block’unun Data’sının erişilebilir olması gerekiyor ki diğerleri yapılan hatayı görüp raporlayabilsin. Dolayısıyla Celestia’ya çok benzer bir Data Availability katmanının Ethereum içinde de oluşturulması gerekiyor. Bu tarz bir Data Availability katmanının Data kapasitesi de üzerinde çalıştığı sistemin Validator sayısının artmasıyla beraber artar.

BLS ve RANDAO

Bu 2 durumu birleştirdiğimizde şunu görüyoruz, Ethereum’un rastgele alt komiteler seçmesi gerekiyor, bunu da ölçekleme önceliklendiği için mümkün olduğu kadar geniş bir Validator sayısıyla yapmak istiyor.

Bunu sağlamak için gerekli en önemli işlevlerden biri verimli bir imza birleştirme sistemi. Validator sayısı arttıkça block’lara yönelik bildirilecek görüş sayısı da artacaktır ve bu görüşlerin herkese de ulaşması gerekiyor. Bu durum ciddi bir yük oluşturacağı için Ethereum’da imzalar daha blocklara ulaşmadan P2P katmanında birleştirilerek ufaltılırlar. Bu iş için ideal olan ve çok yüksek sayıda imzayı birleştirmeye yarayan imza altyapısına BLS Signature denir.

Bir de rastgele alt komiteler seçilmesi gerek demiştik. Bunu da RANDAO denilen bir yapı ile yapıyoruz. Temelde bir alt komitenin başka bir alt komiteyi rastgele seçmesi işlemi denebilir. Mekanızmanın işleyişini mevcut komitedeki her bir aktörün sırayla bir deste kartı tekrar tekrar karması olarak düşünübilirsiniz.

Not:Random sayı üretimi yazının diğer kısımlarını anlamak için şart değil. İlginizi çekmediyse Consensus kısmına atlayabilirsiniz.

Klasik RANDAO şemalarında her bir aktörün kafasına göre bir karma yapmaması için işlem başlamadan aktörlerin bir random sayı belirleyip bu sayıyı hash değerini alarak gizlemelerini(seçilen sayı gizli sayının Hash’i herkese açık), işlem sırasında ise bu gizledikleri sayıyı ortaya çıkardıkları bir şemada görürsünüz. Bu yapılara kısaca commit-reveal şemaları denir. Bir değere kilitlenip sonrasında bu değerin ne olduğunu açığa çıkarmak. Bunun yapılabilmelerinin sebebi Hash fonksiyonlarının tek taraflı çalışması. Yani bir değerin Hash’ini hesaplayabilirsiniz fakat bir Hash’in hangi değerden hesaplandığını bulamazsınız.

Bunları RANDAO’nun klasik haline denk gelirseniz diye anlattım çünkü Ethereum’daki RANDAO bu şekilde çalışmıyor. Commit-Reveal şeması kullanmak yerine yine BLS Signature kullanıyorlar. Burda da karıştırılmaması gereken nokta, BLS’in tamamen RANDAO yerine kullanıldığı şemalar da mevcut. O şemalarda kısaca random sayı oluşturacak komite topluca bir BLS imzalaması yapıyor. Fakat bu imzalamanın yapılabilmesi için imzalamayı yapacak ekibin belirli bir yüzdesinin limit olarak belirlenmesi lazım. Bu genelde 2/3 olarak belirleniyor. Yani ekibin 2/3'den fazlası imzalamayı yapmalı ki yeni bir random sayı oluşturulabilirsin. Fakat Ethereum’da bu random sayı üretimini yapan ekip rastgele seçilmiş bir alt komite olduğu için tekrar random sayı üretme sürecinde bu ekibin 2/3'ünün iş birliği yapacağına bel bağlamak mantıklı değil. Bunun yerine sadece RANDAO’nun her bir tekrar karma aşamasını sağlayan commit-reveal kısmı yerine BLS imzalama kullanılıyor.

BLS’den imza birleştirmede bahsetmiştik peki burda neden karşımıza çıktı, standart bir eliptic eğri imzalaması niye yapmıyoruz sorusu akla gelebilir. BLS’in burda yine öne çıkmasının sebebi imzalamanın deterministic olması ve sadece tek bir sonuç üretebilmesi. Eğer birden fazla sonuç üretme mümkün olsaydı imzalamayı yapan bu alternatiflerden işine geleni seçerek yaptığı karma işlemine müdahele edebilirdi. BLS ile ise bu mümkün değil.

Peki ne mümkün? BLS’i komite geneli toplu imzalama için kullanamadık çünkü komitenin çoğunluğununn işbirliği yapacağından emin değildik. Bu da işlemi durdurabilirdi(stoppable). 2 aşamalı Hash yerine tek aşamalı BLS imzalama kullandık fakat genel yapı yine de RANDAO. Dolayısıyla onun sıkıntısı olan biasable olma yani çıkacak random sayıya etki edebilme sorunu mevcut. BLS imzalama yaparken işlem deterministic demiştik, yani orda bir seçim yaparak sonuca etki edememeleri lazım değil mi? Değil :)

Bir ihtimal daha var, o da imzalamamak... Komitenin başındakiler ve ortasındakiler için bir sıkıntı yok, çünkü kendilerinden sonrakilerin işlemleri de sonuca etki edecek ve nasıl etki edeceklerine dair öncül bir fikirleri yok. Dolayısıyla sadece sıranın sonundakilerin yapacakları imzalamalar önemli.

En son sırada imzalama yapan dürüstse manipüle edilmemiş bir random sayı üretilmiş olur. Son sıradaki imzalama yapıp yapmama noktasında bir seçim yapıyorsa, potansiyel 2 alternatifden biri seçilerek. Eğer son <n> imzalamada manipülasyon yapılıyorsa 2^n alternatiften birini seçme imkanına sahip olurlar.

Bu manipülasyonun sonucu gerçekleştirenlerin kendi seçilme olasılıklarını arttırarak ödül miktarlarını arttırmaları. Ethereum’da yazıyı yazdığım an itibariyle bu manipülasyonlar mümkün. Güzel tarafı şu ki bu manipülasyon aktörlerin yapmaları gereken imzalamayı yapıp yapmalarına göre değiştiği için bu manipülasyonun yapılmaya başlanması son sıralarda yapılan imzalamalarda normalden fazla eksik imzalama görülmesiyle anlaşılabilir.

Spesifik olarak belirtmek gerekirse şuan bu işlemi gerçekleştiren her bir alt komitede 32 aktör bulunuyor. Her biri sırayla block üretiyor. Her bir block üretiminde de BLS imzalama ile random sayı üretmiş oluyorlar. Bu 32 blockluk periyota da EPOCH deniyor. Eğer zincirde bu EPOCH ile üretilecek Random sayıya yönelik bir manipülasyon varsa bu 32 blockluk periyodun özellikle son ve sondan bir önceki block slotlarında üretilmeyen block miktarlarında bir artış görülecektir. Peki bu nasıl engellenebilir?

Verifiable Delay Function ( VDF)

VDF hesaplaması uzun süren kontrol edilmesi ise kolay olan bir fonksiyondur. Hesaplamasının hızlandıralamamasındaki temel nokta yapılan işlemin paralel şekilde hesaplananamaması. Bu açıdan EVM’e de benziyor denebilir :)

VDF’in burda amacı EPOCH sonundaki kişilerin imzalama yapıp yapmamaa kararını verecekleri zaman oluşacak sonuçları tahmin edememelerini sağlamak. Çünkü oluşacak random sayının ne olacağı ancak vakit alacak VDF hesaplaması bittikten sonra ortaya çıkacak. Şimdi imzala sonucunu 30dk öğren gibi düşünebilirsiniz.

VDF henüz Ethereum’a eklenmiş değil. Paralel işlem ile hızlandırma olmasa da ASIC ile hızlandırma olabileceği için aynı zamanda ağdaki herkesin bir VDF ASIC’ine sahip olarak elde edilebilecek potansiyel kazanç düşürülmek isteniyor. Bu sebeple açık kaynak şekilde geliştirilmeye çalışılan bir VDF odaklı donanım çalışması da mevcut.

LMD GHOST + FFG(Friendly Finality Gadget)

Artık elimizde hem rastgele komite seçme hem de imza biriktirme mekanızması mevcut. Yapılan seçimlerden Random sayı üretiminde de bahsettiğimiz 32 tanesi aynı zamanda block üreticileri. POW ağlarındaki gibi sadece block üretimlerine bakarak geçerli zinciri seçemeyiz çünkü total Validator sayısı çok fazla. Bu sebeple üretilen blockları diğer Validator’lerin de oylaması gerekiyor. Bir EPOCH’da 32 Block üretiliyor, diğer Validator’ler de bu 32 block’tan birinde oy vermeleri amaçlı rastgele seçiliyorlar.

Verilmesi gereken oy miktarını azaltan bir diğer etki de her block için değil de block zincirleri için oylama yapılması. Örnekten bakarsak Block A’nın sağındaki herhangi bir Block’a oy vermek aynı zamanda Block A’nın geçerliliğine oy vermek demek. Bu mantıkla oluşturulan ilk mekanızma kısa vadeli Consensus da diyebileceğimiz LMD GHOST.

GHOST’tan Ethereum’un POW Consensus’unda bahsetmiştik, sadece en uzun zinciri değil zincire etki eden diğer blockların da hesaba katılması. LMD ise Latest Message Driven yani bir Validator’un sadece en son kullandığı oyun hesaba katılması demek. Burda artık sadece block saymıyoruz çünkü Block’larla beraber gelen oyları da sayıyoruz.

LMD GHOST ayran gönüllü bir Consensus. Yani o an en son verilen oyların çoğunluğu hangi block’u işaret ediyorsa o Block’u kabul ederek devam eder. Bu durum ise sonradan değişebilir. Bu şekilde esnek davranması zincir ilerlemesinin sekteye uğramamasını sağlıyor fakat bu ilerlemede güvenlik konusunda net bir vaatte bulunamıyor. Bu özelliğiyle Liveness yani aktif kalabilme özelliğini önceliklediğini söyleyebiliriz. Safety yani güvenlik ise ikinci planda.

FFG Consensus mekanızmasında bir önceki EPOCH’un son block’una yönelik bir oy kullanımı vardır. Burda işlem daha nettir. İlk EPOCH’da bir şeyler gerçekleşti, ikinci EPOCH’da ya Validator’ler %66+ oranında önceki EPOCH’u kabul etmiştir ya da etmemiştir. Birden fazla oy kullanımı ceza sebebidir. Bir EPOCH’dan sonra bu EPOCH’a yönelik 2 EPOCH kabul yönünde çoğunluk görüş bildirirse artık o EPOCH’daki işlemler Finalize olmuş kabul edilir ve Validator’lerin çok büyük bir kısmının ceza almasına yol açacak alternatif bir oylama gerçekleşmediği sürece de geçerli olmayan bir duruma düşmeleri imkansızdır.

FFG güvenlik yani Safety önceleyen bir yapıdır. Bir kere kabul etti mi değişmesi çok zordur. Fakat bir karara varacağının da garantisi yoktur. EPOCH’da Validator’lerin %66+’sından oy toplanamayabilir. Yani tek başına kullanıldığında bir devamlılık garantisi yoktur Liveness öncelemez. Ethereum’da LMD GHOST ile beraber kullanılmalarındaki sebep de tam olarak budur. FFG bir karara varamasa dahi sistem LMD GHOST ile ilerlemeye devam eder. Bu sırada FFG de her EPOCH’da bir karara varabilmeyi tekrar dener.

Diyelim ki ağın %50'si şalteri indirdi. Aktif değiller. FFG Validator’lerin %66 oyunu sonsuza kadar bekleyecek mi? Bu durumda dışardan bir Hardfork ile müdahele her zaman masada. Sadece Safety öncelikleyen Tendermint(Cosmos) gibi ekosistemlerde zincir zaten otomatik olarak durup Hardfork bekler. Ethereum’da ise LMD GHOST çalışmaya devam eder. Aktif olmayan Validator’lerin ise Stake miktarı Inactivity Leak denilen bir mekanızmayla yavaş yavaş azalmaya başlar. Yani müdahele edilmeye çekinilen bir durumda bu yavaş ceza sistemi ile yaklaşık 2–3 hafta sonra kalan aktif Validator’ler FFG Consensus’da da bir karar alabilmeye başlarlar.

Inactivity Leak yoluyla zamanla ceza keserek karar alabilir hale gelmenin enteresan bir etkisi de var. Ethereum ağının birbirinden habersiz 2 parçaya bölünüp uzun süre bu durumun devam etmesi durumunda ikisi de yoluna bu şekilde devam ederek 2 farklı ağ oluşumuna sebebiyet verebilirler. Extreme bir örnek olsa da teorik anlamda değerlendirilen senaryolardan biridir.

Merge

Ethereum’un Consensus yapısını anladıysak gelelim meşhur Merge’e. Neden standart bir Hardfork değil de Merge yani birleşme tabiri kullanılıyor? Çünkü Ethereum POW zincir üzerinde çalışmaya devam ederken Beacon Chain denilen Proof of Stake’in ana block zinciri de boş blocklar ile çalışmaya başladı. POS zincire ETH geçişi tek taraflı olarak açıldı. POS ödülleri de verilmeye başlandı fakat geçiş tek taraflı olduğu için ödülleri veya ana ETH Stake’lerini çekmek mümkün değil.

Merge ile beraber ise POW Consensus üzerinde çalışan EVM tabanlı Execution altyapısı POS zincir üzerine taşınmış oldu. Temel işleyişte bir değişim söz konusu değil yani. Ethereum yapı olarak zaten Consensus ve Execution’u ayrı ele alıyor. Yani bir Ethereum Node’u kuracak kullanıcının 2 seçim yapması gerekiyor. Consensus yazılımı seçimi ve Execution yazılımı seçimi.

ETH 2.0 aslında Ethereum’un yeni halinin tamamını anlatan büyük bir vaadin adıydı. Uygulamaya geçirmede olan yavaşlık fakat planlarda ve isteklerde giderek daha fazlasının istenmesi ETH 2.0'ı Ethereum topluluğunun Kızıl Elma’sı haline getirmişti.

Kızıl Elma: Türk mitolojisinde düşünüldükçe uzaklaşan ancak uzaklaştığı oranda cazibesi artan ülküler veya düşleri simgeleyen bir ifade.

The Great Renaming

Ethereum geliştiricileri açısından ise Ethereum 2.0 başlığı altında yaptıkları şey Consensus dizayn etmek, devam eden POW zinciri tarafında yaptıkları şey ise Execution mantığı üzerinde çalışmaya dönünce, Ethereum 2.0'ın hiçbir zaman gerçekleşmemesi meselesini de ortadan kaldıracak bir yeniden isimlendirme yoluna gittiler. Bu yeniden isimlendirmeye göre ETH1 artık Execution mantığını temsil ediyor, ETH2 ise Consensus mantığını temsil ediyor. Vaad edilen büyük değişim yok. Sadece Ethereum var ve onun üzerinde adım adım değerlendirilecek ve gerçekleştirecek geliştirmeler olacak.

Öze geri dönüş

Ethereum geliştiricileri Consensus ile boğuşmaya devam ederken 2020'de DEFI Summer dediğimiz dönemde DEFI’nin yükselişi ile beraber Ethereum’un kullanımında daha önceki Cryptokitties ve ICO patlaması dönemlerinde olduğu gibi devasa bir kullanım ortaya çıktı. O zamandan farklı olarak ise topluluk Sharding’in yakında gelip onları kurtarmayacağını, Plasma gibi yapıların başarısız olduğunu kabul etmiş durumdaydı.

Bu durum kullanıcıların alternatif zincirlere kaymasına yol açarken Ethereum tarafında da daha hızlı gerçekleştirilebilecek ölçeklenme metodları arayışına yol açtı. Bu arayış Ethereum’un köklerinden budaklandığı temel zinciri Data kaynağı olarak Meta Protocol mantığının Rollup genel ismi ile, ilk paperlarda hesaplamaları kolaylaştırma amaçlı bahsedilen SCIP mantığının ZK-Rollup ismi ile, Plasma üzerinde çalışmış ve Data’nın ana zincirde olmaması sebebiyle başarısız olmuş ekiplerin ise Optimistic Rollup ismi ile geri dönüşüne yol açtı.

Rollup

Rollup’ları basit olarak ana ağın hesaplama yükünü kendilerine alan yapılar veya bağımsız bir zincirin akıllı kontratlar kullanarak ana ağın güvenliğinden faydalandırılması gibi tanımlanabilir.

ZK-Rollup ağları her blockta yaptıkları ilerlemeyi cryptographic olarak ana ağa kanıtlarken, diğer block üreticilerin block üretebilmek için ihtiyaç duyacakları veriye ulaşabilmelerini garanti edebilmek için de block verilerini ana ağa gönderir. Yapılan cryptographic ispat doğrulaması kolay olsa da ağın bunu hesaplaması maliyetlidir.

Optimistic-Rollup ağları her blockta yaptıkları ilerlemeyi ana zincire bildirirken hem bu bildirdikleri ilerlemenin diğer block üreticileri tarafından denetlenip itiraz edilebilmesi hem de yeni block yeni block üretebilmeleri için ihtiyaç duyacakları veriye ulaşabilmelerini garanti edebilmek için de block verilerini ana ağa gönderir. Ekstra bir itiraz mekanızması da olduğu için yapılan ilerlemenin doğrulanabilmesi için ekstra bir zaman geçmesi gerekir.

CallData vs State

Rollup’lar Ethereum’un hesaplama yükünü alıyor, Ethereum ise Rollup’ların Data’sını saklayarak onlara Data Availability hizmeti sunuyor diyerek Ethereum’un Data kapasitesini nasıl arttıracağından bahsetmeye geçebilirdik. Fakat Rollup’ların tek katkısı bu değildir. Ethereum Sharding getirilseydi onda da görebilmiş olacağımız bir durum var(Polkadot’da görülebilir alternatif olarak). Ana ağın altında çalışan bu gibi alt ağların ana ağdan beklediği Data tutma hizmeti ile kendi içindeki uygulamaların beklediği Data tutma hizmeti arasında büyük bir fark mevcut.

Blockchain’lere yazılan her şeyin o blockchain tarafından sonsuza kadar tutulacağı bir yanılgıdır. Validator’ler ilerde doğrulayacakları blockların doğrulanmasında ihtiyaç duymayacakları verileri saklamak zorunda değillerdir. İlerde akıllı kontratlar tarafından erişilerek kullanılabilecek verilere State verisi denir ve her blockta bu State verisinin Hash’i de eklenir. State verisini Validator’ler tutmak zorundadır ve büyümesi Ethereum için sıkıntılı bir durumdur. Büyümesinin önüne geçmek için belirli bir zamandan sonra silmek(State Expiry) gibi çözümler de gündemdedir.

Rollup’ların ise bu tarz uzun süreli bir depolamaya ihtiyacı yoktur. Rollup verilerinin ana zincire gönderilme sebebi block’u üretenlerin block verisini gizlemediğinden emin olmaktır. Yani kısa vadeli bir depolama yeterlidir. Bu sebeple mevcut durumda verilerini State’e yazmak yerine CALLData’ya yazmaktadırlar. CALLDATA o block’un hesaplamasının başlatılması için gerekli bir veri olsa da tekrar ihtiyacın olmayacak bir veri olduğu için GAS Fee olarak daha ucuz bir depolama seçeneğidir. Validator’lerin silmesinde pek bir sakınca olmadığı için de Validator’lere fazla bir yük bindirmez.

Rollup Centric Roadmap

Rollup’ların önem kazanması ve diğer ölçeklenme çözümlerinin ufukta gözükememesi Ethereum’da Rollup odaklı daha basit ve hızlı gerçekleştirebilecek geliştirmelerin önem kazanmasına yol açtı. Bu hedef doğrultasındaki yol haritası temel olarak şöyledir:

1. CALLDATA’yı ucuzlat
2. Rollup odaklı bir data formatı oluştur (Blob)
3. Tam ölçekli bir Data Availability servisi oluştur (Celestia benzeri)

3 numara klasik Sharding temelli yol haritasında da Shard’lar için lazım olan ve bu sebepten zaten geliştirilmesi gereken bir şeydi. Burda yapılan temel değişiklik 3 numaranın geç geleceği malum olduğu için tam çözüm gelene kadar mevcut durumu daha basit çözümlerle daha iyi hale getirmek.

Data Availability konusuna Celestia yazısında yeterince değindiğim için burda artık değinmeyeceğim. Ethereum’un yaklaşımı da Celestia’ya oldukça benzer. 2D Erasure Coding ve Data Availability Sampling iki sistemde mevcut. Farklı olan nokta Data’nın doğru oluşturup oluşturulmadığını Celestia Fraud Proof’lar ile kontrol ederken Ethereum Cryptographic olarak bunu ispatlayacak. Bunun için de ZK-Snark’larda da görebileceğimiz bir setup seremonisi gerekecek. Kısaca aradaki farki ZK-Rollup ve Optimistic Rollup’lar arasındaki farka benzetebilirsiniz. Her ne kadar Ethereum ZK Proof kullanmayacak olsa da.

Enshrined Rollup

Rollup’lara gerekli olan Data sorununu da çözdüğümüze göre geriye ne kaldı diye sorabilirsiniz. Geriye Ethereum topluluğunun şuan için konuşmaktan kaçındığı “Elephant in the Room” kalıyor. Rollup’ların protokol dışı aktörler tarafından akıllı kontrat olarak geliştirilmesi beraberinde ciddi güvenlik riski de getiriyor.

Kısaca özetlemek gerekirse bu akıllı kontratların kodlarının hatalı olmasından kaynaklanabilecek riskler, kodların zamanla değiştirilmesi gerektiği için oluşturulan Upgrade patternlerinin getirdiği riskler, yazılım ekibinin güvenlik amaçlı koyduğu kontrollerin getirdiği riskler. Günün sonunda Ethereum’un bir parçası olması beklenen minik ağlarımız Ethereum’un sağladığı güvenlik seviyesinden uzaklaşmış oluyor.

Bu sorunları çözmek için getirilen öneri akıllı kontrat olarak değil Ethereum’da protokol seviyesinde yazılmış Rollup’ların oluşturulması ve Ethereum kodu ile beraber hardforklar ile güncellenmeleri. Bu Rollup’lara da Enshrined Rollup diyoruz.

ZKEVM

Oluşturulacak Enshrined Rollup’larda uzun bekleme süreleri nedeniyle Optimistic Rollup olması istenmiyor, ZK-Rollup olması isteniyor. İlerde mevcut ana ağın da Enshrined Rollup şeklinde doğrulanabilmesi için ZK uyumlu başka bir VM’e geçilmesi de seçeneklerin dışında kalıyor. Dolayısıyla ZK-Rollup içinde EVM’in doğrulanabilmesinin mümkün hale getirilmesi gerekiyor.

Piyasada çeşitli ekiplerden ZKEVM geliştirdik açıklamaları görebilirsiniz. Bu sebepten de bunu gerçekleştirmek kolay gibi görünebilir fakat her ZKEVM diyen aslında aynı şeyi kastetmiş olmuyor. Solidity kodu desteğine veya EVM’nin makine kodu desteğine ZKEVM denilebiliyor. Ethereum protokolü özelinde baktığımızda ise mevcut yapı ile tamamen uyumlu olması istenen bir ZKEVM var. Vitalik bu farkı açıklamak için ZKEVM’leri 5 kategoriye ayırarak farklarını anlatıyor. Ethereum’a lazım olan 1 numaralı olan yani yapması en zor ve performansı en kısıtlı olanı. Şahsi görüşüm cryptography’nin sınırlarını bu kadar zorlamadan önce mevcut VM’i nasıl daha ZK uyumlu hale getirebiliriz diye de kafa yorulması gerekiyor.

DANKSHARDING

Danksharding mevcut L1'in kendisi ile beraber totalde 64 tane Enshrined Rollup’ın cryptographic kanıtlarının Builder denilen devasa makineli Validator’ler tarafından üretilmesini, blocklara hangi işlemleri alıp almayacaklarının ise Proposer denilen standart donanımlı Validator’ler tarafından belirlenmesini içerir. Totalde de buna Proposal Builder Separation deniyor. Block’un oluşturulması ayrı, kanıtlanması ayrı aşamada yapılıyor. Mevcut plandaki Ethereum’un istenen noktaya da bu şekilde ulaşmış oluyoruz.

Diğer geliştirmeler

Consensus’dan bahsederken değinmem bazı noktalar daha vardı yazıyı bitirmeden onlara değinelim. Consensus’da geliştirilmesi istenen bazı noktalar var. Bunlardan birisi yapılan Random seçimlerin herkes tarafından görülmesi. Bunun da block üreticilerin kim olduklarının ortaya çıkarak DOS saldırısına uğrama şanslarını arttırıyor.

Single Secret Leader Election(SSLE) her slot için bir block üretici seçerken bu seçimin sadece seçilen block üretici tarafından önceden bilinebilmesini sağlamaya yarıyor. Bu cryptographic sistemin arkasında da BLS signature’un B’si Dan Boneh reis bulunuyor. Detaylarına ise girmiyorum.

Single Slot Finality: Bir diğer gerçekleştirilmek istenen ise FFG’nin finality süresi. Hatırlanacak olursa her Validator her EPOCH’da bir oy kullanıyordu ve FFG’nin finality süresi en iyi ihtimalle 2 EPOCH sürüyordu. Her EPOCH’da 32 block ve 12 saniye block süresini de hesaba kattığımızda finality süresi minimum 13 dakika oluyor. Bu süreyi kısaltmak için BLS imzalarının birleştirilme mekanızmasını geliştirerek her Validator’un her block için oy kullanmasını sağlamak istiyorlar. Buna da Single Slot Finality deniyor. Normal şartlarda bu kadar yüksek sayıda Validator’ün imzasını hızlı şekilde toplamak pek mümkün değil fakat Ethereum’da Validator Node’u başına 32 ETH sınırı olduğundan dolayı Validator sayısı aslında gerçek değerleri yansıtmıyor. Validator’lerin çok büyük kısmı aslında bir elin parmağını geçmeyecek aktörün elinde. Bu aktörlerin Validator’lerinin keylerinin nasıl birleştirileceğine Ethereum karar verdiği için bu keyler birbirlerinden bağımsız şekilde birleştiriliyor. Bu işlem biraz daha esnetilip bu Validator keylerinin kendi sahipleri tarafından birleştirilmesi mümkün hale getirildiği gibi finality süresini oldukça kısaltmak mümkün olacaktır.

Ethereum’un genel yol haritasını da görselden inceleyebilirsiniz. Her kısmına değinmedim ama görece önemli gördüğüm kısımları anlatmaya çalıştım.

SON

Yazıyı bitirebilen bordo berelileri tebrik ediyorum. Beni twitter’dan takip edebilirsiniz. Bu tarz teknik konuları konuşabilecek bir ortam arıyorsanız →Coin Fedaileri← grubumuza bekleriz.