Vitalik: Hỗ trợ đặt cược phi tập trung với nhiều ưu đãi chống tương quan hơn

Tác giả: Vitalik Buterin, @vitalik.eth; Biên soạn bởi: Songxue, Golden Finance

Thỏa thuận khuyến khích Một chiến lược để phân cấp tốt hơn là trừng phạt mối tương quan. Nghĩa là, nếu một người tham gia có hành vi sai trái (kể cả vô tình), thì càng có nhiều người tham gia khác có hành vi sai trái cùng lúc với họ (được đo bằng tổng ETH), họ sẽ nhận được hình phạt càng lớn. Lý thuyết cho rằng nếu bạn là một người chơi lớn, bất kỳ sai lầm nào bạn mắc phải đều có nhiều khả năng được lặp lại trên tất cả "danh tính" mà bạn kiểm soát, ngay cả khi bạn chia số token của mình ra nhiều tài khoản riêng biệt trên danh nghĩa .

Công nghệ này đã được sử dụng trong cơ chế cắt giảm (và được cho là rò rỉ không hoạt động) của Ethereum. Tuy nhiên, các ưu đãi trong trường hợp cạnh chỉ phát sinh trong các tình huống tấn công rất cụ thể có thể không bao giờ thành hiện thực trong thực tế và có thể không đủ khuyến khích Phân cấp.

Bài viết này đề xuất mở rộng các khuyến khích chống tương quan tương tự cho các trường hợp thất bại "tầm thường" hơn, ví dụ như bỏ sót một bằng chứng, gần như tất cả người xác nhận thỉnh thoảng làm điều này. Lý thuyết là những người đặt cược lớn hơn, bao gồm cả những cá nhân giàu có và nhóm đặt cược, sẽ chạy nhiều trình xác thực trên cùng một kết nối internet hoặc thậm chí trên cùng một máy tính vật lý, điều này sẽ gây ra số lượng lỗi liên quan không tương xứng. Những người đặt cược như vậy luôn có thể có các thiết lập vật lý riêng biệt cho từng nút, nhưng nếu họ làm điều đó, điều đó có nghĩa là chúng tôi đã loại bỏ hoàn toàn tính kinh tế theo quy mô khỏi việc đặt cược.

Kiểm tra độ chính xác: Các lỗi từ các trình xác thực khác nhau trong cùng một "cụm" có thực sự có nhiều khả năng tương quan hơn không?

Chúng ta có thể kiểm tra điều này bằng cách kết hợp hai bộ dữ liệu: (i) dữ liệu chứng thực cho một số kỷ nguyên gần đây, cho biết người xác nhận nào lẽ ra phải chứng thực trong mỗi khoảng thời gian và người xác thực nào thực sự đã chứng thực và (ii) ánh xạ ID trình xác thực cho đến dữ liệu có sẵn công khai chứa các cụm gồm nhiều trình xác thực (ví dụ: “Lido”, “Coinbase”, “Vitalik Buterin”). Bạn có thể kiểm tra tại đây, tại đây và tại đây  Một bãi chứa trước đây đã được tìm thấy tại đây  bãi chứa của orer.

Sau đó, chúng tôi chạy tập lệnh để đếm tổng số lần đồng lỗi: các trường hợp của hai trình xác thực trong cùng một cụm được chỉ định để chứng thực trong cùng một khoảng thời gian đều không thành công trong khoảng thời gian đó.

Chúng tôi cũng tính toán Các lỗi thường gặp:Số lỗi phổ biến "có thể xảy ra" nếu lỗi hoàn toàn là do ngẫu nhiên.

Ví dụ: giả sử có 10 trình xác thực có kích thước cụm là 4, các cụm còn lại độc lập và 3 trình xác thực không thành công: 2 trình xác thực trong cụm và một trình xác thực bên ngoài cụm .

Có một điểm chung chủ đề ở đây Lỗi: Trình xác thực thứ 2 và thứ 4 trong cụm đầu tiên. Nếu cả bốn trình xác nhận trong cụm đều thất bại thì sẽ có sáu lỗi phổ biến, cứ sáu cặp có thể có một lỗi.

Nhưng “nên” có bao nhiêu thất bại phổ biến? Đây là một câu hỏi triết học hóc búa. Một số cách trả lời:

Đối với mỗi lỗi, giả sử rằng số lỗi phổ biến bằng tỷ lệ lỗi của các trình xác nhận khác trong vùng đó nhân với số lượng trình xác nhận trong cụm và giảm một nửa xuống Bồi thường cho việc đếm đôi. Đối với ví dụ trên, 2/3 được đưa ra.

Tính tỷ lệ thất bại chung, bình phương nó rồi nhân với [n*(n-1)]/2 cho mỗi cụm. Điều này được đưa ra bởi [(3/10)^2]*6=0.54

Phân phối lại ngẫu nhiên các lỗi của từng trình xác thực trong suốt lịch sử của nó.

Không phải phương pháp nào cũng hoàn hảo. Hai phương pháp đầu tiên không tính đến các cụm khác nhau có cài đặt chất lượng khác nhau. Đồng thời, cách tiếp cận cuối cùng không tính đến các mối tương quan phát sinh từ các vị trí khác nhau với những khó khăn cố hữu khác nhau: ví dụ: vị trí 8103681 có một số lượng lớn bằng chứng không được đưa vào một vị trí duy nhất, có thể do khối có các lỗi bất thường. muộn để phát hành.

Xem "10216 ssfumbles" trong đầu ra python này.

Cuối cùng tôi đã triển khai ba phương pháp: hai phương pháp đầu tiên ở trên và một phương pháp phức tạp hơn trong đó tôi so sánh "đồng lỗi thực tế" với "đồng lỗi giả": Mỗi thành viên cụm là được thay thế bằng trình xác thực ngẫu nhiên (giả) không thành công với tỷ lệ thất bại tương tự.

Tôi cũng phân biệt rõ ràng giữa Sai lầm và Bỏ lỡ. Tôi định nghĩa các thuật ngữ này như sau:

Lỗi: Khi người xác thực bỏ sót chứng minh ở kỳ hiện tại, nhưng đã chứng minh đúng ở kỳ trước;

Bỏ sót: Khi người xác thực bỏ lỡ một bằng chứng ở kỷ nguyên hiện tại và cũng bỏ sót một bằng chứng ở kỷ nguyên trước đó.

Mục đích là để phân biệt giữa hai hiện tượng riêng biệt: (i) lỗi mạng trong quá trình hoạt động bình thường và (ii) lỗi ngoại tuyến hoặc lỗi lâu dài.

Tôi cũng thực hiện phân tích này cùng lúc trên hai bộ dữ liệu: thời hạn tối đa và thời hạn một thời điểm. Tập dữ liệu đầu tiên sẽ coi trình xác thực là không thành công trong một kỷ nguyên nếu nó không chứa bằng chứng nào cả. Tập dữ liệu thứ hai coi trình xác thực là không thành công nếu bằng chứng không được chứa trong một vị trí.

Đây là kết quả của tôi về hai phương pháp đầu tiên tính toán các hư hỏng thường gặp dự kiến. Ở đây SSfumbles và SSmisses đề cập đến việc dò tìm và bỏ sót khi sử dụng tập dữ liệu một khe.

Đối với loại đầu tiên Các phương thức, dòng thực tế khác nhau vì tập dữ liệu hạn chế hơn được sử dụng để cải thiện hiệu quả:

Các cột "Dự kiến" và "Cụm giả" hiển thị số lượng lỗi phổ biến "nên" xuất hiện trong cụm nếu các cụm không liên quan, dựa trên kỹ thuật trên. Cột "Thực tế" cho biết thực tế có bao nhiêu lỗi phổ biến. Một cách nhất quán, chúng tôi nhận thấy bằng chứng mạnh mẽ về “các lỗi tương quan quá mức” trong một cụm: hai trình xác thực trong cùng một cụm có nhiều khả năng bỏ sót các chứng thực cùng lúc hơn đáng kể so với hai trình xác thực trong các cụm khác nhau.

Chúng ta áp dụng điều này vào các quy tắc phạt như thế nào?

Tôi đã đưa ra một lập luận đơn giản: trong mỗi vị trí, gọi p là số vị trí bị bỏ lỡ hiện tại chia cho mức trung bình của 32 vị trí cuối cùng.

Khoảng thời gian này chứng tỏ Hình phạt phải tỷ lệ thuận với p.

Tức là, Hình phạt cho việc không chứng minh được một vị trí sẽ giống như các vị trí gần nhất khác Tỷ lệ thuận với số lượng trình xác nhận không thành công trong vị trí đó.

Một đặc điểm hay của cơ chế này là nó không dễ bị tấn công: thất bại trong mọi trường hợp sẽ giảm bớt hình phạt của bạn và việc thao túng mức trung bình là đủ. Để tạo ra tác động đòi hỏi rất nhiều nỗ lực. thất bại của chính mình.

Bây giờ, hãy thử chạy nó. Sau đây là tổng số hình phạt đối với bốn phương án phạt đối với cụm lớn, cụm trung bình, cụm nhỏ và tất cả người xác thực (bao gồm cả người không phải cụm):

Cơ bản: Một điểm cho mỗi lỗi (tức là tương tự như hiện trạng)

basic_ss:Tương tự, nhưng cần bao gồm một vị trí duy nhất để được tính là lỗi

Vượt quá : Sử dụng p được tính ở trên để trừng phạt điểm p

extra_ss:Sử dụng p được tính ở trên để trừng phạt điểm p, yêu cầu các lần bao gồm một ô không được tính là bỏ lỡ

Sử dụng "cơ bản ", giải pháp lớn hơn sẽ tốt hơn giải pháp nhỏ hơn. Có lợi thế khoảng 1,4 lần (khoảng 1,2 lần trong tập dữ liệu một khe). Sử dụng kịch bản "bổ sung", giá trị này giảm xuống khoảng 1,3 lần (khoảng 1,1 lần trong tập dữ liệu một vị trí). Thông qua một số lần lặp lại khác, sử dụng các bộ dữ liệu hơi khác nhau, kế hoạch phạt quá mức đã thu hẹp một cách thống nhất lợi thế của "kẻ lớn" so với "kẻ nhỏ".

Chuyện gì đang xảy ra vậy?

Số lượng lỗi trên mỗi khe ít: thường chỉ vài chục. Số tiền đó nhỏ hơn nhiều so với hầu hết bất kỳ "cổ phần lớn" nào. Trên thực tế, nó ít hơn số lượng người xác thực đang hoạt động trong một vị trí dành cho những người đặt cọc lớn (tức là 1/32 tổng số cổ phiếu của họ). Nếu một nhà đầu tư lớn chạy nhiều nút trên cùng một máy tính vật lý hoặc kết nối internet, thì bất kỳ lỗi nào cũng có thể ảnh hưởng đến tất cả các trình xác thực của nó.

Điều này có nghĩa là: Khi một trình xác thực lớn không chứng minh được sự bao gồm, họ sẽ tự mình thay đổi vị trí hiện tại. tỷ lệ thất bại, do đó làm tăng hình phạt của họ. Trình xác nhận nhỏ không làm điều này.

Về nguyên tắc, các cổ đông lớn có thể tránh được âm mưu trừng phạt này bằng cách đặt mỗi trình xác thực trên một kết nối Internet riêng biệt. Nhưng điều này phải trả giá bằng lợi ích kinh tế nhờ quy mô khi có thể tái sử dụng cơ sở hạ tầng vật chất giống nhau giữa các bên liên quan lớn.

Phân tích sâu hơn

• Tìm các chiến lược khác để Xác nhận mức độ của hiệu ứng này, những người xác thực trong cùng một cụm có khả năng không thể chứng thực cùng một lúc.

• Cố gắng tìm ra kế hoạch thưởng/phạt lý tưởng (nhưng vẫn đơn giản để không bị quá tải và không thể khai thác được) nhằm giảm thiểu lợi thế trung bình của các trình xác nhận lớn so với các trình xác nhận nhỏ .

• Cố gắng chứng minh các đặc tính bảo mật của các kế hoạch khuyến khích như vậy, lý tưởng nhất là xác định một "khu vực không gian thiết kế" nơi có nguy cơ xảy ra các cuộc tấn công lạ (ví dụ: chuyển sang chế độ ngoại tuyến một cách chiến lược vào những thời điểm cụ thể để thao túng trung bình) thì quá tốn kém và không đáng.

• Phân cụm theo vị trí địa lý. Điều này có thể xác định liệu cơ chế này có khuyến khích phân cấp địa lý hay không.

• Phân cụm thông qua phần mềm máy khách (thực thi và báo hiệu). Điều này có thể xác định liệu cơ chế này có khuyến khích một số ít khách hàng sử dụng hay không.