Chỉ trích EIP-3074 và thay thế đơn giản

Đối với các nhà phát triển, cơ chế AUTH/AUTHCALL rất hấp dẫn. Nó cho phép một người tạo người gọi để thực hiện các chiến lược theo đợt khác nhau (ví dụ: hỗ trợ nhiều nonce để có tính song song tốt hơn), mô hình trừu tượng hóa gas, phương pháp trừu tượng hóa tài khoản phức tạp, v.v.

Tính linh hoạt này bắt nguồn từ sự tự do tuyệt vời mà cơ chế này mang lại cho các nhà phát triển. Cơ chế AUTH/AUTHCALL không yêu cầu nhà phát triển tuân theo một mẫu cụ thể, nhưng yêu cầu người dùng ký giá trị băm cam kết (nội dung cam kết sẽ được người gọi phân tích cú pháp), cho phép nhà phát triển đặt các hạn chế của riêng họ dựa trên cam kết.

Tuy nhiên, tính linh hoạt này đi kèm với chi phí bảo mật. Trong bài viết này, tôi muốn giới thiệu một giải pháp thay thế đơn giản hơn. Giải pháp này có hầu hết các ưu điểm của cơ chế AUTH/AUTHCALL, nhưng rủi ro thấp hơn nhiều so với giải pháp sau.

Tại sao việc ký một cam kết AUTH rủi ro hơn so với việc ký một giao dịch liên quan đến hợp đồng dễ bị tấn công/độc hại?

Khi người dùng ký một giao dịch liên quan đến hợp đồng, rủi ro mà người dùng gặp phải đã được biết đến, tức là tài sản trong tầm kiểm soát của hợp đồng có thể bị mất. Giả sử người dùng ký một giao dịch phê duyệt hợp đồng ERC 20 cho phép một hợp đồng DEX độc hại. Hợp đồng DEX độc hại này có thể rút toàn bộ số dư của người dùng trong hợp đồng ERC 20. Tuy nhiên, nó không thể rút mã thông báo từ các hợp đồng ERC 20 khác của người dùng trừ khi được người dùng chấp thuận. Nó cũng không thể thực hiện các hành động khác thay mặt người dùng, vì điều này cũng yêu cầu sự chấp thuận của người dùng độc quyền.

Ngược lại, EIP 3074 không chỉ yêu cầu người dùng ký vào "tấm séc trắng" mà còn giả định rằng người gọi là trung thực và không có lỗ hổng. Người gọi độc hại/dễ bị tổn thương có thể thực hiện bất kỳ hành động nào thay mặt người dùng - truy cập tài sản do người dùng nắm giữ, bỏ phiếu thay mặt người dùng, kiểm soát các hợp đồng do người dùng sở hữu, v.v.

Tồi tệ hơn, người gọi có thể làm điều ác bất cứ lúc nào, vì việc triển khai nonce nằm dưới sự kiểm soát của người gọi. Việc triển khai logic nonce dễ bị tổn thương/độc hại có thể phát lại các giao dịch trước đây của người dùng. Nếu logic của các phần khác của xác minh cam kết cũng dễ bị tổn thương, thì người gọi có thể sử dụng triển khai logic nonce này để thực hiện bất kỳ thao tác nào thay mặt cho người dùng. Ngay cả khi lỗ hổng được phát hiện, người dùng không thể rút séc trắng. Tài khoản bên ngoài (EOA) này đã bị xâm phạm vĩnh viễn.

Viết một chương trình người gọi chính xác rất khó và chúng tôi gần như chắc chắn rằng người gọi sẽ thỉnh thoảng gặp lỗi, bằng chứng là danh sách kiểm tra/lỗ hổng/hoàn cảnh không đầy đủ mà người gọi nên cảnh giác ở cuối EIP 3074. Danh sách này chắc chắn sẽ dài hơn, có thể là một quá trình khám phá đau đớn.

Ngoài ra, một tác nhân độc hại có thể viết một chương trình người gọi dường như vô hại, nhưng cố tình để lại một lỗ hổng tinh vi mà kẻ tấn công không thể khai thác được cho đến khi một số lượng lớn tài khoản bên ngoài ủy quyền cho người gọi.

tiêu đề phụ

Ví dụ về chiếm đoạt quản trị

• Sàn giao dịch phi tập trung độc hại EveSwap đã viết một chương trình người gọi cho người dùng của nó. Chương trình người gọi này cung cấp tài trợ gas cho người dùng bằng cách airdrop mã thông báo EVE, đồng thời thực hiện theo đợt các giao dịch chuyển và phê duyệt của người dùng.

• Chương trình người gọi của EveSwap dường như vô hại và sẽ không bao giờ đánh cắp mã thông báo của người dùng vì nó sẽ bị lộ ngay lập tức.

• Người dùng hài lòng. Các giao dịch đều thành công và phí giao dịch rẻ. Đó là một vài tháng yên bình.

• Tuy nhiên, bất cứ khi nào ai đó sử dụng EveSwap để giao dịch ALI, mã thông báo quản trị của AliceSwap, quyền biểu quyết AliceSwap của người dùng sẽ tự động được ủy quyền cho EveSwap.

• Khi số lượng được ủy quyền đạt đến một ngưỡng nhất định, EveSwap sẽ chiếm đoạt AliceSwap thông qua đề xuất quản trị.

• tiêu đề phụ

Ví dụ về phát lại chuỗi chéo

EIP 3074 gợi ý một cách hợp lý rằng các cam kết nên chứa chainid. Tuy nhiên, điều này được thực thi bởi người gọi, không phải giao thức. Người gọi có cùng địa chỉ trên một chuỗi khác có thể bỏ qua bước kiểm tra này (hoặc kiểm tra vấn đề đó).

• EveSwap chạy trên BobSpongeChain tương thích với EVM, hỗ trợ EIP 3074. EveSwap triển khai một người gọi trung thực trên BobSpongeChain.

• Người dùng sử dụng trình gọi này để giao dịch trên BobSpongeChain, sau đó sử dụng cầu nối để chuyển tài sản sang Ethereum.

• EveSwap triển khai một người gọi khác có cùng địa chỉ trên Ethereum bằng cách sử dụng cùng một khóa triển khai. Trình gọi này trên Ethereum không kiểm tra các xác nhận, chỉ dành cho chủ sở hữu và hoạt động như một proxy AUTH/AUTHCALL chung cho chủ sở hữu của nó.

• Bằng cách này, EveSwap có thể chiếm đoạt tài khoản bên ngoài của người dùng trên Ethereum và lấy đi tài sản của họ.

• Người dùng chưa bao giờ giao dịch trên Ethereum và chương trình người gọi chạy trên BobSpongeChain đã trải qua các đánh giá bảo mật nghiêm ngặt. Mặc dù vậy, người dùng đã mất toàn bộ tài sản của họ.

  tiêu đề phụ

Ta còn làm gì khác được nữa?

Đề xuất của tôi là triển khai một cơ chế rõ ràng hơn để thực thi ý nghĩa của cam kết ở cấp độ giao thức. Cấu trúc cam kết sẽ được nhập (như được mô tả trong EIP 712) và ví sẽ trình bày cam kết ở dạng người dùng có thể đọc được. Người dùng có thể biết chính xác giao dịch trông như thế nào và tự tin rằng giao dịch này sẽ không được thực hiện lại trên bất kỳ chuỗi nào mà không phụ thuộc vào đặc điểm và khả năng của nhà phát triển chương trình gọi vốn.

Một thực hiện có thể:

AUTH sẽ thay thế hàm băm cam kết bằng một cấu trúc đã nhập có chứa danh sách các cuộc gọi được ủy quyền. Mỗi lệnh gọi sẽ chỉ định {nonce,to,gas,calldata,value,chainid}. Chữ ký sẽ được xác minh và toàn bộ danh sách các cuộc gọi được ủy quyền sẽ được lưu dưới dạng ủy quyền_giao dịch thay vì biến địa chỉ được ủy quyền.

AUTHCALL sẽ nhận được một chỉ mục tham số mới trỏ đến địa chỉ trong danh sách được tạo bởi AUTH cuối cùng.

Số nonce của địa chỉ người dùng sẽ được tăng lên bằng AUTHCALL. Nonce không được lưu trữ bởi người gọi, nhưng nonce tài khoản thực tế.

lợi nhuận:

• Người dùng có thể hiểu rõ tình hình.

• Bảo mật được đảm bảo bởi giao thức.

• Tóm tắt hàng loạt và tài khoản vẫn được hỗ trợ.

• Nhược điểm:

• Việc triển khai nonce không hỗ trợ xử lý song song.

• Giao dịch cho các chương trình người gọi phức tạp có thể cồng kềnh vì người dùng phải xem xét và chấp nhận toàn bộ danh sách cuộc gọi.

• Các triển khai khác nhau có thể hỗ trợ các sơ đồ nonce khác nhau. Tuy nhiên, bất kể chúng ta sử dụng cơ chế nào, cơ chế đó phải được thực hiện bởi giao thức chứ không phải người gọi.

  tiêu đề phụ

Thay thế: Tránh hard fork hoàn toàn

Ngoài ra còn có một tùy chọn để tránh hoàn toàn cơ chế AUTH và giải quyết vấn đề trừu tượng hóa tài khoản và xử lý theo lô bằng một nhóm giao dịch thay thế như được đề xuất bởi vbuterin.

lợi nhuận:

• Không yêu cầu hard fork, được hỗ trợ bởi các hợp đồng thông minh và các nút nhận thức được các hợp đồng thông minh đó.

• Có thể được sử dụng với bất kỳ triển khai nào hỗ trợ EIP 3074 mà không gây thêm rủi ro.

• Nhược điểm:

• Không tương thích ngược với các tài khoản bên ngoài hiện có. Người dùng cần triển khai ví hợp đồng và chuyển tài sản vào ví.

• Liên kết gốc:

Liên kết gốc:

https://blog.mycrypto.com/eip-3074/

Biên dịch & Hiệu đính: Min Min & A Jian

Biên dịch & Hiệu đính: Min Min & A Jian