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/guides/developer_guides/js_apps/authwit.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -68,9 +68,9 @@ Then create the message hash by hashing the inner hash with the authwit receiver
68
68
69
69
## Create the authwit
70
70
71
-
There are slightly different interfaces depending on whether your contract is checking the authwit in private or public.
71
+
There are slightly different interfaces depending on whether your contract is checking the authwit in private or public.
72
72
73
-
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.
73
+
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.
74
74
75
75
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.
76
76
@@ -107,7 +107,7 @@ Set a public authwit like this:
107
107
Remember it is a transaction and calls a method in the account contract. In this example,
108
108
109
109
-`wallets[0]` is the authwit giver
110
-
-`wallets[1]` is the authwit reciever and caller of the function
110
+
-`wallets[1]` is the authwit receiver and caller of the function
111
111
-`action` was [defined previously](#define-the-action)
112
112
-`true` sets the `authorized` boolean (`false` would revoke this authwit)
Copy file name to clipboardexpand all lines: docs/docs/guides/developer_guides/smart_contracts/writing_contracts/authwit.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -141,7 +141,7 @@ Then you will be able to import it into your contracts as follows.
141
141
142
142
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.
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.
147
147
@@ -151,7 +151,7 @@ In the snippet we are constraining the `else` case such that only `nonce = 0` is
151
151
152
152
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.
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.
169
169
170
170
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).
Here you approve someone to transfer funds publicly on your behalf
27
27
@@ -84,8 +84,6 @@ Let's say you have some storage in public and want to move them into the private
84
84
85
85
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.
86
86
87
-
This pattern is discussed in detail in [the codealong token tutorial in the shield() method](../../../../../tutorials/codealong/contract_tutorials/token_contract.md#redeem_shield).
88
-
89
87
### Discovering my notes
90
88
91
89
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:
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
@@ -57,7 +57,7 @@ Here is an explanation of what it is doing:
57
57
- 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.
58
58
- We use our utility method that creates a sha256 hash but truncates it to fit into a field
59
59
- 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.
60
-
- We encode this message as a mint_public function call, to specify the exact intentions and parameters we want to execute on L2.
60
+
- We encode this message as a mint_to_public function call, to specify the exact intentions and parameters we want to execute on L2.
61
61
- 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.
62
62
- 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.
63
63
3. The tokens are transferred from the user to the portal using `underlying.safeTransferFrom()`. This puts the funds under the portal's control.
Copy file name to clipboardexpand all lines: docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/2_minting_on_aztec.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -28,15 +28,15 @@ The `claim_public` function enables anyone to consume the message on the user's
28
28
29
29
**What’s happening here?**
30
30
31
-
1. We first recompute the L1->L2 message content by calling `get_mint_public_content_hash()`. Note that the method does exactly the same as what the TokenPortal contract does in `depositToAztecPublic()` to create the content hash.
31
+
1. We first recompute the L1->L2 message content by calling `get_mint_to_public_content_hash()`. Note that the method does exactly the same as what the TokenPortal contract does in `depositToAztecPublic()` to create the content hash.
32
32
2. We then attempt to consume the L1->L2 message. Since we are depositing to Aztec publicly, all of the inputs are public.
33
33
-`context.consume_l1_to_l2_message()` takes in the few parameters:
34
-
-`content_hash`: The content - which is reconstructed in the `get_mint_public_content_hash()`
34
+
-`content_hash`: The content - which is reconstructed in the `get_mint_to_public_content_hash()`
35
35
-`secret`: The secret used for consumption, often 0 for public messages
36
36
-`sender`: Who on L1 sent the message. Which should match the stored `portal_address` in our case as we only want to allow messages from a specific sender.
37
37
-`message_leaf_index`: The index in the message tree of the message.
38
38
- Note that the `content_hash` requires `to` and `amount`. If a malicious user tries to mint tokens to their address by changing the to address, the content hash will be different to what the token portal had calculated on L1 and thus not be in the tree, failing the consumption. This is why we add these parameters into the content.
39
-
3. Then we call `Token::at(storage.token.read()).mint_public()` to mint the tokens to the to address.
39
+
3. Then we call `Token::at(storage.token.read()).mint_to_public()` to mint the tokens to the to address.
40
40
41
41
## Private flow
42
42
@@ -48,7 +48,7 @@ Now we will create a function to mint the amount privately. Paste this into your
48
48
49
49
The `get_mint_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_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_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.
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.
0 commit comments