关于OpenZeppelin Ownable合约transferOwnership事件触发顺序的技术问询

Great question—this is a really important detail to clarify when working with Solidity and the EVM, so let’s break it down step by step.

First, let’s confirm a core EVM behavior: the execution of a single smart contract function is fully atomic. That means every operation in the function will either complete successfully together, or if any part fails (e.g., a require check fails, a revert is triggered), the entire function’s state changes are rolled back, and no events from that execution are ever persisted to the blockchain.

Now, let’s look at the transferOwnership code you shared:

function transferOwnership(address newOwner) public onlyOwner {
    require(newOwner != address(0));
    OwnershipTransferred(owner, newOwner);
    owner = newOwner;
}

You’re right that the OwnershipTransferred event is emitted before the owner state variable is updated. But here’s why this is safe and doesn’t lead to the "out-of-sync" scenario you’re worried about:

• While the event is emitted at the point the line executes, the event log is only written to the blockchain if the entire function completes without errors. If anything went wrong after emitting the event (though in this case, there’s no code that can fail after the require), the entire transaction would revert, and the event would never be visible to external listeners.
• When external services or dApps receive the OwnershipTransferred event, it’s always tied to a successfully mined block. By the time the event is propagated to listeners, the contract’s owner state has already been updated to newOwner. There’s no window where a listener can see the event but read the old owner value—because the event only exists if the state update completed successfully.

Wait, but why does OpenZeppelin order it this way instead of updating the state first? It’s actually a common pattern in Solidity: emitting events with the old and new values gives listeners complete context about the state change in one log entry. Since the event includes both owner (the old value) and newOwner, listeners don’t even need to query the contract state to know what the change was—they can get all necessary data directly from the event.

To put it simply: The EVM’s atomicity guarantees that either both the event emission and state update happen (and are visible together), or neither does. There’s no scenario where a listener can react to an event that didn’t result in the corresponding state change. This implementation is completely safe.

内容的提问来源于stack exchange，提问作者Shammah