ผู้เขียนต้นฉบับ: 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 ให้ดียิ่งขึ้น