ใน Ethereum ทรัพยากรถูก จํากัด เมื่อเร็ว ๆ นี้และกําหนดราคาโดยใช้ทรัพยากรเดียวที่เรียกว่า "ก๊าซ" ก๊าซคือการวัดจํานวน "ความพยายามในการคํานวณ" ที่จําเป็นในการประมวลผลธุรกรรมหรือบล็อกที่กําหนด ก๊าซรวม "ความพยายาม" หลายประเภทเข้าด้วยกันโดยเฉพาะอย่างยิ่ง:

• การคำนวณเชิงรุก (เช่น บวก, คูณ)
• การอ่านและเขียนไปยังการเก็บข้อมูลของ Ethereum (เช่น SSTORE, SLOAD, การโอน ETH)
• แบนด์วิดธ์ข้อมูล
• ต้นทุนในการสร้าง ZK-SNARK proofของบล็อก

ตัวอย่างเช่น ธุรกรรมนี้ว่าฉันส่งมีค่าทั้งหมด 47,085 แก๊ส แบ่งเป็น (i) ค่าฐาน 21,000 แก๊ส (ii) 1556 แก๊สสำหรับไบต์ใน calldata ที่รวมอยู่ในธุรกรรม (iii) 16500 แก๊สสำหรับการอ่านและเขียนไปยังพื้นที่จัดเก็บ (iv) แก๊ส 2149 สำหรับการทำบันทึก, และส่วนที่เหลือสำหรับการดำเนินการ EVM ค่าธรรมเนียมการทำธุรกรรมที่ผู้ใช้ต้องจ่ายเป็นสัมระกับแก๊สที่ธุรกรรมใช้ไปบล็อกสามารถบรรจุได้สูงสุด 30 ล้านแก๊สและราคาแก๊สถูกปรับตาม@vbuterinการสำรวจ EIP-1559 ที่เน้นการเข้าถึง เพื่อให้บล็อกมีแก๊สอย่างน้อย 15 ล้านเฉลี่ย

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

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

ขีดจำกัดขอบเขตของแก๊ส

𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛<𝑁

ข้อจำกัดด้านความปลอดภัยในขณะนี้จริงๆมักอยู่ใกล้กับ

𝑚𝑎𝑥(𝑥1∗𝑑𝑎𝑡𝑎,𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛)<𝑁

. ความขัดแย้งนี้ทำให้ข้อจำกัดของแก๊สไม่จำเป็นต้องยกเว้นบล็อกที่ปลอดภัยจริง ๆ หรือยอมรับบล็อกที่ไม่ปลอดภัยจริง ๆ หรือเป็นสารสำคัญระหว่างทั้งสอง

ถ้ามี

𝑛

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

𝑛

. เพราะเหตุนี้มีความสนใจต่อแนวคิดของแก๊สหลายมิติมานานแล้ว และกับEIP-4844เราจริง ๆ มีแก๊สหลายมิติที่ทำงานบน Ethereum ในขณะนี้ โพสต์นี้สำรวจประโยชน์ของวิธีการนี้ และโอกาสในการเพิ่มมันได้อีก

Blobs: แก๊สหลายมิติใน Dencun

ตอนเริ่มต้นของปีนี้ บล็อกเฉลี่ย150 kB in ขนาดขนาดส่วนใหญ่ของข้อมูลนั้นคือข้อมูล rollup: โปรโตคอลชั้นที่ 2การเก็บข้อมูลบนเชนเพื่อความปลอดภัย ข้อมูลเหล่านี้มีค่าใช้จ่ายสูง: แม้ว่าธุรกรรมบน rollups จะมีค่าในระดับ ~5-10 เท่าน้อยกว่าธุรกรรมที่เกิดขึ้นบน Ethereum L1 แต่ค่าใช้จ่ายเหล่านั้นก็ยังสูงเกินไปสำหรับกรณีการใช้งานหลายรายการ

ทำไมไม่ลดค่าแก๊ส calldata (ปัจจุบันคือ 16 แก๊สต่อไบต์ที่ไม่เท่ากับศูนย์และ 4 แก๊สต่อไบต์ที่เท่ากับศูนย์) เพื่อทำให้ rollups ถูกกว่า?ทำนี่ก่อน, เราสามารถทำมันอีกครั้ง คำตอบที่นี่คือ: ขนาดสุดเลวของบล็อกเป็น

30,000,00016=1,875,000

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

ปัญหานี้ได้รับการจัดการโดยการนำเข้าพื้นที่เฉพาะของข้อมูลที่เป็นมิตรกับ rollup ที่เรียกว่า "blobs" ลงในแต่ละบล็อก ทั้งสองทรัพยากรมีราคาและขีดจำกัดที่แยกกัน: หลังจากการ hard fork ของ Dencun บล็อก Ethereum สามารถมีแก๊สได้มากที่สุด (i) 30 ล้านแก๊ส และ (ii) 6 blobs ซึ่งสามารถบรรจุ calldata ประมาณ 125 kB แต่ละอัน ทั้งสองทรัพยากรมีราคาที่แยกกัน ที่ปรับโดยกลไกการกำหนดราคาที่เหมือนกับ EIP-1559 โดยแยกออกจากกัน, มุ่งเน้นการใช้งานเฉลี่ย 15 ล้านแก๊สและ 3 บล็อกต่อบล็อก

เป็นผลจากนี้ การจัดกลุ่มที่ดีขึ้น 100 เท่า ปริมาณการทำธุรกรรมบนการจัดกลุ่มเพิ่มขึ้นมากกว่า 3 เท่า และขนาดบล็อกสูงสุดทฤษฎีเพิ่มขึ้นเล็กน้อยเท่านั้น: จาก ~1.9 MB เป็น ~2.6 MB

ค่าธรรมเนียมการทำธุรกรรมบน rollups ของ growthepie.xyz. การฟอร์ค Dencun ซึ่งเป็นการแนะนำของ blobs ที่มีราคาที่หลากหลายมิติเกิดขึ้นในวันที่ 13 มีนาคม พ.ศ. 2024

Multi-dimensional แก๊ส and stateless clients

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

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

ค่าอ่านการจัดเก็บเป็น 2100-2600 แก๊สตามขึ้นอยู่กับประเภทของการอ่าน และการเขียนการจัดเก็บมีค่าใช้จ่ายมากกว่า โดยเฉลี่ย บล็อกทำบางอย่างในระดับ 1000 การอ่านและเขียนการจัดเก็บ (รวมถึงการตรวจสอบยอดเงิน ETH, การโทร SSTORE และ SLOAD, การอ่านรหัสสัญญา, และการดำเนินการอื่น ๆ) ส่วนสูงสุดที่เป็นไปได้ทึบอยู่ที่

30,000,0002,100=14,285

อ่านว่า ภาระแบนด์วิดธ์ของไคลเอ็นต์ที่ไม่มีสถานะเป็นสัมบูรณ์ตรงข้ามกับจำนวนนี้

วันนี้แผนคือการสนับสนุนลูกค้าที่ไม่มีสถานะโดยการย้ายการออกแบบต้นไม้สถานะของ Ethereum จากต้นไม้ Merkle Patriciaถึงต้นไม้ Verkle. อย่างไรก็ตามเรือป้อมไม้ Verkle ไม่ได้ต้านทานทางควอนตัมและไม่เหมาะสำหรับระบบพิสูจน์ STARK คลื่นใหม่ ๆ ดังนั้น ผู้คนหลายคนสนใจในการสนับสนุนลูกค้าที่ไม่มีสถานะผ่านต้นไม้ Merkle ทวิภาคSTARKsแทนที่จะข้าม Verkle โดยสิ้นเชิง หรืออัปเกรดหลังจากที่ Verkle transition ไปแล้วไม่กี่ปี หลังจากนั้น STARKs ก็จะกลายเป็นอันดับหนึ่ง

การพิสูจน์ STARK ของกิ่งต้นเฮชไบนารีมีข้อดีมากมาย แต่พวกเขามีจุดอ่อนที่สำคัญคือการพิสูจน์ใช้เวลาในการสร้างนาน: ในขณะที่ ต้นเวอร์เคิล can prove มากกว่าแสนค่าต่อวินาที, สตาร์คที่ใช้แบบแบบโฮว์ส์สามารถพิสูจน์ได้เพียงหลายพันแห่งต่อวินาทีและการพิสูจน์ค่าแต่ละค่าต้องการ “สาขา” ที่มีแฮชมากมาย

จากตัวเลขที่กำลังถูกโปรเจคชันวันนี้จากระบบพิสูจน์ที่ถูกปรับแต่งอย่างสมบูรณ์BiniusและPlonky3และแฮชที่เชี่ยวชาญเช่นVision-Mark-32, ดูเหมือนว่าเป็นไปได้ที่เราจะอยู่ใน reสักเวลาที่จะเป็นประจำที่จะพิสูจน์ค่า 1,000 ค่าในเวลาน้อยกว่าหนึ่งวินาที แต่ไม่ใช่ 14,285 ค่า บล็อกเฉลี่ยจะดี แต่บล็อกในกรณีที่แย่ที่สุด ที่อาจถูกเผยแพร่โดยผู้โจมตี จะทำลายเครือข่าย

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

แก๊สหลากมิติมากขึ้นโดยทั่วไป

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

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

2𝑛

degrees of freedom to set

2𝑛

พารามิเตอร์ ปรับแต่งแต่ละอย่างโดยขึ้นอยู่กับสิ่งที่ปลอดภัยสำหรับเครือข่าย

สถานการณ์ที่ซับซ้อนมากขึ้น เช่น เมื่อทรัพยากรสองรายการมีการพิจารณาความปลอดภัยที่บางส่วนที่สามารถจัดการได้ด้วยการทำให้รหัสคำสั่งหรือค่าทรัพยากรบางปริมาณของแก๊สหลายประเภท (เช่น การ SSTORE ที่เป็นศูนย์ถึง SSTORE ที่เป็นศูนย์ อาจมีค่า 5000 แก๊สสำหรับการพิสูจน์ไคลเอนต์โดยไม่มีสถานะและ 20000 แก๊สสำหรับการขยายพื้นที่เก็บข้อมูล)

Per-transaction max: วิธีที่อ่อนแอแต่ง่ายที่สุดในการได้รับแก๊สหลายมิติ

Let

𝑥1

เป็นค่าใช้จ่ายแก๊สของข้อมูลและ

𝑥2

เป็นค่าแก๊สของการคำนวณ ดังนั้นในระบบแก๊สที่มีมิติหนึ่งเราสามารถเขียนค่าแก๊สของธุรกรรมได้:

แก๊ส=𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛

ในโครงการนี้เราจะกำหนดค่าแก๊สของธุรกรรมเป็น

แก๊ส=มักซ์(x1*การดำเนินการ,x2*คอมพิวเตอร์)

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

max(…,x3*storage_access)

.

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

𝐺𝐴𝑆𝐿𝐼𝑀𝐼𝑇𝑥1

, ที่เหมือนกันกับโครงการแก๊สหนึ่งมิติ อย่างไรก็ตาม ปริมาณการคำนวณสูงสุดทฤษฎีคือ

𝐺𝐴𝑆𝐿𝐼𝑀𝐼𝑇𝑥2

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

นี่คือโครงการโดยประมาณที่ใช้ในข้อเสนอEIP-7623เพื่อลดขนาดบล็อกสูงสุดในขณะที่เพิ่มจํานวน blob ต่อไป กลไกที่แม่นยําใน EIP-7623 นั้นซับซ้อนกว่าเล็กน้อย: ทําให้ราคา calldata ปัจจุบันอยู่ที่ 16 ก๊าซต่อไบต์ แต่เพิ่ม "ราคาพื้น" ที่ 48 ก๊าซต่อไบต์ ธุรกรรมจ่ายสูงกว่า (16 bytes + execution_gas) และ (48 bytes). ด้วยผลลัพธ์ EIP-7623 ทำให้ขนาดข้อมูลการทำธุรกรรมที่สูงสุดทฤษฎีในบล็อกลดลงจาก 1.9 MB เป็น 0.6 MB ในขณะที่ค่าใช้จ่ายของแอปพลิเคชันส่วนใหญ่ไม่มีการเปลี่ยนแปลง ประโยชน์ของวิธีนี้คือมันเป็นการเปลี่ยนแปลงที่เล็กน้อยมากจากระบบแก๊สแบบมิติเดียวปัจจุบัน ดังนั้นมันง่ายมากที่จะนำมาใช้งาน

มีข้อเสียสองประการ:

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

ฉันขอว่าจะมีกฎแบบ EIP-7623 ทั้งสำหรับ transaction calldata และสำหรับทรัพยากรอื่น ๆ ที่สามารถนำประโยชน์ได้มากพอที่คุ้มค่า แม้กระทั่งมีข้อเสียเหล่านี้ อย่างไรก็ตาม หากและเมื่อเราพร้อมที่จะใช้ความพยายามในการพัฒนา (ที่สูงมาก) มีวิธีที่ดีกว่า

Multidimensional EIP-1559: ยุทธวิธีที่ยากแต่เหมาะสม

เราเริ่มจากการสรุปวิธีการทำงานของ EIP-1559 "ปกติ" ก่อน เราจะให้ความสำคัญกับเวอร์ชันที่ถูกนำเสนอใน EIP-4844 สำหรับ blobs เพราะมันเป็นทางคณิตศาสตร์ที่สง่างามมากขึ้น

เราติดตามพารามิเตอร์ excess_blobs ระหว่างทุกๆ บล็อก เราตั้งค่า:

excess_blobs <— max(excess_blobs + len(block.blobs) - TARGET, 0)

ที่ที่ TARGET = 3 นั่นคือหากบล็อกมี blobs มากกว่าเป้าหมาย excess_blobs เพิ่มขึ้น และหากบล็อกมีน้อยกว่าเป้าหมาย excess_blobs ลดลง เราจึงตั้ง blob_basefee = exp(excess_blobs / 25.47) โดยที่ exp เป็นการประมาณฟังก์ชันเอ็กซโพเนนเชียล

𝑒𝑥𝑝(𝑥)=2.71828𝑥

.

นั่นคือ เมื่อ excess_blobs เพิ่มขึ้นประมาณ ~25 แล้ว ค่าธรรมเนียมขั้นพื้นฐานของ blob เพิ่มขึ้นด้วยอัตราประมาณ ~2.7 หาก blobs เริ่มแพงเกินไป การใช้งานเฉลี่ยลดลง และ excess_blobs เริ่มลดลง โดยลดราคาอัตโนมัติ ราคาของ blob ปรับตัวอย่างที่แน่นอนเพื่อให้แน่ใจว่าโดยเฉลี่ยบล็อกจะเต็มครึ่ง - กล่าวคือ พวกเขาประกอบด้วยเฉลี่ยของ 3 blobs แต่ละอัน

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

ประเภทการกำหนดราคานี้มีอยู่ใน Ethereum สำหรับแก๊สมาหลายปี: มีกลไกที่คล้ายกันมีการนำเสนอด้วย@vbuterin/eip-1559-faq">EIP-1559 กลับมาในปี 2020 ด้วย EIP-4844 เราตอนนี้มีราคาแยกที่ละสองอย่างสำหรับแก๊สและสำหรับ blobs

ค่าฐานแก๊สในระหว่างหนึ่งชั่วโมงเมื่อวันที่ 8 พฤษภาคม 2024 ในเกเวย แหล่งที่มา: ultrasound.money.

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

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

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

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

การกำหนดราคาแบบหลายมิติ โปรแกรม EVM และการเรียกย่อย

มีปัญหาหนึ่งที่ไม่ปรากฏกับ blobs และจะไม่ปรากฏกับ EIP-7623 หรือแม้แต่ “full” multidimensional pricing implementation สำหรับ calldata แต่จะปรากฏถ้าเราพยายามอินไพร์ราคาการเข้าถึงสถานะโดยแยกออกมา หรือทรัพยากรอื่น ๆ: ขีดจำกัดแก๊สในการเรียกซับ

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

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

ความท้าทายคือ: การทำให้แก๊สมีมิติหลายมิติระหว่างประเภทการดำเนินการที่แตกต่างกันดูเหมือนว่าจะต้องใช้การเรียกย่อยเพื่อให้ได้ข้อจำกัดหลายข้อสำหรับแต่ละประเภทของแก๊ส ซึ่งจะต้องการการเปลี่ยนแปลงที่ลึกลึกจริง ๆ ใน EVM และไม่สอดคล้องกับแอปพลิเคชันที่มีอยู่อย่างแท้จริง

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

เราสามารถคิดถึง "EIP-7623-style solution" ในการแก้ปัญหานี้ นี่คือหนึ่งวิธีการที่เรียบง่าย: ในระหว่างการดำเนินการ คิดค่าใช้จ่ายสำหรับการเก็บข้อมูลเพิ่มขึ้น 4 เท่า; เพื่อความง่ายในการวิเคราะห์ ขอให้เราพูดถึง 10000 gas ต่อการดำเนินการเก็บข้อมูล ที่สุดของธุรกรรม คืนเงิน min(7500 * storage_operations, execution_gas) ผลลัพธ์คือ หลังจากหักเงินคืน ผู้ใช้จะถูกเรียกเก็บเงิน:

execution_แก๊ส + 10000 การดำเนินงานการจัดเก็บ - min(7500 storage_operations, execution_gas)

ซึ่งเท่ากับ:

max(execution_gas + 2500 storage_operations, 10000 storage_operations)

นี่เหมือนกรอบของ EIP-7623 วิธีอื่น ๆ ในการทำคือติดตาม storage_operations และ execution_gas แบบเรียลไทม์ และคิดค่าใช้จ่ายทั้ง 2500 หรือ 10000 ขึ้นอยู่กับว่า max(execution_gas + 2500 มีเท่าไหร่การดำเนินงานเก็บรักษา, 10000การดำเนินการเก็บรักษา) เพิ่มขึ้นในเวลาที่ opcode ถูกเรียก สิ่งนี้ช่วยให้ไม่ต้องมีการจ่ายเงินเพิ่มเติมที่จะได้รับกลับมาผ่านการคืนเงิน

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

วิธีที่ง่ายที่สุดที่ฉันคิดถึงเกี่ยวกับ "การแก้ปัญหาราคาหลายมิติที่สมบูรณ์" คือ: เราจะต้องการวัสดุย่อยแก๊ส ณ โครงการ ในอัตราสัมพันธ์กัน

𝑘

ประเภทการดำเนินการที่แตกต่างกัน และทุกรายการธุรกรรมกำหนดขีดจำกัดที่มีมิติหลายมิติ

𝐿1…𝐿𝑘

. สมมติว่า ณ จุดปัจจุบันของการดำเนินการ แก๊สที่เหลือ

𝑔1…𝑔𝑘

. สมมติว่ามีการเรียกใช้รหัสคำสั่ง CALL โดยมีขีดจำกัดแก๊สในการเรียกซับคอล

𝑆

. Let

𝑠1=𝑆

และจากนั้น

𝑠2=𝑠1𝑔1∗𝑔2

,

𝑠3=𝑠1𝑔1∗𝑔3

, และอื่น ๆ

นั่นคือเราจัดการประเภทแรกของแก๊ส (อย่างเชิงจริง VM การดำเนินการ) ให้เป็นชนิดของ "หน่วยบัญชี" ที่เป็นพิเศษ และจากนั้นกำหนดแก๊สประเภทอื่น ๆ โดยที่การเรียกซับได้รับเปอร์เซ็นต์เดียวกันของแก๊สที่ใช้ได้ในแต่ละประเภท นี่คือที่น่าเสียดายเล็กน้อย แต่มันทำให้เกิดความเข้ากันได้ย้อนหลังสูงสุด หากเราต้องการที่จะทำให้ระบบเป็น "เนวัต" มากขึ้นระหว่างประเภทแตกต่างของแก๊ส ซึ่งมีค่าใช้จ่ายในการสูญเสียความเข้ากันได้ย้อนหลัง เราสามารถมีพารามิเตอร์ขีดจำกัดแก๊สของการเรียกซับแทนด้วยเป็นเศษ (เช่น [1…63] / 64) ของแก๊สที่เหลือในบริบทปัจจุบัน)

ในกรณีใด ๆ ก็ตาม ความสำคัญก็คือเมื่อคุณเริ่มนำแก๊สการดำเนินการหลายมิติเข้ามา ระดับความไมสวยงามที่มีอยู่เพิ่มขึ้น และดูเหมือนว่ามันยากที่จะหลีกเลี่ยง ดังนั้น งานของเราคือการทำการต่อรองที่ซับซ้อน: เรายอมรับความไมสวยงามบางประการที่ระดับ EVM เพิ่มขึ้นเพื่อปลดล็อคประสิทธิภาพในระดับ L1 ที่สำคัญและหากเป็นเช่นนั้น ข้อเสนอเฉพาะเจาะจงใดที่เหมาะที่สุดสำหรับเศรษฐศาสตร์โปรโตคอลและผู้พัฒนาแอปพลิเคชัน? มีโอกาสมากที่มันไม่ใช่คนที่ฉันกล่าวถึงข้างต้น และยังมีที่ว่างในการคิดให้เกิดสิ่งที่สวยงามและดีกว่า

ข้อปฏิเสธ：

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