Vào ngày 30 tháng 6, Vitalik đã xuất bản một bài viết mới thảo luận về các vấn đề của Ethereum với tốc độ xác nhận giao dịch. Vitalik đề cập rằng Ethereum đã được cải thiện rất nhiều so với 5 năm trước Nhờ EIP-1559 (phí giao dịch điều chỉnh linh hoạt) và thời gian tạo khối ổn định sau khi sáp nhập, các giao dịch được người dùng gửi trên L1 thường trong vòng 5 -Được xác nhận trong vòng 20 giây. . Tuy nhiên, thời gian này có thể được cải thiện hơn nữa và đối với một số ứng dụng yêu cầu độ trễ rõ ràng là vài trăm mili giây hoặc thậm chí ít hơn, việc giảm thêm thời gian xác nhận là rất có ý nghĩa. Để đạt được mục tiêu này, cộng đồng Ethereum và các nhà nghiên cứu đã đề xuất một số giải pháp thiết thực, một trong số đó là Xác nhận trước.
Xác nhận trước là gì?
Xác nhận trước (preconf) là trạng thái xác nhận trước của một giao dịch trước khi nó được xác nhận chính thức. Cụ thể, nó đề cập đến xác nhận tạm thời của nút trước khi giao dịch được người khai thác đưa vào khối và chính thức đưa vào chuỗi. Xác nhận tạm thời này có nghĩa là nhiều nút xác minh tính hợp lệ của giao dịch và tạm thời lưu trữ nó trong bộ nhớ. hồ bơi. Điều này cho phép người dùng nhận được tín hiệu rằng giao dịch đã được chấp nhận trong một khoảng thời gian ngắn, từ đó nhận được phản hồi ngay lập tức để giảm thời gian chờ đợi và cải thiện trải nghiệm người dùng. Việc xác nhận trước này không phải là xác nhận cuối cùng và vẫn có thể bị thu hồi (chẳng hạn như tổ chức lại khối), tuy nhiên trường hợp này tương đối hiếm.
Thông thường, người đề xuất đóng vai trò cung cấp dịch vụ xác nhận trước trong cơ chế xác nhận trước. Với một khoản phí bổ sung, người dùng có thể nhận được cam kết chữ ký rằng giao dịch của họ sẽ được đưa vào khối tiếp theo. Nếu những người đề xuất không thực hiện đúng cam kết của mình, họ sẽ phải đối mặt với các hình phạt tài chính.
Kế hoạch thực hiện cụ thể: Dựa trên xác nhận trước
Justin Drake , một nhà nghiên cứu tại Ethereum Foundation, đã thúc đẩy một phương pháp cơ chế xác nhận trước của Ethereum: Xác nhận trước dựa trên , cung cấp xác nhận giao dịch nhanh chóng thông qua các cơ chế khuyến khích và hình phạt cụ thể.
Trong cơ chế Dựa trên preconfs, để giảm rủi ro giao dịch không được đóng gói thành các khối vì nhiều lý do, cần phải có hình phạt bổ sung cho người đề xuất và buộc phải đưa vào:
- Proposer slashing: Người đề xuất L1 phải chọn thêm điều kiện phạt bổ sung để trở thành người đề xuất trước. Điều này có thể đạt được thông qua các cơ chế liên quan đến đặt cược nặng.
- Proposer forced inclusions: Người đề xuất L1 phải có khả năng buộc các giao dịch được đưa vào chuỗi, ngay cả khi kinh tế không cao hoặc những người đề xuất khác không hợp tác. Điều này có thể đạt được thông qua danh sách bao gồm.
Người đề xuất L1 trở thành người xác nhận trước bằng cách chọn tham gia vào hai điều kiện phạt xác nhận trước sau đây. Người xác thực trước đưa ra các cam kết xác nhận trước đã ký cho người dùng, hứa sẽ bao gồm các giao dịch theo khối trong một khoảng thời gian xác định và nhận lời khuyên từ người dùng để thực hiện cam kết của họ.
- Liveness slashing: Người xác nhận trước sẽ phải đối mặt với hình phạt nếu họ không bao gồm các giao dịch được xác nhận trước trong một khoảng thời gian nhất định.
- Safety slashing: Người xác nhận trước sẽ phải chịu phạt nếu cam kết của họ không phù hợp với các giao dịch thực tế được đưa vào.
Ngoài ra, những người xác nhận trước sẽ được ưu tiên dựa trên vị trí của họ trong tầm nhìn của người đề xuất để thực hiện các giao dịch xác nhận trước nhanh hơn. Cơ chế xem trước của người đề xuất là một cơ chế được sử dụng để xác định những người đề xuất nào sẽ có cơ hội đóng gói các khối trong tương lai. Mỗi người đề xuất trong tương lai sẽ được chỉ định một số vị trí, đại diện cho vị trí của họ theo thứ tự khối trong tương lai. Những người xác nhận trước được sắp xếp sâu hơn theo vị trí của họ trong tầm nhìn phía trước của người đề xuất. Số vị trí càng nhỏ thì mức độ ưu tiên của người xác nhận trước càng cao. Giả sử giao dịch được thực hiện bởi người xác nhận trước B thì người đề xuất có số vị trí nhỏ hơn trước B (người xác nhận trước A) có thể đóng gói ngay giao dịch, giảm thời gian chờ đợi của người dùng và không phải đợi đến lượt B. thời gian làm người đề xuất. Nếu người đề xuất trước của B không đóng gói các giao dịch kịp thời, người xác nhận trước B cần đảm bảo rằng các giao dịch này được đưa vào trong khoảng thời gian của mình, nếu không sẽ phải đối mặt với các hình phạt.
Thông qua các điều kiện và cài đặt ở trên, các preconf dựa trên có thể cung cấp cho L1 khả năng xác nhận giao dịch nhanh hơn. Nếu dựa trên cơ sở tổng hợp (thứ tự của L2 được để lại cho L1), nghĩa là tất cả các khối L2 được coi là giao dịch L1 về mặt logic thì cơ chế tương tự có thể được sử dụng để cung cấp xác nhận trước cho L2.
Thảo luận cộng đồng
Justin Drake đã khiến cộng đồng chú ý đến cơ chế xác nhận trước sau khi đề xuất xác nhận trước. Sau đó, cộng đồng đã đưa ra một cuộc thảo luận phong phú xung quanh chủ đề xác nhận trước. Trong số đó, đáng chú ý nhất là: Jonah B , thành viên của Blockchain Capital, đề xuất cho phép người dùng tùy chỉnh các biện pháp trừng phạt trong cơ chế xác nhận trước; Matthew đề xuất sử dụng cơ chế xác nhận trước chuỗi (preconf chaining) để bảo vệ người đề xuất khỏi bị trừng phạt bởi các tình huống bất ngờ bên ngoài như mất điện, gián đoạn mạng, v.v. (nhà nghiên cứu Christian Matt của Primev đã giới thiệu hai chế độ xác nhận trước ); : một do người lãnh đạo được chỉ định (dựa trên người lãnh đạo) cung cấp xác nhận trước, và người kia do nhiều đối thủ cạnh tranh cung cấp xác nhận trước (không có người lãnh đạo) trong trường hợp không có người dẫn đầu. Ưu điểm của chế độ dẫn đầu là nó có thể đảm bảo xác nhận gần như 100%. Trong môi trường cạnh tranh không có người dẫn đầu, điều này giúp phát hiện hiệu quả các mức giá được xác nhận trước và tối ưu hóa doanh thu của người xác thực. Christian Matt cũng đề xuất một số giải pháp kết hợp xác nhận trước với người lãnh đạo và không có người lãnh đạo; potuz , thành viên của Ethereum Foundation đã thảo luận về các thách thức và giải pháp khác nhau để giới thiệu cơ chế xác nhận trước trong khuôn khổ ePBS.
