Daha dün şok edici bir olay meydana geldi: Metamask'ın ana şirketi Consensys tarafından geliştirilen Ethereum Katman 2 çözüm olan Linea proaktif olarak kapatıldı. Verilen resmi sebep, Velocore hack olayının etkisini azaltmaktı. Bu olay kaçınılmaz olarak, bilgisayar korsanlığı kayıplarını en aza indirmek için BSC zincirinin (BNB Chain) resmi koordinasyon altında kapatıldığı önceki bir vakayı akla getiriyor. Bu olaylar genellikle insanların Web3'ün savunduğu merkezi olmayan değerleri sorgulamasına neden olur.

Yukarıda bahsedilen olayların arkasındaki temel neden, altyapının kusurluluğunda, özellikle de ademi merkeziyetçilik eksikliğinde yatmaktadır. Bir blok zinciri yeterince merkeziyetsiz olsaydı, bu kadar kolay kapanamazdı. Ethereum Katman 2'nin benzersiz yapısı nedeniyle, çoğu Katman 2 çözümü merkezi sıralayıcılara dayanır. Son yıllarda merkezi olmayan sıralayıcılar hakkındaki artan söyleme rağmen, Katman 2 amacı ve yapısı göz önüne alındığında, Katman 2 sıralayıcıların yüksek düzeyde ademi merkeziyetçilik elde etme olasılığının düşük olduğunu varsayabiliriz. Aslında, BSC zincirinden daha az merkezi olmayan olabilirler. Bu durumda ne yapılabilir? Katman 2 için, merkezi olmayan sıralayıcıların en acil riskleri, sansür direnişi ve canlılık eksikliğidir. İşlemleri işleyen yalnızca birkaç kuruluş (sıralayıcılar) varsa, size hizmet edip etmeme konusunda mutlak yetkiye sahiptirler: işlemlerinizi istedikleri zaman reddedebilir ve sizi rücu etmeden bırakabilirler. Katman 2'da sansür direnişi konunun ele alınması açıkça önemli bir konudur. Son birkaç yılda, çeşitli Ethereum Katman 2 çözümler bu sorunun üstesinden gelmek için farklı yaklaşımlar önerdi. Örneğin, Loopring, Degate ve StarkEx, zorla geri çekilme ve kaçış kapısı işlevlerini tanıtırken, Arbitrum ve diğer Optimistic Rollup'lar, Force Inclusion özelliklerini uyguladı. Bu mekanizmalar, kullanıcı işlemlerinin keyfi olarak reddedilmesini önlemek için sıralayıcılara kontroller uygulayabilir. Bugünkü makalede, Taipei Ethereum Derneği'nden NIC Lin, dört büyük Rollup'ın sansüre dayanıklı işlem özelliklerini deneyerek ve iş akışı ve operasyonel yöntemlere odaklanarak Force Inclusion mekanizmasının derinlemesine bir analizini sağlayarak ilk elden deneyimini paylaşıyor. Bu analiz özellikle Ethereum topluluğu ve büyük varlık sahipleri için değerlidir.

İşlem Sansürü ve Zorla Dahil Etme

İşlemlerde sansür DİRENÇ herhangi bir blok zinciri için çok önemlidir. Bir blok zinciri, kullanıcı işlemlerini keyfi olarak sansürleyebiliyor ve reddedebiliyorsa, bunun bir Web2 sunucusundan hiçbir farkı yoktur. Ethereum'nin işlem sansür direnişi şu anda çok sayıda doğrulayıcılar ile sağlanmaktadır. Birisi Bob'un işlemini sansürlemek ve blok zincirine dahil edilmesini engellemek isterse, ya ağın doğrulayıcılar çoğuna rüşvet vermesi ya da Bob'unkinden daha yüksek ücretlere sahip çöp işlemlerle ağa spam göndermesi ve böylece blok alanını işgal etmesi gerekir. Her iki yöntem de son derece maliyetlidir.

Not: Ethereum'in mevcut Proposer-Builder Separation (PBS) mimarisinde, işlemleri sansürlemenin maliyeti önemli ölçüde azaltılmıştır. Örneğin, OFAC'ın Tornado Cash işlemlerine yönelik sansürüne uyan blokların oranına bakabilirsiniz. Mevcut sansür direnişi, OFAC ve diğer devlet kurumlarının yetki alanı dışında kalan bağımsız doğrulayıcılar ve aktarıcılara dayanmaktadır.

Peki ya Rollup'lar? Toplamalar, güvenliği sağlamak için çok sayıda doğrulayıcılar gerektirmez. Bir Rollup, blok üreten yalnızca bir merkezi varlığa (Sequencer) sahip olsa bile, Katman 1 (L1) kadar güvenli kalır. Ancak güvenlik ve sansür direnişi iki farklı konudur. Bir Rollup, Ethereum kadar güvenli olsa da, yalnızca tek bir merkezi sıralayıcıya sahipse, herhangi bir kullanıcının işlemini sansürleyebilir.

Sequencer, bir kullanıcının işlemini gerçekleştirmeyi reddedebilir, bu da kullanıcının fonlarının kilitlenmesine ve Toplamadan ayrılamamasına neden olabilir.

Force Inclusion mekanizması

Rollup'ların çok sayıda merkezi olmayan sıralayıcıya sahip olmasını gerektirmek yerine, Katman 1'in (L1) sansür direnişi doğrudan yararlanmak daha etkilidir:

Sıralayıcının işlem verilerini paketlemesi ve L1'deki Rollup sözleşmesine göndermesi gerektiğinden, sözleşmeye kullanıcıların işlemlerini Rollup sözleşmesine kendilerinin eklemesine olanak tanıyan bir özellik ekleyebiliriz. Bu mekanizma "Zorla Dahil Etme" olarak bilinir. Sıralayıcı long kullanıcıları L1 düzeyinde sansürleyemediği gibi, kullanıcıların L1'de zorla işlem eklemesini de engelleyemez. Bu şekilde, Toplama L1'in sansür direnişi devralabilir.

Sequencer, kullanıcının L1 işlemlerini yüksek bir maliyet ödemeden inceleyemez

Zorunlu İşlemler Nasıl Uygulanmalıdır?

İşlemlerin Zorla Dahil Etme yoluyla doğrudan Toplama sözleşmesine yazılmasına izin verilirse (yani hemen yürürlüğe girerlerse), Toplamanın durumu anında değişecektir. Örneğin, Bob, Carol'a 1000 DAI aktaran bir işlem eklemek için Dahil Etmeye Zorla mekanizmasını kullanırsa ve işlem hemen yürürlüğe girerse, güncellenmiş durumda Bob'un bakiyesi 1000 DAI azalırken, Carol'ın bakiyesi 1000 DAI artar.

Dahil Etmeyi Zorla, işlemlerin doğrudan Rollup sözleşmesine yazılmasına ve hemen yürürlüğe girmesine izin verirse, Rollup'ın durumu anında değişir. Sıralayıcı aynı anda off-chain işlemleri topluyor ve bir sonraki toplu işlemi Toplama sözleşmesine göndermeye hazırlanıyorsa, Bob'un zorla eklenen ve hemen yürürlüğe giren işlemi tarafından kesintiye uğrayabilir. Bu sorunu önlemek için, Rollup'lar genellikle Zorla Dahil etme işlemlerinin hemen yürürlüğe girmesine izin vermez. Bunun yerine, kullanıcılar başlangıçta işlemlerini L1'de bir "hazırlık" durumuna girdikleri bir bekleme kuyruğuna eklerler. Sıralayıcı, Toplama sözleşmesine gönderilecek off-chain işlemleri paketlediğinde, bu kuyruğa alınmış işlemlerin dahil edilip edilmeyeceğini seçebilir. Sıralayıcı, "hazırlık" durumundaki işlemleri sürekli olarak yok sayarsa, pencere dönemi sona erdiğinde, kullanıcılar bu işlemleri zorla Toplama sözleşmesine ekleyebilir. Sıralayıcı, bekleme kuyruğundaki işlemleri ne zaman "tesadüfen dahil edeceğine" karar verebilir, ancak yine de bunları işlemeyi reddedebilir. Sıralayıcı sürekli olarak reddederse, belirli bir süre sonra, herhangi biri işlemleri Toplama sözleşmesine zorla eklemek için Dahil Etmeye Zorla işlevini kullanabilir. Daha sonra, Force Inclusion mekanizmasının uygulanmasını öne çıkan dört Rollup'ta tanıtacağız: Optimism, Arbitrum, StarkNet ve zkSync.

Sıralayıcı, bekleme kuyruğundan işlemlerin ne zaman alınacağını seçebilir.

Sıralayıcılar yine de bekleme kuyruğundaki işlemleri işlemeyi reddedebilir.

Sıralayıcı sürekli olarak işlemleri işlemeyi reddederse, belirli bir süre sonra herkes işlemleri Toplama sözleşmesine zorla eklemek için Dahil Etmeye Zorla işlevini kullanabilir. Daha sonra, Force Inclusion mekanizmasının öne çıkan dört Rollup'ta nasıl uygulandığını tanıtacağız: Optimism, Arbitrum, StarkNet ve zkSync.

Optimism'in Force Inclusion mekanizması

İlk olarak, Optimism'in Para Yatırma sürecini tartışalım. Bu Para Yatırma işlemi, yalnızca Optimism'e para aktarmayı değil, aynı zamanda "L2'ye kullanıcı mesajları" göndermeyi de içerir. Bir L2 düğümü yeni yatırılan bir mesaj aldığında, mesajı bir L2 işlemine dönüştürür ve yürüterek belirtilen alıcıya teslim eder.

L1'den L2'ye Yatırılan Kullanıcı Mesajları

L1CrossDomainMessenger Sözleşmesi

Bir kullanıcı tokenleri Optimism'e yatırma ETH veya ERC-20 etmek istediğinde, bir ön uç web sayfası aracılığıyla L1'deki L1StandardBridge sözleşmesiyle etkileşime girerek yatırma tutarı ve bu varlıkları alacak L2 adresini belirtir. L1StandardBridge sözleşmesi daha sonra iletiyi, L1 ve L2 arasında birincil iletişim köprü görevi gören L1CrossDomainMessenger sözleşmesine iletir. L1StandardBridge, L2'deki L2StandardBridge ile etkileşim kurmak için bu iletişim bileşenini kullanır ve L2'de kimlerin token mint edebileceğini veya L1'den token'ların kilidini açabileceğini belirler. L1 ve L2 arasında birlikte çalışan ve durumları eşitleyen sözleşmeler oluşturması gereken geliştiriciler, bunları L1CrossDomainMessenger sözleşmesinin üzerine inşa edebilir.

CrossDomainMessenger Sözleşmesi Aracılığıyla L1'den L2'ye İletilen Kullanıcı Mesajları

Not: Bu makaledeki bazı görsellerde CrossDomainMessenger, CrossChainMessenger olarak yazılmıştır.

OptimismPortal Sözleşmesi

L1CrossDomainMessenger sözleşmesi daha sonra iletiyi en alt katman olan OptimismPortal sözleşmesine iletir. İletiyi işledikten sonra OptimismPortal sözleşmesi, "gönderen", "alıcı" ve diğer ilgili yürütme ayrıntıları gibi parametreleri içeren TransactionDeposited adlı bir olay yayar. L2'deki Optimism düğümleri, OptimismPortal sözleşmesinden bu TransactionDeposited olayını dinler ve olayın parametrelerini bir L2 işlemine dönüştürür. Bu işlemi başlatan, olayda belirtilen "gönderen" olacak, alıcı, olayda belirtilen "alıcı" olacak ve diğer işlem detayları da olayın parametrelerinden türetilecektir.

L2 düğümleri, OptimismPortal tarafından yayılan İşlem Yatırıldı olayının parametrelerini bir L2 işlemine dönüştürür.

Örneğin, bir kullanıcı L1StandardBridge sözleşmesi aracılığıyla 0,01 ETH yatırdığında, mesaj ve ETH OptimismPortal sözleşmesine iletilir (adres 0xbEb5... 06Ed). Birkaç dakika sonra bu bir L2 işlemine dönüştürülür: ileti gönderen L1CrossDomainMessenger sözleşmesidir, alıcı L2'deki L2CrossDomainMessenger sözleşmesidir ve ileti içeriği L1StandardBridge'in Bob'dan 0,01 ETH yatırma aldığını gösterir. Bu daha sonra L2StandardBridge için mintleme 0,01 ETH gibi ek işlemleri tetikler ve daha sonra Bob'a aktarır.

Nasıl Tetiklenir?

Bir işlemi Optimism'in Rollup sözleşmesine zorla dahil etmek istiyorsanız, amacınız "L2'deki L2 adresinizden başlatılan ve yürütülen" bir işlemin başarıyla yürütülebilmesini sağlamaktır. Bunu başarmak için, L2 adresinizi kullanarak mesajı doğrudan OptimismPortal sözleşmesine göndermelisiniz (OptimismPortal sözleşmesinin aslında L1'de olduğunu, ancak OP adres biçiminin L1 adres biçimiyle eşleştiğini unutmayın, bu nedenle bu sözleşmeyi L2 hesap'nizle aynı adrese sahip bir L1 hesap kullanarak çağırabilirsiniz). Bu sözleşme tarafından yayılan İşlem Yatırıldı olayından türetilen L2 işleminin "göndericisi" daha sonra L2 hesap'niz olacaktır ve işlem formatı standart bir L2 işlemiyle tutarlı olacaktır.

İşlem
Yatırıldı olayından türetilen L2 işleminde, Bob'un kendisi başlatıcı olacaktır; alıcı Uniswap sözleşmesi olacaktır ve Bob'un L2 işlemini kendisi başlatıyormuş gibi belirtilen ETH içerecektir.

Optimism'in Force Inclusion işlevini kullanmak için, doğrudan OptimismPortal sözleşmesinin depositTransaction işlevini çağırmanız ve L2'de yürütmek istediğiniz işlemin parametrelerini girmeniz gerekir. Basit bir Kuvvet İçerme deneyi yaptım. Bu işlemin amacı, adresimi kullanarak L2'de kendi kendine transfer yapmaktı (0xeDc1... 6909) ve "dahil etmeye zorla" yazan bir mesaj ekleyin. Bu, OptimismPortal sözleşmesi aracılığıyla depositTransaction fonksiyonunu çağırarak gerçekleştirdiğim L1 işlemidir. Yaydığı İşlem Yatırıldı olayından da görebileceğiniz gibi, hem gönderici hem de alıcı benim.

Opak Veri sütununda kalan değerler ETH "depositTransaction işlevini çağıran kişinin ne kadar eklediği", "L2 işlem başlatıcısının alıcıya ne kadar ETH göndermek istediği", "L2 işlemi GasLimit" ve "L2 alıcısı için veriler" gibi bilgileri kodlar. Bu bilgilerin kodunu çözdükten sonra, aşağıdaki ayrıntıları alacaksınız: "depositTransaction'ı çağıran kişinin ne kadar ETH eklediği": 0, çünkü L1'den L2'ye ETH yatırmıyorum; "L2 işlem başlatıcısının alıcıya ne kadar ETH göndermek istediği": 5566 (Wei); "L2 işlemi GasLimit": 50000; "L2 alıcısı için veri": 0x666f72636520696e636c7573696f6e, "kuvvet ekleme" dizesinin onaltılık kodlamasıdır. Kısa bir süre sonra, dönüştürülen L2 işlemi ortaya çıktı: 5566 Wei kendime aktardığım bir L2 işlemi, Veri alanı "zorla dahil etme" dizesini içeriyor. Ek olarak, Diğer Öznitelikler bölümünün sondan ikinci satırında, TxnType (işlem türü) sistem işlemi 126 (Sistem) olarak gösterilir ve bu işlemin L2'de benim tarafımdan başlatılmadığını, ancak L1 işleminin Yatırıldı olayından dönüştürüldüğünü gösterir.

Dönüştürülen L2 işlemi

Force Inclusion aracılığıyla bir L2 sözleşmesini çağırmak ve farklı Veriler göndermek istiyorsanız, depositTransaction işlevindeki parametreleri doldurmanız yeterlidir. depositTransaction işlevini çağırırken L2 hesap adresinizle aynı L1 adresini kullanmayı unutmayın. Bu şekilde, Yatırılan Etkinlik bir L2 işlemine dönüştürüldüğünde, başlatıcı L2 hesap olacaktır. Sıralayıcı Penceresi İşlem Yatırıldı olayını bir L2 işlemine dönüştüren İyimserlik L2 düğümü aslında Sıralayıcı'dır. Bu, işlem sıralamasını içerdiğinden, olayın ne zaman bir L2 işlemine dönüştürüleceğine yalnızca Sıralayıcı karar verebilir. Sequencer, TransactionDeposited olayını dinlediğinde, olayı hemen bir L2 işlemine dönüştürmez; Gecikme olabilir. Bu gecikmenin maksimum süresine Sıralayıcı Penceresi adı verilir. Şu anda, Optimism ana ağındaki Sıralayıcı Penceresi 24 saattir. Bu, bir kullanıcı L1'den para yatırdığında veya bir işlem için Zorla Dahil Etme'yi kullandığında, en kötü senaryoda, 24 saat sonra L2 işlem geçmişine dahil edileceği anlamına gelir.

Arbitrum'un Kuvvet Dahil Etme Mekanizması

İyimserlikte, L1 yatırma işlemi bir İşlem Yatırıldı olayını tetikler ve ardından Sequencer'ın işlemi dahil etmesini beklemek yeterlidir. Bununla birlikte, Arbitrum'da, L1'deki işlemler (L2'ye para yatırmak veya mesaj göndermek gibi), yalnızca bir olay yaymak yerine L1'deki bir kuyrukta saklanır. Sıralayıcı, kuyruğa alınan bu işlemleri L2 işlem geçmişine dahil etmek için belirli bir süreye sahiptir. Sequencer bu süre içinde bunu yapamazsa, Sequencer adına dahil etme işlemini tamamlamak için herkes devreye girebilir.

Arbitrum, bir L1 sözleşmesinde bir Kuyruk tutar. Sıralayıcı, Kuyruktaki işlemleri belirli bir süre içinde işleyemezse, herkes bu işlemleri zorla L2 işlem geçmişine dahil edebilir. Arbitrum'un tasarımında, L1'deki para yatırma işlemleri gibi işlemler, adından da anlaşılacağı gibi, bu işlemlerin yürürlüğe girmeden önce erteleneceği Gecikmeli Gelen Kutusu sözleşmesinden geçmelidir. Başka bir sözleşme olan Sequencer Gelen Kutusu, Sequencer'ın L2 işlemlerini doğrudan L1'e yüklediği yerdir. Sequencer, L2 işlemlerini her yüklediğinde, Gecikmeli Gelen Kutusu'ndan bekleyen bazı işlemleri de alabilir ve bunları işlem geçmişine dahil edebilir.

Sıralayıcı yeni işlemler yazdığında, DelayedInbox'taki işlemleri de içerebilir.

Karmaşık tasarım ve referans malzeme eksikliği

Arbitrum'un Sequencer ve Force Inclusion ile ilgili resmi belgelerine bakarsanız, bazı parametre ve işlev adlarıyla birlikte Force Inclusion'ın nasıl çalıştığına dair genel bir açıklama bulacaksınız: Kullanıcılar ilk olarak DelayedInbox sözleşmesinde sendUnsignedTransaction işlevini çağırır. Sequencer bunu yaklaşık 24 saat içinde eklemezse, kullanıcılar SequencerInbox sözleşmesinde forceInclusion işlevini çağırabilir. Ancak, resmi belgeler bu işlevlere bağlantılar sağlamaz, bu nedenle bunları sözleşme kodunda kendiniz aramanız gerekir. sendUnsignedTransaction fonksiyonunu bulduğunuzda, nonce değerini ve maxFeePerGas değerini kendiniz doldurmanız gerektiğini fark edersiniz. Kimin nonce? Hangi ağın maxFeePerGas'ı? Nasıl doğru bir şekilde doldurmalısınız? Referans belgesi yok, NatSpec bile yok. Arbitrum sözleşmesinde de birçok benzer işlev bulacaksınız: sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction. Bu işlevler arasındaki farkları, bunların nasıl kullanılacağını veya parametrelerin nasıl doldurulacağını açıklayan hiçbir belge yoktur, NatSpec bile.

Doğru kullanımı bulmayı umarak parametreleri doldurmayı ve işlemi deneme yanılma yaklaşımıyla göndermeyi denersiniz. Ancak, tüm bu işlevlerin L1 adresinize Aliasing Adres uygulandığını ve L2'deki işlemin Göndericisinin tamamen farklı bir adres olmasına neden olduğunu ve L2 adresinizi devre dışı bıraktığını keşfedersiniz. Daha sonra, yanlışlıkla Arbitrum'un L1'den L2 işlemlerinin nasıl gönderileceğini gösteren komut dosyaları içeren bir Eğitim kitaplığına sahip olduğunu ortaya çıkaran bir Google arama sonucuna rastladınız. Öğreticide daha önce belirtilmeyen bir işlev listelenir: sendL2Message. Şaşırtıcı bir şekilde, gerekli mesaj parametresi aslında bir L2 hesap kullanan imzalı bir L2 işlemidir. "Zorla Dahil Etme yoluyla L2'ye gönderilen mesajın" aslında "imzalı bir L2 işlemi" olduğunu kim bilebilirdi? Ayrıca, bu işlevin ne zaman ve nasıl kullanılacağını açıklayan hiçbir belge veya NatSpec yoktur.

Sonuç: Arbitrum'da manuel olarak zorunlu işlem oluşturmak oldukça karmaşıktır. Resmi Eğitimi takip etmeniz ve Arbitrum SDK'yı kullanmanız önerilir. Diğer Rollup'lardan farklı olarak Arbitrum, net geliştirici belgelerinden ve kod açıklamalarından yoksundur. Birçok işlev, amaçları ve parametreleri için açıklamalardan yoksundur, bu da geliştiricilerin bunları entegre etmek ve kullanmak için beklenenden çok daha fazla zaman harcamasına neden olur. Arbitrum Discord'da da yardım istedim ama tatmin edici cevaplar alamadım. Discord'da sorduğumda, beni yalnızca sendL2Message'a bakmaya yönlendirdiler ve diğer yöntemlerin işlevlerini (sendUnsignedTransaction gibi Force Inclusion belgelerinde belirtilenler dahil), amaçlarını, nasıl kullanılacağını veya ne zaman kullanılacağını açıklamadılar.

StarkNet'in ForceInclusion mekanizması

Ne yazık ki, StarkNet şu anda bir Force Inclusion mekanizmasına sahip değil. Resmi forumda Sansür ve Zorla Dahil Etme'yi tartışan sadece iki makale var. Başarısız işlemlerin kanıtlanamamasının nedeni, StarkNet'in sıfır bilgi ispat sisteminin başarısız bir işlemi kanıtlayamamasıdır, bu nedenle Zorla Dahil Etmeye izin verilemez. Birisi kötü niyetli olarak (veya kasıtsız olarak) başarısız, kanıtlanamaz bir işlem içeriyorsa, StarkNet sıkışıp kalır: çünkü işlem zorla dahil edildiğinde, Kanıtlayıcı başarısız işlemi kanıtlamalıdır, ancak yapamaz. StarkNet'in v0.15.0 sürümünde başarısız işlemleri kanıtlama yeteneğini sunması bekleniyor ve bundan sonra Force Inclusion mekanizması daha fazla uygulanmalıdır.

zkSync'in L1->L2 mesaj iletimi ve Zorla Dahil etme mekanizması, MailBox sözleşmesinin requestL2Transaction işlevi aracılığıyla işlenir. Kullanıcılar L2 adresini, çağrı verilerini, eklenecek ETH miktarını, L2GasLimit değerini ve diğer ayrıntıları belirtir. requestL2Transaction işlevi, bu parametreleri bir L2 işleminde birleştirir ve PriorityQueue'a yerleştirir. Sequencer işlemleri paketleyip L1'e yüklediğinde (commitBatches işlevi aracılığıyla), L2 işlem kayıtlarına dahil etmek için PriorityQueue'dan kaç işlem alınacağını belirtir. Force Inclusion açısından zkSync, imzalı bir L2 işlemi gerektiren Arbitrum'dan ziyade, başlatıcının L2 adresinin (L1 adresiyle aynı) ilgili işlevleri çağırmak ve gerekli ayrıntıları (aranan, çağrı verileri vb.) doldurmak için kullanıldığı Optimism'e benzer. Bununla birlikte, tasarım olarak Arbitrum'a benzer, çünkü her ikisi de L1'de bir kuyruk tutar ve Sıralayıcı, kullanıcılar tarafından doğrudan Kuyruktan gönderilen bekleyen işlemleri alır ve bunları işlem geçmişine yazar.

Bu işlem gibi zkSync'in resmi köprü üzerinden yatırma ETH yaparsanız, MailBox sözleşmesinin requestL2Transaction işlevini çağırır. Bu işlev, Deposit ETH L2 işlemini PriorityQueue'a yerleştirir ve bir NewPriorityRequest olayı yayar. Sözleşme, L2 işlem verilerini bir bayt dizisine kodladığından, kolayca okunamaz. Ancak, bu L1 işleminin parametrelerine bakarsanız, L2 alıcısının aynı zamanda işlemin başlatıcısı olduğunu göreceksiniz (çünkü bu bir yatırma kendi başınadır). Bir süre sonra, Sequencer bu L2 işlemini PriorityQueue'dan çıkarıp işlem geçmişine dahil ettiğinde, kendinize aktardığınız bir L2 işlemine dönüştürülür. Transfer tutarı, L1 Para Yatırma ETH işleminde başlatıcı tarafından eklenen ETH tutar olacaktır. L1 Para Yatırma işleminde, hem başlatan hem de alıcı 0xeDc1... 6909, tutar 0,03 ETH ve çağrı verisi yok. L2'de, 0xeDc1 bir işlem olacak... 6909 kendisine aktarır. İşlem türü (TxnType) 255'tir ve bir sistem işlemini gösterir. Daha sonra, daha önce Optimism'de zorunlu işlem işlevini denediğim gibi, zkSync'in requestL2Transaction işlevini çağırdım ve kendi kendine aktarım işlemini başlattım: hiçbir ETH eklenmedi ve çağrı verileri "zorla dahil etme" dizesinin HEX kodlamasını içeriyordu. Bu daha sonra, "zorla dahil etme" için onaltılık dizeyi içeren çağrı verileriyle kendime aktardığım bir L2 işlemine dönüştürüldü: 0x666f72636520696e636c7573696f6e. Sequencer, PriorityQueue'dan işlemleri alıp işlem geçmişine yazdığında, bunlar karşılık gelen L2 işlemlerine dönüştürülür. Kullanıcılar, requestL2Transaction işlevini kullanarak, L2 alıcılarını, eklenecek ETH miktarını ve çağrı verilerini belirterek, L2 adresleriyle aynı L1 hesap ile L1'deki verileri gönderebilir. Kullanıcılar diğer sözleşmeleri çağırmak veya farklı Veriler eklemek isterlerse, requestL2Transaction işlevindeki parametreleri doldurmaları yeterlidir. Henüz kullanıcılar için zorla dahil etme işlevi yok PriorityQueue'a yerleştirilen bir L2 işlemi, Sequencer tarafından dahil edilmek için hesaplanmış bir bekleme süresine sahip olsa da, zkSync'in mevcut tasarımında kullanıcıların bunu zorlamasına izin veren bir Zorla Dahil Etme işlevi yoktur. Bu, yalnızca kısmi bir çözüm olduğu anlamına gelir. "Dahil edilmek için bir bekleme süresi" olsa da, sonuçta Sequencer'ın onu dahil etmeye karar verip vermediğine bağlıdır: Sequencer, süre sona erdikten sonra bunu dahil edebilir veya PriorityQueue'dan hiçbir işlemi dahil etmeyebilir. Gelecekte, zkSync, bekleme süresinden sonra Sequencer tarafından dahil edilmemişlerse, kullanıcıların işlemleri zorla L2 işlem geçmişine dahil etmelerine olanak tanıyan işlevler ekleyecektir. Bu gerçekten etkili bir Kuvvet Dahil etme mekanizması olacaktır. Summarize

L1, ağın "güvenliğini" ve "sansür direnişi" sağlamak için çok sayıda doğrulayıcılar dayanır. Bununla birlikte, toplamaların daha zayıf sansür direnişi vardır, çünkü işlemler birkaç veya hatta tek bir Sıralayıcı tarafından yazılır. Bu nedenle, Rollup'lar, kullanıcıların Sequencer'ı atlamasına ve işlemleri geçmişe yazmasına izin vermek, Sequencer'ın sansürünün Rollup'ı kullanılamaz hale getirmesini ve kullanıcıların para çekmesini önlemek için bir Zorla Dahil etme mekanizmasına ihtiyaç duyar. Zorla Dahil Etme, kullanıcıların işlemleri geçmişe zorla yazmasına izin verir, ancak tasarımın "işlemlerin geçmişe hemen eklenip eklenemeyeceğini ve hemen yürürlüğe girip giremeyeceğini" seçmesi gerekir. Hemen etkiye izin verilirse, L2'de bekleyen işlemler L1'den zorla dahil edilen işlemlerden etkilenebileceğinden, Sıralayıcı'yı olumsuz etkiler. Bu nedenle, Rollup'lardaki mevcut Force Inclusion mekanizmaları önce L1'den eklenen işlemleri bekleme durumuna geçirir ve Sequencer'a tepki vermesi ve bu bekleyen işlemlerin dahil edilip edilmeyeceğine karar vermesi için bir zaman penceresi verir. zkSync ve Arbitrum, L2 işlemlerini veya L1'den L2'ye gönderilen mesajları yönetmek için L1'de bir kuyruk tutar. Arbitrum buna DelayedInbox diyor; zkSync buna PriorityQueue adını verir. Bununla birlikte, zkSync'in L2 işlemlerini gönderme yöntemi, mesajların L2 adresi kullanılarak L1'den gönderildiği Optimism'e daha benzer, böylece bir L2 işlemine dönüştürüldüğünde başlatıcı L2 adresidir. Optimism'de L2 işlemleri gönderme işlevine depositTransaction adı verilir; zkSync'te requestL2Transaction olarak adlandırılır. Buna karşılık, Arbitrum tam bir L2 işlemi oluşturur ve imzalar, ardından bunu sendL2Message işlevi aracılığıyla gönderir. L2'de Arbitrum, imzalayanı L2 işleminin başlatıcısı olarak geri yüklemek için imzayı kullanır. StarkNet'in şu anda bir Kuvvet Dahil Etme mekanizması yoktur; zkSync'in yarı uygulanmış bir Force Inclusion mekanizması vardır—bir PriorityQueue'u vardır ve Queue'daki her L2 işleminin bir dahil etme geçerlilik süresi vardır, ancak bu geçerlilik süresi şu anda yalnızca göstermelik bir süredir. Pratikte, Sequencer, PriorityQueue'dan herhangi bir L2 işlemini dahil etmemeyi seçebilir.

Yasal Uyarı:

1. Bu makale şu adresten iletilmiştir: [Geek Web3], orijinal başlık "Teori ve Uygulama: Ethereum Toplamada sansüre dayanıklı işlemler nasıl tetiklenir?", orijinal yazara [NIC Lin, Taipei Ethereum Meetup Başkanı] telif hakkı atfı, yeniden baskıya herhangi bir itirazınız varsa, lütfen iletişime geçin Gate Learn Team, ekip bunu ilgili prosedürlere göre mümkün olan en kısa sürede halledecektir.

2. Yasal Uyarı: Bu makalede ifade edilen görüş ve görüşler yalnızca yazarın kişisel görüşlerini temsil eder ve herhangi bir yatırım tavsiyesi teşkil etmez.

3. Makalenin diğer dil sürümleri Gate Learn ekibi tarafından çevrilmiştir. Gate.io referans göstermeden, çeviri makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.