Since I joined the Enigma community, I’ve had several interesting discussions about the concept of encrypted state. It’s a difficult idea to grasp immediately, and I’m still figuring out how to best communicate the meaning of that unique selling point and its potential impact on Enigma’s adoption. Here’s a brief description for reference:
“Enigma’s Discovery release features encrypted state. In effect, this means that secret contracts can function as encrypted databases shared between multiple parties. This enables games that have multiple rounds like poker. It also enables organizations to create shared database that they can both contribute to, and compute over. Furthermore, it addresses a key need of enterprises: to update and modify user permissions for these shared data. Encrypted state is a novel contribution to distributed private computation, because it means applications can have shared, secret storage— without requiring trust in a counterparty. Other forms of encrypted storage do not enable both updates to the state of that storage, and computation over the stored data. Encrypted state and encrypted data in use are our unique contributions to this field.”
Maybe it would help if the phrase involved the context of blockchain? Encrypted state could seem vague to app developers who think about state in a different way. If our audience understands the value of blockchains, we should be able to explain why privacy and Enigma are crucial for adoption. How can we better explain Secret State? Please let us know your thoughts!
I think most people expect state when they think of secret contracts. And that’s because it’s so fundamental – Do Ethereum contracts have state? Yes, of course – How else would we know what the current balance is?
In that same way, an Enigma Secret Contract enables you to store and update data within the contract over time.
To respond to @anon60841010’s questions,
1 - because we understood from partners that state would enable a much wider range of use-cases
2 - some of which are:
modifying the permissions of secret contracts (i.e., who is authorized to do what)
updating the data stored in the contract (for example, alice sends in some data. Bob adds his data to Alice’s. Cathy adds her data. All users are able to query the contract for a result based on data that has been submitted thus far, update their data, and query it again later.
games that take place over multiple rounds
But in essence, I think I would frame it not as what “state” enables for Enigma, but rather that we all already expect and require statefulness on our decentralized applications. BUT-- we should be able to have data privacy for this as well.
As a counterexample, Enigma could, for example, have tried to suggest developers use Ethereum to set the state of their applications. Then after every secret computation, they would have to update and store that state publicly on Ethereum (which would be expensive in addition to less useful). We choose to optionally enable Ethereum function calls, and natively support stateful secret contracts to make a better and more useful developer experience.
First of all, blockchains are replicated state machines and blockchains have state. Encrypted state means an encrypted blockchain or a blockchain that can handle sensitive data. It’s a basic principle, a hard but a necessary one to achieve.
State has many useful implications. Imagine we are playing a best of 5 rock paper scissors game on Enigma and betting 1 ETH each. If there was no state on Enigma, the result of each round would be submitted to Ethereum and winner would be determined after 3-5 Ethereum TXs + 1 more TX to move the funds to winners. With state in Enigma, all game logic can take place on Enigma and then the winner can be determined on Enigma, reducing the number TXs needed on Ethereum to 2 (one to determine the winner and one to transfer the funds). There are numerous examples like this we can talk about.
For clarity, the first testnet we released in Summer 2018 was not a stateful network.
How is state saved on Enigma? Is it saved in a node’s enclave? Does the state last forever as it does on a blockchain or just as long as the contract runs?
Hi @anon60841010
To answer your questions:
1 - that depends on what’s being stored. There are limitations on task size.
2 - good question, but I don’t have an answer at this time. I understand the question is driven by the situation with Ethereum nodes, but we’re likely to have better information around this after we launch at least the networked testnet.
No, the state can be reconstructed by other nodes.
If the node goes down before completing the task, another worker will be assigned that task and subsequently update the state.
Part of each node completing their assigned task is updating the state delta and propagating that across the enigma p2p network.
It doesn’t – I was saying I understand he is asking because it is a current issue in Ethereum, so he is curious if we will have the same issue. I don’t have a concrete answer for that yet, we have very different constraints and will have more data after testnet.
Edit-- the short answer is no, there is no state rent implemented at this time.
Roger that I misinterpreted your initial response to Ian. The question was being driven by experience with ETH nodes; not that technical issue at hand. This all is very cool. Reduces transactions and thus cost for Dapps making them more usable, helps with scaling issues, AND enables more hidden logic/states. I’m looking forward to some more walk throughs like the one @can provided above!
Re: explaining encrypted state, I think @ainsley and @can did a great job explaining its importance. I’d sum it all up saying that pretty much every internet service today requires a state. A state is essentially your application’s database, and I’m struggling to think of even a single, sufficiently interesting, application that does not require a database.
As to how state is stored in the Enigma network. Some technical pointers:
Although not every node runs every computation, ALL nodes replicate all state in the network. This is to prevent any data availability problems
We are thinking of ways to shard the data as well, but wanted to at least reduce one dimension of the problem space (again - availability)
State is comprised of encrypted deltas. Every state change results in a delta that is propagated in the network by the worker who committed that change. A secret contract’s state is essentially the composition of all of these deltas.
We are considering issues like rent, but since this is an open research topic (on other networks as well), we decided not to tackle it in the near future.