EIP-2938 ที่เสนอโดย Vitalik จะมีการเปลี่ยนแปลงอะไรบ้างใน Ethereum
หมายเหตุบรรณาธิการ: บทความนี้มาจากCrypto Valley สด (รหัส: cryptovalley)หมายเหตุบรรณาธิการ: บทความนี้มาจาก
Crypto Valley สด (รหัส: cryptovalley)"Crypto Valley สด (รหัส: cryptovalley)", ผู้แต่ง: Rajeev Gopalakrishna, ผู้แปล: Olivia, Odaily ทำซ้ำโดยได้รับอนุญาต
มีบัญชีสองประเภทใน Ethereum บัญชีภายนอกของตัวเอง (EOA) และบัญชีสัญญา (CA) EOA ถูกควบคุมโดยคีย์ส่วนตัว ในขณะที่ CA ถูกควบคุมโดยรหัสสัญญาอัจฉริยะที่อยู่ภายใน EOA ได้รับสิทธิพิเศษมากกว่า CA เสมอ เนื่องจากมีเพียง EOA เท่านั้นที่สามารถเริ่มดำเนินการธุรกรรมโดยการจ่ายน้ำมัน Account Abstraction (AA) เป็นข้อเสนอที่ช่วยให้สัญญาเป็น
ชั้นบนสุด
แรงจูงใจในการแยกบัญชีคือการปรับปรุงประสบการณ์ผู้ใช้อย่างมากเมื่อผู้ใช้โต้ตอบกับ Ethereum ในสถานการณ์ต่างๆ เช่น กระเป๋าเงิน, DApps และ DeFi การแยกบัญชีเป็นฟังก์ชันพื้นฐานใน Ethereum เพื่อตัดสินใจว่าจะจ่ายน้ำมันได้เมื่อใดและให้ใครจ่ายน้ำมัน
แอป Status Messenger รวมระบบส่งข้อความที่เน้นความเป็นส่วนตัว พร้อมด้วยกระเป๋าเงิน Ethereum และเบราว์เซอร์ Web3 DApp ปัจจุบันกระเป๋าเงินสถานะเป็นกระเป๋าเงิน EOA ซึ่งจำกัดเราไม่ให้มอบประสบการณ์การใช้งานที่หลากหลายซึ่งกระเป๋าเงินสัญญาอัจฉริยะเท่านั้นที่ทำได้ เช่น การรักษาความปลอดภัยแบบหลายลายเซ็น การกู้คืนทางสังคม การจำกัดอัตราดอกเบี้ย รายการที่อยู่อนุญาต/ปฏิเสธ และธุรกรรมเมตาที่ปราศจากก๊าซ . ในปัจจุบัน ผู้ใช้กระเป๋าเงินสัญญาอัจฉริยะได้รับผลกระทบจากความผันผวนของค่าธรรมเนียมน้ำมัน และผู้ทำซ้ำบุคคลที่สามไม่สามารถแก้ปัญหานี้ได้อย่างมีประสิทธิภาพ นามธรรมบัญชีมีวัตถุประสงค์เพื่อแก้ปัญหานี้
ในบทความนี้ เรากล่าวถึงความจำเป็นในการแยกบัญชีในบริบทของกระเป๋าเงินสัญญาอัจฉริยะ จากนั้นเราจะลงลึกในประเด็นสำคัญของการสรุปบัญชีโดยอธิบายการเปลี่ยนแปลงโปรโตคอลและผลกระทบต่อโหนด สุดท้าย เราจะหารือเกี่ยวกับข้อเสนอบางอย่างสำหรับการปรับขนาด และสรุปโดยการหาเหตุผลเข้าข้างตนเองของแผนงานที่วางแผนไว้สำหรับโครงการสถานะที่เชื่อมต่อกับ Ethereum ซึ่งอาจได้รับผลกระทบจากการสรุปบัญชี"ชื่อเรื่องรอง"ประวัติและแรงจูงใจ"เดิมเสนอนามธรรมบัญชีในปี 2560 เป็น EIP-86 เพื่อเปิดใช้งาน"
สรุปที่มาของธุรกรรมและลายเซ็น
แต่ที่มาของแนวคิดนี้สามารถย้อนไปถึงปี 2016 ในครั้งนั้นมีผู้เสนอว่า
แทนที่จะมีกลไกในโปรโตคอลที่ใช้ ECDSA และรูปแบบ nonce ที่เป็นค่าเริ่มต้นเป็นวิธี "มาตรฐาน" เพียงวิธีเดียวในการรักษาความปลอดภัยของบัญชี จะเป็นการดีกว่าหากทำตามขั้นตอนเริ่มต้นและสร้างแบบจำลองโดยที่ในระยะยาวบัญชีทั้งหมดเป็นสัญญาและ สัญญาสามารถจ่ายก๊าซได้และผู้ใช้มีอิสระในการกำหนดรูปแบบความปลอดภัยของตนเอง
ข้อเสนอเริ่มต้นถือเป็นความท้าทายเนื่องจากจำเป็นต้องมีการเปลี่ยนแปลงโปรโตคอลจำนวนมากและจำเป็นต้องรับประกันความปลอดภัย เมื่อเร็ว ๆ นี้ Vitalik และคณะได้เสนอร่าง EIP-2938 ซึ่งสรุปแนวทางที่บรรลุผลได้มากขึ้น: โดยลดการเปลี่ยนแปลงโปรโตคอล/ฉันทามติให้น้อยที่สุด และบังคับใช้การรับประกันความปลอดภัยที่จำเป็นผ่านกฎโหนด mempool การนำเสนอ Meetup ของ Ethereum Engineering Group ของ Vitalik และการนำเสนอ ETH Online (และบทความที่เกี่ยวข้อง 1 และ 2) โดย Sam Wilson และ Ansgar Dietrichs (ผู้เขียน EIP อีกสองคน) ให้คำแนะนำโดยละเอียดเพิ่มเติมเกี่ยวกับหัวข้อนี้ บทความนี้เน้นประเด็นสำคัญจากแหล่งข้อมูลเหล่านี้ทั้งหมด
แรงจูงใจ: แรงจูงใจเบื้องหลังการสรุปบัญชีนั้นง่ายมาก แต่เป็นพื้นฐาน: ธุรกรรม Ethereum ในปัจจุบันมีเอฟเฟกต์ที่ตั้งโปรแกรมได้ (ดำเนินการโดยการเรียกใช้สัญญาอัจฉริยะ) แต่จะมีความถูกต้องคงที่เท่านั้น เช่น เฉพาะในกรณีที่มีลายเซ็น ECDSA ที่ถูกต้อง nonce ที่ถูกต้อง และยอดเงินในบัญชีเพียงพอสำหรับการทำธุรกรรม ธุรกรรมที่เป็นนามธรรมจะอัปเกรดธุรกรรมจากความถูกต้องคงที่เป็นความถูกต้องที่ตั้งโปรแกรมได้โดยแนะนำประเภทธุรกรรมการแยกบัญชีใหม่ ประเภทของธุรกรรมที่เป็นนามธรรมของบัญชีนี้จะมาจากที่อยู่พิเศษเสมอ และโปรโตคอลไม่ต้องการลายเซ็น nonce หรือการตรวจสอบยอดคงเหลือ ความถูกต้องของธุรกรรมการตัดบัญชีดังกล่าวถูกกำหนดโดยสัญญาอัจฉริยะเป้าหมาย ซึ่งสามารถบังคับใช้กฎความถูกต้องของมันเอง หลังจากนั้นจะสามารถตัดสินใจชำระเงินสำหรับธุรกรรมดังกล่าวได้
เหตุใดจึงมีประโยชน์ เราใช้กระเป๋าเงิน Ethereum เป็นตัวอย่างเพื่อเน้นให้เห็นประโยชน์ของการแยกบัญชี
กระเป๋าเงินสัญญาอัจฉริยะ: กระเป๋าเงิน Ethereum ส่วนใหญ่ในปัจจุบันคือกระเป๋าเงิน EOA ซึ่งได้รับการรักษาความปลอดภัยโดยคีย์ส่วนตัวที่สร้างจากวลีเริ่มต้น (วลีเมล็ด BIP-39 เป็นรายการลำดับของคำ 12-24 คำที่สุ่มเลือกจาก 2,048 คำ ซึ่งให้เอนโทรปีที่จำเป็นในการรับเมล็ดไบนารี ซึ่งสร้างขึ้นโดยใช้ฟังก์ชัน PBKDF2 จากนั้นเมล็ดไบนารีจะถูกใช้เพื่อสร้าง คู่คีย์อสมมาตรสำหรับกระเป๋าเงิน BIP-32) ผู้ใช้ควรเก็บวลีเริ่มต้นไว้ในที่ปลอดภัย เนื่องจากอาจต้องใช้ในการกู้คืนกุญแจในกระเป๋าเงินอื่นในภายหลัง อย่างไรก็ตาม กระเป๋าเงินดังกล่าวมีความเสี่ยงที่จะถูกขโมยคีย์ส่วนตัวหรือวลีเริ่มต้นที่สูญหาย ทำให้สูญเสียเงินของผู้ใช้
กระเป๋าเงินสัญญาอัจฉริยะถูกนำมาใช้ในเครือข่ายผ่านสัญญาอัจฉริยะ กระเป๋าเงินนี้มอบการลดความเสี่ยงที่ตั้งโปรแกรมได้และประสบการณ์ที่เป็นมิตรต่อผู้ใช้โดยการใช้คุณสมบัติต่างๆ เช่น การรักษาความปลอดภัยแบบหลายลายเซ็น การกู้คืนทางสังคมหรือตามเวลา การจำกัดอัตราการทำธุรกรรมหรือจำนวนเงิน อนุญาต/ปฏิเสธรายการที่อยู่
ในขณะที่กระเป๋าเงินสัญญาอัจฉริยะมีความเสี่ยงด้านความปลอดภัยของสัญญาสมาร์ทที่มีช่องโหว่ ความเสี่ยงนี้สามารถบรรเทาได้ด้วยการทดสอบความปลอดภัยและการตรวจสอบที่ดำเนินการโดยผู้ให้บริการกระเป๋าเงิน ความเสี่ยงของกระเป๋าเงิน EOA อยู่ที่ผู้ใช้กระเป๋าเงินทั้งหมด ซึ่งได้รับความไว้วางใจให้รักษาความปลอดภัยของวลีเริ่มต้นโดยไม่มีขั้นตอนใด ๆ ในสัญญาอัจฉริยะเพื่อรับประกันความปลอดภัย
ตัวอย่างของกระเป๋าเงินสัญญาอัจฉริยะ ได้แก่ Argent, Authereum, Dapper, Dharma, Gnosis Safe, Monolith และ MYKEY ตามแผนภูมิด้านล่าง การยอมรับของกระเป๋าเงินดังกล่าวดูเหมือนจะเพิ่มขึ้น
Argent เปิดใช้งานการกู้คืนทางสังคมแบบไม่ใช้กุญแจผ่านแนวคิดของ Guardians โดยที่ Guardians คือบุคคลหรืออุปกรณ์ที่ผู้ใช้ไว้วางใจให้ช่วยดึงกระเป๋าเงินของพวกเขา Argent ยังตั้งเป้าที่จะบรรลุการผสมผสานระหว่างการรักษาความปลอดภัยแบบธนาคาร (ผ่านคุณสมบัติต่างๆ เช่น การจำกัดการทำธุรกรรมรายวัน การล็อคบัญชี และการติดต่อที่เชื่อถือได้) และความสามารถในการใช้งานแบบ Venmo (โดยใช้ชื่อ ENS แทนที่อยู่และรองรับธุรกรรมเมตา)
Gnosis Safe เป็นกระเป๋าเงินสัญญาอัจฉริยะแบบหลายลายเซ็นที่เน้นการจัดการกองทุนของทีม โดยกำหนดให้สมาชิกในทีมมีจำนวนขั้นต่ำ (m-of-n) เพื่ออนุมัติธุรกรรมที่จะเกิดขึ้น นอกจากนี้ยังเปิดใช้งานลายเซ็นแบบไม่ใช้ก๊าซผ่านธุรกรรมเมตา
คุณสมบัติกระเป๋าเงินขั้นสูงทั้งหมดนี้ต้องใช้สัญญาอัจฉริยะที่มีการสร้างมาอย่างดี ผู้ใช้กระเป๋าเงินจะต้องโต้ตอบกับ EOA หรือพึ่งพาผู้ให้บริการกระเป๋าเงินเพื่อสนับสนุนธุรกรรมเมตาผ่านรีเลย์ของผู้ให้บริการหรือเครือข่ายรีเลย์ของบุคคลที่สาม เช่น เครือข่ายสถานีบริการน้ำมัน แบบแรกพึ่งพาการซื้อ ETH จากการแลกเปลี่ยนแบบรวมศูนย์หลัง KYC ในขณะที่แบบหลังมีเป้าหมายเพื่อลดแรงเสียดทานจากประสบการณ์ของผู้ใช้บนเครือข่ายนี้โดยการเปลี่ยนภาระของผู้ใช้ไปยังรีเลย์ ซึ่งเป็นค่าใช้จ่ายที่ผู้ให้บริการกระเป๋าเงินเป็นผู้รับผิดชอบ on-chain/on - การชดเชยแบบ off-chain และ/หรือ user แบบ off-chain
อย่างไรก็ตาม สถาปัตยกรรมที่ใช้รีเลย์มีข้อเสียที่สำคัญ 3 ประการ: (1) อาจถูกพิจารณาว่าเป็นตัวกลางที่รวมศูนย์ ธุรกรรมที่อาจถูกเซ็นเซอร์ (2) ธุรกรรมเนื่องจากรีเลย์ต้องการค่าธรรมเนียมน้ำมันฐานเพิ่มเติม 21,000 และธุรกิจของพวกเขาจำเป็นต้องทำกำไรนอกเหนือจากค่าธรรมเนียมน้ำมัน ดังนั้นจึงไม่มีประสิทธิภาพทางเทคนิค/ทางเศรษฐกิจ (3) การใช้โปรโตคอลแบบรีเลย์อย่างเดียวบังคับให้แอปพลิเคชันพึ่งพาโครงสร้างพื้นฐาน Ethereum เลเยอร์ที่ไม่ใช่ฐานซึ่งมีฐานผู้ใช้ที่เล็กกว่า ไม่รับประกันความพร้อมใช้งาน
Tornado Cash: แอปพลิเคชันสร้างแรงบันดาลใจที่เกี่ยวข้องคือเครื่องผสมเหรียญ เช่น tornado.cash โดยที่ Tornado ปรับปรุงความเป็นส่วนตัวในการทำธุรกรรมโดยทำลายความสัมพันธ์แบบออนไลน์ระหว่างที่อยู่โดยใช้สัญญาอัจฉริยะที่ยอมรับการฝาก ETH ซึ่งสามารถถอนออกได้ในภายหลังโดยใช้ที่อยู่อื่น ผู้ใช้จะต้องระบุแฮชของความลับเมื่อทำการฝากเงิน และแสดงหลักฐาน zkSnark ในภายหลังเมื่อถอนออกเพื่อแสดงความรู้ของความลับโดยไม่เปิดเผยความลับหรือการฝากเงินก่อนหน้านี้ สิ่งนี้จะแยกการถอนออกจากเงินฝาก
แต่มีปัญหากับการถอนเงิน ในการดำเนินธุรกรรมการถอนเงินจากที่อยู่ที่สร้างขึ้นใหม่ ผู้ใช้จำเป็นต้องมี ETH จำนวนหนึ่งเพื่อชำระค่าน้ำมัน แหล่งที่มาของ ETH นี้ (โดยทั่วไปคือการแลกเปลี่ยน) จะประนีประนอมความเป็นส่วนตัวของ Tornado ทางเลือกที่ต้องการคือการใช้เครือข่ายตัวทำซ้ำอีกครั้ง แต่มีข้อเสียที่อธิบายไว้ก่อนหน้านี้
การถอนบัญชีจะแก้ปัญหานี้ โดยอนุญาตให้สัญญา Tornado ยอมรับธุรกรรมการถอนบัญชีของผู้ใช้ จากนั้นจึงตรวจสอบ zkSnark และหักค่าธรรมเนียมน้ำมันบางส่วน (หักจากจำนวนเงินฝากก่อนหน้า) จากนั้นโอนเงินจำนวนเงินฝากที่เหลือไปยังที่อยู่การถอน
ชื่อเรื่องรอง
การสรุปบัญชีที่เสนอโดย EIP-2938 ช่วยให้สัญญาเป็นบัญชีระดับสูงสุดที่ชำระค่าธรรมเนียมและเริ่มดำเนินการธุรกรรม สิ่งนี้ทำได้โดยการแนะนำการเปลี่ยนแปลงโปรโตคอล ซึ่งเป็นประเภทธุรกรรมการถอนบัญชีใหม่ที่ต้องใช้ opcodes ใหม่สองตัว: NONCE และ PAYGAS การเปลี่ยนแปลงกฎของ mempool และส่วนขยายเพื่อรองรับการใช้งานขั้นสูง ยังคงมีประเภทบัญชีสองประเภท (บัญชี EOA และบัญชีสัญญา) และการเปลี่ยนแปลงที่เสนอทั้งหมดสามารถใช้งานร่วมกับธุรกรรมปัจจุบัน สัญญาอัจฉริยะ และโปรโตคอลย้อนหลังได้
การประยุกต์ใช้การสรุปบัญชีแบ่งออกเป็นสองข้อพิจารณา: 1) แอปพลิเคชันแบบผู้เช่ารายเดียว เช่น กระเป๋าเงินสัญญาอัจฉริยะ สร้างสัญญาใหม่สำหรับผู้ใช้แต่ละคน 2) แอปพลิเคชันแบบหลายผู้เช่า เช่น tornado.cash หรือ Uniswap ผู้ใช้หลายคน และ ชุดเดียวกัน การโต้ตอบสัญญาอัจฉริยะ
การสนับสนุนการสรุปบัญชีสำหรับแอปพลิเคชันแบบหลายผู้เช่าต้องการการวิจัยเพิ่มเติมและแนะนำให้เป็นงานในอนาคต ดังนั้นเราจะมุ่งเน้นไปที่การสนับสนุนของนามธรรมบัญชีผู้เช่ารายเดียวในบทความนี้
ชื่อเรื่องรอง
การเปลี่ยนแปลงโปรโตคอล
มีการแนะนำประเภทธุรกรรมใหม่พร้อมกับ opcodes สองตัวที่รองรับ NONCE และ PAYGAS นี่เป็นเพียงการเปลี่ยนแปลงโปรโตคอลเท่านั้น
ธุรกรรมบทคัดย่อของบัญชี: แนะนำประเภทธุรกรรมบทคัดย่อของบัญชีใหม่ AA_TX_TYPE ประเภทที่มีประสิทธิภาพจะถูกตีความเป็น RLP([ไม่มี เป้าหมาย ข้อมูล]) แทนประเภทธุรกรรมที่มีอยู่ ประเภทที่ถูกต้องสำหรับหลังคือ RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s])
gas_price และ gas_limit ที่ละเว้นในธุรกรรมการตัดบัญชีจะถูกระบุโดยสัญญาการแยกบัญชีเป้าหมายระหว่างการดำเนินการ ลายเซ็น ECDSA v, r, s ละเว้นในธุรกรรมการสรุปบัญชีจะถูกแทนที่ด้วยการตรวจสอบยืนยันข้อมูลโดยสัญญาเฉพาะ ที่อยู่ปลายทางถูกแทนที่ด้วยที่อยู่สัญญาเป้าหมาย เหตุผลที่ไม่ระบุค่านี้เนื่องจากที่อยู่ต้นทางของธุรกรรมนามธรรมของบัญชีทั้งหมดเป็นที่อยู่พิเศษ ENTRY_POINT (0xFFFF...FFF) ไม่ใช่ค่า EOA ที่เชื่อมโยง
หากการตรวจสอบล้มเหลว ธุรกรรมจะถือว่าไม่ถูกต้อง มิฉะนั้น tx.target.nonce จะเพิ่มขึ้นและธุรกรรมจะดำเนินต่อไป
ต้นทุนก๊าซพื้นฐานสำหรับธุรกรรมการถอนบัญชีเสนอเป็น 15,000 แทนที่จะเป็น 21,000 ปัจจุบัน (เพื่อสะท้อนถึงการประหยัดต้นทุนจากการขาดลายเซ็น ECDSA ที่แท้จริง) นอกจากนี้ ธุรกรรมบทคัดย่อของบัญชีไม่มีขีดจำกัดก๊าซที่แท้จริง เมื่อเริ่มต้นการดำเนินการ จำเป็นต้องตั้งค่าขีดจำกัดของก๊าซเป็นก๊าซที่เหลืออยู่สำหรับกลุ่ม
NONCE opcode: NONCE opcode (0x48) ผลัก NONCE ของผู้โทร (นั่นคือสัญญาเป้าหมายที่เป็นนามธรรมของบัญชี) ไปยังกองซ้อน EVM ดังนั้น Nonce จึงเปิดเผยต่อ EVM เพื่ออนุญาตการตรวจสอบลายเซ็นของฟิลด์ธุรกรรมทั้งหมด (รวมถึง nonce) ซึ่งเป็นส่วนหนึ่งของการตรวจสอบในสัญญาการสรุปบัญชี
PAYGAS opcode: PAYGAS opcode (0x49) ดึงพารามิเตอร์สองตัวจากสแต็ก: (บนสุด) version_number, (วินาทีบนสุด) memory_start version_number อนุญาตให้ใช้งานในอนาคตเพื่อเปลี่ยนความหมายของ opcode ปัจจุบันความหมายของ opcode นี้มีดังต่อไปนี้
ตรวจสอบ version_number == 0 (มิฉะนั้นจะส่งข้อยกเว้น)
แยก gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
แยก gas_limit = bytes_to_int (vm.memory[memory_start + 32: memory_start + 64])
ตรวจสอบยอดคงเหลือ >= gas_price * gas_limit (มิฉะนั้นจะมีข้อยกเว้น)
ตรวจสอบ globals.transaction_fee_paid == False (มิฉะนั้นจะยกเว้น)
ตรวจสอบกรอบการดำเนินการ AA == กรอบบนสุด นั่นคือ หากการดำเนินการ EVM ปัจจุบันออกหรือกู้คืน การดำเนินการ EVM ของธุรกรรมทั้งหมดจะถูกยกเลิก (มิฉะนั้น จะเกิดข้อยกเว้น)
กำหนด contract.balance -= gas_price * gas_limit(จำกัด)
ตั้ง globals.transaction_fee_paid = จริง
ตั้ง globals.gas_price = gas_price และ globals.gas_limit = gas_limit
เมื่อสิ้นสุดการดำเนินการของธุรกรรมการถอนบัญชี (globals.gas_limit - left_gas)*globals.gas_price จะถูกโอนไปยังนักขุด และสัญญาการถอนบัญชีจะส่งคืน left_gas * globals.gas_price
PAYGAS ดำเนินการจุดตรวจในฐานะ EVM การย้อนกลับใด ๆ หลังจากจุดนี้จะถูกเปลี่ยนกลับที่นี่เท่านั้น จากนั้นสัญญาจะไม่ยอมรับการคืนเงิน และ globals.gas_limit * globals.gas_price จะถูกโอนไปยังนักขุด
"Mempool "ประเภทธุรกรรมใหม่และ opcodes ใหม่สองรายการประกอบด้วยการเปลี่ยนแปลงระดับโปรโตคอล/ฉันทามติ และความหมายค่อนข้างง่ายที่จะเข้าใจ"ชื่อเรื่องรอง"กฎของเมมพูล"อ้างถึงชุดของโครงสร้างข้อมูลในหน่วยความจำภายในโหนด Ethereum ที่จัดเก็บธุรกรรมของผู้สมัครก่อนการขุด เก็ทเรียกมันว่า"กลุ่มธุรกรรม"; Parity เรียกมันว่า"คิวการทำธุรกรรม"
. โดยไม่คำนึงถึงชื่อ มันเป็นกลุ่มของธุรกรรมที่อยู่ในหน่วยความจำที่รอการรวมไว้ในบล็อก คิดว่าเป็น
พื้นที่คอย
ปัจจุบัน ด้วยกฎความถูกต้องของการทำธุรกรรมแบบตายตัว นักขุดและโหนดอื่น ๆ สามารถตรวจสอบธุรกรรมใน mempool ของพวกเขาได้โดยใช้ความพยายามเพียงเล็กน้อย ดังนั้นจึงหลีกเลี่ยงการโจมตีแบบ DoS ตัวอย่างเช่น หากนักขุดมีลายเซ็น ECDSA ที่ถูกต้อง, nonce ที่ถูกต้อง และมียอดเงินในบัญชีเพียงพอ ก็สามารถมั่นใจได้ว่าการทำธุรกรรมจะจ่ายค่าธรรมเนียมจริง ธุรกรรมอื่นๆ ใน mempool ของนักขุดอาจทำให้ธุรกรรมที่ค้างอยู่นี้ใช้ไม่ได้ ก็ต่อเมื่อธุรกรรมนั้นมาจากที่อยู่เดียวกัน และเพิ่ม nonce หรือลดยอดเงินในบัญชีให้เพียงพอ เงื่อนไขเหล่านี้มีการคำนวณขั้นต่ำเพื่อให้นักขุดและโหนดมีความมั่นใจเพียงพอในเมมพูลของพวกเขาเพื่อดำเนินการรอบล็อกหรือเล่นซ้ำตามลำดับ
Opcode Restriction
ธุรกรรมการถอนบัญชีทำให้เกิดความซับซ้อนเพิ่มเติมด้วยประสิทธิภาพที่ตั้งโปรแกรมได้ การทำธุรกรรมการตัดบัญชีไม่ต้องจ่ายน้ำมันล่วงหน้าและอาศัยสัญญาการตัดบัญชีเป้าหมายเพื่อชำระค่าน้ำมัน (ผ่าน PAYGAS) ตามแนวคิดแล้ว การประมวลผลธุรกรรมที่เป็นนามธรรมของบัญชีจะแบ่งออกเป็นสองขั้นตอน: ระยะการตรวจสอบที่สั้นกว่า (ก่อน PAYGAS) และระยะการดำเนินการที่ยาวขึ้น (หลัง PAYGAS) หากขั้นตอนการตรวจสอบล้มเหลว (หรือเกิดข้อยกเว้น) ธุรกรรมนั้นไม่ถูกต้อง (เช่น ธุรกรรมที่ไม่ใช่บัญชีที่มีลายเซ็นที่ไม่ถูกต้องในปัจจุบัน) จะไม่รวมอยู่ในบล็อก และนักขุดจะไม่ได้รับค่าธรรมเนียม
ชื่อเรื่องรอง
เพื่อป้องกันไม่ให้ความถูกต้องของธุรกรรมการถอนบัญชีขึ้นอยู่กับปัจจัยอื่นใดนอกเหนือจากสัญญาการถอนบัญชีเอง opcodes ต่อไปนี้ถือว่าไม่ถูกต้องในระหว่างขั้นตอนการยืนยัน (เช่น ก่อน PAYGAS: ก่อน PAYGAS): opcodes สภาพแวดล้อม (BLOCKHASH, COINBASE, TIMESTAMP , NUMBER, DIFFICULTY, GASLIMIT), BALANCE (บัญชีใดๆ รวมถึงตัวเป้าหมายเอง), การเรียก/สร้างจากภายนอกหรือคอมไพล์ล่วงหน้าไปยังสิ่งอื่นนอกเหนือจากเป้าหมาย (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) และการเข้าถึงสถานะภายนอกเพื่ออ่านโค้ด ( EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL) เว้นแต่ที่อยู่จะเป็นเป้าหมาย
โหนดควรละทิ้งธุรกรรมการแยกบัญชีที่กำหนดเป้าหมายไปที่สัญญาการแยกบัญชีใน mempool และทำลายกฎข้อจำกัดของ opcode นี้ สิ่งนี้ทำให้แน่ใจว่าธุรกรรมการแยกบัญชีที่ถูกต้องใน mempool จะยังคงใช้ได้ตราบเท่าที่สถานะสัญญาการแยกบัญชีไม่เปลี่ยนแปลง
ชื่อเรื่องรอง
ข้อ จำกัด คำนำหน้า Bytecode
โหนดควรส่งธุรกรรมการสรุปบัญชีไปยังสัญญาการสรุปบัญชีที่ไม่มี AA_PREFIX นี้ในจุดเข้าใช้รหัสไบต์
เมื่อรวมกันแล้ว ข้อจำกัดทั้งสองนี้ที่กำหนดไว้ในสัญญาการตัดบัญชีทำให้มั่นใจได้ว่า (1) สถานะเดียวที่เข้าถึงได้สำหรับตรรกะความถูกต้องของธุรกรรมการตัดบัญชีคือสถานะภายในสัญญาการตัดบัญชี และ (2) สถานะนี้สามารถเข้าถึงได้โดยบุคคลอื่นเท่านั้น การแก้ไขธุรกรรมการตัดบัญชีของสัญญาการตัดบัญชี
ดังนั้น ธุรกรรมการตัดบัญชีที่คงค้างจะถูกยกเลิกหากมีธุรกรรมอื่นที่รอดำเนินการสำหรับสัญญาการตัดบัญชีเดียวกัน อย่างไรก็ตาม เนื่องจากสิ่งเหล่านี้ไม่ใช่การเปลี่ยนแปลงโปรโตคอล/ฉันทามติ นักขุดมีอิสระที่จะรวมธุรกรรมในบล็อกที่ฝ่าฝืนกฎเหล่านี้
ชื่อเรื่องรอง
ขยาย
การเปลี่ยนแปลงโปรโตคอลดังกล่าวและกฎของ mempool ช่วยให้สัญญาการแยกบัญชีขั้นพื้นฐานสามารถใช้งานแอปพลิเคชันแบบผู้เช่ารายเดียวได้อย่างสมบูรณ์และปลอดภัย เช่น กระเป๋าเงินสัญญาอัจฉริยะ การใช้งานขั้นสูงอื่น ๆ ที่จำเป็นต้องผ่อนคลายกฎข้างต้นหรือต้องการใช้แอปพลิเคชันแบบหลายผู้เช่าจำเป็นต้องมีการสรุปบัญชีเพื่อให้การสนับสนุนเพิ่มเติมในรูปแบบของส่วนขยาย เช่น
IS_STATIC opcode ส่งคืนค่าจริงหากบริบทปัจจุบันเป็นแบบคงที่ อนุญาตให้ผู้เรียกธุรกรรมที่ไม่ใช่บัญชีลบแทนที่ข้อจำกัดคำนำหน้า bytecode ก่อนหน้าเพื่ออ่านค่าจากสัญญานามธรรมบัญชีได้อย่างปลอดภัย
RESERVE_GAS opcode ซึ่งเมื่อถูกเรียกจากธุรกรรมที่ไม่ใช่บัญชีที่เป็นนามธรรม สร้างขอบเขตล่างของก๊าซที่ใช้โดยสัญญานามธรรมบัญชีที่ต้องการเขียนถึงสถานะของสัญญา สิ่งนี้บังคับให้ผู้โจมตีไม่ใช้ก๊าซในปริมาณขั้นต่ำเพื่อยับยั้งความพยายามที่จะทำให้ธุรกรรมที่เป็นนามธรรมของบัญชีเป็นโมฆะใน mempool
มีรายการอื่นๆ เช่น ธุรกรรมที่รอดำเนินการหลายรายการ ผลลัพธ์แคชสำหรับการตรวจสอบ ขีดจำกัดของไดนามิกแก๊สสำหรับการตรวจสอบ และธุรกรรมที่ได้รับการสนับสนุน ซึ่งทั้งหมดนี้จำเป็นสำหรับการสนับสนุนแอปพลิเคชันหลายผู้เช่าและการพิสูจน์ zk เช่น Tornado Cash รายละเอียดเกี่ยวกับสิ่งเหล่านี้อยู่นอกเหนือขอบเขตของบทความนี้
ชื่อเรื่องรอง
ขั้นตอนต่อไปของงาน
บัญชี Abstraction EIP-2938 กำลังอยู่ในโหมดร่างและกำลังถูกหารือในฟอรัมการวิจัย Ethereum ขั้นตอนต่อไปสำหรับ EIP คือการพิจารณาเพื่อรวมไว้ในฮาร์ดฟอร์กที่กำลังจะมีขึ้น เป้าหมายของผู้เขียน EIP นั้นชัดเจนว่าเป็นการ hard fork หลังจากเบอร์ลิน (เบอร์ลินมีกำหนดการไม่แน่นอนในช่วงต้นปี 2021) และตารางเวลายังไม่ชัดเจน ยังเร็วเกินไปสำหรับ EIP-2938
สถานะ: ปัจจุบันกระเป๋าเงินสถานะเป็นกระเป๋าเงิน EOA ซึ่งมีความแตกต่างโดยการรวมระบบ SMS ที่เน้นความเป็นส่วนตัวและเปิดใช้งานการผสานรวม เช่น การชำระเงินในการแชท หรือความปลอดภัยขั้นสูงสำหรับคีย์การ์ด คุณสมบัติกระเป๋าเงินสัญญาอัจฉริยะเช่น multi-sig และการกู้คืนโซเชียลกำลังได้รับการพิจารณา และการสนับสนุนสำหรับบัญชีแยก EIP-2938 จะช่วยขจัดการพึ่งพาสถาปัตยกรรมที่ใช้รีเลย์แบบรวมศูนย์และไม่มีประสิทธิภาพตามที่กล่าวไว้ก่อนหน้านี้
สรุป
สถานะกำลังประเมินโซลูชัน L2 เช่นกัน ทั้งเพื่อรองรับ multi-chain ในกระเป๋าเงินและเพื่อให้มาตราส่วนที่จำเป็นสำหรับกรณีการใช้งานต่างๆ ดังที่เราได้กล่าวถึงในโพสต์ก่อนหน้านี้ ตัวอย่างเช่น Keycard กำลังสำรวจเครือข่ายการชำระเงินซึ่งข้อกำหนดด้านการออกแบบสำหรับความสามารถในการปรับขนาดระดับบัตรเครดิตและการสิ้นสุดที่เกือบจะในทันทียังไม่เป็นไปตามข้อกำหนดของเครือข่าย Ethereum นอกจากนี้ยังมีโปรแกรมอื่นๆ อีกมากมาย เช่น โปรแกรมผู้อ้างอิง Tribute-to-Talk และ ENS Names ซึ่งทั้งหมดจะได้รับประโยชน์จากความสามารถในการปรับขยาย L2 สำหรับการปรับใช้ที่ใช้งานได้และประสบการณ์ผู้ใช้ที่สมเหตุสมผล หากโซลูชัน L2 ที่ใช้งานได้ใช้การสรุปบัญชี โครงการที่สร้างขึ้นบน L2 นั้นจะสามารถใช้ประโยชน์จากการสรุปบัญชีโดยไม่ต้องพึ่งพา L1
ชื่อเรื่องรอง
สรุป
ลักษณะพื้นฐานของโปรโตคอล Ethereum คือบัญชีที่เป็นของภายนอก (EOA) เท่านั้นที่สามารถจ่ายค่าธรรมเนียมก๊าซและเริ่มดำเนินการธุรกรรมได้ บัญชีสัญญา (CA) ไม่สามารถทำได้ Account Abstraction (AA) เป็นข้อเสนอเพื่อเปลี่ยนแปลงความแตกต่างนี้ ซึ่งช่วยให้ CA ที่สร้างขึ้นตามวัตถุประสงค์สามารถตรวจสอบความถูกต้องของธุรกรรมการถอนบัญชีใหม่ทางโปรแกรม ตัดสินใจจ่ายค่าธรรมเนียมก๊าซในนามของพวกเขา และด้วยเหตุนี้จึงเริ่มต้นการดำเนินการได้อย่างมีประสิทธิภาพโดยไม่จำเป็นต้องใช้ EOA .
