บทนำ

In our previous โพสต์ 15เราได้เปิดตัวรุ่น ERC-4337 โมเดลนี้สรุปโครงสร้างตลาดค่าธรรมเนียมสําหรับ bundlers และรายละเอียดฟังก์ชันต้นทุนที่เกี่ยวข้องกับต้นทุนการเผยแพร่แบบ on-chain และ off-chain (ต้นทุนการรวม) ของชุดรวม

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

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

สถานะปัจจุบันของ ERC-4337

ในตลาดปัจจุบัน พูล P2P ไม่ได้ถูกเปิดใช้งานบน mainnet และกำลังทดสอบบนเครือข่ายทดสอบ Sepolia บริษัทที่กำลังสร้างบน ERC-4337 กำลังดำเนินการในโหมดส่วนตัว ผู้ใช้เชื่อมต่อผ่าน RPC ไปยัง bundler ส่วนตัวที่จะทำงานกับ buidler เพื่อเผยแพร่ useroperation บนเครือข่ายแอป Bundle Bear 3โดย Kofi พัฒนาขึ้นมา เพื่อให้ความสนใจในสถิติบางอย่างเกี่ยวกับสถานะปัจจุบันของ ERC-4337

ในWeekly % Multi-UserOp Bundles 1ในมุมมองทางทฤษฎี จะสังเกตเห็นได้ว่า เปอร์เซ็นต์ของผู้รวมสร้าง bundle ที่รวม userops มากกว่า 1 รายการ ตั้งแต่เริ่มต้นของปี 2024 ถึงเดือนมิถุนายน 2024 ไม่เกิน 6.6% ข้อมูลนี้กลายเป็นที่น่าสนใจมากยิ่งขึ้นเมื่อพิจารณาว่า มีการใช้งาน paymasters เป็นของตนเองในผู้รวมสุดยอด 2 ราย ซึ่งเป็นผู้ดำเนินการในด้าน user operations ที่เผยแพร่ออกมาสปอนเซอร์ 97% 1 ของการดําเนินงานของผู้ใช้โดยใช้บริการของพวกเขา paymaster จ่ายสําหรับบางส่วนของการดําเนินการของผู้ใช้และส่วนที่เหลือจะจ่ายโดย dapps หรืออื่น ๆ entity 1.

คําถามที่เกิดขึ้นคือทําไม paymasters, dApps ฯลฯ จึงจ่ายเงินสําหรับการดําเนินงานของผู้ใช้ ผู้ใช้จะจ่ายเงินคืนในอนาคตหรือไม่? เราไม่สามารถแน่ใจได้ว่าจะเกิดอะไรขึ้น แต่การคาดเดาส่วนตัวของฉันคือปัจจุบัน dApps ครอบคลุมค่าธรรมเนียมเพื่อเพิ่มการใช้งานและการยอมรับแอพของพวกเขา เมื่อการยอมรับสูงผู้ใช้อาจต้องจ่ายเงินสําหรับการทําธุรกรรมด้วยตนเอง เป็นมูลค่าการกล่าวขวัญว่าสําหรับผู้ใช้ที่จะจ่ายสําหรับการดําเนินงานของผู้ใช้ด้วยรุ่นปัจจุบันไม่ใช่ตัวเลือกที่ดีที่สุดเนื่องจากการดําเนินการ ERC-4337 ขั้นพื้นฐานมีค่าใช้จ่าย ~ 42,000 ก๊าซในขณะที่การทําธุรกรรมปกติมีค่าใช้จ่าย ~ 21,000 ก๊าซ

รูปแบบที่แตกต่างของ ERC-4337

ภาพรวมของ ERC-4337

Mempool ยังคงอยู่ในช่วงทดสอบใน Sepolia และยังไม่มีการใช้งานจริงบน mainnet โดยไม่มี mempool ผู้ใช้จะมีตัวเลือกที่จำกัดในการใช้ account abstraction ผู้ใช้จะติดต่อกับ RPC ซึ่งอาจถูกนำเสนอโดย bundler ที่รวม UserOps หรือกับบริการ RPC ที่ไม่รวม คล้ายกับบริการเช่น Alchemy หรือ Infura ซึ่งรับและ propaGate ธุรกรรมไปยัง bundler อื่นๆ

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

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

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

Bundlers และ builders เป็นสองหน่วยงานที่แตกต่างกัน

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

การใช้ mempool ที่ userops เป็นสาธารณะกับ bundlers ที่แตกต่างกัน เพิ่มความแข่งขัน ในกรณีของ non native account abstraction การมีการแยกแยะระหว่าง bundler และ builder เป็นสิ่งที่จำเป็น ในกรณีของ native account abstraction การแยกแยะอาจไม่จำเป็นเนื่องจาก builder สามารถตีความ userops เป็นธุรกรรมปกติ

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

RIP-7560

นโยบายบัญชี Native ไม่ใช่แนวคิดใหม่; มันอยู่ภายใต้การวิจัยมาหลายปีแล้ว ในขณะที่ ERC-4337 กำลังได้รับความสนใจ การนำมาใช้นอกโปรโตคอลนั้นมีข้อได้เปรียบที่แตกต่างกันพร้อมกับการแลกเปลี่ยนข้อมูล โดยโดยเฉพาะอย่างยิ่ง บัญชี EOAs ที่มีอยู่ไม่สามารถเปลี่ยนสลับไปใช้กับ SCWs ได้อย่างราบรื่นและการใช้รายชื่อแบบต้านการเซ็นเซอร์ชั่วคราวต่างๆ ยากขึ้น อย่างที่กล่าวมาแล้ว ค่าใช้จ่ายในการดำเนินการ userOp เพิ่มขึ้นอย่างมีนัยสำคัญเมื่อเทียบกับธุรกรรมปกติRIP-7560 2won’t inherently resolve the ongoing issue concerning off-chain costs, but it substantially reduce transaction expenses. From the initial ~42000 gas, it’s possible to reduce the cost by ~20000 gas.

Layer2s Account Abstraction

การสรุปบัญชีสามารถใช้ในการแก้ปัญหาชั้นที่ 2 (L2) บางส่วน L2s ได้ใช้งานอยู่แล้วในรูปแบบธรรมชาติ ในขณะที่อื่น ๆ ทำตามวิธีการ L1 และกำลังรอข้อเสนอใหม่ที่คล้ายกับ RIP-7560 ใน L2 L1 ใช้สำหรับการให้ข้อมูลสำหรับรับรองความปลอดภัยในขณะที่เกิดการคำนวณใน L2 ได้เกิดขึ้นนอกเหนือจากเครือข่ายบน L2 ซึ่งทำให้การทำธุรกรรมเป็นราคาถูกและมีความยืดหยุ่นสูงขึ้น

ในสถานการณ์ที่การคำนวณบน L2 ถูกกว่าค่า calldata สำหรับการใช้งานข้อมูลที่พร้อมใช้งาน (DA) บน mainchain การใช้งานการรวบรวมลายมือเป็นประโยชน์อย่างมาก ตัวอย่างเช่น การจับคู่สำหรับ BLS บน mainnet ถูกให้บริการโดย0x08 1precompile จาก EVM ซึ่งมีค่าใช้จ่ายประมาณ ~45000k gas ด้วยเหตุนี้การใช้ BLS บน L1 จะมีค่าใช้จ่ายมากกว่าธุรกรรมแบบดั้งเดิม

เทคนิคการบีบอัดบน L2 ได้ถูกนำมาใช้แล้ว เช่น การบีบอัด 0 ไบต์ ซึ่งลดต้นทุนจาก ~188 ไบต์ เหลือ ~154 ไบต์ สำหรับการโอนเหรียญ ERC20 ด้วยการรวมลายเซ็นต์ เราสามารถเพิ่มประสิทธิภาพการบีบอัดได้อีกโดยใช้ลายเซ็นเดียว ลดขนาดไปเหลือ ~128 ไบต์

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

Signature Aggregation economics in Layer2s

เมื่อใช้บริการ L2 ผู้ใช้ต้องเสียค่าใช้จ่ายหลายรายการรวมถึงค่าธรรมเนียมสำหรับผู้ดำเนินการ L2 ค่าใช้จ่ายที่ขึ้นอยู่กับการติดขอบเขตของเครือข่ายและค่าใช้จ่ายสำหรับความพร้อมใช้ข้อมูลบน L1

จากการวิจัยก่อนหน้าเข้าใจเศรษฐศาสตร์ของ rollup จากหลักการเบื้องต้นเราสามารถกำหนดค่าใช้จ่ายที่ผู้ใช้ต้องเผชิญเจอเมื่อใช้บริการ L2 ได้ดังนี้:

เมื่อผู้ใช้ interatcs กับเลเยอร์ 2 เขามีค่าใช้จ่ายบางอย่างที่เราสามารถกําหนดได้ดังนี้:

• ค่าธรรมเนียมผู้ใช้ = ค่าเผยแพร่ข้อมูล L1 + ค่าผู้ดำเนินการ L2 + ค่าเสียหน้า L2
• ค่าดำเนินการของผู้ให้บริการ = ค่าดำเนินการของตัวดำเนินการ L2 + ค่าการเผยแพร่ข้อมูล L1
• รายได้จากผู้ประกอบการ = ค่าธรรมเนียมของผู้ใช้ + MEV
• กำไรของผู้ประกอบการ = รายได้ของผู้ประกอบการ - ต้นทุนของผู้ประกอบการ = ค่าธุรกิจ L2 + MEV

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

เมื่อพิจารณาถึงช่องรวม ค่าใช้จ่ายและกำไรถูกขยายออกไปตามต่อไปนี้:

• ค่าธรรมเนียมผู้ใช้ = ค่าการตีพิมพ์ข้อมูล L1 + ค่าผู้ดำเนินการ L2 + ค่าการแออัด L2 + ค่าผู้รวม
• ค่า Bundler = Quoted(L1 ค่าธรรมเนียมการเผยแพร่ข้อมูล + L2 ค่าธรรมเนียมของผู้ดำเนินการ + L2 ค่าธรรมเนียมการแอคเคิล)
• รายได้จากการรวม = ค่าธรรมเนียมของผู้ใช้
• กำไรจากการรวม = รายได้จากการรวม - ต้นทุนจากการรวม = ความแตกต่างระหว่างต้นทุนระดับ L1 และ L2 และราคาที่เสนอจากผู้รวม + ค่าธรรมเนียมจากผู้รวม
• ค่าใช้จ่ายของผู้ประกอบการ = ค่าจ่ายการเผยแพร่ข้อมูล L1 + ค่าธรรมเนียมของผู้ประกอบการ L2
• กำไรของผู้ประกอบการ = รายได้ของผู้ประกอบการ - ต้นทุนของผู้ประกอบการ = ค่าการแอบดีของ L2 + MEV

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

การจัดการให้สอดคล้องกันของสิ่งต่าง ๆ ใน L2

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

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

ค่าใช้จ่ายที่เกี่ยวข้องกับการสร้างแบบจัดกลุ่มและเผยแพร่บนเชื่อมโยงสามารถแบ่งออกเป็นสองส่วน:

ฟังก์ชันต้นทุนโซ่บน: แบร์เดิลเอาต์พร้อมกับการเรียกเก็บเงินเมื่อค่าฐาน r ใช้ค่าใช้จ่าย:

ฟังก์ชันต้นทุนที่รวมกัน: ผู้รวมแบนเดิลมีฟังก์ชันต้นทุนสำหรับรวม n ธุรกรรมในชุดเดียวกัน B โดยมีค่าฐานของค่าฟี้เริ่มต้น r:

ด้วย S′F ซึ่งมีสิ่งพิมพ์และการตรวจสอบลายเซ็น aggreGated แบบ on-chain เดียว

หากผู้ใช้สามารถรับค่าประมาณที่เชื่อถือได้สําหรับ n พวกเขาสามารถคํานวณต้นทุนโดยใช้ฟังก์ชัน estimateGas ซึ่งมีอยู่ในโซลูชัน L2 ส่วนใหญ่ การประมาณค่าที่ดีสามารถทําให้ผู้ใช้เสนอราคาตามนั้นได้โดยไม่ต้องประเมินราคาเสนอสูงเกินไปเพื่อรวมไว้ ฟังก์ชันนี้กําหนดค่าใช้จ่ายที่จําเป็นเพื่อให้แน่ใจว่ามีการรวม การมีการประมาณการที่ดีสําหรับ n และฟังก์ชัน estimateGas สามารถหลีกเลี่ยงผู้ใช้ที่จะจ่ายเงินสําหรับ preVerificationGas ที่สูงขึ้น ในส่วนถัดไปเราจะสํารวจกลไกต่างๆเพื่อให้แน่ใจว่าการประมาณการที่เชื่อถือได้ของ n

Layer2s ดำเนินการออรัคเคิล

บทบาทของออราเคิลคือการตรวจสอบ mempool และประมาณจํานวนธุรกรรมที่มีอยู่ กระบวนการทํางานดังนี้: เลเยอร์ 2 ปรับใช้ oracle เพื่อตรวจสอบ mempool แล้วแจ้งให้ผู้ใช้ทราบเกี่ยวกับจํานวนธุรกรรมใน mempool สิ่งนี้ทําให้ผู้ใช้สามารถประเมินราคาเสนอเพื่อรวมไว้ในกลุ่มได้ เลเยอร์ 2 สามารถขอให้บันเดิลรวมธุรกรรมอย่างน้อยตามจํานวนที่ระบุ (n) ในชุดรวม มิฉะนั้นบันเดิลจะถูกปฏิเสธ เมื่อ bundler รวบรวมธุรกรรมเพียงพอที่จะสร้างกลุ่มมันจะส่งบันเดิลไปยังเลเยอร์ 2 ซึ่งจะส่งต่อไปยัง mainnet เป็น calldata สําหรับความพร้อมใช้งานของข้อมูล

Watcher proposal691×642 47.4 KB

Layer2s ที่มีตัวควบคุมที่ใช้ร่วมกัน

วิธีการที่น่าสนใจคือการมีเครือข่าย Layer 2 (L2) หลายระดับที่ทำงานร่วมกันผ่านตัวจัดเรียงร่วมกัน การตั้งค่านี้สามารถให้ประเมินค่าที่แม่นยำขึ้นของ mempool เนื่องจากตัวจัดเรียงร่วมกันได้เห็นความเห็นด้วยการทำสรรพสิ่ง ที่ได้รับการสนับสนุนโดยตัวจัดเรียงร่วมกัน

ในการกำหนดค่านี้เครือข่าย L2 ที่แตกต่างกันทำงานอย่างอิสระ แต่มีตัวควบคุมร่วมกัน เป็นประจำเครือข่ายเหล่านี้จะตรวจสอบจำนวนของการดำเนินการของผู้ใช้ (userops) ใน shared mempool เมื่อเครือข่ายเหล่านี้เห็นด้วยกันข้อมูลจะถูกส่งต่อไปยังผู้ใช้ ให้เขาเสนอราคาโดยอิงตามจำนวน userops ที่มีอยู่

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

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

Sequencer ที่ใช้ร่วมกัน 764×785 66.3 KB

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

n

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

Layer2s ดำเนินการเป็นธนาคารของตนเอง

ในข้อเสนอนี้เลเยอร์ 2 จะถือว่าบทบาทของ bundler ในขณะที่เอนทิตีอื่นจัดการการรวมลายเซ็น (อาจเป็นบริการ bundler ปัจจุบัน) กระบวนการทํางานดังนี้: เลเยอร์ 2 ดําเนินการ bundler ของตัวเองและผู้ใช้ส่งการดําเนินการ (userops) ไปยัง mempool เลเยอร์ 2 เลือก userops เหล่านี้บางส่วนจาก mempool และส่งพวกเขา "ดิบ" ไปยังผู้รวบรวมชดเชยผู้รวบรวมสําหรับการรวมลายเซ็น เมื่อผู้รวบรวมสร้างบันเดิลแล้วจะส่งไปยัง bundler ซึ่งจะส่งต่อไปยัง mainnet เป็น calldata สําหรับความพร้อมใช้งานของข้อมูล

ความคิดหลักคือ Layer 2 จัดการรวบรวม userops แล้วนำการรวบรวมไปให้กับหน่วยงานอื่น ๆ Layer 2 จ่ายค่ารวบรวมและคิดค่าบริการผู้ใช้

มีตัวเลือกสองแบบที่แตกต่างกัน:

1. โครงแบบค่าธรรมเนียมแบบค่าคงที่: ผู้จัดชุด (Sequencer) เลือกบางธุรกรรมและคิดค่าใช้จ่ายแบบค่าคงที่ให้กับผู้ใช้ ค่าธรรมเนียมแบบนี้ถูกคำนวณในลักษณะเดียวกับธุรกรรม Layer 2 ปัจจุบัน โดยการทำนายค่าใช้จ่ายในอนาคตของการเผยแพร่ข้อมูล L1 อย่างอื่น หรือ Layer 2 อาจคิดค่าธรรมเนียมแบบค่าคงที่ให้กับผู้ใช้โดยขึ้นอยู่กับค่าใช้จ่ายในการจัดชุด n
2. การรวมผู้ใช้ ops ชั้น 2 ยังต้องการทำนายว่าจะมีการทำธุรกรรมกี่รายการในกลุ่มที่เขาจะสร้างเพื่อเสนอราคาถูกต้องแก่ผู้ใช้ สิ่งนี้สามารถทำได้ในทางเดียวกันกับที่เป็นอยู่ในปัจจุบันที่ . ในปัจจุบันที่ l2 คิดค่าใช้จ่ายที่ดีที่สุดสำหรับผู้ใช้ที่มันเป็นประโยชน์ที่สุดสำหรับชั้น 2 ที่เก็บราคาให้ผู้ใช้เป็นไปตามการแข่งขันให้เท่าที่จะเป็นไปได้
   
3. ค่าธรรมเนียมคงที่ 671×702 22.1 KB
4. การขอเงินคืน: หากเลเยอร์ 2 ต้องการเพิ่มความน่าเชื่อถือ ก็สามารถเปิดใช้งานการคืนเงินอัตโนมัติได้ สิ่งนี้จะเกี่ยวข้องกับกลไกที่ตรวจสอบจํานวน userops ที่เผยแพร่ในบล็อกเดียวและธุรกรรมอาจถูกรวมเข้าด้วยกันหรือไม่ หากผู้ใช้ที่อาจถูก aggreGated ไม่ได้และไม่มีการคืนเงินอัตโนมัติผู้ใช้สามารถขอเงินคืนได้ ในสถานการณ์สมมตินี้ เลเยอร์ 2 อาจเดิมพันสินทรัพย์บางอย่าง และหากไม่มีการคืนเงิน ผู้ใช้สามารถบังคับใช้การคืนเงิน เพื่อให้มั่นใจถึงความเป็นธรรมและความรับผิดชอบ
   
5. ขอคืนเงิน 671×702 22.8 KB

สรุป

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

ในส่วนที่สองเราอธิบาย ERC-4337 และ RIP-7560 จากนั้นเราได้พูดคุยกันว่าเหตุใดการรวมลายเซ็นจึงมีแนวโน้มที่จะเกิดขึ้นในโซลูชันเลเยอร์ 2 มากกว่าในเลเยอร์ 1 โดยตรง เราแสดงให้เห็นว่าโซลูชันเลเยอร์ 2 สามารถจัดการกับความรู้ที่ไม่สมมาตรที่ผู้ใช้ประสบในรูปแบบต่างๆ ได้อย่างไร ประการแรกคือการใช้ oracles เพื่อส่งสัญญาณให้ผู้ใช้ทราบว่ามีธุรกรรมกี่รายการใน mempool ด้วยวิธีการนี้ผู้ใช้รู้ว่าพวกเขาควรเสนอราคาเท่าใดและสามารถบังคับให้ bundler สร้างกลุ่มที่ใหญ่ขึ้นได้ วิธีที่สามซึ่งง่ายที่สุดคือ L2 ทําหน้าที่เป็น bundler และ outsources การรวมไปยังบุคคลที่สามและให้ผู้ใช้จ่ายค่าธรรมเนียมสําหรับมัน

ประกาศจาก Gate.io：

1. บทความนี้ถูกนำเข้ามาจาก [ ethresear], ส่งต่อชื่อเรื่องต้นฉบับ 'Embedded fee markets and ERC-4337 (part 2)' ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [ DavideRezzoli & Barnabé Monnot]. หากมีคำปฏิเสธในการเผยแพร่นี้ กรุณาติดต่อ Gate Learn ทีมและพวกเขาจะจัดการกับมันทันที

2. คำประกาศความรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงมุมมองของผู้เขียนเท่านั้น และไม่มีการให้การแนะนำใด ๆ เกี่ยวกับการลงทุน

3. การแปลบทความเป็นภาษาอื่น ๆ โดยทีมงาน Gate Learn ถูกทำการ ยกเว้นการกล่าวถึง การคัดลอก การกระจาย หรือการลอกเลียนแบบบทความที่แปล