From 74dd005e1b7e1741759ee14f3e3e2c6782aae6f1 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Mon, 17 Jul 2023 20:18:17 +0200 Subject: [PATCH] :memo: Fix: typos (#162) * Fix: typo * Fix: typos * Fix: typos * Fix: typos * Fix: typos * Fix: typo * Fix: typos * Fix: typos * Fix: typos * Fix: typos * Fix: typos * Fix: typo * Fix: typo * Fix: typo * Fix: typo * Fix: typos * Fix: typo * Fix: typos * Fix: typo * Fix: typos * Fix: typo --- README.adoc | 4 ++-- .../book/modules/chapter_1/pages/community_funds.adoc | 4 ++-- .../book/modules/chapter_1/pages/compute_costs.adoc | 2 +- .../book/modules/chapter_1/pages/first_contract.adoc | 6 +++--- chapters/book/modules/chapter_2/pages/asserts.adoc | 4 ++-- .../modules/chapter_2/pages/deploy_call_invoke.adoc | 2 +- chapters/book/modules/chapter_2/pages/enums.adoc | 6 +++--- chapters/book/modules/chapter_2/pages/index.adoc | 4 ++-- .../chapter_2/pages/security_considerations.adoc | 4 ++-- chapters/book/modules/chapter_2/pages/strings.adoc | 4 ++-- chapters/book/modules/chapter_2/pages/types.adoc | 2 +- chapters/book/modules/chapter_3/pages/hardhat.adoc | 2 +- .../book/modules/chapter_8/pages/arithmetization.adoc | 4 ++-- .../book/modules/chapter_8/pages/cryptography.adoc | 10 +++++----- chapters/book/modules/chapter_8/pages/geometry.adoc | 8 ++++---- .../book/modules/chapter_8/pages/number_theory.adoc | 10 +++++----- .../pages/part1_trace_and_low_degree_extension.adoc | 2 +- .../pages/part1_trace_and_low_degree_extension_rs.adoc | 4 ++-- .../modules/chapter_8/pages/part2_constraints.adoc | 4 ++-- .../modules/chapter_8/pages/part2_constraints_rs.adoc | 4 ++-- .../modules/chapter_8/pages/trust_verification.adoc | 6 +++--- 21 files changed, 48 insertions(+), 48 deletions(-) diff --git a/README.adoc b/README.adoc index 49cadf9a1..b3e969e79 100644 --- a/README.adoc +++ b/README.adoc @@ -36,7 +36,7 @@ Depending on your goals and interests, you can choose different paths through th * If you're a *security researcher* or *smart contract auditor* wanting to learn about the Account Abstraction feature and its implications, go for *Account Abstraction*. -* If you're a *blockchain enthusiast* curious about the underlying architecture and mechanics of Starknet and Cairo, explore *Starknet and Cairo CPU Arquitecture*. +* If you're a *blockchain enthusiast* curious about the underlying architecture and mechanics of Starknet and Cairo, explore *Starknet and Cairo CPU Architecture*. * If you're a *cryptography expert* or *researcher* eager to understand the fundamentals of STARKs and their connection to the Starknet ecosystem, delve into *STARKs*. @@ -222,4 +222,4 @@ a| a| a| a| -|=== \ No newline at end of file +|=== diff --git a/chapters/book/modules/chapter_1/pages/community_funds.adoc b/chapters/book/modules/chapter_1/pages/community_funds.adoc index 84f13b873..ecd6c84e9 100644 --- a/chapters/book/modules/chapter_1/pages/community_funds.adoc +++ b/chapters/book/modules/chapter_1/pages/community_funds.adoc @@ -8,7 +8,7 @@ Starknet is dedicated to bolstering community strength, unity, and outreach. As . Provision of grants to community members undertaking projects that align with our philosophy and contribute to our broader objectives. . Allocation of member education and training resources via online tutorials, webinars, mentorship programs, and more. . Enhancement and upkeep of open, inclusive communication channels, such as Telegram groups, Discord servers and community forums. -.P romotion of community engagement via incentivized activities like idea contests, art contests, and problem-solving challenges. +. Promotion of community engagement via incentivized activities like idea contests, art contests, and problem-solving challenges. . In addition, we are open to other creative initiatives that align with our philosophy and goals. Starknet recognizes that all community members are potential contributors to our mission, and we discourage any attempts to deter participation or collaboration. == Community Ethics and Code of Conduct: @@ -50,4 +50,4 @@ Non-compliance with these guidelines may result in fund termination and possible == Revision and Updates: The funds aim to help grow and strengthen the community. Adherence to these guidelines ensures effective and beneficial use of these funds for all community members. -We appreciate your cooperation and commitment to creating a vibrant, engaging, and supportive Starknet community. Together, we can construct a future unfettered by creative and innovative bounds. \ No newline at end of file +We appreciate your cooperation and commitment to creating a vibrant, engaging, and supportive Starknet community. Together, we can construct a future unfettered by creative and innovative bounds. diff --git a/chapters/book/modules/chapter_1/pages/compute_costs.adoc b/chapters/book/modules/chapter_1/pages/compute_costs.adoc index 73d2958e9..96a0da761 100644 --- a/chapters/book/modules/chapter_1/pages/compute_costs.adoc +++ b/chapters/book/modules/chapter_1/pages/compute_costs.adoc @@ -41,7 +41,7 @@ The advent of economical on-chain computation has the potential to significantly 3. **Computational Feeds**: The lower cost of execution also opens the door for feeds of aggregated and calculated data. For instance, traditional financial applications often rely on sophisticated data feeds that provide information on risk, yield, and volatility. Teams like Pragma are dedicated to bringing these types of feeds to the web3 space. Currently, Pragma has already launched two computational feeds on the Starknet testnet, including a volatility index and a yield curve. -4. **Storage Proofs**: With these cryptographic commitments, it is possible to trustlessly prove that a particular state existed at a specific time or block. While these proofs require some computation to verify, the low computational cost greatly enhances user experience. Storage proofs not only allow for the transfer of information between different chains in a decentralized manner but also offer access to historical data from the blockchain and much more. In the realm of oracles, storage proofs promise to revolutionize how data is handled and verified. For a deeper dive into storage proofs, be sure to check outhttps://book.starknet.io/chapter_6/storage_proofs.html[**Chapter 6: Pioneering Applications**]. +4. **Storage Proofs**: With these cryptographic commitments, it is possible to trustlessly prove that a particular state existed at a specific time or block. While these proofs require some computation to verify, the low computational cost greatly enhances user experience. Storage proofs not only allow for the transfer of information between different chains in a decentralized manner but also offer access to historical data from the blockchain and much more. In the realm of oracles, storage proofs promise to revolutionize how data is handled and verified. For a deeper dive into storage proofs, be sure to check out https://book.starknet.io/chapter_6/storage_proofs.html[**Chapter 6: Pioneering Applications**]. === Realization of On-Chain Gaming diff --git a/chapters/book/modules/chapter_1/pages/first_contract.adoc b/chapters/book/modules/chapter_1/pages/first_contract.adoc index 7035d229f..609d83633 100644 --- a/chapters/book/modules/chapter_1/pages/first_contract.adoc +++ b/chapters/book/modules/chapter_1/pages/first_contract.adoc @@ -15,11 +15,11 @@ starkli --version # To interact with Starknet A smart wallet is composed of two parts: a Signer and an Account Descriptor. The signer is a smart contract that can sign transactions (we need its private key). The account descriptor is a json file that contains information about the smart wallet, such as its address and public key. -First, create a smart wallet via the Braavos or Argent X browser extensions. Follow you wallet (Argent or Braavos) instructions. After creating and funding your smart wallet with ETH (use the https://faucet.goerli.starknet.io/[Starknet Goerli Faucet] whenever you require it), you can deploy it to the Starknet's testnet for this tutorial. +First, create a smart wallet via the Braavos or Argent X browser extensions. Follow your wallet (Argent or Braavos) instructions. After creating and funding your smart wallet with ETH (use the https://faucet.goerli.starknet.io/[Starknet Goerli Faucet] whenever you require it), you can deploy it to the Starknet's testnet for this tutorial. === Creating a Signer -A Signer is an smart contract that can sign transactions. It's a crucial component of accounts in Starknet. To create a Signer we just need the private key of our smart wallet (the public key can be derived from it). +A Signer is a smart contract that can sign transactions. It's a crucial component of accounts in Starknet. To create a Signer we just need the private key of our smart wallet (the public key can be derived from it). Starkli provides us with the ability to create a "keystore" file that securely stores the private key of our smart wallets each with a password. The accounts in the keystore file can be used to sign transactions using Starkli. The main advantage of this approach is that it prevents storing the private key as plain text on our computer. Instead, we use a password to create an encrypted file in the location of our choosing. @@ -142,7 +142,7 @@ With the smart contract compiled, we're ready to declare it using Starkli. Howev . The default an easiest option is to use Starknet Sequencer's Gateway. This is the option we will use in this tutorial and it is the default for Starkli. However, as you proceed with your Starknet journey, we recommend you to set up your own node or use a provider like Infura or Alchemy, because the Starknet Sequencer's Gateway could get saturated with requests and you may experience delays in your transactions. . Use a provider like Infura or Alchemy. You can find more information about this in the https://book.starknet.io/chapter_1/environment_setup.html[Setting up your Environment] subchapter. Set up an API key and as endpoint select Starknet's testnet/goerli. In the Infura case, the endpoint looks like this: https://starknet-goerli.infura.io/v3/; review the https://docs.infura.io/networks/starknet/how-to/choose-a-network[Infura documentation] for more information. -. Set up you own node and use the RPC provider of your node. Check out https://www.kasar.io/[Kasar] or the https://book.starknet.io/chapter_4/node.html[Chapter 4] of the Starknet Book to learn how to set up your own node. +. Set up your own node and use the RPC provider of your node. Check out https://www.kasar.io/[Kasar] or the https://book.starknet.io/chapter_4/node.html[Chapter 4] of the Starknet Book to learn how to set up your own node. Here's the structure for the declaration command using the Starknet Sequencer's Gateway: diff --git a/chapters/book/modules/chapter_2/pages/asserts.adoc b/chapters/book/modules/chapter_2/pages/asserts.adoc index 6b49b6b64..6afa972a3 100644 --- a/chapters/book/modules/chapter_2/pages/asserts.adoc +++ b/chapters/book/modules/chapter_2/pages/asserts.adoc @@ -22,7 +22,7 @@ Some key points about the `assert` statement in Cairo are: 3. The `assert` statement is helpful for input validation, ensuring that only valid inputs are processed by the contract. -4. The compiler will not notice if an assertions is not complied with. That is, the compiler will not check if the condition is true or false. The assertion is only checked at runtime: for example, in tests (more on this in a following chapter) or when the contract is deployed. +4. The compiler will not notice if an assertion is not complied with. That is, the compiler will not check if the condition is true or false. The assertion is only checked at runtime: for example, in tests (more on this in a following chapter) or when the contract is deployed. [NOTE] ==== @@ -41,4 +41,4 @@ ____ StarknetBook is a work in progress, and your passion, expertise, and unique insights can help transform it into something truly exceptional. Don't be afraid to challenge the status quo or break the Book! Together, we can create an invaluable resource that empowers countless others. Embrace the excitement of contributing to something bigger than ourselves. If you see room for improvement, seize the opportunity! Check out our https://github.com/starknet-edu/starknetbook/blob/main/CONTRIBUTING.adoc[guidelines] and join our vibrant community. Let's fearlessly build Starknet! -____ \ No newline at end of file +____ diff --git a/chapters/book/modules/chapter_2/pages/deploy_call_invoke.adoc b/chapters/book/modules/chapter_2/pages/deploy_call_invoke.adoc index 608d288fa..538360d3d 100644 --- a/chapters/book/modules/chapter_2/pages/deploy_call_invoke.adoc +++ b/chapters/book/modules/chapter_2/pages/deploy_call_invoke.adoc @@ -94,7 +94,7 @@ The contract has been deployed at address: 0x0447025aad44c69080e821ffef78f03b520 == Voter Eligibility Verification -In our voting contract, we have two functions to validate voter eligibility, `voter_can_vote` and `is_voter_registered`. These are read external functions, which mean they don't alter the state of the contract but only read the current state. +In our voting contract, we have two functions to validate voter eligibility, `voter_can_vote` and `is_voter_registered`. These are read external functions, which means they don't alter the state of the contract but only read the current state. The `is_voter_registered` function checks whether a particular address is registered as an eligible voter in the contract. The `voter_can_vote` function, on the other hand, checks whether the voter at a specific address is currently eligible to vote, i.e., they are registered and haven't voted already. diff --git a/chapters/book/modules/chapter_2/pages/enums.adoc b/chapters/book/modules/chapter_2/pages/enums.adoc index 442e8f2dd..a45065c71 100644 --- a/chapters/book/modules/chapter_2/pages/enums.adoc +++ b/chapters/book/modules/chapter_2/pages/enums.adoc @@ -80,7 +80,7 @@ You can define traits and implement them for your custom enums, this allows you } ---- -In the example above, we implemented the Processing traits for Message .Hers is ow it could be used to process a Quit message: +In the example above, we implemented the Processing traits for Message. Here is how it could be used to process a Quit message: [source, bash] ---- @@ -107,7 +107,7 @@ mod Enum{ use option::OptionTrait; // This function returns how much icecream there is left in the fridge. -// If it is before 10PM, there is 5 pieces left. At 10PM, someone eats them all, so there will be no more left. +// If it is before 10PM, there is 5 pieces left. At 10PM, someone eats them all, so there will be no more left. fn maybe_icecream(time_of_day: u32) -> Option { if time_of_day < 22_u32 { @@ -119,4 +119,4 @@ fn maybe_icecream(time_of_day: u32) -> Option { } } } ----- \ No newline at end of file +---- diff --git a/chapters/book/modules/chapter_2/pages/index.adoc b/chapters/book/modules/chapter_2/pages/index.adoc index 1d4469a30..8cd9573fe 100644 --- a/chapters/book/modules/chapter_2/pages/index.adoc +++ b/chapters/book/modules/chapter_2/pages/index.adoc @@ -37,7 +37,7 @@ In practice, there are two different technologies for proving general programs: Cairo addresses these limitations and offers more efficient solutions: -1. A low-level field data type called "felt252" is available, alongside a several types of uints +1. A low-level field data type called "felt252" is available, alongside several types of uints 2. Cairo is idiomatically write-once, resembling a functional programming language 3. Cairo provides full low-level access to underlying primitives @@ -70,4 +70,4 @@ ____ StarknetBook is a work in progress, and your passion, expertise, and unique insights can help transform it into something truly exceptional. Don't be afraid to challenge the status quo or break the Book! Together, we can create an invaluable resource that empowers countless others. Embrace the excitement of contributing to something bigger than ourselves. If you see room for improvement, seize the opportunity! Check out our https://github.com/starknet-edu/starknetbook/blob/main/CONTRIBUTING.adoc[guidelines] and join our vibrant community. Let's fearlessly build Starknet! -____ \ No newline at end of file +____ diff --git a/chapters/book/modules/chapter_2/pages/security_considerations.adoc b/chapters/book/modules/chapter_2/pages/security_considerations.adoc index 3f6b3dd6f..9b957005e 100644 --- a/chapters/book/modules/chapter_2/pages/security_considerations.adoc +++ b/chapters/book/modules/chapter_2/pages/security_considerations.adoc @@ -292,7 +292,7 @@ image::sec_over_u128.png[u128] == 5. Private Data On-Chain. -In some cases, a smart contracts may needs to store secret values that can't be revelead to users, however this is not possible +In some cases, a smart contract may need to store secret values that can't be revealed to users, however this is not possible if you store data on chain because all stored data is public and can be retrieved even if you don't publish your code. In the next example, our smart contract will use a contructor parameter to set a password (12345678) and store it on chain: @@ -375,4 +375,4 @@ ____ StarknetBook is a work in progress, and your passion, expertise, and unique insights can help transform it into something truly exceptional. Don't be afraid to challenge the status quo or break the Book! Together, we can create an invaluable resource that empowers countless others. Embrace the excitement of contributing to something bigger than ourselves. If you see room for improvement, seize the opportunity! Check out our https://github.com/starknet-edu/starknetbook/blob/main/CONTRIBUTING.adoc[guidelines] and join our vibrant community. Let's fearlessly build Starknet! -____ \ No newline at end of file +____ diff --git a/chapters/book/modules/chapter_2/pages/strings.adoc b/chapters/book/modules/chapter_2/pages/strings.adoc index ace752bdc..f00434923 100644 --- a/chapters/book/modules/chapter_2/pages/strings.adoc +++ b/chapters/book/modules/chapter_2/pages/strings.adoc @@ -31,7 +31,7 @@ Currently, when coding with Cairo we need to constantly be converting between fe image::starkutils.png[starkutils] -This is a tedious process, which the Cairo community is improving in the near the future. +This is a tedious process, which the Cairo community is improving in the near future. == Summary @@ -61,4 +61,4 @@ ____ StarknetBook is a work in progress, and your passion, expertise, and unique insights can help transform it into something truly exceptional. Don't be afraid to challenge the status quo or break the Book! Together, we can create an invaluable resource that empowers countless others. Embrace the excitement of contributing to something bigger than ourselves. If you see room for improvement, seize the opportunity! Check out our https://github.com/starknet-edu/starknetbook/blob/main/CONTRIBUTING.adoc[guidelines] and join our vibrant community. Let's fearlessly build Starknet! -____ \ No newline at end of file +____ diff --git a/chapters/book/modules/chapter_2/pages/types.adoc b/chapters/book/modules/chapter_2/pages/types.adoc index b668c5c6c..3b681ce91 100644 --- a/chapters/book/modules/chapter_2/pages/types.adoc +++ b/chapters/book/modules/chapter_2/pages/types.adoc @@ -26,7 +26,7 @@ A list of primitive types in Cairo (not all), along with a brief description of | Array | A dynamic array data structure for elements of type T, used for creating and manipulating arrays. |=== -Similar to Rust, Cairo also supports type inference so the compiler will try to guess the type of a variable based on how the value is used. Incases where its not possible for compiler to guess the type of a variable, explicit annotation must be added. +Similar to Rust, Cairo also supports type inference so the compiler will try to guess the type of a variable based on how the value is used. In cases where it's not possible for compiler to guess the type of a variable, explicit annotation must be added. Here is an example of using types in Cairo: diff --git a/chapters/book/modules/chapter_3/pages/hardhat.adoc b/chapters/book/modules/chapter_3/pages/hardhat.adoc index 48336d2b6..81ad34336 100644 --- a/chapters/book/modules/chapter_3/pages/hardhat.adoc +++ b/chapters/book/modules/chapter_3/pages/hardhat.adoc @@ -2,7 +2,7 @@ = Starknet Hardhat Plugin -Hardhat is a popular JS development environment for Ethereum, and if you are already familiar with it and want to use it on Starknet, then this plugin will come in hand! +Hardhat is a popular JS development environment for Ethereum, and if you are already familiar with it and want to use it on Starknet, then this plugin will come in handy! == Getting Started diff --git a/chapters/book/modules/chapter_8/pages/arithmetization.adoc b/chapters/book/modules/chapter_8/pages/arithmetization.adoc index 037af3070..d18fefbb0 100644 --- a/chapters/book/modules/chapter_8/pages/arithmetization.adoc +++ b/chapters/book/modules/chapter_8/pages/arithmetization.adoc @@ -214,7 +214,7 @@ This concludes the promised reduction, that translates the problem of checking w Succinctness -Having a very efficient verification technique is key to STARKs, and it can be seen as comprised of two parts -- using a small number of queries, and having the verifier perform a small computation on each query. The former is achieved by error correction codes, which allow querying in very few places, and the latter we have sort of sweeped under the rug throughout this post, until now. The verifier's work can be summed up as 1) querying the composition polynomial in random places, and 2) checking low-degreeness based on these queries. Low degreeness succinct checking will be handled in the next post, but what exactly do we mean by "`querying the composition polynomial`"? The avid reader may have been suspicious of this expression, and rightfully so. The prover, after all, may be malicious. When the verifier asks for the evaluation of the composition polynomial at some x, the prover may reply with the evaluation of some truly low-degree polynomial, that will pass any low-degree testing, but is not the composition polynomial. +Having a very efficient verification technique is key to STARKs, and it can be seen as comprised of two parts -- using a small number of queries, and having the verifier perform a small computation on each query. The former is achieved by error correction codes, which allow querying in very few places, and the latter we have sort of swept under the rug throughout this post, until now. The verifier's work can be summed up as 1) querying the composition polynomial in random places, and 2) checking low-degreeness based on these queries. Low degreeness succinct checking will be handled in the next post, but what exactly do we mean by "`querying the composition polynomial`"? The avid reader may have been suspicious of this expression, and rightfully so. The prover, after all, may be malicious. When the verifier asks for the evaluation of the composition polynomial at some x, the prover may reply with the evaluation of some truly low-degree polynomial, that will pass any low-degree testing, but is not the composition polynomial. To prevent this, the verifier explicitly queries the Fibonacci execution trace at some row w by asking for the values of $f$ in three places: $f(w)$, $f(gw)$, $f(g²w)$. @@ -222,7 +222,7 @@ The verifier can now compute the value of the composition polynomial at w by: image::succinctness.png[succintness] -Where the numerator can be computed using the values obtained from the prover, and the denominator... well, there's the rub (that was sweeped under the rug). +Where the numerator can be computed using the values obtained from the prover, and the denominator... well, there's the rub (that was swept under the rug). On the one hand the denominator is completely independent of the execution trace, so the verifier can compute it before ever communicating with the prover. diff --git a/chapters/book/modules/chapter_8/pages/cryptography.adoc b/chapters/book/modules/chapter_8/pages/cryptography.adoc index 6d620584a..a4380711f 100644 --- a/chapters/book/modules/chapter_8/pages/cryptography.adoc +++ b/chapters/book/modules/chapter_8/pages/cryptography.adoc @@ -43,7 +43,7 @@ When the dataset D is public, any party (V) interested in verifying CI can re-ex Additionally, when the dataset D contains confidential data, the previous solution can no longer be implemented and the party P in charge of D may conceal violations of computational integrity under the veil of secrecy. -Zero knowledge (ZK) proof and argument systems are automated protocols that guarantee computational integrity over confidential data for any efficient computation, eliminating corruptibility (possibly of auditors) and reducing costs. A ZK system S for a computation C is a pair of randomized algorithms, S = (P, V); the prover P is the algorithm used to prove computational integrity and the verifier V checks such proofs. Ideally we want the proof to be succint: the proof should be quicker to verify than than computing it. +Zero knowledge (ZK) proof and argument systems are automated protocols that guarantee computational integrity over confidential data for any efficient computation, eliminating corruptibility (possibly of auditors) and reducing costs. A ZK system S for a computation C is a pair of randomized algorithms, S = (P, V); the prover P is the algorithm used to prove computational integrity and the verifier V checks such proofs. Ideally we want the proof to be succinct: the proof should be quicker to verify than computing it. The completeness and soundness of S imply that P can efficiently prove all truisms but will fail to convince V of any falsities (with all but negligible probability). @@ -54,9 +54,9 @@ Zero Knowledge Proof Systems are proof systems in which there is secret informat A `non-interactive` proof system is an abstract machine that models computation between the two parties(prover and verifier). Messages are sent in https://www.youtube.com/watch?v=QJO3ROT-A4E[one direction] until the verifier is convinced of the computational claim. -A `succinct` proof system is one in which the verifier can run an order of magnitute faster than a naive re-execution of the program +A `succinct` proof system is one in which the verifier can run an order of magnitude faster than a naive re-execution of the program -`SNARKS`: Succint Non-Interactive Arguments of Knowledge +`SNARKS`: Succinct Non-Interactive Arguments of Knowledge `STARKs`: Scalable Transparent Arguments of Knowledge @@ -76,11 +76,11 @@ ____ https://vitalik.ca/general/2017/11/09/starks_part_1.html[Vitalik (2017)] - "What you might not know is that ZK-SNARKs have a newer, shinier cousin: ZK-STARKs." ____ -STARKs were introduced in 2018 in a https://eprint.iacr.org/2018/046.pdf[paper by Eli Ben-Sasson et. al.]. Eli is Co-Founder of Starkware. That is right, Starkware was founded by the some of the creators of both SNARKs and STARKs. +STARKs were introduced in 2018 in a https://eprint.iacr.org/2018/046.pdf[paper by Eli Ben-Sasson et. al.]. Eli is Co-Founder of Starkware. That is right, Starkware was founded by some of the creators of both SNARKs and STARKs. The main difference between SNARKs and STARKs is that a STARK uses collision resistant hash functions instead of elliptic curves. These are much simpler cryptographic assumptions. STARKs rely purely on hashes and information theory; meaning that they are secure against attackers with quantum computers (https://vitalik.ca/general/2017/11/09/starks_part_1.html[Vitalik, 2017]). -What is the downside? Mainly that proof sizes go uo from 288 bytes, in SNARKs case, to a few hundred kilobytes. The tradeoff could be worth it or not. Authors suggest it could be worth it because it This tradeoff is worth STARKs allow us to have a much higher effective TPS and throughput than a SNARK (https://pseudotheos.mirror.xyz/_LAi4cCFz2gaC-3WgNmri1eTvckA32L7v31A8saJvqg[pseudotheos, 2022]), and if elliptic curves break or when quantum computers come around (https://vitalik.ca/general/2017/11/09/starks_part_1.html[Vitalik, 2017]). +What is the downside? Mainly that proof sizes go up from 288 bytes, in SNARKs case, to a few hundred kilobytes. The tradeoff could be worth it or not. Authors suggest it could be worth it because it This tradeoff is worth STARKs allow us to have a much higher effective TPS and throughput than a SNARK (https://pseudotheos.mirror.xyz/_LAi4cCFz2gaC-3WgNmri1eTvckA32L7v31A8saJvqg[pseudotheos, 2022]), and if elliptic curves break or when quantum computers come around (https://vitalik.ca/general/2017/11/09/starks_part_1.html[Vitalik, 2017]). "With the T standing for "transparent", ZK-STARKs resolve one of the primary weaknesses of ZK-SNARKs, its reliance on a 'trusted setup´." https://vitalik.ca/general/2017/11/09/starks_part_1.html[(Vitalik 2017)]. diff --git a/chapters/book/modules/chapter_8/pages/geometry.adoc b/chapters/book/modules/chapter_8/pages/geometry.adoc index 7907a99f3..1690c61dd 100644 --- a/chapters/book/modules/chapter_8/pages/geometry.adoc +++ b/chapters/book/modules/chapter_8/pages/geometry.adoc @@ -39,11 +39,11 @@ Polynomial arithmetic is quite simple. The more complex operation is the divisio image::poly2.png[poly2] -We can define several polynomials belonging to the same field. For example, for the $F_2$ field, which only contains $0$ and $1$ as members, we can generate an infinite number of polynomials without caring for the their degree. That is, the members of the field only populate the coefficients of the polynomial without caring for the exponents. +We can define several polynomials belonging to the same field. For example, for the $F_2$ field, which only contains $0$ and $1$ as members, we can generate an infinite number of polynomials without caring for their degree. That is, the members of the field only populate the coefficients of the polynomial without caring for the exponents. image::poly6.png[poly6] -We can follow the same logic for polynomial arithmetic operations when the coefficients belong to finite field. We just need to remember the modular nature of finite fields. As an example, let's operate with polynomals whose coefficients belong to the $F_7$ field. You will notice that we are simply using field arithmetic within the coefficients. +We can follow the same logic for polynomial arithmetic operations when the coefficients belong to finite field. We just need to remember the modular nature of finite fields. As an example, let's operate with polynomials whose coefficients belong to the $F_7$ field. You will notice that we are simply using field arithmetic within the coefficients. Addition: @@ -61,7 +61,7 @@ Again the division case is out of the scope of this tutorial for now. A polynomial $f(x)$ over a field $F$ is called prime or irreducible if $f(x)$ cannot be expressed as a product of two polynomials. Both polynomials have to be part of $F$ and of a lower degree than $f(x)$. That is, an irreducible polynomial as a polynomial that cannot be factorized into lower-degree polynomials. -The concept of generator, $g$, frequently appears in cryptography. A generator is an element in the subgroup whose powers span the entire subgroup. In easier words, it is a number that is capable of of generating the entire set or the entire field by exponentiating the generator. For example, for the field $Z_\{13}$, a generator $g$ is $g=2$. Why? Because if we exponentiate $2$ we can get all the 13 elements in the field $Z_\{13} = {0,1,...,12}$ (except for the 0). Notice $2{caret}\{0}\bmod13 = 1$, $2{caret}\{1}\bmod13 = 2$, $2{caret}\{2}\bmod13 = 4$, $2{caret}\{3}\bmod13 = 8$, $2{caret}\{4}\bmod13 = 3$, $2{caret}\{5}\bmod13 = 6$, and so on. Not all elements in a set can be generators, make the exercise and you will notice 3 is not a generator of the field $Z_\{13}$. +The concept of generator, $g$, frequently appears in cryptography. A generator is an element in the subgroup whose powers span the entire subgroup. In easier words, it is a number that is capable of generating the entire set or the entire field by exponentiating the generator. For example, for the field $Z_\{13}$, a generator $g$ is $g=2$. Why? Because if we exponentiate $2$ we can get all the 13 elements in the field $Z_\{13} = {0,1,...,12}$ (except for the 0). Notice $2{caret}\{0}\bmod13 = 1$, $2{caret}\{1}\bmod13 = 2$, $2{caret}\{2}\bmod13 = 4$, $2{caret}\{3}\bmod13 = 8$, $2{caret}\{4}\bmod13 = 3$, $2{caret}\{5}\bmod13 = 6$, and so on. Not all elements in a set can be generators, make the exercise and you will notice 3 is not a generator of the field $Z_\{13}$. More generally, note that if $g$ is the generator of a field $Z_\{n}$, then $Z_\{n} = {0, g{caret}\{0}, g{caret}\{1}, ..., g{caret}\{n-2}}$ (because by exponentiating generator $g$ we can get each element in the field). @@ -88,4 +88,4 @@ ____ StarknetBook is a work in progress, and your passion, expertise, and unique insights can help transform it into something truly exceptional. Don't be afraid to challenge the status quo or break the Book! Together, we can create an invaluable resource that empowers countless others. Embrace the excitement of contributing to something bigger than ourselves. If you see room for improvement, seize the opportunity! Check out our https://github.com/starknet-edu/starknetbook/blob/main/CONTRIBUTING.adoc[guidelines] and join our vibrant community. Let's fearlessly build Starknet! -____ \ No newline at end of file +____ diff --git a/chapters/book/modules/chapter_8/pages/number_theory.adoc b/chapters/book/modules/chapter_8/pages/number_theory.adoc index c06eb4992..4e4e90e92 100644 --- a/chapters/book/modules/chapter_8/pages/number_theory.adoc +++ b/chapters/book/modules/chapter_8/pages/number_theory.adoc @@ -19,7 +19,7 @@ A system of arithmetic for integers where numbers "wrap around" when reaching a image:modular.png[modular] -A real-world example of modular arithmetic is time-keeping via a clock. When the hour of the day exceed the modulus(12) we "wrap" around and begin at zero. +A real-world example of modular arithmetic is time-keeping via a clock. When the hour of the day exceeds the modulus(12) we "wrap" around and begin at zero. Example: @@ -28,9 +28,9 @@ Example: python3 finite_fields/python/modular_arithmetic.py ---- -In other words, of an division we sometimes are more interested in the *remainder*. Here is where we use the operator named as *modulo operator* or simply *mod*. For example, $13\bmod5 = 3$ because $\frac\{13}\{5}=2$ remainder $3$. +In other words, of a division we sometimes are more interested in the *remainder*. Here is where we use the operator named as *modulo operator* or simply *mod*. For example, $13\bmod5 = 3$ because $\frac\{13}\{5}=2$ remainder $3$. -Let's go trough a couple examples: +Let's go through a couple examples: * $-29\bmod3 = 1$ @@ -69,7 +69,7 @@ We need to make our finite field closed under arithmetic operations as addition, Now, for our finite field $F_3$, $1$ $+_f$ $2$ $=$ $(1+2) \bmod 3$ $=$ $0$. Also $2$ $⋅_f$ $2$ $=$ $(2⋅2) \bmod 3$ $=$ $1$. Now we have close operations for our finite field. -What about substraction? It is the same. For a finite field $F_3$, $1$ $-_f$ $2$ $=$ $(1-2) \bmod 3$ $=$ $2$. We are basically performing modular arithmetic where the the modulo is the finite field's order. For multiplication the case is similar. +What about substraction? It is the same. For a finite field $F_3$, $1$ $-_f$ $2$ $=$ $(1-2) \bmod 3$ $=$ $2$. We are basically performing modular arithmetic where the modulo is the finite field's order. For multiplication the case is similar. Addition, Multiplication, Exponentiation, and Substraction of fields are intuitive. However, Division of fields can be a bit challenging at the beginning. Let's begin with easy operations: @@ -78,7 +78,7 @@ Addition, Multiplication, Exponentiation, and Substraction of fields are intuiti * For the finite field $F_3$, the operation $1$ $/_f$ $0$ $=$ $(1/0) \bmod 3$ can not be performed since we can not divide by 0. * For the finite field $F_3$, $8$ $/_f$ $5$ $=$ $(2/2) \bmod 3$ $=$ $1$. It makes sense since $2/2=1$. -Until now eveything seems ok. However, what happens when, for the finite field $F_5$, we divide $8$ $/_f$ $4$ $=$ $(3/4) \bmod 5$? The result is not trivial. +Until now everything seems ok. However, what happens when, for the finite field $F_5$, we divide $8$ $/_f$ $4$ $=$ $(3/4) \bmod 5$? The result is not trivial. == Congruences diff --git a/chapters/book/modules/chapter_8/pages/part1_trace_and_low_degree_extension.adoc b/chapters/book/modules/chapter_8/pages/part1_trace_and_low_degree_extension.adoc index 9ed98a8b7..5978b355c 100644 --- a/chapters/book/modules/chapter_8/pages/part1_trace_and_low_degree_extension.adoc +++ b/chapters/book/modules/chapter_8/pages/part1_trace_and_low_degree_extension.adoc @@ -244,7 +244,7 @@ print('Success!') == Evaluate on a Coset Time to use `+interpolate_poly+` and `+Polynomial.poly+` to evaluate -over the coset. Note that it is implemented fairely naively in our +over the coset. Note that it is implemented fairly naively in our Python module, so interpolation may take up to a minute. Indeed - interpolating and evaluating the trace polynomial is one of the most computationally-intensive steps in the STARK protocol, even when using diff --git a/chapters/book/modules/chapter_8/pages/part1_trace_and_low_degree_extension_rs.adoc b/chapters/book/modules/chapter_8/pages/part1_trace_and_low_degree_extension_rs.adoc index d2f2c9325..80d7d1190 100644 --- a/chapters/book/modules/chapter_8/pages/part1_trace_and_low_degree_extension_rs.adoc +++ b/chapters/book/modules/chapter_8/pages/part1_trace_and_low_degree_extension_rs.adoc @@ -299,7 +299,7 @@ way we got latexmath:[G] a few minutes ago. [source,rust] ---- -// Fix the following, make sure that the the element of H are powers of its generator (let's call it h) in +// Fix the following, make sure that the element of H are powers of its generator (let's call it h) in // order, that is - H[0] will be the unit (i.e 1), H[1] will be h (H's generator), H[2] will be H's // generator squared (h^2), etc. let h: FieldElement = todo!(); @@ -352,7 +352,7 @@ Success! == Evaluate on a Coset Time to use `+interpolate+` and `+eval+` to evaluate over the coset. -Note that it is implemented fairely naively in our Rust module, so +Note that it is implemented fairly naively in our Rust module, so interpolation may take some seconds. Indeed - interpolating and evaluating the trace polynomial is one of the most computationally-intensive steps in the STARK protocol, even when using diff --git a/chapters/book/modules/chapter_8/pages/part2_constraints.adoc b/chapters/book/modules/chapter_8/pages/part2_constraints.adoc index 8a8ff45e2..61c7c66db 100644 --- a/chapters/book/modules/chapter_8/pages/part2_constraints.adoc +++ b/chapters/book/modules/chapter_8/pages/part2_constraints.adoc @@ -314,7 +314,7 @@ where latexmath:[$\alpha_0, \alpha_1, \alpha_2$] are random field elements obtai from the verifier, or in our case - from the channel. Proving that (the rational function) latexmath:[$CP$] is a polynomial -guarantess, with high probability, that each of latexmath:[$p_0$], +guarantees, with high probability, that each of latexmath:[$p_0$], latexmath:[$p_1$], latexmath:[$p_2$] are themselves polynomials. In the next part, you will generate a proof for an equivalent fact. But @@ -347,7 +347,7 @@ print('Success!') Lastly, we evaluate latexmath:[$cp$] over the evaluation domain (`eval_domain`), build a Merkle tree on top of that and send its root -over the channel. This is similar to commiting on the LDE trace, as we +over the channel. This is similar to committing on the LDE trace, as we did at the end of part 1. Solution: diff --git a/chapters/book/modules/chapter_8/pages/part2_constraints_rs.adoc b/chapters/book/modules/chapter_8/pages/part2_constraints_rs.adoc index 37654aa8c..242828234 100644 --- a/chapters/book/modules/chapter_8/pages/part2_constraints_rs.adoc +++ b/chapters/book/modules/chapter_8/pages/part2_constraints_rs.adoc @@ -401,7 +401,7 @@ where latexmath:[$\alpha_0, \alpha_1, \alpha_2$] are random field elements obtai from the verifier, or in our case - from the channel. Proving that (the rational function) latexmath:[$CP$] is a polynomial -guarantess, with high probability, that each of latexmath:[$p_0$], +guarantees, with high probability, that each of latexmath:[$p_0$], latexmath:[$p_1$], latexmath:[$p_2$] are themselves polynomials. In the next part, you will generate a proof for an equivalent fact. But @@ -449,7 +449,7 @@ Success! Lastly, we evaluate latexmath:[$cp$] over the evaluation domain (`eval_domain`), build a Merkle tree on top of that and send its root -over the channel. This is similar to commiting on the LDE trace, as we +over the channel. This is similar to committing on the LDE trace, as we did at the end of part 1. [source,rust] diff --git a/chapters/book/modules/chapter_8/pages/trust_verification.adoc b/chapters/book/modules/chapter_8/pages/trust_verification.adoc index 084986218..410e9489a 100644 --- a/chapters/book/modules/chapter_8/pages/trust_verification.adoc +++ b/chapters/book/modules/chapter_8/pages/trust_verification.adoc @@ -40,7 +40,7 @@ We say that a proof system _solves_ CI if when updating the system from state A This pair of properties has a crucial implication to the principle of Inclusive Accountability discussed earlier. The verifier can accept the state transition suggested by the prover without making any assumptions about the integrity of the prover. In fact, the prover can run on faulty hardware, it can be closed source and it can be executed on a computer controlled by a malicious entity. The only thing that matters¹ is that the messages sent by the prover lead the verifier to accept the statement. If that is the case, we know that computational integrity holds. -== (extra) Probabistically Checkable Proofs. +== (extra) Probabilistically Checkable Proofs. When polling an election, the margin of error is independent from the sample size. That is, the sample size is what determines the margin of error and not the population size. The image below exemplifies this fact.+++
+++[#modular_arithmetic] == Margin of error @@ -49,9 +49,9 @@ The margin of error does not depend on the size of the population. image:marginError.png[marginError] -The same principle holds for mathematical proofs and for validating the integrity of a computation. If you want to sample a computation of a proof and know to a high degree of certainty (and a small margin of error) whether this computation was done with integrity (i.e. the proof is correct), the margin of error only depends on the sample size and not on how long or complicated the computation of proof is. This is huge: you can cjheck the validity of any proof (the integrity of any computation) by reading only a small number of bits of it. In other words, the computation size does not matter, what matter is the number of bits you sample. +The same principle holds for mathematical proofs and for validating the integrity of a computation. If you want to sample a computation of a proof and know to a high degree of certainty (and a small margin of error) whether this computation was done with integrity (i.e. the proof is correct), the margin of error only depends on the sample size and not on how long or complicated the computation of proof is. This is huge: you can check the validity of any proof (the integrity of any computation) by reading only a small number of bits of it. In other words, the computation size does not matter, what matter is the number of bits you sample. -This has implications for scalability. A single reliable smart contract in Ethereum monitors the operation of a very large computer, the prover, the processor of Starknet transactions. We do not care at all if that super computer is on top of unreliable sofware or untested hardware. All we have to do is trust the smart contract! +This has implications for scalability. A single reliable smart contract in Ethereum monitors the operation of a very large computer, the prover, the processor of Starknet transactions. We do not care at all if that super computer is on top of unreliable software or untested hardware. All we have to do is trust the smart contract! This was already discovered since the 1990s, however, it was not implemented because the computation to create a proof that could be verified efficiently was too hard. However, Eli Ben-Sasson and other scientists worked on the problem to create smaller and smaller proofs.