Tóm tắt nội dung; Không đọc hết

• ePBS được thiết kế với tập trung vào bảo mật giao thức, cấp cho người xây dựng hoàn toàn kiểm soát trên các giao dịch khối.
• Nó tích hợp Tách rời người đề xuất-xây dựng (PBS) trực tiếp vào lớp đồng thuận của Ethereum, được gọi là In-Protocol PBS, để giải quyết các lỗi chuyển tiếp tiềm năng và loại bỏ điểm hỏng hệ thống duy nhất.
• ePBS tiếp tục nền tảng của PBS bằng cách giảm sự kiểm soát của một thực thể duy nhất đối với nội dung khối, nâng cao khả năng chống kiểm duyệt và phi tập trung của mạng.
• Ủy ban Đúng Hẹn Của Dữ Liệu (PTC) đảm bảo tính đúng hẹn và tính hợp lệ của giao dịch trong các khối mới.

Giới thiệu

Vào tháng 2, nhà phát triển Prysm Potuz đã đề cập đến vấn đề tin cậy trong mainnet của Ethereum, đề xuất việc hoãn Electra fork cho đến năm 2025, sử dụng Sự kiện Tương thích để hoàn thiện thiết kế ePBS. Tuy nhiên, trong cộng đồng Ethereum, có ý kiến trái chiều, với một số nhà phát triển và nhà nghiên cứu lo lắng về những rủi ro tiềm ẩn. Ý kiến về ePBS được chia rẽ, vì vậy hôm nay chúng ta sẽ tìm hiểu về ePBS là gì và nó khác biệt như thế nào so với PBS.

Trước đây, chúng tôi đã đề cập rằng cơ chế PBS đảm bảo an ninh của sự cam kết của người đề xuất và giải thích của người xây dựng bằng cách giao trách nhiệm này cho các relay được tin cậy. Relay lưu trữ nội dung khối và đảm bảo rằng người đề xuất nhận được nội dung khối nhưng không thể dễ dàng đánh cắp nội dung của người xây dựng. Tuy nhiên, nếu relay là độc hại, cả người đề xuất và người xây dựng đều có thể bị tổn thương, và họ chỉ có thể chuyển sang relay khác và hy vọng nó không độc hại. Điều này đặt ra một vấn đề: chúng ta phải tìm một bên thứ ba được tin cậy để ủy quyền. PBS là một giải pháp ngoại chuỗi phụ thuộc vào sự đồng thuận của cộng đồng và tuân thủ tự nguyện, đòi hỏi sự phối hợp và niềm tin bổ sung.

Trong PBS, phải có một vai trò trung gian để hoạt động như một người quản lý niềm tin bên thứ ba:

• Các người đề xuất phải tin tưởng vào bên trung gian nếu muốn bán quyền nội dung khối.
• Những người xây dựng phải tin tưởng trung gian nếu muốn mua quyền xây dựng khối.

Thiết kế Cách mạng của ePBS

Phân Tách Xây Dựng Nhà Đề Xuất Tích Hợp

Tách Biệt Người Đề Xuất-Vận Động Viên (ePBS) là một biến thể của PBS tích hợp trực tiếp vào lớp đồng thuận của Ethereum, còn được gọi là In-Protocol PBS. Nó được thiết kế để giải quyết các sự cố truyền tải tiềm năng và loại bỏ các điểm thất bại đơn hệ thống. Là một cơ chế đồng thuận mới nổi, chúng ta sẽ giải thích về ePBS, các nguyên tắc cốt lõi, ưu điểm và sự khác biệt so với Tách Biệt Người Đề Xuất-Vận Động Viên (PBS) truyền thống.

PBS thay thế nhu cầu về vai trò truyền tín hiệu tin cậy bằng cách sử dụng chính giao thức Ethereum. Nếu Proposer hoặc Builder hành động một cách độc hại, giao thức Ethereum có thể áp dụng các hình phạt (như tịch thu), loại bỏ sự phụ thuộc vào việc tin tưởng một vai trò của bên thứ ba. Điều này là sự khác biệt chính giữa PBS, nơi sự tin tưởng là bên ngoài.

Tuy nhiên, việc tách biệt vai trò trong ePBS vẫn tuân theo cấu trúc PBS ban đầu, giảm sự kiểm soát của một thực thể duy nhất đối với nội dung khối, từ đó nâng cao khả năng chống kiểm duyệt và phi tập trung của mạng blockchain.

• Người đề xuất: Trách nhiệm đề xuất khối, bao gồm thông tin tiêu đề khối.
• Builder: Trách nhiệm xây dựng nội dung khối.

Hai lợi ích chính

Trừng Phạt Trực Tiếp Cho Hành Vi Điều Hành Xấu & Không Cần Sự Tin Cậy của Bên Thứ Ba

Từ tên của nó, rõ ràng rằng thuật ngữ “Truyền thống” trong ePBS phản ánh thiết kế tích hợp giao thức của nó, cho phép trừng phạt trực tiếp hành vi độc hại. Sự tích hợp này một cách tinh tế biến đổi mô hình tin cậy trong hệ thống.

1. Khả năng tích hợp để phát hiện và thực thi

   Trong PBS, việc xác định và phạt hành động độc hại phụ thuộc vào sự can thiệp của bên thứ ba, chẳng hạn như các nhà xác thực hoặc thiết bị truyền tải. Ngược lại, ePBS, là giao thức nguyên bản, cho phép chính giao thức tự phát hiện và xử lý vi phạm mà không cần sự tham gia từ bên ngoài.

2. Giảm sự phụ thuộc vào bên thứ ba, nâng cao tính phi tập trung

   PBS inherently depends on external governance or third parties, which introduces an element of trust centralization. ePBS, however, embeds rules within the giao thức, fundamentally reducing reliance on external trust. This shift enhances the decentralization of the system, making it more robust and resistant to manipulation.

*So sánh giữa PBS truyền thống và ePBS👇

Thiết kế ePBS

Vũ điệu thực hiện và xác minh

Trong hệ thống Proof of Stake (PoS) của Ethereum, thời gian cho mỗi khe được chia thành các khoảng thời gian 12 giây. Trong mỗi khe, một người xác thực được chọn ngẫu nhiên để đề xuất một khối, và một ủy ban được giao nhiệm vụ để xác minh tính hợp lệ của khối đó. Nếu không có khối được đề xuất trong khe đã cho, người xác thực có trách nhiệm sẽ xác minh khối trước đó sau 4 giây.

Nguồn: ethresearch, một khe ePBS sẽ được xử lý bởi Consensus Layer (CL) và Execution Layer (EL). Thông tin khối được phát sóng trong lớp đồng thuận, sau đó khối được gửi đến lớp thực thi để xác minh.

1. Giai đoạn đặt giá thầu khối: Nhà xây dựng bắt đầu đặt giá thầu và gửi giá thầu cho Người đề xuất.
2. Proposer Broadcasting: Người đề xuất chọn giá trúng thầu và quyết định có nên sử dụng Danh sách đưa vào để xây dựng nội dung khối hay không, sau đó phát khối.
3. Bỏ phiếu của người xác minh: Khi nhìn thấy khối, người xác minh bỏ phiếu dựa trên kết quả xác minh của họ.
4. Chứng thực Tổng hợp: Chứng thực được tổng hợp bởi Aggregators, họ kết hợp chứng minh từ nhiều validator cho cùng một block. Các validator sau đó sử dụng chứng thực tổng hợp để xác minh block.
5. Phát sóng Payload: Người xây dựng phải công bố đầy đủ payload thực thi trong thời gian chỉ định.
6. Bỏ phiếu PTC: Ủy ban tính đúng giờ của dữ liệu (PTC) giám sát và xác minh xem dữ liệu của Builder có đúng giờ và hợp lệ không.
7. Người đề xuất của vị trí tiếp theo xuất bản khối của họ, xây dựng nó trên một khối đầy đủ hoặc trống dựa trên kết quả bỏ phiếu của PTC và các chứng thực tổng hợp. Một khối có tỷ lệ phiếu PT kịp thời cao hơn được coi là một khối đầy đủ.

PTC - đảm bảo tính kịp thời và hợp lệ của các giao dịch trong các khối mới \Ủy ban kịp thời tải trọng (PTC) đảm bảo rằng các giao dịch trong các khối mới được bổ sung kịp thời và chính xác. Ủy ban này bao gồm các trình xác thực (521 thành viên mượn từ ủy ban chuỗi đèn hiệu), những người kiểm tra xem Người xây dựng đã hoàn thành việc điền giao dịch của khối hay chưa và liệu các giao dịch này có được thực hiện chính xác theo các quy tắc trước khi kết thúc mỗi chu kỳ tạo khối hay không.

Một cách đơn giản, PTC hoạt động như một đội quản lý, đảm bảo rằng Người xây dựng gửi công việc của họ đúng hạn và bao gồm các giao dịch chính xác trong khối. Nếu Người xây dựng làm tốt và gửi khối yêu cầu đúng hạn, PTC xác nhận thông qua bỏ phiếu. Như vậy, mạng có thể xác định được những khối nào đã hoàn chỉnh và hợp lệ, và những khối nào có thể có vấn đề hoặc chưa hoàn chỉnh.

Qua cơ chế bỏ phiếu, PTC ảnh hưởng đến việc một khối được coi là “khối đầy đủ” hay “khối trống”. Nếu PTC xác minh tính kịp thời và đúng đắn của dữ liệu đầu vào, khối được nhận dạng là “khối đầy đủ”. Nếu không có dữ liệu đầu vào hoặc dữ liệu đầu vào bị trễ, khối có thể được đánh dấu là “khối trống”. Dựa trên phiếu bỏ của PTC, mạng trực tiếp thưởng hoặc phạt Proposer và Builder để khuyến khích xây dựng khối kịp thời và chính xác.

• Full Block: Khối chứa một bộ payload hợp lệ hoàn chỉnh, có thể bao gồm nhiều giao dịch, và trạng thái thực hiện giao dịch được cập nhật đúng thời điểm.
• Khối Rỗng: Khối chứa rất ít hoặc không có giao dịch nào. Có thể là một khối CL, nhưng nó không cập nhật trạng thái EL.
• Khối bị thiếu: Một khe trống rỗng. Điều này đề cập đến một khối được dự kiến nhưng không được tạo ra hoặc thành công thêm vào chuỗi. Các khối bị thiếu có thể được phân loại là đầy đủ hoặc trống dựa trên sự bỏ phiếu lựa chọn (khối, khe).

Khả năng chống kiểm duyệt của ePBS, kết hợp với Thiết kế danh sách bao gồm

Trong khi thiết kế cốt lõi của ePBS xoay quanh việc bảo mật của Builder và cấp cho Builder quyền kiểm soát đầy đủ các giao dịch khối, việc triển khai Danh sách bao gồm (Inclusion List) là một sự kết hợp hoàn hảo để đạt được khả năng chống kiểm duyệt và phân tán.

Trong các bài viết trước, chúng tôi đã thảo luận vềCLquá trình (để biết thêm chi tiết, vui lòng truy cập: https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rg). Tóm lại, Người đề xuất cung cấp cho Người xây dựng một danh sách các giao dịch cần được ưu tiên. Danh sách này phải bao gồm tất cả các giao dịch hiện đang hoạt động, bất kể chúng có nằm trong nhóm giao dịch hay không. Miễn là còn khoảng trống trong khối, các giao dịch từ danh sách phải được đưa vào khối của Trình tạo. Nếu khối đầy, Người xây dựng phải chỉ rõ và xác nhận rằng họ đã thừa nhận danh sách.

Khi một Builder cố gắng kiểm duyệt một số giao dịch cụ thể, phí cơ bản sẽ tăng nhanh do việc triển khai EIP-1559, khi các khối liên tục được điền đầy giao dịch. Nếu Builder cố gắng thêm các giao dịch giả mạo vào khối để thực hiện kiểm duyệt, các khoản phí tăng cao sẽ làm cho các hành động đó trở nên không khả thi và không thực tế.

Tóm tắt

ePBS tách biệt vai trò của Proposer và Builder thông qua tích hợp giao thức của nó. Với PTC hoạt động như một tập hợp con của ủy ban xác minh, nó có trách nhiệm bỏ phiếu về tính hợp lệ và kịp thời của Tải trọng thực thi do Nhà xây dựng phát hành. Ưu điểm cốt lõi của ePBS nằm ở sự thay đổi từ việc dựa vào các bên thứ ba đáng tin cậy sang được giám sát và phạt trực tiếp bởi chính giao thức Ethereum, giảm nhu cầu tin tưởng vào một thực thể duy nhất. Điều này không chỉ tăng cường khả năng chống kiểm duyệt của hệ thống mà còn tăng cường bảo vệ giao dịch thông qua các cơ chế như Danh sách đưa vào, khiến chi phí kiểm duyệt các giao dịch trở nên cao và không thực tế.

Chúng ta cần lưu ý rằng ePBS cung cấp một tùy chọn cho phân tách Block Proposer-Builder ở cấp độ giao thức, thay vì bắt buộc. Sự khác biệt chính giữa ePBS và các mô hình khác nằm ở cơ chế thanh toán và mô hình tin cậy của chúng. Khi xem xét vấn đề tin cậy của toàn bộ giao thức, chi phí phải trả là nhu cầu cam kết trả trước phí. Ngược lại, MEV-Boost cho phép thanh toán cho Beacon Proposer dựa trên lợi nhuận thu được từ Execution Payload được sắp xếp, mang lại nhiều cơ hội lợi nhuận hơn. Có lẽ một ngày nào đó, ePBS có thể phát triển đến mức không còn cần cam kết trả trước phí nữa - đây là một hy vọng nhỏ cho tương lai!

Tham chiếu

@ttsao/epbs-faq0””>@ttsao/epbs-faq0"">https://hackmd.io/@ttsao/epbs-faq0

@potuz/rJ9GCnT1C””>@potuz/rJ9GCnT1C"">https://hackmd.io/@potuz/rJ9GCnT1C

https://mirror.xyz/ohotties.eth/kw_7qbkOl4NV1pmpRgVwtsS-7TZff_zTmmNEOm2BbmU

https://mirror.xyz/barnabe.eth/LJUb_TpANS0VWi3TOwGx_fgomBvqPaQ39anVj3mnCOg

https://ethresear.ch/t/epbs-design-constraints/18728?u=barnabe

@potuz/ry9NirU2p””>@potuz/ry9NirU2p"">https://hackmd.io/@potuz/ry9NirU2p

https://vitalik.eth.limo/general/2023/09/30/enshrinement.html

https://ethresear.ch/t/three-dichotomies-in-epbs/16267

https://ethresear.ch/t/the-contention-between-preconfs-and-epbs/19770?utm_source=substack&utm_medium=email

Disclaimer:

1. Bài viết này được sao chép từ [gate.io]Uncommons], Tất cả bản quyền thuộc về tác giả gốc [Jocelyn]. Nếu có ý kiến phản đối về việc tái bản này, vui lòng liên hệ với Học cửa gateđội ngũ và họ sẽ xử lý nó một cách nhanh chóng.
2. Thông báo từ chối trách nhiệm: Quan điểm và ý kiến được diễn tả trong bài viết này chỉ là quan điểm của tác giả và không hề đưa ra bất kỳ lời khuyên đầu tư nào.
3. Bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài báo đã dịch đều bị cấm.