Giriş: AA cüzdanları kullanıcı giriş engellerini önemli ölçüde azaltmış ve gaz ödemeleri ve web2 hesap girişleri sağlamış olsa da, gizli giriş, gizli işlemler, omnichain AA ve niyet füzyon protokolü gibi kitlesel benimseme ile ilgili hususlar hala AA'nın temelinde daha fazla geliştirme gerektirmektedir.

ZenGo'nun MPC cüzdanı veya Argent gibi akıllı sözleşme cüzdanları gibi çeşitli UX optimizasyon çözümlerinin kullanıcı engellerini etkili bir şekilde azalttığını görsek de, bunlar genel ürün kullanılabilirliği endişelerini tam olarak karşılamadan yukarıda belirtilen sorunların yalnızca bir kısmını ele almaktadır.

Açıkçası, çoğu AA cüzdanı veya benzer ürünler henüz Web3'ün yaygın olarak benimsenmesini destekleyememektedir. Öte yandan, ekosistem perspektifinden bakıldığında, geliştirici tarafı çok önemli bir unsurdur. Geliştirici tarafında yeterli etki olmaksızın, sadece normal kullanıcılar için çekiciliğin ölçeklenebilirliği sağlaması pek olası değildir. Daha fazla geliştirici deneyimi optimizasyon çözümünün ortaya çıkması, ürün ekosisteminde geliştirici tarafının artan önemini göstermektedir.

Particle Network'ü örnek alarak, Web3 ürünlerinin karşılaştığı mevcut kullanıcı deneyimi zorluklarını detaylandıracak ve hedefe yönelik, kapsamlı bir teknik çözümün nasıl tasarlanacağını tartışacağız. Bu tür bir entegre çözüm, kitlesel benimseme için gerekli bir koşul olabilir. Ayrıca, Particle'ın BtoBtoC iş stratejisi, birçok proje ekibinin faydalı bulabileceği kayda değer bir yaklaşım olarak hizmet ediyor.

Partikül Ürün Yapısı Dağılımı

Kullanım engellerini azaltmaya odaklanan Particle Network, B2B2C ürün oluşturma ve ekolojik geliştirme yaklaşımını benimseyerek Web3'ün yaygın bir şekilde benimsenmesi için kapsamlı bir çözüm sunmaktadır. Çekirdek modülleri üç temel bileşenden oluşmaktadır:

zkWaaS, hizmet olarak sıfır bilgi cüzdanı anlamına gelir. Geliştiriciler, Particle'ın SDK'sını kullanarak akıllı cüzdan modüllerini dApp'lerine hızla entegre edebilirler. Cüzdan, hesap soyutlamasına dayanan, gaz ödemelerine olanak tanıyan ve Web2 tarzı OAuth gizli oturum açma ve gizli işlemler sunan anahtarsız bir akıllı sözleşme cüzdanıdır.

Particle Chain - Particle için tasarlanan özel Omnichain Hesap Soyutlama şeması, akıllı sözleşme cüzdanları için zincirler arası dağıtım, bakım ve çağırma zorluklarını ele almayı amaçlamaktadır. Ayrıca, çok zincirli işlemlerde farklı gaz tokenlerinin kullanımını basitleştiren Birleşik Gaz Tokenini de içerir.

Intent Fusion Protocol - Niyete dayalı bir Web3 etkileşim çerçevesi oluşturmak için özlü bir Alana Özgü Dil (DSL), Niyet çerçevesi, Niyet Çözücü Ağı vb. içerir. Kullanıcılar, her bir spesifik işlemi yürütmek yerine işlem niyetlerini doğrudan beyan ederek karmaşık yol değerlendirmelerinden kurtulur ve altta yatan karmaşık altyapıyı anlama ihtiyacını azaltır.

zkWaaS - Hizmet Olarak Sıfır Bilgi Cüzdanı

Cüzdan tarafında, Particle öncelikle dApp geliştiricileri için Hizmet Olarak Cüzdan (WaaS) şeklinde SDK'lar sağlar. Amaç, geliştiricilerin kapsamlı Web3 kitlesel benimseme çerçevesine entegre olmalarını sağlamaktır. Bu BtoBtoC yaklaşımı hem iş hem de ekosistem açısından çeşitli avantajlara sahiptir:

Tüketici cüzdanı pazarı oldukça rekabetçi ve işlevler giderek birbirine benziyor. Tüketici cüzdanları artık en uygun giriş noktası değildir. Öte yandan, dApp geliştiricileri, kullanıcı deneyimini geliştirmek ve daha özelleştirilebilir özellikler sağlamak için cüzdanları uygulamalarına entegre etmeyi tercih ediyor.

Tüketici tarafında kullanıcı edinmek maliyetlidir, ancak iş tarafı farklıdır. WaaS'ın kullanıcı büyümesi öncelikle SDK ile entegre dApp'lerden kaynaklanıyor. Etkili iş geliştirme ve geliştirici ilişkileri ile ekosistem organik olarak genişleyebilir.

Mevcut tüketici cüzdanları öncelikle finans ve varlıklara odaklanmaktadır ve bunlar Web3'ün geleceği için ana senaryoları temsil etmeyebilir. Web3'ün yaygın bir şekilde benimsenmesi için kullanıcı kimliği (hesaplar) ve kullanıcı işlemleri (işlem başlatma) gibi temel özellikler temel bir hizmet olarak soyutlanmalı ve daha zengin senaryolar dApp'ler tarafından ele alınmalıdır.

Tarihsel olarak, dApp'ler için giriş noktası cüzdanlar ve dApp'ler arasında yakın bir ilişki olduğunu göstermiştir. Cüzdanın dApp tarafındaki pazar payını artırmak çok önemlidir. Bu özellikle B2B2C modeli için avantajlıdır.

Kullanıcı ihtiyaçlarını karşılayan, giriş engellerini azaltan ve geliştirici entegrasyonunu kolaylaştıran bir çözüm oluşturmak için Particle'ın zkWaaS'ı üç temel özelliği ile çok önemli bir bileşen olarak hizmet vermektedir:

1. Gizli Giriş: Akıllı sözleşme cüzdanında Twitter, Google, WeChat vb. platformlardan OAuth doğrulaması gibi geleneksel Web2 giriş yöntemlerinden yararlanma. Bu, kullanıcıların özel anahtar yönetiminin kısıtlamalarından tamamen kurtulmalarını ve Web3'e en tanıdık ve basit şekilde girmelerini sağlar. Aynı zamanda, kullanıcı kimliği sıfır bilgi kanıtları kullanılarak gizlenir.

2. Gizli İşlemler: Smart Stealth Address mekanizması aracılığıyla noktadan noktaya gizlilik transferlerinin uygulanması, işlemlerde evrensel gizliliğin sağlanması. Ayrıca, ERC-4337'nin Paymaster'ını kullanmak, Akıllı Gizli Adresler (gaz sponsorluğu) için varlıkların gazsız kullanımını sağlar.

3. Kapsamlı AA Cüzdan İşlevselliği: Particle'ın cüzdan modülü ERC-4337'nin temel gereksinimlerine tamamen uygundur. ERC-4337 iş akışının tüm kritik yönlerini kapsayan Bundler, EntryPoint, Paymaster, Smart Wallet Account ve daha fazlası gibi temel bileşenleri içerir. Bu tek duraklı çözüm, DApp'lerin veya kullanıcıların akıllı cüzdanlara yönelik işlevsel taleplerini etkili bir şekilde karşılar.

Web2 Hesaplarına Dayalı Zincir Üstü Cüzdanlar için Gizli Giriş

Particle'ın gizli oturum açma çözümü, JSON Web Token'ları (JWT) kullanarak akıllı sözleşme içinde Web2 kimlik doğrulama ve cüzdan işlemlerini mümkün kılmaktadır.

JWT, geleneksel internet uygulamalarında yaygın olarak kullanılan ve sunucu tarafından istemciye verilen bir kimlik kanıtlama biçimidir. İstemci, sunucu ile her etkileşimde kimlik doğrulaması için bu kanıtı kullanır.

(Kaynak: FlutterFlow Dokümanları)

JWT'de sözleşme tarafından kimlik doğrulaması için temel oluşturan birkaç anahtar alan vardır:

- "iss" (Veren) JWT'yi vereni, yani Google, Twitter vb. gibi sunucuyu gösterir.

- "aud" (Kitle): JWT'nin amaçlandığı hizmeti veya uygulamayı belirtir. Örneğin, Twitter kullanarak Medium'da oturum açarken Twitter tarafından verilen JWT, Medium'a uygulanabilirliğini gösteren bu alanı içerecektir.

- "sub" (Özne): JWT'yi alan kullanıcı kimliğini ifade eder, genellikle UID ile tanımlanır.

Uygulamada, dahili sistemler ve harici referanslar arasında önemli bir karışıklığı önlemek için "iss" ve "sub" genellikle sabit kalır. Bu nedenle, bu parametreler sözleşme tarafından kullanıcı kimliğini belirlemek için kullanılabilir ve kullanıcıların özel anahtarlar oluşturma ve koruma ihtiyacını ortadan kaldırır.

JWT'ye karşılık gelen JSON Web Anahtarı (JWK) kavramı, sunucudaki bir dizi anahtar çiftidir. JWT yayınlanırken, sunucu bunu JWK'nın özel anahtarıyla imzalarken, ilgili açık anahtar diğer hizmetlerin imzayı doğrulaması için herkese açık hale getirilir.

Örneğin, Medium oturum açmak için Twitter'ı kullandığında, Medium JWT'nin gerçekliğini doğrulamak için Google'ın herkese açık JWK'sını kullanarak JWT'nin gerçekten Google tarafından verildiğini doğrular. Sözleşmenin JWT doğrulaması aynı zamanda JWK kullanımını da içerecektir.

Particle'ın gizli oturum açma çözümü süreci aşağıdaki şemada gösterilmektedir:

Burada spesifik ZK devresini atlayacağız, sadece süreçteki bazı kilit noktaları vurgulayacağız:

Oturum açma bilgilerini doğrulayan Doğrulayıcı sözleşme, yalnızca kullanıcının kimlik JWT'si ve bir eph_pk ile ilgili bir ZK Kanıtı algılayacaktır. İlgili cüzdan genel anahtarını veya JWT bilgilerini doğrudan elde edemez, kullanıcı gizliliğini sağlar ve harici varlıkların oturum açan kullanıcıyı zincir üzerindeki verilerden tanımlamasını önler.

eph_pk (geçici anahtar çifti) tek bir oturumda kullanılan bir anahtar çiftidir ve cüzdanın genel-özel anahtar çifti değildir. Kullanıcıların bununla ilgilenmesine gerek yoktur.

Bu sistem zincir dışı doğrulamayı destekler ve MPC (Multiparty Computation) gibi mantık kullanan sözleşme cüzdanları için kullanılabilir.

Bu, gerçekten geleneksel oturum açma yöntemlerine dayalı bir sözleşme doğrulama çözümü olduğundan, kullanıcılar Web2 hesabının devre dışı bırakılması gibi olağanüstü durumlarda diğer sosyal kişileri de koruyucu olarak belirleyebilirler.

DH Anahtar Değişimine Dayalı Gizli İşlemler

Particle'ın gizli işlemlerini tartışmadan önce, mevcut EVM sistemi içinde alıcı için gizli işlemlerin nasıl gerçekleştirileceğini, özellikle de alıcının adresinin nasıl gizleneceğini inceleyelim.

Alice'in gönderici ve Bob'un alıcı olduğunu varsayarsak, her iki taraf da bazı ortak bilgileri paylaşır:

1. Bob bir kök harcama anahtarı (m) ve gizli bir meta adres (M) oluşturur. M, m tarafından üretilebilir ve aralarındaki ilişki, kriptografik işlemlerde matematiksel bir ilişkiyi gösteren M = G * m ile temsil edilir.

2. Alice, Bob'un gizli meta adresi M'yi herhangi bir yolla elde eder.

3. Alice geçici bir özel anahtar (r) üretir ve gizli bir adres (A) oluşturmak için generate_address(r, M) algoritmasını kullanır. Bu adres Bob için hazırlanmış özel bir gizli adres görevi görür ve varlıklar alındıktan sonra Bob kontrolü ele alır.

4. Alice, geçici özel anahtar r'ye dayalı olarak geçici bir açık anahtar (R) üretir ve bunu geçici açık anahtar kayıt sözleşmesine (veya Bob'un erişebileceği karşılıklı olarak kararlaştırılmış herhangi bir konuma) gönderir.

5. Bob periyodik olarak geçici pubkey kayıt sözleşmesini tarar ve güncellenen her geçici pubkey'i kaydeder. Geçici pubkey sözleşmesi herkese açık olduğundan ve başkaları tarafından gönderilen gizlilik işlemleriyle ilgili anahtarları içerdiğinden, Bob Alice'in görmesi için hangisini gönderdiğini bilmez.

6. Bob her güncellenmiş kaydı tarar ve gizli adresi hesaplamak için generate_address(R, m) komutunu çalıştırır. Bu adreste varlıklar varsa, Alice bunu Bob'un kontrolü için oluşturmuş ve yetkilendirmiş demektir; aksi takdirde, Bob ile ilgisi yoktur.

7. Bob generate_spending_key(R, m) komutunu çalıştırarak söz konusu gizli adres için harcama anahtarını, yani p = m + hash(A) değerini üretir. Daha sonra Bob, Alice tarafından oluşturulan A adresini kontrol edebilir.

Tanımlanan süreç birçok karmaşık matematiksel işlemi basitleştirmektedir. Tüm bilgi alışverişi süreci, iki gizli ajanın kamuya açık bir ilan tahtasına şifreli mesajlar yazmasına benziyor, mesajlar sadece birbirleri tarafından deşifre edilebiliyor. Bu mesajların oluşturulma ve şifre çözme yöntemleri herkese açık olmasına rağmen, her iki aracı için gerekli olan önemli veriler sadece onlar tarafından bilinmektedir. Sonuç olarak, yabancılar yöntemleri anlasa bile, başarılı bir şifre çözme zor olmaya devam etmektedir.

Bu değişim süreci, iyi bilinen Diffie-Hellman anahtar değişim yöntemine benzemektedir. Sırlarını (Bob'un kök harcama anahtarı (m) ve Alice'in geçici özel anahtarı (r)) açıklamadan, her iki taraf da paylaşılan bir sırrı hesaplayabilir - daha önce bahsedilen gizli adres (A). DH değişimine aşina değilseniz, aşağıdaki diyagram kullanılarak metaforik anlayış kolaylaştırılabilir.

DH ile karşılaştırıldığında eklenen bir adım, paylaşılan gizli - gizli adres (A) hesaplandıktan sonra, Alice A'yı da bildiği için doğrudan özel anahtar olarak kullanılamaz. Daha önce de belirtildiği gibi, kök harcama anahtarını (m) yalnızca Bob bilir, bu da Bob'u bu gizli adresin tek denetleyicisi yapar.

Açıkçası, bu gizlilik transferi yönteminde, alınan her yeni işlem için fonlar yepyeni bir EOA adresine akacaktır. Alıcı, her adres için harcama anahtarını yinelemeli olarak hesaplamak için kök harcama anahtarını kullanabilir ve kendileriyle gerçekten ilişkili olanı bulmak için denemeler yapabilir.

Ancak yine de bir sorun var. Başlangıçta, yeni oluşturulan bu gizli adres hala bir EOA hesabıdır ve ETH veya diğer gaz tokenlerinden yoksun olabilir. Bob işlemleri doğrudan başlatamaz ve gizli işlemler gerçekleştirmek için gaz ödemesi için bir akıllı sözleşme cüzdanının Paymaster'ını kullanması gerekir. Bu nedenle, alıcı adresi için bazı değişiklikler yapılması gerekmektedir:

Sözleşme dağıtımı sırasında CREATE2 işlevindeki adres hesaplama yöntemini ilgili parametrelerle birlikte kullanarak (gizli adres A'yı sözleşmenin sahibi olarak ayarlama, vb.), bir Karşı Olgusal adres hesaplayın. Bu, henüz dağıtılmamış, hesaplanmış bir sözleşme adresidir, şu anda bir EOA'dır.

Alice fonları doğrudan bu Karşı Gerçek adrese aktarır. Bob bunu kullanmak istediğinde, doğrudan bu adreste bir sözleşme cüzdanı oluşturarak gaz ödeme hizmetinin çağrılmasını sağlar (bu adım önceden Alice veya Parçacık ağı tarafından da gerçekleştirilebilir).

Yukarıda bahsedilen Karşı Olgusal adresi Akıllı Gizli Adres olarak adlandırabiliriz. Bob, bu Akıllı Gizli Adres altındaki varlıkları aşağıdaki süreç aracılığıyla anonim olarak kullanır:

-Paymaster'a herhangi bir adresinden para yatırın ve Paymaster bir fon kanıtı (ZK tabanlı) iade edecektir.

-AA mekanizması ile, Bundler düğümüne UserOperation göndermek için bakiyesi olmayan başka bir adres kullanın ve söz konusu gizli adres altındaki varlıkları çağırın. Bob'un Paymaster'a yeni bir adres kullanarak bir fon kanıtı sağlaması yeterlidir ve Paymaster işlem paketlemesi için Bundler'a ödeme yapar.

Bu süreç Tornado Cash'in işleyişine benzer. Fon kanıtı (ZK tabanlı), Merkle ağacındaki yaprak düğümleri kümesinde bir yeniden şarjın meydana geldiğini kanıtlayabilir. Ancak harcama yapılırken, hiç kimse hangi yaprak düğümün fonlarının tüketildiğini belirleyemez ve böylece tüketici ile şarj cihazı arasındaki bağlantı kopar.

Özetle Particle, AA ile gizli adresleri akıllıca bir araya getirerek akıllı gizli cüzdanlar aracılığıyla gizli transferler gerçekleştiriyor.

Parçacık Zinciri & Omnichain Hesap Soyutlaması

Parçacık Zinciri, Omnichain Hesap Soyutlaması için tasarlanmış bir POS zinciridir. Hem günümüz hem de gelecek göz önüne alındığında, tek zincirin hakimiyeti pek olası görünmemektedir. Çok zincirli bir senaryoda kullanıcı deneyimini iyileştirmek çok önemlidir.

Şu anda ERC4337 hesap soyutlama sistemi, çok zincirli bir durumda bazı sorunlarla karşılaşabilir:

• Aynı kullanıcının farklı zincirlerdeki adresleri, sözleşmenin tasarımına bağlı olarak tek tip olmayabilir.
• Farklı zincir sözleşme cüzdanlarını yönetmek, birden fazla zincirde yönetici değiştirmek gibi manuel işlemler gerektirir. Daha kötü senaryolarda, bir zincirde yönetici izinleri güncellenir ve ardından eski yönetici doğrulama yöntemi atılırsa, diğer zincirlerde değişiklik yapmak imkansız hale gelir ve cüzdan kullanılamaz hale gelir.
• Farklı zincirlerin kullanılması, her zincir için gaz jetonlarına veya her zincirin Paymaster'ında önceden depolanmış fonlara sahip olmayı gerektirir. Geliştiriciler için bu durum zahmetli olabilir. Kullanıcıların belirli koşulları sıfır maliyetle kullanmalarını veya diğer işlevleri uygulamalarını istiyorlarsa, özel Paymaster'larını her zincire dağıtmaları ve ön finansman sağlamaları gerekir.

Particle Chain'in Omnichain Hesap Soyutlaması yukarıdaki sorunlu noktaları ele almaktadır:

• Parçacık Zinciri üzerinde AA cüzdanları oluşturun.
• Oluşturma, yükseltme ve izinleri değiştirme gibi çeşitli işlemleri diğer zincirlerle senkronize etmek için LayerZero ve diğer Arbitrary Message Bridge (AMB) çapraz zincir protokollerini kullanın. Bu, diğer zincirlerdeki cüzdanların o zincirdeki cüzdana referans olması ve ana gövdede yapılan değişikliklerin tüm cüzdanlarla senkronize edilmesi olarak anlaşılabilir.
• Tutarlı bir parametre Dağıtıcı Sözleşmesi aracılığıyla her zincirdeki cüzdanlar için tek tip adresler sağlayın.
• Farklı zincirlerdeki cüzdanlar birbirlerini AMB aracılığıyla da arayabilir, bunun için Parçacık Zincirinden başlatılması gerekmez.
• Birleşik Gaz Simgesi yayınlayın. Paymaster mekanizması ERC20'yi gaz ücreti olarak uygular. Paymaster'da gaz veya önceden depolanmış fon bulunmayan bir zincirde bile, uyumlu zincirlerde birleşik gaz tokenleri kullanan zincirler arası işlemler başlatılabilir.

Yukarıda belirtilen kullanım durumlarına ek olarak, Parçacık Zinciri aşağıdakiler için de kullanılabilir:

• zkWaaS kanıtları ve tuz üretimi için merkezi olmayan ağ.
• Farklı zincirlerdeki Bundler'lar için teşvik katmanları, Bundler'ların daha fazla ademi merkeziyetçilik sağlamasına yardımcı olur.
• Intent Fusion Protokolü için çözücü ağı olarak hizmet vermektedir.

Particle Chain'in anlatısında, birleşik gaz tokenı tüm ekosistem için temel bir değer önerisi olarak hizmet etmektedir:

• Gaz ücreti ödeme işlevi, kripto alanında defalarca doğrulanmış güçlü bir talep ve değer yakalama mantığıdır.
• Unified Gas Token, gaz katmanları kavramını mevcut halka açık zincir ekosistemlerinden soyutlamaktadır. Bu soyutlama, Parçacık Zinciri ve cüzdanlar olmadan gerçekleştirilemez. Bu nedenle, birleşik gaz jetonu tüm Particle ekosistemi için bir değerin gerçekleşmesini temsil etmektedir. Gaz katmanı ile kullanıcı etkileşimi, büyüme ve yerel token'ın farklı zincirlerdeki değeri, birleşik gaz token'ı ile karşılıklı fayda sağlayan bir ilişki içindedir.
• Birleşik gaz da Zincirsiz'e ulaşmak için itici faktörlerden biridir. Kullanıcılar için tek bir para birimi kullanmak, kullanım sürecini ve maliyetlerin anlaşılmasını büyük ölçüde kolaylaştırır. Gelecekte, çok zincirli bir senaryoda bile, kullanıcılar farkında olmayabilir ve altta yatan altyapının işleyişiyle ilgilenmeleri gerekmeyebilir. Tıpkı şu anda Web2'de veri merkezlerinin konumlarını, konfigürasyonlarını ya da kullandıkları dilleri ve veritabanlarını umursamadan sunucularla etkileşim kurmamız gibi.
• dApp'ler tarafından içe aktarılan kullanıcılar, birleşik gaz tokenini doğrudan güçlendirerek çok çeşitli kullanım durumları sunar.

Niyet Füzyon Protokolü

Tipik olarak, çeşitli dApp'leri kullanırken, kullanıcıların sürekli olarak kullanım yollarını göz önünde bulundurmaları gerekir:

• Bir DEX'te likidite yoksa, başka bir DEX'i kontrol etmek gerekir.
• Bir işlem veya görev için aynı kategorideki en uygun dApp'ı seçmek.
• Birçok özelliği kullanabilmek için önce "Onayla" kavramını anlamak.
• Cüzdanların tozunu almak, birden fazla küçük token miktarını belirli bir tokena dönüştürmek - sıkıcı bir süreç.
• Nihai bir hedefe ulaşmak için farklı uygulamalarda birden fazla adımı tamamlama. Örneğin, yüksek kaldıraçlı borç vermede: takas, stake etme, borçlanma, token elde etme, ardından tekrar takas, stake etme ve borçlanma.

Yukarıdaki içerik, mevcut DeFi ortamına yalnızca bir bakışı temsil ediyor ve Web3'te çeşitli dApp'lerin yaygın olarak benimsenmesi çağına girdiğimizde, etkileşimlerin karmaşıklığı hayal gücümüzü çok aşabilir.

Bu nedenle, belirli operasyonel adımların niyetlerle değiştirilmesi, kullanıcılar için çok farklı bir deneyim sunar. Amaçlar, işlemlere kıyasla, bildirimsel programlamaya karşı işlevsel programlamaya benzer. Beyan edici ifadeler genellikle basit bir his verir ve sonraki ayrıntılarla ilgilenmeden yalnızca ne yapılması gerektiğinin beyan edilmesini gerektirir. Bu da altta yatan katmanlarda çeşitli seviyelerde kapsüllenmiş fonksiyonel programlama ifadelerini gerekli kılar.

Benzer şekilde, Intent'lerin kullanılması da bir dizi olanaktan destek alınmasını gerektirir. Tüm süreci inceleyelim:

1. Kullanıcılar Niyetlerini, doğal dil gibi bir şekilde tanımlayarak RFS (Request For Solver) şeklinde Solver ağına gönderir. Çözücü, amaçlar için bir yorumlayıcıdır ve kullanıcılar için en uygun DEX'i arayan bir toplayıcı olan 1inch gibi yaygın çözücülerdir. Ancak bu Çözücüler, bizim vizyonumuzla karşılaştırıldığında, yeterince çok yönlü ve güçlü olmayabilir.

2. Birden fazla Çözücü yanıt verir ve birbirleriyle yarışır. Bu yanıtlar Intent DSL dilinde yazılır ve daha sonra istemci tarafından kullanıcıların anlaması kolay bir forma ayrıştırılır. Bu yanıtlar, girdi ve çıktıların sınırlarını tanımlayan Girdi Kısıtlamaları ve Çıktı Kısıtlamalarını içerir. Kullanıcılar kısıtlamaları kendileri de belirleyebilirler. Anlamak için basit bir örnek: Takas kullanılırken, kullanıcıya takas sonrasında alabileceği minimum miktar sorulur, bu da bir tür kısıtlamadır. Kullanıcılar birden fazla Çözücü tarafından sağlanan yanıtlar arasından seçim yapar.

3. Niyeti imzala.

4. Çözücü belirli bir yürütme sözleşmesi Yürütücüsü belirler ve amacı yanıt sözleşmesi Reaktörüne gönderir.

5. Reaktör, kullanıcının hesabından gerekli girdileri (belirli bir varlık gibi) toplar, amacı Yürütücüye gönderir ve ilgili mantık sözleşmesini çağırdıktan sonra işlemin çıktısını Reaktöre döndürür. Reaktör kısıtlamaları kontrol eder ve doğruysa çıktıyı kullanıcıya döndürür.

Bu süreci, gereksinimlerinizi ChatGPT'ye açıklıyormuşsunuz gibi düşünebiliriz. Gereksinimler ne kadar karmaşık olursa olsun, sizin için nihai bir sonuç üretebilir. Sonuçtan memnun kaldığınız sürece, altta yatan süreçle ilgilenmeden doğrudan kullanabilirsiniz.

Sonuç

Particle Network kapsamlı bir çözüm önermiştir: zkWaaS, Particle Chain ve Intent Fusion Protocol'ün entegre formu aracılığıyla Web2 OAuth gizlilik girişi, gizlilik işlemleri, omnichain hesap soyutlaması ve amaç tabanlı bir işlem paradigması elde eder. Her bir özellik Web3 kullanımındaki sorunlu noktaların bir kısmını ele almaktadır. Bu ilerlemeler ve optimizasyonlar, Web3 ürünlerinin ve teknolojilerinin gelecekte yaygın olarak benimsenmesi için temel oluşturacaktır. Ekosistem ve iş modelleri açısından, B2B2C paradigmasını benimsemek, tüm ürün zincirinin ölçeklenebilirliğini ve standardizasyonunu sağlamak için WaaS'ı giriş noktası olarak kullanmak, ekosistemi dApp geliştiricileriyle birlikte inşa etmek ve kullanıcılar için düşük eşikli, yüksek deneyime sahip bir Web3 dünyasını ortaklaşa oluşturmak.

Elbette, farklı projelerin Web3'ün kitlesel olarak benimsenmesi için uygulama yoluna ilişkin farklı yorumları vardır. Belirli projeleri incelemenin yanı sıra, şu anda Web3'ün karşılaştığı işe alım sürtünmesinin anlaşılmasını, kullanıcı ihtiyaçlarının ve acı noktalarının düşünülmesini ve tüm ekosistemin kolektif bağlantısı ve gelişimi için dikkate alınması gereken hususları vurgulamak için farklı çözümler kullanmayı umuyoruz.

Sorumluluk Reddi：

1. Bu makale[极客 Web3] adresinden yeniden basılmıştır, Tüm telif hakları orijinal yazara aittir[雾月，极客Web3]. Bu baskıya itirazınız varsa, lütfen Gate Learn ekibiyle iletişime geçin, onlar bu konuyu derhal ele alacaklardır.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve fikirler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirisi Gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.