Ethereum galaksisi, iş yükünü gezegenlerine bölüyor. Galaksinin Güneş’i konumundaki Ethereum L1, tüm gezegenleri (L2 ağları) ile iletişim halinde ve galaksi içerisinde devamlı yoğun uzay mekiği trafiği oluşuyor.
Yeterli düzeyde mekik (blok boyutu) bulunmadığı için parası olanlar mekiklere önden yerleşerek işlerini hallediyorlar. Gezegenlere bölünen işler ile Güneş üzerindeki baskı azalmış durumda. Mekik trafiğini rahatlatacak çözümler ile (Protodanksharding, Sharding ve diğer EIPler) insanlar huzurlu bir hayata kavuşacaklar.
Solana galaksisi içerisinde devasa büyüklükte bir gezegen bulunuyor. Geçmiş tarihlerde, nüfusunu taşıyamayan bu gezegenin ozon tabakası sık sık deliniyordu ve bu galaksinin insanlarının tüm işleri duruyordu (ağ duruyordu). Gezegende yaşanan sanayi devrimi ile (QUIC, Stake-Weight QoS, Localized Fee Markets) insanlar refaha erdi. Fakat halen galaksinin ilerlemesi gereken zorlu bir yol mevcut.

Bu iki galaksimizin de bir kayıt defteri bulunmakta. Ethereum galaksisi çok kalabalık ve EVM isimli bir kayıt defteri kullanıyor. Ethereum galaksisinde kullanılan EVM, yapısı gereği kayıtları (işlemleri) sırasıyla tek tek tutuyor. Solana galaksisi ise SVM olarak çağrılan e-BFP kayıt defterine sahip. SVM, birbiriyle çakışmayan kayıtları (işlemleri) paralel olarak işliyor ve deftere yazıyor.
Evren nüfusunun çoğu EVM kayıt defterini kullanmakta çok daha yetenekli.

Tüm bu kargaşanın ortasında yeni bir galaksi doğuyor, adı MONAD.

M
onad, EVM kayıt defterini (sanal makinesini) kullanan bir galaksi. Solana gibi tek ve devasa bir gezegenden oluşacak bu galaksi. Monad üzerinde saniyede 10.000 kayıt (TPS) tutulabileceği iddia ediliyor. Monad, EVM’i alarak geliştiren ve SVM gibi paralel kayıt yapabilmesini sağlayan bir galaksi.
Şimdi Galaksi-Evren paradoksundan çıkıp mühendislik terimleri kullanmaya başlayalım. Asıl macera şimdi başlıyor..
Her blockchain, kendisini tanımlayan bir yenilik ile hayatımıza giriyor. Bu yenilikler Avalanche için Subnets, Solana için Proof of History, Near için Sharding, Ethereum için…

Monad için ise bu Deferred Execution. Execution’ın Consensus’dan ayrılması…

1) Deferred Execution

• Execution, ağa gelen işlemlerin işlenerek bir hash çıktısının alınmasıdır. State değişikliği ifade eder.
• Consensus ise bu state değişikliklerinin nodelar tarafından onaylanmasıdır.

Öncelikle bir işlemin ve bloğun Ethereum üzerinde nasıl onaylandığına bakalım.

1. Kullanıcılar, clientler (cüzdanlar) aracılığıyla Ethereum nodelarına bir transaction gönderir.
2. Nodelar bu transactionları alır ve o blok için Lider olan node’a gönderir. Lider, kendisine gelen işlemleri sıralar, tek tek execute eder ve bir Merkle Tree oluşturur. Son olarak bloğun hash değerini hesaplar.
3. Daha sonra bu bloğu validator nodelar arasında dağıtır. Validator nodelar önce işlemleri tek tek execute eder ve merkle tree oluşturur.
4. Daha sonra Lider tarafından gönderilen tree’nin root’u ile kendi oluşturdukları root’u karşılaştırırlar.

Eğer bu rootlar örtüşüyorsa ve blok hash değeri de doğruyla oylama aşamasına geçilir.
Bu durumda herkes execution yapar. Ağdaki iletişim miktarı çok fazladır. Bu durum haliyle bir gecikme yaşatır. Execution, consensus’u yavaşlatır.

Monad kartları yeniden dağıtıyor. Yeni bir felsefe ve mühendislik katıyor.

Execution ile Consensus’u aynı zaman aralığına serpmek yanlıştır, Monad bunu savunur.

1. Monad üzerindeki Lider Node, önce işlemleri sıralar.
2. Daha sonra işlemlerin sırası ile hash değerlerini hesaplar ve diğer nodelara gönderir.
3. Diğer nodelar ise kendi mempoollarında tuttukları işlemlerin hashlerini hesaplarlar ve liderden gelen sırayı kontrol ederler.

Eğer kendi mempoollarında olmayan bir işlem yoksa oylama aşamasına geçerler.
Execution yapılmadı. Sadece işlemlerin sırası ve varlığı kontrol edildi. Çünkü eğer işlemlerin sırası belli ise execution için acele etmemize gerek yok. State değişimi elbet doğru ve deterministic olacaktır.

Her node, “N” bloğundaki işlemleri “N+1” bloğunda kendi bilgisayarında execute etmeye başlayacak.

Fakat elimizde bir merkle root yok? İşlemlerin geçersiz olduğunu nasıl anlayacağız?
Bu durum, State Machine Replication dediğimiz olaya mani değil. Bir threshold belirliyoruz. “N” bloğunun merkle root’u “D” blok sonra (“D” sayısı başlangıç için 10 olarak belirlenmiş), yani “N+D” bloğunda yer alacak ve state değişikliği garantilenmiş olacak.

Eğer nodelar yanlış ya da hatalı bir execution yaparlarsa “D” blok geriden tekrar executiona başlayacaklar.

Ethereum ile Monad arasındaki farkı iyi anladığınızı düşünüyorum.

Ethereum, state machine replication olayını çok katı şekilde tutuyor ve sağlıyor.
Monad ise işlem girdi sayısını ve ağın hızını artırmak için esnek ve iyimser bir tavır takınıyor.

2) MonadBFT

2.1) Pipelining

P
ipelining, bir işlemi daha verimli hale getirmek için birden fazla aşamaya bölmeyi ve her bir aşamanın eş zamanlı olarak farklı iş parçaları üzerinde çalışmasını sağlamayı ifade eder.
Bir işlemcinin komut yürütme sürecini birkaç aşamaya ayırarak, her bir aşamanın bir öncekinin tamamlanmasını beklemeden yeni bir komut üzerinde çalışmaya başlaması sağlanır.
Pipelining için güzel bir mutfak örneği Solana yazımda vermiştim. Burada da çamaşırhane örneğinden gidelim.

Ethereum görselin ilk bölümüdür, Monad ikinci bölümüdür.

2.2) Consensus

MonadBFT, pipelining uygulanmış bir HotStuff Consensus’tur. HotStuff Consensus kısaca 3 aşamada gerçekleşir:

• Lider node, validatörlere bir öneri sunar. Validatör nodelar, Lider node hazırız mesajı (prepare) gönderir. Tüm nodeların aktif ve lideri dinlemekte olduğu kesinleşir.
• Validatör nodelar, Liderin önerisine ön onay (pre-commit) oylarını sunarlar. Belirli çoğunluğa ulaşılırsa son round başlar.
• Validatör nodelar, Liderin önerisine kesin onay (commit) oylarını sunarlar. Gerekli çoğunluk sağlanırsa oylama biter ve öneri doğru kabul edilir.

MonadBFT bundan farklı çalışır. İki aşamada, execution yapmadığımız için optimistic cevaplarla gerçekleşir. Varsayımsal çalışır.

Doğru çalışıyorsa linear communication, yanlış giden bir şeyler varsa quadratic communication uygulanır. Anlatacağım.
MonadBFT, adı üstünde bir BFT Consensustur. Ağdaki nodaların stake dağılımları eşit varsayalım. Nodeların “%66+1” tanesi gelen bloğa geçerli onayı verirse blok onaylanır. Ağı ele geçirmek için bu sayı aşılmalı. Ağdaki nodeların “%33+1"i ise ağı yakalayamazsa consensus ve ağ durur (Solana’da çokça gördük bunu :) ).
Consensus içerisindeki pipelining sayesinde Quorum Certificate (QC) or Timeout Certificate (TC) isimli iki onay/red mesajı bulunur.

QC gönderilirse blok onaylanmış, TC gönderilirse bir sıkıntı çıkmıştır.

• “N” bloğunu sıralayan lider, “N-1” bloğunun sertifikası (QC geçerli ya da TC geçersiz, buna detaylı olarak değineceğiz.) ile beraber kendi bloğunu validatör nodelara dağıtır.
• Validatörler, aldıkları işlemleri sırasıyla kontrol ederler ve eğer işlemler doğruysa geçerli oylarını “N+1” bloğunu oluşturacak olan lidere gönderirler. “N+1” bloğunun lideri “threshold signatures” kullanarak validatörlerin “%66+1” tanesinden gelen oyu toplar ve bir QC oluşturur. İletişim lineardir. Lider doğrudan validatörlere, validatörler de doğrudan bir sonraki lidere veri gönderirler.
• Aksi durumda, yani validatörler liderden bir blok alamazlarsa, kendi aralarında konuşmaya başlarlar. Birbirlerine “timeout” mesajı ve ellerinde bulunan son QC’yi gönderirler. Herhangi bir validatör “%66+1” sayıda “timeout” mesajı alırsa TC oluşturur ve sonraki bloğun liderine gönderir.
• “N” bloğunun sonucunun kesinlik teşkil etmesi için “N+2” bloğuyla beraber “N+1” bloğunun QC’si gelmiş olmalı. Aksi taktirde validatörler, “N” bloğu için gelen QC’nin doğruluğundan emin olamazlar.

2.3) BLS Multi-Signatures
Sertifikalar (QC’ler ve TC’ler), secp256k1 eğrisi üzerindeki ECDSA imzalarının bir vektörü olarak basit bir şekilde uygulanabilir. Bu sertifikalar açık ve oluşturulması, doğrulanması kolaydır. Ancak, sertifikanın boyutu imzacı sayısı ile doğru orantılıdır. Sertifika, oy mesajı hariç, hemen hemen her konsensüs mesajında yer aldığı için, bu durum ölçeklenmeyi sınırlayan bir faktördür. Ölçekleme sorununu çözmek için, BLS12–381 eğrisi üzerinde eşleştirme tabanlı BLS imzası kullanılabilir. İmzalar, tek bir imzaya, birbirlerine eklenecek şekilde birleştirilebilir. Tek geçerli birleştirilmiş imzanın doğrulanması, oy kullanan tüm validatörlerin imzalarını doğrular.
BLS imzası, ECDSA imzasından çok daha yavaştır. Performans sebepleriyle BLS Multi-Signatures sadece birleştirilebilir mesaj türlerinde (blok oyları ve sertifikalar QC ve TC için) kullanılır.

Monad, Proof-of-Stake ile çalışacak. Delegasyon sistemi mevcut. Single Slot Finality ile çok verimli bir kullanım sunacak.

2.4) Shared Mempool
Monad, Ethereum gibi Mempool’a sahip olacak. İşlemler, hash değerleri ile burada saklanacak.
Lider node, işlemlerin sırasını doğrulamaları için validatör nodelara işlemlerin kendilerini değil, hash değerlerini gönderecek. Böylece iletişim sırasında validatörlerin indirmeleri gereken veri miktarı çok az olacağı için bandwith gereksinimi de azalmış olacak.

3) Parallel Execution

Monad, parallel execution yapar. Ağa gelen işlemler, eğer aynı hesabın stateini değiştirmiyorsa aynı anda ağdan geçebilir.
Aynı blok içerisinde yer alan 2 işlemi ele alalım;

• Bir işlem A hesabının durumunu (state) okur ve A hesabına para transferi yapar.
• Diğer işlem A hesabının durumunu (state) okur ve A hesabından para transferi yapar.

Bu durumda işlemlerin girdi ve çıktıları karşılaştırılır. İşlemler optimistic olarak execute edilir ve ilk işlemin sonucu ile ikinci işlemin başlangıç durumu karşılaştırılır. Eğer karşılaştırılan durumlar birbirinden farklıysa (sonuç ve başlangıç değerleri aynıysa işlem sırası doğrudur.) yanlış execution yapılmıştır. İşlemler doğru sıra bulunana kadar execute edilir. İşlemler “merge”lenmiş sayılır. Optimistic Execution budur.
İşlemlerin executionı, validatörlerin işlemcilerinde boşta yeterli işlem gücü ve alanı varsa gerçekleştirilir. Eğer bu yer hiç açılmazsa uzun bir işlem zinciri birikebilir. Bu sebeple Monad, fail olmuş işlemler için scheduling yapar. Node yazılımının içinde bulunan Static Code Analyzer ile fail olmuş işlemler için tahmini bir execution zaman aralığı belirlenir.

4) MonadDB

İşlemlerimizi sıraladık, consensusa vardık ve execution gerçekleştirdik. Peki veri tabanı? Bu verileri nerede tutuyoruz?

Ağ verilerinin depolanması için MonadDB tasarlanmıştır. MonadDb, hem kalıcı (disk) hem de geçici depolamada (RAM, memory) yerel olarak Patricia Trie veri yapısını uygular.

Monad, birden fazla işlemi paralel olarak yürütür. Bir işlem diske yazılan durumu okuması gerektiğinde, bu işlemin tamamlanmasını beklemek yerine, okumayı başlatmalı ve bu arada başka bir işlem üzerinde çalışmaya başlamalıdır.

Dolayısıyla, veritabanı için asynchronous i/o (async i/o) gereklidir.

“Async i/o” kısacası, işlemcinin birçok işi paralel olarak yürütebilmesidir. Pipelining konsepti de buradan gelir. İşlemci bir input/output işlemini yürütüp sonucunu beklemek yerine, bu işlemle çakışmayan başka işlemleri eşzamanlı olarak yürütebilir ve çıktılar verebilir.
Görselde görülebileceği gibi Disk ve Network, Memory ve CPU ile karşılaştırıldığında çok yavaş kalıyor. Fakat SSD sürücüler işlemleri eşzamanlı/paralel olarak gerçekleştirebilme kabiliyetine sahip. Böylece CPU’da aynı anda birkaç işlem başlatabilir, yürütebilir ve çıktı verebilir.

5) Carriage Cost and Reserve Balance

Monad, execution ve conseususu birbirinden ayırıp paralel olarak gerçekleştiriyor ve execution için ek zaman ayırıyor. Buraya kadar hemfikiriz.
Ancak, validatör nodeların güncel state’e sahip olmaması, hesaplarının tüm gas tokenini harcamış olan işlemlerin yanlışlıkla dahil edilmesine ve bir Denial-of-Service (Hizmet Reddi) saldırısına yol açabilecek bir soruna neden olabilir. Bu tür sorunları önlemek için Monad, ağ üzerinden bir blokta taşınan işlem için bir “Carriage Cost (Taşıma Maliyeti)” uygular ve her hesap için consensus zamanında güncellenen bir “Reserve Balance (Rezerv Bakiyesi)” tutar.

Taşıma maliyeti, ağ kaynaklarının kullanım maliyetini yansıtan minimal bir ücret olup, spam önleme amacı taşır.

Her adres için, nodelar iki tür bakiye tutar:

• Carriage Cost’u ödemek için kullanılan bir Reserve Balance ve,
• Execution ödemek için kullanılan bir gas miktarı.

Consensus gerçekleştiğinde Carriage Cost, Reserve Balancedan düşülür. Execution gerçekleştiğinde ise gas maliyeti ödenir (çift ücretlendirme).

D blokluk bir gecikme süresi (10 saniye) geçtikten sonra Carriage Cost Reserve Balance’a geri ödenir.

Reserve Balance, ödenmiş işlemlerin bloklara dahil edilmesini sağlamak için var olan bir kasadır. Kullanıcılar, aynı EOA üzerinden çok sayıda işlem göndermeyi planlıyorlarsa, hedef Reserve Balance değerini, bir akıllı sözleşmeyle etkileşim kurarak değiştirebilirler.
Reserve Balance üzerindeki değişiklikler execution olarak ele alınır, yani sadece gecikme süresi (D Blok) geçtikten sonra Reserve Balance üzerinde değişiklik görülür. Bu sistem, kullanıcıların Carriage Costunun büyük bir katı (200 katı) olarak belirlenen varsayılan bir hedef Reserve Balance ile çok sayıda işlemi sorunsuz bir şekilde göndermelerine olanak tanır.
Kurulmakta olan koca bir galaksinin ön gösteriminin sonuna gelmiş bulunmaktayız. Bu galaksi üzerinde kimin ne ödemesi gerektiği, nasıl karar alındığı, işlerin ne kadar hızlı döndüğünü teoride görmüş olduk.
Bundan sonra yapabileceğimiz tek şey gelişmeleri takip etmek ve ağın aktif hale gelmesini beklemek olacak.
Bu noktaya kadar geldiğiniz için teşekkür ederim. Sonraki yazılarda görüşmek üzere.