Thêm tính linh hoạt vào hàng đợi thoát của Ethereum
Bài viết này thúc đẩy việc đề xuất gần đây EIP-7922.
^src: https://www.youtube.com/watch?v=bl91wk5fB4g
bởi mike neuder, mallesh pai, mikhail kalinin (mik-mal-mik) – ngày 1 tháng 4, 2025
\uparrow↑ nhưng không phải là trò đùa ngày cá tháng tư
Nội dung
1. Giới thiệu2. Xem lại hàng đợi thoát hiện tại3. Cải thiện hàng đợi thoát4. Kết nối với công việc trước đây
tl;dr; Chúng tôi mô tả một thay đổi tiềm năng đối với hàng đợi thoát của Ethereum như được đề xuất trong EIP-7922. Bài đăng ELI5 của chúng tôi đã thảo luận về cách Ethereum quản lý việc thoát của validator ngày nay và những thay đổi sắp tới trong nâng cấp Prague/Electra. Bài viết này thúc đẩy một thay đổi bổ sung cho hàng đợi để cải thiện hiệu quả của nó mà không thay đổi mô hình bảo mật của giao thức.
1. Giới thiệu
Cơ chế Bằng chứng cổ phần (PoS) trong Ethereum triển khai một hàng đợi thoát để bảo toàn tính an toàn có trách nhiệm của các giao dịch đã hoàn thiện (để biết thêm chi tiết, xem "Tại sao phải có hàng đợi thoát?"). Trong khi việc giới hạn tốc độ thoát của validator (đôi khi được gọi là churn validator) là cần thiết, nhưng việc hạn chế quá mức sẽ ảnh hưởng đến các validator trung thực phải đối mặt với nguy cơ chậm trễ dài nếu họ cần rút. Điều này cũng tốn kém cho giao thức: lý thuyết tài chính tiêu chuẩn cho chúng ta biết rằng các tài sản tương đối kém thanh khoản phải cung cấp tỷ suất sinh lời cao hơn để thu hút cùng một lượng vốn. Điều này áp dụng, mutatis mutandis, cho việc staking. Do đó, hàng đợi thoát phải được làm hiệu quả nhất có thể, tuân theo các ràng buộc bảo mật của giao thức.
Trong bài viết này, chúng tôi thúc đẩy EIP-7922, đề xuất thêm giới hạn churn động dựa trên nghiên cứu của chúng tôi về thiết kế các hàng đợi thoát. Thay đổi này cải thiện đáng kể chất lượng cuộc sống của các validator mà không làm tổn hại đến bảo mật của Ethereum.
2. Xem lại hàng đợi thoát hiện tại
Như được mô tả trong "Quá trình thoát", giai đoạn đầu tiên của việc thoát tự nguyện là hàng đợi thoát. Giới hạn "churn" xác định số lượng validator có thể thoát trong một epoch nhất định, và hiện được tính như \max(8, \lfloor \# \text{ validators} / 2^{16} \rfloor)max(8,⌊# validators/216⌋) (xem get_validator_activation_churn_limit); tính đến ngày 1 tháng 4 năm 2025, điều này tương ứng với \lfloor 1,065,882/2^{16} \rfloor=16⌊1,065,882/216⌋=16 lần thoát mỗi epoch (ví dụ, nếu có 160 validator trong hàng đợi, một validator mới được đưa vào hàng đợi sẽ được thoát sau 10 epoch, khoảng một giờ).
Hãy nhớ rằng chúng ta đang giới hạn tốc độ để đảm bảo rằng bảo mật kinh tế của một giao dịch không giảm quá nhanh. Một cách khác để hiểu mô hình bảo mật 16 lần thoát mỗi epoch là nó mã hóa các "ràng buộc" sau đây xung quanh việc thoát của validator:
- nhiều nhất là 16 validator thoát trong epoch tiếp theo, và
- nhiều nhất là 32 validator thoát trong hai epoch tiếp theo, và
- nhiều nhất là 48 validator thoát trong ba epoch tiếp theo, và
… - nhiều nhất là 16 \cdot⋅ n validator thoát trong n epoch tiếp theo,
…
Tương đương, với 1.065.882 validator, chúng ta có thể mô tả các ràng buộc này là tốc độ giảm bảo mật kinh tế của một giao dịch đã hoàn thiện. Bảo mật kinh tế của một giao dịch giảm không quá:
- 16/1.065.882 = 0,0015\% trong một kỳ,
- 32/1.065.882 = 0,0030\% trong hai kỳ,
... - 3600/1.065.882 = 0,34\% trong 225 kỳ (một ngày),
... - 50.400/1.065.882 = 4,7\% trong 3.150 kỳ (hai tuần),
... - 108.000/1.065.882 = 10,1\% trong 6.750 kỳ (30 ngày),
... - 324.000/1.065.882 = 30,4\% trong 20.250 kỳ (90 ngày),
Những ràng buộc này dễ dàng diễn giải. Ví dụ, chúng ta có thể đọc (5) là "một giao dịch đã được xác nhận sẽ không mất nhiều hơn 10% an toàn có thể truy xuất của nó trong 30 ngày tới." Hãy nhớ rằng mặc dù an ninh kinh tế của một giao dịch giảm theo thời gian, nhưng xác suất của một sự tái tổ chức/lỗi an toàn phạm vi dài cũng giảm. Do đó, các đảm bảo thanh toán của giao dịch vẫn cực kỳ cao khi thời gian trôi qua.
Nhận xét chính: Một số ràng buộc trên quan trọng hơn với giao thức, do đó việc chỉ cho phép 16 lần thoát mỗi kỳ bất kể các lần rút tiền lịch sử là quá hạn chế.
Chúng tôi minh họa điều này bằng một ví dụ. Với một triệu người xác thực, giao thức hiện tại quy định rằng 16 người xác thực có thể thoát mỗi kỳ. Trong hai tuần, điều này tương ứng với 50.400 lần thoát. Điều này chuyển trực tiếp thành "không nhiều hơn 5,04% người xác thực (tương đương stake) có thể thoát trong hai tuần." Giả sử đây là ràng buộc duy nhất mà giao thức quan tâm. Bây giờ hãy tưởng tượng trong 13 ngày qua, không có người xác thực nào thoát khỏi giao thức, và do đó, không có giới hạn churn hai tuần nào được sử dụng. Nếu một nhà điều hành stake lớn với 3% tập hợp người xác thực (30.000 người xác thực) muốn rút ngay lập tức, họ nên được phép - điều này không vi phạm giới hạn hai tuần 5,04%. Tuy nhiên, vì chỉ có 16 lần thoát có thể được xử lý mỗi kỳ về phía trước, họ buộc phải chờ 1875 kỳ (tương đương 8,33 ngày).
Nhận xét chính: Nếu chúng ta cho phép giao thức nhìn lại lịch sử thoát, chúng ta không còn cần giới hạn cứng mỗi kỳ về phía trước.
Ví dụ, trong EIP-7922 như được đề xuất hiện tại, chúng tôi đã chọn ràng buộc sau một cách rõ ràng:
Ràng buộc yếu về tính chủ quan được đề xuất: Không nhiều hơn 50.400 lần thoát người xác thực trong bất kỳ khoảng hai tuần nào.
Sau đó, chúng ta chỉ cần đảm bảo rằng ràng buộc được tôn trọng trong mọi khoảng hai tuần lăn, mà không đặt giới hạn cứng về số lần thoát trong mỗi kỳ. Một giới hạn churn được điều chỉnh động dựa trên dữ liệu thoát người xác thực lịch sử cho phép Ethereum linh hoạt đáp ứng các đợt tăng đột biến về nhu cầu thoát trong khi vẫn giữ nguyên an ninh trong mọi khoảng hai tuần.
(Phần còn lại của bản dịch tương tự, tuân theo các nguyên tắc dịch như trên)4. Kết nối với các công trình trước đây
Đề xuất cải tiến Ethereum (EIP) này trực tiếp mở rộng bài báo trước đây của chúng tôi với Max Resnick về các hàng đợi thoát tối ưu. Trong công trình đó, chúng tôi đã giới thiệu MINSLACK, một hệ thống hàng đợi động. Giống như Đề xuất cải tiến Ethereum (EIP) này, thay vì xử lý một số lượng xác định các validator mỗi kỷ nguyên, MINSLACK tính toán số lượng validator có thể thoát an toàn dựa trên dữ liệu lịch sử và một tập hợp các ràng buộc bảo mật nhất định. Cụ thể, nó kiểm tra "slack" - năng lực rút tiền chưa sử dụng từ các kỷ nguyên gần đây - để xác định các lần thoát được phép. MINSLACK tận dụng slack này bằng cách nhận ra rằng nếu ít validator thoát hơn trong các kỷ nguyên trước so với mức tối đa cho phép, giao thức có thể an toàn xử lý nhiều lần thoát hơn trong kỷ nguyên hiện tại trong khi vẫn duy trì cùng một đảm bảo an toàn có trách nhiệm trên toàn bộ khoảng thời gian.
Đề xuất cải tiến Ethereum (EIP) này là phiên bản đơn giản hóa của MINSLACK chỉ triển khai ràng buộc duy nhất được mô tả trong mục 3. Cải thiện hàng đợi thoát. Phân tích của chúng tôi đã chứng minh rằng MINSLACK là tối ưu khi tất cả các validator có mức độ khẩn cấp thoát tương tự nhau (các giá trị đồng nhất). Nói một cách đơn giản, MINSLACK đạt được tốc độ thoát nhanh nhất có thể, với điều kiện bảo mật của Ethereum. Dựa trên khuôn khổ lý thuyết này, chúng tôi tin rằng thuật toán MINSLACK với một ràng buộc duy nhất mã hóa khoảng thời gian yếu chủ quan sẽ cải thiện tình trạng hiện tại. Nếu cộng đồng cảm thấy cần thêm các ràng buộc trên các khung thời gian khác nhau, Đề xuất cải tiến Ethereum (EIP) này có thể dễ dàng mở rộng để triển khai thuật toán MINSLACK hoàn chỉnh. Hơn nữa, bài báo của chúng tôi cũng nghiên cứu khả năng các lần thoát đấu giá để được ưu tiên. Chúng tôi chỉ ra rằng một phiên bản sửa đổi của MINSLACK sắp xếp hàng đợi dựa trên kích thước đấu giá (triển khai hàng đợi ưu tiên) là gần như tối ưu trong bối cảnh các giá trị không đồng nhất. Điều này có thể phục vụ như một cải tiến bổ sung cho quá trình hàng đợi thoát, và chúng tôi rất mong muốn thảo luận nếu cộng đồng quan tâm.
–
được thực hiện với 
và markdown bởi mik-mal-mik
