|
| 1 | +import React from "react"; |
| 2 | + |
| 3 | +export const Glossary = { |
| 4 | + Tools: { |
| 5 | + aztec: () => ( |
| 6 | + <p> |
| 7 | + The CLI tool (with an extensive set of parameters) that enables users to |
| 8 | + perform a wide range of tasks. It can: run a node, run a sandbox, |
| 9 | + execute tests, generate contract interfaces for javascript... |
| 10 | + </p> |
| 11 | + ), |
| 12 | + aztec_nargo: () => ( |
| 13 | + <p> |
| 14 | + The command line tool used to compile Aztec contracts. It is a specific |
| 15 | + version of <code>nargo</code>, with additional transpiler for turning a |
| 16 | + contract's public function code from Noir brillig bytecode into Aztec |
| 17 | + Virtual Machine (AVM) bytecode. |
| 18 | + </p> |
| 19 | + ), |
| 20 | + aztec_up: () => ( |
| 21 | + <p> |
| 22 | + This tool updates the local aztec executables to the latest version |
| 23 | + (default behaviour) or to a specified version. |
| 24 | + </p> |
| 25 | + ), |
| 26 | + aztec_wallet: () => ( |
| 27 | + <p> |
| 28 | + The Aztec Wallet is a CLI wallet, <code>aztec-wallet</code>, that allows |
| 29 | + a user to manage accounts and interact with an Aztec network. It |
| 30 | + includes a PXE. |
| 31 | + </p> |
| 32 | + ), |
| 33 | + }, |
| 34 | + |
| 35 | + Libs: { |
| 36 | + aztec_nr: () => ( |
| 37 | + <p> |
| 38 | + A <a href="https://noir-lang.org">Noir</a> framework for writing smart |
| 39 | + contracts on Aztec. |
| 40 | + </p> |
| 41 | + ), |
| 42 | + noir_contracts: () => ( |
| 43 | + <p> |
| 44 | + Programs that run on the Aztec network, written in the Noir programming |
| 45 | + language. They may optionally include private state and private |
| 46 | + functions. |
| 47 | + </p> |
| 48 | + ), |
| 49 | + aztec_js: () => ( |
| 50 | + <p> |
| 51 | + A{" "} |
| 52 | + <a href="https://www.npmjs.com/package/@aztec/aztec.js">Node package</a>{" "} |
| 53 | + to help make Aztec dApps. |
| 54 | + </p> |
| 55 | + ), |
| 56 | + }, |
| 57 | + |
| 58 | + Noir: () => ( |
| 59 | + <p> |
| 60 | + Noir is a Domain Specific Language for SNARK proving systems. It is used |
| 61 | + for writing smart contracts in Aztec because private functions on Aztec |
| 62 | + are implemented as SNARKs to support privacy-preserving operations. |
| 63 | + </p> |
| 64 | + ), |
| 65 | + |
| 66 | + PXE: () => ( |
| 67 | + <p> |
| 68 | + A client-side key manager, private contract storage, and Private eXecution |
| 69 | + Environment for private transactions. A PXE is a core part of an Aztec |
| 70 | + wallet and Sandbox, but can be decoupled and run independently. |
| 71 | + </p> |
| 72 | + ), |
| 73 | + |
| 74 | + AztecNode: () => ( |
| 75 | + <p> |
| 76 | + A prover/sequencer that is part of a decentralised Aztec network. The |
| 77 | + Aztec testnet rolls up to Ethereum Sepolia. |
| 78 | + </p> |
| 79 | + ), |
| 80 | + |
| 81 | + AztecSandbox: () => ( |
| 82 | + <p> |
| 83 | + The Aztec Sandbox runs a set of Aztec tools for convenient local |
| 84 | + development, it includes: an Ethereum node, an Aztec node, and PXE. |
| 85 | + </p> |
| 86 | + ), |
| 87 | + |
| 88 | + Account: () => ( |
| 89 | + <p> |
| 90 | + An account on Aztec is a smart contract that specifies a method of |
| 91 | + authentication and a method of payment, allowing it to be used by the |
| 92 | + protocol to perform a transaction. |
| 93 | + </p> |
| 94 | + ), |
| 95 | + |
| 96 | + TXE: () => ( |
| 97 | + <p> |
| 98 | + TXE stands for Test eXecution Environment. It enables rapid Aztec contract |
| 99 | + development by using "cheatcodes" in the Aztec Sandbox that manipulate |
| 100 | + state. For convenience, similar "cheatcodes" to manipulate Anvil's EVM |
| 101 | + state are wrapped. |
| 102 | + </p> |
| 103 | + ), |
| 104 | + |
| 105 | + Barretenberg: () => ( |
| 106 | + <p> |
| 107 | + Aztec's cryptography back-end. Refer to the graphic at the top of{" "} |
| 108 | + <a href="https://medium.com/aztec-protocol/explaining-the-network-in-aztec-network-166862b3ef7d"> |
| 109 | + this page |
| 110 | + </a>{" "} |
| 111 | + to see how it fits in the Aztec architecture. |
| 112 | + <br /> |
| 113 | + <br /> |
| 114 | + Barretenberg's source code can be found{" "} |
| 115 | + <a href="https://github.com/AztecProtocol/barretenberg">here</a>. |
| 116 | + </p> |
| 117 | + ), |
| 118 | +}; |
| 119 | + |
| 120 | +export const Fees = { |
| 121 | + FPC: () => ( |
| 122 | + <p> |
| 123 | + A fee paying contract (FPC) effectively implements fee abstraction. It is |
| 124 | + a contract that pays for transactions of other accounts, when its own |
| 125 | + custom criteria is met. |
| 126 | + </p> |
| 127 | + ), |
| 128 | + |
| 129 | + FeeAsset_NonTransferrable: () => ( |
| 130 | + <p> |
| 131 | + The fee asset is only transferrable within a block to the current |
| 132 | + sequencer, as it powers the fee abstraction mechanism on Aztec. The asset |
| 133 | + is not transferable beyond this to ensure credible neutrality between all |
| 134 | + third party developer made asset portals and to ensure local compliance |
| 135 | + rules can be followed. |
| 136 | + </p> |
| 137 | + ), |
| 138 | +}; |
| 139 | + |
| 140 | +export const Tx_Teardown_Phase = () => ( |
| 141 | + <p> |
| 142 | + Transactions can optionally have a "teardown" phase as part of their public |
| 143 | + execution, during which the "transaction fee" is available to public |
| 144 | + functions. This is useful to transactions/contracts that need to compute a |
| 145 | + "refund", e.g. contracts that facilitate fee abstraction. |
| 146 | + </p> |
| 147 | +); |
| 148 | + |
| 149 | +export const CLI_Add_Test_Accounts = () => ( |
| 150 | + <p> |
| 151 | + For convenience, the sandbox comes with 3 initial accounts that are |
| 152 | + prefunded, helping bootstrap payment of any transaction. To use them, you |
| 153 | + will need to add them to your pxe/wallet. |
| 154 | + </p> |
| 155 | +); |
| 156 | + |
| 157 | +export const Why_Fees = () => ( |
| 158 | + <p> |
| 159 | + Fees are an integral part of any protocol's design. Proper fee pricing |
| 160 | + contributes to the longevity and security of a network, and the fee payment |
| 161 | + mechanisms available inform the types of applications that can be built. |
| 162 | + </p> |
| 163 | +); |
| 164 | + |
| 165 | +export const CLI_Fees = () => ( |
| 166 | + <p> |
| 167 | + The CLI tool <code>aztec-wallet</code> takes the fee payment method via the |
| 168 | + param: <code>--payment method=fee_juice</code>. See help for sending txs, eg{" "} |
| 169 | + <code>aztec-wallet help deploy</code> |
| 170 | + </p> |
| 171 | +); |
| 172 | + |
| 173 | +export const Gas_Settings = () => ( |
| 174 | + <p> |
| 175 | + <code>Gas Settings</code> used in transactions specify gas limits and |
| 176 | + maximum fee rates (fees-per-gas) |
| 177 | + </p> |
| 178 | +); |
| 179 | + |
| 180 | +export const Gas_Settings_Components = () => ( |
| 181 | + <p> |
| 182 | + The <code>Gas</code> and <code>GasFees</code> types each specify Data |
| 183 | + availability and L2 cost components, so the settings are: |
| 184 | + <ul> |
| 185 | + <li>gasLimits: DA and L2 gas limits</li> |
| 186 | + <li> |
| 187 | + teardownGasLimits: DA and L2 gas limits for a txs optional teardown |
| 188 | + operation |
| 189 | + </li> |
| 190 | + <li>maxFeesPerGas: maximum DA and L2 fees-per-gas</li> |
| 191 | + <li>maxPriorityFeesPerGas: maximum priority DA and L2 fees-per-gas</li> |
| 192 | + </ul> |
| 193 | + </p> |
| 194 | +); |
| 195 | + |
| 196 | +export const Spec_Placeholder = () => ( |
| 197 | + <p> |
| 198 | + The design and implementation have largely changed since the original |
| 199 | + specification, and these docs will soon be updated to reflect the latest |
| 200 | + implementation. |
| 201 | + </p> |
| 202 | +); |
0 commit comments