Cơ chế đồng thuận Solana: PoH, Tower BFT, PoS

Lưu ý về độ chính xác: Hiệu suất mạng, số lượng trình xác thực, phí, tính năng giao thức, hỗ trợ ví và tích hợp của bên thứ ba thay đổi theo thời gian. Hãy coi các số liệu đã cũ là ảnh chụp nhanh lịch sử và xác minh tài liệu nguồn chính hiện tại.

Cơ chế đồng thuận Solana kết hợp Bằng chứng Lịch sử để sắp xếp thời gian, Tower BFT để bỏ phiếu có trọng số stake và Bằng chứng Stake để tham gia và khuyến khích trình xác thực.

Tóm tắt: Solana sử dụng Bằng chứng Lịch sử để sắp xếp thời gian, Tower BFT để bỏ phiếu có trọng số stake và lựa chọn Fork, và Bằng chứng Stake để tham gia và khuyến khích trình xác thực. Thông lượng và xác nhận phụ thuộc vào toàn bộ thời gian chạy, điều kiện mạng, hỗn hợp giao dịch và mức độ cam kết đang được đo lường.

Mục lục

1. Cơ chế đồng thuận Solana là gì?
2. Vấn đề mà Solana được xây dựng để giải quyết
3. Bằng chứng Lịch sử: Đồng hồ mật mã của Solana được giải thích
4. Tower BFT: Cách các trình xác thực đạt được sự đồng thuận
5. Bằng chứng Lịch sử, Tower BFT và Bằng chứng Stake hoạt động cùng nhau như thế nào
6. Cách một giao dịch Solana đạt được tính cuối cùng: Từng bước
7. Hiệu suất Solana: Tốc độ, Thông lượng và Tính cuối cùng
8. Cơ chế đồng thuận Solana so với Ethereum, Avalanche, Cardano và Polkadot
9. Ưu điểm và hạn chế của mô hình đồng thuận Solana
10. Cách tham gia: Staking và xác thực trên Solana
11. Câu hỏi thường gặp
12. Điểm chính cần ghi nhớ

Solana được thiết kế cho việc thực thi thông lượng cao, độ trễ thấp, trong khi lịch sử sự cố và yêu cầu trình xác thực của nó tạo ra các câu hỏi quan trọng về độ tin cậy và tính phi tập trung. Những sự đánh đổi đó là trọng tâm để hiểu cơ chế đồng thuận.

Solana đã ra mắt bản thử nghiệm Mainnet Beta vào tháng 3 năm 2020 và nhanh chóng thu hút sự chú ý nhờ xử lý hàng nghìn giao dịch mỗi giây với chi phí chỉ vài xu cho mỗi giao dịch. Các giao thức DeFi và thị trường NFT được xây dựng trên Solana phụ thuộc vào thông lượng đó; đó là điều làm cho giao dịch theo thời gian thực, các đợt mint NFT hàng loạt và thanh toán phí nhỏ trở nên khả thi trên chuỗi. Nhưng tốc độ mà không có độ tin cậy thì không phải là nền tảng mà bất kỳ ai cũng nên xây dựng, và một số sự cố ngừng hoạt động cấp cao giữa năm 2021 và 2023 đã đặt ra những câu hỏi chính đáng về kiến trúc của giao thức có vững chắc hay không.

Bài viết này giải thích cơ chế một cách trung thực: cách thức hoạt động, tại sao nó nhanh, tại sao mạng bị ngừng hoạt động và những đánh đổi đó có ý nghĩa gì đối với bất kỳ ai đánh giá Solana với tư cách là nhà đầu tư, nhà phát triển hoặc người tham gia.

Cơ chế đồng thuận Solana là gì?

Solana sử dụng một hệ thống đồng thuận kết hợp ba thành phần: Proof of History (PoH), Tower BFT và Proof of Stake (PoS). Bằng chứng Lịch sử hoạt động như một đồng hồ mật mã đánh dấu thời gian cho các giao dịch trước khi các trình xác thực giao tiếp. Tower BFT là thuật toán đồng thuận chịu lỗi Byzantine đạt được sự đồng thuận bằng cách sử dụng PoH làm đồng hồ chung. Bằng chứng Stake xác định trình xác thực nào tham gia và trọng số phiếu bầu của họ theo SOL đã stake.

Ba thành phần này không phải là tên có thể thay thế cho cùng một thứ. Mỗi thành phần đóng một vai trò riêng biệt trong cách Solana tạo và xác nhận các khối trên Blockchain của nó, sổ lệnh phân tán ghi lại tất cả các giao dịch trên mạng.

Đây là cách hệ thống hoạt động ở cấp độ cao:

1. Bằng chứng Lịch sử tạo ra một bản ghi thời gian liên tục, có thể xác minh mà tất cả các trình xác thực trên mạng đều chia sẻ.
2. Các trình xác thực (những người tham gia mạng tạo và xác minh các khối) được chỉ định vào các khoảng thời gian cụ thể dựa trên lượng SOL họ đã stake.
3. Trình xác thực lãnh đạo được chỉ định cho mỗi khoảng thời gian sử dụng dòng thời gian PoH để đánh dấu thời gian và lắp ráp các giao dịch thành một khối.
4. Tất cả các trình xác thực khác xác minh khối và bỏ phiếu Tower BFT có trọng số stake; khi hơn hai phần ba SOL đã stake xác nhận khối, khối đó sẽ đạt được tính cuối cùng.

Nhầm lẫn phổ biến: Solana không phải là một Blockchain Bằng chứng Công việc (không có giải câu đố tính toán hoặc tính toán tiêu tốn năng lượng). Gọi Solana đơn giản là "một Blockchain Bằng chứng Stake" là chính xác về mặt kỹ thuật nhưng chưa đầy đủ. Nó bỏ qua Bằng chứng Lịch sử và Tower BFT, những yếu tố cũng quan trọng ngang nhau trong cách Solana đạt được sự đồng thuận. Mô tả đầy đủ và chính xác là: Solana sử dụng một hệ thống kết hợp gồm PoH, Tower BFT và PoS.

Vấn đề mà Solana được xây dựng để giải quyết

Mọi cơ chế đồng thuận Blockchain đều đối mặt với cùng một thách thức nền tảng: làm thế nào để hàng nghìn máy tính được phân phối trên toàn cầu đồng ý về thứ tự các giao dịch mà không cần tin tưởng lẫn nhau?

Tam giác bất khả thi về khả năng mở rộng của Blockchain, một khuôn khổ được phổ biến bởi người đồng sáng lập Ethereum Vitalik Buterin, mô tả lý do tại sao điều này lại khó khăn. Tam giác bất khả thi phát biểu rằng một Blockchain thực tế chỉ có thể đạt được tối đa hai trong ba thuộc tính đồng thời: tính phi tập trung, bảo mật và khả năng mở rộng. Bitcoin, Blockchain gốc, ưu tiên tính phi tập trung và bảo mật. Kết quả là một mạng đạt khoảng 7 giao dịch mỗi giây với thời gian khối 10 phút, những thuộc tính an toàn và được phân phối rộng rãi nhưng khiến Bitcoin không thực tế cho các ứng dụng tần suất cao. Ethereum giai đoạn đầu cũng đối mặt với những hạn chế tương tự trước con đường nâng cấp của chính nó.

Nút thắt cổ chai cụ thể làm cho việc mở rộng quy mô trở nên khó khăn là độ trễ mạng. Trong cơ chế đồng thuận truyền thống, các trình xác thực phải gửi các thông điệp có dấu thời gian cho nhau để đồng ý về thứ tự các giao dịch. Chi phí truyền thông liên lạc giữa các nút này tạo ra một giới hạn về tốc độ mà bất kỳ mạng nào có thể đạt được sự đồng thuận. Bất kể máy tính cá nhân xử lý dữ liệu nhanh như thế nào, chúng vẫn phải đợi thông điệp di chuyển khắp thế giới và tất cả người tham gia xác nhận những gì họ nhận được.

Anatoly Yakovenko, một cựu kỹ sư Qualcomm đã dành sự nghiệp của mình để làm việc về các hệ thống phân tán và đồng bộ hóa đồng hồ ở cấp độ phần cứng, đã xác định vấn đề giao tiếp dấu thời gian này là nút thắt cổ chai cơ bản. Ý tưởng chính của ông: nếu các trình xác thực có thể chia sẻ một đồng hồ duy nhất, có thể xác minh bằng mật mã mà tất cả họ đều tin cậy mà không cần liên lạc dấu thời gian với nhau, thì quy trình đồng thuận có thể nhanh hơn đáng kể. Vào tháng 11 năm 2017, Yakovenko đã xuất bản Solana: Một kiến trúc mới cho Blockchain hiệu năng cao,) phác thảo những gì sẽ trở thành Bằng chứng Lịch sử. Ông đồng sáng lập Solana Labs (công ty phát triển vì lợi nhuận đứng sau giao thức Solana) với Greg Fitzgerald và Raj Gokal, và ba người đã ra mắt bản thử nghiệm Mainnet Beta vào tháng 3 năm 2020.

Luận điểm thiết kế của Solana là tam giác bất khả thi về khả năng mở rộng có thể được giảm thiểu đáng kể, không bị loại bỏ nhưng giảm thiểu, bằng cách kết hợp các phương pháp mật mã mới lạ (PoH) với khả năng phần cứng hiện đại để đẩy cả ba chỉ số lên cao hơn đồng thời. Việc liệu sự giảm thiểu đó có phải trả giá bằng tính phi tập trung hay không là một câu hỏi mà bằng chứng trong bài viết này giải quyết trực tiếp.

Bằng chứng Lịch sử: Đồng hồ mật mã của Solana được giải thích

Proof of History (PoH) là một cơ chế tính thời gian mật mã học tạo ra một bản ghi có thể xác minh, chống giả mạo về thời điểm mỗi sự kiện trên mạng lưới Solana xảy ra. Bằng cách cung cấp cho tất cả các trình xác thực một đồng hồ dùng chung mà họ có thể tin cậy mà không cần trao đổi thông điệp, PoH cho phép thuật toán đồng thuận thực tế của Solana, Tower BFT, hoạt động với ít vòng giao tiếp hơn nhiều so với bất kỳ hệ thống đồng thuận Blockchain tiêu chuẩn nào.

PoH không phải là một Cơ chế đồng thuận. Nó là chiếc đồng hồ giúp cho Cơ chế đồng thuận của Solana khả thi.

Proof of History Giải Quyết Vấn Đề Gì?

Trong một mạng lưới phi tập trung không có cơ quan trung ương, các trình xác thực không thể chỉ đơn giản là đồng ý sử dụng một đồng hồ treo tường. Mỗi nút chạy trên phần cứng khác nhau ở các múi giờ khác nhau và đồng hồ sẽ bị lệch. Quan trọng hơn, một trình xác thực độc hại có thể giả mạo dấu thời gian để thao túng thứ tự giao dịch. Các mạng lưới Blockchain truyền thống giải quyết vấn đề này bằng cách yêu cầu các trình xác thực gửi các thông điệp có gắn dấu thời gian cho nhau và đạt được thỏa thuận thông qua nhiều vòng giao tiếp. Mỗi vòng giao tiếp bổ sung đều làm tăng độ trễ.

PoH loại bỏ độ trễ đó bằng cách tạo ra một dòng thời gian dùng chung mà tất cả các trình xác thực có thể xác minh độc lập, mà không cần bất kỳ hoạt động giao tiếp liên nút nào để thiết lập thời điểm một sự việc đã xảy ra.

Cách Proof of History Hoạt Động: Chuỗi Băm (Hash Chain)

Hãy coi PoH giống như một đồng hồ bấm giờ mật mã học chạy liên tục trên mạng lưới. Mỗi tích tắc của đồng hồ bấm giờ tạo ra một đầu ra duy nhất, có thể xác minh được. Vì mỗi đầu ra được tạo ra từ đầu ra trước đó, bất kỳ ai cũng có thể xác minh toàn bộ chuỗi và xác nhận rằng một khoảng thời gian cụ thể đã trôi qua giữa hai điểm bất kỳ, mà không cần phải tin tưởng vào chủ sở hữu của đồng hồ.

Cơ chế kỹ thuật hoạt động như sau:

1. Trình tạo Solana PoH bắt đầu với một giá trị băm ban đầu.
2. Nó chạy hàm băm mật mã SHA-256 trên giá trị đó, tạo ra một đầu ra 256-bit mới.
3. Nó ngay lập tức đưa đầu ra đó trở lại làm đầu vào cho hoạt động SHA-256 tiếp theo.
4. Mỗi hàm băm trong chuỗi được ghi lại cùng với một bộ đếm, tạo ra một trình tự có thể xác minh để chứng minh thời gian tính toán thực tế đã trôi qua.
5. Các giao dịch được chèn vào chuỗi băm tại các vị trí cụ thể, gắn dấu thời gian vĩnh viễn cho chúng so với trình tự có thể xác minh trước khi bất kỳ trình xác thực nào cần giao tiếp với trình xác thực khác.

Kết quả là một bản ghi công khai về chính xác thời điểm mỗi giao dịch đi vào hàng đợi. Bất kỳ ai cũng có thể xác minh chuỗi còn nguyên vẹn. Không ai có thể làm giả thời gian cần thiết để tạo ra nó.

Ngôn ngữ bình dân: PoH giống như một đồng hồ bấm giờ mật mã học gắn dấu thời gian cho mọi sự kiện trước khi các trình xác thực thậm chí cần phải giao tiếp. Nó là một bản ghi công khai về chính xác thời điểm mỗi giao dịch đi vào hàng đợi, có thể được xác minh bởi bất kỳ ai và không ai có thể thao túng.

Tìm hiểu sâu về kỹ thuật: SHA-256 là một hàm băm mật mã một chiều: tính toán theo một chiều thì nhanh, nhưng về mặt tính toán thì không thể đảo ngược để tìm lại dữ liệu gốc. Việc liên kết tuần tự các đầu ra SHA-256 mang lại cho PoH thuộc tính "trễ có thể xác minh" (verifiable delay): chuỗi này mất thời gian thực để tạo ra (tính toán tuần tự không thể thực hiện song song), nhưng có thể được xác minh song song rất nhanh bởi bất kỳ người quan sát nào kiểm tra từng hàm băm so với hàm băm trước đó. Điều này về mặt chức năng tương tự như Verifiable Delay Function (VDF), một cấu trúc mật mã yêu cầu một lượng tính toán tuần tự tối thiểu để tạo ra nhưng có thể được xác minh nhanh chóng. Vai trò của SHA-256 trong PoH hoàn toàn khác với vai trò của nó trong Bitcoin, nơi nó được sử dụng như một trò chơi đố cạnh tranh (tìm một hàm băm dưới một mục tiêu). Trong PoH, SHA-256 được sử dụng để tính thời gian tuần tự, không phải để tính toán cạnh tranh.

Proof of History Là Gì Và Không Phải Là Gì

Proof of History không phải là Cơ chế đồng thuận của Solana. Một Cơ chế đồng thuận là quá trình mà qua đó các trình xác thực đạt được thỏa thuận về việc giao dịch nào là hợp lệ và theo thứ tự nào. PoH không làm điều đó. PoH ghi lại thứ tự và thời gian của các sự kiện; Tower BFT là thuật toán đạt được sự đồng thuận về việc liệu các sự kiện đó có hợp lệ hay không.

PoH cũng không phải là Proof of Stake. Proof of Stake xác định ai có đủ điều kiện kinh tế để tham gia vào quá trình đồng thuận và phiếu bầu của họ có trọng số bao nhiêu. PoH không xác định điều kiện tham gia hay trọng số phiếu bầu; nó cung cấp đồng hồ dùng chung giúp quá trình bỏ phiếu nhanh hơn.

Quan niệm sai lầm rằng "Solana sử dụng Proof of History" làm Cơ chế đồng thuận hoàn chỉnh của nó là một trong những lỗi phổ biến nhất trong các bài viết công khai về Solana. Điều đó không chính xác và nó quan trọng: nếu không có Tower BFT và Proof of Stake, riêng PoH sẽ không cung cấp đảm bảo an ninh nào.

Tower BFT: Cách Các Trình Xác Thực Đạt Được Thỏa Thuận

Tower BFT là thuật toán đồng thuận của Solana, một sự điều chỉnh của Practical Byzantine Fault Tolerance (PBFT) được xây dựng để sử dụng PoH làm đồng hồ dùng chung. Nó cho phép các trình xác thực đạt được thỏa thuận về trạng thái của sổ cái bằng cách sử dụng các phiếu bầu có trọng số cổ phần (stake-weighted votes). Bởi vì các trình xác thực dùng chung Proof of History như một đồng hồ đáng tin cậy, Tower BFT yêu cầu ít vòng giao tiếp hơn nhiều so với các triển khai BFT tiêu chuẩn và hoàn tất các khối trong khoảng 400 đến 800 mili giây trong điều kiện mạng bình thường.

Byzantine Fault Tolerance Là Gì?

Tên gọi này bắt nguồn từ Bài toán các vị tướng Byzantine, một thí nghiệm tư duy về các hệ thống phân tán cổ điển được Leslie Lamport chính thức hóa vào năm 1982. Bài toán đặt ra câu hỏi: làm thế nào một nhóm các vị tướng có thể phối hợp một cuộc tấn công khi một số người trong số họ có thể là những kẻ phản bội gửi thông tin sai lệch? Một hệ thống là Byzantine Fault Tolerant (Khả năng chịu lỗi Byzantine) nếu nó có thể đạt được sự đồng thuận chính xác ngay cả khi một số người tham gia hành động ác ý, gửi thông điệp sai hoặc gặp lỗi tùy ý.

Các hệ thống BFT truyền thống, bao gồm thuật toán PBFT nền tảng được Miguel Castro và Barbara Liskov công bố năm 1999, yêu cầu ít hơn một phần ba số người tham gia bị lỗi hoặc ác ý. Đối với một mạng lưới có 100 trình xác thực, tối đa 33 trình có thể bị xâm phạm và 67 trình còn lại vẫn có thể đạt được sự đồng thuận chính xác. Thuộc tính này có thể chứng minh được về mặt toán học, điều này làm cho các hệ thống dựa trên BFT trở nên hấp dẫn đối với các ứng dụng quan trọng về bảo mật.

Tower BFT của Solana kế thừa thuộc tính này. Một kẻ tấn công sẽ cần kiểm soát hơn một phần ba tổng số SOL đã được stake để làm dừng mạng lưới, và hơn hai phần ba để ghi đè sự đồng thuận. Không giống như các mạng lưới Proof of Work nơi kẻ tấn công cần 51% sức mạnh tính toán, Tower BFT của Solana yêu cầu kiểm soát hơn 33% tổng số SOL đã stake để làm dừng mạng lưới. Ngưỡng đó thường được coi là khó đạt được hơn trong thực tế vì nó yêu cầu tích lũy vốn, không chỉ là tài nguyên tính toán.

Tìm hiểu sâu về kỹ thuật: PBFT tiêu chuẩn yêu cầu độ phức tạp thông điệp O(n²), trong đó n là số lượng trình xác thực. Mỗi trình xác thực phải giao tiếp với mọi trình xác thực khác để xác nhận sự đồng thuận. Đối với các mạng lưới có hàng nghìn trình xác thực, điều này tạo ra chi phí giao tiếp cực lớn. Tower BFT giảm chi phí này bằng cách sử dụng PoH làm đồng hồ dùng chung: vì tất cả các trình xác thực đồng ý về thời gian từ trình tự PoH mà không cần nhắn tin cho nhau về điều đó, Tower BFT chỉ cần các trình xác thực bỏ phiếu về tính hợp lệ của khối, chứ không phải về thứ tự dấu thời gian. Cơ chế khóa (lockout) tạo thêm một hiệu quả khác: khi một trình xác thực bỏ phiếu cho một khối, nó sẽ bị khóa vào phiếu bầu đó trong một khoảng thời gian chờ tăng dần theo cấp số nhân. Việc thay đổi phiếu bầu yêu cầu phải chờ hết thời gian khóa, tạo ra một sự không khuyến khích về mặt kinh tế đối với các lần Fork và giảm số vòng bỏ phiếu cần thiết để đạt được tính hữu hạn (finality).

Cách Tower BFT Sử Dụng Proof of History

Nếu không có đồng hồ dùng chung, các trình xác thực trong hệ thống BFT tiêu chuẩn phải gửi các thông điệp có gắn dấu thời gian cho nhau để thiết lập thứ tự các sự kiện, làm tăng chi phí giao tiếp ở mỗi bước. Với PoH, thứ tự đã được thiết lập và có thể kiểm chứng độc lập bởi mọi trình xác thực.

Các trình xác thực thực hiện bỏ phiếu có trọng số cổ phần cho các khối và Tower BFT sử dụng các lần khóa và bỏ phiếu đa số tuyệt đối trong việc lựa chọn Fork. Xác nhận lạc quan (optimistic confirmation), xác nhận gốc (rooted confirmation) và tính hữu hạn kinh tế ở cấp độ ứng dụng là các ngưỡng khác nhau. Thời gian của chúng thay đổi tùy theo điều kiện cụm và nên được kiểm tra trong tài liệu hiện tại thay vì quy về một con số mili giây cố định.

Lịch trình Leader: Cách Solana Chọn Các Trình Xác Thực

Vào đầu mỗi epoch, Solana sẽ tính toán một sự phân bổ xác định về việc validator nào sẽ làm leader cho mỗi slot sắp tới. Việc phân bổ này tỷ lệ thuận với trọng số stake của mỗi validator: một validator kiểm soát 5% tổng số SOL được stake sẽ được chỉ định làm leader cho xấp xỉ 5% tổng số slot trong epoch đó.

Một slot là đơn vị thời gian cơ bản của Solana, mục tiêu là khoảng 400 mili giây mỗi slot (xác minh số liệu hiện tại từ docs.solana.com tại thời điểm viết bài). Một epoch kéo dài khoảng 432.000 slot, tương đương với khoảng hai đến ba ngày (xác minh từ docs.solana.com tại thời điểm viết bài).

Lịch trình leader được công khai trước. Các validator có thể sử dụng lịch trình này để chuyển tiếp các giao dịch tới leader sắp tới trước khi slot đó bắt đầu. Điều này làm giảm sự phụ thuộc vào một Mempool toàn cầu thông thường, nhưng không loại bỏ được tình trạng tắc nghẽn, cạnh tranh phí ưu tiên, giao dịch bị hủy hoặc rủi ro MEV.

Hệ quả của việc phân quyền theo lãnh đạo dựa trên trọng số stake là trực tiếp: các validator có nhiều SOL được stake hơn sẽ nhận được số lượng slot làm leader nhiều hơn một cách tương ứng, nghĩa là họ tạo ra nhiều khối hơn một cách tương ứng. Cấu trúc này mang lại cho những người stake lớn hơn nhiều ảnh hưởng hơn đối với việc giao dịch nào được đưa vào và theo thứ tự nào. Các hệ quả cụ thể của sự tập trung đó, bao gồm hệ số Nakamoto của Solana và các rào cản tham gia về phần cứng, được xem xét trong phần điểm mạnh và hạn chế bên dưới.

Cách Proof of History, Tower BFT và Proof of Stake Hoạt động Cùng nhau

Proof of History, Tower BFT và Proof of Stake không phải là ba cơ chế đồng thuận riêng biệt chạy song song. Chúng là ba lớp phụ thuộc lẫn nhau của một hệ thống tích hợp duy nhất, mỗi lớp giải quyết một phần khác nhau của vấn đề đồng thuận phân tán.

Proof of Stake là nền tảng kinh tế. Các validator phải stake (khóa) SOL để tham gia vào quá trình đồng thuận. Khoản stake này tạo ra sự gắn bó quyền lợi tài chính: các validator bỏ phiếu sai hoặc cố gắng thao túng sổ cái có nguy cơ bị mất số SOL đã stake thông qua hình thức slashing (xác minh chi tiết triển khai slashing hiện tại từ docs.solana.com, vì điều này thay đổi theo các bản nâng cấp giao thức). Những người ủy quyền (Delegators), nghĩa là bất kỳ chủ sở hữu SOL nào không muốn vận hành một validator, có thể stake SOL của họ cho một validator và kiếm được một phần phần thưởng của validator đó tỷ lệ thuận với sự ủy quyền của họ.

Sau khi Proof of Stake xác định ai tham gia và với trọng số bao nhiêu, Proof of History sẽ cung cấp dòng thời gian mà những người tham gia đó sử dụng. Đồng hồ PoH chạy liên tục, tạo ra chuỗi hash có thể xác minh để đóng dấu thời gian cho mọi giao dịch. Không cần giao tiếp giữa các nút để thiết lập thứ tự vì tất cả các validator đều có thể xác minh chuỗi PoH một cách độc lập.

Tower BFT là thuật toán mà các validator đủ điều kiện, được đồng bộ hóa thời gian đó sử dụng để bỏ phiếu. Sự kết hợp của một đồng hồ chung (PoH) và một hệ thống bỏ phiếu được bảo mật về mặt kinh tế (Tower BFT theo trọng số PoS) tạo ra sự đồng thuận vừa nhanh chóng vừa có khả năng chống thao túng.

Các validator đạt được đồng thuận về trạng thái khối, bao gồm kết quả của các Hợp đồng Thông minh, được gọi là các chương trình (programs) trong hệ sinh thái của Solana. Môi trường thực thi Hợp đồng Thông minh song song của Solana (Sealevel) cho phép nhiều chương trình không xung đột thực thi đồng thời, góp phần nâng cao hơn nữa thông lượng của mạng lưới.

Cách một Giao dịch Solana Đạt đến Trạng thái Cuối cùng: Từng bước một

Một giao dịch Solana có thể được định tuyến tới các leader đã được lên lịch mà không cần chờ đợi trong một Mempool toàn cầu thông thường. Vòng đời của nó tuân theo các giai đoạn dưới đây, nhưng xác nhận và Thời gian Quyết toán thay đổi tùy theo mức độ cam kết và điều kiện cụm; thời lượng slot mục tiêu không phải là một đảm bảo hoàn tất cuối cùng.

1. Gửi Giao dịch. Người dùng ký và phát sóng một giao dịch tới mạng lưới Solana. Giao dịch đã ký chứa tất cả thông tin mà các validator cần để xác minh tính xác thực của nó: Public Key của người gửi, hoạt động dự định và chữ ký mật mã chứng minh người gửi đã ủy quyền cho giao dịch đó. Việc ký diễn ra cục bộ; sau đó giao dịch được lan truyền đến mạng lưới.

2. Chuyển tiếp Nhận biết Leader. Solana chuyển tiếp giao dịch tới một leader sắp tới được xác định từ lịch trình công khai. Không giống như Mempool toàn cầu thông thường, thiết kế này có thể dàn xếp công việc trước slot của leader, trong khi tình trạng tắc nghẽn, mất gói tin, Đáo hạn giao dịch, phí ưu tiên và các khuyến khích về thứ tự vẫn ảnh hưởng đến kết quả.

3. Đóng dấu Thời gian PoH của Leader. Validator leader chèn giao dịch vào Vị thế hiện tại trong chuỗi hash PoH, ghi lại vĩnh viễn vị trí của giao dịch trong dòng thời gian có thể xác minh. Dấu thời gian này được ràng buộc về mặt mật mã với chuỗi của tất cả các hash PoH trước đó; nó không thể bị thay đổi hồi tố mà không làm mất hiệu lực của mọi hash tiếp theo, làm cho bản ghi có bằng chứng chống giả mạo.

4. Sản xuất Khối. Trong cửa sổ slot xấp xỉ 400 mili giây của mình, leader tập hợp tất cả các giao dịch đã được đóng dấu thời gian thành một khối. Vì các giao dịch đến đã được sắp xếp trước theo trình tự PoH, leader không cần phải thương lượng thứ tự với các validator khác. Nó chỉ đơn giản là xây dựng khối theo dòng thời gian đã thiết lập.

5. Lan truyền Turbine. Giao thức lan truyền khối Turbine của Solana chia khối đã hoàn thành thành các gói dữ liệu nhỏ hơn gọi là các shred và phân phối chúng cho tất cả các validator khác bằng cấu trúc lan truyền dạng cây lấy cảm hứng từ BitTorrent. Thay vì phát sóng toàn bộ khối cho mọi validator cùng một lúc (điều này sẽ đòi hỏi băng thông khổng lồ ở khối lượng lớn), Turbine chuyển các shred qua một cây cấu trúc gồm các validator, với mỗi validator chịu trách nhiệm chuyển tiếp cho một số lượng nhỏ các bên ngang hàng (peers). Điều này làm giảm gánh nặng băng thông lên bất kỳ validator đơn lẻ nào trong khi vẫn đảm bảo toàn bộ khối đến được với tất cả những người tham gia một cách nhanh chóng.

6. Bỏ phiếu Tower BFT. Sau khi nhận được các shred của khối và tái cấu trúc lại toàn bộ khối, các validator khác sẽ xác minh rằng chuỗi PoH là hợp lệ và các giao dịch được hình thành chính xác. Mỗi validator bỏ một phiếu bầu Tower BFT theo trọng số stake về tính hợp lệ của khối. Các validator có nhiều SOL được stake hơn sẽ có trọng số lớn hơn một cách tương ứng trong phiếu bầu này. Các phiếu bầu lan truyền qua mạng lưới khi các validator phát tín hiệu xác nhận của họ.

7. Tính Hoàn tất (Finality). Khi các validator đại diện tập thể cho hơn hai phần ba tổng số SOL được stake đã xác nhận khối, khối đó sẽ đạt được tính hoàn tất của Tower BFT và được ghi lại vĩnh viễn trên sổ cái. Ngưỡng đa số tuyệt đối này giống như yêu cầu 2/3+ làm nền tảng cho lý thuyết Chống lỗi Byzantine (Byzantine Fault Tolerance): nó đảm bảo rằng sự đồng thuận được giữ vững ngay cả khi có tới một phần ba số người tham gia theo trọng số stake bị lỗi hoặc có ý đồ xấu.

Thuật ngữ về tính hoàn tất: Thời gian slot mục tiêu không giống với xác nhận lạc quan (optimistic confirmation), tạo gốc (rooting) hoặc tính hoàn tất kinh tế. Các ứng dụng nên chọn một mức độ cam kết dựa trên các yêu cầu rủi ro của mình và xác minh hành vi cụm hiện tại.

Hiệu suất của Solana: Tốc độ, Thông lượng và Tính Hoàn tất

Tốc độ của Solana không phải là kết quả của bất kỳ lựa chọn thiết kế đơn lẻ nào. Đó là hiệu ứng tích lũy của bốn quyết định kiến trúc hoạt động phối hợp với nhau: Proof of History, Tower BFT, giao thức Gulf Stream của Solana và giao thức lan truyền khối Turbine của Solana.

Tại sao Solana lại nhanh? Bốn lý do

1. Proof of History cung cấp một tham chiếu thứ tự có thể kiểm chứng, giúp giảm bớt một số chi phí điều phối thời gian; các validator vẫn trao đổi phiếu bầu và dữ liệu mạng.
2. Tower BFT yêu cầu ít vòng bỏ phiếu hơn so với các triển khai BFT tiêu chuẩn vì tất cả các validator đều chia sẻ chung một đồng hồ PoH và không cần thương lượng về thời gian.
3. Leader-aware forwarding (Chuyển tiếp nhận biết leader) gửi các giao dịch tới các leader sắp tới trước khi slot của họ bắt đầu, điều này có thể làm giảm hàng đợi mempool truyền thống mà không loại bỏ hoàn toàn độ trễ hoặc sự cạnh tranh về phí.
4. Giao thức lan truyền khối Turbine của Solana phân phối các khối thành các mảnh nhỏ (shreds) thông qua cấu trúc cây thay vì phát sóng toàn bộ khối tới mọi validator cùng một lúc, giúp giảm yêu cầu băng thông trên các mạng lưới lớn.

Thông lượng tối đa lý thuyết của Solana là một con số lý thuyết lịch sử khoảng 65.000 giao dịch mỗi giây trong điều kiện mạng lý tưởng. Con số đó là một điểm chuẩn (benchmark), không phải là mô tả về hiệu suất điển hình. Thông lượng thực tế trên Mainnet trong lịch sử trung bình khoảng 2.000 đến 4.000 TPS, với các mức đỉnh trong thời gian nhu cầu cao. Khoảng cách giữa mức tối đa lý thuyết và mức trung bình thực tế phản ánh độ trễ lan truyền mạng, phân bổ địa lý của validator và chi phí phần mềm mà các điểm chuẩn điều kiện lý tưởng không nắm bắt được. Hãy xác minh các con số hiện tại từ Solscan (solscan.io) tại thời điểm viết bài.

Tài liệu của Solana trong lịch sử đã mô tả thời gian slot mục tiêu là gần 400 mili giây, nhưng các slot thực tế và các giai đoạn xác nhận có sự thay đổi. Xác nhận lạc quan (Optimistic confirmation), rooting và tính hoàn tất kinh tế ở cấp độ ứng dụng là các ngưỡng khác nhau và nên được đo lường bằng tài liệu hiện tại và điều kiện cụm (cluster) trực tiếp.

Để so sánh: Ethereum, mạng lưới đã chuyển từ Proof of Work sang Proof of Stake vào tháng 9 năm 2022, hiện đạt khoảng 15 đến 30 TPS trên Layer 1 của mình với tính hoàn tất kinh tế đầy đủ mất khoảng 12 đến 15 phút thông qua các epoch điểm kiểm soát Casper FFG (xác minh từ ethereum.org). Cơ chế đồng thuận Nakamoto của Bitcoin đạt khoảng 7 TPS với tính hoàn tất xác suất mất khoảng 60 phút qua 6 lần xác nhận khối.

Khoảng cách về tính hoàn tất giữa Solana và Ethereum Layer 1 là đáng kể. Việc khoảng cách đó có quan trọng đối với một trường hợp sử dụng cụ thể hay không tùy thuộc vào ứng dụng. Các mạng lưới Layer 2 của Ethereum (Arbitrum, Optimism và các mạng khác) cung cấp tính hoàn tất nhanh hơn Ethereum L1, mặc dù chúng hoạt động thông qua các cơ chế khác với cơ chế đồng thuận của Solana.

Cơ chế đồng thuận của Solana so với Ethereum, Avalanche, Cardano và Polkadot

Solana không phải là blockchain hiệu suất cao duy nhất và cơ chế đồng thuận của nó không phải là cách tiếp cận duy nhất để đạt được tính hoàn tất giao dịch nhanh chóng, có khả năng mở rộng. Dưới đây là cách hệ thống PoH + Tower BFT + PoS của Solana so sánh về mặt cấu trúc và các chỉ số hiệu suất so với các lựa chọn thay thế nổi bật nhất.

Ethereum (sau The Merge, tháng 9 năm 2022) hiện sử dụng Gasper, một hệ thống đồng thuận kết hợp LMD-GHOST (một quy tắc lựa chọn Fork nhằm chọn chuỗi có nhiều chứng thực của validator được tích lũy nhất) và Casper FFG (một công cụ hoàn tất định kỳ tạo điểm kiểm soát cho chuỗi). Ethereum đã chuyển từ Proof of Work sang Proof of Stake vào ngày 15 tháng 9 năm 2022. Sự tương phản về kiến trúc với Solana là rất lớn: Gasper của Ethereum đạt được tính bảo mật và phi tập trung thông qua một tập hợp validator khổng lồ (khoảng 900.000 validator trở lên, xác minh từ beaconcha.in tại thời điểm viết bài) với cái giá phải trả là thông lượng. Solana đạt được thông lượng thông qua cơ chế đồng hồ của PoH và hiệu quả của Tower BFT, nhưng với tập hợp validator nhỏ hơn đáng kể.

Avalanche (C-Chain) sử dụng cơ chế đồng thuận Snowman, một biến thể chuỗi tuyến tính của giao thức đồng thuận Avalanche. Snowman mang tính xác suất và dựa trên lấy mẫu thay vì BFT xác định: các validator liên tục lấy mẫu các tập hợp con ngẫu nhiên của các validator khác để đánh giá sự đồng thuận. Các con số thông lượng và tính hoàn tất được công bố thay đổi tùy theo ngày, khối lượng công việc và phương pháp đo lường, vì vậy nên sử dụng các nguồn sơ cấp hiện tại để so sánh. Sự tương phản về kiến trúc là Avalanche sử dụng phương pháp lấy mẫu phụ lặp đi lặp lại, trong khi Solana sử dụng bỏ phiếu theo trọng số cổ phần được xây dựng dựa trên tham chiếu thứ tự PoH.

Cardano sử dụng Ouroboros Praos, phiên bản Mainnet hiện tại của hệ gia đình cơ chế đồng thuận PoS Ouroboros. Ouroboros là giao thức PoS an toàn có thể chứng minh được đầu tiên, được công bố trên các địa điểm học thuật được bình duyệt với các bằng chứng bảo mật toán học chính thức. Thiết kế của Cardano ưu tiên rõ ràng tính đúng đắn chính thức và các bằng chứng bảo mật hơn là thông lượng thô. TPS thực tế trên Mainnet của Cardano là khoảng 250 (xác minh tại thời điểm viết bài). Sự tương phản về triết lý thiết kế với Solana là trực tiếp: Solana ưu tiên thông lượng thông qua các đổi mới kiến trúc; Cardano ưu tiên khả năng chứng minh chính thức các đặc tính bảo mật thông qua sự khắt khe về học thuật.

Polkadot (relay chain) sử dụng BABE (Blind Assignment for Blockchain Extension) để sản xuất khối và GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) cho tính hoàn tất, đạt khoảng 1.000 TPS trên relay chain với tính hoàn tất dao động từ khoảng 12 đến 60 giây. Kiến trúc relay chain cộng với parachain của Polkadot khác biệt cơ bản so với thiết kế chuỗi nguyên khối (monolithic) của Solana, khiến việc so sánh hiệu suất trực tiếp trở nên phức tạp hơn những gì các con số trong bảng gợi ý.

Tất cả các con số là ước tính định hướng. Các chỉ số hiệu suất thay đổi tùy theo điều kiện mạng; mức tối đa lý thuyết đại diện cho công suất trong điều kiện lý tưởng. Xác minh các con số hiện tại từ tài liệu chính thức (docs.solana.com, ethereum.org, Solana Beach, beaconcha.in) trước khi đưa ra bất kỳ quyết định nào. Số lượng validator thay đổi thường xuyên.

Điểm mạnh và Hạn chế của Mô hình Đồng thuận của Solana

Kiến trúc đồng thuận của Solana mang lại những lợi thế có thể đo lường được về tốc độ và thông lượng so với mọi blockchain Layer 1 lớn, nhưng những lợi thế đó đi kèm với những đánh đổi thực sự về tính phi tập trung và hồ sơ độ tin cậy trong lịch sử mà bất kỳ đánh giá nghiêm túc nào cũng phải giải quyết một cách trung thực.

Điểm mạnh:

• Mục tiêu xác nhận độ trễ thấp. Solana có thể cung cấp xác nhận lạc quan nhanh chóng, nhưng mức độ cam kết và tính hoàn tất kinh tế phải được phân biệt rõ ràng.
• Thiết kế thông lượng cao. Các điểm chuẩn trong lịch sử minh họa cho năng lực kiến trúc, trong khi thông lượng trực tiếp phụ thuộc vào khối lượng công việc, tính toán phiếu bầu, các validator, sự tắc nghẽn và các phiên bản phần mềm.
• Phí giao dịch thấp. Công suất thông lượng cao có nghĩa là sự cạnh tranh phí giữa các giao dịch thấp hơn, giữ cho chi phí ở mức chỉ bằng một phần nhỏ của một xu cho hầu hết các hoạt động.
• Chuyển tiếp giao dịch không có Mempool. Giao thức Gulf Stream của Solana loại bỏ vấn đề về phòng chờ, giảm độ trễ xác nhận bằng cách định tuyến trước các giao dịch tới các leader sắp tới đã biết.
• Hiệu quả năng lượng. Proof of Stake không yêu cầu tính toán tiêu tốn nhiều năng lượng, đưa dấu chân năng lượng của Solana vào một danh mục khác biệt cơ bản so với Proof of Work của Bitcoin.

Hạn chế:

• Các sự cố mạng trong lịch sử. Solana đã trải qua nhiều lần ngừng hoạt động mạng hoàn toàn trong khoảng thời gian từ 2021 đến 2023, tạo ra những lo ngại thực sự về độ tin cậy mà bất kỳ nhà đầu tư hoặc nhà phát triển nào cũng phải cân nhắc.
• Số lượng validator ít hơn Ethereum. Tập hợp validator tương đối nhỏ tạo ra một hồ sơ phân cấp khác biệt so với các mạng có hàng trăm nghìn validator.
• Yêu cầu phần cứng cao tạo rào cản tham gia. Chạy một validator Solana đòi hỏi phần cứng cấp máy chủ mà hầu hết các cá nhân không đủ khả năng chi trả hoặc vận hành, hạn chế những người có thể tham gia vào quá trình đồng thuận trực tiếp.
• Phụ thuộc vào một client validator duy nhất (trước Firedancer). Cho đến gần đây, hầu hết các validator Solana đều chạy cùng một client phần mềm, tạo ra một điểm lỗi duy nhất nếu client đó có lỗi.
• Sự tập trung Stake trong nhóm các validator hàng đầu. Một phần đáng kể tổng lượng SOL đã stake tập trung trong một số ít validator, ảnh hưởng đến hệ số Nakamoto.

Tại sao mạng Solana bị sập?

Các sự cố ngừng hoạt động trong lịch sử của Solana không phải do lỗi của thuật toán Proof of History hoặc Tower BFT. Bản thân thiết kế đồng thuận không bị lỗi. Nguyên nhân gốc rễ được ghi nhận của các lần ngừng hoạt động lớn là do cạn kiệt tài nguyên phần mềm và lỗi triển khai: spam giao dịch làm quá tải bộ nhớ của validator, lỗi phần mềm trong client validator gây treo máy và cạn kiệt tài nguyên do các sự kiện có nhu cầu cao bao gồm cả việc chạy đua mint NFT và sự gia tăng đột biến hoạt động DeFi.

Các sự kiện cụ thể minh họa cho quy luật này. Vào tháng 9 năm 2021, Solana đã gặp sự cố ngừng hoạt động kéo dài 17 giờ do bị tràn giao dịch từ sự kiện IDO làm bão hòa bộ nhớ của validator và yêu cầu khởi động lại phối hợp. Vào tháng 1 năm 2022, một sự cố đáng kể thứ hai bắt nguồn từ việc cạn kiệt tài nguyên trong điều kiện thông lượng cao. Nhiều sự cố suy giảm hiệu suất bổ sung đã xảy ra trong suốt năm 2022 (xác minh ngày và thời lượng cụ thể từ các báo cáo hậu kiểm của Solana Foundation tại thời điểm viết bài, vì danh sách sự cố được ghi nhận đã mở rộng). Sự khác biệt giữa các sự kiện này và lỗi thuật toán đồng thuận rất quan trọng để đánh giá tính khả thi lâu dài của Solana: một thuật toán đồng thuận bị lỗi sẽ yêu cầu thiết kế lại giao thức, trong khi việc cạn kiệt tài nguyên phần mềm là một vấn đề kỹ thuật có thể khắc phục được.

Các cải tiến được triển khai kể từ giai đoạn ngừng hoạt động đỉnh cao bao gồm việc áp dụng QUIC làm giao thức mạng (thay thế phương pháp dựa trên UDP dễ bị tấn công spam hơn), một hệ thống chất lượng dịch vụ có trọng số theo stake ưu tiên các giao dịch từ các validator đã stake hơn là spam ẩn danh, và các cải tiến liên tục cho phần mềm client validator. Client Firedancer, một triển khai validator độc lập hiệu suất cao do Jump Crypto phát triển, nhằm mục đích cung cấp sự đa dạng về client, ngăn chặn một lỗi phần mềm duy nhất ảnh hưởng đến toàn bộ mạng. Xác minh trạng thái phát triển Firedancer hiện tại từ các nguồn chính thức tại thời điểm viết bài.

Tần suất và mức độ nghiêm trọng của các sự cố ngừng hoạt động là một mối lo ngại thực sự về độ tin cậy, không phải là sự bất tiện nhỏ. Các mạng xử lý các giao dịch tài chính không thể chấp nhận việc ngừng hoạt động ngoài kế hoạch. Các cải tiến được thực hiện kể từ những giai đoạn ngừng hoạt động tồi tệ nhất là đáng kể, nhưng lịch sử hoạt động là một phần của đánh giá mà bất kỳ ai xây dựng trên Solana hoặc nắm giữ SOL nên thực hiện một cách cởi mở.

Phân cấp và sự tập trung validator: Solana có khoảng 1.500 validator hoạt động trở lên tính đến thời điểm viết bài (xác minh số lượng hiện tại từ phân tích validator của Solana Beach). Ethereum có khoảng 900.000 validator trở lên (xác minh từ beaconcha.in). Sự khác biệt là đáng kể và phản ánh rào cản phần cứng đối với việc xác thực Solana: chạy một validator Solana đòi hỏi ít nhất khoảng 128GB RAM, lưu trữ SSD NVMe hiệu suất cao từ 2TB trở lên và kết nối mạng ít nhất 1Gbps (xác minh thông số kỹ thuật hiện tại từ docs.solana.com/running-validator tại thời điểm viết bài). Ngược lại, validator Ethereum có thể chạy trên phần cứng cấp tiêu dùng cùng với 32 ETH.

Hệ số Nakamoto của Solana (số lượng thực thể tối thiểu cần thông đồng để làm tổn hại đến cơ chế đồng thuận) trong lịch sử dao động trong khoảng từ 19 đến 31 validator, mặc dù con số này thay đổi theo sự thay đổi phân phối stake. Xác minh hệ số hiện tại từ các báo cáo phân cấp của Solana Foundation hoặc Nakaflow tại thời điểm viết bài. 20 validator hàng đầu trong lịch sử đã kiểm soát một phần đáng kể tổng lượng SOL đã stake (xác minh tỷ lệ tập trung hiện tại từ Solana Beach). Solana Foundation vận hành một chương trình ủy quyền được thiết kế đặc biệt để phân phối stake cho các validator nhỏ hơn và cải thiện hệ số này, cung cấp một biện pháp đối phó có cấu trúc với sự tập trung. Ngưỡng bảo mật của Tower BFT có nghĩa là kẻ tấn công sẽ cần kiểm soát hơn một phần ba tổng lượng SOL đã stake để làm ngừng mạng, và hơn hai phần ba để ghi đè cơ chế đồng thuận, một yêu cầu vốn cao có quy mô tương ứng với mức độ tập trung của stake đó trong thực tế.

Cách tham gia: Staking và Xác thực trên Solana

Người nắm giữ SOL có thể tham gia vào cơ chế đồng thuận của Solana theo hai cách: bằng cách vận hành trực tiếp một node validator, hoặc bằng cách ủy quyền SOL cho một validator hiện có. Con đường đầu tiên đòi hỏi đầu tư phần cứng đáng kể và chuyên môn kỹ thuật. Con đường thứ hai dễ tiếp cận với bất kỳ người nắm giữ SOL nào có ví tương thích.

Tuyên bố miễn trừ trách nhiệm: Bài viết này chỉ dành cho mục đích cung cấp thông tin và giáo dục. Nó không cấu thành lời khuyên tài chính, lời khuyên đầu tư, hoặc khuyến nghị mua, bán, hoặc nắm giữ bất kỳ loại tiền điện tử nào. Các khoản đầu tư tiền điện tử mang theo rủi ro đáng kể, bao gồm cả khả năng mất vốn gốc. Luôn thực hiện nghiên cứu của riêng bạn và tham khảo ý kiến của cố vấn tài chính có trình độ trước khi đưa ra quyết định đầu tư.

Yêu cầu để chạy một validator Solana

Vận hành một validator Solana khiến người điều hành trở thành người dẫn đầu các slot được chỉ định và là người bỏ phiếu cho tất cả các slot khác. Yêu cầu phần cứng là đáng kể và đã tăng lên khi mạng lưới phát triển. Luôn xác minh thông số kỹ thuật hiện tại từ tài liệu chính thức về validator của Solana) trước khi cam kết phần cứng:

• CPU: Hiệu năng đơn luồng cao; các đề xuất mẫu cụ thể được cập nhật trong tài liệu chính thức.
• RAM: Tối thiểu 128GB được đề xuất; 256GB trở lên cho hiệu suất tốt nhất.
• Lưu trữ: SSD NVMe hiệu suất cao; khuyến nghị 2TB trở lên.
• Mạng: Kết nối tối thiểu 1Gbps; khuyến nghị 10Gbps cho hiệu suất cạnh tranh.
• Lượng stake SOL: Lượng stake tự ủy quyền hoặc ủy quyền từ cộng đồng đủ để vận hành có lãi về mặt kinh tế. Không có mức stake tối thiểu bắt buộc theo giao thức để chạy validator, nhưng các validator có lượng stake rất nhỏ sẽ nhận được phần thưởng rất nhỏ.

Yêu cầu phần cứng đã tăng lên với mỗi lần nâng cấp mạng lớn. Bất kỳ ai có kế hoạch vận hành một validator nên lập ngân sách cho các nâng cấp phần cứng liên tục và xác nhận tất cả các thông số kỹ thuật từ tài liệu chính thức trước khi mua thiết bị.

Cách Stake SOL: Quyền chọn gốc và Quyền chọn phái sinh (Liquid Options)

Ủy quyền SOL cho một validator hiện có là con đường dễ tiếp cận nhất cho hầu hết người tham gia. Cơ chế hoạt động như sau.

Staking gốc: Sử dụng ví tương thích như Phantom hoặc Solflare, mọi người nắm giữ SOL đều có thể ủy quyền token của mình cho một validator mà họ chọn. Việc ủy quyền này sẽ kiếm được một phần phần thưởng lạm phát của validator đó, tỷ lệ thuận với số tiền được ủy quyền. Lãi suất staking hiện tại APY thay đổi dựa trên các tham số lạm phát của mạng và tổng lượng SOL đã stake (xác minh từ Solana Beach tại thời điểm viết bài trước khi đưa ra bất kỳ quyết định staking nào). Có một thời gian chờ rút ủy quyền khoảng hai epoch, tương đương khoảng bốn đến năm ngày, trước khi SOL được ủy quyền trở lại trạng thái có thể giao dịch (verify from docs.solana.com at time of writing).

Staking thanh khoản: Các giao thức bao gồm Marinade Finance (phát hành token mSOL) và Jito (phát hành token jitoSOL) cho phép người dùng staking SOL mà vẫn duy trì thanh khoản. Thay vì khóa trực tiếp SOL với trình xác thực và chờ hết thời gian chờ để truy cập, người dùng staking thanh khoản nhận được token thanh khoản đại diện cho SOL đã stake cùng phần thưởng tích lũy, có thể giao dịch bất kỳ lúc nào. Các token staking thanh khoản này là một phần của các giao thức DeFi hoạt động trên Solana và mang rủi ro hợp đồng thông minh riêng ngoài kinh tế staking cơ bản.

Khi chọn trình xác thực để ủy quyền, các tiêu chí liên quan bao gồm lịch sử thời gian hoạt động của trình xác thực, tỷ lệ hoa hồng (phần trăm phần thưởng mà trình xác thực giữ lại trước khi chuyển phần còn lại cho người ủy quyền) và mức độ tập trung của stake. Ủy quyền cho các trình xác thực nhỏ hơn giúp cải thiện sự phi tập trung của mạng lưới và có thể đủ điều kiện nhận các lợi ích từ chương trình ủy quyền của Quỹ Solana.

Câu hỏi thường gặp về Cơ chế đồng thuận của Solana

Solana sử dụng cơ chế đồng thuận nào?

Solana sử dụng một hệ thống đồng thuận lai kết hợp ba thành phần: Proof of History (PoH), Tower BFT và Proof of Stake (PoS). PoH hoạt động như một đồng hồ mật mã thiết lập thứ tự giao dịch. Tower BFT là thuật toán đồng thuận mà các trình xác thực sử dụng để xác nhận các khối. PoS xác định trình xác thực nào tham gia và cân trọng phiếu bầu của họ theo SOL đã stake.

Solana có phải là blockchain Proof of Stake không?

Solana có sử dụng Proof of Stake làm lớp bảo mật kinh tế của mình, vì vậy gọi nó là blockchain PoS về mặt kỹ thuật là chính xác. Tuy nhiên, điều đó là chưa đầy đủ. Bản thân Proof of Stake không giải thích được cách Solana đạt được sự đồng thuận. Cơ chế đầy đủ yêu cầu Proof of History (đồng hồ mật mã thiết lập thứ tự mà không cần giao tiếp giữa các trình xác thực) và Tower BFT (thuật toán bỏ phiếu đạt được tính cuối cùng). Mô tả chính xác: Solana sử dụng hệ thống đồng thuận lai PoH + Tower BFT + PoS.

Solana nhanh như thế nào so với Ethereum?

Các phép đo hiệu suất lịch sử báo cáo thông lượng khác biệt đáng kể giữa Solana và Ethereum L1, nhưng định nghĩa giao dịch, lưu lượng truy cập bỏ phiếu, thực thi L2, tính khả dụng của dữ liệu và các mô hình quyết toán khác nhau. Sử dụng các phép đo hiện tại, tương đương và phân biệt xác nhận lạc quan với quyết toán cuối cùng hoặc không thể đảo ngược về mặt kinh tế.

Tại sao mạng Solana bị sập?

Các sự cố mạng lịch sử của Solana là do cạn kiệt tài nguyên phần mềm và lỗi triển khai, chứ không phải do lỗi trong các thuật toán đồng thuận Proof of History hoặc Tower BFT. Các nguyên nhân được ghi nhận bao gồm tin nhắn rác làm quá tải dung lượng bộ nhớ của trình xác thực, lỗi phần mềm trong client trình xác thực và cạn kiệt tài nguyên trong các sự kiện nhu cầu cao như đợt mint NFT và các đợt tăng đột biến hoạt động DeFi. Sự cố sập mạng vào tháng 9 năm 2021 kéo dài khoảng 17 giờ và gây ra bởi tình trạng quá tải từ sự kiện IDO. Các cải tiến kể từ đỉnh điểm sự cố năm 2021 đến 2022 bao gồm mạng QUIC, ưu tiên giao dịch theo stake và các cải tiến client trình xác thực liên tục. Xác minh trạng thái độ tin cậy mạng hiện tại từ blog của Quỹ Solana tại thời điểm viết bài.

Proof of History là gì?

Proof of History (PoH) là một cơ chế ghi nhận thời gian mật mã do Anatoly Yakovenko phát minh và giới thiệu trong whitepaper năm 2017 có tựa đề "Solana: Một kiến trúc mới cho blockchain hiệu năng cao". PoH tạo ra một bản ghi liên tục, có thể xác minh về thời điểm các sự kiện xảy ra bằng cách nối chuỗi các đầu ra hàm băm SHA-256 theo trình tự. Nó không phải là một cơ chế đồng thuận. Nó là một đồng hồ mật mã cho phép thuật toán đồng thuận thực tế của Solana, Tower BFT, hoạt động với ít vòng giao tiếp hơn nhiều. Để biết chi tiết đầy đủ, hãy xem phần Proof of History ở trên.

Ai đã phát minh ra cơ chế đồng thuận của Solana?

Anatoly Yakovenko, cựu kỹ sư của Qualcomm, đã giới thiệu Proof of History trong whitepaper nền tảng của Solana vào năm 2017. Yakovenko đồng sáng lập Solana Labs với Greg Fitzgerald và Raj Gokal, những người đã đóng góp vào việc triển khai rộng rãi hơn của giao thức. PoH cung cấp một tham chiếu sắp xếp có thể xác minh, có thể giảm bớt một số chi phí điều phối thời gian, nhưng nó không loại bỏ giao tiếp đồng thuận.

Solana có bao nhiêu trình xác thực?

Solana có khoảng 1.500 hoặc nhiều hơn các trình xác thực hoạt động tính đến thời điểm viết bài; hãy xác minh số liệu hiện tại từ phân tích trình xác thực Solana Beach để có dữ liệu mới nhất. So với Ethereum có khoảng 900.000 hoặc nhiều hơn các trình xác thực (xác minh từ beaconcha.in). Sự khác biệt về số lượng trình xác thực phản ánh sự khác biệt về yêu cầu phần cứng: trình xác thực Solana yêu cầu thiết bị cấp máy chủ với RAM 128GB trở lên, trong khi trình xác thực Ethereum có thể chạy trên phần cứng cấp tiêu dùng cùng với 32 ETH.

Tower BFT là gì?

Tower BFT là thuật toán đồng thuận của Solana, được xây dựng như một sự điều chỉnh PBFT sử dụng Proof of History làm đồng hồ chung. Các trình xác thực bỏ phiếu cho các khối dựa trên stake; một khối đạt được tính cuối cùng khi các trình xác thực đại diện cho hơn hai phần ba tổng số SOL đã stake xác nhận nó. Ngưỡng đa số 2/3+ này có nghĩa là mạng lưới chịu được tới một phần ba người tham gia dựa trên stake hoạt động độc hại mà không làm mất tính toàn vẹn của đồng thuận.

Solana có sử dụng delegated Proof of Stake không?

Việc staking của Solana về mặt kỹ thuật tương tự như Delegated Proof of Stake (DPoS) ở chỗ những người nắm giữ SOL có thể ủy quyền cho các trình xác thực mà không cần chạy node của riêng họ. Tuy nhiên, nó khác với các hệ thống DPoS truyền thống ở một điểm quan trọng: không có tập hợp trình xác thực được bầu chọn cố định. Bất kỳ trình xác thực nào cũng có thể thu hút sự ủy quyền từ thị trường mở. Chính xác hơn, Solana sử dụng hệ thống PoS dựa trên stake có ủy quyền mở, hoạt động như lớp bảo mật kinh tế trên nền PoH và Tower BFT, thay vì kiến trúc DPoS truyền thống với nhóm ủy quyền cố định.

Solana có tốt hơn Ethereum không?

Không mạng nào tốt hơn một cách khách quan. Mỗi mạng đưa ra các đánh đổi kiến trúc khác nhau phù hợp với các trường hợp sử dụng khác nhau. Các phép đo lịch sử thường cho thấy thông lượng lớp cơ sở cao hơn và phí thấp hơn trên Solana, trong khi thời gian xác nhận phụ thuộc vào mức độ cam kết và điều kiện mạng. Ethereum có cộng đồng nhà phát triển lớn hơn và hệ sinh thái Layer 2 rộng lớn. Số lượng trình xác thực đơn thuần không đo lường mức độ phi tập trung; sự phân bổ stake, sự đa dạng của client, sự tập trung của nhà điều hành và yêu cầu phần cứng cũng quan trọng. Lựa chọn phù hợp phụ thuộc vào ứng dụng và mô hình rủi ro.

Khám phá SOL trên Bybit

Người đọc có thể xem thông tin thị trường SOL hiện tại) hoặc so sánh các sản phẩm SOL Sinh lời có sẵn.). Bybit Sinh lời là một sản phẩm tập trung và không nên được mô tả là staking trình xác thực gốc của Solana; các điều khoản, quyền giám hộ, tính khả dụng và rủi ro khác nhau.

• Cơ chế đồng thuận của Solana là một hệ thống lai: Proof of History (đồng hồ mật mã) + Tower BFT (thuật toán đồng thuận) + Proof of Stake (lớp bảo mật kinh tế). Không có thành phần đơn lẻ nào tự nó cấu thành cơ chế.

• Proof of History không phải là một cơ chế đồng thuận. Nó là một công cụ ghi nhận thời gian mật mã thiết lập thứ tự giao dịch trước khi các trình xác thực giao tiếp, cho phép Tower BFT đạt được sự đồng thuận với số vòng bỏ phiếu ít hơn nhiều so với các triển khai BFT tiêu chuẩn.

• Các sự cố mạng của Solana là do cạn kiệt tài nguyên phần mềm, chứ không phải do lỗi trong PoH hoặc Tower BFT. Thiết kế đồng thuận không bị hỏng. Các cải tiến bao gồm mạng QUIC, ưu tiên phí theo stake và client Firedancer nhằm giảm thiểu rủi ro dừng hoạt động trong tương lai.

• Đồng thuận của Solana nhanh hơn Ethereum Layer 1 và Bitcoin, đạt được tính cuối cùng trong chưa đầy 1,3 giây so với 12 đến 15 phút đối với Ethereum L1 và khoảng 60 phút đối với Bitcoin, nhưng tốc độ này đi kèm với những đánh đổi: ít trình xác thực hơn, yêu cầu phần cứng cao hơn và các lo ngại về sự tập trung của stake.

• Bất kỳ người nắm giữ SOL nào cũng có thể tham gia vào cơ chế đồng thuận của Solana bằng cách ủy quyền SOL cho một validator thông qua native staking hoặc các giao thức liquid staking. Việc trực tiếp vận hành một validator đòi hỏi sự đầu tư đáng kể về phần cứng và chuyên môn kỹ thuật.

• Các số liệu hiệu suất và số lượng validator thay đổi theo các đợt nâng cấp mạng. Mọi đánh giá về tính phi tập trung, thông lượng hoặc lợi suất staking của Solana nên sử dụng dữ liệu hiện tại từ Solana Beach, Solscan và tài liệu Solana chính thức tại thời điểm đưa ra quyết định.

Để tham gia vào Cơ chế đồng thuận của Solana, hãy xem các phần staking và xác thực ở trên hoặc truy cập tài liệu chính thức của Solana tại docs.solana.com.

Đọc thêm:

• Solana: Một kiến trúc mới cho một blockchain hiệu suất cao: Whitepaper tháng 11 năm 2017 của Anatoly Yakovenko
• Tài liệu chính thức của Solana: thông số kỹ thuật giao thức, yêu cầu phần cứng, hướng dẫn staking
• Phân tích validator trên Solana Beach: số lượng validator hiện tại, phân bổ stake và số liệu thống kê mạng lưới

Bài viết liên quan

• Solana Proof of History
• Kiến trúc Solana
• Tốc độ Solana