Chịu lỗi Byzantine (BFT, Byzantine Fault Tolerance) và PBFT

1. Khái quát

A. Định nghĩa

Chịu lỗi Byzantine (Byzantine Fault Tolerance, BFT) là khả năng của một hệ thống phân tán bảo đảm rằng các nút bình thường vẫn đạt đồng thuận về một giá trị đúng duy nhất và hệ thống hoạt động nhất quán, ngay cả khi một số nút không chỉ dừng lại mà còn gửi thông điệp sai, mâu thuẫn hoặc độc hại một cách tùy ý (lỗi Byzantine). PBFT (Practical Byzantine Fault Tolerance), do Castro·Liskov đề xuất năm 1999, là thuật toán tiêu biểu đạt được đồng thuận Byzantine với hiệu năng thực dụng dưới giả định đồng bộ bộ phận (partial synchrony).

BFT là dạng mạnh nhất của đồng thuận phân tán. Lỗi sập (Crash Fault) mà Paxos·Raft xử lý giả định rằng một nút "chỉ chết hoặc chậm đi chứ không nói dối", còn BFT giả định cả mô hình lỗi đối kháng trong đó "một nút có thể bị tấn công và gửi các giá trị khác nhau cho các nút khác nhau, thử chữ ký giả mạo, hoặc vi phạm giao thức một cách tinh vi". Vì vậy BFT đã trở thành công nghệ nền tảng cốt lõi nâng đỡ tính an toàn của các môi trường không tin cậy (permissionless·adversarial)—blockchain công khai, mạng thanh toán tài chính đa bên, thiết bị điều khiển hàng không·vũ trụ.

B. Bối cảnh ra đời và tính cần thiết

Gốc rễ lý thuyết của BFT là bài toán các tướng Byzantine (Byzantine Generals Problem), được Lamport·Shostak·Pease hình thức hóa năm 1982. Nhiều vị tướng mỗi người dẫn quân vây hãm thành của kẻ địch và phải cùng chọn giống nhau giữa "tấn công" và "rút lui", chỉ liên lạc bằng người đưa tin (thông điệp), trong khi một số tướng là kẻ phản bội có thể tung ra mệnh lệnh giả. Đây là thí nghiệm tư duy hỏi liệu các tướng trung thành có luôn đạt đến cùng một quyết định hay không, trừu tượng hóa câu hỏi trong hệ thống phân tán "liệu có thể đồng thuận ngay cả khi có lẫn những nút nói dối hay không". Bài báo này đã chứng minh toán học rằng chỉ với thông điệp truyền miệng (không chữ ký), để chịu được dù chỉ một kẻ phản bội thì tổng số tướng phải tối thiểu gấp ba lần cộng một, tức là điều kiện 3f+1.

Lý do bài toán này quan trọng trong thực tế là rõ ràng. Dòng Paxos·Raft chỉ giả định lỗi đơn giản sẽ sụp đổ tính an toàn trước cuộc tấn công mà một nút một cách độc hại gửi các log mâu thuẫn cho các follower khác nhau. Ở các lĩnh vực như thanh toán tài chính, bỏ phiếu điện tử, điều khiển hàng không—nơi chỉ một lần đồng thuận sai là chí mạng—không thể dùng tiền đề lạc quan "nút không nói dối". Đặc biệt sau Bitcoin năm 2008, nhu cầu các bên tham gia ẩn danh không tin nhau phải đồng thuận về trạng thái sổ cái mà không có quản trị viên trung tâm đã bùng nổ, nâng đồng thuận Byzantine từ một bài toán khó của giới học thuật lên công nghệ thiết yếu của giới công nghiệp.

Tuy nhiên các thuật toán BFT ban đầu bị chặn bởi bức tường "về lý thuyết thì khả thi nhưng hiệu năng phi thực tế". PBFT đã phá vỡ đúng điểm này. Bằng cách đưa vào đồng bộ bộ phận (giả định yếu rằng có cận trên cho độ trễ thông điệp) thay vì bất đồng bộ hoàn toàn, và hạ số lần trao đổi thông điệp từ mức hàm mũ xuống mức đa thức, nó đã chứng minh thông lượng áp dụng được cho một hệ thống tập tin thực (BFS), giành được cái tên "Practical".

C. Các tính chất cốt lõi mà BFT bảo đảm

• Đồng thuận (Agreement): Mọi nút trung thực thực thi cùng một yêu cầu tại cùng một số thứ tự. Dù nút Byzantine phát tán các giá trị khác nhau, kiểm chứng chéo vẫn lọc bỏ chúng.
• Thứ tự toàn phần (Total Order): Các yêu cầu được áp dụng theo cùng một thứ tự tại mọi nút trung thực, nên trạng thái của máy trạng thái sao chép không phân kỳ.
• Toàn vẹn (Integrity): Chỉ yêu cầu của client trung thực mới được thực thi, đúng một lần (chặn tấn công giả mạo·phát lại).
• Nhất quán bên ngoài (Linearizability): Theo góc nhìn của client, hệ thống đáp ứng như một máy chủ đúng duy nhất.
• Tính sống (Liveness): Khi mạng ổn định (đồng bộ bộ phận) yêu cầu trung thực chắc chắn được xử lý—nhưng được bảo đảm phụ thuộc vào tính an toàn.

2. Đặc tính của lỗi Byzantine và nguyên lý quorum

Điểm khác biệt căn bản giữa lỗi Byzantine và lỗi sập nằm ở chỗ không có ràng buộc nào lên hành vi của nút lỗi. Nút lỗi sập chỉ thể hiện một dạng thất bại duy nhất—"không phản hồi"—nên các nút còn lại có thể tin rằng "giá trị đã phản hồi là trung thực". Ngược lại, nút Byzantine vẫn phản hồi nhưng nội dung có thể sai, và còn có thể thực hiện hành vi hai mặt (equivocation)—gửi các giá trị khác nhau tùy người nhận. Do đó, thay vì "tin giá trị gửi đến", BFT áp dụng cấu trúc kiểm chứng đa trùng "chỉ tin giá trị mà đủ nhiều nút cùng làm chứng giống nhau".

Cốt lõi của cấu trúc này là nguyên lý quorum 3f+1. Để giữ tính an toàn khi tối đa f trong tổng số N nút là Byzantine thì phải có N ≥ 3f+1. Giải thích trực quan, quorum cần cho đồng thuận là 2f+1, và như vậy thỏa mãn đồng thời hai điều. Thứ nhất, dù f nút Byzantine từ chối phản hồi, vẫn có thể lấp đầy quorum bằng f+1 trong số 2f+1 nút bình thường, nên tiến triển (liveness) được bảo đảm. Thứ hai, hai quorum khác nhau bất kỳ (mỗi cái 2f+1) tất yếu chồng lấp ít nhất f+1 nút trong N=3f+1, và vì phần giao đó chứa ít nhất một nút trung thực, việc hai quyết định mâu thuẫn được chốt đồng thời bị chặn tận gốc, nên tính an toàn (safety) được giữ. Ví dụ f=1 cần tối thiểu 4 nút, f=2 cần 7 nút, đòi hỏi nhiều dư thừa hơn so với 2f+1 của lỗi sập (3 nút cho f=1).

flowchart TB
    subgraph CFT["Chịu lỗi sập (CFT, N=2f+1)"]
      direction TB
      C1["Nút bình thường"] --- C2["Nút bình thường"]
      C2 --- C3["Nút im lặng (dừng)"]
      CNOTE["Giả định: nút chỉ dừng, không nói dối"]
    end
    subgraph BFT["Chịu lỗi Byzantine (BFT, N=3f+1)"]
      direction TB
      B1["Nút bình thường"] --- B2["Nút bình thường"]
      B2 --- B3["Nút bình thường"]
      B3 --- B4["Nút độc hại (hành vi hai mặt)"]
      BNOTE["Giả định: nút có thể gửi thông điệp sai·mâu thuẫn"]
    end
    CFT -->|"Tăng cường mô hình đe dọa"| BFT

Hình trên cho thấy ngay cả để chịu cùng f=1, CFT cần 3 nút còn BFT cần 4 nút. Một bản sao thêm vào là cái giá để chuẩn bị cho "khả năng nói dối", và vì lẽ đó BFT mang một đánh đổi căn bản: cung cấp tính an toàn mạnh hơn nhưng số nút·chi phí thông điệp·độ trễ lớn hơn. Điểm rẽ nhánh để chọn CFT chi phí thấp bên trong miền tin cậy (trung tâm dữ liệu nội bộ) so với BFT trong môi trường không tin nhau (blockchain công khai) được phân chia ngay tại đây.

Mặt khác, bài báo gốc về bài toán các tướng Byzantine để lại một nhận thức quan trọng rằng sự hiện diện hay vắng mặt của xác thực thông điệp (chữ ký) làm thay đổi giới hạn chịu lỗi. Trong mô hình thông điệp truyền miệng (oral message) không chữ ký, kẻ phản bội có thể nói "tấn công cho A, rút lui cho B" mà không có cách nào truy vết sau đó, nên 3f+1 là bắt buộc nghiêm ngặt. Nhưng nếu gắn một chữ ký số không thể giả mạo vào thông điệp, thì nếu kẻ phản bội đổi nội dung trong lúc truyền, chữ ký sẽ vỡ và bị phát hiện ngay, nên về lý thuyết đồng thuận trở nên khả thi với ít nút hơn. Chính vì vậy BFT hiện đại kể cả PBFT đều không ngoại lệ gắn chữ ký hoặc MAC vào mọi thông điệp giao thức, và chữ ký vừa là "thiết bị phát hiện nói dối" của BFT vừa đồng thời là nút thắt cổ chai hiệu năng. Tuy nhiên chữ ký không ngăn được hành vi hai mặt (equivocation)—cuộc tấn công mà cùng một bên ký gắn chữ ký hợp lệ cho mỗi thông điệp trong hai thông điệp khác nhau—nên rốt cuộc kiểm chứng chéo phiếu bầu qua quorum 3f+1 vẫn là thiết bị an toàn cốt lõi.

Một trục khác bắt buộc phải phân biệt trong thiết kế BFT là tính an toàn (Safety) và tính sống (Liveness). Tính an toàn nghĩa là "hai nút trung thực khác nhau không bao giờ chốt các giá trị khác nhau tại cùng một số thứ tự" (điều xấu không bao giờ xảy ra), còn tính sống nghĩa là "một yêu cầu rốt cuộc chắc chắn được xử lý" (điều tốt rốt cuộc xảy ra). Theo định lý bất khả thi FLP, hai điều này không thể được bảo đảm tất định đồng thời trong môi trường bất đồng bộ hoàn toàn, nên PBFT đã chọn thiết kế không bao giờ hy sinh tính an toàn trong bất kỳ trường hợp nào và chỉ giao tính sống cho giả định đồng bộ bộ phận (sự tồn tại của cận trên độ trễ thông điệp). Nghĩa là nếu mạng cực kỳ bất ổn, PBFT có thể dừng (mất tính sống) nhưng không bao giờ ra quyết định mâu thuẫn (giữ tính an toàn). Triết lý "an toàn trước hết" này là nguyên tắc căn bản khiến BFT đáng tin cậy ở các lĩnh vực như tài chính·điều khiển nơi đồng thuận sai là chí mạng.

3. Giao thức đồng thuận ba pha của PBFT

PBFT chia các nút thành primary (leader) và backup, và trong một cấu hình (view) nhất định, primary đề xuất thứ tự của các yêu cầu còn các backup kiểm chứng chéo và chốt lại. Đồng thuận trong khoảng hoạt động bình thường (normal-case) được thực hiện bằng trao đổi thông điệp ba pha Pre-prepare → Prepare → Commit, và mỗi pha tích lũy bằng chứng rằng "một số lượng nút đủ lớn đã thấy cùng một nội dung". Tóm tắt trong một cái nhìn các bảo đảm mà mỗi pha giành được như sau.

• Pre-prepare: Primary đề xuất số thứ tự (n) → cố định ứng viên cho "yêu cầu ở vị trí n trong view này".
• Prepare (thu thập 2f+1): Bảo đảm không yêu cầu khác nào có thể được prepared tại cùng view·số thứ tự (đồng thuận thứ tự bậc nhất trong cùng view).
• Commit (thu thập 2f+1): Bảo đảm quyết định được giữ lại ngay cả sau khi đổi view (tính chốt xuyên view) → thực thi·phản hồi.

A. Pre-prepare (chuẩn bị trước). Primary nhận yêu cầu của client gán cho yêu cầu đó một số thứ tự (sequence number) n, và quảng bá đến tất cả các backup kèm chữ ký cùng với view v hiện tại·digest của yêu cầu. Mục đích của pha này là cố định một đề xuất thứ tự rằng "trong view này, vị trí n chứa yêu cầu này". Backup chấp nhận nó sau khi kiểm chứng tính hợp lệ của chữ ký·view·khoảng số thứ tự. Dù primary có độc hại, kiểm chứng chéo ở pha kế tiếp vẫn lọc bỏ mâu thuẫn.

B. Prepare (chuẩn bị). Mỗi backup đã chấp nhận Pre-prepare quảng bá thông điệp Prepare cho cùng ⟨v, n, digest⟩ đến tất cả các nút kèm chữ ký của mình. Khi một nút, kể cả chính nó, thu thập 2f+1 Prepare khớp nhau (do các nút khác nhau ký), nó đạt đến "trạng thái prepared". Khi điều kiện này thỏa, giữa các nút trung thực được bảo đảm rằng không yêu cầu khác nào có thể được prepared tại cùng view·cùng số thứ tự. Nghĩa là pha Prepare giành được "đồng thuận bậc nhất về thứ tự", nhưng chưa bảo đảm liệu quyết định này có sống sót khi view thay đổi hay không.

C. Commit (chốt). Nút đã đạt prepared cũng quảng bá thông điệp Commit đến toàn thể, và khi thu thập 2f+1 Commit khớp nhau thì vào trạng thái "committed-local", thực thi (execute) yêu cầu trên máy trạng thái sao chép rồi phản hồi client. Client tin kết quả khi nhận được f+1 phản hồi giống nhau từ các nút khác nhau (vì ít nhất một trong f+1 là trung thực). Lý do cần thêm pha Commit là vì chỉ với Prepare, quyết định có thể bị lật khi đổi view (view change). Commit trao tính chốt rằng "quyết định này được giữ lại ngay cả khi view thay đổi".

sequenceDiagram
    participant C as Client
    participant P as Primary (nút0)
    participant B1 as Backup1
    participant B2 as Backup2
    participant B3 as Backup3 (có thể lỗi)
    C->>P: yêu cầu (request)
    Note over P,B3: 1) Pha Pre-prepare
    P->>B1: Pre-prepare(v,n,digest)
    P->>B2: Pre-prepare(v,n,digest)
    P->>B3: Pre-prepare(v,n,digest)
    Note over P,B3: 2) Pha Prepare (thu thập 2f+1)
    B1->>P: Prepare
    B1->>B2: Prepare
    B2->>P: Prepare
    B2->>B1: Prepare
    Note over P,B3: 3) Pha Commit (thu thập 2f+1)
    P->>B1: Commit
    B1->>B2: Commit
    B2->>P: Commit
    Note over P,B2: đạt committed-local → thực thi
    P-->>C: phản hồi
    B1-->>C: phản hồi
    B2-->>C: phản hồi (tin khi nhận f+1 giống nhau)

D. Checkpoint và thu gom rác. Khi đồng thuận tích lũy, log thông điệp mỗi nút lưu giữ phình to vô hạn, nên PBFT tạo một checkpoint tại các số thứ tự nhất định để chia sẻ ảnh chụp trạng thái và loại bỏ an toàn log trước điểm đó. Một khi checkpoint ổn định (stable checkpoint)—mà 2f+1 nút đã ký cùng một digest trạng thái—được bảo đảm, các quyết định đến điểm đó đông cứng thành sự thật không thể đảo ngược và bộ nhớ được thu hồi. Checkpoint không chỉ là tối ưu hiệu năng mà còn là một thành phần của tính an toàn, làm điểm tham chiếu cho "tiếp nối từ đâu" khi đổi view.

Nếu primary không phản hồi hoặc ép một thứ tự sai, các backup kích hoạt đổi view (View Change) sau khi bộ đếm thời gian hết hạn. Khi 2f+1 nút đồng ý đổi view, primary kế tiếp (nút theo v+1) được bầu, và primary mới kế thừa các yêu cầu đã prepared·committed đến ngay trước đó—kèm bằng chứng (chứng minh prepared)—để bảo đảm rằng các quyết định đã chốt không bị mất. Nhờ cơ chế này, một primary độc hại không thể chặn vĩnh viễn tiến triển tổng thể trong PBFT. Tuy nhiên đồng thuận khoảng bình thường có độ phức tạp thông điệp O(N²) (mọi nút trao đổi Prepare·Commit với nhau), nên có giới hạn là khả năng mở rộng sụt mạnh một khi số nút vượt vài chục.

4. So sánh các mô hình đồng thuận và các trường hợp áp dụng

Trong thực tế, "dùng đồng thuận nào" là một quyết định thiết kế xuất phát không phải từ con số hiệu năng mà từ giả định tin cậy. Ngay cả cùng một đồng thuận phân tán, nếu mô hình lỗi được giả định khác nhau thì số nút cần thiết·lượng thông điệp·bản chất của tính chốt thay đổi toàn bộ. Dưới đây so sánh ba mô hình tiêu biểu, tập trung không phải vào bản thân con số mà vào vì sao những con số đó được định như vậy.

Để dùng BFT đúng cách, phải hiểu rõ khác biệt với đồng thuận lỗi sập, và với đồng thuận xác suất (PoW) của blockchain công khai. Bảng dưới so sánh các khác biệt cốt lõi, nhưng vì sao mỗi khác biệt phát sinh mới là điều quan trọng. CFT có ít nút và độ trễ thấp hơn BFT là vì nó "không giả định nút nói dối", còn PoW có khả năng mở rộng người tham gia lớn hơn BFT nhưng đổi lại tính chốt (finality) mang tính xác suất là vì nó thay đồng thuận bằng cạnh tranh hash thay vì bỏ phiếu.

Phân loại	Lỗi sập (Paxos/Raft)	PBFT (BFT tất định)	PoW (BFT xác suất)
Mô hình lỗi	chỉ dừng·trễ	tùy ý·độc hại (nói dối)	tùy ý·độc hại (mở)
Giới hạn chịu lỗi	f < N/2 (N=2f+1)	f < N/3 (N=3f+1)	sức mạnh hash < 50%
Tính chốt	tức thì (tất định)	tức thì (tất định)	xác suất (tích lũy xác nhận)
Độ phức tạp thông điệp	O(N)	O(N²)	thấp (quảng bá)
Khả năng mở rộng nút	vài~vài chục	vài chục (giới hạn rõ)	hàng nghìn~hàng vạn
Áp dụng tiêu biểu	etcd·ZooKeeper	Hyperledger Fabric·Zilliqa	Bitcoin·Ethereum thời kỳ đầu

Cụ thể hóa phép tính quorum bằng con số nhỏ làm khác biệt trở nên rõ. Khi vận hành với N=100 nút như một blockchain công khai, BFT có thể chịu tối đa f=33 nút độc hại (100 ≥ 3×33+1) và mọi quyết định cần tối thiểu 67 (2f+1) phiếu bầu có chữ ký. Ngược lại, CFT có thể chịu f=49 lỗi dừng với cùng 100 nút—"tỷ lệ" chịu lỗi cao hơn—nhưng điều này chỉ thành lập trên tiền đề mạnh rằng "không có nút độc hại". Nghĩa là BFT chịu tỷ lệ lỗi nhỏ hơn (dưới 1/3) nhưng đổi lại cung cấp ưu thế về chất là giữ được tính an toàn ngay cả khi các lỗi đó là hành vi tùy ý bao gồm nói dối. Nhà thiết kế phải hỏi trước tiên không phải "chịu được bao nhiêu lỗi" mà "phải chịu loại lỗi nào".

Lấy một trường hợp cụ thể, blockchain có cấp phép (permissioned) Hyperledger Fabric có số tổ chức tham gia hạn chế với danh tính đã xác minh, nên dùng orderer dòng PBFT (hoặc Raft) để có tính chốt tức thì và thông lượng cao. Ngược lại, Bitcoin kiểu mở có người tham gia ẩn danh lên tới hàng vạn, khiến bỏ phiếu O(N²) bất khả thi, nên chọn PoW và đổi lại chấp nhận "tính chốt xác suất", nơi xác suất một khối bị lật giảm theo hàm mũ theo thời gian. Mặt khác, trong lĩnh vực hàng không, máy tính điều khiển bay của Boeing 777 chuẩn bị cho lỗi cảm biến·tính toán bằng cấu trúc đa số ba lần (kháng Byzantine)—nên khái niệm BFT đã thực sự được áp dụng vào các hệ thống an toàn-trọng yếu (safety-critical) từ lâu trước blockchain. Như vậy ba trục "số người tham gia·giả định tin cậy·tính chốt yêu cầu" quyết định dùng đồng thuận nào.

5. Chuyên sâu — BFT mở rộng và xu hướng mới nhất

Nút thắt cổ chai O(N²) của PBFT là thách thức lớn nhất trong nghiên cứu BFT suốt hơn một thập kỷ qua, và cùng với sự trỗi dậy của blockchain, BFT thế hệ mới khắc phục nó đã tuôn ra. Thứ nhất, Tendermint (nay là CometBFT) đơn giản hóa PBFT, luân phiên leader mỗi khối, cung cấp tính chốt tức thì, và đã được nhiều chuỗi trong hệ sinh thái Cosmos chọn làm động cơ đồng thuận. Thứ hai, HotStuff (2019) hạ độ phức tạp thông điệp xuống O(N) và tái cấu trúc mọi pha thành giao tiếp tuyến tính lấy leader làm trung tâm, tuyến tính hóa cả chi phí đổi leader. HotStuff được kế thừa bởi LibraBFT (DiemBFT) của Libra/Diem do Meta thúc đẩy và bởi Aptos·Flow v.v., trở thành thiết kế chuẩn trên thực tế của các chuỗi bằng chứng cổ phần (PoS) hiện đại.

Các dòng BFT thế hệ mới tiêu biểu có thể tóm tắt như sau.

• Tendermint / CometBFT: Đơn giản hóa PBFT + luân phiên leader mỗi khối, tính chốt tức thì. Được Cosmos·Binance Chain v.v. chọn dùng.
• HotStuff / DiemBFT: Giao tiếp tuyến tính (O(N)) và tuyến tính hóa đổi leader, nâng thông lượng bằng pipelining. Được Aptos·Flow·Diem kế thừa.
• Casper FFG + Gasper: BFT lấy mẫu ủy ban kết hợp bằng chứng cổ phần, ức chế hành vi độc hại bằng slashing. Ethereum PoS.
• HoneyBadgerBFT / dựa trên DAG (Narwhal·Bullshark): BFT bất đồng bộ không giả định timeout, duy trì tính sống ngay cả dưới tấn công mạng.

Thứ ba, bản thân bằng chứng cổ phần (PoS) kết hợp với BFT để né vấn đề khả năng mở rộng. Casper FFG và Gasper của Ethereum rút ngẫu nhiên một ủy ban từ hàng trăm nghìn validator để tiến hành bỏ phiếu BFT, và áp hình phạt slashing lên hành vi độc hại với cổ phần (stake) làm thế chấp, ức chế hành vi Byzantine bằng chi phí kinh tế. Đây là một thể lai kết hợp "bỏ phiếu mật mã học (BFT) + động lực kinh tế (stake)", một trường hợp phá vỡ giới hạn số nút của BFT truyền thống bằng lấy mẫu validator. Thứ tư, BFT bất đồng bộ như HoneyBadgerBFT, bảo đảm an toàn·tính sống ngay cả trong mạng bất đồng bộ hoàn toàn, đã xuất hiện, và đồng thuận bền vững hoạt động không cần giả định timeout đang được nghiên cứu. Xu hướng này được coi là đặc biệt quan trọng trong thiết kế Web3·CBDC (tiền kỹ thuật số ngân hàng trung ương) vốn theo đuổi đồng thời "tham gia quy mô lớn không cần tin cậy" và "tính chốt tức thì".

6. Điểm cần cân nhắc và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)

• Chọn đồng thuận khớp với mô hình đe dọa: Bên trong miền tin cậy (cụm nội bộ, etcd) nên chọn CFT (Raft) chi phí thấp, còn trong môi trường không tin nhau·mở (consortium·blockchain công khai) nên chọn BFT. Áp dụng BFT quá mức gây chi phí nút·độ trễ không cần thiết, còn áp dụng CFT thiếu gây sụp đổ an toàn chí mạng, nên ghi chép tường minh mô hình lỗi từ sớm trong thiết kế là nhiệm vụ quản trị cốt lõi.
• Đánh đổi khả năng mở rộng-tính chốt: Do bản chất O(N²) của PBFT, thông lượng sụt mạnh một khi số nút vượt vài chục. Nếu cần quy mô lớn, hãy giảm lượng giao tiếp bằng dòng HotStuff (O(N)) hoặc lấy mẫu ủy ban (bỏ phiếu bởi tập con validator), nhưng vì lấy mẫu có thể làm yếu tính an toàn theo xác suất, phải kiểm chứng định lượng kích thước ủy ban·chu kỳ bầu lại.
• Quản lý khóa và hiệu năng chữ ký: Vì BFT đòi hỏi chữ ký số·MAC trên mọi thông điệp, rò rỉ khóa đồng nghĩa với việc nút hóa Byzantine. Một thiết kế bảo vệ khóa ký bằng HSM·chữ ký ngưỡng (threshold signature)·xoay khóa, và bù chi phí kiểm chứng bằng chữ ký tổng hợp BLS v.v., sẽ quyết định tính ổn định vận hành.
• Giả định mạng và bảo đảm tính sống: Vì tính sống của PBFT phụ thuộc vào đồng bộ bộ phận (sự tồn tại của cận trên độ trễ), một cuộc tấn công mạng kéo dài (trễ·chia cắt) có thể làm dừng tiến triển. Hãy phòng vệ tính sống bằng chống DDoS·đa đường·tinh chỉnh bộ đếm thời gian đổi view, và xem xét dòng HoneyBadgerBFT nếu cần kháng bất đồng bộ hoàn toàn.
• Triển vọng kết hợp với động lực kinh tế: Trong BFT dựa trên PoS, thiết kế slashing·phần thưởng trở thành một phần của tính an toàn. Ức chế hành vi Byzantine bằng thiết kế cơ chế bao gồm cả động lực kinh tế, chứ không chỉ các thiết bị an toàn mật mã học, sẽ trở thành năng lực thiết yếu của CBDC·tài chính phi tập trung, và Kỹ sư chuyên nghiệp phải có góc nhìn thiết kế tích hợp bao trùm mật mã·phân tán·cơ chế kinh tế.
• Chiến lược triển khai theo giai đoạn và kiểm chứng: Trước khi triển khai BFT toàn diện, hãy tái hiện các kịch bản đổi view·primary độc hại bằng kỹ thuật hỗn loạn (Chaos Engineering)·tiêm lỗi để kiểm chứng định lượng tính an toàn·tính sống, và đo trước các nút thắt cổ chai về phân tán địa lý nút·lệch đồng hồ·thông lượng chữ ký. Đặc biệt, do đặc tính BFT "nhanh ở khoảng bình thường nhưng độ trễ tăng vọt ở khoảng bị tấn công", một thiết kế thận trọng định cỡ dung lượng theo độ trễ trường hợp xấu nhất (worst-case) chứ không phải hiệu năng thường ngày là then chốt cho vận hành ổn định.

Tài liệu tham khảo

• Lamport, Shostak, Pease, "The Byzantine Generals Problem", ACM TOPLAS, 1982. https://lamport.azurewebsites.net/pubs/byz.pdf
• Castro, Liskov, "Practical Byzantine Fault Tolerance", OSDI, 1999. https://pmg.csail.mit.edu/papers/osdi99.pdf
• Yin et al., "HotStuff: BFT Consensus with Linearity and Responsiveness", PODC, 2019. https://arxiv.org/abs/1803.05069
• Buchman, "Tendermint: Byzantine Fault Tolerance in the Age of Blockchains", 2016. https://tendermint.com/

---

Tóm tắt một câu: BFT là công nghệ chịu lỗi mạnh nhất, giữ được đồng thuận bằng quorum N≥3f+1 và kiểm chứng chéo đa trùng ngay cả trong môi trường đối kháng nơi các nút gửi thông điệp nói dối·mâu thuẫn; ba pha Pre-prepare·Prepare·Commit cùng đổi view của PBFT là nguyên mẫu thực dụng của nó, ngày nay đã mở rộng sang HotStuff·PoS để trở thành nền tảng của niềm tin trong blockchain·CBDC.