Bounty for Ledger Replication Implementation
Want to get straight to the point? Apply directly here. Otherwise - read on!
At full capacity on a 1gbps network, Solana will generate 4 petabytes of data per year. To prevent the network from centralizing around validators that have to store the full data set, this bounty proposes a way for mining nodes to provide storage capacity for pieces of data.
Archivers are specialized light clients built to download and store pieces of the ledger. They earn rewards for storing segments.
This bounty is for the implementation of the Ledger Replication behavior across Archivers and Validators. The Solana team has outlined a strategy for integration and is searching for a developer or development team fluent in Rust to assist with creating the functionality in the protocol.
The basic idea for Proof of Replication is encrypting a dataset with a public symmetric key using CBC encryption, then hashing the encrypted dataset. The main problem with the naive approach is that a dishonest storage node can stream the encryption and delete the data as it’s hashed. The simple solution is to periodically regenerate the hash based on a signed PoH value. This ensures that all the data is present during the generation of the proof and also requires validators to have the entirety of the encrypted data present for verification of every proof of every identity.
The storage epoch should be the number of slots which results in around 100GB-1TB of ledger to be generated for archivers to store. Archivers will start storing ledger when a given fork has a high probability of not being rolled back.
See this document for more detailed information on our desired implementation: https://docs.solana.com/proposals/ledger-replication-to-implement
As well as this document for a broader portrait of the replication functionality: https://docs.solana.com/cluster/ledger-replication
The following links correspond to relevant parts of the Solana codebase:
List of current issues that relate to bounty:
- No test for archiver and validator storage mining.
- Validators cannot verify mining proofs efficiently
- Accessing banks from a root slot older
- Archivers should only store rooted slots
- Validator doesn’t pick what storage proofs
- Storage program is using DEFAULT_TICKS_PER_SLOT
- Archivers don’t send fake storage proofs
- We will work with the developer/team to scope out deliverables and milestones
- Code that complies with the Contributing Guide
How to Apply
- Complete the form here
- Initial Outreach - we’ll review the applications over the next 2 weeks, and reach out to promising candidates to arrange a video call
- Shortlist - Applicants shortlisted after the initial outreach will be invited to discuss milestones, compensation, timeline etc.
- Final Selection - One successful applicant/team will be selected to proceed with the work
- Bounty to be delivered in SOL and negotiated with team