Restone: Plazma değil, Optimium varyantı

Yazar: Faust, geek web3***

Son zamanlarda, Redstone adlı bir proje sıcak bir konu haline geldi. **Lattice ekibi tarafından başlatılan bu Layer2 tesisi resmi olarak 15 Kasım'da piyasaya sürüldü ve şimdi test ağında başlatıldı. İlginç bir şekilde, Lattice ekibi "Redstone'un plazmadan ilham alan bir Alt-DA zinciri olduğunu" iddia ediyor.

Redstone'un piyasaya sürülmesinden sadece bir gün önce Vitalik, Ethereum ekosisteminden kaybolan "Plasma" teknik çözümünü kısaca gözden geçirdiği "EVM validiumları için oyunlardan çıkın: Plasma'nın dönüşü" makalesini yayınladı ve Plasma sorununu çözmek için geçerlilik kanıtlarının (ZK Proof ile karıştırılan) tanıtılabileceğine dikkat çekti.

Bu bağlamda, birçok arkadaş Vitalik'in Redstone'a bir platform sağlamak için bu makaleyi yayınladığına inanıyor ve hatta geek Web3 topluluğunda bile bazı insanlar Vitalik'in Redstone'a yatırım yapmadığını söylüyor. Bir önceki söylentide kaynayan "Ethereum Katman 2 tanım anlaşmazlığı" ile birleştiğinde, bir sonraki "Plazma canlanmasının" tetikleneceğine ve Celestia gibi Ethereum ekosistemi dışındaki DA çözümlerinin bastırılabileceğine inanılıyordu, çünkü Plazma'nın DA için katı gereksinimleri yoktur. **

Bununla birlikte, bu makalenin yazarının araştırmasına göre, Redstone, Plazma çözümünün genel çerçevesine uymuyor ve "Plazmadan ilham aldığı" iddiası, Vitalik'in makalesinin ısısını ovma olasılığına sahip, Vitalik'in gerçekten Redstone'u temsil etmek istemesinden ziyade. Ek olarak, Redstone'un DA zorluğu, Metis'in Nisan 2022'de başlattığı Katman 2 projesine benzer, ancak Stateroot'u güncelleme ve DA verilerini yayınlama sırası farklıdır.

Yani gerçek durum, Redstone'u "aşırı yorumlamış" olabilirsiniz. Aşağıda, Plasma'nın nasıl çalıştığını, neden akıllı sözleşmeler ve DeFi için uygun olmadığını ve Redstone'un tam olarak ne olduğunu açıklamak için basit bir akıl yürütme yer almaktadır. **

Plazma: Veri saklama saldırısı durumunda acil para çekme

Plazmanın tarihi, Ethereum kullanıcılarının işlem talebinin patladığı ve düşük TPS'li ETH'nin bunaldığı 2017'deki Ethereum IC0 patlamasına kadar uzanabilir. Bu noktada, Plasma'nın "dünyadaki neredeyse tüm finansal senaryoları" işleyebilecek bir katman-2 ölçeklendirme şeması öneren en eski teorik sürümü yayınlandı.

Basitçe ifade etmek gerekirse, Plasma, yalnızca Katman 2 blok başlığını/Merkle kökünü Katman 1'e yayınlayan ve verilerin blok başlığı/Merkle kökü (DA verileri) dışında kalan kısmı yalnızca zincir dışı olarak yayınlanan bir ölçeklendirme çözümüdür. **Plazma sıralayıcı/Operatör tarafından L1'de yayınlanan Merkle Kökü geçersiz bir işlemle (örneğin, bir dijital imza hatası) ilişkiliyse, kullanıcı, sıralayıcı tarafından gönderilen Kökün geçersiz bir işlemle ilişkili olduğunu kanıtlamak için bir sahtekarlık sertifikası gönderebilir.

Sorun şu ki, sahtekarlık kanıtları yayınlamak için DA verilerinin saklanmadığından emin olmak gerekir, ancak Plasma'nın DA katmanı için katı gereksinimleri yoktur ve kullanıcıların veya L2 düğümlerinin veri alabileceğini garanti edemez. Sıralayıcı, belirli bir zamanda bir veri saklama saldırısı (veri kullanılabilirliği sorunu olarak da bilinir) başlatırsa ve yalnızca yeni bir blok başlığı/Merkle kökü yayınlar, ancak ilgili blok gövdesini yayınlamazsa, blok başlığının/kökünün geçerli olup olmadığını doğrulamayı imkansız hale getirirse, kullanıcı sıralayıcıyı yalnızca "umutsuz" olarak varsayılan olarak kullanabilir ve "Oyundan Çık" adı verilen bir acil çıkış mekanizması aracılığıyla varlıkları Katman 2'den Katman 1'e çekebilir.

Bu adım, kullanıcının L2'de "Varlık Kanıtı" olarak adlandırabileceğimiz karşılık gelen miktarda varlığa sahip olduğunu kanıtlamak için bir Merkle Kanıtı göndermesini gerektirir. İlginç bir şekilde, Plasma'nın Çıkış Oyunu, ZK Rollup'ın Kaçış Bölmesi moduyla aynı değildir, burada ZK Rollup kullanıcılarının en son geçerli Stateroot'a karşılık gelen bir Merkle Kanıtı göndermesi gerekirken, Plasma kullanıcıları uzun zaman önce bir Merkle Köküne karşılık gelen bir Kanıt gönderebilir.

Neden bu şekilde tasarlandı? Sadece ZK Rollup tarafından sunulan Stateroot, Katman 1'deki sözleşme tarafından (geçerlilik kanıtının geçerli olup olmadığını belirlemek için) derhal yargıya yatırılacaktır. Yeni gönderilen Stateroot geçerli ve meşruysa, kullanıcı geçerli Stateroot'a karşılık gelen Merkle Kanıtını varlık kanıtı olarak sunmalıdır.

Bununla birlikte, Plasma sequencer tarafından gönderilen Merkle Root, Layer1 sözleşmesi geçerli olup olmadığına karar veremez ve yalnızca L2 düğümünün geçersiz Root'u hariç tutmak için inisiyatif almasına izin verebilir, bu nedenle Plasma ve Zk Rollup'ın çalışmasını çok farklı kılan bir meydan okuma mekanizması olacaktır. **

Sıralayıcının geçersiz bir Merkle Kökü 101 yayınladığını ve L2 düğümünün kök 101'in geçersiz olduğunu kanıtlayamaması için bir veri saklama saldırısı başlattığını varsayalım, ardından kullanıcı kök 100 veya daha önceki köke karşılık gelen merkle Kanıtını gönderebilir ve varlıklarını geri çekebilir.

Elbette burada çözülmesi gereken bir sorun var, yani bir kullanıcı root 30 veya öncesine karşılık gelen bir varlık sertifikası sunabilir ve varlığı Katman 1'e çekme talebinde bulunabilir ancak bu kişinin varlık durumu root 30'un yayınlanmasından sonra değişebilir. Başka bir deyişle, tipik bir çift harcama saldırısı/çift harcama olan güncel olmayan bir varlık kanıtı sunar. **

Buna cevaben, Plasma, para çekme talebinde bulunan bir kullanıcı tarafından gönderilen "eşitlik kanıtının" eski olduğunu belirterek, herkesin yukarıdaki durumlar için bir dolandırıcılık sertifikası sunmasına izin verir. Bu "herkes bir başkasının para çekme beyanına itiraz edebilir" özelliğini tanıtarak, Plasma'nın ZK Rollup gibi acil para çekme taleplerini ele almasına gerek kalmaz.

Ancak yine de, sıralayıcının, yabancıların hilelerine meydan okumasını imkansız kılan bir veri saklama saldırısı başlatmadan önce başka birinin varlıklarını kendi L2 hesabına aktarma olasılığı vardır. Bundan sonra, sıralayıcının kendi hesabı, L2'deki varlıklara gerçekten sahip olduğunu iddia eden bir "varlık kanıtı" göndererek acil bir para çekme işlemi başlatır.

Açıkçası, bir geçmiş parçasının olmaması nedeniyle, sıralayıcının varlık kaynağının sorunlu olduğunu doğrudan kanıtlamanın bir yolu yoktur. Plasma MVP gibi Plasma'nın önceki sürümleri bunu dikkate aldı ve bir "para çekme önceliği" buldu. Bir kişi daha önce root'a karşılık gelen bir varlık kanıtı gönderirse, para çekme talebine öncelik verilecektir.

Sıralayıcı, 101 numaralı kökü gönderirken hile yapar ve bir para çekme işlemi başlatırsa, kullanıcı acil bir para çekme işlemi yapmak için 99 numaralı veya daha önceki bir köke karşılık gelen varlıkların kanıtını sunabilir. Açıkçası, sıralayıcı Katman 1'e gönderilen geçmişi kurcalayamadığı sürece, kullanıcının kaçmanın bir yolu vardır.

Ancak Plasma'nın hala ölümcül bir hatası var: Sıralayıcı veri stopajını başlattığı sürece, insanlar varlıkların güvenliğini sağlamak için acil para çekme işlemlerine (Oyundan Çıkış olarak da bilinir) güvenmek zorundadır ve çok sayıda kullanıcı kısa bir süre içinde toplu olarak para çekerse, Katman 1'in kullanımı kolaydır;

Diyelim ki birisi DEX'in LP havuzuna 100 ETH şarj etti ve ardından Plazma sıralayıcısı başarısız oldu veya kötülük yaptı ve insanların acilen para çekmesi gerekiyor, şu anda kullanıcının 100 ETH'si hala DEX sözleşmesi tarafından kontrol ediliyor, şu anda bu varlıklardan Katman 1'e kim bahsetmeli?

Bunu yapmanın en iyi yolu, kullanıcıların önce varlıklarını DEX havuzundan kullanmalarına izin vermek ve ardından kullanıcıların paralarını L1'e çekmelerine izin vermektir, ancak sorun şu ki, Plazma sıralayıcı arızalı/bozulabilir ve kullanıcılar varlıklarını kullanamıyor. Ancak, DEX sözleşmesinin sahibinin, sözleşme tarafından kontrol edilen varlıkları L1'e getirmesine izin versek, bu da açıkça sözleşme sahibine varlıkların mülkiyetini verseydi ve bu varlıkları istediği zaman L1'e yükseltip kaçabilseydi korkunç olmaz mıydı?

Sonuç olarak, Defi sözleşmeleri tarafından desteklenen bu "kamu mülkü" ile nasıl başa çıkılacağı büyük bir gök gürültüsüdür. **Sosyal konsensüsü takip ederseniz, Katman 1'de Katman 2'deki defi sözleşmesini yansıtan bir ayna sözleşmesini yeniden inşa etmek sorun değil gibi görünüyor, ancak bu oldukça büyük bir sorun yaratacak, fırsat maliyetini artıracak ve ayna sözleşmesinin elden çıkarılmasına kimin oy vereceği de büyük bir sorun olacak. Bu aslında Xiangma'nın daha önce bir röportajda bahsettiği kamu gücünün dağıtımı sorununu içeriyor "Yüksek performanslı kamu zincirlerinin yeni şeyler yapması zordur ve akıllı sözleşmeler güç dağıtımını içerir.

Elbette Vitalik, "EVM validiumları için oyunlardan çıkın: Plasma'nın geri dönüşü" başlıklı son makalesinde de buna dikkat çekiyor ve bunu Plasma'yı akıllı sözleşmelere karşı düşmanca yapan faktörlerden biri olarak vurguluyor. **Geçmişte, Plasma MVP ve Plasma Cash gibi iyi bilinen Plasma varyantları, Ethereum'un hesap adresi modelini değiştirmek için UTXO veya benzer modeller kullandı ve akıllı sözleşmeleri desteklemiyordu, bu da yukarıda bahsedilen "varlık sahipliği dağıtımı" sorununu önleyebilir, ancak her UTXO'nun mülkiyeti kullanıcıya aittir, ancak UTXO'nun kendisinin birçok kusuru vardır ve akıllı sözleşmelere uygun değildir. Bu nedenle, Plasma çözümü basit ödeme veya emir defteri değişimleri için en uygun çözümdür.

Daha sonra, ZK Rollup'ın popülaritesi ile Plasma'nın kendisi de tarih sahnesinden çekildi, çünkü Rollup'ın Plasma'nın veri tutma sorunu yoktu. ZK Rollup'ın sıralayıcısı bir veri stopaj saldırısı başlatırsa ve Stateroot'u DA verileri olmadan yalnızca ETH zincirine gönderirse, bu kök geçersiz olarak değerlendirilecek ve L1'deki Doğrulayıcı sözleşmesi tarafından reddedilecektir. Bu nedenle, ZK Rollup'ın yasal Stateroot'una karşılık gelen DA verileri ETH zincirinde mevcut olmalıdır. Bu sayede "sadece blok başlığını veya merkle kökünü yayınla, karşılık gelen blok gövdesini yayınlama" gibi bir durum söz konusu değildir, yani veri kullanılabilirliği sorunu/veri saklama saldırısı çözülebilir. **

Aynı zamanda, Rollup'ların geçmiş DA verileri Ethereum'da mevcuttur ve herkes ETH zincirinin geçmişi boyunca Katman 2 düğümlerini başlatabilir, bu da merkezi olmayan ve hatta izinsiz sıralayıcı şemalarının zorluğunu büyük ölçüde azaltır. Buna karşılık, Plasma'nın DA için katı gereksinimleri yoktur ve merkezi olmayan bir sıralayıcı uygulamak daha zordur (değiştirilebilir bir merkezi olmayan sıralayıcı uygulamak için önce tüm L2 düğümlerinin aynı bloğu tanıdığından emin olmalısınız, bu da DA uygulaması için gereksinimleri ortaya koyar).

Ek olarak, ZK Rollup'ın sıralayıcısı geçersiz işlemleri Katman 2 bloğuna dahil etmeye çalışırsa, geçerlilik kanıtı ilkesi ile garanti edilen başarılı olmaz.

Günün sonunda, ZK Rollup sıralayıcı, Plasma'dan çok daha küçük bir hareket alanına sahiptir - en iyi ihtimalle Stateroot güncellemelerini durdurabilir, UX düzeyinde kesinti süresine eşdeğer olabilir veya halk arasında işlem sansürü olarak bilinen belirli kullanıcı isteklerini reddedebilir. Aynı zamanda, sıralayıcı Toplama şemasında başarısız olursa, diğer düğümlerin onu değiştirmesi daha kolay olacaktır. **İdeal olarak, Plasma'da Çıkış oyun modunu tetikleme olasılığı 0'a düşürülebilir (ZK Rollup'ta kaçış kapsülü olarak adlandırılır).

(L2BEAT'teki Teklif Eden Hatası sütunu, her bir L2 çözümünün sıralayıcı hatalarıyla nasıl başa çıkabileceğini gösterir, Kendi Kendine Poz genellikle şu anda kapalı olan sıralayıcının yerini alabilecek diğer düğümleri ifade eder)**

Bugün, Ethereum ekosisteminde hala Plasma rotasına bağlı kalan neredeyse hiçbir ekip yok ve neredeyse tüm Plasma projeleri ölü doğmuş durumda.

(Vitalik, ZK Rollup'ın neden Plasma'dan daha üstün olduğunu açıklıyor, izinsiz sıralayıcı çalışması ve DA sorunlarından bahsediyor)

Redstone nedir: Plazma değil, Optimium'un bir çeşididir****

Yukarıda Plasma'yı ve neden Rollup ile değiştirildiğini kısaca açıkladık ve Redstone'a gelince, onunla Plasma arasındaki farkı da görmüş olmalısınız: Redstone, veri saklama saldırıları sorununu çözebilir,** Örneğin, hemen yeni bir durum kökü yayınlamaz, ancak önce orijinal DA verilerini zincir dışı yayınlar ve ardından ETH zincirindeki DA verilerinin veri karmasını ilişkili bir kimlik bilgisi taahhüdü olarak yayınlar ve bu veri karmasına karşılık gelen tüm verileri zincir dışı olarak yayınladığını söyler.

(Redstone'un veri saklama saldırılarını önlemeye yönelik kendi planına ilişkin resmi açıklaması)**

Herkes Redstone'un sıralayıcısına, bu veri karması için zincir dışı ham verileri yayınlamadığını söylemesi için meydan okuyabilir. Bu noktada, sıralayıcının, sorgulayıcının zorluğunu karşılamak için zincir üzerindeki veri karmasına karşılık gelen verileri yayınlaması gerekir. **Sıralayıcı, itiraz edildikten sonra ETH zincirindeki verileri zamanında yayınlamazsa, daha önce yayınlanmış veri karması/taahhüdü geçersiz sayılacaktır.

Sıralayıcı, sorgulayıcının isteğine zamanında yanıt verirse, sorgulayıcı, veri karmasına karşılık gelen orijinal DA verilerini zamanında elde edebilir. Sonunda, tüm L2 düğümleri, veri saklama saldırıları sorununu çözmek için gerekli DA verilerini elde edebilir. Elbette, kötü niyetli meydan okuyanların sequencer'a ücretsiz olarak meydan okumasını ve ikincisinin zarara uğramasına neden olmasını önlemek için, meydan okuyanın kendisinin ETH zincirinde ham DA verilerini yayınlayan sequencer'ın maliyetine yaklaşık olarak eşit bir ücret ödemesi gerekir.

Son olarak, veri karması için sınama süresi sona erdiğinde, sıralayıcı, veri karmasına karşılık gelen DA verilerinde yer alan işlem dizisini yürüttükten sonra elde edilen kök olan ilgili durum kökünü yayınlayacaktır. Bu noktada, L2 düğümü bu geçersiz köklere meydan okumak için sahtekarlık kanıtı sistemini kullanabilir. Sıralayıcı, bir veri karmasına itiraz edildikten sonra karşılık gelen orijinal DA verilerini zamanında yayınlamazsa, veri karmasına karşılık gelen durum kökü daha sonra yayımlansa bile sıralayıcı varsayılan olarak geçersiz olacaktır.

Redstone önce DA verilerini yayınladığından ve ardından karşılık gelen geçerli Stateroot'u yayınladığından, veri saklama saldırıları sorununu doğrudan çözer (sıralayıcı yalnızca kök yayınlar, ancak DA verilerini yayınlamaz).

Açıkçası, bu model sıradan Optimium'dan (Arbitrum Nova gibi Ethereum'suz DA'nın OP Rollup'ı) farklıdır, Optimium genellikle veri kullanılabilirliğini sağlamak için zincir dışı DAC komitelerine güvenir, DAC arada bir zincire bir multi-Sig txn gönderir ve Katman 1'deki Rollup sözleşmesi, multi-Sig txn'yi aldıktan sonra en son DA verisi grubunu zincir dışı yayınlayan sıralayıcıya varsayılan olarak geçecektir.

(图源:L2beat)

Metis ve Arbitrum Nova, Stateroot ve datahash'i aynı anda gönderirken, birisi sequencer'ın DA verilerini sakladığını düşünürse, bir meydan okuma başlatmaya çalışacak ve sequencer, datahash'e karşılık gelen DA verilerini zincire gönderecektir.

Bu nedenle, Redstone ve Metis arasındaki temel fark şudur: ilki önce veri karmasını yayınlar ve durum kökünü yayınlamadan önce DA sorgulama süresinin bitmesini beklerken, Metis hem durum kökünü hem de veri karmasını yayınlar ve birisi bir sorgulama başlatırsa, DA verileri zincire yüklenir. Açıkçası, Redstone'un çözümü daha güvenlidir, çünkü Metis'in şemasına göre, sıralayıcı, meydan okuyanın DA verileri talebine yanıt vermezse, veri saklama saldırısı sorunu hızlı bir şekilde çözülemez ve acil para çekme işlemlerine ve sosyal fikir birliğine güvenmenin tek yolu, diğer düğümlerin mevcut sıralayıcıyı devralmasına izin vermektir;

Bununla birlikte, Redstone söz konusu olduğunda, sıralayıcı veri stopajına girerse, onun tarafından serbest bırakılan durum kökü doğrudan geçersiz kabul edilir, bu nedenle durum kökü ve DA verileri bağlanır, bu da Redstone'un Rollup'a daha yakın DA garantileri elde etmesine olanak tanır, bu da esasen Arbitrum Nova ve Metis'ten daha üstün bir Optimium varyantıdır.

View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Reward
  • Comment
  • Repost
  • Share
Comment
0/400
No comments
Trade Crypto Anywhere Anytime
qrCode
Scan to download Gate App
Community
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)