Rủi ro hợp đồng thông minh trong DeFi

Đọc bài viết này mất 27 phút

Trong khi tình trạng hỗn loạn về các vấn đề rủi ro quản trị của MakerDAO vẫn đang tiếp diễn, hãy cùng lắng nghe Xie Hanjian, kiến trúc sư trưởng của chuỗi công cộng Nervos, phân tích rủi ro của các hợp đồng thông minh DeFi của Ethereum và các biện pháp đối phó của Nervos DAO.

Tiêu đề gốc: "Rủi ro hợp đồng thông minh trong DeFi"
Nguồn gốc: NervosCommunity

Tác giả: Jan Xie, kiến trúc sư trưởng của Nervos, CEO của Miyuan Technology, cựu thành viên nhóm R&D cốt lõi Ethereum

Tài chính là nghệ thuật quản lý rủi ro. Có thể có rủi ro về cả bản thân tài sản và quá trình vận hành. Tài sản có giá, giá cả phản ánh giá trị nội tại và rủi ro toàn diện. Khi định giá một tài sản, việc đánh giá rủi ro cũng rất cần thiết. Rủi ro hoạt động chủ yếu đến từ “những người” dễ mắc sai sót và có thể bị mua chuộc. Do đó, việc đánh giá rủi ro tài sản và hoạt động là cốt lõi của tài chính, cho dù đối với tài chính truyền thống dựa trên tài sản truyền thống hay tài chính phi tập trung mới nổi (còn gọi là DeFi) chạy trên tài sản tiền điện tử bản địa.

Kiểm soát rủi ro là chìa khóa

Rủi ro của tài sản tiền điện tử không chỉ bao gồm các rủi ro bên ngoài như thay đổi chính sách mà còn sai sót trong thiết kế và rủi ro nội bộ như lỗi triển khai. Trên Ethereum, mã thông báo gốc là ETH và mã thông báo không phải gốc là cái mà chúng tôi gọi là mã thông báo ERC. Mã thông báo ERC đề cập đến mã thông báo tuân thủ bất kỳ tiêu chuẩn ERC20 nào và các tiêu chuẩn phái sinh của nó (chẳng hạn như ERC721 và ERC777, v.v.). Rủi ro của tài sản gốc sẽ thấp hơn rủi ro của tài sản không phải gốc, vì tài sản không phải gốc sẽ bị ảnh hưởng bởi các lỗ hổng hợp đồng thông minh bên cạnh các lỗ hổng của máy khách Ethereum. Đối với token ERC và DeFi, lỗ hổng trong hợp đồng thông minh là mối quan tâm lớn nhất vì DeFi, với tư cách là một hệ thống, là một mạng lưới phức tạp gồm vô số hợp đồng thông minh được đan xen bởi các nhà phát triển khác nhau từ khắp nơi trên thế giới. Chúng tôi gọi những rủi ro do lỗ hổng hợp đồng thông minh gây ra là rủi ro hợp đồng thông minh.

Mọi người đã thực hiện rất nhiều nghiên cứu về các lỗ hổng của hợp đồng thông minh và chúng tôi cũng đã phát hiện ra nhiều phương pháp phòng thủ. Nếu bạn quan tâm, đây là một cuộc khảo sát hay [1] . Tuy nhiên, nổi tiếng là không thể tìm và sửa các lỗ hổng trong tất cả các hợp đồng thông minh quan trọng hơn (hoặc trong tất cả các chương trình). Chúng ta đang sống trong một thế giới đầy rẫy những lỗi giao tiếp và sự ngẫu nhiên (thay đổi), và mỗi bước đi đều có thể dẫn đến sự “biến dạng”: chúng ta không thể viết ra những ý tưởng trong đầu thành những chỉ dẫn chính xác, và cũng không thể biến những chỉ dẫn này thành hướng dẫn hoàn hảo. Trình bày không hoàn hảo.

Nếu đây là thực tế tàn khốc, thì trong quá trình triển khai tài sản tiền điện tử, chúng ta không chỉ phải xem xét phòng thủ chủ động và phòng thủ thụ động mà còn phải kiểm soát rủi ro, để khi một số tình huống xấu xảy ra, có thể giảm thiểu tổn thất và tránh một sai sót nhỏ có thể biến thành sự kiện thiên nga đen. Hợp đồng thông minh có thể đạt được kiểm soát rủi ro thông qua nhiều mẫu thiết kế khác nhau, điều quan trọng nhất (theo ý kiến của tôi) là sự phân cấp trạng thái ứng dụng, bởi vì việc tập trung trạng thái ứng dụng có thể khuếch đại thiệt hại do các lỗ hổng hợp đồng thông minh gây ra. Tôi sẽ làm rõ hơn điều này ở những bài viết sau.

Rủi ro của mã thông báo ERC

Một số tiêu chuẩn của mã thông báo ERC bề ngoài có thể trông khác nhau, nhưng chúng đều có một số đặc điểm chung. Mô hình cơ bản của mã thông báo ERC là sử dụng hợp đồng mã thông báo để quản lý sổ cái mã thông báo và người dùng có thể phát hành, chuyển hoặc hủy mã thông báo thông qua tương tác với hợp đồng mã thông báo. Tất cả các bản ghi của sổ cái mã thông báo được lưu trữ trong hợp đồng mã thông báo và bản thân hợp đồng chỉ là một tài khoản trên Ethereum.

Ví dụ: giả sử có một mã thông báo ERC có tên là "cốc", Alice sở hữu 100 cốc và Bob sở hữu 50 cốc. Sổ cái của mã thông báo nằm trên hợp đồng thông minh Ethereum có địa chỉ/tài khoản 0x1234. Hợp đồng mã thông báo 0x1234 này sẽ duy trì cơ sở dữ liệu nội bộ và lưu trữ các bản ghi như "Alice có 100 cốc" và "Bob có 50 cốc". Khi Alice muốn chuyển 30 cốc cho Bob, cô ấy gửi một tin nhắn đã ký tới hợp đồng 0x1234 với nội dung "Hãy chuyển 30 cốc cho Bob." Sau đó, hợp đồng 0x1234 sẽ xác minh xem tin nhắn có thực sự đến từ Alice hay không, và sau đó sửa đổi cơ sở dữ liệu nội bộ của nó để cập nhật các bản ghi liên quan của "Alice có 70 cốc" và "Bob có 80 cốc".

Vấn đề ở đây là tất cả logic và trạng thái đều được lưu trong hợp đồng 0x1234 này. Alice và Bob không có quyền truy cập trực tiếp vào hồ sơ của chính họ vì những hồ sơ này được lưu giữ theo hợp đồng 0x1234. Tất cả người dùng nắm giữ mã thông báo này cần phải tương tác với hợp đồng này và cách duy nhất để quản lý mã thông báo của họ là gửi tin nhắn đến hợp đồng 0x1234.

Nói cách khác, hợp đồng mã thông báo là trung tâm của mọi thứ. Trung tâm của bất kỳ hệ thống nào cũng là mục tiêu mang lại nhiều lợi nhuận nhất cho những kẻ tấn công. Mọi vấn đề với trung tâm sẽ ảnh hưởng đến tất cả người dùng vì tất cả mã thông báo/bản ghi đều do trung tâm nắm giữ và mọi người phải tương tác với nó. Ví dụ: do lỗ hổng "transferFlaw[2]"/"allowAnyone[3]" do tràn số nguyên hoặc lỗ hổng "ItchySwap[4]" do ủy quyền bất cẩn, kẻ tấn công có thể sử dụng "transferFlaw[2]" /"allowAnyone[3]" lỗ hổng do ủy quyền bất cẩn. Trong trường hợp này, hãy đánh cắp mã thông báo của người khác. Thông qua lỗ hổng "ownerAnyone[5]", kẻ tấn công có thể khóa mã thông báo của mọi người bằng cách kiểm soát hợp đồng mã thông báo. Trong những ví dụ này, một khi hợp đồng token bị phá vỡ, mọi người đều gặp rắc rối.

Mã thông báo ERC được nắm giữ bởi các hợp đồng mã thông báo thay vì người dùng cá nhân, điều này rất khác với mã thông báo gốc ETH của Ethereum. Số dư ETH không được lưu trữ bởi bất kỳ hợp đồng thông minh nào mà được người dùng trực tiếp kiểm soát. Mỗi chủ sở hữu ETH có tài khoản và hồ sơ số dư của riêng mình. Ví dụ: nếu Alice có 100 ETH và Bob có 50 ETH trên chuỗi chính Ethereum thì Alice sẽ ghi "Số dư = 100" trong tài khoản của mình và Bob sẽ ghi "Số dư = 50" trong tài khoản của anh ấy. Số dư của Alice chỉ giảm khi chuyển khoản đi có chữ ký của cô ấy, tài khoản của Bob cũng vậy. Hồ sơ quyền sở hữu ETH được phân tán trên nhiều tài khoản thay vì tập trung vào một tài khoản. Miễn là khóa riêng của họ được an toàn thì không ai có thể đánh cắp ETH từ họ. Ngược lại, phạm vi tấn công của token ERC lớn hơn, bởi vì kẻ tấn công hoàn toàn có thể cố gắng phá hủy hợp đồng token, việc này dễ dàng hơn nhiều so với việc phá hủy chính giao thức.

Rủi ro nội sinh khác nhau khiến token ERC và ETH trở thành hai loại tài sản khác nhau. Hợp đồng thông minh chạy trên mạng phi tập trung khác với mạng phi tập trung. Vấn đề tập trung hóa là do mã thông báo ERC nằm ở lớp ứng dụng, điều này làm tăng thêm tác hại tiềm tàng của các lỗ hổng hợp đồng thông minh. Thật không may, chúng tôi biết rằng con người sẽ luôn mắc lỗi nên sẽ luôn có những lỗ hổng. Sự phân quyền của lớp mạng/lớp đồng thuận không thể giải quyết được vấn đề tập trung hóa của lớp ứng dụng.

Cách giảm thiểu rủi ro

Hiện tượng tập trung hóa xuất hiện trong các token dòng ERC vì trạng thái của chúng không phải như vậy một công dân hạng nhất trong mô hình lập trình Ethereum [6]. Trong Ethereum, trạng thái là phần đính kèm với mã và không thể được tham chiếu và so sánh trực tiếp. Tất nhiên, việc đặt các trạng thái có cùng quy tắc xác minh (ví dụ: bản ghi của cùng một mã thông báo) vào cùng một hợp đồng là điều đương nhiên, tuy nhiên, điều này sẽ khiến hợp đồng trở thành hợp đồng tập trung ở một mức độ nào đó. Đây là những gì xảy ra trong mô hình lập trình Ethereum.

Nhưng ở CKB, vì tư cách là công dân hạng nhất nên điều ngược lại. Trạng thái là một đối tượng mà người dùng có thể sử dụng trực tiếp và mã chỉ là một phụ kiện của trạng thái. Chúng ta có thể so sánh và nhóm các trạng thái sử dụng cùng một quy tắc xác thực một cách tự nhiên, ngay cả khi chúng do những người dùng khác nhau trực tiếp nắm giữ.

Trên CKB, chúng tôi gọi các token không phải gốc là “token do người dùng xác định” hoặc UDT. Đối với một UDT nhất định, định nghĩa (mã) nội dung và bản ghi nội dung (trạng thái) là riêng biệt, cũng như các bản ghi cho những người dùng (địa chỉ) khác nhau. Định nghĩa nội dung mô tả logic của mã thông báo, chẳng hạn như "giới hạn phát hành là 1 triệu" hoặc "Bob có thể phát hành mã thông báo mới", trong khi bản ghi tài sản là thông tin như "Alice có 100 mã thông báo".

Định nghĩa nội dung là một hợp đồng, được tạo bởi nhà phát hành mã thông báo và được lưu trữ trong Ô do nhà phát hành sở hữu (Ô Định nghĩa Tài sản, Ô Định nghĩa Tài sản), trong khi bản ghi tài sản được lưu trữ trong ô riêng của người dùng và tất cả các bản ghi tài sản đều được sử dụng giống nhau "gõ tập lệnh".

Mỗi người dùng sử dụng Ô riêng của mình để lưu trữ bản ghi mã thông báo của riêng mình. Các bản ghi mã thông báo này có chung quy tắc xác thực được xác định trong ô định nghĩa nội dung. Thông qua cấu trúc này, hồ sơ tài sản được lưu trữ dưới dạng phi tập trung.

Như được hiển thị trong hình trên, mã thông báo do Alice nắm giữ được lưu trữ trong ô riêng của Alice và ( Ô này) được bảo vệ bởi "tập lệnh khóa" của riêng nó, hiện sử dụng Secp256k1 theo mặc định. Ngay cả khi có vấn đề với định nghĩa tài sản, kẻ tấn công không thể sửa đổi bản ghi tài sản của Alice vì làm như vậy cần có khóa riêng của Alice. Vì mã thông báo do Alice nắm giữ trực tiếp nên kẻ tấn công không thể phá khóa do Alice thiết lập. Bằng cách phân cấp trạng thái mã thông báo, chúng tôi có thể kiểm soát hiệu quả các tổn thất do các lỗ hổng do tài sản xác định gây ra.

Nhưng vẫn có thể có những lỗ hổng ảnh hưởng đến mọi người (tài sản): ví dụ: có thể có lỗ hổng trong định nghĩa nội dung, điều này lỗ hổng Cho phép mọi người phát hành nhiều mã thông báo hơn dự định. Ưu điểm của UDT là, thứ nhất, hầu hết các lỗ hổng đều bị loại bỏ; thứ hai, ô định nghĩa tài sản được bảo vệ bằng khóa (tập lệnh), vốn có thể tự nhiên là một phần của logic xác thực trong việc phát hành mã thông báo. Rất dễ dàng để thiết lập cơ chế xác thực thông qua giao thức. Việc tách rời ủy quyền và logic nghiệp vụ này là một phương pháp kỹ thuật tuyệt vời và là phương pháp mặc định trong CKB. UDT sẽ có đặc tính phân cấp tốt hơn token ERC nên rủi ro hợp đồng thông minh của UDT thấp hơn token ERC nhưng tất nhiên vẫn cao hơn token gốc.

Nếu bạn cũng quan tâm đến UDT, đã có một số cuộc thảo luận trên Nervos Talk [7], vui lòng tham gia.

Bảo mật Nervos DAO

Việc phân cấp trạng thái ứng dụng cũng giúp ích trong việc thiết kế các chương trình DeFi. Nervos DAO[8] là ứng dụng DeFi đầu tiên trên CKB. Đó là một hợp đồng thông minh và người dùng có thể tương tác với bất kỳ hợp đồng thông minh nào trên CKB theo cách tương tự. Một trong những chức năng của Nervos DAO là cung cấp cho người nắm giữ CKByte một biện pháp đối phó chống pha loãng (phát hành thứ cấp). Bằng cách gửi CKByte vào Nervos DAO, chủ sở hữu CKByte sẽ nhận được phần thưởng phát hành thứ cấp tương ứng, điều này đảm bảo rằng tỷ lệ nắm giữ CKByte của họ sẽ chỉ bị ảnh hưởng bởi giới hạn phát hành cơ bản, giống như Bitcoin. Tại thời điểm viết bài này, hơn 1 tỷ CKByte[9] đã được gửi vào DAO và con số này vẫn đang tăng lên. Đây chẳng phải là mục tiêu mà những kẻ tấn công đang tìm kiếm sao? Chúng ta có cần phải lo lắng về điều này không?

Không cần! Bởi vì CKByte bị khóa trong Nervos DAO không được tổng hợp trong cùng một hợp đồng thông minh nên nó vẫn được nắm giữ bởi những người dùng khác nhau! Khi người dùng muốn gửi CKByte vào Nervos DAO, họ sẽ chọn các ô (mô hình UTXO của CKByte) rồi đặt tham chiếu tập lệnh loại của các ô này thành

0x82d76d1b75fe2fd9a27dfbaa65a039221a380d76c926f378d3f81cf3e7e13f2e, chuỗi số này sẽ trỏ tới tập lệnh Nervos DAO[10]. Tập lệnh khóa cho các ô này sẽ không thay đổi. Vì tập lệnh loại và tập lệnh khóa của Nervos DAO được tách biệt nên kẻ tấn công không bao giờ có thể sử dụng CKByte trong các cửa hàng này mà không có sự cho phép của người dùng.

Nếu bạn muốn giải nén CKByte bị khóa, bạn phải cung cấp chứng chỉ (chữ ký) tương ứng với tập lệnh khóa. Quá trình xác minh này không thông qua bất kỳ hợp đồng thông minh nào mà được đảm bảo bởi mạng CKB và không có lựa chọn thay thế nào khác. Ở đây, kịch bản của Nervos DAO là đảm bảo rằng khi người dùng thoát khỏi DAO, họ có thể nhận được khoản bồi thường chính xác thông qua tính toán, thay vì giữ tiền (của người dùng).

Tác động đến DeFi

Hiện rất khó để phân tích định lượng tác động của rủi ro hợp đồng thông minh đối với DeFi, nhưng chúng tôi có thể nhận được một số manh mối từ các sản phẩm bảo hiểm do Nexus Mutual cung cấp[11], một loại bảo hiểm thay thế phi tập trung. Sản phẩm đầu tiên của nó, SmartContractCover[12], cho phép người dùng mua bảo hiểm cho bất kỳ hợp đồng thông minh nào, để nếu hợp đồng thông minh bị hack, người dùng có thể nhận được khoản bồi thường tương ứng. Phí bảo hiểm hợp đồng thông minh được xác định bởi thị trường và có liên quan tích cực đến thời hạn hợp đồng và số tiền bảo đảm. Theo bài viết này [13], 1000 DAI trong Nuo tương ứng với phí bảo hiểm 90 ngày là 6,41 DAI, trong khi 1 ETH trong Uniswap tương ứng với phí bảo hiểm 365 ngày là 0,013 ETH. Dựa trên những dữ liệu này, chúng tôi có thể ước tính sơ bộ rằngchi phí rủi ro hàng năm hiện tại của hợp đồng thông minh là khoảng 2%.

Chi phí 2% này là do sự kém hiệu quả của thị trường do rủi ro hợp đồng thông minh gây ra, do đó việc cải thiện thông minh Mô hình lập trình hợp đồng là vô cùng quan trọng. Một mô hình lập trình khác có thể giảm rủi ro của hợp đồng thông minh và mang lại cho chúng ta một thị trường DeFi hiệu quả hơn.

Xin cảm ơn Haseeb Qureshi, Cipher Wang và Christopher Heymann vì phản hồi của họ về bài viết này.

Liên kết trích dẫn:

[1]. https://arxiv.org/abs/ 1908.04507
[2]. https://blog.peckshield.com/2018/04/28/transferFlaw/
[3]. https://blog.peckshield.com/2018/05/23/allowAnyone /
[4]. https://blog.peckshield.com/2019/09/27/ItchySwap/
[5]. https://blog.peckshield.com/2018/05/03/ownerAnyone /
[6]. https://en.wikipedia.org/wiki/First-class_citizen
[7]. https://talk.nervos.org/t/discussion-on-udt-standard- đánh giá-tiêu chí/3774;
https://talk.nervos.org/t/approach-to-designing-a-user-d xác định-token-standard-on-ckb-part-1/3855;
https://talk.nervos.org/t/proposal-minimal-udt-implementation-and-extensions/3932;
[8]. https://github.com/nervosnetwork/rfcs/blob/master/rfcs /0023-dao-deposit-withdraw/0023-dao-deposit-withdraw.md
[9]. https://explorer.nervos.org/nervosdao
[10]. https://github.com /nervosnetwork/ckb-system-scripts/blob/master/c/dao.c
[11]. https://nexusmutual.io/
[12]. https://nexusmutual.io/pages/ SmartcontactCoverWordingv1.0.pdf
[13]. https://medium.com/nexus-mutual/smart-contract-cover-is-now-live-91b3015f99eb

Liên kết gốc: mp. weixin .qq.com