Giới thiệu sơ lược về các rủi ro DeFi

Thông qua phần này, chúng tôi hy vọng sẽ làm rõ các rủi ro kinh tế và kỹ thuật có liên quan nhất đối với các giao thức DeFi, phân tích một số cách khai thác nổi bật nhất và các yếu tố mà người dùng nên xem xét để quản lý khả năng gặp phải những rủi ro này.

Phân loại rủi ro trong giao thức DeFi

Các giao thức DeFi phải đối mặt với nhiều rủi ro – từ việc rug pulls đến hack các cuộc tấn công kinh tế (economic attacks). Những thuật ngữ này thường được sử dụng thay thế cho nhau… nhưng chúng thực sự có nghĩa là gì?

Trước khi phân biệt các cuộc tấn công này, trước tiên cần hiểu các loại rủi ro liên quan. Chúng có thể được phân loại rộng rãi theo cách sau:

• Rủi ro kỹ thuật – các chức năng lập trình được sử dụng theo cách đối nghịch để rút tiền từ các giao thức.
• Rủi ro kinh tế – sử dụng đòn bẩy làm chìa khóa cho các giao thức theo những cách không mong muốn, để tạo ra sự mất cân bằng dẫn đến thiệt hại cho người gửi tiền (và lợi nhuận cho kẻ tấn công).

Trong bối cảnh này, chúng tôi sẽ phân loại hack là các cuộc tấn công thuần túy về kỹ thuật – tấn công bên ngoài, rug pulls – nội bộ, cố ý sử dụng sai các yếu tố kỹ thuật và khai thác kinh tế như những hoạt động lợi dụng sự mất cân bằng giao thức.

Đối với phần tiếp theo của phần này, chúng tôi xem xét các yếu tố cơ bản đằng sau những rủi ro này thông qua lăng kính của 50 sự cố lớn nhất trong DeFi. Đối với những người quan tâm đến dữ liệu chi tiết, vui lòng kiểm tra bảng tính này.

Phân tích các rủi ro lớn nhất

Để hiểu mức độ nhạy cảm của các giao thức DeFi đối với từng loại rủi ro, chúng tôi đi sâu vào 50 sự cố lớn nhất đã diễn ra cho đến nay. Bao gồm các vụ hack trong hàng trăm triệu USD trong các cầu nối, sự sụp đổ kinh tế của các Stablecoin theo thuật toán và các vụ cướp hoàn toàn tiền của người dùng.

Giữa 50 sự cố này, chúng tôi ước tính người dùng đã mất hơn 5 tỷ đô la trong các ứng dụng DeFi. Như chúng tôi sẽ đề cập trong suốt phần này, trong số các vụ khai thác lớn nhất đến từ các vụ hack cầu nối, cũng như sự sụp đổ đặc biệt lớn của một Stablecoin thuật toán.

Dưới đây là sự phân bố của các yếu tố rủi ro chính đằng sau 50 cuộc tấn công DeFi lớn nhất.

Khoảng 2/3 các sự cố lớn nhất xuất phát từ rủi ro kỹ thuật. Trong khi đó, chỉ dưới một phần tư là do mất cân đối kinh tế dẫn đến khai thác lỗ hổng và 10% là sự kết hợp giữa hai loại rủi ro này.

Rủi ro kỹ thuật

Chúng tôi phân loại thêm các cuộc tấn công có lập trình tùy thuộc vào việc chúng là do lỗi hợp đồng thông minh, quản lý khóa cá nhân, khai thác front-end hay rug pulls.

Ở đây, chúng ta có thể quan sát thấy phần lớn các cuộc tấn công kỹ thuật là do các lỗi không mong muốn xuất hiện trong các hợp đồng thông minh của các giao thức. Trên thực tế, 46% trong số 50 cuộc tấn công được coi là bắt nguồn từ nguy cơ như vậy. Trong số này, một số lỗi phổ biến nhất là các lỗi re-entrancy, chẳng hạn như những lỗi được khai thác trong vụ hack khét tiếng của The DAO.

Hơn nữa, một phần đáng kể các cuộc tấn công là do quản lý khóa cá nhân, như gần đây đã thấy với vụ hack mạng Ronin trị giá 624 triệu đô la đằng sau Axie Infinity. Những sự cố này là do tin tặc có thể truy cập vào các khóa riêng tư, có quyền kiểm soát các hợp đồng thông minh của giao thức. Trong trường hợp của Ronin, có một ví multi-sig yêu cầu 5 trong số 9 địa chỉ để phê duyệt giao dịch, với 4 trong số này thuộc về Sky Mavis, công ty đứng sau mạng lưới. Thông báo từ Ronin chỉ ra rằng cuộc tấn công được thiết kế trên phương diện xã hội, cho thấy rằng một kẻ mạo danh đã gửi một liên kết đến nhóm của Sky Mavis sau khi được mở và được cấp quyền truy cập vào các khóa riêng của họ. Địa chỉ thứ năm bị xâm phạm thuộc về Axie DAO, có vẻ như một trong những thành viên của họ đã rơi vào cuộc tấn công tương tự.

Trong khi cầu Ronin đã sử dụng ví multi-sig, nhiều cuộc tấn công khác trong danh mục con này là do một địa chỉ duy nhất kiểm soát quyền truy cập vào quỹ giao thức. Việc quản lý khóa cá nhân không đúng cách như vậy có thể dẫn đến cả hack và rug pulls. Điều này hoạt động như một điểm thất bại chính để tin tặc khai thác, đồng thời cho phép các nhà phát triển có thể cố tình rút tiền của người dùng.

Bảo vệ tiền của một người trước những rủi ro này có vẻ khó khăn, nhưng không phải là không thể. Ở phần cuối của phần này, chúng tôi sẽ cung cấp các bước mà người dùng có thể thực hiện để giảm thiểu rủi ro kỹ thuật, nhưng trước đó hãy đi sâu vào các rủi ro kinh tế, vốn đã dẫn đến tổn thất thậm chí còn lớn hơn.

Rủi ro kinh tế

Mặc dù các yếu tố kỹ thuật đứng sau hầu hết các cuộc tấn công trong DeFi, nhưng những thiệt hại lớn hơn đã thực sự đến từ các rủi ro kinh tế.

Rủi ro kinh tế có thể được phân loại thành bốn loại: Phía cung, phía cầu, cơ chế ổn định và tình trạng tài sản. Các yếu tố này phụ thuộc lẫn nhau ở một mức độ nhất định, mặc dù tổn thất thường có thể được bắt nguồn từ một hoặc hai trong số các loại này cho mỗi sự cố.

Rủi ro từ phía cung chủ yếu giải quyết các dòng tiền vào và ra của thanh khoản và sự tập trung của nó. Ở đây các động lực rất khác so với các động lực được quan sát trong các cuộc tấn công kỹ thuật.

Ví dụ, hãy xem xét một sự cố kinh tế gần đây dẫn đến thiệt hại ít nhất 80 triệu đô la Mỹ cho những người gửi tiền vào Curve pools. Đồng ổn định MIM là một trong những tài sản mang lại lợi nhuận cao cho farmer DeFi cho đến ngày 26 tháng 1 năm 2022. Ngày hôm đó, người ta tiết lộ rằng người sáng lập dự án Daniel Sesta đã hợp tác trong một dự án khác, Wonderland, với một đồng nghiệp ẩn danh. Người sáng lập là một người từng bị kết án có liên quan đến một quỹ trị giá triệu USD, thông qua sàn giao dịch tập trung Quadriga ở Canada. Ngoài ra, một phần tài sản thế chấp hỗ trợ MIM nằm trong token gốc TIME của Wonderland. Khi danh tính của người đồng sáng lập được tiết lộ, DeFi đã có những cú sốc lớn về kinh tế.

Michael Patryn, người từng được biết đến với biệt danh Sifu, là Giám đốc tài chính ở Wonderland và người sáng lập của Abracadabra thừa nhận đã biết danh tính thực sự của anh ta. Điều này dẫn đến tổn thất đáng kể trong dự án gắn liền với Daniele Sesta. Trong trường hợp của Curve MIM pool, người gửi tiền đổ xô rút thanh khoản.

Khoảng 2 tỷ đô la Mỹ thanh khoản đã được rút chỉ trong vòng vài giờ. Nhóm bị rút này bao gồm MIM và 3Crv (một nhóm khác với 33,3% USDT, USDC, DAI), người gửi tiền đã chọn rút tiền trong 3Crv để tránh rủi ro liên quan đến MIM. Điều này dẫn đến cơ cấu tài sản trong pool trở nên mất cân đối.

Khi nhóm chuyển sang chủ yếu là MIM, người gửi tiền bắt đầu bị tính phí thoát cao hơn nếu họ chọn rút tiền trong 3Crv (hoặc bất kỳ thành phần nào của nó). Với tính thanh khoản trong nhóm ngày càng mỏng và MIM mất chốt với đồng đô la Mỹ, phí thoát đã tăng đến mức một địa chỉ nhận ra khoản lỗ 80 triệu đô la Mỹ từ một giao dịch rút tiền. Tổng thiệt hại cho tất cả những người gửi tiền có thể đạt đến con số rất lớn do sự cố này.

Mặc dù đây không phải là một cách khai thác, nhưng sự cố Curve MIM nêu bật các rủi ro kinh tế có thể dẫn đến thiệt hại đáng kể cho người dùng DeFi. Khi nói đến các cuộc tấn công kinh tế, biến số thường xuyên liên quan nhất là thao túng giá, thường là vốn hóa thị trường tương đối thấp hoặc tài sản kém thanh khoản. Những thứ này dẫn đến dễ bị lợi dụng các lỗ hổng trong cơ chế ổn định của giao thức, đặc biệt là các phép thuật mà chúng sử dụng.

Các giao thức cho vay Cream Finance và Compound đã trở thành nạn nhân của điều này, nơi những kẻ tấn công sử dụng các khoản vay nhanh để thao túng giá tài sản, cho phép chúng tăng giả giá tài sản thế chấp và tăng sức vay của chúng đến mức không bền vững. Vì Cream và Compound vào thời điểm đó được sử dụng các Oracles trên chuỗi, nên kẻ tấn công có thể thực hiện tất cả trong một khối thông qua một khoản vay nhanh.

Mặc dù các khoản vay nhanh tạo điều kiện cho nhiều cuộc tấn công này nhưng đó không phải là lý do chính đằng sau chúng. Đây là những dấu hiệu cho thấy các giao thức dễ bị mất cân bằng và thậm chí có thể được thực hiện theo cách thủ công mà không cần vay nhanh như trường hợp khai thác 200 triệu đô la Mỹ của giao thức Venus trong BSC. Chúng tôi sẽ thảo luận thêm về cách người dùng có thể giảm thiểu rủi ro ổn định liên quan đến Oracles, nhà thanh khoản và nhà kinh doanh chênh lệch giá.

Nhìn chung, những rủi ro kinh tế này có thể rất phức tạp, nhưng có thể được theo dõi bằng cách xem xét các yếu tố như sự thay đổi về tính thanh khoản trong các giao thức này và các Oracles mà chúng sử dụng. Người dùng có thể hành động nhiều hơn để bảo vệ mình khỏi những rủi ro này cũng như những rủi ro kỹ thuật.

Giảm nguy cơ “phơi nhiễm” trong DeFi

Như đã lưu ý trước đây, 66% trong số 50 sự cố lớn nhất trong DeFi là do rủi ro kỹ thuật, chủ yếu là lỗi hợp đồng thông minh. Vì đại đa số mọi người không thành thạo khi nói đến mã hợp đồng thông minh, điều này đặt ra câu hỏi: Chúng ta có thể làm gì để ngăn chặn những rủi ro này?

Bước đầu tiên và đơn giản nhất cần thực hiện là kiểm tra xem giao thức đã được kiểm toán chưa. Phần lớn các hoạt động khai thác được phân tích là không được kiểm toán.

Cần lưu ý rằng dù có nhiều hơn một bên kiểm định, xem xét các giao thức này thì nó vẫn có nguy cơ bị khai thác. Ví dụ, vụ hack Poly Network trị giá 611 triệu đô la Mỹ đã được kiểm toán bởi cả nhóm Certik và NCC. Với hồ sơ theo dõi của những người đánh giá này, người dùng có thể đánh giá giá trị mà họ có thể cung cấp và có khả năng gán trọng số cho khả năng các giao thức bị khai thác dựa trên các sự cố trước đó. Tuy nhiên, ở đây, điều đáng nói không chỉ là số lượng các cuộc tấn công mà những người kiểm tra này phải chịu mà còn cả số lượng các giao thức đã được họ kiểm tra an toàn và giá trị mà chúng chứa trong đó bị khóa.

Ngoài các lỗi hợp đồng thông minh, chúng tôi cũng chỉ ra rủi ro mà việc quản lý khóa cá nhân có thể gây ra. Người dùng nên tiến hành thẩm định xem ai có quyền truy cập vào các khóa riêng tư đằng sau một giao thức. Lý tưởng nhất là các giao thức này không chỉ có nhiều địa chỉ trong nội bộ mà nên bao gồm những người có uy tín bên ngoài tổ chức của họ. Điều này tương đương với các “giám đốc” cho các giao thức DeFi, ngoại trừ khả năng tiếp xúc với các lỗ hổng bảo mật nhiều hơn theo nghĩa truyền thống. Bằng cách tuân thủ tiêu chuẩn này, các giao thức ít có khả năng bị truy cập vào khóa riêng tư và rug pulls vì chúng sẽ không thể làm như vậy theo lập trình.

Từ góc độ kinh tế, người dùng nên theo dõi các chỉ số chính có thể ảnh hưởng đến sự an toàn của khoản tiền gửi. Đối với các khoản tiền gửi trong AMM, đặc biệt là các giao dịch hoán đổi cổ phiếu như Curve, cần theo dõi tính thanh khoản và thành phần của nó trên các tài sản. Hơn nữa, sự tập trung thanh khoản trong các địa chỉ của cá voi cũng có thể hữu ích để đánh giá mức độ dễ bị khai thác lỗ hổng của các vị trí, có thể bị trượt giá hoặc thoát phí, nếu các địa chỉ này rút tiền.

Khi nói đến các giao thức cho vay, điều quan trọng là chúng sử dụng Oracles theo dõi dữ liệu ngoài chuỗi hoặc sử dụng giá trung bình theo thời gian cho tài sản. Những điều này giúp ngăn chặn các hành vi thao túng giá, có thể dẫn đến thua lỗ cho người gửi tiền. Tương tự, nếu có các tài sản vốn hóa nhỏ, kém thanh khoản được liệt kê trong các nhóm thanh khoản được chia sẻ, thì những tài sản này cũng có thể bị thổi phồng giả tạo bởi những kẻ tấn công tìm cách lấy tiền.

Những rủi ro này bao gồm những rủi ro từ phía giao thức, nhưng cũng có những phương pháp mà người dùng có thể thực hiện để tránh những thiệt hại nặng nề. Phổ biến nhất trong số này bao gồm sử dụng ví phần cứng, có một ví “burner” để sử dụng tối ưu các khoản tiền nhỏ và tránh nhấp vào các liên kết đáng ngờ hoặc tương tác với các trò gian lận lừa đảo.

Kết luận

Rủi ro có rất nhiều trong thị trường tiền mã hoá và DeFi cũng nằm trong số đó. Mặc dù các giao thức DeFi mang lại cơ hội lợi nhuận cao hơn so với các giao thức có sẵn trong tài chính truyền thống, nhưng chúng dễ gặp rủi ro lớn hơn, với các tác động rất khác nhau. Mặc dù việc theo dõi tất cả những rủi ro này chắc chắn rất phức tạp, nhưng bạn cần lưu ý những rủi ro này, đặc biệt nếu bạn đang gửi số tiền lớn.

Mặc dù các sự cố ngày càng trở nên lớn hơn khi thị trường tiền mã hoá ngày càng phát triển nhưng ngành công nghiệp này đang thiết lập các phương pháp hay nhất để giảm thiểu những rủi ro. Giờ đây, nhiều giao thức lựa chọn kiểm tra hơn bất chấp chi phí đắt đỏ. Việc họ sử dụng multi-sigs để quản lý tiền gửi cũng phổ biến hơn. Oracles được sử dụng để định giá, cũng có khả năng phục hồi cao hơn khi các nhà phát triển học hỏi từ các cuộc tấn công trước đó. Là mã nguồn mở, tiền mã hoá có thể cung cấp thông tin chi tiết, minh bạch về các cuộc tấn công này, để củng cố ngành công nghiệp nói chung. Cuối cùng, rủi ro có thể vẫn tồn tại mọi nơi, nhưng ngày càng có nhiều nhà phát triển và người dùng có thể hành động để giảm thiểu điều đó.