Một dự án công nghệ tốt không bắt đầu bằng câu hỏi “chúng ta sẽ dùng blockchain ở đâu?”. Nó bắt đầu bằng việc mô tả quy trình hiện tại, các bên tham gia, điểm nghẽn, tranh chấp, dữ liệu và trách nhiệm.
Bài tình huống này đặt sinh viên vào vai nhóm tư vấn cho một quy trình BĐS giả lập. Nhiệm vụ không phải bảo vệ blockchain, mà là chọn giữa cơ sở dữ liệu, blockchain hoặc kiến trúc kết hợp dựa trên bằng chứng và có thể giải thích vì sao.
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. Bắt đầu từ quy trình BĐS, không bắt đầu từ blockchain
Kiến thức blockchain chỉ có giá trị khi người học có thể nói “không nên dùng” trong trường hợp không phù hợp. Bài case study này buộc sinh viên đi từ quy trình BĐS thật, không bắt đầu từ công nghệ. Mục tiêu là thiết kế một quyết định có thể bảo vệ trước chủ đầu tư: vì sao chọn cơ sở dữ liệu, blockchain hoặc kiến trúc lai và rủi ro còn lại là gì.
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
Công ty Minh Thành quản lý quá trình bán một dự án căn hộ có sự tham gia của chủ đầu tư, sàn môi giới, ngân hàng bảo lãnh, ngân hàng cho vay người mua, đơn vị công chứng, đơn vị quản lý hồ sơ và khách hàng. Mỗi bên đang dùng hệ thống riêng. Tranh chấp thường xảy ra về phiên bản bảng giá, thời điểm xác nhận giữ chỗ, trạng thái khoản tiền, phiên bản hợp đồng và tài liệu đã bàn giao. Ban điều hành yêu cầu nghiên cứu “một blockchain dùng chung” nhưng không chấp nhận đưa dữ liệu cá nhân hoặc hợp đồng đầy đủ ra ngoài hệ thống nội bộ.
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. Bước 1: xác định sự kiện liên tổ chức thật sự gây tranh chấp
Không phải mọi trường dữ liệu đều cần chia sẻ. Case xác định 5 sự kiện: bảng giá có hiệu lực, mã căn giữ chỗ, xác nhận khoản tiền, phiên bản hợp đồng, trạng thái bàn giao hồ sơ. Các dữ liệu nội bộ như ghi chú chăm sóc khách hàng không cần vào sổ chung.
Ví dụ BĐS: Nhóm sinh viên phải chứng minh mỗi sự kiện đang gây chi phí đối soát hoặc tranh chấp.
Điểm kiểm soát: Loại mọi trường “đưa lên vì có sẵn” nếu không phục vụ quyết định.
5.2. Bước 2: phân biệt nguồn sự thật pháp lý và nguồn sự thật kỹ thuật
Thông tin về quyền, hợp đồng, thanh toán và công chứng có nguồn pháp lý khác nhau. Sổ công nghệ chỉ ghi trạng thái đã được các bên xác nhận; không tự thay cơ quan có thẩm quyền.
Ví dụ BĐS: Trạng thái “đã công chứng” chỉ được ghi sau khi hệ thống nhận bằng chứng từ quy trình công chứng hợp lệ.
Điểm kiểm soát: Lập bảng nguồn sự thật cho từng sự kiện.
5.3. Bước 3: kiểm tra xem có một bên trung tâm đủ tin cậy không
Nếu tất cả các bên chấp nhận chủ đầu tư làm nguồn dữ liệu duy nhất, cơ sở dữ liệu có API và chữ ký số có thể đủ. Nếu các bên độc lập muốn giữ bản sao và không cho một bên đơn phương sửa lịch sử, sổ phân tán có thêm giá trị.
Ví dụ BĐS: Ngân hàng có thể không muốn phụ thuộc hoàn toàn vào nhật ký của sàn môi giới.
Điểm kiểm soát: Phỏng vấn từng bên về quyền quản trị họ chấp nhận.
5.4. Bước 4: thiết kế dữ liệu tối thiểu trên sổ dùng chung
Case không đưa họ tên, CCCD, hợp đồng PDF lên chuỗi. Chỉ ghi mã giả danh, mã căn, loại sự kiện, thời điểm, hash tài liệu, chủ thể ký và trạng thái.
Ví dụ BĐS: Hợp đồng lưu tại kho riêng; hash cho phép các bên kiểm phiên bản.
Điểm kiểm soát: Thực hiện kiểm tra dữ liệu cá nhân trước thử nghiệm.
5.5. Bước 5: so sánh ba phương án bằng cùng bộ tiêu chí
Phương án A: cơ sở dữ liệu trung tâm; B: blockchain cấp quyền; C: kiến trúc lai DB + sổ dùng chung. Tiêu chí gồm chi phí, độ trễ, quản trị, chống sửa, tích hợp, riêng tư, khả năng sửa sai.
Ví dụ BĐS: Kiến trúc lai có thể thắng nếu chỉ vài trạng thái cần sổ dùng chung.
Điểm kiểm soát: Không chấm điểm theo cảm tính; ghi trọng số và giả định.
5.6. Bước 6: thiết kế xử lý ngoại lệ trước khi tự động hóa
Giao dịch sai căn, khách đổi hợp đồng, ngân hàng hoàn tiền, giao dịch on-chain thất bại, hệ thống kết nối hệ thống bị gián đoạn đều phải có quy trình.
Ví dụ BĐS: Không được dùng “immutable” làm lý do từ chối sửa lỗi nghiệp vụ; phải thêm giao dịch điều chỉnh có truy vết.
Điểm kiểm soát: Mỗi trạng thái phải có đường hoàn tác nghiệp vụ hợp lệ.
5.7. Bước 7: đặt tiêu chí thành công có thể đo
Thử nghiệm phải đo thời gian đối soát, số tranh chấp phiên bản, số lỗi đồng bộ, chi phí mỗi giao dịch, thời gian xử lý ngoại lệ và mức chấp nhận của các bên.
Ví dụ BĐS: Nếu chi phí tăng mà tranh chấp không giảm, blockchain không đạt mục tiêu.
Điểm kiểm soát: Định nghĩa đường cơ sở trước thử nghiệm.
5.8. Bước 8: quyết định có điều kiện, không quyết định tuyệt đối
Kết luận hợp lý có thể là “dùng cơ sở dữ liệu cho dữ liệu nghiệp vụ, blockchain cấp quyền cho 5 sự kiện liên tổ chức; sau 6 tháng đánh giá lại”. Đây là quyết định có thể đảo ngược và học hỏi.
Ví dụ BĐS: Không cần token hóa căn hộ để giải bài toán phiên bản hồ sơ.
Điểm kiểm soát: Giữ phạm vi thử nghiệm nhỏ và độc lập với quyền pháp lý chính thức.
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 |
|---|---|---|
| A. CSDL trung tâm | Rẻ, nhanh, dễ sửa, tích hợp quen thuộc | Phụ thuộc bên quản trị trung tâm |
| B. Blockchain cấp quyền | Lịch sử chung giữa tổ chức, nhiều bản sao | Quản trị mạng và tích hợp phức tạp |
| C. Kiến trúc lai | Giữ dữ liệu chi tiết trong DB, sổ chung cho sự kiện quan trọng | Phải đồng bộ hai lớp |
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. Vẽ quy trình hiện tại và điểm tranh chấp. 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. Định nghĩa sự kiện cần chia sẻ. 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 nguồn sự thật pháp lý. 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. Phân loại dữ liệu riêng tư. 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. So sánh A/B/C theo tiêu chí có trọng số. 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ế ngoại lệ và cơ chế điều chỉnh. 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. Đặt chỉ số đánh giá thử nghiệm và đường cơ sở. 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. Ra quyết định có điều kiện + kế hoạch đánh giá lạ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
- Bắt đầu bằng yêu cầu “phải dùng blockchain”. 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ệ.
- Token hóa căn hộ khi bài toán chỉ là đối soát. 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ệ.
- Đưa thông tin khách hàng 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ệ.
- Không hỏi ngân hàng/công chứng về quyền quản trị. 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 thiết kế lỗi kết nối hệ thố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 có đường cơ sở. 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ệ.
- Đánh giá thử nghiệm chỉ bằng số giao dịch. 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 tính chi phí vận hành lâu dà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ệ.
- Biến thử nghiệm chứng minh ý tưởng thành hệ thống chính thức quá sớ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ó tiêu chí dừ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ệ.
10. Khung pháp lý Việt Nam cần nhớ
Trong case này, lớp blockchain được dùng để chia sẻ bằng chứng và trạng thái giữa các bên, không được mô tả là thay thế công chứng, đăng ký quyền hoặc điều kiện giao dịch BĐS. Điều này phù hợp với nguyên tắc của Luật Giao dịch điện tử rằng phương tiện điện tử không tự thay nội dung, điều kiện và hình thức của giao dịch do luật chuyên ngành quy định.
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: Bước 1: xác định sự kiện liên tổ chức thật sự gây tranh chấp
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: Không phải mọi trường dữ liệu đều cần chia sẻ. Case xác định 5 sự kiện: bảng giá có hiệu lực, mã căn giữ chỗ, xác nhận khoản tiền, phiên bản hợp đồng, trạng thái bàn giao hồ sơ. Các dữ liệu nội bộ như ghi chú chăm sóc khách hàng không cần vào sổ chung.
Bối cảnh BĐS: Nhóm sinh viên phải chứng minh mỗi sự kiện đang gây chi phí đối soát hoặc tranh chấp.
Yêu cầu kiểm soát: Loại mọi trường “đưa lên vì có sẵn” nếu không phục vụ quyết định. 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: Bước 2: phân biệt nguồn sự thật pháp lý và nguồn sự thật kỹ thuậ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: Thông tin về quyền, hợp đồng, thanh toán và công chứng có nguồn pháp lý khác nhau. Sổ công nghệ chỉ ghi trạng thái đã được các bên xác nhận; không tự thay cơ quan có thẩm quyền.
Bối cảnh BĐS: Trạng thái “đã công chứng” chỉ được ghi sau khi hệ thống nhận bằng chứng từ quy trình công chứng hợp lệ.
Yêu cầu kiểm soát: Lập bảng nguồn sự thật cho từng sự kiện. 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: Bước 3: kiểm tra xem có một bên trung tâm đủ tin cậy khô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 tất cả các bên chấp nhận chủ đầu tư làm nguồn dữ liệu duy nhất, cơ sở dữ liệu có API và chữ ký số có thể đủ. Nếu các bên độc lập muốn giữ bản sao và không cho một bên đơn phương sửa lịch sử, sổ phân tán có thêm giá trị.
Bối cảnh BĐS: Ngân hàng có thể không muốn phụ thuộc hoàn toàn vào nhật ký của sàn môi giới.
Yêu cầu kiểm soát: Phỏng vấn từng bên về quyền quản trị họ chấp nhận. 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: Bước 4: thiết kế dữ liệu tối thiểu trên sổ dùng chung
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: Case không đưa họ tên, CCCD, hợp đồng PDF lên chuỗi. Chỉ ghi mã giả danh, mã căn, loại sự kiện, thời điểm, hash tài liệu, chủ thể ký và trạng thái.
Bối cảnh BĐS: Hợp đồng lưu tại kho riêng; hash cho phép các bên kiểm phiên bản.
Yêu cầu kiểm soát: Thực hiện kiểm tra dữ liệu cá nhân trước thử nghiệm. 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: Bước 5: so sánh ba phương án bằng cùng bộ tiêu chí
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: Phương án A: cơ sở dữ liệu trung tâm; B: blockchain cấp quyền; C: kiến trúc lai DB + sổ dùng chung. Tiêu chí gồm chi phí, độ trễ, quản trị, chống sửa, tích hợp, riêng tư, khả năng sửa sai.
Bối cảnh BĐS: Kiến trúc lai có thể thắng nếu chỉ vài trạng thái cần sổ dùng chung.
Yêu cầu kiểm soát: Không chấm điểm theo cảm tính; ghi trọng số và giả định. 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: Bước 6: thiết kế xử lý ngoại lệ trước khi tự động hó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: Giao dịch sai căn, khách đổi hợp đồng, ngân hàng hoàn tiền, giao dịch on-chain thất bại, hệ thống kết nối hệ thống bị gián đoạn đều phải có quy trình.
Bối cảnh BĐS: Không được dùng “immutable” làm lý do từ chối sửa lỗi nghiệp vụ; phải thêm giao dịch điều chỉnh có truy vết.
Yêu cầu kiểm soát: Mỗi trạng thái phải có đường hoàn tác nghiệp vụ hợp lệ. 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: Bước 7: đặt tiêu chí thành công có thể đo
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: Thử nghiệm phải đo thời gian đối soát, số tranh chấp phiên bản, số lỗi đồng bộ, chi phí mỗi giao dịch, thời gian xử lý ngoại lệ và mức chấp nhận của các bên.
Bối cảnh BĐS: Nếu chi phí tăng mà tranh chấp không giảm, blockchain không đạt mục tiêu.
Yêu cầu kiểm soát: Định nghĩa đường cơ sở trước thử nghiệm. 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: Bước 8: quyết định có điều kiện, không quyết định tuyệt đố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: Kết luận hợp lý có thể là “dùng cơ sở dữ liệu cho dữ liệu nghiệp vụ, blockchain cấp quyền cho 5 sự kiện liên tổ chức; sau 6 tháng đánh giá lại”. Đây là quyết định có thể đảo ngược và học hỏi.
Bối cảnh BĐS: Không cần token hóa căn hộ để giải bài toán phiên bản hồ sơ.
Yêu cầu kiểm soát: Giữ phạm vi thử nghiệm nhỏ và độc lập với quyền pháp lý chính thức. 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
- Luôn có phương án đối chứng không dùng blockchain.
- Quyết định công nghệ phải xuất phát từ mô hình tin cậy, dữ liệu, chi phí và rủi ro.
- Bước 1: xác định sự kiện liên tổ chức thật sự gây tranh chấp.
- Bước 2: phân biệt nguồn sự thật pháp lý và nguồn sự thật kỹ thuật.
- 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: Ví blockchain thực sự lưu gì nếu tài sản không “nằm trong ví”?