Mức độ cam kết trên Solana là gì?

Mức độ cam kết trên Solana là gì?

Mức độ cam kết trên Solana là cách tiêu chuẩn hóa để đo lường mức đồng thuận của mạng đối với một khối hoặc giao dịch cụ thể. Khi truy vấn node RPC của Solana để lấy trạng thái giao dịch hoặc dữ liệu tài khoản (ví dụ: getTransaction), bạn có thể chỉ định mức độ cam kết để cho biết dữ liệu cần được hoàn tất đến mức nào. Solana sử dụng mức độ cam kết này để giúp máy khách cân bằng giữa độ trễ và độ chắc chắn: mức cam kết thấp cho phản hồi nhanh hơn, còn mức cam kết cao giúp nhà phát triển chắc chắn hơn rằng trạng thái sẽ không bị hoàn tác.

Solana xác định ba mức độ cam kết chính (theo thứ tự mức hoàn tất giảm dần):

Finalized

Mức chắc chắn cao nhất, cho biết khối đã được đại đa số cổ phần (≥66 %) xác nhận và có ít nhất 31 khối đã xác nhận khác được xây dựng phía trên, giúp slot đạt thời gian khóa tối đa sau 32 phiếu bầu. Giao dịch Finalized về cơ bản không thể đảo ngược.

Confirmed

Mức trung gian, trong đó khối đã nhận được phiếu bầu từ đại đa số cổ phần (≥66%) nhưng chưa được hoàn tất qua một giai đoạn bỏ phiếu liên tục dài hơn khiến việc đảo ngược trở nên khó khăn hơn. Trạng thái này thường được gọi là xác nhận lạc quan, cung cấp sự đảm bảo mạnh mẽ rằng giao dịch nằm trên “fork chính” hay chuỗi chính tắc.

Processed

Processed nghĩa là giao dịch vừa được leader xử lý và đưa vào khối gần nhất mà node biết đến. Tuy nhiên, khối đó có thể chưa nhận được phiếu bầu nào trên toàn cụm. Giao dịch vẫn có thể bị loại nếu khối đó cuối cùng không thuộc fork đa số.

Các mức này đại diện cho từng giai đoạn trong vòng đời của giao dịch. 

Một giao dịch mới gửi sẽ chuyển từ Processed → Confirmed → Finalized khi ngày càng nhiều thành phần trong mạng quan sát và bỏ phiếu cho khối chứa giao dịch, đồng thời các khối tiếp theo được xây dựng phía trên khối đó. Mức cam kết cao hơn đồng nghĩa với việc có nhiều node đồng thuận hơn về sự hiện diện của giao dịch, qua đó giảm rủi ro fork hoặc hoàn tác. 

Hãy cùng tìm hiểu chi tiết từng mức.

Mức độ cam kết Processed

Giao dịch đạt trạng thái Processed ngay khi một node validator (tức leader hiện tại) đưa giao dịch vào khối. Đây là xác nhận sớm nhất: giao dịch đã được nhận và tích hợp vào trạng thái sổ cái cục bộ.

Các đặc điểm chính của mức Processed gồm:

• Được đưa vào khối: Giao dịch nằm trong một khối do validator tạo ra.
• Không đảm bảo thuộc fork đa số: Khối này có thể thuộc hoặc không thuộc fork đa số (dài nhất/nặng nhất)
• Phản hồi nhanh nhất: Mức này phản hồi ngay rằng giao dịch đã được một node xử lý. Điều này hữu ích cho các cập nhật nhanh phía máy khách (ví dụ: hiển thị giao dịch đang chờ xử lý trong giao diện ví).
• Chưa hoàn toàn an toàn: Ở giai đoạn này, không có gì đảm bảo các validator khác đã thấy hoặc bỏ phiếu cho khối. Cụm vẫn có thể “bỏ qua” khối này hoặc ghi đè bằng một fork khác. Nói cách khác, Processed = đã được đưa vào nhưng chưa được các bên khác xác nhận.

Ví dụ về khối Processed: 

Giả sử Alice gửi một giao dịch chuyển khoản trên Solana. Ngay khi leader hiện tại thêm giao dịch vào một khối (slot N), giao dịch được đánh dấu là Processed. Ví của Alice có thể lập tức hiển thị giao dịch là đang chờ xử lý/đã xử lý. 

Tuy nhiên, nếu khối của leader đó không được đa số validator chấp nhận (ví dụ: leader hoạt động chậm hoặc ngoại tuyến và một fork khác chiếm ưu thế), giao dịch của Alice có thể biến mất (tức bị loại) vì khối đã xử lý không trở thành một phần của chuỗi chính.

Mức độ cam kết Confirmed

Mức độ cam kết Confirmed cho biết khối chứa giao dịch đã được đại đa số trong cụm chấp nhận và rất có thể nằm trên chuỗi chính tắc. Về mặt kỹ thuật, “confirmed” nghĩa là ≥66% validator tính theo trọng số cổ phần đã trực tiếp bỏ phiếu cho khối đó. 

Các đặc điểm chính:

• Nằm trên fork đa số: Khối chứa giao dịch được công nhận là một phần của fork đa số trong sổ cái. Điều này có nghĩa mạng xem đây là một khối chính tắc.

• Phiếu bầu của đại đa số: Ít nhất hai phần ba tổng cổ phần đã bỏ phiếu xác nhận khối. Các phiếu bầu này được thu thập qua cơ chế gossip của Solana, nghĩa là các validator đã phát và quan sát phiếu bầu cho khối này trên toàn mạng. Giai đoạn này sử dụng xác nhận lạc quan, được giới thiệu trong Solana v1.3, cho phép các node xem một khối là đã xác nhận ngay khi đại đa số bỏ phiếu cho khối đó (ngay cả trước khi khối được hoàn tất).

• Rủi ro hoàn tác thấp: Với mức đồng thuận từ 66% trở lên, khả năng một fork xung đột thay thế khối này là rất thấp, dù không phải không thể. Trên thực tế, mọi validator trung thực đều đã cam kết với khối này, trừ khi xảy ra một đợt tái tổ chức lớn. Không có khối Confirmed nào bị hoàn tác trong lịch sử năm năm của Solana.

• Nhanh hơn Finalized: Trạng thái Confirmed thường xuất hiện không lâu sau khi một khối hoặc giao dịch được đánh dấu là Processed (trong vòng một hoặc hai giây), vì các validator nhanh chóng bỏ phiếu cho khối mới. Trạng thái này không chờ nhiều khối tiếp theo. Vì vậy, Confirmed mang lại sự cân bằng tốt giữa tốc độ và độ tin cậy trong điều kiện bình thường.

• Tính hoàn tất lạc quan: Với cơ chế đồng thuận nhanh của Solana, nhà phát triển thường xem giao dịch Confirmed là về cơ bản đã hoàn tất cho phần lớn mục đích thực tế. Tuy nhiên, vẫn còn một xác suất nhỏ giao dịch bị hoàn tác trước khi hoàn tất.

Ví dụ về khối Confirmed: 

Giao dịch của Alice ở trên trở thành Confirmed sau khi các validator trong cụm bỏ phiếu cho khối N. Trên thực tế, nếu một số validator tiếp theo (ở slot N+1, N+2, v.v.) bỏ phiếu và nhìn thấy khối N, giúp đạt ngưỡng 66%, mạng sẽ đánh dấu khối N là đã xác nhận. Lúc này, ví của Alice có thể an toàn hiển thị giao dịch là đã xác nhận cho người dùng. 

Xác suất giao dịch chuyển khoản của Alice bị hoàn tác ở thời điểm này rất thấp (chỉ khi xảy ra fork hiếm gặp hoặc sự cố mạng). Điều này tương tự “N lượt xác nhận” trên các chuỗi khác, nhưng trên Solana, nó dựa trên phiếu bầu theo cổ phần thay vì một số lượt xác nhận khối cố định.

Mức độ cam kết Finalized

Giao dịch đạt trạng thái Finalized khi khối của giao dịch đã được đại đa số bỏ phiếu và có đủ số khối bổ sung được xây dựng phía trên. Trong cơ chế đồng thuận của Solana, điều này tương ứng với việc khối đạt thời gian khóa tối đa, thường sau khi 32 phiếu bầu (slot) liên tiếp xác nhận khối. Finalized là mức độ cam kết mạnh nhất, mang lại độ chắc chắn cao nhất rằng giao dịch sẽ không bị đảo ngược. 

Các đặc điểm của Finalized gồm:

• Khối không thể đảo ngược: Cụm đã công nhận khối này là hoàn tất, nghĩa là khối đã được đặt làm gốc trong trạng thái sổ cái. Các validator sẽ không hoàn tác khối và khối về cơ bản là vĩnh viễn.

• Đại đa số + thời gian khóa: Tương tự Confirmed, ít nhất 66% cổ phần đã ủng hộ khối. Ngoài ra, hơn 31 khối đã xác nhận tiếp theo đã được thêm vào sau khối đó. Nói cách khác, mạng đã xây dựng một chuỗi sâu phía trên khối này, đạt độ sâu khóa khiến việc tái tổ chức không còn khả thi.

• Thời gian khóa tối đa (32 phiếu bầu): Cơ chế Tower BFT của Solana tăng gấp đôi thời gian khóa của các phiếu bầu theo cấp số nhân. Khi một khối đã tích lũy 32 phiếu bầu trong tower (nghĩa là khối vẫn thuộc fork dẫn đầu qua thêm 32 slot), khối đạt thời gian khóa tối đa và được hoàn tất. Lúc này, bất kỳ validator nào cố bỏ phiếu cho một fork khác đều sẽ vi phạm quy tắc đồng thuận.

• An toàn nhất, xác nhận chậm nhất: Quá trình hoàn tất thường chậm hơn các mức Processed và Confirmed một khoảng thời gian (khoảng ~10-20 giây trong điều kiện bình thường, vì 32 slot với mỗi slot ~400ms ≈ 13 giây). Đây là sự đánh đổi để đạt được độ chắc chắn của Finalized. Bằng cách chờ hoàn tất, máy khách loại bỏ mọi rủi ro giao dịch bị loại hoặc đảo ngược, nhưng phải chấp nhận độ trễ bổ sung.

• Đã xác nhận + được xây dựng phía trên: Một cách khác để hiểu trạng thái hoàn tất: đó là một khối Confirmed đã bị chôn sâu dưới nhiều khối khác. Tất cả node trung thực đều đã khóa khối này vào sổ cái vĩnh viễn theo cách có thể xác minh.

Ví dụ về khối Finalized:

Giao dịch của Alice đạt trạng thái Finalized sau khi mạng tiếp tục tạo các khối vượt qua slot N. Giả sử đến slot N+32, đại đa số validator đã bỏ phiếu cho từng khối liên tiếp cho đến N+32 (không có fork nào chiếm ưu thế). Khối N (chứa giao dịch của Alice) lúc này đã được hoàn tất. 

Tại thời điểm này, giao dịch của Alice hoàn toàn vĩnh viễn trong sổ cái của Solana – ngay cả khi cô ấy chờ thêm một thời gian, trạng thái chứa giao dịch chuyển khoản của cô ấy cũng sẽ không thay đổi. 

Mọi ứng dụng yêu cầu tính hoàn tất mạnh (chẳng hạn sàn giao dịch giải ngân) giờ đây có thể an toàn thực hiện hành động dựa trên giao dịch này. Đáng chú ý, nếu kẻ tấn công cố hoàn tác giao dịch, chúng sẽ cần kiểm soát hơn 1/3 cổ phần và vi phạm cơ chế đồng thuận.

Các mức độ cam kết đã ngừng dùng

Các phiên bản Solana trước đây (trước năm 2021) cung cấp thêm một số mức độ cam kết, nhưng chúng đã ngừng được dùng và được thay thế bằng ba mức nêu trên.

Để cung cấp thông tin đầy đủ, dưới đây là các thuật ngữ cũ và cách chúng ánh xạ tới những mức hiện tại:

• recent – Đã ngừng dùng; tương đương với Processed. Trong tài liệu cũ, “recent” chỉ đơn giản là trạng thái mới nhất mà node biết đến.

• single và singleGossip – Đã ngừng dùng; tương đương với Confirmed. Các thuật ngữ này đề cập đến xác nhận từ một validator hoặc qua gossip, phù hợp với định nghĩa của Confirmed.

• root và max – Đã ngừng dùng; tương đương với Finalized. “Root” đề cập đến trạng thái gốc đã được hoàn tất trong cụm, còn “max” đề cập đến thời gian khóa tối đa—cả hai về cơ bản đều có nghĩa là đã hoàn tất.

Hiện nay, nhà phát triển chỉ nên dùng processed, confirmed hoặc finalized khi chỉ định mức độ cam kết. Kể từ v1.5.5, Solana JSON-RPC API mặc định sử dụng các thuật ngữ này và coi những thuật ngữ đã ngừng dùng là bí danh của mức tương ứng. 

Ngoài ra, nếu yêu cầu RPC không chỉ định mức cam kết, giá trị mặc định là Finalized (tức node mặc định trả về trạng thái đã được hoàn tất cao nhất).

Khác biệt giữa các mức độ cam kết

Có thể hiểu sự khác biệt giữa Processed, Confirmed và Finalized dựa trên mức độ mạng đã công nhận giao dịch và khả năng giao dịch bị đảo ngược. Bảng dưới đây (được điều chỉnh từ tài liệu chính thức của Solana) tóm tắt các điểm khác biệt chính:

Tóm lại, Processed chỉ có nghĩa là giao dịch nằm trong một khối (không hơn). Confirmed nghĩa là cụm đã đồng thuận về khối đó (phiếu bầu của đại đa số), nhưng khối vẫn nằm gần đầu chuỗi. Finalized nghĩa là khối nằm sâu trong chuỗi với nhiều lượt xác nhận—sâu đến mức về cơ bản không thể thay đổi.

Một cách khác để nhìn nhận sự khác biệt là xét xác suất giao dịch vẫn còn trong sổ cái chính tắc theo thời gian. 

Ngay khi được xử lý, xác suất không phải là 100% (vẫn có khả năng xảy ra fork hoặc lỗi). Sau khi được hơn 66% cổ phần xác nhận, xác suất được đưa vào tăng lên rất cao. Đến khi giao dịch được hoàn tất với hàng chục khối phía trên, xác suất được đưa vào đạt ~100%. 

Biểu đồ dưới đây minh họa điều này, cho thấy khả năng một giao dịch được hoàn tất tăng lên như thế nào khi nhiều slot trôi qua và mức độ cam kết tăng lên:

Khả năng một giao dịch được đưa vào chuỗi chính tắc cuối cùng tăng dần theo thời gian. Ban đầu tại slot n (giao dịch được xử lý), giao dịch vẫn có nguy cơ bị “bỏ qua” hoặc loại khỏi chuỗi do fork. Với xác nhận lạc quan (Confirmed), khả năng được đưa vào tăng mạnh khi các validator bỏ phiếu. Sau khi có đủ số fork liên tiếp được xây dựng phía trên (Finalized), xác suất đảo ngược về cơ bản bằng không. Điều này cho thấy rủi ro hoàn tác giảm dần khi mức độ cam kết tăng lên.

Solana xác định mức độ cam kết như thế nào?

Hiểu cách cơ chế đồng thuận của Solana hoạt động “bên trong” sẽ giúp làm rõ lý do các mức độ cam kết này tồn tại:

Proof of History (PoH) và quá trình tạo khối

Các leader của Solana tạo khối liên tục với tốc độ cao (mỗi slot có một leader, mỗi slot ~400ms). Giao dịch được truyền vào chuỗi băm Proof of History (PoH), tạo thành các mục trong một khối. Các khối nhanh chóng lan truyền qua mạng thông qua Turbine (giao thức truyền khối của Solana). Khi leader tạo một khối chứa giao dịch của bạn, khối đó lập tức được truyền đi nhưng chưa được xác nhận — tương ứng với giai đoạn Processed.

Bỏ phiếu (Tower BFT)

Solana sử dụng thuật toán đồng thuận BFT có tên Tower BFT. Các validator (mỗi validator kiểm soát một lượng cổ phần) bỏ phiếu cho những khối mà họ cho rằng nên trở thành phần tiếp theo của sổ cái. Bản thân phiếu bầu cũng là giao dịch Solana và bao gồm khái niệm thời gian khóa. Mỗi khi validator bỏ phiếu cho một khối tại slot N, validator đó phải chịu một khoảng khóa; nếu sau đó bỏ phiếu cho một fork xung đột, validator có thể mất quyền bỏ phiếu trong một thời gian. 

Thời gian khóa này tăng gấp đôi theo cấp số nhân với mỗi phiếu bầu liên tiếp trên cùng một fork (1, 2, 4, 8... slot khóa) và đạt giới hạn ở 32 phiếu bầu. Nếu validator đã bỏ phiếu 32 lần liên tiếp trên một fork (nghĩa là khối từ 32 slot trước vẫn thuộc fork nặng nhất), khối đó đạt thời gian khóa tối đa. Cơ chế này khuyến khích validator tiếp tục theo fork đa số và hoàn tất các khối.

Xác nhận (Xác nhận lạc quan)

Khi một khối được tạo, các validator phát phiếu bầu cho khối đó. Ngay khi đại đa số cổ phần (≥66%) đã bỏ phiếu cho một khối, các node Solana xem khối đó là đã được xác nhận theo cơ chế lạc quan. Đây là mức độ cam kết Confirmed. Quá trình này diễn ra nhanh chóng, thường trong vòng một hoặc hai slot sau khối, vì phiếu bầu được truyền qua gossip. 

Điều quan trọng là việc triển khai của Solana không yêu cầu chờ khối được đặt làm gốc trong sổ cái; hệ thống tin tưởng phiếu bầu của đại đa số như một tín hiệu lạc quan rằng khối cuối cùng sẽ được hoàn tất (trừ trường hợp <33% cổ phần hành xử sai trái). 

Đây là lý do nó được gọi là xác nhận lạc quan: theo giả định lỗi Byzantine thông thường (tối đa 1/3 không trung thực), phiếu bầu của đại đa số có nghĩa là khối sẽ không bị lật ngược. Để một fork ghi đè khối này, hơn 33% validator sẽ phải bỏ phiếu cho chuỗi thay thế, vi phạm các giả định.

Hoàn tất (Đặt khối làm gốc)

Khi các khối mới tiếp tục được tạo và bỏ phiếu, mỗi khối đã xác nhận sẽ tiến sâu hơn vào fork. Sau khi một khối tích lũy phiếu bầu trong 32 slot liên tiếp phía sau, khối đạt thời gian khóa tối đa. Tại thời điểm này, mạng đặt khối đó làm gốc, đánh dấu khối là đã hoàn tất và không thể đảo ngược. Trạng thái hoàn tất nghĩa là khối nằm sau đầu chuỗi ít nhất 31 khối và chưa bao giờ bị từ bỏ để chuyển sang fork khác. Tất cả node lúc này xem khối là một phần của lịch sử bất biến (trạng thái sổ cái đến slot đó được đóng băng). 

Trên thực tế, mức độ cam kết Finalized tương đương với “khối có ≥32 lượt xác nhận” khi so sánh với chuỗi PoW, nhưng Solana đạt được điều này qua các phiếu bầu bị khóa theo thời gian thay vì xác nhận bằng proof-of-work. Quy tắc 32 slot là hệ quả từ thiết kế của Tower BFT (thời gian khóa tăng gấp đôi đến 2^32) và cung cấp bảo đảm toán học về tính hoàn tất theo giả định chịu lỗi 1/3.

Lựa chọn fork và hoàn tác

Cơ chế đồng thuận của Solana liên tục đánh giá các fork. Validator sử dụng thuật toán chọn fork nặng nhất (dựa trên trọng số phiếu bầu theo cổ phần) để quyết định sẽ xây dựng trên fork nào. Nếu một khối chỉ được một nhóm validator xử lý và không nhận đủ phiếu bầu, một fork khác có thể ghi đè lên khối đó. Đây là lý do giao dịch Processed có thể bị loại. 

Sau khi một khối được 2/3 xác nhận, fork thay thế sẽ cần hơn 1/3 cổ phần ủng hộ để giành ưu thế. Điều này rất khó xảy ra và có thể đồng nghĩa với hành vi độc hại. 

Sau khi hoàn tất, một fork đảo ngược khối đó về cơ bản là bất khả thi nếu không xảy ra lỗi đồng thuận nghiêm trọng. Ngay cả khi mạng ngừng hoạt động hoặc bị tấn công, việc hoàn tác các slot đã hoàn tất sẽ đòi hỏi sự phối hợp ngoài các quy tắc của giao thức.

Tóm tắt cơ chế: Processed = khối đã được tạo (PoH) nhưng chưa nhận được nhiều phiếu bầu; Confirmed = phiếu bầu của cụm (Tower BFT) đạt đại đa số cho khối (đồng thuận lạc quan); Finalized = khối vẫn tồn tại dưới dạng “gốc” của chuỗi sau nhiều phiếu bầu hơn (tính hoàn tất tuyệt đối của đồng thuận). Thiết kế của Solana đảm bảo các khối Confirmed sẽ trở thành Finalized sau một khoảng trễ ngắn, vừa cung cấp xác nhận nhanh vừa đạt tính hoàn tất tuyệt đối sau cùng.

Trường hợp sử dụng từng mức độ cam kết dành cho nhà phát triển

Chọn mức độ cam kết phù hợp là điều rất quan trọng khi xây dựng trên Solana. Mỗi ứng dụng có yêu cầu khác nhau về tốc độ và độ chắc chắn. 

Dưới đây là các trường hợp sử dụng điển hình và phương pháp hay nhất cho từng mức:

Dùng Processed để nhận phản hồi tức thì và thực hiện tác vụ không quan trọng

Nhà phát triển có thể dùng mức cam kết Processed trong những trường hợp tốc độ là ưu tiên hàng đầu và có thể chấp nhận một phần rủi ro hoàn tác. Ví dụ: trong quá trình phát triển và kiểm thử, bạn có thể muốn được xác nhận tức thì rằng giao dịch đã được một validator nhận. 

Các ứng dụng giao diện người dùng (như ví hoặc trò chơi) có thể hiển thị giao dịch theo cơ chế lạc quan ngay khi giao dịch được xử lý để cải thiện trải nghiệm người dùng (ví dụ: hiển thị trạng thái “đang chờ xử lý”). 

Tuy nhiên, vì không có gì đảm bảo giao dịch Processed sẽ được giữ lại, mức này không được khuyến nghị cho các luồng trọng yếu trong môi trường production. Nếu sử dụng, chỉ nên áp dụng cho giao dịch có giá trị thấp hoặc không quan trọng, nơi việc hoàn tác tiềm ẩn không gây ra vấn đề nghiêm trọng.

Dùng Confirmed cho phần lớn giao dịch

Mức Confirmed thường là lựa chọn mặc định được khuyến nghị cho nhiều trường hợp sử dụng trên Solana. Mức này đảm bảo chắc chắn giao dịch thành công mà chỉ làm tăng độ trễ ở mức tối thiểu. 

Ví dụ: ứng dụng DeFi thực hiện hoán đổi token hoặc người dùng chuyển tiền thường dựa vào trạng thái Confirmed: sau khi giao dịch được xác nhận, ứng dụng có thể xem giao dịch là đã hoàn thành trong điều kiện bình thường. So với Processed, mức này giảm đáng kể nguy cơ giao dịch bị loại. Phương pháp hay nhất là dùng mức cam kết Confirmed, đặc biệt khi truy vấn blockhash gần đây và gửi giao dịch, vì mức này cân bằng tốt hơn giữa độ trễ và độ an toàn.

Dùng Finalized cho các giao dịch có giá trị cao và trọng yếu

Khi cần sự chắc chắn tuyệt đối, chẳng hạn như chuyển tài sản giá trị cao, cầu nối liên chuỗi hoặc xác nhận tiền gửi trên sàn giao dịch, nhà phát triển nên dùng mức cam kết Finalized. Mức này thường được dùng trong những trường hợp không thể chấp nhận dù chỉ một rủi ro hoàn tác rất nhỏ. 

Ví dụ: sàn giao dịch có thể chờ giao dịch đạt trạng thái Finalized trước khi ghi có khoản tiền gửi vào tài khoản người dùng, nhằm tránh mọi khả năng một đợt tái tổ chức sau đó có thể hủy khoản tiền gửi. 

Một trường hợp khác là sau một chuỗi giao dịch: bạn có thể đảm bảo trạng thái cuối cùng đã được hoàn tất trước khi xem một thao tác phức tạp là hoàn thành (ví dụ: trong quy trình kiểm toán hoặc quyết toán cần trạng thái sổ cái cuối cùng). 

Nhà phát triển cần lưu ý rằng yêu cầu mức cam kết Finalized sẽ làm tăng độ trễ và trong điều kiện mạng tải cao có thể làm tăng khả năng giao dịch hết hạn, vì về cơ bản bạn đang chờ băm của một khối cũ hơn được hoàn tất. Chỉ nên dùng Finalized một cách thận trọng cho những giao dịch quan trọng nhất, khi độ an toàn bổ sung xứng đáng với sự đánh đổi về độ trễ.

Tóm lại, Processed chủ yếu dành cho phản hồi nhanh và mục đích ngoài production, Confirmed là lựa chọn phù hợp cho hầu hết thao tác nhờ cân bằng giữa an toàn và hiệu năng, còn Finalized dành cho trường hợp thực sự cần đảm bảo tính hoàn tất bất chấp thời gian chờ. 

Nhiều ứng dụng sẽ kết hợp các mức: cập nhật giao diện ở trạng thái Processed, xem thao tác là hoàn thành ở trạng thái Confirmed và ghi nhật ký sau khi đạt Finalized.

Tác động đến độ tin cậy, hiệu năng và bảo mật của giao dịch

Việc chọn mức độ cam kết ảnh hưởng trực tiếp đến độ tin cậy (giao dịch có được giữ lại không?), hiệu năng (độ trễ) và bảo mật (rủi ro chi tiêu hai lần hoặc sự cố fork):

Độ tin cậy

Mức độ cam kết cao hơn làm tăng độ tin cậy rằng giao dịch sẽ được ghi lại vĩnh viễn. Giao dịch Finalized về cơ bản có độ tin cậy 100% về việc tồn tại trong sổ cái (trừ các sự kiện bất thường), trong khi giao dịch Confirmed có độ tin cậy rất cao nhưng chưa đạt 100%, còn giao dịch Processed có độ tin cậy thấp hơn. 

Như đã đề cập, khoảng ~5% giao dịch có thể bị loại nếu chỉ tính trạng thái Processed (do các fork liên tục thay đổi), trong khi Confirmed giảm rủi ro đó xuống gần 0%. 

Trong các ứng dụng trọng yếu, sử dụng mức cam kết Finalized loại bỏ rủi ro giao dịch nằm trong một fork về sau bị loại bỏ.

Hiệu năng (Độ trễ)

Có sự đánh đổi rõ ràng giữa tốc độ nhận xác nhận và mức độ cam kết. 

Xác nhận Processed gần như tức thì (trong thời gian tạo khối, thường dưới một giây). 

Confirmed làm tăng một chút độ trễ (khoảng một hoặc hai slot, có thể thêm ~0,5–1 giây) để thu thập phiếu bầu của validator—mức này vẫn rất nhanh và trên thực tế người dùng thường không nhận thấy. 

Finalized làm tăng độ trễ nhiều nhất vì giao dịch chỉ được báo cáo là đã hoàn tất sau khi khoảng hơn 30 khối tiếp theo được tạo. Thông thường mất ~10-20 giây để đạt tính hoàn tất. 

Trong thời gian mạng tắc nghẽn hoặc quá trình tạo khối chậm, độ trễ này có thể kéo dài hơn. Vì vậy, lạm dụng mức cam kết Finalized có thể làm chậm trải nghiệm người dùng và thông lượng. Nếu ứng dụng chờ trạng thái hoàn tất, ứng dụng phải tính đến thời gian bổ sung này. Tuy nhiên, điều đó không có nghĩa bản thân giao dịch mất nhiều thời gian hơn để thực thi trên chuỗi; nó chỉ có nghĩa máy khách chờ lâu hơn để đảm bảo giao dịch đã hoàn tất. Trong thời gian đó, Solana vẫn tiếp tục xử lý các giao dịch mới.

Thông lượng và thời điểm hết hạn

Một tác động tinh tế nhưng quan trọng liên quan đến thời điểm hết hạn giao dịch và việc sử dụng blockhash. Giao dịch Solana bao gồm một blockhash gần đây và chỉ hợp lệ trong ~150 slot sau blockhash đó. 

Nếu yêu cầu một blockhash finalized để ký giao dịch, blockhash đó sẽ cũ hơn (vì Finalized chậm hơn đầu chuỗi) và giao dịch sẽ còn ít slot hơn trước khi hết hạn. Điều này có thể làm tăng nguy cơ hết hạn nếu mạng tắc nghẽn và giao dịch không được xử lý nhanh chóng. 

Dùng blockhash mới hơn (Confirmed) sẽ mang lại khoảng thời gian dài hơn. Khuyến nghị chính thức là dùng Confirmed cho getLatestBlockhash để giảm nguy cơ hết hạn. 

Vì vậy, dùng Finalized cho preflight hoặc blockhash có thể làm giảm đôi chút thời gian để giao dịch được tiếp nhận, ảnh hưởng đến độ tin cậy khi tải cao. 

Nói ngắn gọn, mức cam kết Finalized có thể đánh đổi một phần khả năng duy trì hoạt động khi tải cao—bạn đạt được độ chắc chắn nhưng có thể phải chấp nhận nhiều giao dịch hết thời gian chờ hơn nếu mạng gần đạt công suất tối đa.

Bảo mật

Xét về bảo mật (ví dụ: ngăn chi tiêu hai lần và đảm bảo an toàn trước fork), Finalized là mức an toàn nhất. 

Sau khi hoàn tất, việc đảo ngược giao dịch sẽ đòi hỏi hơn một phần ba tổng cổ phần hành động độc hại, hành vi này nhiều khả năng sẽ bị phát hiện và trừng phạt. 

Confirmed rất an toàn trong điều kiện bình thường (kẻ tấn công phải tạo một fork xung đột và thuyết phục hơn 33% validator hỗ trợ fork đó sau khi đại đa số đã bỏ phiếu, điều này cực kỳ khó xảy ra nếu không có một cuộc tấn công phối hợp quy mô lớn). 

Tuy nhiên, về lý thuyết, Confirmed vẫn có một kịch bản trong đó một số validator (chỉ dưới 33%) giữ lại phiếu bầu hoặc fork đang ở đúng ngưỡng, khiến một khối Confirmed có thể trở thành khối mồ côi. Dù vậy, thiết kế của Solana (xác nhận lạc quan) giả định đa số trung thực để ngăn chặn điều này. 

Processed cung cấp mức bảo mật thấp nhất: trước khi có phiếu bầu, không có gì đảm bảo bất kỳ validator nào khác thậm chí biết về giao dịch. Một leader độc hại thậm chí có thể đưa giao dịch vào rồi không truyền khối đúng cách, v.v. 

Vì vậy, không nên dựa vào Processed cho bất kỳ xác nhận trọng yếu về bảo mật nào (mức này giống một “thông báo” rằng quá trình đã bắt đầu hơn). 

Tóm lại: Finalized > Confirmed > Processed xét về khả năng bảo vệ trước fork và chi tiêu hai lần.

Sử dụng mức cam kết khi đọc và ghi

Khi đọc trạng thái từ Solana (ví dụ: kiểm tra số dư tài khoản qua RPC), bạn cũng chỉ định một mức độ cam kết. Nếu dùng mức cam kết Processed cho thao tác đọc, bạn có thể thấy dữ liệu rất mới nhưng dữ liệu đó có thể đến từ một fork chưa được hoàn tất. Dùng Finalized cho thao tác đọc mang lại tính nhất quán tuyệt đối (trạng thái mà mọi bên đều đồng thuận), nhưng dữ liệu có thể chậm hơn một vài slot. Trong phần lớn trường hợp, dùng Confirmed cho truy vấn trạng thái là lựa chọn cân bằng tốt, tương tự như với giao dịch. Điều này đảm bảo bạn không đưa ra quyết định dựa trên một fork có thể bị hoàn tác. 

Đối với truy vấn ghi (tức gửi giao dịch), mức độ cam kết chủ yếu ảnh hưởng đến cách thư viện máy khách chờ xác nhận. Một mẫu phổ biến là gửi giao dịch với một preflightCommitment cụ thể (có thể mô phỏng TX dựa trên trạng thái mới nhất), sau đó dùng confirmTransaction với cùng mức độ cam kết. Nhà phát triển có thể chọn chờ xác nhận Finalized nếu cần.

Để minh họa bằng số liệu thực tế: dựa trên các phép đo gần đây, Solana xử lý một giao dịch trong ~0,4 giây, đạt trạng thái Confirmed trong ~0,6 giây và hoàn tất trong ~13 giây. 

Nếu ứng dụng của bạn, chẳng hạn ứng dụng thanh toán, không thể chờ ~13 giây cho mỗi giao dịch, hãy dùng Confirmed. Mức này vẫn cung cấp khả năng bảo mật mạnh. 

Nếu đang chuyển một lượng tài sản lớn giữa các chuỗi, bạn có thể chọn chờ đủ ~13 giây để hoàn toàn chắc chắn. Mặt khác, nếu đang xây dựng một sản phẩm mà tốc độ là yếu tố thiết yếu và có thể chấp nhận một chút rủi ro, chẳng hạn như cập nhật giao diện theo cơ chế lạc quan, bạn có thể dựa vào trạng thái Processed để mang lại trải nghiệm người dùng nhanh nhạy.

Kết luận

Các mức độ cam kết của Solana—Processed, Confirmed và Finalized—là tính năng cốt lõi cho phép nhà phát triển điều chỉnh sự cân bằng giữa tốc độ và độ chắc chắn cho từng giao dịch.

Processed cho kết quả tức thì nhưng chưa chắc chắn, Confirmed mang lại sự đảm bảo gần như hoàn tất trong vòng một hoặc hai giây (đủ cho hầu hết ứng dụng), còn Finalized cung cấp tính hoàn tất tuyệt đối sau một khoảng thời gian bổ sung. 

Bên trong hệ thống, các mức này tương ứng với tiến trình đồng thuận của Solana: từ khi một khối được tạo, được đại đa số bỏ phiếu, cho đến khi được đặt làm gốc trong sổ cái với thời gian khóa tối đa.

Khi xây dựng trên Solana, việc chọn đúng mức độ cam kết cho từng tác vụ là rất quan trọng:

• Dùng mức cam kết thấp hơn để nhận phản hồi nhanh hoặc thực hiện hành động không quan trọng
• Dùng Confirmed cho các thao tác tiêu chuẩn cần cả tốc độ lẫn độ an toàn
• Dùng Finalized cho những trường hợp chỉ có tính hoàn tất tuyệt đối mới được chấp nhận

Mỗi mức đều ảnh hưởng đến độ tin cậy khi đưa giao dịch vào chuỗi và thời gian bạn phải chờ. 

Bằng cách hiểu ý nghĩa kỹ thuật (66% phiếu bầu, 32 khối, fork, thời gian khóa) và tuân theo các phương pháp hay nhất mới nhất, nhà phát triển có thể đạt được hiệu năng mà Solana cam kết mà không phải hy sinh tính nhất quán và bảo mật của ứng dụng.

Tài nguyên bổ sung

• Tài liệu Solana – Cấu hình mức cam kết trạng thái, Bảng trạng thái cam kết
• Blog Helius – Cơ chế đồng thuận trên Solana (cơ chế đồng thuận và hoàn tất)