Quy tắc xác nhận nhanh về Safe Head trong Prysm (Phần 1)
Tài liệu này nêu bật việc triển khai thuật toán xác nhận nhanh của chúng tôi trong Prysm, như phần 1 của một cuộc khám phá rộng hơn. Chúng tôi gọi là phần 1 vì công việc vẫn đang trong giai đoạn đầu—có một Sách trắng và một bằng chứng an toàn, nhưng không có bằng chứng nào được thẩm định đầy đủ và theo như chúng tôi biết, chưa có khách hàng nào khác triển khai nó. Giống như tất cả các triển khai, lỗi và sai sót đều tồn tại. Trong bài đăng này, chúng tôi trình bày về triển khai của mình trong Prysm và chia sẻ một số quan sát thú vị khi chạy nó trên mạng chính.
Tài liệu tham khảo:
- Quy tắc xác nhận cho Ethereum PoS của Aditya Asgaonkar, với sự đóng góp của Francesco D'Amato, Roberto Saltini, Luca Zanolini và Chenyi Zhang
- Quy tắc xác nhận nhanh cho giao thức Consensus Ethereum của Aditya Asgaonkar, Francesco D'Amato, Roberto Saltini, Luca Zanolini và Chenyi Zhang
- Mã triển khai xác nhận nhanh Prysm của Aditya Asgaonkar và Terence
- Giải thích về triển khai Prysm Forkchoice của Terence
Lý lịch
Đầu an toàn là gì?
Trên Ethereum, đầu an toàn đề cập đến Block gần đây nhất được coi là an toàn trước các đợt tổ chức lại ngắn hạn, nghĩa là không có khả năng khối đó bị thay thế bởi một Block khác do Fork. Một Block cuối cùng sẽ trở nên an toàn khi nó được root trong một điểm kiểm tra hợp lý và nhận được đủ xác thực của người xác thực. Theo truyền thống, khách hàng coi điểm kiểm tra hợp lý mới nhất (cũng là điểm khởi đầu cho thuật toán lựa chọn Fork LMD GHOST) là một Block an toàn hoặc điểm kiểm tra hợp lý chưa thực hiện mới nhất (mà không cần quan tâm đến việc thực hiện on-chain có xảy ra hay không) là một Block an toàn. Block an toàn cho phép người dùng chuỗi thực hiện tiến trình tiếp theo một cách an toàn mà không cần phải chờ đợi Tính chất cuối cùng mất nhiều thời gian hơn để đạt được.
Làm sao để có được cái đầu an toàn?
Các máy khách Lớp thực thi (như Geth, Nethermind, ETC) sẽ hiển thị các điểm cuối RPC chuyên dụng để truy vấn các khối thực thi đầu , đầu an toàn và đã hoàn tất . Người tiêu dùng dữ liệu trực tiếp của blockchain có thể quyết định cách hành động dựa trên thông tin này:
- Đầu cuối đã hoàn thiện :
eth_getBlockByHash("finalized", ...) - Đầu an toàn :
eth_getBlockByHash("safe", ...) - Tiêu đề :
eth_getBlockByHash("latest", ...)
Đầu an toàn được truyền đến EL như thế nào?
Đầu an toàn được truyền từ Lớp Consensus đến Lớp thực thi thông qua API Engine , cụ thể là thông qua các phương thức engine_forkchoiceUpdated trong quá trình cập nhật đầu. Các máy khách CL khác nhau có thể có các diễn giải khác nhau về những gì đủ điều kiện là an toàn, hãy sử dụng 1.) điểm kiểm tra hợp lý mới nhất, những máy khách khác (như Prysm theo mặc định) sử dụng 2.) điểm kiểm tra hợp lý chưa thực hiện mới nhất. Trong bài đăng này, chúng tôi khám phá một giải pháp thay thế: sử dụng 3.) Block được xác nhận nhanh làm Block an toàn.
{ "jsonrpc" : "2.0" , "method" : "engine_forkchoiceUpdatedV2" , "params" : [ { "headBlockHash" : "0x..." , "safeBlockHash" : "0x..." , ← this is the safe head "finalizedBlockHash" : "0x..." } , { "timestamp" : "0x..." , "random" : "0x..." , "suggestedFeeRecipient" : "0x..." } ] , "id" : 1 }Block xác nhận nhanh là gì?
Block được xác nhận nhanh là khối mà, giả sử một mạng đồng bộ (xác thực mất <8 giây để đến) và quyền lực đối nghịch hạn chế, rất có khả năng vẫn nằm trên chuỗi chuẩn —thậm chí trước khi nó được hoàn tất. Quy tắc xác nhận nhanh cung cấp một phương pháp tìm kiếm cho người dùng và ứng dụng để coi một Block là đã được xác nhận trong vòng vài giây đến dưới một phút sau khi đề xuất. Nó thực hiện điều này bằng cách kiểm tra xem Block đã nhận được đủ số phiếu xác thực có thể quan sát được và đáp ứng các ngưỡng an toàn cụ thể hay chưa. Không giống như Tính chất cuối cùng, đảm bảo tính không thể đảo ngược thông qua các điều kiện Slashing , xác nhận nhanh cung cấp sự đảm bảo nhanh hơn nhưng yếu hơn dựa trên các điều kiện mạng và hành vi của trình xác thực.
Triển khai Prysm
Phần này phác thảo triển khai đầu an toàn của Prysm từ PR thử nghiệm. Vì nó vẫn đang trong quá trình phát triển tích cực và có thể thay đổi, bạn có thể bỏ qua phần quan sát thử nghiệm. Để kích hoạt xác nhận nhanh như Block an toàn, hai cờ phải được đặt:
- Để chọn chế độ Block an toàn:
-safe-block=fast-confirmation(mặc định:unrealized-justified) - Để chỉ định Threshold byzantine:
-fast-confirmation-byzantine-threshold=33(mặc định:33)- Ở đây, byzantine ám chỉ các hành động độc hại như giữ lại chứng thực, bỏ phiếu cho các cây con xung đột, ETC
Thời gian xác nhận nhanh
Vào giây thứ 0 của khe n , trong trường hợp may mắn, nút đèn hiệu Prysm gọi UpdateHead Up d a t e H e a d theo khoảng thời gian đều đặn của nó. Bắt đầu từ giây thứ 4 của n-1 , nó bắt đầu thu thập, xác minh và đếm các chứng thực cho khe Block kịp thời n-1 . Nếu mọi việc diễn ra như mong đợi, Block tại n-1 có thể được xác nhận nhanh chóng trong vòng chưa đầy 8 giây (giả sử Threshold byzantine dưới 30%, chúng tôi sẽ giải thích lý do tại sao phép toán này sau.
Đã sửa đổi forkchoice và các đối tượng node
Đối tượng Forkchoice F o k ch o i c e hiện lưu trữ một trường mới: gốc đầu an toàn.
Node N o d e thêm phương pháp mới để tính toán mức hỗ trợ tối đa có thể nhận được từ khe bắt đầu đến khe hiện tại. Điều này dựa trên trọng số ủy ban và giải phẫu khe/kỷ nguyên:
- Nếu phạm vi nằm trong một kỷ nguyên duy nhất, nó sẽ trả về tổng hỗ trợ như sau: CommitteeWeight × SlotCount C o m mi t t e e W e i gh t × S l o t C o u n t .
- Nếu phạm vi kéo dài toàn bộ các kỷ nguyên, nó sẽ trả về trọng số của một kỷ nguyên: CommitteeWeight * 32 C o m mi t t e e W e i g h t ∗ 32 .
- Nếu nó chuyển sang một kỷ nguyên mới mà không mở rộng hoàn toàn, nó sẽ tính toán hỗ trợ theo tỷ lệ dựa trên số lượng khe trong mỗi phân đoạn kỷ nguyên.
Khi cập nhật hậu duệ tốt nhất, hàm sẽ nhận được cả số giây vào khe hiện tại và trọng số ủy ban của chuỗi hiện tại
- Nếu phần tử con tốt nhất của khe trước đó được xác nhận nhanh, nó sẽ đệ quy đặt BestConfirmedDescendant B e s t Con f i r m e d Desc e sc e n d a n t thành phần tử con được xác nhận sâu nhất.
- Nếu không được xác nhận, nó sẽ gán trực tiếp phần tử con tốt nhất hoặc đặt BestConfirmedDescendant B e s t Con o n Firm i r m e d Desc e sc e n d a n t thành nil n i l .
Điều này đảm bảo trạng thái xác nhận được truyền ngược nhanh chóng qua chuỗi.
Cuối cùng, để xác định xem một nút có được xác nhận hay không, nó sẽ so sánh trọng số của nút đó mà không áp dụng mức tăng cường của người đề xuất với Threshold an toàn. Logic sẽ kiểm tra:
- Khe của nút phải sớm hơn khe hiện tại.
- Nó tính toán mức hỗ trợ tối đa có thể và trọng số tăng cường của người đề xuất.
- Điều kiện xác nhận là:
voteOnlyWeight > ( maxPossibleSupport + proposalBoostWeight ) / 2 + maxPossibleSupport / 3 Chỉ bỏ phiếu W e i g h t > ( tối đa khả năng ủng hộ + đề xuất Tăng W e i g h t ) / 2 + tối đa khả năng ủng hộ / 3
Ở đâu:
proposalBoostWeight = ( committeeWeight * ProposerScoreBoost ) / 100 Trọng lượng đề xuất tăng = ( trọng lượng đề xuất tăng ∗ Điểm đề xuất tăng ) / 100
Quan sát số 1
(Tất cả dữ liệu bên dưới được thu thập trong khoảng thời gian từ ngày 13 tháng 4 năm 2025 đến ngày 14 tháng 4 năm 2025)
Trường hợp may mắn: Đối với một Block lệ được đề xuất đúng thời hạn tại khe n , khi bắt đầu khe n+1 , Block này thường nhận được khoảng 97% sự hỗ trợ của trình xác thực chỉ bằng cách đăng ký vào mạng con xác thực tổng hợp.
Trong biểu đồ này, giả sử bắt đầu từ khe n , node0 là Block tại khe n-1 , node1 là Block tại khe n-2:
Trường hợp Block trễ: Nếu Block ở khe n được giải phóng trễ, nó sẽ không thu thập đủ hỗ trợ vào lúc bắt đầu n+1 . Trong trường hợp này, xác nhận nhanh thường mất hơn 3 khe , giả sử Block tiếp theo sắp xếp lại Block trễ.
Quan sát #2
Như dự kiến, việc tổ chức lại khe Beacon xảy ra thường xuyên hơn so với việc tổ chức lại Block an toàn, với 8 lần tổ chức lại Beacon và 0 lần tổ chức lại Block an toàn được quan sát thấy trong 12 giờ qua.
Quan sát số 3
Như mong đợi, các khối xác nhận nhanh (an toàn) xảy ra thường xuyên hơn các khối hợp lý hóa (an toàn) chưa thực hiện, và các khối này lại xảy ra thường xuyên hơn các khối đã hoàn tất. Điều này phản ánh sự đánh đổi giữa tốc độ xác nhận và sức mạnh của các đảm bảo an toàn—xác nhận nhanh cung cấp sự đảm bảo nhanh hơn với cái giá phải trả là các đảm bảo yếu hơn, trong khi Tính chất cuối cùng cung cấp các đảm bảo mạnh nhất nhưng có độ trễ dài hơn.
Đây là chế độ xem theo giờ, trong đó màu xanh lá cây biểu thị kỷ nguyên được hợp lý hóa, màu vàng biểu thị kỷ nguyên được hợp lý hóa chưa thực hiện, màu xanh lam biểu thị kỷ nguyên được xác nhận nhanh và màu cam biểu thị kỷ nguyên mới nhất. Như đã hiển thị, kỷ nguyên được xác nhận nhanh theo sát kỷ nguyên mới nhất, không giống như kỷ nguyên được hợp lý hóa và chưa thực hiện có xu hướng tụt hậu:
Đây là chế độ xem 30 phút:
Quan sát #4
Sự khác biệt giữa khe cắm đầu mới nhất và khe cắm an toàn thường trung bình là 2 khe cắm trong chế độ xem hàng giờ và dao động từ 2 đến 4 khe cắm trong khung thời gian 5 phút:
Quan sát số 5
Khi sử dụng Threshold Byzantine là 33%, không thể xác nhận một Block trong một khe duy nhất . Điều này là do điều kiện xác nhận chặt chẽ hơn:
vote > (max_support + pb_score) / 2 + max_support * 0.33Theo trực giác, điều này có nghĩa là Block này sẽ cần:
- 50% ( Threshold LMD GHOST)
- 20% (một nửa số tiền tăng của người đề xuất)
- 33% ( Threshold Byzantine)
Tổng cộng là 103% , vượt quá số phiếu bầu tối đa có thể là 100%.
Để khái quát Threshold trên nhiều khe, chúng tôi mô hình hóa nó như sau:
threshold = ((n * 0.5 ) + 0.2 + (n * 0.33 )) / n Trong đó n là số khe kể từ khi Block được đề xuất. Công thức này nắm bắt:
-
n * 0.5: Yêu cầu bỏ phiếu của LMD -
n * 0.33: vùng đệm an toàn cho hành vi byzantine -
0.2: đóng góp cố định của người đề xuất tăng cường
Khi n tăng, ảnh hưởng của người đề xuất tăng cường giảm dần và Threshold hội tụ về 0,83. Điều này có nghĩa là để xác nhận nhanh một Block trong hai khe , khối đó phải nhận được ít nhất 93% tổng trọng số của ủy ban .
| Các vị trí kể từ khi đề xuất (n) | Phiếu bầu của LMD (n * 0,5) | Tăng cường người đề xuất (/2) | Threshold Byzantine (n * 0,33) | Tổng cộng | Threshold chuẩn hóa (Tổng / n) |
|---|---|---|---|---|---|
| 1 | 0,50 | 0,20 | 0,33 | 1.03 | 1.03 |
| 2 | 1,00 | 0,20 | 0,66 | 1,86 | 0,93 |
| 3 | 1,50 | 0,20 | 0,99 | 2,69 | 0,89 |
| 4 | 2,00 | 0,20 | 1,32 | 3.52 | 0,88 |
| 5 | 2,50 | 0,20 | 1,65 | 4,35 | 0,87 |
Như mong đợi trong biểu đồ này, biểu đồ trên cùng hiển thị một Block từ n-1 , trong đó màu vàng là Threshold cần xác nhận nhanh và màu xanh lá cây là trọng số của nút mà không áp dụng tăng cường đề xuất. Nó vẫn nằm dưới Threshold và luôn Short từ 2 đến 4 phần trăm nên không thể xác nhận được. Trong biểu đồ dưới cùng, Block nằm từ n-2 và trọng số cao hơn Threshold từ 1 đến 2 phần trăm nên có thể xác nhận được.
Quan sát #6
Với Threshold Byzantine là 25%, chúng ta có thể xác nhận một Block trong chưa đầy một khe, hoặc khoảng 8 giây. Xem lại biểu đồ khe đầu trừ khe an toàn và biểu đồ trọng số nút 0 so với Threshold an toàn.
Các mục theo dõi
Việc tổ chức lại cho các khối an toàn không bao giờ là ổn. Ví dụ, nếu các sàn giao dịch dựa vào các khối an toàn để xử lý việc rút tiền, việc tổ chức lại có thể dẫn đến tình trạng chi tiêu gấp đôi. Trong thử nghiệm của mình, chúng tôi đã quan sát thấy việc tổ chức lại Block an toàn, nhưng chỉ trong quá trình đồng bộ ban đầu với đầu chuỗi . Điều này có vẻ giống một vấn đề về triển khai hơn. Một cách khắc phục tiềm năng là chỉ áp dụng thuật toán xác nhận nhanh nếu Block có dấu thời gian khe hiện tại (h/t potuz), nếu không, hãy quay lại sử dụng thuật toán hợp lý hóa chưa thực hiện để đảm bảo an toàn.
- Điều này đã được thực hiện trong PR của Prysm ngày hôm nay
Bằng chứng an toàn xác nhận nhanh được mô tả trong bài báo sẽ có lợi khi có nhiều người xem hơn. Bằng chứng càng được thẩm định và xem xét kỹ lưỡng thì càng tốt—xem điểm 1. Việc tổ chức lại các khối an toàn có thể nguy hiểm tùy thuộc vào cách chúng được sử dụng trong thực tế.
Nếu bất kỳ ai có thắc mắc hoặc phản hồi, vui lòng liên hệ. Chúng tôi sẽ tiếp tục làm việc để triển khai sản xuất này sẵn sàng, chạy ở chế độ thử nghiệm dài hạn và công bố báo cáo phần 2 với các phát hiện được cập nhật.
