MEV-Boost, giao thức sidecar trích xuất MEV trong hình vuông ETH hiện tại, phụ thuộc rất nhiều vào một người tham gia tập trung được gọi là Chuyển tiếp. Chúng tôi đề xuất một kiến trúc thay thế cho phép giao tiếp trực tiếp, riêng tư về mặt mật mã giữa các nhà xây dựng và người đề xuất. Kiến trúc này dựa trên một dạng mã hóa ngưỡng "im lặng" không tương tác mới có thể sử dụng cặp BLSChìa khoá bảo mật hiện có của Người xác thực.
Bản chất, chúng tôi đề xuất mã hóa Khối qua ngưỡng cửa, gửi nó cho một phần của người tham gia, từ đó sử dụng ủy ban chứng minh để đạt được tính riêng tư và sẵn có của dữ liệu. Chứng minh của họ tạo nên chìa khoá bảo mật giải mã; khi đạt được ngưỡng cửa cần thiết, Khối có thể được giải mã.
Giải pháp xây dựng của chúng tôi giải quyết vấn đề bảo mật giữa người xây dựng và người đề xuất, nhưng nó không đảm bảo tính hiệu quả của Khối một mình. Nó có thể kết hợp với các cơ chế khác để hoàn toàn sao chép các chức năng được cung cấp bởi Chuyển tiếp, bao gồm cả tính bảo mật và tính hiệu quả của Khối. Ví dụ, có thể sử dụng chứng minh Môi trường thực thi tin cậy (TEE) hoặc chứng minh không biết (ZK), hoặc cung cấp bảo đảm cho người xây dựng thông qua cơ chế kinh tế mã hóa.
Chúng tôi nhằm mục tiêu giảm Trễ và nâng cao khả năng Phi tập trung và chống kiểm duyệt của Ethereum bằng cách loại bỏ yêu cầu bảo vệ sự riêng tư của Chuyển tiếp và đảm bảo tính hiệu quả của Khối.
Vai trò của MEV-Boost và Chuyển tiếp
MEV-Boost là một giao thức trung gian, đóng vai trò là trung gian giữa người xây dựng khối và người đề xuất. Chuyển tiếp có tác dụng chính là cung cấp hai đảm bảo:
Quyền riêng tư của người xây dựng: Chuyển tiếp đảm bảo nhà đề xuất không thể xem nội dung Khối và không thể đánh cắp MEV mà người xây dựng tìm thấy.
Bảo mật người đề xuất: Rơle đảm bảo rằng người xây dựng trả giá trị đã hứa cho người đề xuất theo giá thầu của nó và khối đó hợp lệ (ví dụ: tất cả các giao dịch đều trả phí khí nội tại).
Tuy nhiên, sự phụ thuộc vào Chuyển tiếp đã mang lại sự tập trung đáng kể. Khoảng 90% khối ETH của các nhóm chỉ thông qua vài Chuyển tiếp. Điều này mang lại một số rủi ro:
中心化:Các nhà xây dựng có thể tăng hiệu quả trễ bằng cách triển khai chung với Chuyển tiếp, thay vì phản ánh phân bố địa lý của người đề xuất. Điều này trực tiếp làm suy yếu tính phi tập trung địa lý và khả năng chống kiểm duyệt mà chúng ta có thể đạt được từ việc thu thập đại trà người xác thực trên toàn cầu.
Thu nhập: Thời gian xử lý khối trung bình từ đầu đến cuối hiệu quả của việc Chuyển tiếp khoảng 5-20 miligiây. Sau đó, còn có một khoảng Trễ trong giao tiếp giữa người xây dựng và người đề xuất. Bỏ qua việc Chuyển tiếp sẽ giảm bớt Trễ, giảm thiểu rủi ro thực hiện qua các lĩnh vực khác nhau (ví dụ: CEX/DEX), và cuối cùng làm tăng phần thưởng MEV của người đề xuất.
TEE-Boost
Một trong những đề xuất chính thay thế cho Chuyển tiếp là "TEE-Boost", nó phụ thuộc vào môi trường thực thi đáng tin cậy (TEEs). Lưu ý rằng TEEs không phải là trung tâm của giải pháp của chúng tôi; sử dụng TEE-Boost như một ví dụ hướng dẫn cho vấn đề chúng tôi cố gắng giải quyết là rất hữu ích.
Cụ thể hơn, TEE-Boost yêu cầu người xây dựng sử dụng TEE để tạo ra chứng thực, chứng minh tính trung thực của giá trị đề xuất và tính hiệu quả của Khối mà không cần tiết lộ nội dung thực tế của Khối cho người đề xuất. Người đề xuất có thể kiểm tra các chứng thực này trên phần cứng thông thường mà không cần chạy TEE.
然而,TEE-Boost存在数据可用性问题:构建者只与提议者共享TEE证明和Khối头,而不共享实际的Khối内容[1] và có thể chọn không phát hành nội dung Khối sau khi người đề xuất ký kết phần đầu (ví dụ, nếu điều kiện thị trường thay đổi không thuận lợi). Các phương pháp đề xuất để giải quyết vấn đề sẵn có dữ liệu này bao gồm:
TEE-Lưu trữ: TEE-Lưu trữ nhận Khối từ người xây dựng trước khi người đề xuất ký và phát hành Khối sau khi nhìn thấy phần đầu ký hiệu.
Lớp sẵn sàng dữ liệu: Trình dựng xuất bản Khối payload của mã hóa lên lớp Data Availability (DA).
Cả hai phương pháp đều có nhược điểm. Giải pháp lưu trữ TEE đã sao chép một cách tương tự với Trễ tập trung hiện có để Chuyển tiếp động[2]. Nếu sử dụng lớp DA bên ngoài thì sẽ đưa ra các giả định giao thức phụ và phải chịu đựng các độ trễ động của giao thức bên ngoài đó (các động tác này cũng có thể không có lợi).
Về lý thuyết, nếu người đề xuất cũng có thể truy cập TEE, người xây dựng có thể mã hóa khối đó vào TEE mà người đề xuất đang chạy. TEE của người đề xuất chỉ được giải mã sau khi được ký. Tuy nhiên, chúng tôi cho rằng TEE-Boost không xem xét thiết kế này vì điều đó sẽ yêu cầu người đề xuất (Người xác thực) chạy TEE. Chúng tôi hy vọng Người xác thực có thể chạy trên phần cứng thông thường.
Nếu người đề xuất tự mình triển khai TEE-Giữ an toàn như là một phần của việc triển khai chung với Người xác thựcNút, thì có thể tránh được việc trễ động
Tuy nhiên, chúng tôi cũng không muốn Người xác thực chạy TEEs. ↩
Mật mã ngưỡng để bảo vệ quyền riêng tư của người xây dựng
Chúng tôi đã đề xuất một giải pháp tinh vi để giải quyết vấn đề khả năng sử dụng dữ liệu của TEE-Boost: mã hóa ngưỡng cho Hội đồng xác minh. Cụ thể, người xây dựng sẽ mã hóa khối thành tỷ lệ xác định của Hội đồng xác minh cho khe thời gian đó. Khi đã thu thập đủ chứng thực, khối có thể được giải mã và sử dụng được.
Công nghệ cho phép cốt lõi là mã hóa im lặng. Kỹ thuật mật mã này [cho phép mã hóa được kiểm soát] (https://eprint.iacr.org/2024/263) mà không cần giai đoạn thiết lập tạo Chìa khoá bảo mật phân tán tương tác (DKG) cần thiết cho bản dựng trước đó. Thay vào đó, Khóa chung công khai được tính toán dựa trên khai BLS hiện có và một số "gợi ý" (thảo luận sau) chắc chắn trong Người xác thực.
Điều này cho phép giao tiếp trực tiếp giữa Builder và Người xác thực, với tính riêng tư mật mã. Người xác thực không cần chạy TEEs hoặc quản lý bất kỳ tài liệu Chìa khoá bảo mật mới nào.
Cơ chế:
Người xây dựng xây dựng một Khối và mã hóa nó cho ủy ban xác thực.
Xây dựng một chứng minh TEE, chứng minh cho ủy ban xác minh ba khía cạnh: đấu giá là trung thực, Khối là hợp lệ và mã hóa là chính xác.
Người xây dựng truyền tải khối đã được mã hóa và chứng thực TEE (bao gồm giá trị đề xuất) cho người đề xuất.[3]
Người đề xuất ký khối mật mã của người xây dựng chiến thắng và tuyên truyền đề xuất đến tập hợp các trình xác thực.
Khi một khối được chứng nhận bởi ủy ban xác minh theo tỷ lệ cụ thể (ví dụ: n / 2 hoặc 2n / 3), nó sẽ được giải mã.
Khối được giải mã sẽ được xác nhận cuối cùng một cách bình thường.
Ảnh hưởng của yêu cầu băng thông của người đề xuất cần được nghiên cứu. Người đề xuất có băng thông thấp có thể hạn chế yêu cầu bằng cách xác nhận trước khi gửi Khối hoặc sử dụng các kỹ thuật lọc và tải thông minh khác. Đây là một vấn đề mở, nhưng có vẻ như việc giải quyết không khó hơn việc lan truyền rác trong memory pool bình thường.
Lưu ý
Hiển thị
Các tính năng hiệu suất của ngưỡng mã hóa vô âm thanh là rất thuận lợi. Ở đây, n là quy mô tối đa của ủy ban mà chúng tôi muốn hỗ trợ, t là ngưỡng giải mã.
Thời gian mã hóa và giải mã một phần đều là thời gian hằng số. Với một cài đặt đơn giản, mã hóa mất ít hơn 7 miligiây và có thể được thực hiện song song. Thời gian giải mã một phần mất ít hơn 1 miligiây.
Bản mã大小比Văn bản thuần túy大768字节,这是一个常量附加因素(对于任何n和t)。
Một phần giải mã tổng hợp (tức là giải mã) phụ thuộc vào kích thước của ủy ban. Khi n=1024, thời gian thực hiện đơn giản là dưới 200 mili giây. Chúng tôi dự đoán rằng khi n=128 (kích thước của ủy ban xác thực cho mỗi khe thời gian), thời gian này sẽ giảm đi 10 lần và triển khai có thể được tối ưu hóa thêm.
Quan trọng là, thời gian mã hóa là chỉ số hiệu suất quan trọng được so sánh với Trễ Chuyển tiếp. Điều này là nội dung phải tính toán trong 'đường dẫn chính' được xây dựng bởi người tạo ra Khối. Thời gian này phải thấp hơn Trễ xử lý Khối Chuyển tiếp hiện tại và tránh giao tiếp nhiều bước.
Phát hành dữ liệu
Cổng im lặng mã hóa không hoàn toàn miễn phí. Nó thực sự cần một chuỗi tham chiếu chung, có dạng: (g, gτ, gτ², …, gτⁿ⁻ᵗ), tương tự như nội dung được sử dụng trong lập trình cam kết đa thức KZG.
Ngoài ra, mỗi Người xác thực có hình thức là g⁽ˢᵏ⁾ BLSKhóa công khai phát hành một tập hợp các phần tử nhóm chúng ta gọi là "gợi ý": (g⁽ˢᵏ⁾⋅τ, …, g⁽ˢᵏ⁾⋅τⁿ⁻ᵗ). Những gợi ý này chỉ cần thiết khi tổng hợp Khóa công khai và giải mã Bản mã. mã hóa chỉ sử dụng kích thước hằng số của tổng hợp Khóa công khai.
Với việc kích hoạt MaxEB, yêu cầu này có thể sẽ giảm đáng kể. MaxEB cho phép người xác thực kiểm soát số dư lớn hơn 32 ETH trong cùng một khóa bảo mật (thay vì phân tán số dư đó thành nhiều khoản tiền gửi 32 ETH). Việc giảm số lượng người xác thực được thực hiện còn đang được thảo luận. Chúng ta có thể giảm xuống khoảng 1GB.
Cuối cùng, dựa trên sự thay đổi trong tương lai của kiến trúc Ethereum (ví dụ, việc giảm quy mô của Nhận thức chung hoặc thay thế đường ống xác nhận cuối cùng), kích thước gợi ý cần lưu trữ có thể giảm xuống hơn nữa.
Năng lượng
Etherum Mong muốn vẫn duy trì trạng thái trực tuyến trong điều kiện mạng không thuận lợi. Vấn đề của giải pháp này là do ủy ban với tỷ lệ xác định bị mất kết nối, có thể xảy ra vấn đề không thể giải mã được Khối.
Một giải pháp là cho phép người xây dựng quyết định tỷ lệ ủy ban可接受的委员会比例(t)用于解密. Tồn tại sự cân nhắc giữa quyền riêng tư (khả năng giải mã và khả năng đánh cắp MEV) và ngưỡng ủy ban trực tuyến. Đối với người xây dựng, việc khối của họ được bao gồm trong chuỗi thay vì bị fork là tối đa hóa thu nhập, vì vậy họ nên tìm cách thiết lập ngưỡng tối ưu.[4]
Ngoài ra, việc sử dụng sơ đồ mã hóa này phải là tự nguyện. Trong điều kiện mạng bất lợi, nếu không có ủy ban nào có quy mô chấp nhận được có thể duy trì trực tuyến, những người đề xuất và xây dựng có thể quay trở lại sử dụng rơle, tự xây dựng hoặc các cơ chế khác mà họ lựa chọn tùy thuộc vào bản chất của môi trường bất lợi.
Cụ thể, giá trị kỳ vọng của Khối của người xây dựng được fork ra là âm (họ không có thu nhập từ đó), trong khi giá trị kỳ vọng của việc giải nén là rất âm. Nếu cho phép người xây dựng lựa chọn t trong khoảng [0, 128], họ tự nhiên sẽ được khuyến khích chọn một giá trị t đủ cao để giảm thiểu rủi ro của việc Thả giải nén và tăng cơ hội được thỏa mãn (ít nhất tên thành viên hội đồng trực tuyến). Dưới điều kiện mạng bình thường, một số Khối có thể bị fork ra, nhưng chúng tôi nhận thấy điều này đã xảy ra trong trò chơi thời gian, trong khi tính hoạt động của chuỗi vẫn là chấp nhận được.
Khối không khả dụng
Ngoài ra, ủy ban có thể trực tuyến, nhưng người xây dựng có thể tạo ra một tình huống khiến Khối không thể giải mã hoặc vô hiệu hóa khi giải mã (ví dụ, sử dụng chứng chỉ gian lận).
Từ góc độ của giao thức, việc fork ra khỏi các Khối này là hoàn toàn khả thi. Một cách rộng lớn, Người xác thực đơn giản không thể chứng minh được bất kỳ Khối nào thuộc loại Khối này hoặc bất kỳ Khối nào được tham chiếu đến chúng. Phương pháp tốt nhất để xử lý lỗi này có thể là làm cho client Nhận thức chung nhận ra khả năng này và có thể thất bại một cách tinh tế. Cần phải nghiên cứu thêm về vấn đề này.
Cấu trúc thị trường
Người xây dựng chiến thắng biết nội dung của Khối trước khi đạt ngưỡng, điều này có thể tạo ưu thế không công bằng trong giai đoạn tiếp theo. Tuy nhiên, ủy ban chứng minh nên hành động trước khi kết thúc giai đoạn tiếp theo, và hầu hết giá trị của Khối tập trung vào cuối giai đoạn, do đó tác động của ưu thế này nên được giảm thiểu càng nhiều càng tốt.
Bằng chứng mật mã thuần túy
Từ xa, có thể có cơ hội sử dụng Bằng chứng không kiến thức(ZK证明) thay thế cho Chứng minh TEE. Hiện tại, tốc độ của ZK证明 quá chậm, nhưng tiến triển trong mật mã học, phần mềm và phần cứng ASICs có thể cuối cùng làm cho việc tạo ra ZK证明 trong giới hạn Trễ cần thiết trở nên khả thi. Đáng chú ý rằng, cùng với Khối, ZK证明 đã trở thành một phần cốt lõi của ETH坊 dài hạn.
Phương pháp tốt nhất có thể là nâng cấp trước hoặc sau MaxEB để cho phía khách hàng Nhận thức chung nhận thức được khả năng mã hóa Khối và khuyến khích Người xác thực đăng thông báo. Ví dụ, sau MaxEB, có thể yêu cầu Người xác thực mới đăng thông báo, trong khi Người xác thực cũ có thể nhận được khuyến khích nâng cấp.
Một khi đủ số lượng Người xác thực đã chấp nhận cơ chế này, Người xây dựng sẽ bắt đầu sử dụng nó để đảm bảo có đủ quy mô ủy ban (tức là, đảm bảo sự kết hợp giữa quyền riêng tư và khả năng giải mã).
Nếu phương pháp của chúng tôi thực sự vượt trội trong việc Trễ so với việc chuyển tiếp nhiều bước, thị trường có lẽ sẽ tự động áp dụng nó mà không cần sử dụng buộc hoặc quy định cài đặt tham số cụ thể.
Nguyên lý cơ bản
Chuyển tiếp là một trong những nguồn trung tâm quan trọng nhất của Ethereum, dẫn đến cơ hội cho thuê và biến t distort giao thức Phi tập trung địa lý. Chúng ta cần loại bỏ Chuyển tiếp và xem đó là một giải pháp tương đối tinh tế. Nó đòi hỏi thay đổi tầng đồng thuận, nhưng không đòi hỏi Người xác thực cung cấp phần cứng mới hoặc tài liệu Chìa khoá bảo mật mới.
Nhược điểm là đây là một sự thay đổi phức tạp đối với lớp đồng thuận, và cơ chế này (nếu được chọn lựa như đề xuất) có thể được thị trường chấp nhận hoặc không. Tuy nhiên, nhiều thay đổi tiềm năng về đường ống MEV cũng đối mặt với vấn đề chấp nhận và tối ưu hóa lợi nhuận tương tự (ví dụ, bao gồm danh sách). Và trong tương lai, có thể có các trường hợp sử dụng khác phụ thuộc vào cơ sở hạ tầng mã hóa với ngưỡng sở hữu xác thực.
Tuyên bố:
Bài viết này được sao chép từ [ paradigm],著作权归属原作者[Charlie NoyesGuru, Vamsi Policharla],如对转载有异议,请联系Gate Learn团队,团队会根据相关流程尽速处理。
Tuyên bố miễn trừ 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á nhân của tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
Các phiên bản bằng ngôn ngữ khác của bài viết được dịch bởi nhóm Gate Learn, không được sao chép, phát tán hoặc sao lưu bài viết đã được dịch mà không được đề cập đến Gate.io.
Làm thế nào để loại bỏ Chuyển tiếp
MEV-Boost, giao thức sidecar trích xuất MEV trong hình vuông ETH hiện tại, phụ thuộc rất nhiều vào một người tham gia tập trung được gọi là Chuyển tiếp. Chúng tôi đề xuất một kiến trúc thay thế cho phép giao tiếp trực tiếp, riêng tư về mặt mật mã giữa các nhà xây dựng và người đề xuất. Kiến trúc này dựa trên một dạng mã hóa ngưỡng "im lặng" không tương tác mới có thể sử dụng cặp BLSChìa khoá bảo mật hiện có của Người xác thực.
Bản chất, chúng tôi đề xuất mã hóa Khối qua ngưỡng cửa, gửi nó cho một phần của người tham gia, từ đó sử dụng ủy ban chứng minh để đạt được tính riêng tư và sẵn có của dữ liệu. Chứng minh của họ tạo nên chìa khoá bảo mật giải mã; khi đạt được ngưỡng cửa cần thiết, Khối có thể được giải mã.
Giải pháp xây dựng của chúng tôi giải quyết vấn đề bảo mật giữa người xây dựng và người đề xuất, nhưng nó không đảm bảo tính hiệu quả của Khối một mình. Nó có thể kết hợp với các cơ chế khác để hoàn toàn sao chép các chức năng được cung cấp bởi Chuyển tiếp, bao gồm cả tính bảo mật và tính hiệu quả của Khối. Ví dụ, có thể sử dụng chứng minh Môi trường thực thi tin cậy (TEE) hoặc chứng minh không biết (ZK), hoặc cung cấp bảo đảm cho người xây dựng thông qua cơ chế kinh tế mã hóa.
Chúng tôi nhằm mục tiêu giảm Trễ và nâng cao khả năng Phi tập trung và chống kiểm duyệt của Ethereum bằng cách loại bỏ yêu cầu bảo vệ sự riêng tư của Chuyển tiếp và đảm bảo tính hiệu quả của Khối.
Vai trò của MEV-Boost và Chuyển tiếp
MEV-Boost là một giao thức trung gian, đóng vai trò là trung gian giữa người xây dựng khối và người đề xuất. Chuyển tiếp có tác dụng chính là cung cấp hai đảm bảo:
Tuy nhiên, sự phụ thuộc vào Chuyển tiếp đã mang lại sự tập trung đáng kể. Khoảng 90% khối ETH của các nhóm chỉ thông qua vài Chuyển tiếp. Điều này mang lại một số rủi ro:
TEE-Boost
Một trong những đề xuất chính thay thế cho Chuyển tiếp là "TEE-Boost", nó phụ thuộc vào môi trường thực thi đáng tin cậy (TEEs). Lưu ý rằng TEEs không phải là trung tâm của giải pháp của chúng tôi; sử dụng TEE-Boost như một ví dụ hướng dẫn cho vấn đề chúng tôi cố gắng giải quyết là rất hữu ích.
Cụ thể hơn, TEE-Boost yêu cầu người xây dựng sử dụng TEE để tạo ra chứng thực, chứng minh tính trung thực của giá trị đề xuất và tính hiệu quả của Khối mà không cần tiết lộ nội dung thực tế của Khối cho người đề xuất. Người đề xuất có thể kiểm tra các chứng thực này trên phần cứng thông thường mà không cần chạy TEE.
然而,TEE-Boost存在数据可用性问题:构建者只与提议者共享TEE证明和Khối头,而不共享实际的Khối内容[1] và có thể chọn không phát hành nội dung Khối sau khi người đề xuất ký kết phần đầu (ví dụ, nếu điều kiện thị trường thay đổi không thuận lợi). Các phương pháp đề xuất để giải quyết vấn đề sẵn có dữ liệu này bao gồm:
TEE-Lưu trữ: TEE-Lưu trữ nhận Khối từ người xây dựng trước khi người đề xuất ký và phát hành Khối sau khi nhìn thấy phần đầu ký hiệu.
Lớp sẵn sàng dữ liệu: Trình dựng xuất bản Khối payload của mã hóa lên lớp Data Availability (DA).
Cả hai phương pháp đều có nhược điểm. Giải pháp lưu trữ TEE đã sao chép một cách tương tự với Trễ tập trung hiện có để Chuyển tiếp động[2]. Nếu sử dụng lớp DA bên ngoài thì sẽ đưa ra các giả định giao thức phụ và phải chịu đựng các độ trễ động của giao thức bên ngoài đó (các động tác này cũng có thể không có lợi).
Về lý thuyết, nếu người đề xuất cũng có thể truy cập TEE, người xây dựng có thể mã hóa khối đó vào TEE mà người đề xuất đang chạy. TEE của người đề xuất chỉ được giải mã sau khi được ký. Tuy nhiên, chúng tôi cho rằng TEE-Boost không xem xét thiết kế này vì điều đó sẽ yêu cầu người đề xuất (Người xác thực) chạy TEE. Chúng tôi hy vọng Người xác thực có thể chạy trên phần cứng thông thường.
Nếu người đề xuất tự mình triển khai TEE-Giữ an toàn như là một phần của việc triển khai chung với Người xác thựcNút, thì có thể tránh được việc trễ động
Tuy nhiên, chúng tôi cũng không muốn Người xác thực chạy TEEs. ↩
Mật mã ngưỡng để bảo vệ quyền riêng tư của người xây dựng
Chúng tôi đã đề xuất một giải pháp tinh vi để giải quyết vấn đề khả năng sử dụng dữ liệu của TEE-Boost: mã hóa ngưỡng cho Hội đồng xác minh. Cụ thể, người xây dựng sẽ mã hóa khối thành tỷ lệ xác định của Hội đồng xác minh cho khe thời gian đó. Khi đã thu thập đủ chứng thực, khối có thể được giải mã và sử dụng được.
Công nghệ cho phép cốt lõi là mã hóa im lặng. Kỹ thuật mật mã này [cho phép mã hóa được kiểm soát] (https://eprint.iacr.org/2024/263) mà không cần giai đoạn thiết lập tạo Chìa khoá bảo mật phân tán tương tác (DKG) cần thiết cho bản dựng trước đó. Thay vào đó, Khóa chung công khai được tính toán dựa trên khai BLS hiện có và một số "gợi ý" (thảo luận sau) chắc chắn trong Người xác thực.
Điều này cho phép giao tiếp trực tiếp giữa Builder và Người xác thực, với tính riêng tư mật mã. Người xác thực không cần chạy TEEs hoặc quản lý bất kỳ tài liệu Chìa khoá bảo mật mới nào.
Cơ chế:
Người xây dựng xây dựng một Khối và mã hóa nó cho ủy ban xác thực.
Xây dựng một chứng minh TEE, chứng minh cho ủy ban xác minh ba khía cạnh: đấu giá là trung thực, Khối là hợp lệ và mã hóa là chính xác.
Người xây dựng truyền tải khối đã được mã hóa và chứng thực TEE (bao gồm giá trị đề xuất) cho người đề xuất.[3]
Người đề xuất ký khối mật mã của người xây dựng chiến thắng và tuyên truyền đề xuất đến tập hợp các trình xác thực.
Khi một khối được chứng nhận bởi ủy ban xác minh theo tỷ lệ cụ thể (ví dụ: n / 2 hoặc 2n / 3), nó sẽ được giải mã.
Khối được giải mã sẽ được xác nhận cuối cùng một cách bình thường.
Lưu ý
Hiển thị
Các tính năng hiệu suất của ngưỡng mã hóa vô âm thanh là rất thuận lợi. Ở đây, n là quy mô tối đa của ủy ban mà chúng tôi muốn hỗ trợ, t là ngưỡng giải mã.
Thời gian mã hóa và giải mã một phần đều là thời gian hằng số. Với một cài đặt đơn giản, mã hóa mất ít hơn 7 miligiây và có thể được thực hiện song song. Thời gian giải mã một phần mất ít hơn 1 miligiây.
Bản mã大小比Văn bản thuần túy大768字节,这是一个常量附加因素(对于任何n和t)。
Một phần giải mã tổng hợp (tức là giải mã) phụ thuộc vào kích thước của ủy ban. Khi n=1024, thời gian thực hiện đơn giản là dưới 200 mili giây. Chúng tôi dự đoán rằng khi n=128 (kích thước của ủy ban xác thực cho mỗi khe thời gian), thời gian này sẽ giảm đi 10 lần và triển khai có thể được tối ưu hóa thêm.
Quan trọng là, thời gian mã hóa là chỉ số hiệu suất quan trọng được so sánh với Trễ Chuyển tiếp. Điều này là nội dung phải tính toán trong 'đường dẫn chính' được xây dựng bởi người tạo ra Khối. Thời gian này phải thấp hơn Trễ xử lý Khối Chuyển tiếp hiện tại và tránh giao tiếp nhiều bước.
Phát hành dữ liệu
Cổng im lặng mã hóa không hoàn toàn miễn phí. Nó thực sự cần một chuỗi tham chiếu chung, có dạng: (g, gτ, gτ², …, gτⁿ⁻ᵗ), tương tự như nội dung được sử dụng trong lập trình cam kết đa thức KZG.
Ngoài ra, mỗi Người xác thực có hình thức là g⁽ˢᵏ⁾ BLSKhóa công khai phát hành một tập hợp các phần tử nhóm chúng ta gọi là "gợi ý": (g⁽ˢᵏ⁾⋅τ, …, g⁽ˢᵏ⁾⋅τⁿ⁻ᵗ). Những gợi ý này chỉ cần thiết khi tổng hợp Khóa công khai và giải mã Bản mã. mã hóa chỉ sử dụng kích thước hằng số của tổng hợp Khóa công khai.
截至撰写本文时,大约有100万个Người xác thực。如果我们设置n=128和t=n/2,每个Người xác thực需要发布大约3KB的提示。因此,存储所有Người xác thực的提示需要3GB的空间。
Với việc kích hoạt MaxEB, yêu cầu này có thể sẽ giảm đáng kể. MaxEB cho phép người xác thực kiểm soát số dư lớn hơn 32 ETH trong cùng một khóa bảo mật (thay vì phân tán số dư đó thành nhiều khoản tiền gửi 32 ETH). Việc giảm số lượng người xác thực được thực hiện còn đang được thảo luận. Chúng ta có thể giảm xuống khoảng 1GB.
Cuối cùng, dựa trên sự thay đổi trong tương lai của kiến trúc Ethereum (ví dụ, việc giảm quy mô của Nhận thức chung hoặc thay thế đường ống xác nhận cuối cùng), kích thước gợi ý cần lưu trữ có thể giảm xuống hơn nữa.
Năng lượng
Etherum Mong muốn vẫn duy trì trạng thái trực tuyến trong điều kiện mạng không thuận lợi. Vấn đề của giải pháp này là do ủy ban với tỷ lệ xác định bị mất kết nối, có thể xảy ra vấn đề không thể giải mã được Khối.
Một giải pháp là cho phép người xây dựng quyết định tỷ lệ ủy ban可接受的委员会比例(t)用于解密. Tồn tại sự cân nhắc giữa quyền riêng tư (khả năng giải mã và khả năng đánh cắp MEV) và ngưỡng ủy ban trực tuyến. Đối với người xây dựng, việc khối của họ được bao gồm trong chuỗi thay vì bị fork là tối đa hóa thu nhập, vì vậy họ nên tìm cách thiết lập ngưỡng tối ưu.[4]
Ngoài ra, việc sử dụng sơ đồ mã hóa này phải là tự nguyện. Trong điều kiện mạng bất lợi, nếu không có ủy ban nào có quy mô chấp nhận được có thể duy trì trực tuyến, những người đề xuất và xây dựng có thể quay trở lại sử dụng rơle, tự xây dựng hoặc các cơ chế khác mà họ lựa chọn tùy thuộc vào bản chất của môi trường bất lợi.
Cụ thể, giá trị kỳ vọng của Khối của người xây dựng được fork ra là âm (họ không có thu nhập từ đó), trong khi giá trị kỳ vọng của việc giải nén là rất âm. Nếu cho phép người xây dựng lựa chọn t trong khoảng [0, 128], họ tự nhiên sẽ được khuyến khích chọn một giá trị t đủ cao để giảm thiểu rủi ro của việc Thả giải nén và tăng cơ hội được thỏa mãn (ít nhất tên thành viên hội đồng trực tuyến). Dưới điều kiện mạng bình thường, một số Khối có thể bị fork ra, nhưng chúng tôi nhận thấy điều này đã xảy ra trong trò chơi thời gian, trong khi tính hoạt động của chuỗi vẫn là chấp nhận được.
Khối không khả dụng
Ngoài ra, ủy ban có thể trực tuyến, nhưng người xây dựng có thể tạo ra một tình huống khiến Khối không thể giải mã hoặc vô hiệu hóa khi giải mã (ví dụ, sử dụng chứng chỉ gian lận).
Từ góc độ của giao thức, việc fork ra khỏi các Khối này là hoàn toàn khả thi. Một cách rộng lớn, Người xác thực đơn giản không thể chứng minh được bất kỳ Khối nào thuộc loại Khối này hoặc bất kỳ Khối nào được tham chiếu đến chúng. Phương pháp tốt nhất để xử lý lỗi này có thể là làm cho client Nhận thức chung nhận ra khả năng này và có thể thất bại một cách tinh tế. Cần phải nghiên cứu thêm về vấn đề này.
Cấu trúc thị trường
Người xây dựng chiến thắng biết nội dung của Khối trước khi đạt ngưỡng, điều này có thể tạo ưu thế không công bằng trong giai đoạn tiếp theo. Tuy nhiên, ủy ban chứng minh nên hành động trước khi kết thúc giai đoạn tiếp theo, và hầu hết giá trị của Khối tập trung vào cuối giai đoạn, do đó tác động của ưu thế này nên được giảm thiểu càng nhiều càng tốt.
Bằng chứng mật mã thuần túy
Từ xa, có thể có cơ hội sử dụng Bằng chứng không kiến thức(ZK证明) thay thế cho Chứng minh TEE. Hiện tại, tốc độ của ZK证明 quá chậm, nhưng tiến triển trong mật mã học, phần mềm và phần cứng ASICs có thể cuối cùng làm cho việc tạo ra ZK证明 trong giới hạn Trễ cần thiết trở nên khả thi. Đáng chú ý rằng, cùng với Khối, ZK证明 đã trở thành một phần cốt lõi của ETH坊 dài hạn.
Sử dụng
根据当前的Người xác thực集规模和增长率,这种方案可能不值得在L1上发布所需的数据量。然而,ETH坊已经计划通过MaxEB显著减少Người xác thực数量。
Phương pháp tốt nhất có thể là nâng cấp trước hoặc sau MaxEB để cho phía khách hàng Nhận thức chung nhận thức được khả năng mã hóa Khối và khuyến khích Người xác thực đăng thông báo. Ví dụ, sau MaxEB, có thể yêu cầu Người xác thực mới đăng thông báo, trong khi Người xác thực cũ có thể nhận được khuyến khích nâng cấp.
Một khi đủ số lượng Người xác thực đã chấp nhận cơ chế này, Người xây dựng sẽ bắt đầu sử dụng nó để đảm bảo có đủ quy mô ủy ban (tức là, đảm bảo sự kết hợp giữa quyền riêng tư và khả năng giải mã).
Nếu phương pháp của chúng tôi thực sự vượt trội trong việc Trễ so với việc chuyển tiếp nhiều bước, thị trường có lẽ sẽ tự động áp dụng nó mà không cần sử dụng buộc hoặc quy định cài đặt tham số cụ thể.
Nguyên lý cơ bản
Chuyển tiếp là một trong những nguồn trung tâm quan trọng nhất của Ethereum, dẫn đến cơ hội cho thuê và biến t distort giao thức Phi tập trung địa lý. Chúng ta cần loại bỏ Chuyển tiếp và xem đó là một giải pháp tương đối tinh tế. Nó đòi hỏi thay đổi tầng đồng thuận, nhưng không đòi hỏi Người xác thực cung cấp phần cứng mới hoặc tài liệu Chìa khoá bảo mật mới.
Nhược điểm là đây là một sự thay đổi phức tạp đối với lớp đồng thuận, và cơ chế này (nếu được chọn lựa như đề xuất) có thể được thị trường chấp nhận hoặc không. Tuy nhiên, nhiều thay đổi tiềm năng về đường ống MEV cũng đối mặt với vấn đề chấp nhận và tối ưu hóa lợi nhuận tương tự (ví dụ, bao gồm danh sách). Và trong tương lai, có thể có các trường hợp sử dụng khác phụ thuộc vào cơ sở hạ tầng mã hóa với ngưỡng sở hữu xác thực.
Tuyên bố: