)

แนวคิดหลัก:

1. FHE สัญญาว่าจะเป็น “จอกศักดิ์สิทธิ์แห่งการเข้ารหัส” อย่างไรก็ตาม มีข้อกังวลด้านประสิทธิภาพ ประสบการณ์ของนักพัฒนา และด้านความปลอดภัยมากมายที่จำกัดการใช้งานในปัจจุบัน

2. ดังที่แสดงในภาพด้านบน FHE จะต้องใช้ร่วมกับ ZKP และ MPC เพื่อสร้างระบบรัฐที่ใช้ร่วมกันที่เป็นความลับและปลอดภัยอย่างแท้จริง

3.FHE มีการพัฒนาอย่างรวดเร็ว การพัฒนาคอมไพเลอร์ ไลบรารี ฮาร์ดแวร์ ฯลฯ ใหม่ ไม่ต้องพูดถึง FHE ได้รับประโยชน์อย่างมากจากการวิจัยและพัฒนาของบริษัท Web2 (Intel, Google, DARPA ฯลฯ)

4.เมื่อ FHE และระบบนิเวศโดยรอบเติบโตเต็มที่ เราคาดหวังว่า "FHE ที่ตรวจสอบได้" จะกลายเป็นมาตรฐาน แอปพลิเคชัน FHE อาจเลือกใช้การประมวลผลและการตรวจสอบจากภายนอกไปยังโปรเซสเซอร์ร่วม FHE

5.ข้อจำกัดพื้นฐานของ onchain FHE คือ “ใครเป็นผู้ถือคีย์ถอดรหัส” การถอดรหัสตามเกณฑ์และ MPC นำเสนอโซลูชัน แต่โดยทั่วไปแล้วจะผูกมัดด้วยข้อดีข้อเสียด้านประสิทธิภาพและความปลอดภัย

บทนำ:

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

ความเป็นส่วนตัวของ Onchain เป็นหนึ่งในปัญหาที่ท้าทายที่สุดใน crypto มาเกือบทศวรรษ แม้ว่าจะมีหลายทีมที่สร้างระบบที่ใช้ ZK เพื่อให้บรรลุความเป็นส่วนตัวแบบออนเชน พวกเขาไม่สามารถรองรับสถานะที่แชร์และเข้ารหัสได้ ทำไม คำตอบสั้นๆ ก็คือเนื่องจากโปรแกรมเหล่านี้เป็นฟังก์ชันของชุดข้อมูล ZKP และด้วยเหตุนี้ จึงเป็นไปไม่ได้ที่ใครก็ตามจะใช้ตรรกะตามอำเภอใจกับสถานะปัจจุบันได้ สิ่งนี้หมายความว่า? โดยพื้นฐานแล้วเราไม่สามารถสร้างแอปพลิเคชันสถานะที่ใช้ร่วมกันที่เป็นความลับ (คิดว่า Uniswap ส่วนตัว) โดยใช้เพียง ZKP

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

แม้ว่า FHE สัญญาว่าจะเป็น "จอกศักดิ์สิทธิ์แห่งการเข้ารหัส" เราพยายามที่จะให้การวิเคราะห์ตามวัตถุประสงค์ของสาขานี้ รวมถึงความท้าทายต่างๆ และแนวทางแก้ไขที่เป็นไปได้ เราครอบคลุมหัวข้อ onchain FHE ต่อไปนี้:

• แบบแผน FHE ไลบรารีและคอมไพเลอร์
• การถอดรหัสเกณฑ์ที่ปลอดภัย
• ZKP สำหรับอินพุตของผู้ใช้ + ฝ่ายคอมพิวเตอร์
• เลเยอร์ DA ที่ตั้งโปรแกรมได้และปรับขนาดได้
• เอฟเอชอี ฮาร์ดแวร์

แบบแผน FHE ไลบรารีและคอมไพเลอร์

ความท้าทาย: แบบแผน FHE ที่เพิ่งเกิดขึ้น ไลบรารี และคอมไพเลอร์

คอขวดพื้นฐานของ onchain FHE อยู่ที่เครื่องมือ/อินฟาเรดของนักพัฒนาที่ล้าหลัง ต่างจาก ZKP หรือ MPC ตรงที่ FHE มีมาตั้งแต่ปี 2009 เท่านั้น ดังนั้นจึงมีระยะเวลาที่สั้นกว่ามากในการเติบโต

ข้อจำกัดหลักใน FHE DevEx คือ:

• ภาษาส่วนหน้าที่ใช้งานง่ายสำหรับนักพัฒนาในการเขียนโค้ดโดยไม่ต้องมีความรู้เกี่ยวกับการเข้ารหัสแบ็กเอนด์มากนัก
• คอมไพเลอร์ FHE ที่ทำงานได้อย่างสมบูรณ์ซึ่งสามารถจัดการงานสกปรกทั้งหมดได้ (การเลือกพารามิเตอร์ การเพิ่มประสิทธิภาพ SIMD สำหรับ BGV/BFV และการเพิ่มประสิทธิภาพแบบขนาน)
• รูปแบบ FHE ที่มีอยู่ (โดยเฉพาะ TFHE) จะช้ากว่าประมาณ 1,000 เท่าเมื่อเทียบกับการคำนวณธรรมดา

เพื่อให้เข้าใจถึงความซับซ้อนของการบูรณาการ FHE อย่างแท้จริง เรามาดูรายละเอียดการเดินทางของนักพัฒนากันดีกว่า:

ขั้นตอนแรกในการรวม FHE เข้ากับแอปพลิเคชันของคุณคือการเลือกแผน FHE ที่จะใช้ แผนภูมิต่อไปนี้จะอธิบายโครงร่างหลัก:

ดังที่แสดงในตารางด้านบน วงจรบูลีนเช่น FHEW และ TFHE มีการบูตสแตรปที่เร็วที่สุดและสามารถหลีกเลี่ยงขั้นตอนการเลือกพารามิเตอร์ที่ค่อนข้างซับซ้อนได้ และสามารถใช้ในการคำนวณตามอำเภอใจ/ทั่วไปได้ แต่ค่อนข้างช้า แม้ว่า BGV/BFV อาจเหมาะกับ DeFi ทั่วไป เนื่องจากมีประสิทธิภาพมากกว่าในการคำนวณทางคณิตศาสตร์ที่มีความแม่นยำสูง แต่นักพัฒนาจำเป็นต้องทราบความลึกของวงจรล่วงหน้าเพื่อตั้งค่าพารามิเตอร์ทั้งหมดของโครงร่าง ในอีกด้านหนึ่งของสเปกตรัม CKKS รองรับการคูณแบบโฮโมมอร์ฟิกโดยอนุญาตให้เกิดข้อผิดพลาดที่แม่นยำได้ ทำให้เหมาะสมที่สุดสำหรับกรณีการใช้งานที่ไม่แม่นยำ เช่น ML

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

ในส่วนของไลบรารี คุณสมบัติและความสามารถของไลบรารี FHE ยอดนิยมสามารถดูได้จากตารางด้านล่าง:

แต่ไลบรารีก็มีความสัมพันธ์ที่แตกต่างกันกับโครงร่างและคอมไพเลอร์ดังแสดงด้านล่าง:

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

ณ จุดนี้ นักพัฒนาอาจถามว่า:

พื้นที่ข้อความธรรมดาของฉันต้องใหญ่แค่ไหน? ไซเฟอร์เท็กซ์มีขนาดเท่าใดที่ยอมรับได้ ฉันจะคำนวณแบบขนานได้ที่ไหน และอื่น ๆ อีกมากมาย…

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

กล่าวโดยย่อ สำหรับนักพัฒนาที่ไม่ได้ฝึกหัด FHE แทบจะเป็นไปไม่ได้เลยที่จะรวม FHE เข้ากับแอปพลิเคชันของพวกเขา จะต้องมีเครื่องมือ dev/อินฟาเรดที่สำคัญเพื่อสรุปความซับซ้อนที่นำเสนอโดย FHE

สารละลาย:

1. คอมไพเลอร์ FHE เฉพาะ Web3

แม้ว่าจะมีคอมไพเลอร์ FHE ที่สร้างโดย Google และ Microsoft อยู่แล้ว แต่ก็มี:

• ไม่ได้ออกแบบโดยคำนึงถึงประสิทธิภาพ โดยเพิ่มโอเวอร์เฮด 1,000x เทียบกับวงจรการเขียนโดยตรง
• ปรับให้เหมาะสมสำหรับ CKKS (aka ML) และไม่เป็นประโยชน์สำหรับ BFV/BGV ที่จำเป็นสำหรับ DeFi
• ไม่ได้สร้างมาสำหรับ Web3 ไม่รองรับความเข้ากันได้กับรูปแบบ ZKP, การเชื่อมโยงโปรแกรม ฯลฯ

นั่นก็คือคอมไพเลอร์ Sunscreen FHE เป็นคอมไพเลอร์เนทิฟ Web3 ที่ให้ประสิทธิภาพที่ดีที่สุดสำหรับการดำเนินการทางคณิตศาสตร์ (เช่น DeFi) โดยไม่ต้องใช้ตัวเร่งฮาร์ดแวร์ ตามที่กล่าวไว้ข้างต้น การเลือกพารามิเตอร์ถือเป็นส่วนที่ยากที่สุดในการดำเนินการตามโครงการ FHE ครีมกันแดดไม่เพียงแต่มีการเลือกพารามิเตอร์อัตโนมัติเท่านั้น แต่ยังมีการเข้ารหัสข้อมูล การเลือกคีย์ ปรับใช้การปรับเชิงเส้นใหม่และการสลับโมดูลัส ตั้งค่าวงจร และใช้การดำเนินการสไตล์ SIMD

เมื่อเราก้าวไปสู่อนาคต เราคาดหวังว่าจะได้เห็นการเพิ่มประสิทธิภาพเพิ่มเติม ไม่เพียงแต่ในคอมไพเลอร์ Sunscreen เท่านั้น แต่ยังมีทีมอื่นๆ ที่สร้างการใช้งานของตนเองที่รองรับภาษาระดับสูงอื่นๆ

1. ห้องสมุด FHE ใหม่

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

มาดูสัญญาอัจฉริยะของ FHE เป็นตัวอย่าง แม้ว่าการเลือกจากไลบรารี FHE ต่างๆ อาจทำได้ยาก แต่จะง่ายขึ้นเมื่อเราพูดถึง onchain FHE เนื่องจากมีภาษาการเขียนโปรแกรมที่โดดเด่นเพียงไม่กี่ภาษาใน Web3

ตัวอย่างเช่น fhEVM ของ Zama รวมไลบรารีโอเพ่นซอร์ส TFHE-rs ของ Zama เข้ากับ EVM ทั่วไป โดยเผยให้เห็นการดำเนินการแบบโฮโมมอร์ฟิกเป็นสัญญาที่คอมไพล์ไว้ล่วงหน้า ช่วยให้นักพัฒนาใช้ข้อมูลที่เข้ารหัสในสัญญาได้อย่างมีประสิทธิภาพ โดยไม่มีการเปลี่ยนแปลงใดๆ ในเครื่องมือการคอมไพล์

สำหรับสถานการณ์เฉพาะอื่นๆ อาจจำเป็นต้องมีโครงสร้างพื้นฐานอื่นๆ บางอย่าง ตัวอย่างเช่น ไลบรารี TFHE ที่เขียนด้วยภาษา C++ ไม่ได้รับการดูแลอย่างดีเท่ากับเวอร์ชัน Rust แม้ว่า TFHE-rs จะสามารถรองรับการส่งออกสำหรับ C/C++ ได้ แต่หากนักพัฒนา C++ ต้องการความเข้ากันได้และประสิทธิภาพที่ดีขึ้น พวกเขาจะต้องเขียนไลบรารี TFHE เวอร์ชันของตนเอง

สุดท้ายนี้ เหตุผลหลักที่ทำให้โครงสร้างพื้นฐาน FHE ขาดหายไปในตลาดก็คือเราขาดวิธีที่มีประสิทธิภาพในการสร้าง FHE-RAM วิธีแก้ปัญหาหนึ่งที่เป็นไปได้คือการทำงานบน FHE-EVM โดยไม่ต้องใช้ opcode บางอย่าง

การถอดรหัสเกณฑ์ที่ปลอดภัย

ความท้าทาย: การถอดรหัสเกณฑ์ที่ไม่ปลอดภัย/รวมศูนย์

ระบบสถานะที่ใช้ร่วมกันที่เป็นความลับทุกระบบจะขึ้นอยู่กับคีย์เข้ารหัส/ถอดรหัส ไม่มีฝ่ายใดฝ่ายหนึ่งที่เชื่อถือได้ ดังนั้นคีย์ถอดรหัสจึงถูกแชร์ระหว่างผู้เข้าร่วมเครือข่าย

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

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

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

วิธีแก้ไข: ปรับปรุงการถอดรหัส Threshold หรือ Dynamic MPC

มีสองสามวิธีในการจัดการกับข้อบกพร่องของการถอดรหัสขีดจำกัด (1) เปิดใช้งานเกณฑ์ n/2 ซึ่งจะทำให้ยากต่อการสมรู้ร่วมคิด (2) เรียกใช้โปรโตคอลการถอดรหัสเกณฑ์ภายใน HSM (3) ใช้เครือข่ายถอดรหัสเกณฑ์ตาม TEE ที่ควบคุมโดยห่วงโซ่การกระจายอำนาจสำหรับการตรวจสอบสิทธิ์ที่อนุญาตสำหรับไดนามิก การจัดการที่สำคัญ

แทนที่จะใช้ประโยชน์จากการถอดรหัสตามเกณฑ์ คุณสามารถใช้ MPC แทนได้ ตัวอย่างของโปรโตคอล MPC ที่สามารถใช้ใน onchain FHE ได้แก่ 2PC-MPC ใหม่ของ Odsy ซึ่งเป็นอัลกอริธึม MPC ตัวแรกที่ไม่รวมตัวกันและมีการกระจายอำนาจอย่างหนาแน่น

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

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

Zero-Knowledge Proof (ZKP) สำหรับการป้อนข้อมูลของผู้ใช้และฝ่ายคอมพิวเตอร์

ความท้าทาย: การตรวจสอบอินพุตของผู้ใช้ + การคำนวณ:

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

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

โซลูชัน: ZKP สำหรับอินพุตของผู้ใช้ + กลุ่มฝ่ายคอมพิวเตอร์:

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

มีสามวิธีหลักที่ FHE และ ZKP เข้ากันได้:

1. ผู้ใช้จำเป็นต้องส่งหลักฐานว่าไซเฟอร์เท็กซ์อินพุตของตนมีรูปแบบที่ถูกต้อง หมายความว่าไซเฟอร์เท็กซ์ตรงตามข้อกำหนดของรูปแบบการเข้ารหัส และไม่ได้เป็นเพียงสตริงข้อมูลที่กำหนดเอง
2. ผู้ใช้จำเป็นต้องส่งหลักฐานว่าข้อความธรรมดาที่ป้อนนั้นตรงตามเงื่อนไขของแอปพลิเคชันที่กำหนด อดีต. amount_balance > amount_transfer
3. โหนดตรวจสอบความถูกต้อง (หรือที่เรียกว่าฝ่ายประมวลผล) จำเป็นต้องพิสูจน์ว่าพวกเขาดำเนินการคำนวณ FHE อย่างถูกต้อง สิ่งนี้เรียกว่า “FHE ที่ตรวจสอบได้” และมองได้ว่าคล้ายคลึงกับ ZKP ที่จำเป็นสำหรับการสรุปรวม

หากต้องการสำรวจการใช้งานของ ZKP เพิ่มเติม:

1. ZKP ของไซเฟอร์เท็กซ์

FHE สร้างขึ้นจากการเข้ารหัสแบบ Lattice ซึ่งหมายความว่าการสร้างการเข้ารหัสแบบดั้งเดิมนั้นเกี่ยวข้องกับ Lattices ซึ่งมีความปลอดภัย PQ (หลังควอนตัม) ในทางตรงกันข้าม ZKP ยอดนิยม เช่น SNARKS, STARKS และ Bulletproofs ไม่ได้พึ่งพาการเข้ารหัสแบบ Lattice

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

1. ZKP ของการป้อนข้อความธรรมดา

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

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

Sunscreen ยังได้วางรากฐานด้วยคอมไพเลอร์ ZKP ที่ให้การสนับสนุน Bulletproofs เนื่องจากเชื่อมต่อกับ SDLP ได้ง่ายที่สุด การพัฒนาในอนาคตกำลังดำเนินการเพื่อ "เชื่อมโยง" คอมไพเลอร์ FHE และ ZKP

Mind Network เป็นผู้บุกเบิกการบูรณาการ ZKP เพื่อให้มั่นใจว่าอินพุตและเอาท์พุตแบบ Zero Trust ควบคู่ไปกับการใช้ประโยชน์จาก FHE เพื่อการคำนวณที่ปลอดภัย

1. ZKP ของการคำนวณที่ถูกต้อง

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

ต้นแบบแรกของ FHE ที่ตรวจสอบได้สามารถแสดงได้โดยโครงการที่เรียกว่า SherLOCKED โดยพื้นฐานแล้ว การคำนวณ FHE จะถูกถ่ายโอนไปยังบอนไซของ Risc ZERO ซึ่งประมวลผลการคำนวณบนข้อมูลที่เข้ารหัสนอกเชน และส่งคืนผลลัพธ์ด้วย ZKP และอัปเดตสถานะออนเชน

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

สุดท้ายนี้ สิ่งสำคัญคือต้องพิจารณาว่านักพัฒนาสามารถสร้างแอปพลิเคชัน FHE ได้ที่ไหนตั้งแต่แรก นักพัฒนาสามารถสร้างแอปพลิเคชันของตนบน L1 ที่ขับเคลื่อนด้วย FHE, การยกเลิก FHE หรือสร้างบนห่วงโซ่ EVM ใดก็ได้ และใช้ประโยชน์จากตัวประมวลผลร่วม FHE การออกแบบแต่ละอย่างมาพร้อมกับข้อดีข้อเสียที่แตกต่างกันออกไป อย่างไรก็ตาม เรามีแนวโน้มมากขึ้นต่อการรวม FHE ที่ออกแบบมาอย่างดี (บุกเบิกโดย Fhenix) หรือตัวประมวลผลร่วม FHE เนื่องจากพวกมันสืบทอดการรักษาความปลอดภัยจาก Ethereum ท่ามกลางสิทธิประโยชน์อื่นๆ

เมื่อเร็ว ๆ นี้ การบรรลุหลักฐานการฉ้อโกงในข้อมูลที่เข้ารหัสของ FHE มีความซับซ้อน แต่เมื่อเร็ว ๆ นี้ทีมงานที่ Fhenix.io ได้สาธิตวิธีการพิสูจน์การฉ้อโกงโดยใช้สแต็ก Arbitrum Nitro ที่จับคู่กับการคอมไพล์ลอจิก FHE ไปยัง WebAssembly

เลเยอร์ความพร้อมใช้งานของข้อมูล (DA) ของ FHE

ความท้าทาย: ขาดความสามารถในการปรับแต่งและปริมาณงาน

แม้ว่าพื้นที่เก็บข้อมูลจะถูกทำให้เป็นสินค้าใน web2 แต่สิ่งเดียวกันนี้ก็ไม่ถือเป็นจริงใน Web3 เนื่องจาก FHE สามารถรักษาข้อมูลขนาดใหญ่ได้ถึง 10,000x+ เราจึงต้องพิจารณาว่าจะจัดเก็บข้อมูลไซเฟอร์เท็กซ์ FHE ขนาดใหญ่ไว้ที่ใด หากผู้ดำเนินการโหนดทุกรายในเลเยอร์ DA ที่กำหนดดาวน์โหลดและจัดเก็บข้อมูลของห่วงโซ่ FHE ทุกรายการ จะมีเพียงผู้ดำเนินการระดับสถาบันเท่านั้นที่จะสามารถตอบสนองความต้องการได้ ซึ่งเสี่ยงต่อการรวมศูนย์

ในส่วนของปริมาณงาน Celestia มีความเร็วสูงสุดที่ 6.7mb/s หากเราต้องการเรียกใช้ FHEML ในรูปแบบใดๆ เราก็ต้องใช้ n GB+/วินาทีอย่างง่ายดาย ตามข้อมูลล่าสุดที่แชร์โดย 1k(x) เลเยอร์ DA ที่มีอยู่ไม่สามารถรองรับ FHE ได้เนื่องจากการตัดสินใจออกแบบที่จำกัดปริมาณงาน (โดยเจตนา)

โซลูชัน: การปรับขนาดแนวนอน + ความสามารถในการปรับแต่งได้

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

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

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

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

ฮาร์ดแวร์การเข้ารหัส Homomorphic (FHE) อย่างสมบูรณ์

ความท้าทาย: ฮาร์ดแวร์ FHE ประสิทธิภาพต่ำ

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

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

จุดสำคัญของความซับซ้อนในการคำนวณและการออกแบบฮาร์ดแวร์สำหรับ FHE นั้นสัมพันธ์กับจำนวนการคูณที่จำเป็นสำหรับแอปพลิเคชันที่กำหนดเสมอ ซึ่งเรียกว่า "ความลึกของการดำเนินการแบบโฮโมมอร์ฟิก" ในกรณีเฉพาะของแอปพลิเคชัน จะทราบความลึก ดังนั้นพารามิเตอร์ของระบบและการคำนวณที่เกี่ยวข้องจึงได้รับการแก้ไข ดังนั้น การออกแบบฮาร์ดแวร์สำหรับกรณีเฉพาะแอปพลิเคชันนี้จะง่ายกว่า และมักจะสามารถปรับให้เหมาะสมเพื่อประสิทธิภาพที่ดีกว่าการออกแบบตัวเร่งความเร็วทั่วไป ในกรณีทั่วไป เมื่อ FHE จำเป็นต้องรองรับการคูณตามจำนวนที่ต้องการ การบูตสแตรปปิ้งจึงเป็นสิ่งจำเป็นเพื่อกำจัดเสียงรบกวนที่สะสมอยู่ในการดำเนินการแบบโฮโมมอร์ฟิก การบูตสแตรปปิ้งมีราคาแพงและต้องใช้ทรัพยากรฮาร์ดแวร์จำนวนมาก รวมถึงหน่วยความจำบนชิป แบนด์วิดท์หน่วยความจำ และการคำนวณ ซึ่งหมายความว่าการออกแบบฮาร์ดแวร์จะแตกต่างจากการออกแบบเฉพาะแอปอย่างมาก ดังนั้น แม้ว่างานที่ทำโดยผู้เล่นหลักๆ ในวงการ รวมถึง Intel, Duality, SRI, DARPA และอื่นๆ อีกมากมาย ไม่ต้องสงสัยเลยว่าเป็นการก้าวข้ามขีดจำกัดด้วยการออกแบบที่ใช้ GPU และ ASIC ของพวกเขา แต่งานเหล่านั้นอาจไม่สามารถใช้งานแบบ 1:1 ได้ รองรับกรณีการใช้งานบล็อคเชน

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

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

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

มีโมดูลทั่วไปบางส่วนระหว่าง ZKP และ FHE เช่น การแปลงทฤษฎีจำนวน (NTT) และการดำเนินการพหุนามพื้นฐาน อย่างไรก็ตาม ความกว้างบิตของ NTT ที่ใช้ในทั้งสองกรณีนี้จะแตกต่างกัน ใน ZKP ฮาร์ดแวร์จำเป็นต้องรองรับความกว้างบิตที่หลากหลายสำหรับ NTT เช่น 64 บิตและ 256 บิต ในขณะที่ FHE ตัวถูกดำเนินการสำหรับ NTT จะสั้นกว่าเนื่องจากแสดงอยู่ในระบบตัวเลขตกค้าง ประการที่สอง ระดับของ NTT ที่ได้รับการจัดการใน ZKP โดยทั่วไปนั้นสูงกว่าระดับของกรณี FHE เนื่องจากเหตุผลทั้งสองนี้ การออกแบบโมดูล NTT ที่ให้ประสิทธิภาพที่น่าพอใจสำหรับทั้ง ZKP และ FHE จึงไม่ใช่เรื่องเล็กน้อย นอกเหนือจาก NTT แล้ว ยังมีปัญหาคอขวดด้านการประมวลผลอื่นๆ ใน FHE เช่น ออโตมอร์ฟิซึม ซึ่งไม่มีอยู่ใน ZKP วิธีที่ไร้เดียงสาในการถ่ายโอนฮาร์ดแวร์ ZKP ไปยังการตั้งค่า FHE คือการถ่ายโอนงานการประมวลผล NTT ไปยังฮาร์ดแวร์ ZKP และใช้ CPU หรือฮาร์ดแวร์อื่นๆ เพื่อจัดการส่วนที่เหลือของการคำนวณใน FHE

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

โซลูชั่น:

1. การปรับปรุงฮาร์ดแวร์ FHE

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

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

1. ซอฟต์แวร์และฮาร์ดแวร์ที่ปรับให้เหมาะสม

ในการพัฒนาล่าสุด ซอฟต์แวร์ได้รับการยอมรับว่าเป็นองค์ประกอบสำคัญในกระบวนการเร่งความเร็วด้วยฮาร์ดแวร์ ตัวอย่างเช่น ตัวเร่งความเร็ว FHE ที่โดดเด่น เช่น F1 และ CraterLake ใช้คอมไพเลอร์สำหรับแนวทางการออกแบบร่วมของซอฟต์แวร์/ฮาร์ดแวร์แบบไฮบริด

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

1. ตัวเร่งความเร็ว FHE ของเครือข่าย: การเปลี่ยนแปลงจากการขยายขนาดไปสู่การขยายขนาด

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

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

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

บทสรุป

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

เมื่อเราก้าวเข้าสู่ขอบเขตใหม่นี้ การทำงานร่วมกันระหว่างนักเข้ารหัส วิศวกรซอฟต์แวร์ และผู้เชี่ยวชาญด้านฮาร์ดแวร์จะมีความจำเป็น ไม่ต้องพูดถึงผู้ร่างกฎหมาย นักการเมือง ฯลฯ เนื่องจากการปฏิบัติตามกฎระเบียบเป็นหนทางเดียวที่จะนำไปสู่การนำไปใช้ในกระแสหลัก

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

ขอขอบคุณเป็นพิเศษ：

ขอขอบคุณ Mason Song (Mind Network), Guy Itzhaki (Fhenix), Leo Fan (Cysic), Kurt Pan, Xiang Xie (PADO), Nitanshu Lokhande (BananaHQ) สำหรับการรีวิว เราหวังว่าจะได้อ่านเกี่ยวกับงานที่น่าประทับใจและความพยายามที่บุคคลเหล่านี้ทำในภาคสนาม!

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

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