RWA（Tài Sản Thực Thế, Real World Asset） đang trở thành hướng đi quan trọng trong việc kết hợp sâu sắc giữa Web3 và tài chính truyền thống. So với DeFi truyền thống, các giao thức RWA không chỉ đảm nhận việc luân chuyển tài sản trên chuỗi mà còn trực tiếp phản ánh các tài sản thực như trái phiếu, cổ phần, bất động sản, thiết bị, quyền lợi sinh lợi, v.v., phạm vi an toàn của chúng cũng mở rộng từ “an toàn mã” sang “xác nhận quyền, quản lý tuân thủ và thực thi ngoài chuỗi”.

Từ góc nhìn kiểm toán, thách thức cốt lõi của RWA không còn chỉ là ngăn chặn rủi ro bị đánh cắp tiền, mà là làm thế nào để đảm bảo logic mã, quy tắc kinh doanh và quyền lợi pháp lý thực tế luôn phù hợp: một lần thay đổi quyền hạn có thể liên quan đến phong tỏa tài sản; một lần chuyển khoản bắt buộc có thể ảnh hưởng đến quyền sở hữu thực trong thế giới thực.

Bài viết sẽ hệ thống hóa các module cốt lõi, rủi ro phổ biến và trọng tâm kiểm toán của các giao thức RWA, từ phân loại nhóm giao thức, thực thi tiêu chuẩn đến thực hành kiểm toán an toàn, giúp các nhà phát triển và kiểm toán nhanh chóng xây dựng một phương pháp an toàn hướng tới ánh xạ tài sản thực.

Do giới hạn về độ dài, bài viết sẽ ưu tiên trình bày khung chính, các module then chốt và kết luận trọng tâm, nếu muốn xem toàn bộ nội dung, có thể truy cập GitHub: 获取。

一、前言：从代码审计视角看 RWA

1.1 RWA 协议引入的复合安全维度与审计挑战

Từ góc độ kiểm toán mã, điểm khác biệt lớn nhất của giao thức RWA so với DeFi thông thường gồm ba điểm.

Thứ nhất, bản chất tài sản khác nhau: mã chỉ là một lớp “ ánh xạ”.

Thứ hai, quyền hạn và vai trò ngày càng chặt chẽ và nhạy cảm hơn.

Thứ ba, quy trình kinh doanh xen kẽ giữa chuỗi và ngoài chuỗi.

Trong DeFi truyền thống, vòng đời của một giao dịch gần như được hợp đồng hoàn toàn kiểm soát: từ gọi hàm, tính toán đến cập nhật trạng thái đều thực hiện trên chuỗi.

Trong khi đó, trong RWA, thường thấy là quy trình như sau:

Người dùng gọi redeem() hoặc forcedTransfer() trên chuỗi → hợp đồng cập nhật trạng thái và ghi nhận sự kiện → hệ thống ngoài chuỗi nhận thông báo, thực hiện giao nhận tài sản thực, chuyển nhượng hoặc thanh lý → kết quả sau đó phản hồi theo một cách nào đó (hoặc giữ ngoài chuỗi).

1.2 RWA 审计的核心使命

Trong một dự án RWA điển hình, mục tiêu kiểm toán an toàn không còn chỉ là “ngăn chặn hacker đánh cắp trực tiếp”, mà ít nhất phải giữ vững ba nguyên tắc:

• Đúng đắn và an toàn: mã không thể sai sót.

• Nhất quán: hành vi mã phải phù hợp với quy tắc dự án đã tuyên bố.

• Có thể kiểm tra được: khi có vấn đề phát sinh, chứng cứ trên chuỗi phải rõ ràng, minh bạch.

1.3 本文的视角与边界

Chúng ta sẽ bàn về RWA từ góc độ kiểm toán an toàn.

• Đối với nhà phát triển, bài viết như một “bản thiết kế ngược từ kiểm toán” để hướng dẫn thiết kế.

• Đối với kiểm toán viên, có thể xem như “Hướng dẫn kiểm toán RWA + checklist”.

Cùng với kinh nghiệm “kiểm toán hợp đồng thông minh” đã có, bài viết bổ sung kiến thức chuyên sâu về cấu trúc giao thức RWA và các trọng tâm kiểm toán.

Mục tiêu là giúp nhà phát triển khi viết giao thức RWA có hướng tiếp cận phù hợp, giúp kiểm toán viên khi đối mặt với dự án RWA không chỉ giới hạn ở phần trên chuỗi mà còn có hệ thống phương pháp phù hợp với ánh xạ tài sản thực.

Bài viết này sẽ không cố gắng làm rõ các vấn đề:

• Không đi sâu vào các quy định pháp luật hoặc án lệ của các quốc gia, chỉ đề cập khi cần thiết về “sự tồn tại của các ràng buộc này”;

• Không giải thích từ đầu về Solidity hay tiêu chuẩn ERC cơ bản, giả định người đọc đã có kinh nghiệm kiểm toán DeFi/NFT;

• Không đánh giá dự án theo Tokenomics hay “dự án tốt”, chỉ quan tâm đến độ an toàn, độ tin cậy, nhất quán của mã và mô hình RWA mà nó tuyên bố.

二、RWA 协议与代码模块速览

2.1 从业务出发：先判断是哪一类 RWA

Từ góc độ kiểm toán dựa trên nghiệp vụ, ta có thể sơ bộ phân loại dự án vào bốn nhóm chính sau:

1. RWA dạng chứng khoán / cổ phần / trái phiếu

2. RWA dạng bất động sản / tài sản cố định

3. RWA dạng vật chất / thiết bị / lô hàng

4. RWA dạng quyền lợi sinh lợi / cấu trúc / sở hữu phân chia

2.2 从标准到实现：RWA 常见协议族的“足够了解”

2.2.1 Tiêu chuẩn chứng khoán hợp quy

Nhóm tiêu chuẩn này giải quyết vấn đề: làm thế nào để phát hành và lưu hành “chứng khoán / sản phẩm chứng khoán hóa” trên chuỗi, đồng thời đáp ứng các yêu cầu KYC, hạn chế chuyển nhượng, thao tác bắt buộc theo quy định.

2.2.2 Tiêu chuẩn bất động sản / tài sản cố định

Chìa khóa của RWA bất động sản không nằm ở “phát hành token như thế nào”, mà ở “làm thế nào để cấu trúc hóa các thông tin về bất động sản một cách an toàn, có cấu trúc”.

2.2.3 Tiêu chuẩn thiết bị / vật chất đổi lấy token

Thường phải giải quyết hai vấn đề: token/NFT làm sao liên kết với vật thể thực tế; trong mối liên hệ này, làm thế nào để thực hiện đổi, sử dụng, hủy bỏ.

2.2.4 Tiêu chuẩn cấu trúc tài sản / giao diện chung RWA

Nhóm tiêu chuẩn này hướng tới “cấu trúc phức tạp của tài sản” và “giao diện thống nhất”.

2.3 典型 RWA 合约架构

Dù dự án thuộc nhóm nào trong trên, phần lớn các giao thức RWA đầy đủ đều có cấu trúc mã gồm các module chính sau:

1. Module Token cốt lõi

2. Module quyền hạn và vai trò

3. Module tuân thủ / danh sách trắng

4. Module thu hồi / thanh lý

5. Module siêu dữ liệu / thông tin tài sản

6. Module nâng cấp và quản trị

2.4 RWA 快速定位三步法

Bước 1: Đọc tài liệu nghiệp vụ, xác định loại và tiêu chuẩn tài sản.

Bước 2: Tìm kiếm “từ khóa” trong mã.

Bước 3: Vẽ sơ đồ kiến trúc.

三、协议族深度解构：主流 RWA 标准的合规模型

Chương này sẽ đi sâu phân tích mã nguồn, phân tích các tiêu chuẩn RWA chính hiện nay.

I. 证券型 RWA：ERC-1400 (UniversalToken) 深度分析

1、合约整体架构

Dự án ERC-1400 (UniversalToken) do ConsenSys phát triển, là nền tảng phát hành và quản lý token chứng khoán dựa trên tiêu chuẩn ERC1400, quản lý phân vùng (partition), cơ chế giữ (hold), xác thực chứng chỉ, phát hành quỹ và trao đổi token. Nền tảng này chủ yếu dùng cho phát hành, giao dịch và quản lý chứng khoán hợp quy, có kiểm soát quyền hạn chi tiết và chức năng giám sát.

Khung tổng thể có thể chia thành sáu module cốt lõi:

• Core: Thực thi toàn bộ logic cốt lõi của chứng khoán, gồm phát hành, thu hồi, chuyển khoản và sổ phân vùng (Partition).

• Quản lý vai trò (Roles): Thực hiện kiểm soát truy cập dựa trên vai trò RBAC tinh vi.

• Module xác thực (Validator): Là “bộ não” về tuân thủ của RWA, chứa logic kiểm tra tuân thủ như quản lý danh sách trắng, lọc danh sách đen, xác thực chữ ký chứng chỉ, kiểm soát tạm dừng giao dịch, v.v.

• Mở rộng: Cung cấp các thực thi sẵn phù hợp với các nghiệp vụ đặc thù.

• Mô-đun mở rộng cho người dùng: Thông qua các hook gửi đi và nhận, cho phép token có thể lập trình.

• Module công cụ: Cung cấp các tiện ích như DomainAware, ERC1820, công cụ thao tác hàng loạt.

2、深度剖析 ERC1400 (UniversalToken) 核心合约

2.1 Phân tích cấu trúc dữ liệu chính

2.1.1 Thông tin cơ bản của chứng khoán

Ngoài metadata của ERC20, hợp đồng còn bổ sung các tham số mang ý nghĩa chứng khoán:

• granularity (độ phân giải): đảm bảo đơn vị giao dịch nhỏ nhất của chứng khoán.

• isControllable: cho phép cơ quan quản lý hoặc nhà phát hành bắt buộc chuyển nhượng hoặc thu hồi token khi cần.

• isIssuable: kiểm soát khả năng phát hành thêm token.

• migrated: khi nâng cấp hợp đồng, có thể triển khai phiên bản mới và dùng cơ chế migration để hướng người dùng đến hợp đồng mới, đồng thời đăng ký trong registry trung tâm.

2.1.2 Phân vùng (Partition) - Đổi mới cốt lõi của ERC1400

Cơ chế phân vùng (Partition) là điểm sáng nhất của ERC1400, chia một hợp đồng token thành nhiều phân vùng độc lập, mỗi phân vùng có số dư và tổng cung riêng biệt.

2.1.3 Hệ thống quyền thao tác (Operator)

ERC1400 thiết kế hệ thống quyền thao tác 3 tầng, cân bằng giữa linh hoạt và an toàn.

Tầng 1 là các kiểm soát viên toàn cục (Global Controllers), thường đại diện cho nhà phát hành chứng khoán hoặc cơ quan quản lý có quyền đặc biệt.

Tầng 2 là các thao tác viên được ủy quyền của người dùng (Authorized Operators), tương tự approve của ERC20 nhưng phạm vi rộng hơn.

Tầng 3 là các thao tác viên phân vùng (Partition Operators), đặc thù của ERC1400.

2.1.4 Quản lý tài liệu

• ERC1400 tích hợp tiêu chuẩn quản lý tài liệu ERC1643, giải quyết vấn đề “xác nhận quyền trên chuỗi, lưu trữ ngoài chuỗi” của chứng khoán hợp quy.

• Hệ thống quản lý tài liệu gồm URI, hash và timestamp.

• Quyền thiết lập và xóa tài liệu bị giới hạn chặt chẽ trong phạm vi kiểm soát, đảm bảo chỉ các thực thể ủy quyền mới có thể quản lý tài liệu chính thức.

• Trong thực tế, hệ thống này có thể lưu trữ các thông tin quan trọng.

2.2 Phân tích các module chức năng cốt lõi

2.2.1 Chức năng phát hành (Issuance)

Phát hành token là bước khởi đầu của vòng đời chứng khoán, ERC1400 thiết kế cơ chế phát hành linh hoạt và an toàn. Chức năng phát hành bị giới hạn trong tay các vai trò Minter hoặc owner, và chỉ khi bật chế độ phát hành mới có thể thực hiện, đảm bảo quyền phát hành luôn trong tầm kiểm soát.

Chức năng phát hành hỗ trợ hai chế độ: phát hành đơn giản và phát hành phân vùng. Phát hành đơn giản sẽ thêm token vào phân vùng mặc định, phù hợp với các trường hợp không cần phân loại phức tạp. Phát hành phân vùng cho phép chỉ định phân vùng cụ thể.

Trong thực tế chứng khoán token hóa, cơ chế này có thể phản ánh nhiều nghiệp vụ tài chính phức tạp:

• Phát hành IPO / STO
• Vốn đầu tư tư nhân (Private Placement)
• Cấp quyền cho nhân viên (ESOP)
• Chi trả cổ tức (thay cho lãi cổ phiếu)

2.2.2 Chức năng thu hồi (Redemption)

Thu hồi token là bước quan trọng trong vòng đời chứng khoán, thể hiện việc thoái vốn và tiêu hủy, giảm cung.

ERC1400 cung cấp bốn đường thu hồi khác nhau để phù hợp các nghiệp vụ:

• Thu hồi chủ động của người nắm giữ (tự tiêu hủy token), thường dùng trong thanh lý hoặc thoái vốn.

• Thu hồi thay mặt người nắm giữ qua người điều hành (authorized operator).

• Thu hồi theo phân vùng (cụ thể phân vùng).

• Tất cả các thao tác thu hồi đều qua quy trình xác thực đầy đủ, bao gồm hook của người gửi và validator của token, đảm bảo tuân thủ quy định.

Trong thực tế, cơ chế thu hồi có thể phản ánh các nghiệp vụ như:

• Mua lại cổ phiếu (Share Buyback)
• Thanh lý công ty (Liquidation Distribution)
• Trái phiếu có thể thu hồi (Callable Bonds)
• Thu hồi cổ phần vi phạm quy định (Enforcement Violation)

2.2.3 Cơ chế chuyển khoản và kiểm tra tuân thủ

Chuyển khoản là chức năng trung tâm của giao dịch chứng khoán, ERC1400 thiết kế cơ chế chuyển khoản đa tầng, vừa đảm bảo tương thích ERC20, vừa đáp ứng yêu cầu giám sát đặc thù.

• Cơ chế chuyển phân vùng mặc định là thiết kế tinh tế.

• Chức năng chuyển theo phân vùng cung cấp khả năng thao tác rõ ràng.

• Quá trình chuyển khoản có kiểm tra tuân thủ đa tầng.

Trong thực tế, cơ chế này có thể phản ánh các nghiệp vụ:

• Giao dịch thị trường thứ cấp (Secondary Market)
• Thanh toán DVP (Delivery Versus Payment)
• Chuyển tài khoản ủy thác (Custodial Rebalancing)
• Giao dịch xuyên biên giới (Travel Rule)

2.3 Hệ thống hook mở rộng - Module kiểm tra tuân thủ có thể cắm vào

Trong phần bàn về cơ chế chuyển khoản, đã đề cập hệ thống sẽ thực hiện nhiều kiểm tra tuân thủ đa tầng, và các kiểm tra này dựa vào hệ thống hook của ERC1400.

2.3.1 Hook người gửi (Sender Hook)

Hook người gửi được gọi trước khi token rời khỏi địa chỉ người gửi, là bước đầu của hệ thống hook 3 tầng. Khác với hook validator, hook người gửi do chính chủ sở hữu token đăng ký, nghĩa là mỗi địa chỉ có thể tùy biến logic trước khi chuyển.

Các ứng dụng điển hình của hook người gửi trong nghiệp vụ chứng khoán:

• Giới hạn khối lượng giao dịch (Trading Volume Limit)

• Tự trừ thuế giao dịch (Automatic Tax Deduction)

• Ghi log kiểm toán (Audit Trail Logging)

• Giám sát giao dịch nội bộ (Insider Trading Monitoring)

2.3.2 Vai trò của hook validator token

Validator token là trung tâm của hệ thống tuân thủ, khác biệt rõ ràng với hook người gửi và hook người nhận: validator là hook toàn cục do hợp đồng token đăng ký qua ERC1820, không do người dùng đăng ký riêng.

Trong thực tế, validator có thể phản ánh các nghiệp vụ:

• KYC/AML whitelist (danh sách trắng)

• Lọc danh sách đen (Sanctions Screening)

• Cơ chế cắt đứt đột ngột (Circuit Breaker)

• Phòng thủ mua thâu tóm (Anti-takeover)

• Xác thực chứng chỉ phê duyệt ngoài chuỗi (Off-chain Approval)

2.3.3 Ứng dụng sáng tạo của hook người nhận

Hook người nhận được gọi sau khi token đến địa chỉ nhận, là bước cuối của hệ thống hook 3 tầng. Tương tự hook người gửi, hook người nhận do chính địa chỉ nhận đăng ký, cho phép thực hiện logic tùy biến sau khi nhận token.

Các ứng dụng điển hình:

• Tái đầu tư cổ tức tự động (Automatic Dividend Reinvestment)

• Ghi sổ tự động cho tài khoản ủy thác (Custodial Auto-booking)

• Đăng ký quyền biểu quyết tự động (Voting Right Auto-registration)

• Mua bán ETF (ETF Subscription & Redemption)

3、扩展合约模块详解

Phần này đi sâu vào thực thi mã, phân tích chi tiết các module mở rộng trong thư viện UniversalToken.

3.1 ERC1400TokensValidator - Cơ chế kiểm tra tuân thủ

3.1.1 Cơ chế xác thực chứng chỉ

Chứng chỉ xác thực là một trong những tính năng đặc trưng của ERC1400TokensValidator, kết hợp giữa phê duyệt ngoài chuỗi và thực thi trên chuỗi. Ý tưởng chính là: các đánh giá tuân thủ phức tạp diễn ra ngoài chuỗi, còn trên chuỗi chỉ xác thực kết quả phê duyệt.

Chứng chỉ hỗ trợ hai chế độ: dựa trên Nonce và dựa trên Salt.

3.1.2 Quản lý danh sách trắng/đen động

Hệ thống whitelist/blacklist là công cụ cơ bản của tuân thủ chứng khoán, sử dụng mô hình kiểm soát truy cập dựa trên vai trò (RBAC), kết hợp thư viện quản lý vai trò của OpenZeppelin.

3.1.3 Thực thi Hold - Khóa tạm thời vốn theo điều kiện

Chức năng Hold cho phép khóa vốn mà không chuyển thực tế token, dựa trên một trạng thái máy và hệ thống theo dõi số dư 3 lớp. Trạng thái Hold có 6 trạng thái, mỗi trạng thái mang ý nghĩa và quyền hạn riêng.

3.1.4 Quản lý phân vùng (Granularity) tinh vi

ERC1400TokensValidator khác với ERC1400 về độ phân giải (Granularity), cho phép thiết lập riêng cho từng phân vùng. Điều này cho phép các loại chứng khoán khác nhau trong cùng hợp đồng token có thể có đơn vị nhỏ nhất khác nhau, phản ánh đúng khái niệm “lot” trong thị trường truyền thống.

3.2 ERC1400TokensChecker - Module kiểm tra chuyển khoản

Cung cấp một API xem (view) để mô phỏng và trả về kết quả khả thi của giao dịch mà không tiêu tốn gas.

3.3 ERC20HoldableToken - Phiên bản đơn giản của Hold

Dành cho các trường hợp không cần phân vùng phức tạp, nhưng vẫn muốn có chức năng khóa vốn, ERC20HoldableToken là lựa chọn nhẹ, hoàn toàn tương thích ERC20, nhưng mở rộng bằng cách ghi nhận số dư có thể chi tiêu (spendableBalance).

3.4 ERC1400HoldableToken và ERC1400HoldableCertificateToken - Token lắp ghép

3.4.1 ERC1400HoldableToken - Chuẩn phù hợp quy định

Phù hợp cho các trường hợp cần KYC/AML nhưng không cần ký xác thực từng giao dịch theo thời gian thực.

Đặc điểm: chỉ có whitelist.

Cấu hình: trong constructor, đăng ký Validator, đặt certificateActivated = None, nhưng bật allowlist, blocklist và holds.

3.4.2 ERC1400HoldableCertificateToken - Chuẩn siêu giám sát

Phù hợp với các quy định cực kỳ nghiêm ngặt, cần kiểm tra từng giao dịch thứ cấp theo thời gian thực.

Đặc điểm: hỗ trợ chứng chỉ dựa trên Nonce hoặc Salt, cần thiết lập địa chỉ signer.

Tổng kết so sánh:

Lựa chọn theo tình huống:

• Tiền pháp định số hóa và thanh toán (Digital Fiat & Payment Settlement)

• Cấu trúc SPV cho cổ phần tư nhân (Private Equity via SPV)

• Chứng khoán công khai có kiểm soát (Regulated Public Distribution)

4、角色管理模块

Hệ thống quản lý vai trò của ERC-1400 không đơn giản, mà xây dựng mô hình phân tầng quyền hạn phức tạp.

4.1 Tầng quản trị cốt lõi: Chủ sở hữu và kiểm soát viên

Là “bộ não” của hệ thống, chịu trách nhiệm thiết lập quy tắc và xử lý ngoại lệ.

• Chủ sở hữu hợp đồng (Owner)

• Trách nhiệm: Là quản trị viên tối cao, có quyền thiết lập tham số hệ thống.

• Thể hiện trong mã: Ownable.sol và ERC1400.sol với modifier onlyOwner.

• Kiểm soát viên (Controller)

• Trách nhiệm: Thể hiện trực tiếp của quản lý tuân thủ trên chuỗi.

• Thể hiện trong mã: danh sách _controllers trong ERC1400.sol, chỉ cho phép onlyTokenController.

4.2 Tầng phát hành tài sản: Người phát hành (Minter) và Oracles

Là “trái tim” của hệ thống, quản lý vòng đời tài sản.

• Người phát hành (Minter)

• Trách nhiệm: Nắm giữ quyền cung cấp chứng khoán.

• Thể hiện trong mã: MinterRole.sol và modifier onlyMinter.

• Oracle giá (PriceOracle)

• Trách nhiệm: Trong phát hành quỹ, đóng vai trò trung gian công bằng.

• Thể hiện trong mã: FundIssuer.sol với onlyPriceOracle.

• Bộ điều khiển token (TokenController)

• Trách nhiệm: Trong các hợp đồng công cụ như FundIssuer, như quản lý quỹ, thiết lập quy tắc phát hành, tỷ lệ phí, vòng đời.

• Thể hiện trong mã: trong FundIssuer.sol, biến _tokenControllers.

4.3 Tầng vận hành: Operator và thực thi giao dịch

Là “tứ chi” của hệ thống, thực hiện các hoạt động chuyển giá trị hàng ngày.

• Operator

• Trách nhiệm: Tham gia tích cực nhất, đại diện người nắm giữ thực hiện chuyển khoản hàng ngày.

• Thể hiện trong mã: logic isOperator trong ERC1400.sol.

• Thực thi giao dịch (TradeExecuter)

• Trách nhiệm: Trong các giao dịch swap nguyên tử hoặc DVP, TradeExecuter (thường là người chứng thực Hold) có quyền thực thi các lệnh đã khóa, hoàn tất chuyển giao tài sản.

• Thể hiện trong mã: trong ERC1400TokensValidator.sol và Swaps.sol.

4.4 Tầng kiểm soát tuân thủ: Người ký chứng chỉ và quản trị danh sách

Là “hệ miễn dịch” của hệ thống, nhận diện rủi ro và đảm bảo tuân thủ.

• Người ký chứng chỉ (CertificateSigner)

• Trách nhiệm: Cầu nối giữa tuân thủ ngoài chuỗi và thực thi trên chuỗi.

• Thể hiện trong mã: xác thực chữ ký trong ERC1400TokensValidator.sol.

• Quản trị danh sách trắng/đen (AllowlistAdmin/BlocklistAdmin)

• Trách nhiệm: Lớp phòng thủ đầu tiên của tuân thủ.

• Thể hiện trong mã: AllowlistedRole.sol và BlocklistedRole.sol.

• Người tạm dừng (Pauser)

• Trách nhiệm: Có quyền “cắt đứt” thị trường.

• Thể hiện trong mã: trong Pausable.sol với pause / unpause.

5、工具合约：提升系统的互操作性与可用性

Giao thức ERC-1400 không chỉ định nghĩa một tiêu chuẩn token đơn lẻ, mà còn cung cấp một hệ sinh thái hợp đồng công cụ, nhằm giải quyết các vấn đề về khả năng tương tác, an toàn và hiệu quả trong thực tế RWA.

5.1 Đăng ký ERC1820

Hệ thống đăng ký dịch vụ động, ERC1820 là một registry toàn cục, giải quyết vấn đề “làm thế nào các hợp đồng tìm thấy nhau”. Trong kiến trúc ERC-1400, ERC1820 đóng vai trò cầu nối, cho phép các hợp đồng cốt lõi có thể phát hiện và gọi các hợp đồng mở rộng một cách linh hoạt.

5.2 Domain Separator EIP-712

Bảo vệ an toàn ký kết: tiêu chuẩn EIP-712 định nghĩa định dạng ký dữ liệu có cấu trúc, là nền tảng kỹ thuật cho cơ chế xác thực chứng chỉ (Certificate). So với ký tin nhắn đơn thuần, EIP-712 cung cấp độ bảo mật và thân thiện người dùng cao hơn.

5.3 Công cụ thao tác hàng loạt

Phân phối và quản lý chứng khoán thường liên quan đến số lượng lớn thao tác hàng loạt. Một đợt phát hành có thể cần gửi chứng khoán đến hàng trăm nhà đầu tư, một lần chia cổ tức có thể chuyển khoản cho hàng nghìn cổ đông. Thao tác từng bước sẽ tốn thời gian, chi phí gas cao. Các công cụ thao tác hàng loạt của ERC-1400 giúp giải quyết hiệu quả.

5.4 Công cụ phát hành vốn

Trong các quỹ, việc phát hành cổ phần cần quy trình phức tạp, dễ gây sai sót. FundIssuer là hợp đồng chuyên quản lý phát hành cổ phần quỹ, theo mô hình phát hành theo chu kỳ, dựa trên mô hình thanh toán trễ theo chu kỳ (Cycle-Based Settlement).

5.5 Giao dịch nguyên tử và DVP (Swaps)

Để hỗ trợ giao dịch thứ cấp an toàn, không tin cậy, thư viện UniversalToken giới thiệu hợp đồng Swaps, thực hiện chức năng DVP và trao đổi nguyên tử.

II. 证券型 RWA：ERC-3643 (T-REX) 深度分析

1、合约整体架构

Từ góc độ kiểm toán, toàn bộ kiến trúc của ERC-3643 có thể chia thành ba phần cốt lõi:

• Tầng tài sản (Token Contract)

• Tầng danh tính (Identity Registry)

• Tầng tuân thủ (Compliance)

Ngoài ra, để hỗ trợ triển khai và nâng cấp phức tạp, T-REX dùng mô hình Proxy-Implementation. Cũng có các module công cụ gồm Factory và Roles.

2、ERC-3643 (T-REX) 核心合约深度剖析

2.1 Phân tích cấu trúc dữ liệu chính

Dữ liệu của ERC-3643 phân tán trong các hợp đồng, liên kết qua địa chỉ, tạo thành một mạng trạng thái.

1. Con trỏ tuân thủ trong hợp đồng token

2. Mạng lưới registry trong IdentityRegistry

3. Các module trong Compliance

2.2 Phân tích các module chức năng chính

1. Cơ chế chuyển khoản và thao tác bắt buộc

Hợp đồng token theo chuẩn ERC-20, bổ sung kiểm tra ba bước:

• Kiểm tra khóa (frozen) và token bị khóa (frozenTokens)

• Kiểm tra xác thực danh tính và tuân thủ qua các hợp đồng khác

• Cập nhật trạng thái tuân thủ (Hook)

Đáp ứng yêu cầu pháp lý (như thi hành án, khôi phục khóa riêng), ERC-3643 hỗ trợ thao tác bắt buộc.

• Chuyển bắt buộc (Forced Transfer)

• Khóa một phần token (Freeze Partial Tokens)

• Địa chỉ khôi phục (Recovery Address)

2.3 Module kiểm tra tuân thủ mở rộng

Hợp đồng ModularCompliance đồng bộ trạng thái qua các hàm created, destroyed, transferred, giúp cập nhật trạng thái nội bộ của các module.

3、扩展合约模块详解

Phần này đi sâu vào hệ thống đăng ký, các module tuân thủ cũ và mới, cùng các module quản lý vai trò.

3.1 Hệ thống registry

Hệ thống registry của ERC-3643 gồm:

• TrustedIssuersRegistry: danh sách các nhà phát hành Claim đáng tin cậy.

• ClaimTopicsRegistry: quản lý các loại chứng chỉ (claim) cần thiết, liên kết bằng AND, xác định tiêu chuẩn phù hợp.

3.2 Các module tuân thủ cũ

Ngoài ModularCompliance, còn có hệ thống Compliance cũ gồm DefaultCompliance và BasicCompliance.

3.3 Quản lý vai trò

Hệ thống phân quyền của ERC-3643 gồm hai loại:

• Owner: chủ hệ thống, quản lý cài đặt, nâng cấp.

• Agent: đại diện vận hành, quản lý các hoạt động như mint, burn, forcedTransfer, freeze.

3.4 Công cụ hỗ trợ

Các hợp đồng công cụ giúp đơn giản hóa triển khai:

• TREXFactory: tạo hợp đồng mới qua CREATE2, dùng _salt để đảm bảo địa chỉ xác định.

• TREXImplementationAuthority: quản lý nâng cấp, dùng mô hình proxy đặc biệt.

III. 垂直场景与扩展标准简析

1、房地产 RWA：ERC-6065 (Real Estate Token)

Áp dụng cho: quỹ tín thác bất động sản (REITs); cho vay thế chấp bằng NFT bất động sản; nền tảng giao dịch xuyên biên giới.

2、物联网与实物资产：ERC-4519

Áp dụng cho: nền tảng cho thuê chia sẻ phi tập trung; theo dõi vận chuyển logistics cao giá trị; kiểm tra danh tính chủ sở hữu trong vận hành xe; hoặc kiểm soát xe qua NFT để cho thuê theo thời gian, tự động khóa xe khi vỡ hợp đồng.

3、通用合规接口：ERC-7943 (uRWA)

Áp dụng cho: pool thanh khoản DeFi tuân thủ, chỉ cho phép địa chỉ KYC tham gia vay mượn; nền tảng phát hành chứng khoán có kiểm soát (STO) với cơ chế phong tỏa và thi hành pháp lý; hoặc hệ thống thanh toán ổn định của tổ chức, hỗ trợ kiểm tra AML và phong tỏa quỹ đáng ngờ.

四、安全编码实践 无论 RWA 项目采用哪种协议标准或资产架构，严谨的代码实现始终是合规性与业务创新的物理底座。

3.1 权限与角色设计：先把“谁能做什么”规划好

Trong hầu hết các dự án RWA, vấn đề quyền hạn không chỉ là “có admin hay không”, mà là “loại admin nào có thể làm tới mức nào”.

Các vai trò phổ biến gồm: chủ hợp đồng, multi-sig quản trị, quản trị nâng cấp, quản trị tuân thủ, quản lý KYC/danh sách trắng, quản lý phong tỏa, quản lý đăng ký tài sản, quản lý thu hồi, quản trị oracle, quản lý rủi ro, quản lý tài chính/kho bạc, v.v.

Đối với nhà phát triển:

• Vẽ ra ma trận vai trò-quyền hạn từ đầu.

• Thực thi theo khung quyền rõ ràng.

• Phân chia trách nhiệm, tránh tập trung quyền quá mức vào một người.

Đối với kiểm toán:

• Liệt kê tất cả các hàm “nguy hiểm cao” trong mã.

• So sánh với ma trận quyền hạn để kiểm tra.

3.2 State machine và invariant: Ghi rõ vòng đời và quy tắc bất biến trong mã

State machine là mô hình cho phép đối tượng (token, cổ phần, cấu hình, yêu cầu) ở các trạng thái khác nhau, chuyển đổi theo điều kiện, và có các quy tắc bất biến phải luôn đúng.

Không kể thứ tự gọi, không kể số lần thao tác, các quy tắc bất biến phải luôn giữ đúng, nếu bị phá vỡ, chứng tỏ thiết kế hoặc thực thi có vấn đề.

Từ góc độ phát triển, cách viết tốt là:

• Phân tích nghiệp vụ để xây dựng state machine, rồi thể hiện trong enum hoặc flags.

• Mỗi entry point phải rõ điều kiện trạng thái trước khi thực thi.

• Viết các quy tắc bất biến quan trọng trong logic mã.

Từ góc độ kiểm toán, state machine và invariant là điểm cốt lõi:

• Xác định vòng đời và quy tắc bất biến từ tài liệu dự án, rồi kiểm tra mã.

• Dựng các đường chuyển trạng thái, kiểm tra xem có thể bypass không.

• Thử phá vỡ các giới hạn, kiểm tra invariants có bị vi phạm không.

3.3 资产映射与账务一致性：别让链上账目和链下资产“对不上数”

Tính chất của RWA là: chuỗi chỉ là ánh xạ, tài sản thực nằm ngoài chuỗi. Do đó, “bảo toàn số dư” trên chuỗi còn quan trọng hơn DeFi.

Đối với nhà phát triển:

• Làm rõ mối quan hệ tài sản trong mã, giảm mơ hồ.

• Đối với kiểm toán: phải dễ dàng nhận biết biến nào đại diện cho tài sản, lô hàng, quỹ, kỳ hạn, v.v.

Nguyên tắc khi phát triển:

• Phân biệt rõ “biến ghi sổ” và “cấu hình/trung gian”.

• Rõ ràng “token này tương ứng tài sản nào”.

• Mọi biến động tài sản đều phải có vòng khép kín rõ ràng.

Trong kiểm toán, vấn đề ánh xạ tài sản thường lộ qua:

• Không khớp (mismatch)

• Hoặc không rõ ràng (unclear)

Không phải lúc nào cũng gây ra tấn công, nhưng về lâu dài, dễ dẫn đến sai sót hoặc lạm dụng.

3.4 升级与代理模式：给自己留后路，也配合好“改规则的人”

Hầu hết các dự án RWA đều dùng mô hình proxy (Transparent / UUPS) kết hợp multi-sig hoặc governance để nâng cấp.

Khi phát triển, cần chú ý:

• Xác định mức độ nâng cấp phù hợp.

• Khóa các bước khởi tạo và quyền quản trị.

• Đảm bảo trạng thái tương thích trước và sau nâng cấp.

Trong kiểm toán, rủi ro liên quan đến nâng cấp thường bị đánh giá thấp:

• Chỉ vì “hiện tại an toàn” không có nghĩa là sau nâng cấp vẫn an toàn.

• Nhiều giao thức “không vấn đề về logic” nhưng lại bị phá hỏng bởi quyền nâng cấp yếu.

Vì vậy, ngoài kiểm tra thực thi, kiểm toán còn cần đánh giá:

• Ai có quyền nâng cấp? Có multi-sig / timelock không?

• Quy trình nâng cấp minh bạch không (đề xuất, bỏ phiếu, chờ đợi)?

• Có backdoor cho phép bypass quy trình nâng cấp không?

3.5 Sự kiện và nhật ký: Để lại “chuỗi chứng cứ” cho tương lai và cơ quan quản lý

Trong RWA, sự kiện (event) không chỉ giúp frontend và explorer đọc dữ liệu dễ dàng, mà còn là chứng cứ cho kiểm toán, thu thập chứng cứ, xử lý tranh chấp, báo cáo quản lý.

Với nhà phát triển:

• Mọi thao tác ảnh hưởng quyền lợi thực tế đều phải phát sinh event, ví dụ:

• Mint, burn, transfer, freeze, unfreeze, forcedTransfer

• Thay đổi whitelist/blacklist, cập nhật KYC

• Tạo, xử lý, hoàn tất, từ chối yêu cầu thu hồi

• Nâng cấp, thay đổi tham số, thay đổi vai trò.

Với kiểm toán:

• Kiểm tra event thường bị bỏ qua, nhưng trong RWA cực kỳ quan trọng:

• Xem có đường dẫn chính nào không thiếu event?

• Các trường event có đủ để phục vụ phục hồi hành vi không?

• Có thể bypass event qua hàm riêng