EVM'nin seri yürütme darboğazı ve paralelleştirme optimizasyonu araştırması

Bilindiği üzere, EVM, Ethereum'un temel yürütme motoru ve akıllı sözleşmelerin çalışma ortamıdır ve Ethereum'un en kritik bileşenlerinden biridir. Birçok düğümden oluşan kamu zinciri ağında, akıllı sözleşmelerin farklı düğümlerde tutarlı bir şekilde yürütülmesini sağlamak için sanal makine teknolojisi hayati bir rol oynamaktadır.

EVM, farklı işletim sistemlerinde ve cihazlarda akıllı sözleşmeleri birlikte bir şekilde çalıştırabilir; bu platformlar arası uyumluluk, her bir düğümün sözleşmeyi çalıştırdıktan sonra tutarlı sonuçlar elde etmesini garanti eder. Bu, Java sanal makinesi JVM'in çalışma prensibine benzer.

Genellikle, akıllı sözleşmeler önce EVM bayt koduna derlenir ve ardından blok zincirine kaydedilir. EVM sözleşmeyi yürütürken, bu bayt kodunu sırayla okur ve her bir komut belirli bir Gas maliyetine karşılık gelir. EVM, her bir komutun yürütülmesi sırasında Gas tüketimini takip eder ve spesifik tüketim miktarı işlemin karmaşıklık derecesine bağlıdır.

Ethereum'in temel yürütme motoru olarak EVM, işlemleri seri bir şekilde işler; tüm işlemler tek bir kuyrukta sıralanır ve belirli bir sıraya göre ardışık olarak yürütülür. Seri yerine paralel seçim yapmanın nedeni, blok zincirinin tutarlılık gereksinimlerini kesin bir şekilde karşılamak ve bir grup işlemin tüm düğümlerde aynı sırayla işlenmesini sağlamaktır.

2014-2015 yılları arasında, Ethereum kurucu ekibi zaman baskısı nedeniyle, basit ve bakımının kolay olduğu seri yürütme yöntemini seçti. Ancak, blok zinciri teknolojisinin gelişimi ve kullanıcı grubunun genişlemesiyle birlikte, TPS ve işlem hacmi talepleri sürekli olarak arttı. Özellikle Rollup teknolojisinin olgunlaşmasıyla birlikte, EVM'nin seri yürütmesi nedeniyle oluşan performans darboğazı Ethereum ikinci katman ağında daha belirgin hale geldi.

Layer2'nin ana bileşeni olarak, Sequencer tüm hesaplama görevlerini tek bir sunucu olarak üstlenir. Eğer Sequencer ile birlikte çalışan harici modüllerin verimliliği yeterince yüksekse, nihai darboğaz Sequencer'ın kendi verimliliğine bağlı olacaktır, bu durumda seri yürütme büyük bir engel haline gelecektir.

Bir ekip, DA katmanı ve veri okuma/yazma modülünü en üst düzeyde optimize ederek Sequencer'ın saniyede yaklaşık 2000'den fazla ERC-20 transferi gerçekleştirebilmesini sağladı. Bu sayı oldukça yüksek görünse de, daha karmaşık işlemler için TPS değeri mutlaka büyük ölçüde düşecektir. Bu nedenle, işlem işleme paralelleştirmesi gelecekte kaçınılmaz bir trend olacaktır.

Ethereum İşlemi Gerçekleştiren İki Temel Bileşen

EVM dışında, işlem yürütme ile ilgili bir diğer temel bileşen stateDB'dir ve Ethereum'daki hesap durumu ve veri depolamasını yönetmek için kullanılır. Ethereum, veritabanı dizini olarak Merkle Patricia Trie ağaç yapısını benimser; EVM her işlem yürütme sırasında stateDB'deki bazı verileri değiştirir ve bu değişiklikler nihayetinde küresel durum ağacında yansır.

stateDB, tüm Ethereum hesaplarının durumunu, EOA hesapları ve akıllı sözleşme hesapları dahil olmak üzere, yönetmekten sorumludur. Sakladığı veriler arasında hesap bakiyesi, akıllı sözleşme kodları vb. bulunmaktadır. İşlem yürütme sürecinde, stateDB ilgili hesapların verilerine okuma ve yazma işlemleri yapar. İşlem tamamlandıktan sonra, stateDB yeni durumu kalıcı işlem için alt veritabanına göndermelidir.

Genel olarak, EVM akıllı sözleşme talimatlarını yorumlamak ve yürütmekten sorumludur, hesaplama sonuçlarına göre blok zincirindeki durumu değiştirmektedir, stateDB ise küresel durum depolama işlevi görerek tüm hesapların ve sözleşmelerin durum değişikliklerini yönetmektedir. İkisi birlikte Ethereum'un işlem yürütme ortamını inşa etmektedir.

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

Ethereum'daki işlem türleri ikiye ayrılır: EOA transferleri ve kontrat işlemleri. EOA transferleri, en basit işlem türüdür; yani, kontrat çağrısı içermeyen normal hesaplar arasındaki ETH transferidir. İşlem hızı çok yüksektir ve alınan gas ücreti son derece düşüktür.

Buna karşılık, sözleşme ticareti akıllı sözleşmelerin çağrılması ve yürütülmesini içerir. EVM sözleşme ticareti yaparken, akıllı sözleşmedeki bytecode talimatlarını satır satır yorumlayıp 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 kaynak da o kadar artar.

Örneğin, ERC-20 transferinin işleme süresi EOA transferinin yaklaşık 2 katı iken, daha karmaşık akıllı sözleşmeler, örneğin bir DEX üzerindeki işlem operasyonları, EOA transferinin on katı kadar sürebilir. Bunun nedeni, DeFi protokollerinin işlem sırasında likidite havuzları, fiyat hesaplamaları, token değişimi gibi karmaşık mantıkları ele alması ve büyük miktarda hesaplama yapması gerekmektedir.

Seri yürütme modunda, EVM ile stateDB bu iki bileşenin işlem işleme süreci aşağıdaki gibidir:

Ethereum tasarımında, bir blok içindeki işlemler sırasıyla işlenir ve her işlem, belirli bir işlemi gerçekleştirmek için bağımsız bir örnek kullanır. Her işlem farklı EVM örnekleri kullanmasına rağmen, tüm işlemler aynı durum veritabanı olan stateDB'yi paylaşır.

İşlem yürütme sürecinde, EVM sürekli olarak stateDB ile etkileşimde bulunmalı, stateDB'den ilgili verileri okumalı ve değiştirilen verileri stateDB'ye yazmalıdır.

Bir bloktaki tüm işlemler tamamlandığında, stateDB'deki veriler küresel durum ağacına gönderilir ve yeni bir durum kökü oluşturulur. Durum kökü, her bloktaki önemli bir parametredir ve bloğun yürütülmesinin ardından yeni küresel durumun "sıkıştırılmış sonucu"nu kaydeder.

Açıkça, EVM'nin seri yürütme modunun belirgin bir darboğazı vardır: işlemler sırayla yürütülmek üzere sıralanmalı, eğer zaman alıcı bir akıllı sözleşme işlemi olursa, diğer işlemler beklemek zorunda kalır ve donanım kaynaklarını yeterince kullanamaz, verimlilik büyük ölçüde sınırlıdır.

EVM'nin çok iş parçacıklı paralel optimizasyon çözümü

Hayattaki örneklerle karşılaştırıldığında, seri yürütme yalnızca tek bir gişesi olan bir bankaya benzerken, paralel EVM ise birden fazla gişesi olan bir bankaya benzer. Paralel modda birden fazla işlem aynı anda işlenebilen birden fazla iş parçacığı açılabilir, verimlilik birkaç kat artabilir, ancak durum çakışması sorununu çözmek gerekmektedir.

Eğer birden fazla işlem, belirli bir hesabın verilerini değiştirmek için talepte bulunursa, bu eşzamanlı işleme sırasında çatışmalar ortaya çıkabilir. Örneğin, bir NFT yalnızca 1 kez basılabilir ve işlem 1 ile işlem 2 bu NFT'yi basma talebinde bulunuyorsa, her iki talebin de karşılanması durumunda açıkça bir hata meydana gelecektir. Gerçek operasyonlardaki durum çatışmaları genellikle daha sık görülür, bu nedenle paralel işleme, durum çatışmalarını ele almak için önlemler almalıdır.

Bir projenin EVM üzerindeki paralel optimizasyon prensibi

Bir ZKRollup projesinin EVM üzerindeki paralel optimizasyon yaklaşımı, her bir iş parçacığına bir işlem atamak ve her iş parçacığında geçici bir durum veritabanı sağlamak, bu veritabanına pending-stateDB denir. Detaylar şu şekildedir:

1. Çoklu iş parçacığı ile paralel işlem: 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ını birkaç kat artırabilir.

2. Her bir iş parçacığına geçici durum veritabanı tahsis etme: Her bir iş parçacığına bağımsız bir geçici durum veritabanı (pending-stateDB) tahsis edilir. İş parçacıkları işlem gerçekleştirirken, global stateDB'yi doğrudan değiştirmek yerine, durum değişikliklerinin sonuçlarını geçici olarak pending-stateDB'de kaydeder.

3. Senkronizasyon Durum Değişiklikleri: Bir blok içindeki tüm işlemler tamamlandıktan sonra, EVM her bir pending-stateDB'de kaydedilen durum değişikliklerini sırasıyla global stateDB'ye senkronize eder. Eğer farklı işlemler yürütülürken durum çakışması olmazsa, pending-stateDB'deki kayıtlar sorunsuz bir şekilde global stateDB'ye birleştirilebilir.

Proje, işlemlerin durum verilerine doğru bir şekilde erişmesini sağlamak ve çakışmaları önlemek için okuma ve yazma işlemlerinin işlenme şeklini optimize etti:

• Okuma işlemi: İşlem durumu okumaya ihtiyaç duyduğunda, EVM önce Pending-state'in ReadSet'ini kontrol eder. Eğer ReadSet'te gereken veri varsa, doğrudan pending-stateDB'den okunur. Eğer ReadSet'te karşılık gelen anahtar-değer çifti bulunamazsa, bir önceki bloğun karşılık gelen global stateDB'sinden tarihsel durum verisi okunur.

• Yazma işlemleri: Tüm yazma işlemleri (yani durumu değiştirme) doğrudan global stateDB'ye yazılmaz, önce Pending-state'in WriteSet'ine kaydedilir. İşlem tamamlandığında, çakışma tespiti ile durumu değiştirme sonuçlarını global stateDB'ye birleştirmeyi dener.

Paralel yürütmenin ana sorunu durum çatışmasıdır; birden fazla işlem aynı hesabın durumunu okuma veya yazma girişiminde bulunduğunda bu sorun özellikle belirgin hale gelir. Bunun için bir çatışma tespit mekanizması getirildi:

• Çatışma tespiti: İşlem yürütme sürecinde, EVM farklı işlemlerin ReadSet ve WriteSet'lerini izler. Eğer birden fazla işlem aynı durum öğesini okumaya veya yazmaya çalışıyorsa, bu bir çatışma olarak kabul edilir.

• Çatışma Yönetimi: Çatışma tespit edildiğinde, çatışma işlemi yeniden yürütülmesi gereken olarak işaretlenecektir.

Tüm işlemler tamamlandıktan sonra, birden fazla pending-stateDB'deki değişiklik kayıtları global stateDB'ye birleştirilecektir. Eğer birleştirme başarılı olursa, EVM nihai durumu global durum ağacına gönderecek ve yeni bir durum kökü oluşturacaktır.

Çoklu iş parçacığı paralel optimizasyonunun performans üzerindeki artışı belirgindir, özellikle karmaşık akıllı sözleşme işlemleri işlenirken. Araştırmalar, düşük çakışma yüklerinde, referans testlerinin TPS'sinin geleneksel seri yürütmeye kıyasla yaklaşık 3-5 kat arttığını göstermektedir. Yüksek çakışma yüklerinde, teorik olarak tüm optimizasyon yöntemleri uygulandığında, hatta 60 kat artış sağlanabilir.

Özet

EVM çoklu iş parçacığı paralel optimizasyon çözümü, her bir işlem için geçici bir durum kütüphanesi atayarak 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 optimize edilmesi ve çakışma tespiti mekanizmasının getirilmesi sayesinde, EVM tabanlı kamu blok zincirleri, durum tutarlılığını sağlama koşuluyla işlemlerin büyük ölçekli paralelleştirilmesini gerçekleştirebilmekte ve geleneksel seri yürütme modelinin getirdiği performans darboğazlarını çözmektedir. Bu, Ethereum Rollup'ın gelecekteki gelişimi için önemli bir temel oluşturmaktadır.

Gelecekte, performansı artırmak için depolama verimliliğini nasıl optimize edebileceğimizi, yüksek çakışma durumlarındaki optimizasyon çözümlerini ve GPU'ları nasıl optimize etmek için kullanabileceğimizi daha fazla keşfedebiliriz.