Đề xuất đơn giản hóa PoS của Vitalik: Duy trì việc sử dụng 8192 chữ ký cho mỗi khe sau SSF
Tuyển chọn TechFlowTuyển chọn TechFlow
Đề xuất đơn giản hóa PoS của Vitalik: Duy trì việc sử dụng 8192 chữ ký cho mỗi khe sau SSF
Điều này sẽ làm cho công việc của những người triển khai công nghệ trở nên dễ dàng hơn, cũng như các nhà phát triển cơ sở hạ tầng phụ trợ như khách hàng nhẹ.
Chuyên sâu báo cáo Web3Tác giả: Vitalik Buterin, ethresearch
Biên dịch: Tùng Tuyết, Jinse Finance
Sự khác biệt chính giữa Ethereum và hầu hết các hệ thống proof-of-stake (PoS) khác (có tính xác định cuối cùng) nằm ở chỗ Ethereum cố gắng hỗ trợ một lượng rất lớn các validator: hiện tại chúng ta có 895.000 đối tượng validator, phân tích đơn giản theo luật Zipf cho thấy điều này tương ứng với hàng chục ngàn validator là những cá nhân/ thực thể riêng biệt. Mục đích của cách tiếp cận này là để thúc đẩy tính phi tập trung, thậm chí cho phép cá nhân bình thường tham gia staking, mà không yêu cầu mọi người phải từ bỏ quyền đại diện và giao quyền kiểm soát cho một trong số ít các nhóm staking.
Tuy nhiên, phương pháp này đòi hỏi chuỗi Ethereum xử lý một lượng lớn chữ ký mỗi slot (hiện nay khoảng 28.000; sau SSF là 1.790.000), đây là một tải trọng rất cao. Để hỗ trợ tải trọng này, cần phải chấp nhận nhiều hy sinh về mặt kỹ thuật:
-
Cần một cơ chế truyền bá bằng chứng phức tạp, liên quan đến việc chia nhỏ bằng chứng qua nhiều mạng con, yêu cầu tối ưu hóa cực độ các phép toán chữ ký BLS để xác minh các chữ ký này, v.v.
-
Chúng ta không có một giải pháp kháng lượng tử rõ ràng, thay thế được và đủ hiệu quả.
-
Việc sửa lỗi lựa chọn phân nhánh kiểu hợp nhất view trở nên phức tạp hơn vì không thể trích xuất từng chữ ký riêng lẻ.
-
Việc xử lý SNARK đối với các chữ ký là khó khăn do số lượng lớn của chúng. Helios cần hoạt động trên một chữ ký bổ sung chuyên dụng, gọi là chữ ký hội đồng đồng bộ.
-
Nó làm tăng thời gian slot an toàn tối thiểu bằng cách yêu cầu ba sub-slot trong một slot thay vì hai.
Hệ thống gom nhóm chữ ký thoạt nhìn có vẻ hợp lý, nhưng thực tế lại tạo ra sự phức tạp hệ thống lan rộng tới mọi khía cạnh.
Hơn nữa, nó thậm chí còn chưa đạt được mục tiêu của chính mình. Yêu cầu tối thiểu để stake vẫn là 32 ETH, điều này quá xa vời với nhiều người. Và chỉ cần phân tích logic đơn thuần, về lâu dài, hệ thống yêu cầu mọi người đều ký dường như không khả thi trong việc thực sự cung cấp khả năng stake cho người bình thường: nếu Ethereum có 500 triệu người dùng, trong đó 10% stake, thì điều đó nghĩa là mỗi slot sẽ có 100 triệu chữ ký. Về mặt lý thuyết thông tin, việc xử lý cắt giảm trong thiết kế này sẽ cần ít nhất 12,5 MB không gian dữ liệu sẵn có mỗi slot, xấp xỉ bằng mục tiêu của daksharding hoàn chỉnh (!!!). Có thể thực hiện được, nhưng yêu cầu bản thân việc stake phụ thuộc vào lấy mẫu sẵn có dữ liệu sẽ mang lại mức tăng đáng kể về độ phức tạp —— ngay cả khi đây mới chỉ là khoảng 0,6% dân số thế giới đang stake, và chưa bắt đầu đề cập đến các vấn đề tính toán khi xác minh hàng chục triệu chữ ký.
Do đó, thay vì trông chờ các nhà mật mã học tạo ra "viên đạn ma thuật" (hoặc "áo giáp ma thuật") để làm cho việc tăng liên tục số lượng chữ ký mỗi slot trở nên khả thi, tôi đề xuất chúng ta thực hiện một bước chuyển đổi triết lý: từ bỏ ngay từ đầu 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 thực hiện nhiều đơn giản hóa kỹ thuật, bằng cách cho phép Helios trực tiếp thực hiện SNARK trên giao thức đồng thuận Ethereum, làm cho nó an toàn hơn, và giải quyết vấn đề kháng lượng tử bằng cách khiến ngay cả các lược đồ chữ ký nhàm chán và đã tồn tại từ lâu như Winternitz cũng trở nên khả thi.
Tại sao không «chỉ dùng ủy ban»?
Nhiều blockchain ngoài Ethereum đang đối mặt với đúng vấn đề này sử dụng một phương pháp an toàn dựa trên ủy ban. Trong mỗi slot, họ chọn ngẫu nhiên N validator (ví dụ, N ≈ 1000), những người này chịu trách nhiệm hoàn thành slot đó. Cần nhắc lại lý do tại sao phương pháp này là chưa đủ: nó thiếu trách nhiệm giải trình.
Để hiểu lý do, 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 tính xác định cuối cùng hoặc tấn công kiểm duyệt. Để phát động cuộc tấn công, vẫn cần kiểm soát phần lớn tài sản kinh tế tham gia staking đồng ý tiến hành tấn công, tức là chạy phần mềm tham gia tấn công, cùng tất cả các validator cuối cùng được chọn vào ủy ban tham gia tấn công. Toán học chọn 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 cuộc tấn công như vậy là rất nhỏ, bởi vì phần lớn các validator đồng ý tấn công cuối cùng không bị phát hiện, vì họ không được chọn vào ủy ban.
Hiện tại, Ethereum đi theo hướng cực đoan ngược lại. Nếu xảy ra một cuộc tấn công 51%, phần lớn toàn bộ tập hợp validator tấn công sẽ bị cắt giảm stake. Chi phí tấn công hiện tại vào khoảng 9 triệu ETH (khoảng 20 tỷ USD), và điều này giả định rằng sự đồng bộ mạng bị gián đoạn theo cách có lợi nhất cho kẻ tấn công.
Tôi cho rằng đây là một chi phí cao, và là một mức giá quá cao; chúng ta có thể chấp nhận một số hy sinh ở vấn đề này. Ngay cả khi chi phí tấn công là 1-2 triệu ETH cũng hoàn toàn đủ. Hơn nữa, rủi ro tập trung chính mà Ethereum hiện nay đối mặt nằm ở một nơi hoàn toàn khác: nếu mức stake tối thiểu giảm xuống gần bằng không, sự chênh lệch sức mạnh giữa các nhóm stake quy mô lớn sẽ không quá lớn.
Đây là lý do tại sao tôi ủng hộ một giải pháp ôn hòa: hy sinh một chút về trách nhiệm giải trình của validator, nhưng vẫn giữ tổng lượng ETH có thể bị cắt giảm khá cao; đổi lại, nó mang lại cho chúng ta phần lớn lợi ích từ việc có một tập hợp validator nhỏ hơn.
Trong điều kiện SSF, 8192 chữ ký mỗi slot sẽ như thế nào?
Giả sử áp dụng giao thức đồng thuận hai vòng truyền thống (tương tự giao thức Tendermint sử dụng, và là giao thức SSF chắc chắn sẽ phải sử dụng), mỗi validator tham gia cần hai chữ ký mỗi slot. Chúng ta cần tìm cách vượt qua thực tế này. Tôi thấy ba phương pháp chính mà chúng ta có thể làm điều này.
Phương pháp một: Đặt cược hoàn toàn vào các nhóm stake phi tập trung
Python có một câu nói rất quan trọng:
Phải có một —— tốt nhất chỉ một —— cách rõ ràng để làm điều đó.
Với vấn đề bình đẳng stake, hiện tại Ethereum đang vi phạm nguyên tắc này, vì chúng ta đang đồng thời thực hiện hai chiến lược khác nhau để đạt được mục tiêu này: (i) stake riêng lẻ quy mô nhỏ, và (ii) các nhóm stake phi tập trung sử dụng công nghệ validator phân tán (DVT). Do những lý do nêu trên, (i) chỉ có thể hỗ trợ một phần các cá nhân stake; luôn sẽ có nhiều người cảm thấy khoản tiền gửi tối thiểu quá lớn. Tuy nhiên, Ethereum đang trả giá rất cao về mặt kỹ thuật để hỗ trợ (i).
Một giải pháp khả thi là từ bỏ (i) và đặt cược hoàn toàn vào (ii). Chúng ta có thể nâng mức stake tối thiểu lên 4096 ETH, và đặt giới hạn tổng cộng 4096 validator (khoảng 16,7 triệu ETH). Dự kiến các stakeholder quy mô nhỏ sẽ tham gia các nhóm DVT: hoặc bằng cách cung cấp vốn, hoặc trở thành nhà vận hành nút. Để ngăn chặn kẻ tấn công lợi dụng, vai trò nhà vận hành nút cần bị giới hạn theo một cách nào đó bởi danh tiếng, và các nhóm sẽ cạnh tranh với nhau bằng cách cung cấp các lựa chọn khác nhau về khía cạnh này. Việc cung cấp vốn sẽ không cần cấp phép.
Chúng ta có thể làm cho việc stake tập thể trong mô hình này trở nên «khoan dung» hơn bằng cách giới hạn hình phạt, ví dụ. chỉ bằng 1/8 tổng số stake đã cung cấp. Điều này sẽ giảm nhu cầu tin tưởng vào nhà vận hành nút, mặc dù cần xử lý cẩn trọng do những vấn đề được nêu ra ở đây.
Phương pháp hai: Stake hai lớp
Chúng ta tạo ra hai lớp stakeholder: một lớp «nặng», yêu cầu 4096 ETH, tham gia vào việc xác định cuối cùng, và một lớp «nhẹ», không có yêu cầu stake tối thiểu (đồng thời không có độ trễ gửi và rút, cũng không có rủi ro bị cắt giảm), đóng góp thêm một lớp bảo mật. Để một khối được xác định cuối cùng, cả lớp nặng phải xác định nó và lớp nhẹ phải có >= 50% các validator nhẹ đang hoạt động bỏ phiếu xác nhận nó.
Sự dị biệ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ì để tấn công thành công cần phải làm tê liệt cả hai lớp. Nếu một lớp bị tê liệt trong khi lớp kia không, chuỗi sẽ dừng lại; nếu lớp nặng bị tê liệt, có thể trừng phạt nó.
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 đồng thời được sử dụng làm tài sản thế chấp bên trong ứng dụng. Nhược điểm chính là, bằng cách xác lập sự phân chia giữa người stake quy mô nhỏ và quy mô lớn, nó làm cho việc stake kém bình đẳng hơn.
Phương pháp ba: Thay phiên tham gia (tức là ủy ban nhưng có trách nhiệm)
Chúng ta áp dụng cách tiếp cận tương tự như thiết kế siêu ủy ban được đề xuất ở đây: đối với mỗi slot, chúng ta chọn 4096 validator đang hoạt động, và chúng ta điều chỉnh cẩn thận tập hợp này trong suốt mỗi slot để đảm bảo an toàn.
Tuy nhiên, chúng ta đưa ra một số lựa chọn tham số khác biệt để đạt được «lợi ích tối đa» trong khung này. Đặc biệt, chúng ta cho phép validator tham gia với số dư tùy ý cao; nếu một validator sở hữu hơn một lượng M ETH nhất định (phải là giá trị biến động), thì họ sẽ tham gia ủy ban trong mỗi khoảng thời gian. Nếu một validator có N
Chúng ta có một đòn bẩy thú vị ở đây: tách rời «trọng số» vì mục đích khuyến khích khỏi «trọng số» vì mục đích đồng thuận: phần thưởng cho mỗi validator trong ủy ban nên giống nhau (ít nhất là đối với các validator ≤M ETH), để duy trì phần thưởng trung bình tỷ lệ thuận. Chúng ta vẫn có thể đếm các validator trong ủy ban theo cơ chế đồng thuận dựa trên trọng số ETH. Điều này đảm bảo rằng để phá vỡ tính xác định cuối cùng cần một lượng ETH lớn hơn 1/3 tổng lượng ETH trong ủy ban.
Phân tích theo luật Zipf sẽ tính toán lượng ETH như sau:
Ở mỗi cấp bậc bình phương của tổng số dư, số lượng validator tỷ lệ nghịch với cấp bậc số dư đó, và tổng số dư của các validator này sẽ bằng nhau.
Do đó, ủy ban sẽ có lượng ETH tham gia bằng nhau từ mỗi cấp bậc số dư, ngoại trừ cấp bậc trên ngưỡng M (validator luôn có mặt trong ủy ban).
Do đó, chúng ta có Log2(M) cấp bậc trong mỗi K validator ở các cấp bậc trên, và K+K/2+……=2K validator ở các cấp bậc trên. Vì vậy, K = 4096 / (Log2(M) + 2).
Validator lớn nhất sẽ có M*k ETH. Chúng ta có thể suy ngược lại: nếu validator lớn nhất có 2^18 = 262144 ETH, điều này nghĩa là (xấp xỉ) M = 1024 và k = 256.
Tổng lượng ETH stake là:
Toàn bộ cổ phần của 512 validator hàng đầu (2^18*1 + 2^17*2 + …… + 2^10*2^8 = 2359296)
Cộng với các stake nhỏ hơn được chọn mẫu ngẫu nhiên (2^8*(2^9 + 2^8 + 2^7……) ≈ 2^8*2^10 = 2^18)
Chúng ta có tổng cộng 2.621.440 ETH, hoặc chi phí tấn công khoảng 900.000 ETH.
Nhược điểm chính của phương pháp này nằm ở việc đưa vào giao thức một chút phức tạp hơn, nhằm chọn ngẫu nhiên các validator theo cách cho phép chúng ta vẫn đạt được an toàn đồng thuận khi ủy ban thay đổi.
Lợi thế chính của nó là duy trì được hình thức stake độc lập có thể nhận diện, duy trì một hệ thống duy nhất, và thậm chí cho phép giảm mức stake tối thiểu xuống mức rất thấp (ví dụ 1 ETH).
Tóm tắt
Nếu chúng ta xác định rằng sau giao thức SSF, chúng ta muốn duy trì 8192 chữ ký mỗi slot, điều này sẽ giúp công việc của các nhà triển khai kỹ thuật dễ dàng hơn, cũng như việc xây dựng các cơ sở hạ tầng phụ trợ như client nhẹ. Việc vận hành một client đồng thuận sẽ dễ dàng hơn với bất kỳ ai, và người dùng, người yêu thích stake và những người khác có thể ngay lập tức làm việc dựa trên giả định này. Tải trọng tương lai của giao thức Ethereum sẽ không còn là điều chưa biết: nó có thể được tăng lên thông qua hard fork trong tương lai, nhưng chỉ khi các nhà phát triển tin chắc rằng công nghệ đã đủ cải tiến để xử lý nhiều chữ ký hơn mỗi slot với mức độ dễ dàng tương tự.
Công việc còn lại là quyết định chúng ta muốn áp dụng một trong ba phương pháp nêu trên, hoặc có thể là một phương pháp hoàn toàn khác. Đây sẽ là một vấn đề về việc chúng ta thoải mái với những cân nhắc nào, đặc biệt là cách chúng ta giải quyết các vấn đề liên quan, ví dụ như stake linh động, điều này giờ đây có thể được giải quyết riêng biệt với các vấn đề kỹ thuật vốn đã trở nên dễ dàng hơn.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@VitalikButerin
