Luận án nghiên cứu bảo mật tài sản trên các sàn giao dịch tập trung (CEX)

Liệu một sàn giao dịch tập trung (CEX) có thực sự an toàn nếu việc xâm phạm một lớp bảo mật có thể làm tổn hại toàn bộ hệ thống? Bảo mật tài sản không chỉ đơn thuần là bảo vệ khóa riêng, ví lạnh hay chữ ký đa lớp; nó phải được thiết kế để sống sót sau một cuộc tấn công. Nghiên cứu này đề xuất mô hình Kiến trúc Khả năng Sống sót của CEX với chín trụ cột, kết hợp Trí tuệ Nhân tạo (AI), Xử lý Đa lớp (MPC), Chống Khóa Tự động (ZK-Proof), Khóa Thời gian Động, Chứng thực Liên tục, Săn lùng Mối đe dọa và các cơ chế cách ly tự động, tất cả đều hướng đến một mục tiêu: không phải là không bao giờ bị tấn công, mà là sống sót ngay cả khi bị tấn công.

Vì vậy, sau hai sự cố lớn tại Bybit năm 2025 và Bitget năm 2026, bảo mật của các sàn giao dịch tập trung không còn chỉ là vấn đề "làm thế nào để bảo vệ khóa riêng?" nữa. Các sự cố gần đây cho thấy một thực tế quan trọng hơn: một CEX có thể duy trì chữ ký đa lớp, ví lạnh, HSM, phân tách ví nóng/ấm/lạnh và các hệ thống kiểm soát rủi ro, nhưng tài sản vẫn có thể bị đánh cắp nếu kẻ tấn công kiểm soát một liên kết nằm trước hoặc bên cạnh lớp ký giao dịch. Hai sự cố này có các phương thức tấn công khác nhau, nhưng chúng đều chỉ ra cùng một điểm yếu về cấu trúc: ranh giới bảo mật của một sàn giao dịch tập trung (CEX) không còn nằm ở ví điện tử nữa. Ranh giới đó trải dài từ môi trường phát triển → nhà cung cấp bên thứ ba → cơ sở hạ tầng đám mây → định danh và thông tin xác thực → API/phần mềm phụ trợ → công cụ đánh giá rủi ro → ký giao dịch → ví điện tử → chuỗi khối. Chỉ cần một mắt xích bị xâm phạm, kẻ tấn công có thể cố gắng biến hành vi bất hợp pháp thành một giao dịch được hệ thống công nhận là hợp lệ.

Đây là lý do tại sao vấn đề "máy bay bị bắn trúng" trở nên đặc biệt quan trọng đối với kiến ​​trúc bảo mật của CEX. Trong nghiên cứu về thiên kiến ​​sống sót của Abraham Wald, phân tích các máy bay trở về cho thấy rằng lớp giáp nên được tăng cường ở những khu vực máy bay sống sót sau cú bắn trúng, thay vì chỉ đơn giản là gia cố những khu vực bị trúng nhiều đạn nhất. Áp dụng vào CEX, câu hỏi không nên là "tin tặc thường tấn công ở đâu?", mà là "nếu tin tặc đã vượt qua một lớp bảo mật, thì lớp bảo mật tiếp theo nào có khả năng ngăn chặn việc mất hoàn toàn tài sản?". Vấn đề bảo mật mới của CEX

Kiến trúc bảo mật truyền thống của CEX chủ yếu được xây dựng dựa trên tư duy bảo mật phòng ngừa: ngăn chặn sự xâm nhập của kẻ tấn công, bảo vệ khóa riêng, sử dụng đa chữ ký, phân tán tài khoản, HSM, tường lửa, MFA, KYC, giám sát và hệ thống phát hiện bất thường. Đây vẫn là những lớp bảo mật thiết yếu, nhưng Bybit và Bitget cho thấy không lớp nào có thể được coi là hoàn toàn an toàn.

Sự khác biệt chính nằm ở từ "Sống sót". Một hệ thống CEX an toàn không nhất thiết phải là hệ thống không bao giờ bị xâm phạm. Một hệ thống thực sự kiên cường phải được thiết kế sao cho ngay cả khi một hoặc nhiều lớp bị xâm phạm, kẻ tấn công cũng không thể ngay lập tức chuyển quyền truy cập đó thành quyền kiểm soát hoàn toàn tài sản của sàn giao dịch. Một mô hình 9 trụ cột về khả năng sống sót và phòng thủ đa chiều cho CEX được đề xuất để mô phỏng toàn bộ quá trình từ vận hành đến bảo mật:

Minh Huy

Founder HCCVenture

Mô hình 9 trụ cột được xây dựng trên một nguyên tắc cốt lõi: không giả định bất kỳ lớp bảo mật nào là tuyệt đối an toàn. Sau các sự cố như Bybit và Bitget, rủi ro đối với tài sản CEX không còn chỉ đến từ việc private key bị đánh cắp mà có thể xuất phát từ giao diện ký giao dịch, credential nội bộ, phần mềm bên thứ ba, chuỗi cung ứng phần mềm, hệ thống CI/CD, quyền quản trị hoặc chính logic phê duyệt withdrawal. Vì vậy, kiến trúc bảo mật cần được chuyển từ tư duy “ngăn chặn mọi cuộc tấn công” sang “giới hạn khả năng biến một cuộc xâm nhập cục bộ thành một sự cố mất tài sản toàn hệ thống”. Mô hình đề xuất gồm ba lớp chính: Runtime Plane, bảo vệ trực tiếp quá trình rút tiền và luân chuyển tài sản; Platform Plane, bảo vệ phần mềm, danh tính và chuỗi cung ứng công nghệ; và Response Plane, bảo đảm khả năng phát hiện, cô lập, điều tra và phục hồi khi sự cố xảy ra.

Trụ cột 1 - Wallet Tiering: Phân tầng tài sản và giới hạn Blast Radius

Trụ cột đầu tiên đặt nền móng bằng việc phân tách tài sản thành các tầng Hot Wallet - Warm Wallet - Vault/Cold Wallet, thay vì tập trung thanh khoản vào một hệ thống lưu ký duy nhất. Hot wallet chỉ duy trì lượng tài sản cần thiết cho nhu cầu thanh toán tức thời và phải chịu một hạn mức exposure rõ ràng; warm wallet đóng vai trò lớp trung gian với HSM và các cơ chế phê duyệt bổ sung; trong khi tài sản dài hạn được đưa vào cold storage, ưu tiên môi trường air-gapped và có thể kết hợp với time-lock vault. Mục tiêu quan trọng nhất của trụ cột này không đơn thuần là “giữ phần lớn tài sản offline”, mà là kiểm soát Blast Radius: nếu hot hoặc warm wallet bị compromise, attacker không được phép tiếp cận trực tiếp toàn bộ treasury của sàn. Cách tiếp cận này chuyển tiêu chuẩn bảo mật từ “không được mất tiền” sang một chỉ tiêu có thể định lượng hơn: Maximum Loss Per Incident, mức tài sản tối đa có thể bị mất trong một sự cố đơn lẻ.

Trụ cột 2 – Signing Layer: Tách quyền kiểm soát tài sản khỏi một khóa duy nhất

Lớp signing là nơi giao dịch được chuyển từ trạng thái “được yêu cầu” sang “được phép thực thi”. Kiến trúc đề xuất kết hợp TSS-MPC, threshold signing, Passkey/WebAuthn và Account Abstraction để tạo nhiều lớp kiểm soát độc lập. Một hướng nâng cấp đáng chú ý trong mô hình là kết hợp MPC với smart account như ERC-4337, trong đó MPC bảo vệ lớp khóa còn smart contract thực thi các policy như giới hạn số tiền, whitelist và daily spending cap. Theo ý tưởng trong các tài liệu được nghiên cứu, nếu một phần MPC bị compromise thì việc sở hữu mảnh khóa không đồng nghĩa với việc attacker có thể tự do chuyển toàn bộ tài sản, bởi lớp policy on-chain vẫn có khả năng từ chối giao dịch không phù hợp. Đây là bước chuyển từ “key-based security” sang “policy-based security”.

Trụ cột 3 - Fund Segregation: Tách biệt tài sản khách hàng và tài sản vận hành

Trụ cột thứ ba tập trung vào việc ngăn sự cố tại hệ thống vận hành biến thành sự cố đối với toàn bộ tài sản khách hàng. Kiến trúc đề xuất tách client funds, exchange operating funds và settlement liquidity thành các miền tài sản riêng biệt, đồng thời sử dụng Proof of Reserves và các cấu trúc Merkle-based để tăng khả năng xác minh. Một hướng phát triển khác là sử dụng non-custodial clearing networks và automated netting để giảm lượng tài sản phải duy trì thường trực trong ví của sàn. Thay vì để CEX nắm giữ một lượng lớn thanh khoản phục vụ settlement 24/7, các giao dịch có thể được bù trừ theo chu kỳ thông qua cơ chế escrow và smart contract. Theo mô hình đề xuất, điều này có thể làm giảm attack surface về mặt tài sản bởi số dư thực sự nằm trong vùng có khả năng bị attacker tiếp cận trực tiếp được thu hẹp.

Trụ cột 4 – AI Monitoring: Biến hành vi bất thường thành tín hiệu bảo mật

Đây là một trong những lớp quan trọng nhất của mô hình và cũng là nơi thể hiện rõ nhất tư duy AI-driven security. Hệ thống không chỉ đánh giá withdrawal dựa trên amount, whitelist hay rule-based threshold, mà xây dựng một behavioral fingerprint của từng user, operator, signer và wallet. Các tín hiệu có thể bao gồm tốc độ thao tác, IP/ASN, network latency, thời gian thực hiện, lịch sử giao dịch, destination address, withdrawal frequency và bối cảnh thị trường. Mục tiêu là phát hiện những giao dịch “hợp lệ về mặt rule nhưng bất thường về mặt hành vi” và chính là dạng rủi ro mà rule engine truyền thống có thể bỏ qua.

Một điểm nâng cấp khác là Federated Learning, cho phép nhiều CEX hoặc tổ chức lưu ký cùng cải thiện mô hình phát hiện gian lận mà không cần chia sẻ trực tiếp dữ liệu người dùng. Mỗi tổ chức huấn luyện mô hình trên dữ liệu nội bộ và chỉ chia sẻ model updates hoặc các tham số cần thiết. Bên cạnh đó, kiến trúc Multi-Agent/LLM có thể được sử dụng như lớp phân tích ngữ cảnh phía trên hệ thống ML: khi mô hình định lượng phát hiện một withdrawal bất thường, AI agent có thể xem xét thêm trạng thái thị trường, lịch sử hành vi và các tín hiệu liên quan trước khi quyết định nâng hoặc hạ risk score. Đây là cách mô hình hướng tới giảm False Positive mà không phải hạ thấp tiêu chuẩn an toàn.

Trụ cột 5 - Policy & Timelock: Biến thời gian thành một lớp bảo mật

Một trong những ý tưởng quan trọng nhất của mô hình là Dynamic Timelock. Thay vì áp dụng một thời gian chờ cố định cho tất cả withdrawal, hệ thống xác định thời gian trì hoãn dựa trên giá trị giao dịch - destination risk - behavioral risk - historical pattern. Ví dụ, một withdrawal nhỏ tới địa chỉ đã giao dịch thường xuyên có thể được xử lý gần như tức thời; trong khi một giao dịch trị giá hàng triệu USD hoặc chuyển tới địa chỉ mới có thể bị trì hoãn 6–48 giờ và yêu cầu thêm xác thực.

Quan trọng hơn, timelock trong mô hình không chỉ nhằm “làm chậm hacker”, mà tạo ra cửa sổ phản ứng cho hệ thống. Trong khoảng thời gian đó, AI monitoring, human operator và blockchain intelligence có thể xác minh giao dịch. Mô hình còn đề xuất Breaker Switch sử dụng HSM và cơ chế Dead Man's Switch, trong đó một giao dịch đang treo có thể bị hủy hoặc đóng băng khi phát hiện compromise. Điều này biến “thời gian” từ một yếu tố vận hành thành một security control có thể định lượng.

Trụ cột 6 – Secure CI/CD: Bảo vệ phần mềm trước khi nó trở thành một phần của hệ thống tài sản

Bybit cho thấy một CEX không thể bảo vệ wallet nếu phần mềm nằm trước wallet đã bị compromise. Vì vậy, trụ cột thứ sáu đưa security xuống tận software supply chain. Mô hình đề xuất sử dụng SBOM, SCA, SAST, DAST, fuzzing, reproducible builds và artifact signing trong CI/CD. SBOM cho phép CEX biết chính xác hệ thống wallet đang phụ thuộc vào thư viện nào; SCA tìm kiếm dependency có CVE hoặc dấu hiệu supply-chain compromise; SAST kiểm tra source code; DAST kiểm tra hành vi của hệ thống trong môi trường sandbox.

Một lớp đặc biệt đáng chú ý là Reproducible/Deterministic Build. Ý tưởng là cùng một source code phải tạo ra cùng một binary/hash khi được build bởi các môi trường độc lập. Nếu source code đã được kiểm tra nhưng binary cuối cùng khác với kết quả được kỳ vọng, pipeline phải coi đây là một tín hiệu compromise và từ chối deployment. Kết hợp với Artifact Signing và Separation of Duties, chỉ những artifact được tạo từ pipeline đáng tin cậy mới có quyền chạy trong production.

Trụ cột 7 – Secrets & Identity: Loại bỏ “Master Credential”

Trụ cột thứ bảy giải quyết một trong những attack surface nguy hiểm nhất của CEX: identity và secret management. Thay vì để service hoặc nhân viên sở hữu static credentials có quyền truy cập dài hạn, kiến trúc đề xuất chuyển sang workload identity, SPIFFE/SVID, mTLS và dynamic credentials với TTL ngắn. Khi đó, một credential bị lộ không còn đồng nghĩa với việc attacker có một “master key” tồn tại vô thời hạn.

Về phía con người, mô hình còn đề xuất Passkey-linked MPC, trong đó thiết bị xác thực phần cứng và WebAuthn/Passkey trở thành một thành phần của quy trình ký. Cách tiếp cận này giảm sự phụ thuộc vào email hoặc cloud account làm yếu tố khôi phục duy nhất. Xa hơn, dMPC được đề xuất nhằm phân tán các thành phần MPC sang nhiều node độc lập thay vì tập trung toàn bộ trust vào một cloud hoặc một custodian. Đây là hướng nghiên cứu nhằm giảm single organizational dependency, dù cần lưu ý rằng các cơ chế này vẫn cần được đánh giá sâu về governance, availability, cryptographic assumptions và khả năng triển khai thực tế trước khi xem là giải pháp production-ready.

Trụ cột 8 – SOAR Response: Khi phát hiện compromise, hệ thống phải tự biết cách “đóng cửa”

Trụ cột thứ tám đưa bảo mật từ detection sang automated response. Một hệ thống SIEM/SOC truyền thống có thể phát hiện một withdrawal bất thường và gửi cảnh báo cho nhân viên. Tuy nhiên, trong một cuộc tấn công tài sản số, vài phút hoặc thậm chí vài giây có thể quyết định hàng triệu USD. Vì vậy, mô hình đề xuất SOAR có khả năng tự động thực hiện các hành động như pause warm tier, revoke service identity, cancel pending transactions, rotate key shares và kích hoạt emergency breaker.

Điểm quan trọng là automation phải được thiết kế theo nguyên tắc fail-safe: hệ thống không được tự động thực hiện những hành động có thể gây thiệt hại lớn hơn chính cuộc tấn công. Những hành động như đóng băng withdrawal, revoke credential hoặc tăng timelock có thể được tự động hóa ở mức cao; trong khi recovery hoặc movement của toàn bộ treasury cần một tầng xác thực độc lập. Mô hình cũng yêu cầu 24/7 alert paging để chuyển các tín hiệu critical tới con người ngay lập tức.

Trụ cột 9 - Forensics: Biến mỗi cuộc tấn công thành dữ liệu cho lần phòng thủ tiếp theo

Trụ cột cuối cùng là Forensics, bởi một hệ thống không thể trở nên an toàn hơn nếu không hiểu chính xác nó đã bị tấn công như thế nào. Toàn bộ hoạt động liên quan đến withdrawal, signing, policy decision, identity, deployment và blockchain transaction cần được lưu trong immutable logs, WORM storage hoặc các cấu trúc hash-chain để hạn chế khả năng attacker xóa dấu vết. Khi xảy ra sự cố, hệ thống cần kết hợp log nội bộ với on-chain tracing, graph clustering và blockchain intelligence để xác định attack path, destination và dòng tiền sau khi rời khỏi sàn.

Kiến trúc từ phòng thủ đến sinh tồn cho một quá trình

Điểm đặc biệt của mô hình 9 trụ cột là các lớp không hoạt động độc lập. Trụ cột 1-3 bảo vệ và giới hạn phạm vi tài sản có thể bị ảnh hưởng; Trụ cột 4-5 kiểm soát hành vi và quyết định giao dịch; Trụ cột 6-7 bảo vệ software supply chain và identity; trong khi Trụ cột 8-9 bảo đảm hệ thống có thể phản ứng và học lại sau sự cố.

Theo đó, một withdrawal có thể đi qua chuỗi:

Withdrawal Request → AI Monitoring → Policy & Dynamic Timelock → Signing Layer → Wallet Tiering → Fund Segregation → Blockchain Settlement

Trong khi phía sau chuỗi vận hành này tồn tại một Platform Security Layer gồm Secure CI/CD và Secrets & Identity, cùng một Response Layer gồm SOAR và Forensics. Điều này tạo thành một hệ thống phòng thủ theo chiều sâu, trong đó một lớp bị compromise không đồng nghĩa với việc toàn bộ hệ thống mất quyền kiểm soát tài sản. Mục tiêu không phải giả định rằng mọi lớp đều bất khả xâm phạm, mà phải xác định những điểm mà nếu bị xuyên thủng sẽ khiến toàn bộ hệ thống mất khả năng sống sót. Khi đó, tiêu chuẩn của một CEX an toàn không còn chỉ là “có multisig hay không”, “có cold wallet hay không” hoặc “có bảo hiểm bao nhiêu”, mà là:

Nếu một attacker đã vượt qua được lớp đầu tiên, hệ thống còn bao nhiêu lớp có thể ngăn họ tiếp cận tài sản? Nếu một phần tài sản đã bị chuyển đi, hệ thống có bao nhiêu thời gian để phát hiện và đảo ngược? Và nếu toàn bộ một trust domain bị compromise, những trust domain độc lập nào vẫn còn khả năng kiểm soát?

Bản quyền, Sở hữu trí tuệ và Tuyên bố miễn trừ trách nhiệm

Bản quyền. Bản quyền © 2026 Minh Huy (HCCVENTURE). Mọi quyền được bảo lưu. Xuất bản lần đầu tháng 10 năm 2026, Phiên bản 1.0.

Quyền sở hữu. Bài viết này là tác phẩm gốc của tác giả. Toàn bộ nội dung, hình ảnh, sơ đồ và bảng biểu, cũng như cách diễn đạt gốc của các khung lý thuyết được đề xuất, bao gồm mô hình “9 Trụ cột An ninh CEX”, Kiến trúc Khả năng Sống sót của CEX, và các mô hình ZK-PoR, Ví TEE, Bảo hiểm Lai CEX-DeFi, Bảo hiểm Lai dCustody, Chứng thực Liên tục, Công cụ Săn lùng Mối đe dọa AI, Bảo hiểm Mã hóa và Lý thuyết Trò chơi Kinh tế, đều được bảo vệ bởi luật bản quyền theo Luật Sở hữu trí tuệ của Việt Nam và Công ước Berne về Bảo vệ Tác phẩm Văn học và Nghệ thuật.

Bảo lưu quyền. Trừ những trường hợp được nêu dưới đây, không một phần nào của bài viết này được phép sao chép, dịch thuật, chuyển thể, phân phối, xuất bản hoặc sử dụng cho mục đích thương mại, dưới bất kỳ hình thức hoặc phương tiện nào, mà không có sự cho phép bằng văn bản trước của tác giả. Tác giả giữ toàn bộ quyền nhân thân, bao gồm quyền được xác định là tác giả của tác phẩm này, và tất cả các quyền sở hữu trí tuệ khác không được cấp rõ ràng ở đây.

Sử dụng được phép. Có thể trích dẫn các đoạn ngắn để phục vụ mục đích học tập, nghiên cứu, giảng dạy, phê bình, đánh giá hoặc đưa tin, với điều kiện nguồn được ghi nhận đầy đủ như trong trích dẫn được đề xuất bên dưới và đoạn trích không bị sửa đổi theo cách làm sai lệch ý nghĩa của tác giả. Yêu cầu cấp phép: Huyminhtruong23@hccventure.com.

Mã nguồn. Các đoạn mã có tiêu đề “SPDX-License-Identifier: MIT” được cấp phép theo Giấy phép MIT. Giấy phép đó chỉ áp dụng cho các đoạn mã đó, không áp dụng cho văn bản, hình ảnh hoặc bảng biểu xung quanh. Tất cả mã đều là một triển khai tham khảo minh họa chưa được kiểm toán và được cung cấp “nguyên trạng”, không có bất kỳ bảo hành nào.

Tác phẩm và nhãn hiệu của bên thứ ba. Các sự kiện, số liệu và trích dẫn từ các bên thứ ba được ghi rõ trong phần Tài liệu tham khảo và vẫn thuộc sở hữu của chủ sở hữu tương ứng. Tên, nhãn hiệu và logo của các công ty, sàn giao dịch, sản phẩm và tiêu chuẩn được đề cập trong bài viết này (bao gồm Binance, Bybit, Bitget, Coinbase, Kraken, Safe, Intel, AMD, AWS, HashiCorp, Chainlink và Starknet) thuộc sở hữu của các chủ sở hữu tương ứng. Việc đề cập đến chúng không ngụ ý bất kỳ sự liên kết hoặc chứng thực nào từ các chủ sở hữu đó.

Tuyên bố miễn trừ trách nhiệm. Bài viết này là một đề xuất nghiên cứu độc lập. Các kiến ​​trúc được mô tả trong đó chưa được xác thực trong môi trường sản xuất. Không có nội dung nào trong đó cấu thành lời khuyên pháp lý, tài chính, đầu tư hoặc chứng nhận bảo mật. Mô tả về các sự cố trong quá khứ dựa trên các nguồn công khai được trích dẫn và có thể được sửa đổi khi các cuộc điều tra tiếp tục.

Đề xuất trích dẫn: Minh Huy, “Bài viết tối cao về tài sản được bảo đảm trên sàn giao dịch tập trung (CEX)”, HCCVENTURE, Phiên bản 1.0, tháng 10 năm 2026. [Trực tuyến]. Có sẵn tại: https://hccventure.com

HCCVENTURE QUANT JSCO

Kết nối với chúng tôi

© 2026 HCCVENTURE . MỌI QUYỀN TÁC GIẢ ĐƯỢC BẢO LƯU

Thông tin liên hệ

Địa chỉ : Tầng 8, Tòa nhà Bạch Đằng Complex, 50 Bạch Đằng, Phường Hải Châu, Thành Phố Đà Nẵng, Việt Nam.

Điện thoại : 1900 1509

Gmail : sp_contact@hccventure.com

Thông tin về chúng tôi

Điều khoản

Phân tích thị trường

Khám phá HCCVenture group

Nội dung phổ cập

Đối tác chiến lược

Chính sách bảo mật

→ Đối tác chiến lược

→ Dữ liệu On-chain

→ Nhà đầu tư

→ Quan hệ truyền thông

→ Báo cáo thị trường

→ Dòng tiền ETFs

Nhận định chiến lược

Chia sẻ kiến thức

Miễn trừ trách nhiệm: Thông tin trên website này chỉ nhằm mục đích cung cấp thông tin tham khảo và không được xem là lời khuyên đầu tư. Chúng tôi không chịu trách nhiệm đối với bất kỳ rủi ro hay tổn thất nào phát sinh từ các quyết định đầu tư dựa trên nội dung tại đây.

ĐIỀU KHOẢN VÀ ĐIỀU KIỆN • CHÍNH SÁCH BẢO VỆ KHÁCH HÀNG

CÁC NỘI DUNG PHÂN TÍCH VÀ TIN TỨC ĐỀU ĐƯỢC TỔNG HỢP VÀ CUNG CẤP BỞI CÁC CHUYÊN GIA TRONG LĨNH VỰC TÀI CHÍNH SỐ VÀ BLOCKCHAIN THUỘC TỔ CHỨC HCCVENTURE, BAO GỒM QUYỀN SỞ HỮU NỘI DUNG.

CHỊU TRÁCH NHIỆM QUẢN LÝ TOÀN BỘ NỘI DUNG VÀ PHÂN TÍCH : NHÀ SÁNG LẬP HCCVENTURE - TRUONG MINH HUY

Đọc cảnh báo về lừa đảo và email lừa đảo — BÁO CÁO SỰ CỐ VỚI TRANG WEB CỦA CHÚNG TÔI.

Tin tức

CÔNG TY CỔ PHẦN DỮ LIỆU ĐỊNH LƯỢNG HCCVENTURE HOẠT ĐỘNG TRONG LĨNH VỰC PHÂN TÍCH DỮ LIỆU ON-CHAIN TÀI SẢN MÃ HÓA TRÊN BLOCKCHAIN VÀ CUNG CẤP CÁC BÁO CÁO NGHIÊN CỨU THÂM DÒ THỊ TRƯỜNG TÀI SẢN MÃ HÓA. KIỂM TRA THÔNG TIN HỒ SƠ DOANH NGHIỆP (MÃ SỐ DOANH NGHIỆP : 0402354866) TẠI WWW.MASOTHUE.COM