first level title
foreword
When you look up transactions on a blockchain explorer, are you just looking at overviews and internal transactions? What about the event log? Whether it is ignored by you in an inconspicuous corner.
Next, I will help you understand in detail about the event log of Ethereum and some basic knowledge about it.
first level title
event
2.1 What is an event?
Event is an interface that can conveniently call the logging function of the Ethereum Virtual Machine.
The Solidity event is an abstraction above the logging function of the EVM. Applications can subscribe to and listen to these events through the RPC interface of the Ethereum client, allowing us to print information on the blockchain.
So through Solidity events, we can do:
Test specific variables in smart contracts
Index variables to reconstruct stored state
Listening events are used to change the state of the front end
Create subgraphs to read data faster
2.2 Declaration and triggering events
Let's take the official ERC20 contract code as an example, and declare it through the event keyword in the IERC20.sol file.
In the _transfer function of ERC20.sol, the corresponding event is triggered by the emit keyword (the previous version does not need to use emit).
first level title
log
3.1 What are logs?
In Ethereum, logs are used to store events. When the event is invoked, the trigger parameters are stored in the transaction's log. It cannot be accessed by smart contracts, but can provide information about transactions and sent in blocks.
Let's open a transaction (0x477ed7208127bea597142622d52df46d3e4967835bd3609995581eb5aaeeec3e) at will to view its logs.
Through the log we can divide the log into four parts:
1. Address: Address. That is, the address of the contract or account that issued the event.
2. Name: name. That is, the name of the triggered event and its parameters.
3. Topics: theme. That is, there are indexed parameters in the event.
4. Data: Data. That is, parameters without an index in the event.
3.2 Topics in Logging
We mentioned the topic (Topics) above, and then we will talk about the topic in detail.
Each log record contains "topics" and "data". A topic is 32 bytes (256 bits) and describes what happened in the event. Different opcodes (LOG0 LOG1 LOG2 LOG3 LOG4) are used to describe the number of topics that need to be included in the log record.
There are 5 opcodes in the EVM used to trigger event logs and create log records, namely LOG0, LOG1, LOG2, LOG3, and LOG4, which are used to describe events in smart contracts, such as token transfers, ownership changes, etc. LOG1 contains one topic, and the maximum number of topics that can be included in a single log record is the four topics of LOG4.
Topics0 is usually the signature of the event name (keccak256 hash value), including the type of its parameters (address, uint256, etc.), Topics1 is the value of the first index parameter, and Topics2 is the value of the second index parameter.
The value of Topics0 in this topic is 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef, and its event is the content of the previous line of Name.
However, we encrypt the event Transfer(address, address, uint256) with keccak256 and the result is the same as the value of Name, indicating that the value of Name is indeed the signature of the event name. Of course, there is one exception where there is no event signature, and that is when an "anonymous event" is triggered.
Topics1 is the value of the first index parameter, that is, the value of the form address. Topics2 is the value of the second index parameter, that is, the value of the to address. It can also be seen from the internal call analysis that this is indeed the case.
A topic can only contain 32 bytes of data, so things like arrays, strings, etc. that may be more than 32 bytes cannot be used as a topic, if you are trying to contain data larger than 32 bytes, the topic must It has been calculated by hash, so it is better to include it as data in the log record after exceeding 32 bytes.
3.3 Data in log records
In addition to the subject, part of the log record is data. The data is the ABI code or hash value of the non-index parameter of the event. We can use Dec or Hex to view the value of the data data.
Both data and topics have their pros and cons:
Topics are searchable, data are not.
Data requires less gas than topics.
Since the topic is a parameter with an index, we can search directly in the log, but the data is an ABI code or hash value, so we cannot search directly.
According to the Yellow Paper, we can find the related gas cost of logs. The basic cost of logs is 375 gas, each topic is also 375 gas, and the cost of data bytes is 8 gas.
We can know from the Yellow Paper that the gas cost of the log is very cheap. The cost of an ERC20 token transfer event only costs 1756 gas at most (375 gas for the log basis, 375 * 3 = 1125 gas for the 3 topics of the transfer event, and the largest data byte 32 bytes is 8 * 32 = 256 gas), while the transfer of standard ether takes 21000 gas. Of course, what I said above is only the cost of the log record operation itself. In the development of smart contracts, the cost of log record operations cannot be simply calculated, but in development, we can only save the data needed by the smart contract in the state variable, and other Events are used for processing, which can save a lot of gas costs.
trigger event
Next, an example is used to illustrate the trigger event. The following code implements the transfer event used by the token contract that conforms to the ERC20 standard.
Since the above is not an "anonymous event", the first topic will contain the signature of the event (only the type of the parameter is required for signature).
Then we look at the parameters of the event, where the from and _to addresses are indexed, and the value value is not indexed. So _from and _to addresses will be treated as topics, and _value values will be treated as data.
In Section 3.3, we mentioned that the topic can be searched, but the data cannot, so we can search the transfer logs related to the from address and _to address value in the log, but we cannot search the transfer log with the transfer amount as the _value value . Since the event has 3 subjects (the event's signature, from, _to), this logging operation will use the LOG3 opcode.
So what if we want to find the content of the data? Here you need to know the parameters of the opcode in the EVM. Although LOG3 contains 3 topics, it has 5 parameters in EVM.
If you want to read the content of the data, you can read the event data from the memory in the following way.
fishing
5.1 The use of events in phishing
So many log events were introduced earlier, so how are these related to fishing? Attackers usually use log events to pretend to be exchanges or celebrities to transfer coins to victims (the coins have no actual transaction value and are phishing tokens), and victims relax their vigilance when they see that the coins are transferred from exchanges or celebrities At this time, the attacker will lead the victim to the pool with phishing tokens. The victim will immediately authorize the transaction when he sees the high transaction value of the token. At this time, he will fall into the trap set by the attacker. It will allow the victim to authorize and steal the money in the victim's wallet.
The picture below is a phishing incident that happened before. The attacker pretended to be a Binance hot wallet and transferred phishing tokens to others.
We can find the official address through the tab on the BSC browser.
Through query, it is found that the address of Binance Hot Wallet 6 is exactly 0x8894e0a0c962cb723c1976a4421c95949be2d4e3.
Since the browser records are based on events, the value of topics1, that is, the value of sender, is 0x8894e0a0c962cb723c1976a4421c95949be2d4e3.
5.2 Recurrence
The following is the pseudocode of BEP20, taking the BNB Chain main network as an example to reproduce, the attacker creates a phishing token named "Phishing Token". .
As shown in the figure below, the value of the new Binance parameter is 0x8894E0a0c962CB723c1976a4421c95949bE2D4E3.
Then, we need to modify the code marked in red in the figure below, and change the sender address in the emit trigger event to Binance.deployedcontract
Then call the transfer function to forward the phishing token to the victim.
first level title
Summarize
first level title
references
