Event Log

Event log trong crypto là gì?

Event log là bản ghi có cấu trúc do hợp đồng thông minh tạo ra trong quá trình thực thi giao dịch blockchain.

Event log cho phép hợp đồng thông minh công bố thông tin để ví, ứng dụng phi tập trung, trình khám phá blockchain, nền tảng phân tích và các hệ thống off-chain khác tìm thấy và xử lý.

Trên Ethereum và các mạng dựa trên EVM khác, nhà phát triển thường tạo event log bằng cách khai báo event trong Solidity và dùng từ khóa emit khi xảy ra hành động liên quan.

Ví dụ, hợp đồng token có thể phát event khi token được chuyển, mint, burn hoặc phê duyệt để chi tiêu.

Giao thức DeFi có thể phát log khi người dùng nạp tài sản thế chấp, vay crypto, trả nợ, nhận phần thưởng hoặc đóng vị thế.

Tài liệu Solidity chính thức về event giải thích rằng event là lớp trừu tượng được xây dựng trên chức năng ghi log của EVM.

Event log thường không kiểm soát trạng thái hợp đồng hoặc thực thi thêm logic nghiệp vụ sau khi được phát ra.

Thay vào đó, event log cung cấp bản ghi hiệu quả để phần mềm bên ngoài hiểu được điều gì đã xảy ra trong một giao dịch.

Nhờ đó, event log trở thành cầu nối quan trọng giữa hợp đồng thông minh on-chain và các ứng dụng off-chain hiển thị hoạt động blockchain cho người dùng.

Event log hoạt động như thế nào?

Event log được tạo khi Ethereum Virtual Machine xử lý một nhánh thực thi thành công bên trong giao dịch.

Trước tiên, hợp đồng thông minh khai báo event với tên và danh sách tham số.

Sau đó, hợp đồng phát event khi mã chạy đến chỉ thị tương ứng.

Trình biên dịch Solidity chuyển thao tác phát event thành một trong các lệnh ghi log của EVM.

Log tạo ra chứa địa chỉ hợp đồng phát log, danh sách topic có thể tìm kiếm và trường dữ liệu chứa thêm thông tin đã mã hóa.

Log trở thành một phần của biên nhận giao dịch sau khi giao dịch được đưa vào block.

Ứng dụng có thể truy xuất log thông qua node Ethereum, nhà cung cấp RPC, trình khám phá blockchain hoặc indexer blockchain chuyên dụng.

Hướng dẫn của Ethereum về ghi event trong hợp đồng thông minh giải thích rằng ứng dụng phi tập trung có thể lắng nghe event được phát ra và thực hiện hành động off-chain khi chúng xuất hiện.

Nếu giao dịch bị hoàn tác, các log được tạo trong quá trình thực thi bị hoàn tác cũng bị loại khỏi kết quả giao dịch cuối cùng.

Vì vậy, log hiển thị trong mô phỏng hoặc dấu vết thực thi có thể không xuất hiện trong biên nhận đã xác nhận nếu toàn bộ lệnh gọi thất bại.

Event và event log

Event là khai báo do nhà phát triển định nghĩa, mô tả thông tin mà hợp đồng có thể công bố.

Event log là bản ghi thực tế được tạo khi hợp đồng phát event đó trong một giao dịch.

Ví dụ, hợp đồng có thể định nghĩa event Transfer trong mã nguồn.

Mỗi lần chuyển hoàn tất có thể tạo một log riêng dựa trên định nghĩa event đó.

Event giống như một mẫu, còn mỗi log là một lần ghi nhận mẫu đó.

Một giao dịch có thể không tạo log nào, tạo một log hoặc tạo nhiều log.

Giao dịch tương tác với nhiều hợp đồng thông minh có thể tạo log từ từng hợp đồng tham gia thực thi.

Ứng dụng sử dụng Application Binary Interface (ABI) của hợp đồng để đối chiếu log thô với khai báo event và giải mã giá trị.

Event log lưu trữ những thông tin nào?

Event log EVM chứa địa chỉ hợp đồng phát log, từ 0 đến 4 topic và một trường dữ liệu có độ dài thay đổi.

Địa chỉ phát log xác định hợp đồng có quá trình thực thi tạo ra log.

Topic chứa các giá trị được thiết kế để lọc và tìm kiếm hiệu quả.

Trường dữ liệu lưu các tham số event không được đánh dấu indexed.

Thông qua các giao diện RPC phổ biến, log cũng được trả về kèm siêu dữ liệu giao dịch và block.

Siêu dữ liệu này có thể gồm hash giao dịch, chỉ số giao dịch, hash block, số block và chỉ số log.

Chỉ số log xác định vị trí của log giữa các log khác trong cùng block.

Thông thường, ứng dụng nên kết hợp chain ID, hash block, hash giao dịch và chỉ số log để tạo định danh bản ghi duy nhất.

Chỉ dùng tên event hoặc hash giao dịch có thể không đủ vì một giao dịch có thể phát cùng một event nhiều lần.

Topic của event là gì?

Topic là giá trị 32 byte nằm trong phần có thể tìm kiếm đặc biệt của log EVM.

Topic cho phép ứng dụng lọc lịch sử blockchain mà không cần giải mã riêng từng trường dữ liệu của event.

Event Solidity thông thường không anonymous có thể dùng tối đa bốn topic.

Topic đầu tiên thường xác định loại event, còn tối đa ba topic bổ sung đại diện cho các tham số được đánh dấu indexed.

Topic có thứ tự, vì vậy lọc một giá trị ở vị trí topic thứ hai khác với lọc cùng giá trị ở vị trí thứ ba.

Tài liệu JSON-RPC chính thức của Ethereum về eth_getLogs giải thích rằng bộ lọc topic phụ thuộc vào thứ tự và có thể bao gồm các giá trị thay thế cho cùng một vị trí.

Topic đặc biệt hữu ích khi tìm event liên quan đến địa chỉ ví, mã định danh token, thị trường, đề xuất hoặc giá trị thường được truy vấn khác.

Lựa chọn tham số indexed không phù hợp có thể khiến dữ liệu lịch sử của ứng dụng khó hoặc tốn kém khi tìm kiếm.

Topic 0 là gì?

Topic 0 thường chứa hash Keccak-256 của chữ ký chuẩn của event.

Chữ ký chuẩn kết hợp tên event với các kiểu tham số theo thứ tự.

Tên tham số và từ khóa indexed không được đưa vào hash chữ ký event.

Ví dụ, event có tên Transfer với các kiểu tham số address, address và uint256 sẽ có chữ ký event xác định trước.

Ứng dụng có thể so sánh topic 0 với hash chữ ký đã biết để nhận diện event được biểu thị bởi log thô.

Thay đổi tên event hoặc thứ tự, kiểu tham số sẽ tạo ra chữ ký event khác.

Do đó, hai event cùng tên nhưng có kiểu tham số khác nhau sẽ có giá trị topic 0 khác nhau.

Thông số ABI của Solidity về event mô tả cách mã hóa chữ ký event và các tham số vào topic và dữ liệu.

Tham số event được đánh dấu indexed

Tham số indexed là tham số event được lưu trong topic để hệ thống bên ngoài lọc hiệu quả.

Solidity cho phép tối đa ba tham số indexed trong event thông thường không anonymous.

Vị trí topic còn lại dành cho chữ ký event.

Địa chỉ, số nguyên, giá trị Boolean và các giá trị khác vừa trong một từ 32 byte có thể được lưu trực tiếp trong topic bằng cách mã hóa tương thích ABI.

Giá trị động như chuỗi, mảng byte, mảng động và cấu trúc phức tạp được xử lý theo cách khác.

Khi một giá trị động được đánh dấu indexed, topic lưu hash Keccak-256 của giá trị đã mã hóa thay vì lưu giá trị gốc có thể đọc được.

Ứng dụng có thể lọc theo hash đó nếu đã biết giá trị cần tìm.

Tuy nhiên, chỉ từ hash thì không thể khôi phục chuỗi hoặc mảng byte gốc chưa biết.

Đôi khi, nhà phát triển đưa cùng một thông tin vào hai nơi: một bản băm trong tham số indexed và một bản dễ đọc trong tham số không indexed.

Thiết kế này cải thiện khả năng tìm kiếm đồng thời vẫn giữ giá trị gốc để giải mã.

Tham số event không indexed

Các tham số không có từ khóa indexed được lưu trong trường dữ liệu của log.

Những giá trị này được mã hóa theo quy tắc ABI của Ethereum.

Cần có ABI vì dữ liệu log thô không gắn nhãn tên và kiểu dễ đọc cho từng giá trị.

Ứng dụng cần định nghĩa event chính xác để giải mã dữ liệu đáng tin cậy.

Tham số không indexed có thể chứa giá trị lớn hơn hoặc phức tạp hơn topic đơn lẻ.

Chúng phù hợp với số lượng, giá trị cấu hình chi tiết, mảng, chuỗi và thông tin khác không cần lọc trực tiếp qua topic.

Thông thường, ứng dụng không thể yêu cầu eth_getLogs lọc theo một giá trị bất kỳ bên trong trường dữ liệu.

Trước tiên, ứng dụng phải truy xuất log theo địa chỉ hợp đồng và topic, sau đó giải mã và kiểm tra dữ liệu cục bộ.

Event anonymous

Event Solidity có thể được khai báo là anonymous.

Event anonymous không tự động đặt hash chữ ký event vào topic 0.

Nhờ đó, cả bốn vị trí topic đều có thể dùng cho tham số indexed.

Tuy nhiên, bỏ topic chữ ký khiến phần mềm bên ngoài khó tự động nhận diện loại event hơn.

Các event anonymous khác nhau có thể khó phân biệt nếu chúng có cấu trúc topic và dữ liệu tương tự.

Event anonymous có thể phù hợp với thiết kế cấp thấp chuyên biệt, nhưng event ứng dụng thông thường thường dễ lập chỉ mục và giải mã hơn khi không dùng anonymous.

Nhà phát triển chỉ nên dùng event anonymous khi topic indexed bổ sung đem lại lợi ích rõ ràng, đủ bù đắp cho việc giảm khả năng nhận diện event.

Opcode ghi log của EVM

EVM có năm opcode ghi log, tên từ LOG0 đến LOG4.

Số trong tên mỗi opcode thể hiện số topic có trong log.

LOG0 tạo log không có topic, còn LOG4 tạo log có bốn topic.

Mỗi thao tác ghi log cũng đọc một vùng bộ nhớ EVM được chọn và lưu vùng đó làm trường dữ liệu của log.

Event Solidity được biên dịch thành các chỉ thị ghi log cấp thấp này.

Môi trường thực thi gắn địa chỉ hợp đồng vào log, chứ địa chỉ này không được cung cấp như một tham số event thông thường.

Thao tác ghi log tiêu thụ gas dựa trên các yếu tố như số topic và lượng dữ liệu được ghi lại.

Tài liệu tham khảo opcode chính thức của Ethereum liệt kê các chỉ thị ghi log EVM và chi phí thực thi tương ứng.

Event log và biên nhận giao dịch

Biên nhận giao dịch là bản ghi thực thi được tạo sau khi giao dịch được đưa vào block.

Biên nhận chứa thông tin như trạng thái thực thi, tổng lượng gas tích lũy, bộ lọc Bloom của log và các log do giao dịch phát ra.

Phản hồi RPC có thể bổ sung các trường hữu ích khác như địa chỉ tạo hợp đồng, giá gas hiệu dụng và lượng gas của riêng giao dịch.

Mảng log giữ nguyên thứ tự event được phát ra trong quá trình thực thi.

Giao dịch thành công có thể có mảng log trống nếu không hợp đồng nào phát event.

Giao dịch thất bại thường không có event log được giữ lại vì các thay đổi trạng thái và log đã bị hoàn tác.

Ứng dụng nên kiểm tra trạng thái biên nhận thay vì coi sự tồn tại của hash giao dịch là bằng chứng thực thi thành công.

Phương thức JSON-RPC chính thức của Ethereum để truy vấn biên nhận giao dịch mô tả các trường biên nhận mà execution client trả về.

Event log và biên nhận block

Biên nhận giao dịch được cam kết bằng mật mã thông qua receipts root của block.

Cam kết này cho phép các bên tham gia blockchain xác minh biên nhận thuộc về lịch sử của một block cụ thể.

Mỗi biên nhận chứa log do giao dịch tương ứng tạo ra.

Theo định dạng execution block hiện hành, header block cũng có bộ lọc Bloom tóm tắt địa chỉ và topic của log từ các giao dịch trong block đó.

Bộ lọc Bloom giúp client xác định liệu block có thể chứa log khớp truy vấn hay không.

Kết quả khớp Bloom không chứng minh log khớp thực sự tồn tại vì bộ lọc Bloom có thể cho kết quả dương tính giả.

Kết quả không khớp cho thấy địa chỉ hoặc topic được tìm kiếm không xuất hiện trong bộ lọc đó.

Ứng dụng vẫn cần log thực tế trong biên nhận để xác nhận chính xác giá trị event.

Event log và storage của hợp đồng

Event log và storage của hợp đồng thông minh phục vụ các mục đích khác nhau.

Storage của hợp đồng chứa dữ liệu lâu dài mà quá trình thực thi hợp đồng thông minh sau này có thể đọc trực tiếp.

Event log chủ yếu được thiết kế để các hệ thống bên ngoài theo dõi và lập chỉ mục lịch sử.

Hợp đồng Solidity không thể trực tiếp đọc log lịch sử, kể cả log do chính hợp đồng đó phát ra.

Tài liệu tham khảo event của Solidity nêu rõ log và dữ liệu event không thể truy cập từ bên trong hợp đồng.

Hợp đồng không bao giờ nên phụ thuộc vào event trước đó làm nguồn duy nhất cho dữ liệu cần thiết trong quyết định on-chain sau này.

Nếu logic hợp đồng tương lai cần một giá trị, thông thường giá trị đó nên được lưu trong trạng thái hợp đồng hoặc cung cấp qua một cơ chế có thể xác minh.

Đối với thông tin chỉ dành cho người dùng off-chain, log thường rẻ hơn storage lâu dài.

Tuy nhiên, dùng log thay cho storage sẽ làm thay đổi khả năng hợp đồng thông minh xác minh hoặc truy xuất thông tin sau này.

Event log và dữ liệu trả về của hàm

Dữ liệu trả về của hàm được gửi cho bên gọi trực tiếp trong quá trình thực thi hợp đồng.

Event log được lưu trong biên nhận giao dịch để truy xuất về sau bằng hệ thống off-chain.

Giao dịch làm thay đổi trạng thái không cung cấp dữ liệu trả về cho giao diện người dùng dưới dạng lịch sử tiện dụng như event log.

Ứng dụng thường dựa vào biên nhận và event để biết kết quả của giao dịch đã gửi.

Lệnh gọi chỉ đọc có thể trả về giá trị mà không tạo event log hoặc thay đổi trạng thái blockchain.

Nhà phát triển nên dùng giá trị trả về để trao đổi trực tiếp trong lệnh gọi hợp đồng, và dùng event cho thông báo off-chain có thể truy xuất lâu dài.

Không nên coi event là phản hồi trực tiếp của hàm vì một giao dịch có thể có nhiều hợp đồng phát log.

Ứng dụng truy vấn event log như thế nào?

Ứng dụng thường truy vấn event log lịch sử bằng phương thức JSON-RPC eth_getLogs.

Truy vấn có thể chỉ định block bắt đầu, block kết thúc, địa chỉ hợp đồng, hash block và bộ lọc topic.

Phương thức này trả về một mảng log khớp với bộ lọc.

Truy vấn phạm vi hẹp thường đáng tin cậy và hiệu quả hơn yêu cầu mọi log trong một phạm vi block rất lớn.

Nhà cung cấp RPC có thể đặt giới hạn về phạm vi block, kích thước phản hồi, thời gian yêu cầu hoặc tần suất truy vấn.

Ứng dụng nên chia tìm kiếm lịch sử lớn thành các phạm vi block nhỏ hơn và lưu tiến độ.

Ứng dụng cũng nên thử lại yêu cầu thất bại với khoảng chờ có kiểm soát, thay vì cho rằng phản hồi trống hoặc thất bại chứng minh không có event nào.

Sử dụng bộ lọc blockHash theo EIP-234 có thể giúp ứng dụng yêu cầu log thuộc chính xác một block.

Polling và đăng ký event

Ứng dụng có thể phát hiện event log mới thông qua polling hoặc subscription.

Polling liên tục yêu cầu node cung cấp log hoặc thay đổi bộ lọc theo thời gian.

Subscription duy trì một kết nối trực tiếp để node gửi thông báo log mới khi có block.

Subscription có thể cập nhật nhanh hơn, nhưng kết nối có thể bị ngắt hoặc bỏ lỡ thông tin khi xảy ra sự cố.

Polling có thể dễ khôi phục hơn vì ứng dụng có thể yêu cầu lại một phạm vi block đã biết.

Hệ thống vận hành thực tế mạnh thường kết hợp subscription trực tiếp với đối soát định kỳ theo block.

Cách này giúp ứng dụng phát hiện log bị bỏ lỡ khi mạng gián đoạn hoặc node khởi động lại.

Tài liệu API JSON-RPC chính thức của Ethereum mô tả các phương thức bộ lọc để truy xuất log mới xuất hiện kể từ lần polling trước.

Event log và tái tổ chức chuỗi

Tái tổ chức chuỗi xảy ra khi một block trước đó được xem là thuộc chuỗi đang hoạt động bị thay thế bằng lịch sử block khác.

Log từ block bị thay thế không còn thuộc blockchain chính thức.

Ứng dụng đã phản ứng ngay với những log đó có thể cần đảo ngược các thay đổi tương ứng trong cơ sở dữ liệu cục bộ.

Một số phản hồi subscription RPC có thể cho biết log đã báo trước đó bị xóa do tái tổ chức.

Tuy nhiên, việc mất kết nối mạng có thể khiến ứng dụng không nhận được thông báo xóa.

Indexer đáng tin cậy theo dõi hash block và quan hệ với block cha để tự phát hiện block bị thay thế.

Phần giải thích về lọc log dựa trên hash block cho thấy vì sao ứng dụng cần xử lý cẩn thận tình huống tái tổ chức và mất kết nối.

Thông thường, hệ thống tài chính nên chờ đạt ngưỡng xác nhận hoặc finality phù hợp trước khi xem event là không thể đảo ngược.

Ngưỡng cần thiết phụ thuộc vào blockchain, giá trị ứng dụng và hậu quả của việc hành động quá sớm.

Event log và finality

Event mới phát có thể xuất hiện trong block được đề xuất trước khi block đạt mức finality đồng thuận cao hơn.

Ứng dụng có thể truy vấn log bằng các nhãn block như latest, safe hoặc finalized nếu client được kết nối hỗ trợ.

Nhãn latest cung cấp thông tin nhanh hơn nhưng có thể bao gồm block có rủi ro bị tái tổ chức cao hơn.

Nhãn finalized mang lại độ tin cậy cao hơn nhưng gây chậm trễ thêm.

Giao diện danh mục đầu tư có thể hiển thị event latest, trong khi bridge hoặc giao dịch tài chính lớn có thể cần mức xác nhận mạnh hơn.

Ứng dụng nên chọn chính sách xác nhận dựa trên rủi ro kinh tế thay vì áp dụng một quy tắc cho mọi event.

Event log trong hợp đồng token

Tiêu chuẩn token sử dụng event log để thông báo giao dịch chuyển token và phê duyệt cho ví cùng hệ thống dữ liệu blockchain.

Token có thể thay thế thường phát event Transfer khi giá trị được chuyển giữa các địa chỉ.

Token cũng có thể phát event Approval khi chủ sở hữu thay đổi hạn mức chi tiêu của một địa chỉ khác.

Hợp đồng NFT thường phát event chuyển và phê duyệt có chứa mã định danh token.

Hợp đồng đa token có thể phát event chuyển đơn lẻ và chuyển theo lô.

Cấu trúc event tiêu chuẩn hóa cho phép công cụ bên ngoài hỗ trợ nhiều hợp đồng token bằng cùng một logic giải mã.

Tuy nhiên, token vẫn có thể phát event gây hiểu lầm hoặc không tuân thủ đúng tiêu chuẩn.

Chỉ riêng event không chứng minh hợp đồng hợp pháp, có giá trị hoặc an toàn.

Event log trong tài chính phi tập trung

Giao thức tài chính phi tập trung sử dụng event log để mô tả các hoạt động tài chính phức tạp.

Ví dụ phổ biến gồm nạp, rút, hoán đổi, vay, trả nợ, thanh lý, cập nhật lãi suất, nhận phần thưởng và thay đổi quản trị.

Giao diện người dùng có thể theo dõi các event này để cập nhật số dư và lịch sử giao dịch.

Hệ thống phân tích có thể tổng hợp chúng để tính khối lượng, thanh khoản, hoạt động vay hoặc doanh thu giao thức.

Dịch vụ giám sát rủi ro có thể theo dõi event thanh lý hoặc tài sản thế chấp để phát hiện vị thế chịu áp lực.

Vì một giao dịch DeFi có thể gọi nhiều hợp đồng, biên nhận có thể chứa nhiều log liên quan.

Ứng dụng cần xem xét địa chỉ phát log và thứ tự log thay vì giải mã mọi chữ ký event quen thuộc như thể chúng đến từ hợp đồng giao thức chính.

Event log trong ví và trình khám phá blockchain

Ví sử dụng event log để tạo lịch sử dễ đọc từ các giao dịch hợp đồng thông minh thô.

Giao dịch chuyển token có thể không xuất hiện dưới dạng chuyển tài sản gốc trực tiếp trong các trường cơ bản của giao dịch.

Ví có thể giải mã event Transfer của hợp đồng token để hiển thị tài sản, người gửi, người nhận và số lượng.

Trình khám phá blockchain cũng giải mã log bằng ABI của hợp đồng đã xác minh và chữ ký event đã biết.

Khi không có mã nguồn hoặc thông tin ABI, trình khám phá có thể hiển thị giá trị topic và dữ liệu thô.

Nhãn đã giải mã nên được xem là cách diễn giải log thô, chứ không phải sự đảm bảo độc lập về ý định của hợp đồng.

Người dùng nên xác minh địa chỉ hợp đồng phát log trước khi tin vào mô tả event.

Event log và indexer blockchain

Indexer blockchain đọc block và biên nhận rồi lưu dữ liệu event đã chọn vào cơ sở dữ liệu dễ truy vấn.

Indexer giúp trả lời những câu hỏi khó xử lý bằng yêu cầu RPC trực tiếp.

Ví dụ gồm truy xuất mọi giao dịch chuyển token của một ví, tính hoạt động giao thức theo thời gian hoặc theo dõi mọi vị thế được mở trên thị trường cho vay.

Indexer thường bắt đầu từ một block được chọn rồi xử lý các block mới theo thứ tự.

Indexer giải mã log liên quan, tạo bản ghi cơ sở dữ liệu và lưu thông tin block cần thiết để xử lý tái tổ chức.

Indexer cần có khả năng tiếp tục sau sự cố mà không bỏ sót hoặc nhân đôi event.

Indexer cũng nên xử lý lại dữ liệu lịch sử khi lược đồ giải mã hoặc logic ứng dụng thay đổi.

Tài liệu Ethereum về dữ liệu và phân tích giải thích cách hệ thống dữ liệu blockchain xử lý log, biên nhận, trace và thông tin thực thi khác.

Event log và tự động hóa off-chain

Dịch vụ off-chain có thể lắng nghe event log và kích hoạt hành động bên ngoài blockchain.

Dịch vụ có thể gửi thông báo sau khi nạp tiền, cập nhật cơ sở dữ liệu nội bộ sau giao dịch hoặc bắt đầu quy trình khác sau một cuộc bỏ phiếu quản trị.

Bản thân log không buộc dịch vụ off-chain phải hành động.

Dịch vụ cần luôn hoạt động, nhận event, xác thực event và quyết định việc cần làm.

Hệ thống tự động hóa off-chain nên xác minh chain ID, địa chỉ hợp đồng, trạng thái block và các giá trị đã giải mã trước khi thực hiện hành động nhạy cảm.

Hệ thống cũng cần có tính idempotent, nghĩa là xử lý cùng một event hai lần không tạo ra kết quả trùng lặp sai lệch.

Biện pháp này quan trọng vì thử lại, kết nối lại và tái tổ chức có thể khiến cùng một log được ghi nhận nhiều lần.

Hợp đồng thông minh có thể đọc event log không?

Hợp đồng thông minh không thể trực tiếp tìm kiếm event log lịch sử thông qua quá trình thực thi EVM thông thường.

Log được thiết kế cho ứng dụng bên ngoài, chứ không phải làm trạng thái có thể đọc bởi hợp đồng.

Hợp đồng cần thông tin từ event trong quá khứ phải nhận thông tin đó qua một cơ chế khác.

Các cơ chế có thể gồm storage của hợp đồng, bằng chứng mật mã, oracle hoặc giao thức nhắn tin liên chuỗi.

Trước khi sử dụng, hợp đồng phải xác minh thông tin được cung cấp là đáng tin cậy.

Giới hạn này ngăn hợp đồng thông minh mặc nhiên coi phản hồi RPC off-chain là dữ liệu on-chain hợp lệ.

Event log có thể bị thay đổi không?

Không thể chỉnh sửa riêng một log đã xác nhận mà không thay đổi giao dịch và block đã tạo ra log đó.

Muốn thay đổi log, cần thay thế hoặc vô hiệu hóa lịch sử blockchain chứa biên nhận đó.

Việc tái tổ chức chuỗi có thể loại log khỏi lịch sử đang hoạt động trước khi đạt finality mạnh hơn.

Giao dịch mới có thể phát event điều chỉnh hoặc đảo ngược, nhưng không xóa log chính thức trước đó.

Ứng dụng nên giữ nguyên event lịch sử và thể hiện nội dung điều chỉnh dưới dạng bản ghi phát sinh sau, thay vì âm thầm viết lại dữ liệu blockchain gốc.

Event log có thể bị làm giả không?

Bất kỳ hợp đồng thông minh nào cũng có thể định nghĩa và phát event có tên cùng chữ ký quen thuộc.

Vì vậy, hợp đồng độc hại có thể phát event Transfer trông tương tự event của hợp đồng token hợp pháp.

Chỉ chữ ký event không xác định được tài sản và cũng không chứng minh có thay đổi số dư thực sự trong một hợp đồng đáng tin cậy.

Ứng dụng phải xác minh địa chỉ hợp đồng phát log và hiểu mã cùng trạng thái của hợp đồng đó.

Token lừa đảo cũng có thể phát giá trị gây hiểu lầm hoặc tạo event khiến người dùng tưởng một ví không hoạt động đã nhận tài sản.

Ví và trình khám phá không nên mặc nhiên coi mọi chữ ký event quen thuộc đều đáng tin như nhau.

Người dùng không nên tương tác với token chỉ vì thấy một event chuyển bất ngờ trong lịch sử giao dịch.

Event log và bảo mật hợp đồng thông minh

Thiết kế event là một phần của bảo mật hợp đồng thông minh vì hệ thống giám sát phụ thuộc vào log chính xác.

Các hành động quản trị quan trọng nên phát event rõ ràng khi quyền hạn, phí, địa chỉ oracle, triển khai nâng cấp hoặc cài đặt khẩn cấp thay đổi.

Thiếu event có thể khiến người dùng và đội ngũ bảo mật khó phát hiện thay đổi nguy hiểm hơn.

Giá trị event không chính xác có thể khiến hệ thống off-chain hiển thị kết quả không khớp với trạng thái hợp đồng.

Hợp đồng chỉ nên phát event sau khi các bước kiểm tra liên quan và thay đổi trạng thái đã thành công.

Nhà phát triển nên kiểm thử để bảo đảm mọi nhánh thực thi quan trọng phát đúng log dự kiến một lần duy nhất.

Nhà phát triển cũng nên kiểm tra để bảo đảm giao dịch bị hoàn tác không để lại log cuối cùng gây hiểu nhầm.

Event không thể thay thế việc thực thi quy tắc quyền hạn và số dư trong mã hợp đồng.

Chi phí gas của event log

Phát event tiêu thụ gas vì EVM phải xử lý chỉ thị ghi log và thêm thông tin vào biên nhận giao dịch.

Nhiều topic hơn và trường dữ liệu lớn hơn thường làm tăng chi phí ghi log.

Vì vậy, event có nhiều giá trị lớn có thể tốn kém hơn event tối giản.

Log thường rẻ hơn việc lưu cùng thông tin trong storage lâu dài của hợp đồng.

Tuy nhiên, log không cần thiết vẫn làm tăng chi phí giao dịch của người dùng và dung lượng lịch sử blockchain.

Nhà phát triển chỉ nên phát thông tin phục vụ nhu cầu lập chỉ mục, giám sát, kiểm toán hoặc giao diện người dùng thực sự.

Không nên sao chép mọi phép tính nội bộ vào event riêng nếu hệ thống bên ngoài không cần đến chúng.

Tối ưu gas không nên loại bỏ tính minh bạch quan trọng cần thiết để giám sát an toàn hoạt động giao thức.

Thực tiễn tốt khi thiết kế event

Tên event nên mô tả rõ hành động đã xảy ra.

Tên tham số cần đủ cụ thể để nhà phát triển và chuyên viên phân tích hiểu ý nghĩa.

Nên cân nhắc đánh dấu indexed cho các giá trị mà người dùng thường tìm kiếm.

Các giá trị indexed phổ biến gồm địa chỉ tài khoản, mã định danh token, mã định danh thị trường và mã định danh đề xuất.

Số lượng và giá trị cấu hình chi tiết thường có thể để trong trường dữ liệu nếu không cần lọc trực tiếp.

Nhà phát triển nên tránh đánh dấu indexed cho giá trị động, trừ khi việc lọc dựa trên hash có ích cụ thể.

Mỗi event nên có đủ ngữ cảnh để diễn giải mà không dựa vào giả định mong manh về thứ tự giao dịch.

Hợp đồng hỗ trợ nhiều tài sản hoặc thị trường nên bao gồm mã định danh tài sản hoặc thị trường tương ứng.

Event nâng cấp nên xác định cả giá trị cũ và mới khi thông tin đó có ích cho giám sát.

Khai báo event nên ổn định khi ứng dụng bên ngoài phụ thuộc vào chữ ký và bố cục tham số của event.

Thực tiễn tốt khi đọc event log

Ứng dụng nên lọc theo địa chỉ hợp đồng dự kiến cùng với chữ ký event dự kiến.

Ứng dụng nên giải mã log bằng phiên bản ABI chính xác của hợp đồng đang hoạt động tại block đó.

Hợp đồng có thể nâng cấp có thể thay đổi event khả dụng sau khi nâng cấp implementation.

Indexer nên lưu hash block, số block, hash giao dịch, chỉ số giao dịch và chỉ số log.

Indexer nên xử lý log theo thứ tự block chính thức và hỗ trợ hoàn tác sau khi chuỗi bị tái tổ chức.

Truy vấn lịch sử lớn nên được chia thành các phạm vi block có thể quản lý.

Ứng dụng cần phân biệt phản hồi thực sự trống với yêu cầu thất bại, bị cắt ngắn hoặc giới hạn tần suất.

Hành động tài chính nên chờ mức xác nhận phù hợp với giá trị và rủi ro.

Khi độ chính xác đặc biệt quan trọng, ứng dụng nên đối chiếu giá trị suy ra từ event với trạng thái hợp đồng.

Event log trên mạng Layer 2

Mạng Layer 2 dựa trên EVM thường dùng cấu trúc event log tương tự Ethereum.

Nhà phát triển thường có thể dùng event Solidity, topic, ABI và truy vấn JSON-RPC quen thuộc.

Tuy nhiên, hệ thống Layer 2 có thể khác về thời gian tạo block, quy tắc xác nhận, sequencer, cấu trúc phí và quy trình thanh toán cuối cùng.

Log do sequencer Layer 2 xác nhận có thể chưa đạt trạng thái thanh toán mạnh nhất trên Ethereum.

Event liên quan đến bridge có thể xuất hiện trên cả mạng nguồn lẫn mạng đích ở các giai đoạn khác nhau của quá trình chuyển.

Ứng dụng phải theo dõi đúng blockchain và không nên coi event từ các mạng riêng biệt là một lịch sử log chung.

Cùng một địa chỉ hợp đồng hoặc chữ ký event có thể đại diện cho các hợp đồng và tài sản khác nhau trên những blockchain khác nhau.

Event log trong chuyển tài sản liên chuỗi

Hệ thống liên chuỗi thường dùng event để báo hiệu tài sản đã được khóa, burn, giải phóng hoặc mint.

Relayer off-chain hoặc giao thức trên mạng đích có thể quan sát event của mạng nguồn trước khi tiếp tục quá trình chuyển.

Hành động trên mạng đích phải xác minh event nguồn bằng proof hoặc thiết kế validator của bridge.

Chỉ nhìn thấy log qua nhà cung cấp RPC thông thường không đủ để hợp đồng thông minh không cần tin cậy chứng minh event hợp lệ.

Bridge cũng phải tính đến việc tái tổ chức và finality của mạng nguồn.

Bridge hành động quá nhanh có thể xử lý event sau đó bị loại khỏi lịch sử nguồn chính thức.

Người dùng cần hiểu rằng event bridge được phát ra có thể chỉ báo hiệu quá trình chuyển bắt đầu, chứ chưa hoàn tất.

Ví dụ về event log

Giả sử người dùng chuyển 500 đơn vị token có thể thay thế sang một ví khác.

Người dùng gửi giao dịch gọi hàm transfer của hợp đồng token.

Hợp đồng kiểm tra số dư của người gửi và cập nhật số dư của người gửi cùng người nhận.

Sau đó, hợp đồng phát event Transfer chứa địa chỉ người gửi, địa chỉ người nhận và lượng token được chuyển.

Địa chỉ người gửi và người nhận có thể được lưu trong topic indexed, còn số lượng được mã hóa theo ABI trong trường dữ liệu.

Hash chữ ký event xuất hiện trong topic 0.

Sau khi giao dịch được đưa vào block, log xuất hiện trong biên nhận giao dịch.

Ví truy xuất và giải mã log để hiển thị việc chuyển token trong lịch sử giao dịch dễ đọc.

Indexer cũng ghi lại event để người dùng tìm kiếm mọi giao dịch chuyển liên quan đến một trong hai địa chỉ.

Ví dụ này cho thấy một event log kết nối quá trình thực thi hợp đồng với ví, trình khám phá và phân tích blockchain như thế nào.

Lỗi thường gặp khi xử lý event log

Một lỗi phổ biến là cho rằng hợp đồng thông minh khác có thể đọc event.

Lỗi khác là xem chữ ký event quen thuộc như bằng chứng hợp đồng phát log hợp pháp.

Lỗi thứ ba là giải mã log mà không kiểm tra địa chỉ hợp đồng.

Lỗi thứ tư là cho rằng có thể khôi phục trực tiếp chuỗi được indexed từ hash topic.

Lỗi thứ năm là chỉ dùng hash giao dịch làm định danh log.

Lỗi thứ sáu là không xử lý tình huống chuỗi bị tái tổ chức.

Lỗi thứ bảy là xử lý cùng một log hai lần sau khi RPC được thử lại hoặc ứng dụng khởi động lại.

Lỗi thứ tám là truy vấn phạm vi block cực lớn rồi xem yêu cầu hết thời gian chờ như kết quả trống.

Lỗi thứ chín là chỉ dựa vào event khi logic hợp đồng thông minh trong tương lai cần cùng dữ liệu đó trong storage.

Lỗi thứ mười là cho rằng event giải mã thành công chứng minh mọi thay đổi trạng thái dự kiến đều xảy ra chính xác.

Câu hỏi thường gặp

Event log trong crypto là gì?

Event log là bản ghi có cấu trúc do hợp đồng thông minh phát ra để mô tả các hành động xảy ra trong quá trình thực thi giao dịch blockchain.

Event log Ethereum được lưu ở đâu?

Event log Ethereum được đưa vào biên nhận giao dịch, và các biên nhận này được cam kết như một phần lịch sử thực thi của block.

Event khác log như thế nào?

Event là khai báo trong mã hợp đồng thông minh, còn log là bản ghi thực tế được tạo khi event đó được phát ra.

Hợp đồng thông minh có thể đọc event log cũ không?

Không. Hợp đồng thông minh không thể trực tiếp tìm kiếm hoặc đọc log lịch sử thông qua quá trình thực thi EVM thông thường.

Topic 0 trong event log Ethereum là gì?

Topic 0 thường chứa hash Keccak-256 của tên event và kiểu tham số chuẩn.

Một event log có thể có bao nhiêu topic?

Log EVM có thể có tối đa bốn topic; event Solidity thông thường thường dành một topic cho chữ ký event.

Indexed trong event Solidity nghĩa là gì?

Tham số indexed được lưu trong topic để ứng dụng bên ngoài lọc log dựa trên giá trị đó.

Có thể đánh dấu indexed cho chuỗi trong event log không?

Có, nhưng chuỗi indexed được biểu thị bằng hash Keccak-256 thay vì chuỗi gốc có thể đọc được.

Điều gì xảy ra với event log khi giao dịch bị hoàn tác?

Log tạo ra trong quá trình thực thi bị hoàn tác sẽ bị loại khỏi kết quả giao dịch cuối cùng.

Event log có tốn gas không?

Có. Phát log tiêu thụ gas, một phần chi phí phụ thuộc vào topic và kích thước dữ liệu.

Event log có chứng minh token hợp pháp không?

Không. Bất kỳ hợp đồng nào cũng có thể phát event quen thuộc, vì vậy người dùng cần xác minh hợp đồng phát log và trạng thái thực tế của nó.

Nhà phát triển có thể truy xuất event log bằng cách nào?

Nhà phát triển có thể truy xuất log thông qua các phương thức như eth_getLogs, truy vấn biên nhận, bộ lọc, subscription, trình khám phá blockchain hoặc dịch vụ lập chỉ mục.

Tái tổ chức blockchain có thể loại bỏ event log không?

Có. Log từ block bị thay thế sẽ bị loại khỏi lịch sử chuỗi chính thức.

Event log có giống nhau trên mọi blockchain EVM không?

Cấu trúc cơ bản thường tương tự, nhưng chain ID, hợp đồng, lịch sử block, finality và cách hoạt động RPC có thể khác nhau.

Event log có rẻ hơn storage hợp đồng không?

Log thường rẻ hơn đối với thông tin lịch sử dành cho hệ thống off-chain, nhưng không thể thay thế storage mà quá trình thực thi hợp đồng thông minh trong tương lai cần đọc.

Vì sao ví sử dụng event log?

Ví sử dụng event log để nhận diện giao dịch chuyển token, phê duyệt, hoán đổi và các hoạt động hợp đồng thông minh khác vốn không thể hiện rõ chỉ qua các trường cơ bản của giao dịch.

Kết luận

Event log là bản ghi có cấu trúc, kết nối quá trình thực thi hợp đồng thông minh với ví, ứng dụng phi tập trung, trình khám phá blockchain, hệ thống phân tích và các dịch vụ off-chain khác.

Event log được tạo bằng chỉ thị ghi log của EVM và lưu trong biên nhận giao dịch sau khi giao dịch thực thi thành công.

Log chứa địa chỉ hợp đồng phát log, topic có thể tìm kiếm và dữ liệu event được mã hóa theo ABI.

Topic 0 thường xác định chữ ký event, còn tham số indexed cung cấp thêm tùy chọn lọc.

Tham số không indexed được lưu trong trường dữ liệu và cần đúng ABI để giải mã.

Event log khác storage của hợp đồng vì hợp đồng thông minh không thể trực tiếp đọc log lịch sử.

Event log cũng khác dữ liệu trả về của hàm vì log được thiết kế để xử lý lịch sử off-chain.

Ứng dụng có thể truy xuất log qua bộ lọc JSON-RPC, subscription, biên nhận giao dịch, trình khám phá blockchain và indexer chuyên dụng.

Hệ thống đáng tin cậy cần xử lý việc xử lý trùng lặp, giới hạn RPC, tái tổ chức chuỗi, nâng cấp hợp đồng và các mức xác nhận khác nhau.

Người dùng cần nhớ rằng tên event quen thuộc không chứng minh hợp đồng phát log đáng tin cậy hoặc token hợp pháp.

Nhà phát triển nên thiết kế event với tên rõ ràng, tham số indexed hữu ích, đủ ngữ cảnh và lược đồ ổn định.

Hiểu event log giúp người dùng crypto và nhà phát triển diễn giải chính xác hơn giao dịch chuyển token, hoạt động DeFi, thay đổi hợp đồng thông minh, biên nhận giao dịch và dữ liệu ứng dụng on-chain.