Skip to main content
rq-go is a Go library that wraps the RaptorQ Forward Error Correction (FEC) algorithm. Lumera’s Cascade service uses it to split files into redundant, independently-retrievable symbols before distributing them across the SuperNode P2P network. Because RaptorQ is an erasure code, the original file can be reconstructed even if a subset of the symbols is lost or unavailable. This makes Cascade storage resilient to node churn and partial network failures. Most developers interact with Cascade through the SuperNode gRPC API or the lumerad CLI rather than calling rq-go directly. This page documents the library for developers who need low-level encoding control or who are building tooling on top of Cascade’s storage layer.

Platform support

rq-go ships pre-built static libraries for the following targets. No external shared libraries or C toolchains are required at runtime. The final binary is fully self-contained.

Installation

Add rq-go to your Go module.
Then import it in your source files.

Quick start

The example below shows the complete encode and decode round trip using the library’s default configuration.
raptorq_example.go
Always call processor.Free() (or defer it immediately after creation) to release the memory held by the underlying C library. Forgetting to do so will cause a memory leak, especially in long-running services.

Custom configuration

Use NewRaptorQProcessor when you need to tune symbol size, redundancy, memory limits, or concurrency.

Configuration parameters


API reference

NewDefaultRaptorQProcessor() (*RaptorQProcessor, error)

Creates a processor with default settings (see table above). Use this for most applications.

NewRaptorQProcessor(symbolSize, redundancyFactor, maxMemoryMB, concurrencyLimit uint32) (*RaptorQProcessor, error)

Creates a processor with explicit parameters.

processor.GetRecommendedBlockSize(fileSize uint64) uint64

Returns the recommended block size (in bytes) for the given file, taking into account the processor’s memory limit and efficiency heuristics. Using this value avoids excessive memory consumption for large files.

processor.EncodeFile(inputPath, outputDir string, blockSize uint64) (*EncodeResult, error)

Encodes the file at inputPath into RaptorQ symbols written to outputDir. The layout metadata file (_raptorq_layout.json) is also written to outputDir. Returns an EncodeResult with two fields.
  • TotalSymbolsCount is the total number of symbols generated across all blocks.
  • LayoutFilePath is the absolute path to the generated layout file.

processor.DecodeSymbols(symbolsDir, outputPath, layoutPath string) error

Reconstructs the original file from the symbols in symbolsDir, guided by the layout file at layoutPath, and writes the output to outputPath. Reconstruction succeeds even when some symbols are missing, as long as enough symbols survive for each block.

processor.CreateMetadata(inputPath, layoutPath string, blockSize uint64) (*EncodeResult, error)

Generates the layout file without writing any symbol files. Use this to plan storage requirements or generate symbol identifiers ahead of time.

processor.Free()

Releases all memory held by the processor. Must be called when the processor is no longer needed.

Block processing and memory management

rq-go processes files in blocks to bound peak memory usage.
1

Split

The file is divided into blocks of at most blockSize bytes.
2

Encode each block independently

Each block is encoded separately. Only one block’s working memory is live at a time, so peak usage is proportional to blockSize rather than to the total file size.
3

Write symbols

Each block produces a set of source symbols plus repair symbols (determined by redundancyFactor). Symbols are written to the output directory as individual files named by their content hash.
4

Write layout

A single _raptorq_layout.json file records the encoder parameters, block boundaries, symbol identifiers, and block hashes needed for decoding.
Use GetRecommendedBlockSize to let the library select a block size that balances memory efficiency against encoding overhead.

Metadata file format

The _raptorq_layout.json file produced by EncodeFile is required for decoding. Keep it alongside the symbols (or store it separately and pass its path to DecodeSymbols).
If the file fits within a single block, the layout contains exactly one entry with block_id: 0. The decoder handles single-block and multi-block layouts identically.

Usage in Lumera

rq-go is used internally by the Lumera SuperNode’s Cascade service. When you call CascadeService/Register, the SuperNode encodes your file with this library, distributes the resulting symbols across the P2P network, and records the symbol IDs on-chain. You do not need to use rq-go directly unless you are building custom tooling or integrating at a lower level than the gRPC API.
For most integration work, prefer the SuperNode gRPC API or the lumerad CLI over calling rq-go directly. The SuperNode handles encoding parameters, P2P distribution, and on-chain finalization for you.