ส่งต่อชื่อเรื่องต้นฉบับ: การ Hardfork ของ Prague/Electra (Pectra) อธิบาย

นำเสนอ

ในบทความก่อนหน้านี้ เราได้ทบทวนอย่างละเอียดถึงวงจรชีวิตของผู้ตรวจสอบ Ethereum โดยอธิบายเกี่ยวกับด้านหลายด้านที่เกี่ยวข้องกับการอัพเกรด Electra ที่กำลังจะมาถึง ตอนนี้เวลาที่จะโฟกัสไปที่การเปลี่ยนแปลงที่กำลังจะมาถึงในอัพเกรดทั้งสองของ Electra และ Prague และอธิบายรายละเอียด

ประวัติความเป็นมาของ Ethereum 2.0 "proof-of-stake" hardforks นั้นซับซ้อน เริ่มต้นด้วยการเพิ่มเลเยอร์บีคอนลงในเลเยอร์การดําเนินการที่มีอยู่, เปิดตัวฉันทามติ proof-of-stake บนเลเยอร์บีคอนในขณะที่ยังคงรักษา proof-of-work บนเลเยอร์การดําเนินการ (Phase0 และ Altair hardforks). จากนั้น PoS ก็เปิดใช้งานอย่างสมบูรณ์ที่ Bellatrix hardfork (แม้ว่าจะไม่ได้เปิดใช้งานการถอนเงิน) ต่อจากนั้น Capella hardfork อนุญาตให้ถอนเงินโดยเสร็จสิ้นวงจรชีวิตของผู้ตรวจสอบความถูกต้อง Hardfork ล่าสุด, Deneb (ส่วนหนึ่งของการอัปเกรด Dencun (Deneb / Cancun)) นําการแก้ไขเล็กน้อยมาสู่พารามิเตอร์ห่วงโซ่บีคอน, เช่นกรอบเวลาสําหรับการรวมการรับรอง, การจัดการทางออกโดยสมัครใจ, และขีด จํากัด การเลิกใช้ผู้ตรวจสอบ. การเปลี่ยนแปลงหลักใน Dencun อยู่ในชั้นการดําเนินการแนะนํานวัตกรรมเช่นธุรกรรม blob, blob gas, ความมุ่งมั่นของ KZG สําหรับ blobs และการเลิกใช้การดําเนินการ SELFDESTRUCT

ตอนนี้ Prague/Electra hardfork แนะนําการอัพเกรดที่สําคัญทั้งชั้นการดําเนินการและชั้นฉันทามติ ในฐานะผู้ตรวจสอบโครงการ Lido เรามุ่งเน้นที่ฉันทามติและการเปลี่ยนแปลงที่เกี่ยวข้องกับการปักหลักใน hardfork นี้เป็นหลัก อย่างไรก็ตามเราไม่สามารถเพิกเฉยต่อการเปลี่ยนแปลงเลเยอร์การดําเนินการในปรากได้เนื่องจากมีคุณสมบัติที่สําคัญที่ส่งผลกระทบต่อเครือข่ายและผู้ตรวจสอบของ Ethereum มาดําดิ่งสู่รายละเอียดของการเปลี่ยนแปลงเหล่านี้

ภาพรวมระดับสูงของ Pectra

Electra มีการนำเสนอคุณสมบัติหลากหลายสำหรับชั้น Beacon ซึ่งประกอบไปด้วยการอัปเดตหลักที่สำคัญ:

• ให้ผู้ตรวจสอบมียอดคงเหลือที่มีประสิทธิภาพตั้งแต่ 32 ถึง 2048 ETH (แทนที่จะมีคงที่ที่ 32 ETH)
• การเปิดให้ผู้ตรวจสอบสามารถเริ่มต้นการออกจากการเชื่อมต่อด้วยข้อมูลประจำตัว"การถอน"(ไม่ต้องการคีย์ผู้ตรวจสอบที่ใช้งานอยู่อีกต่อไป)
• การเปลี่ยนวิธีการประมวลผลเงินฝาก Eth1 โดยชั้น Beacon (การเลิกใช้การวิเคราะห์เหตุการณ์จากสัญญาเงินฝาก)
• เพิ่มกรอบงานทั่วไปใหม่สำหรับการจัดการคำขอจากสัญญา Eth1 ปกติบนชั้น beacon (คล้ายกับวิธีที่การฝากเงินถูกบริหารจัดการก่อน Electra)

ในที่เดียวกัน ปรากูประกาศเปลี่ยนแปลงในชั้นการดำเนินงาน เช่น:

• สัญญาก่อนการคอมไพล์ใหม่ที่สนับสนุนเส้น BLS12-381 เพื่อการตรวจสอบพิสูจน์ zkSNARK (นอกจากเส้น BN254 ที่นิยม)
• สัญญาระบบใหม่สำหรับเก็บและเข้าถึงไฮแอชบล็อกประวัติสูงสุด 8192 (มีประโยชน์สำหรับผู้ใช้ที่ไม่เก็บสถานะ)
• ค่า gas ของ calldata เพิ่มเพื่อลดขนาดบล็อกและส่งเสริมให้โครงการย้ายการดำเนินการที่ใช้ calldata (เช่น rollups) ไปยัง blobs ซึ่งถูกนำเสนอใน Dencun
• รองรับจำนวนของ blobs ที่มากกว่าต่อบล็อก Eth1 พร้อมกับ API เพื่ออ่านจำนวนเหล่านี้
• การอนุญาตให้ EOA (บัญชีที่เป็นเจ้าของจากภายนอก) มีรหัสบัญชีของตัวเอง ที่เพิ่มขยายอย่างมากว่าที่ EOA สามารถทำได้ เช่น การดำเนินการมากหลายครั้งหรือมอบหมายการดำเนินการให้กับที่อยู่อื่น

เรามาอ้างถึง Ethereum Improvement Proposals (EIPs) ที่เกี่ยวข้องเพื่อให้การสนทนาเป็นไปอย่างราบรื่น:

• EIP-7251: เพิ่ม MAX_EFFECTIVE_BALANCE
• EIP-7002: การออกจากระบบที่สามารถเรียกใช้ชั้นการดำเนินการ
• EIP-6110: มอบเงินมัดจำผู้ตรวจสอบบนเชน
• EIP-7549: เลื่อนดัชนีคณะกรรมการออกนอกการรับรอง
• EIP-7685: คำขอชั้นทั่วไปสำหรับการดำเนินการ
• EIP-2537: Precompile for BLS12-381 curve operations
• EIP-2935: บันทึกค่าแฮชบล็อกทางประวัติในสถานะ
• EIP-7623: เพิ่มค่าใช้จ่ายของข้อมูลการเรียก
• EIP-7691: ความเร็วในการถ่ายโอนข้อมูลเพิ่มขึ้น
• EIP-7840: เพิ่มตาราง blob ไปยังไฟล์ EL config
• EIP-7702: ตั้งรหัสบัญชี EOA

บางส่วนของ EIP เหล่านี้เน้นที่ระดับความเห็น (beacon) ในขณะที่อื่นๆ เกี่ยวข้องกับระดับการดำเนินการ บางส่วนครอบคลุมทั้งทั้ง 2 ระดับ เนื่องจากการดำเนินการบางอย่างเช่นการฝากเงินและการถอนต้องการการเปลี่ยนแปลงที่ประสานกันทั้งในระดับความเห็นและระดับการดำเนินการ ด้วยเหตุนี้การแยก Electra และ Prague เป็นสิ่งที่ไม่ปฏิบัติได้เราจะทบทวน EIP แต่ละตัวตามลำดับและระบุส่วนประสบความเสียหายของ Ethereum ในแต่ละกรณี

EIP-7251: เพิ่ม MAX_EFFECTIVE_BALANCE

Reference: EIP-7251

ตั้งแต่ Hardfork Phase0 แรกดําเนินการเพื่อเตรียม Ethereum สําหรับ Proof-of-Stake และจนถึง Electra ความสมดุลที่มีประสิทธิภาพสูงสุดของผู้ตรวจสอบความถูกต้องได้รับการแก้ไขที่ 32 ETH การเปิดใช้งานตัวตรวจสอบความถูกต้องต้องมี spec.min_activation_balance อย่างน้อย (32 ETH) หลังจากเปิดใช้งานผู้ตรวจสอบจะเริ่มต้นด้วยยอดคงเหลือที่มีประสิทธิภาพสูงสุดนี้ แต่สามารถลดยอดคงเหลือที่มีประสิทธิภาพเป็น spec.ejection_balance (16 ETH) และจะถูกดีดออกเมื่อถึงเกณฑ์นั้น ตรรกะ "ขั้นต่ํา" นี้ยังคงไม่เปลี่ยนแปลงใน Electra แต่ตอนนี้ spec.max_effective_balance เพิ่มขึ้นเป็น 2048 ETH ด้วยเหตุนี้ผู้ตรวจสอบความถูกต้องจึงสามารถฝากเงินได้ทุกที่ระหว่าง 32 ถึง 2048 ETH เพื่อเปิดใช้งานโดยจํานวนเงินทั้งหมดในช่วงนี้เอื้อต่อยอดคงเหลือที่มีประสิทธิภาพ การเปลี่ยนแปลงนี้นับเป็นการย้ายจาก "proof-of-32ETH-stake" เป็น "proof-of-stake" :)

ความสมดุลที่มีผลของตัวแปรนี้จะถูกใช้เดี๋ยวนี้

• เพื่อเพิ่มโอกาสที่จะเป็นผู้เสนอบล็อก แบบสัมบูรณ์ต่อยอดยอดคงความสมดุล
• เพื่อเพิ่มโอกาสในการเป็นสมาชิกคณะกรรมการการซิงค์ สัมพันธ์ตามยอดคงเหลือที่มีผล
• เป็นพื้นฐานสำหรับคำนวณจำนวนโทษการลดทอนและค่าปรับการไม่ใช้งานที่สัมพันธ์

กิจกรรมสองกิจกรรมแรกเป็นกิจกรรมที่สร้างผลประโยชน์มากที่สุดสำหรับผู้ตรวจสอบ ดังนั้นหลังจาก Electra ผู้ตรวจสอบที่มีส่วนได้เสียที่มากขึ้นจะมีส่วนร่วมในการเสนอบล็อกและคณะกรรมการการประสานบ่อยขึ้นตามสัดส่วนกับยอดคงเหลือที่มีผล

ผลกระทบอื่น ๆ เกี่ยวข้องกับการตัดสินใจ โทษการตัดสินใจทั้งหมดเป็นสัมพันธ์ต่อยอดความสามารถของผู้ตรวจสอบ:

• โทษการตัดสินให้โดยตรงและการตัดสินในภายหลังมีขนาดใหญ่กว่าสำหรับผู้ตรวจสอบที่มีเงินเดิมพันสูงกว่า
• “การลดความรุนแรง” โทษสำหรับผู้ตรวจสอบที่ถูกตัดสินหน้าที่ผู้ตรวจสอบมีการเพิ่มขึ้น เนื่องจากส่วนที่ถูกตัดของมูลค่ารวมก้อนทุนมีมูลค่ามากกว่า
• ผู้รายงานที่รายงานผู้ตรวจสอบด้วยยอดเงินสะสมที่มีผลทำให้ได้รับส่วนใหญ่ของเงินทุบ

Electra ยังมีข้อเสนอเปลี่ยนแปลงในส่วนของการลดการตัดเหล็ก, กำหนดส่วนของมูลค่าของผู้ตรวจสอบที่ถูกตัดและได้รับจากผู้แจ้งรายนั้น

ผลกระทบจากการไม่ใช้งานจะเกิดขึ้นต่อไป เมื่อผู้ตรวจสอบออกจากเครือข่ายขณะที่เป็นแบบใช้งาน (การยืนยันหรือการเสนอข้อเสนอ) คะแนนการไม่ใช้งานจะสะสมขึ้น และจะทำให้มีการลงโทษการไม่ใช้งานทุกๆ epoch การลงโทษเหล่านี้จะเป็นพร้อมสัดส่วนกับยอดคงเหลือที่มีผลต่อผู้ตรวจสอบ

“ขีดจำกัดการหมุน” ของผู้ตรวจสอบยังเปลี่ยนแปลงเนื่องจากมูลค่ามีผลเพิ่มขึ้นด้วย ใน Ethereum “pre-Electra” ผู้ตรวจสอบมักจะมีมูลค่าที่มีผลเท่ากัน และขีดจำกัดการออกไปจะถูกกำหนดว่า “ไม่เกิน 1/65536 (spec.churn_limit_quotient) ของมูลค่ารวมสามารถออกไปในแต่ละยุค” นี้สร้างจำนวนผู้ตรวจสอบที่ออกไปที่มีมูลค่าเท่ากัน อย่างไรก็ตามใน “post-Electra” อาจเกิดสถานการณ์ที่ “ปลาวาฬ” เพียงไม่กี่คนออกไปเท่านั้น เนื่องจากพวกเขาแทนส่วนใหญ่ของมูลค่ารวม

ข้อควรพิจารณาอีกประการหนึ่งคือการหมุนคีย์ผู้ตรวจสอบความถูกต้องจํานวนมากบนอินสแตนซ์ผู้ตรวจสอบความถูกต้องเดียว ปัจจุบันผู้ตรวจสอบความถูกต้องรายใหญ่ถูกบังคับให้เรียกใช้คีย์ผู้ตรวจสอบความถูกต้องหลายพันรายการบนอินสแตนซ์เดียวเพื่อรองรับเงินเดิมพันจํานวนมาก โดยแบ่งออกเป็น 32 ส่วน ETH ด้วย Electra พฤติกรรมนี้ไม่จําเป็นอีกต่อไป การเปลี่ยนแปลงนี้สร้างความแตกต่างเพียงเล็กน้อยเนื่องจากรางวัลและความน่าจะเป็นปรับขนาดเป็นเส้นตรงด้วยจํานวนเงินที่เดิมพัน ดังนั้นผู้ตรวจสอบความถูกต้อง 100 คนที่มี 32 ETH แต่ละคนเทียบเท่ากับผู้ตรวจสอบหนึ่งคนที่มี 3200 ETH นอกจากนี้คีย์ผู้ตรวจสอบที่ใช้งานอยู่หลายคีย์สามารถมีข้อมูลรับรองการถอน Eth1 เดียวกันทําให้สามารถถอนรางวัลทั้งหมดไปยังที่อยู่ ETH เดียวและหลีกเลี่ยงค่าใช้จ่ายก๊าซที่เกี่ยวข้องกับการรวมรางวัล อย่างไรก็ตามการจัดการคีย์จํานวนมากมีค่าใช้จ่ายด้านการบริหารเพิ่มเติม

ความสามารถในการรวมยอดผู้ตรวจสอบเพิ่มเติมเป็นการของชั้นการดำเนินงานประเภทอื่น ก่อนหน้านี้ เรามีการฝากเงินและถอนเงิน ตอนนี้ จะมีประเภทอื่นอีกหนึ่งประเภท: คำขอรวมยอด จะรวมผู้ตรวจสอบสองรายให้เป็นหนึ่ง คำขอดำเนินการนี้จะรวมประกอบกันโดยมี pubkey ของผู้ตรวจสอบแหล่งและ pubkey เป้าหมาย และจะดำเนินการเช่นเดียวกับการฝากเงินและถอนเงิน การรวมยอดยังจะมีคำขอที่รอดำเนินการและขีดจำกัดยอดคงเหลือเช่นเดียวกับการฝากเงินและถอนเงิน

สรุปคือ:

• สําหรับผู้ตรวจสอบเดี่ยวขนาดเล็ก Electra แนะนําความสามารถในการเพิ่มความสมดุลที่มีประสิทธิภาพโดยอัตโนมัติ (และรางวัล) ก่อนหน้านี้ส่วนเกินใด ๆ ที่สูงกว่า 32 ETH สามารถถอนได้เท่านั้น แต่หลังจาก Electra ส่วนเกินนี้จะนําไปสู่ความสมดุลที่มีประสิทธิภาพในที่สุด อย่างไรก็ตามความสมดุลที่มีประสิทธิภาพสามารถเพิ่มขึ้นได้เฉพาะในพหุคูณของ spec.effective_balance_increment (1 ETH) ซึ่งหมายความว่าการเพิ่มขึ้นจะเกิดขึ้นหลังจากถึง "1 ETH ผูก" ถัดไปเท่านั้น
• สำหรับผู้ตรวจสอบโซโลขนาดใหญ่ Electra มีการจัดการที่ง่ายขึ้นอย่างมีนัยจากการอนุญาตให้รวมกุญแจผู้ตรวจสอบที่ใช้งานจริงหลายตัวเข้าด้วยกันเป็นหนึ่ง ในขณะที่ไม่ใช่เรื่องที่เปลี่ยนเกม การดำเนินการแทนทุน 1x2048 เพียงตัวเดียวเป็นเรื่องที่ไม่อาจปฏิเสธว่าง่ายกว่าการจัดการกับแทนทุน 64x32
• สำหรับผู้ให้บริการการมีส่วนร่วมที่เหลว ซึ่งรวบรวมการมีส่วนร่วมขนาดเล็กจากผู้ใช้และแจกจ่ายให้กับผู้ตรวจสอบมากขึ้น อิเล็กตราเพิ่มความยืดหยุ่นในระบบการแจกจ่ายมีส่วนร่วม แต่ในเวลาเดียวกัน ต้องการการปรับปรุงระบบการบัญชีผู้ตรวจสอบอย่างจริงจัง ซึ่งในปัจจุบันขึ้นอยู่กับยอดคงเหลือที่มีประสิทธิภาพ 32 ETH ที่แน่นอน

อีกหัวข้อที่สําคัญคือข้อมูลในอดีตและการประมาณการกําไรสําหรับผู้ตรวจสอบความถูกต้องซึ่งมีความเกี่ยวข้องโดยเฉพาะอย่างยิ่งสําหรับผู้เข้าร่วมใหม่ที่พยายามประเมินความเสี่ยงและผลตอบแทน หมวก 32 ETH (ทั้งต่ําสุดและสูงสุดในทางปฏิบัติ) ก่อนที่ Electra (ณ วันที่เขียนบทความนี้) จะสร้างความสม่ําเสมอในข้อมูลในอดีต ผู้ตรวจสอบความถูกต้องทั้งหมดมียอดคงเหลือรางวัลบทลงโทษที่ลดลงความถี่ของข้อเสนอบล็อกและตัวชี้วัดอื่น ๆ ที่เท่าเทียมกัน ความสม่ําเสมอนี้ทําให้ Ethereum สามารถทดสอบกลไกฉันทามติกับผู้ตรวจสอบจํานวนมากโดยไม่มีค่าผิดปกติทางสถิติรวบรวมข้อมูลพฤติกรรมเครือข่ายที่มีค่า

หลังจาก Electra การกระจายเงินเดิมพันจะเปลี่ยนไปอย่างมาก ผู้ตรวจสอบความถูกต้องขนาดใหญ่จะเข้าร่วมบ่อยขึ้นในข้อเสนอบล็อกและคณะกรรมการซิงค์ได้รับบทลงโทษที่มากขึ้นในกิจกรรมเฉือนและมีอิทธิพลมากขึ้นในการเฉือนที่เลื่อนออกไปคิวการเปิดใช้งานและคิวออก แม้ว่าสิ่งนี้อาจสร้างความท้าทายในการรวมข้อมูล แต่ฉันทามติของ Ethereum ทําให้มั่นใจได้ว่าการคํานวณที่ไม่ใช่เชิงเส้นมีน้อย ส่วนประกอบที่ไม่ใช่เชิงเส้นเพียงชิ้นเดียวใช้ sqrt(total_effective_balance) เพื่อคํานวณรางวัลพื้นฐาน ซึ่งใช้กับผู้ตรวจสอบความถูกต้องทั้งหมดอย่างสม่ําเสมอ ซึ่งหมายความว่ารางวัลผู้ตรวจสอบความถูกต้องและการเฉือนยังคงสามารถประมาณได้บนพื้นฐาน "ต่อ 1 ETH" (หรือแม่นยํายิ่งขึ้นต่อ spec.effective_balance_increment ซึ่งอาจเปลี่ยนแปลงได้ในอนาคต)

สำหรับรายละเอียดเพิ่มเติม โปรดอ้างถึงบทความก่อนหน้าของเราเกี่ยวกับพฤติกรรมของผู้ตรวจสอบ

EIP-7002: การออกจากชั้นดำเนินการที่สามารถเรียกใช้ได้

อ้างอิง: EIP-7002

แต่ละผู้ตรวจสอบใน Ethereum มีคีย์เพื่อใช้งานสองคู่: คีย์ที่ทำงานอยู่และคีย์ที่ถอนออก คีย์ BLS สาธารณะที่ทำงานอยู่ใช้เป็นตัวแทนหลักของผู้ตรวจสอบใน beacon chain และคู่คีย์นี้ใช้สำหรับการเซ็นต์บล็อก, การยืนยัน, การลดค่า, การรวบรวมคณะกรรมการซิงค์ และ (จนกว่า EIP นี้) การออกจากการเข้าร่วมของผู้ตรวจสอบอย่างสมัครใจ (เพื่อเริ่มต้นกระบวนการออกจากการเชื่อมต่อหลังจากการล่าช้า) คีย์คู่ที่สอง ("ข้อมูลของการถอน") สามารถเป็นคีย์คู่ BLS อื่นหรือบัญชี Eth1 ปกติ (คีย์ส่วนตัวและที่อยู่) ตอนนี้การถอนไปยังที่อยู่ ETH ต้องใช้ข้อความการถอนที่ลงนามด้วยคีย์ส่วนตัว BLS ที่ทำงานอยู่ เอกสาร EIP นี้เปลี่ยนแปลงสิ่งนั้น

ในทางปฏิบัติเจ้าของคีย์สองคู่นี้ (ใช้งานและถอน) อาจแตกต่างกัน คีย์ที่ใช้งานอยู่ของผู้ตรวจสอบมีหน้าที่รับผิดชอบในการตรวจสอบความถูกต้อง: เรียกใช้เซิร์ฟเวอร์ทําให้ใช้งานได้ ฯลฯ ในขณะที่ข้อมูลรับรองการถอนมักจะถูกควบคุมโดยเจ้าของเงินเดิมพันซึ่งได้รับรางวัลและรับผิดชอบเงิน ปัจจุบันเจ้าของเงินเดิมพันที่ควบคุมเฉพาะข้อมูลรับรองการถอนไม่สามารถเริ่มต้นการออกจากผู้ตรวจสอบความถูกต้องและสามารถถอนรางวัลได้เท่านั้น สถานการณ์นี้ช่วยให้เจ้าของคีย์ที่ใช้งานอยู่ของผู้ตรวจสอบสามารถจับยอดคงเหลือของผู้ตรวจสอบได้อย่างมีประสิทธิภาพในฐานะ "ตัวประกัน" ผู้ตรวจสอบความถูกต้องสามารถ "ลงนามล่วงหน้า" ออกจากข้อความและมอบให้กับเจ้าของหุ้นได้ แต่วิธีแก้ปัญหานี้ไม่เหมาะ นอกจากนี้, ทั้งการถอนและการออกในปัจจุบันต้องมีการโต้ตอบกับตัวตรวจสอบเลเยอร์บีคอนโดยใช้ API พิเศษ.

วิธีการที่ดีที่สุดคืออนุญาตให้เจ้าของสเตคที่จะทำการออกและถอนเงินโดยใช้การเรียกสัญญาสมาร์ทปกติ ซึ่งเกี่ยวข้องกับการตรวจสอบลายเซ็นเจาะจง Eth1 มาตรฐาน ทำให้งานเรียบง่ายขึ้น

EIP นี้ช่วยให้เจ้าของสเตคสามารถเริ่มการถอนและออกจากการเดิมพันผ่านธุรกรรมมาตรฐานจากที่อยู่ ETH ของพวกเขาไปยังสัญญาอัจฉริยะที่ได้รับการจัดสรร (คล้ายกับกระบวนการฝากที่ใช้สัญญา 'ฝาก' ที่มีอยู่) กระบวนการถอน (หรือออก ถ้ามีจำนวนเงินเดิมพันเพียงพอที่จะถอน) ทำงานตามวิธีต่อไปนี้:

• เจ้าของสเตคส่งคำขอถอน (“คำขอเข้า”) ไปยังสัญญา “การถอน” ของระบบ
• สัญญาเรียกเก็บค่าธรรมเนียมเฉพาะ (ในปี ETH) เพื่อลดการโจมตีที่น่าเศร้าที่อาจเกิดขึ้นและดําเนินการคล้ายกับ EIP-1559 โดยมีค่าธรรมเนียมเพิ่มขึ้นเมื่อคิวคําขอไม่ว่าง
• สัญญาจะบันทึกคำขอถอน/ออก "in" ไปยังการเก็บรักษาของมัน
• เมื่อบล็อกถูกเสนอให้กับชั้นบีคอน เราจะดึงคำขอการถอน/ออก "เข้า" ที่อยู่ในคิวจากการเก็บข้อมูล
• ชั้น Beacon ประมวลผลคำขอ "in" โดยปฏิสัมพันธ์กับยอดคงเหลือของผู้ตรวจสอบที่ใช้งาน กำหนดตารางเวลาให้กับผู้ตรวจสอบเพื่อออก และสร้างคำขอถอน "out"
• คำขอถอน "out" จะถูกประมวลผลบนเลเยอร์การปฏิบัติ และเจ้าของพื้นที่จะได้รับ ETH ของตน

ขณะที่การฝากเงินเป็นการดำเนินการที่ถูกเริ่มขึ้นในบล็อก Eth1 และจากนั้น “ย้าย” ไปที่ชั้น Beacon โดยใช้คิวการฝากเงินที่ “รอดำเนินการ” การถอนเงินก็มีรูปแบบที่แตกต่างกัน มันถูกเริ่มขึ้นที่ชั้น Beacon (ผ่าน CLI) และจากนั้น “ย้าย” ไปที่บล็อก Eth1 ตอนนี้ ทั้งสองรูปแบบจะดำเนินการโดยใช้กรอบทั่วไปเดียวกัน (ที่อธิบายด้านล่าง): สร้างคำขอที่ชั้น Eth1 การประมวลผลของคิวการฝากเงิน/การถอนเงิน/การรวมกันที่ “รอดำเนินการ” และการประมวลผลที่ชั้น Beacon สำหรับการดำเนินการที่เป็น “ผลลัพธ์” เช่น การถอนเงิน คิวผลลัพธ์ก็ถูกประมวลผล และผลลัพธ์จะถูก “ตรึงตั้ง” ในบล็อก Eth1

ด้วย EIP นี้เจ้าของสเตคสามารถถอนและออกจากตัวตรวจสอบของพวกเขาโดยใช้ธุรกรรม ETH ปกติโดยไม่จำเป็นต้องมีการจับคู่โดยตรงกับ CLI ของตัวตรวจสอบหรือเข้าถึงโครงสร้างพื้นฐานของตัวตรวจสอบ สิ่งนี้ทำให้การจัดการการจำนำตัวตรวจสอบง่ายขึ้นอย่างมากโดยเฉพาะสำหรับผู้ให้บริการสเตคขนาดใหญ่ โครงสร้างพื้นฐานของตัวตรวจสอบตอนนี้สามารถถูกแยกออกเกือบทั้งหมดเนื่องจากต้องรักษากุญแจตัวตรวจสอบที่ใช้งานอยู่เท่านั้น ในขณะที่การดำเนินการการจำนำทั้งหมดสามารถจัดการได้ที่ที่อื่น ๆ มันลบความจำเป็นที่ต้องรอการดำเนินการของตัวตรวจสอบที่ทำงานอยู่เดียวและทำให้สิ่งที่อยู่นอกเชือกง่ายขึ้นอย่างมีนัยสำหรับบริการเช่นโมดูลการจำนำทางชุมชนจาก Lido

เนื่องจากฉะนั้น EIP นี้ “สมบูรณ์” การดำเนินการ Staking โดยการย้ายไปที่เลเยอร์ Eth1 อย่างสมบูรณ์ ลดความเสี่ยงด้านความปลอดภัยของโครงสร้างพื้นฐานอย่างมีนัยสำคัญ และเสริมสร้างความกระจายอำนาจของการเริ่มต้น Staking เดี่ยว

EIP-6110: ฝากเงินผู้ตรวจสอบ供應บนโซ่

อ้างอิง: EIP-6110

ปัจจุบันการฝากเงินจะดําเนินการผ่านเหตุการณ์ในสัญญา "ฝาก" ของระบบ (ตามที่กล่าวไว้ในรายละเอียดในบทความก่อนหน้า) สัญญายอมรับข้อมูลรับรอง ETH และผู้ตรวจสอบความถูกต้อง, ปล่อยเหตุการณ์ "Deposit()" และเหตุการณ์เหล่านี้จะถูกแยกวิเคราะห์ในภายหลังและเปลี่ยนเป็นคําขอฝากเงินในเลเยอร์บีคอน. ระบบนี้มีข้อเสียมากมาย: ต้องมีการลงคะแนนสําหรับ eth1data บนเลเยอร์โซ่บีคอน, ซึ่งเพิ่มความล่าช้าอย่างมาก. นอกจากนี้, เลเยอร์บีคอนจําเป็นต้องสืบค้นเลเยอร์การดําเนินการ, แนะนําความซับซ้อนเพิ่มเติม. ประเด็นเหล่านี้ถูกกล่าวถึงในรายละเอียดใน EIP วิธีที่ง่ายกว่าซึ่งขจัดปัญหาเหล่านี้ได้หลายอย่างเกี่ยวข้องกับการขอฝากเงินในบล็อก Eth1 ในสถานที่ที่กําหนดโดยตรง กลไกนี้สะท้อนกระบวนการจัดการการถอนเงินที่อธิบายไว้ใน EIP ก่อนหน้านี้

การเปลี่ยนแปลงที่เสนอใน EIP นี้มีความมั่นใจ การประมวลผลของ eth1data ตอนนี้สามารถลบออกได้ทั้งหมด โดยการกำจัดความจำเป็นในการลงคะแนนหรือความล่าช้าที่ยาวนานระหว่างเหตุการณ์ที่เกิดขึ้นทางด้าน Eth1 และการรวมฝากในเลเยอร์เสาร์ (ปัจจุบันอยู่ที่ราว 12 ชั่วโมง) นอกจากนี้ยังมีการลบตรรกสำหรับการถ่ายภาพของสัญญาฝาก EIP นี้ปรับปรุงการประมวลผลการฝากและปรับให้เข้ากันกับแผนการประมวลผลการถอนที่อธิบายไว้ด้านบน

สำหรับเจ้าของสเตคและผู้ตรวจสอบ การเปลี่ยนแปลงเหล่านี้ลดความล่าช้าระหว่างการฝากเงินและการเปิดใช้งานผู้ตรวจสอบลงอย่างมีนัยสำคัญ การเติมเงินเพิ่ม, ซึ่งจำเป็นเมื่อตัดเงินผู้ตรวจสอบ, ก็จะเร็วขึ้น

ไม่มีอะไรมากที่จะพูดเกี่ยวกับ EIP นี้นอกจากว่ามันจะลบตัวตนที่ล้าสมัยออก เพื่อทำให้กระบวนการง่ายขึ้นและสร้างผลลัพธ์ที่ดีกว่าสำหรับทุกคนที่เกี่ยวข้อง

EIP-7685: ของเลเยอร์การดำเนินการทั่วไปของเครือข่าย

อ้างอิง: EIP-7685

EIP นี้สามารถได้รับการนำเสนอได้ต่อเนื่องกับที่สาม EIP ก่อนหน้านี้เกี่ยวกับการฝากถอน/รวมรวม แต่เนื่องจาก EIP นี้จะเป็นพื้นฐานสำหรับการทำงานของพวกเขา ดังนั้น EIP นี้ถูกนำเสนอขึ้นที่นี่เพื่อเน้นถึงความต้องการที่เพิ่มขึ้นในการสร้างกลไกทั่วไปเพื่อเคลื่อนย้ายข้อมูลที่เฉพาะเจาะจงระหว่างบล็อกของ Eth1 (การประมวลผล) และ Beacon (ตรวจสอบ) (ชั้น) EIP นี้มีผลต่อชั้นทั้งสอง โดยทำให้การประมวลผลคำขอที่เกิดขึ้นจากธุรกรรม ETH ปกติมีประสิทธิภาพมากขึ้น ในปัจจุบันเราสังเกตเห็นว่า:

• เหตุการณ์การฝากเงินในบล็อก Eth1 กำลังถูก "ย้าย" จาก Eth1 ไปยังบล็อก Beacon เพื่อดำเนินการ
• คำขอถอนออกจากบล็อกบีคอน (โดยใช้ CLI) กำลังถูก "ย้าย" ไปยังบล็อก Eth1 เพื่อดำเนินการ
• ความจำเป็นในการจัดการการรวมกลุ่มของผู้ตรวจสอบที่เป็นคำขอ Eth1->Beacon ด้วย

การดำเนินการสามประการนี้เป็นการแสดงถึงความจำเป็นของการจัดการอย่างสม่ำเสมอสำหรับประเภทต่าง ๆ ของคำขอเมื่อพวกเขาเปลี่ยนแปลงระหว่างชั้นการกระทำและชั้นสัญญาณ นอกจากนี้เราต้องการความสามารถในการเริ่มการดำเนินการเหล่านี้โดยใช้ชั้น Eth1 เท่านั้น เนื่องจากสิ่งนี้จะช่วยให้เราแยกโครงสร้างพื้นฐานของผู้ตรวจสอบออกจากโครงสร้างการจัดการเงินเดิมพัน ที่ช่วยเสริมความมั่นคงปลอดภัย ดังนั้น การแก้ปัญหาทั่วไปในการจัดการคำขอเหล่านี้เป็นสิ่งจำเป็นและสำคัญ

EIPนี้จะสร้างกรอบงานสำหรับกรณีหลักอย่างน้อยสามกรณี: การฝากเงิน การถอนเงิน และการรวมกัน นี่คือเหตุผลที่ EIPก่อนหน้านี้ได้นำเข้าฟิลด์เช่น WITHDRAWAL_REQUEST_TYPE และ DEPOSIT_REQUEST_TYPE และตอนนี้การรวมกันจะเพิ่มอีกหนึ่งอย่าง คือ CONSOLIDATION_REQUEST_TYPE นอกจากนี้ EIPนี้ยังคงรวมกลไกการทำงานทั่วไปเพื่อจัดการขีดจำกัดสำหรับคำขอเหล่านี้ (อ้างอิงค่าคงที่: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT)

แม้ว่ารายละเอียดการปฏิบัติตามสำหรับเฟรมเวิร์กนี้ยังไม่มีอยู่ในขณะนี้ แต่มันก็คงจะรวมประเภทคำขอสำคัญ กลไกความสมบูรณ์ (เช่น การทำ Hashing และ Merkle-izing คำขอ) และการประมวลผลคิวที่รอดำเนินการพร้อมกับการจำกัดอัตรา

EIP นี้มีความสำคัญทางสถาปัตยกรรม ทำให้ Eth1 สามารถเรียกใช้การดำเนินการที่สำคัญในชั้น Beacon ผ่านเฟรมเวิร์ครวมกันได้ สำหรับผู้ใช้งานและโครงการ นี่หมายความว่าคำขอทั้งหมดที่เกิดขึ้นในชั้น Eth1 จะถูกส่งมอบและประมวลผลในชั้น Beacon อย่างมีประสิทธิภาพมากขึ้น

EIP-2537: Precompile for BLS12-381 curve operations

อ้างอิง: EIP-2537

หากคุณไม่ต้องการศึกษาลึกลงไปอีกมาก คุณสามารถคิดถึง BLS12-381 precompile ในลักษณะของ "การแฮช" ทางการประสาทที่ซับซ้อนที่สามารถใช้ในสมาร์ทคอนแทรคได้ตอนนี้ สำหรับผู้ที่สนใจ ให้เราสำรวจเรื่องนี้ต่อไป

การดำเนินการทางคณิตศาสตร์บนเส้นโค้งรูปวงเล็กเช่น BLS12-381 (และตัวช่วงเวลา BN-254) ถูกใช้ในปัจจุบันสำหรับวัตถุประสงค์สองอย่างหลัก:

• ลายมือ BLS ที่ใช้การดำเนินการพิเศษที่เรียกว่า "การจับคู่" เพื่อยืนยันลายมือเหล่านี้ ลายมือ BLS ถูกใช้กันอย่างแพร่หลายโดย validators เนื่องจากพวกเขาทำให้เกิดการรวมกลุ่มของลายมือหลาย ๆ ในหนึ่ง โดย validators พึงพอใจในลายมือ BLS ที่ใช้เส้นโค้ง BLS12-381 (แม้ว่าพวกเขาสามารถนำมาใช้ได้ด้วยเส้นโค้งใดก็ตามที่รองรับการจับคู่ เช่น BN254)
• การตรวจสอบพิสูจน์ zkSNARK ที่ใช้การจับคู่เพื่อตรวจสอบพิสูจน์ นอกจากนี้ KZG commitments ต่อ blobs (ที่ถูกนำเสนอโดย Dencun hard fork) ยังใช้การจับคู่ในการตรวจสอบการสัญญา blobs

หากคุณต้องการยืนยันลายเซ็นเจอร์ BLS หรือพิสูจน์ zkSNARK ภายในสมาร์ทคอนแทรคคุณต้องคำนวณ "คู่" เหล่านี้ซึ่งมีความใช้ทราบสูงมาก อีเธเรียมมีสัญญาก่อนเตรียมไว้สำหรับการดำเนินการบนเส้นโค้ง BN254 (EIP-196 และ EIP-197) อย่างไรก็ตาม เส้นโค้ง BLS12-381 (ซึ่งตอนนี้ได้รับการรับรองว่าปลอดภัยมากขึ้นและใช้กันอย่างแพร่หลายมากขึ้นในปัจจุบัน) ยังไม่ได้ถูกนำมาใช้เป็นสัญญาก่อนเตรียม โดยไม่มีสัญญาก่อนเตรียมเช่นนั้นการนำมาใช้คู่และการดำเนินการบนเส้นโค้งอื่นในสมาร์ทคอนแทรคต้องการการคำนวณที่มีน้ำหนักมาก เช่นที่แสดงไว้ที่นี่ และใช้ปริมาณก๊าซอย่างมาก (~10^5 ถึง 10^6 แก๊ส)

EIP นี้เปิดประตูสู่แอปพลิเคชันที่มีศักยภาพมากมายโดยเฉพาะอย่างยิ่งในการเปิดใช้งานการตรวจสอบลายเซ็น BLS ราคาถูกตามเส้นโค้ง BLS12-381 สิ่งนี้ทําให้สามารถใช้รูปแบบเกณฑ์เพื่อวัตถุประสงค์ต่างๆ ดังที่ได้กล่าวไว้ก่อนหน้านี้ผู้ตรวจสอบ Ethereum ใช้ลายเซ็นที่ใช้ BLS12-381 อยู่แล้ว ด้วย EIP นี้ สัญญาอัจฉริยะมาตรฐานสามารถทําการตรวจสอบลายเซ็นผู้ตรวจสอบรวมได้อย่างมีประสิทธิภาพ สิ่งนี้สามารถทําให้การพิสูจน์ฉันทามติและการเชื่อมโยงสินทรัพย์ระหว่างเครือข่ายง่ายขึ้นเนื่องจากลายเซ็น BLS ใช้กันอย่างแพร่หลายในบล็อกเชน ลายเซ็น BLS เกณฑ์ด้วยตัวเองช่วยให้สามารถสร้างรูปแบบเกณฑ์ที่มีประสิทธิภาพมากมายสําหรับการลงคะแนนการสร้างหมายเลขสุ่มแบบกระจายอํานาจมัลติซิกส์

การตรวจสอบพิสูจน์ zkSNARK ราคาถูกจะปลดล็อคแอปพลิเคชันจำนวนมาก มีหลายโซลูชันที่ใช้ zkSNARK ถูกขัดข้องโดยค่าใช้จ่ายสูงของการตรวจสอบพิสูจน์ ทำให้โครงการบางโครงการเกือบจะไม่ Prคิดได้ EIP นี้มีศักยภาพในการเปลี่ยนแปลง

EIP-2935: บันทึกค่า hash บล็อกประวัติในสถานะ

Reference: EIP-2935

EIP นี้เสนอการเก็บรักษาบล็อกแฮช 8192 (~27.3 ชั่วโมง) ในสถานะบล็อกเชื่อมต่อกัน เพื่อให้มีประวัติยาวนานสำหรับไคลเอนต์ที่ไม่เกี่ยวข้องกับสถานะ (เช่น rollups) และสมาร์ทคอนแทร็ก มันแนะนำให้เก็บไว้ตามพฤติกรรมปัจจุบันของโอปเคด BLOCKHASH โดยรักษาข้อจำกัดไว้ที่ 256 บล็อก ในขณะเดียวกัน เพิ่มเข้ามาอีกหนึ่งสัญญาสำหรับเก็บและเรียกคืนแฮชที่ประวัติ สัญญานี้ดำเนินการ set() เมื่อเลเยอร์การประมวลผลบล็อก และมีเมธอด get() ที่สามารถเข้าถึงได้โดยใครก็ได้ เพื่อเรียกคืนแฮชบล็อกที่ต้องการจากแหล่งข้อมูลแบบริงเบอร์

ปัจจุบันเป็นไปได้ที่จะอ้างอิงเฮชบล็อกประวัติศาสตร์ภายใน EVM แต่การเข้าถึงถูกจำกัดเฉพาะกับบล็อก 256 ล่าสุด (~50 นาที) อย่างไรก็ตาม มีกรณีที่การเข้าถึงข้อมูลบล็อกเก่าเป็นสิ่งจำเป็น เช่นสำหรับแอปพลิเคชันที่เชื่อมโยง (ซึ่งต้องการพิสูจน์ข้อมูลจากบล็อกก่อนหน้า) และไคลเอ็นต์ที่ไม่มีสถานะ ซึ่งต้องการเข้าถึงเฮชบล็อกก่อนหน้า

EIP นี้ขยายขอบเขตเวลาที่ใช้ได้สำหรับ rollups และ cross-chain applications โดยให้สามารถเข้าถึงข้อมูลประวัติศาสตร์ได้โดยตรงใน EVM โดยไม่ต้องเก็บรวบรวมจากภายนอก ด้วยเหตุนี้ การแก้ไขเหล่านี้กลายเป็นความแข็งแกร่งและยั่งยืนมากขึ้น

EIP-7623: เพิ่มค่าใช้จ่ายในการดึงข้อมูล

Reference: EIP-7623

ค่าข้อมูลที่ใช้ควบคุมขนาดที่ใช้ได้ของภาระการทำธุรกรรม ซึ่งในบางกรณีอาจมีขนาดใหญ่มาก (เช่น เมื่อส่งอาร์เรย์ขนาดใหญ่หรือบัฟเฟอร์ที่เป็นไบนารีเป็นพารามิเตอร์) การใช้ข้อมูลที่สำคัญเป็นหลักของ rollup ซึ่งส่งภาระทางข้อมูลผ่านข้อมูลที่มีข้อมูลภายใน rollup ปัจจุบัน

ความสามารถในการนำข้อมูลไบนารีขนาดใหญ่ที่สามารถพิสูจน์เข้าสู่บล็อกเชนเป็นสิ่งจำเป็นสำหรับ rollups การอัพเกรด Dencun (Deneb-Cancun) นำเสนอนวัตกรรมสำคัญสำหรับกรณีการใช้งานแบบนี้ - ธุรกรรม blob (EIP-4844) ธุรกรรม blob มีค่าธรรมเนียมแก๊ส "blob" ที่ได้รับการจัดสรรเฉพาะของตนเอง และในขณะที่ร่างกายของพวกเขาถูกเก็บไว้ชั่วขณะ พิสูจน์ทางรัฐบาลของพวกเขา (KZG commitments) รวมถึงเขว่าของพวกเขา ถูกผสานเข้ากับเลเยอร์ความเห็นเชิงสร้างสรรค์ ดังนั้น blobs ให้คำตอบที่ดีกว่าสำหรับ rollups เมื่อเปรียบเทียบกับการใช้ calldata สำหรับการเก็บข้อมูล

การส่งเสริมให้ rollups ย้ายข้อมูลของพวกเขาเป็น blobs สามารถทำได้โดยใช้วิธี “ตอบแทนแบบมีดและกระตุ้น” ค่าธรรมเนียม gas สำหรับ blobs ที่ลดลงใช้เป็น “ตอบแทนแบบมีด” ในขณะที่ EIP นี้เป็น “มีด” โดยเพิ่มค่า calldata ที่มีค่าใช้จ่าย เพื่อป้องกันการเก็บข้อมูลเกินไปในการทำธุรกรรม EIP นี้เสริมเติม EIP-7691 ต่อไป (เพิ่มประสิทธิภาพการส่งข้อมูลของ Blob) ซึ่งเพิ่มจำนวน blobs สูงสุดที่อนุญาตในแต่ละบล็อก

EIP-7691: การเพิ่มประสิทธิภาพในการถ่ายทอด Blob

อ้างอิง: EIP-7691

Blobs ได้รับการแนะนําใน Hard Fork Dencun ก่อนหน้านี้และค่าเริ่มต้นสําหรับจํานวนสูงสุดและเป้าหมายของ blobs "ต่อบล็อก" เป็นการประมาณการแบบอนุรักษ์นิยม นี่เป็นเพราะความซับซ้อนของการทํานายว่าเครือข่าย p2p จะจัดการกับการแพร่กระจายของวัตถุไบนารีขนาดใหญ่ระหว่างโหนดตรวจสอบได้อย่างไร การกําหนดค่าเริ่มต้นได้พิสูจน์แล้วว่าทํางานได้ดีทําให้เป็นเวลาที่เหมาะสมในการทดสอบค่าใหม่ ก่อนหน้านี้เป้าหมาย / จํานวน blobs สูงสุดต่อบล็อกถูกตั้งไว้ที่ 3/6 ขีด จํากัด เหล่านี้กําลังถูกเพิ่มเป็น 6/9 ตามลําดับ

เมื่อผสมกับ EIP-7623 ก่อนหน้านี้ (เพิ่มค่า calldata) การปรับแต่งนี้จะส่งเสริมให้ rollups ย้ายข้อมูลของพวกเขาจาก calldata เป็น blobs ได้อย่างมีเหตุผลมากขึ้น การค้นหาพารามิเตอร์ blob ที่เหมาะสมยังคงดำเนินต่อไป

EIP-7840: เพิ่มกําหนดการ blob ให้กับไฟล์กําหนดค่า EL

Reference: EIP-7840

EIP นี้เสนอให้เพิ่มเป้าหมายและจํานวนสูงสุดของ blobs "ต่อบล็อก" (ที่กล่าวถึงก่อนหน้านี้) และค่า baseFeeUpdateFraction ลงในไฟล์การกําหนดค่า Ethereum Execution Layer (EL) นอกจากนี้ยังช่วยให้ไคลเอนต์สามารถดึงค่าเหล่านี้ผ่านโหนด API คุณลักษณะนี้มีประโยชน์อย่างยิ่งสําหรับงานต่างๆเช่นการประมาณค่าธรรมเนียมก๊าซบล็อบ

EIP-7702: ตั้งโค้ดบัญชี EOA

อ้างอิง: EIP-7702

นี่คือ EIP ที่สำคัญมากที่จะนำมาสู่การเปลี่ยนแปลงที่สำคัญสำหรับผู้ใช้ Ethereum ตามที่เรารู้ว่า EOA (Externally Owned Account) ไม่สามารถมีโค้ดใด ๆ ได้ แต่สามารถให้ลายเซ็นการทำธุรกรรม (tx.origin) ในทางกลับกัน สมารถสมารถมี bytecode แต่ไม่สามารถมีลายเซ็นต์โดยตรง "ของมัน" การกระทำจากผู้ใช้ที่ต้องการตรรกะเพิ่มเติม และตรวจสอบโดยอัตโนมัติ สามารถทำได้เฉพาะโดยการเรียกใช้สัญญาฉลากภายนอกเพื่อดำเนินการที่จำเป็น อย่างไรก็ตามในกรณีเช่นนั้น สัญญาฉลากภายนอกจะกลายเป็น msg.sender สำหรับสัญญาต่อไป ซึ่งทำให้การเรียกใช้ "การเรียกใช้จากสัญญาฉลาก ไม่ใช่ผู้ใช้"

EIP นี้แนะนําประเภทธุรกรรม SET_CODE_TX_TYPE=0x04 ใหม่ (ก่อนหน้านี้เรามีธุรกรรม 0x1 เก่า ธุรกรรม 0x02 ที่ใหม่กว่าจากการอัพเกรดเบอร์ลินและ EIP-1559 และธุรกรรม Blob 0x03 ที่นํามาใช้ใน Dencun) ประเภทธุรกรรมใหม่นี้เปิดใช้งานการตั้งค่ารหัสสําหรับบัญชี EOA โดยพื้นฐานแล้วจะช่วยให้ EOA สามารถรันโค้ดภายนอก "ในบริบทของบัญชี EOA ของตัวเอง" จากมุมมองภายนอกดูเหมือนว่าในระหว่างการทําธุรกรรม EOA "ยืม" รหัสจากสัญญาภายนอกและดําเนินการ ในทางเทคนิคสิ่งนี้เกิดขึ้นได้โดยการเพิ่มข้อมูลการอนุญาตพิเศษลงในที่เก็บข้อมูล "รหัส" ของที่อยู่ EOA (ก่อน EIP นี้ที่เก็บข้อมูล "รหัส" นี้จะว่างเปล่าสําหรับ EOAs เสมอ)

ขณะนี้ EIP นี้เสนอว่าประเภทธุรกรรมใหม่ 0x04 รวมถึงอาร์เรย์

authorization_list = [[chain_id, ที่อยู่, nonce, y_parity, r, s], ...]

โดยที่แต่ละองค์ประกอบอนุญาตให้บัญชีใช้รหัสจากที่อยู่ที่ระบุ (จากรายการการอนุญาตที่ถูกต้องล่าสุด) การประมวลผลธุรกรรมดังกล่าวกําหนดรหัสของ EOA ที่กําหนดเป็น 0xef0100 พิเศษ || ค่าที่อยู่ (23 ไบต์) โดยที่ที่อยู่ชี้ไปที่สัญญาที่มีรหัสที่ต้องการจะดําเนินการ|| หมายถึงการเรียงต่อกันและ 0xef0100 แสดงถึงค่าเวทย์มนตร์พิเศษที่สัญญาอัจฉริยะปกติไม่สามารถมีได้ (ตาม EIP-3541) ค่าเวทย์มนตร์นี้ทําให้มั่นใจได้ว่า EOA นี้ไม่สามารถถือว่าเป็นสัญญาปกติหรือมีการโทรไปเช่นนี้

เมื่อ EOA นี้เริ่มต้นทำธุรกรรม ที่อยู่ที่ระบุจะถูกใช้เรียกโค้ดที่เกี่ยวข้องภายในบริบทของ EOA นั้น ขณะที่รายละเอียดการปฏิบัติงานเต็มรูปแบบของ EIP นี้ยังไม่ทราบ แต่มั่นใจว่ามันจะนำมาซึ่งการเปลี่ยนแปลงที่สำคัญ

หนึ่งในผลกระทบที่สำคัญคือการเปิดใช้งานความสามารถในการทำการโทรหลายครั้งโดยตรงจาก EOA โทรหลายครั้งเป็นแนวโน้มต่อเนื่องใน DeFi โดยมีโปรโตคอลหลายรายการที่มีคุณสมบัตินี้เป็นเครื่องมือที่มีพลัง (ตัวอย่างเช่น Uniswap V4, Balancer V3, หรือ Euler V2) ด้วย EIP นี้ โทรหลายครั้งสามารถทำได้โดยตรงจาก EOA แล้ว

ตัวอย่างเช่นคุณลักษณะใหม่นี้แก้ไขปัญหาที่พบบ่อยใน DeFi: ปัญหาความไม่มีประสิทธิภาพของ approve() + anything() ที่ต้องการธุรกรรมสองรายการที่แยกกัน EIP นี้ช่วยให้เกิดตรรกะ "pre-approval" ที่สามารถทำให้การกระทำเช่น approve(X) + deposit(X) สามารถทำเสร็จสิ้นในธุรกรรมเดียว

ข้อดีอีกอย่างที่แนะนําโดยความสามารถในการมอบหมายการดําเนินการธุรกรรม "ในนามของ" ของ EOA คือแนวคิดของการสนับสนุน สปอนเซอร์มักถูกกล่าวถึงและคุณสมบัติที่ต้องการอย่างมากสําหรับการเตรียมความพร้อมให้กับผู้ใช้ใหม่ไปยัง Ethereum

โลจิกที่สามารถโปรแกรมได้ที่เกี่ยวข้องกับ EOA ปลดล็อกโอกาสมากมาย เช่น การใช้การจำกัดความปลอดภัย การตั้งขีดจำกัดการใช้จ่าย การบังคับข้อกำหนด KYC และอื่น ๆ

โดยธรรมชาติแล้วการเปลี่ยนแปลงนี้ยังทําให้เกิดคําถามด้านการออกแบบมากมาย ปัญหาหนึ่งคือการใช้ chain_id ซึ่งกําหนดว่าลายเซ็นเดียวกันสามารถหรือไม่สามารถใช้งานได้ในหลายเครือข่ายตามการรวมหรือการยกเว้นในลายเซ็น อีกเรื่องที่ซับซ้อนคือการใช้ที่อยู่ของรหัสเป้าหมายเทียบกับการฝังไบต์โค้ดจริงหรือไม่ ทั้งสองวิธีมีคุณสมบัติและข้อ จํากัด ที่เป็นเอกลักษณ์ นอกจากนี้ การใช้ nonce ยังมีบทบาทสําคัญในการกําหนดว่าสิทธิ์เป็น "การใช้งานหลายรายการ" หรือ "การใช้งานครั้งเดียว" องค์ประกอบเหล่านี้มีอิทธิพลต่อคุณสมบัติและข้อกังวลด้านความปลอดภัย รวมถึงแง่มุมต่างๆ เช่น การยกเลิกลายเซ็นจํานวนมากและความสะดวกในการใช้งาน Vitalik ได้ตั้งคําถามเหล่านี้ในการอภิปราย (ที่นี่) ซึ่งควรค่าแก่การสํารวจเพิ่มเติม

สิ่งสําคัญคือต้องทราบว่าการเปลี่ยนแปลงนี้จะส่งผลกระทบต่อหนึ่งในกลไกความปลอดภัยของ Ethereum tx.origin จําเป็นต้องมีรายละเอียดเพิ่มเติมเกี่ยวกับการใช้งาน EIP นี้ แต่ดูเหมือนว่าพฤติกรรมของความต้องการ (tx.origin == msg.sender) จะเปลี่ยนไป การตรวจสอบนี้เป็นวิธีที่น่าเชื่อถือที่สุดเพื่อให้แน่ใจว่า msg.sender เป็น EOA และไม่ใช่สัญญา วิธีการอื่น ๆ เช่นการตรวจสอบ EXTCODESIZE (เพื่อตรวจสอบว่าเป็นสัญญาหรือไม่) มักจะล้มเหลวและสามารถข้ามได้ (เช่นโดยการโทรจากตัวสร้างหรือโดยการปรับใช้รหัสตามที่อยู่ที่กําหนดไว้ล่วงหน้าหลังจากการทําธุรกรรม) การตรวจสอบเหล่านี้ถูกใช้เพื่อป้องกันการโจมตีแบบ reentrancy และ flashloan แต่ยังห่างไกลจากอุดมคติเนื่องจากเป็นอุปสรรคต่อการผสานรวมกับโปรโตคอลภายนอก หลังจาก EIP นี้แม้แต่การตรวจสอบความต้องการที่เชื่อถือได้ (tx.origin == msg.sender) ก็ดูเหมือนจะล้าสมัย โปรโตคอลต้องปรับตัวโดยการลบการตรวจสอบดังกล่าว เนื่องจากความแตกต่างระหว่าง "EOA" และ "สัญญา" จะไม่มีผลบังคับใช้อีกต่อไป — ตอนนี้ทุกที่อยู่อาจมีรหัสที่เกี่ยวข้องได้

EOA แบบดั้งเดิมและการแยกสัญญาอัจฉริยะยังคงเบลอ EIP นี้ทําให้ Ethereum เข้าใกล้การออกแบบเช่น TON มากขึ้นซึ่งทุกบัญชีเป็นรหัสปฏิบัติการเป็นหลัก วิวัฒนาการนี้เป็นธรรมชาติเนื่องจากการโต้ตอบกับโปรโตคอลมีความซับซ้อนมากขึ้นทําให้จําเป็นต้องใช้ตรรกะที่ตั้งโปรแกรมได้เพื่อปรับปรุง UX สําหรับผู้ใช้ปลายทาง

บทสรุป

การอัปเกรด Prague/Electra (Pectra) มีกําหนดในเดือนมีนาคม 2025 การเปลี่ยนแปลงตามแผนที่สําคัญที่สุด ได้แก่ :

• การเสี่ยงของผู้ตรวจสอบตัวแปรที่มีผลเลือกได้ สูงสุด 2048 ETH ซึ่งจะเปลี่ยนแปลงการกระจายเสี่ยงอย่างมีนัยสำคัญ ตารางตรวจสอบ และการบริหารจัดการอย่างง่ายดายสำหรับผู้ให้บริการการจับกุมเสี่ยงที่มีขนาดใหญ่โดยการรวมเสี่ยงที่มีขนาดเล็ก
• ปรับปรุงการปฏิบัติต่อการจับคู่ชั้นทางความเห็น โดยการลดความซับซ้อนในการแลกเปลี่ยนข้อมูลระหว่างบล็อกการดำเนินการ Eth1 และบล็อก Beacon chain ซึ่งจะทำให้ง่ายต่อการฝากเงิน การเปิดใช้งาน การถอนเงิน และการออกจากการเป็นเจ้าของ ทำให้กระบวนการเหล่านี้เร็วขึ้น และเป็นพื้นฐานสำหรับปฏิสัมพันธ์เพิ่มเติมระหว่างชั้นทางความเห็นและชั้นการดำเนินการ
• รองรับการตราประทับลายมือถูกกว่าและการตราประทับลายมือ zkSNARK โดยตรงในสัญญาอัจฉริยะผ่านการเตรียมพร้อมใช้งานใหม่ "pairing-friendly" BLS12-381
• การส่งเสริมให้ rollups ยอมรับการทำธุรกรรม blob แทนการทำธุรกรรม calldata โดยเพิ่มขีดจำกัดของ blob transaction และเพิ่มค่าใช้จ่าย calldata
• การเปิดใช้งาน EOAs เพื่อทำหน้าที่เป็นบัญชีที่สามารถโปรแกรมได้ ทำให้มีคุณสมบัติเช่นการโทรหาหลายคนพร้อมกัน การสนับสนุนผู้สนับสนุนและความสามารถขั้นสูงอื่น ๆ

ตามที่คุณเห็น Pectra จะมีผลกระทบอย่างมากต่อการเพิ่มมูลค่าและชั้นบรรยากาศที่สำคัญ รวมทั้งประสบการณ์ของผู้ใช้ที่ระดับการดำเนินการ ในขณะที่เราไม่สามารถวิเคราะห์รายละเอียดของการเปลี่ยนแปลงทั้งหมดนี้ผ่านรหัส ณ ขั้นตอนนี้ เนื่องจากการพัฒนากำลังดำเนินการ เราจะพูดถึงการอัปเดตเหล่านี้ในบทความอนาคต

ข้อความปฏิเสธความรับผิดชอบ:

1. บทความนี้ถูกคัดลอกมาจาก [เทคโฟลว์]. ส่งต่อชื่อเดิม: The Prague/Electra (Pectra) Hardfork Explained. ลิขสิทธิ์เป็นของผู้เขียนต้นฉบับ [มิกซ์ไบต์]. หากคุณมีข้อขัดแย้งใด ๆ เกี่ยวกับการพิมพ์ซ้ำ โปรดติดต่อ ทีม Gate Learnและทีมงานจะจัดการโดยเร็วที่สุดตามขั้นตอนที่เกี่ยวข้อง
2. คำประกาศ: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงมุมมองส่วนบุคคลของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำใด ๆ เกี่ยวกับการลงทุน
3. เวอร์ชันภาษาอื่น ๆ ของบทความถูกแปลโดยทีม Gate Learn นอกจากนี้ จะระบุไว้เป็นอย่างอื่น บทความที่ถูกแปลอาจจะไม่สามารถคัดลอก แจกจ่าย หรือลอกเลียนในทางอื่น