Khả năng nâng cấp hợp đồng thông minh

Khả năng nâng cấp hợp đồng thông minh là gì?

Khả năng nâng cấp hợp đồng thông minh là khả năng thay đổi, thay thế, mở rộng hoặc chuyển hướng logic của một hệ thống hợp đồng thông minh đã triển khai sau lần triển khai đầu tiên.

Trong crypto, khả năng nâng cấp được sử dụng vì nhiều hợp đồng thông minh quản lý tài sản thực tế, và đội ngũ có thể cần sửa lỗi, cải thiện tính năng, cập nhật tích hợp hoặc phản hồi vấn đề bảo mật sau khi ra mắt.

Tài liệu Ethereum về nâng cấp hợp đồng thông minh chính thức giải thích rằng hợp đồng thông minh thường được xem là bất biến, nhưng nhà phát triển có thể sử dụng các mô hình nâng cấp khi cần thay đổi trong tương lai.

Một hợp đồng thông minh cơ bản đã triển khai thường giữ nguyên mã vĩnh viễn, trừ khi được thiết kế với cơ chế nâng cấp.

Hệ thống hợp đồng thông minh có thể nâng cấp tách địa chỉ hướng đến người dùng, trạng thái được lưu trữ và logic nghiệp vụ để đưa logic mới vào mà không buộc người dùng tự di chuyển thủ công.

Mô hình nâng cấp phổ biến nhất sử dụng proxy contract mà người dùng tương tác cùng implementation contract chứa logic hiện tại.

Khi implementation thay đổi, địa chỉ proxy có thể giữ nguyên trong khi mã phía sau thay đổi.

Điều này hữu ích cho người dùng vì số dư, quyền và tích hợp có thể tiếp tục trỏ đến cùng địa chỉ.

Điều này cũng rủi ro vì người hoặc hệ thống quản trị có quyền nâng cấp có thể thay đổi hành vi hợp đồng sau khi người dùng nạp tiền.

Nói đơn giản, khả năng nâng cấp hợp đồng thông minh là thiết kế phần mềm on-chain để logic có thể được cập nhật sau này trong khi vẫn giữ trạng thái quan trọng, tính liên tục của địa chỉ và quyền truy cập người dùng.

Vì sao khả năng nâng cấp hợp đồng thông minh quan trọng?

Khả năng nâng cấp hợp đồng thông minh quan trọng vì mã blockchain đã triển khai có thể kiểm soát token, kho quỹ, thị trường cho vay, hệ thống staking, bridge, NFT hoặc quyền quản trị.

Lỗi trong mã bất biến có thể khóa tài sản, làm hỏng chức năng người dùng hoặc khiến tiền dễ bị kẻ tấn công khai thác.

Khả năng nâng cấp cho nhà phát triển cách vá vấn đề nghiêm trọng và cải thiện giao thức sau khi triển khai.

Hướng dẫn OpenZeppelin về nâng cấp hợp đồng thông minh giải thích rằng triển khai có thể nâng cấp có thể sửa đổi mã hợp đồng trong khi duy trì địa chỉ, trạng thái và số dư.

Việc bảo toàn này quan trọng vì người dùng, ví, công cụ phân tích và giao thức khác có thể đã phụ thuộc vào địa chỉ hợp đồng ban đầu.

Nếu không có khả năng nâng cấp, đội ngũ có thể phải triển khai hợp đồng mới và yêu cầu người dùng tự di chuyển tiền hoặc quyền phê duyệt.

Quá trình di chuyển có thể chậm, rủi ro, tốn kém và khó hiểu.

Tuy nhiên, khả năng nâng cấp cũng thay đổi mô hình tin cậy của hợp đồng thông minh.

Hợp đồng có thể nâng cấp không hoàn toàn bất biến giống hợp đồng không có cơ chế nâng cấp.

Người dùng luôn nên hỏi ai có thể nâng cấp hợp đồng, nâng cấp được phê duyệt thế nào, nâng cấp có thể diễn ra nhanh đến đâu và người dùng có thể rút tiền trước khi thay đổi lớn có hiệu lực không.

Khả năng nâng cấp hợp đồng thông minh hoạt động như thế nào?

Khả năng nâng cấp hợp đồng thông minh thường hoạt động bằng cách tách lưu trữ khỏi logic.

Proxy contract giữ địa chỉ mà người dùng gọi và thường lưu trạng thái chính của hệ thống.

Implementation contract chứa logic xác định chức năng hoạt động như thế nào.

Khi người dùng gọi proxy, proxy chuyển tiếp lệnh gọi đến implementation contract hiện tại.

Trong các hệ thống theo kiểu Ethereum, việc chuyển tiếp này thường dùng delegatecall, cơ chế chạy logic implementation trong ngữ cảnh lưu trữ của proxy.

Điều này nghĩa mã implementation có thể đọc và ghi dữ liệu lưu trữ của proxy như thể dữ liệu đó thuộc về implementation.

Khi giao thức nâng cấp, tài khoản được ủy quyền hoặc quy trình quản trị thay đổi địa chỉ implementation được lưu trong proxy.

Sau thay đổi, các lệnh gọi trong tương lai sẽ đến logic implementation mới.

Dữ liệu lưu trữ cũ có thể giữ nguyên, nên số dư người dùng và trạng thái giao thức có thể tiếp tục nếu bố cục lưu trữ tương thích.

Thiết kế này mạnh mẽ nhưng đòi hỏi quy tắc nghiêm ngặt về bố cục lưu trữ, khởi tạo, ủy quyền, kiểm toán và quản trị nâng cấp.

Proxy contract

Proxy contract là địa chỉ hợp đồng ổn định mà người dùng và hợp đồng khác tương tác trong nhiều hệ thống có thể nâng cấp.

Proxy thường lưu trạng thái và chuyển tiếp lệnh gọi hàm đến implementation contract.

Tài liệu mô hình nâng cấp proxy của OpenZeppelin mô tả mô hình proxy lưu trữ phi cấu trúc là khối xây dựng nền tảng cho hợp đồng có thể nâng cấp.

Proxy hữu ích vì người dùng không cần đổi địa chỉ hợp đồng mỗi khi logic được nâng cấp.

Ứng dụng, ví, dashboard và tích hợp DeFi có thể tiếp tục dùng cùng địa chỉ proxy.

Mô hình proxy cũng tạo độ phức tạp vì người dùng có thể thấy một địa chỉ hợp đồng, trong khi logic thực tế nằm ở địa chỉ khác.

Trình khám phá blockchain thường hiển thị thông tin proxy và địa chỉ implementation khi có thể nhận diện mô hình.

Người dùng nên kiểm tra cả proxy và implementation khi đánh giá hợp đồng có thể nâng cấp.

Proxy không tự động an toàn vì mức độ an toàn phụ thuộc vào kiểm soát nâng cấp, khả năng tương thích lưu trữ và chất lượng mã implementation.

Proxy là cánh cửa, còn implementation là logic phía sau cánh cửa.

Implementation contract

Implementation contract là hợp đồng chứa logic nghiệp vụ được proxy sử dụng.

Hợp đồng này có thể định nghĩa chức năng chuyển tiền, nạp, rút, cho vay, bỏ phiếu, mint, burn, tạm dừng, thanh lý hoặc các hành động giao thức khác.

Người dùng thường không tương tác trực tiếp với địa chỉ implementation trong hệ thống dựa trên proxy.

Thay vào đó, họ tương tác với proxy và proxy ủy quyền thực thi cho implementation.

Nâng cấp thường là thay đổi proxy để trỏ đến implementation contract mới.

Implementation mới nên tương thích với bố cục lưu trữ cũ và kỳ vọng của người dùng.

Nâng cấp implementation nguy hiểm có thể thêm logic độc hại, làm hỏng kế toán, thay đổi quyền hoặc chặn rút tiền.

Đây là lý do mã implementation nên được xác minh, kiểm toán, kiểm thử và xem xét trước khi thực hiện nâng cấp.

Người dùng không nên cho rằng giao thức sẽ giữ nguyên mãi chỉ vì địa chỉ proxy không thay đổi.

Trong hệ thống có thể nâng cấp, địa chỉ implementation là phần then chốt của câu chuyện bảo mật.

Delegatecall

Delegatecall là cơ chế EVM cấp thấp cho phép một hợp đồng thực thi mã từ hợp đồng khác trong khi sử dụng ngữ cảnh lưu trữ của bên gọi.

Trong khả năng nâng cấp proxy, delegatecall cho phép proxy dùng logic implementation nhưng giữ trạng thái ở địa chỉ proxy.

Đây là lý do implementation mới có thể thay đổi hành vi mà không cần di chuyển số dư người dùng khỏi proxy.

Delegatecall mạnh mẽ vì tách mã khỏi trạng thái.

Delegatecall rủi ro vì implementation phải giả định đang ghi vào dữ liệu lưu trữ proxy, không phải dữ liệu riêng.

Nếu implementation dùng bố cục lưu trữ khác dự kiến, biến có thể xung đột hoặc làm hỏng trạng thái.

Thiết kế delegatecall sai có thể khiến biến quyền sở hữu, số dư, mapping hoặc giá trị cấu hình bị ghi đè.

Nhà phát triển nên tránh viết logic delegatecall proxy tùy chỉnh trừ khi hiểu đầy đủ về lưu trữ và thực thi EVM.

Người dùng không cần hiểu từng opcode, nhưng nên biết proxy có thể nâng cấp dựa vào sự gián tiếp kỹ thuật này.

Delegatecall là một lý do hợp đồng có thể nâng cấp cần kiểm toán chuyên biệt.

Bố cục lưu trữ

Bố cục lưu trữ là thứ tự và vị trí các biến trong dữ liệu lưu trữ hợp đồng thông minh.

Tài liệu bố cục lưu trữ Solidity chính thức giải thích cách biến trạng thái được bố trí trong lưu trữ và vì sao các quy tắc bố cục quan trọng với hợp đồng và thư viện.

Bố cục lưu trữ là một trong các rủi ro nâng cấp quan trọng nhất.

Nếu implementation mới thay đổi sai thứ tự, loại hoặc cấu trúc biến hiện có, proxy có thể diễn giải dữ liệu lưu trữ cũ theo cách mới và lỗi.

Ví dụ, mapping số dư có thể bị dịch chuyển, địa chỉ owner có thể bị ghi đè hoặc biến cấu hình có thể được đọc dưới loại khác.

Đây được gọi là rủi ro xung đột lưu trữ hoặc hỏng lưu trữ.

Nhà phát triển thường thêm biến mới sau biến hiện có thay vì chèn vào giữa.

Họ cũng tránh thay đổi loại biến hoặc thứ tự kế thừa nếu không có kế hoạch di chuyển cẩn trọng.

Công cụ nâng cấp hiện đại có thể so sánh bố cục lưu trữ trước khi cho phép nâng cấp.

Người dùng nên coi an toàn bố cục lưu trữ là phần cốt lõi của bảo mật hợp đồng có thể nâng cấp.

Storage slot proxy ERC-1967

ERC-1967 là tiêu chuẩn xác định các storage slot cụ thể cho thông tin proxy như địa chỉ implementation, địa chỉ admin và địa chỉ beacon.

Tiêu chuẩn ERC-1967 chính thức xác định storage slot proxy tiêu chuẩn để công cụ và trình khám phá nhận diện cấu hình proxy đáng tin cậy hơn.

Các slot tiêu chuẩn này giảm khả năng biến quản lý proxy xung đột với biến lưu trữ ứng dụng.

ERC-1967 cũng giúp trình khám phá blockchain hiển thị implementation mà proxy đang sử dụng.

Nhiều hệ thống proxy hiện đại dựa vào slot tương thích ERC-1967.

Tiêu chuẩn không tự làm nâng cấp trở nên an toàn.

Tiêu chuẩn chủ yếu cung cấp nơi có thể dự đoán để lưu metadata proxy.

Nhà phát triển vẫn cần ủy quyền đúng, xác thực bố cục lưu trữ, xem xét implementation và thực thi nâng cấp an toàn.

Người dùng đánh giá hợp đồng có thể nâng cấp nên kiểm tra proxy có tuân theo tiêu chuẩn đã biết thay vì mô hình tùy chỉnh không rõ hay không.

Lưu trữ proxy tiêu chuẩn cải thiện tính minh bạch, nhưng chỉ là một phần của an toàn khả năng nâng cấp hợp đồng thông minh.

Mô hình Transparent Proxy

Mô hình Transparent Proxy tách lệnh gọi admin khỏi lệnh gọi người dùng để giảm nhầm lẫn function selector giữa hàm proxy và hàm implementation.

Tài liệu proxy OpenZeppelin giải thích rằng TransparentUpgradeableProxy có giao diện admin và nâng cấp tích hợp.

Trong mô hình này, người dùng thông thường tương tác với các hàm implementation qua proxy.

Admin proxy thực hiện hành động nâng cấp và không nên vô tình gọi hàm implementation qua proxy theo cách người dùng thực hiện.

Thiết kế này giúp tránh xung đột khi hàm proxy và hàm implementation có cùng selector.

Transparent proxy được sử dụng rộng rãi vì cung cấp mô hình admin rõ ràng.

Tuy nhiên, chúng vẫn yêu cầu quản lý khóa admin an toàn.

Nếu admin proxy bị kiểm soát bởi một khóa bị lộ, toàn bộ giao thức có thể gặp rủi ro.

Transparent proxy có thể an toàn khi kết hợp kiểm soát đa chữ ký, timelock, kiểm toán và quản trị rõ ràng.

Mô hình này giảm một rủi ro kỹ thuật nhưng không loại bỏ rủi ro quản trị.

Mô hình UUPS Proxy

UUPS là viết tắt của Universal Upgradeable Proxy Standard.

Tiêu chuẩn EIP-1822 chính thức mô tả mô hình proxy có thể nâng cấp phổ quát, trong đó logic nâng cấp gắn với thiết kế implementation.

Tài liệu OpenZeppelin giải thích rằng UUPSUpgradeable bao gồm cơ chế nâng cấp trong implementation contract thay vì sử dụng cấu trúc admin tích hợp của proxy như transparent proxy.

UUPS proxy có thể nhẹ hơn transparent proxy vì bản thân proxy đơn giản hơn.

Tuy nhiên, implementation phải bao gồm và bảo vệ chính xác các hàm nâng cấp.

Implementation UUPS kém có thể vô tình loại bỏ khả năng nâng cấp, làm lộ quyền nâng cấp hoặc cho phép nâng cấp trái phép.

Nhà phát triển cũng phải bảo vệ khỏi việc nâng cấp lên implementation làm hỏng đường nâng cấp.

UUPS có thể hiệu quả và linh hoạt khi dùng với thư viện trưởng thành và công cụ xác thực.

Không nên sao chép một cách mù quáng nếu chưa hiểu ủy quyền và kiểm tra an toàn nâng cấp.

Người dùng nên kiểm tra ai kiểm soát nâng cấp UUPS và các nâng cấp trước đây có minh bạch, được kiểm toán không.

Mô hình Beacon Proxy

Mô hình Beacon Proxy sử dụng beacon contract để lưu địa chỉ implementation cho nhiều proxy.

Thay vì mỗi proxy tự lưu địa chỉ implementation, mỗi proxy đọc implementation từ beacon.

Điều này cho phép nâng cấp cùng lúc nhiều instance proxy bằng cách cập nhật một beacon.

Beacon proxy hữu ích cho hệ thống triển khai nhiều hợp đồng tương tự, như vault, pool, tài khoản hoặc instance hợp đồng riêng cho người dùng.

Chúng có thể giảm độ phức tạp vận hành khi nhiều instance cần cùng một nâng cấp.

Chúng cũng có thể tăng phạm vi ảnh hưởng vì nâng cấp beacon lỗi có thể ảnh hưởng đến nhiều proxy cùng lúc.

Tài liệu proxy OpenZeppelin bao gồm BeaconProxy và UpgradeableBeacon như các thành phần liên quan đến proxy.

Quyền beacon phải được bảo vệ cẩn thận vì có thể kiểm soát logic của nhiều hợp đồng.

Người dùng nên kiểm tra hợp đồng họ sử dụng có phụ thuộc beacon không và ai có thể cập nhật beacon đó.

Beacon thuận tiện cho nhà phát triển, nhưng tập trung quyền nâng cấp vào điểm kiểm soát dùng chung.

Mô hình Diamond Proxy

Mô hình Diamond Proxy cho phép một hợp đồng giống proxy định tuyến lệnh gọi hàm đến nhiều implementation contract gọi là facet.

Tiêu chuẩn Diamond EIP-2535 chính thức xác định hệ thống hợp đồng thông minh mô-đun, nơi các hàm có thể được thêm, thay thế hoặc loại bỏ qua facet.

Diamond hữu ích cho hệ thống lớn có thể vượt giới hạn kích thước hợp đồng hoặc cần nâng cấp theo mô-đun.

Diamond có thể tổ chức logic phức tạp thành nhiều facet riêng trong khi giữ một địa chỉ chính.

Tính linh hoạt này có thể mạnh mẽ với hệ thống DeFi lớn, game, hệ thống tài khoản hoặc framework giao thức.

Điều này cũng làm tăng độ phức tạp vì người dùng và kiểm toán viên phải hiểu định tuyến facet, bảng selector, mô hình lưu trữ và quyền nâng cấp.

Nâng cấp diamond có thể thay thế chỉ một phần hệ thống, khiến việc theo dõi thay đổi trở nên quan trọng.

Thiết kế lưu trữ đặc biệt quan trọng vì nhiều facet có thể dùng chung cùng dữ liệu lưu trữ.

Nhà phát triển nên sử dụng mô hình diamond storage hoặc namespaced storage rõ ràng khi phù hợp.

Người dùng nên xem hợp đồng diamond là hệ thống có thể nâng cấp nâng cao cần xem xét cẩn trọng.

Lưu trữ theo không gian tên

Namespaced storage là phương pháp tổ chức dữ liệu lưu trữ hợp đồng để các mô-đun khác nhau dùng vị trí lưu trữ xác định và giảm rủi ro xung đột.

Tiêu chuẩn ERC-7201 Namespaced Storage Layout chính thức xác định quy ước ghi lại vị trí lưu trữ của namespaced storage trong mã nguồn Solidity.

Namespaced storage hữu ích trong hợp đồng có thể nâng cấp và mô-đun vì giảm sự phụ thuộc vào một thứ tự biến đơn giản trong chuỗi kế thừa dài.

Phương pháp này có thể làm nâng cấp an toàn hơn khi hợp đồng được xây dựng từ nhiều mô-đun.

Phương pháp này cũng có thể giúp công cụ xác thực thay đổi lưu trữ rõ hơn khi compiler và framework hỗ trợ.

Hướng dẫn OpenZeppelin về viết hợp đồng có thể nâng cấp lưu ý Solidity 0.8.20 hoặc cao hơn là bắt buộc để plugin nâng cấp xác thực namespaced storage layout bằng thông tin compiler cần thiết.

Namespaced storage không loại bỏ nhu cầu kiểm toán.

Phương pháp này giúp cấu trúc trạng thái để quản lý thay đổi trong tương lai dễ hơn.

Nhà phát triển nên sử dụng namespaced storage nhất quán nếu chọn kiến trúc này.

Người dùng hưởng lợi gián tiếp vì thiết kế lưu trữ an toàn hơn giảm khả năng hỏng trạng thái do nâng cấp.

Initializer

Initializer là hàm thiết lập đặc biệt được hợp đồng có thể nâng cấp sử dụng thay cho constructor.

Trong hợp đồng thông thường, constructor chạy khi hợp đồng được triển khai.

Trong hệ thống proxy, người dùng tương tác với proxy và constructor implementation không khởi tạo dữ liệu lưu trữ proxy theo cách thông thường.

Đây là lý do implementation có thể nâng cấp thường dùng hàm initializer để thiết lập owner, tên token, quyền, giá trị cấu hình và trạng thái ban đầu khác.

Initializer chỉ nên chạy một lần, trừ khi reinitializer được thiết kế cẩn thận để dùng cho nâng cấp sau này.

Nếu initializer bị để mở, kẻ tấn công có thể khởi tạo hợp đồng và chiếm quyền kiểm soát vai trò quan trọng.

Nếu implementation mới cần biến trạng thái mới, có thể cần reinitializer để cấu hình chúng an toàn.

Nhà phát triển phải bảo vệ initializer và vô hiệu hóa khởi tạo trên implementation contract độc lập khi phù hợp.

Người dùng nên cẩn trọng khi hợp đồng có thể nâng cấp có lịch sử khởi tạo không rõ ràng.

Lỗi khởi tạo là nguồn lớn của lỗ hổng hợp đồng có thể nâng cấp.

Quyền nâng cấp

Quyền nâng cấp là tài khoản, hợp đồng, ví đa chữ ký, timelock, DAO hoặc hệ thống quản trị có thể phê duyệt nâng cấp.

Quyền nâng cấp là một trong các giả định tin cậy quan trọng nhất trong hợp đồng có thể nâng cấp.

Nếu một khóa riêng tư kiểm soát nâng cấp, khóa đó có thể thay thế logic giao thức.

Nếu ví đa chữ ký kiểm soát nâng cấp, người dùng phải tin cậy nhóm người ký và bảo mật vận hành của nhóm.

Nếu DAO kiểm soát nâng cấp, người dùng phải hiểu quyền biểu quyết, quorum, thời gian trì hoãn đề xuất, thời gian trì hoãn thực thi và rủi ro tấn công quản trị.

Nếu timelock kiểm soát nâng cấp, người dùng có thể có thời gian xem xét và rút tiền trước khi thay đổi có hiệu lực.

Quy trình nâng cấp an toàn thường kết hợp thực thi đa chữ ký, trì hoãn timelock, công bố đề xuất công khai, xem xét kiểm toán và giám sát.

Quyền nâng cấp nên hiển thị rõ và được ghi lại.

Người dùng không nên coi hợp đồng có thể nâng cấp là không cần tin cậy nếu một nhóm nhỏ có thể thay đổi ngay lập tức.

Trong hệ thống có thể nâng cấp, thiết kế quản trị cũng là thiết kế bảo mật.

Timelock

Timelock trì hoãn việc thực thi sau khi nâng cấp được đề xuất hoặc phê duyệt.

Sự trì hoãn này cho người dùng, kiểm toán viên, nhà nghiên cứu và hệ thống giám sát thời gian để xem xét thay đổi sắp tới.

Timelock có thể giảm rủi ro nâng cấp bất ngờ làm thay đổi hành vi hợp đồng ngay lập tức.

Timelock cũng có thể cho người dùng thời gian rút tiền nếu không đồng ý với nâng cấp.

Tuy nhiên, timelock không hoàn hảo vì sửa lỗi khẩn cấp có thể cần tốc độ trong các cuộc tấn công đang diễn ra.

Một số hệ thống sử dụng lộ trình khẩn cấp ngắn hơn và lộ trình quản trị thông thường dài hơn.

Lộ trình khẩn cấp có thể bảo vệ người dùng khỏi khai thác, nhưng cũng có thể tạo rủi ro tập trung hóa.

Giao thức tốt giải thích rõ quy tắc timelock.

Người dùng nên kiểm tra nâng cấp có bị trì hoãn, diễn ra ngay lập tức hay do quyền khẩn cấp kiểm soát.

Timelock có giá trị vì biến quyền nâng cấp tức thì thành quyền lực trì hoãn có thể quan sát.

Nâng cấp do quản trị kiểm soát

Nâng cấp do quản trị kiểm soát dùng bỏ phiếu token, bỏ phiếu ủy quyền, phê duyệt hội đồng, đề xuất DAO hoặc hệ thống tương tự để phê duyệt thay đổi implementation.

Điều này có thể khiến nâng cấp phi tập trung hơn một khóa admin.

Điều này cũng có thể khiến nâng cấp chậm và phức tạp hơn.

Bảo mật quản trị phụ thuộc vào phân phối quyền biểu quyết, quy tắc quorum, ngưỡng đề xuất, trì hoãn bỏ phiếu, trì hoãn thực thi, ủy quyền và khả năng chống mua phiếu hoặc tấn công quản trị bằng flash loan.

Một phiếu quản trị không tự động nghĩa là thay đổi an toàn về mặt kỹ thuật.

Người bỏ phiếu có thể phê duyệt mã mà họ không hiểu hoàn toàn.

Đề xuất độc hại có thể che giấu logic nguy hiểm trong gói nâng cấp lớn.

Giao thức nên công bố khác biệt nâng cấp rõ ràng, kiểm toán, kết quả mô phỏng và giải thích bằng ngôn ngữ dễ hiểu trước khi bỏ phiếu.

Người dùng nên xem quy trình nâng cấp quản trị trước khi nạp tài sản vào giao thức.

Quản trị có thể phân phối quyền lực, nhưng không loại bỏ nhu cầu xem xét bảo mật kỹ thuật.

Hợp đồng bất biến và hợp đồng có thể nâng cấp

Hợp đồng thông minh bất biến không thể thay đổi sau khi triển khai, trừ khi được thiết kế với kiểm soát bên ngoài hoặc lộ trình di chuyển.

Hợp đồng thông minh có thể nâng cấp có thể thay đổi logic qua cơ chế nâng cấp xác định.

Hợp đồng bất biến có thể dễ phân tích hơn vì mã triển khai giữ cố định.

Chúng cũng có thể nguy hiểm nếu phát hiện lỗi nghiêm trọng mà không có cách sửa an toàn.

Hợp đồng có thể nâng cấp có thể sửa lỗi và thêm tính năng.

Chúng cũng có thể tạo rủi ro tin cậy vì logic tương lai có thể khác mã mà người dùng ban đầu đã xem xét.

Không có mô hình nào luôn tốt hơn.

Hợp đồng token đơn giản có thể ưu tiên tính bất biến nếu quy tắc không nên thay đổi.

Giao thức DeFi phức tạp có thể cần khả năng nâng cấp để vá bảo mật và thích ứng điều kiện thị trường thay đổi.

Thiết kế phù hợp phụ thuộc vào rủi ro, độ phức tạp, mức độ trưởng thành quản trị và kỳ vọng người dùng.

Di chuyển và khả năng nâng cấp

Di chuyển là triển khai hợp đồng mới và chuyển người dùng, tài sản hoặc tích hợp từ hợp đồng cũ sang hợp đồng mới.

Khả năng nâng cấp là thay đổi logic phía sau địa chỉ hoặc hệ thống hiện có trong khi duy trì trạng thái hoặc tính liên tục hướng đến người dùng.

Di chuyển có thể dễ hiểu hơn vì hợp đồng cũ không thay đổi và hợp đồng mới tách biệt.

Di chuyển có thể gây khó khăn vì người dùng có thể phải phê duyệt chuyển tiền, di chuyển vị thế, nhận token mới hoặc cập nhật tích hợp.

Khả năng nâng cấp có thể tạo trải nghiệm người dùng mượt mà hơn vì cùng địa chỉ vẫn hoạt động.

Khả năng nâng cấp cũng có thể che giấu thay đổi lớn sau cùng địa chỉ.

Một số giao thức sử dụng cả hai phương pháp tùy mức độ nghiêm trọng của thay đổi.

Sửa lỗi nhỏ có thể dùng nâng cấp, trong khi tái thiết kế lớn có thể dùng di chuyển.

Người dùng nên hiểu giao thức có thể thay đổi tại chỗ hay yêu cầu di chuyển thủ công.

Rủi ro di chuyển và rủi ro nâng cấp khác nhau, nhưng đều cần truyền thông cẩn trọng.

Xác minh mã nguồn

Xác minh mã nguồn giúp người dùng so sánh mã nguồn được công bố với bytecode đã triển khai.

Tài liệu xác minh hợp đồng thông minh Ethereum chính thức giải thích rằng xác minh so sánh mã nguồn hợp đồng thông minh và bytecode đã biên dịch.

Với hợp đồng có thể nâng cấp, người dùng nên xác minh cả proxy và implementation hiện tại khi có thể.

Chỉ proxy đã xác minh có thể không hiển thị toàn bộ logic nghiệp vụ.

Implementation đã xác minh giúp người dùng đọc logic hiện tại, nhưng họ vẫn nên kiểm tra quyền nâng cấp.

Khi giao thức nâng cấp, implementation mới cũng nên được xác minh.

Người dùng không nên giả định hợp đồng vẫn an toàn vì implementation trước đó đã được kiểm toán.

Nâng cấp có thể thêm hàm mới, thay đổi quyền, sửa kế toán hoặc tạo lỗi mới.

Xác minh là bước minh bạch, không phải bảo đảm bảo mật đầy đủ.

Hệ thống có thể nâng cấp cần xác minh liên tục sau mỗi lần nâng cấp.

Storage gap

Storage gap là các slot lưu trữ dự phòng chưa dùng được thêm vào hợp đồng có thể nâng cấp để phiên bản tương lai có thể thêm biến mà không làm dịch chuyển bất ngờ dữ liệu lưu trữ của hợp đồng con.

Mô hình này phổ biến trong hợp đồng có thể nâng cấp sử dụng nhiều kế thừa.

Storage gap có thể xuất hiện dưới dạng mảng chưa dùng với kích thước cố định dành cho biến tương lai.

Khi nâng cấp sau này thêm biến trạng thái, nhà phát triển có thể giảm kích thước gap tương ứng.

Storage gap hữu ích, nhưng cần tính kỷ luật.

Dùng gap không đúng vẫn có thể gây vấn đề bố cục lưu trữ.

Namespaced storage là phương pháp mới hơn, có thể giảm sự phụ thuộc vào storage gap lớn trong một số kiến trúc.

Nhà phát triển nên tuân theo hướng dẫn của framework nâng cấp và công cụ compiler.

Kiểm toán viên nên xem storage gap và thay đổi bố cục trong mọi lần nâng cấp.

Người dùng không cần quản lý storage gap, nhưng hưởng lợi khi nhà phát triển sử dụng đúng.

Kiểm thử nâng cấp

Kiểm thử nâng cấp đánh giá implementation mới có hoạt động chính xác với trạng thái proxy hiện có không.

Unit test thông thường là chưa đủ vì có thể triển khai hợp đồng mới với dữ liệu lưu trữ trống.

Kiểm thử nâng cấp nên mô phỏng phiên bản cũ, điền trạng thái thực tế, thực hiện nâng cấp rồi kiểm tra phiên bản mới với trạng thái hiện có.

Kiểm thử nên kiểm tra số dư, quyền, kế toán, phê duyệt token, phân công vai trò, cài đặt oracle, logic tạm dừng và vị thế người dùng.

Kiểm thử cũng nên xác nhận người dùng không được ủy quyền không thể nâng cấp hợp đồng.

Fork testing có thể giúp mô phỏng nâng cấp với trạng thái chuỗi thực khi phù hợp.

Công cụ xác thực bố cục lưu trữ có thể phát hiện nhiều thay đổi không an toàn trước khi triển khai.

Phạm vi kiểm thử nên bao gồm cả trường hợp thành công và thất bại.

Mọi nâng cấp nên được coi là triển khai mới với rủi ro di chuyển bổ sung.

Giao thức nâng cấp mà không kiểm thử nghiêm túc đang khiến người dùng đối mặt với nguy hiểm có thể tránh được.

Kiểm toán nâng cấp

Kiểm toán nâng cấp xem xét implementation mới, thay đổi lưu trữ, logic initializer hoặc reinitializer, kiểm soát truy cập và đường thực thi quản trị.

Kiểm toán nâng cấp nên so sánh phiên bản cũ với phiên bản mới.

Mục tiêu không chỉ là kiểm tra mã mới mà còn hiểu mã mới ảnh hưởng thế nào đến trạng thái hiện có và người dùng.

Kiểm toán viên nên xem bố cục lưu trữ, lệnh gọi bên ngoài, quyền, ủy quyền nâng cấp, kiểm soát khẩn cấp, sự kiện và khả năng tương thích với tích hợp.

Họ cũng nên xem nâng cấp có tạo thay đổi phá vỡ ABI với ứng dụng gọi hợp đồng không.

Kiểm toán không đảm bảo an toàn, nhưng giảm rủi ro.

Giao thức lớn nên công bố báo cáo hoặc tóm tắt kiểm toán khi nâng cấp ảnh hưởng đến tiền người dùng.

Nâng cấp nhỏ vẫn có thể nguy hiểm nếu tác động đến kế toán, quyền, rút tiền hoặc logic oracle.

Người dùng nên kiểm tra nâng cấp implementation lớn có được kiểm toán trước khi tin tưởng không.

Kiểm toán nâng cấp là biện pháp phòng vệ cốt lõi trước hồi quy ẩn.

Tương thích ABI

Tương thích ABI nghĩa là ứng dụng bên ngoài có thể tiếp tục gọi hợp đồng như kỳ vọng sau nâng cấp.

ABI xác định tên hàm, đầu vào, đầu ra, sự kiện và lỗi mà ví và ứng dụng sử dụng.

Nâng cấp có thể phá vỡ tương thích nếu loại bỏ hàm, thay đổi loại trả về, thay đổi hành vi sự kiện hoặc thay đổi giả định mà bên tích hợp phụ thuộc.

Thay đổi ABI phá vỡ có thể khiến ứng dụng front-end, bot, hệ thống kế toán hoặc tích hợp DeFi thất bại.

Dù lưu trữ an toàn, trải nghiệm người dùng vẫn có thể hỏng nếu giao diện thay đổi mà không phối hợp.

Nhà phát triển nên ghi lại rõ thay đổi ABI trước khi nâng cấp.

Bên tích hợp nên theo dõi nâng cấp implementation của giao thức mà họ phụ thuộc.

Người dùng có thể thấy giao dịch thất bại nếu ứng dụng không được cập nhật cho implementation mới.

Tương thích ABI là một phần của an toàn nâng cấp vì hợp đồng thông minh tồn tại trong hệ sinh thái rộng hơn.

Nâng cấp hợp lệ về kỹ thuật vẫn có thể gây ảnh hưởng đến người dùng thực nếu giao diện thay đổi bất cẩn.

Rủi ro khóa admin

Rủi ro khóa admin là nguy cơ khóa hoặc tài khoản kiểm soát nâng cấp bị đánh cắp, lạm dụng, mất hoặc do bên không đáng tin cậy kiểm soát.

Nếu kẻ tấn công có quyền nâng cấp, họ có thể triển khai logic độc hại để rút tiền hoặc thay đổi số dư.

Nếu khóa admin bị mất, đội ngũ có thể không thể vá lỗi trong tương lai.

Nếu một người kiểm soát khóa admin, người dùng phải tin người đó không hành động độc hại hoặc cẩu thả.

Ví đa chữ ký có thể giảm rủi ro một khóa bằng cách yêu cầu nhiều phê duyệt.

Timelock có thể giảm rủi ro nâng cấp bất ngờ bằng cách thêm thời gian trì hoãn.

Quản trị DAO có thể phân phối quyền nâng cấp nhưng tạo rủi ro tấn công quản trị.

Giao thức nên công bố ai kiểm soát nâng cấp và khóa được bảo mật như thế nào.

Người dùng nên xem kiểm soát admin bị ẩn hoặc không rõ là dấu hiệu cảnh báo lớn.

Trong hợp đồng có thể nâng cấp, bảo mật admin thường quan trọng ngang với bảo mật mã.

Nâng cấp khẩn cấp

Nâng cấp khẩn cấp là nâng cấp nhanh để sửa lỗ hổng nghiêm trọng hoặc ngăn chặn tấn công đang diễn ra.

Chúng có thể bảo vệ tiền người dùng khi chờ một chu kỳ quản trị đầy đủ là quá chậm.

Nâng cấp khẩn cấp cũng có thể tạo rủi ro tập trung hóa vì có thể bỏ qua xem xét, bỏ phiếu hoặc trì hoãn timelock thông thường.

Giao thức nên xác định quyền khẩn cấp trước khi tình huống khẩn cấp xảy ra.

Kiểm soát khẩn cấp nên có phạm vi hẹp, được ghi lại, giám sát và quản lý bởi quy trình đáng tin cậy.

Sau nâng cấp khẩn cấp, đội ngũ nên công bố thông tin rõ ràng về điều đã thay đổi và lý do.

Người dùng nên hiểu giao thức có quyền nâng cấp khẩn cấp không.

Giao thức không có lộ trình khẩn cấp có thể phản hồi chậm hơn trước khai thác.

Giao thức có quyền khẩn cấp không giới hạn có thể đòi hỏi quá nhiều tin cậy.

Thiết kế tốt nhất cân bằng bảo vệ nhanh với minh bạch và trách nhiệm giải trình.

Token có thể nâng cấp

Token có thể nâng cấp là token contract có logic có thể thay đổi sau khi triển khai.

Điều này có thể cho phép sửa lỗi, thay đổi tuân thủ, mô hình phí mới, thay đổi bridge hoặc cập nhật tính năng.

Điều này cũng có thể cho phép thay đổi nguy hiểm như quyền mint mới, hạn chế chuyển tiền, blacklist hoặc phí bất ngờ.

Người dùng nên kiểm tra token contract có thể nâng cấp không trước khi giả định quy tắc token cố định.

Token có quyền nâng cấp có thể thay đổi hành vi dù tên, ký hiệu và địa chỉ giữ nguyên.

Người nắm giữ token nên xem vai trò admin, quyền mint, kiểm soát tạm dừng, hàm blacklist và quản trị nâng cấp.

Mã nguồn đã xác minh nên được kiểm tra sau các nâng cấp lớn.

Nhà cung cấp thanh khoản nên đặc biệt cẩn trọng vì thay đổi quy tắc token có thể ảnh hưởng đến pool giao dịch.

Token có thể nâng cấp có thể hợp pháp, nhưng có mô hình tin cậy khác token bất biến.

Khả năng nâng cấp token nên được công bố rõ cho người dùng.

Giao thức DeFi có thể nâng cấp

Giao thức DeFi có thể nâng cấp có thể thay đổi logic cho vay, swap, staking, thanh lý, chiến lược vault, lãi suất hoặc quy tắc tài sản thế chấp.

Tính linh hoạt này có thể hữu ích vì thị trường DeFi thay đổi nhanh và lỗi có thể nghiêm trọng.

Tính linh hoạt này cũng có thể tạo rủi ro vì quy tắc giao thức có thể thay đổi sau khi người dùng nạp tiền.

Nâng cấp có thể thay đổi logic rút tiền, cách tính phí, tham số rủi ro, nguồn oracle hoặc hành vi thanh lý.

Người dùng nên kiểm tra nâng cấp giao thức DeFi do đội ngũ, ví đa chữ ký, timelock hay quy trình quản trị kiểm soát.

Người dùng cũng nên kiểm tra hợp đồng quan trọng là bất biến hay có thể nâng cấp.

Một giao thức có thể có một số hợp đồng bất biến và một số hợp đồng có thể nâng cấp.

Rủi ro nâng cấp DeFi đặc biệt quan trọng vì hợp đồng thường nắm giữ thanh khoản được gộp.

Một nâng cấp lỗi có thể ảnh hưởng đến nhiều người dùng cùng lúc.

DeFi có thể nâng cấp cần giám sát liên tục, không phải tin cậy một lần.

Khả năng nâng cấp và oracle

Oracle cung cấp dữ liệu bên ngoài, như giá tài sản, cho hợp đồng thông minh.

Giao thức có thể nâng cấp có thể thay đổi logic oracle hoặc địa chỉ oracle.

Tài liệu oracle Ethereum chính thức giải thích oracle cần thiết vì hợp đồng thông minh không thể tự truy cập trực tiếp dữ liệu off-chain.

Khả năng nâng cấp oracle có thể hữu ích khi feed cũ không đáng tin cậy hoặc có nguồn tốt hơn.

Điều này có thể nguy hiểm nếu admin có thể chuyển sang oracle bị thao túng hoặc độc hại.

Trong hệ thống cho vay và phái sinh, nâng cấp oracle lỗi có thể gây thanh lý không công bằng hoặc thanh toán không chính xác.

Người dùng nên kiểm tra ai có thể thay đổi nguồn oracle và các thay đổi đó có timelock không.

Nhà phát triển nên sử dụng quản trị oracle và giám sát mạnh mẽ.

Thay đổi oracle nên được coi là nâng cấp rủi ro cao.

Nguồn dữ liệu là một phần của logic hợp đồng thông minh ngay cả khi nằm ngoài mã hợp đồng chính.

Khả năng nâng cấp và bridge

Bridge thường dùng hợp đồng có thể nâng cấp vì logic bridge phải phản hồi với chuỗi mới, định dạng thông điệp, tập validator, kiểm soát rủi ro và bản vá bảo mật.

Khả năng nâng cấp bridge có thể cải thiện khả năng thích ứng.

Điều này cũng có thể tạo rủi ro tin cậy lớn vì bridge có thể kiểm soát lượng lớn tài sản bị khóa hoặc được mint.

Nâng cấp bridge độc hại có thể thay đổi quy tắc rút, mint wrapped asset không đúng hoặc chuyển hướng tiền.

Người dùng nên kiểm tra quyền nâng cấp bridge, quản trị validator, timelock, kiểm toán và kiểm soát khẩn cấp.

Bridge vốn đã phức tạp vì phụ thuộc nhiều mạng và giả định xác minh.

Khả năng nâng cấp bổ sung thêm một lớp rủi ro.

Bridge contract có quản trị nâng cấp mạnh có thể an toàn hơn bridge do một khóa kiểm soát.

Tuy nhiên, không quy trình nâng cấp nào loại bỏ toàn bộ rủi ro bridge.

Người dùng bridge nên hiểu cả giả định kỹ thuật lẫn quản trị trước khi chuyển tài sản.

Khả năng nâng cấp và niềm tin người dùng

Khả năng nâng cấp tạo ra sự đánh đổi về niềm tin.

Người dùng hưởng lợi từ sửa lỗi và cải thiện tính năng.

Người dùng chấp nhận rủi ro logic tương lai có thể thay đổi theo cách họ không mong muốn.

Quy trình nâng cấp minh bạch có thể cải thiện niềm tin bằng cách cho thấy điều gì sẽ thay đổi trước khi thay đổi.

Quy trình nâng cấp ẩn hoặc tức thì có thể làm giảm niềm tin vì người dùng không thể đánh giá thay đổi kịp thời.

Giao thức nên giải thích quyền nâng cấp bằng ngôn ngữ dễ hiểu.

Giao thức nên công bố địa chỉ implementation, địa chỉ admin, chi tiết timelock, báo cáo kiểm toán và đề xuất quản trị.

Người dùng không nên chỉ hỏi hợp đồng có được kiểm toán không.

Họ nên hỏi liệu mã đã kiểm toán có thể bị thay thế vào ngày mai không.

Trong hợp đồng thông minh có thể nâng cấp, niềm tin phụ thuộc vào cả mã hiện tại và cơ chế kiểm soát thay đổi tương lai.

Cách kiểm tra hợp đồng có thể nâng cấp không

Hãy bắt đầu bằng cách kiểm tra trang hợp đồng trên trình khám phá blockchain để xem hợp đồng có được gắn nhãn proxy không.

Sau đó, kiểm tra địa chỉ implementation nếu trình khám phá hiển thị.

Xem proxy có tuân theo mô hình đã biết như ERC-1967, Transparent Proxy, UUPS, Beacon Proxy hoặc Diamond không.

Kiểm tra mã nguồn implementation có được xác minh không.

Kiểm tra ai kiểm soát nâng cấp qua địa chỉ admin, vai trò owner, ví đa chữ ký, timelock hoặc hợp đồng quản trị.

Xem sự kiện gần đây để biết thay đổi implementation hoặc giao dịch nâng cấp.

Đọc tài liệu giao thức để hiểu chính sách nâng cấp.

Kiểm tra báo cáo kiểm toán để biết khả năng nâng cấp có nằm trong phạm vi kiểm toán không.

Theo dõi đề xuất quản trị nếu giao thức dùng nâng cấp do DAO kiểm soát.

Chỉ địa chỉ hợp đồng là chưa đủ vì hệ thống có thể nâng cấp cần được đánh giá đồng thời về proxy, implementation và cấu trúc quyền hạn.

Các lỗi phổ biến về khả năng nâng cấp hợp đồng thông minh

Một lỗi phổ biến là thay đổi thứ tự biến lưu trữ khi nâng cấp.

Một lỗi khác là quên bảo vệ hàm initializer.

Lỗi thứ ba là dùng một khóa riêng tư làm admin nâng cấp duy nhất.

Lỗi thứ tư là nâng cấp mà không có timelock hoặc thông báo công khai.

Lỗi thứ năm là triển khai implementation mới mà không xác minh mã nguồn.

Lỗi thứ sáu là cho rằng kiểm toán cũ vẫn bao gồm implementation mới.

Lỗi thứ bảy là thay đổi ABI làm hỏng tích hợp.

Lỗi thứ tám là không kiểm thử nâng cấp với trạng thái hiện có giống production.

Lỗi thứ chín là dùng logic proxy tùy chỉnh mà không xem xét sâu.

Lỗi thứ mười là nói hệ thống phi tập trung trong khi một nhóm admin nhỏ có thể thay thế logic ngay lập tức.

Lợi ích của khả năng nâng cấp hợp đồng thông minh

Lợi ích đầu tiên là khả năng sửa lỗi sau khi triển khai.

Lợi ích thứ hai là khả năng thêm tính năng mà không buộc người dùng di chuyển thủ công.

Lợi ích thứ ba là tính liên tục địa chỉ cho người dùng, ví và tích hợp.

Lợi ích thứ tư là năng lực phản hồi tốt hơn trong tình huống khẩn cấp.

Lợi ích thứ năm là khả năng bảo trì dài hạn tốt hơn cho giao thức phức tạp.

Lợi ích thứ sáu là cải tiến sản phẩm mượt mà hơn trong thị trường crypto biến động nhanh.

Lợi ích thứ bảy là khả năng cập nhật tích hợp oracle, tham số rủi ro hoặc phụ thuộc bên ngoài.

Lợi ích thứ tám là giảm trở ngại di chuyển khi thiết kế giao thức phát triển.

Các lợi ích này giải thích vì sao nhiều ứng dụng crypto phức tạp chọn kiến trúc có thể nâng cấp.

Lợi ích mạnh nhất khi quyền nâng cấp minh bạch, an toàn, có trì hoãn, được kiểm toán và được quản trị có trách nhiệm.

Rủi ro và giới hạn của khả năng nâng cấp hợp đồng thông minh

Rủi ro đầu tiên là quyền nâng cấp độc hại hoặc bị xâm phạm.

Rủi ro thứ hai là hỏng lưu trữ khi thay đổi implementation không an toàn.

Rủi ro thứ ba là lạm dụng initializer hoặc reinitializer.

Rủi ro thứ tư là tập trung hóa ẩn qua khóa admin.

Rủi ro thứ năm là tích hợp bị hỏng do thay đổi ABI hoặc hành vi.

Rủi ro thứ sáu là người dùng nhầm lẫn vì địa chỉ hiển thị có thể giữ nguyên trong khi logic thay đổi.

Rủi ro thứ bảy là lạm dụng nâng cấp khẩn cấp.

Rủi ro thứ tám là sự tự tin sai lầm từ kiểm toán chỉ bao gồm implementation cũ.

Rủi ro thứ chín là chiếm quyền quản trị hoặc bỏ phiếu vội vàng.

Rủi ro thứ mười là độ phức tạp khiến hệ thống khó hiểu hơn với người dùng và kiểm toán viên.

Thực tiễn tốt nhất cho nhà phát triển

Khi có thể, hãy dùng thư viện nâng cấp trưởng thành và được xem xét kỹ thay vì mã proxy tùy chỉnh.

Chỉ chọn mô hình nâng cấp rõ ràng như Transparent Proxy, UUPS, Beacon Proxy hoặc Diamond sau khi hiểu các đánh đổi.

Xác thực bố cục lưu trữ trước mọi lần nâng cấp.

Bảo vệ initializer và reinitializer cẩn thận.

Sử dụng kiểm soát đa chữ ký, timelock và quy trình quản trị cho quyền nâng cấp quan trọng.

Công bố địa chỉ implementation, giao dịch nâng cấp và giải thích nâng cấp bằng ngôn ngữ dễ hiểu.

Xác minh mã nguồn cho mọi implementation mới.

Thực hiện kiểm thử nâng cấp với trạng thái giống production và môi trường fork khi phù hợp.

Kiểm toán các nâng cấp lớn trước khi thực thi.

Theo dõi sự kiện nâng cấp và chuẩn bị kế hoạch rollback hoặc ứng phó sự cố khi kiến trúc cho phép.

Thực tiễn tốt nhất cho người dùng

Kiểm tra hợp đồng có thể nâng cấp không trước khi nạp tiền.

Xem ai kiểm soát quyền nâng cấp.

Ưu tiên giao thức sử dụng timelock, kiểm soát đa chữ ký, kiểm toán và quản trị công khai cho nâng cấp.

Kiểm tra mã nguồn implementation hiện tại có được xác minh không.

Không cho rằng kiểm toán cũ bao gồm implementation mới.

Theo dõi thông báo nâng cấp giao thức lớn nếu bạn sử dụng giao thức nhiều.

Hiểu nâng cấp khẩn cấp có thể bỏ qua trì hoãn thông thường hay không.

Xem vai trò admin, kiểm soát tạm dừng, kiểm soát oracle và quyền mint token.

Cân nhắc rút tiền trước các nâng cấp gây tranh cãi hoặc không rõ ràng khi có thể.

Hãy coi khả năng nâng cấp là một giả định tin cậy, không phải chi tiết kỹ thuật nhỏ.

FAQ

Khả năng nâng cấp hợp đồng thông minh nghĩa là gì?

Khả năng nâng cấp hợp đồng thông minh nghĩa là hệ thống hợp đồng thông minh đã triển khai có thể thay đổi logic sau khi triển khai thông qua cơ chế nâng cấp được thiết kế.

Vì sao hợp đồng thông minh được nâng cấp?

Hợp đồng thông minh được nâng cấp để sửa lỗi, thêm tính năng, cải thiện bảo mật, cập nhật tích hợp, điều chỉnh kiểm soát rủi ro hoặc đáp ứng nhu cầu giao thức thay đổi.

Hợp đồng thông minh có thể nâng cấp có kém an toàn hơn không?

Hợp đồng thông minh có thể nâng cấp không tự động kém an toàn hơn, nhưng bổ sung rủi ro liên quan đến kiểm soát admin, bố cục lưu trữ, quản trị và thay đổi implementation trong tương lai.

Proxy contract là gì?

Proxy contract là địa chỉ ổn định chuyển tiếp lệnh gọi đến implementation contract, đồng thời thường giữ trạng thái của hệ thống.

Implementation contract là gì?

Implementation contract chứa logic mà proxy thực thi qua cơ chế ủy quyền.

Rủi ro lớn nhất của nâng cấp hợp đồng thông minh là gì?

Rủi ro lớn nhất là quyền nâng cấp được ủy quyền hoặc bị xâm phạm có thể thay logic an toàn bằng logic lỗi hoặc độc hại.

Rủi ro bố cục lưu trữ là gì?

Rủi ro bố cục lưu trữ là khả năng implementation mới đọc hoặc ghi sai dữ liệu lưu trữ proxy hiện có, làm hỏng trạng thái quan trọng.

Timelock trong khả năng nâng cấp là gì?

Timelock trì hoãn thực thi nâng cấp để người dùng và người đánh giá có thời gian kiểm tra thay đổi được đề xuất trước khi có hiệu lực.

Mã nguồn đã xác minh có nghĩa hợp đồng có thể nâng cấp an toàn không?

Không. Mã nguồn đã xác minh cải thiện tính minh bạch, nhưng người dùng vẫn cần xem quyền nâng cấp, kiểm toán, an toàn lưu trữ, quản trị và rủi ro thay đổi trong tương lai.

Làm sao biết hợp đồng có thể nâng cấp không?

Bạn có thể kiểm tra nhãn proxy trên trình khám phá blockchain, địa chỉ implementation, slot ERC-1967, sự kiện nâng cấp, vai trò admin, tài liệu quản trị và báo cáo kiểm toán.

Kết luận

Khả năng nâng cấp hợp đồng thông minh là phương pháp thiết kế cho phép ứng dụng blockchain thay đổi logic hợp đồng sau khi triển khai trong khi duy trì địa chỉ và trạng thái quan trọng.

Phương pháp này được sử dụng rộng rãi vì ứng dụng crypto thường cần sửa lỗi, cải thiện tính năng, vá bảo mật và cập nhật tích hợp sau khi ra mắt.

Các thiết kế nâng cấp phổ biến nhất sử dụng proxy, implementation contract, delegatecall, storage slot tiêu chuẩn và quyền nâng cấp được kiểm soát.

Khả năng nâng cấp có thể giúp giao thức dễ bảo trì và có khả năng phục hồi hơn, nhưng cũng thay đổi mô hình tin cậy vì mã trong tương lai có thể khác mã người dùng đã xem xét ban đầu.

Độ an toàn của hệ thống có thể nâng cấp phụ thuộc vào kỷ luật bố cục lưu trữ, bảo vệ initializer, xác minh mã nguồn, kiểm thử, kiểm toán, bảo mật khóa admin, timelock và quản trị minh bạch.

Người dùng không nên coi hợp đồng có thể nâng cấp là hoàn toàn bất biến trừ khi quyền nâng cấp đã bị loại bỏ hoặc không thể thực hiện theo thiết kế.

Nhà phát triển không nên coi khả năng nâng cấp là lối tắt đơn giản vì mô hình này bổ sung trách nhiệm kỹ thuật và quản trị đáng kể.

Với người mới, khả năng nâng cấp hợp đồng thông minh nên được hiểu là cách cập nhật phần mềm blockchain sau khi triển khai.

Với người dùng nâng cao, đây là mô hình bảo mật đầy đủ liên quan đến kiến trúc proxy, tương thích lưu trữ, kiểm soát truy cập, thực thi quản trị, giám sát và quyền rút lui của người dùng.

Trong ngữ cảnh thuật ngữ crypto, Smart Contract Upgradeability là khả năng của hệ thống hợp đồng thông minh đã triển khai thay đổi logic qua cơ chế được kiểm soát, đồng thời duy trì trạng thái on-chain quan trọng và địa chỉ hướng đến người dùng.

Điểm chính cần nhớ là khả năng nâng cấp hợp đồng thông minh có thể bảo vệ người dùng khỏi lỗi vĩnh viễn và hỗ trợ giao thức phát triển, nhưng phải được thực hiện với tính minh bạch, kiểm soát mạnh, kiểm thử cẩn trọng và công bố rõ ràng vì quyền nâng cấp cũng có thể trở thành nguồn rủi ro lớn.