Reshaping the Smart Contract Paradigm: In-depth Analysis of AO’s Holographic State and Log-driven Contract Architecture
Abstract
Log-driven smart contracts, by decoupling contract state storage from real-time updates, allow contract states to be rebuilt on demand. This provides an asynchronous blockchain alternative to reduce state conflicts and computational burden. This article explains the innovative contract paradigm represented by AO’s holographic state.
Author: Marshal Orange
Translator: Eason Jiang
Reviewer: Jomosis
Source: Content Guild Research
According to the broad definition, EVM smart contracts are event-driven, stateful computer programs deployed on a shared distributed database. It was originally designed to ensure decentralization and security, requiring each node to execute all operations of the smart contract, and every state change of each contract needs to be recorded in real time and persistently stored in the blockchain. However, each transaction of an EVM smart contract may change the state of the blockchain. As the complexity of on-chain states increases, it becomes increasingly difficult for individual nodes to manage and synchronize these states. Especially when multiple smart contracts require frequent updates, the risks of having state lock conflicts and losing state synchronization become 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 immutable message log, this architecture not only enhances scalability but also significantly reduces the computational burden on full nodes. AO’s Holographic State is a typical representative of this new paradigm, utilizing Arweave's permanent storage and distributed computing to pioneer a more transparent and scalable way of executing smart contracts.
What is a Log-Driven Smart Contract?
It is different between Log-driven smart contracts and traditional smart contracts. Traditional smart contracts are state-driven, directly storing the latest state of the current system without keeping a historical record of all changes. In contrast, log-driven smart contracts do not store the current state of the contract in real time. Instead, they drive the dynamic calculation of the state by recording users’ interaction logs (or transaction event logs). This means that each interaction with the smart contract (such as transactions, state updates, etc.) generates an immutable log, and these logs are permanently stored in a permanent storage layer. When querying the current state is needed, any node can simply recalculate the current contract’s state through these logs.
Interaction logs: Each operation or transaction of a smart contract generates a log entry, which records the state changes of the contract, similar to event triggers in event-driven programming.
Dynamic state reconstruction: The current state of the contract is not directly stored, but is obtained by reading all relevant logs and performing calculations. The state of the smart contract can be reconstructed at any time by reading the logs.
Immutable storage layer: Logs are typically stored in immutable storage layers like Arweave, which are specifically designed for long-term storage, ensuring that all log records are permanent and immutable.
The verification mechanism of Ethereum’s scaling solution, Optimistic Rollup, is also similar to this log-driven smart contract architecture. The Rollup sub-chain generates batch transactions and submits them to the Ethereum main chain, but it does not store the complete contract states. Instead, it reconstructs and verifies the state through the "state roots" and "transaction logs." On the main chain, there are only simple transaction proofs submitted by the sub-chain, and the state is verified through a 7-day challenge window mechanism. Theoretically, anyone (now only those on the OP verification whitelist) can recalculate the state through the submitted transaction logs and raise disputes.
AO’s Historical State Change Log — Holographic State
The holographic state is a key innovation used in AO that enables boundless scalability for decentralized compute.
Instead of coming to a consensus about the state of computation itself, AO ensures logs of interactions are stored on Arweave, creating a 'hologram' of the state.
———Source: AO’s X account
In traditional architectures, each node needs to store the complete contract state, and over time, the demand for state storage continues to increase. To overcome these bottlenecks, the AO’s holographic state architecture emerged. AO’s holographic state uses a unique log-driven approach to record every state change of the contract, ensuring consistency and completeness of the state while simplifying the processing logic in complex interaction scenarios. The process state is mainly implied in the interaction logs stored on Arweave, which can be deterministically computed by any participant. This approach ensures that while the process state cannot be directly monitored, it can be independently verified and maintained consistently across the network. Meanwhile, it leverages Arweave's immutable storage capabilities to ensure scalability and reduce computational overhead, emphasizing AO's commitment to enhancing decentralized computation.
This also precisely reflects the "infinite scalability" of the holographic state: only the historical state change logs of the contract are recorded, and the state is reconstructed on demand. Nodes do not need to perform real-time calculations continuously, thus reducing the consumption of computing resources.
Log-Driven vs. State-Driven Smart Contract
Note: This chapter introduces a brand new contract scheme and presents objective facts, without any inclination towards which scheme is better or worse!
Data Log Storage Difference
Doesn't Ethereum store historical state change logs of contracts? Ethereum does indeed store historical state change logs for contracts, but its approach differs significantly from AO's holographic architecture. Ethereum’s nodes retain the current state trie (MPT, Merkle Patricia Trie) of the entire network. Whenever a new transaction is packaged into blocks and executed, the state trie is immediately updated to reflect the latest state, and each full node needs to store and maintain this state trie. The state trie records the account’s state updates (such as balance, nonce, smart contract storage changes, etc.) and writes these updates to the state root of the block. Logs are just additional information stored in transaction receipts, and they don't affect or record any part of the state trie.
Although Ethereum does record every transaction and its related event logs, these data are different from the specific state changes of contracts. Logs were originally designed for event listening and query functions. Ethereum logs usually record event data, not state data. In smart contracts, events can be generated using the emit keyword. These events only record some important information during the transaction execution process, making it easier for external applications to query. However, these events do not contain detailed changes about contract storage variables or contract state, so Ethereum’s logs cannot be used to reconstruct contract states like AO’s holographic state.
To rebuild the contract state, it is necessary to rely on replaying all historical transactions and reconstructing the state trie. Therefore, AO’s holographic state stores more information than Ethereum's log storage. So, essentially it is a strategy that sacrifices hard drive storage to reduce memory and real-time computation burden. The data storage cost of Ethereum is too high, even though EIP-4844 introduces a temporary data type called "blobs" that allows Rollup to submit more data to the Ethereum main chain at a lower cost. However, the blobs’ data is deleted about 18 days after being stored in consensus layer nodes, which does not align with the concept of permanent log storage and permanent traceability. So it is not suitable for Ethereum in the short term. Perhaps this paradigm will be adopted after Ethereum’s upgrade to sharding. For other public chains, they might inherit Arweave-like storage chains to implement cheaper and more easily scalable hard drive storage, freeing up memory and computational resources.
State Bloat and Fault Tolerance Problem
The design of Ethereum leads to the potential issue of state bloat. Unlike block data and log data, which are static and do not require frequent read and write operations once permanently stored, state data needs to be read and written many times for each new block. Since each full node needs to maintain the latest state of all contracts and accounts in real-time, as the amount of state data increases, the burden of read and write operations also becomes heavier.
Compared to Ethereum's direct storage of the complete state trie, the holographic state reduces reliance on the global state through logging. By shifting state storage from real-time memory to the hard drive, nodes do not need to update and maintain the global state in real time but can reconstruct the state on demand, breaking down state updates into discrete log records.
This design philosophy brings several significant advantages: First, the log-driven model reduces state conflicts and race conditions because all operations are executed sequentially based on logs, ensuring consistency and verifiability of state changes. Second, log-driven smart contracts naturally support state rollback, allowing the AO holographic state to achieve state reconstruction at a lower cost, providing smart contracts with higher fault tolerance and transparency.
Asynchronous Blockchain’s DeFi Dilemma
It must be stated that from a practical application perspective, especially in the DeFi sector, although asynchronous blockchains like AO have theoretical advantages in terms of scalability, maintaining Ethereum-like composability on asynchronous blockchains remains challenging. This is because it requires coordinating multiple actors to reach a consensus state at a specific point in time, which demands precise coordination of the order and dependencies of all transactions. If a transaction is delayed in processing at a certain node in the network, it may cause overall transaction logic errors or state inconsistencies. In an asynchronous environment, high-concurrency DeFi transactions are very prone to issues such as double spending or state confusion, which actually pose a threat to the security and reliability of ecosystem DeFi applications.
But log-driven smart contracts can alleviate these issues to some extent. Through a log-driven architecture, transaction execution can be processed asynchronously across multiple nodes, while changes to each transaction are recorded through the logging system. This way, even if there are differences in the execution order of transactions on different nodes, the system can ultimately reconstruct the correct state by backtracking the logs. Another major advantage is failure recovery. With log-driven systems, detailed information of each transaction step can be recorded. If a transaction fails, the system can rely on the logs to roll back to the previous correct state or perform asynchronous compensation. This mechanism is crucial for the high fault tolerance of DeFi systems, especially in environments with high concurrent transactions. The log-driven design allows some transactions to fail without affecting global stability, ensuring eventual consistency through log tracking. Additionally, in supply chain management scenarios, log-driven smart contracts can achieve full-process product traceability and verification: the status changes of each product in production, transportation, warehouse storage, and other stages are recorded through logs, clearly displaying the entire product lifecycle.
Conclusion
In today's rapidly evolving blockchain technology field, log-driven smart contract architecture provides a new perspective for addressing state management and scalability issues in traditional architectures. By decoupling state storage from the chain and recording contract state changes in immutable interaction logs, the AO holographic architecture not only reduces the consumption of computational resources but also significantly improves system scalability.
The core of log-driven smart contracts lies in ensuring dynamic calculation and reconstruction of states through a log-driven approach, thereby reducing the need for real-time maintenance of global states. This design allows nodes to reconstruct contract states on demand, avoiding storage and computational burdens caused by state bloat. Meanwhile, the contract itself executes according to the log order, effectively reducing state conflicts and race conditions, and enhancing the consistency and transparency of contract execution.
As blockchain applications become increasingly complex, log-driven smart contracts represented by AO holographic state will become an important trend in future decentralized computing, providing developers with a new approach to address composability challenges in asynchronous blockchains. By combining Arweave's permanent storage capabilities, AO’s holographic state may continue to drive the evolution of blockchain technology, helping to build a more robust and scalable decentralized application ecosystem.
🏆 Spot typos, grammatical errors, or inaccuracies in this article? Report and Earn!
Disclaimer: This article does not represent the views of PermaDAO. PermaDAO does not provide investment advice or endorse any projects. Readers should comply with their country's laws when engaging in Web3 activities.
🔗 More about PermaDAO ：Website | Twitter | Telegram | Discord | Medium | Youtube
