Was the option of storing encrypted state on IPFS (and once a contract starts running, require it keep getting run by the same node to obviate the reencryption problem) ever considered? obv eventually you need your own networking, but this kills the problem for minimum viable?
Yes, but networking outside of a blockchain is very much a problem.
Each node must run each computation and reach the same result (consensus). Do all of them write to IPFS? What if some of the nodes are having networking issues? This also affects consensus. Plus reading & writing to IPFS will be much slower than to local HD.
Have all nodes that are verifying compare their results to IPFS, and have encrypted state associated with points in a computation (relative memory locations in wasm should work) to provide staging points for verification if you want to do it that way? Alternatively have defined points to save out to IPFS and have them be relatively infrequent.
Is reading/writing to IPFS worse than HD + p2p pullin?
This is probably doable but I’m afraid networking issues with IPFS will just complicate things. Why do you think we shouldn’t use the storage given to us for free by tendermint?
Also we want to keep things as simple as possible. If nodes would also be required to run an IPFS node to improve performance and network errors than it’s more complex and surely still slower then using the blocks as storage
If you’re using the tendermint storage than that should work too trivially, i’m just not sure why you needed to rewrite enigmap2p then given that every node is using the same key – why can’t state be stored as easily as inputs in some massive global state-struct mapping contracts to param-spaces?
We are not rewriting enigma-p2p, we are using tendermint as dpos blockchain+p2p+consensus.
Too trivial?
The massive global state struct you are referring to is already there. Going off-chain with storage would very much complicate consensus and any other decentralized solution will also hurt performance
i meant ‘that should work too, trivially’
I assumed the state struct wasn’t there, because encrypted state is being nixed for the current mainnet? if the struct’s there and there’s no need for new work on it, why is encrypted state not planned for the next feature release?
Because i agree, given the existence of a p2p system, encrypted state should be pretty easy to do – so i assumed the reason it wasn’t planned for the upcoming release was bc that p2p layer was broken
We want to release smaller deliverables than we used to. We feel that this way we’ll be more connected with the community,be more open and welcoming and get better feedbacks.
This Means more communications from us to you (like the recent posts from Guy, Can, Tor and James), and faster but smaller release cycles. 
1 Like
Oh, alright, if that’s the reason I’m cool with it 
something something agile
but that really wasn’t clear from the roadmap post, good to have it clarified! (I assume encrypted outputs are similar?)
Not so much agile, but this is what we believe the best way forward - communication and feedback.
Encrypted state, encrypted outputs, randomness, IBC… We prefer hearing from the community what’s more important to them that we do next than guessing it ourselves or doing all at once, which will take longer.
1 Like
Makes sense. What’s the timeline for first release/testnet, btw?
Nothing concrete yet, you’ll know when we know 
1 Like
Well, I’ll have to keep an eye out