According to a broad definition, an EVM smart contract is an event-driven, stateful computer program deployed on a shared distributed database. This design was originally intended to ensure decentralization and security. Each node must execute all operations of the smart contract, and the state changes of each contract need to be recorded in real time and stored persistently in the blockchain. Each transaction of the EVM smart contract may change the state of the blockchain. However, as the complexity of the on-chain state increases, it becomes increasingly difficult for each node to manage and synchronize these states, especially when multiple smart contracts need to be updated frequently, the risks of state lock conflict and state synchronization are more prominent.
In this context, log-driven smart contracts have become a new paradigm that breaks through the limitations of traditional architectures. By decoupling contract state storage from the chain and embedding it in an unalterable message log, this architecture not only improves scalability, but also greatly reduces the burden of full-node computing. AO Holostate is a typical representative of this new paradigm. It uses Arweave's permanent storage and distributed computing to create a more transparent and scalable way to execute smart contracts.
What are log-driven smart contracts?
Log-driven smart contracts are different from traditional smart contracts. Traditional smart contracts are state-driven and directly store the latest state of the current system without keeping a historical record of all changes. Log-driven smart contracts do not store the current state of the contract in real time, but drive the dynamic calculation of the state by recording the user's interaction log (or transaction event log). This means that every interaction of the smart contract (such as transactions, state updates, etc.) will generate an unalterable log, and these logs will be permanently stored in a permanent storage layer. When the current state needs to be queried, any node only needs to recalculate the current contract state through these logs.
- Interaction log : Each smart contract operation or transaction generates a log, which records the state changes of the contract, similar to the event triggering in event-driven programming.
- Dynamic state reconstruction : The current state of the contract is not stored directly, but is obtained by reading all relevant logs and calculating them. The state of the smart contract can be reconstructed at any time by reading the logs.
- Immutable storage layer : Logs are typically stored in Arweave, an immutable storage layer specifically designed for long-term storage, ensuring that all log records are permanent and cannot be tampered with.
The verification mechanism of Ethereum's scaling solution Optimistic Rollup is somewhat similar to this log-driven smart contract architecture. The Rollup subchain generates a transaction batch and submits it to the Ethereum main chain, but it does not store the complete contract state. Instead, it drives the reconstruction and verification of the state through the "state root" and "transaction log". The main chain only has the simple transaction proof submitted by the subchain, and then verifies the state through the 7-day challenge resolution mechanism. Anyone (only in theory, currently only the OP verification whitelist can) can recalculate the state through the submitted transaction log and raise disputes.
AO Historical State Change Log - Holographic State
Holographic state is a key innovation of AO that provides infinite scalability for decentralized computing. Instead of reaching consensus on the state of the computation itself, AO ensures that the interaction log is stored on Arweave, creating a "hologram" of the state.
In traditional architectures, each node needs to store the complete state of the contract, and the demand for state storage increases over time. To overcome these bottlenecks, the AO holographic architecture came into being: the AO holographic state records every state change of the contract in a unique log-driven way, ensuring the consistency and integrity of the state, while simplifying the processing logic in complex interaction scenarios. The state of the process is mainly implicit in the interaction log stored on Arweave, and any participant can calculate it deterministically. This approach ensures that although the state of the process cannot be directly monitored, it can be independently verified and remains consistent across the entire network. At the same time, Arweave's immutable storage capabilities are used to ensure scalability and reduce computing overhead, emphasizing AO's commitment to enhancing decentralized computing.
This also reflects the "infinite scalability" of the holographic state: only the historical state change log of the contract is recorded, and the state is rebuilt on demand . Nodes do not need to perform real-time calculations continuously, thereby reducing the consumption of computing resources.
Log-Driven vs. State-Driven
Note: This chapter introduces a new contract plan and explains the objective facts. There is no tendency to suggest that one plan is better or worse!
Data log storage difference
Doesn’t Ethereum store the historical state change log of the contract? Ethereum does store the historical state change log of the contract, but its processing method is significantly different from the AO holographic architecture.
Ethereum nodes retain the current state tree (MPT tree, Merkle Patricia Tree) of the entire network. Whenever a new transaction is packaged into a block and executed, the state tree will be immediately updated to reflect the latest state. Each full node needs to store and maintain this state tree. The state tree records the state updates of the account (such as balance, nonce, storage changes of smart contracts, etc.) and writes these updates to the state root of the block. The log is just additional information stored in the transaction receipt, and it does not affect or record any part of the state tree.
While Ethereum does record every transaction and related event logs, this data is different from the specific state changes of the contract. The log was originally designed for event monitoring and query functions . Ethereum's logs usually record event data , not state data . Events can be generated in smart contracts through the emit keyword, and these events only record some important information during the transaction execution process, which is convenient for external applications to query. These events do not contain detailed changes in contract storage variables or contract status, so Ethereum's logs cannot be used to reconstruct contract status like AO holographic state.
In order to rebuild the contract state, it is necessary to rely on the replay of all historical transactions and the reconstruction of the state tree. Therefore, the AO holographic state will store more information than Ethereum's log, so it is essentially a strategy to reduce memory and real-time computing burdens by sacrificing hard disk storage. Ethereum's data storage cost is too high, even if EIP-4844 introduces the "blobs" temporary data type, allowing Rollup to submit more data to the Ethereum main chain at a lower cost. However, blobs data is deleted after being stored in the consensus layer node for about 18 days , which does not conform to the concept of permanent storage and permanent traceability of logs, so it is not suitable for Ethereum in the short term. Perhaps this paradigm will be adopted after upgrading sharding, and for other public chains, it may be possible to inherit Arweave, a storage chain, to achieve cheaper and easier to expand hard disk storage, and memory and computing resources are also released.
State bloat and fault tolerance issues
Ethereum’s design leads to the hidden danger of state expansion. Since each full node needs to maintain the latest status of all contracts and accounts in real time, state data is not like block data. Log data is static and does not need to be read and written frequently after being permanently saved; but state data needs to be read and written many times for each additional block. As the amount of state data increases, the burden of reading and writing will become heavier.
Compared to Ethereum directly storing the complete state tree, the holographic state reduces the reliance on the global state through logs. By transferring the state storage from real-time memory to the hard disk, nodes do not need to update and maintain the global state in real time, but can rebuild the state on demand and decompose the state update into discrete log records .
This design concept brings several significant advantages: First, the log-driven model reduces the occurrence of state conflicts and race conditions, because all operations are executed sequentially based on logs , which can ensure the consistency and verifiability of state changes. Second, log-driven smart contracts naturally support state backtracking, and AO holographic state can achieve state reconstruction with lower overhead, making smart contracts more fault-tolerant and transparent.
The Asynchronous Blockchain DeFi Conundrum
It has to be said that from the perspective of practical applications, especially in the field of DeFi, although asynchronous blockchains such as AO have theoretical advantages in scalability, it is still challenging to maintain the composability of Ethereum on asynchronous blockchains, because multiple actors need to be coordinated to reach a consistent state at a specific time point, which requires precise coordination of the order and dependencies of all transactions. If a transaction is delayed on a node in the network, it may cause errors in the overall transaction logic or inconsistent states. Highly concurrent DeFi transactions in an asynchronous environment are very prone to double spending or state confusion, which actually poses a threat to the security and reliability of ecological DeFi applications.
Log-driven smart contracts can alleviate these problems to a certain extent. Through the log-driven architecture, the execution of transactions can be processed asynchronously on multiple nodes, and the changes of each transaction can be recorded through the log system. In this way, even if the execution order of transactions is different on different nodes, the system can eventually reconstruct the correct state by backtracking the log. Another major advantage is failure recovery. Through log drive, the system can record the detailed information of each step of the transaction. If a transaction fails, it can rely on the log to roll back to the previous correct state or perform asynchronous compensation. This mechanism is very important for the high fault tolerance of the DeFi system, especially in the environment of high concurrent transactions. The log-driven design allows some transactions to not affect the global stability after failure, but to ensure the final consistency through log tracking. In addition, in the supply chain management scenario, the whole process of commodity traceability and verification can be achieved through log-driven smart contracts: the state changes of each commodity in each link such as production, transportation, and warehousing are recorded through logs, which can clearly show the entire life cycle of the product.
Conclusion
In today's rapidly developing blockchain technology field, the log-driven smart contract architecture provides a new perspective for solving state management and scalability problems in traditional architectures. By decoupling state storage from the chain and recording contract state changes in an unalterable interaction log, the AO holographic architecture not only reduces the consumption of computing resources, but also greatly improves the scalability of the system.
The core of log-driven smart contracts is that they ensure dynamic calculation and reconstruction of states through log-driven methods, thereby reducing the need for real-time maintenance of global states. This design allows nodes to rebuild contract states on demand, avoiding storage and computing burdens caused by state expansion. At the same time, the contract itself will be executed according to the order of logs, which effectively reduces state conflicts and race conditions, and enhances the consistency and transparency of contract execution.
As blockchain applications become increasingly complex, log-driven smart contracts will become an important trend in decentralized computing in the future, providing developers with a new way to solve composability challenges in asynchronous blockchains.
