Load Network Bundler
The LN Bundler is the fastest, cheapest and most scalable way to store EVM data onchain
⚡ Quickstart
To upload data to Load Network with the alphanet bundling service, see here in the quickstart docs for the upload SDK and example repository.
About
Load Network Bundler is a data protocol specification and library that introduces the first bundled EVM transactions format. This protocol draws inspiration from Arweave's ANS-102 specification.
Bundler as data protocol and library is still in PoC (Proof of Concept) phase - not recommended for production usage, testing purposes only.
For the JS/TS version of LN bundles, click here.
Advantages of Load Network bundled transactions
Reduces transaction overhead fees from multiple fees (
n) perntransaction to a single fee per bundle of envelopes (ntransactions)Enables third-party services to handle bundle settlement on LN (will be decentralized with LOAD1)
Maximizes the TPS capacity of LN without requiring additional protocol changes or constraints
Supports relational data grouping by combining multiple related transactions into a single bundle
Protocol Specification
Nomenclature
Bundler: Refers to the data protocol specification of the EVM bundled transactions on Load Network.
Envelope: A legacy EVM transaction that serves as the fundamental building block and composition unit of a Bundle.
Bundle: An EIP-1559 transaction that groups multiple envelopes (
n > 0), enabling efficient transaction batching and processing.Large Bundle: A transaction that carries multiple bundles.
Bundler Lib: Refers to the Bundler Rust library that facilitates composing and propagating Bundler's bundles.
1. Bundle Format
A bundle is a group of envelopes organized through the following process:
Envelopes MUST be grouped in a vector
The bundle is Borsh serialized according to the
BundleDatatypeThe resulting serialization vector is compressed using Brotli compression
The Borsh-Brotli serialized-compressed vector is added as
input(calldata) to an EIP-1559 transactionThe resulting bundle is broadcasted on Load Network with
targetset to0xbabeaddresses based on bundle version.
pub struct BundleData {
pub envelopes: Vec<TxEnvelopeWrapper>,
}
Bundles Versioning
Bundles versioning is based on the bundles target address:
2. Envelope Format
An envelope is a signed Legacy EVM transaction with the following MUSTs and restrictions.
pub struct Tag {
pub name: String,
pub value: String,
}
pub struct EnvelopeSignature {
pub y_parity: bool,
pub r: String,
pub s: String,
}
pub struct TxEnvelopeWrapper {
pub chain_id: u64,
pub nonce: u64,
pub gas_price: u128,
pub gas_limit: u64,
pub to: String,
pub value: String,
pub input: String,
pub hash: String,
pub signature: EnvelopeSignature,
pub tags: Option<Vec<Tag>>,
}Transaction Fields
nonce: MUST be 0gas_limit: MUST be 0gas_price: MUST be 0value: MUST be 0
Size Restrictions
Total Borsh-Brotli compressed envelopes (Bundle data) MUST be under 9 MB
Total Tags bytes size must be <= 2048 bytes before compression.
Signature Requirements
each envelope MUST have a valid signature
Usage Constraints
MUST be used strictly for data settling on Load Network
MUST only contain envelope's calldata, with optional
targetsetting (default fallback to ZERO address)CANNOT be used for:
tLOAD transfers
Contract interactions
Any purpose other than data settling
3. Transaction Type Choice
The selection of transaction types follows clear efficiency principles. Legacy transactions were chosen for envelopes due to their minimal size (144 bytes), making them the most space-efficient option for data storage. EIP-1559 transactions were adopted for bundles as the widely accepted standard for transaction processing.
4. Notes
Envelopes exist as signed Legacy transactions within bundles but operate under distinct processing rules - they are not individually processed by the Load Network as transactions, despite having the structure of a Legacy transaction (signed data with a Transaction type). Instead, they are bundled together and processed as a single onchain transaction (therefore the advantage of Bundler).
Multiple instances of the same envelope within a bundle are permissible and do not invalidate either the bundle or the envelopes themselves. These duplicate instances are treated as copies sharing the same timestamp when found in a single bundle. When appearing across different bundles, they are considered distinct instances with their respective bundle timestamps (valid envelopes and considered as copies of distinct timestamps).
Since envelopes are implemented as signed Legacy transactions, they are strictly reserved for data settling purposes. Their use for any other purpose is explicitly prohibited for the envelope's signer security.
Large Bundle
About
A Large Bundle is a bundle under version 0xbabe2 that exceeds the Load Network L1 and 0xbabe1 transaction size limits, introducing incredibly high size efficiency to data settling on LN. For example, with Alphanet v0.4.0 running @ 500 mgas/s, a Large Bundle has a max size of 246 GB. For the sake of DevX and simplicity of the current 0xbabe2 stack, Large Bundles in the Bundler SDK have been limited to 2GB, while on the network level, the size is 246GB.
SuperAccount
A Super Account is a set of wallets created and stored as keystore wallets locally under your chosen directory. In Bundler terminology, each wallet is called a "chunker". Chunkers optimize the DevX of uploading LB chunks to LN by splitting each chunk to a chunker (~4MB per chunker), moving from a single-wallet single-threaded design in data uploads to a multi-wallet multi-threaded design.
use bundler::utils::core::super_account::SuperAccount;
// init SuperAccount instance
let super_account = SuperAccount::new()
.keystore_path(".bundler_keystores".to_string())
.pwd("weak-password".to_string()) // keystore pwd
.funder("private-key".to_string()) // the pk that will fund the chunkers
.build();
// create chunkers
let _chunkers = super_account.create_chunkers(Some(256)).await.unwrap(); // Some(amount) of chunkers
// fund chunkers (1 tWVM each)
let _fund = super_account.fund_chunkers().await.unwrap(); // will fund each chunker by 1 tWVM
// retrieve chunkers
let loaded_chunkers = super_account.load_chunkers(None).await.unwrap(); // None to load all chunkersArchitecture design
Large Bundles are built on top of the Bundler data specification. In simple terms, a Large Bundle consists of n smaller chunks (standalone bundles) that are sequentially connected tail-to-head and then at the end the Large Bundle is a reference to all the sequentially related chunks, packing all of the chunks IDs in a single 0xbabe2 bundle and sending it to Load Network.
Large Bundle Size Calculation
Determining Number of Chunks
To store a file of size S (in MB) with a chunk size C, the number of chunks (N) is calculated as:
N = ⌊S/C⌋ + [(S mod C) > 0]
Special case: if S < C then N = 1
Maximum Theoretical Size
The bundling actor collects all hash receipts of the chunks, orders them in a list, and uploads this list as a LN L1 transaction. The size components of a Large Bundle are:
2 Brackets [ ] = 2 bytes
EVM transaction header without "0x" prefix = 64 bytes per hash
2 bytes for comma and space (one less comma at the end, so subtract 2 from total)
Size per chunk's hash = 68 bytes
Therefore: Total hashes size = 2 + (N × 68) - 2 = 68N bytes
Maximum Capacity Calculation
Maximum L1 transaction input size (
C_tx) = 4 MB = 4_194_304 bytesMaximum number of chunks (
Σn) =C_tx÷ 68 = 4_194_304 ÷ 68 = 61_680 chunksMaximum theoretical Large Bundle size (
C_max) =Σn×C_tx= 61_680 × 4 MB = 246,720 MB ≈ 246.72 GB
Load Network Bundles Limitation
500 mgas/s (current)
4MB
4MB
246 GB
1 gigagas/s (upcoming)
8MB
8MB
492 GB
Bundler Library
Import Bundler in your project
bundler = { git = "https://github.com/weaveVM/bundler", branch = "main" }0xbabe1 Bundles
Build an envelope, build a bundle
use bundler::utils::core::envelope::Envelope;
use bundler::utils::core::bundle::Bundle;
use bundler::utils::core::tags::Tag;
// Envelope
let envelope = Envelope::new()
.data(byte_vec)
.target(address)
.tags(tags)
.build()?;
// Bundle
let bundle_tx = Bundle::new()
.private_key(private_key)
.envelopes(envelopes)
.build()
.propagate()
.await?;Example: Build a bundle packed with envelopes
async fn send_bundle_without_target() -> eyre::Result<String> {
// will fail until a tLOAD funded EOA (pk) is provided
let private_key = String::from("");
let mut envelopes: Vec<Envelope> = vec![];
for _ in 0..10 {
let random_calldata: String = generate_random_calldata(128_000); // 128 KB of random calldata
let envelope_data = serde_json::to_vec(&random_calldata).unwrap();
let envelope = Envelope::new()
.data(Some(envelope_data))
.target(None)
.build()?;
envelopes.push(envelope);
}
let bundle_tx = Bundle::new()
.private_key(private_key)
.envelopes(envelopes)
.build()
.propagate()
.await?;
Ok(bundle_tx)
}Example: Send tagged envelopes
async fn send_envelope_with_tags() -> eyre::Result<String> {
// will fail until a tLOAD funded EOA (pk) is provided
let private_key = String::from("");
let mut envelopes: Vec<Envelope> = vec![];
// add your tags to a vector
let tags = vec![Tag::new(
"Content-Type".to_string(),
"text/plain".to_string(),
)];
for _ in 0..1 {
let random_calldata: String = generate_random_calldata(128_000); // 128 KB of random calldata
let envelope_data = serde_json::to_vec(&random_calldata).unwrap();
let envelope = Envelope::new()
.data(Some(envelope_data))
.target(None)
.tags(Some(tags.clone())) // add your tags
.build()
.unwrap();
envelopes.push(envelope);
}
let bundle_tx = Bundle::new()
.private_key(private_key)
.envelopes(envelopes)
.build()
.expect("REASON")
.propagate()
.await
.unwrap();
Ok(bundle_tx)
}0xbabe2 Large Bundle
Example: construct and disperse a Large Bundle single-threaded
use bundler::utils::core::large_bundle::LargeBundle;
async fn send_large_bundle_without_super_account() -> eyre::Result<String> {
let private_key = String::from("");
let content_type = "text/plain".to_string();
let data = "~UwU~".repeat(4_000_000).as_bytes().to_vec();
let large_bundle = LargeBundle::new()
.data(data)
.private_key(private_key)
.content_type(content_type)
.chunk()
.build()?
.propagate_chunks()
.await?
.finalize()
.await?;
Ok(large_bundle_hash)
}Example: construct and disperse a Large Bundle multi-threaded
async fn send_large_bundle_with_super_account() {
// will fail until a tLOAD funded EOA (pk) is provided, take care about nonce if same wallet is used as in test_send_bundle_with_target
let private_key = String::from("");
let content_type = "text/plain".to_string();
let data = "~UwU~".repeat(8_000_000).as_bytes().to_vec();
let super_account = SuperAccount::new()
.keystore_path(".bundler_keystores".to_string())
.pwd("test".to_string());
let large_bundle = LargeBundle::new()
.data(data)
.private_key(private_key)
.content_type(content_type)
.super_account(super_account)
.chunk()
.build()
.unwrap()
.super_propagate_chunks()
.await
.unwrap()
.finalize()
.await
.unwrap();
println!("{:?}", large_bundle);
}Example: Retrieve Large Bundle data
async fn retrieve_large_bundle() -> eyre::Result<Vec<u8>> {
let large_bundle = LargeBundle::retrieve_chunks_receipts(
"0xb58684c24828f8a80205345897afa7aba478c23005e128e4cda037de6b9ca6fd".to_string(),
)
.await?
.reconstruct_large_bundle()
.await?;
Ok(large_bundle)
}For more examples, check the tests in lib.rs.
HTTP API
Base endpoint: https://bundler.load.rs/
Retrieve full envelopes data of a given bundle
GET /v1/envelopes/:bundle_txidRetrieve full envelopes data of a given bundle (with from's envelope property derived from sig)
from's envelope property derived from sig)GET /v1/envelopes-full/:bundle_txidRetrieve envelopes ids of a given bundle
GET /v1/envelopes/ids/:bundle_txidN.B: All of the
/v1methods (0xbabe1) are available under/v2for0xbabe2Large Bundles.
Resolve the content of a Large Bundle (not efficient, experimental)
GET /v2/resolve/:large_bundle_txidCost Efficiency: some comparisons
SSTORE2 VS LN L1 calldata
SSTORE2 VS LN L1 Calldata VS LN Bundler 0xbabe1
LN L1 Calldata VS LN Bundler 0xbabe1
Table data sources
Source Code
Last updated