Last night, I stared at the distributed system architecture diagram on the screen for a long time, pondering over the 'impossible triangle' that has troubled Web3 infrastructure for many years. I couldn't sleep no matter how many times I turned it over in my mind. In today's on-chain ecosystem, the computation layer, which consists of L1 and L2, is indeed very competitive, with TPS metrics boasting higher and higher numbers. However, the storage layer seems to remain a huge pain point, always like a crucial piece missing from a puzzle. To clarify this chaotic thought process, I simply went through my research notes on the white paper of @Walrus 🦭/acc and the fragmented ideas in my mind over the past couple of days, not to write any popular science article, but purely to see if I could completely run this logical loop in my head and determine whether this thing could indeed be the variable that breaks the deadlock.
In the past, when writing smart contracts, the most frustrating and powerless thing for me was that state storage was too expensive, and those large file blob data had no place to go. This sense of disconnection was very strong. Previous solutions were either using IPFS, but that was essentially just an addressing protocol. Whether the data is lost or how long it can be stored depends entirely on the nodes' mood. Unless you use centralized services like Pinata, which goes against the initial intent of decentralization; or you could use Arweave, which primarily promotes permanent storage, but that endowment-based cost model is a bit heavy for many non-financial data that do not require permanent preservation or frequent updates. As for Filecoin, its storage market mechanism is complete, but in terms of retrieval efficiency and instantaneous interoperability with smart contracts, it always feels like there is a thick veil between it and current instant applications. Recently, I have deeply explored #Walrus's technical details, and my feeling is that its entry point is exceptionally clever. It does not attempt to reinvent a cumbersome universal storage public chain but instead cleverly leverages the characteristics of Sui and its Move language to create a remarkably elegant decoupling between the 'coordinating layer' and the 'storage layer.' This kind of architectural simplification is done at a very high level.
When I read the technical documentation, the most striking part that made me stop and ponder, even feel amazed, was their mention of the "Red Stuff" algorithm. The name sounds casual, like a joke, but the underlying mathematical logic is hardcore. Traditional storage thinking is extremely linear, simply 'multiple copy replication.' I have 1GB of data, and for safety, I store 3 or even 5 copies—it's simple, crude, but extremely heavy and expensive. The two-dimensional erasure coding (2D Erasure Coding) used by Walrus represents a completely different dimension of thought. It no longer focuses on storing copies but instead shatters data into pieces and generates redundant shards. It's like I smash a beautiful vase into 100 pieces, but I only need to pick up any 30 pieces and, with some mathematical magic, I can restore the entire vase 100%. The key here is achieving an extreme balance between fault tolerance and storage efficiency. I imagined this process in my mind: when a storage node goes offline or even when a large area of nodes fails simultaneously, the network does not need to panic and look for 'backups' because the remaining nodes possess those seemingly meaningless fragments. As long as they reach the threshold, they can instantly reconstruct the original data. This means Walrus does not require nodes to have extremely high online rates or overly complex spatio-temporal proof mechanisms like some heavy protocols. It places reliability on probability theory and coding theory rather than on the hardware stability of a single node. For someone like me, who has a code cleanliness obsession, this design is truly appealing. It allows for localized 'unreliability' while ensuring the overall system's 'extreme reliability.'
Before, I couldn't understand why Walrus had to be deeply tied to Sui. Looking back now, it is an extremely clever 'leveraging strength against strength.' The most challenging aspect of storage networks has never been storing data itself but managing state: who stored what, how long, how much they paid, and who has the rights. If the management of this metadata also requires a consensus mechanism, the system's complexity would rise exponentially. Walrus's approach is very pragmatic: it leaves the dirty work of storing blobs to the storage node network while handing over the meticulous tasks of metadata management, payment, and permission control to Sui. I am imagining the workflow of developing a dApp in the future: a user uploads a 50MB video on the frontend, the video is sliced and encoded, thrown into Walrus's storage node network, and Walrus returns a Blob ID. The user's smart contract only needs to record this ID on Sui, rather than the video itself. All payment settlements and storage cycle verifications are completed on Sui's lightning-fast consensus layer. This is akin to using AWS S3 to store files and Lambda to handle logic in the Web2 world, but here it is entirely decentralized. Because of Sui's parallel execution characteristics, this means Walrus's throughput theoretically will not be bottlenecked by a 'coordinating layer.' This architectural design is clearly prepared for large-scale applications, not just for storing a few small images.
Thinking of this, I suddenly realized that Walrus might have a subtle impact on the current Layer 2 market. Today's rollups are struggling with the DA layer, that is, the data availability layer. The Ethereum mainnet is too expensive, and Celestia is a good choice, but the emergence of Walrus provides a new dimension. If Walrus's storage costs are low enough and retrieval speeds are fast enough, it can fully serve as the historical data layer for high-throughput blockchains, especially for game chains or social graph chains that require storing a large number of state snapshots. The all-chain game architecture I conceived previously faced challenges in terms of where to place map data and player-generated rich media content. It was too expensive to store on-chain and unsafe on servers. Now it seems that directly turning these assets into blobs on Walrus and encapsulating the Blob ID into the NFT's Move object is a natural fit. The object model of Move and the blob storage of Walrus are truly a match made in heaven. You can think of a Blob as the 'projection' of a Move object in the physical world. This uniformity in programming models is hard to compare with other heterogeneous storage solutions.
Of course, I remain vigilant while thinking about these things, as they definitely carry risks. Any system based on erasure coding faces the issue of 'reconstruction costs.' If the loss rate of network nodes is too high, the system needs to consume a large amount of bandwidth to reconstruct the lost shards, which is a huge test for network bandwidth. Moreover, the incentive model is always the key to success or failure. How can we ensure that nodes are motivated to store 'cold data' that hasn't been accessed for a long time? Although the white paper mentions storage proofs and incentive mechanisms, the actual environment's game theory is far more complex than mathematical models. Human nature is always greedy, and nodes always seek profit. Designing a mechanism that compels nodes to benefit others while acting in their own self-interest is a sociological issue rather than a purely technical one. However, it must be said that Walrus exhibits a long-lost 'engineering aesthetic.' It does not pile up complex concepts but rather uses solid coding theory to solve the most challenging scalability issues.
If we do not limit ourselves to 'storing files,' the imaginative space of Walrus is incredibly vast. For example, for the decentralized AI model weight storage, current LLMs can easily reach dozens of G, making it impossible to place on-chain. However, if model weights are placed on Walrus and version control and access authorization are handled via Sui, could this achieve true decentralized AI inference? Another example is censorship-resistant static website hosting. While this is a common topic, combining it with Sui's domain service could provide a smoother experience than IPFS combined with ENS. Additionally, there is personal data vaults where users can throw encrypted private data onto Walrus, only disclosing zero-knowledge proofs on-chain. Writing this, I think I have sorted out the logic: Walrus is not just creating a better Dropbox; it is building the massive data foundation for Web3. On this foundation, those previously shelved crazy ideas due to 'high storage costs'—such as all-chain video platforms, all-chain AAA games, and decentralized big data analysis—now have the potential to be realized. This feeling is reminiscent of when I first saw the TCP/IP protocol splitting and reassembling data packets. Although you cannot see it, you know it is this foundation that supports the prosperity above.
In the past few days, I need to find time to run their Devnet. Just reading the white paper is not enough; I must practically test the read and write latency and the interaction experience of Move contracts because code does not lie. If Walrus can truly deliver on the performance metrics outlined in the white paper, then this could be a trump card for the Sui ecosystem and even the entire Web3 storage track. This is not just about storage; it is also about how to evolve blockchains from 'ledgers' to 'computers.' The path of this technological evolution, the more I think about it, only this 'subtracting' approach seems to be the right answer—returning storage to storage and computation to computation, stitching them together through efficient coding and consensus. This has been my entire thought process last night. Although I have not yet seen large-scale deployed applications, as a developer, this kind of fundamental change is often more exciting than the prosperity at the application layer.
