Finality blockchain là trạng thái mà tại đó một giao dịch hoặc block được xem là đã hoàn tất và rất khó, hoặc không thể, bị đảo ngược theo các quy tắc đồng thuận của mạng. Khái niệm này không đồng nghĩa với việc giao dịch vừa xuất hiện trên explorer hay vừa được đưa vào một block.
Có hai mô hình chính:
- Probabilistic finality — finality xác suất: khả năng giao dịch bị đảo ngược giảm dần khi có thêm block được xây phía trên.
- Deterministic finality — finality xác định: giao dịch đạt trạng thái hoàn tất khi giao thức tạo ra một quyết định finality rõ ràng, với điều kiện các giả định an toàn của cơ chế đồng thuận vẫn được duy trì.
Vì các blockchain sử dụng cơ chế đồng thuận, fork-choice rule và kiến trúc khác nhau, không tồn tại một số block xác nhận phù hợp cho mọi mạng.
Finality blockchain là gì?
Tính hoàn tất giao dịch blockchain trả lời câu hỏi: giao dịch đã ổn định đến mức nào và còn khả năng bị loại khỏi lịch sử chuẩn của chuỗi hay không?
Một giao dịch đã được đưa vào block vẫn có thể chưa đạt finality. Nếu mạng xuất hiện hai nhánh cạnh tranh, quy tắc lựa chọn chuỗi có thể chọn nhánh không chứa giao dịch đó. Hiện tượng một số block gần đầu chuỗi bị thay thế bởi nhánh khác thường được gọi là tái tổ chức chuỗi, hay chain reorganization/reorg.
Finality luôn gắn với các giả định cụ thể, chẳng hạn:
- Tỷ lệ tài nguyên đồng thuận do bên trung thực kiểm soát.
- Số validator hoạt động và mức độ phân tán của họ.
- Điều kiện kết nối giữa các node.
- Fork-choice rule của giao thức.
- Cơ chế checkpoint hoặc biểu quyết finality.
- Việc phần mềm đồng thuận có hoạt động đúng hay không.
Do đó, “final” không nên được hiểu là sự bất biến tuyệt đối trong mọi tình huống. Lỗi phần mềm nghiêm trọng, vi phạm giả định an toàn hoặc quyết định phối hợp ngoài giao thức vẫn có thể tạo ra trường hợp ngoại lệ.
Giao dịch đi từ pending đến finality như thế nào?
Một giao dịch thường trải qua các trạng thái sau:
- Đã phát tới mạng: ví gửi giao dịch đến node hoặc RPC.
- Pending: giao dịch chờ được nhà sản xuất block lựa chọn.
- Đã được đưa vào block: explorer hoặc RPC hiển thị block chứa giao dịch.
- Có xác nhận: các block mới tiếp tục được xây dựng sau block chứa giao dịch.
- Đạt finality: giao dịch đáp ứng tiêu chí hoàn tất của giao thức.
Pending không phải là một dạng finality thấp. Đây là trạng thái giao dịch chưa được ghi nhận vào lịch sử chuẩn của chuỗi. Nếu gặp tình trạng này, người dùng nên kiểm tra giao dịch blockchain bị pending trước khi kết luận mạng đã xác nhận giao dịch.
Thông tin trên ví cũng có thể chậm hoặc sai do RPC chưa đồng bộ. Khi dữ liệu giữa ví và explorer không thống nhất, cần kiểm tra RPC blockchain và lỗi kết nối ví bằng nhiều nguồn độc lập.
Probabilistic finality và deterministic finality khác nhau ra sao?
Probabilistic finality là gì?
Probabilistic finality, hay tính hoàn tất xác suất, không tạo ra một thời điểm tuyệt đối mà tại đó giao dịch đột ngột trở thành không thể đảo ngược. Thay vào đó, rủi ro reorg thường giảm khi độ sâu xác nhận tăng.
Các chuỗi sử dụng cơ chế lựa chọn nhánh dựa trên lượng tài nguyên tích lũy có thể thuộc nhóm này. Chẳng hạn, khi tìm hiểu cơ chế hoạt động và rủi ro của Bitcoin, cần phân biệt giao dịch đã vào block với giao dịch đã có đủ độ sâu xác nhận cho mục đích sử dụng cụ thể.
Mức rủi ro không chỉ phụ thuộc vào số block. Nó còn liên quan đến năng lực của bên có thể tạo nhánh cạnh tranh, độ trễ mạng, giá trị giao dịch và tình trạng hiện tại của hệ thống. Vì vậy, không thể suy ra một xác suất đảo ngược chính xác chỉ từ con số confirmations trên explorer nếu thiếu mô hình và dữ liệu đầu vào.
Deterministic finality là gì?
Deterministic finality, hay tính hoàn tất xác định, xuất hiện khi giao thức có một quyết định rõ ràng rằng block đã được finalized. Quyết định này thường dựa trên biểu quyết hoặc chứng nhận của một tỷ lệ validator theo quy tắc đồng thuận.
Sau khi block đạt finality, hai lịch sử xung đột không thể cùng được hoàn tất nếu các giả định an toàn vẫn đúng. Muốn đảo ngược block có thể đòi hỏi việc vi phạm quy tắc đồng thuận, một tỷ lệ validator hành xử sai hoặc sự can thiệp ngoài quy trình thông thường.
Tuy nhiên, deterministic finality không có nghĩa mọi block vừa được tạo đều final ngay lập tức. Một mạng có thể phân biệt:
- Block mới được đề xuất.
- Block đã được fork-choice ưu tiên.
- Block an toàn hơn nhưng chưa finalized.
- Block đã có chứng nhận finality.
Người dùng cần tra đúng trạng thái do giao thức công bố, thay vì chỉ đếm block đã xuất hiện sau giao dịch.
| Tiêu chí | Probabilistic finality | Deterministic finality |
|---|---|---|
| Cách đạt độ an toàn | Rủi ro giảm dần theo độ sâu chuỗi | Giao thức đưa ra quyết định finality |
| Vai trò của số block xác nhận | Thường là chỉ báo quan trọng | Có thể không phải tiêu chí chính |
| Khả năng reorg trước finality | Có, tùy điều kiện mạng | Có thể có trước khi được finalized |
| Khả năng đảo ngược sau finality | Không bằng tuyệt đối; rủi ro giảm theo mô hình | Đòi hỏi vi phạm giả định an toàn hoặc tình huống ngoại lệ |
| Cách kiểm tra | Độ sâu block và hướng dẫn của mạng | Trạng thái finalized, checkpoint hoặc chứng nhận đồng thuận |
Số block xác nhận liên quan thế nào đến rủi ro tái tổ chức chuỗi?
Số block xác nhận thường thể hiện độ sâu của block chứa giao dịch so với đầu chuỗi hiện tại. Khi có thêm block xây phía trên, một nhánh cạnh tranh muốn loại bỏ giao dịch phải thay thế phần lịch sử dài hoặc nặng hơn.
Quan hệ tổng quát có thể hiểu như sau:
- Ít xác nhận: giao dịch nằm gần đầu chuỗi, dễ bị ảnh hưởng hơn bởi reorg ngắn.
- Nhiều xác nhận: việc tạo nhánh cạnh tranh thường khó hơn trong mô hình finality xác suất.
- Đã finalized: với mạng có finality xác định, trạng thái finality quan trọng hơn việc tiếp tục đếm confirmations.
Dù vậy, confirmations không phải đơn vị hoàn toàn đồng nhất. Explorer có thể tính block chứa giao dịch là xác nhận đầu tiên, trong khi hệ thống khác chỉ đếm các block được tạo sau đó. Một số mạng còn sử dụng slot, round, epoch hoặc checkpoint thay cho cách đếm block đơn giản.
Reorg có làm giao dịch biến mất hoàn toàn không?
Không phải lúc nào cũng vậy. Sau reorg, giao dịch có thể:
- Được đưa lại vào một block trên chuỗi mới.
- Quay về trạng thái chờ nếu vẫn hợp lệ.
- Bị thay thế bởi giao dịch khác sử dụng cùng nonce hoặc đầu vào.
- Trở nên không hợp lệ do trạng thái chuỗi đã thay đổi.
Vì vậy, khi phát hiện block hash hoặc trạng thái giao dịch thay đổi, cần kiểm tra lại transaction hash, block hash, trạng thái thực thi và chuỗi chuẩn hiện tại.
Vì sao không nên áp dụng một số xác nhận cho mọi blockchain?
Một con số confirmations chung có thể tạo cảm giác an toàn sai vì các mạng khác nhau ở nhiều yếu tố:
- Cơ chế đồng thuận và fork-choice rule.
- Thời gian tạo block và mức độ biến động của thời gian này.
- Khả năng xảy ra reorg thông thường.
- Cách mạng định nghĩa safe, justified hoặc finalized.
- Cơ chế checkpoint và chu kỳ biểu quyết validator.
- Kiến trúc Layer 1, sidechain hoặc Layer 2.
- Yêu cầu riêng của sàn giao dịch, bridge và ứng dụng lưu ký.
Ngay cả trên cùng một mạng, ngưỡng chấp nhận cũng có thể khác theo mục đích. Một giao dịch giá trị nhỏ có thể được ứng dụng hiển thị sớm, trong khi hệ thống lưu ký hoặc dịch vụ chuyển tài sản liên chuỗi có thể chờ tiêu chí nghiêm ngặt hơn.
Ngưỡng do sàn hoặc ứng dụng công bố là chính sách quản trị rủi ro của đơn vị đó, không nhất thiết trùng với finality ở cấp giao thức.
Cách tra finality và số xác nhận của từng mạng
Thay vì lấy một con số từ bài viết tổng hợp rồi áp dụng lâu dài, người dùng nên kiểm tra tài liệu hiện hành của từng blockchain theo quy trình sau.
1. Xác định đúng mạng và lớp đang sử dụng
Kiểm tra chain ID, tên mạng, tài sản gốc hay token và giao dịch diễn ra trên Layer 1, Layer 2 hay sidechain. Các mạng có tên hoặc tài sản tương tự vẫn có thể sử dụng mô hình finality hoàn toàn khác nhau.
2. Tìm tài liệu đồng thuận chính thức
Trong website tài liệu hoặc kho mã nguồn chính thức của dự án, tìm các mục có thuật ngữ:
- Consensus.
- Finality.
- Fork choice.
- Block confirmation.
- Checkpoint.
- Safe block hoặc finalized block.
- Reorganization.
Ưu tiên tài liệu kỹ thuật đang được dự án duy trì. Bài blog cũ có thể không còn đúng sau khi mạng nâng cấp cơ chế đồng thuận.
3. Xác định mạng dùng finality xác suất hay xác định
Nếu tài liệu mô tả rủi ro giảm theo số block, hãy tìm khuyến nghị confirmations cho từng loại hoạt động. Nếu giao thức có checkpoint hoặc chứng nhận finality, hãy tìm cách node và explorer biểu thị trạng thái finalized.
Một số hệ thống kết hợp cả hai lớp bảo đảm: fork-choice cung cấp trạng thái tạm thời, còn cơ chế finality tạo checkpoint mạnh hơn. Không nên ép chúng vào một trong hai nhóm theo cách tuyệt đối.
4. Kiểm tra cách RPC biểu thị finality
Tài liệu RPC có thể cho phép truy vấn block theo trạng thái như latest, safe hoặc finalized. Cần đọc định nghĩa chính thức vì cùng một nhãn không bảo đảm có ý nghĩa giống nhau trên mọi hệ sinh thái.
Nên đối chiếu ít nhất các dữ liệu sau:
- Transaction hash.
- Trạng thái thực thi thành công hay thất bại.
- Block number hoặc block height.
- Block hash.
- Đầu chuỗi hiện tại.
- Trạng thái safe/finalized nếu mạng hỗ trợ.
5. Đọc yêu cầu của dịch vụ nhận tiền
Nếu chuyển tiền vào sàn, bridge hoặc hệ thống lưu ký, hãy kiểm tra chính sách nạp tiền của chính dịch vụ đó. Dịch vụ có thể chỉ ghi có sau một số xác nhận hoặc sau khi block đạt finality theo tiêu chuẩn nội bộ.
Không nên tự suy đoán rằng giao dịch đã được mạng xác nhận thì số dư trên sàn phải xuất hiện ngay. Hệ thống nạp tiền còn phụ thuộc vào bộ lập chỉ mục, kiểm soát rủi ro và trạng thái vận hành của dịch vụ.
6. Kiểm tra thay đổi giao thức gần đây
Nâng cấp mạng có thể thay đổi thời gian hoặc cách đạt finality. Khi tài liệu mâu thuẫn, cần ưu tiên phiên bản áp dụng cho mạng chính hiện tại và đối chiếu thông báo phát hành. Việc kiểm tra lịch hard fork và nguồn thông báo chính thức giúp tránh dùng thông số của phiên bản giao thức cũ.
Finality trên Layer 2 và bridge cần hiểu thế nào?
Trên Layer 2, người dùng có thể gặp nhiều mốc xác nhận khác nhau:
- Giao dịch được sequencer tiếp nhận.
- Giao dịch xuất hiện trong block hoặc batch của Layer 2.
- Dữ liệu hoặc cam kết trạng thái được đăng lên Layer 1.
- Batch đáp ứng cơ chế xác minh của rollup.
- Hoạt động rút hoặc chuyển tài sản được bridge chấp nhận.
Xác nhận nhanh từ sequencer có thể hữu ích cho trải nghiệm người dùng, nhưng không tự động đồng nghĩa với finality kế thừa từ Layer 1. Khi đánh giá rủi ro, cần hiểu vai trò và giới hạn của sequencer Layer 2, bao gồm khả năng trì hoãn hoặc sắp xếp giao dịch.
Finality của rollup còn liên quan đến việc dữ liệu cần thiết để xác minh trạng thái có sẵn hay không. Data availability trong kiến trúc rollup là vấn đề khác với việc giao dịch chỉ xuất hiện trên giao diện của Layer 2.
Đối với bridge, “đã xác nhận ở chuỗi nguồn” và “đã nhận tài sản ở chuỗi đích” là hai sự kiện riêng. Bridge có thể chờ finality của chuỗi nguồn, xác minh bằng chứng rồi mới phát hành hoặc mở khóa tài sản ở chuỗi đích. Mỗi bridge có mô hình tin cậy và tiêu chí xác nhận riêng.
Cách đánh giá một giao dịch đã đủ an toàn hay chưa
Có thể sử dụng danh sách kiểm tra sau:
- Giao dịch đã được thực thi thành công, không chỉ được phát tới RPC.
- Transaction hash nằm trong block thuộc chuỗi chuẩn hiện tại.
- Block hash không thay đổi khi đối chiếu giữa các nguồn đáng tin cậy.
- Số block xác nhận được hiểu đúng theo cách tính của explorer hoặc RPC.
- Trạng thái safe hoặc finalized đã đạt nếu mạng cung cấp nhãn này.
- Ngưỡng chấp nhận phù hợp với tài liệu hiện hành của mạng.
- Dịch vụ nhận tiền đã công bố yêu cầu xác nhận riêng.
- Với Layer 2, đã phân biệt xác nhận của sequencer, trạng thái trên Layer 1 và finality của cơ chế rollup.
- Với bridge, đã kiểm tra cả chuỗi nguồn lẫn chuỗi đích.
Tóm lại, số block xác nhận là một tín hiệu về độ ổn định của giao dịch, đặc biệt trong mô hình probabilistic finality, nhưng không phải thước đo chung cho toàn bộ blockchain. Cách an toàn hơn là xác định mô hình đồng thuận của mạng, đọc định nghĩa finality trong tài liệu chính thức và áp dụng tiêu chí phù hợp với loại giao dịch, ứng dụng hoặc dịch vụ đang sử dụng.
