Điều gì thực sự xảy ra khi bạn gửi một giao dịch Ethereum

--> Vấn Đề

Bạn nhấn “Gửi” trong ví của bạn. Giao diện xác nhận giao dịch.

Nhưng sau đó... không có gì xảy ra.

Đôi khi nó xác nhận trong vòng vài giây.
Đôi khi nó treo trong vài phút—hoặc hoàn toàn thất bại.

Tại sao?

Hầu hết các lời giải thích dừng lại ở “nó vào blockchain.”

Điều đó không hữu ích nếu bạn đang xây dựng hệ thống trên đó.

Hãy cùng phân tích xem điều gì thực sự xảy ra bên trong.

Mô Hình Tư Duy (Định Hướng Nhanh)


Một giao dịch không được thực thi ngay lập tức.

Nó di chuyển qua ba giai đoạn rõ ràng:

  • Lan truyền (mempool)

  • Bao gồm (đề xuất khối)

  • Thực thi (chuyển trạng thái)

Mỗi giai đoạn tạo thêm độ trễ, rủi ro và các chế độ lỗi.

Bước 1: Tạo giao dịch

Khi bạn bấm “send”:


  • Ví của bạn tạo giao dịch:

    • để

    • giá trị

    • gasLimit

    • maxFeePerGas

    • data (nếu có tương tác hợp đồng)

    Nó ký giao dịch bằng khóa riêng của bạn

Tại thời điểm này:
👉 Giao dịch hợp lệ nhưng chưa được mạng biết đến

Bước 2: Phát tán ra mạng

Ví của bạn gửi giao dịch tới một nút.

  • Nút đó:

  • Xác minh chữ ký

  • Kiểm tra nonce

  • Đảm bảo tính hợp lệ cơ bản

Nếu hợp lệ → nó đi vào mempool

Bước 3: Mempool (Nơi mọi thứ trở nên thú vị)

Mempool là:

  • Khu vực lưu giữ tạm thời

  • Không nhất quán trên toàn cục

  • Khác nhau giữa các nút

Điều này có nghĩa là:
👉 Giao dịch của bạn có thể tồn tại ở một số nút—nhưng không phải ở tất cả

Hành vi then chốt:

  • Các nút ưu tiên giao dịch theo phí

  • maxFeePerGas càng cao = ưu tiên càng cao

📊 Sơ đồ 1: Luồng lan truyền giao dịch


Sơ đồ nên thể hiện:

  • Ví người dùng → Nút A → Nút B → Nút C

  • Mỗi nút có mempool riêng

  • Các mũi tên thể hiện lan truyền gossip

  • Điểm nhấn: “Không phải mọi mempool đều giống nhau”

Bước 4: Đề xuất khối

Trình xác thực chọn giao dịch từ mempool của họ.

Họ sẽ chọn:

  • Giao dịch có phí cao nhất được ưu tiên trước

  • Các giao dịch nằm trong giới hạn gas

Quan trọng:
👉 Giao dịch của bạn đang cạnh tranh với những giao dịch khác


Bước 5: Thực thi (cấp EVM)


Ngay sau khi được đưa vào một khối

  • Giao dịch được thực thi bên trong EVM

  • Các thay đổi trạng thái xảy ra:

    • Cập nhật số dư

    • Thay đổi dữ liệu lưu trữ của hợp đồng thông minh

Nếu thực thi thất bại:

  • Vẫn tiêu tốn gas

  • Các thay đổi trạng thái bị hoàn lại

📊 Sơ đồ 2: Luồng thực thi


Sơ đồ nên thể hiện:

  • Khối → EVM → Chuyển trạng thái

  • Đầu vào:

    • Giao dịch

    • Trạng thái hiện tại


  • Đầu ra:

    • Trạng thái mới

  • Hãy đưa “tiêu thụ gas” vào mỗi bước

Các trường hợp biên & Chế độ lỗi

Đây là nơi hầu hết các bài viết thất bại. Hãy đi sâu hơn.

❌ 1. Giao dịch bị kẹt trong Mempool

  • Phí quá thấp

  • Không bao giờ được trình xác thực chọn

❌ 2. Giao dịch bị loại

  • Nút loại bỏ nó vì:

    • Phí thấp

    • Tràn mempool

❌ 3. Giao dịch bị thay thế

  • Cùng nonce + phí cao hơn → thay thế giao dịch ban đầu

❌ 4. Thực thi hết gas

  • Việc thực thi dừng giữa chừng

  • Trạng thái bị hoàn lại

  • Gas bị mất

❌ 5. Tổ chức lại chuỗi (Reorg)

  • Khối bị thay thế

  • Giao dịch có thể biến mất tạm thời


Hệ quả trong thực tế

Dành cho nhà phát triển:

  • Bạn không thể giả định tính hoàn tất ngay lập tức

  • Phải xử lý các trạng thái đang chờ

Vì UX:

  • Người dùng thấy “pending” → gây bối rối

  • Ước lượng phí trở nên cực kỳ quan trọng

Dành cho Thiết kế Hệ thống

  • Cần có logic thử lại

  • Theo dõi giao dịch là bắt buộc

Những điểm cần nhớ

  • Một giao dịch là quá trình nhiều giai đoạn, không phải một sự kiện đơn lẻ

  • Mempool là không xác định và bị phân mảnh

  • Phí ảnh hưởng trực tiếp đến xác suất được thực thi

  • Có thể xảy ra lỗi ở nhiều lớp

  • Hệ thống phải được thiết kế cho sự không chắc chắn và độ trễ


Nếu bạn đang xây dựng trên Ethereum, việc hiểu pipeline này là không thể thiếu—đó là nền tảng$ETH