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
Ok. Don't be scared. 262 files sounds horrific but it's mostly path
updates and that kind of nonsense. The `noir-contracts` and
`noir-compiler` changes are probably what to focus on.
* We update boxes to use our build of nargo, and the modified
code-generator.
* We update paths in docs, as noir-contracts/src/contracts moved to
noir-contracts/contracts, as src is now pure codegen output.
* Contracts are now imported e.g. `import { ChildContractArtifact } from
'@aztec/noir-contracts/Child';`. You can still just import from top
level index, but it's pretty cruel to ask the runtime to parse all the
artifacts just to get one, they are huge.
* Contract files are now just named as per the name of the contract
(i.e. not snake case). Less moving parts is better here. Given it's
codegen output it's acceptable to allow the output names to be
inconsistent.
* aztec.js is now responsible for copying the account contracts into
itself, as opposed to have some other random module push code into it.
But we just need to get rid of this baked account stuff at some point
anyway.
* Got rid of lodash.zip in one place, and then restrained myself to not
go further. But think we should remove the "trivial" lodash cases at
some point.
* Tidied up yp/bootstrap a bit, it's basically in line with the
dockerfile at this point. Will prob make dockerfile just call bootstrap
as part of some other docker cleanup I'll do later.
* `source-map-support` in cli.
* Remove compile command from cli. We are just going to promote use of
aztec-nargo.
* The ts and noir generators now expect nargo output as input, rather
than our transformed abi. The ts generator outputs the transformed abi
as part of it's generation.
* Delete all the script stuff from `noir-contracts`. src folder is now
just the codegen output, and the codegen is done with a trivial script
to call compile and the ts generator in noir-compiler.
* Added an unused script called `transform_json_abi.sh` that uses a tiny
bit of jq to perform the transform. Probably to be deleted, especially
if we just stop transforming the noir output and use it directly, but it
served me as a useful tool at one point.
Still, different accounts may use different signing schemes, may require multi-factor authentication, or _may not even use signing keys_ and instead rely on other authentication mechanisms. Read [how to write an account contract](../../../dev_docs/wallets/writing_an_account_contract.md) for a full example of how to manage authentication.
Copy file name to clipboardexpand all lines: docs/docs/dev_docs/cli/cli-commands.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -93,7 +93,7 @@ export ADDRESS2=<Account address printed by the above command>
93
93
94
94
## Deploying a Token Contract
95
95
96
-
We will now deploy a token contract using the `deploy` command, and set an address of the admin via a constructor argument. You can find the contract we are deploying [here](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/src/contracts/token_contract/src/main.nr) (or write it for yourself in [this tutorial!](../tutorials/writing_token_contract.md))
96
+
We will now deploy a token contract using the `deploy` command, and set an address of the admin via a constructor argument. You can find the contract we are deploying [here](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/contracts/token_contract/src/main.nr) (or write it for yourself in [this tutorial!](../tutorials/writing_token_contract.md))
97
97
Make sure to replace this address with one of the two you created earlier.
We called the [`mint_public`](https://github.com/AztecProtocol/aztec-packages/blob/87fa621347e55f82e36c70515c1824161eee5282/yarn-project/noir-contracts/src/contracts/token_contract/src/main.nr#L157C10-L157C10) function and provided it with the 2 arguments it expects: the recipient's address and the amount to be minted. Make sure to replace all addresses in this command with yours.
126
+
We called the [`mint_public`](https://github.com/AztecProtocol/aztec-packages/blob/87fa621347e55f82e36c70515c1824161eee5282/yarn-project/noir-contracts/contracts/token_contract/src/main.nr#L157C10-L157C10) function and provided it with the 2 arguments it expects: the recipient's address and the amount to be minted. Make sure to replace all addresses in this command with yours.
127
127
128
128
The command output tells us the details of the transaction such as its hash and status. We can use this hash to query the receipt of the transaction at a later time:
You can see all of our example contracts in the monorepo [here](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/noir-contracts/src/contracts).
177
+
You can see all of our example contracts in the monorepo [here](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/noir-contracts/contracts).
Below is typescript code generated from the [Token](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/src/contracts/token_contract/src/main.nr) contract:
45
+
Below is typescript code generated from the [Token](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/contracts/token_contract/src/main.nr) contract:
46
46
47
47
```ts showLineNumbers
48
48
exportclassTokenContractextendsContractBase {
@@ -145,7 +145,7 @@ You can also generate these interfaces from prebuilt artifacts using the `genera
Below is an example interface, also generated from the [Token](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/src/contracts/token_contract/src/main.nr) contract:
148
+
Below is an example interface, also generated from the [Token](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/contracts/token_contract/src/main.nr) contract:
Please note that any example contract set out herein is provided solely for informational purposes only and does not constitute any inducement to use or deploy. Any implementation of any such contract with an interface or any other infrastructure should be used in accordance with applicable laws and regulations.
Computing the `content` must be done manually in its current form, as we are still adding a number of bytes utilities. A good example exists within the [Token bridge example](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/src/contracts/token_bridge_contract/src/util.nr).
47
+
Computing the `content` must be done manually in its current form, as we are still adding a number of bytes utilities. A good example exists within the [Token bridge example](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/contracts/token_bridge_contract/src/util.nr).
The `content_hash` is a sha256 truncated to a field element (~ 254 bits). In Aztec-nr, you can use our `sha256_to_field()` to do a sha256 hash which fits in one field element
When the transaction is included in a rollup block the message will be inserted into the `Outbox`, where the recipient portal can consume it from. When consuming, the `msg.sender` must match the `recipient` meaning that only portal can actually consume the message.
94
94
@@ -202,4 +202,4 @@ Designated callers are enforced at the contract level for contracts that are not
202
202
203
203
- Token bridge (Portal contract built for L1 -> L2, i.e., a non-native L2 asset)
Very similar to the above, we have variations that work in the public domain. These functions are wrapped to give a similar flow for both cases, but behind the scenes the logic of the account contracts is slightly different since they cannot use the oracle as they are not in the private domain.
#### Checking if the current call is authenticated
144
144
145
145
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.
146
146
147
-
#include_code transfer /yarn-project/noir-contracts/src/contracts/token_contract/src/main.nr rust
147
+
#include_code transfer /yarn-project/noir-contracts/contracts/token_contract/src/main.nr rust
148
148
149
149
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.
150
150
@@ -162,7 +162,7 @@ With private functions covered, how can we use this in a public function? Well,
162
162
163
163
#### Checking if the current call is authenticated
It also needs a way to update those storage values. Since we want the updates to be trustless, we can compute the action based on the function inputs, and then have the contract compute the key at which it must add a `true` to approve the action.
184
184
185
185
An example of this would be our Uniswap example which performs a cross chain swap on L1. In here, we both do private and public auth witnesses, where the public is set by the uniswap L2 contract itself. In the below snippet, you can see that we compute the action hash, and then update an `approved_action` mapping with the hash as key and `true` as value. When we then call the `token_bridge` to execute afterwards, it reads this value, burns the tokens, and consumes the authentication.
Outlining more of the `swap` flow: this simplified diagram shows how it will look for contracts that are not wallets but also need to support authentication witnesses.
Copy file name to clipboardexpand all lines: docs/docs/dev_docs/contracts/resources/common_patterns/main.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -57,9 +57,9 @@ contract Bridge {
57
57
amount:Field,
58
58
) ->Field {
59
59
...
60
-
#include_codecall_assert_token_is_same/yarn-project/noir-contracts/src/contracts/token_bridge_contract/src/main.nr raw
60
+
#include_codecall_assert_token_is_same/yarn-project/noir-contracts/contracts/token_bridge_contract/src/main.nr raw
61
61
}
62
-
#include_codeassert_token_is_same/yarn-project/noir-contracts/src/contracts/token_bridge_contract/src/main.nr raw
62
+
#include_codeassert_token_is_same/yarn-project/noir-contracts/contracts/token_bridge_contract/src/main.nr raw
63
63
}
64
64
```
65
65
:::danger
@@ -102,11 +102,11 @@ Hence, it's necessary to add a "randomness" field to your note to prevent such a
102
102
Currently, if you have storage defined, the compiler will error if you don't have a `compute_note_hash_and_nullifier()` defined. Without this, the PXE can't process encrypted events and discover your notes.
103
103
104
104
If your contract doesn't have anything to do with notes (e.g. operates solely in the public domain), you can do the following:
Otherwise, you need this method to help the PXE with processing your notes. In our [demo token contract](../../../tutorials/writing_token_contract.md#compute_note_hash_and_nullifier), we work with 2 kinds of notes: `ValueNote` and `TransparentNote`. Hence this method must define how to work with both:
Refer to [Token Portal tutorial on bridging tokens between L1 and L2](../../../tutorials/token_portal/main.md) and/or [Uniswap tutorial that shows how to swap on L1 using funds on L2](../../../tutorials/uniswap/main.md). Both examples show how to:
0 commit comments