Selector Hàm Solidity

Giới Thiệu Selector Hàm Solidity

Công cụ Selector Hàm Solidity giúp các nhà phát triển làm việc với selector hàm hợp đồng thông minh Ethereum và chữ ký sự kiện. Selector hàm là 4 byte đầu tiên của hash Keccak256 của chữ ký hàm và được sử dụng để xác định hàm nào sẽ gọi trong hợp đồng thông minh. Chữ ký sự kiện (Topic0) là hash Keccak256 đầy đủ 32 byte của chữ ký sự kiện. Công cụ này tạo selector từ chữ ký và tra cứu selector phổ biến trong cơ sở dữ liệu tích hợp.

Selector hàm là gì?

Selector hàm là một mã định danh 4 byte được sử dụng trong Ethereum để chỉ định hàm nào sẽ gọi trong hợp đồng thông minh. Nó được tính toán là 4 byte đầu tiên của hash Keccak256 của chữ ký hàm. Ví dụ, chữ ký hàm 'transfer(address,uint256)' tạo ra selector '0xa9059cbb'.

Selector hàm được tính toán như thế nào?

Selector hàm được tính toán bằng cách:
1. Tạo chữ ký hàm (vd: 'transfer(address,uint256)')
2. Tính toán hash Keccak256 của chữ ký
3. Lấy 4 byte đầu tiên (8 ký tự hex) của hash
4. Thêm tiền tố '0x' để tạo selector

Chữ ký sự kiện (Topic0) là gì?

Chữ ký sự kiện, còn được gọi là Topic0, là hash Keccak256 đầy đủ 32 byte của chữ ký sự kiện. Không giống như selector hàm chỉ sử dụng 4 byte, chữ ký sự kiện sử dụng toàn bộ hash. Điều này được sử dụng để xác định các sự kiện trong log giao dịch. Ví dụ, 'Transfer(address,address,uint256)' tạo ra một Topic0 duy nhất 32 byte.

Tại sao cần tra cứu selector hàm?

Khi phân tích hợp đồng thông minh hoặc giao dịch, bạn thường gặp các selector hàm thô (như 0xa9059cbb) mà không biết chúng đại diện cho hàm nào. Tra cứu selector giúp bạn hiểu hàm nào đang được gọi. Điều này đặc biệt hữu ích cho debug, audit hoặc hiểu các hợp đồng không quen thuộc.

Sự khác biệt giữa selector hàm và sự kiện là gì?

Selector hàm là 4 byte (8 ký tự hex) và xác định lời gọi hàm, trong khi chữ ký sự kiện là 32 byte (64 ký tự hex) và xác định sự kiện trong log. Selector hàm được sử dụng trong dữ liệu đầu vào giao dịch, trong khi chữ ký sự kiện xuất hiện dưới dạng Topic0 trong log giao dịch.

Selector hàm khác Topic0 sự kiện ở chỗ nào?

Selector hàm là 4 BYTE ĐẦU của Keccak256(funcName(types)) dùng trong calldata giao dịch. Topic0 sự kiện là 32 BYTE đầy đủ của Keccak256(EventName(types)) dùng làm topic đầu tiên trong log. Hàm gọn (4 byte) vì calldata tốn gas; sự kiện dùng hash đầy đủ vì log là index off-chain để search.

Tại sao phải dùng Keccak-256 thay vì SHA3-256 cho Ethereum?

Ethereum chuẩn hóa trên phiên bản Keccak-256 trước NIST — TRƯỚC khi NIST tinh chỉnh thành SHA3 cuối (thêm padding). Nhiều thư viện gọi biến thể Ethereum là keccak256 để phân biệt. SHA3-256 và Keccak-256 ra hash KHÁC nhau cho cùng đầu vào — dùng SHA3 sẽ ra selector sai.

Hai hàm khác nhau có thể vô tình trùng selector 4 byte không?

Có, gọi là va chạm selector. Xác suất xấp xỉ 1/4.3 tỷ cho mỗi cặp hàm (2^32). Va chạm nổi tiếng Solidity 0x42966c68: burn(uint256) và burn_uint256_(uint256). Trình biên dịch hiện đại cảnh báo va chạm trong một contract. Rủi ro chủ yếu ở proxy pattern nơi bạn kiểm soát delegatecall.

Tra cứu một selector 4 byte lạ trên Etherscan thế nào?

Dán vào CSDL chữ ký như 4byte.directory hoặc Openchain.xyz — chứa hàng triệu chữ ký chuẩn hóa crowdsource từ contract đã xác thực. Công cụ này link tới cả hai. Nếu selector không có trong CSDL, hàm có thể từ contract chưa verify hoặc chiến lược DEX riêng; đôi khi có thể ghép theo mẫu calldata.

Quy tắc chữ ký canonical là gì, và tại sao 'uint' lại cho selector khác với 'uint256'?

Solidity hash một dạng canonical nghiêm ngặt: KHÔNG có khoảng trắng, mỗi kiểu phải viết đầy đủ. 'uint' là alias của 'uint256', 'int' của 'int256', và 'byte' của 'bytes1' — nhưng selector là Keccak-256 của chuỗi ký tự thực, nên 'transfer(address, uint256)' có khoảng trắng, hoặc 'transfer(address,uint)', sẽ ra giá trị KHÔNG BAO GIỜ khớp với contract đã triển khai. Tuple (struct) được viết dưới dạng danh sách kiểu trong ngoặc đơn, ví dụ exactInputSingle((address,address,uint24,...)), và các hậu tố mảng như [] hay [3] được giữ nguyên. Công cụ này chuẩn hóa đầu vào và hiển thị đúng chữ ký canonical đã hash, để bạn kiểm tra trước khi ký giao dịch.

Selector 4 byte liên quan thế nào tới calldata của một giao dịch?

Dữ liệu input của giao dịch = selector 4 byte theo sau là các đối số mã hóa ABI, mỗi đối số đệm thành một từ 32 byte (64 ký tự hex). Kiểu tĩnh (address, uint256, bool) nằm trực tiếp trong ô đầu của nó; kiểu động (bytes, string, T[]) đặt một OFFSET 32 byte trong ô đầu trỏ tới phần độ dài+dữ liệu ở đuôi. Vậy đọc calldata là: bỏ 4 byte đầu để xác định hàm, rồi cắt phần còn lại thành các từ 32 byte theo chữ ký. Mẫu Calldata trong công cụ này cho bạn bộ khung đó (selector + một từ số 0 cho mỗi đối số cấp cao nhất) để dán vào eth_call hoặc cast và điền vào.

Tính Năng Chính

• Tạo selector hàm (4 byte) từ chữ ký
• Tạo chữ ký sự kiện (Topic0, 32 byte)
• Hiển thị hash Keccak256 đầy đủ
• Tra cứu selector hàm phổ biến trong cơ sở dữ liệu tích hợp
• Xác thực định dạng chữ ký và selector
• Tải ví dụ ngẫu nhiên để thử nghiệm
• Liên kết đến cơ sở dữ liệu chữ ký bên ngoài (4byte.directory, Openchain)
• Bao gồm hơn 30 selector phổ biến của ERC20, DeFi và quản trị
• Tính toán phía client để bảo mật