ผู้เขียน: จอน ชาร์บอนโน
ชื่อเดิม: The Hitchhiker's Guide to Ethereum
ประเด็นหลัก:
Ethereum เป็นโปรโตคอลหลักเพียงตัวเดียวที่มีจุดมุ่งหมายเพื่อสร้างการตั้งถิ่นฐานแบบครบวงจรที่ปรับขนาดได้และชั้นความพร้อมใช้งานของข้อมูล
Rollup ขยายขนาดการคำนวณในขณะที่ใช้ประโยชน์จากความปลอดภัยของ Ethereum
ถนนทุกสายนำไปสู่จุดจบของการผลิตบล็อกแบบรวมศูนย์ การตรวจสอบบล็อกแบบไร้ความน่าเชื่อถือแบบกระจายอำนาจ และการต่อต้านการเซ็นเซอร์
นวัตกรรม เช่น การแยกผู้ริเริ่ม-ผู้สร้าง และการไร้สัญชาติที่อ่อนแอ ซึ่งนำมาซึ่งการแยกอำนาจ (การสร้างและการตรวจสอบ) ที่สามารถบรรลุความสามารถในการขยายขนาดโดยไม่ต้องเสียสละความปลอดภัยหรือเป้าหมายการกระจายอำนาจ
ขณะนี้ MEV อยู่ด้านหน้าและตรงกลาง - การออกแบบส่วนใหญ่มีการวางแผนเพื่อลดอันตรายและป้องกันแนวโน้มการรวมศูนย์
Danksharding รวมแนวทางต่างๆ เข้ากับการวิจัยที่ทันสมัยเพื่อให้ชั้นฐานที่ปรับขนาดได้ซึ่งจำเป็นสำหรับแผนงานที่เน้นการรวมศูนย์ของ Ethereum
สารบัญ
สารบัญ
ตอนที่ 1 เส้นทางสู่ Danksharding
การออกแบบการแบ่งส่วนข้อมูลต้นฉบับ - ข้อเสนอการแยกส่วนอิสระ
การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล (DAS)
ความมุ่งมั่นของ KZG
KZG Promise เทียบกับหลักฐานการฉ้อโกง
การแยกผู้ริเริ่มและผู้สร้างภายในโปรโตคอล
รายการต่อต้านการเซ็นเซอร์ (crList)
กลยุทธ์ 2D KZG
Danksharding
Danksharding - การยืนยันเสียงข้างมากโดยสุจริต
Danksharding - การสร้างใหม่
Danksharding - ความปลอดภัยส่วนใหญ่ที่เป็นอันตรายพร้อมการสุ่มตัวอย่างส่วนตัว
Danksharding - บทสรุปที่สำคัญ
Danksharding——ข้อจำกัดในการขยายตัวของ Blockchain
Danksharding พื้นเมือง (EIP-4844)
EIP-1559 หลายมิติ
ส่วนที่ 2 ประวัติศาสตร์กับการจัดการรัฐ
การลดต้นทุนก๊าซข้อมูลการโทรและขีดจำกัดข้อมูลการโทรทั้งหมด (EIP-4488)
ตรวจสอบข้อมูลประวัติในไคลเอนต์การดำเนินการ (EIP-4444)
กู้คืนข้อมูลทางประวัติศาสตร์
ภาวะไร้สัญชาติที่อ่อนแอ
Verkle พยายาม (พยายาม Verkle)
สถานะหมดอายุ
ตอนที่ 3 ทุกอย่างเป็นความผิดของ MEV
ห่วงโซ่อุปทานของ MEV ในปัจจุบัน
MEV-Boost
คณะกรรมการขับเคลื่อนการปรับเรียบ MEV
ตอนจบช่องเดียว
การเลือกตั้งผู้นำลับเดี่ยว
ตอนที่ 4 ความลับของการควบรวมกิจการ
ไคลเอนต์ที่ผสาน
การแนะนำ
การแนะนำ
ฉันค่อนข้างสงสัยเกี่ยวกับช่วงเวลาของการควบรวมกิจการตั้งแต่ Vitalik กล่าวว่าคนที่เกิดวันนี้มีโอกาส 50-75% ที่จะมีชีวิตอยู่ถึง 3,000 AD และเขาหวังว่าจะมีชีวิตอยู่ตลอดไป แต่ไม่ว่าอย่างไรก็ตาม มาสนุกกันเถอะ ใช้โอกาสนี้ดูแผนงานที่ทะเยอทะยานของ Ethereum ให้ละเอียดยิ่งขึ้น
บทความนี้ไม่ควรมองข้าม หากคุณต้องการดูแผนงานที่ทะเยอทะยานของ Ethereum แบบกว้างและเหมาะสม ให้เวลาฉันหนึ่งชั่วโมง แล้วฉันจะช่วยคุณประหยัดเวลาทำงานหลายเดือน
บทความนี้ไม่ควรมองข้าม หากคุณต้องการดูแผนงานที่ทะเยอทะยานของ Ethereum แบบกว้างและเหมาะสม ให้เวลาฉันหนึ่งชั่วโมง แล้วฉันจะช่วยคุณประหยัดเวลาทำงานหลายเดือน
มีหลายสิ่งที่ต้องติดตามในการวิจัย Ethereum แต่ทั้งหมดเชื่อมโยงกันเป็นเป้าหมายที่ครอบคลุมเพียงหนึ่งเดียว นั่นคือการปรับขนาดการคำนวณโดยไม่ต้องเสียสละการตรวจสอบแบบกระจายอำนาจ
Vitalik มีคำพูด "endgame" ที่โด่งดัง ฉันไม่รู้ว่าคุณเคยได้ยินไหม เขายอมรับว่าการปรับขนาด ethereum จำเป็นต้องมีการรวมศูนย์ ในบล็อกเชน ตัวอักษร C สำหรับการรวมศูนย์นั้นน่ากลัว แต่มันคือความจริง เราเพียงแค่ต้องควบคุมอำนาจนี้ด้วยการตรวจสอบแบบกระจายอำนาจและไร้ความน่าเชื่อถือ ไม่มีการประนีประนอมที่นี่
ผู้เชี่ยวชาญจะเพิ่ม L1 และอื่น ๆ Ethereum ยังคงปลอดภัยอย่างเหลือเชื่อด้วยการตรวจสอบแบบกระจายศูนย์อย่างง่าย ในขณะที่การยกเลิกจะสืบทอดความปลอดภัยมาจาก L1 จากนั้น Ethereum จะให้การตั้งถิ่นฐานและความพร้อมใช้งานของข้อมูล ทำให้สามารถปรับขนาดได้ การวิจัยทั้งหมดในที่นี้มุ่งเป้าไปที่การปรับบทบาททั้งสองนี้ให้เหมาะสมที่สุด และในขณะเดียวกันก็ช่วยให้การตรวจสอบบล็อคเชนทั้งหมดง่ายขึ้นกว่าที่เคย
คำต่อไปนี้ซ้ำประมาณเจ็ดหรือแปดห้าสิบเก้าครั้ง:
DA – ความพร้อมใช้งานของข้อมูล ความพร้อมใช้งานของข้อมูล
DAS – การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล
PBS – ผู้ริเริ่มการแยกผู้เสนอและผู้ริเริ่มและการแยกผู้สร้าง
PDS – ดาร์กชาร์ดแบบเนทีฟ Proto-danksharding
DS – Danksharding การออกแบบการแบ่งส่วนของ Ethereum
PoW – หลักฐานยืนยันภาระงาน
PoS – หลักฐานการจำนำหลักฐานการเดิมพัน
ตอนที่ 1 เส้นทางสู่ Danksharding
หวังว่าคุณจะเคยได้ยินว่า Ethereum ได้เปลี่ยนไปใช้แผนการทำงานแบบโรลอัปเป็นศูนย์กลาง ไม่มีเศษการประมวลผลอีกต่อไป - Ethereum จะปรับให้เหมาะสมสำหรับการยกเลิกการใช้ข้อมูลแทน สิ่งนี้ทำได้โดยการแบ่งส่วนข้อมูล (แผนเล็กน้อยของ Ethereum) หรือบล็อกที่ใหญ่กว่า (แผนของ Celestia)
ชั้นฉันทามติไม่ได้ตีความข้อมูลที่แยกส่วน มีเพียงงานเดียวเท่านั้น - ตรวจสอบให้แน่ใจว่าข้อมูลพร้อมใช้งาน
ฉันจะถือว่าคุณคุ้นเคยกับแนวคิดพื้นฐาน เช่น การยกเลิก การฉ้อโกง และการพิสูจน์ ZK และเหตุใด DA (ความพร้อมใช้งานของข้อมูล) จึงมีความสำคัญ หากคุณไม่คุ้นเคยหรือแค่ต้องการทบทวน โปรดดูรายงาน Celestia ล่าสุดของ Can
การออกแบบการแบ่งส่วนข้อมูลต้นฉบับ - ข้อเสนอการแยกส่วนอิสระ
การออกแบบที่อธิบายไว้ที่นี่ล้าสมัย แต่ก็คุ้มค่าที่จะมองหาพื้นหลัง เพื่อความง่าย ฉันจะเรียกมันว่า "sharding 1.0"
แต่ละส่วนจาก 64 ชิ้นมีข้อเสนอส่วนบุคคลและคณะกรรมการที่หมุนเวียนจากชุดผู้ตรวจสอบความถูกต้อง พวกเขาตรวจสอบโดยอิสระว่าข้อมูลในชาร์ดของพวกเขามีอยู่ จะไม่ใช่ DAS (Data Availability Sampling) ในขั้นต้น แต่จะอาศัยชุดเครื่องมือตรวจสอบความถูกต้องของแต่ละชาร์ดส่วนใหญ่เพื่อดาวน์โหลดข้อมูลทั้งหมด
การออกแบบนี้ทำให้เกิดความซับซ้อนที่ไม่จำเป็น ประสบการณ์ของผู้ใช้ที่แย่ลง และเวกเตอร์ของการโจมตี การจัดระเบียบตัวตรวจสอบใหม่ระหว่างเศษส่วนอาจมีความเสี่ยง
นอกจากนี้ยังยากที่จะรับประกันว่าการลงคะแนนเสียงจะทำภายในช่องเดียว เว้นแต่คุณจะตั้งสมมติฐานการซิงโครไนซ์ที่เข้มงวดมาก ข้อเสนอบล็อกบีคอนจำเป็นต้องรวบรวมคะแนนเสียงของคณะกรรมการแต่ละคนทั้งหมด ซึ่งอาจล่าช้าได้
(ในการออกแบบการแบ่งส่วนข้อมูลดั้งเดิม แต่ละส่วนจะได้รับการยืนยันโดยการลงคะแนนเสียงของคณะกรรมการ การลงคะแนนเสียงไม่ได้ทำในช่องเดียวเสมอไป และแต่ละส่วนสามารถยืนยันได้ถึงสองยุค)
DS (Danksharding) แตกต่างอย่างสิ้นเชิง ผู้ตรวจสอบความถูกต้องดำเนินการ DAS โดยยืนยันว่าข้อมูลทั้งหมดมีอยู่ (ไม่มีคณะกรรมการย่อยที่แยกจากกันอีกต่อไป) ตัวสร้างเฉพาะ (ตัวสร้าง) ใช้บล็อก Beacon และข้อมูลที่แยกส่วนทั้งหมดเพื่อสร้างบล็อกขนาดใหญ่และยืนยัน ดังนั้น PBS (การแยกข้อเสนอและตัวสร้าง) จึงเป็นสิ่งจำเป็นสำหรับ DS ที่จะยังคงกระจายอำนาจอยู่ (การสร้างบล็อกขนาดใหญ่ร่วมกันนั้นต้องใช้ทรัพยากรมาก)
การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล (DAS)
Rollups เผยแพร่ข้อมูลจำนวนมาก แต่เราไม่ต้องการสร้างภาระให้กับโหนดในการดาวน์โหลดข้อมูลทั้งหมด สิ่งนี้จะบ่งบอกถึงการจัดสรรทรัพยากรที่สูง ซึ่งจะทำให้การกระจายอำนาจลดลง
แต่ DAS อนุญาตให้โหนด (แม้แต่ไคลเอ็นต์แบบไลท์) ตรวจสอบได้อย่างง่ายดายและปลอดภัยว่าข้อมูลทั้งหมดพร้อมใช้งานโดยไม่ต้องดาวน์โหลดทั้งหมด
วิธีแก้ปัญหาไร้เดียงสา - เพียงตรวจสอบส่วนที่สุ่มจากบล็อก ถ้าไม่มีปัญหาอะไรก็แค่เซ็นก็จบ แต่ถ้าคุณพลาดการทำธุรกรรมที่จะระบาย ETH ทั้งหมดของคุณให้กับคนเลว สิ่งนี้จะปลอดภัยได้ไหม (safu)
วิธีแก้ปัญหาที่ชาญฉลาด - ลบรหัสข้อมูลก่อน ข้อมูลถูกขยายโดยใช้รหัสรีด-โซโลมอน ซึ่งหมายความว่าข้อมูลจะถูกแก้ไขเป็นพหุนาม ซึ่งเราสามารถประเมินได้จากที่อื่น เรื่องนี้ค่อนข้างซับซ้อน ดังนั้นเรามาแยกย่อยกัน
ไม่ต้องกังวลเกี่ยวกับคณิตศาสตร์ของคุณ นี่คือหลักสูตรเร่งรัด (ฉันสัญญาว่าคณิตศาสตร์ไม่ได้น่ากลัวที่นี่ - ฉันต้องดูวิดีโอของ Khan Academy เพื่อเขียนส่วนเหล่านี้ แต่ตอนนี้ฉันเข้าใจแล้ว)
พหุนามคือนิพจน์ที่เกิดจากการบวกของจำนวนจำกัดของพจน์ในแบบฟอร์ม จำนวนคำศัพท์แสดงถึงดัชนีสูงสุด ตัวอย่างเช่น + + - 4 เป็นพหุนามลูกบาศก์ คุณสามารถสร้างพหุนามของดีกรีจากพิกัดใดๆ ที่อยู่ในพหุนามได้
ตอนนี้ดูตัวอย่างที่เป็นรูปธรรม ด้านล่างเรามีบล็อกข้อมูลสี่บล็อก (ถึง) บล็อกข้อมูลเหล่านี้สามารถแมปกับค่าของพหุนาม ณ จุดที่กำหนดได้ ตัวอย่างเช่น =. จากนั้นคุณจะพบพหุนามดีกรีต่ำสุดที่ตรงกับค่าเหล่านี้ เนื่องจากนี่คือบล็อกข้อมูลสี่บล็อก เราจึงสามารถหาพหุนามของลูกบาศก์ได้ จากนั้นเราสามารถขยายข้อมูลนี้ได้โดยการเพิ่มค่าสี่ค่า ( ถึง ) ที่อยู่บนพหุนามเดียวกัน
โปรดจำไว้ว่าคุณสมบัติพหุนามที่สำคัญ - เราสามารถสร้างมันขึ้นมาใหม่จากสี่จุดใดก็ได้ ไม่ใช่แค่สี่ส่วนเดิมของเรา
กลับไปที่ DAS ของเรา ตอนนี้เราแค่ต้องแน่ใจว่าข้อมูลรหัสลบ 50% (4/8) ใช้งานได้ จากนี้ เราสามารถสร้างบล็อคข้อมูลทั้งหมดขึ้นมาใหม่ได้
ดังนั้น ผู้โจมตีจะต้องซ่อนบล็อกข้อมูลมากกว่า 50% เพื่อหลอกโหนด DAS ให้คิดว่าข้อมูลนั้นพร้อมใช้งานเมื่อไม่มีข้อมูล
หลังจากการสุ่มตัวอย่างที่ประสบความสำเร็จหลายครั้ง ความน่าจะเป็นที่ <50% ของข้อมูลมีอยู่น้อยมาก หากเราสุ่มตัวอย่างการลบข้อมูลที่เข้ารหัสสำเร็จ 30 ครั้ง มีความน่าจะเป็น <50% ที่จะใช้งานได้
ความมุ่งมั่นของ KZG
ตกลง เราจึงสร้างกลุ่มตัวอย่างแบบสุ่ม และทั้งหมดก็พร้อมใช้ แต่เรายังมีคำถาม - การลบข้อมูลมีรหัสถูกต้องหรือไม่? มิฉะนั้น ผู้ผลิตบล็อกอาจเพิ่งเพิ่มขยะ 50% เมื่อขยายบล็อก และการสุ่มตัวอย่างของเราก็เสียเวลาเปล่า ในกรณีนี้ เราจะไม่สามารถสร้างข้อมูลขึ้นมาใหม่ได้
โดยปกติแล้ว เราเพียงแต่ส่งข้อมูลจำนวนมากโดยใช้ Merkle root สิ่งนี้มีประโยชน์สำหรับการพิสูจน์การรวมข้อมูลบางอย่างในชุด
อย่างไรก็ตาม เราจำเป็นต้องทราบด้วยว่าข้อมูลต้นฉบับและข้อมูลที่ขยายทั้งหมดอยู่บนพหุนามดีกรีต่ำเดียวกัน แมร์เคิลไม่สามารถพิสูจน์ได้ ดังนั้น หากคุณใช้แผนนี้ คุณต้องมีหลักฐานการฉ้อโกงเพื่อป้องกันข้อผิดพลาดที่อาจเกิดขึ้น
(รากของ Merkle ช่วยให้เราสามารถผูกมัดกับข้อมูลและส่วนขยายของข้อมูลได้ แต่ไม่สามารถบอกเราได้ว่าพวกมันอยู่ในพหุนามดีกรีต่ำเดียวกันหรือไม่)
นักพัฒนาสามารถแก้ปัญหานี้ได้สองทิศทาง:
Celestia กำลังเข้าสู่เส้นทางพิสูจน์การฉ้อโกง แผนการนี้ต้องการคนเฝ้าดู และถ้าบล็อกถูกลบรหัสอย่างไม่ถูกต้อง พวกเขาจะส่งหลักฐานการฉ้อโกงเพื่อแจ้งเตือนทุกคน การดำเนินการนี้ต้องใช้สมมติฐานของชนกลุ่มน้อยที่ซื่อสัตย์ตามมาตรฐานและสมมติฐานที่สอดคล้องกัน (เช่น นอกจากมีคนส่งหลักฐานการฉ้อโกงมาให้ฉันแล้ว ฉันยังต้องถือว่าฉันออนไลน์อยู่และจะได้รับภายในระยะเวลาจำกัด)
Ethereum และ Polygon Avail กำลังก้าวไปสู่เส้นทางใหม่ - ความมุ่งมั่นของ KZG (หรือที่เรียกว่าความมุ่งมั่นของ Kate) สิ่งนี้จะลบข้อสันนิษฐานของชนกลุ่มน้อยที่ซื่อสัตย์และความสอดคล้องกันเพื่อรักษาหลักฐานการฉ้อโกงให้ปลอดภัย (แม้ว่าจะยังคงมีอยู่และใช้สำหรับการสร้างใหม่ ซึ่งเราจะพูดถึงในไม่ช้า)
วิธีแก้ปัญหาอื่น ๆ นั้นไม่ได้ขาด แต่ต้องการน้อยกว่า ตัวอย่างเช่น คุณสามารถใช้ ZK-proofs น่าเสียดายที่พวกเขาไม่สามารถคำนวณได้ (สำหรับตอนนี้) อย่างไรก็ตาม พวกเขาคาดว่าจะดีขึ้นในอีกไม่กี่ปีข้างหน้า ดังนั้นจึงมีแนวโน้มว่า Ethereum จะเปลี่ยนมาใช้ STARK ในอนาคต เนื่องจาก KZG สัญญาว่าจะไม่ต้านทานควอนตัม
(ฉันไม่คิดว่าพวกคุณพร้อมสำหรับ STARK หลังควอนตัม แต่คนรุ่นต่อไปจะรักมัน)
กลับไปที่ข้อผูกพันของ KZG - เป็นแผนข้อผูกพันแบบพหุนาม
รูปแบบข้อผูกมัดเป็นเพียงวิธีการเข้ารหัสเพื่อให้คำมั่นสัญญากับค่าบางอย่างสามารถพิสูจน์ได้ การเปรียบเทียบที่ดีที่สุดคือการใส่จดหมายในกล่องที่ล็อกแล้วส่งต่อให้คนอื่น ไม่สามารถเปลี่ยนตัวอักษรได้เมื่อเข้าไปแล้ว แต่สามารถเปิดได้ด้วยกุญแจและรับรอง คุณยอมรับในจดหมาย และที่สำคัญคือหลักฐาน
ในกรณีของเรา เราแมปข้อมูลต้นฉบับและข้อมูลที่ขยายทั้งหมดลงในกริด X,Y แล้วค้นหาโพลิโนเมียลดีกรีต่ำสุดที่เหมาะกับข้อมูลเหล่านั้น (กระบวนการนี้เรียกว่าการแก้ไข Lagrangian) พหุนามนี้คือสิ่งที่ผู้พิสูจน์สัญญาไว้
(ข้อผูกมัดของ KZG ช่วยให้เราสามารถทำข้อผูกมัดกับข้อมูลและส่วนขยายข้อมูล และพิสูจน์ได้ว่าพวกมันอยู่ในพหุนามดีกรีต่ำที่เหมือนกัน)
ประเด็นสำคัญบางประการ:
อันดับแรกคือพหุนาม
ความมุ่งมั่นของผู้พิสูจน์ต่อรูปแบบพหุนามนี้
สิ่งนี้อาศัยการตั้งค่าการเข้ารหัสแบบวงรีโค้งที่เชื่อถือได้ สำหรับวิธีการทำงานนี้มีหัวข้อที่ยอดเยี่ยมจาก Bartek
สำหรับค่าใดๆ ของพหุนามนี้ ผู้พิสูจน์สามารถคำนวณการพิสูจน์ได้
คำพูดของมนุษย์: ผู้พิสูจน์ให้ชิ้นส่วนเหล่านี้แก่ผู้ตรวจสอบ จากนั้นผู้ตรวจสอบสามารถยืนยันได้ว่าค่าของจุดใดจุดหนึ่ง (ค่าในที่นี้แสดงถึงข้อมูลที่อยู่เบื้องหลัง) อยู่ในตำแหน่งที่ถูกต้องบนพหุนามที่ส่งมา
นี่เป็นการปรับส่วนขยายของเราให้เป็นข้อมูลดั้งเดิมเนื่องจากค่าทั้งหมดอยู่ในพหุนามเดียวกัน
หมายเหตุ: ผู้ตรวจสอบไม่จำเป็นต้องใช้พหุนาม
คุณสมบัติที่สำคัญ — ขนาดของข้อผูกพันที่ต้องปฏิบัติตาม ขนาดการพิสูจน์ถึง และเวลาการตรวจสอบถึง แม้แต่ผู้พิสูจน์ การสร้างข้อผูกมัดและการพิสูจน์ก็มีความซับซ้อนเพียง ระดับของพหุนามอยู่ที่ไหน
กล่าวอย่างตรงไปตรงมา: แม้ว่า (จำนวนของค่า) จะเพิ่มขึ้น (เช่น ชุดข้อมูลจะขยายใหญ่ขึ้นตามขนาดชาร์ด) - ขนาดของข้อผูกมัดและการพิสูจน์จะคงที่ และปริมาณงานที่จำเป็นในการตรวจสอบจะคงที่
ทั้งสัญญาและหลักฐานเป็นเพียงองค์ประกอบเส้นโค้งวงรีในการจับคู่เส้นโค้งที่เป็นมิตร (ที่นี่ใช้ BLS12-381) ในกรณีนี้ แต่ละอันมีขนาดเพียง 48 ไบต์เท่านั้น (เล็กมาก)
ดังนั้น ความมุ่งมั่นของผู้พิสูจน์ต่อข้อมูลต้นฉบับและข้อมูลที่ขยายจำนวนมาก (แสดงเป็นค่าจำนวนมากบนพหุนาม) ยังคงมีเพียง 48 ไบต์ และการพิสูจน์ก็จะมีเพียง 48 ไบต์เท่านั้น
ในแง่ที่ง่ายกว่า: ปรับขนาดได้ดีพอสมควร
ที่นี่ รากของ KZG (ความมุ่งมั่นแบบพหุนาม) นั้นคล้ายคลึงกับรากของ Merkle (ความมุ่งมั่นของเวกเตอร์)
ข้อมูลดั้งเดิมคือค่าของพหุนามที่ ถึง จากนั้นเราจะขยายโดยการประเมินพหุนามที่ ถึง คะแนนทั้งหมดจะรับประกันว่าจะอยู่บนพหุนามเดียวกัน
ในหนึ่งประโยค: DAS ช่วยให้เราตรวจสอบว่ามีข้อมูลรหัสลบหรือไม่ KZG สัญญาว่าจะพิสูจน์ให้เราเห็นว่าข้อมูลต้นฉบับได้รับการปรับขนาดอย่างถูกต้อง และสัญญาว่าจะให้ข้อมูลทั้งหมด
พีชคณิตทั้งหมดจบลงที่นี่
KZG Promise เทียบกับหลักฐานการฉ้อโกง
ตอนนี้เราเข้าใจวิธีการทำงานของ KZG แล้ว ลองย้อนกลับไปเปรียบเทียบทั้งสองวิธี
ข้อเสียของ KZG คือจะไม่ปลอดภัยหลังควอนตัม และต้องมีการเริ่มต้นที่เชื่อถือได้ นี่ไม่ใช่สาเหตุที่ต้องกังวล STARK ให้ทางเลือกหลังควอนตัม ในขณะที่การเริ่มต้นที่เชื่อถือได้ (การมีส่วนร่วมแบบเปิด) ต้องการผู้เข้าร่วมที่ซื่อสัตย์เพียงคนเดียว
ข้อได้เปรียบของ KZG คือมีเวลาแฝงต่ำกว่าการตั้งค่าหลักฐานการฉ้อโกง (แม้ว่าตามที่กล่าวไว้ก่อนหน้านี้ GASPER จะไม่ได้ผลลัพธ์สุดท้ายที่รวดเร็วอยู่ดี) และทำให้แน่ใจว่ามีการลบรหัสที่เหมาะสมโดยไม่ถูกนำเข้าสู่หลักฐานการฉ้อโกง ความต่อเนื่องและความซื่อสัตย์โดยธรรมชาติ เป็นข้อสันนิษฐานเล็กน้อย
อย่างไรก็ตาม เนื่องจาก Ethereum ยังคงนำข้อสันนิษฐานเหล่านี้กลับมาใช้ใหม่ในการสร้างบล็อกใหม่ คุณจึงไม่ได้ลบออก เลเยอร์ DA จำเป็นต้องถือว่าบล็อกพร้อมใช้งานในขั้นต้นเสมอ แต่จากนั้นโหนดจำเป็นต้องสื่อสารกันเพื่อนำกลับมารวมกัน การสร้างใหม่นี้ต้องใช้สมมติฐานสองประการ:
คุณมีโหนดเพียงพอ (เบาหรือหนัก) สุ่มตัวอย่างข้อมูลที่พวกเขามีพลังงานเพียงพอที่จะรวมข้อมูล นี่เป็นข้อสันนิษฐานของชนกลุ่มน้อยที่ค่อนข้างอ่อนแอและหลีกเลี่ยงไม่ได้ และไม่มีอะไรต้องกังวล
สมมติฐานการซิงโครไนซ์ได้รับการแนะนำอีกครั้ง - โหนดจำเป็นต้องสื่อสารภายในระยะเวลาหนึ่งก่อนที่จะสามารถประกอบเข้าด้วยกันใหม่ได้
ตัวตรวจสอบความถูกต้องของ Ethereum จะดาวน์โหลดข้อมูลชาร์ดทั้งหมดในรูปแบบ PDS (native darksharding) ในขณะที่ DS จะทำเฉพาะ DAS (ดาวน์โหลดแถวและคอลัมน์ที่ระบุ) Celestia จะกำหนดให้ผู้ตรวจสอบความถูกต้องดาวน์โหลดบล็อกทั้งหมด
โปรดทราบว่าในทั้งสองกรณี เราต้องการสมมติฐานการซิงโครไนซ์สำหรับการสร้างใหม่ ในกรณีที่บล็อกพร้อมใช้งานเพียงบางส่วน โหนดเต็มจะต้องสื่อสารกับโหนดอื่นเพื่อรวมเข้าด้วยกัน
หาก Celestia ต้องการเปลี่ยนจากการกำหนดให้ผู้ตรวจสอบความถูกต้องดาวน์โหลดข้อมูลทั้งหมดเป็นการทำ DAS เท่านั้น ความได้เปรียบด้านเวลาแฝงของ KZG จะเข้ามามีบทบาท (แม้ว่าการเปลี่ยนแปลงนี้ยังไม่ได้วางแผนไว้ในขณะนี้) จากนั้น พวกเขาจำเป็นต้องดำเนินการตามข้อผูกพันของ KZG - การรอการพิสูจน์การฉ้อโกงหมายถึงการเพิ่มช่วงเวลาการบล็อกอย่างมาก และอันตรายจากการตรวจสอบความถูกต้องที่ลงคะแนนสำหรับการบล็อกที่เข้ารหัสไม่ถูกต้องก็จะสูงเช่นกัน
ฉันแนะนำให้อ่านบทความต่อไปนี้เพื่อความเข้าใจที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับวิธีการทำงานของพันธสัญญา KZG:
พื้นฐาน (ค่อนข้างง่ายที่จะเข้าใจ) ของการเข้ารหัสแบบเส้นโค้งวงรี
สำรวจการจับคู่ Elliptic Curve โดย Vitalik
ความมุ่งมั่นพหุนามของ KZG โดย Dankrad
หลักการเริ่มต้นที่เชื่อถือได้โดย Vitalik
การแยกผู้ริเริ่มและผู้สร้างภายในโปรโตคอล
โหนดที่เป็นเอกฉันท์ในปัจจุบัน (ผู้ขุด) และโหนดที่เป็นเอกฉันท์ที่ผสานรวม (ผู้ตรวจสอบ) มีบทบาทที่แตกต่างกัน พวกเขาสร้างบล็อกจริงซึ่งจะถูกส่งไปยังโหนดที่เป็นเอกฉันท์อื่น ๆ เพื่อตรวจสอบความถูกต้อง นักขุดจะ "ลงคะแนน" ในบล็อกก่อนหน้า และหลังจากการรวมแล้ว ผู้ตรวจสอบความถูกต้องจะลงคะแนนโดยตรงว่าบล็อกนั้นถูกต้องหรือไม่ถูกต้อง
PBS (Separation of Initiators and Builders) แยกสิ่งเหล่านี้ - มันสร้างบทบาทผู้สร้างในโปรโตคอลใหม่อย่างชัดเจน ผู้สร้างโดยเฉพาะจะรวมบล็อกเข้าด้วยกันและประมูลสำหรับผู้ริเริ่ม (ผู้ตรวจสอบความถูกต้อง) เพื่อเลือกบล็อกของพวกเขา สิ่งนี้สวนทางกับการรวมศูนย์อำนาจของ MEV
เมื่อมองย้อนกลับไปที่ "จุดจบ" ของ Vitalik - ถนนทุกสายนำไปสู่การผลิตบล็อกแบบรวมศูนย์ด้วยการตรวจสอบที่ไม่น่าเชื่อถือและกระจายอำนาจ PBS ก้าวไปอีกขั้น เราต้องการผู้สร้างที่ซื่อสัตย์เพื่อรองรับความถูกต้องและการต่อต้านการเซ็นเซอร์ของเครือข่าย (สองคนจะมีประสิทธิภาพมากกว่า) แต่ชุดเครื่องมือตรวจสอบต้องการคนส่วนใหญ่ที่ซื่อสัตย์ PBS ทำให้บทบาทของผู้ริเริ่มเป็นเรื่องง่ายที่สุดเท่าที่จะเป็นไปได้เพื่อสนับสนุนการกระจายอำนาจของผู้ตรวจสอบความถูกต้อง
ผู้สร้างจะได้รับทิปค่าธรรมเนียมพิเศษ รวมถึง MEV ใด ๆ ที่พวกเขาสามารถถอนได้ ในตลาดที่มีประสิทธิภาพ ผู้สร้างที่แข่งขันกันจะเสนอราคาเต็มมูลค่าที่พวกเขาสามารถดึงออกมาจากบล็อก (ลบด้วยต้นทุนที่ตัดจำหน่าย เช่น ฮาร์ดแวร์ราคาแพง ฯลฯ) ค่าทั้งหมดจะหยดลงไปที่ชุดตัวตรวจสอบความถูกต้องแบบกระจายอำนาจ ซึ่งเป็นสิ่งที่เราต้องการอย่างแท้จริง
การใช้งาน PBS ที่แน่นอนยังอยู่ระหว่างการสนทนา แต่ PBS แบบสองช่องอาจมีลักษณะดังนี้:
ผู้สร้างมุ่งมั่นที่จะบล็อกส่วนหัวในขณะที่เสนอราคา
ผู้ริเริ่มบล็อกบีคอนเลือกส่วนหัวของบล็อกที่ชนะและเสนอราคา ผู้ริเริ่มจะได้รับเงินโดยไม่มีเงื่อนไขสำหรับการชนะการประมูล แม้ว่าผู้สร้างจะล้มเหลวในการสร้างตัวบล็อกก็ตาม
คณะกรรมการผู้รับรองยืนยันส่วนหัวของบล็อกที่ชนะ
ผู้สร้างเปิดเผยเรื่องของผู้ชนะการประมูล
คณะกรรมการพยานชุดอื่นจะเลือกร่างที่ชนะ (หากผู้สร้างที่ชนะไม่แสดงร่าง ให้ลงคะแนนเสียงเพื่อพิสูจน์ว่าไม่มีอยู่จริง)
ผู้ริเริ่มถูกเลือกจากกลุ่มผู้ตรวจสอบความถูกต้องโดยใช้กลไก RANDAO มาตรฐาน จากนั้นเราจะใช้กลยุทธ์การเปิดเผยความมุ่งมั่นโดยไม่เปิดเผยเนื้อหาทั้งหมดจนกว่าส่วนหัวของบล็อกจะได้รับการยืนยันจากคณะกรรมการ
การเปิดเผยตามสัญญาจะมีประสิทธิภาพมากกว่า (การส่งเนื้อหาแบบเต็มบล็อกหลายร้อยรายการอาจทำให้แบนด์วิธของเลเยอร์ p2p ล้นหลาม) และยังป้องกันการโจรกรรม MEV อีกด้วย หากผู้สร้างส่งบล็อกทั้งหมดของพวกเขา ผู้สร้างรายอื่นสามารถดู กำหนดกลยุทธ์ ผสานรวมเข้าด้วยกัน และเผยแพร่บล็อกที่ดีกว่าได้อย่างรวดเร็ว นอกจากนี้ ผู้ริเริ่มที่มีความซับซ้อนสามารถตรวจพบกลยุทธ์ MEV ที่ใช้ และจำลองแบบโดยไม่ต้องชดเชยผู้สร้าง หากการขโมย MEV นี้กลายเป็นพลังที่สมดุล มันจะจูงใจให้ผู้สร้างและผู้ริเริ่มรวมตัวกัน ดังนั้น เราจึงใช้กลยุทธ์การเปิดเผยข้อมูลเพื่อหลีกเลี่ยงสิ่งนี้
หลังจากที่ผู้ริเริ่มเลือกส่วนหัวของบล็อกที่ชนะ คณะกรรมการจะได้รับการยืนยันและเข้มงวดในกฎการเลือกทางแยก ผู้สร้างที่ชนะจะเผยแพร่เนื้อความ "บล็อกผู้สร้าง" เต็มรูปแบบที่ชนะ หากเผยแพร่ทันกำหนดคณะกรรมการชุดต่อไปจะรับรอง หากพวกเขาไม่สามารถเผยแพร่ได้ทันเวลา พวกเขายังคงต้องจ่ายให้กับผู้สร้างเต็มจำนวน (และสูญเสีย MEV และค่าธรรมเนียมทั้งหมด) การชำระเงินแบบไม่มีเงื่อนไขนี้ทำให้ผู้ริเริ่มไม่จำเป็นต้องเชื่อถือผู้สร้าง
ข้อเสียของการออกแบบ "ช่องคู่" นี้คือเวลาแฝง บล็อกที่ผสานจะมีเวลาคงที่ 12 วินาที ดังนั้นหากไม่มีการตั้งสมมติฐานใหม่ เราต้องใช้เวลา 24 วินาทีสำหรับเวลาบล็อกเต็ม (ช่อง 12 วินาทีสองช่อง) สล็อต 8 วินาที (เวลาบล็อก 16 วินาที) ดูเหมือนจะเป็นการประนีประนอมด้านความปลอดภัย แต่การวิจัยยังดำเนินต่อไป
รายการต่อต้านการเซ็นเซอร์ (crList)
น่าเสียดายที่ PBS ให้ความสามารถในการตรวจสอบข้อเสนอแก่ผู้สร้างได้อย่างมาก บางทีผู้สร้างอาจไม่ชอบคุณ ดังนั้นพวกเขาจึงเพิกเฉยต่อข้อตกลงของคุณ บางทีพวกเขาอาจทำงานได้ดีจนผู้สร้างรายอื่นยอมแพ้ หรืออาจตั้งราคาสูงสำหรับบล็อกเพราะพวกเขาไม่ชอบคุณจริงๆ
crLists ป้องกันสิ่งนี้ การใช้งานที่เฉพาะเจาะจงเป็นพื้นที่การออกแบบแบบเปิดอีกครั้ง แต่ "PBS แบบไฮบริด" ดูเหมือนจะเป็นที่นิยมมากที่สุด ผู้สร้างระบุรายการธุรกรรมที่มีสิทธิ์ทั้งหมดที่พวกเขาเห็นใน mempool และผู้สร้างจะถูกบังคับให้ยอมรับธุรกรรมแบบครอบคลุม (เว้นแต่ว่าบล็อกจะเต็ม)
ผู้ริเริ่มเผยแพร่ crList และสรุป crList ด้วยธุรกรรมที่มีสิทธิ์ทั้งหมด
ผู้สร้างสร้างเนื้อหาของบล็อกที่เสนอ จากนั้นส่งการเสนอราคาที่รวมแฮชของสรุป crList เพื่อเป็นหลักฐานที่พวกเขาได้เห็น
ผู้ริเริ่มยอมรับการเสนอราคาและส่วนหัวของบล็อกของผู้ชนะการประมูล (พวกเขายังไม่เห็นเนื้อหาของบล็อก)
ผู้สร้างเผยแพร่บล็อกของพวกเขา รวมถึงหลักฐานว่าพวกเขาได้รวมธุรกรรมทั้งหมดใน crList หรือบล็อกนั้นเต็ม มิฉะนั้น บล็อกจะไม่ได้รับการยอมรับจากกฎการเลือกทางแยก
พยาน (ผู้รับรอง) ตรวจสอบความถูกต้องของหลักการที่เผยแพร่
ยังมีประเด็นสำคัญที่ต้องแก้ไขที่นี่ ตัวอย่างเช่น กลยุทธ์ทางเศรษฐกิจที่โดดเด่นอย่างหนึ่งคือให้ผู้ริเริ่มส่งรายชื่อที่ว่างเปล่า ด้วยวิธีนี้ แม้แต่ผู้สร้างที่ควรได้รับการตรวจสอบก็สามารถชนะการประมูลได้ตราบเท่าที่พวกเขาเสนอราคาสูงสุด มีวิธีแก้ไข (หรือมีอย่างอื่น) ฉันแค่เน้นว่าการออกแบบที่นี่ไม่แข็งกระด้าง
กลยุทธ์ 2D KZG
เราเห็นว่าข้อผูกมัดของ KZG ช่วยให้เรายอมรับข้อมูลและพิสูจน์ว่าได้รับการปรับขนาดอย่างถูกต้องได้อย่างไร อย่างไรก็ตาม นี่เป็นการทำให้ Ethereum ทำอะไรได้ง่ายขึ้น จะไม่ส่งข้อมูลทั้งหมดในข้อผูกพัน KZG เดียว - บล็อกจะใช้ข้อผูกพัน KZG จำนวนมาก
เรามีผู้สร้างที่ทุ่มเทอยู่แล้ว ดังนั้นทำไมไม่ปล่อยให้พวกเขาสร้าง KZG คอมมิชชันขนาดยักษ์ล่ะ ปัญหาคือสิ่งนี้ต้องใช้ supernode ที่ทรงพลังในการปรับโครงสร้างใหม่ เราสามารถยอมรับข้อกำหนดของ supernode สำหรับการสร้างครั้งแรกได้ แต่เราต้องหลีกเลี่ยงการตั้งสมมติฐานเกี่ยวกับการสร้างใหม่ เราต้องการหน่วยงานทั่วไปเพื่อให้สามารถจัดการการสร้างใหม่ได้ ดังนั้นการแบ่งข้อผูกพันของ KZG ออกเป็นหลายส่วนร่วมกันจึงเป็นเรื่องปกติ เมื่อพิจารณาจากจำนวนข้อมูลที่มีอยู่ การสร้างใหม่อาจค่อนข้างธรรมดา หรือเป็นข้อสันนิษฐานพื้นฐานในการออกแบบนี้
เพื่อให้การสร้างใหม่ง่ายขึ้น แต่ละบล็อกจะประกอบด้วยข้อมูลเศษ m ที่เข้ารหัสเป็นข้อผูกมัด KZG m หากคุณไม่ฉลาด การทำเช่นนี้จะส่งผลให้เกิดการสุ่มตัวอย่างจำนวนมาก - คุณจะต้องทำ DAS กับเศษชิ้นส่วนแต่ละชิ้นเพื่อให้แน่ใจว่าพร้อมใช้งาน (ต้องใช้ตัวอย่าง m*k โดยที่ k คือจำนวนตัวอย่างต่อชิ้น)
ดังนั้น Ethereum จะใช้กลยุทธ์ 2D KZG เราใช้รหัส Reed-Solomon อีกครั้งเพื่อขยายภาระผูกพัน m เป็น 2 ล้าน
เรากำหนดให้เป็นนโยบาย 2 มิติโดยขยายข้อผูกพันเพิ่มเติมของ KZG (ในที่นี้คือ 256-511) ซึ่งอยู่บนพหุนามเดียวกับ 0-255 ตอนนี้เราต้องทำ DAS ในตารางด้านบนเพื่อให้แน่ใจว่าข้อมูลชาร์ดทั้งหมดพร้อมใช้งาน
การสุ่มตัวอย่างแบบ 2 มิติต้องใช้ข้อมูล 75% (เทียบกับ 50% ที่กล่าวถึงก่อนหน้านี้) ซึ่งหมายความว่าเราจำเป็นต้องดึงตัวอย่างในจำนวนที่แน่นอนมากขึ้น กลยุทธ์ 1D เวอร์ชันก่อนหน้าอย่างง่ายต้องการตัวอย่าง 30 ตัวอย่าง และที่นี่จะต้องใช้ 75 ตัวอย่างเพื่อให้แน่ใจว่าความน่าจะเป็นในการสร้างบล็อกที่ใช้งานได้ใหม่นั้นสอดคล้องกัน
Sharding 1.0 (สอดคล้องกับกลยุทธ์ความมุ่งมั่น 1D KZG) ต้องการเพียง 30 ตัวอย่าง แต่คุณต้องสุ่มตัวอย่าง 64 ชิ้น และการตรวจสอบแบบเต็มต้องใช้ 1920 ตัวอย่าง แต่ละตัวอย่างคือ 512 B ดังนั้นจึงเป็น:
(512 B x 64 ชิ้น x 30 ตัวอย่าง) / 16 วินาที = แบนด์วิดท์ 60 KB/s
ในความเป็นจริง ผู้ตรวจสอบจะถูกเลือกแบบสุ่มแทนที่จะตรวจสอบชิ้นส่วนทั้งหมดทีละชิ้น
การผสานบล็อกด้วยกลยุทธ์ 2D KZG ทำให้การตรวจสอบ DA เต็มรูปแบบเป็นเรื่องง่ายมาก ต้องเลือกเพียง 75 ตัวอย่างจากบล็อกที่ผสานเดียว:
(512 B x 1 บล็อก x 75 ตัวอย่าง) / 16 วินาที = แบนด์วิดท์ 2.5 KB/s
Danksharding
PBS was initially designed to blunt the centralizing forces of MEV on the validator set. However, Dankrad recently took advantage of that design realizing that it unlocked a far better sharding construct – DS.
DS leverages the specialized builder to create a tighter integration of the Beacon Chain execution block and shards. We now have one builder creating the entire block together, one proposer, and one committee voting on it at a time. DS would be infeasible without PBS – regular validators couldn’t handle the massive bandwidth of a block full of rollups’ data blobs:
เดิมที PBS ได้รับการออกแบบมาเพื่อป้องกันอำนาจการรวมศูนย์ของ MEV ในกลุ่มเครื่องมือตรวจสอบความถูกต้อง อย่างไรก็ตาม Dankrad เพิ่งใช้ประโยชน์จากการออกแบบนี้และสร้างแผนการแยกชิ้นส่วนที่ดีขึ้น - DS (Danksharding)
DS ใช้ตัวสร้างเฉพาะเพื่อให้บรรลุการรวมที่แน่นแฟ้นยิ่งขึ้นระหว่างบล็อกการดำเนินการของ Beacon Chain และชิ้นส่วน ขณะนี้เรามีผู้สร้างที่สร้างบล็อกทั้งหมด ผู้เสนอ และคณะกรรมการที่ลงคะแนนเสียง DS ไม่สามารถทำได้หากไม่มี PBS - ผู้สร้างทั่วไปไม่สามารถมีแบนด์วิธขนาดใหญ่เพื่อตอบสนองบล็อกที่มีบล็อกการยกเลิกจำนวนนับไม่ถ้วน
Sharding 1.0 ประกอบด้วยคณะกรรมการอิสระและผู้ริเริ่ม 64 คน ซึ่งช่วยให้แต่ละกลุ่มสามารถหยิบยกประเด็นขึ้นมาได้อย่างอิสระ การผสานรวมที่แน่นแฟ้นยิ่งขึ้นนี้ช่วยให้เรามั่นใจได้ว่า Data Available (DA) ที่สมบูรณ์พร้อมกัน ข้อมูลยังคง "แยกย่อย" ในกล่องดำ แต่จากมุมมองที่ใช้งานได้จริง เศษเริ่มรู้สึกเหมือนเป็นก้อนข้อมูลมากขึ้น ซึ่งดีมาก
Danksharding - การยืนยันเสียงข้างมากโดยสุจริต
มาดูกันว่าผู้ตรวจสอบพิสูจน์ว่าข้อมูลเชื่อถือได้อย่างไร:
สิ่งนี้จำเป็นต้องอาศัยตัวตรวจสอบที่ซื่อสัตย์เป็นส่วนใหญ่ เนื่องจากตัวตรวจสอบความถูกต้องตัวเดียว คอลัมน์และแถวของฉันจึงพร้อมใช้งาน ไม่เพียงพอที่จะทำให้ฉันมีความมั่นใจทางสถิติว่าทั้งบล็อกพร้อมใช้งาน เราต้องการเสียงข้างมากที่ซื่อสัตย์ในการสรุปผลนั้น การตรวจสอบแบบกระจายอำนาจเป็นสิ่งสำคัญ
โปรดทราบว่าสิ่งนี้แตกต่างจากตัวอย่างสุ่ม 75 ตัวอย่างที่เราพูดถึงก่อนหน้านี้ การสุ่มตัวอย่างแบบส่วนตัวหมายความว่าบุคคลที่มีการเตรียมใช้งานต่ำจะสามารถตรวจสอบความพร้อมใช้งานได้อย่างง่ายดาย (เช่น ฉันสามารถเรียกใช้โหนดแสง DAS และรู้ว่าบล็อกพร้อมใช้งาน) อย่างไรก็ตาม ผู้ตรวจสอบจะยังคงใช้วิธีแถวและคอลัมน์ต่อไปเพื่อตรวจสอบความพร้อมใช้งานและแนะนำการสร้างบล็อกใหม่
Danksharding - การสร้างใหม่
ตราบเท่าที่มี 50% ของแถวหรือคอลัมน์เดียว ระบบจะสร้างใหม่ทั้งหมดได้อย่างง่ายดายด้วยตัวตรวจสอบตัวอย่าง เมื่อพวกเขาสร้างบล็อกใดๆ ที่หายไปในแถว/คอลัมน์ใหม่ พวกเขากระจายบล็อกเหล่านั้นใหม่บนเส้นมุมฉาก ซึ่งช่วยให้ตัวตรวจสอบความถูกต้องอื่นๆ สร้างบล็อกที่ขาดหายไปจากแถวและคอลัมน์ที่ตัดกันใหม่ได้ตามต้องการ
สมมติฐานที่ปลอดภัยสำหรับการสร้างบล็อกที่ใช้งานได้ใหม่คือ:
มีโหนดเพียงพอที่ดำเนินการตามคำขอตัวอย่าง เพื่อให้พวกเขามีข้อมูลรวมกันเพียงพอในการสร้างบล็อกใหม่
สมมติฐานการซิงโครไนซ์ระหว่างโหนดที่กำลังเผยแพร่บล็อกย่อยตามลำดับ
แล้วมีกี่โหนดถึงจะพอ? การประมาณคร่าวๆ ต้องใช้อินสแตนซ์เดี่ยว 64,000 รายการ (มากกว่า 380,000 รายการจนถึงตอนนี้) นี่เป็นการคำนวณแบบอนุรักษ์นิยมมาก ซึ่งถือว่าไม่มีการครอสโอเวอร์ของโหนดที่รันโดยตัวตรวจสอบความถูกต้องเดียวกัน (ซึ่งห่างไกลจากกรณีนี้เนื่องจากโหนดถูกจำกัดไว้ที่ 32 ETH) หากคุณสุ่มตัวอย่างมากกว่า 2 แถวและ 2 คอลัมน์ คุณจะเพิ่มโอกาสในการดึงข้อมูลโดยรวมเนื่องจากครอสโอเวอร์ สิ่งนี้เริ่มปรับขนาดเป็นกำลังสอง - หากตัวตรวจสอบความถูกต้องทำงานด้วยตัวตรวจสอบความถูกต้อง 10 หรือ 100 ตัว ความต้องการ 64,000 ตัวจะลดลงตามลำดับความสำคัญ
DS สามารถตั้งค่าให้ลดจำนวนบล็อกชาร์ดโดยอัตโนมัติ หากจำนวนตัวตรวจสอบออนไลน์เริ่มต่ำมาก ดังนั้นสมมติฐานด้านความปลอดภัยจะลดลงสู่ระดับที่ปลอดภัย
Danksharding - ความปลอดภัยส่วนใหญ่ที่เป็นอันตรายพร้อมการสุ่มตัวอย่างส่วนตัว
เราเห็นว่าการยืนยัน DS อาศัยเสียงส่วนใหญ่ที่ซื่อสัตย์ในการพิสูจน์การบล็อก ฉันในฐานะปัจเจกบุคคล ไม่สามารถพิสูจน์ได้ว่าบล็อกนั้นใช้งานได้ด้วยการดาวน์โหลดหลายอันดับ อย่างไรก็ตาม การสุ่มตัวอย่างแบบส่วนตัวสามารถให้การรับประกันนี้โดยไม่ต้องไว้วางใจใคร นี่คือสิ่งที่เกิดขึ้นเมื่อโหนดที่กล่าวถึงก่อนหน้านี้ตรวจสอบตัวอย่างแบบสุ่ม 75 ตัวอย่าง
ในตอนแรก DS จะไม่รวมการสุ่มตัวอย่างแบบส่วนตัว เนื่องจากนี่เป็นปัญหาที่แก้ไขได้ยากในแง่ของระบบเครือข่าย (PSA: บางทีคุณอาจช่วยพวกเขาได้!)
โปรดทราบว่า "ส่วนตัว" มีความสำคัญเพราะหากผู้โจมตีไม่เปิดเผยตัวตนของคุณ พวกเขาจะสามารถปลอมแปลงโหนดตัวอย่างจำนวนเล็กน้อยได้ พวกเขาสามารถส่งคืนข้อมูลก้อนเดียวที่คุณขอและระงับส่วนที่เหลือ คุณจึงไม่ทราบว่าข้อมูลทั้งหมดมาจากการสุ่มตัวอย่างของคุณเอง
Danksharding - บทสรุปที่สำคัญ
DS น่าตื่นเต้นมาก ไม่ใช่แค่ชื่อที่ดีเท่านั้น ในที่สุดมันก็ทำให้วิสัยทัศน์ของ Ethereum เกี่ยวกับการชำระบัญชีเป็นหนึ่งเดียวและเลเยอร์ DA เป็นจริง การประกบกันแน่นของบล็อกบีคอนและชิ้นส่วนสามารถบรรลุผลโดยไม่ทำให้ชิ้นส่วนของจริงแตกเป็นชิ้นเล็กชิ้นน้อย
อันที่จริง เรามานิยามว่าทำไมมันถึงถูกมองว่าเป็น "sharded" การแบ่งส่วนเพียงอย่างเดียวในที่นี้เป็นเพียงข้อเท็จจริงที่ว่าตัวตรวจสอบความถูกต้องจะไม่รับผิดชอบในการดาวน์โหลดข้อมูลทั้งหมด ไม่มีอะไรอีกแล้ว.
ดังนั้น หากคุณกำลังสงสัยว่านี่เป็นการแบ่งส่วนจริงหรือไม่ คุณก็ไม่ได้บ้า นี่คือเหตุผลที่ PDS (เราจะพูดถึงในไม่ช้า) ไม่ถือว่าเป็น "เศษ" (แม้ว่าจะมีคำว่า "เศษ" ในชื่อก็ตาม ใช่ ฉันรู้ว่ามันสับสน) PDS กำหนดให้โปรแกรมตรวจสอบแต่ละรายการดาวน์โหลดบล็อกทั้งหมดเพื่อพิสูจน์ความพร้อมใช้งาน จากนั้น DS แนะนำการสุ่มตัวอย่าง ดังนั้นผู้ตรวจสอบแต่ละคนจึงดาวน์โหลดเฉพาะบางส่วนเท่านั้น
การแบ่งชิ้นส่วนที่น้อยที่สุดหมายถึงการออกแบบที่เรียบง่ายกว่าการแบ่งชิ้นส่วน 1.0 (การส่งมอบที่เร็วกว่าใช่ไหม) เนื้อหาแบบง่ายประกอบด้วย:
เมื่อเทียบกับข้อมูลจำเพาะ Sharding 1.0 ข้อมูลจำเพาะของ DS อาจมีโค้ดน้อยกว่าหลายร้อยบรรทัด (และน้อยกว่าหลายพันบรรทัดในฝั่งไคลเอ็นต์)
ไม่มีคณะกรรมการย่อยเป็นโครงสร้างพื้นฐานอีกต่อไป คณะกรรมการจำเป็นต้องลงคะแนนในห่วงโซ่หลักเท่านั้น
ไม่จำเป็นต้องติดตามการยืนยัน Shard Blob แต่ละรายการ ตอนนี้การยืนยันทั้งหมดในห่วงโซ่หลักจะได้รับการยืนยันหรือไม่ก็ได้
ผลลัพธ์ที่ดีของสิ่งนี้คือตลาดรวมค่าธรรมเนียมสำหรับข้อมูล Sharding 1.0 จะทำให้สิ่งเหล่านี้แยกส่วนด้วยผู้สร้างที่แตกต่างกันซึ่งสร้างบล็อกที่แตกต่างกัน
คณะกรรมการแยกส่วนได้ต่อต้านการติดสินบนอย่างมีประสิทธิภาพเช่นกัน ผู้ตรวจสอบความถูกต้องของ DS ลงคะแนนให้กับบล็อกทั้งหมดหนึ่งครั้งในแต่ละยุค ดังนั้นข้อมูลจะได้รับการยืนยันทันทีโดย 1/32 ของกลุ่มผู้ตรวจสอบความถูกต้องทั้งหมด (32 ตำแหน่งในแต่ละยุค) ผู้ตรวจสอบ Shard 1.0 ยังลงคะแนนหนึ่งครั้งต่อยุค แต่แต่ละ Shard จะมีคณะกรรมการของตนเองที่ต้องจัดระเบียบใหม่ ดังนั้น ชิ้นส่วนแต่ละชิ้นจะได้รับการยืนยันโดยกลุ่มผู้ตรวจสอบ 1/2048 เท่านั้น (1/32 ถูกแบ่งระหว่าง 64 ชิ้น)
ตามที่กล่าวไว้ การบล็อกรวมกับแผนความมุ่งมั่น 2D KZG ยังทำให้ DAS มีประสิทธิภาพมากขึ้น Sharding 1.0 ต้องการแบนด์วิธ 60KB/s เพื่อตรวจสอบ DA ทั้งหมดของ Shards ทั้งหมด และ DS ต้องการเพียง 2.5KB/s
นอกจากนี้ยังมีความเป็นไปได้ที่น่าตื่นเต้นสำหรับ DS - การเรียกใช้แบบซิงโครนัสระหว่างการดำเนินการ ZK-rollup และ L1 Ethereum การทำธุรกรรมจาก Shard Blocks สามารถยืนยันและเขียนไปยัง L1 ได้ทันที เนื่องจากทุกอย่างถูกสร้างใน Beacon Chain Block เดียวกัน Sharding 1.0 ขจัดความเป็นไปได้นี้เนื่องจากการยืนยันชิ้นส่วนแยกต่างหาก สิ่งนี้ทำให้พื้นที่การออกแบบที่น่าตื่นเต้นซึ่งอาจมีค่ามากสำหรับสิ่งต่าง ๆ เช่น สภาพคล่องที่ใช้ร่วมกัน (เช่น dAMM)
Danksharding——ข้อจำกัดในการขยายตัวของ Blockchain
เลเยอร์แบบแยกส่วนปรับขนาดได้อย่างสง่างาม — การกระจายอำนาจที่มากขึ้นนำไปสู่การปรับขนาดที่มากขึ้น สิ่งนี้แตกต่างโดยพื้นฐานจากสิ่งที่เราเห็นในปัจจุบัน การเพิ่มโหนดในเลเยอร์ DA สามารถเพิ่มปริมาณงานข้อมูลได้อย่างปลอดภัย
ความสามารถในการปรับขนาดของบล็อกเชนยังมีจำกัด แต่เราสามารถปรับปรุงให้ดีขึ้นได้ตามลำดับความสำคัญเมื่อเทียบกับทุกวันนี้ เลเยอร์ฐานที่ปลอดภัยและปรับขนาดได้ช่วยให้สามารถปรับขนาดการใช้งานได้อย่างรวดเร็ว การปรับปรุงการจัดเก็บข้อมูลและแบนด์วิธจะเพิ่มปริมาณงานข้อมูลเมื่อเวลาผ่านไป
เป็นไปได้อย่างแน่นอนที่ปริมาณงานของ DA จะเกินตามที่กำหนดไว้ในบทความนี้ แต่เป็นการยากที่จะบอกว่าค่าสูงสุดนี้จะตกอยู่ที่ใด เราไม่มีเส้นสีแดงที่ชัดเจน แต่สามารถระบุช่วงเวลาที่การสนับสนุนสมมติฐานบางอย่างเริ่มกลายเป็นเรื่องยาก
การจัดเก็บข้อมูล - เกี่ยวกับ DA และความสามารถในการดึงข้อมูล บทบาทของ Consensus Layer ไม่ได้รับประกันว่าจะสามารถเรียกค้นข้อมูลได้อย่างไม่มีกำหนด บทบาทของเลเยอร์นี้คือการทำให้ข้อมูลพร้อมใช้งานนานพอที่ใครก็ตามที่เต็มใจจะดาวน์โหลดจะสามารถตอบสนองสมมติฐานด้านความปลอดภัยของเราได้ จากนั้น มันถูกทิ้งทุกที่ - ซึ่งสะดวกสบาย เพราะประวัติเป็นสมมติฐานความน่าเชื่อถือ 1 ใน N และเราไม่ได้พูดถึงข้อมูลจำนวนมากขนาดนั้น โครงการขนาดใหญ่ขนาดนั้น อย่างไรก็ตาม เมื่อทรูพุตเพิ่มขึ้น มันสามารถเข้าสู่พื้นที่ที่อึดอัดได้
เครื่องมือตรวจสอบ - DAS ต้องการโหนดมากพอที่จะร่วมกันสร้างบล็อกใหม่ มิฉะนั้น ผู้โจมตีสามารถนั่งเฉย ๆ และตอบเฉพาะคำถามที่ได้รับ หากข้อความค้นหาเหล่านี้ไม่เพียงพอที่จะสร้างบล็อกขึ้นมาใหม่ ผู้โจมตีสามารถระงับส่วนที่เหลือและเราตาย เพื่อเพิ่มปริมาณงานอย่างปลอดภัย เราจำเป็นต้องเพิ่มโหนด DAS หรือเพิ่มความต้องการแบนด์วิธข้อมูล สำหรับทรูพุตที่กล่าวถึงในที่นี้ นี่ไม่ใช่ปัญหา ถึงกระนั้นก็อาจไม่สบายใจหากปริมาณงานเพิ่มขึ้นหลายลำดับความสำคัญเหนือการออกแบบนี้
โปรดทราบว่าตัวสร้างไม่ใช่คอขวด คุณต้องสร้างการพิสูจน์ KZG อย่างรวดเร็วสำหรับข้อมูล 32MB ดังนั้นจึงต้องการ GPU หรือ CPU ที่ทรงพลังพอสมควรพร้อมแบนด์วิดท์อย่างน้อย 2.5GBit/s มันเป็นบทบาทเฉพาะอยู่แล้ว และเป็นต้นทุนทางธุรกิจเล็กน้อยสำหรับพวกเขา
Danksharding พื้นเมือง (EIP-4844)
DS นั้นยอดเยี่ยม แต่เราต้องอดทน PDS พร้อมที่จะช่วยเหลือเรา - ได้ดำเนินการขั้นตอนความเข้ากันได้ล่วงหน้าที่จำเป็นในตารางเวลาที่รัดกุม (กำหนดเป้าหมาย Shanghai hard fork) เพื่อจัดเตรียมลำดับความสำคัญระหว่างการเปลี่ยนแปลง อย่างไรก็ตาม มันไม่ได้ใช้งาน data sharding จริง ๆ (เช่น ตัวตรวจสอบจำเป็นต้องดาวน์โหลดข้อมูลทั้งหมดทีละรายการ)
การยกเลิกวันนี้ใช้ข้อมูลการโทร L1 สำหรับการจัดเก็บ ซึ่งสามารถคงอยู่ตลอดไปบนเครือข่าย อย่างไรก็ตาม การรวบรวมต้องใช้ DA ในช่วงเวลาสั้นๆ เท่านั้น ดังนั้นจึงมีเวลาเหลือเฟือสำหรับทุกคนที่สนใจดาวน์โหลด
EIP-4844 นำเสนอรูปแบบการทำธุรกรรมแบบ blob-carrying ใหม่ ซึ่งจะใช้การยกเลิกสำหรับการจัดเก็บข้อมูลในอนาคต Blobs มีข้อมูลจำนวนมาก (ประมาณ 125KB) และมีราคาถูกกว่า calldata ในจำนวนที่ใกล้เคียงกันมาก Data Blob ถูกตัดออกจากโหนดหลังจากผ่านไปหนึ่งเดือน ทำให้ความต้องการพื้นที่เก็บข้อมูลลดลง ซึ่งช่วยให้มีเวลาเพียงพอที่จะตอบสนองสมมติฐานด้านความปลอดภัยของ DA ของเรา
สำหรับบริบทเพิ่มเติม บล็อก Ethereum ปัจจุบันโดยทั่วไปมีขนาดเฉลี่ยประมาณ 90 KB (ข้อมูลการโทรประมาณ 10 KB) PDS เพิ่มแบนด์วิดท์ DA ให้มากขึ้น (เป้าหมาย ~1MB, สูงสุด ~2MB) สำหรับ blobs เมื่อถูกตัดหลังจากผ่านไปหนึ่งเดือน พวกเขาไม่เป็นภาระกับโหนดตลอดเวลา
หยดเป็นเวกเตอร์ขององค์ประกอบฟิลด์ 4096 แต่ละ 32 ไบต์ PDS อนุญาตสูงสุด 16 blobs ต่อบล็อก ในขณะที่ DS จะเพิ่มเป็น 256
แบนด์วิธ PDS DA = 4096 x 32 x 16 = 2 MiB ต่อบล็อก เป้าหมายคือ 1 MiB
แบนด์วิดท์ DS DA = 4096 x 32 x 256 = 32 MiB ต่อบล็อก เป้าหมายคือ 16 MiB
แต่ละขั้นตอนคือลำดับของการขยายขนาด PDS ยังคงต้องใช้โหนดที่สอดคล้องกันเพื่อดาวน์โหลดข้อมูลทั้งหมด ดังนั้นจึงเป็นการดำเนินการแบบอนุรักษ์นิยม DS กระจายโหลดของการจัดเก็บและเผยแพร่ข้อมูลระหว่างตัวตรวจสอบความถูกต้อง
ต่อไปนี้คือสิ่งดีๆ ที่ EIP-4844 นำเสนอระหว่างทางสู่ DS:
ข้อมูลรูปแบบการทำธุรกรรมที่มี blobs
ความมุ่งมั่นของ KZG ต่อหยด
ตรรกะเลเยอร์การดำเนินการทั้งหมดที่จำเป็นโดย DS
ตรรกะการตรวจสอบข้ามการดำเนินการ/ฉันทามติทั้งหมดที่จำเป็นโดย DS
การแยกเลเยอร์ระหว่างการตรวจสอบ beacon block และ DAS blobs
ลอจิกบล็อกบีคอนส่วนใหญ่ที่ DS ต้องการ
ราคาก๊าซอิสระที่ปรับเองได้สำหรับ blobs (หลายมิติ EIP-1559 พร้อมกฎการกำหนดราคาดัชนี)
DS จะเพิ่มในอนาคต:
PBS
DAS
กลยุทธ์ 2D KZG
หลักฐานการอารักขาหรือข้อกำหนดในโปรโตคอลที่คล้ายกันซึ่งช่วยให้ผู้ตรวจสอบความถูกต้องแต่ละคนสามารถตรวจสอบความพร้อมใช้งานของข้อมูลชาร์ดบางส่วนต่อบล็อก (ประมาณหนึ่งเดือน)
โปรดทราบว่า data blobs เหล่านี้ถูกนำมาใช้เป็นประเภทธุรกรรมใหม่ในสายตัวดำเนินการ แต่ไม่ได้กำหนดภาระเพิ่มเติมให้กับตัวดำเนินการ EVM ดูเฉพาะข้อผูกมัดที่แนบมากับบล็อคข้อมูลเท่านั้น การเปลี่ยนแปลงเลเยอร์การใช้งานที่แนะนำโดย EIP-4844 ยังเข้ากันได้กับ DS ไปข้างหน้า ไม่จำเป็นต้องเปลี่ยนแปลงเพิ่มเติมที่นี่ การอัปเกรดจาก PDS เป็น DS จำเป็นต้องเปลี่ยนเลเยอร์ฉันทามติเท่านั้น
ใน PDS บล็อกข้อมูลจะถูกดาวน์โหลดอย่างสมบูรณ์โดยไคลเอนต์ที่สอดคล้องกัน บล็อกข้อมูลได้รับการอ้างอิงแล้ว แต่ไม่ได้รับการเข้ารหัสอย่างสมบูรณ์ในเนื้อหาของบล็อกบีคอน แทนที่จะฝังเนื้อหาทั้งหมดไว้ในร่างกาย เนื้อหาของ Blob จะถูกเผยแพร่แยกกันเป็น "sidecar" แต่ละบล็อกมี blob sidecar ซึ่งดาวน์โหลดอย่างสมบูรณ์ใน PDS จากนั้น DAS (Data Availability Sampling) โดยตัวตรวจสอบความถูกต้องของ DS
ก่อนหน้านี้เราได้กล่าวถึงวิธีกระทำกับ blobs โดยใช้คำมั่นสัญญาแบบพหุนามของ KZG อย่างไรก็ตาม แทนที่จะใช้ KZG โดยตรง EIP-4844 จะใช้สิ่งที่เราใช้จริง นั่นคือแฮชเวอร์ชันของมัน นี่คือ 0x01 ไบต์เดียว (แสดงถึงเวอร์ชัน) ตามด้วย 31 ไบต์สุดท้ายของแฮช SHA256 ของ KZG
เราทำสิ่งนี้เพื่อความเข้ากันได้ของ EVM และความเข้ากันได้แบบส่งต่อ:
ความเข้ากันได้ของ EVM - สัญญาของ KZG คือ 48 ไบต์ ในขณะที่ EVM ใช้ค่า 32 ไบต์ตามธรรมชาติมากกว่า
ความเข้ากันได้แบบส่งต่อ - หากเราเปลี่ยนจาก KZG เป็นอย่างอื่น (เช่น STARK สำหรับการต้านทานควอนตัม) สัญญาสามารถดำเนินการต่อไปได้ 32 ไบต์
EIP-1559 หลายมิติ
ในที่สุด PDS จะสร้างชั้นข้อมูลที่ปรับแต่งได้ - บล็อกข้อมูลจะได้รับตลาดค่าธรรมเนียมเฉพาะของตนเอง พร้อมราคาก๊าซลอยตัวและขีดจำกัดอิสระ ดังนั้นแม้ว่าโครงการ NFT บางโครงการจะขายที่ดินลิงบน L1 จำนวนมาก ค่าใช้จ่ายข้อมูลสะสมของคุณจะไม่เพิ่มขึ้น (แม้ว่าค่าใช้จ่ายในการพิสูจน์หลักฐานจะยุติลงก็ตาม) นี่แสดงให้เห็นว่าต้นทุนหลักของโครงการยกเลิกใดๆ ในปัจจุบันคือการเผยแพร่ข้อมูลไปยัง L1 (แทนที่จะเป็นการพิสูจน์)
ตลาดค่าธรรมเนียมก๊าซไม่มีการเปลี่ยนแปลง และมีการเพิ่มบล็อคข้อมูลเป็นตลาดใหม่:
ค่าธรรมเนียมหยดจะเรียกเก็บเป็นก๊าซ แต่เป็นจำนวนเงินที่เปลี่ยนแปลงได้ซึ่งปรับตามกลไก EIP-1559 ของมันเอง จำนวนเฉลี่ยระยะยาวของ blobs ต่อบล็อกควรเท่ากับเป้าหมายที่ระบุ
มีการประมูลแบบคู่ขนานกันสองรายการที่นี่ - รายการหนึ่งสำหรับการคำนวณและอีกรายการหนึ่งสำหรับ DA นี่เป็นก้าวสำคัญสำหรับการกำหนดราคาทรัพยากรอย่างมีประสิทธิภาพ
สามารถดูการออกแบบที่น่าสนใจได้ ตัวอย่างเช่น อาจมีเหตุผลที่จะเปลี่ยนกลไกการกำหนดราคาก๊าซและหยดในปัจจุบันจาก EIP-1559 เชิงเส้นไปเป็นกลไก EIP-1559 แบบเอ็กซ์โปเนนเชียลใหม่ การใช้งานปัจจุบันไม่ได้เฉลี่ยตามขนาดบล็อกเป้าหมายของเรา เสถียรภาพของค่าธรรมเนียมพื้นฐานในปัจจุบันไม่ดี ส่งผลให้มีการใช้ก๊าซที่สังเกตได้ต่อบล็อกโดยเฉลี่ยสูงกว่าเป้าหมายประมาณ 3%
ส่วนที่ 2 ประวัติศาสตร์กับการจัดการรัฐ
สรุปแนวคิดพื้นฐานโดยย่อ:
ประวัติศาสตร์ - ทุกสิ่งที่เกิดขึ้นบนห่วงโซ่ คุณสามารถใส่ลงในฮาร์ดไดรฟ์ได้โดยตรง เนื่องจากไม่ต้องการการเข้าถึงที่รวดเร็ว นี่คือ 1 ในสมมติฐานที่ซื่อสัตย์ในระยะยาว
สถานะ - ภาพรวมของยอดคงเหลือในบัญชีปัจจุบันทั้งหมด สัญญาอัจฉริยะ ฯลฯ โหนดแบบเต็ม (ปัจจุบัน) จำเป็นต้องมีข้อมูลนี้เพื่อตรวจสอบธุรกรรม มันใหญ่เกินไปสำหรับ RAM และฮาร์ดไดรฟ์ก็ช้าเกินไป - มันเข้ากันได้ดีกับ SSD บล็อกเชนที่มีปริมาณงานสูงช่วยให้สถานะนี้เติบโตอย่างรวดเร็ว เร็วกว่าที่คนทั่วไปสามารถรักษาไว้ในแล็ปท็อปของตนได้ หากผู้ใช้ทั่วไปไม่สามารถรักษาสถานะนั้นได้ พวกเขาจะไม่สามารถตรวจสอบได้อย่างสมบูรณ์ และการกระจายอำนาจก็หมดปัญหา
กล่าวโดยย่อ สิ่งเหล่านี้อาจมีขนาดใหญ่มาก ดังนั้นจึงเป็นเรื่องยากสำหรับคุณที่จะเรียกใช้โหนด หากจำเป็น โหนดจะต้องรักษาข้อมูลนี้ไว้ ถ้ามันยากเกินไปที่จะรันโหนด พวกเราคนปกติจะไม่ทำมัน แย่จัง เราต้องทำให้แน่ใจว่าสิ่งนี้จะไม่เกิดขึ้น
การลดต้นทุนก๊าซข้อมูลการโทรและขีดจำกัดข้อมูลการโทรทั้งหมด (EIP-4488)
PDS เป็นขั้นตอนที่ดีสำหรับ DS และเป็นไปตามข้อกำหนดขั้นสุดท้ายหลายประการ การนำ PDS ไปใช้ภายในกรอบเวลาที่เหมาะสมจะทำให้สามารถเลื่อนกำหนดการ DS ไปข้างหน้าได้
วิธีแก้ไขที่ง่ายกว่าคือ EIP-4488 มันหรูหราน้อยกว่า แต่ก็ยังแก้ปัญหาความเร่งด่วนของค่าธรรมเนียมปัจจุบัน ขออภัย มันไม่ได้ให้ขั้นตอนกับ DS ดังนั้นจึงจะถูกเพิ่มในภายหลังอย่างหลีกเลี่ยงไม่ได้ หากเริ่มรู้สึกว่า PDS ช้ากว่าที่เราต้องการ อาจสมเหตุสมผลที่จะผ่าน EIP-4488 (ซึ่งเป็นการแก้ไขโค้ดเพียงไม่กี่บรรทัด) อย่างรวดเร็ว แล้วจึงเข้าสู่ PDS ในอีกหกเดือนต่อมา เรามีอิสระที่จะใช้เวลาของเรา
EIP-4488 มีสององค์ประกอบหลัก:
ลดต้นทุนข้อมูลการโทรจาก 16 แก๊สต่อไบต์เป็น 3 แก๊สต่อไบต์
เพิ่มขีดจำกัด Calldata 1MB ต่อบล็อก บวกเพิ่มอีก 300 ไบต์ต่อธุรกรรม (สูงสุดตามทฤษฎีรวมประมาณ 1.4MB)
ต้องเพิ่มขีดจำกัดเพื่อป้องกันสิ่งที่เลวร้ายที่สุด - บล็อกที่เต็มไปด้วยข้อมูลการโทรจะสูงถึง 18MB ซึ่งมากเกินกว่าที่ Ethereum จะรับมือได้ EIP-4488 เพิ่มความจุข้อมูลเฉลี่ยของ Ethereum แต่เนื่องจากขีดจำกัดของ calldata (30 ล้าน gas/16 gas ต่อ calldata byte = 1.875MB) ความจุข้อมูลการระเบิดจะลดลงเล็กน้อย
โหลดที่ต่อเนื่องสำหรับ EIP-4488 นั้นสูงกว่า PDS มาก เนื่องจากยังคงเป็น calldata เทียบกับ data block (ซึ่งสามารถตัดออกได้หลังจากผ่านไปหนึ่งเดือน) ด้วย EIP-4488 อัตราการเติบโตจะเพิ่มขึ้นอย่างมีความหมาย แต่จะสร้างปัญหาคอขวดสำหรับการรันโหนดด้วย แม้ว่า EIP-4444 จะถูกติดตั้งพร้อมกับ EIP-4488 แต่จะลดประวัติเพย์โหลดการดำเนินการในอีกหนึ่งปีต่อมาเท่านั้น โหลดอย่างต่อเนื่องที่ต่ำกว่าของ PDS จะดีกว่าอย่างชัดเจน
ตรวจสอบข้อมูลประวัติในไคลเอนต์การดำเนินการ (EIP-4444)
EIP-4444 ช่วยให้ลูกค้าสามารถเลือกตัดข้อมูลประวัติภายในเครื่อง (รวมถึงส่วนหัว เนื้อหา และใบเสร็จรับเงิน) ที่เก่ากว่าหนึ่งปี โดยมีเงื่อนไขว่าไคลเอนต์หยุดให้ข้อมูลประวัติที่ถูกตัดที่เลเยอร์ p2p การตัดข้อมูลประวัติช่วยให้ลูกค้าลดความต้องการพื้นที่เก็บข้อมูลดิสก์ของผู้ใช้ (ปัจจุบันหลายร้อยกิกะไบต์และเพิ่มขึ้นอีกเรื่อยๆ)
สิ่งนี้มีความสำคัญอยู่แล้ว แต่ถ้าใช้ EIP-4488 โดยทั่วไปจะเป็นข้อบังคับ (เพราะจะเพิ่มข้อมูลประวัติอย่างมาก) เราหวังว่าจะสามารถทำได้ในระยะเวลาอันสั้น ในที่สุดก็ต้องมีการหมดอายุของประวัติบางรูปแบบ ดังนั้นตอนนี้เป็นเวลาที่ดีในการจัดการกับมัน
ประวัติเป็นสิ่งจำเป็นสำหรับการซิงโครไนซ์เชนอย่างสมบูรณ์ แต่ไม่ใช่สำหรับการตรวจสอบบล็อกใหม่ (สถานะเท่านั้น) ดังนั้น เมื่อไคลเอนต์ซิงค์กับห่วงโซ่ด้านบนแล้ว ข้อมูลประวัติจะถูกดึงมาเฉพาะเมื่อมีการร้องขออย่างชัดแจ้งผ่าน JSON-RPC หรือเมื่อเพียร์พยายามซิงค์เชน เมื่อใช้ EIP-4444 เราจำเป็นต้องค้นหาทางเลือกอื่นสำหรับสิ่งเหล่านี้
ลูกค้าจะไม่สามารถทำการ "ซิงค์แบบเต็ม" กับ devp2p เหมือนที่ทำอยู่ในปัจจุบัน แต่จะ "ซิงก์จุดตรวจสอบ" จากจุดตรวจสอบเชิงอัตนัยที่อ่อนแอแทน ซึ่งพวกเขาจะมองว่าเป็นบล็อกการกำเนิด
โปรดทราบว่าความเป็นตัวตนที่อ่อนแอจะไม่เป็นข้อสันนิษฐานเพิ่มเติม - เป็นสิ่งที่หลีกเลี่ยงไม่ได้เมื่อเปลี่ยนไปใช้ PoS เนื่องจากความเป็นไปได้ของการโจมตีจากระยะไกล จึงจำเป็นต้องใช้จุดตรวจสอบความเป็นส่วนตัวที่อ่อนแออย่างมีประสิทธิภาพสำหรับการซิงโครไนซ์ สมมติฐานที่นี่คือไคลเอนต์จะไม่ซิงค์จากจุดตรวจสอบที่ไม่ถูกต้องหรือเก่าที่มีความเป็นส่วนตัวต่ำ จุดตรวจสอบนี้ต้องอยู่ภายในระยะเวลาที่เราเริ่มตัดข้อมูลประวัติ (ที่นี่ภายในหนึ่งปี) มิฉะนั้นชั้น p2p จะไม่สามารถให้ข้อมูลที่จำเป็นได้
สิ่งนี้จะลดการใช้แบนด์วิธบนเครือข่าย เนื่องจากลูกค้าจำนวนมากขึ้นเรื่อยๆ หันมาใช้กลยุทธ์การซิงค์แบบไลท์เวท
กู้คืนข้อมูลทางประวัติศาสตร์
EIP-4444 จะตัดข้อมูลย้อนหลังหลังจากหนึ่งปีฟังดูดี ในขณะที่ PDS จะตัด blobs เร็วขึ้น (หลังจากประมาณหนึ่งเดือน) สิ่งเหล่านี้เป็นการดำเนินการที่จำเป็นเนื่องจากเราไม่สามารถกำหนดให้โหนดเก็บข้อมูลทั้งหมดและยังคงกระจายอำนาจได้
EIP-4488 - อาจต้องการประมาณ 1MB ต่อซ็อกเก็ตในระยะยาว เพิ่มพื้นที่เก็บข้อมูลประมาณ 2.5TB ต่อปี
PDS - กำหนดเป้าหมาย ~1MB ต่อซ็อกเก็ต เพิ่มพื้นที่เก็บข้อมูล ~2.5TB ต่อปี
DS - กำหนดเป้าหมาย ~16MB ต่อซ็อกเก็ต เพิ่มพื้นที่เก็บข้อมูล ~40TB ต่อปี
แต่ข้อมูลไปไหน? เรายังต้องการพวกเขาอยู่หรือไม่? ได้ แต่โปรดทราบว่าการสูญเสียข้อมูลประวัติไม่ได้มีความเสี่ยงต่อโปรโตคอล - เฉพาะกับแอปพลิเคชันแต่ละรายการเท่านั้น ดังนั้น การทำงานของโปรโตคอลหลักของ Ethereum จึงไม่ควรรวมถึงการรักษาข้อมูลที่เป็นเอกฉันท์ทั้งหมดเหล่านี้อย่างถาวร
แล้วใครจะเป็นผู้จัดเก็บข้อมูลนี้? นี่คือผู้มีส่วนร่วมบางส่วน:
อาสาสมัครรายบุคคลและสถาบัน
Block explorers (เช่น etherscan.io) ผู้ให้บริการ API และบริการข้อมูลอื่นๆ
โปรโตคอลการจัดทำดัชนีของบุคคลที่สามเช่น TheGraph สามารถสร้างตลาดที่มีแรงจูงใจซึ่งลูกค้าจ่ายเซิร์ฟเวอร์สำหรับข้อมูลประวัติด้วยหลักฐานของ Merkle
ลูกค้าใน Portal Network (กำลังอยู่ในระหว่างการพัฒนา) สามารถเก็บส่วนสุ่มของประวัติเชน และ Portal Network จะส่งคำขอข้อมูลไปยังโหนดที่เป็นเจ้าของข้อมูลโดยอัตโนมัติ
ตัวอย่างเช่น BitTorrent จะสร้างและแจกจ่ายไฟล์ขนาด 7GB ที่มีข้อมูล Blob สำหรับบล็อกแต่ละวันโดยอัตโนมัติ
โปรโตคอลแอปพลิเคชันบางอย่าง (เช่น การยกเลิก) สามารถกำหนดให้โหนดจัดเก็บส่วนต่าง ๆ ของประวัติที่เกี่ยวข้องกับแอปพลิเคชันของตนได้
ปัญหาการจัดเก็บข้อมูลระยะยาวเป็นปัญหาที่ค่อนข้างง่ายเพราะเป็นหนึ่งในสมมติฐานความน่าเชื่อถือ N ดังที่เราได้กล่าวไว้ก่อนหน้านี้ ปัญหานี้ยังอีกหลายปีกว่าจะกลายมาเป็นขีดจำกัดสูงสุดของความสามารถในการปรับขนาดของบล็อคเชน
ภาวะไร้สัญชาติที่อ่อนแอ
โอเค เรามีการจัดการประวัติศาสตร์ที่ดีแล้ว แล้วรัฐล่ะ? นี่เป็นคอขวดหลักในการปรับปรุง TPS ของ Ethereum ในปัจจุบัน
โหนดแบบเต็มใช้รูทก่อนสถานะ ดำเนินการธุรกรรมทั้งหมดในบล็อก และตรวจสอบว่ารูทหลังสถานะตรงกับสิ่งที่พวกเขาให้ไว้ในบล็อก เพื่อให้ทราบว่าธุรกรรมเหล่านี้ถูกต้องหรือไม่ ปัจจุบันจำเป็นต้องตรวจสอบสถานะในมือ
ไร้รัฐไร้สัญชาติ - ไม่ต้องการให้รัฐเข้ามามีบทบาท Ethereum กำลังดำเนินการไปสู่การเป็น "คนไร้สัญชาติอย่างอ่อนแอ" หมายความว่าสถานะนั้นไม่จำเป็นต้องตรวจสอบบล็อก แต่จำเป็นต้องสร้างบล็อก การตรวจสอบความถูกต้องกลายเป็นฟังก์ชันบริสุทธิ์ - ให้บล็อกที่แยกออกมาทั้งหมดให้ฉันและฉันสามารถบอกคุณได้ว่าใช้งานได้หรือไม่ โดยทั่วไปเช่นนี้:
ผู้สร้างยังคงต้องการสถานะเนื่องจาก PBS ซึ่งยอมรับได้ - พวกเขาจะเป็นเอนทิตีการกำหนดค่าสูงแบบรวมศูนย์มากกว่าอยู่ดี เรามุ่งเน้นที่การกระจายอำนาจของผู้ตรวจสอบความถูกต้อง การไร้รัฐไร้สัญชาติที่อ่อนแอทำให้ผู้สร้างงานเพิ่มขึ้นเล็กน้อยและผู้ตรวจสอบก็ทำงานน้อยลงมาก มาก.
เราใช้พยานเพื่อให้บรรลุถึงการประหารชีวิตไร้สัญชาติที่มีมนต์ขลังนี้ พยานคือหลักฐานการเข้าถึงสถานะที่ถูกต้อง และผู้สร้างจะเริ่มรวมหลักฐานเหล่านี้ในทุกช่วงตึก คุณไม่จำเป็นต้องใช้สถานะทั้งหมดเพื่อตรวจสอบความถูกต้องของบล็อก - คุณต้องใช้สถานะที่อ่านหรือได้รับผลกระทบจากธุรกรรมในบล็อกนั้นเท่านั้น ผู้สร้างจะเริ่มรวมชิ้นส่วนของรัฐที่ได้รับผลกระทบจากการทำธุรกรรมในบล็อกที่กำหนด และพวกเขาจะใช้พยานเพื่อยืนยันว่าพวกเขาเข้าถึงสถานะเหล่านั้นอย่างถูกต้อง
ลองมาเป็นตัวอย่าง อลิซต้องการส่ง 1 ETH ให้ Bob ในการตรวจสอบการบล็อกสำหรับธุรกรรมนี้ ฉันจำเป็นต้องทราบ:
ก่อนการทำธุรกรรม - อลิซมี 1 ETH
กุญแจสาธารณะของอลิซ - เพื่อให้ฉันรู้ว่าลายเซ็นนั้นถูกต้อง
อลิซไม่มีเหตุผล - ดังนั้นฉันจึงรู้ว่าธุรกรรมถูกส่งไปตามลำดับที่ถูกต้อง
หลังจากทำธุรกรรม Bob ได้รับ 1 ETH และ Alice เสีย 1 ETH
ในโลกไร้สัญชาติที่อ่อนแอ ผู้สร้างเพิ่มข้อมูลพยานดังกล่าวเพื่อบล็อกและยืนยันความถูกต้อง Validators ได้รับบล็อก ดำเนินการ และตัดสินใจว่าถูกต้องหรือไม่ ไม่เป็นไร.
จากมุมมองของผู้ตรวจสอบความถูกต้อง ต่อไปนี้เป็นนัยบางประการ:
ความต้องการ SSD ขนาดใหญ่ที่จำเป็นต่อการรักษาสถานะนั้นหายไป ซึ่งเป็นปัญหาคอขวดที่สำคัญในการปรับขนาดในปัจจุบัน
ความต้องการแบนด์วิธจะเพิ่มขึ้นเล็กน้อยเนื่องจากขณะนี้คุณกำลังดาวน์โหลดข้อมูลพยานและหลักฐานด้วย นี่เป็นคอขวดสำหรับต้นไม้ Merkle-Patricia แต่ไม่ใช่ปัญหาใหญ่ ไม่ใช่คอขวดแบบที่ Verkle Tries เจอ
คุณยังคงดำเนินธุรกรรมเพื่อตรวจสอบความถูกต้องอย่างสมบูรณ์ การไร้สัญชาติยอมรับความจริงที่ว่าปัจจุบันนี้ไม่ใช่คอขวดในการปรับขนาด Ethereum
การไร้รัฐไร้สัญชาติที่อ่อนแอยังช่วยให้ Ethereum ผ่อนคลายข้อจำกัดที่กำหนดขึ้นเองในด้านปริมาณการประมวลผล และการขยายสถานะจะไม่เป็นปัญหาเร่งด่วนอีกต่อไป อาจมีเหตุผลที่จะเพิ่มขีด จำกัด ของก๊าซเป็น 3 เท่า
ณ จุดนี้ การดำเนินการของผู้ใช้ส่วนใหญ่จะอยู่ที่ L2 แต่ปริมาณงาน L1 ที่สูงกว่าจะเป็นประโยชน์สำหรับพวกเขาด้วยซ้ำ การยกเลิกขึ้นอยู่กับ Ethereum สำหรับ DA (เผยแพร่ไปยังเศษ) และการชำระเงิน (ต้องใช้การดำเนินการ L1) เมื่อ Ethereum ขยายเลเยอร์ DA ออกไป ค่าใช้จ่ายในการออกหลักฐานการตัดจำหน่ายอาจใช้ส่วนแบ่งที่มากขึ้นของต้นทุนการยกเลิก (โดยเฉพาะอย่างยิ่งสำหรับ ZK-rollup)
Verkle พยายาม (พยายาม Verkle)
เราจงใจข้ามวิธีการทำงานของพยานเหล่านี้ไป ปัจจุบัน Ethereum ใช้ต้นไม้ Merkle-Patricia เพื่อจัดเก็บสถานะ แต่หลักฐานที่จำเป็นของ Merkle นั้นใหญ่เกินไปที่พยานเหล่านี้จะเป็นไปได้
Ethereum จะหันไปหา Verkle ที่พยายามจัดเก็บสถานะ การพิสูจน์ของ Verkle มีประสิทธิภาพมากกว่ามาก ดังนั้นจึงสามารถใช้เป็นพยานที่พิสูจน์ได้เพื่อให้บรรลุถึงภาวะไร้รัฐไร้สัญชาติที่อ่อนแอ
ก่อนอื่นเรามาทบทวนว่าต้นไม้ Merkle มีลักษณะอย่างไร ทุกธุรกรรมเริ่มต้นด้วยแฮช - แฮชเหล่านี้ที่ด้านล่างเรียกว่า "ลีฟ" ค่าแฮชทั้งหมดเรียกว่า "โหนด" ซึ่งเป็นค่าแฮชของโหนดลูกทั้งสองด้านล่าง แฮชที่ได้คือ "ราก Merkle"
โครงสร้างข้อมูลนี้มีประโยชน์มากในการพิสูจน์ความสมบูรณ์ของการทำธุรกรรมโดยไม่ต้องดาวน์โหลดทรีทั้งหมด ตัวอย่างเช่น หากคุณต้องการตรวจสอบว่าธุรกรรม H4 รวมอยู่ด้วย คุณต้องมี H12, H3 และ H5678 จากการพิสูจน์ของ Merkle เรามี H12345678 จากส่วนหัวของบล็อก ดังนั้นไคลเอนต์ที่มีน้ำหนักเบาสามารถขอโหนดแบบเต็มสำหรับแฮชเหล่านี้ และแฮชพวกมันเข้าด้วยกันตามเส้นทางในแผนผัง หากผลลัพธ์คือ H12345678 แสดงว่าเราได้พิสูจน์แล้วว่า H4 อยู่บนต้นไม้ได้สำเร็จ
แต่ยิ่งต้นไม้ลึกเท่าไร เส้นทางสู่ก้นเหวก็จะยิ่งยาวขึ้น คุณจึงต้องการไอเท็มมากขึ้นเพื่อพิสูจน์ ดังนั้นต้นไม้ที่ตื้นและกว้างจึงเหมาะสำหรับการพิสูจน์ที่มีประสิทธิภาพ
ปัญหาคือถ้าคุณพยายามทำให้ Merkle tree กว้างขึ้นโดยการเพิ่มโหนดย่อยเข้าไปในแต่ละโหนด มันจะไร้ประสิทธิภาพอย่างมาก คุณต้องแฮชค่าแฮชของโหนดเพียร์ทั้งหมดเข้าด้วยกันเพื่อสัมผัสทั้งทรี ดังนั้นคุณต้องยอมรับค่าแฮชของโหนดเพียร์ที่มากขึ้นสำหรับการพิสูจน์ Merkle สิ่งนี้จะทำให้ขนาดของหลักฐานมีขนาดใหญ่
นี่คือคำสัญญาของเวกเตอร์ที่มีประสิทธิภาพ โปรดทราบว่าแฮชที่ใช้ใน Merkle tree นั้นแท้จริงแล้วเป็นการผูกมัดเวกเตอร์ - เป็นเพียงการผูกมัดที่ไม่ดีที่สามารถผูกมัดได้อย่างมีประสิทธิภาพกับสององค์ประกอบเท่านั้น ดังนั้นเราจึงต้องการความมุ่งมั่นของเวกเตอร์ที่เราไม่จำเป็นต้องได้รับเพื่อนทั้งหมดเพื่อยืนยัน เมื่อได้สิ่งนี้แล้ว เราสามารถทำให้ต้นไม้กว้างขึ้นและลดความลึกลงได้ นี่คือวิธีที่เราบรรลุขนาดการพิสูจน์ที่มีประสิทธิภาพ - ลดจำนวนข้อมูลที่ต้องจัดเตรียม
Trie ของ Verkle นั้นคล้ายกับ Merkle tree แต่จะมอบลูกของมันโดยใช้พันธะเวกเตอร์ที่มีประสิทธิภาพ (เพราะฉะนั้นชื่อ "Verkle") แทนที่จะเป็นแฮชธรรมดา แนวคิดพื้นฐานคือแต่ละโหนดสามารถมีลูกได้หลายคน แต่ฉันไม่ต้องการทุกโหนดเพื่อยืนยันการพิสูจน์ นี่คือหลักฐานของขนาดคงที่โดยไม่คำนึงถึงความกว้าง
อันที่จริง เราได้กล่าวถึงตัวอย่างที่ดีของความเป็นไปได้นี้มาก่อน - ข้อผูกพันของ KZG สามารถใช้เป็นข้อผูกพันเวกเตอร์ได้ อันที่จริงแล้ว นี่คือสิ่งที่ผู้พัฒนา ethereum วางแผนไว้ตั้งแต่แรกว่าจะใช้ที่นี่ ต่อมาพวกเขาหันมาใช้ความมุ่งมั่นของ Pedersen เพื่อบรรลุบทบาทที่คล้ายกัน มันจะขึ้นอยู่กับเส้นโค้งวงรี (ในที่นี้หมายถึง Bandersnatch) โดยมีค่า 256 ค่า (ดีกว่าสองมาก!)
เหตุใดจึงไม่สร้างต้นไม้ที่มีความลึก 1 ให้กว้างที่สุด นี่เป็นสิ่งที่ดีสำหรับผู้ตรวจสอบเพราะตอนนี้เขามีหลักฐานที่กะทัดรัดมาก แต่มีการแลกเปลี่ยนในทางปฏิบัติที่ผู้ตรวจสอบจำเป็นต้องสามารถคำนวณหลักฐานนี้ได้ และยิ่งกว้างเท่าไรก็ยิ่งยากขึ้นเท่านั้น ดังนั้น ความพยายามของ Verkle จะอยู่ระหว่างสองสุดขั้วของค่าความกว้าง 1~256 ค่า
สถานะหมดอายุ
การไร้สัญชาติที่อ่อนแอช่วยขจัดข้อจำกัดเงินเฟ้อของรัฐออกจากเครื่องมือตรวจสอบความถูกต้อง แต่รัฐไม่ได้หายไปอย่างน่าอัศจรรย์ ค่าใช้จ่ายในการทำธุรกรรมถูกจำกัดไว้ แต่จะเรียกเก็บภาษีถาวรในเครือข่ายโดยการเพิ่มสถานะ การเติบโตของรัฐยังคงเป็นอุปสรรคต่อเครือข่ายอย่างถาวร เราต้องทำอะไรบางอย่างเพื่อแก้ไขปัญหาพื้นฐานนี้
นั่นเป็นเหตุผลที่เราต้องการการหมดอายุของรัฐ การไม่มีการใช้งานเป็นเวลานาน (เช่น 1 หรือ 2 ปี) จะถูกกำจัด แม้แต่สิ่งที่ผู้สร้างบล็อกอาจรวมไว้ ผู้ใช้ที่ใช้งานอยู่จะไม่สังเกตเห็นการเปลี่ยนแปลงใดๆ และเราสามารถละทิ้งสถานะที่ไม่จำเป็นอีกต่อไป
หากคุณต้องการกู้คืนสถานะที่หมดอายุ คุณเพียงแค่ต้องแสดงหลักฐานและเปิดใช้งานอีกครั้ง สิ่งนี้ย้อนกลับไปที่สมมติฐานการจัดเก็บ N ข้อใดข้อหนึ่ง ตราบใดที่บางคนยังมีประวัติครบถ้วน (ตัวสำรวจบล็อก ฯลฯ) คุณจะได้รับสิ่งที่คุณต้องการจากพวกเขา
ภาวะไร้รัฐไร้สัญชาติที่อ่อนแอจะทำให้ความต้องการการหมดอายุของสถานะในชั้นฐานลดลงในทันที แต่จะส่งผลดีในระยะยาว โดยเฉพาะอย่างยิ่งเมื่อปริมาณงาน L1 เพิ่มขึ้น สำหรับการยกเลิกปริมาณงานสูง นี่จะเป็นเครื่องมือที่มีประโยชน์มากกว่า สถานะ L2 จะเติบโตในอัตราที่สูงกว่าซึ่งจะฉุดรั้งแม้แต่ผู้สร้างการกำหนดค่าที่สูง
ตอนที่ 3 ทุกอย่างเป็นความผิดของ MEV
PBS เป็นเงื่อนไขที่จำเป็นสำหรับการใช้งาน DS (Danksharding) อย่างปลอดภัย แต่โปรดจำไว้ว่าการออกแบบดั้งเดิมนั้นแท้จริงแล้วมีไว้เพื่อต่อต้านอำนาจรวมศูนย์ของ MEV คุณจะสังเกตเห็นแนวโน้มที่เกิดขึ้นซ้ำๆ ในการวิจัย Ethereum ในวันนี้ — ขณะนี้ MEV อยู่แถวหน้าและเป็นศูนย์กลางของเศรษฐศาสตร์คริปโต
เมื่อออกแบบบล็อกเชน การคำนึงถึง MEV เป็นกุญแจสำคัญในการรักษาความปลอดภัยและการกระจายอำนาจ วิธีการระดับโปรโตคอลพื้นฐานคือ:
ลด MEV ที่เป็นอันตรายให้ได้มากที่สุด (เช่น single slot Finality การเลือกผู้นำแบบลับเดียว)
ทำให้ส่วนที่เหลือเป็นประชาธิปไตย (เช่น MEV-Boost, PBS, MEV smoothing)
ส่วนที่เหลือจะต้องถูกจับและเผยแพร่ได้อย่างง่ายดายในหมู่ผู้ตรวจสอบความถูกต้อง มิฉะนั้นจะเป็นการรวมศูนย์กลุ่มผู้ตรวจสอบความถูกต้องโดยไม่สามารถแข่งขันกับผู้ค้นหาที่มีความซับซ้อนได้ สิ่งนี้เลวร้ายยิ่งขึ้นเมื่อ MEV เป็นเปอร์เซ็นต์ที่สูงขึ้นของรางวัลผู้ตรวจสอบความถูกต้องหลังจากการควบรวมกิจการ (การออกการเดิมพันต่ำกว่าอัตราเงินเฟ้อที่มอบให้กับนักขุด) สิ่งนี้ไม่สามารถเพิกเฉยได้
ห่วงโซ่อุปทานของ MEV ในปัจจุบัน
ลำดับเหตุการณ์วันนี้มีดังนี้
สระขุดมีบทบาทของผู้สร้างที่นี่ ผู้แสวงหา MEV ส่งต่อชุดธุรกรรม (พร้อมกับการเสนอราคาที่เกี่ยวข้อง) ไปยังกลุ่มการขุดผ่าน Flashbots ผู้ดำเนินการกลุ่มการขุดรวมบล็อกที่สมบูรณ์และส่งส่วนหัวของบล็อกไปยังนักขุดแต่ละคน นักขุดใช้ PoW เพื่อพิสูจน์บล็อกและให้น้ำหนักในกฎการเลือกส้อม
Flashbots อยู่ที่นี่เพื่อป้องกันการรวมในแนวดิ่งของสแต็กทั้งหมด ซึ่งจะเปิดประตูสู่การเซ็นเซอร์และบุคคลภายนอกที่น่ารังเกียจอื่นๆ เมื่อ Flashbots ถือกำเนิดขึ้น
IOS
Android