Cập nhật Agave 4.2: Mọi điều bạn cần biết

Giới thiệu

Với Agave 4.2, client trình xác thực cốt lõi của Solana tiếp tục tạo ra những bước tiến mới. Bản phát hành lớn này tập trung vào ba nâng cấp được mong đợi từ lâu và được kiểm soát bằng cổng tính năng: thời gian slot 200ms, giảm 90% khoản ký quỹ trạng thái và giao dịch 4.096 byte thông qua định dạng giao dịch v1 mới. Bản phát hành cũng cung cấp Alpenglow với đầy đủ tính năng trước thời điểm kích hoạt dự kiến trong phiên bản tiếp theo, đồng thời XDP transmit hiện được bật theo mặc định.

Những cập nhật đáng chú ý

• Giao dịch lớn hơn 3,3× với tiêu chuẩn Transaction v1 mới *
• Giảm 90% khoản ký quỹ trạng thái (tiền thuê) *
• Giảm thời gian slot xuống 200ms *
• Alpenglow hoàn thiện đầy đủ tính năng
• Công cụ quản trị mới (liên quan đến SIMD)

* Các nâng cấp được kiểm soát bằng cổng tính năng

Giao dịch lớn hơn (Transaction v1)

Chu kỳ phát hành Agave 4.2 bao gồm việc kích hoạt cổng tính năng cho các giao dịch lớn hơn, lên đến 4.096 byte, tăng từ giới hạn 1.232 byte đã tồn tại từ lâu. Được định nghĩa chính thức trong SIMD-0296: Kích thước giao dịch lớn hơn, giới hạn cao hơn này tương đương mức tăng khoảng 3,3× và chỉ áp dụng cho định dạng giao dịch v1 mới được giới thiệu trong SIMD-0385: Định dạng Transaction V1. Các giao dịch legacy và v0 tiếp tục hoạt động mà không thay đổi và vẫn chịu giới hạn 1.232 byte hiện tại.

Đối với nhà phát triển, thay đổi này không chỉ đơn thuần bổ sung không gian cho dữ liệu lệnh. Các bằng chứng mật mã, phê duyệt multisig, danh sách tài khoản lớn và những payload khác trước đây không thể chứa vừa trong một giao dịch nay có thể thực thi trong một thao tác nguyên tử duy nhất ở cấp giao thức. Thay đổi này không làm tăng các giới hạn của Solana về tài nguyên tính toán, tài khoản, chữ ký hoặc số lượng lệnh.

Giới hạn 1.232 byte ban đầu được kế thừa từ kiến trúc mạng trước đây của Solana. Các giao dịch được truyền dưới dạng từng datagram UDP riêng lẻ và phải vừa với đơn vị truyền tối đa tối thiểu (MTU) của IPv6 là 1.280 byte. Sau khi tính đến header IPv6 40 byte và header UDP 8 byte, giao dịch còn lại 1.232 byte. Việc giữ mỗi giao dịch trong một gói duy nhất giúp giảm phân mảnh và khiến quá trình truyền dễ dự đoán hơn.

Solana từ lâu đã chuyển từ UDP sang QUIC để tiếp nhận giao dịch. Các stream QUIC không bị giới hạn trong payload của một datagram mạng duy nhất, vì vậy mức trần 1.232 byte cũ không còn là yêu cầu bắt buộc. Client vẫn cần một giới hạn trên rõ ràng để kiểm soát tiếp nhận, phân bổ bộ nhớ và xác thực đồng thuận, nhưng giờ đây giới hạn đó có thể được lựa chọn theo yêu cầu của runtime và ứng dụng thay vì MTU IPv6.

Danh sách tài khoản thường chiếm một phần đáng kể trong dung lượng hiện có. Mỗi khóa công khai Ed25519 hoặc địa chỉ do chương trình tạo ra chiếm 32 byte, và một giao dịch phải xác định mọi tài khoản mà các lệnh của nó đọc hoặc sửa đổi. Trước đây, điều này tạo ra mức trần thực tế khoảng 32 khóa tài khoản đầy đủ. Để khắc phục, giao dịch V0 đã giới thiệu Address Lookup Tables (ALT), thay thế mỗi khóa 32 byte bằng một chỉ mục bảng 1 byte, cho phép giao dịch đạt giới hạn 64 tài khoản của runtime.

Mặc dù ALT là một hình thức nén hiệu quả, chúng cũng gây thêm nhiều phức tạp. Ứng dụng phải tạo và quản lý các bảng tra cứu onchain. Các dịch vụ RPC và indexer giải mã thông điệp v0 thô phải tái dựng danh sách tài khoản đầy đủ bằng metadata của giao dịch hoặc trạng thái bảng liên quan. Điều này gây khó khăn khi phân tích các giao dịch tham chiếu đến một ALT đã bị đóng và không còn khả dụng onchain. 

Vấn đề này của nhà phát triển được giải quyết bằng giao dịch v1, vốn đủ lớn để chứa toàn bộ tập hợp tài khoản hiện được hỗ trợ thông qua ALT (64 khóa công khai đầy đủ chiếm 2.048 byte). Do đó, ứng dụng chuyển từ v0 có thể phân giải các mục trong bảng tra cứu và đưa trực tiếp những địa chỉ thu được vào giao dịch v1.

Ngoài ra, kích thước giao dịch 1.232 byte đặc biệt hạn chế đối với các hàm mật mã như bằng chứng không kiến thức và những triển khai BLS không có precompile gốc. Các tác vụ này có thể mang theo hàng trăm hoặc hàng nghìn byte dữ liệu bằng chứng hoặc chữ ký. Giới hạn 4.096 byte đáp ứng nhiều trường hợp sử dụng mật mã phổ biến như vậy. 

Đặc tả Transaction V1

Một giao dịch v1 đã tuần tự hóa bắt đầu bằng byte phiên bản 0x81. Tiếp theo là header thông điệp kiểu legacy dài 3 byte, mặt nạ cấu hình giao dịch 32 bit, bộ chỉ định thời hạn 32 byte, số lượng lệnh và địa chỉ, mảng đầy đủ các địa chỉ 32 byte, giá trị cấu hình, header lệnh có kích thước cố định, các payload lệnh liên tiếp và cuối cùng là các chữ ký. 

VersionByte (u8)
LegacyHeader (u8, u8, u8) 
TransactionConfigMask (u32) -- Bitmask of which config requests are present.
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- Length matches NumAddresses
ConfigValues [[u8; 4]] -- Length equal to the popcount (number of set bits)
  of TransactionConfigMask. See section TransactionConfigMask for details.
InstructionHeaders [(u8, u8, u16)] -- Length of NumInstructions. Values are
  (ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- Length = NumInstructions.
  Each InstructionPayload is the concatenation of the following byte arrays:
    InstructionAccountIndexes [u8] -- Length = NumInstructionAccounts from the
    corresponding InstructionHeader
    InstructionData [u8] -- Length = NumInstructionDataBytes from the
    corresponding InstructionHeader
Signatures [[u8; 64]]

Header lệnh xác định rõ chỉ mục tài khoản chương trình, số lượng tài khoản của lệnh và độ dài dữ liệu lệnh, nhờ đó có thể xác định ranh giới thông điệp mà không cần diễn giải payload của từng lệnh.

Giao dịch V1 vẫn bị giới hạn ở 12 chữ ký, 64 địa chỉ tài khoản, 64 lệnh và 255 chỉ mục tài khoản cho mỗi lệnh. Giao dịch lớn vẫn phải nằm trong giới hạn đơn vị tính toán được yêu cầu, giới hạn dữ liệu tài khoản được tải, các quy tắc khóa tài khoản và năng lực thực thi khả dụng của block.

Các parser hiện tại không thể xử lý v1 như v0 với độ dài tối đa lớn hơn. Indexer, RPC, SDK và hạ tầng ký có kiểm tra giao dịch đã tuần tự hóa phải nhận diện tiền tố 0x81 và triển khai thứ tự trường mới. Đáng chú ý, chữ ký v1 xuất hiện ở cuối giao dịch thay vì đứng trước thông điệp như trong giao dịch legacy và v0.

Transaction v1 thay thế các lệnh cấu hình của chương trình Compute Budget bằng các trường trong header giao dịch. `TransactionConfigMask` ban đầu có thể khai báo những thông tin sau của giao dịch:

• tổng phí ưu tiên tính bằng lamport
• giới hạn đơn vị tính toán
• giới hạn kích thước dữ liệu tài khoản được tải
• kích thước heap được yêu cầu

Mỗi bit được đặt xác định một giá trị cấu hình 4 byte đi kèm, trong đó phí ưu tiên 64 bit chiếm hai vị trí trong mặt nạ. Mặt nạ được thiết kế để có thể mở rộng trong các phiên bản giao dịch tương lai.

Giảm khoản ký quỹ trạng thái (tiền thuê)

Yêu cầu ký quỹ trạng thái cao, thường được gọi là “tiền thuê”, vẫn là một trong những nguồn gây cản trở lớn nhất của Solana đối với các ứng dụng sử dụng nhiều tài khoản. Tên gọi này phần nào gây hiểu nhầm vì tiền thuê không phải là phí lưu trữ định kỳ, mà là khoản ký quỹ có thể hoàn lại mà một tài khoản phải duy trì trong suốt thời gian trạng thái của tài khoản còn tồn tại onchain. Lamport thường có thể được thu hồi khi tài khoản đóng, nhưng trước thời điểm đó, chúng là phần vốn mà nhà phát triển hoặc người dùng phải ứng trước và để bất động.

Agave 4.2 giới thiệu phần triển khai được kiểm soát bằng cổng tính năng của SIMD-0437: Giảm dần lamports_per_byte xuống 696, qua đó giảm hằng số `lamports_per_byte` từ 6.960 xuống 696. Đây là mức giảm 90% tiền thuê (hay chính xác hơn là số dư tối thiểu được miễn tiền thuê), được triển khai qua năm cổng tính năng độc lập: 6.960 → 6.333 → 5.080 → 2.575 → 1.322 → 696. 

Khi một trong các cổng được kích hoạt, Agave cập nhật cấu hình tiền thuê của Bank và công bố giá trị mới thông qua Rent sysvar. Việc triển khai theo từng giai đoạn cho phép mạng quan sát cách ứng dụng phản ứng ở mỗi mức giá và dừng lại trước lần giảm tiếp theo nếu tốc độ tăng trưởng trạng thái hoặc mức sử dụng tài nguyên của trình xác thực trở nên đáng lo ngại.

Số dư tối thiểu được miễn tiền thuê của một tài khoản được tính từ kích thước dữ liệu đã phân bổ cộng với chi phí lưu trữ cố định 128 byte:

minimum_balance = (128 + account_data_size) × lamports_per_byte

Theo thay đổi này, cơ chế tiền thuê không thay đổi: tài khoản vẫn cần số dư tối thiểu và số dư đó vẫn có thể được thu hồi khi tài khoản đóng. Chỉ lượng SOL cần được ký quỹ thay đổi.

Một tài khoản SPL Token tiêu chuẩn có kích thước 165 byte. Khi cộng chi phí 128 byte, kích thước thực tế của nó là 293 byte. Việc giảm 90% tiền thuê đưa lượng SOL cần thiết cho một tài khoản như vậy từ khoảng ~0,16 USD xuống dưới 2 xu. 

Điều này đặc biệt quan trọng đối với thanh toán bằng stablecoin, phân phối token, hệ thống khách hàng thân thiết và airdrop trực tiếp. Ví không trực tiếp nắm giữ SPL token; thông thường, ví cần một Associated Token Account (ATA) cho mỗi mint. Khi người nhận chưa có ATA cần thiết, người gửi có thể tạo tài khoản này cùng lúc với giao dịch chuyển, nhưng cũng phải cấp vốn cho số dư miễn tiền thuê của người nhận. Nhìn chung, đây là chi phí tiếp nhận một lần cho mỗi cặp ví và mint, thay vì chi phí phải trả cho mọi khoản thanh toán tiếp theo. Tuy nhiên, ở quy mô lớn, chi phí này có thể đủ cao để quyết định doanh nghiệp sẽ trợ cấp việc tiếp nhận hay chuyển chi phí sang người dùng.

Tăng trưởng trạng thái của Solana

Việc giảm theo từng giai đoạn rất quan trọng vì giảm khoản ký quỹ trạng thái cũng làm giảm số vốn mà kẻ tấn công phải giữ bất động để tạo và duy trì trạng thái không mong muốn. Trạng thái Solana được sao chép, lập chỉ mục, đưa vào snapshot và duy trì bởi mọi trình xác thực, vì vậy sự tăng trưởng trạng thái liên tục cuối cùng sẽ ảnh hưởng đến yêu cầu ổ đĩa, hoạt động của AccountsDB và sau cùng là chi phí vận hành.

Theo phân tích gần đây của Solana Foundation, các tệp lưu trữ AccountsDB chiếm khoảng 495 GB trong mức phân bổ khuyến nghị 1 TB. Sau đợt giảm tiền thuê dự kiến, để sử dụng hết dung lượng còn lại đó, kẻ tấn công sẽ phải cam kết lượng SOL trị giá khoảng 17,2 triệu USD. Việc tăng gấp đôi mức phân bổ lưu trữ được khuyến nghị cho trình xác thực lên 2 TB sẽ nâng yêu cầu vốn của kẻ tấn công lên 51 triệu USD.

Sau khi tính đến cả việc tạo tài khoản mới và đóng các tài khoản cũ, trạng thái được xác định là đang tăng khoảng 0,3 GB mỗi ngày.

Snapshot trạng thái được chụp tại epoch 997 cho thấy mức sử dụng trạng thái tập trung rất cao. Tài khoản SPL Token là danh mục lớn nhất, trong khi tài khoản OpenBook và Serum chiếm khoảng 30% trạng thái đang hoạt động, phản ánh kiến trúc phức tạp của các sổ lệnh onchain. Phân tích cũng ước tính khoảng 30% không gian SPL Token liên quan đến các tài sản theo mô hình launchpad token của Pump.fun.

Các biện pháp an toàn

Để giảm khoản ký quỹ trạng thái một cách an toàn, cần có một lộ trình khả thi theo chiều ngược lại. Nếu không có thêm thay đổi đối với runtime, việc tăng số dư tối thiểu được miễn tiền thuê sau này sẽ ngay lập tức khiến các tài khoản hiện có thấp hơn ngưỡng mới. Các giao dịch khóa ghi những tài khoản đó có thể thất bại ngay cả khi không phân bổ thêm trạng thái, dẫn đến gián đoạn trên diện rộng.

Đây là lúc SIMD-0392: Điều chỉnh Runtime cho việc tăng tiền thuê thay đổi quy tắc số dư tối thiểu sau thực thi để các tài khoản hiện có có thể được áp dụng cơ chế kế thừa khi tiền thuê tăng. Khi một tài khoản đã tồn tại, không tăng kích thước và vẫn giữ nguyên chủ sở hữu, mức tối thiểu được phép của tài khoản sẽ là giá trị thấp hơn trong hai giá trị sau:

1. mức tối thiểu theo mức tiền thuê hiện tại
2. số dư trước khi thực thi của tài khoản

Tài khoản mới vẫn phải đáp ứng số dư tối thiểu được miễn tiền thuê hiện tại. Điều tương tự cũng áp dụng cho các tài khoản tăng kích thước phân bổ hoặc thay đổi chủ sở hữu. Số dư bằng 0 tiếp tục biểu thị việc đóng tài khoản. Điều này cho phép trạng thái hiện có tiếp tục hoạt động với số tiền ký quỹ trước đó, đồng thời đảm bảo trạng thái mới được phân bổ phải trả theo mức mới nhất.

SIMD-0438: Biện pháp bảo vệ khi tăng số dư tối thiểu được miễn tiền thuê bổ sung một cổng tính năng bảo vệ riêng biệt, khôi phục `lamports_per_byte` về giá trị legacy là 6.960. Cổng này chỉ được kích hoạt nếu mức tiền thuê thấp hơn gây tăng trưởng trạng thái quá mức hoặc phát sinh vấn đề vận hành nghiêm trọng khác. Vì cổng đã tồn tại trước khi bắt đầu giảm, các nhà phát triển cốt lõi sẽ không cần thiết kế, đánh giá và triển khai một thay đổi đồng thuận mới trong lúc xảy ra sự cố tăng trưởng trạng thái.

Kết hợp lại, năm cổng giảm, các quy tắc kế thừa trong SIMD-0392 và cơ chế dự phòng trong SIMD-0438 giúp quá trình triển khai có thể đảo ngược ở cấp giao thức. Mạng có thể giảm dần khoản ký quỹ, quan sát trạng thái đang hoạt động và hành vi lưu trữ của trình xác thực, tạm dừng ở một giá trị trung gian hoặc khôi phục yêu cầu ban đầu mà không buộc mọi tài khoản hiện có phải lập tức bổ sung số dư.

Giảm thời gian slot xuống 200ms

Một trong những nâng cấp hiệu năng được mong đợi nhất của Solana là giảm thời gian slot mục tiêu từ 400ms xuống 200ms. Lợi ích chính là độ trễ thấp hơn. Với slot 200ms, cửa sổ leader bốn slot của Solana sẽ giảm từ 1,6 giây xuống 800ms, rút ngắn thời gian xác nhận và hạn chế khoảng thời gian một leader độc hại có thể trì hoãn, sắp xếp lại hoặc chọn lọc giao dịch để đưa vào. Slot ngắn hơn cũng cung cấp cho các ứng dụng như bên sử dụng oracle và nhà tạo lập thị trường khả năng định thời onchain chi tiết hơn.

Đề xuất được thiết kế để duy trì mô hình kinh tế và thông lượng hiện tại của Solana. Các tham số lạm phát, chi phí Validator Admission Ticket trong Alpenglow và giới hạn khối lượng công việc mỗi slot được điều chỉnh theo tỷ lệ. Tuy nhiên, nếu slot 200ms được triển khai trước Alpenglow, chi phí bỏ phiếu của trình xác thực có thể tăng gần gấp đôi vì các trình xác thực sẽ phải bỏ phiếu thường xuyên gấp đôi.

Để tìm hiểu sâu hơn về slot 200ms, hãy đọc phân tích trước đây của chúng tôi trong bài tổng quan Agave 4.1.

Những cập nhật đáng chú ý khác

Một số cải tiến nhỏ hơn nhưng đáng chú ý dự kiến sẽ được kích hoạt trong chu kỳ phát hành Agave 4.2.

Mức độ sẵn sàng của Alpenglow

Agave 4.2 cung cấp Alpenglow với đầy đủ tính năng nhưng sẽ không kích hoạt giao thức đồng thuận mới trên mainnet; các nhóm kỹ thuật cốt lõi đang sử dụng chu kỳ phát hành này để tiếp tục kiểm thử, kiểm tra và gia cố trước khi chuyển đổi cơ chế đồng thuận, hiện dự kiến diễn ra với Agave 4.3. Do đó, các trình xác thực chạy 4.2 đã có đầy đủ phần triển khai Alpenglow, bao gồm công cụ bỏ phiếu Votor và các thành phần xác minh chứng chỉ BLS. 

Để mở rộng quá trình đánh giá bảo mật mã nguồn, Anza cũng đang tổ chức cuộc thi săn lỗi Alpenglow với tổng giải thưởng lên đến 50.000 SOL và thời gian gửi báo cáo từ ngày 5 đến ngày 19 tháng 8. Trước đây, Alpenglow không thuộc phạm vi chương trình săn lỗi thường trực của Agave trong quá trình phát triển, chuyển đổi monorepo và kiểm tra nội bộ; cuộc thi đánh dấu việc Alpenglow bắt đầu đủ điều kiện tham gia chương trình săn lỗi và nhằm phát hiện các vấn đề có thể đã bị bỏ sót trong những đợt đánh giá trước.

Chuyển Stake Program từ số thực dấu phẩy động sang dấu phẩy cố định

Chu kỳ phát hành Agave 4.2 cũng bao gồm phần triển khai được kiểm soát bằng cổng tính năng của SIMD-0391: Chuyển Stake Program từ số thực dấu phẩy động sang dấu phẩy cố định, thay thế số học dấu phẩy động IEEE-754 trong các phép tính khởi động và hạ nhiệt của Stake Program bằng phép toán số nguyên dấu phẩy cố định có tính xác định. Động lực chính là khả năng tương thích với bộ công cụ eBPF tiêu chuẩn, vốn không hỗ trợ các phép toán dấu phẩy động. Bộ công cụ SBF của Solana có thể mô phỏng chúng bằng các routine soft-float có tính xác định, nhưng cách này không hiệu quả và cản trở quá trình chuyển Stake Program sang phần triển khai `no_std`.

Hầu hết ứng dụng không cần thay đổi, mặc dù các indexer và công cụ staking tự tái tạo stake hiệu lực, đang kích hoạt hoặc đang hủy kích hoạt nên triển khai các quy tắc số nguyên mới sau khi tính năng được kích hoạt.

Công cụ quản trị mới

Chu kỳ phát hành Agave 4.2 cũng chứng kiến sự ra mắt của bộ công cụ quản trị mới đã được phát triển từ năm ngoái. Bộ công cụ này cung cấp một quy trình onchain để cả trình xác thực và người staking gốc thể hiện quan điểm của họ về những quyết định lớn ở cấp độ kinh tế và giao thức. 

Thành phần trung tâm, svmgov, là một chương trình dựa trên Anchor để quản lý việc tạo đề xuất, ủng hộ, bỏ phiếu theo trọng số stake và hoàn tất. Trọng số bỏ phiếu được lấy từ snapshot stake dành riêng cho từng epoch do Node Consensus Network (NCN) tạo ra. Các nhà vận hành độc lập tạo snapshot, đạt đồng thuận về một Merkle root chuẩn và công bố nó onchain; sau đó, các trình xác thực chứng minh stake đang hoạt động của mình bằng bằng chứng Merkle. 

Các trình xác thực có ít nhất 100.000 SOL stake đang hoạt động có thể tạo đề xuất, trong khi đề xuất cần nhận được sự ủng hộ từ 15% stake của cụm trước khi chuyển sang quy trình bỏ phiếu. Kho lưu trữ quản trị cũng bao gồm một CLI Rust và giao diện web để bỏ phiếu và theo dõi mức độ ủng hộ.

Các tài liệu đề xuất đầy đủ nằm trong kho lưu trữ Solana Governance Proposals riêng biệt và được ghim vào một Git commit cụ thể, trong khi tài khoản đề xuất onchain lưu trữ liên kết, trạng thái vòng đời và số phiếu. Ban đầu, trình xác thực bỏ phiếu bằng toàn bộ stake được ủy quyền cho họ, nhưng từng người ủy quyền vẫn giữ quyền tự quyết đối với SOL của mình; người staking có thể gửi lựa chọn ghi đè cho một tài khoản stake cụ thể, loại phần stake đó khỏi tổng phiếu của trình xác thực và phân bổ lại theo lá phiếu của chính người staking.

Solana Governance Proposals (SGP) được thiết kế để bổ sung thay vì thay thế SIMD: một SGP trả lời câu hỏi định hướng về việc mạng có nên theo đuổi một thay đổi hay không, còn SIMD liên quan xác định cách triển khai thay đổi đó.

Ba SGP đã vượt qua giai đoạn ủng hộ và sẽ đánh dấu vòng bỏ phiếu quản trị đầu tiên theo hệ thống mới:

• SGP-0001: Hiến pháp Solana đề xuất phê chuẩn một khế ước xã hội quản trị chuẩn, xác định vai trò của nhà phát triển, trình xác thực và người staking, đồng thời chính thức thiết lập quy trình SGP.
• SGP-0002: Tăng gấp đôi tốc độ giảm lạm phát đề nghị mạng tăng gấp đôi tốc độ giảm lạm phát hằng năm của SOL từ 15% lên 30%, trong khi giữ nguyên tỷ lệ lạm phát cuối cùng ở mức 1,5%, qua đó rút ngắn thời gian ước tính để đạt tỷ lệ cuối cùng từ khoảng 5,7 năm xuống 2,8 năm. 
• SGP-0003: Phí tài nguyên và đưa vào đề xuất thay thế cấu trúc phí cơ sở cố định hiện tại bằng phí đưa vào 2.500 lamport trả cho leader và một khoản phí tài nguyên riêng dựa trên số đơn vị chi phí giao dịch được yêu cầu, được đốt toàn bộ, trong khi giữ nguyên cơ chế phân phối phí ưu tiên.

Kết luận

Agave 4.2 là một trong những bản phát hành có ảnh hưởng lớn nhất của Solana trong thời gian gần đây. Slot 200ms nhanh hơn đưa mạng tiến gần hơn đến khả năng phản hồi theo thời gian thực, kế hoạch giảm 90% khoản ký quỹ trạng thái giúp chi phí tạo tài khoản thấp hơn đáng kể, còn giao dịch v1 có kích thước 4.096 byte mở ra nhiều không gian hơn cho các lệnh phức tạp, bằng chứng mật mã và ứng dụng sử dụng nhiều tài khoản. Kết hợp lại, những thay đổi này giúp Solana nhanh hơn, tiết kiệm hơn và linh hoạt hơn cho cả nhà phát triển lẫn người dùng.

Tài nguyên bổ sung

• Lịch phát hành Agave 4.2
• Lịch theo dõi cổng tính năng
• Nhật ký thay đổi Agave 4.2
• Các pull request của Agave 4.2