แนะนำ

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

ประวัติศาสตร์ของการแยกแข่งขัน Ethereum 2.0 'Proof of Stake' เป็นเรื่องที่ซับซ้อน มันเริ่มต้นด้วยการเพิ่มชั้นเครื่องหมายไปยังชั้นการดำเนินการที่มีอยู่แล้ว โดยที่ชั้นเครื่องหมายจะเริ่มต้นเป็นการเชื่อมต่อเครือข่าย Proof of Stake ในขณะเดียวกันชั้นการดำเนินการยังคงใช้ Proof of Work (Phase0 และ Altair hard fork) ต่อมาใน Bellatrix hard fork ทำให้ PoS ถูกเปิดใช้งานเต็มรูปแบบ (แม้ว่าการถอนยังไม่ได้เปิดใช้) จากนั้น Capella hard fork อนุญาตให้ถอนเงินโดยสมบูรณ์แบบ เพื่อให้เสร็จสิ้นวงจรชีวิตของผู้ตรวจสอบ การแยกแข่ง Deneb (ซึ่งเป็นส่วนหนึ่งของการอัปเกรด Deneb/Cancun) ทำการแก้ไขพารามิเตอร์ของโซ่เครื่องหมายเล็กน้อย เช่น หน้าต่างเวลาการพิสูจน์ การจัดการการเลิกบริการด้วยความสมัครใจและการจำกัดการเปลี่ยนผู้ตรวจสอบ การเปลี่ยนแปลงสำคัญใน Dencun เกิดขึ้นที่ชั้นการดำเนินการ โดยนำเสนอการซื้อขาย Blob และก๊าซ Blob KZG สำหรับ Blob และยกเลิกการทำงาน SELFDESTRUCT

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

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

Electra ได้เพิ่มฟังก์ชันหลายอย่างให้กับชั้นบันทึกสัญญาณเสาอ้างอิง การอัปเดตหลักประกอบได้รวมถึง:

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

ในขณะเดียวกัน Prague ได้นำเข้าการเปลี่ยนแปลงต่อการดำเนินงานดังต่อไปนี้：

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

เรามาดูคำเสนอปรับปรุงที่เกี่ยวข้องกับอีเอพี (EIP) กันเถอะ เพื่อที่จะได้พูดคุยต่อ

• EIP - 7251 : MAX เพิ่มขึ้น \ _EFFECTIVE \ _BALANCE
• EIP-7002: การออกจากชั้นดำเนินการที่สามารถเรียกใช้งานได้
• EIP-6110: ที่จัดให้บนเชื่อมต่อผู้ตรวจสอบฝาก
• EIP-7549: นำดัชนีคณะออกจากการพิสูจน์
• EIP-7685: คำขอชั้นการดำเนินการทั่วไป
• EIP-2537: การเตรียมความพร้อมสำหรับการดำเนินการบนเส้นโค้ง BLS12-381
• EIP-2935: ในสถานะเก็บค่าความหมายของบล็อกย้อนหลัง
• EIP-7623: เพิ่มค่าใช้จ่ายของ calldata
• EIP-7691: ประสิทธิภาพการถ่ายโอนข้อมูลขนาดใหญ่เพิ่มขึ้น
• EIP-7840: เพิ่มการกำหนดค่า blob ในไฟล์การกำหนดค่า EL
• EIP-7702: ตั้งค่ารหัสบัญชี EOA

บางส่วนของ EIPs เหล่านี้ส่วนใหญ่เกี่ยวข้องกับเลเยอร์ฉันทามติ (บีคอน) ในขณะที่บางส่วนเกี่ยวข้องกับเลเยอร์การดําเนินการ บางช่วงสองชั้นเนื่องจากการดําเนินการบางอย่างเช่นการฝากและถอนเงินจําเป็นต้องเปลี่ยนพร้อมกันระหว่างชั้นฉันทามติและชั้นการดําเนินการ เนื่องจากการพึ่งพาซึ่งกันและกันนี้จึงไม่สามารถแยก Electra และ Prague ออกจากกันได้ดังนั้นเราจะตรวจสอบ EIP แต่ละรายการตามลําดับและระบุว่าส่วนประกอบ Ethereum ใดที่ได้รับผลกระทบในแต่ละกรณี

# EIP-7251: เพิ่มขึ้น MAX \ _EFFECTIVE \ _BALANCE

อ้างอิง: EIP-7251

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

ยอดเงินที่เหลือที่เปลี่ยนได้นี้จะถูกใช้ในปัจจุบัน:

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

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

อีกปัจจัยหนึ่งที่มีผลต่อการลดลงเกี่ยวข้องกับการลดลง ค่าปรับลดลงทั้งหมดขึ้นอยู่กับยอดคงเหลือที่ถูกต้องของผู้ตรวจสอบ:

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

Electra ยัง提出การเปลี่ยนแปลงอัตราการลดลง นิยามส่วนหนึ่งของยอดคงเหลือของผู้สอบสวนที่ถูกลดลง และได้รับจากผู้รายงาน

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

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

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

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

สรุปได้ดังนี้：

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

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

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

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

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

อ้างอิง: EIP-7002

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

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

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

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

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

การฝากเงินถูกเรียกใช้ในบล็อก Eth1 และเคลื่อนที่ไปยังชั้นสัญญาณรองรับผ่านคิวการฝากเงิน "รอการดำเนินการ" แต่การถอนเงินกลับปฏิบัติตามแผนที่แตกต่างกัน พวกเขาถูกเรียกใช้ในชั้นสัญญาณรองรับ (ผ่าน CLI) และเคลื่อนที่ไปยังบล็อก Eth1 ขณะนี้ สองแผนจะถูกดำเนินการผ่านเฟรมเดียวกัน (เช่นที่อธิบายด้านล่าง) การสร้างคำขอในชั้น Eth1, การประมวลผลคิวการฝากเงิน/ถอนเงิน/รวม และการประมวลผลในชั้นสัญญาณรองรับ สำหรับการดำเนินการ "เอาท์พุต" เช่นการถอนเงิน คิวเอาท์พุตจะถูกประมวลผลและผลลัพธ์จะถูก "ตรวจสอบ" ในบล็อก Eth1

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

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

EIP-6110: การฝากเงินของผู้ตรวจสอบการยืนยันอัตราส่วนในเครือข่าย

อ้างอิง: EIP-6110

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

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

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

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

EIP-7685: ข้อร้องขอชั้นบรรทัดการดำเนินการทั่วไป

อ้างอิง: EIP-7685

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

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

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

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

แม้ว่ารายละเอียดการดำเนินการของกรอบนี้ยังไม่สามารถใช้ได้ แต่มันแน่นอนว่าจะประกอบด้วยประเภทของคำขอที่สำคัญ กลไกความสมบูรณ์ (เช่นการแฮชและการขอคำขอที่มีเมอร์เคิล) และการจัดการคิวที่รอดำเนินการและการจำกัดอัตรา

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

EIP-2537: การพรีคอมไพล์ของการดำเนินการบนเส้นโค้ง BLS12-381

อ้างอิง: EIP-2537

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

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

• การเซ็น BLS ซึ่งใช้การดำเนินการพิเศษที่เรียกว่า "จับคู่" เพื่อยืนยันลายเซ็นดังกล่าว BLS ซึ่งมีการยืนยันที่รวมไปถึงมีการใช้งานอย่างแพร่หลายเนื่องจากทำให้ลายเซ็นหลายรายการรวมเป็นหนึ่ง ผู้ตรวจสอบพึ่งพิจารณาจากลายเซ็น BLS ที่พื้นฐานบนเส้น曲 BLS12-381 (แม้ว่าพวกเขายังสามารถใช้การสร้างคู่ของเส้น曲ใดก็ได้ที่รองรับ รวมถึง BN254) *การตรวจสอบพิสูจน์ zkSNARK ที่ใช้การจับคู่ในการตรวจสอบพิสูจน์ นอกจากนี้การสัญญา KZG ของบล็อกที่ใหญ่ที่ถูกนำเข้าโดย Dencun ในการแยกฟอร์คยังใช้การจับคู่ในการตรวจสอบสัญญาบล็อก

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

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

การยืนยัน zkSNARK ที่ถูกถูกลดราคาจะปลดล็อกการใช้งานมากมาย การยืนยันที่มีความเชื่อถือสูงของค่าใช้จ่ายในปัจจุบันกำลังขัดขวางการใช้งานของหลายๆโครงการทำให้มีการใช้งานเกินความเป็นจริง ความคิด EIP นี้สามารถเปลี่ยนแปลงสถานะนี้

EIP-2935: การเก็บรักษาค่าแฮชบล็อกประวัติในสถานะ

อ้างอิง: EIP-2935

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

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

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

EIP-7623: เพิ่มค่าใช้จ่าย calldata

อ้างอิง: EIP-7623

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

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

การสนับสนุนให้ rollups ย้ายข้อมูลไปยัง blobs สามารถทําได้ในลักษณะแครอทและติด ค่าธรรมเนียมก๊าซ blob ที่ลดลงทําหน้าที่เป็น "แครอท" และ EIP นี้ทําหน้าที่เป็น "เลเวอเรจ" โดยการเพิ่มต้นทุน calldata ซึ่งจะช่วยยับยั้งการจัดเก็บข้อมูลที่มากเกินไปในการทําธุรกรรม EIP นี้เสริม EIP-7691 ถัดไป (Blob Throughput Increase) ซึ่งจะเพิ่มจํานวน blobs สูงสุดที่อนุญาตต่อบล็อก

EIP-7691: การเพิ่มปริมาณการส่งผ่าน blob

อ้างอิง: EIP-7691

ในการ hard fork ก่อนหน้าของ Dencun มีการนำเข้า blob และค่าเริ่มต้นของจำนวน blob 'ต่อบล็อก' ที่มากที่สุดและเป้าหมายเป็นการประมาณอย่างระมัดระวัง นี่เกิดจากความซับซ้อนของวิธีที่เครือข่าย p2p ทำงานกับวัตถุทวิภาคขนาดใหญ่ที่มีการกระจายตัวระหว่างโหนดตรวจสอบ การกำหนดค่าก่อนหน้านี้ได้ยืนยงดีซึ่งทำให้นี้เป็นช่วงเวลาที่เหมาะสมสำหรับการทดสอบค่าใหม่ ในอดีต จำนวน blob ต่อบล็อกเป้าหมาย/สูงสุดถูกตั้งค่าเป็น 3/6 ขณะนี้ขีดจำกัดเหล่านี้ได้ถูกเพิ่มขึ้นเป็น 6/9

การปรับปรุงนี้มีประสิทธิภาพอย่างยิ่งในการสร้างความกระตุ้นให้ rollup ย้ายข้อมูลจาก calldata ไปยัง blobs โดยยิ่งเป็นการหาพารามิเตอร์ blob ที่ดีที่สุด

EIP-7840: เพิ่มการจัดตาราง blob ไปยังไฟล์การกำหนดค่า EL

อ้างอิง: EIP-7840

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

EIP-7702: ตั้งค่ารหัสบัญชี EOA

อ้างอิง: EIP-7702

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

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

ปัจจุบันประเภทธุรกรรม 0x04 ใหม่ที่เสนอโดย EIP นี้มีอาร์เรย์:

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

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

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

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

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

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

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

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

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

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

สรุป

บราก / Electra (Pectra) อัพเกรดที่วางแผนไว้ในเดือนมีนาคม ปี 2025 ซึ่งการเปลี่ยนแปลงที่สำคัญที่สุดคือ

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

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