Phân tích: Thay thế nonce của Solana có thể giữ nguyên phê duyệt sau giao dịch thất bại

Kế hoạch tháng 10 của Solana Foundation đề xuất thay nonce bền vững bằng các chương trình ký trên chuỗi, có chức năng xác minh chữ ký ngoại tuyến và thực thi chỉ thị đã được phê duyệt. Một địa chỉ được tạo từ chương trình (PDA) sẽ kiểm soát các tài khoản liên quan, trong khi khóa gốc phê duyệt hành động và một đơn vị vận hành trực tuyến riêng gửi giao dịch, đồng thời trả phí mạng. Các sàn giao dịch, đơn vị lưu ký và đơn vị vận hành ngân quỹ sẽ cần chuyển tài sản hoặc quyền hạn, bảo đảm ứng dụng chấp nhận quy trình thực thi mới và được nhóm quản lý rủi ro phê duyệt.

Nonce bền vững vẫn có thể sử dụng; Foundation chưa ấn định ngày loại bỏ cũng chưa chọn giữa Programmatic Signer của Anza và Vector của Blueshift. Thời hạn chuyển đổi khoảng sáu tháng phụ thuộc vào việc một phương án thay thế phù hợp sẵn sàng, được kiểm toán và hoạt động trên mainnet. Nonce bền vững cho phép phê duyệt ngoại tuyến rồi phát giao dịch sau đó bằng cách sử dụng nonce được lưu trữ thay vì blockhash gần đây vốn sớm hết hạn. Bản nâng cấp riêng về slot 200ms của Solana đã đến giai đoạn cuối trên mainnet vào ngày 9 tháng 10, rút ngắn thời gian phê duyệt thông thường, dù thời điểm hết hạn phụ thuộc vào quá trình tạo block chứ không theo một bộ đếm thời gian được bảo đảm.

Theo Programmatic Signer, khóa lạnh ký một thông điệp ủy quyền, sau đó bên chuyển tiếp gửi thông điệp này trong giao dịch có blockhash mới để xác minh và thực thi bằng địa chỉ được tạo. PDA không có khóa riêng; quyền hạn được xác lập thông qua việc xác minh phê duyệt của khóa gốc, đồng thời tài sản hoặc quyền hạn phải được chuyển riêng. Hướng dẫn chuyển đổi nêu các bước chuyển SOL gốc, số dư token, quyền đúc hoặc đóng băng, cùng quyền của tài khoản staking như quyền quản lý, quyền rút hoặc cả hai sang địa chỉ được tạo. Foundation đề xuất hoàn tất các bước bàn giao riêng biệt này trong khi nonce bền vững cũ vẫn hoạt động; danh mục tài khoản và quyền hạn hiện có của từng ngân quỹ sẽ quyết định những thay đổi cần thiết. Tài khoản SOL được tạo bởi Programmatic Signer thuộc quyền quản lý của System và có thể gửi SOL thông qua giao dịch chuyển tiền thông thường đã được phê duyệt. Tuy nhiên, Vector khởi tạo tài khoản thuộc quyền quản lý của chương trình và giải ngân SOL thông qua thao tác rút tiền hoặc đóng tài khoản được ủy quyền.

Tài liệu về thông điệp của Programmatic Signer cho biết chữ ký lạnh gắn với bên thực thi, tài khoản nonce và thông điệp thực thi được nhúng, ngăn bên chuyển tiếp thay đổi các byte đã được ủy quyền này. Bên chuyển tiếp có thể chọn bên trả phí bên ngoài và blockhash, cũng như thêm chỉ thị trước hoặc sau khi gửi giao dịch. Vector gắn chữ ký với bộ đệm chỉ thị cấp cao nhất, bao gồm dữ liệu và tài khoản của các lệnh gọi đã được phê duyệt tới chương trình khác, qua đó ngăn việc chèn, xóa hoặc sắp xếp lại các chỉ thị xung quanh sau đó. Programmatic Signer cho phép lắp ghép ngữ cảnh thực thi xung quanh một hành động đã được phê duyệt, trong khi Vector yêu cầu phê duyệt trước chuỗi chỉ thị xung quanh; không phương án nào cho phép bên trả phí sửa đổi các hành động đã ký.

Một giao dịch dùng nonce bền vững hiện nay sẽ tiêu thụ nonce nếu quá trình xác thực thành công nhưng thực thi thất bại. Programmatic Signer ghi nhận việc tăng nonce và các thay đổi của ứng dụng cùng nhau hoặc hoàn tác cả hai. Vector mô tả khả năng thử lại tương tự, nghĩa là một lần gửi thất bại có thể khiến phê duyệt vẫn thực thi được sau đó nếu nonce không thay đổi và không có hạn chót được áp dụng. Vector cảnh báo bên chuyển tiếp có thể giữ lại giao dịch đến khi điều kiện thay đổi, hoặc chữ ký bị lộ trong một lần thử thất bại có thể được thực thi sau đó. Hạn chót trong các chỉ thị đã ký có thể khiến giao dịch bị từ chối sau thời điểm quy định. Việc thu hồi đòi hỏi một lần tăng nonce được ủy quyền riêng phải được ghi nhận thành công. Giao dịch bị từ chối vì quá hạn không tiêu thụ nonce nếu thay đổi nonce được hoàn tác cùng giao dịch thất bại.

Lý do Foundation đưa ra là đơn giản hóa cách trình xác thực xử lý giao dịch, vì nonce bền vững đòi hỏi các quy tắc chống phát lại đặc biệt, làm phức tạp việc thực thi bất đồng bộ và khiến giao dịch không hợp lệ khó lọc hơn. Việc chuyển trạng thái phê duyệt và chống phát lại vào các chương trình thông thường giúp trình xác thực chỉ xử lý giao dịch dùng blockhash thông thường, trong khi ứng dụng nhận hành động đã phê duyệt thông qua lời gọi liên chương trình (CPI). Các ứng dụng yêu cầu hành động cấp cao nhất có thể từ chối quy trình này; những bước kiểm tra chỉ giới hạn ở chỉ thị hoàn trả hoặc xác minh chữ ký cấp cao nhất có thể bỏ sót hành động nằm trong các chương trình ký. Tăng độ sâu lời gọi không thể giải quyết các quy tắc từ chối vị trí của lời gọi hoặc không thể kiểm tra chỉ thị lồng bên trong. Foundation đề xuất hỗ trợ các chương trình ký đã biết hoặc cung cấp một quy trình thực thi khác. Việc ứng dụng chấp nhận chữ ký PDA là vấn đề riêng, không đồng nhất với tính hợp lệ về mật mã của phê duyệt ngoại tuyến.

Khi bật CPI Guard của Token-2022, chuyển và đốt token qua CPI cần có quyền của bên được ủy quyền, phê duyệt qua CPI bị cấm và thay đổi chủ sở hữu bị cấm ngay cả bên ngoài CPI. Các bên được ủy quyền vĩnh viễn có ngoại lệ đối với việc chuyển và đốt; một lộ trình chuyển tiền có thể thực hiện thông qua bên được ủy quyền đòi hỏi quyết định riêng về quyền hạn và chính sách lưu ký. Trong cuộc thảo luận ngày 4 tháng 3, một người tự giới thiệu là Michael từ Fireblocks ủng hộ việc loại bỏ nonce nhưng phản đối gánh nặng chuyển đổi, sự phụ thuộc vào hợp đồng và vấn đề tương thích DeFi của CPI Passthrough. Michael ủng hộ transaction envelope, với Sudo là phương án khác, thay vì quy trình ký dựa trên CPI được đề xuất. Grant, người cho biết mình làm việc tại Unit 410, nói cùng ngày rằng một chương trình ký nhỏ, có thể kiểm toán, có thể khiến việc chuyển quyền hạn trở nên chấp nhận được. Grant phản đối việc tạm thời chuyển tài sản sang bên ký nóng, kể cả khi chuyển nguyên tử, vì theo mô hình không lưu ký của Unit 410, tiền phải luôn gắn với lưu trữ lạnh.

Tài liệu của Programmatic Signer cho biết chương trình đã được triển khai trên devnet và đang được kiểm toán; các vấn đề cần khắc phục trước khi phát hành v1 và triển khai trên mainnet, đồng thời cảnh báo giao diện có thể thay đổi. Tài liệu hướng dẫn sử dụng Programmatic Signer đánh dấu mô phỏng và gửi qua bên chuyển tiếp là các tính năng sắp ra mắt, trong khi hướng dẫn chuyển đổi cũng để ngỏ một số thao tác chưa hoàn tất. Vector công bố mã triển khai và ID chương trình, nhưng README của Vector không nêu tình trạng kiểm toán hoặc triển khai trên mainnet. Bộ tài liệu onboarding giao thức hiện tại của Fireblocks mô tả việc tự động chèn nonce bền vững cho một số tích hợp WalletConnect được chọn, bao gồm Jupiter và Kamino, với thời hạn hiệu lực mặc định 15 phút do nhà cung cấp quản lý mà phương án thay thế cần đáp ứng.