เคล็ดลับการอ่าน

· ก่อนที่จะอ่านบทความนี้ คุณต้องมีความเข้าใจพื้นฐานเกี่ยวกับ MEV

· เข้าใจเรื่องการทำธุรกรรม Ethereum และเข้าใจว่าธุรกรรมประกอบด้วยสิ่งที่อยู่ข้างในและวิธีที่มันถูกเพิ่มเข้าไปในบล็อก

· ทราบเกี่ยวกับ Merkle Tree และบทบาทของพิสูจน์ที่ไม่ต้องบอกให้รู้

· คลิกเพื่ออ่าน: MEV (5): ระบบนิยม MEV ที่เป็นธรรมของการทำธุรกรรม (ส่วนที่ 1)

บทความก่อนหน้านี้ได้แนะนำ (1) การออกแบบ Flashbot SGX Builder ซึ่งเพิ่มความยุติธรรมของ Block Builder ผ่านฮาร์ดแวร์ที่น่าเชื่อถือ และ (2) การออกแบบ Chainlink FSS ซึ่งป้องกัน MEV โดยการทำให้บทบาทในการจัดลำดับธุรกรรมกระจาย

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

Mempools ที่เข้ารหัสลับ

Two goals: การป้องกัน MEV และความต้านทานการเซ็นเซอร์ชั่น

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

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

เคล็ดลับในการอ่าน: การเข้ารหัสเพียงอย่างเดียวไม่สามารถให้ความมั่นคงในการต้านการเซ็นเซอร์ เพราะ Proposer ที่ต้องการเซ็นเซอร์ยังคงสามารถปฏิเสธการยอมรับธุรกรรมที่ถูกเข้ารหัสได้ ดังนั้นการเข้ารหัสเพียงเพิ่มค่าใช้จ่ายของการเซ็นเซอร์ (Proposer ยอมแพ้ค่าธรรมเนียมสำหรับธุรกรรมที่ถูกเข้ารหัสทั้งหมด) หากต้องการความคุ้มครองต่อการเซ็นเซอร์ที่ดีกว่าคุณต้องใช้ Inclusion List เช่น PBS

Ensure transactions can be decrypted (การถอดรหัสทรานแซคชันได้ (การถอดรหัสที่รับรอง))

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

มีวิธีบางวิธีที่ทำให้การทำธุรกรรมสามารถถอดรหัสได้:

1. ความเชื่อมั่นสุทธิ (In-flight)

2. ฮาร์ดแวร์ที่เชื่อถือได้, Enclave

3. การเข้ารหัส / ถอดรหัสค่าเข้ารหัส

4. การเข้ารหัส/ถอดรหัสล่าช้า

5. การเข้ารหัส/ถอดรหัสพยาน

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

Image source:https://www.youtube.com/watch?v=XRM0CpGY3sw

Commit-reveal

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

คำแนะนำในการอ่าน: วิธีการที่มีการมุ่งมั่นอาจเหมือนกับผู้เสนอใน PBS ที่สัญญาว่ามันจะถูกรวมอยู่ในบล็อก Builder ผ่านลายเซ็น นั่นคือการมุ่งมั่นที่รับประกัน หากผู้เสนอละเมิดสัญญา จะถูกลงโทษ

△ ผู้เสนอมีสัญญาที่จะได้รับความมุ่งมั่นของธุรกรรมของ Alice

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

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

△ อลิซไม่จำเป็นต้องเปิดเผยธุรกรรมของเธอ

1. ความเชื่อสมบูรณ์ (บนเครื่องบิน)

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

เคล็ดลับในการอ่าน: บทบาทที่ถูกจัดกลุ่มไว้ในที่นี้อาจเป็นตัวอย่างเช่น Builder ของ PBS, Proposer, หรือ Sequencer/Operator ของ Rollup

2.ฮาร์ดแวร์ที่น่าเชื่อถือ, Enclave

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

3.การเข้ารหัส/ถอดรหัสขั้นต่ำ

Chainlink FSS ใช้การเข้ารหัสและถอดรหัสที่มีเกณฑ์สำหรับการจัดการคีย์แบ่งกลุ่มโดยผู้จัดการของคีย์เกณฑ์ใน Chainlink คือ Oracles ของ Chainlink ในขณะที่ใน Encrypted Mempools ผู้จัดการ (ที่เรียกว่า Keypers) อาจเป็น Validators ของ L1 หรือ L2 (ในกรณีที่ L2 มี Validator แบบกระจายด้วย)

การเข้ารหัส/ถอดรหัสขอบเขตมีข้อเสียหายหลายประการ:

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

เนื่องจากการเข้ารหัสและถอดรหัสแบบโครงสร้างพรีเซ็ตต้องการการเปลี่ยนแปลงมากมาย L2 เหมาะสำหรับวิธีการนี้มากกว่า L1

บทความนี้นำเสนอการออกแบบและข้อคิดพิจารณาสำหรับการปฏิบัติใน L1 โครงการที่กำลังทดสอบการออกแบบนี้สามารถอ้างอิงไปยัง Shutter Network สำหรับข้อมูลเพิ่มเติม โปรดตรวจสอบที่:https://ethresear.ch/t/shutterized-beacon-chain/12249

4.การเข้ารหัส/ถอดรหัสการหน่วงเวลา

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

แนวคิดของการเข้ารหัสหน่วงเหมือนกับฟังก์ชันการเข้ารหัสที่สามารถยืนยันได้ (VDF) ซึ่งทั้งสองเป็นสมาชิกในวงศ์ของ Cryptography ที่ปล่อยเวลา

VDF ช่วยให้เราสามารถยืนยัน F(x) อย่างรวดเร็ว: ผลลัพธ์ของ "การคำนวณลำดับที่ใช้เวลานาน" นี้ คล้ายกับ Proof of Work (PoW) แต่การคำนวณของ VDF เป็นกระบวนการลำดับ ต่างจาก PoW ซึ่งสามารถเร่งความเร็วผ่านการคำนวณแบบขนาน. ผู้ถอดรหัสของ VDF สามารถทำการคำนวณซ้ำๆ ตามขั้นตอนไปเรื่อยๆ เท่านั้น

△ ด้วย VDF คุณสามารถยืนยันผลลัพธ์ของการคำนวณที่ใช้เวลา 10 วินาทีในที่สุด ในเวลาเพียง 0.01 วินาที และฉันไม่สามารถแบ่งการคำนวณของฉันตามขนาดได้ ภาพของฉัน:https://techtelegraph.co.uk/verifiable-delay-functions-on-bitcoin

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

ในปัจจุบัน Ethereum Foundation และ Protocol Labs ได้เริ่มร่วมมือกันในการวิจัยชิป VDF ASIC โดยหวังว่าจะสามารถส่งออกฮาร์ดแวร์คอมพิวเตอร์ที่ทันสมัยที่สุดไปยังตลาด เพื่อให้ไม่มีใครสามารถมีประโยชน์จากความสามารถของฮาร์ดแวร์ที่แตกต่างกันและถอดรหัสล่วงหน้าได้ หากต้องการเรียนรู้เพิ่มเติม โปรดตรวจสอบที่: https://filecoin.io/blog/posts/collaboration-with-the-ethereum-foundation-on-vdfs/

เคล็ดลับการอ่าน: VDF ยังสามารถใช้เพื่อเพิ่มความไม่สามารถถูกจัดการของตัวเลขสุ่มของ Ethereum อีกด้วย

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

5.การเข้ารหัส/ถอดรหัสพยาน

ลองนึกภาพว่าข้อความเข้ารหัสไม่ได้ถูกถอดรหัสโดยคีย์หรือการคํานวณตามลําดับ แต่สามารถถอดรหัสได้เมื่อตรงตาม "เงื่อนไข" บางอย่างเช่น "เมื่อสมการนี้ได้รับการแก้ไข" หรือ "เมื่อสมการนี้ได้รับการแก้ไข" เมื่อข้อความเข้ารหัสรวมอยู่ในบล็อกข้อความเข้ารหัสสามารถถอดรหัสและอื่น ๆ

เคล็ดลับในการอ่าน: “ทราบความลับในการถอดรหัสข้อความ” หรือ “ทราบผลลัพธ์ของการคำนวณต่อเนื่อง” นั้นจริง ๆ แล้วเป็นเงื่อนไข

ด้วยการเข้ารหัสพยานเราไม่เพียง แต่สามารถบรรลุผลของการเข้ารหัสเกณฑ์และการเข้ารหัสที่ล่าช้า แต่เรายังสามารถรวมวิธีการถอดรหัสทั้งสองนี้ ตัวอย่างเช่นเราสามารถตั้งค่าเงื่อนไขเป็น "เงื่อนไขที่ 1: 'กลุ่ม Keypers ตกลงที่จะถอดรหัสข้อความเข้ารหัสนี้' หรือเงื่อนไขที่ 2: 'หลังจากห้านาที'": หาก Keypers ทั้งหมดออนไลน์เราสามารถปฏิบัติตามเงื่อนไข 1 ได้อย่างรวดเร็วเพื่อถอดรหัสข้อความเข้ารหัส อย่างไรก็ตามหากมี Keypers ออนไลน์ไม่เพียงพออย่างน้อยเราก็สามารถมั่นใจได้ว่าเราสามารถปฏิบัติตามเงื่อนไขที่ 2 และถอดรหัสได้โดยพิสูจน์ผ่าน VDF ว่า "ผ่านไปห้านาทีแล้ว"

△ พอเห็นว่ามี Keypers พอกันสามารถถูกถอดรหัสออนไลน์ (ข้างบน) หรือหลังจากเวลาพอ (ด้านล่าง)

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

△ ความสุกของเทคโนโลยีการเข้ารหัสและถอดรหัสที่แตกต่างกัน การเข้ารหัสและถอดรหัสของพยาน (พยาน) ยังไม่สุกพอ. ที่มาของภาพ:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_591

จัดการและดําเนินการกับข้อความเข้ารหัสผ่านการเข้ารหัสแบบโฮโมมอร์ฟิก

ย่อหน้าก่อนหน้านี้ได้แนะนำวิธีที่แตกต่างกันในการให้ความแน่ใจว่าธุรกรรมสามารถถอดรหัสได้ แต่เมื่อสามารถถอดรหัสของธุรกรรมได้? คำตอบคือ: หลังจากที่ธุรกรรมถูกรวมอยู่ในบล็อกและเรียงลำดับได้ แต่ทำไงให้ Block Builder สร้างบล็อกจากกองขยะหรือแม้กระทั่งสร้างบล็อกที่มีกำไรมากมายอย่างมีประสิทธิภาพ? คำตอบคือ: Homomorphic Encryption (HE)

△ ตัวอย่างของการเข้ารหัสโฮโมมอร์ฟิกที่ใช้สำหรับการลงคะแนนเสียง: หัวข้อของการลงคะแนนเสียงได้รับการเข้ารหัสแล้ว แต่ข้อความจะยังสามารถรวมกันและถอดรหัสหลังจากที่ผลลัพธ์ได้รับการคำนวณ แหล่งภาพ: https://twitter.com/khushii_w/status/1660278622291210242

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

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

△ ผ่านการเข้ารหัสโฮโมมอร์ฟิก บล็อกบิลเดอร์สามารถประกอบบล็อกที่สมบูรณ์และถูกกฎหมายจากการธุรกรรมที่ถูกเข้ารหัส

เคล็ดลับการอ่าน: มีระดับของการเข้ารหัส homomorphic เช่นการเข้ารหัส homomorphic บางส่วน (บางส่วน HE) และการเข้ารหัส homomorphic อย่างสมบูรณ์ (Fully HE) การเข้ารหัสแบบ homomorphic บางส่วนสามารถเพิ่มหรือคูณข้อความเข้ารหัสได้เท่านั้นในขณะที่การเข้ารหัสแบบ homomorphic อย่างสมบูรณ์สามารถเพิ่มและคูณข้อความเข้ารหัสได้ (โดยทั่วไปการดําเนินการใด ๆ สามารถทําได้)

△ คอลัมน์ที่สาม: ความสมบูรณ์ของเทคโนโลยีการเข้ารหัสและถอดรหัสที่สนับสนุน FHE ที่แตกต่างกัน ยกเว้นในกรณีของการเดินทางและอาณาเขตที่ไม่ต้องการ HE และดังนั้นถือว่ารองรับ ส่วนอื่น ๆ ยังไม่พร้อมใช้งาน แหล่งภาพ: https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_620

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

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

Ensure Metadata does not leak privacy

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

1. ที่อยู่ IP

2. ลายเซ็นธุรกรรม

3. ค่าธรรมเนียมการทำธุรกรรม

4. ผู้เริ่มต้นธุรกรรมและค่า Nonce ของมัน

5. ขนาดธุรกรรม

△ ข้อมูลเมตาของธุรกรรมที่แตกต่างกันอาจทำให้ความเป็นส่วนตัวของผู้ใช้รั่วไหล ที่มาของรูปภาพ:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_709

ที่อยู่ IP

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

ลายเซ็นการทำธุรกรรม ค่าธรรมเนียมการดำเนินการ ผู้เริ่มต้นการทำธุรกรรมและค่า Nonce ของมัน

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

เมื่อโหนดได้รับธุรกรรมที่ถูกเข้ารหัสแล้ว จะต้อง (1) ยืนยันให้แน่ใจก่อนว่าผู้เริ่มต้นธุรกรรมได้เริ่มต้นธุรกรรมจริง ๆ คือการยืนยันลายเซ็นต์ธุรกรรม และจากนั้น (2) ยืนยันว่าผู้เริ่มต้นมี ETH พอสำหรับการจ่ายค่าธุรกรรม (ยอดคงเหลือของผู้ใช้ ≥ ราคา gas * ขีดจำกัด gas) และ (3) ตรวจสอบค่า nonce ของผู้ส่งเพื่อหลีกเลี่ยงการโจมตีซ้ำซ้อนของธุรกรรม

พิสูจน์ที่ไม่มีความรู้

เราสามารถใช้พิสูจน์ที่ไม่รู้เพื่อพิสูจน์ว่าธุรกรรมผ่านการตรวจสอบเหล่านี้โดยไม่เปิดเผยข้อมูลเหล่านี้ พิสูจน์ที่ไม่รู้เรื่องหนึ่งประกอบด้วยข้อมูลสาธารณะ (Public Input), ข้อมูลส่วนตัว (Private Witness), และคำกล่าวที่พิสูจน์ต้องการพิสูจน์ (Statement).

△ตัวอย่างเช่นข้อมูลสาธารณะ (อินพุตสาธารณะ) เป็นธุรกรรมที่เข้ารหัส (tx ciphertext) ข้อมูลส่วนตัว (พยานส่วนตัว) เป็นธุรกรรมที่ไม่ได้เข้ารหัส (tx ciphertext) และคําสั่ง (คําสั่ง zk) ที่จะพิสูจน์โดยหลักฐานที่ไม่มีความรู้นี้คือ "ธุรกรรมที่เข้ารหัสนี้ถูกกฎหมาย" (tx ciphertext ถูกต้อง) แหล่งที่มาของภาพ:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_391

ตัวอย่างเช่น หาก Alice ต้องการพิสูจน์ให้ Bob ทราบว่าเธอมีมากกว่า 10 ETH แต่ไม่ต้องการเปิดเผยที่อยู่ของเธอ เธอสามารถใช้พิสูจน์ที่ไม่เปิดเผยได้เพื่อพิสูจน์ให้ Bob ทราบว่าที่อยู่ของเธอจริงๆ มียอดเงินมากกว่า 10 ETH

“พิสูจน์ว่าที่อยู่ของ Alice มียอดคงเหลือมากกว่า 10 ETH” เป็นคำกล่าวตัว (zk statement) ที่จะต้องพิสูจน์โดยพิสูจน์ที่เรียกว่าศูนย์ศาสตร์ (zero-knowledge proof) นี้ ในการสร้างพิสูจน์นี้ Alice จำเป็นต้องให้ที่อยู่ของเธอและพิสูจน์ว่าเธอถือกุญแจส่วนตัวของที่อยู่ (เช่น การใช้ private key สร้างลายเซ็นเจอร์) และเธอยังต้องให้ยอดคงเหลือ ETH ของที่อยู่นี้ เช่น ใช้ Merkle Proof เพื่อพิสูจน์ว่าที่อยู่นี้ถือ ETH ได้เท่าใดในบล็อกที่ 1001

ที่อยู่ ลายเซ็น และพิสูจน์เมอร์เคิลไม่สามารถเปิดเผยได้และเป็นข้อมูลส่วนตัว (พยานส่วนตัว)

เมื่อพิสูจน์นี้ถูกสร้างขึ้น บ็อบสามารถตรวจสอบพิสูจน์นี้ด้วย Merkle Root (ที่เรียกว่า State Root) ของต้นไม้สถานะของบล็อก 1001 ใครๆก็ทราบ State Root ของแต่ละบล็อกซึ่งเป็นข้อมูลสาธารณะ (ข้อมูลนำเข้าสาธารณะ)

ข้อมูลเพียงเท่าที่บ็อบทราบคือข้อมูลสาธารณะของรากสถานะและผลลัพธ์การตรวจสอบ เขาจะไม่ทราบข้อมูลส่วนตัวของอลิซ

△ แอลิซให้ข้อมูลเข้ารหัสสองอย่าง: พิสูจน์เมอร์เคิลและลายเซ็น; บ็อบให้ข้อมูลเข้ารหัสสาธารณะของรากสถานะ คำประกาศ zk สามารถยืนยันว่า แอลิซมีที่อยู่และยอดเงินในที่อยู่มากกว่า 10 ETH

(1) ตรวจสอบลายเซ็นการทำธุรกรรม

การตรวจสอบลายเซ็นธุรกรรมประกอบด้วยสองส่วน: (ก) ตัวเริ่มต้นธุรกรรมถูกต้องตามกฎหมายและ (ข) ลายเซ็นธุรกรรมลงนามโดยตัวเริ่มต้นธุรกรรม

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

(b) ตรวจสอบว่าลายเซ็นธุรกรรมลงนามโดยคีย์ส่วนตัวของผู้ริเริ่มธุรกรรม

△ พิสูจน์นี้ยืนยัน (a) ที่อยู่ของผู้ส่งธุรกรรม (ผ่านการพิสูจน์ Merkle pubkey ของผู้ส่ง) และ (b) ลายเซ็นในธุรกรรมเป็นชอบ (ลายเซ็นจะถูกรวมอยู่ในข้อความ tx plaintext) tx plaintext เป็นข้อมูลธุรกรรมชัดเจนแบบดิบที่ไม่ได้เข้ารหัส ซึ่งเป็นข้อมูลส่วนตัวที่ให้โดยผู้เริ่มต้นธุรกรรม

Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_736

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

△ พิสูจน์ว่าที่อยู่ของผู้เริ่มต้นธุรกรรมมีอยู่ในต้นไม้สถานะ Ethereum และว่าผู้เริ่มต้นธุรกรรมจริง ๆ มีกุญแจส่วนตัวของที่อยู่

(2) ยืนยันว่าผู้เริ่มต้นธุรกรรมมีจำนวนเงินพอใน ETH เพื่อชำระค่าธรรมเนียม

เช่นเดียวกับตัวอย่างก่อนหน้าของ Alice และ Bob ที่พิสูจน์ว่ายอดเงินมีค่า > 10 ETH ผู้เริ่มต้นธุรกรรมต้องให้พิสูจน์ Merkle ของยอดเงินในที่อยู่ของตนเอง และคำประพันธ์ที่ต้องพิสูจน์คือ "ยอดเงินในที่อยู่ ≥ ค่าธรรมเนียมการทำธุรกรรม" ค่าธรรมเนียมการทำธุรกรรมเท่ากับราคาแก๊สคูณกับขีดจำกัดแก๊ส ข้อมูลทั้งราคาแก๊สและขีดจำกัดแก๊สรวมอยู่ในข้อมูลธุรกรรมไม่เข้ารหัส (tx plaintext) ข้อมูล tx plaintext เป็นข้อมูลส่วนตัวที่ให้โดยผู้เริ่มต้นธุรกรรม

△ พิสูจน์นี้ยืนยันว่ายอดเงินในบัญชีผู้เริ่มธุรกรรม (ผ่านพิสูจน์ Merkle ยอดเงินผู้ส่ง) มากกว่าหรือเท่ากับค่าธรรมเนียมการทำธุรกรรม (ข้อมูลค่าธรรมเนียมการทำธุรกรรมรวมอยู่ใน tx plaintext) ที่มา: https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_743

△ พิสูจน์สมดุลของที่อยู่ผู้เริ่มธุรกรรม > ราคาน้ำมัน

(3) ตรวจสอบค่า Nonce ของผู้เริ่มทำธุรกรรม

เนื่องจาก Nonce ยังถูกบันทึกในสถานะ Ethereum การพิสูจน์ Merkle ใช้เพื่อพิสูจน์ค่า Nonce ปัจจุบันของผู้เริ่มธุรกรรม แล้วเปรียบเทียบกับค่า Nonce ที่ระบุในธุรกรรมเพื่อยืนยันว่าธุรกรรมไม่ถูกทำซ้ำ

△หลักฐานนี้เปรียบเทียบค่า Nonce ของที่อยู่ของผู้ริเริ่มธุรกรรม (ผ่านหลักฐาน Nonce Merkle) และค่า Nonce ที่ระบุโดยธุรกรรม (ค่า Nonce ที่ระบุโดยธุรกรรมจะรวมอยู่ในข้อความธรรมดา tx) แหล่งที่มาของภาพ:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_327

△ พิสูจน์ nonce ของที่อยู่ผู้เริ่มต้นธุรกรรม = tx nonce

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

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

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

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

Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_750

△ พิสูจน์ nonce ของที่อยู่ผู้เริ่มธุรกรรม = tx nonce และ replay tag = H(nonce, key)

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

ในขณะนี้เราสามารถนำค่า Slot ของ PoS เข้าสู่การคำนวณของ Replay Tag ได้: replay tag = H(nonce, private key, slot) ตัวอย่างเช่น บ็อบส่งธุรกรรมด้วย Nonce ค่า 5 ใน Slot 1001 แต่ยังไม่ได้รับรอยยิ้ม ดังนั้นเขาตัดสินใจที่จะเพิ่มราคาก๊าซของธุรกรรมขณะที่เก็บฟิลด์อื่น ๆ ที่ไม่เปลี่ยนแปลง และส่งธุรกรรมอัปเดตใน Slot 1005 ซึ่งเนื่องจาก Slot เปลี่ยนแปลงแล้ว Replay Tag ก็เปลี่ยนไป และธุรกรรมใหม่นี้จะไม่ถูกปฏิเสธเพราะค่า Nonce เหมือนเดิม

△ ข้อมูลนำเข้าสาธิตจะผ่านค่าช่องเพิ่มเติมเพื่อคำนวณแท็กเพลย์ ภาพจากแหล่งที่มา:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_757

5.ขนาดการทำธุรกรรม

วิธีการเข้ารหัสบางอย่างจะทําให้ขนาดของข้อมูลธุรกรรมที่เข้ารหัสเหมือนกับก่อนการเข้ารหัส อย่างไรก็ตามยังมีโอกาสที่จะอนุมานข้อมูลบางอย่างผ่านขนาด ตัวอย่างเช่นข้อมูลธุรกรรมของธุรกรรมที่ดําเนินการใน Uniswap จะต้องมีขนาดใหญ่กว่าข้อมูลธุรกรรมของการถ่ายโอน ETH อย่างง่าย ขนาดใหญ่ดังนั้นขนาดธุรกรรมจึงเหมือนกับข้อมูลเมตาที่อาจทําให้ความเป็นส่วนตัวรั่วไหล

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

△ สีขาวคือการเติม. การซื้อขายสีน้ำเงินและส้มมีขนาดเท่ากัน ดังนั้นไม่มีทางจะระบุได้ว่าเป็นสีใดโดยขึ้นอยู่กับขนาด. ภาพที่มา: https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_860

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

△ ข้อเสียคือความไม่มีประสิทธิภาพและการป้องกันความเป็นส่วนตัวที่ถูกจำกัด แหล่งภาพ:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_812

วิธีการที่ดีกว่าคือการเติมบรรทัดให้มีขนาดคงที่ก่อน แต่การเข้ารหัสโฮโมร์ฟิกสามารถใช้เพื่อลบการเติมบรรทัด

เนื่องจากธุรกรรมทั้งหมดมีขนาดคงที่ธุรกรรมทั้งหมดที่ผู้สังเกตการณ์เห็นจะมีขนาดเท่ากัน Block Builder สามารถรวมธุรกรรมที่เข้ารหัสผ่านฟังก์ชันและลบช่องว่างภายในในเวลาเดียวกัน

△ ใช้การเข้ารหัสโฮโมมอร์ฟิกเพื่อลบการเติมพลังขณะรวมธุรกรรมที่เข้ารหัสแล้ว ภาพที่มา: https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_908

คำแนะนำในการอ่าน: Block Builder ด้วย pure trust หรือ trusted hardware สามารถบรรลุผลลัพธ์เดียวกันได้โดยไม่ต้องใช้ homomorphic encryption (เนื่องจากทุกคนเชื่อมั่นในมัน)

วิธีการสร้างบล็อกอย่างมีประสิทธิภาพของ Block Builder

แม้ว่าเราสามารถรวมธุรกรรมที่เข้ารหัสอย่างมีประสิทธิภาพเข้าไปในบล็อกผ่านการเข้ารหัสโฮโมมอร์ฟิกได้ ยังมีปัญหาบางประการที่ต้องการแก้ เช่น (1) ธุรกรรมที่แตกต่างกันอาจอ่านและเขียนสถานะเดียวกัน (ตัวอย่างเช่นพวกเขาค้าทุกอย่างบน Uniswap) ซึ่งอาจ导致ธุรกรรมระดับต่ำกว่ามีโอกาสล้มเหลวมากกว่า และ (2) Block Builder ไม่สามารถรวบรวมธุรกรรมตามระดับค่าธรรมเนียมการจัดการ

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

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

△ มันถูกกำหนดโดยค่าธรรมเนียมการจัดการและรายการเข้าถึงว่าธุรกรรมใดจะถูกเก็บรวบรวมและลำดับที่พวกเขาจะถูกเก็บรวบรวม แหล่งภาพ:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1133

เวลาที่ธุรกรรมเกิดขึ้น

หากเรากังวลว่าเวลาที่ธุรกรรมที่เข้ารหัสถูกส่งไปยังเครือข่าย p2p อาจทําให้ความเป็นส่วนตัวรั่วไหล (ตัวอย่างเช่น Alice ทําธุรกรรมที่ UTC+8 00:00-04:00) เราสามารถขอให้ผู้ตรวจสอบความถูกต้องส่งธุรกรรม Dummy ที่เข้ารหัสเป็นประจํา เพื่อสร้างความสับสนให้กับผู้สังเกตการณ์

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

ธุรกรรมปลอมจะถูกระบุและทิ้งไปในระหว่างการดำเนินการเข้ารหัสโฮโมอร์ฟิกของกลุ่มบล็อก

△ ผู้ตรวจสอบจะส่ง (สีเทา) ธุรกรรมปลอมๆ อย่างสม่ำเสมอเพื่อทำให้ผู้สังเกตเห็นสับสน แต่นี้จะเพิ่มภาระให้กับเครือข่ายและโหนด ภาพฝากจาก:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1210

Mempools ที่เข้ารหัสกับ FSS

ในบทความก่อนหน้านี้ FSS ยังได้นำเสนอว่า FSS จะเข้ารหัสการทำธุรกรรมก่อนแล้วจึงส่งให้ Chainlink Oracle เรียงลำดับ กระบวนการของ FSS ในการเข้ารหัสการทำธุรกรรมและการตรวจสอบความถูกต้องของการทำธุรกรรมที่เข้ารหัสก็เหมือนกับ Encrypted Mempools นอกจาก:

• การเข้ารหัสธุรกรรมของ FSS ไม่ได้กล่าวถึงการป้องกัน Metadata ในขณะที่ Encrypted Mempools ซ่อน Metadata และใช้ฐานพิสูจน์ที่ไม่รู้เพื่อพิสูจน์ความถูกต้องของธุรกรรม
• FSS ใช้การเข้ารหัส/ถอดรหัสแบบค่ายิ่งยวด และถูกถอดรหัสร่วมกันโดย Chainlink Oracle ซึ่งหมายความว่าคุณต้องเชื่อถือ Chainlink Oracle ระบบการเข้ารหัส Mempools ไม่ระบุว่าจะเรียงลำดับอย่างไร แต่เน้นการเข้ารหัสธุรกรรมและพิสูจน์ความถูกต้องของมันด้วยหลักศูนย์ความรู้
• เมื่อเทียบกับ FSS ซึ่งเน้นเฉพาะ "ความเป็นธรรม" Encrypted Mempools ให้ความสําคัญกับ "วิธีการรวบรวมเนื้อหาบล็อกอย่างมีประสิทธิภาพและวิธีอนุญาตให้ผู้เสนอรวบรวมบล็อกที่เป็นประโยชน์มากที่สุดแทนที่จะสุ่มตัดสินใจลําดับของธุรกรรม"

ในอนาคต, FSS อาจใช้เทคโนโลยีใน Encrypted Mempools เพื่อเสริมหรือแทนที่การเข้ารหัสและถอดรหัสธุรกรรม

การจัดการ MEV ด้วยกระบวนการทางคริปโต

บทโพยนี้เกี่ยวกับ Encrypted Mempools ที่ผู้เขียนแบ่งปันวิธีการใช้เทคนิคทางกายภาพและการปรับปรุงในระดับความเห็นของ Ethereum สามารถช่วยต่อสู้กับปัญหาที่เกิดขึ้นจาก MEV สำหรับรายละเอียดโปรดตรวจสอบที่:https://www.youtube.com/watch?v=mpRq-WFihz8

สรุปและข้อความสำคัญ

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

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

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

4. นอกจากนี้ จำเป็นต้องหลีกเลี่ยง metadata เช่น IP, ขนาดข้อมูลธุรกรรม หรือเวลาส่งธุรกรรม ที่อาจทำให้ข้อมูลส่วนตัวของธุรกรรมรั่วไหล

5. สุดท้ายสิ่งที่สำคัญที่สุดคือการตรวจสอบให้แน่ใจว่าธุรกรรมสามารถถอดรหัสได้ —— การเข้ารหัสที่รับประกัน มีวิธีที่แตกต่างกัน 5 วิธี: ความไว้วางใจเพียงอย่างเดียว (In-flight), Trusted Hardware Enclave, การเข้ารหัส/ถอดรหัสแบบอุปกรณ์ชิ้นนี้, การเข้ารหัส/ถอดรหัสแบบเกณฑ์, และการเข้ารหัส/ถอดรหัสของพยาน แต่ละวิธีมีข้อดีและข้อเสียของตัวเอง

ข้อมูลอ้างอิงและการอ่านเพิ่มเติมที่แนะนำ

Mempools ที่เข้ารหัส

• https://www.youtube.com/watch?v=XRM0CpGY3sw
• https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_639
• วิธีการใช้ประโยชน์จากการเข้ารหัสเพื่อแก้ปัญหาที่เกิดจาก MEV จากชั้นแอปพลิเคชันและชั้นความเห็นทัศน์:https://youtu.be/jLHf6yw7b5Y?t=4139

ขอบคุณพิเศษถึงสตีเวน วู คิมิ วู เควิน ไม-ฮั่น เจีย และ อันต่อน เฉิง สำหรับการตรวจทานและปรับปรุงโพสต์นี้

ข้อความปฏิเสธความรับผิดชอบ：

1. บทความนี้ถูกพิมพ์โดย [MEVtechflowpost]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [Will 阿望；Diane Cheung]. If there are objections to this reprint, please contact the Gate Learnทีม และพวกเขาจะดำเนินการโดยเร็ว
2. คำประกาศความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางด้านการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่น ๆ ถูกดำเนินการโดยทีม Gate Learn ยกเว้นที่จะได้ระบุไว้ การคัดลอก การแจกจ่าย หรือการลอกเลียนแบบบทความที่ถูกแปลนั้นถือเป็นการละเมิดกฎหมาย