Optimism Nasıl Çalışır?

Optimism, birçoğumuzun bildiği gibi Ethereum için ölçeklenebilirlik çözümü sunan bir Layer 2 projesidir. Ethereum’un ölçeklenebilirlik sorununu çözmek için optimistic rollup kullanır ve işlemler Optimism (Layer 2) üzerinde, zincir dışında gerçekleşir. Ancak Optimism, işlem verilerini doğrulama için ana ağda calldata (Layer 1) olarak yayınlanmalıdır. (Yazı genelinde Layer 1, Ethereum ana ağını; Layer 2, Optimism’i ifade edecek şekilde kullanıldı.)
Bu durumu, bir restoran mutfağına benzetebiliriz. Optimism, yardımcı aşçı gibi; malzemeleri (yani işlemleri) toplar, hazırlar ve sonra baş aşçıya (ana zincir) son dokunuşları yapması için teslim eder. Böylece, işlemleri daha kolay ve ekonomik hale getirir.
Peki, bu ölçekleme yöntemine neden optimism yani “iyimser” denmiş diyecek olursak, bunun sebebi: Aksini gösteren kesin bir hata veya manipülasyon bulunana kadar layer 2 veya zincir dışı işlenen tüm işlemlerin geçerli olduğu varsayılır. Yani, her şey yolunda gittiği sürece işlemler geçerli kabul edilir.
Kısaca Optimism’i anladıysak artık bu “iyimser” zincirin detaylarına inebilir ve Optimism’in temel iş akışını inceleyebiliriz:

1. Kullanıcılar işlemleri sıralayıcıya gönderir ve sıralayıcı bu işlemleri L2 zincirinin kendi kopyası üzerinde işler.
2. İşlendikten sonra sıralayıcı hem işlem verilerini hem de yeni L2 durum kökünü (state root) L1'e gönderir.
3. Daha sonra tüm L2 düğümleri, işlemi L2 zincirinin kendi kopyalarında işler.
4. L1'e gönderilen yeni durum kökünün doğru olduğundan emin olmak için doğrulayıcı düğümler, yeni durum köklerini sıralayıcı tarafından gönderilen durum köküyle karşılaştırır.
5. Eğer fark varsa “sahtekarlık kanıtı” süreci başlar ve durum değişikliği geçersiz sayılır.
6. Eğer sahtecilik kanıtının sonucu sıralayıcı tarafından gönderilen durum kökü ile uyuşmuyorsa, sıralayıcının ilk depozitosu kesilir. Bu işlemden sonraki durum kökleri silinir ve sıralayıcı, bu kayıp durum köklerini doğru bir şekilde yeniden hesaplamak zorunda kalır.
7. En son sıralayıcı rolü merkeziyetsiz hale geldikten sonra; eğer sıralayıcının teminatı kesilirse, yeni bir sıralayıcı atanır. Böylece sistemin güvenilirliği ve sürekliliği sağlanır.

iş akışının 1–4. adımlar arasını görselden inceleyebilirsiniz.
Bu sistem için önemli iki tür işlem var:

• L2 zinciri üzerindeki iki adres arasında gerçekleşen L2 işlemleri
• L1 ve L2 zincirleri arasında gerçekleşen çapraz zincir işlemleri

İlk olarak, iki adres arasında gerçekleşen L2 işlemlerinin nasıl çalıştığını açıklayalım:

1. Kullanıcılar işlemlerini sıralayıcı düğüme gönderir.
2. Sıralayıcı, geçerli işlemleri L2 zincirine ekler. Her L2 bloğu sadece bir işlem içerir.
3. Birkaç işlem ekledikten sonra, sıralayıcı bu işlemleri L1'deki bir akıllı sözleşmeye gönderir. Bu sözleşme işlem verilerini ve L2 zincirinin yeni durum köklerini saklar.
4. İşlem verileri L1'de depolandıktan sonra, doğrulayıcı düğümler bu işlemi kendi L2 zincir kopyalarına dahil ederler.
5. Eğer sıralayıcı belirli bir kullanıcıyı engellerse , kullanıcı işlem verilerini kendisi görüntüleyebilir ve sıralayıcı bu işlemi belirli bir süre içinde işlemek zorunda olur. Aksi takdirde sıralayıcının teminatı kesilebilir.
6. Ayrıca doğrulayıcılar sadece L1'e değil, aynı zamanda L2'den de senkronize olabilirler. Bu, gecikmeyi azaltır ancak L1'e gönderilip gönderilmeyeceğini garanti etmez.

İkinci olarak, L1 ve L2 zincirleri arasındaki çapraz işlemleri inceleyelim:
L1'de İşlem ve Durum Kökü Depolanması
Her bir işlem için işlem verileri ve sonuç durum kökünün L1'de saklanması gerektiğinden bu verilerin boyutunun en aza indirilmesi, sistemin depolama maliyetlerinin düşürülmesi açısından çok önemli. Bu noktada devreye “rolluplar” giriyor.
Her bir L2 işlemine ait verilerin L1'de nasıl saklandığını açıklayalım:

1. Sıralayıcı, bir dizi ardışık L2 işleminin çağrı verilerini alır ve bunları tek bir yığında birleştirir.
2. Sıralayıcı bu işlem yığınını “CanonicalTransactionChain” olarak bilinen akıllı bir sözleşmeye gönderir.
3. Sonrasında, akıllı sözleşme her işlemin çağrı verisine hash uygular ve bu hashlerden bir merkle ağacı oluşturur.
4. CanonicalTransactionChain, bu grubun merkle kökünü alır ve bunu depolama amacıyla bir akıllı sözleşmeye gönderir.

L2 çağrı verilerinin L1de depolanmasını bu görselden inceleyebilirsiniz.
Peki Optimism güvenlik riskleriyle nasıl başa çıkıyor?
Bilindiği üzere, çeşitli öncelikler olsa da “güvenlik” bir blokzincir projesinde en önemli kritelerden biri. Bu noktada Optimism, Ethereum’un güçlü bileşenlerini kullanıyor. Bu bileşenler arasında “L2Geth” (Ethereum’un resmi istemcisi) ve “EVM” (Ethereum Sanal Makinesi) bulunuyor. Böylece Optimism, bu bileşenlerin zaten sahip olduğu iyi denetlenmiş güvenlik standartlarını baz alarak güvenli bir ortam sağlamış oluyor.
OVM, (Optimism Virtual Machine) Ethereum’daki işlemleri EVM ile aynı şekilde işliyor sadece bu işlemleri off-chain’e taşıyor ve daha sonra sadece çok küçük bir veriyi Ethereum ana zincirine geri gönderiyor. Bu durum, işlemleri hızlandırıyor ve işlem ücretlerini düşürüyor. EVM ise her işlemi ana zincirde doğruluyor.
Sonuç olarak OVM Ethereum işlemlerini hızlandırmak ve işlem maliyetlerini düşürmek için EVM ile etkileşime giriyor, bu da güvenliğin yanında ölçeklenmiş ve daha verimli bir deneyim sağlıyor.
Bununla birlikte Optimism’de “güvenlik” dediğimizde akla Sahtekarlık Kanıtları (Fraud Proofs) geliyor.
Sahtekarlık kanıtları, Optimism sisteminin güvenliği için hayati önem taşıyan bir mekanizma. Aslında yazının ortalarında da bahsettiğim gibi Optimism’de bir sıralayıcı, L1'e yanıltıcı bir durum kökü göndermeye çalışıyorsa doğrulayıcı düğümün devreye girdiği bir süreç bu. Daha sonra doğrulayıcı düğüm, sahtekarlık kanıtını başlatarak ilgili L2 işlemini L1 üzerinde gerçekleştirir ve sahtekarlık kanıtının sonucu, sıralayıcının L1'e gönderdiği durum köküyle karşılaştırıldığında farklı çıkarsa sıralayıcının bağlılık mektubu kesilerek o işlemden sonraki durum kökleri silinip yeniden hesaplanır. Bu sahtekarlık kanıtları işlemlerini yürütmek için Optimism’de OVM (Optimistic Sanal Makine) kullanılır. Bu OVM, işlemlerin L1 ve L2 zincirlerinde aynı sonuçla tekrar oynatılabilmesini sağlar. Bu, doğrulayıcıların sahtekarlık kanıtları oluşturmasını ve işlemleri L1 üzerinde tekrar oynatmasını kolaylaştırır.
Her şey doğru kabul ediliyorsa, bir dolandırıcılık durumunda sistem nasıl işliyor diye soracak olursak:
Optimistic rollupta, ana ağa gönderilen verilerle ilgili bir güvenlik önlemi olarak her düğümün 7 günlük bir itiraz hakkı süresi vardır. L2 ağı üzerinde tek dürüst bir düğümün itiraz etmesi durumunda, yanlış veri gönderen kişi cezalandırılır ve dürüst düğümün verileri kabul edilir. Bu düzenleme, sistemde güvenilirliği ve doğrulamayı sağlamak için kullanılır. Bu 7 günlül süre sistemde tutulan veriler arttıkça artmaz çünkü itiraz penceresi açıldıktan sonra bütün rollup değil sadece itiraz edilen transferin Merkle Ağacı incelenir.
Sonuç olarak işleyişi anladıysak ve neden Optimism kullanalım?, bizlere sunduğu avantaj ne? sorusuna da kısa bir cevap verelim:
Optimism ve optimistic rolluplar, Ethereum ağının ölçeklenebilirliğini büyük ölçüde artırır ve böylece iş hacmini sabit tutarak gaz maliyetlerini düşürür. Ethereum, ağındaki her tam düğümü işler ve ağ çok sayıda düğüm içerdiği için hesaplama çok maliyetli hale gelir. Buna karşılık Optimism ile işlemler, sadece belirli bir grup sıralayıcı ve doğrulayıcı tarafından işlenir. Böylece her bir işlemin hesaplanması L1'in dışına taşınırken, işlem çağrı verileri L1'de kalır. Bu da L1'de çok fazla alan açar ve daha fazla işlemin gerçekleştirilmesine olanak tanır. Böylece Optimism ile, daha büyük kapasiteye sahip olunarak, bir bloğa bir işlem eklemek için rekabet daha düşük olur ve gaz maliyetleri azalmış olur.