feat: use privacy consistently

docs/docs/about_aztec/history/differences_to_aztec_connect.md

@@ -4,9 +4,9 @@
 
 In Connect, we had multiple circuits that could each create/destroy a unified set of value notes. This was acceptable because all Connect circuits had a single author (us!).
 
-In Aztec our architecture must process arbitrary circuits written by potentially dishonest actors. Contract state must therefore be siloed at the architecture level similar to Ethereum. Fortunately, this does not require splitting up the anonymity set.
+In Aztec our architecture must process arbitrary circuits written by potentially dishonest actors. Contract state must therefore be siloed at the architecture level similar to Ethereum. Fortunately, this does not require splitting up the privacy set.
 
-**Anonymity set must be shared across all contracts**
+**Privacy set must be shared across all contracts**
 
 In Connect observers knew when different note types were being created (value note, account note etc). This cannot be the case in Aztec, as we want to provide strong privacy gaurantees to all private contracts even if they have few transactions interacting with their contract.
 

docs/docs/about_aztec/history/history.mdx

@@ -60,11 +60,11 @@ The original blockchain.
 
 **Programmability**:  
 - The functionality of zk.money, plus:  
-- Tokens can be sent from the L2 shielded pool to many L1 defi contracts, and the resulting tokens can be re-shielded. This gives anonymity to L1 defi users.
+- Tokens can be sent from the L2 shielded pool to many L1 defi contracts, and the resulting tokens can be re-shielded. This gives privacy to L1 defi users.
 
 **Privacy**:  
 - Transfers of the ERC20 tokens within the L2 are private.  
-- User defi interactions are anonymous.
+- User defi interactions are private.
 
 ---
 
@@ -80,5 +80,5 @@ The original blockchain.
 - Executing private functions grants:
   - Function privacy
   - Input privacy
-  - User anonymity
+  - User privacy
 - Executing a private function which calls a public function grants varying degrees of privacy, depending on the application someone deploys. (Similar to how deposits and withdrawals to/from shielded pools can leak privacy).

docs/docs/concepts/advanced/contract_creation.md

@@ -153,7 +153,7 @@ The contract address is calculated by the contract deployer, deterministically,
 
 > The EVM's CREATE2 does `contractAddress = hash(0xff, deployerAddress, salt, keccak(bytecode))` - we've taken this as inspiration.
 
-- `deployerAddress` is included to prevent frontrunning of deployment requests, but it does reveal who is deploying the contract. To remain anonymous a user would have to use a burner address, or deploy a contract _through_ a private contract which can deploy contracts.
+- `deployerAddress` is included to prevent frontrunning of deployment requests, but it does reveal who is deploying the contract. To remain private a user would have to use a burner address, or deploy a contract _through_ a private contract which can deploy contracts.
 - :question: Why does CREATE2 include a deployerAddress?
 - :exclamation: So that contracts can deploy contracts to deterministic addresses. Original goal was to enable pre-funding contracts before they were deployed. Not v. relevant for us though
 - `salt` gives the deployer some 'choice' over the eventual contract address; they can loop through salts until they find an address they like.

docs/docs/dev_docs/privacy/main.md

@@ -45,7 +45,7 @@ There are many caveats to the above. Since Aztec also enables interaction with t
 Any time a private function makes a call to a public function, information is leaked. Now, that might be perfectly fine in some use cases (it's up to the smart contract developer). Indeed, most interesting apps will require some public state. But let's have a look at some leaky patterns:
 
 - Calling a public function from a private function. The public function execution will be publicly visible.
-- Calling a public function from a private function, without anonymising the `msg_sender` of that call. (Otherwise the `msg_sender` will be publicly visible).
+- Calling a public function from a private function, without revealing the `msg_sender` of that call. (Otherwise the `msg_sender` will be publicly visible).
 - Passing arguments to a public function from a private function. All of those arguments will be publicly visible.
 - Calling an internal public function from a private function. The fact that the call originated from a private function of that same contract will be trivially known.
 - Emitting unencrypted events from a private function. The unencrypted event name and arguments will be publicly visible.
@@ -118,7 +118,7 @@ App developers should be aware of this avenue for private data leakage. **Whenev
 
 To read a private state is to read a note from the private data tree. To read a note is to prove existence of that note in the private data tree. And to prove existence is to re-compute the root of the private data tree using the leaf value, the leaf index, and the sibling path of that leaf. This computed root is then exposed to the world, as a way of saying "This note exists", or more precisely "This note has existed at least since this historic snapshot time".
 
-If an old historic snapshot is used, then that old historic root will be exposed, and this leaks some information about the nature of your transaction: it leaks that your note was created before the snapshot date. It shrinks the 'anonymity set' of the transaction to a smaller window of time than the entire history of the network.
+If an old historic snapshot is used, then that old historic root will be exposed, and this leaks some information about the nature of your transaction: it leaks that your note was created before the snapshot date. It shrinks the 'privacy set' of the transaction to a smaller window of time than the entire history of the network.
 
 So for maximal privacy, it's in a user's best interest to read from the very-latest snapshot of the data tree.
 
@@ -130,7 +130,7 @@ But if a user is not running their own node, they would need to query the very-l
 
 We're [researching](../../about_aztec/roadmap/engineering_roadmap.md) cryptographic ways to enable users to retrieve sibling paths from 3rd-parties without revealing leaf indices.
 
-> \* Note: due to the non-uniformity of Aztec transactions, the 'anonymity set' of a transaction might not be the entire set of transactions that came before. See here (LINK).
+> \* Note: due to the non-uniformity of Aztec transactions, the 'privacy set' of a transaction might not be the entire set of transactions that came before. See here (LINK).
 
 ##### Any query