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

ข้อเสนอนี้คืออะไร

รายงานจาก CryptoSlate ระบุว่าคำขอรวมโค้ดของ SIMD-0649 ถูกปิดเมื่อวันที่ 25 กันยายน โดยยังไม่ถูกควบรวมเป็นกฎที่ใช้งานจริง ข้อเสนอเดิมต้องการให้ผู้ตรวจสอบบล็อกหรือ validator ปฏิเสธบล็อกได้ หากธุรกรรมภายในกลุ่มรายการหรือ entry batch เดียวกันถูกบันทึกโดยลำดับคะแนนความสำคัญของค่าธรรมเนียมไม่เรียงจากสูงไปต่ำหรือเท่ากันอย่างเป็นระบบ แต่ไม่ได้กำหนดว่าธุรกรรมใดควรอยู่ในบล็อกนั้น จึงเหลือเพียงประเด็นที่ต้องถกเถียงต่อ แทนการบังคับใช้กฎการจัดลำดับใหม่ทันที

ทำไมจึงสำคัญต่อการส่งคำสั่ง

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

กฎไม่ได้สร้างแถวรอทั้งสล็อต

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

คะแนนความสำคัญคำนวณอย่างไร

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

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

ช่องว่างที่ร่างพยายามปิด

ร่างยังกันไม่ให้ leader ทำให้กฎไร้ความหมายด้วยการสร้างกลุ่มรายการเล็กมากจนไม่มีอะไรให้เปรียบเทียบ จึงกำหนดให้กลุ่มก่อนกลุ่มสุดท้ายต้องครอบคลุมอย่างน้อย 2 ชุด FEC ซึ่งเป็นกลุ่มของแพ็กเก็ตข้อมูลที่เรียกว่า shreds ตามกฎขนาด FEC ที่ร่างอ้างอิง ข้อนี้หมายความว่าต้องมีอย่างน้อย 64 data shreds ส่วนกลุ่มสุดท้ายยังต้องผ่านการตรวจสอบลำดับ แต่ได้รับยกเว้นขั้นต่ำด้านขนาด เพราะสล็อตอาจจบก่อนจะเต็ม

ข้อถกเถียงที่ยังไม่จบ

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

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

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

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

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

บริบทด้านค่าธรรมเนียมและความเร็ว

รายงานที่เกี่ยวข้องยังอ้างถึงประเด็น Solana กลับด้าน Ethereum ในค่าธรรมเนียม ขณะที่ ETH ยังนำด้านการเผา รวมถึงการถกเถียงเรื่องความเร็ว 300ms เพื่อแข่งกับบอตซื้อขาย และข้อกังวลว่าการเร่งความเร็ว 250ms อาจกระตุ้นความไม่เสถียรของเครือข่าย

ผู้อ่านควรรู้อะไร

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

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