Mẹo Đọc

· Trước khi đọc bài viết này, bạn cần hiểu cơ bản về MEV

· Hiểu về giao dịch Ethereum và biết những gì một giao dịch chứa đựng và cách nó cuối cùng được bao gồm trong khối

· Biết về cây Merkle và vai trò của chứng minh không chứng minh

· nhấn để đọc:MEV (5): Một hệ sinh thái MEV công bằng (Phần 1)

Bài viết trước đã giới thiệu (1) thiết kế của Flashbot SGX Builder, giúp tăng tính công bằng của Block Builder thông qua phần cứng đáng tin cậy, và (2) thiết kế của Chainlink FSS, giúp ngăn chặn MEV bằng cách phân quyền xếp hàng giao dịch.

Bài viết này sẽ thảo luận (3) về thiết kế của Encrypted Mempools, mục tiêu là giảm thiểu hoặc loại bỏ MEV bằng cách cung cấp sự riêng tư cho giao dịch thông qua các phương pháp mật mã.

Bể nhớ được mã hóa

Hai mục tiêu: bảo vệ MEV và sự chống cenzô

Nếu có một công cụ cho phép người dùng mã hóa giao dịch của họ trước khi phát sóng chúng, và chỉ giải mã chúng khi chúng được bao gồm trong khối, người dùng sẽ không cần phải lo lắng về việc bị ảnh hưởng bởi MEV. Người tìm kiếm MEV không thể nhìn thấy nội dung giao dịch hoàn toàn, và người dùng không cần phải lo lắng về việc giao dịch của họ bị từ chối thu nhập do bị nhắm mục tiêu bởi người đề xuất hoặc vi phạm các lệnh trừng phạt của chính phủ. Nền tảng xây dựng công cụ này là mật mã học.

Mempools được mã hóa sử dụng mật mã để (1) mã hóa nội dung giao dịch của người dùng để bảo vệ sự riêng tư của họ, và (2) xác minh tính hợp lệ của giao dịch khi nó được mã hóa, ngăn chặn kẻ tấn công tạo ra một đống giao dịch không hợp lệ nhưng đã được mã hóa. Điều này ngăn chặn họ khỏi phát động cuộc tấn công DoS trên chuỗi, vì Người đề xuất sẽ lãng phí không gian khối bằng cách bao gồm một đống giao dịch không hợp lệ chỉ được phát hiện vào phút cuối cùng.

Mẹo đọc: Việc mã hóa đơn thuần không thể đảm bảo hoàn toàn sự chống chịu với sự kiểm duyệt, bởi vì Người Đề Xuất muốn kiểm duyệt vẫn có thể từ chối chấp nhận bất kỳ giao dịch nào được mã hóa, do đó việc mã hóa chỉ tăng chi phí của việc kiểm duyệt (Người Đề Xuất từ bỏ phí xử lý cho tất cả các giao dịch được mã hóa). Để đạt được sự bảo vệ chống chịu kiểm duyệt tốt hơn, bạn cần sử dụng Danh Sách Bao Gồm như PBS.

Đảm bảo giao dịch có thể được giải mã (Đảm bảo giải mã)

Sau khi mã hóa giao dịch, quan trọng là đảm bảo rằng nó có thể được giải mã. Việc không thực hiện điều này có thể tạo ra một lỗ hổng trong cuộc tấn công từ chối dịch vụ (DoS). Trong một cuộc tấn công như vậy, kẻ tấn công liên tục gửi các giao dịch đã được mã hóa mà không thể được giải mã. Kết quả là, nút phải giữ lại những giao dịch này cho đến khi chúng hết hạn, dẫn đến một sự tích lũy của những giao dịch vô dụng này trong hồ bơi giao dịch của nút.

Có một số cách để đảm bảo rằng các giao dịch có thể được giải mã:

1. Tin cậy tuyệt đối (Trong chuyến bay)

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

3. Mã hóa/Giải mã Ngưỡng

4. Trễ Mã hóa/Giải mã

5. Mã hóa/Giải mã chứng kiến

△ Có một số cách để đảm bảo rằng các giao dịch có thể được giải mã và các ví dụ của chúng. Độ phức tạp tăng từ trái sang phải, với sự tin cậy tuyệt đối là đơn giản nhất và việc giải mã của nhân chứng là khó nhất.

Nguồn hình ảnh:https://www.youtube.com/watch?v=XRM0CpGY3sw

Commit-reveal

Cơ chế cam kết-vạch mặt cũng có thể đạt được mục đích tương tự không? Người dùng bắt đầu bằng cách nhập nội dung giao dịch của họ vào một hàm băm để có được giá trị băm, được biết đến là cam kết. Khi người đề xuất đảm bảo việc bao gồm cam kết giao dịch của người dùng vào khối, người dùng tiếp tục tiết lộ toàn bộ nội dung giao dịch.

Mẹo đọc: Cách cam kết có thể giống như Proposer trong PBS hứa rằng nó sẽ được bao gồm trong khối Builder thông qua chữ ký. Đó là một cam kết đảm bảo. Nếu Proposer vi phạm lời hứa, sẽ bị trừng phạt.

Người đề xuất cam kết sẽ nhận cam kết của giao dịch của Alice

Mặc dù Commit-reveal và mã hóa có thể phục vụ cùng một mục đích là che giấu nội dung giao dịch người dùng và ngăn chặn việc trích xuất MEV và kiểm duyệt, nhưng Commit-reveal không thể đảm bảo giải mã vì quyền lực nằm trong tay người dùng. Người dùng có quyền lựa chọn không tiết lộ nội dung, có ý định hoặc không ý định.

Yêu cầu người dùng đính kèm một khoản tiền đặt cọc và mất khoản tiền đặt cọc khi họ không có Reveal có thể làm trở nên tồi tệ hơn trải nghiệm người dùng đang kém của Commit-reveal.

△ Alice không cần phải tiết lộ giao dịch của mình

1. Niềm tin tuyệt đối (Trong chuyến bay)

Người dùng mã hóa giao dịch và gửi nó cho vai trò tập trung. Vai trò tập trung sau đó giải mã giao dịch và đảm bảo rằng nó sẽ không bị rò rỉ trước khi được bao gồm trong khối. Người dùng nói chung tin tưởng vai trò tập trung và coi giao dịch như đã được mã hóa cho đến khi chúng được bao gồm trong khối, mặc dù vai trò tập trung giải mã giao dịch ngay sau khi nhận được.

Mẹo đọc: Ví dụ, vai trò tập trung này sẽ là, ví dụ như Builder, Proposer của PBS hoặc Sequencer/Operator của Rollup.

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

Nó hoạt động giống như niềm tin tuyệt đối, nhưng tốt hơn vì người dùng tin tưởng vào phần cứng đáng tin cậy và mã chương trình mà nó thực thi, thay vì tin tưởng vào một người, một tổ chức hoặc một công ty.

3. Mã hóa/Giải mã Ngưỡng

Chainlink FSS cũng sử dụng mã hóa ngưỡng và giải mã, nhưng trong Chainlink FSS các quản lý của các khóa ngưỡng là các Oracle của Chainlink, trong khi trong Encrypted Mempools các quản lý (được gọi là Keypers) có thể là Validators của L1 hoặc L2 (giả sử L2 cũng có Trong trường hợp Validator phi tập trung).

Mã hóa/giải mã ngưỡng có một số nhược điểm:

• Giả định đa số trung thực mạnh mẽ: Phải giả định rằng hơn một nửa các Keypers là trung thực. Nếu họ không trung thực, họ có thể giải mã và xem giao dịch của người dùng bất cứ lúc nào, xem xét các giao dịch, hoặc trích xuất MEV của các giao dịch.
• Thiếu trách nhiệm: Miễn là có đủ số lượng người tham gia Keyper hợp tác, họ có thể giải mã thông tin. Tuy nhiên, khi các thành viên Keyper âm mưu, chúng ta không biết được ai tham gia âm mưu. Mà không thể xác định được những người tham gia độc ác, việc thiết kế cơ chế trừng phạt cho Keyper là không thể. Do đó, chúng ta phải dựa vào giả định rằng đa số các thành viên Keyper là trung thực.
• Sự sống còn yếu đi: Khi Keyper quá nhiều offline sẽ d导n đến số lượng Keyper online không đủ, điều này sẽ ngăn chặn việc giải mã và sản xuất block. Điều này sẽ làm cho chuỗi tạm dừng. Điều này xung đột với cơ chế Ethereum PoS, nhấn mạnh rằng chuỗi sẽ tiếp tục sản xuất block ngay cả khi có xảy ra chiến tranh thế giới thứ ba, và cuối cùng đạt đến tính cố định. Có thể suy luận rằng xác suất của Ethereum PoS sử dụng giải mã với một ngưỡng không cao.

Bởi vì mã hóa và giải mã ngưỡng yêu cầu nhiều thay đổi, L2 phù hợp hơn cho phương pháp này so với L1.

Bài viết này đề xuất thiết kế và các yếu tố cần xem xét cho việc triển khai trên L1. Các dự án đang thử nghiệm thiết kế này có thể tham khảo Shutter Network. Để biết thêm thông tin, vui lòng kiểm tra:https://ethresear.ch/t/shutterized-beacon-chain/12249

4. Chậm trễ Mã hóa/Giải mã

Việc mã hóa trễ đảm bảo rằng văn bản mã hóa có thể tự động giải mã sau một khoảng thời gian nhất định. Tuy nhiên, quá trình giải mã không hoàn toàn tự động và yêu cầu một người phải làm vai trò giải mã và thực hiện các phép tính liên tục. Sau một khoảng thời gian nhất định, được xác định bởi độ khó của quá trình mã hóa, các phép tính có thể hoàn thành và giải mã có thể được thực hiện thành công.

Khái niệm đằng sau mã hóa trễ tương tự như Chức năng Xác minh Trễ (VDF), cả hai đều thuộc gia đình Mật mã Phát hành Thời gian.

VDF cho phép chúng ta nhanh chóng xác minh F(x): một kết quả của "thuật toán tính toán tuần tự tốn thời gian". Điều này tương tự như Proof of Work (PoW), nhưng thuật toán của VDF là một quá trình tuần tự, khác với PoW, mà có thể được tăng tốc thông qua tính toán song song. Bộ giải mã của VDF chỉ có thể thực hiện các tính toán lặp đi lặp lại từng bước.

△ Với VDF, bạn có thể xác minh kết quả của một phép tính mà mất cho tôi 10 giây để hoàn thành, ví dụ, trong 0.01 giây, và tôi không có cách nào để song song hóa phép tính của mình. Nguồn hình ảnh:https://techtelegraph.co.uk/verifiable-delay-functions-on-bitcoin

Mã hóa và giải mã trễ cũng là các phép tính liên tục giống như VDF, và không thể được tăng tốc thông qua các hoạt động song song. Tuy nhiên, phải xem xét rằng có người sẽ tăng tốc quá trình giải mã thông qua tối ưu phần cứng. Do đó, nếu bạn muốn áp dụng công nghệ này và áp dụng nó trong môi trường công cộng thực tế, bạn phải đảm bảo rằng không ai có một khoảng cách phần cứng lớn và có thể hoàn thành quá trình giải mã trước (và quá trình giải mã được thực hiện riêng tư, vì vậy khó phát hiện).

Hiện tại, Ethereum Foundation và Protocol Labs đã hợp tác trong nghiên cứu vi xử lý ASIC VDF, hy vọng xuất khẩu phần cứng máy tính tiên tiến nhất ra thị trường, để không ai có lợi thế về phần cứng khác biệt và giải mã trước một cách bí mật. Để biết thêm thông tin, vui lòng kiểm tra: https://filecoin.io/blog/posts/collaboration-with-the-ethereum-foundation-on-vdfs/

Mẹo đọc: VDF cũng có thể được sử dụng để tăng tính không thể thao tác của các số ngẫu nhiên trên Ethereum.

Ưu điểm của mã hóa và giải mã trễ so với mã hóa và giải mã ngưỡng là không cần tin tưởng hoặc phụ thuộc vào việc hoạt động bình thường của một nhóm Keypers, và nó sẽ tự động giải mã khi đến thời gian. Tuy nhiên, thời gian giải mã bắt buộc này cũng là một nhược điểm của giải mã trễ: các giao dịch đã được mã hóa phải mất một khoảng thời gian để được giải mã, điều đó có nghĩa là có một thời gian trễ cố định để giao dịch của người dùng được tải lên chuỗi. Ngoài ra, cạnh tranh về phần cứng cũng là một rủi ro không thể phớt lờ trong phương pháp này. Khó khăn để biết liệu có ai đã phát triển một chip nhanh hơn để giải mã.

5. Mã hóa/Giải mã của nhân chứng

Hãy tưởng tượng rằng một bản mã không được giải mã bằng khóa hoặc tính toán tuần tự, mà chỉ có thể được giải mã khi một "điều kiện" nhất định được đáp ứng, chẳng hạn như "khi phương trình này được giải" hoặc "khi phương trình này được giải" Khi bản mã được bao gồm trong khối, bản mã có thể được giải mã, v.v.

Mẹo đọc: "Biết chìa khóa giải mã một văn bản mã hóa" hoặc "biết kết quả của các phép tính liên tục" thực ra là một điều kiện.

Thời gian chứng kiến, chúng ta không chỉ có thể đạt được hiệu ứng của mật mã ngưỡng và mật mã trễ, mà còn có thể kết hợp hai phương pháp giải mã này. Ví dụ, chúng ta có thể đặt điều kiện như “Điều kiện 1: ‘Một nhóm Keypers đồng ý giải mã văn bản này’ hoặc Điều kiện 2: ‘Sau năm phút’”: Nếu tất cả các Keypers đều online, chúng ta có thể nhanh chóng đáp ứng Điều kiện 1 để giải mã văn bản. Tuy nhiên, nếu không đủ Keypers online, chúng ta ít nhất có thể đảm bảo rằng chúng ta có thể đáp ứng Điều kiện 2 và giải mã bằng cách chứng minh thông qua VDF rằng “đã qua năm phút”.

△ Đủ Keypers có thể được giải mã trực tuyến (ở trên) hoặc sau đủ thời gian (ở dưới)

Miễn là điều kiện được chứng minh đã được đáp ứng, việc giải mã có thể được thực hiện. Chứng minh có thể được thực hiện thông qua các phương pháp như chứng minh không cần biết, có thể xác minh một cách hiệu quả các phép tính phức tạp (giả sử các phép tính cần thiết để chứng minh điều kiện là phức tạp) hoặc che giấu thông tin (giả sử người chứng minh không muốn tiết lộ một số thông tin nào đó trong quá trình chứng minh). Tuy nhiên, mặc dù mã hóa chứng kiến rất mạnh mẽ, công nghệ hiện tại không đủ để cung cấp bất kỳ ứng dụng thực tế nào.

△ Sự chín muồi của các công nghệ mã hóa và giải mã khác nhau. Mã hóa và giải mã chứng kiến (Chứng kiến) chưa đủ chín muồi. Nguồn hình ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_591

Thao tác và thực hiện các hoạt động trên văn bản mã hóa thông qua việc mã hóa đồng dạng

Các đoạn văn trước đã giới thiệu các cách khác nhau để đảm bảo rằng giao dịch có thể được giải mã, nhưng khi nào giao dịch có thể được giải mã? Câu trả lời là: sau khi giao dịch được bao gồm trong khối và thứ tự được xác định. Nhưng làm thế nào Block Builder lắp ráp một khối từ một đống lờ mờ, hoặc thậm chí lắp ráp một khối cực kỳ lợi nhuận? Câu trả lời là: Mã hóa đồng dạng (HE).

△ Ví dụ về mã hóa đồng dạng được sử dụng cho việc bỏ phiếu: Nội dung của phiếu đã được mã hóa, nhưng văn bản mật vẫn có thể được cộng và giải mã sau khi kết quả được tính toán. Nguồn ảnh:https://twitter.com/khushii_w/status/1660278622291210242

Mẹo đọc: Nếu việc mã hóa và giải mã được thực hiện thông qua sự tin cậy tuyệt đối (trong quá trình truyền tải) hoặc phần cứng tin cậy, thì thực sự không cần chờ đến khi giao dịch được bao gồm trong khối và thứ tự được xác định trước khi giải mã. Cuối cùng, mọi người đều tin tưởng vào bên kia, vì vậy sẽ giải mã và sắp xếp giao dịch ngay sau khi nhận được. Điều này có thể tăng tốc quá trình hình thành các khối và không đòi hỏi tài nguyên bổ sung để thực hiện các hoạt động mã hóa đồng dạng.

Thông qua mã hóa đồng cấu, chúng ta có thể thực hiện các thao tác trên bản mã mà không cần giải mã giao dịch. Chúng tôi có thể áp dụng quy trình hoạt động sắp xếp các giao dịch và hình thành một khối pháp lý cho các giao dịch được mã hóa này mà không cần giải mã giao dịch và có được giao dịch được mã hóa. Khối. Khi khối được giải mã, chúng ta sẽ có được một khối hoàn chỉnh và hợp pháp, trong đó các giao dịch được giải mã và sắp xếp theo thứ tự trước khi mã hóa.

△ Thông qua việc mã hóa đồng dạng, Block Builder có thể lắp ráp một khối hoàn chỉnh và hợp pháp từ các giao dịch đã được mã hóa

Mẹo đọc: Có các cấp độ của mã hóa đồng dạng, như mã hóa đồng dạng một phần (Partially HE) và mã hóa đồng dạng hoàn toàn (Fully HE). Mã hóa đồng dạng một phần chỉ có thể cộng hoặc nhân với văn bản mã hóa, trong khi mã hóa đồng dạng hoàn toàn có thể cộng và nhân với văn bản mã hóa (về cơ bản, bất kỳ phép toán nào cũng có thể được thực hiện).

△ Cột thứ ba: Sự chín muồi của các công nghệ mã hóa và giải mã khác nhau hỗ trợ FHE. Ngoại trừ trạng thái trên đường bay và khu vực an toàn, không yêu cầu HE và do đó được coi là được hỗ trợ, các cái khác vẫn chưa có sẵn. Nguồn hình ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_620

Phần trên giới thiệu các cơ chế khác nhau để mã hóa và giải mã giao dịch. Mỗi cơ chế này đều có các ưu điểm và nhược điểm khác nhau, nhưng cuối cùng, tất cả chúng đều chỉ có thể che giấu nội dung giao dịch và đảm bảo rằng nó có thể được giải mã khi các điều kiện được đáp ứng. Khi nội dung giao dịch bị che giấu, nó có thể tránh việc giải mã. Rút trích MEV và nguy cơ bị kiểm duyệt.

Nhưng dữ liệu giao dịch chính sẽ có siêu dữ liệu liên quan, ví dụ như người khởi tạo giao dịch, phí giao dịch hoặc chữ ký, được sử dụng để xác minh tính hợp lệ của giao dịch. Ngoài ra, địa chỉ IP của người khởi tạo cũng là một dạng siêu dữ liệu, và thậm chí cả kích thước dữ liệu của giao dịch. Tất cả các siêu dữ liệu này đều có khả năng rò rỉ thông tin riêng tư của người dùng, vì vậy chúng ta cũng phải bảo vệ siêu dữ liệu này.

Đảm bảo dữ liệu siêu dữ liệu không rò rỉ quyền riêng tư

Danh sách sau liệt kê các siêu dữ liệu khác nhau của các giao dịch được mã hóa và các biện pháp bảo vệ tương ứng, sẽ đòi hỏi các kỹ thuật mật mã như mã hóa đồng dạng và chứng minh không bằng chứng.

1. địa chỉ IP

2. Chữ ký giao dịch

3. Phí giao dịch

4. Người khởi tạo giao dịch và giá trị Nonce của nó

5. Quy mô giao dịch

△ Các siêu dữ liệu khác nhau của giao dịch có thể tiết lộ quyền riêng tư của người dùng. Nguồn hình ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_709

Địa chỉ IP

Mạng mà người dùng kết nối để gửi giao dịch được mã hóa có thể tiết lộ danh tính của người dùng dựa trên địa chỉ IP của người dùng và có thể bị kiểm duyệt. Bảo vệ quyền riêng tư ở mức độ mạng phụ thuộc vào các công nghệ như Tor.

Chữ ký giao dịch, phí xử lý, người khởi tạo giao dịch và giá trị Nonce của nó

Những dữ liệu siêu dữ liệu này được sử dụng để chứng minh tính hợp lệ của giao dịch, nhưng chúng sẽ tiết lộ danh tính của người dùng, vì vậy chúng phải được mã hóa. Một khi đã được mã hóa, chúng ta phải sử dụng các công cụ khác để chứng minh tính hợp lệ của giao dịch mà không tiết lộ thông tin này. Nếu không, mạng có thể bị tấn công bởi DoS và bị lấp đầy bởi một đống giao dịch không hợp lệ chỉ được phát hiện sau khi giải mã.

Khi một nút nhận được một giao dịch được mã hóa, nó phải (1) xác nhận rằng người khởi xướng giao dịch thực sự đã khởi xướng giao dịch, tức là, xác minh chữ ký giao dịch, sau đó (2) xác nhận rằng người khởi xướng có đủ ETH để thanh toán cho giao dịch (số dư người dùng ≥ giá gas * giới hạn gas), và (3) kiểm tra giá trị nonce của người gửi để tránh các cuộc tấn công phát lại giao dịch.

Chứng minh không mất thông tin

Chúng ta có thể sử dụng chứng minh không tiết lộ để chứng minh rằng các giao dịch vượt qua những kiểm tra này mà không tiết lộ thông tin này. Một chứng minh không tiết lộ bao gồm thông tin công khai (Public Input), thông tin riêng tư (Private Witness), và câu lệnh mà chứng minh muốn chứng minh (Statement).

△ Ví dụ, thông tin công cộng (đầu vào công cộng) là một giao dịch được mã hóa (văn bản giao dịch), thông tin riêng tư (chứng nhân riêng tư) là một giao dịch không mã hóa (văn bản giao dịch), và câu lệnh (tuyên bố zk) cần được chứng minh bằng bằng chứng không biết (zero-knowledge proof) là "các Giao dịch được mã hóa là hợp lệ" (văn bản giao dịch hợp lệ). Nguồn ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_391

Ví dụ, nếu Alice muốn chứng minh với Bob rằng cô ấy có hơn 10 ETH nhưng không muốn tiết lộ địa chỉ của mình, cô ấy có thể sử dụng chứng minh không tiết lộ để chứng minh với Bob rằng địa chỉ của cô ấy thực sự có số dư hơn 10 ETH.

“Chứng minh rằng địa chỉ của Alice có số dư lớn hơn 10 ETH” là câu lệnh (câu lệnh zk) cần được chứng minh bằng bằng chứng không chứng thực này. Để tạo ra bằng chứng này, Alice phải cung cấp địa chỉ của mình và chứng minh rằng cô ấy giữ khóa riêng tư của địa chỉ (ví dụ, bằng cách Sử dụng khóa riêng tư tạo chữ ký), và cô ấy cũng cần cung cấp số dư ETH của địa chỉ này, ví dụ, sử dụng Merkle Proof để chứng minh địa chỉ này giữ bao nhiêu ETH trong khối thứ 1001.

Địa chỉ, chữ ký và Chứng minh Merkle không thể tiết lộ và là thông tin riêng tư (nhân chứng riêng).

Khi bằng chứng này được tạo ra, Bob có thể xác minh bằng chứng này với Merkle Root (được gọi là Gốc Trạng thái) của cây trạng thái của khối 1001. Bất kỳ ai biết Gốc Trạng thái của mỗi khối, đó là thông tin công khai (đầu vào công khai).

Bob chỉ biết thông tin duy nhất là thông tin công khai của State Root và kết quả xác minh. Anh ấy sẽ không biết bất kỳ thông tin riêng tư nào của Alice.

△ Alice cung cấp hai đầu vào riêng: Chứng minh Merkle và chữ ký; Bob cung cấp đầu vào công khai của Gốc trạng thái. Tuyên bố zk có thể xác minh rằng Alice có một địa chỉ và số dư của địa chỉ đó là > 10 ETH

(1) Xác minh chữ ký giao dịch

Xác minh chữ ký giao dịch bao gồm hai phần: (a) người khởi tạo giao dịch hợp lệ và (b) chữ ký giao dịch được ký bởi người khởi tạo giao dịch.

(a) Chủ yếu để xác minh rằng địa chỉ Ethereum của người khởi tạo giao dịch là một địa chỉ hợp lệ và không phải là một số ngẫu nhiên. Điều này sẽ được chứng minh thông qua một Bằng chứng Merkle rằng địa chỉ tồn tại trong cây trạng thái Ethereum.

(b) Xác minh rằng chữ ký giao dịch được ký bởi khóa riêng của người khởi tạo giao dịch.

△ Bằng chứng này xác minh (a) địa chỉ của người gửi giao dịch (thông qua chứng thực Merkle của khóa công khai của người gửi) và (b) chữ ký trong giao dịch là hợp lệ (chữ ký sẽ được bao gồm trong văn bản tx). Văn bản tx là dữ liệu giao dịch thô chưa được mã hóa, đó là thông tin riêng tư do người khởi tạo giao dịch cung cấp.

Nguồn ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_736

Mẹo đọc: Văn bản màu đỏ trong hình ảnh trên đề cập đến ý nghĩa của chứng chỉ sau khi vượt qua xác minh (tức là “chữ ký của giao dịch là hợp lệ”). Đó không phải là phần của câu lệnh zk. Phần màu xanh là thông tin liên quan đến giao dịch chính nó, bao gồm dữ liệu giao dịch được mã hóa (công khai) và dữ liệu giao dịch không mã hóa (riêng tư). Phần màu xanh lá cây là dữ liệu bổ sung cần thiết để hoàn thành bằng chứng, cả công khai và riêng tư.

△ Chứng minh rằng địa chỉ của người khởi tạo giao dịch tồn tại trong cây trạng thái Ethereum và người khởi tạo giao dịch thực sự có khóa riêng của địa chỉ đó

(2) Xác nhận rằng người khởi tạo giao dịch có đủ ETH để thanh toán phí giao dịch

Giống như ví dụ trước về Alice và Bob chứng minh rằng số dư là > 10 ETH, người khởi tạo giao dịch cần cung cấp Chứng minh Merkle về số dư của địa chỉ của mình, và câu phát biểu cần chứng minh là “số dư của địa chỉ ≥ phí giao dịch.” Phí giao dịch bằng với giá gas nhân với giới hạn gas. Cả thông tin về giá gas và giới hạn gas đều được bao gồm trong dữ liệu giao dịch không mã hóa gốc (plaintext tx). Plaintext tx là thông tin riêng tư do người khởi tạo giao dịch cung cấp.

△ Bằng chứng này xác minh rằng số dư của địa chỉ người khởi tạo giao dịch (thông qua chứng minh cân bằng người gửi Merkle) lớn hơn hoặc bằng phí giao dịch (thông tin phí giao dịch được bao gồm trong văn bản tx). Nguồn hình ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_743

△ Chứng minh cân đối của địa chỉ người khởi tạo giao dịch > giá gas

(3) Xác minh giá trị Nonce của người khởi tạo giao dịch

Bởi vì Nonce cũng được ghi lại trong trạng thái Ethereum, Merkle Proof cũng được sử dụng để chứng minh giá trị Nonce hiện tại của người khởi tạo giao dịch, sau đó so sánh với giá trị Nonce được chỉ định trong giao dịch để xác nhận rằng giao dịch không bị phát lại.

△ Bằng chứng này so sánh giá trị Nonce của địa chỉ người khởi xướng giao dịch (qua chứng minh Merkle Nonce) và giá trị Nonce được chỉ định bởi giao dịch (giá trị Nonce được chỉ định bởi giao dịch được bao gồm trong văn bản tx). Nguồn hình ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_327

△ Chứng minh số thứ tự của địa chỉ khởi tạo giao dịch = số thứ tự giao dịch

Tuy nhiên, kiểm tra này không thể ngăn chặn kẻ tấn công độc hại tạo ra nhiều giao dịch với cùng một giá trị Nonce (những giao dịch này đều có thể vượt qua kiểm tra giá trị Nonce) để thực hiện các cuộc tấn công DoS, vì vậy chúng ta cần thêm các kiểm tra bổ sung.

Chúng tôi yêu cầu người khởi tạo giao dịch cung cấp thêm một Thẻ Phát lại để đảm bảo sẽ chỉ có một giao dịch với cùng một giá trị Nonce. Thẻ Phát lại là giá trị băm của giá trị Nonce và khóa riêng của người khởi tạo giao dịch: thẻ phát lại = H (nonce, khóa riêng), vì vậy các giá trị Nonce khác nhau của cùng một người khởi tạo giao dịch sẽ tương ứng với một Thẻ Phát lại duy nhất.

Do đó, các nút có thể sử dụng Thẻ Phát lại để xác định xem một bên khởi tạo giao dịch đã khởi tạo nhiều giao dịch với cùng giá trị Nonce (các Thẻ Phát lại của những giao dịch này sẽ giống nhau), và từ chối giao dịch thứ hai có cùng Thẻ Phát lại.

△ Bằng chứng này sẽ tính toán thẻ phát lại và so sánh nó với thẻ phát lại được truyền vào bởi đầu vào công khai. Giá trị Nonce của giao dịch được chứa trong văn bản tx, và khóa riêng tư được chứa trong chứng cứ riêng tư.

Nguồn hình ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_750

△ Chứng minh nonce của địa chỉ người khởi tạo giao dịch = tx nonce và thẻ phát lại = H(nonce, key)

Hoặc nếu chúng ta xem xét rằng người khởi xướng giao dịch có thể muốn thay thế giao dịch với cùng giá trị Nonce bằng một giao dịch khác, có lẽ vì anh ta không muốn thực hiện giao dịch ban đầu, hoặc anh ta muốn tăng giá gas để giao dịch có thể được thu thập nhanh hơn.

Lúc này, chúng ta có thể giới thiệu giá trị Slot của PoS vào việc tính toán Tag Tái phát: tag tái phát = H(nonce, khóa riêng, slot). Ví dụ, Bob đã gửi một giao dịch với một Nonce là 5 trong Slot 1001 nhưng vẫn chưa nhận được, vì vậy anh ấy quyết định tăng giá gas của giao dịch gấp đôi trong khi giữ nguyên các trường khác, và gửi giao dịch được cập nhật trong Slot 1005. Giao dịch này, và vì Slot đã thay đổi, Tag Tái phát là khác nhau, và giao dịch mới này sẽ không bị từ chối vì giá trị Nonce là giống nhau.

△ Các giá trị khe cắm bổ sung sẽ được truyền vào đầu vào công khai để tính toán thẻ phát lại. Nguồn ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_757

5. Kích thước giao dịch

Một số phương pháp mã hóa sẽ làm cho kích thước dữ liệu giao dịch đã được mã hóa giống như trước khi mã hóa. Tuy nhiên, vẫn có cơ hội suy luận được một số thông tin thông qua kích thước. Ví dụ, dữ liệu giao dịch của một giao dịch được thực hiện trong Uniswap phải lớn hơn dữ liệu giao dịch của một giao dịch ETH đơn giản. Lớn, vì vậy kích thước giao dịch giống như siêu dữ liệu có thể rò rỉ quyền riêng tư.

Một cách tiếp cận trực quan là thực hiện một hành động đệm trên dữ liệu giao dịch trước khi mã hóa nó, như đệm một loạt các số không đến khi kích thước giao dịch trở thành một lũy thừa của hai, hoặc thậm chí đệm nó cho đến khi nó trở thành một kích thước cố định. Điều này giảm cơ hội của một người quan sát xác định giao dịch dựa trên kích thước của nó. Block Builder sẽ kết hợp các giao dịch đã đệm vào một khối.

△ Trắng là Lớp lót. Các ưu đãi màu xanh và cam có cùng kích thước, vì vậy không có cách nào phân biệt chúng dựa trên kích thước. Nguồn ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_860

Tuy nhiên, nhược điểm của phương pháp này là (1) nó không hiệu quả vì rất nhiều không gian trong khối sẽ bị lãng phí trên Đệm và (2) nó có thể không cung cấp đủ bảo vệ quyền riêng tư. Ví dụ: kích thước của giao dịch màu đỏ trong hình trên (bốn ô vuông) có thể rất hiếm, vì vậy nó vẫn có thể được tìm ra. Nếu tất cả các giao dịch được đệm vào một kích thước cố định (chẳng hạn như 64 khối), quyền riêng tư sẽ được cải thiện, nhưng nó sẽ trở thành một sự lãng phí tương đối của không gian khối.

△ Nhược điểm là sự không hiệu quả và bảo vệ quyền riêng tư hạn chế. Nguồn ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_812

Một cách tiếp cận tốt hơn là trước tiên thêm dữ liệu vào các giao dịch để có kích thước cố định, nhưng mã hóa đồ hợp có thể được sử dụng để loại bỏ phần dữ liệu thêm vào.

Vì tất cả các giao dịch đều được đệm đến một kích thước cố định, tất cả các giao dịch được nhìn thấy bởi các quan sát viên sẽ có cùng một kích thước. Người xây dựng khối có thể kết hợp các giao dịch được mã hóa thông qua một hàm và loại bỏ đệm đồng thời.

△ Sử dụng mã hóa homomorphic để loại bỏ Padding khi kết hợp các giao dịch được mã hóa. Nguồn hình ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_908

Mẹo đọc: Người xây dựng khối với niềm tin tuyệt đối hoặc phần cứng tin cậy có thể đạt được cùng hiệu quả mà không cần mật mã đồng dạng (sau tất cả, mọi người đều tin tưởng nó).

Cách Block Builder xây dựng các khối hiệu quả

Mặc dù chúng ta có thể kết hợp giao dịch được mã hóa một cách hiệu quả vào một khối thông qua mã hóa đồng cấu, nhưng vẫn còn một số vấn đề cần giải quyết, chẳng hạn như (1) các giao dịch khác nhau có thể đọc và viết trạng thái giống nhau (ví dụ, tất cả đều thực hiện giao dịch trên Uniswap), điều này có thể dẫn đến việc giao dịch có hạng thấp hơn có khả năng thất bại nhiều hơn, và (2) Người xây dựng khối không thể thu thập các giao dịch theo mức phí xử lý.

Giải pháp lý tưởng là chạy EVM trong mã hóa đồng dạng, giống như việc đưa EVM vào một hộp đen để thực thi, để Block Builder có thể mô phỏng việc thực thi giao dịch thông qua EVM để tạo ra khối hiệu quả nhất và có thu nhập cao nhất. Tuy nhiên, độ phức tạp kỹ thuật của công nghệ này quá cao, và sẽ mất một thời gian dài để thực hiện nó.

Phương án thay thế là đính kèm một phí xử lý được mã hóa và một Danh sách Truy cập được mã hóa vào giao dịch (Danh sách Truy cập được sử dụng để chỉ định các trạng thái mà giao dịch sẽ đọc và viết), và sử dụng mã hóa homomorphic để xác minh tính hợp lệ. Điều này giúp Block Builder xác định thứ tự thu nhập của giao dịch thông qua phí xử lý, và sử dụng Danh sách Truy cập để ngăn các giao dịch ảnh hưởng đến nhau và dẫn đến hiệu suất thực thi giao dịch giảm.

△ Nó được xác định bởi phí xử lý và Danh sách Truy cập xem giao dịch nào sẽ được thu thập và thứ tự mà họ sẽ được thu thập. Nguồn ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1133

Thời điểm giao dịch xảy ra

Nếu chúng ta lo lắng rằng thời điểm mà giao dịch được mã hóa được gửi đến mạng p2p có thể làm lộ thông tin riêng tư (ví dụ, Alice thực hiện giao dịch vào lúc UTC+8 00:00–04:00), chúng ta có thể yêu cầu các Validators gửi một đống Giao Dịch Giả mã hóa thường xuyên để làm rối loạn người quan sát.

Giao dịch giả mạo sẽ cần được đính kèm với một chứng minh không cần biết để chứng minh rằng nó đã được gửi bởi Người xác minh và giới hạn tần suất để ngăn mạng lưới bị lấp đầy bởi Giao dịch giả mạo (người quan sát sẽ không biết rằng đó là một Giao dịch giả mạo, chỉ biết rằng nó là "hợp pháp và hợp lệ").

Giao dịch giả sẽ được xác định và loại bỏ trong quá trình mã hóa đồng dạng của khối nhóm.

△ Người xác minh thường xuyên gửi Giao Dịch Giả (màu xám) để làm lạc đào, nhưng điều này sẽ tăng gánh nặng cho mạng lưới và các nút. Nguồn ảnh:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1210

Bể nhớt được mã hóa v.s FSS

Bài viết trước đó cũng đã giới thiệu rằng FSS sẽ mã hóa giao dịch trước và sau đó chuyển giao cho Chainlink Oracle để sắp xếp. Quá trình mã hóa giao dịch và xác minh tính hợp lệ của giao dịch đã được mã hóa của FSS thực ra giống như Encrypted Mempools, ngoại trừ:

• Việc mã hóa giao dịch của FSS không đề cập đến việc bảo vệ Dữ liệu Siêu dữ liệu, trong khi Bể nhớ Mã hóa ẩn Dữ liệu Siêu dữ liệu và sử dụng chứng minh không biết để chứng minh tính hợp lệ của giao dịch.
• FSS hiện đang sử dụng Mã hóa/Giải mã Ngưỡng và được giải mã chung bởi Chainlink Oracle, điều đó có nghĩa là bạn phải tin tưởng Chainlink Oracle. Encrypted Mempools không chỉ định cách sắp xếp, mà chỉ tập trung vào việc mã hóa giao dịch và chứng minh tính hợp lệ của chúng với bằng chứng không biết.
• So với FSS chỉ nhấn mạnh vào "sự công bằng", Encrypted Mempools đặt nhiều sự chú ý hơn vào "cách hiệu quả để lắp ráp nội dung khối và cách cho Phụ trách lắp ráp khối có lợi nhất thay vì chỉ ngẫu nhiên quyết định thứ tự của giao dịch."

Trong tương lai, FSS cũng có thể sử dụng công nghệ trong Encrypted Mempools để tăng cường hoặc thay thế các giao dịch mã hóa và giải mã của mình.

Đối phó với MEV bằng mật mã

Bài thuyết trình này nói về Mempools được Mã hóa, nơi tác giả chia sẻ cách các kỹ thuật mật mã và cải tiến trong lớp đồng thuận Ethereum có thể giúp chống lại các vấn đề do MEV gây ra. Để biết thêm chi tiết, vui lòng kiểm tra:https://www.youtube.com/watch?v=mpRq-WFihz8

Tóm tắt và điểm nổi bật

1. Mục đích của Encrypted Mempools là bảo vệ chống lại MEV và kiểm duyệt bằng cách mã hóa giao dịch. Người khác chỉ có thể biết rằng giao dịch của bạn là hợp lệ, nhưng họ không thể biết bạn đang thực hiện những hành động gì trong giao dịch của bạn.

2. Tuy nhiên, để thực sự đạt được sự chống cenzor hiệu quả, cơ chế như Danh sách Bao gồm PBS phải được sử dụng. Nếu không, Người xây dựng vẫn có thể thực hiện việc kiểm duyệt bằng cách từ chối nhận các giao dịch được mã hóa.

3. Không dễ dàng chứng minh rằng một giao dịch được mã hóa là hợp lệ. Bạn cần nhiều chứng minh không tiết lộ để chứng minh chữ ký của giao dịch, giá trị Nonce của người khởi tạo giao dịch, các khoản phí xử lý đủ, v.v.

4. Ngoài ra, cần tránh các siêu dữ liệu như IP, kích thước dữ liệu giao dịch hoặc thời gian gửi giao dịch làm rò rỉ quyền riêng tư của giao dịch.

5. Cuối cùng, điều quan trọng nhất là đảm bảo rằng các giao dịch có thể được giải mã —— Bảo mật Đảm bảo. Có năm phương pháp khác nhau: Tin cậy tuyệt đối (Trên đường bay), Ổ bảo mật phần cứng tin cậy, Mật mã/Giải mã ngưỡng, Mật mã/Giải mã trì hoãn, và Mật mã/Giải mã nhân chứng. Mỗi phương pháp đều có ưu điểm và nhược điểm riêng.

Dữ liệu tham khảo và đọc thêm được khuyến nghị

Hồ bơi giao dịch được mã hóa

• https://www.youtube.com/watch?v=XRM0CpGY3sw
• https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_639
• Làm thế nào mật mã giúp giải quyết các vấn đề do MEV gây ra từ lớp ứng dụng và lớp đồng thuận:https://youtu.be/jLHf6yw7b5Y?t=4139

Cảm ơn đặc biệt Steven Wu, Kimi Wu, Kevin Mai-Hsuan Chia và Anton Cheng đã xem xét và cải thiện bài viết này.

免责声明：

1. Bài viết này được sao chép từ [Gatetechflowpost]. Tất cả bản quyền thuộc về tác giả gốc [Will 阿望；Diane Cheung]. Nếu có ý kiến phản đối về việc tái in này, vui lòng liên hệ Cổng Họcđội ngũ và họ sẽ xử lý ngay lập tức.
2. Thông báo miễn trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi đội ngũ Gate Learn. Trừ khi được nêu rõ, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch là không được phép.