Sáp nhập Ethereum: Rủi ro khi chạy nhiều khách hàng là gì?

Bản dịch gốc: Khối kỳ lân

Bản dịch gốc: Khối kỳ lân

Đặc biệt cảm ơn Vitalik Buterin (V God), Hsiao-Wei Wang, Caspar Schwarz-Schilling vì phản hồi và đánh giá của họ.

tiêu đề cấp đầu tiên

Tại sao chúng ta cần nhiều khách hàng?

Có tranh luận về lý do tại sao kiến ​​trúc một máy khách lại được ưu tiên hơn. Và việc phát triển nhiều máy khách sẽ tạo ra chi phí đáng kể, đó là lý do tại sao chúng tôi không thấy bất kỳ mạng blockchain nào khác nghiêm túc theo đuổi tùy chọn nhiều máy khách.

Vậy tại sao Ethereum lại hướng đến mục tiêu trở thành nhiều khách hàng? Máy khách là những đoạn mã rất phức tạp có khả năng chứa lỗi. Điều tồi tệ nhất trong số này được gọi là "lỗi đồng thuận", lỗi trong logic chuyển đổi trạng thái ở cốt lõi của chuỗi khối. Một ví dụ thường được trích dẫn là cái gọi là khai thác "nguồn cung tiền vô hạn", trong đó một khách hàng dễ bị tổn thương chấp nhận các giao dịch in một lượng ether tùy ý. Nếu ai đó tìm thấy một lỗi như vậy, nhưng không bị dừng lại trước khi họ thoát ra (tức là khai thác tiền thông qua máy trộn hoặc sàn giao dịch), điều đó sẽ khiến giá trị của Ether sụt giảm nghiêm trọng.

Nếu mọi người đang chạy cùng một khách hàng, thì cần phải dừng sự can thiệp của con người, vì chuỗi, tất cả các hợp đồng thông minh và sàn giao dịch sẽ tiếp tục hoạt động như bình thường. Thậm chí một vài phút là đủ thời gian để thực hiện một cuộc tấn công thành công và phân tán tiền đủ để không thể khôi phục giao dịch của kẻ tấn công. Tùy thuộc vào số lượng ETH được in, cộng đồng có thể phối hợp khôi phục chuỗi về trước khi khai thác (sau khi lỗi được xác định và sửa).

Bây giờ, hãy xem điều gì sẽ xảy ra khi chúng ta có nhiều khách hàng. Có hai kịch bản có thể xảy ra:

1.Khách hàng dễ bị tổn thương chiếm ít hơn 50% cổ phần, khách hàng sẽ tạo một khối với giao dịch khai thác lỗi, in ETH, hãy gọi chuỗi nàyA。

Tuy nhiên, hầu hết những người đặt cược chạy ứng dụng khách không có trục trặc sẽ bỏ qua khối này vì nó không hợp lệ (đối với họ, hoạt động in ETH là không hợp lệ). họ sẽ xây dựng

Tuy nhiên, hầu hết những người đặt cược chạy ứng dụng khách không có trục trặc sẽ bỏ qua khối này vì nó không hợp lệ (đối với họ, hoạt động in ETH là không hợp lệ). Họ sẽ xây dựng một chuỗi B thay thế không chứa các khối không hợp lệ.

Vì các khách hàng chính xác chiếm đa số, chuỗi B sẽ tích lũy thêm bằng chứng. Do đó, ngay cả những khách hàng có vấn đề cũng sẽ bỏ phiếu cho chuỗi B; kết quả là chuỗi B sẽ tích lũy 100% số phiếu bầu và chuỗi A sẽ chết. Chuỗi sẽ tiếp tục như thể lỗi không bao giờ xảy ra.

2.Phần lớn cổ phần được đặt cược đang sử dụng ứng dụng khách lỗi, trong trường hợp này chuỗiAPhần lớn phiếu bầu sẽ được tích lũy. Nhưng doBVới ít hơn 50% của tất cả các bằng chứng, khách hàng vi phạm sẽ không bao giờ nhìn thấy chuỗi nô lệAchuyển sang chuỗiBlý do. Do đó, chúng ta sẽ thấy sự phân tách chuỗi.

Trường hợp 1 là trường hợp lý tưởng nhất. Bởi vì điều này rất có thể sẽ dẫn đến một khối mồ côi và hầu hết người dùng thậm chí sẽ không nhận thấy. Các nhà phát triển có thể gỡ lỗi ứng dụng khách, sửa lỗi và bạn đã sẵn sàng. Ngược lại, trường hợp 2 rõ ràng kém lý tưởng hơn. Nhưng vẫn tốt hơn so với chỉ một ứng dụng - hầu hết sẽ phát hiện sự phân tách chuỗi khá nhanh (bạn có thể tự động hóa việc này bằng cách chạy nhiều ứng dụng khách), các sàn giao dịch sẽ nhanh chóng tạm dừng tiền gửi và người dùng Defi có thể đợi sự phân tách giải quyết xong Tiến hành một cách thận trọng. Về cơ bản, điều này vẫn cung cấp cho chúng tôi đèn cảnh báo màu đỏ nhấp nháy trước những kết quả tồi tệ nhất so với kiến ​​trúc một máy khách.

Trường hợp 2 sẽ tồi tệ hơn nếu máy khách bị lỗi chiếm hơn 2/3 số tiền đặt cược. Trong trường hợp này, nó sẽ hoàn tất chuỗi không hợp lệ. Thêm về điều này sau.

tiêu đề cấp đầu tiên

Khuyến khích sự đa dạng của khách hàng: Hình phạt chống mối quan hệ

Nếu cổ phần được trải rộng trên nhiều khách hàng, trường hợp tốt nhất là mỗi khách hàng sở hữu ít hơn một phần ba tổng số cổ phần, điều này rõ ràng là có lợi cho mạng. Điều này sẽ làm cho nó có khả năng phục hồi các lỗi trong bất kỳ máy khách nào. Nhưng tại sao các nhà sản xuất lại quan tâm? Nếu mạng không có bất kỳ ưu đãi nào, họ sẽ ít phải chịu chi phí chuyển sang khách hàng thiểu số.

Thật không may, chúng tôi không thể làm cho phần thưởng phụ thuộc trực tiếp vào ứng dụng khách mà trình xác thực đang chạy. Không có cách khách quan nào để đo lường điều này mà không thể bị lừa.

Tuy nhiên, bạn không thể ẩn khi khách hàng của bạn có lỗi. Đây là lúc các hình phạt chống tương quan xuất hiện: ý tưởng là nếu người xác nhận của bạn làm điều gì đó không tốt, thì hình phạt sẽ cao hơn nếu có nhiều người xác nhận sai cùng một lúc. Nói cách khác, bạn sẽ bị phạt vì những lỗi liên quan.

Trong ether, hiện tại bạn có thể bị hack vì hai hành vi:

1. Ký hiệu trên hai khối có cùng chiều cao.

2. Tạo một cặp bằng chứng có thể cắt tỉa được (biểu quyết xung quanh hoặc biểu quyết kép).

Khi bị chặt chém thường không mất hết tiền. Tại thời điểm viết (Altair Fork), hình phạt mặc định thực sự khá nhỏ: bạn sẽ chỉ mất 0,5ETH hoặc 1,5% số Ether đã đặt cược của mình (cuối cùng sẽ tăng lên 1ETH hoặc 3%).

Tuy nhiên, có một nhược điểm: có một hình phạt bổ sung phụ thuộc vào tất cả các dấu gạch chéo khác xảy ra trong vòng 4096 kỷ nguyên (18 ngày) trước và sau khi trình xác thực của bạn bị gạch chéo. Số tiền bạn bị phạt thêm tỷ lệ thuận với tổng số tiền bị cắt giảm trong khoảng thời gian này.

tiêu đề cấp đầu tiên

Một hình phạt chống tương quan khác: rò rỉ không hoạt động bậc hai

Một cách khác khiến trình xác thực không thành công là ngoại tuyến, một lần nữa, điều này có hình phạt, nhưng cơ chế rất khác. Chúng tôi không gọi đây là chém và nó thường nhỏ: trong điều kiện hoạt động bình thường, những người xác thực ngoại tuyến sẽ bị phạt giống như nếu họ đang xác thực đầy đủ. Khi viết bài này, đó là tốc độ tăng trưởng hàng năm là 4,8%. Nếu trình xác thực của bạn ngoại tuyến trong nhiều giờ hoặc nhiều ngày, chẳng hạn như do mất kết nối internet tạm thời, thì có lẽ bạn không nên đổ mồ hôi lạnh.
Mọi thứ trở nên rất khác khi hơn 1/3 số người xác thực ngoại tuyến. Sau đó, chuỗi đèn hiệu không thể hoàn thiện, đe dọa một thuộc tính cơ bản của các giao thức đồng thuận, đó là tính sống động.
Để trẻ hóa trong những tình huống như thế này, cái gọi là "rò rỉ không hoạt động thứ cấp" ra đời. Nếu trình xác thực tiếp tục ngoại tuyến trong khi chuỗi chưa hoàn thành, thì tổng số tiền phạt sẽ tăng theo cấp số nhân theo thời gian. Ban đầu, nó rất thấp; sau khoảng 4,5 ngày, những người xác thực ngoại tuyến sẽ mất 1% cổ phần của họ. Tuy nhiên, nó đã tăng lên 5% sau ~10 ngày và 20% sau ~21 ngày (đây là giá trị của Altair, sẽ tăng gấp đôi trong tương lai).

Cơ chế này được thiết kế sao cho trong trường hợp xảy ra sự kiện thảm khốc khiến một số lượng lớn hoạt động của trình xác nhận bị lỗi, chuỗi cuối cùng sẽ có thể hoàn thành lại. Khi những người xác thực ngoại tuyến mất ngày càng nhiều cổ phần, phần chia sẻ của họ trong tổng số cổ phần sẽ ngày càng nhỏ hơn và khi cổ phần của họ giảm xuống dưới 1/3, những người xác nhận trực tuyến còn lại sẽ chiếm đa số 2/3 cần thiết, do đó cho phép họ hoàn tất chuôi.
tiêu đề cấp đầu tiên

Điều hành một khách hàng đa số tệ đến mức nào?

Để hiểu những mối nguy hiểm là gì, hãy xem xét ba loại thất bại:

1. Sự kiện chém hàng loạt: Hầu hết những người xác thực khách hàng đã ký vào các bằng chứng có thể chém do một lỗi.

2. Số lượng lớn các sự kiện ngoại tuyến: do một lỗi, tất cả các trình xác nhận phần lớn ứng dụng khách đều ngoại tuyến.

3. Sự kiện khối không hợp lệ: Do nhầm lẫn, hầu hết các trình xác nhận khách hàng đã chứng minh rằng có một khối không hợp lệ.

tiêu đề cấp đầu tiên

Tình huống 1: Chữ ký kép

Đây có lẽ là tình huống mà hầu hết các nhà điều hành trình xác thực lo sợ nhất: một lỗi khiến ứng dụng khách trình xác thực ký vào một bằng chứng có thể xóa được. Một ví dụ là hai người ủng hộ bỏ phiếu cho cùng một thời điểm mục tiêu, nhưng với các trọng tải khác nhau. Vì đây là lỗi của máy khách nên mối quan tâm không chỉ là một người đặt cược mà là tất cả những người đặt cược đang chạy ứng dụng khách cụ thể này. Một khi những điều mơ hồ này được phát hiện, đó sẽ là một cuộc tắm máu: tất cả những người đặt cược có liên quan sẽ mất 100% số tiền đặt cược của họ. Điều này là do chúng tôi đang xem xét nhiều khách hàng: nếu khách hàng được đề cập chỉ đặt cược 10% cổ phần của họ, thì "chỉ" 20% cổ phần của họ sẽ bị cắt giảm (trong Altair; 30% và đặt thông số phạt cuối cùng).

Trong trường hợp này, thiệt hại rõ ràng là rất lớn, nhưng tôi cũng cho rằng nó rất khó xảy ra. Các điều kiện đối với bằng chứng có thể xóa rất đơn giản, đó là lý do tại sao các ứng dụng khách trình xác thực (VC) được xây dựng để thực thi chúng. Ứng dụng khách của trình xác thực là một phần mềm nhỏ, đã được kiểm tra kỹ lưỡng và việc vi phạm kích thước này là không thể xảy ra.

tiêu đề cấp đầu tiên

Tình huống 2: Hoạt động offline quy mô lớn

Đối với trường hợp này, chúng tôi giả định rằng hầu hết các máy khách đều có một lỗi mà khi được kích hoạt sẽ khiến máy khách gặp sự cố. Khối được đề cập đã được tích hợp vào chuỗi và bất cứ khi nào khách hàng gặp phải khối đó, khối đó sẽ bị ngoại tuyến, ngăn cản việc tham gia thêm vào quá trình đàm phán. Hầu hết các khách hàng hiện đang ngoại tuyến, vì vậy rò rỉ không hoạt động bắt đầu xuất hiện.

Các nhà phát triển khách hàng sẽ tranh giành để đặt mọi thứ lại với nhau. Trên thực tế, trong vòng vài giờ, nhiều nhất là vài ngày, họ sẽ phát hành bản sửa lỗi để loại bỏ sự cố.

Trong thời gian chờ đợi, người đặt hàng cũng có thể chọn chuyển sang khách hàng khác. Ngay sau khi điều này được thực hiện đủ để có hơn 2/3 số người xác thực trực tuyến, rò rỉ trạng thái không hoạt động bậc hai sẽ dừng lại. Điều này không phải là không thể xảy ra cho đến khi ứng dụng khách bị lỗi được sửa.

tiêu đề cấp đầu tiên

Tình huống 3: Khối dữ liệu không hợp lệ

Đối với trường hợp này, chúng tôi xem xét tình huống trong đó hầu hết khách hàng gặp lỗi tạo ra khối không hợp lệ và cũng chấp nhận khối đó là hợp lệ -- nghĩa là khi những người xác thực khác sử dụng cùng một khách hàng nhìn thấy khối không hợp lệ, họ sẽ coi khối đó là hợp lệ, do đó chứng minh Nó.
Hãy gọi chuỗi chứa chuỗi khối không hợp lệ là A, khi khối không hợp lệ được tạo ra, hai điều sẽ xảy ra:

1. Tất cả các máy khách đang hoạt động sẽ bỏ qua các khối không hợp lệ và thay vào đó xây dựng trên các phần đầu hợp lệ mới nhất để tạo ra một chuỗi B riêng biệt. Tất cả các khách hàng đang hoạt động sẽ bỏ phiếu và xây dựng trên chuỗi B.

2. Máy khách bị lỗi nghĩ rằng cả hai chuỗi A và B đều hợp lệ, vì vậy nó sẽ bỏ phiếu cho chuỗi nào trong số hai chuỗi mà nó hiện cho là nặng nhất.

Chúng ta cần phân biệt ba trường hợp:

1. Các khách hàng dễ bị tổn thương nắm giữ ít hơn một nửa tổng số cổ phần. Trong trường hợp này, tất cả các khách hàng chính xác sẽ bỏ phiếu và xây dựng trên chuỗi B, cuối cùng làm cho nó trở thành chuỗi nặng nhất. Tại thời điểm này, ngay cả những máy khách bị lỗi cũng sẽ chuyển sang chuỗi B. Ngoại trừ một hoặc một vài khối mồ côi, sẽ không có gì xấu xảy ra. Đây là một tình huống dễ chịu và tại sao chỉ có đa số người dùng lại là điều tuyệt vời.

2. Các khách hàng dễ bị tổn thương đã nắm giữ hơn một nửa nhưng chưa đến hai phần ba số cổ phần.Trong ví dụ này, chúng ta sẽ thấy hai chuỗi đang được xây dựng - A bởi khách hàng có lỗi và B bởi tất cả các khách hàng khác. Cả hai chuỗi đều không có đa số hai phần ba, vì vậy chúng không thể được hoàn thiện. Khi điều này xảy ra, các nhà phát triển sẽ tranh nhau để hiểu tại sao lại có hai chuỗi. Khi họ phát hiện ra rằng có các khối không hợp lệ trong chuỗi A, họ có thể tiến hành sửa các ứng dụng khách bị lỗi. Sau khi sửa, nó sẽ nhận ra chuỗi A là không hợp lệ. Vì vậy, nó sẽ bắt đầu xây dựng trên chuỗi B, điều này sẽ cho phép nó được hoàn thiện. Điều này rất gây khó chịu cho người dùng. Mặc dù hy vọng rằng sự nhầm lẫn về chuỗi nào hợp lệ sẽ chỉ tồn tại trong thời gian ngắn, chưa đầy một giờ, chuỗi có thể không được hoàn thành trong nhiều giờ hoặc thậm chí một ngày. Nhưng đối với các nhà sản xuất, ngay cả những người điều hành khách hàng đang bị nghi ngờ, hình phạt vẫn tương đối nhẹ. Nếu họ không tham gia chuỗi B trong khi xây dựng chuỗi A không hợp lệ, họ sẽ bị phạt "rò rỉ do không hoạt động". Tuy nhiên, vì điều này có thể kéo dài chưa đầy một ngày, nên chúng ta đang nói về mức phạt dưới 1% cổ phần.

3. Khách hàng được đề cập nắm giữ hơn hai phần ba số cổ phần.Trong trường hợp này, ứng dụng khách lỗi sẽ không chỉ xây dựng chuỗi A — nó thực sự sẽ có đủ cổ phần để "hoàn thiện" nó. Lưu ý rằng nó sẽ là khách hàng duy nhất sẽ coi chuỗi A là hoàn tất. Một trong những điều kiện để hoàn tất là chuỗi hợp lệ và đối với tất cả các ứng dụng khách đang hoạt động chính xác khác, chuỗi A sẽ không hợp lệ. Tuy nhiên, do cách thức hoạt động của giao thức Casper FFG, khi những người xác nhận hoàn tất chuỗi A, họ không bao giờ có thể tham gia vào một chuỗi khác xung đột với A mà không bị tấn công, trừ khi chuỗi đó được hoàn thiện (để biết chi tiết. Đối với những người quan tâm, hãy xem Phụ lục 2). Vì vậy, khi chuỗi A được hoàn tất, các trình xác thực đang chạy ứng dụng khách có lỗi sẽ rơi vào tình huống nghiêm trọng: họ đã cam kết với chuỗi A, nhưng chuỗi A không hợp lệ. Họ không thể đóng góp cho B vì nó chưa được hoàn thành. Ngay cả việc sửa lỗi đối với phần mềm trình xác thực của họ cũng không giúp được gì cho họ - họ đã gửi những lá phiếu vi phạm. Điều gì sẽ xảy ra bây giờ rất đau đớn: chuỗi B chưa được hoàn thiện sẽ rơi vào tình trạng rò rỉ không hoạt động thứ cấp. Trong vòng vài tuần, những người xác nhận vi phạm sẽ rò rỉ cổ phần của họ cho đến khi đủ số cổ phần bị mất để B hoàn tất lại. Giả sử họ bắt đầu với 70% tiền đặt cược – sau đó họ sẽ mất 79% tiền đặt cược, vì đó là số tiền họ cần phải mất để chiếm ít hơn một phần ba tổng số tiền đặt cược. Tại thời điểm này, chuỗi B sẽ được hoàn thiện lại và tất cả những người đặt cược có thể chuyển sang chuỗi đó. Chuỗi sẽ hoạt động trở lại, nhưng sự cố ngừng hoạt động sẽ kéo dài trong nhiều tuần, với hàng triệu ETH bị phá hủy trong quá trình này.

tiêu đề cấp đầu tiên

Phân tích rủi ro

Vì vậy, làm thế nào để chúng tôi đánh giá các kịch bản này? Một chiến lược phân tích rủi ro điển hình là đánh giá khả năng xảy ra sự kiện (1-rất khó xảy ra, 5-rất có thể xảy ra) và tác động (1-rất thấp, 5-thảm khốc). Những rủi ro quan trọng nhất cần tập trung vào là những rủi ro đạt điểm cao trên cả hai chỉ số, được biểu thị bằng tích của tác động và khả năng xảy ra.

Với suy nghĩ này, Kịch bản 3 cho đến nay là ưu tiên cao nhất. Khi một khách hàng chiếm đa số hai phần ba, tác động sẽ khá thảm khốc, đây cũng là một kịch bản tương đối có thể xảy ra. Để nhấn mạnh mức độ dễ dàng của một lỗ hổng như vậy, một lỗi như vậy đã xảy ra gần đây trên Mạng thử nghiệm lò nung (xem Đề xuất chặn mạng thử nghiệm lò nung không thành công). Trong trường hợp này, Prysm đã phát hiện ra rằng viên gạch bị lỗi sau khi nó được trình bày và không chứng minh điều đó. Nếu Prysm nghĩ rằng việc chặn là hợp lệ và điều này xảy ra trên Mainnet, thì chúng ta đang ở trong tình huống thảm khốc được mô tả trong Trường hợp 3 của Kịch bản 3 - vì Prysm hiện chiếm đa số 2/3 trên Mainnet. Vì vậy, nếu bạn hiện đang chạy Prysm, có một rủi ro rất thực tế là bạn có thể mất tất cả số tiền của mình và bạn nên cân nhắc chuyển đổi khách hàng.

Kịch bản 1, có lẽ là đáng sợ nhất, nhận được đánh giá tương đối thấp. Lý do cho điều này là tôi nghĩ rằng khả năng điều này xảy ra là khá thấp vì tôi nghĩ rằng phần mềm máy khách Trình xác thực được triển khai tốt trên tất cả các máy khách và không có khả năng nó sẽ tạo ra các bằng chứng hoặc khối có thể sai lệch.

Nếu tôi hiện đang chạy nhiều ứng dụng khách và lo lắng về việc chuyển đổi, thì tôi có những lựa chọn nào?

Thay thế khách hàng có thể là một công việc lớn, đi kèm với một số rủi ro. Tôi nên làm gì nếu cơ sở dữ liệu của người thợ rèn không được di chuyển đúng cách sang thiết lập mới? Có thể có nguy cơ bị hack, điều này hoàn toàn không đạt được mục đích.

Tôi sẽ đề xuất một lựa chọn khác cho bất kỳ ai lo lắng về điều này. Cũng có thể để nguyên thiết lập trình xác thực của bạn (không cần lấy khóa ra, v.v.) và chỉ cần chuyển các nút báo hiệu. Đây là rủi ro rất thấp vì miễn là ứng dụng khách của trình xác thực hoạt động như mong đợi, nó sẽ không bao giờ ký lại và do đó không thể bị tấn công. Đặc biệt nếu bạn có các hoạt động lớn trong đó việc thay đổi cơ sở hạ tầng ứng dụng khách xác thực (hoặc người ký từ xa) sẽ tốn kém và có thể phải kiểm tra, thì đây có thể là một lựa chọn tốt. Cũng dễ dàng quay lại ứng dụng khách ban đầu nếu thiết lập của bạn không hoạt động như mong đợi hoặc thử một số ứng dụng khách khác.

tiêu đề cấp đầu tiên

Còn khách hàng bị trừng phạt thì sao?

Những gì tôi đã viết ở trên áp dụng cho các máy khách Đồng thuận - Prysm, LightTower, Nimbus, Loestar và Teku, và tại thời điểm viết bài, Prysm có thể chiếm đa số 2/3 trên mạng.
Tất cả những điều này áp dụng theo cùng một cách để thực hiện các ứng dụng khách. Go-Etherum có thể sẽ là ứng dụng khách thực thi phần lớn sau khi hợp nhất và nếu nó tạo ra các khối không hợp lệ, nó có thể hoàn tất, dẫn đến thất bại thảm khốc được mô tả trong Kịch bản 3.
tiêu đề phụ

ruột thừa

Phụ lục 1: Tại sao các khối không hợp lệ không bị gạch chéo?

Trong Kịch bản 3, chúng ta phải dựa vào các rò rỉ không hoạt động bậc hai để xử phạt những người xác nhận đề xuất và bỏ phiếu cho các khối không hợp lệ. Lạ thật, tại sao chúng ta không trừng phạt họ? Nó sẽ có vẻ nhanh hơn và ít đau đớn hơn theo cách này.

Trên thực tế, có hai lý do khiến chúng tôi không - một là hiện tại chúng tôi không thể, nhưng ngay cả khi có thể, chúng tôi có thể sẽ không:

1. Hiện tại, hầu như không thể đưa ra các hình phạt ("dấu gạch chéo") đối với các khối dữ liệu không hợp lệ. Điều này là do cả chuỗi đèn hiệu và chuỗi thực thi đều không phải là "không trạng thái" - tức là để kiểm tra xem một khối có hợp lệ hay không, bạn cần có một ngữ cảnh ("trạng thái" ). Điều này có nghĩa là không có "bằng chứng ngắn gọn" rằng một khối không hợp lệ. Chúng tôi cần bằng chứng như vậy để cắt giảm trình xác thực: các khối "chém" trình xác thực cần bao gồm bằng chứng cho thấy trình xác nhận đã vi phạm luật. Trong trường hợp không có sự đồng thuận phi trạng thái, vẫn có nhiều cách giải quyết vấn đề này, nhưng nó sẽ liên quan đến các cấu trúc phức tạp hơn, chẳng hạn như bằng chứng gian lận nhiều vòng, chẳng hạn như Arbitrum hiện đang sử dụng để tổng hợp.

2. Lý do thứ hai khiến chúng tôi có thể ít háo hức hơn khi giới thiệu kiểu cắt giảm này, ngay cả khi chúng tôi có thể, là vì việc tạo ra các khối không hợp lệ khó ngăn chặn hơn so với tình trạng cắt giảm hiện tại. Điều kiện hiện tại đơn giản đến mức các máy khách của trình xác thực có thể dễ dàng xác minh nó chỉ bằng một vài dòng mã. Đó là lý do tại sao tôi nghĩ Trường hợp 1 ở trên khó xảy ra - cho đến nay, các thông báo có thể xóa được chỉ được tạo do lỗi của nhà điều hành và tôi nghĩ điều đó có thể sẽ tiếp tục. Việc thêm dấu gạch chéo để tạo ra các khối không hợp lệ (hoặc chứng minh chúng) sẽ làm tăng rủi ro cho những người nắm giữ tiền xu. Giờ đây, ngay cả những người điều hành các khách hàng thiểu số cũng có thể phải đối mặt với các hình phạt nghiêm khắc.

tiêu đề phụ

Phụ lục 2: Tại sao các khách hàng có lỗi không thể chuyển sang chuỗi B sau khi kết thúc chuỗi A?

Phần này dành cho những người muốn hiểu chi tiết hơn tại sao các máy khách bị lỗi không thể đơn giản chuyển trở lại và phải chịu sự cố rò rỉ không hoạt động đáng sợ. Để làm được điều đó, chúng ta phải xem xét cách hoạt động của quá trình hoàn thiện Casper FFG.

Mỗi bằng chứng bao gồm một điểm kiểm tra nguồn và một điểm kiểm tra đích. Một điểm kiểm tra là khối đầu tiên của một kỷ nguyên. Nếu có một liên kết từ kỷ nguyên này sang kỷ nguyên khác với tổng số hơn 2/3 tổng số phiếu bầu bị đe dọa (nghĩa là có rất nhiều bằng chứng trong đó điểm kiểm tra đầu tiên là "nguồn" và điểm kiểm tra thứ hai là "mục tiêu"), chúng tôi gọi chúng là "liên kết đa số".

Một kỷ nguyên có thể là "hợp lý" hoặc "xác định", được định nghĩa như sau:

1. Epoch 0 được căn chỉnh.

2. Một kỷ nguyên là hợp pháp nếu nó có mối liên hệ đa số với một kỷ nguyên hợp lý.

3. Nếu (1) kỷ nguyên X được căn chỉnh và (2) kỷ nguyên tiếp theo cũng được căn chỉnh và nguồn của phần lớn các liên kết là kỷ nguyên X, thì kỷ nguyên X được hoàn thiện.

Quy tắc 3 được đơn giản hóa một chút (có nhiều điều kiện hơn để kết thúc một kỷ nguyên, nhưng chúng không quan trọng đối với cuộc thảo luận này). Bây giờ, hãy xem xét các điều kiện để cắt giảm đáng kể. Có hai quy tắc để cắt bằng chứng. Cả hai đều so sánh một cặp bằng chứng V và W:

1. V và W có thể bị tấn công nếu chúng nhắm mục tiêu vào cùng một kỷ nguyên (tức là cùng độ cao), nhưng chúng không bỏ phiếu cho cùng một điểm kiểm tra (bỏ phiếu kép).

2. Điều này có nghĩa là (1) Nguồn của V sớm hơn nguồn của W và (2) Mục tiêu của V muộn hơn mục tiêu của W (bỏ phiếu kín).

Điều kiện đầu tiên là hiển nhiên: nó ngăn việc bỏ phiếu đơn giản cho hai chuỗi khác nhau có cùng chiều cao. Nhưng điều kiện thứ hai làm gì?

Chức năng của nó là cắt giảm tất cả các trình xác thực liên quan đến việc hoàn thiện hai chuỗi xung đột (điều này sẽ không bao giờ xảy ra). Để biết lý do tại sao, chúng ta hãy xem lại Kịch bản 3 của chúng ta, trong trường hợp xấu nhất sẽ có phần lớn tuyệt đối khách hàng gặp lỗi (>2/3 số tiền đặt cược). Khi nó tiếp tục bỏ phiếu cho chuỗi bị lỗi, nó sẽ hoàn thành kỷ nguyên với các khối không hợp lệ, như sau:

Các hộp tròn trong hình ảnh này đại diện cho các kỷ nguyên, không phải khối. Mũi tên màu xanh lá cây là liên kết đa số cuối cùng được tạo bởi tất cả các trình xác thực. Mũi tên đỏ là các liên kết siêu đa số chỉ được hỗ trợ bởi các ứng dụng khách có lỗi. Một máy khách đang hoạt động bỏ qua các kỷ nguyên có khối không hợp lệ (màu đỏ). Mũi tên đỏ đầu tiên sẽ xác minh kỷ nguyên không hợp lệ và mũi tên thứ hai sẽ xác định kỷ nguyên không hợp lệ.
Bây giờ, hãy giả sử rằng lỗi đã được sửa và những người xác thực cuối cùng đã xác định được kỷ nguyên không hợp lệ muốn tham gia lại đúng chuỗi B. Để có thể kết thúc chuỗi, bước đầu tiên là điều chỉnh kỷ nguyên X:

Tuy nhiên, để tham gia điều chỉnh kỷ nguyên X (yêu cầu liên kết đa số được biểu thị bằng mũi tên chấm màu xanh lá cây), họ sẽ phải "nhảy qua" mũi tên đỏ thứ hai - mũi tên cuối cùng xác định kỷ nguyên không hợp lệ. Nâng cao hai liên kết đó là một hành vi phạm tội để cắt.

Điều này sẽ tiếp tục đúng cho bất kỳ thời đại nào tiếp theo. Cách duy nhất để khắc phục là thông qua rò rỉ trạng thái không hoạt động bậc hai: khi chuỗi B phát triển, những người xác nhận bị khóa sẽ làm rò rỉ tiền của họ cho đến khi chuỗi B có thể được chứng minh và hoàn thiện bởi các khách hàng đang hoạt động.