Nhận Diện Rủi Ro Upgradeable Proxy: Các Lỗi Bảo Mật Smart Contract Nhà Đầu Tư Crypto Cần Biết

Upgradeable Proxy là một trong những cơ chế phổ biến nhất để giữ cho smart contract có thể nâng cấp sau khi đã triển khai, nhưng cũng chính cơ chế này làm tăng thêm một lớp tin cậy, một lớp quản trị và một lớp bề mặt tấn công mà nhà đầu tư crypto không nên xem nhẹ. Nếu mục tiêu của bạn là nhận diện rủi ro upgradeable proxy, câu trả lời ngắn gọn là: có rủi ro thật, và rủi ro nằm ở quyền nâng cấp, cách tách proxy với implementation, storage layout, cũng như quy trình vận hành sau khi audit.

Đi sâu hơn, người đọc thường không chỉ muốn biết “Upgradeable Proxy là gì”, mà muốn hiểu nó nguy hiểm ở đâu, lỗi nào xuất hiện nhiều nhất, và vì sao một dự án đã audit vẫn có thể gặp sự cố nếu dùng proxy sai cách. Những lỗi như uninitialized proxy, storage collision, hoặc cấp quyền nâng cấp quá tập trung đều có thể biến một hệ thống tưởng như an toàn thành điểm yếu nghiêm trọng.

Ở góc độ thực dụng hơn, nhà đầu tư thường quan tâm một câu hỏi khác: liệu có thể tự sàng lọc rủi ro upgradeable proxy trước khi xuống tiền không. Câu trả lời là có, ở mức cơ bản. Bạn không cần là auditor chuyên nghiệp để kiểm tra xem dự án có multisig, timelock, verified contract, cơ chế upgrade minh bạch hay không. Những tín hiệu này không thay thế audit, nhưng đủ để loại bớt nhiều dự án có bề mặt rủi ro cao.

Tiếp theo, để đi từ hiểu khái niệm sang nhận diện rủi ro thật sự, bài viết sẽ lần lượt giải thích cơ chế của Upgradeable Proxy, nhóm lỗi bảo mật phổ biến, checklist kiểm tra cho nhà đầu tư, sự khác nhau giữa Transparent Proxy, UUPS và Beacon Proxy, rồi kết thúc bằng các tín hiệu cảnh báo cho thấy một dự án dùng proxy nhưng không an toàn.

Upgradeable Proxy là gì và vì sao nó tạo ra rủi ro bảo mật trong smart contract?

Upgradeable Proxy là một kiến trúc smart contract dùng proxy contract để giữ địa chỉ và trạng thái, còn implementation contract giữ logic; khi cần nâng cấp, dự án thay implementation thay vì thay địa chỉ contract chính.

Để hiểu vì sao Upgradeable Proxy vừa hữu ích vừa tạo rủi ro, cần nhớ rằng blockchain vốn đề cao tính bất biến. Proxy xuất hiện để giải quyết mâu thuẫn giữa “không thể sửa code đã deploy” và “vẫn cần vá lỗi hoặc thêm tính năng”. Chính vì thêm một cơ chế đổi logic, hệ thống cũng đồng thời thêm một cơ chế có thể bị lạm dụng, bị cấu hình sai hoặc bị chiếm quyền. Đó là lý do mọi phân tích về upgradeable contract luôn phải đi cùng phân tích về quyền admin, governance và quy trình upgrade.

Upgradeable Proxy có phải là mô hình giúp smart contract thay đổi logic sau khi triển khai không?

Có, Upgradeable Proxy cho phép smart contract thay đổi logic sau khi triển khai mà vẫn giữ nguyên địa chỉ contract, trạng thái lưu trữ và điểm truy cập của người dùng.

Cụ thể hơn, điểm quan trọng nhất nằm ở chỗ người dùng không tương tác trực tiếp với implementation, mà tương tác với proxy. Proxy sẽ chuyển tiếp lời gọi bằng delegatecall sang implementation hiện tại. Khi dự án nâng cấp, phần được thay là implementation address hoặc logic quản lý implementation, còn proxy vẫn đứng ở vị trí cũ. Lợi ích là giao diện dùng không đổi, dữ liệu vẫn giữ nguyên, hệ thống có thể sửa lỗi mà không bắt người dùng di chuyển tài sản. Nhưng cái giá phải trả là người dùng phải tin rằng quyền nâng cấp sẽ không bị lạm dụng.

Upgradeable Proxy hoạt động như thế nào trong smart contract?

Upgradeable Proxy là mô hình trong đó proxy giữ storage, implementation giữ code, còn delegatecall cho phép code của implementation chạy trong ngữ cảnh của proxy.

Để hiểu rõ hơn, hãy hình dung proxy như mặt tiền của một cửa hàng và implementation là bộ máy vận hành phía sau. Người dùng gửi lệnh đến proxy. Proxy không tự xử lý phần lớn nghiệp vụ, mà chuyển lệnh sang implementation. Tuy nhiên, vì dùng delegatecall, mọi thay đổi trạng thái lại được ghi vào storage của chính proxy. Đây là chi tiết rất quan trọng: logic ở một nơi, dữ liệu ở một nơi khác, nên bất kỳ sai lệch nào giữa hai bên, nhất là về storage layout, đều có thể gây lỗi nặng. Proxy và delegatecall là điểm có thể tạo ra rủi ro đặc thù khi contract được trao hoặc mô phỏng quyền vượt ngoài ý định ban đầu.

Vì sao khả năng nâng cấp lại làm tăng bề mặt tấn công của dự án crypto?

Khả năng nâng cấp làm tăng bề mặt tấn công vì hệ thống phải thêm ít nhất ba lớp rủi ro: quyền nâng cấp, logic nâng cấp và rủi ro tương thích giữa các phiên bản implementation.

Nói cách khác, một smart contract không nâng cấp được có thể lỗi nhưng khó bị “thay đổi bản chất” sau khi deploy. Ngược lại, contract dùng proxy có thể bị đổi sang implementation mới, và implementation đó có thể thêm phí ẩn, khóa rút tiền, thay công thức tính toán, hoặc mở backdoor nếu quản trị bị xâm nhập. Đây là lý do nhiều nhà đầu tư giỏi không chỉ xem tokenomics hay TVL, mà còn xem kỹ quyền admin và lịch sử nâng cấp. Trong thực tế, rủi ro smart contract không chỉ là bug trong code hiện tại, mà còn là khả năng code có thể bị thay đổi về sau.

Theo các phân tích kỹ thuật về upgradable smart contract, việc đưa proxy vào kiến trúc là cách phổ biến để giải quyết tính bất biến của blockchain, nhưng cũng tạo thêm nguy cơ tấn công vì hợp đồng nắm giữ lượng tài sản lớn trở thành mục tiêu hấp dẫn khi quyền nâng cấp tồn tại.

Những rủi ro bảo mật phổ biến nào của Upgradeable Proxy nhà đầu tư crypto cần nhận diện?

Có 5 nhóm rủi ro Upgradeable Proxy chính: lỗi phân quyền upgrade, lỗi khởi tạo, lỗi storage layout, lỗi nâng cấp sai implementation và lỗi quy trình governance/vận hành.

Nói cách khác, khi bạn đọc một dự án có dùng proxy, đừng chỉ dừng ở câu “đã audit”. Hãy truy lần lượt xem ai có quyền upgrade, upgrade diễn ra thế nào, logic mới có thể thay gì, và giữa proxy với implementation có đang chia sẻ storage an toàn hay không. Đây là phần cốt lõi của việc nhận diện rủi ro upgradeable proxy, vì phần lớn sự cố không đến từ một bug đơn lẻ, mà đến từ tổ hợp giữa code, quyền và vận hành.

Upgradeable Proxy có thể bị chiếm quyền nâng cấp trái phép không?

Có, Upgradeable Proxy có thể bị chiếm quyền nâng cấp trái phép nếu access control yếu, private key admin bị lộ, multisig bị kiểm soát hoặc governance bị thao túng.

Cụ thể, đây là rủi ro lớn nhất vì khi quyền upgrade bị chiếm, hacker không nhất thiết phải phá toàn bộ logic cũ. Họ chỉ cần trỏ proxy sang implementation độc hại hoặc implementation có thêm hàm rút tiền, đổi tham số quan trọng, hoặc làm hỏng quyền truy cập của người dùng. Với một số giao thức, việc “không bị hack hôm nay” không đồng nghĩa “không thể bị đổi luật vào ngày mai”. Ở góc độ đầu tư, đây là điểm bạn nên nhìn như một loại risk premium: dự án càng tập trung quyền upgrade, nhà đầu tư càng phải đòi hỏi mức độ minh bạch và kiểm soát cao hơn.

Các lỗi phổ biến của Upgradeable Proxy gồm những nhóm nào?

Có 5 nhóm lỗi Upgradeable Proxy chính: lỗi quyền nâng cấp, lỗi khởi tạo, lỗi storage collision, lỗi function/selector clash và lỗi implementation độc hại hoặc nâng cấp sai quy trình.

Để bạn dễ theo dõi, bảng dưới đây tóm tắt các nhóm lỗi bảo mật thường gặp trong hệ thống proxy nâng cấp:

Cụ thể hơn, nhà đầu tư không cần nhớ hết thuật ngữ kỹ thuật, nhưng nên nhớ quy luật: mọi khi hệ thống cho phép đổi logic sau deploy, quyền đổi logic luôn là điểm cần soi đầu tiên. Từ đó mới đi đến những lỗi sâu hơn như storage collision hay selector clash. Khi bạn từng tìm hiểu lỗi oracle manipulation là gì, bạn sẽ thấy một điểm chung quan trọng: không phải lúc nào hacker cũng đập trực diện vào nơi giữ tiền; đôi khi họ tấn công vào lớp “ra quyết định” của hệ thống. Với oracle manipulation, lớp quyết định là nguồn giá; với upgradeable proxy, lớp quyết định là quyền nâng cấp và logic implementation.

Uninitialized proxy và storage collision nguy hiểm ra sao?

Uninitialized proxy nguy hiểm vì kẻ tấn công có thể chiếm quyền cấu hình ban đầu; storage collision nguy hiểm vì bản nâng cấp mới có thể ghi đè hoặc đọc sai dữ liệu cũ trong proxy.

Cụ thể hơn, ở mô hình upgradeable contract, constructor không hoạt động như contract thường, nên dự án phải dùng initializer. Nếu đội ngũ cấu hình sai hoặc quên initialize đúng lúc, quyền sở hữu hay biến quan trọng có thể bị người khác chiếm mất. Trường hợp storage collision còn khó chịu hơn: contract mới thêm biến hoặc đổi thứ tự biến mà không giữ layout tương thích, từ đó khiến dữ liệu cũ bị diễn giải sai. Một biến “owner” có thể thành “fee”, hoặc một cờ pause có thể đè lên vị trí dữ liệu khác, gây hậu quả khó đoán. Đây là dạng lỗi vừa kỹ thuật vừa thực dụng: dev có thể xem là bug code, còn nhà đầu tư phải xem là risk quản trị tài sản.

Theo các hướng dẫn kỹ thuật về writing upgradeable contracts, constructor không dùng được trong hệ thống proxy; thay vào đó phải dùng initializer và tuân thủ chặt thứ tự khởi tạo. Việc nhiều implementation ghi vào cùng storage của proxy mà không kiểm soát layout có thể dẫn đến storage clashes, một trong những nguyên nhân rủi ro nổi bật của smart contract nâng cấp.

Nhà đầu tư crypto nên kiểm tra rủi ro Upgradeable Proxy bằng cách nào?

Nhà đầu tư có thể kiểm tra rủi ro Upgradeable Proxy bằng 6 bước cơ bản: xác định quyền upgrade, xem governance, kiểm tra timelock, xác minh contract, đọc audit và rà lịch sử nâng cấp.

Để hiểu rõ hơn, phần này không nhằm biến bạn thành auditor, mà giúp bạn có một bộ lọc đủ mạnh trước khi bỏ vốn. Trong crypto, rất nhiều thiệt hại không đến từ việc “không biết code”, mà đến từ việc không đặt câu hỏi đúng về quyền lực trong hệ thống. Nếu bạn biết soi đúng 6 điểm dưới đây, bạn đã đi trước phần lớn nhà đầu tư chỉ nhìn chart, narrative hoặc TVL.

Có thể tự kiểm tra rủi ro Upgradeable Proxy trước khi đầu tư không?

Có, bạn có thể tự kiểm tra rủi ro Upgradeable Proxy ở mức cơ bản trước khi đầu tư, dù không thể thay thế audit chuyên sâu.

Cụ thể, mức “tự kiểm tra” gồm ba việc: đọc public docs, đọc on-chain config và đọc báo cáo audit. Bạn không cần hiểu mọi opcode, nhưng bạn cần trả lời được: ai giữ quyền upgrade, quyền đó có cần nhiều chữ ký không, có thời gian chờ trước khi nâng cấp không, và code hiện tại có được verify hay không. Nếu dự án né tránh những câu này, đó đã là một dữ kiện đầu tư quan trọng. Cũng giống như việc bạn học revoke approval và vì sao cần để giảm rủi ro sau khi đã cấp quyền token cho dApp, việc hiểu Upgradeable Proxy giúp bạn giảm rủi ro trước khi gửi tài sản vào một hệ thống có thể đổi logic về sau. Hai việc này khác nhau về kỹ thuật nhưng giống nhau ở tư duy: kiểm soát quyền trước khi quyền bị lạm dụng.

Checklist đánh giá rủi ro Upgradeable Proxy gồm những gì?

Checklist đánh giá rủi ro Upgradeable Proxy gồm 6 điểm chính: chủ thể giữ quyền upgrade, cấu trúc multisig, timelock, tình trạng verify code, chất lượng audit và lịch sử nâng cấp.

Dưới đây là checklist ngắn gọn nhưng đủ dùng cho nhà đầu tư crypto:

• Ai giữ quyền upgrade?
  Là EOA, multisig hay DAO? Quyền càng tập trung, rủi ro càng cao.
• Có timelock không?
  Nếu không có thời gian chờ, dự án có thể đổi logic rất nhanh trước khi cộng đồng kịp phản ứng.
• Code có verify trên explorer không?
  Không verify là dấu hiệu xấu vì bạn khó đối chiếu implementation hiện tại.
• Đã có audit chưa?
  Có audit tốt hơn không audit, nhưng phải xem audit bao phủ đúng phiên bản đang chạy.
• Lịch sử upgrade có minh bạch không?
  Các lần nâng cấp trước có được công bố, giải thích và kiểm thử hay không?
• Có cơ chế giảm quyền hay từ bỏ quyền upgrade không?
  Một số dự án trưởng thành sẽ chuyển sang governance chặt hơn hoặc khóa bớt quyền theo thời gian.

Khi áp dụng checklist này, bạn đừng chỉ tìm câu trả lời “có” hoặc “không”, mà phải nhìn cả chất lượng câu trả lời. Ví dụ, “có multisig” chưa chắc đã an toàn nếu số signer ít, signer tập trung, hoặc không công khai quy trình vận hành. “Có audit” chưa chắc đã mạnh nếu audit quá cũ hoặc không bao phủ module proxy.

Báo cáo audit có đủ để kết luận Upgradeable Proxy an toàn không?

Không, báo cáo audit không đủ để kết luận Upgradeable Proxy an toàn tuyệt đối vì rủi ro còn nằm ở governance, key management, quy trình upgrade và các thay đổi diễn ra sau thời điểm audit.

Cụ thể, audit là lớp giảm thiểu rủi ro chứ không phải giấy miễn trừ rủi ro. Một bản audit tốt thường đánh giá code tại một thời điểm nhất định. Nhưng sau đó dự án có thể thay implementation, thêm module, đổi signer, chuyển quyền upgrade hoặc thay quy trình triển khai. Nếu nhà đầu tư chỉ nhìn logo công ty audit mà không xem audit version, phạm vi audit và các lần upgrade sau audit, bạn đang dùng một chỉ báo tiện lợi thay cho phân tích thật. Trong DeFi, nhiều case rủi ro không xuất phát từ việc không có audit, mà từ việc thay đổi hệ thống sau audit hoặc vận hành trái với giả định ban đầu.

Transparent Proxy, UUPS và Beacon Proxy khác nhau thế nào về mức độ rủi ro?

Transparent Proxy mạnh ở tách riêng admin, UUPS linh hoạt và tiết kiệm hơn ở phía proxy, còn Beacon Proxy phù hợp khi cần nâng cấp đồng loạt nhiều proxy nhưng làm tăng rủi ro tập trung vào beacon.

Để bạn nhìn rõ hơn, bảng dưới đây so sánh ba mô hình proxy phổ biến nhất theo góc độ đầu tư và bảo mật:

Nói cách khác, không có mô hình nào “an toàn mặc định”. Mô hình chỉ là khung. Mức rủi ro thực sự phụ thuộc vào cách nhóm phát triển triển khai access control, test migration, khóa quyền và công bố thay đổi cho cộng đồng.

Transparent Proxy và UUPS Proxy khác nhau thế nào về cơ chế nâng cấp?

Transparent Proxy đặt logic nâng cấp ở proxy/admin layer, còn UUPS đặt logic authorize và upgrade chủ yếu ở implementation; vì vậy UUPS linh hoạt hơn nhưng cũng đòi hỏi đội ngũ cẩn thận hơn khi triển khai.

Cụ thể hơn, Transparent Proxy thường đi với ProxyAdmin và phân biệt rõ admin với user thường. Điều này giúp tránh một số nhầm lẫn trong hành vi gọi hàm. Trong khi đó, UUPS chuyển phần lớn logic upgrade sang implementation contract, nên proxy gọn hơn. Trade-off ở đây là gì? Nếu đội ngũ triển khai đúng, UUPS có thể hiệu quả hơn. Nhưng nếu authorize upgrade viết sai, initializer xử lý chưa chuẩn, hoặc implementation mở ra khả năng nâng cấp không mong muốn, rủi ro có thể tăng mạnh.

Beacon Proxy có phù hợp với mọi dự án DeFi không?

Không, Beacon Proxy không phù hợp với mọi dự án DeFi vì lợi thế nâng cấp đồng loạt đi kèm rủi ro tập trung vào beacon contract và quyền của chủ thể kiểm soát beacon.

Cụ thể, Beacon Proxy hữu ích khi một hệ thống có nhiều proxy instance cần cùng trỏ về một implementation thống nhất. Điều này hay gặp trong những kiến trúc muốn scale theo nhiều pool, vault hoặc account abstraction. Nhưng chính vì nhiều proxy phụ thuộc cùng một beacon, nếu beacon bị kiểm soát sai hoặc upgrade độc hại, tác động sẽ lan rộng. Vì thế, Beacon phù hợp về mặt vận hành nhưng không mặc định phù hợp về mặt risk appetite. Đội ngũ dùng Beacon cần chứng minh governance và bảo vệ beacon đủ mạnh.

Mô hình proxy nào thường khiến nhà đầu tư cần cảnh giác hơn?

Nhà đầu tư nên cảnh giác hơn với mô hình có quyền upgrade tập trung, authorize mơ hồ hoặc lịch sử nâng cấp thiếu minh bạch; không phải chỉ vì nó là Transparent, UUPS hay Beacon.

Nói thẳng hơn, đừng biến câu hỏi “mô hình nào nguy hiểm hơn” thành một câu trả lời nhị phân quá đơn giản. Transparent Proxy có thể an toàn hơn trong tay đội ngũ kỷ luật, nhưng vẫn nguy hiểm nếu ProxyAdmin do một ví đơn lẻ nắm. UUPS có thể tinh gọn và tốt nếu triển khai chuẩn, nhưng dễ thành điểm chết nếu implementation cho phép authorize sai. Beacon tiện cho vận hành, nhưng có thể trở thành “single point of failure”. Trong đầu tư, cái bạn cần xếp hạng không chỉ là pattern, mà là pattern + governance + quality of execution.

Những tín hiệu cảnh báo nào cho thấy dự án dùng Upgradeable Proxy nhưng không an toàn?

Có 4 tín hiệu cảnh báo lớn: quyền upgrade quá tập trung, quy trình nâng cấp thiếu timelock, tài liệu kỹ thuật mập mờ và lịch sử nâng cấp không minh bạch.

Sau khi đã hiểu cơ chế, nhóm lỗi và checklist, phần còn lại là nhìn ra “red flags” trong thực tế. Đây là nơi nhiều nhà đầu tư bỏ qua nhất, vì họ tưởng rủi ro chỉ nằm trong code. Thực ra, với Upgradeable Proxy, red flag thường nằm ở cách đội ngũ dùng quyền lực kỹ thuật. Một dự án có thể viết code tốt nhưng vẫn tạo ra cấu trúc rủi ro nếu giữ quá nhiều quyền, thiếu thời gian chờ, hoặc không công bố đầy đủ việc nâng cấp.

Dự án giữ quyền upgrade tập trung có phải là dấu hiệu rủi ro cao không?

Có, quyền upgrade tập trung là dấu hiệu rủi ro cao vì một điểm kiểm soát đơn lẻ có thể thay toàn bộ logic của hệ thống, dù code hiện tại đang an toàn.

Cụ thể hơn, khi một ví đơn lẻ hoặc một nhóm signer quá nhỏ nắm quyền upgrade, nhà đầu tư đang thực chất đặt niềm tin vào con người nhiều hơn vào code. Trong bull market, điều này thường bị bỏ qua vì narrative tăng trưởng lấn át quản trị rủi ro. Nhưng khi sự cố xảy ra, đây lại là câu hỏi đầu tiên cộng đồng quay lại: ai có thể đổi implementation, và họ đã làm điều đó dưới cơ chế kiểm soát nào? Nếu câu trả lời là “một địa chỉ EOA” hoặc “team giữ quyền để linh hoạt”, bạn nên định giá lại mức độ an toàn của dự án.

Vì sao quy trình nâng cấp không có timelock hoặc không minh bạch là tín hiệu xấu?

Không có timelock hoặc không minh bạch là tín hiệu xấu vì người dùng không có thời gian quan sát, phản ứng hoặc rút tài sản trước khi logic hệ thống bị thay đổi.

Để hiểu rõ hơn, timelock không phải chi tiết “cho đẹp”, mà là lớp giảm rủi ro hành vi. Nó tạo độ trễ giữa quyết định nâng cấp và thời điểm nâng cấp có hiệu lực, nhờ đó cộng đồng có cơ hội kiểm tra, tranh luận và thoát vị thế nếu cần. Khi dự án thiếu timelock, một thay đổi bất lợi có thể được áp dụng gần như ngay lập tức. Trong đầu tư on-chain, độ minh bạch của quá trình thay đổi luật chơi quan trọng không kém nội dung của luật chơi.

Những chi tiết nào trong audit report hoặc tài liệu kỹ thuật thường bị nhà đầu tư bỏ qua?

Nhà đầu tư thường bỏ qua phạm vi audit, phiên bản implementation được audit, giả định về quyền admin và chi tiết khởi tạo hoặc authorize upgrade trong tài liệu kỹ thuật.

Cụ thể, nhiều người đọc audit theo kiểu “có tên hãng lớn là đủ”. Nhưng với Upgradeable Proxy, bạn cần soi kỹ hơn: audit đang nói về implementation nào, thời điểm nào, và có nói gì về quyền upgrade không. Tương tự, trong docs kỹ thuật, những dòng tưởng nhỏ như “initializer chỉ được gọi một lần”, “ProxyAdmin thuộc multisig nào”, “có emergency upgrade path hay không” lại là nơi chứa rất nhiều thông tin định giá rủi ro. Nếu bạn đã quen tự bảo vệ ví bằng cách kiểm tra allowance, học revoke approval và vì sao cần, thì logic đó nên được mở rộng lên cấp hệ thống: quyền càng lớn, cơ chế thu hồi và kiểm soát quyền càng phải rõ.

Khi nào nên tránh hoàn toàn một dự án dùng Upgradeable Proxy?

Bạn nên tránh hoàn toàn một dự án dùng Upgradeable Proxy khi dự án không verify code, không minh bạch quyền upgrade, không có timelock, audit quá cũ hoặc có lịch sử nâng cấp bất thường không được giải thích rõ.

Tóm lại, Upgradeable Proxy không phải dấu hiệu xấu tự thân. Nó là công cụ trung tính. Điều quyết định mức độ nguy hiểm là cách công cụ đó được quản trị. Nếu dự án minh bạch, có cơ chế khóa quyền hợp lý, dùng multisig nghiêm túc, công bố nâng cấp và kiểm thử bài bản, proxy có thể là một giải pháp cần thiết để sửa lỗi và thích ứng. Nhưng nếu dự án mập mờ về quyền, không cho cộng đồng thời gian phản ứng, hoặc liên tục thay đổi implementation mà thiếu giải trình, nhà đầu tư nên xem đó là red flag đủ mạnh để đứng ngoài. Trong crypto, bảo toàn vốn thường bắt đầu từ việc hiểu đúng cấu trúc quyền lực ẩn sau smart contract, chứ không chỉ từ việc tìm dự án “có vẻ đang hot”.