Merge pull request #296 from 0xPolygonMiden/frisitano-precommit-sync

chore: run pre-comimt run --all-files

.pre-commit-config.yaml

@@ -36,7 +36,7 @@ repos:
       args: ["+stable", "check", "--all-targets", "--no-default-features"]
     - id: cargo
       name: Cargo check --all-targets --all-features
-      args: ["+stable", "check", "--all-targets", "--all-features"]
+      args: ["+stable", "check", "--all-targets", "--all-features","--workspace", "--exclude", "miden-mock"]
     # Unlike fmt, clippy will not be automatically applied
     - id: cargo
       name: Cargo clippy

Makefile

@@ -2,4 +2,4 @@ watch:
 	cargo watch -w miden-lib/asm -x build
 
 test:
-	cargo test --features testing
+	cargo test --features testing

docs/src/architecture.md

@@ -1,19 +1,19 @@
 # Architecture
-The Polygon Miden Architecture decribes the concepts of how the participants of the network can interact. 
+The Polygon Miden Architecture decribes the concepts of how the participants of the network can interact.
 
-The architecture reflects the design goals for the rollup: 
+The architecture reflects the design goals for the rollup:
 
-* **High throughput** 
+* **High throughput**
 * **Privacy**
 * **Asset Safety**
 
-On Miden, developers can build dApps currently infeasible anywhere else. 
+On Miden, developers can build dApps currently infeasible anywhere else.
 
-## Actor Model 
+## Actor Model
 The [Actor Model](https://en.wikipedia.org/wiki/Actor_model) inspires Miden to achieve concurrent and local state changes. Actors are little state machines with inboxes, meaning each actor is responsible for their state. Actors can send and receive messages to communicate with other actors. Messages can be read asynchronously.
 
 ## Concepts in Miden
-There are accounts and notes which can hold assets. Accounts consume and produce notes in transactions. Transactions are account state changes of single accounts. The state model captures all individual states of all accounts and notes. Finally, the execution model describes state progress in a sequence of blocks. 
+There are accounts and notes which can hold assets. Accounts consume and produce notes in transactions. Transactions are account state changes of single accounts. The state model captures all individual states of all accounts and notes. Finally, the execution model describes state progress in a sequence of blocks.
 
 ### Accounts
 Accounts can hold assets and define rules how those can be transferred. Accounts can represent users or autonomous smart contracts. This chapter describes the design, the storage types, and the creation of an account.
@@ -28,7 +28,7 @@ Assets can be fungible and non-fungible. They are stored in the owner’s accoun
 Transactions describe production or consumption of notes by a single account. For every transaction there is always a STARK proof in Miden. This chapter describes the transaction design and the different transaction modes.
 
 ### State Model
-State describes everything that is the case at a certain point in time. Individual state of accounts or notes can be stored onchain and offchain to provide privacy. This chapter describes the three different state databases in Miden. 
+State describes everything that is the case at a certain point in time. Individual state of accounts or notes can be stored onchain and offchain to provide privacy. This chapter describes the three different state databases in Miden.
 
 ### Execution Model
 Execution describes how the state progresses - on an individual level via transactions and at the global level expressed as aggregated state updates in blocks. This chapter describes the execution model and how blocks are built.

docs/src/architecture/accounts.md

@@ -34,9 +34,9 @@ In the above picture, you can see:
 *Note: Miden uses little-endian by default, but big_endian for better readability in the picture above.*
 
 ### Account Storage
-User-defined data that can be stored in an account. `AccountStorage` is composed of two components. 
+User-defined data that can be stored in an account. `AccountStorage` is composed of two components.
 
-The first component is a simple sparse Merkle tree of depth `8` which is index addressable. This provides the user with `256` `Word` slots. 
+The first component is a simple sparse Merkle tree of depth `8` which is index addressable. This provides the user with `256` `Word` slots.
 
 Users requiring additional storage can use the second component a `MerkleStore`. It allows users to store any Merkle structures they need. The root of the Merkle structure can be stored as a leaf in the simple sparse Merkle tree. When `AccountStorage` is serialized it will check to see if any of the leafs in the simple sparse Merkle tree are Merkle roots of other Merkle structures. If any Merkle roots are found then the Merkle structures will be persisted in the `AccountStorage` `MerkleStore`.
 
@@ -82,5 +82,5 @@ The process is as follows:
 Account data - stored by the Miden Node - can be public, private, or encrypted. The third and fourth most significant bits of the account ID specifies whether the account data is public `00`, encrypted `01`, or private `11`.
 
 * Accounts with **public state**, where the actual state is stored onchain. These would be similar to how accounts work in public blockchains. Smart contracts that depend on public shared state should be stored public on Miden, e.g., DEX contract.
-* Account with **encrypted state**, where the account data is stored onchain but in encrypted text. It provides liveness guarantee of the protocol for the account in question.  
-* Accounts with **private state**, where only the hash of the account is stored onchain. Users who want stay private and take care of their own data should choose this mode. The hash is defined as: `hash([account ID, 0, 0, nonce], [vault root], [storage root], [code root])`. 
+* Account with **encrypted state**, where the account data is stored onchain but in encrypted text. It provides liveness guarantee of the protocol for the account in question.
+* Accounts with **private state**, where only the hash of the account is stored onchain. Users who want stay private and take care of their own data should choose this mode. The hash is defined as: `hash([account ID, 0, 0, nonce], [vault root], [storage root], [code root])`.

docs/src/architecture/assets.md

@@ -1,22 +1,22 @@
 # Assets
-In Miden, users can create and trade arbitrary fungible and non-fungible assets. 
+In Miden, users can create and trade arbitrary fungible and non-fungible assets.
 
-We differentiate between native and non-native assets in Miden. Native assets follow the Miden asset model. Non-native assets are all other data structures of value that can be exchanged.   
+We differentiate between native and non-native assets in Miden. Native assets follow the Miden asset model. Non-native assets are all other data structures of value that can be exchanged.
 
 Recording of native assets in Polygon Miden suffices four goals:
 
-* Asset exchange should be parallelizable 
-* Asset ownership should be private 
+* Asset exchange should be parallelizable
+* Asset ownership should be private
 * Asset usage should be indeed censorship resistant
 * Fees can be paid using any asset
 
-All native assets in Miden are stored directly in accounts, like Ether in Ethereum. Miden does not track ownership of assets using global hashmaps, e.g., ERC20 contracts. Storage of assets locally in accounts provides privacy and the ability for client-side proofs. That is because ownership changes always involve only one account and not the change of a global hashmap. Thus, they can happen in parallel. Additionally, asset exchange is censorship resistant at this level because there is no global contract the transfer must pass through. Finally, users can pay fees in any asset. 
+All native assets in Miden are stored directly in accounts, like Ether in Ethereum. Miden does not track ownership of assets using global hashmaps, e.g., ERC20 contracts. Storage of assets locally in accounts provides privacy and the ability for client-side proofs. That is because ownership changes always involve only one account and not the change of a global hashmap. Thus, they can happen in parallel. Additionally, asset exchange is censorship resistant at this level because there is no global contract the transfer must pass through. Finally, users can pay fees in any asset.
 
 ## Native assets
-Native assets are data structures that follow the Miden asset model (encoding, issuance, storing). All native assets are encoded using a single `Word` (4 field elements). The asset encodes both the ID of the issuing account and the asset details. Having the issuer's ID encoded in the asset makes it cost-efficient to determine the type of an asset inside and outside Miden VM. And, representing the asset in a `Word` means the representation is always a commitment to the asset data itself. That is particularly interesting for non-fungible assets. 
+Native assets are data structures that follow the Miden asset model (encoding, issuance, storing). All native assets are encoded using a single `Word` (4 field elements). The asset encodes both the ID of the issuing account and the asset details. Having the issuer's ID encoded in the asset makes it cost-efficient to determine the type of an asset inside and outside Miden VM. And, representing the asset in a `Word` means the representation is always a commitment to the asset data itself. That is particularly interesting for non-fungible assets.
 
 ### Issuance
-Only specialized accounts called faucets can issue assets. Just like with regular accounts, anyone can create a faucet account. Faucets can issue only either fungible or non-fungible assets - but not both. The `faucet_id` identifies the faucet and is starts with a different sequence depending on the asset type, see [here](https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html#account-id). The faucet's code defines rules for how assets can be minted, who can mint them etc. Conceptually, faucet accounts on Miden are similar to ERC20 contracts on Ethereum. But, there is no ownership tracking in Miden faucets. 
+Only specialized accounts called faucets can issue assets. Just like with regular accounts, anyone can create a faucet account. Faucets can issue only either fungible or non-fungible assets - but not both. The `faucet_id` identifies the faucet and is starts with a different sequence depending on the asset type, see [here](https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html#account-id). The faucet's code defines rules for how assets can be minted, who can mint them etc. Conceptually, faucet accounts on Miden are similar to ERC20 contracts on Ethereum. But, there is no ownership tracking in Miden faucets.
 
 Faucets can create assets and immediately distribute them by producing notes. However, assets can also stay in the faucet after creation to be sent later, e.g., in a bundle. That way, one can mint a million NFTs locally in a single transaction and then send them out as needed in separate transactions in the future.
 
@@ -27,27 +27,27 @@ Faucets can create assets and immediately distribute them by producing notes. Ho
 ### Fungible assets
 A fungible asset is encoded using the amount and the `faucet_id` of the faucet which issued the asset. The amount is guaranteed to be  $2^{63} - 1$ or smaller, the maximum supply for any fungible asset. Examples of fungible assets are ETH and stablecoins, e.g., DAI, USDT, and USDC.
 
-If the `faucet_id` of MATIC were to be `2`, 100 MATIC are encoded as `[100, 0, 0, 2]` - whereas the `0`s in the middle help to quickly distinguish between fungible and non-fungible assets. 
+If the `faucet_id` of MATIC were to be `2`, 100 MATIC are encoded as `[100, 0, 0, 2]` - whereas the `0`s in the middle help to quickly distinguish between fungible and non-fungible assets.
 
 ### Non-fungible assets
 A non-fungible asset is encoded by hashing the asset data into a `Word` and then replacing the second element with the `faucet_id` of the issuing account. It looks like `[e0, faucet_id, e2, e3]`. Note that the second element is guaranteed to be non-Zero.
 
-Examples of non-fungible assets are all NFTs, e.g., a DevCon ticket. The ticket's data might be represented in a JSON string - which DevCon, the date, the initial price, etc. . Now, users can create a faucet for non-fungible DevCon tickets. This DevCon faucet would hash the JSON string into a `Word` to transform the ticket into an asset.  
+Examples of non-fungible assets are all NFTs, e.g., a DevCon ticket. The ticket's data might be represented in a JSON string - which DevCon, the date, the initial price, etc. . Now, users can create a faucet for non-fungible DevCon tickets. This DevCon faucet would hash the JSON string into a `Word` to transform the ticket into an asset.
 
 ### Storage
-[Accounts](https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html) and [notes](https://0xpolygonmiden.github.io/miden-base/architecture/notes.html) contain asset vaults that are used to store assets. Accounts can keep unlimited assets in a [tiered sparse Merkle tree](https://0xpolygonmiden.github.io/miden-base/crypto-primitives/tsmt.html) called `account vault`. Notes can only store up to `255` distinct assets. 
+[Accounts](https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html) and [notes](https://0xpolygonmiden.github.io/miden-base/architecture/notes.html) contain asset vaults that are used to store assets. Accounts can keep unlimited assets in a [tiered sparse Merkle tree](https://0xpolygonmiden.github.io/miden-base/crypto-primitives/tsmt.html) called `account vault`. Notes can only store up to `255` distinct assets.
 
 <p align="center">
     <img src="../diagrams/architecture/asset/Asset_Storage.png">
 </p>
 
-The information on which and how many assets are owned can be private depending on the account's storage mode or the note. This is true for any native asset in Miden. 
+The information on which and how many assets are owned can be private depending on the account's storage mode or the note. This is true for any native asset in Miden.
 
 ## Non-native assets
-Miden is flexible enough to create other types of assets as well. 
+Miden is flexible enough to create other types of assets as well.
 
-For example, developers can fully replicate Ethereum's ERC20 model, where ownership of fungible assets is recorded in a single account. To transact, users must send a note to that account to change the global hashmap. 
+For example, developers can fully replicate Ethereum's ERC20 model, where ownership of fungible assets is recorded in a single account. To transact, users must send a note to that account to change the global hashmap.
 
-Furthermore, a complete account can be treated as a programmable asset because ownership of accounts is transferrable. An account could be a "crypto kitty" with specific attributes and rules, and people can trade these "crypto kitties" by transferring accounts between each other. 
+Furthermore, a complete account can be treated as a programmable asset because ownership of accounts is transferrable. An account could be a "crypto kitty" with specific attributes and rules, and people can trade these "crypto kitties" by transferring accounts between each other.
 
 We can also think of an account representing a car. The owner of the car can change so the car account - granting access to the physical car - can be treated as an asset. In this car account, there could be rules defining who is allowed to drive the car and when.

docs/src/architecture/execution.md

@@ -10,15 +10,15 @@ Polygon Miden is an Ethereum Rollup. It batches transactions - or more precisely
 
 Every transaction will result in a ZK proof that attests to its correctness.
 
-As mentioned in [transactions](https://0xpolygonmiden.github.io/miden-base/architecture/transactions.html#local-vs-network-transactions), there are two types of transactions: local and network. For every transaction there is a proof which is either created by the user in the Miden Client or by the Operator using the Miden Node. 
+As mentioned in [transactions](https://0xpolygonmiden.github.io/miden-base/architecture/transactions.html#local-vs-network-transactions), there are two types of transactions: local and network. For every transaction there is a proof which is either created by the user in the Miden Client or by the Operator using the Miden Node.
 
 ## Transaction Batching
 To reduce the required space on the Ethereum blockchain, transaction proofs are aggregated into batches. This can happen in parallel by different machines that need to verify several proofs using the Miden VM and thus creating a proof. Verifying a STARK proof within the VM is relatively efficient but it is still a pretty costly operation (we aim for 2<sup>16</sup> cycles).
 
 ## Block Production
 Several batch proofs are being aggregated together into one block. This can not happen in parallel and must be done by the Miden Operator running the Miden Node. The idea is the same, using recursive verification.
 
-## State progress 
+## State progress
 At the beginning, Miden will have a centralized Operator running a Miden Node.
 
 Users will send either transaction proofs (using local execution) or transaction data (for network execution) to the Miden Node. Later on, the Miden Node will use recursive verification to aggregate transaction proofs into batches.