You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/docs/tutorials/codealong/aztecjs-getting-started.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -283,7 +283,7 @@ Our output should now look like this:
283
283
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.
284
284
285
285
Finally, the contract has 2 `mint` functions that can be used to generate new tokens for an account.
286
-
We will focus only on `mint_private`.
286
+
We will focus only on `mint_to_private`.
287
287
This function is public but it mints tokens privately.
Copy file name to clipboardexpand all lines: docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/1_depositing_to_aztec.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -78,7 +78,7 @@ Let’s do the similar for the private flow:
78
78
79
79
Here we want to send a message to mint tokens privately on Aztec! Some key differences from the previous method are:
80
80
81
-
- 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!
81
+
- 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!
82
82
- 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
83
83
- Like with the public flow, we move the user’s funds to the portal
84
84
- 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).
The `get_mint_private_content_hash` function is imported from the `token_portal_content_hash_lib`.
49
+
The `get_mint_to_private_content_hash` function is imported from the `token_portal_content_hash_lib`.
50
50
51
-
If the content hashes were constructed similarly for `mint_private` and `mint_to_publicly`, then content intended for private execution could have been consumed by calling the `claim_public` method. By making these two content hashes distinct, we prevent this scenario.
51
+
If the content hashes were constructed similarly for `mint_to_private` and `mint_to_public`, then content intended for private execution could have been consumed by calling the `claim_public` method. By making these two content hashes distinct, we prevent this scenario.
52
52
53
53
While we mint the tokens on L2, we _still don’t actually mint them to a certain address_. Instead we continue to pass the `secret_hash_for_redeeming_minted_notes` like we did on L1. This means that a user could reveal their secret for L2 message consumption for anyone to mint tokens on L2 but they can redeem these notes at a later time. **This enables a paradigm where an app can manage user’s secrets for L2 message consumption on their behalf**. **The app or any external party can also mint tokens on the user’s behalf should they be comfortable with leaking the secret for L2 Message consumption.** This doesn’t leak any new information to the app because their smart contract on L1 knew that a user wanted to move some amount of tokens to L2. The app still doesn’t know which address on L2 the user wants these notes to be in, but they can mint tokens nevertheless on their behalf.
54
54
55
-
To mint tokens privately, `claim_private` calls an internal function `_call_mint_on_token()` which then calls [token.mint_private()](../../token_contract.md#mint_private).
55
+
To mint tokens privately, `claim_private` calls an internal function `_call_mint_on_token()` which then calls [token.mint_to_private()](../../token_contract.md#mint_to_private).
56
56
57
57
In the next step we will see how we can cancel a message.
Copy file name to clipboardexpand all lines: docs/docs/tutorials/codealong/contract_tutorials/token_contract.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -68,7 +68,7 @@ These are functions that have transparent logic, will execute in a publicly veri
68
68
-`set_admin` enables the admin to be updated
69
69
-`set_minter` enables accounts to be added / removed from the approved minter list
70
70
-`mint_to_public` enables tokens to be minted to the public balance of an account
71
-
-`mint_private` enables tokens to be minted to the private balance of an account (with some caveats we will dig into)
71
+
-`mint_to_private` enables tokens to be minted to the private balance of an account (with some caveats we will dig into)
72
72
-`transfer_to_public` enables tokens to be moved from a public balance to a private balance, not necessarily the same account (step 1 of a 2 step process)
73
73
-`transfer_in_public` enables users to transfer tokens from one account's public balance to another account's public balance
74
74
-`burn_public` enables users to burn tokens
@@ -199,7 +199,7 @@ First, storage is initialized. Then the function checks that the `msg_sender` is
0 commit comments