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:
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.
8
8
9
+
## 0.63.0
10
+
### [Token contract] Partial notes related refactor
11
+
We've decided to replace the old "shield" flow with one leveraging partial notes.
12
+
This led to a removal of `shield` and `redeem_shield` functions and an introduction of `transfer_to_private`.
13
+
An advantage of the new approach is that only 1 tx is required and the API of partial notes is generally nicer.
14
+
For more information on partial notes refer to docs.
15
+
16
+
### [Token contract] Function naming changes
17
+
There have been a few naming changes done for improved consistency.
18
+
These are the renamings:
19
+
`transfer_public` --> `transfer_in_public`
20
+
`transfer_from` --> `transfer_in_private`
21
+
`mint_public` --> `mint_to_public`
22
+
`burn` --> `burn_private`
23
+
9
24
## 0.62.0
10
25
### [TXE] Single execution environment
11
26
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.
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
+2-2
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.
@@ -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).
0 commit comments