แบบจำลองสถานะที่อิงบัญชี

ทำความเข้าใจแบบจำลองบัญชีของ Ethereum ผ่านฟิลด์บัญชี รากสถานะและรากพื้นที่จัดเก็บ การประมวลผลธุรกรรมตามลำดับ gas และการย้อนกลับ พื้นที่จัดเก็บโทเค็น การมอบสิทธิ EIP-7702 access list trace และ finality

จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

คำตอบโดยตรง

แบบจำลองที่อิงบัญชีแสดงสถานะการประมวลผลเป็นข้อมูลที่ใช้ที่อยู่เป็นคีย์ ใน execution layer ของ Ethereum leaf ของบัญชีประกอบด้วย [nonce, balance, storageRoot, codeHash] โดย balance ของสินทรัพย์ดั้งเดิมมีหน่วยเป็น wei ข้อมูลสัญญาอยู่ภายใต้ storageRoot ของบัญชีนั้น และ stateRoot หลังประมวลผลของบล็อกผูกมัดกับสถานะรวมของระบบที่เป็นผลลัพธ์ กระเป๋าเงิน ผู้ให้บริการ RPC หรือ block explorer อ่านและตีความสถานะนี้ แต่ไม่ได้เก็บยอดคงเหลือที่เป็นข้อมูลอ้างอิงของเชนแทนผู้ใช้

ยอด ERC-20 วงเงินอนุมัติ หนี้จากการกู้ยืม และหลักประกัน โดยทั่วไปเป็นค่าในพื้นที่จัดเก็บของสัญญา ไม่ใช่ฟิลด์เพิ่มเติมในบัญชีระดับโปรโตคอลของผู้ถือ เช่นเดียวกัน “ธุรกรรมภายใน” ที่ explorer แสดงมักเป็น message call ของ EVM ที่สร้างขึ้นใหม่จาก trace ไม่ใช่ธุรกรรม Ethereum ที่ลงนามแยกต่างหากพร้อม hash ธุรกรรมและ nonce ของผู้ส่งของตนเอง

การแบ่งแบบดั้งเดิมระหว่าง externally owned account (EOA) กับบัญชีสัญญายังมีประโยชน์ แต่ข้อความว่า “EOA มี code ว่างเสมอ” ไม่เป็นจริงโดยไม่มีข้อยกเว้นอีกต่อไปบนเชนที่เปิดใช้ EIP-7702 EOA สามารถมีตัวบ่งชี้การมอบสิทธิ 0xef0100 || address และประมวลผล code ของผู้รับมอบสิทธิ โดยยังคงอำนาจส่งธุรกรรมแบบ EOA ดังนั้นการจำแนกต้องใช้กฎของเชนและ code จริงของบัญชี ไม่ใช่ป้ายกำกับเก่าใน UI

ตรวจสอบการเปลี่ยนสถานะในเจ็ดขั้นตอน

กำหนดจุดสังเกตให้ชัด ได้แก่ เครือข่าย chainId กฎของ fork เลขและ hash ของบล็อก timestamp และแท็กบล็อก เช่น pending latest safe หรือ finalized สถานะใกล้ head อาจเปลี่ยนหลังการจัดระเบียบเชนใหม่ ห้ามรวมข้อเท็จจริงจากคนละบล็อกโดยไม่ระบุ
อ่านฟิลด์บัญชีระดับโปรโตคอล ได้แก่ nonce balance ของสินทรัพย์ดั้งเดิม storageRoot และ codeHash หาก code เป็นตัวบ่งชี้การมอบสิทธิ EIP-7702 ให้หา delegate ตามกฎของ fork นั้น สำหรับ proxy และบัญชีที่มอบสิทธิ ให้แยกตรวจ code ของ implementation อำนาจอัปเกรด และโครงร่างพื้นที่จัดเก็บ
ระบุตำแหน่งยอดของแอปพลิเคชัน ETH เปลี่ยนยอดดั้งเดิม ส่วนยอด ERC-20 มักเปลี่ยน mapping ในพื้นที่จัดเก็บของสัญญาโทเค็น ขณะที่วงเงินอนุมัติ หนี้ หลักประกัน และรางวัลอาจอยู่ในสัญญาและ slots อื่น Decimals ของโทเค็นและ logs ช่วยในการตีความ แต่ไม่ใช่ฟิลด์เพิ่มใน leaf ของบัญชี
ถอดรหัสและตรวจล่วงหน้าธุรกรรมระดับบนสุด ได้แก่ ประเภท ขอบเขตเชน ลายเซ็น nonce ของผู้ส่ง ผู้รับหรือการสร้าง value input ขีดจำกัด gas เพดานค่าธรรมเนียม และ access list หรือ authorization EIP-7702 ที่อาจมี ผู้ส่งต้องมีเงินพอสำหรับ value และภาระค่าธรรมเนียมสูงสุด ธุรกรรมที่ถูกปฏิเสธจะไม่ถูกรวมและไม่ใช้ gas บนเชน
ประมวลผลธุรกรรมตามลำดับในบล็อกจากสถานะก่อนหน้า EVM ประมวลผล message call ที่ซ้อนกันและ frame การสร้างสัญญา ซึ่งแต่ละ frame มี caller callee value calldata gas และสถานะส่งคืนของตนเอง การอ่านและเขียนร่วมกันทำให้ผลลัพธ์ขึ้นกับลำดับ Access list ของ EIP-2930 ทำให้บัญชีและ slots ที่ระบุอยู่ในสถานะ warm ล่วงหน้าและเปลี่ยนการคิด gas แต่ไม่ได้ห้ามการเข้าถึงที่ไม่ได้ประกาศ และไม่ได้พิสูจน์ว่าประมวลผลแบบขนานได้อย่างปลอดภัย
ใช้ขอบเขตการ commit และ rollback Frame ที่สำเร็จจะ commit สถานะและ logs เว้นแต่ parent จะ revert ภายหลัง REVERT ย้อนการเขียน การโอน value และ logs ของ frame ที่ล้มเหลว พร้อมคืน gas ที่ยังไม่ใช้ สัญญาชั้นนอกอาจจับความล้มเหลวของ child call แล้วสำเร็จต่อได้ ความล้มเหลวระดับบนสุดที่ถูกรวมมี receipt status = 0 แต่ nonce ของธุรกรรมผู้ส่งเพิ่มขึ้นและต้องจ่าย gas ที่ใช้ไป การประมวลผล authorization EIP-7702 มีกฎการคงอยู่ของตนเอง แม้การประมวลผลภายหลังจะ revert
กระทบยอด post-state จับคู่การเปลี่ยนยอดดั้งเดิมและโทเค็น การเปลี่ยนพื้นที่จัดเก็บ สถานะ receipt gas ที่ใช้ ราคา gas ที่มีผลจริง logs และ trace ของผู้ให้บริการ กับ root ที่บล็อกผูกมัดไว้ ให้ถือว่า traces เป็นการสร้างมุมมองใหม่ของผู้ให้บริการ ไม่ใช่ธุรกรรมฉันทามติแยกต่างหาก รอ finality ตามที่ต้องการ แล้วจัดการ replacement reorg การแก้ข้อมูลของ indexer bridge rollups และรายการบัญชีกลับรายการอย่างชัดเจน

ตัวอย่างคำนวณสี่กรณี

การโอน ETH ตาม EIP-1559 A เริ่มด้วย 5 ETH และ nonce 12 ส่วน B เริ่มด้วย 1 ETH A ส่ง 1 ETH โดยใช้ 21,000 gas มี base fee 20 gwei priority cap 3 gwei และ max fee 40 gwei ราคา gas ที่มีผลจริงคือ min(40, 20 + 3) = 23 gwei ค่าธรรมเนียมรวมคือ 21,000 × 23 gwei = 0.000483 ETH โดย 0.000420 ETH เป็น base fee ที่ถูกเผา และ 0.000063 ETH เป็น priority fee เงินที่ต้องมีสูงสุดตอนลงนามคือ 1 ETH + 21,000 × 40 gwei = 1.000840 ETH ยอดสุดท้ายของ A คือ 3.999517 ETH ของ B คือ 2 ETH และ nonce ของ A คือ 13
ธุรกรรมที่ถูกรวมแต่ revert A เริ่มด้วย 2 ETH และ nonce 7 A เรียกสัญญาพร้อม 0.50 ETH การประมวลผลระดับบนสุด revert หลังใช้ 80,000 gas ที่ราคาจริง 25 gwei ค่าธรรมเนียมจึงเป็น 80,000 × 25 gwei = 0.002000 ETH การเขียนพื้นที่จัดเก็บของสัญญา logs และการโอน 0.50 ETH ถูกย้อนกลับ ส่วน A เหลือ 1.998000 ETH nonce 8 และ receipt status = 0 ในทางกลับกัน child call ที่ล้มเหลวแต่ A จับไว้ อาจอยู่ร่วมกับ receipt ชั้นนอก status = 1
ยอดโทเค็นอยู่ในพื้นที่จัดเก็บของสัญญา สัญญาโทเค็นบันทึก Alice 1,000 units และ Bob 200 units การโอนสำเร็จ 250 units ทำให้ Alice มี 750 units และ Bob มี 450 units รวมยังเป็น 1,200 units หากธุรกรรมระดับบนสุดของ Alice ใช้ 60,000 gas × 20 gwei = 0.001200 ETH ยอด ETH ดั้งเดิมของเธอจะลดลงแยกต่างหากตามค่าธรรมเนียม storageRoot ของบัญชีโทเค็นและ stateRoot รวมเปลี่ยนไป แต่จำนวนโทเค็นไม่เคยกลายเป็นยอดดั้งเดิมของบัญชี Alice
ขอบเขตการคงอยู่ของ EIP-7702 ผู้สนับสนุนส่งธุรกรรม set-code ที่มี authorization จากบัญชี A ณ nonce 5 เพื่อมอบสิทธิให้ implementation D โปรโตคอลเขียนตัวบ่งชี้ขนาด 23-byte คือ 0xef0100 || 20-byte address และเพิ่ม authority nonce ของ A เป็น 6 หากการประมวลผลภายหลังในธุรกรรมชั้นนอกนั้น revert ตัวบ่งชี้การมอบสิทธิและ authorization nonce ที่ประมวลผลแล้วจะยังคงอยู่ ขอบเขต rollback นี้ไม่เหมือนพื้นที่จัดเก็บ EVM ทั่วไปที่ call ซึ่งล้มเหลวเขียนไว้

ความเสี่ยงและการควบคุม

การอ่านเชน fork hash บล็อก หรือแท็กบล็อกผิด ทำให้ snapshot สถานะไม่สอดคล้องกันภายใน
RPC ที่ล้าสมัยหรือไม่น่าเชื่อถืออาจตกหล่น ล่าช้า หรือรายงานสถานะ head ผิด
การแข่งขัน ช่องว่าง และ replacement ของ pending nonce อาจทำให้สมมติฐานเกี่ยวกับคิวใช้ไม่ได้
“ยกเลิก” ในกระเป๋าเงินมักเป็นธุรกรรม replacement ไม่ใช่การลบระดับโปรโตคอล
ยอดไม่พอสำหรับ value รวมค่าธรรมเนียมสูงสุดทำให้ธุรกรรมไม่ถูกนำเข้าบล็อก
การเปลี่ยน base fee หรือข้อผิดพลาดของ fee cap อาจทำให้ inclusion ล่าช้าหรือเปลี่ยนต้นทุน
Code EIP-7702 อาจทำให้ระบบเก่าจำแนก EOA ผิด
Delegate ที่เป็นอันตราย ข้อบกพร่องการเริ่มต้น หรือ replay authorization อาจทำให้บัญชี EIP-7702 ถูกควบคุม
การอัปเกรด proxy และ delegate calls อาจเปลี่ยนการตีความ code และพื้นที่จัดเก็บเมื่อเวลาผ่านไป
ข้อผิดพลาดของคีย์ ขอบเขตลายเซ็น หรือ chain ID อาจอนุญาตให้ขโมยหรือ replay
Reentrancy และลำดับ shared state อาจเปลี่ยนยอดภายในการประมวลผลเดียว
Child call อาจล้มเหลวและถูกจับไว้ ขณะที่ธุรกรรมชั้นนอกยังรายงานว่าสำเร็จ
Revert ระดับบนสุดหรือ out-of-gas ยังคงใช้ gas และเพิ่ม nonce ของผู้ส่ง
Decimals โทเค็น fee-on-transfer rebasing และ hooks อาจทำให้เลขคณิตยอดอย่างง่ายใช้ไม่ได้
วงเงินอนุมัติ หนี้ หลักประกัน และรางวัลอาจตกหล่นหากกระทบยอดเฉพาะยอดในกระเป๋าเงิน
Logs อาจไม่มี ถูกย้อนกลับ ทำให้เข้าใจผิด หรือไม่พอพิสูจน์สถานะสุดท้าย
“ธุรกรรมภายใน” ของ explorer และ traces ของผู้ให้บริการอาจต่างกันเพราะเป็นมุมมองที่สร้างขึ้นใหม่
Access list อาจไม่ครบ ซ้ำซ้อน หรือไม่คุ้มค่า และไม่ได้ล็อกชุดการอ่านและเขียน
ลำดับ shared state priority fees และ MEV อาจเปลี่ยนผลการประมวลผล
Reorg pruning proofs ที่เข้าถึงไม่ได้ การเปลี่ยนระบบ L2 และ finality ของ bridge อาจย้อนกลับหรือบดบังการบัญชี

ความเข้าใจผิดที่พบบ่อย

“กระเป๋าเงินเก็บยอดบนเชน” กระเป๋าเงินเก็บข้อมูลรับรองและแสดงสถานะที่ได้จากเครือข่าย
“ทุกที่อยู่เป็น EOA ที่ไม่มี code หรือสัญญาทั่วไปอย่างใดอย่างหนึ่งตลอดไป” การมอบสิทธิ EIP-7702 ทำให้เกณฑ์จาก code นี้เปลี่ยนไป
“ทุกการโอนที่แสดงเป็นธุรกรรม Ethereum แยกกัน” Event ของโทเค็นและ trace ของ message call ภายในไม่ใช่ธุรกรรมระดับบนสุดที่ลงนาม
“ธุรกรรมที่ล้มเหลวไม่เปลี่ยนอะไรและไม่มีต้นทุน” ความล้มเหลวที่ถูกรวมอาจใช้ gas และเพิ่ม nonce ของผู้ส่ง
“แบบจำลองบัญชีหรือ access list รับประกันว่าประมวลผลแบบขนานได้เร็วกว่า UTXO” ประสิทธิภาพและข้อขัดแย้งขึ้นกับโปรโตคอลและภาระงานทั้งหมด