Implementing a Polkadot-native system parachain for data storage: Phase 2/3

 

Hey everyone, I wanna start by saying thank you to the community for the overwhelming support of OpenGov referendum 494. Since then we have been heads down working on the storage network and have now completed phase 1 and some extra parts.

If you weren't aware we have been posting weekly updates on the forum 

Check out the book https://eigerco.github.io/polka-storage-book/ It contains lots of technical details and some nice instructions on how to test it. Work continues uninterrupted on phase 2 tasks.

During this time, in addition to the work on the storage network, there's two more projects we have been working on that contribute to Polkadot:

1. We integrated Move to Substrate. Allowing builders to integrate the Move VM and execute Move smart contracts. Anyone can now create a Move parachain on Polkadot. https://x.com/Polkadot/status/1816109501394637034

2. We have a full team working on Strawberry our client implementation of JAM and are very close to the first milestone. More updates on that soon.

 

Links:

• Full proposal https://docs.google.com/document/d/16SZXvXyBRd-oEMIbgAid_vaxTuKzDlxuNc9CwSq3Lq0/edit
• JAM DA integration https://docs.google.com/document/d/1L1jlMI9-KOfxMYUMQVeq0tPNtz1fitxTXlg6gKwjXnM/edit?usp=sharing

• Initial research pre-implementation https://github.com/eigerco/polkadot-native-storage/blob/main/doc/report/polkadot-native-storage-v1.0.0.pdf
• Forum discussion https://forum.polkadot.network/t/polkadot-native-storage/4551
• Forum development updates https://forum.polkadot.network/t/polkadot-native-storage-updates/7021
• OpenGov Phase 1/3 https://polkadot.polkassembly.io/referenda/494

 

Edit: Adding some notes on the value proposition and our integration with JAM as we had looked at this months ago but realized that we hadn't shared it here.

Why PolkaStorage, adding native storage offering to Polkadot:

• Uses DOT exclusively as the fee token where anyone in the eco thru XCM can store and retrieve data. No new tokens to take away utility from DOT.
• Inspired by Gavins presentation about the Ubiquitous Supercomputer, storage offering is critical: cores for execution, storage for data. Now with JAM, the same storage offering is needed.
• Reliance on other networks is a weakness. Other solutions use their own token and are just incentivization models on top of IPFS. This would be exclusive native storage for the DOT ecosystem. Bringing in storage providers to the ecosystem, service fees paid in DOT.
• Although we use some Filecoin libraries to speed up development and not waste developer time reinventing the wheel, this custom implementation allows us to tailor the solution to what is needed in DOT, we are adapting it around JAM (We have a separate team working on Strawberry our client implementation) and bring in other use cases like data availability on top of this storage. (We built the Celestia rust stack, read about our work and experience in DA).

 

Integrating Eiger’s Polka Storage with JAM's Preimage Lookup System and Data Availability

 

Providing access to larger data capacity that doesn't fit in account state and being the underlying storage layer for resupply of unrequested data that needs to be provided to validators on request.

• Fully synchronous execution: ETH L1. All app data is stored on-chain and easily accessible. Not scalable.
• Incoherent system: App data in different rollups, scalable but not composable, rollup model.
• Best of both worlds: JAM with DA. Where apps can access this data and only keep crucial parts on the JAM state. We are building the underlying storage layer for that data.

Read our notes on this topic at https://docs.google.com/document/d/1L1jlMI9-KOfxMYUMQVeq0tPNtz1fitxTXlg6gKwjXnM/edit?usp=sharing