Son aylarda yardımcı işlemci kavramı popüler hale geldikçe, bu yeni ZK kullanım durumu giderek daha fazla ilgi görmeye başladı.

Bununla birlikte, çoğu insanın yardımcı işlemci kavramına, özellikle de yardımcı işlemcilerin kesin konumlandırılmasına (bir yardımcı işlemcinin ne olduğu ve ne olmadığı) hala göreceli olarak aşina olmadığını gördük. Piyasadaki çeşitli ortak işlemci parçalarının teknik çözümlerinin karşılaştırılması konusunda henüz kimse bunu sistematik olarak çözmedi. Bu makale, pazara ve kullanıcılara ortak işlemci yolu hakkında daha net bir anlayış sunmayı umuyor.

1. Ortak İşlemci nedir, ne değildir?

Yardımcı işlemcileri teknik bilgisi olmayan birine veya geliştiriciye tek bir cümleyle açıklamanız istense, bunu nasıl tanımlarsınız?

Dr. Dong Mo'nun söylediğinin standart cevaba çok yakın olabileceğini düşünüyorum; açık bir şekilde ifade etmek gerekirse, bir yardımcı işlemci "akıllı sözleşmelere Dune Analytics'i gerçekleştirme yeteneği veriyor."

Bu cümleyi nasıl çözebiliriz?

Dune'u kullandığımız senaryoyu hayal edin - Bazı işlem ücretleri kazanmak için Uniswap V3'te LP yapmak istiyorsunuz, böylece Dune'u açıyorsunuz ve Uniswap'teki çeşitli işlem çiftlerinin son işlem hacmini, son 7 gündeki işlem ücretlerinin APR'sini buluyorsunuz, ve ana ticaret çiftleri Üst ve alt dalgalanma aralıkları, vb…

Ya da belki StepN popüler hale geldiğinde ayakkabılar hakkında spekülasyon yapmaya başladınız ve ne zaman satacağınızı bilemediğinizden her gün Dune'daki StepN verilerine, günlük işlem hacmine, yeni kullanıcı sayısına, ayakkabıların taban fiyatına baktınız… ve büyüme gerçekleştiğinde bunu yapmayı planladık. Trend yavaşlarsa veya düşerse hızlı koşun.

Elbette sadece siz bu verilere bakmıyorsunuz, Uniswap ve StepN'in geliştirme ekipleri de bu verilere dikkat ediyor.

Bu veriler çok anlamlıdır; yalnızca trendlerdeki değişiklikleri değerlendirmeye yardımcı olmakla kalmaz, aynı zamanda onu, tıpkı büyük İnternet şirketlerinin yaygın olarak kullandığı "büyük veri" yaklaşımı gibi, daha fazla hile oluşturmak için de kullanabilir.

Örneğin kullanıcıların sıklıkla alıp sattığı ayakkabıların tarzına ve fiyatına göre benzer ayakkabılar öneriliyor.

Örneğin, sadık kullanıcılara daha fazla airdrop veya avantaj sağlamak için kullanıcıların Creation Shoes'u elinde tuttukları süreye bağlı olarak bir "Kullanıcı Bağlılığı Ödül Programı" başlatılacak.

Örneğin, Cex'e benzer bir VIP planı, LP'nin Uniswap veya Trader'da sağladığı TVL veya işlem hacmine bağlı olarak başlatılabilir, bu da Trader'a işlem ücretinde indirim veya LP'nin ücret payının artmasıyla fayda sağlar…

Bu noktada sorun ortaya çıkıyor; büyük İnternet şirketlerinin büyük verisi + yapay zekası aslında bir kara kutu. Onlar istediklerini yapabilirler. Kullanıcılar bunu göremiyor ve umursamıyor.

Ancak Web3'te şeffaflık ve güvensizlik bizim doğal politik doğruluğumuzdur ve kara kutuları reddediyoruz!

Dolayısıyla, yukarıdaki senaryoyu gerçekleştirmek istediğinizde bir ikilemle karşı karşıya kalacaksınız - ya bunu merkezi yöntemlerle başarabilirsiniz, ya da arka planda dizin verilerini saymak için Dune'u "manuel olarak" kullanabilirsiniz ve ardından bunu dağıtıp uygulayabilirsiniz; veya zincirdeki bu verileri otomatik olarak yakalamak, hesaplamaları tamamlamak ve noktaları otomatik olarak dağıtmak için Akıllı sözleşmeler ayarlayın yazabilirsiniz.

İlki sizi “siyasi olarak yanlış” güven sorunlarına sürükleyecektir.

İkincisinin zincirde oluşturduğu gaz ücreti astronomik bir rakam olacaktır ve (proje tarafı) cüzdanınız bunu karşılayamaz.

Bu, yardımcı işlemcinin sahneye çıkma zamanıdır. Şimdi bu iki yöntemi birleştirin ve aynı zamanda teknik yollarla "masumiyeti tasdik etmek" için "arka uç kılavuzu" adımını kullanın. Başka bir deyişle, ZK teknolojisini "indekslemek +" hesaplama "bölümünü "masumiyeti kendi kendine kanıtlar" için kullanın ve ardından bunu akıllı sözleşmeye besleyin. Bu sayede güven sorunu çözülüyor ve devasa gaz ücretleri ortadan kalkıyor. Mükemmel!

Neden “yardımcı işlemci” olarak adlandırılıyor? Aslında bu Web2.0'ın gelişim tarihindeki “GPU”dan geliyor. GPU'nun o dönemde ayrı bir bilgi işlem donanımı olarak tanıtılmasının ve CPU'dan bağımsız olarak var olmasının nedeni, tasarım mimarisinin, büyük ölçekli paralel tekrarlanan hesaplamalar, grafikler gibi CPU için temelde zor olan bazı hesaplamaları işleyebilmesiydi. hesaplamalar vb. Tam da bu "ortak işlemci" mimarisi sayesinde bugün harika CG filmlerimiz, oyunlarımız, yapay zeka modellerimiz vb. var, yani bu ortak işlemci mimarisi aslında bilgi işlem mimarisinde bir sıçramadır. Artık çeşitli ortak işlemci ekipleri de bu mimariyi Web3.0'a tanıtmayı umuyor. Buradaki blockchain Web3.0'ın CPU'suna benzer. İster L1 ister L2 olsun, doğası gereği bu tür "ağır veri" ve "Karmaşık hesaplama mantığı" görevleri için uygun değildirler, dolayısıyla bu tür hesaplamaların yönetilmesine yardımcı olmak için bir blockchain ortak işlemcisi tanıtılır ve böylece blockchain uygulamalarının olanakları büyük ölçüde genişletilir.

Yani yardımcı işlemcinin yaptığı iki şeyle özetlenebilir:

1. Blockchain'den verileri alın ve elde ettiğim verilerin doğru olduğunu ve tahrifat olmadığını kanıtlamak için ZK'yi kullanın;
2. Az önce elde ettiğim verilere dayanarak ilgili hesaplamaları yapın ve hesapladığım sonuçların doğru olduğunu ve hileli olmadığını bir kez daha ZK kullanarak kanıtlayın. Hesaplama sonuçları akıllı sözleşmeyle "Düşük Ücret + Güvensiz" olarak adlandırılabilir.

Bir süre önce Starkware'in, State Proof olarak da adlandırılan Storage Proof adında popüler bir konsepti vardı. Temel olarak Herodot, Langrage vb. tarafından temsil edilen 1. adımı gerçekleştirir. ZK teknolojisine dayalı birçok zincirler arası köprünün teknik odağı da 1.1. adımdadır.

Ortak işlemci, 1. adımın ardından 2. adımın gelmesinden başka bir şey değildir. Verileri güven olmadan çıkardıktan sonra, güvensiz bir hesaplama yapın ve bu kadar.

Bu nedenle, bunu doğru bir şekilde tanımlamak için nispeten teknik bir terim kullanmak gerekirse, yardımcı işlemcinin Depolama Kanıtı/Durum Kanıtı'nın bir üst kümesi ve Doğrulanabilir Hesaplama'nın bir alt kümesi olması gerekir.

Unutulmaması gereken bir nokta, yardımcı işlemcinin Toplama olmamasıdır.

Teknik olarak konuşursak, Rollup'ın ZK kanıtı yukarıdaki 2. adıma benzer ve 1. adımın "veri alma" süreci doğrudan Sıralayıcı aracılığıyla uygulanır. Merkezi olmayan bir Sıralayıcı bile bunu başarmak için yalnızca bir tür rekabet veya fikir birliği mekanizması kullanır. Depolama Kanıtı yerine ZK'nin bu formunu alın. Daha da önemlisi, ZK Rollup'ın hesaplama katmanına ek olarak L1 blok zincirine benzer bir depolama katmanı da uygulaması gerekiyor. Bu depolama kalıcıdır, ancak ZK Yardımcı İşlemcisi "durumsuzdur". Hesaplama tamamlandıktan sonra Tümü durumu korunmaz.

Uygulama senaryoları açısından bakıldığında, yardımcı işlemci tüm Katman1/Katman2 için bir hizmet eklentisi olarak kabul edilebilirken, Toplama, yerleşim katmanının genişletilmesine yardımcı olmak için bir yürütme katmanını yeniden oluşturur.

2. Neden ZK kullanmam gerekiyor? OP'yi kullanmak uygun mudur?

Yukarıdakileri okuduktan sonra ZK'nın yardımcı işlemci olarak kullanılması gerektiği konusunda şüpheniz olabilir. “ZK eklenmiş bir Grafik”e çok benziyor ve Grafiğin sonuçları hakkında “büyük şüphelerimiz” yok gibi görünüyor.

Bunun nedeni, Graph'ı kullandığınızda temelde gerçek paranın söz konusu olmamasıdır. Bu indeksler zincir dışı hizmetlere hizmet eder. Ön uç kullanıcı arayüzünde gördüğünüz şeyler işlem hacmi, işlem geçmişi vb.'dir. Veriler, Graph, Alchemy, Zettablock vb. gibi birden fazla veri indeksi sağlayıcısı aracılığıyla sağlanabilir, ancak bu veriler akıllı sözleşmeye geri doldurulamaz çünkü onu tekrar doldurduğunuzda indeks hizmetine daha fazla güven katacaksınız. Veriler gerçek paraya, özellikle de büyük hacimli TVL'ye bağlandığında, bu ekstra güven önem kazanır. Bir dahaki sefere bir arkadaşınız sizden 100 yuan borç istediğinde, onu gözünüzü bile kırpmadan ödünç verebileceğinizi hayal edin. Evet, sizden 10.000 yuan, hatta 1 milyon yuan borç almanızı istediğimde ne olacak?

Ancak yukarıdaki senaryoların tümünü birlikte işlemek için gerçekten ZK'yi kullanmamız gerekiyor mu? Sonuçta Rollup'ta OP ve ZK olmak üzere iki teknik rotamız var. Son zamanlarda popüler olan ZKML ayrıca OPML'nin karşılık gelen şube rotaları konseptine de sahiptir. Yardımcı işlemcinin ayrıca OP-Yardımcı İşlemci gibi bir OP şubesi var mı diye sorulur.

Aslında gerçekten de var, ancak şimdilik belirli ayrıntıları gizli tutuyoruz ve yakında daha ayrıntılı bilgileri yayınlayacağız.

3. Hangi yardımcı işlemci en iyisidir - Piyasadaki çeşitli yaygın yardımcı işlemci teknik çözümlerinin karşılaştırılması

Brevis

Brevis'in mimarisi üç bileşenden oluşur: zkFabric, zkQueryNet ve zkAggregatorRollup.

Aşağıda bir Brevis mimari şeması yer almaktadır:

zkFabric: Bağlı tüm blok zincirlerinden blok başlıklarını toplar ve bu blok başlıklarının geçerliliğini kanıtlayan ZK fikir birliği kanıtları üretir. Brevis, zkFabric aracılığıyla birden fazla zincir için birlikte çalışabilen bir yardımcı işlemci uygular ve bu, bir blockchain'in başka bir blockchain'in herhangi bir geçmiş verisine erişmesine olanak tanır.

zkQueryNet: DApp'lerden gelen veri sorgularını kabul eden ve bunları işleyen açık bir ZK sorgu motoru pazarı. Veri sorguları, bu sorguları zkFabric'in doğrulanmış blok başlıklarını kullanarak işler ve ZK sorgu kanıtları oluşturur. Bu motorlar, farklı uygulama ihtiyaçlarını karşılamak için hem son derece uzmanlaşmış işlevlere hem de genel sorgulama dillerine sahiptir.

zkAggregatorRollup: zkFabric ve zkQueryNet için toplama ve depolama katmanı görevi gören bir ZK evrişimli blok zinciri. Her iki bileşenden gelen kanıtları doğrular, doğrulanmış verileri saklar ve zk tarafından doğrulanmış durum kökünü tüm bağlı blok zincirlerine aktarır.

ZK Fabric, blok başlığı için kanıt oluşturmanın önemli bir parçasıdır. Bu kısmın güvenliğinin sağlanması oldukça önemlidir. zkFabric'in mimari diyagramı aşağıdadır:

zkFabric'in sıfır bilgi kanıtı (ZKP) tabanlı hafif istemcisi, herhangi bir harici doğrulama kuruluşuna dayanmadan onu tamamen güvenilmez hale getirir. Güvenliği tamamen temel blok zincirinden ve matematiksel olarak güvenilir kanıtlardan geldiğinden, herhangi bir harici doğrulama kuruluşuna güvenmeye gerek yoktur.

zkFabric Prover ağı, her bir blok zincirinin lightclient protokolü için devreleri uygular ve ağ, blok başlıkları için geçerlilik kanıtları üretir. Provacılar, prova süresini ve maliyetini en aza indirmek için GPU'lar, FPGA'ler ve ASIC'ler gibi hızlandırıcılardan yararlanabilir.

zkFabric, blok zincirinin ve temel şifreleme protokollerinin güvenlik varsayımlarına ve temel şifreleme protokollerinin güvenlik varsayımlarına dayanır. Ancak zkFabric'in etkinliğini sağlamak için doğru çatalı senkronize edecek en az bir dürüst aktarıcı gerekir. Bu nedenle zkFabric, zkFabric'in etkinliğini optimize etmek için tek bir röle yerine merkezi olmayan bir röle ağı kullanır. Bu aktarma ağı, Celer ağındaki devlet koruma ağı gibi mevcut yapılardan yararlanabilir.

Kanıtlayıcı Tahsisi: Kanıtlayıcı ağı, her kanıt oluşturma görevi için bir kanıtlayıcı seçen ve bu kanıtlayıcılara ücret ödeyen merkezi olmayan bir ZKP kanıtlayıcı ağıdır.

Mevcut dağıtım:

Ethereum PoS, Cosmos Tendermint ve BNB Chain dahil olmak üzere çeşitli blok zincirleri için halihazırda uygulanan hafif istemci protokolleri örnek ve kavram kanıtı olarak hizmet vermektedir.

Brevis şu anda özel uniswap havuzlarını büyük ölçüde ekleyen uniswap hook ile işbirliği yapıyor. Bununla birlikte, CEX ile karşılaştırıldığında UnisWap, büyük kullanıcı işlem verilerine dayanan projeler (işlem hacmine dayalı sadakat programları gibi) oluşturmak için hala etkili veri işleme yeteneklerinden yoksundur. İşlev.

Hook, Brevis'in yardımıyla bu sorunu çözdü. Hook'lar artık bir kullanıcının veya LP'nin tüm geçmiş zincir verilerinden okuyabilir ve özelleştirilebilir hesaplamaları tamamen güvenilir bir şekilde çalıştırabilir.

Herodot

Herodot, Ethereum katmanı boyunca zincirdeki mevcut ve geçmiş verilere eşzamanlı olarak erişmek için aşağıdaki işlevlere sahip akıllı sözleşmeler sağlayan güçlü bir veri erişim ara yazılımıdır:

1. L2'lerden L1 durumları
2. Hem L1'lerden hem de diğer L2'lerden L2 durumları
3. L3/Uygulama Zinciri durumları L2'lere ve L1'lere

Herodot, büyük bir veri kümesinin (tüm Ethereum blok zinciri veya toplaması gibi) veya birden fazla unsurun geçerliliği.

Blockchain'in çekirdeği, Merkle ağaçları ve Merkle Patricia ağaçları gibi veri yapıları kullanılarak verilerin şifrelendiği ve korunduğu veritabanıdır. Bu veri yapılarının benzersiz yanı, veriler onlara güvenli bir şekilde aktarıldığında, verilerin yapı içinde yer aldığını doğrulayacak kanıtların oluşturulabilmesidir.

Merkle ağaçlarının ve Merkle Patricia ağaçlarının kullanımı Ethereum blok zincirinin güvenliğini artırır. Ağacın her seviyesindeki verilere kriptografik olarak karma işlemi uygulandığında, verileri tespit edilmeden değiştirmek neredeyse imkansızdır. Bir veri noktasında yapılacak herhangi bir değişiklik, ağaçtaki karşılık gelen karma değerinin, blockchain başlığında herkesin görebileceği kök karma değerine değiştirilmesini gerektirir. Blockchain'in bu temel özelliği, yüksek düzeyde veri bütünlüğü ve değişmezliği sağlar.

İkincisi, bu ağaçlar dahil etme kanıtları yoluyla verimli veri doğrulamaya olanak tanır. Örneğin, bir işlemin dahil edildiğini veya bir sözleşmenin durumunu doğrularken, tüm Ethereum blok zincirinin aranmasına gerek yoktur, yalnızca ilgili Merkle ağacındaki yol aranır.

Herodot tarafından tanımlandığı şekliyle saklama kanıtı aşağıdakilerin bir birleşimidir:

1. Sınırlama kanıtları: Bu kanıtlar, kriptografik bir veri yapısında (Merkle ağacı veya Merkle Patricia ağacı gibi) belirli verilerin varlığını doğrulayarak söz konusu verilerin veri kümesinde gerçekten mevcut olduğunu garanti eder.
2. Hesaplamalı Kanıt: Tüm Ethereum blok zinciri veya bir toplam gibi geniş bir veri kümesindeki bir veya daha fazla öğenin geçerliliğini kanıtlayarak çok adımlı bir iş akışının yürütülmesini doğrulayın. Verinin varlığını belirtmenin yanı sıra, o verilere uygulanan dönüşümleri veya işlemleri de doğrularlar.
3. Sıfır bilgi kanıtları: Akıllı sözleşmelerin etkileşimde bulunması gereken veri miktarını basitleştirin. Sıfır bilgi kanıtları, akıllı sözleşmelerin, temeldeki tüm verileri işlemeden bir iddianın geçerliliğini onaylamasına olanak tanır.

İş akışı

1. Blok karmasını elde edin

Blockchain'deki her veri belirli bir bloğa aittir. Blok karması, bloğun benzersiz tanımlayıcısı olarak görev yapar ve tüm içeriğini blok başlığı aracılığıyla özetler. Proof-of-storage iş akışında öncelikle ilgilendiğimiz veriyi içeren bloğun blok hash değerini belirleyip doğrulamamız gerekiyor. Bu, tüm sürecin ilk adımıdır.

2.Blok başlığını edinin

İlgili blok karması elde edildikten sonraki adım blok başlığına erişmektir. Bunu yapmak için, önceki adımda elde edilen blok karma değeriyle ilişkili blok başlığının karma hale getirilmesi gerekir. Sağlanan blok başlığının karması daha sonra ortaya çıkan blok karmasıyla karşılaştırılır:

Hash elde etmenin iki yolu vardır:

1. Almak için BLOCKHASH işlem kodunu kullanın
2. Geçmişte doğrulanmış blokların karma değerini Block Hash Accumulator'dan sorgulayın

Bu adım, işlenmekte olan blok başlığının orijinal olmasını sağlar. Bu adım tamamlandığında akıllı sözleşme blok başlığındaki herhangi bir değere erişebilir.

3.Gerekli kökleri belirleyin (isteğe bağlı)

Elimizde blok başlığı varken, içeriğini detaylı olarak inceleyebiliriz:

stateRoot: Blok zincirinin meydana geldiği andaki tüm blok zinciri durumunun kriptografik özeti.

makbuzRoot: Bloktaki tüm işlem sonuçlarının (makbuzların) şifrelenmiş özeti.

TransactionsRoot: Blokta meydana gelen tüm işlemlerin kriptografik özeti.

Belirli bir hesabın, makbuzun veya işlemin bloğa dahil olup olmadığının doğrulanmasına olanak tanıyacak şekilde kodu çözülebilir.

4. Verileri seçilen köke göre doğrulayın (isteğe bağlı)

Seçtiğimiz kök ile Ethereum'un Merkle-Patricia Trie yapısını kullandığını göz önünde bulundurarak, Merkle dahil etme kanıtını kullanarak verinin ağaçta var olduğunu doğrulayabiliriz. Doğrulama adımları verilere ve blok içindeki verilerin derinliğine bağlı olarak değişiklik gösterecektir.

Şu anda desteklenen ağlar:

1. Ethereum'dan Starknet'e
2. Ethereum Goerli'den Starknet Goerli'ye
3. Ethereum Goerli'den zkSync Era Goerli'ye

Aksiyom

Axiom, geliştiricilere Ethereum'un tüm geçmişinden blok başlıklarını, hesap veya depolama değerlerini sorgulamaları için bir yol sağlar. AXIOM, kriptografiye dayalı yeni bir bağlantı yöntemi sunar. Axiom tarafından döndürülen tüm sonuçlar, sıfır bilgi kanıtlarıyla zincir üzerinde doğrulanır; bu, akıllı sözleşmelerin bunları ek güven varsayımları olmadan kullanabileceği anlamına gelir.

Axiom yakın zamanda Javascript ile yazılmış, tarayıcı tabanlı bir halo2 REPL olan Halo2-repl'i piyasaya sürdü. Bu, geliştiricilerin Rust gibi yeni bir dil öğrenmeye, kanıt kitaplıkları kurmaya veya bağımlılıklarla uğraşmaya gerek kalmadan yalnızca standart Javascript kullanarak ZK devreleri yazmasına olanak tanır.

Axiom iki ana teknoloji bileşeninden oluşur:

1. AxiomV1 — Genesis ile başlayan Ethereum blockchain önbelleği.
2. AxiomV1Query — AxiomV1'e karşı sorguları yürüten akıllı bir sözleşme.

AxiomV1'de blok karmalarının önbelleğe alınması:

AxiomV1 akıllı sözleşmeler, oluşum bloğundan bu yana Ethereum blok karmalarını iki biçimde önbelleğe alır:

İlk olarak, ardışık 1024 blok karma değerinin Keccak Merkle kökü önbelleğe alınır. Bu Merkle kökleri, ZK kanıtları aracılığıyla güncellenir ve blok başlığı karmasının, EVM tarafından doğrudan erişilebilen en son 256 bloktan biriyle veya AxiomV1 önbelleğinde zaten mevcut olan bir blok karmasıyla biten bir taahhüt zinciri oluşturduğunu doğrular.

İkinci olarak Axiom, oluşum bloğundan başlayarak bu Merkle köklerinin Merkle Sıradağlarını saklar. Merkle Sıradağları, önbelleğin ilk kısmı olan Keccak Merkle kökünün güncellenmesiyle zincir üzerine inşa edilmiştir.

AxiomV1Query'de sorguyu yürütün:

AxiomV1Query akıllı sözleşmesi, geçmiş Ethereum blok başlıklarına, hesaplara ve hesaplarda depolanan rastgele verilere güvenilir erişim sağlamak amacıyla toplu sorgular için kullanılır. Sorgular zincir üzerinde yapılabilir ve AxiomV1 önbelleğe alınmış blok karmalarına karşı ZK kanıtları aracılığıyla zincir üzerinde tamamlanır.

Bu ZK kanıtları, Merkle-Patricia üçlüsünün dahil edilme (veya dahil edilmeme) kanıtını doğrulayarak ilgili zincir üstü verilerin doğrudan blok başlığında mı yoksa bloğun hesabında veya depolama üçlüsünde mi bulunduğunu kontrol eder.

bağ kurma

Nexus, doğrulanabilir bulut bilişim için evrensel bir platform oluşturmak amacıyla sıfır bilgi kanıtlarını kullanmaya çalışıyor. Şu anda makine mimarisinden bağımsızdır ve risk 5/WebAssembly/EVM'yi destekler. Nexus süpernovanın kanıt sistemini kullanıyor. Ekip, kanıtı oluşturmak için gereken belleğin 6 GB olduğunu test etti. Gelecekte sıradan istemci cihaz bilgisayarlarının kanıt oluşturabilmesi için bu temelde optimize edilecektir.

Kesin olmak gerekirse, mimari iki bölüme ayrılmıştır:

1. Nexus Zero: Sıfır bilgi kanıtları ve evrensel zkVM ile desteklenen, merkezi olmayan, doğrulanabilir bir bulut bilgi işlem ağı.
2. Nexus: Çok taraflı hesaplama, durum makinesi çoğaltması ve evrensel bir WASM sanal makinesiyle desteklenen, merkezi olmayan, doğrulanabilir bir bulut bilgi işlem ağı.

Nexus ve Nexus Zero uygulamaları, şu anda Rust'u destekleyen geleneksel programlama dillerinde yazılabilir ve daha fazla dil de gelecek.

Nexus uygulamaları, esasen doğrudan Ethereum'a bağlı genel amaçlı bir "sunucusuz blok zinciri" olan merkezi olmayan bir bulut bilgi işlem ağı üzerinde çalışır. Bu nedenle, Nexus uygulamaları Ethereum'un güvenliğini devralmaz, ancak karşılığında ağının küçültülmüş boyutu nedeniyle daha yüksek bilgi işlem gücüne (bilgi işlem, depolama ve olay odaklı G/Ç gibi) erişim kazanır. Nexus uygulamaları, dahili fikir birliğine ulaşan ve Ethereum içindeki ağ çapında doğrulanabilir eşik imzaları aracılığıyla doğrulanabilir hesaplama "kanıtları" (gerçek kanıtlardan ziyade) sağlayan özel bir bulut üzerinde çalışır.

Nexus Zero uygulamaları, BN-254 eliptik eğrisi üzerinde zincir üzerinde doğrulanabilen sıfır bilgi kanıtlarına sahip evrensel programlar olduğundan Ethereum'un güvenliğini devralır.

Nexus, çoğaltılmış bir ortamda herhangi bir deterministik WASM ikili dosyasını çalıştırabildiğinden zk-rollup sıralayıcıları, iyimser toplama sıralayıcıları ve diğer kanıt sunucuları da dahil olmak üzere oluşturulan uygulamalar için bir geçerlilik/dağılım/hata toleransı kanıtı kaynağı olarak kullanılması beklenir. Nexus Zero'nun zkVM'sinin kendisi gibi.

Yasal Uyarı:

1. Bu makale [panewslab]'dan yeniden basılmıştır. Tüm telif hakları orijinal yazara [ABCDE] aittir. Bu yeniden basıma itirazlarınız varsa lütfen Gate Learn ekibiyle iletişime geçin; onlar konuyu hemen halledeceklerdir.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve görüşler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Aksi belirtilmedikçe tercüme edilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.