Trả lời ngắn: Bitcoin và Ethereum đều là blockchain nhưng tổ chức trạng thái khác nhau: Bitcoin dùng UTXO chưa tiêu cho giao dịch giá trị, còn Ethereum dùng account/state để chạy smart contract. So sánh kiến trúc giúp bạn đọc đúng dữ liệu, phí và giới hạn trước khi suy ra điều gì về ứng dụng hay token.

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

  • Bitcoin ghi nhận transaction bằng UTXO và Proof of Work ở mức khái niệm.
  • Ethereum quản lý account/state và smart contract execution ra sao.
  • Vì sao một transaction trên explorer không tự chứng minh người dùng, chất lượng ứng dụng hay mức an toàn.
  • Cách điền architecture card trong 15 phút, chỉ đọc và không dùng tiền thật.

Lưu ý giáo dục: Bài này giúp bạn đọc kiến trúc và đặt câu hỏi. Đây không phải lời khuyên mua bán, không cam kết lợi nhuận và không thay cho kiểm tra kỹ thuật. Blockchain vẫn có rủi ro về phần mềm, consensus, khóa truy cập, phí, thanh khoản và dữ liệu không đầy đủ.

1. Bitcoin và Ethereum Architecture Review là gì?

Architecture là cách các thành phần của một hệ thống được tổ chức và cách trạng thái đi từ dữ liệu cũ sang dữ liệu mới. Với blockchain, bạn không chỉ hỏi “chain này dùng token gì?”. Bạn cần hỏi mạng ghi nhận gì, ai kiểm tra, block được chấp nhận thế nào, chương trình chạy ở đâu và người quan sát thấy được bao nhiêu.

Người mới hay gom Bitcoin, Ethereum, protocol và ứng dụng vào một chữ “blockchain”. Cách gọi đó tiện cho cuộc trò chuyện, nhưng quá thô khi làm research. Bitcoin được thiết kế quanh việc ghi nhận chuyển giao giá trị ngang hàng. Ethereum mở rộng mô hình để account và chương trình trên chain cùng thay đổi trạng thái.

Hãy hình dung hai hệ thống giao vé. Hệ thống A phát hành từng phiếu chưa dùng; muốn trả tiền, bạn gom phiếu cũ và tạo phiếu mới. Hệ thống B giữ sổ tài khoản và trạng thái dịch vụ; một yêu cầu có thể vừa chuyển số dư vừa gọi chương trình. Cả hai đều có sổ được nhiều bên kiểm tra, nhưng câu hỏi và dữ liệu cần đọc không giống nhau.

Hình 1 — Hai architecture card đặt cạnh nhau: Bitcoin dùng UTXO, Ethereum dùng account/state và smart contract execution.

Bộ câu hỏi chung của bài là: state model, transaction flow, consensus, execution, fee và observation boundary. “Nhanh” phải nói nhanh ở bước nào. “An toàn” phải nói an toàn trước rủi ro nào. “Phi tập trung” phải nói quyền kiểm soát đang phân tán ở lớp nào.

2. Bitcoin: UTXO, Proof of Work và transaction flow

Transaction là yêu cầu chuyển dữ liệu hoặc giá trị mà mạng có thể kiểm tra. Bitcoin dùng mô hình UTXO, viết tắt của unspent transaction output: đầu ra của transaction trước đó chưa được dùng tiếp. Bạn có thể hình dung UTXO như những phiếu tiền chưa tiêu. Khi thanh toán, transaction dùng một hoặc nhiều phiếu cũ làm input, rồi tạo các phiếu mới làm output.

Ví dụ đơn giản: bạn có hai phiếu 0,4 BTC và 0,3 BTC nhưng muốn gửi 0,5 BTC. Transaction có thể dùng cả hai phiếu, tạo một output 0,5 BTC cho người nhận và một output còn lại cho chính bạn, sau khi tính phần phí. Đây là mô hình minh họa; không dùng số này để suy ra phí hoặc giá trị thật ở thời điểm khác.

Hình 2 — UTXO cũ được tham chiếu làm input, rồi tạo output mới; explorer cho thấy record nhưng không kể toàn bộ danh tính phía sau địa chỉ.

Luồng khái niệm gồm bốn bước:

  1. Người gửi tạo transaction, chọn UTXO đầu vào và chỉ định output.
  2. Các node kiểm tra chữ ký, điều kiện chi tiêu và dữ liệu có hợp lệ không.
  3. Một miner gom transaction vào block theo cơ chế Proof of Work, tức cạnh tranh tính toán để đề xuất block hợp lệ.
  4. Các block sau đó làm tăng số confirmation, nhưng confirmation không đồng nghĩa mọi rủi ro đã biến mất.

Bitcoin whitepaper đặt bài toán thanh toán ngang hàng và double-spending ở trung tâm. Bitcoin Developer Guide giúp đọc transaction, input, output và UTXO ở mức kỹ thuật hơn.

Điểm cần giữ: một địa chỉ có thể đại diện cho nhiều hoạt động khác nhau; một transaction hợp lệ không tự nói người dùng là ai, mục tiêu là gì hoặc hệ thống có sản phẩm tốt không. UTXO giải thích cách Bitcoin ghi nhận quyền chi tiêu, không phải bảng xếp hạng tài sản.

3. Ethereum: account, state và smart contract execution

Ethereum dùng account để đại diện cho thực thể có địa chỉ và trạng thái. Ở mức beginner, hãy tách hai loại: tài khoản do người dùng kiểm soát bằng khóa và tài khoản contract do code điều khiển. State là dữ liệu hiện tại mà mạng ghi nhận, gồm số dư, nonce và dữ liệu liên quan đến contract.

Smart contract là chương trình triển khai trên Ethereum. Khi một transaction gọi contract, môi trường thực thi xử lý hàm và có thể tạo thay đổi state. EVM là môi trường thực thi smart contract Ethereum. Gas là đơn vị đo lượng tính toán và lưu trữ cần dùng; phí thực tế phụ thuộc quy tắc mạng và transaction cụ thể, nên không nên viết “Ethereum luôn đắt” hoặc “luôn rẻ”.

Ví dụ: gọi một hàm để đọc trạng thái contract thường không ghi state. Gửi transaction để đổi state cần chữ ký, được đưa qua mạng và trả phí theo điều kiện tương ứng. Ethereum Technical Introduction giải thích account, transaction, block và state; Ethereum Smart Contracts giải thích contract ở mức ứng dụng.

Hình 3 — Ethereum có lớp account/state và execution; đọc state không giống gửi transaction để ghi state.

Composite case: Protocol X có một contract nhận yêu cầu đổi trạng thái. Việc contract chạy đúng điều kiện chỉ chứng minh code đã thực thi theo dữ liệu đầu vào. Nó chưa chứng minh UX tốt, oracle đúng, governance lành mạnh, người dùng quay lại hoặc token nhận giá trị. Đây là ranh giới quan trọng khi đi từ architecture review sang protocol research.

Ethereum cũng có nhiều lớp cần phân biệt: chain và consensus, execution environment, contract, frontend, wallet, oracle và dữ liệu ngoài chain. Nếu một dashboard cho thấy con số hoạt động, hãy hỏi con số ấy lấy từ lớp nào, có trùng địa chỉ không và data cut-off là khi nào.

4. Những chỗ người mới hay so sánh sai

a. “Ethereum nhanh hơn Bitcoin” là một câu chưa đủ

Bạn phải nói đang so tốc độ truyền transaction, thời gian block, thời gian quan sát confirmation hay thời điểm có finality theo mô hình được dùng. Một chain có block thường xuyên hơn chưa tự động phù hợp hơn cho mọi ứng dụng. Không có một con số cố định đúng trong mọi cấu hình và giai đoạn.

b. Gọi mọi xác nhận là finality

Finality là mức chắc chắn một trạng thái không bị đảo theo mô hình chain. Xác nhận làm tăng độ tin cậy, nhưng “đã thấy trên explorer” và “không thể đảo trong mọi điều kiện” là hai mệnh đề khác nhau. Khi viết research, ghi rõ bạn đang dùng confirmation hay finality.

c. Thấy smart contract là nghĩ sản phẩm đã an toàn

Code có thể chạy đúng mà logic kinh tế, quyền admin, oracle hoặc giao diện vẫn có rủi ro. Contract mở không đồng nghĩa người dùng hiểu hết điều kiện. Đọc architecture chỉ cho bạn biết code nằm ở đâu và trạng thái đổi thế nào; không thay cho audit hoặc kiểm tra threat model.

d. Dùng số transaction để đại diện cho người dùng

Một người có thể dùng nhiều địa chỉ, bot có thể tạo nhiều giao dịch và chương trình thưởng có thể làm hoạt động tăng ngắn hạn. Transaction là evidence về record, không phải bằng chứng đủ về danh tính, nhu cầu lặp lại hay product–market fit.

e. So token trước khi hiểu chain

Token, chain, contract và ứng dụng có thể liên quan nhưng không phải cùng một đối tượng. Trước khi suy luận, hãy tách vai trò, dòng phí, quyền quản trị, nguồn cung và nơi giá trị được ghi nhận. Nếu chưa có dữ liệu cho một vế, ghi chưa đủ evidence.

Hình 4 — Confirmation, finality và observation boundary là ba câu hỏi liên quan nhưng không đồng nhất.

5. Checklist và Practice Bridge 15 phút

Trước khi ghi một chain vào research note, dùng checklist này:

  1. State: chain ghi trạng thái theo UTXO hay account/state?
  2. Transaction: input, output, account, contract call và chữ ký nằm ở đâu?
  3. Consensus: ai đề xuất/kiểm tra block và mức chắc chắn được mô tả thế nào?
  4. Execution: code chạy ở lớp nào, điều kiện nào làm state đổi?
  5. Fee: phí trả cho tính toán, lưu trữ hay ưu tiên đưa transaction vào block?
  6. Observation: explorer cho thấy record nào, còn danh tính và động cơ nào chưa biết?
  7. Stop: dữ liệu nào thiếu khiến bạn chưa được phép kết luận?

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

Mở Bitcoin Developer Guide, Ethereum Technical Introduction hoặc một explorer công khai ở chế độ đọc. Không kết nối ví, không ký transaction, không nhập seed phrase và không dùng tiền thật. Chọn một transaction mẫu hoặc dùng Protocol X mô phỏng; không gán bảng mẫu cho dự án thật.

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

Hàng kiểm tra Bitcoin — mẫu Ethereum — mẫu Nhãn/giới hạn
State model UTXO chưa tiêu Account và contract state real (public) theo tài liệu, cần ghi nguồn
Transaction Input UTXO tạo output mới Account gọi hàm hoặc chuyển giá trị real (public) ở mức cơ chế
Consensus Proof of Work Không suy ra từ bài này nếu chưa đọc tài liệu consensus assumed nếu chưa kiểm tra
Execution/fee Kiểm tra điều kiện chi tiêu và phí transaction EVM thực thi, gas đo tài nguyên Không dùng để dự báo phí tương lai
Observation limit Record không chứng minh danh tính Contract call không chứng minh sản phẩm an toàn simulated nếu dùng Protocol X

Deliverable là một card năm dòng và một câu: “Điều gì sẽ khiến tôi đổi cách so sánh hai chain?”. Nếu không phân biệt được record với kết luận, điểm dừng là đọc thêm tài liệu; không chuyển sang hành động.

Hình 5 — Card năm dòng giúp giữ cùng một bộ câu hỏi khi so sánh hai chain, kèm điểm dừng khi evidence chưa đủ.

Tự kiểm tra trước bài #3

  • Tôi có thể giải thích UTXO khác account/state mà không nói “một cái tốt hơn tuyệt đối” chưa?
  • Tôi có thể chỉ ra read state khác write state ở Ethereum chưa?
  • Tôi đã tách confirmation, finality và explorer record chưa?
  • Tôi có biết điều gì chưa thể kết luận từ một transaction chưa?
  • Tôi có ghi source và data cut-off cho card chưa?

6. Tổng kết: chọn đúng câu hỏi trước khi đọc chain

Năm ý chính

  • Bitcoin và Ethereum đều là blockchain nhưng có state model khác: UTXO so với account/state.
  • Bitcoin transaction dùng input/output; Proof of Work và confirmation cần được nói đúng phạm vi.
  • Ethereum dùng account/state và smart contract execution; read không đồng nghĩa write.
  • Transaction, block hoặc dashboard là evidence có giới hạn, không tự chứng minh danh tính, nhu cầu hay an toàn.
  • Architecture card giúp chuyển từ nhãn chung “blockchain” sang câu hỏi có nguồn, giới hạn và điểm dừng.

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

  • UTXO là gì và vì sao transaction có thể tạo output trả lại?
  • Account/state của Ethereum khác mô hình UTXO ở điểm nào?
  • Vì sao “đã thấy trên explorer” chưa phải finality tuyệt đối?
  • Gas liên quan gì tới execution và vì sao không nên hứa một mức phí cố định?
  • Dữ liệu nào còn thiếu trước khi gọi một contract là sản phẩm an toàn?

Gợi ý đáp án

Xem gợi ý câu 1

UTXO là output chưa tiêu; transaction dùng nó làm input rồi tạo output mới. → Xem lại mục 2.

Xem gợi ý câu 2

UTXO theo dõi các phiếu chưa tiêu, còn account/state theo dõi thực thể và trạng thái hiện tại. → Xem lại mục 2 và 3.

Xem gợi ý câu 3

Explorer cho thấy record đã quan sát; confirmation và finality là mức chắc chắn theo các quy tắc khác nhau. → Xem lại mục 4.

Xem gợi ý câu 4

Gas đo tài nguyên execution; phí thực tế phụ thuộc transaction và điều kiện mạng, không phải lời hứa cố định. → Xem lại mục 3.

Xem gợi ý câu 5

Cần kiểm tra logic, quyền admin, oracle, governance, UX và threat model; code chạy đúng chưa đủ. → Xem lại mục 3 và 4.

Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
UTXO Đầu ra transaction chưa được dùng tiếp.
Account Thực thể có địa chỉ và trạng thái trên Ethereum.
State Dữ liệu hiện tại mà chain ghi nhận.
Consensus Quy trình giúp mạng thống nhất trạng thái.
Smart contract Chương trình chạy theo điều kiện trên chain.
Gas Đơn vị đo tài nguyên tính toán và lưu trữ.
Confirmation Block sau giao dịch làm tăng mức kiểm tra.
Finality Mức chắc chắn trạng thái không bị đảo theo mô hình chain.

Nguồn tham khảo

Bài tiếp theo

Bài #3 sẽ review Token, Smart Contract, DeFi và Web3 Ecosystem: từ architecture card, ta chuyển sang phân biệt token, contract, protocol và ứng dụng trong cùng một hệ sinh thái.

Nhắc lại: Nội dung chỉ phục vụ giáo dục, không phải lời khuyên mua hoặc bán và không cam kết lợi nhuận. Hãy dừng lại khi evidence, nguồn hoặc giới hạn quan sát chưa đủ.