Bản cập nhật Agave 4.4: Mọi điều bạn cần biết

Giới thiệu

Với Agave 4.4, client trình xác thực cốt lõi của Solana tiếp tục phát triển dựa trên quá trình triển khai Alpenglow, đơn giản hóa việc xác thực khối, tinh gọn quá trình tính phần thưởng staking và giảm lượng SOL cần thiết để lưu trữ chương trình cũng như dữ liệu tài khoản. Những thay đổi này cải thiện hiệu quả vận hành hằng ngày, đồng thời tiếp tục đặt nền móng cho việc thực thi bất đồng bộ. Việc thời gian slot mục tiêu gần đây giảm xuống còn 200ms rút ngắn mỗi epoch xuống khoảng một ngày, cho phép kích hoạt các feature gate với nhịp độ nhanh hơn nữa.

Những cập nhật đáng chú ý trong chu kỳ phát hành Agave 4.4

• Cho phép người trả phí không hợp lệ: Một bước quan trọng hướng tới việc hỗ trợ thực thi bất đồng bộ
• Tự động thay đổi kích thước chương trình: Hoàn lại phần tiền thuê dư thừa khi nâng cấp chương trình
• Chuẩn hóa shred: Giao thức hiện áp dụng các tập FEC gồm 32 shred dữ liệu và 32 shred mã hóa
• Dọn dẹp stake không hoạt động: Loại stake không hoạt động khỏi quá trình tính phần thưởng
• Giảm tiền thuê: Ba giai đoạn cuối theo kế hoạch giảm 90% khoản ký quỹ trạng thái

Cho phép người trả phí không hợp lệ

Feature gate của SIMD-0290: Nới lỏng ràng buộc đối với người trả phí dự kiến sẽ được kích hoạt trong chu kỳ phát hành Agave 4.4. Thay đổi này điều chỉnh cách xử lý khi một khối chứa giao dịch có người trả phí không vượt qua bước xác thực, chẳng hạn do không có đủ SOL. Trước đây, việc đưa một giao dịch như vậy vào sẽ khiến toàn bộ khối trở nên không hợp lệ. Theo các quy tắc đồng thuận mới, giao dịch vẫn nằm trong khối và các trình xác thực sẽ bỏ qua việc thực thi mà không thay đổi trạng thái tài khoản.

Số dư của người trả phí có thể thay đổi khi các giao dịch trước đó được thực thi. Vì vậy, việc yêu cầu mọi giao dịch phải có người trả phí hợp lệ đồng nghĩa với việc các trình xác thực phải thực thi một số giao dịch trước đó rồi mới có thể xác định khối có hợp lệ hay không. Việc coi các giao dịch có người trả phí không hợp lệ là giao dịch bị bỏ qua sẽ loại bỏ phần phụ thuộc cụ thể này.

Đây là nền tảng cho việc thực thi bất đồng bộ, trong đó các trình xác thực có thể thống nhất về khối và thứ tự giao dịch trước khi hoàn tất thực thi. Quá trình thực thi diễn ra riêng biệt, áp dụng các giao dịch đã được thống nhất vào trạng thái tài khoản. Solana đang chuyển sang thiết kế này để hỗ trợ những cải tiến trong tương lai, chẳng hạn như thời gian tạo khối ngắn hơn và nhiều bên đề xuất khối đồng thời.

Agave biểu diễn các giao dịch bị bỏ qua này dưới dạng thao tác no-op: chúng không thực thi chỉ thị nào và không trả phí. Chúng vẫn chiếm dung lượng khối theo toàn bộ ngân sách tài nguyên được yêu cầu hoặc ngân sách mặc định, qua đó giới hạn số lượng mà một leader có thể đưa vào. Cách triển khai này cũng giữ nguyên khả năng lọc bỏ chúng của leader trong quá trình tạo khối, dù các trình xác thực có thể chấp nhận chúng khi phát lại một khối.

SIMD-0290 áp dụng riêng cho các giao dịch sử dụng blockhash gần đây làm thông số xác định thời hạn. Các giao dịch durable nonce cần được xử lý thêm và được đề cập riêng trong SIMD-0297: Nới lỏng ràng buộc đối với giao dịch nonce không hợp lệ. Thay đổi này hoàn toàn tương thích ngược, nên mọi giao dịch và khối hợp lệ trước đây vẫn tiếp tục hợp lệ.

Tự động thay đổi kích thước chương trình khi nâng cấp

Agave 4.4 sẽ kích hoạt feature gate cho SIMD-0433: Loader V3: Đặt dữ liệu chương trình theo độ dài ELF, giúp quá trình nâng cấp chương trình tự động thay đổi kích thước tài khoản lưu trữ mã đã biên dịch của chương trình.

Loader v3 (tức loader mặc định hiện tại để triển khai và nâng cấp các chương trình Solana) lưu trữ tệp nhị phân ELF đã biên dịch của chương trình trong một tài khoản ProgramData, cùng với siêu dữ liệu như quyền nâng cấp. Trước đây, nhà phát triển chỉ có thể mở rộng tài khoản này chứ không thể thu nhỏ. Vì vậy, việc nâng cấp lên tệp nhị phân nhỏ hơn vẫn để lại không gian chưa sử dụng, còn lượng SOL cần thiết để duy trì trạng thái miễn tiền thuê cho không gian đó vẫn bị khóa trong tài khoản.

Với thay đổi này, chỉ thị Upgrade sẽ thay đổi kích thước tài khoản thành tổng kích thước phần đầu siêu dữ liệu và độ dài của ELF mới. Tệp nhị phân nhỏ hơn sẽ chuyển phần lamport dư thừa đến tài khoản nhận phần dư của bản nâng cấp, tức bên nhận được chỉ định cho số tiền còn lại. Tệp nhị phân lớn hơn sẽ tự động mở rộng tài khoản, loại bỏ bước mở rộng riêng đối với các bản nâng cấp thông thường. Tài khoản ProgramData và các tài khoản buffer phải có sẵn đủ lamport để đáp ứng yêu cầu tiền thuê mới; nếu không, quá trình nâng cấp sẽ thất bại.

Do đó, các nhà phát triển chuyển sang dùng tệp nhị phân nhỏ hơn có thể thu hồi SOL trong lần nâng cấp tiếp theo. Mọi dung lượng dự phòng đã đặt trước đó cũng sẽ bị loại bỏ. Đối với các bản nâng cấp được gọi qua CPI, giới hạn tăng trưởng tài khoản 10 KiB vẫn được áp dụng: mức tăng lớn hơn cần được mở rộng trước hoặc sử dụng chỉ thị nâng cấp cấp cao nhất. Nhà phát triển nên kiểm tra đích đến của tài khoản nhận phần dư trước khi nâng cấp để đảm bảo khoản hoàn trả đến đúng người nhận dự kiến.

Thay đổi này khuyến khích các nhà phát triển nâng cấp lên những thư viện và framework mới hơn, có hiệu năng cao hơn như Pinocchio. Nó cũng giảm lượng không gian mà các chương trình chiếm dụng trong Accounts DB.

Chuẩn hóa shred

Agave 4.4 thắt chặt các quy tắc truyền khối của Solana được nêu trong SIMD-0317: Áp dụng 32 shred dữ liệu + 32 shred mã hóa. Thay đổi này chuẩn hóa cấu trúc mà các trình xác thực sử dụng để phân phối và tái tạo dữ liệu khối.

Solana phân phối các khối thông qua Turbine, hệ thống chia dữ liệu khối thành các shred rồi chuyển tiếp chúng qua nhiều lớp trình xác thực. Các shred được nhóm thành những tập sửa lỗi chuyển tiếp (FEC), kết hợp shred dữ liệu với shred mã hóa chứa thông tin khôi phục. Với một tập gồm 32 shred dữ liệu và 32 shred mã hóa được tạo đúng cách, bên nhận có thể tái tạo dữ liệu gốc từ 32 shred bất kỳ trong tổng số 64 shred, giúp chịu được tình trạng mất gói tin.

Mỗi shred cũng mang theo một bằng chứng Merkle liên kết nó với gốc Merkle của tập, được xác thực bằng chữ ký của leader. Với một tập gồm 64 shred, bằng chứng đó có sáu phần tử, tương ứng với sáu cấp giữa một lá và gốc. Kiểm tra kích thước bằng chứng của Agave yêu cầu kích thước đúng như dự kiến cho cấu trúc 32:32 cố định này.

Các client đã tạo 32 shred dữ liệu và 32 shred mã hóa cho mỗi tập, nhưng trước đây các trình xác thực nhận dữ liệu vẫn chấp nhận những cấu hình linh hoạt hơn. SIMD-0317 khắc phục điểm không đồng nhất đó bằng cách biến cấu trúc 32:32 cố định thành một yêu cầu của giao thức. Điều này đơn giản hóa quá trình xác thực: bên nhận có thể xác định các ranh giới chỉ mục shred hợp lệ mà không cần chờ shred mã hóa tiết lộ kích thước của tập.

Cấu trúc cố định cũng đơn giản hóa việc phát hiện hành vi equivocation, khi một leader phân phối các phiên bản xung đột của cùng một dữ liệu. Hai shred thuộc cùng một tập FEC nhưng có gốc Merkle khác nhau và chữ ký leader hợp lệ sẽ cung cấp bằng chứng về xung đột đó. Vì vậy, việc chuẩn hóa định dạng vừa giảm độ phức tạp khi triển khai, vừa giúp dễ dàng xác định hành vi equivocation hơn.

Loại stake không hoạt động khỏi quá trình tính phần thưởng

Chu kỳ phát hành Agave 4.4 sẽ kích hoạt feature gate cho SIMD-0599: Loại stake không hoạt động khỏi danh sách ủy quyền stake, giúp đơn giản hóa cách các trình xác thực xử lý tài khoản stake không hoạt động trong quá trình phân chia phần thưởng epoch ở đầu mỗi epoch. Tài khoản stake không hoạt động có thể nắm giữ lượng SOL cao hơn mức tối thiểu để được miễn tiền thuê, nhưng không có stake nào đang hoạt động hoặc đang được kích hoạt. SOL của chúng chưa được ủy quyền hoặc đã hoàn tất quá trình hủy kích hoạt.

Các tài khoản này không nhận phần thưởng từ giao thức, nhưng việc đưa chúng vào vẫn có thể ảnh hưởng đến số lượng phân vùng phân phối phần thưởng và hàm băm lưới dùng để theo dõi trạng thái tài khoản. Mọi client trình xác thực đều phải tái hiện chính xác hành vi này, làm tăng thêm độ phức tạp không cần thiết cho mã có vai trò then chốt đối với cơ chế đồng thuận.

Thay đổi này loại trừ stake không hoạt động trong epoch được nhận thưởng, đồng thời giữ lại các stake đang kích hoạt, đang hoạt động và đang hủy kích hoạt. Do đó, một tài khoản stake chuyển sang trạng thái không hoạt động ở đầu epoch mới vẫn nhận được phần thưởng đã tích lũy trong epoch trước đó, khi tài khoản đang trong quá trình hủy kích hoạt.

Tiếp tục giảm tiền thuê

Agave 4.4 dự kiến sẽ triển khai ba lần kích hoạt cuối cùng trong lộ trình giảm tiền thuê theo từng giai đoạn của Solana. Theo kế hoạch được nêu trong SIMD-0437, số dư tối thiểu bắt buộc cho mỗi byte lưu trữ tài khoản sẽ giảm từ mức ban đầu 6.960 lamport xuống còn 696 qua năm bước (tức giảm 90%).

Mỗi lần kích hoạt có feature gate riêng, cho phép mạng đánh giá tác động đối với việc tạo tài khoản và tăng trưởng trạng thái trước khi tiếp tục.

Việc hạ thấp yêu cầu này giúp giảm lượng vốn mà nhà phát triển và người dùng phải cam kết khi tạo tài khoản token, PDA và các trạng thái onchain khác. Điều này đặc biệt hữu ích cho những ứng dụng tài trợ việc tạo tài khoản thay cho người dùng, chẳng hạn như các dịch vụ thanh toán quy mô lớn.

Ước tính từ Ghost cho thấy có thể thu hồi hơn 3 triệu SOL (~300 triệu USD). Một số công cụ đã được phát triển để giúp người dùng thu hồi lượng SOL dư thừa từ tài khoản của họ.

Kết luận

Những thay đổi nổi bật trong Agave 4.4 tiếp tục phát triển dựa trên Alpenglow, đồng thời thúc đẩy các cải tiến được mong đợi từ lâu đối với phần thưởng staking, triển khai chương trình và chi phí tài khoản. Nhìn chung, chúng tiếp tục đưa Solana tiến tới một mạng nhanh hơn và dễ tiếp cận hơn. Tiếp theo sẽ là Breakpoint London, rồi đến Agave 4.5.

Tài nguyên khác

• Lịch phát hành Agave 4.4
• Lịch theo dõi feature gate
• Nhật ký thay đổi Agave 4.4
• Các pull request của Agave 4.4