Bản cập nhật Agave 4.3: Tất cả những gì bạn cần biết

Giới thiệu

Với Agave 4.3, Solana đang chuẩn bị cho một trong những nâng cấp giao thức lớn nhất từ trước đến nay. Chu kỳ phát hành 4.3 sẽ mở đường cho Alpenglow, cơ chế đồng thuận mới rất được mong đợi của Solana, và đạt đến đỉnh điểm với "Alpenswitch": quá trình chuyển đổi mainnet có phối hợp khỏi TowerBFT.

Kể từ khi ra mắt, kiến trúc đồng thuận của Solana được xây dựng trên Proof of History và TowerBFT. Các trình xác thực bỏ phiếu bằng cách gửi giao dịch, sau đó các giao dịch này được xử lý và đưa vào khối cùng với giao dịch thông thường của người dùng. Tính hoàn tất dần được tích lũy khi các phiếu bầu tăng lên trong 32 slot, mang lại cho Solana thời gian hoàn tất khoảng 12,8 giây (giả sử mỗi slot kéo dài 400 mili giây).

Proof of History (PoH) là một trong những đổi mới kiến trúc mang tính định hình của Solana khi ra mắt, với cách tiếp cận độc đáo để sắp xếp sự kiện và đồng bộ thời gian. Vì vậy, việc công nghệ này cuối cùng ngừng được sử dụng đánh dấu sự kết thúc của một thời kỳ, đồng thời cho thấy giao thức đã tiến xa đến đâu so với những công nghệ từng tạo nên sự khác biệt ban đầu.

Alpenglow thay thế 'PoH + TowerBFT' bằng Votor, một giao thức trong đó các trình xác thực trao đổi phiếu bầu bên ngoài quy trình giao dịch cốt lõi. Giao thức tổng hợp các phiếu bầu này thành chứng nhận mật mã. Thiết kế hướng tới thời gian hoàn tất khoảng 150 mili giây.

Người dùng và ứng dụng gửi giao dịch cũng như đọc trạng thái tài khoản hầu như không phải di chuyển gì. Giao dịch và cơ chế phí vẫn không thay đổi. Các trình xác thực và hạ tầng sử dụng khối, phiếu bầu, luồng hoặc dữ liệu cam kết sẽ chịu ảnh hưởng lớn nhất.

Giao dịch bỏ phiếu biến mất khỏi các khối, confirmed và finalized về cơ bản hội tụ, còn hạ tầng truyền phát có thêm thông tin mới để phân biệt các bank cạnh tranh trong cùng một slot.

Trong bài viết này, chúng ta sẽ tìm hiểu cách Alpenglow hoạt động, bao gồm những thay đổi mà Votor mang đến cho quá trình tạo khối và tính hoàn tất. Chúng ta cũng sẽ đề cập đến các thay đổi đáng chú ý khác trong chu kỳ phát hành Agave 4.3.

Triển khai theo giai đoạn: Votor trước, sau đó là Rotor

Alpenglow được thiết kế xoay quanh hai thành phần chính: Votor, thay thế cơ chế bỏ phiếu và hoàn tất của Solana, và Rotor, thiết kế lại cách các khối được truyền trên mạng. Hai cơ chế này sẽ được triển khai theo từng giai đoạn, với Votor ra mắt trước.

Agave 4.3 giới thiệu Votor nhưng vẫn giữ giao thức truyền khối hiện tại là Turbine. Rotor đã được loại trừ rõ ràng khỏi SIMD-0326, đề xuất chi phối quá trình kích hoạt Alpenglow ban đầu. Rotor sẽ cần một SIMD riêng trước khi có thể triển khai. Đợt triển khai ban đầu thay đổi cách các trình xác thực đạt được đồng thuận, nhưng chưa thay đổi cách dữ liệu khối di chuyển trên mạng.

Votor

Votor thay thế các giao dịch bỏ phiếu và hệ thống khóa phiếu của TowerBFT bằng một giao thức trực tiếp hơn giữa các trình xác thực. Trong TowerBFT, các trình xác thực bỏ phiếu bằng cách gửi giao dịch được đưa vào khối, rồi dần tích lũy đủ độ sâu khóa phiếu để khối được hoàn tất. Với Votor, các trình xác thực trao đổi trực tiếp các thông điệp phiếu bầu đã ký, còn giao thức tổng hợp các chữ ký đó thành những chứng nhận nhỏ gọn.

Thay vì chờ phiếu bầu tích lũy qua 32 slot, Votor có thể hoàn tất một khối sau một hoặc hai vòng bỏ phiếu. Giao thức hướng tới thời gian hoàn tất khoảng 150 mili giây, so với khoảng 12,8 giây của TowerBFT.

Votor có hai lộ trình hoàn tất hoạt động đồng thời.

Nếu ít nhất 80% lượng stake công chứng một khối trong vòng đầu tiên, các phiếu bầu đó có thể được tổng hợp thành Fast-Finalization Certificate và khối sẽ được hoàn tất ngay lập tức. Đây là lộ trình nhanh của giao thức và chỉ cần một vòng bỏ phiếu.

Nếu không đạt ngưỡng 80%, một khối vẫn có thể tiến tiếp nếu hơn 60% lượng stake đã bỏ phiếu công chứng khối đó. Điều này tạo ra Notarization Certificate, cho phép diễn ra vòng bỏ phiếu thứ hai. Khi hơn 60% lượng stake bỏ phiếu hoàn tất qua lộ trình hai vòng, quá trình này tạo thành Finalization Certificate và khiến khối được hoàn tất.

Do đó, giao thức đầy đủ có năm loại phiếu bầu: Notarization, Notarization Fallback, Skip, Skip Fallback và Final. Các tổ hợp khác nhau của những phiếu bầu này tạo ra chứng nhận công chứng, dự phòng, bỏ qua hoặc hoàn tất. Những chứng nhận này đóng vai trò là bằng chứng mật mã nhỏ gọn cho thấy đủ lượng stake đã đồng thuận về kết quả của một slot.

Votor được thiết kế để tiếp tục tiến triển chỉ với 60% lượng stake trung thực có phản hồi, cho phép tối đa 20% lượng stake có hành vi đối nghịch trong khi 20% khác ngoại tuyến hoặc không phản hồi. Đây là sự đánh đổi có chủ đích: Alpenglow từ bỏ ngưỡng Byzantine một phần ba truyền thống của các thiết kế BFT để đổi lấy mô hình chống chịu 20+20, với khả năng chịu đựng tốt hơn khi trình xác thực gặp sự cố hoặc không khả dụng.

Votor cũng loại bỏ việc dùng Proof of History làm đồng hồ đồng thuận. Thay vào đó, các trình xác thực sử dụng bộ định thời chờ cục bộ. Nếu đã chờ đủ lâu mà không nhận được khối phù hợp, trình xác thực có thể bỏ phiếu bỏ qua và cho phép quá trình đồng thuận tiếp tục. Cách này đơn giản hóa mối quan hệ giữa việc đo thời gian và đồng thuận so với TowerBFT.

Rotor

Rotor không thuộc Agave 4.3 và hiện chưa có ngày kích hoạt được công bố. Vì vậy, Turbine sẽ tiếp tục truyền dữ liệu khối khi Votor được kích hoạt. Rotor, cùng cơ chế lấy mẫu thông minh dùng để chọn các relay, sẽ được đưa vào một đề xuất và đợt triển khai riêng sau này.

Điều quan trọng là việc này không có nghĩa Solana phải chờ Rotor để đạt thời gian hoàn tất dưới một giây. Đợt triển khai Alpenglow hiện tại hướng tới thời gian hoàn tất khoảng 150 mili giây với Votor trong Agave 4.3, trong khi Turbine vẫn được giữ nguyên. Rotor được thiết kế để tiếp tục cải thiện khả năng phân phối khối và tăng hiệu quả cho kiến trúc Alpenglow tổng thể, nhưng không phải điều kiện tiên quyết cho mô hình hoàn tất mới của Votor.

Không còn giao dịch bỏ phiếu

Một trong những hệ quả dễ thấy nhất của Alpenglow là giao dịch bỏ phiếu sẽ biến mất khỏi các khối Solana. Các trình xác thực phải trả phí giao dịch cho những phiếu bầu này, còn mạng phải tiêu tốn băng thông, tài nguyên tính toán và không gian sổ cái để xử lý và lưu trữ chúng.

Trước đây, giao dịch bỏ phiếu chiếm khoảng ba phần tư tổng số giao dịch được ghi nhận onchain, dù tỷ lệ này đã giảm khi dung lượng khối tăng lên. Mặc dù giao dịch bỏ phiếu có chi phí thấp (5.000 lamport) và chỉ chiếm một phần nhỏ (khoảng 5%) tổng tài nguyên tính toán, chúng làm tăng số lượng giao dịch thô và dung lượng sổ cái của mạng.

Thay vào đó, với Alpenglow, các trình xác thực trao đổi trực tiếp với nhau những thông điệp phiếu bầu được ký bằng BLS. ConsensusPool của Agave theo dõi các phiếu bầu đã quan sát được và tổng hợp đủ lượng stake thành các chứng nhận mà Votor sử dụng để thúc đẩy hoặc hoàn tất đồng thuận.

Điều đó không có nghĩa bằng chứng về sự tham gia của trình xác thực biến mất khỏi sổ cái. Các khối Alpenglow giới thiệu một phần chân khối mới chứa thông tin đồng thuận. Trong cách triển khai Agave hiện tại, BlockFooterV1 có thể chứa chứng nhận hoàn tất mới nhất cũng như notar_reward_cert và skip_reward_cert. Các chứng nhận phần thưởng bao gồm một chữ ký BLS tổng hợp và bitmap xác định những trình xác thực đã bỏ phiếu.

Các hệ thống hiện xác định liệu một trình xác thực đã bỏ phiếu hay chưa bằng cách lập chỉ mục giao dịch Vote Program sẽ phải chuyển sang dùng các chứng nhận và dữ liệu liên quan đến phiếu bầu của Alpenglow. Những quy trình giao dịch hiện chỉ lọc giao dịch bỏ phiếu nhìn chung vẫn có thể tiếp tục hoạt động; sau Alpenswitch, bộ lọc đơn giản là không còn gì để loại bỏ.

Quá trình chuyển đổi cũng tạo ra sự gián đoạn trong các số liệu TPS quen thuộc của Solana. Khi Alpenglow được kích hoạt, các phép đo TPS thô có tính giao dịch bỏ phiếu sẽ giảm mạnh ngay cả khi hoạt động của người dùng hoàn toàn không thay đổi. Vì vậy, TPS không tính phiếu bầu là chỉ số có ý nghĩa để so sánh hoạt động trước và sau Alpenswitch. Việc loại bỏ giao dịch bỏ phiếu xóa bỏ một nguồn gây nhầm lẫn lâu nay về thông lượng thực tế của Solana và giúp việc so sánh với các mạng tương đương trở nên dễ dàng hơn.

Việc loại bỏ giao dịch bỏ phiếu giải phóng một phần dung lượng cho người dùng, nhưng không nên phóng đại tác động này vì phiếu bầu chỉ chiếm một phần tương đối nhỏ trong tải tính toán của mạng.

Các mức cam kết

Alpenglow cũng xóa bỏ một trong những khác biệt tồn tại lâu nay của Solana: khoảng cách giữa mức cam kết confirmed và finalized.

Hiện nay, các ứng dụng lựa chọn giữa ba mức cam kết. processed cung cấp trạng thái mới nhất nhưng không có bảo đảm trên toàn cụm. confirmed nghĩa là đại đa số lượng stake đã bỏ phiếu cho khối, thường đạt được trong một hoặc hai slot. finalized cung cấp tính hoàn tất tất định, nhưng trong TowerBFT, khối phải đạt mức khóa phiếu tối đa, tạo ra khoảng cách khoảng 32 slot giữa xác nhận và hoàn tất. Nhìn chung, confirmed được khuyến nghị cho các yêu cầu RPC nhạy cảm với độ trễ, còn finalized phù hợp khi cần mức bảo đảm cao hơn.

Trong thực tế, confirmed đã chứng minh độ tin cậy rất cao: chưa từng có khối Solana nào được xác nhận lạc quan nhưng sau đó không thể hoàn tất. Tuy nhiên, bảo đảm của giao thức vẫn yếu hơn. Một khối đã xác nhận vẫn chưa hoàn tất theo cách tất định, nên các ứng dụng như cầu nối, sàn giao dịch và hệ thống quyết toán không thể chấp nhận phần rủi ro còn lại này trước đây vẫn phải chờ finalized.

Alpenglow loại bỏ sự đánh đổi này. Khi Votor tạo ra chứng nhận hoàn tất nhanh hoặc chứng nhận hoàn tất, khối sẽ được hoàn tất. Khi Votor chọn một bank đã hoàn tất làm root, trình xác thực sẽ đồng thời cập nhật slot được xác nhận cao nhất, root và root có đại đa số cao nhất.

Đối với nhà phát triển, điều này có nghĩa confirmed và finalized về cơ bản trỏ đến cùng một trạng thái đồng thuận sau Alpenswitch. Các ứng dụng hiện có không cần thay đổi cài đặt cam kết vào ngày kích hoạt, vì giao diện RPC vẫn chấp nhận processed, confirmed và finalized, nhưng chênh lệch độ trễ giữa hai mức sau sẽ biến mất.

Người dùng RPC thông thường không nhìn thấy sự khác biệt giữa hai lộ trình hoàn tất của Votor. Dù một khối đạt ngưỡng hoàn tất nhanh 80% trong một vòng hay hoàn tất qua lộ trình hai vòng với ngưỡng 60%, kết quả hiển thị ra bên ngoài đều giống nhau.

Nhiều khối ứng viên

Một thay đổi quan trọng khác trong Alpenglow nhắm đến các nhà cung cấp RPC, bộ lập chỉ mục và hạ tầng khác sử dụng dữ liệu trình xác thực. Một slot không còn có thể được xem là mã định danh khối duy nhất.

Slot Solana là khoảng thời gian mà một leader có thể tạo khối. Trong khi đó, bank là biểu diễn cục bộ của trình xác thực về trạng thái được tạo ra khi thực thi một khối ứng viên cụ thể. Các khái niệm này vốn luôn khác biệt và bank cạnh tranh không phải điều mới, nhưng phần lớn hạ tầng thực tế từ trước đến nay vẫn xem slot và khối là một.

Alpenglow khiến giả định đó ngày càng thiếu an toàn.

Agave 4.3 mở rộng Geyser (giao diện trình xác thực dùng để truyền phát các bản cập nhật tài khoản, giao dịch, mục nhập và khối) bằng một mã định danh mới: bank_id. Các callback mới có nhận biết bank, bao gồm update_account_for_bank, notify_transaction_for_bank, notify_entry_for_bank và notify_block_metadata_for_bank, liên kết một sự kiện với bank cụ thể đã tạo ra sự kiện đó. Tương tự, thông báo trạng thái theo phạm vi bank cũng mang theo bank_id. Các callback cũ vẫn được giữ để tương thích trong phiên bản 4.3 nhưng đã bị đánh dấu ngừng dùng và dự kiến bị loại bỏ trong bản phát hành Agave lớn tiếp theo.

Điểm quan trọng là bank_id xác định một phiên bản bank cục bộ, không phải một khối được thống nhất trên toàn mạng. Agave tạo ID bank từ một bộ đếm nguyên tử cục bộ do runtime của trình xác thực duy trì, vì vậy không nên kỳ vọng hai trình xác thực phát lại cùng một khối sẽ gán cùng một bank_id. Do đó, hạ tầng nên dùng (slot, bank_id) để phân tách các luồng cạnh tranh đến từ một trình xác thực, nhưng dùng ID khối hoặc blockhash khi đối chiếu dữ liệu giữa các trình xác thực hay kết nối khác nhau.

Các giai đoạn tương lai của Alpenglow sẽ biến việc có nhiều bank cho cùng một slot thành một phần bình thường trong hoạt động của trình xác thực.

Ví dụ rõ ràng nhất là chuyển giao leader nhanh, một trong những thành phần Alpenglow được triển khai sau khi Votor kích hoạt lần đầu. Một leader có thể bắt đầu xây dựng theo cách lạc quan trên parent mà họ dự đoán đồng thuận sẽ chấp nhận. Nếu Votor quyết định rằng parent đó nên bị bỏ qua, leader có thể chuyển parent và xây dựng lại trong phần còn lại của khoảng thời gian làm leader. Về nội bộ, điều đó có nghĩa thay thế một bank bằng bank khác cho cùng một slot. Agave đã có sẵn cơ chế UpdateParent cần thiết để biểu diễn lần chuyển đổi này. Chuyển giao leader nhanh không thuộc đợt kích hoạt Alpenglow ban đầu trong Agave 4.3 và dự kiến được triển khai trong phiên bản 4.4.

Hành vi mâu thuẫn của leader có thể tạo ra kết quả tương tự. Nếu một leader ký và phân phối hai khối khác nhau cho cùng một slot, các trình xác thực có thể tạm thời phải lưu giữ và phân tích cả hai ứng viên. Các phần khác nhau của mạng có thể thấy những ứng viên đó theo thứ tự khác nhau vì Votor hoạt động bất đồng bộ, còn các trình xác thực xử lý khối, phiếu bầu, chứng nhận và thời gian chờ cục bộ theo thứ tự chúng xuất hiện.

Một thay đổi gần đây đã giảm MAX_ALTERNATE_BLOCKS_PER_SLOT từ 11 xuống 6. Vì vậy, một trình xác thực chỉ cần lưu giữ tối đa bảy khối ứng viên cho một slot. Cuối cùng, đồng thuận sẽ quy các ứng viên đó về một lịch sử duy nhất. Trong Votor, việc công chứng cần hơn 60% lượng stake. Hai khối xung đột không thể cùng nhận được chứng nhận công chứng hợp lệ nếu không có một lượng stake đáng kể bỏ phiếu cho cả hai. Theo giả định của Alpenglow rằng chưa đến 20% lượng stake có hành vi Byzantine, các chứng nhận công chứng xung đột là không thể xảy ra nếu không vi phạm các giả định an toàn của giao thức.

Đối với người dùng Geyser, bài học thực tế rất rõ ràng: không còn dùng riêng slot làm khóa cho trạng thái tạm thời. Các thay đổi tài khoản, giao dịch, mục nhập và siêu dữ liệu khối phải được theo dõi theo từng (slot, bank_id) cho đến khi đồng thuận xác định bank còn tồn tại. Nếu một bank khác xuất hiện cho cùng một slot, các sự kiện của bank đó thuộc về một trạng thái ứng viên riêng và không được âm thầm ghi đè lên sự kiện từ bank đầu tiên.

Vé tham gia cho trình xác thực

Giao dịch bỏ phiếu hiện là chi phí lớn nhất khi vận hành trình xác thực Solana. Trong TowerBFT, trình xác thực trả phí giao dịch tiêu chuẩn mỗi lần gửi phiếu bầu, tổng cộng khoảng 2 SOL mỗi epoch. Alpenglow thay phí giao dịch bằng một khoản phí thu một lần mỗi epoch từ các trình xác thực được tiếp nhận vào tập hợp đồng thuận đang hoạt động, gọi là Validator Admission Ticket (VAT).

Nền tảng cho quá trình chuyển đổi này đã hoạt động. Việc đăng ký khóa công khai BLS, được quy định trong SIMD-0387, đã được kích hoạt trên mainnet vào tháng 7, ngay sau đó là cổng tính năng VAT, SIMD-0357. Votor dùng chữ ký BLS để có thể tổng hợp chữ ký từ nhiều trình xác thực thành một chứng nhận nhỏ gọn. Mỗi trình xác thực phải đăng ký một khóa công khai BLS trong tài khoản bỏ phiếu trước khi có thể tham gia Alpenglow. Kể từ khi cổng VAT được kích hoạt, các trình xác thực không có khóa này đã bị loại khỏi tập hợp bỏ phiếu.

Trước Alpenglow, các trình xác thực tiếp tục gửi giao dịch bỏ phiếu thông thường và trả các khoản phí liên quan. Ở giai đoạn này, VAT chủ yếu đóng vai trò là bộ lọc tiếp nhận. Trình xác thực đủ điều kiện phải có khóa BLS và nằm trong nhóm 2.000 trình xác thực đạt yêu cầu hàng đầu theo lượng stake. VAT bắt đầu được áp dụng khi Alpenglow được bật và giao dịch bỏ phiếu biến mất.

Khi Alpenglow hoạt động, việc tiếp nhận được tính toán lại quanh ranh giới epoch. Tài khoản bỏ phiếu của trình xác thực phải chứa khóa BLS đã đăng ký và đủ SOL để chi trả cho vé cùng khoản miễn tiền thuê. Nếu có hơn 2.000 tài khoản đủ điều kiện, hệ thống xếp hạng theo lượng stake và tiếp nhận các trình xác thực có stake cao nhất. Sau đó, hệ thống khấu trừ vé trực tiếp từ tài khoản bỏ phiếu của từng trình xác thực được tiếp nhận và gửi đến tài khoản đốt của Solana. Vì vậy, các trình xác thực cần duy trì đủ tiền trong tài khoản bỏ phiếu; theo hệ thống cũ, phí giao dịch bỏ phiếu được khấu trừ từ tài khoản danh tính của trình xác thực.

Các đề xuất Alpenglow và VAT ban đầu quy định mức vé 1,6 SOL mỗi epoch, tương đương khoảng 80% mức gần 2 SOL mà một trình xác thực trước đây chi cho giao dịch bỏ phiếu. Con số đó giả định mục tiêu slot lịch sử của Solana là 400 mili giây. Thay vào đó, SIMD-0525 điều chỉnh VAT theo thời lượng slot. Chi phí tiếp nhận khi slot kéo dài 200 mili giây sẽ là 0,8 SOL.

VAT cũng thay đổi đích đến của khoản chi phí này. Hiện nay, phí cơ sở 5.000 lamport do một giao dịch bỏ phiếu chi trả được chia đôi: 50% bị đốt và 50% thuộc về leader của khối. Ngược lại, VAT được gửi toàn bộ đến tài khoản đốt. Tuy nhiên, mục đích rộng hơn của VAT không phải là khiến SOL giảm phát đáng kể hơn, mà là duy trì chi phí kinh tế khi tham gia tập hợp đồng thuận sau khi phí giao dịch bỏ phiếu biến mất.

An toàn và công tác chuẩn bị

Thay thế giao thức đồng thuận của một mạng đang hoạt động là một quá trình có rủi ro đặc biệt cao. Vì vậy, Alpenglow có quy trình kiểm thử và di chuyển rộng hơn nhiều so với một lần kích hoạt tính năng Agave thông thường, bao gồm một cụm kiểm thử cộng đồng chuyên dụng và chương trình săn lỗi nhận thưởng.

Kể từ tháng 5, các đơn vị vận hành trình xác thực đã chạy Alpenglow Community Cluster chuyên dụng, hiện đã phát triển lên hơn 100 node. Các đơn vị vận hành sử dụng phần cứng trình xác thực và cấu hình mạng thực tế, cho phép kiểm thử Alpenglow trong điều kiện phân tán địa lý, biến động độ trễ, nhiều cấu hình phần mềm, khởi động lại và lỗi vận hành vốn khó tái tạo trong môi trường được kiểm soát.

Một trong những mục đích quan trọng nhất của cụm là kiểm thử chính Alpenswitch. Thay vì chỉ kiểm tra xem Votor có hoạt động khi một cụm đã chạy Alpenglow hay không, các đơn vị vận hành đã nhiều lần thực hiện quá trình chuyển đổi từ TowerBFT sang hệ thống đồng thuận mới.

Roger Wattenhofer

@TheWattenhofer

We just had the first successful Alpenswitch on our Alpenglow community cluster! The @solana finalization time improved 100x. Thanks to everybody participating. Watch it live: https://ag.validblocks.com/ https://ag-community-status.stakingfacilities.com/

6:59 CH 9 thg 5, 2026

Alpenglow cũng đã trải qua một đợt đánh giá đối nghịch chuyên biệt. Vào tháng 8, Anza đã mở Cuộc thi săn lỗi nhận thưởng Alpenglow kéo dài hai tuần với tổng giải thưởng lên đến 50.000 SOL. Khác với chương trình thưởng Agave thường trực, cuộc thi này tập trung riêng vào stack đồng thuận mới, bao gồm Votor, việc xác minh chữ ký và chứng nhận BLS, tiếp nhận trình xác thực và lộ trình di chuyển từ TowerBFT sang Alpenglow. Số lượng người tham gia rất lớn. Anza báo cáo có hơn 300 bài gửi và cho biết hơn 25.000 SOL sẽ được phân phối làm tiền thưởng.

Hỗ trợ Frankendancer sẽ kết thúc khi Alpenglow xuất hiện. Frankendancer vốn luôn được định hướng là một client chuyển tiếp, kết hợp các thành phần mạng và tạo khối của Firedancer với các thành phần Agave để thực thi và đồng thuận. Việc hỗ trợ hệ thống đồng thuận mới trong kiến trúc lai đó sẽ làm tăng đáng kể gánh nặng bảo trì và bảo mật, nên đội ngũ Firedancer đang tập trung phát triển client Firedancer đầy đủ.

Hướng dẫn được chia sẻ với các trình xác thực cho biết cả Frankendancer lẫn Firedancer đầy đủ đều không hỗ trợ chính khoảng thời gian di chuyển ngắn từ TowerBFT sang Alpenglow. Vì vậy, các đơn vị vận hành Firedancer nên bố trí chuyển dự phòng sang một trình xác thực Agave trước Alpenswitch, duy trì trên Agave trong suốt quá trình bàn giao, sau đó chuyển lại sang Firedancer khi cụm hoạt động bình thường với Alpenglow.

Alpenswitch thực sự diễn ra như thế nào

Alpenglow không được bật ở mọi nơi vào một thời điểm tùy ý theo đồng hồ thực. Sau khi tính năng của Alpenglow được kích hoạt, giao thức xác định một ranh giới di chuyển sau đó 5.000 slot. TowerBFT tiếp tục hoạt động trong khi các trình xác thực vượt qua ranh giới này và tìm kiếm một khối được xác nhận đủ mạnh. Sau đó, các trình xác thực ký BLS cho khối genesis Alpenglow đã chọn và trực tiếp phân phối các phiếu bầu genesis đó cho nhau.

Quá trình bàn giao diễn ra khi ít nhất 82% lượng stake đã ký cùng một khối genesis, tạo ra chứng nhận genesis Alpenglow. Các trình xác thực nhận và xác minh chứng nhận đó sẽ vô hiệu hóa TowerBFT sau khối genesis và khởi tạo Votor từ trạng thái đã thống nhất. Sau đó, chứng nhận được truyền qua tập hợp trình xác thực, đưa các node còn lại vượt qua ranh giới.

Chứng nhận này mang đến cho các đơn vị vận hành hạ tầng một cách thuận tiện để xác định cụm đang ở phía nào của Alpenswitch.

Agave 4.3 giới thiệu phương thức RPC mới getAgGenesisCert. Trước khi di chuyển, một node Agave 4.3 trả về null. Sau khi cụm chuyển đổi, node trả về chứng nhận genesis Alpenglow, bao gồm khối genesis và chữ ký BLS tổng hợp. Một node cũ không hỗ trợ phương thức này sẽ trả về Method not found. CLI cung cấp cùng thông tin qua: solana alpenglow-genesis-info.

Vì vậy, đối với các trình xác thực, nhà cung cấp RPC và hạ tầng khác cần phản ứng với quá trình di chuyển, kiểm tra chứng nhận genesis là cách tốt hơn so với giả định Alpenglow đã hoạt động tại một dấu thời gian cụ thể.

Các syscall mật mã mới

Agave 4.3 cũng mở rộng bộ công cụ mật mã của SVM bằng các primitive runtime mới cho những thao tác có chi phí quá cao nếu thực hiện trực tiếp trong sBPF.

Hai bổ sung đáng chú ý là băm SHA-512 và lũy thừa modulo số nguyên lớn. Cả hai đều là phần bổ sung và được kiểm soát bằng cổng tính năng: các chương trình hiện có không bị ảnh hưởng, còn chương trình chọn sử dụng chúng có thể ủy thác các phép tính mật mã tốn nhiều tài nguyên cho những cách triển khai native đã tối ưu hóa bên trong runtime của trình xác thực.

Lũy thừa modulo số nguyên lớn

SIMD-0529: Syscall ModExp số nguyên lớn giới thiệu sol_big_mod_exp, một syscall để tính:

result = (base ^ exponent) mod modulus

Lũy thừa modulo là phép toán nền tảng cho việc xác minh chữ ký RSA, bộ tích lũy mật mã, một số hàm trì hoãn có thể xác minh và các giao thức lý thuyết số khác. Việc triển khai phép toán này bằng số học số nguyên có độ chính xác tùy ý ngay trong chương trình SVM tiêu tốn rất nhiều tài nguyên tính toán, đặc biệt với các kích thước khóa RSA phổ biến như 2048, 3072 và 4096 bit.

Syscall mới chuyển phần số học tốn kém vào runtime của trình xác thực. Chương trình cung cấp cơ số, số mũ và modulo dưới dạng số nguyên không dấu little-endian, rồi nhận kết quả trong vùng nhớ do bên gọi cung cấp. Ban đầu, mỗi toán hạng được giới hạn ở 512 byte, đủ để hỗ trợ số nguyên lên đến 4096 bit.

Trường hợp sử dụng rõ ràng nhất là xác minh RSA. Ví dụ, một chương trình xác minh chữ ký RSA thông thường có thể gọi sol_big_mod_exp bằng số mũ công khai phổ biến 65537, thay vì tự triển khai phép lũy thừa số nguyên lớn. Syscall chủ đích dừng ở primitive số học: chương trình vẫn chịu trách nhiệm về việc băm, phần đệm RSA như PKCS#1 v1.5 hoặc PSS, xác minh khóa và mọi hoạt động phân tách miền dành riêng cho giao thức.

Syscall cũng có thể thực hiện phép rút gọn modulo số nguyên lớn một cách hiệu quả. Truyền số mũ 1 sẽ rút gọn phép toán thành:

base mod modulus

Điều này cung cấp cho chương trình một primitive native để rút gọn các số nguyên lớn hơn kích thước từ máy tích hợp của SVM mà không phải trả chi phí cho một cách triển khai số nguyên lớn đa dụng.

Về ý tưởng, thiết kế này tương tự precompile ModExp của Ethereum được giới thiệu trong EIP-198, và mô hình đo lường tài nguyên tính toán tuân theo công thức độ phức tạp phép toán của EIP-198. Tuy nhiên, nó không tương thích từng byte với Ethereum. Solana cung cấp chức năng này qua ABI syscall native, sử dụng đầu vào little-endian và yêu cầu modulo phải là số nguyên lẻ lớn hơn một; modulo chẵn sẽ bị từ chối.

Điều đó khiến syscall đặc biệt hữu ích cho khả năng tương tác mà không buộc Solana phải áp dụng chính giao diện precompile của EVM. Các chương trình xác minh bằng chứng, chữ ký hoặc chứng thực dựa trên giả định mật mã kiểu Ethereum có thể tái sử dụng cùng nền tảng số học, đồng thời điều chỉnh cách gọi syscall.

SHA-512

Phần bổ sung thứ hai đơn giản hơn đáng kể nhưng hữu ích ngay lập tức.

SIMD-0512: Syscall Sha512 bổ sung sol_sha512, cung cấp cho các chương trình onchain quyền truy cập trực tiếp vào hàm băm SHA-512 thông qua runtime của trình xác thực. Giao diện của syscall này tương tự các syscall sol_sha256, sol_keccak256 và sol_blake3 hiện có của Solana, đồng thời trả về bản tóm lược SHA-512 tiêu chuẩn dài 64 byte.

Đáng chú ý, SHA-512 là một trong những primitive cốt lõi được Ed25519 sử dụng, cũng chính là lược đồ chữ ký mà Solana sử dụng rộng rãi. Cả Agave và Firedancer đều đã phụ thuộc vào SHA-512 trong nội bộ, nhưng trước thay đổi này, các chương trình SVM không thể truy cập trực tiếp cách triển khai đã tối ưu hóa đó. Thay vào đó, chương trình cần SHA-512 phải tự triển khai thuật toán bằng phần mềm.

Xét về tài nguyên tính toán, sự khác biệt này rất đáng kể. SIMD ước tính việc băm một đầu vào ngắn bằng cách triển khai sBPF tốn hàng nghìn CU, trong khi thực hiện cùng thao tác qua syscall tốn chưa đến 100 CU. sol_sha512 sử dụng cùng mô hình chi phí tính toán tổng quát như syscall SHA-256 hiện có của Solana.

Nhìn chung, hai syscall này tiếp nối một xu hướng rộng hơn trong SVM: chuyển các primitive mật mã phổ biến nhưng tốn nhiều tài nguyên tính toán ra khỏi từng chương trình và đưa vào các thao tác runtime tiêu chuẩn, có đo lường. Chương trình vẫn xác định giao thức mật mã cấp cao hơn, nhưng trình xác thực có thể thực thi các khối xây dựng tốn kém hiệu quả hơn nhiều so với cách triển khai sBPF.

Kết luận

Thay đổi nổi bật của Agave 4.3 là Alpenglow, thay thế TowerBFT bằng Votor, loại bỏ giao dịch bỏ phiếu khỏi các khối, rút ngắn thời gian hoàn tất từ vài giây xuống vài mili giây và định hình lại cách các trình xác thực cùng hạ tầng tương tác với cơ chế đồng thuận.

Đối với hầu hết người dùng và nhà phát triển ứng dụng, phần lớn quá trình chuyển đổi này sẽ diễn ra âm thầm. Tuy nhiên, với các trình xác thực, nhà cung cấp RPC, bộ lập chỉ mục và đội ngũ hạ tầng, Agave 4.3 đánh dấu khởi đầu của một thay đổi lớn trong cách Solana đạt được đồng thuận.

Tài nguyên khác

• Sách trắng Alpenglow v1.2 (tháng 7 năm 2026)
• Lịch phát hành Agave 4.3
• Lịch theo dõi cổng tính năng
• Nhật ký thay đổi Agave 4.3
• Các pull request của Agave 4.3
• Nâng cấp Alpenglow - Solana Foundation