Giải pháp thay thế cho Beacon Chain: Mô hình cuối cùng dựa trên Ủy ban tích lũy

Nguồn | ethresear.ch

Tác giả | Vitalik Buterin

Đây là một thiết kế thay thế được đề xuất cho chuỗi đèn hiệu, có thể được chuyển sang mô hình này trong tương lai xa (thay thế CBC hiện đang được lên kế hoạch) và nó cố gắng cung cấp các tính năng chính sau:

➤ Trong các trường hợp bình thường, hãy cung cấp sự chắc chắn về kinh tế cho một vị trí có ý nghĩa (tức là các thuộc tính giống như Tendermint)

• Ngay cả khi phần lớn các trình xác nhận tham gia thông đồng để tổ chức lại một vị trí duy nhất, chi phí thực hiện vẫn cao hơn nhiều so với hiện tại, do đó làm giảm giá trị có thể trích xuất đồng thuận (CEV)

➤ Loại bỏ sự phụ thuộc nhiều vào lựa chọn ngã ba LMD GHOST, tránh những lỗi đã biết và cần giới thiệuQuy tắc lựa chọn phuộc hybrid phức tạp, để khắc phục những khiếm khuyết này.

➤ Tiềm năng kích hoạt quy mô tiền gửi tối thiểu thấp hơn và số lượng người xác thực cao hơn

kiến thức sơ bộ

kiến thức sơ bộ

Hãy để CONSENSUS là một thuật toán đồng thuận an toàn không đồng bộ (ví dụ: Tendermint, Casper FFG, v.v.). Chúng tôi giả định rằng thuật toán đồng thuận được thiết kế để liên quan đến các vị trí và lượt xem (lượt xem lượt xem), tức là nó cố gắng đạt được sự đồng thuận trong mỗi khoảng thời gian cố định. Chúng tôi cũng giả định rằng nó lấy đầu vào là một tập hợp các trình xác thực có trọng số (một thuộc tính dễ dàng thêm vào các thuật toán đồng thuận BFT hiện có).

Trong thiết kế bên dưới, chúng tôi sửa đổi SỰ ĐỒNG Ý để tập hợp các trình xác thực được yêu cầu hoàn thiện là khác nhau cho mỗi lần tra cứu. Nghĩa là, CONSENSUS được sử dụng thay cho trình xác thực được đặt làm đầu vào của hàm get_validator_set(view_number: int) -> Map[Validator, int] (trong đó int đại diện cho số dư của trình xác thực), có thể tạo ra chế độ xem mới của trình xác thực đặt . get_validator_set phải có thuộc tính mà bộ trình xác thực thay đổi tối đa 1/r từ chế độ xem này sang chế độ xem tiếp theo, trong đó r (r=65536 ) là độ dài thời gian khôi phục. Chính thức hơn, chúng tôi hy vọng rằng:

Trong số đó, |x| trả về tổng giá trị tuyệt đối của các giá trị x và diff trả về giá trị sau khi trừ từng giá trị khóa (ví dụ: diff({a:0.1, b:0.2}, {b:0.1 , c:0,3}) = {a: 0,1, b: 0,1, c: -0,3}).

Trên thực tế, sự khác biệt giữa hai bộ trình xác thực liền kề sẽ bao gồm số dư đã khấu trừ của các trình xác thực hiện có và tỷ lệ của các trình xác thực mới được thêm vào bằng với tỷ lệ của số dư đã khấu trừ.

Lưu ý rằng chức năng delta bộ xác thực tối đa của 1/r chỉ khả dụng nếu các trình xác thực trước đó chưa được hoàn thiện. Nếu bộ trình xác thực trước đó đã được hoàn thiện, phiên bản của CONSENSUS sẽ thay đổi, do đó, tính ngẫu nhiên bên trong của hàm get_validator_set cũng sẽ thay đổi hoàn toàn; trong trường hợp này, hai bộ trình xác thực liền kề sẽ trở nên hoàn toàn khác nhau.

cơ chế

cơ chế

Chúng tôi sử dụng hai cấp độ lựa chọn ngã ba:

➤ Chọn LATEST_FINALIZED_BLOCK (khối hoàn thiện mới nhất)

➤ Bắt đầu với LATEST_FINALIZED_BLOCK, hãy sử dụng các lựa chọn rẽ nhánh khác (ví dụ: LMD GHOST) để chọn tiêu đề khối

Thuật toán CONSENSUS có thể được xem một lần trên mỗi vị trí, lấy đầu vào là hàm tạo bộ xác thực dựa trên dữ liệu được tạo bởi get_post_state(LATEST_FINALIZED_BLOCK). Đề xuất hợp lệ phải chứa khối con hợp lệ LATEST_FINALIZED_BLOCK. Người xác thực chuẩn bị và bỏ phiếu cho các đề xuất khối chỉ khi phần đó thắng lựa chọn fork và trở thành một phần của chuỗi khối.

Mô tả hình ảnh

Lưu ý: vị trí phải luôn bằng số chế độ xem hiện tại cộng với tổng số chế độ xem của từng bộ trình xác thực đã hoàn tất thành công trước đó.

Ta có các hình phạt sau:

➤ Hình phạt chặt chém thông thường được xác định bởi thuật toán đồng thuận

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

Thay thế FFG: Casper FFG một khe cắm

Một giải pháp thay thế cho thiết kế trên là sử dụng Casper FFG, nhưng làm cho các epoch bằng với độ dài của khe. Casper FFG hoạt động khác vì nó không cố gắng ngăn chặn cùng một ủy ban hoàn thiện một khối và hậu duệ của nó. Để phù hợp với sự khác biệt này, chúng tôi cần thực thi (i) ngưỡng an toàn là 1/4 thay vì 1/3, (ii) quy tắc rằng nếu một vị trí hoàn tất, bộ trình xác thực sẽ thay thế tối đa 1/4 thay vì hoàn toàn .

Lưu ý rằng trong một thiết kế như vậy, về mặt lý thuyết, việc thực hiện sắp xếp lại một vị trí (nhưng không nhiều hơn một vị trí) là miễn phí. Ngoài ra, ở phần cuối của biểu đồ "lên đến vị trí để có độ chính xác tối đa"tiêu đề cấp đầu tiên

đặc trưng

Nếu một khối được hoàn thiện, một trong những điều sau đây cần xảy ra để các khối cạnh tranh của nó được hoàn thiện:

➤ Đã xảy ra sự cố với một ủy ban và ≥1/3 số người xác thực đã bị cắt giảm do hoàn thiện hai lần một khối khác

➤ Ủy ban gần đây nhất đã ngoại tuyến và sau các vị trí r/3, ủy ban đã xáo trộn đủ để hoàn thiện một khối khác mà không bị cắt giảm. Tuy nhiên, điều này đi kèm với một hình phạt phá hoại nặng nề (≥1/3 số dư của kẻ tấn công)

Trong cả hai trường hợp, ngay cả việc khôi phục một khối đã hoàn thiện cũng yêu cầu ít nhất DEPOSIT_SIZE * COMMITTEE_SIZE / 3 (số tiền gửi * kích thước ủy ban / 3) ETH bị đốt cháy. Nếu chúng ta đặt COMMITTEE_SIZE = 131.072 (số lượng trình xác nhận trên mỗi vị trí của ủy ban Eth2, tối đa theo lý thuyết là 4 triệu), thì giá trị này là 1.398.101 ETH.

Một số tính năng quan trọng khác trong giải pháp bao gồm:

➤ Bất kể có bao nhiêu trình xác thực đã ký gửi, tải của trình xác thực vẫn ổn định khi xử lý các giao dịch COMMITTEE_SIZE (kích thước ủy ban) trên mỗi vị trí

➤ Tải của người xác thực sẽ thấp hơn vì họ có thể ngủ khi không bắt buộc phải tham gia ủy ban

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

Mở rộng quy mô: Xác nhận chuỗi với các Ủy ban nhỏ

Nếu chúng tôi phải giảm COMMITTEE_SIZE để đạt hiệu quả, chúng tôi có thể thực hiện các điều chỉnh sau:

➤ Chúng tôi đã đổi tên "quyết toán" thành "xác nhận" để phản ánh rằng một xác nhận duy nhất không còn đại diện cho kết quả cuối cùng thực sự

➤ Khác với việc chọn khối được xác nhận mới nhất, chúng tôi chọn khối được xác nhận có đầu chuỗi dài nhất của khối được xác nhận (nhưng từ chối khôi phục các khối được xác nhận bởi COMMITTEE_LOOKAHEAD, vì vậy xác nhận của COMMITTEE_LOOKAHEAD thể hiện tính hữu hạn thực sự)

➤ get_validator_set chỉ nên sử dụng thông tin trạng thái, không dùng COMMITTEE_LOOKAHEAD trước khi xác nhận

➤ Số lượng chế độ xem phải là số lượng vị trí (điều này giúp dễ dàng suy luận rằng cùng một bộ trình xác thực đang cố gắng đạt được sự đồng thuận trên các chuỗi khác nhau, điều này chỉ có thể xảy ra khi một số xác nhận bị hỏng)

Sơ đồ này giữ lại tất cả các tính năng trên, nhưng nó cũng giới thiệu một tính năng mới: nếu một khối nhận được nhiều xác nhận (ví dụ: khối được hoàn thiện và các khối con của chuỗi nhận được k-1 Xác nhận, bởi vì tổng số k xác nhận liên tiếp sẽ ảnh hưởng đến khối), sau đó khôi phục khối cần vi phạm đảm bảo đồng thuận trong nhiều ủy ban. Điều này cho phép các mức bảo mật từ nhiều ủy ban chồng chất lên nhau: khôi phục k xác nhận yêu cầu COMMITTEE_SIZE * DEPOSIT_SIZE * k / 3 ETH và phải mất k = COMMITTEE_LOOKAHEAD để các ủy ban phân kỳ.

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

Ví dụ về các giá trị cụ thể

Lưu ý rằng "ETH cần thiết để phá vỡ tài chính"Con số giả định rằng kẻ tấn công kiểm soát số lượng trình xác nhận tương đương với việc kiểm soát hơn một nửa tổng số ETH đã đặt cược (tức là hàng triệu ETH); con số này là ETH mà kẻ tấn công sẽ mất. Nhưng điều này không có nghĩa là bất kỳ ai có 2.730, 174.762 ETH đều có thể quay lại một vị trí bằng cách đốt ngẫu nhiên những ETH này.

Liên kết gốc: https://ethresear.ch/t/a-model-for-cumulative-committee-basing-finality/10259