กลไกค่าธรรมเนียมการทําธุรกรรมได้กลายเป็นแบบจําลองม้างานเพื่อทําความเข้าใจตัวกลางของผู้ผลิตบล็อกระหว่างผู้ใช้ที่ต้องการทําธุรกรรมและ "ห่วงโซ่" (หรือ "โปรโตคอล") ที่ผู้ใช้ทําธุรกรรม เมื่อพิจารณาถึงความสามารถในการใช้อุปทานบางส่วนที่จัดทําโดยห่วงโซ่ผู้ผลิตบล็อกจะต้องตัดสินว่าผู้ใช้รายใดจะมีความสามารถในการใช้ทรัพยากรที่หายากของการดําเนินการแบบ on-chain และมีค่าใช้จ่ายเท่าใด ใน Ethereum สําหรับคําถามเรื่องต้นทุนผู้ผลิตบล็อกจะถูก จํากัด โดยกลไกค่าธรรมเนียม EIP-1559 ซึ่งกําหนดราคาสํารองแบบบล็อกต่อบล็อกแบบไดนามิกที่เรียกว่า "ค่าธรรมเนียมพื้นฐาน" ค่าธรรมเนียมพื้นฐานคือราคาที่แสดงต่อหน่วยของก๊าซซึ่งธุรกรรมของผู้ใช้จะต้องจ่ายเพื่อรวมและดําเนินการ ผู้ใช้อาจให้สิ่งที่เรียกว่า "ค่าธรรมเนียมลําดับความสําคัญ" นอกเหนือจากค่าธรรมเนียมพื้นฐานเพื่อจูงใจผู้ผลิตบล็อกในยามแออัด

ในบันทึกฉบับนี้ เราสืบสวดคำถามเกี่ยวกับตลาดค่าธรรมเนียมที่ฝังอยู่ภายในตลาดค่าธรรมเนียมอื่น ๆ นั่นคือ ตลาดค่าธรรมเนียมที่ “อาศัย” อยู่ในตลาดค่าธรรมเนียมอื่น คำถามนี้ได้รับการสนทนาในบทความล่าสุดโดย Maryam Bahrani, Pranav Garimidi และ Tim Roughgarden ในบทความที่มีบทสนทนาที่แตกต่างการออกแบบกลไกค่าธรรมเนียมธุรกรรมในโลกหลัง MEV 9”. ในบทความนี้ผู้เขียนจําลองการใช้ผู้ค้นหาซึ่งเป็นตัวกลางในการเข้าถึงห่วงโซ่ระหว่างผู้ใช้และผู้ผลิตบล็อก ผู้ผลิตบล็อกได้รับ "คําใบ้" จากผู้ค้นหาซึ่งรวบรวมโดยการรวมกลุ่มอะตอมของธุรกรรมที่จะรวมโดยห่วงโซ่ ตลาดค่าธรรมเนียมของผู้ค้นหาได้รับแรงหนุนจากวัตถุประสงค์การเพิ่มปริมาณสูงสุดที่เรียกว่า MEV หรือมูลค่าสูงสุดที่สกัดได้

ในการตั้งค่าของเราผู้ใช้ต้องการเข้าถึงเชน แต่ไม่แสดงความต้องการของพวกเขาโดยใช้ธุรกรรมที่เป็นไปตามโปรโตคอล แทนที่จะทำเช่นนั้นผู้ใช้จะสร้าง "การดำเนินการ" เพื่อรวมกันโดยหน่วยงานที่รู้จักว่า "bundlers" ซึ่งจากนั้นก็กำเนิดธุรกรรมที่เป็นไปตามโปรโตคอลที่รวมการดำเนินการด้วยกันเพื่อดำเนินการ ดังนั้นต่อกลไกค่าธรรมเนียม EIP-1559 bundlers เป็นผู้ใช้เชน แต่ผู้ใช้จริงจะต้องได้รับการรวมอยู่ในกองที่เป็นของ bundler ก่อนที่พวกเขาจะสามารถได้รับการรวมในเชน กล่าวอีกนัยหนึ่งเราอาจเห็นการตั้งค่านี้เป็นส่วนหนึ่งของคำถามที่ใหญ่กว่าของการสร้างบล็อกร่วมกัน, ซึ่งเกิดขึ้นกับ (บางส่วน) ผู้สร้าง/ผู้ค้นหาและรายการการรวม

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

ในการลงทุนความแตกต่างระหว่างตลาดค่าธรรมเนียมโดยตรงและกลไกที่ฝังตัว (ย่อย) เราต้องกําหนดข้อ จํากัด ทางเศรษฐกิจที่ผู้รวมกลุ่มปฏิบัติตาม ในส่วนต่อไปนี้เราขอเสนอรูปแบบง่ายๆของฟังก์ชันต้นทุน bundler ที่ได้รับแรงบันดาลใจจากการปฏิบัติโดยเฉพาะอย่างยิ่ง bundlers ที่เข้าร่วมในโปรโตคอล ERC-4337 ซึ่งเราสรุปสั้น ๆ

โมเดล

การรวมกลุ่มใน ERC-4337

ผู้ใช้ที่ต้องการทํากิจกรรมบางอย่างแบบ on-chain ผ่าน bundlers จะออกการดําเนินการของผู้ใช้ (UserOp หรือการดําเนินการ) UserOp นี้ถูกปล่อยออกมาจากกระเป๋าเงินของผู้ใช้เช่นหลังจากโต้ตอบกับ DApp เมื่อ UserOp ออกอากาศแล้ว bundler บางคนที่ได้รับการดําเนินการอาจตัดสินใจที่จะรวมไว้ในชุด บันเดิลคือธุรกรรมเมตา "บัญชีที่เป็นเจ้าของภายนอก" (EOA) ซึ่งเขียนข้อมูลของ UserOps ที่รวมอยู่ในฟิลด์ bundle.calldata bundler ออกชุดรวมเพื่อรวมไว้ในบล็อกโดยผู้ผลิตบล็อก (เราพูดถึงความสัมพันธ์ระหว่าง bundler และ block producer ในบันทึกในอนาคต)

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

• การตรวจสอบก่อน: ธุรกรรม EOA ของผู้รวบรวมจะใช้ gas 21,000 และการเรียก contract ของ EntryPoint จะตั้งค่าตัวแปรสำคัญเพื่อติดตามการดำเนินการในลูปการดำเนินการ
• การดำเนินการวงจร 3: สำหรับทุก ๆ การดำเนินการที่รวมอยู่ในชุด จะมีขั้นตอนทั้งสองตามนี้เกิดขึ้น:
  • ขั้นตอนการยืนยัน: UserOps ดําเนินการที่มีขั้นตอนการยืนยันซึ่งเข้ารหัสใน "กระเป๋าเงินสัญญาอัจฉริยะ" ที่ปรับใช้โดยผู้ใช้ในตอนแรก (ระหว่าง UserOp เริ่มต้น) ขั้นตอนการตรวจสอบอาจเพียงแค่ตรวจสอบลายเซ็นหรือดําเนินการที่ซับซ้อนมากขึ้นเพื่อ "ให้" สิทธิ์แก่ UserOp ในการดําเนินการต่อไป ขั้นตอนการตรวจสอบจะถูกวัดโดย op.verificationGasLimit
  • ขั้นตอนการดำเนินการ: ส่วนหลักของ UserOp ขั้นตอนการดำเนินการทำงานตามที่กำหนดไว้ใน op.callData ขั้นตอนนี้ยังมีการจัดเมตร โดยใช้ op.callGasLimit

ขั้นตอนการยืนยันล่วงหน้าจะดําเนินการหนึ่งครั้ง ซึ่งเสนอความเป็นไปได้ในการตัดค่าใช้จ่ายก่อนการยืนยันในผู้ใช้ที่รวมอยู่ทั้งหมด เมื่อดําเนินการบันเดิลค่าใช้จ่ายทั้งหมด (เช่น block.basefee + ค่าธรรมเนียมลําดับความสําคัญที่จ่ายโดย bundler ให้กับผู้ผลิตบล็อกรวมถึงพวกเขา) จะถูกเรียกเก็บจาก bundler ซึ่งต้องตรวจสอบให้แน่ใจว่าการดําเนินการของผู้ใช้ชดเชยค่าใช้จ่ายที่เกิดขึ้น เราทําให้ข้อความเหล่านี้แม่นยําในส่วนต่อไปนี้

โมเดลตลาดค่าธรรมเนียมสำหรับกลุ่ม

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

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

ตลาดค่าธรรมเนียม EIP-1559 เปิดเผยราคาสํารอง r ที่เรียกว่า "ค่าธรรมเนียมพื้นฐาน" ซึ่ง bundlers จะต้องเกิดขึ้นเมื่อชุดของพวกเขาถูกดําเนินการ หากบันเดิลมีการดําเนินการ n bundler จะต้องเสียค่าใช้จ่ายอย่างน้อย n × S × r นอกจากนี้เนื่องจากกลุ่มใช้ "ก๊าซตรวจสอบล่วงหน้า" เช่นปริมาณ F บางอย่าง bundler จะจ่าย F เพิ่มเติม× r

. การดำเนินการที่รวมอยู่ในชุดนี้มีอยู่ในเซ็ต B.

ฟังก์ชันต้นทุนของบันเดล

เราตอนนี้พิจารณาค่าใช้จ่ายที่เกิดขึ้นจากผู้รวมพลของการรวมกลุ่มของพวกเขาในบล็อก

On-chain ฟังก์ชันต้นทุน: การแพคเกจรวม B เมื่อค่าฐานเป็น r จะใช้ค่าใช้จ่าย:

ปัญหาของโปรแกรมตรวจสอบการเบิกจ่ายเงินสะท้อนสถานการณ์ของโปรดิวเซอร์บล็อกที่ถูกนำเสนอใน[Roughgarden 2021] 3. ที่นั่นผู้ผลิตบล็อกต้องตรวจสอบให้แน่ใจว่ามีการจัดหามูลค่าบางอย่าง μ ชดเชยค่าใช้จ่ายในการรวมธุรกรรมเพิ่มเติมให้กับบล็อกของพวกเขา (เช่น μ อาจชดเชยภาระที่เพิ่มขึ้นของบล็อกซึ่งทําให้การขยายพันธุ์ล่าช้าและเพิ่มความเสี่ยงในการจัดระเบียบใหม่) ตลาดค่าธรรมเนียมระดับบล็อกจะต้องตรวจสอบให้แน่ใจว่าผู้ผลิตบล็อกได้รับการชดเชยอย่างน้อยสําหรับต้นทุนรวม n × S × μ หากผู้ผลิตบล็อกรวมธุรกรรม n ไว้ในบล็อกของพวกเขา ตลาดค่าธรรมเนียมระดับ bundler จะต้องชดเชยอย่างน้อย bundler สําหรับค่าใช้จ่ายภายนอก

Con-chain(B,r) ที่พวกเขาได้รับจากตลาดค่าธรรมเนียมขนาดใหญ่ที่พวกเขาถูกฝังอยู่ใน

ERC-4337 เสนอความเป็นไปได้ในการตัดจําหน่ายค่าใช้จ่ายนอกเหนือจากการแบ่งปันต้นทุนก๊าซก่อนการตรวจสอบ หากการดําเนินการทั้งหมดใช้รูปแบบลายเซ็นเดียวกันสําหรับขั้นตอนการตรวจสอบลายเซ็นของการดําเนินการเหล่านี้อาจเป็น รวมเป็น 2โดยการรวมกลุ่ม โดยที่ไม่ต้องการการยืนยันลายเซ็นบนเชื่อมโยง n ลายเซ็น แต่อาจต้องการใช้การยืนยันลายเซ็นเพียงหนึ่งครั้ง ในกรณีนี้ ฟังก์ชันต้นทุนของผู้รวมกลุ่มจะต้องคำนึงถึงค่าใช้จ่ายนอกโซนที่ผู้รวมกลุ่มต้องรับผิดชอบเมื่อทำการรวมกลุ่ม ในที่นี้ เราสมมติว่าค่าใช้จ่ายดังกล่าวเป็นเชิงเส้นต่อจำนวนของการดำเนินการ สมมติฐานที่คล้ายกันกับ[วังและคณะ, 2024] 2, ที่มีค่าใช้จ่ายขั้นต่ำ ω.

นอกจากนี้เรายังคํานึงถึงปริมาณการใช้ก๊าซที่ลดลงของแต่ละการดําเนินการเนื่องจากการประหยัดจากการรวม เมื่อรวมเข้าด้วยกันการดําเนินการไม่จําเป็นต้องเผยแพร่ลายเซ็น แต่ต้องมีการดําเนินการจับคู่เพิ่มเติม ในห่วงโซ่ที่ต้นทุน calldata มีราคาแพง แต่การจับคู่การดําเนินการ / การคํานวณมีราคาถูกการรวมจึงช่วยประหยัดต่อการดําเนินการ ในกรณีนี้เราแสดงโดย S′ < S ถึงขนาดที่ลดลงของธุรกรรม นอกจากนี้เรายังต้องคํานึงถึงการใช้ก๊าซก่อนการตรวจสอบที่เพิ่มขึ้น F′ > F ซึ่งตอนนี้มีการเผยแพร่และการตรวจสอบลายเซ็น aggreGated แบบ on-chain เดียว

ฟังก์ชันต้นทุนที่รวมกัน: ผู้รวมกลุ่มที่ออกกลุ่ม B ด้วยลายเซ็นที่รวมกันเมื่อค่าฐานคือ r จะเสียค่าใช้จ่าย:

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

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

การตรวจสอบปริมาณตลาดค่าธรรมเนียมอีกครั้ง

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

กฎการจัดสรรระดับการจัดสรร: การจัดสรร (ระดับการจัดสรร) x ตัดสินใจเซ็ตของการดำเนินการของผู้ใช้ที่ผูกเข้าไว้ในกอง, โดยให้ค่า mempool M และค่าฐาน r ปัจจุบัน

กฎการชำระเงินระดับแบบชุด: โดยที่กฎการชำระเงินจะกำหนดค่าธรรมเนียมให้แก่ผู้ใช้ทุกคนที่ถูกรวมอยู่ในชุดของการดำเนินการที่เลือก

ฟังก์ชันการใช้งานของผู้ใช้:

โดยหลักเราสามารถอนุญาตให้เกิดกฎการเผาไหม้ qt(B) ที่แสดงถึงข้อเท็จจริงว่าผู้รวบรวมอาจไม่ได้รับเงินจากผู้ใช้ทั้งหมดที่รวมอยู่ แต่เราไม่พิจารณาในบันทึกฉบับนี้

(Myopic) ฟังก์ชั่นบรรจุสินค้า:

TFM ระดับบันเดิล (x, p) เข้ากันได้กับสิ่งจูงใจสําหรับ myopic bundlers (MBIC) หากสําหรับทุก mempool M และค่าธรรมเนียมพื้นฐาน r bundler myopic จะเพิ่มยูทิลิตี้สูงสุดโดยทําตามคําแนะนําของกฎการจัดสรร x (เช่นการตั้งค่า B = x (M, r))

การรวมกลุ่มหลายรายการ

ในส่วนก่อนหน้านี้เราได้พิจารณาถึงความเป็นไปได้ที่ bundler จะออกชุดเดียวเท่านั้น อย่างไรก็ตามเราอาจสนใจความเป็นไปได้ที่ bundler จะสร้างชุดมากกว่าหนึ่งชุดจากการดําเนินการที่มีอยู่ใน mempool เมื่อพิจารณาจาก mempool M ให้ P (M) แทนชุดของพาร์ติชันของ mempool กําหนดการดําเนินการแต่ละครั้งให้กับกลุ่มเดียว (เราอาจสันนิษฐานว่าสําหรับแต่ละพาร์ติชันมีชุดที่จัดทําดัชนี 0 ซึ่งมีการดําเนินการทั้งหมดที่ไม่ได้กําหนดให้กับชุดรวม) กฎการปันส่วนจะส่งกลับดัชนีของชุดในพาร์ติชันที่กําหนดการดําเนินการ

เราสามารถเขียนเซตของแบรนด์เอาท์พุตที่ถูกแบ่งแยกโดยตัวแบ่ง x(M, β) เป็น B(x(M, r)) ในทางตรรกะ, แบรนด์เหล่านี้ประกอบด้วยการดำเนินการที่ไม่อยู่ในเซตที่มีดัชนี 0 กำหนดให้มีเซตของแบรนด์ B กฎการชำระเงินคือ:

ฟังก์ชันการใช้งานของผู้ใช้เปลี่ยนเป็น:

และฟังก์ชันการรวมแบบที่ประโยชน์กลายเป็น:

เกมการบรรจุ

การรวมธุรกรรมในบล็อกจะต้องชำระเงินให้แก่ผู้ผลิตบล็อกด้วยปริมาณ μ บางปริมาณ ซึ่งถูกสันนิษฐานว่าเป็นเส้นตรงกับขนาดของธุรกรรม เช่น [Roughgarden, 2021] 3ปริมาณนี้หมายถึงค่า Opportunity cost สำหรับผู้ผลิตบล็อกที่จะเพิ่มธุรกรรมอีกหนึ่งรายการลงในบล็อกของพวกเขา เช่น เพิ่มความล่าช้าในการแพร่เสียงและทำให้มีโอกาสเพิ่มขึ้นที่บล็อกจะถูกเรอจ์อีกครั้ง ใน Proof-of-Stake แม้ว่ากฎระเบียบของโปรโตคอลจะอนุญาตให้มีเวลาเพียงพอในการแพร่เสียงบล็อกเต็มแบบ แต่เกมการตั้งเวลาhave induced “last-second” propagation dynamics which have once again made this μ parameter relevant.

ในทุกกรณีเราอาจสังเกตเห็นว่าปัญหาในการแบ่งปันค่าใช้จ่ายที่ระดับบล็อกและระดับแบรนด์มีความแตกต่างกันมาก ในระดับบล็อก การทำธุรกรรมไม่จำเป็นต้องรู้ว่าเกิดอะไรขึ้นภายในบล็อกเพื่อการจัดอุทยานการรวมตัวตาม EIP-1559 (อาจต้องการทราบว่าเกิดอะไรขึ้นเรื่อง MEV[Bahrani et al., 2024] 9แต่เราจะพิจารณาว่านี่เป็นปัญหาแยกต่างหากในตอนนี้) ที่ระดับมัดต้นทุนค่าโสหุ้ยมัดจะไม่เป็นเส้นตรงในจํานวนธุรกรรมอีกต่อไป แต่ค่าโสหุ้ยคงที่อาจถูกตัดจําหน่ายโดยธุรกรรมจํานวนมาก นอกจากนี้หากต้นทุนการรวมของการดําเนินงานของผู้ใช้ไม่เป็นเชิงเส้นในจํานวนธุรกรรม (เช่นหลักฐานบางอย่างเป็นเชิงเส้นย่อยอย่างมีประสิทธิภาพในขนาดที่ได้รับการพิสูจน์แล้ว) ซึ่งเสนอความเป็นไปได้ในการตัดจําหน่ายต้นทุนรวมสําหรับผู้ใช้จํานวนมาก

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

• op.maxPriorityFeePerGas และ op.maxFeePerGas อาจถูกตั้งค่าตามการวิเคราะห์พฤติกรรมที่ผู้ใช้จะใช้ภายใต้ EIP-1559 กล่าวคือเมื่อพิจารณาจากปริมาณก๊าซโดยประมาณที่แผนการดําเนินงานของพวกเขาจะใช้ผู้ใช้จะตั้งค่าคุณลักษณะเหล่านี้เพื่อปรับเทียบจํานวนเงินที่พวกเขายินดีจ่ายในกรณีที่เลวร้ายที่สุด (maxFee) และจํานวนเงินที่พวกเขายินดีเติมเพื่อจ่ายให้กับผู้ผลิตบล็อกในที่สุด (maxPriority) แต่ผู้ใช้ควรประเมินก๊าซอย่างไร?
• op.preVerificationGas เป็นคุณลักษณะของ UserOperation ที่ต้องกำหนดเพื่อแสดงปริมาณของ "gas เพิ่มเติม" ที่แผนการดำเนินการของผู้ใช้ต้องการใช้งาน ในโมเดลของเรา เราอนุญาตให้
• F ระบุว่านี้เป็น "ค่าใช้จ่ายแก๊สคงที่" หากมีผู้ใช้ n คนถูกรวมอยู่ในแบนเดิล แต่ละผู้ใช้ควรตั้งค่า preVerificationGas = F / n อย่างไรก็ตาม หากผู้ใช้เตรียมการดำเนินการของพวกเขาโดยให้ความสำคัญกับสถานการณ์ที่แย่ที่สุดพวกเขาจะตั้งค่า preVerificationGas = F

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

ในขณะที่พวกเขาต้องรับผลกระทบทางด้านต้นทุน:

เมื่อพวกเขาเผยแพร่บันเดิลที่รวมการดําเนินการ n ทั้งหมดเข้าด้วยกันในบล็อก สิ่งนี้ทําให้ผู้มัดมีกําไร π = (n−1)×F×r

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

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

, นั่นคือการขู่เดือดที่จะเก็บผู้ใช้ทุกคนในกลุ่มเดียวกันและเรียกเก็บค่าน้ำมันสูงสุด

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

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

กรณีที่เหมาะสม: ค่าใช้จ่ายถูกแบ่งแยกระหว่างผู้ใช้ในแบบไบรด์เดิ้ล กรณีที่เป็นภาวะคาดหมายแย่: ผู้ใช้จ่ายมากเกินไป และค่าใช้จ่ายไม่ถูกแบ่งแยก

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

อลิซคาดว่าผู้ใช้อีก 9 คนจะปรากฏตัวนอกเหนือจากตัวเอง ดังนั้นเธอจึงตั้งค่า preVerificationGas เป็น 1 ตามที่เธอรู้จัก F = 10 ค่าของอลิซและมูลค่าของผู้ใช้รายอื่นทั้งหมดเข้ากันได้กับการตั้งค่า preVerificationGas = 3 แต่เธอพยายามจ่ายเงินให้น้อยที่สุดสําหรับการรวมของเธอ ปรากฎว่ามีผู้ใช้เพียง 5 คนเท่านั้นที่ปรากฏในตลาดซึ่งได้ตั้งค่า preVerificationGas เป็น 1 เช่นกัน bundler จะไม่ได้รับการชดเชยสําหรับ F = 10 หน่วยของก๊าซดังนั้น bundler จะไม่ส่งออกชุดและผู้ใช้จะได้รับ 0 ยูทิลิตี้ เห็นได้ชัดว่านี่เป็น suboptimal เนื่องจากผู้ใช้สามารถตั้งค่า preVerificationGas = 2 ได้ทั้งหมดและรับยูทิลิตี้ 1 รายการ (preVerificationGas สูงสุดที่พวกเขายินดีที่จะตั้งค่าลบด้วย preVerificationGas จริงที่พวกเขาจ่ายเพื่อรวมไว้)

งานในอนาคต

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

ข้อปฏิเสธ:

1. บทความนี้ถูกพิมพ์ใหม่จาก [Gateethresear], ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [DavideRezzoli]. หากมีการคัดค้านการพิมพ์ซ้ํานี้โปรดติดต่อ Gate Learn ทีมและพวกเขาจะจัดการกับมันทันที
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงอยู่ในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางด้านการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่น ๆ ทำโดยทีม Gate Learn หากไม่ได้กล่าวถึง การคัดลอก การกระจายหรือการลอกเลียนแบบบทความที่ถูกแปลนั้นถือเป็นการฝ่าฝืนกฎหมาย