Gần đây, Uniswap Lab đã chính thức công bố tiến trình phát triển của AMM Uniswap V4 thế hệ tiếp theo, đồng thời phát hành kho lưu trữ mã và sách trắng. Sách trắng V4 lần này chỉ có 3 trang, lý do là V4 không thực hiện quá nhiều thay đổi đối với logic thuật toán cốt lõi của AMM mà bổ sung một số tính năng mới trên nền tảng của V3 để đáp ứng nhu cầu của nhiều kịch bản hơn. Dựa trên mã nguồn mở hiện tại, SharkTeam sẽ xem xét những tính năng mới mà V4 mang lại và phân tích các phương pháp ứng dụng tốt nhất cho tính năng quan trọng Hook được giới thiệu bởi V4.

1. Sự khác biệt giữa V4 và V3

1.1 AMM

Ở cấp độ thuật toán AMM, Uniswap V4 không sửa đổi V3 và vẫn sử dụng thuật toán thanh khoản dựa trên tích không đổi x*y=k.

Trong Uniswap V3, mỗi cặp giao dịch có thể có 4 nhóm (ban đầu là 3 và sau đó một nhóm 1bp mới được thêm vào), tương ứng với các nhóm tỷ lệ 0,01%, 0,05%, 0,3% và 1%. cũng khác nhau, khi tạo pool bạn chỉ được chọn 1 trong 4 loại này.

Trong Uniswap V4, về mặt lý thuyết, mỗi cặp giao dịch có thể có số lượng nhóm bất kỳ và tỷ lệ phí của mỗi nhóm cũng có thể là bất kỳ giá trị nào và khoảng trống đánh dấu của các nhóm này cũng có thể là bất kỳ giá trị nào.

Điều này cũng dẫn đến một vấn đề: tính thanh khoản của các cặp giao dịch trong Uniswap V4 sẽ bị phân mảnh, do đó, cần có một bộ định tuyến/bộ tổng hợp hiệu quả hơn để giúp người dùng tìm ra lộ trình giao dịch tối ưu.

1.2 Móc

Móc là một tập hợp các hợp đồng được phát triển bởi bên thứ ba hoặc chính thức của Uniswap. Khi tạo một nhóm, nhóm có thể chọn ràng buộc một móc. Sau đó, ở một giai đoạn cụ thể của giao dịch, nhóm sẽ tự động gọi hợp đồng Móc đã ràng buộc. Uniswap V4 xác định các giai đoạn này trong đó mã hợp đồng hook có thể được thực thi:

Điều đó có nghĩa là hợp đồng hook có thể được gọi trước và sau các hoạt động như khởi tạo nhóm, thêm/xóa thanh khoản, giao dịch và quyên góp.

Hợp đồng Hook cần chỉ định rõ ràng giai đoạn nào trong số các giai đoạn trên sẽ được thực thi và nhóm cần biết liệu Hook tương ứng có cần được thực thi ở một giai đoạn nhất định hay không. yêu cầu Hook sử dụng một địa chỉ cụ thể để chỉ ra địa chỉ. Mã án cụ thể như sau:

Có thể thấy rằng 8 bit đầu tiên của địa chỉ Hook không được sử dụng để đánh dấu liệu Hook có cần được thực hiện ở một giai đoạn cụ thể hay không.

Do đó, nhà phát triển Hook cần tạo một địa chỉ đáp ứng các yêu cầu của Pool khi triển khai hợp đồng, điều này thường yêu cầu sử dụng tính toán Create2 + của Salt ngẫu nhiên để đạt được.

Sau đây là một ví dụ về triển khai Hook trong sách trắng:

Có thể thấy rằng trước và sau khi thực hiện hoán đổi, đầu tiên nhóm sẽ kiểm tra xem Hook tương ứng với nhóm có bật cờ tương ứng hay không và nếu được bật, nó sẽ tự động gọi chức năng tương ứng của hợp đồng Hook.

1.3 tỷ lệ phí động

Ngoài việc thực thi mã ở một giai đoạn cụ thể, Hook cũng có thể xác định tỷ lệ phí hoán đổi và tỷ lệ rút tiền của một nhóm nhất định. Tỷ lệ rút tiền đề cập đến tỷ lệ mà người dùng phải trả cho Hook khi rút thanh khoản. Ngoài ra, Hook cũng có thể chỉ định một phần phí hoán đổi cho chính nó.

Khi tạo nhóm, bạn cần sử dụng 4 bit đầu tiên của tham số phí (uint24) để đánh dấu xem nhóm có sử dụng phí động hay không và có bật phí hoán đổi hook và phí rút tiền hay không:

Nếu phí động được bật, nhóm sẽ gọi hợp đồng Hook để lấy tỷ lệ phí hoán đổi hiện tại trước mỗi lần hoán đổi. Hợp đồng Hook cần triển khai hàm getFee() để trả về tỷ lệ phí hoán đổi hiện tại.

Các móc làm cho Uniswap V4 trở thành một nền tảng dành cho nhà phát triển và cung cấp cho AMM nhiều khả năng hơn. Một số chức năng có thể được thực hiện với Hook bao gồm TWAMM (nhà tạo lập thị trường tự động theo trọng số thời gian), Limit Order (lệnh giới hạn), tái đầu tư LP, v.v., sẽ được giới thiệu chi tiết trong các chương tiếp theo.

1.4 Hợp đồng đơn lẻ

Mỗi khi một nhóm mới được tạo trong Uniswap V3, một hợp đồng mới cần được triển khai, điều này tiêu tốn rất nhiều gas, nhưng trên thực tế, mã được sử dụng bởi các nhóm này là giống nhau, chỉ có các tham số khởi tạo là khác nhau. Uniswap V4 giới thiệu hợp đồng Singleton để quản lý tất cả các nhóm, do đó việc tạo một nhóm mới không còn yêu cầu triển khai hợp đồng mới, giúp tiết kiệm gas cho việc triển khai hợp đồng.

Mỗi khi một nhóm mới được tạo trong Uniswap V3, một hợp đồng mới cần được triển khai, điều này tiêu tốn rất nhiều gas, nhưng trên thực tế, mã được sử dụng bởi các nhóm này là giống nhau, chỉ có các tham số khởi tạo là khác nhau. Uniswap V4 giới thiệu hợp đồng Singleton để quản lý tất cả các nhóm, do đó việc tạo một nhóm mới không còn yêu cầu triển khai hợp đồng mới, giúp tiết kiệm gas cho việc triển khai hợp đồng.

Ngoài ra, lợi thế của việc sử dụng hợp đồng Singleton là nó có thể giảm việc chuyển mã thông báo trong quá trình giao dịch, bởi vì tất cả các nhóm đều nằm trong cùng một hợp đồng, do đó, việc hoán đổi giữa các nhóm có thể được hoàn thành trực tiếp trong hợp đồng và trong V3, hoán đổi giữa các nhóm Sẽ cần phải chuyển mã thông báo giữa các nhóm khác nhau, điều này sẽ làm tăng gas.

Đồng thời, trong V4, tất cả các nhóm sử dụng cùng một hợp đồng và việc ghi sổ mã thông báo bên trong hợp đồng cũng được đơn giản hóa để mỗi mã thông báo được ghi sổ theo mã thông báo thay vì theo nhóm. số lượng lớn mã thông báo cũng sẽ thuận tiện hơn.

1.5 tải trọng

Để tạo điều kiện thuận lợi cho việc tích hợp Hook và các hợp đồng khác, hợp đồng V4 bổ sung chức năng extload để tất cả các trạng thái bên trong của hợp đồng có thể đọc được từ bên ngoài và trạng thái của tất cả các nhóm sẽ hoàn toàn trong suốt với bên ngoài.

1.6 Kế toán Flash

Để giảm chuyển đổi mã thông báo qua các giao dịch hoán đổi nhóm, V4 cũng sử dụng một phương pháp có tên là Kế toán Flash để chuẩn hóa quy trình hoán đổi, thêm/xóa tính thanh khoản/khoản vay nhanh vào một quy trình giống như khoản vay nhanh:

(1) Người dùng bị khóa

(2) Người dùng thực hiện bất kỳ thao tác nào, chẳng hạn như hoán đổi trong nhiều nhóm, thêm/xóa tính thanh khoản hoặc mượn mã thông báo từ nhóm thông qua các khoản vay nhanh

(3) Việc chuyển mã thông báo được tạo bởi tất cả các hoạt động của người dùng sẽ được ghi lại trong khóa

(4) Sau khi tất cả các thao tác kết thúc, người dùng có thể lấy mã thông báo đã lấy được, đồng thời cần thanh toán mã thông báo cần trả được ghi trong khóa.

Các quá trình này cần phải xảy ra trong một giao dịch.

Bằng cách này, nếu một giao dịch cần được hoán đổi trên nhiều nhóm, thì chỉ cần hai lần chuyển là đủ để giải quyết. Ví dụ: trong một giao dịch hoán đổi như ETH->USDC-BTC, USDC với tư cách là mã thông báo trung gian hoàn toàn không yêu cầu bất kỳ chuyển khoản nào.

1.7 ERC1155 bạc hà/đốt

Flash Accounting có thể giảm việc chuyển mã thông báo hoán đổi trong cùng một giao dịch. Bằng cách sử dụng mã thông báo ERC1155, nó có thể giảm hơn nữa việc chuyển mã thông báo của nhiều giao dịch.

V4 cho phép bạn lưu mã thông báo của mình trong hợp đồng V4 thông qua ERC1155 đúc, để bạn có thể sử dụng các mã thông báo này trong nhiều giao dịch mà không cần chuyển mã thông báo sang hợp đồng V4 mỗi lần.

Mã thông báo được lưu trữ trong hợp đồng V4 có thể được rút bằng cách sử dụng ghi ERC1155.

ERC1155 phù hợp với những người dùng thường xuyên hoán đổi hoặc thêm/xóa thanh khoản. Những người dùng này có thể lưu trực tiếp các mã thông báo thường được sử dụng trong hợp đồng V4, điều này có thể giảm chi phí gas khi chuyển mã thông báo.

2. Ví dụ về các phương pháp hay nhất cho Hook

2.1 TWAMM (Nhà tạo lập thị trường tự động theo trọng số thời gian)

Alice muốn mua ether trị giá 100 triệu đô la trên blockchain. Việc thực hiện một đơn đặt hàng có kích thước này trên các nền tảng tạo thị trường tự động (AMM) hiện có như Uniswap sẽ rất tốn kém vì các nền tảng này có thể sẽ tính phí cắt cổ cho Alice để ngăn cô ấy sử dụng thông tin nội bộ để có được giá tốt hơn.

Để có được mức giá tốt hơn, lựa chọn tốt nhất của Alice là chia đơn đặt hàng thành nhiều đơn đặt hàng con nhỏ hơn theo cách thủ công và thực hiện chúng từng bước trong vài giờ. Ý tưởng là cung cấp cho thị trường đủ thời gian để nhận ra rằng cô ấy không có thông tin nội bộ và cung cấp cho cô ấy một mức giá tốt hơn. Tuy nhiên, ngay cả khi cô ấy gửi một số đơn đặt hàng phụ lớn hơn, mỗi đơn đặt hàng phụ vẫn sẽ có tác động đáng kể đến giá, đồng thời dễ bị "tấn công kiểu bánh mì kẹp" bởi các nhà giao dịch thù địch.

Để có được mức giá tốt hơn, lựa chọn tốt nhất của Alice là chia đơn đặt hàng thành nhiều đơn đặt hàng con nhỏ hơn theo cách thủ công và thực hiện chúng từng bước trong vài giờ. Ý tưởng là cung cấp cho thị trường đủ thời gian để nhận ra rằng cô ấy không có thông tin nội bộ và cung cấp cho cô ấy một mức giá tốt hơn. Tuy nhiên, ngay cả khi cô ấy gửi một số đơn đặt hàng phụ lớn hơn, mỗi đơn đặt hàng phụ vẫn sẽ có tác động đáng kể đến giá, đồng thời dễ bị "tấn công kiểu bánh mì kẹp" bởi các nhà giao dịch thù địch.

TWAMM giải quyết vấn đề này bằng cách thực hiện các giao dịch thay cho Alice. Nó chia đơn đặt hàng của cô ấy thành vô số đơn đặt hàng ảo nhỏ để đảm bảo thực hiện suôn sẻ kịp thời. Đồng thời, TWAMM sử dụng mối quan hệ toán học đặc biệt của giao thức AMM nhúng để có thể chia sẻ chi phí Gas giữa các đơn đặt hàng ảo này. Vì TWAMM xử lý các giao dịch giữa các khối nên nó cũng không dễ bị "tấn công bánh sandwich".

Nhìn chung, TWAMM cung cấp cho Alice một cách hiệu quả hơn để thực hiện các giao dịch quy mô lớn, tránh phí cao và nguy cơ thao túng thị trường.

2.1.1 Nguyên tắc

TWAMM có AMM tích hợp, không khác gì các AMM khác, người dùng có thể trực tiếp thực hiện các giao dịch giao ngay thông qua AMM này hoặc thêm tính thanh khoản cho nó. Tuy nhiên, TWAMM cũng có hai nhóm lệnh TWAP, được sử dụng để thực hiện các lệnh TWAP theo hai hướng, khi người dùng gửi lệnh, chỉ định số lượng đầu vào mã thông báo và thời lượng của giao dịch, TWAMM sẽ đặt lệnh của cùng một hướng giao dịch vào nhóm tương ứng. , và tự động thực hiện các giao dịch theo tốc độ giao dịch được chỉ định. Khi lệnh của người dùng được thực hiện đầy đủ, người dùng có thể rút mã thông báo thu được từ giao dịch. Tất nhiên, trước khi lệnh của người dùng được thực hiện, người dùng cũng có thể hủy lệnh trước hoặc sửa đổi số lượng mã thông báo mà lệnh cần giao dịch.

Trong Ethereum, các hợp đồng thông minh chỉ có thể được kích hoạt bởi các giao dịch được khởi xướng bởi địa chỉ EOA và không thể được thực thi tự động. Do đó, TWAMM cần định kỳ gửi các giao dịch từ tài khoản EOA để giải quyết các mã thông báo được giao dịch trong nhóm đặt hàng của nó, điều này yêu cầu phải có tài khoản người quản lý để thực hiện các giao dịch này.

Tất nhiên, TWAMM cũng có thể tự động giải quyết nhóm đơn đặt hàng mỗi khi người dùng tương tác với nó, điều này giúp tiết kiệm chi phí hoạt động cho người quản lý, đây cũng là một cách phổ biến để các giao thức DeFi xử lý dữ liệu truyền phát.

2.1.2 Tại sao mô hình giao dịch này khó bị bánh mì kẹp tấn công?

Kiểu tấn công này rất khó thực hiện, vì dấu thời gian trong một khối sẽ không thay đổi nên kẻ tấn công phải tăng giá nhóm trong giao dịch cuối cùng của một khối, do đó việc giải quyết TWAMM trong khối tiếp theo sẽ bị ảnh hưởng. Điều này đòi hỏi cuộc tấn công bánh sandwich phải diễn ra thành nhiều khối, điều này chắc chắn sẽ mang lại rủi ro lớn cho kẻ tấn công, bởi vì những người kinh doanh chênh lệch giá khác có thể can thiệp vào giữa, khiến kẻ tấn công phải chịu tổn thất.

Đồng thời, do sự tồn tại của những người kinh doanh chênh lệch giá nên việc thao túng giá như vậy chắc chắn là không bền vững, do đặc điểm của lệnh TWAP là sẽ không giao dịch quá nhiều mã thông báo trong thời gian ngắn nên hầu hết các trường hợp đều thua lỗ phải hạn chế.

2.1.3 Luồng công việc TWAMM trong V4

(1) Móc này duy trì hai nhóm lệnh TWAP, tương ứng đại diện cho thứ tự TWAP của hai hướng giao dịch

(2) Người dùng có thể gửi đơn đặt hàng TWAP thông qua Móc này và cần chỉ định mã thông báo, số lượng và thời lượng của giao dịch

(3) Hook này đăng ký beforeSwap và beforeModifyPosition, và Hook này sẽ được kích hoạt mỗi khi người dùng giao dịch hoặc điều chỉnh một vị trí

(4) Sau khi được kích hoạt, Hook chịu trách nhiệm giải quyết hai nhóm lệnh TWAP

(5) Người dùng cũng có thể kích hoạt thanh toán theo cách thủ công bất cứ lúc nào

(6) Người dùng có thể hủy hoặc sửa đổi số lượng mã thông báo theo thứ tự TWAP

2.1.4 Ví dụ chi tiết

TWAMM đăng ký ba giai đoạn cho lệnh gọi logic của móc, khởi tạo TWAMM trước khi khởi tạo nhóm và kích hoạt móc này mỗi khi người dùng giao dịch hoặc điều chỉnh vị trí.

2.1.4 Ví dụ chi tiết

TWAMM đăng ký ba giai đoạn cho lệnh gọi logic của móc, khởi tạo TWAMM trước khi khởi tạo nhóm và kích hoạt móc này mỗi khi người dùng giao dịch hoặc điều chỉnh vị trí.

Người dùng có thể gọi hàm submitOrder trong TWAMM theo cách thủ công để gửi đơn đặt hàng mà họ cần thực hiện cho hợp đồng.

Sau khi người dùng thêm lệnh mà anh ta cần thực hiện vào hợp đồng, lệnh sẽ được thực hiện tự động mỗi khi nhóm thực hiện các hoạt động hoán đổi và sửa đổi Vị trí.

Mỗi khi người dùng gọi hàm hoán đổi v4 để giao dịch hoặc hàm modifyPosition để thay đổi vị trí, hàm thực thi trong TWAMM sẽ được kích hoạt và hàm nội bộ _executeTWAMMOrders sẽ được gọi trong hàm để tiếp tục thực hiện lệnh chưa hoàn thành trước đó.

_executeTWAMMOrder chức năng

Trên đây là quá trình thực hiện cập nhật lệnh, sau khi thực hiện xong thời gian thực hiện lệnh hiện tại của twamm sẽ được cập nhật.

2.2 Lệnh giới hạn

Không giống như các lệnh thị trường, được thực hiện ngay lập tức ở mức giá thị trường cuối cùng, các lệnh giới hạn được thực hiện ngay khi đạt đến một mức giá định trước. Hầu hết các DEX dựa trên các nhà tạo lập thị trường tự động (AMM) đều chọn hệ thống đặt lệnh thị trường theo mặc định. Đơn giản và dễ hiểu cho người mới. Các lệnh thị trường được thực hiện hoặc không thành công do các thông số như tác động giá tối đa. Trong lệnh giới hạn, lệnh sẽ chỉ được khớp khi giá tài sản đạt đến giá giới hạn, nếu không lệnh sẽ vẫn mở.

Ví dụ: giả sử ETH hiện đang giao dịch ở mức 1 ETH = 1500 DAI trong nhóm ETH/DAI. Người dùng có thể đặt lệnh chốt lời, nội dung chính là "nếu 1 ETH = 2000 DAI, hãy bán tất cả ETH của tôi". Nếu đạt đến mức giá này, ETH của người dùng sẽ tự động được hoán đổi thành DAI hoàn toàn trên chuỗi theo cách phi tập trung.

Trong các phiên bản trước của Uniswap, lệnh giới hạn thực tế là không thể. Hầu hết các AMM chỉ cho phép mua và bán trên thị trường. Trong phiên bản V4, do các tính năng mạnh mẽ và khả năng mở rộng của móc, có cơ sở để thực hiện lệnh giới hạn trong v4.

2.2.1 Nguyên tắc

Nguyên tắc thiết kế của lệnh giới hạn đơn giản hơn so với twamm, hiện tại, lệnh giới hạn để thêm thanh khoản đã được triển khai và việc thực hiện lệnh giới hạn để giao dịch sẽ dễ dàng hơn.

Vì có tickLower và tickUpper trong v4, nên dưới và trên sẽ thay đổi theo tình hình giao dịch của nhóm, khi người dùng thêm thanh khoản, họ không muốn thêm nó ở mức giá hiện tại, tại thời điểm này, giới hạn Order hook có thể được được sử dụng để thực hiện yêu cầu này, hãy đặt giá tương ứng trong hook. Sau mỗi lần hoán đổi, hook sẽ phán đoán giá nhóm hiện tại. Nếu đạt được giá đã đặt, thanh khoản tương ứng sẽ được thêm vào để có được thu nhập.

2.2.2 Quy trình đặt hàng giới hạn trong V4

1. Giới hạn duy trì nhiều kỷ nguyên dưới dạng các lệnh giới hạn cho các mức thấp hơn và các hướng giao dịch khác nhau.

2. Thông qua hook này, người dùng gửi giá thấp hơn và hướng giao dịch của mình, đồng thời thêm lệnh giới hạn vào hợp đồng.

3. Móc này đăng ký afterSwap, chỉ được kích hoạt khi giá thay đổi sau mỗi lần hoán đổi kết thúc

4. Sau khi được kích hoạt, Hook sẽ kiểm tra phạm vi giá hiện tại và kiểm tra từ kỷ nguyên xem có lệnh giới hạn nào cần thêm thanh khoản ở mức giá hiện tại hay không.

5. Người dùng có thể rút tiền hoặc thêm thanh khoản trực tiếp bất cứ lúc nào

2.2.3 Ví dụ chi tiết

Móc được kích hoạt trong hai giai đoạn đăng ký hợp đồng, móc được khởi tạo sau khi Pool được khởi tạo và logic móc được kích hoạt sau mỗi lần trao đổi.

Người dùng gọi hàm địa điểm để chuyển số lượng, giá và hướng giao dịch của thanh khoản mà người dùng muốn thêm. Trước tiên, hook sẽ thêm thanh khoản mà người dùng muốn thêm vào nhóm để lưu trữ, sau đó tạo một thứ tự giới hạn tương ứng cho người dùng.

Cái móc này sẽ được kích hoạt sau khi mỗi lần hoán đổi kết thúc và hoạt động thêm thanh khoản sẽ được hoàn thành dựa trên lệnh giới hạn hiện có trong phạm vi giá theo phạm vi giá hiện tại.

Người dùng có thể gọi chức năng hủy để hủy lệnh giới hạn trước khi lệnh giới hạn được hoàn thành và nhận được lợi ích của việc thêm thanh khoản lần này.

Người dùng có thể gọi chức năng rút tiền khi họ muốn loại bỏ thanh khoản để rút thanh khoản mong muốn.

Nói chung, móc lệnh giới hạn này cung cấp cho người dùng một cách thuận tiện hơn, người dùng có thể đặt giá khi họ muốn thêm thanh khoản, sau khi phạm vi giá trong nhóm đạt đến mức giá, móc sẽ tự động vào nhóm để người dùng thực hiện hoạt động thêm thanh khoản và người dùng có thể hủy và rút thanh khoản bất kỳ lúc nào.

Ngoài TWAMM và Lệnh giới hạn, các chức năng như tái đầu tư LP và thay đổi phí xử lý động cũng có thể được thực hiện dựa trên Hook. Do hạn chế về không gian, chúng tôi sẽ giới thiệu chúng trong phần phân tích tiếp theo:

Ngoài TWAMM và Lệnh giới hạn, các chức năng như tái đầu tư LP và thay đổi phí xử lý động cũng có thể được thực hiện dựa trên Hook. Do hạn chế về không gian, chúng tôi sẽ giới thiệu chúng trong phần phân tích tiếp theo:

Tái đầu tư LP: người dùng có thể sử dụng móc để thêm, sửa đổi và xóa tính thanh khoản, đồng thời móc có thể đăng ký afterSwap và afterModifyPosition để gọi. Vì người dùng thống nhất sử dụng móc để thêm thanh khoản, nên địa chỉ duy nhất bổ sung thanh khoản trong poolManager là hook. Móc có thể kiểm tra thời gian hiện tại mỗi khi nó được kích hoạt. Sau một khoảng thời gian nhất định, hãy chọn rút phần thưởng thanh khoản và nhận The lp mã thông báo sẽ thêm thanh khoản vào nhóm một lần nữa, do đó tự động tối ưu hóa thu nhập của người dùng.

Thay đổi phí động: móc có thể đăng ký trướcSwap và các giao diện khác để sửa đổi phí động trước khi trao đổi. Phí xử lý động không thể đơn giản thay đổi tuyến tính theo thời gian mà có thể định lượng mức độ biến động theo số lần nhảy đánh dấu được tạo bởi một lần hoán đổi, để thay đổi linh hoạt phí xử lý và thực hiện phòng ngừa rủi ro vô thường LP. Từ đó giảm tác động của các tổn thất tạm thời do giao dịch gây ra đối với các nhà cung cấp thanh khoản.

3. Thực hành tốt nhất về bảo mật hooks

Giảm việc sử dụng yêu cầu và hoàn nguyên

Trong logic chức năng của lệnh gọi hook của pool, nên giảm thiểu việc sử dụng các câu lệnh rollback. Do mối quan hệ chung giữa hợp đồng pool và hợp đồng hook, sau khi rollback giao dịch xảy ra trong hook, giao dịch trong pool cũng sẽ được khôi phục. Các câu lệnh khôi phục trong hook không liên quan đến các giao dịch thông thường trong nhóm có thể khiến người dùng không thể sử dụng các chức năng trong nhóm một cách bình thường.

Tránh sử dụng chức năng tự hủy

Tránh sử dụng chức năng tự hủy trong hook. Nếu chức năng tự hủy được gọi trong hook, nó sẽ không chỉ gây ra vấn đề về logic trong hook mà còn khiến các chức năng trong nhóm bị lỗi, khiến nội dung trong hook bị hỏng. toàn bộ nhóm bị mất và các chức năng bị lỗi. Hoạt động bình thường.

Kiểm soát truy cập nghiêm ngặt

Kiểm soát chặt chẽ các quyền trong hợp đồng hook để tránh các vai trò có quá nhiều quyền và thực hiện quản lý đa chữ ký đối với các vai trò đặc quyền để ngăn chặn các cuộc tấn công một điểm. Để tránh các tình huống trong đó vai trò đặc quyền có thể tùy ý sửa đổi các biến trạng thái hợp đồng, lỗi logic có thể xảy ra và khiến toàn bộ giao dịch bị khôi phục, ảnh hưởng đến việc sử dụng bình thường của nhóm. Để xác minh nguyên tắc đặc quyền tối thiểu, chúng ta nên sử dụng hợp đồng AccessControl của openzeppelin để triển khai các quyền chi tiết hơn để kiểm soát quyền truy cập, bởi vì thực tiễn này hạn chế từng thành phần hệ thống tuân theo nguyên tắc đặc quyền tối thiểu.

Thực hiện tốt các hạn chế chống tái nhập cảnh

Là mã mở rộng bên ngoài của Pool, hook cũng nên chú ý đến các cuộc tấn công vào lại có thể xảy ra trong hợp đồng, chẳng hạn như các cuộc tấn công vào lại có thể xảy ra trong các lệnh giới hạn khi chuyển mã thông báo gốc, dẫn đến mất tài sản hợp đồng. Kiểm tra và thử cập nhật tất cả trạng thái trước khi gọi một hợp đồng bên ngoài hoặc cái gọi là mẫu "kiểm tra-xác thực-tương tác". Bằng cách này, ngay cả việc vào lại sẽ không có hiệu lực vì tất cả các cập nhật trạng thái đã được thực hiện. .

Kiểm soát nâng cấp hợp đồng

Kiểm soát nâng cấp hợp đồng

Một số nhà phát triển có thể sử dụng hợp đồng ủy quyền để thay đổi và nâng cấp logic của hook trong tương lai, nhưng họ cũng cần chú ý đến các vấn đề có thể xảy ra trong quá trình nâng cấp hợp đồng. Trước hết, ngay cả khi chế độ proxy được áp dụng trong hook, giai đoạn tương ứng phải được khai báo trong hợp đồng proxy, chẳng hạn như beforeSwap, nếu không, nhóm không thể xác minh giá trị trả về chính xác. Thứ hai, hãy kiểm tra xem hợp đồng mục tiêu có tồn tại trước khi gọi cuộc gọi ủy nhiệm hay không. Solidity không thực hiện việc kiểm tra này cho chúng tôi. Bỏ qua bước kiểm tra này có thể dẫn đến các vấn đề về bảo mật và hành vi không mong muốn. Hãy xem xét cẩn thận thứ tự khai báo biến, vì các biến sẽ được đóng gói và lưu trữ trong cùng một vị trí, Ảnh hưởng đến các vấn đề như chi phí gas, bố cục bộ nhớ và kết quả cuộc gọi của đại biểu.

Về chúng tôi

Tầm nhìn của SharkTeam là bảo vệ toàn diện an ninh của thế giới Web3. Nhóm bao gồm các chuyên gia bảo mật giàu kinh nghiệm và các nhà nghiên cứu cấp cao từ khắp nơi trên thế giới. Họ thành thạo lý thuyết cơ bản về chuỗi khối và hợp đồng thông minh, đồng thời cung cấp các dịch vụ bao gồm kiểm toán hợp đồng thông minh, phân tích trên chuỗi và ứng phó khẩn cấp. Nó đã thiết lập mối quan hệ hợp tác lâu dài với những người chơi chính trong các lĩnh vực khác nhau của hệ sinh thái blockchain, chẳng hạn như Polkadot, Moonbeam, đa giác, OKC, Huobi Global, imToken, ChainIDE, v.v.