Thanh toán Không cần tin cậy
Tóm lại
Chúng tôi ủng hộ việc giữ lại thành phần thanh toán Không cần tin cậy của Đề xuất cải tiến Ethereum (EIP)-7732. Mặc dù thiết kế có thể được cải thiện, nhưng những hạn chế không quá nghiêm trọng, có thể được khắc phục và không làm lu mờ tầm quan trọng của tính năng không cần xin phép.
Hợp tác cùng @jcschlegel , @quintuskilbourn , @boz1 và @LuisVCorreia . Cảm ơn @tripoli vì những phản hồi chi tiết. Và cuối cùng, xin cảm ơn tất cả các thành viên của Hiệp hội ePBS thinkboi.
Trong bài viết này, chúng tôi cung cấp tổng quan về những tác động của thanh toán Không cần tin cậy được giới thiệu bởi Đề xuất cải tiến Ethereum (EIP)-7732 và lý giải sự ủng hộ của chúng tôi đối với Đề xuất cải tiến Ethereum (EIP). Chúng tôi chỉ phản ánh quan điểm cá nhân và không đại diện cho lập trường của toàn bộ tổ chức Flashbots.
Chúng ta hãy bắt đầu với điều mà chúng ta cho là hiển nhiên: sự tách biệt giữa người đề xuất và người xây dựng sẽ vẫn là kiến trúc xây dựng khối của Ethereum trong tương lai gần. Cách hiệu quả để tổ chức tương tác giữa người đề xuất và người xây dựng là thông qua đấu giá Block tức thời (JIT). Ngay cả khi chúng ta muốn thiết lập một cấu trúc thị trường khác (ví dụ: thông qua APS), hiệu quả đòi hỏi một thị trường JIT ngoài giao thức phải xuất hiện để đạt được hiệu quả. Câu hỏi cốt lõi là mạng Ethereum nên tương tác với thị trường này như thế nào.
Hiện tại, các trình xác thực duy trì danh sách các "trung gian" đáng tin cậy nằm ngoài giao thức và cung cấp các khối. Sự khác biệt giữa trung gian và người xây dựng ở đây không phải là vốn có (và rõ ràng là đang mờ dần) - điều quan trọng nhất là ai có quyền truy cập vào người đề xuất . Việc đảm bảo quyền truy cập vào người đề xuất hiện nay liên quan đến việc phát triển kinh doanh và xây dựng lòng tin với các nhà điều hành nút. Đây chính là kiểu phối hợp phức tạp mà Ethereum muốn tránh. Để có một giao thức mạnh mẽ và bền vững trên toàn bộ hệ thống, chúng ta không nên để các phần quan trọng, cốt lõi cho chức năng hiệu quả của nó, hoạt động hoàn toàn dựa trên lòng tin. Lựa chọn khả thi duy nhất về lâu dài là ghi nhận vai trò của người xây dựng trong giao thức và cung cấp một cách thức để người xây dựng và người đề xuất ký kết hợp đồng trong giao thức mà không cần tin tưởng lẫn nhau.
Từ những điều đã nêu ở trên, có thể suy ra rằng chúng ta nên hoặc là triển khai các trình xây dựng được ghi nhận và thanh toán Không cần tin cậy ngay bây giờ với Đề xuất cải tiến Ethereum (EIP)-7732 và đề xuất hiện có, hoặc là chờ đợi và triển khai chúng sau này. Theo chúng tôi, lý do duy nhất để chờ đợi là nếu 1) đề xuất hiện tại có một lỗi nghiêm trọng hoặc 2) có một thiết kế thay thế khả thi và đủ chi tiết mà chúng ta có thể triển khai sớm. Những lỗi nhỏ không nên là lý do để dừng quá trình và có thể được sửa đổi hoặc cải thiện trong các bản cập nhật giao thức trong tương lai. Việc trì hoãn cơ chế thanh toán Không cần tin cậy thêm nữa trong tương lai sẽ chỉ làm cho việc giới thiệu trở nên khó khăn hơn vì hệ sinh thái bên ngoài giao thức xung quanh sẽ ngày càng được thiết lập vững chắc hơn. Lựa chọn 2) không khả dụng đối với chúng ta, do đó chúng ta cần xác định xem có lỗi nghiêm trọng nào không và đồng thời kiểm tra xem các lỗi nhỏ có thể được giảm thiểu hoặc loại bỏ hay không.
Vậy chúng ta hãy cùng xem xét những vấn đề tiềm ẩn với phương thức thanh toán Không cần tin cậy như đề xuất và xem liệu có vấn đề nào trong số đó là một thiếu sót lớn hay không:
Chi phí Vốn cho các nhà xây dựng
Đấu thầu trong giao thức yêu cầu các nhà xây dựng phải Stake , điều này làm phát sinh thêm chi phí. Cụ thể, họ cần vận hành một trình xác thực và trở thành cơ sở hạ tầng quan trọng cho mạng lưới, điều này đòi hỏi phải khóa 32 ETH vào giao thức. Hơn nữa, họ cần phải thế chấp thêm các giá thầu, tương tự như những gì họ đã làm với các relay lạc quan. Sự kết hợp các chi phí này có thể loại bỏ một lượng lớn các nhà xây dựng tham gia đấu thầu trong giao thức nhưng không muốn hoặc không đủ khả năng khóa tiền trong một khoảng thời gian không xác định.
Những chi phí này không hề nhỏ, tuy nhiên nhiệm vụ của người xác thực tạo ra lợi nhuận trên toàn bộ số dư của người xây dựng 0x03, do đó chi phí thực tế chỉ là chi phí cơ hội, chi phí vận hành và chi phí huy động Vốn. Hầu hết các giá thầu khối không lớn lắm (<0,02 ETH) (99% giá thầu Block nhỏ hơn 0,46 ETH). Những chi phí này cũng có thể được tránh một phần, vì các dịch vụ chuyển tiếp có khả năng sẽ tiếp tục tồn tại (thông qua các biến thể đã đặt cọc và chưa đặt cọc), cung cấp quyền truy cập cho người đề xuất đối với các tác nhân chưa đặt cọc. Việc thế chấp các giá thầu trong mọi trường hợp là cần thiết đối với bất kỳ hệ thống đấu thầu không cần cấp phép nào không dựa vào uy tín hoặc sử dụng các dịch vụ DA bổ sung.
Hơn nữa, nhiều chi phí Vốn có thể được giảm thiểu bằng cách cải thiện các điểm không hiệu quả về mặt kỹ thuật, cả trong Đề xuất cải tiến Ethereum (EIP) hiện tại lẫn trong tương lai. Ví dụ, việc bắt buộc các nhà phát triển phải chạy trình xác thực và Stake 32 ETH là không hợp lý nếu chúng ta thiết kế một hệ thống từ đầu. Điều này tồn tại là do sự phụ thuộc vào tiến trình và nợ kỹ thuật, và lý tưởng nhất là sẽ được loại bỏ trong tương lai (ví dụ: thông qua các bản nâng cấp giao thức trong tương lai để giảm yêu cầu Stake trình xác thực ).
Hình: Phần thưởng MEV (<1 ETH) giữa các khối 20000000 và 23984511.
Chi phí công nghệ và độ phức tạp vận hành
Việc triển khai các phương thức thanh toán Không cần tin cậy sẽ đòi hỏi các nhà phát triển và các bên trung gian phải thích ứng với sự thay đổi và tạo ra nhiều trạng thái hơn để các máy khách Consensus theo dõi.
Việc đấu thầu trong giao thức diễn ra chậm hơn bằng cách sử dụng các tính năng gửi tiền và rút tiền một phần của lớp Consensus Ethereum. Điều này loại bỏ tính linh hoạt của việc cấp vốn và thanh toán đấu thầu JIT, vì người xây dựng cần phải đăng ký với giao thức và nạp tiền vào tài khoản của họ để đấu thầu. Đây là hệ quả của việc triển khai logic xây dựng hoàn toàn trên lớp Consensus , vốn không được xây dựng cho các khoản thanh toán giữa các trình xác thực. Điều này làm cho tính năng này khó sử dụng hơn, nhưng không phải là không thể sử dụng được và có thể được cải thiện trong tương lai.
Cần xem xét thêm các cải tiến khác như phát hiện và quản lý điểm cuối trình tạo lập trình cho các trình xác thực.
Mặc dù tất cả những điều này đều đòi hỏi thêm nỗ lực, nhưng chúng tôi tin rằng chi phí này là hợp lý, đặc biệt là vì bất kỳ hình thức thuê ngoài sản xuất Block Không cần tin cậy sẽ yêu cầu một số công việc này. Cũng cần lưu ý rằng thanh toán Không cần tin cậy loại bỏ nhu cầu quản lý mối quan hệ với các nhà điều hành nút, điều cần thiết để các máy chuyển tiếp giành và duy trì thị phần. Vì vậy, nó loại bỏ chi phí phát sinh này.
Cấu trúc thị trường
Thị trường xây dựng khối Ethereum hiện nay đã có mức độ tập trung cao , làm dấy lên lo ngại về tính trung lập lâu dài của chuỗi. Một mối quan ngại hợp lý cần được giải quyết là liệu Đề xuất cải tiến Ethereum (EIP)-7732 có thể làm tăng thêm sự tập trung do chi phí Vốn và quản lý rủi ro hay không.
Như chúng tôi đã đề cập trong phần về chi phí Vốn , chúng tôi tin rằng những lo ngại này có thể không nghiêm trọng như dự đoán. Quan trọng hơn, chúng tôi tin rằng tốt hơn hết là nên chuyển rủi ro và sự phức tạp sang các bên tham gia thị trường bên ngoài thay vì người đề xuất. Nếu không có EIP7732, việc quản lý rủi ro của người đề xuất thể hiện ở việc quản lý danh sách cho phép. Với EIP7732, người đề xuất không cần phải tin tưởng vào các máy chủ chuyển tiếp. Điều quan trọng là, Đề xuất cải tiến Ethereum (EIP) không ngăn cản việc tạo khối từ những người xây dựng chưa được đặt cọc.
Trong cả hai trường hợp, chúng tôi tin rằng thách thức về tính trung lập cần được giải quyết triệt để hơn ở cấp độ giao thức, thông qua các cơ chế như FOCIL nhằm tăng cường khả năng chống kiểm duyệt.
Ý nghĩa đối với vấn đề quyền chọn tự do
Việc sử dụng kỹ thuật đường ống (pipelining) đã tạo ra "Vấn đề lựa chọn tự do" và vấn đề này không biến mất nếu chúng ta loại bỏ các khoản thanh toán Không cần tin cậy . Trên thực tế, vấn đề lựa chọn tự do có thể diễn ra theo cách khác: nếu chúng ta buộc các lệnh đặt giá phải thông qua các máy trung gian, thì các máy trung gian có thể giúp kiểm soát vấn đề lựa chọn tự do. Các cơ chế giảm thiểu ở cấp độ máy trung gian có thể là các biện pháp như yêu cầu đặt cọc đối với các nhà xây dựng để kiểm soát các lỗi phân phối tải trọng, chỉ cho phép các lệnh đặt giá từ một nhóm nhà xây dựng được cấp phép (hoặc chặn các nhà xây dựng đã không phân phối được tải trọng trong quá khứ) hoặc chỉ cho phép các lệnh đặt giá "lạc quan" đối với một nhóm nhà xây dựng được cấp phép.
Về nguyên tắc, các cơ chế giảm thiểu như vậy cũng khả thi trong giao thức, ví dụ như thông qua các yêu cầu đặt cọc của người xây dựng, có thể được sử dụng để trừng phạt trong trường hợp tải trọng không thành công. Chúng tôi đã ủng hộ và mô tả chi tiết điều này trong bài đăng này . Trong bối cảnh này, việc cho phép hoặc chặn truy cập phức tạp hơn, vì người đề xuất thường không có động lực để sử dụng chúng. Tuy nhiên, chúng ta không nên dựa vào chúng lâu dài ở cấp độ máy chủ chuyển tiếp, vì điều này hoặc dẫn đến việc phân biệt đối xử giữa những người xây dựng (về các dịch vụ mà họ có thể truy cập) do các tác nhân ngoài giao thức quản lý, hoặc dẫn đến việc các máy chủ chuyển tiếp mới (hoặc hiện có) cung cấp những gì hấp dẫn đối với người đề xuất - quyền truy cập vào những người xây dựng bằng cách sử dụng "tùy chọn miễn phí" cùng với cơ chế thanh toán vô điều kiện do máy chủ chuyển tiếp làm trung gian.
Đấu thầu kín
Nếu sử dụng phương thức liên lạc trực tiếp và bỏ qua các trung gian, hình thức đấu giá sẽ chuyển đổi hiệu quả từ hình thức hiện tại - đấu giá công khai với thời hạn ngẫu nhiên - sang đấu giá kín.
Mặc dù một số người cho rằng đấu giá kín theo hệ thống ePBS ảnh hưởng tiêu cực đến cấu trúc thị trường của các nhà thầu, chúng tôi cho rằng tác động tổng thể là trung lập hoặc thậm chí tích cực. Cụ thể, hình thức đấu giá công khai hiện tại ưu tiên những nhà thầu có lợi thế về độ trễ, cho phép họ vượt mặt các đối thủ cạnh tranh ngay trước thời hạn. Sự bất đối xứng này thúc đẩy sự tập trung thị trường . Ngược lại, đấu giá kín san bằng sân chơi bằng cách trung hòa những lợi thế về độ trễ này, dẫn đến một cơ chế công bằng hơn. Đấu giá kín dẫn đến ít hồ sơ dự thầu cần xử lý hơn cho mỗi nhà thầu và do đó tiết kiệm băng thông hơn.
Mặc dù người ta có thể lập luận rằng cơ chế này thiếu tính đáng tin cậy—cụ thể là, các nhà xác thực có thể có động cơ để tiết lộ giá thầu nhằm tăng doanh thu—trừ khi cuộc đấu giá có một thành phần giá trị chung đáng kể và không xác định, nhìn chung các nhà xác thực không có động cơ để tiết lộ thông tin trong một cuộc đấu giá kín với giá khởi điểm. Đáng chú ý, điều này dẫn đến kết quả đấu giá hiệu quả hơn, tăng doanh thu ở trạng thái cân bằng và công bằng hơn cho tất cả những người tham gia thị trường.
Sẽ chẳng ai dùng đến chúng sao?
Như chúng ta đã lập luận cho đến nay, chi phí bổ sung của việc sử dụng thanh toán Không cần tin cậy dường như là nhỏ và cũng có tiềm năng về hiệu quả. Các relay lạc quan có thể cho chúng ta một số trực quan về những gì chúng ta có thể mong đợi: hiện tại, phần lớn các khối được đề xuất thông qua con đường lạc quan và những người xây dựng sẵn sàng gửi tiền vào các relay lạc quan, nhưng đối với các khối có giá trị cao, họ có thể sử dụng con đường bi quan. Chúng ta có thể kỳ vọng những điều tương tự sẽ xảy ra với thanh toán Không cần tin cậy : sử dụng song song cả hai con đường tùy thuộc vào tình huống.
Sự khác biệt về giá trị giữa đấu thầu trong giao thức và ngoài giao thức đối với các nhà xây dựng dường như không đáng kể, điều này dẫn chúng ta đến trở ngại lớn nhất: chi phí chuyển đổi . Nói cách khác, việc tích hợp con đường trong giao thức đòi hỏi nỗ lực kỹ thuật từ phía các nhà xây dựng. Vì vậy, chúng ta hãy chỉ ra điều hiển nhiên: điều này phụ thuộc phần lớn vào thiện chí của những người tham gia hệ sinh thái (chủ yếu là các nhà xây dựng và các máy chủ trung gian) để muốn làm cho nó hoạt động. Chúng tôi rất lạc quan về điểm này, vì trong lịch sử, mọi người đã tham gia để làm cho Ethereum hoạt động và ưu tiên lợi ích lâu dài hơn là tiết kiệm chi phí Short hạn. Như có lẽ các bạn đã nhận thấy, chúng tôi đang tiến gần đến một trong những nhà xây dựng lớn và rõ ràng chúng tôi sẽ vận động họ chấp nhận con đường trong giao thức và phân bổ năng lực kỹ thuật để làm cho nó hoạt động.
