ชื่อเดิม: "อนาคตที่เป็นไปได้ของโปรโตคอล Ethereum ตอนที่ 6: The Splurge"
ผู้เขียนต้นฉบับ: @VitalikButerin
เรียบเรียงต้นฉบับ: zhouzhou, BlockBeats
ต่อไปนี้เป็นเนื้อหาต้นฉบับ (เนื้อหาต้นฉบับได้รับการแก้ไขเพื่อความสะดวกในการอ่านและทำความเข้าใจ):
บางสิ่งเป็นเรื่องยากที่จะจัดให้อยู่ในหมวดหมู่เดียว และมี "รายละเอียดเล็กๆ น้อยๆ" มากมายในการออกแบบโปรโตคอล Ethereum ที่มีความสำคัญมากต่อความสำเร็จของ Ethereum ในความเป็นจริง ประมาณครึ่งหนึ่งของเนื้อหาครอบคลุมการปรับปรุง EVM ประเภทต่างๆ และส่วนที่เหลือประกอบด้วยหัวข้อเฉพาะต่างๆ ซึ่งเป็นสิ่งที่ "เจริญรุ่งเรือง" เป็นเรื่องเกี่ยวกับ
แผนงานปี 2023: ความเจริญรุ่งเรือง
ความเจริญรุ่งเรือง: เป้าหมายสำคัญ
เปลี่ยน EVM ให้เป็น "สถานะสิ้นสุด" ที่มีประสิทธิภาพสูงและมีเสถียรภาพ
การแนะนำบัญชีที่เป็นนามธรรมในโปรโตคอล ทำให้ผู้ใช้ทุกคนเพลิดเพลินไปกับบัญชีที่ปลอดภัยและสะดวกสบายมากขึ้น
เพิ่มประสิทธิภาพการประหยัดค่าธรรมเนียมการทำธุรกรรม เพิ่มความสามารถในการขยายขนาดในขณะที่ลดความเสี่ยง
สำรวจการเข้ารหัสขั้นสูงเพื่อปรับปรุง Ethereum อย่างมีนัยสำคัญในระยะยาว
เนื้อหาของบทนี้
VDF (ฟังก์ชันหน่วงเวลาที่ตรวจสอบได้)
การสร้างความสับสนและลายเซ็นแบบครั้งเดียว: อนาคตอันยาวนานของการเข้ารหัส
การปรับปรุง EVM
แก้ไขปัญหาอะไรไปแล้ว?
EVM ในปัจจุบันนั้นยากต่อการวิเคราะห์แบบคงที่ ซึ่งทำให้ยากต่อการสร้างการใช้งานที่มีประสิทธิภาพ ตรวจสอบโค้ดอย่างเป็นทางการ และสร้างส่วนขยายเพิ่มเติม นอกจากนี้ EVM ยังไม่มีประสิทธิภาพและยากต่อการปรับใช้การเข้ารหัสขั้นสูงหลายรูปแบบ เว้นแต่จะได้รับการสนับสนุนอย่างชัดเจนผ่านการคอมไพล์ล่วงหน้า
มันคืออะไรและมันทำงานอย่างไร?
ขั้นตอนแรกในแผนงานการปรับปรุง EVM ในปัจจุบันคือ EVM Object Format (EOF) ซึ่งได้รับการวางแผนว่าจะรวมไว้ใน Hard Fork ครั้งถัดไป EOF คือชุดของ EIP ที่ระบุเวอร์ชันโค้ด EVM ใหม่พร้อมคุณลักษณะเฉพาะหลายประการ โดยเฉพาะอย่างยิ่ง:
การแยกระหว่างโค้ด (ปฏิบัติการได้ แต่ไม่สามารถอ่านได้จาก EVM) และข้อมูล (สามารถอ่านได้ แต่ไม่สามารถปฏิบัติการได้)
ห้ามกระโดดแบบไดนามิกและอนุญาตให้กระโดดแบบคงที่เท่านั้น
รหัส EVM ไม่สามารถสังเกตข้อมูลที่เกี่ยวข้องกับน้ำมันเชื้อเพลิงได้อีกต่อไป
เพิ่มกลไกรูทีนย่อยที่ชัดเจนใหม่
โครงสร้างของรหัส EOF
Boom: การปรับปรุง EVM (ต่อ)
สัญญาแบบเดิมจะยังคงมีอยู่และสามารถสร้างได้ แม้ว่าในที่สุดสัญญาเหล่านั้นอาจถูกยุติลง (และอาจถูกบังคับให้ใช้โค้ด EOF ด้วยซ้ำ) สัญญารูปแบบใหม่จะได้รับประโยชน์จากการปรับปรุงประสิทธิภาพที่ EOF นำเสนอ - อันดับแรกจากไบต์โค้ดที่เล็กลงเล็กน้อยผ่านฟีเจอร์รูทีนย่อย และต่อมาจากฟังก์ชันใหม่เฉพาะของ EOF หรือต้นทุนก๊าซที่ลดลง
หลังจากการเปิดตัว EOF การอัพเกรดเพิ่มเติมก็กลายเป็นเรื่องง่าย การพัฒนามากที่สุดในปัจจุบันคือ ส่วนขยายเลขคณิตของโมดูล EVM (EVM-MAX) EVM-MAX สร้างชุดการดำเนินการใหม่โดยเฉพาะสำหรับเลขคณิตแบบโมดูลาร์ และวางไว้ในพื้นที่หน่วยความจำใหม่ที่ไม่สามารถเข้าถึงได้ผ่าน opcode อื่นๆ ทำให้สามารถใช้การปรับให้เหมาะสม เช่น การคูณมอนต์โกเมอรี่
แนวคิดที่ใหม่กว่าคือการรวม EVM-MAX เข้ากับคุณสมบัติ Single Instruction Multiple Data (SIMD) SIMD เป็นแนวคิดใน Ethereum มาเป็นเวลานานและถูกเสนอครั้งแรกโดย EIP-616 ของ Greg Colvin SIMD สามารถใช้เพื่อเร่งความเร็วการเข้ารหัสได้หลายรูปแบบ รวมถึงฟังก์ชันแฮช, STARK 32 บิต และการเข้ารหัสแบบ Lattice และการผสมผสานระหว่าง EVM-MAX และ SIMD ทำให้ส่วนขยายที่มุ่งเน้นประสิทธิภาพทั้งสองนี้เป็นการจับคู่ที่เป็นธรรมชาติ
การออกแบบคร่าวๆ ของ EIP แบบรวมจะเริ่มต้นด้วย EIP-6690 จากนั้น:
อนุญาตให้ (i) เลขคี่ใดๆ หรือ (ii) กำลังใดๆ ของ 2 จนถึง 2768 เป็นโมดูลัส
สำหรับ opcode EVM-MAX แต่ละรายการ (การบวก การลบ การคูณ) ให้เพิ่มเวอร์ชันที่แทนที่จะใช้ 3 ทันที x, y, z ให้ใช้ 7 ทันที: x_start, x_skip, y_start, y_skip , z_start, z_skip, count ในโค้ด Python opcode เหล่านี้ทำงานดังนี้:
สำหรับฉันอยู่ในช่วง (นับ):
mem[z_start + z_skip * นับ] = op(
บันทึก [x_start + x_skip * นับ],
mem[y_start + y_skip * นับ]
-
ในการใช้งานจริงจะต้องจัดการควบคู่กันไป
อาจเพิ่ม XOR, AND, OR, NOT และ SHIFT (ทั้งแบบวนและแบบอะไซคลิก) อย่างน้อยก็สำหรับกำลังของ 2 โมดูโล นอกจากนี้ เพิ่ม ISZERO (พุชเอาท์พุตไปยังสแต็กหลัก EVM) ซึ่งจะมีประสิทธิภาพเพียงพอที่จะใช้การเข้ารหัสแบบเส้นโค้งวงรี การเข้ารหัสโดเมนขนาดเล็ก (เช่น Poseidon, Circle STARKs) ฟังก์ชันแฮชแบบดั้งเดิม (เช่น SHA 256, KECCAK, BLAKE) และ การเข้ารหัสแบบ Lattice การอัพเกรด EVM อื่นๆ สามารถทำได้ แต่ได้รับความสนใจน้อยลงจนถึงตอนนี้
ลิงก์ไปยังงานวิจัยที่มีอยู่
EOF: https://evmobjectformat.org/
EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690
SIMD: https://eips.ethereum.org/EIPS/eip-616
งานที่เหลือและการแลกเปลี่ยน
ปัจจุบัน EOF มีแผนที่จะรวมอยู่ในฮาร์ดฟอร์คครั้งถัดไป แม้ว่าจะสามารถลบออกได้ในนาทีสุดท้ายเสมอ แต่ฟีเจอร์ต่างๆ ได้ถูกลบออกชั่วคราวในฮาร์ดฟอร์กครั้งก่อนๆ แล้ว การทำเช่นนั้นค่อนข้างท้าทาย การลบ EOF หมายความว่าการอัพเกรด EVM ในอนาคตจะต้องดำเนินการโดยไม่ต้องใช้ EOF ซึ่งสามารถทำได้ แต่อาจทำได้ยากกว่า
ข้อเสียเปรียบหลักของ EVM คือความซับซ้อนของ L1 และความซับซ้อนของโครงสร้างพื้นฐาน EOF คือโค้ดจำนวนมากที่ต้องเพิ่มในการใช้งาน EVM และการตรวจสอบโค้ดแบบคงที่ก็ค่อนข้างซับซ้อนเช่นกัน อย่างไรก็ตาม เพื่อเป็นการแลกเปลี่ยน เราได้รับภาษาระดับสูงที่เรียบง่าย การใช้งาน EVM ที่เรียบง่าย และสิทธิประโยชน์อื่นๆ อาจกล่าวได้ว่าแผนงานที่จัดลำดับความสำคัญของการปรับปรุงอย่างต่อเนื่องของ Ethereum L1 ควรรวมและสร้างบน EOF
งานสำคัญที่ต้องทำคือการใช้ฟังก์ชันที่คล้ายกับ EVM-MAX plus SIMD และเปรียบเทียบปริมาณการใช้ก๊าซของการดำเนินการเข้ารหัสต่างๆ
ฉันจะโต้ตอบกับส่วนอื่นๆ ของแผนงานได้อย่างไร
L1 ปรับ EVM เพื่อให้ L2 สามารถปรับตามได้ง่ายขึ้น หากทั้งสองไม่ปรับพร้อมกัน อาจทำให้เกิดความไม่เข้ากันและก่อให้เกิดผลเสีย นอกจากนี้ EVM-MAX และ SIMD ยังสามารถลดต้นทุนก๊าซของระบบพิสูจน์อักษรหลายระบบ ทำให้ L2 มีประสิทธิภาพมากขึ้น นอกจากนี้ยังทำให้ง่ายต่อการแทนที่การคอมไพล์ล่วงหน้าเพิ่มเติมด้วยโค้ด EVM ที่สามารถทำงานเดียวกันได้ โดยไม่ส่งผลกระทบต่อประสิทธิภาพอย่างมาก
นามธรรมบัญชี
แก้ไขปัญหาอะไรไปแล้ว?
ปัจจุบัน ธุรกรรมสามารถตรวจสอบได้เพียงวิธีเดียวเท่านั้น: ลายเซ็น ECDSA ในขั้นต้น การแยกบัญชีมีจุดมุ่งหมายให้ไปไกลกว่านั้น โดยอนุญาตให้ตรรกะการตรวจสอบบัญชีเป็นโค้ด EVM ที่กำหนดเองได้ สิ่งนี้ทำให้สามารถใช้งานที่หลากหลาย:
เปลี่ยนไปใช้การเข้ารหัสแบบต้านทานควอนตัม
หมุนเวียนคีย์เก่า ( ซึ่งถือเป็นหลักปฏิบัติด้านความปลอดภัยที่แนะนำ อย่างกว้างขวาง)
กระเป๋าเงินหลายลายเซ็นและ กระเป๋าเงินเพื่อการฟื้นฟูทางสังคม
ใช้คีย์หนึ่งสำหรับการดำเนินการที่มีมูลค่าต่ำและอีกคีย์หนึ่ง (หรือชุดของคีย์) สำหรับการดำเนินการที่มีมูลค่าสูง
ช่วยให้โปรโตคอลความเป็นส่วนตัวทำงานโดยไม่ต้องรีเลย์ ซึ่งลดความซับซ้อนลงอย่างมาก และขจัดจุดพึ่งพาส่วนกลางที่สำคัญ
นับตั้งแต่มีการเสนอบัญชีที่เป็นนามธรรมในปี 2558 เป้าหมายก็ได้ขยายไปสู่ "เป้าหมายความสะดวกสบาย" จำนวนมาก ตัวอย่างเช่น บัญชีที่ไม่มี ETH แต่มี ERC 20 บางตัวสามารถชำระค่าน้ำมันด้วย ERC 20 ได้ นี่คือแผนภูมิสรุปของเป้าหมายเหล่านี้:
MPC (การคำนวณแบบหลายฝ่าย) เป็น เทคโนโลยีอายุ 40 ปี ที่ใช้ในการแยกคีย์ออกเป็นหลายส่วนและจัดเก็บไว้ในอุปกรณ์หลายเครื่อง โดยใช้เทคนิคการเข้ารหัสเพื่อสร้างลายเซ็นโดยไม่ต้องรวมส่วนสำคัญโดยตรง
EIP-7702 เป็นข้อเสนอที่วางแผนไว้ว่าจะเปิดตัวใน Hard Fork ครั้งถัดไป EIP-7702 เป็นผลมาจากการรับรู้ที่เพิ่มขึ้นในการมอบความสะดวกสบายในการลบบัญชีเพื่อเป็นประโยชน์ต่อผู้ใช้ทุกคน รวมถึงผู้ใช้ EOA และมีเป้าหมายที่จะปรับปรุงผู้ใช้ทุกคนในระยะสั้น ประสบการณ์และหลีกเลี่ยงการแยกออกเป็นสองระบบนิเวศ
งานเริ่มต้นด้วย EIP-3074 และในที่สุดก็นำไปสู่ EIP-7702 EIP-7702 มอบ "ฟังก์ชันอำนวยความสะดวก" ของการลบบัญชีให้กับผู้ใช้ทุกคน รวมถึง EOA ในปัจจุบัน (บัญชีที่เป็นเจ้าของภายนอก นั่นคือบัญชีที่ควบคุมโดยลายเซ็น ECDSA)
ดังที่คุณเห็นจากแผนภูมิ ในขณะที่ความท้าทายบางอย่าง (โดยเฉพาะความท้าทายด้าน "ความสะดวกสบาย") สามารถแก้ไขได้ด้วยเทคโนโลยีที่เพิ่มขึ้น เช่น การคำนวณแบบหลายฝ่ายหรือ EIP-7702 แต่เป้าหมายด้านความปลอดภัยหลักของข้อเสนอนามธรรมบัญชีเดิมสามารถแก้ไขได้เท่านั้น โดยการย้อนรอยและแก้ไขปัญหาเดิม เพื่อให้บรรลุ: อนุญาตให้ใช้รหัสสัญญาอัจฉริยะเพื่อควบคุมการตรวจสอบธุรกรรม เหตุผลที่ยังไม่สามารถทำได้จนถึงขณะนี้ก็คือการนำไปปฏิบัติอย่างปลอดภัยถือเป็นความท้าทาย
มันคืออะไรและมันทำงานอย่างไร?
แก่นหลักของนามธรรมบัญชีนั้นเรียบง่าย: อนุญาตให้สัญญาอัจฉริยะเริ่มธุรกรรม ไม่ใช่แค่ EOA ความซับซ้อนทั้งหมดมาจากการนำสิ่งนี้ไปใช้ในลักษณะที่เป็นมิตรต่อการรักษาเครือข่ายแบบกระจายอำนาจและป้องกันการโจมตีแบบปฏิเสธการบริการ
ความท้าทายหลักโดยทั่วไปคือปัญหาความล้มเหลวหลายประการ:
หากมี 1,000 บัญชีที่ฟังก์ชันการตรวจสอบทั้งหมดขึ้นอยู่กับค่า S เดียว และค่า S ปัจจุบันทำให้ธุรกรรมทั้งหมดใน mempool ถูกต้อง ดังนั้นธุรกรรมเดียวที่พลิกค่าของ S อาจทำให้ธุรกรรมอื่น ๆ ทั้งหมดในธุรกรรมนั้นไม่ถูกต้อง . ช่วยให้ผู้โจมตีสามารถส่งสแปมธุรกรรมไปยัง mempool ด้วยต้นทุนที่ต่ำมาก ซึ่งทำให้เกิดการอุดตันทรัพยากรของโหนดเครือข่าย
หลังจากการทำงานหนักหลายปีโดยมุ่งเป้าไปที่การขยายฟังก์ชันการทำงานในขณะที่จำกัดความเสี่ยงจากการปฏิเสธการบริการ (DoS) ในที่สุดโซลูชันเพื่อให้บรรลุ "การสร้างนามธรรมบัญชีในอุดมคติ" ก็มาถึงแล้วที่: ERC-4337
ERC-4337 ทำงานโดยแบ่งการประมวลผลการดำเนินงานของผู้ใช้ออกเป็นสองขั้นตอน: การตรวจสอบและการดำเนินการ การตรวจสอบความถูกต้องทั้งหมดจะได้รับการจัดการก่อน การดำเนินการทั้งหมดจะได้รับการจัดการในภายหลัง ใน mempool การกระทำของผู้ใช้จะได้รับการยอมรับก็ต่อเมื่อขั้นตอนการตรวจสอบเกี่ยวข้องกับบัญชีของตนเองเท่านั้น และไม่ได้อ่านตัวแปรสภาพแวดล้อม วิธีนี้จะช่วยป้องกันการโจมตีที่ไม่ถูกต้องหลายครั้ง นอกจากนี้ มีการบังคับใช้ขีดจำกัดก๊าซที่เข้มงวดในขั้นตอนการตรวจสอบ
ERC-4337 ได้รับการออกแบบให้เป็นมาตรฐานโปรโตคอลเพิ่มเติม (ERC) เนื่องจากในขณะนั้น นักพัฒนาไคลเอนต์ Ethereum มุ่งเน้นไปที่การผสานรวมและไม่มีพลังงานเพิ่มเติมในการจัดการกับฟังก์ชันอื่น ๆ นั่นเป็นเหตุผลที่ ERC-4337 ใช้ออบเจ็กต์ที่เรียกว่า User Action แทนธุรกรรมปกติ อย่างไรก็ตาม เมื่อเร็วๆ นี้เราได้ตระหนักว่าอย่างน้อยบางส่วนจำเป็นต้องเขียนลงในโปรโตคอล
เหตุผลสำคัญสองประการมีดังนี้:
1. ความไร้ประสิทธิภาพโดยธรรมชาติของ EntryPoint ตามสัญญา: ค่าใช้จ่ายคงที่ประมาณ 100,000 ก๊าซต่อชุด และก๊าซเพิ่มเติมหลายพันรายการต่อการดำเนินงานของผู้ใช้
2. ความจำเป็นในการรับรองคุณสมบัติของ Ethereum: การรับประกันการรวมที่สร้างขึ้นโดยรายการการรวมจะต้องถูกโอนไปยังผู้ใช้ที่เป็นนามธรรมของบัญชี
นอกจากนี้ ERC-4337 ยังขยายฟังก์ชันอีก 2 ฟังก์ชัน:
ผู้ชำระเงิน: คุณสมบัติที่อนุญาตให้บัญชีหนึ่งชำระค่าธรรมเนียมในนามของบัญชีอื่น ซึ่งถือเป็นการละเมิดกฎที่สามารถเข้าถึงได้เฉพาะบัญชีผู้ส่งเท่านั้นในระหว่างขั้นตอนการตรวจสอบ ดังนั้นจึงมีการนำการจัดการพิเศษมาใช้เพื่อให้มั่นใจในความปลอดภัยของกลไกการชำระเงินหลัก
ผู้รวบรวม: รองรับฟังก์ชันการรวมลายเซ็น เช่น การรวม BLS หรือการรวมตาม SNARK นี่เป็นสิ่งจำเป็นเพื่อให้บรรลุประสิทธิภาพข้อมูลสูงสุดบน Rollup
ลิงก์ไปยังงานวิจัยที่มีอยู่
บรรยายประวัตินามธรรมบัญชี: https://www.youtube.com/watch?v=iLf8qpOmxQc
ERC-4337: https://eips.ethereum.org/EIPS/eip-4337
EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
รหัส BLSWallet (ใช้ฟังก์ชันการรวม): https://github.com/getwax/bls-wallet
EIP-7562 (นามธรรมบัญชีที่เขียนลงในโปรโตคอล): https://eips.ethereum.org/EIPS/eip-7562
EIP-7701 (นามธรรมบัญชีโปรโตคอลการเขียนที่ใช้ EOF): https://eips.ethereum.org/EIPS/eip-7701
งานที่เหลือและการแลกเปลี่ยน
สิ่งสำคัญที่ต้องแก้ไขในปัจจุบันคือวิธีการแนะนำบัญชีที่เป็นนามธรรมในโปรโตคอลอย่างสมบูรณ์ EIP บัญชีที่ได้รับความนิยมเมื่อเร็ว ๆ นี้ที่เขียนลงในโปรโตคอลคือ EIP-7701 ข้อเสนอนี้ใช้บัญชีนามธรรมนอกเหนือจาก EOF บัญชีสามารถมีส่วนรหัสแยกต่างหากสำหรับการตรวจสอบ และหากบัญชีมีการตั้งค่าส่วนรหัสนั้น รหัสจะถูกดำเนินการในระหว่างขั้นตอนการตรวจสอบธุรกรรมจากบัญชีนั้น
สิ่งที่น่าสนใจเกี่ยวกับแนวทางนี้คือ มันแสดงให้เห็นอย่างชัดเจนสองมุมมองที่เทียบเท่ากันเกี่ยวกับนามธรรมของบัญชีท้องถิ่น:
1. ทำให้ EIP-4337 เป็นส่วนหนึ่งของโปรโตคอล
2. EOA รูปแบบใหม่ที่มีอัลกอริธึมลายเซ็นคือการเรียกใช้โค้ด EVM
หากเราเริ่มต้นด้วยการกำหนดขอบเขตที่เข้มงวดกับความซับซ้อนของโค้ดที่เรียกใช้งานได้ในระหว่างการตรวจสอบ - ไม่อนุญาตให้เข้าถึงสถานะภายนอก และแม้แต่ขีดจำกัดของก๊าซที่ตั้งไว้ในตอนแรกก็ต่ำเกินไปที่จะมีประสิทธิภาพสำหรับแอปพลิเคชันที่ต้านทานควอนตัมหรือรักษาความเป็นส่วนตัว - ดังนั้นแนวทางนี้ การรักษาความปลอดภัยมีความชัดเจนมาก เพียงแทนที่การตรวจสอบ ECDSA ด้วยการเรียกใช้โค้ด EVM ซึ่งใช้เวลาใกล้เคียงกัน
อย่างไรก็ตาม เมื่อเวลาผ่านไป เราจะต้องผ่อนคลายขอบเขตเหล่านี้ เนื่องจากการอนุญาตให้แอปพลิเคชันที่รักษาความเป็นส่วนตัวทำงานโดยไม่ต้องใช้รีเลย์ และการต้านทานควอนตัม เป็นสิ่งสำคัญทั้งคู่ ในการทำเช่นนี้ เราจำเป็นต้องค้นหาวิธีที่ยืดหยุ่นมากขึ้นในการจัดการกับความเสี่ยงจากการปฏิเสธการบริการ (DoS) โดยไม่ต้องมีขั้นตอนการตรวจสอบยืนยันขั้นต่ำ
ข้อเสียเปรียบหลักๆ น่าจะเป็น "เขียนวิธีแก้ปัญหาอย่างรวดเร็วเพื่อให้คนพอใจน้อยลง" เทียบกับ "รอนานกว่านี้และอาจได้วิธีแก้ปัญหาที่เหมาะสมกว่า" แนวทางที่เหมาะสมที่สุดน่าจะเป็นแนวทางแบบผสมผสาน แนวทางแบบผสมผสานคือการเขียนกรณีการใช้งานบางกรณีให้เร็วขึ้น และปล่อยให้มีเวลาสำรวจกรณีอื่นๆ มากขึ้น อีกแนวทางหนึ่งคือการปรับใช้ Account Abstraction ในเวอร์ชันที่มีความทะเยอทะยานมากขึ้นใน L2 ก่อน อย่างไรก็ตาม ความท้าทายในเรื่องนี้ก็คือ ทีมงาน L2 จำเป็นต้องมั่นใจในงานรับข้อเสนอก่อนที่จะเต็มใจดำเนินการ โดยเฉพาะอย่างยิ่งเพื่อให้แน่ใจว่า L1 และ/หรือ L2 อื่นๆ สามารถใช้แนวทางที่เข้ากันได้ในอนาคต
แอปพลิเคชันอื่นที่เราต้องพิจารณาอย่างชัดเจนคือ บัญชีพื้นที่เก็บข้อมูลคีย์ ซึ่งจัดเก็บสถานะที่เกี่ยวข้องกับบัญชีบน L1 หรือ L2 เฉพาะ แต่สามารถใช้บน L1 และ L2 ที่เข้ากันได้ การดำเนินการนี้อย่างมีประสิทธิภาพอาจกำหนดให้ L2 รองรับ opcode เช่น L1S LOAD หรือ REMOTESTATICCALL แต่การดำเนินการนี้ยังกำหนดให้การใช้งานนามธรรมของบัญชีบน L2 รองรับการดำเนินการเหล่านี้ด้วย
มันโต้ตอบกับส่วนอื่น ๆ ของแผนการทำงานอย่างไร?
รายการที่รวมไว้จำเป็นต้องสนับสนุนธุรกรรมที่เป็นนามธรรมของบัญชี และในทางปฏิบัติแล้ว ความต้องการของรายการที่รวมไว้นั้นจริงๆ แล้วคล้ายคลึงกับของ Mempool แบบกระจายอำนาจมาก แม้ว่ารายการที่รวมจะมีความยืดหยุ่นมากกว่าเล็กน้อยก็ตาม นอกจากนี้ การใช้งานนามธรรมบัญชีควรได้รับการประสานงานระหว่าง L1 และ L2 ทุกครั้งที่เป็นไปได้ หากในอนาคตเราคาดหวังให้ผู้ใช้ส่วนใหญ่ใช้การรวบรวมคีย์การจัดเก็บ การออกแบบนามธรรมบัญชีควรเป็นไปตามสิ่งนี้
การปรับปรุง EIP-1559
มันแก้ปัญหาอะไรได้บ้าง?
EIP-1559 ถูกเปิดใช้งานบน Ethereum ในปี 2021 ซึ่งช่วยปรับปรุงเวลาการรวมบล็อกโดยเฉลี่ยได้อย่างมาก
รอเวลา
อย่างไรก็ตาม การใช้งาน EIP-1559 ในปัจจุบัน ยังไม่สมบูรณ์ในหลายด้าน:
1. สูตรมีข้อบกพร่องเล็กน้อย: ไม่ได้กำหนดเป้าหมายไปที่ 50% ของบล็อก แต่ประมาณ 50-53% ของบล็อกทั้งหมด ขึ้นอยู่กับความแปรปรวน (ซึ่งไม่สอดคล้องกับสิ่งที่นักคณิตศาสตร์เรียกว่า "ความไม่เท่าเทียมกันของค่าเฉลี่ยเลขคณิต-เรขาคณิต" " ที่เกี่ยวข้อง).
2. ปรับตัวได้ไม่เร็วพอในสถานการณ์ที่รุนแรง
สูตรภายหลังสำหรับ blobs (EIP-4844) ได้รับการออกแบบมาโดยเฉพาะเพื่อแก้ไขปัญหาแรกและโดยรวมง่ายกว่า อย่างไรก็ตาม ทั้ง EIP-1559 และ EIP-4844 ไม่ได้พยายามที่จะแก้ไขปัญหาที่สอง สภาพที่เป็นอยู่จึงเป็นรัฐกลางที่ยุ่งวุ่นวายซึ่งเกี่ยวข้องกับกลไกสองอย่างที่แตกต่างกัน และมีข้อโต้แย้งว่าทั้งสองกลไกจะต้องได้รับการปรับปรุงเมื่อเวลาผ่านไป
นอกจากนี้ยังมีจุดอ่อนอื่นๆ ในราคาทรัพยากร Ethereum ที่ไม่เกี่ยวข้องกับ EIP-1559 แต่สามารถแก้ไขได้ด้วยการปรับเปลี่ยน EIP-1559 ปัญหาหลักประการหนึ่งคือความแตกต่างระหว่างสถานการณ์โดยเฉลี่ยและกรณีที่เลวร้ายที่สุด: ราคาทรัพยากรใน Ethereum จะต้องได้รับการตั้งค่าเพื่อจัดการกับสถานการณ์กรณีที่เลวร้ายที่สุด ซึ่งปริมาณการใช้ก๊าซทั้งหมดของบล็อกจะใช้ทรัพยากร แต่การใช้งานโดยเฉลี่ยที่แท้จริงคือ ต่ำกว่านี้มากจนทำให้ขาดประสิทธิภาพ
ก๊าซหลายมิติคืออะไร และทำงานอย่างไร
วิธีแก้ปัญหาความไร้ประสิทธิภาพเหล่านี้คือ ก๊าซหลายมิติ : การกำหนดราคาและขีดจำกัดที่แตกต่างกันสำหรับทรัพยากรที่แตกต่างกัน แนวคิดนี้ไม่ขึ้นอยู่กับ EIP-1559 ในทางเทคนิค แต่การมีอยู่ของ EIP-1559 ทำให้การนำโซลูชันนี้ไปใช้ได้ง่ายขึ้น หากไม่มี EIP-1559 การบรรจุบล็อกที่มีข้อจำกัดด้านทรัพยากรหลายรายการอย่างเหมาะสมที่สุดจะเป็น ปัญหากระเป๋าเป้สะพายหลังหลายมิติที่ซับซ้อน ด้วย EIP-1559 บล็อกส่วนใหญ่จะใช้งานทรัพยากรได้ไม่เต็มประสิทธิภาพ ดังนั้นอัลกอริทึมง่ายๆ เช่น "ยอมรับธุรกรรมที่จ่ายค่าธรรมเนียมเพียงพอ" ก็เพียงพอแล้ว
ขณะนี้เรามีก๊าซหลายมิติสำหรับการดำเนินการและบล็อกข้อมูล โดยหลักการแล้ว เราสามารถขยายสิ่งนี้ไปยังมิติอื่น ๆ ได้มากขึ้น เช่น ข้อมูลการโทร (ข้อมูลธุรกรรม) การอ่าน/เขียนสถานะ และการขยายขนาดสถานะ
EIP-7706 แนะนำมิติก๊าซใหม่สำหรับข้อมูลการโทรโดยเฉพาะ ในขณะเดียวกัน ยังช่วยลดความซับซ้อนของกลไกก๊าซหลายมิติด้วยการรวมก๊าซสามประเภทเข้าไว้ในกรอบงาน (สไตล์ EIP-4844) ดังนั้นจึงแก้ไขข้อบกพร่องทางคณิตศาสตร์ของ EIP-1559 ได้ด้วย EIP-7623 เป็นโซลูชันที่แม่นยำยิ่งขึ้น ซึ่งจำกัดข้อมูลการโทรสูงสุดสำหรับปัญหาทรัพยากรโดยเฉลี่ยและกรณีที่เลวร้ายที่สุดอย่างเคร่งครัดยิ่งขึ้น โดยไม่ต้องเปิดมิติใหม่ทั้งหมด
ทิศทางการวิจัยเพิ่มเติมคือการแก้ปัญหาอัตราการอัปเดตและค้นหาอัลกอริธึมการคำนวณค่าธรรมเนียมพื้นฐานที่เร็วขึ้นโดยยังคงรักษาค่าคงที่ที่สำคัญที่แนะนำโดยกลไก EIP-4844 (เช่น ในระยะยาวการใช้งานโดยเฉลี่ยจะใกล้เคียงกับค่าเป้าหมายเท่านั้น ).
ลิงก์ไปยังงานวิจัยที่มีอยู่
EIP-1559 คำถามที่พบบ่อย: EIP-1559 คำถามที่พบบ่อย
การวิเคราะห์เชิงประจักษ์ใน EIP-1559: การวิเคราะห์เชิงประจักษ์
การปรับปรุงที่เสนอเพื่อให้สามารถปรับเปลี่ยนได้อย่างรวดเร็ว: การปรับปรุงที่เสนอ
ส่วนเกี่ยวกับกลไกค่าธรรมเนียมพื้นฐานใน EIP-4844 FAQ: EIP-4844 FAQ
EIP-7706: EIP-7706
EIP-7623: EIP-7623
ก๊าซหลายมิติ: ก๊าซหลายมิติ
ความพยายามและการแลกเปลี่ยนที่เหลืออยู่คืออะไร?
มีข้อแลกเปลี่ยนหลักสองประการสำหรับก๊าซหลายมิติ:
1. เพิ่มความซับซ้อนของโปรโตคอล: การนำ Gas หลายมิติมาใช้จะทำให้โปรโตคอลซับซ้อนมากขึ้น
2. การเพิ่มความซับซ้อนของอัลกอริธึมที่เหมาะสมที่สุดซึ่งจำเป็นในการเติมบล็อก: อัลกอริธึมที่เหมาะสมที่สุดที่จำเป็นในการนำบล็อกมาสู่ความจุก็มีความซับซ้อนเช่นกัน
ความซับซ้อนของโปรโตคอลค่อนข้างน้อยสำหรับ calldata แต่เพิ่มขึ้นสำหรับขนาดก๊าซเหล่านั้นภายใน EVM (เช่น การอ่านและเขียนที่เก็บข้อมูล) ปัญหาคือผู้ใช้ไม่เพียงแต่กำหนดขีดจำกัดของแก๊สเท่านั้น สัญญายังกำหนดขีดจำกัดเมื่อเรียกสัญญาอื่นๆ ด้วย และในปัจจุบัน วิธีเดียวที่พวกเขาสามารถกำหนดขีดจำกัดได้คือมิติเดียว
วิธีแก้ปัญหาง่ายๆ คือการทำให้ Gas หลายมิติใช้งานได้ภายใน EOF เท่านั้น เนื่องจาก EOF ไม่อนุญาตให้สัญญากำหนดขีดจำกัดของก๊าซเมื่อเรียกสัญญาอื่นๆ สัญญาที่ไม่ใช่ EOF จะต้องชำระค่าธรรมเนียมสำหรับก๊าซทุกประเภทเมื่อดำเนินการจัดเก็บ (ตัวอย่างเช่น หาก SLOAD ใช้พื้นที่ 0.03% ของขีดจำกัดก๊าซในการเข้าถึงบล็อก) ผู้ใช้ที่ไม่ใช่ EOF จะถูกเรียกเก็บเงิน 0.03% ของก๊าซในการดำเนินการด้วย ค่าธรรมเนียมจำกัด)
การวิจัยเพิ่มเติมเกี่ยวกับก๊าซหลายมิติจะช่วยให้เข้าใจข้อดีข้อเสียเหล่านี้และค้นหาสมดุลในอุดมคติ
มันโต้ตอบกับส่วนอื่น ๆ ของแผนการทำงานอย่างไร?
การใช้งาน Gas หลายมิติที่ประสบความสำเร็จสามารถลดการใช้ทรัพยากร "กรณีที่เลวร้ายที่สุด" ลงได้อย่างมาก ซึ่งช่วยลดความกดดันในการเพิ่มประสิทธิภาพการทำงานเพื่อรองรับความต้องการต่างๆ เช่น ไบนารีทรีที่ใช้แฮชของ STARKed การตั้งเป้าหมายที่ชัดเจนสำหรับการเติบโตของขนาดของรัฐจะช่วยให้นักพัฒนาของลูกค้าสามารถวางแผนและประเมินความต้องการในอนาคตได้ง่ายขึ้น
ดังที่ได้กล่าวไว้ก่อนหน้านี้ การมีอยู่ของ EOF ทำให้ง่ายต่อการใช้งานก๊าซหลายมิติรุ่นสุดขั้วมากขึ้น เนื่องจากธรรมชาติของก๊าซที่ไม่สามารถสังเกตได้
ฟังก์ชันหน่วงเวลาที่ตรวจสอบได้ (VDF)
มันแก้ปัญหาอะไรได้บ้าง?
ปัจจุบัน Ethereum ใช้การสุ่มตาม RANDAO เพื่อเลือกผู้เสนอ ซึ่งทำงานโดยกำหนดให้ผู้เสนอแต่ละคนเปิดเผยความลับที่พวกเขาตกลงไว้ล่วงหน้า และผสมความลับที่เปิดเผยแต่ละรายการเข้ากับการสุ่ม
ผู้เสนอแต่ละคนจึงมี "1 การควบคุม": พวกเขาสามารถเปลี่ยนการสุ่มได้โดยไม่แสดงขึ้นมา (มีค่าใช้จ่าย) แนวทางนี้เหมาะสมสำหรับการค้นหาผู้เสนอเพราะเป็นเรื่องยากมากที่คุณจะละทิ้งโอกาสหนึ่งและได้รับโอกาสใหม่อีกสองโอกาส แต่นี่ไม่เหมาะสำหรับแอปพลิเคชันออนไลน์ที่ต้องการการสุ่ม ตามหลักการแล้ว เราควรค้นหาแหล่งที่มาของการสุ่มที่แข็งแกร่งกว่านี้
VDF คืออะไรและทำงานอย่างไร
ฟังก์ชันหน่วงเวลาที่ตรวจสอบได้คือฟังก์ชันที่สามารถประเมินได้ตามลำดับเท่านั้น และไม่สามารถเร่งความเร็วได้ด้วยการขนาน ตัวอย่างง่ายๆ คือการแฮชซ้ำ: for i อยู่ในช่วง ( 10** 9): x = hash(x) ผลลัพธ์เอาต์พุตที่ได้รับการพิสูจน์ว่าถูกต้องโดยใช้ SNARK สามารถใช้เป็นค่าสุ่มได้
แนวคิดก็คืออินพุตจะถูกเลือกตามข้อมูลที่มีอยู่ ณ เวลา T ในขณะที่ยังไม่ทราบเอาต์พุต ณ เวลา T: เอาต์พุตจะพร้อมใช้งานในบางครั้งหลังจาก T หลังจากมีคนรันการคำนวณโดยสมบูรณ์แล้วเท่านั้น เนื่องจากใครๆ ก็สามารถดำเนินการคำนวณได้ จึงไม่มีความเป็นไปได้ที่จะระงับผลลัพธ์ ดังนั้นจึงไม่สามารถจัดการผลลัพธ์ได้
ความเสี่ยงหลักของฟังก์ชันล่าช้าที่ตรวจสอบได้คือการปรับให้เหมาะสมโดยไม่ได้ตั้งใจ: มีคนพบว่าตัวเองใช้งานฟังก์ชันเร็วกว่าที่คาดไว้ ดังนั้นจึงจัดการข้อมูลที่พวกเขาเปิดเผยในเวลา T
การปรับให้เหมาะสมที่ไม่คาดคิดสามารถเกิดขึ้นได้สองวิธี:
1. การเร่งความเร็วด้วยฮาร์ดแวร์: มีคนสร้าง ASIC ที่สามารถรันลูปการคำนวณได้เร็วกว่าฮาร์ดแวร์ที่มีอยู่
2. การทำ Parallelization โดยไม่ได้ตั้งใจ: มีคนพบวิธีเรียกใช้ฟังก์ชันได้เร็วขึ้นโดยการทำ Parallelize แม้ว่าการทำเช่นนั้นต้องใช้ทรัพยากรถึง 100 เท่าก็ตาม
งานในการสร้าง VDF ที่ประสบความสำเร็จคือการหลีกเลี่ยงปัญหาทั้งสองในขณะที่ยังคงมีประสิทธิภาพและใช้งานได้จริง (ตัวอย่างเช่น ปัญหาหนึ่งเกี่ยวกับแนวทางแบบแฮชก็คือ SNARK การพิสูจน์แฮชแบบเรียลไทม์ต้องใช้ฮาร์ดแวร์จำนวนมาก) การเร่งด้วยฮาร์ดแวร์มักได้รับการแก้ไขโดยผู้มีส่วนได้ส่วนเสียในการสร้างและแจกจ่าย VDF ASIC ที่เกือบจะเหมาะสมที่สุดด้วยตัวมันเอง
ลิงก์ไปยังงานวิจัยที่มีอยู่
เว็บไซต์วิจัย VDF: vdfresearch.org
คิดเกี่ยวกับการโจมตี VDF ใน Ethereum, 2018: คิดเกี่ยวกับการโจมตี
การโจมตี VDF MinRoot ที่เสนอ: การโจมตี MinRoot
ความพยายามและการแลกเปลี่ยนที่เหลืออยู่คืออะไร?
ในปัจจุบัน ไม่มีโครงสร้าง VDF ที่ตรงตามความต้องการของนักวิจัย Ethereum ในทุกด้านอย่างสมบูรณ์ ยังจำเป็นต้องมีการทำงานเพิ่มเติมเพื่อค้นหาฟังก์ชันดังกล่าว หากพบ ข้อดีข้อเสียหลักๆ ก็คือ จะต้องรวมหรือไม่: ข้อเสียง่ายๆ ระหว่างฟังก์ชันการทำงานและความซับซ้อนของโปรโตคอล และความเสี่ยงด้านความปลอดภัย
หากเราพิจารณาว่า VDF มีความปลอดภัย แต่ปรากฏว่าไม่ปลอดภัย ขึ้นอยู่กับวิธีการนำไปใช้ การรักษาความปลอดภัยจะลดลงตามสมมติฐานของ RANDAO (การควบคุม 1 บิตต่อผู้โจมตี) หรือแย่กว่านั้นเล็กน้อย ดังนั้น หาก VDF ล้มเหลว ก็จะไม่ทำให้โปรโตคอลเสียหาย แต่จะทำให้แอปพลิเคชันที่ต้องใช้โปรโตคอลจำนวนมากหรือคุณลักษณะใหม่ของโปรโตคอลหยุดทำงาน
มันโต้ตอบกับส่วนอื่น ๆ ของแผนการทำงานอย่างไร?
VDF เป็นส่วนประกอบที่ค่อนข้างสมบูรณ์ในตัวเองของโปรโตคอล Ethereum ซึ่งนอกเหนือจากการเพิ่มความปลอดภัยให้กับการเลือกผู้เสนอแล้ว ยังมีแอปพลิเคชันใน (i) แอปพลิเคชันออนไลน์ที่ต้องอาศัยการสุ่มและ (ii) พูลหน่วยความจำเข้ารหัส แม้ว่าจะขึ้นอยู่กับการสร้าง VDF พูลหน่วยความจำที่เข้ารหัสยังคงอาศัยการค้นพบการเข้ารหัสเพิ่มเติมที่ยังไม่เกิดขึ้น
จุดสำคัญประการหนึ่งที่ต้องจำก็คือ เมื่อคำนึงถึงความไม่แน่นอนของฮาร์ดแวร์แล้ว มี "ส่วนต่าง" อยู่บ้างระหว่างการสร้างเอาต์พุต VDF และความต้องการ ซึ่งหมายความว่าข้อมูลจะพร้อมใช้งานเมื่อหลายช่วงตึกที่ผ่านมา นี่อาจเป็นต้นทุนที่ยอมรับได้ แต่ควรพิจารณาเมื่อสรุปรถถังเดี่ยวหรือคณะกรรมการเลือกการออกแบบ
การสร้างความสับสนและลายเซ็นแบบครั้งเดียว: อนาคตอันไกลโพ้นของการเข้ารหัส
มันแก้ปัญหาอะไรได้บ้าง?
บทความที่โด่งดังที่สุดบทความหนึ่งของ Nick Szabo คือบทความปี 1997 ของเขาเรื่อง "The God Agreement" ในรายงานนี้ เขาชี้ให้เห็นว่าแอปพลิเคชันหลายฝ่ายจำนวนมากอาศัย "บุคคลที่สามที่เชื่อถือได้" ในการจัดการการโต้ตอบ ในมุมมองของเขา บทบาทของการเข้ารหัสคือการสร้างบุคคลที่สามที่เชื่อถือได้จำลองซึ่งทำงานเดียวกันโดยไม่ต้องอาศัยความไว้วางใจจากผู้เข้าร่วมคนใดโดยเฉพาะ
จนถึงขณะนี้เราสามารถบรรลุอุดมคตินี้ได้เพียงบางส่วนเท่านั้น หากเราต้องการเพียงคอมพิวเตอร์เสมือนที่โปร่งใส ซึ่งข้อมูลและการคำนวณไม่สามารถปิด ตรวจสอบ หรือแก้ไขได้ และความเป็นส่วนตัวไม่ใช่เป้าหมาย บล็อกเชนก็สามารถบรรลุเป้าหมายนี้ได้ แม้ว่าจะมีความสามารถในการปรับขนาดที่จำกัดก็ตาม
หากความเป็นส่วนตัวคือเป้าหมาย จนกระทั่งเมื่อไม่นานมานี้ เราสามารถพัฒนาโปรโตคอลเฉพาะบางประการสำหรับแอปพลิเคชันเฉพาะได้เท่านั้น: ลายเซ็นดิจิทัลสำหรับการตรวจสอบสิทธิ์ขั้นพื้นฐาน ลายเซ็นวงแหวนและลายเซ็นวงแหวนที่ลิงก์ได้สำหรับการไม่เปิดเผยตัวตนแบบดิบ การเข้ารหัสตามข้อมูลประจำตัวสำหรับการเปิดใช้งานการเข้ารหัสที่สะดวกยิ่งขึ้นภายใต้สมมติฐานเฉพาะเกี่ยวกับ ผู้ออกที่เชื่อถือได้ ลายเซ็นปลอมสำหรับเงินสดอิเล็กทรอนิกส์แบบ Chaim และอีกมากมาย แนวทางนี้ต้องใช้ความพยายามอย่างมากสำหรับแอปพลิเคชันใหม่แต่ละแอปพลิเคชัน
ในปี 2010 เราได้เห็นแนวทางที่แตกต่างและมีประสิทธิภาพยิ่งขึ้นเป็นครั้งแรก โดยอาศัยการเข้ารหัสแบบตั้งโปรแกรมได้ แทนที่จะสร้างโปรโตคอลใหม่สำหรับแอปพลิเคชันใหม่ทุกรายการ เราสามารถใช้โปรโตคอลใหม่ที่มีประสิทธิภาพ — โดยเฉพาะ ZK-SNARK — เพื่อเพิ่มการรับประกันการเข้ารหัสให้กับโปรแกรมที่กำหนดเอง
ZK-SNARK ช่วยให้ผู้ใช้สามารถพิสูจน์การอ้างสิทธิ์โดยพลการเกี่ยวกับข้อมูลที่พวกเขาถืออยู่ และการพิสูจน์ (i) นั้นง่ายต่อการตรวจสอบ และ (ii) จะไม่เปิดเผยข้อมูลใด ๆ นอกเหนือจากการอ้างสิทธิ์นั้นเอง นี่เป็นการปรับปรุงครั้งใหญ่ทั้งในด้านความเป็นส่วนตัวและความสามารถในการปรับขนาด และฉันก็เปรียบเสมือนผลกระทบของหม้อแปลงไฟฟ้าในปัญญาประดิษฐ์ คนหลายพันปีที่สมัครงานเฉพาะอย่างจู่ๆ ก็ถูกแทนที่ด้วยโซลูชันขนาดเดียวที่เหมาะกับทุกคน ซึ่งสามารถจัดการกับปัญหาที่หลากหลายอย่างไม่คาดคิดได้
อย่างไรก็ตาม ZK-SNARK เป็นเพียงตัวแรกจากสามตัวดั้งเดิมที่ทรงพลังอย่างยิ่ง โปรโตคอลเหล่านี้ทรงพลังมากจนเมื่อฉันคิดถึงมัน มันทำให้ฉันนึกถึงชุดไพ่ที่ทรงพลังมากใน Yu-Gi-Oh เกมไพ่และรายการทีวีที่ฉันเล่นตอนเป็นเด็ก: การ์ดเทพเจ้าแห่งอียิปต์
การ์ดเทพแห่งอียิปต์เป็นการ์ดที่ทรงพลังมากสามใบ ตำนานเล่าว่ากระบวนการสร้างการ์ดเหล่านี้อาจมีอันตรายถึงชีวิตได้ และพลังของพวกมันทำให้ห้ามมิให้ใช้ในการดวล ในทำนองเดียวกัน ในวิทยาการเข้ารหัสลับ เรามีชุดโปรโตคอลเทพเจ้าอียิปต์สามชุดนี้:
ZK-SNARK คืออะไร และทำงานอย่างไร
ZK-SNARK เป็นหนึ่งในสามโปรโตคอลที่เรามีอยู่แล้วซึ่งมีระดับวุฒิภาวะที่สูงกว่า ในช่วงห้าปีที่ผ่านมา การปรับปรุงความเร็วของผู้พิสูจน์อย่างมากและความเป็นมิตรของนักพัฒนาทำให้ ZK-SNARK เป็นรากฐานสำคัญของกลยุทธ์ความสามารถในการปรับขนาดและความเป็นส่วนตัวของ Ethereum แต่ ZK-SNARK มีข้อจำกัดที่สำคัญ: คุณจำเป็นต้องรู้ข้อมูลเพื่อพิสูจน์ แต่ละรัฐในแอปพลิเคชัน ZK-SNARK จะต้องมี "เจ้าของ" ที่ไม่ซ้ำกัน ซึ่งจะต้องปรากฏตัวเพื่ออนุมัติการอ่านหรือเขียนในสถานะนั้น
โปรโตคอลที่สองที่ไม่มีข้อจำกัดนี้คือการเข้ารหัสโฮโมมอร์ฟิกอย่างสมบูรณ์ (FHE) FHE ช่วยให้คุณสามารถคำนวณข้อมูลที่เข้ารหัสโดยไม่ต้องดูข้อมูล สิ่งนี้ทำให้คุณสามารถคำนวณข้อมูลของผู้ใช้ เพื่อประโยชน์ของผู้ใช้ ขณะเดียวกันก็รักษาข้อมูลและอัลกอริทึมให้เป็นส่วนตัว
นอกจากนี้ยังช่วยให้คุณสามารถขยายระบบการลงคะแนนเช่น MACI เพื่อรับประกันความปลอดภัยและความเป็นส่วนตัวที่เกือบจะสมบูรณ์แบบ FHE เคยคิดมานานแล้วว่าไม่มีประสิทธิภาพมากเกินไปสำหรับการใช้งานจริง แต่ในที่สุด บัดนี้ก็มีประสิทธิภาพมากพอที่การใช้งานจริงจะเริ่มปรากฏให้เห็น
Cursive เป็นแอปพลิเคชันที่ใช้ประโยชน์จากการคำนวณแบบสองฝ่ายและการเข้ารหัสแบบโฮโมมอร์ฟิก (FHE) เต็มรูปแบบสำหรับการค้นพบความสนใจร่วมกันที่รักษาความเป็นส่วนตัว
อย่างไรก็ตาม FHE มีข้อจำกัด: เทคโนโลยีใดๆ ก็ตามที่ใช้ FHE ยังคงต้องมีใครสักคนถือคีย์ถอดรหัส นี่อาจเป็นการตั้งค่าแบบกระจาย M-of-N และคุณยังสามารถเพิ่มการป้องกันชั้นที่สองโดยใช้ Trusted Execution Environments (TEE) ได้ แต่นี่ก็ยังคงเป็นข้อจำกัด
ถัดมาคือโปรโตคอลที่สามที่มีประสิทธิภาพมากกว่าการรวมกันของสองโปรโตคอลแรก: การทำให้สับสนอย่างแยกไม่ออก แม้ว่าเทคโนโลยีนี้ยังห่างไกลจากความสมบูรณ์ แต่ในปี 2020 เรามีโปรโตคอลที่ถูกต้องตามหลักทฤษฎีตามสมมติฐานด้านความปลอดภัยมาตรฐาน และเพิ่งเริ่มนำไปใช้งาน
การสร้างความสับสนที่แยกไม่ออกช่วยให้คุณสร้าง "โปรแกรมที่เข้ารหัส" ที่ทำการคำนวณโดยพลการในขณะที่ซ่อนรายละเอียดภายในทั้งหมดของโปรแกรม ตามตัวอย่างง่ายๆ คุณสามารถใส่คีย์ส่วนตัวของคุณลงในโปรแกรมที่สับสนซึ่งอนุญาตให้คุณใช้มันเพื่อเซ็นชื่อจำนวนเฉพาะเท่านั้น และแจกจ่ายโปรแกรมนี้ให้กับผู้อื่น พวกเขาสามารถเซ็นชื่อจำนวนเฉพาะใดๆ โดยใช้โปรแกรมนี้ แต่ไม่สามารถดึงคีย์ออกมาได้ อย่างไรก็ตาม ความสามารถของมันมีมากกว่านั้น: เมื่อรวมกับแฮชแล้ว มันสามารถนำไปใช้ในการดำเนินการเข้ารหัสลับแบบดั้งเดิมอื่น ๆ และอีกมากมาย
สิ่งเดียวที่ผู้ obfuscator ที่แยกไม่ออกไม่สามารถทำได้คือป้องกันไม่ให้ตัวเองถูกคัดลอก อย่างไรก็ตาม มีเทคโนโลยีที่ทรงพลังกว่ารออยู่ในปีก แม้ว่าจะเป็นเทคโนโลยีที่ต้องอาศัยทุกคนที่มีคอมพิวเตอร์ควอนตัม นั่นก็คือลายเซ็นควอนตัมแบบช็อตเดียว
ด้วยการรวมการสร้างความสับสนและลายเซ็นแบบครั้งเดียว เราสามารถสร้างบุคคลที่สามที่แทบไม่น่าเชื่อถือได้เกือบสมบูรณ์แบบ เป้าหมายเดียวที่ไม่สามารถทำได้ด้วยการเข้ารหัสเพียงอย่างเดียว และยังต้องใช้บล็อคเชนเพื่อให้แน่ใจว่ามีการต่อต้านการเซ็นเซอร์ เทคโนโลยีเหล่านี้ไม่เพียงแต่ทำให้ Ethereum มีความปลอดภัยมากขึ้นเท่านั้น แต่ยังช่วยให้สามารถสร้างแอปพลิเคชันที่มีประสิทธิภาพมากขึ้นได้อีกด้วย
เพื่อให้เข้าใจได้ดีขึ้นว่าวิธีดั้งเดิมเหล่านี้เพิ่มความสามารถเพิ่มเติมได้อย่างไร เราจะใช้การลงคะแนนเป็นตัวอย่างสำคัญ การลงคะแนนเสียงเป็นปัญหาที่น่าสนใจ เนื่องจากต้องเป็นไปตามคุณสมบัติด้านความปลอดภัยที่ซับซ้อนจำนวนหนึ่ง รวมถึงความสามารถในการตรวจสอบความถูกต้องและความเป็นส่วนตัวที่เข้มงวดมาก แม้ว่าโปรโตคอลการลงคะแนนที่มีคุณสมบัติความปลอดภัยที่แข็งแกร่งจะมีมานานหลายทศวรรษแล้ว แต่เราสามารถทำให้ยากขึ้นสำหรับตัวเราเองได้ และจำเป็นต้องมีการออกแบบที่สามารถจัดการโปรโตคอลการลงคะแนนโดยพลการได้ เช่น การลงคะแนนเสียงแบบกำลังสอง การระดมทุนกำลังสองแบบจำกัดแบบคู่ การระดมทุนแบบกำลังสองที่จับคู่แบบคลัสเตอร์ เป็นต้น ให้รอก่อน กล่าวอีกนัยหนึ่ง เราต้องการให้ขั้นตอน "การนับ" เป็นขั้นตอนที่กำหนดเอง
ขั้นแรก สมมติว่าเราใส่ผลการลงคะแนนแบบสาธารณะบนบล็อกเชน สิ่งนี้ทำให้เราสามารถตรวจสอบได้ต่อสาธารณะ (ใครๆ ก็สามารถยืนยันได้ว่าผลลัพธ์สุดท้ายนั้นถูกต้อง รวมถึงกฎการนับคะแนนและคุณสมบัติ) และการต่อต้านการเซ็นเซอร์ (ผู้คนไม่สามารถหยุดการลงคะแนนได้) แต่เราไม่มีความเป็นส่วนตัว
ต่อไป เราได้เพิ่ม ZK-SNARKs และตอนนี้เรามีความเป็นส่วนตัว: การลงคะแนนทุกครั้งจะไม่ระบุชื่อ ในขณะเดียวกันก็ทำให้มั่นใจว่ามีเพียงผู้ลงคะแนนที่ได้รับอนุญาตเท่านั้นที่สามารถลงคะแนนได้ และผู้ลงคะแนนแต่ละคนสามารถลงคะแนนได้เพียงครั้งเดียว
ต่อไป เราจะแนะนำกลไก MACI ซึ่งการโหวตจะถูกเข้ารหัสไปยังคีย์ถอดรหัสของเซิร์ฟเวอร์กลาง เซิร์ฟเวอร์กลางมีหน้าที่รับผิดชอบในกระบวนการนับคะแนน รวมถึงกำจัดคะแนนเสียงที่ซ้ำกัน และออกผลการพิสูจน์ ZK-SNARK สิ่งนี้ยังคงรักษาการรับประกันก่อนหน้านี้ (แม้ว่าเซิร์ฟเวอร์จะโกงก็ตาม!) แต่ยังเพิ่มการรับประกันที่ทนต่อการบีบบังคับหากเซิร์ฟเวอร์ซื่อสัตย์: ผู้ใช้ไม่สามารถพิสูจน์ได้ว่าลงคะแนนอย่างไร แม้ว่าพวกเขาต้องการก็ตาม เนื่องจากในขณะที่ผู้ใช้สามารถพิสูจน์การลงคะแนนของตนได้ แต่พวกเขาไม่สามารถพิสูจน์ได้ว่าไม่ได้ลงคะแนนเพื่อชดเชยการลงคะแนนนั้น วิธีนี้จะป้องกันการติดสินบนและการโจมตีอื่นๆ
เราดำเนินการนับคะแนนใน FHE จากนั้นทำการคำนวณการถอดรหัสเกณฑ์ N/2-of-N สิ่งนี้จะเพิ่มการรับประกันความต้านทานการบีบบังคับเป็น N/2-of-N แทนที่จะเป็น 1-of-1
เราทำให้โปรแกรมการนับคะแนนสับสนและออกแบบโปรแกรมทำให้งงงวยเพื่อให้สามารถแสดงผลลัพธ์ได้เฉพาะเมื่อได้รับอนุญาตเท่านั้น วิธีการอนุญาตอาจเป็นข้อพิสูจน์ฉันทามติของบล็อคเชน การพิสูจน์การทำงานบางประเภท หรือทั้งสองอย่างรวมกัน สิ่งนี้ทำให้การรับประกันการต่อต้านการบีบบังคับเกือบจะสมบูรณ์แบบ: ในกรณีของฉันทามติบล็อคเชน 51% ของผู้ตรวจสอบความถูกต้องจำเป็นต้องสมรู้ร่วมคิดเพื่อถอดรหัส ในกรณีของการพิสูจน์การทำงาน แม้ว่าทุกคนจะสมรู้ร่วมคิดก็ตาม คะแนนโหวตจะถูกนับใหม่ โดยมีผู้มีสิทธิเลือกตั้งกลุ่มย่อยต่างๆ ให้ลองใช้ การแยกผู้มีสิทธิเลือกตั้งแต่ละรายออกก็จะมีราคาแพงมากเช่นกัน เราอาจให้โปรแกรมทำการสุ่มเล็กน้อยในการนับคะแนนสุดท้ายเพื่อเพิ่มความยากในการแยกพฤติกรรมของผู้ลงคะแนนเสียงแต่ละคน
เราได้เพิ่มลายเซ็นแบบครั้งเดียวซึ่งเป็นแบบดั้งเดิมที่อาศัยการคำนวณควอนตัมเพื่อให้ลายเซ็นสามารถใช้ได้เพียงครั้งเดียวสำหรับข้อมูลประเภทใดประเภทหนึ่ง ทำให้การรับประกันแรงต้านสมบูรณ์แบบอย่างแท้จริง
การสร้างความสับสนอย่างแยกไม่ออกยังรองรับแอปพลิเคชันที่ทรงพลังอื่น ๆ อีกด้วย ตัวอย่างเช่น:
1. องค์กรอิสระแบบกระจายอำนาจ (DAO) การประมูลออนไลน์ และแอปพลิเคชันอื่นๆ ที่มีสถานะความลับภายในโดยพลการ
2. การตั้งค่าที่เชื่อถือได้ที่เป็นสากลอย่างแท้จริง: บางคนสามารถสร้างโปรแกรมที่สับสนซึ่งมีคีย์ และรันโปรแกรมใดๆ และจัดเตรียมเอาต์พุต โดยใส่แฮช (คีย์, โปรแกรม) เป็นอินพุตลงในโปรแกรม ด้วยโปรแกรมดังกล่าว ใครๆ ก็สามารถใส่โปรแกรม 3 ไว้ในตัวมันเองได้ โดยรวมคีย์ที่คีย์ไว้ล่วงหน้าของโปรแกรมเข้ากับคีย์ของตัวเอง จึงเป็นการขยายการตั้งค่า สามารถใช้เพื่อสร้างการตั้งค่าที่เชื่อถือได้ 1 ใน N สำหรับโปรโตคอลใดๆ
3. การยืนยัน ZK-SNARK ต้องการเพียงลายเซ็น: การดำเนินการนี้ง่ายมาก: ตั้งค่าสภาพแวดล้อมที่เชื่อถือได้และให้ผู้อื่นสร้างโปรแกรมที่สับสนซึ่งจะเซ็นข้อความด้วยคีย์เฉพาะในกรณีที่มี ZK-SNARK ที่ถูกต้อง
4. พูลหน่วยความจำที่เข้ารหัส: การเข้ารหัสธุรกรรมกลายเป็นเรื่องง่ายมาก ดังนั้นธุรกรรมจึงสามารถถอดรหัสได้เมื่อมีเหตุการณ์ออนไลน์บางอย่างเกิดขึ้นในอนาคตเท่านั้น ซึ่งอาจรวมถึง Verifiable Delay Functions (VDF) ที่ดำเนินการได้สำเร็จด้วย
ด้วยลายเซ็นแบบครั้งเดียว เราสามารถสร้างบล็อคเชนให้ต้านทานการโจมตี 51% ในการพลิกกลับขั้นสุดท้าย แม้ว่าการโจมตีด้วยการเซ็นเซอร์จะยังเป็นไปได้ก็ตาม สิ่งพื้นฐาน เช่น ลายเซ็นแบบครั้งเดียวทำให้สกุลเงินควอนตัมเป็นไปได้ แก้ปัญหาการใช้จ่ายซ้ำซ้อนโดยไม่ต้องใช้บล็อกเชน แม้ว่าแอปพลิเคชันที่ซับซ้อนอีกมากมายยังต้องใช้ลูกโซ่ก็ตาม
หากพื้นฐานเหล่านี้สามารถทำให้มีประสิทธิภาพเพียงพอ แอปพลิเคชันส่วนใหญ่ในโลกก็สามารถกระจายอำนาจได้ คอขวดหลักคือการตรวจสอบความถูกต้องของการดำเนินการ
ต่อไปนี้คือลิงก์ไปยังงานวิจัยบางส่วนที่มีอยู่:
1. พิธีสารการทำให้งงงันแยกไม่ออก (2021): พิธีสารทำให้งงงันแยกไม่ออก
2. Obfuscation สามารถช่วย Ethereum ได้อย่างไร: Obfuscation สามารถช่วย Ethereum ได้อย่างไร
3. การสร้างลายเซ็น One-Shot ที่รู้จักครั้งแรก: การสร้างลายเซ็น One-Shot ที่รู้จักครั้งแรก
4. ความพยายามในการดำเนินการของการทำให้งงงวย (1): ความพยายามในการดำเนินการของการทำให้งงงวย (1)
5. ความพยายามในการดำเนินการของการทำให้งงงวย (2): ความพยายามในการดำเนินการของการทำให้งงงวย (2)
มีงานอะไรอีกบ้างที่ต้องทำ และมีข้อแลกเปลี่ยนอะไรบ้าง?
ยังมีงานอีกมากที่ต้องทำ การ obfuscation ที่แยกไม่ออกยังไม่สมบูรณ์มากนัก และโครงสร้างของผู้สมัครดำเนินการช้าอย่างน่าประหลาดใจ (ถ้ามากกว่านั้น) เพื่อให้มีประโยชน์ในแอปพลิเคชัน เป็นที่รู้กันว่าความสับสนที่แยกไม่ออกต้องใช้เวลาแบบพหุนาม "ทางทฤษฎี" แต่ในการใช้งานจริง ความสับสนนั้นสามารถทำงานได้นานกว่าอายุของจักรวาล โปรโตคอลล่าสุดแสดงให้เห็นการปรับปรุงบางอย่างในรันไทม์ แต่โอเวอร์เฮดยังคงสูงเกินไปสำหรับการใช้งานเป็นประจำ: ผู้นำไปใช้งานรายหนึ่งประมาณรันไทม์เป็นหนึ่งปี
คอมพิวเตอร์ควอนตัมยังไม่มีอยู่จริง โครงสร้างทั้งหมดที่คุณเห็นบนอินเทอร์เน็ตเป็นต้นแบบที่ไม่สามารถทำได้มากกว่า 4 บิต หรือไม่ใช่คอมพิวเตอร์ควอนตัมที่สำคัญเลย และถึงแม้คอมพิวเตอร์เหล่านั้นอาจมีส่วนควอนตัม แต่ก็มี ไม่สามารถเรียกใช้สิ่งต่าง ๆ เช่นอัลกอริทึมของ Shor หรือการคำนวณที่มีความหมายเช่นอัลกอริทึมของ Grover มีสัญญาณล่าสุดว่าคอมพิวเตอร์ควอนตัม "ของจริง" นั้นอยู่ไม่ไกล อย่างไรก็ตาม แม้ว่าคอมพิวเตอร์ควอนตัม "ของจริง" จะวางจำหน่ายในเร็วๆ นี้ แต่คนทั่วไปที่ใช้คอมพิวเตอร์ควอนตัมบนแล็ปท็อปหรือโทรศัพท์อาจต้องรอหลายทศวรรษก่อนที่สถาบันที่ทรงอำนาจจะสามารถถอดรหัสการเข้ารหัสแบบ Elliptic Curve ได้
สำหรับการสร้างความสับสนอย่างแยกไม่ออก การแลกเปลี่ยนที่สำคัญอยู่ที่สมมติฐานด้านความปลอดภัย และมีการออกแบบที่รุนแรงกว่าที่ใช้สมมติฐานพิเศษ โดยทั่วไปการออกแบบเหล่านี้จะมีรันไทม์ที่สมจริงมากกว่า แต่บางครั้งสมมติฐานพิเศษก็มักจะล้มเหลว เมื่อเวลาผ่านไป เราอาจเข้าใจขัดแตะได้ดีขึ้น ทำให้เรากำหนดสมมติฐานที่ไม่พังง่าย อย่างไรก็ตาม เส้นทางนี้มีความเสี่ยงมากกว่า แนวทางอนุรักษ์นิยมมากขึ้นคือการยึดติดกับโปรโตคอลที่มีการรักษาความปลอดภัยลดลงจนเหลือสมมติฐาน "มาตรฐาน" แต่นี่อาจหมายความว่าอาจใช้เวลานานกว่าที่เราจะได้โปรโตคอลที่ทำงานเร็วเพียงพอ
มันโต้ตอบกับส่วนอื่น ๆ ของแผนการทำงานอย่างไร?
การเข้ารหัสที่แข็งแกร่งอย่างยิ่งสามารถปฏิวัติเกมได้ เช่น:
1. หากเราได้รับ ZK-SNARK ที่ตรวจสอบได้ง่ายเหมือนลายเซ็น เราอาจไม่ต้องการโปรโตคอลการรวมกลุ่มอีกต่อไป เราสามารถตรวจสอบได้โดยตรงทางออนไลน์
2. ลายเซ็นแบบครั้งเดียวอาจหมายถึงโปรโตคอลการพิสูจน์การเดิมพันที่ปลอดภัยยิ่งขึ้น
3. โปรโตคอลความเป็นส่วนตัวที่ซับซ้อนจำนวนมากอาจจำเป็นต้องถูกแทนที่ด้วย Ethereum Virtual Machine (EVM) ที่รักษาความเป็นส่วนตัวเท่านั้น
4. พูลหน่วยความจำที่เข้ารหัสจะนำไปใช้ได้ง่ายขึ้น
ในขั้นต้น ประโยชน์จะเกิดขึ้นที่ชั้นแอปพลิเคชัน เนื่องจาก L1 ของ Ethereum จำเป็นต้องระมัดระวังในสมมติฐานด้านความปลอดภัย อย่างไรก็ตาม การใช้เลเยอร์แอปพลิเคชันเพียงอย่างเดียวอาจทำให้เกิดการรบกวนได้ เช่นเดียวกับกรณีที่ ZK-SNARK เกิดขึ้น
IOS
Android