If you trap during one of your update calls the canister will be restored to the state before the call happened (every await is also a commit point), but I think you’re not asking about this case.
Right now, you need to implement custom logic to do rollbacks. There’s some good ideas in this thread. AFAIK we intend to implement canister backup (downloading complete canister state) and restore operations soon™ but no concrete work has started yet.
Thanks for your answer. My question is regarding the immutability of a blockchain and around the question: Goes the IC confirm with the GDPR.
Let me explain it with an example:
Imagine I have a user record stored on the IC. Later I would like to delete this record, I can do that easily with motoko and some logic.
But in this case the deleted record is not accessibe for me and others anymore. It remains saved in a previous state on the IC, but this state is not accessible for me. Is that correct?
ah, GDPR, that makes the context clearer. In general, subnets do not save the state for previous blocks except for some quite recent checkup points (think hours, not even days IIRC). So anything you delete should be lost to history pretty soon, however, it is not guaranteed to be thrown away (nodes could - for this case maliciously - store older backups).
If your application were to run on a public subnet, the whole answer would change, however. For more on that topic see this thread.
If I understand your point correct, the IC respects the GDPR right of forget, because the subnet will not store any previous state.
A malicious actor can make a copy without authorization but the same would be happen if a malicious employee from AWS or any other cloud provider could make a copy of my data.
But could you explain how this malicious actor can extract my data record in a human readable form from the copied state ?
AFAIK the replica is like a black box for a node provider, but with some effort a node provider could dump the state of the replica and investigate it.
Technically, I’d argue it is way harder for a node provider to access data than for an AWS employee. However, AWS has signed the required contracts.
Thanks for the link to the GDPR thread. After reading over this I ask myself, which kind of application can I build? So as a company based in the EU, we have to make sure the data remains into the EU. For some people is this the killer argument.
Also if the IC will replace the AWS, Google, Azure and co and will be a place for application developer I ask myself again as an entrepreneur which kind of application can we build and I don’t speak about any EU regulations like MiCA e.g.
I’m a little bit confused!! The tech is one side but If I can use the tech in legal secure way what’s then ?
Yes, absolutely. You cannot claim that you want to compete with AWS and ignore 99% of applications that require certain regulations. If Amazon or Google has to comply, they will have to ICP.
And it’s not just an EU issue. We had an interesting discussion with the guy from the healthcare space yesterday, he likes ICP. We could identify many potential highly valued applications, but you have to be HIPAA compliant, so data will not leave the US.
I think that ICP technology allows it to happen, just need to probably make some decisions.
I will give one example to be GDPR conform, hopefully.
Currently we are running an application which stores Verified Credentials (W3C) on the IC. The VC does not store personal data. In this point we are safe.
To verify or download such a VC we use a web2 application (frontend, and backend) hosted into the EU which works as a kind of proxy, a nodejs backend application does the final request to the IC canister, so the only IP which could be stored it’s ours and no customer IP address is stored on the boundary nodes of the node provider.
To answer my question: which kind of application you can build as an EU based company the following roles must be considered.
1.) encrypt all PII data
2.) use an backend Motoko or asset canister to store date, a frontend canister is not allowed (IP address of the customer could be stored outside of the EU)
3.) use a web2 application located in the EU as proxy to hide the customer IP.
I wonder why there isn’t more discussion about how these realities can be dealt with.
note that users access the IC via Boundary Nodes. The replica nodes won’t get the IP address of the user. Also, Boundary Nodes don’t log IP addresses AFAIK (cc @raymondk).
Furthermore, you could run your own HTTP Gateway (one part of a Boundary Node), and then even the DFINITY Boundary Nodes wouldn’t see the IP addresses of the users.