Điều này sẽ giúp cuộc sống của những người triển khai công nghệ 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 hạng nhẹ trở nên dễ dàng hơn.
Người viết: Vitalik Buterin, ethresearch
Biên soạn: 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ợ một số lượng rất lớn đối tượng xác thực: chúng tôi hiện có 895.000 đối tượng xác thực và phân tích luật đơn giản của Zipf cho thấy điều này tương ứng với Hàng chục đối tượng hàng nghìn đối tượng xác thực là các 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. Hỗ trợ tải 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ế truyền bá bằng chứng phức tạp liên quan đến việc phân chia bằng chứng trên nhiều mạng con, yêu cầu siêu tối ưu hóa các hoạt động chữ ký BLS để xác minh các chữ ký này, v.v.
- Chúng tôi không có giải pháp thay thế rõ ràng đủ hiệu quả để 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ẻ.
- Chữ ký SNARK khó khăn 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ộ hóa.
- 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 phụ 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 trên 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 phục vụ mục đích của nó. 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 một viên đạn ma thuật (hoặc áo giáp ma thuật) giúp có thể có số lượng chữ ký ngày càng tăng trong mỗi khoảng thời gian, tôi khuyên chúng ta nên thực hiện một sự thay đổi triết học: từ bỏ những kỳ vọng như vậy trong địa điểm đầu tiên . Đ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ỉ sử dụng ủy ban”?
Nhiều blockchain không phải Ethereum phải đối mặt vớ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 tưởng tượng một cuộc tấn công 51%. Đâ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 có thái cực 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ộ xác thực tấn công sẽ bị cắt cổ phần. 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 nghĩ đó là một chi phí cao, và đó là một chi phí quá cao, và chúng ta có thể hy sinh một số vấn đề 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 đủ. Hơn nữa, rủi ro tập trung chính hiện đang tồn tại đối với 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, thì sự khác biệt về sức mạnh của các nhóm đặt cược quy mô lớn sẽ không nhiều.
Đó là lý do tại sao tôi ủng hộ một giải pháp khiêm tốn: hy sinh một số trách nhiệm của người xác thực, nhưng vẫn giữ tổng số ETH có thể cắt giảm ở mức khá cao và đổi lại, nó mang lại cho chúng tôi một bộ xác thực nhỏ hơn để nhận được hầu hết các lợi ích.
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ư giao thức được Tendermint sử dụng và chắc chắn được SSF 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 vào nhóm cầm cố phi tập trung
Python có một câu nói rất quan trọng:
Nên có một - tốt nhất là chỉ một - cách hiển nhiên để thực hiện việc này.
Liên quan đến vấn đề cân bằng đặt cược, Ethereum hiện vi phạm quy tắc này vì chúng tôi thực hiện đồng thời hai chiến lược khác nhau để đạt được mục tiêu này: (i) đặt cược riêng lẻ quy mô nhỏ và (ii) sử dụng nhóm đặt cược phi tập trung 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à từ bỏ (i) và tập trung toàn lực vào (ii). Chúng tôi có thể tăng số tiền đặt cược tối thiểu lên 4096 ETH và đặt tổng giới hạn là 4096 trình xác nhận (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 hạn, 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. đế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.
Cách 2: Cam kết hai cấp độ
Chúng tôi tạo ra hai cấp độ người đặt cược: cấp độ “nặng”, yêu cầu 4096 ETH, để tham gia quyết toán và cấp độ “nhẹ”, không có yêu cầu đặt cược tối thiểu (cũng không có độ trễ gửi và rút tiền và không có rủi ro bị cắt giảm), 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, vì cả lớp nặng và lớp nhẹ đều cần phải bị hỏng để cuộc tấn công thành cô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.
Cách 3: Thay phiên nhau tham gia (tức là ủy ban nhưng chịu trách nhiệm)
Cách tiếp cận mà chúng tôi thực hiện tương tự như thiết kế siêu ủy ban được đề xuất ở đây: đối với mỗi khoảng thời gian, chúng tôi chọn 4096 trình xác thực hiện đang hoạt động và chúng tôi cẩn thận điều chỉnh bộ này trong mỗi khoảng thời gian để đảm bảo rằng 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 để có được “lợi ích 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 minh có N <M ETH，那么他们有 N/M 在任何给定时间段内进入委员会的概率。
Một đòn bẩy thú vị mà chúng tôi có ở đây là tách “trọng lượng” cho mục đích khuyến khích khỏi “trọng số” cho mục đích đồng thuận: phần thưởng cho mọi người xác nhận trong ủy ban phải giống nhau (ít nhất là đối với những người xác nhận có ≤M ETH), để giữ phần thưởng trung bình tỷ lệ thuận. Chúng tôi vẫn có thể thực hiện tính toán đồng thuận của những người xác nhận trong ủy ban bằng cách sử dụng ETH làm trọng số. Đ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 theo luật của Zipf sẽ tính toán số lượng ETH như sau:
Ở 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 nhận này sẽ bằ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) cho mọi trình xác thực K ở cấp trên và K+K/2+…=2K trình xác thực ở cấp trên. Do đó, K=4096/Log2(M)+2.
Trình xác nhận 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 được cam kết là:
Tất cả quyền và lợi ích của 512 người xác nhận hàng đầu (2^18*1+2^17*2+……+2^10*2^8=2359296)
Cộng với các cược nhỏ hơn từ 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 2621440 ETH hoặc chi phí cho cuộc tấn công là khoảng 900 nghìn ETH.
Nhược điểm chính của phương pháp này là nó gây ra một số phức tạp hơn trong giao thức để chọn ngẫu nhiên người xác thực 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.
Ưu điểm chính của nó 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 đằng sau giao thức SSF, chúng tôi muốn gắn bó với 8192 chữ ký, điều này 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ư máy khách hạng 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 trọng 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 chữ ký hơn trên mỗi khe thời gian một cách dễ dàng.
Phần còn lại sẽ là 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ó lẽ là một phương pháp tiếp cận 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 với các vấn đề kỹ thuật đang trở nên dễ dàng hơn hiện nay.
