Cơ chế chống thông đồng cho Mempool được mã hóa Threshold
Cảm ơn Luis Bezzenberger đã có những bình luận có giá trị về bài đăng này.
TL;DR: Mempool được mã hóa là một phương pháp tiếp cận đầy hứa hẹn để ngăn chặn việc trích xuất độc hại Giá trị có thể trích xuất tối đa (MEV) (MEV) trong các blockchain công khai như Ethereum. Threshold là một ứng cử viên tốt để thiết lập một mempool được mã hóa, nhưng thật không may, nó phụ thuộc rất nhiều vào giả định về độ tin cậy Threshold : giả định rằng trong một tập hợp các bên được xác định trước (ủy ban Threshold ), ít nhất một tập hợp con của các bên này hành động trung thực. Trong bài đăng này, chúng tôi khám phá một phương pháp tiếp cận để thiết lập một mempool được mã hóa Threshold vẫn an toàn ngay cả khi tất cả các bên trong ủy ban Threshold thông đồng với nhau.
Giá trị có thể trích xuất tối đa (MEV) (MEV) trong mạng blockchain mô tả giá trị mà một số bên tham gia có thể nắm bắt bằng cách thao túng thứ tự thực hiện giao dịch, thường là gây thiệt hại cho những người dùng khác. Thật vậy, ước tính tổng số MEV bị đánh cắp từ người dùng trong Ethereum cho đến nay dao động trong khoảng từ 1,1 đến 3 tỷ đô la Mỹ . Mempool được mã hóa là một phương pháp tiếp cận đầy hứa hẹn để ngăn chặn việc trích xuất MEV độc hại bằng cách mã hóa các giao dịch cho đến khi thứ tự thực hiện của chúng được cố định. Một ứng cử viên tốt để thiết lập mempool được mã hóa là mã hóa Threshold , đây là một chương trình mã hóa khóa công khai trong đó khóa giải mã được chia cho một ủy ban các bên. Nghĩa là, để giải mã một bản mã, cần có sự hợp tác từ ít nhất một số Threshold nhất định trong số các bên này. Nếu ít hơn số lượng bên tham gia này, sẽ không có thông tin nào về bản rõ hoặc khóa giải mã được tiết lộ. Nguyên thủy này cho phép một mempool được mã hóa như sau:
Ủy ban Threshold ban đầu sẽ tạo ra một khóa công khai và chia sẻ khóa bí mật tương ứng.
Người dùng mã hóa giao dịch của họ bằng khóa công khai của ủy ban Threshold .
Khi vị trí của giao dịch được mã hóa được "cố định" ở đầu Block, ủy ban sẽ cùng nhau giải mã văn bản mã hóa và tiết lộ giao dịch.
Trong khi mã hóa Threshold là một phương pháp đầy hứa hẹn, nó dựa trên giả định về Threshold tin cậy - tiền đề là số lượng thành viên ủy ban hành động ác ý ít hơn Threshold . Nếu vượt quá Threshold này, các bên độc hại có thể thông đồng để giải mã các giao dịch trước thời hạn, cho phép họ tìm hiểu nội dung của các giao dịch được mã hóa và do đó trích xuất MEV độc hại. Trong bài đăng này, chúng tôi khám phá một cơ chế chống thông đồng cho các mempool được mã hóa Threshold , giúp giảm hiệu quả giả định về Threshold tin cậy. Chúng tôi minh họa cơ chế này tại ví dụ về một mempool được mã hóa bằng cách sử dụng lược đồ mã hóa Threshold Shutter và thảo luận sau đó rằng nó có thể được khái quát hóa cho về cơ bản bất kỳ mempool được mã hóa Threshold .
Tóm tắt: Shutter Encrypted Mempool
Shutter về cơ bản là một biến thể Threshold của lược đồ mã hóa dựa trên danh tính Boneh-Franklin (IBE) . Một lược đồ IBE bao gồm một cặp khóa công khai/bí mật chính (mpk, msk) ( m p k , m s k ) và nó cho phép mã hóa một thông điệp m m wrt một số danh tính i i và khóa công khai chính mpk m p k . Trong phần sau, chúng tôi sẽ biểu thị mã hóa Shutter bằng ct \leftarrow Shutter.Encrypt(mpk, i, m) c t ← Shutter.Encrypt ( mpk , i , m ) c t ← Shutter.Enc r y p t ( m p k , i , m ) . Bản mã kết quả ct c t có thể được giải mã bằng cách suy ra cái gọi là khóa bí mật danh tính sk_i s k i từ khóa bí mật chính msk m s k và danh tính i i và sử dụng sk_i s k i để giải mã. Chúng tôi biểu thị giải mã bằng m \leftarrow Shutter.Decrypt(sk_i, ct) m ← Shutter.Decrypt ( sk_i , ct ) m ← Shutter.Decrypt ( sk_i , c t ) . Thông thường trong các lược đồ IBE , khóa bí mật chính được duy trì bởi một cơ quan đáng tin cậy, nhưng trong trường hợp của Shutter, khóa này được phân phối giữa một ủy ban các bên, được gọi là Keypers, sao cho không một bên nào có quyền truy cập vào khóa đầy đủ. Nghĩa là, đối với một mempool được mã hóa của Shutter, người dùng có thể gửi giao dịch tx t x được mã hóa của mình theo mpk m p k và một danh tính i i . Sau đó, khi vị trí của giao dịch được mã hóa được cố định ở đầu một Block, các Keypers cùng nhau suy ra khóa bí mật danh tính sk_i s k i và giải mã giao dịch.
Việc sửa vị trí của bản mã trong Block có nghĩa là gì?
MEV chỉ có thể được ngăn chặn hiệu quả bằng mã hóa Threshold , nếu vị trí của một bản mã trong Block được cố định ở đầu trước khi giải mã. Nếu không, người đề xuất Block có thể chỉ cần đợi một bản mã được giải mã và sắp xếp lại việc thực thi của nó dựa trên nội dung của nó. Có một số cách để đảm bảo vị trí cố định, chẳng hạn như danh sách bao gồm như FOCIL hoặc cam kết của người đề xuất (xem ví dụ, Commit-Boost ). Trong bài đăng này, chúng tôi tập trung vào thiết kế mempool được mã hóa Threshold tận dụng các cam kết của người đề xuất — một khái niệm mà chúng tôi đã khám phá chi tiết gần đây tại đây ). Sau đó, chúng tôi sẽ thảo luận về cách tiếp cận này có khả năng được khái quát hóa thành các phương pháp khác để thực thi thứ tự giao dịch sau khi giải mã.
Cam kết của người đề xuất cho phép người đề xuất Block đưa ra cam kết về việc phân bổ không gian trong Block mà họ sắp đề xuất. Một Use Case phổ biến của các cam kết như vậy là xác nhận trước giao dịch, trong đó người đề xuất Block cam kết đưa một số giao dịch nhất định vào Block của mình, do đó cung cấp cho người gửi giao dịch sự đảm bảo rằng các giao dịch của họ thực sự sẽ được thực hiện sau khi Block được hoàn tất. Ở cấp độ cao, cam kết của người đề xuất là các tuyên bố đã ký và nếu người đề xuất không tuân theo cam kết của mình, nó có thể bị cắt giảm do đó ngăn chặn hành vi độc hại. Commit-Boost, một nỗ lực chuẩn hóa nổi bật cho các cam kết của người đề xuất, chỉ định rằng các cam kết có thể là chữ ký BLS theo các khóa xác thực hiện có.
Trong bối cảnh của mempool được mã hóa, các cam kết của người đề xuất có thể được mở rộng để bao gồm các giao dịch được mã hóa. Người đề xuất có thể cam kết bao gồm một bản mã đã giải mã trong Block, với điều kiện giao dịch kết quả là hợp lệ. Cam kết có thể là một tuyên bố đã ký “ Nếu bản mã ct c t chứa một giao dịch hợp lệ và nếu nó đang được giải mã đúng hạn, tôi sẽ bao gồm giao dịch được mã hóa trong ct c t ở đầu Block k k ”.
Cơ chế chống thông đồng
Ý tưởng cấp cao. Ý tưởng chính của cơ chế chống thông đồng là làm cho Keypers không thể giải mã một bản mã từ mempool được mã hóa về mặt kỹ thuật trước khi người đề xuất Block đưa ra cam kết hợp lệ để đưa giao dịch đã giải mã vào đầu Block. Điều này đảm bảo rằng nếu một bản mã được giải mã, giao dịch kết quả sẽ được đưa vào Block tiếp theo hoặc người đề xuất sẽ bị cắt. Nếu không có cam kết như vậy, thì Keypers không thể giải mã bản mã. Sau đây, chúng tôi sẽ mô tả cách tiếp cận này ở cấp độ kỹ thuật hơn.
Chi tiết kỹ thuật. Cốt lõi của cơ chế chống thông đồng là quan sát sau đây được đưa ra bởi các tác phẩm trước đó (ví dụ: 1 , 2 ): chữ ký BLS có thể được sử dụng làm khóa giải mã trong lược đồ mã hóa Boneh-Franklin. Vì Shutter dựa trên lược đồ Boneh-Franklin, nên Shutter cũng vậy. Chúng ta hãy đi sâu hơn một Bit vào chi tiết:
- BLS, như được sử dụng trong Ethereum, và Shutter hoạt động trên cùng một đường cong elip BLS12-381
- Một cặp khóa công khai và bí mật BLS cũng có thể được sử dụng làm cặp khóa chính cho Shutter
- Khóa bí mật danh tính trong Shutter có cấu trúc của chữ ký BLS, nghĩa là khóa bí mật danh tính cho danh tính i i là sk_i = H(i)^{msk} s k i = H ( i ) m s k và sk_i s k i là chữ ký BLS hợp lệ cho i i theo khóa bí mật msk m s k
Tất cả điều này có nghĩa là chữ ký BLS của người đề xuất có thể được sử dụng làm khóa giải mã cho Shutter.
Cơ chế chống thông đồng sau đó hoạt động như sau: Giả sử mpk m p k là khóa công khai chính của ủy ban Shutter và giả sử pk p k là khóa công khai BLS của người đề xuất. Sau đó, người dùng mã hóa giao dịch tx t x của mình như sau:
- như trước đây người dùng mã hóa tx t x bằng cách sử dụng mpk m p k và một danh tính i i , tức là người dùng tính toán ct_1 \ leftarrow Shutter.Encrypt ( mpk , i , tx ) c t 1 ← Shutter.Encrypt ( m p k , i , t x )
- ngoài ra, người dùng mã hóa i i dưới pk p k và một danh tính khác j j , tức là người dùng tính toán thêm ct_2 \leftarrow Shutter.Encrypt(pk, j, i ) c t 2 ← Shutter.Encrypt ( pk , j , i ) . Enc r y p t ( p k , j , i )
Sau đó, người dùng gửi cả hai bản mã hóa (ct_1, ct_2) ( c t 1 , c t 2 ) cùng với danh tính j j đến mempool được mã hóa. Lưu ý rằng nếu không biết danh tính i i , Keypers không thể giải mã ct_1 c t 1 và do đó họ không thể học giao dịch tx t x . Cuối cùng, người đề xuất cam kết bao gồm tx t x ở đầu Block của mình bằng cách gửi chữ ký BLS trên danh tính j j , tức là \sigma = H(j)^{sk} σ = H ( j ) s k . Chữ ký này về cơ bản là khóa bí mật danh tính cho danh tính i i và khóa công khai pk p k , tức là, nó có thể được sử dụng để giải mã danh tính i i bằng cách tính i \leftarrow Shutter.Decrypt(\sigma, ct_2) i ← Shutter.Decrypt ( \sigma, ct_2) i ← Shut t t e r . Dec r y p t ( σ , c t 2 ) . Bây giờ danh tính i i đã được biết, Keypers có thể giải mã giao dịch tx t x bằng cách đầu tiên là suy ra khóa bí mật danh tính sk_i s k i và sau đó tính toán tx \leftarrow Shutter.Decrypt ( sk_i , ct_1 ) t x ← Shutter.Decrypt ( sk_i , ct_1 ) t x ← Shutter.Decrypt ( sk i , ct 1 ) .
Miễn là người đề xuất và Keypers không thông đồng, về mặt kỹ thuật, Keypers không thể giải mã tx t x trước khi người đề xuất cam kết đưa nó vào. Lưu ý rằng việc giải mã tx t x sau khi người đề xuất đã gửi cam kết của mình không gây hại vì giao dịch đã được cam kết đưa vào đầu Block.
Thảo luận và hạn chế của phương pháp tiếp cận
Ngăn chặn sự thông đồng giữa Keypers và Proposer. Cơ chế được đề xuất làm giảm tác động có hại của sự thông đồng trong ủy ban Threshold bằng cách đảm bảo rằng việc giải mã chỉ có thể thực hiện được khi người đề xuất Block hiện tại cam kết đưa một bản mã đã giải mã vào đầu Block tiếp theo. Tuy nhiên, như đã đề cập ở trên, cách tiếp cận này không giải quyết được sự thông đồng tiềm ẩn giữa Keypers và người đề xuất Block . Để ngăn chặn hiệu quả sự thông đồng như vậy, điều cần thiết là phải đưa ra các hình phạt kinh tế cho cả ủy ban Keypers và người đề xuất trong trường hợp có hành vi sai trái.
Mã hóa cho nhiều người đề xuất. Một hạn chế khác là ở dạng hiện tại, người dùng luôn mã hóa giao dịch của mình cho một người đề xuất cụ thể . Nếu người đề xuất này không cam kết thực hiện giao dịch, giao dịch sẽ không được đưa vào, về cơ bản là buộc người dùng phải gửi lại giao dịch. Một biện pháp đối phó rõ ràng là để người dùng mã hóa cho nhiều người đề xuất để tăng khả năng một trong số họ thực sự cam kết đưa giao dịch vào. Tuy nhiên, điều này đi kèm với hai nhược điểm: (1) nó làm tăng kích thước bản mã theo tuyến tính theo số lượng người đề xuất và (2) càng có nhiều người đề xuất tham gia, thì khả năng một trong số họ thông đồng với Keypers càng cao. Nhược điểm đầu tiên có thể được giải quyết bằng cách sử dụng một lược đồ mã hóa nhiều người nhận . Mặt khác, nhược điểm thứ hai có vẻ là sự đánh đổi giữa tính bảo mật và sự tiện lợi: người dùng càng chọn nhiều người đề xuất, thì khả năng một trong số họ thông đồng với Keypers càng cao, nhưng khả năng người dùng phải gửi lại giao dịch càng thấp.
Đảm bảo Keypers phát hành khóa giải mã. Nếu chúng ta cho rằng tất cả Keypers đều hành động có ác ý và thông đồng với nhau, thì có khả năng họ từ chối phát hành khóa giải mã, do đó khiến hệ thống dừng lại. Một giải pháp để tránh điều này là để Keypers Stake một số tiền và để một ủy ban gồm những người chứng thực xác nhận xem Keypers có phát hành khóa giải mã hay không cho một cam kết đề xuất hợp lệ. Nếu Keypers không phát hành khóa, họ có nguy cơ bị cắt giảm Stake .
Tại sao chúng ta cần Keypers nếu người dùng có thể mã hóa trực tiếp cho người đề xuất? Người ta có thể tự hỏi, tại sao chúng ta lại cần một ủy ban Keypers nếu các cam kết của người đề xuất cho phép người dùng mã hóa giao dịch của họ trực tiếp cho người đề xuất. Lý do là nếu không có ủy ban, một người đề xuất có ác ý có thể chỉ giải mã cục bộ các giao dịch mà không cần công khai cam kết bao gồm chúng, do đó về cơ bản mở ra cánh cửa cho các cuộc tấn công MEV một lần nữa. Chỉ khi có một bên độc lập khác (trong trường hợp của chúng ta là một ủy ban) được yêu cầu giải mã giao dịch, chúng ta mới có thể buộc người đề xuất công khai cam kết của mình và do đó đảm bảo rằng người đề xuất phải chịu trách nhiệm.
Sắp xếp các giao dịch được mã hóa ở đầu Block. Trong suốt bài đăng này, chúng tôi đã giả định rằng khi người đề xuất cam kết thực hiện một giao dịch được mã hóa, giao dịch được giải mã tương ứng phải xuất hiện ở đầu Block. Nhưng điều gì xảy ra nếu người đề xuất cam kết thực hiện nhiều giao dịch? Trong trường hợp đó, không có thứ tự rõ ràng nào cho các giao dịch này.
Một giải pháp đơn giản là người đề xuất sẽ bao gồm một bộ đếm tăng dần với mỗi cam kết. Các giao dịch sau đó có thể được sắp xếp theo bộ đếm này và Keypers sẽ chỉ giải mã chúng theo trình tự đó.
Chúng tôi lưu ý rằng vấn đề sắp xếp này không phát sinh khi sử dụng danh sách bao gồm thay vì cam kết của người đề xuất, vì danh sách bao gồm có thể xác định rõ ràng thứ tự của các giao dịch được mã hóa trong Block.
Tổng quát hóa cách tiếp cận
Có hai cách để chúng ta có thể khái quát hóa phương pháp tiếp cận, cụ thể là liên quan đến mempool được mã hóa và liên quan đến cơ chế xác định vị trí của văn bản mã hóa.
Tổng quát hóa mempool được mã hóa. Để đơn giản, chúng tôi đã mô tả cơ chế chống thông đồng đối với mempool được mã hóa Shutter. Tuy nhiên, ý tưởng cốt lõi không phụ thuộc vào Shutter. Hiểu biết chính là cam kết của người đề xuất dưới dạng chữ ký BLS có thể đóng vai trò là khóa giải mã trong lược đồ Boneh-Franklin IBE. Điều này có thể được kết hợp với bất kỳ mempool được mã hóa (Threshold) nào bằng cách sử dụng các cam kết của người đề xuất. Hãy xem xét thiết kế tổng quát hơn sau đây: Giả sử pk_C p k C là khóa công khai của ủy ban vận hành mempool được mã hóa (Threshold) và giả sử pk_P p k P là Khóa công khai. Sau đó, người dùng có thể mã hóa giao dịch của mình trước tiên vào mempool được mã hóa (tức là theo pk_C p k C ) rồi mã hóa bản mã kết quả cho người đề xuất thông qua lược đồ Boneh-Frankling IBE theo pk_P p k P. Về cơ bản, điều này tạo ra một giao dịch được mã hóa kép mà trước tiên người đề xuất phải giải mã (thông qua cam kết) và sau đó ủy ban Threshold có thể giải mã giao dịch.
Tổng quát hóa cơ chế “sửa lỗi”. Chúng tôi đã mô tả cơ chế chống thông đồng cho một mempool được mã hóa sử dụng các cam kết của người đề xuất để sửa lỗi vị trí của một bản mã trong một Block. Tuy nhiên, ở cấp độ trừu tượng hơn, cơ chế này không phụ thuộc vào cách sửa lỗi vị trí chính xác miễn là việc sửa lỗi được thực hiện dưới dạng chữ ký BLS có thể đóng vai trò là khóa giải mã. Ví dụ, đối với FOCIL, danh sách bao gồm có thể được ký bằng chữ ký BLS cho phép giải mã tất cả các giao dịch trong danh sách bao gồm. Tuy nhiên, việc tích hợp chính xác một cơ chế như FOCIL với giải pháp chống thông đồng của chúng tôi vẫn là một nhiệm vụ thú vị cho công việc trong tương lai.
Phần kết luận
Giải pháp được mô tả trong bài đăng này trình bày một cơ chế chống thông đồng thực tế và hiệu quả cho các mempool được mã hóa Threshold , thậm chí có thể được khái quát hóa cho bất kỳ loại mempool được mã hóa nào. Bằng cách liên kết giải mã với các cam kết của người đề xuất (và thậm chí có thể là danh sách bao gồm), cơ chế này làm giảm đáng kể sự tin tưởng vào nhà cung cấp mempool được mã hóa mà không yêu cầu bất kỳ chi phí truyền thông hoặc tính toán lớn nào.
