Xây dựng khối Ethereum: Nền kinh tế ẩn sau mỗi giao dịch

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:

• Slot: 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.
• Kỷ nguyên: Mỗi kỷ nguyên bao gồm 32 ô, tổng cộng là 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 2 kỷ nguyên (~12,8 phút) , sau đó gần như không thể hoàn nguyên các khối.

Các ủy ban

Ethereum 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 beaconcha.in 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 các ủy ban để 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.

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ó N Ủy ban được chỉ định cho mỗi khe và giả sử có M Người xác thực trong mỗi Ủy ban (trong đó M > 128). Điều này có nghĩa là có NxM 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.

• 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 M Người xác thực, chỉ có 1 Aggregated Attestation cuối cùng thay vì M

• Vì vậy, trong mỗi ô, có một bản cuối cùng của N 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 N chứng thực này.

  
  

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ó 64 Ủy ban cho mỗi vị trí tức là 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 1 Epoch (32 slot) 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. Lưu ý 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.

get_committee_assignment 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 ( current_epoch + 1 ). Đ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ọ.

Ngoài ra, một Validator có thể được chỉ định làm Aggregator 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.

Trách nhiệm của người đề xuất

Trong mỗi ô, một người xác thực duy nhất từ ủy ban tương ứng sẽ được chọn làm người đề xuất để tạo và gửi một khối.

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 SignedBeaconBlock tới mạng.
• 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à:

• Chạy trước : Đặ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 ngượ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á).
• Tấn công kiểu sandwich : 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.

Ai là người chiết xuất MEV?

• Trình xác thực (Trước PBS) : 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.
• Người tìm kiếm : 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 xây dựng (Sau PBS) : 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.

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ó toàn quyền kiểm soát thứ tự giao dịch . Đ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.

Cách thức hoạt động trước PBS:

1. Nhóm giao dịch : Các giao dịch được phát như bình thường và nhập vào mempool.
2. 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à priority_fee , đâ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).
3. 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.
4. Truyền khối : Khối đã ký được truyền tới mạng.

Đ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

• Tập trung năng lượng MEV : 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.
• Rủi ro kiểm duyệt gia tăng : 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ọ.
• Tắc nghẽn mạng và phí gas cao : 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.

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, Proposer-Builder Separation (PBS) đã đượ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:

1. Người xây dựng khối : 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.
2. Người đề xuất khối (Người xác thực) : 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.

Cách thức hoạt động sau PBS:

1. Những người xây dựng khối : 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.
2. Đấu thầu để đưa khối vào : 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.
3. Người xác thực chọn giá thầu cao nhất : 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ọ.

Cách xây dựng khối Ethereum hiện nay hoạt động như thế nào

1. Người dùng gửi giao dịch thông qua ví được kết nối JSON-RPC.
2. 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, Private Orderflows đã 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 Dune để biết thêm thông tin chi tiết.

3. Searchers → 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 ( thông tin chi tiết hơn về điều này bên dưới ). 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 eth_sendBundle .

   Lưu ý : 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.

   

   
   

4. Người xây dựng → 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.

   Họ điền vào các khối bằng:

   1. Các gói hàng được gửi bởi Searchers.

   2. Giao dịch có mức độ ưu tiên cao.

   3. Đặ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 feeRecipient 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.

   
   

5. Relays → 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à BeaverBuild và Titan. Để đơ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 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 feeRecipient 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 eth_getPaylaodHeader . Relay hiện gửi PayloadHeader 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.

Người đề xuất có 2 lựa chọn tại thời điểm này:

• Để chọn PayloadHeader (còn gọi là Blinded Block ) 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 PayloadBody bằng lệnh gọi eth_returnSignedHeader . Bây giờ Relay thực hiện lệnh gọi eth_sendPayload trả về toàn bộ ExecutionPayload 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.

  
  

• Người đề xuất có thể chọn không chấp nhận PayloadHeader 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.

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ý PayloadHeader vì lý do chính xác này. Trước khi gửi Header, Relay gửi PayloadBody đến Escrow để lưu giữ an toàn. Sau khi Relay nhận được PayloadHeader đã ký từ người đề xuất, nó sẽ xác minh chữ ký và gửi PayloadBody đượ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.

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 Censorship.pics, 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.

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 .

Danh sách bao gồm 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 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.

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

Danh sách bao gồm được thực thi bởi Fork Choice (FOCIL) 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.

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”.

Lợi ích của PBS trong quản lý MEV

• Phân quyền trích xuất 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 phối doanh thu công bằng hơn : 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.
• Sử dụng không gian khối hiệu quả 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.

Những thách thức của PBS

• Rủi ro tập trung giữa các nhà xây dựng : 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.
• Tin tưởng vào Rơ le MEV ngoài chuỗi : 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.

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