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.
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:
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.
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
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.
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.
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.
We are only in the planning phase for design. I wanted to check if it is possible to do this cheaply as it will influence the design of the system.
I appreciate the detailed answer, and will reference and reply here again once we begin implementing a storage solution. This is 3-12 months away though.
Thanks for the detailed steps @jtolio, we’re also interested in sending data to Storj from a smart contract.
The key for us would be to allow the wallet that executed the smart contract to be the only one able to access the stored file(s).
The smart contract would generate and upload a file based on some internal logic so it would need write access to the bucket and then generate access rights to the executor wallet based on their wallet’s private key (plus ownership of file based on smart contract).
We will implement all the logic, just need a way to authenticate a smart contract and a connected wallet.
Interesting idea, but I am not sure how would it work. If you can share any technical details, it may help.
If it’s an ethereum/evm based smart contract, you couldn’t access anything from the external world without an oracle. You couldn’t access HTTP / offchain storage
Chainlink (a well known oracle) uses an async methods: if you call the chainlink contract, you would be eventually called back with the return value (usually price data in case of chainlink).
But it requires an oracle process (or more) running somewhere which reads the events of the oracle contract and call back the original contract. Depends on the usecase, this callback can be very specific (eg. which part of the file should be provided to the contract?
As a result, I think the easiest method is running your own oracle (which would require more trust from your users as the oracle is not governed by the chain but operated by you) which is specific to your use case.
And if you have an own oracle, you have full control to authenticating as it can be done on the oracle side using any lookup based on any data on the evm original data.
(Hope I don’t misunderstood your request, please let me know if you plan to do sg. else…)