Phân tích: Hồ sơ phần thưởng Solana bỏ sót tỷ lệ hoa hồng, khiến việc kiểm tra phí phức tạp hơn

Phần mềm Agave của Solana không ghi tỷ lệ hoa hồng vào siêu dữ liệu phần thưởng khi các bộ thu thập tùy chỉnh được kích hoạt, dù khoản chi trả staking vẫn có thể hiển thị. P2P.org cho biết trong báo cáo ngày 30 tháng 10 rằng hồ sơ phần thưởng biểu quyết và staking không có mục hoa hồng kể từ ngày 8 tháng 9. P2P.org cho biết các validator vẫn tiếp tục thu hoa hồng và số tiền thưởng vẫn khớp. Vấn đề liên quan đến bằng chứng cần thiết để giải thích các khoản chi trả, chứ không phải tình trạng thiếu hụt khoản chi trả đã được xác định. P2P.org có lợi ích thương mại trong vấn đề này vì nhà cung cấp tiếp thị các dịch vụ staking và báo cáo.

Pull request Agave #12588, được hợp nhất ngày 20 tháng 5, quy định việc bỏ sót thông tin sau khi các bộ thu thập tùy chỉnh được kích hoạt, áp dụng cho hoa hồng validator tích lũy và phần thưởng của từng khoản stake. Thông tin phần thưởng bị ảnh hưởng được cung cấp cho người dùng qua các truy vấn và đăng ký khối. Mã tính toán của Agave tiếp tục đưa hoa hồng vào phép tính phần thưởng trước khi loại tỷ lệ này khỏi hồ sơ kết quả. Vì vậy, tỷ lệ không xuất hiện có nghĩa là thiếu siêu dữ liệu, chứ không phải mức hoa hồng bằng 0. SIMD-0232 cho phép validator chuyển thu nhập hoa hồng vào các tài khoản thu thập được chỉ định mà không thay đổi cách tính hoa hồng lạm phát.

Pull request giải thích rằng phần thưởng tích lũy có thể gộp thu nhập được chuyển vào một tài khoản thu thập, nên một tỷ lệ hoa hồng có thể không mô tả đầy đủ tổng số tiền. Tuy nhiên, cách triển khai cũng loại bỏ tỷ lệ khỏi phần thưởng của từng khoản stake, làm giảm bằng chứng sẵn có để kiểm tra một tài khoản stake riêng lẻ. Việc Solana áp dụng thay đổi hoa hồng có độ trễ khiến tỷ lệ lịch sử trở nên cần thiết cho việc xác minh. Theo SIMD-0249, phần thưởng kiếm được trong epoch E thường sử dụng tỷ lệ được ghi nhận khi epoch E-1 bắt đầu, còn việc tính toán diễn ra khi epoch E+1 bắt đầu. Tài khoản biểu quyết mới tạo có thể sử dụng trạng thái tài khoản về sau nếu không có dữ liệu lịch sử trước đó cần thiết. Do đó, thiết lập mới nhất của một validator có thể khác với tỷ lệ áp dụng cho khoản chi trả cũ hơn.

Một cuộc thảo luận kỹ thuật ngày 16 tháng 7 xác định thông tin về hoa hồng hiệu lực và tài khoản thu thập trong trạng thái runtime được lưu trong bộ nhớ đệm, vốn không thể đọc qua các truy vấn tài khoản thông thường. Các nhà phát triển cho biết quy tắc trì hoãn hoa hồng đã hoạt động trên mainnet và thảo luận việc tách riêng xử lý sự phụ thuộc vào trạng thái được lưu trong bộ nhớ đệm. Cộng tác viên Agave ax-x2 gửi yêu cầu RPC ngày 18 tháng 10, giải thích rằng getVoteAccounts và dữ liệu tài khoản biểu quyết đã phân tích chỉ hiển thị thiết lập mới nhất, dù phép tính phần thưởng có thể sử dụng tỷ lệ đã lưu. Yêu cầu đề xuất một phản hồi tùy chọn hiển thị hoa hồng lạm phát hiệu lực, epoch liên quan và vị trí bank. Đến ngày 30 tháng 10, yêu cầu vẫn đang mở và chưa có triển khai nào được liên kết. Ví dụ minh họa trong yêu cầu ghép một tỷ lệ hiển thị thấp với một tỷ lệ đã lưu cao, nhưng không xác định sự cố validator nào đã xảy ra và cũng không chứng minh có tình trạng thu quá mức.

Việc kiểm tra hoa hồng trong quá khứ đòi hỏi đối chiếu kỳ nhận phần thưởng, ủy quyền validator của tài khoản stake và tỷ lệ được chọn theo quy tắc lịch sử áp dụng. Chương trình Validator History của Jito ghi lại lịch sử hoa hồng và thông tin khác của validator, bao phủ tối đa 512 epoch cho mỗi validator. Chỉ dẫn sao chép của Jito ghi lại hoa hồng của tài khoản biểu quyết cùng epoch và vị trí, nhưng riêng dữ liệu quan sát đó không xác lập được tỷ lệ hiệu lực có độ trễ cho một khoản chi trả cụ thể. Bộ phân tích cú pháp snapshot của Marinade truy cập thông tin được lưu trong bộ nhớ đệm trực tiếp hơn bằng cách trích xuất hoa hồng lạm phát từ snapshot epoch-stakes và công bố thời điểm của giá trị cùng các bộ đếm dự phòng. Marinade lưu ý rằng ranh giới kho lưu trữ và các tệp đầu ra cũ hơn không có siêu dữ liệu về thời điểm có thể hạn chế việc diễn giải các tỷ lệ đã lưu. Bộ phân tích cú pháp này cung cấp một phương pháp tái dựng, chứ không đảm bảo kho lưu trữ đầy đủ cho mọi tài khoản và epoch.

Phương pháp tính APY của Trillium đo lợi nhuận từ lạm phát thông qua mức tăng trưởng của tài khoản stake kể từ epoch 1070, áp dụng các bước kiểm tra điều kiện hợp lệ và phương án dự phòng RPC thay vì dựa vào tỷ lệ hoa hồng hiển thị. Trillium sử dụng các phương pháp khác cho những epoch trước đó. Vì vậy, thu nhập ròng vẫn có thể đo lường được mà không cần xác minh độc lập khoản hoa hồng tạo ra thu nhập đó. Trillium coi việc thiếu bằng chứng tài khoản phù hợp là kết quả chưa xác định, chứ không phải bằng 0. Hồ sơ thu nhập hữu ích cho người nắm giữ SOL hoặc các sản phẩm staking sẽ liên kết phần thưởng ròng với kỳ liên quan, ủy quyền validator và bằng chứng về hoa hồng hiệu lực, đồng thời công bố các giới hạn trong việc tái dựng hoặc lấy mẫu.

Một cuộc thảo luận về trạng thái biểu quyết trong tháng 10 đề xuất lưu giữ tỷ lệ hoa hồng cùng các epoch mà những tỷ lệ đó bắt đầu có hiệu lực. Đề xuất về trạng thái biểu quyết và yêu cầu RPC đang mở vẫn là các biện pháp khắc phục được đề xuất, chứ chưa phải bằng chứng về một bản sửa lỗi đã triển khai. Hoa hồng lạm phát, hoa hồng MEV và chia sẻ doanh thu khối là những thành phần riêng biệt, nên việc làm hiển thị một tỷ lệ sẽ không giải thích toàn bộ lợi nhuận staking. Phạm vi đưa tin hồi tháng 9 về tín dụng biểu quyết gắn với phần thưởng cũng cho thấy chỉ riêng các phép đo hiệu suất không thể định lượng khoản SOL mà một người nắm giữ riêng lẻ bị mất nếu thiếu bằng chứng ở cấp tài khoản. Người nắm giữ muốn kiểm tra các tỷ lệ hoa hồng bị lược bỏ cần đối chiếu khoản chi trả với bằng chứng lịch sử có thời điểm và phạm vi dữ liệu kiểm chứng được.