Alpenglow: Cuộc cải tổ lớn về cơ chế đồng thuận của Solana

Những điểm chính có thể áp dụng 

• Lợi ích nổi bật của Alpenglow đối với Solana là rút ngắn 100 lần thời gian đạt tính chung cuộc của giao dịch. Tùy vào vị trí địa lý của validator, thời gian này sẽ giảm từ 12,8 giây xuống còn 100–150ms, giúp Solana cạnh tranh với hạ tầng Web2 tập trung hơn và hỗ trợ các ứng dụng thời gian thực.
• Alpenglow đơn giản hóa cơ chế đồng thuận bằng cách loại bỏ một số thành phần cũ của Solana, gồm Proof of History, Tower BFT và cơ chế truyền phiếu bầu dựa trên gossip. Thay cho Proof of History, Alpenglow đưa ra thời gian khối cố định 400ms — điều này không đồng nghĩa với một đồng hồ được đồng bộ hóa toàn cầu — để điều phối thời gian trên toàn mạng.
• Giao thức được xây dựng quanh hai thành phần nền tảng: Rotor, giao thức truyền khối cải tiến, mở rộng và tinh chỉnh kiến trúc Turbine hiện tại của Solana; và Votor, cơ chế bỏ phiếu mới thay thế Tower BFT, Proof of History và việc dùng gossip để truyền phiếu bầu.
• Mọi hoạt động đồng thuận đều chuyển ra ngoài chuỗi — các chứng chỉ biểu quyết vẫn được neo trên chuỗi, thay thế giao dịch biểu quyết theo từng slot bằng hệ thống chứng chỉ BLS gọn nhẹ. Thay đổi này loại bỏ phí biểu quyết như hiện nay, vốn từ trước đến nay là chi phí vận hành chính của validator, qua đó cải thiện đáng kể hiệu quả kinh tế cho các đơn vị vận hành nhỏ. Mô hình kinh tế chính xác vẫn đang được hoàn thiện.
• Alpenglow cung cấp mô hình chống chịu “20+20”: duy trì tính an toàn nếu tối đa 20% stake do đối thủ kiểm soát và duy trì tính sống nếu thêm một nhóm 20% stake riêng biệt ngoại tuyến hoặc không phản hồi. Nhờ đó, giao thức có thể chịu được cả điều kiện mạng thù địch lẫn bất ổn.
• Votor sử dụng hệ thống bỏ phiếu đồng thời hai tầng để đạt đồng thuận. Trong lộ trình Hoàn tất nhanh, nếu một khối nhận được sự chấp thuận của ≥80% stake ở vòng đầu tiên, khối đó lập tức đạt tính chung cuộc với Chứng chỉ Hoàn tất nhanh. Trong lộ trình Hoàn tất chậm, vòng thứ hai bắt đầu ngay khi một khối nhận được sự chấp thuận của ≥60% stake. Nếu vòng này đạt mức chấp thuận ≥60%, khối sẽ đạt tính chung cuộc với Chứng chỉ Hoàn tất.
• Khác với Turbine vốn dựa vào cấu trúc cây nhiều tầng với fanout 200, Rotor sử dụng mô hình một chặng, trong đó các node chuyển tiếp đảm nhiệm việc phân phối shred. Mỗi shred được truyền dưới dạng một gói duy nhất đã mã hóa xóa và thiết kế của Rotor tương thích sẵn với các hệ thống multicast như DoubleZero. Lưu ý rằng Rotor rất có thể sẽ là một SIMD tách biệt với Votor.
• Alpenglow hiện dự kiến được triển khai lên mainnet Solana vào đầu năm sau. Bạn có thể xem bản triển khai tham chiếu của giao thức trên Github.

Giới thiệu

Thuật toán đồng thuận Alpenglow là cuộc cải tổ quan trọng nhất đối với giao thức lõi của Solana từ trước đến nay. Dựa trên những tiến bộ mới nhất trong nghiên cứu blockchain, thuật toán này tái kiến trúc căn bản cách mạng lưới đạt được đồng thuận.

Alpenglow là thành quả của bộ phận nghiên cứu mới của Anza, do Giáo sư Roger Wattenhofer thuộc ETH Zurich — một trong những cơ sở khoa học máy tính hàng đầu thế giới — dẫn dắt. Là chuyên gia hàng đầu về hệ thống phân tán, Giáo sư Wattenhofer trước đây từng đồng tác giả bài báo năm 2024 Halting the Solana Blockchain with Epsilon Stake, trong đó phát hiện các lỗ hổng tiềm ẩn về tính sống trong giao thức đồng thuận hiện tại của Solana. Cùng làm việc với Giáo sư Wattenhofer tại Anza là hai cựu nghiên cứu sinh tiến sĩ của ông, Kobi Sliwinski và Quentin Kniep.

Nhiệm vụ của nhóm là thiết kế lại thuật toán đồng thuận của Solana để đạt hiệu năng cao hơn và có thể chứng minh tính đúng đắn, đồng thời duy trì kiến trúc dựa trên Turbine. Alpenglow tích hợp nhiều tiến bộ mới nhất trong nghiên cứu hệ thống phân tán, đặc biệt về cách xử lý hành vi mạng thù địch.

Tên Alpenglow bắt nguồn từ từ tiếng Đức Alpenglühen, có nghĩa là “ánh sáng dãy Alps”. Tên gọi này chỉ ánh sáng rực rỡ trên các đỉnh núi lúc bình minh hoặc hoàng hôn, đồng thời gợi nhắc đến nguồn gốc Thụy Sĩ của giao thức.

Alpenglow mang lại những lợi ích gì?

Dưới đây là phần tổng quan cấp cao về những lợi ích chính mà Alpenglow dự kiến mang lại. Từng lợi ích sẽ được phân tích sâu hơn trong phần còn lại của bài viết.

Đạt tính chung cuộc nhanh hơn

Lợi ích nổi bật của Alpenglow đối với Solana là rút ngắn 100 lần thời gian đạt tính chung cuộc của giao dịch, tức tốc độ giao dịch của người dùng được ghi nhận gốc trên mạng blockchain. Tùy vào vị trí địa lý của validator, thời gian này sẽ giảm từ 12,8 giây xuống còn 100–150ms, giúp Solana cạnh tranh với hạ tầng Web2 tập trung hơn và hỗ trợ các ứng dụng thời gian thực.

• Tính chung cuộc hiện tại của Solana: 12,8 giây 
• Xác nhận lạc quan hiện tại của Solana: 500–600 mili giây
• Tính chung cuộc của Alpenglow: 150 mili giây (giá trị trung vị)*
• Tính chung cuộc nhanh nhất của đối thủ: 400 mili giây (tự công bố)

*dao động tùy theo vị trí địa lý và phân bố cluster.

Không còn giao dịch biểu quyết

Với Alpenglow, mọi hoạt động đồng thuận đều diễn ra ngoài chuỗi. Điều này sẽ giảm tải cho bộ phận xử lý giao dịch (TPU) và quá trình phát lại vì chúng không còn phải xử lý giao dịch biểu quyết.

Alpenglow cũng sẽ cải thiện đáng kể hiệu quả kinh tế cho các validator nhỏ. Phí giao dịch biểu quyết là khoản chi phí vận hành lớn nhất của validator. Việc loại bỏ các khoản phí này thông qua biểu quyết ngoài chuỗi giúp giảm mạnh chi phí tham gia, tạo điều kiện để các validator nhỏ vận hành khả thi hơn và hạ thấp rào cản tham gia bảo mật mạng.

Các lợi ích khác gồm logic cam kết đơn giản hơn và sổ cái tăng trưởng chậm hơn, vì giao dịch biểu quyết không còn chiếm không gian khối hoặc làm tăng kích thước sổ cái.

Thay đổi này còn giúp loại bỏ sự mơ hồ trong số liệu giao dịch mỗi giây (TPS) của Solana. Hiện nay, TPS thường được báo cáo theo hai cách: tổng TPS, bao gồm giao dịch biểu quyết, và TPS thực, chỉ tính giao dịch không phải biểu quyết.

Giao thức tinh gọn hơn

Alpenglow tinh gọn quá trình đạt đồng thuận bằng cách loại bỏ một số thành phần cũ của Solana, gồm Proof of History, Tower BFT và việc dùng gossip để truyền phiếu bầu. Giao thức tích hợp những tiến bộ tiên tiến từ nghiên cứu blockchain hiện đại mà không tạo thêm độ phức tạp không cần thiết.

Votor và Rotor của Alpenglow đặt nền móng cho các nâng cấp trong tương lai, như thực thi bất đồng bộ và nhiều leader đồng thời (MCL), giúp Solana sẵn sàng tiếp tục cải thiện hiệu năng và phát triển giao thức.

Cơ chế đồng thuận hiện tại của Solana là gì?

Proof of History

Proof of History (PoH) không phải là thuật toán đồng thuận. Thay vào đó, đây là công cụ hỗ trợ đạt đồng thuận. Sự nhầm lẫn có thể bắt nguồn từ cách đặt tên — “Proof of X” khiến những người quen thuộc với Proof of Work và Proof of Stake nghĩ rằng đối tượng được nhắc đến là một thuật toán đồng thuận. Sẽ hữu ích hơn nếu xem đây là thuật toán “tiền đồng thuận”, giúp tinh gọn quá trình đồng thuận thông qua xử lý giao dịch hiệu quả.

Ở cấp độ tổng quan, PoH là đồng hồ phi tập trung dùng để chứng minh thời gian trong một mạng thù địch. Chính xác hơn, PoH là hàm đóng dấu thời gian mật mã cho phép các node thống nhất thứ tự sự kiện mà không cần trao đổi với nhau. Nó sử dụng một hàm băm tuần tự chống tìm ảnh ngược để tạo chuỗi băm. Leader dùng các hàm băm này để đóng dấu thời gian cho khối, qua đó chứng minh một khoảng thời gian đã trôi qua. Vì mọi hàm băm đều được liên kết, PoH cung cấp bản ghi lịch sử chứng minh dữ liệu đã tồn tại tại một thời điểm cụ thể. 

Cách tiếp cận này khác với các chain khác, vốn thường quyết định thứ tự khối trong quá trình đồng thuận rồi mới thêm dấu thời gian. Trên Solana, một đồng hồ có thể xác minh bằng mật mã được xây dựng trước, giao dịch được truyền theo đồng hồ đó, còn cơ chế đồng thuận xác minh nhật ký giao dịch đã được sắp thứ tự trước. Chuỗi băm khiến thứ tự thời gian không thể bị tranh cãi. 

Tower BFT

Tower BFT hoạt động sau khi các shred (tức những phần của khối) được truyền đến các validator khác và mạng đã phát lại chúng để xác định khối đó có trở thành một phần của sổ cái hay không. Về mặt khái niệm, đây là thuật toán đồng thuận tương tự pBFT, được thiết kế để tận dụng đồng hồ trên toàn mạng của Proof of History. Thay vì cần một vòng đồng thuận đồng bộ cho từng slot, validator cam kết trước với các slot trong tương lai dựa trên chuỗi Proof of History đã quan sát, qua đó cho phép sản xuất khối liên tục.

Validator gửi một giao dịch biểu quyết cho mỗi slot, được ký bằng tài khoản biểu quyết của họ. Phiếu bầu trên một fork nhất định phải chịu thời gian khóa (tức thời gian chờ) đối với fork đó. Thời gian khóa là một khoảng slot được chỉ định mà trong đó validator không thể bỏ phiếu cho fork khác. Mục đích là buộc validator cam kết với một fork và tăng thời gian khóa theo cấp số nhân nếu muốn chuyển fork. Mỗi phiếu bầu mang một bộ đếm thời gian khóa, tăng gấp đôi mỗi khi validator bỏ phiếu cho một slot hậu duệ, tạo thành một “tháp phiếu bầu” gồm các cam kết. Vì vậy, nếu validator bỏ phiếu cho khối X, họ sẽ bị khóa không thể bỏ phiếu cho bất kỳ fork xung đột nào trong số slot tương lai tăng theo cấp số nhân (ví dụ: 1, 2, 4, 8…). Hành vi phá vỡ thời gian khóa có thể được chứng minh và xử phạt, dù slashing vẫn chưa được áp dụng trên mainnet.

Solana đạt hai cấp độ tính chung cuộc trong Tower BFT: xác nhận lạc quan và tính chung cuộc tất định. 

Khi một khối mới được tạo và ≥66% stake bỏ phiếu cho khối đó, khối được công nhận là một phần của fork dẫn đầu, hay fork chính tắc. Đây được gọi là xác nhận lạc quan vì khối được đánh dấu ở mức cam kết “confirmed” ngay khi có siêu đa số bỏ phiếu cho nó. Xác nhận lạc quan được giới thiệu trong phiên bản v1.3 của client Solana Labs (nay là Agave) nhằm cải thiện UX bằng cách coi một khối là đã đạt tính chung cuộc trước khi quá trình này chính thức hoàn tất.

Kể từ khối khởi nguyên của Solana, chưa từng có khối nào đã được xác nhận lạc quan bị đảo ngược. Để làm được điều đó, ít nhất một phần ba tổng stake phải tiết lộ một fork xung đột sau khi 66% đã bỏ phiếu trung thực. Tương đương, khi số phiếu xác nhận lạc quan của một khối đạt ~87% stake, đối thủ sẽ cần ≥20% trong chính lượng stake đó ký hai lần — một hành vi có thể chứng minh để áp dụng slashing. Dù không phải tính chung cuộc tuyệt đối theo nghĩa lý thuyết đồng thuận nghiêm ngặt, xác nhận lạc quan vẫn mang lại đảm bảo mạnh mẽ trong thực tế. Các khối này có thể được coi là đã đạt tính chung cuộc trong gần như mọi trường hợp sử dụng — vì vậy, trên thực tế, tính chung cuộc của Solana thường được nêu là 500–600 mili giây.

Tính chung cuộc tất định thực sự yêu cầu một khối đạt thời gian khóa tối đa trong tháp phiếu bầu, tương đương 32 phiếu bầu xếp chồng để xác nhận khối đó. Nói cách khác, phải có thêm 32 khối được xây dựng trên khối đó thì nó mới được coi là “đã hoàn tất” hoặc được ghi nhận gốc trong mạng. Với yêu cầu 32 slot và thời gian mỗi slot là ~0,4 giây, một khối cần ~12,8 giây để đạt tính chung cuộc tất định. Tính chung cuộc tất định đạt được khi độ sâu phiếu bầu khóa khiến việc đảo ngược trở nên bất khả thi.

Cơ chế đồng thuận hiện tại của Solana có những hạn chế gì?

Proof of History và Tower BFT đã giúp Solana đạt thông lượng cao cùng khả năng xác nhận lạc quan nhanh. Tuy nhiên, thiết kế này có một số hạn chế về chi phí, độ trễ, tính sống và hoạt động của validator.

Chi phí và gánh nặng biểu quyết cao

Mọi validator đều phải liên tục bỏ phiếu cho từng slot để đóng góp vào cơ chế đồng thuận. Phiếu bầu là các giao dịch tương tác với chương trình biểu quyết, tiêu thụ tài nguyên mạng và phải trả phí. 

Khoảng ba phần tư giao dịch trên Solana là giao dịch biểu quyết, tạo ra gánh nặng đáng kể cho mạng và khiến validator phải chịu chi phí thực tế ở mỗi slot. Việc phụ thuộc không cần thiết vào hoạt động bỏ phiếu liên tục tạo ra gánh nặng và chi phí cao, tăng theo số slot được xử lý và số validator trong cluster. 

Độ trễ của tính chung cuộc

Dù xác nhận lạc quan diễn ra nhanh, tính chung cuộc tất định thì không. ~12,8 giây là chậm so với các giao thức đồng thuận mới hơn như Mysticeti của Sui, vốn công bố thời gian đạt tính chung cuộc là ~500ms. Điều này gây khó khăn cho các ứng dụng như sàn giao dịch, vốn đòi hỏi sự chắc chắn tuyệt đối trong hoạt động. Trên thực tế, người dùng tin tưởng các khối đã được xác nhận. Tuy nhiên, mạng vẫn phải duy trì lịch sử fork dài để xử lý khả năng tái tổ chức nhỏ trước khi hoàn tất. 

Khoảng cách giữa xác nhận lạc quan và độ trễ tất định là một sự đánh đổi: Tower BFT ưu tiên tính sống với một khoảng thời gian ngắn để xử lý khả năng phân nhánh, đổi lại tính chung cuộc chậm hơn. Ngay cả khi không có bất kỳ cuộc tấn công hay lỗi đồng thuận nào, thời gian đạt tính chung cuộc ~12,8 giây vẫn kém xa các chain có tính chung cuộc nhanh và hạ tầng Web2 hiện có.

Tính sống và khả năng chịu phân vùng mạng

Tower BFT yêu cầu siêu đa số validator phải trực tuyến và phản hồi để xác nhận cũng như hoàn tất các khối mới. Cơ chế đồng thuận có thể đình trệ nếu hơn một phần ba stake ngoại tuyến hoặc mạng bị phân vùng nghiêm trọng. Solana vẫn có thể tiếp tục tạo khối để ưu tiên tính sống, nhưng mạng có thể không đạt ngưỡng phiếu bầu cần thiết nhằm xác nhận lạc quan các khối này. Trong trường hợp xấu nhất, như từng xảy ra trong các sự cố ngừng hoạt động gần đây của Solana, validator bị kẹt khi chờ phiếu bầu hoặc không thể xử lý fork lạc quan có thể khiến mạng dừng lại và cần khởi động lại có điều phối.

Đây là hạn chế kinh điển của cơ chế đồng thuận BFT. Solana không có cơ chế tích hợp để ứng phó khi một lượng lớn validator tạm thời không phản hồi. Vì vậy, tính sống của Solana bị ảnh hưởng trong điều kiện cực đoan do giao thức không thể xử lý linh hoạt khi tỷ lệ tham gia giảm xuống dưới ngưỡng siêu đa số cần thiết cho đồng thuận. Tower BFT buộc phải tiếp tục tạo khối khi chưa đến 60% stake trực tuyến. Điều này đồng nghĩa các khối đó không bao giờ có thể đạt xác nhận lạc quan và có thể bị đảo ngược.

Độ phức tạp trong vận hành validator

Tower BFT đặt ra nhiều yêu cầu cho validator: giao dịch biểu quyết liên tục, kết nối mạng ổn định, nâng cấp client, tránh tình trạng không hoàn thành nhiệm vụ và duy trì “trạng thái tháp”. Nếu validator khởi động lại hoặc mất trạng thái tháp mới nhất, họ có nguy cơ bỏ một phiếu vi phạm cam kết khóa trước đó, dẫn đến mất điểm tín dụng biểu quyết.

Sự phụ thuộc của giao thức vào quá trình băm liên tục của Proof of History và truyền phiếu bầu qua gossip khiến validator phải hoạt động tích cực để theo kịp thời gian slot ~400ms của Solana. Yêu cầu phần cứng cao của Solana, dù đang giảm dần theo thời gian, cũng không hề nhỏ. Hơn nữa, bất kể lượng stake, tất cả validator đều phải bỏ phiếu cho mọi slot để tối đa hóa phần thưởng. Điều này có nghĩa là phần lớn validator nhỏ phải trả cùng mức phí và gánh cùng khối lượng công việc như validator lớn. Vì slot leader được phân bổ tỷ lệ thuận với stake, validator có nhiều stake hơn sẽ tạo nhiều khối hơn, qua đó thu về nhiều phí biểu quyết hơn từ các validator khác. Điều này tạo ra dòng giá trị tuần hoàn, trong đó phí biểu quyết thực chất phân phối lại vốn về phía các validator có lượng stake cao hơn.

Ngoài ra, cơ chế đồng thuận hiện tại của Solana khiến việc phát lại khối trùng lặp trở nên cực kỳ phức tạp vì client phải quản lý nhiều khối ứng viên cho cùng một slot. Hệ thống chứng chỉ của Votor đảm bảo mỗi slot cam kết một hàm băm duy nhất hoặc một lần bỏ qua rõ ràng, giúp việc phát lại khối trùng lặp trở nên đơn giản.

Có thể thấy rằng thiết kế của Tower BFT, dù sáng tạo, vẫn tạo ra mức độ phức tạp đáng kể trong hoạt động của validator.

Alpenglow hoạt động như thế nào?

Alpenglow được xây dựng quanh hai thành phần cốt lõi:

• Rotor: giao thức truyền khối được nâng cấp, xây dựng trên và cải thiện kiến trúc Turbine hiện có.
• Votor: giao thức biểu quyết mới thay thế Tower BFT, cơ chế truyền phiếu bầu dựa trên gossip và Proof of History trong việc tham gia đồng thuận.

Trong các phần tiếp theo, chúng ta sẽ tìm hiểu chi tiết về những thành phần này.

Rotor: Lớp phân phối dữ liệu mới

Rotor là giao thức truyền khối nâng cao, được xây dựng trên thiết kế Turbine hiện tại của Solana với những cải tiến quan trọng về hiệu quả và tính đơn giản. Khác với Turbine sử dụng cấu trúc cây nhiều tầng với fanout 200, Rotor dùng mô hình một chặng (2δ). 

Các khối được chia thành slice, sau đó mỗi slice được mã hóa thành nhiều shred bằng mã xóa Reed-Solomon. Để đảm bảo tính xác thực của shred, leader tạo cây Merkle từ các hàm băm của shred và ký vào gốc. Mỗi shred chứa đường dẫn của nó trong cây này và chữ ký của leader.

Mỗi shred được gửi trực tiếp đến một node chuyển tiếp. Sau đó, các node chuyển tiếp phát shred của mình đến tất cả node trong mạng, ưu tiên leader tiếp theo trước. Cách tiếp cận một tầng này giảm độ trễ và đơn giản hóa đường truyền. Nó cũng nhanh đến bất ngờ:

Cả leader và các node chuyển tiếp shred đều được chọn bằng phương pháp lấy mẫu có trọng số stake, nghĩa là mỗi node chịu trách nhiệm truyền lượng dữ liệu tỷ lệ thuận với stake của mình. Nhờ mã hóa xóa, node chỉ cần nhận một tập con shred để tái tạo slice khối ban đầu.

Một điểm khác biệt đáng chú ý so với Turbine là Rotor chỉ truyền một phiên bản đã mã hóa xóa của mỗi shred, không cần gửi riêng shred dữ liệu và shred khôi phục như Turbine. Dù độ dư thừa (tức tỷ lệ mở rộng dữ liệu) vẫn giữ nguyên, thiết kế này loại bỏ mọi hành vi bất thường liên quan đến chuyển tiếp shred dữ liệu và đảm bảo giao thức có thiết kế đơn giản.

Kiến trúc của Rotor cũng tương thích với các hệ thống multicast như DoubleZero, mang lại sự linh hoạt trong cách phân phối khối. Vì việc truyền khối tiêu thụ băng thông đáng kể (hiện các validator lớn đạt gần 150.000 gói tin đầu ra mỗi giây), Rotor đưa ra mô hình thưởng cho các node chuyển tiếp phân phối dữ liệu, qua đó điều chỉnh động lực để hỗ trợ hiệu năng mạng.

Sách trắng Alpenglow không xác định cơ chế cụ thể để tính toán hoặc phân phối phần thưởng. Tuy nhiên, tài liệu lưu ý rằng phần thưởng Rotor nên tính đến lượng băng thông tiêu thụ, trong đó các node chuyển tiếp nhiều dữ liệu hơn dự kiến nhận được tỷ lệ phần thưởng lớn hơn.

Blokstor là gì?

Blokstor là nơi các node lưu trữ và quản lý dữ liệu khối nhận được từ Rotor. Chính xác hơn, Blokstor là một cấu trúc dữ liệu quản lý việc lưu trữ các slice. Khi nhận được một shred, nội dung của shred sẽ được thêm vào Blokstor nếu đáp ứng một số điều kiện, gồm:

• Blokstor chưa chứa shred cho các chỉ mục đó
• Chữ ký leader hợp lệ
• Đường dẫn cây Merkle hợp lệ

Blokstor phát ra sự kiện "Block(slot(b), hash(b) hash(parent(b)))" khi nhận được khối hoàn chỉnh đầu tiên b cho slot(b). Blokstor cũng có thể thực hiện quy trình sửa chữa để thu thập và lưu trữ các khối thay thế cho cùng một slot. Khi một khối đạt tính chung cuộc, Blokstor chỉ được lưu trữ khối đó trong slot tương ứng.

Votor: Công cụ biểu quyết và hoàn tất mới

Votor là công cụ biểu quyết và hoàn tất mới của Aplenglow, thay thế Tower BFT trong việc công chứng và hoàn tất khối. Công cụ này lấy cảm hứng từ hướng nghiên cứu Simplex để nâng cao hiệu quả và tính đơn giản, đồng thời áp dụng vào bối cảnh Proof of Stake. 

Simplex chứng minh rằng có thể đạt thỏa thuận Byzantine hiệu quả trong môi trường Proof of Stake với leader luân phiên bằng các thông điệp cực nhỏ, miễn là có giới hạn trên chặt chẽ về độ trễ mạng. Dựa trên những hiểu biết này, Votor đạt đồng thuận trong một hoặc hai vòng.

Ở cấp độ tổng quan, Votor đảm bảo rằng với mỗi slot, hoặc có chứng chỉ bỏ qua cho biết slot đó đã bị bỏ qua, hoặc có một khối đã được công chứng xây dựng trên chain chính tắc gồm các khối đã được công chứng. Để được công chứng, khối phải có chứng chỉ hợp lệ. Thay vì làm tràn gossip bằng phiếu bầu, validator phát các thông điệp biểu quyết gọn nhẹ đến một tập hợp peer có trọng số stake dưới dạng lưới “gửi trực tiếp”, thay vì gossip truyền thống của Solana. Khi đạt ngưỡng túc số, bất kỳ node nào cũng có thể tổng hợp các chữ ký này thành chứng chỉ bằng lược đồ chữ ký Boneh–Lynn–Shacham (BLS). Điều này loại bỏ nhu cầu về giao dịch biểu quyết theo từng slot vì phần header chứng chỉ tổng hợp sẽ được neo trên chuỗi.

Cơ chế biểu quyết của Votor hoạt động như thế nào?

Votor sử dụng cơ chế biểu quyết đồng thời theo tầng, được chia thành hai lộ trình biểu quyết:

• Hoàn tất nhanh: Nếu khối được đề xuất nhận được sự chấp thuận của ≥80% stake trong vòng biểu quyết đầu tiên, khối sẽ lập tức đạt tính chung cuộc và một Chứng chỉ Hoàn tất nhanh được tạo ra. Việc hoàn tất trong một vòng khả thi vì 80% stake cao hơn nhiều so với ngưỡng siêu đa số, nên không cần vòng biểu quyết thứ hai để hoàn tất.
• Hoàn tất chậm: Nếu vòng biểu quyết đầu tiên nhận được sự chấp thuận của <80% stake nhưng ≥60%, Votor lập tức bắt đầu vòng biểu quyết thứ hai. Khi vòng thứ hai đạt mức chấp thuận ≥60% stake, một Chứng chỉ Hoàn tất được tạo ra.

Cả hai lộ trình chạy đồng thời và lộ trình đầu tiên đạt ngưỡng sẽ hoàn tất khối. Ngay khi leader hoàn tất việc tiếp nhận khối cha, leader có thể bắt đầu truyền khối tiếp theo trong lúc phiếu bầu vẫn đang được tích lũy. Do đó, cứ mỗi ~400ms lại có một khối được tạo, giống như cơ chế đồng thuận cũ của Solana. Thiết kế này đảm bảo rằng nếu vòng đầu tiên không nhận được sự chấp thuận của ≥80% stake, Votor sẽ chuyển sang vòng biểu quyết thứ hai. Nó cũng đảm bảo hai khối xung đột không thể cùng đạt tính chung cuộc nhờ phần stake giao nhau.

Cấu trúc dữ liệu Pool của Votor là gì?

Pool là cấu trúc dữ liệu được mỗi node duy trì, hoạt động như một sổ cái cục bộ ghi lại hoạt động biểu quyết và quá trình tạo chứng chỉ. Nó ghi nhớ các phiếu bầu đã nhận cho từng slot và từng node. Khi nhận đủ phiếu bầu, chứng chỉ tương ứng sẽ được tạo. Khi một chứng chỉ mới nhận hoặc tự tạo được thêm vào Pool, chứng chỉ đó sẽ được phát đến tất cả node khác. 

Dù nhiều validator có thể tạo chứng chỉ gần như cùng lúc, mọi chứng chỉ đáp ứng ngưỡng túc số đều tương đương về chức năng đối với cơ chế đồng thuận, bất kể validator cụ thể nào có trong tập chữ ký. Ngoại lệ duy nhất là Chứng chỉ Hoàn tất vì có thể có tối đa ba chứng nhận riêng biệt cần được lưu chuyển. Với một slot nhất định, không bao giờ có quá bốn chứng chỉ duy nhất thuộc mọi loại và mỗi chứng chỉ duy nhất chỉ được phát một lần. Cách tiếp cận này ngăn chặn spam phiếu bầu, đồng thời vẫn cho phép bất kỳ node trung thực nào tạo và chia sẻ chứng chỉ ngay khi Pool cho thấy đã đạt túc số.

Những điểm chính

Phiếu bầu được truyền dưới dạng các gói UDP đơn lẻ đến tất cả validator. Các validator ghi nhớ phiếu bầu đã nhận cho từng slot và từng node. Việc công chứng và đạt tính chung cuộc của một khối trong Votor được xác định bằng ba điều kiện sau:

• Sự chấp thuận của ≥80% stake trong vòng biểu quyết đầu tiên.
• Sự chấp thuận của ≥60% stake trong vòng biểu quyết thứ nhất và thứ hai.
• Validator nhận được chứng chỉ hợp lệ từ một validator khác xác nhận khối đã đạt tính chung cuộc.

Không còn Proof of History

Vì Rotor truyền dữ liệu khối trong một chặng và Votor có mục tiêu độ trễ tối đa là ~150ms (chúng tôi sẽ trình bày kỹ hơn trong phần tiếp theo), Solana không còn cần đồng hồ phi tập trung. Thay vào đó, các đồng hồ cục bộ đơn giản là đủ. Alpenglow thay Proof of History bằng các bộ hẹn giờ chờ cục bộ.

Cơ chế thời gian chờ của Votor hoạt động như thế nào?

Trong thực tế, hệ thống thời gian chờ hoạt động như sau:

• Cửa sổ leader: Leader sẽ phụ trách một cửa sổ gồm bốn slot, với Δblock ≈ 400ms cho mỗi slot.
• Dữ liệu đến hoặc hết thời gian chờ: Ngay khi khối cha của một leader được công chứng, mỗi validator kích hoạt thời gian chờ và đặt trước bốn thời hạn — mỗi slot một thời hạn — tại t = now + Δtimeout + slotIndex * Δblock, trong đó Δblock ≈ 400ms. Lưu ý rằng các bộ hẹn giờ này không bao giờ được đặt lại và đóng vai trò là giới hạn trên. Nếu shred của khối đến đúng hạn, slot đó sẽ được bỏ phiếu bằng thông điệp NotarVote và thời gian chờ đang đợi sẽ không làm gì. Tuy nhiên, nếu hết thời gian trước khi có shred nào đến, validator sẽ cho rằng leader không trung thực hoặc không hoàn thành nhiệm vụ và phát SkipVote.
• Chứng nhận: Chứng chỉ Hoàn tất nhanh hoặc Chứng chỉ Hoàn tất được tạo cho các khối đã công chứng như mô tả ở trên. Chứng chỉ Bỏ qua cũng có thể được tạo cho các slot bị bỏ qua.

Alpenglow đưa ra một hệ thống trong đó mọi validator đều đo thời gian chờ cục bộ và độc lập. Vì vậy, Solana không cần một đồng hồ duy nhất dựa trên hàm băm như Proof of History. Vì mỗi thông điệp chỉ là một gói UDP và Rotor chỉ có một chặng, giới hạn 400ms là khả thi mà không cần băm. Validator sẽ không còn phải liên tục tính toán hàm băm, có thể bỏ phiếu chống lại khối mà không chịu thời gian khóa, còn các client thay thế như Firedancer sẽ không bị buộc phải sao chép bản triển khai Proof of History của client Agave.

Bỏ qua slot

Validator cũng có thể bỏ qua một slot bằng cách gửi thông điệp SkipVote. Nếu ≥60% stake gửi thông điệp SkipVote, Chứng chỉ Bỏ qua sẽ được tạo và slot đó chính thức bị bỏ qua. Phiếu bỏ qua có trọng số phần thưởng bằng phiếu công chứng, vì vậy validator không có động lực im lặng khi leader hành xử sai. Lưu ý rằng điều này có thể thay đổi sau khi mô hình kinh tế của Alpenglow được hoàn thiện.

Validator gửi SkipVote cho một slot bất cứ khi nào xác định rằng họ không thể hoàn tất khối cho slot đó. Nguyên nhân có thể là hết thời gian chờ, thiếu khối hoặc tạo ra khối không hợp lệ hay sai định dạng. Nếu slot đầu tiên trong cửa sổ bốn slot của leader gặp bất kỳ điều kiện nào kể trên, validator sẽ đánh dấu toàn bộ cửa sổ là không hợp lệ. Sau đó, họ duyệt qua các slot còn lại trong cửa sổ và phát SkipVote cho mọi slot chưa bỏ phiếu. Nhờ đó, toàn bộ cửa sổ bốn slot có thể được thu gọn thành một vòng bỏ qua. Mỗi phiếu vẫn chỉ áp dụng cho một slot, nhưng vì phần lớn validator cùng gửi theo đợt, cả ba slot đang chờ sẽ đạt ngưỡng 60% gần như cùng lúc. Điều này ngăn cluster phải chờ qua ba slot trống nữa trong khi leader ngoại tuyến hết thời gian chờ.

Rõ ràng, điều này tạo ra khoảng trống trong quá trình sản xuất khối. Tuy nhiên, nhịp slot vẫn tiếp tục không gián đoạn nhờ các chứng chỉ bỏ qua nhanh. Điều này đơn giản hóa việc chọn fork và cải thiện tính nhất quán vì chứng chỉ bỏ qua hoạt động như một “khối rỗng” chính tắc cho slot đó, nên tất cả node trung thực đều chấp nhận việc bỏ qua làm kết quả. Vì vậy, không có fork cạnh tranh và việc bỏ qua không dẫn đến fork kéo dài, cho phép duy trì nhịp sản xuất khối bình thường.

Phần thưởng cho validator

Phần thưởng cho validator trong Votor dựa trên việc tham gia biểu quyết và tạo chứng chỉ. Các node đóng góp vào cơ chế đồng thuận bằng cách bỏ phiếu ủng hộ (NotarVote) hoặc phản đối (SkipVote) một khối đều được thưởng như nhau. Điều này khuyến khích sự tham gia trung thực, đảm bảo các node bỏ phiếu dựa trên trạng thái riêng thay vì cố dự đoán hoặc làm theo đa số.

Hiện chưa có thông số triển khai phần thưởng chính xác.

Điểm chuẩn hiệu năng và kết quả mô phỏng Alpenglow

Các mô phỏng của Anza cho thấy Alpenglow hoàn tất một khối trong khoảng 100-150ms, tùy vào việc khối được chứng thực qua luồng Fast-Finalization hay Fallback (tức hoàn tất chậm). Luồng Fast-Finalization hướng đến độ trễ ~100ms, còn luồng Slow-Finalization hướng đến độ trễ ~150ms.

Biểu đồ phân bố độ trễ

Độ trễ mạng đặt ra giới hạn dưới cơ bản cho hoạt động giao tiếp trong mọi hệ thống phân tán. Ví dụ: nếu leader ở New York và phần lớn cổ phần ở châu Âu, độ trễ một chiều trung vị để một node gửi thông tin đến các node mạng khác có thể lên tới khoảng 200 mili giây. Độ trễ thấp hơn đối với các node ở gần nhau về mặt địa lý (ví dụ: trong cùng trung tâm dữ liệu hoặc khu vực) và cao hơn đáng kể đối với các node ở Nam bán cầu hoặc những khu vực xa xôi khác.

• Mạng: Đây là độ trễ mạng khi gửi 1 bit đến các node khác qua internet
• Rotor: Rotor chậm hơn bao nhiêu so với giới hạn dưới này
• Chứng thực: Thời gian cần để nhận phiếu bầu đã được chứng thực từ 60% cổ phần (cũng có thể tiến hành thêm một vòng bỏ phiếu; sau khi nhận được, quá trình hoàn tất có thể bắt đầu)
• Tính hoàn tất: Thời gian hoàn tất

Nhìn chung, tính hoàn tất của Alpenglow cao gấp 2 lần giới hạn dưới. Nói cách khác, chi phí đồng thuận tạo ra hệ số nhân 2 lần so với mức sàn của mạng thuần túy. Vì vậy, nếu chặng một chiều dài nhất giữa leader và siêu đa số cổ phần là ~70ms (tức ~140ms RTT), tính hoàn tất theo luồng nhanh sẽ đạt trong khoảng 120-150ms.

Biểu đồ phân bố độ trễ từ các mô phỏng của Anza cho thấy 65% cổ phần hoàn tất trong vòng 50ms so với độ trễ mạng thuần túy. Điều này có nghĩa là hầu hết trình xác thực bỏ phiếu gần như ngay khi dữ liệu đến nơi.

Với Alpenglow, các cam kết mang tính xác định có độ trễ thấp hơn đáng kể so với mọi L1 cạnh tranh, đưa trải nghiệm on-chain của Solana đến gần hơn nhiều với các dịch vụ Web2 truyền thống.

Phân tích bảo mật và khả năng chịu lỗi của Alpenglow

Cơ chế đồng thuận của Alpenglow là một bước cải tiến so với đồng thuận BFT truyền thống, vốn duy trì khả năng chống chịu trước các đối thủ kiểm soát tối đa 33% cổ phần của mạng. Mức này được biểu thị là “3f + 1”. Alpenglow hạ giới hạn này xuống 20% cổ phần của mạng dựa trên giới hạn 5f + 1 do Martin và Alvisi đề xuất trong Đồng thuận Byzantine nhanh. Cơ chế này sử dụng mô hình chống chịu “20+20”, trong đó bảo mật được chia thành hai phần:

• Lỗi Byzantine ≤ 20%: Tính an toàn được duy trì nếu dưới 20% tổng cổ phần do các trình xác thực đối địch kiểm soát. Đây là một khoản tiền đáng kể lên đến hàng tỷ đô la, đồng thời hành vi này cũng dễ bị phát hiện và trừng phạt. Do đó, kẻ tấn công có nguy cơ mất toàn bộ cổ phần, khiến các cuộc tấn công như vậy không khả thi về mặt kinh tế.
• Hiện tượng không ác ý ≤ 20%: Tính sống được duy trì nếu tối đa 20% tổng cổ phần, tách biệt với cổ phần đối địch, ngoại tuyến, gặp sự cố hoặc không tham gia đồng thuận vì lý do khác. Điều này bao gồm sự cố mạng, cấu hình sai và lỗi phần mềm. Nhờ đó, mạng vẫn có thể tiếp tục hoàn tất các khối ngay cả khi một bộ phận đáng kể trình xác thực không phản hồi.

Tính an toàn

Tính an toàn được đảm bảo với điều kiện tổng cổ phần đối địch ≤20% và không thể ngăn ít nhất 60% cổ phần trung thực tham gia trên một fork. Các điều kiện này đảm bảo mọi ngưỡng phiếu bầu mà giao thức coi là hoàn tất (tức một vòng nhanh, hai vòng chậm) đều đủ cao để không thể đạt được ngưỡng xung đột trên một fork khác. Nếu các trình xác thực đối địch cố bỏ phiếu mâu thuẫn (tức bỏ phiếu cho hai fork khác nhau hoặc tạo hai khối khác nhau trong cùng một slot), các node trung thực cuối cùng sẽ nhận được các chữ ký xung đột của họ. Hành vi này dễ dàng bị phát hiện và lý tưởng nhất là trong tương lai sẽ dẫn đến các hình phạt như slashing. 

Ngoài ra, nếu một leader cố tạo ra khối không hợp lệ, các trình xác thực trung thực sẽ đơn giản từ chối bỏ phiếu cho khối đó. Mô hình giao tiếp trực tiếp để bỏ phiếu của Alpenglow khiến tác nhân ác ý khó cô lập hoặc che khuất một node trung thực về mặt cổ phần, vì cuối cùng họ sẽ bị phiếu bầu của đa số trung thực vạch trần. Trong trường hợp tốt nhất, leader ác ý chỉ có thể buộc quá trình đồng thuận chuyển sang luồng chậm hơn hoặc gây ra độ trễ một slot, nhưng không thể khiến chuỗi đình trệ vĩnh viễn hoặc phân kỳ.

Tính sống

Tính sống được đảm bảo trong điều kiện đồng bộ một phần, miễn là các ngưỡng lỗi được tuân thủ. Điều này có nghĩa là sau một khoảng trễ mạng, các trình xác thực trung thực sẽ có thể giao tiếp và tập hợp ≥60% cổ phần cho một khối. Nếu đúng 20% tổng cổ phần ngoại tuyến, luồng nhanh vẫn có thể thành công nếu tất cả các node trung thực còn lại bỏ phiếu. Nếu hơn 20% tổng cổ phần một chút bị ngoại tuyến, mạng sẽ liên tục sử dụng luồng hoàn tất chậm cho vòng bỏ phiếu thứ hai. Tính hoàn tất vẫn được đảm bảo, dù chậm hơn. Do đó, các sự cố lành tính chủ yếu ảnh hưởng đến hiệu năng chứ không phải tính an toàn.

Khả năng chống chịu sự cố cao

Alpenglow được thiết kế rõ ràng với khả năng chống chịu sự cố cao để xử lý các điều kiện mạng khắc nghiệt. Cụ thể, Alpenglow sẽ tiếp tục duy trì tính an toàn và vận hành trong kịch bản 20% cổ phần ác ý và 20% cổ phần không phản hồi. 

Tuy nhiên, đây không phải giải pháp toàn diện cho mọi sự cố có thể xảy ra. Alpenglow là một cải tiến đáng kể đối với Solana, nhưng không loại bỏ hoàn toàn nguy cơ mạng dừng hoạt động hoặc gián đoạn nếu các giả định của cơ chế bị vi phạm. Cần ≥60% cổ phần để tạo ra các khối mới, và ≥20% cổ phần hành động ác ý có thể ngăn chặn đồng thuận hoặc gây lỗi. Dù vậy, trong các giới hạn đã xác định, Alpenglow đảm bảo tính an toàn và tính sống trong một hoặc hai vòng bỏ phiếu.

Việc loại bỏ Proof of History có làm suy yếu bảo mật không?

Mặc dù là nền tảng cho hoạt động hiện tại của Solana, việc loại bỏ Proof of History không làm suy yếu bảo mật theo bất kỳ cách đáng kể nào. Như đã đề cập, giới hạn chung 400ms thay thế đồng hồ băm Proof of History. Ngay cả khi mạng gặp độ trễ đáng kể, mức chồng lấn cổ phần của Votor (tức ≥80% trong một vòng và ≥60% + ≥60% trong hai vòng) vẫn ngăn các trình xác thực trung thực phê duyệt hai fork khác nhau.

Tuy nhiên, điều này làm thay đổi các đảm bảo về tính sống vì tính sống phụ thuộc vào thông báo đồng bộ—tính sống sẽ được duy trì miễn là các thông báo trung thực đến trong khoảng trễ này. Cơ chế truyền dữ liệu một chặng và phiếu bầu trong một gói tin của Rotor giúp độ trễ luôn nằm trong giới hạn 400ms, ngay cả khi chịu tải lớn.

Nhìn chung, việc loại bỏ Proof of History sẽ chấm dứt sự phụ thuộc vào quá trình tính toán hàm băm liên tục, qua đó loại bỏ mọi hướng tấn công làm đình trệ hàm băm. Như đã đề cập ở trên, việc này cũng làm thay đổi các đảm bảo về tính sống. Tuy nhiên, loại bỏ Proof of History không làm suy yếu bảo mật theo bất kỳ cách đáng kể nào.

Những điểm chính

Alpenglow đánh đổi mức giảm nhẹ về khả năng chịu lỗi Byzantine để đạt được tính hoàn tất xác định dưới một giây, xử lý linh hoạt các sự cố lành tính quy mô lớn và dễ dàng xác định các trình xác thực ác ý hơn. Có thể tóm tắt những điểm chính như sau:

• Không thể hoàn tất hai khối xung đột trừ khi ≥20% cổ phần ký hai lần, một hành vi rất dễ chứng minh và trừng phạt.
• Solana sẽ tiếp tục hoàn tất các khối miễn là ≥60% cổ phần có thể giao tiếp, ngay cả khi phần cổ phần còn lại ngoại tuyến.
• Trong trường hợp xấu nhất, quá trình hoàn tất sẽ chuyển sang bỏ phiếu vòng hai với mục tiêu độ trễ ~150ms, để các cuộc tấn công làm giảm tốc độ chuỗi trước khi đe dọa tính an toàn.
• Chi phí để vượt qua giới hạn Byzantine 20% là quá cao, trong khi các hành vi sai trái nhỏ hơn có thể bị phát hiện và trừng phạt về mặt xã hội lẫn kinh tế sau khi slashing đi vào hoạt động trên mainnet.

Alpenglow tác động thế nào đến các trình xác thực?

Chi phí bỏ phiếu là rào cản gia nhập lớn nhất đối với việc vận hành trình xác thực Solana. Không có mức SOL tối thiểu bắt buộc nghiêm ngặt để vận hành trình xác thực. Tuy nhiên, việc gửi transaction bỏ phiếu ở mỗi slot, vốn cần thiết để tham gia đồng thuận, có thể tốn tới ~1 SOL mỗi ngày.

Alpenglow hướng đến thay thế các transaction bỏ phiếu theo từng slot bằng một hệ thống chứng chỉ nhỏ gọn, qua đó loại bỏ hiệu quả phí bỏ phiếu như hiện nay. Mỗi trình xác thực sẽ phát các thông báo phiếu bầu nhẹ đến tất cả node khác. Khi đạt túc số, bất kỳ node nào cũng có thể tổng hợp các chữ ký đó thành một chứng chỉ thông qua lược đồ chữ ký BLS. Vì các phiếu bầu này đã được tổng hợp bằng BLS, chỉ phần đầu chứng chỉ được neo on-chain. Trên thực tế, điều này sẽ xóa bỏ chi phí ~1 SOL mỗi ngày cho mỗi trình xác thực. 

Như đã đề cập, với Alpenglow, mỗi đề xuất khối được đánh giá qua hai luồng bỏ phiếu đồng thời:

• Fast-Finalization (một vòng)
  • Kích hoạt khi tổng phiếu bầu đã chứng thực cho một khối nhất định trong vòng bỏ phiếu đầu tiên đạt ≥80% cổ phần
  • Tạo Chứng chỉ Fast-Finalization
  • Có mục tiêu độ trễ ~100ms
• Slow-Finalization (hai vòng)
  • Kích hoạt khi tổng phiếu bầu đã chứng thực cho một khối nhất định trong vòng bỏ phiếu đầu tiên đạt ≥60% cổ phần
  • Tạo Chứng chỉ Hoàn tất sau khi tổng phiếu bầu đã chứng thực cho vòng thứ hai đạt ≥60% cổ phần
  • Có mục tiêu độ trễ ~150ms

Votor chạy đồng thời cả hai luồng, nghĩa là cả hai tổng phiếu đều được cập nhật từ cùng một luồng phiếu bầu vòng đầu tiên, để chứng chỉ đầu tiên vượt ngưỡng sẽ hoàn tất khối. Tập hợp cổ phần chồng lấn (tức ≥60%) đảm bảo hai khối xung đột không bao giờ có thể cùng đạt trạng thái hoàn tất.

Thiết kế mới này mang lại những tác động vận hành tích cực cho các trình xác thực:

Giảm chi phí vận hành 

Loại bỏ phí bỏ phiếu làm giảm đáng kể rào cản gia nhập đối với các trình xác thực tiềm năng. Đồng thời, phí bỏ phiếu khiến các trình xác thực nhỏ phụ thuộc nhiều hơn vào phần thưởng lạm phát trong thị trường giá xuống. Việc loại bỏ phí này có thể mở ra các cuộc thảo luận trong tương lai về lạm phát của Solana, xét đến cuộc bỏ phiếu gây tranh cãi về SIMD-228. Theo phương án triển khai Alpenglow đang được thảo luận, mức cắt giảm như vậy sẽ giảm lượng SOL tối thiểu để có lợi nhuận từ ~4850 SOL (~800 nghìn USD) xuống ~450 SOL (~75 nghìn USD), theo tính toán bằng Công cụ tính lợi nhuận trình xác thực của Cogent Crypto.

Tinh gọn quy trình quản lý khóa 

Các trình xác thực Solana không còn phải ký phiếu bầu theo từng slot. Điều này có nghĩa là khóa danh tính của trình xác thực có thể được lưu trong Mô-đun bảo mật phần cứng (HSM) mà không gây rủi ro về hiệu năng, qua đó giảm thiểu hiệu quả rủi ro từ ví nóng.

Giảm tải mạng tại slot của leader

Việc tổng hợp một chứng chỉ cho mỗi khối thay thế hàng nghìn transaction bỏ phiếu riêng lẻ trong mỗi epoch, qua đó giảm tải mạng tại slot của leader. 

Không cần phép tính khóa phiếu

Bảng khóa phiếu lũy thừa kiểu Tower của Solana được loại bỏ. Giờ đây, các trình xác thực chỉ cần theo dõi chuỗi chứng chỉ mới nhất trong bộ nhớ, giúp rút ngắn thời gian khởi động lại.

Alpenglow tác động thế nào đến các nhà cung cấp RPC?

Thiết kế mới này chủ yếu mang lại những tác động vận hành tích cực cho các nhà cung cấp RPC, dù một số khía cạnh có thể gây lo ngại về khả năng mở rộng:

Đơn giản hóa các mức cam kết 

Mức hoàn tất mới này sẽ xóa bỏ khoảng cách lâu nay giữa các mức cam kết confirmed (tức lạc quan) và finalized (tức đã được neo gốc). Ví dụ: điều này có nghĩa là mọi logic UX chờ hai mức xác nhận (chẳng hạn hiển thị biểu tượng tải cho đến khi finalized) có thể được rút gọn thành một lần kiểm tra chứng chỉ.

Giảm kích thước sổ cái

Với nhu cầu hiện tại của Solana, tốc độ tăng trưởng sổ cái sẽ giảm khoảng ba phần tư do không còn transaction bỏ phiếu. Điều này cũng giúp giảm kích thước snapshot và kho lưu trữ. Tuy nhiên, xét đến các mục tiêu dự kiến về việc tăng giới hạn CU của khối, kết quả thực tế vẫn chưa thể xác định.

Nút thắt phân phối WebSocket

Với Alpenglow, việc thăm dò transaction không còn hợp lý vì trạng thái hoàn tất xuất hiện trong ~100-150ms và được mã hóa trong một chứng chỉ duy nhất. Sẽ hợp lý hơn nếu nhận thông tin hoàn tất qua một kênh đẩy luôn mở trong suốt vòng đời của ứng dụng, trình duyệt hoặc bot, đồng thời phát mọi chứng chỉ mới đến từng client đã đăng ký. Điểm nghẽn chuyển từ hàng triệu lượt thăm dò HTTP nhỏ sang hàng trăm nghìn socket thời gian thực.

Độ mới của bộ nhớ đệm theo thời gian thực

Mọi bộ nhớ đệm giữ dữ liệu account lâu hơn một phần tư giây đều có khả năng hiển thị dữ liệu cũ vì chứng chỉ xác nhận một khối trong vòng 100-150ms. Bộ nhớ đệm biên, CDN và proxy Layer 7 sẽ cần TTL cực ngắn hoặc các hook xóa dữ liệu nhận biết chứng chỉ.

Lộ trình phát triển Alpenglow là gì?

Alpenglow chính thức được công bố tại hội nghị New York Accelerate vào cuối tháng 5. Giai đoạn tiếp theo bao gồm việc công bố một Tài liệu Cải tiến Solana (SIMD) chính thức, qua đó mở đề xuất để cộng đồng phản hồi trên GitHub, các diễn đàn quản trị Solana và Solana Tech Discord.

Sau giai đoạn cộng đồng đánh giá, đề xuất sẽ được đưa ra biểu quyết quản trị on-chain bởi cộng đồng trình xác thực. Song song đó, thiết kế mới sẽ trải qua quá trình kiểm thử toàn diện để đảm bảo hiệu năng và bảo mật.

Nếu mọi giai đoạn diễn ra đúng kế hoạch, Alpenglow dự kiến được triển khai lên mainnet Solana vào đầu năm sau.

Rủi ro và câu hỏi còn bỏ ngỏ về Alpenglow

Một thuật toán đồng thuận mới

Chuyển sang một giao thức đồng thuận mới là nhiệm vụ lớn, nhưng đã có tiền lệ đáng chú ý. The Merge của Ethereum năm 2022 cho thấy một mạng lớn đang hoạt động có thể chuyển đổi thành công cơ chế đồng thuận cốt lõi từ Proof-of-Work sang Proof-of-Stake mà không làm gián đoạn hoạt động. Nói cách khác, vẫn có rất nhiều rủi ro, nhưng đây không phải lãnh thổ hoàn toàn chưa được khám phá.

Quá trình chuyển đổi như vậy cũng đòi hỏi các hướng dẫn di chuyển để ứng dụng, SDK, ví và bot không âm thầm ngừng hoạt động khi Alpenglow hợp nhất các mức cam kết confirmed và finalized thành một lần kiểm tra chứng nhận duy nhất. Mọi mã nguồn thăm dò rõ ràng hai mức cam kết hoặc mặc định dùng mức cam kết confirmed sẽ ngừng hoạt động. Hệ sinh thái cần phối hợp về tài liệu, cảnh báo lint, phương thức RPC và kiến trúc mã nguồn tổng thể trước khi Alpenglow đi vào hoạt động. 

Quản trị

Rủi ro quản trị là một yếu tố khác cần cân nhắc. Cuộc bỏ phiếu SIMD-228 gần đây cho thấy Solana vận hành như một mạng thực sự phi tập trung, nơi các đề xuất, kể cả khi được các nhà phát triển cốt lõi và thành viên nổi bật trong cộng đồng ủng hộ, cũng không chắc chắn được thông qua. Tuy nhiên, những thay đổi sắp tới do Alpenglow mang lại, đặc biệt là việc giảm chi phí bỏ phiếu, nhìn chung có lợi cho các trình xác thực, nhất là các đơn vị vận hành nhỏ. Vì vậy, chúng tôi cho rằng khả năng gặp phải sự phản đối về quản trị là tương đối thấp.

Phần thưởng

Sách trắng Alpenglow và các tài liệu liên quan đã công bố đến nay chưa nêu rõ cơ chế cụ thể để trao thưởng cho hoạt động bỏ phiếu của trình xác thực hoặc đền bù cho các relay Rotor về mức sử dụng băng thông. Sách trắng cũng nêu rõ hành vi bỏ phiếu mâu thuẫn sẽ bị trừng phạt, nhưng chưa chỉ rõ ai thực sự gửi hình phạt, mức phạt là bao nhiêu và hình phạt đó được thực thi tự động hay thông qua quản trị. Những điểm thiếu sót này khiến các khía cạnh then chốt trong mô hình kinh tế của trình xác thực chưa được xác định và có thể trở thành chủ đề tranh luận gay gắt trong hệ sinh thái.

MEV

Alpenglow cũng sẽ tái cấu trúc căn bản bối cảnh MEV hiện tại trên Solana. Độ trễ tiếp tục là một yếu tố chi phối MEV vì một số chiến lược sinh lời dựa vào việc sao chép lưu lượng TPU hoặc liên tục hủy và thay thế transaction theo một thứ tự nhất định trước khi chúng được xác nhận theo cơ chế lạc quan. Tất cả diễn ra trong khung thời gian ~500-600ms hiện tại, còn Alpenglow hướng đến rút ngắn xuống ~150ms. Thoạt nhìn, các leader, đặc biệt là những trình xác thực đã vận hành hạ tầng dựng khối tùy chỉnh, có thể giành được phần MEV lớn hơn, trong khi các nhà kinh doanh chênh lệch độ trễ độc lập có thể mất lợi thế nếu không tiếp tục phát triển những hệ thống giao dịch nhanh hơn và chi tiết hơn nữa.

Nhiều leader đồng thời

So với kiến trúc đồng thuận hiện tại của Solana, thiết kế của Alpenglow linh hoạt hơn nhiều trong việc áp dụng khuôn khổ đa leader—được gọi là Multiple Concurrent Leaders (MCL). Như Anatoly Yakovenko đã lưu ý, nguyên mẫu MCL ban đầu có thể bao gồm việc khởi chạy hai phiên bản Alpenglow dùng chung một tập hợp Rotor và phát hành đồng thời tất cả shred. Rotor sẽ phân phối các luồng song song và Votor sẽ chứng thực từng làn. Tuy nhiên, một số câu hỏi ở lớp thực thi bắt đầu xuất hiện. Cụ thể:

• Nên phân vùng các tập hợp ghi như thế nào để khối của hai leader không bao giờ khóa cùng một account—hoặc nếu có, việc giải quyết xung đột phải vừa mang tính xác định vừa ít tốn kém?
• Làm thế nào để hợp nhất các chứng chỉ của từng làn thành một state root chính tắc mà không làm tăng gấp đôi chi phí phát lại?
• Loại logic thị trường phí nào sẽ được áp dụng khi các làn cạnh tranh tài sản?
• Cơ chế này sẽ tạo điều kiện cho những loại chiến lược MEV xuyên làn nào?
• Liệu một trình xác thực có cổ phần lớn có thể thống trị các slot đồng thời nếu không giới hạn số làn không? 

Mặc dù thiết kế của Alpenglow giúp MCL trở thành một hạng mục thực tế trong lộ trình bằng cách loại bỏ các rào cản ở cấp độ đồng thuận, đây vẫn là một định hướng trong tương lai đầy triển vọng cho đến khi các câu hỏi còn bỏ ngỏ này được giải đáp.

Kết luận

Báo cáo này đã khám phá các thành phần cốt lõi của Alpenglow và xem xét cách chúng định hình lại mô hình đồng thuận của Solana. Chúng tôi cũng đã phân tích các cải tiến kỹ thuật, những thay đổi đối với mô hình kinh tế của trình xác thực, tác động ở cấp độ mạng và lợi ích về hiệu năng, tính đơn giản cũng như khả năng mở rộng.

Sách trắng Alpenglow đánh dấu một bước ngoặt đối với Solana, không chỉ trong thiết kế giao thức mà còn trong triết lý phát triển. Lần đầu tiên, Solana công bố các bằng chứng chính xác hình thức cho thuật toán đồng thuận của mình, báo hiệu sự chuyển đổi từ cách tiếp cận truyền thống dựa trên thực nghiệm và kỹ thuật sang một nền tảng nghiêm ngặt hơn, được hậu thuẫn bởi nghiên cứu. Sự phát triển này phản ánh một hệ sinh thái đang trưởng thành, tiếp tục ưu tiên hiệu năng nhưng giờ đây có thêm tính kỷ luật của phương pháp xác minh hình thức.

Việc ngừng sử dụng Proof-of-History (PoH) cũng thể hiện một thay đổi mang tính biểu tượng tương tự trong bản sắc của mạng. Dù tầm quan trọng thực tiễn của PoH thường bị phóng đại, từ lâu đây vẫn là đổi mới đặc trưng của Solana, xuất hiện nổi bật trong các tài liệu kỹ thuật nhập môn và trở thành yếu tố đồng nghĩa với thương hiệu. Việc loại bỏ PoH đánh dấu sự kết thúc của một kỷ nguyên và khởi đầu của một kỷ nguyên mới. Solana đang trưởng thành.

Tài nguyên bổ sung

• Trang trình bày về Alpenglow tại Accelerate - Roger Wattenhofer
• Alpenglow: Cơ chế đồng thuận mới cho Solana - Blog Anza
• Bản triển khai tham chiếu Alpenglow - GitHub
• Sách trắng Alpenglow - Quentin Kniep, Jakub Sliwinski, Roger Wattenhofer
• Đồng thuận trên Solana - Blog Helius
• Mở rộng hoặc bị đào thải tại Accelerate 2025: Giới thiệu Alpenglow - Cơ chế đồng thuận mới của Solana - Video YouTube