คำอธิบายโดยละเอียด 4 มิติของ Danksharding: หรือการอัปเกรดขั้นต่อไปของ Ethereum?
ผู้แต่ง: Vitalik Buterin
Vitalik Buterin ผู้ก่อตั้ง Ethereum เพิ่งตอบคำถามที่เกี่ยวข้องกับ Proto-danksharding (หรือที่รู้จักในชื่อ EIP-4844) Danksharding คือการออกแบบ Sharding ใหม่ที่เสนอสำหรับ Ethereum เทคโนโลยีนี้นำมาซึ่งอะไร
Danksharding คืออะไร?
Danksharding คือการออกแบบ Sharding ใหม่ที่เสนอสำหรับ Ethereum ซึ่งนำเสนอความเรียบง่ายที่สำคัญบางอย่างเมื่อเทียบกับการออกแบบก่อนหน้านี้
ข้อแตกต่างหลักระหว่างข้อเสนอการแชร์ Ethereum ล่าสุดทั้งหมดตั้งแต่ปี 2020 (รวมถึง Danksharding และ Danksharding ก่อนหน้า) และข้อเสนอการแชร์ข้อมูลที่ไม่ใช่ Ethereum ส่วนใหญ่คือแผนงานที่เน้นการรวมศูนย์ของ Ethereum: Ethereum Sharding Shards ไม่ได้ให้พื้นที่เพิ่มเติมสำหรับธุรกรรม แต่สำหรับข้อมูล ซึ่ง Ethereum โปรโตคอลเองไม่ได้พยายามอธิบาย
การตรวจสอบความถูกต้องของ blob เป็นการตรวจสอบว่ามี blob นั้นอยู่ นั่นคือสามารถดาวน์โหลดได้จากเครือข่าย พื้นที่ข้อมูลใน Blob เหล่านี้คาดว่าจะใช้โดยโปรโตคอล Rollup เลเยอร์ 2 (เลเยอร์ 2) ที่รองรับธุรกรรมปริมาณงานสูง
นวัตกรรมหลักที่นำเสนอโดย Danksharding คือตลาดค่าธรรมเนียมแบบรวม: แทนที่จะเป็นจำนวนที่แน่นอนของชาร์ด แต่ละชาร์ดมีบล็อกที่แตกต่างกันและผู้เสนอบล็อกที่แตกต่างกัน ใน Danksharding มีเพียงผู้เสนอรายเดียวเท่านั้นที่เลือกเข้าสู่ช่องธุรกรรมทั้งหมดและข้อมูลทั้งหมด
เพื่อหลีกเลี่ยงความต้องการของระบบที่สูงสำหรับผู้ตรวจสอบในการออกแบบนี้ เราแนะนำการแยกผู้เสนอ/ผู้สร้าง (PBS): ผู้เข้าร่วมคลาสพิเศษที่เรียกว่าผู้สร้างบล็อกเสนอราคาสำหรับสิทธิ์ในการเลือกช่อง และผู้เสนอต้องการเพียงเลือกการเสนอราคา ส่วนหัวที่ถูกต้องสูงสุดก็เพียงพอแล้ว .
เฉพาะผู้สร้างบล็อกเท่านั้นที่ต้องประมวลผลบล็อกทั้งหมด (ที่นี่ โปรโตคอล oracle แบบกระจายอำนาจของบุคคลที่สามสามารถใช้เพื่อใช้งานตัวสร้างบล็อกแบบกระจาย) เครื่องมือตรวจสอบและผู้ใช้อื่นๆ ทั้งหมดสามารถสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลได้อย่างมีประสิทธิภาพมาก ตรวจสอบความถูกต้องของบล็อก (โปรดจำไว้ว่า: "ใหญ่" ส่วนหนึ่งของบล็อกเป็นเพียงข้อมูล)
Proto-danksharding คืออะไร (หรือที่เรียกว่า EIP-4844)
Proto-danksharding (หรือที่เรียกว่า EIP-4844) เป็น Ethereum Improvement Proposal (EIP) ที่ใช้ตรรกะและ "scaffolding" ส่วนใหญ่ (เช่น รูปแบบธุรกรรม กฎการตรวจสอบความถูกต้อง) ซึ่งประกอบขึ้นเป็นข้อกำหนด Danksharding เต็มรูปแบบ แต่ยังไม่ได้ใช้งานส่วนใดส่วนหนึ่ง . ในการใช้งาน proto-danksharding ผู้ตรวจสอบความถูกต้องและผู้ใช้ทั้งหมดยังคงต้องยืนยันความพร้อมใช้งานของข้อมูลทั้งหมดโดยตรง
คุณสมบัติหลักที่แนะนำโดย proto-danksharding คือประเภทธุรกรรมใหม่ ซึ่งเราเรียกว่าธุรกรรมที่มีหยด ธุรกรรมที่มี blob นั้นคล้ายกับธุรกรรมทั่วไป ยกเว้นว่ามันยังมีข้อมูลเพิ่มเติมที่เรียกว่า blob Blobs มีขนาดใหญ่มาก (~ 125 kB) และราคาถูกกว่า calldata ในจำนวนที่ใกล้เคียงกันมาก อย่างไรก็ตาม การดำเนินการ EVM ไม่สามารถเข้าถึงข้อมูล blob ได้ EVM สามารถเห็นได้เฉพาะสัญญากับ blob เท่านั้น
เนื่องจากตัวตรวจสอบความถูกต้องและไคลเอนต์ยังคงต้องดาวน์โหลดเนื้อหา Blob แบบเต็ม เป้าหมายแบนด์วิธข้อมูลใน proto-danksharding คือ 1 MB ต่อซ็อกเก็ตแทนที่จะเป็น 16 MB เต็ม อย่างไรก็ตาม เนื่องจากข้อมูลนี้ไม่สามารถแข่งขันกับการใช้ก๊าซของธุรกรรม Ethereum ที่มีอยู่ได้ จึงยังคงมีประโยชน์ด้านความสามารถในการขยายขนาดใหญ่
เหตุใดจึงเป็นเรื่องปกติที่จะเพิ่มข้อมูล 1 MB ลงในอันที่ทุกคนต้องดาวน์โหลด แทนที่จะทำให้ calldata ถูกลง 10 เท่า
สิ่งนี้เกี่ยวข้องกับความแตกต่างระหว่างโหลดเฉลี่ยและโหลดกรณีที่แย่ที่สุด วันนี้เราพบสถานการณ์ที่มีขนาดบล็อกเฉลี่ยอยู่ที่ประมาณ 90 kB แต่ขนาดบล็อกสูงสุดที่เป็นไปได้ในทางทฤษฎี (หากใช้แก๊ส 30M ทั้งหมดในบล็อกเพื่อเรียกข้อมูล) อยู่ที่ประมาณ 1.8 MB เครือข่าย Ethereum ใช้ในการประมวลผลใกล้เคียงกับจำนวนบล็อกสูงสุด
อย่างไรก็ตาม หากเราลดค่า calldata gas ลง 10 เท่า แม้ว่าขนาดบล็อกเฉลี่ยจะเพิ่มขึ้นจนถึงระดับที่ยอมรับได้ แต่กรณีที่แย่ที่สุดจะกลายเป็น 18 MB ซึ่งมากเกินไปสำหรับเครือข่าย Ethereum มากเกินไป
รูปแบบการกำหนดราคาก๊าซในปัจจุบันไม่สามารถแยกปัจจัยทั้งสองนี้ได้: อัตราส่วนระหว่างโหลดเฉลี่ยและโหลดกรณีที่เลวร้ายที่สุดขึ้นอยู่กับทางเลือกของผู้ใช้ว่าจะใช้ก๊าซเท่าใดกับข้อมูลการโทรเทียบกับทรัพยากรอื่นๆ ซึ่งหมายความว่าราคาก๊าซจะต้องขึ้นอยู่กับ กรณีที่เลวร้ายที่สุด การตั้งค่าความน่าจะเป็น ทำให้ค่าเฉลี่ยโหลดต่ำกว่าที่ระบบสามารถจัดการได้โดยไม่จำเป็น
อย่างไรก็ตาม หากเราเปลี่ยนราคาก๊าซเพื่อสร้างตลาดค่าธรรมเนียมแบบหลายมิติอย่างชัดเจนมากขึ้น เราสามารถหลีกเลี่ยงการโหลดกรณีเฉลี่ย/กรณีแย่ที่สุดที่ไม่ตรงกัน และรวมในแต่ละบล็อกให้ใกล้เคียงกับจำนวนข้อมูลสูงสุดที่เราสามารถจัดการได้อย่างปลอดภัย Proto-danksharding และ EIP-4488 เป็นสองข้อเสนอในการทำเช่นนี้
proto-danksharding เปรียบเทียบกับ EIP-4488 อย่างไร
EIP-4488 เป็นความพยายามก่อนหน้านี้และง่ายกว่าในการแก้ปัญหาการโหลดกรณีเฉลี่ย/กรณีแย่ที่สุดที่ไม่ตรงกัน EIP-4488 ทำสิ่งนี้โดยใช้กฎง่ายๆ สองข้อ:
ค่าแก๊ส Calldata ลดลงจาก 16 แก๊สต่อไบต์เป็น 3 แก๊สต่อไบต์
จำกัด 1 MB ต่อบล็อกบวกเพิ่มอีก 300 ไบต์ต่อการทำธุรกรรม (สูงสุดตามทฤษฎี: ~ 1.4 MB)
ฮาร์ดลิมิตเป็นวิธีที่ง่ายที่สุดเพื่อให้แน่ใจว่าการโหลดกรณีเฉลี่ยที่เพิ่มขึ้นอย่างมากจะไม่ส่งผลให้การโหลดกรณีเลวร้ายที่สุดเพิ่มขึ้น การลดต้นทุนก๊าซจะเพิ่มการใช้การยกเลิกอย่างมาก ซึ่งอาจเพิ่มขนาดบล็อกเฉลี่ยเป็นหลายร้อย KB แต่ขีดจำกัดแบบถาวรจะป้องกันความเป็นไปได้ในกรณีที่เลวร้ายที่สุดโดยตรงของบล็อกเดียวที่มี 10 MB ขนาดบล็อกที่แย่ที่สุดจะเล็กกว่าที่เป็นอยู่ในปัจจุบัน (1.4 MB เทียบกับ 1.8 MB)
Proto-danksharding แทนที่จะสร้างประเภทธุรกรรมแยกต่างหากซึ่งบันทึกข้อมูลที่ถูกกว่าใน blobs ขนาดคงที่ขนาดใหญ่ และจำกัดจำนวน blobs ที่แต่ละบล็อกสามารถบรรจุได้ blobs เหล่านี้ไม่สามารถเข้าถึงได้จาก EVM (เฉพาะข้อผูกมัดกับ blobs) และ blobs จะถูกเก็บไว้โดยเลเยอร์ฉันทามติ (ห่วงโซ่บีคอน) แทนที่จะเป็นเลเยอร์การดำเนินการ
ข้อแตกต่างหลักในทางปฏิบัติระหว่าง EIP-4488 และ Proto-danksharding คือ EIP-4488 พยายามลดการเปลี่ยนแปลงที่จำเป็นในปัจจุบันให้น้อยที่สุด ในขณะที่ Proto-danksharding มีการเปลี่ยนแปลงมากมายในปัจจุบัน ดังนั้นการอัปเกรดเป็น Sharding แบบเต็มในอนาคตจึงจำเป็นต้องเปลี่ยนแปลงเพียงเล็กน้อย
ในขณะที่การนำ Sharding แบบเต็มไปใช้ (โดยใช้การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล ฯลฯ) เป็นงานที่ซับซ้อน และยังคงเป็นงานที่ซับซ้อนหลังจากการทำ Proto-danksharding ความซับซ้อนนี้มีอยู่ในชั้นฉันทามติ เมื่อ proto-danksharding เปิดตัวแล้ว ไม่จำเป็นต้องทำงานเพิ่มเติมจากทีมไคลเอนต์ระดับผู้บริหาร นักพัฒนาชุดรวม และผู้ใช้เพื่อดำเนินการเปลี่ยนไปสู่การแบ่งส่วนที่สมบูรณ์
โปรดทราบว่าตัวเลือกระหว่างทั้งสองไม่ใช่อย่างใดอย่างหนึ่ง/หรือ: เราสามารถนำ EIP-4488 มาใช้โดยเร็วที่สุดเท่าที่จะเป็นไปได้ จากนั้นตามด้วยโปรโต-แดนส์ชาร์ดในอีกครึ่งปีให้หลัง
proto-danksharding ใช้ส่วนใดของ darksharding ที่สมบูรณ์ ต้องดำเนินการอะไรอีกบ้าง
อ้างถึง EIP-4844 งานที่ทำใน EIP นี้ประกอบด้วย:
ธุรกรรมประเภทใหม่ในรูปแบบเดียวกันที่ต้องมีอยู่ใน "full sharding"
ลอจิกเลเยอร์การดำเนินการทั้งหมดที่จำเป็นสำหรับการแบ่งส่วนทั้งหมด
ตรรกะการตรวจสอบข้ามการดำเนินการ/ฉันทามติทั้งหมดที่จำเป็นสำหรับการแบ่งส่วนทั้งหมด
การแยกเลเยอร์ระหว่างการตรวจสอบความถูกต้องของ BeaconBlock และการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล
ตรรกะ BeaconBlock ส่วนใหญ่จำเป็นสำหรับการชาร์ดดิ้งแบบเต็ม
Gasprice อิสระที่ปรับได้เองสำหรับ blobs
งานที่ต้องทำเพื่อให้ได้การแบ่งส่วนที่สมบูรณ์ประกอบด้วย:
ส่วนขยายระดับต่ำของ blob_kzgs ในชั้นฉันทามติเพื่อให้สามารถสุ่มตัวอย่างแบบ 2 มิติได้
การใช้งานจริงของการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล
PBS (การแยกผู้เสนอ/ผู้สร้าง) เพื่อหลีกเลี่ยงการต้องใช้ตัวตรวจสอบความถูกต้องตัวเดียวในการประมวลผลข้อมูล 32 MB ในหนึ่งสล็อต
การพิสูจน์ Escrow หรือข้อกำหนดในโปรโตคอลที่คล้ายกันสำหรับผู้ตรวจสอบความถูกต้องแต่ละคนเพื่อตรวจสอบความถูกต้องของข้อมูลเศษส่วนที่เฉพาะเจาะจงในแต่ละบล็อก
โปรดทราบว่างานที่เหลือทั้งหมดคือการเปลี่ยนแปลงเลเยอร์ที่สอดคล้องกัน และทีมลูกค้า ผู้ใช้ หรือนักพัฒนาชุดค่าสะสมไม่ต้องทำงานเพิ่มเติมใดๆ
จะเกิดอะไรขึ้นถ้าชิ้นส่วนขนาดใหญ่เหล่านี้เพิ่มความต้องการพื้นที่ดิสก์
ทั้ง EIP-4488 และ proto-danksharding นำไปสู่การใช้งานสูงสุดในระยะยาวประมาณ 1 MB ต่อซ็อกเก็ต (12 วินาที) ซึ่งเท่ากับประมาณ 2.5 TB ต่อปี ซึ่งสูงกว่าอัตราการเติบโตที่ Ethereum ต้องการในปัจจุบัน
ในกรณีของ EIP-4488 การแก้ปัญหานี้ต้องใช้แผนการหมดอายุของประวัติ (EIP-4444) ซึ่งลูกค้าไม่จำเป็นต้องเก็บประวัติเกินระยะเวลาที่กำหนดอีกต่อไป (เสนอเวลาต่อเนื่องตั้งแต่ 1 เดือนถึง 1 ปี) .
ในกรณีของ proto-danksharding ไม่ว่าจะใช้ EIP-4444 หรือไม่ก็ตาม ชั้นฉันทามติสามารถใช้ตรรกะแยกต่างหากเพื่อลบข้อมูล blob โดยอัตโนมัติหลังจากช่วงระยะเวลาหนึ่ง (เช่น 30 วัน) อย่างไรก็ตาม ไม่ว่าโซลูชันการปรับขนาดข้อมูลในระยะสั้นจะเป็นเช่นไร เราขอแนะนำให้ใช้ EIP-4444 โดยเร็วที่สุด
ทั้งสองกลยุทธ์จะจำกัดการโหลดดิสก์เพิ่มเติมบนไคลเอนต์ที่สอดคล้องกันไว้ที่สูงสุดไม่กี่ร้อย GB ในระยะยาว การใช้กลไกการหมดอายุในอดีตเป็นสิ่งที่จำเป็นเป็นหลัก: การชาร์ดดิ้งแบบเต็มจะเพิ่มข้อมูล blob ย้อนหลังประมาณ 40 TB ต่อปี ดังนั้นผู้ใช้จึงสามารถจัดเก็บได้เพียงเศษเสี้ยวของข้อมูลชั่วคราวเท่านั้น ดังนั้นจึงควรตั้งความคาดหวังไว้แต่เนิ่นๆ
ผู้ใช้จะเข้าถึง blobs เก่าได้อย่างไรหากข้อมูลถูกลบหลังจาก 30 วัน
วัตถุประสงค์ของโปรโตคอลฉันทามติของ Ethereum ไม่ใช่การรับประกันการจัดเก็บข้อมูลประวัติทั้งหมดอย่างถาวร ความตั้งใจคือการจัดหากระดานข่าวแบบเรียลไทม์ที่มีความปลอดภัยสูง และปล่อยให้มีที่ว่างสำหรับโปรโตคอลแบบกระจายอำนาจอื่นๆ สำหรับการจัดเก็บระยะยาว
กระดานข่าวมีอยู่เพื่อให้แน่ใจว่าข้อมูลที่โพสต์บนกระดานข่าวนั้นมีอยู่นานพอที่ผู้ใช้ที่ต้องการข้อมูลนั้นหรือข้อตกลงระยะยาวในการสำรองข้อมูลมีเวลาเพียงพอในการรับข้อมูลและนำเข้าสู่แอปพลิเคชันอื่นของพวกเขา หรือโปรโตคอล
โดยทั่วไป การจัดเก็บประวัติระยะยาวเป็นเรื่องง่าย แม้ว่า 2.5 TB ต่อปีจะใหญ่เกินไปสำหรับโหนดปกติ แต่ก็สามารถจัดการได้สำหรับผู้ใช้เฉพาะทาง คุณสามารถซื้อฮาร์ดไดรฟ์ขนาดใหญ่มากได้ในราคาประมาณ 20 ดอลลาร์ต่อ TB ซึ่งมากเกินพอสำหรับผู้มีงานอดิเรก
ซึ่งแตกต่างจากฉันทามติซึ่งมีรูปแบบความน่าเชื่อถือ N/2-of-N ที่จัดเก็บประวัติมีรูปแบบความน่าเชื่อถือแบบ 1-of-N: คุณต้องการเพียงหนึ่งในผู้จัดเก็บข้อมูลที่ซื่อสัตย์ ดังนั้น ข้อมูลประวัติแต่ละชิ้นจำเป็นต้องจัดเก็บหลายร้อยครั้งเท่านั้น แทนที่จะเป็นโหนดนับพันที่ทำการตรวจสอบฉันทามติตามเวลาจริง
วิธีปฏิบัติบางประการในการจัดเก็บประวัติทั้งหมดและทำให้เข้าถึงได้ง่าย ได้แก่:
โปรโตคอลเฉพาะแอปพลิเคชัน เช่น Rollup อาจกำหนดให้โหนดจัดเก็บประวัติส่วนที่เกี่ยวข้องกับแอปพลิเคชันของตน ข้อมูลประวัติที่สูญหายไม่ก่อให้เกิดความเสี่ยงต่อโปรโตคอล เฉพาะกับแอปพลิเคชันแต่ละตัว ดังนั้นจึงเหมาะสมที่แอปพลิเคชันจะรับภาระในการจัดเก็บข้อมูลที่เกี่ยวข้องกับตัวเอง
การจัดเก็บข้อมูลย้อนหลังใน BitTorrent เช่น ไฟล์ขนาด 7 GB ที่มีข้อมูล Blob จากบล็อกจะถูกสร้างขึ้นโดยอัตโนมัติและเผยแพร่ทุกวัน
เครือข่ายพอร์ทัล Ethereum (กำลังอยู่ในระหว่างการพัฒนา) สามารถขยายไปสู่การจัดเก็บประวัติได้อย่างง่ายดาย
Block explorer ผู้ให้บริการ API และบริการข้อมูลอื่น ๆ อาจจัดเก็บประวัติทั้งหมด
ผู้ที่ทำงานอดิเรกและนักวิชาการแต่ละคนที่มีส่วนร่วมในการวิเคราะห์ข้อมูลอาจจัดเก็บบันทึกทางประวัติศาสตร์ที่สมบูรณ์ ในกรณีหลังนี้ การจัดเก็บประวัติไว้ในเครื่องจะให้คุณค่าที่สำคัญ เนื่องจากทำให้ง่ายต่อการคำนวณโดยตรง
โปรโตคอลการจัดทำดัชนีของบุคคลที่สาม เช่น TheGraph อาจจัดเก็บประวัติทั้งหมด
ที่พื้นที่จัดเก็บประวัติในระดับที่สูงขึ้น (เช่น 500 TB ต่อปี) ความเสี่ยงที่ข้อมูลบางส่วนจะถูกลืมจะสูงขึ้น (นอกจากนี้ ระบบการตรวจสอบความพร้อมใช้งานของข้อมูลจะเข้มงวดมากขึ้น) นี่อาจเป็นขีดจำกัดที่แท้จริงของความสามารถในการปรับขนาดสำหรับบล็อกเชนแบบแยกส่วน อย่างไรก็ตาม พารามิเตอร์ที่เสนอทั้งหมดอยู่ไกลจากจุดนี้มาก
ข้อมูล Blob อยู่ในรูปแบบใด และส่งอย่างไร
หยดเป็นเวกเตอร์ขององค์ประกอบฟิลด์ 4096 ตัวเลขในช่วง:
0 <= x < 52435875175126190479447740508185965837690552500527637822603658699938581184513
หยดหนึ่งถูกมองในทางคณิตศาสตร์ว่าเป็นตัวแทนของพหุนามที่มีดีกรี < 4096 บนฟิลด์จำกัดที่มีโมดูลัสด้านบน โดยที่องค์ประกอบฟิลด์ที่ตำแหน่ง i ในหยดคือการประเมินพหุนามนั้นที่ wi w เป็นค่าที่น่าพอใจคงที่ w=1
ความมุ่งมั่นต่อหยดเป็นแฮชของความมุ่งมั่นของ KZG ต่อพหุนาม อย่างไรก็ตาม จากมุมมองของการใช้งาน ไม่สำคัญที่จะต้องสนใจรายละเอียดทางคณิตศาสตร์ของพหุนาม แต่จะมีเพียงเวกเตอร์ของจุดโค้งวงรีเท่านั้น (ขึ้นอยู่กับการตั้งค่า Lagrangian ที่เชื่อถือได้) และความมุ่งมั่นของ KZG ต่อหยดจะเป็นชุดค่าผสมเชิงเส้น รหัสอ้างอิงจาก EIP-4844:
def blob_to_kzg(blob: Vector[BLSFieldElement, 4096]) -> KZGCommitment: computed_kzg = bls.Z1 for value, point_kzg in zip(tx.blob, KZG_SETUP_LAGRANGE): assert value < BLS_MODULUS computed_kzg = bls.add( computed_kzg, bls.multiply(point_kzg, value) ) return computed_kzg
BLS_MODULUS เป็นโมดูลัสด้านบน และ KZG_SETUP_LAGRANGE เป็นเวกเตอร์ของจุดโค้งวงรี ซึ่งเป็นการตั้งค่าที่เชื่อถือได้ตาม Lagrange ตอนนี้มันสมเหตุสมผลแล้วที่ผู้ดำเนินการจะคิดว่ามันเป็นฟังก์ชันแฮชเฉพาะของกล่องดำ
เหตุใดจึงใช้แฮชของ KZG แทน KZG โดยตรง
แทนที่จะใช้ KZG เพื่อแสดง blob โดยตรง EIP-4844 ใช้แฮชเวอร์ชัน: 0x01 ไบต์เดียว (ระบุเวอร์ชันนี้) ตามด้วย 31 ไบต์สุดท้ายของแฮช SHA256 ของ KZG
สิ่งนี้ทำเพื่อความเข้ากันได้ของ EVM และความเข้ากันได้ในอนาคต: สัญญาของ KZG คือ 48 ไบต์ ในขณะที่ EVM ใช้ค่า 32 ไบต์ตามธรรมชาติมากกว่า และถ้าเราเปลี่ยนจาก KZG เป็นอย่างอื่น (เช่น ด้วยเหตุผลด้านควอนตัม) ภาระผูกพันของ KZG จะยังคงดำเนินต่อไปได้ 32 ไบต์
การคอมไพล์ล่วงหน้าสองอย่างที่แนะนำใน proto-danksharding คืออะไร
Proto-danksharding แนะนำการคอมไพล์ล่วงหน้าสองประเภท: การคอมไพล์ล่วงหน้าการตรวจสอบ blob และการคอมไพล์ล่วงหน้าการประเมินดอท
precompile การตรวจสอบความถูกต้องของ blob เป็นตัวอธิบาย: ใช้เป็นอินพุตแฮชเวอร์ชันและหยด และตรวจสอบว่าแฮชเวอร์ชันที่ระบุนั้นเป็นแฮชเวอร์ชันที่ถูกต้องสำหรับ blob การคอมไพล์ล่วงหน้านี้มีวัตถุประสงค์เพื่อใช้โดย Optimistic Rollup การอ้างอิง EIP-4844:
Optiistic Rollup จำเป็นต้องให้ข้อมูลพื้นฐานจริง ๆ เท่านั้นเมื่อส่งหลักฐานการฉ้อโกง คุณลักษณะการส่งหลักฐานการฉ้อโกงจะต้องส่งเนื้อหาทั้งหมดของ blob การฉ้อโกงเพื่อเป็นส่วนหนึ่งของข้อมูลการโทร จะใช้การตรวจสอบความถูกต้องของ Blob เพื่อตรวจสอบความถูกต้องของข้อมูลกับแฮชที่มีการกำหนดเวอร์ชันก่อนหน้านี้ จากนั้นจึงดำเนินการตรวจสอบหลักฐานการฉ้อโกงกับข้อมูลดังกล่าวเหมือนที่ทำอยู่ในปัจจุบัน
การคอมไพล์ล่วงหน้าของการประเมินจุดใช้เป็นอินพุตเวอร์ชันแฮช พิกัด x พิกัด y และหลักฐาน (ข้อผูกพัน KZG ของ blob และหลักฐานการประเมิน KZG) ตรวจสอบหลักฐานเพื่อตรวจสอบว่า P(x) = y โดยที่ P คือพหุนามที่แสดงโดย blob พร้อมแฮชเวอร์ชันที่กำหนด การคอมไพล์ล่วงหน้านี้มีวัตถุประสงค์เพื่อใช้โดย ZK Rollup การอ้างอิง EIP-4844:
การยกเลิก ZK จะให้ข้อผูกมัดสองข้อสำหรับธุรกรรมหรือข้อมูลเดลต้าของรัฐ: KZG ใน Blob และข้อผูกมัดบางอย่างโดยใช้ระบบพิสูจน์หลักฐานใดๆ ที่ ZK ยกเลิกใช้เป็นการภายใน พวกเขาจะใช้ Proof of Commitment of Equivalent Protocol โดยใช้การคอมไพล์ล่วงหน้าของการประเมินจุด เพื่อพิสูจน์ว่า kzg (การรับประกันโปรโตคอลที่ชี้ไปยังข้อมูลที่มีอยู่) และข้อผูกมัดของ ZK rollup อ้างอิงถึงข้อมูลเดียวกัน
โปรดทราบว่าการออกแบบ Optimistic Rollup ที่สำคัญส่วนใหญ่ใช้รูปแบบการป้องกันการฉ้อโกงหลายรอบ โดยที่รอบสุดท้ายต้องการข้อมูลเพียงเล็กน้อยเท่านั้น ดังนั้น อาจเป็นไปได้ว่า Optimistic Rollup ยังสามารถใช้การคอมไพล์ล่วงหน้าของการประเมินจุดแทนการคอมไพล์ล่วงหน้าการตรวจสอบ blob และจะถูกกว่าหากทำเช่นนั้น
การตั้งค่าที่เชื่อถือได้ของ KZG มีลักษณะอย่างไร
ดู:
คำอธิบายทั่วไปเกี่ยวกับการทำงานของการตั้งค่าที่เชื่อถือได้
https://vitalik.ca/general/2022/03/14/trustedsetup.html สำหรับ powers-of-tau
ตัวอย่างการใช้งานการคำนวณที่เกี่ยวข้องกับการตั้งค่าที่เชื่อถือได้ที่สำคัญทั้งหมด
https://github.com/ethereum/research/blob/master/trusted_setup/trusted_setup.py
โดยเฉพาะในกรณีของเรา แผนปัจจุบันคือการรันสี่ขนาดพร้อมกัน (n1=4096, n2=16), (n1=8192, n2=16), (n1=16834, n2=16) และ (n1= 32768, n2=16) พิธีกรรม (มีความลับต่างกัน) ตามทฤษฎีแล้ว ต้องใช้อันแรกเท่านั้น แต่การเรียกใช้ขนาดใหญ่ขึ้นจะช่วยเพิ่มการบังคับใช้ในอนาคตโดยอนุญาตให้เราเพิ่มขนาดหยด เราไม่สามารถเพียงแค่ตั้งค่าให้ใหญ่ขึ้นได้ เนื่องจากเราต้องการจำกัดจำนวนของพหุนามที่สามารถกระทำได้อย่างมีประสิทธิภาพ เท่ากับขนาดหยด
แนวทางปฏิบัติที่เป็นไปได้คือการเริ่มต้นด้วยการตั้งค่า Filecoin จากนั้นดำเนินพิธีเพื่อปรับขนาด การใช้งานหลายอย่างรวมถึงการใช้งานเบราว์เซอร์จะทำให้ผู้คนจำนวนมากสามารถเข้าร่วมได้
เราจะใช้แผนการผูกมัดอื่นไม่ได้หากไม่มีการตั้งค่าที่เชื่อถือได้
น่าเสียดายที่การใช้สิ่งอื่นที่ไม่ใช่ KZG (เช่น IPA หรือ SHA256) ทำให้แผนงานการแบ่งกลุ่มทำได้ยากขึ้น มีหลายสาเหตุนี้:
ข้อผูกมัดที่ไม่ใช่เลขคณิต (เช่น ฟังก์ชันแฮช) เข้ากันไม่ได้กับการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล ดังนั้นหากเราใช้โครงร่างดังกล่าว เมื่อเราเปลี่ยนไปใช้การแบ่งกลุ่มย่อยแบบเต็ม เราจะต้องเปลี่ยนเป็น KZG อยู่ดี
IPA อาจเข้ากันได้กับการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล แต่จะนำไปสู่โครงร่างที่ซับซ้อนมากขึ้นพร้อมคุณสมบัติที่อ่อนแอกว่า (เช่น การรักษาตัวเองและการสร้างบล็อกแบบกระจายจะยากขึ้น)
ทั้งการแฮชและ IPA ไม่สามารถใช้งานร่วมกับการคอมไพล์ล่วงหน้าการประเมินจุดราคาถูกได้ ดังนั้น การใช้งานแบบแฮชหรือ IPA จะไม่สามารถเปิดใช้งาน ZK Rollup หรือสนับสนุนการพิสูจน์การฉ้อโกงราคาถูกในรอบ Optimistic Rollup หลายรอบได้อย่างมีประสิทธิภาพ
ดังนั้น โชคไม่ดีที่การสูญเสียฟังก์ชันการทำงานและความซับซ้อนที่เพิ่มขึ้นของการใช้สิ่งอื่นนอกเหนือจาก KZG นั้นมีมากกว่าความเสี่ยงของ KZG เอง นอกจากนี้ ยังครอบคลุมถึงความเสี่ยงที่เกี่ยวข้องกับ KZG: ความล้มเหลวของ KZG จะส่งผลต่อ Rollup และแอปพลิเคชันอื่นๆ ที่ขึ้นอยู่กับข้อมูล Blob เท่านั้น ไม่ใช่ส่วนอื่นๆ ของระบบ
KZG "ซับซ้อน" และ "ใหม่" เป็นอย่างไร
ข้อผูกพันของ KZG ได้รับการแนะนำในเอกสารปี 2010 และมีการใช้กันอย่างแพร่หลายในโปรโตคอล ZK-SNARK สไตล์ PLONK ตั้งแต่ปี 2019 อย่างไรก็ตาม คณิตศาสตร์พื้นฐานที่ KZG สัญญาว่าเป็นเลขคณิตที่ค่อนข้างง่าย นอกเหนือจากคณิตศาสตร์พื้นฐานของการดำเนินการและการจับคู่เส้นโค้งวงรี
เส้นโค้งเฉพาะที่ใช้คือ BLS12-381 ซึ่งคิดค้นโดย Barreto-Lynn-Scott ในปี 2545 การจับคู่เส้นโค้งวงรีซึ่งจำเป็นในการตรวจสอบคำสัญญาของ KZG เป็นคณิตศาสตร์ที่ซับซ้อนมาก แต่มันถูกคิดค้นขึ้นในทศวรรษที่ 1940 และถูกนำมาใช้ในการเข้ารหัสตั้งแต่ทศวรรษที่ 1990 ในปี 2544 มีการเสนออัลกอริธึมการเข้ารหัสจำนวนหนึ่งโดยใช้การจับคู่
จากมุมมองของความซับซ้อนในการนำไปใช้งาน KZG ไม่ได้ยากไปกว่า IPA: ฟังก์ชันในการคำนวณความมุ่งมั่น (ดูด้านบน) นั้นเหมือนกับในกรณีของ IPA เพียงแค่ใช้ชุดค่าคงที่จุดโค้งวงรีที่แตกต่างกัน การคอมไพล์ล่วงหน้าแบบยืนยันจุดนั้นซับซ้อนกว่าเนื่องจากเกี่ยวข้องกับการประเมินคู่ แต่คณิตศาสตร์นั้นเหมือนกับที่ทำไปแล้วในการใช้งานพรีคอมไพล์ EIP-2537 (BLS12-381) และคล้ายกันมากกับพรีคอมไพล์คู่ bn128 (ดูเพิ่มเติมที่: ปรับให้เหมาะสม Python สำเร็จ) ดังนั้นจึงไม่จำเป็นต้องมี "งานใหม่" ที่ซับซ้อนเพื่อใช้การตรวจสอบ KZG
ซอฟต์แวร์ส่วนต่าง ๆ ของการนำ proto-danksharding ไปใช้มีอะไรบ้าง
มีสี่องค์ประกอบหลัก:
1. ฉันทามติของเลเยอร์การดำเนินการมีการเปลี่ยนแปลง (ดูรายละเอียดที่ EIP):
ประเภทธุรกรรมใหม่ที่มี blobs
Opcode ที่ส่งออกแฮชเวอร์ชันของ ith blob ในธุรกรรมปัจจุบัน
การรวบรวมล่วงหน้าการตรวจสอบความถูกต้องของ Blob
การคอมไพล์การประเมินแบบดอท
2. การเปลี่ยนแปลงฉันทามติในเลเยอร์ฉันทามติ (ดูโฟลเดอร์นี้ใน repo):
รายชื่อ blob KZG ใน BeaconBlockBody
กลไก "ไซด์คาร์" ที่เนื้อหาของ Blob ทั้งหมดถูกส่งไปพร้อมกับวัตถุแยกต่างหากจาก BeaconBlock
ตรวจสอบข้ามระหว่างแฮชเวอร์ชัน blob ในชั้นการดำเนินการและ blob KZG ในชั้นฉันทามติ
3. พูลหน่วยความจำ
BlobTransactionNetworkWrapper (ดูส่วนเครือข่ายของ EIP)
การป้องกันต่อต้าน DoS ที่แข็งแกร่งขึ้นเพื่อชดเชยขนาดหยดที่ใหญ่
4. บล็อกตรรกะการก่อสร้าง
ยอมรับทรานแซกชัน wrapper จาก mempool, ใส่ทรานแซกชันใน ExecutionPayload, ใส่ KZG ลงใน beacon block และ body ใน sidecar
ตอบรับตลาดค่าธรรมเนียมสองมิติ
โปรดทราบว่าสำหรับการใช้งานเพียงเล็กน้อย เราไม่จำเป็นต้องมี mempool เลย (เราสามารถพึ่งพาตลาดบันเดิลธุรกรรมชั้นที่สองได้) เราเพียงแค่ต้องการไคลเอ็นต์เพื่อใช้ตรรกะการสร้างบล็อก เฉพาะการเปลี่ยนแปลงฉันทามติในชั้นการดำเนินการและชั้นฉันทามติเท่านั้นที่ต้องการการทดสอบฉันทามติอย่างครอบคลุม ซึ่งค่อนข้างเบา สิ่งใดก็ตามระหว่างการใช้งานขั้นต่ำและการปรับใช้ "เต็มรูปแบบ" ที่ไคลเอนต์ทั้งหมดรองรับการผลิตแบบบล็อกและ mempool นั้นเป็นไปได้
ตลาดค่าธรรมเนียมหลายมิติแบบ Proto-danksharding มีลักษณะอย่างไร
Proto-danksharding นำเสนอตลาดค่าธรรมเนียม EIP-1559 แบบหลายมิติที่มีทรัพยากรสองอย่าง ได้แก่ ก๊าซและหยด โดยมีราคาก๊าซลอยตัวแยกต่างหากและขีดจำกัดแยกต่างหาก
อีเธอเรียม
ค่าธรรมเนียมหยดจะเรียกเก็บเป็นก๊าซ แต่เป็นปริมาณก๊าซที่เปลี่ยนแปลงได้ซึ่งปรับเพื่อให้ในระยะยาว จำนวนเฉลี่ยของหยดต่อบล็อกจริง ๆ แล้วเท่ากับจำนวนเป้าหมาย
ลักษณะสองมิติหมายความว่าผู้สร้างบล็อกจะเผชิญกับปัญหาที่หนักกว่า แทนที่จะยอมรับธุรกรรมที่มีค่าธรรมเนียมลำดับความสำคัญสูงสุดเพียงอย่างเดียวจนกว่าธุรกรรมจะหมดหรือถึงขีดจำกัดของบล็อก พวกเขาจะต้องหลีกเลี่ยงการเข้าถึงข้อจำกัดที่แตกต่างกันทั้งสองอย่าง
นี่คือตัวอย่าง สมมติว่าขีดจำกัดของแก๊สคือ 70 และขีดจำกัดของหยดคือ 40 mempool มีธุรกรรมมากมาย เพียงพอที่จะเติมเต็มบล็อค และมีสองประเภท (tx gas รวมถึง per-blob gas):
ค่าธรรมเนียมลำดับความสำคัญ 5 ต่อแก๊ส 4 หยด รวม 4 แก๊ส
ค่าธรรมเนียมลำดับความสำคัญ 3 ต่อการเติมน้ำมัน 1 หยด รวม 2 ก๊าซ
อีเธอเรียม
การดำเนินการไคลเอนต์ตอนนี้ต้องใช้อัลกอริธึมเป้หลายมิติที่ซับซ้อนเพื่อเพิ่มประสิทธิภาพการผลิตบล็อกหรือไม่ ไม่ มีเหตุผลหลายประการ:
EIP-1559 ทำให้แน่ใจว่าบล็อกส่วนใหญ่ไม่ถึงขีดจำกัด ดังนั้นมีบล็อกจำนวนเล็กน้อยเท่านั้นที่ประสบปัญหาการปรับให้เหมาะสมหลายมิติ ในกรณีปกติที่ mempool ไม่มีธุรกรรมเพียงพอ (จ่ายเพียงพอ) ถึงขีดจำกัดอย่างใดอย่างหนึ่ง นักขุดคนใดก็ตามสามารถสร้างรายได้อย่างเหมาะสมโดยรวมทุกธุรกรรมที่พวกเขาเห็น
ในทางปฏิบัติ ฮิวริสติกที่ค่อนข้างง่ายสามารถเข้าใกล้สิ่งที่ดีที่สุดได้ ในสถานการณ์ที่คล้ายกัน โปรดดูการวิเคราะห์ EIP-4488 ของ Ansgar สำหรับข้อมูลบางอย่างในเรื่องนี้
การกำหนดราคาแบบหลายมิติไม่ใช่กระแสรายได้ที่ใหญ่ที่สุดจากความเชี่ยวชาญเฉพาะทาง - MEV คือ รายได้เฉพาะของ MEV ที่ดึงออกมาผ่านอัลกอริธึมเฉพาะจากการเก็งกำไร DEX บนเครือข่าย การชำระบัญชี การขาย NFT ที่ดำเนินการล่วงหน้า ฯลฯ เป็นส่วนสำคัญของ "รายได้ที่สกัดได้" ทั้งหมด (เช่น ค่าธรรมเนียมลำดับความสำคัญ): รายได้เฉพาะของ MEV ดูเหมือนจะเฉลี่ยประมาณ 0.025 ETH ต่อบล็อกโซน ค่าธรรมเนียมการจัดลำดับความสำคัญโดยรวมจะอยู่ที่ประมาณ 0.1 ETH ต่อบล็อก
การแยกผู้เสนอ/ผู้สร้างได้รับการออกแบบมาสำหรับการผลิตบล็อกที่มีความเชี่ยวชาญสูง PBS เปลี่ยนกระบวนการสร้างบล็อกเป็นการประมูลที่ผู้เข้าร่วมมืออาชีพเสนอราคาเพื่อสิทธิ์ในการสร้างบล็อก ผู้ตรวจสอบปกติจะต้องยอมรับการเสนอราคาสูงสุดเท่านั้น นี่คือการป้องกันไม่ให้การประหยัดจากขนาดที่ขับเคลื่อนด้วย MEV คืบคลานเข้าสู่การรวมศูนย์ของเครื่องมือตรวจสอบความถูกต้อง แต่จะจัดการปัญหาทั้งหมดที่อาจทำให้การเพิ่มประสิทธิภาพการสร้างบล็อกทำได้ยากขึ้น
ด้วยเหตุผลเหล่านี้ พลวัตของตลาดค่าธรรมเนียมที่ซับซ้อนมากขึ้นไม่ได้เพิ่มการรวมศูนย์หรือความเสี่ยงขึ้นมากนัก อันที่จริง หลักการที่ใช้ในวงกว้างสามารถลดความเสี่ยงของการโจมตี DoS ได้อย่างแท้จริง!
กลไกการปรับค่าหยดแบบ Exponential EIP-1559 ทำงานอย่างไร
EIP-1559 ของวันนี้ปรับค่าธรรมเนียมพื้นฐาน b เพื่อให้ได้ระดับการใช้ก๊าซเป้าหมายเฉพาะ t ดังนี้:
โดยที่ b(n) คือค่าธรรมเนียมพื้นฐานสำหรับบล็อกปัจจุบัน b(n+1) คือค่าธรรมเนียมพื้นฐานสำหรับบล็อกถัดไป t คือเป้าหมาย และ u คือก๊าซที่ใช้
อีเธอเรียม
แม้ว่าการใช้งานเฉลี่ยจะเท่ากับ t แต่ค่าธรรมเนียมพื้นฐานจะลดลง 63/64 ดังนั้น ค่าฐานจะคงที่ก็ต่อเมื่อการใช้งานสูงกว่า t เล็กน้อย ในทางปฏิบัติ เห็นได้ชัดว่าสูงกว่าประมาณ 3% แม้ว่าจำนวนที่แน่นอนจะขึ้นอยู่กับความแปรปรวน
สูตรที่ดีกว่าคือการปรับเลขชี้กำลัง:
exp(x) คือฟังก์ชันเลขชี้กำลัง e^x โดยที่ e≈2.71828 เมื่อค่า x น้อย exp(x)≈1+x อย่างไรก็ตาม มีคุณสมบัติที่สะดวกซึ่งไม่เกี่ยวข้องกับการเปลี่ยนแปลงธุรกรรม: การปรับหลายขั้นตอน
อีเธอเรียม
ดังนั้น การทำธุรกรรมเดียวกันจะส่งผลให้มีค่าธรรมเนียมฐานขั้นสุดท้ายเหมือนกัน ไม่ว่าจะกระจายอย่างไรระหว่างบล็อกต่างๆ
สูตรสุดท้ายข้างต้นยังมีการตีความทางคณิตศาสตร์โดยธรรมชาติ: คำว่า (u1+u2+...+u/n-nt) สามารถถูกมองว่าซ้ำซ้อน: ความแตกต่างระหว่างก๊าซทั้งหมดที่ใช้จริงและก๊าซทั้งหมดที่ต้องการใช้
ค่าธรรมเนียมฐานปัจจุบันเท่ากับ
ข้อเท็จจริงที่ว่าส่วนที่เกินต้องไม่เกินช่วงที่แคบมาก: หากเกิน 8t∗60 ค่าฐานจะกลายเป็น e^60 ซึ่งสูงจนน่าขันจนไม่มีใครสามารถจ่ายได้ และถ้าต่ำกว่า 0 ทรัพยากรโดยทั่วไปจะไม่มีค่าใช้จ่าย และห่วงโซ่จะถูกสแปมจนกว่าส่วนที่เกินจะกลับมาสูงกว่าศูนย์
กลไกการปรับจะทำงานตามเงื่อนไขเหล่านี้ทุกประการ โดยจะติดตามผลรวมจริง (u1+u2+...+u/n) และคำนวณผลรวมเป้าหมาย (nt) และคำนวณราคาเป็นดัชนีของส่วนต่าง เพื่อให้การคำนวณง่ายขึ้น เราใช้ 2^x แทน e^x อันที่จริง เราใช้ค่าประมาณของ 2^x: ฟังก์ชัน fake_exponential ใน EIP ดัชนีเท็จมักจะอยู่ภายใน 0.3% ของค่าจริง
เพื่อป้องกันไม่ให้การใช้งานน้อยเกินไปเป็นระยะเวลานานจนทำให้เกิดการบล็อกเต็ม 2x เป็นระยะเวลานาน เราได้เพิ่มคุณสมบัติพิเศษ: เราไม่ปล่อยให้บล็อกส่วนเกินต่ำกว่าศูนย์ หากactual_totalต่ำกว่าtargeted_total เราก็แค่ตั้งค่าactual_totalให้เท่ากับtargeted_total ในกรณีที่รุนแรง (blob gas ไปจนถึงศูนย์) สิ่งนี้จะทำลายความไม่แปรผันของคำสั่งธุรกรรม แต่ความปลอดภัยที่เพิ่มขึ้นทำให้สิ่งนี้เป็นการแลกเปลี่ยนที่ยอมรับได้
นอกจากนี้ โปรดสังเกตผลลัพธ์ที่น่าสนใจของตลาดหลายมิตินี้: เมื่อมีการเปิดตัว proto-danksharding เป็นครั้งแรก มีแนวโน้มว่าจะมีผู้ใช้น้อยมากในตอนแรก ดังนั้นในขณะที่ราคาของ blob เกือบจะถูกมากอย่างแน่นอน แม้กระทั่งสำหรับ "ปกติ" กิจกรรม Ethereum blockchain ยังคงมีราคาแพง
ผู้เขียนเชื่อว่ากลไกการปรับค่าธรรมเนียมนี้ดีกว่าแนวทางปัจจุบัน ดังนั้นในที่สุดทุกส่วนของตลาดค่าธรรมเนียม EIP-1559 ควรเปลี่ยนไปใช้กลไกนี้
สำหรับคำอธิบายที่ละเอียดและยาวกว่านี้ โปรดดูโพสต์ของ Dankrad
fake_exponential ทำงานอย่างไร
เพื่อความสะดวก นี่คือรหัสสำหรับ fake_exponential:
def fake_exponential(numerator: int, denominator: int) -> int: cofactor = 2 ** (numerator // denominator) fractional = numerator % denominator return cofactor + ( fractional * cofactor * 2 + (fractional ** 2 * cofactor) // denominator ) // (denominator * 3)
อีเธอเรียม
เป้าหมายคือการต่ออินสแตนซ์จำนวนมากของ (QX) เข้าด้วยกัน ซึ่งหนึ่งในนั้นจะถูกเลื่อนและปรับขนาดอย่างเหมาะสมสำหรับแต่ละช่วง [2^k,2^(k+1)] Q(x) เองเป็นค่าประมาณของ 2^x สำหรับ 0≤x≤1 ซึ่งเลือกจากคุณสมบัติต่อไปนี้:
ความเรียบง่าย (เป็นสมการกำลังสอง)
ความถูกต้องของขอบด้านซ้าย (Q(0)=2^0=1)
ความถูกต้องของขอบด้านขวา (Q(1)=2^1=2)
ความชันที่ราบรื่น (เรามั่นใจว่า Q'(1)=2∗Q'(0) ดังนั้นแต่ละสำเนา shift+scaled ของ Q จึงมีความชันเท่ากันที่ขอบขวากับสำเนาถัดไปที่ขอบซ้าย)
สมการสามตัวสุดท้ายต้องใช้สมการเชิงเส้นสามตัวที่ให้ค่าสัมประสิทธิ์ที่ไม่รู้จักสามตัว และ Q(x) ที่ให้ไว้ข้างต้นให้คำตอบเดียว
อีเธอเรียม
ประเด็นใดที่ยังคงถกเถียงกันใน proto-danksharding?
หมายเหตุ: ส่วนนี้ล้าสมัยได้ง่าย อย่าวางใจที่จะให้ความคิดล่าสุดเกี่ยวกับประเด็นใดประเด็นหนึ่งโดยเฉพาะ
Optimistic Rollups ที่สำคัญทั้งหมดใช้การพิสูจน์หลายรอบ ดังนั้นพวกเขาจึงสามารถใช้การรวบรวมล่วงหน้าของการประเมินจุด (ถูกกว่ามาก) แทนการรวบรวมล่วงหน้าของการตรวจสอบ Blob ใครก็ตามที่ต้องการการยืนยัน blob จริงๆ สามารถนำไปใช้ได้ด้วยตนเอง: ใช้เป็นอินพุต blob D และแฮชเวอร์ชัน h เลือก x=hash(D,h) คำนวณ y=D(x) โดยใช้การประเมิน barycentric และคาดการณ์คอมไพล์และตรวจสอบว่า h (x)=ย. ดังนั้นเราต้องการการคอมไพล์ล่วงหน้าของการตรวจสอบความถูกต้องของ blob จริง ๆ หรือเราสามารถลบมันออกแล้วใช้การประเมินจุดได้หรือไม่
เชนมีความสามารถในการจัดการบล็อกขนาด 1 MB+ ที่มีอายุการใช้งานยาวนานเพียงใด หากความเสี่ยงมากเกินไป จำนวนหยดเป้าหมายควรลดลงตั้งแต่แรกหรือไม่
Blob ควรเปลี่ยนเป็นก๊าซหรือ ETH (เผา)? ควรมีการปรับอื่น ๆ ในตลาดค่าธรรมเนียมหรือไม่?
ควรพิจารณาประเภทธุรกรรมใหม่เป็น blob หรือเป็นวัตถุ SSZ ในกรณีหลังให้เปลี่ยน ExecutionPayload เป็นประเภท union (เป็นการแลกเปลี่ยน "ทำงานให้มากขึ้นตอนนี้" กับ "ทำงานให้มากขึ้นในภายหลัง")
รายละเอียดที่แน่นอนของการปรับใช้การตั้งค่าที่เชื่อถือได้ (ในทางเทคนิคแล้วเกินขอบเขตของ EIP เอง เนื่องจากการตั้งค่าดังกล่าวเป็น "ค่าคงที่" สำหรับผู้ดำเนินการ แต่ก็ยังจำเป็นต้องดำเนินการ)
