Trừng phạt Validator Solana (Slashing): SOL có áp dụng không?

Tính năng trừng phạt validator (slashing) của Solana không hoạt động ở cấp độ giao thức theo lần đánh giá cuối cùng của nguồn vào tháng 6/2025. Bài viết này lưu giữ phát hiện có ghi ngày tháng đó và xác định những gì người đọc phải xác minh trước khi dựa vào thông tin này.

Nội dung này chỉ mang tính chất thông tin và không cấu thành lời khuyên tài chính. Staking tiền điện tử có rủi ro, bao gồm khả năng mất tài sản đã stake. Hãy 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ư.

Cập nhật lần cuối: Tháng 6 năm 2025

Nếu bạn đang staking SOL và gần đây gặp cụm từ "trừng phạt validator Solana", thì đây là câu trả lời trực tiếp: tính đến tháng 6 năm 2025, Solana không thực hiện trừng phạt validator ở cấp độ giao thức. SOL được ủy quyền của bạn không thể bị giao thức tự động cắt giảm vì hành vi của validator. Bài viết này trình bày ý nghĩa của slashing, tình trạng hiện tại của Solana, cách Tower BFT xử lý hành vi sai trái thay thế, những rủi ro thực tế tồn tại đối với người ủy quyền hiện nay, vị trí của Marinade Finance và Jito, và cách Solana so sánh với Ethereum, Cosmos và Polkadot.

Nội dung chính

• Tính đến tháng 6 năm 2025, Solana không thực hiện trừng phạt validator (slashing) ở cấp độ giao thức
• SOL được ủy quyền của bạn không thể bị giao thức tự động cắt giảm do hành vi sai trái của validator ở thời điểm hiện tại
• Solana sử dụng cơ chế khóa Tower BFT để ngăn chặn hành vi sai trái của validator thay vì phạt trực tiếp bằng token
• Các đề xuất quản trị được gọi là Tài liệu Cải tiến Solana (SIMD) để giới thiệu slashing đã tồn tại nhưng chưa được triển khai
• Các giao thức staking thanh khoản như Marinade Finance và Jito phân bổ lượt stake cho nhiều validator, giúp giảm thiểu rủi ro khi chỉ tiếp xúc với một validator duy nhất

Nội dung

• Trừng phạt Validator (Validator Slashing) là gì?
• Trừng phạt Validator Solana: Hiện tại Solana có áp dụng không?
• Cách Solana xử lý hành vi sai trái của Validator: Cơ chế Tower BFT và Lockout
• Ý nghĩa của tình trạng Slashing trên Solana đối với Staker và người ủy quyền
• Staking thanh khoản và rủi ro Slashing: Marinade Finance và Jito
• Solana so với Ethereum, Cosmos và Polkadot: So sánh Slashing như thế nào
• Quy tắc thực hành tốt nhất cho Validator: Cách tránh các điều kiện Slashing trên Solana
• Quản trị Slashing trên Solana: Các đề xuất SIMD và ý nghĩa của chúng
• Câu hỏi thường gặp về Trừng phạt Validator Solana
• Kết luận: Staking Solana có an toàn trước Slashing hiện nay không?
• Thuật ngữ

Trừng phạt Validator (Validator Slashing) là gì?

Định nghĩa: Trừng phạt validator (slashing) là một cơ chế xử phạt ở cấp độ giao thức trong các Blockchain Proof of Stake (PoS), tự động giảm số lượng token đang stake của validator như một hình phạt cho hành vi sai trái có thể chứng minh được. Nó được thiết kế để khiến hành vi không trung thực trở nên phi lý về mặt tài chính bằng cách đảm bảo các validator mất nhiều hơn những gì họ có thể thu được từ việc thao túng mạng lưới.

Trên một Blockchain như Solana, các validator là những nút chịu trách nhiệm xử lý các giao dịch và đạt được sự đồng thuận về trạng thái của mạng lưới. Trừng phạt validator về cơ bản là một cơ chế bảo mật mạng lưới: bằng cách khiến hành vi không trung thực gây tốn kém về tài chính, nó ngăn cản các validator cố gắng thao túng Blockchain. Trong các hệ thống Proof of Stake (PoS), các validator nạp token như một khoản tiền ký quỹ để tham gia. Không giống như Bitcoin sử dụng Proof of Work, nơi các thợ đào cạnh tranh để giải các câu đố toán học, các hệ thống đồng thuận dựa trên stake quy trách nhiệm tài chính cho các validator thông qua số vốn bị khóa của họ. Slashing là những gì xảy ra khi họ phá vỡ các quy tắc. Để biết thêm bối cảnh mạng lưới rộng hơn, hãy xem validator Solana là gì.

Hai điều kiện kích hoạt slashing trong hầu hết các mạng PoS. Sự không nhất quán (thường được gọi là bỏ phiếu kép) xảy ra khi một validator ký hai phiếu bầu hoặc khối mâu thuẫn cho cùng một vị trí, cố gắng hỗ trợ hai phiên bản khác nhau của Blockchain cùng một lúc. Bỏ phiếu bao quanh là điều kiện thứ hai: một validator ký các xác nhận trái ngược với những xác nhận đã ký trước đó. Cả hai hành vi này đều làm suy yếu tính xác thực của sự đồng thuận và ở quy mô lớn, có thể cho phép các cuộc tấn công chi tiêu gấp đôi.

Logic kinh tế đằng sau Slashing

Slashing tồn tại vì các validator gửi các token đã stake làm tài sản thế chấp. Một validator có nguy cơ mất nhiều hơn do hành vi sai trái so với những gì họ có thể nhận được khi gian lận sẽ không có động lực hợp lý để gian lận. Khả năng chịu lỗi Byzantine (BFT) là khung khoa học máy tính lý thuyết làm nền tảng cho các hệ thống đồng thuận phân tán, được đặt theo tên của Bài toán các vị tướng Byzantine, một thí nghiệm tư duy về việc phối hợp các tác nhân có thể là những kẻ phản bội. Tower BFT là triển khai cụ thể của Solana cho sự đồng thuận loại BFT. Slashing thực thi các thuộc tính BFT bằng cách chuyển đổi sự không nhất quán từ một rủi ro lý thuyết thành một hành động phi lý về mặt tài chính. Trên các mạng như Ethereum, những người ủy quyền cho mượn stake của họ cho các validator cũng chia sẻ tỷ lệ phạt slashing, điều này đặt ra câu hỏi liệu những người ủy quyền SOL có phải đối mặt với rủi ro tương tự trên Solana hay không.

Trừng phạt Validator Solana: Hiện tại Solana có áp dụng không?

Cập nhật lần cuối: Tháng 6 năm 2025

Tính đến tháng 6 năm 2025, Solana không triển khai hình phạt validator (slashing) ở cấp độ giao thức. Solana hiện không có cơ chế nào tự động đốt hoặc giảm lượng SOL đã stake của validator như một hình phạt cho hành vi sai trái. Các validator không thể bị phạt ở cấp độ giao thức theo mã nguồn trực tiếp của Solana.

Đây là một đặc điểm thiết kế có chủ đích, không phải là một sự thiếu sót. Kiến trúc của Solana cung cấp khả năng răn đe thông qua cơ chế khóa (lockout) của Tower BFT và cộng đồng nhà phát triển đã tích cực tranh luận liệu việc thêm các hình phạt tài chính (slashing) có xứng đáng với sự phức tạp vận hành mà nó tạo ra trong môi trường có thông lượng cao hay không. Cuộc tranh luận đó hiện đã có một lộ trình chính thức: Các Tài liệu Cải tiến Solana (SIMD) đã đề xuất giới thiệu slashing, nhưng chưa có đề xuất nào được thực hiện. Để theo dõi toàn bộ quản trị, hãy xem phần quản trị SIMD bên dưới.

Ba loại hậu quả đối với validator tồn tại trên Solana:

1. Trừng phạt cấp giao thức (không tồn tại trên Solana tính đến tháng 6 năm 2025): tự động giảm số lượng token đã stake
2. Hình phạt xã hội và kinh tế (hiện có): các validator có hành vi sai trái sẽ mất quyền ủy quyền khi những người ủy quyền rút stake của họ
3. Trừng phạt do quản trị đề xuất (được đề xuất qua SIMD, chưa được triển khai): những gì sẽ tồn tại nếu một SIMD liên quan được chấp nhận

Tại sao Solana chưa triển khai Slashing

Kiến trúc của Solana cung cấp khả năng răn đe chống lại sự không nhất quán thông qua cơ chế khóa của Tower BFT, nhưng việc triển khai các hình phạt tài chính trong môi trường có thông lượng cao sẽ gây ra các rủi ro vận hành mà cộng đồng đã tích cực cân nhắc. Các validator trong các hệ thống hiệu suất cao phải đối mặt với rủi ro cao hơn đối với các điều kiện slashing sai lệch (dương tính giả) từ độ trễ mạng, khởi động lại phần mềm hoặc lỗi cơ sở hạ tầng. Cuộc thảo luận quản trị đã xem xét liệu các rủi ro vận hành này có vượt quá lợi ích bảo mật của slashing hay không, và tính đến tháng 6 năm 2025, câu hỏi này vẫn chưa được giải quyết thông qua các kênh quản trị chính thức.

Solana Xử Lý Hành Vi Sai Trái Của Người Xác Thực Như Thế Nào: Tower BFT Và Cơ Chế Khóa

Cách tiếp cận của Solana đối với hành vi sai trái của người xác thực thông qua Tower BFT, và việc hiểu cơ chế đó giải thích cả lý do tại sao sự khai báo đôi lại khó khăn về mặt cấu trúc trên mạng này và tại sao hiện tại không có hình phạt tài chính nào đi kèm với việc phát hiện.

Proof of History (PoH) là một cơ chế ghi nhận thời gian mật mã được tạo ra bởi đồng sáng lập Solana Anatoly Yakovenko. Nó hoạt động như một chiếc đồng hồ có thể xác minh cho mạng, chứ không phải là một cơ chế đồng thuận. PoH tạo ra một bản ghi lịch sử chứng minh rằng một chuỗi sự kiện cụ thể đã xảy ra vào một thời điểm cụ thể, cho phép những người xác thực đồng ý về thứ tự mà không cần liên lạc qua lại liên tục. Tower BFT, cơ chế đồng thuận, được xây dựng trên nền tảng của chiếc đồng hồ này. Solana sử dụng kiến trúc lai kết hợp Bằng chứng Lịch sử (Proof of History) làm lớp ghi nhận thời gian với Tower BFT làm lớp đồng thuận, thay vì Bằng chứng Stake tiêu chuẩn.

Tower BFT là giao thức đồng thuận của Solana, hệ thống mà những người xác thực sử dụng để đồng ý về trạng thái của blockchain. Được xây dựng trên nền tảng Bằng chứng Lịch sử, nó sử dụng các cửa sổ khóa tăng theo cấp số nhân để khiến việc bỏ phiếu cho nhiều phiên bản blockchain cạnh tranh trở nên phi lý về mặt kinh tế. Cửa sổ khóa là cơ chế của Tower BFT ngăn người xác thực bỏ phiếu trên các nhánh cạnh tranh sau khi đã cam kết với một nhánh.

Cơ chế khóa hoạt động như sau:

1. Người xác thực bỏ phiếu cho nhánh A của blockchain
2. Phiếu bầu đó mang theo một cửa sổ khóa, ban đầu là 2 slot, trong thời gian đó người xác thực không thể bỏ phiếu cho một nhánh cạnh tranh
3. Mỗi phiếu bầu tiếp theo cho cùng một nhánh sẽ nhân đôi thời gian khóa: 4 slot, sau đó là 8, rồi 16, tiếp tục theo cấp số nhân
4. Từ bỏ nhánh A để bỏ phiếu cho nhánh B trước khi hết hạn khóa là vi phạm khóa

Tháp phiếu bầu của người xác thực trên một nhánh càng sâu thì càng phải đợi lâu hơn trước khi chuyển sang nhánh khác. Cơ chế cam kết này làm cho việc đảo ngược phiếu bầu trước đó ngày càng tốn kém về thời gian, không chỉ danh tiếng.

Người xác thực kiếm được tín chỉ bỏ phiếu cho các phiếu bầu kịp thời, chính xác. Bỏ lỡ phiếu bầu làm giảm tín chỉ và do đó giảm phần thưởng Staking tương ứng. Hệ thống tín chỉ bỏ phiếu này là cơ chế phạt mềm trực tiếp của Solana, ảnh hưởng đến phần thưởng mà không chạm vào vốn Staking.

Cơ chế khóa Tower BFT: mỗi phiếu bầu của người xác thực trên một nhánh mang theo một cửa sổ khóa tăng theo cấp số nhân. Vi phạm khóa cấu thành sự khai báo đôi.

Khai báo đôi (thường được gọi là bỏ phiếu hai lần) xảy ra khi một người xác thực ký hai phiếu bầu hoặc khối xung đột cho cùng một slot, cố gắng ủng hộ hai phiên bản blockchain khác nhau cùng một lúc. Vi phạm khóa đặc biệt đề cập đến việc người xác thực bỏ phiếu trên một nhánh cạnh tranh trước khi hết hạn cửa sổ khóa Tower BFT.

Chuỗi phát hiện-hậu quả theo giao thức hiện tại:

1. Người xác thực bỏ phiếu trên nhánh A, xây dựng một cửa sổ khóa tăng theo cấp số nhân
2. Người xác thực ký một phiếu bầu trên nhánh B trước khi hết hạn khóa
3. Dấu thời gian PoH làm cho cả hai phiếu bầu đều có thể chứng minh bằng mật mã
4. Giao thức phát hiện các chữ ký xung đột là khai báo đôi
5. Người xác thực mất tín chỉ bỏ phiếu cho khoảng thời gian bị ảnh hưởng; SOL đã Staking không bị giảm

Đây là khoảng trống kiến trúc mà các đề xuất slashing của SIMD tìm cách khắc phục. Theo các triển khai slashing được đề xuất, bước 5 sẽ bổ sung việc đốt token tự động từ cả vốn Staking của người xác thực và một phần tương ứng từ vốn được ủy quyền.

Tài khoản Staking là một bản ghi Trên chuỗi dành riêng cho Solana, nơi lưu trữ SOL đã Staking của người ủy quyền và theo dõi việc ủy quyền của họ cho một người xác thực cụ thể. Theo triển khai slashing, tài khoản Staking sẽ bị trừ trực tiếp nếu người xác thực bị phạt.

Tình Trạng Slashing Của Solana Có Ý Nghĩa Gì Đối Với Người Staking Và Người Ủy Quyền

Tính đến tháng 6 năm 2025, SOL đã Staking của bạn không có nguy cơ bị giảm thông qua slashing. Solana không triển khai cơ chế này. Đối với các nhà phân bổ tổ chức, slashing hiện tại không gây ra rủi ro tài chính đáng kể nào cho các vị thế Staking SOL. Số dư gốc của bạn không thể bị đốt tự động bởi giao thức do hành vi của người xác thực. Bức tranh đó sẽ thay đổi nếu các đề xuất slashing của SIMD được chấp nhận: theo các bản nháp hiện tại, người ủy quyền sẽ đối mặt với rủi ro gốc tương ứng cùng với người xác thực.

Hiệu suất của người xác thực ảnh hưởng đến phần thưởng Staking của bạn. Người xác thực hoạt động kém hoặc chậm trễ (người bỏ lỡ phiếu bầu do ngừng hoạt động) kiếm được ít tín chỉ bỏ phiếu hơn, điều này làm giảm khoảng 5–8% APY mà tài sản Staking của bạn kiếm được. Sự khác biệt giữa rủi ro phần thưởng và rủi ro gốc là chìa khóa để đánh giá chính xác Staking Solana. Người ủy quyền có thể áp dụng danh sách kiểm tra trong cách chọn người xác thực Solana.

Người Ủy Quyền so với Người Xác Thực: Ai Chịu Rủi Ro?

Hầu hết những người nắm giữ SOL thực hiện Staking về mặt kỹ thuật là người ủy quyền. Hồ sơ rủi ro khác nhau tùy theo vai trò. Người xác thực đối mặt với các hình phạt giao thức trực tiếp theo bất kỳ khuôn khổ slashing nào; người ủy quyền đối mặt với rủi ro phát sinh tương ứng với tỷ lệ Staking của họ. Trên các mạng có slashing trực tiếp, cả hai loại đều chịu rủi ro tài chính. Trên Solana hôm nay, không ai trong số họ ở cấp độ giao thức.

Người xác thực là thực thể chạy nút và đưa ra các phiếu bầu đồng thuận. Theo bất kỳ triển khai slashing nào, người xác thực sẽ là thực thể bị phạt chính. Người ủy quyền cho vay SOL của họ vào nhóm của người xác thực đó và kiếm phần thưởng tương ứng với tỷ lệ Staking của họ. Theo hầu hết các triển khai slashing được đề xuất, người ủy quyền sẽ bị ảnh hưởng tương ứng cùng với vốn Staking của người xác thực. Nếu người xác thực bị slashing 5% tổng nhóm Staking của họ, và bạn có 100 SOL được ủy quyền, bạn có thể mất khoảng 5 SOL.

Theo các triển khai slashing được đề xuất của Solana, người ủy quyền sẽ bị ảnh hưởng tương ứng. Nếu người xác thực bị slashing một tỷ lệ phần trăm tổng nhóm Staking của họ, người ủy quyền sẽ mất cùng một tỷ lệ phần trăm SOL được ủy quyền của họ.

Các rủi ro tài chính thực tế tồn tại đối với người ủy quyền ngày nay, ngay cả khi không có slashing. Chúng ảnh hưởng đến phần thưởng Staking thay vì số dư gốc của bạn:

1. Sự chậm trễ của người xác thực: người xác thực bỏ lỡ phiếu bầu sẽ kiếm được ít tín chỉ bỏ phiếu hơn, làm giảm OTK_9 của bạn cho kỷ nguyên bị ảnh hưởng (một kỷ nguyên kéo dài khoảng 2–3 ngày trong giao thức Solana)
2. Thời gian hủy Staking: SOL đã Staking không thể rút ngay lập tức; thời gian hủy Staking của Solana kéo dài khoảng 2–3 ngày, trong thời gian đó token của bạn vẫn bị khóa trong tài khoản Staking của bạn
3. Tỷ lệ hoa hồng: hoa hồng của người xác thực là tỷ lệ phần trăm phần thưởng Staking mà người xác thực giữ lại trước khi chuyển phần còn lại cho người ủy quyền; hoa hồng 10% có nghĩa là 10% phần thưởng kiếm được, không phải 10% vốn gốc
4. Rủi ro chương trình Solana: Staking được điều chỉnh bởi một chương trình Trên chuỗi (tương đương với một hợp đồng thông minh trên các mạng khác); lỗi giao thức, mặc dù hiếm trong lịch sử, nhưng đại diện cho một rủi ro lý thuyết đối với tài sản đã Staking (các sàn giao dịch cung cấp sản phẩm Staking SOL cũng đối mặt với các xem xét rủi ro slashing trong việc lựa chọn người xác thực và thiết kế lưu ký của họ)

Để so sánh hồ sơ rủi ro của Solana với Ethereum và Cosmos, hãy xem Solana so sánh với các mạng PoS như thế nào.

Cách Đánh giá và Chọn Người Xác thực Solana An Toàn

Khi đánh giá một người xác thực Solana, sáu tiêu chí sẽ cho thấy rõ nhất về độ tin cậy và rủi ro:

1. Kiểm tra tỷ lệ hoạt động và chậm trễ: nhắm mục tiêu những người xác thực có tỷ lệ hoạt động trên 95% bằng cách sử dụng Stakewiz, Solana Beach hoặc Validators.app
2. Xem xét tín dụng bỏ phiếu mỗi kỷ nguyên: tín dụng bỏ phiếu cao và nhất quán báo hiệu sự tham gia đáng tin cậy vào quá trình đồng thuận
3. So sánh tỷ lệ hoa hồng: 0–10% là phạm vi tiêu chuẩn; hãy tính đến điều này cùng với các chỉ số hiệu suất, không độc lập
4. Kiểm tra mức độ tập trung của stake: tránh ủy quyền cho những người xác thực nắm giữ hơn 10% tổng stake mạng, vì điều này làm tăng rủi ro tập trung mạng
5. Xem lại lịch sử của người xác thực: tìm kiếm một lịch sử rõ ràng mà không có các giai đoạn chậm trễ kéo dài
6. Xem xét staking thanh khoản thông qua Marinade Finance hoặc Jito để đa dạng hóa tự động trên nhiều người xác thực đồng thời

Staking Thanh khoản và Rủi ro Hình phạt: Marinade Finance và Jito Xử lý như thế nào

Các giao thức staking thanh khoản gộp SOL được ủy quyền trên nhiều người xác thực và phát hành một token staking thanh khoản có thể giao dịch (LST) đại diện cho stake cơ bản của bạn. Marinade Finance phát hành mSOL; Jito phát hành jitoSOL. Thay vì khóa SOL của bạn với một người xác thực duy nhất, các giao thức này tự động phân bổ stake của bạn trên các nhóm người xác thực của họ.

Cách Đa dạng hóa Staking Thanh khoản Giảm Tiếp xúc với Người xác thực Duy nhất

Marinade Finance và Jito phân phối stake trên các nhóm người xác thực lớn. Hành vi sai trái của một người xác thực chỉ ảnh hưởng đến một phần nhỏ của tổng stake được gộp thay vì toàn bộ vị thế của bạn. Nếu một người xác thực trong nhóm 100 người bị phạt 5% stake của riêng họ, thì chỉ 1/100 phần tiếp xúc của nhóm sẽ bị ảnh hưởng tại người xác thực đó. Việc đa dạng hóa cấu trúc này làm giảm rủi ro tập trung so với việc ủy quyền mọi thứ cho một người xác thực duy nhất.

Tính đến tháng 6 năm 2025, với việc Solana chưa áp dụng hình phạt slashing, việc đa dạng hóa này chủ yếu hoạt động như một cơ chế bảo vệ trong tương lai. Cả Marinade Finance và Jito đều sử dụng các tiêu chí lựa chọn và giám sát người xác thực để tránh những người xác thực chậm trễ hoặc hoạt động kém hiệu quả, điều này bảo vệ phần thưởng staking của bạn ngay hôm nay bất kể trạng thái hình phạt.

Marinade Finance và Jito có cách tiếp cận rủi ro hình phạt khác nhau dựa trên phương pháp lựa chọn người xác thực và thành phần nhóm của họ.

Marinade Finance sử dụng chiến lược ủy quyền stake tự động chấm điểm người xác thực dựa trên các chỉ số hiệu suất bao gồm tỷ lệ tín dụng bỏ phiếu, hoa hồng và mức độ tập trung stake. Theo tài liệu của Marinade Finance, giao thức phân phối stake trên một bộ người xác thực lớn và áp dụng các tiêu chí chấm điểm để giảm thiểu tiếp xúc với những người xác thực hoạt động kém. Người nắm giữ mSOL sẽ bị ảnh hưởng theo tỷ lệ nếu bất kỳ người xác thực nào trong nhóm gặp hình phạt, nhưng tác động trên mỗi người nắm giữ sẽ chỉ là một phần nhỏ so với những gì người ủy quyền cho một người xác thực duy nhất phải đối mặt.

Nhóm người xác thực của Jito tập trung vào cơ sở hạ tầng MEV (giá trị có thể trích xuất tối đa), với các người xác thực chạy bộ phần mềm của Jito. Theo tài liệu staking của Jito, người nắm giữ jitoSOL hưởng lợi từ việc đa dạng hóa nhóm. Thành phần người xác thực tập trung vào MEV của Jito có những đặc điểm độc đáo: bộ người xác thực có thể khác biệt so với các nhóm người xác thực Solana nói chung về thành phần và hồ sơ hoạt động của họ.

Staking trực tiếp và staking thanh khoản đại diện cho các hồ sơ rủi ro khác nhau, không phải là một thứ bậc rõ ràng về sự an toàn. Cả Marinade và Jito đều không loại bỏ hoàn toàn rủi ro hình phạt trong tương lai, và cả hai đều mang lại rủi ro chương trình Solana mà staking trực tiếp không có. Lỗi giao thức hoặc lỗ hổng quản trị sẽ đại diện cho một loại rủi ro riêng biệt. Những người đọc ưa thích sản phẩm kiếm tiền có người giám sát cũng có thể xem xét Bybit Sinh lời,) nơi có sẵn; hãy so sánh các điều khoản hiện tại, điều kiện rút tiền và rủi ro lưu ký trước khi đưa ra quyết định.

Solana so với Ethereum, Cosmos và Polkadot: Hình phạt Slashing So sánh trên các Mạng PoS Như thế nào

Ba trong số năm mạng PoS lớn được so sánh dưới đây có hình phạt slashing đang hoạt động. Solana và Cardano thì không, tính đến tháng 6 năm 2025. Sự khác biệt cấu trúc đơn lẻ này giải thích cho sự khác biệt chính về rủi ro vốn gốc đối với người ủy quyền trên các mạng này.

Beacon Chain của Ethereum: Hình phạt Slashing hoạt động từ The Merge (2022)

Beacon Chain của Ethereum là lớp đồng thuận PoS được giới thiệu với The Merge vào tháng 9 năm 2022. Solana không triển khai slashing; Ethereum đã có nó hoạt động kể từ The Merge. Trên Beacon Chain, hai điều kiện kích hoạt hình phạt slashing: đề xuất kép (một người xác thực đề xuất hai khối khác nhau cho cùng một khe) và bỏ phiếu bao vây (một người xác thực ký một xác nhận mâu thuẫn với một xác nhận đã ký trước đó). Mức phạt ban đầu tối thiểu là 1/32 số dư hiệu quả của người xác thực, và các hình phạt tương quan sẽ tăng lên khi nhiều người xác thực phạm cùng một lỗi trong cùng một khoảng thời gian. Những người xác thực bị phạt sẽ phải đối mặt với sự chậm trễ trong hàng đợi rút tiền trước khi số dư còn lại của họ được gỡ bỏ. Xem tài liệu phạt của Ethereum Beacon Chain) để biết chi tiết thông số đầy đủ.

Ethereum yêu cầu tối thiểu 32 ETH để chạy một người xác thực trực tiếp; Solana không có yêu cầu stake tối thiểu. Để có sự so sánh rộng hơn giữa hai mạng này, hãy xem Solana so với Ethereum.)

So sánh hình phạt slashing đa chuỗi | Dữ liệu hiện tại tính đến tháng 6 năm 2025. Xác minh với tài liệu giao thức hiện tại trước khi đưa ra quyết định staking.

Để biết thông tin nền về mô hình staking và đồng thuận của Polkadot, hãy xem Polkadot là gì?

Năm mạng lưới PoS, hai phương pháp slashing: các mạng lưới có hình phạt tài chính trực tiếp (Ethereum, Cosmos, Polkadot) và các mạng lưới không có (Solana, Cardano). Việc thiếu slashing ở cấp độ giao thức của Solana có nghĩa là hiện nay những người ủy quyền không phải đối mặt với việc bị giảm vốn gốc do hành vi sai trái của validator. Những người ủng hộ kiến trúc hiện tại lập luận rằng cơ chế lockout của Tower BFT cung cấp đủ khả năng răn đe; các nhà phê bình cho rằng các hình phạt kinh tế là cần thiết cho trách nhiệm giải trình của validator ở quy mô lớn.

Các phương pháp thực hành tốt nhất cho Validator: Cách tránh các điều kiện Slashing trên Solana

Sự chậm trễ (delinquency), bị bỏ tù (jailing) và slashing của validator là ba loại hình phạt riêng biệt trên Solana. Hiện nay, chỉ có sự chậm trễ và việc bị bỏ tù mới gây ra hậu quả trực tiếp theo giao thức hiện hành. Người ủy quyền khi đọc phần này có thể dùng nó để hiểu những gì cần tìm kiếm trong lịch sử hoạt động của một validator; đối với danh sách kiểm tra lựa chọn validator, hãy xem Cách đánh giá và chọn một Validator Solana an toàn.

Chậm trễ vs. Slashing vs. Bỏ tù: Hiểu sự khác biệt

Slashing và bỏ tù là các hình phạt validator riêng biệt với những hậu quả cơ bản khác nhau đối với các token đã được stake.

Slashing và bỏ tù là hai hình phạt validator riêng biệt. Slashing (đang được đề xuất trên Solana) liên quan đến việc cưỡng chế giảm các token đã stake như một hình phạt cho hành vi sai trái như gian lận (equivocation). Bỏ tù là việc tạm thời loại trừ khỏi tập hợp validator đang hoạt động do thời gian ngoại tuyến kéo dài; nó không làm giảm số token đã stake. Bỏ tù ảnh hưởng đến phần thưởng; slashing ảnh hưởng đến vốn gốc.

Một validator ngoại tuyến trong thời gian dài có thể bị tạm thời loại bỏ khỏi tập hợp hoạt động, đôi khi được gọi là bị bỏ tù hoặc bị loại khỏi lịch trình leader. Điều này khác với slashing và không dẫn đến việc mất token cho người ủy quyền.

Các biện pháp bảo vệ vận hành dành cho người vận hành Validator Solana

Bảy biện pháp bảo vệ vận hành giúp giảm nguy cơ xảy ra các điều kiện gian lận vô ý, tác nhân chính gây ra slashing theo các bản triển khai SIMD được đề xuất. Để biết thêm về bối cảnh cung cấp và bảo mật tài khoản, cũng hãy xem lại yêu cầu validator Solana:

1. Chỉ chạy một khóa ký hoạt động duy nhất tại bất kỳ thời điểm nào. Không bao giờ để hai node chia sẻ cùng một danh tính validator đồng thời, vì đây là nguyên nhân chính dẫn đến gian lận vô ý.
2. Triển khai sao lưu trạng thái tower. Một node được khởi động lại nên khôi phục trạng thái lockout đã cam kết gần nhất thay vì bắt đầu mới từ một Vị thế có khả năng xung đột.
3. Sử dụng các mô-đun bảo mật phần cứng (HSM) để lưu ký khóa validator khi có tính khả thi về vận hành, giúp giảm rủi ro bị xâm phạm khóa.
4. Theo dõi tỷ lệ tín nhiệm phiếu bầu với cảnh báo tự động. Sự sụt giảm mạnh về tỷ lệ tín nhiệm phiếu bầu báo hiệu các vấn đề trước khi chúng leo thang thành sự chậm trễ kéo dài hoặc nguy cơ gian lận.
5. Theo dõi các ghi chú phát hành client của Solana Labs và Anza và nâng cấp theo lộ trình được khuyến nghị để tránh các lỗi làm thay đổi sự đồng thuận có thể gây ra hành vi ngoài ý muốn.
6. Duy trì dự phòng cơ sở hạ tầng thông qua các node chuyển đổi dự phòng (fail-over), nhưng không bao giờ chạy hai node ký hoạt động đồng thời. Dự phòng và ký hoạt động kép là các yêu cầu loại trừ lẫn nhau.
7. Tham gia vào các chu kỳ nâng cấp testnet trước khi áp dụng trên Mainnet để phát hiện các thay đổi hành vi đồng thuận có thể tạo ra các điều kiện gian lận ở quy mô lớn.

Ngay cả khi không có slashing trực tiếp, các validator tích lũy danh tiếng kém phải đối mặt với hậu quả kinh tế thông qua việc người ủy quyền rút tiền. Người ủy quyền theo dõi dữ liệu hiệu suất qua Stakewiz, Solana Beach, và Validators.app và chuyển stake ra khỏi các nhà vận hành kém hiệu quả.

Quản trị Slashing Solana: Các đề xuất SIMD và ý nghĩa đối với tương lai

Cập nhật lần cuối: Tháng 6 năm 2025

Tài liệu Cải tiến Solana (SIMD) là cơ chế quản trị chính thức của Solana để đề xuất các thay đổi ở cấp độ giao thức, tương tự như EIP của Ethereum. SIMD là cách cộng đồng nhà phát triển Solana chính thức đề xuất, thảo luận và phê chuẩn các thay đổi đối với giao thức. Solana Foundation, một tổ chức phi lợi nhuận có trụ sở tại Thụy Sĩ hỗ trợ hệ sinh thái Solana, đóng vai trò quản lý các cuộc thảo luận SIMD cùng với các validator, nhà phát triển và các bên liên quan khác trong cộng đồng.

Các đề xuất SIMD liên quan đến việc slashing validator đã được đưa ra bởi các thành viên của cộng đồng nhà phát triển Solana. Các đề xuất này tìm cách đưa ra các hình phạt tài chính cho hành vi gian lận (cụ thể là các vi phạm lockout do Tower BFT phát hiện) lần đầu tiên ở cấp độ giao thức. Người đọc nên xác minh tình trạng hiện tại của các SIMD có liên quan trực tiếp tại kho lưu trữ Tài liệu Cải tiến Solana (SIMD)) trên GitHub, vì tình trạng đề xuất thay đổi khi quá trình xem xét của cộng đồng tiến triển.

Cuộc tranh luận về quản trị tập trung vào hai Vị thế. Những người ủng hộ lập luận rằng các hình phạt kinh tế là cần thiết để điều chỉnh các khuyến khích của validator ở quy mô lớn và việc thiếu slashing thể hiện một lỗ hổng bảo mật so với Ethereum và Cosmos. Những người thận trọng với việc triển khai nhanh chóng chỉ ra rủi ro slashing nhầm (false-positive) trong môi trường thông lượng cao của Solana, nơi độ trễ mạng hoặc lỗi client có thể gây ra các điều kiện gian lận ở những validator trung thực.

Nếu một SIMD đề xuất slashing được chấp nhận và triển khai, hậu quả đối với các validator và người ủy quyền sẽ bao gồm:

• Gian lận (equivocation) sẽ trở thành một hành vi bị slash lần đầu tiên trên Solana
• Một tỷ lệ xác định trong tổng số SOL đã stake của validator sẽ bị đốt tự động
• Người ủy quyền có khả năng phải đối mặt với việc bị giảm vốn gốc theo tỷ lệ, tùy thuộc vào SIMD cụ thể được chấp nhận
• Các validator sẽ cần triển khai các biện pháp bảo vệ vận hành được mô tả trong phần trước trước khi thay đổi có hiệu lực

Tính đến tháng 6 năm 2025, chưa có SIMD về slashing nào được triển khai. Người đọc theo dõi chủ đề này nên giám sát trực tiếp kho lưu trữ SIMD, vì các cuộc thảo luận quản trị diễn ra ngoài chu kỳ xuất bản của bài viết này.

Các câu hỏi thường gặp về Slashing Validator trên Solana

Solana có slashing validator không?

Không. Tính đến tháng 6 năm 2025, Solana không triển khai slashing validator ở cấp độ giao thức. Solana không có cơ chế tự động đốt hoặc giảm lượng SOL đã stake của validator như một hình phạt cho hành vi sai trái. Slashing đã được đề xuất chính thức thông qua Tài liệu Cải tiến Solana (SIMD) nhưng vẫn chưa được triển khai. Các validator đối mặt với các hình phạt ảnh hưởng đến phần thưởng (chậm trễ, giảm điểm tín nhiệm phiếu bầu) nhưng không bị giảm token.

Bạn có thể mất số SOL đã stake do hành vi sai trái của validator trên Solana không?

Tính đến tháng 6 năm 2025, vốn gốc SOL mà bạn đã ủy quyền không thể bị giảm tự động bởi giao thức do hành vi sai trái của validator. Điều có thể ảnh hưởng đến bạn là hiệu suất của validator: một validator chậm trễ hoặc hoạt động kém sẽ nhận được ít điểm tín nhiệm phiếu bầu hơn, điều này làm giảm phần thưởng staking của bạn trong giai đoạn đó. Nếu việc slashing theo SIMD được triển khai trong tương lai, người ủy quyền sẽ phải đối mặt với rủi ro vốn gốc theo tỷ lệ tương ứng.

Gian lận (equivocation) trong sự đồng thuận của Solana là gì?

Gian lận xảy ra khi một validator ký hai phiếu bầu hoặc khối mâu thuẫn cho cùng một slot, cố gắng hỗ trợ hai phiên bản Blockchain khác nhau cùng một lúc. Trong Tower BFT, điều này cấu thành một vi phạm lockout. Gian lận là hành vi sai trái chính mà các bản triển khai slashing được đề xuất hướng tới. Giao thức của Solana có thể phát hiện gian lận nhưng hiện tại không xử phạt bằng cách giảm token.

Sự khác biệt giữa sự chậm trễ của validator và slashing trên Solana là gì?

Sự chậm trễ có nghĩa là trình xác thực bỏ lỡ phiếu bầu do ngừng hoạt động. Nó chỉ ảnh hưởng đến phần thưởng stake thông qua giảm tín dụng phiếu bầu và không làm giảm số dư SOL gốc của bạn. Slashing (được đề xuất trên Solana) sẽ liên quan đến việc đốt token đã stake một cách tự động như một hình phạt cho hành vi sai trái cố ý như phạm quy. Sự chậm trễ ảnh hưởng đến lợi suất; slashing ảnh hưởng đến số dư gốc. Một trình xác thực bị tạm khóa đã bị loại trừ tạm thời khỏi tập hợp hoạt động do chậm trễ kéo dài và cũng không ảnh hưởng đến số dư gốc của người ủy quyền.

Việc stake Solana có an toàn hơn việc stake Ethereum về mặt slashing không?

Tính đến tháng 6 năm 2025, người ủy quyền Solana không đối mặt với rủi ro slashing đối với số dư gốc của họ vì slashing không tồn tại ở cấp độ giao thức của Solana. Beacon Chain của Ethereum đã triển khai slashing kể từ The Merge vào năm 2022, có nghĩa là người ủy quyền Ethereum sử dụng các giao thức stake thanh khoản phải chịu rủi ro slashing theo tỷ lệ nếu trình xác thực của họ vi phạm. Các sự kiện slashing của Ethereum thực tế tương đối hiếm. Rủi ro gốc hiện tại của Solana đến từ các nguồn khác ngoài slashing.

Các đề xuất SIMD cho slashing trên Solana là gì?

Solana Improvement Documents (SIMD - Tài liệu Cải tiến Solana) là các đề xuất quản trị chính thức cho các thay đổi cấp độ giao thức. Tính đến tháng 6 năm 2025, các đề xuất SIMD đã được đưa ra để giới thiệu các hình phạt tài chính cho hành vi phạm quy trên Solana. Trạng thái hiện tại của các đề xuất cụ thể nên được xác minh tại kho lưu trữ Solana Improvement Documents (SIMD),) vì trạng thái thay đổi trong quá trình xem xét của cộng đồng.

Marinade Finance hoặc Jito có bảo vệ khỏi slashing không?

Cả Marinade Finance và Jito đều phân chia SOL đã ủy quyền trên nhiều trình xác thực, giảm rủi ro của bạn đối với hành vi sai trái của bất kỳ trình xác thực đơn lẻ nào. Nếu một trình xác thực trong một nhóm lớn bị slashing, chỉ một phần nhỏ của tổng số stake trong nhóm bị ảnh hưởng. Cả hai giao thức đều không loại bỏ hoàn toàn rủi ro slashing, và cả hai đều đưa vào rủi ro chương trình Solana mà việc stake trực tiếp không mang lại. Tham khảo tài liệu của Marinade Finance và tài liệu stake của Jito để biết chi tiết hiện tại.

Slashing sẽ hoạt động như thế nào trên Solana nếu nó được triển khai?

Theo các đề xuất triển khai slashing SIMD, cơ chế sẽ hoạt động thông qua việc phát hiện phạm quy hiện có của Tower BFT. Nếu một trình xác thực phạm quy (vi phạm khóa), giao thức sẽ tự động đốt một tỷ lệ phần trăm xác định của tổng số SOL đã stake của trình xác thực. Người ủy quyền có khả năng mất cùng một tỷ lệ phần trăm stake đã ủy quyền của họ một cách tương ứng. Số tiền phạt được đề xuất trong các cuộc thảo luận SIMD nhưng chưa được hoàn thiện. Để biết giải thích đầy đủ về cơ chế, hãy xem How Solana Handles Validator Misbehavior.

Tài khoản stake Solana (Solana stake account) là một bản ghi trên chuỗi lưu trữ SOL đã stake của bạn và theo dõi việc bạn ủy quyền cho một trình xác thực cụ thể. Nó ghi lại số tiền đã stake, trình xác thực mà nó được ủy quyền tới, và trạng thái stake hiện tại (hoạt động, hủy kích hoạt hoặc không hoạt động). Theo một triển khai slashing, tài khoản stake của bạn sẽ là mục tiêu trực tiếp của bất kỳ hình phạt nào áp dụng cho trình xác thực của bạn. Tài khoản stake khác với ví SOL chính của bạn.

Tower BFT là giao thức đồng thuận của Solana, hệ thống mà các trình xác thực sử dụng để đồng ý về trạng thái của blockchain. Được xây dựng trên Proof of History, nó sử dụng các cửa sổ khóa tăng theo cấp số nhân khiến việc bỏ phiếu trên nhiều phiên bản blockchain cạnh tranh trở nên phi lý về mặt kinh tế. Tower BFT có thể phát hiện hành vi phạm quy nhưng hiện không kích hoạt các hình phạt tài chính cho nó. Nó là nền tảng kiến trúc mà bất kỳ cơ chế slashing trong tương lai nào trên Solana sẽ hoạt động.

Kết luận: Solana Staking Có An Toàn Trước Nguy Cơ Slashing Hôm Nay Không?

Tính đến tháng 6 năm 2025, việc stake Solana không có rủi ro slashing cấp độ giao thức. Lượng SOL bạn ủy quyền không thể bị giảm tự động bởi giao thức do hành vi sai trái của trình xác thực của bạn. Các rủi ro hiện tại đối với người ủy quyền ảnh hưởng đến phần thưởng stake thông qua sự chậm trễ của trình xác thực và cấu trúc hoa hồng, chứ không phải số dư gốc của bạn.

Bức tranh nhìn về tương lai thì khác. Các đề xuất quản trị SIMD để giới thiệu slashing đang hoạt động trong cộng đồng Solana và nếu được chấp nhận, người ủy quyền sẽ đối mặt với rủi ro gốc theo tỷ lệ. Theo dõi trạng thái SIMD giờ đây là một phần quan trọng để theo dõi hồ sơ rủi ro stake của bạn.

Đối với người stake: Xem xét tỷ lệ tín dụng phiếu bầu và thời gian hoạt động của trình xác thực của bạn bằng Solana Beach hoặc Validators.app. Để đa dạng hóa tự động, việc stake thanh khoản thông qua Marinade Finance hoặc Jito sẽ phân phối stake của bạn mà không yêu cầu quản lý trình xác thực thủ công. Tham khảo tiêu chí lựa chọn trình xác thực ở trên trước khi ủy quyền.

Đối với trình xác thực: Xem xét các đề xuất SIMD hiện tại trong kho lưu trữ Solana Improvement Documents (SIMD) và triển khai các biện pháp bảo vệ hoạt động Tower BFT ngay bây giờ, trước khi bất kỳ thay đổi giao thức nào được phê chuẩn.

Đối với nhà nghiên cứu và nhà phân tích: Theo dõi trạng thái quản trị SIMD tại kho lưu trữ SIMD và so sánh mô hình phạt trình xác thực của Solana với lịch sử sự cố slashing của Ethereum để mô hình hóa bảo mật so sánh.

Thuật ngữ

Beacon Chain: Lớp đồng thuận proof-of-stake của Ethereum, được giới thiệu cùng với The Merge vào tháng 9 năm 2022. Slashing được triển khai trên Beacon Chain, không phải trên Ethereum trước The Merge.

Byzantine Fault Tolerance (BFT) (Khả năng chịu lỗi Byzantine): Một thuộc tính của các hệ thống phân tán cho phép mạng tiếp tục hoạt động chính xác ngay cả khi một số người tham gia hành động độc hại hoặc gặp sự cố. Được đặt tên theo Bài toán các tướng lĩnh Byzantine. Tower BFT là cách triển khai BFT của Solana.

Delinquency (Chậm trễ): Trình xác thực Solana bỏ lỡ các phiếu bầu do ngừng hoạt động hoặc các vấn đề về hiệu suất. Sự chậm trễ làm giảm tín dụng phiếu bầu và do đó làm giảm phần thưởng stake, nhưng không làm giảm số dư gốc đã stake. Khác với slashing và jailing.

Delegator (Người ủy quyền): Người nắm giữ SOL ủy quyền stake của họ cho trình xác thực mà không tự chạy node. Người ủy quyền kiếm phần thưởng stake tỷ lệ với phần chia sẻ của họ trong nhóm stake của trình xác thực. Hầu hết người stake SOL bán lẻ về mặt kỹ thuật là người ủy quyền, không phải trình xác thực.

Epoch (Kỳ): Một khoảng thời gian cố định trong giao thức Solana, kéo dài khoảng 2–3 ngày. Phần thưởng Staking được phân phối theo kỳ. Thời gian hủy stake để rút SOL đã stake của Solana kéo dài khoảng một kỳ.

Equivocation (Phạm quy/Khớp lệnh): Khi một trình xác thực ký hai phiếu bầu hoặc khối mâu thuẫn cho cùng một slot, thường gọi là bỏ phiếu kép. Trong Tower BFT, điều này cấu thành vi phạm khóa. Phạm quy là hành vi chính mà các đề xuất triển khai slashing nhắm tới.

Jailing (Tạm khóa): Loại trừ tạm thời trình xác thực khỏi tập hợp đồng thuận hoạt động, thường là do chậm trễ kéo dài. Tạm khóa không làm giảm token đã stake. Nó chỉ ảnh hưởng đến khả năng kiếm phần thưởng của trình xác thực trong thời gian tạm khóa. Khác với slashing.

Liquid Staking Token (LST) (Token Stake Thanh khoản): Một token có thể giao dịch đại diện cho SOL đã stake được giữ trong một giao thức stake thanh khoản. mSOL là LST của Marinade Finance; jitoSOL là LST của Jito. LST là các công cụ tài chính khác biệt với SOL đã stake thông thường.

Lockout (Khóa): Một cơ chế Tower BFT ngăn trình xác thực bỏ phiếu trên các phân nhánh cạnh tranh sau khi đã cam kết với một nhánh. Cửa sổ khóa tăng theo cấp số nhân với mỗi phiếu bầu tiếp theo. Vi phạm khóa cấu thành phạm quy.

Proof of History (PoH): Một cơ chế ghi nhận thời gian bằng mật mã, không phải là một cơ chế đồng thuận. PoH tạo ra một bản ghi có thể xác minh về trình tự các sự kiện trên mạng, hoạt động như một đồng hồ mật mã. Tower BFT, cơ chế đồng thuận của Solana, được xây dựng trên PoH.

Proof of Stake (PoS): Một khuôn khổ đồng thuận trong đó các trình xác thực đặt token làm tài sản thế chấp để tham gia sản xuất khối và bỏ phiếu. Slashing là cơ chế phạt thực thi hành vi trung thực trong các hệ thống PoS. Solana sử dụng kiến trúc lai (PoH cộng với Tower BFT) thay vì PoS tiêu chuẩn.

SIMD (Tài liệu Cải tiến Solana): Cơ chế quản trị chính thức của Solana để đề xuất các thay đổi cấp giao thức, tương tự như EIP của Ethereum. SIMD là cách thức slashing đã được đề xuất nhưng chưa được triển khai trên Solana.

Slashing: Một hình phạt cấp giao thức trong các blockchain Proof of Stake tự động giảm bớt token đã stake của một validator làm hình phạt cho hành vi sai trái có thể chứng minh được như cố tình đưa ra các fork khác nhau (equivocation). Tính đến tháng 6 năm 2025, slashing chưa được triển khai trên Solana.

Tài khoản Stake: Một cấu trúc dữ liệu trên chuỗi đặc thù của Solana chứa SOL đã stake của người ủy quyền. Nó ghi lại số lượng stake, validator được ủy quyền và trạng thái stake hiện tại. Khác với ví SOL chính.

Tower BFT: Giao thức đồng thuận Khả dĩ Sai sót (Byzantine Fault Tolerant) của Solana, được xây dựng trên Proof of History. Các validator bỏ phiếu về các fork, và mỗi phiếu bầu mang một cửa sổ khóa có độ dài tăng dần theo cấp số nhân. Tower BFT có thể phát hiện hành vi cố tình đưa ra các fork khác nhau (equivocation) nhưng hiện không phạt nó bằng cách giảm token.

Validator: Một nhà điều hành nút chạy cơ sở hạ tầng validator Solana, đưa ra phiếu bầu đồng thuận thông qua Tower BFT và tham gia vào việc sản xuất khối. Validator khác với người ủy quyền. Validator là thực thể sẽ bị phạt trực tiếp theo bất kỳ việc triển khai slashing nào.

Phí hoa hồng của Validator: Tỷ lệ phần trăm phần thưởng staking mà một validator giữ lại trước khi phân phối phần còn lại cho người ủy quyền. Phí hoa hồng là tỷ lệ phần trăm của phần thưởng, không phải của số dư gốc đã stake. Mức phí 10% có nghĩa là validator giữ lại 10% phần thưởng kiếm được.

Đọc thêm

• Solana so với Ethereum: Nên mua cái nào bây giờ)
• Polkadot là gì? Giải thích Parachains)