Sự vững chắc trên TRON: Viết hợp đồng thông minh cho TVM

Sự vững chắc là ngôn ngữ chủ đạo cho hợp đồng thông minh TRON. Các nhà phát triển quen thuộc với các mẫu Ethereum ERC-20 và DeFi có thể chuyển nhiều kiến ​​thức của họ sang TRC-20 và TVM — chú ý đến các định dạng địa chỉ, chi phí năng lượng và sự khác biệt về chuỗi công cụ.

Hướng dẫn này bao gồm các quy ước Solidity về TRON, triển khai mã thông báo tiêu chuẩn, các cạm bẫy phổ biến và đường dẫn từ mã đến mạng chính.

Solidity → Đường ống TVM

1. Viết tệp .sol bằng pragma solidity
2. Biên dịch qua TronBox/TronIDE → bytecode + ABI
3. Triển khai bằng di chuyển hoặc TronWeb
4. Tương tác qua TronWeb hoặc HTTP trigger
5. Xác minh nguồn trên TronScan

Môi trường thực thi: TVM giải thích.

TRC-20 mẫu

Mã thông báo có thể thay thế tiêu chuẩn sử dụng OpenZeppelin:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract ExampleToken is ERC20, Ownable {
    constructor() ERC20("Example", "EXM") Ownable(msg.sender) {
        _mint(msg.sender, 1_000_000 * 10 ** decimals());
    }

    function mint(address to, uint256 amount) external onlyOwner {
        _mint(to, amount);
    }
}

mint với onlyOwner thuận tiện nhưng nguy hiểm nếu khóa chủ sở hữu bị xâm phạm — hướng dẫn bảo mật.

Xử lý địa chỉ

• Loại address trên chuỗi có dạng hex 20 byte nội bộ
• TronWeb chuyển đổi Base58 T... ↔ hex cho API
• msg.sender là địa chỉ người gọi theo hợp đồng trong TVM

Luôn xác thực đầu vào:

require(to != address(0), "zero address");

Sự khác biệt so với Ethereum Solidity

Kiểm tra lại các bộ bảo vệ quay lại, các mẫu call và delegatecall trên Shasta.

Mô hình tiết kiệm năng lượng

• Gói lưu trữ các biến
• Giảm thiểu các chuỗi trên chuỗi (tên/ký hiệu được chấp nhận khi triển khai)
• Tránh các vòng lặp không giới hạn trên mảng người dùng
• Sử dụng immutable và constant nếu có thể

Các hợp đồng đắt tiền làm tăng chi phí chuyển giao USDT cho các nhà tích hợp.

Quy trình kiểm thử

1. Biên dịch TronBox
2. Triển khai Shasta
3. Kịch bản TronWeb: chuyển, phê duyệt, chuyểnTừ
4. Các trường hợp cạnh mờ: số lượng bằng 0, uint tối đa, số lần thử lại

Các lỗ hổng phổ biến trên TRON

Cùng loại với EVM:

• Tái nhập
• Tràn số nguyên (Solidity 0.8+ có tích hợp kiểm tra)
• Thiếu kiểm soát truy cập trên mint / withdraw
• Danh sách đen Honeypot (token độc hại)

Kiểm toán viên áp dụng các phương pháp Ethereum cho mã byte TVM.

Tích hợp với dApps

Cuộc gọi giao diện người dùng thông qua TronLink được chèn TronWeb:

const contract = await tronWeb.contract(abi, contractAddress);
await contract.transfer(to, amount).send({ feeLimit: 100_000_000 });

Phần cuối: gửi USDT theo chương trình.

Xác minh và xuất bản ABI

Sau triển khai:

• TronScan xác minh hợp đồng
• Xuất bản ABI trong tài liệu dành cho nhà tích hợp
• Chức năng quản trị tài liệu và quyền sở hữu

Ghim phiên bản trình biên dịch

Ghim chính xác phiên bản solc trong cấu hình TronBox. Xác minh TronScan yêu cầu cài đặt trình biên dịch phù hợp bao gồm cả các lần chạy tối ưu hóa. Cài đặt không khớp không xác minh được ngay cả với mã nguồn chính xác.

Nhập đường dẫn và OpenZeppelin

Sử dụng phiên bản @openzeppelin/contracts đã được thử nghiệm trên TVM. Một số mẫu dành riêng cho Ethereum (ví dụ: một số giao diện oracle nhất định) cần được điều chỉnh. Kiểm tra SafeERC20 để biết các tương tác TRC-20 trong hợp đồng của bạn — mã thông báo không chuẩn tồn tại trên TRON với hành vi tính phí khi chuyển khoản phá vỡ các tích hợp ngây thơ.

Danh sách kiểm tra khắc phục sự cố

Nếu có sự cố xảy ra trên TRON, hãy xử lý nó như một vấn đề gỡ lỗi có cấu trúc: xác nhận txid chính xác trên chuỗi, xác minh địa chỉ hợp đồng mục tiêu và chỉ sau đó mới quyết định xem liệu lỗi có thể phục hồi được hay không. Trên TRON, nhiều vấn đề “bí ẩn” chỉ đơn giản là một trong số: mạng sai (mainnet so với testnet), hợp đồng mã thông báo sai (USDT giả / mã thông báo có tên tương tự), không đủ tài nguyên (OUT_OF_ENERGY / băng thông) hoặc độ trễ giao diện người dùng/trình lập chỉ mục giữa ví và trình khám phá.

Bắt đầu với các bước kiểm tra dựa trên chuỗi sau:

• Luôn sao chép toàn bộ txid/hash từ ví hoặc explorer của bạn.
• Xác nhận trạng thái kết quả tx trên TronScan (SUCCESS, REVERT, OUT_OF_ENERGY hoặc vẫn đang chờ xử lý).
• Kiểm tra xem địa chỉ người nhận/hợp đồng có khớp với nội dung bạn định gửi hay không.
• Nếu đó là lệnh gọi hợp đồng, hãy xác nhận rằng bộ chọn chức năng và các tham số phù hợp với tiêu chuẩn mã thông báo mà bạn cho rằng mình đang sử dụng (TRC-20 so với TRC-10 so với BEP-20 trên BSC).

Sau đó áp dụng đường dẫn sửa lỗi cho danh mục của bạn:

• Xác nhận trạng thái và thông số giao dịch.
• Xác minh địa chỉ (hợp đồng mã thông báo, người nhận, bộ định tuyến/người chi tiêu).
• Thêm hoặc ủy quyền tài nguyên (Năng lượng/Băng thông) khi lỗi do tài nguyên.

###Những lỗi thường gặpCác mẫu này gây ra hầu hết các lỗi ở cấp độ người dùng:

• Sử dụng địa chỉ mainnet trên testnet (hoặc ngược lại).
• Sao chép ký hiệu mã thông báo thay vì địa chỉ hợp đồng TRC-20 thực tế.
• Ký sai địa chỉ phê duyệt/chi tiêu do liên kết UI độc hại hoặc lỗi thời.
• Thử lại mà không thay đổi đầu vào bị lỗi (ví dụ: REVERT tiếp tục hoàn nguyên cho đến khi bạn sửa được tham số).

Nếu bạn không chắc chắn, đừng “gửi lại”. Thực hiện một thay đổi có kiểm soát, xác minh trên TronScan rồi tiếp tục.

##Câu hỏi thường gặp

Làm cách nào để biết liệu giao dịch có thực sự được xác nhận hay không?

Sử dụng TronScan và kiểm tra trạng thái kết quả tx. Nhãn “đang chờ xử lý” của ví có thể bị trễ; trạng thái dây chuyền là nguồn gốc của sự thật. Sao chép txid và xác minh SUCCESS/REVERT/OUT_OF_ENERGY, không chỉ văn bản giao diện người dùng.

Tại sao giao diện người dùng khác với TronScan?

Một số ví và dApp sử dụng các bộ chỉ mục hoặc lớp bộ đệm khác nhau. Độ trễ ngắn giữa phát sóng và lập chỉ mục là bình thường; so sánh txid và đợi chuỗi ổn định trước khi kết luận thất bại.

Tôi nên làm gì sau REVERT?

Dừng và giải mã cuộc gọi thất bại. Hầu hết REVERT đều do tham số không hợp lệ, địa chỉ hợp đồng sai, thiếu phê duyệt hoặc không khớp giữa tiêu chuẩn và phương thức mã thông báo. Khắc phục nguyên nhân rồi ký lại.

Ký phê duyệt không giới hạn có an toàn không?

Phê duyệt không giới hạn chỉ an toàn đối với các địa chỉ chi tiêu đáng tin cậy mà bạn đã xác minh (nguồn đã xác minh, bộ định tuyến chính xác và hợp đồng mã thông báo dự kiến). Để thử nghiệm, hãy ưu tiên phê duyệt có giới hạn và thu hồi sau khi bạn hoàn thành.

TRON yêu cầu những tài nguyên gì cho cuộc gọi hợp đồng?

Việc thực thi hợp đồng thông minh chủ yếu tiêu thụ Năng lượng, trong khi byte giao dịch tiêu thụ Băng thông. Nếu bạn nhận được OUT_OF_ENERGY, hãy thêm/đóng băng/ủy thác Năng lượng. Nếu băng thông cạn kiệt, hãy tập trung vào việc giữ đủ chất lỏng TRX để phân bổ byte và tài nguyên.

Làm cách nào để giảm phiếu hỗ trợ?

Hiển thị cho người dùng thông báo rõ ràng về “điều gì đã xảy ra” dựa trên trạng thái chuỗi và liên kết trực tiếp đến hướng dẫn có liên quan (đang chờ xử lý, không thành công, hết năng lượng hoặc xác minh). Lưu trữ txid để bạn có thể hòa giải nhanh chóng.

Hướng dẫn liên quan {#có liên quan}

• TVM giải thích
• Hợp đồng thông minh TronBox
• Xác minh hợp đồng thông minh TRON
• Triển khai TRC-20 TronWeb

Câu hỏi thường gặp

Tôi nên sử dụng phiên bản Solidity nào trên TRON?

Khớp phiên bản được trình biên dịch TronBox hoặc TronIDE của bạn hỗ trợ — thường là 0.8.x. Ghim các phiên bản đang được sản xuất và xác minh bằng cùng một trình biên dịch trên TronScan.

Tôi có thể sử dụng hợp đồng OpenZeppelin trên TRON không?

Đúng. Nhập OpenZeppelin ERC20, Ownable, v.v. và biên dịch bằng TronBox. Xác minh tính tương thích của giấy phép và phiên bản.

Solidity có phải là lựa chọn duy nhất?

Sự vững chắc chiếm ưu thế. Một số công cụ thử nghiệm các ngôn ngữ khác biên dịch sang TVM — mã thông báo sản xuất hầu hết đều là Solidity.

Làm cách nào để gọi một hợp đồng khác?

Mẫu interface + Contract(addr).method() giống hệt Ethereum.

TRC-20 cùng tên tệp với ERC20.sol?

Tên gói OpenZeppelin ghi là ERC20 nhưng triển khai lên TRON dưới dạng hành vi tiêu chuẩn TRC-20.