Cảm ơn Matheus Franco đã đánh giá.
Tóm tắt
Sự cố trên mạng thử nghiệm Holesky đã tiết lộ một lỗ hổng nghiêm trọng trong cơ chế đồng thuận của Ethereum: khi đa số các trình xác thực xác nhận sai trạng thái chuỗi không hợp lệ do lỗi máy khách, mạng sẽ rơi vào trạng thái không thể phục hồi, đòi hỏi phải có những rò rỉ do sự không hoạt động gây thiệt hại để khôi phục tính cuối cùng. Bài viết này đề xuất rằng Công nghệ Trình xác thực Phân tán (DVT) với các nhà điều hành không đồng nhất có thể cung cấp một cơ chế bảo vệ chống lại các kịch bản phân nhánh đa số như vậy. Bằng cách giới thiệu xác thực điểm kiểm tra ở cấp độ cụm DVT, chúng tôi chứng minh cách các nhà điều hành trình xác thực đa dạng có thể chọn lọc không xác nhận các nhánh độc hại, ngăn chặn việc hoàn tất mà không cần các sự kiện cắt giảm lớn. Cơ chế này đánh đổi sự biện minh ngắn hạn cho các nhánh không chính xác để đổi lấy sự an toàn lâu dài của mạng, cho phép thiểu số trung thực cuối cùng chiếm ưu thế thông qua sự đồng thuận xã hội và rò rỉ do sự không hoạt động.
1. Lựa chọn thiết kế cơ bản của Ethereum: Ưu tiên tính khả thi hơn tính an toàn
Đây là phần tóm tắt về thiết kế ưu tiên tính hoạt động hơn tính an toàn của Ethereum và mối liên hệ của nó với sự rò rỉ dữ liệu do không hoạt động. Người đọc đã nắm rõ thông tin có thể bỏ qua phần này và chuyển sang phần tiếp theo.
1.1 Định lý CAP và sự đồng thuận trên Blockchain
Thiết kế cơ chế đồng thuận của Ethereum phản ánh một lựa chọn có chủ ý ở cấp độ cơ bản: khi mạng lưới phải lựa chọn giữa tính an toàn (ngăn ngừa các trạng thái hoàn thiện xung đột) và tính khả thi (tiếp tục tạo ra và hoàn thiện các khối), Ethereum ưu tiên tính khả thi . Điều này có nghĩa là nó cho phép các nhánh khác nhau cạnh tranh để được mạng lưới chấp nhận.
Sự lựa chọn này bắt nguồn từ Định lý CAP . Định lý CAP phát biểu rằng một hệ thống phân tán không thể đồng thời đảm bảo Tính nhất quán (an toàn), Tính khả dụng (hoạt động liên tục) và Khả năng chịu lỗi phân vùng. Ethereum, với tư cách là một hệ thống phi tập trung phải chịu được sự phân vùng mạng, không thể đạt được cả ba điều này. Ethereum đã chọn hy sinh tính nhất quán trong các sự cố nghiêm trọng để đảm bảo mạng vẫn hoạt động.
1.2 Lý do: Sự rò rỉ do không hoạt động
Ethereum đã chính thức hóa lựa chọn này thông qua cơ chế rò rỉ do không hoạt động . Như đã nêu trong đặc tả Gasper của Ethereum, cơ chế rò rỉ do không hoạt động được kích hoạt khi chuỗi không hoàn tất quá bốn kỷ nguyên. Sau khi được kích hoạt, nó sẽ dần dần trừng phạt các trình xác thực không chứng thực cho nhánh đa số, bất kể nhánh đa số đó có hợp lệ hay không. Phải mất 4986 kỷ nguyên, hay 3 tuần, để một trình xác thực có 32 ETH bị loại khỏi hệ thống.
Lý luận của giao thức này là tính khả dụng tạm thời của mạng tốt hơn là sự an toàn vĩnh viễn . Nếu xảy ra sự phân vùng và đa số các trình xác thực nằm ở một phía, việc rò rỉ thông tin do không hoạt động sẽ đảm bảo phía đó cuối cùng có thể hoàn tất và phục hồi. Nhóm thiểu số trung thực ở phía bên kia sẽ phải chịu hình phạt, nhưng cuối cùng họ có thể phục hồi thông qua sự đồng thuận cộng đồng (một hard fork) và tham gia lại mạng.
2. Vụ việc Holesky: Một nghiên cứu điển hình về sự thất bại trong việc đạt được sự đồng thuận khi các giả định bị phá vỡ
2.1 Chuyện gì đã xảy ra
Vào ngày 25 tháng 2 năm 2025, mạng thử nghiệm Ethereum Holesky đã kích hoạt bản nâng cấp Pectra. Chỉ vài giờ sau, mạng lưới gặp phải một lỗi nghiêm trọng: ba máy khách lớp thực thi chính—Geth, Nethermind và Besu—bị cấu hình sai với địa chỉ hợp đồng gửi tiền không chính xác. Các máy khách bị ảnh hưởng không thể theo dõi chính xác các khoản tiền gửi của trình xác thực, tạo ra sự không nhất quán trong cơ chế đồng thuận. Do đó, lớp thực thi và lớp đồng thuận trở nên không đồng bộ. Phần lớn các trình xác thực bắt đầu chứng thực các khối trên chuỗi không hợp lệ, không thể phát hiện ra lỗi trong trạng thái thực thi cơ bản.
Kết quả là quá trình hoàn tất giao dịch thất bại không thể khắc phục . Để mạng lưới phục hồi, các trình xác thực đã chứng thực sai chuỗi phải đối mặt với các hình phạt cắt giảm. Cơ chế rò rỉ do không hoạt động phải từ từ rút bớt cổ phần của các trình xác thực ngoại tuyến cho đến khi chuỗi chính xác giành lại được đa số tuyệt đối hai phần ba — một quá trình mất khoảng ba tuần . Mặc dù thực tế là các máy khách thiểu số (một máy khách thực thi) vẫn tiếp tục tạo ra các khối hợp lệ, nhưng sự chứng thực của đa số tuyệt đối đã ngăn cản quá trình hoàn tất trên chuỗi chính xác.
2.2 Vi phạm giả định đa số trung thực
Giao thức đồng thuận của Ethereum đưa ra một giả định bảo mật cơ bản: giả định đa số trung thực . Tính xác thực cuối cùng của Casper FFG yêu cầu hai phần ba số người xác thực chứng thực cùng một điểm kiểm tra. Tính khả dụng (sản xuất khối) dựa trên đa số đơn giản tuân theo quy tắc lựa chọn nhánh. Giao thức được thiết kế để hoàn thiện trạng thái một cách chính xác miễn là ít hơn một phần ba số người xác thực là Byzantine (ác ý hoặc sai sót).
Sự cố Holesky đã vi phạm giả định này. Lỗi này khiến các trình xác thực trung thực hành xử lý có tính chất đối kháng với mạng lưới. Đa số máy khách trở nên rối loạn, bỏ phiếu cho một trạng thái không hợp lệ.
Điều quan trọng cần hiểu là các đặc tính an toàn của Ethereum phụ thuộc vào việc có ít hơn một phần ba số trình xác thực Byzantine . Khi ba máy khách chiếm đa số đều gặp lỗi theo cùng một cách, chúng chiếm hơn một phần ba mạng lưới, phá vỡ các đảm bảo an toàn.
2.3 Tại sao sự thiếu hoạt động dẫn đến rò rỉ thông tin lại gây hại
Khi mạng lưới bước vào trạng thái phân nhánh, quá trình phục hồi đòi hỏi Ethereum phải hy sinh tính an toàn để đổi lấy tính hoạt động liên tục. Cơ chế rò rỉ do không hoạt động sẽ dần dần làm giảm số dư hiệu quả của các trình xác thực không chứng thực cho nhánh đa số. Quá trình này tiếp tục cho đến khi các trình xác thực không chứng thực có số dư quá thấp đến mức chúng bị loại khỏi tập hợp trình xác thực, cho phép các trình xác thực còn lại (chính xác) đạt được hai phần ba.
Tuy nhiên, cơ chế này lại gây ra nhiều tác hại :
- Thiệt hại kinh tế : Các trình xác thực trên nhánh đa số (sai) sẽ bị phạt, mất ETH vĩnh viễn. Các trình xác thực trên nhánh thiểu số (đúng) sẽ bị phạt vì sự không hoạt động rõ ràng.
- Rủi ro phân nhánh : Nếu tình trạng rò rỉ do không hoạt động kéo dài đủ lâu, cả hai phân vùng có thể riêng biệt đạt được hai phần ba cổ phần và hoàn thiện các phiên bản lịch sử độc lập.
- Thời gian khôi phục : Toàn bộ quá trình kéo dài nhiều tuần, trong thời gian đó mạng lưới không thể hoàn tất các giao dịch hoặc đảm bảo sự ổn định cho người dùng và ứng dụng.
3. Vấn đề DVT PBFT: Tại sao xác thực dựa trên số lượng thành viên tối thiểu đơn giản lại thất bại
3.1 Phương pháp tiếp cận DVT đơn giản
Công nghệ xác thực phân tán chia khóa ký của một trình xác thực duy nhất cho nhiều nhà điều hành độc lập bằng cách sử dụng mật mã ngưỡng và chia sẻ bí mật. Mỗi nhà điều hành nắm giữ một phần khóa và tham gia vào cơ chế đồng thuận chịu lỗi Byzantine (BFT) để đạt được thỏa thuận về nhiệm vụ cần thực hiện.
Trong một thiết kế DVT đơn giản, một khi nhóm BFT đạt được sự đồng thuận về một hành động, tất cả các nhà điều hành sẽ ký và gửi bản xác nhận. Logic rất đơn giản: nếu nhóm BFT đạt được sự đồng thuận cần thiết, quyết định đó là đúng .
Tuy nhiên, lối tư duy này có thể khiến chúng ta trở thành nạn nhân của bẫy phân nhánh đa số .
3.2 Đặc tính bẫy thú
Trực giác phi chính thức
Khi một trình xác thực bỏ phiếu để hoàn tất quá trình kiểm tra trên một nhánh, nhánh đó sẽ bị khóa cục bộ tại thời điểm đó.
Cụ thể hơn, giả sử có hai nhánh xung đột, (A) và (B), và nhánh (A) đã tiến xa hơn nhánh B. Nếu một trình xác thực (V) bỏ phiếu ((s_a, t_a)) góp phần hoàn tất điểm kiểm tra (a) trên nhánh (A), thì kể từ thời điểm đó, (V) không thể bỏ phiếu cho nhánh B có thời điểm mục tiêu ở hoặc sau (t_a) mà không vi phạm quy tắc cắt giảm của Casper FFG.
Theo trực giác, bằng cách bỏ phiếu để hoàn tất (a), trình xác thực cam kết một khoảng thời gian cụ thể trên nhánh (A). Bất kỳ nỗ lực nào để "bắt kịp" nhánh (B) bằng cách bỏ phiếu cho một điểm kiểm tra ở cùng hoặc sau thời điểm đó sẽ dẫn đến:
- Bỏ phiếu kép cho cùng một kỷ nguyên mục tiêu, hoặc
- bao quanh cuộc bỏ phiếu trước đó,
Cả hai đều là những hành vi có thể bị phạt.
Do đó, sau khi bỏ phiếu để hoàn tất (a), trình xác thực bị mắc kẹt đối với nhánh (B): nó không thể giúp nhánh (B) đạt được trạng thái hoàn tất trừ khi nhánh (B) trước tiên nâng cấp các điểm kiểm tra hợp lệ của nó lên các kỷ nguyên vượt quá phạm vi bị khóa của trình xác thực. Cho đến lúc đó, trình xác thực không thể đóng góp vào quá trình hoàn tất trên nhánh B mà không mâu thuẫn với thuộc tính mắc kẹt.
Để làm rõ điều này, chúng ta hãy chính thức hóa nó.
Tóm tắt Casper FFG
Trước tiên, hãy cùng điểm lại nhanh cơ chế bỏ phiếu của Casper FFG:
Với mỗi lần xác nhận, sẽ có một cuộc bỏ phiếu điểm kiểm tra mục tiêu nhằm xác thực một kỷ nguyên và một cuộc bỏ phiếu điểm kiểm tra nguồn nhằm hoàn tất kỷ nguyên đó. Một kỷ nguyên chỉ có thể được xác thực nếu nó nhận được hơn 2/3 số phiếu mục tiêu. Nó chỉ có thể được hoàn tất nếu trước đó nó đã được xác thực, nhận được hơn 2/3 số phiếu nguồn, và một điểm kiểm tra được xác thực mới được tạo ra ở kỷ nguyên ngay trên nó với cùng một bộ xác nhận.
Bây giờ, hãy cùng tóm tắt lại các quy tắc chém:
Giả sử (s_a, s_b) là hai phiếu bầu khác nhau từ các nguồn khác nhau.
Giả sử (t_a, t_b) là hai phiếu bầu mục tiêu khác nhau.
Gọi (h(x)) là độ cao (thời điểm) của bất kỳ cuộc bỏ phiếu hoặc điểm kiểm tra nào.
Nếu được cùng một người xác thực ban hành, phiếu bầu sẽ bị tính là vi phạm quy định về điểm cắt giảm bởi một trong hai bên:
- Quy tắc bỏ phiếu trùng lặp: (h(t_a) = h(t_b))
- Quy tắc bỏ phiếu bao quanh: (h(s_b) < h(s_a)) VÀ (h(t_a) < h(t_b))
Từ những quy tắc đó, bài báo của Casper FFG đã suy ra thuộc tính sau:
(iv) tồn tại nhiều nhất một trạm kiểm soát hợp lệ với độ cao (n).
Định nghĩa chính thức về tính chất bẫy
Phần mở đầu
Giả sử (a, b) là các điểm kiểm tra được xác thực gần nhất trên các nhánh khác nhau ((A) và (B)) có thể lần lượt tiến tới hoàn tất với số phiếu bầu ((s_a, t_a)) hoặc ((s_b, t_b)) trong đó (h(s_a) = h(a)) và (h(b) = h(s_b)).
Chúng tôi lưu ý nếu (h(a) = h(b)) thì ít nhất (1/3) số người xác thực đã phạm tội vi phạm cắt giảm (1).
Bẫy tài sản
Không mất tính tổng quát, nếu (h(a) > h(b)), và (V) là một trình xác thực bỏ phiếu để hoàn tất (a) với một phiếu bầu ((s_a, t_a)), thì (V) không thể tạo ra bất kỳ phiếu bầu ((s_b, t_b)) nào sao cho (h(t_b) \ge h(t_a)) mà không gây ra vi phạm cắt giảm (tiến hành phân nhánh).
Từ đây, dễ dàng nhận thấy rằng hiện tại (V) không thể đóng góp vào việc hoàn tất bất kỳ điểm kiểm tra nào trên (B) mà không cần gạch chéo.
Bằng chứng
Nếu (V) đưa ra ((s_b, t_b)) sao cho (h(t_b) = h(t_a)) thì đây là vi phạm rõ ràng quy tắc bỏ phiếu kép. Vì vậy, để tiến qua nhánh (A), (V) phải đưa ra (t_b) sao cho (h(t_b) > h(t_a)). (V) phải bỏ phiếu với (s_b) vì (b) là điểm kiểm tra hợp lệ mới nhất. Cho rằng (h(s_b) = h(b) < h(a) = h(s_a)), nên việc bỏ phiếu này cấu thành vi phạm quy tắc cắt giảm.
3.2 Bẫy phân nhánh đa số: Ví dụ minh họa
Thiết lập kịch bản:
- Một cụm DVT có 4 người vận hành: (O_1), (O_2), (O_3), (O_4).
- Số lượng người vận hành tối thiểu để đạt đủ số người tham gia là 3.
- Mạng đã trải qua một sự phân nhánh: Chuỗi (A) (đa số mạng) và Chuỗi (B) (thiểu số, chuỗi chính xác) vào Kỷ nguyên (X+1).
- Cả (A) lẫn (B) đều không có đủ người xác thực chứng nhận để biện minh hoặc hoàn tất điểm kiểm tra.
- Người dẫn đầu BFT (được chọn thông qua vòng tròn) hiện là (O_1).
Tình huống:
- (O_1) nằm trên Chuỗi (A) (nhánh phân nhánh chiếm đa số).
- (O_1), với tư cách là người lãnh đạo BFT, đề xuất với cụm DVT: “Xác nhận với Chuỗi (A): bỏ phiếu nguồn vào thời điểm (X) và bỏ phiếu mục tiêu vào thời điểm (X+1)”.
- (O_2) và (O_3) tình cờ nằm trên Chuỗi (B), nhưng chúng chỉ kiểm tra xem đề xuất có dẫn đến vi phạm cắt giảm hay không.
- Sự đồng thuận BFT đạt được số lượng tối thiểu: (O_1), (O_2), (O_3) chấp thuận xác nhận cho Chuỗi (A), Khối (X).
- Bản xác nhận được ký và nộp bởi nhóm DVT.
- Vào cuối kỷ nguyên, không có điểm kiểm tra nào trên Chuỗi (B) được tạo hoặc hoàn tất.
- Kỷ nguyên tiếp theo (O_2) là người dẫn đầu BFT và đề xuất với cụm DVT: Chứng thực trên Chuỗi (B): bỏ phiếu nguồn trên kỷ nguyên (X) và bỏ phiếu mục tiêu trên kỷ nguyên (X+2).
- Phiếu này không bị gạch bỏ vì nó không phải là phiếu bầu kép và không bao quanh phiếu bầu trước đó, do đó nó được chấp nhận.
- Cụm DVT tiếp tục luân chuyển các chứng thực giữa Chuỗi (A) và Chuỗi (B), do đó thu thập phần thưởng từ cả hai nhánh. Lưu ý : do số lượng trình xác thực trên một chuỗi thấp, sẽ có những vị trí bị thiếu. Điều này sẽ làm mất đi hiệu ứng tích cực này, vì sẽ khó có thể thu thập được các chứng thực.
- Sau 4 kỷ nguyên, rò rỉ không hoạt động được kích hoạt trên cả hai nhánh. Đối với mỗi chuỗi, điểm không hoạt động của trình xác thực DVT tăng lên (4) trong mỗi kỷ nguyên không hoạt động và giảm đi (1) trong mỗi kỷ nguyên hoạt động.
- Chuỗi (A) bắt đầu xác thực các điểm kiểm tra trước (B). Khi trình xác thực DVT chuyển phiếu bầu nguồn, nó sẽ bị kẹt lại ở (A).
- Điểm không hoạt động của cụm DVT bắt đầu tăng (4) mỗi chu kỳ trên (B).
- Tại thời điểm này, cụm huyết khối tĩnh mạch sâu (DVT) chỉ có thể thoát ra (A) nếu:
a. nó ngừng xác nhận vào (A)
b. nó đã vượt qua được sự rò rỉ do không hoạt động trên (B)
c. Chuỗi (B) biện minh cho việc đặt trạm kiểm soát ở độ cao cao hơn so với mục tiêu DVT đã bỏ phiếu (A).
Hậu quả:
Nhóm DVT ép buộc các nhà điều hành thiểu số phải liên kết với nhà điều hành đa số.
Nếu đa số đều trung thực thì đây là một hành vi có lợi.
Trình xác thực DVT tham gia vào cả hai chuỗi vì nó không biết trước chuỗi nào sẽ trở thành chuỗi chính thức. Chuỗi nào giành được đa số 2/3 trước thì nó sẽ được sử dụng để xây dựng.
Nếu đa số là độc hại thì cụm DVT sẽ bị mắc kẹt bởi nhánh đa số. Sau đó, khi rò rỉ do không hoạt động khiến mạng lưới phục hồi và Chuỗi (B) trở thành chính tắc, các trình xác thực của cụm DVT sẽ phải đối mặt với việc bị phạt vì sự không rõ ràng hoặc từ bỏ Chuỗi (B) (chấp nhận tổn thất).
Vấn đề then chốt: nhóm DVT bị buộc phải bỏ phiếu cho nhánh đa số ngay cả khi không phải tất cả các nhà điều hành đều đồng ý rằng đó là lựa chọn đúng đắn . Cơ chế đồng thuận BFT trở thành một công cụ để buộc các nhà điều hành thiểu số phải chấp nhận lựa chọn của đa số.
4. Giải pháp: Xác thực điểm kiểm tra và bỏ phiếu trắng ở cấp cụm
4.1 Giới thiệu Xác thực Điểm kiểm tra
Để giải quyết vấn đề lỗi phân nhánh đa số, các cụm DVT có thể triển khai xác thực điểm kiểm tra trước khi chứng thực điểm kiểm tra đó.
Quy tắc xác thực điểm kiểm tra:
Để một cụm DVT xác nhận điểm kiểm tra (C) tại thời điểm (E):
- Mỗi người vận hành phải xác minh rằng cấu trúc điểm kiểm tra cấp kỷ nguyên là hợp lệ.
- Mỗi người vận hành phải tự mình xác minh các thời điểm của nguồn.
Điểm kiểm tra mục tiêu phù hợp với tầm nhìn cục bộ của họ. - Nếu đủ số lượng người vận hành (ví dụ: 2/3) đồng ý, DVT sẽ xác nhận.
- Nếu không đạt đủ số thành viên cần thiết để thông qua, DVT sẽ không xác nhận.
func shouldSignAttestation (own, proposed Attestation) bool { return own.SourceCheckpoint.Epoch == proposed.SourceCheckpoint.Epoch && own.TargetCheckpoint.Epoch == proposed.TargetCheckpoint.Epoch} 4.2 Khi việc xác nhận thất bại: Cơ chế từ chối tham gia
Đây là cơ chế quan trọng: nếu không có đủ số lượng người vận hành đồng ý về cấu trúc điểm kiểm tra cấp kỷ nguyên, cụm máy chủ sẽ không xác nhận .
Không giống như các trình xác thực riêng lẻ, vốn phải xác nhận (hoặc chịu hình phạt do không hoạt động), một cụm DVT có thể lựa chọn không tham gia . Đây là một lợi thế quan trọng: cụm DVT được thiết kế để chịu lỗi và dự phòng, chứ không phải để đảm bảo sự tham gia.
Điều gì xảy ra khi cụm huyết khối tĩnh mạch sâu (DVT) ngừng xuất hiện?
- Huyết khối tĩnh mạch sâu (DVT) được đánh dấu là không hoạt động.
- Nó bắt đầu tích lũy các hình phạt do không hoạt động, nhưng không bị giảm bớt.
- Sau đó, DVT có thể chuyển hướng trở lại để xác nhận ngã rẽ chính xác.
5. An toàn cấp độ mạng: Làm thế nào DVT đa dạng có thể ngăn chặn việc hoàn tất nhánh chính
5.1 Giả định về tính không đồng nhất
Toàn bộ cơ chế phụ thuộc vào một giả định quan trọng: các cụm huyết khối tĩnh mạch sâu (DVT) phải không đồng nhất .
Nếu tất cả các cụm DVT đều sử dụng cùng một máy khách thực thi (ví dụ: tất cả đều sử dụng Geth), chúng sẽ đều gặp phải cùng một lỗi trong sự cố tương tự như Holesky. Tất cả chúng sẽ nằm trên cùng một nhánh đa số và đều bị buộc phải xác thực (thông qua cơ chế đồng thuận BFT). Trong trường hợp đó, DVT không cung cấp bất kỳ sự bảo vệ nào.
Tuy nhiên, nếu các cụm DVT được vận hành bởi các bên độc lập sử dụng các ứng dụng khách khác nhau (một số sử dụng Geth, một số sử dụng Nethermind, một số sử dụng Besu), thì tình hình sẽ thay đổi:
Khi một nhánh rẽ được chứng minh là hợp lệ, cơ chế kiểm tra điểm dừng (checkpoint validation) sẽ kích hoạt cơ chế bỏ qua (untention mechanism).
5.2 Ngưỡng quan trọng: Ngăn chặn việc hoàn tất phân nhánh đa số
Quy tắc về tính hoàn thiện của Ethereum yêu cầu hơn hai phần ba (66,7%) tổng số trình xác thực phải đồng ý về một điểm kiểm tra thì điểm kiểm tra đó mới được coi là hoàn thiện.
Nếu một tỷ lệ đủ lớn các trình xác thực của Ethereum là các DV có nhà điều hành khác nhau, thì:
- Các DV trên nhánh đa số sẽ bỏ phiếu trắng (nếu họ phát hiện ra sự khác biệt).
- Nhánh đa số sẽ không đạt được sự đồng thuận hai phần ba và do đó không thể hoàn tất.
Ví dụ tính toán:
Chúng ta hãy lấy tỷ lệ thâm nhập mạng SSV hiện tại làm cơ sở:
- Phiếu chống: 14% (tất cả đều bỏ phiếu trắng trong quá trình quyết định cuối cùng).
- Trong một phân nhánh đa số, giả sử 80% mạng (một cách không chính xác) đi theo nhánh đa số.
- Các trình xác thực truyền thống: 69% xác nhận phân nhánh đa số, 17% phân nhánh thiểu số.
- Nhánh đa số được hoàn tất mà không có sự tham gia của DVT .
Tuy nhiên, giả sử 30% số trình xác thực của Ethereum là các DV với các nhà điều hành không đồng nhất.
- 70% là các trình xác thực truyền thống.
- Trong một sự phân nhánh đa số, giả sử 90% mạng (một cách không chính xác) đi theo nhánh đa số.
- Các cuộc thăm dò ý kiến với nhiều nhà điều hành khác nhau: 30% không tham gia.
- Các trình xác thực truyền thống: 63% xác nhận phân nhánh đa số, 7% xác nhận phân nhánh thiểu số.
- Chưa có sự hoàn thiện cuối cùng .
5.3 Luận điểm về tính ổn định của mạng lưới
Điểm mấu chốt: nếu tồn tại một nhóm bệnh nhân DVT đủ đa dạng, việc hoàn tất một quyết định sai lầm sẽ trở nên khó khăn nếu không có sự đồng lõa của họ . Điều này tạo ra một điểm dừng tự nhiên:
- Đa số các nỗ lực phân nhánh nhằm hoàn tất quá trình.
- Các biến số DV khác nhau phát hiện ra sự không nhất quán và bỏ phiếu trắng.
- Quá trình hoàn tất bị chặn, ngăn ngừa sự phân tách trong chuỗi chính tắc.
- Mạng lưới đang "bị kẹt" mà chưa có giải pháp cuối cùng.
- Cơ chế rò rỉ do không hoạt động sẽ được kích hoạt.
- Cộng đồng trung thực có một khoảng thời gian nhất định để phối hợp.
Điều quan trọng là , kết quả này vượt trội hơn so với kịch bản Holesky:
- Không có trình xác thực nào trên chuỗi chính xác bị phạt.
- Nhóm thiểu số trung thực không bị ép buộc phải chấp nhận nhánh tư tưởng của đa số là chuẩn mực.
- Sự đồng thuận xã hội có thể xác định con đường phục hồi đúng đắn.
- Cho đến khi điều này xảy ra, cả hai nhánh vẫn hoạt động.
6. Sự đánh đổi: Sự biện minh mà không cần kết luận cuối cùng
6.1 Tại sao DV có thể biện minh (nhưng không hoàn tất) một nhánh rẽ tồi tệ
Cơ chế xác thực điểm kiểm tra mà chúng tôi đề xuất cố ý không kiểm tra các gốc trạng thái . Đây là một lựa chọn thiết kế quan trọng tạo ra một hạn chế cơ bản: các cụm DVT vẫn có thể chứng thực (và do đó biện minh cho) một nhánh rẽ không hợp lệ, ngay cả khi chúng không thể hoàn tất nhánh rẽ đó.
Vì sao việc kiểm tra gốc trạng thái bị loại trừ:
Việc so sánh các gốc trạng thái đầy đủ giữa các nhà điều hành DVT sẽ đòi hỏi:
- Tất cả các nhà điều hành đều đã xử lý và xác thực cùng một trạng thái khối.
- Sự thống nhất về trạng thái toàn bộ lớp thực thi tại một vị trí nhất định
- Từ chối bất kỳ khối nào có sự sai lệch trạng thái dù nhỏ nhất.
Điều này tạo ra một vấn đề nghiêm trọng: do độ trễ mạng và độ trễ lan truyền khối, các nhà khai thác có thể không có cùng một gốc trạng thái tại cùng một thời điểm . Một số nhà khai thác nhận được Khối X sớm hơn một chút so với những nhà khai thác khác. Việc yêu cầu sự thống nhất hoàn hảo về gốc trạng thái sẽ đồng nghĩa với việc các cụm DVT hầu như không bao giờ xác nhận — dẫn đến các khoản phạt do không hoạt động liên tục và khiến DVT không khả thi về mặt kinh tế. Vấn đề càng trở nên trầm trọng hơn trong kịch bản đối kháng.
Để giải quyết vấn đề này, cơ chế này cố tình nới lỏng quy tắc xác thực: chỉ cấu trúc epoch của checkpoint được xác thực, chứ không phải toàn bộ trạng thái thực thi . Điều này cho phép các operator xác nhận ngay cả khi họ có quan điểm hơi khác nhau về slot HEAD hiện tại, miễn là cấu trúc đồng thuận ở cấp độ epoch (checkpoint nguồn, checkpoint đích, checkpoint được chứng thực) là nhất quán.
Sự đánh đổi:
Lựa chọn thiết kế này có một hệ quả trực tiếp: vì các cụm DVT không xác minh các gốc trạng thái, chúng sẽ hỗ trợ việc biện minh cho một nhánh rẽ .
Trong kỷ nguyên đầu tiên của một nhánh rẽ:
- Các chuyên gia DVT nhìn thấy 2 ngã rẽ khác nhau.
- Cấu trúc điểm kiểm tra cấp kỷ nguyên có vẻ hợp lệ trên mỗi nhánh.
- Sự đồng thuận của BFT dễ dàng đạt được số lượng thành viên tối thiểu để xác nhận bất cứ điều gì mà người lãnh đạo quyết định (nhiều khả năng là đa số).
Hậu quả:
Các DV có thể biện minh (tích lũy hơn một phần ba số chứng thực) cho một nhánh rẽ xấu chỉ đơn giản vì cấu trúc ở cấp độ kỷ nguyên thoạt nhìn có vẻ đúng. Không thể ngăn chặn họ làm điều này mà không ảnh hưởng đến tính khả dụng thông qua việc liên tục có các chứng thực thất bại.
6.2 Tại sao điều này được chấp nhận
Từ góc nhìn của đơn vị thẩm định DVT, điều này là mong muốn và hoàn toàn phù hợp với các mục tiêu của họ:
- Tính khả dụng của mạng : Bằng cách loại trừ việc kiểm tra trạng thái gốc, chúng ta duy trì tính khả dụng của DVT. Các cụm DVT có thể tiếp tục tham gia vào quá trình đồng thuận ngay cả khi mạng bị phân vùng hoặc có sự khác biệt trạng thái tạm thời, điều này rất cần thiết cho tính hoạt động liên tục của mạng.
- Quá trình hoàn tất vẫn được bảo vệ : Mặc dù các DV có thể biện minh cho một nhánh rẽ không tốt, nhưng họ sẽ không hoàn tất nó miễn là họ có một thiết lập đa dạng.
- Khả năng đảo ngược : Sau khi chứng minh được lý do, các DV luôn có thể chọn chuyển sang nhánh khác mà không phải chịu bất kỳ hình phạt nào, cho phép họ tối đa hóa phần thưởng có thể nhận được từ cả hai chuỗi.
- Giảm thiểu nguy cơ rò rỉ do không hoạt động : Biến DV chứng minh tỷ lệ thuận với thành phần cụm của nó trên mỗi chuỗi cho đến khi đạt điểm hợp lý. Dừng lại sớm hơn đồng nghĩa với việc phải chịu đựng hậu quả của hiện tượng rò rỉ do không hoạt động.
7. Tình thế khó xử của các nhà xác thực khác: Sự đánh đổi giữa việc cắt giảm và việc hoàn tất
7.1 Vấn đề đối với các đơn vị thẩm định không thuộc DVT
Một khi cụm DVT đã xác nhận nhánh đa số, các trình xác thực khác trên mạng sẽ phải đối mặt với một tình huống khó xử :
Tình hình:
- DVs (lý giải cho nhánh đa số) + trình xác thực truyền thống đa số > 66,7%.
- Một lỗi phân nhánh (fork) là điều có thể chấp nhận được, khiến các DV phải bỏ phiếu trắng trong kỷ nguyên tiếp theo.
- Ngay cả khi các trình xác thực truyền thống không thể hoàn tất việc phân nhánh, họ vẫn có thể bị mắc kẹt trong đó bằng một cuộc bỏ phiếu ủng hộ nguồn gốc .
Hậu quả:
Các trình xác thực bị mắc kẹt không thể giúp hoàn tất việc phân nhánh chính xác.
7.2 Cơ hội DVT: Một con đường hướng tới khả năng phục hồi mạng lưới mạnh mẽ hơn
Từ góc độ an ninh mạng, kết quả này không mấy tối ưu . Tuy nhiên, các cụm DVT vẫn được khuyến khích không đẩy nhanh quá trình rò rỉ trạng thái không hoạt động của chính chúng bằng cách xác thực trên cả hai chuỗi. Đối với các trình xác thực lo ngại về một sự kiện phân nhánh đa số thảm khốc, các bước chủ động có thể giúp giảm thiểu rủi ro của họ.
Một lựa chọn quan trọng là chuyển sang cụm DVT. Việc áp dụng rộng rãi DVT thậm chí có thể giải quyết vấn đề đa dạng khách hàng : với các thiết lập vận hành đa dạng, trình xác thực DVT tích hợp hiệu quả các kiểm tra trên nhiều triển khai khách hàng, củng cố toàn bộ hệ sinh thái.
8. Tầm quan trọng của đa số bệnh nhân huyết khối tĩnh mạch sâu (DVT)
8.1 Thuộc tính an ninh quan trọng
Cơ chế hoàn thiện của Ethereum (Casper FFG) yêu cầu hai phần ba số người xác thực phải chấp thuận và hoàn tất một điểm kiểm tra. Nếu hơn một phần ba mạng lưới bao gồm các nhà xác thực đa dạng, thì chắc chắn sẽ không có nhánh rẽ nào được hoàn tất nếu không có sự đồng thuận của cộng đồng.
8.2 Gỡ bỏ trình xác thực
Vì việc bỏ phiếu trắng sau khi đã có lý do chính đáng giúp tránh được những cạm bẫy, nên các bên tham gia có thể chuyển sang xác nhận lựa chọn đúng ngay khi đạt được sự đồng thuận xã hội.
Khi nhánh được chọn hợp lệ ở mức cao hơn nhánh không chính xác, các trình xác thực truyền thống bị mắc kẹt giờ đây có thể chuyển đổi một cách an toàn.
Số lượng người dùng DVT càng lớn, nhánh được chọn càng được hoàn tất nhanh chóng và tình trạng rò rỉ do không hoạt động càng chấm dứt. Nếu điều này xảy ra đủ nhanh, các trình xác thực bị mắc kẹt sẽ có thể thoát ra ngay sau khi đạt được sự đồng thuận chung.
8.3 Tác động thực tiễn
Trên thực tế, điều này có nghĩa là:
- Kịch bản Holesky được ngăn chặn : Nếu 40% số người xác thực là các DV với các nhà điều hành khác nhau trong thời điểm Holesky xảy ra, thì nhánh đa số đã không thể hoàn tất. Việc rò rỉ thông tin do không hoạt động trong ba tuần sẽ không cần thiết.
- Cửa sổ đồng thuận xã hội : Mạng lưới có thêm thời gian (vài ngày đến vài tuần) để phối hợp giải quyết vấn đề và đạt được sự đồng thuận xã hội. Không xảy ra sự chia rẽ không thể đảo ngược.
9. Hạn chế và Giả định: Khi Khả năng Bảo vệ Chống Huyết khối Tĩnh mạch Sâu (DVT) Thất bại
9.1 Kịch bản huyết khối tĩnh mạch sâu đồng nhất
Toàn bộ cơ chế phụ thuộc vào các nhà điều hành DVT không đồng nhất . Nếu một cụm DVT được vận hành bởi các bên liên quan hoặc chỉ sử dụng một triển khai máy khách duy nhất, nó sẽ cung cấp khả năng bảo vệ hạn chế hoặc không có khả năng bảo vệ nào.
9.2 Cuộc tấn công phối hợp của các nhà điều hành
Nếu các nhà điều hành của một cụm DVT được khuyến khích phối hợp xung quanh một nhánh cụ thể (ví dụ: họ cùng nhau ưu tiên Nhánh A vì lý do kinh tế không liên quan đến tính chính xác), thì cơ chế xác thực điểm kiểm tra không thể ngăn chặn điều này.
Tính bảo mật mật mã của DVT đảm bảo rằng không một nhà điều hành nào có thể đánh cắp khóa xác thực. Tuy nhiên, nó không đảm bảo rằng các nhà điều hành sẽ hành động vì lợi ích của mạng. Nếu một nhóm các nhà điều hành có ý đồ xấu hoặc phối hợp với nhau, họ có thể buộc cụm máy chủ phải chứng thực bất kỳ nhánh rẽ nào.
9.3 Vấn đề đa số khách hàng
Trong quá trình triển khai Holesky, ba máy khách thực thi đã bị ảnh hưởng: Geth, Nethermind và Besu. Nếu ba máy khách này chiếm hơn 66,7% tổng số trình xác thực (cả solo và DVT), thì tất cả các DV sử dụng các máy khách này sẽ nằm trên nhánh chính.
9.4 Thất bại trong việc thoát khỏi sự thụ động
Các DV sẽ xác thực trên chuỗi thiểu số trước khi khóa vào một trap với tần suất tỷ lệ thuận với số lượng các nhà điều hành trong ủy ban của nó coi nó là chính tắc. Tuy nhiên, do thực tế là đa số các trình xác thực không đề xuất khối, nên việc xác thực sẽ được ghi nhận với độ trễ. Kết quả là, DV có thể phải chịu hình phạt rò rỉ do không hoạt động bất kể hiệu suất của nó.
10. Kết luận: Con đường dẫn đến sự đồng thuận bền vững
Công nghệ xác thực phân tán với các nhà điều hành không đồng nhất mang đến một giải pháp mới. Bằng cách triển khai xác thực điểm kiểm tra ở cấp độ cụm, DVT có thể cung cấp khả năng bỏ qua có chọn lọc đối với các nhánh đa số. Nếu một lượng lớn các trình xác thực áp dụng DVT đa dạng, mạng lưới sẽ có khả năng:
- Ngăn chặn việc hoàn tất các nhánh rẽ lỗi mà không cần phải cắt giảm mã nguồn quy mô lớn.
- Bảo vệ các con đường khôi phục sự đồng thuận xã hội bằng cách ngăn chặn những chia rẽ không thể đảo ngược.
- Hãy tạo điều kiện về thời gian và không gian để cộng đồng trung thực phối hợp khôi phục lại hệ thống sau khi thực hiện hard fork.
- Tạo ra các biện pháp khuyến khích sự đa dạng liên tục về khách hàng và nhà điều hành ở cấp độ giao thức.
Cơ chế này không phải là giải pháp thần kỳ. Nó đòi hỏi:
- Tỷ lệ áp dụng DVT đầy đủ (>33,3% người thẩm định).
- Phân bố khách hàng và nhà mạng không đồng đều.
- Không có sự phối hợp hành vi kiểu Byzantine nào giữa các nhà điều hành DVT.
Tuy nhiên, ngay cả với những giả định này, nó vẫn thể hiện sự cải thiện đáng kể so với tình trạng hiện tại, nơi mà sự cố chiếm đa số khách hàng có thể dẫn đến việc phân nhánh mạng một cách không kiểm soát.
Hướng đi tiếp theo là tích cực thúc đẩy việc áp dụng DVT, đảm bảo sự tham gia đa dạng của các nhà điều hành và khách hàng, và biến việc xác thực điểm kiểm tra trở thành một phần tiêu chuẩn của cơ chế đồng thuận DVT. Khi Ethereum trưởng thành, lớp bảo vệ này sẽ ngày càng trở nên quan trọng đối với sự ổn định lâu dài của mạng lưới.
