Ý tưởng “đưa mọi dữ liệu lên blockchain để minh bạch” nghe đơn giản nhưng hiếm khi phù hợp với bất động sản. Hồ sơ BĐS có thể gồm hợp đồng, bản vẽ, thông tin cá nhân, dữ liệu định giá, lịch sử vận hành và nhiều loại tài liệu cần sửa đổi hoặc giới hạn truy cập.
Kiến trúc thực tế vì vậy thường phải tách phần trên chuỗi và ngoài chuỗi. Câu hỏi không phải dữ liệu nào có thể đưa lên blockchain, mà là dữ liệu nào thực sự cần một bằng chứng hoặc trạng thái dùng chung và dữ liệu nào nên ở hệ thống khác.
Biên soạn: ThS. Nguyễn Mạnh Hùng
Đơn vị: GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
1. Không phải dữ liệu nào cũng nên đưa lên chuỗi
Một trong những sai lầm phổ biến nhất là muốn đưa “mọi dữ liệu” lên blockchain để tăng minh bạch. BĐS lại có tệp lớn, hồ sơ cá nhân, giá thương lượng, bản vẽ, định giá, dữ liệu vận hành và tài liệu pháp lý cần cập nhật. Vì vậy kiến trúc thực tế thường tách dữ liệu trên chuỗi (on-chain) và ngoài chuỗi (off-chain), dùng chuỗi cho trạng thái/bằng chứng cần chia sẻ và dùng hệ thống ngoài chuỗi cho dữ liệu chi tiết.
2. Mục tiêu học tập
- Giải thích được khái niệm trung tâm bằng ngôn ngữ của người làm BĐS, không chỉ nhắc lại định nghĩa kỹ thuật.
- Phân biệt lớp công nghệ, lớp dữ liệu, lớp quyền pháp lý và lớp dòng tiền khi chúng xuất hiện cùng một sản phẩm.
- Đặt được câu hỏi kiểm soát trước khi chấp nhận đề xuất từ nhà cung cấp công nghệ hoặc tổ chức phát hành.
- Nhận diện trường hợp blockchain tạo giá trị và trường hợp cơ sở dữ liệu hoặc quy trình truyền thống phù hợp hơn.
- Thiết kế được một sơ đồ dữ liệu/quy trình tối thiểu có người chịu trách nhiệm, bằng chứng và cách xử lý ngoại lệ.
- Đối chiếu được nguyên tắc kỹ thuật với bối cảnh pháp luật Việt Nam đang có hiệu lực, đặc biệt từ năm 2026.
3. Tình huống BĐS mở bài
Một nền tảng giao dịch BĐS muốn lưu hồ sơ thẩm định, hợp đồng, ảnh, thông tin khách hàng và lịch sử phê duyệt. Nếu đưa mọi thứ lên chuỗi công khai, chi phí cao và lộ dữ liệu; nếu để mọi thứ trong cơ sở dữ liệu riêng, các bên khác khó kiểm chứng lịch sử. Phương án hợp lý có thể là lưu tài liệu trong kho được kiểm soát, ghi mã tài liệu, phiên bản, giá trị băm, người phê duyệt và trạng thái lên sổ dùng chung.
Khi phân tích tình huống, sinh viên nên tách bốn nhóm: dữ kiện đã biết – giả định đang dùng – dữ liệu cần xác minh – người hoặc cơ quan có thẩm quyền xác nhận. Cách tách này giúp tránh biến một bản ghi kỹ thuật thành “sự thật pháp lý” chỉ vì nó được lưu trên chuỗi khối.
4. Khung tư duy xuyên suốt
Mỗi bài toán blockchain trong BĐS nên được đọc qua sáu lớp: (1) tài sản hoặc quy trình thật; (2) quyền và nghĩa vụ của các bên; (3) dữ liệu và nguồn sự thật; (4) cơ chế ghi nhận/chuyển trạng thái; (5) quản trị, an toàn và xử lý ngoại lệ; (6) pháp luật áp dụng. Nếu một đề xuất chỉ mô tả lớp 4 mà bỏ năm lớp còn lại, đề xuất đó chưa đủ để triển khai.
| Lớp | Câu hỏi bắt buộc | Bằng chứng cần có |
|---|---|---|
| 1 | Vấn đề BĐS nào đang cần giải quyết? | Quy trình hiện tại, thời gian, lỗi, chi phí hoặc tranh chấp. |
| 2 | Quyền/lợi ích nào đang được ghi nhận? | Hợp đồng, điều lệ, hồ sơ quyền, quy định nội bộ. |
| 3 | Dữ liệu đến từ đâu và ai xác nhận? | Nguồn dữ liệu, người chịu trách nhiệm, thời điểm. |
| 4 | Vì sao cần chuỗi khối thay vì cơ sở dữ liệu? | So sánh phương án và mô hình tin cậy. |
| 5 | Ai quản trị khóa, nút, nâng cấp và ngoại lệ? | Ma trận quyền và kế hoạch ứng phó. |
| 6 | Luật nào quyết định hiệu lực giao dịch/quyền? | Ý kiến pháp lý, văn bản hiện hành, phạm vi thí điểm. |
5. Các nguyên lý cốt lõi
5.1. Dữ liệu trên chuỗi phù hợp với trạng thái nhỏ, cần kiểm chứng và chia sẻ
Blockchain phù hợp hơn với dữ liệu trạng thái, mã tham chiếu, giá trị băm, sự kiện và quyền số thay vì tệp dung lượng lớn. Dữ liệu càng nhỏ và có ý nghĩa kiểm toán rõ, lợi ích càng dễ biện minh.
Ví dụ BĐS: Ghi hash của hợp đồng và mốc “đã phê duyệt” thay vì toàn bộ PDF.
Điểm kiểm soát: Mỗi trường on-chain phải có lý do tại sao cần tồn tại lâu dài và chia sẻ.
5.2. Dữ liệu ngoài chuỗi phù hợp với tệp lớn, riêng tư và cần sửa/xóa
Bản vẽ, ảnh, hồ sơ KYC, hợp đồng chi tiết và dữ liệu cảm biến thường cần kho ngoài chuỗi có phân quyền. On-chain chỉ lưu bằng chứng liên kết.
Ví dụ BĐS: Bản vẽ BIM/CAD lưu trong DMS; chuỗi lưu mã phiên bản và hash.
Điểm kiểm soát: Thiết kế cơ chế sao lưu, kiểm soát truy cập và bảo toàn liên kết với hash.
5.3. Giá trị băm nối hai thế giới nhưng không đảm bảo dữ liệu đầu vào đúng
Hash giúp kiểm tra một tệp có bị thay đổi so với bản đã ghi hay không. Nếu tệp ban đầu sai hoặc giả, hash chỉ chứng minh “đúng bản sai đó”.
Ví dụ BĐS: Biên bản nghiệm thu khai sai số liệu vẫn có hash hoàn toàn hợp lệ.
Điểm kiểm soát: Kết hợp quy trình kiểm chứng nghiệp vụ trước khi băm/ghi chuỗi.
5.4. Thông tin cá nhân không nên mặc định đưa lên chuỗi bất biến
Địa chỉ, CCCD, số điện thoại, hồ sơ KYC và dữ liệu cư dân có yêu cầu bảo vệ và có thể cần cập nhật/giới hạn truy cập. Ghi trực tiếp lên chuỗi tạo rủi ro lâu dài.
Ví dụ BĐS: Chỉ lưu mã định danh giả danh hoặc tham chiếu, dữ liệu thật trong kho được kiểm soát.
Điểm kiểm soát: Thực hiện đánh giá dữ liệu cá nhân trước thiết kế schema.
5.5. Dữ liệu giá và trạng thái ngoài đời cần cơ chế đưa vào chuỗi
Blockchain không tự biết giá BĐS, tình trạng công trình, lãi suất hay việc tiền đã vào ngân hàng. Dữ liệu ngoài chuỗi phải được cung cấp qua hệ thống tích hợp/oracle, tạo thêm điểm tin cậy và rủi ro.
Ví dụ BĐS: NAV của tài sản do đơn vị định giá tính ngoài chuỗi rồi mới công bố hash/kết quả lên chuỗi.
Điểm kiểm soát: Ghi nguồn, thời điểm, người chịu trách nhiệm và cơ chế sửa dữ liệu đầu vào.
5.6. Khả năng truy xuất phải tồn tại sau nhiều năm
Nếu chuỗi chỉ lưu hash nhưng kho ngoài chuỗi mất tệp gốc thì bằng chứng không còn hữu dụng. Kiến trúc phải có chính sách lưu trữ, định danh bền vững và sao lưu.
Ví dụ BĐS: Tệp hợp đồng 10 năm sau vẫn phải tìm được bằng mã tham chiếu on-chain.
Điểm kiểm soát: Kiểm thử phục hồi dữ liệu định kỳ, không chỉ kiểm chuỗi.
5.7. Chi phí on-chain có thể tăng theo dung lượng và tần suất
Mỗi mạng có mô hình phí/lưu trữ khác nhau. Ghi dữ liệu cảm biến mỗi giây lên mạng công khai thường không hợp lý; có thể tổng hợp theo lô và neo hash định kỳ.
Ví dụ BĐS: Tòa nhà có 10.000 điểm IoT nên lưu time-series ngoài chuỗi, chỉ neo bằng chứng theo ngày/tháng nếu cần.
Điểm kiểm soát: Mô hình hóa số giao dịch và chi phí ở tải thực tế.
5.8. Kiến trúc lai cần định nghĩa nguồn sự thật cho từng trường
Nếu cùng một trạng thái tồn tại cả cơ sở dữ liệu và blockchain, phải biết nguồn nào là chính và xử lý lệch dữ liệu thế nào. Nếu không, hệ thống tạo thêm tranh chấp thay vì giảm tranh chấp.
Ví dụ BĐS: Trạng thái hợp đồng ở DB là ACTIVE nhưng token đã chuyển; quy trình phải xác định bên nào cập nhật bên nào.
Điểm kiểm soát: Lập bảng source-of-truth và quy tắc đồng bộ cho từng thực thể.
6. Bảng so sánh và ra quyết định
| Đối tượng hoặc tình huống | Cách hiểu/Phương án | Điểm cần kiểm |
|---|---|---|
| Hash tài liệu | Trên chuỗi | Nhỏ, dùng kiểm toàn vẹn |
| PDF hợp đồng | Ngoài chuỗi | Dung lượng lớn, cần quyền truy cập |
| CCCD/KYC | Ngoài chuỗi | Dữ liệu nhạy cảm |
| Mã token/quyền số | Trên chuỗi | Cần trạng thái chuyển giao dùng chung |
| Dữ liệu cảm biến chi tiết | Ngoài chuỗi | Tần suất cao, dung lượng lớn |
| Hash tập dữ liệu cảm biến theo kỳ | Có thể trên chuỗi | Bằng chứng chống sửa |
| NAV/giá thẩm định | Tính ngoài chuỗi, có thể công bố bằng chứng on-chain | Phụ thuộc phương pháp và chuyên gia ngoài đời |
Bảng này không phải công thức pháp lý. Khi áp dụng cho dự án thật phải cập nhật theo loại BĐS, cấu trúc giao dịch, khu vực pháp lý, hệ thống công nghệ và thời điểm triển khai.
7. Quy trình thực hành đề xuất
- Bước 1. Lập danh mục toàn bộ dữ liệu nghiệp vụ. Sau bước này phải có một đầu ra kiểm chứng được, không chỉ là cuộc họp hoặc nhận định miệng.
- Bước 2. Phân loại dung lượng/tần suất/độ nhạy. Sau bước này phải có một đầu ra kiểm chứng được, không chỉ là cuộc họp hoặc nhận định miệng.
- Bước 3. Xác định nhu cầu sửa/xóa và thời hạn lưu. Sau bước này phải có một đầu ra kiểm chứng được, không chỉ là cuộc họp hoặc nhận định miệng.
- Bước 4. Xác định dữ liệu cần nhiều bên kiểm chứng. Sau bước này phải có một đầu ra kiểm chứng được, không chỉ là cuộc họp hoặc nhận định miệng.
- Bước 5. Chọn dữ liệu on-chain tối thiểu. Sau bước này phải có một đầu ra kiểm chứng được, không chỉ là cuộc họp hoặc nhận định miệng.
- Bước 6. Thiết kế kho off-chain và định danh bền vững. Sau bước này phải có một đầu ra kiểm chứng được, không chỉ là cuộc họp hoặc nhận định miệng.
- Bước 7. Thiết kế đồng bộ/oracle và xử lý lệch. Sau bước này phải có một đầu ra kiểm chứng được, không chỉ là cuộc họp hoặc nhận định miệng.
- Bước 8. Kiểm thử phục hồi cả chuỗi và kho ngoài chuỗi. Sau bước này phải có một đầu ra kiểm chứng được, không chỉ là cuộc họp hoặc nhận định miệng.
Nguyên tắc quan trọng là không tự động hóa một quy trình mà tổ chức chưa thống nhất được quyền, dữ liệu và ngoại lệ. Blockchain làm cho sai sót có thể lan nhanh và khó sửa hơn nếu đầu vào và quyền phê duyệt chưa rõ.
8. Góc nhìn theo vòng đời BĐS
| Giai đoạn | Câu hỏi liên quan nội dung bài | Ví dụ bằng chứng |
|---|---|---|
| Phát triển dự án | Dữ liệu nào do chủ đầu tư, tư vấn, ngân hàng và nhà thầu cùng dùng? | Phê duyệt thiết kế, giải ngân, hồ sơ nghiệm thu. |
| Giao dịch | Trạng thái nào cần nhiều bên kiểm chứng và đâu là nguồn sự thật pháp lý? | Phiên bản hợp đồng, xác nhận thanh toán, hồ sơ công chứng. |
| Đầu tư/quỹ | Quyền lợi kinh tế nào được biểu diễn và ai quản trị nhà đầu tư? | Danh sách nhà đầu tư, dòng tiền, NAV, quyền biểu quyết. |
| Vận hành | Bản ghi nào cần truy vết qua chủ sở hữu/nhà thầu? | Bảo trì, kiểm định, bàn giao, sự cố. |
| Thoái vốn/chuyển giao | Lịch sử nào phải bàn giao cho chủ thể mới? | Hồ sơ pháp lý, lịch sử tài sản, quyền truy cập hệ thống. |
9. Các sai lầm thường gặp
- Đưa PDF/ảnh lớn trực tiếp lên chuỗi. Cách sửa là quay lại vấn đề nghiệp vụ, xác định bằng chứng cần có và so với phương án đơn giản hơn trước khi thêm công nghệ.
- Ghi CCCD lên mạng công khai. Cách sửa là quay lại vấn đề nghiệp vụ, xác định bằng chứng cần có và so với phương án đơn giản hơn trước khi thêm công nghệ.
- Tin hash chứng minh nội dung đúng. Cách sửa là quay lại vấn đề nghiệp vụ, xác định bằng chứng cần có và so với phương án đơn giản hơn trước khi thêm công nghệ.
- Không lưu được tệp gốc sau vài năm. Cách sửa là quay lại vấn đề nghiệp vụ, xác định bằng chứng cần có và so với phương án đơn giản hơn trước khi thêm công nghệ.
- Không có source-of-truth. Cách sửa là quay lại vấn đề nghiệp vụ, xác định bằng chứng cần có và so với phương án đơn giản hơn trước khi thêm công nghệ.
- Không xử lý đồng bộ lỗi. Cách sửa là quay lại vấn đề nghiệp vụ, xác định bằng chứng cần có và so với phương án đơn giản hơn trước khi thêm công nghệ.
- Ghi dữ liệu IoT quá dày. Cách sửa là quay lại vấn đề nghiệp vụ, xác định bằng chứng cần có và so với phương án đơn giản hơn trước khi thêm công nghệ.
- Không dự toán phí on-chain. Cách sửa là quay lại vấn đề nghiệp vụ, xác định bằng chứng cần có và so với phương án đơn giản hơn trước khi thêm công nghệ.
- Dùng blockchain như kho backup. Cách sửa là quay lại vấn đề nghiệp vụ, xác định bằng chứng cần có và so với phương án đơn giản hơn trước khi thêm công nghệ.
- Không có cơ chế sửa nghiệp vụ khi oracle sai. Cách sửa là quay lại vấn đề nghiệp vụ, xác định bằng chứng cần có và so với phương án đơn giản hơn trước khi thêm công nghệ.
10. Khung pháp lý Việt Nam cần nhớ
Nguyên tắc tách on-chain/off-chain đặc biệt quan trọng khi xử lý dữ liệu cá nhân, hồ sơ pháp lý và dữ liệu giao dịch BĐS. Luật Giao dịch điện tử cho phép giao dịch bằng phương tiện điện tử nhưng không thay nội dung/điều kiện của giao dịch; Luật Công nghiệp công nghệ số và Nghị quyết 05 đặt thêm yêu cầu quản lý đối với tài sản số/tài sản mã hóa. Kiến trúc dữ liệu phải đáp ứng đồng thời các lớp pháp luật này.
Khi áp dụng vào BĐS cần giữ ba nguyên tắc: (i) thuật ngữ kỹ thuật quốc tế không tự quyết định phân loại pháp lý tại Việt Nam; (ii) một bản ghi hoặc token không tự thay thế giấy tờ, đăng ký, hợp đồng hay thẩm quyền theo pháp luật BĐS; (iii) phải ghi rõ thời điểm và phạm vi áp dụng của văn bản vì khung tài sản số đang thay đổi nhanh.
11. Bài tập thực hành
Bài tập A – Phân loại một đề xuất công nghệ
Chọn một quy trình BĐS thật hoặc giả lập. Viết tối đa một trang mô tả vấn đề, các bên tham gia, dữ liệu, quyền và lý do có/không cần blockchain. Bắt buộc đưa một phương án đối chứng không dùng blockchain.
Bài tập B – Vẽ sơ đồ bốn lớp
Vẽ bốn lớp: tài sản/quyền ngoài đời → hồ sơ pháp lý → dữ liệu/hệ thống ngoài chuỗi → dữ liệu/trạng thái trên chuỗi. Dùng mũi tên ghi rõ ai xác nhận chuyển trạng thái giữa các lớp.
Bài tập C – Phản biện nhà cung cấp
Giả sử nhà cung cấp nói “hệ thống minh bạch, không thể sửa và loại bỏ trung gian”. Hãy viết ít nhất 10 câu hỏi kiểm tra để làm rõ: ai nhập dữ liệu, ai vận hành nút, cách sửa sai, cách nâng cấp, chi phí, quyền pháp lý và cơ chế xử lý tranh chấp.
12. Kiểm tra hiện trường và hồ sơ
- Có sơ đồ quy trình hiện tại và điểm gây chậm/tranh chấp trước khi nói về blockchain.
- Có danh sách chủ thể được ghi/đọc/xác thực và căn cứ thẩm quyền.
- Có phân loại dữ liệu công khai, nội bộ, bí mật và dữ liệu cá nhân.
- Có định nghĩa nguồn sự thật cho từng trường dữ liệu quan trọng.
- Có phương án xử lý nhập sai, giao dịch thất bại và tranh chấp.
- Có kế hoạch quản trị khóa, tài khoản, nút và quyền quản trị.
- Có so sánh với cơ sở dữ liệu/kiến trúc không dùng blockchain.
- Có dự toán chi phí vận hành tối thiểu 3 năm, không chỉ chi phí làm thử.
- Có tiêu chí đo thành công và tiêu chí dừng dự án.
- Có rà soát pháp lý theo bản chất quyền và giao dịch, không theo tên sản phẩm.
13. Câu hỏi tự kiểm tra
- Nếu bỏ blockchain ra khỏi giải pháp, vấn đề nào vẫn chưa được giải quyết?
- Ai có thể làm dữ liệu đầu vào sai và hệ thống phát hiện bằng cách nào?
- Một giao dịch được xác nhận kỹ thuật có ý nghĩa pháp lý đến đâu?
- Dữ liệu nào cần sửa hoặc xóa trong vòng đời hệ thống?
- Ai giữ khóa/quyền quản trị và ai kiểm soát người đó?
- Nếu mạng hoặc nhà cung cấp ngừng hoạt động, quyền của người dùng được bảo vệ ra sao?
- Chi phí và độ trễ có chấp nhận được ở tải thực tế không?
- Đâu là bằng chứng độc lập để kiểm tra tuyên bố của hệ thống?
14. Phòng thực hành phân tích sâu
Tình huống 1: Dữ liệu trên chuỗi phù hợp với trạng thái nhỏ, cần kiểm chứng và chia sẻ
Giả sử dự án đã vận hành 6 tháng và xuất hiện một tranh chấp liên quan nội dung này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu đầu vào, lỗi quy trình/quyền hạn và lỗi kỹ thuật. Với mỗi giả thuyết, chỉ ra bằng chứng có thể bác bỏ hoặc xác nhận.
Dữ kiện nền: Blockchain phù hợp hơn với dữ liệu trạng thái, mã tham chiếu, giá trị băm, sự kiện và quyền số thay vì tệp dung lượng lớn. Dữ liệu càng nhỏ và có ý nghĩa kiểm toán rõ, lợi ích càng dễ biện minh.
Bối cảnh BĐS: Ghi hash của hợp đồng và mốc “đã phê duyệt” thay vì toàn bộ PDF.
Yêu cầu kiểm soát: Mỗi trường on-chain phải có lý do tại sao cần tồn tại lâu dài và chia sẻ. Sau đó nêu người có thẩm quyền ra quyết định, thời hạn xử lý và bằng chứng đóng vụ việc.
Tình huống 2: Dữ liệu ngoài chuỗi phù hợp với tệp lớn, riêng tư và cần sửa/xóa
Giả sử dự án đã vận hành 6 tháng và xuất hiện một tranh chấp liên quan nội dung này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu đầu vào, lỗi quy trình/quyền hạn và lỗi kỹ thuật. Với mỗi giả thuyết, chỉ ra bằng chứng có thể bác bỏ hoặc xác nhận.
Dữ kiện nền: Bản vẽ, ảnh, hồ sơ KYC, hợp đồng chi tiết và dữ liệu cảm biến thường cần kho ngoài chuỗi có phân quyền. On-chain chỉ lưu bằng chứng liên kết.
Bối cảnh BĐS: Bản vẽ BIM/CAD lưu trong DMS; chuỗi lưu mã phiên bản và hash.
Yêu cầu kiểm soát: Thiết kế cơ chế sao lưu, kiểm soát truy cập và bảo toàn liên kết với hash. Sau đó nêu người có thẩm quyền ra quyết định, thời hạn xử lý và bằng chứng đóng vụ việc.
Tình huống 3: Giá trị băm nối hai thế giới nhưng không đảm bảo dữ liệu đầu vào đúng
Giả sử dự án đã vận hành 6 tháng và xuất hiện một tranh chấp liên quan nội dung này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu đầu vào, lỗi quy trình/quyền hạn và lỗi kỹ thuật. Với mỗi giả thuyết, chỉ ra bằng chứng có thể bác bỏ hoặc xác nhận.
Dữ kiện nền: Hash giúp kiểm tra một tệp có bị thay đổi so với bản đã ghi hay không. Nếu tệp ban đầu sai hoặc giả, hash chỉ chứng minh “đúng bản sai đó”.
Bối cảnh BĐS: Biên bản nghiệm thu khai sai số liệu vẫn có hash hoàn toàn hợp lệ.
Yêu cầu kiểm soát: Kết hợp quy trình kiểm chứng nghiệp vụ trước khi băm/ghi chuỗi. Sau đó nêu người có thẩm quyền ra quyết định, thời hạn xử lý và bằng chứng đóng vụ việc.
Tình huống 4: Thông tin cá nhân không nên mặc định đưa lên chuỗi bất biến
Giả sử dự án đã vận hành 6 tháng và xuất hiện một tranh chấp liên quan nội dung này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu đầu vào, lỗi quy trình/quyền hạn và lỗi kỹ thuật. Với mỗi giả thuyết, chỉ ra bằng chứng có thể bác bỏ hoặc xác nhận.
Dữ kiện nền: Địa chỉ, CCCD, số điện thoại, hồ sơ KYC và dữ liệu cư dân có yêu cầu bảo vệ và có thể cần cập nhật/giới hạn truy cập. Ghi trực tiếp lên chuỗi tạo rủi ro lâu dài.
Bối cảnh BĐS: Chỉ lưu mã định danh giả danh hoặc tham chiếu, dữ liệu thật trong kho được kiểm soát.
Yêu cầu kiểm soát: Thực hiện đánh giá dữ liệu cá nhân trước thiết kế schema. Sau đó nêu người có thẩm quyền ra quyết định, thời hạn xử lý và bằng chứng đóng vụ việc.
Tình huống 5: Dữ liệu giá và trạng thái ngoài đời cần cơ chế đưa vào chuỗi
Giả sử dự án đã vận hành 6 tháng và xuất hiện một tranh chấp liên quan nội dung này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu đầu vào, lỗi quy trình/quyền hạn và lỗi kỹ thuật. Với mỗi giả thuyết, chỉ ra bằng chứng có thể bác bỏ hoặc xác nhận.
Dữ kiện nền: Blockchain không tự biết giá BĐS, tình trạng công trình, lãi suất hay việc tiền đã vào ngân hàng. Dữ liệu ngoài chuỗi phải được cung cấp qua hệ thống tích hợp/oracle, tạo thêm điểm tin cậy và rủi ro.
Bối cảnh BĐS: NAV của tài sản do đơn vị định giá tính ngoài chuỗi rồi mới công bố hash/kết quả lên chuỗi.
Yêu cầu kiểm soát: Ghi nguồn, thời điểm, người chịu trách nhiệm và cơ chế sửa dữ liệu đầu vào. Sau đó nêu người có thẩm quyền ra quyết định, thời hạn xử lý và bằng chứng đóng vụ việc.
Tình huống 6: Khả năng truy xuất phải tồn tại sau nhiều năm
Giả sử dự án đã vận hành 6 tháng và xuất hiện một tranh chấp liên quan nội dung này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu đầu vào, lỗi quy trình/quyền hạn và lỗi kỹ thuật. Với mỗi giả thuyết, chỉ ra bằng chứng có thể bác bỏ hoặc xác nhận.
Dữ kiện nền: Nếu chuỗi chỉ lưu hash nhưng kho ngoài chuỗi mất tệp gốc thì bằng chứng không còn hữu dụng. Kiến trúc phải có chính sách lưu trữ, định danh bền vững và sao lưu.
Bối cảnh BĐS: Tệp hợp đồng 10 năm sau vẫn phải tìm được bằng mã tham chiếu on-chain.
Yêu cầu kiểm soát: Kiểm thử phục hồi dữ liệu định kỳ, không chỉ kiểm chuỗi. Sau đó nêu người có thẩm quyền ra quyết định, thời hạn xử lý và bằng chứng đóng vụ việc.
Tình huống 7: Chi phí on-chain có thể tăng theo dung lượng và tần suất
Giả sử dự án đã vận hành 6 tháng và xuất hiện một tranh chấp liên quan nội dung này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu đầu vào, lỗi quy trình/quyền hạn và lỗi kỹ thuật. Với mỗi giả thuyết, chỉ ra bằng chứng có thể bác bỏ hoặc xác nhận.
Dữ kiện nền: Mỗi mạng có mô hình phí/lưu trữ khác nhau. Ghi dữ liệu cảm biến mỗi giây lên mạng công khai thường không hợp lý; có thể tổng hợp theo lô và neo hash định kỳ.
Bối cảnh BĐS: Tòa nhà có 10.000 điểm IoT nên lưu time-series ngoài chuỗi, chỉ neo bằng chứng theo ngày/tháng nếu cần.
Yêu cầu kiểm soát: Mô hình hóa số giao dịch và chi phí ở tải thực tế. Sau đó nêu người có thẩm quyền ra quyết định, thời hạn xử lý và bằng chứng đóng vụ việc.
Tình huống 8: Kiến trúc lai cần định nghĩa nguồn sự thật cho từng trường
Giả sử dự án đã vận hành 6 tháng và xuất hiện một tranh chấp liên quan nội dung này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu đầu vào, lỗi quy trình/quyền hạn và lỗi kỹ thuật. Với mỗi giả thuyết, chỉ ra bằng chứng có thể bác bỏ hoặc xác nhận.
Dữ kiện nền: Nếu cùng một trạng thái tồn tại cả cơ sở dữ liệu và blockchain, phải biết nguồn nào là chính và xử lý lệch dữ liệu thế nào. Nếu không, hệ thống tạo thêm tranh chấp thay vì giảm tranh chấp.
Bối cảnh BĐS: Trạng thái hợp đồng ở DB là ACTIVE nhưng token đã chuyển; quy trình phải xác định bên nào cập nhật bên nào.
Yêu cầu kiểm soát: Lập bảng source-of-truth và quy tắc đồng bộ cho từng thực thể. Sau đó nêu người có thẩm quyền ra quyết định, thời hạn xử lý và bằng chứng đóng vụ việc.
15. Nguồn tham khảo chính
- NIST IR 8202 – Blockchain Technology Overview.
- NIST – Blockchain.
- Luật Công nghiệp công nghệ số số 71/2025/QH15.
- Nghị quyết 05/2025/NQ-CP về thí điểm thị trường tài sản mã hóa.
- Luật Giao dịch điện tử số 20/2023/QH15.
- BIS – Tokenisation for the real world.
- BIS – When bricks meet bytes: does tokenisation fill gaps in traditional real estate markets?.
- FATF – Virtual Assets.
- IOSCO – Tokenization of Financial Assets, Final Report 2025.
Nguồn được dùng để kiểm định khái niệm, giới hạn và bối cảnh pháp lý. Các ví dụ BĐS trong bài là tình huống học tập do tác giả xây dựng; không phải tư vấn pháp lý, đầu tư hoặc khuyến nghị phát hành/giao dịch tài sản mã hóa.
Ghi nhớ trong 30 giây
- Dữ liệu nhạy cảm, tệp lớn và dữ liệu cần sửa/xóa thường nên ở ngoài chuỗi.
- Trên chuỗi có thể chỉ cần trạng thái, mã tham chiếu hoặc giá trị băm để kiểm chứng.
- Dữ liệu trên chuỗi phù hợp với trạng thái nhỏ, cần kiểm chứng và chia sẻ.
- Dữ liệu ngoài chuỗi phù hợp với tệp lớn, riêng tư và cần sửa/xóa.
- Trong BĐS phải tách bản ghi kỹ thuật khỏi quyền pháp lý đối với đất, nhà, phần vốn hoặc dòng tiền.
- Nếu phương án đơn giản hơn giải quyết tốt bài toán, không nên dùng blockchain chỉ để tạo cảm giác đổi mới.
Bài tiếp theo: Case study: chọn blockchain hay cơ sở dữ liệu cho một quy trình BĐS giả lập