EVM Paralelizasyon Optimizasyonu: Reddio Örneği ile Performans Artışı Yolu

Herkesin bildiği gibi, EVM, Ethereum'un en temel bileşenlerinden biridir ve "uygulama motoru" ve "akıllı sözleşme çalışma ortamı" gibi önemli roller üstlenir. Binlerce düğümden oluşan açık bir ağ olan blokzincirinde, farklı düğümlerin donanım yapılandırmaları büyük farklılıklar gösterebilir. Akıllı sözleşmelerin her düğümde tutarlı bir şekilde yürütülmesini sağlamak için sanal makine teknolojisi ideal bir çözüm olmuştur.

EVM, farklı işletim sistemlerinde ve cihazlarda akıllı sözleşmeleri aynı şekilde çalıştırabilir, bu çapraz platform uyumluluğu her bir düğümün sözleşmeyi yürüttükten sonra tutarlı sonuçlar almasını garanti eder. Bu, Java Sanal Makinesi JVM'nin prensibiyle benzerdir.

Blockchain tarayıcısında gördüğümüz akıllı sözleşmeler, önce EVM bayt koduna derlenir ve ardından zincir üzerinde saklanır. EVM sözleşmeyi yürüttüğünde, bu bayt kodunu sırayla okur, her bir talimatın belirli bir Gaz maliyeti vardır. EVM, her bir talimatın yürütülmesi sırasında Gaz tüketimini takip eder, tüketim miktarı işlemin karmaşıklık düzeyine 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 kuyruğa sırayla alınır ve belirli bir sıraya göre gerçekleştirilir. Paralel işleme yöntemi kullanılmamasının sebebi, blok zincirinin tutarlılığı kesin bir şekilde sağlaması gerektiğidir; aynı işlem grubunun tüm düğümler arasında aynı sırayla işlenmesi gerekmektedir. İşlem işleme paralelleştirildiğinde, işlem sırasını tam olarak tahmin etmek zorlaşır, karmaşık bir zamanlama algoritması kullanılmadığı sürece.

2014-2015 yıllarında, Ethereum kurucu ekibi zaman baskısı nedeniyle basit ve bakımı kolay bir seri yürütme yöntemi tasarlamayı tercih etti. Ancak, blok zinciri teknolojisinin evrimi ve kullanıcı kitlesinin genişlemesi ile TPS ve throughput talepleri giderek artmaktadır. Rollup teknolojisinin ortaya çıkıp olgunlaştıktan sonra, EVM'nin seri yürütme ile sağladığı performans darboğazı Ethereum ikinci katman ağında belirgin bir şekilde ortaya çıkmıştır.

Sequencer, Layer2'nin ana bileşeni olarak, tüm hesaplama görevlerini tek bir sunucu biçiminde üstlenir. Eğer Sequencer ile birlikte çalışan dış modüllerin verimliliği yeterince yüksekse, nihai darboğaz Sequencer'ın kendisinin 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ünde mükemmel optimizasyon yaparak 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, işlenmesi gereken işlemler ERC-20 transferlerinden çok daha karmaşık olduğunda, TPS değeri kesinlikle büyük ölçüde düşecektir. Bu nedenle, işlem işlemenin paralelleştirilmesi gelecekte kaçınılmaz bir eğilim olacaktır.

Ethereum işlemlerinin yürütülmesindeki iki ana bileşen

EVM dışında, go-ethereum'daki işlem yürütmeyle ilgili bir diğer temel bileşen stateDB'dir ve Ethereum'daki hesap durumunu ve veri depolamasını yönetmek için kullanılır. Ethereum, veritabanı indeksleri olarak Merkle Patricia Trie adı verilen ağaç yapısını kullanır; EVM her işlem yürütmesi sırasında stateDB'de saklanan bazı verileri değiştirir ve bu değişiklikler nihayetinde küresel durum ağacında yansıtılır.

stateDB, tüm Ethereum hesaplarının durumunu, EOA hesapları ve sözleşme hesapları dahil olmak üzere, hesap bakiyesi, akıllı sözleşme kodu gibi verileri saklayarak korur. İşlem yürütme sürecinde, stateDB ilgili hesap verileri üzerinde okuma ve yazma işlemleri yapar. İşlem tamamlandıktan sonra, stateDB yeni durumu kalıcı işleme için alt veritabanına göndermesi gerekir.

Genel olarak, EVM akıllı sözleşme talimatlarını yorumlamak ve yürütmekle sorumludur, hesaplama sonuçlarına göre blok zincirindeki durumu değiştirirken, stateDB ise küresel durum deposu olarak görev yapar ve 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ı inşa eder.

Sıralı yürütmenin belirli süreci

Ethereum'daki işlem türleri EOA transferi ve sözleşme işlemleri olarak ikiye ayrılmaktadır. EOA transferi, sıradan hesaplar arasında ETH transferi olan en basit işlem türüdür; sözleşme çağrısını içermez, işleme hızı oldukça yüksektir ve alınan gas ücreti de oldukça düşüktür.

Sözleşme ticareti, akıllı sözleşmelerin çağrılması ve yürütülmesini içerir. EVM, sözleşme ticaretini işlerken, akıllı sözleşmedeki bayt kodu talimatlarını satır satır yorumlayıp yürütmek zorundadır; sözleşmenin mantığı ne kadar karmaşıksa, ilgili talimat sayısı da o kadar fazla olur ve harcanan kaynak da o kadar fazla olur.

Örneğin, ERC-20 transferlerinin işlenme süresi, EOA transferlerinin yaklaşık 2 katı kadardır ve daha karmaşık akıllı sözleşmeler, örneğin bir DEX üzerindeki ticaret işlemleri, EOA transferlerinin on katından daha fazla zaman alabilir. Bunun nedeni, DeFi protokollerinin işlem yaparken likidite havuzları, fiyat hesaplamaları, token takasları gibi karmaşık mantıkları ele alması ve büyük miktarda hesaplama yapması gerekmektedir.

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

Ethereum tasarımında, bir blok içindeki işlemler sırayla teker teker işlenir, her işlem belirli bir eylemi gerçekleştirmek için bağımsız bir örneği vardır. Her işlem farklı EVM örnekleri kullanmasına rağmen, tüm işlemler aynı durum veritabanı stateDB'yi paylaşır.

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

Bir bloktaki tüm işlemler tamamlandığında, stateDB'deki veriler küresel durum ağacına kaydedilir ve yeni bir durum kökü oluşturulur. Durum kökü, her bloktaki önemli bir parametredir ve blok uygulandıktan sonraki yeni küresel durumun "sıkıştırılmış sonucunu" kaydeder.

EVM'nin seri yürütme modu belirgin bir darboğaza sahip: işlemler sırayla bekletilerek yürütülmelidir, eğer uzun süren bir akıllı sözleşme işlemi ortaya çıkarsa, diğer işlemler ancak onun tamamlanmasından sonra işlenebilir, bu da açıkça CPU gibi donanım kaynaklarının tam olarak kullanılmasını engeller ve verimlilik büyük ölçüde kısıtlanır.

EVM Çoklu İş Parçacığı Paralel Optimizasyon Çözümü

Sıralı yürütme ile paralel yürütme, tek bir banka gişesi olan bir banka ile birden fazla gişesi olan bir bankayı kıyaslamak gibidir. Paralel modda birden fazla iş parçacığı aynı anda birden fazla işlemi işleyebilir, verimlilik birkaç kat artabilir, ancak karmaşık olan durum çakışması problemidir.

Eğer birden fazla işlem, belirli bir hesabın verilerini değiştirmek için talepte bulunuyorsa ve bunlar aynı anda işlenirse çakışmalar ortaya çıkar. Örneğin, bir NFT yalnızca 1 kez basılabiliyorsa ve işlem 1 ile işlem 2 bu NFT'yi basmak için talepte bulunuyorsa, her iki talebin de karşılanması durumunda açıkça bir hata oluşacaktır. Gerçek işlemlerde durum çakışmaları daha sık görülmektedir, bu yüzden paralel işlem işleme, durum çakışmalarına karşı önlemler almalıdır.

Reddio'nun EVM'ye Paralel Optimizasyon Prensibi

Bir ZKRollup projesinin EVM için paralel optimizasyon fikri, her bir iş parçacığına bir işlem atamak ve her bir iş parçacığında geçici bir durum veritabanı sağlamak, buna pending-stateDB denir. Ayrıntılar aşağıdaki gibidir:

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. Bu, işlem hızını birkaç kat artırabilir.

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

3. Eşzamanlı Durum Değişikliği: Bir blok içindeki tüm işlemler tamamlandıktan sonra, EVM her pending-stateDB'de kaydedilen durum değişikliği sonuçlarını sırayla global stateDB'ye senkronize eder. Eğer farklı işlemler yürütülürken durum çakışması meydana gelmediyse, pending-stateDB'deki kayıtlar global stateDB'ye sorunsuz bir şekilde birleştirilebilir.

Bu proje, işlemlerin durum verilerine doğru bir şekilde erişebilmesini sağlamak ve çakışmaları önlemek için okuma/yazma işlemlerinin işlenme şeklini optimize etmiştir:

• Okuma işlemi: İşlem bir durumu okumak gerektiğinde, EVM öncelikle Pending-state'in ReadSet'ini kontrol eder. Eğer ReadSet'te gerekli veriler varsa, doğrudan pending-stateDB'den okunur. Eğer ReadSet'te karşılık gelen anahtar-değer çifti bulunamazsa, bir önceki bloğun ilgili global stateDB'sinden geçmiş durum verileri okunur.

• Yazma işlemleri: Tüm yazma işlemleri (, yani durum değişiklikleri ) doğrudan global stateDB'ye yazılmaz, önce Pending-state'in WriteSet'ine kaydedilir. İşlem tamamlandıktan sonra, çakışma tespiti ile durum değişikliği 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 ve yazma girişiminde bulunduğunda bu sorun özellikle belirgin hale gelir. Bu nedenle ç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ığında, 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 optimizasyonun performansa katkısı belirgindir, özellikle karmaşık akıllı sözleşme işlemleriyle uğraşırken. Araştırmalar, düşük çakışma yükünde ( işlem havuzunda daha az çelişki ya da aynı kaynakları kullanan işlemler ) arasında, standart testlerdeki TPS'nin 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 kullanıldığında, hatta 60 katına kadar bir artış sağlanabilir.

Özet

Bu projenin EVM çoklu iş parçacığı paralel optimizasyon çözümü, her işlem için geçici bir durum deposu tahsis ederek ve işlemleri farklı iş parçacıklarında paralel olarak gerçekleştirerek EVM'nin işlem işleme kapasitesini önemli ölçüde artırmıştır. Okuma ve yazma işlemlerinin optimize edilmesi ve çatışma tespiti mekanizmasının getirilmesi ile EVM tabanlı kamu blok zinciri, durum tutarlılığını garanti ederken işlemlerin büyük ölçekli paralelleştirilmesini gerçekleştirebilmiştir. Bu, Ethereum Rollup'un geleceği için önemli bir temel oluşturmuştur.