ไม่กี่เดือนมาแล้ว ทีมคริปโตที่ a16z ได้เผยแพร่ท้าทายนาคาโมโต้ซึ่งเป็นรายการปัญหาที่สําคัญที่สุดที่ต้องแก้ไขในบล็อกเชน ประการที่สี่ดึงดูดความสนใจของเราเป็นพิเศษ: "ความเป็นส่วนตัวที่ตั้งโปรแกรมได้" เนื่องจากเราคิดเรื่องนี้มาระยะหนึ่งแล้ว วันนี้เรากําลังเสนอโซลูชันแรกโดยใช้การเข้ารหัสแบบ homomorphic และโปรโตคอลสัญญาอัจฉริยะที่เป็นความลับ fhEVM ของเรา (หากคุณไม่คุ้นเคยกับ fhEVM คุณสามารถอ่านบทความของเราเกี่ยวกับความลับ โทเคน ERC20 และ การประมูลบนหลักการ).

fhEVM เป็น EVM ปกติที่มีคอมไพล์ล่วงหน้าบางอย่างที่ช่วยให้สามารถประมวลผลบนสถานะที่เข้ารหัสโดยใช้ไลบรารีการเข้ารหัสแบบโฮโมมอร์ฟิก TFHE-rs ของเรา จากมุมมองของนักพัฒนาไม่มีการเข้ารหัสที่เกี่ยวข้อง: พวกเขาเพียงแค่เขียนรหัส Solidity โดยใช้ประเภทข้อมูลที่เข้ารหัสที่เรามีให้ (euint32, ebool ฯลฯ ) ข้อดีอย่างหนึ่งของ fhEVM เทียบกับโซลูชันความเป็นส่วนตัวอื่น ๆ คือข้อมูลและการคํานวณทั้งหมดเกิดขึ้นบนเชน ซึ่งหมายความว่าคุณสามารถมีความสามารถในการเขียนและความพร้อมใช้งานของข้อมูลในระดับเดียวกับสัญญาข้อความธรรมดาทั่วไป

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

ในบทความนี้ เราจะแสดงวิธีการสร้าง ERC20 token ที่เป็นไปตามข้อกำหนด โดยใช้ onchain DIDs โค้ดต้นฉบับสำหรับบทแนะนำนี้สามารถค้นพบได้ในโฟลเดอร์ตัวอย่างของที่เก็บข้อมูล fhEVM

การรวมกลไกการหลีกเลี่ยงเพื่อใช้บนเชน, DIDs ที่ลับ

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

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

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

ปัญหา: ทุกคนจะเห็นตัวตนของทุกคน!

โชคดีที่เรามีวิธีแก้ปัญหา: การเข้ารหัสแบบ homomorphic และโดยเฉพาะอย่างยิ่ง fhEVM! ด้วยความสามารถในการเขียนบนสถานะที่เข้ารหัสเราจึงสามารถโฮสต์ DIDs ของผู้ใช้ได้โดยตรงในรูปแบบที่เข้ารหัสและให้แอปพลิเคชันที่เป็นไปตามข้อกําหนดตรวจสอบแอตทริบิวต์โดยใช้การเรียกสัญญาอย่างง่าย ความสามารถในการจัดการข้อมูลประจําตัวผ่านสัญญาอัจฉริยะซึ่งเราเรียกว่า "Identity Abstraction" นั้นคล้ายกับวิธีที่เราสามารถจัดการเงินผ่านสัญญาอัจฉริยะด้วย Account Abstraction

บทแนะนำนี้มี 3 ส่วน:

• การทำการสร้างเสมือนบุคคล ถูกดำเนินการผ่านสัญญาเรจิสทรีที่รับผิดชอบการบริหารจัดการเรื่องตัวตนและการรับรอง ที่นี่เราสมมติว่า DIDs เป็นบัตรประจำตัวทางการของรัฐบาล ทะเบียนเองถูกบริหารจัดการโดยเจ้าพนักงานหลัก (เช่น AFNIC) ซึ่งสามารถสร้างผู้ลงทะเบียน (เช่น บริษัท KYC เช่น Onfido, Jumio, เป็นต้น) ซึ่งจากนั้นสามารถสร้าง DIDs ของผู้ใช้ได้ ผู้ใช้จึงผ่านผู้ลงทะเบียนของตนเพื่อจัดการและอัปเดต DIDs ของตน
• การประกาศเพื่อหมายถึงในสัญญาที่เข้ารหัสกลุ่มกฎระเบียบสำหรับการโอนโทเค็นระหว่างบุคคล โดยขึ้นอยู่กับข้อมูลที่มีอยู่ใน DIDs ของพวกเขา มันทำหน้าที่ในระดับสัญญาแทนการใช้งานในระดับผู้ใช้
• การโอนที่เป็นไปตามกฎระเบียบถูกนำมาใช้ในสัญญา ERC20 ที่เป็นไปตามกฎระเบียบที่ใช้สัญญากฎหมายเพื่อบังคับการปฏิบัติตามในการโอนโทเคน โดยไม่มีการเปลี่ยนแปลงใด ๆ ใน ERC20 API เอง ในตัวอย่างนี้เราใช้สัญญา ERC20 ที่เป็นไปตามกฎระเบียบที่มีการซ่อนยอดคงเหลือและยอดเงิน แต่ก็สามารถทำงานได้เช่นเดียวกันกับโทเคน ERC20 ปกติแบบปลายทาง

สถาปัตยกรรมของ Onchain Confidential DID Protocol ของเรา

สัญญาทะเบียนตัวตน

สัญญา IdentityRegistry เป็นทะเบียนของผู้ใช้ DIDs ที่ออกโดยผู้ลงทะเบียนและรวมเซ็ตของตัวระบุที่เข้ารหัส เช่น สัญชาติ อายุ เลขประจำตัวประชาชน ฯลฯ ตัวระบุเหล่านี้ถูกเก็บเป็นค่า 32 บิตที่เข้ารหัส (euint32)

สัญญายังจัดการสิทธิ์ เช่น:

• การให้เจ้าของสัญญา (เช่น AFNIC) เพิ่ม ลบ หรืออัปเดตผู้จดทะเบียน
• การทำให้ผู้ลงทะเบียนสามารถเพิ่ม ลบหรืออัปเดต DID ของผู้ใช้ที่พวกเขาสร้าง
• อนุญาตให้ผู้ใช้อนุญาตให้สัญญาอัจฉริยะเข้าถึงคุณลักษณะเฉพาะของ DID ของตน สิ่งสําคัญคือต้องทราบที่นี่ว่าผู้ใช้มีหน้าที่รับผิดชอบในการไม่ให้การเข้าถึงสัญญาที่เป็นอันตรายเช่นเดียวกับที่พวกเขามีหน้าที่รับผิดชอบในการไม่ปล่อยให้สัญญาที่เป็นอันตรายใช้โทเค็นของพวกเขา

เริ่มต้นด้วยการนำเสนอตรรกะสำหรับการสร้างและบริหารจัดการ DIDs:

ตอนนี้ขั้นตอนถัดไปคือการปฏิบัติตามตรรกะสำหรับตัวระบุและควบคุมการเข้าถึง

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

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

สัญญา IdentityRegistry เป็น EIP712WithModifier, Ownable

ตอนนี้เราสามารถสรุปสัญญาการลงทะเบียนข้อมูลประจําตัวของเราได้โดยการเพิ่มผู้รับที่จําเป็นโดยมีเงื่อนไขบางประการและการจัดการข้อผิดพลาด

contract IdentityRegistry เป็น EIP712WithModifier, Ownable

สัญญากฎหมาย

ขั้นตอนถัดไปคือการสร้างสัญญาข้อกำหนดของเรา

เมื่อใช้ชุดของกฎสําหรับการถ่ายโอนระหว่างบุคคลสองคนสิ่งสําคัญคือต้องตระหนักว่ากฎเหล่านี้อาจมีวิวัฒนาการเมื่อเวลาผ่านไป การมีสัญญาอัจฉริยะเดียวที่กําหนดกฎระเบียบทั้งหมดสําหรับบริบทที่กําหนดเช่นการโอนเงินหมายความว่าสัญญา ERC20 ไม่จําเป็นต้องติดตามกฎระเบียบด้วยตนเอง รัฐบาลสามารถอัปเดตสัญญานี้และจะเผยแพร่ไปยังโทเค็นทั้งหมดที่ดําเนินการโดยอัตโนมัติ

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

ในตัวอย่างนี้ เราจะดำเนินการปฏิบัติตามกฎพื้นฐานบางประการ

• การโอนในประเทศไม่มีขีดจำกัด แต่การโอนไปต่างประเทศถูกจำกัดที่ 10,000 โทเค็น
• ผู้ใช้ที่อยู่ในรายการดำไม่สามารถโอนหรือรับโทเค็นได้
• ผู้ใช้ไม่สามารถโอนโทเค็นไปยังประเทศที่อยู่ในรายการห้าม

แทนที่จะล้มเหลวในการทำธุรกรรม ซึ่งอาจเปิดเผยข้อมูลที่ละเอียดอ่อน เราจะเพียงแค่ตั้งค่าจำนวนการโอนเป็น 0 หากหนึ่งในเงื่อนไขไม่ได้รับการปฏิบัติ นี้ใช้ตัวดำเนินการเติมทรัพยาการแบบโฮโมมอร์ฟิกที่เรียกว่า cmux: ค่า = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse)

สัญญา ERC20 ที่เป็นความลับที่เป็นไปตามข้อบังคับ

ตอนนี้เมื่อเรามีทะเบียนข้อมูลตัวตนและสัญญากฎหมาย เราสามารถสร้างสัญญา token ที่เป็นไปตามกฎหมายและรักษาความเป็นส่วนตัวได้สัญญานี้จะชื่อ CompliantERC20 และมีคุณสมบัติหลักต่อไปนี้:

• ยอดคงเหลือของผู้ใช้และจำนวนการโอนถอนถูกเข้ารหัส
• การปฏิบัติตามถูกบังคับในการโอนโดยการเรียกร้องสัญญาข้อบังคับ
• การเปิดเผยค่าคงเหลือบางรายการสามารถมอบให้กับที่อยู่ใน whitelist (เช่น ผู้ควบคุมดูแล)

สัญญาข้อกำหนดถูกเรียกผ่านการโทรเรียกง่าย นี่แปลว่าผู้ใช้ต้องให้สิทธิ์ในการเข้าถึงสัญญา ERC20 ก่อนที่จะเริ่มการโอนเงินใด ๆ มิฉะนั้นการโอนเงินจะถูกย้อนกลับ

สุดท้ายแล้ว เราสามารถสร้างสัญญา ERC20 ของเราได้แล้ว

ในทางเดียวกันกับวิธีที่ผู้ใช้ให้สิทธิให้โปรโตคอล DeFi ใช้เหรียญโทเค็นของพวกเขา พวกเขาจะต้องให้สิทธิให้สัญญาเข้าถึงตัวบ่งชี้ที่จำเป็นโดยสัญญาข้อบังคับนี้ สิ่งนี้ทำโดยการเรียกใช้ Identity.grantAccess(contractAddress, identifiers), ซึ่งสามารถเรียกดูได้โดยการเรียกใช้วิธีมุมมอง ERC20.identifiers() รายการนี้มาโดยตรงจากสัญญา ERC20Rules เพื่ออนุญาตให้อัปเดตคุณสมบัติ

การปฏิบัติตามและความเป็นส่วนตัวสามารถในโลกเดียวกันได้!

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

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

ลิงก์เพิ่มเติม

• ดาวที่เก็บข้อมูล Github fhEVM ของ Zama เพื่อรับรองงานของเรา
• Review เอกสาร fhEVM ของ Zama.
• รับการสนับสนุนเกี่ยวกับช่องทางชุมชน.
• ช่วยเสริมสร้างพื้นที่ FHE ด้วยโปรแกรม Zama Bounty: สร้างเกม on-chain ที่เก็บสถานะส่วนตัวซ่อนไว้โดยใช้ Zama’s fhEVM programmable privacy (15,000€ in prize).

ข้อความปฏิบัติตาม：

1. บทความนี้ถูกพิมพ์อีกครั้งจาก [zama]。 All copyrights belong to the original author [fhEVM]. If there are objections to this reprint, please contact the Gate Learnทีม และพวกเขาจะจัดการกับมันโดยรวดเร็ว
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำในการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่นๆ ทำโดยทีม Gate Learn การคัดลอก การกระจาย หรือการลอกเลียนบทความที่แปลนั้นถ้าไม่ได้ระบุไว้ จะถูกห้าม