Giao dịch khung và ba cánh cửa dẫn đến quyền riêng tư

fallout_comic_strong_compress 1200×800 168 KB

Bài viết này xem EIP-8141 như một điều đã được chứng minh mà không tranh luận ủng hộ hay phản đối nó. Mục tiêu là để chỉ ra cách các giao dịch khung có thể cải thiện các giao thức bảo mật, và những gì cần thay đổi trong các quy tắc mempool công khai và việc thực thi danh sách bao gồm để điều đó thực sự hoạt động.
Xin chân thành cảm ơn Carlos , Ben , Milos và Matt vì những phản hồi!

Giao dịch khung ( EIP-8141 ) hứa hẹn sẽ loại bỏ các trung gian chuyển tiếp khỏi các giao thức bảo mật. Tuy nhiên, các quy tắc quản lý việc chấp nhận mempool công khai, việc thực thi FOCIL và lộ trình không trạng thái đều vạch ra những ranh giới khác nhau về các giao dịch mà chúng hỗ trợ. Bài viết này phân tích nơi các ranh giới đó giao nhau và nơi chúng xung đột, đặc biệt là đối với các giao dịch bảo vệ quyền riêng tư.

Cách giao dịch khung loại bỏ các trung gian

Các giao thức bảo mật như Tornado Cash và Railgun phá vỡ liên kết trên chuỗi giữa người gửi và người rút tiền bằng cách sử dụng zk-SNARK. Việc rút tiền chứng minh người rút tiền đã biết về một cam kết hợp lệ trong cây Merkle mà không tiết lộ cam kết nào. Vấn đề là: địa chỉ của người rút tiền là địa chỉ mới và không có ETH để trả phí gas. Hiện nay, các trung gian (các bên thứ ba tập trung, có thể kiểm duyệt, thường hoạt động ngoại tuyến khi cần thiết) lấp đầy khoảng trống này bằng cách tài trợ các giao dịch rút tiền.

EIP-8141 thay đổi cơ chế kinh tế. Khung VERIFY của một giao dịch frame chạy như một STATICCALL : chỉ đọc, không thay đổi trạng thái. Nếu VERIFY bị đảo ngược trước khi thanh toán được chấp thuận, giao dịch sẽ không hợp lệ ở cấp độ giao thức, không bao giờ được đưa vào khối và không ai phải trả phí gas. Việc rút tiền riêng tư trở thành:

• Khung VERIFY (với tx.sender = pool , do đó khung nhắm mục tiêu vào bộ nhớ riêng của pool): đọc publicInputs từ calldata của khung SENDER , xác minh gốc Merkle so với lịch sử được lưu trữ của pool ( SLOAD ), xác nhận rằng nullifier chưa được sử dụng ( SLOAD ), và thực hiện kiểm tra ghép nối Groth16 đối với các publicInputs đó. Nếu mọi thứ đều đạt, hãy gọi APPROVE .
• Khung SENDER : đánh dấu lệnh hủy là đã sử dụng, chuyển số tiền ròng cho người nhận và ghi có khoản phí vào tài khoản của nhà tài trợ trong nhóm.

Điều quan trọng là, phí giao dịch không còn cần phải đến từ một nhà tài trợ bên ngoài. Chính việc rút tiền có thể chi trả cho việc thực hiện giao dịch: khung SENDER có thể chuyển một phần tiền rút ra để trang trải phí gas, loại bỏ nhu cầu về người gửi được cấp vốn trước hoặc bên trung gian thứ ba. Phần tiền của nhà tài trợ vẫn nằm trong nhóm dưới dạng tín dụng nội bộ, có thể được yêu cầu sau này, do đó việc rút tiền chỉ phát sinh một lần chuyển khoản đi thay vì hai lần.

Rủi ro của nhà tài trợ bằng không đối với các bằng chứng không hợp lệ ( VERIFY hoàn tác, giao dịch bị hủy) và bằng không đối với các bằng chứng được phát lại (bộ vô hiệu hóa đã được đánh dấu, VERIFY hoàn tác). Không cần sự tin tưởng, không cần cơ sở hạ tầng chuyển tiếp và không có bề mặt kiểm duyệt bổ sung.

ba cánh cửa dẫn đến sự hòa nhập

Con đường chống kiểm duyệt của một giao dịch khung tập trung vào quyền riêng tư phải đi qua ba cánh cửa độc lập, mỗi cánh cửa đều có những ràng buộc riêng:

Cổng 1: Lối vào bể bơi công cộng

Các quy tắc mempool của EIP-8141, dựa trên ERC-7562 nhưng loại bỏ hoàn toàn cơ chế đặt cọc và uy tín, định nghĩa những gì có thể lan truyền qua mạng P2P công cộng:

• Tiền tố xác thực phải khớp với một mẫu được nhận dạng ( self_verify hoặc only_verify + pay , tùy chọn có thể đứng trước bởi deploy )
• SLOAD chỉ giới hạn trong bộ nhớ tx.sender .
• Tổng lượng khí VERIFY được giới hạn ở MAX_VERIFY_GAS (100.000)
• Các mã lệnh bị cấm: TIMESTAMP , NUMBER , BLOCKHASH , BALANCE , SELFBALANCE , SSTORE , TLOAD , TSTORE , v.v.
• Người trả tiền chính thức được xác định bằng mã băm thời gian thực chính xác, với các giao dịch rút tiền được khóa theo thời gian và theo dõi số dư đang chờ xử lý ở phía máy chủ.
• Các chủ nợ không chính thống bị giới hạn ở MAX_PENDING_TXS_USING_NON_CANONICAL_PAYMASTER (1) giao dịch đang chờ xử lý mỗi chủ nợ

Bất cứ thứ gì vi phạm các quy tắc này sẽ bị loại bỏ khỏi mempool công cộng nhưng vẫn có thể đến được với người xây dựng thông qua alt-mempool hoặc các kênh riêng tư.

cổng 2: thực thi tiêu điểm

FOCIL đảm bảo việc đưa giao dịch vào: 16 thành viên ủy ban IL mỗi vị trí xây dựng danh sách đưa vào dựa trên quan điểm của họ về các giao dịch đang chờ xử lý. Người chứng thực chỉ bỏ phiếu cho các khối bao gồm các giao dịch IL (hoặc chứng minh tính không hợp lệ của chúng ở giai đoạn sau).

Đối với EOA, kiểm tra bỏ sót của FOCIL là một thao tác tra cứu nonce / balance đơn giản dựa trên post-state thực thi. Đối với FrameTxs , kiểm tra bỏ sót yêu cầu phát lại tiền tố VERIFY . Không có proxy đơn giản nào vì tính hợp lệ của giao dịch phụ thuộc vào quá trình thực thi, chứ không chỉ trạng thái của người gửi. Đề xuất FOCIL-frame-txs định nghĩa tính đủ điều kiện thông qua năm ràng buộc:

1. Thứ tự tiền tố xác thực : Khung VERIFY phải đứng trước khung DEFAULT / SENDER
2. Lượng gas VERIFY giới hạn trên mỗi giao dịch : verify_gas(tx) <= MAX_VERIFY_GAS_PER_FRAMETX (100,000)
3. Ngân sách VERIFY trên mỗi IL : lượng khí VERIFY lũy trên toàn bộ IL được giới hạn ở MAX_VERIFY_GAS_PER_INCLUSION_LIST (250.000)
4. Kiểm tra tính hợp lệ cơ bản của giao dịch : chain_id , phí, không có dữ liệu nhị phân (blobs).
5. Quyền truy cập trạng thái bị giới hạn : VERIFY chỉ có thể đọc trạng thái tài khoản tx.sender và người trả tiền ( balance , nonce , mã) cộng với N vị trí lưu trữ đầu tiên của chúng ( N = 2-4), phù hợp với bộ nhớ đệm AA-VOPS . Việc đọc dữ liệu từ bất kỳ hợp đồng nào khác sẽ khiến giao dịch không hợp lệ.

FrameTxs không đáp ứng bất kỳ ràng buộc nào đều được miễn trừ khỏi việc thực thi FOCIL: việc thiếu sót này không thể bị coi là lỗi của nhà sản xuất.

cổng 3: khả năng xác thực nút

Thuật ngữ:
PS = Tình trạng không quốc tịch một phần: nắm giữ một số quốc tịch, chứ không phải toàn bộ.
VOPS = Validity-Only PS: lưu trữ đủ trạng thái để xác thực các giao dịch từ EOA.
AA-VOPS = VOPS + một vài khe lưu trữ cho mỗi tài khoản

Sau ZKEVM, các node sẽ không cần phải lưu giữ toàn bộ trạng thái. Ví dụ, các node VOPS chỉ lưu trữ khoảng 8.4 GB ( nonce , balance , codeHash cho mỗi tài khoản). AA-VOPS mở rộng điều này bằng cách duy trì N vị trí lưu trữ đầu tiên cho mỗi tài khoản trong cây trie (do đó một số vị trí tx.sender và payer có sẵn cục bộ để phát lại VERIFY ). Các node có trạng thái một phần (PS) cũng theo dõi bộ nhớ cho các hợp đồng được chọn. Loại node xác định các khung VERIFY mà nó có thể phát lại cục bộ, và do đó, các lớp giao dịch nào nó có thể chấp nhận vào mempool của mình và đưa vào danh sách bao gồm giống như FOCIL:

Một nút không thể xác thực loại giao dịch thì không thể lưu giữ nó trong mempool của mình và không nên đưa nó vào IL. Khả năng chống kiểm duyệt đối với lớp này giảm đi theo tỷ lệ các trình xác thực có khả năng.

Xem Giao dịch khung thông qua lăng kính không trạng thái để có phân tích chi tiết về các loại nút nào có thể hỗ trợ các chiến lược mempool EIP-8141 nào.

Vì sao các giao dịch bảo mật thất bại ở cả ba khía cạnh?

Việc thu hồi quyền riêng tư không vượt qua được cả ba bước kiểm tra theo các thông số mặc định:

Cổng 1 (bộ nhớ công cộng) : Với tx.sender = pool , các thao tác SLOAD của khung VERIFY trên lịch sử gốc Merkle của pool và ánh xạ nullifierHashes đáp ứng hạn chế lưu trữ chỉ dành cho tx.sender , nhưng kiểm tra ghép nối Groth16 vượt quá giới hạn 100k MAX_VERIFY_GAS được định nghĩa trong các quy tắc theo dõi xác thực của EIP-8141 . Bị từ chối.

Cổng 2 (Điều kiện đủ điều kiện FOCIL) : Việc kiểm tra ghép cặp Groth16 vượt quá ngân sách phí gas VERIFY 100k mỗi giao dịch. Ngay cả khi tx.sender = pool điều chỉnh dung lượng lưu trữ của pool phù hợp với quy tắc truy cập trạng thái giới hạn, chỉ riêng giới hạn phí gas cũng đủ để loại bỏ giao dịch. Được miễn thực thi.

Cổng 3 (khả năng của nút) : Các nút VOPS và AA-VOPS không lưu trữ hợp đồng nhóm. Chỉ các nút PS theo dõi nhóm hoặc các nút đầy đủ mới có thể xác thực.

Do đó, các giao dịch liên quan đến quyền riêng tư bị loại trừ khỏi mọi lộ trình mặc định để chống lại kiểm duyệt. Những giao dịch cần được chống lại kiểm duyệt nhất lại là những giao dịch mà thiết kế hiện tại không thể bảo vệ được.

Điều này không phải là không thể tránh khỏi. Khoảng cách này bắt nguồn từ cách FOCIL thực thi việc đưa FrameTxs vào, và đề xuất FOCIL-frame-txs đưa ra hai cách tiếp cận với những hệ quả rất khác nhau đối với những gì có thể được thực thi. Việc lựa chọn giữa hai cách tiếp cận này sẽ quyết định liệu FrameTxs liên quan đến quyền riêng tư có khả năng chống lại kiểm duyệt hay không.

thực thi trọng tâm: hai cách tiếp cận

Cả hai phương pháp đều giải quyết cùng một vấn đề: làm thế nào để các nhà phát triển chứng minh họ không kiểm duyệt các IL FrameTx đủ điều kiện, và làm thế nào để người chứng thực xác minh những tuyên bố đó.

phương pháp vòng lặp thêm

Phương pháp mặc định là trình xây dựng sẽ lần lượt thêm FrameTxs IL đủ điều kiện bị loại trừ vào khối cho đến khi không còn FrameTx bị bỏ sót nào hợp lệ ở post-state cùng. Chi phí là O(k²) theo số lượng FrameTxs bị loại trừ. Chi phí xây dựng bậc hai này buộc các tham số phải được đặt ở mức thận trọng: MAX_VERIFY_GAS_PER_FRAMETX ở 100_000 và MAX_VERIFY_GAS_PER_INCLUSION_LIST ở 250_000 .

Giả sử ủy ban IL đối địch chiếm 25% (4 trong số 16 thành viên, diễn ra khoảng một lần mỗi tháng với tỷ lệ cổ phần 1%) và các giao dịch ~100 byte: mỗi IL có thể chứa ~81 giao dịch trong MAX_BYTES_PER_INCLUSION_LIST ( 8 KiB ), nhưng ngân sách gas VERIFY cho mỗi IL chỉ cho phép 2 FrameTxs với MAX_VERIFY_GAS_PER_FRAMETX gas cho mỗi IL ( 2 * 100k = 200k <= 250k ). 4 IL độc hại tạo ra k=8 FrameTxs không hợp lệ. Vòng lặp thêm chạy k(k+1)/2 = 36 phát lại VERIFY : 3.6M gas (~6% của khối). Công việc của người kiểm thử: 4 * 250k = 1M gas (~1,7%). Chi phí phát sinh không lớn, nhưng các tham số này khiến FOCIL gần như vô dụng đối với FrameTxs : MAX_VERIFY_GAS_PER_FRAMETX ở 100k loại trừ các bằng chứng Groth16, chữ ký PQ và bất kỳ logic xác thực nào không tầm thường, trong khi MAX_VERIFY_GAS_PER_INCLUSION_LIST ở mức 250k giới hạn mỗi IL chỉ ở mức 2 FrameTxs đầy đủ gas. Một IL chỉ có chỗ cho 2 FrameTxs có thể thực thi hầu như không thực thi được tính trừu tượng của tài khoản.

phương pháp chỉ số xác thực

Quá trình tiếp theo loại bỏ vòng lặp thêm. Thay vào đó, trình xây dựng sẽ bỏ qua mỗi giao dịch bị loại trừ bằng cách công bố một cặp (tx_hash, claimed_index) khai báo chỉ mục khối mà tại đó giao dịch trở nên không hợp lệ. Các bên xác nhận sẽ xây dựng lại trạng thái tại claimed_index bằng cách sử dụng Danh sách truy cập khối ( EIP-7928 ) và phát lại tiền tố VERIFY ở đó. Nếu VERIFY thành công, trình xây dựng đã nói dối và khối không đáp ứng các điều kiện IL. Chi phí của trình xây dựng giảm từ O(k²) xuống O(k) . Sự đánh đổi là độ phức tạp của giao thức tăng lên: các yêu cầu chỉ mục là một hiện vật mạng bổ sung, engine_newPayload sẽ cần chấp nhận chúng cùng với các giao dịch IL và EL sẽ cần xác thực chúng một cách phù hợp.

Khi chi phí xây dựng không còn là nút thắt cổ chai, MAX_VERIFY_GAS_PER_INCLUSION_LIST có thể tăng lên 2^20 (~1 triệu gas), và giới hạn trên mỗi giao dịch trở nên ít quan trọng hơn vì mỗi giao dịch bị loại trừ được xác thực một lần tại claimed_index của nó thay vì lặp đi lặp lại. Mức 2^20 trên mỗi IL sẽ đủ cao để các giao dịch từ các giao thức bảo mật được hưởng lợi từ các đảm bảo chống kiểm duyệt của FOCIL.

Cùng kịch bản đối thủ 25%: mỗi IL hiện phân bổ ngân sách cho tối đa 10 FrameTxs với chi phí 100k mỗi FrameTx ( 10 * 100k = 1M <= 2^20 ). Bốn IL độc hại * 10 = 40 FrameTxs bị loại trừ. Chi phí xây dựng là tuyến tính: 40 * 100k = 4M gas (~6,7% của khối). Chi phí kiểm tra: 4 * 2^20 ≈ 4.2M gas (~7%). Trường hợp xấu nhất trên tất cả 16 IL: 16 * 2^20 = 2^24 ≈ 16.8M gas (~28%). Việc tăng ngân sách mỗi IL lên khoảng 4 lần loại bỏ hoàn toàn hiện tượng bùng nổ bậc hai của trình xây dựng.

khả năng của nút là yếu tố hạn chế

Phương pháp chỉ mục tạo ra sự tách biệt giữa các quy tắc mempool công khai và việc thực thi FOCIL. Các quy tắc mempool công khai phải nghiêm ngặt vì các giao dịch có thể cần được xác thực lại sau mỗi khối, do đó sự phụ thuộc trạng thái phải nhỏ và mang tính xác định. FOCIL theo phương pháp chỉ mục xác thực sẽ phát lại VERIFY chính xác một lần tại một claimed_index cố định. Không có chi phí bảo trì liên tục, điều này cho phép nó có quyền truy cập trạng thái rộng hơn và ngân sách gas cao hơn. Mặt khác: quá trình xác thực FOCIL nằm trên đường dẫn quan trọng của trình xác thực (trong thời hạn chứng thực t=4s ), trong khi quá trình xác thực mempool chạy không đồng bộ. MAX_VERIFY_GAS_PER_INCLUSION_LIST cao hơn sẽ trực tiếp làm giảm ngân sách thời gian của trình xác thực.

Điều này có nghĩa là các thành viên ủy ban IL có thể lấy các giao dịch từ các alt-mempool (bao gồm cả các mempool tập trung vào quyền riêng tư) và đưa chúng vào IL của họ, ngay cả khi mempool công cộng mặc định không chứa chúng. Nhưng để điều này hoạt động đối với các giao dịch riêng tư, quy tắc truy cập trạng thái bị giới hạn (chỉ đọc được ở tài khoản tx.sender và payer) cần được nới lỏng. Và các nút thực thi việc đưa vào cần trạng thái để thực sự xác thực các giao dịch này.

AA-VOPS không thể khắc phục được vấn đề này. Nó lưu trữ N khe nhớ cho mỗi tài khoản, đủ cho việc xác thực ví đơn giản (khóa chủ sở hữu, nonce) nhưng không đủ cho các giao thức bảo mật. Các khung VERIFY liên quan đến giao dịch bảo mật đọc bộ nhớ hợp đồng nhóm (bộ đệm vòng gốc, ánh xạ nullifier), chứ không phải bộ nhớ người gửi. Không có giá trị nào của N khắc phục được điều này: các thao tác đọc nhắm mục tiêu đến một hợp đồng hoàn toàn khác. Ngay cả khi AA-VOPS lưu trữ N khe nhớ cho mọi hợp đồng, điều đó cũng không giúp ích gì: ánh xạ nullifier được khóa bằng hàm băm, do đó các khe nhớ được truy cập là không thể đoán trước và nằm rải rác trên cây lưu trữ.

một nhóm riêng tư chính thống

Giải pháp thiết thực nhất là một mô hình nhóm chuẩn , tương tự như người quản lý thanh toán chuẩn . Một hợp đồng chuẩn, được nhận dạng bằng mã băm, có thể đóng vai trò là một sổ đăng ký chung cho nhiều giao thức bảo mật: lưu trữ các gốc Merkle chỉ được thêm vào cho mỗi nhóm và các tập hợp nullifier trong một bố cục thống nhất, có thể kiểm toán được. Được thiết kế đúng cách, nhóm như vậy an toàn cho cả mempool công khai và việc thực thi FOCIL: các khung VERIFY nhắm mục tiêu vào hợp đồng này đọc chính xác hai khe lưu trữ: acceptedRoots[R] và nullifierHashes[h] , cả hai đều ở các khóa có thể suy ra từ calldata. Mô hình truy cập bị giới hạn, có thể dự đoán được và đơn điệu : mỗi khe VERIFY chỉ đọc các chuyển đổi false → true . Thay vì yêu cầu các nút theo dõi N hợp đồng nhóm riêng biệt, một sổ đăng ký chuẩn giảm vấn đề xuống còn một địa chỉ được biết đến với bố cục lưu trữ đã biết, làm cho trạng thái một phần để bảo mật trở nên khả thi với chi phí tối thiểu.

Trạng thái đơn điệu là yếu tố giúp thiết kế này chống lại việc bị vô hiệu hóa hàng loạt. Các giao thức bảo mật hiện nay sử dụng bộ đệm vòng xoay của các gốc Merkle gần đây, loại bỏ mục nhập cũ nhất trên mỗi lần gửi tiền. Theo EIP-8141, việc loại bỏ đó là một vectơ vô hiệu hóa hàng loạt: một lần gửi tiền (hoặc tấn công spam) có thể xoay vòng một gốc mà hàng chục lần rút tiền được tài trợ đang chờ xử lý phụ thuộc vào, loại bỏ tất cả chúng khỏi mempool cùng một lúc. Việc thay thế bộ đệm vòng bằng ánh xạ acceptedRoots chỉ thêm vào sẽ loại bỏ hoàn toàn vectơ này. Bằng chứng rút tiền được tạo dựa trên bất kỳ gốc nào trong quá khứ vẫn hợp lệ mãi mãi; tập hợp nullifier đã ngăn chặn việc chi tiêu kép, vì vậy việc chấp nhận các gốc cũ là an toàn về mặt mật mã. Thay đổi trạng thái duy nhất có thể vô hiệu hóa một lần rút tiền đang chờ xử lý là ghi vào khe nullifierHashes[h] cụ thể của nó , điều này yêu cầu phải có bí mật của ghi chú. Điều đó áp dụng cho từng giao dịch và nhắm mục tiêu riêng lẻ, không bao giờ là hàng loạt.

Một chi tiết triển khai cần lưu ý: các bộ đệm vòng cho các gốc Merkle, thường được sử dụng trong các giao thức bảo mật hiện nay, phải được thay thế bằng các ánh xạ chỉ thêm vào để tránh việc hủy bỏ hàng loạt. Về kích thước, điều đó không thành vấn đề: ví dụ, hợp đồng Tornado Cash được sử dụng phổ biến nhất (pool 1-ETH) có 81.881 khoản tiền gửi. Điều đó sẽ tương đương khoảng 10,5 MB dữ liệu cặp khóa-giá trị thô (81.881 mục trong acceptedRoots và nullifierHashes , ~64 byte mỗi mục), hoặc khoảng 25-40 MB sau khi được lưu trữ trong cây trạng thái. Một nút PS theo dõi pool này chỉ cam kết thêm dưới 50 MB trạng thái, con số này không đáng kể so với mức cơ bản ~8,4 GB của VOPS.

Với 16 thành viên ủy ban IL cho mỗi vị trí, FOCIL chỉ cần 1 trong 16 thành viên trung thực để đảm bảo được đưa vào. Nhưng “trung thực” ở đây cũng có nghĩa là “có khả năng”: một thành viên muốn đưa vào giao dịch bảo mật nhưng lại vận hành một nút VOPS hoặc AA-VOPS thì đơn giản là không thể xác thực nó. Giả định về sự trung thực 1 trong 16 trở thành giả định về khả năng 1 trong 16. Các nút PS giải quyết vấn đề này. Chúng không cần toàn bộ trạng thái, chỉ cần các hợp đồng mà chúng quan tâm. Một nút PS theo dõi một nhóm bảo mật chuẩn chỉ thêm tối đa vài MB. Chi phí cơ sở hạ tầng là không đáng kể; câu hỏi đặt ra là liệu có đủ người xác thực lựa chọn làm điều đó hay không.

Một giải pháp thay thế cho việc chuẩn hóa các nhóm bảo mật là cho phép người gửi giao dịch đính kèm trạng thái (lưu trữ) cần thiết cùng với bằng chứng Merkle so với gốc trạng thái mới nhất. Cách tiếp cận này có một số nhược điểm, quan trọng nhất là vì các bằng chứng này trở nên không hợp lệ sau mỗi khối và phải được tính toán lại liên tục.

những thay đổi được đề xuất

1. Mở rộng ngoại lệ hợp đồng chuẩn cho các nhóm riêng tư. EIP-8141 đã chấp nhận các chủ thể thanh toán chuẩn bằng cách khớp mã băm thời gian chạy, miễn trừ chúng khỏi các quy tắc nhóm bộ nhớ công khai nghiêm ngặt vì sự phụ thuộc trạng thái của chúng được biết là an toàn.
2. Tăng giới hạn gas VERIFY trên mỗi giao dịch cho các khung hợp đồng chuẩn. MAX_VERIFY_GAS = 100_000 là không đủ cho Groth16 (~250k). Các hợp đồng chuẩn có đường dẫn xác minh cố định, vì vậy chi phí VERIFY trong trường hợp xấu nhất là một thuộc tính tĩnh của hàm băm mã. Một bằng chứng không hợp lệ sẽ tiêu tốn cùng một lượng gas như một bằng chứng hợp lệ và bị loại bỏ, không có sự khuếch đại nào. Giữ mức 100k cho các khung chung; cho phép ví dụ ~400k cho các khung hợp đồng chuẩn, để lại đủ chỗ, và giới hạn số lượng của chúng trong mempool.
3. Áp dụng cơ chế thực thi FOCIL chỉ số xác thực , chấp nhận độ phức tạp của giao thức bổ sung (ánh xạ (tx_hash, claimed_index) ) để loại bỏ chi phí xây dựng bậc hai buộc phải sử dụng ngân sách gas thận trọng cho FrameTx
4. Tăng MAX_VERIFY_GAS_PER_INCLUSION_LIST lên 2^20 (=1M), cho phép các giao dịch riêng lẻ với lượng gas VERIFY cao hơn (Groth16, chữ ký PQ) nằm trong ngân sách cho mỗi IL.
5. Nới lỏng quy tắc truy cập trạng thái giới hạn cho các hợp đồng nhóm bảo mật chuẩn , cho phép các thành viên ủy ban IL lấy các giao dịch này từ các nhóm bộ nhớ thay thế và đảm bảo việc đưa chúng vào có thể được thực thi bởi những người chứng thực chạy các nút PS theo dõi các hợp đồng này.

Nhìn chung, những điều này mang lại cho FrameTxs bảo mật một con đường khả thi để chống lại kiểm duyệt: sự lan truyền mempool công khai theo ngoại lệ hợp đồng chuẩn, sự bao gồm bởi các thành viên IL có khả năng PS và việc thực thi FOCIL thông qua phương pháp chỉ số xác thực, mà không làm suy yếu khả năng chống lại DoS đối với FrameTxs không chuẩn.

Những lập luận tương tự cũng áp dụng cho các giao dịch hậu lượng tử . Chữ ký PQ rất lớn và tốn kém để xác minh, và 100.000 gas VERIFY không đủ để trang trải chi phí. Giống như các giao thức bảo mật, các giao dịch PQ sẽ cần được miễn trừ khỏi giới hạn cố định, bằng cách chuẩn hóa các hợp đồng xác minh hoặc bằng cách thêm các biên dịch trước chuẩn hóa.

Các quy tắc mempool công khai hiện tại cho FrameTxs , VOPS và AA-VOPS quá cứng nhắc đối với các giao thức bảo mật. Việc chuẩn hóa các nhóm bảo mật sẽ thay đổi điều đó. Việc nhận dạng chúng bằng mã băm cho phép mempool công khai xác thực an toàn các khung VERIFY của chúng, và các nút PS theo dõi một tập hợp nhỏ các hợp đồng có giá trị cao (các nhóm bảo mật, các bên thanh toán chuẩn) có thể xây dựng danh sách bao gồm cho chúng. Điều này mang lại khả năng chống kiểm duyệt cho các giao dịch cần thiết nhất.

phụ lục

Tại sao các mempool thay thế lại thất bại

• Phân mảnh không tạo nên sự thống nhất : Mỗi giao dịch cần xác thực chặt chẽ hơn (quyền riêng tư, chất lượng, v.v.) có thể phải tạo ra nhóm bộ nhớ thay thế riêng. Người vận hành nút chọn ra những người thắng cuộc, số lượng người dùng hỗ trợ những người đó giảm dần, và nhóm bộ nhớ thay thế yếu nhất trở thành vectơ kiểm duyệt cho bất cứ thứ gì phụ thuộc vào nó. Nếu không có các cơ chế khuyến khích tích hợp, các nhóm bộ nhớ thay thế chỉ có thể mở rộng quy mô bằng cách yêu cầu các tình nguyện viên vận hành chúng một cách vị tha, thậm chí có thể yêu cầu những người đó phải mua phần cứng mạnh mẽ và đắt tiền hơn.
• Sự sụp đổ của tập hợp ẩn danh : Tập hợp ẩn danh bị suy giảm từ "tất cả các nút Ethereum" xuống "các nút hỗ trợ mempool riêng tư", và các kết nối ngang hàng bị rò rỉ ở lớp mạng.
• Dễ dàng bị kiểm duyệt ở lớp mạng : Các nút khởi động, bản ghi DNS và danh sách ngang hàng cho một alt-mempool chuyên dụng là những điểm nghẽn mà nhà cung cấp dịch vụ Internet hoặc quốc gia có thể loại bỏ chỉ bằng một quy tắc. Mempool công cộng khó bị kiểm duyệt vì nó chịu tải cho toàn bộ mạng; alt-mempool thì không. Lưu lượng truy cập riêng tư cuối cùng lại nằm trên cơ sở hạ tầng có cấu trúc dễ bị vô hiệu hóa hơn so với bộ chuyển tiếp mà nó thay thế.
• Giả định "1/16" của focil bị phá vỡ : Việc đưa vào kịp thời chỉ được đảm bảo nếu ít nhất một thành viên ủy ban IL có kết nối ngang hàng với alt-mempool và có thể xác thực giao dịch. Giả định "1/16 trung thực" trở thành "1/16 trung thực, đã đăng ký và có khả năng", đây là một sự đảm bảo yếu hơn nhiều so với những gì EIP-7805 hứa hẹn. Điều này đặc biệt có vấn đề nếu các trình xây dựng IL được quảng cáo là các nút phần cứng thấp.
• Bộ chuyển tiếp không biến mất, nó chỉ di chuyển : Các giao dịch Alt-mempool vẫn phải đến được bộ xây dựng. Các nút cầu nối chuyển tiếp qua ranh giới chính xác là bề mặt tin cậy và kiểm duyệt mà các giao dịch khung được cho là để loại bỏ, chỉ một bước nhảy xuống ngăn xếp.

khung tx <> cây quyết định mempool công cộng:

luồng khung (6) 1040×1000 111 KB

ví dụ về nhóm bảo mật chuẩn

Để xem ví dụ về cách triển khai giao thức bảo mật chuẩn (sử dụng mã giả), hãy xem tại đây .