บทความใหม่ของ Vitaliks: อนาคตที่เป็นไปได้ของ Ethereum, The Splurge

ชื่อเรื่องเดิม: อนาคตที่เป็นไปได้ของโปรโตคอล Ethereum ตอนที่ 6: การใช้จ่ายฟุ่มเฟือย

บทความต้นฉบับโดย @VitalikButerin

คำแปลต้นฉบับ: โจวโจว, BlockBeats

ต่อไปนี้เป็นเนื้อหาต้นฉบับ (เพื่อให้อ่านและเข้าใจง่ายขึ้น เนื้อหาต้นฉบับได้รับการจัดระเบียบใหม่):

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

แผนงานปี 2023: ความเจริญรุ่งเรือง

ความเจริญรุ่งเรือง: เป้าหมายสำคัญ

นำ EVM ไปสู่สถานะสุดท้ายที่มีประสิทธิภาพสูงและเสถียร

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

เพิ่มประสิทธิภาพเศรษฐศาสตร์ค่าธรรมเนียมธุรกรรม เพิ่มความสามารถในการปรับขนาดและลดความเสี่ยง

การสำรวจขั้นสูง การเข้ารหัสลับกราฟีจะปรับปรุง Ethereum อย่างมีนัยสำคัญในระยะยาว

ในบทนี้

การปรับปรุง EVM

บัญชีบทคัดย่อ

การปรับปรุง EIP-1559

VDF (ฟังก์ชันการหน่วงเวลาที่ตรวจสอบได้)

การบดบังและลายเซ็นครั้งเดียว: อนาคตของการเข้ารหัส

การปรับปรุง EVM

ปัญหาอะไรได้รับการแก้ไข?

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

มันคืออะไรและทำงานอย่างไร?

ขั้นตอนแรกในแผนงานปรับปรุง EVM ปัจจุบันคือ EVM Object Format (EOF) ซึ่งกำหนดให้รวมอยู่ใน hard fork ครั้งต่อไป EOF คือชุด EIP ที่ระบุเวอร์ชันโค้ด EVM ใหม่พร้อมคุณสมบัติเฉพาะจำนวนหนึ่ง ที่น่าสังเกตมากที่สุด:

• การแยกระหว่างโค้ด (ซึ่งสามารถดำเนินการได้แต่ไม่สามารถอ่านจาก EVM) และข้อมูล (ซึ่งสามารถอ่านได้แต่ไม่สามารถดำเนินการได้)

• ห้ามกระโดดแบบไดนามิก อนุญาตให้กระโดดได้เฉพาะแบบคงที่เท่านั้น

• รหัส EVM ไม่สามารถสังเกตข้อมูลที่เกี่ยวข้องกับเชื้อเพลิงได้อีกต่อไป

• เพิ่มกลไกซับรูทีนที่ชัดเจนใหม่

โครงสร้างของโค้ด EOF

บูม: การปรับปรุง EVM (ต่อ)

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

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

แนวคิดใหม่คือการรวม EVM-MAX เข้ากับคุณลักษณะ Single Instruction Multiple Data (SIMD) SIMD มีมานานแล้วในฐานะแนวคิดของ Ethereum ซึ่งเสนอครั้งแรกโดย เกร็ก คอลวินส์ EIP-616 SIMD สามารถใช้เพื่อเร่งความเร็วการเข้ารหัสในรูปแบบต่างๆ ได้มากมาย รวมถึงฟังก์ชันแฮช STARK 32 บิต และการเข้ารหัสแบบแลตทิซ การผสมผสานระหว่าง EVM-MAX และ SIMD ทำให้ส่วนขยายที่เน้นประสิทธิภาพทั้งสองนี้เป็นคู่ที่เหมาะสมกัน

การออกแบบคร่าวๆ สำหรับ EIP แบบรวมจะเริ่มต้นด้วย EIP-6690 จากนั้น:

• อนุญาตให้ (i) จำนวนคี่ใดๆ หรือ (ii) กำลัง 2 ใดๆ ขึ้นไปจนถึง 2768 เป็นโมดูลัส

• สำหรับแต่ละโอปโค้ด EVM-MAX (การบวก การลบ การคูณ) ให้เพิ่มเวอร์ชันที่ใช้ 7 ตัวทันทีแทน 3 x, y, z: x_start, x_skip, y_start, y_skip, z_start, z_skip, count ในโค้ด Python โอปโค้ดเหล่านี้ทำงานดังนี้:

• สำหรับ i ในช่วง(จำนวน):
  mem[z_start + z_skip * count] = op(
  mem[x_start + x_skip * นับ],
  mem[y_start + y_skip * จำนวน]
  )

ในการใช้งานจริงจะมีการจัดการแบบคู่ขนานกันไป

• อาจเพิ่ม XOR, AND, OR, NOT และ SHIFT (ทั้งแบบวนซ้ำและไม่วนซ้ำ) อย่างน้อยสำหรับโมดูโลของกำลัง 2 นอกจากนี้ยังเพิ่ม ISZERO (การผลักเอาต์พุตไปที่สแต็กหลักของ EVM) ซึ่งจะมีประสิทธิภาพเพียงพอที่จะใช้การเข้ารหัสเส้นโค้งวงรี การเข้ารหัสโดเมนขนาดเล็ก (เช่น Poseidon, Circle STARKs) ฟังก์ชันแฮชแบบดั้งเดิม (เช่น SHA 256, KECCAK, BLAKE) และการเข้ารหัสแบบแลตทิซ การอัพเกรด EVM อื่นๆ ก็เป็นไปได้เช่นกัน แต่ได้รับความสนใจน้อยกว่ามาก

ลิงค์ไปยังงานวิจัยที่มีอยู่

อีโอเอฟ: https://evmobjectformat.org/

อีวีเอ็ม-แม็กซ์: https://eips.ethereum.org/EIPS/eip-6690

ซิมดี: https://eips.ethereum.org/EIPS/eip-616

งานที่เหลือและการแลกเปลี่ยน

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

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

งานสำคัญที่ต้องทำคือการนำฟังก์ชันเช่น EVM-MAX บวกกับ SIMD มาใช้ และประเมินการใช้ก๊าซของการดำเนินการเข้ารหัสต่างๆ

มันจะโต้ตอบกับแผนงานส่วนที่เหลืออย่างไร?

L1 จะปรับ EVM เพื่อให้ L2 สามารถปรับได้ง่ายขึ้น หากไม่ได้ปรับทั้งสองพร้อมกัน อาจทำให้เกิดความไม่เข้ากันและเกิดผลเสีย นอกจากนี้ EVM-MAX และ SIMD ยังช่วยลดต้นทุนก๊าซของระบบพิสูจน์หลายๆ ระบบ ทำให้ L2 มีประสิทธิภาพมากขึ้น นอกจากนี้ยังทำให้การแทนที่การคอมไพล์ล่วงหน้าด้วยโค้ด EVM ที่สามารถทำงานเดียวกันได้ง่ายขึ้น โดยอาจไม่ส่งผลกระทบต่อประสิทธิภาพมากนัก

บัญชีบทคัดย่อ

ปัญหาอะไรได้รับการแก้ไข?

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

• การเปลี่ยนไปใช้การเข้ารหัสที่ทนทานต่อควอนตัม

• หมุนกุญแจเก่า (แบบกว้างๆ ถือเป็นแนวทางปฏิบัติด้านความปลอดภัยที่แนะนำ )

• กระเป๋าสตางค์หลายลายเซ็นและ กระเป๋าเงินกู้คืนทางสังคม

• ใช้คีย์หนึ่งอันสำหรับการดำเนินการค่าต่ำและอีกคีย์หนึ่ง (หรือชุดคีย์) สำหรับการดำเนินการค่าสูง

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

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

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

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

การทำงานเริ่มต้นด้วย EIP-3074 และในที่สุดก็ได้ก่อตั้ง EIP-7702 ขึ้น โดย EIP-7702 นำเสนอฟีเจอร์ที่สะดวกในการแยกบัญชีให้กับผู้ใช้ทุกคน รวมถึง EOA (บัญชีที่เป็นเจ้าของภายนอก เช่น บัญชีที่ควบคุมโดยลายเซ็น ECDSA) ในปัจจุบัน

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

มันคืออะไรและทำงานอย่างไร?

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

ความท้าทายหลักทั่วไปคือปัญหาความล้มเหลวหลายครั้ง:

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

หลังจากทำงานหนักมาหลายปีเพื่อขยายฟังก์ชันการทำงานพร้อมจำกัดความเสี่ยงจากการปฏิเสธการให้บริการ (DoS) ในที่สุดก็ได้โซลูชันสำหรับการแยกบัญชีที่เหมาะสมที่สุด: ERC-4337

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

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

เหตุผลหลักสองประการมีดังนี้:

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 ที่นิยมใช้มากที่สุดในการเขียนการแยกบัญชีโปรโตคอลคือ อีไอพี-7701 ซึ่งใช้การแยกส่วนบัญชีบน EOF บัญชีสามารถมีส่วนรหัสแยกต่างหากสำหรับการตรวจยืนยัน หากบัญชีกำหนดส่วนรหัสนี้ รหัสจะถูกดำเนินการในขั้นตอนการตรวจยืนยันธุรกรรมจากบัญชี

สิ่งที่สวยงามของแนวทางนี้คือมันแสดงให้เห็นมุมมองที่เทียบเท่ากันสองมุมของการแยกย่อยบัญชีท้องถิ่นได้อย่างชัดเจน:

1. ทำให้ EIP-4337 เป็นส่วนหนึ่งของโปรโตคอล

2. EOA ประเภทใหม่ที่อัลกอริทึมลายเซ็นคือการเรียกใช้โค้ด EVM

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

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

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

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

มันจะโต้ตอบกับแผนงานส่วนที่เหลืออย่างไร?

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

การปรับปรุง EIP-1559

มันช่วยแก้ปัญหาอะไรได้บ้าง?

EIP-1559 ได้รับการเปิดใช้งานบน Ethereum ในปี 2021 ซึ่งช่วยปรับปรุงเวลาการรวมบล็อกโดยเฉลี่ยได้อย่างมีนัยสำคัญ

เวลาที่รอคอย

อย่างไรก็ตามปัจจุบัน การดำเนินการตาม EIP-1559 ไม่สมบูรณ์แบบในหลายๆ ด้าน:

1. สูตรนี้มีข้อบกพร่องเล็กน้อย คือ ไม่ได้กำหนดเป้าหมายที่ 50% ของบล็อก แต่กำหนดเป้าหมายที่ 50-53% ของบล็อกเต็ม ขึ้นอยู่กับความแปรปรวน (ซึ่งเกี่ยวข้องกับสิ่งที่นักคณิตศาสตร์เรียกว่า "ความไม่เท่าเทียมของค่าเฉลี่ยเลขคณิต-เรขาคณิต")

2. ปรับตัวไม่รวดเร็วพอในสถานการณ์ที่รุนแรง

สูตรสำหรับหยดสีในภายหลัง (EIP-4844) ได้รับการออกแบบมาโดยเฉพาะเพื่อแก้ไขปัญหาแรก และโดยรวมแล้วยังสะอาดกว่าด้วย อย่างไรก็ตาม ทั้ง EIP-1559 และ EIP-4844 เองไม่ได้พยายามแก้ไขปัญหาที่สอง ดังนั้น สถานะปัจจุบันจึงเป็นจุดกึ่งกลางที่สับสนซึ่งเกี่ยวข้องกับกลไกที่แตกต่างกันสองแบบ และมีข้อโต้แย้งว่าทั้งสองจะต้องได้รับการปรับปรุงในอนาคต

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

ก๊าซหลายมิติคืออะไร และทำงานอย่างไร?

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

ขณะนี้ เรามีแก๊สหลายมิติสำหรับการดำเนินการและบล็อกข้อมูล โดยหลักการแล้ว เราสามารถขยายสิ่งนี้ไปยังมิติอื่นๆ เพิ่มเติมได้ เช่น ข้อมูลการโทร (ข้อมูลธุรกรรม) การอ่าน/เขียนสถานะ และการขยายขนาดสถานะ

อีไอพี-7706 แนะนำมิติใหม่ของก๊าซโดยเฉพาะสำหรับข้อมูลการโทร นอกจากนี้ยังทำให้กลไกของก๊าซหลายมิติง่ายขึ้นด้วยการรวมก๊าซสามประเภทเข้าเป็นกรอบงานเดียว (แบบ EIP-4844) ซึ่งจะช่วยแก้ไขข้อบกพร่องทางคณิตศาสตร์ของ EIP-1559 ได้ด้วย อีไอพี-7623 เป็นโซลูชันที่แม่นยำยิ่งขึ้นสำหรับปัญหาทรัพยากรในกรณีเฉลี่ยและกรณีที่เลวร้ายที่สุด โดยมีขีดจำกัดที่เข้มงวดยิ่งขึ้นสำหรับข้อมูลการเรียกสูงสุดโดยไม่ต้องแนะนำมิติใหม่ทั้งหมด

ทิศทางการวิจัยเพิ่มเติมคือการแก้ปัญหาอัตราการอัปเดตและค้นหาอัลกอริธึมการคำนวณค่าธรรมเนียมพื้นฐานที่เร็วขึ้นในขณะที่รักษาค่าคงที่ที่สำคัญที่นำมาใช้โดยกลไก EIP-4844 (กล่าวคือ ในระยะยาว การใช้งานโดยเฉลี่ยจะใกล้เคียงกับค่าเป้าหมาย)

ลิงค์ไปยังงานวิจัยที่มีอยู่

คำถามที่พบบ่อย EIP-1559: คำถามที่พบบ่อย EIP-1559

เชิงประจักษ์ การวิเคราะห์ของ EIP-1559

เสนอ การปรับปรุงเพื่อให้สามารถปรับเปลี่ยนได้อย่างรวดเร็ว:

คำถามที่พบบ่อย EIP-4844 เกี่ยวกับกลไกค่าธรรมเนียมพื้นฐาน: คำถามที่พบบ่อย EIP-4844

EIP-7706: อีไอพี-7706

EIP-7623: อีไอพี-7623

ก๊าซหลายมิติ: ก๊าซหลายมิติ

ภารกิจและการแลกเปลี่ยนที่เหลือคืออะไร?

มีการแลกเปลี่ยนหลักสองประการสำหรับแก๊สหลายมิติ:

1. เพิ่มความซับซ้อนของโปรโตคอล: การนำแก๊สหลายมิติมาใช้จะทำให้โปรโตคอลมีความซับซ้อนมากขึ้น

2. ความซับซ้อนที่เพิ่มขึ้นของอัลกอริทึมที่เหมาะสมที่สุดที่จำเป็นในการเติมบล็อก: อัลกอริทึมที่เหมาะสมที่สุดในการเติมบล็อกให้เต็มความจุก็จะซับซ้อนมากขึ้นด้วยเช่นกัน

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

วิธีแก้ปัญหาง่ายๆ คือการทำให้แก๊สหลายมิติมีให้ใช้ได้เฉพาะภายใน EOF เท่านั้น เนื่องจาก EOF ไม่อนุญาตให้สัญญาตั้งขีดจำกัดแก๊สเมื่อเรียกใช้สัญญาอื่น สัญญาที่ไม่ใช่ EOF จะต้องชำระเงินสำหรับแก๊สทุกประเภทเมื่อดำเนินการจัดเก็บ (ตัวอย่างเช่น หาก SLOAD ใช้ 0.03% ของขีดจำกัดแก๊สการเข้าถึงที่จัดเก็บบล็อก ผู้ใช้ที่ไม่ใช่ EOF จะถูกเรียกเก็บค่าธรรมเนียม 0.03% ของขีดจำกัดแก๊สในการดำเนินการด้วย)

การวิจัยเพิ่มเติมเกี่ยวกับก๊าซหลายมิติจะช่วยให้เข้าใจการแลกเปลี่ยนเหล่านี้และค้นหาสมดุลที่เหมาะสม

มันจะโต้ตอบกับแผนงานส่วนที่เหลืออย่างไร?

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

ดังที่กล่าวไว้ก่อนหน้านี้ การมีอยู่ของ EOF ทำให้สามารถใช้งานแก๊สหลายมิติในเวอร์ชันที่รุนแรงมากขึ้นได้ง่ายดายขึ้นเนื่องจากลักษณะที่ไม่อาจสังเกตได้

ฟังก์ชั่นการหน่วงเวลาที่ตรวจสอบได้ (VDF)

มันช่วยแก้ปัญหาอะไรได้บ้าง?

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

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

VDF คืออะไรและทำงานอย่างไร?

ฟังก์ชันหน่วงเวลาที่ตรวจสอบได้คือฟังก์ชันที่สามารถคำนวณได้ตามลำดับเท่านั้น และไม่สามารถเร่งความเร็วได้ด้วยการประมวลผลแบบขนาน ตัวอย่างง่ายๆ คือ การแฮชซ้ำๆ: for i in range(10**9): x = hash(x) ผลลัพธ์ได้รับการพิสูจน์ว่าถูกต้องโดยใช้ SNARK และสามารถใช้เป็นค่าสุ่มได้

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

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

การเพิ่มประสิทธิภาพโดยไม่ได้ตั้งใจสามารถเกิดขึ้นได้สองวิธี:

1. การเร่งด้วยฮาร์ดแวร์: มีคนสร้าง ASIC ที่ทำให้รอบการคำนวณเร็วกว่าฮาร์ดแวร์ที่มีอยู่

2. การทำงานแบบขนานโดยไม่ได้ตั้งใจ: มีคนพบวิธีที่จะเรียกใช้ฟังก์ชันได้เร็วขึ้นโดยการทำงานแบบขนาน ถึงแม้ว่าจะต้องใช้ทรัพยากรมากขึ้นถึง 100 เท่าก็ตาม

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

ลิงค์ไปยังงานวิจัยที่มีอยู่

เว็บไซต์วิจัย VDF: วีดีเฟรชอาร์จีโอ

การคิด เกี่ยวกับการโจมตี VDF ใน Ethereum ปี 2018:

การโจมตี MinRoot

ภารกิจและการแลกเปลี่ยนที่เหลือคืออะไร?

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

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

มันจะโต้ตอบกับแผนงานส่วนที่เหลืออย่างไร?

VDF เป็นส่วนประกอบที่ค่อนข้างเป็นอิสระของโปรโตคอล Ethereum ซึ่งนอกเหนือจากการเพิ่มความปลอดภัยในการเลือกผู้เสนอแล้ว ยังมีแอปพลิเคชันใน (i) แอปพลิเคชันแบบออนเชนที่อาศัยความสุ่ม และ (ii) mempool แบบเข้ารหัส แม้ว่าการสร้าง mempool แบบเข้ารหัสที่อิงจาก VDF จะยังคงต้องอาศัยการค้นพบทางเข้ารหัสเพิ่มเติมที่ยังไม่ได้เกิดขึ้นก็ตาม

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

การบดบังและลายเซ็นครั้งเดียว: อนาคตอันไกลโพ้นของการเข้ารหัส

มันช่วยแก้ปัญหาอะไรได้บ้าง?

บทความที่มีชื่อเสียงที่สุดบทความหนึ่งของ Nick Szabo คือบทความในปี 1997 เกี่ยวกับ “God Protocol” ในบทความนี้ เขาได้ตั้งข้อสังเกตว่าแอปพลิเคชันหลายฝ่ายจำนวนมากต้องอาศัย “บุคคลที่สามที่เชื่อถือได้” เพื่อจัดการการโต้ตอบ ในมุมมองของเขา บทบาทของการเข้ารหัสคือการสร้างบุคคลที่สามที่เชื่อถือได้จำลองที่ทำหน้าที่เดียวกันโดยไม่จำเป็นต้องไว้วางใจผู้เข้าร่วมรายใดรายหนึ่งโดยเฉพาะ

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

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

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

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

อย่างไรก็ตาม ZK-SNARK เป็นเพียงการ์ดพื้นฐานสามใบแรกจากทั้งหมดสามใบที่มีพลังมหาศาล โปรโตคอลเหล่านี้มีพลังมากจนเมื่อนึกถึงพวกมัน พวกมันก็ทำให้ฉันนึกถึงการ์ดชุดหนึ่งที่มีพลังมหาศาลใน Yu-Gi-Oh! ซึ่งเป็นเกมการ์ดและรายการทีวีที่ฉันเคยเล่นตอนเป็นเด็ก นั่นก็คือการ์ด Egyptian Gods

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

ZK-SNARKs คืออะไรและทำงานอย่างไร?

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

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

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

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

อย่างไรก็ตาม FHE ก็มีข้อจำกัดเช่นกัน: เทคโนโลยีใดๆ ก็ตามที่ใช้ FHE ยังคงต้องมีใครสักคนถือคีย์การถอดรหัส ซึ่งอาจเป็นการตั้งค่าแบบกระจาย M-of-N และคุณยังสามารถใช้ Trusted Execution Environments (TEEs) เพื่อเพิ่มชั้นการป้องกันที่สองได้ แต่ยังคงเป็นข้อจำกัดอยู่

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

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

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

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

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

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

จากนั้นเราจึงเพิ่ม ZK-SNARKs และตอนนี้เราก็มีความเป็นส่วนตัว: การลงคะแนนเสียงทุกครั้งจะเป็นแบบไม่เปิดเผยตัวตน ในขณะที่มั่นใจว่ามีเพียงผู้ลงคะแนนเสียงที่ได้รับอนุญาตเท่านั้นที่สามารถลงคะแนนเสียงได้ และผู้ลงคะแนนเสียงแต่ละคนสามารถลงคะแนนเสียงได้เพียงครั้งเดียวเท่านั้น

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

เราเรียกใช้การนับคะแนนใน FHE จากนั้นจึงดำเนินการคำนวณการถอดรหัสเกณฑ์ N/2-of-N วิธีนี้ช่วยปรับปรุงการรับประกันการต่อต้านการบังคับเป็น N/2-of-N แทนที่จะเป็น 1-of-1

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

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

การบดบังที่แยกแยะไม่ออกยังรองรับแอปพลิเคชันอันทรงพลังอื่น ๆ ด้วย ตัวอย่างเช่น:

1. องค์กรอิสระแบบกระจายอำนาจ (DAO) การประมูลแบบบนเครือข่าย และแอปพลิเคชันอื่น ๆ ที่มีสถานะลับภายในที่กำหนดเอง

2. การตั้งค่าที่เชื่อถือได้อย่างแท้จริง: ใครๆ ก็สามารถสร้างโปรแกรมที่ซ่อนเร้นซึ่งประกอบไปด้วยคีย์ และเรียกใช้โปรแกรมใดๆ ก็ได้ และให้ผลลัพธ์ โดยใส่ hash(key, program) เป็นอินพุตในโปรแกรม เมื่อมีโปรแกรมดังกล่าวแล้ว ใครๆ ก็สามารถใส่โปรแกรม 3 ลงในตัวเองได้ โดยรวมพรีคีย์ของโปรแกรมและคีย์ของตัวเองเข้าด้วยกัน จึงทำให้การตั้งค่าขยายออกไปได้ ซึ่งสามารถใช้เพื่อสร้างการตั้งค่าที่เชื่อถือได้ 1 ใน N สำหรับโปรโตคอลใดๆ ก็ได้

3. การตรวจสอบ ZK-SNARK ต้องใช้ลายเซ็นเพียงอันเดียว การดำเนินการนี้ง่ายมาก: ตั้งค่าสภาพแวดล้อมที่เชื่อถือได้และให้ใครบางคนสร้างตัวสร้างความสับสนที่ลงนามข้อความด้วยคีย์เฉพาะในกรณีที่มี ZK-SNARK ที่ถูกต้องเท่านั้น

4. พูลหน่วยความจำที่เข้ารหัส: การเข้ารหัสธุรกรรมนั้นง่ายมาก ดังนั้นจึงสามารถถอดรหัสได้เฉพาะในกรณีที่เกิดเหตุการณ์บนเชนในอนาคตเท่านั้น ซึ่งอาจรวมถึงฟังก์ชัน Verifiable Delay (VDF) ที่ดำเนินการสำเร็จด้วย

ด้วยลายเซ็นครั้งเดียว เราสามารถสร้างบล็อคเชนให้ปลอดภัยจากการโจมตี 51% ด้วยการย้อนกลับความแน่นอน แม้ว่าการโจมตีด้วยการเซ็นเซอร์ยังคงเป็นไปได้ก็ตาม พื้นฐานเช่นลายเซ็นครั้งเดียวทำให้เงินควอนตัมเป็นไปได้ โดยแก้ปัญหาการใช้จ่ายซ้ำโดยไม่ต้องใช้บล็อคเชน แม้ว่าแอปพลิเคชันที่ซับซ้อนกว่านั้นจำนวนมากยังคงต้องใช้เชน

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

ต่อไปนี้เป็นลิงก์ไปยังงานวิจัยที่มีอยู่:

1. ความไม่แยกแยะ การบดบัง (2021):

2. Obfuscation ช่วย Ethereum ได้อย่างไร

3. การสร้างลายเซ็นแบบช็อตเดียวครั้งแรกที่รู้จัก

4. ความพยายามในการดำเนินการบดบังข้อมูล (1)

5. ความพยายามในการดำเนินการบดบังข้อมูล (2)

งานที่เหลือจะเหลืออะไรให้ทำและมีการแลกเปลี่ยนอะไรเกิดขึ้นบ้าง?

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

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

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

มันจะโต้ตอบกับแผนงานส่วนที่เหลืออย่างไร?

การเข้ารหัสที่แข็งแกร่งเป็นพิเศษอาจปฏิวัติเกมได้ เช่น:

1. หากเราสามารถทำให้ ZK-SNARK ง่ายต่อการตรวจสอบเช่นเดียวกับการลงนาม เราก็อาจไม่จำเป็นต้องมีโปรโตคอลการรวมข้อมูลอีกต่อไป เราสามารถทำการตรวจสอบโดยตรงบนเชนได้

2. ลายเซ็นครั้งเดียวอาจหมายถึงโปรโตคอลการพิสูจน์การถือครองที่ปลอดภัยยิ่งขึ้น

3. โปรโตคอลความเป็นส่วนตัวที่ซับซ้อนหลายรายการอาจต้องใช้เพียง Ethereum Virtual Machine (EVM) ที่รักษาความเป็นส่วนตัวมาแทนที่เท่านั้น

4. การใช้งานพูลหน่วยความจำแบบเข้ารหัสทำได้ง่ายขึ้น

ในขั้นต้น ประโยชน์จะปรากฏที่ชั้นแอปพลิเคชัน เนื่องจาก L1 ของ Ethereum จำเป็นต้องมีการคาดเดาความปลอดภัยอย่างรัดกุม อย่างไรก็ตาม การใช้งานที่ชั้นแอปพลิเคชันเพียงอย่างเดียวอาจก่อให้เกิดความวุ่นวายได้ เช่นเดียวกับกรณีการถือกำเนิดของ ZK-SNARK

ลิงค์เดิม

บทความนี้มีที่มาจากอินเทอร์เน็ต: บทความใหม่ของ Vitaliks: อนาคตที่เป็นไปได้ของ Ethereum, The Splurge

ที่เกี่ยวข้อง: Grayscale คัดเลือกโทเค็น 35 รายการอย่างระมัดระวัง: FDV ขั้นต่ำ 300 ล้านเหรียญสหรัฐ เหมาะสำหรับนักลงทุนรายใหญ่มากกว่า

ต้นฉบับ | Odaily Planet Daily ( @OdailyChina ) ผู้เขียน | Fu Howe ( @vincent 31515173 ) Grayscales เป็นหนึ่งในสะพานเชื่อมระหว่าง Web3 และการเงินกระแสหลัก โดยได้รับความสนใจอย่างมากจากความคิดริเริ่มของ Grayscales ในอุตสาหกรรมคริปโต ตั้งแต่ผลิตภัณฑ์ความน่าเชื่อถือเบื้องต้นของ Bitcoin, Ethereum และโทเค็นชื่อดังมากมาย ไปจนถึงการเปิดตัว Bitcoin spot ETF และ Ethereum spot ETF ในปีนี้ การมีส่วนสนับสนุนของ Grayscales ต่ออุตสาหกรรมคริปโตเป็นสิ่งที่ชัดเจนสำหรับทุกคน เมื่อไม่นานมานี้ Grayscale ได้ระบุสินทรัพย์คริปโต 35 รายการที่กำลังพิจารณาเพิ่มในผลิตภัณฑ์ในอนาคต เพื่อจุดประสงค์นี้ Odaily Planet Daily ได้จัดประเภทสกุลเงิน 35 รายการตามแทร็กก่อน จากนั้นจึงจัดเรียงตามมูลค่าตลาดของแต่ละสกุลเงิน และแบ่งปันแนวโน้มราคาในช่วงสองปีที่ผ่านมากับผู้อ่านผ่านไดอะแกรม มีทั้งหมด…