ผู้เขียน: Samuel Okediji เรียบเรียง: Cointime.com 237

ในด้านเทคโนโลยีบล็อกเชน Ethereum ได้ทำงานเพื่อจัดการกับฐานผู้ใช้ที่ขยายตัวอย่างต่อเนื่อง เพิ่มปริมาณงานธุรกรรม และลดค่าใช้จ่าย เพื่อให้ได้ความสามารถในการปรับขนาดในระยะยาว Ethereum ใช้แนวคิดของการแบ่งส่วนข้อมูล ในขั้นตอนชั่วคราวเพื่อนำไปสู่การใช้ Sharding อย่างเต็มรูปแบบ ข้อเสนอการปรับปรุง Ethereum 4844 (EIP-4844) ได้รับการแนะนำ ข้อเสนอนี้มีจุดมุ่งหมายเพื่อให้ Ethereum บรรลุทรูพุตที่สูงขึ้นประมาณ 100,000 ธุรกรรมต่อวินาที (TPS) ในขณะที่ยังคงรักษาความปลอดภัยและการกระจายอำนาจ
เข้าใจถึงความสำคัญของมาตรฐาน EIP และ EIP-4844:
Ethereum Improvement Proposal (EIP) เป็นเอกสารอย่างเป็นทางการที่สรุปการปรับปรุง คุณลักษณะใหม่ หรือการเปลี่ยนแปลงโปรโตคอล Ethereum พวกเขาให้วิธีการสำหรับสมาชิกชุมชน Ethereum เพื่อเสนอและหารือเกี่ยวกับการปรับปรุงศักยภาพ
EIP-4844 เกี่ยวข้องกับการรวมธุรกรรม shard blob เข้ากับเครือข่าย Ethereum เป็นหลัก Sharding คือการแบ่งฐานข้อมูลออกเป็นพาร์ติชันขนาดเล็ก (หรือที่เรียกว่า Shards) เพื่อปรับปรุงประสิทธิภาพและประสิทธิภาพ ด้วยการใช้ธุรกรรม sharded blob Ethereum มีเป้าหมายเพื่อปรับปรุงต้นทุนการทำธุรกรรมและเพิ่มปริมาณงานโดยรวม แม้ว่า EIP-4844 จะไม่ใช่โซลูชันการแบ่งชิ้นส่วนที่สมบูรณ์ แต่ก็เป็นขั้นตอนสำคัญในการบรรลุความสามารถในการปรับขนาดที่จำเป็นและความคุ้มค่าเพื่ออำนวยความสะดวกในการนำไปใช้ในวงกว้าง
บทความนี้จะเจาะลึกลงไปใน EIP-4844 และผลกระทบต่อความสามารถในการปรับขนาดของ Ethereum เราจะอธิบายแนวคิดของ Sharding ให้ข้อมูลเชิงลึกเกี่ยวกับบทบาทของมาตรฐาน EIP และให้ความกระจ่างเกี่ยวกับความสำคัญของธุรกรรม Sharding Blob ในระบบนิเวศ Ethereum นอกจากนี้ เราจะสำรวจคุณสมบัติและกลไกหลักที่แนะนำโดย EIP-4844 รวมถึงธุรกรรมที่มี blobs การเรียกเก็บเงินค่าก๊าซ และความสัมพันธ์ระหว่าง EIP-4844 และการแบ่งส่วนข้อมูลแบบเต็มสเกล เมื่ออ่านบทความนี้ คุณจะได้รับความเข้าใจที่ครอบคลุมเกี่ยวกับ EIP-4844 และการมีส่วนร่วมของ Ethereum ในความพยายามอย่างต่อเนื่องในการปรับปรุงความสามารถในการปรับขนาดและลดต้นทุนการทำธุรกรรม
จากการสำรวจนี้ คุณจะได้รับข้อมูลเชิงลึกต่อไปนี้:
แนวคิดของ Sharding และความสำคัญต่อความสามารถในการปรับขนาดของ Ethereum
บทบาทของ EIP-4844 เป็นขั้นตอนขั้นกลางในการแยกชิ้นส่วนทั้งหมด
คุณสมบัติและกลไกที่แนะนำโดย EIP-4844 เช่น ธุรกรรมที่มี blobs และการเรียกเก็บเงินก๊าซ
EIP-4844 สอดคล้องกับโรดแมปการปรับขนาดและการลดต้นทุนของ Ethereum อย่างไร
ผู้ใช้สามารถคาดหวังการทำธุรกรรมที่รวดเร็วขึ้นและค่าธรรมเนียมที่ลดลงจากการใช้ EIP-4844
เมื่ออ่านบทความนี้ คุณจะสามารถเข้าใจและเข้าใจถึงความสำคัญของ EIP-4844 และผลกระทบต่อ Ethereum ที่มีต่อความสามารถในการปรับขนาดที่มากขึ้นและการนำไปใช้อย่างแพร่หลายโดยการอ่านบทความนี้
EIP-4844 คืออะไร?
EIP-4844 มุ่งเน้นไปที่การรวมธุรกรรม shard blob ในเครือข่าย Ethereum Sharding เกี่ยวข้องกับการแบ่งฐานข้อมูลออกเป็นพาร์ติชันหรือชิ้นส่วนขนาดเล็กเพื่อปรับปรุงประสิทธิภาพและประสิทธิภาพ ในบริบทของ Ethereum การชาร์ดดิ้งมีเป้าหมายเพื่อปรับปรุงต้นทุนการทำธุรกรรมและเพิ่มปริมาณงาน Ethereum วางแผนที่จะใช้ dank sharding (ประเภทเฉพาะของ sharding) ซึ่งคาดว่าจะเพิ่ม TPS ของ Ethereum อย่างมีนัยสำคัญเป็นประมาณ 100,000
EIP-4844 มุ่งเน้นไปที่การรวมธุรกรรม shard blob ในเครือข่าย Ethereum Sharding เกี่ยวข้องกับการแบ่งฐานข้อมูลออกเป็นพาร์ติชันหรือชิ้นส่วนขนาดเล็กเพื่อปรับปรุงประสิทธิภาพและประสิทธิภาพ ในบริบทของ Ethereum การชาร์ดดิ้งมีเป้าหมายเพื่อปรับปรุงต้นทุนการทำธุรกรรมและเพิ่มปริมาณงาน Ethereum วางแผนที่จะใช้ dank sharding (ประเภทเฉพาะของ sharding) ซึ่งคาดว่าจะเพิ่ม TPS ของ Ethereum อย่างมีนัยสำคัญเป็นประมาณ 100,000
เมื่อเปรียบเทียบกับข้อเสนอการชาร์ดดิ้งของ Ethereum และที่ไม่ใช่ Ethereum ก่อนหน้านี้ การชาร์ดดิ้งแบบเปียกนั้นนำเสนอนวัตกรรมหลายอย่าง มันมุ่งเน้นไปที่การให้พื้นที่มากขึ้นสำหรับหยดข้อมูล ไม่ใช่แค่การทำธุรกรรม นอกจากนี้ Dank Sharding ยังนำตลาดค่าธรรมเนียมแบบผสานรวมมาใช้โดยที่ผู้เสนอรายหนึ่งเลือกธุรกรรมสำหรับชิ้นส่วนทั้งหมด โดยขจัดความจำเป็นที่แต่ละชิ้นส่วนจะต้องมีผู้เสนอของตนเอง เพื่อแก้ไขปัญหาของค่าสูงสุดที่สกัดได้ (MEV) จะมีการแนะนำวิธีการแยกผู้เสนอ/ผู้สร้าง
EIP-4844 (Proto-Danksharding)
EIP-4844 หรือที่รู้จักในชื่อ Proto-dank sharding เป็นขั้นตอนขั้นกลางสู่การแยกชิ้นส่วน dank อย่างเต็มรูปแบบ โดยมีเป้าหมายที่จะเพิ่ม TPS เป็นประมาณ 1,000 รายการ และแนะนำประเภทธุรกรรมใหม่ที่เรียกว่า ธุรกรรมเหล่านี้รวมถึงข้อมูล "blob" ซึ่งเป็นองค์ประกอบสำคัญสำหรับการแยกชิ้นส่วนที่เปียกโชก การดำเนินการ EIP-4844 คาดว่าจะเกิดขึ้นในช่วงครึ่งหลังของปี 2023 แต่อาจมีความล่าช้า
EIP-4844 ทำงานอย่างไร
EIP-4844 แนะนำการทำธุรกรรมด้วย blobs ซึ่งคล้ายกับการทำธุรกรรมทั่วไป แต่มีการเพิ่มวัตถุไบนารีขนาดใหญ่ที่เรียกว่า "blobs" Blob เหล่านี้จะผนวกเข้ากับบล็อก เพิ่มความจุข้อมูลของบล็อกที่มี Blob เป็นที่น่าสังเกตว่า ไม่เหมือนกับการเพิ่มขนาดบล็อกเพียงอย่างเดียว ซึ่งรวมถึง blobs ที่หลีกเลี่ยงแนวปฏิบัติของ Ethereum ในการเพิ่มขนาดบล็อก เนื่องจากปัญหาต่างๆ เช่น การรวมศูนย์และข้อกำหนดด้านการคำนวณ
Blobs มีคุณสมบัติที่แตกต่างกันเมื่อเปรียบเทียบกับบล็อค บล็อกจะถูกเก็บไว้อย่างไม่มีกำหนดและ Ethereum Virtual Machine (EVM) จะมองเห็นได้ ในขณะที่ Blob มีอายุการใช้งานจำกัดและ EVM จะมองไม่เห็น Blobs มีอยู่ที่เลเยอร์ฉันทามติของ Ethereum ไม่ใช่เลเยอร์การดำเนินการ ซึ่งช่วยลดต้นทุนการจัดเก็บ นอกจากนี้ EIP-4844 ยังมีตรรกะเลเยอร์การดำเนินการ กฎการตรวจสอบ ตลาดค่าธรรมเนียมหลายมิติ และการเปลี่ยนแปลงระบบอื่นๆ ที่จำเป็นสำหรับการแยกส่วนข้อมูล Dank แบบเต็มสเกลในอนาคต
สิ่งสำคัญคือต้องสังเกตว่า EIP-4844 ไม่ได้ใช้การชาร์ดดิ้งจริง ๆ แต่ทำให้ Ethereum เข้าใกล้ระดับของความสามารถในการปรับขนาดและค่าใช้จ่ายที่จำเป็นเพื่อให้เกิดการนำไปใช้อย่างแพร่หลาย EIP-4844 นำเสนอความสามารถในการปรับขนาดและประโยชน์ในการประหยัดต้นทุนแม้ว่าจะไม่ได้ใช้การแบ่งชิ้นส่วนที่เปียกชื้นอย่างเต็มรูปแบบ
EIP-4844 จะเป็นประโยชน์ต่อผู้ใช้อย่างไร?
EIP-4844 เป็นการอัปเกรดโปรโตคอลที่สอดคล้องกับแผนงานที่เน้นการรวมศูนย์ของ Ethereum การเตรียมการสำหรับการใช้งานกำลังดำเนินไปอย่างรวดเร็ว เครือข่ายการพัฒนากำลังดำเนินการอยู่ และข้อกำหนดสำหรับการอัปเกรดใกล้จะเสร็จสิ้น
หลังจากการใช้งาน EIP-4844 ผู้ใช้สามารถคาดหวังการปรับปรุงที่สำคัญ ซึ่งส่วนใหญ่อยู่ในรูปของการทำธุรกรรมที่เร็วขึ้นและค่าธรรมเนียมที่ลดลง การใช้งานที่ประสบความสำเร็จจะช่วยเพิ่มความสามารถในการแข่งขันของ Ethereum ในพื้นที่ cryptocurrency
สำหรับผู้ใช้ที่เกี่ยวข้องกับการเข้าถึงข้อมูลจาก blobs เก่าที่ถูกลบไปแล้ว สิ่งสำคัญคือต้องทราบว่า แม้ว่า blobs จะถูกลบหลังจากผ่านไปสองสามสัปดาห์ แต่ข้อมูลของพวกเขาควรยังคงอยู่ในที่จัดเก็บระยะยาวที่ดูแลโดยชั้นฉันทามติของ Ethereum
ธุรกรรมหยด
EIP-4844 แนะนำประเภทธุรกรรมใหม่ "ธุรกรรมหยด" ตามมาตรฐาน EIP-2718 TransactionType ของธุรกรรม blob คือ BLOB_TX_TYPE และ TransactionPayload คือการจัดลำดับ RLP ของ TransactionPayloadBody ซึ่งรวมถึง chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_data_gas, blob_versioned_hashes, y_parity, ฟิลด์ต่างๆ เช่น r และ ส.
ซึ่งแตกต่างจากธุรกรรมการสร้างปกติ ฟิลด์ "ถึง" ของธุรกรรมหยดต้องแสดงที่อยู่ 20 ไบต์และไม่สามารถเป็นศูนย์ได้
EIP-2718 ReceiptPayload ของธุรกรรม blob ประกอบด้วยสถานะ cumulative_transaction_gas_used, logs_bloom และบันทึก เข้ารหัสเป็น RLP
รูปแบบธุรกรรมหยด:
EIP-2718 ReceiptPayload ของธุรกรรม blob ประกอบด้วยสถานะ cumulative_transaction_gas_used, logs_bloom และบันทึก เข้ารหัสเป็น RLP
รูปแบบธุรกรรมหยด:

เข้าสู่ระบบ
ค่าลายเซ็น y_parity, r และ s สำหรับธุรกรรม blob คำนวณโดยการสร้างลายเซ็น secp256k1 บนไดเจสต์เฉพาะ ข้อมูลสรุปได้มาจากการต่อและแฮชการทำให้เป็นอันดับ RLP ของ BLOB_TX_TYPE และ chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_data_gas และ blob_versioned_hashes โดยใช้อัลกอริทึมการแฮช keccak256
การคำนวณลายเซ็น:
ไดเจสต์ = keccak256(BLOB_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_data_gas, blob_versioned_hashes]))
ลายเซ็น = secp256k1_sign (ไดเจสต์, private_key)
y_parity, r, s = extract_signature_parts(ลายเซ็น) ส่วนขยายของหัว
EIP-4844 ขยายการเข้ารหัสส่วนหัวปัจจุบันโดยแนะนำฟิลด์จำนวนเต็ม 64 บิตที่ไม่ได้ลงนามใหม่สองฟิลด์: data_gas_used และexcess_data_gas ช่อง data_gas_used ระบุจำนวน data gas ทั้งหมดที่ใช้โดยธุรกรรมในบล็อก ช่องexcess_data_gasติดตามค่าสะสมของก๊าซข้อมูลที่เกินค่าเป้าหมาย โดยมีค่าต่ำสุดเป็น 0 บล็อกที่เกินปริมาณการใช้ก๊าซข้อมูลเป้าหมายจะเพิ่มมูลค่าของส่วนเกิน_data_gas ในขณะที่บล็อกที่ต่ำกว่าค่าเป้าหมายจะลดค่าลง
รหัสส่วนหัว:

Opcode เพื่อรับเวอร์ชันแฮช
EIP-4844 แนะนำ opcode ใหม่ที่เรียกว่า BLOBHASH (โดยใช้ HASH_OPCODE_BYTE เป็น opcode byte) เพื่อรับแฮชเวอร์ชัน opcode นี้อ่านดัชนี uint256 big-endian จากสแต็กและแทนที่ด้วย tx.blob_versioned_hashes[index] หากดัชนีอยู่ภายในช่วงของรายการ blob_versioned_hashes มิฉะนั้น ดัชนีจะถูกแทนที่ด้วยไบต์ที่มีค่าเป็นศูนย์32 ก๊าซที่ใช้โดย opcode นี้กำหนดโดย HASH_OPCODE_GAS
รหัส BLOBHASH:
รหัส BLOBHASH:

การคอมไพล์การประเมินแบบดอท
แนะนำการคอมไพล์ล่วงหน้าใหม่ที่ POINT_EVALUATION_PRCOMPILE_ADDRESS สำหรับตรวจสอบการพิสูจน์ KZG หลักฐานแสดงให้เห็นว่าหยดที่แสดงโดยสัญญาจะประเมินค่าตามที่กำหนด ณ จุดใดจุดหนึ่ง การรวบรวมล่วงหน้านี้ดำเนินการโดยมีค่าใช้จ่าย POINT_EVALUATION_PRCOMPILE_GAS ตรวจสอบความสัมพันธ์ของข้อผูกมัดกับ versioned_hash ที่ให้มา และยืนยันการพิสูจน์ KZG โดยใช้ข้อผูกมัด จุด และค่าการพิสูจน์
pip ประเมินคอมไพล์ล่วงหน้า:
def point_evaluation_precompile (อินพุต: ไบต์) -> ไบต์:
versioned_hash = อินพุต [:32]
z = อินพุต[32:64]
y = อินพุต[64:96]
ความมุ่งมั่น = อินพุต [96:144]
หลักฐาน = อินพุต[144:192]
ยืนยัน kzg_to_versioned_hash (ความมุ่งมั่น) == versioned_hash
ยืนยันการ Verify_kzg_proof(ความมุ่งมั่น, z, y, การพิสูจน์)
คืนค่าไบต์(U256(FIELD_ELEMENTS_PER_BLOB).to_be_bytes32() + U256(BLS_MODULUS).to_be_bytes32()) การคำนวณแก๊ส
EIP-4844 แนะนำก๊าซข้อมูลเป็นชนิดใหม่ที่ไม่ขึ้นกับก๊าซปกติ เช่นเดียวกับ EIP-1559 ก๊าซข้อมูลเป็นไปตามกฎปลายทางของมันเอง ฟิลด์ส่วนหัวของexcess_data_gasเก็บข้อมูลถาวรที่จำเป็นในการคำนวณราคาก๊าซข้อมูล ปัจจุบัน เฉพาะราคาหยดเท่านั้นที่ใช้ดาต้าแก๊ส
สูตรการคำนวณแก๊ส:
data_fee = calc_data_fee (ส่วนหัว, tx)
total_data_gas = get_total_data_gas(tx)
data_gasprice = get_data_gasprice (ส่วนหัว)
calc_data_fee(ส่วนหัว, tx) = get_total_data_gas(tx) * get_data_gasprice(ส่วนหัว)
get_total_data_gas(tx) = DATA_GAS_PER_BLOB * len(tx.blob_versioned_hashes)
get_data_gasprice(ส่วนหัว) = fake_exponential(MIN_DATA_GASPRICE, header.excess_data_gas, DATA_GASPRICE_UPDATE_FRACTION) การยืนยันเลเยอร์ฉันทามติ
get_data_gasprice(ส่วนหัว) = fake_exponential(MIN_DATA_GASPRICE, header.excess_data_gas, DATA_GASPRICE_UPDATE_FRACTION) การยืนยันเลเยอร์ฉันทามติ
ในชั้นฉันทามติ หยดจะถูกอ้างอิงแต่ไม่ได้เข้ารหัสทั้งหมดภายในบล็อกบีคอน แต่จะเผยแพร่ในรูปแบบ "บายพาส" เลเยอร์ฉันทามติช่วยให้มั่นใจได้ถึงความพร้อมใช้ของ blob และจัดการการประมวลผลของบล็อกบีคอนที่อัปเดต เผยแพร่และซิงโครไนซ์ประเภทบล็อกบีคอนและบายพาสของบล็อกใหม่ และสร้างบล็อกบีคอนที่มีบายพาสของบล็อกที่เกี่ยวข้อง
การตรวจสอบความถูกต้องของชั้นการดำเนินการ
เลเยอร์การดำเนินการบังคับใช้เงื่อนไขที่ถูกต้องสำหรับบล็อก รวมถึงการอัพเดทexcess_data_gas ยอดเงินที่เพียงพอสำหรับธุรกรรม blob การมีอยู่ของ blob อย่างน้อยหนึ่ง การตรวจสอบเวอร์ชันแฮชของ blob ยืนยันว่าเป็นไปตามราคาของ data gas ในปัจจุบัน การติดตามปริมาณการใช้ data gas ทั้งหมด และบังคับใช้แต่ละ ขีด จำกัด ดาต้าแก๊สสูงสุดสำหรับบล็อก
เครือข่าย
มีตัวแทนสองเครือข่ายสำหรับธุรกรรม blob: PooledTransactions และ BlockBodies PooledTransactions ใช้รูปแบบ wrapper รวมถึง EIP-2718 TransactionPayload, blobs, สัญญาผูกมัด และการพิสูจน์ องค์ประกอบเหล่านี้จะสรุปข้อมูลที่จำเป็นในการตรวจสอบความถูกต้องของธุรกรรมหยด BlockBodies สำหรับการตอบสนองการดึงเนื้อหาเป็นไปตามรูปแบบธุรกรรม EIP-2718 blob TransactionPayload มาตรฐาน
โหนดไม่ถ่ายทอดธุรกรรม blob ไปยังเพียร์โดยอัตโนมัติ ธุรกรรมเหล่านี้จะถูกโฆษณาโดยใช้ข้อความ NewPooledTransactionHashes แทน และสามารถร้องขอได้ด้วยตนเองโดยใช้ GetPooledTransactions
สรุปแล้ว
EIP-4844 เป็นขั้นตอนสำคัญสู่การแบ่งส่วนย่อยทั้งหมด ซึ่งสอดคล้องกับเป้าหมายของ Ethereum ในการจัดเตรียมการปรับสเกลแบบเฉพาะกิจสำหรับการยกเลิก EIP-4844 อนุญาตให้โรลอัปปรับขนาดได้สูงสุด 0.375 MB ต่อสล็อตโดยแนะนำธุรกรรม blob ที่สอดคล้องกับรูปแบบที่คาดไว้โดยข้อกำหนดการแบ่งส่วนขั้นสุดท้าย มันสร้างตลาดค่าธรรมเนียมอิสระที่คงค่าธรรมเนียมต่ำในขณะที่ระบบมีการใช้งานอย่างจำกัด
การออกแบบ EIP-4844 สร้างความสมดุลระหว่างการบรรลุผลลัพธ์และการลดภาระของการพัฒนาในอนาคต มันช่วยพัฒนางานที่จำเป็นอย่างมากในการปรับใช้ Sharding เต็มรูปแบบ รวมถึงประเภทธุรกรรมใหม่ ลอจิกเลเยอร์การดำเนินการ การตรวจสอบความถูกต้องข้ามฉันทามติ ลอจิกบล็อกบีคอน และการกำหนดราคาก๊าซอิสระที่ปรับเปลี่ยนได้สำหรับ blobs
การทำงานเพิ่มเติมเพื่อเปิดใช้งานการแบ่งส่วนย่อยทั้งหมดรวมถึงส่วนขยายการสุ่มตัวอย่าง 2 มิติ การใช้งานการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล การแยกผู้เสนอ/ผู้สร้าง และข้อกำหนดการพิสูจน์การคุมขังสำหรับผู้ตรวจสอบความถูกต้อง
EIP-4844 ยังปูทางสำหรับการปรับปรุงโปรโตคอลในอนาคตและการล้างข้อมูล เช่น การใช้กฎการอัปเดตราคาก๊าซกับการคำนวณฐานหลัก
ความคิดเห็นทั้งหมด