โซลานา(SOL) เปิดโหวต SIMD-0553 ปรับค่าธรรมเนียมตามทรัพยากรที่ขอใช้

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

เอกสารปรับปรุงโซลานา SIMD-0553 เสนอให้แบ่งค่าธรรมเนียมพื้นฐานที่ปัจจุบันอยู่ที่ 5,000 แลมพอร์ต(lamport) ต่อหนึ่งลายเซ็น ออกเป็นค่าธรรมเนียมพื้นฐานคงที่ 2,500 แลมพอร์ต กับค่าธรรมเนียมทรัพยากร (resource fee) ที่คำนวณตามทรัพยากรที่ขอใช้ ค่าธรรมเนียมทรัพยากรคำนวณตามสัดส่วนของ requested_cost_units และถูก 'เผา' (burn) ทั้งหมด ส่วนค่าธรรมเนียมความสำคัญ (priority fee) ยังคงเป็นของผู้ตรวจสอบ (validator) เช่นเดิม

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

หัวใจของข้อเสนอนี้ไม่ใช่แค่การขึ้นค่าธรรมเนียม แต่เป็นการทำให้ราคาสะท้อนทรัพยากรที่ธุรกรรมเรียกใช้จากเครือข่ายอย่างละเอียดขึ้น ที่ผ่านมาค่าธรรมเนียมพื้นฐานเน้นคิดจากต้นทุนการตรวจสอบลายเซ็นเป็นหลัก แต่ข้อเสนอใหม่จะนำการล็อกการเขียน (write lock) ข้อมูลคำสั่ง (instruction data) การประมวลผลโปรแกรม และขนาดข้อมูลบัญชีที่โหลด (loaded account data) เข้ามาเป็นเกณฑ์คิดค่าธรรมเนียมด้วย

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

ข้อเสนอนี้วางโครงสร้าง feature gate ให้ปรับอัตราค่าธรรมเนียมทรัพยากรขึ้นเป็นขั้น ๆ ที่ 1/10, 1/4 และ 1/2 แลมพอร์ต แทนที่จะบังคับใช้อัตราสุดท้ายทันที นั่นหมายความว่าการออกแบบนี้วางอยู่บนสมมติฐานการทยอยเปิดใช้งาน อย่างไรก็ตาม การที่เอกสารได้รับการยอมรับ (accepted) ไม่ได้แปลว่าจะถูกนำไปใช้บนเมนเน็ตทันที

Crypto Briefing รายงานผลจำลองสถานการณ์ว่า หากใช้อัตราค่าธรรมเนียมสุดท้าย ปริมาณโซลานา(SOL) ที่ถูกเผาต่อวันอาจเพิ่มจากราว 648 SOL เป็นช่วง 1,500-9,000 SOL รายงานเดียวกันระบุว่าแอปพลิเคชันและเราท์เตอร์ที่มีโหลดสูงอย่าง Jupiter, Titan และ DFlow อาจเผชิญแรงกดดันให้ค่าธรรมเนียมเฉลี่ยเพิ่มขึ้น ทั้งนี้ ตัวเลขดังกล่าวเป็นค่าประมาณจากแบบจำลอง ไม่ใช่ผลที่เกิดขึ้นจริง

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

โซลานาคอมพานี (Solana Company) ประกาศเมื่อวันที่ 21 สิงหาคม ว่าคัดค้าน SGP-0003 โดยให้เหตุผลว่าค่าธรรมเนียมคงที่ช่วยให้ผู้ใช้งานระดับสถาบันวางแผนงบประมาณได้ง่ายกว่า และหากทำให้ต้นทุนธุรกรรมผันแปรก่อนที่ระบบนิเวศจะปรับตัวทัน ความเสี่ยงด้านการประเมินต้นทุนจะตกไปอยู่กับผู้ใช้และผู้ดำเนินการ

การถกเถียงครั้งนี้เชื่อมโยงเอกสารเทคนิค SIMD-0553 เข้ากับข้อเสนอธรรมาภิบาล SGP-0003 โดย SIMD ว่าด้วยวิธีคำนวณค่าธรรมเนียมโดยตรง ส่วน SGP เป็นการโหวตส่งสัญญาณบนเชนว่าเครือข่ายควรเดินไปในทิศทางนั้นหรือไม่ เอกสารธรรมาภิบาลของโซลานาระบุว่า SGP จะเข้าสู่ขั้นตอนการโหวตอย่างเป็นทางการเมื่อได้รับการสนับสนุนจากสัดส่วนหุ้น (stake) ที่ยังทำงานอยู่อย่างน้อย 15%

ประกาศอัปเดตสำหรับนักพัฒนาของโซลานาระบุเมื่อวันที่ 23 กรกฎาคม ว่าเอกสาร Resource and Inclusion Fees SIMD ได้รับสถานะ 'accepted' แล้ว ซึ่งหมายถึงเอกสารได้รับการยอมรับ แต่ไม่ได้กำหนดวันเปิดใช้งานจริงบนเมนเน็ตหรือวัน feature gate มีผล ขณะที่ Validator Info ระบุสถานะของ SGP-0003 ว่าอยู่ระหว่าง 'Voting'

กำหนดเวลาปิดโหวตยังไม่ตรงกันระหว่างแหล่งข้อมูล บางแหล่งระบุเวลาที่แปลงเป็นเวลาประเทศไทยแล้วตกราว 22:30 น. ของวันที่ 26 ขณะที่บางแหล่งระบุว่าปิดโหวตวันที่ 27 หรือ 28 ณ ช่วงเวลาที่เขียนข่าวนี้ ยังไม่สามารถยืนยันกำหนดเวลาปิดโหวตที่แน่นอนเป็นค่าเดียวได้

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

โซลานาคอมพานีประกาศเมื่อวันที่ 21 สิงหาคมเช่นกันว่า สนับสนุน SGP-0001 แต่คัดค้าน SGP-0003 ประเด็นถกเถียงจึงไม่ได้อยู่ที่ความจำเป็นในการปรับโครงสร้างเศรษฐกิจของเครือข่ายในตัวมันเอง แต่อยู่ที่จังหวะเวลาและความสามารถในการคาดการณ์ต้นทุนมากกว่า

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