Tìm hiểu nhóm bộ nhớ được mã hóa: Không gian thiết kế mới để giải quyết các vấn đề về MEV và kiểm duyệt

Tiêu đề gốc: "Tìm hiểu về nhóm bộ nhớ được mã hóa: Không gian thiết kế mới để giải quyết các vấn đề về MEV và kiểm duyệt"

Tác giả gốc: Jon Charbonneau

Trình biên dịch gốc: 0x11, Tin tức tầm nhìn xa

Nhóm bộ nhớ được mã hóa là một công cụ mạnh mẽ để giải quyết các vấn đề về MEV và kiểm duyệt. Hiện tại có nhiều giải pháp liên quan có thể được sử dụng riêng lẻ và chúng cũng có thể được sử dụng kết hợp.

Bài viết này cung cấp cái nhìn tổng quan về bài nói chuyện của Justin Drake về chủ đề này (Columbia, Amsterdam and  Flashbots Roast). Hầu hết các bạn có thể thấy khó hiểu khi xem lần đầu, vì vậy tôi đã cố gắng chia nhỏ và mở rộng nó một cách đơn giản.

Ý tưởng cơ bản: Cho phép người dùng gửi các giao dịch được mã hóa và nhà sản xuất khối có thể gửi các giao dịch này để giải mã chúng:

Người dùng mã hóa và truyền phát giao dịch

Giao dịch được mã hóa đã gửi

Giao dịch được giải mã

Thực hiện giao dịch (lưu ý: việc gửi, giải mã và thực thi có thể ở một vị trí duy nhất)

Hai vấn đề có vẻ dễ dàng được giải quyết:

MEV : Tôi không thể thực hiện trước một giao dịch nếu tôi không thể nhìn thấy nó

Đánh giá: Tôi không thể xem lại giao dịch trừ khi tất cả các giao dịch tiền điện tử đều bị loại trừ (nếu nhiều giao dịch là tiền điện tử, Chi phí có thể rất đắt)

Điểm mấu chốt cần đảm bảo ở đây là việc đảm bảo Giải mã không phụ thuộc vào người dùng. Có một số cách để đạt được điều này:

1 .Trong chuyến bay

Tin tưởng một bên thứ ba và gửi dữ liệu riêng tư cho bên đó. Bên này có thể giải mã và xem dữ liệu nhưng hứa sẽ không làm như vậy trước khi dữ liệu được gửi vào chuỗi sẽ được tiết lộ công khai. Đây là cách các sản phẩm như Flashbots Protect hoạt động.

2. Phần cứng đáng tin cậy

Bạn có thể tận dụng phần cứng đáng tin cậy. Bản rõ có thể chạy trong phần cứng đáng tin cậy nhưng không được giải mã công khai cho đến khi giao dịch được gửi. Ví dụ nổi tiếng nhất là Flashbots SUAVE SGX.

3. Mã hóa/Giải mã ngưỡng (TED)

Một ủy ban có thể hợp lực để buộc giải mã bản mã nhưng yêu cầu người ký phải đáp ứng một ngưỡng để thực hiện việc này. Ví dụ: "ngưỡng" của bạn có thể là 2/3 số người xác thực đồng ý giải mã. TED đã tiến hành nghiên cứu ở nhiều lĩnh vực khác nhau, bao gồm:

Ethereum L1 - Chuỗi đèn hiệu được đóng cửa

Mạng Shutter ——Ethereum L2 s

Arbitrum—— FSS của Chainlink

Thẩm thấu & dị thường—— Ferveo

Chuỗi đèn hiệu Shutterized

Hãy xem xét kỹ đề xuất Chuỗi đèn hiệu Shutterized, Tập hợp con ("người khóa") của người xác thực tạo các cặp khóa công khai/riêng bằng cách sử dụng Trình tạo khóa phân tán (DKG). Mọi người đều có thể nhìn thấy khóa chung, nhưng khóa riêng được chia cho ủy ban để giữ an toàn. Việc xây dựng lại khóa riêng tư và giải mã yêu cầu các chia sẻ khóa phải đạt đến một ngưỡng nhất định (ví dụ:  2/3 ).  

Người dùng có thể tùy ý mã hóa các giao dịch được đưa vào chuỗi trước khi nội dung của chúng được giải mã và thực thi. Các nhà sản xuất khối tạo các khối bằng cách sử dụng các giao dịch văn bản gốc (được thực hiện ngay lập tức) và các giao dịch được mã hóa (được lên lịch cho chiều cao khối trong tương lai).  

Sau khi tạo và chứng minh khối n -1, người tạo khóa sẽ tạo và công bố khóa giải mã cho khối n. Khóa này có thể giải mã các giao dịch trong khối n. Khối n phải chứa khóa giải mã mới được coi là hợp lệ. Trạng thái sau của một khối được tính bằng cách thực hiện các giao dịch mật mã trong khối (theo thứ tự chúng được đặt) trước khi thực hiện các giao dịch văn bản gốc trong khối.

Nhược điểm

TED có một số nhược điểm:

Thiếu trách nhiệm giải trình: Không giống như các giả định về bảo mật truyền thống, ở đây hành vi độc hại không được quy cho hoặc có thể báo cáo. Người khóa có thể giải mã ngay lập tức và bạn không thể quy kết nó. Ngay cả khi bạn cho rằng người xác thực hoạt động theo cách tương thích với khuyến khích, thì các cơ quan gồm ba chữ cái bên ngoài nhóm người xác nhận cũng có thể gây ảnh hưởng lên họ.  

Giả định trung thực của đa số: Các ủy ban không trung thực có thể gây ra vấn đề, chẳng hạn như chọn không bao giờ giải mã một số tin nhắn nhất định hoặc bí mật giải mã những tin nhắn mà họ không nên giải mã. (Ví dụ: , theo yêu cầu của cơ quan nhà nước hoặc thực hiện việc khai thác MEV một cách ích kỷ). Trong hầu hết các trường hợp, blockchain thực sự dựa vào đa số hợp lý về mặt kinh tế (tức là hình phạt cắt giảm thường lớn hơn các khuyến khích kinh tế đối với hành vi như chi tiêu gấp đôi độc hại). Với mã hóa ngưỡng, giả định này được chuyển sang đa số thực sự trung thực và vị tha.

Phá hoại tính ổn định của giao thức: Về cơ bản là sự kết hợp của hai điểm trên, TED tăng thêm động lực cho những người xác thực làm điều ác và ít có khả năng bị trừng phạt hơn.

Giảm hoạt động: ngưỡng giải mã cao hơn giúp tăng cường bảo mật giao thức). Tuy nhiên, điều này trực tiếp làm giảm hoạt động. Ví dụ: sự cố ngừng hoạt động mạng lớn làm mất đi một nửa số trình xác thực giờ đây có thể khiến giao thức dừng lại. Đặc biệt đối với Ethereum, nơi tập trung nhiều vào hoạt động “Thế chiến III”, đây là một sự đánh đổi không thể chấp nhận được.  

Trải nghiệm người dùng kém: TED có thể tăng thêm mức độ trễ và chi phí khác nhau tùy thuộc vào chi tiết triển khai.

Phân bổ giá trị dưới mức tối ưu: Hãy xem một ví dụ đơn giản về tiền tuyến:

1 ETH giá là $1000 

Nếu tôi gửi giao dịch đến vanilla mempool - tôi nhận được $990 (người tìm kiếm chạy trước và chạy lùi, kiếm được $10 ròng)

Nếu tôi gửi giao dịch đến nhóm TED - tôi nhận được 995 USD (người tìm kiếm không thể chạy trước nhưng tôi đẩy giá giao ngay tại địa phương , tạo cơ hội chênh lệch giá 5 USD cho người tìm kiếm)

Tôi gửi giao dịch tới Đấu giá luồng đơn hàng tốt nhất - Tôi đã nhận được $1000 (Tôi không nhận được lượt chạy trước hoặc lượt chạy lùi. Hoặc tương tự, tôi nhận được lượt chạy trước và/hoặc lượt chạy lùi. , nhưng người tìm kiếm phải trả giá 10 USD trong một cuộc đấu giá cạnh tranh để có quyền làm như vậy và kết quả cuối cùng là như nhau.)

Trong trường hợp này, bạn để tiền trên bàn cho người khác lấy. Người dùng hợp lý về mặt kinh tế nên tiết lộ đủ thông tin đơn hàng để họ có thể được bồi thường gần bằng toàn bộ giá trị của đơn hàng. Họ không nên mã hóa ngưỡng giao dịch của mình một cách ngây thơ, che giấu giá trị mà nó cung cấp (cho phép người khác nắm bắt nó).  

Đây là một ví dụ siêu lý tưởng, nhưng bạn thấy đấy, việc che đậy một vấn đề không phải lúc nào cũng giải quyết được nó. TED có thể là một công cụ hữu ích nhưng nó không phải là liều thuốc chữa bách bệnh cho MEV. Trong một số trường hợp, CR được cho là tốt hơn.  

Ngoài ra, Ethereum còn mang đến sự phức tạp hơn nữa. Ví dụ: nó thiếu tính hữu hạn ngay lập tức (mặc dù điều này một ngày nào đó có thể thay đổi với tính hữu hạn của một khe) được giới thiệu Các vấn đề xung quanh việc tái cơ cấu. Tôi tin rằng ít nhất là trong L1 của Ethereum, sự đánh đổi ở đây lớn hơn những bất lợi. Việc tăng các giả định về niềm tin của Ethereum, tăng động cơ thông đồng (không bị phát hiện) và giảm tính tồn tại của nó có thể gây hại nhiều hơn là có lợi.  

Tuy nhiên, một số sự đánh đổi này có thể được chấp nhận hơn đối với L2 hoặc các L1 khác so với Ethereum L1.  

4. Mã hóa/giải mã bị trì hoãn (DED)

Sử dụng mã hóa bị trì hoãn, bạn Thông tin được mã hóa có thể được thiết lập để tự động giải mã sau một khoảng thời gian nhất định, đây là phép tính tuần tự liên quan đến VDF.

Để thực sự triển khai DED, bạn cần có VDF ASIC. May mắn thay, Ethereum Foundation và Protocol Labs đã và đang nỗ lực xây dựng chúng và gần đây đã thu được các mẫu thử nghiệm đầu tiên của con chip do GlobalFoundries chế tạo. Những người đánh giá VDF này sẽ có thể thực hiện các phép tính tuần tự cực nhanh. Các ASIC VDF này cũng thích hợp cho các câu đố có khóa thời gian và DED.  

VDF cũng cần tạo SNARK. Điều này có thể được thực hiện bằng cách sử dụng GPU, nhưng lý tưởng nhất là Ethereum Foundation cũng muốn sản xuất các ASIC có liên quan cho SNARK.  

Nói chung, bạn không còn tin tưởng vào một ủy ban nữa, vì vậy các giả định an toàn thường được ưu tiên hơn. Tuy nhiên, yêu cầu phần cứng chuyên dụng là không lý tưởng và độ trễ cần thiết cũng có thể làm tăng độ trễ của hệ thống. Điều thú vị là bạn có thể kết hợp các ưu điểm của TED + DED...

5. Mã hóa/Giải mã Witness (WED)

WED rất Mạnh mẽ nhưng đừng quá phấn khích quá sớm, nó sẽ không đến sớm đâu. Đây là thứ rất kỳ lạ và sẽ phải mất nhiều năm mới đạt được. Nhưng nó rất hay và hữu ích để hiểu nên tôi sẽ trình bày ngắn gọn về nó.  

WED cho phép bất kỳ nhân chứng nào có thể cưỡng bức giải mã văn bản mật mã. Ví dụ: quy tắc của bạn có thể là "Chỉ giải mã sau khi Ethereum hoàn thành khối chứa tải trọng được mã hóa" và chỉ giải mã nếu điều này được chứng minh. Bạn có thể tưởng tượng rằng về cơ bản, bất kỳ câu lệnh phức tạp nào bạn muốn triển khai đều sẽ yêu cầu SNARK.

WED thực chất là sự khái quát hóa của TED hoặc DED. Bạn thậm chí có thể xây dựng một sự kết hợp của cả hai. Ví dụ: một nhân chứng được chỉ định có thể chứng nhận:

Kết quả tốt đẹp: Ủy ban Ngưỡng đã phê duyệt việc giải mật, hoặc 

Kịch bản chuẩn bị: Thời gian yêu cầu đã trôi qua, quay trở lại quá trình giải mã bị trì hoãn

Điều này cung cấp một điều khoản trong trường hợp ủy ban ngưỡng không phản hồi . Điều này cũng cho phép bạn thận trọng hơn trong việc tham số hóa các giả định ngưỡng m/n (tức là bạn có thể yêu cầu mọi thành viên ủy ban hoặc gần như tất cả các thành viên phê duyệt).

Kết quả đáng mừng: Trải nghiệm người dùng tốt nhất, được toàn thể ủy ban xác nhận ngay lập tức 

Kịch bản chuẩn bị : Độ trễ và trải nghiệm người dùng tạm thời bị ảnh hưởng nhưng tính sống động được giữ nguyên

Trên thực tế, WED có thể sẽ xác minh SNARK theo bất kỳ khiếu nại nào bạn muốn. Ví dụ: 

TED: Bạn có thể có SNARK để chứng minh "Tôi có m chữ ký trong số n chữ ký" để buộc giải mã.

DED: Bạn có thể sử dụng VDF và thực hiện các phép tính tuần tự (rất tốn kém). Sau đó, khi kết thúc tính toán, bạn có một bằng chứng ngắn gọn. Sau đó, bạn lấy bằng chứng ngắn đó và bọc nó trong SNARK (làm cho nó thậm chí còn ngắn hơn) và nhập nó để buộc giải mã.

Đồng hình

Mọi sơ đồ mã hóa ở đây (ngưỡng, độ trễ và bằng chứng), bạn có thể có sự đồng hình. Nghĩa là, bạn có thể tạo ngưỡng FHE , FHE bị trì hoãn và chứng kiến sơ đồ FHE để thực hiện các phép toán tùy ý trên bản mã.

Các giải pháp phần cứng trên máy bay và đáng tin cậy (ví dụ: SGX) cũng có thể mô phỏng chức năng tương tự - hoạt động trên dữ liệu riêng tư. Điều này là do trong cả hai trường hợp, bên thứ ba hoặc phần cứng đáng tin cậy đều có quyền truy cập vào chính bản rõ để hoạt động. Tuy nhiên, lý tưởng nhất là chúng tôi muốn loại bỏ những giả định về độ tin cậy này và chỉ dựa vào mật mã cứng.

Chúng ta có thể tưởng tượng một ví dụ:

m 1 = Giao dịch 1 

m 2 = Giao dịch 2 

f(x) = xây dựng một khối 

Sau đó, tất cả năm giải pháp có thể được sao chép. Các tính năng sau:  

Khi chúng tôi xem xét cách ẩn siêu dữ liệu và cách sử dụng giao dịch, hãy giữ khả năng này cần lưu ý khi xây dựng khối tốt nhất từ đầu vào mật mã. Về lý thuyết, mỗi phương án trong số 5 phương án ở đây đều có thể được sử dụng cho các giải pháp sau yêu cầu "đồng cấu".  

Siêu dữ liệu

Siêu dữ liệu là dữ liệu cung cấp thông tin về các dữ liệu khác. Tuy nhiên, nội dung của dữ liệu này (chẳng hạn như văn bản của tin nhắn hoặc chính hình ảnh) không được cung cấp. Vì mục đích của chúng tôi, siêu dữ liệu giao dịch có thể bao gồm địa chỉ IP của người gửi, số nonce, thanh toán gas, v.v.

Lý tưởng nhất là chúng tôi muốn ẩn càng nhiều siêu dữ liệu càng tốt. Nếu không, nó có thể rò rỉ thông tin cho phép người ngoài suy ra các giao dịch của bạn (có thể cung cấp cho họ đủ thông tin để cố gắng chạy trước hoặc kiểm duyệt, v.v.). Tuy nhiên, chúng tôi cần siêu dữ liệu để xác minh rằng giao dịch là hợp lệ, các khoản phí cần thiết đã được thanh toán hay đó là thư rác, v.v.

Hãy xem xét một số giải pháp để che giấu nhiều siêu dữ liệu khác nhau.

1. Địa chỉ IP - Tor

Rất đơn giản - người ta có thể sử dụng thứ gì đó như dịch vụ Tor để phát sóng riêng tư và chặn địa chỉ IP của họ.

2. Signature-SNARK

Bạn cần biết ở cấp độ p2p rằng các giao dịch tiền điện tử là hợp lệ, đặc biệt nếu nó có chữ ký hợp lệ. Chúng ta có thể sử dụng SNARK để chứng minh rằng chữ ký là hợp lệ, chữ ký này sẽ đi kèm với mọi giao dịch mật mã. SNARK chứa ba phần quan trọng:

Người dùng muốn chứng minh rằng bản mã giao dịch của mình là hợp lệ, nó tương ứng với bản rõ giao dịch và chữ ký của nó là hợp lệ. Để chứng minh rằng bất kỳ chữ ký nào là hợp lệ, bạn cần có khóa chung được liên kết với tài khoản để xác minh nó.

Tìm trạng thái gốc của Ethereum (công khai).

Cung cấp bằng chứng Merkle khóa công khai (riêng tư) của người gửi tương ứng với gốc trạng thái này

To xác minh chữ ký, bạn cần xác minh khóa chung của người gửi dựa trên bằng chứng Merkle gốc của tiểu bang. Sử dụng SNARK để chứng minh rằng bằng chứng Merkle khóa công khai của người gửi là hợp lệ và chữ ký của bạn cũng hợp lệ.

3. Thanh toán gas - SNARK

Bạn cần chứng minh rằng người gửi giao dịch được mã hóa có đủ ETH phải trả khoản phí này. Chúng ta có thể sử dụng lại SNARK.  

Đây là một quy trình tương tự, nhưng bây giờ bạn cung cấp đường dẫn Merkle tới thư mục gốc trạng thái, chứng minh số dư của người gửi (thay vì khóa chung của người gửi) . Bạn xác thực đường dẫn Merkle và xác minh rằng số dư đủ để trang trải lượng khí cần thiết.

Chỉ lượng gas tối thiểu cần thiết để thực hiện các hoạt động cơ bản như giải tuần tự hóa một giao dịch, kiểm tra số dư và kiểm tra chữ ký. Bạn có thể chỉ định rằng người gửi phải luôn thanh toán số tiền tối thiểu này.  

Nhưng xét về thời gian thực hiện, bạn cũng cần phải có Gas limit của chính giao dịch thực tế, Gas limit này cũng có thể được mã hóa. Vì vậy, khi bạn thực sự thực hiện giao dịch, bạn sẽ kiểm tra xem người gửi có đủ số dư để chi trả toàn bộ chi phí cho giao dịch tại thời điểm đó hay không:

Nếu vậy : thực hiện giao dịch Và hoàn lại tiền khi kết thúc

Nếu không: hủy giao dịch, người gửi chỉ cần thanh toán 21.000 Gas

4. Người gửi và nonce - SNARK

Nonce là giá trị bằng số lượng giao dịch được gửi từ một địa chỉ ( hoặc hợp đồng được tạo theo số lượng tài khoản). Số nonce của người dùng được tăng thêm 1 cho mỗi giao dịch bắt đầu từ địa chỉ của họ.  

Một trong những lý do khiến chúng tôi gặp nonces ngày hôm nay là người dùng không thể spam mempool (tấn công DoS) với số lượng lớn giao dịch nhằm tăng số lần thực thi về khả năng giao dịch của họ. Các nút sẽ chỉ xem xét một giao dịch không có giao dịch đó và loại bỏ các giao dịch khác.  

Đối với các giao dịch tiền điện tử, bạn sẽ SNARK để chứng minh rằng nonce là nonce trước đó + 1  Tuy nhiên, cuộc tấn công DoS được mô tả ở trên có thể gây ra những tác động bất lợi nếu các nút không còn có thể nhận biết rằng nhiều giao dịch tiền điện tử có cùng một lần mở.

Để duy trì đặc tính chống DoS này, chúng tôi muốn thêm "thẻ phát lại". Nó gắn thẻ duy nhất cho các giao dịch để bạn không còn có thể spam một số lượng lớn giao dịch đến một địa chỉ nữa. Để tạo thẻ này bạn chỉ cần băm (số ngẫu nhiên, khóa riêng). Vì khóa nonce và khóa riêng đều cố định nên nếu người dùng cố gắng gửi cả hai bằng cách sử dụng cùng một khóa nonce và khóa riêng thì các giao dịch khác nhau sẽ có cùng một thẻ phát lại.

Cuối cùng, bạn có thể muốn duy trì mức độ linh hoạt nhất định. Giả sử giá gas đã thay đổi, bạn sẽ muốn phát lại giao dịch ở mức giá cao hơn một cách hợp lý. Để giảm thiểu điều này, bạn có thể băm (nonce, khóa riêng, vị trí). Giờ đây, bạn có thể điều chỉnh các giao dịch của mình một lần cho mỗi vị trí và chỉ có thể gửi một giao dịch cho mỗi vị trí trên mỗi địa chỉ.   

5. Kích thước dữ liệu - đồng hình

Mã hóa bản rõ có kích thước n sẽ tạo ra bản mã có kích thước n. Ngay cả kích thước này cũng đủ để tính toán một số giao dịch nhất định theo xác suất. Chúng ta có thể giảm bớt vấn đề này bằng cách "đệm" - thêm số 0 vào bản rõ trước khi mã hóa, mở rộng số bit lên lũy thừa tiếp theo là 2 (ví dụ: thêm ba số 0 vào bản mã 5 bit).  

Trong ví dụ sau:

Trắng = chứa 0 

Các màu khác = dữ liệu giao dịch thực tế

Khi bạn xây dựng khối, bạn có thể nối các bản mã này, nhưng điều này có hai vấn đề:

Việc đóng gói không hoàn hảo - thêm A 0 có nghĩa là bạn phải trả tiền để có thêm dữ liệu sẵn có

Quyền riêng tư không hoàn hảo - có thể lũy thừa 2 sẽ cung cấp đủ thông tin. Sự phân bổ quy mô giao dịch không rõ ràng, vì vậy một số quy mô nhất định vẫn có thể tiết lộ đủ thông tin.

Giải pháp tốt hơn là "cắt bỏ" phần đệm: 

Thay đổi từng giao dịch được đệm đến kích thước tối đa (16 ở đây) và được mã hóa đồng cấu

Áp dụng một hàm trên bản mã để đóng gói bản rõ một cách hiệu quả, loại bỏ phần đệm cần thiết

Bây giờ bạn sẽ có được gói tốt nhất.

Bằng cách đệm đến kích thước "tối đa", điều này thực sự làm giảm giá trị tối đa Đặt thành giá trị mà giới hạn kích thước khối thực tế chuyển thành (tức là nếu Gas 30mm chuyển thành xấp xỉ x kB). Điều này có nghĩa là đệm mỗi giao dịch ở kích thước x kB. Ngoài ra, nếu giả sử 99,9% giao dịch thường nằm trong phạm vi y kB, bạn có thể đặt kích thước y kB nhỏ hơn, thực tế hơn.

Tương tự, việc "cắt" này có thể được mô phỏng bằng phần cứng đáng tin cậy thay vì FHE đã thảo luận trước đó. Ví dụ: bạn có thể chạy SGX và nhận các giao dịch tiền điện tử vào vùng đáng tin cậy của mình. Trong một vùng kín, dữ liệu có thể được xử lý bằng văn bản gốc để cắt bớt phần đệm không cần thiết để đóng gói các khối dày đặc. Dữ liệu sau đó được mã hóa và gửi trở lại, theo sau là phương pháp giải mã bắt buộc (ngưỡng, độ trễ, bằng chứng).  

Lưu ý rằng trong cả hai trường hợp, đầu ra phải có kích thước cố định, do đó bạn có thể chỉ còn lại một lượng đệm nhỏ.  

Lựa chọn gói giao dịch: danh sách truy cập trạng thái đồng hình và rời rạc

Giả định Chúng tôi giải quyết tất cả các vấn đề trên và các nhà sản xuất khối có thể đóng gói mọi thứ vào một khối một cách tối ưu dựa trên kích thước. Nhưng chúng tôi có một câu hỏi khác - liệu các nhà sản xuất khối có thể đóng gói mọi thứ một cách tối ưu về mặt kinh tế không? Chúng tôi muốn phân cấp các khối xây dựng mà không làm mất đi giá trị. Nếu không, nó không thể cạnh tranh với các thực thể tập trung.

Giải pháp 1 - FHE EVM

Câu trả lời thẳng thắn: Chạy EVM hoàn toàn trong FHE . Điều này sẽ cho phép xây dựng phi tập trung các khối tối ưu để thu được giá trị tối đa cho các nhà sản xuất khối. Họ lựa chọn và sắp xếp các giao dịch để tối đa hóa giá trị.  

Thật không may, đây không phải là vấn đề đơn giản. Chi phí lớn nhất của mạch FHE là "độ sâu" của nó (tức là số lượng cổng trong đường dẫn dài nhất). Đặc biệt, độ sâu nhân của nó là rất quan trọng. Ví dụ: giao dịch "cắt tỉa" được mô tả trước đây để loại bỏ phần đệm là một mạch khá "nông" (nghĩa là nó rất đơn giản). Với khả năng tăng tốc phần cứng, các trường hợp sử dụng như vậy có thể trở nên khả thi về mặt tính toán trong 2-3 năm.  

Tuy nhiên, việc chạy toàn bộ EVM bằng FHE đòi hỏi mạch điện rất sâu và phức tạp. Cuối cùng, chúng tôi cũng đã bắt đầu đạt được một số tiến bộ có ý nghĩa với các mạch zkEVM (có cường độ tính toán cao hơn nhiều so với việc chạy EVM tiêu chuẩn), nhưng EVM FHE thậm chí còn còn xa hơn thế.  

Xin lưu ý một lần nữa rằng có thể mô phỏng chức năng này bằng phần cứng đáng tin cậy (ví dụ: SGX trong SUAVE thực hiện việc này).

Giải pháp 2 - Danh sách truy cập có trạng thái

Ngoài ra, chúng ta có thể sử dụng FHE một cách hạn chế hơn và quyền truy cập danh sách. Điều này dễ thực hiện hơn là chạy FHE EVM đầy đủ - đó là một mạch nông hơn. Trong thiết lập này, gói giao dịch có thể bao gồm danh sách truy cập trạng thái được mã hóa và giá thầu của nó. Điều này chỉ định chính xác phần nào của trạng thái mà gói của họ sẽ truy cập.  

Bây giờ, mạch đồng cấu của nhà sản xuất khối chỉ cần chọn giá thầu cao nhất cho gói giao dịch có danh sách truy cập trạng thái rời rạc.  

Xin lưu ý rằng điều này không hoàn toàn tối ưu. Ví dụ: giá thầu cao thứ hai trong một khối (T 2 ) có thể đạt đến trạng thái giống hệt như giá thầu cao nhất (T 1 ). Trong ví dụ về danh sách truy cập này, nhà sản xuất khối sẽ loại bỏ giao dịch thứ hai. Tuy nhiên, có thể cả T 1 và T 2 đều đúng. Trong trường hợp này, FHE EVM (hay sản xuất khối tập trung ngày nay) sẽ thu được nhiều giá trị hơn.  

Nó không hoàn hảo, nhưng xét theo tình hình hiện tại của chúng ta, lối tắt này phải đủ gần mức tối ưu. Phần lớn MEV sẽ vẫn sử dụng danh sách truy cập rời rạc vì các ví dụ về xung đột như trên là rất hiếm.  

6. Dấu thời gian - Đồng hình

Bạn thậm chí có thể thực hiện việc này bằng cách cho phép người xác thực " Các giao dịch giả" được thực hiện để cố gắng che giấu sự rò rỉ của các giao dịch, do đó vùng bộ nhớ luôn được lấp đầy. Người xác thực cũng cần SNARK để chứng minh rằng họ là người xác thực được phép tạo các giao dịch ảo này. Khi các giao dịch "thực" tăng đột biến, người xác thực sẽ phát đi ít giao dịch giả hơn. Khi giao dịch thực giảm xuống, người xác thực sẽ phát hành nhiều giao dịch giả hơn.  

Giả sử mọi thứ được mã hóa bằng FHE, bạn sẽ có thể phát hiện việc bổ sung "cờ ảo" của giao dịch tương ứng. Bạn có thể bỏ qua các giao dịch này khi đóng gói khối thực tế.

Sự khác biệt về trạng thái - FHE EVM

Thông tin cơ bản: Một lợi thế của ZK Rollups là họ không cần xuất bản dữ liệu giao dịch hoàn chỉnh trên chuỗi. "Sự khác biệt trạng thái" giữa các cập nhật trạng thái được công bố của họ là đủ. Thay vào đó, Optimistic Rollups phải xuất bản dữ liệu hoàn chỉnh trên chuỗi để ngăn chặn việc phân xử bằng chứng gian lận. Yêu cầu dữ liệu thấp hơn này giúp tiết kiệm chi phí cho ZK Rollups vì chúng tiêu thụ ít tài nguyên hơn trong lớp sẵn có của dữ liệu.  

Đưa điểm này vào cuộc trò chuyện của chúng ta - lý tưởng nhất là bạn không muốn mất lợi ích này nếu mã hóa nhóm bộ nhớ. Bạn muốn có một nhóm bộ nhớ được mã hóa và vẫn giữ được khả năng ZK Rollup chỉ xuất bản những khác biệt về trạng thái. Câu trả lời là đây - FHE zkEVM. Nghe có vẻ hay nhưng có thể bạn sẽ phải chờ rất lâu.

Một nhược điểm là việc xuất bản các khác biệt về trạng thái riêng lẻ có thể làm chậm khả năng phản hồi của nút tổng hợp đầy đủ. Ví dụ: trong quá trình tổng hợp quy tắc lựa chọn ngã ba thuần túy, các nút đầy đủ có thể hoàn thành chế độ xem tổng hợp của chúng ngay khi lớp sẵn có của dữ liệu được hoàn thành và tính hợp lệ được đảm bảo. Nếu bạn chỉ công bố sự khác biệt về trạng thái (chứ không phải dữ liệu giao dịch đầy đủ), thì ngay cả các nút đầy đủ cũng sẽ cần gửi bằng chứng ZK để xác nhận quan điểm của họ về tổng hợp. Hiện tại - những bằng chứng này sẽ mất một thời gian để tạo ra, nhưng lớp sẵn có của dữ liệu có thể mở rộng hứa hẹn sẽ sớm trở nên rất rẻ.

Kết luận

Nhóm bộ nhớ mật mã là một không gian thiết kế hấp dẫn và đầy hứa hẹn, nhưng vẫn còn một số thách thức thực tế. Ví dụ: bạn có thể di chuyển một số vấn đề nhất định đi nơi khác trong ngăn xếp. Ví có thể kiểm duyệt bạn tại nguồn để ngăn chặn mã hóa/định tuyến giao dịch, họ có thể gửi tải trọng để chạy trước/sau giao dịch của bạn (hoặc bán quyền), v.v. Một câu trả lời khả thi là người dùng có thể tạo giao dịch cục bộ mà không cần dựa vào nhà cung cấp dịch vụ.  

Vấn đề là không có viên đạn ma thuật nào ở đây, nhưng nếu được thiết kế phù hợp, chúng có thể là một phần quan trọng của giải pháp và có thể được cải thiện bằng các chức năng khác nhau và tin tưởng giả định Tình hình hiện tại.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia