docs: Update welcome page and dev pages (AztecProtocol#4143)

This PR adds clearer entry points to the docs homepage so people have a
better idea of where to go. It incorporates the thinking behind the
Solidity Dev and Aztec Dev personas
([mindmap](https://www.mindmeister.com/app/map/3110603953?t=oWDwlsESBd)),
but doesn't explicit say "Solidity devs go here" or "Aztec devs go
here".

Adds a higher level introduction to the main Foundational Concepts page,
related to issue 3715 linked below.

Removes the History of blockchain privacy page.

This is not meant to be a final version, merely an incremental
improvement on what we currently have.

closes: AztecProtocol#3715  AztecProtocol#2652
closes: AztecProtocol/dev-rel#112

docs/docs/about_aztec/overview.mdx

@@ -10,17 +10,15 @@ Aztec is an L2 that brings programmable privacy to Ethereum.
 
 A smart contract on Aztec is a collection of functions, written as ZK-SNARK circuits. These circuits can have different modes of execution:
 
-1. Secret Functions -- can read and write private state, read historical public state, consume or send messages to / from Ethereum, and read Ethereum state. They can call other secret functions in the same contract, or other contracts, and can call public functions.
+1. Private Functions -- can read and write private state, read historical public state, consume or send messages to / from Ethereum, and read Ethereum state. They can call other private functions in the same contract, or other contracts, and can call public functions.
 2. Public Functions -- can read and write public state, write private state, consume or send messages to / from Ethereum and read Ethereum state. They can call other public functions on the same or other contracts.
 3. Portal Contracts -- these are contracts on Ethereum that can receive messages from Aztec or send messages to Aztec from Ethereum contracts.
 
 Using these different modes of execution, developers can build applications with user privacy, data privacy and code privacy.
 
-User privacy -- transactions may not reveal information about the sender or the recipient.
-
-Data privacy -- transactions may not reveal information about the payload of the transaction, e.g., the asset or value being transacted.
-
-Code privacy -- transactions may not reveal the program logic.
+- User privacy - transactions may not reveal information about the sender or the recipient.
+- Data privacy - transactions may not reveal information about the payload of the transaction, e.g., the asset or value being transacted.
+- Code privacy - transactions may not reveal the program logic.
 
 Watch Zac, CEO of Aztec, describe our approach to building a privacy preserving smart contract blockchain.
 

docs/docs/concepts/foundation/main.md

@@ -2,15 +2,31 @@
 title: Foundational Concepts
 ---
 
-As a layer 2 rollup on Ethereum, the Aztec network includes components that look similar to other layer 2 networks, but since it handles private state it also includes many new components.
+Aztec Labs is building a layer 2 rollup on Ethereum focused on 3 things:
 
-On this page we will introduce the high level network architecture for Aztec with an emphasis on the concepts that are core to understanding Aztec, including:
+- Data privacy
+- Confidentiality
+- Trustlessness
 
-- [The state model](./state_model/main.md)
-- [Accounts](./accounts/main.md)
-- [Aztec Smart Contracts](./contracts.md)
-- [Transactions](./transactions.md)
-- [Communication between network components](./communication/main.md)
+## Data privacy
+
+Data privacy refers to the ability of Aztec smart contract to have private (encrypted) state. Aztec abstracts away many of the complexities associated with managing private state, providing developers with an interface that feels familiar, but is much more powerful.
+
+<!-- Discuss UTXOs, Notes, note tree, nullifier tree? -->
+
+## Confidentiality
+
+Confidentiality is the ability of Aztec smart contracts to execute private functions and transactions. Aztec provides a secure, private environment for the execution of sensitive operations, ensuring private information and decrypted data are not accessible to unauthorized applications.
+
+When a user sends a private transaction on the network, the only information that an external observer can infer is that a transaction was sent. Transaction data, the sender, and the recipient can all be obfuscated.
+
+Aztec achieved this level of privacy by leveraging a Private eXecution Environment (PXE). This software runs client-side, for example in a browser, and is responsible for managing private keys, encrypting and decrypting data, and executing private functions. The PXE is also responsible for generating proofs of private function execution, which are then sent to the sequencer for inclusion in the rollup.
+
+## Trustlessness
+
+Aztec is building a permissionless, censorship resistant, peer-to-peer network. It aims to be credibly neutral, where the same transparent rules apply to everyone, enforced by the protocol.
+
+Aztec will have a network of sequencers that stake tokens to participate in the network. Sequencers are responsible for aggregating transactions into a block, generating proofs of the state updates (or delegating proof generation to the prover network) and posting it to the rollup contract on Ethereum, along with any required public data for data availability.
 
 ## High level network architecture
 
@@ -34,15 +50,8 @@ The sequencer aggregates transactions into a block, generates proofs of the stat
 
 ## Further Reading
 
-Here are links to pages with more information about the network components mentioned above:
-
-- Aztec.js
-  - [Dapp tutorial](../../dev_docs/tutorials/writing_dapp/main.md)
-  - [API reference](../../apis/aztec-js)
-- Private Execution Environment (PXE)
-  - [Dapp tutorial](../../dev_docs/tutorials/writing_dapp/pxe_service.md)
-  - [API reference](../../apis/pxe/index.md)
-- [Private Kernel Circuit](../advanced/circuits/kernels/private_kernel.md)
-- [Sequencer](./nodes_clients/sequencer.md)
-- Prover Network (coming soon<sup>tm</sup>)
-- [Rollup Circuit](../advanced/circuits/rollup_circuits/main.md) -- a component of the rollup contract
+- [The state model](./state_model/main.md)
+- [Accounts](./accounts/main.md)
+- [Aztec Smart Contracts](./contracts.md)
+- [Transactions](./transactions.md)
+- [Communication between network components](./communication/main.md)

docs/docs/dev_docs/getting_started/core-concepts.md

@@ -4,18 +4,19 @@ title: Core Concepts
 
 import Image from '@theme/IdealImage';
 
-This page outlines Aztec concepts that are essential for developers to understand. Reading and understanding these concepts will help you massively when you start to dive deeper into smart contracts.
+This page outlines Aztec concepts that are essential for developers to understand. Understanding these concepts will help you as you start to dive deeper into smart contracts.
 
 A little bit of time here can save a lot down the road.
 
-# Aztec Overview
+## Aztec Overview
 
-<Image img={require('/img/aztec_high_level_network_architecture.png')} />
+<Image img={require('/img/aztec_high_level_network_architecture.svg')} />
 
 To sum this up:
+
 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
-3. They are rolled up and sent to the Public VM
+3. They are rolled up and sent to the Public VM (running on an Aztec node)
 4. Public functions are executed in the Public VM
 5. The Public VM rolls up the private & public transaction rollups
 6. These rollups are submitted to Ethereum
@@ -24,73 +25,64 @@ To sum this up:
 
 The PXE is unaware of the Public VM. And the Public VM is unaware of the PXE. They are completely separate execution environments. This means:
 
-* The PXE and the Public VM cannot directly communicate with each other
-* Private transactions in the PXE are executed first, followed by public transactions
+- The PXE and the Public VM cannot directly communicate with each other
+- Private transactions in the PXE are executed first, followed by public transactions
 
 You can call a public function from a private function by using `context.call_public_function`, like this:
 
 #include_code call_public_function yarn-project/noir-contracts/contracts/card_game_contract/src/main.nr rust
 
-You cannot call a private function from a public function, but you can use a slow updates tree to read historical public state and stage writes to public state from a private function. 
+You cannot call a private function from a public function, but you can use a [slow updates tree](../contracts/syntax/slow_updates_tree.md) to read historical public state and stage writes to public state from a private function.
 
 ### Data types
 
-Private state works with UTXOs, or what we call notes. To keep things private, everything is stored in an append-only UTXO tree, and a nullifier is created when notes are spent.
+Private state works with UTXOs, or what we call notes. To keep things private, everything is stored in an [append-only UTXO tree](../../concepts/advanced/data_structures/trees.md#note-hash-tree), and a nullifier is created when notes are invalidated.
 
-Public state works similarly to other chains like Ethereum, behaving more like a public ledger. 
+Public state works similarly to other chains like Ethereum, behaving like a public ledger.
 
 Working with private state is like creating commitments and nullifiers to state, whereas working with public state is like directly updating state.
 
 We have abstractions for working with private state so you don't have to worry about these commitments and nullifiers. However, it is important to understand that the types and libraries you use will be different when working with private state and public state.
 
 For example, let's say you're trying to work with an integer. We have a library called `EasyPrivateUint` that acts like an integer but in the background is actually updating notes in private state. For the public side, we instead have something called `SafeU120`. You cannot use EasyPrivateUint in a public environment, and you cannot use SafeU120 in a private environment.
 
-# Storage
+## Storage
 
 Currently, when writing Aztec.nr smart contracts, you will need to define two things when initiating storage:
 
 1. The storage struct, ie what you are storing and their types
 2. A storage `impl` block with `init` function that will be called when you use the storage in a function
 
-The storage struct looks like this:
-
-#include_code storage_struct yarn-project/noir-contracts/contracts/token_contract/src/main.nr rust
-
-The storage impl block looks like this:
-
-#include_code storage_init yarn-project/noir-contracts/contracts/token_contract/src/main.nr rust
-
 The `init` function must declare the storage struct with an instantiation defining how variables are accessed and manipulated. Each variable must be given a storage slot, which can be anything except 0.
 
 The impl block is likely to be abstracted away at a later date.
 
 Learn more about how to use storage [here](../contracts/syntax/storage/main.md).
 
-# Portals
+## Portals
 
 Aztec allows you to interact with Ethereum privately - ie no-one knows where the transaction is coming from, just that it is coming from somewhere on Aztec.
 
 This is achieved through portals - these are smart contracts written in Solidity that are related to the Ethereum smart contract you want to interact with.
 
-A portal can be associated with multiple Aztec contracts, but an Aztec contract can only be associated with one portal. 
+A portal can be associated with multiple Aztec contracts, but an Aztec contract can only be associated with one portal.
 
 Learn more about how to work with portals [here](../contracts/portals/main.md).
 
-# Account Abstraction
+## Accounts
 
-Every account in Aztec is a smart contract. This allows implementing different schemes for transaction signing, nonce management, and fee payments.
+Every account in Aztec is a smart contract (account abstraction). This allows implementing different schemes for transaction signing, nonce management, and fee payments.
 
 You can write your own account contract to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed.
 
 Learn more about account contracts [here](../../concepts/foundation/accounts/main.md).
 
-# Noir Language
+## Noir Language
 
 Aztec smart contracts are written in a framework on top of Noir, the zero-knowledge domain-specific language developed specifically for Aztec. Its syntax is similar to Rust. Outside of Aztec, Noir is used for writing circuits that can be verified in Solidity.
 
 A cursory understanding of Noir is sufficient for writing Aztec contracts. The [Noir docs](https://noir-lang.org) will be a helpful reference when you start writing more advanced contracts.
 
-Now you're ready to dive into coding:
+## Next steps
 
-1. [Learn how to interact with a smart contract in Aztec.js](./aztecjs-getting-started.md)
-2. [Write your first Aztec smart contract](./aztecnr-getting-started.md)
+Continue through the getting started section by reviewing how to write a smart contract contract in [Getting started with Aztec.nr](./aztecnr-getting-started.md).

docs/docs/dev_docs/getting_started/main.md

@@ -2,13 +2,19 @@
 title: Getting Started
 ---
 
-In this section, you will
+## Build
+
+If this is your first time using Aztec, and you want to get started by learning by doing, head to the [Quickstart section](quickstart.md). This section is the entry point to:
 
 1. Set up the Aztec sandbox and deploy a sample first contract with the CLI
 2. Deploy and interact with a contract using Aztec.js
 3. Write your first smart contract in Aztec.nr
 
-The whole section should take you less than 60 minutes.
+## Learn
+
+If you want to read more about the high level concepts of Aztec before writing some code, head to the [Foundational Concepts section](../../concepts/foundation/main.md).
+
+## In this section
 
 import DocCardList from '@theme/DocCardList';
 

docs/docs/dev_docs/getting_started/quickstart.md

@@ -4,8 +4,8 @@ title: Quickstart
 
 In this guide, you will
 
-1. Set up the Aztec sandbox locally
-2. Install the Aztec CLI
+1. Set up the Aztec sandbox (local development environment) locally
+2. Install the Aztec development kit
 3. Use the CLI to deploy an example contract that comes with the sandbox
 4. Use the CLI to interact with the contract you just deployed
 
@@ -17,7 +17,7 @@ In this guide, you will
 
 ## Install Docker
 
-See this page of the Docker docs for instructions on how to install Docker Desktop for your operating system: [https://docs.docker.com/get-docker/](https://docs.docker.com/get-docker/)
+See [this page of the Docker docs](https://docs.docker.com/get-docker/) for instructions on how to install Docker Desktop for your operating system.
 
 Once you have Docker installed, make sure it is running by opening the Docker Desktop application.