Monad 3 — Monad Neyi Farklı ve Nasıl Yapıyor, Pipelining, Parallel & Deferred Execution, MonadBFT, MonadDB
İlk iki yazımızda Monad’ın TPS’ini, block süresini, geliştiriciler ve kullanıcılar için uyumluluğunun öneminden bahsetmiştik. Bu yazıda Monad, “sıradan çinko karbon blockchainlere” göre neyi farklılaştırarak bu değerlerine sahip oluyor inceleyelim.
Monad, diğer blockchainlere göre daha hızlı ve ucuz olmasını Parallel Execution ve SuperScalar Pipelining (İç İçe Sokma) özelliklerine borçlu.
Kısaca tanımlayarak örneklendirelim.
Superscalar Pipelining
Superscalar Pipelining, Monad’ın blockchainlerde var olan darboğazlara sunduğu çözüm yolu. İşlemleri paralel şekilde nasıl yapabilirizin cevabı bu Pipelining’de saklı.
Çamaşır yıkama, kurutma, katlama ve yerleştirme işlemleri üzerinden anlatılan diagramda sistemi kolayca anlayabilirsiniz.
Pipelining, ilk işlemde kurutmaya geçtiğimizde boşa çıkan yıkama kaynağını tekrar kullanmaya deniyor. Monad bu sistemi, parallel execution, deferred execution, MonadBFT ve MonadDB alanlarında kullanıyor.
Parallel Execution (Paralel Yürütme)
Parallel execution öncesinde blockchainlerde Execution’ın ne işe yaradığını anlamamız gerekiyor.
Execution
Türkçe’ye çevirdiğimizde Yürütmek, Uygulamak, İcra Etmek gibi anlamlara geliyor. Hatta İnfaz Etmek anlamı da var. (örn: Executioner:Cellat). Basitçe, işi yerine getirmek diyebiliriz.
Blockchainde execution, gönderdiğiniz bir transfer işlemi ya da akıllı kontrat işlemlerinde, işlemlerin gerçekleşmesidir. EVM, execution’ı gerçekleştiren makineye verilen isimdir.
Bir işlemi gerçekleştirirken tahmin edebileceğiniz gibi birden fazla yol vardır. Önemli olan, ağın durumunu bozmamak ve kötü niyetli işlemlere izin vermemek. Örneğin, Ethereum Serial Execution’ı kullanır. Transferler birbiri ardına gelir, gerçekleştirilir ve ağın durumu güncellenir. Ölçeklenme konusunda negatif etkileri olsa da ağın her zaman doğru ve güvenilir olacağı bellidir. Çünkü kafa karıştırmaz ve aynı anda iki işlem yapılmaz.
Monadda da sonuçlar aynıdır. Temel olarak Ethereum gibi işlemleri seri şeklinde onaylıyor. Sonuçlara baktığınız zaman Monad ve Ethereum blockları birbirinin aynısı olacaktır. Fakat gidiş yolu biraz değişik.
Parallel Execution Örneği
Monad ağında 2 işlem yaptınız. Hesabınızın bakiyesi 10 MONAD olsun.
Aynı anda, Ahmet’ten 15 MONAD alacaksınız.
Mehmet’e 5 MONAD göndereceksiniz.
Monad bu işlemleri paralel şekilde devreye alarak, ilk başta ikisinin de doğru olduğunu kabul ediyor. Fakat şöyle bir sorun var, eğer ikinci işlem ilk işlem tamamlanmadan gerçekleşirse hesabınızın bakiyesi 10'dan 5'e düşüp sonra 15 eklenecek.
Fakat olması gereken süreç, hesabınızın bakiyesinin önce 25'e çıkıp sonra 5 düşmesi.
Aynı işlemler Ethereum blockchaininde birbiri ardına geleceği için böyle bir sorun yaşanmıyor. Fakat Monad’ın iyimser parallel execution’ında böyle bir şeyle karşı karşıya kalınabilir. Peki bu durumda transferler ne olacak?
Bu tarz durumlarda Monad, ikinci transferin girdileri ile birinci transferin çıktılarını kontrol ediyor.
Olması gereken neydi, ilk transfer sonucunda hesap bakiyemizin 25 MONAD olması gerekiyor. Eğer ikinci transferin girdisi 25'e eşit değilse, transfer bekletilip tekrar hesaplanıyor. İşte bu kadar.
İşlem sonucunda iki transferinizi de birbiri ardına görüyorsunuz. Tıpkı Ethereum’da olduğu gibi. Bunun sık sık yaşanmaması için Monad’ın bir tahmin edici algoritması var. Fakat beklenenden fazla yaşanırsa, block süresi değişiklik gösterebilir.
Deferred Execution
Diğer blockchainlerde olduğu gibi, Monad’da da işlemler gerçekleştirilmeden önce bir consensus (fikir birliği) sağlanması gerekiyor. Bu işlem, binlerce node’un birbiri arasında iletişimini gerektiriyor. Bu nedenle block süresine ayrılan zamanın çoğunluğu consensusu sağlamakla geçiyor.
Örneğin, Ethereum’un 12 saniyelik block süresinin sadece 1 saniyesi Execution’a kalan 11 saniyesi fikir birliğine ayrılıyor.
Ethereum’un kullandığı mekanizmada koyu renkli olanlar execution, açık renkli olanlar ise consensus olarak resmedilmiş. Birbiri ardına gelen blocklarda görebileceğiniz gibi, consensus uzun bir süre alıyor.
Monad ise execution ve consensus’u ayırarak consensus’da harcanan vakti değerlendirmeye çalışıyor. Bu da execution için büyük bir zaman kaynağı yaratıyor. Ne kadar çok kaynak var ise o kadar fazla execution yapılabilir, ne kadar fazla execution olursa o kadar fazla tx gerçekleşir.
Bu iki örneği, Monad kurucu ortağı ve COO’su Eunice Giarta’nın anlatımı ile dinlemek isterseniz Türkçe altyazılı olarak hazırladığımız videoya göz atabilirsiniz.
MonadBFT
BFT (Byzantine Fault Tolerance), blockchainlerde consensus’u sağlamak için kullanılan algoritmadır. En basit mantığıyla, doğru kabul edilecek block’un üzerinde fikir birliğine varılması için ağın çoğunluğunun o bloğu kabul etmesi gerekir. Klasik örnek üzerinden anlatalım:
Örnek:
Bir şehre saldırı yapmayı planlayan Bizans generallerini düşünün. (blockchaindeki nodelar) 4 general olsun. Birbirleri arasındaki iletişim kısıtlı ve birbirlerine gönderdikleri elçiler hain olabilir/yolda öldürülüp yerine geçilebilir. (ağı manipüle etmeye çalışan nodelar)
Cevaplanması gereken soru ise, bu generaller şehre aynı anda saldırı yapma ya da yapmama konusunda fikir birliğine nasıl varacaklar? (yeni block’u onaylama konusu)
MonadBFT, bu sistemi Liderler ve Roundlar ile çözüyor. Sıfırdan oluşturulmuş bir şey değil, hali hazırda kullanılan HotstuffBFT’nin geliştirilmiş hali.
MonadBFT Sistemi:
Monad ağı validatörlerden birisi (her blockta değişiyor) tüm nodelara sıradaki blocku sunuyor.
Eğer validatörlerin çoğunluğu (2/3) blocku onaylarsa sıradaki bloğa geçiliyor. Buradaki QC (Quorum Certificates), nitelikli çoğunluğun oy verdiğini gösteriyor.
Fakat onaylanmazsa ağa bir “timeout” mesajı yayınlanıyor. Ve liderin potansiyel bir hain olduğu düşünülüyor. (Timeout Certificates) TC ise, liderin dürüst davranmadığının ve blockun geçerli olmadığının belgesi niteliğinde.
Finalizasyon, iki QC art arda elde edildiğinde yapılıyor. TC de block’un geçersiz olduğunu göstermek için kullanılıyor. Bu sayede blockların doğru olduğu onaylanmış oluyor.
İşte bu sistemde, tıpkı diğer pipelining örnekleri gibi, MonadBFT’de lider validatör bir taraftan yeni block teklifi sunarken, diğer taraftan önceki blockun onaylandığı bilgisini (QC) ağa iletir. Bu sayede iletişim, dolayısıyla ağ hızlanmış olur.
MonadDB
Monad birden fazla işlemi paralel olarak yürütüyor. Bu nedenle bir işlemin sonucunu beklemek için diğer bir işlemi engellemememiz gerekiyor. Tıpkı diğer pipelining yöntemlerindeki gibi bir taraftan bir işleme başlayıp boş kaynaklar ile diğerlerine yönelmeliyiz.
Monad bunu Async i/o ile çözüyor.
Async i/o (Eşzamansız Girdi/Çıktı)
İletişim devam ederken CPU’nun eşzamanlı olarak çalışmaya devam etmesini sağlayan bir giriş/çıkış işleme biçimidir.
Bunu, HGS sistemi gibi düşünebilirsiniz. Yine her şey sırasıyla gelip gidiyor, fakat en azından okuma işlemleri aynı zamanda yapılabiliyor.
Yazıyı okuduğunuz için teşekkürler, sevgiyle kalın!
Hazırlayan: Modular Team, CyranoDB 🦍
