EVM'nin Paralel Optimizasyon Yolu

Herkesçe bilindiği gibi, EVM, Ethereum'un temel yürütme motoru ve akıllı sözleşme çalışma ortamıdır. Çok sayıda düğüm içeren açık bir ağ olarak, kamu blok zinciri, donanım parametreleri büyük farklılıklar gösteren cihazlarda tutarlı yürütmeyi sağlama zorluğuyla karşı karşıyadır. Sanal makine teknolojisi, bu sorunun çözümü için mümkün olanaklar sunarak, akıllı sözleşmelerin farklı işletim sistemleri ve cihazlarda aynı şekilde çalışmasını sağlayarak sonuçların tutarlılığını garanti eder.

Akıllı sözleşmeler zincire eklenmeden önce EVM bayt koduna derlenir. EVM, sözleşmeyi yürütürken bu bayt kodunu sırayla okur, her bir komutun karşılık gelen Gas maliyeti vardır. EVM, her bir komutun yürütülmesi sırasında Gas tüketimini takip eder; tüketim miktarı işlemin karmaşıklığına bağlıdır.

Geleneksel olarak, EVM işlemleri seri bir şekilde işleyerek, tüm işlemler tek bir sırada bekletilir ve belirli bir sırayla yürütülür. Bu tasarım basit ve bakımı kolaydır, ancak blockchain teknolojisinin gelişimi ve kullanıcı kitlesinin genişlemesi ile birlikte TPS ve throughput talepleri sürekli olarak artmaktadır. Rollup teknolojisinin olgunlaşmasıyla birlikte, EVM'nin seri yürütme performansındaki darboğaz Ethereum ikinci katman ağında özellikle belirgin hale gelmiştir.

Sequencer, Layer2'nin ana bileşeni olarak, tek bir sunucu biçiminde tüm hesaplama görevlerini üstlenir. Eğer eşlik eden modüllerin verimliliği yeterince yüksek olursa, nihai dar boğaz Sequencer'ın kendisinin verimliliğine bağlı olacaktır, bu durumda seri yürütme büyük bir engel haline gelecektir. Bu nedenle, işlem işleme sürecinin paralelleştirilmesi geleceğin kaçınılmaz bir eğilimi haline gelmiştir.

Ethereum İşlemlerinin Temel Bileşeni

EVM dışında, go-ethereum'daki işlemlerin yürütülmesiyle ilgili bir diğer temel bileşen stateDB'dir ve bu, Ethereum'daki hesap durumunu ve veri depolamasını yönetmek için kullanılır. Ethereum, veritabanı indeksleri olarak Merkle Patricia Trie ağaç yapısını kullanır. Her işlem yürütüldüğünde, stateDB'deki bazı veriler değişir ve bu değişiklikler nihayetinde global durum ağacında yansıtılır.

stateDB, tüm Ethereum hesaplarının durumunu, EOA hesapları ve sözleşme hesapları da dahil olmak üzere, hesabın bakiyesini, akıllı sözleşme kodunu ve diğer verileri saklamakla sorumludur. İşlem yürütme sürecinde, stateDB ilgili hesap verilerini okur ve yazar. İşlem yürütme tamamlandıktan sonra, stateDB yeni durumu kalıcılık için alt veritabanına gönderir.

Genel olarak, EVM akıllı sözleşme talimatlarını yorumlamak ve yürütmekten sorumludur, hesaplama sonuçlarına göre blok zinciri durumunu değiştirirken, stateDB küresel durum depolaması olarak tüm hesapların ve sözleşmelerin durum değişikliklerini yönetir. İkisi birlikte Ethereum'un işlem yürütme ortamını oluşturur.

sıralı yürütme süreci

Ethereum işlemleri, EOA transferleri ve sözleşme işlemleri olmak üzere iki türde sınıflandırılır. EOA transferi, en basit işlem türüdür; yani, sözleşme çağrısı içermeyen, normal hesaplar arasında ETH transferidir. İşlem hızı hızlıdır ve gas ücreti düşüktür.

Sözleşme işlemleri, akıllı sözleşmelerin çağrılması ve yürütülmesini içerir. EVM, sözleşme işlemlerini işlerken, akıllı sözleşmedeki bayt kodu talimatlarını satır satır yorumlamak ve yürütmek zorundadır. Sözleşme mantığı ne kadar karmaşık olursa, ilgili talimat sayısı da o kadar fazla olur ve tüketilen kaynaklar da artar.

Örneğin, ERC-20 transferlerinin işlenme süresi, EOA transferlerinin yaklaşık 2 katıdır ve Uniswap üzerindeki işlem gibi daha karmaşık akıllı sözleşmeler, EOA transferlerinin on katı kadar zaman alabilir. Bunun nedeni, DeFi protokollerinin işlem sırasında likidite havuzları, fiyat hesaplamaları, token takası gibi karmaşık mantıkları işlemesi ve büyük miktarda hesaplama yapması gerekmektedir.

Seri yürütme modunda, EVM ile stateDB arasındaki işbirliği süreci aşağıdaki gibidir:

1. Blok içindeki işlemler sırasıyla birer birer işlenir, her bir işlemin bağımsız bir örneği belirli işlemleri yerine getirir.
2. Tüm işlemler aynı durum veritabanı stateDB'yi paylaşır.
3. İşlem yürütme sürecinde, EVM sürekli olarak stateDB ile etkileşimde bulunur, ilgili verileri okur ve değiştirilen verileri stateDB'ye geri yazar.
4. Blok içindeki tüm işlemler tamamlandıktan sonra, stateDB'deki veriler global durum ağacına gönderilir ve yeni bir durum kökü oluşturulur.

Bu seri yürütme modelinin belirgin bir darboğazı var: İşlemler sırayla kuyruğa alınarak yürütülmelidir, eğer uzun süren bir akıllı sözleşme işlemi ile karşılaşılırsa, diğer işlemler yalnızca beklemek zorundadır, donanım kaynakları yeterince kullanılamaz ve verimlilik büyük ölçüde sınırlıdır.

EVM'nin Çoklu İş Parçacığı Paralel Optimizasyon Planı

Paralel yürütme modu, birden fazla iş parçacığının aynı anda birden fazla işlemi işleyebilmesini sağlar, bu da verimliliği birkaç kat artırabilir, ancak durum çakışması sorunuyla karşı karşıya kalır. Birden fazla işlem aynı anda bir hesabın verilerini değiştirmek istediğinde çakışma meydana gelir ve bu durumun koordine edilmesi gerekir.

Paralel Optimizasyon Prensibi

ZKRollup projesi Reddio'nun paralel optimizasyon yaklaşımını örnek alarak, ana özellikleri şunlardır:

1. Çoklu iş parçacığı ile paralel işlem yapma: Farklı işlemleri aynı anda işlemek için birden fazla iş parçacığı ayarlayın, iş parçacıkları birbirini etkilemez ve işlem hızı kat kat artırılabilir.

2. Her bir iş parçacığına geçici durum veritabanı tahsis edin: Her bir iş parçacığının bağımsız bir geçici durum veritabanı (pending-stateDB) vardır. İşlem gerçekleştirilirken, durum değişikliği sonuçları geçici olarak pending-stateDB'de kaydedilir ve global stateDB doğrudan değiştirilmez.

3. Senkronizasyon Durumu Değişiklikleri: Blok içindeki tüm işlemler tamamlandıktan sonra, her bir pending-stateDB'de kaydedilen durum değişikliği sonuçları sırayla global stateDB'ye senkronize edilir.

Reddio, okuma ve yazma işlemlerinin yönetimini optimize etti:

• Okuma işlemi: Öncelikle Pending-state'in ReadSet'ini kontrol edin. Gerekli veriler mevcutsa, doğrudan pending-stateDB'den okuyun; aksi takdirde, bir önceki bloğa karşılık gelen global stateDB'den tarihsel durum verilerini okuyun.

• Yazma işlemleri: Tüm yazma işlemleri önce Beklemede durumundaki WriteSet'e kaydedilir, işlem tamamlandıktan sonra çakışma tespiti ile durumu değiştirme sonuçlarının global stateDB'ye birleştirilmesi için tekrar denenir.

Durum çelişkisi sorununu çözmek için, Reddio çelişki tespit mekanizmasını tanıttı:

• Çatışma tespiti: Farklı işlemlerin ReadSet ve WriteSet'lerini izler, eğer birden fazla işlem aynı durum öğesini okumaya veya yazmaya çalışıyorsa, bu çatışma olarak kabul edilir.

• Çatışma yönetimi: Çatışma işlemleri yeniden yürütülmesi gerekenler olarak işaretlenir.

Tüm işlemler tamamlandığında, birden fazla pending-stateDB'deki değişiklik kayıtları global stateDB'ye birleştirilir. Birleştirme başarılı olduktan sonra, nihai durum global durum ağacına iletilir ve yeni bir durum kökü oluşturulur.

Çok iş parçacıklı paralel optimizasyon, özellikle karmaşık akıllı sözleşme işlemleri gerçekleştirirken performansı önemli ölçüde artırdı. Araştırmalar, düşük çatışma yüklerinde, standart testlerin TPS'sinin geleneksel seri yürütmeye kıyasla 3-5 kat arttığını göstermektedir. Yüksek çatışma yüklerinde, teorik olarak tüm optimizasyon yöntemleri kullanıldığında, hatta 60 kat artışa ulaşmak mümkündür.

Özet

Reddio'nun EVM çoklu iş parçacığı paralel optimizasyon çözümü, her işlem için geçici bir durum kütüphanesi tahsis ederek ve farklı iş parçacıklarında işlemleri paralel olarak yürüterek EVM'nin işlem işleme kapasitesini önemli ölçüde artırmıştır. Okuma ve yazma işlemlerinin optimizasyonu ve çakışma tespit mekanizmasının tanıtılması sayesinde, EVM tabanlı halka zinciri, durum tutarlılığını garanti ederken işlem büyük ölçekli paralelleşmeyi gerçekleştirebilir ve geleneksel seri yürütme modelinin performans darboğazlarını çözebilir. Bu, Ethereum Rollup'un gelecekteki gelişimi için önemli bir temel oluşturur.

Reddio'nun uygulanabilir detaylarını, depolama verimliliğini nasıl daha da optimize edeceğimizi, yüksek çelişki durumlarındaki optimizasyon çözümlerini ve GPU'dan nasıl yararlanacağımızı içerecek şekilde daha sonra daha fazla tartışabiliriz.