I’m Serhii from the Eiger team. As a follow-up to our efforts in building native storage, presented in this thread, we would like to provide weekly updates in this thread regarding the progress we are making.
Here is the current status from the scope of our proposal as of March 25, 2024:
Milestone: 1. Research.
Task: 1. Research lotus.
Subtasks:
Analysis of lotus.
Prepared an overview of Filecoin specification and Lotus implementation analysis.
Prepared parachain implementation guidelines with project structure definition, required pallets for implementation. Also, testing setup and instructions have been provided.
Define JSON-RPC API.
WIP: Defined and summarized the RPC API provided by Lotus with partial cross-references to required methods for implementation in our parachain solution.
WIP: Partially defined RPC methods to be exposed and described methods which are already exposed by Substrate.
Task: 2. Research lotus-miner.
Subtasks:
Analysis of lotus-miner.
WIP: Conducted lotus-miner analysis and prepared an overview of the component.
Define JSON-RPC API.
WIP: Defined and summarized the RPC API provided by Lotus, with cross-references to the required methods for implementation in our parachain solution.
Analyze the lotus-worker.
WIP: Conducting a lotus-worker analysis to decide whether we should implement it and how.
WIP: Overview of RPC method definitions.
The next update reports will be provided on a weekly basis and will only include and describe progress made since the previous report.
We should observe that storage depends upon threat model, which blockchain storage proposals typically either omit entirely or else over engeneering, at extreme costs.
“Availability” systems incur real costs, with the one used by polkadot being optimal for polkadot’s byzantine threat model. Celesia costs more because they over sample. Filecoin & ETH cost more because they prove encoding roots using zk proofs.
Afaik nobody has proposed a storage scheme with a formalized threat model that provides less assurances than polakdot’s availability, but still provides useful assurances, except maybe certificate transperency. I suspect the answer lies with rateless erasure codes, and assume an honest encoder, but the availabiity work using rateless erasure codes winds up much worse than even celestia.
I always phrase this question as: How could rateless erasure codes improve bittorrent?
Anyways…
I relaize this project ports filecoin, which likely serves some purposes, but it’ll be interesting to see how much more this costs than our own blockspace.
Thanks for sharing your thoughts on the challenges and costs involved in blockchain storage. We’re really excited about where we’re heading with our project.
When planning the project, we took inspiration from Lotus, adopting their well-tested decentralized storage protocols and algorithms, but we’re tweaking them to better serve Polkadot’s unique needs. This ensures our solution isn’t just a copy, but a tailored fit for our ecosystem.
On pricing, we’re looking to Filecoin’s model for inspiration. We plan to let market forces determine our storage prices. That way we foster a competitive atmosphere that promotes efficiency and fairness, encouraging providers to offer the best, most cost-effective services possible, meeting the diverse needs of our community.
The next update reports will be provided on a weekly basis and will only include and describe progress made since the previous report.