We are happy to announce the release of Caplin's Archival format, which will significantly reduce input/output (I/O) operations, deliver better latency, enable more efficient data processing.
The Problem
The management of historical data in Ethereum's beacon chain is becoming an increasingly challenging task as the chain continues to grow. With new blocks added every 12 seconds, archival nodes are required to store and manage a continuously expanding dataset. This growth has led to the following critical issues:
- Excessive I/O operations: Archival nodes must perform a high number of read and write operations to the disk, creating significant bottlenecks that affect the overall performance of the node.
- High latency: The access time for data stored on disk is significantly higher than that of data stored in RAM. As a result, historical data queries can be extremely slow, with disk access times often being orders of magnitude slower than RAM.
- Massive disk requirements: Modern archive nodes often have disk sizes exceeding 4 terabytes, which not only increases hardware costs but also makes the retrieval of historical data more complex and time-consuming.
Caplin vs. Lighthouse Tree-States
We compared Caplin's approach to archival with Lighthouse's Tree-States model.
Disk Footprint
For archival sizes up to 8.4 million slots, Caplin uses 145 GB of additional disk footprint whilst Lighthouse requires 180 GB. Both have similar sync speeds in terms of adding new slots. The difference lies in the approach: Caplin uses internal indexing and pre-loading while Lighthouse uses a delta-compression algorithm (xdelta3).
Latency
When it comes to reading historical states, caplin sits all the time below the one-second mark while lighthouse-tree states go as far as to exceed 2 seconds at times.
Validator Latency
When retrieving historical validator data, Caplin is six times faster than Lighthouse.
Validator Delta
When tracking validator delta history, Caplin is ten times faster than Lighthouse.
Recent Improvements
We also recently fixed a bug where Caplin was occasionally missing a few gossip blocks. The bug was caused by a miscalculation of the P2P message size.
Next Steps
In our next releases, we will enable the archive node via the --internalcl and --caplin.archive flags. This will enable state backfilling and reconstruction. After that we will implement full validator functionality. Lastly, we will start researching efficient blob retrieval for L2s.