It makes decentralized storage feel unusable.
The reason why decentralized storage is difficult is not normally explained in a whitepaper the first time. When you attempt to ship one of its products, that is when. One of the users uploads a file via a browser. Their connection is average. Their phone is mid-range. And the path which seemed beautiful on paper becomes thousands of calls within the network, time-outs and repetitions. At that point, decentralized storage ceases to be a story and is a liability to engineering. Walrus is notable as it is a rather unusual admission of this failure mode and is designing straight to that end.
The main problem is that there are way too many requests that may be necessary to write a blob to a decentralized storage network. In the official Walrus TypeScript SDK documentation, it is explicitly stated that reading and writing blobs involves many requests, and on the scale of ~2200 requests to write a blob and 335 requests to read it when communication is made directly to storage nodes. It is not a fussy footnote, that is the difference between something that works in a backend service and something that works in a consumer application. Browser uploads are not failing because the concept is flawed, but because the network path is too fat in real-life conditions.
It is not that Walrus is not responding to the fact that the problem exists. It is to bring in the Upload Relay as a realistic intermediary. The relay, according to the Walrus team, is a lightweight companion service, which makes uploads quicker and more stable and limits the load on client applications. The operator documentation also is more straightforward: browser uploads are challenging in reality since there must be a client process that can directly interact with storage nodes, but one that must open a vast number of connections to upload all the slivers to all the shards. Between the two, there is the relay that does the heavy distribution work. This is not a creeping reinstatement of centralization, but a recognition that the last mile does matter, and you must have to design around it.
What makes this more infrastructure-like than most crypto content is the economic detail. Paid services Public relays may be operated as paid services. The relay provides an endpoint of tip configuration, and has tip models which are either constant or linear with the size of unencoded data, expressly to enable relay operators to incur costs and gain profit. It is an adult design choice: we can have decentralized networks when operators are able to operate sustainable businesses. Walrus is not only fixing a technical bottleneck, it is establishing a functional avenue that will work at scale without favoritism.
The tradeoff is clear and must be outspoken. The introduction of a relay layer introduces an additional operational element, which may be required to operate, have trust or be outsourced by the teams. Although the protocol might have the capability to identify some malicious behavior, still a relay is a part of your application reliability chain. What Walrus is betting is that it is a net improvement: they are taking complexity out of all of their end users and moving it into a structured layer that can be professionally run. To the builders, that is a tolerable trade since it only matters whether the product will operate in the real scenarios. Should Walrus win, it will not be since it is the purest of the storage systems in terms of its ideology. It will be because it is the one that people are able to ship with.
