Xây dựng khối là một khía cạnh quan trọng trong vòng đời của Ethereum bao gồm nhiều bộ phận chuyển động khác nhau. Nó xác định giao dịch nào được đưa vào một khối và theo thứ tự nào, tác động trực tiếp đến hiệu quả mạng, tính phi tập trung và tính công bằng. Theo thời gian, quy trình sản xuất khối của Ethereum đã phát triển, đặc biệt là với vai trò ngày càng tăng của MEV và sự chuyển đổi từ lựa chọn do trình xác thực điều khiển sang trình xây dựng chuyên biệt. Bài đăng này sẽ thảo luận về cách Ethereum Block Building phát triển cùng với sự ra đời của Proposer Builder Separation và các nghiên cứu trong tương lai. Sơ lược về các thành phần xây dựng khối Ethereum Các khe cắm và thời đại Ethereum sắp xếp thời gian thành các đơn vị riêng biệt: Một slot là khoảng thời gian 12 giây trong đó một khối duy nhất có thể được đề xuất. Nếu không có trình xác thực nào gửi một khối trong một slot, nó sẽ bị bỏ qua. Slot: Mỗi kỷ nguyên bao gồm 32 ô, tổng cộng là . Kỷ nguyên: 6,4 phút Vào cuối mỗi kỷ nguyên, nhiệm vụ của người xác thực được xáo trộn để đảm bảo tính phi tập trung và bảo mật. Ethereum đạt được mục tiêu kinh tế sau , sau đó gần như không thể hoàn nguyên các khối. 2 kỷ nguyên (~12,8 phút) Các ủy ban có một số lượng lớn các Validator trong mạng lưới. Tại thời điểm viết bài, có 1.051.349 validator đang hoạt động theo Sẽ là không khả thi nếu nhiều validator như vậy phải xác minh từng khối sau mỗi 12 giây. Do đó, các validator được chia thành để xác thực hiệu quả các giao dịch và chứng thực tính hợp lệ của khối. Ethereum beaconcha.in các ủy ban Mỗi ủy ban: Bao gồm một tập hợp con các trình xác thực được chỉ định ngẫu nhiên vào đầu một kỷ nguyên bằng cách sử dụng RANDAO. Đảm bảo rằng không có trình xác thực nào có ảnh hưởng không cân xứng. Tham gia bỏ phiếu (chứng thực) cho các khối và xác nhận tính hợp lệ của chúng. Quy mô của một ủy ban phụ thuộc vào tổng số trình xác thực đang hoạt động trong mạng nhưng nhìn chung, mỗi ủy ban có ít nhất 128 trình xác thực. Trong mỗi ô: Giả sử có Ủy ban được chỉ định cho mỗi khe và giả sử có Người xác thực trong mỗi Ủy ban (trong đó > 128). Điều này có nghĩa là có xác thực cho mỗi khe. Như bạn có thể hiểu, việc truyền bá nhiều xác thực như vậy có thể nhanh chóng trở nên quá sức đối với mạng lưới. N M M NxM Các nhà tổng hợp trong mỗi Ủy ban được giao nhiệm vụ tổng hợp các chứng thực của Ủy ban tương ứng của họ. Điều này có nghĩa là trong một Ủy ban gồm Người xác thực, chỉ có 1 cuối cùng thay vì M Aggregated Attestation M Vì vậy, trong mỗi ô, có một bản cuối cùng của Chứng thực (1 cho mỗi ủy ban của ô đó) được đưa ra thảo luận về chủ đề toàn cầu. Người đề xuất của ô tiếp theo sẽ chọn chứng thực này. N N Một số điểm cần lưu ý Trong một kỷ nguyên, mỗi trình xác thực đang hoạt động đều là thành viên của đúng một ủy ban, do đó tất cả các ủy ban của kỷ nguyên đó đều không liên kết với nhau. Giao thức điều chỉnh tổng số ủy ban trong mỗi kỷ nguyên theo số lượng trình xác thực đang hoạt động. Thiết kế hiện tại là có Ủy ban cho mỗi vị trí tức là 64 N=64 Người đề xuất nhìn về phía trước Việc xáo trộn chuỗi beacon được thiết kế để cung cấp tối thiểu lookahead về các nhiệm vụ ủy ban sắp tới của trình xác thực để chứng thực được quyết định bởi việc xáo trộn và slot. rằng lookahead này không áp dụng cho việc đề xuất, mà phải được kiểm tra trong epoch đang đề cập. 1 Epoch (32 slot) Lưu ý có thể được gọi vào đầu mỗi kỷ nguyên để lấy nhiệm vụ cho kỷ nguyên tiếp theo ( ). Điều này cũng cho phép người xác thực tính toán ID mạng con, tham gia ủy ban tương ứng và chuẩn bị cho nhiệm vụ của họ. get_committee_assignment current_epoch + 1 Ngoài ra, một Validator có thể được chỉ định làm của một ủy ban cụ thể. Nếu vậy, họ cũng phải đăng ký vào chủ đề tương ứng. Aggregator Trách nhiệm của người đề xuất Trong mỗi ô, một sẽ được chọn làm để tạo và gửi một khối. người xác thực duy nhất từ ủy ban tương ứng người đề xuất Vai trò của người đề xuất rất quan trọng vì họ: Xây dựng khối bằng cách bao gồm các giao dịch và chứng thực đang chờ xử lý. Ký và phát tới mạng. SignedBeaconBlock Nhận phần thưởng khi đề xuất thành công các khối hợp lệ. Bài viết ngắn về MEV MEV là lợi nhuận bổ sung được trích xuất bởi người xác thực (trước đây là thợ đào) bằng cách sắp xếp lại, bao gồm hoặc kiểm duyệt các giao dịch trong một khối. Một số chiến lược MEV phổ biến là: : Đặt lệnh giao dịch ngay trước một giao dịch có lợi nhuận đã biết. Chạy trước cũng được coi là MEV độc hại vì nó gây bất ngờ cho người dùng với tác động tiêu cực. Chạy trước : Thực hiện giao dịch ngay sau một sự kiện cụ thể (ví dụ: bot chênh lệch giá). Chạy ngược : Sự kết hợp giữa tấn công trực diện và tấn công gián tiếp, đặc biệt là trong giao dịch DeFi. Tấn công kiểu sandwich Ai là người chiết xuất MEV? : Khi trình xác thực kiểm soát việc sản xuất khối, họ có toàn quyền quyết định thứ tự giao dịch và có thể trực tiếp trích xuất MEV. Trình xác thực (Trước PBS) : Các tác nhân độc lập quét mempool để tìm kiếm cơ hội MEV và gửi giao dịch phù hợp. Người tìm kiếm : Sau PBS, người xây dựng khối đảm nhận vai trò xây dựng các khối được tối ưu hóa MEV, trong khi người xác thực chỉ cần chọn các khối từ người trả giá cao nhất. Người xây dựng (Sau PBS) Xây dựng khối trước PBS: MEV lấy người xác thực làm trung tâm Trước khi Ethereum chuyển sang PBS, người đề xuất (trước đây là thợ đào trong PoW) có . Điều này tạo ra một hệ sinh thái nơi MEV được trích xuất trực tiếp bởi trình xác thực hoặc thuê ngoài cho những người tìm kiếm chuyên biệt. toàn quyền kiểm soát thứ tự giao dịch Cách thức hoạt động trước PBS: : Các giao dịch được phát như bình thường và nhập vào mempool. Nhóm giao dịch Trình xác thực đã chọn lọc các giao dịch từ mempool. Những giao dịch này có thể được sắp xếp theo thứ tự gọi là , đây là phí mà người dùng sẵn sàng trả để được đưa vào đầu tiên. Nó cũng có thể được sắp xếp theo cách mà Trình xác thực tạo ra nhiều doanh thu hơn (thông qua sandwich/frontrunning). priority_fee Trình xác thực xây dựng khối dựa trên các giao dịch mà họ đã chọn. : Khối đã ký được truyền tới mạng. Truyền khối Điều này được trừu tượng hóa một cách lỏng lẻo để đơn giản hóa. Nhưng đây là dòng chảy chung. Điều này có thể được gọi là Xây dựng khối vani Các vấn đề với việc xây dựng khối trước PBS : Các trình xác thực lớn có lợi thế kinh tế hơn các trình xác thực nhỏ hơn do khả năng trích xuất MEV hiệu quả hơn. Tập trung năng lượng MEV : Người xác thực có thể chọn loại trừ các giao dịch không phù hợp với động cơ tài chính của họ. Rủi ro kiểm duyệt gia tăng : Cuộc chiến đấu thầu giao dịch MEV dẫn đến việc sử dụng không gian khối không hiệu quả, làm tăng chi phí cho người dùng thông thường. Tắc nghẽn mạng và phí gas cao Xây dựng khối sau PBS: Tách biệt người đề xuất và người xây dựng Để giải quyết các rủi ro tập trung hóa và tình trạng kém hiệu quả của việc xây dựng khối do trình xác thực kiểm soát, đã được giới thiệu. PBS chia tách trách nhiệm sản xuất khối giữa hai thực thể riêng biệt: Proposer-Builder Separation (PBS) : Các thực thể chuyên xây dựng các khối được tối ưu hóa, thường kết hợp các chiến lược MEV. Người xây dựng khối : Người xác thực không còn tự xây dựng các khối nữa; họ chỉ cần chọn khối có lợi nhuận cao nhất do người xây dựng cung cấp. Người đề xuất khối (Người xác thực) Cách thức hoạt động sau PBS: : Những người xây dựng khối cạnh tranh để xây dựng khối có lợi nhuận cao nhất, tính đến các cơ hội khai thác MEV. Những người xây dựng khối : Các nhà xây dựng đấu thầu để đề xuất khối của họ cho những người xác thực, đảm bảo rằng những người xác thực nhận được lựa chọn có lợi nhất. Đấu thầu để đưa khối vào : Thay vì chọn từng giao dịch riêng lẻ, người xác thực chỉ cần chọn khối của người xây dựng có giá thầu cao nhất, qua đó tối đa hóa phần thưởng của họ. Người xác thực chọn giá thầu cao nhất Cách xây dựng khối Ethereum hiện nay hoạt động như thế nào Người dùng gửi giao dịch thông qua ví được kết nối JSON-RPC. Giao dịch này được gửi vào mempool công khai. Tất cả các giao dịch được đổ vào đây trước khi chúng được chọn và xác thực. Gần đây, đã trở thành tâm điểm với hầu hết những người chơi lớn lựa chọn điều này vì đây là giải pháp thay thế cho việc phát sóng các giao dịch của bạn tới công chúng bằng cách sử dụng các kênh được cấp phép/riêng tư. Kiểm tra bảng điều khiển trên để biết thêm thông tin chi tiết. Private Orderflows Dune → là những thực thể bên ngoài liên tục quét mempool để tìm kiếm các cơ hội MEV ( ). Họ lấy các giao dịch tương ứng và chèn giao dịch của riêng họ nếu và khi cần thiết để kiếm lợi nhuận. Sau đó, tạo một bó các giao dịch này, thứ tự của chúng phải được duy trì trong suốt quá trình để Searcher kiếm được lợi nhuận. Các bó là các giao dịch được sắp xếp phải được thực hiện một cách nguyên tử. Cùng với bó này, họ có thể thêm một giao dịch vào cuối bó biểu thị "hối lộ" cho Builder. Bó này được gửi đến Builder thông qua lệnh gọi . Searchers thông tin chi tiết hơn về điều này bên dưới eth_sendBundle : Người tìm kiếm là những thực thể bên ngoài và có ảnh hưởng đến thứ tự giao dịch nhưng không tham gia vào xác thực khối hoặc quyết định đồng thuận. Lưu ý → Thực thể tiếp theo là Người xây dựng, người thực sự xây dựng khối. Họ cố gắng tối đa hóa cả doanh thu phí cũng như doanh thu MEV. Họ bao gồm các giao dịch được đóng gói do Người tìm kiếm gửi (hy vọng là theo thứ tự) và chấp nhận khoản thanh toán (hối lộ) do Người tìm kiếm gửi. Người xây dựng xây dựng các tải trọng thực thi bằng cách sử dụng các giao dịch đã nhận. Người xây dựng Họ điền vào các khối bằng: Các gói hàng được gửi bởi Searchers. Giao dịch có mức độ ưu tiên cao. Đặt hàng các giao dịch chung cần lưu ý để tối đa hóa doanh thu. Họ cũng đặt trường thành địa chỉ của riêng họ, biểu thị rằng họ sẽ nhận được cả tiền hối lộ của Searcher cũng như tất cả các khoản phí từ các giao dịch trong khối đã gửi của họ. Người xây dựng gửi một giao dịch vào cuối khối của họ, đóng vai trò là khoản hối lộ cho người đề xuất tương tự như những gì Searcher đã làm cho Người xây dựng. feeRecipient : Người xây dựng là những thực thể bên ngoài và không tương tác trực tiếp với blockchain. Lưu ý → Thị trường Builder là một thị trường cạnh tranh với nhiều builder muốn hoàn thiện payload của họ để kiếm được phí. Tuy nhiên, hầu hết các khối được xây dựng bởi một số Block Builder nổi tiếng, cụ thể là và Để đơn giản hóa quy trình này cho Proposer thực tế, Relays là các thực thể trung gian xác thực payload do nhiều Builder khác nhau gửi và chọn ra payload có lợi nhuận/giá thầu tối đa. Giao tiếp Relay-Proposer sử dụng một thủ thuật gọn gàng tương tự như Commit và Reveal để đảm bảo Proposer không gian lận mọi thực thể cho đến thời điểm này. Thêm thông tin . Relays BeaverBuild Titan. tại đây Lắp ráp lại với nhau Giao tiếp với người đề xuất chuyển tiếp Hoàn toàn có thể khi nhận được khối tải trọng, người đề xuất sẽ mở gói khối, chèn các giao dịch của họ và thay đổi thứ tự theo ý thích của họ cũng như đặt thành địa chỉ của họ. Điều này có nghĩa là mọi thực thể đã làm việc trên quy trình xây dựng khối cho đến bây giờ (Searcher → Builder → Relay) sẽ bị gian lận hoặc thực hiện "trộm MEV". Để ngăn chặn điều này, Relay chỉ gửi Header của Block Payload đã chọn. Điều này xảy ra khi người đề xuất thực hiện lệnh gọi . Relay hiện gửi chứa hàm băm của phần thân, giá thầu và chữ ký của người xây dựng. feeRecipient eth_getPaylaodHeader PayloadHeader Người đề xuất có 2 lựa chọn tại thời điểm này: Để chọn (còn gọi là ) do Relay cung cấp. Nếu vậy, người đề xuất phải ký header bằng khóa của họ và gửi lại cho Relay và sau đó yêu cầu bằng lệnh gọi . Bây giờ Relay thực hiện lệnh gọi trả về toàn bộ cho người đề xuất. Sau đó, người đề xuất chỉ cần đề xuất khối này cho mạng lưới Ethereum Validator hoặc cụ thể hơn là cho ủy ban mà họ được chỉ định. PayloadHeader Blinded Block PayloadBody eth_returnSignedHeader eth_sendPayload ExecutionPayload Người đề xuất có thể chọn không chấp nhận do Relay gửi, trong trường hợp đó, họ phải tự xây dựng khối. Điều này bao gồm việc tìm kiếm các cơ hội MEV và sắp xếp các giao dịch theo đó. Tất nhiên, trong trường hợp này, Người đề xuất sẽ giữ toàn bộ doanh thu từ phí + MEV. Tuy nhiên, điều này không đơn giản như vẻ bề ngoài. Việc tìm kiếm MEV và tối ưu hóa doanh thu là một nhiệm vụ khá tốn kém về mặt tính toán và có khả năng là người đề xuất không thể xây dựng khối kịp thời (12 giây), do đó sẽ có một khe bị bỏ lỡ. Trong trường hợp này, người đề xuất có thể bị cắt khỏi mạng. PayloadHeader Nhưng trong Trường hợp 1, điều gì sẽ xảy ra nếu Người đề xuất không gửi khối được gửi bởi Relay? Vâng, người đề xuất được yêu cầu ký vì lý do chính xác này. Trước khi gửi Header, Relay gửi đến để lưu giữ an toàn. Sau khi Relay nhận được đã ký từ người đề xuất, nó sẽ xác minh chữ ký và gửi được lưu trữ trong escrow đến Proposer. Bây giờ, giả sử người đề xuất không bao gồm Block này. Nó xây dựng khối riêng của mình, bỏ qua thứ tự đã thực hiện cho đến nay. Trong trường hợp này, chữ ký sẽ không khớp vì các header đã thay đổi. PayloadHeader PayloadBody Escrow PayloadHeader PayloadBody : Lưu ý Việc ký hai Tiêu đề khác nhau cho cùng một vị trí đề xuất là hành vi vi phạm có thể bị phạt. Người xây dựng hiện có thể phát các Tiêu đề đã ký xung đột này tới mạng và Người đề xuất có thể bị loại khỏi mạng. Điều gì ngăn cản Builders kiểm duyệt các giao dịch? Vâng, không có gì cả. Lý do phổ biến nhất khiến Builders có thể kiểm duyệt một giao dịch là vì nó tương tác với . các địa chỉ OFAC Nói một cách đơn giản, OFAC giải quyết các giao dịch tương tác có thể có hậu quả pháp lý, điều mà rõ ràng là không ai muốn xảy ra. Theo các khối do Builders xây dựng chỉ bao gồm 0-7% giao dịch được OFAC chấp thuận. Censorship.pics, Chúng ta giải quyết vấn đề này thế nào? Một trong những giải pháp kiểm duyệt giao dịch được biết đến nhiều nhất tại thời điểm viết bài này là . Inclusion Lists là danh sách các giao dịch (cùng với thứ gọi là Tóm tắt) được Người đề xuất của Khe N đăng cùng với việc đề xuất Khối của Khe N. Danh sách bao gồm Danh sách bao gồm bắt buộc các giao dịch trong danh sách phải được bao gồm trong Khối N hoặc Khối N+1, nếu không thì khối N+1 sẽ không hợp lệ. Chúng được gọi là Danh sách bao gồm chuyển tiếp. : Cũng có một khái niệm về thực hiện IL cho chính Block N hiện tại. Nhưng thiết kế này có những sai sót về mặt kinh tế dẫn đến Lưu ý Spot Inclusion Lists Forward Inclusion Lists. Tất nhiên, thiết kế IL này sẽ không cho phép Chống kiểm duyệt 100%, nhưng hiện đang có nhiều nghiên cứu tích cực được tiến hành để củng cố các đề xuất này và nhiều tối ưu hóa tuyệt vời có thể được áp dụng để cải thiện cấu trúc khuyến khích. TIÊU ĐIỂM là thiết kế mới được đề xuất vào năm 2024 nhằm xây dựng và cải thiện Danh sách bao gồm để tăng tính trung lập đáng tin cậy. Danh sách bao gồm được thực thi bởi Fork Choice (FOCIL) FOCIL cho phép nhiều Validator đưa ra các gợi ý về Inclusion List cho một vị trí cụ thể. Nói chính xác hơn, 16 Validator được chọn ngẫu nhiên tại mỗi vị trí để thành lập một Ủy ban Inclusion List. Mỗi thành viên này thành lập IL cục bộ của riêng mình và truyền bá nó đến mạng lưới. Người đề xuất thu thập và tổng hợp các danh sách bao gồm cục bộ có sẵn thành một IL cuối cùng. Các thiết kế IL rất nhẹ vì không cần phải xây dựng lại khối để bao gồm các giao dịch này; chúng chỉ có thể được thêm vào khối. Điều kiện để một Khối đáp ứng yêu cầu xác thực IL là “ Khối hợp lệ nếu nó chứa tất cả các giao dịch từ tất cả các IL cho đến khi khối đầy”. : Các thành viên ủy ban IL không thể đảm bảo bất kỳ hình thức sắp xếp giao dịch nào vì các giao dịch IL có thể được đưa vào bất kỳ thứ tự nào. Họ chỉ đảm bảo việc bao gồm giao dịch. Lưu ý Lợi ích của PBS trong quản lý MEV : Các nhà xây dựng khối, thay vì một vài trình xác thực lớn, xử lý việc trích xuất MEV, giảm thiểu rủi ro tập trung trình xác thực. Tuy nhiên, đây là con dao hai lưỡi vì trong quá trình giảm thiểu tập trung trình xác thực, chúng tôi đã giới thiệu Trung tâm hóa trình xây dựng, trong đó chỉ một vài trình xây dựng xây dựng một tỷ lệ lớn các khối. Phân quyền trích xuất MEV : Người xác thực vẫn được hưởng lợi từ MEV mà không cần trực tiếp tham gia vào quá trình trích xuất, giúp việc sản xuất khối trở nên công bằng hơn. Phân phối doanh thu công bằng hơn : Sự cạnh tranh giữa các nhà xây dựng dẫn đến các khối được tối ưu hóa với hiệu suất sử dụng khí tốt hơn. Sử dụng không gian khối hiệu quả hơn Những thách thức của PBS : Mặc dù các trình xác thực được phân cấp, một số nhà xây dựng chiếm ưu thế vẫn có thể tập trung hóa việc trích xuất MEV. Rủi ro tập trung giữa các nhà xây dựng : Hiện tại, PBS đang dựa vào các rơ le MEV-Boost hoạt động ngoài chuỗi, gây ra rủi ro bảo mật tiềm ẩn do lỗi điểm. Tin tưởng vào Rơ le MEV ngoài chuỗi Tài liệu tham khảo: Sự tách biệt giữa Proposer-Builder của Ethereum: Lời hứa và thực tế Tình hình nghiên cứu: khả năng chống kiểm duyệt theo PBS Kiểm duyệt của nhà xây dựng: cốt lõi thối nát của ethereum EPF Wiki - PBS Ghi chú về PBS Chuyển tiếp danh sách bao gồm Ai thắng cuộc đấu giá xây dựng khối Ethereum và tại sao? TIÊU ĐIỂM Lời cảm ơn Cảm ơn , và đã đánh giá và đưa ra gợi ý. @mteam @Gajpower @unnawut
