ผู้เขียน: EQ Labs แหล่งที่มา: equilibrium แปล: น้องชายที่ดี, ทองสีทางการเงิน

ซีรีส์ความเป็นส่วนตัวของเรา ส่วนที่ 1 อธิบายถึงความหมายของ "ความเป็นส่วนตัว" ความแตกต่างระหว่างความเป็นส่วนตัวในบล็อกเชนและเว็บ 2 และเหตุผลว่าทำไมความเป็นส่วนตัวในบล็อกเชนยากที่จะทำได้

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

พ้นจากข้อจำกัดในอดีตและต้อนรับอนาคต

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

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

• สถานะที่ซ่อน : ส่วนใหญ่ของ Use Case ทางการเงินต้องการ (อย่างน้อย) ที่จะเก็บเป็นความลับจากผู้ใช้คนอื่น ๆ และหากไม่มีสถานะที่ซ่อนอยู่ ความสนุกสนานในเกมหลายคนจะลดลงอย่างมาก (ตัวอย่างเช่น ถ้าทุกคนบนโต๊ะโป๊กเกอร์สามารถเห็นไพ่ของกันและกัน)
• การซ่อนตัว：บางกรณีต้องการซ่อนบางตัวตน แต่ยังอนุญาตให้ผู้อื่นใช้แอปพลิเคชันนั้น เช่น ระบบจับคู่ กลยุทธ์การซื้อขาย on-chain และอื่น ๆ

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

เทคโนโลยีเสริมความเป็นส่วนตัว (PET) และแนวทางการถอดรหัสรหัสผ่านที่ทันสมัย* (ความสามารถในการตั้งค่ารหัสผ่าน)* เป็นส่วนประกอบหลักในการสร้างวิสัยทัศน์นี้* (สำหรับข้อมูลเพิ่มเติมเกี่ยวกับตัวเลือกที่แตกต่างกันที่มีอยู่และการชดเชยของพวกเขาโปรดดูเพิ่มเติมที่ภาคผนวก)*

สามสมมติฐานที่ส่งผลต่อมุมมองของเรา

สามข้อสมมติสำคัญกำหนดว่าเรามองวิธีการพัฒนาพื้นฐานความเป็นส่วนตัวของบล็อกเชนอย่างไร

1. เทคโนโลยีการเข้ารหัสจะถูกแยกออกจากนักพัฒนาแอปพลิเคชั่น: ส่วนใหญ่ของนักพัฒนาแอปพลิเคชั่นไม่ต้องการ (หรือไม่รู้ว่าจะจัดการ) เทคโนโลยีการเข้ารหัสที่จำเป็นสำหรับความเป็นส่วนตัว คาดหวังว่าพวกเขาจะสร้างเทคโนโลยีการเข้ารหัสของตัวเองและสร้างเครือข่ายส่วนตัวที่เฉพาะเจาะจง (เช่น Zcash หรือ Namada) หรือแอปพลิเคชั่นส่วนตัวบนเครือข่ายสาธารณะ (เช่น Tornado Cash) คือสิ่งที่ไม่เป็นไปได้ มันซับซ้อนมากและมีค่าใช้จ่ายมากเกินไป ส่วนใหญ่จำกัดพื้นที่การออกแบบของนักพัฒนา (ไม่สามารถสร้างแอปพลิเคชั่นที่ต้องการการป้องกันความเป็นส่วนตัวบางอย่าง) ดังนั้น เราเชื่อว่าจำเป็นต้องแยกความซับซ้อนในการจัดการการเข้ารหัสออกจากนักพัฒนาแอปพลิเคชั่น วิธีที่สองที่นี่คือความสามารถในการตั้งโปรแกรมพื้นฐานความเป็นส่วนตัว (L1/L2 ที่แบ่งปัน) หรือ "ความปลอดภัยแบบเฉพาะเจาะจง" ซึ่งอนุญาตให้การคำนวณเชิงลับถูกนอกระบบทำ
2. มีภาพรวมของการใช้งาน (บางทีอาจจะมีมากกว่าที่เราคาดคิด) ที่ต้องการแบ่งปันสถานะส่วนตัว: ตามที่กล่าวมาแล้ว แอปพลิเคชันหลายๆ แอปพลิเคชันต้องการสถานะที่ซ่อนเร้นและ/หรือต้องการตรรกะเพื่อให้ทำงานได้ถูกต้อง การแบ่งปันสถานะส่วนตัวเป็นหนึ่งในคำส่วนย่อยและผู้ลงทุนที่คาดหวังว่าราคาจะขึ้นได้คำนวณสถานะส่วนตัวเดียวกัน ถึงแม้ว่าเราจะไว้วางใจในฝ่ายที่เป็นศูนย์กลางให้เราทำเรื่องนี้และจบแค่เท่านั้น แต่ในกรณีที่ดีที่สุด เราต้องการที่จะทำเรื่องนี้ในรูปแบบที่มีการไว้วางใจในระดับต่ำที่สุดเพื่อหลีกเลี่ยงการล้มเหลวเพียงแค่จุดเดียว การใช้เทคโนโลยี Zero-Knowledge Proof (ZKP) คนเดียวไม่เพียงพอ - เราต้องใช้เครื่องมืออื่นๆ เช่น Trusted Execution Environment (TEE), Fully Homomorphic Encryption (FHE) และ/หรือการคำนวณ Multi-Party Computation (MPC)
3. ชุดการป้องกันที่ใหญ่ขึ้นสามารถป้องกันความเป็นส่วนตัวได้มากที่สุด: ข้อมูลส่วนใหญ่จะถูกรั่วไหลเมื่อเข้าหรือออกจากชุดการป้องกัน ดังนั้นเราควรลดสถานการณ์นี้ให้มากที่สุด การสร้างแอปพลิเคชันส่วนตัวหลายรายการบนบล็อกเชนเดียวกันสามารถช่วยเสริมความมั่นคงของความเป็นส่วนตัวโดยการเพิ่มจำนวนผู้ใช้และธุรกรรมในชุดการป้องกันเดียวกัน

หลักการความเป็นส่วนตัวที่สิ้นสุด

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

ไม่ได้เต็มที่เท่าไหร่ก็ตาม ทั้งหมดนี้มีการตัดสินใจที่แตกต่างกัน และเราได้เห็นว่าพวกเขารวมกันอย่างหลากหลาย โดยรวมเราได้ระบุวิธีที่แตกต่างกันออกไป 11 วิธี

ในขณะนี้มีวิธีสองวิธีที่ได้รับความนิยมสูงสุดในการสร้างพื้นฐานความเป็นส่วนตัวในบล็อกเชนคือการใช้ ZKP หรือ FHE อย่างไรก็ตาม ทั้งสองวิธีนี้มีข้อบกพร่องขั้นพื้นฐาน:

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

หากสถานะแสดงถึงความสมบูรณ์แบบที่ต้องการคือการสร้างพื้นฐานความเป็นส่วนตัวที่สามารถโปรแกรมได้และสามารถจัดการสถานะส่วนตัวที่ถูกแชร์โดยไม่มีจุดเสียเดียว สองเส้นทางสามารถเข้าถึง MPC ได้:

โปรดทราบว่า กระบวนการ MPC และวิธีอื่นๆ อาจมีลักษณะที่คล้ายคลึงกัน แต่มีการใช้งานที่แตกต่างกัน:

• ZKP ระบบเครือข่าย: MPC โดยการประมวลผลสถานะส่วนตัวที่แชร์เพื่อเพิ่มความสามารถในการแสดงออก
• FHE เครือข่าย: MPC โดยการกระจายกุญแจลับถึงคณะกรรมการ MPC (ไม่ใช่บุคคลที่สามเดียว) เพื่อเพิ่มความปลอดภัยและเสริมความเป็นส่วนตัว

ถึงแม้การสนทนาจะเริ่มเข้าสู่มุมมองที่ละเอียดอ่อนมากขึ้น แต่การค้นหาความมั่นคงทางหลังในวิธีการต่าง ๆ เหล่านี้ยังไม่ได้รับการสำรวจอย่างครบถ้วน ด้วยมิจฉาที่เราได้สรุปสมมติฐานของเราใน MPC ในอะไรที่เราต้องการยื่นเสนอคือ 3 คำถามสำคัญ

1. การรับประกันความเป็นส่วนตัวที่ MPC โปรโตคอลสามารถให้ในห่วงโซ่บล็อกแข็งแกร่งเพียงใด?
2. การเทคโนโลยีเพียงพอแล้วหรือไม่? ถ้าไม่พอ ข้อจำกัดคืออะไร?
3. มีความหมายหรือไม่ในการเปรียบเทียบกับวิธีอื่นๆ โดยพิจารณาถึงความเข้มงวดของการรักษาความปลอดภัยและค่าใช้จ่ายที่เกี่ยวข้อง?

เรามาตอบคำถามเหล่านี้อย่างละเอียด

ใช้ MPC วิเคราะห์ความเสี่ยงและจุดอ่อน

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

*ข้อมูลจาก: *Zama ในการบรรยายที่ ETH CC

ความเสี่ยงหลักของ MPC คือการฉ้อโกง หมายความว่ามีผู้เข้าร่วมมากเพียงพอที่จะแทรกแซงข้อมูลการถอดรหัสหรือการใช้งานอย่างไม่ถูกต้อง การฉ้อโกงสามารถที่จะถูกทำได้ใน off-chain และจะถูกเปิดเผยเฉพาะเมื่อฝ่ายที่ไม่หวังดีดำเนินการบางอย่าง (การขู่เอาเงินเป็นต้น) โดยไม่ต้องสงสัยว่าสิ่งนี้ส่งผลกระทบอย่างมากต่อความเป็นส่วนตัวที่ระบบสามารถให้ได้ ความเสี่ยงที่เกี่ยวข้องกับการฉ้อโกงขึ้นอยู่กับ:

• โปรโตคอลนี้สามารถทนทานกับฝ่ายที่มีความชั่วร้ายเท่าไหร่?
• อินเทอร์เน็ตประกอบด้วยฝ่ายใดบ้าง ความน่าเชื่อถือของพวกเขาเป็นอย่างไร
• จำนวนและการกระจายของฝ่ายที่เข้าร่วมในเครือข่าย - มีสื่อโจมตีที่พบบ่อยหรือไม่?
• การเชื่อมต่อเป็นไปได้โดยไม่ต้องขออนุญาตหรือต้องขออนุญาต (ประโยชน์ทางเศรษฐกิจและเสียงชื่อ/พื้นฐานทางกฎหมาย)？
• การลงโทษทรยศที่มีความร้ายแรงคืออะไร? การตกลงเล่นเกมร่วมกันเป็นผลลัพธ์ที่ดีที่สุดในทฤษฎีหรือไม่?

1. โปรโตคอล MPC สามารถให้ความปลอดภัยของความเป็นส่วนตัวในบล็อกเชนได้แรงแค่ไหน?

TLDR: ไม่มีความแข็งแกร่งเหมือนที่เราหวัง แต่ยังแข็งแกร่งกว่าการพึ่งพาฝ่ายสาธารณะที่เป็นศูนย์กลาง

การถอดรหัสที่จำเป็นต้องขึ้นอยู่กับแผน MPC ที่เลือกไว้ - มีความยุ่งยากอยู่บางอย่างในการตีความระหว่างความคลาดเคลื่อน*（การส่งมอบผลลัพธ์ที่รับรอง）*และความปลอดภัย คุณสามารถใช้แผน N/N ที่มีความปลอดภัยมากมาย แต่เมื่อโหนดหนึ่งออฟไลน์แค่นั้นก็จะทำให้มันล่มสลาย อีกทางหนึ่ง N/2 หรือ N/3 มีความเข้มงวดมากกว่า แต่มีความเสี่ยงในการกลุ่มก่อการร้ายที่สูงขึ้น

เงื่อนไขสองอย่างที่ต้องสมดุลกันคือ:

1. ข้อมูลลับจะไม่มีการรั่วไหลตลอดเวลา (เช่นกุญแจลับ)
2. ข้อมูลลับจะไม่หายไปตลอดไป (แม้ว่าผู้เข้าร่วม 1/3 จะออกไปโดยอย่างไม่คาดคิด)

แผนที่ถูกเลือกจะแตกต่างกันไปตามการนำไปใช้งาน เช่นเป้าหมายของ Zama คือ N/3 ในขณะที่ Arcium กำลังนำเสนอแผนที่ N/N อยู่ในปัจจุบัน แต่จะสนับสนุนแผนที่มีการรับรองกิจกรรมที่สูงขึ้น (และความสมัครใจที่มากขึ้น) ในอนาคต

ในขอบเขตของการตีความนี้ วิธีที่ประนีประนอมคือการใช้วิธีผสมผสาน:

คณะกรรมการความเชื่อมั่นสูงใช้การจัดการกุญแจลับโดยใช้ค่า N/3 เช่นเดียวกัน

• คณะกรรมการคำนวณ เป็นการสลับกัน เช่นมี N-1 ค่าเขตความถี่ (หรือหลายคณะกรรมการคำนวณที่มีลักษณะที่แตกต่างกันให้ผู้ใช้เลือก)

ถึงแม้ว่ามันจะดึงดูดใจตามทฤษฎี แต่มันก็เพิ่มความ复杂 เช่น การคำนวณคณะกรรมการว่าจะทำงานร่วมกับคณะกรรมการที่เชื่อถือได้สูงอย่างไร

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

ความเสี่ยงที่ละเอียดอ่อนมากขึ้นรวมถึงสถานการณ์ขอบข่าย เช่น บริษัททั้งหมดในกลุ่ม MPC ได้จ้างวิศวกรระดับสูงมากว่า 10 ถึง 15 ปี

2. การเทคโนโลยีเป็นอย่างไรบ้าง? หากไม่เพียงพอ ข้อจำกัดคืออะไร?

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

1. ชุดตัวดำเนินการขนาดเล็ก: เพื่อควบคุมค่าใช้จ่ายในการสื่อสาร โปรโตคอลที่มีอยู่ในปัจจุบัน ส่วนใหญ่ จำกัดการใช้ชุดตัวดำเนินการขนาดเล็กเท่านั้น ตัวอย่างเช่น เครือข่ายถอดรหัสของ Zama ในปัจจุบันอนุญาตให้มีโหนด 4 โหนดเท่านั้น (แม้ว่าพวกเขากำลังวางแผนที่จะขยายเป็น 16 โหนด) ตามเกณฑ์เปรียบเทียบสมรรถนะเริ่มต้นที่ Zama ปล่อยให้กับเครือข่ายถอดรหัส (TKMS) แม้แต่กลุ่มโหนด 4 โหนดอย่างเดียวก็จะต้องใช้เวลาถอดรหัส 0.5-1 วินาที (กระบวนการ e2e ทั้งหมดจะใช้เวลานานกว่านี้) ตัวอย่างอีกอันคือ MPC ที่ Taceo นำมาประยุกต์ใช้กับฐานข้อมูลไอริสของ Worldcoin ซึ่งมี 3 ฝ่าย (สมมติว่ามี 2/3 ฝ่ายซื่อสัตย์)

*ข้อมูลจาก: *Zama ในการบรรยายที่ ETH CC 2. 3. ชุดผู้ดำเนินการที่ได้รับอนุญาต: ในส่วนมากชุดผู้ดำเนินการได้รับอนุญาต ซึ่งหมายความว่าเราพึ่งพาชื่อเสียงและสัญญากฎหมายไม่ใช่ความปลอดภัยทางเศรษฐกิจหรือการเข้ารหัส ความท้าทายหลักของชุดผู้ดำเนินการที่ได้รับอนุญาตคือไม่สามารถทราบได้อย่างแน่นอนว่าผู้คนทำการแปรผันภายนอกหรือไม่ นอกจากนี้ยังต้องมีการนำทางหรือจัดสรรส่วนแบ่งกุญแจใหม่ให้โหนดสามารถเข้าหรือออกจากเครือข่ายได้โดยอยู่ในรูปแบบที่เปลี่ยนแปลงได้ ถึงแม้ว่าชุดผู้ดำเนินการที่ได้รับอนุญาตจะเป็นเป้าหมายสุดท้ายและกำลังศึกษาวิธีการขยายกลไก PoS เพื่อให้เกิด MPC ค่าเข้ารหัสขั้นต่ำ (เช่น Zama) แต่เส้นทางที่ได้รับอนุญาตดูเหมือนเป็นทิศทางการเดินหน้าที่ดีที่สุดในปัจจุบัน

ทางเลือก

ชุดความเป็นส่วนตัวครอบคลุมทั้งหมด:

• FHE ใช้สำหรับการคำนวณความเป็นส่วนตัว
• ZKP ใช้สำหรับการยืนยันว่าการคำนวณ FHE ถูกต้อง
• ใช้สำหรับการถอดรหัสความลับโดยใช้ MPC
• ทุกโหนด MPC ใช้ TEE เพื่อเพิ่มความปลอดภัย

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

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

1. ใช้ MPC โดยตรงสำหรับการคำนวณทั่วไป

หาก ZK และ FHE กลับมาสู่สมมติการเชื่อมั่นของ MPC ในที่สุด ทำไมเราไม่ใช้ MPC ในการคำนวณโดยตรง? นี่เป็นคำถามที่สมเหตุสมผล และก็เป็นสิ่งที่ทีม Arcium、SodaLabs (ใช้ COTI v2)、Taceo และ Nillion กำลังพยายามทำอยู่ โปรดทราบว่า MPC มีหลายรูปแบบ แต่ในวิธีสามวิธีหลัก เราต้องการอ้างถึงโปรโตคอลที่ใช้การแบ่งความลับและวงจรความสับสน (GC) ไม่ใช่โปรโตคอลที่ใช้ MPC ในการถอดรหัสอ้างอิงจาก FHE

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

มีวิธีบางวิธีที่สามารถลดค่าใช้จ่าย เช่น การดำเนินการก่อนออฟไลน์ (ส่วนที่มีค่าในโปรโตคอล) - Arcium และ SodaLabs กำลังสำรวจจุดนี้ จากนั้นดำเนินการคำนวณในขณะออนไลน์ ซึ่งจะใช้ข้อมูลบางส่วนที่สร้างขึ้นในขั้นตอนออฟไลน์ ซึ่งลดค่าใช้จ่ายในการสื่อสารโดยรวมอย่างมาก

SodaLabs ตารางด้านล่างแสดงเวลาเริ่มต้นเปรียบเทียบสมรรถนะเมื่อดำเนินการ รหัสการดำเนินงาน 1,000 ครั้งใน gcEVM ของตน*（เป็นไมโครวินาที）* มีความเป็นไปได้ที่นี่เป็นขั้นตอนที่ถูกต้อง แต่ยังมีงานอีกมากที่ต้องทำเพื่อเพิ่มประสิทธิภาพและขยายชุดตัวดำเนินการไปยังโหนดหลายๆ รายการ

ที่มา: SodaLabs

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

2. สภาพแวดล้อมการดำเนินงานที่น่าเชื่อถือ

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

กระทั่ง TEE ถือว่าเป็นการส่วนหนึ่งที่เจริญเติบโตมากขึ้นและมีค่าใช้จ่ายในการทำงานที่น้อยกว่า แต่ทว่ามันก็ไม่ได้ไม่มีข้อเสีย อันแรกคือ TEE มีความไว้วางใจที่แตกต่างกัน (1/N) และให้การแก้ไขที่ใช้ฮาร์ดแวร์แทนซอฟต์แวร์ คำวิจารณ์ที่มักจะได้ยินคือการคาดหวังในอดีตของ SGX แต่ควรทราบว่า TEE ≠ Intel SGX นอกจากนี้ TEE ยังต้องพึ่งพาผู้ให้บริการฮาร์ดแวร์และมีราคาสูงเกินกว่าส่วนใหญ่ของคนจะสามารถเอาไปใช้ได้ วิธีการแก้ปัญหาความเสี่ยงจากการโจมตีทางกายภาพคือการขับเคลื่อน TEE ในอวกาศเพื่อปฏิบัติภารกิจที่สำคัญ

โดยทั่วไป TEE ดูเหมาะสมกับการพิสูจน์หรือสถานการณ์ที่มีความเป็นส่วนตัวในระยะสั้นเท่านั้น (การถอดรหัสโดยความเป็นไปได้, บัญชีภายในที่ไม่เผยแพร่, ฯลฯ) สำหรับความเป็นส่วนตัวที่ถาวรหรือยาวนาน รักษาความปลอดภัยดูเหมือนจะไม่น่าสนใจ

3. DAC ส่วนตัวและวิธีการปกป้องความเป็นส่วนตัวที่พึ่งขึ้นอยู่กับบุคคลที่เชื่อถือได้

ตัวกลางความเป็นส่วนตัวสามารถให้ความเป็นส่วนตัวและป้องกันไม่ให้ผู้ใช้รายอื่นเข้าถึง แต่การรับประกันความเป็นส่วนตัวมาจากความไว้วางใจในบุคคลที่สามทั้งหมด (จุดเดียวของความล้มเหลว) แม้ว่าจะคล้ายกับ "web2 privacy" (ป้องกันความเป็นส่วนตัวของผู้ใช้รายอื่น) แต่ก็สามารถเสริมความแข็งแกร่งด้วยการรับประกันเพิ่มเติม (การเข้ารหัสหรือเศรษฐกิจ) และช่วยให้การตรวจสอบดําเนินการได้อย่างถูกต้อง

คณะกรรมการสามารถใช้ข้อมูลส่วนตัว (DAC) เป็นตัวอย่างหนึ่ง; สมาชิกของ DAC จะเก็บข้อมูลไว้ใน off-chain และผู้ใช้พึงพอใจในความสามารถของพวกเขาในการเก็บข้อมูลอย่างถูกต้องและปรับปรุงการเปลี่ยนสถานะ รูปแบบอื่น ๆ คือตัวตนอนุญาตที่ Tom Walpo ได้นำเสนอ

แม้ว่าวิธีนี้จะทำให้มีการตัดสินใจทางด้านความเป็นส่วนตัวอย่างมาก แต่จากมุมมองของความคุ้มค่าและประสิทธิภาพ มันอาจเป็นทางเลือกที่เหมาะสมสำหรับแอปพลิเคชันคุณค่าต่ำ ประสิทธิภาพสูงเท่านั้น (อย่างน้อยในปัจจุบัน) ตัวอย่างเช่น โปรโตคอลเลนส์ มีแผนที่จะใช้ DAC เอกชนเพื่อให้ได้กระแสข้อมูลส่วนตัว สำหรับการใช้งานเชิงสังคมทาง on-chain การตัดสินใจระหว่างความเป็นส่วนตัว และความคุ้มค่า/ประสิทธิภาพในปัจจุบันอาจจะเป็นไปได้ (โดยพิจารณาค่าใช้จ่ายและค่าใช้จ่ายทางเลือก)

4. ที่อยู่

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

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

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

ข้อเสนอของเราเผชิญกับความเสี่ยง

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

1. การแบ่งปันรัฐเอกชนไม่สําคัญอย่างที่เราคิด: ในกรณีนี้โครงสร้างพื้นฐานที่ใช้ ZK มีแนวโน้มที่จะชนะเนื่องจากมีการรับประกันความเป็นส่วนตัวที่แข็งแกร่งกว่าและค่าใช้จ่ายต่ํากว่า FHE มีกรณีการใช้งานบางอย่างที่แสดงให้เห็นว่าระบบที่ใช้ ZK ทํางานได้ดีในกรณีการใช้งานที่แยกได้เช่นโปรโตคอลการชําระเงินส่วนตัว Payy
2. การตัดสินใจเกี่ยวกับประสิทธิภาพที่ไม่คุ้มค่ากับการคุ้มครองความเป็นส่วนตัว: บางคนอาจพูดว่าการเชื่อมั่นในเครือข่าย MPC ที่มีผู้อนุญาต 2-3 คนไม่ต่างจากผู้มีส่วนร่วมที่มีศูนย์กลางเดียว และค่าใช้จ่ายที่เพิ่มขึ้นนั้นไม่คุ้มค่า สำหรับหลายๆ แอปพลิเคชัน โดยเฉพาะแอปพลิเคชันที่มีมูลค่าต่ำ ที่ตอบสนองต่อค่าใช้จ่าย (เช่น โซเชียล หรือ เกม) นั่นอาจจะถูกต้อง อย่างไรก็ตาม ยังมีกรณีการใช้งานที่มีมูลค่าสูงมาก ซึ่งการร่วมมือขณะนี้มีค่าใช้จ่ายสูงมาก (หรือไม่เป็นไปได้) เนื่องจากปัญหากฎหมายหรือความเสียหาย ส่วนหลังจากนั้นก็คือจุดที่ MPC และ FHE สามารถทำได้ดี
3. การออกแบบที่เชี่ยวชาญดีกว่าการออกแบบทั่วไป: การสร้างโซเชียลนวัตกรรมและช่วยส่งเสริมชุมชนของผู้ใช้และนักพัฒนามีความยากลำบากมาก ดังนั้น พื้นฐานความเป็นส่วนตัวทั่วไป (L1/L2) อาจยากที่จะได้รับการติดตาม. ปัญหาอีกประการหนึ่งเกี่ยวข้องกับความเชี่ยวชาญ; การออกแบบโปรโตคอลเดียวก็ยากที่จะครอบคลุมพื้นที่ที่เป็นความสมดุลทั้งหมด ในโลกนี้ การให้ความเป็นส่วนตัวให้กับระบบนิเวศที่มีอยู่แล้ว (เช่น บริการความลับ) หรือกรณีการใช้งานที่เฉพาะเจาะจง (เช่น การชำระเงิน) จะได้รับการยอมรับมากขึ้น อย่างไรก็ตาม เรามีความสงสัยในเรื่องหลัง ๆ นี้ เนื่องจากมันทำให้นักพัฒนาแอปพลิเคชันต้องเผชิญกับความซับซ้อน และต้องทำการดำเนินการบางเทคโนโลยีการเข้ารหัสบางอย่างด้วยตนเอง (แทนที่จะทำให้มันมีความเข้มงวดขึ้น)
4. การควบคุมยังคงเป็นอุปสรรคในการทดสอบโซลูชันความเป็นส่วนตัว: สำหรับผู้สร้างพื้นฐานความเป็นส่วนตัวและแอปพลิเคชันที่มีการป้องกันข้อมูลส่วนบุคคลบางอย่างนั้นเป็นความเสี่ยง ไม่มีการควบคุมในการสร้างบนพื้นฐานความเป็นส่วนตัวที่ไม่ต้องขออนุญาตอาจจะยาก (หรือไม่เป็นไปได้) เรามีโอกาสแก้ไขปัญหาเทคโนโลยีก่อนแก้ไขปัญหาการกำกับ
5. สำหรับส่วนใหญ่ของ Use Case แบบ MPC และ FHE ยังมีค่าใช้จ่ายสูงเกินไป: โดย MPC ถูกพบว่าส่วนใหญ่มีผลจากค่าใช้จ่ายในการสื่อสาร แต่ทีมงานของ FHE พึ่งพาการเร่งความเร็วด้วยฮาร์ดแวร์เพื่อปรับปรุงประสิทธิภาพ แต่ถ้าเราสามารถคาดคะเนการพัฒนาฮาร์ดแวร์ที่เฉพาะเจาะจงสำหรับ ZK ได้ จะใช้เวลารอนานกว่าที่คนส่วนใหญ่คิดก่อนที่เราจะได้รับฮาร์ดแวร์ FHE ที่สามารถใช้งานได้ ทีมงานที่มุ่งมั่นพัฒนาฮาร์ดแวร์ FHE รวมถึง Optalysys、fhela และ Niobium

สรุป

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

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

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

แม้แต่คุณมีค้อนที่ดีที่สุดในโลก ก็ไม่จำเป็นว่าทุกสิ่งทุกอย่างก็เป็นตะขอ.