Đưa cơ chế phạt cắt stake lên Solana

Giới thiệu

Phạt cắt stake là cơ chế bảo đảm an ninh mạng bằng cách xử phạt hành vi ác ý hoặc bất cẩn của validator. Sau khi hành vi sai phạm được xác minh, một phần stake được ủy quyền cho validator vi phạm sẽ bị đốt.

Đây là đặc điểm riêng biệt của các mạng Proof of Stake (PoS) như Solana và không có cơ chế tương đương trong Proof of Work (PoW), vì nó phụ thuộc vào khả năng của giao thức trong việc trực tiếp thực thi hình phạt tài chính bằng cách tiêu hủy tài sản đã stake. Trong PoW không có cơ chế tương tự, bởi blockchain không thể tịch thu hoặc phá hủy phần cứng khai thác vật lý của các tác nhân không trung thực.

Cơ chế phạt cắt stake mang lại một số lợi ích chính:

• Tạo ra yếu tố răn đe kinh tế trực tiếp đối với hoạt động ác ý
• Khuyến khích người stake phân bổ stake cho các validator uy tín, qua đó cải thiện tính phi tập trung
• Khuyến khích các đơn vị vận hành lớn xây dựng hạ tầng không đồng nhất để giảm nguy cơ lỗi chung (ví dụ: chia stake giữa các client Firedancer và Agave).
• Cung cấp thêm một chỉ số để validator tạo sự khác biệt và xây dựng danh tiếng bằng cách tránh các vi phạm dẫn đến phạt cắt stake, đồng thời phát hiện hoạt động ác ý của những bên tham gia khác.

Trong suốt lịch sử của mình, Solana đã dựa vào phương thức đồng thuận thủ công do cộng đồng dẫn dắt, được gọi là phạt cắt stake xã hội. Theo mô hình này, nếu một validator có hành vi ác ý, chẳng hạn làm tổn hại đến tính hoạt động liên tục hoặc tính an toàn của mạng, những bên tham gia trung thực có thể phối hợp ngoài chuỗi để khởi tạo hard fork, tái khởi động mạng và cắt stake của bên vi phạm. Dù phương thức này cho phép đánh giá linh hoạt theo từng trường hợp, nó đòi hỏi chi phí phối hợp đáng kể và vốn mang tính phản ứng.

Cho đến nay, chưa có validator nào trên Solana bị phạt cắt stake. Sự kiện gần giống nhất diễn ra vào tháng 5 năm 2020, hai tháng sau khi mainnet ra mắt, khi Solana Foundation tự nguyện đốt 11,36 triệu SOL từ phần phân bổ của mình để phản hồi những lo ngại của cộng đồng về các khoản vay token không được công bố dành cho các nhà tạo lập thị trường. Việc này làm giảm tổng nguồn cung token 2,3%, từ 500 triệu xuống còn 488,64 triệu SOL. Dù không phải một sự kiện phạt cắt stake chính thức, việc đốt token đóng vai trò như một hình phạt tự áp đặt nhằm khôi phục niềm tin và giải quyết các vấn đề minh bạch mà cộng đồng ban đầu nêu ra.

Trong nhiều năm, đã có những lời kêu gọi Solana áp dụng một cơ chế phạt cắt stake chính thức hơn, thường được gọi là phạt cắt stake theo chương trình, được thực thi trực tiếp trên chuỗi thông qua một chương trình tích hợp sẵn. Theo hệ thống này, nếu validator vi phạm các quy tắc cụ thể của giao thức, bằng chứng mật mã về hành vi vi phạm có thể được tạo và gửi đến một chương trình chuyên dụng, sau đó chương trình sẽ tự động kích hoạt hình phạt. Mô hình này giảm sự phụ thuộc vào việc phối hợp giữa con người và cho phép xử lý các vi phạm nhỏ mà không làm gián đoạn hoạt động của mạng, mở đường cho cơ chế trách nhiệm giải trình phi tập trung có khả năng mở rộng.

Việc sắp kích hoạt feature gate cho SIMD-0204: Xác minh sự kiện có thể bị phạt cắt stake đánh dấu bước tiến lớn và thực chất đầu tiên của Solana trong quá trình triển khai cơ chế phạt cắt stake theo chương trình chính thức trên mainnet. Như sẽ được trình bày ở phần sau của báo cáo, rất may là các sự kiện phạt cắt stake theo chương trình trên mạng blockchain hiếm khi xảy ra và mức phạt thường nhỏ. Tuy nhiên, chỉ riêng khả năng stake của validator bị giao thức tự động tiêu hủy cũng tạo ra những rủi ro mới mà mọi bên liên quan phải cân nhắc kỹ lưỡng. Vẫn còn nhiều câu hỏi chưa có lời giải về phương thức tối ưu để Solana thực thi cơ chế này. Giống như mọi thay đổi kinh tế khác, các tham số và hình phạt liên quan sẽ cần được cộng đồng thảo luận rộng rãi và cuối cùng phải được phê duyệt thông qua một cuộc bỏ phiếu quản trị chính thức.

Các SIMD liên quan đến phạt cắt stake

Một số SIMD liên quan đến quá trình triển khai cơ chế phạt cắt stake theo chương trình trên Solana. Hai SIMD đầu tiên là SIMD-180 và SIMD-204 dự kiến sẽ đi vào hoạt động trên mainnet trong những tháng tới.

Đầu tiên là điều kiện tiên quyết SIMD-0180: Sử dụng địa chỉ vote account làm khóa cho lịch leader. SIMD này chuyển khóa dùng trong lịch leader từ địa chỉ danh tính của validator sang địa chỉ vote account. Thay đổi này rất cần thiết để quy trách nhiệm phạt cắt stake chính xác, vì nó tạo ra mối liên kết trực tiếp, rõ ràng giữa nhiệm vụ sản xuất block của validator và stake được ủy quyền cho họ.

SIMD-0204: Xác minh sự kiện có thể bị phạt cắt stake phác thảo một Chương trình phạt cắt stake mới. Chương trình này đưa vào một cơ chế trên chuỗi cho phép bất kỳ ai gửi và ghi lại bằng chứng về hành vi có thể bị phạt cắt stake, qua đó tạo ra một hồ sơ bất biến và có thể xác minh về hành vi sai phạm của validator.

Cuối cùng, SIMD-0212: Phạt cắt stake phác thảo cách triển khai cơ chế phạt cắt stake trong giao thức Solana. SIMD này dựa trên nền tảng do SIMD-0204 thiết lập để áp dụng hình phạt cho các vi phạm đã được xác minh. Đề xuất này vẫn đang mở và tiếp tục được thảo luận tích cực.

Phát hiện và quy trách nhiệm lỗi

Chương trình phạt cắt stake được thiết kế như một lớp thuần quan sát. Chương trình không sửa đổi stake hoặc phần thưởng; chức năng duy nhất là xác minh và ghi lại các vi phạm. Một nguyên mẫu ban đầu đã hoạt động trên Testnet, với các nội dung gửi mẫu (ví dụ: các transaction DuplicateBlockProof) minh họa cách ghi lại vi phạm.

Sản xuất block trùng lặp

Trong lần triển khai đầu tiên, chương trình sẽ tập trung vào một loại hành vi ác ý duy nhất: phát hiện các trường hợp sản xuất block trùng lặp. Đây là khi một leader gửi hai hoặc nhiều phiên bản khác nhau của một block cho cùng một slot, cấu thành hành vi vi phạm đồng thuận rõ ràng và khách quan. 

Trước đây, vào tháng 9 năm 2022, một sự cố ngừng hoạt động của mạng đã xảy ra do một validator sản xuất nhầm các block trùng lặp ở cùng độ cao block. Nguyên nhân là cả node chính và node dự phòng của validator đều hoạt động đồng thời, sử dụng cùng danh tính node nhưng đề xuất các block khác nhau.

Vấn đề này sau đó đã được khắc phục. Hiện nay, ngay cả khi đơn vị vận hành đang chạy một node dự phòng nóng, client validator cũng có các biện pháp bảo vệ để tự tắt nếu phát hiện nhiều phiên bản đang chạy. Vì vậy, việc sản xuất block trùng lặp gần như không thể xảy ra nếu không có hành động cố ý sửa đổi phần mềm validator với mục đích ác ý.

Sản xuất block trùng lặp là một ví dụ về vi phạm giao thức khó phát hiện theo thời gian thực nhưng dễ xác minh sau khi xảy ra. Việc cố gắng phối hợp phản ứng đồng bộ, trong đó mạng dừng lại để xác nhận rằng các bên đều quan sát thấy bản trùng lặp, sẽ tạo ra độ phức tạp đáng kể. Thay vào đó, phát hiện và xử phạt hồi tố thực tế hơn nhiều.

Bằng chứng được gửi cho các block trùng lặp bao gồm hai shred xung đột của cùng một slot, đều được ký bởi cùng một validator. Chương trình phạt cắt stake xác minh bằng chứng bằng cách bảo đảm các shred tạo thành bằng chứng block trùng lặp hợp lệ, xác nhận chúng thuộc cùng một slot và được validator vi phạm ký chính xác. Logic này phản ánh phương thức mà giao thức gossip của Solana dùng để xử lý bằng chứng block trùng lặp trong quy trình lựa chọn fork.

struct DuplicateBlockProofData {
  shred1_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred1: &[u8]           // `shred1_length` bytes representing a shred,
  shred2_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred2: &[u8]           // `shred2_length` bytes representing a shred,
}

Người báo cáo tạo bằng chứng và lưu trữ bằng chứng đó trong một buffer account trên chuỗi, sau đó gửi một transaction đến chương trình phạt cắt stake tại địa chỉ `S1ashing11111111111111111111111111111111111`, tham chiếu đến buffer account của họ. Sau khi bằng chứng được xác minh thành công, kết quả được lưu trong một Program Derived Address (PDA) `report_account` thuộc quyền sở hữu của chương trình phạt cắt stake để tham chiếu trong tương lai. Nhờ đó, có thể dễ dàng xây dựng dashboard hiển thị dữ liệu liên quan đến phạt cắt stake chỉ bằng cách chạy lệnh gọi getProgramAccounts trên chương trình. Validator có thể dùng các dashboard này để kiểm tra xem mình có bị báo cáo vi phạm hay không và thực hiện biện pháp khắc phục khi cần.

Anza dự kiến sẽ phát hành công cụ hỗ trợ quan sát các sự kiện này, tạo bằng chứng và gửi bằng chứng lên chuỗi. Có thể sẽ có nhiều cách triển khai, bao gồm một phiên bản được nhúng trong phần mềm validator. Chỉ cần một bên tham gia trung thực báo cáo vi phạm trong một epoch, vì mỗi tổ hợp duy nhất giữa bên vi phạm và slot chỉ có thể được báo cáo một lần. Chương trình xác minh xem báo cáo cho cùng slot và bên vi phạm đã tồn tại hay chưa. Nếu tìm thấy báo cáo trùng khớp, nội dung gửi mới sẽ bị từ chối. Báo cáo có thể được gửi trong vòng tối đa một epoch sau khi vi phạm xảy ra, dựa trên slot nơi sự việc diễn ra (tức là tối đa 432.000 slot sau đó, theo dõi bằng sysvar `Clock`).

Phần thưởng cho người tố giác

Một câu hỏi phổ biến khi thiết kế cơ chế phạt cắt stake là liệu những người báo cáo vi phạm (tức người tố giác) có nên được thưởng hay không. Dù việc thưởng cho người tố giác có vẻ là một cơ chế khuyến khích đơn giản, nó đi kèm những thách thức đáng kể.

Trên Solana, nơi leader kiểm soát việc đưa transaction vào block, phần thưởng cho người tố giác tạo ra rủi ro frontrunning. Giả sử một validator gửi bằng chứng phạt cắt stake hợp lệ cho leader của block hiện tại. Khi đó, leader có thể chỉ cần sao chép bằng chứng, tự gửi bằng chứng đó và kiểm duyệt transaction ban đầu để nhận phần thưởng mà không phải thực hiện công việc. Điều này làm suy yếu mô hình khuyến khích và mở đường cho hành vi lạm dụng.

Ethereum cung cấp một phần thưởng nhỏ cho người tố giác: 1/512 số dư hiệu dụng của validator bị phạt cắt stake. Với validator có đủ 32 ETH, con số này tương đương 0,0625 ETH. Phần thưởng được phát hành dưới dạng ETH mới nhưng được bù trừ bởi lượng lớn hơn bị đốt từ stake của validator chịu phạt. Giá trị thấp là có chủ đích, vì phần thưởng nhằm thúc đẩy tính chính trực và sự tham gia trung thực thay vì hành vi cơ hội vì lợi nhuận.

Vi phạm bỏ phiếu

Các phiên bản tương lai của Chương trình phạt cắt stake dự kiến sẽ mở rộng hỗ trợ cho nhiều loại vi phạm bỏ phiếu, chẳng hạn như vi phạm lockout và vi phạm switching proof.

Vi phạm lockout xảy ra khi validator bỏ phiếu trên hai fork riêng biệt mà không chờ đủ thời gian để tower lockout hết hạn. Theo thuật toán đồng thuận hiện tại của Solana là TowerBFT, sau khi validator bỏ phiếu cho một fork cụ thể tại một slot nhất định, validator đó sẽ bị "khóa" không được bỏ phiếu cho các fork cạnh tranh trong một khoảng thời gian. Nếu validator sau đó bỏ phiếu cho một fork khác trước khi thời gian lockout hết hạn, họ đã vi phạm quy tắc lockout.

Bot Votalizer, do Michael Vines, đồng sáng lập Solana, phát triển, hiện hoạt động trong Solana Tech Discord và theo dõi các vi phạm lockout khi chúng xảy ra trên toàn mạng. Trên thực tế, validator hiếm khi vô tình thực hiện những vi phạm như vậy, vì điều đó thường đòi hỏi phải cố ý sửa đổi client validator. Các biện pháp bảo vệ tích hợp bảo đảm client truy xuất phiếu bầu trên chuỗi gần nhất và ngăn những hành động có thể dẫn đến vi phạm lockout.

Mặc dù vi phạm lockout được đề cập rõ ràng trong SIMD về phạt cắt stake và tài liệu ban đầu như một ví dụ về vi phạm bỏ phiếu mà chương trình có thể xử lý, bản cập nhật đồng thuận Alpenglow theo kế hoạch sẽ loại bỏ Tower BFT, đồng thời xóa bỏ khái niệm lockout. Vì lý do này, các vi phạm bỏ phiếu dự kiến chỉ được đưa vào sau khi Alpenglow ra mắt.

Các vi phạm bỏ phiếu mới hơn trong Alpenglow mà chương trình phạt cắt stake có thể được thiết kế để phát hiện có thể bao gồm những hành động như gửi các phiếu xung đột cho cùng một slot, chẳng hạn bỏ cả phiếu `NotarVote` và `SkipVote`.

Các loại vi phạm trong tương lai

Cơ chế phạt cắt stake theo chương trình phải gắn với các trường hợp sai phạm có thể xác minh và không mơ hồ. Đáng tiếc là yêu cầu này khiến việc xử lý những vấn đề mang tính chủ quan hoặc hệ thống hơn, chẳng hạn cố tình sản xuất block chậm hoặc các hình thức khai thác MEV có hại, trở nên khó khăn hơn đáng kể.

Trên các mạng blockchain tương đương, những loại hành vi thường dẫn đến phạt cắt stake khác nhau tùy theo giao thức. Các ví dụ phổ biến gồm:

• Ký hai lần: Sản xuất hai block xung đột ở cùng độ cao hoặc slot.
• Thời gian ngừng hoạt động: Ngoại tuyến và không tham gia đồng thuận.
• Bỏ phiếu bao quanh: Bỏ các phiếu xung đột với phiếu trước đó nhằm thao túng hoặc gây mất ổn định mạng.

Một đề xuất mới về phạt cắt stake do chính 0xIchigo của Helius đưa ra vào năm ngoái đề nghị xử phạt các validator thuộc nhóm siêu đa số nhưng không tham gia các cuộc bỏ phiếu quản trị chính thức nhằm khuyến khích mức độ tham gia cao hơn. Dù phương thức này đáp ứng yêu cầu có thể xác minh khách quan, một số người bình luận đã nêu quan ngại. Một số chỉ ra rằng các ràng buộc pháp lý có thể ngăn một số validator bỏ phiếu. Những người khác cho rằng chỉ nên áp dụng phạt cắt stake đối với hành vi trực tiếp đe dọa đến an ninh hoặc tính toàn vẹn của mạng.

Thực thi hình phạt

Sau khi Solana có cơ chế trên chuỗi đáng tin cậy để báo cáo và xác minh các hành vi có thể bị phạt cắt stake, ưu tiên tiếp theo là thực thi hình phạt về mặt kinh tế, bao gồm xác định chính xác các tham số và công thức tính mức phạt cho từng loại vi phạm.

Các hướng dẫn vẫn đang được tích cực thảo luận và nội dung trong phần này phản ánh những đề xuất hiện tại nhằm cung cấp thông tin, khuyến khích đối thoại và tiếp tục phát triển dựa trên phản hồi của cộng đồng. Vì các quyết định này ảnh hưởng trực tiếp đến bài toán kinh tế khi vận hành validator Solana, mọi thay đổi sẽ trải qua tranh luận công khai trong cộng đồng và phải được phê duyệt thông qua quy trình quản trị chính thức.

Khi xác định hình phạt cắt stake, một nguyên tắc quan trọng là tránh xử phạt quá nặng những lỗi vận hành hiếm gặp và chỉ xảy ra một lần. Lý tưởng nhất, hệ thống hình phạt nên có biên độ dung sai cùng các biện pháp bảo vệ phù hợp đối với những sự cố nhỏ không ảnh hưởng đến đồng thuận, thay vì áp dụng hình phạt nghiêm khắc cho sai sót vô ý.

Phương án hiện đang được cân nhắc cho biên độ này là ngưỡng Hệ số Nakamoto (NC), được đặt ở mức stake của validator nhỏ nhất trong nhóm siêu thiểu số (tức khoảng 1% tổng stake). 

Theo hàm được đề xuất, dùng để xác định lượng stake bị cắt từ mỗi khoản ủy quyền theo từng vote account, nếu tổng stake vi phạm thấp hơn ngưỡng NC thì sẽ không có stake nào bị cắt. Ngược lại, nếu đồng thuận gặp rủi ro, nghĩa là hơn một phần ba tổng stake liên quan đến các vi phạm, giao thức nên phản ứng dứt khoát bằng cách cắt 100% stake vi phạm.

Đối với các trường hợp nằm giữa hai thái cực này, đề xuất hiện tại đưa vào một hàm phạt bậc hai có tốc độ tăng chậm. Công thức dùng để tính tỷ lệ stake bị cắt cho mỗi vote account như sau:

v = vote account có thể bị phạt cắt stake

TSS = Tổng stake có thể bị phạt cắt

TS = Tổng stake

Ngưỡng NC = Ngưỡng Hệ số Nakamoto

Theo công thức này, tỷ lệ phần trăm stake bị cắt của validator vi phạm có thể được tính như sau:

• 1,2% khi 4,66% stake vi phạm (tức là (3 * (0.0466 - 0.01) / 1)²)
• 7,3% khi 10% stake vi phạm (tức là (3 * (0.1 - 0.01) / 1)²)

Biểu đồ dưới đây minh họa đường cong được đề xuất cùng hai phương án thay thế (mạnh tay và tuyến tính).

Tổng stake có thể bị phạt cắt (TSS) được tính bằng trọng số dựa trên loại vi phạm. Vi phạm bỏ phiếu có trọng số 1 vì ít nghiêm trọng hơn. Vi phạm block trùng lặp có trọng số 10 vì được xem là nghiêm trọng hơn.

Một lợi thế chính của hình phạt cắt stake bậc hai và có tương quan, như phương án hiện được đề xuất, là khuyến khích các bên vận hành nhiều validator, chẳng hạn sàn giao dịch hoặc nhà cung cấp staking-as-a-service, duy trì hạ tầng độc lập, chất lượng cao để giảm thiểu nguy cơ xảy ra lỗi tương quan trên diện rộng.

Các phương án thay thế cơ chế phạt cắt stake truyền thống

Việc cắt stake được ủy quyền đặt ra những câu hỏi quan trọng về tính công bằng và trách nhiệm giải trình. Trong mô hình staking hiện tại, phần lớn, nếu không muốn nói là toàn bộ, stake tại hầu hết validator không riêng tư đều là stake được ủy quyền. Điều này có nghĩa là khi xảy ra phạt cắt stake, bên chịu phần lớn hình phạt thường là người ủy quyền chứ không phải đơn vị vận hành validator đã thực hiện hành vi vi phạm. Ngay cả những người stake thận trọng và lựa chọn validator uy tín cũng có thể bị cắt stake dù không có lỗi nếu validator hành động ác ý hoặc cấu hình sai node.

Để giải quyết sự mất cân bằng này, một số thiết kế phạt cắt stake thay thế đã được đề xuất. Một phương thức là yêu cầu mọi validator duy trì mức stake tự có tối thiểu. Điều này bảo đảm các đơn vị vận hành cũng phải chịu rủi ro và không thể chuyển toàn bộ chi phí phạt sang người ủy quyền. Phiên bản nghiêm ngặt hơn của phương thức này là chỉ cắt stake tự có, đồng thời tự động hủy staking của tất cả người ủy quyền liên quan đến validator bị phạt. Người ủy quyền sẽ mất phần thưởng nhưng vẫn giữ được tiền gốc, cho phép họ phân bổ lại stake sang validator khác với tác động dài hạn tối thiểu.

Một phương thức khác là đóng băng account trong một khoảng thời gian xác định. Trong thời gian này, account không thể nhận phần thưởng, thay đổi quyền sở hữu hoặc rút tiền. Thời gian đóng băng sẽ tăng theo mức độ nghiêm trọng của hành vi vi phạm. Ngoài ra, giao thức có thể cắt giảm phần thưởng trong tương lai, làm giảm thu nhập của validator và người ủy quyền trong một khoảng thời gian nhất định mà không động đến stake gốc.

Một số người đề xuất phân phối lại stake bị cắt cho các validator trung thực như một hình thức củng cố tích cực thay vì đốt. Tuy nhiên, việc đốt SOL thực tế đạt được kết quả tương tự vì làm giảm tổng nguồn cung, qua đó tăng tỷ lệ sở hữu mạng tương đối của mọi người nắm giữ.

Các vấn đề cần cân nhắc

Việc đưa cơ chế phạt cắt stake vào Solana kéo theo một số hệ quả quan trọng. Trong phần này, chúng ta xem xét hai lĩnh vực then chốt: thời gian chờ và các rủi ro, nhu cầu bảo hiểm cũng như gánh nặng vận hành phát sinh đối với những bên tham gia hệ sinh thái.

Thời gian chờ

Một lỗ hổng quan trọng trong mô hình staking hiện tại xuất hiện khi validator thực hiện hành vi có thể bị phạt cắt stake nhưng hủy staking trước khi vi phạm được quan sát và báo cáo. Nếu không có cơ chế trì hoãn rút tiền, tác nhân ác ý có thể lợi dụng khoảng trống thời gian này để thoát khỏi hình phạt.

Một khoảng thời gian chờ mà trong đó stake vẫn có thể bị cắt ngay cả sau khi ngừng kích hoạt sẽ giảm thiểu vấn đề này. Thời gian chờ phải dài hơn khoảng thời gian tối đa cần thiết để validator hoặc bên quan sát bên ngoài phát hiện và phối hợp phản ứng phạt cắt stake, đặc biệt trong các điều kiện đối kháng như tấn công DDoS ở cấp độ mạng hoặc sự thông đồng giữa các validator ác ý. Trên thực tế, điều này có nghĩa thời gian chờ nên kéo dài nhiều ngày.

Việc Solana phụ thuộc vào các snapshot stake được tính toán trước khiến vấn đề này trầm trọng hơn. Một số thành phần giao thức quan trọng, bao gồm lịch leader và quy tắc lựa chọn fork, dựa vào các giá trị stake được tính trước. Do đó, stake đã ngừng kích hoạt hoặc thậm chí đã được rút hoàn toàn vẫn có thể ảnh hưởng đến đồng thuận.

Ví dụ, lịch leader được tạo từ snapshot stake trước đó, chụp trước một epoch tại ranh giới epoch. Điều này tạo ra một khoảng thời gian mà validator có thể thực hiện hành vi có thể bị phạt cắt stake sau khi đã ngừng kích hoạt stake trong epoch trước và rút stake vào đầu epoch hiện tại. Đến khi vi phạm bị phát hiện, không còn stake đang hoạt động để xử phạt.

Một giải pháp là bổ sung thời gian chờ, trong đó stake vẫn có thể bị cắt nhưng không còn được tính vào trọng số stake của giao thức. Người stake ngừng kích hoạt stake trong epoch N nhưng chỉ có thể rút stake vào đầu epoch N+3. Dù cải thiện bảo mật, sự chậm trễ này gây ra trải nghiệm người dùng kém vì buộc người stake phải chờ thêm khoảng ~2-4 ngày trước khi có thể rút toàn bộ stake. Một cách giải quyết là rút ngắn epoch để duy trì thời gian hủy staking theo thời gian thực tương tự tiêu chuẩn hiện tại. Tuy nhiên, mọi sự rút ngắn thời lượng epoch đều có thể gây ra những hệ quả không lường trước đối với giao thức và cần được đánh giá cẩn thận.

Rủi ro, bảo hiểm và gánh nặng vận hành

Việc đưa cơ chế phạt cắt stake vào Solana có ảnh hưởng đến nhiều bên tham gia hệ sinh thái, đặc biệt là những bên lưu ký, quản lý hoặc xây dựng sản phẩm tài chính dựa trên SOL đã stake. Chỉ riêng khả năng bị phạt cắt stake cũng có thể tạo ra rủi ro tài chính, sự phức tạp trong vận hành và mối lo ngại về danh tiếng, đặc biệt đối với các tổ chức hoạt động dưới những ràng buộc về trách nhiệm ủy thác hoặc quy định. Có thể giải quyết các rủi ro này bằng những biện pháp bảo vệ như bảo hiểm hoặc trái phiếu bảo đảm.

Các bên liên quan có thể bị ảnh hưởng gồm:

• Các giao thức liquid staking
• Các pool stake
• Các nhà cung cấp dịch vụ staking lưu ký
• Các giao thức restaking
• Các giao thức DeFi
• ETF staking

Đối với một số tổ chức này, sự kiện phạt cắt stake có thể gây ra hậu quả dây chuyền. Ví dụ, liquid staking token (LST) được bảo chứng dựa trên giả định rằng các validator nền tảng hoạt động an toàn. Nếu một validator bị phạt cắt stake, điều này có thể khiến LST của họ bị định giá lại mạnh hoặc trong trường hợp cực đoan bị mất neo giá nếu niềm tin vào validator nơi SOL nền tảng được stake sụp đổ. Điều này có thể dẫn đến thanh lý nếu LST được dùng làm tài sản thế chấp trong một giao thức cho vay.

Các nhà cung cấp dịch vụ staking trong những hệ sinh thái khác thường cung cấp bảo hiểm phạt cắt stake để giảm thiểu các rủi ro này. Chẳng hạn trên Ethereum, nhiều nhà cung cấp đưa ra phạm vi bảo hiểm với chi phí hợp lý để bảo vệ trước tổn thất do phạt cắt stake, với mức độ bảo vệ khác nhau tùy theo gói bảo hiểm.

Rủi ro phạt cắt stake cũng tạo ra những trách nhiệm vận hành mới trên toàn bộ chuỗi giá trị staking. Các bên chịu ảnh hưởng gồm:

• Đơn vị vận hành dịch vụ staking, hiện phải theo dõi hành vi của validator và chủ động giảm thiểu rủi ro
• Nền tảng lưu ký và sàn giao dịch tiền mã hóa, vốn phụ thuộc vào đơn vị vận hành bên thứ ba và có thể cần thẩm định cũng như đa dạng hóa tập hợp validator
• Đơn vị quản lý tài sản tổ chức, có thể tìm kiếm bảo hiểm tổn thất riêng để bảo vệ trước các khoản lỗ liên quan đến phạt cắt stake do đơn vị vận hành bên ngoài gây ra

So sánh với các mạng tương đương

Phần này xem xét cách cơ chế phạt cắt stake được triển khai trên các mạng Proof of Stake tương đương như Ethereum và Cosmos. Những mạng này đã thực thi cơ chế phạt cắt stake theo chương trình trong nhiều năm, cung cấp dữ liệu thực tế có giá trị về tần suất xảy ra sự kiện phạt và tác động của chúng đến an ninh mạng cũng như hành vi của validator.

Ethereum

Giao thức Proof of Stake của Ethereum, được đưa vào cùng thời điểm ra mắt Beacon Chain vào tháng 12 năm 2020, đã sử dụng phạt cắt stake làm cơ chế thực thi cốt lõi ngay từ ngày đầu tiên. Ethereum xác định bốn hành vi cụ thể có thể bị phạt cắt stake, tất cả đều xoay quanh hành vi biểu quyết mâu thuẫn:

• Đề xuất nhiều block cho cùng một slot
• Gửi các chứng thực xung đột cho cùng một checkpoint đích
• Chứng thực các block đầu chuỗi khác nhau với cùng checkpoint nguồn và đích
• Tạo hai chứng thực mà một chứng thực “bao quanh” chứng thực còn lại xét theo phiếu nguồn và đích

Mỗi hành vi vi phạm đều có cùng cấu trúc hình phạt. Khi validator bị phạt cắt stake, hình phạt tức thời bằng 1/32 số dư hiệu dụng được áp dụng, giới hạn ở 1 ETH do số dư hiệu dụng tối đa là 32 ETH. Sau đó, validator bị buộc rời khỏi tập hợp đang hoạt động và được đưa vào hàng đợi thoát trong khoảng 36 ngày.

Trong thời gian này, validator không hoạt động và không thể rút tiền. Validator tiếp tục mất những phần thưởng lẽ ra nhận được nếu vẫn hoạt động, qua đó phải chịu chi phí cơ hội liên tục. Sau 18 ngày, một hình phạt tương quan bổ sung được áp dụng, được thiết kế để tăng theo tỷ lệ số validator bị phạt cắt stake trong khung thời gian 36 ngày. Nếu chỉ một vài validator bị phạt, mức phạt sẽ nhỏ. Tuy nhiên, trong trường hợp xảy ra sự kiện phạt cắt stake hàng loạt, dù do hành vi sai phạm có phối hợp hay lỗi hạ tầng dùng chung, mức phạt sẽ tăng mạnh và trong kịch bản xấu nhất có thể khiến validator mất gần như toàn bộ số dư đã stake.

Dù giữ vai trò trung tâm trong giao thức Ethereum, trên thực tế phạt cắt stake cực kỳ hiếm khi xảy ra. Tính đến tháng 5 năm 2025, chỉ 484 validator, chiếm chưa đến 0,05% tổng số validator, bị phạt trong 131 sự cố. Các sự cố này thường bắt nguồn từ một lỗi duy nhất ảnh hưởng đến nhiều validator và thường là kết quả của sai sót từ đơn vị vận hành hoặc lỗi phần mềm, không phải ý đồ ác ý.

Sự kiện phạt cắt stake lớn nhất xảy ra vào tháng 11 năm 2023, khi Bitcoin Suisse có 100 validator bị phạt vì các vi phạm liên quan đến tình trạng không hoạt động, mỗi validator mất 1 ETH.

Cho đến nay, chưa có sự cố phạt cắt stake nào trên Ethereum đe dọa tính toàn vẹn tổng thể của giao thức. Điều này cho thấy dù phạt cắt stake là một biện pháp răn đe thiết yếu, việc thực thi trên thực tế không thường xuyên và hệ sinh thái validator phần lớn đã tiếp thu những hành vi cần thiết để tránh các hình phạt này.

Cosmos

Cosmos và các chuỗi dựa trên Cosmos SDK, chẳng hạn Cosmos Hub, triển khai phạt cắt stake như một cơ chế bảo mật tích hợp nhằm xử lý hai lỗi chính: ký hai lần và ngừng hoạt động kéo dài. Các quy tắc phạt này giúp thực thi cả đặc tính an toàn lẫn tính hoạt động liên tục của giao thức.

Validator ký hai block khác nhau ở cùng độ cao sẽ bị xử phạt ngay lập tức. Bất kỳ bên tham gia nào cũng có thể gửi bằng chứng vi phạm lên chuỗi. Sau khi được xác minh, validator sẽ tự động bị cắt 5% số token đã stake và chuyển sang trạng thái tombstoned, nghĩa là bị loại vĩnh viễn khỏi tập hợp validator đang hoạt động và không thể tham gia lại. Sau khi bị tombstoned, cả validator lẫn người ủy quyền phải chờ hết thời gian unbonding trước khi có thể ủy quyền lại stake. Dù đơn vị vận hành validator bị tombstoned có thể khởi chạy lại bằng khóa mới, họ phải xây dựng lại danh tiếng và các khoản ủy quyền từ đầu.

Cosmos cũng thực thi tính hoạt động liên tục thông qua cơ chế tự động phạt cắt stake khi ngừng hoạt động kéo dài. Nếu validator ký ít hơn 5% trong 10.000 block gần nhất, validator đó được xem là không hoạt động và bị phạt cắt 0,01% stake. Dù nhỏ hơn nhiều khi so sánh, việc thực thi này rất nghiêm ngặt và không thể thương lượng, bảo đảm validator duy trì thời gian hoạt động và tham gia đồng thuận một cách đáng tin cậy.

Điều thú vị là một số validator chấp nhận mức phạt nhỏ này như chi phí để tự nguyện ngừng hoạt động vì cho rằng tổn thất không đáng kể.

Dù các mạng Cosmos SDK sử dụng chung tham số phạt cắt stake mặc định tiêu chuẩn, từng chuỗi có thể sửa đổi hoặc mở rộng các quy tắc này để phản ánh những giả định bảo mật và mô hình rủi ro riêng. Tính linh hoạt này cho phép mỗi mạng điều chỉnh hệ thống phạt theo quy mô tập hợp validator, mục tiêu phi tập trung hoặc khả năng chịu lỗi dự kiến. Hoạt động phạt cắt stake trên 57 mainnet dựa trên Cosmos SDK cung cấp góc nhìn rộng hơn về việc thực thi trên toàn hệ sinh thái:

• 12.143 lần phạt liên quan đến thời gian ngừng hoạt động
• 111 lần phạt do ký hai lần
• 326 vi phạm khác
• Tổng cộng 12.580 sự cố phạt cắt stake

Những số liệu này cho thấy dù ký hai lần hiếm khi xảy ra và bị xử phạt nặng, phạt cắt stake do ngừng hoạt động diễn ra thường xuyên hơn và chủ yếu được xem là chi phí vận hành thông thường. 

Kết luận

Phạt cắt stake vẫn là một trong những chủ đề gây tranh luận và nhiều cảm xúc nhất trong ngành blockchain. Bất cứ khi nào xuất hiện những hình thức sai phạm mới của validator hoặc sự thiếu đồng bộ về động lực khuyến khích, lời kêu gọi áp dụng phạt cắt stake nhanh chóng xuất hiện. Không khó để hiểu lý do: bề ngoài, đây dường như là một biện pháp răn đe mạnh mẽ, cung cấp cơ chế trực tiếp trên chuỗi để trừng phạt tác nhân xấu và duy trì tính toàn vẹn của mạng.

Tuy nhiên, như bài viết đã trình bày, phạt cắt stake theo chương trình không phải giải pháp vạn năng cho hành vi sai phạm. Hiệu quả của nó phụ thuộc vào việc hành vi vi phạm phải vừa rõ ràng vừa có thể chứng minh, những điều kiện không phải lúc nào cũng dễ đáp ứng trong các tình huống thực tế phức tạp. Việc phạt cắt stake khi bằng chứng không rõ ràng hoặc còn có thể diễn giải theo nhiều cách sẽ có nguy cơ trừng phạt các bên trung thực, làm suy yếu niềm tin và có thể gây thiệt hại lớn hơn chính những vi phạm mà cơ chế muốn ngăn chặn.

Có thể nói giá trị lớn nhất mà các hình thức phạt cắt stake tự động mang lại cho mạng là tác động tâm lý đến các bên liên quan. Chỉ riêng khả năng chịu tổn thất kinh tế do bất kỳ hình thức vi phạm nào, dù hiếm đến đâu, cũng có thể đủ để thúc đẩy những người stake ngại rủi ro phân bổ khoản ủy quyền của mình cho nhiều validator, đồng thời tạo động lực để các đơn vị vận hành đầu tư vào hạ tầng đa dạng và độc lập.

Tài nguyên tham khảo thêm

• Phạt cắt stake: Thuốc chữa bách bệnh hay chiếc hộp Pandora? - Tim Roughgarden, Accelerate Conference
• Các giới hạn kinh tế của cơ chế đồng thuận không cần cấp phép - Eric Budish, Andrew Lewis-Pye, Tim Roughgarden 
• Trách nhiệm giải trình về tính hoạt động liên tục - Andrew Lewis-Pye, Joachim Neu, Tim Roughgarden, Luca Zanolini