Instances of all entity objects are identified by their (value) hash and can be
referenced by hash only. Even the Address, the only stable identifier, is itself a hash. In the philosophy of blockchain, everything in the world is changing all the time. For entities at different times, such as Account, Contract, Storage, etc., the value of their instances is changing. As a result, their identification and Key (value hash) are also changing. The only thing that does not change is the Address, which itself is hash. The Address does not change, but its associated Account needs to be found in the latest Account trie, as it is also the case of Storage.
Account Trie and Storage Trie is like a state map. The states of the world are
connected to a verifiable, tamper-free and easy-to-find state map through the nodes of these Tries.
There are several interconnected state maps in the timestamp of Ethereum at any time, including Account Trie, StateStorage Trie, Receipt Trie, Transaction Trie and so on. The change of any node will lead to a series of changes in the corresponding nodes, and finally be reflected in the root node.
Comparing the blockchain design model with the DDD model for enterprise
applications, we can see that the two fit with each other. For this reason, the path to refactor enterprise applications to the blockchain is to adopt DDD to analyze and design enterprise application systems, and a “peer-to-peer trustworthy distributed cluster in the WAN environment” is constructed by generally adopting cryptography technology, peer-to-peer networking, event sequencing and sealing, and state snapshot storage and query in blockchains.
While theoretically feasible, do the related blockchain technologies mentioned above have the ability to refactor large-scale enterprise applications?