Son zamanlarda Ethereum Toplamalarının geleceğinin aslında iki ana yaklaşımın (ZK ve İyimser) bir melezi olduğuna ikna oldum. Bu yazıda, tasavvur ettiğim şeyin temel mimarisini açıklamaya çalışacağım ve bunun neden ileriye dönük en iyi yol olduğunu düşündüğümü açıklayacağım.
ZK veya Optimist Toplamaların doğasını tartışmak için fazla zaman harcamayacağım. Bu gönderi, bu şeylerin nasıl çalıştığına dair zaten iyi bir anlayışa sahip olduğunuzu varsayar. Uzman olmanıza gerek yok ama en azından ne olduklarını ve üst düzeyde nasıl çalıştıklarını bilmelisiniz. Size Rollup'ları anlatmaya kalksam bu yazı çok ama çok uzun olur. Sonuç olarak, okumanın tadını çıkarın!
İyimser Toplama ile Başlayın
Hybrid ZK/Optimistic Rollup, Optimism'in Bedrock mimarisine çok benzeyen Optimistic Rollup olarak başladı. Bedrock, Ethereum ("EVM Eşdeğeri") ile maksimum uyumluluğu hedefler ve bunu normal bir Ethereum istemcisiyle neredeyse aynı olan bir yürütme istemcisi çalıştırarak başarır. Bedrock, Ethereum'un yaklaşmakta olan konsensüs/yürütme istemci ayırma modelini kullanır ve EVM'deki varyansı önemli ölçüde azaltır (bazı değişiklikler her zaman gerekli olacaktır, ancak bunu yönetebiliriz). Bunu yazarken, Bedrock Geth farkı +388 -30 taahhüttür.
İyimserlik, herhangi bir iyi Toplama gibi, Ethereum'dan blok/işlem verilerini alır, bu verileri mutabakat istemcisi içinde belirli bir şekilde sıralar ve ardından bu verileri yürütme için L2 yürütme istemcisine besler. Bu mimari, "ideal Toplama" bulmacasının ilk yarısını çözerek bize bir EVM Eşdeğeri L2 veriyor.
Elbette artık Ethereum Optimism içinde neler olup bittiğini kanıtlanabilir bir şekilde nasıl anlatacağımız problemini de çözmemiz gerekiyor. Bu özellik olmadan, sözleşmeler İyimserlik durumuna dayalı kararlar veremez. Bu, kullanıcıların Optimism'e para yatırabilecekleri ancak varlıklarını asla çekemeyecekleri anlamına gelir. Bazı durumlarda tek yönlü bir toplama gerçekten yararlı olabilirken, genel olarak çift yönlü bir toplama daha kullanışlıdır.
Ethereum'a herhangi bir Toplamanın durumunu, bu duruma bir taahhüt vererek ve taahhüdün doğru bir şekilde oluşturulduğunu kanıtlayarak söyleyebiliriz. Bunu söylemenin başka bir yolu da, "Toplama programının" doğru yürütüldüğünü kanıtlıyoruz. ZK ve İyimser Toplamalar arasındaki tek gerçek fark, bu kanıtın biçimidir. ZK Toplamasında, programın doğru şekilde yürütüldüğüne dair açık bir ZK kanıtı vermeniz gerekir. İyimser Toplama'da, vaatler hakkında iddialarda bulunursunuz, ancak açık kanıtlar yoktur. Diğer kullanıcılar iddialarınıza meydan okuyabilir ve sizi sonunda kimin haklı olduğunu anladığınız yinelemeli bir oyun oynamaya zorlayabilir.
Optimistic Rollup meydan okuma oyunu hakkında çok fazla ayrıntıya girmeyeceğim. Bu oyundaki son teknolojinin, programınızı (Geth EVM + Optimism durumundaki bazı uç kısımlar) MIPS gibi basit bir makine mimarisine derlemek olduğunu belirtmekte fayda var. Bunu yapıyoruz çünkü programımız için zincir üstü bir tercüman oluşturmamız gerekiyor ve bir MIPS tercümanı oluşturmak EVM tercümanından çok daha kolay. EVM ayrıca hareketli bir hedeftir (düzenli yükseltme çatallarımız vardır) ve kanıtlamak istediğimiz programları tam olarak kapsamaz (orada EVM olmayan bazı şeyler de vardır).
Basit makine mimariniz için zincir üstü bir yorumlayıcı oluşturduktan ve bazı zincir dışı araçlar oluşturduktan sonra, tamamen işlevsel bir Optimistic Rollup'a sahip olmalısınız.
ZK Toplamasına Dönüştürüldü
Genel olarak, İyimser Toplamaların en azından önümüzdeki birkaç yıl boyunca hakim olacağını düşünüyorum. Bazı insanlar ZK Toplamalarının sonunda İyimser Toplamaları geçeceğini düşünüyor, ancak bence bu yanlış olabilir. Bence bugün Optimistic Toplamaların göreceli basitliği ve esnekliği, bunların zaman içinde ZK Toplamalarına dönüştürülebilecekleri anlamına geliyor. Bunu gerçekleştirecek bir model bulabilirsek, mevcut bir Optimistic sistemine kolayca konuşlandırabileceğiniz ve buna bir günlük çalışma ZK sistemi diyebileceğiniz zaman, daha az esnek, daha kırılgan bir modeli devreye almak için gerçekten güçlü bir teşvik yoktur.
Bu nedenle amacım, mevcut modern Optimistic sistemlerin (Bedrock gibi) sorunsuz bir şekilde ZK sistemlerine dönüştürülebilmesi için bir mimari ve geçiş yolu oluşturmak. İşte bunun sadece mümkün olmadığını, aynı zamanda mevcut zkEVM yaklaşımının ötesine geçen bir şekilde nasıl olduğunu düşünüyorum.
Yukarıda anlattığım Bedrock tarzı mimari ile başlıyoruz. Bedrock'un L2 programını savunan bir meydan okuma oyununa nasıl sahip olduğunu (kısaca) açıkladığımı unutmayın (EVM'yi çalıştırmak + onu bir ZK Toplamasına dönüştürmek için bazı ekstra şeyler
Genel olarak, İyimser Toplamaların önümüzdeki birkaç yıl içinde hakim olacağını düşünüyorum. ZK Rollup'ın eninde sonunda Optimistic Rollup'ı geçeceği yönünde bir görüş var ama bence bu yanlış olabilir. İyimser Toplamaların göreceli basitliği ve esnekliğinin, zaman içinde ZK Toplamalarına dönüştürülebilecekleri anlamına geldiğini düşünüyorum. Bu geçişin gerçekleşmesi için bir model bulabilirsek, daha az esnek ve daha problem eğilimli bir ZK sistemlerine dağıtım yapmak için gerçekten güçlü bir teşvik yoktur.
Bu nedenle amacım, mevcut modern Optimistic sistemlerin (Bedrock gibi) sorunsuz bir şekilde ZK sistemlerine geçişine izin veren bir mimari ve geçiş yolu oluşturmak. Sadece bu geçişi gerçekleştirmenin değil, aynı zamanda bunu bugünün zkEVM yaklaşımının ötesine geçen bir şekilde yapmanın bir yolunun burada olduğuna inanıyorum.
Daha önce anlattığım Bedrock tarzı mimariyle başlıyoruz. Bedrock'un bir L2 programının (EVM'yi çalıştıran bir MIPS programı + bazı ekstralar) yürütülmesinin geçerliliğini iddia edebilen bir meydan okuma oyununa nasıl sahip olduğunu (kısaca) açıkladığımı unutmayın. Bu yaklaşımın ana dezavantajlarından biri, bir kullanıcının yanlış bir program sonuç teklifini tespit etmesi ve başarılı bir şekilde itiraz etmesi için bir süre tanımamız gerekmesidir. Bu, varlık çekme işlemine önemli miktarda zaman ekler (şu anda Optimism ana ağında 7 gün).
Ancak, bizim L2'miz sadece basit bir makinede (MIPS) çalışan bir programdır. Bu kadar basit bir makine için bir ZK devresi oluşturmak tamamen mümkündür. Daha sonra bu devreyi L2 programının doğru yürütüldüğünü kesin olarak kanıtlamak için kullanabiliriz. Mevcut Bedrock kod tabanında herhangi bir değişiklik yapmadan, Optimism için geçerlilik kanıtları yayınlamaya başlayabilirsiniz. Gerçekten bu kadar basit.
Bu yöntem neden bu kadar iyi çalışıyor
Kısa not: Bu bölümde "zkMIPS"den bahsetmiştim, ama aslında onu herhangi bir genel "basit" zkVM'ye atıfta bulunmak için kullanıyorum.
zkMIPS, zkEVM'den daha basittir
zkEVM yerine bir zkMIPS (veya zk[diğer makine adını girin]) oluşturmanın büyük yararı, hedef makinenin mimarisinin basit ve statik olmasıdır. EVM sık sık değişir. Gaz fiyatları değişecek, işlem kodları ayarlanacak ve bir şeyler eklenecek veya çıkarılacak. Ve MIPS-V 1996'dan beri değişmedi. zkMIPS'yi hedefleyerek, sabit bir sorun alanı üzerinde çalışırsınız. EVM her güncellendiğinde devrenizi değiştirmenize ve muhtemelen yeniden denetlemenize gerek yoktur.
zkMIPS, zkEVM'den daha esnektir
Bir başka önemli tartışma noktası da, zkMIPS'nin zkEVM'den daha esnek olmasıdır. zkMIPS ile, çeşitli optimizasyonlar veya kullanıcı deneyimi geliştirmeleri elde etmek için istemci kodunu istediğiniz zaman değiştirmek için daha fazla esnekliğe sahipsiniz. İstemci güncellemelerinin artık devre güncellemeleriyle birlikte gelmesi gerekmiyor. Ayrıca, herhangi bir blok zincirini yalnızca Ethereum'a değil, bir ZK Toplamasına dönüştürmek için kullanılabilecek bir çekirdek bileşen de oluşturabilirsiniz.
Sorunuz deneme süresine dönüşüyor
ZK prova süresi iki eksen boyunca ölçeklenir: kısıtlama sayısı ve devre boyutu. (EVM gibi daha karmaşık bir makine yerine) MIPS gibi basit bir makinenin devresine odaklanarak, devrenin boyutunu ve karmaşıklığını önemli ölçüde azaltabildik. Ancak kısıtlamaların sayısı, yürütülen makine komutlarının sayısına bağlıdır. Her EVM işlem kodu, birden fazla MIPS işlem koduna bölünmüştür; bu, kısıtlamaların sayısının ve genel kanıtlama süresinin önemli ölçüde arttığı anlamına gelir.
Ancak prova sürelerinin azaltılması, Web2 alanında kök salmış bir sorundur. MIPS makine mimarisinin yakın gelecekte değişmeyeceği göz önüne alındığında, daha sonraki bir aşamada EVM değişiklikleri hakkında endişelenmeden devrelerimizi ve prova programlarımızı yüksek oranda optimize edebiliriz. İyi tanımlanmış bir programı optimize edebilen donanım mühendisleri için işe alma havuzunun, sürekli değişen bir zkEVM hedefi oluşturmak ve denetlemek için işe alma havuzundan en az 10 (100 değilse de) kat daha büyük olduğundan oldukça eminim. Netflix gibi bir şirketin muhtemelen kod dönüştürme çiplerini optimize etmek için çalışan çok sayıda donanım mühendisi vardır ve ilginç bir ZK sorununun üstesinden gelmek için bir sürü VC parasını memnuniyetle kabul ederler.
Böyle bir devre için ilk prova süresi, 7 günlük İyimser Toplama geri çekilme süresini aşabilir. Bu prova süresi yalnızca zamanla azalacaktır. ASIC'leri ve FPGA'ları tanıtarak, prova süresini büyük ölçüde hızlandırabiliriz. Statik bir hedefle, daha uygun kanıtlayıcılar oluşturabiliriz.
Sonunda, bu devre için prova süresi, mevcut 7 günlük Optimistic Toplama geri çekilme süresinden daha düşük olacak ve Optimistic'i iptal etmeyi düşünmek için meydan okuma sürecine başlayabiliriz. Bir provayı 7 gün boyunca çalıştırmak yine de çok pahalı olabilir, bu yüzden biraz daha beklemek isteyebiliriz, ancak mesele yine de geçerli. Hatta her iki ispat sistemini aynı anda çalıştırabilirsiniz, böylece ZK ispatlarını hemen kullanmaya başlayabiliriz ve herhangi bir nedenle ispat programı başarısız olursa, İyimser ispatlara geri dönebiliriz. Hazır olduğunuzda, uygulamaya tamamen şeffaf olacak şekilde ZK provalarına geçmek kolaydır. Başka hiçbir sistem bu esnekliği ve sorunsuz geçiş yolunu sunmaz.
Diğer önemli konulara odaklanabilirsiniz
Bir blok zinciri çalıştırmak zor bir iştir ve yalnızca çok sayıda arka uç kodu yazmayı içermez. Optimism'de yaptığımız işlerin çoğu, faydalı istemci tarafı araçlar aracılığıyla kullanıcı ve geliştirici deneyimini geliştirmeye odaklanmıştır. Ayrıca "yumuşak" şeylerle uğraşmak için çok fazla zaman ve enerji harcadık: projelerle konuşmak, sorunlu noktaları anlamak, teşvikler tasarlamak. Blockchain yazılımına ne kadar çok zaman harcarsanız, diğer şeyleri düşünmek için o kadar az zaman harcarsınız. Her zaman daha fazla kişiyi işe almayı deneyebilirsiniz, ancak kuruluşlar doğrusal olarak ölçeklenmez ve işe alınan her yeni kişi dahili iletişim yükünü artırır.
ZK devre çalışması mevcut çalışan bir zincire eklenebileceğinden, çekirdek platformu ve prova yazılımını paralel olarak oluşturmaya çalışabilirsiniz. Ayrıca client devre değiştirilmeden modifiye edilebildiği için client ve tasdik ekiplerinizi ayırabilirsiniz. Bu yaklaşımı benimseyen bir İyimser Toplama, gerçek zincir üstü faaliyet açısından ZK rakiplerinden yıllarca önde olabilir.
** A **** BAZI SONUÇLAR **
Tamamen dürüst olmak gerekirse, zkMIPS kanıtlayıcının zaman içinde önemli ölçüde optimize edilebileceğini varsayarsak, bu yaklaşımın herhangi bir önemli dezavantajını göremiyorum. Uygulamada gördüğüm tek gerçek etki, farklı işlem kodları için gaz maliyetlerinin, bu işlem kodları tarafından eklenen kanıt süresini yansıtacak şekilde ayarlanması gerekebileceğidir. Bu ispatlayıcıyı makul bir seviyeye optimize etmek gerçekten imkansızsa, o zaman yenilgiyi kabul ediyorum. Bu kanıtlayıcıyı optimize etmek gerçekten mümkünse, o zaman zkMIPS/zkVM yaklaşımı mevcut zkEVM yaklaşımından çok daha iyi görünüyor ki, ikincisini tamamen geçersiz kılabilir. Bu, radikal bir ifade gibi görünebilir, ancak çok uzun zaman önce, tek adımlı İyimser başarısızlık ispatlarının yerini tamamen çok adımlı ispatlar aldı.
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.
ZK/Optimistic Hybrid Toplama Üzerine Tartışma
Yazar: kelvinfichter; Derleyen: MarsBit, MK
Son zamanlarda Ethereum Toplamalarının geleceğinin aslında iki ana yaklaşımın (ZK ve İyimser) bir melezi olduğuna ikna oldum. Bu yazıda, tasavvur ettiğim şeyin temel mimarisini açıklamaya çalışacağım ve bunun neden ileriye dönük en iyi yol olduğunu düşündüğümü açıklayacağım.
ZK veya Optimist Toplamaların doğasını tartışmak için fazla zaman harcamayacağım. Bu gönderi, bu şeylerin nasıl çalıştığına dair zaten iyi bir anlayışa sahip olduğunuzu varsayar. Uzman olmanıza gerek yok ama en azından ne olduklarını ve üst düzeyde nasıl çalıştıklarını bilmelisiniz. Size Rollup'ları anlatmaya kalksam bu yazı çok ama çok uzun olur. Sonuç olarak, okumanın tadını çıkarın!
İyimser Toplama ile Başlayın
Hybrid ZK/Optimistic Rollup, Optimism'in Bedrock mimarisine çok benzeyen Optimistic Rollup olarak başladı. Bedrock, Ethereum ("EVM Eşdeğeri") ile maksimum uyumluluğu hedefler ve bunu normal bir Ethereum istemcisiyle neredeyse aynı olan bir yürütme istemcisi çalıştırarak başarır. Bedrock, Ethereum'un yaklaşmakta olan konsensüs/yürütme istemci ayırma modelini kullanır ve EVM'deki varyansı önemli ölçüde azaltır (bazı değişiklikler her zaman gerekli olacaktır, ancak bunu yönetebiliriz). Bunu yazarken, Bedrock Geth farkı +388 -30 taahhüttür.
İyimserlik, herhangi bir iyi Toplama gibi, Ethereum'dan blok/işlem verilerini alır, bu verileri mutabakat istemcisi içinde belirli bir şekilde sıralar ve ardından bu verileri yürütme için L2 yürütme istemcisine besler. Bu mimari, "ideal Toplama" bulmacasının ilk yarısını çözerek bize bir EVM Eşdeğeri L2 veriyor.
Elbette artık Ethereum Optimism içinde neler olup bittiğini kanıtlanabilir bir şekilde nasıl anlatacağımız problemini de çözmemiz gerekiyor. Bu özellik olmadan, sözleşmeler İyimserlik durumuna dayalı kararlar veremez. Bu, kullanıcıların Optimism'e para yatırabilecekleri ancak varlıklarını asla çekemeyecekleri anlamına gelir. Bazı durumlarda tek yönlü bir toplama gerçekten yararlı olabilirken, genel olarak çift yönlü bir toplama daha kullanışlıdır.
Ethereum'a herhangi bir Toplamanın durumunu, bu duruma bir taahhüt vererek ve taahhüdün doğru bir şekilde oluşturulduğunu kanıtlayarak söyleyebiliriz. Bunu söylemenin başka bir yolu da, "Toplama programının" doğru yürütüldüğünü kanıtlıyoruz. ZK ve İyimser Toplamalar arasındaki tek gerçek fark, bu kanıtın biçimidir. ZK Toplamasında, programın doğru şekilde yürütüldüğüne dair açık bir ZK kanıtı vermeniz gerekir. İyimser Toplama'da, vaatler hakkında iddialarda bulunursunuz, ancak açık kanıtlar yoktur. Diğer kullanıcılar iddialarınıza meydan okuyabilir ve sizi sonunda kimin haklı olduğunu anladığınız yinelemeli bir oyun oynamaya zorlayabilir.
Optimistic Rollup meydan okuma oyunu hakkında çok fazla ayrıntıya girmeyeceğim. Bu oyundaki son teknolojinin, programınızı (Geth EVM + Optimism durumundaki bazı uç kısımlar) MIPS gibi basit bir makine mimarisine derlemek olduğunu belirtmekte fayda var. Bunu yapıyoruz çünkü programımız için zincir üstü bir tercüman oluşturmamız gerekiyor ve bir MIPS tercümanı oluşturmak EVM tercümanından çok daha kolay. EVM ayrıca hareketli bir hedeftir (düzenli yükseltme çatallarımız vardır) ve kanıtlamak istediğimiz programları tam olarak kapsamaz (orada EVM olmayan bazı şeyler de vardır).
Basit makine mimariniz için zincir üstü bir yorumlayıcı oluşturduktan ve bazı zincir dışı araçlar oluşturduktan sonra, tamamen işlevsel bir Optimistic Rollup'a sahip olmalısınız.
ZK Toplamasına Dönüştürüldü
Genel olarak, İyimser Toplamaların en azından önümüzdeki birkaç yıl boyunca hakim olacağını düşünüyorum. Bazı insanlar ZK Toplamalarının sonunda İyimser Toplamaları geçeceğini düşünüyor, ancak bence bu yanlış olabilir. Bence bugün Optimistic Toplamaların göreceli basitliği ve esnekliği, bunların zaman içinde ZK Toplamalarına dönüştürülebilecekleri anlamına geliyor. Bunu gerçekleştirecek bir model bulabilirsek, mevcut bir Optimistic sistemine kolayca konuşlandırabileceğiniz ve buna bir günlük çalışma ZK sistemi diyebileceğiniz zaman, daha az esnek, daha kırılgan bir modeli devreye almak için gerçekten güçlü bir teşvik yoktur.
Bu nedenle amacım, mevcut modern Optimistic sistemlerin (Bedrock gibi) sorunsuz bir şekilde ZK sistemlerine dönüştürülebilmesi için bir mimari ve geçiş yolu oluşturmak. İşte bunun sadece mümkün olmadığını, aynı zamanda mevcut zkEVM yaklaşımının ötesine geçen bir şekilde nasıl olduğunu düşünüyorum.
Yukarıda anlattığım Bedrock tarzı mimari ile başlıyoruz. Bedrock'un L2 programını savunan bir meydan okuma oyununa nasıl sahip olduğunu (kısaca) açıkladığımı unutmayın (EVM'yi çalıştırmak + onu bir ZK Toplamasına dönüştürmek için bazı ekstra şeyler
Genel olarak, İyimser Toplamaların önümüzdeki birkaç yıl içinde hakim olacağını düşünüyorum. ZK Rollup'ın eninde sonunda Optimistic Rollup'ı geçeceği yönünde bir görüş var ama bence bu yanlış olabilir. İyimser Toplamaların göreceli basitliği ve esnekliğinin, zaman içinde ZK Toplamalarına dönüştürülebilecekleri anlamına geldiğini düşünüyorum. Bu geçişin gerçekleşmesi için bir model bulabilirsek, daha az esnek ve daha problem eğilimli bir ZK sistemlerine dağıtım yapmak için gerçekten güçlü bir teşvik yoktur.
Bu nedenle amacım, mevcut modern Optimistic sistemlerin (Bedrock gibi) sorunsuz bir şekilde ZK sistemlerine geçişine izin veren bir mimari ve geçiş yolu oluşturmak. Sadece bu geçişi gerçekleştirmenin değil, aynı zamanda bunu bugünün zkEVM yaklaşımının ötesine geçen bir şekilde yapmanın bir yolunun burada olduğuna inanıyorum.
Daha önce anlattığım Bedrock tarzı mimariyle başlıyoruz. Bedrock'un bir L2 programının (EVM'yi çalıştıran bir MIPS programı + bazı ekstralar) yürütülmesinin geçerliliğini iddia edebilen bir meydan okuma oyununa nasıl sahip olduğunu (kısaca) açıkladığımı unutmayın. Bu yaklaşımın ana dezavantajlarından biri, bir kullanıcının yanlış bir program sonuç teklifini tespit etmesi ve başarılı bir şekilde itiraz etmesi için bir süre tanımamız gerekmesidir. Bu, varlık çekme işlemine önemli miktarda zaman ekler (şu anda Optimism ana ağında 7 gün).
Ancak, bizim L2'miz sadece basit bir makinede (MIPS) çalışan bir programdır. Bu kadar basit bir makine için bir ZK devresi oluşturmak tamamen mümkündür. Daha sonra bu devreyi L2 programının doğru yürütüldüğünü kesin olarak kanıtlamak için kullanabiliriz. Mevcut Bedrock kod tabanında herhangi bir değişiklik yapmadan, Optimism için geçerlilik kanıtları yayınlamaya başlayabilirsiniz. Gerçekten bu kadar basit.
Bu yöntem neden bu kadar iyi çalışıyor
Kısa not: Bu bölümde "zkMIPS"den bahsetmiştim, ama aslında onu herhangi bir genel "basit" zkVM'ye atıfta bulunmak için kullanıyorum.
zkMIPS, zkEVM'den daha basittir
zkEVM yerine bir zkMIPS (veya zk[diğer makine adını girin]) oluşturmanın büyük yararı, hedef makinenin mimarisinin basit ve statik olmasıdır. EVM sık sık değişir. Gaz fiyatları değişecek, işlem kodları ayarlanacak ve bir şeyler eklenecek veya çıkarılacak. Ve MIPS-V 1996'dan beri değişmedi. zkMIPS'yi hedefleyerek, sabit bir sorun alanı üzerinde çalışırsınız. EVM her güncellendiğinde devrenizi değiştirmenize ve muhtemelen yeniden denetlemenize gerek yoktur.
zkMIPS, zkEVM'den daha esnektir
Bir başka önemli tartışma noktası da, zkMIPS'nin zkEVM'den daha esnek olmasıdır. zkMIPS ile, çeşitli optimizasyonlar veya kullanıcı deneyimi geliştirmeleri elde etmek için istemci kodunu istediğiniz zaman değiştirmek için daha fazla esnekliğe sahipsiniz. İstemci güncellemelerinin artık devre güncellemeleriyle birlikte gelmesi gerekmiyor. Ayrıca, herhangi bir blok zincirini yalnızca Ethereum'a değil, bir ZK Toplamasına dönüştürmek için kullanılabilecek bir çekirdek bileşen de oluşturabilirsiniz.
Sorunuz deneme süresine dönüşüyor
ZK prova süresi iki eksen boyunca ölçeklenir: kısıtlama sayısı ve devre boyutu. (EVM gibi daha karmaşık bir makine yerine) MIPS gibi basit bir makinenin devresine odaklanarak, devrenin boyutunu ve karmaşıklığını önemli ölçüde azaltabildik. Ancak kısıtlamaların sayısı, yürütülen makine komutlarının sayısına bağlıdır. Her EVM işlem kodu, birden fazla MIPS işlem koduna bölünmüştür; bu, kısıtlamaların sayısının ve genel kanıtlama süresinin önemli ölçüde arttığı anlamına gelir.
Ancak prova sürelerinin azaltılması, Web2 alanında kök salmış bir sorundur. MIPS makine mimarisinin yakın gelecekte değişmeyeceği göz önüne alındığında, daha sonraki bir aşamada EVM değişiklikleri hakkında endişelenmeden devrelerimizi ve prova programlarımızı yüksek oranda optimize edebiliriz. İyi tanımlanmış bir programı optimize edebilen donanım mühendisleri için işe alma havuzunun, sürekli değişen bir zkEVM hedefi oluşturmak ve denetlemek için işe alma havuzundan en az 10 (100 değilse de) kat daha büyük olduğundan oldukça eminim. Netflix gibi bir şirketin muhtemelen kod dönüştürme çiplerini optimize etmek için çalışan çok sayıda donanım mühendisi vardır ve ilginç bir ZK sorununun üstesinden gelmek için bir sürü VC parasını memnuniyetle kabul ederler.
Böyle bir devre için ilk prova süresi, 7 günlük İyimser Toplama geri çekilme süresini aşabilir. Bu prova süresi yalnızca zamanla azalacaktır. ASIC'leri ve FPGA'ları tanıtarak, prova süresini büyük ölçüde hızlandırabiliriz. Statik bir hedefle, daha uygun kanıtlayıcılar oluşturabiliriz.
Sonunda, bu devre için prova süresi, mevcut 7 günlük Optimistic Toplama geri çekilme süresinden daha düşük olacak ve Optimistic'i iptal etmeyi düşünmek için meydan okuma sürecine başlayabiliriz. Bir provayı 7 gün boyunca çalıştırmak yine de çok pahalı olabilir, bu yüzden biraz daha beklemek isteyebiliriz, ancak mesele yine de geçerli. Hatta her iki ispat sistemini aynı anda çalıştırabilirsiniz, böylece ZK ispatlarını hemen kullanmaya başlayabiliriz ve herhangi bir nedenle ispat programı başarısız olursa, İyimser ispatlara geri dönebiliriz. Hazır olduğunuzda, uygulamaya tamamen şeffaf olacak şekilde ZK provalarına geçmek kolaydır. Başka hiçbir sistem bu esnekliği ve sorunsuz geçiş yolunu sunmaz.
Diğer önemli konulara odaklanabilirsiniz
Bir blok zinciri çalıştırmak zor bir iştir ve yalnızca çok sayıda arka uç kodu yazmayı içermez. Optimism'de yaptığımız işlerin çoğu, faydalı istemci tarafı araçlar aracılığıyla kullanıcı ve geliştirici deneyimini geliştirmeye odaklanmıştır. Ayrıca "yumuşak" şeylerle uğraşmak için çok fazla zaman ve enerji harcadık: projelerle konuşmak, sorunlu noktaları anlamak, teşvikler tasarlamak. Blockchain yazılımına ne kadar çok zaman harcarsanız, diğer şeyleri düşünmek için o kadar az zaman harcarsınız. Her zaman daha fazla kişiyi işe almayı deneyebilirsiniz, ancak kuruluşlar doğrusal olarak ölçeklenmez ve işe alınan her yeni kişi dahili iletişim yükünü artırır.
ZK devre çalışması mevcut çalışan bir zincire eklenebileceğinden, çekirdek platformu ve prova yazılımını paralel olarak oluşturmaya çalışabilirsiniz. Ayrıca client devre değiştirilmeden modifiye edilebildiği için client ve tasdik ekiplerinizi ayırabilirsiniz. Bu yaklaşımı benimseyen bir İyimser Toplama, gerçek zincir üstü faaliyet açısından ZK rakiplerinden yıllarca önde olabilir.
** A **** BAZI SONUÇLAR **
Tamamen dürüst olmak gerekirse, zkMIPS kanıtlayıcının zaman içinde önemli ölçüde optimize edilebileceğini varsayarsak, bu yaklaşımın herhangi bir önemli dezavantajını göremiyorum. Uygulamada gördüğüm tek gerçek etki, farklı işlem kodları için gaz maliyetlerinin, bu işlem kodları tarafından eklenen kanıt süresini yansıtacak şekilde ayarlanması gerekebileceğidir. Bu ispatlayıcıyı makul bir seviyeye optimize etmek gerçekten imkansızsa, o zaman yenilgiyi kabul ediyorum. Bu kanıtlayıcıyı optimize etmek gerçekten mümkünse, o zaman zkMIPS/zkVM yaklaşımı mevcut zkEVM yaklaşımından çok daha iyi görünüyor ki, ikincisini tamamen geçersiz kılabilir. Bu, radikal bir ifade gibi görünebilir, ancak çok uzun zaman önce, tek adımlı İyimser başarısızlık ispatlarının yerini tamamen çok adımlı ispatlar aldı.