Merge pull request #371 from laishawadhwa/master

Added documentation updates Phase 1 from Aleo Ambassadors

documentation updates aleo ambassadors/book.toml

@@ -0,0 +1,6 @@
+[book]
+title = "zero-to-zk"
+authors = ["Zk"]
+language = "en"
+multilingual = false
+src = "src"

documentation updates aleo ambassadors/src/SUMMARY.md

@@ -0,0 +1,77 @@
+# Summary
+
+- [Overview](./overview.md)
+- [LEARN](./learn/README.md)
+
+  - [Core Architecture](./learn/core-architecture.md)
+  - [Concepts](./learn/concepts/README.md)
+    - [Accounts](./learn/concepts/accounts.md)
+    - [Programs](./learn/concepts/programs/README.md)
+      - [Execution](./learn/concepts/programs/execution.md)
+      - [Deployment](./learn/concepts/programs/deployment.md)
+    - [Blocks](./learn/concepts/blocks.md)
+    - [Transactions](./learn/concepts/transactions.md)
+    - [Transitions](./learn/concepts/transitions.md)
+    - [Storage](./learn/concepts/storage.md)
+    - [Fee](./learn/concepts/fee.md)
+  - [zkCloud](./learn/zkcloud/README.md)
+    - [snarkOS](./learn/zkcloud/snarkos.md)
+    - [snarkVM](./learn/zkcloud/snarkvm.md)
+  - [Network](./learn/network/README.md)
+    - [Validators](./learn/network/validators.md)
+    - [Clients](./learn/network/clients.md)
+    - [Provers](./learn/network/provers.md)
+    - [Consensus](./learn/network/concensus.md)
+
+- [BUILD](./build/README.md)
+
+  - [Leo](./build/leo/README.md)
+
+    - [Overview](./build/leo/overview.md)
+    - [Installation](./build/installation/installation.md)
+    - [HelloLeo](./build/leo/helloleo.md)
+    - [Core Components](./build/leo/README.md)
+      - [Language](./build/leo/language.md)
+      - [Operators](./build/leo/operators.md)
+      - [Commands](./build/leo/commands.md)
+    - [Manage your Program](./build/leo/manage-your-program/README.md)
+      - [Compiling Programs](./build/leo/compiling-programs.md)
+      - [Deploying Programs](./build/leo/deploying-programs.md)
+      - [Executing Programs](./build/leo/executing-programs.md)
+    - [Resources](./build/leo/resources/README.md)
+      - [Tooling](./build/leo/resources/tooling.md)
+      - [Leo Playground](./build/leo/resources/leo-playground.md)
+      - [Leo Syntax Cheatsheet](./build/leo/resources/leo-syntax-cheatsheet.md)
+      - [Developer Resources](./build/leo/resources/developer-resources.md)
+    - [Aleo SDK](./build/leo/aleo-sdk/README.md)
+
+      - [Overview](./build/leo/aleo-sdk/overview.md)
+      - [Javascript/TypeScript](./build/leo/aleo-sdk/js-ts/README.md)
+
+        - [Guide](./build/leo/aleo-sdk/js-ts/guide.md)
+        - [Account](./build/leo/aleo-sdk/js-ts/account.md)
+        - [Aleo Network Client](./build/leo/aleo-sdk/js-ts/aleo-network-client.md)
+        - [Development Client](./build/leo/aleo-sdk/js-ts/development-client.md)
+
+      - [Create Aleo App](./build/leo/aleo-sdk/create-aleo-app/README.md)
+        - [Installation](./build/leo/aleo-sdk/create-aleo-app/installation.md)
+        - [React + JS + Leo Tutorial](./build/leo/aleo-sdk/create-aleo-app/react-js-leo-tutorial.md)
+      - [Wasm](./build/leo/aleo-sdk/wasm/README.md)
+
+        - [Installation](./build/leo/aleo-sdk/wasm/installation.md)
+        - [NodeJS + Browser](./build/leo/aleo-sdk/wasm/nodejs-browser.md)
+        - [Browser(Multi-Threaded)](./build/leo/aleo-sdk/wasm/browser-multi-threaded.md)
+
+      - [Python](./build/leo/aleo-sdk/python/README.md)
+        - [Aleo SDK](./build/leo/aleo-sdk/python/aleo-sdk.md)
+        - [zkML Transpiler](./build/leo/ale-sdk/python/zkml-transpiler.md)
+
+    - [Development Netowrk](./build/development-network/README.md)
+    - [snarkOS Node RPC](./build/snarkos-node-rpc/README.md)
+    - [Data and analytics](./build/data-and-analytics/README.md)
+
+  - [Advanced](./advanced/README.md)
+    - [InclusionProof](./advanced/inclusion-proof..md)
+    - [Dive into AVM](./advanced/dive-into-avm/README.md)
+      - [Circuit](./advanced/dive-into-avm/circuits-r1cs.md)
+      - [Aleo Account](./advanced/dive-into-avm/aleo-account-keys.md)

documentation updates aleo ambassadors/src/advanced/README.md

@@ -0,0 +1 @@
+# Advanced

documentation updates aleo ambassadors/src/advanced/dive-into-avm/README.md

@@ -0,0 +1,70 @@
+# Aleo’s Virtual Machine (AVM)
+
+The Aleo Virtual Machine (AVM) is a computational platform integral to the Aleo blockchain, designed to run privacy-focused applications. It operates as a stack machine that executes queued instructions. Its primary function is to construct arithmetic circuits described as Rank-1 Constraint System (R1CS), from each instruction in a function.
+
+After constructing the **R1CS**, corresponding proofs are generated using a variation of **Marlin** algorithm called **Varuna**. This approach allows for succinct verification of arbitrary computations by leveraging a **universal** and **updatable** Structured Reference String (**SRS**).
+
+It was formalised and implemented in the Aleo Network as [ARC-0002](https://github.com/AleoHQ/ARCs/tree/master/arc-0002).
+
+### **Key Features of the AVM**
+
+- **Privacy Preservation**: The AVM executes transactions and contracts while maintaining the confidentiality of the data involved. This is done using zk-SNARKs, which allow the verification of the correctness of computations without revealing the inputs or internal state.
+- **Deterministic Execution**: Like other blockchain virtual machines, the AVM ensures that contract execution is deterministic, meaning it produces the same output given the same initial state and inputs across all nodes.
+- **Scalability**: The use of zk-SNARKs also aids scalability. Since the computational load of verifying a zero-knowledge proof is less than repeatedly executing the computation, the AVM can handle more complex operations at a larger scale compared to traditional systems.
+
+## **AVM’s Architecture and Design**
+
+The AVM is virtual machine that operates on a last-in, first-out (LIFO) principle where data is stacked and the most recently added data is the first to be accessed or removed. This design is conducive to the execution of complex arithmetic circuits that are essential for the privacy-preserving features of Aleo. The AVM's architecture is designed to support the execution of private applications by leveraging zero-knowledge proofs. It uses Leo (high-level programming language), which compiles down into an intermediate representation known as AVM opcodes. These opcodes are then used to construct the R1CS, which are essential for generating zero-knowledge proofs. Check the full list [here](https://developer.aleo.org/aleo/opcodes/)
+
+The AVM architecture can be broken down into several key components and characteristics:
+
+### **Instruction Set Architecture (ISA)**
+
+The Instruction Set Architecture of the AVM is custom-designed to support operations required for zero-knowledge proofs, especially zk-SNARKs. This set of instructions is optimized to handle complex mathematical operations efficiently, such as those involving elliptic curves, which are crucial for creating and verifying zero-knowledge proofs.
+
+### **Execution Environment**
+
+The execution environment of the AVM provides the runtime in which smart contracts are executed. This environment is tightly controlled and deterministic, meaning that given the same initial state and inputs, the execution will always produce the same output. This determinism is essential for maintaining consensus across the blockchain network.
+
+### **Memory Management**
+
+AVM features a structured memory model to manage both transient and persistent data:
+
+- **Stack**: Used for temporary storage during the execution of instructions. This is typically where variables, temporary results, and stack frames (context for function calls) are stored.
+- **Heap**: For dynamic allocation of memory during execution, supporting more complex data structures necessary for advanced contract functionality.
+- **Storage**: This refers to the persistent state of contracts on the blockchain. Unlike stack and heap, storage data persists between transactions and is part of the blockchain's state.
+
+### **State Transition System**
+
+The state transition system in the AVM defines how the state of the blockchain changes in response to transactions:
+
+- **Transactions**: These are submitted by users and can include smart contract interactions or simple transfers. They change the state of the blockchain.
+- **State Transitions**: Each transaction processed by the AVM results in a state transition, updating the blockchain's global state according to predefined rules.
+- **Privacy Enforcement**: During state transitions, the AVM ensures that all operations uphold the privacy guarantees promised by zero-knowledge proofs. This means sensitive data remains encrypted, and only the validity of transactions is verified.
+
+A Merkle tree is used to represent the global state. One of the biggest challenges is to also include encrypted information in this global state.
+
+The transaction data is not stored directly but through encrypted transitions.
+
+![AVS Global State](./images/avs_global_state.png)
+Source: trapdoortech.com
+
+### **Smart Contract Compilation and Deployment**
+
+- **Leo Programming Language**: Smart contracts are written in Leo, a Domain Specific Language (DSL) designed for expressing the semantics of Aleo and zero-knowledge. Leo code is compiled into AVM bytecode.
+- **Bytecode Execution**: The compiled bytecode is what the AVM directly executes. This bytecode is optimized for the AVM's execution environment, ensuring efficient processing and privacy preservation.
+
+### **Networking and Consensus Layer Integration**
+
+Although not a direct part of the AVM, the virtual machine operates within the broader context of Aleo's network architecture:
+
+- **Block Propagation and Validation**: The AVM's execution outcomes influence block validation and propagation across the network.
+- **Consensus Mechanism**: The AVM interfaces with the blockchain's consensus mechanism by providing guarantees about the correctness of executed transactions through zero-knowledge proofs, thus facilitating a secure and verifiable agreement on the state of the ledger.
+
+![AVM Execution Flow](./images/avm_execution_flow_overview.png)
+
+### **Execution Flow**
+
+- **Compilation**: Developers write their contracts in Leo, which compiles into AVM bytecode.
+- **Deployment**: Bytecode is deployed to the Aleo network, where it is executed by the AVM.
+- **Execution**: When a contract is called, the AVM processes the bytecode, leveraging zk-SNARKs to maintain privacy. The outputs verify that the contract executed correctly without revealing any sensitive information.

documentation updates aleo ambassadors/src/advanced/dive-into-avm/aleo-account-keys.md

@@ -0,0 +1,25 @@
+# Aleo Account Key Generation
+
+An Aleo account is similar to accounts on other blockchain platforms but designed with a focus on privacy, leveraging cryptographic techniques unique to the platform. Here's a detailed breakdown of the components of an Aleo account and the processes involved in generating addresses, public keys, and private keys:
+
+## **Account Structure**
+
+- **Private Key**: This is the secret key that an account holder must protect. It is used to sign transactions and prove ownership of the account. In Aleo, the private key is typically a large random number.
+- **Public Key**: Derived from the private key using cryptographic algorithms, the public key is used to receive transactions. It is safe to share publicly as it does not expose the private key.
+- **Address**: The address is a user-friendly representation of the public key. It is what other users will use to send Aleo to your account. The address is usually derived from the public key through a series of cryptographic hash functions and encoding techniques, ensuring it is both unique and verifiable.
+
+## **Key Generation**
+
+Aleo generates private and public keys using elliptic curve cryptography (ECC) through a process that involves several key components and cryptographic principles. The core of this process is based on the properties of elliptic curves and the discrete logarithm problem, which provides the security foundation for the cryptographic operations. Here's a detailed explanation of how Aleo leverages elliptic curve cryptography for generating private and public keys:
+
+- **Private Key**: generated as a random scalar from a finite field defined by the elliptic curve. This key must remain secret and secure.
+- **View Key**: derived by multiplying the private key with the base point (a predefined point on the curve). This operation in ECC is non-invertible, which means you cannot derive the private key from the view key.
+- **Compute Key:** similarly to the view key, it’s derived from the private key. It can be used to delegate the execution of a transaction to a third party.
+- **Address:** derived from the compute key
+
+![Key Generation Flow](./images/aleo_key_generation.png)
+Source: trapdoortech.com
+
+### **Integration with Wallets and Applications**
+
+In practice, Aleo accounts are often managed through wallets, which automate many of the processes described above. Wallets provide user interfaces for generating keys, creating and signing transactions, and managing balances without needing deep technical knowledge of the underlying cryptographic processes.

documentation updates aleo ambassadors/src/advanced/dive-into-avm/circuits-r1cs.md

@@ -0,0 +1,31 @@
+# R1CS Circuits
+
+Aleo Virtual Machine leverages a type of intermediate representation for their circuits called “Rank-1 Constrained System” (R1CS). This format is used to express computations as a system of equations that can later be formally verified.
+
+## **Definition and Structure of R1CS**
+
+R1CS is essentially a set of linear equations over a field, structured to represent computational problems. Each constraint in an R1CS is an equation of the form:
+
+$$
+(a_0+a_1x_1+...+a_nx_n)(b_0+b_1y_1+...+b_my_m) = (c_0+c_1z_1+...+c_lz_l)
+$$
+
+Where $x_i, y_j, z_k$ are variables and $a_i,b_j,c_k$ are constant from the given field. These constraints are designed to ensure that if the variables satisfy the left side of the equations, they must also satisfy the right side. Check the **Schwartz-Zippel Lemma** more further details.
+
+## **R1CS flow in the AVM**
+
+### **Circuit Generation**
+
+1. **Leo** programs are compiled into “**Aleo instruction**s”: an assembly-like language that the AVM can understand.
+2. **Aleo Instructions** are compiled into R1CS circuit representation.
+3. **R1CS circuits** are exported and potentially deployed to the network.
+
+### **Proof Generation**
+
+Once a program is represented as an R1CS, Aleo uses this representation to generate zero-knowledge proofs. These proofs allow a prover (the one executing the program) to convince a verifier (Aleo’s verifier network of nodes) that they have correctly executed the logic included in the program without revealing the specific inputs or internal state of the computation.
+
+### **Verification**
+
+The verifier, who receives only the proof and the public outputs (if any), checks the proof against the R1CS circuit to ensure that the computation was performed correctly. This verification process does not require the verifier to know the specific details of the computation, thus maintaining privacy.
+
+---

documentation updates aleo ambassadors/src/advanced/inclusion-proof..md

@@ -0,0 +1,15 @@
+# Inclusion Proofs
+
+Inclusion proofs are like a special handshake or password that gets you past verifier without revealing the actual element. In Aleo, inclusion proofs are like digital receipts that verify transactions without compromising users' privacy.
+
+Inclusion proofs are a part of Merkle tree data structures, which are used in cryptographic systems to efficiently prove that a piece of data is part of a set of data. An inclusion proof, in this context, is a proof that a certain element is included in a set without revealing the entire set.
+
+In SnarkVM function `inclusion_proving_key()` returns the proving key for inclusion circuit and `inclusion_verifying_key()` returns the verifying key for inclusion circuit. As the name implies, the inclusion proving key is used to prove that a certain element is included in a set, while the inclusion verifying key is used to verify that the proof is correct.
+
+In Aleo, to execute a function, a user uses the synthesizer in a similar way as the deployment process. As such, the user will produce 𝑛+1 transition proofs if they wish to execute a function call that triggers 𝑛 nested calls. The synthesizer is run with the actual values (as opposed to random values) for the inputs as well as the different registers in the circuits.
+
+In addition to producing these proofs, a user also produces 𝑛+1 “inclusion proofs”. These inclusion proofs are used to prove that any record being used as input in the transition or function call indeed exists. Inclusion proofs prove that records exist either in some previous block that has been included in the blockchain, or in one of the previous transition outputs.
+
+An inclusion proof also publicly outputs the serial numbers (also called a nullifier in ZCash-like systems) that uniquely identify the records without leaking any information about them. This way, records cannot be consumed more than once. (In addition, the network enforces that no serial number is seen twice within the same transaction.)
+
+**Note:** All of these different proofs are eventually aggregated together into a single proof using Varuna’s batching capabilities.