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

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

เรากำลังสร้างสิ่งเดียวกันหรือไม่? อ่านต่อเพื่อดูคำตอบ

Thanks to Avishay (SodaLabs), ลูกัส ( Taceo), Michael ( สมดุล), และNico (Arcium) สำหรับการสนทนาที่ช่วยรูปร่างโพสต์นี้

สิ่งที่สามารถเป็นได้โดยไม่ต้องถูกหน้าที่โดยสิ่งที่ผ่านมา

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

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

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

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

เทคโนโลยีการเพิ่มความเป็นส่วนตัว (PETs) และโซลูชันการเข้ารหัสที่ทันสมัย ("การเข้ารหัสที่สามารถโปรแกรมได้“) เป็นบล็อกสำคัญในการสร้างฐานรากสำหรับการสาบานนี้ (ดูภาคผนวกสำหรับข้อมูลเพิ่มเติมเกี่ยวกับความสามารถที่มีให้เลือกใช้และข้อเสียข้อเสีย

สามสมมติฐานที่เป็นรูปแบบการมองเห็นของเรา

สามสมมติฐานสำคัญรูปร่างมุมมองของเราเกี่ยวกับวิวัฒนาการโครงสร้างความเป็นส่วนตัวในบล็อกเชน:

1. การเข้ารหัสจะถูกแยกออกจากนักพัฒนาแอปพลิเคชัน: นักพัฒนาแอปพลิเคชันส่วนมากไม่ต้องการ (หรือไม่รู้ว่าจะทำอย่างไร) ที่จะรับมือกับการเข้ารหัสที่จำเป็นสำหรับความเป็นส่วนตัว มันไม่สมเหตุสมผลที่คาดหวังให้พวกเขานำมาปฏิบัติการเข้ารหัสของตนเองและสร้างเชนแอปพลิเคชันส่วนตัว (เช่นZcash หรือ นามาดา) หรือแอปพลิเคชันส่วนตัวที่อยู่ด้านบนของเครือข่ายสาธารณะ (เช่น Tornado Cash) นี่เป็นเพียงความซับซ้อนและค่าใช้จ่ายมากเกินไปซึ่งปัจจุบัน จํากัด พื้นที่การออกแบบสําหรับนักพัฒนาส่วนใหญ่ (ไม่สามารถสร้างแอปพลิเคชันที่ต้องการการรับประกันความเป็นส่วนตัวได้) ด้วยเหตุนี้เราเชื่อว่าความซับซ้อนของการจัดการส่วนการเข้ารหัสจะต้องถูกแยกออกจากนักพัฒนาแอปพลิเคชัน สองแนวทางที่นี่คือโครงสร้างพื้นฐานความเป็นส่วนตัวที่ตั้งโปรแกรมได้ (L1/L2 ส่วนตัวที่ใช้ร่วมกัน) หรือ "การรักษาความลับเป็นบริการ" ซึ่งช่วยให้สามารถจ้างการประมวลผลที่เป็นความลับจากภายนอกได้
2. กรณีการใช้งานจํานวนมาก (อาจมากกว่าที่เราคิด) ต้องการสถานะส่วนตัวที่ใช้ร่วมกัน: ดังที่ได้กล่าวไว้ก่อนหน้านี้แอปพลิเคชันจํานวนมากต้องการสถานะที่ซ่อนอยู่และ / หรือตรรกะเพื่อให้ทํางานได้อย่างถูกต้อง รัฐเอกชนที่ใช้ร่วมกันเป็นส่วนย่อยของสิ่งนี้ซึ่งหลายฝ่ายคํานวณผ่านรัฐเอกชนชิ้นเดียวกัน ในขณะที่เราสามารถไว้วางใจให้พรรคส่วนกลางทําเพื่อเราและเรียกมันว่าวัน แต่เราต้องการทําในลักษณะที่ลดความไว้วางใจเพื่อหลีกเลี่ยงความล้มเหลวเพียงจุดเดียว การพิสูจน์ความรู้เป็นศูนย์ (ZKPs) เพียงอย่างเดียวไม่สามารถทําได้ - เราจําเป็นต้องใช้ประโยชน์จากเครื่องมือเพิ่มเติมเช่นสภาพแวดล้อมการดําเนินการที่เชื่อถือได้ (TEE), การเข้ารหัสแบบ homomorphic อย่างสมบูรณ์ (FHE) และ / หรือการคํานวณแบบหลายฝ่าย (MPC)
3. ชุดเกราะขนาดใหญ่เพิ่มความเป็นส่วนตัวสูงสุด: ส่วนใหญ่ของข้อมูลถูกเปิดเผยเมื่อ เข้าหรือออก ชุดป้องกันดังนั้นเราควรพยายามลดสิ่งนั้นให้น้อยที่สุด การมีแอปพลิเคชันส่วนตัวหลายตัวที่สร้างขึ้นบนบล็อกเชนเดียวกันสามารถช่วยเสริมสร้างการรับประกันความเป็นส่วนตัวโดยการเพิ่มจํานวนผู้ใช้และธุรกรรมภายในชุดป้องกันเดียวกัน

End Game ของโครงสร้างความเป็นส่วนตัว

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

ไม่เต็มที่ ทั้งหมดเหล่านี้มีการแบ่งปันที่แตกต่างกันและเราได้เห็นว่าพวกเขาได้รวมกันในวิธีต่าง ๆ แล้ว โดยรวมแล้วเราได้ระบุวิธีการที่แตกต่างกัน 11 วิธี (ดู ภาคผนวก).

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

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

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

โปรดทราบว่าแม้ว่าวิธีการสองวิธีนี้จะเข้าใจกันในที่สุด แต่ MPC ถูกใช้เพื่อสิ่งที่แตกต่างกัน

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

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

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

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

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

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

แหล่งที่มา: การพูดของ Zama ที่ ETH CC

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

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

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

TLDR: ไม่แข็งแกร่งเท่าที่เราต้องการ แต่แข็งแกร่งกว่าการพึ่งพาแค่หนึ่งบุคคลที่สาม

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

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

1. ข้อมูลลับไม่เคยรั่วไหล (เช่น คีย์การถอดรหัส)
2. ข้อมูลลับจะไม่หายไป (แม้ว่าจะมี 1/3 ของฝ่ายออกไปอย่างกะทันหัน)

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

หนึ่ง การประนีประนอมที่อยู่บนเส้นขอบเขตการค้านี้คือการมีการแก้ไขแบบผสม:

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

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

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

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

2. เทคโนโลยีมีความสมบูรณ์พอแล้วหรือไม่? ถ้าไม่ ข้อจำกัดคืออะไร?

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

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

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

วิธีทางเลือก

เครื่องดื่มความเป็นส่วนตัวที่เต็มรูปแบบประกอบด้วย:

• FHE สำหรับการคำนวณส่วนตัวที่ได้รับมอบหมาย
• ZKP เพื่อการตรวจสอบว่าการคำนวณ FHE ได้รับการดำเนินการอย่างถูกต้อง
• MPC สำหรับการถอดรหัสเกณฑ์
• แต่ละโหนด MPC ทำงานภายใน TEE เพื่อความปลอดภัยเพิ่มเติม

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

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

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

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

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

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

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

ต้นฉบับ: SodaLabs

ประโยชน์ของวิธีการที่ใช้ ZK คือคุณใช้ MPC สําหรับกรณีการใช้งานที่ต้องใช้การคํานวณผ่านรัฐเอกชนที่ใช้ร่วมกันเท่านั้น FHE แข่งขันกับ MPC โดยตรงมากขึ้นและต้องพึ่งพาการเร่งฮาร์ดแวร์อย่างมาก

2. Trusted Execution Environments

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

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

โดยรวมแล้ว, TEEs ดูเหมาะสมกว่าสำหรับการรับรองหรือกรณีการใช้ที่ต้องการความเป็นส่วนตัวในระยะสั้น (การถอดรหัสเกณฑ์, สมุดคำสั่งที่มืด, ฯลฯ) สำหรับความเป็นส่วนตัวระยะยาวหรือยาวนาน, การรับประกันความปลอดภัยดูเหมือนน้อยนิด

3. DAC ส่วนตัวและวิธีการอื่น ๆ ที่พึ่งพาบุคคลที่มีความไว้วางใจเป็นส่วนตัว

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

คณะกรรมการความสามารถในการเข้าถึงข้อมูลส่วนตัว (DAC) เป็นตัวอย่างหนึ่งของนี้ สมาชิกของ DAC เก็บข้อมูลออกเชือกและผู้ใช้มีความไว้วางใจในการเก็บข้อมูลและใช้งานการอัปเดตสถานะอย่างถูกต้อง อีกแบบหนึ่งของสิ่งนี้คือ ตัวจัดเรียงแบบฟรันไชส์ เสนอโดย Tom Walpo

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

4. ที่อยู่แบบล่อซ่อน

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

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

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

ความเสี่ยงต่อการก้าวหน้าของเรา

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

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

สรุป

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

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

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

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

ส่วนเสริม 1: วิธีการที่แตกต่างกันในการรักษาความเป็นส่วนตัวในบล็อกเชน

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

มี PETs ที่แตกต่างกันมากมายให้เลือก แต่สิ่งที่เกี่ยวข้องมากที่สุดสําหรับอุตสาหกรรมบล็อกเชน ได้แก่ ซุปสามตัวอักษร - ZKP, MPC, FHE และ TEE - พร้อมกับวิธีการเพิ่มเติมเช่นที่อยู่ซ่อนตัว:

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

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

• Trusted vs Trust-minimized privacy (มีจุดล้มเหลวเพียงจุดเดียวหรือไม่)
• แนวทางฮาร์ดแวร์และซอฟต์แวร์
• กรณีแยกตัว vs การรวม PET หลายตัวเข้าด้วยกัน
• L1 vs L2
• ชื่อเชืองใหม่ vs ความเป็นส่วนตัวเสริมให้กับเชืองที่มีอยู่แล้ว ("ความเป็นส่วนตัวเป็นบริการ")
• ขนาดของชุดที่ปกป้อง (Multi-chain > Single-chain > Application > Single asset)

ภาคผนัง 2: ภูมิภาคอุตสาหกรรม

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

ปฏิเสธ:

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