ทำความเข้าใจ EIP-4844 ในบทความเดียว: จะลดค่าธรรมเนียม Layer 2 ลง 100 เท่าได้อย่างไร
ผู้เขียนต้นฉบับ: Chuan Lin
ชื่อระดับแรก
01. บทนำ
Vitalik เปิดตัวแผนงาน Ethereum ที่อัปเดตเมื่อวันที่ 5 พฤศจิกายน 2022 เมื่อเทียบกับแผนงานก่อนหน้านี้ที่เผยแพร่เมื่อวันที่ 2 ธันวาคม 2021 การอัปเดตที่กำลังจะมาถึงของเฟส Surge นั้นเป็นสิ่งที่สำคัญที่สุดอย่างไม่ต้องสงสัย
ดังที่แสดงในรูปด้านล่าง การอัปเดตในขั้นตอนนี้เพิ่มรายละเอียดมากขึ้นอย่างเห็นได้ชัด - เราสามารถเห็นได้อย่างชัดเจนว่าเพื่อให้บรรลุ "การขยายค่าสะสมพื้นฐาน" ชุมชน Ethereum เสนอ EIP-4844: Proto-Danksharding ข้อเสนอนี้จะดำเนินการตั้งแต่เดือนพฤษภาคมถึงต้นเดือนมิถุนายน 2023 ซึ่งเมื่อถึงเวลานั้นต้นทุนของ Rollup จะลดลง 100 เท่า ซึ่งจะช่วยเพิ่มประสิทธิภาพประสบการณ์ผู้ใช้ Ethereum L2 อย่างมาก การเพิ่มประสิทธิภาพขนาดใหญ่ดังกล่าวจะกลายเป็นจุดสนใจของการสนทนาและความสนใจในชุมชน Web3
ปัญหาเกี่ยวข้องกับ Ethereum ตรงไหน? EIP-4844 ใช้แนวคิดและวิธีแก้ปัญหาใดในการแก้ปัญหานี้ บทความนี้จะช่วยให้คุณเข้าใจ EIP-4844 อย่างกระชับ
ชื่อระดับแรก
02. ข้อความ
1. ที่มาของ EIP-4844: คอขวดค่าธรรมเนียม L2 เกิดจากความพร้อมใช้งานของข้อมูล
1.1 สถานการณ์พื้นฐานปัจจุบันของการโต้ตอบข้อมูลระหว่าง L2 และ L1
ในปัจจุบัน Ethereum L2 ส่วนใหญ่ใช้ Rollup เป็นเส้นทางทางเทคนิคพื้นฐาน Vitalik ยังอธิบายถึงการอัปเดตของ Ethereum ด้วย "A Rollup-Centric Roadmap" ซึ่งแสดงให้เห็นว่า Rollup ได้ครอบงำเวที L2 โดยพื้นฐานแล้ว
หลักการพื้นฐานของการดำเนินการ Rollup คือการดำเนินการกลุ่มของธุรกรรมนอกห่วงโซ่หลักของ Ethereum หลังจากดำเนินการแล้ว ผลลัพธ์ของการดำเนินการและข้อมูลธุรกรรมจะถูกบีบอัดและส่งกลับไปยัง L1 เพื่อให้ผู้อื่นสามารถตรวจสอบความถูกต้องของผลลัพธ์ของธุรกรรมได้เห็นได้ชัดว่าหากไม่มีใครอ่านข้อมูลได้ การยืนยันจะไม่สามารถทำได้ ดังนั้นจึงเป็นเรื่องสำคัญมากที่จะต้องทำให้ผู้อื่นสามารถเข้าถึงข้อมูลธุรกรรมดิบได้ เรียกอีกอย่างว่า "ความพร้อมใช้งานของข้อมูล"
อย่างไรก็ตาม ถูกจำกัดโดยสถาปัตยกรรมปัจจุบันของ Ethereum ข้อมูลที่ส่งจาก L2 ไปยัง L1 จะถูกจัดเก็บไว้ใน Calldata ของการทำธุรกรรมอย่างไรก็ตาม Calldata เป็นเพียงพารามิเตอร์ของการเรียกใช้ฟังก์ชันสัญญาอัจฉริยะเมื่อ Ethereum ได้รับการออกแบบมาตั้งแต่แรก และเป็นข้อมูลที่โหนดทั้งหมดต้องดาวน์โหลดพร้อมกัน หาก Calldata ขยายตัว มันจะทำให้เกิดโหลดสูงบนโหนดเครือข่าย Ethereum ดังนั้นค่าใช้จ่ายของ Calldata จึงค่อนข้างแพง นี่เป็นปัจจัยหลักที่ทำให้เกิดค่าธรรมเนียม L2 ในปัจจุบัน
1.2 แนวคิดในการปรับปรุงสำหรับปัญหา
ผู้อ่านอาจลองคิดเล่นๆ ว่า หากคุณถูกขอให้ออกแบบแผนการเพิ่มประสิทธิภาพสำหรับปัญหานี้ คุณจะปรับปรุงไปในทิศทางใด
ในความเป็นจริง เราสามารถสังเกตว่าการอัปโหลดข้อมูลธุรกรรมที่บีบอัดของ L2 เป็นเพียงเพื่อให้ผู้อื่นสามารถดาวน์โหลดและตรวจสอบได้ และไม่จำเป็นต้องดำเนินการโดย L1 สาเหตุที่ราคา Calldata สูงเนื่องจากเป็นพารามิเตอร์ของการเรียกใช้ฟังก์ชัน อาจดำเนินการโดย L1 ตามค่าเริ่มต้น ดังนั้นจึงจำเป็นต้องซิงโครไนซ์โดยโหนดในเครือข่ายทั้งหมด
สิ่งนี้ทำให้เกิดความไม่ตรงกัน ตัวอย่างเช่น ฉันแค่ต้องการถ่ายโอนข้อมูลไปยังดิสก์เครือข่าย เพื่อให้คนอื่น ๆ ที่ต้องการข้อมูลสามารถดาวน์โหลดได้ในช่วงระยะเวลาหนึ่ง ท้ายที่สุด คุณทำให้ข้อมูลของฉันมีการซิงโครไนซ์กระจายเสียงทั่วทั้งเครือข่าย ที่ฉันไม่ต้องการ บังคับให้ทุกคนดาวน์โหลดให้เสร็จภายในเวลาจำกัด จากนั้นจึงเรียกเก็บค่าบริการสูงสำหรับบริการนี้ เห็นได้ชัดว่าไม่เหมาะสมและจำเป็นต้องปรับปรุง
แล้วจะปรับปรุงยังไง?เราสามารถออกแบบแยกประเภทข้อมูลสำหรับข้อมูลที่ส่งผ่านจาก L2 และแยกออกจาก Calldata ของ L1 ข้อมูลประเภทนี้จะต้องสามารถเข้าถึงได้และดาวน์โหลดโดยบุคคลอื่นที่ต้องการภายในระยะเวลาหนึ่งเท่านั้น และไม่จำเป็นต้องซิงโครไนซ์เครือข่ายทั้งหมดในความเป็นจริง สมาชิกหลายคนในชุมชนด้านเทคนิคของ Ethereum ได้คิดประเด็นนี้เช่นกัน
การปรับปรุง EIP-4844 ดำเนินการตามบริบทนี้
2. แกนหลักของ EIP-4844: การทำธุรกรรมกับ blobs
หากคุณใช้หนึ่งประโยคเพื่อสรุปว่า EIP-4844 ทำอะไร นั่นคือ: แนะนำ"การทำธุรกรรมกับ blobs"ธุรกรรมประเภทใหม่นี้ Blob เป็นประเภทข้อมูลที่ออกแบบมาเป็นพิเศษสำหรับการส่งข้อมูล L2 ที่กล่าวถึงข้างต้น
ดังนั้น หากคุณเข้าใจรายละเอียดเกี่ยวกับ Blob อย่างชัดเจน คุณสามารถพูดได้ว่าคุณเข้าใจ EIP-4844 โดยพื้นฐานแล้ว
2.1 Blob ontology: "บล็อกข้อมูลขนาดใหญ่" ที่ใช้วางข้อมูลที่บีบอัด L2 ซึ่งจัดเก็บไว้ในโหนดของเลเยอร์ฉันทามติ
ชื่อ Blob เป็นตัวย่อของ Binary Large Object ซึ่งแปลตามตัวอักษรว่า "บล็อกข้อมูลขนาดใหญ่แบบไบนารี" มันถูกออกแบบมาเพื่อพกพาข้อมูลที่บีบอัดของธุรกรรมดั้งเดิมของ L2 ซึ่งเทียบเท่ากับการใส่ข้อมูลของ L2 ลงใน Calldata ก่อนหน้านี้ และตอนนี้ใส่ลงใน Blob เมื่อเทียบกับ Calldata ขนาดข้อมูลของ Blob อาจมีขนาดใหญ่มากถึง 125 KB
Blobs จะถูกเก็บไว้โดยโหนดของเลเยอร์ฉันทามติ แทนที่จะถูกอัปโหลดโดยตรงไปยังเชนหลักเช่น Calldata ซึ่งนำคุณสมบัติหลักสองประการของ Blobs มาด้วย:
ไม่สามารถอ่านได้โดย EVM เช่น Calldata
มีอายุการใช้งานและจะถูกลบหลังจาก 30 วัน
ในรายละเอียดเพิ่มเติม Blob นั้นเป็นเวกเตอร์ (Vector) ที่ประกอบด้วยองค์ประกอบ 4096 รายการ แต่ละมิติของเวกเตอร์นี้เป็นจำนวนที่ใหญ่มากโดยมีช่วงตั้งแต่ 0 ถึง 52435875175126190477474050818596525252527637826036999938584513 - จำนวนที่มากนี้เป็นจำนวนคุณภาพ เป็นวงรีและวงรี Curve -อัลกอริทึมที่เกี่ยวข้องกับอัลกอริทึม
และจำนวนของแต่ละมิติของเวกเตอร์นี้สามารถถือเป็นแต่ละค่าสัมประสิทธิ์ของพหุนามฟิลด์จำกัดที่ไม่เกิน 4096 ลำดับ ตัวอย่างเช่น จำนวนของมิติ i-th คือสัมประสิทธิ์ที่อยู่หน้า w^i โดยที่ w คือ ค่าคงที่และเป็นไปตาม w^4096 = 1 โครงสร้างนี้ออกแบบมาเพื่ออำนวยความสะดวกในการสร้างพันธะพหุนามของ KZG
2.2 การออกแบบสถาปัตยกรรมที่เกี่ยวข้องกับ Blob: Sidecar
ก่อนที่จะเข้าใจสถาปัตยกรรม Blob ต้องอธิบายแนวคิดเสียก่อน: Execution Payload หลังจากการควบรวมกิจการของ Ethereum เลเยอร์ Consensys และ Execution Layer ก็ถูกแยกออกจากกัน ซึ่งมีหน้าที่รับผิดชอบสองหน้าที่หลัก: หน้าที่แรกรับผิดชอบฉันทามติของ PoS และหน้าที่หลังดำเนินการ EVM Execution Payload สามารถพิจารณาได้ง่ายๆว่าเป็นธุรกรรม L1 ธรรมดาในเลเยอร์ EL
การผสานรวมของ Blob และสถาปัตยกรรม Ethereum ในปัจจุบันสามารถเปรียบเทียบได้กับความสัมพันธ์ระหว่างตัวถังรถจักรยานยนต์และรถจักรยานยนต์พ่วงข้าง (Sidecar) ดังนี้ (อันทางซ้ายคือรถจักรยานยนต์พ่วงข้าง)
Sidecar (รถจักรยานยนต์พ่วงข้าง) เป็นคำเปรียบเทียบอย่างเป็นทางการ ความหมายของมันคือแม้ว่าการทำงานของ Blob จะขึ้นอยู่กับห่วงโซ่หลัก แต่ก็ขนานกับห่วงโซ่หลักในระดับหนึ่งและมีความเป็นอิสระมาก
ดังที่แสดงในรูปด้านล่าง ให้เราดำเนินการตามขั้นตอนการดำเนินการที่เกี่ยวข้องกับ Blob เพื่อทำความเข้าใจคำอุปมานี้ให้ดียิ่งขึ้น:
ขั้นแรก L2 Sequencer จะกำหนดธุรกรรม และส่งผลลัพธ์ของธุรกรรมและหลักฐานที่เกี่ยวข้อง (ส่วนสีเหลือง) และแพ็กเก็ตข้อมูล (Blob ส่วนสีน้ำเงิน) ไปยังกลุ่มธุรกรรมของ L1
โหนด L1 (Beacon Proposer) เห็นธุรกรรม จะดำเนินการธุรกรรมที่เกี่ยวข้องในข้อเสนอบล็อกใหม่ (Beacon Block) และออกอากาศ แต่เมื่อออกอากาศ จะแยก Blob และปล่อยให้อยู่ในเลเยอร์ CL ที่สอดคล้องกัน ใส่ลงในบล็อกใหม่ในชั้นการดำเนินการ
โหนด L1 อื่นๆ (Beacon Peer) จะได้รับข้อเสนอบล็อกใหม่และผลลัพธ์ของธุรกรรม หากต้องการเป็นผู้ตรวจสอบ L2 ก็สามารถไปที่ Blobs Sidecar เพื่อดาวน์โหลดข้อมูลที่เกี่ยวข้องได้
รูปด้านล่างคือภาพประกอบของวงจรชีวิตของ Blob จากมุมมองอื่น เราเห็นได้ชัดเจนว่าข้อมูลของ Blob จะไม่ถูกอัปโหลดไปยังห่วงโซ่หลัก L1 แต่จะมีอยู่เฉพาะในโหนดเลเยอร์ที่สอดคล้องกันเท่านั้น และมีวงจรชีวิตที่แตกต่างกัน .
ดังนั้น,ไม่ยากที่จะเข้าใจว่าทำไม EVM ไม่สามารถอ่าน Blob ได้โดยตรง นั่นคือสัญญาอัจฉริยะ L1: สิ่งที่สามารถอ่านได้คือสิ่งที่ส่งผ่านไปยังชั้นการดำเนินการ เนื่องจาก Blob อยู่ในชั้นฉันทามติเท่านั้น จะต้องไม่มีฟังก์ชั่นดังกล่าวในขณะนี้ในความเป็นจริง การแยกส่วนนี้เป็นสาเหตุที่ทำให้ต้นทุนค่าสะสมลดลงได้
2.3 Blob Storage: ตลาดค่าธรรมเนียมใหม่
ดังที่ได้กล่าวไว้ก่อนหน้านี้ ข้อมูล Blob จะถูกจัดเก็บไว้ในโหนดเลเยอร์ที่สอดคล้องกันและมีวงจรชีวิต แต่เห็นได้ชัดว่าบริการนี้ไม่ฟรี ดังนั้นจะนำมาซึ่งตลาดค่าธรรมเนียมใหม่ที่ไม่ขึ้นกับค่าธรรมเนียม L1 Gas ซึ่งเป็นตลาดค่าธรรมเนียมหลายมิติที่สนับสนุนโดย Vitalik รายละเอียดที่เกี่ยวข้องของตลาดค่าธรรมเนียมนี้ยังคงได้รับการปรับปรุงซ้ำๆ สำหรับรายละเอียด โปรดดูการสนทนาและการอัปเดตที่เกี่ยวข้องบน Github: https://github.com/ethereum/EIPs/pull/5707
นอกจากนี้ หากระดับโหนดสามารถจัดเก็บข้อมูลเหล่านี้ได้ในช่วงเวลาสั้นๆ เท่านั้น จะจัดเก็บข้อมูลระยะยาวได้อย่างไร ในเรื่องนี้ Vitalik กล่าวว่ามีวิธีแก้ปัญหามากมาย เนื่องจากข้อสันนิษฐานด้านความปลอดภัยที่นี่ไม่ได้เรียกร้องมากนัก จึงเป็น "แบบจำลองความน่าเชื่อถือ 1 ใน N" ตราบใดที่มีคนสามารถจัดเก็บข้อมูลจริงให้เสร็จสมบูรณ์ได้ ในเวลาที่ฮาร์ดแวร์จัดเก็บข้อมูลขนาดใหญ่มีราคาเพียง $20 ต่อ TB พื้นที่จัดเก็บข้อมูล 2.5 TB ต่อปีเป็นปัญหาเล็กน้อยสำหรับผู้ที่ต้องการ นอกจากนี้ โซลูชันการจัดเก็บข้อมูลแบบกระจายอำนาจอื่นๆ อีกหลายตัวเลือกก็เป็นตัวเลือกเช่นกัน แต่ Vitalik ไม่ได้กล่าวถึงโครงการเฉพาะในที่นี้
3. ผลกระทบของ EIP-4844
ในระดับสถาปัตยกรรม EIP-4844 ขอแนะนำประเภทธุรกรรมใหม่ ธุรกรรมที่มีหยดเลือด ซึ่งเป็นครั้งแรกที่ Ethereum ได้สร้างชั้นข้อมูลแยกต่างหากสำหรับ L2 และยังเป็นก้าวแรกในการทำให้ Full Danksharding เป็นจริง
ในระดับโมเดลเศรษฐกิจ EIP-4844 จะแนะนำตลาดค่าธรรมเนียมใหม่สำหรับ blobs ซึ่งจะเป็นก้าวแรกสำหรับ Ethereum ในการก้าวไปสู่ตลาดหลายมิติ
ในระดับประสบการณ์ของผู้ใช้การรับรู้โดยสัญชาตญาณของผู้ใช้คือการลดค่าธรรมเนียม L2 ลงอย่างมาก การปรับปรุงที่สำคัญที่ชั้นล่างสุดนี้จะเป็นรากฐานที่สำคัญสำหรับการระเบิดของ L2 และชั้นแอปพลิเคชัน
4. Outlook หลังจาก EIP-4844: Danksharding อย่างเต็มที่
ในปัจจุบัน,EIP-4844 ได้รับการรวมไว้อย่างชัดเจนในชุดอัปเกรด Ethereum Shanghai ตามตารางเวลาที่กำหนดโดยสมาชิกชุมชนปัจจุบันคาดว่าจะแล้วเสร็จตั้งแต่เดือนพฤษภาคมถึงต้นเดือนมิถุนายนปีหน้า
และ EIP-4844 เป็นเพียง "Proto-Danksharding" ซึ่งหมายถึงต้นแบบของ Danksharding แนวคิดของเวอร์ชันเต็มของ Danksharing แสดงอยู่ในรูปด้านล่าง แต่ละโหนดสามารถตรวจสอบความถูกต้องของข้อมูล L2 ได้โดยตรงผ่านการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล สิ่งนี้จะช่วยปรับปรุงความปลอดภัยและประสิทธิภาพของ L2 ให้ดียิ่งขึ้น
