Chủ đề này dành để thảo luận về Đề xuất cải tiến Ethereum (EIP) nhằm bổ sung một mempool mã hóa không phụ thuộc vào lược đồ cho Ethereum (số hiệu đang chờ xử lý). Sau đây là toàn văn:
Tóm tắt
Đề xuất Đề xuất cải tiến Ethereum (EIP) này đưa việc mã hóa mempool vào giao thức. Điều này cho phép người dùng mã hóa các giao dịch của họ cho đến khi chúng được đưa vào một Block, bảo vệ chúng khỏi các cuộc tấn công Chạy trước và sandwiching cũng như tăng cường khả năng chống kiểm duyệt. Thiết kế này không phụ thuộc vào công nghệ mã hóa bằng cách hỗ trợ các nhà cung cấp khóa giải mã tùy ý, chẳng hạn như dựa trên mã hóa Threshold , ủy ban MPC, TEE, mã hóa trì hoãn hoặc các lược đồ FHE. Các giao dịch văn bản gốc truyền thống vẫn được hỗ trợ và quá trình tiến triển của chuỗi được đảm bảo ngay cả khi các nhà cung cấp khóa giải mã gặp sự cố.
Động lực
Mục tiêu của Đề xuất cải tiến Ethereum (EIP) này là ngăn chặn người dùng khỏi các cuộc tấn công sắp xếp lại giao dịch độc hại cũng như tăng cường khả năng chống kiểm duyệt thời gian thực (“yếu”) của giao thức. Nó cũng nhằm mục đích giảm thiểu rủi ro pháp lý đối với những người xây dựng Block và các bên tham gia giao thức khác bằng cách tạm thời che giấu thông tin của họ. Mục tiêu không phải là cải thiện quyền riêng tư của người dùng (ví dụ: tính bảo mật giao dịch) vì các giao dịch cuối cùng sẽ được công khai.
Đề xuất này dựa trên các công trình nghiên cứu trước đó như Shutterized Beacon Chain và một triển khai thực tế, ngoài giao thức, của mempool được mã hóa đã được triển khai trên Gnosis Chuỗi . Nó giải quyết một vấn đề tồn tại lâu nay liên quan đến việc giao Chạy trước) và có tiềm năng giảm thiểu các tác động thứ cấp có hại của MEV, chẳng hạn như sự tập trung hóa của người xây dựng. Thiết kế này cũng phù hợp một cách tự nhiên với sự tách biệt giữa người đề xuất và người xây dựng (ePBS) đã được quy định, khiến nó trở thành một phần mở rộng hợp lý của lộ trình phát triển Ethereum.
Thông số kỹ thuật
Ở lớp thực thi, một hợp đồng được gọi là sổ đăng ký nhà cung cấp khóa được triển khai. Nó cho phép bất kỳ tài khoản nào đăng ký nhà cung cấp khóa và gán cho họ một ID duy nhất. Việc đăng ký yêu cầu chỉ định một hợp đồng với chức năng giải mã và chức năng xác thực khóa, mỗi chức năng đều chấp nhận ID khóa và thông điệp khóa dưới dạng chuỗi byte. Ngoài ra, các nhà cung cấp khóa có thể chỉ định các nhà cung cấp khác là đáng tin cậy trực tiếp, từ đó hình thành một đồ thị tin cậy có hướng. Chúng ta định nghĩa một nhà cung cấp khóa A tin tưởng một nhà cung cấp khóa B nếu và chỉ nếu tồn tại một đường dẫn có hướng từ A đến B trong đồ thị này. Beacon Chain sao chép sổ đăng ký nhà cung cấp khóa ở trạng thái của nó, tương tự như cơ chế xử lý các khoản tiền gửi Beacon Chain .
Giao dịch mã hóa được thêm vào như một loại giao dịch mới. Chúng bao gồm một phong bì và dữ liệu mã hóa. Phong bì chỉ định Nonce của phong bì, lượng gas , các tham số Phí Gas , ID nhà cung cấp khóa, ID khóa và chữ ký của phong bì. Dữ liệu mã hóa chứa Nonce của dữ liệu, giá trị, dữ liệu cuộc gọi và chữ ký của dữ liệu.
Trong một Block hợp lệ, bất kỳ giao dịch nào được mã hóa bằng khóa từ nhà cung cấp khóa A chỉ có thể được bắt đầu bằng
Giao dịch văn bản thuần túy
Các giao dịch được mã hóa bằng khóa từ nhà cung cấp khóa A.
Các giao dịch được mã hóa bằng khóa từ các nhà cung cấp khóa mà A tin tưởng.
Trong mỗi khe thời gian, khi nhà cung cấp khóa quan sát được dữ liệu thực thi do người xây dựng công bố, họ sẽ thu thập các ID khóa được tham chiếu trong các gói tin của tất cả các giao dịch được mã hóa có địa chỉ bằng ID nhà cung cấp khóa của họ. Đối với mỗi ID đó, họ phải công bố khóa giải mã tương ứng hoặc thông báo giữ lại khóa. Thông báo tương ứng tham chiếu đến Hash Block beacon để ngăn chặn việc phát lại trong khe thời gian tiếp theo. Họ có thể thực hiện việc này ngay lập tức khi quan sát được dữ liệu thực thi hoặc trì hoãn việc công bố đến một thời điểm sau đó trong khe thời gian.
Các thành viên của Ủy ban Đảm bảo Tính kịp thời của Tải trọng (PTC) phải lắng nghe các khóa giải mã được tham chiếu bởi tất cả các giao dịch được mã hóa, được xác định bởi các trường ID nhà cung cấp khóa và ID khóa. Họ phải xác thực các khóa này bằng cách sử dụng hàm xác thực được quy định trong hợp đồng đăng ký, sử dụng Gas Limit nhỏ được mã hóa cứng cho mỗi khóa. Cuối cùng, họ phải xác nhận sự hiện diện hoặc vắng mặt của một khóa hợp lệ cho mỗi giao dịch được mã hóa trong thông điệp xác nhận tải trọng, được mở rộng cho mục đích này với một trường bit chuyên dụng.
Trong quá trình xử lý dữ liệu thực thi, sau khi tất cả các giao dịch văn bản gốc hoàn tất, các phong bì của các giao dịch được mã hóa sẽ được thực thi theo lô. Điều này cập nhật số ngẫu nhiên (nonce) của người ký phong bì và thanh toán phí từ tài khoản phong bì. Phí này bao gồm chi phí Block Space được sử dụng bởi phong bì, dữ liệu đã giải mã và khóa giải mã, cũng như chi phí tính toán được sử dụng trong quá trình giải mã và xác thực khóa. Sau đó, dữ liệu được mã hóa sẽ được giải mã bằng khóa được chỉ định bởi ID nhà cung cấp khóa và ID khóa trên phong bì bằng cách sử dụng chức năng giải mã từ sổ đăng ký nhà cung cấp khóa. Nếu quá trình giải mã thành công, các giao dịch dữ liệu kết quả sẽ được thực thi tuân theo Gas Limit được chỉ định trên phong bì cũng như Gas Limit Block . Nếu quá trình giải mã hoặc thực thi thất bại, bao gồm cả trường hợp khóa giải mã được PTC xác nhận là bị thiếu, giao dịch sẽ bị bỏ qua mà không khôi phục phong bì.
Lý do
Đăng ký nhà cung cấp chính
Việc đăng ký không phụ thuộc vào công nghệ mã hóa nào để đảm bảo tính trung lập của giao thức, giảm thiểu rào cản gia nhập cho các nhà cung cấp khóa mới và trao quyền cho người dùng lựa chọn phương án tối ưu nhất cho mục đích của họ. Hợp đồng lớp thực thi được chọn làm cách thức chuẩn để xác định logic thực thi tùy ý. Việc đăng ký hoàn toàn trên CL là một lựa chọn thay thế hợp lý.
Nhiều lược đồ mã hóa không hiệu quả khi thể hiện trong Máy ảo Ethereum (EVM) và do đó sẽ yêu cầu biên dịch trước chuyên dụng. Tuy nhiên, việc bổ sung các biên dịch trước đó nằm ngoài phạm vi của Đề xuất cải tiến Ethereum (EIP) này.
Biểu đồ độ tin cậy của nhà cung cấp chính
Người dùng gửi giao dịch được mã hóa không chỉ phải tin tưởng nhà cung cấp khóa của riêng họ, mà còn phải tin tưởng bất kỳ nhà cung cấp khóa nào được sử dụng cho các giao dịch trước đó trong cùng một Block (xem phần Cân nhắc về Bảo mật). Mặc dù giao thức nên tôn trọng các tùy chọn tin cậy của người dùng, nhưng nếu mỗi người dùng chỉ tin tưởng nhà cung cấp khóa của riêng họ, thì các nhà xây dựng chỉ có thể đưa các giao dịch được mã hóa bằng khóa từ một nhà cung cấp khóa duy nhất vào mỗi Block. Điều này không mong muốn vì nó gây khó khăn cho các nhà cung cấp khóa có thị phần nhỏ trong việc cạnh tranh, dẫn đến nguy cơ tạo ra thế độc quyền cho nhà cung cấp khóa.
Mặt khác, việc yêu cầu người dùng phải nêu rõ họ tin tưởng nhà cung cấp bên thứ ba nào sẽ làm tăng kích thước giao dịch và khiến việc xây dựng Block trở nên khó khăn hơn do số lượng lớn các tùy chọn ưu tiên của người dùng cần được đáp ứng. Để dung hòa, đề xuất này yêu cầu các nhà cung cấp khóa phải đưa ra lựa chọn này. Người dùng ngầm đồng ý bằng cách sử dụng khóa của nhà cung cấp khóa.
Với giải pháp này, ngay cả khi xuất hiện một thế độc quyền gần như hoàn toàn do một nhà cung cấp khóa thống trị duy nhất điều khiển và nhà cung cấp khóa này không chỉ định bất kỳ nhà cung cấp khóa nào khác là đáng tin cậy, các nhà xây dựng vẫn có thể bao gồm các giao dịch sử dụng các nhà cung cấp khóa nhỏ khác mà không phải chịu chi phí cơ hội, miễn là các nhà cung cấp khóa nhỏ tin tưởng nhà cung cấp khóa chính (và có thể tin tưởng lẫn nhau).
Lệnh giao dịch
Đề xuất này chia các khối thành hai phần: phần giao dịch văn bản gốc và phần giao dịch được mã hóa. Các giao dịch văn bản gốc được đặt trước, cho phép người xây dựng khối mô phỏng đầy đủ quá trình thực thi trong phần này và áp dụng các kỹ thuật xây dựng Block hiện có cũng như các chiến lược trích xuất MEV. Do đó, người xây dựng có thể thêm các giao dịch được mã hóa vào cuối Block mà không mất chi phí cơ hội. Nếu thứ tự bị đảo ngược, phí cho các giao dịch được mã hóa sẽ phải cao hơn đáng kể để các khối có chứa chúng có thể cạnh tranh trong các cuộc đấu giá PBS so với các khối chỉ có giao dịch văn bản gốc.
Thực thi giao dịch
Cả giao thức và người xây dựng khối đều phải được bảo vệ khỏi việc đưa vào các giao dịch mã hóa dẫn đến việc không thể thanh toán phí gas. Để đảm bảo điều này xảy ra bất kể nội dung của bất kỳ tải trọng mã hóa nào trong Block, việc thanh toán phí là một phần của phong bì văn bản gốc và tất cả các phong bì trong một Block đều được thực thi trước bất kỳ tải trọng mã hóa nào. Phí gas không được hoàn trả để đảm bảo số tiền phí mà người xây dựng và giao thức sẽ nhận được tại thời điểm xây dựng Block .
Để đơn giản, dữ liệu được mã hóa chứa chữ ký. Một phương án ít riêng tư hơn nhưng hiệu quả hơn là coi người ký trên phong bì là người gửi.
Giữ lại khóa giải mã
Giao thức này cho phép các nhà cung cấp khóa giải mã giữ lại khóa giải mã theo các điều kiện do họ lựa chọn. Điều này cho phép họ triển khai một cách an toàn các quy tắc để hạn chế người dùng nào được phép sử dụng khóa nào, ví dụ: dựa trên các khoản thanh toán trước đó và để ngăn chặn các cuộc tấn công Chạy trước đoạt ID khóa (xem phần Cân nhắc về Bảo mật). Mặt khác, các khóa bị giữ lại một cách bất hợp lý có thể được sử dụng trong các cơ chế Slashing tùy chỉnh và các chỉ số độ tin cậy (lưu ý rằng giao thức ghi lại những khóa nào hiện có, những khóa nào đã có và những khóa nào chưa có).
Thiếu các ưu đãi dành cho nhà cung cấp khóa trong giao thức
Đề xuất này không quy định cơ chế phí cho các nhà cung cấp khóa, cũng như không có hình phạt nào cho hành vi sai trái. Điều này cho phép triển khai nhiều mô hình khuyến khích khác nhau Ngoài chuỗi. Ví dụ, các nhà cung cấp khóa có thể ký kết thỏa thuận với các nhà xây dựng, được người dùng trả tiền theo từng giao dịch hoặc hoạt động như hàng hóa công cộng. Họ cũng có thể tự đặt ra các điều kiện Slashing đối với việc giữ lại khóa một cách vô lý để làm cho dịch vụ của họ hấp dẫn hơn đối với người dùng.
Mã hóa dữ liệu thực thi
Một đề xuất cải tiến Đề xuất cải tiến Ethereum (EIP) trong tương lai có thể cho phép người xây dựng sử dụng các khóa từ nhà cung cấp khóa để mã hóa dữ liệu thực thi. Điều này cho phép họ công bố dữ liệu thực thi ngay sau khi xây dựng xong, thay vì chỉ công bố khi đạt mốc 50%. Điều này sẽ tăng hiệu quả giữa các máy ảo (p2p) và bảo vệ người xây dựng khỏi việc bỏ lỡ các khe thời gian do sự cố. Ngoài ra, nếu người xây dựng đính kèm bằng Zero Knowledge Proof về các khóa đã được sử dụng trong một Block, cửa sổ thời gian tiết lộ khóa có thể bắt đầu sớm hơn và do đó dài hơn. Tính năng này không được bao gồm trong Đề xuất cải tiến Ethereum (EIP) hiện tại để giảm thiểu độ phức tạp.
Khả năng tương thích ngược
Đề xuất này thực hiện những thay đổi không tương thích ngược đối với giao thức ở lớp thực thi và lớp Consensus .
Các vấn đề liên quan đến an ninh
Các nhà cung cấp khóa đáng tin cậy
Người dùng nhất thiết phải tin tưởng các nhà cung cấp khóa mà họ sử dụng để mã hóa các giao dịch của mình.
Không nên công bố sớm các khóa giải mã vì điều đó sẽ tạo điều kiện cho các cuộc tấn công "Chạy trước" và "sandwiching".
Không nên phát hành khóa giải mã quá muộn vì điều đó sẽ ngăn cản việc thực hiện giao dịch trong khi phí phong bì vẫn chưa được thanh toán.
Các nhà cung cấp khóa có thể giành được sự tin tưởng này thông qua các cơ chế mật mã (ví dụ: mã hóa Threshold , mã hóa phần cứng), các cơ chế kinh tế (ví dụ: Slashing đối với hành vi sai trái), các cơ chế quản trị (ví dụ: bỏ phiếu để chọn các thực thể có uy tín xã hội) hoặc sự kết hợp của các cơ chế này.
Ở mức độ thấp hơn, người dùng cần tin tưởng tất cả các nhà cung cấp khóa được sử dụng cho các giao dịch được mã hóa trước giao dịch của họ trong một Block. Điều này là do các nhà cung cấp khóa có tùy chọn công bố hoặc giữ lại các khóa giải mã mà họ có thể lấy sau khi quan sát các khóa giải mã cho các giao dịch tiếp theo. Tùy chọn này cho phép họ có một Bit ảnh hưởng đến trạng thái ban đầu của các giao dịch sau đó. Các phương án "giải mã" được lựa chọn một cách độc hại có thể làm cho cuộc tấn công này mạnh hơn nhiều bằng cách cho phép sửa đổi trực tiếp các phần cụ thể của kết quả giải mã bằng cách sử dụng các khóa giải mã được tạo sẵn hoặc thiết lập hoàn toàn. Điều này thực chất cho phép tấn Chạy trước" ( tấn công trước).
Người dùng không cần phải tin tưởng bất kỳ nhà cung cấp khóa nào được sử dụng cho các giao dịch được thực hiện sau giao dịch của họ vì trạng thái ban đầu của dữ liệu giao dịch của người dùng không bị ảnh hưởng bởi dữ liệu của các giao dịch sau đó (chỉ có phần bao bì của chúng bị ảnh hưởng, nhưng phần bao bì này được chọn trước khi bất kỳ khóa giải mã nào được công bố). Tương tự, người dùng của các giao dịch văn bản thuần túy không cần phải tin tưởng bất kỳ nhà cung cấp khóa nào (nhưng họ vẫn phải tin tưởng những người tạo ra chúng).
Tái cấu trúc
Các khóa giải mã được công bố trước khi các giao dịch được mã hóa tương ứng được hoàn tất. Do đó, trong trường hợp tái cấu trúc chuỗi , một giao dịch có thể trở nên công khai ngay cả khi nó không nhất thiết phải được bao gồm trong chuỗi . Tuy nhiên, vì thông điệp khóa giải mã bao gồm cả Hash Block , nên nó có thể bị vô hiệu hóa bởi chức năng xác thực khóa. Điều này không ngăn cản việc bao gồm giao dịch bao bọc, nhưng ngăn cản việc thực thi và do đó, ngăn chặn Chạy trước tải trọng.
ID chính Chạy Chạy trước
Khi người dùng mã hóa một giao dịch bằng một ID khóa cụ thể, người dùng khác có thể quan sát giao dịch này đang diễn ra và tạo một giao dịch được mã hóa khác chỉ định cùng nhà cung cấp khóa và ID khóa đó. Nếu giao dịch thứ hai được đưa vào một Block trước giao dịch gốc, một nhà cung cấp khóa thiếu kinh nghiệm sẽ tiết lộ khóa và do đó cả giao dịch gốc, ngay cả khi nó chưa được đưa vào.
Các nhà cung cấp khóa có thể bảo vệ người dùng của họ khỏi cuộc tấn công này. Một chiến lược khả thi để làm điều đó là "phân vùng tên" cho ID khóa: Các nhà cung cấp chỉ phát hành khóa cho các ID khóa được đặt tiền tố bằng địa chỉ của người ký phong bì và giữ lại tất cả các ID khác. Vì chúng ta có thể giả định một cách hợp lý rằng kẻ tấn công không có quyền truy cập vào tài khoản của người ký phong bì, nên kẻ tấn công sẽ không thể tạo ra một giao dịch với ID khóa được phân vùng tên chính xác.
Sự thông đồng giữa nhà cung cấp chính và nhà xây dựng trẻ em
Để xây dựng một Block mới, người xây dựng cần biết trạng thái sau khi Block trước đó, tức là tất cả các khóa giải mã được sử dụng trong Block và khóa nào đang bị giữ lại. Thông tin này được công khai sau khi PTC xác nhận. Tuy nhiên, các nhà cung cấp khóa độc hại có thể thông đồng với người xây dựng Block và cung cấp cho họ thông tin sớm hơn. Điều này sẽ mang lại cho người xây dựng lợi thế cạnh tranh vì họ có thể bắt đầu quá trình xây dựng Block sớm hơn.
Tác động của cuộc tấn công được đánh giá là thấp vì khoảng thời gian giữa việc công bố các chứng thực tải trọng và kết thúc khe thời gian vẫn đủ dài để xây dựng Block . Hơn nữa, thời điểm bắt đầu giai đoạn xây dựng Block ít quan trọng hơn nhiều so với thời điểm kết thúc (vì chỉ khi đó mới biết được toàn bộ tập hợp các giao dịch có thể bao gồm), và giai đoạn này không bị ảnh hưởng bởi cuộc tấn công. Ngoài ra, việc trì hoãn việc phát hành các khóa giải mã tiềm ẩn rủi ro chúng không được PTC chứng thực, làm mất đi lợi thế cạnh tranh của kẻ tấn công. Và cuối cùng, nếu số lượng giao dịch được mã hóa sử dụng nhà cung cấp khóa độc hại là nhỏ, thì tác động của chúng đến trạng thái cây cũng có khả năng nhỏ. Điều này có nghĩa là các chiến lược xây dựng Block quan không dựa vào việc biết đầy đủ về cây trạng thái có thể khả thi, giúp chống lại cuộc tấn công.
