28 docs tagged with "contracts"

All Aztec macros

This section contains some errors that you may encounter when writing and compiling contracts in Aztec.nr. If you run into an error that is not listed here, please create an issue (GitHub link).

A contract is a collection of persistent state variables and functions which may manipulate these variables.

Is this your first time hearing the word Portal? You might want to check out the protocol specs.

After compiling a contract you'll get a Contract Artifact file, that contains the data needed to interact with a specific contract, including its name, functions that can be executed, and the interface and code of those functions. Since private functions are not published in the Aztec network, you'll need this artifact file to be able to call private functions of contracts.

The latest information about contract deployment has moved to the protocol specification. You can find it here.

A contract is a collection of persistent state varibles and functions which may manipulate these variables. Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state. If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called.

On this page, you will learn how to define storage in your smart contract.

This page explains how to write an initializer function, also known as a constructor.

Events in Aztec work similarly to Ethereum events in the sense that they are a way for contracts to communicate with the outside world.

Once you have written a contract in Aztec.nr, you will need to compile it into an artifact in order to use it.

This guide explains how to deploy a smart contract using Aztec.js.

Once you have compiled your contracts you can proceed to deploying them using aztec.js which is a Typescript client to interact with the sandbox.

On this page you will find information about Aztec.nr libraries and up-to-date paths for use in your Nargo.toml.

The Inbox is a contract deployed on L1 that handles message passing from L1 to the rollup (L2)

Notes are the fundamental data structure in Aztec when working with private state. In this section there are guides about how to work with AddressNote, ValueNote, and custom notes in Aztec.nr. You can learn more about notes in the concepts section.

The Outbox is a contract deployed on L1 that handles message passing from the rollup and to L1.

An Aztec transaction typically consists of a private and a public part. The private part is where the user executes contract logic within the PXE and generates a proof of execution, which is then sent to the sequencer.

The registry is a contract deployed on L1, that contains addresses for the Rollup. It also keeps track of the different versions that have been deployed and let you query prior deployments easily.

Smart contracts in Aztec are privacy-first, and can include both public and private elements. They are written in Noir framework called Aztec.nr, and allow high-level programs to be converted into ZK circuits.

From the description of storage slots in the Concepts you will get an idea around the logic of storage slots. In this section we will go into more detail and walk through an entire example of how storage slots are computed for private state to improve our storage slot intuition. Recall, that storage slots in the private domain is just a logical construct, and are not "actually" used for lookups, but rather just as a value to constrain against.

In this guide we will cover how to interact with your Aztec.nr smart contracts in a testing environment to write automated tests for your apps.

Aztec contracts can be tested in a variety of ways depending on the needs of a particular application and the complexity of the interactions they must support.

Address notes hold one main property of the type AztecAddress. It also holds npkmhash and randomness, similar to other note types.

It may be useful to write a custom note type if you want to use a specific type of private data or struct that does not have a default implementation in Aztec.nr. If you create a note that uses a custom note type, you are able to nullify that note with one nullifier. This is more secure and less expensive than using multiple separate notes.

The Aztec Protocol uses an append-only Merkle tree to store hashes of the headers of all previous blocks in the chain as its leaves. This is known as the Archive tree. You can learn more about how it works in the concepts section.

ValueNotes hold one main property - a value - and have utils useful for manipulating this value, such as incrementing and decrementing it similarly to an integer.

Core knowledge of Notes and how they work