What is needed to implement Storj for smart contracts

I am on a team of people developing an ethereum project.

It seems that integration that allows ethereum contracts to send data and Storj tokens to be able to store its data cheaper on Storj instead of on chain has not been built yet. Years ago the Storj team said smart contract storage was one of their long term goals.

Our team is capable of coding a pull request to add the functionality to Storj.

I am looking to know the current situation, regarding what is possible and what is missing. Perhaps someone knowledgeable can write a sentence or two about each of these explaining what is needed or how difficult it will be to implement.

The goals are:

  • Ethereum contract able to have Storj space
  • Ethereum contract able to create a file on Storj
  • Ethereum contract able to read a file on Storj
  • Storj able to have publicly accessible read only files.

Hello!

Smart contract storage remains a long term goal for us, but we aren’t quite there yet. Here’s what you’d need to set up to make this work:

  1. The contract would need a Tardigrade project on a specific Satellite. It would need to be set up for payments through STORJ token, and you’d need to make sure your contract kept the wallet address paid up for the cost of the storage. Assuming a source of STORJ tokens, you could do this today.

  2. You’d need an access control primitive that ties writes to operation of the contract. Right now our macaroon based access control allows you to limit an API Key to specific time windows, specific buckets/paths, and specific types of access (read, list, delete, write, etc). The current restrictions will allow you to create an add-new-files only API key (https://pkg.go.dev/storj.io/uplink?tab=doc#Permission), but anyone who can read the smart contract will have the same access. Your contract would need a way to prove its identity, and identity proofs for API keys are on our roadmap but not yet implemented. If this is something you’d like to tackle, that’d be great! We have some plans and ideas here, so the next step would be a blueprint: https://github.com/storj/storj/tree/master/docs/blueprints

  3. Once you had a bucket with the right contents in it, read only access is absolutely doable with existing access control. Of course, once again it’s worth pointing out that data storage and transfer are both billable events, so you’d again need to make sure the payment wallet address remains funded. But reading data on Storj is doable today. To get a feel for this, try uploading some data using our Uplink and running uplink share --readonly sj://bucket/path/file and trying out the URL it returns.

  4. The last part is the actual integration with Solidity code itself - we don’t have a library ready to include in any Ethereum codebases directly, even if they’d have us, so you’ll want to make sure that there is a gateway running somewhere that Solidity could hit over standard channels (maybe some kind of REST API). I believe there are a number of other projects like this that one could use for inspiration.

Does that help? Really the open questions are #2 and #4, though #2 is close, especially with a small amount of public private key cryptography (creating an access key that is valid only if a signature from the contract is included), and #4 should be small.

8 Likes

Thinking about step 2 more - obviously the blockchain and everything on it is public, so public/private key crypto wouldn’t actually work for identity proofs here. Instead, the API Key scheme we have would need to be extended to validate that a contract had approved something, which would almost certainly require having the API key validation check for existence+confirmations of operations having completed successfully on the blockchain.

We are currently considering adding arbitrary third-party caveat checking to our API keys, so if you’re already setting up a gateway service for #4, having the gateway do this caveat checking would be a piece of cake, in which case the Storj side would be functionally complete once third-party caveat checking is merged.

2 Likes