Today we are introducing the load0 service, a way to push any amount of data to Load Network with web2 UX. It’s Large Bundles on steroids.
Load0 offers a cloud-like experience to upload and download data from Load Network using the Bundler’s 0xbabe2 transaction format powered with SuperAccount & cloud buckets under the hood.
How it works
The user sends data to the load0 REST API /upload endpoint -- the data is pushed to load0’s cloud bucket and returns an optimistic hash (keccak hash) which allows the users to instantly retrieve the object data from load0.
After being added to the load0 bucket, the object gets added to the orchestrator queue that uploads the optimistic cached objects to Load Network. Using Large Bundle & SuperAccount, the cloud bucket objects get sequentially uploaded to Load and therefore, permanently stored while maintaining very fast uploads and downloads.
In the current release, load0 supports any object data size lower than or equal to 2GB.
Start using load0
Load0 service can be integrated with any stack, thanks to the beauty of HTTP APIs. It’s completely client agnostic, making it flexible for whatever you’re building.
Uploading data to load0 service is straightforward. Here’s a simple example:
curl -X POST "https://load0.network/upload" \
--data-binary "@./video.mp4" \
-H "Content-Type: video/mp4" With just this single command, you can start pushing your data to the network. No complicated setup required.
To retrieve data back from load0, it can be done either via the optimistic hash, or the bundle txid when the object gets settled on Load Network, using the following REST endpoints:
- Optimistic caching:
https://load0.network/resolve/{Bundle.optimistic_hash} - From Load Network (once settled):
https://bundler.load.rs/v2/resolve/{Bundle.bundle_txid}
The Bigger Picture
load0 is a service to upload data to Load Network efficiently, with low latency and zero setup overhead – future releases of load0 will start using onchain component, such as onchain optimistic_hash -> bundle_txid mapping, making it possible for onchain apps (dApps, agents, users) to be bidirectionally aware of the content of a given load0 object.
Nonetheless, the architectural design behind load0 is groundwork for the upcoming LOAD1 AVS.
Short-window centralization
Despite using centralized components to boost up the UX and storage experience for a very short window, load0 is cloud-stack agnostic. One powerful aspect is the idea that it is centralized for only a tiny percentage of its lifespan, and the UX improvement gained from that micro trade-off makes all the difference. In the current stack, Planetscale and AWS S3 are used; however, it’s up to the user (load0 operator) to use the stack they prefer. This will come into effect when load0 gets integrated into the LOAD1 AVS engine, allowing full customization and bare metal implementations.
Load0 for temporal storage?
The short window where data lives in the cloud bucket until it gets seeded to the Load Network by the node operator can be re-engineered to offer temporal storage with cryptographic guarantees, making it possible to use Load Network for both permanent and temporary data storage.
Right now, as is in the load0 version, it can be seen as a soft-feature of temporal data storage; however, LOAD1 & LOAD2 AVS are being developed to offer robust different data storage solutions. Stay tuned for new versions of load0 that focus on temporal storage!
If Filecoin was on (steroids / acid / speed / ozempic)
While Load Network feels like Filecoin on steroids, load0 gives Load Network an extra dose, widening the gap between Filecoin and Load’s turbocharged performance (so ozempic (?) [ ^^])
The reality of uploading 1GiB to Filecoin…
For example, when you upload a 1 GiB file to Filecoin, the process begins with proposing a storage deal and funding it, which typically takes 1 to 2 minutes.
Once the deal is accepted, your node uploads the data to the storage provider, usually taking around 1 to 5 minutes depending on your network speed. After the data is received, the provider verifies it and publishes the deal on-chain, which takes about 30 to 60 seconds.
The final and most time-consuming step is sector sealing, where the storage provider seals your data into a 32 GiB sector. This sealing process generally takes between 1.5 to 3 hours, depending on the provider’s hardware. Your file becomes retrievable only after this sealing is complete, because sealed storage is what’s verifiably committed on-chain.
Altogether, the total time from upload to retrievability is around 2 to 3 hours under typical conditions. Some storage offers unsealed data retrievability, however it’s far from being near-instantaneous due to data upload to the network & finality latency.
vs. Uploading 1GiB on load0
Uploading the same data size of 1GB on Load Network Alphanet v4 (~62 MBps, 1s slot finality) using Large Bundles data protocols would take the user ~20-60sec on top of the user’s data upload network speed (assuming same case as in Filecoin case) to upload the data and have it retrievable from the EVM network– its worth noting that we are working on a new Load Network release that can 8x the data throughput 👀
Now comparing that to load0, the by-default optimistic caching of load0 (like unsealed on Filecoin) offers instant data retrievability after it being uploaded to the load0 storage provider, with guarantees for the data to get seeded on Load Network, which gives load0 even faster data retrievability and lower latency.
It’s worth noting that once data is uploaded and finalized on Load Network, it’s retrievable also from Arweave from more than 270 data gateways – this is possible thanks to the Load Network ExEx interoperability architecture with Arweave!
(source)
Load Network Cloud Platform
Yes this is an announcement of announcement, or technically, a tease – Load Network Cloud Platform is coming very soon!
You’ve heard of Google Cloud Platform, well, Loud Cloud will be the onchain data center’s cloud. Load Cloud offers an easy way to access the real power of Load Network, with web2-like UX while everything ends up onchain.
The Load Cloud will be released with an IPFS pinning service, Dropbox alternative, and an AWS S3 Object-Bucket service – all of these services interface with Load Network storage.
Imagine, with a single API key, you can interface with Load Network storage efficiently, via different data entries pipelines, the most common ways to store data in the web3 industry – one upload spawns a permanently pinned IPFS hash and Load bundle ID, making the data compatible with wherever you plan on integrating it. This will be all possible via a single API key, robust dev tooling, and permanent storage in the background.