Skip to content

Commit

Permalink
chore(docs): Add redirects (#6581)
Browse files Browse the repository at this point in the history
This PR adds some catch all redirects to avoid getting 404s. It also
cleans up a few pages for when a user clicks a dropdown.
  • Loading branch information
critesjosh authored May 22, 2024
1 parent f44d567 commit 432cec0
Show file tree
Hide file tree
Showing 9 changed files with 151 additions and 349 deletions.
7 changes: 4 additions & 3 deletions docs/docs/aztec/concepts/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,14 +2,14 @@
title: Concepts
---

import Image from '@theme/IdealImage';
import DocCardList from '@theme/DocCardList';
import Image from "@theme/IdealImage";
import DocCardList from "@theme/DocCardList";

This page outlines Aztec's fundamental technical concepts.

## Aztec Overview

<Image img={require('/img/aztec_high_level_network_architecture.svg')} />
<Image img={require("/img/aztec_high_level_network_architecture.png")} />

1. A user interacts with Aztec through Aztec.js (like web3js or ethersjs) or Aztec CLI
2. Private functions are executed in the PXE, which is client-side
Expand Down Expand Up @@ -52,6 +52,7 @@ Aztec allows private communications with Ethereum - ie no-one knows where the tr
This is achieved through portals - these are smart contracts deployed on an EVM that are related to the Ethereum smart contract you want to interact with.

Learn more about portals [here](/protocol-specs/l1-smart-contracts/index.md).

## Circuits

Aztec operates on three types of circuits:
Expand Down
2 changes: 2 additions & 0 deletions docs/docs/aztec/roadmap/features_initial_ldt.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,8 @@ sidebar_position: 0

The Aztec Sandbox is intended to provide developers with a lightweight and fast local node, running alongside a PXE.

You can learn more about running the Sandbox [here](../../reference/sandbox_reference/sandbox-reference.md).

Developers should be able to quickly spin up local, emulated instances of an Ethereum blockchain and an Aztec encrypted rollup, and start deploying private contracts and submitting private txs.

The sandbox allows developers to:
Expand Down
6 changes: 3 additions & 3 deletions docs/docs/guides/smart_contracts/writing_contracts/index.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: Portals
title: Writing Contracts
---

A portal is a point of contact between L1 and a contract on Aztec. For applications such as token bridges, this is the point where the tokens are held on L1 while used in L2.
import DocCardList from "@theme/DocCardList";

As outlined in [Communication](/protocol-specs/l1-smart-contracts/index.md), an Aztec L2 contract does not have to be linked to a portal contract, but can specify an intended portal in storage. Note, that a portal doesn't actually need to be a contract, it could be any address on L1.
<DocCardList />
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
title: Defining Storage
title: Declaring Storage
---

On this page, you will learn how to define storage in your smart contract.
Expand Down
52 changes: 0 additions & 52 deletions docs/docs/reference/sandbox_reference/sandbox-reference.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,58 +8,6 @@ For a quick start, follow the [guide](/getting_started.md) to install the sandbo

:::

## Manual Install


You can manually install the sandbox via the underlying script used in the [Aztec Boxes](/getting_started.md#run-the-npx-script).

### Prerequisites

- Node.js >= v18 (recommend installing with [nvm](https://github.com/nvm-sh/nvm))
- Docker (visit [this page of the Docker docs](https://docs.docker.com/get-docker/) on how to install it)

### Install the sandbox

To install the latest Sandbox version, run:

```bash
bash -i <(curl -s install.aztec.network)
```

This will install the following tools:

- **aztec** - launches various infrastructure subsystems (sequencer, prover, pxe, etc).
- **aztec-nargo** - aztec's build of nargo, the noir compiler toolchain.
- **aztec-sandbox** - a wrapper around docker-compose that launches services needed for sandbox testing.
- **aztec-up** - a tool to upgrade the aztec toolchain to the latest, or specific versions.
- **aztec-builder** - A useful tool for projects to generate ABIs and update their dependencies.

Once these have been installed, to start the sandbox, run:

```bash
aztec-sandbox
```

### Have fun!

**Congratulations, you have just installed and run the Aztec Sandbox!**

```bash
/\ | |
/ \ ___| |_ ___ ___
/ /\ \ |_ / __/ _ \/ __|
/ ____ \ / /| || __/ (__
/_/___ \_\/___|\__\___|\___|

```
In the terminal, you will see some logs:
1. Sandbox version
2. Contract addresses of rollup contracts
3. PXE (private execution environment) setup logs
4. Initial accounts that are shipped with the sandbox and can be used in tests
## Manual Install

You can manually install the sandbox via the underlying script used in the [Aztec Boxes](getting_started.md#run-the-npx-script).
Expand Down
109 changes: 109 additions & 0 deletions docs/docs/reference/smart_contract_reference/contract_artifact.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,109 @@
---
title: "Contract Artifact Reference"
---

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 artifact file can be used with `aztec.js` to instantiate contract objects and interact with them.

## Contract Artifact Structure

The structure of a contract artifact is as follows:
```json
{
"name": "CardGame",
"functions": [
{
"name": "constructor",
"functionType": "private",
"isInternal": false,
"parameters": [],
"returnTypes": [],
"bytecode": "...",
"verificationKey": "..."
},
{
"name": "on_card_played",
"functionType": "public",
"isInternal": true,
"parameters": [
{
"name": "game",
"type": {
"kind": "integer",
"sign": "unsigned",
"width": 32
},
"visibility": "private"
},
{
"name": "player",
"type": {
"kind": "field"
},
"visibility": "private"
},
{
"name": "card_as_field",
"type": {
"kind": "field"
},
"visibility": "private"
}
],
"returnTypes": [
...
],
"bytecode": "...",
"verificationKey": "..."
},
...
]
}

```

### `name`
It is a simple string that matches the name that the contract developer used for this contract in noir. It's used for logs and errors.

### `functions`
A contract is a collection of several functions that can be called. Each function has the following properties:

#### `function.name`
A simple string that matches the name that the contract developer used for this function in noir. For logging and debugging purposes.

#### `function.functionType`
The function type can have one of the following values:

- Private: The function is ran and proved locally by the clients, and its bytecode not published to the network.
- Public: The function is ran and proved by the sequencer, and its bytecode is published to the network.
- Unconstrained: The function is ran locally by the clients to generate digested information useful for the user. It's not meant to be transacted against.

#### `function.isInternal`
The is internal property is a boolean that indicates whether the function is internal to the contract and cannot be called from outside.

#### `function.parameters`
Each function can have multiple parameters that are arguments to execute the function. Parameters have a name, and type (like integers, strings, or complex types like arrays and structures).

#### `function.returnTypes`
The return types property defines the types of values that the function returns after execution.

#### `function.bytecode`
The bytecode is a string representing the compiled ACIR of the function, ready for execution on the network.

#### `function.verificationKey`
The verification key is an optional property that contains the verification key of the function. This key is used to verify the proof of the function execution.

### `debug` (Optional)
Although not significant for non-developer users, it is worth mentioning that there is a debug section in the contract artifact which helps contract developers to debug and test their contracts. This section mainly contains debug symbols and file maps that link back to the original source code.

## Understanding Parameter and Return Types
To make the most of the functions, it's essential to understand the types of parameters and return values. Here are some common types you might encounter:

- `field`: A basic type representing a field element in the finite field of the curve used in the Aztec protocol.
- `boolean`: A simple true/false value.
- `integer`: Represents whole numbers. It has attributes defining its sign (positive or negative) and width (the number of bits representing the integer).
- `array`: Represents a collection of elements, all of the same type. It has attributes defining its length and the type of elements it holds.
- `string`: Represents a sequence of characters with a specified length.
- `struct`: A complex type representing a structure with various fields, each having a specific type and name.

108 changes: 3 additions & 105 deletions docs/docs/reference/smart_contract_reference/index.md
Original file line number Diff line number Diff line change
@@ -1,109 +1,7 @@
---
title: "Contract Artifact Reference"
title: Smart Contract Reference
---

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 artifact file can be used with `aztec.js` to instantiate contract objects and interact with them.

## Contract Artifact Structure

The structure of a contract artifact is as follows:
```json
{
"name": "CardGame",
"functions": [
{
"name": "constructor",
"functionType": "private",
"isInternal": false,
"parameters": [],
"returnTypes": [],
"bytecode": "...",
"verificationKey": "..."
},
{
"name": "on_card_played",
"functionType": "public",
"isInternal": true,
"parameters": [
{
"name": "game",
"type": {
"kind": "integer",
"sign": "unsigned",
"width": 32
},
"visibility": "private"
},
{
"name": "player",
"type": {
"kind": "field"
},
"visibility": "private"
},
{
"name": "card_as_field",
"type": {
"kind": "field"
},
"visibility": "private"
}
],
"returnTypes": [
...
],
"bytecode": "...",
"verificationKey": "..."
},
...
]
}

```

### `name`
It is a simple string that matches the name that the contract developer used for this contract in noir. It's used for logs and errors.

### `functions`
A contract is a collection of several functions that can be called. Each function has the following properties:

#### `function.name`
A simple string that matches the name that the contract developer used for this function in noir. For logging and debugging purposes.

#### `function.functionType`
The function type can have one of the following values:

- Private: The function is ran and proved locally by the clients, and its bytecode not published to the network.
- Public: The function is ran and proved by the sequencer, and its bytecode is published to the network.
- Unconstrained: The function is ran locally by the clients to generate digested information useful for the user. It's not meant to be transacted against.

#### `function.isInternal`
The is internal property is a boolean that indicates whether the function is internal to the contract and cannot be called from outside.

#### `function.parameters`
Each function can have multiple parameters that are arguments to execute the function. Parameters have a name, and type (like integers, strings, or complex types like arrays and structures).

#### `function.returnTypes`
The return types property defines the types of values that the function returns after execution.

#### `function.bytecode`
The bytecode is a string representing the compiled ACIR of the function, ready for execution on the network.

#### `function.verificationKey`
The verification key is an optional property that contains the verification key of the function. This key is used to verify the proof of the function execution.

### `debug` (Optional)
Although not significant for non-developer users, it is worth mentioning that there is a debug section in the contract artifact which helps contract developers to debug and test their contracts. This section mainly contains debug symbols and file maps that link back to the original source code.

## Understanding Parameter and Return Types
To make the most of the functions, it's essential to understand the types of parameters and return values. Here are some common types you might encounter:

- `field`: A basic type representing a field element in the finite field of the curve used in the Aztec protocol.
- `boolean`: A simple true/false value.
- `integer`: Represents whole numbers. It has attributes defining its sign (positive or negative) and width (the number of bits representing the integer).
- `array`: Represents a collection of elements, all of the same type. It has attributes defining its length and the type of elements it holds.
- `string`: Represents a sequence of characters with a specified length.
- `struct`: A complex type representing a structure with various fields, each having a specific type and name.
import DocCardList from "@theme/DocCardList";

<DocCardList />
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"position": 0,
"collapsible": true,
"collapsed": true,
"label": "Smart Contract Reference"
"position": 0,
"collapsible": true,
"collapsed": true,
"label": "Storage"
}
Loading

0 comments on commit 432cec0

Please sign in to comment.