ที่มา: Delphi Digital

รวบรวมข้อความต้นฉบับ: The Way of DeFi

ประเด็นสำคัญ

• ที่มา: Delphi Digital

• รวบรวมข้อความต้นฉบับ: The Way of DeFi

• ประเด็นสำคัญ

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

• Rollups Scale Computation ในขณะที่ใช้ประโยชน์จากความปลอดภัยของ Ethereum

• ถนนทุกเส้นนำไปสู่การผลิตบล็อกแบบรวมศูนย์ การตรวจสอบความถูกต้องของบล็อกแบบกระจายอำนาจ และจุดจบเกมที่ทนต่อการเซ็นเซอร์

• ขณะนี้ MEV อยู่ด้านหน้าและตรงกลาง - มีการวางแผนการออกแบบจำนวนมากเพื่อลดอันตรายและป้องกันแนวโน้มไปสู่การรวมศูนย์

การแนะนำ

Danksharding รวมลู่ทางการวิจัยที่ทันสมัยหลายช่องทางเพื่อให้ชั้นฐานที่ปรับขนาดได้ซึ่งจำเป็นสำหรับแผนงานที่เน้นการรวมศูนย์ของ Ethereum

ฉันหวังว่าจะประสบความสำเร็จในชีวิตของเรา

การแนะนำ

ตอนที่ 1 – เส้นทางสู่ Danksharding

1) การออกแบบชิ้นส่วนข้อมูลดิบ - ผู้เสนอชิ้นส่วนอิสระ

2) การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล

3) ความมุ่งมั่นของ KZG

4) คำมั่นสัญญาของ KZG และหลักฐานการฉ้อโกง

8) Danksharding

5) การแยกผู้เสนอและผู้สร้างภายในโปรโตคอล

6) รายการต่อต้านการเซ็นเซอร์ (crList)

7) รูปแบบ KZG สองมิติ

9) Danksharding – การยืนยันเสียงข้างมากโดยสุจริต

10) Danksharding – การสร้างใหม่

11) Danksharding – การรักษาความปลอดภัยส่วนใหญ่ที่เป็นอันตรายพร้อมการสุ่มตัวอย่างส่วนตัว

12) Danksharding – ประเด็นสำคัญ

13) Danksharding – ข้อจำกัดของความสามารถในการปรับขนาดของ Blockchain

14) Danksharding ดิบ (EIP-4844)

15) EIP-1559 หลายมิติ

ส่วนที่ II – ประวัติศาสตร์และการจัดการรัฐ

1) ลดก๊าซข้อมูลการโทรตามขีด จำกัด ข้อมูลการโทรทั้งหมด (EIP-4488)

5) Verkle Tries

2) จำกัดการดำเนินการของข้อมูลประวัติในไคลเอนต์ (EIP-4444)

3) กู้คืนข้อมูลประวัติ

4) ไร้สัญชาติอย่างอ่อนแอ

2) MEV-Boost

6) รัฐหมดอายุ

ตอนที่ III – มันคือ MEV ทั้งหมด

1) ห่วงโซ่อุปทาน MEV ปัจจุบัน

3) การปรับ MEV ที่ขับเคลื่อนโดยคณะกรรมการ

4) การกำหนดระดับช่องเดียว

5) การเลือกตั้งผู้นำลับคนเดียว

1) ไคลเอนต์ที่ผสาน

การแนะนำ

2) ความเห็นพ้องต้องกัน

สรุปความคิด

การแนะนำ

ฉันสงสัยเกี่ยวกับลำดับเวลาของ The Merge เนื่องจาก Vitalik กล่าวว่าคนที่เกิดวันนี้มีโอกาส 50-75% ที่จะมีชีวิตอยู่ถึง 3,000 ปี และเขาหวังว่าจะมีชีวิตอยู่ตลอดไป อย่างไรก็ตาม ถือว่าเป็นเรื่องตลก อย่างไรก็ตาม เรายังคงต้องตั้งตารอแผนงานที่ทะเยอทะยานของ Ethereumนี่ไม่ใช่การอ่านอย่างรวดเร็ว หากคุณต้องการดูแผนงานที่ทะเยอทะยานของ Ethereum แบบกว้างและเหมาะสม ให้เวลาฉันหนึ่งชั่วโมงเพื่อโฟกัส แล้วฉันจะช่วยคุณประหยัดเวลาทำงานหลายเดือนมีแนวทางการวิจัย Ethereum มากมายให้ติดตามในระยะยาว แต่ท้ายที่สุดแล้วทุกอย่างก็รวมเป็นเป้าหมายเดียว — เพื่อขยายขนาดการคำนวณโดยไม่ต้องเสียสละการตรวจสอบแบบกระจายอำนาจ

หวังว่าคุณจะคุ้นเคยกับ Vitalik's ที่มีชื่อเสียง "

จบเกม

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

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

• นี่คืออภิธานศัพท์สำหรับย่อคำบางคำที่จะปรากฏ ~43531756765713534 ครั้ง:

• DA - ความพร้อมใช้งานของข้อมูล

• DS–Danksharding

• DAS – การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล

• PBS – การแยกผู้เสนอและผู้สร้าง

PDS – darksharding ดิบ

PoW - หลักฐานการทำงาน

PoS – หลักฐานการเดิมพัน

ตอนที่ 1: เส้นทางสู่ Danksharding

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

ชั้นฉันทามติไม่ตีความข้อมูลที่แยกส่วน มีงานเดียวที่ต้องทำ - ตรวจสอบให้แน่ใจว่าข้อมูลพร้อมใช้งาน

ฉันถือว่าคุณคุ้นเคยกับแนวคิดพื้นฐานเช่น Rollup, Fraud และ ZK Proofs อยู่แล้ว และเหตุใด DA จึงมีความสำคัญ หากคุณไม่คุ้นเคยหรือแค่ต้องการทบทวน รายงานที่เผยแพร่เมื่อเร็วๆ นี้ของ Can เกี่ยวกับ Celestia จะครอบคลุมถึงสิ่งเหล่านี้

การออกแบบชิ้นส่วนข้อมูลดิบ - ผู้เสนอชิ้นส่วนข้อมูลอิสระ

การออกแบบที่อธิบายไว้ที่นี่ล้าสมัย แต่เป็นสถานการณ์ที่มีคุณค่า เพื่อความง่าย ฉันจะเรียกสิ่งนี้ว่า "sharding 1.0"

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

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

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

DS แตกต่างอย่างสิ้นเชิง ตัวตรวจสอบความถูกต้องดำเนินการ DAS เพื่อยืนยันว่าข้อมูลทั้งหมดมีอยู่ (ไม่มีคณะกรรมการย่อยที่แยกจากกันอีกต่อไป) เครื่องมือสร้างที่เชี่ยวชาญจะสร้างบล็อกขนาดใหญ่ที่มีบล็อกบีคอนและข้อมูลเศษทั้งหมดได้รับการยืนยันพร้อมกัน ดังนั้น PBS จึงจำเป็นสำหรับ DS ที่จะยังคงกระจายอำนาจ (การสร้างบล็อคขนาดใหญ่ร่วมกันนั้นต้องใช้ทรัพยากรมาก)

• การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล

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

แต่ DAS อนุญาตให้โหนด (แม้แต่ไคลเอ็นต์แบบไลท์) ตรวจสอบได้อย่างง่ายดายและปลอดภัยว่าทุกอย่างพร้อมใช้งานโดยไม่ต้องดาวน์โหลดทุกอย่าง

วิธีแก้ปัญหาง่ายๆ - เพียงตรวจสอบกลุ่มก้อนสุ่มในบล็อกนั้น ถ้าทุกคนเซ็น ผมก็เซ็น แต่ถ้าคุณพลาดการทำธุรกรรมที่ให้ ETH ทั้งหมดของคุณแก่ Sifu กองทุนไม่ปลอดภัยอีกต่อไป

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

สำหรับผู้ที่ไม่เข้าใจคณิตศาสตร์เราจะอธิบายอย่างรวดเร็ว (ฉันสัญญาว่ามันจะไม่ใช่คณิตศาสตร์ที่น่ากลัวจริงๆ - ฉันต้องดูวิดีโอของ Khan Academy เพื่อเขียนส่วนต่างๆ แต่ตอนนี้ฉันเข้าใจแล้ว)

พหุนามคือนิพจน์ที่หาผลรวมพจน์ของจำนวนจำกัดใดๆ ในรูปแบบ cxk องศาเป็นเลขชี้กำลังสูงสุด ตัวอย่างเช่น 2 x3+6 x2+2 x-4 เป็นพหุนามลูกบาศก์ คุณสามารถสร้างพหุนามของดีกรี d จากพิกัด d+1 ใดๆ ที่อยู่ในพหุนามนั้นได้

ตอนนี้ให้ตัวอย่างที่เป็นรูปธรรม ด้านล่างเรามีข้อมูลสี่ส่วน (d0 ถึง d3) ข้อมูลเหล่านี้สามารถจับคู่กับการประเมินพหุนาม f(X) ณ จุดที่กำหนดได้ ตัวอย่างเช่น f(0) = d0 ตอนนี้คุณได้พบพหุนามดีกรีต่ำสุดที่ดำเนินการผ่านการประเมินเหล่านี้แล้ว เนื่องจากนี่คือสี่ส่วน เราจึงสามารถหาพหุนามลูกบาศก์ได้ จากนั้นเราสามารถขยายข้อมูลนี้เพื่อเพิ่มการประเมินสี่รายการ (e0 ถึง e3) ในพหุนามเดียวกัน

จดจำคุณสมบัติพหุนามที่สำคัญ - เราสามารถสร้างมันขึ้นมาใหม่จากสี่จุดใดก็ได้ ไม่ใช่แค่ข้อมูลสี่ก้อนดั้งเดิมของเรา

กลับไปที่ DAS ของเรา ตอนนี้เราต้องแน่ใจว่ามีข้อมูลโค้ดลบ 50% (4/8) ที่มีอยู่ จากนี้เราสามารถสร้างบล็อกใหม่ทั้งหมดได้

ดังนั้น ผู้โจมตีจะต้องซ่อนบล็อกมากกว่า 50% เพื่อหลอกโหนด DAS ให้คิดว่าข้อมูลนั้นพร้อมใช้งานเมื่อไม่มีข้อมูล

หลังจากการสุ่มตัวอย่างที่ประสบความสำเร็จหลายครั้ง ความน่าจะเป็นที่มีอยู่ <50% นั้นน้อยมาก หากเราสุ่มตัวอย่างการลบข้อมูลที่เข้ารหัสสำเร็จ 30 ครั้ง ความน่าจะเป็นที่ <50% จะพร้อมใช้งานคือ 2-30

ความมุ่งมั่นของ KZG

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

• โดยปกติแล้วเราเพียงแค่ส่งข้อมูลจำนวนมากโดยใช้ Merkle root วิธีนี้ใช้ได้ผลในการพิสูจน์ว่าคอลเล็กชันมีข้อมูลบางอย่าง

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

นักพัฒนากำลังทำงานในสองทิศทาง:

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

Ethereum และ Polygon Avail กำลังใช้เส้นทางใหม่ - KZG Commitments (aka Kate Commitments) การดำเนินการนี้จะลบข้อสันนิษฐานด้านความปลอดภัยของชนกลุ่มน้อยที่ซื่อสัตย์และซิงโครนัสเกี่ยวกับหลักฐานการฉ้อโกงออกไป

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

กลับไปที่ข้อผูกมัด KZG - นี่คือโครงร่างข้อผูกมัดแบบพหุนาม

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

• ในกรณีของเรา เราแมปข้อมูลต้นฉบับและข้อมูลที่ขยายทั้งหมดลงในกริด X,Y แล้วหาพหุนามดีกรีต่ำสุดที่ผ่านเข้าไป (กระบวนการนี้เรียกว่าการแก้ไข Lagrangian) พหุนามนี้คือสิ่งที่ผู้พิสูจน์จะสัญญา:

นี่คือประเด็นสำคัญ:

• เรามี "พหุนาม" f(X)

• ผู้พิสูจน์ให้ "คำมั่นสัญญา" กับพหุนาม C(f)

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

• สำหรับ "การประเมินค่า" ใดๆ ของพหุนาม y = f(z) ผู้พิสูจน์สามารถคำนวณ "การพิสูจน์" π(f,z)

• จากข้อผูกมัด C(f), การพิสูจน์ π(f,z), ตำแหน่ง z ใดๆ และการประเมิน y ของพหุนามที่ z ผู้ตรวจสอบสามารถยืนยันได้ว่า f(z) = y

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

• นี่เป็นการพิสูจน์ว่าข้อมูลต้นฉบับได้รับการปรับขนาดอย่างถูกต้อง เนื่องจากการประเมินทั้งหมดอยู่บนพหุนามเดียวกัน

• โปรดทราบว่าตัวตรวจสอบไม่จำเป็นต้องใช้พหุนาม f(X)

• คุณสมบัติที่สำคัญ - มีขนาดข้อผูกมัด O(1) ขนาดการพิสูจน์ O(1) และเวลาการตรวจสอบ O(1) มาตราส่วนการสร้างความมุ่งมั่นและการพิสูจน์เฉพาะใน O(d) แม้แต่สำหรับผู้พิสูจน์ โดยที่ d คือระดับของพหุนาม

• คำอธิบาย: แม้ว่า n (จำนวนของค่าใน X) จะเพิ่มขึ้น (เช่น เมื่อชุดข้อมูลเพิ่มขึ้นพร้อมกับ shard blobs ที่ใหญ่ขึ้น) สัญญาและการพิสูจน์ยังคงมีขนาดเท่าเดิม และการตรวจสอบต้องใช้ความพยายามอย่างต่อเนื่อง

ทั้งคู่ยอมรับ C(f) และพิสูจน์ว่า π(f,z) เป็นเพียงองค์ประกอบเส้นโค้งวงรีบนเส้นโค้งที่เป็นมิตรต่อคู่ (สิ่งนี้จะใช้ BL12-381) ในกรณีนี้มีขนาดเพียง 48 ไบต์เท่านั้น (เล็กมาก)

ดังนั้น ผู้พิสูจน์ที่ส่งข้อมูลต้นฉบับและข้อมูลส่วนขยายจำนวนมาก (แทนค่าพหุนามหลายตัว) จึงยังมีขนาดเพียง 48 ไบต์ และการพิสูจน์มีขนาดเพียง 48 ไบต์เท่านั้น

TLDR – สามารถปรับขนาดได้สูง

จากนั้น รูต KZG (พันธะพหุนาม) จะคล้ายกับรูต Merkle (ซึ่งเป็นพันธะเวกเตอร์):

ข้อมูลต้นฉบับคือพหุนาม f (X) ที่คำนวณที่ตำแหน่ง f (0) ถึง f (3) ซึ่งเราจะขยายโดยการคำนวณพหุนามที่ f (4) ถึง f (7) ทุกจุด f (0) ถึง f (7) รับประกันว่าจะอยู่บนพหุนามเดียวกัน

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

ดีมาก นั่นคือสิ่งที่พีชคณิตมีไว้สำหรับวันนี้

คำมั่นสัญญาของ KZG และหลักฐานการฉ้อโกง

ตอนนี้เราเข้าใจวิธีการทำงานของ KZG แล้ว ลองย้อนกลับไปเปรียบเทียบทั้งสองวิธี

• ข้อเสียของ KZG - มันไม่ปลอดภัยหลังควอนตัม มันต้องมีการตั้งค่าที่เชื่อถือได้ สิ่งเหล่านี้ไม่น่าเป็นห่วง STARK ให้ทางเลือกหลังควอนตัม ในขณะที่การตั้งค่าที่เชื่อถือได้ (การมีส่วนร่วมแบบเปิด) ต้องการผู้เข้าร่วมที่ซื่อสัตย์เพียงคนเดียว

• ข้อดีของ KZG - เวลาแฝงต่ำกว่าการตั้งค่าหลักฐานการฉ้อโกง (แม้ว่าตามที่ระบุไว้ก่อนหน้านี้ GASPER จะไม่เข้ารอบสุดท้ายอย่างรวดเร็วก็ตาม) และรับประกันการลบรหัสที่ถูกต้องโดยไม่ต้องใช้ข้อสันนิษฐานเล็กน้อยเกี่ยวกับความสอดคล้องกันและความซื่อสัตย์

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

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

การแนะนำสมมติฐานการซิงโครไนซ์อีกครั้ง - โหนดต้องสามารถสื่อสารได้ชั่วระยะเวลาหนึ่งเพื่อให้กลับมารวมกันได้

เครื่องมือตรวจสอบความถูกต้องของ Ethereum ดาวน์โหลด shard blobs ใน PDS และด้วย DS พวกเขาจะทำเฉพาะ DAS (ดาวน์โหลดแถวและคอลัมน์ที่จัดสรรไว้) Celestia จะกำหนดให้ผู้ตรวจสอบความถูกต้องดาวน์โหลดบล็อกทั้งหมด

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

• หาก Celestia จะเปลี่ยนจากการกำหนดให้ตัวตรวจสอบความถูกต้องดาวน์โหลดข้อมูลทั้งหมดเป็นการนำ DAS ไปใช้งานเท่านั้น (แม้ว่าการเปลี่ยนแปลงดังกล่าวจะยังไม่ได้วางแผนไว้ก็ตาม) เมื่อนั้นข้อได้เปรียบด้านเวลาแฝงของ KZG ก็จะชัดเจนขึ้น จากนั้น พวกเขาจำเป็นต้องดำเนินการตามข้อผูกพันของ KZG - การรอการพิสูจน์การฉ้อโกงหมายถึงการเพิ่มช่วงเวลาการบล็อกอย่างมีนัยสำคัญ และความเสี่ยงที่ผู้ตรวจสอบความถูกต้องจะลงคะแนนสำหรับการบล็อกที่เข้ารหัสผิดจะสูงมาก–Vitalik

• ฉันขอแนะนำสิ่งต่อไปนี้สำหรับการสำรวจเชิงลึกเพิ่มเติมว่าคำสัญญาของ KZG ทำงานอย่างไร:–Dankrad

• ไพรเมอร์ (ค่อนข้างง่ายที่จะเข้าใจ) ในการเข้ารหัสแบบเส้นโค้งวงรี–Vitalik

สำรวจการจับคู่ Elliptic Curve

พันธสัญญาพหุนามของ KZG

การตั้งค่าที่เชื่อถือได้ทำงานอย่างไร

การแยกผู้เสนอและผู้สร้างภายในโปรโตคอล

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

PBS แยกพวกเขา - มันสร้างบทบาทตัวสร้างในโปรโตคอลใหม่อย่างชัดเจน ผู้สร้างมืออาชีพจะรวบรวมบล็อกเข้าด้วยกันและเสนอราคาให้กับผู้เสนอ (ผู้ตรวจสอบความถูกต้อง) เพื่อเลือกบล็อกของพวกเขา สิ่งนี้ต่อสู้กับอำนาจรวมศูนย์ของ MEV

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

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

3. การใช้งาน PBS ที่แน่นอนยังอยู่ระหว่างการสนทนา แต่ PBS แบบสองช่องอาจมีลักษณะดังนี้:

4. ผู้สร้างยอมรับส่วนหัวของบล็อกด้วยการเสนอราคา

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

คณะกรรมการพิสูจน์ยืนยันส่วนหัวที่ชนะ

ผู้สร้างประกาศร่างกายที่ชนะ

คณะกรรมการอิสระที่มีพยานเป็นผู้เลือกร่างที่ชนะ (หากผู้สร้างที่ชนะไม่เห็นด้วย จะถือว่าขาดการโหวต)

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

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

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

ข้อเสียของการออกแบบ "สองช่อง" นี้คือเวลาแฝง บล็อกที่ผสานจะคงที่ 12 วินาที ดังนั้นที่นี่เราต้องการ 24 วินาทีเพื่อให้ได้เวลาเต็มบล็อก (สองช่อง 12 วินาที) หากเราไม่ต้องการแนะนำสมมติฐานใหม่ 8 วินาทีต่อช่อง (เวลาบล็อก 16 วินาที) ดูเหมือนจะเป็นการประนีประนอมที่ปลอดภัย แม้ว่าการวิจัยยังดำเนินอยู่

1. รายการต่อต้านการเซ็นเซอร์ (crList)

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

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

4. ผู้เสนอเผยแพร่ crList และสรุป crList ซึ่งรวมถึงธุรกรรมที่มีสิทธิ์ทั้งหมด

5. ผู้สร้างสร้างเนื้อหาของบล็อกที่เสนอ จากนั้นส่งการเสนอราคาที่รวมแฮชของไดเจสต์ crList เพื่อพิสูจน์ว่าพวกเขาได้เห็นแล้ว

ผู้เสนอยอมรับการเสนอราคาและบล็อกส่วนหัวของผู้สร้างที่ชนะ (พวกเขายังไม่เห็นเนื้อหา)

ผู้สร้างเผยแพร่บล็อกของพวกเขาและรวมหลักฐานว่าพวกเขาได้รวมธุรกรรมทั้งหมดจาก crList หรือบล็อกนั้นเต็ม มิฉะนั้นกฎการเลือกทางแยกจะไม่ยอมรับการบล็อก

ผู้พิสูจน์ตรวจสอบความถูกต้องของเนื้อความที่เผยแพร่

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

โครงร่าง KZG สองมิติ

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

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

เพื่อให้การสร้างใหม่ง่ายขึ้น แต่ละบล็อกจะมี m shard blobs ที่เข้ารหัสเป็น m KZG การทำเช่นนี้อย่างไร้เดียงสาจะส่งผลให้เกิดการสุ่มตัวอย่างจำนวนมาก - คุณจะทำ DAS ในแต่ละ shard blob จนกว่าจะมีทั้งหมด (m*k ตัวอย่าง โดยที่ k คือจำนวนตัวอย่างต่อ blob)

Ethereum จะใช้รูปแบบ 2D KZG แทน เราใช้รหัส Reed-Solomon อีกครั้งเพื่อปรับขนาดข้อผูกมัด m เป็นข้อผูกมัด 2 m:

เราทำให้เป็นแบบแผน 2 มิติโดยขยายข้อผูกพันเพิ่มเติมของ KZG ในพหุนามเดียวกับ 0-255 (ในที่นี้คือ 256-511) ตอนนี้เราต้อง DAS ตารางด้านบนเพื่อให้แน่ใจว่าข้อมูลพร้อมใช้งานสำหรับเศษทั้งหมด

ข้อกำหนดการสุ่มตัวอย่าง 2 มิติที่ ≥75% ของข้อมูลที่มีอยู่ (เทียบกับ 50% ก่อนหน้านี้) หมายความว่าเราจะเพิ่มขนาดตัวอย่างคงที่อีกเล็กน้อย ก่อนที่ฉันจะพูดถึง 30 ตัวอย่างสำหรับ DAS ในรูปแบบ 1D แบบง่าย แต่สิ่งนี้ต้องการ 75 ตัวอย่างเพื่อให้แน่ใจว่ามีโอกาสเป็นไปได้เท่ากันในการสร้างบล็อกที่ใช้งานได้ใหม่

Sharding 1.0 (ด้วยแผนความมุ่งมั่น 1D KZG) ต้องการตัวอย่างเพียง 30 ตัวอย่าง แต่ถ้าคุณต้องการตรวจสอบ DA ทั้งหมดของ 1920 ตัวอย่าง คุณต้องสุ่มตัวอย่าง 64 ชิ้น แต่ละตัวอย่างคือ 512 B ดังนั้นสิ่งนี้จึงต้องการ:

(512 B x 64 ชิ้น x 30 ตัวอย่าง) / 16 วินาที = แบนด์วิดท์ 60 KB/s

Danksharding

อย่างมีประสิทธิภาพ ตัวตรวจสอบความถูกต้องจะถูกสับเปลี่ยนโดยไม่ต้องตรวจสอบเศษทั้งหมดทีละส่วน

บล็อกองค์ประกอบที่ใช้แผนความมุ่งมั่น 2D KZG ทำให้การตรวจสอบเรื่องเล็กน้อยของ DA เต็มรูปแบบ ต้องการเพียง 75 ตัวอย่างของบล็อกเครื่องแบบเดียว:

(512 B x 1 บล็อก x 75 ตัวอย่าง) / 16 วินาที = แบนด์วิดท์ 2.5 KB/s

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

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

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

Danksharding – การยืนยันเสียงข้างมากโดยสุจริต

ข้อมูลหลักฐานของผู้ตรวจสอบมีอยู่ดังต่อไปนี้:

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

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

• Danksharding - การปรับโครงสร้างใหม่

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

สมมติฐานที่ปลอดภัยสำหรับการสร้างบล็อกที่ใช้งานได้ใหม่คือ:

โหนดเพียงพอที่จะดำเนินการตามคำขอตัวอย่างเพื่อให้มีข้อมูลรวมกันเพียงพอในการสร้างบล็อกใหม่

สมมติฐานการซิงโครไนซ์ระหว่างโหนดที่กระจายบล็อกตามลำดับ

แล้วมีกี่โหนดถึงจะพอ? ค่าประมาณโดยประมาณคือประมาณ 64,000 ราย (มากกว่า 380,000 รายจนถึงปัจจุบัน) นี่เป็นการคำนวณในแง่ร้ายเช่นกันที่ถือว่าไม่มีการครอสโอเวอร์ระหว่างโหนดที่รันโดยตัวตรวจสอบเดียวกัน (ซึ่งห่างไกลจากโหนดที่ถูกจำกัดไว้ที่ 32 ETH) หากคุณสุ่มตัวอย่างมากกว่า 2 แถวและคอลัมน์ โอกาสที่คุณจะดึงข้อมูลเหล่านั้นกลับมารวมกันได้เพิ่มขึ้นเนื่องจากการครอสโอเวอร์ สิ่งนี้เริ่มปรับขนาดเป็นกำลังสอง - 64,000 อาจเป็นลำดับความสำคัญที่น้อยกว่าหากตัวตรวจสอบกำลังเรียกใช้ตัวตรวจสอบความถูกต้อง 10 หรือ 100 ตัว

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

Danksharding – การรักษาความปลอดภัยส่วนใหญ่ที่เป็นอันตรายด้วยการสุ่มตัวอย่างส่วนตัว

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

ในตอนแรก DS จะไม่รวมการสุ่มตัวอย่างแบบส่วนตัว เนื่องจากนี่เป็นปัญหาที่แก้ไขได้ยากในแง่ของระบบเครือข่าย (PSA: บางทีพวกเขาอาจจะใช้ความช่วยเหลือของคุณก็ได้!)

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

Danksharding – ประเด็นสำคัญ

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

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

• ดังนั้น หากคุณกำลังสงสัยว่านี่ยังเป็นการแบ่งส่วนจริงๆ หรือไม่ คุณก็ไม่ได้บ้า ความแตกต่างนี้เป็นสาเหตุที่ PDS (ซึ่งเราจะพูดถึงในไม่ช้า) ไม่ถือว่าเป็น "เศษ" (แม้ว่าจะมีคำว่า "เศษ" ในชื่อก็ตาม ใช่ ฉันรู้ว่ามันสับสน) PDS กำหนดให้ตัวตรวจสอบความถูกต้องแต่ละรายการดาวน์โหลด shard blobs ทั้งหมดเพื่อพิสูจน์ความพร้อมใช้งาน จากนั้น DS จะแนะนำการสุ่มตัวอย่าง ดังนั้นตัวตรวจสอบความถูกต้องแต่ละตัวจะดาวน์โหลดเพียงบางส่วนเท่านั้น

• โชคดีที่การแบ่งส่วนย่อยน้อยที่สุดหมายถึงการออกแบบที่เรียบง่ายกว่าการแบ่งส่วนย่อย 1.0 (ส่งมอบเร็วมากใช่ไหม) กล่าวโดยย่อ ได้แก่

เมื่อเทียบกับข้อมูลจำเพาะของ Sharding 1.0 อาจมีโค้ดน้อยกว่าหลายร้อยบรรทัดในข้อมูลจำเพาะ DS (น้อยกว่าหลายพันรายการในฝั่งไคลเอ็นต์)

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

ไม่มีการติดตามการยืนยัน Shard Blob แต่ละรายการ ได้รับการยืนยันทั้งหมดในห่วงโซ่หลักในขณะนี้ หรือไม่ก็ตาม

ผลลัพธ์ที่ดีของสิ่งนี้คือตลาดรวมค่าธรรมเนียมสำหรับข้อมูล Sharding 1.0 ด้วยบล็อกต่างๆ ที่สร้างโดยผู้เสนอที่แตกต่างกันจะกระจายสิ่งนี้ออกไปdAMMการปลดคณะกรรมการชุดย่อยยังช่วยเสริมความแข็งแกร่งในการต่อต้านการติดสินบน โปรแกรมตรวจสอบ DS ลงคะแนนเสียงทั้งบล็อกหนึ่งครั้งต่อยุค ดังนั้นข้อมูลจะได้รับการยืนยันทันทีโดย 1/32 ของชุดเครื่องมือตรวจสอบทั้งหมด (32 ช่องต่อยุค) ผู้ตรวจสอบความถูกต้องของ Shard 1.0 ยังลงคะแนนหนึ่งครั้งต่อยุค แต่แต่ละส่วนจะมีการสับเปลี่ยนคณะกรรมการของตนเอง ดังนั้น ชิ้นส่วนแต่ละชิ้นจะได้รับการยืนยันภายใน 1/2048 ของชุดเครื่องมือตรวจสอบเท่านั้น (1/32 แบ่งออกเป็น 64 ชิ้น)

การรวมบล็อกเข้ากับแผนความมุ่งมั่น 2D KZG ยังทำให้ DAS มีประสิทธิภาพมากขึ้น ดังที่ได้กล่าวไว้ก่อนหน้านี้ Sharding 1.0 ต้องการแบนด์วิธ 60 KB/s เพื่อตรวจสอบ DA แบบเต็มของ Shards ทั้งหมด DS ต้องการเพียง 2.5 KB/s

ความเป็นไปได้ที่น่าตื่นเต้นอีกอย่างหนึ่งมีอยู่ใน DS นั่นคือการเรียกแบบซิงโครนัสระหว่าง ZK-rollups และการดำเนินการ L1 Ethereum ธุรกรรมจาก shard blobs สามารถยืนยันและเขียนไปยัง L1 ได้ทันที เนื่องจากทุกอย่างถูกสร้างขึ้นในบล็อกเชนบีคอนเดียวกัน Sharding 1.0 จะขจัดความเป็นไปได้นี้เนื่องจากการยืนยันชิ้นส่วนแยกต่างหาก สิ่งนี้ทำให้มีพื้นที่การออกแบบที่น่าตื่นเต้น ซึ่งมีประโยชน์สำหรับการเคลื่อนย้ายที่ใช้ร่วมกัน (เช่น

) และสิ่งที่คล้ายกันสามารถมีค่ามาก

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

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

เป็นไปได้อย่างแน่นอนที่ปริมาณงานของ DA จะเกินกว่าที่คาดการณ์ไว้ที่นี่ แต่เป็นการยากที่จะบอกว่าค่าสูงสุดนี้จะสิ้นสุดที่จุดใด ไม่มีเส้นสีแดงที่ชัดเจน แต่บริเวณที่สมมติฐานบางอย่างเริ่มรู้สึกอึดอัด:

Proto-danksharding (EIP-4844)

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

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

โปรดทราบว่าตัวสร้างไม่ใช่คอขวด คุณต้องสร้างการพิสูจน์ KZG อย่างรวดเร็วสำหรับข้อมูล 32 MB ดังนั้น GPU หรือ CPU ที่ทรงพลังพอสมควรที่มีแบนด์วิดท์อย่างน้อย 2.5 GBit/s จึงเป็นสิ่งจำเป็น ไม่ว่าจะเป็นบทบาทเฉพาะทางและเป็นต้นทุนทางธุรกิจเล็กน้อยสำหรับพวกเขา

DS นั้นยอดเยี่ยม แต่เราต้องอดทน PDS ได้รับการออกแบบมาเพื่อรองรับเรา - ใช้ขั้นตอนความเข้ากันได้ล่วงหน้าที่จำเป็นสำหรับ DS บนไทม์ไลน์ที่เร่งขึ้น (สำหรับ Shanghai hard fork) เพื่อจัดเตรียมลำดับความสำคัญในระหว่างนี้ อย่างไรก็ตาม มันไม่ได้ใช้งาน data sharding จริง ๆ (เช่น ตัวตรวจสอบจำเป็นต้องดาวน์โหลดข้อมูลทั้งหมดทีละรายการ)

Rollups วันนี้ใช้ L1 "calldata" สำหรับการจัดเก็บซึ่งอยู่บนเครือข่ายตลอดไป อย่างไรก็ตาม Rollup ต้องการ DA ในระยะเวลาที่เหมาะสมเท่านั้น เพื่อให้ทุกคนที่สนใจมีเวลาเพียงพอในการดาวน์โหลด

EIP-4844 นำเสนอรูปแบบธุรกรรมใหม่ที่รองรับ blobs และ Rollup จะใช้สำหรับการจัดเก็บข้อมูลในอนาคต Blobs มีข้อมูลจำนวนมาก (ประมาณ 125 KB) และมีราคาถูกกว่า calldata ในจำนวนที่ใกล้เคียงกันมาก จากนั้นบล็อกข้อมูลจะถูกลบออกจากโหนดหลังจากผ่านไปหนึ่งเดือน ซึ่งช่วยลดความต้องการในการจัดเก็บ นี่เป็นเวลาเพียงพอที่จะตอบสนองสมมติฐานด้านความปลอดภัยของ DA ของเรา

บล็อก Ethereum ปัจจุบันโดยทั่วไปมีขนาดเฉลี่ยประมาณ 90 KB (ซึ่งข้อมูลการโทรอยู่ที่ประมาณ 10 KB) PDS ปลดล็อกแบนด์วิดท์ DA มากขึ้นสำหรับ Blob (เป้าหมาย ~1 MB และสูงสุด ~2 MB) เมื่อถูกตัดออกหลังจากผ่านไปหนึ่งเดือน พวกมันจะไม่กลายเป็นตัวลากบนโหนดอย่างถาวร

หยดเป็นเวกเตอร์ขององค์ประกอบฟิลด์ 4096 แต่ละองค์ประกอบฟิลด์คือ 32 ไบต์ PDS อนุญาตสูงสุด 16 ต่อบล็อก ในขณะที่ DS จะเพิ่มเป็น 256

แบนด์วิดท์ PDS DA = 4096 x 32 x 16 = 2 MiB ต่อบล็อกโดยมีเป้าหมาย 1 MiB

• แบนด์วิดท์ DS DA = 4096 x 32 x 256 = 32 MiB ต่อบล็อกโดยมีเป้าหมาย 16 MiB

• รูปแบบการทำธุรกรรมสำหรับการพกพา data blobs

• ตรรกะเลเยอร์การดำเนินการทั้งหมดที่จำเป็นโดย DS

• ตรรกะการตรวจสอบข้ามการดำเนินการ/ฉันทามติทั้งหมดที่จำเป็นโดย DS

• ความมุ่งมั่นของ KZG ต่อ blobs

• ตรรกะเลเยอร์การดำเนินการทั้งหมดที่จำเป็นโดย DS

• ตรรกะการตรวจสอบข้ามการดำเนินการ/ฉันทามติทั้งหมดที่จำเป็นโดย DS

การแยกชั้นระหว่างการรับรองความถูกต้อง BeaconBlock และ DAS blobs

• PBS

• ตรรกะ BeaconBlock ส่วนใหญ่ที่ DS ต้องการ

• ราคาก๊าซอิสระที่ปรับเองได้สำหรับ blobs (EIP-1559 แบบหลายมิติพร้อมกฎการกำหนดราคาแบบเอ็กซ์โปเนนเชียล)

• DS แล้วเพิ่มเติม:

ระบบเก็บข้อมูล

รูปแบบ 2D KZG

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

โปรดทราบว่า data blobs เหล่านี้ถูกนำมาใช้เป็นประเภทธุรกรรมใหม่ในห่วงโซ่การดำเนินการ แต่ไม่มีข้อกำหนดเพิ่มเติมในด้านการดำเนินการ EVM ดูเฉพาะข้อผูกมัดที่แนบมากับ blobs การเปลี่ยนแปลงเลเยอร์การใช้งานที่ทำโดยใช้ EIP-4844 ยังเข้ากันได้กับ DS อีกด้วย และไม่จำเป็นต้องทำการเปลี่ยนแปลงเพิ่มเติมในเรื่องนี้ จากนั้นการอัปเกรดจาก PDS เป็น DS จะต้องเปลี่ยนชั้นฉันทามติเท่านั้น

• Data Blob ถูกดาวน์โหลดอย่างสมบูรณ์โดยไคลเอนต์ที่สอดคล้องกันใน PDS ตอนนี้ blob ถูกอ้างอิงในเนื้อหาของบล็อก Beacon แต่ไม่ได้เข้ารหัสอย่างสมบูรณ์ แทนที่จะฝังเนื้อหาทั้งหมดในร่างกาย เนื้อหาของ Blob จะถูกเผยแพร่แยกกันโดยเป็น "รถเสริม" แต่ละบล็อกมี blob sidecar ที่ดาวน์โหลดอย่างสมบูรณ์ใน PDS จากนั้นใช้ตัวตรวจสอบ DS จะดำเนินการ DAS บนนั้น

• ก่อนหน้านี้เราได้กล่าวถึงวิธีการคอมมิต blobs โดยใช้การคอมมิตแบบพหุนามของ KZG อย่างไรก็ตาม แทนที่จะใช้ KZG โดยตรง EIP-4844 จะใช้สิ่งที่เราใช้จริง นั่นคือแฮชเวอร์ชันของมัน นี่คือ 0x01 ไบต์ (แทนเวอร์ชันนี้) ตามด้วย 31 ไบต์สุดท้ายของแฮช SHA256 ของ KZG

เราทำสิ่งนี้เพื่อความเข้ากันได้ของ EVM และความเข้ากันได้แบบส่งต่อที่ง่ายขึ้น:

ความเข้ากันได้ของ EVM – ข้อผูกพัน KZG คือ 48 ไบต์ ในขณะที่ EVM ใช้ค่า 32 ไบต์ตามธรรมชาติมากกว่า

ความเข้ากันได้แบบส่งต่อ - หากเราเปลี่ยนจาก KZG เป็นอย่างอื่น (สามารถใช้ STARK สำหรับการต้านทานควอนตัม) สัญญาเหล่านี้สามารถดำเนินการต่อไปได้ 32 ไบต์

ในที่สุด PDS จะสร้างชั้นข้อมูลที่กำหนดเอง - data blobs จะมีตลาดค่าธรรมเนียมเฉพาะของตนเองพร้อมราคาก๊าซลอยตัวและขีดจำกัดแต่ละรายการ ดังนั้นแม้ว่าโครงการ NFT บางโครงการจะขายที่ดินลิงจำนวนมากบน L1 ก็ตาม ต้นทุนข้อมูลค่าสะสมของคุณจะไม่เพิ่มขึ้น (แม้ว่าค่าใช้จ่ายในการพิสูจน์หลักฐานจะตกลง) นี่เป็นการรับทราบว่าค่าใช้จ่ายหลักของการยกเลิกในวันนี้คือการเผยแพร่ข้อมูลไปยัง L1 (ไม่ใช่การพิสูจน์)ตลาดค่าน้ำมันยังคงเหมือนเดิม data blobs ถูกเพิ่มเป็นตลาดใหม่:ค่าธรรมเนียมหยดจะเรียกเก็บเป็นก๊าซ แต่เป็นการปรับจำนวนที่ผันแปรตามกลไก EIP-1559 ของมันเอง จำนวนเฉลี่ยระยะยาวของ blobs ต่อบล็อกควรเท่ากับเป้าหมาย

คุณมีการประมูลสองรายการที่ทำงานพร้อมกัน หนึ่งรายการสำหรับการคำนวณและอีกรายการหนึ่งสำหรับ DA สิ่งนี้ใช้ได้

ราคาทรัพยากร

กระโดดยักษ์

• นี่คือการออกแบบที่น่าสนใจ ตัวอย่างเช่น การเปลี่ยนกลไกการกำหนดราคาก๊าซและหยดในปัจจุบันจาก EIP-1559 เชิงเส้นไปเป็นกลไก EIP-1559 แบบเอ็กซ์โปเนนเชียลแบบใหม่อาจสมเหตุสมผล การใช้งานปัจจุบันไม่ได้เฉลี่ยตามขนาดบล็อกเป้าหมายในทางปฏิบัติ วันนี้ ค่าธรรมเนียมพื้นฐานยังไม่คงที่เต็มที่ ทำให้ก๊าซเฉลี่ยที่สังเกตได้ที่ใช้ต่อบล็อกสูงกว่าเป้าหมายโดยเฉลี่ยประมาณ 3%

• ส่วนที่ II: ประวัติศาสตร์และการจัดการรัฐ

สรุปข้อมูลพื้นฐานบางส่วนโดยย่อที่นี่:

ประวัติศาสตร์ — ทุกสิ่งที่เกิดขึ้นบนเครือข่าย คุณสามารถติดไว้ในฮาร์ดไดรฟ์ได้เนื่องจากไม่ต้องการการเข้าถึงที่รวดเร็ว ในระยะยาวถือว่ามีความซื่อสัตย์ 1 ใน N

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

การลดต้นทุน Calldata Gas และขีดจำกัด Calldata ทั้งหมด (EIP-4488)

EIP-4488 มีสององค์ประกอบหลัก:

• PDS เป็นก้าวสำคัญสู่ DS และตรวจสอบข้อกำหนดขั้นสุดท้ายหลายประการ การนำ PDS ไปใช้ภายในระยะเวลาที่เหมาะสมสามารถเลื่อนไทม์ไลน์บน DS ได้

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

EIP-4488 มีสององค์ประกอบหลัก:

ลดต้นทุนข้อมูลการโทรจาก 16 แก๊สต่อไบต์เป็น 3 แก๊สต่อไบต์

เพิ่มขีดจำกัดของข้อมูลการโทร 1 MB ต่อบล็อก และเพิ่มอีก 300 ไบต์ต่อธุรกรรม (สูงสุดตามทฤษฎีคือประมาณ 1.4 MB)

จำเป็นต้องเพิ่มขีดจำกัดเพื่อป้องกันกรณีที่เลวร้ายที่สุด - บล็อกที่เต็มไปด้วยข้อมูลการโทรจะสูงถึง 18 MB ซึ่งเกินกว่าที่ Ethereum จะรับมือได้ EIP-4488 เพิ่มความจุข้อมูลเฉลี่ยของ Ethereum แต่เนื่องจากขีดจำกัด calldata นี้ (30 ล้าน gas / 16 gas ต่อ calldata byte = 1.875 MB) ความจุข้อมูลการระเบิดจะลดลงเล็กน้อย

โหลดที่ต่อเนื่องของ EIP-4488 นั้นสูงกว่า PDS มาก เนื่องจากยังคงเป็น calldata และ blob ซึ่งเป็นข้อมูลที่สามารถตัดได้หลังจากผ่านไปหนึ่งเดือน EIP-4488 จะเร่งการเติบโตในอดีตอย่างมีนัยสำคัญ ทำให้เป็นคอขวดสำหรับรันโหนด แม้ว่าจะใช้ EIP-4444 ควบคู่กับ EIP-4488 การดำเนินการนี้จะลบประวัติการโหลดการดำเนินการหลังจากหนึ่งปีเท่านั้น โหลดอย่างต่อเนื่องที่ต่ำกว่าบน PDS เป็นที่ต้องการอย่างชัดเจน

ผูกข้อมูลประวัติในไคลเอนต์การดำเนินการ (EIP-4444)

EIP-4444 อนุญาตให้ไคลเอ็นต์เลือกตัดข้อมูลประวัติภายในเครื่อง (ส่วนหัว เนื้อหา และใบเสร็จ) ที่เก่ากว่าหนึ่งปี ไคลเอ็นต์ต้องหยุดให้บริการข้อมูลประวัติที่ตัดแล้วบนเลเยอร์ p2p ประวัติการตัดช่วยให้ลูกค้าลดความต้องการพื้นที่เก็บข้อมูลดิสก์ของผู้ใช้ (ปัจจุบันหลายร้อยกิกะไบต์และกำลังเพิ่มขึ้น)devp2pสิ่งนี้มีความสำคัญอยู่แล้ว แต่หากมีการใช้งาน EIP-4488 (เนื่องจากประวัติศาสตร์เติบโตขึ้นอย่างมาก) ก็จะกลายเป็นข้อบังคับส่วนใหญ่ อย่างไรก็ตาม หวังว่าการดำเนินการนี้จะเสร็จสิ้นในเร็วๆ นี้ ในที่สุดจะต้องมีการหมดอายุในอดีตบางรูปแบบ ดังนั้นนี่เป็นเวลาที่ดีในการจัดการกับมัน

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

ลูกค้าจะไม่สามารถใช้ปัจจุบันได้

ทำ "การซิงค์แบบเต็ม" - พวกเขาจะแทนที่ "การซิงค์จุดตรวจสอบ" จากจุดตรวจสอบความเป็นส่วนตัวที่อ่อนแอ ซึ่งพวกเขามองว่าเป็นบล็อกการกำเนิด

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

• สิ่งนี้จะลดการใช้แบนด์วิธบนเครือข่าย เนื่องจากไคลเอ็นต์จำนวนมากขึ้นเรื่อยๆ ใช้กลยุทธ์การซิงค์แบบไลท์เวท

• ดึงข้อมูลประวัติ

• EIP-4444 การตัดข้อมูลย้อนหลังหลังจากผ่านไปหนึ่งปีฟังดูดี ในขณะที่ PDS จะตัด blobs เร็วขึ้น (หลังจากผ่านไปประมาณหนึ่งเดือน) เราต้องการสิ่งเหล่านี้อย่างยิ่งเพราะเราไม่สามารถขอให้โหนดจัดเก็บทั้งหมดและกระจายอำนาจ:

EIP-4488 – ระยะยาวน่าจะรวมประมาณ 1 MB ต่อสล็อต เพิ่มพื้นที่เก็บข้อมูลประมาณ 2.5 TB ต่อปี

DS – กำหนดเป้าหมาย ~16 MB ต่อช่อง เพิ่มพื้นที่เก็บข้อมูลประมาณ 40 TB ต่อปี

• อาสาสมัครรายบุคคลและสถาบัน

• แต่ข้อมูลไปไหน? เราไม่ต้องการมันอีกแล้วเหรอ? ได้ แต่โปรดทราบว่าการสูญเสียข้อมูลประวัตินั้นไม่เป็นอันตรายต่อโปรโตคอล - เฉพาะกับแอปพลิเคชันเดียวเท่านั้น ดังนั้นงานของโปรโตคอลหลักของ Ethereum จึงไม่ควรรักษาข้อมูลที่เป็นเอกฉันท์ทั้งหมดตลอดไป

• แล้วใครจะเก็บ? นี่คือผู้มีส่วนร่วมบางส่วน:

• อาสาสมัครรายบุคคลและสถาบัน

• Block explorers (เช่น etherscan.io) ผู้ให้บริการ API และบริการข้อมูลอื่นๆ

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

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

ตัวอย่างเช่น BitTorrent ไฟล์ขนาด 7 GB ถูกสร้างขึ้นโดยอัตโนมัติและแจกจ่ายทุกวันซึ่งมีข้อมูลหยดจากบล็อก

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

ปัญหาการจัดเก็บข้อมูลระยะยาวนั้นค่อนข้างง่ายเนื่องจากสมมติฐานความน่าเชื่อถือ 1 ใน N ที่เรากล่าวถึงก่อนหน้านี้ เรายังเหลืออีกหลายปีจากการเป็นขีด จำกัด สูงสุดของความสามารถในการปรับขนาดของ blockchain

ไร้สัญชาติอ่อนแอ

โอเค เรามีการจัดการประวัติค่อนข้างดี แล้วรัฐล่ะ ปัญหาสถานะเป็นคอขวดหลักในการปรับปรุง TPS ของ Ethereum ในปัจจุบัน

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

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

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

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

• ลองมาเป็นตัวอย่าง อลิซต้องการส่ง 1 ETH ให้ Bob ในการตรวจสอบการบล็อกด้วยธุรกรรมนี้ ฉันจำเป็นต้องทราบ:

• ก่อนการทำธุรกรรม - อลิซมี 1 ETH

กุญแจสาธารณะของอลิซ - เพื่อให้ฉันรู้ว่าลายเซ็นนั้นถูกต้อง

อลิซไม่มีเหตุผล - ดังนั้นฉันจึงรู้ว่าธุรกรรมถูกส่งไปตามลำดับที่ถูกต้อง

• หลังจากทำธุรกรรม - Bob ได้รับ 1 ETH, Alice เสีย 1 ETH

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

• นี่คือความหมายจากมุมมองของผู้ตรวจสอบความถูกต้อง:

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

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

Verkle Tries

คุณยังคงทำธุรกรรมเพื่อตรวจสอบความถูกต้องอย่างสมบูรณ์ การไร้สัญชาติยอมรับว่าปัจจุบันนี้ไม่ใช่คอขวดในการปรับขนาด Ethereum

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

การดำเนินการของผู้ใช้ส่วนใหญ่จะอยู่ที่ L2 อยู่แล้ว แต่ปริมาณงาน L1 ที่สูงกว่าก็ยังเป็นประโยชน์สำหรับพวกเขา การสะสมขึ้นอยู่กับ Ethereum สำหรับ DA (เผยแพร่ไปยังเศษ) และการชำระเงิน (ต้องใช้การดำเนินการ L1) เมื่อ Ethereum ขยายเลเยอร์ DA ออกไป ต้นทุนการตัดจำหน่ายในการออกหลักฐานมีแนวโน้มที่จะกลายเป็นส่วนแบ่งที่มากขึ้นของต้นทุนการยกเลิก (โดยเฉพาะอย่างยิ่งสำหรับ ZK-rollups)

เราสรุปได้ว่าประจักษ์พยานเหล่านี้ใช้งานได้จริงอย่างไร ปัจจุบัน Ethereum ใช้ต้นไม้ Merkle-Patricia เพื่อเป็นตัวแทนของรัฐ แต่การพิสูจน์ที่จำเป็นของ Merkle นั้นใหญ่เกินไปที่จะนำไปใช้ได้จริงสำหรับพยานเหล่านี้

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

ก่อนอื่นเรามาทบทวนว่าต้นไม้ Merkle มีลักษณะอย่างไร ทุกธุรกรรมถูกแฮช - แฮชเหล่านี้ที่ด้านล่างเรียกว่า "leave" แฮชทั้งหมดเรียกว่า "โหนด" ซึ่งเป็นแฮชของโหนด "ลูก" สองโหนดด้านล่าง แฮชสุดท้ายที่ได้คือ "Merkle root"

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

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

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

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

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

ในความเป็นจริง เราได้กล่าวถึงตัวอย่างที่ดีของหนึ่งในความเป็นไปได้เหล่านี้ก่อนหน้านี้ - ข้อผูกพันของ KZG สามารถใช้เป็นข้อผูกมัดเวกเตอร์ได้ อันที่จริงแล้ว นี่คือสิ่งที่ผู้พัฒนา ethereum วางแผนไว้ตั้งแต่แรกว่าจะใช้ที่นี่ ตั้งแต่นั้นมาพวกเขาก็หันไปหา Pedersen เพื่อทำหน้าที่ที่คล้ายกัน สิ่งเหล่านี้จะขึ้นอยู่กับเส้นโค้งวงรี (ในกรณีนี้ Bandersnatch) และแต่ละค่าจะส่ง 256 ค่า (ดีกว่าสองมาก!)

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

สถานะหมดอายุ

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

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

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

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

• ส่วนที่ III - MEV

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

การออกแบบบล็อกเชนด้วย MEV มีความสำคัญต่อการรักษาความปลอดภัยและการกระจายอำนาจ วิธีการระดับโปรโตคอลพื้นฐานคือ:

ลด MEV ที่เป็นอันตรายให้เหลือน้อยที่สุด (เช่น single slot Finality การเลือกผู้นำแบบลับๆ เดียว)

ทำให้ส่วนที่เหลือเป็นประชาธิปไตย (เช่น MEV-Boost, PBS, MEV smoothing)

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

ห่วงโซ่อุปทานของ MEV ในปัจจุบัน

ลำดับเหตุการณ์ในวันนี้มีดังนี้

MEV-Boost

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

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

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

น่าเสียดายที่ PBS ในข้อตกลงไม่พร้อมสำหรับการควบรวมกิจการ Flashbots เสนอวิธีแก้ปัญหาขั้นบันไดอีกครั้ง - MEV-Boost

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

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

MEV Seekers จะยังคงทำงานในลักษณะเดียวกับที่ทำอยู่ในปัจจุบัน พวกเขาจะดำเนินกลยุทธ์เฉพาะ (การเก็งกำไรทางสถิติ การเก็งกำไรปรมาณู แซนวิช ฯลฯ) และเสนอราคาในชุดของพวกเขา จากนั้นผู้สร้างจะรวมบันเดิลทั้งหมดที่พวกเขาเห็น รวมถึงสตรีมคำสั่งซื้อส่วนตัวใดๆ (เช่น จาก Flashbots Protect) ลงในบล็อกเต็มรูปแบบที่ดีที่สุด ผู้สร้างจะส่งส่วนหัวของบล็อกไปยังตัวตรวจสอบผ่านรีเลย์ที่รันไปยัง MEV-Boost เท่านั้น Flashbots ตั้งใจที่จะเรียกใช้ตัวส่งต่อและตัวสร้าง และวางแผนที่จะกระจายอำนาจเมื่อเวลาผ่านไป แต่มันอาจจะช้าในการอนุญาตพิเศษให้กับตัวสร้างรายอื่น

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

การปรับ MEV ที่ขับเคลื่อนโดยคณะกรรมการ

นอกจากนี้ PBS ยังเปิดประตูสู่แนวคิดดีๆ อีกประการหนึ่ง --

การปรับ MEV ที่ขับเคลื่อนโดยคณะกรรมการ

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

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

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

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

จบการทำธุรกรรมช่องเดียว

การจบอย่างรวดเร็วนั้นยอดเยี่ยมมาก การรอประมาณ 15 นาทีไม่เหมาะสำหรับ UX หรือการสื่อสารข้ามสาย ที่สำคัญกว่านั้น สิ่งนี้สร้างปัญหาในการประกอบชิ้นส่วน MEV ใหม่

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

ฉันจะไม่อาศัยกลไกพื้นฐานที่นี่มากเกินไป Single slot Finality ได้รับการพัฒนาไปไกลมากในแผนงานของ Ethereum และเป็นพื้นที่การออกแบบที่เปิดกว้างมากที่นี่ในโปรโตคอลที่เป็นเอกฉันท์ในปัจจุบัน (โดยไม่มีการสิ้นสุดของสล็อต) Ethereum ต้องการเพียง 1/32 ของผู้ตรวจสอบความถูกต้องเพื่อยืนยันแต่ละสล็อต (ประมาณ 12,000 จากประมาณ 380,000 ในปัจจุบัน) การขยายการลงคะแนนประเภทนี้ไปยังชุดเครื่องมือตรวจสอบเต็มรูปแบบที่รวมกับลายเซ็น BLS ในช่องเดียวจะต้องทำงานมากขึ้น สิ่งนี้จะรวมคะแนนเสียงหลายแสนคะแนนไว้ในการตรวจสอบเดียว:

Vitalik อยู่ที่

ที่นี่

แยกวิธีแก้ปัญหาที่น่าสนใจ

การเลือกตั้งผู้นำเดี่ยวแบบลับๆ (SSLE)

SSLE พยายามแพตช์เวกเตอร์โจมตี MEV อื่นที่เราจะต้องเจอหลังจากการควบรวมกิจการ

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

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

สมมติว่าคุณเป็นผู้เสนอบล็อก n และฉันเป็นผู้เสนอบล็อก n+1 ถ้าฉันรู้ที่อยู่ IP ของคุณ ฉันสามารถ DDOS ให้คุณในราคาถูก เพื่อให้คุณหมดเวลาและไม่สามารถสร้างบล็อกของคุณได้ ตอนนี้ฉันสามารถจับ MEV ของสล็อตของเราและเพิ่มรางวัลเป็นสองเท่าได้แล้ว สิ่งนี้แย่ลงไปอีกเนื่องจากขนาดบล็อกยืดหยุ่นของ EIP-1559 (ก๊าซสูงสุดต่อบล็อกสองเท่าของขนาดเป้าหมาย) ดังนั้นฉันจึงสามารถยัดธุรกรรมที่ควรจะเป็นสองบล็อกลงในบล็อกเดียวได้นานเป็นสองเท่า

ส่วนที่สี่ - การควบรวมกิจการ

ไคลเอนต์ที่ผสาน

เพื่อให้ชัดเจนว่าฉันล้อเล่น ฉันคิดว่า (หวังว่า) การควบรวมกิจการของ Ethereum จะเกิดขึ้นค่อนข้างเร็ว

• เราทุกคนกำลังพูดถึงหัวข้อนี้ ดังนั้นฉันจึงรู้สึกว่าจำเป็นต้องแนะนำสั้นๆ

• ไคลเอนต์ที่ผสาน

วันนี้ คุณเรียกใช้ไคลเอนต์ขนาดใหญ่ที่จัดการทุกอย่าง (เช่น Go Ethereum, Nethermind เป็นต้น) โดยเฉพาะอย่างยิ่ง โหนดเต็มดำเนินการต่อไปนี้พร้อมกัน:

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

ฉันทามติ - ยืนยันว่าคุณอยู่ในเครือข่ายที่หนักที่สุด (PoW สูงสุด) ที่ทำงานได้มากที่สุด (เช่น ฉันทามติของ Satoshi)

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

• ขณะนี้ beacon chain กำลังเรียกใช้ฉันทามติเพื่อให้ PoS ทดสอบการทำงานเท่านั้น ไม่รวมการดำเนินการ ความยากสุดท้ายทั้งหมดจะถูกกำหนด ณ จุดนั้นบล็อกการดำเนินการ Ethereum ในปัจจุบันจะถูกรวมเข้ากับบล็อกเชนบีคอนเพื่อสร้างเชน:

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

Execution Client (หรือที่เรียกว่า "Eth1 Client") - ไคลเอนต์ Eth 1.0 ปัจจุบันดำเนินการประมวลผลต่อไป พวกเขาประมวลผลบล็อก บำรุงรักษาพูลหน่วยความจำ จัดการและซิงโครไนซ์สถานะ ส่วน PoW ถูกฉีกออก

Consensus Client (หรือที่เรียกว่า "Eth2 Client") - ไคลเอนต์ beacon chain ในปัจจุบันที่ดำเนินการประมวลผลฉันทามติ PoS ต่อไป พวกเขาคอยติดตามหัวหน้าเครือข่าย ซุบซิบและรับรองการบล็อก และรับรางวัลผู้ตรวจสอบความถูกต้อง

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

หรือ:

ฉันทามติหลังการควบรวมกิจการ

Ethereum ที่ผสานได้ย้ายไปที่ GASPER ซึ่งเป็นการรวมกันของ Casper FFG (เครื่องมือขั้นสุดท้าย) และ LMD GHOST (กฎการเลือกทางแยก) เพื่อฉันทามติ TLDR ที่นี่ - เป็นความมีชีวิตชีวาที่สนับสนุนฉันทามติ ไม่ใช่ความปลอดภัย

สรุปแล้ว

ความแตกต่างคืออัลกอริธึมที่สอดคล้องกันซึ่งเป็นมิตรกับความปลอดภัย (เช่น Tendermint) จะหยุดทำงานเมื่อไม่ได้รับคะแนนโหวตตามจำนวนที่กำหนด (ในที่นี้ตั้งค่าเป็น 2/3 ของผู้ตรวจสอบความถูกต้อง) ความมีชีวิตชีวาของห่วงโซ่ที่ดี (เช่น PoW + ฉันทามติของ Nakamoto) จะยังคงสร้างบัญชีแยกประเภทในแง่ดีต่อไป แต่จะไม่สามารถบรรลุผลสุดท้ายได้หากไม่มีคะแนนเสียงเพียงพอ Bitcoin และ Ethereum ในปัจจุบันยังไม่สิ้นสุด - คุณเพียงแค่คิดว่าการ reorgs จะไม่เกิดขึ้นหลังจากจำนวนบล็อกที่เพียงพอ

อย่างไรก็ตาม Ethereum จะบรรลุจุดสิ้นสุดผ่านจุดตรวจปกติด้วยคะแนนเสียงที่เพียงพอ แต่ละอินสแตนซ์ 32 ETH เป็นตัวตรวจสอบเดียว และมีตัวตรวจสอบเชนบีคอนมากกว่า 380,000 ตัว ยุคประกอบด้วย 32 สล็อต โดยตัวตรวจสอบทั้งหมดแยกและยืนยันสล็อตภายในยุคที่กำหนด (หมายถึง ~ 12,000 พิสูจน์ต่อสล็อต) กฎการเลือกทางแยก LMD Ghost จะกำหนดส่วนหัวปัจจุบันของโซ่ตามหลักฐานเหล่านี้ บล็อกใหม่จะถูกเพิ่มทุกช่อง (12 วินาที) ดังนั้นช่วงเวลาคือ 6.4 นาที มักจะบรรลุผลสำเร็จหลังจากสองยุค (นั่นคือ 64 ช่อง แม้ว่าอาจต้องการมากถึง 95 ช่อง) ด้วยการโหวตที่จำเป็น