dApp là gì?

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: dApp là ứng dụng có giao diện cho người dùng nhưng dùng smart contract và blockchain cho một phần logic hoặc dữ liệu cốt lõi. Một dApp hoàn chỉnh còn có thể cần wallet, RPC, node và dịch vụ ngoài chain. Vì vậy, “chạy blockchain” không có nghĩa mọi bộ phận đều phi tập trung hoặc an toàn.

Đọc xong, bạn sẽ hiểu:

• Một dApp gồm những lớp nào và lớp nào onchain.
• Một thao tác đọc khác một transaction ghi ra sao.
• Cách nhận diện điểm tập trung, rủi ro và điểm dừng trước khi ký.

1. dApp gồm những lớp nào?

Tên đầy đủ của dApp là decentralized application, thường dịch là ứng dụng phi tập trung. Theo Ethereum.org, dApp ghép smart contract với frontend, tức phần màn hình người dùng nhìn và bấm. Ngoài đời, dApp thường có các lớp:

1. Frontend hiển thị nút, biểu đồ, số dư và trạng thái.
2. Wallet giữ private key, cho biết địa chỉ người dùng và ký khi cần.
3. RPC là giao thức để frontend gửi yêu cầu tới node, tức máy tham gia mạng blockchain và cung cấp dữ liệu.
4. Smart contract xử lý quy tắc đã lập trình.
5. Blockchain state là dữ liệu hiện tại được mạng ghi nhận.
6. Dịch vụ phụ có thể gồm lưu trữ file, indexer, oracle hoặc máy chủ thông báo.

Phần ghi trên blockchain gọi là onchain; phần chạy bên ngoài là offchain. Contract và state có thể onchain, còn website, RPC hoặc dữ liệu vẫn có thể do một bên vận hành.

Hãy hình dung quầy dịch vụ: giao diện là quầy; wallet là con dấu cá nhân; RPC giống tổng đài; contract là bộ quy tắc; blockchain là sổ chung.

Hình 1 — Contract và state có thể onchain; frontend, RPC, storage, indexer hoặc oracle có thể nằm ngoài chain.

2. Một lượt bấm đi từ màn hình đến blockchain ra sao?

Không phải nút nào trên dApp cũng làm cùng một việc. Cần tách read và write.

Read: hỏi dữ liệu, không đổi state

Ví dụ bạn mở trang để xem số dư token:

1. Frontend tạo một yêu cầu đọc.
2. Yêu cầu đi qua RPC đến node.
3. Node đọc state hoặc mô phỏng function của contract.
4. Kết quả quay lại frontend để hiển thị.

Lượt đọc thông thường không tạo transaction, không đổi state và không cần trả gas onchain. Địa chỉ công khai cần tra cũng có thể được nhập thủ công.

Write: đề nghị đổi state

Ví dụ bạn bấm swap 10 token A sang token B:

1. Frontend chuẩn bị contract address, function, tham số và value.
2. Wallet hiện bản xem trước gồm network, tài sản, approval hoặc gas estimate.
3. Người dùng đọc rồi ký bằng private key.
4. Transaction được gửi qua RPC/node vào mạng.
5. Smart contract kiểm tra điều kiện và thực thi.
6. Nếu thành công, state đổi; nếu lỗi, transaction revert và có thể vẫn tốn gas.

Kết nối ví thường chỉ chia sẻ địa chỉ. Chữ ký tiếp theo có thể tạo transaction hoặc cấp quyền, nên đừng ký mọi cửa sổ hiện ra.

Token approval là quyền cho contract dùng token trong giới hạn. Trước khi ký, phải đọc contract nhận quyền, token và hạn mức.

Hình 2 — Nhánh read trả dữ liệu; nhánh write cần người dùng xem trước, ký và chờ mạng xác nhận hoặc revert.

Hình 3 — Read chủ yếu hỏi state; write đề nghị thay đổi state nên có thêm chữ ký, phí và rủi ro thực thi.

3. dApp khác ứng dụng thông thường ở đâu?

Ứng dụng thông thường để nhà vận hành quản lý database, server và logic. dApp chuyển một phần logic hoặc state sang blockchain. Ranh giới không phải trắng hoặc đen.

Với một DEX, frontend nhận số lượng; wallet ký; contract pool thực hiện swap; blockchain ghi số dư mới. Website ngừng hoạt động thì contract có thể vẫn tồn tại, nhưng người mới sẽ khó dùng nếu không có giao diện khác.

Các nhóm khác gồm nền tảng vay, NFT marketplace, game onchain và công cụ bỏ phiếu DAO. Một dApp có thể gọi nhiều contract; một contract có thể được nhiều frontend dùng.

Ethereum.org mô tả phi tập trung như một phổ. Không phải dịch vụ nào cũng cần thành dApp; tốc độ, trải nghiệm và dữ liệu riêng tư có thể đòi hỏi kiến trúc khác.

4. Rủi ro và giới hạn nằm ở cả onchain lẫn offchain

Frontend hoặc tên miền giả

Trang giả có thể chuẩn bị transaction tới contract khác. Hãy đối chiếu domain từ các kênh chính thức và đọc cửa sổ wallet.

RPC, indexer và oracle

RPC có thể ngừng phục vụ. Indexer sắp xếp dữ liệu để frontend truy vấn nhanh; indexer lỗi có thể làm lịch sử hiển thị thiếu. Oracle đưa dữ liệu ngoài đời vào contract; dữ liệu sai hoặc trễ có thể gây kết quả không mong muốn.

Contract, admin và dependency

Contract có thể có bug, proxy, admin key hoặc dependency. Source verified và audit cung cấp thêm thông tin, không bảo đảm an toàn.

Chữ ký, approval và sai network

Người dùng có thể ký nhầm message, cấp approval quá rộng, chọn sai network hoặc gửi tài sản tới address không tương thích. Theo hướng dẫn bảo mật Ethereum, không chia sẻ seed phrase/private key và phải đọc transaction trước khi ký.

Phí, tốc độ và trải nghiệm

Write có thể tốn gas hoặc revert. Ethereum.org nêu giới hạn về mở rộng, trải nghiệm, tiếp cận và chi phí; sai lầm onchain thường khó hoàn tác.

Câu đoán chắc: “dApp chạy blockchain nên mọi phần đều phi tập trung.” Sai. Website, RPC, oracle, indexer hoặc admin vẫn có thể là điểm tập trung.

Câu có điều kiện: dApp có thể giảm phụ thuộc vào một nhà vận hành nếu logic và state quan trọng nằm onchain, quyền quản trị được giới hạn, đồng thời người dùng có đường truy cập thay thế. Mức độ phải kiểm tra từng lớp, không nhìn mỗi chữ “dApp”.

Hình 4 — Onchain không xóa rủi ro offchain; mỗi lớp cần kiểm tra quyền kiểm soát và phương án thay thế.

5. Checklist và bài tập 15 phút chỉ đọc

Checklist trước khi dùng một dApp

1. Domain có đến từ nguồn chính thức và dùng kết nối bảo mật không?
2. Wallet đang ở đúng network không?
3. Contract address có khớp tài liệu hoặc explorer chính thức không?
4. Hành động là read, ký message, approval hay transaction write?
5. Function, token, value, recipient và gas có đúng điều bạn định làm không?
6. Approval có giới hạn hợp lý hay mở vô hạn?
7. Contract có admin, proxy, pause, oracle hoặc dependency nào?
8. Frontend/RPC lỗi thì có nguồn kiểm tra độc lập không?

Nếu domain, contract, function hoặc quyền cấp chưa rõ, dừng và đối chiếu lại. Đừng ký để “xem bước tiếp theo”.

Bắt đầu từ đâu: bài tập 15 phút

Dùng miễn phí trang tài liệu của một dApp mã nguồn công khai và block explorer tương ứng. Chỉ đọc; không kết nối ví, không ký, không cấp approval và chưa dùng tiền thật.

1. Phút 1–3: ghi tên network và contract address từ tài liệu.
2. Phút 4–6: mở explorer, tìm source verified và dấu hiệu proxy/admin.
3. Phút 7–10: ghi một read function và một write function.
4. Phút 11–13: xác định frontend, RPC, indexer hoặc oracle nếu tài liệu nêu.
5. Phút 14–15: đánh dấu điều đã biết, điều chưa biết và điểm phải dừng.

Mẫu đối chiếu đã điền

Kết quả mong đợi là một sơ đồ đủ các lớp và danh sách câu hỏi còn mở, không phải tìm được dApp để bỏ tiền.

Hình 5 — Thiếu một dữ kiện quan trọng là lý do dừng; bài tập đầu tiên chỉ cần đọc và đối chiếu.

6. Tổng kết: dApp là cả hệ thống, không chỉ một contract

a. Năm ý chính

• dApp ghép frontend với smart contract và thường cần wallet, RPC/node cùng dịch vụ hỗ trợ.
• Read hỏi dữ liệu; write đề nghị đổi state nên thường cần chữ ký, gas và xác nhận mạng.
• Website không phải toàn bộ giao thức; một contract có thể được nhiều frontend gọi.
• Phi tập trung là một phổ vì frontend, RPC, oracle, indexer hoặc admin vẫn có thể tập trung.
• Trước khi ký, phải kiểm tra domain, network, contract, function, value, approval và gas.

b. Câu hỏi tự kiểm tra

• Frontend, RPC/node và smart contract làm ba việc khác nhau thế nào?
• Vì sao read thường không cần gas onchain còn write thì có?
• Kết nối ví khác ký transaction ở điểm nào?
• Vì sao một dApp có contract onchain vẫn có điểm tập trung?

c. Gợi ý đáp án

Xem gợi ý câu 1

Frontend nhận thao tác, RPC/node chuyển và đọc dữ liệu, contract xử lý logic onchain. Xem lại mục 1.

Xem gợi ý câu 2

Read không đổi state; write yêu cầu mạng thực thi và ghi state mới. Xem lại mục 2.

Xem gợi ý câu 3

Connect chủ yếu chia sẻ địa chỉ; chữ ký có thể cấp quyền hoặc gửi transaction. Xem lại mục 2.

Xem gợi ý câu 4

Frontend, RPC, oracle, indexer và quyền admin vẫn có thể do một bên kiểm soát. Xem lại mục 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• Ethereum.org — Introduction to dApps
• Ethereum.org — JSON-RPC API
• Ethereum.org — Web2 vs Web3
• Ethereum.org — Frameworks
• Ethereum.org — Security

f. Bài tiếp theo nên đọc

Bài tiếp theo: DeFi là gì? Bạn sẽ thấy các dApp tài chính ghép smart contract thành dịch vụ swap, vay, cho vay và quản lý tài sản như thế nào.

Nội dung giáo dục, không phải lời khuyên đầu tư. dApp và smart contract có thể có lỗi; hãy kiểm tra mọi yêu cầu trước khi ký.