added account updates summary

GettingStarted/MinaAndZkAppEssentials.md

@@ -13,6 +13,7 @@
     - [Deploy a zkApp and entities involved when running code](#deploy-a-zkapp-and-entities-involved-when-running-code)
     - [Writing a zkApp](#writing-a-zkapp)
     - [Permissions and authorizations](#permissions-and-authorizations)
+    - [Account Updates](#account-updates)
     - [Events](#events)
     - [Actions \& Reducers](#actions--reducers)
     - [Fetching events \& actions](#fetching-events--actions)
@@ -244,6 +245,19 @@ Mina.setActiveInstance(Local);
   - `setVerificationKey` has slightly different authorizations types: `none`, `signature`, `proofOrSignature` exist as they were, instead `impossible` now is `impossibleDuringCurrentVersion` and `proof` now is `proofDuringCurrentVersion`
   - If set to `impossibleDuringCurrentVersion()` it will not be possible to update the verification key unless an hardfork happens, namely the new transaction version is greater than the old one. More [here](https://docs.minaprotocol.com/zkapps/writing-a-zkapp/feature-overview/permissions#upgrading-after-an-update-to-the-mina-protocol) and [here](https://docs.minaprotocol.com/zkapps/writing-a-zkapp/feature-overview/permissions#example-impossible-to-upgrade).
 
+#### Account Updates
+We talked about Account Updates in different paragraphs. Let's summarize the informations provided:
+- Account Updates is nothing more that a JSON file in plain text containing
+  - precondition of the previous state
+  - a list of the changes to apply on-chain to different accounts (one item for account) when sending a transaction.
+- When code is executed locally, the list of Account Updates is created
+- Applying the changes described within Account Updates needs to be authorized by either a Signature or Proof.
+- When `tx.prove()` is called, a proof for the defined Account Updates is created. For zkApps the public input is the account update that is passed in implicitly with `tx.prove()`
+- The proof and account updates are signed and sent to the Mina network as a transaction. If the proof is valid, then the changes described in the Account Updates are applied to the zkApp updating its state
+- The integrity of these account updates is ensured by passing a hash of the account updates as a public input to the smart contract. 
+- The account updates must be present and unmodified for the verification function to pass successfully when it runs on Mina.
+
+
 #### Events
 - are informations passed along with a transaction
 - use cases: a zkApp would like to publish a message and so emits an event for observers, highlight state changes of an off chain storage (e.g. merkle trees are stored off chain and commit only the root on-chain: when a leaf changes its value the root changes and in the event you can emit what actually changed) 

README.md

@@ -43,6 +43,7 @@ Permissions related issues:\
 🔒 [restrictive permissions can be circumvented if `setPermissions` is not set to impossible](https://docs.minaprotocol.com/zkapps/writing-a-zkapp/feature-overview/permissions#example-impossible-to-upgrade:~:text=For%20the-,sake,-of%20security%2C%20it)\
 🔒 [lack of access controls](https://docs.minaprotocol.com/zkapps/writing-a-zkapp/feature-overview/permissions#example-unsecurecontract:~:text=not%20very%20secure%3A-,Anyone,-can%20call%20the)\
 🔒 [Minting unlimited tokens to himself is possile for an attacker if a custom token contract does not change `access` permission from `none` to at least `proof`](https://docs.minaprotocol.com/zkapps/writing-a-zkapp/introduction-to-zkapps/secure-zkapps#dont-deadlock-your-zkapp-by-interacting-with-unknown-accounts:~:text=can%20mint%20an-,arbitrary,-number%20of%20tokens)
+🔒 Setting `access` to `impossible` makes your account inaccessible: no one will ever be able to call their contract againt. It's like deleting.
 
 ## Development best practices
 - Do not assume that the fact that someone has to pay transaction fees doesn't have incentives to attack your zkApp