Skip to content

Commit

Permalink
Merge branch 'main' into feature/hf-audit-recursion
Browse files Browse the repository at this point in the history
  • Loading branch information
ymekuria committed May 30, 2024
2 parents 6349f78 + 334ea90 commit d6b3bcb
Show file tree
Hide file tree
Showing 409 changed files with 11,274 additions and 37,247 deletions.
20 changes: 9 additions & 11 deletions docs/about-mina/faq.mdx
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: Mina FAQ
description: Frequently asked questions about Mina Protocol.
keywords:
keywords:
- mina faq
- mina language
- zkapp language
Expand All @@ -16,25 +16,21 @@ Answers to frequently asked questions about Mina Protocol.

### What language is Mina written in?

The Mina node is written in OCaml. You don't need to know OCaml to write smart contracts for Mina.
The Mina node is written in OCaml and Rust. You don't need to know OCaml/Rust to write smart contracts for Mina.

### What language are zkApp smart contracts written in?

Mina's zero knowledge smart contracts (zkApps) are written in TypeScript.

See [How to write a zkApp](/zkapps/how-to-write-a-zkapp).
See [How to write a zkApp](/zkapps/writing-a-zkapp/introduction-to-zkapps/how-to-write-a-zkapp).

### How large is the Mina Blockchain?

22 KB

### Given Mina is only 22 KB, where are past transactions stored?
### Where are past transactions stored?

A Mina node can run with an optional flag to make it an archive node to store historical transactions. Archive nodes are useful for anyone running a service, such as a block explorer. Still, this historical data is not required to verify the current consensus state of the protocol.

### What zero knowledge (zk) proof system does Mina use?

Mina Protocol uses a custom proof system called Kimchi, developed by [O(1) Labs](https://o1labs.org/). Mina is the only blockchain offering infinite recursion.
Mina Protocol uses a custom proof system called Kimchi, developed by [o1Labs](https://o1labs.org/). Mina is the only blockchain offering infinite recursion.

Check out the [Mina Book](https://o1-labs.github.io/proof-systems/plonk/overview.html) to learn more about Kimchi and the cryptography powering Mina Protocol.

Expand All @@ -50,8 +46,10 @@ Mina's consensus mechanism is an implementation of Ouroboros proof of stake. Due

Yes, check out these block explorers:

- https://minascan.io
- https://minataur.net
- [MinaScan](https://minascan.io/)
- [MinaSearch](https://minasearch.com/) (in development by Granola)
- [Minataur](https://minataur.net/)
- [Minaverse](https://minaverse.xyz/)

### How does Mina achieve scalability?

Expand Down
13 changes: 8 additions & 5 deletions docs/about-mina/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -16,11 +16,14 @@ Mina is an L1 blockchain based on zero knowledge proofs (ZKP) with smart contrac

## Why Mina?

Mina Protocol uses zero knowledge proofs to build a more ideal blockchain architecture.
The Mina Protocol is a native ZK blockchain, but what does this mean? The Mina Protocol is a layer 1 blockchain built to use zero knowledge proofs. The Mina Protocol uses zk-SNARKS.

Early blockchains, like Bitcoin and Ethereum, accumulate data over time and are currently hundreds of gigabytes in size. As time goes on, their blockchains will continue to increase in size. The entire chain history is required to verify the current consensus state of these networks.
Some advantages of this approach are:

With Mina, the blockchain always remains a constant size — about 22KB (the size of a few tweets). It's possible to verify the current consensus state of the protocol using this one recursive, 22KB zero knowledge proof. This means participants can quickly sync and verify the current consensus state of the network.
- A succinct blockchain that facilitates decentralization. The lightweight design allows a node to sync faster and reduces both storage and bandwidth requirements for [node operators](../node-operators).
- Zero knowledge proofs are used to secure the blockchain. Using recursive zk-SNARKs, the blockchain remains a constant size — about 22 KB.
Client-side code execution: zkApps run code on the client, helping to scale blockchain technology. Client-side code execution generates zk-SNARKS (proofs) to prove correct execution. Transactions send these proofs to the blockchain and are verified on-chain.
- Privacy by default, protect your data using zero knowledge proofs.

Learn more about Mina's unique [protocol architecture](about-mina/protocol-architecture).

Expand All @@ -32,9 +35,9 @@ Learn more in this video about [zero knowledge proofs](about-mina/what-are-zero-

## What are zkApps?

Mina's zero knowledge smart contracts are referred to as zkApps. zkApps provide powerful and unique characteristics such as unlimited off-chain execution, privacy for private data inputs that are never seen by the blockchain, the ability to write smart contracts in TypeScript, and more.
Mina's zero knowledge smart contracts, known as zkApps, offer distinct features, including off-chain proving, extensive off-chain execution capabilities, on-chain verification, privacy for confidential data (private inputs, by default, are not sent to the blockchain), the option to code smart contracts in TypeScript, and additional functionalities.

See [zkApps Overview](/zkapps).
See [zkApps Overview](/zkapps/writing-a-zkapp).

## How does consensus work on Mina?

Expand Down
2 changes: 1 addition & 1 deletion docs/about-mina/what-are-zero-knowledge-proofs.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,6 @@ import ResponsiveVideo from '@site/src/components/common/ResponsiveVideo';

Zero knowledge proofs keep Mina's blockchain light and your personal data private.

In this video, Brandon from <a href="https://o1labs.org/">O(1) Labs</a> explains what zero knowledge proofs are by comparing them to the game of "Where's Waldo?". Learn what zero knowledge proofs are, how they work, and their importance to Mina and the greater crypto community.
In this video, Brandon from <a href="https://o1labs.org/">o1Labs</a> explains what zero knowledge proofs are by comparing them to the game of "Where's Waldo?". Learn what zero knowledge proofs are, how they work, and their importance to Mina and the greater crypto community.

<ResponsiveVideo src="https://www.youtube.com/embed/GvwYJDzzI-g" />
82 changes: 82 additions & 0 deletions docs/berkeley-upgrade/appendix.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,82 @@
---
title: Appendix
sidebar_label: Appendix
hide_title: true
description: Berkeley Upgrade Appendix
keywords:
- Berkeley
- upgrade
- appendix
---

# Appendix

## Migration from o1labs/client-sdk to mina-signer

The signing library `o1labs/client-sdk` was deprecated some time ago and will stop working after the Mina mainnet upgrade. All users should upgrade to use the [mina-signer](https://www.npmjs.com/package/mina-signer) library.

Below you will find an example of how to use the `mina-signer` library. Please keep in mind the following:

1. Make sure to adjust the `nonce` to the correct nonce on the account you want to use as "sender"
1. Update the `url` variable with an existing Mina Node GraphQL endpoint

```javascript
import { Client } from 'mina-signer';

// create the client and define the keypair

const client = new Client({ network: 'testnet' }); // Mind the `network` client configuration option

const senderPrivateKey = 'EKFd1Gx...'; // Sender's private key
const senderPublicKey = 'B62qrDM...'; // Sender's public key, perhaps derived from the private key using `client.derivePublicKey(senderPrivateKey)`;

// define and sign payment

let payment = {
from: senderPublicKey,
to: 'B62qkBw...', // Recipient public key
amount: 100,
nonce: 1,
fee: 1000000,
};

const signedPayment = client.signPayment(payment, senderPrivateKey);

// send payment to graphql endpoint

const url = 'https://qanet.minaprotocol.network/graphql';

const sendPaymentMutationQuery = `
mutation SendPayment($input: SendPaymentInput!, $signature: SignatureInput!) {
sendPayment(input: $input, signature: $signature) {
payment {
hash
}
}
}
`;
const graphQlVariables = {
input: signedPayment.data,
signature: signedPayment.signature,
};
const body = JSON.stringify({
query: sendPaymentMutationQuery,
variables: graphQlVariables,
operationName: 'SendPayment',
});

const paymentResponse = await fetch(url, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body
});

const paymentResponseJson = await paymentResponse.json();
if (paymentResponse.ok) {
console.log(`Transaction hash: ${paymentResponseJson.data.sendPayment.payment.hash}`);
} else {
console.error(JSON.stringify(paymentResponseJson));
}


```
137 changes: 137 additions & 0 deletions docs/berkeley-upgrade/archive-migration/appendix.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,137 @@
---
title: Appendix
sidebar_label: Appendix
hide_title: true
description: archive node schema changes between Mainnet and Berkeley
keywords:
- Berkeley
- upgrade
- archive migration
- appendix
- mina archive node
- archive node
---

# Appendix

## Archive node schema changes

If you are using the Archive Node database directly for your system integrations, then you should understand all the changes that might impact your applications. The most important change is that the `balances` table in the Berkeley schema will no longer exist. In the new schema, it is replaced with the table `accounts_accessed` - from an application semantics point of view, the data in `accounts_accessed` is still the same.

In the Berkeley protocol, accounts can now have the same public key but a different token_id. This means accounts are identified by both their public key and token_id, not just the public key. Consequently, the foreign key for the account in all tables is account_identifier_id instead of public_key_id.

### Schema differences
- **Removed Types**
- The options `create_token`, `create_account`, and `mint_tokens` have been removed from the user_command_type enumeration.
- Indexes Dropped
- We've removed several indexes from tables, this may affect how you search and organize data:
- `idx_public_keys_id`
- `idx_public_keys_value`
- `idx_snarked_ledger_hashes_value`
- `idx_blocks_id`
- `idx_blocks_state_hash`
- **Table Removed**
- The `balances` table is no longer available.
- **New Tables Added**
- We've introduced the following new tables:
- `tokens`
- `token_symbols`
- `account_identifiers`
- `voting_for`
- `protocol_versions`
- `accounts_accessed`
- `accounts_created`
- `zkapp_commands`
- `blocks_zkapp_commands`
- `zkapp_field`
- `zkapp_field_array`
- `zkapp_states_nullable`
- `zkapp_states`
- `zkapp_action_states`
- `zkapp_events`
- `zkapp_verification_key_hashes`
- `zkapp_verification_keys`
- `zkapp_permissions`
- `zkapp_timing_info`
- `zkapp_uris`
- `zkapp_updates`
- `zkapp_balance_bounds`
- `zkapp_nonce_bounds`
- `zkapp_account_precondition`
- `zkapp_accounts`
- `zkapp_token_id_bounds`
- `zkapp_length_bounds`
- `zkapp_amount_bounds`
- `zkapp_global_slot_bounds`
- `zkapp_epoch_ledger`
- `zkapp_epoch_data`
- `zkapp_network_precondition`
- `zkapp_fee_payer_body`
- `zkapp_account_update_body`
- `zkapp_account_update`
- `zkapp_account_update_failures`
- **Updated Tables**
- The following tables have been updated
- `timing_info`
- `user_commands`
- `internal_commands`
- `epoch_data`
- `blocks`
- `blocks_user_commands`
- `blocks_internal_commands`

### Differences per table
- **`timing_info`**
- Removed columns:
- `token`
- `initial_balance`
- **`user_commands`**
- Removed columns:
- `fee_token`
- `token`
- **`internal_commands`**
- Removed columns:
- `token`
- Renamed column
- `command_type` to `type`
- **`epoch_data`**
- Added columns:
- `total_currency`
- `start_checkpoint`
- `lock_checkpoint`
- `epoch_length`
- **`blocks`**
- Added columns:
- `last_vrf_output`
- `min_window_density`
- `sub_window_densities`
- `total_currency`
- `global_slot_since_hard_fork`
- `global_slot_since_genesis`
- `protocol_version_id`
- `proposed_protocol_version_id`
- Removed column:
- `global_slot`
- **`blocks_user_commands`**
- Removed columns:
- `fee_payer_account_creation_fee_paid`
- `receiver_account_creation_fee_paid`
- `created_token`
- `fee_payer_balance`
- `source_balance`
- `receiver_balance`
- Added index:
- `idx_blocks_user_commands_sequence_no`
- **`blocks_internal_commands`**
- Removed columns:
- `receiver_account_creation_fee_paid`
- `receiver_balance`
- Added indexes:
- `idx_blocks_internal_commands_sequence_no`
- `idx_blocks_internal_commands_secondary_sequence_no`

### Rosetta API new operations

The Berkeley upgrade introduces two new operation types:
- `zkapp_fee_payer_dec`
- `zkapp_balance_change`
Loading

0 comments on commit d6b3bcb

Please sign in to comment.