วิเคราะห์: ซอฟต์แวร์ Solana Agave ไม่บันทึกอัตราคอมมิชชันในข้อมูลรางวัล ทำให้ตรวจสอบค่าธรรมเนียมซับซ้อนขึ้น

ซอฟต์แวร์ Agave ของ Solana ไม่บันทึกอัตราคอมมิชชันไว้ในข้อมูลกำกับรางวัลเมื่อมีการใช้ตัวรวบรวมแบบกำหนดเอง แม้ข้อมูลการจ่ายผลตอบแทนจาก staking อาจยังปรากฏอยู่ P2P.org ระบุในรายงานวันที่ 30 ตุลาคมว่า บันทึกรางวัลการโหวตและ staking ไม่มีรายการคอมมิชชันมาตั้งแต่วันที่ 8 กันยายน P2P.org ระบุว่า validator ยังคงเรียกเก็บคอมมิชชัน และยอดรางวัลยังคำนวณสอดคล้องกัน ปัญหานี้เกี่ยวข้องกับหลักฐานที่จำเป็นต่อการอธิบายการจ่ายผลตอบแทน ไม่ใช่การพบว่ามีการจ่ายผลตอบแทนขาดไป P2P.org มีผลประโยชน์เชิงพาณิชย์ในประเด็นนี้ เนื่องจากผู้ให้บริการทำการตลาดบริการ staking และการรายงานข้อมูล

Pull request #12588 ของ Agave ซึ่งถูกรวมเมื่อวันที่ 20 พฤษภาคม ระบุว่าข้อมูลจะไม่แสดงอัตราคอมมิชชันหลังเปิดใช้ตัวรวบรวมแบบกำหนดเอง โดยครอบคลุมทั้งคอมมิชชันสะสมของ validator และรางวัลของแต่ละ stake ข้อมูลรางวัลที่ได้รับผลกระทบส่งถึงผู้ใช้ผ่านการเรียกดูบล็อกและการสมัครรับข้อมูล โค้ดคำนวณของ Agave ยังคงนำคอมมิชชันไปใช้คำนวณรางวัล ก่อนตัดอัตราดังกล่าวออกจากบันทึกผลลัพธ์ ดังนั้น การไม่มีอัตราแสดงอยู่จึงหมายถึงข้อมูลกำกับขาดหาย ไม่ใช่การเรียกเก็บคอมมิชชันเป็นศูนย์ SIMD-0232 อนุญาตให้ validator ส่งรายได้จากคอมมิชชันไปยังบัญชีรับเงินที่กำหนดไว้ โดยไม่เปลี่ยนวิธีคำนวณคอมมิชชันจากเงินเฟ้อ

Pull request อธิบายว่ารางวัลสะสมอาจรวมรายได้ที่ส่งไปยังตัวรวบรวม ทำให้อัตราคอมมิชชันเพียงค่าเดียวอาจอธิบายยอดรวมได้ไม่เพียงพอ อย่างไรก็ตาม การใช้งานดังกล่าวยังตัดอัตราออกจากรางวัลของแต่ละ stake ด้วย ทำให้หลักฐานสำหรับตรวจสอบบัญชี stake รายบัญชีมีน้อยลง การที่ Solana ใช้อัตราคอมมิชชันที่เปลี่ยนแปลงล่าช้าทำให้ต้องใช้อัตราย้อนหลังในการตรวจสอบ ภายใต้ SIMD-0249 โดยปกติรางวัลที่ได้รับใน epoch E จะใช้อัตราที่บันทึกไว้เมื่อเริ่ม epoch E-1 และคำนวณเมื่อเริ่ม epoch E+1 บัญชี vote ที่สร้างขึ้นใหม่อาจใช้อ้างอิงสถานะบัญชีในเวลาต่อมา เมื่อไม่มีประวัติย้อนหลังที่จำเป็น ดังนั้น การตั้งค่าล่าสุดของ validator จึงอาจต่างจากอัตราที่ใช้กับการจ่ายผลตอบแทนก่อนหน้า

การหารือด้านวิศวกรรมเมื่อวันที่ 16 กรกฎาคมระบุว่าข้อมูลคอมมิชชันที่มีผลบังคับใช้และข้อมูลตัวรวบรวมอยู่ในสถานะ runtime ที่แคชไว้ ซึ่งการอ่านบัญชีตามปกติไม่สามารถเปิดเผยได้ นักพัฒนากล่าวว่ากฎการหน่วงเวลาคอมมิชชันใช้งานบน mainnet อยู่แล้ว และหารือแยกต่างหากถึงการแก้ปัญหาการพึ่งพาสถานะที่แคชไว้ ผู้ร่วมพัฒนา Agave ชื่อ ax-x2 ยื่นคำขอเกี่ยวกับ RPC เมื่อวันที่ 18 ตุลาคม โดยอธิบายว่า getVoteAccounts และข้อมูลบัญชี vote ที่แยกวิเคราะห์แล้วแสดงการตั้งค่าล่าสุด แม้การคำนวณรางวัลอาจใช้อัตราที่บันทึกไว้ คำขอเสนอให้เพิ่มการตอบกลับทางเลือกที่แสดงคอมมิชชันจากเงินเฟ้อซึ่งมีผลบังคับใช้ epoch ที่เกี่ยวข้อง และ bank slot คำขอยังเปิดอยู่เมื่อวันที่ 30 ตุลาคม โดยไม่มีการเชื่อมโยงกับการนำไปใช้งาน ตัวอย่างในคำขอแสดงอัตราที่ปรากฏต่ำควบคู่กับอัตราที่บันทึกไว้สูง แต่ไม่ได้ระบุเหตุการณ์ที่เกิดขึ้นจริงกับ validator รายใด และไม่ได้ยืนยันว่ามีการเรียกเก็บเงินเกิน

การตรวจสอบคอมมิชชันย้อนหลังต้องจับคู่ช่วงเวลาของรางวัล การมอบหมาย validator ให้บัญชี stake และอัตราที่เลือกใช้ตามกฎย้อนหลังที่เกี่ยวข้อง เอกสารของ Validator History Program จาก Jito ระบุว่ามีประวัติคอมมิชชันและข้อมูลอื่นของ validator ย้อนหลังได้สูงสุด 512 epoch ต่อ validator คำสั่งคัดลอกของ Jito บันทึกคอมมิชชันของบัญชี vote พร้อม epoch และ slot แต่ข้อมูลที่บันทึกไว้เพียงอย่างเดียวไม่สามารถยืนยันอัตราที่มีผลบังคับใช้แบบหน่วงเวลาสำหรับการจ่ายผลตอบแทนรายการใดรายการหนึ่งได้ ตัวแยกวิเคราะห์ snapshot ของ Marinade เข้าถึงข้อมูลที่แคชไว้ได้โดยตรงกว่า ด้วยการดึงคอมมิชชันจากเงินเฟ้อจาก snapshot ของ epoch-stakes และเผยแพร่ข้อมูลรุ่นของค่าดังกล่าวกับตัวนับการใช้ค่าทดแทน Marinade เตือนว่าขอบเขตของคลังข้อมูลย้อนหลังและไฟล์ผลลัพธ์รุ่นเก่าที่ไม่มีข้อมูลรุ่นของค่าจำกัดการตีความอัตราที่จัดเก็บไว้ ตัวแยกวิเคราะห์นี้เป็นเทคนิคสำหรับสร้างข้อมูลย้อนหลังขึ้นใหม่ ไม่ใช่การรับประกันว่ามีคลังข้อมูลครบถ้วนสำหรับทุกบัญชีและทุก epoch

วิธีคำนวณ APY ของ Trillium วัดผลตอบแทนจากเงินเฟ้อผ่านการเติบโตของบัญชี stake ตั้งแต่ epoch 1070 เป็นต้นไป โดยใช้การตรวจสอบคุณสมบัติและข้อมูลสำรองจาก RPC แทนการใช้อัตราคอมมิชชันที่แสดงอยู่ Trillium ใช้วิธีอื่นสำหรับ epoch ก่อนหน้านั้น ดังนั้นจึงยังวัดรายได้สุทธิได้ โดยไม่สามารถตรวจสอบคอมมิชชันที่ทำให้เกิดรายได้นั้นได้อย่างเป็นอิสระ Trillium ระบุว่าหากไม่มีหลักฐานจากบัญชีที่เหมาะสม จะถือว่าผลลัพธ์ไม่ทราบค่า แทนที่จะเป็นศูนย์ บันทึกรายได้ที่เป็นประโยชน์ต่อผู้ถือ SOL หรือผลิตภัณฑ์ staking ควรเชื่อมโยงรางวัลสุทธิกับช่วงเวลาที่เกี่ยวข้อง การมอบหมาย validator และหลักฐานคอมมิชชันที่มีผลบังคับใช้ พร้อมเปิดเผยข้อจำกัดด้านการสร้างข้อมูลย้อนหลังหรือการสุ่มตัวอย่าง

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