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

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

เคลื่อนไปเกิน 12 คำ

อุตสาหกรรมของเราชอบคําศัพท์และ "ไร้เมล็ด" เป็นหนึ่งในผลิตภัณฑ์ล่าสุดที่ดึงดูดความสนใจ ในขณะที่เราทุกคนยอมรับว่าการคาดหวังให้ผู้ใช้จัดเก็บคีย์ส่วนตัวอย่างปลอดภัยนั้นทําไม่ได้และส่งผลให้สูญเสียเงินหลายล้านดอลลาร์คําถามยังคงอยู่: ถ้าเราไม่แสดงวลีเมล็ดพันธุ์ให้ผู้ใช้เห็นเราจะเก็บกุญแจไว้ที่ไหน?

หากไม่มี Account Abstraction (AA) โซลูชันที่มีอยู่ส่วนใหญ่จะใช้ Multi-Party Computation (MPC) เพื่อกระจายคีย์ออกเป็นหลายส่วนและสร้างเกณฑ์สําหรับการทําธุรกรรม โซลูชันเหล่านี้มักอ้างว่าเป็นการดูแลตนเอง อย่างไรก็ตามสิ่งนี้ไม่ถูกต้องทั้งหมด ตัวอย่างเช่น Binance จัดเก็บคีย์หนึ่งส่วนแบ่งโดยทําหน้าที่เป็นผู้ดูแลในกรณีที่ผู้ใช้ทําอุปกรณ์หาย การตั้งค่านี้หมายความว่าแม้จะมีการอ้างสิทธิ์ แต่ผู้ใช้ก็ไม่สามารถควบคุมคีย์ของตนได้อย่างแท้จริงและยังคงต้องพึ่งพาเอนทิตีแบบรวมศูนย์สําหรับการกู้คืนคีย์

นอกจากนี้หากมีคีย์แชร์ใดๆ หลุดออกมา ไม่มีทางยกเลิกคีย์จากบัญชีหลักได้ การยกเลิกไม่สามารถทำได้เพราะบัญชี EOA (Externally Owned Accounts) ไม่รองรับการหมุนเวียนคีย์ ซึ่งหมายความว่าคีย์ที่หลุดจะเป็นส่วนหนึ่งของบัญชีตลอดไป สิ่งนี้นำเสนอความเสี่ยงด้านความปลอดภัยที่สำคัญ เนื่องจากคีย์ที่ถูกขโมยไม่สามารถแทนที่หรือลบออกได้ ทำให้บัญชีเป็นเป้าหมายของการโจมตีอย่างไม่มีที่สิ้นสุด

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

1. บัญชีที่เขียนโปรแกรมได้เต็มรูปแบบ: การส่วนแยกบัญชี

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

กับ AA ทุนถูกเก็บไว้ในสัญญาอัจฉริยะ และการเป็นเจ้าของบัญชีถูกกำหนดโดยสัญญาเหล่านี้ บัญชีที่เข้ากันได้กับ EIP-4337 มีสองส่วนในการทำธุรกรรมของพวกเขา

1. ส่วนแรกคือการยืนยันตัวตนที่ทำให้เจ้าของบัญชีได้รับการยืนยันบนเชือง
2. ส่วนที่สองคือการดำเนินการ ซึ่งทำการดำเนินการข้อความ

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

ดังนั้นเมื่อเราพูดถึงการรับรองบัญชีดั้งเดิม (EOAs) การรับรองเท่าเทียมกับการให้สิทธิ์ใช้งาน ด้วย AA การให้สิทธิ์ใช้งานเป็นไปตามโปรแกรมได้ ดังนั้นนักพัฒนาสามารถกำหนดระบบควบคุมการเข้าถึงที่ใช้บทบาทในการควบคุมและปฏิบัติตามหลักการของการให้สิทธิ์น้อยที่สุด

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

ข้อดีและข้อเสียของระบบการจัดการคีย์ที่แตกต่างกัน

ฉันจะสรุป Passkeys (Consumer Secure Enclaves), โซลูชันที่ใช้ MPC, โซลูชันที่ใช้ Cloud-Based TEE, โซลูชันที่เป็น Custodial, Traditional 12 คำ และ Session Keys อย่างรวดเร็ว หลังจากนั้นจะอธิบายเกี่ยวกับการสอดคล้องที่ดีที่สุด

1. คำ 12 คำแบบดั้งเดิม - (secp256k1) -

Bitcoin และ Ethereum สนับสนุน secp256k1ขั้นตอน ECC (elliptic curve cryptography) ในการสร้างกุญแจส่วนตัวและเก็บไว้บนอุปกรณ์ของผู้ใช้ วิธีนี้ถูกนำมาใช้กันอย่างแพร่หลายใน EOAs และสามารถนำมาใช้ในบัญชีอัจฉริยะ. ในการใช้งาน แอปพลิเคชันกระเป๋าเงินจะสร้างคีย์ส่วนตัวโดยใช้อัลกอริทึมการสร้างคีย์แบบสุ่มแล้วจัดเก็บคีย์ส่วนตัวในพื้นที่จัดเก็บร่วมกัน

การใช้ secp256k1 มีข้อได้เปรียบหลายอย่าง: ไม่ต้องเสียค่า gas เพิ่มเติม ราคาถูก และง่ายต่อการตรวจสอบใน onchain ผ่าน precompile ecrecover นอกจากนี้ยังเป็นการรักษาเก็บตัวเองเนื่องจากผู้ใช้เท่านั้นที่สามารถเข้าถึงกุญแจได้

อย่างไรก็ตาม ยังคงมีข้อเสียบางอย่าง:

1. การศึกษาผู้ใช้ให้เก็บกุญแจของพวกเขาอย่างปลอดภัยในกรณีที่พวกเขาสูญเสียอุปกรณ์ของพวกเขา นั้นเป็นเรื่องท้าทาย
2. โทรจันหรือมัลแวร์อาจทำการขโมยคีย์ส่วนตัวจากอุปกรณ์ของผู้ใช้เนื่องจากมันถูกเก็บไว้ในพื้นที่จัดเก็บที่ใช้ร่วมกัน

NIST ไม่รองรับเส้นโค้ง secp256k1 ซึ่งหมายความว่ามันไม่ได้รับการสนับสนุนโดยกรอบงานยอดนิยมและฮาร์ดแวร์ส่วนใหญ่

2. Passkeys (Consumer Secure Enclaves)

อุปกรณ์ที่ทันสมัยเกือบทั้งหมดมีสององค์ประกอบหลัก: ระบบปฏิบัติการ (พร้อมที่เก็บข้อมูลที่ใช้ร่วมกันที่เกี่ยวข้อง) และ Secure Enclave ระบบปฏิบัติการจัดการการดําเนินงานส่วนใหญ่ยกเว้นงานที่ละเอียดอ่อนเช่นการปกป้องข้อมูลไบโอเมตริกซ์คีย์การเข้ารหัสการเข้ารหัสและการปลดล็อกอุปกรณ์

นักพัฒนาได้สร้างชิปเฉพาะที่ชื่อว่า Secure Enclave เพื่อจัดการการดำเนินการที่ละเอียดอ่อนเหล่านี้แยกต่างหาก Secure Enclave ทำงานอย่างคล้ายกับกระเป๋าเงินฮาร์ดแวร์ มันทำงานอย่างอิสระโดยรัชศกษาข้อมูลที่ละเอียดอ่อนและเจ้าของอุปกรณ์ไม่สามารถเข้าถึงเนื้อหาได้ โชคดีที่ Secure Enclave รองรับการดำเนินการทางคริปโตเกรซี เช่น การสร้างกุญแจส่วนตัวและการเซ็นต์ข้อความด้วยกุญแจเหล่านั้น นับเป็นอุปกรณ์ที่สนับสนุนการทำงานเชิงคณิตศาสตร์ของ Ethereum (secp256k1) แต่ Secure Enclave รองรับเส้นโค้ง p256 แทนเพื่อให้การตรวจสอบ P256 เป็นที่เป็นธรรมชาติ@getclave"">ทีม @getclave) ของ提议RIP-7212และเกือบทุกโรลอัพขนาดใหญ่ตอนนี้รองรับมัน

และส่วนที่ดีที่สุดของ Secure Enclaves คือเราสามารถสร้างกุญแจส่วนตัวภายใน Secure Enclaves ด้วยการพิสูจน์ตัวด้วยชีวภาพเพียงแค่คลิกเดียวที่ทำให้มีประสบการณ์การเข้าร่วมที่ดีที่สุดด้วยความปลอดภัยที่ดีที่สุดที่มีอยู่บนอุปกรณ์ที่ทันสมัย - ระดับฮาร์ดแวร์ แต่ก็ยังมีข้อเสียบางอย่าง

• การยืนยัน P256 โดยไม่มี RIP-7212 เป็นเรื่องที่ใช้เงินมากและเพิ่มความเสี่ยงของข้อบกพร่อง
• เนื่องจากไม่สามารถทำการสกัดคีย์ได้ ความสามารถในการกู้คืนข้อมูล (Passkeys ทำให้สามารถกู้คืนข้อมูลได้ แต่มันยังไม่เพียงพอ) เป็นคุณสมบัติที่ขาดหาย
• ถ้าโดเมนเว็บของ passkey หรือแอปพลิเคชัน Secure Enclave (SE) หยุดทำงาน ผู้ใช้จะไม่สามารถเข้าถึงกุญแจส่วนตัวได้เนื่องจาก Secure Enclave ถูกออกแบบให้เป็นส่วนที่เลือกและเป็นอิสระ โดยไม่มีแอปพลิเคชันหรือโดเมนเว็บที่เกี่ยวข้อง ไม่มีทางดึงข้อมูลหรือปฏิสัมพันธ์กับกุญแจส่วนตัว ทำให้ผู้ใช้ไม่สามารถดำเนินการทางคริปโตกราฟฟิกที่จำเป็นได้ - ฉันจะอธิบายวิธีแก้ปัญหานี้

3. โซลูชันการจัดการคีย์ที่ใช้ SSS

โซลูชัน SSS (Shamir’s Secret Sharing) สร้างทางให้กำจัดจุดล้วนในการล้มเหลวที่ระบบการจัดการคีย์แบบดั้งเดิมมี โดยพวกเขาเกือบแยกคีย์เป็นส่วนต่าง ๆ และสร้างค่าเข้าถึงคีย์ โดยการกระจายส่วนเหล่านี้ SSS ยืนยันว่าไม่มีองค์กรเดียวถือคีย์ทั้งหมด ซึ่งเสริมความปลอดภัย

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

ดังนั้นผู้ใช้จะมอบหมายควบคุมกระเป๋าเงินของตนให้กับฝ่ายอื่นๆ ด้วยอิทธิพลของคณะบุคคลหลายคน (MPC) เป็นวิธีที่มีประสิทธิภาพในการมอบหมายความรับผิดชอบในการจัดการคีย์ให้กับฝ่ายที่แตกต่างกัน แต่ก็ยังมีข้อเสียบางประการ

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

ข้อเสียเปรียบที่สําคัญอีกประการหนึ่งของ SSS คือการสร้างคีย์ส่วนตัวขึ้นมาใหม่โดยปกติจะอยู่ในเบราว์เซอร์ เป็นความเสี่ยงด้านความปลอดภัยอย่างมากสําหรับคีย์ข้อความธรรมดาที่จะพร้อมใช้งานฝั่งไคลเอ็นต์ TSS ไม่เคยสร้างคีย์ใหม่และใช้ MPC เพื่อรวมการลงนามในหุ้นหลัก

4. โซลูชัน TEE ที่ใช้เทคโนโลยี Cloud

ฉันไม่คิดว่า Cloud-Based Trusted Execution Environments (TEEs) และโซลูชันที่ใช้ SSS นั้นต่างกันมาก แต่ฉันยังอยากจะอธิบายว่าพวกเขาทำงานอย่างไร Trusted Execution Environments ทำงานตรงตามที่ถูกเขียนไว้ พวกเขาเปลี่ยนแปลงไม่ได้ (อย่างน้อยพวกเขาอ้างว่าเป็นเช่นนั้น) และ TEEs ไม่แสดงสิ่งที่อยู่ข้างในไปยังเจ้าของ TEEs พวกเขาถูกออกแบบให้ทำงานอย่างซื่อสัตย์—ทำสิ่งที่ถูกต้อง แม้ไม่มีใครมองอยู่ ดังนั้น คีย์ไม่ถูกเปิดเผยให้กับลูกค้า ในทันทีที่ TEEs ทำงานอย่างถูกต้อง

โดยใช้ TEEs เราสามารถสร้างชั้นการจัดการคีย์ที่นักพัฒนาสามารถใช้วิธีการตรวจสอบที่แตกต่างกันได้และ TEE สามารถตรวจสอบได้หลังจากที่ได้รับการตรวจสอบ TEE จะลงชื่อข้อความด้วยกุญแจส่วนตัวที่เกี่ยวข้องกับผู้ใช้และตรวจสอบได้ในเชื่อมโยง

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

Cloud-based TEEs ดูมีความสมดุลในทฤษฎี แต่ในอดีตเราเห็นช่องโหว่เช่น com.sgx.failในคลาวด์ TEEs โดยมีข้อดีของ TEEs คือ ถึงแม้จะมีทางเข้าหลังบ้านหรือช่องโหว่ ผู้โจมตีจะต้องมีการเข้าถึงทางกายภาพถึง TEE ดังนั้นฮาร์ดแวร์ของผู้ใช้ (Secure Enclave - Passkeys) เป็นอย่างมากเนื่องจากฮาร์ดแวร์ของผู้ใช้เก็บคีย์ภายใน Secure Enclave ของผู้ใช้และเฉพาะเจ้าของเท่านั้นที่สามารถเข้าถึงคีย์ได้ ในขณะที่ Cloud TEEs เก็บคีย์ภายในคลาวด์ ซึ่งทำให้เป็นที่ที่อ่อนแอต่อการโจมตี

ไม่ใช่ป้อมป้องความปลอดภัยของคุณ ไม่ใช่เหรียญของคุณ

เหมือนที่ฉันได้กล่าวไว้ TEE มีข้อดีบางประการ เช่น ใช้วิธีการตรวจสอบสิทธิ์เกือบทั้งหมดโดยไม่มีการบล็อกข้อมูลรหัสลับ อย่างไรก็ตาม TEE ก็ยังมีข้อเสียบางอย่างด้วย:

หากผู้ให้บริการปิดเซิร์ฟเวอร์ ก็จะทำให้เงินทุนของผู้ใช้ถูกระงับและไม่มีใครสามารถเข้าถึงได้ คีย์ถูกเก็บไว้ภายใน Cloud TEE ซึ่งหมายความว่าพวกเขาสามารถเซ็นเซอร์ผู้ใช้ได้ การพึ่งพาเฉพาะ TEEs สำหรับการจัดการคีย์จะสร้างจุดล้มเหลวเพียงจุดเดียว

คีย์เซสชัน: วิธีใหม่สำหรับสิทธิ์จำกัด

เราได้พูดถึงคีย์ถาวรแล้ว แต่ถ้าเราสามารถสร้างคีย์ชั่วคราวที่มีสิทธิ์เข้าถึงทรัพย์สินจำกัดและหายไปหลังจากเวลาที่ผู้ใช้ตั้งค่าได้? Session Key ช่วยให้เราทำได้:

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

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

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

สมาคมการยืนยันตัวตนและการจัดการคีย์ที่ดีที่สุดสำหรับกรณีการใช้งานต่าง ๆ

ฉันได้อธิบายระบบการจัดการกุญแจที่แตกต่างและข้อดีและข้อเสียของแต่ละระบบ ด้วยพลังของ AA เราสามารถผสานรวมระบบการจัดการกุญแจเหล่านี้และสร้างโครงสร้างที่มีพลังงานมากพร้อมกับการสูญเสียต่ำที่สุด มาอธิบาย C.1) Passkey + recovery with timelock - Clave - แอพฯทางการเงินที่เก็บเงินที่มีค่า

วิธีการรับรองตัวตนที่ใช้ Secure Enclave (passkeys) ให้มีความปลอดภัยระดับฮาร์ดแวร์; อย่างไรก็ตาม ความสามารถในการกู้คืนข้อมูลของพวกเขามักจะไม่เพียงพอสำหรับผู้ใช้ส่วนใหญ่ โชคดีที่ AA ช่วยให้นักพัฒนาสามารถรวมวิธีการเซ็นต์ต่างๆ และใช้ในบัญชีเดียวกันได้ โดยการเพิ่มการรับรองคืนข้อมูลในบัญชีสมาร์ท เราสามารถแก้ไขปัญหาการกู้คืนข้อมูลที่ passkeys มีได้

มีตัวเลือกการกู้คืนหลายรูปแบบ เช่น social recovery, universal recovery (ZK-Email Based Recovery) และ MPC-based recovery อย่างไรก็ตาม ในความเห็นของฉัน สำหรับแอปพลิเคชันการเงินที่ออกแบบมาเพื่อให้เป็น self-custodial อย่างเต็มรูปแบบ social recovery จะช่วยแก้ไขส่วนใหญ่ของปัญหา ที่ Clave เราได้สร้างโมดูล social recovery และกำลังทำงานกับ Universal Recovery

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

แอปพลิเคชันที่ไม่ใช่ทางการเงินเช่นแอป social-Fi และเกมที่ไม่ centralize ต้องการวิธีที่ง่ายขึ้นในการดำเนินการธุรกรรม โดยที่ไม่ต้องให้ผู้ใช้ลงนามในแต่ละธุรกรรม วิธีไหน? นี่คือคำตอบ:

1. Passkey + การกู้คืนด้วยการล็อคเวลา + กุญแจเซสชั่น - แอปโซเชียลมือถือ

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

วันนี้ส่วนใหญ่ของผู้ใช้ไม่ได้ตรวจสอบว่าพวกเขากำลังลงนามอะไรเมื่อเล่นเกมหรือโต้ตอบกับ dApp ซึ่งเป็นเรื่องอันตรายเพราะส่วนหน้าที่เป็นอันตรายอาจทำให้ผู้ใช้สูญเสียสินทรัพย์ทั้งหมด

Session keys เป็นทางเลือกที่ดีกว่านี้ ผู้ใช้สามารถตรวจสอบระยะเวลาของเซสชันที่จะใช้งานและทรัพย์สินที่เซสชันสามารถเข้าถึงได้ เพื่อลดความจำเป็นในการเชื่อมั่นใน dApp หลังจากสิ้นสุดระยะเวลาเซสชัน ผู้ใช้ไม่ต้องกังวลเรื่องการอนุมัติอีกต่อไป = ไม่ต้องการอนุมัติอีกต่อไปrevoke.cashชอบแอปพลิเคชัน :)

2. MPC หรือ cloud TEE based signer + self-custodial signer for escape

ข้อเสียเปรียบของเลเยอร์การจัดการคีย์ของบุคคลที่สามที่ใช้ MPC หรือ Cloud TEE คือส่วนใหญ่ไม่ใช่การดูแลตนเองและมีส่วนประกอบส่วนกลางที่สําคัญ อย่างไรก็ตาม dApps บางรุ่นต้องการกระเป๋าเงินแบบฝังตัวโดยไม่มีค่าใช้จ่ายก๊าซเพิ่มเติมซึ่งจําเป็นต้องใช้โซลูชันที่ใช้ MPC หรือ Cloud TEE การเพิ่มผู้ลงนามเพิ่มเติมสําหรับ "ความโกรธ" สามารถแก้ปัญหาการเซ็นเซอร์ที่ระบบการจัดการหลักเหล่านี้มีและยังช่วยลดปัญหาทางกฎหมายที่อาจเกิดขึ้น dApps เหล่านี้อาจเผชิญ คุณต้องมีกระเป๋าเงินอัจฉริยะเพื่อสร้างสิ่งนี้เนื่องจากไม่สามารถหมุนคีย์ได้ด้วย EOAs

มีแอปพลิเคชันหลายรายการที่ใช้สถาปัตยกรรมการจัดการคีย์นี้แล้ว

3. 12 คำ + ฮาร์ดแวร์ไซน์เนอร์เพื่อเพิ่มความปลอดภัย - ประสบการณ์การใช้งานส่วนขยายเบราว์เซอร์ DeFi

ผู้ใช้ DeFi ชื่นชอบประสบการณ์ขยายเว็บและการเปลี่ยนพฤติกรรมของผู้ใช้เป็นสิ่งที่ยากที่สุดในโลกปัจจุบัน ดังนั้น ทำไมไม่สร้างทางเลือกที่ดีกว่า? การผสมผสานฮาร์ดแวร์ไซน์เนอร์ (Secure Enclave หรือ Passkey Signer) กับวลีเซ็ด 12 คำที่สามารถเข้าถึงได้ผ่านส่วนขยายยังสามารถแก้ปัญหาของคีย์ส่วนตัวที่หลุดออกไปได้ วิธีการนี้ปรับปรุงความปลอดภัยพร้อมทั้งไม่ต้องเปลี่ยนการกระทำของผู้ใช้ มีทีมหลายทีมในอุตสาหกรรม AA ที่กำลังทำงานเพื่อเปิดใช้งานนี้ (เช่น@myBraavos)

บัญชีสมาร์ทไม่เก่งพอ

สมมติว่าคุณเป็นผู้ใช้ที่สร้าง EOA ครั้งแรก @MetaMaskแล้วค้นพบทางเลือกเช่น Zerion คุณตัดสินใจที่จะใช้@zerion, และที่คุณต้องทำคือนำ seed phrase ของคุณเข้าสู่ระบบ - ง่ายดาย ตอนนี้พยายามจินตนาการว่าจะทำเช่นเดียวกันบน Starknet ที่กระเป๋าเงินทั้งหมดเป็นบัญชีอัจฉริยะ คุณไม่สามารถทำได้เพราะ Braavos และ Argent ไม่สามารถใช้งานร่วมกันได้ ปัญหานี้ยังมีอยู่ในระบบนิเวศ EIP-4337 ด้วย @zkSync’s native AA.

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

นอกจากนี้ "rage quit" ควรเป็นคุณสมบัติเริ่มต้นเนื่องจากตัวแสดงกลายเป็นผู้ที่สำคัญในระบบการจัดการที่สำคัญเกือบทุกระบบ ควรทำให้ผู้ใช้สามารถเปลี่ยนผู้เซ็นต์หรือสลับสัญญาสมาร์ทได้ง่ายขึ้น และการโฮสต์เองควรเป็นตัวเลือกเริ่มต้นสำหรับผู้ใช้ มีมาตรฐานบัญชีสมาร์ทโมดูลาร์สองแบบ: ERC-6900 และ ERC-7579 ทั้งสองพยายามทำให้บัญชีสมาร์ทฉลาดขึ้นอย่างเท่าเทียม

ขอบคุณพิเศษ Derek , Konrad, และNoamสำหรับคำติชมและความคิดเห็น!

คำปฏิเสธ:

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