ส่งต่อชื่อเดิม：กลไกค่าธรรมเนียมการทำธุรกรรมของ Solana & Ethereum: ข้อเสนอเพื่อปรับปรุง TFM ของ Solana

ขอขอบคุณ Andrew Fitzgerald, Harsh Patel, Jon Charbonneau, Kevin Galler, Lanre Ige, Mert Mumtaz, Pranav Garimidi, Ryan Chern, Tao Zhu และ Tarun Chitra สำหรับคำติชมและบทวิจารณ์

แนะนำสกุลเงิน

Eclipse เป็น SVM L2 ตัวแรกของ Ethereum เรารู้สึกตื่นเต้นอย่างไม่น่าเชื่อที่จะนำพลังของ SVM ที่มีอยู่มาสู่ผู้ใช้มากขึ้น แต่เรายังมุ่งมั่นที่จะผลักดันการวิจัยและพัฒนาอย่างต่อเนื่องเกี่ยวกับ SVM อีกด้วย เรามุ่งเน้นไปที่การทำให้แน่ใจว่าการพัฒนาของ Eclipse จะคืนค่ากลับไปยังเชน SVM ทั้งหมดอย่างปฏิเสธไม่ได้ โดยเฉพาะ Solana

ในฐานะปูชนียบุคคลของบทความในอนาคตเกี่ยวกับการคิดของเราเกี่ยวกับตลาดค่าธรรมเนียม บทความนี้จะวิเคราะห์ตลาดค่าธรรมเนียมที่มีอยู่ของ Solana และข้อเสนอที่เกี่ยวข้องเพื่อปรับปรุง เราวางกรอบข้อเสนอเหล่านี้ควบคู่ไปกับเป้าหมายทางทฤษฎีหลักสำหรับกลไกค่าธรรมเนียมการทำธุรกรรม (TFM) โดยยืมมาจากงานของ Tim Roughgarden, Maryam Bahrani, Pranav Garimidi, Hao Chung, Elaine Shi และคนอื่นๆ เราจะระบุคำจำกัดความหลักตลอดด้วย **

โดยทั่วไป TFM จะกำหนด:

1. ธุรกรรมใดบ้างที่รวมอยู่ในบล็อกที่กำหนด
2. ค่าธรรมเนียมการทำธุรกรรมที่กำหนดจ่ายและ
3. ค่าธรรมเนียมการทำธุรกรรมสะสมจะถูกแจกจ่ายอย่างไร (และให้กับใคร)

ท้ายที่สุดแล้ว บทความนี้มุ่งหวังที่จะรวมความมั่งคั่งของการวิจัย TFM ที่เน้น Ethereum เข้ากับนวัตกรรมวิศวกรรมของ Solana

ภาพรวมของ TFM ปัจจุบันของ Solana และ Ethereum

ข้อมูลพื้นฐานเกี่ยวกับโซลานากับ Ethereum

เราจะเริ่มต้นด้วยภาพรวมของ TFM ของ Solana และเปรียบเทียบกับของ Ethereum สิ่งนี้จะทำให้ข้อเสนอที่เกี่ยวข้องมีบริบทดีขึ้น เพื่อให้เราสามารถดำเนินการแก้ไขและปรับปรุง TFM ได้ สำหรับผู้เริ่มต้น:

ค่าธรรมเนียมพื้นฐานของ Solana คือ 5,000 lamports (0.000005 SOL) คงที่ต่อลายเซ็น และธุรกรรมส่วนใหญ่จะมีลายเซ็นเดียว ไม่ได้คำนึงถึงทรัพยากรการคำนวณที่กว้างขึ้นของธุรกรรม (ตามที่วัดโดย CU)

ค่าธรรมเนียมฐาน Solana Tx = (5,000 Lamports) x (# ของลายเซ็นใน Tx)

กลไกค่าธรรมเนียมพื้นฐานของ Ethereum แตกต่างกันในสองวิธีหลัก:

1. ไดนามิก - ค่าธรรมเนียมพื้นฐานของ Ethereum (วัดโดย gwei ต่อหน่วยก๊าซ) ลอยตัวตามความต้องการของตลาดต่อท้าย
2. ค่าธรรมเนียมที่ละเอียดมากขึ้นต่อหน่วยการคำนวณ - ค่าธรรมเนียมพื้นฐานของ Ethereum ต่อการทำธุรกรรมจะเป็นเส้นตรงในปริมาณก๊าซที่ใช้

ดังนั้นค่าธรรมเนียมพื้นฐานของ Ethereum ต่อธุรกรรมคือ:

ค่าธรรมเนียมฐาน Ethereum Tx = (ราคาก๊าซปัจจุบันในหน่วย gwei) x (ก๊าซที่ใช้ใน tx)

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

1. SetComputeUnitLimit - ธุรกรรมสามารถกำหนดจำนวน CU สูงสุดที่ได้รับอนุญาตให้ใช้ (สูงสุด 1.4M CU ต่อธุรกรรม) เมื่อดำเนินการแล้ว ธุรกรรมสามารถใช้ได้ถึงขีดจำกัด CU ที่ร้องขอ หากไม่มีคำสั่ง SetComputeUnitLimit ขีดจำกัด CU ของธุรกรรมจะถูกคำนวณเป็น (# ของคำสั่งในธุรกรรม) x (200,000 CU)
2. SetComputeUnitPrice - # ของ micro-lamports ต่อ CU ร้องขอให้ธุรกรรมเสนอให้ชำระค่าธรรมเนียมตามลำดับความสำคัญ

นำมารวมกัน:

ค่าธรรมเนียมลำดับความสำคัญ Tx = (ขีดจำกัด Tx CU) x (ราคา CU)

โปรดทราบว่าค่าธรรมเนียมสำคัญนี้จะชำระตามจำนวน CU ทั้งหมดที่ร้องขอ (ไม่ว่าธุรกรรมจะใช้จำนวนเงินทั้งหมดที่ร้องขอหรือไม่) ไม่เหมือนใน Ethereum ซึ่งค่าธรรมเนียมจะขึ้นอยู่กับปริมาณก๊าซที่ธุรกรรมใช้จริง

การเผาค่าธรรมเนียมเทียบกับรางวัลผู้ตรวจสอบความถูกต้อง

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

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

ผู้ใช้ไม่สามารถหลีกเลี่ยงการจ่ายค่าธรรมเนียมพื้นฐานได้ แต่สามารถหลีกเลี่ยงค่าธรรมเนียมสำคัญและส่งสัญญาณความปรารถนาที่จะถูกจัดลำดับความสำคัญในลักษณะอื่นได้ เราเห็นสิ่งนี้แล้วในทางปฏิบัติ — การประมูลของ Jito-Solana จ่าย 100% (หักค่าธรรมเนียม) ให้กับผู้นำที่อยู่นอกกลุ่ม SIMD-0096 นำเสนอวิธีแก้ไขปัญหานี้แบบง่ายๆ โดยมอบรางวัล 100% ของค่าธรรมเนียมลำดับความสำคัญให้กับผู้ตรวจสอบ

การโอนโดยตรง*: ประสานงานผ่านการประมูล MEV-Boost / Jito-Solana

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

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

ที่มา: โซลานา คอมพาส

Ethereum Block Builder กับ Solana Scheduler

โดยทั่วไปการผลิตบล็อกของ Ethereum นั้นง่ายต่อการเข้าใจ ดังนั้นเราจะเริ่มต้นจากตรงนั้น ผู้ตรวจสอบเกือบทั้งหมด (aka ผู้เสนอ) จ้างการผลิตบล็อกจากภายนอกให้กับผู้สร้างนอกโปรโตคอลผ่าน MEV-Boost ผู้สร้างสร้างบล็อกทุกๆ 12 วินาที (เวลาสล็อตของ Ethereum) และส่งบล็อกทั้งหมดเหล่านี้ไปยังผู้เสนอ (ผ่านรีเลย์) ซึ่งจะเลือกบล็อกที่มีมูลค่าสูงสุด

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

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

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

คุณจะทราบว่ามีการรับประกันที่แตกต่างกันสองประการที่พยายามบรรลุค่าธรรมเนียมที่นี่:

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

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

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

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

ภายในหนึ่งบล็อก สามารถใช้ CU ได้สูงสุด 12,000,000 หน่วย สำหรับการเขียนตามลำดับไปยังบัญชีเดียว (“ชิ้นส่วนของรัฐ”) นี่คือจำนวน CU โดยประมาณที่สามารถประมวลผลได้โดยเธรดเดียวต่อสล็อต 400ms บนข้อกำหนดของโหนดที่สมเหตุสมผล ขีดจำกัดต่อบล็อกของ Solana คือ 48,000,000 CU การใช้งานตัวกำหนดเวลาปัจจุบันใช้สี่เธรดสำหรับธุรกรรมที่ไม่ลงคะแนนและ 12M x 4 = 48M ตามทฤษฎีแล้ว นี่หมายถึงการใช้คอร์มากขึ้น = การเพิ่มขีดจำกัด CU การปรับขนาดด้วยฮาร์ดแวร์

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

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

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

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

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

แม้ว่าส่วนใหญ่จะอยู่นอกขอบเขตของบทความนี้ แต่ ไคลเอนต์ Jito-Solana ช่วยให้ผู้ค้นหาจับค่า miner/maximal extractable value (MEV) ได้อย่างมีประสิทธิภาพมากขึ้นด้วยวิธีที่ลดผลกระทบภายนอกเชิงลบบน Solana ให้เหลือน้อยที่สุด Jito-Solana เบี่ยงเบนไปจากตัวกำหนดเวลาเริ่มต้นของ Solana โดยการแนะนำ การประมูลชุดรวม Flashbots-esque แบบ out-of-protocol discrete 200 มิลลิวินาที ซึ่งทำงานคู่ขนานกับการผลิตบล็อกต่อเนื่องที่เป็นค่าเริ่มต้นและ mempool ส่วนตัว (ซึ่งเบี่ยงเบนไปจาก TFM เริ่มต้นของ Solana อีกครั้ง) การนำไคลเอ็นต์ Jito-Solana มาใช้โดยเครื่องมือตรวจสอบความถูกต้องของ Solana (>50% ของผู้ตรวจสอบใช้งานในปัจจุบัน) ได้ช่วยแก้ไขปัญหาบางประการเกี่ยวกับ TFM ที่มีอยู่ของ Solana กล่าวคือ ความแพร่หลายของสแปมที่ขับเคลื่อนด้วย MEV

ข้อบกพร่องของ TFM ปัจจุบันของ Solana

แม้ว่า TFM ของ Solana จะมีแนวโน้มที่ดี แต่ก็มีข้อบกพร่องบางประการในตอนนี้:

แรงจูงใจให้สแปม

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

ที่มา: มูลนิธิจิโต้

การประมูลราคาแรก

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

อย่างเป็นทางการมากขึ้น โมเดล FPA ไม่ใช่ DSIC:

**Dominant Strategy Incentive Compatible (DSIC): สมมติว่าผู้ผลิตบล็อกใช้ TFM อย่างซื่อสัตย์ กลยุทธ์การเสนอราคาที่กำหนดควรเป็นกลยุทธ์ที่โดดเด่นสำหรับผู้ใช้ ซึ่งหมายความว่าผู้ใช้จะเสนอราคา (ในค่าธรรมเนียมการทำธุรกรรม) ตามมูลค่าที่แน่นอนที่พวกเขากำหนดให้รวมธุรกรรม [Chu22]

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

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

การจ่ายเงิน 50/50 Burn/Validator

ตามที่ระบุไว้ก่อนหน้านี้ Ethereum จะเผาค่าธรรมเนียมพื้นฐาน 100% ในขณะที่ส่งค่าธรรมเนียมลำดับความสำคัญ 100% ไปยังผู้ผลิตบล็อก ในขณะที่สำหรับ Solana ทั้งค่าธรรมเนียมพื้นฐานและค่าธรรมเนียมลำดับความสำคัญจะถูกเผา 50/50/จ่ายให้กับผู้ผลิตบล็อก ด้วยเหตุนี้ Solana TFM จึงไม่สามารถพิสูจน์ OCA ได้:

**การพิสูจน์ข้อตกลง Off-Chain (การพิสูจน์ OCA หรือ SCP): ไม่มีข้อตกลง off-chain ระหว่างผู้ใช้และผู้ผลิตบล็อก Pareto สามารถปรับปรุงผลลัพธ์ของ TFM สำหรับบล็อกที่กำหนด [Rou21] โปรโตคอล c-SCP สามารถต้านทานการรวมตัวของผู้ผลิตบล็อกและผู้ใช้สูงสุดสามารถทำกำไรได้จากการเบี่ยงเบนจากการรายงานตามความเป็นจริง

เราเห็นตัวอย่างที่ชัดเจนของเรื่องนี้ด้วยการประมูลนอกโปรโตคอลของ Jito-Solana โดยจ่าย 100% ของราคาเสนอ (ลดการตัดของ Jito) ให้กับผู้ผลิตบล็อก แทนที่จะเผา 50% - Jito-Solana คือตัวอย่างของ Off-Chain ข้อตกลงที่ใช้โดยผู้ผลิตบล็อก อย่างไรก็ตาม เราทราบว่าทิปของ Jito-Solana นั้นไม่เทียบเท่ากับค่าธรรมเนียมที่มีลำดับความสำคัญ เนื่องจากค่าธรรมเนียมแรกจะได้รับการชำระเงินก็ต่อเมื่อธุรกรรมที่เกี่ยวข้อง (และชุดรวม) ดำเนินการได้สำเร็จเท่านั้น

SIMD-0109 ที่นำเสนอเมื่อเร็วๆ นี้ จะแนะนำกลไกการให้ทิป (คล้ายกับกลไกที่ใช้โดยการประมูลนอกโปรโตคอลของ Jito-Solana) ลงในโปรโตคอลในฐานะคำสั่งดั้งเดิม

ขาดประเภทธุรกรรมสิทธิพิเศษ

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

ที่มา: เซเทริส, โซลานา มหาหินใหญ่

นอกจากนี้ ตรรกะที่คล้ายกันสามารถขยายออกไปเพื่อรวมการอัปเดต Oracle ที่เชื่อถือได้ ซึ่งโดยทั่วไปเครือข่ายจะเรียกเก็บเงิน แม้ว่าฟีดราคาออนไลน์ที่ถูกต้องจะมีค่าภายนอกเป็นบวกก็ตาม ห่วงโซ่ที่มีความเห็นมากกว่าซึ่งได้รับมูลค่าสูงจากออราเคิลที่แข็งแกร่งโดยเฉพาะอาจเลือกที่จะประดิษฐานกลไกที่อุดหนุนต้นทุนของมัน

ตลาดค่าธรรมเนียมท้องถิ่นของโซลานา

มีการประมาณกลไกค่าธรรมเนียมท้องถิ่นของ Solana เนื่องจากไม่มีบัญชีใดที่สามารถเขียนมากกว่า 12M CU ต่อขีดจำกัดบล็อก 48M ควบคู่ไปกับลักษณะแบบมัลติเธรดของตัวกำหนดเวลาเริ่มต้นของ Solana หมายความว่าธุรกรรมสูงสุด 25% ในบล็อกสามารถสอดคล้องกับสถานะที่เป็นที่ต้องการเพียงชิ้นเดียว ตามทฤษฎีแล้ว ผู้ใช้ที่มีสถานะเป็นที่ต้องการน้อยกว่าไม่ควรต้องเพิ่มค่าธรรมเนียมตามลำดับความสำคัญเพื่อการรับประกันการรวมที่แข็งแกร่ง เมื่อเปรียบเทียบกับผู้ใช้ที่มีสถานะเป็นที่ต้องการ

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

การใช้งานและคำขอ CU ที่ไม่มีประสิทธิภาพ

เนื่องจากค่าธรรมเนียมพื้นฐานของ Solana ไม่ได้คิดเป็น CU จึงไม่จูงใจให้ทำธุรกรรมเพื่อ:

1. ใช้ CU อย่างมีประสิทธิภาพ — ธุรกรรมที่มี 1.4M CU จะมีค่าธรรมเนียมพื้นฐานเดียวกันกับธุรกรรมที่มี 100,000 CU ส่วนอย่างอื่นเท่ากัน
2. ร้องขอ CU อย่างมีประสิทธิภาพ — แม้ว่าธุรกรรมจะใช้ 50,000 CU แต่จะมีค่าธรรมเนียมพื้นฐานเท่ากัน ไม่ว่าจะขอ 100,000 CU หรือ 1M CU

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

ไม่มีค่าใช้จ่ายในการเขียนบัญชีล็อค

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

1. ฉันส่ง Tx_A ซึ่งระบุว่าจะเขียนไปยังบัญชี_A
2. ผู้นำได้รับ Tx_A กำหนดเวลา และเริ่มดำเนินการ ขณะนี้บัญชี_A ถูกล็อค - ไม่สามารถดำเนินการธุรกรรมอื่นที่แตะบัญชี_A ได้จนกว่า Tx_A จะดำเนินการเสร็จสิ้น

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

ข้อเสนอและกรอบการทำงานของ TFM

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

ตลาดค่าธรรมเนียม Blockchain หลายมิติ

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

ตัวอย่างเช่น แต่ละ opcode ของ Ethereum มีปริมาณการใช้ก๊าซที่แน่นอน (เช่น ADD ใช้ 3 gas ในขณะที่ MUL ใช้ 5) ราคาก๊าซสำหรับ opcode แต่ละรายการถูกกำหนดเป็นการประมาณคร่าวๆ ของทรัพยากรพื้นฐานที่พวกเขาใช้ และค่าใช้จ่ายที่ถือว่าแพงสำหรับโหนดในเครือข่าย ตัวอย่างเช่น การวัดต้นทุนการดำเนินการโดยนัยนี้สามารถกำหนดได้โดยการรันการวัดประสิทธิภาพบนฮาร์ดแวร์ในโลกแห่งความเป็นจริง

อย่างไรก็ตาม ยังสามารถสร้างตลาดค่าธรรมเนียมหลายมิติที่กำหนดราคาทรัพยากรที่ไม่สามารถทดแทนกันได้เหล่านี้แต่ละรายการ แทนที่จะรวมเป็นหน่วยเดียว EIP-4844 เป็นตลาดค่าธรรมเนียมสองมิติที่ตรงไปตรงมา เนื่องจาก data blobs มีตลาดค่าธรรมเนียมเป็นของตัวเองโดยไม่ขึ้นอยู่กับการดำเนินการของ Ethereum

บทความปี 2022 นี้ โดย Diamandis, Evans, Chitra และ Angeris วิเคราะห์วิธีสร้างตลาดค่าธรรมเนียมหลายมิติเช่นนี้ งานของพวกเขาวางกรอบปัญหาการก่อสร้าง TFM จากมุมมองของนักออกแบบเครือข่ายที่มีจุดมุ่งหมายเพื่อเพิ่มสวัสดิการ (หรืออรรถประโยชน์ทั้งหมด) ของผู้ใช้บล็อกเชนให้สูงสุด ลบด้วยการใช้ทรัพยากรของผู้ใช้ดังกล่าว โดยขึ้นอยู่กับธุรกรรมของเครือข่ายและข้อจำกัดของบล็อก (เช่น ขีดจำกัดสัญญาอัจฉริยะหรือขีดจำกัด CU/ก๊าซ) ผลลัพธ์หลักของรายงานวิจัยนี้คือ แม้จะไม่ทราบสวัสดิการ แต่พวกเขาก็ออกแบบกลไกที่ทำให้เกิดประโยชน์สูงสุด และแสดงวิธีการสร้างกลไกดังกล่าวอย่างชัดเจน

**การเพิ่มสวัสดิการสูงสุด: กฎการจัดสรรและการชำระเงินที่ตั้งใจไว้บ่งบอกว่าผลรวมของส่วนเกินของผู้บริโภคและนักขุดถูกขยายให้ใหญ่สุด (โดยประมาณ)

การค้นพบที่สำคัญของพวกเขาคือสามารถนำไปใช้งาน TFM ที่เทียบเท่าได้ ซึ่งเป็นราคาทรัพยากรที่ถูกตั้งค่าเพื่อลดความแตกต่างระหว่างสวัสดิการของผู้ตรวจสอบและผู้ใช้ - ราคาดังกล่าวควรนำไปสู่การบล็อกซึ่งตามทฤษฎีแล้วจะเหมาะสมที่สุดจากสวัสดิการ - เพิ่มมุมมองให้สูงสุด แม้ว่างานนี้จะถูกมองว่าเป็นกรอบทางวิชาการสำหรับการออกแบบ TFM ที่เหมาะสมที่สุด แต่ก็ช่วยแสดงให้เห็นว่าทรัพยากรการกำหนดราคาที่แยกจากกันสามารถทำให้บล็อกเชนมีประสิทธิภาพมากขึ้นและมีความยืดหยุ่นมากขึ้นในช่วงที่มีความแออัดหรือสแปมสูง กลไกค่าธรรมเนียมพื้นฐานตามตัวควบคุม เช่น EIP-1559 ได้รับการเน้นว่าเป็นแนวทางที่มีศักยภาพซึ่งสามารถทำงานได้ดีเป็นพิเศษบนเครือข่าย Solana และ SVM เมื่อพิจารณาจากระยะเวลาบล็อกที่สั้น ทำให้ค่าธรรมเนียมพื้นฐานสามารถปรับได้อย่างรวดเร็วตามการเปลี่ยนแปลงในความต้องการและทรัพยากรของผู้ใช้ ความพร้อมใช้งาน

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

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

ค่าธรรมเนียมเอ็กซ์โปเนนเชียลสำหรับบัญชีล็อคการเขียน

หลังจากโพสต์ล่าสุด ของ Anatoly เกี่ยวกับ SVM Execution Economics Tao Zhu ร่วมกับ Anatoly ได้เสนอ SIMD-0110 แรงจูงใจหลักคือการยับยั้งสแปมด้วยแรงกดดันทางเศรษฐกิจ (เช่น การเพิ่มค่าธรรมเนียมในลักษณะที่กำหนดเป้าหมายเมื่อเวลาผ่านไป เพื่อลดแรงจูงใจที่จะเป็นสแปม) ส่งผลให้การใช้ทรัพยากรเครือข่ายมีประสิทธิภาพมากขึ้น ธุรกรรมการเก็งกำไรที่ล้มเหลวยังคงเติมเต็ม ประมาณครึ่งหนึ่ง (หรือมากกว่า) ของ Blockspace ของ Solana เนื่องจากสแปมมีเหตุผลและราคาถูกอย่างไม่น่าเชื่อ

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

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

1. ติดตามการใช้งานหน่วยประมวลผล EMA ต่อท้ายของบัญชีที่มีการโต้แย้งในช่วง 150 ช่องที่ผ่านมา
2. จำนวนบัญชีสูงสุดที่จะถูกติดตามคือ 2,048 โดยจะมีการติดตามเฉพาะบัญชีที่มีการถกเถียงกันมากที่สุดซึ่งมีอัตราต้นทุนการล็อกการเขียนสูงสุดเท่านั้น
3. หากการใช้งานหน่วยประมวลผล EMA ของบัญชี >50% ของขีดจำกัด CU สูงสุด อัตราต้นทุนการล็อกการเขียนจะเพิ่มขึ้น X% หากน้อยกว่า 50% ของขีดจำกัด อัตราต้นทุนจะลดลง X%
4. V0 แนะนำอัตราต้นทุนการล็อคการเขียนเริ่มต้นที่ 1,000 ไมโครแลมพอร์ต/CU และอัตราการปรับอัตราต้นทุน 1% ต่อช่อง (โปรดทราบว่าเปอร์เซ็นต์ที่แน่นอนในที่นี้ทั้งหมดอาจมีการเปลี่ยนแปลงเนื่องจากลักษณะของข้อเสนอในช่วงแรกๆ)
5. ค่าธรรมเนียมการล็อกการเขียนสำหรับบัญชีในบล็อกที่กำหนดจะคำนวณโดยการคูณอัตราต้นทุนการล็อกการเขียนด้วย CU ที่ร้องขอของธุรกรรม
6. ธุรกรรมยังคงต้องชำระค่าธรรมเนียมลายเซ็น และค่าธรรมเนียมลำดับความสำคัญที่เป็นตัวเลือกยังคงอยู่
7. ค่าธรรมเนียมการล็อคการเขียนที่รวบรวมจะถูกเผา 100%
8. ค่าธรรมเนียมลำดับความสำคัญที่รวบรวมไว้จะได้รับรางวัล 100%
9. ค่าธรรมเนียมลายเซ็นที่เรียกเก็บจะถูกเผา 50% และได้รับรางวัล 50%

ข้อเสนอนี้จะทำให้ฟีเจอร์ล็อคการเขียนของ Solana (ปกติ) DSIC คล้ายกับวิธีที่ EIP-1559 สร้าง TFM ของ Ethereum (ปกติ) DSIC และ MMIC [Rou23] — ยกเว้นในกรณีที่มีค่าธรรมเนียมพุ่งสูงขึ้นอย่างกะทันหัน

เราสามารถกำหนดคุณสมบัติ MMIC ได้ดังนี้:

**ความเข้ากันได้ของ Myopic Miner Incentive (MMIC): ผู้ผลิตบล็อกจะเพิ่มประโยชน์สูงสุดโดยการสร้างธุรกรรมที่ไม่ปลอมและปฏิบัติตามกฎที่ระบุไว้ของ TFM สายตาสั้นหมายถึงเป้าหมายนี้เกี่ยวข้องกับบล็อกปัจจุบันเท่านั้นเมื่อพิจารณาการเพิ่มอรรถประโยชน์สูงสุด [Rou21]

กลไกการต่อท้ายใด ๆ นั้นไม่สมบูรณ์เนื่องจากอาจไม่สามารถแสดงสถานะปัจจุบันของความต้องการได้อย่างแม่นยำ ตัวอย่างเช่น ความต้องการอาจต่ำเป็นระยะเวลานาน (และด้วยเหตุนี้ ค่าธรรมเนียมพื้นฐานแบบไดนามิกจึงต่ำ) จากนั้นจึงพุ่งสูงขึ้นอย่างกะทันหันสำหรับ NFT mint นี่อาจเป็นกรณีในระดับโลก (เช่นใน TFM ของ Ethereum) และอาจมีความผันผวนมากขึ้นในระดับต่อบัญชีท้องถิ่น (ตามที่พิจารณาใน SIMD-0110)

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

ความจริงที่ว่าค่าธรรมเนียมการล็อกการเขียนนี้ถูกเรียกเก็บจาก CU ที่ร้องขอ ยังจูงใจผู้ใช้และนักพัฒนาให้ประเมินการใช้งาน CU ของธุรกรรมได้อย่างถูกต้องอีกด้วย วิธีนี้จะช่วยหลีกเลี่ยงปัญหาที่เราได้พูดคุยกันก่อนหน้านี้ ซึ่งฐานลายเซ็นแบบแบนในปัจจุบันไม่มีบทลงโทษสำหรับการขอ CU มากกว่าที่จำเป็น (แม้จะสูงสุดถึง CU สูงสุด 1.4 มม.) มิฉะนั้น เฉพาะค่าธรรมเนียมลำดับความสำคัญเท่านั้นที่จะมีสิ่งจูงใจนี้ในวันนี้ (เนื่องจาก CU ร้องขอด้วย)

ข้อวิพากษ์วิจารณ์ที่อาจเกิดขึ้นประการหนึ่งคือตลาดค่าธรรมเนียมท้องถิ่นตามบัญชี (โดยเฉพาะข้อเสนอนี้ ซึ่งต้องมีการคำนวณ EMA ต่อเนื่องสำหรับทุกบัญชี) อาจมีราคาแพงในการคำนวณ ค่าธรรมเนียมหลายมิติประเภทนี้ไม่มีขอบเขต เนื่องจากบัญชีใดๆ ก็ตามสามารถถูกอัดแน่นได้ ซึ่งอาจจะสร้างปัญหาให้กับ TFM ดังกล่าว อย่างไรก็ตาม ในกรณีของ SIMD-0110 สิ่งนี้สามารถหลีกเลี่ยงได้โดยการตั้งค่าขีดจำกัดสูงสุดสำหรับจำนวนบัญชีที่สามารถติดตามการใช้งาน CU EMA ในเวลาที่กำหนด

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

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

การเปลี่ยนแปลงตัวกำหนดเวลาเริ่มต้นของ Solana

ตามที่กล่าวไว้ข้างต้น “ตัวกำหนดเวลา” คืออัลกอริธึมเริ่มต้นที่รวมอยู่ใน ไคลเอนต์ตรวจสอบความถูกต้องของ Solana Labs ซึ่งจัดกำหนดการธุรกรรมสำหรับการดำเนินการและสร้างบล็อกอย่างต่อเนื่อง มันมีบทบาทสำคัญอย่างไม่น่าเชื่อในตลาดค่าธรรมเนียมของ Solana แม้ว่าพฤติกรรมเริ่มต้นจะไม่ถูกบังคับใช้ในโปรโตคอล เนื่องจากผู้ตรวจสอบอาจเลือกที่จะเรียกใช้อัลกอริธึมอื่น ๆ เราจะเน้นที่ตัวกำหนดเวลาปัจจุบันและการเปลี่ยนแปลงที่เสนอที่กำลังจะเกิดขึ้น ซึ่ง Andrew Fitzgerald ดำเนินการอยู่

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

ที่มา: Andrew Fitzgerald, Solana Banking Stage และ Scheduler

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

จุดสำคัญของการอัพเกรดเป็นตัวกำหนดเวลาเริ่มต้นของ Solana อยู่ที่การเปลี่ยนจากแนวทางเดิม (ชื่อโหมด ThreadLocalMultiIterator) ไปเป็นแนวทางใหม่ในการกำหนดเวลา โดยมีชื่อว่าโหมด CentralScheduler บทความนี้จะให้ภาพรวมและการวิเคราะห์การเปลี่ยนแปลงเท่านั้น อย่างไรก็ตาม สามารถดูข้อมูลเพิ่มเติมได้ใน บทความ ของ Andrew Fitzgerald และ <a href="https://medium.com/@harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7"> บล็อกโพสต์โดยสรุปประกอบโดย Harsh Patel จากทีม Tiny Dancer ภาพรวมของกระบวนการจัดกำหนดการใหม่แสดงอยู่ด้านล่าง

ที่มา: Andrew Fitzgerald, Solana Banking Stage และ Scheduler

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

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

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

ค่าธรรมเนียมการเขียนบัญชีที่สามารถคืนเงินได้ (PRAW) ของโปรแกรม

ประพันธ์โดย Godmode Galactus และ Max Schneider SIMD-0016 เสนอค่าธรรมเนียมการเขียนบัญชีที่สามารถคืนเงินได้ (PRAW) ของโปรแกรม พวกเขาจะให้การควบคุมที่สำคัญแก่นักพัฒนาแอปพลิเคชัน เนื่องจากพวกเขาสามารถกำหนดเกณฑ์ในการชำระเงินและการคืนค่าธรรมเนียมเหล่านี้ ทำให้พวกเขาสามารถจูงใจและไม่จูงใจพฤติกรรมของผู้ใช้ตามที่เห็นสมควร

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

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

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

สมาชิกของชุมชน Solana แจ้งปัญหาเกี่ยวกับข้อเสนอนี้: ความสามารถของโปรแกรมต่างๆ ในการทำงานแบบอัตโนมัติโดยสิ้นเชิงนั้นดูไม่ดีนัก และความสามารถในการประเมินค่าธรรมเนียมอย่างแม่นยำอาจเป็นเรื่องยาก ยิ่งไปกว่านั้น ยังมีวิธีที่ง่ายกว่าและสม่ำเสมอกว่าในการจัดการกับปัญหาความโศกเศร้าเหล่านี้เกี่ยวกับบัญชีที่ถูกล็อคการเขียน เช่น SIMD-0110

**Griefing Resistance: กลุ่มย่อยของ DSIC ที่ผู้ใช้ไม่ได้รับแรงจูงใจให้บิดเบือนรายการเข้าถึงของตน — ระบุทรัพยากรที่จำเป็นสำหรับการทำธุรกรรมอย่างไม่ถูกต้อง [Gar23]

ข้อเสนอ PRAW อาจล้มเหลวในการป้องกันสแปม เนื่องจากต้องอาศัยนักพัฒนาแอปพลิเคชันอย่างเพียงพอ: 1) สามารถแยกสแปมออกจาก "พฤติกรรมปกติ" และ 2) เลือกที่จะเรียกเก็บเงินเพิ่มโดยสมัครใจสำหรับผลกระทบภายนอกเชิงลบที่พวกเขาต้องรับผิดชอบบางส่วน เมื่ออาจไม่เป็นเช่นนั้น เป็นประโยชน์สูงสุดแก่พวกเขาที่จะทำเช่นนั้น และพวกเขาก็สามารถเลือกที่จะไม่ทำก็ได้

ในทางตรงกันข้าม แม้ว่าสมาชิกของชุมชนการวิจัยของ Solana จะแตกแยกกันอย่างปฏิเสธไม่ได้ในเรื่องค่าธรรมเนียมฐาน EMA แต่โดยทั่วไปก็มีข้อตกลงเกี่ยวกับการเพิ่มส่วนประกอบของค่าธรรมเนียมพื้นฐานบางส่วนซึ่งปรับขนาดตาม CU สิ่งนี้สามารถจูงใจการประมาณค่า CU ที่แม่นยำและการใช้งาน CU อย่างมีประสิทธิภาพโดยนักพัฒนา

ความคิดที่พรากจากกัน

เป้าหมายด้านวิศวกรรมและประสิทธิภาพที่เป็นเอกลักษณ์ของ Solana จำเป็นต้องคำนึงถึง TFM ที่เป็นเอกลักษณ์ แน่นอนว่าการย้ายตลาดค่าธรรมเนียมที่มีอยู่ของ Ethereum ไปยัง Solana แน่นอนว่าไม่ใช่วิธีแก้ปัญหาที่นี่ แต่มีบทเรียนอันมีค่าที่ต้องเรียนรู้จากสิ่งนี้ สิ่งนี้มีความเกี่ยวข้องอย่างมากกับกลไกที่มีทั้ง:

1. ในโปรโตคอล - TFM ที่บังคับใช้ฉันทามติ (เช่น EIP-1559 และ SIMD-0110)
2. นอกโปรโตคอล - PBS ผ่าน MEV-Boost, การปรับปรุงตัวกำหนดเวลา Solana และการประมูล Jito

สำหรับทั้ง Solana และ Ethereum กลไกในโปรโตคอลและนอกโปรโตคอลดูเหมือนจะมีแนวโน้มที่จะอยู่ร่วมกันและพัฒนาร่วมกันในอนาคต ความสมดุลระหว่างสิ่งเหล่านี้เป็นหนึ่งในคำถามพื้นฐานในการออกแบบระบบเหล่านี้ การถกเถียงรอบ SIMD-0110 มักมีศูนย์กลางอยู่ที่มุมมองที่ขัดแย้งกันสองประการ:

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

การกำหนดราคาทรัพยากรหลายมิติในบางรูปแบบก็มีคุณค่าอย่างชัดเจนในทั้งสองกรณีเช่นกัน Ethereum กำลังเริ่มดำเนินการตาม TFM ในระดับทรัพยากรพื้นฐาน โดย EIP-4844 จะแยกข้อมูล Blob ออกจากตลาดการดำเนินการ ในทางกลับกัน Solana กำลังผลักดันการกำหนดราคาทรัพยากรหลายมิติในระดับบัญชีบุคคลเพื่อบุกเบิก "ตลาดค่าธรรมเนียมท้องถิ่น"

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

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

ข้อสงวนสิทธิ์：

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