deploy: 68c75e7

architecture.html

@@ -196,7 +196,7 @@ <h3 id="notes"><a class="header" href="#notes">Notes</a></h3>
 <h3 id="assets"><a class="header" href="#assets">Assets</a></h3>
 <p><a href="./architecture/assets.html">Assets</a> can be fungible and non-fungible. They are stored in the owner’s account itself or in a note. This chapter describes asset issuance, customization, and storage.</p>
 <h3 id="transactions"><a class="header" href="#transactions">Transactions</a></h3>
-<p><a href="./architecture/transactions.html">Transactions</a> describe production and consumption of notes by a single account. Executing a transaction always results in a STARK proof. This chapter describes the transaction design and the implementation thereof. At it's core, transaction execution happens in the transaction kernel program which is explained in depth. </p>
+<p><a href="./architecture/transactions.html">Transactions</a> describe production and consumption of notes by a single account. Executing a transaction always results in a STARK proof. This chapter describes the transaction design and the implementation thereof. At it's core, transaction execution happens in the transaction kernel program which is explained in depth.</p>
 <h4 id="accounts-produce-and-consume-notes-to-communicate"><a class="header" href="#accounts-produce-and-consume-notes-to-communicate">Accounts produce and consume notes to communicate</a></h4>
 <p align="center">
     <img src="./diagrams/architecture/miden_architecture_core_concepts.gif" style="width: 80%;">
@@ -215,10 +215,10 @@ <h1 id="architecture-tradeoffs"><a class="header" href="#architecture-tradeoffs"
 <details>
   <summary>Want to know more on why we designed Miden as is?</summary>
 <h3 id="polygon-midens-architecture"><a class="header" href="#polygon-midens-architecture">Polygon Miden's architecture</a></h3>
-<p>Polygon Miden’s architecture departs considerably from typical blockchain designs to support privacy and parallel transaction execution. In traditional blockchains state and transactions must be transparent to be verifiable. This is necessary for block production and execution. User generated zero-knowledge proofs allow state transitions, e.g. transactions, to be verifiable without being transparent. </p>
+<p>Polygon Miden’s architecture departs considerably from typical blockchain designs to support privacy and parallel transaction execution. In traditional blockchains state and transactions must be transparent to be verifiable. This is necessary for block production and execution. User generated zero-knowledge proofs allow state transitions, e.g. transactions, to be verifiable without being transparent.</p>
 <h3 id="actor-based-execution-model"><a class="header" href="#actor-based-execution-model">Actor-based execution model</a></h3>
-<p>The actor model inspires Polygon Miden’s execution model. This is a well-known design paradigm in concurrent systems. In the actor model, actors are state machines responsible for maintaining their own state. In the context of Polygon Miden, each account is an actor. Actors communicate with each other by exchanging messages asynchronously. One actor can send a message to another, but it is up to the recipient to apply the requested change to their state. </p>
-<p>Polygon Miden’s architecture takes the actor model further and combines it with zero-knowledge proofs. Now, actors not only maintain and update their own state, but they can also prove the validity of their own state transitions to the rest of the network. This ability to independently prove state transitions enables local smart contract execution, private smart contracts, and much more. And it is quite unique in the rollup space. Normally only centralized entities - sequencer or prover - create zero-knowledge proofs, not the users. </p>
+<p>The actor model inspires Polygon Miden’s execution model. This is a well-known design paradigm in concurrent systems. In the actor model, actors are state machines responsible for maintaining their own state. In the context of Polygon Miden, each account is an actor. Actors communicate with each other by exchanging messages asynchronously. One actor can send a message to another, but it is up to the recipient to apply the requested change to their state.</p>
+<p>Polygon Miden’s architecture takes the actor model further and combines it with zero-knowledge proofs. Now, actors not only maintain and update their own state, but they can also prove the validity of their own state transitions to the rest of the network. This ability to independently prove state transitions enables local smart contract execution, private smart contracts, and much more. And it is quite unique in the rollup space. Normally only centralized entities - sequencer or prover - create zero-knowledge proofs, not the users.</p>
 <h3 id="hybrid-state-model"><a class="header" href="#hybrid-state-model">Hybrid state model</a></h3>
 <p>The actor-based execution model requires a radically different approach to recording the system's state. Actors and the messages they exchange must be treated as first-class citizens. Polygon Miden addresses this by combining the state models of account-based systems like Ethereum and UTXO-based systems like Bitcoin and Zcash.</p>
 </details>

architecture/accounts.html

@@ -193,7 +193,7 @@ <h2 id="account-design"><a class="header" href="#account-design">Account Design<
 <li><strong>Code →</strong> a collection of functions which define the external interface for an account</li>
 </ul>
 <h3 id="account-id"><a class="header" href="#account-id">Account ID</a></h3>
-<p>~63 bits (1 field element) long identifier for the account. The four most significant bits specify its <a href="https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html#account-types">account type</a> - regular, immutable, faucet - and the <a href="https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html#account-storage-modes">storage mode</a> - public or private. </p>
+<p>~63 bits (1 field element) long identifier for the account. The four most significant bits specify its <a href="https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html#account-types">account type</a> - regular, immutable, faucet - and the <a href="https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html#account-storage-modes">storage mode</a> - public or private.</p>
 <h3 id="account-storage"><a class="header" href="#account-storage">Account Storage</a></h3>
 <p>Storage for user-defined data. <code>AccountStorage</code> is composed of two components.</p>
 <p>The first component is a simple sparse Merkle tree of depth <code>8</code> which is index addressable. This provides the user with <code>256</code> <code>Word</code> slots.</p>
@@ -213,7 +213,7 @@ <h3 id="vault"><a class="header" href="#vault">Vault</a></h3>
 </ul>
 <p>An account vault can be reduced to a single hash which is the root of the sparse Merkle tree.</p>
 <h3 id="code"><a class="header" href="#code">Code</a></h3>
-<p>Interface for accounts. In Miden every account is a smart contract. It has an interface that exposes functions that can be called by <a href="https://0xpolygonmiden.github.io/miden-base/architecture/notes.html#note-scripts">note scripts</a> and <a href="https://0xpolygonmiden.github.io/miden-base/transactions/transaction-kernel.html#the-transaction-script-processing">transaction scripts</a>. Users cannot call those functions directly. </p>
+<p>Interface for accounts. In Miden every account is a smart contract. It has an interface that exposes functions that can be called by <a href="https://0xpolygonmiden.github.io/miden-base/architecture/notes.html#note-scripts">note scripts</a> and <a href="https://0xpolygonmiden.github.io/miden-base/transactions/transaction-kernel.html#the-transaction-script-processing">transaction scripts</a>. Users cannot call those functions directly.</p>
 <p>Functions exposed by the account have the following properties:</p>
 <ul>
 <li>Functions are actually roots of <a href="https://0xpolygonmiden.github.io/miden-vm/user_docs/assembly/main.html">Miden program MASTs</a> (i.e., a 32-byte hash). Thus, function identifier is a commitment to the code which is executed when a function is invoked.</li>
@@ -222,7 +222,7 @@ <h3 id="code"><a class="header" href="#code">Code</a></h3>
 </ul>
 <p><em>Note: Since code in Miden is expressed as MAST, every function is a commitment to the underlying code. The code cannot change unnoticed to the user because its hash would change. Behind any MAST root there can only be <code>256</code> functions</em></p>
 <h4 id="example-account-code"><a class="header" href="#example-account-code">Example Account Code</a></h4>
-<p>Currently, Miden provides two standard implementations for account code. </p>
+<p>Currently, Miden provides two standard implementations for account code.</p>
 <h5 id="basic-user-account-regular-updatable-account"><a class="header" href="#basic-user-account-regular-updatable-account">Basic user account (Regular updatable account)</a></h5>
 <p>There is a standard for a basic user account. It exposes three functions via its interface.</p>
 <details>

architecture/assets.html

@@ -211,7 +211,7 @@ <h3 id="storage"><a class="header" href="#storage">Storage</a></h3>
 <h2 id="non-native-assets"><a class="header" href="#non-native-assets">Non-native assets</a></h2>
 <p>Miden is flexible enough to create other types of assets as well.</p>
 <p>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.</p>
-<p>Furthermore, a complete account can be treated as a programmable asset because ownership of accounts is transferrable. An account could be a &quot;crypto kitty&quot; with specific attributes and rules, and people can trade these &quot;crypto kitties&quot; by transferring accounts between each other.</p>
+<p>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.</p>
 <p>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.</p>
 
                     </main>