refactor: token naming cleanup (#9904)

docs/docs/guides/developer_guides/getting_started.md

@@ -139,12 +139,12 @@ In the next step, let's mint some tokens!
 Call the public mint function like this:
 
 ```bash
-aztec-wallet send mint_public --from accounts:my-wallet --contract-address contracts:testtoken --args accounts:my-wallet 100
+aztec-wallet send mint_to_public --from accounts:my-wallet --contract-address contracts:testtoken --args accounts:my-wallet 100
 ```
 
 This takes
 
-- the function name as the argument, which is `mint_public`
+- the function name as the argument, which is `mint_to_public`
 - the `from` account (caller) which is `accounts:my-wallet`
 - the contract address, which is aliased as `contracts:testtoken` (or simply `testtoken`)
 - the args that the function takes, which is the account to mint the tokens into (`my-wallet`), and `amount` (`100`).
@@ -165,7 +165,7 @@ Transaction has been mined
  Status: success
  Block number: 17
  Block hash: 1e27d200600bc45ab94d467c230490808d1e7d64f5ee6cee5e94a08ee9580809
-Transaction hash stored in database with aliases last & mint_public-9044
+Transaction hash stored in database with aliases last & mint_to_public-9044
 ```
 
 You can double-check by calling the function that checks your public account balance:

docs/docs/guides/developer_guides/js_apps/authwit.md

@@ -68,9 +68,9 @@ Then create the message hash by hashing the inner hash with the authwit receiver
 
 ## Create the authwit
 
-There are slightly different interfaces depending on whether your contract is checking the authwit in private or public. 
+There are slightly different interfaces depending on whether your contract is checking the authwit in private or public.
 
-Public authwits are stored in the account contract and batched with the authwit action call, so a user must send a transaction to update their account contract, authorizing an action before the authorized contract's public call will succeed. 
+Public authwits are stored in the account contract and batched with the authwit action call, so a user must send a transaction to update their account contract, authorizing an action before the authorized contract's public call will succeed.
 
 Private execution uses oracles and are executed locally by the PXE, so the authwit needs to be created by the authwit giver and then added to the authwit receiver's PXE.
 
@@ -107,7 +107,7 @@ Set a public authwit like this:
 Remember it is a transaction and calls a method in the account contract. In this example,
 
 - `wallets[0]` is the authwit giver
-- `wallets[1]` is the authwit reciever and caller of the function
+- `wallets[1]` is the authwit receiver and caller of the function
 - `action` was [defined previously](#define-the-action)
 - `true` sets the `authorized` boolean (`false` would revoke this authwit)
 

docs/docs/guides/developer_guides/smart_contracts/how_to_compile_contract.md

@@ -199,8 +199,8 @@ export class TokenContract extends ContractBase {
 
   /** Type-safe wrappers for the public methods exposed by the contract. */
   public override methods!: {
-    /** transfer_public(from: struct, to: struct, amount: field, nonce: field) */
-    transfer_public: ((
+    /** transfer_in_public(from: struct, to: struct, amount: field, nonce: field) */
+    transfer_in_public: ((
       from: AztecAddressLike,
       to: AztecAddressLike,
       amount: FieldLike,

docs/docs/guides/developer_guides/smart_contracts/testing_contracts/testing.md

@@ -118,13 +118,13 @@ Our test environment is capable of utilizing the autogenerated contract interfac
 
 For example, to call the private `transfer` function on the token contract:
 
-#include_code txe_test_transfer_private /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_private.nr rust
+#include_code txe_test_transfer_private /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer.nr rust
 
 #### Public
 
-To call the public `transfer_public` function:
+To call the public `transfer_in_public` function:
 
-#include_code call_public /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_public.nr rust
+#include_code call_public /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_public.nr rust
 
 #### Unconstrained
 
@@ -178,11 +178,11 @@ Reading notes:
 
 You can add [authwits](../writing_contracts/authwit.md) to the TXE. Here is an example of testing a private token transfer using authwits:
 
-#include_code private_authwit /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_private.nr rust
+#include_code private_authwit /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_private.nr rust
 
 #### Public
 
-#include_code public_authwit /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_public.nr rust
+#include_code public_authwit /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_public.nr rust
 
 ### Storing notes in cache
 
@@ -206,7 +206,7 @@ You can test functions that you expect to fail generically, with the `#[test(sho
 
 For example:
 
-#include_code fail_with_message /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_private.nr rust
+#include_code fail_with_message /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_private.nr rust
 
 You can also use the `assert_public_call_fails` or `assert_private_call_fails` methods on the `TestEnvironment` to check that a call fails.
 

docs/docs/guides/developer_guides/smart_contracts/writing_contracts/authwit.md

@@ -141,7 +141,7 @@ Then you will be able to import it into your contracts as follows.
 
 Based on the diagram earlier on this page let's take a look at how we can implement the `transfer` function such that it checks if the tokens are to be transferred `from` the caller or needs to be authenticated with an authentication witness.
 
-#include_code transfer_from /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust
+#include_code transfer_in_private /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust
 
 The first thing we see in the snippet above, is that if `from` is not the call we are calling the `assert_current_call_valid_authwit` function from [earlier](#private-functions). If the call is not throwing, we are all good and can continue with the transfer.
 
@@ -151,7 +151,7 @@ In the snippet we are constraining the `else` case such that only `nonce = 0` is
 
 Cool, so we have a function that checks if the current call is authenticated, but how do we actually authenticate it? Well, assuming that we use a wallet that is following the spec, we import `computeAuthWitMessageHash` from `aztec.js` to help us compute the hash, and then we simply `addAuthWitness` to the wallet. Behind the scenes this will make the witness available to the oracle.
 
-#include_code authwit_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_private.test.ts typescript
+#include_code authwit_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_in_private.test.ts typescript
 
 Learn more about authwits in Aztec.js by [following this guide](../../js_apps/authwit.md).
 
@@ -161,15 +161,15 @@ With private functions covered, how can we use this in a public function? Well,
 
 #### Checking if the current call is authenticated
 
-#include_code transfer_public /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust
+#include_code transfer_in_public /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust
 
 #### Authenticating an action in TypeScript
 
 Authenticating an action in the public domain is slightly different from the private domain, since we are executing a function on the auth registry contract to add the witness flag. As you might recall, this was to ensure that we don't need to call into the account contract from public, which is a potential DOS vector.
 
 In the snippet below, this is done as a separate contract call, but can also be done as part of a batch as mentioned in the [Accounts concepts](../../../../aztec/concepts/accounts/authwit.md#what-about-public).
 
-#include_code authwit_public_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_public.test.ts typescript
+#include_code authwit_public_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_in_public.test.ts typescript
 
 #### Updating approval state in Noir
 

docs/docs/guides/developer_guides/smart_contracts/writing_contracts/common_patterns/index.md

@@ -21,7 +21,7 @@ We call this the "authentication witness" pattern or authwit for short.
 Here you approve a contract to burn funds on your behalf.
 
 - Approve in public domain:
-  #include_code authwit_public_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_public.test.ts typescript
+  #include_code authwit_public_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_in_public.test.ts typescript
 
 Here you approve someone to transfer funds publicly on your behalf
 
@@ -84,8 +84,6 @@ Let's say you have some storage in public and want to move them into the private
 
 So you have to create a custom note in the public domain that is not encrypted by some owner - we call such notes a "TransparentNote" since it is created in public, anyone can see the amount and the note is not encrypted by some owner.
 
-This pattern is discussed in detail in [the codealong token tutorial in the shield() method](../../../../../tutorials/codealong/contract_tutorials/token_contract.md#redeem_shield).
-
 ### Discovering my notes
 
 When you send someone a note, the note hash gets added to the note hash tree. To spend the note, the receiver needs to get the note itself (the note hash preimage). There are two ways you can get a hold of your notes:

docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md

@@ -53,7 +53,7 @@ The `content_hash` is a sha256 truncated to a field element (~ 254 bits). In Azt
 
 ### Token portal hash library
 
-#include_code mint_public_content_hash_nr /noir-projects/noir-contracts/contracts/token_portal_content_hash_lib/src/lib.nr rust
+#include_code mint_to_public_content_hash_nr /noir-projects/noir-contracts/contracts/token_portal_content_hash_lib/src/lib.nr rust
 
 ### Token Portal contract
 

docs/docs/migration_notes.md

@@ -6,6 +6,21 @@ keywords: [sandbox, aztec, notes, migration, updating, upgrading]
 
 Aztec is in full-speed development. Literally every version breaks compatibility with the previous ones. This page attempts to target errors and difficulties you might encounter when upgrading, and how to resolve them.
 
+## 0.63.0
+### [Token contract] Partial notes related refactor
+We've decided to replace the old "shield" flow with one leveraging partial notes.
+This led to a removal of `shield` and `redeem_shield` functions and an introduction of `transfer_to_private`.
+An advantage of the new approach is that only 1 tx is required and the API of partial notes is generally nicer.
+For more information on partial notes refer to docs.
+
+### [Token contract] Function naming changes
+There have been a few naming changes done for improved consistency.
+These are the renamings:
+`transfer_public` --> `transfer_in_public`
+`transfer_from` --> `transfer_in_private`
+`mint_public` --> `mint_to_public`
+`burn` --> `burn_private`
+
 ## 0.62.0
 ### [TXE] Single execution environment
 Thanks to recent advancements in Brillig TXE performs every single call as if it was a nested call, spawning a new ACVM or AVM simulator without performance loss.

docs/docs/reference/developer_references/sandbox_reference/cli_wallet_reference.md

@@ -104,10 +104,10 @@ The authwit management in private is a two-step process: create and add. It's no
 
 #### Example
 
-An example for authorizing an operator (ex. a DeFi protocol) to call the transfer_from action (transfer on the user's behalf):
+An example for authorizing an operator (ex. a DeFi protocol) to call the transfer_in_private action (transfer on the user's behalf):
 
 ```bash
-aztec-wallet create-authwit transfer_from accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master -a secret_trade
+aztec-wallet create-authwit transfer_in_private accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master -a secret_trade
 
 aztec-wallet add-authwit authwits:secret_trade accounts:jedi_master -f accounts:coruscant_trader
 ```
@@ -117,7 +117,7 @@ aztec-wallet add-authwit authwits:secret_trade accounts:jedi_master -f accounts:
 A similar call to the above, but in public:
 
 ```bash
-aztec-wallet authorize-action transfer_public accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master
+aztec-wallet authorize-action transfer_in_public accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master
 ```
 
 ### Simulate

docs/docs/tutorials/codealong/aztecjs-getting-started.md

@@ -283,7 +283,7 @@ Our output should now look like this:
 Here, we used the same contract abstraction as was previously used for reading Alice's balance. But this time we called `send()` generating and sending a transaction to the network. After waiting for the transaction to settle we were able to check the new balance values.
 
 Finally, the contract has 2 `mint` functions that can be used to generate new tokens for an account.
-We will focus only on `mint_private`.
+We will focus only on `mint_to_private`.
 This function is public but it mints tokens privately.
 This function takes:
 

docs/docs/tutorials/codealong/cli_wallet/faceid_wallet.md

@@ -103,9 +103,9 @@ You should get a prompt to sign this transaction. You can now mint, transfer, an
 
 ```bash
 aztec-wallet create-account -a new_recipient # creating a schnorr account
-aztec-wallet send mint_public -ca last --args accounts:my-wallet 10 -f accounts:my-wallet # minting some tokens in public
+aztec-wallet send mint_to_public -ca last --args accounts:my-wallet 10 -f accounts:my-wallet # minting some tokens in public
 aztec-wallet simulate balance_of_public -ca contracts:devtoken --args accounts:my-wallet -f my-wallet # checking that my-wallet has 10 tokens
-aztec-wallet send transfer_public -ca contracts:devtoken --args accounts:my-wallet accounts:new_recipient 10 0 -f accounts:my-wallet # transferring some tokens in public
+aztec-wallet send transfer_in_public -ca contracts:devtoken --args accounts:my-wallet accounts:new_recipient 10 0 -f accounts:my-wallet # transferring some tokens in public
 aztec-wallet simulate balance_of_public -ca contracts:devtoken --args accounts:new_recipient -f my-wallet # checking that new_recipient has 10 tokens
 ```
 

docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/1_depositing_to_aztec.md

@@ -57,7 +57,7 @@ Here is an explanation of what it is doing:
    - The content is limited to a single field (~254 bits). So if the content is larger, we have to hash it and the hash can be passed along.
      - We use our utility method that creates a sha256 hash but truncates it to fit into a field
    - Since we want to mint tokens on Aztec publicly, the content here is the amount to mint and the address on Aztec who will receive the tokens.
-   - We encode this message as a mint_public function call, to specify the exact intentions and parameters we want to execute on L2.
+   - We encode this message as a mint_to_public function call, to specify the exact intentions and parameters we want to execute on L2.
      - In reality the content can be constructed in any manner as long as the sister contract on L2 can also create it. But for clarity, we are constructing the content like an ABI encoded function call.
      - It is good practice to include all parameters used by L2 into this content (like the amount and to) so that a malicious actor can’t change the to to themselves when consuming the message.
 3. The tokens are transferred from the user to the portal using `underlying.safeTransferFrom()`. This puts the funds under the portal's control.
@@ -78,7 +78,7 @@ Let’s do the similar for the private flow:
 
 Here we want to send a message to mint tokens privately on Aztec! Some key differences from the previous method are:
 
-- The content hash uses a different function name - `mint_private`. This is done to make it easy to separate concerns. If the contentHash between the public and private message was the same, then an attacker could consume a private message publicly!
+- The content hash uses a different function name - `mint_to_private`. This is done to make it easy to separate concerns. If the contentHash between the public and private message was the same, then an attacker could consume a private message publicly!
 - Since we want to mint tokens privately, we shouldn’t specify a `to` Aztec address (remember that Ethereum is completely public). Instead, we will use a secret hash - `secretHashForRedeemingMintedNotes`. Only he who knows the preimage to the secret hash can actually mint the notes. This is similar to the mechanism we use for message consumption on L2
 - Like with the public flow, we move the user’s funds to the portal
 - We now send the message to the inbox with the `recipient` (the sister contract on L2 along with the version of aztec the message is intended for) and the `secretHashForL2MessageConsumption` (such that on L2, the consumption of the message can be private).