chore: adding some clarification after a question on discourse (Aztec…

…Protocol#3823)

Adding some clarification on when exactly are note hash contents
available, following a [question on
discourse](https://forum.aztec.network/t/trust-assumptions-for-private-public-functions-that-create-notes-and-then-revert/2692/3?u=spalladino).
Thanks @spalladino for the tag!

---------

Co-authored-by: José Pedro Sousa <[email protected]>
Co-authored-by: Cat McGee <[email protected]>
Co-authored-by: Santiago Palladino <[email protected]>

docs/docs/concepts/foundation/state_model/storage_slots.md

@@ -28,7 +28,7 @@ For structs and arrays, we are logically using a similar storage slot computatio
 
 Private storage is a different beast. As you might remember from [State Model](./main.md), private state is stored in encrypted logs and the corresponding private state commitments in append-only tree where each leaf is a commitment. Being append-only, means that leaves are never updated or deleted; instead a nullifier is emitted to signify that some note is no longer valid. A major reason we used this tree, is that lookups at a specific storage slot would leak information in the context of private state. If you could look up a specific address balance just by looking at the storage slot, even if encrypted you would be able to see it changing! That is not good privacy. 
 
-Following this, the storage slot as we know it doesn't really exist. The leaves of the note hashes tree are just commitments to content (think of it as a hash of its content). 
+Following this, the storage slot as we know it doesn't really exist. The leaves of the note hashes tree are just commitments to content (think of it as a hash of its content).
 
 Nevertheless, the concept of a storage slot is very useful when writing applications, since it allows us to reason about distinct and disjoint pieces of data. For example we can say that the balance of an account is stored in a specific slot and that the balance of another account is stored in another slot with the total supply stored in some third slot. By making sure that these slots are disjoint, we can be sure that the balances are not mixed up and that someone cannot use the total supply as their balance. 
 

docs/docs/dev_docs/contracts/resources/common_patterns/main.md

@@ -66,10 +66,10 @@ contract Bridge {
 This leaks information about the private function being called and the data which has been read. 
 :::
 
-### Writing public storage from private: when updating public state from private, you can call a public function from private, just make sure you mark public as internal
+### Writing public storage from private
+When calling a private function, you can update public state by calling a public function.
 
-When calling a public function from private, try to mark the public function as `internal`
-This ensures your flow works as intended and that no one can call the public function without going through the private function first!
+In this situation, try to mark the public function as `internal`. This ensures your flow works as intended and that no one can call the public function without going through the private function first!
 
 ### Moving public data into the private domain
 Let's say you have some storage in public and want to move them into the private domain. If you pass your aztec address that should receive the data, then that leaks privacy (as everyone will know who has the private notes). So what do you do?
@@ -91,6 +91,16 @@ When you send someone a note, the note hash gets added to the [note hash tree](.
 
 In the token contract, TransparentNotes are stored in a set called "pending_shields" which is in storage slot 5. See [here](../../../tutorials/writing_token_contract.md#contract-storage)
 
+### Revealing encrypted logs conditionally
+
+An encrypted log can contain any information for a recipient, typically in the form of a note. One could think this log is emitted as part of the transaction execution, so it wouldn't be revealed if the transaction fails.
+
+This is not true for Aztec, as the encrypted log is part of the transaction object broadcasted to the network. So if a transaction with an encrypted log and a note commitment is broadcasted, there could be a situation where the transaction is not mined or reorg'd out, so the commitment is never added to the note hash tree, but the recipient could still have read the encrypted log from the transaction in the mempool.
+
+Example:
+
+> Alice and Bob agree to a trade, where Alice sends Bob a passcode to collect funds from a web2 app, in exchange of on-chain tokens. Alice should only send Bob the passcode if the trade is successful. But just sending the passcode as an encrypted log doesn't work, since Bob could see the encrypted log from the transaction as soon as Alice broadcasts it, decrypt it to get the passcode, and withdraw his tokens from the trade to make the transaction fail.
+
 ### Randomness in notes
 Notes are hashed and stored in the merkle tree. While notes do have a header with a `nonce` field that ensure two exact notes still can be added to the note hash tree (since hashes would be different), preimage analysis can be done to reverse-engineer the contents of the note.