บทนำ: แม้ว่ากระเป๋าเงิน AA จะลดอุปสรรคในการเข้าใช้งานของผู้ใช้ลงอย่างมาก และประสบความสำเร็จในการชำระเงินค่าก๊าซและการเข้าสู่ระบบบัญชี web2 แต่ประเด็นที่เกี่ยวข้องกับการยอมรับจำนวนมาก เช่น การเข้าสู่ระบบที่เป็นความลับ การทำธุรกรรมที่เป็นความลับ omnichain AA และโปรโตคอลฟิวชั่นเจตนา ยังคงต้องมีการพัฒนาเพิ่มเติมบนพื้นฐานของ เอเอ

แม้ว่าเราจะเห็นโซลูชันการเพิ่มประสิทธิภาพ UX ต่างๆ เช่น กระเป๋าเงิน MPC ของ ZenGo หรือกระเป๋าเงินสัญญาอัจฉริยะ เช่น Argent ช่วยลดอุปสรรคของผู้ใช้ได้อย่างมีประสิทธิภาพ แต่โซลูชันเหล่านี้จัดการปัญหาที่กล่าวมาข้างต้นเพียงบางส่วนเท่านั้น โดยไม่ครอบคลุมข้อกังวลด้านการใช้งานผลิตภัณฑ์โดยรวมทั้งหมด

เห็นได้ชัดว่ากระเป๋าเงิน AA ส่วนใหญ่หรือผลิตภัณฑ์ที่คล้ายคลึงกันยังไม่สามารถรองรับการนำ Web3 ไปใช้อย่างแพร่หลายได้ ในทางกลับกัน จากมุมมองของระบบนิเวศ ฝั่งนักพัฒนาถือเป็นส่วนสำคัญ ความน่าดึงดูดใจสำหรับผู้ใช้ทั่วไปเพียงอย่างเดียว โดยไม่มีผลกระทบเพียงพอต่อฝั่งนักพัฒนา ไม่น่าจะบรรลุความสามารถในการปรับขนาดได้ การเกิดขึ้นของโซลูชันการเพิ่มประสิทธิภาพประสบการณ์ของนักพัฒนามากขึ้น บ่งชี้ถึงความสำคัญที่เพิ่มขึ้นของฝ่ายนักพัฒนาในระบบนิเวศของผลิตภัณฑ์

ยกตัวอย่าง Particle Network เราจะอธิบายรายละเอียดเกี่ยวกับความท้าทาย UX ในปัจจุบันที่ผลิตภัณฑ์ Web3 เผชิญ และหารือเกี่ยวกับวิธีการออกแบบโซลูชันทางเทคนิคที่ครอบคลุมและตรงเป้าหมาย โซลูชันแบบผสมผสานประเภทนี้อาจเป็นเงื่อนไขที่จำเป็นสำหรับการนำไปใช้ในวงกว้าง นอกจากนี้ กลยุทธ์ธุรกิจ BtoBtoC ของ Particle ยังทำหน้าที่เป็นแนวทางสำคัญที่ทีมงานโครงการจำนวนมากอาจพบว่ามีประโยชน์

การแยกย่อยโครงสร้างผลิตภัณฑ์อนุภาค

Particle Network ซึ่งมุ่งเน้นหลักในการลดอุปสรรคในการใช้งาน ได้นำแนวทางการสร้างผลิตภัณฑ์ B2B2C และการพัฒนาระบบนิเวศมาใช้ โดยมอบโซลูชันที่ครอบคลุมสำหรับการนำ Web3 ไปใช้อย่างแพร่หลาย โมดูลหลักประกอบด้วยองค์ประกอบหลักสามประการ:

zkWaaS หมายถึงกระเป๋าเงินแบบศูนย์ความรู้ นักพัฒนาสามารถรวมโมดูลกระเป๋าสตางค์อัจฉริยะเข้ากับ dApps ของตนได้อย่างรวดเร็วโดยใช้ SDK ของ Particle กระเป๋าเงินเป็นกระเป๋าเงินสัญญาอัจฉริยะแบบไร้กุญแจซึ่งอิงตามนามธรรมของบัญชี ช่วยให้สามารถชำระเงินแบบแก๊สได้ และนำเสนอการเข้าสู่ระบบที่เป็นความลับ OAuth แบบ Web2 และการทำธุรกรรมที่เป็นความลับ

Particle Chain - โครงการ Omnichain Account Abstraction เฉพาะที่ออกแบบมาสำหรับ Particle มีจุดมุ่งหมายเพื่อจัดการกับความท้าทายในการปรับใช้ การบำรุงรักษา และการเรียกใช้ข้ามสายโซ่สำหรับกระเป๋าเงินสัญญาอัจฉริยะ นอกจากนี้ยังมี Unified Gas Token ซึ่งทำให้การใช้โทเค็น Gas ต่างๆ ในธุรกรรมแบบหลายลูกโซ่ง่ายขึ้น

Intent Fusion Protocol - รวมภาษาเฉพาะโดเมน (DSL), กรอบงาน Intent, Intent Solver Network ที่กระชับ ฯลฯ เพื่อสร้างกรอบงานการโต้ตอบ Web3 ตามเจตนา ผู้ใช้ประกาศความตั้งใจในการทำธุรกรรมของตนโดยตรง แทนที่จะดำเนินการแต่ละการดำเนินการโดยเฉพาะ ทำให้พวกเขาไม่ต้องพิจารณาเส้นทางที่ซับซ้อน และลดความจำเป็นในการทำความเข้าใจโครงสร้างพื้นฐานพื้นฐานที่ซับซ้อน

zkWaaS - Zero-Knowledge Wallet-as-a-Service

ในด้านกระเป๋าสตางค์ Particle จัดเตรียม SDK สำหรับนักพัฒนา dApp ในรูปแบบของ Wallet-as-a-Service (WaaS) เป็นหลัก จุดมุ่งหมายคือเพื่อให้นักพัฒนาสามารถรวมเข้ากับกรอบการนำ Web3 มาใช้อย่างครอบคลุม แนวทาง BtoBtoC นี้มีข้อดีหลายประการจากทั้งมุมมองทางธุรกิจและระบบนิเวศ:

ตลาดกระเป๋าสตางค์ของผู้บริโภคมีการแข่งขันสูง และฟังก์ชันการทำงานมีความคล้ายคลึงกันมากขึ้น กระเป๋าเงินของผู้บริโภคไม่ใช่จุดเริ่มต้นที่เหมาะสมอีกต่อไป ในทางกลับกัน นักพัฒนา dApp ต้องการรวม wallets เข้ากับแอปพลิเคชันของตน เพื่อปรับปรุงประสบการณ์ผู้ใช้และมอบคุณสมบัติที่ปรับแต่งได้มากขึ้น

การรับผู้ใช้จากฝั่งผู้บริโภคนั้นมีค่าใช้จ่ายสูง แต่ฝั่งธุรกิจนั้นแตกต่างออกไป การเติบโตของผู้ใช้ WaaS ส่วนใหญ่มาจาก dApps ที่ผสานรวมกับ SDK ด้วยการพัฒนาธุรกิจที่มีประสิทธิภาพและความสัมพันธ์ของนักพัฒนา ทำให้ระบบนิเวศสามารถขยายตัวได้แบบออร์แกนิก

กระเป๋าเงินผู้บริโภคในปัจจุบันมุ่งเน้นไปที่การเงินและสินทรัพย์เป็นหลัก ซึ่งอาจไม่ได้แสดงถึงสถานการณ์หลักสำหรับอนาคตของ Web3 เพื่อให้เกิดการนำ Web3 มาใช้อย่างแพร่หลาย คุณลักษณะพื้นฐาน เช่น ข้อมูลประจำตัวผู้ใช้ (บัญชี) และการดำเนินการของผู้ใช้ (การเริ่มต้นธุรกรรม) จะต้องถูกมองว่าเป็นบริการพื้นฐาน ปล่อยให้ dApps จัดการสถานการณ์ที่สมบูรณ์ยิ่งขึ้น

ในอดีต จุดเริ่มต้นสำหรับ dApps ได้แสดงให้เห็นความสัมพันธ์ที่ใกล้ชิดระหว่าง wallets และ dApps การเพิ่มส่วนแบ่งการตลาดของกระเป๋าเงินในฝั่ง dApp ถือเป็นสิ่งสำคัญ นี่เป็นข้อได้เปรียบโดยเฉพาะอย่างยิ่งสำหรับรุ่น B2B2C

เพื่อสร้างโซลูชันที่ตรงตามความต้องการของผู้ใช้ ลดอุปสรรคในการเข้าใช้งาน และอำนวยความสะดวกในการบูรณาการของนักพัฒนา zkWaaS ของ Particle ทำหน้าที่เป็นองค์ประกอบสำคัญพร้อมคุณสมบัติหลักสามประการ:

1. การเข้าสู่ระบบที่เป็นความลับ: ใช้ประโยชน์จากวิธีการเข้าสู่ระบบ Web2 แบบดั้งเดิม เช่น การตรวจสอบ OAuth จากแพลตฟอร์ม เช่น Twitter, Google, WeChat ฯลฯ บนกระเป๋าเงินสัญญาอัจฉริยะ ช่วยให้ผู้ใช้สามารถปลดปล่อยตนเองจากข้อจำกัดของการจัดการคีย์ส่วนตัวได้อย่างสมบูรณ์ โดยเข้าสู่ Web3 ในลักษณะที่คุ้นเคยและตรงไปตรงมาที่สุด ในขณะเดียวกัน ข้อมูลระบุตัวตนของผู้ใช้จะถูกปกปิดโดยใช้การพิสูจน์ความรู้แบบศูนย์

2. ธุรกรรมที่เป็นความลับ: การใช้การถ่ายโอนความเป็นส่วนตัวแบบจุดต่อจุดผ่านกลไก Smart Stealth Address เพื่อให้มั่นใจถึงความเป็นส่วนตัวสากลในการทำธุรกรรม นอกจากนี้ การใช้ Paymaster ของ ERC-4337 ช่วยให้สามารถใช้สินทรัพย์แบบไร้ก๊าซสำหรับที่อยู่ Smart Stealth (การสนับสนุนก๊าซ)

3. ฟังก์ชันกระเป๋าสตางค์ AA ที่ครอบคลุม: โมดูลกระเป๋าสตางค์ของ Particle สอดคล้องกับข้อกำหนดพื้นฐานของ ERC-4337 โดยสมบูรณ์ ประกอบด้วยองค์ประกอบที่สำคัญ เช่น Bundler, EntryPoint, Paymaster, บัญชี Smart Wallet และอื่นๆ ครอบคลุมทุกแง่มุมที่สำคัญของเวิร์กโฟลว์ ERC-4337 โซลูชันแบบครบวงจรนี้ตอบสนองความต้องการด้านการทำงานของ DApps หรือผู้ใช้กระเป๋าสตางค์อัจฉริยะได้อย่างมีประสิทธิภาพ

การเข้าสู่ระบบที่เป็นความลับสำหรับกระเป๋าเงินออนไลน์ตามบัญชี Web2

โซลูชันการเข้าสู่ระบบที่เป็นความลับของ Particle ใช้ JSON Web Tokens (JWT) ซึ่งเปิดใช้งานการตรวจสอบตัวตน Web2 และการดำเนินการกระเป๋าเงินภายในสัญญาอัจฉริยะ

JWT เป็นรูปแบบการพิสูจน์ตัวตนที่ใช้กันอย่างแพร่หลายในแอปพลิเคชันอินเทอร์เน็ตแบบดั้งเดิมที่ออกโดยเซิร์ฟเวอร์ไปยังไคลเอนต์ ไคลเอนต์ใช้หลักฐานนี้สำหรับการรับรองความถูกต้องของข้อมูลประจำตัวในการโต้ตอบกับเซิร์ฟเวอร์แต่ละครั้ง

(ที่มา: เอกสาร FlutterFlow)

มีหลายฟิลด์สำคัญใน JWT ที่เป็นพื้นฐานสำหรับการตรวจสอบตัวตนตามสัญญา:

·”iss” (ผู้ออก) หมายถึงผู้ออก JWT นั่นคือเซิร์ฟเวอร์ เช่น Google, Twitter เป็นต้น

·”aud” (Audience): ระบุบริการหรือแอปพลิเคชันที่ JWT ตั้งใจไว้ ตัวอย่างเช่น เมื่อเข้าสู่ระบบสื่อโดยใช้ Twitter JWT ที่ออกโดย Twitter จะรวมฟิลด์นี้ที่ระบุถึงการบังคับใช้กับสื่อ

·”ย่อย” (หัวเรื่อง): หมายถึงข้อมูลประจำตัวผู้ใช้ที่ได้รับ JWT ซึ่งโดยทั่วไปจะระบุโดย UID

ในทางปฏิบัติ “iss” และ “sub” โดยทั่วไปจะยังคงคงที่เพื่อหลีกเลี่ยงความสับสนอย่างมากระหว่างระบบภายในและการอ้างอิงภายนอก ดังนั้นสัญญาจึงสามารถใช้พารามิเตอร์เหล่านี้เพื่อระบุตัวตนของผู้ใช้ได้ โดยไม่จำเป็นต้องให้ผู้ใช้สร้างและปกป้องคีย์ส่วนตัว

สิ่งที่สอดคล้องกับ JWT คือแนวคิดของ JSON Web Key (JWK) ซึ่งเป็นชุดของคู่คีย์บนเซิร์ฟเวอร์ เมื่อออก JWT เซิร์ฟเวอร์จะลงนามด้วยรหัสส่วนตัวของ JWK ในขณะที่รหัสสาธารณะที่เกี่ยวข้องจะถูกเปิดเผยต่อสาธารณะสำหรับบริการอื่น ๆ เพื่อตรวจสอบลายเซ็น

ตัวอย่างเช่น เมื่อ Medium ใช้ Twitter ในการเข้าสู่ระบบ Medium จะตรวจสอบ JWT โดยใช้ JWK สาธารณะของ Google เพื่อยืนยันความถูกต้องว่า Google ออกให้จริงหรือไม่ การตรวจสอบสัญญาของ JWT จะเกี่ยวข้องกับการใช้ JWK ด้วย

กระบวนการของโซลูชันการเข้าสู่ระบบที่เป็นความลับของ Particle แสดงอยู่ในแผนภาพด้านล่าง:

เราจะข้ามวงจร ZK เฉพาะที่นี่ เพียงเน้นประเด็นสำคัญบางประการในกระบวนการ:

สัญญาผู้ตรวจสอบที่ตรวจสอบข้อมูลการเข้าสู่ระบบจะรับรู้เฉพาะหลักฐาน ZK ที่เกี่ยวข้องกับตัวตนของผู้ใช้ JWT และ eph_pk ไม่สามารถรับคีย์สาธารณะกระเป๋าสตางค์หรือข้อมูล JWT ที่เกี่ยวข้องได้โดยตรง รับประกันความเป็นส่วนตัวของผู้ใช้ และป้องกันไม่ให้หน่วยงานภายนอกระบุผู้ใช้ที่เข้าสู่ระบบจากข้อมูลออนไลน์

eph_pk (คู่คีย์ชั่วคราว) คือคู่คีย์ที่ใช้ในเซสชันเดียวและไม่ใช่คู่คีย์สาธารณะ-ส่วนตัวของกระเป๋าสตางค์ ผู้ใช้ไม่จำเป็นต้องกังวลกับมัน

ระบบนี้รองรับการตรวจสอบแบบออฟไลน์และสามารถใช้กับกระเป๋าสตางค์สัญญาที่ใช้ตรรกะ เช่น MPC (การคำนวณหลายฝ่าย)

เนื่องจากนี่เป็นโซลูชันการตรวจสอบสัญญาตามวิธีการเข้าสู่ระบบแบบดั้งเดิมอย่างแท้จริง ผู้ใช้จึงสามารถกำหนดผู้ติดต่อทางโซเชียลอื่น ๆ ให้เป็นผู้ปกครองได้ในกรณีที่รุนแรง เช่น บัญชี Web2 ที่ถูกปิดใช้งาน

ธุรกรรมที่เป็นความลับตามการแลกเปลี่ยนคีย์ DH

ก่อนที่จะหารือเกี่ยวกับธุรกรรมที่เป็นความลับของ Particle เรามาตรวจสอบวิธีบรรลุธุรกรรมที่เป็นความลับสำหรับผู้รับภายในระบบ EVM ที่มีอยู่ โดยเฉพาะการซ่อนที่อยู่ของผู้รับ

สมมติว่าอลิซเป็นผู้ส่งและบ๊อบเป็นผู้รับ ทั้งสองฝ่ายต่างแบ่งปันความรู้ทั่วไปบางประการ:

1. Bob สร้างคีย์การใช้จ่ายรูท (m) และที่อยู่เมตาที่ซ่อนตัว (M) M สามารถสร้างขึ้นได้ด้วย m และความสัมพันธ์ของพวกมันแสดงด้วย M = G * m ซึ่งบ่งบอกถึงความสัมพันธ์ทางคณิตศาสตร์ในการดำเนินการเข้ารหัส

2. อลิซได้รับเมตาแอดเดรส M ที่ซ่อนตัวของบ็อบไม่ว่าจะด้วยวิธีใดก็ตาม

3. อลิซสร้างคีย์ส่วนตัวชั่วคราว (r) และใช้อัลกอริทึม Generate_address(r, M) เพื่อสร้างที่อยู่ที่ซ่อนตัว (A) ที่อยู่นี้ทำหน้าที่เป็นที่อยู่ลับเฉพาะที่เตรียมไว้สำหรับ Bob โดย Bob จะได้รับการควบคุมเมื่อได้รับทรัพย์สินแล้ว

4. Alice สร้าง Pubkey ชั่วคราว (R) โดยอิงตามคีย์ส่วนตัวชั่วคราว r และส่งไปยังสัญญาการบันทึก Pubkey ชั่วคราว (หรือตำแหน่งใดๆ ที่ Bob สามารถเข้าถึงได้ตามที่ตกลงร่วมกัน)

5. Bob สแกนสัญญาการบันทึกเผยแพร่ชั่วคราวเป็นระยะๆ โดยบันทึกทุกสัญญาเผยแพร่เผยแพร่ชั่วคราวที่อัปเดตทั้งหมด เนื่องจากสัญญาเผยแพร่ชั่วคราวเป็นแบบสาธารณะและมีกุญแจที่เกี่ยวข้องกับธุรกรรมความเป็นส่วนตัวที่ผู้อื่นส่งมา บ็อบจึงไม่รู้ว่าอลิซคนไหนส่งให้เขาดู

6. Bob สแกนแต่ละบันทึกที่อัปเดต โดยดำเนินการ Generate_address(R, M) เพื่อคำนวณที่อยู่ที่ซ่อนตัว หากมีทรัพย์สินในที่อยู่นั้น แสดงว่าอลิซสร้างและอนุญาตให้ Bob เป็นผู้ควบคุม ไม่เช่นนั้น มันก็จะไม่เกี่ยวข้องกับบ็อบ

7. Bob ดำเนินการ Generate_spending_key(R, m) เพื่อสร้างคีย์การใช้จ่ายสำหรับที่อยู่ที่ซ่อนอยู่ เช่น p = m + hash(A) จากนั้น Bob จะสามารถควบคุมที่อยู่ A ที่สร้างโดย Alice ได้

กระบวนการที่อธิบายไว้ทำให้การดำเนินการทางคณิตศาสตร์ที่ซับซ้อนหลายอย่างง่ายขึ้น กระบวนการแลกเปลี่ยนข้อมูลทั้งหมดคล้ายกับสายลับสองคนที่เขียนข้อความที่เป็นความลับบนกระดานข่าวสาธารณะ ข้อความที่แต่ละฝ่ายสามารถถอดรหัสได้เท่านั้น แม้ว่าวิธีการสร้างและถอดรหัสของข้อความเหล่านี้จะเป็นแบบสาธารณะ แต่มีเพียงพวกเขาเท่านั้นที่รู้ข้อมูลสำคัญที่จำเป็นสำหรับเอเจนต์ทั้งสอง ดังนั้นแม้ว่าบุคคลภายนอกจะเข้าใจวิธีการต่างๆ แต่การถอดรหัสที่ประสบความสำเร็จก็ยังคงเป็นเรื่องที่เข้าใจยาก

กระบวนการแลกเปลี่ยนนี้ค่อนข้างคล้ายคลึงกับวิธีแลกเปลี่ยนคีย์ Diffie–Hellman ที่รู้จักกันดี โดยไม่ต้องเปิดเผยความลับของพวกเขา (คีย์การใช้จ่ายรูตของ Bob (m) และคีย์ส่วนตัวชั่วคราวของ Alice (r)) ทั้งสองฝ่ายสามารถคำนวณความลับที่ใช้ร่วมกัน - ที่อยู่การลักลอบ (A) ที่กล่าวถึงก่อนหน้านี้ หากไม่คุ้นเคยกับการแลกเปลี่ยน DH คุณสามารถทำความเข้าใจเชิงเปรียบเทียบได้โดยใช้แผนภาพด้านล่าง

ขั้นตอนที่เพิ่มเมื่อเปรียบเทียบกับ DH คือ หลังจากคำนวณความลับที่ใช้ร่วมกัน – ที่อยู่ซ่อนตัว (A) แล้ว จะไม่สามารถใช้เป็นคีย์ส่วนตัวได้โดยตรง เนื่องจากอลิซรู้จัก A ด้วยเช่นกัน จำเป็นต้องสร้างคีย์การใช้จ่าย (p = m + hash (A)) ถือว่า A เป็นกุญแจสาธารณะ ตามที่กล่าวไว้ข้างต้น มีเพียง Bob เท่านั้นที่รู้คีย์การใช้จ่ายรูท (m) ทำให้ Bob เป็นผู้ควบคุมที่อยู่ที่ซ่อนอยู่นี้แต่เพียงผู้เดียว

เห็นได้ชัดว่าในวิธีการโอนความเป็นส่วนตัวนี้ สำหรับธุรกรรมใหม่แต่ละรายการที่ได้รับ เงินจะไหลไปยังที่อยู่ EOA ใหม่ ผู้รับสามารถใช้คีย์การใช้จ่ายหลักเพื่อคำนวณคีย์การใช้จ่ายซ้ำๆ สำหรับแต่ละที่อยู่ โดยทดลองเพื่อค้นหาที่อยู่ที่เกี่ยวข้องอย่างแท้จริง

อย่างไรก็ตามยังคงมีปัญหาอยู่ ในขั้นต้น ที่อยู่การลักลอบที่สร้างขึ้นใหม่นี้ยังคงเป็นบัญชี EOA และอาจขาด ETH หรือโทเค็นก๊าซอื่น ๆ Bob ไม่สามารถเริ่มธุรกรรมได้โดยตรงและจำเป็นต้องใช้ Paymaster ของกระเป๋าเงินสัญญาอัจฉริยะเพื่อชำระค่าน้ำมันเพื่อให้บรรลุธุรกรรมที่เป็นความลับ ดังนั้นจึงจำเป็นต้องมีการแก้ไขบางอย่างสำหรับที่อยู่ผู้รับ:

การใช้วิธีการคำนวณที่อยู่จากฟังก์ชัน CREATE2 ระหว่างการใช้งานสัญญา ร่วมกับพารามิเตอร์ที่เกี่ยวข้อง (การตั้งค่าที่อยู่ที่ซ่อนตัว A ในฐานะเจ้าของสัญญา ฯลฯ) คำนวณที่อยู่ที่ไม่จริง นี่คือที่อยู่สัญญาที่คำนวณแล้วซึ่งยังไม่ได้ใช้งาน ซึ่งปัจจุบันเป็น EOA

อลิซโอนเงินโดยตรงไปยังที่อยู่อันเป็นการปลอมแปลงนี้ เมื่อ Bob ต้องการใช้ เขาจะสร้างกระเป๋าเงินสัญญาโดยตรงตามที่อยู่นี้ เพื่อให้สามารถเรียกใช้บริการชำระค่าน้ำมันได้ (Alice หรือเครือข่าย Particle สามารถจัดการขั้นตอนนี้ได้ล่วงหน้า)

เราสามารถอ้างถึงที่อยู่ต่อต้านข้อเท็จจริงที่กล่าวมาข้างต้นว่าเป็นที่อยู่ Smart Stealth Bob ใช้สินทรัพย์ภายใต้ Smart Stealth Address โดยไม่เปิดเผยตัวตนผ่านกระบวนการต่อไปนี้:

·ฝากเงิน Paymaster จากที่อยู่ใดๆ ของเขา และ Paymaster จะส่งคืนหลักฐานกองทุน (ตาม ZK)

·ด้วยกลไก AA ให้ใช้ที่อยู่อื่นซึ่งอาจไม่มีความสมดุล เพื่อส่ง UserOperation ไปยังโหนด Bundler โดยเรียกใช้สินทรัพย์ภายใต้ที่อยู่ซ่อนตัวดังกล่าว Bob ต้องการเพียงแสดงหลักฐานกองทุนแก่ Paymaster โดยใช้ที่อยู่ใหม่ และ Paymaster จะชำระเงินให้กับ Bundler สำหรับการรวมแพ็คเกจธุรกรรม

กระบวนการนี้คล้ายกับวิธีการทำงานของ Tornado Cash หลักฐานกองทุน (ตาม ZK) สามารถพิสูจน์ได้ว่ามีการเติมเกิดขึ้นในชุดโหนดใบบนต้น Merkle อย่างไรก็ตาม เมื่อใช้จ่าย ไม่มีใครสามารถระบุได้ว่าเงินทุนของ leaf node ใดถูกใช้ไปแล้ว ดังนั้นจึงเป็นการตัดการเชื่อมต่อระหว่างผู้บริโภคกับเครื่องชาร์จใหม่

โดยสรุป Particle ผสมผสาน AA เข้ากับที่อยู่แบบซ่อนตัวอย่างชาญฉลาด บรรลุการถ่ายโอนที่เป็นความลับผ่านรูปแบบของกระเป๋าเงินล่องหนอัจฉริยะ

ห่วงโซ่อนุภาคและนามธรรมบัญชี Omnichain

Particle Chain คือ POS chain ที่ออกแบบมาสำหรับ Omnichain Account Abstraction เมื่อพิจารณาทั้งในปัจจุบันและอนาคต การครอบงำแบบห่วงโซ่เดียวไม่น่าจะเป็นไปได้ การยกระดับประสบการณ์ผู้ใช้ในสถานการณ์แบบหลายสายโซ่ถือเป็นสิ่งสำคัญ

ปัจจุบัน ระบบนามธรรมบัญชี ERC4337 อาจประสบปัญหาบางอย่างในสถานการณ์แบบหลายสายโซ่:

• ที่อยู่ของผู้ใช้รายเดียวกันในเครือข่ายที่แตกต่างกันอาจไม่เหมือนกัน ขึ้นอยู่กับการออกแบบของสัญญา
• การจัดการกระเป๋าสตางค์สัญญาลูกโซ่ต่างๆ จำเป็นต้องมีการดำเนินการด้วยตนเองในเครือข่ายต่างๆ เช่น การเปลี่ยนผู้ดูแลระบบ ในสถานการณ์ที่เลวร้ายกว่านั้น หากสิทธิ์ของผู้ดูแลระบบได้รับการอัปเดตในห่วงโซ่เดียว ตามด้วยการละทิ้งวิธีการตรวจสอบความถูกต้องของผู้ดูแลระบบแบบเก่า จะเป็นไปไม่ได้ที่จะทำการเปลี่ยนแปลงในห่วงโซ่อื่น ๆ ส่งผลให้กระเป๋าเงินใช้งานไม่ได้
• การใช้เชนที่แตกต่างกันจำเป็นต้องมีโทเค็นแก๊สสำหรับแต่ละเชน หรือมีเงินทุนที่เก็บไว้ล่วงหน้าใน Paymaster ของแต่ละเชน สำหรับนักพัฒนา การดำเนินการนี้อาจเป็นปัญหาได้ หากต้องการให้ผู้ใช้ใช้เงื่อนไขบางอย่างโดยไม่มีค่าใช้จ่ายหรือใช้ฟังก์ชันอื่นๆ พวกเขาจำเป็นต้องปรับใช้ Paymasters ที่กำหนดเองในแต่ละเครือข่ายและจัดสรรเงินทุนล่วงหน้า

Omnichain Account Abstraction ของ Particle Chain จัดการกับปัญหาข้างต้น:

• สร้างกระเป๋าเงิน AA บน Particle Chain
• ใช้ LayerZero และโปรโตคอลข้ามสายโซ่ Arbitrary Message Bridge (AMB) อื่นๆ เพื่อซิงโครไนซ์การดำเนินการต่างๆ เช่น การสร้าง การอัพเกรด และการเปลี่ยนแปลงการอนุญาต ไปยังเครือข่ายอื่นๆ สามารถเข้าใจได้ว่าเป็นกระเป๋าเงินบนเครือข่ายอื่นที่อ้างอิงถึงกระเป๋าเงินบนเครือข่ายนั้น โดยมีการปรับเปลี่ยนเนื้อหาหลักที่ซิงค์กับกระเป๋าเงินทั้งหมด
• ตรวจสอบให้แน่ใจว่าที่อยู่เหมือนกันสำหรับกระเป๋าเงินในแต่ละเครือข่ายผ่านพารามิเตอร์ Deployer Contract ที่สอดคล้องกัน
• กระเป๋าเงินบนเครือข่ายที่แตกต่างกันสามารถโทรหากันผ่าน AMB ได้ ไม่จำเป็นต้องเริ่มต้นจาก Particle Chain
• ออกโทเค็น Unified Gas กลไก Paymaster ใช้ ERC20 เป็นค่าธรรมเนียมก๊าซ แม้แต่ในเครือข่ายที่ไม่มีก๊าซหรือเงินทุนที่เก็บไว้ล่วงหน้าใน Paymaster การทำธุรกรรมข้ามสายโซ่ที่ใช้โทเค็นก๊าซแบบรวมก็สามารถเริ่มต้นได้บนเครือข่ายที่ปฏิบัติตามข้อกำหนด

นอกเหนือจากกรณีการใช้งานที่กล่าวมาข้างต้นแล้ว Particle Chain ยังอาจใช้สำหรับ:

• เครือข่ายแบบกระจายอำนาจสำหรับการพิสูจน์ zkWaaS และการสร้างเกลือ
• ชั้นสิ่งจูงใจสำหรับ Bundlers ในเครือข่ายต่างๆ ช่วยให้ Bundlers บรรลุการกระจายอำนาจที่มากขึ้น
• ทำหน้าที่เป็นเครือข่ายตัวแก้ปัญหาสำหรับ Intent Fusion Protocol

ในการเล่าเรื่องของ Particle Chain โทเค็นก๊าซแบบครบวงจรทำหน้าที่เป็นข้อเสนอคุณค่าหลักสำหรับระบบนิเวศทั้งหมด:

• ฟังก์ชั่นการจ่ายค่าธรรมเนียมก๊าซเป็นความต้องการที่แข็งแกร่งและตรรกะการจับมูลค่าที่แข็งแกร่งที่ได้รับการตรวจสอบซ้ำแล้วซ้ำอีกในพื้นที่ crypto
• Unified Gas Token เป็นนามธรรมแนวคิดของชั้นก๊าซจากระบบนิเวศห่วงโซ่สาธารณะที่มีอยู่ สิ่งที่เป็นนามธรรมนี้หากไม่มี Particle Chain และกระเป๋าสตางค์ก็ไม่สามารถทำได้ ดังนั้นโทเค็นก๊าซแบบครบวงจรจึงแสดงถึงการตระหนักถึงคุณค่าของระบบนิเวศของอนุภาคทั้งหมด ด้วยชั้นของก๊าซ การโต้ตอบของผู้ใช้ การเติบโต และมูลค่าของโทเค็นดั้งเดิมในเครือข่ายต่างๆ มีความสัมพันธ์ที่เป็นประโยชน์ร่วมกันกับโทเค็นก๊าซแบบรวม
• Unified Gas ยังเป็นหนึ่งในปัจจัยผลักดันให้เกิด Chainless สำหรับผู้ใช้ การใช้สกุลเงินเดียวจะทำให้กระบวนการใช้งานและการทำความเข้าใจต้นทุนง่ายขึ้นอย่างมาก ในอนาคต แม้จะอยู่ในสถานการณ์แบบหลายเครือข่าย ผู้ใช้อาจไม่ทราบและไม่จำเป็นต้องกังวลกับการทำงานของโครงสร้างพื้นฐานพื้นฐาน เช่นเดียวกับที่เราโต้ตอบกับเซิร์ฟเวอร์ในปัจจุบันบน Web2 โดยไม่สนใจตำแหน่งของศูนย์ข้อมูล การกำหนดค่า หรือภาษาและฐานข้อมูลที่พวกเขาใช้
• ผู้ใช้ที่นำเข้าโดย dApps เสริมพลังให้กับโทเค็นก๊าซแบบครบวงจรโดยตรง โดยนำเสนอกรณีการใช้งานที่หลากหลาย

โปรโตคอลฟิวชั่นเจตนา

โดยทั่วไป เมื่อใช้ dApps ต่างๆ ผู้ใช้จะต้องพิจารณาเส้นทางการใช้งานอย่างต่อเนื่อง:

• หากไม่มีสภาพคล่องใน DEX หนึ่ง จำเป็นต้องตรวจสอบ DEX อื่น
• การเลือก dApp ที่เหมาะสมที่สุดภายในหมวดหมู่เดียวกันสำหรับธุรกรรมหรืองาน
• ทำความเข้าใจแนวคิด “อนุมัติ” ก่อนจึงจะสามารถใช้ฟีเจอร์ต่างๆ มากมายได้
• การปัดฝุ่นกระเป๋าเงินออก โดยการแปลงจำนวนโทเค็นขนาดเล็กหลายรายการให้เป็นโทเค็นเฉพาะ ซึ่งเป็นกระบวนการที่น่าเบื่อ
• ดำเนินการหลายขั้นตอนในแอปพลิเคชันต่างๆ เพื่อให้บรรลุเป้าหมายสุดท้าย ตัวอย่างเช่น ในการให้กู้ยืมที่มีเลเวอเรจสูง: การสลับ การปักหลัก การยืม การได้รับโทเค็น จากนั้นการสลับอีกครั้ง การปักหลัก และการยืม

เนื้อหาข้างต้นเป็นเพียงการมองคร่าวๆ ของภูมิทัศน์ DeFi ในปัจจุบัน และในขณะที่เราก้าวเข้าสู่ยุคของการนำ dApps ที่หลากหลายมาใช้อย่างแพร่หลายใน Web3 ความซับซ้อนของการโต้ตอบอาจเกินจินตนาการของเรามาก

ดังนั้น การแทนที่ขั้นตอนการปฏิบัติงานเฉพาะด้วยความตั้งใจจะมอบประสบการณ์ที่แตกต่างอย่างมากให้กับผู้ใช้ เจตนาเมื่อเปรียบเทียบกับการดำเนินการจะคล้ายกับการเขียนโปรแกรมแบบประกาศกับการเขียนโปรแกรมเชิงฟังก์ชัน ข้อความที่เปิดเผยมักจะให้ความรู้สึกตรงไปตรงมา โดยต้องการเพียงการประกาศถึงสิ่งที่ต้องทำโดยไม่ต้องคำนึงถึงรายละเอียดที่ตามมา สิ่งนี้จำเป็นต้องมีคำสั่งการเขียนโปรแกรมฟังก์ชันแบบห่อหุ้มในระดับต่างๆ ในเลเยอร์พื้นฐาน

ในทำนองเดียวกัน การใช้ Intents ต้องการการสนับสนุนจากสิ่งอำนวยความสะดวกต่างๆ มาตรวจสอบกระบวนการทั้งหมดกัน:

1. ผู้ใช้ส่ง Intent ของตน โดยอธิบายในทางใดทางหนึ่ง เช่น ภาษาธรรมชาติ ในรูปแบบของ RFS (คำขอสำหรับ Solver) ที่ส่งไปยังเครือข่าย Solver Solver เป็นตัวแปลสำหรับเจตนา และตัวแก้ปัญหาทั่วไป เช่น 1inch ซึ่งเป็นผู้รวบรวม เพื่อค้นหา DEX ที่เหมาะสมที่สุดสำหรับผู้ใช้ อย่างไรก็ตาม เมื่อเปรียบเทียบกับวิสัยทัศน์ของเราแล้ว นักแก้ปัญหาเหล่านี้อาจไม่อเนกประสงค์และทรงพลังเพียงพอ

2. นักแก้ปัญหาหลายคนตอบสนองและแข่งขันกันเอง คำตอบเหล่านี้เขียนด้วยภาษา Intent DSL ซึ่งต่อมาลูกค้าแยกวิเคราะห์ให้อยู่ในรูปแบบที่ผู้ใช้เข้าใจง่าย การตอบสนองเหล่านี้รวมถึงข้อจำกัดอินพุตและข้อจำกัดเอาต์พุต ซึ่งกำหนดขอบเขตของอินพุตและเอาต์พุต ผู้ใช้ยังสามารถระบุข้อจำกัดได้ด้วยตนเอง ตัวอย่างง่ายๆ เพื่อทำความเข้าใจ: เมื่อใช้ Swap ผู้ใช้จะได้รับแจ้งจำนวนเงินขั้นต่ำที่สามารถรับได้หลังจากการสลับ ซึ่งเป็นรูปแบบหนึ่งของข้อจำกัด ผู้ใช้เลือกจากคำตอบที่ได้รับจาก Solvers หลายคน

3. ลงนามแสดงเจตจำนง.

4. Solver ระบุผู้ดำเนินการตามสัญญาการดำเนินการที่เฉพาะเจาะจง และส่งเจตนาไปยังเครื่องปฏิกรณ์ตามสัญญาตอบสนอง

5. เครื่องปฏิกรณ์รวบรวมอินพุตที่ต้องการ (เช่น สินทรัพย์เฉพาะ) จากบัญชีของผู้ใช้ ส่งเจตนาไปยังผู้ดำเนินการ และหลังจากเรียกสัญญาตรรกะที่เกี่ยวข้องแล้ว ก็จะส่งคืนเอาต์พุตของธุรกรรมไปยังเครื่องปฏิกรณ์ เครื่องปฏิกรณ์จะตรวจสอบข้อจำกัด และหากถูกต้อง ก็จะส่งคืนเอาต์พุตให้กับผู้ใช้

เราจินตนาการถึงกระบวนการนี้ได้เหมือนกับว่าคุณกำลังอธิบายข้อกำหนดของคุณให้ ChatGPT ฟัง ไม่ว่าข้อกำหนดจะซับซ้อนเพียงใด แต่ก็สามารถสร้างผลลัพธ์สุดท้ายให้คุณได้ ตราบใดที่คุณพอใจกับผลลัพธ์ คุณสามารถใช้งานได้โดยตรงโดยไม่ต้องกังวลเกี่ยวกับกระบวนการพื้นฐาน

บทสรุป

Particle Network ได้เสนอโซลูชันที่ครอบคลุม: ผ่านรูปแบบที่ผสานรวมของ zkWaaS, Particle Chain และ Intent Fusion Protocol ทำให้สามารถเข้าสู่ระบบความเป็นส่วนตัวของ Web2 OAuth ธุรกรรมความเป็นส่วนตัว การสร้างบัญชี Omnichain และกระบวนทัศน์ธุรกรรมตามเจตนา แต่ละฟีเจอร์จะแก้ไขส่วนหนึ่งของปัญหาในการใช้งาน Web3 ความก้าวหน้าและการเพิ่มประสิทธิภาพเหล่านี้จะทำหน้าที่เป็นรากฐานสำหรับการนำผลิตภัณฑ์และเทคโนโลยี Web3 ไปใช้อย่างแพร่หลายในอนาคต ในแง่ของระบบนิเวศและโมเดลธุรกิจ การนำกระบวนทัศน์ B2B2C มาใช้ โดยใช้ WaaS เป็นจุดเริ่มต้นในการขับเคลื่อนความสามารถในการปรับขนาดและมาตรฐานของห่วงโซ่ผลิตภัณฑ์ทั้งหมด ร่วมสร้างระบบนิเวศร่วมกับนักพัฒนา dApp และร่วมกันสร้าง Web3 ที่มีเกณฑ์ต่ำและมีประสบการณ์สูง โลกสำหรับผู้ใช้

แน่นอนว่า โครงการต่างๆ มีการตีความเส้นทางการดำเนินงานที่แตกต่างกันออกไปสำหรับการนำ Web3 มาใช้เป็นจำนวนมาก นอกเหนือจากการพิจารณาโครงการที่เฉพาะเจาะจงอย่างละเอียดแล้ว เราหวังว่าจะใช้โซลูชันที่แตกต่างกันเพื่อเน้นความเข้าใจเกี่ยวกับอุปสรรคในการเริ่มต้นใช้งานที่ Web3 เผชิญอยู่ในปัจจุบัน การไตร่ตรองถึงความต้องการของผู้ใช้และประเด็นปัญหา และข้อพิจารณาสำหรับการเชื่อมต่อโดยรวมและการพัฒนาระบบนิเวศทั้งหมด

ข้อสงวนสิทธิ์：

1. บทความนี้พิมพ์ซ้ำจาก [极客 Web3] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [雾月，极客Web3] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีมงาน Gate Learn แล้วพวกเขาจะจัดการโดยเร็วที่สุด
2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว