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

Giới thiệu

Với Agave 4.1, client trình xác thực cốt lõi của Solana tiếp tục phát triển ổn định, mang đến các cải tiến hiệu năng ngay hôm nay, đồng thời đặt nền móng cho các block lớn hơn, thời gian slot 200ms và việc triển khai Alpenglow trong tương lai.

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

• Nhịp độ phát hành nhanh hơn, với các bản phát hành lớn hiện ra mắt sáu tuần một lần
• Tiếp tục chuẩn bị cho Alpenglow, bao gồm quản lý khóa công khai BLS*, Validator Admission Tickets* và cụm thử nghiệm cộng đồng
• Mức độ áp dụng XDP vượt qua một ngưỡng quan trọng của mạng
• Thêm các chương trình được viết lại bằng Pinocchio, bao gồm p-memo và p-ATA
• Giảm mức sử dụng RAM của trình xác thực
• Chuẩn bị cho thời gian slot 200ms**

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

** Dự kiến có trong Agave 4.2

Song song với công việc trên client cốt lõi, Anza và hệ sinh thái rộng lớn hơn cũng đang đồng thời thúc đẩy một số sáng kiến lớn:

• Constellation: Constellation đề xuất cách triển khai chính thức đầu tiên ở cấp giao thức của Multiple Concurrent Proposers (MCP) trên một blockchain vận hành thực tế ở quy mô lớn. Thay vì trao cho một leader quyền quyết định rộng rãi về việc đưa transaction vào block, Constellation bổ sung các proposer và attester để giới hạn những gì leader có thể loại khỏi một block hợp lệ.
• Tăng cường khả năng chống lượng tử: Nhóm nghiên cứu của Anza đã bắt đầu tìm hiểu cách bảo vệ Solana trước các đối thủ lượng tử trong tương lai, bao gồm nghiên cứu về chữ ký hậu lượng tử, di chuyển account, chữ ký đồng thuận, truyền block và xác minh chữ ký onchain.
• Nâng cấp kinh tế: Một làn sóng đề xuất tokenomics mới cũng đang được chuẩn bị. SIMD-550 đề xuất tăng gấp đôi tốc độ giảm lạm phát của Solana từ -15% lên -30%, trong khi SIMD-553: Phí tài nguyên và phí đưa vào block đề xuất chia phí chữ ký hiện tại thành phí cơ sở để đưa vào block, được trả cho leader, và phí tài nguyên bị đốt dựa trên số đơn vị chi phí được yêu cầu.
• Công cụ quản trị mới: Vòng đề xuất kinh tế tiếp theo cũng đang được định hình bởi hạ tầng quản trị được cải thiện. Công cụ mới không chỉ cho phép các trình xác thực mà cả staker trực tiếp tham gia quản trị Solana, mở rộng đối tượng có thể đóng góp ý kiến về những thay đổi cốt lõi của giao thức.

Hiện có rất nhiều điều đang diễn ra.

Dù là đơn vị vận hành trình xác thực hay nhà phát triển, hướng dẫn này cung cấp những thông tin cập nhật và phân tích cần thiết để tận dụng tối đa các cải tiến mới nhất. Mỗi phần trong bài viết đều độc lập, cho phép độc giả tập trung vào những chủ đề phù hợp nhất với mình. 

Tại thời điểm viết bài, Agave v4.1.0-rc.1 hiện được khuyến nghị sử dụng rộng rãi trên mainnet. Các trình xác thực, đã đến lúc nâng cấp!

Mức độ sẵn sàng cho Alpenglow

Phần lớn nền tảng cho bản nâng cấp đồng thuận Alpenglow đang được triển khai trong chu kỳ phát hành Agave 4.1. Những thay đổi này chuẩn bị cho quá trình chuyển đổi mạng từ Tower BFT sang Alpenglow, bao gồm quản lý khóa BLS trong chương trình bỏ phiếu, Validator Admission Tickets và các marker Fast Leader Handover.

Cụm thử nghiệm cộng đồng

Lộ trình còn lại để kích hoạt Alpenglow trên mainnet hiện phụ thuộc nhiều vào hoạt động thử nghiệm thực tế trên diện rộng. Kể từ tháng 5, một cụm thử nghiệm cộng đồng gồm khoảng 100 trình xác thực phân bố ở nhiều khu vực địa lý đã chạy bản nâng cấp trong môi trường mạng trực tiếp, kiểm thử quá trình chuyển đổi giữa cơ chế đồng thuận hiện tại của Solana dựa trên Tower BFT và Alpenglow trước khi kích hoạt trên mainnet.

Mục tiêu là giúp quá trình ra mắt diễn ra suôn sẻ nhất có thể. Các trình xác thực trong cụm đã chuyển đổi qua lại giữa Tower BFT và Alpenglow, kiểm tra lộ trình di chuyển trong điều kiện vận hành thực tế thay vì chỉ dựa vào thử nghiệm nội bộ có kiểm soát. Các cuộc thảo luận đang diễn ra trong kênh `ag-community-cluster` trên Solana Tech Discord, còn hoạt động trực tiếp của cụm có thể được theo dõi qua các bảng điều khiển cộng đồng từ Valid Blocks, Staking Facilities và Noders.

Quản lý khóa công khai BLS

SIMD-0387: Quản lý khóa công khai BLS trong vote account sẽ được kích hoạt trong chu kỳ phát hành Agave 4.1. Thay đổi này bổ sung hạ tầng chương trình bỏ phiếu cần thiết để các trình xác thực đăng ký khóa công khai BLS trong vote account trước Alpenglow. Alpenglow sử dụng chữ ký tổng hợp BLS để giảm chi phí tổng hợp và xác minh phiếu bầu, nhưng khóa công khai BLS khác với khóa thẩm quyền bỏ phiếu Ed25519 đang được sử dụng. 

Các trình xác thực có thể thêm khóa công khai BLS vào vote account trong khi tiếp tục vận hành bằng khóa thẩm quyền bỏ phiếu Ed25519 hiện có. Sau khi Alpenglow hoạt động, các vote account chưa đăng ký khóa công khai BLS sẽ không thể tham gia quy trình bỏ phiếu mới.

Alpenglow Validator Admission Tickets (VAT)

Chu kỳ phát hành Agave 4.1 cũng sẽ kích hoạt SIMD-0357 trên mainnet, triển khai Validator Admission Tickets (VAT). VAT được thiết kế để duy trì cấu trúc chi phí tương tự cho trình xác thực khi Solana chuyển khỏi mô hình transaction bỏ phiếu hiện tại của Tower BFT.

Hiện nay, các trình xác thực liên tục trả phí transaction bỏ phiếu khi tham gia bỏ phiếu, tổng cộng lên đến ~2.1 SOL mỗi epoch đối với những trình xác thực bỏ phiếu đều đặn. Trong Alpenglow, các transaction bỏ phiếu này được thay thế bằng một thiết kế đồng thuận mới, vì vậy SIMD-0357 đưa ra chi phí gia nhập một lần mỗi epoch. Mỗi trình xác thực đủ điều kiện tham gia bỏ phiếu Alpenglow phải trả VAT 1.6 SOL mỗi epoch, duy trì một rào cản kinh tế tương đương đồng thời giảm nguy cơ tập hợp trình xác thực mở rộng tức thời và thiếu kiểm soát sau khi Alpenglow ra mắt.

Quá trình triển khai được xử lý tại ranh giới epoch. Khi chuyển sang epoch mới, runtime tính toán tập hợp trình xác thực cho epoch tiếp theo, lọc các vote account có cả khóa công khai BLS đã đăng ký lẫn đủ lamport để thanh toán VAT và tiền thuê, sau đó khấu trừ VAT từ vote account của các trình xác thực được chấp nhận. Số lamport đó được gửi thẳng đến account incinerator. Nếu có hơn 2.000 trình xác thực đủ điều kiện, tập hợp bỏ phiếu sẽ được giới hạn theo trọng số stake và chọn các trình xác thực đủ điều kiện đứng đầu.

Về mặt vận hành, thay đổi này ảnh hưởng đến nơi đơn vị vận hành trình xác thực cần lưu giữ tiền. Phí transaction bỏ phiếu hiện được thanh toán từ account danh tính của trình xác thực, vốn phải là một hot keypair để phục vụ hoạt động bình thường. Với VAT, chi phí gia nhập sẽ được khấu trừ từ vote account.

Marker Fast Leader Handover

Cuối cùng, việc kích hoạt SIMD-0337: Marker cho Alpenglow Fast Leader Handover sẽ bổ sung các marker block mới, cho phép một leader Alpenglow khai báo block cha của một block ngay từ đầu block và cập nhật block cha đó khi cần trong lúc truyền trực tiếp block. Các marker này hỗ trợ Fast Leader Handover, được thiết kế để giảm độ trễ đồng bộ giữa các leader.

XDP được áp dụng rộng rãi hơn và lộ trình đạt 100 triệu CU

XDP (eXpress Data Path) là đường dẫn mạng hiệu năng cao mà Agave dùng để tăng tốc Turbine. Công nghệ này cho phép Agave tải một chương trình eBPF gần card giao tiếp mạng, giúp lưu lượng shred bỏ qua phần lớn quy trình xử lý gói tin tiêu chuẩn của Linux. Việc áp dụng XDP là yếu tố thiết yếu để mạng đạt được mục tiêu lâu dài là các block 100 triệu CU. 

Mức độ áp dụng hiện đã vượt qua một ngưỡng quan trọng. Đầu tháng này, mạng đã chứng kiến sự kiện “đảo chiều,” khi số leader chạy XDP vượt số leader không chạy XDP. Hiện tại, hơn hai phần ba mạng đã kích hoạt XDP. Agave 4.1 phản ánh mức độ trưởng thành đó bằng cách loại bỏ nhãn thử nghiệm khỏi tính năng hỗ trợ XDP và thay thế các cờ `--experimental-retransmit-xdp-*` cũ bằng `--xdp-interface`, `--xdp-cpu-cores` và `--xdp-zero-copy`. Trong Agave 4.2, XDP dự kiến sẽ được bật theo mặc định.

Đối với các đơn vị vận hành trình xác thực vẫn chưa chuyển đổi, trang nâng cấp của Solana Foundation và hướng dẫn thiết lập của Anza cung cấp danh sách kiểm tra khả năng tương thích thực tế, bao gồm hỗ trợ kernel, phần cứng mạng, năng lực của trình xác thực, cờ khởi động và các bước xác minh. Dưới đây là hướng dẫn hữu ích về khả năng tương thích của driver và NIC.

Thêm nhiều chương trình được viết lại bằng Pinocchio

Việc p-token ra mắt thành công gần đây đã chứng minh rằng viết lại có mục tiêu các chương trình được sử dụng nhiều nhất của Solana có thể mang lại mức tiết kiệm tài nguyên tính toán đáng kể trên toàn mạng. Là giải pháp thay thế trực tiếp cho chương trình SPL Token, p-token giảm khoảng 95% mức tiêu thụ đơn vị tính toán (CU), tương đương hiệu suất cao hơn ~19 lần đối với các transaction token tiêu chuẩn. Trước đây, các chỉ thị của chương trình token chiếm khoảng 10% mức sử dụng CU trên toàn block. Bằng cách giảm chi phí của các chỉ thị đó xuống còn khoảng 5% so với trước đây, p-token đã giải phóng gần 9.5% tổng dung lượng block.

Chữ “p” trong p-token là viết tắt của Pinocchio, một thư viện tối ưu, hiệu năng cao và không có dependency để viết chương trình Solana do Anza phát triển. Pinocchio thay thế crate solana-program tiêu chuẩn, vốn sử dụng rộng rãi các kiểu zero-copy để xử lý dữ liệu chỉ thị và account.

Anza hiện đang viết lại các chương trình cốt lõi khác bằng Pinocchio. Mục tiêu không phải là đưa ra các tiêu chuẩn mới hay buộc ứng dụng phải di chuyển, mà là giảm mạnh chi phí thực thi của các chương trình hiện có và được sử dụng rộng rãi.

Chương trình P-memo

Ví dụ đầu tiên là p-memo, phiên bản triển khai lại chương trình SPL Memo bằng Pinocchio, hiện đã hoạt động trên mainnet. Chương trình Memo có quy mô nhỏ, nhưng mức tăng hiệu suất vẫn rất ấn tượng. Khi không có signer, p-memo tiêu thụ 287 CU so với 2.022 CU của chương trình Memo hiện tại, tương đương khoảng 14% chi phí hiện có. Khi có signer, chênh lệch còn rõ rệt hơn: với một signer, p-memo sử dụng 513 CU so với 13.525 CU; với hai signer, 628 CU so với 25.111 CU; và với ba signer, 743 CU so với 36.406 CU. Điều này có nghĩa là trong những trường hợp có nhiều signer, p-memo giảm mức tiêu thụ tài nguyên tính toán xuống chỉ còn 2–4% chi phí của chương trình hiện tại.

Chương trình P-ATA

Công việc trên p-ATA, phiên bản triển khai lại chương trình Associated Token Account bằng Pinocchio, cũng đang được tiến hành. Chương trình ATA xác định ánh xạ tiêu chuẩn giữa một ví, một token mint và token account dùng để nắm giữ token từ mint đó. Chương trình cung cấp cách xác định account token liên kết của người dùng một cách tất định và cho phép bất kỳ ai tạo account đó cho người nhận nếu nó chưa tồn tại. 

Chương trình ATA là chương trình được gọi nhiều thứ năm trên mạng. Theo ước tính của nhóm Anza, chương trình này xuất hiện trong ~11.9% tổng số transaction và chiếm ~13.3% tổng mức tiêu thụ CU. Bản viết lại có thể giảm 80.9% mức sử dụng CU trung bình có trọng số, đồng thời dự kiến tiết kiệm thêm nhờ các chỉ thị mới được bổ sung cùng p-ATA. Với mức sử dụng mạng hiện tại, điều đó sẽ giúp tiết kiệm khoảng 10% CU trên toàn mainnet. Trong mẫu thử của Anza, p-ATA đã giải phóng hơn 2,78 triệu CU trên mỗi block.

P-token, p-memo và p-ATA nhiều khả năng chưa phải là điểm kết thúc của công việc này. Chương trình Token-2022 là một chương trình khác được yêu cầu rất nhiều. Nhìn rộng hơn, nỗ lực của Anza nhằm giúp các chương trình cốt lõi `no_std` đặt nền móng cho việc viết lại thêm nhiều chương trình nền tảng của Solana với ít dependency và chi phí tính toán thấp hơn.

Giảm overhead tại entrypoint của chương trình

Một thay đổi liên quan dự kiến được kích hoạt trong chu kỳ phát hành Agave 4.1 là SIMD-0449: Con trỏ account trực tiếp trong đầu vào chương trình, giúp tối ưu entrypoint của chương trình. Hiện nay, các chương trình sBPF ABIv1 phải phân tích phần account đã tuần tự hóa trong đầu vào chương trình để tìm ranh giới account và tạo slice account được truyền vào chương trình. SIMD-0449 thay đổi quy trình này bằng cách để VM nối thêm một slice chứa các con trỏ account trực tiếp vào đầu vào chương trình, sử dụng thông tin ranh giới mà VM đã biết khi chuẩn bị lời gọi.

Điều này đặc biệt phù hợp với các chương trình theo phong cách Pinocchio vì quá trình phân tích account chiếm phần lớn chi phí entrypoint. Với con trỏ account trực tiếp, entrypoint có thể truy cập account mà không cần lặp qua toàn bộ phần account, khiến tài nguyên tính toán tại entrypoint gần như không đổi bất kể số lượng account. 

Trong các benchmark mới nhất, một entrypoint Pinocchio có 64 account giảm từ 504 CU xuống mức ước tính 7 CU, trong khi các tập hợp account nhỏ hơn cũng hội tụ về cùng mức chi phí thấp là 7 CU.

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

Một trong những cải tiến hiệu năng được mong đợi nhất là giảm thời gian slot mục tiêu của Solana từ 400ms xuống 200ms. Thay đổi này khó có thể được triển khai trong chu kỳ phát hành Agave 4.1 và nhiều khả năng sẽ lên mainnet cùng Agave 4.2. Tuy nhiên, động lực đưa bản nâng cấp quan trọng này lên mainnet sớm nhất có thể đang ngày càng lớn.

SIMD-0525: Giảm thời gian slot đề xuất triển khai theo từng giai đoạn, chuyển từ slot 400ms xuống 350ms, sau đó 300ms, 250ms và cuối cùng đạt 200ms. Mỗi bước đều được kiểm soát bằng cổng tính năng, cho phép các nhóm client và đơn vị vận hành quan sát mạng ở thời gian slot ngắn hơn trước khi chuyển sang giai đoạn tiếp theo. Anza đã thử nghiệm nội bộ slot 200ms trong nhiều tháng và nhóm tin rằng mạng đã sẵn sàng để giảm mạnh thời gian slot. Những cải tiến ở giai đoạn replay đã giúp thay đổi này trở nên khả thi hơn: việc replay toàn bộ một slot 400ms hiện mất khoảng 40ms.

Động lực rất rõ ràng. Slot ngắn hơn giúp giảm độ trễ xác nhận và hoàn tất cho người dùng. Chúng cũng rút ngắn cửa sổ của mỗi leader. Hiện nay, khoảng thời gian leader của Solana kéo dài bốn slot liên tiếp, mang lại cho leader một cửa sổ 1,6 giây với slot 400ms. Với slot 200ms, cửa sổ đó giảm xuống còn 800ms. Điều này cải thiện cấu trúc thị trường bằng cách giảm khoảng thời gian tối đa mà một leader độc hại có thể trì hoãn, sắp xếp lại hoặc chọn lọc transaction để đưa vào trước khi leader tiếp theo có cơ hội tạo block.

Slot ngắn hơn cũng cung cấp cho ứng dụng góc nhìn chi tiết hơn về thời gian onchain. Điều đó rất quan trọng đối với các hệ thống đánh giá độ mới của slot, bao gồm các ứng dụng sử dụng oracle và nhà tạo lập thị trường độc quyền theo mô hình AMM.

Đề xuất được thiết kế cẩn thận để tránh làm thay đổi cơ chế kinh tế của Solana. `slots_per_year` được tăng theo tỷ lệ nghịch, duy trì lịch phát hành SOL. Trong Alpenglow, chi phí Validator Admission Ticket (VAT) cũng tăng giảm theo giai đoạn thời gian slot, giữ chi phí gia nhập gần mức dự kiến là ~0.8 SOL mỗi ngày. Ngoài ra, giới hạn công việc trên mỗi slot được giảm theo tỷ lệ tương ứng với thời gian slot mục tiêu ngắn hơn, vì vậy khối lượng công việc mạng có thể xử lý mỗi giây gần như không đổi. 

Một số giả định cốt lõi vẫn không thay đổi. Khoảng thời gian của leader vẫn là bốn slot, mỗi epoch vẫn cố định ở 432.000 slot và số tick trên mỗi slot vẫn là 64. Vì epoch vẫn cố định theo số lượng slot, slot 200ms sẽ rút ngắn độ dài của một epoch từ khoảng hai ngày xuống còn một ngày.

Một điểm gây tranh luận là tác động đến chi phí bỏ phiếu của trình xác thực nếu thời gian slot ngắn hơn được kích hoạt trước Alpenglow. Slot nhanh hơn đồng nghĩa với nhiều phiếu bầu hơn mỗi ngày và do đó chi phí bỏ phiếu hằng ngày của trình xác thực cũng cao hơn. Chi phí transaction bỏ phiếu là khoản chi đơn lẻ lớn nhất đối với đơn vị vận hành trình xác thực. Các transaction bỏ phiếu có mức giá cố định là 0.000005 SOL và mỗi ngày, chi phí cho các transaction này lên tới ~1.086 SOL. Với slot 200ms, các chi phí đó sẽ tăng gần gấp đôi.

Các 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 được kích hoạt trong chu kỳ phát hành Agave 4.1, từ tỷ lệ hoa hồng chính xác hơn cho trình xác thực đến các primitive mật mã mới và việc loại bỏ một vector tấn công từ chối dịch vụ trong loader có thể nâng cấp.

Tăng độ chính xác của tỷ lệ hoa hồng trình xác thực

Trong chu kỳ phát hành Agave 4.1, bản nâng cấp được kiểm soát bằng cổng tính năng SIMD-0291: Tỷ lệ hoa hồng tính theo điểm cơ bản sẽ được kích hoạt trên mainnet. Hiện nay, tỷ lệ hoa hồng của trình xác thực chỉ có thể được đặt theo điểm phần trăm nguyên. Điều đó có nghĩa là một trình xác thực có thể đặt hoa hồng ở mức 5% hoặc 6%, nhưng không thể đặt 5.5%, 5.25% hay 5.01%.

Với bản cập nhật này, các trình xác thực có quyền kiểm soát chi tiết hơn bằng cách đặt tỷ lệ hoa hồng theo điểm cơ bản, trong đó 100 điểm cơ bản tương đương 1%. Chương trình bỏ phiếu bổ sung một chỉ thị `UpdateCommissionBps` mới, cho phép người rút tiền được ủy quyền trên vote account cập nhật hoa hồng phần thưởng lạm phát của trình xác thực với độ chính xác cao hơn. Đối với các trình xác thực, thay đổi này giúp thiết lập hoa hồng linh hoạt và cạnh tranh hơn.

Thay đổi này là một trong nhiều bản cập nhật liên quan đến Vote Account V4 mới. Nó cũng giúp chuẩn bị mạng cho thời điểm dự kiến kích hoạt SIMD-0123: Phân phối doanh thu block, cho phép phân phối phần thưởng block ngay trong giao thức.

Syscall SHA-512

SIMD-0512: Syscall Sha512 giới thiệu một syscall mới, cung cấp cho các chương trình onchain quyền truy cập trực tiếp vào phép băm SHA-512 thông qua runtime, sử dụng giao diện tương tự các syscall băm hiện có như `sol_sha256`, `sol_keccak256` và `sol_blake3`.

SHA-512 là một primitive cốt lõi được sử dụng trong quá trình xác minh chữ ký Ed25519 và đã tồn tại dưới dạng dependency nội bộ trong cả client trình xác thực Agave lẫn Firedancer. Tuy nhiên, cho đến nay nó vẫn chưa được cung cấp cho các chương trình onchain. Việc trực tiếp băm một thông điệp ngắn onchain rất tốn kém và sẽ tiêu thụ hàng nghìn CU, so với chưa đến 100 CU khi thực hiện qua syscall.

Với `sol_sha512`, các chương trình có thể tính toán hàm băm SHA-512 với chi phí syscall và trực tiếp nhận giá trị digest 64 byte tiêu chuẩn. Đây là thay đổi bổ sung và được kiểm soát bằng cổng tính năng, vì vậy các chương trình không sử dụng syscall mới sẽ không bị ảnh hưởng, còn các syscall băm hiện có vẫn không thay đổi.

Tăng cường bảo mật cho loader có thể nâng cấp

Chu kỳ phát hành Agave 4.1 cũng sẽ chứng kiến việc phát hành có kiểm soát bằng cổng tính năng của SIMD-0431: Loader V3: Kích thước mở rộng chương trình tối thiểu, bổ sung kích thước mở rộng tối thiểu cho chỉ thị `ExtendProgram` của Loader V3. Sau khi tính năng này được kích hoạt, các chương trình phải được mở rộng ít nhất 10.240 byte (10 KiB), trừ khi account dữ liệu chương trình đã cách kích thước account tối đa 10 MiB không quá 10 KiB.

Thay đổi này xử lý một vector tấn công từ chối dịch vụ tinh vi trong loader có thể nâng cấp hiện tại. `ExtendProgram` không cần cấp quyền, nghĩa là bất kỳ ai cũng có thể mở rộng account dữ liệu của một chương trình có thể nâng cấp, dù chỉ thêm một byte. Vì mỗi lần mở rộng đều vô hiệu hóa mục cache của chương trình cho slot hiện tại, một lần mở rộng thêm một byte với chi phí thấp có thể tạm thời làm gián đoạn quyền truy cập vào chương trình.

Thay vì yêu cầu cấp quyền cho `ExtendProgram`, thay đổi này giữ nguyên thiết kế không cần cấp quyền của chỉ thị nhưng khiến hành vi lạm dụng không còn hấp dẫn về mặt kinh tế. Với mức tối thiểu mới là 10 KiB, mỗi lần mở rộng tốn khoảng 0.072 SOL dưới dạng lamport miễn tiền thuê.

Đối với các bản nâng cấp chương trình hợp lệ, tác động sẽ ở mức hạn chế. Các chương trình cần ít hơn 10 KiB dung lượng bổ sung sẽ phải mở rộng đủ mức tối thiểu, nhưng phần dung lượng thừa vẫn có thể được sử dụng cho các bản nâng cấp trong tương lai. SIMD cũng giữ nguyên các account của chỉ thị, yêu cầu về signer, giới hạn CPI và quy trình multisig hiện có.

Kết luận

Agave 4.1 là một bản nâng cấp client lớn, kết hợp nhiều cải tiến và tối ưu hóa hiệu năng. Trong tương lai, Agave 4.2 có thể còn mang tính bước ngoặt hơn nữa, với kích thước transaction lớn hơn ở mức 4096 byte, thời gian slot giảm xuống 200ms và có thể cả bản nâng cấp đồng thuận Alpenglow được mong đợi từ lâu.

Tài nguyên bổ sung

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