Cơ chế Hook của Uniswap v4: Thách thức về an ninh đứng sau sức mạnh

robot
Đang tạo bản tóm tắt

Cơ chế Hook của Uniswap v4: Tiềm năng và rủi ro đồng hành

Uniswap v4 sắp ra mắt, bản cập nhật lần này mang đến nhiều tính năng hoàn toàn mới, bao gồm hỗ trợ số lượng bể thanh khoản không giới hạn cho mỗi cặp giao dịch và phí động, thiết kế đơn thể, kế toán chớp nhoáng, cơ chế Hook, cũng như hỗ trợ tiêu chuẩn mã thông báo ERC1155. Trong đó, cơ chế Hook đã thu hút được sự chú ý rộng rãi vì tiềm năng mạnh mẽ của nó.

Cơ chế Hook cho phép thực hiện mã tùy chỉnh tại những điểm cụ thể trong vòng đời của bể thanh khoản, từ đó nâng cao đáng kể khả năng mở rộng và tính linh hoạt của bể. Tuy nhiên, cơ chế Hook cũng có thể là một con dao hai lưỡi. Mặc dù mạnh mẽ và linh hoạt, nhưng việc sử dụng Hook một cách an toàn cũng là một thách thức không nhỏ. Độ phức tạp của Hook không thể tránh khỏi mang đến những vectơ tấn công tiềm ẩn mới.

Bài viết này sẽ giới thiệu các khái niệm liên quan đến cơ chế Hook trong Uniswap v4, và tóm tắt những rủi ro an ninh mà nó có thể gặp phải.

Cơ chế cốt lõi của Uniswap v4

Trước khi đi sâu vào thảo luận, chúng ta cần có một hiểu biết cơ bản về cơ chế của Uniswap v4. Theo thông báo chính thức và sách trắng, Hook, kiến trúc đơn thể và kế toán chớp nhoáng là ba chức năng quan trọng giúp thực hiện các pool thanh khoản tùy chỉnh và định tuyến hiệu quả qua nhiều pool.

Cơ chế Hook

Hook chỉ là hợp đồng hoạt động ở các giai đoạn khác nhau của vòng đời của quỹ thanh khoản, nhằm mục đích cho phép bất kỳ ai đưa ra quyết định cân bằng. Thông qua cách này, có thể đạt được hỗ trợ gốc cho phí động, thêm lệnh giới hạn trên chuỗi, hoặc thực hiện giao dịch lớn phân tán thông qua nhà tạo lập thị trường trung bình có trọng số theo thời gian (TWAMM).

Hiện tại có tám callback Hook, được chia thành bốn nhóm ( mỗi nhóm chứa một cặp callback ):

  • trướcKhởiTạo/sauKhởiTạo
  • beforeModifyPosition/afterModifyPosition
  • trướcHoán đổi/sauHoán đổi
  • trướcDonate/sauDonate

Tại sao Hook được coi là "con dao hai lưỡi" của Uniswap V4?

Mô hình đơn, ghi sổ nhanh và cơ chế khóa

Kiến trúc đơn thể và ghi sổ chớp nhoáng nhằm nâng cao hiệu suất bằng cách giảm chi phí và đảm bảo hiệu quả. Nó giới thiệu một hợp đồng singleton mới, tức là tất cả các bể thanh khoản đều được lưu giữ trong cùng một hợp đồng thông minh. Thiết kế đơn thể này phụ thuộc vào một PoolManager để lưu trữ và quản lý trạng thái của tất cả các bể.

Phiên bản v4 giới thiệu tính năng ghi sổ chớp nhoáng và cơ chế khóa. Cách thức hoạt động của cơ chế khóa như sau:

  1. hợp đồng locker yêu cầu lock trên PoolManager.

  2. PoolManager thêm địa chỉ hợp đồng locker vào hàng đợi lockData và gọi hàm callback lockAcquired.

  3. hợp đồng locker thực hiện logic của nó trong callback. Sự tương tác với pool trong quá trình thực hiện có thể dẫn đến sự gia tăng tiền tệ khác không bằng không, nhưng khi kết thúc thực hiện, tất cả các gia tăng phải được quyết toán về không.

  4. PoolManager kiểm tra trạng thái của hàng đợi lockData và gia tăng tiền tệ. Sau khi xác minh, xóa hợp đồng locker đó.

Tổng thể mà nói, cơ chế khóa ngăn chặn việc truy cập đồng thời và đảm bảo rằng tất cả các giao dịch đều có thể được thanh lý. Phương pháp này có nghĩa là việc điều chỉnh hoạt động là số dư nội bộ ròng, chứ không phải thực hiện chuyển khoản ngay lập tức. Bất kỳ thay đổi nào sẽ được ghi lại trong số dư nội bộ của bể, trong khi chuyển khoản thực tế sẽ được thực hiện khi kết thúc hoạt động.

Do sự tồn tại của cơ chế khóa, tất cả các tài khoản bên ngoài (EOA) không thể tương tác trực tiếp với PoolManager. Tất cả các tương tác phải được thực hiện thông qua hợp đồng. Chủ yếu có hai kịch bản tương tác hợp đồng:

  • Hợp đồng locker đến từ kho mã chính thức hoặc được người dùng triển khai. Tình huống này có thể được coi là tương tác thông qua bộ định tuyến.

  • Hợp đồng locker và Hook được tích hợp vào cùng một hợp đồng, hoặc được kiểm soát bởi thực thể bên thứ ba. Tình huống này có thể được coi là tương tác thông qua Hook.

Mô hình đe dọa

Trước khi thảo luận về các vấn đề an ninh liên quan, chúng ta cần xác định mô hình mối đe dọa. Chủ yếu xem xét hai trường hợp sau:

  • Mô hình đe dọa I: Hook bản thân là hợp lệ, nhưng có lỗ hổng.
  • Mô hình đe dọa II: Hook bản thân nó là ác ý.

Vấn đề an ninh trong mô hình đe dọa I

Mô hình đe dọa I tập trung vào các lỗ hổng liên quan đến chính Hook. Mô hình đe dọa này giả định rằng các nhà phát triển và Hook của họ là không có ác ý. Tuy nhiên, các lỗ hổng đã biết hiện có trong hợp đồng thông minh cũng có thể xuất hiện trong Hook.

Chúng tôi chọn tập trung vào các lỗ hổng tiềm ẩn đặc trưng của phiên bản v4, chủ yếu chú ý đến hai loại Hook sau:

  • Hook bảo quản vốn của người dùng. Kẻ tấn công có thể tấn công Hook này để chuyển tiền, gây ra tổn thất tài sản.

  • Hook để lưu trữ dữ liệu trạng thái quan trọng mà người dùng hoặc các giao thức khác phụ thuộc vào. Kẻ tấn công có thể cố gắng thay đổi trạng thái quan trọng, khi người dùng khác hoặc giao thức sử dụng trạng thái sai, có thể mang lại rủi ro tiềm ẩn.

Qua nghiên cứu, chúng tôi phát hiện ra một số lỗ hổng nghiêm trọng, chủ yếu xuất phát từ sự tương tác rủi ro giữa Hook, PoolManager và bên thứ ba bên ngoài, có thể được chia thành hai loại vấn đề: vấn đề kiểm soát truy cập và vấn đề xác thực đầu vào.

Vấn đề kiểm soát truy cập

Các hàm callback trong v4 có thể gây ra vấn đề, bao gồm 8 callback Hook và callback lock. Các hàm này chỉ nên được PoolManager gọi, không được gọi bởi địa chỉ khác. Đối với Hook, việc thiết lập cơ chế kiểm soát truy cập mạnh mẽ là rất quan trọng, đặc biệt là khi chúng có thể được gọi bởi các bên khác ngoài chính bể.

Vấn đề xác thực đầu vào

Mặc dù có cơ chế khóa, vẫn tồn tại một kịch bản tấn công có thể xảy ra, đó là các cuộc gọi bên ngoài không đáng tin cậy do xác thực đầu vào không đúng cách trong một số triển khai Hook dễ bị tấn công:

  • Hook không xác minh quỹ mà người dùng dự định tương tác. Đây có thể là một quỹ độc hại chứa các mã thông báo giả mạo và thực hiện logic có hại.

  • Một số hàm Hook quan trọng cho phép gọi bên ngoài tùy ý.

Các cuộc gọi bên ngoài không đáng tin cậy cực kỳ nguy hiểm, có thể dẫn đến nhiều loại tấn công khác nhau, bao gồm cả tấn công tái nhập.

Biện pháp phòng ngừa

Để tránh các vấn đề an ninh liên quan đến Hook, việc thực hiện kiểm soát truy cập cần thiết đối với các hàm bên ngoài/công cộng nhạy cảm một cách thích hợp và xác minh các tham số đầu vào để xác thực các tương tác là rất quan trọng. Hơn nữa, việc bảo vệ chống lại tái nhập có thể giúp đảm bảo rằng Hook sẽ không được thực hiện lại trong quy trình logic tiêu chuẩn.

Tại sao nói Hook là "con dao hai lưỡi" của Uniswap V4?

Vấn đề an ninh trong mô hình đe dọa II

Trong mô hình đe dọa này, chúng tôi giả định rằng nhà phát triển và Hook của họ là độc hại. Điều quan trọng là Hook được cung cấp có thể xử lý tài sản tiền điện tử mà người dùng chuyển khoản hoặc ủy quyền hay không.

Theo phương pháp truy cập Hook, chúng tôi chia Hook thành hai loại:

  • Hook quản lý: Hook không phải là điểm vào. Người dùng phải tương tác với Hook thông qua bộ định tuyến.

  • Hook độc lập: Hook là điểm vào, cho phép người dùng tương tác trực tiếp.

Hook quản lý

Tài sản mã hóa của người dùng đã được chuyển nhượng hoặc ủy quyền cho router. Do PoolManager đã thực hiện kiểm tra số dư, việc đánh cắp tài sản này qua Hook độc hại không dễ dàng. Tuy nhiên, vẫn tồn tại bề mặt tấn công tiềm ẩn, chẳng hạn như cơ chế quản lý phí của phiên bản v4 có thể bị kẻ tấn công thao túng thông qua Hook.

Hook độc lập

Khi Hook được sử dụng làm điểm vào, tình hình trở nên phức tạp hơn. Hook có được quyền lực nhiều hơn, lý thuyết có thể thực hiện bất kỳ thao tác nào mong muốn thông qua tương tác này.

Trong phiên bản v4, việc xác minh logic mã là rất quan trọng. Vấn đề chính là liệu có thể thao tác với logic mã hay không. Nếu Hook có thể nâng cấp, điều này có nghĩa là một Hook có vẻ an toàn có thể trở thành độc hại sau khi nâng cấp, do đó tạo ra rủi ro lớn. Những rủi ro này bao gồm:

  • Đại lý có thể nâng cấp ( có thể bị tấn công trực tiếp )
  • Có logic tự hủy. Có thể bị tấn công trong trường hợp gọi đồng thời selfdestruct và create2.

Biện pháp phòng ngừa

Điều quan trọng là đánh giá xem Hook có phải là độc hại hay không. Cụ thể, đối với Hook loại quản lý, chúng ta nên chú ý đến hành vi quản lý chi phí; trong khi đối với Hook độc lập, điểm chính là liệu chúng có thể nâng cấp được hay không.

Tại sao Hook được coi là "con dao hai lưỡi" của Uniswap V4?

Kết luận

Bài viết này tóm tắt các cơ chế cốt lõi liên quan đến vấn đề an toàn của Hook trong Uniswap v4, và đưa ra hai mô hình đe dọa cùng các rủi ro an ninh liên quan. Mặc dù cơ chế Hook rất mạnh mẽ, nhưng cũng mang lại những thách thức an ninh mới. Các nhà phát triển và người dùng cần nhận thức đầy đủ về những rủi ro tiềm ẩn này và thực hiện các biện pháp phòng ngừa thích hợp để đảm bảo an toàn tài sản khi sử dụng Uniswap v4.

UNI2.93%
HOOK6.4%
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
  • Phần thưởng
  • 6
  • Chia sẻ
Bình luận
0/400
NightAirdroppervip
· 08-06 06:42
Chơi một cách trơn tru đến cùng
Xem bản gốcTrả lời0
WenAirdropvip
· 08-05 22:14
Tiềm năng thật sự lớn.
Xem bản gốcTrả lời0
consensus_failurevip
· 08-05 22:11
An toàn là tối thượng.
Xem bản gốcTrả lời0
CryptoPhoenixvip
· 08-05 22:06
Rủi ro chính là sự mới mẻ
Xem bản gốcTrả lời0
GateUser-74b10196vip
· 08-05 22:05
Không hổ danh là bản cập nhật cấp sử thi
Xem bản gốcTrả lời0
LayerZeroHerovip
· 08-05 22:02
Tính năng mới rất nguy hiểm.
Xem bản gốcTrả lời0
Giao dịch tiền điện tử mọi lúc mọi nơi
qrCode
Quét để tải xuống ứng dụng Gate
Cộng đồng
Tiếng Việt
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)