Đề xuất đơn giản hóa PoS của Vitalik: sử dụng 8192 chữ ký trên mỗi vị trí sau SSF

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

Sự khác biệt chính giữa Ethereum và hầu hết các hệ thống bằng chứng cổ phần (cuối cùng) khác là Ethereum cố gắng hỗ trợ rất nhiều đối tượng trình xác thực: Chúng tôi hiện có 895.000 đối tượng trình xác thực và phân tích Luật Zipf đơn giản cho thấy rằng điều này tương ứng với hàng chục nghìn đối tượng trình xác thực là những cá nhân/thực thể duy nhất. Mục đích của việc này là để hỗ trợ phân cấp và thậm chí cho phép các cá nhân bình thường tham gia đặt cược mà không yêu cầu mỗi người từ bỏ quyền đại diện của mình và trao quyền kiểm soát cho một trong số ít nhóm đặt cược.

Tuy nhiên, cách tiếp cận này yêu cầu chuỗi Ethereum xử lý một số lượng lớn chữ ký trên mỗi vị trí (khoảng 28.000 ngày nay; 1.790.000 sau SSF), đây là một mức tải rất cao. Việc hỗ trợ tải trọng này đòi hỏi phải hy sinh đáng kể về mặt kỹ thuật:

• Điều này đòi hỏi một cơ chế lan truyền bằng chứng phức tạp, liên quan đến việc phân tách bằng chứng trên nhiều mạng con, hoạt động chữ ký BLS cần phải được tối ưu hóa siêu tốc để xác minh các chữ ký đó, v.v.

• Chúng ta không có giải pháp thay thế rõ ràng nào đủ hiệu quả và kháng lượng tử.

• Các bản sửa lỗi chọn nhánh như hợp nhất chế độ xem trở nên phức tạp hơn vì không thể trích xuất được các chữ ký riêng lẻ.

• SNARKing chữ ký rất khó vì số lượng lớn. Helios cần hoạt động trên một chữ ký bổ sung chuyên dụng, được gọi là chữ ký ủy ban đồng bộ.

• Nó tăng khe thời gian tối thiểu an toàn bằng cách yêu cầu ba khe thời gian con trong một khe thời gian thay vì hai.

Hệ thống tổng hợp chữ ký thoạt nhìn có vẻ hợp lý nhưng thực tế nó tạo ra sự phức tạp mang tính hệ thống, thấm sâu vào mọi khía cạnh.

Hơn nữa, nó thậm chí còn không đạt được mục đích của mình. Yêu cầu tối thiểu để đặt cược vẫn là 32 ETH, vượt quá khả năng của nhiều người. Chỉ từ một phân tích logic, về lâu dài, có vẻ như không khả thi đối với một hệ thống mà mọi người đăng nhập thực sự cung cấp dịch vụ đặt cược cho người bình thường: Nếu Ethereum có 500 triệu người dùng và 10% trong số họ cam kết, thì điều này có nghĩa là Có 100 triệu chữ ký trên mỗi khe. Theo thuật ngữ lý thuyết thông tin, việc cắt giảm xử lý trong thiết kế này yêu cầu ít nhất 12,5 MB dung lượng trống dữ liệu trên mỗi khe, gần bằng mục tiêu của daksharding đầy đủ (!!!). Có lẽ có thể thực hiện được, nhưng việc yêu cầu bản thân việc đặt cược dựa vào việc lấy mẫu dữ liệu sẵn có sẽ dẫn đến mức độ phức tạp lớn - ngay cả khi đó chỉ là khoảng 0,6% dân số đặt cược trên thế giới và điều đó thậm chí còn không bắt đầu vướng vào các vấn đề tính toán khi xác minh rất nhiều chữ ký.

Vì vậy, thay vì dựa vào các nhà mật mã để tạo ra những viên đạn ma thuật (hoặc áo giáp ma thuật) nhằm tạo ra số lượng chữ ký ngày càng tăng trong mỗi khoảng thời gian, tôi đề xuất chúng ta thực hiện một sự thay đổi triết học: từ Let bắt đầu với những kỳ vọng như vậy. Điều này sẽ mở rộng đáng kể không gian thiết kế PoS và cho phép đơn giản hóa nhiều kỹ thuật, làm cho nó an toàn hơn bằng cách cho phép Helios SNARK trực tiếp trên cơ chế đồng thuận Ethereum và bằng cách tạo ra các kế hoạch chữ ký lâu đời thậm chí nhàm chán như Winternitz. giải quyết vấn đề kháng lượng tử.

Tại sao không "chỉ dùng ủy ban"?

Nhiều chuỗi khối không phải Ethereum gặp phải vấn đề chính xác này sử dụng cách tiếp cận dựa trên ủy ban để bảo mật. Trong mỗi khoảng thời gian, họ chọn ngẫu nhiên N trình xác nhận (ví dụ: N xấp xỉ bằng 1000) và những trình xác nhận này chịu trách nhiệm hoàn thành khoảng thời gian đó. Cần phải nhắc lại lý do tại sao cách tiếp cận này lại thất bại: nó thiếu trách nhiệm giải trình.

Để hiểu lý do tại sao, hãy giả sử một cuộc tấn công 51% xảy ra. Đây có thể là một cuộc tấn công đảo ngược cuối cùng hoặc một cuộc tấn công kiểm duyệt. Để phát động một cuộc tấn công, tác nhân kinh tế kiểm soát phần lớn cổ phần vẫn cần phải đồng ý thực hiện cuộc tấn công, tức là chạy phần mềm tham gia cuộc tấn công, cùng với tất cả những người xác nhận cuối cùng được bầu vào ủy ban. Toán học lấy mẫu ngẫu nhiên đảm bảo điều này. Tuy nhiên, hình phạt mà họ phải chịu cho một cuộc tấn công như vậy là nhỏ vì hầu hết những người xác nhận đồng ý với cuộc tấn công đều không được nhìn thấy vì họ không được bầu vào ủy ban.

Hiện tại, Ethereum đã đi theo hướng ngược lại. Trong trường hợp xảy ra cuộc tấn công 51%, phần lớn toàn bộ bộ trình xác thực tấn công sẽ bị cắt khỏi cổ phần của họ. Chi phí hiện tại của cuộc tấn công là khoảng 9 triệu ETH (khoảng 20 tỷ USD) và điều này giả định rằng việc đồng bộ hóa mạng bị gián đoạn theo cách tối đa hóa lợi ích của kẻ tấn công.

Tôi cho rằng đây là một cái giá cao, một cái giá quá cao và chúng ta có thể hy sinh một số trong vấn đề này. Ngay cả khi chi phí tấn công là 1-2 triệu ETH thì cũng hoàn toàn đủ. Ngoài ra, rủi ro tập trung chính hiện có trong Ethereum nằm ở một chỗ hoàn toàn khác: nếu số tiền đặt cược tối thiểu giảm xuống gần bằng 0, quy mô lớn Sự khác biệt về sức mạnh của nhóm đặt cược sẽ không quá lớn.

Đây là lý do tại sao tôi ủng hộ một giải pháp nhẹ nhàng: trong trình xác minh Nó tạo ra một số hy sinh về trách nhiệm giải trình nhưng vẫn giữ tổng số ETH có thể cắt được khá cao và đổi lại, nó mang lại cho chúng ta hầu hết lợi ích của một bộ trình xác thực nhỏ hơn.

8192 chữ ký trên mỗi khe thời gian sẽ trông như thế nào trong SSF?

Giả sử giao thức đồng thuận hai vòng truyền thống (tương tự như những gì Tendermint sử dụng và những gì SSF chắc chắn sẽ sử dụng), mỗi trình xác thực tham gia yêu cầu hai chữ ký cho mỗi khe thời gian. Chúng ta cần phải vượt qua thực tế này. Tôi thấy ba cách chính chúng ta có thể làm điều này.

Phương pháp 1: Tập trung toàn lực vào các nhóm đặt cược phi tập trung

Python có một câu nói rất quan trọng:< / p>

Nên có một - tốt nhất là chỉ một - cách rõ ràng để thực hiện việc này.

Liên quan đến vấn đề cân bằng đặt cược, Ethereum hiện đang vi phạm quy tắc này vì chúng tôi đang thực hiện hai chiến lược khác nhau cùng lúc để đạt được mục tiêu này:< span style ="color: rgb(0, 112, 192);">(i) đặt cược riêng lẻ quy mô nhỏ và (ii) nhóm đặt cược phi tập trung sử dụng Công nghệ xác thực phân tán (DVT). Vì những lý do trên, (i) chỉ có thể hỗ trợ một nhóm nhỏ người đặt cược riêng lẻ; sẽ luôn có nhiều người có số tiền gửi tối thiểu quá lớn. Tuy nhiên, Ethereum đang phải trả một gánh nặng kỹ thuật rất cao để hỗ trợ (i).

Một giải pháp khả thi là bỏ (i) và dồn hết sức vào ( ii). Chúng tôi có thể tăng số tiền cam kết tối thiểu lên 4096 ETH và đặt tổng giới hạn là 4096 trình xác thực (khoảng 16,7 triệu ETH). Những người đặt cược nhỏ dự kiến ​​​​sẽ tham gia nhóm DVT: bằng cách cung cấp vốn hoặc trở thành nhà điều hành nút. Để ngăn chặn những kẻ tấn công lạm dụng, vai trò của người điều hành nút cần phải được giới hạn bởi danh tiếng theo một cách nào đó và các nhóm sẽ cạnh tranh với nhau bằng cách đưa ra các tùy chọn khác nhau về vấn đề này. Việc tài trợ sẽ không được phép.

Chúng ta có thể làm cho việc đặt cược tập thể trong mô hình này trở nên "dễ tha thứ" hơn bằng cách hạn chế các hình phạt chẳng hạn. đến 1/8 tổng số tiền cam kết được cung cấp. Điều này sẽ làm giảm niềm tin vào các nhà khai thác nút, mặc dù cần thận trọng khi tiếp cận do các vấn đề được nêu ở đây.

Phương pháp 2: Cam kết hai cấp

Chúng tôi tạo ra hai cấp độ người đặt cược: một cấp độ “nặng”, yêu cầu 4096 ETH, để tham gia quyết toán và một cấp độ “nhẹ”, không có yêu cầu đặt cược tối thiểu (và không có sự chậm trễ khi gửi và rút tiền và nguy cơ không cắt giảm), điều này bổ sung thêm một lớp bảo mật khác. Để một khối là cuối cùng, cả lớp nặng cần hoàn thiện nó và lớp nhẹ cần >= 50% trình xác thực nhẹ trực tuyến để chứng thực khối đó.

Tính không đồng nhất này có lợi cho khả năng chống kiểm duyệt và chống tấn công, bởi vì để một cuộc tấn công thành công, cả lớp nặng và lớp nhẹ đều cần phải bị hỏng. Nếu lớp này bị hỏng còn lớp kia không thì dây chuyền sẽ dừng lại, nếu lớp nặng bị hỏng thì có thể bị trừng phạt.

Một lợi ích khác của phương pháp này là lớp nhẹ có thể bao gồm ETH cũng được sử dụng làm tài sản thế chấp trong ứng dụng. Nhược điểm chính là nó làm cho việc đặt cược trở nên kém bình đẳng hơn bằng cách thiết lập sự phân chia giữa những người đặt cược nhỏ và lớn.

Phương pháp 3: Thay phiên nhau tham gia (tức là ủy ban nhưng chịu trách nhiệm)

Chúng tôi áp dụng cách tiếp cận tương tự với thiết kế siêu ủy ban được đề xuất ở đây: đối với mỗi vị trí, chúng tôi chọn 4096 trình xác thực hiện đang hoạt động và bộ sưu tập của chúng tôi được điều chỉnh cẩn thận để đảm bảo chúng tôi vẫn an toàn.

Tuy nhiên, chúng tôi đã thực hiện một số lựa chọn tham số khác nhau để đạt được "mức tăng tối đa" trong khuôn khổ này. Đặc biệt, chúng tôi cho phép người xác thực tham gia với số dư cao tùy ý và nếu người xác thực sở hữu nhiều hơn một lượng M ETH nhất định (phải thả nổi), thì họ sẽ tham gia vào ủy ban mỗi thời đại. Nếu người xác thực có N<M ETH thì họ có N/M xác suất có mặt trong ủy ban trong bất kỳ khoảng thời gian nhất định nào.

Một đòn bẩy thú vị mà chúng tôi có ở đây là tách "trọng số" nhằm mục đích khuyến khích khỏi "trọng số" nhằm mục đích đồng thuận: phần thưởng cho mỗi người xác thực trong ủy ban phải giống nhau (ít nhất là đối với ≤M Trình xác thực ETH) để giữ phần thưởng trung bình theo tỷ lệ. Chúng tôi vẫn có thể thống nhất số lượng người xác nhận trong ủy ban, tính theo ETH. Điều này đảm bảo rằng việc phá vỡ tính hữu hạn yêu cầu số lượng ETH bằng hơn một phần ba tổng số ETH trong ủy ban.

Phân tích luật của Zipf sẽ tính toán số lượng ETH như sau:

• < p>Ở mỗi cấp bậc hai của tổng số dư, số lượng người xác nhận tỷ lệ nghịch với mức số dư đó và tổng số dư của những người xác thực này sẽ giống nhau.

• Do đó, ủy ban sẽ có số lượng ETH tham gia bằng nhau từ mọi cấp độ số dư ngoại trừ các cấp trên rào cản M (người xác nhận luôn có mặt trong ủy ban).

• Do đó, chúng tôi có cấp độ Log2 (M) trong mỗi trình xác thực K ở cấp độ trên và xác minh cấp độ K+K/2+...=2K ở trên By. Do đó, K=4096/Log2(M)+2.

• Trình xác thực lớn nhất sẽ có M*k ETH. Chúng ta có thể làm ngược lại: nếu trình xác nhận lớn nhất có 2^18=262144 ETH, điều này có nghĩa là (khoảng) M = 1024 và k = 256.

• Tổng số ETH cam kết là:

  Tổng vốn sở hữu của 512 trình xác thực hàng đầu (2^18*1+2^17*2+ … +2^10*2^8=2359296)

  Thêm mức đặt cược nhỏ hơn của việc lấy mẫu ngẫu nhiên (2^8*(2^9+2^8+2^7...) xấp xỉ bằng 2^ 8*2^10=2^18)

  Chúng tôi đã thu được tổng cộng 2.621.440 ETH, hay chi phí tấn công là khoảng 900k ETH.

Nhược điểm chính của phương pháp này là nó tạo ra một số phức tạp hơn trong giao thức để đạt được bảo mật đồng thuận theo cách cho phép chúng tôi vẫn đạt được bảo mật đồng thuận khi ủy ban thay đổi phương pháp chọn ngẫu nhiên người xác nhận.

Ưu điểm chính là nó vẫn giữ được hình thức đặt cược độc lập dễ nhận biết, giữ lại một hệ thống duy nhất và thậm chí cho phép giảm số tiền đặt cược tối thiểu xuống mức rất thấp (ví dụ: 1 ETH).

Tóm tắt

Nếu chúng tôi xác định rằng sau giao thức SSF, chúng tôi muốn tuân theo 8192 Signatures, sẽ giúp cuộc sống của những người triển khai kỹ thuật cũng như những người xây dựng cơ sở hạ tầng hỗ trợ như các máy khách nhẹ trở nên dễ dàng hơn. Mọi người có thể điều hành một ứng dụng khách đồng thuận trở nên dễ dàng hơn và người dùng, những người đam mê đặt cược và những người khác có thể ngay lập tức thực hiện giả định này. Tải trong tương lai của giao thức Ethereum không còn là ẩn số nữa: nó có thể được cải thiện trong tương lai thông qua các nhánh cứng, nhưng chỉ khi các nhà phát triển tin rằng công nghệ đã cải tiến đủ để có thể xử lý nhiều hơn với sự dễ dàng giống nhau của chữ ký cho mỗi khe thời gian.

Phần còn lại của công việc sẽ quyết định xem chúng ta muốn áp dụng phương pháp nào trong ba phương pháp trên, hoặc có thể là một phương pháp hoàn toàn khác. Đây sẽ là câu hỏi về những sự đánh đổi mà chúng tôi cảm thấy thoải mái, đặc biệt là cách chúng tôi giải quyết các vấn đề liên quan, như đặt cược thanh khoản, có thể được giải quyết tách biệt khỏi các vấn đề kỹ thuật đang trở nên dễ dàng hơn hiện nay.