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
This PR adds source code references to code that was previously hard
coded. It also adds a couple of functions that are in the implementation
but were not referenced in the tutorial.
- removes references to the `utils.nr` file that is no longer used in
the implementation in noir-contracts.
- Adds the FORK_URL and FORK_BLOCK_NUMBER env vars to the sandbox
reference page
# Checklist:
Remove the checklist to signal you've completed it. Enable auto-merge if
the PR is ready to merge.
- [ ] If the pull request requires a cryptography review (e.g.
cryptographic algorithm implementations) I have added the 'crypto' tag.
- [ ] I have reviewed my diff in github, line by line and removed
unexpected formatting changes, testing logs, or commented-out code.
- [ ] Every change is related to the PR description.
- [ ] I have
[linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
this pull request to relevant issues (if any exist).
@@ -108,8 +70,10 @@ Note that because L1 is public, everyone can inspect and figure out the fee, con
108
70
109
71
**So how do we privately consume the message on Aztec?**
110
72
111
-
On Aztec, anytime something is consumed, we emit a nullifier hash and add it to the nullifier tree. This prevents double-spends. The nullifier hash is a hash of the message that is consumed. So without the secret, one could reverse engineer the expected nullifier hash that might be emitted on L2 upon message consumption. Hence, to consume the message on L2, the user provides a secret to the private noir function, which computes the hash and asserts that it matches to what was provided in the L1->L2 message. This secret is then included in the nullifier hash computation and emits this nullifier. This way, anyone inspecting the blockchain, won’t know which nullifier hash corresponds to the L1->L2 message consumption.
73
+
On Aztec, anytime something is consumed (i.e. deleted), we emit a nullifier hash and add it to the nullifier tree. This prevents double-spends. The nullifier hash is a hash of the message that is consumed. So without the secret, one could reverse engineer the expected nullifier hash that might be emitted on L2 upon message consumption. To consume the message on L2, the user provides a secret to the private function, which computes the hash and asserts that it matches to what was provided in the L1->L2 message. This secret is included in the nullifier hash computation and the nullifier is added to the nullifier tree. Anyone inspecting the blockchain won’t know which nullifier hash corresponds to the L1->L2 message consumption.
112
74
113
-
Note: the secret hashes are Pedersen hashes since the hash has to be computed on L2, and sha256 hash is very expensive for zk circuits. The content hash however is a sha256 hash truncated to a field as clearly shown before.
75
+
:::note
76
+
Secret hashes are Pedersen hashes since the hash has to be computed on L2 and sha256 hash is very expensive for zk circuits. The content hash however is a sha256 hash truncated to a field as shown before.
77
+
:::
114
78
115
79
In the next step we will start writing our L2 smart contract to mint these tokens on L2.
Copy file name to clipboardexpand all lines: docs/docs/dev_docs/tutorials/token_portal/minting_on_aztec.md
+7-17
Original file line number
Diff line number
Diff line change
@@ -6,23 +6,18 @@ In this step we will start writing our Aztec.nr bridge smart contract and write
6
6
7
7
## Initial contract setup
8
8
9
-
In our `token-bridge`Noir project in `aztec-contracts`, under `src` there is an example `main.nr` file. Delete all the code in here and paste this to define imports and initialize the constructor:
9
+
In our `token-bridge`Aztec project in `aztec-contracts`, under `src` there is an example `main.nr` file. Paste this to define imports and initialize the constructor:
10
10
11
-
```rust
12
-
modutil;
13
-
#include_codetoken_bridge_imports/yarn-project/noir-contracts/src/contracts/token_bridge_contract/src/main.nr raw
The `claim_public` function enables anyone to consume the message on the user's behalf and mint tokens for them on L2. This is fine as the minting of tokens is done publicly anyway.
38
30
39
31
**What’s happening here?**
@@ -55,9 +47,7 @@ Now we will create a function to mint the amount privately. Paste this into your
The `get_mint_private_content_hash` function is imported from the `token_portal_content_hash_lib`.
61
51
62
52
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.
For this to work we import the `get_withdraw_content_hash` helper function from the `token_portal_content_hash_lib`.
16
14
17
15
**What’s happening here?**
18
16
@@ -53,6 +51,16 @@ We also use a `_withCaller` parameter to determine the appropriate party that ca
53
51
54
52
We call this pattern _designed caller_ which enables a new paradigm **where we can construct other such portals that talk to the token portal and therefore create more seamless crosschain legos** between L1 and L2.
55
53
54
+
Before we can compile and use the contract, we need to add two additional functions.
55
+
56
+
We need a function that let's us read the token value.
0 commit comments