From 52965cbfedace726db58b206600a0b10f8e1fccf Mon Sep 17 00:00:00 2001 From: Mai Nakagawa Date: Fri, 20 May 2022 15:52:11 +0900 Subject: [PATCH] Apply Markdown's Bold and Italic best practice. --- de/1/functions.md | 2 +- en/1/arrays.md | 8 ++++---- en/1/datatypes.md | 2 +- en/1/events.md | 4 ++-- en/1/functions3.md | 8 ++++---- en/1/lessoncomplete.md | 4 ++-- en/1/math.md | 2 +- en/1/structs.md | 2 +- en/1/web3js.md | 2 +- en/10/00-overview.md | 10 +++++----- en/10/01.md | 6 +++--- en/10/02.md | 10 +++++----- en/10/03.md | 4 ++-- en/10/04.md | 6 +++--- en/10/05.md | 6 +++--- en/10/06.md | 2 +- en/10/07.md | 14 +++++++------- en/10/08.md | 6 +++--- en/10/09.md | 2 +- en/10/10.md | 14 +++++++------- en/10/lessoncomplete.md | 4 ++-- en/11/00-overview.md | 2 +- en/11/02.md | 2 +- en/11/04.md | 6 +++--- en/11/06.md | 2 +- en/11/10.md | 2 +- en/11/14.md | 6 +++--- en/14/00-overview.md | 6 +++--- en/14/01.md | 4 ++-- en/14/02.md | 2 +- en/14/03.md | 2 +- en/14/05.md | 2 +- en/14/06.md | 2 +- en/15/01.md | 2 +- en/15/09.md | 2 +- en/15/lessoncomplete.md | 2 +- en/16/01.md | 2 +- en/16/02.md | 2 +- en/16/06.md | 2 +- en/17/00-overview.md | 4 ++-- en/17/01.md | 2 +- en/17/03.md | 2 +- en/17/05.md | 8 ++++---- en/17/09.md | 6 +++--- en/17/15.md | 2 +- en/18/01.md | 6 +++--- en/19/00-overview.md | 2 +- en/2/10-interactingcontracts.md | 4 ++-- en/2/2-mappings.md | 4 ++-- en/2/5-inheritance.md | 4 ++-- en/2/7-storage.md | 4 ++-- en/3/01-externaldependencies.md | 2 +- en/3/02-ownable.md | 4 ++-- en/3/04-gas.md | 4 ++-- en/4/battle-02.md | 6 +++--- en/4/battle-08.md | 2 +- en/4/payable.md | 4 ++-- en/5/01-erc721-1.md | 10 +++++----- en/5/09-safemath-1.md | 6 +++--- en/5/13-comments.md | 2 +- en/5/14-wrappingitup.md | 2 +- en/6/01.md | 4 ++-- en/6/02.md | 8 ++++---- en/6/03.md | 4 ++-- en/7/02.md | 2 +- en/8/04.md | 2 +- en/9/01-erc721x.md | 8 ++++---- en/9/03-erc721x.md | 2 +- en/9/10-erc721x.md | 2 +- es/1/arrays.md | 8 ++++---- es/1/datatypes.md | 2 +- es/1/events.md | 4 ++-- es/1/functions3.md | 8 ++++---- es/1/lessoncomplete.md | 4 ++-- es/1/math.md | 2 +- es/1/structs.md | 2 +- es/1/web3js.md | 2 +- es/2/10-interactingcontracts.md | 4 ++-- es/2/2-mappings.md | 4 ++-- es/2/5-inheritance.md | 4 ++-- es/2/7-storage.md | 4 ++-- es/3/01-externaldependencies.md | 2 +- es/3/02-ownable.md | 4 ++-- es/3/04-gas.md | 4 ++-- es/4/battle-02.md | 6 +++--- es/4/battle-08.md | 2 +- es/4/payable.md | 2 +- es/5/01-erc721-1.md | 8 ++++---- es/5/13-comments.md | 2 +- es/6/01.md | 4 ++-- es/6/02.md | 8 ++++---- es/6/03.md | 4 ++-- fa/1/arrays.md | 4 ++-- fa/1/datatypes.md | 2 +- fa/1/events.md | 2 +- fa/1/functions3.md | 8 ++++---- fa/1/lessoncomplete.md | 4 ++-- fa/1/math.md | 2 +- fa/1/structs.md | 2 +- fa/1/web3js.md | 2 +- fa/10/00-overview.md | 10 +++++----- fa/10/01.md | 6 +++--- fa/10/02.md | 10 +++++----- fa/10/03.md | 4 ++-- fa/10/04.md | 6 +++--- fa/10/05.md | 6 +++--- fa/10/06.md | 2 +- fa/10/07.md | 14 +++++++------- fa/10/08.md | 6 +++--- fa/10/09.md | 2 +- fa/10/10.md | 14 +++++++------- fa/10/lessoncomplete.md | 4 ++-- fa/11/00-overview.md | 2 +- fa/11/02.md | 2 +- fa/11/04.md | 6 +++--- fa/11/06.md | 2 +- fa/11/10.md | 2 +- fa/11/14.md | 6 +++--- fa/14/00-overview.md | 6 +++--- fa/14/01.md | 4 ++-- fa/14/02.md | 2 +- fa/14/03.md | 2 +- fa/14/05.md | 2 +- fa/14/06.md | 2 +- fa/15/01.md | 2 +- fa/15/09.md | 2 +- fa/15/lessoncomplete.md | 2 +- fa/16/01.md | 2 +- fa/16/02.md | 2 +- fa/16/06.md | 2 +- fa/17/00-overview.md | 4 ++-- fa/17/01.md | 2 +- fa/17/03.md | 2 +- fa/17/05.md | 8 ++++---- fa/17/09.md | 6 +++--- fa/17/15.md | 2 +- fa/18/01.md | 6 +++--- fa/2/00-overview.md | 2 +- fa/2/1-overview.md | 4 ++-- fa/2/10-interactingcontracts.md | 4 ++-- fa/2/2-mappings.md | 4 ++-- fa/2/5-inheritance.md | 2 +- fa/2/7-storage.md | 4 ++-- fa/3/01-externaldependencies.md | 2 +- fa/3/02-ownable.md | 4 ++-- fa/3/04-gas.md | 2 +- fa/4/battle-02.md | 6 +++--- fa/4/battle-08.md | 2 +- fa/4/payable.md | 2 +- fa/5/01-erc721-1.md | 10 +++++----- fa/5/09-safemath-1.md | 6 +++--- fa/5/13-comments.md | 2 +- fa/5/14-wrappingitup.md | 2 +- fa/6/01.md | 4 ++-- fa/6/02.md | 8 ++++---- fa/6/03.md | 4 ++-- fa/7/02.md | 2 +- fa/8/04.md | 2 +- fa/9/01-erc721x.md | 8 ++++---- fa/9/03-erc721x.md | 2 +- fa/9/10-erc721x.md | 2 +- fa/lessoncomplete.md | 4 ++-- fr/1/arrays.md | 8 ++++---- fr/1/datatypes.md | 2 +- fr/1/events.md | 4 ++-- fr/1/functions3.md | 8 ++++---- fr/1/lessoncomplete.md | 4 ++-- fr/1/math.md | 2 +- fr/1/structs.md | 2 +- fr/1/web3js.md | 2 +- fr/2/10-interactingcontracts.md | 4 ++-- fr/2/2-mappings.md | 4 ++-- fr/2/5-inheritance.md | 4 ++-- fr/2/7-storage.md | 4 ++-- fr/3/01-externaldependencies.md | 2 +- fr/3/02-ownable.md | 4 ++-- fr/3/04-gas.md | 4 ++-- fr/4/battle-02.md | 6 +++--- fr/4/battle-08.md | 2 +- fr/4/payable.md | 2 +- fr/5/01-erc721-1.md | 8 ++++---- fr/5/09-safemath-1.md | 6 +++--- fr/5/13-comments.md | 2 +- fr/5/14-wrappingitup.md | 2 +- fr/6/01.md | 4 ++-- fr/6/02.md | 8 ++++---- fr/6/03.md | 4 ++-- it/1/arrays.md | 8 ++++---- it/1/datatypes.md | 2 +- it/1/events.md | 4 ++-- it/1/functions3.md | 8 ++++---- it/1/lessoncomplete.md | 6 +++--- it/1/math.md | 2 +- it/1/structs.md | 4 ++-- it/1/web3js.md | 2 +- it/2/10-interactingcontracts.md | 4 ++-- it/2/2-mappings.md | 4 ++-- it/2/5-inheritance.md | 4 ++-- it/2/7-storage.md | 4 ++-- it/3/01-externaldependencies.md | 2 +- it/3/02-ownable.md | 4 ++-- it/3/04-gas.md | 4 ++-- it/4/battle-02.md | 4 ++-- it/4/battle-08.md | 2 +- it/4/payable.md | 2 +- it/5/01-erc721-1.md | 12 ++++++------ it/5/09-safemath-1.md | 6 +++--- it/5/13-comments.md | 2 +- it/5/14-wrappingitup.md | 2 +- it/6/01.md | 4 ++-- it/6/02.md | 8 ++++---- it/6/03.md | 4 ++-- jp/1/arrays.md | 8 ++++---- jp/1/datatypes.md | 2 +- jp/1/events.md | 4 ++-- jp/1/functions3.md | 8 ++++---- jp/1/lessoncomplete.md | 4 ++-- jp/1/math.md | 2 +- jp/1/structs.md | 2 +- jp/1/web3js.md | 2 +- jp/2/10-interactingcontracts.md | 4 ++-- jp/2/2-mappings.md | 4 ++-- jp/2/5-inheritance.md | 4 ++-- jp/2/7-storage.md | 4 ++-- jp/3/01-externaldependencies.md | 2 +- jp/3/02-ownable.md | 4 ++-- jp/3/04-gas.md | 6 +++--- jp/4/battle-02.md | 6 +++--- jp/4/battle-08.md | 2 +- jp/4/payable.md | 2 +- jp/5/01-erc721-1.md | 10 +++++----- jp/5/09-safemath-1.md | 6 +++--- jp/5/13-comments.md | 2 +- jp/5/14-wrappingitup.md | 2 +- jp/6/01.md | 4 ++-- jp/6/02.md | 8 ++++---- jp/6/03.md | 4 ++-- jp/7/02.md | 2 +- jp/8/04.md | 2 +- jp/9/01-erc721x.md | 8 ++++---- jp/9/03-erc721x.md | 2 +- jp/9/10-erc721x.md | 2 +- ko/1/arrays.md | 8 ++++---- ko/1/datatypes.md | 2 +- ko/1/events.md | 4 ++-- ko/1/functions3.md | 8 ++++---- ko/1/lessoncomplete.md | 4 ++-- ko/1/math.md | 2 +- ko/1/structs.md | 2 +- ko/1/web3js.md | 2 +- ko/2/10-interactingcontracts.md | 4 ++-- ko/2/2-mappings.md | 4 ++-- ko/2/5-inheritance.md | 2 +- ko/2/7-storage.md | 4 ++-- ko/3/02-ownable.md | 4 ++-- ko/3/04-gas.md | 4 ++-- ko/4/battle-02.md | 6 +++--- ko/4/battle-08.md | 2 +- ko/4/payable.md | 2 +- ko/5/01-erc721-1.md | 10 +++++----- ko/5/09-safemath-1.md | 6 +++--- ko/5/13-comments.md | 2 +- ko/5/14-wrappingitup.md | 2 +- ko/6/01.md | 4 ++-- ko/6/02.md | 8 ++++---- ko/6/03.md | 4 ++-- ko/7/02.md | 2 +- ko/8/04.md | 2 +- ko/9/01-erc721x.md | 8 ++++---- ko/9/03-erc721x.md | 2 +- ko/9/10-erc721x.md | 2 +- no/1/arrays.md | 8 ++++---- no/1/datatypes.md | 2 +- no/1/events.md | 4 ++-- no/1/functions3.md | 8 ++++---- no/1/lessoncomplete.md | 4 ++-- no/1/math.md | 2 +- no/1/structs.md | 2 +- no/1/web3js.md | 2 +- no/2/10-interactingcontracts.md | 4 ++-- no/2/2-mappings.md | 4 ++-- no/2/5-inheritance.md | 4 ++-- no/2/7-storage.md | 4 ++-- no/3/01-externaldependencies.md | 2 +- no/3/02-ownable.md | 4 ++-- no/3/04-gas.md | 4 ++-- pl/1/arrays.md | 8 ++++---- pl/1/datatypes.md | 2 +- pl/1/events.md | 4 ++-- pl/1/functions3.md | 8 ++++---- pl/1/lessoncomplete.md | 4 ++-- pl/1/math.md | 2 +- pl/1/structs.md | 2 +- pl/1/web3js.md | 2 +- pt/1/arrays.md | 8 ++++---- pt/1/datatypes.md | 2 +- pt/1/events.md | 4 ++-- pt/1/functions3.md | 4 ++-- pt/1/lessoncomplete.md | 4 ++-- pt/1/math.md | 2 +- pt/1/structs.md | 2 +- pt/1/web3js.md | 2 +- pt/2/10-interactingcontracts.md | 4 ++-- pt/2/2-mappings.md | 4 ++-- pt/2/5-inheritance.md | 4 ++-- pt/2/7-storage.md | 4 ++-- pt/3/01-externaldependencies.md | 2 +- pt/3/02-ownable.md | 4 ++-- pt/3/04-gas.md | 4 ++-- pt/4/battle-02.md | 6 +++--- pt/4/battle-08.md | 2 +- pt/4/payable.md | 2 +- pt/5/01-erc721-1.md | 10 +++++----- pt/5/09-safemath-1.md | 6 +++--- pt/5/13-comments.md | 2 +- pt/5/14-wrappingitup.md | 2 +- pt/6/01-intro-web3.md | 4 ++-- pt/6/02-web3-providers.md | 8 ++++---- pt/6/03-talking-to-contracts.md | 4 ++-- pt/7/02.md | 2 +- ru/1/arrays.md | 8 ++++---- ru/1/datatypes.md | 2 +- ru/1/events.md | 4 ++-- ru/1/functions3.md | 8 ++++---- ru/1/lessoncomplete.md | 4 ++-- ru/1/math.md | 2 +- ru/1/structs.md | 2 +- ru/1/web3js.md | 2 +- ru/2/10-interactingcontracts.md | 4 ++-- ru/2/2-mappings.md | 4 ++-- ru/2/5-inheritance.md | 4 ++-- ru/2/7-storage.md | 4 ++-- ru/3/01-externaldependencies.md | 2 +- ru/3/02-ownable.md | 4 ++-- ru/3/04-gas.md | 4 ++-- ru/4/battle-02.md | 4 ++-- ru/4/battle-08.md | 2 +- ru/4/payable.md | 2 +- ru/5/01-erc721-1.md | 10 +++++----- ru/5/09-safemath-1.md | 8 ++++---- ru/5/13-comments.md | 2 +- ru/5/14-wrappingitup.md | 2 +- sk/1/arrays.md | 8 ++++---- sk/1/events.md | 2 +- sk/1/functions3.md | 8 ++++---- sk/1/lessoncomplete.md | 4 ++-- sk/1/math.md | 2 +- sk/1/structs.md | 2 +- sk/1/web3js.md | 2 +- sk/2/10-interactingcontracts.md | 4 ++-- sk/2/2-mappings.md | 4 ++-- sk/2/5-inheritance.md | 4 ++-- sk/2/7-storage.md | 4 ++-- sk/3/01-externaldependencies.md | 2 +- sk/3/02-ownable.md | 4 ++-- sk/3/04-gas.md | 4 ++-- sk/4/battle-02.md | 6 +++--- sk/4/battle-08.md | 2 +- sk/4/payable.md | 2 +- sk/5/01-erc721-1.md | 10 +++++----- sk/5/09-safemath-1.md | 6 +++--- sk/5/13-comments.md | 2 +- sk/5/14-wrappingitup.md | 2 +- sk/6/01.md | 4 ++-- sk/6/02.md | 8 ++++---- sk/6/03.md | 4 ++-- th/1/arrays.md | 8 ++++---- th/1/datatypes.md | 2 +- th/1/events.md | 4 ++-- th/1/functions3.md | 8 ++++---- th/1/lessoncomplete.md | 4 ++-- th/1/math.md | 2 +- th/1/structs.md | 2 +- th/1/web3js.md | 2 +- th/2/10-interactingcontracts.md | 4 ++-- th/2/2-mappings.md | 4 ++-- th/2/5-inheritance.md | 4 ++-- th/2/7-storage.md | 6 +++--- th/3/01-externaldependencies.md | 2 +- th/3/02-ownable.md | 4 ++-- th/3/04-gas.md | 4 ++-- th/4/battle-02.md | 6 +++--- th/4/battle-08.md | 2 +- th/4/payable.md | 2 +- th/5/01-erc721-1.md | 10 +++++----- th/5/09-safemath-1.md | 6 +++--- th/5/13-comments.md | 2 +- th/5/14-wrappingitup.md | 2 +- th/6/01.md | 4 ++-- th/6/02.md | 8 ++++---- th/6/03.md | 4 ++-- tr/1/arrays.md | 8 ++++---- tr/1/datatypes.md | 2 +- tr/1/events.md | 4 ++-- tr/1/functions3.md | 8 ++++---- tr/1/lessoncomplete.md | 4 ++-- tr/1/math.md | 2 +- tr/1/structs.md | 2 +- tr/1/web3js.md | 2 +- tr/2/10-interactingcontracts.md | 4 ++-- tr/2/2-mappings.md | 4 ++-- tr/2/5-inheritance.md | 4 ++-- tr/2/7-storage.md | 4 ++-- zh/1/arrays.md | 6 +++--- zh/1/datatypes.md | 2 +- zh/1/functions3.md | 6 +++--- zh/1/lessoncomplete.md | 4 ++-- zh/1/math.md | 2 +- zh/1/web3js.md | 2 +- zh/10/00-overview.md | 6 +++--- zh/10/01.md | 4 ++-- zh/10/02.md | 10 +++++----- zh/10/03.md | 4 ++-- zh/10/04.md | 6 +++--- zh/10/05.md | 8 ++++---- zh/10/lessoncomplete.md | 4 ++-- zh/11/00-overview.md | 2 +- zh/11/02.md | 2 +- zh/11/04.md | 6 +++--- zh/11/06.md | 2 +- zh/11/10.md | 2 +- zh/11/14.md | 6 +++--- zh/2/5-inheritance.md | 2 +- zh/2/7-storage.md | 2 +- zh/3/01-externaldependencies.md | 2 +- zh/3/04-gas.md | 6 +++--- zh/4/battle-02.md | 4 ++-- zh/4/battle-08.md | 2 +- zh/4/payable.md | 2 +- zh/5/01-erc721-1.md | 10 +++++----- zh/5/09-safemath-1.md | 6 +++--- zh/5/13-comments.md | 2 +- zh/5/14-wrappingitup.md | 2 +- zh/6/01.md | 4 ++-- zh/6/02.md | 10 +++++----- zh/6/03.md | 4 ++-- zh/6/09.md | 2 +- zh/7/02.md | 2 +- zh/8/04.md | 2 +- zh/9/01-erc721x.md | 8 ++++---- zh/9/03-erc721x.md | 2 +- zh/9/10-erc721x.md | 2 +- 442 files changed, 905 insertions(+), 905 deletions(-) diff --git a/de/1/functions.md b/de/1/functions.md index b2a723908b..cbe06b470d 100755 --- a/de/1/functions.md +++ b/de/1/functions.md @@ -55,6 +55,6 @@ You would call this function like so: In our app, we're going to need to be able to create some zombies. Let's create a function for that. -1. Create a function named `createZombie`. It should take two parameters: **__name_** (a `string`), and **__dna_** (a `uint`). +1. Create a function named `createZombie`. It should take two parameters: ***_name*** (a `string`), and ***_dna*** (a `uint`). Leave the body empty for now — we'll fill it in later. \ No newline at end of file diff --git a/en/1/arrays.md b/en/1/arrays.md index 72b86b8bb3..1329611ad0 100644 --- a/en/1/arrays.md +++ b/en/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -When you want a collection of something, you can use an **_array_**. There are two types of arrays in Solidity: **_fixed_** arrays and **_dynamic_** arrays: +When you want a collection of something, you can use an ***array***. There are two types of arrays in Solidity: ***fixed*** arrays and ***dynamic*** arrays: ``` // Array with a fixed length of 2 elements: @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -You can also create an array of **_structs_**. Using the previous chapter's `Person` struct: +You can also create an array of ***structs***. Using the previous chapter's `Person` struct: ``` Person[] people; // dynamic Array, we can keep adding to it @@ -60,7 +60,7 @@ Remember that state variables are stored permanently in the blockchain? So creat ## Public Arrays -You can declare an array as `public`, and Solidity will automatically create a **_getter_** method for it. The syntax looks like: +You can declare an array as `public`, and Solidity will automatically create a ***getter*** method for it. The syntax looks like: ``` Person[] public people; @@ -72,4 +72,4 @@ Other contracts would then be able to read from, but not write to, this array. S We're going to want to store an army of zombies in our app. And we're going to want to show off all our zombies to other apps, so we'll want it to be public. -1. Create a public array of `Zombie` **_structs_**, and name it `zombies`. +1. Create a public array of `Zombie` ***structs***, and name it `zombies`. diff --git a/en/1/datatypes.md b/en/1/datatypes.md index f9ebf65379..0b24e4e6e9 100644 --- a/en/1/datatypes.md +++ b/en/1/datatypes.md @@ -25,7 +25,7 @@ material: Great job! Now that we've got a shell for our contract, let's learn about how Solidity deals with variables. -**_State variables_** are permanently stored in contract storage. This means they're written to the Ethereum blockchain. Think of them like writing to a DB. +***State variables*** are permanently stored in contract storage. This means they're written to the Ethereum blockchain. Think of them like writing to a DB. ##### Example: ``` diff --git a/en/1/events.md b/en/1/events.md index 2dd9dc28f3..6ba057a50e 100644 --- a/en/1/events.md +++ b/en/1/events.md @@ -73,9 +73,9 @@ material: } --- -Our contract is almost finished! Now let's add an **_event_**. +Our contract is almost finished! Now let's add an ***event***. -**_Events_** are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be 'listening' for certain events and take action when they happen. +***Events*** are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be 'listening' for certain events and take action when they happen. Example: diff --git a/en/1/functions3.md b/en/1/functions3.md index ae34242632..96ef240816 100644 --- a/en/1/functions3.md +++ b/en/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -In this chapter, we're going to learn about function **_return values_**, and function modifiers. +In this chapter, we're going to learn about function ***return values***, and function modifiers. ## Return Values @@ -73,13 +73,13 @@ In Solidity, the function declaration contains the type of the return value (in The above function doesn't actually change state in Solidity — e.g. it doesn't change any values or write anything. -So in this case we could declare it as a **_view_** function, meaning it's only viewing the data but not modifying it: +So in this case we could declare it as a ***view*** function, meaning it's only viewing the data but not modifying it: ``` function sayHello() public view returns (string memory) { ``` -Solidity also contains **_pure_** functions, which means you're not even accessing any data in the app. Consider the following: +Solidity also contains ***pure*** functions, which means you're not even accessing any data in the app. Consider the following: ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -This function doesn't even read from the state of the app — its return value depends only on its function parameters. So in this case we would declare the function as **_pure_**. +This function doesn't even read from the state of the app — its return value depends only on its function parameters. So in this case we would declare the function as ***pure***. > Note: It may be hard to remember when to mark functions as pure/view. Luckily the Solidity compiler is good about issuing warnings to let you know when you should use one of these modifiers. diff --git a/en/1/lessoncomplete.md b/en/1/lessoncomplete.md index 9c9cdd0ee3..ebc270c9a4 100644 --- a/en/1/lessoncomplete.md +++ b/en/1/lessoncomplete.md @@ -14,8 +14,8 @@ This is just the beginning. We will be releasing a new CryptoZombies lesson each ### 1. Sign in to save your progress -**_Sign in_** to save your progress by clicking the "Save Progress" link at the top of the page. We'll let you know as soon as we add a new lesson. +***Sign in*** to save your progress by clicking the "Save Progress" link at the top of the page. We'll let you know as soon as we add a new lesson. ### 2. Share your zombie with your friends -**_Share_** your zombie on Twitter, blah blah, etc. (Need to insert images / links) +***Share*** your zombie on Twitter, blah blah, etc. (Need to insert images / links) diff --git a/en/1/math.md b/en/1/math.md index 8082bd9934..5666f6c3b3 100644 --- a/en/1/math.md +++ b/en/1/math.md @@ -34,7 +34,7 @@ Math in Solidity is pretty straightforward. The following operations are the sam * Division: `x / y` * Modulus / remainder: `x % y` _(for example, `13 % 5` is `3`, because if you divide 5 into 13, 3 is the remainder)_ -Solidity also supports an **_exponential operator_** (i.e. "x to the power of y", x^y): +Solidity also supports an ***exponential operator*** (i.e. "x to the power of y", x^y): ``` uint x = 5 ** 2; // equal to 5^2 = 25 diff --git a/en/1/structs.md b/en/1/structs.md index 6b52731a6f..d029538575 100644 --- a/en/1/structs.md +++ b/en/1/structs.md @@ -32,7 +32,7 @@ material: } --- -Sometimes you need a more complex data type. For this, Solidity provides **_structs_**: +Sometimes you need a more complex data type. For this, Solidity provides ***structs***: ``` struct Person { diff --git a/en/1/web3js.md b/en/1/web3js.md index 65778af133..5e915d42fa 100644 --- a/en/1/web3js.md +++ b/en/1/web3js.md @@ -12,7 +12,7 @@ material: Our Solidity contract is complete! Now we need to write a JavaScript frontend that interacts with the contract. -Ethereum has a JavaScript library called **_Web3.js_**. +Ethereum has a JavaScript library called ***Web3.js***. In a later lesson, we'll go over in depth how to deploy a contract and set up Web3.js. But for now let's just look at some sample code for how Web3.js would interact with our deployed contract. diff --git a/en/10/00-overview.md b/en/10/00-overview.md index 85e9142288..e0e59afd5d 100644 --- a/en/10/00-overview.md +++ b/en/10/00-overview.md @@ -11,16 +11,16 @@ Remember that we promised to teach you how to deploy a smart contract? It's been a while, but the time has come! -In this lesson, we will be teaching you how to deploy to **_Ethereum_** using **_Truffle_**. +In this lesson, we will be teaching you how to deploy to ***Ethereum*** using ***Truffle***. -And this is not all. You are going to learn how to deploy your smart contracts to **_Loom_** as well😎. +And this is not all. You are going to learn how to deploy your smart contracts to ***Loom*** as well😎. -Why deploy to **_Loom_**? After all, **_Ethereum_** is the most secure network. +Why deploy to ***Loom***? After all, ***Ethereum*** is the most secure network. Yes, we totally agree with that. But on Ethereum each transaction costs _gas_, so your users will have to pay fees for each and every transaction. Also, they will have to wait at least 10 seconds for each transaction to be confirmed. -In a nutshell, **_on Ethereum, all transactions benefit from the same security guarantees_**. For something like a user-facing DApp or a game, this level of security isn't always a requirement. In fact, it just harms the user experience. +In a nutshell, ***on Ethereum, all transactions benefit from the same security guarantees***. For something like a user-facing DApp or a game, this level of security isn't always a requirement. In fact, it just harms the user experience. -On **_Loom_**, users have access to much speedier and gas-free transactions. This makes **_Loom_** a much better fit for something like a game or a user-facing DApp. +On ***Loom***, users have access to much speedier and gas-free transactions. This makes ***Loom*** a much better fit for something like a game or a user-facing DApp. Enough talking! Let's get started😉 diff --git a/en/10/01.md b/en/10/01.md index 3cd14e6c18..28a1162c21 100644 --- a/en/10/01.md +++ b/en/10/01.md @@ -23,7 +23,7 @@ So you've worked your way through our previous lessons. Awesome! This means you' But an important piece of the puzzle is still missing. -That's right... you still have to learn how to **_deploy a smart contract_**. +That's right... you still have to learn how to ***deploy a smart contract***. Now, if you have a background in front-end development, you are probably well accustomed to the multitude of tools like *Webpack, Gulp, or Browserify* that make a developer's life simpler. @@ -31,12 +31,12 @@ But what tools do **Solidity** developers use? ## Truffle -**_Truffle_** is the most popular blockchain development framework for good reason - it's packed with lots of useful features: +***Truffle*** is the most popular blockchain development framework for good reason - it's packed with lots of useful features: - easy smart contract compilation - automated ABI generation - integrated smart contract testing - there's even support for **Mocha** and **Chai**! -- support for multiple networks - code can be deployed to Rinkeby, **_Ethereum_** or even to **_Loom_**. We'll walk you through this later😉 +- support for multiple networks - code can be deployed to Rinkeby, ***Ethereum*** or even to ***Loom***. We'll walk you through this later😉 Provided that `npm` and `node` have been installed on your computer, we'll want you to install **Truffle** and make it available globally. diff --git a/en/10/02.md b/en/10/02.md index 07a85a4d40..17d3d6e783 100644 --- a/en/10/02.md +++ b/en/10/02.md @@ -48,15 +48,15 @@ Don't worry, learning to use **Truffle** won't eat your brains. This chapter wil So, running the `truffle init` command inside of the `CryptoZombies` directory, should create several directories and some JavaScript and Solidity files. Let's have a closer look: - - **_contracts_**: this is the place where **Truffle** expects to find all our smart contracts. To keep the code organized, we can even create nested folders such as `contracts/tokens`. Pretty neat😉. + - ***contracts***: this is the place where **Truffle** expects to find all our smart contracts. To keep the code organized, we can even create nested folders such as `contracts/tokens`. Pretty neat😉. >Note: `truffle init` should automatically create a contract called `Migrations.sol` and the corresponding migration file. We'll explain them a bit later. - - **_migrations_**: a migration is a JavaScript file that tells **Truffle** how to deploy a smart contract. + - ***migrations***: a migration is a JavaScript file that tells **Truffle** how to deploy a smart contract. - - **_test_**: here we are expected to put the unit tests which will be JavaScript or Solidity files. Remember, once a contract is deployed it can't be changed, making it essential that we test our smart contracts before we deploy them. + - ***test***: here we are expected to put the unit tests which will be JavaScript or Solidity files. Remember, once a contract is deployed it can't be changed, making it essential that we test our smart contracts before we deploy them. - - **_truffle.js_** and **_truffle-config.js_**: config files used to store the network settings for deployment. **Truffle** needs two config files because on Windows having both `truffle.js` and `truffle.exe` in the same folder might generate conflicts. Long story short - if you are running Windows, it is advised to delete `truffle.js` and use `truffle-config.js` as the default config file. Check out **Truffle**'s official documentation to further your understanding. + - ***truffle.js*** and ***truffle-config.js***: config files used to store the network settings for deployment. **Truffle** needs two config files because on Windows having both `truffle.js` and `truffle.exe` in the same folder might generate conflicts. Long story short - if you are running Windows, it is advised to delete `truffle.js` and use `truffle-config.js` as the default config file. Check out **Truffle**'s official documentation to further your understanding. But why should I use this directory structure? I'm not used to it and it looks complicated... @@ -67,7 +67,7 @@ Second, by adhering to this convention your projects will be easily understood b ## truffle-hdwallet-provider -In this lesson, we will be using _Infura_ to deploy our code to **_Ethereum_**. This way, we can run the application without needing to set up our own **_Ethereum_** node or wallet. +In this lesson, we will be using _Infura_ to deploy our code to ***Ethereum***. This way, we can run the application without needing to set up our own ***Ethereum*** node or wallet. However, to keep things secure, _Infura_ does not manage the private keys, which means it can't sign transactions on our behalf. Since deploying a smart contract requires **Truffle** to sign transactions, we are going to need a tool called `truffle-hdwallet-provider`. Its only purpose is to handle the transaction signing. >Note: Maybe you are asking why we chose not to install `truffle-hdwallet-provider` in the previous chapter using something like: diff --git a/en/10/03.md b/en/10/03.md index 98cda54f06..9f62a6d925 100644 --- a/en/10/03.md +++ b/en/10/03.md @@ -27,7 +27,7 @@ Congratulations! Now that we've put the project structure in place and set up `t Why do we need to compile, you ask? -The _Ethereum Virtual Machine_ can't directly understand Solidity source code as we write it. Thus, we need to run a compiler that will "translate" our smart contract into machine-readable **_bytecode_**. The virtual machine then executes the bytecode, and completes the actions required by our smart contract. +The _Ethereum Virtual Machine_ can't directly understand Solidity source code as we write it. Thus, we need to run a compiler that will "translate" our smart contract into machine-readable ***bytecode***. The virtual machine then executes the bytecode, and completes the actions required by our smart contract. Curious about how does the bytecode look like? Let's take a look: @@ -51,7 +51,7 @@ function add(uint16 a, uint16 b) internal returns (uint16) { } ``` -If we're going to compile this function, the Solidity compiler will throw a **_warning_**: +If we're going to compile this function, the Solidity compiler will throw a ***warning***: ``` safemath.sol:110:11: Warning: Function state mutability can be restricted to pure diff --git a/en/10/04.md b/en/10/04.md index 204e9b51e3..c9ba2bab82 100644 --- a/en/10/04.md +++ b/en/10/04.md @@ -18,15 +18,15 @@ material: }; --- -Normally at this point, before deploying to **_Ethereum_**, you would want to test your smart contract locally. You can do this using a tool called Ganache, which sets up a local **_Ethereum_** network. +Normally at this point, before deploying to ***Ethereum***, you would want to test your smart contract locally. You can do this using a tool called Ganache, which sets up a local ***Ethereum*** network. However, while testing is very important, it requires an entire lesson to cover — so we’re just going to stick to deployment in this lesson. If you're so inclined, to learn more about testing, I recommend our very own Testing Smart Contracts with Truffle lesson. -To deploy to **_Ethereum_** we will have to create something called a **migration**. +To deploy to ***Ethereum*** we will have to create something called a **migration**. -Migrations are JavaScript files that help **Truffle** deploy the code to **_Ethereum_**. Note that `truffle init` created a special contract called `Migrations.sol` that keeps track of the changes you're making to your code. The way it works is that the history of changes is saved onchain. Thus, there's no way you will ever deploy the same code twice. +Migrations are JavaScript files that help **Truffle** deploy the code to ***Ethereum***. Note that `truffle init` created a special contract called `Migrations.sol` that keeps track of the changes you're making to your code. The way it works is that the history of changes is saved onchain. Thus, there's no way you will ever deploy the same code twice. ## Creating a New Migration diff --git a/en/10/05.md b/en/10/05.md index 0f8b3bf433..8baba396cb 100644 --- a/en/10/05.md +++ b/en/10/05.md @@ -74,11 +74,11 @@ Awesome! You've successfully compiled the source code and created a migration fi There is still one more thing to do before we can deploy. We'll have to edit the configuration file to tell **Truffle** the networks we want to deploy to. -Wait a minute, I thought there was only one **_Ethereum_** network. What am I missing here? +Wait a minute, I thought there was only one ***Ethereum*** network. What am I missing here? ## Ethereum Test Networks -Several public **_Ethereum_** test networks let you test your contracts for free before you deploy them to the main net (remember once you deploy a contract to the main net it can't be altered). These test networks use a different consensus algorithm to the main net (usually PoA), and Ether is free to encourage thorough testing. +Several public ***Ethereum*** test networks let you test your contracts for free before you deploy them to the main net (remember once you deploy a contract to the main net it can't be altered). These test networks use a different consensus algorithm to the main net (usually PoA), and Ether is free to encourage thorough testing. In this lesson, we will be using Rinkeby, a public test network created by The Ethereum Foundation. @@ -133,7 +133,7 @@ Config files are often pushed to GitHub, where anyone can see them, leaving you ### Set up Truffle for Rinkeby and Ethereum main net -Next, to make sure **Truffle** "knows" the networks we want to deploy to, we will have to create two separate objects- one for Rinkeby and the other one for the **_Ethereum_** main net: +Next, to make sure **Truffle** "knows" the networks we want to deploy to, we will have to create two separate objects- one for Rinkeby and the other one for the ***Ethereum*** main net: ```JavaScript networks: { diff --git a/en/10/06.md b/en/10/06.md index dc573142b8..51333c1e91 100644 --- a/en/10/06.md +++ b/en/10/06.md @@ -28,7 +28,7 @@ material: Saving artifacts... --- -Great! That was the difficult part — actually deploying to Rinkeby is going to be straightforward. To do this, **Truffle** relies on something called a **_migration_**. +Great! That was the difficult part — actually deploying to Rinkeby is going to be straightforward. To do this, **Truffle** relies on something called a ***migration***. # Migrations diff --git a/en/10/07.md b/en/10/07.md index 367a83c554..01241cd6af 100644 --- a/en/10/07.md +++ b/en/10/07.md @@ -21,21 +21,21 @@ Even if **Truffle** helped a lot, this is no small feat, so pat yourself on the ## Loom Basechain -Now, if you want to build DApps on **_Ethereum_**, there's one thing you should be aware of - on the main net, users are required to **_pay gas fees for every transaction_**. But this isn't ideal for a user-facing DApp or a game. It can easily ruin the user experience. +Now, if you want to build DApps on ***Ethereum***, there's one thing you should be aware of - on the main net, users are required to ***pay gas fees for every transaction***. But this isn't ideal for a user-facing DApp or a game. It can easily ruin the user experience. -Conversely, on **_Loom_**, your users can have much speedier and gas-free transactions, making it a much better fit for games and other non-financial applications. +Conversely, on ***Loom***, your users can have much speedier and gas-free transactions, making it a much better fit for games and other non-financial applications. -This means that your **_Loom_** zombies will be fast zombies! +This means that your ***Loom*** zombies will be fast zombies! -That's not all - deploying to **_Loom_** is no different from deploying to Rinkeby, or to the Ethereum main net. If you know how to do one, you also know how to do the other. +That's not all - deploying to ***Loom*** is no different from deploying to Rinkeby, or to the Ethereum main net. If you know how to do one, you also know how to do the other. -In the next chapters, we'll be walking you through deploying to **_Loom_**. +In the next chapters, we'll be walking you through deploying to ***Loom***. ## loom-truffle-provider -We at **_Loom_** are using **Truffle** to build, test, and deploy our smart contracts. To make our life easier, we developed something called a **_provider_** that lets Truffle deploy to **_Loom_** just like it deploys to Rinkeby or Ethereum main net. +We at ***Loom*** are using **Truffle** to build, test, and deploy our smart contracts. To make our life easier, we developed something called a ***provider*** that lets Truffle deploy to ***Loom*** just like it deploys to Rinkeby or Ethereum main net. -Without delving too much into details, the provider works like a bridge that makes Web3 calls compatible with **_Loom_**. The beauty of it is that, to use it, you don't have to understand how it works under the hood. +Without delving too much into details, the provider works like a bridge that makes Web3 calls compatible with ***Loom***. The beauty of it is that, to use it, you don't have to understand how it works under the hood. # Put it to the test: diff --git a/en/10/08.md b/en/10/08.md index caca2a669b..a891dd64a6 100644 --- a/en/10/08.md +++ b/en/10/08.md @@ -89,9 +89,9 @@ material: }; --- -In this chapter, we’re going to deploy our smart contract to the **_Loom_** Testnet, but before doing the deployment, some prep work is needed. +In this chapter, we’re going to deploy our smart contract to the ***Loom*** Testnet, but before doing the deployment, some prep work is needed. -First, we should create our own **_Loom_** private key. The easiest way to do it is by downloading and installing **_Loom_** according to this tutorial. +First, we should create our own ***Loom*** private key. The easiest way to do it is by downloading and installing ***Loom*** according to this tutorial. Next, creating a private key is as as simple as this: @@ -113,7 +113,7 @@ The first thing we are required to do is to initialize `loom-truffle-provider`. const LoomTruffleProvider = require('loom-truffle-provider'); ``` -Next, just as we did in chapter 5, we'll have to let **_Truffle_** know how to deploy on **_Loom_** testnet. To do so, let's add a new object to `truffle.js` +Next, just as we did in chapter 5, we'll have to let ***Truffle*** know how to deploy on ***Loom*** testnet. To do so, let's add a new object to `truffle.js` ```JavaScript loom_testnet: { diff --git a/en/10/09.md b/en/10/09.md index f65826bb38..60470578c8 100644 --- a/en/10/09.md +++ b/en/10/09.md @@ -61,7 +61,7 @@ material: --- - Now we have everything in place to deploy to **_Loom_** Testnet with just one command. + Now we have everything in place to deploy to ***Loom*** Testnet with just one command. # Put it to the test: diff --git a/en/10/10.md b/en/10/10.md index 9ba2ec686f..2eead3bf9e 100644 --- a/en/10/10.md +++ b/en/10/10.md @@ -63,16 +63,16 @@ material: --- -Congratulations! You've successfully deployed to **_Loom_** Testnet. But can you guess what's coming next?🤔 +Congratulations! You've successfully deployed to ***Loom*** Testnet. But can you guess what's coming next?🤔 -Yup, you're right! This chapter will walk you through the process of deploying to **_Basechain_** (that is our Mainnet). +Yup, you're right! This chapter will walk you through the process of deploying to ***Basechain*** (that is our Mainnet). Here's a brief rundown of what you'll do in this chapter: - Create a new private key. - Creating a new private key is pretty straightforward. But since we're talking about deploying to the main net, it's time to get more serious about security. Thus, we'll show you how to securely pass the private key to **Truffle**. -- Tell **Truffle** how to deploy to **_Basechain_** by adding a new object to the `truffle.js` configuration file. -- Whitelist your deployment keys so you can deploy to **_Basechain_**. +- Tell **Truffle** how to deploy to ***Basechain*** by adding a new object to the `truffle.js` configuration file. +- Whitelist your deployment keys so you can deploy to ***Basechain***. - Lastly, we wrap everything up by actually deploying the smart contract. ### Create a new private key @@ -122,7 +122,7 @@ Pretty straightforward, isn't it? ### Tell Truffle how to deploy to Basechain -Now, we must let **Truffle** know how to deploy to **_Basechain_**. To do so, let's add a new object to `truffle.js` +Now, we must let **Truffle** know how to deploy to ***Basechain***. To do so, let's add a new object to `truffle.js` ```js basechain: { @@ -197,9 +197,9 @@ module.exports = { ### Whitelist your deployment keys -Before deploying to **_Basechain_**, you need to whitelist your keys by following the instructions from our Deploy to Mainnet guide. Don't worry about it right now, but keep in mind that you have to do this after you finish this tutorial. +Before deploying to ***Basechain***, you need to whitelist your keys by following the instructions from our Deploy to Mainnet guide. Don't worry about it right now, but keep in mind that you have to do this after you finish this tutorial. -We've gone ahead and performed all these steps and now we are ready to deploy to **_Basechain_**! +We've gone ahead and performed all these steps and now we are ready to deploy to ***Basechain***! # Put it to the test: diff --git a/en/10/lessoncomplete.md b/en/10/lessoncomplete.md index 9cc39b2c62..18d3bfe928 100644 --- a/en/10/lessoncomplete.md +++ b/en/10/lessoncomplete.md @@ -9,9 +9,9 @@ Well done!👏🏻👏🏻👏🏻 You mastered the art of deploying smart contracts using **Truffle**! -Remember, building on top of **_Loom_** brings you faster, gas-free transactions that make it the perfect choice for creating blockchain games and user-facing DApps. At the same time, your users will enjoy the guaranteed security that Ethereum provides! +Remember, building on top of ***Loom*** brings you faster, gas-free transactions that make it the perfect choice for creating blockchain games and user-facing DApps. At the same time, your users will enjoy the guaranteed security that Ethereum provides! -Another thing to remember is how similar deploying to **_Loom_** is to deploying to the Ethereum mainnet. You now know how to do both, just be careful how you choose which one to use for your next project😉. +Another thing to remember is how similar deploying to ***Loom*** is to deploying to the Ethereum mainnet. You now know how to do both, just be careful how you choose which one to use for your next project😉. Anyway, this was just an example — we made several decisions that simplified things a bit to make the lesson easier to understand. diff --git a/en/11/00-overview.md b/en/11/00-overview.md index a1385a8a54..3021136f3a 100644 --- a/en/11/00-overview.md +++ b/en/11/00-overview.md @@ -13,7 +13,7 @@ So, go ahead and deploy the game to the mainnet. Enjoy your success! Hang on a moment... There are a _few things_ you might have already thought of. After all, once contracts get deployed to the mainnet, they will live there forever. If there are mistakes in them, they will still live on as well. Like undead zombies. -Mistakes, or _**bugs**_, happen to every coder, no matter how skilled. It's unlikely that you would make a major mistake like giving attacking zombies a 100% chance of victory, but it could happen. +Mistakes, or ***bugs***, happen to every coder, no matter how skilled. It's unlikely that you would make a major mistake like giving attacking zombies a 100% chance of victory, but it could happen. Clearly giving the attacking side 100% of wins would mean what you had written was no longer a game, or even any fun at all. A bug like this would kill your game dead, and no promise of juicy brains would drag your zombies from their graves. diff --git a/en/11/02.md b/en/11/02.md index ae1c515eb7..efec3071cf 100644 --- a/en/11/02.md +++ b/en/11/02.md @@ -35,7 +35,7 @@ Say there was a contract called `MyAwesomeContract`. We could do something like const MyAwesomeContract = artifacts.require(“MyAwesomeContract”); ``` -The function returns something called a **_contract abstraction_**. In a nutshell, a _contract abstraction_ hides the complexity of interacting with **Ethereum** and provides a convenient _JavaScript_ interface to our _Solidity_ smart contract. We'll be using it in the next chapters. +The function returns something called a ***contract abstraction***. In a nutshell, a _contract abstraction_ hides the complexity of interacting with **Ethereum** and provides a convenient _JavaScript_ interface to our _Solidity_ smart contract. We'll be using it in the next chapters. ### The contract() function diff --git a/en/11/04.md b/en/11/04.md index 9dc0182330..122746a98b 100644 --- a/en/11/04.md +++ b/en/11/04.md @@ -34,11 +34,11 @@ Great job! Now that we have a shell for our first test, let me walk you through Usually, every test has the following phases: - 1. **_set up_**: in which we define the initial state and initialize the inputs. + 1. ***set up***: in which we define the initial state and initialize the inputs. - 2. **_act_**: where we actually test the code. Always make sure you _test only one thing_. + 2. ***act***: where we actually test the code. Always make sure you _test only one thing_. - 3. **_assert_:** where we check the results. + 3. ***assert_:** where we check the results. Lets look at what our test should do in some more detail. diff --git a/en/11/06.md b/en/11/06.md index 6377f85ed9..bb0776817a 100644 --- a/en/11/06.md +++ b/en/11/06.md @@ -95,7 +95,7 @@ We'll continue fleshing out this function in the next chapter! ### 🧟‍♂️Here be... zombies of every kind!!!🧟‍♂️ -If you really, really want to **_achieve mastery_**, go ahead and read on. Otherwise... just click next and off you go to the next chapter. +If you really, really want to ***achieve mastery***, go ahead and read on. Otherwise... just click next and off you go to the next chapter. You still around?😁 diff --git a/en/11/10.md b/en/11/10.md index 6d5d3f4c11..e44278c54a 100644 --- a/en/11/10.md +++ b/en/11/10.md @@ -120,7 +120,7 @@ In a nutshell, we have to test two different scenarios: - Alice approves Bob to take the ERC721 token. Next, Alice transfers the ERC721 token. -The difference in the two scenarios lies with _**who**_ calls the actual transfer, Alice or Bob. +The difference in the two scenarios lies with ***who*** calls the actual transfer, Alice or Bob. We've made it look simple, right? diff --git a/en/11/14.md b/en/11/14.md index fe2a7b29dd..2fbcd7f531 100644 --- a/en/11/14.md +++ b/en/11/14.md @@ -107,11 +107,11 @@ material: Impressive! You must have been practicing. -Now, this tutorial would not be complete without showing you how to test against **_Loom_** Testnet. +Now, this tutorial would not be complete without showing you how to test against ***Loom*** Testnet. -Recall from our previous lessons that, on **_Loom_**, users have access to much speedier and gas-free transactions than on **Ethereum**. This makes DAppChains a much better fit for something like a game or a user-facing DApp. +Recall from our previous lessons that, on ***Loom***, users have access to much speedier and gas-free transactions than on **Ethereum**. This makes DAppChains a much better fit for something like a game or a user-facing DApp. -And you know what? Deploying and testing against **Loom** is not different at all. We've gone ahead and summed up what needs to be done so you can test against **_Loom_**. Let's have a quick look. +And you know what? Deploying and testing against **Loom** is not different at all. We've gone ahead and summed up what needs to be done so you can test against ***Loom***. Let's have a quick look. ## Configure Truffle for Testing on **Loom** diff --git a/en/14/00-overview.md b/en/14/00-overview.md index ef8afed2aa..534b317426 100644 --- a/en/14/00-overview.md +++ b/en/14/00-overview.md @@ -5,14 +5,14 @@ path: solidity_advanced publishedOn: Cryptozombies --- -By completing the previous tutorials you've demonstrated a good grasp of Solidity and JavaScript; and you are probably well on your way to building your first dapp. If so, you may already have noticed that smart contracts can't directly access data from the outside world through an HTTP request or something similar. Instead, smart contracts pull data through something called an **_oracle_**. +By completing the previous tutorials you've demonstrated a good grasp of Solidity and JavaScript; and you are probably well on your way to building your first dapp. If so, you may already have noticed that smart contracts can't directly access data from the outside world through an HTTP request or something similar. Instead, smart contracts pull data through something called an ***oracle***. -This lesson is the first in the sequence of three lessons that aim to show how you can **_build and interact with an oracle_**. +This lesson is the first in the sequence of three lessons that aim to show how you can ***build and interact with an oracle***. In the first two lessons, we will be teaching you to build and interact with the simplest possible oracle that allows only one user, its owner, to fetch data from Binance's public API. That said, I have a question for you: why would users trust your oracle?🤔🤔🤔 -The quick answer is that they wouldn't. At least not until there **_social trust_** or you come up with a **_decentralized version_**. Thus, in the third lesson, we'll show you how to make your oracle more decentralized. But, for now, let's start with the beginning. +The quick answer is that they wouldn't. At least not until there ***social trust*** or you come up with a ***decentralized version***. Thus, in the third lesson, we'll show you how to make your oracle more decentralized. But, for now, let's start with the beginning. Time to write some code! diff --git a/en/14/01.md b/en/14/01.md index 2f65e6d138..7694c04a79 100644 --- a/en/14/01.md +++ b/en/14/01.md @@ -38,7 +38,7 @@ material: run `npm audit fix` to fix them, or `npm audit` for details --- -Before we begin, let's be clear: this is an intermediate lesson, and it requires a bit of **_JavaScript_** and **_Solidity_** knowledge. +Before we begin, let's be clear: this is an intermediate lesson, and it requires a bit of ***JavaScript*** and ***Solidity*** knowledge. If you're new to Solidity, it's highly recommended that you go over the first lessons before starting this one. @@ -48,7 +48,7 @@ If you are not comfortable with **JavaScript**, consider going through a tutoria Now, let's suppose you're building a DeFi dapp, and want to give your users the ability to withdraw ETH worth a certain amount of USD. To fulfill this request, your smart contract (for simplicity's sake we'll call it the "caller contract" from here onwards) must know how much one Ether is worth. -And here's the thing: a JavaScript application can easily fetch this kind of information, making requests to the Binance public API (or any other service that publicly provides a price feed). But, a smart contract can't directly access data from the outside world. Instead, it relies on an **_oracle_** to pull the data. +And here's the thing: a JavaScript application can easily fetch this kind of information, making requests to the Binance public API (or any other service that publicly provides a price feed). But, a smart contract can't directly access data from the outside world. Instead, it relies on an ***oracle*** to pull the data. Phew! At first glance, this sounds like a complicated thing to do 🤯. But, by taking it one step at a time, we'll set you on a smooth sail. diff --git a/en/14/02.md b/en/14/02.md index 1618551ea5..f9ba8e9290 100644 --- a/en/14/02.md +++ b/en/14/02.md @@ -34,7 +34,7 @@ I reckon that the simplest approach would be to just hardcode the address of the But let’s put on our blockchain developer hat🎩and try to figure out if this is what we want to do. -The answer has to do with how the blockchains work. Meaning that, once a contract is deployed, there's no way you can update it. As the natives call it, **_contracts are immutable_**. +The answer has to do with how the blockchains work. Meaning that, once a contract is deployed, there's no way you can update it. As the natives call it, ***contracts are immutable***. If you think about it, you'll see that there are plenty of cases in which you would want to update the address of the oracle. As an example, say there's a bug and the oracle gets redeployed. What then? You'll have to redeploy everything. And update your front-end. diff --git a/en/14/03.md b/en/14/03.md index 3a24412a4d..e10d283069 100644 --- a/en/14/03.md +++ b/en/14/03.md @@ -40,7 +40,7 @@ Awesome! Now that you've saved the address of the oracle into a variable, let's ## Calling the Oracle Contract -For the caller contract to interact with the oracle, you must first define something called an **_interface_**. +For the caller contract to interact with the oracle, you must first define something called an ***interface***. Interfaces are somehow similar to contracts, but they only declare functions. In other words, an interface can't: * define state variables, diff --git a/en/14/05.md b/en/14/05.md index 71dac1d982..78adc859d8 100644 --- a/en/14/05.md +++ b/en/14/05.md @@ -59,7 +59,7 @@ Next, let's look into how the ETH price gets updated. To initiate an ETH price update, the smart contract should call the `getLatestEthPrice` function of the oracle. Now, due to its asynchronous nature, there's no way the `getLatestEthPrice` function can return this bit of information. What it does return instead, is a unique `id` for every request. Then, the oracle goes ahead and fetches the ETH price from the Binance API and executes a `callback` function exposed by the caller contract. Lastly, the `callback` function updates the ETH price in the caller contract. -This is a **_really important point_**, so spend a few minutes thinking about it before moving forward. +This is a ***really important point***, so spend a few minutes thinking about it before moving forward. Now, does implementing this sound like a hard problem? Actually, the way this works is so easy it'll surprise you. Just bear with me for the next two chapters🤓. diff --git a/en/14/06.md b/en/14/06.md index ed2280590f..a50a61d7b7 100644 --- a/en/14/06.md +++ b/en/14/06.md @@ -69,7 +69,7 @@ material: } --- -The caller contract logic is **_almost complete_**, but there's one more thing you should take care of. +The caller contract logic is ***almost complete***, but there's one more thing you should take care of. As mentioned in the previous chapter, calling the Binance public API is an asynchronous operation. Thus, the caller smart contract must provide a `callback` function which the oracle should call at a later time, namely when the ETH price is fetched. diff --git a/en/15/01.md b/en/15/01.md index 635ecf34b0..037cab5800 100644 --- a/en/15/01.md +++ b/en/15/01.md @@ -172,7 +172,7 @@ Things to note: Aren’t you happy to be using higher-level languages such as JavaScript and Solidity that abstract away all this complexity? I certainly am🤓! * We've initialized an empty array called `pendingRequests`. You'll use this later to keep track of the incoming requests. -**_☞ Spend a couple of minutes to give the code a read-through before moving on!_** +***☞ Spend a couple of minutes to give the code a read-through before moving on!*** ## Instantiate the Oracle Contract diff --git a/en/15/09.md b/en/15/09.md index 3085c8522d..5dea4b4b72 100644 --- a/en/15/09.md +++ b/en/15/09.md @@ -292,7 +292,7 @@ material: Remember we've mentioned that data needs a bit of massaging before it's sent to the oracle contract. Let's look into why. -The Ethereum Virtual Machine doesn't support floating-point numbers, meaning that **_divisions truncate the decimals_**. The workaround is to simply multiply the numbers in your front-end by `10**n`. The Binance API returns eight decimals numbers and we'll also multiply this by `10**10`. Why did we choose `10**10`? There's a reason: one ether is 10**18 wei. This way, we'll be sure that no money will be lost. +The Ethereum Virtual Machine doesn't support floating-point numbers, meaning that ***divisions truncate the decimals***. The workaround is to simply multiply the numbers in your front-end by `10**n`. The Binance API returns eight decimals numbers and we'll also multiply this by `10**10`. Why did we choose `10**10`? There's a reason: one ether is 10**18 wei. This way, we'll be sure that no money will be lost. But there's more to it. The `Number` type in JavaScript is "double-precision 64-bit binary format IEEE 754 value" which supports only 16 decimals... diff --git a/en/15/lessoncomplete.md b/en/15/lessoncomplete.md index de5450cc68..e0cc5f889d 100644 --- a/en/15/lessoncomplete.md +++ b/en/15/lessoncomplete.md @@ -9,6 +9,6 @@ Awesome, you've completed Lesson 2 of our series about building and interacting Because we're just building an oracle for demo purposes, we've made a bunch of decisions that simplified things a bit. For example, think about what would happen when you bring the oracle down for an upgrade. Yeah, even if it'll take just a few minutes until you bring it back online, all the requests made during this period will be lost. And there's no way to notify the app that a particular request hasn't been processed. A solution for this is to keep track of the last block that got processed, and, every time the oracle starts, it should take it from there. -A production-ready oracle should take care of this, and a few other things, of which, the most important is: how to make the oracle more **_decentralized_**. And this is exactly what we'll cover next. +A production-ready oracle should take care of this, and a few other things, of which, the most important is: how to make the oracle more ***decentralized***. And this is exactly what we'll cover next. Stay tuned for our next lesson! diff --git a/en/16/01.md b/en/16/01.md index 23530ce6ef..2298e16073 100644 --- a/en/16/01.md +++ b/en/16/01.md @@ -65,7 +65,7 @@ material: } --- -In the previous lessons, you've used OpenZeppelin's `Ownable` contract to implement a simple access control mechanism based on the concept of **_ownership_**. Simply put, only the owner was allowed to call the `setLatestEthPrice` function. +In the previous lessons, you've used OpenZeppelin's `Ownable` contract to implement a simple access control mechanism based on the concept of ***ownership***. Simply put, only the owner was allowed to call the `setLatestEthPrice` function. Now, to make the oracle more decentralized, we need to implement a system that provides different levels of access: `owner` and `oracle`. The owner should be able to add and remove oracles. In turn, an oracle must be allowed to update the ETH price by calling the `setLatestEthPrice` function. diff --git a/en/16/02.md b/en/16/02.md index aaeaf1bf09..abb3acc4e3 100644 --- a/en/16/02.md +++ b/en/16/02.md @@ -70,7 +70,7 @@ material: } --- -Now that your contract doesn't inherit from `Ownable`, you must find a way to specify its owner. You'll do this by adding a `constructor`. This is a special function that's **_executed only once_**, when a contract gets deployed. +Now that your contract doesn't inherit from `Ownable`, you must find a way to specify its owner. You'll do this by adding a `constructor`. This is a special function that's ***executed only once***, when a contract gets deployed. Here's an example of using a constructor: diff --git a/en/16/06.md b/en/16/06.md index e4d7311d85..2d9d1f1948 100644 --- a/en/16/06.md +++ b/en/16/06.md @@ -156,7 +156,7 @@ To accomplish this, you're going to use a `mapping` that'll associate each reque myStructInstance = MyStruct(msg.sender, 200); // initialize it ``` - ☞ Did you notice the `memory` keyword? **_Starting with Solidity 5.0, it is mandatory to specify the data location for every reference type!_** + ☞ Did you notice the `memory` keyword? ***Starting with Solidity 5.0, it is mandatory to specify the data location for every reference type!*** Of course, you can change the value of an object's member using an assignment statement, the same way you'd assign a value to any other plain variable. Just keep in mind that, in Solidity, we refer to structs and their members are using the dot notation: diff --git a/en/17/00-overview.md b/en/17/00-overview.md index 7de0bbb2c8..e1ed18437d 100644 --- a/en/17/00-overview.md +++ b/en/17/00-overview.md @@ -19,8 +19,8 @@ zkSync is built on the ZK rollup architecture, a level-two scaling solution in w This is the short answer to why we think zkSync is important: -* The protocol allows ETH and ERC20 token transfers with **_instant confirmations_** and 10 min finality on Ethereum. -* Provides Mainnet-level security with **_zero reliance on 3rd parties_**. +* The protocol allows ETH and ERC20 token transfers with ***instant confirmations*** and 10 min finality on Ethereum. +* Provides Mainnet-level security with ***zero reliance on 3rd parties***. * Low transaction fees * Fast deposits and withdrawals diff --git a/en/17/01.md b/en/17/01.md index c5e2a2861c..bf138ae419 100644 --- a/en/17/01.md +++ b/en/17/01.md @@ -78,4 +78,4 @@ npm install 1. The first thing you would want to do is to initialize your new project and accept all the defaults. If you can't remember the syntax for doing this, check the example from above. But first, try to do it without peeking. 2. Now, let's use the `npm install` command to install **ethers** and **zksync**. - > Note: It shouldn't matter the order in which you specify the packages you want to install but, since our command-line interpreter is pretty basic, it won't consider the answer correct unless you're specifying **_ethers first_**. + > Note: It shouldn't matter the order in which you specify the packages you want to install but, since our command-line interpreter is pretty basic, it won't consider the answer correct unless you're specifying ***ethers first***. diff --git a/en/17/03.md b/en/17/03.md index b481734100..4669ea5a85 100644 --- a/en/17/03.md +++ b/en/17/03.md @@ -70,7 +70,7 @@ Yeah, and so does the code. Thus, we went ahead and created a function called `g ## Accounts -The Ethereum blockchain is made up of **_accounts_**, which you can think of like bank accounts. An account has a balance of **_Ether_** (the currency used on the Ethereum blockchain), and you can send and receive Ether payments to other accounts, just like your bank account can wire transfer money to other bank accounts. +The Ethereum blockchain is made up of ***accounts***, which you can think of like bank accounts. An account has a balance of ***Ether*** (the currency used on the Ethereum blockchain), and you can send and receive Ether payments to other accounts, just like your bank account can wire transfer money to other bank accounts. Each account has an `address`, which you can think of like a bank account number. It's a unique identifier that points to that account, and it looks like this: diff --git a/en/17/05.md b/en/17/05.md index 712e4099e8..499f2bfb47 100644 --- a/en/17/05.md +++ b/en/17/05.md @@ -114,7 +114,7 @@ In this chapter, you're going to learn about the two types of operations a user Note the following about zkSync transactions: - * When you submit a transaction to zkSync, it's **_instantly confirmed_** by the protocol. That's nice, but you should know that an instant confirmation is just a **_promise_** the operators make that they'll add the transaction to the next block. If you trust the operators then you don't need to wait for the transaction to be finalized. + * When you submit a transaction to zkSync, it's ***instantly confirmed*** by the protocol. That's nice, but you should know that an instant confirmation is just a ***promise*** the operators make that they'll add the transaction to the next block. If you trust the operators then you don't need to wait for the transaction to be finalized. * A zkSync transaction is **final** after the SNARK proof is accepted by the Ethereum smart contract. This takes around 10 minutes. @@ -136,19 +136,19 @@ The parameters of this function are self-explanatory, so we won't spend time exp But what happens **after** you call this function? -**_First_**, the transaction gets **mined** on the Ethereum network. At this stage, the transaction is not yet reflected on zkSync. However, if you don't want your users to stare at a blank screen for too long and you trust this is secure enough, you can use the `awaitEthereumTxCommit` function to `await` for the deposit transaction to be mined: +***First***, the transaction gets **mined** on the Ethereum network. At this stage, the transaction is not yet reflected on zkSync. However, if you don't want your users to stare at a blank screen for too long and you trust this is secure enough, you can use the `awaitEthereumTxCommit` function to `await` for the deposit transaction to be mined: ```JavaScript await deposit.awaitEthereumTxCommit() ``` -**_Second_**, the transaction is **committed** to zkSync. When this happens, your **balance gets updated** accordingly. To check when that happens, you can use the `awaitReceipt` function. +***Second***, the transaction is **committed** to zkSync. When this happens, your **balance gets updated** accordingly. To check when that happens, you can use the `awaitReceipt` function. ```JavaScript await deposit.awaitReceipt() ``` -**_Lastly_**, once a specific number of blocks get confirmed on Ethereum, the transaction is considered **finalized** or verified. You can check this by calling the `awaitVerifyReceipt` function. +***Lastly***, once a specific number of blocks get confirmed on Ethereum, the transaction is considered **finalized** or verified. You can check this by calling the `awaitVerifyReceipt` function. ```JavaScript await deposit.awaitVerifyReceipt() diff --git a/en/17/09.md b/en/17/09.md index 5b1c6d9291..5cf6eeb036 100644 --- a/en/17/09.md +++ b/en/17/09.md @@ -215,12 +215,12 @@ Of course, they would want to see their balance on zkSync. When you transfer assets on zkSync, the operator includes your transaction in a new block and pushes this new block to the zkSync smart contract on Ethereum using a **Commit** transaction. Then, the SNARK proofs for each transaction in the block is and published on Ethereum using a **Verify** transaction. Once the **Verify** transaction is mined on Ethereum, the protocol considers the new state to be final. -Remember that you can receive some tokens and then immediately send those tokens to another user as part of a different transaction? How can that be possible if the protocol waits for the transaction to be mined on Ethereum? The answer is that there are two types of balances on zkSync (**_committed_** and **_verified_**) and you can use the assets in your **committed** balance as you wish. +Remember that you can receive some tokens and then immediately send those tokens to another user as part of a different transaction? How can that be possible if the protocol waits for the transaction to be mined on Ethereum? The answer is that there are two types of balances on zkSync (***committed*** and ***verified***) and you can use the assets in your **committed** balance as you wish. Just to make things clear: -* The **_committed_** balance includes all verified and committed transactions -* The **_verified_** balance includes only verified transactions +* The ***committed*** balance includes all verified and committed transactions +* The ***verified*** balance includes only verified transactions There are two way in which you can retrieve the balances for an account: diff --git a/en/17/15.md b/en/17/15.md index 8bf7712e97..d5561a08c7 100644 --- a/en/17/15.md +++ b/en/17/15.md @@ -227,7 +227,7 @@ Now let's say Alice wants to withdraw her tokens to Ethereum. This is a two-step 1. Retrieve the withdrawal transfer fee 2. Withdraw assets from zkSync to Ethereum -If you didn't use the "**_Show me the answer_**" button to finish the previous lesson, the steps in this lesson should be a walk in the park. +If you didn't use the "***Show me the answer***" button to finish the previous lesson, the steps in this lesson should be a walk in the park. ## Put it to the test diff --git a/en/18/01.md b/en/18/01.md index a37a484ccc..1e2ade7361 100644 --- a/en/18/01.md +++ b/en/18/01.md @@ -229,12 +229,12 @@ Before we get into the meat and potatoes, let's get yourself some Rinkeby USDT t 2. Click the **Connect to Web3** link, and then select the wallet you want to use. Note that we recommend MetaMask. 2. Select the **Write Contract** tab 3. To get to the end of this lesson, you must mint at least six USDT tokens. Scroll down to the **mint** function, and populate the following fields: - * **_to**: enter your Rinkeby address - * **_amount**: enter `6000000` (the USDT token has six decimal places) + * ***to**: enter your Rinkeby address + * ***amount**: enter `6000000` (the USDT token has six decimal places) 4. Select the **Write** button. 5. You'll see a Metamask popup. To approve the transaction, select the **Confirm** button. -Now let's get back to why we're here. The first thing you'll have to do is to configure the `src/alice.js` script to use **_USDT_** instead of **_ETH_** for deposits, transfer, and withdrawals. +Now let's get back to why we're here. The first thing you'll have to do is to configure the `src/alice.js` script to use ***USDT*** instead of ***ETH*** for deposits, transfer, and withdrawals. ## Put it to the test diff --git a/en/19/00-overview.md b/en/19/00-overview.md index 9722290d5e..ce498f2d6a 100644 --- a/en/19/00-overview.md +++ b/en/19/00-overview.md @@ -16,7 +16,7 @@ In this lesson, we are going to go over **Chainlink** and **oracles**. So all we have to do, is trust one of these devices to honestly deliver our data and we are all set right? -The quick answer is no. At least not until there is **_social trust_** or you come up with a **_decentralized version_**. You're doing all this work to build your smart contracts in a decentralized context, you'd basically ruin all the effort by pulling your data from a centralized version! This means, that even if you deliver the data by yourself, it's still centralized, because you are the centralized point! +The quick answer is no. At least not until there is ***social trust*** or you come up with a ***decentralized version***. You're doing all this work to build your smart contracts in a decentralized context, you'd basically ruin all the effort by pulling your data from a centralized version! This means, that even if you deliver the data by yourself, it's still centralized, because you are the centralized point! When your smart contracts include data or computation from oracles, they are considered hybrid smart contracts, and many of the most successful decentralized applications include data from the external world. diff --git a/en/2/10-interactingcontracts.md b/en/2/10-interactingcontracts.md index 81f963861b..e39013d102 100644 --- a/en/2/10-interactingcontracts.md +++ b/en/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ Don't worry — our game isn't actually going to hurt anyone's CryptoKitty. We' ## Interacting with other contracts -For our contract to talk to another contract on the blockchain that we don't own, first we need to define an **_interface_**. +For our contract to talk to another contract on the blockchain that we don't own, first we need to define an ***interface***. Let's look at a simple example. Say there was a contract on the blockchain that looked like this: @@ -131,7 +131,7 @@ This would be a simple contract where anyone could store their lucky number, and Now let's say we had an external contract that wanted to read the data in this contract using the `getNum` function. -First we'd have to define an **_interface_** of the `LuckyNumber` contract: +First we'd have to define an ***interface*** of the `LuckyNumber` contract: ``` contract NumberInterface { diff --git a/en/2/2-mappings.md b/en/2/2-mappings.md index 56fcf61e33..0910a96199 100644 --- a/en/2/2-mappings.md +++ b/en/2/2-mappings.md @@ -84,7 +84,7 @@ To do this, we'll need 2 new data types: `mapping` and `address`. ## Addresses -The Ethereum blockchain is made up of **_accounts_**, which you can think of like bank accounts. An account has a balance of **_Ether_** (the currency used on the Ethereum blockchain), and you can send and receive Ether payments to other accounts, just like your bank account can wire transfer money to other bank accounts. +The Ethereum blockchain is made up of ***accounts***, which you can think of like bank accounts. An account has a balance of ***Ether*** (the currency used on the Ethereum blockchain), and you can send and receive Ether payments to other accounts, just like your bank account can wire transfer money to other bank accounts. Each account has an `address`, which you can think of like a bank account number. It's a unique identifier that points to that account, and it looks like this: @@ -98,7 +98,7 @@ So we can use it as a unique ID for ownership of our zombies. When a user create ## Mappings -In Lesson 1 we looked at **_structs_** and **_arrays_**. **_Mappings_** are another way of storing organized data in Solidity. +In Lesson 1 we looked at ***structs*** and ***arrays***. ***Mappings*** are another way of storing organized data in Solidity. Defining a `mapping` looks like this: diff --git a/en/2/5-inheritance.md b/en/2/5-inheritance.md index 18a804d1dc..9b2f063145 100644 --- a/en/2/5-inheritance.md +++ b/en/2/5-inheritance.md @@ -95,7 +95,7 @@ material: Our game code is getting quite long. Rather than making one extremely long contract, sometimes it makes sense to split your code logic across multiple contracts to organize the code. -One feature of Solidity that makes this more manageable is contract **_inheritance_**: +One feature of Solidity that makes this more manageable is contract ***inheritance***: ``` contract Doge { @@ -111,7 +111,7 @@ contract BabyDoge is Doge { } ``` -`BabyDoge` **_inherits_** from `Doge`. That means if you compile and deploy `BabyDoge`, it will have access to both `catchphrase()` and `anotherCatchphrase()` (and any other public functions we may define on `Doge`). +`BabyDoge` ***inherits*** from `Doge`. That means if you compile and deploy `BabyDoge`, it will have access to both `catchphrase()` and `anotherCatchphrase()` (and any other public functions we may define on `Doge`). This can be used for logical inheritance (such as with a subclass, a `Cat` is an `Animal`). But it can also be used simply for organizing your code by grouping similar logic together into different contracts. diff --git a/en/2/7-storage.md b/en/2/7-storage.md index d23a4efa8e..58c36dde58 100644 --- a/en/2/7-storage.md +++ b/en/2/7-storage.md @@ -71,11 +71,11 @@ material: In Solidity, there are two locations you can store variables — in `storage` and in `memory`. -**_Storage_** refers to variables stored permanently on the blockchain. **_Memory_** variables are temporary, and are erased between external function calls to your contract. Think of it like your computer's hard disk vs RAM. +***Storage*** refers to variables stored permanently on the blockchain. ***Memory*** variables are temporary, and are erased between external function calls to your contract. Think of it like your computer's hard disk vs RAM. Most of the time you don't need to use these keywords because Solidity handles them by default. State variables (variables declared outside of functions) are by default `storage` and written permanently to the blockchain, while variables declared inside functions are `memory` and will disappear when the function call ends. -However, there are times when you do need to use these keywords, namely when dealing with **_structs_** and **_arrays_** within functions: +However, there are times when you do need to use these keywords, namely when dealing with ***structs*** and ***arrays*** within functions: ``` contract SandwichFactory { diff --git a/en/3/01-externaldependencies.md b/en/3/01-externaldependencies.md index d583e3e565..e2e3a7cda6 100644 --- a/en/3/01-externaldependencies.md +++ b/en/3/01-externaldependencies.md @@ -143,7 +143,7 @@ material: Up until now, Solidity has looked quite similar to other languages like JavaScript. But there are a number of ways that Ethereum DApps are actually quite different from normal applications. -To start with, after you deploy a contract to Ethereum, it’s **_immutable_**, which means that it can never be modified or updated again. +To start with, after you deploy a contract to Ethereum, it’s ***immutable***, which means that it can never be modified or updated again. The initial code you deploy to a contract is there to stay, permanently, on the blockchain. This is one reason security is such a huge concern in Solidity. If there's a flaw in your contract code, there's no way for you to patch it later. You would have to tell your users to start using a different smart contract address that has the fix. diff --git a/en/3/02-ownable.md b/en/3/02-ownable.md index a80e598271..563d25b338 100644 --- a/en/3/02-ownable.md +++ b/en/3/02-ownable.md @@ -225,7 +225,7 @@ To handle cases like this, one common practice that has emerged is to make contr ## OpenZeppelin's `Ownable` contract -Below is the `Ownable` contract taken from the **_OpenZeppelin_** Solidity library. OpenZeppelin is a library of secure and community-vetted smart contracts that you can use in your own DApps. After this lesson, we highly recommend you check out their site to further your learning! +Below is the `Ownable` contract taken from the ***OpenZeppelin*** Solidity library. OpenZeppelin is a library of secure and community-vetted smart contracts that you can use in your own DApps. After this lesson, we highly recommend you check out their site to further your learning! Give the contract below a read-through. You're going to see a few things we haven't learned yet, but don't worry, we'll talk about them afterward. @@ -307,7 +307,7 @@ contract Ownable { A few new things here we haven't seen before: -- Constructors: `constructor()` is a **_constructor_**, which is an optional special function. It will get executed only one time, when the contract is first created. +- Constructors: `constructor()` is a ***constructor***, which is an optional special function. It will get executed only one time, when the contract is first created. - Function Modifiers: `modifier onlyOwner()`. Modifiers are kind of half-functions that are used to modify other functions, usually to check some requirements prior to execution. In this case, `onlyOwner` can be used to limit access so **only** the **owner** of the contract can run this function. We'll talk more about function modifiers in the next chapter, and what that weird `_;` does. - `indexed` keyword: don't worry about this one, we don't need it yet. diff --git a/en/3/04-gas.md b/en/3/04-gas.md index 6e610b5b07..790a1b1472 100644 --- a/en/3/04-gas.md +++ b/en/3/04-gas.md @@ -223,9 +223,9 @@ Let's look at another way Solidity is quite different from other programming lan ## Gas — the fuel Ethereum DApps run on -In Solidity, your users have to pay every time they execute a function on your DApp using a currency called **_gas_**. Users buy gas with Ether (the currency on Ethereum), so your users have to spend ETH in order to execute functions on your DApp. +In Solidity, your users have to pay every time they execute a function on your DApp using a currency called ***gas***. Users buy gas with Ether (the currency on Ethereum), so your users have to spend ETH in order to execute functions on your DApp. -How much gas is required to execute a function depends on how complex that function's logic is. Each individual operation has a **_gas cost_** based roughly on how much computing resources will be required to perform that operation (e.g. writing to storage is much more expensive than adding two integers). The total **_gas cost_** of your function is the sum of the gas costs of all its individual operations. +How much gas is required to execute a function depends on how complex that function's logic is. Each individual operation has a ***gas cost*** based roughly on how much computing resources will be required to perform that operation (e.g. writing to storage is much more expensive than adding two integers). The total ***gas cost*** of your function is the sum of the gas costs of all its individual operations. Because running functions costs real money for your users, code optimization is much more important in Ethereum than in other programming languages. If your code is sloppy, your users are going to have to pay a premium to execute your functions — and this could add up to millions of dollars in unnecessary fees across thousands of users. diff --git a/en/4/battle-02.md b/en/4/battle-02.md index 4c2baeb8b8..0bc863a7d3 100644 --- a/en/4/battle-02.md +++ b/en/4/battle-02.md @@ -285,7 +285,7 @@ It would then "pack" the inputs and use `keccak` to convert them to a random has ### This method is vulnerable to attack by a dishonest node -In Ethereum, when you call a function on a contract, you broadcast it to a node or nodes on the network as a **_transaction_**. The nodes on the network then collect a bunch of transactions, try to be the first to solve a computationally-intensive mathematical problem as a "Proof of Work", and then publish that group of transactions along with their Proof of Work (PoW) as a **_block_** to the rest of the network. +In Ethereum, when you call a function on a contract, you broadcast it to a node or nodes on the network as a ***transaction***. The nodes on the network then collect a bunch of transactions, try to be the first to solve a computationally-intensive mathematical problem as a "Proof of Work", and then publish that group of transactions along with their Proof of Work (PoW) as a ***block*** to the rest of the network. Once a node has solved the PoW, the other nodes stop trying to solve the PoW, verify that the other node's list of transactions are valid, and then accept the block and move on to trying to solve the next block. @@ -297,7 +297,7 @@ If I were running a node, I could publish a transaction **only to my own node** ## So how do we generate random numbers safely in Ethereum? -Because the entire contents of the blockchain are visible to all participants, this is a hard problem, and its solution is beyond the scope of this tutorial. You can read this StackOverflow thread for some ideas. One idea would be to use an **_oracle_** to access a random number function from outside of the Ethereum blockchain. +Because the entire contents of the blockchain are visible to all participants, this is a hard problem, and its solution is beyond the scope of this tutorial. You can read this StackOverflow thread for some ideas. One idea would be to use an ***oracle*** to access a random number function from outside of the Ethereum blockchain. Of course, since tens of thousands of Ethereum nodes on the network are competing to solve the next block, my odds of solving the next block are extremely low. It would take me a lot of time or computing resources to exploit this profitably — but if the reward were high enough (like if I could bet $100,000,000 on the coin flip function), it would be worth it for me to attack. @@ -305,7 +305,7 @@ So while this random number generation is NOT secure on Ethereum, in practice un Because we're just building a simple game for demo purposes in this tutorial and there's no real money on the line, we're going to accept the tradeoffs of using a random number generator that is simple to implement, knowing that it isn't totally secure. -In a future lesson, we may cover using **_oracles_** (a secure way to pull data in from outside of Ethereum) to generate secure random numbers from outside the blockchain. +In a future lesson, we may cover using ***oracles*** (a secure way to pull data in from outside of Ethereum) to generate secure random numbers from outside the blockchain. ## Put it to the test diff --git a/en/4/battle-08.md b/en/4/battle-08.md index 4e2fc54ecb..b73b05966a 100644 --- a/en/4/battle-08.md +++ b/en/4/battle-08.md @@ -292,7 +292,7 @@ In chapter 6 we calculated a random number from 0 to 100. Now let's use that num ## Put it to the test -1. Create an `if` statement that checks if `rand` is **_less than or equal to_** `attackVictoryProbability`. +1. Create an `if` statement that checks if `rand` is ***less than or equal to*** `attackVictoryProbability`. 2. If this condition is true, our zombie wins! So: diff --git a/en/4/payable.md b/en/4/payable.md index 4680cc1356..7b05502b0a 100644 --- a/en/4/payable.md +++ b/en/4/payable.md @@ -265,7 +265,7 @@ material: } --- -Up until now, we've covered quite a few **_function modifiers_**. It can be difficult to try to remember everything, so let's run through a quick review: +Up until now, we've covered quite a few ***function modifiers***. It can be difficult to try to remember everything, so let's run through a quick review: 1. We have visibility modifiers that control when and where the function can be called from: `private` means it's only callable from other functions inside the contract; `internal` is like `private` but can also be called by contracts that inherit from this one; `external` can only be called outside the contract; and finally `public` can be called anywhere, both internally and externally. @@ -287,7 +287,7 @@ In this chapter, we're going to introduce one more function modifier: `payable`. Let that sink in for a minute. When you call an API function on a normal web server, you can't send US dollars along with your function call — nor can you send Bitcoin. -But in Ethereum, because the money (_Ether_), the data (*transaction payload*), and the contract code itself all live on Ethereum, it's possible for you to call a function **_and_** pay money to the contract at the same time. +But in Ethereum, because the money (_Ether_), the data (*transaction payload*), and the contract code itself all live on Ethereum, it's possible for you to call a function ***and*** pay money to the contract at the same time. This allows for some really interesting logic, like requiring a certain payment to the contract in order to execute a function. diff --git a/en/5/01-erc721-1.md b/en/5/01-erc721-1.md index 2f0230dbb4..851c3894e0 100644 --- a/en/5/01-erc721-1.md +++ b/en/5/01-erc721-1.md @@ -284,11 +284,11 @@ material: } --- -Let's talk about **_tokens_**. +Let's talk about ***tokens***. -If you've been in the Ethereum space for any amount of time, you've probably heard people talking about tokens — specifically **_ERC20 tokens_**. +If you've been in the Ethereum space for any amount of time, you've probably heard people talking about tokens — specifically ***ERC20 tokens***. -A **_token_** on Ethereum is basically just a smart contract that follows some common rules — namely it implements a standard set of functions that all other token contracts share, such as `transferFrom(address _from, address _to, uint256 _amount)` and `balanceOf(address _owner)`. +A ***token*** on Ethereum is basically just a smart contract that follows some common rules — namely it implements a standard set of functions that all other token contracts share, such as `transferFrom(address _from, address _to, uint256 _amount)` and `balanceOf(address _owner)`. Internally the smart contract usually has a mapping, `mapping(address => uint256) balances`, that keeps track of how much balance each address has. @@ -312,9 +312,9 @@ For one, zombies aren't divisible like currencies — I can send you 0.237 ETH, Secondly, all zombies are not created equal. Your Level 2 zombie "**Steve**" is totally not equal to my Level 732 zombie "**H4XF13LD MORRIS 💯💯😎💯💯**". (Not even close, *Steve*). -There's another token standard that's a much better fit for crypto-collectibles like CryptoZombies — and they're called **_ERC721 tokens._** +There's another token standard that's a much better fit for crypto-collectibles like CryptoZombies — and they're called ***ERC721 tokens.*** -**_ERC721 tokens_** are **not** interchangeable since each one is assumed to be unique, and are not divisible. You can only trade them in whole units, and each one has a unique ID. So these are a perfect fit for making our zombies tradeable. +***ERC721 tokens*** are **not** interchangeable since each one is assumed to be unique, and are not divisible. You can only trade them in whole units, and each one has a unique ID. So these are a perfect fit for making our zombies tradeable. > Note that using a standard like ERC721 has the benefit that we don't have to implement the auction or escrow logic within our contract that determines how players can trade / sell our zombies. If we conform to the spec, someone else could build an exchange platform for crypto-tradable ERC721 assets, and our ERC721 zombies would be usable on that platform. So there are clear benefits to using a token standard instead of rolling your own trading logic. diff --git a/en/5/09-safemath-1.md b/en/5/09-safemath-1.md index dc39455822..b832c1f99b 100644 --- a/en/5/09-safemath-1.md +++ b/en/5/09-safemath-1.md @@ -429,7 +429,7 @@ But we wanted to keep this lesson manageable, so we went with the most basic imp We're going to look at one major security feature you should be aware of when writing smart contracts: Preventing overflows and underflows. -What's an **_overflow_**? +What's an ***overflow***? Let's say we have a `uint8`, which can only have 8 bits. That means the largest number we can store is binary `11111111` (or in decimal, 2^8 - 1 = 255). @@ -448,11 +448,11 @@ While we're not using `uint8` here, and it seems unlikely that a `uint256` will ### Using SafeMath -To prevent this, OpenZeppelin has created a **_library_** called SafeMath that prevents these issues by default. +To prevent this, OpenZeppelin has created a ***library*** called SafeMath that prevents these issues by default. But before we get into that... What's a library? -A **_library_** is a special type of contract in Solidity. One of the things it is useful for is to attach functions to native data types. +A ***library*** is a special type of contract in Solidity. One of the things it is useful for is to attach functions to native data types. For example, with the SafeMath library, we'll use the syntax `using SafeMath for uint256`. The SafeMath library has 4 functions — `add`, `sub`, `mul`, and `div`. And now we can access these functions from `uint256` as follows: diff --git a/en/5/13-comments.md b/en/5/13-comments.md index 3a939a2052..3d54edb500 100644 --- a/en/5/13-comments.md +++ b/en/5/13-comments.md @@ -523,7 +523,7 @@ contract CryptoZombies { In particular, it's good practice to comment your code to explain the expected behavior of every function in your contract. This way another developer (or you, after a 6 month hiatus from a project!) can quickly skim and understand at a high level what your code does without having to read the code itself. -The standard in the Solidity community is to use a format called **_natspec_**, which looks like this: +The standard in the Solidity community is to use a format called ***natspec***, which looks like this: ``` /// @title A contract for basic math operations diff --git a/en/5/14-wrappingitup.md b/en/5/14-wrappingitup.md index 9040e18f83..041f8977b6 100644 --- a/en/5/14-wrappingitup.md +++ b/en/5/14-wrappingitup.md @@ -33,6 +33,6 @@ In this lesson we learned about: This lesson concludes our game's Solidity code! (For now — we may add even more lessons in the future). -In the next 2 lessons, we're going to look at how to deploy your contracts and interact with them using **_web3.js_** (so you can build a front-end for your DApp). +In the next 2 lessons, we're going to look at how to deploy your contracts and interact with them using ***web3.js*** (so you can build a front-end for your DApp). Go ahead and rename any of your zombies if you like, then proceed to the next chapter to complete the lesson. diff --git a/en/6/01.md b/en/6/01.md index 21f275c7c7..90797f59b0 100644 --- a/en/6/01.md +++ b/en/6/01.md @@ -469,7 +469,7 @@ material: By completing Lesson 5, our zombie DApp is now complete. Now we're going to create a basic web page where your users can interact with it. -To do this, we're going to use a JavaScript library from the Ethereum Foundation called **_Web3.js_**. +To do this, we're going to use a JavaScript library from the Ethereum Foundation called ***Web3.js***. ## What is Web3.js? @@ -479,7 +479,7 @@ Remember, the Ethereum network is made up of nodes, with each containing a copy 2. The function you want to call, and 3. The variables you want to pass to that function. -Ethereum nodes only speak a language called **_JSON-RPC_**, which isn't very human-readable. A query to tell the node you want to call a function on a contract looks something like this: +Ethereum nodes only speak a language called ***JSON-RPC***, which isn't very human-readable. A query to tell the node you want to call a function on a contract looks something like this: ``` // Yeah... Good luck writing all your function calls this way! diff --git a/en/6/02.md b/en/6/02.md index 8b06ea2fd9..787ae8c500 100644 --- a/en/6/02.md +++ b/en/6/02.md @@ -489,11 +489,11 @@ material: Great! Now that we have Web3.js in our project, let's get it initialized and talking to the blockchain. -The first thing we need is a **_Web3 Provider_**. +The first thing we need is a ***Web3 Provider***. -Remember, Ethereum is made up of **_nodes_** that all share a copy of the same data. Setting a Web3 Provider in Web3.js tells our code **which node** we should be talking to handle our reads and writes. It's kind of like setting the URL of the remote web server for your API calls in a traditional web app. +Remember, Ethereum is made up of ***nodes*** that all share a copy of the same data. Setting a Web3 Provider in Web3.js tells our code **which node** we should be talking to handle our reads and writes. It's kind of like setting the URL of the remote web server for your API calls in a traditional web app. -You could host your own Ethereum node as a provider. However, there's a third-party service that makes your life easier so you don't need to maintain your own Ethereum node in order to provide a DApp for your users — **_Infura_**. +You could host your own Ethereum node as a provider. However, there's a third-party service that makes your life easier so you don't need to maintain your own Ethereum node in order to provide a DApp for your users — ***Infura***. ## Infura @@ -511,7 +511,7 @@ However, since our DApp is going to be used by many users — and these users a Cryptography is complicated, so unless you're a security expert and you really know what you're doing, it's probably not a good idea to try to manage users' private keys yourself in our app's front-end. -But luckily you don't need to — there are already services that handle this for you. The most popular of these is **_Metamask_**. +But luckily you don't need to — there are already services that handle this for you. The most popular of these is ***Metamask***. ## Metamask diff --git a/en/6/03.md b/en/6/03.md index 6a1ff497f0..59308272d0 100644 --- a/en/6/03.md +++ b/en/6/03.md @@ -955,7 +955,7 @@ material: Now that we've initialized Web3.js with MetaMask's Web3 provider, let's set it up to talk to our smart contract. -Web3.js will need 2 things to talk to your contract: its **_address_** and its **_ABI_**. +Web3.js will need 2 things to talk to your contract: its ***address*** and its ***ABI***. ## Contract Address @@ -967,7 +967,7 @@ You'll need to copy this address after deploying in order to talk to your smart ## Contract ABI -The other thing Web3.js will need to talk to your contract is its **_ABI_**. +The other thing Web3.js will need to talk to your contract is its ***ABI***. ABI stands for Application Binary Interface. Basically it's a representation of your contracts' methods in JSON format that tells Web3.js how to format function calls in a way your contract will understand. diff --git a/en/7/02.md b/en/7/02.md index 055ee948a5..0a010aa65a 100644 --- a/en/7/02.md +++ b/en/7/02.md @@ -483,7 +483,7 @@ We've abstracted these into a library, so you won't need to put the same boilerp ### "Hooks" — the heart of every custom game mode -The first step for every custom game mode is to implement at least one **_hook_**. +The first step for every custom game mode is to implement at least one ***hook***. Basically, the core game logic will look for and call certain functions from your contract at certain parts of the game, if they exist in your code. diff --git a/en/8/04.md b/en/8/04.md index 6f0412d72b..36ad2ce814 100644 --- a/en/8/04.md +++ b/en/8/04.md @@ -576,7 +576,7 @@ Making these custom game modes is super simple, right? Now let's move on to the next one: -_**Singleton:** When assembling your deck of 30 cards to play, no card may share a name with another card in the deck._ +***Singleton:** When assembling your deck of 30 cards to play, no card may share a name with another card in the deck._ To start with, we've forked (made a copy of) `munchkin.sol` and called it `singleton.sol`. diff --git a/en/9/01-erc721x.md b/en/9/01-erc721x.md index 4528081c42..83ad466320 100644 --- a/en/9/01-erc721x.md +++ b/en/9/01-erc721x.md @@ -246,7 +246,7 @@ For our first chapter, let's start with some background to make sure we're all o Referring to in-game items as "tokens" can be a bit misleading, since the word "token" implies something that would be spent like a currency. -But the word **_token_** on Ethereum simply refers to a standard for smart contracts that all implement the same common functions, such as `transfer(address _to, uint256 _value)` and `balanceOf(address _owner)`. +But the word ***token*** on Ethereum simply refers to a standard for smart contracts that all implement the same common functions, such as `transfer(address _to, uint256 _value)` and `balanceOf(address _owner)`. Yes, you can transfer and have a balance of a currency — but you can also transfer and have an inventory of items in a game, like swords or playing cards. @@ -256,15 +256,15 @@ Thus the concept of a "token" is useful for abstracting out these common methods ## Different Token Standards: ERC20 and ERC721 -The most commonly known token standard is the **_ERC20 token_**. These tokens act like currencies. But they're not particularly useful for representing digital items, such as cards in a card trading game. +The most commonly known token standard is the ***ERC20 token***. These tokens act like currencies. But they're not particularly useful for representing digital items, such as cards in a card trading game. First of all, cards aren't divisible like currencies — you can't own 2/5ths of a playing card. Second, not all cards are created equal, so they're not interchangeable. You wouldn't want to exchange your **Z-Virus** card for my **Ozmoziz**. -There's another token standard that's a much better fit for crypto-collectibles — and they're called **_ERC721 tokens._** +There's another token standard that's a much better fit for crypto-collectibles — and they're called ***ERC721 tokens.*** -**_ERC721 tokens_** are **not** interchangeable. Each item is assumed to be unique, and has a unique ID. They're also not divisible — you can only trade them in whole units. +***ERC721 tokens*** are **not** interchangeable. Each item is assumed to be unique, and has a unique ID. They're also not divisible — you can only trade them in whole units. So these are a better fit for making our card trading game. diff --git a/en/9/03-erc721x.md b/en/9/03-erc721x.md index bcd5968503..c564c04b23 100644 --- a/en/9/03-erc721x.md +++ b/en/9/03-erc721x.md @@ -265,7 +265,7 @@ material: } --- -With a normal ERC20 or ERC721 token, we have the concept of **_token supply_** — this is how many of that token exist in total. +With a normal ERC20 or ERC721 token, we have the concept of ***token supply*** — this is how many of that token exist in total. With ERC721x Multi-Fungible tokens, we can actually have multiple tokens defined in the same contract — and each one will have its own "supply" (number of tokens that exist). diff --git a/en/9/10-erc721x.md b/en/9/10-erc721x.md index d448e1be45..9df841ba09 100644 --- a/en/9/10-erc721x.md +++ b/en/9/10-erc721x.md @@ -357,7 +357,7 @@ material: We are almost done! Let's wrap up our contract with one more function, then do some review. -The last thing we're going to implement is **_batch minting_** tokens. This function will allow us to mint many tokens in a single function call — and is one of the reasons ERC721x allows us to save so much on gas fees on Ethereum. +The last thing we're going to implement is ***batch minting*** tokens. This function will allow us to mint many tokens in a single function call — and is one of the reasons ERC721x allows us to save so much on gas fees on Ethereum. With everything we've set up until now, the function is quite simple to implement. diff --git a/es/1/arrays.md b/es/1/arrays.md index 6e4f01740e..a1c7914d8e 100644 --- a/es/1/arrays.md +++ b/es/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -Cuando quieres tener una colección de algo, puedes usar un **_array_**. Hay dos tipos de arrays en Solidity: arrays **_fijos_** y arrays **_dinámicos_**: +Cuando quieres tener una colección de algo, puedes usar un ***array***. Hay dos tipos de arrays en Solidity: arrays ***fijos*** y arrays ***dinámicos***: ``` // Un Array con una longitud fija de 2 elementos: @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -También puedes crear arrays de **_estructuras_**. Si usásemos la estructura `Person` del capítulo anterior: +También puedes crear arrays de ***estructuras***. Si usásemos la estructura `Person` del capítulo anterior: ``` Person[] people; // Array dinámico, podemos seguir añadiéndole elementos @@ -60,7 +60,7 @@ Person[] people; // Array dinámico, podemos seguir añadiéndole elementos ## Arrays Públicos -Puedes declarar un array como `público`, y Solidity creará automaticamente una función **_getter_** para acceder a él. La sintaxis es así: +Puedes declarar un array como `público`, y Solidity creará automaticamente una función ***getter*** para acceder a él. La sintaxis es así: ``` Person[] public people; @@ -72,4 +72,4 @@ Otros contratos entonces podrán leer (pero no escribir) de este array. Es un pa Vamos a guardar un ejército de zombis en nuestra aplicación. Y vamos a querer mostrar todos nuestros zombis a otras applicaciones, así que lo queremos público: -1. Crea un array público de **_estructuras_** `Zombie` y llámalo `zombies`. +1. Crea un array público de ***estructuras*** `Zombie` y llámalo `zombies`. diff --git a/es/1/datatypes.md b/es/1/datatypes.md index 5bcbdeca85..c7de1c7863 100644 --- a/es/1/datatypes.md +++ b/es/1/datatypes.md @@ -25,7 +25,7 @@ material: ¡Buen trabajo! Ahora que tenemos una capa para nuestro contrato, aprendamos cómo maneja las variables Solidity. -Las **_Variables de estado_** se guardan permanentemente en el almacenamiento del contrato. Esto significa que se escriben en la cadena de bloques de Ethereum. Piensa en ellos como en escribir en una base de datos. +Las ***Variables de estado*** se guardan permanentemente en el almacenamiento del contrato. Esto significa que se escriben en la cadena de bloques de Ethereum. Piensa en ellos como en escribir en una base de datos. ##### Ejemplo: ``` diff --git a/es/1/events.md b/es/1/events.md index 04ae0854e3..7da3f0b6a5 100644 --- a/es/1/events.md +++ b/es/1/events.md @@ -73,9 +73,9 @@ material: } --- -¡Nuestro contrato está casi terminado! Añadamos ahora un **_evento_**. +¡Nuestro contrato está casi terminado! Añadamos ahora un ***evento***. -Los **_eventos_** son la forma en la que nuestro contrato comunica que algo sucedió en la cadena de bloques a la interfaz de usuario, el cual puede estar 'escuchando' ciertos eventos y hacer algo cuando sucedan. +Los ***eventos*** son la forma en la que nuestro contrato comunica que algo sucedió en la cadena de bloques a la interfaz de usuario, el cual puede estar 'escuchando' ciertos eventos y hacer algo cuando sucedan. Ejemplo: diff --git a/es/1/functions3.md b/es/1/functions3.md index d2e1bd6bde..0579094cf4 100644 --- a/es/1/functions3.md +++ b/es/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -En este capítulo aprenderemos sobre los **_valores de retorno_** de una función, y sobre modificadores de funciones. +En este capítulo aprenderemos sobre los ***valores de retorno*** de una función, y sobre modificadores de funciones. ## Valores de Retorno @@ -73,13 +73,13 @@ En Solidity, la declaración de la función contiene al final tipo de dato del v La función de arriba no cambia el estado en Solidity, esto es que no cambia ningún valor o escribe nada. -En este caso podríamos declararla como función **_view_**, que significa que solo puede ver los datos pero no modificarlos: +En este caso podríamos declararla como función ***view***, que significa que solo puede ver los datos pero no modificarlos: ``` function sayHello() public view returns (string) { ``` -Solidity también contiene funciones **_pure_**, que significa que ni siquiera accedes a los datos de la aplicación. Por ejemplo: +Solidity también contiene funciones ***pure***, que significa que ni siquiera accedes a los datos de la aplicación. Por ejemplo: ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -Esta función no lee desde el estado de la aplicación - el valor devuelto depende por completo de los parámetros que le pasemos. En este caso deberíamos declarar la función como **_pure_**. +Esta función no lee desde el estado de la aplicación - el valor devuelto depende por completo de los parámetros que le pasemos. En este caso deberíamos declarar la función como ***pure***. > Nota: No siempre es fácil recordar marcar una función como pure o view, por suerte el compilador de Solidity es muy bueno avisándonos de cuándo debemos usar estos modificadores de función. diff --git a/es/1/lessoncomplete.md b/es/1/lessoncomplete.md index 7302024b9e..24726d8725 100644 --- a/es/1/lessoncomplete.md +++ b/es/1/lessoncomplete.md @@ -14,8 +14,8 @@ Esto es solamente el comienzo. Iremos publicando nuevas lecciones de CryptoZombi ### 1. Regístrate para guardar tu progreso -**_Regístrate_** para guardar el progreso haciendo clic en el enlace "Guardar Progreso" arriba de la página. ¡Te avisaremos cuando tengamos nuevas lecciones! +***Regístrate*** para guardar el progreso haciendo clic en el enlace "Guardar Progreso" arriba de la página. ¡Te avisaremos cuando tengamos nuevas lecciones! ### 2. Comparte tu zombi con tus amigos -**_Comparte_** tu zombi en Twitter, bla bla, etc. (Necesita insertar imágenes / links) +***Comparte*** tu zombi en Twitter, bla bla, etc. (Necesita insertar imágenes / links) diff --git a/es/1/math.md b/es/1/math.md index 12f92b98d6..ba1fa0acdf 100644 --- a/es/1/math.md +++ b/es/1/math.md @@ -34,7 +34,7 @@ Las matemáticas de Solidity son bastante básicas. Las siguientes operaciones s * División: `x / y` * Módulo: `x % y` _(por ejemplo, `13 % 5` es `3`, ya que al dividir 13 entre 5, 3 es el resto)_ -Solidity también tiene un **_operador exponencial_** (por ejemplo "x elevado a y", x^y): +Solidity también tiene un ***operador exponencial*** (por ejemplo "x elevado a y", x^y): ``` uint x = 5 ** 2; // es igual a 5^2 = 25 diff --git a/es/1/structs.md b/es/1/structs.md index b3dc0a8e81..29c1c42e52 100644 --- a/es/1/structs.md +++ b/es/1/structs.md @@ -32,7 +32,7 @@ material: } --- -Algunas veces necesitas tipos de datos más complejos. Para esto Solidity proporciona **_structs_** (estructuras de datos): +Algunas veces necesitas tipos de datos más complejos. Para esto Solidity proporciona ***structs*** (estructuras de datos): ``` struct Person { diff --git a/es/1/web3js.md b/es/1/web3js.md index 6d35224182..f18ec52781 100644 --- a/es/1/web3js.md +++ b/es/1/web3js.md @@ -12,7 +12,7 @@ material: ¡Nuestro contrato en Solidity está completo! Ahora tenemos que escribir una aplicación de usuario en JavaScript para interactuar con él. -Ethereum tiene una librería JavaScript llamada **_Web3.js_**. +Ethereum tiene una librería JavaScript llamada ***Web3.js***. En lecciones posteriores veremos en detalle como publicar un contrato y como configurar Web3.js. Pero por ahora vamos solamente a ver un ejemplo de código de cómo Web3.js interactuaría con nuestro contrato. diff --git a/es/2/10-interactingcontracts.md b/es/2/10-interactingcontracts.md index 1a5e734080..7748b34e96 100644 --- a/es/2/10-interactingcontracts.md +++ b/es/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ No te preocupes - nuestro juego aún no va a hacer dañor a ningún CryptoKitty. ## Interactuando con otros contratos -Para que nuestro contrato pueda hablar a otro contrato de la blockchain que no poseemos, necesitamos definir una **_interfaz_**. +Para que nuestro contrato pueda hablar a otro contrato de la blockchain que no poseemos, necesitamos definir una ***interfaz***. Vamos a ver un simple ejemplo. Digamos que hay un contrato en la blockchain tal que así: @@ -131,7 +131,7 @@ Este seria un simple contrato donde cualquiera puede guardar su número de la su Ahora digamos que tenemos un contrato externo que quiere leer la información de este contrato usando la función `getNum`. -Primero debemos usar una **_interfaz_** del contrato `LuckyNumber`: +Primero debemos usar una ***interfaz*** del contrato `LuckyNumber`: ``` contract NumberInterface { diff --git a/es/2/2-mappings.md b/es/2/2-mappings.md index e98f015aac..325f1e6237 100644 --- a/es/2/2-mappings.md +++ b/es/2/2-mappings.md @@ -84,7 +84,7 @@ Para esto, vamos a necesitar dos nuevos tipos de datos: `mapping` y `address`. ## Direcciones -La blockchain de Ethereum está creada por **_cuentas_**, que podrían ser como cuentas bancarias. Una cuenta tiene un balance de **_Ether_** (la divisa utilizada en la blockchain de Ethereum), y puedes recibir pagos en Ether de otras cuentas, de la misma manera que tu cuenta bancaria puede hacer transferencias a otras cuentas bancarias. +La blockchain de Ethereum está creada por ***cuentas***, que podrían ser como cuentas bancarias. Una cuenta tiene un balance de ***Ether*** (la divisa utilizada en la blockchain de Ethereum), y puedes recibir pagos en Ether de otras cuentas, de la misma manera que tu cuenta bancaria puede hacer transferencias a otras cuentas bancarias. Cada cuenta tiene una dirección (`address`), que sería como el número de la cuenta bancaria. Es un identificador único que apuntado a una cuenta, y se asemejaría a algo así: @@ -98,7 +98,7 @@ Así que podemos utilizarlo como identificador único para nuestros zombis. Cuan ## Mapeando -En la Lección 1 vimos los **_structs_** y los **_arrays_**. Los **_mapeos_** son otra forma de organizar los datos en Solidity. +En la Lección 1 vimos los ***structs*** y los ***arrays***. Los ***mapeos*** son otra forma de organizar los datos en Solidity. Definir un `mapping` se asemejaría a esto: diff --git a/es/2/5-inheritance.md b/es/2/5-inheritance.md index 6ed3b32521..6b586db3b6 100644 --- a/es/2/5-inheritance.md +++ b/es/2/5-inheritance.md @@ -95,7 +95,7 @@ material: Nuestro código está haciéndose un poco largo. Mejor que hacer un contrato extremandamente largo, a veces tiene sentido separar la lógica de nuestro código en múltiples contratos para organizar el código. -Una característica de Solidity que hace más manejable esto es la **_herencia_** de los contratos: +Una característica de Solidity que hace más manejable esto es la ***herencia*** de los contratos: ``` contract Doge { @@ -111,7 +111,7 @@ contract BabyDoge is Doge { } ``` -`BabyDoge` **_hereda_** de `Doge`. Eso significa que si compilas y ejecutas `BabyDoge`, este tendrá acceso tanto a `catchphrase()` como a `anotherCatchphrase()` (y a cualquier otra función publica que definamos en `Doge`). +`BabyDoge` ***hereda*** de `Doge`. Eso significa que si compilas y ejecutas `BabyDoge`, este tendrá acceso tanto a `catchphrase()` como a `anotherCatchphrase()` (y a cualquier otra función publica que definamos en `Doge`). Esto puede usarse como una herencia lógica (como una subclase, un `Gato` es un `Animal`). Pero también puede usarse simplemente para organizar tu código agrupando lógica similar en diferentes clases. diff --git a/es/2/7-storage.md b/es/2/7-storage.md index ca9e78985d..03e76c72be 100644 --- a/es/2/7-storage.md +++ b/es/2/7-storage.md @@ -71,11 +71,11 @@ material: En Solidity, hay dos sitios donde puedes guardar variables - en `storage` y en `memory`. -**_Storage_** se refiere a las variables guardadas permanentemente en la blockchain. Las variables de tipo **_memory_** son temporales, y son borradas en lo que una función externa llama a tu contrato. Piensa que es como el disco duro vs la RAM de tu ordenador. +***Storage*** se refiere a las variables guardadas permanentemente en la blockchain. Las variables de tipo ***memory*** son temporales, y son borradas en lo que una función externa llama a tu contrato. Piensa que es como el disco duro vs la RAM de tu ordenador. La mayoría del tiempo no necesitas usar estas palabras clave ya que Solidity las controla por defecto. Las variables de estado (variables declaradas fuera de las funciones) son por defecto del tipo `storage` y son guardadas permanentemente en la blockchain, mientras que las variables declaradas dentro de las funciones son por defecto del tipo `memory` y desaparecerán una vez la llamada a la función haya terminado. -Aun así, hay momentos en los que necesitas usar estas palabras clave, concretamente cuando estes trabajando con **_structs_** y **_arrays_** dentro de las funciones: +Aun así, hay momentos en los que necesitas usar estas palabras clave, concretamente cuando estes trabajando con ***structs*** y ***arrays*** dentro de las funciones: ``` contract SandwichFactory { diff --git a/es/3/01-externaldependencies.md b/es/3/01-externaldependencies.md index bbb5e1cd4f..28d6cd9666 100644 --- a/es/3/01-externaldependencies.md +++ b/es/3/01-externaldependencies.md @@ -143,7 +143,7 @@ material: Hasta ahora, Solidity se ha parecido bastante a otros lenguajes como JavaScript. Pero hay unas cuantas maneras en las que las DApps de Ethereum son diferentes a las aplicaciones normales. -Para empezar, despues de implementar un contrato en Ethereum, es **_inmutable_**, lo que significa que nunca va a ser modificado o actualizado de nuevo. +Para empezar, despues de implementar un contrato en Ethereum, es ***inmutable***, lo que significa que nunca va a ser modificado o actualizado de nuevo. El código inicial que implementes en el contrato es el que va a permanecer, permanentemente, en la blockchain. Esto es debido a que una de las mayores preocupaciones de Solidity es la seguridad. Si hay un error en el código del contrato, no hay forma de solucionarlo más adelante. Tendrás que decirles a tus usuarios que empiecen a usar otra dirección de contrato inteligente que incluya ese arreglo. diff --git a/es/3/02-ownable.md b/es/3/02-ownable.md index 3b1fa7f06b..1e5dc03d7f 100644 --- a/es/3/02-ownable.md +++ b/es/3/02-ownable.md @@ -221,7 +221,7 @@ Para manejar casos como este, una práctica emergente común es hacer el contrat ## Contrato `Ownable` de OpenZeppelin -Abajo está el contrato `Ownable` definido en la librería Solidity de **_OpenZeppelin_**. OpenZeppelin es una librería segura donde hay contratos inteligentes para utilizar en tus propias DApps revisados por la comunidad. Despues de esta lección, ¡te recomendamos encarecidamente que visites su sitio web para fomentar tu aprendizaje! +Abajo está el contrato `Ownable` definido en la librería Solidity de ***OpenZeppelin***. OpenZeppelin es una librería segura donde hay contratos inteligentes para utilizar en tus propias DApps revisados por la comunidad. Despues de esta lección, ¡te recomendamos encarecidamente que visites su sitio web para fomentar tu aprendizaje! Échale un vistazo al contrato más abajo. Vas a ver algunas cosas que no hemos aprendido aún, pero no te preocupes, hablaremos de ellas más adelante. @@ -303,7 +303,7 @@ contract Ownable { Alguna de las cosas que no hemos visto todavía: -- Constructores: `function Ownable()` es un **_constructor_**, que es una función especial opcional que tiene el mismo nombre que el contrato. Será ejecutada una única vez, cuando el contrato sea creado por primera vez. +- Constructores: `function Ownable()` es un ***constructor***, que es una función especial opcional que tiene el mismo nombre que el contrato. Será ejecutada una única vez, cuando el contrato sea creado por primera vez. - Modificadores de Funciones: `modifier onlyOwner()`. Los modificadores son como semifunciones que son usadas para modificar otras funciones, normalmente para comprobar algunos requisitos antes de la ejecución. En este caso, `onlyOwner` puede ser usada para limitar el acceso y que **solo** el **dueño** del contrato pueda ejecutar función. Hablaremos sobre los modificadores en el siguiente capítulo, y que hace ese extraño `_;`. - Palabra clave `indexed`: no te preocupes por esto, no lo necesitamos todavía. diff --git a/es/3/04-gas.md b/es/3/04-gas.md index 19e37e555f..9d6158aaa0 100644 --- a/es/3/04-gas.md +++ b/es/3/04-gas.md @@ -223,9 +223,9 @@ Vamos a ver otra característica por la que Solidity es diferente a otros lengua ## Gas — el combustible que mueven las DApps de Ethereum -En Solidity, tus usuarios tienen que pagar cada vez que ejecuten una función en tu DApp usando una divisa llamada **_gas_**. Los usuarios compran gas con Ether (la divisa de Ethereum), así que deben gastar ETH para poder ejecutar funciones en tu DApp. +En Solidity, tus usuarios tienen que pagar cada vez que ejecuten una función en tu DApp usando una divisa llamada ***gas***. Los usuarios compran gas con Ether (la divisa de Ethereum), así que deben gastar ETH para poder ejecutar funciones en tu DApp. -La cantidad de gas necesaria para ejecutar una función depende en cuán compleja sea la lógica de la misma. Cada operación individual tiene un **_coste de gas_** basado aproximadamente en cuantos recursos computacionales se necesitarán para llevarla a cabo (p. ej. escribir en memoria es más caro que añadir dos integers). El total **_coste de gas_** de tu función es la suma del coste de cada una de sus operaciones. +La cantidad de gas necesaria para ejecutar una función depende en cuán compleja sea la lógica de la misma. Cada operación individual tiene un ***coste de gas*** basado aproximadamente en cuantos recursos computacionales se necesitarán para llevarla a cabo (p. ej. escribir en memoria es más caro que añadir dos integers). El total ***coste de gas*** de tu función es la suma del coste de cada una de sus operaciones. Como ejecutar funciones cuestan dinero real a los usuarios, la optimización de código es mucho más importante en Ethereum que en cualquier otro lenguaje. Si tu código es descuidado, tus usuarios van a tener que pagar un premium para ejecutar tus funciones - esto puede suponer millones de dolares gastados innecesariamente por miles de usuarios en tasas. diff --git a/es/4/battle-02.md b/es/4/battle-02.md index e671384a6d..8c31ad648f 100644 --- a/es/4/battle-02.md +++ b/es/4/battle-02.md @@ -284,7 +284,7 @@ Luego entonces utilizaría `keccak` para convertir estas entradas a un hash alea ### Este método es vulnerable a ataques de nodos deshonestos -En Ethereum, cuando llama a una función en un contrato, lo transmite a un nodo o nodos en la red como una **_transacción_**. Los nodos en la red luego recolectan un montón de transacciones, intentan ser el primero en resolver el problema de matemática intensamente informático como una "Prueba de Trabajo", para luego publicar ese grupo de transacciones junto con sus Pruebas de Trabajo (PoW) como un **_bloque_** para el resto de la red. +En Ethereum, cuando llama a una función en un contrato, lo transmite a un nodo o nodos en la red como una ***transacción***. Los nodos en la red luego recolectan un montón de transacciones, intentan ser el primero en resolver el problema de matemática intensamente informático como una "Prueba de Trabajo", para luego publicar ese grupo de transacciones junto con sus Pruebas de Trabajo (PoW) como un ***bloque*** para el resto de la red. Una vez que un nodo ha resuelto la PoW, los otros nodos dejan de intentar resolver la PoW, verifican que las transacciones en la lista de transacciones del otro nodo son válidas, luego aceptan el bloque y pasan a tratar de resolver el próximo bloque. @@ -296,7 +296,7 @@ Si yo estuviera ejecutando un nodo, podría publicar una transacción **a mi pro ## Entonces ¿Cómo generamos números aleatorio de manera segura en Ethereum? -Ya que todos los contenidos de la blockchain son visibles para todos los participantes, este es un problema dificil, y su solución está más allá del rango de este tutorial. Puede leer este hilo de StackOverflow para que se haga un idea. Una idea sería utilizar un **_oráculo_** para ingresar una función de número aleatorio desde fuera de la blockchain de Ethereum. +Ya que todos los contenidos de la blockchain son visibles para todos los participantes, este es un problema dificil, y su solución está más allá del rango de este tutorial. Puede leer este hilo de StackOverflow para que se haga un idea. Una idea sería utilizar un ***oráculo*** para ingresar una función de número aleatorio desde fuera de la blockchain de Ethereum. Por supuesto, debido a que cientos de miles de nodos de Ethereum en la red están compitiendo por resolver el próximo bloque, mis probabilidades de resolver el siguiente bloque son extremadamente escasas. Me tomaría mucho tiempo o recursos informáticos para explotar esto y que sea beneficioso — pero si la recompensa fuera lo suficientemente alta (como si pudiera apostar $100,000,000 en la función coin flip), para mi valdría la pena atacar. @@ -304,7 +304,7 @@ Así que mientras esta generación de número aleatorio NO sea segura en Ethereu Ya que sólo estamos construyendo un juego simple para propósitos de demo en este tutorial y no hay dinero real en riesgo, vamos a asumir el riesgo de utilizar un generador de números aleatorios que es simple de implementar, sabiendo que no es totalmente seguro. -En una lección futura, puede que cubramos el uso de los **_oráculos_** (una manera segura de incorporar datos desde afuera de Ethereum) para generar números aleatorios seguros desde afuera de la blockchain. +En una lección futura, puede que cubramos el uso de los ***oráculos*** (una manera segura de incorporar datos desde afuera de Ethereum) para generar números aleatorios seguros desde afuera de la blockchain. ## Pongalo a prueba diff --git a/es/4/battle-08.md b/es/4/battle-08.md index 3b6fafcc3a..e25d4ece08 100644 --- a/es/4/battle-08.md +++ b/es/4/battle-08.md @@ -286,7 +286,7 @@ En el capítulo 6 calculamos un número aleatorio entre 0 y 100. Ahora utilicemo ## Vamos a probarlo -1. Cree una declaración `if` que verifique si `rand` es **_menor o igual a_** `attackVictoryProbability`. +1. Cree una declaración `if` que verifique si `rand` es ***menor o igual a*** `attackVictoryProbability`. 2. Si esta condición resulta verdadera ¡Nuestro zombie gana! Entonces: diff --git a/es/4/payable.md b/es/4/payable.md index 1d6f13ffd0..046c10b16b 100644 --- a/es/4/payable.md +++ b/es/4/payable.md @@ -265,7 +265,7 @@ material: } --- -Hasta ahora, hemos cubierto unos cuantos **_modificadores de función_**. Puede resultar difícil tratar de recordar todo, así que hagamos un breve repaso: +Hasta ahora, hemos cubierto unos cuantos ***modificadores de función***. Puede resultar difícil tratar de recordar todo, así que hagamos un breve repaso: 1. Tenemos modificadores de visibilidad que controlan desde dónde y cuándo la función puede ser llamada: `private` significa que sólo puede ser llamada desde otras funciones dentro del contrato; `internal` es como `private` pero también puede ser llamada por contratos que hereden desde este; `external` sólo puede ser llamada desde afuera del contrato; y finalmente `public` puede ser llamada desde cualquier lugar, tanto internamente como externamente. diff --git a/es/5/01-erc721-1.md b/es/5/01-erc721-1.md index 6e5b8a2047..0eb9b5f3d3 100644 --- a/es/5/01-erc721-1.md +++ b/es/5/01-erc721-1.md @@ -282,9 +282,9 @@ material: Hablemos de **tokens**. -Si has estado en el ecosistema de Ethereum durante un tiempo, es probable que hayas oído hablar de los tokens — en concreto, de los **_tokens ERC20_**. +Si has estado en el ecosistema de Ethereum durante un tiempo, es probable que hayas oído hablar de los tokens — en concreto, de los ***tokens ERC20***. -Un **_token_** es básicamente un contrato inteligente que sigue algunas reglas comunes, es decir, implementa un conjunto estándar de funciones que comparten el resto de tokens (contratos), como por ejemplo `transfer(address _to, uint256 _value)` y `balanceOf(address _owner)`. +Un ***token*** es básicamente un contrato inteligente que sigue algunas reglas comunes, es decir, implementa un conjunto estándar de funciones que comparten el resto de tokens (contratos), como por ejemplo `transfer(address _to, uint256 _value)` y `balanceOf(address _owner)`. Internamente, el contrato inteligente tiene por lo general un mapeo, `mapping(address => uint256) balances`, que realiza un seguimiento de cuánto saldo tiene cada dirección. @@ -308,9 +308,9 @@ Por un lado, los zombies no son divisibles como las monedas - puedo enviarte 0.2 En segundo lugar, todos los zombies no son creados iguales. Tu zombi de nivel 2 "**Steve**" no es igual a mi zombie de nivel 732 "**H4XF13LD MORRIS 💯💯😎💯💯**". (Ni estás cerca de serlo, *Steve*). -Hay otro estándar de token que encaja mucho mejor con los cripto-coleccionables como CryptoZombies, y se llaman **_tokens ERC721._** +Hay otro estándar de token que encaja mucho mejor con los cripto-coleccionables como CryptoZombies, y se llaman ***tokens ERC721.*** -Los **_tokens ERC721_ ** **no son intercambiables entre sí**, ya que se supone que cada uno de ellos es totalmente único e indivisible. Solo se pueden intercambiar en unidades completas, y cada uno tiene una ID única. Así que estos, son perfectos para hacer que nuestros zombies sean comerciables. +Los ***tokens ERC721_ ** **no son intercambiables entre sí**, ya que se supone que cada uno de ellos es totalmente único e indivisible. Solo se pueden intercambiar en unidades completas, y cada uno tiene una ID única. Así que estos, son perfectos para hacer que nuestros zombies sean comerciables. > Nota: Tenga en cuenta que el uso de un estándar como ERC721 tiene el beneficio de que no tenemos que implementar la lógica que está detrás del sistema que permite las operaciones de compra/venta en nuestro contrato, y que determina cómo los jugadores pueden comprar / vender nuestros zombies. Si cumplimos con la especificación, alguien más podría construir otra plataforma de intercambio para los activos ERC721, y nuestros zombies ERC721 se podrían usar en esa plataforma. Por lo tanto, existen beneficios claros en el uso de un token estándar en lugar de desarrollar su propia lógica comercial. diff --git a/es/5/13-comments.md b/es/5/13-comments.md index 2de8762024..f7dc8aee07 100644 --- a/es/5/13-comments.md +++ b/es/5/13-comments.md @@ -521,7 +521,7 @@ contract CryptoZombies { En particular, es una buena práctica comentar su código para explicar el comportamiento esperado de cada función en su contrato. De esta forma, otro desarrollador (¡O tú, después de un paréntesis de 6 meses en un proyecto!) puede leer rápidamente y comprender a un nivel alto lo que hace su código sin tener que leer el código en sí. -El estándar en la comunidad Solidity es usar un formato llamado **_natspec_**, que tiene esta apariencia: +El estándar en la comunidad Solidity es usar un formato llamado ***natspec***, que tiene esta apariencia: ``` /// @title Un contrato para operaciones matemáticas básicas diff --git a/es/6/01.md b/es/6/01.md index 5e4983dd56..fe936d8b8d 100644 --- a/es/6/01.md +++ b/es/6/01.md @@ -420,7 +420,7 @@ material: Al terminar la lección 5, nestra DApp ya está completa. Ahora, nos falta por crear una página web básica donde los usuarios podrán interactuar con ella. -Para hacer esto, tendremos que usar una librería de JavaScript de la fundación de Ethereum llamada **_Web3.js_**. +Para hacer esto, tendremos que usar una librería de JavaScript de la fundación de Ethereum llamada ***Web3.js***. ## ¿Qué es Web3.js? @@ -430,7 +430,7 @@ Recuerda, que la red de Ethereum está formada por nodos, cada uno de los cuales 2. La función que quieres llamar, y 3. Las variables que quieres pasar a dicha función. -Los nodos de Ethereum solamente hablan un idioma llamado **_JSON-RPC_**, cuyo lenguaje es bastante difícil de leer para un humano. Una consulta para decirle al nodo que quieres llamar una función en un Contrato Inteligente es algo así: +Los nodos de Ethereum solamente hablan un idioma llamado ***JSON-RPC***, cuyo lenguaje es bastante difícil de leer para un humano. Una consulta para decirle al nodo que quieres llamar una función en un Contrato Inteligente es algo así: ``` // ¡Y es que escribiendo nuestro contrato así tardaríamos una eternidad! diff --git a/es/6/02.md b/es/6/02.md index ed10eb2ad3..17847d383a 100644 --- a/es/6/02.md +++ b/es/6/02.md @@ -437,11 +437,11 @@ material: ¡Estupendo! Ahora que ya tenemos Web3.js en nuestro proyecto, vamos a inicializarlo y hablar de la blockchain. -Lo primero que necesitamos, es un **_Web3 Provider_**. +Lo primero que necesitamos, es un ***Web3 Provider***. -Recuerda, que Ethereum está compuesto por **_nodos_** que a la vez todos estos comparten una copia de los mismos datos. Al configurar un proveedor Web3 en Web3.js le decimos **qué nodo** deberíamos de estar hablando para manejar nuestras lecturas y escrituras. Es como configurar la URL de un servidor remoto para tus llamadas API en una aplicación web tradicional. +Recuerda, que Ethereum está compuesto por ***nodos*** que a la vez todos estos comparten una copia de los mismos datos. Al configurar un proveedor Web3 en Web3.js le decimos **qué nodo** deberíamos de estar hablando para manejar nuestras lecturas y escrituras. Es como configurar la URL de un servidor remoto para tus llamadas API en una aplicación web tradicional. -Podrías "hostear" tu propio nodo Ethereum como proveedor. Sin embargo, hay un servicio de terceros que te hace la vida más fácil así que no necesitas mantener tu propio nodo Ethereum para ofrecer tu DApp a tus usuarios — **_Infura_**. +Podrías "hostear" tu propio nodo Ethereum como proveedor. Sin embargo, hay un servicio de terceros que te hace la vida más fácil así que no necesitas mantener tu propio nodo Ethereum para ofrecer tu DApp a tus usuarios — ***Infura***. ## Infura @@ -453,7 +453,7 @@ var web3 = new Web3(new Web3.providers.WebsocketProvider("wss://mainnet.infura.i Sin embargo, dado que muchas personas serán usuarios de nuestra DApp — y estos usuarios no solo van a leer la blockchain sino también escribir en ella — vamos a necesitar una forma para que estos usuarios puedan firmar diversas transacciones con su llave privada. > Nota: Ethereum (y las Blockchains en general) usan una llave pública/privada para firmar de forma digital las transacciones. De esta manera si cambio algunos datos de la Blockchain, puedo **demostrar** a través de mi llave pública que fui yo quien lo firmó — pero como nadie sabe mi llave privada, nadie puede falsificar una transacción en mi nombre. La criptografía es complicada, así que a menos que seas un experto en seguridad y realmente sepas lo que estás haciendo, probablemente no sea una buena idea tratar de administrar manualmente las claves privadas de los usuarios en el front-end de nuestra aplicación. -Pero afortunadamente no necesitamos hacerlo — hoy en día ya hay servicios que manejan estas llaves por nosotros. El más popular de estos es **_Metamask_**. +Pero afortunadamente no necesitamos hacerlo — hoy en día ya hay servicios que manejan estas llaves por nosotros. El más popular de estos es ***Metamask***. ## Metamask diff --git a/es/6/03.md b/es/6/03.md index 43d688d1dd..0c8e4a2b04 100644 --- a/es/6/03.md +++ b/es/6/03.md @@ -912,7 +912,7 @@ material: Ahora que ya hemos inicializado Web3.js con el proveedor Web3 de MetaMask, vamos a configurarlo para hablar con nuestro contrato inteligente. -Web3.js va a necesitar dos cosas para poder hablar con nuestro contrato inteligente: su **_address_** (dirección) y su **_ABI_**). +Web3.js va a necesitar dos cosas para poder hablar con nuestro contrato inteligente: su ***address*** (dirección) y su ***ABI***). ## Dirección del contrato @@ -924,7 +924,7 @@ Deberás copiar esta dirección después de la implementación para poder hablar ## Contrato ABI -La otra cosa que Web3.js necesitará para hablar con tu contrato es su **_ABI_**. +La otra cosa que Web3.js necesitará para hablar con tu contrato es su ***ABI***. Básicamente es una representación de los métodos de sus contratos en formato JSON que le dice a Web3.js cómo formatear las llamadas de función de una manera que su contrato lo entienda. Cuando compilas tu contrato para implementarlo en Ethereum (que cubriremos en la Lección 7), el compilador de Solidity te dará el ABI, por lo que deberás copiarlo y guardarlo además de la dirección del contrato. diff --git a/fa/1/arrays.md b/fa/1/arrays.md index 3fd9329934..db50aae6cc 100644 --- a/fa/1/arrays.md +++ b/fa/1/arrays.md @@ -68,7 +68,7 @@ Person[] people; // dynamic Array, we can keep adding to it ## آرایه‌های عمومی -شما می‌تونین یک آرایه را به صورت `عمومی` تعریف کنین، و سالیدیتی به‌صورت خودکار یک متد **_getter_** برایش ایجاد می‌کنه. سینتکس آن به صورت زیر خواهد بود: +شما می‌تونین یک آرایه را به صورت `عمومی` تعریف کنین، و سالیدیتی به‌صورت خودکار یک متد ***getter*** برایش ایجاد می‌کنه. سینتکس آن به صورت زیر خواهد بود: ``` @@ -84,6 +84,6 @@ Person[] public people; می‌خواهیم یک ارتش زامبی در اپلیکیشن‌مان داشته باشیم. و می‌خواهیم زامبی‌هامون را به رخ اپلیکیشن‌های دیگر بکشیم، بنابراین می‌خواهیم به صورت عمومی ذخیره بشن. -۱. یک آرایه عمومی `Zombie` به صورت **_ساختار_** ایجاد کنین، و اسمش رو `zombies` بگذارین. +۱. یک آرایه عمومی `Zombie` به صورت ***ساختار*** ایجاد کنین، و اسمش رو `zombies` بگذارین. diff --git a/fa/1/datatypes.md b/fa/1/datatypes.md index 58c99a4c46..8fcc33af36 100644 --- a/fa/1/datatypes.md +++ b/fa/1/datatypes.md @@ -26,7 +26,7 @@ material: کارتون عالی بود! حالا که با ساختار کلی قرارداد آشنا شدیم بریم ببینیم متغیرها در سالیدیتی چطور تعریف می‌شن. -**_متغیرهای حالت(State variables)_** به صورت دائم در حافظه قرارداد ذخیره می‌شن. یعنی روی بلاکچین اتریوم نوشته می‌شن. مثل نوشتن تو دیتابیس. +***متغیرهای حالت(State variables)*** به صورت دائم در حافظه قرارداد ذخیره می‌شن. یعنی روی بلاکچین اتریوم نوشته می‌شن. مثل نوشتن تو دیتابیس. ##### مثال: diff --git a/fa/1/events.md b/fa/1/events.md index 235a5509b4..a8253a505a 100644 --- a/fa/1/events.md +++ b/fa/1/events.md @@ -74,7 +74,7 @@ material: ---
-قراردادمون تقریبا تمومه! حالا بیایین یه **_event(رویداد)_** بهش اضافه کنیم. +قراردادمون تقریبا تمومه! حالا بیایین یه ***event(رویداد)*** بهش اضافه کنیم. رویدادها راهی برای براقراری ارتباط بین قرارداد و فرانت اند اپلیکیشن شماست. diff --git a/fa/1/functions3.md b/fa/1/functions3.md index 7d0d62e785..53e3d038d4 100644 --- a/fa/1/functions3.md +++ b/fa/1/functions3.md @@ -55,7 +55,7 @@ material:
-در این فصل درباره **_مقادیر بازگشتی_** و تغییردهنده‌های (modifiers) توابع یاد می‌گیریم. +در این فصل درباره ***مقادیر بازگشتی*** و تغییردهنده‌های (modifiers) توابع یاد می‌گیریم. ## Return Values @@ -78,7 +78,7 @@ function sayHello() public returns (string) { تابع بالا حالتی را تغییر نمی‌ده، مثلا مقداری را تغییر نمی‌ده یا چیزی نمی‌نویسه. -در این حالت می‌تونیم تابع را یه عنوان **_view_** تعریف کنیم. به این معنی که فقط داده رو می‌بینه و تغییرش نمی‌ده: +در این حالت می‌تونیم تابع را یه عنوان ***view*** تعریف کنیم. به این معنی که فقط داده رو می‌بینه و تغییرش نمی‌ده:
@@ -87,7 +87,7 @@ function sayHello() public view returns (string) { ```
-توابعی دیگری هم در سالیدیتی می‌توان تعریف کرد. تابع **_pure_** حتی به داده‌های اپلیکیشن هم دسترسی نداره. به مثال زیر دقت کنید: +توابعی دیگری هم در سالیدیتی می‌توان تعریف کرد. تابع ***pure*** حتی به داده‌های اپلیکیشن هم دسترسی نداره. به مثال زیر دقت کنید:
``` @@ -97,7 +97,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { ```
-این تابع حتی حالت اپلیکیشن رو نمی‌خونه، مقداری که برمی‌گردونه فقط به پارامتر تابعش وابسته است. پس در این موارد تابع به عنوان **_pure_** تعریف می‌شه. +این تابع حتی حالت اپلیکیشن رو نمی‌خونه، مقداری که برمی‌گردونه فقط به پارامتر تابعش وابسته است. پس در این موارد تابع به عنوان ***pure*** تعریف می‌شه. > نکته: ممکنه تشخیص اینکه چه زمانی تابع رو به صورت view یا pure تعریف کنیم. خوشبختانه کامپایلر سالیدیتی هشدارهای مناسبی می‌ده تا متوجه بشیم از کدوم modifier استفاده کنیم. diff --git a/fa/1/lessoncomplete.md b/fa/1/lessoncomplete.md index eefe0cdd67..80ba7e5d95 100644 --- a/fa/1/lessoncomplete.md +++ b/fa/1/lessoncomplete.md @@ -16,10 +16,10 @@ material: ### 1. عضو شید تا میزان پیشرفت‌تون رو ذخیره کنید -**_عضو شید_** و با کلیک روی گزینه "ذخیره پیشرفت" در بالای صفحه، میزان پیشرفت‌تون رو ذخیره کنید. به محض اضافه شدن درس جدید به شما اطلاع می‌دیم. +***عضو شید*** و با کلیک روی گزینه "ذخیره پیشرفت" در بالای صفحه، میزان پیشرفت‌تون رو ذخیره کنید. به محض اضافه شدن درس جدید به شما اطلاع می‌دیم. ### 2. زامبی‌تون رو با دوستانتون به اشتراک بذارین -زامبی‌تون رو در توئیتر و دیگر شبکه‌های اجتماعی **_به اشتراک بذارین_**. +زامبی‌تون رو در توئیتر و دیگر شبکه‌های اجتماعی ***به اشتراک بذارین***.
diff --git a/fa/1/math.md b/fa/1/math.md index 918972a107..a0785e47a9 100644 --- a/fa/1/math.md +++ b/fa/1/math.md @@ -35,7 +35,7 @@ material: * تقسیم: `x / y` * پیمانه‌ای / باقی‌مانده: `x % y` _(برای مثال، `۱۳٪۵` می‌شه `۳`. چون باقی‌مانده تقسیم `۱۳` به `۵` می‌شه `۳`)_ -سالیدیتی از **_عملگر نمایی_** هم پشتیبانی می‌کند.("x به توان y"، x^y): +سالیدیتی از ***عملگر نمایی*** هم پشتیبانی می‌کند.("x به توان y"، x^y):
``` uint x = 5 ** 2; // equal to 5^2 = 25 diff --git a/fa/1/structs.md b/fa/1/structs.md index ece9f2760b..9e55b2f6b8 100644 --- a/fa/1/structs.md +++ b/fa/1/structs.md @@ -34,7 +34,7 @@ material:
-گاهی اوقات ممکنه به نوع‌داده پیچیده‌تری نیاز داشته باشین و **_structs(ساختار)_** در سالیدیتی برای اینطور مواقع است. +گاهی اوقات ممکنه به نوع‌داده پیچیده‌تری نیاز داشته باشین و ***structs(ساختار)*** در سالیدیتی برای اینطور مواقع است. ``` struct Person { diff --git a/fa/1/web3js.md b/fa/1/web3js.md index cff3abfcea..73e12be6f2 100644 --- a/fa/1/web3js.md +++ b/fa/1/web3js.md @@ -13,7 +13,7 @@ material: قرارداد سالیدیتی ما تکمیل شد! حالا باید یک فرانت جاوااسکریپتی بنویسیم که با قراردادمون در تعامل باشه. -اتریوم یک کتابخونه جاوااسکریپت به اسم **_Web3.js_** داره. +اتریوم یک کتابخونه جاوااسکریپت به اسم ***Web3.js*** داره. در دروس آینده، می‌بینیم که چطور باید یک قرارداد رو دیپلوی کنیم و از استفاده کنیم.اما فعلا بیایین یه نگاهی بندازیم به چند تا نمونه کد برای اینکه ببینیم Web3.js چطور با قرارداد دیپلوی شده ارتباط برقرا می‌کنه. diff --git a/fa/10/00-overview.md b/fa/10/00-overview.md index 85e9142288..e0e59afd5d 100644 --- a/fa/10/00-overview.md +++ b/fa/10/00-overview.md @@ -11,16 +11,16 @@ Remember that we promised to teach you how to deploy a smart contract? It's been a while, but the time has come! -In this lesson, we will be teaching you how to deploy to **_Ethereum_** using **_Truffle_**. +In this lesson, we will be teaching you how to deploy to ***Ethereum*** using ***Truffle***. -And this is not all. You are going to learn how to deploy your smart contracts to **_Loom_** as well😎. +And this is not all. You are going to learn how to deploy your smart contracts to ***Loom*** as well😎. -Why deploy to **_Loom_**? After all, **_Ethereum_** is the most secure network. +Why deploy to ***Loom***? After all, ***Ethereum*** is the most secure network. Yes, we totally agree with that. But on Ethereum each transaction costs _gas_, so your users will have to pay fees for each and every transaction. Also, they will have to wait at least 10 seconds for each transaction to be confirmed. -In a nutshell, **_on Ethereum, all transactions benefit from the same security guarantees_**. For something like a user-facing DApp or a game, this level of security isn't always a requirement. In fact, it just harms the user experience. +In a nutshell, ***on Ethereum, all transactions benefit from the same security guarantees***. For something like a user-facing DApp or a game, this level of security isn't always a requirement. In fact, it just harms the user experience. -On **_Loom_**, users have access to much speedier and gas-free transactions. This makes **_Loom_** a much better fit for something like a game or a user-facing DApp. +On ***Loom***, users have access to much speedier and gas-free transactions. This makes ***Loom*** a much better fit for something like a game or a user-facing DApp. Enough talking! Let's get started😉 diff --git a/fa/10/01.md b/fa/10/01.md index 3cd14e6c18..28a1162c21 100644 --- a/fa/10/01.md +++ b/fa/10/01.md @@ -23,7 +23,7 @@ So you've worked your way through our previous lessons. Awesome! This means you' But an important piece of the puzzle is still missing. -That's right... you still have to learn how to **_deploy a smart contract_**. +That's right... you still have to learn how to ***deploy a smart contract***. Now, if you have a background in front-end development, you are probably well accustomed to the multitude of tools like *Webpack, Gulp, or Browserify* that make a developer's life simpler. @@ -31,12 +31,12 @@ But what tools do **Solidity** developers use? ## Truffle -**_Truffle_** is the most popular blockchain development framework for good reason - it's packed with lots of useful features: +***Truffle*** is the most popular blockchain development framework for good reason - it's packed with lots of useful features: - easy smart contract compilation - automated ABI generation - integrated smart contract testing - there's even support for **Mocha** and **Chai**! -- support for multiple networks - code can be deployed to Rinkeby, **_Ethereum_** or even to **_Loom_**. We'll walk you through this later😉 +- support for multiple networks - code can be deployed to Rinkeby, ***Ethereum*** or even to ***Loom***. We'll walk you through this later😉 Provided that `npm` and `node` have been installed on your computer, we'll want you to install **Truffle** and make it available globally. diff --git a/fa/10/02.md b/fa/10/02.md index 07a85a4d40..17d3d6e783 100644 --- a/fa/10/02.md +++ b/fa/10/02.md @@ -48,15 +48,15 @@ Don't worry, learning to use **Truffle** won't eat your brains. This chapter wil So, running the `truffle init` command inside of the `CryptoZombies` directory, should create several directories and some JavaScript and Solidity files. Let's have a closer look: - - **_contracts_**: this is the place where **Truffle** expects to find all our smart contracts. To keep the code organized, we can even create nested folders such as `contracts/tokens`. Pretty neat😉. + - ***contracts***: this is the place where **Truffle** expects to find all our smart contracts. To keep the code organized, we can even create nested folders such as `contracts/tokens`. Pretty neat😉. >Note: `truffle init` should automatically create a contract called `Migrations.sol` and the corresponding migration file. We'll explain them a bit later. - - **_migrations_**: a migration is a JavaScript file that tells **Truffle** how to deploy a smart contract. + - ***migrations***: a migration is a JavaScript file that tells **Truffle** how to deploy a smart contract. - - **_test_**: here we are expected to put the unit tests which will be JavaScript or Solidity files. Remember, once a contract is deployed it can't be changed, making it essential that we test our smart contracts before we deploy them. + - ***test***: here we are expected to put the unit tests which will be JavaScript or Solidity files. Remember, once a contract is deployed it can't be changed, making it essential that we test our smart contracts before we deploy them. - - **_truffle.js_** and **_truffle-config.js_**: config files used to store the network settings for deployment. **Truffle** needs two config files because on Windows having both `truffle.js` and `truffle.exe` in the same folder might generate conflicts. Long story short - if you are running Windows, it is advised to delete `truffle.js` and use `truffle-config.js` as the default config file. Check out **Truffle**'s official documentation to further your understanding. + - ***truffle.js*** and ***truffle-config.js***: config files used to store the network settings for deployment. **Truffle** needs two config files because on Windows having both `truffle.js` and `truffle.exe` in the same folder might generate conflicts. Long story short - if you are running Windows, it is advised to delete `truffle.js` and use `truffle-config.js` as the default config file. Check out **Truffle**'s official documentation to further your understanding. But why should I use this directory structure? I'm not used to it and it looks complicated... @@ -67,7 +67,7 @@ Second, by adhering to this convention your projects will be easily understood b ## truffle-hdwallet-provider -In this lesson, we will be using _Infura_ to deploy our code to **_Ethereum_**. This way, we can run the application without needing to set up our own **_Ethereum_** node or wallet. +In this lesson, we will be using _Infura_ to deploy our code to ***Ethereum***. This way, we can run the application without needing to set up our own ***Ethereum*** node or wallet. However, to keep things secure, _Infura_ does not manage the private keys, which means it can't sign transactions on our behalf. Since deploying a smart contract requires **Truffle** to sign transactions, we are going to need a tool called `truffle-hdwallet-provider`. Its only purpose is to handle the transaction signing. >Note: Maybe you are asking why we chose not to install `truffle-hdwallet-provider` in the previous chapter using something like: diff --git a/fa/10/03.md b/fa/10/03.md index 98cda54f06..9f62a6d925 100644 --- a/fa/10/03.md +++ b/fa/10/03.md @@ -27,7 +27,7 @@ Congratulations! Now that we've put the project structure in place and set up `t Why do we need to compile, you ask? -The _Ethereum Virtual Machine_ can't directly understand Solidity source code as we write it. Thus, we need to run a compiler that will "translate" our smart contract into machine-readable **_bytecode_**. The virtual machine then executes the bytecode, and completes the actions required by our smart contract. +The _Ethereum Virtual Machine_ can't directly understand Solidity source code as we write it. Thus, we need to run a compiler that will "translate" our smart contract into machine-readable ***bytecode***. The virtual machine then executes the bytecode, and completes the actions required by our smart contract. Curious about how does the bytecode look like? Let's take a look: @@ -51,7 +51,7 @@ function add(uint16 a, uint16 b) internal returns (uint16) { } ``` -If we're going to compile this function, the Solidity compiler will throw a **_warning_**: +If we're going to compile this function, the Solidity compiler will throw a ***warning***: ``` safemath.sol:110:11: Warning: Function state mutability can be restricted to pure diff --git a/fa/10/04.md b/fa/10/04.md index bc58a172e5..840d72626e 100644 --- a/fa/10/04.md +++ b/fa/10/04.md @@ -18,15 +18,15 @@ material: }; --- -Normally at this point, before deploying to **_Ethereum_**, you would want to test your smart contract locally. You can do this using a tool called Ganache, which sets up a local **_Ethereum_** network. +Normally at this point, before deploying to ***Ethereum***, you would want to test your smart contract locally. You can do this using a tool called Ganache, which sets up a local ***Ethereum*** network. However, while testing is very important, it requires an entire lesson to cover — so we’re just going to stick to deployment in this lesson. If you're so inclined, to learn more about testing, I recommend our very own Testing Smart Contracts with Truffle lesson. -To deploy to **_Ethereum_** we will have to create something called a **migration**. +To deploy to ***Ethereum*** we will have to create something called a **migration**. -Migrations are JavaScript files that help **Truffle** deploy the code to **_Ethereum_**. Note that `truffle init` created a special contract called `Migrations.sol` that keeps track of the changes you're making to your code. The way it works is that the history of changes is saved onchain. Thus, there's no way you will ever deploy the same code twice. +Migrations are JavaScript files that help **Truffle** deploy the code to ***Ethereum***. Note that `truffle init` created a special contract called `Migrations.sol` that keeps track of the changes you're making to your code. The way it works is that the history of changes is saved onchain. Thus, there's no way you will ever deploy the same code twice. ## Creating a New Migration diff --git a/fa/10/05.md b/fa/10/05.md index 713820d6b0..12ff93ae2b 100644 --- a/fa/10/05.md +++ b/fa/10/05.md @@ -74,11 +74,11 @@ Awesome! You've successfully compiled the source code and created a migration fi There is still one more thing to do before we can deploy. We'll have to edit the configuration file to tell **Truffle** the networks we want to deploy to. -Wait a minute, I thought there was only one **_Ethereum_** network. What am I missing here? +Wait a minute, I thought there was only one ***Ethereum*** network. What am I missing here? ## Ethereum Test Networks -Several public **_Ethereum_** test networks let you test your contracts for free before you deploy them to the main net (remember once you deploy a contract to the main net it can't be altered). These test networks use a different consensus algorithm to the main net (usually PoA), and Ether is free to encourage thorough testing. +Several public ***Ethereum*** test networks let you test your contracts for free before you deploy them to the main net (remember once you deploy a contract to the main net it can't be altered). These test networks use a different consensus algorithm to the main net (usually PoA), and Ether is free to encourage thorough testing. In this lesson, we will be using Rinkeby, a public test network created by The Ethereum Foundation. @@ -133,7 +133,7 @@ Config files are often pushed to GitHub, where anyone can see them, leaving you ### Set up Truffle for Rinkeby and Ethereum main net -Next, to make sure **Truffle** "knows" the networks we want to deploy to, we will have to create two separate objects- one for Rinkeby and the other one for the **_Ethereum_** main net: +Next, to make sure **Truffle** "knows" the networks we want to deploy to, we will have to create two separate objects- one for Rinkeby and the other one for the ***Ethereum*** main net: ```JavaScript networks: { diff --git a/fa/10/06.md b/fa/10/06.md index dc573142b8..51333c1e91 100644 --- a/fa/10/06.md +++ b/fa/10/06.md @@ -28,7 +28,7 @@ material: Saving artifacts... --- -Great! That was the difficult part — actually deploying to Rinkeby is going to be straightforward. To do this, **Truffle** relies on something called a **_migration_**. +Great! That was the difficult part — actually deploying to Rinkeby is going to be straightforward. To do this, **Truffle** relies on something called a ***migration***. # Migrations diff --git a/fa/10/07.md b/fa/10/07.md index 367a83c554..01241cd6af 100644 --- a/fa/10/07.md +++ b/fa/10/07.md @@ -21,21 +21,21 @@ Even if **Truffle** helped a lot, this is no small feat, so pat yourself on the ## Loom Basechain -Now, if you want to build DApps on **_Ethereum_**, there's one thing you should be aware of - on the main net, users are required to **_pay gas fees for every transaction_**. But this isn't ideal for a user-facing DApp or a game. It can easily ruin the user experience. +Now, if you want to build DApps on ***Ethereum***, there's one thing you should be aware of - on the main net, users are required to ***pay gas fees for every transaction***. But this isn't ideal for a user-facing DApp or a game. It can easily ruin the user experience. -Conversely, on **_Loom_**, your users can have much speedier and gas-free transactions, making it a much better fit for games and other non-financial applications. +Conversely, on ***Loom***, your users can have much speedier and gas-free transactions, making it a much better fit for games and other non-financial applications. -This means that your **_Loom_** zombies will be fast zombies! +This means that your ***Loom*** zombies will be fast zombies! -That's not all - deploying to **_Loom_** is no different from deploying to Rinkeby, or to the Ethereum main net. If you know how to do one, you also know how to do the other. +That's not all - deploying to ***Loom*** is no different from deploying to Rinkeby, or to the Ethereum main net. If you know how to do one, you also know how to do the other. -In the next chapters, we'll be walking you through deploying to **_Loom_**. +In the next chapters, we'll be walking you through deploying to ***Loom***. ## loom-truffle-provider -We at **_Loom_** are using **Truffle** to build, test, and deploy our smart contracts. To make our life easier, we developed something called a **_provider_** that lets Truffle deploy to **_Loom_** just like it deploys to Rinkeby or Ethereum main net. +We at ***Loom*** are using **Truffle** to build, test, and deploy our smart contracts. To make our life easier, we developed something called a ***provider*** that lets Truffle deploy to ***Loom*** just like it deploys to Rinkeby or Ethereum main net. -Without delving too much into details, the provider works like a bridge that makes Web3 calls compatible with **_Loom_**. The beauty of it is that, to use it, you don't have to understand how it works under the hood. +Without delving too much into details, the provider works like a bridge that makes Web3 calls compatible with ***Loom***. The beauty of it is that, to use it, you don't have to understand how it works under the hood. # Put it to the test: diff --git a/fa/10/08.md b/fa/10/08.md index caca2a669b..a891dd64a6 100644 --- a/fa/10/08.md +++ b/fa/10/08.md @@ -89,9 +89,9 @@ material: }; --- -In this chapter, we’re going to deploy our smart contract to the **_Loom_** Testnet, but before doing the deployment, some prep work is needed. +In this chapter, we’re going to deploy our smart contract to the ***Loom*** Testnet, but before doing the deployment, some prep work is needed. -First, we should create our own **_Loom_** private key. The easiest way to do it is by downloading and installing **_Loom_** according to this tutorial. +First, we should create our own ***Loom*** private key. The easiest way to do it is by downloading and installing ***Loom*** according to this tutorial. Next, creating a private key is as as simple as this: @@ -113,7 +113,7 @@ The first thing we are required to do is to initialize `loom-truffle-provider`. const LoomTruffleProvider = require('loom-truffle-provider'); ``` -Next, just as we did in chapter 5, we'll have to let **_Truffle_** know how to deploy on **_Loom_** testnet. To do so, let's add a new object to `truffle.js` +Next, just as we did in chapter 5, we'll have to let ***Truffle*** know how to deploy on ***Loom*** testnet. To do so, let's add a new object to `truffle.js` ```JavaScript loom_testnet: { diff --git a/fa/10/09.md b/fa/10/09.md index f65826bb38..60470578c8 100644 --- a/fa/10/09.md +++ b/fa/10/09.md @@ -61,7 +61,7 @@ material: --- - Now we have everything in place to deploy to **_Loom_** Testnet with just one command. + Now we have everything in place to deploy to ***Loom*** Testnet with just one command. # Put it to the test: diff --git a/fa/10/10.md b/fa/10/10.md index 9ba2ec686f..2eead3bf9e 100644 --- a/fa/10/10.md +++ b/fa/10/10.md @@ -63,16 +63,16 @@ material: --- -Congratulations! You've successfully deployed to **_Loom_** Testnet. But can you guess what's coming next?🤔 +Congratulations! You've successfully deployed to ***Loom*** Testnet. But can you guess what's coming next?🤔 -Yup, you're right! This chapter will walk you through the process of deploying to **_Basechain_** (that is our Mainnet). +Yup, you're right! This chapter will walk you through the process of deploying to ***Basechain*** (that is our Mainnet). Here's a brief rundown of what you'll do in this chapter: - Create a new private key. - Creating a new private key is pretty straightforward. But since we're talking about deploying to the main net, it's time to get more serious about security. Thus, we'll show you how to securely pass the private key to **Truffle**. -- Tell **Truffle** how to deploy to **_Basechain_** by adding a new object to the `truffle.js` configuration file. -- Whitelist your deployment keys so you can deploy to **_Basechain_**. +- Tell **Truffle** how to deploy to ***Basechain*** by adding a new object to the `truffle.js` configuration file. +- Whitelist your deployment keys so you can deploy to ***Basechain***. - Lastly, we wrap everything up by actually deploying the smart contract. ### Create a new private key @@ -122,7 +122,7 @@ Pretty straightforward, isn't it? ### Tell Truffle how to deploy to Basechain -Now, we must let **Truffle** know how to deploy to **_Basechain_**. To do so, let's add a new object to `truffle.js` +Now, we must let **Truffle** know how to deploy to ***Basechain***. To do so, let's add a new object to `truffle.js` ```js basechain: { @@ -197,9 +197,9 @@ module.exports = { ### Whitelist your deployment keys -Before deploying to **_Basechain_**, you need to whitelist your keys by following the instructions from our Deploy to Mainnet guide. Don't worry about it right now, but keep in mind that you have to do this after you finish this tutorial. +Before deploying to ***Basechain***, you need to whitelist your keys by following the instructions from our Deploy to Mainnet guide. Don't worry about it right now, but keep in mind that you have to do this after you finish this tutorial. -We've gone ahead and performed all these steps and now we are ready to deploy to **_Basechain_**! +We've gone ahead and performed all these steps and now we are ready to deploy to ***Basechain***! # Put it to the test: diff --git a/fa/10/lessoncomplete.md b/fa/10/lessoncomplete.md index 9cc39b2c62..18d3bfe928 100644 --- a/fa/10/lessoncomplete.md +++ b/fa/10/lessoncomplete.md @@ -9,9 +9,9 @@ Well done!👏🏻👏🏻👏🏻 You mastered the art of deploying smart contracts using **Truffle**! -Remember, building on top of **_Loom_** brings you faster, gas-free transactions that make it the perfect choice for creating blockchain games and user-facing DApps. At the same time, your users will enjoy the guaranteed security that Ethereum provides! +Remember, building on top of ***Loom*** brings you faster, gas-free transactions that make it the perfect choice for creating blockchain games and user-facing DApps. At the same time, your users will enjoy the guaranteed security that Ethereum provides! -Another thing to remember is how similar deploying to **_Loom_** is to deploying to the Ethereum mainnet. You now know how to do both, just be careful how you choose which one to use for your next project😉. +Another thing to remember is how similar deploying to ***Loom*** is to deploying to the Ethereum mainnet. You now know how to do both, just be careful how you choose which one to use for your next project😉. Anyway, this was just an example — we made several decisions that simplified things a bit to make the lesson easier to understand. diff --git a/fa/11/00-overview.md b/fa/11/00-overview.md index a1385a8a54..3021136f3a 100644 --- a/fa/11/00-overview.md +++ b/fa/11/00-overview.md @@ -13,7 +13,7 @@ So, go ahead and deploy the game to the mainnet. Enjoy your success! Hang on a moment... There are a _few things_ you might have already thought of. After all, once contracts get deployed to the mainnet, they will live there forever. If there are mistakes in them, they will still live on as well. Like undead zombies. -Mistakes, or _**bugs**_, happen to every coder, no matter how skilled. It's unlikely that you would make a major mistake like giving attacking zombies a 100% chance of victory, but it could happen. +Mistakes, or ***bugs***, happen to every coder, no matter how skilled. It's unlikely that you would make a major mistake like giving attacking zombies a 100% chance of victory, but it could happen. Clearly giving the attacking side 100% of wins would mean what you had written was no longer a game, or even any fun at all. A bug like this would kill your game dead, and no promise of juicy brains would drag your zombies from their graves. diff --git a/fa/11/02.md b/fa/11/02.md index 574f66a787..3c67842292 100644 --- a/fa/11/02.md +++ b/fa/11/02.md @@ -35,7 +35,7 @@ Say there was a contract called `myAwesomeContract`. We could do something like const myAwesomeContract = artifacts.require(“myAwesomeContract”); ``` -The function returns something called a **_contract abstraction_**. In a nutshell, a _contract abstraction_ hides the complexity of interacting with **Ethereum** and provides a convenient _JavaScript_ interface to our _Solidity_ smart contract. We'll be using it in the next chapters. +The function returns something called a ***contract abstraction***. In a nutshell, a _contract abstraction_ hides the complexity of interacting with **Ethereum** and provides a convenient _JavaScript_ interface to our _Solidity_ smart contract. We'll be using it in the next chapters. ### The contract() function diff --git a/fa/11/04.md b/fa/11/04.md index ead9c3d5d6..11c81adc66 100644 --- a/fa/11/04.md +++ b/fa/11/04.md @@ -34,11 +34,11 @@ Great job! Now that we have a shell for our first test, let me walk you through Usually, every test has the following phases: - 1. **_set up_**: in which we define the initial state and initialize the inputs. + 1. ***set up***: in which we define the initial state and initialize the inputs. - 2. **_act_**: where we actually test the code. Always make sure you _test only one thing_. + 2. ***act***: where we actually test the code. Always make sure you _test only one thing_. - 3. **_assert_:** where we check the results. + 3. ***assert_:** where we check the results. Lets look at what our test should do in some more detail. diff --git a/fa/11/06.md b/fa/11/06.md index 6377f85ed9..bb0776817a 100644 --- a/fa/11/06.md +++ b/fa/11/06.md @@ -95,7 +95,7 @@ We'll continue fleshing out this function in the next chapter! ### 🧟‍♂️Here be... zombies of every kind!!!🧟‍♂️ -If you really, really want to **_achieve mastery_**, go ahead and read on. Otherwise... just click next and off you go to the next chapter. +If you really, really want to ***achieve mastery***, go ahead and read on. Otherwise... just click next and off you go to the next chapter. You still around?😁 diff --git a/fa/11/10.md b/fa/11/10.md index 6d5d3f4c11..e44278c54a 100644 --- a/fa/11/10.md +++ b/fa/11/10.md @@ -120,7 +120,7 @@ In a nutshell, we have to test two different scenarios: - Alice approves Bob to take the ERC721 token. Next, Alice transfers the ERC721 token. -The difference in the two scenarios lies with _**who**_ calls the actual transfer, Alice or Bob. +The difference in the two scenarios lies with ***who*** calls the actual transfer, Alice or Bob. We've made it look simple, right? diff --git a/fa/11/14.md b/fa/11/14.md index f2d6faaae9..981795dbbe 100644 --- a/fa/11/14.md +++ b/fa/11/14.md @@ -107,11 +107,11 @@ material: Impressive! You must have been practicing. -Now, this tutorial would not be complete without showing you how to test against **_Loom_** Testnet. +Now, this tutorial would not be complete without showing you how to test against ***Loom*** Testnet. -Recall from our previous lessons that, on **_Loom_**, users have access to much speedier and gas-free transactions than on **Ethereum**. This makes DAppChains a much better fit for something like a game or a user-facing DApp. +Recall from our previous lessons that, on ***Loom***, users have access to much speedier and gas-free transactions than on **Ethereum**. This makes DAppChains a much better fit for something like a game or a user-facing DApp. -And you know what? Deploying and testing against **Loom** is not different at all. We've gone ahead and summed up what needs to be done so you can test against **_Loom_**. Let's have a quick look. +And you know what? Deploying and testing against **Loom** is not different at all. We've gone ahead and summed up what needs to be done so you can test against ***Loom***. Let's have a quick look. ## Configure Truffle for Testing on **Loom** diff --git a/fa/14/00-overview.md b/fa/14/00-overview.md index ef8afed2aa..534b317426 100644 --- a/fa/14/00-overview.md +++ b/fa/14/00-overview.md @@ -5,14 +5,14 @@ path: solidity_advanced publishedOn: Cryptozombies --- -By completing the previous tutorials you've demonstrated a good grasp of Solidity and JavaScript; and you are probably well on your way to building your first dapp. If so, you may already have noticed that smart contracts can't directly access data from the outside world through an HTTP request or something similar. Instead, smart contracts pull data through something called an **_oracle_**. +By completing the previous tutorials you've demonstrated a good grasp of Solidity and JavaScript; and you are probably well on your way to building your first dapp. If so, you may already have noticed that smart contracts can't directly access data from the outside world through an HTTP request or something similar. Instead, smart contracts pull data through something called an ***oracle***. -This lesson is the first in the sequence of three lessons that aim to show how you can **_build and interact with an oracle_**. +This lesson is the first in the sequence of three lessons that aim to show how you can ***build and interact with an oracle***. In the first two lessons, we will be teaching you to build and interact with the simplest possible oracle that allows only one user, its owner, to fetch data from Binance's public API. That said, I have a question for you: why would users trust your oracle?🤔🤔🤔 -The quick answer is that they wouldn't. At least not until there **_social trust_** or you come up with a **_decentralized version_**. Thus, in the third lesson, we'll show you how to make your oracle more decentralized. But, for now, let's start with the beginning. +The quick answer is that they wouldn't. At least not until there ***social trust*** or you come up with a ***decentralized version***. Thus, in the third lesson, we'll show you how to make your oracle more decentralized. But, for now, let's start with the beginning. Time to write some code! diff --git a/fa/14/01.md b/fa/14/01.md index 2f65e6d138..7694c04a79 100644 --- a/fa/14/01.md +++ b/fa/14/01.md @@ -38,7 +38,7 @@ material: run `npm audit fix` to fix them, or `npm audit` for details --- -Before we begin, let's be clear: this is an intermediate lesson, and it requires a bit of **_JavaScript_** and **_Solidity_** knowledge. +Before we begin, let's be clear: this is an intermediate lesson, and it requires a bit of ***JavaScript*** and ***Solidity*** knowledge. If you're new to Solidity, it's highly recommended that you go over the first lessons before starting this one. @@ -48,7 +48,7 @@ If you are not comfortable with **JavaScript**, consider going through a tutoria Now, let's suppose you're building a DeFi dapp, and want to give your users the ability to withdraw ETH worth a certain amount of USD. To fulfill this request, your smart contract (for simplicity's sake we'll call it the "caller contract" from here onwards) must know how much one Ether is worth. -And here's the thing: a JavaScript application can easily fetch this kind of information, making requests to the Binance public API (or any other service that publicly provides a price feed). But, a smart contract can't directly access data from the outside world. Instead, it relies on an **_oracle_** to pull the data. +And here's the thing: a JavaScript application can easily fetch this kind of information, making requests to the Binance public API (or any other service that publicly provides a price feed). But, a smart contract can't directly access data from the outside world. Instead, it relies on an ***oracle*** to pull the data. Phew! At first glance, this sounds like a complicated thing to do 🤯. But, by taking it one step at a time, we'll set you on a smooth sail. diff --git a/fa/14/02.md b/fa/14/02.md index b8f6ce446c..6f0a990453 100644 --- a/fa/14/02.md +++ b/fa/14/02.md @@ -34,7 +34,7 @@ I reckon that the simplest approach would be to just hardcode the address of the But let’s put on our blockchain developer hat🎩and try to figure out if this is what we want to do. -The answer has to do with how the blockchains work. Meaning that, once a contract is deployed, there's no way you can update it. As the natives call it, **_contracts are immutable_**. +The answer has to do with how the blockchains work. Meaning that, once a contract is deployed, there's no way you can update it. As the natives call it, ***contracts are immutable***. If you think about it, you'll see that there are plenty of cases in which you would want to update the address of the oracle. As an example, say there's a bug and the oracle gets redeployed. What then? You'll have to redeploy everything. And update your front-end. diff --git a/fa/14/03.md b/fa/14/03.md index ed1c715ab0..6f1b1b9e2e 100644 --- a/fa/14/03.md +++ b/fa/14/03.md @@ -40,7 +40,7 @@ Awesome! Now that you've saved the address of the oracle into a variable, let's ## Calling the Oracle Contract -For the caller contract to interact with the oracle, you must first define something called an **_interface_**. +For the caller contract to interact with the oracle, you must first define something called an ***interface***. Interfaces are somehow similar to contracts, but they only declare functions. In other words, an interface can't: * define state variables, diff --git a/fa/14/05.md b/fa/14/05.md index 71dac1d982..78adc859d8 100644 --- a/fa/14/05.md +++ b/fa/14/05.md @@ -59,7 +59,7 @@ Next, let's look into how the ETH price gets updated. To initiate an ETH price update, the smart contract should call the `getLatestEthPrice` function of the oracle. Now, due to its asynchronous nature, there's no way the `getLatestEthPrice` function can return this bit of information. What it does return instead, is a unique `id` for every request. Then, the oracle goes ahead and fetches the ETH price from the Binance API and executes a `callback` function exposed by the caller contract. Lastly, the `callback` function updates the ETH price in the caller contract. -This is a **_really important point_**, so spend a few minutes thinking about it before moving forward. +This is a ***really important point***, so spend a few minutes thinking about it before moving forward. Now, does implementing this sound like a hard problem? Actually, the way this works is so easy it'll surprise you. Just bear with me for the next two chapters🤓. diff --git a/fa/14/06.md b/fa/14/06.md index ed2280590f..a50a61d7b7 100644 --- a/fa/14/06.md +++ b/fa/14/06.md @@ -69,7 +69,7 @@ material: } --- -The caller contract logic is **_almost complete_**, but there's one more thing you should take care of. +The caller contract logic is ***almost complete***, but there's one more thing you should take care of. As mentioned in the previous chapter, calling the Binance public API is an asynchronous operation. Thus, the caller smart contract must provide a `callback` function which the oracle should call at a later time, namely when the ETH price is fetched. diff --git a/fa/15/01.md b/fa/15/01.md index c18fdb8957..b131389820 100644 --- a/fa/15/01.md +++ b/fa/15/01.md @@ -172,7 +172,7 @@ Things to note: Aren’t you happy to be using higher-level languages such as JavaScript and Solidity that abstract away all this complexity? I certainly am🤓! * We've initialized an empty array called `pendingRequests`. You'll use this later to keep track of the incoming requests. -**_☞ Spend a couple of minutes to give the code a read-through before moving on!_** +***☞ Spend a couple of minutes to give the code a read-through before moving on!*** ## Instantiate the Oracle Contract diff --git a/fa/15/09.md b/fa/15/09.md index fce287ac19..7232590c9d 100644 --- a/fa/15/09.md +++ b/fa/15/09.md @@ -286,7 +286,7 @@ material: Remember we've mentioned that data needs a bit of massaging before it's sent to the oracle contract. Let's look into why. -The Ethereum Virtual Machine doesn't support floating-point numbers, meaning that **_divisions truncate the decimals_**. The workaround is to simply multiply the numbers in your front-end by `10**n`. The Binance API returns eight decimals numbers and we'll also multiply this by `10**10`. Why did we choose `10**10`? There's a reason: one ether is 10**18 wei. This way, we'll be sure that no money will be lost. +The Ethereum Virtual Machine doesn't support floating-point numbers, meaning that ***divisions truncate the decimals***. The workaround is to simply multiply the numbers in your front-end by `10**n`. The Binance API returns eight decimals numbers and we'll also multiply this by `10**10`. Why did we choose `10**10`? There's a reason: one ether is 10**18 wei. This way, we'll be sure that no money will be lost. But there's more to it. The `Number` type in JavaScript is "double-precision 64-bit binary format IEEE 754 value" which supports only 16 decimals... diff --git a/fa/15/lessoncomplete.md b/fa/15/lessoncomplete.md index de5450cc68..e0cc5f889d 100644 --- a/fa/15/lessoncomplete.md +++ b/fa/15/lessoncomplete.md @@ -9,6 +9,6 @@ Awesome, you've completed Lesson 2 of our series about building and interacting Because we're just building an oracle for demo purposes, we've made a bunch of decisions that simplified things a bit. For example, think about what would happen when you bring the oracle down for an upgrade. Yeah, even if it'll take just a few minutes until you bring it back online, all the requests made during this period will be lost. And there's no way to notify the app that a particular request hasn't been processed. A solution for this is to keep track of the last block that got processed, and, every time the oracle starts, it should take it from there. -A production-ready oracle should take care of this, and a few other things, of which, the most important is: how to make the oracle more **_decentralized_**. And this is exactly what we'll cover next. +A production-ready oracle should take care of this, and a few other things, of which, the most important is: how to make the oracle more ***decentralized***. And this is exactly what we'll cover next. Stay tuned for our next lesson! diff --git a/fa/16/01.md b/fa/16/01.md index 1dede079f7..f6c55575dc 100644 --- a/fa/16/01.md +++ b/fa/16/01.md @@ -65,7 +65,7 @@ material: } --- -In the previous lessons, you've used OpenZeppelin's `Ownable` contract to implement a simple access control mechanism based on the concept of **_ownership_**. Simply put, only the owner was allowed to call the `setLatestEthPrice` function. +In the previous lessons, you've used OpenZeppelin's `Ownable` contract to implement a simple access control mechanism based on the concept of ***ownership***. Simply put, only the owner was allowed to call the `setLatestEthPrice` function. Now, to make the oracle more decentralized, we need to implement a system that provides different levels of access: `owner` and `oracle`. The owner should be able to add and remove oracles. In turn, an oracle must be allowed to update the ETH price by calling the `setLatestEthPrice` function. diff --git a/fa/16/02.md b/fa/16/02.md index 374cd01370..e6fe8fb501 100644 --- a/fa/16/02.md +++ b/fa/16/02.md @@ -70,7 +70,7 @@ material: } --- -Now that your contract doesn't inherit from `Ownable`, you must find a way to specify its owner. You'll do this by adding a `constructor`. This is a special function that's **_executed only once_**, when a contract gets deployed. +Now that your contract doesn't inherit from `Ownable`, you must find a way to specify its owner. You'll do this by adding a `constructor`. This is a special function that's ***executed only once***, when a contract gets deployed. Here's an example of using a constructor: diff --git a/fa/16/06.md b/fa/16/06.md index 801518f418..9573afcbb4 100644 --- a/fa/16/06.md +++ b/fa/16/06.md @@ -156,7 +156,7 @@ To accomplish this, you're going to use a `mapping` that'll associate each reque myStructInstance = new MyStruct(msg.sender, 200); // initialize it ``` - ☞ Did you notice the `memory` keyword? **_Starting with Solidity 5.0, it is mandatory to specify the data location for every reference type!_** + ☞ Did you notice the `memory` keyword? ***Starting with Solidity 5.0, it is mandatory to specify the data location for every reference type!*** Of course, you can change the value of an object's member using an assignment statement, the same way you'd assign a value to any other plain variable. Just keep in mind that, in Solidity, we refer to structs and their members are using the dot notation: diff --git a/fa/17/00-overview.md b/fa/17/00-overview.md index 7de0bbb2c8..e1ed18437d 100644 --- a/fa/17/00-overview.md +++ b/fa/17/00-overview.md @@ -19,8 +19,8 @@ zkSync is built on the ZK rollup architecture, a level-two scaling solution in w This is the short answer to why we think zkSync is important: -* The protocol allows ETH and ERC20 token transfers with **_instant confirmations_** and 10 min finality on Ethereum. -* Provides Mainnet-level security with **_zero reliance on 3rd parties_**. +* The protocol allows ETH and ERC20 token transfers with ***instant confirmations*** and 10 min finality on Ethereum. +* Provides Mainnet-level security with ***zero reliance on 3rd parties***. * Low transaction fees * Fast deposits and withdrawals diff --git a/fa/17/01.md b/fa/17/01.md index 70b2b33d53..b906072f38 100644 --- a/fa/17/01.md +++ b/fa/17/01.md @@ -78,4 +78,4 @@ npm install 1. The first thing you would want to do is to initialize your new project and accept all the defaults. If you can't remember the syntax for doing this, check the example from above. But first, try to do it without peeking. 2. Now, let's use the `npm install` command to install **ethers** and **zksync**. - > Note: It shouldn't matter the order in which you specify the packages you want to install but, since our command-line interpreter is pretty basic, it won't consider the answer correct unless you're specifying **_ethers first_**. + > Note: It shouldn't matter the order in which you specify the packages you want to install but, since our command-line interpreter is pretty basic, it won't consider the answer correct unless you're specifying ***ethers first***. diff --git a/fa/17/03.md b/fa/17/03.md index b481734100..4669ea5a85 100644 --- a/fa/17/03.md +++ b/fa/17/03.md @@ -70,7 +70,7 @@ Yeah, and so does the code. Thus, we went ahead and created a function called `g ## Accounts -The Ethereum blockchain is made up of **_accounts_**, which you can think of like bank accounts. An account has a balance of **_Ether_** (the currency used on the Ethereum blockchain), and you can send and receive Ether payments to other accounts, just like your bank account can wire transfer money to other bank accounts. +The Ethereum blockchain is made up of ***accounts***, which you can think of like bank accounts. An account has a balance of ***Ether*** (the currency used on the Ethereum blockchain), and you can send and receive Ether payments to other accounts, just like your bank account can wire transfer money to other bank accounts. Each account has an `address`, which you can think of like a bank account number. It's a unique identifier that points to that account, and it looks like this: diff --git a/fa/17/05.md b/fa/17/05.md index 712e4099e8..499f2bfb47 100644 --- a/fa/17/05.md +++ b/fa/17/05.md @@ -114,7 +114,7 @@ In this chapter, you're going to learn about the two types of operations a user Note the following about zkSync transactions: - * When you submit a transaction to zkSync, it's **_instantly confirmed_** by the protocol. That's nice, but you should know that an instant confirmation is just a **_promise_** the operators make that they'll add the transaction to the next block. If you trust the operators then you don't need to wait for the transaction to be finalized. + * When you submit a transaction to zkSync, it's ***instantly confirmed*** by the protocol. That's nice, but you should know that an instant confirmation is just a ***promise*** the operators make that they'll add the transaction to the next block. If you trust the operators then you don't need to wait for the transaction to be finalized. * A zkSync transaction is **final** after the SNARK proof is accepted by the Ethereum smart contract. This takes around 10 minutes. @@ -136,19 +136,19 @@ The parameters of this function are self-explanatory, so we won't spend time exp But what happens **after** you call this function? -**_First_**, the transaction gets **mined** on the Ethereum network. At this stage, the transaction is not yet reflected on zkSync. However, if you don't want your users to stare at a blank screen for too long and you trust this is secure enough, you can use the `awaitEthereumTxCommit` function to `await` for the deposit transaction to be mined: +***First***, the transaction gets **mined** on the Ethereum network. At this stage, the transaction is not yet reflected on zkSync. However, if you don't want your users to stare at a blank screen for too long and you trust this is secure enough, you can use the `awaitEthereumTxCommit` function to `await` for the deposit transaction to be mined: ```JavaScript await deposit.awaitEthereumTxCommit() ``` -**_Second_**, the transaction is **committed** to zkSync. When this happens, your **balance gets updated** accordingly. To check when that happens, you can use the `awaitReceipt` function. +***Second***, the transaction is **committed** to zkSync. When this happens, your **balance gets updated** accordingly. To check when that happens, you can use the `awaitReceipt` function. ```JavaScript await deposit.awaitReceipt() ``` -**_Lastly_**, once a specific number of blocks get confirmed on Ethereum, the transaction is considered **finalized** or verified. You can check this by calling the `awaitVerifyReceipt` function. +***Lastly***, once a specific number of blocks get confirmed on Ethereum, the transaction is considered **finalized** or verified. You can check this by calling the `awaitVerifyReceipt` function. ```JavaScript await deposit.awaitVerifyReceipt() diff --git a/fa/17/09.md b/fa/17/09.md index 5b1c6d9291..5cf6eeb036 100644 --- a/fa/17/09.md +++ b/fa/17/09.md @@ -215,12 +215,12 @@ Of course, they would want to see their balance on zkSync. When you transfer assets on zkSync, the operator includes your transaction in a new block and pushes this new block to the zkSync smart contract on Ethereum using a **Commit** transaction. Then, the SNARK proofs for each transaction in the block is and published on Ethereum using a **Verify** transaction. Once the **Verify** transaction is mined on Ethereum, the protocol considers the new state to be final. -Remember that you can receive some tokens and then immediately send those tokens to another user as part of a different transaction? How can that be possible if the protocol waits for the transaction to be mined on Ethereum? The answer is that there are two types of balances on zkSync (**_committed_** and **_verified_**) and you can use the assets in your **committed** balance as you wish. +Remember that you can receive some tokens and then immediately send those tokens to another user as part of a different transaction? How can that be possible if the protocol waits for the transaction to be mined on Ethereum? The answer is that there are two types of balances on zkSync (***committed*** and ***verified***) and you can use the assets in your **committed** balance as you wish. Just to make things clear: -* The **_committed_** balance includes all verified and committed transactions -* The **_verified_** balance includes only verified transactions +* The ***committed*** balance includes all verified and committed transactions +* The ***verified*** balance includes only verified transactions There are two way in which you can retrieve the balances for an account: diff --git a/fa/17/15.md b/fa/17/15.md index 8bf7712e97..d5561a08c7 100644 --- a/fa/17/15.md +++ b/fa/17/15.md @@ -227,7 +227,7 @@ Now let's say Alice wants to withdraw her tokens to Ethereum. This is a two-step 1. Retrieve the withdrawal transfer fee 2. Withdraw assets from zkSync to Ethereum -If you didn't use the "**_Show me the answer_**" button to finish the previous lesson, the steps in this lesson should be a walk in the park. +If you didn't use the "***Show me the answer***" button to finish the previous lesson, the steps in this lesson should be a walk in the park. ## Put it to the test diff --git a/fa/18/01.md b/fa/18/01.md index e499f3bd39..5d3e8af493 100644 --- a/fa/18/01.md +++ b/fa/18/01.md @@ -229,12 +229,12 @@ Before we get into the meat and potatoes, let's get yourself some Rinkeby USDT t 2. Click the **Connect to Web3** link, and then select the wallet you want to use. Note that we recommend MetaMask. 2. Select the **Write Contract** tab 3. To get to the end of this lesson, you must mint at least six USDT tokens. Scroll down to the **mint** function, and populate the following fields: - * **_to**: enter your Rinkeby address - * **_amount**: enter `6000000` (the USDT token has six decimal places) + * ***to**: enter your Rinkeby address + * ***amount**: enter `6000000` (the USDT token has six decimal places) 4. Select the **Write** button. 5. You'll see a Metamask popup. To approve the transaction, select the **Confirm** button. -Now let's get back to why we're here. The first thing you'll have to do is to configure the `src/alice.js` script to use **_USDT_** instead of **_ETH_** for deposits, transfer, and withdrawals. +Now let's get back to why we're here. The first thing you'll have to do is to configure the `src/alice.js` script to use ***USDT*** instead of ***ETH*** for deposits, transfer, and withdrawals. ## Put it to the test diff --git a/fa/2/00-overview.md b/fa/2/00-overview.md index 7cbd56feb0..ee73671f7b 100644 --- a/fa/2/00-overview.md +++ b/fa/2/00-overview.md @@ -9,6 +9,6 @@ path: solidity فصل 2 به شما یاد می دهد که چطور **با تغذیه از سایر اشکال زندگی ، ارتش زامبی خودتون رو چند برابر کنید**. -در این فصل برخی از مفاهیم پیشرفته تر **_Solidity_** را پوشش خواهیم داد ، بنابراین شدیدا +در این فصل برخی از مفاهیم پیشرفته تر ***Solidity*** را پوشش خواهیم داد ، بنابراین شدیدا توصیه می کنم قبل از شروع ، فصل 1 رو کامل کنید.
\ No newline at end of file diff --git a/fa/2/1-overview.md b/fa/2/1-overview.md index 6cad6df574..f82b08a88a 100644 --- a/fa/2/1-overview.md +++ b/fa/2/1-overview.md @@ -20,7 +20,7 @@ material: ## تغذیه زامبی -وقتی که یک زامبی تغذیه می کند، در واقع میزبان رو به ویروس آلوده می کند و به زامبی تبدیل میکنه که جزوی از ارتش شما خواهد شد. **_DNA_** زامبی جدید بر اساس **_DNA_** زامبی قبل و **_DNA_** میطبان محاسبه میشه. +وقتی که یک زامبی تغذیه می کند، در واقع میزبان رو به ویروس آلوده می کند و به زامبی تبدیل میکنه که جزوی از ارتش شما خواهد شد. ***DNA*** زامبی جدید بر اساس ***DNA*** زامبی قبل و ***DNA*** میطبان محاسبه میشه. و زامبی های ما بیشتر دوست دارند از چه چیزی تغذیه کنند؟ @@ -30,7 +30,7 @@ material: یک دموی ساده برای تغذیه در سمت راست وجود دارد. روی یک انسان کلیک کنید تا ببینید چه اتفاقی می افتد وقتی زامبی شما تغذیه می کند! -می بینید که **_DNA_** زامبی جدید توسط **_DNA_** زامبی اصلی شما و همچنین **_DNA_** میزبان تعیین می شود. +می بینید که ***DNA*** زامبی جدید توسط ***DNA*** زامبی اصلی شما و همچنین ***DNA*** میزبان تعیین می شود. وقتی آماده شدید ، برای ادامه کار روی "درس بعدی" کلیک کنید ، و بیایید کار خود را با ساخت چند نفره بازی شروع کنیم. \ No newline at end of file diff --git a/fa/2/10-interactingcontracts.md b/fa/2/10-interactingcontracts.md index 4edaa081dd..486d8d99b0 100644 --- a/fa/2/10-interactingcontracts.md +++ b/fa/2/10-interactingcontracts.md @@ -110,7 +110,7 @@ material: ## تعامل با سایر قراردادها -برای اینکه قرارداد ما با قرارداد دیگری در مورد بلاکچین صحبت کند که ما مالک آن نیستیم، ابتدا باید یک **_interface_** تعریف کنیم. +برای اینکه قرارداد ما با قرارداد دیگری در مورد بلاکچین صحبت کند که ما مالک آن نیستیم، ابتدا باید یک ***interface*** تعریف کنیم. بیایید به یک مثال ساده نگاه کنیم. فرض کنید قراردادی در بلاکچین وجود دارد که به این شکل است: @@ -132,7 +132,7 @@ contract LuckyNumber { حال فرض کنید یک قرارداد خارجی داشتیم که می خواست با استفاده از تابع `getNum` داده های این قرارداد را بخواند. -ابتدا باید **_interface_** قرارداد `LuckyNumber` را تعریف کنیم: +ابتدا باید ***interface*** قرارداد `LuckyNumber` را تعریف کنیم: ``` contract NumberInterface { diff --git a/fa/2/2-mappings.md b/fa/2/2-mappings.md index 1a9b15b97e..a12186f4f0 100644 --- a/fa/2/2-mappings.md +++ b/fa/2/2-mappings.md @@ -84,7 +84,7 @@ material: ## آدرس ها -بلاکچین اتریوم از **_accounts_** تشکیل شده است که می توانید آنها را مانند حساب های بانکی در نظر بگیرید. یک حساب شامل مقداری **_Ether_** (ارز مورد استفاده در بلاک چین اتریوم) است و شما می توانید اتر را به حساب های دیگر ارسال و دریافت کنید ، درست مانند حساب بانکی شما که می تواند پول را به حساب های بانکی دیگر منتقل کند. +بلاکچین اتریوم از ***accounts*** تشکیل شده است که می توانید آنها را مانند حساب های بانکی در نظر بگیرید. یک حساب شامل مقداری ***Ether*** (ارز مورد استفاده در بلاک چین اتریوم) است و شما می توانید اتر را به حساب های دیگر ارسال و دریافت کنید ، درست مانند حساب بانکی شما که می تواند پول را به حساب های بانکی دیگر منتقل کند. هر حساب یک `address` دارد ، که می توانید آن را مانند شماره حساب بانکی در نظر بگیرید. که یک شناسه منحصر به فرد است که به آن حساب اشاره می کند و به این شکل است: @@ -98,7 +98,7 @@ material: ## Mappings -در فصل 1 ما **_structs_** و **_arrays_** را بررسی کردیم. **_Mappings_** روش دیگری برای ذخیره سازی داده های سازمان یافته در Solidity است. +در فصل 1 ما ***structs*** و ***arrays*** را بررسی کردیم. ***Mappings*** روش دیگری برای ذخیره سازی داده های سازمان یافته در Solidity است. تعریف `mapping` به این شکل است: diff --git a/fa/2/5-inheritance.md b/fa/2/5-inheritance.md index d9901c680e..360a264766 100644 --- a/fa/2/5-inheritance.md +++ b/fa/2/5-inheritance.md @@ -95,7 +95,7 @@ material:
کد بازی ما در حال زیاد شدن است. به جای ساخت یک قرارداد بسیار طولانی ، گاهی اوقات منطقی است که منطق کد خود را در چندین قرارداد برای سازماندهی کد تقسیم کنید. -یکی از ویژگی های Solidity که این قابلیت را بیشتر کنترل می کند ، **_inheritance_** یا وراثت قرارداد است: +یکی از ویژگی های Solidity که این قابلیت را بیشتر کنترل می کند ، ***inheritance*** یا وراثت قرارداد است: ``` contract Doge { diff --git a/fa/2/7-storage.md b/fa/2/7-storage.md index 8e8fea58a4..fb678df1dc 100644 --- a/fa/2/7-storage.md +++ b/fa/2/7-storage.md @@ -72,11 +72,11 @@ material:
در Solidity ، دو مکان وجود دارد که می توانید متغیرها را ذخیره کنید - در `storage` و `memory`. -**_Storage_** به متغیرهایی گفته می شود که به طور دائمی در زنجیره بلوک ذخیره می شوند. **_Memory_** متغیرها موقتی هستند و بین فراخوانی های خارجی توابع قرارداد شما، پاک می شوند. به آن مانند دیسک سخت و RAM در کامپیوترتان فکر کنید. +***Storage*** به متغیرهایی گفته می شود که به طور دائمی در زنجیره بلوک ذخیره می شوند. ***Memory*** متغیرها موقتی هستند و بین فراخوانی های خارجی توابع قرارداد شما، پاک می شوند. به آن مانند دیسک سخت و RAM در کامپیوترتان فکر کنید. بیشتر اوقات نیازی به استفاده از این کلمات کلیدی نیست زیرا Solidity به طور پیش فرض آنها را کنترل می کند. متغیرهای State (متغیرهای اعلام شده در خارج از توابع) بصورت پیش فرض `storage` هستند و برای همیشه در بلاکچین نوشته می شوند ، در حالی که متغیرهای اعلام شده در داخل توابع `memory` هستند و با پایان دادن به فراخوانی تابع از بین می روند. -با این حال ، مواردی وجود دارد که شما مجبور به استفاده از این کلمات کلیدی هستید ، به عنوان مثال در هنگام برخورد با **_structs_** و **_arrays_** در توابع: +با این حال ، مواردی وجود دارد که شما مجبور به استفاده از این کلمات کلیدی هستید ، به عنوان مثال در هنگام برخورد با ***structs*** و ***arrays*** در توابع: ``` contract SandwichFactory { diff --git a/fa/3/01-externaldependencies.md b/fa/3/01-externaldependencies.md index 13110b591b..722afb38a9 100644 --- a/fa/3/01-externaldependencies.md +++ b/fa/3/01-externaldependencies.md @@ -145,7 +145,7 @@ material: تا الان سالیدیتی خیلی شبیه زبان‌های برنامه‌نویسی دیگه مثل جاوااسکریپت به نظر می‌اومد. اما مواردی هست که اپلیکیشن‌های اتریوم تفاوت بسیاری با اپلیکیشن‌های معمولی دارند. -یکی از اون موارد اینه که، بعد از اینکه قرارداد رو در شبکه اتریوم دیپلوی کردین، **_immutable_ (غیرقابل تغییر)** خواهد بود یعنی امکان به‌روزرسانی یا تغییر نداره. +یکی از اون موارد اینه که، بعد از اینکه قرارداد رو در شبکه اتریوم دیپلوی کردین، ***immutable_ (غیرقابل تغییر)** خواهد بود یعنی امکان به‌روزرسانی یا تغییر نداره. کد اولیه‌ای که در قرارداد می‌نویسین همیشه در بلاکچین، ماندگار خواهد بود. به همین دلیله که امنیت، یکی از موارد مهم در سالیدیتی به شمار می‌آد.اگر خطایی در قرارداد شما باشه، به هیچ وجه امکان اصلاح نخواهد داشت. و در این موارد باید آدرس یک قرارداد هوشمند دیگری که اصلاح شده است را در اختیار کاربرانتان قرار دهید. diff --git a/fa/3/02-ownable.md b/fa/3/02-ownable.md index 8af95fda98..d51fcc00e3 100644 --- a/fa/3/02-ownable.md +++ b/fa/3/02-ownable.md @@ -226,7 +226,7 @@ material: ## قرارداد `Ownable` از OpenZeppelin -در ادامه قرارداد `Ownable` رو از کتابخونه سالیدیتی **_OpenZeppelin_** می‌بینید. OpenZeppelin یک کتابخونه برای تامین امنیت قراردادهاست که مورد تایید جامعه بلاکچین اتریومه که می‌تونین در دپ خودتون ازش استفاده کنید. بعد از اتمام این درس پیشنهاد می‌شه که یه سری به وبسایتشون بزنید تا اطلاعات بیشتری درباره‌ش کسب کنین. +در ادامه قرارداد `Ownable` رو از کتابخونه سالیدیتی ***OpenZeppelin*** می‌بینید. OpenZeppelin یک کتابخونه برای تامین امنیت قراردادهاست که مورد تایید جامعه بلاکچین اتریومه که می‌تونین در دپ خودتون ازش استفاده کنید. بعد از اتمام این درس پیشنهاد می‌شه که یه سری به وبسایتشون بزنید تا اطلاعات بیشتری درباره‌ش کسب کنین. یه نگاهی به قرارداد زیر بندازین، مواردی رو می‌بینید که هنوز یاد نگرفتین، اما نگران نباشید در ادامه درباره‌شون صحبت می‌کنیم.
@@ -309,7 +309,7 @@ contract Ownable {
بعضی از چیزایی که قبلا ندیدیم: -- سازنده‌ها (Constructors): `constructor()` یک **_سازنده_** است، یک تابع اختیاری خاص. فقط یک بار اجرا می‌شه، زمانی که قرارداد برای اولین بار ساخته شد. +- سازنده‌ها (Constructors): `constructor()` یک ***سازنده*** است، یک تابع اختیاری خاص. فقط یک بار اجرا می‌شه، زمانی که قرارداد برای اولین بار ساخته شد. - متغیرهای تابع(Function Modifiers): تغییردهنده‌ها(Modifiers) یه جورایی نیمه‌تابع هستند که برای تغییر توابع دیگر استفاده می‌شن، معمولا برای اینکه یک‌سری پیش‌نیازها رو قبل از اجرا چک کنن. در اینجا، `modifier onlyOwner()` برای محدودکردن دسترسی استفاده می‌شه پس **فقط مالک** قرارداد می‌تونه این تابع رو اجرا کنه. بعدا بیشتر درباره تغییردهنده‌ها و این علامت عجیب `_;` صحبت می‌کنیم. - کلمه کلیدی `indexed` : فعلا بهش نیاز نداریم، نگرانش نباشید. پس اساسا قرارداد `Ownable` موارد زیر رو انجام می‌ده: diff --git a/fa/3/04-gas.md b/fa/3/04-gas.md index 99a4d13339..bff38b8f1d 100644 --- a/fa/3/04-gas.md +++ b/fa/3/04-gas.md @@ -224,7 +224,7 @@ material: ## گس - سوختی که دپ‌های اتریوم با آن کار می‌کنند -در سالیدیتی، کارابران دپ شما هر بار که یک تابعی رو اجرا می‌کنند باید هزینه‌ای رو پرداخت کنند و واحد این ارز **_gas(گس)** نام داره. کاربران با اتر (واحد ارز اتریوم) گس خریداری می‌کنند، بنابراین کاربران شما برای اجرای توابع باید اتر خرج کنند. +در سالیدیتی، کارابران دپ شما هر بار که یک تابعی رو اجرا می‌کنند باید هزینه‌ای رو پرداخت کنند و واحد این ارز ***gas(گس)** نام داره. کاربران با اتر (واحد ارز اتریوم) گس خریداری می‌کنند، بنابراین کاربران شما برای اجرای توابع باید اتر خرج کنند. مقدار گس مورد نیاز برای اجرای تابع به پیچیدگی منطق تابع بستگی داره. **هزینه گس** هر عملیات براساس میزان منابعی که برای انجام اون عملیات نیازه، تعیین می‌شه (برای مثال- هزینه نوشتن روی حافظه خیلی بیشتر از جمع دو عدد صحیحه). **هزینه گس** تابع می‌شه مجموع هزینه‌های گس تک تک عملیات اون تابع. diff --git a/fa/4/battle-02.md b/fa/4/battle-02.md index 7c78623642..6efbd25b3e 100644 --- a/fa/4/battle-02.md +++ b/fa/4/battle-02.md @@ -285,7 +285,7 @@ It would then "pack" the inputs and use `keccak` to convert them to a random has ### This method is vulnerable to attack by a dishonest node -In Ethereum, when you call a function on a contract, you broadcast it to a node or nodes on the network as a **_transaction_**. The nodes on the network then collect a bunch of transactions, try to be the first to solve a computationally-intensive mathematical problem as a "Proof of Work", and then publish that group of transactions along with their Proof of Work (PoW) as a **_block_** to the rest of the network. +In Ethereum, when you call a function on a contract, you broadcast it to a node or nodes on the network as a ***transaction***. The nodes on the network then collect a bunch of transactions, try to be the first to solve a computationally-intensive mathematical problem as a "Proof of Work", and then publish that group of transactions along with their Proof of Work (PoW) as a ***block*** to the rest of the network. Once a node has solved the PoW, the other nodes stop trying to solve the PoW, verify that the other node's list of transactions are valid, and then accept the block and move on to trying to solve the next block. @@ -297,7 +297,7 @@ If I were running a node, I could publish a transaction **only to my own node** ## So how do we generate random numbers safely in Ethereum? -Because the entire contents of the blockchain are visible to all participants, this is a hard problem, and its solution is beyond the scope of this tutorial. You can read this StackOverflow thread for some ideas. One idea would be to use an **_oracle_** to access a random number function from outside of the Ethereum blockchain. +Because the entire contents of the blockchain are visible to all participants, this is a hard problem, and its solution is beyond the scope of this tutorial. You can read this StackOverflow thread for some ideas. One idea would be to use an ***oracle*** to access a random number function from outside of the Ethereum blockchain. Of course, since tens of thousands of Ethereum nodes on the network are competing to solve the next block, my odds of solving the next block are extremely low. It would take me a lot of time or computing resources to exploit this profitably — but if the reward were high enough (like if I could bet $100,000,000 on the coin flip function), it would be worth it for me to attack. @@ -305,7 +305,7 @@ So while this random number generation is NOT secure on Ethereum, in practice un Because we're just building a simple game for demo purposes in this tutorial and there's no real money on the line, we're going to accept the tradeoffs of using a random number generator that is simple to implement, knowing that it isn't totally secure. -In a future lesson, we may cover using **_oracles_** (a secure way to pull data in from outside of Ethereum) to generate secure random numbers from outside the blockchain. +In a future lesson, we may cover using ***oracles*** (a secure way to pull data in from outside of Ethereum) to generate secure random numbers from outside the blockchain. ## Put it to the test diff --git a/fa/4/battle-08.md b/fa/4/battle-08.md index d6d41fe6de..e2af79a746 100644 --- a/fa/4/battle-08.md +++ b/fa/4/battle-08.md @@ -292,7 +292,7 @@ In chapter 6 we calculated a random number from 0 to 100. Now let's use that num ## Put it to the test -1. Create an `if` statement that checks if `rand` is **_less than or equal to_** `attackVictoryProbability`. +1. Create an `if` statement that checks if `rand` is ***less than or equal to*** `attackVictoryProbability`. 2. If this condition is true, our zombie wins! So: diff --git a/fa/4/payable.md b/fa/4/payable.md index 990e6bb095..0a222d5c89 100644 --- a/fa/4/payable.md +++ b/fa/4/payable.md @@ -265,7 +265,7 @@ material: } --- -Up until now, we've covered quite a few **_function modifiers_**. It can be difficult to try to remember everything, so let's run through a quick review: +Up until now, we've covered quite a few ***function modifiers***. It can be difficult to try to remember everything, so let's run through a quick review: 1. We have visibility modifiers that control when and where the function can be called from: `private` means it's only callable from other functions inside the contract; `internal` is like `private` but can also be called by contracts that inherit from this one; `external` can only be called outside the contract; and finally `public` can be called anywhere, both internally and externally. diff --git a/fa/5/01-erc721-1.md b/fa/5/01-erc721-1.md index 818b3635b9..71069df6fc 100644 --- a/fa/5/01-erc721-1.md +++ b/fa/5/01-erc721-1.md @@ -284,11 +284,11 @@ material: } --- -Let's talk about **_tokens_**. +Let's talk about ***tokens***. -If you've been in the Ethereum space for any amount of time, you've probably heard people talking about tokens — specifically **_ERC20 tokens_**. +If you've been in the Ethereum space for any amount of time, you've probably heard people talking about tokens — specifically ***ERC20 tokens***. -A **_token_** on Ethereum is basically just a smart contract that follows some common rules — namely it implements a standard set of functions that all other token contracts share, such as `transferFrom(address _from, address _to, uint256 _tokenId)` and `balanceOf(address _owner)`. +A ***token*** on Ethereum is basically just a smart contract that follows some common rules — namely it implements a standard set of functions that all other token contracts share, such as `transferFrom(address _from, address _to, uint256 _tokenId)` and `balanceOf(address _owner)`. Internally the smart contract usually has a mapping, `mapping(address => uint256) balances`, that keeps track of how much balance each address has. @@ -312,9 +312,9 @@ For one, zombies aren't divisible like currencies — I can send you 0.237 ETH, Secondly, all zombies are not created equal. Your Level 2 zombie "**Steve**" is totally not equal to my Level 732 zombie "**H4XF13LD MORRIS 💯💯😎💯💯**". (Not even close, *Steve*). -There's another token standard that's a much better fit for crypto-collectibles like CryptoZombies — and they're called **_ERC721 tokens._** +There's another token standard that's a much better fit for crypto-collectibles like CryptoZombies — and they're called ***ERC721 tokens.*** -**_ERC721 tokens_** are **not** interchangeable since each one is assumed to be unique, and are not divisible. You can only trade them in whole units, and each one has a unique ID. So these are a perfect fit for making our zombies tradeable. +***ERC721 tokens*** are **not** interchangeable since each one is assumed to be unique, and are not divisible. You can only trade them in whole units, and each one has a unique ID. So these are a perfect fit for making our zombies tradeable. > Note that using a standard like ERC721 has the benefit that we don't have to implement the auction or escrow logic within our contract that determines how players can trade / sell our zombies. If we conform to the spec, someone else could build an exchange platform for crypto-tradable ERC721 assets, and our ERC721 zombies would be usable on that platform. So there are clear benefits to using a token standard instead of rolling your own trading logic. diff --git a/fa/5/09-safemath-1.md b/fa/5/09-safemath-1.md index b2b40444da..841d406ed9 100644 --- a/fa/5/09-safemath-1.md +++ b/fa/5/09-safemath-1.md @@ -429,7 +429,7 @@ But we wanted to keep this lesson manageable, so we went with the most basic imp We're going to look at one major security feature you should be aware of when writing smart contracts: Preventing overflows and underflows. -What's an **_overflow_**? +What's an ***overflow***? Let's say we have a `uint8`, which can only have 8 bits. That means the largest number we can store is binary `11111111` (or in decimal, 2^8 - 1 = 255). @@ -448,11 +448,11 @@ While we're not using `uint8` here, and it seems unlikely that a `uint256` will ### Using SafeMath -To prevent this, OpenZeppelin has created a **_library_** called SafeMath that prevents these issues by default. +To prevent this, OpenZeppelin has created a ***library*** called SafeMath that prevents these issues by default. But before we get into that... What's a library? -A **_library_** is a special type of contract in Solidity. One of the things it is useful for is to attach functions to native data types. +A ***library*** is a special type of contract in Solidity. One of the things it is useful for is to attach functions to native data types. For example, with the SafeMath library, we'll use the syntax `using SafeMath for uint256`. The SafeMath library has 4 functions — `add`, `sub`, `mul`, and `div`. And now we can access these functions from `uint256` as follows: diff --git a/fa/5/13-comments.md b/fa/5/13-comments.md index 0ffed1aa16..b6649a94b2 100644 --- a/fa/5/13-comments.md +++ b/fa/5/13-comments.md @@ -523,7 +523,7 @@ contract CryptoZombies { In particular, it's good practice to comment your code to explain the expected behavior of every function in your contract. This way another developer (or you, after a 6 month hiatus from a project!) can quickly skim and understand at a high level what your code does without having to read the code itself. -The standard in the Solidity community is to use a format called **_natspec_**, which looks like this: +The standard in the Solidity community is to use a format called ***natspec***, which looks like this: ``` /// @title A contract for basic math operations diff --git a/fa/5/14-wrappingitup.md b/fa/5/14-wrappingitup.md index 9040e18f83..041f8977b6 100644 --- a/fa/5/14-wrappingitup.md +++ b/fa/5/14-wrappingitup.md @@ -33,6 +33,6 @@ In this lesson we learned about: This lesson concludes our game's Solidity code! (For now — we may add even more lessons in the future). -In the next 2 lessons, we're going to look at how to deploy your contracts and interact with them using **_web3.js_** (so you can build a front-end for your DApp). +In the next 2 lessons, we're going to look at how to deploy your contracts and interact with them using ***web3.js*** (so you can build a front-end for your DApp). Go ahead and rename any of your zombies if you like, then proceed to the next chapter to complete the lesson. diff --git a/fa/6/01.md b/fa/6/01.md index ab28049aa2..561a9bd354 100644 --- a/fa/6/01.md +++ b/fa/6/01.md @@ -469,7 +469,7 @@ material: By completing Lesson 5, our zombie DApp is now complete. Now we're going to create a basic web page where your users can interact with it. -To do this, we're going to use a JavaScript library from the Ethereum Foundation called **_Web3.js_**. +To do this, we're going to use a JavaScript library from the Ethereum Foundation called ***Web3.js***. ## What is Web3.js? @@ -479,7 +479,7 @@ Remember, the Ethereum network is made up of nodes, with each containing a copy 2. The function you want to call, and 3. The variables you want to pass to that function. -Ethereum nodes only speak a language called **_JSON-RPC_**, which isn't very human-readable. A query to tell the node you want to call a function on a contract looks something like this: +Ethereum nodes only speak a language called ***JSON-RPC***, which isn't very human-readable. A query to tell the node you want to call a function on a contract looks something like this: ``` // Yeah... Good luck writing all your function calls this way! diff --git a/fa/6/02.md b/fa/6/02.md index a4e706c8a9..1d177b91f1 100644 --- a/fa/6/02.md +++ b/fa/6/02.md @@ -489,11 +489,11 @@ material: Great! Now that we have Web3.js in our project, let's get it initialized and talking to the blockchain. -The first thing we need is a **_Web3 Provider_**. +The first thing we need is a ***Web3 Provider***. -Remember, Ethereum is made up of **_nodes_** that all share a copy of the same data. Setting a Web3 Provider in Web3.js tells our code **which node** we should be talking with to handle our reads and writes. It's kind of like setting the URL of the remote web server for your API calls in a traditional web app. +Remember, Ethereum is made up of ***nodes*** that all share a copy of the same data. Setting a Web3 Provider in Web3.js tells our code **which node** we should be talking with to handle our reads and writes. It's kind of like setting the URL of the remote web server for your API calls in a traditional web app. -You could host your own Ethereum node as a provider. However, there's a third-party service that makes your life easier so you don't need to maintain your own Ethereum node in order to provide a DApp for your users — **_Infura_**. +You could host your own Ethereum node as a provider. However, there's a third-party service that makes your life easier so you don't need to maintain your own Ethereum node in order to provide a DApp for your users — ***Infura***. ## Infura @@ -511,7 +511,7 @@ However, since our DApp is going to be used by many users — and these users a Cryptography is complicated, so unless you're a security expert and you really know what you're doing, it's probably not a good idea to try to manage users' private keys yourself in our app's front-end. -But luckily you don't need to — there are already services that handle this for you. The most popular of these is **_Metamask_**. +But luckily you don't need to — there are already services that handle this for you. The most popular of these is ***Metamask***. ## Metamask diff --git a/fa/6/03.md b/fa/6/03.md index 4537cb1284..2bdcbd7c5e 100644 --- a/fa/6/03.md +++ b/fa/6/03.md @@ -955,7 +955,7 @@ material: Now that we've initialized Web3.js with MetaMask's Web3 provider, let's set it up to talk to our smart contract. -Web3.js will need 2 things to talk to your contract: its **_address_** and its **_ABI_**. +Web3.js will need 2 things to talk to your contract: its ***address*** and its ***ABI***. ## Contract Address @@ -967,7 +967,7 @@ You'll need to copy this address after deploying in order to talk to your smart ## Contract ABI -The other thing Web3.js will need to talk to your contract is its **_ABI_**. +The other thing Web3.js will need to talk to your contract is its ***ABI***. ABI stands for Application Binary Interface. Basically it's a representation of your contracts' methods in JSON format that tells Web3.js how to format function calls in a way your contract will understand. diff --git a/fa/7/02.md b/fa/7/02.md index 055ee948a5..0a010aa65a 100644 --- a/fa/7/02.md +++ b/fa/7/02.md @@ -483,7 +483,7 @@ We've abstracted these into a library, so you won't need to put the same boilerp ### "Hooks" — the heart of every custom game mode -The first step for every custom game mode is to implement at least one **_hook_**. +The first step for every custom game mode is to implement at least one ***hook***. Basically, the core game logic will look for and call certain functions from your contract at certain parts of the game, if they exist in your code. diff --git a/fa/8/04.md b/fa/8/04.md index 6f0412d72b..36ad2ce814 100644 --- a/fa/8/04.md +++ b/fa/8/04.md @@ -576,7 +576,7 @@ Making these custom game modes is super simple, right? Now let's move on to the next one: -_**Singleton:** When assembling your deck of 30 cards to play, no card may share a name with another card in the deck._ +***Singleton:** When assembling your deck of 30 cards to play, no card may share a name with another card in the deck._ To start with, we've forked (made a copy of) `munchkin.sol` and called it `singleton.sol`. diff --git a/fa/9/01-erc721x.md b/fa/9/01-erc721x.md index 4528081c42..83ad466320 100644 --- a/fa/9/01-erc721x.md +++ b/fa/9/01-erc721x.md @@ -246,7 +246,7 @@ For our first chapter, let's start with some background to make sure we're all o Referring to in-game items as "tokens" can be a bit misleading, since the word "token" implies something that would be spent like a currency. -But the word **_token_** on Ethereum simply refers to a standard for smart contracts that all implement the same common functions, such as `transfer(address _to, uint256 _value)` and `balanceOf(address _owner)`. +But the word ***token*** on Ethereum simply refers to a standard for smart contracts that all implement the same common functions, such as `transfer(address _to, uint256 _value)` and `balanceOf(address _owner)`. Yes, you can transfer and have a balance of a currency — but you can also transfer and have an inventory of items in a game, like swords or playing cards. @@ -256,15 +256,15 @@ Thus the concept of a "token" is useful for abstracting out these common methods ## Different Token Standards: ERC20 and ERC721 -The most commonly known token standard is the **_ERC20 token_**. These tokens act like currencies. But they're not particularly useful for representing digital items, such as cards in a card trading game. +The most commonly known token standard is the ***ERC20 token***. These tokens act like currencies. But they're not particularly useful for representing digital items, such as cards in a card trading game. First of all, cards aren't divisible like currencies — you can't own 2/5ths of a playing card. Second, not all cards are created equal, so they're not interchangeable. You wouldn't want to exchange your **Z-Virus** card for my **Ozmoziz**. -There's another token standard that's a much better fit for crypto-collectibles — and they're called **_ERC721 tokens._** +There's another token standard that's a much better fit for crypto-collectibles — and they're called ***ERC721 tokens.*** -**_ERC721 tokens_** are **not** interchangeable. Each item is assumed to be unique, and has a unique ID. They're also not divisible — you can only trade them in whole units. +***ERC721 tokens*** are **not** interchangeable. Each item is assumed to be unique, and has a unique ID. They're also not divisible — you can only trade them in whole units. So these are a better fit for making our card trading game. diff --git a/fa/9/03-erc721x.md b/fa/9/03-erc721x.md index bcd5968503..c564c04b23 100644 --- a/fa/9/03-erc721x.md +++ b/fa/9/03-erc721x.md @@ -265,7 +265,7 @@ material: } --- -With a normal ERC20 or ERC721 token, we have the concept of **_token supply_** — this is how many of that token exist in total. +With a normal ERC20 or ERC721 token, we have the concept of ***token supply*** — this is how many of that token exist in total. With ERC721x Multi-Fungible tokens, we can actually have multiple tokens defined in the same contract — and each one will have its own "supply" (number of tokens that exist). diff --git a/fa/9/10-erc721x.md b/fa/9/10-erc721x.md index d448e1be45..9df841ba09 100644 --- a/fa/9/10-erc721x.md +++ b/fa/9/10-erc721x.md @@ -357,7 +357,7 @@ material: We are almost done! Let's wrap up our contract with one more function, then do some review. -The last thing we're going to implement is **_batch minting_** tokens. This function will allow us to mint many tokens in a single function call — and is one of the reasons ERC721x allows us to save so much on gas fees on Ethereum. +The last thing we're going to implement is ***batch minting*** tokens. This function will allow us to mint many tokens in a single function call — and is one of the reasons ERC721x allows us to save so much on gas fees on Ethereum. With everything we've set up until now, the function is quite simple to implement. diff --git a/fa/lessoncomplete.md b/fa/lessoncomplete.md index 9cc39b2c62..18d3bfe928 100644 --- a/fa/lessoncomplete.md +++ b/fa/lessoncomplete.md @@ -9,9 +9,9 @@ Well done!👏🏻👏🏻👏🏻 You mastered the art of deploying smart contracts using **Truffle**! -Remember, building on top of **_Loom_** brings you faster, gas-free transactions that make it the perfect choice for creating blockchain games and user-facing DApps. At the same time, your users will enjoy the guaranteed security that Ethereum provides! +Remember, building on top of ***Loom*** brings you faster, gas-free transactions that make it the perfect choice for creating blockchain games and user-facing DApps. At the same time, your users will enjoy the guaranteed security that Ethereum provides! -Another thing to remember is how similar deploying to **_Loom_** is to deploying to the Ethereum mainnet. You now know how to do both, just be careful how you choose which one to use for your next project😉. +Another thing to remember is how similar deploying to ***Loom*** is to deploying to the Ethereum mainnet. You now know how to do both, just be careful how you choose which one to use for your next project😉. Anyway, this was just an example — we made several decisions that simplified things a bit to make the lesson easier to understand. diff --git a/fr/1/arrays.md b/fr/1/arrays.md index 564f1e7f84..dcd8cd0944 100644 --- a/fr/1/arrays.md +++ b/fr/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -Quand vous voulez regrouper des éléments, vous pouvez utiliser un **_tableau_** (array). il y a deux sortes de tableaux dans Solidity : les tableaux **_fixes_** et les tableaux **_dynamiques_** : +Quand vous voulez regrouper des éléments, vous pouvez utiliser un ***tableau*** (array). il y a deux sortes de tableaux dans Solidity : les tableaux ***fixes*** et les tableaux ***dynamiques*** : ``` // Tableau avec une longueur fixe de 2 éléments : @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -Vous pouvez aussi créer un tableau de **_structure_**. En utilisant la structure Person du chapitre précédent : +Vous pouvez aussi créer un tableau de ***structure***. En utilisant la structure Person du chapitre précédent : ``` Person[] people; // Tableau dynamique, on peut en rajouter sans limite. @@ -60,7 +60,7 @@ Vous vous rappelez que les variables d'état sont stockées définitivement dans ## Tableaux publics -Vous pouvez déclarer un tableau comme `public`, et Solidity créera automatiquement une méthode **_d'accès_**. La syntaxe ressemble à : +Vous pouvez déclarer un tableau comme `public`, et Solidity créera automatiquement une méthode ***d'accès***. La syntaxe ressemble à : ``` Person[] public people; @@ -71,4 +71,4 @@ Les autres contrats vont pouvoir lire (mais pas écrire) ce tableau. C'est donc Nous allons vouloir stocker une armée de zombies dans notre application. Et nous allons vouloir montrer tous nos zombies à d'autres applications, cette armée devra donc être publique. -1. Créez un tableau public de **_structures_** `Zombie`, et appelez le `zombies`. +1. Créez un tableau public de ***structures*** `Zombie`, et appelez le `zombies`. diff --git a/fr/1/datatypes.md b/fr/1/datatypes.md index dd4acc06bf..866571617b 100644 --- a/fr/1/datatypes.md +++ b/fr/1/datatypes.md @@ -25,7 +25,7 @@ material: Bien joué ! Maintenant que nous avons une structure pour notre contrat, voyons voir comment Solidity gère les variables. -**_Les variables d'état_** sont stockées de manière permanente dans le stockage du contrat. Cela signifie qu'elles sont écrites dans la blockchain Ethereum. C'est comme écrire dans une base de données. +***Les variables d'état*** sont stockées de manière permanente dans le stockage du contrat. Cela signifie qu'elles sont écrites dans la blockchain Ethereum. C'est comme écrire dans une base de données. ##### Exemple: ``` diff --git a/fr/1/events.md b/fr/1/events.md index 672a5f2ef7..d917ce1104 100644 --- a/fr/1/events.md +++ b/fr/1/events.md @@ -73,9 +73,9 @@ material: } --- -Notre contrat est presque fini ! nous allons maintenant ajouter un **_ évènement _** (event). +Notre contrat est presque fini ! nous allons maintenant ajouter un *** évènement *** (event). -Un **_ évènement _** est un moyen pour votre contrat d'indiquer à votre application frontale (front-end) que quelque chose vient d'arriver sur la blockchain, l'application frontale pouvant être «à l'écoute» de certains événements pour prendre des mesures quand ils se produisent. +Un *** évènement *** est un moyen pour votre contrat d'indiquer à votre application frontale (front-end) que quelque chose vient d'arriver sur la blockchain, l'application frontale pouvant être «à l'écoute» de certains événements pour prendre des mesures quand ils se produisent. Exemple : diff --git a/fr/1/functions3.md b/fr/1/functions3.md index b2909a6fbf..357a4f926c 100644 --- a/fr/1/functions3.md +++ b/fr/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -Dans ce chapitre, nous allons apprendre les **_valeurs retournées_** des fonctions, ainsi que les modificateurs de fonction. +Dans ce chapitre, nous allons apprendre les ***valeurs retournées*** des fonctions, ainsi que les modificateurs de fonction. ## Valeurs retournées @@ -73,19 +73,19 @@ En Solidity, une déclaration de fonction indique le type de la valeur retourné La fonction ci-dessus ne change pas un état en Solidity - c.-à-d. elle ne change pas une valeur et n'écrit rien. -Dans ce cas là, nous pouvons la déclarer comme une fonction **_view_** (vue), cela veut dire qu'elle va seulement voir des données sans les modifier : +Dans ce cas là, nous pouvons la déclarer comme une fonction ***view*** (vue), cela veut dire qu'elle va seulement voir des données sans les modifier : ``` function sayHello() public view returns (string) { ``` -Solidity a aussi des fonctions **_pure_**, cela veut dire que vous n'avez même pas accès à des données de l'application. Par exemple : +Solidity a aussi des fonctions ***pure***, cela veut dire que vous n'avez même pas accès à des données de l'application. Par exemple : ``` function _multiply(uint a, uint b) private pure returns (uint) { return a * b; } ``` -Cette fonction ne lit aucune donnée du contrat - elle retourne une valeur qui dépend seulement de ses arguments. Dans ce cas là, nous déclarerons la fonction comme **_pure_**. +Cette fonction ne lit aucune donnée du contrat - elle retourne une valeur qui dépend seulement de ses arguments. Dans ce cas là, nous déclarerons la fonction comme ***pure***. > Remarque: Il peut être difficile de se rappeler quand marquer les fonctions comme étant pure/view. Heureusement, le compilateur Solidity est bon pour vous avertir quand vous devriez utiliser l'un ou l'autre de ces modificateurs. diff --git a/fr/1/lessoncomplete.md b/fr/1/lessoncomplete.md index bc88b5a2e6..b58ff67835 100644 --- a/fr/1/lessoncomplete.md +++ b/fr/1/lessoncomplete.md @@ -14,8 +14,8 @@ Ce n'est que le début. Chaque semaine, nous allons publier une nouvelle leçon ### 1. Connectez-vous pour sauvegarder vos progrès -**_Connectez-vous_** pour sauvegarder vos progrès en cliquant sur le lien "Sauvegarder" en haut de la page. Nous vous informerons dès qu'une nouvelle leçon sera disponible. +***Connectez-vous*** pour sauvegarder vos progrès en cliquant sur le lien "Sauvegarder" en haut de la page. Nous vous informerons dès qu'une nouvelle leçon sera disponible. ### 2. Partagez votre zombie avec vos amis -**_Partagez_** votre zombie sur Twitter, bla bla, etc. (Insérer une image / liens) +***Partagez*** votre zombie sur Twitter, bla bla, etc. (Insérer une image / liens) diff --git a/fr/1/math.md b/fr/1/math.md index 4332224f56..0274953f5c 100644 --- a/fr/1/math.md +++ b/fr/1/math.md @@ -34,7 +34,7 @@ Les opérations Mathématiques en Solidity sont assez simples. Les opérations s * Division : `x / y` * Modulo / reste : `x % y` _(par exemple, `13 % 5` est `3`, car si vous divisez 13 par 5, le reste est 3)_ -Solidity prend aussi en charge l'**_opérateur exponentiel_** (c.-à-d. "x à la puissance y", x^y) : +Solidity prend aussi en charge l'***opérateur exponentiel*** (c.-à-d. "x à la puissance y", x^y) : ``` uint x = 5 ** 2; // égal à 5^2 = 25 diff --git a/fr/1/structs.md b/fr/1/structs.md index 0d69061ec3..910ba6c7bc 100644 --- a/fr/1/structs.md +++ b/fr/1/structs.md @@ -32,7 +32,7 @@ material: } --- -Il est possible que vous ayez besoin d'un type de données plus complexe. Pour cela, Solidity fournit les **_structures_** (struct) : +Il est possible que vous ayez besoin d'un type de données plus complexe. Pour cela, Solidity fournit les ***structures*** (struct) : ``` struct Person { diff --git a/fr/1/web3js.md b/fr/1/web3js.md index 08b199ade8..0d3cf4fb06 100644 --- a/fr/1/web3js.md +++ b/fr/1/web3js.md @@ -12,7 +12,7 @@ material: Notre contrat Solidity est fini ! Maintenant nous devons écrire la partie client en JavaScript pour interagir avec le contrat. -Ethereum a une bibliothèque JavaScript appelée **_Web3.js_**. +Ethereum a une bibliothèque JavaScript appelée ***Web3.js***. Dans une prochaine leçon, nous verrons en détail comment déployer un contrat et configurer Web3.js. Mais pour l'instant, regardons simplement un exemple de code pour voir comment Web3.js pourrait interagir avec notre contrat déployé. diff --git a/fr/2/10-interactingcontracts.md b/fr/2/10-interactingcontracts.md index 7f30f50ad8..d943277221 100644 --- a/fr/2/10-interactingcontracts.md +++ b/fr/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ Ne vous en faites pas - notre jeu ne va faire de mal à aucun CryptoKitty. Nous ## Interagir avec d'autres contrats -Pour que notre contrat puisse parler avec un autre contrat que nous ne possédons pas sur la blockchain, nous allons avoir besoin de définir une **_interface_**. +Pour que notre contrat puisse parler avec un autre contrat que nous ne possédons pas sur la blockchain, nous allons avoir besoin de définir une ***interface***. Prenons un exemple simple. Imaginons un contrat comme celui-ci sur la blockchain : @@ -130,7 +130,7 @@ Cela serait un simple contrat où n'importe qui pourrait stocker son nombre port Maintenant, imaginons que nous avons un contrat externe qui voudrait lire les données de ce contrat en utilisant la fonction `getNum`. -Premièrement, nous devrions définir une **_interface_** du contract `LuckyNumber` : +Premièrement, nous devrions définir une ***interface*** du contract `LuckyNumber` : ``` contract NumberInterface { diff --git a/fr/2/2-mappings.md b/fr/2/2-mappings.md index 086015ff2f..9757198693 100644 --- a/fr/2/2-mappings.md +++ b/fr/2/2-mappings.md @@ -84,7 +84,7 @@ Pour cela, nous allons avoir besoin de 2 nouveaux types de données : `mapping` ## Adresses -La blockchain Ethereum est constituée de **_comptes_**, un peu comme des comptes en banque. Un compte a un montant d'**_Ether_** (c'est la monnaie utilisée sur la blockchain Ethereum), et vous pouvez envoyer des Ethers à d'autres comptes ou en recevoir, de la même manière que vous pouvez transférer de l'argent d'un compte bancaire à un autre. +La blockchain Ethereum est constituée de ***comptes***, un peu comme des comptes en banque. Un compte a un montant d'***Ether*** (c'est la monnaie utilisée sur la blockchain Ethereum), et vous pouvez envoyer des Ethers à d'autres comptes ou en recevoir, de la même manière que vous pouvez transférer de l'argent d'un compte bancaire à un autre. Chaque compte a une `address`, qui est l'équivalent d'un numéro de compte bancaire. c'est un identifiant unique qui désigne un compte et qui ressemble à : @@ -99,7 +99,7 @@ Nous pouvons donc l'utiliser comme un ID unique pour définir l'appartenance de ## Mappages -Dans la Leçon 1 nous avec vu les **_structures_** et les **_tableaux_**. Les **_mappages_** sont une autre façon d'organiser des données en Solidity. +Dans la Leçon 1 nous avec vu les ***structures*** et les ***tableaux***. Les ***mappages*** sont une autre façon d'organiser des données en Solidity. Voici un exemple de `mapping` : diff --git a/fr/2/5-inheritance.md b/fr/2/5-inheritance.md index e4f1db2505..03409d9b5b 100644 --- a/fr/2/5-inheritance.md +++ b/fr/2/5-inheritance.md @@ -95,7 +95,7 @@ material: Le code de notre jeu commence à être un peu long. A la place de faire un contrat vraiment long, il vaut mieux parfois séparer la logique de votre code en plusieurs contrats pour mieux l'organiser. -Une des fonctionnalités de Solidity qui rend les contrats plus facile à gérer est l'**_héritage_** : +Une des fonctionnalités de Solidity qui rend les contrats plus facile à gérer est l'***héritage*** : ``` contract Doge { @@ -112,7 +112,7 @@ contract BabyDoge is Doge { ``` -`BabyDoge` **_hérite_** de `Doge`. Cela veut dire que si vous compilez et déployez `BabyDoge`, il aura accès à `catchphrase()` et à `anotherCatchphrase()` (et n'importe quelle fonction publique que nous définirions dans `Doge`). +`BabyDoge` ***hérite*** de `Doge`. Cela veut dire que si vous compilez et déployez `BabyDoge`, il aura accès à `catchphrase()` et à `anotherCatchphrase()` (et n'importe quelle fonction publique que nous définirions dans `Doge`). Cela peut être utiliser pour les héritages logiques (comme avec les sous-classes, un `Chat` est un `Animal`). Mais cela peut aussi simplement être utilisé pour organiser votre code en groupant les logiques similaires en différentes classes. diff --git a/fr/2/7-storage.md b/fr/2/7-storage.md index 07a039b9c1..416ee9cb4c 100644 --- a/fr/2/7-storage.md +++ b/fr/2/7-storage.md @@ -71,11 +71,11 @@ material: En Solidity, il y a deux endroits pour stocker les variables - dans le `storage` (stockage) ou dans la `memory` (mémoire). -Le **_stockage_** est utilisé pour les variables stockées de manière permanente dans la blockchain. Les variables **_mémoires_** sont temporaires, et effacées entre les appels de fonction extérieure à votre contrat. C'est un peu comme le disque dur et la mémoire vive de votre ordinateur. +Le ***stockage*** est utilisé pour les variables stockées de manière permanente dans la blockchain. Les variables ***mémoires*** sont temporaires, et effacées entre les appels de fonction extérieure à votre contrat. C'est un peu comme le disque dur et la mémoire vive de votre ordinateur. La plupart du temps, vous n'aurez pas besoin d'utiliser ces mots clés car Solidity gère ça tout seul. les variables d'état (déclarées en dehors des fonctions) sont par défaut `storage` et écrites de manière permanente dans la blockchain, alors que les variables déclarées à l'intérieur des fonctions sont `memory` et disparaissent quand l'appel à la fonction est terminé. -Cependant, il peut arriver que vous ayez besoin d'utiliser ces mots clés, surtout quand vous utilisez des **_structures_** et des **_tableaux_** à l'intérieur de fonctions : +Cependant, il peut arriver que vous ayez besoin d'utiliser ces mots clés, surtout quand vous utilisez des ***structures*** et des ***tableaux*** à l'intérieur de fonctions : ``` contract SandwichFactory { diff --git a/fr/3/01-externaldependencies.md b/fr/3/01-externaldependencies.md index 7f508bc8bf..a6a42c57fa 100644 --- a/fr/3/01-externaldependencies.md +++ b/fr/3/01-externaldependencies.md @@ -143,7 +143,7 @@ material: Jusqu'à présent, Solidity était plutôt similaire aux autres langages comme JavaScript. Mais il y a de nombreuses différences entre les DApps Ethereum et les applications normales. -Pour commencer, une fois que vous avez déployé un contrat Ethereum, il est **_immuable_**, ce qui veut dire qu'il ne pourra plus jamais être modifié ou mis à jour. +Pour commencer, une fois que vous avez déployé un contrat Ethereum, il est ***immuable***, ce qui veut dire qu'il ne pourra plus jamais être modifié ou mis à jour. Le code que vous allez déployer initialement pour un contrat restera de manière permanente sur la blockchain. C'est pour cela que la sécurité est une préoccupation si importante en Solidity. S'il y a une faille dans le code de votre contrat, il n'y aucun moyen pour vous de le patcher plus tard. Vous devrez dire à vos utilisateurs d'utiliser une adresse de contrat différente qui a le correctif. diff --git a/fr/3/02-ownable.md b/fr/3/02-ownable.md index 4d75dc240a..adc1434757 100644 --- a/fr/3/02-ownable.md +++ b/fr/3/02-ownable.md @@ -189,7 +189,7 @@ Pour gérer une situation comme celle-là, il y a une pratique courante qui cons ## Le contrat `Ownable` d'OpenZeppelin -Ci-dessous vous trouverez le contrat `Ownable` issu de la bibliothèque Solidity d'**_OpenZeppelin_**. OpenZeppelin est une bibliothèque de smart contracts sécurisés et approuvés par la communauté que vous pouvez utiliser dans vos propres DApps. Après cette leçon, alors que vous allez attendre avec impatience la sortie de la Leçon 4, nous vous recommandons fortement d'aller voir leur site internet pour en apprendre d'avantage ! +Ci-dessous vous trouverez le contrat `Ownable` issu de la bibliothèque Solidity d'***OpenZeppelin***. OpenZeppelin est une bibliothèque de smart contracts sécurisés et approuvés par la communauté que vous pouvez utiliser dans vos propres DApps. Après cette leçon, alors que vous allez attendre avec impatience la sortie de la Leçon 4, nous vous recommandons fortement d'aller voir leur site internet pour en apprendre d'avantage ! Lisez-le contrat ci-dessous. Vous allez voir des choses que nous ne connaissons pas encore, mais ne vous inquiétez pas, nous en parlerons plus tard. @@ -234,7 +234,7 @@ contract Ownable { Quelques nouveautés que nous n'avions pas encore vues : -- Constructeurs : `function Ownable()` est un **_constructor_** (constructeur), c'est une fonction spéciale optionnelle qui a le même nom que le contrat. Elle sera exécutée seulement une fois, lorsque le contrat est créé. +- Constructeurs : `function Ownable()` est un ***constructor*** (constructeur), c'est une fonction spéciale optionnelle qui a le même nom que le contrat. Elle sera exécutée seulement une fois, lorsque le contrat est créé. - Modificateurs de fonction : `modifier onlyOwner()`. Les modificateurs sont comme des demi-fonctions qui permettent de modifier d'autres fonctions, souvent pour vérifier des conditions avant l'exécution. Dans ce cas, `onlyOwner` peut être utilisé pour limiter l'accès pour que **seulement** (only) le **propriétaire** (owner) du contrat puisse exécuter cette fonction. Nous parlerons plus en détail des modificateurs de fonction dans le prochain chapitre, et ce que cet étrange `_;` fait. - Mot-clé `indexed` : ne vous inquiétez pas pour celui là, nous n'en avons pas encore besoin. diff --git a/fr/3/04-gas.md b/fr/3/04-gas.md index b1218dd48b..eea45b2ae3 100644 --- a/fr/3/04-gas.md +++ b/fr/3/04-gas.md @@ -185,9 +185,9 @@ Nous allons voir une autre chose qui différencie Solidity des autres langages d ## Gas (gaz) - le carburant des DApps Ethereum -En Solidity, vos utilisateurs devront payer à chaque fois qu'ils exécutent une fonction de votre DApp avec une monnaie appelée **_gas_**. Les utilisateurs achètent du gas avec de l'Ether (la monnaie d'Ethereum), vos utilisateurs doivent donc dépenser de l'ETH pour exécuter des fonctions de votre DApp. +En Solidity, vos utilisateurs devront payer à chaque fois qu'ils exécutent une fonction de votre DApp avec une monnaie appelée ***gas***. Les utilisateurs achètent du gas avec de l'Ether (la monnaie d'Ethereum), vos utilisateurs doivent donc dépenser de l'ETH pour exécuter des fonctions de votre DApp. -La quantité de gas requit pour exécuter une fonction dépend de la complexité de cette fonction. Chaque opération individuelle a un **_coût en gas_** basé approximativement sur la quantité de ressources informatiques nécessaires pour effectuer l'opération (ex: écrire dans le storage est beaucoup plus cher que d'ajouter deux entiers). Le **_coût en gas_** total de votre fonction est la somme du coût de chaque opération individuelle. +La quantité de gas requit pour exécuter une fonction dépend de la complexité de cette fonction. Chaque opération individuelle a un ***coût en gas*** basé approximativement sur la quantité de ressources informatiques nécessaires pour effectuer l'opération (ex: écrire dans le storage est beaucoup plus cher que d'ajouter deux entiers). Le ***coût en gas*** total de votre fonction est la somme du coût de chaque opération individuelle. Parce qu'exécuter des fonctions coûte de l'argent réel pour les utilisateurs, l'optimisation de code est encore plus importante en Solidity que pour les autres langages de programmation. Si votre code est négligé, vos utilisateurs devront payer plus cher pour exécuter vos fonctions - et cela pourrait résulter en des millions de dollars de frais inutiles répartis sur des milliers d'utilisateurs. diff --git a/fr/4/battle-02.md b/fr/4/battle-02.md index b4d525ad36..28e2c8b4e3 100644 --- a/fr/4/battle-02.md +++ b/fr/4/battle-02.md @@ -243,7 +243,7 @@ Ensuite, cela utilisera le `keccak` pour convertir ces paramètres en un hachage ### Cette méthode est vulnérable aux attaques d'un nœud malhonnête. -En Ethereum, quand vous appelez la fonction d'un contrat, vous diffusez une **_transaction_** à un nœud ou à des nœuds du réseau. Les nœuds du réseau vont ensuite collecter plusieurs transactions, vont essayer d'être le premier à résoudre un problème mathématique qui demande un calcul intensif appelé "Proof of Work" (Preuve de Travail) ou PoW, et vont ensuite diffuser ce groupe de transactions avec leur PoW dans un **_bloc_** au reste du réseau. +En Ethereum, quand vous appelez la fonction d'un contrat, vous diffusez une ***transaction*** à un nœud ou à des nœuds du réseau. Les nœuds du réseau vont ensuite collecter plusieurs transactions, vont essayer d'être le premier à résoudre un problème mathématique qui demande un calcul intensif appelé "Proof of Work" (Preuve de Travail) ou PoW, et vont ensuite diffuser ce groupe de transactions avec leur PoW dans un ***bloc*** au reste du réseau. Quand un nœud a résolu un PoW, les autres nœuds arrêtent d'essayer de résoudre le PoW, ils vérifient que la liste des transactions de l'autre nœud soit valide, acceptent le bloc et passent à la résolution du bloc suivant. @@ -255,7 +255,7 @@ Si j'ai un nœud, je pourrais publier une transaction **seulement à mon propre ## Comment faire pour générer des nombres aléatoires de manière sûre sur Ethereum ? -Parce que tout le contenu de la blockchain est visible de tous les participants, c'est un problème difficile, et la solution est au-delà du cadre de ce tutoriel. Vous pouvez lire Cette discussion StackOverflow (en anglais) pour vous faire une idée. Une des possibilités serait d'avoir un **_oracle_** pour avoir accès à une fonction aléatoire en dehors de la blockchain Ethereum. +Parce que tout le contenu de la blockchain est visible de tous les participants, c'est un problème difficile, et la solution est au-delà du cadre de ce tutoriel. Vous pouvez lire Cette discussion StackOverflow (en anglais) pour vous faire une idée. Une des possibilités serait d'avoir un ***oracle*** pour avoir accès à une fonction aléatoire en dehors de la blockchain Ethereum. Bien sur, puisque des dizaine de milliers de nœuds Ethereum sur le réseau rivalisent pour résoudre le prochain bloc, mes chances de résoudre le prochain bloc sont vraiment faibles. Il me faudrait énormément de puissance de calcul et de temps pour réussir à l'exploiter - mais si la récompense est assez élevée (si je pouvais parier 100 000 000$ sur la fonction pile ou face), cela vaudrait la peine de l'attaquer. @@ -263,7 +263,7 @@ Même si cette fonction aléatoire N'EST PAS sécurisée sur Ethereum, en pratiq Puisque nous construisons simplement un jeu à des fin de démonstration dans ce tutoriel, et qu'il n'y a pas vraiment d'argent en jeu, nous allons accepter les compromis d'utiliser un générateur de nombre aléatoire simple à implémenter, sachant qu'il n'est pas totalement sûr. -Dans une prochaine leçon, il se peut que nous voyons comment utiliser des **_oracles_** (un moyen sécurisé de récupérer des données en dehors d'Ethereum) pour générer une fonction aléatoire depuis l'extérieur de la blockchain. +Dans une prochaine leçon, il se peut que nous voyons comment utiliser des ***oracles*** (un moyen sécurisé de récupérer des données en dehors d'Ethereum) pour générer une fonction aléatoire depuis l'extérieur de la blockchain. ## A votre tour diff --git a/fr/4/battle-08.md b/fr/4/battle-08.md index 8add487691..b30c195d89 100644 --- a/fr/4/battle-08.md +++ b/fr/4/battle-08.md @@ -247,7 +247,7 @@ Au chapitre 6 nous avons calculé un nombre aléatoire entre 0 et 100. Nous allo ## A votre tour -1. Créez une déclaration `if` qui va vérifier si `rand` est **_plus petit ou égal_** à `attackVictoryProbability`. +1. Créez une déclaration `if` qui va vérifier si `rand` est ***plus petit ou égal*** à `attackVictoryProbability`. 2. Si c'est le cas, notre zombie gagne ! Donc : diff --git a/fr/4/payable.md b/fr/4/payable.md index 97ed9434ab..77ab45296a 100644 --- a/fr/4/payable.md +++ b/fr/4/payable.md @@ -229,7 +229,7 @@ material: } --- -Nous avons, jusqu'à présent, vu plusieurs **_modificateurs de fonction_**. Il n'est pas forcément évident de se rappeler de tous, nous allons donc les revoir rapidement : +Nous avons, jusqu'à présent, vu plusieurs ***modificateurs de fonction***. Il n'est pas forcément évident de se rappeler de tous, nous allons donc les revoir rapidement : 1. Il existe des modificateurs de visibilité qui contrôlent quand et depuis où la fonction peut être appelée : `private` veut dire que la fonction ne peut être appelée que par les autres fonctions à l'intérieur du contrat; `internal` est comme `private` mais en plus, elle peut être appelée par les contrats qui héritent de celui-ci; avec `external`, la fonction ne peut être appelée que depuis l'extérieur du contrat; et enfin avec `public`, elle peut être appelée depuis n'importe où, à l'intérieur et à l'extérieur. diff --git a/fr/5/01-erc721-1.md b/fr/5/01-erc721-1.md index e28ddc0d71..995550f9f3 100644 --- a/fr/5/01-erc721-1.md +++ b/fr/5/01-erc721-1.md @@ -242,11 +242,11 @@ material: } --- -Commençons par les **_tokens_**. +Commençons par les ***tokens***. Si vous êtes dans la sphère Ethereum depuis un moment, vous avez sûrement entendu parler des tokens - en particulier des **tokens ERC20**. -un **_token_** Ethereum est un smart contract qui suit un ensemble de règles - à savoir, il implémente un ensemble de fonctions standards que tous les autres contrats de tokens partagent, comme `transfer(address _to, uint256 _value)` et `balanceOf(address _owner)`. +un ***token*** Ethereum est un smart contract qui suit un ensemble de règles - à savoir, il implémente un ensemble de fonctions standards que tous les autres contrats de tokens partagent, comme `transfer(address _to, uint256 _value)` et `balanceOf(address _owner)`. Le smart contract a habituellement un mappage interne, `mapping(address => uint256) balances`, qui permet de connaître le solde de chaque adresse. @@ -270,9 +270,9 @@ Premièrement, les zombies ne sont pas divisibles comme les monnaies - je peux v Deuxièmement, tous les zombies ne sont pas égaux. Votre zombie "**Pierre**" de niveau 2 n'est pas du tout égal à mon zombie de niveau 732 "**H4XF13LD MORRIS 💯💯😎💯💯**". (Tu peux pas test, *Pierre*). -Il existe un autre standard de token qui est beaucoup plus adapté pour les crypto-collectibles comme CryptoZombies — ce sont les **_tokens ERC721._** +Il existe un autre standard de token qui est beaucoup plus adapté pour les crypto-collectibles comme CryptoZombies — ce sont les ***tokens ERC721.*** -Les **_tokens ERC721_** **ne** sont **pas** interchangeable puisqu'ils sont supposés être uniques, et ne sont pas divisibles. Vous pouvez seulement les échanger en entier, et ils ont chacun un ID unique. C'est exactement cela que l'on veut pour rendre nos zombies échangeables. +Les ***tokens ERC721*** **ne** sont **pas** interchangeable puisqu'ils sont supposés être uniques, et ne sont pas divisibles. Vous pouvez seulement les échanger en entier, et ils ont chacun un ID unique. C'est exactement cela que l'on veut pour rendre nos zombies échangeables. > Remarque : En utilisant un standard comme ERC721, nous n'avons pas besoin d'implémenter les logiques qui définissent comment les joueurs vont échanger / vendre les zombies. Si on respecte les spécifications, quelqu'un d'autre pourrait construire une plateforme d'échange pour les actifs crypto-échangeables, et nos zombies ERC721 seraient compatibles avec cette plateforme. C'est un avantage évident d'utiliser un standard de token au lieu d'implémenter sa propre logique d'échange. diff --git a/fr/5/09-safemath-1.md b/fr/5/09-safemath-1.md index 0ccb437eec..cd3186b423 100644 --- a/fr/5/09-safemath-1.md +++ b/fr/5/09-safemath-1.md @@ -396,7 +396,7 @@ Mais nous voulons garder cette leçon simple, nous avons opté pour l'implément Nous allons voir une fonctionnalité de sécurité majeure à prendre en compte quand vous écrivez des smart contracts : Prévenir les débordements. -C'est quoi un **_débordement_** ? +C'est quoi un ***débordement*** ? Imaginez un `uint8`, qui peut seulement avoir 8 bits. Ce qui veut dire que le binaire du plus grand nombre que l'on peut stocker est `11111111` (ou en décimal, 2^8 -1 = 255). @@ -415,11 +415,11 @@ Nous n'utilisons pas de `uint8` ici, et il paraît peut probable qu'un `uint256` ### Utiliser SafeMath -Pour prévenir cela, OpenZeppelin a créé une **_bibliothèque_** appelée SafeMath qui empêche ces problèmes. +Pour prévenir cela, OpenZeppelin a créé une ***bibliothèque*** appelée SafeMath qui empêche ces problèmes. Mais d'abord, c'est quoi une bibliothèque ? -Une **_bibliothèque_** est un type de contrat spécial en Solidity. Une de leurs fonctionnalités est que cela permet de rajouter des fonctions à un type de données natif. +Une ***bibliothèque*** est un type de contrat spécial en Solidity. Une de leurs fonctionnalités est que cela permet de rajouter des fonctions à un type de données natif. Par exemple. avec la bibliothèque SafeMath, nous allons utiliser la syntaxe `using SafeMath for uint256`. La bibliothèque SafeMath a 4 fonctions — `add`, `sub`, `mul`, et `div`. Et maintenant nous pouvons utiliser ces fonctions à partir d'un `uint256` en faisant : diff --git a/fr/5/13-comments.md b/fr/5/13-comments.md index 5d6884d337..f602a67833 100644 --- a/fr/5/13-comments.md +++ b/fr/5/13-comments.md @@ -426,7 +426,7 @@ contract CryptoZombies { C'est une particulièrement bonne habitude de commenter son code pour expliquer le comportement attendu de chaque fonction de votre contrat. De cette manière, un autre développeur (ou vous, après 6 mois loin de votre projet !) peut parcourir votre code pour avoir une compréhension rapide du fonctionnement sans avoir à lire le code en détail. -Le standard dans la communauté Solidity est d'utiliser un format appelé **_natspec_**, qui ressemble à ça : +Le standard dans la communauté Solidity est d'utiliser un format appelé ***natspec***, qui ressemble à ça : ``` /// @title Un contrat pour des opérations mathématiques basiques diff --git a/fr/5/14-wrappingitup.md b/fr/5/14-wrappingitup.md index bdadc10185..7db311ca1f 100644 --- a/fr/5/14-wrappingitup.md +++ b/fr/5/14-wrappingitup.md @@ -33,6 +33,6 @@ Dans cette leçon nous avons appris : Cette leçon termine le code de notre jeu Solidity ! (Pour l'instant — nous rajouterons peut-être plus de leçons). -Dans les 2 prochaines leçons, nous allons voir comment déployer vos contrats et comment interagir avec en utilisant **_web3.js_** (afin que vous puissiez faire un front-end pour votre DApp). +Dans les 2 prochaines leçons, nous allons voir comment déployer vos contrats et comment interagir avec en utilisant ***web3.js*** (afin que vous puissiez faire un front-end pour votre DApp). Renommez un de vos zombies si vous le souhaitez, et passez au chapitre suivant pour terminer la leçon. diff --git a/fr/6/01.md b/fr/6/01.md index 9f1d27d4ab..245cd79159 100644 --- a/fr/6/01.md +++ b/fr/6/01.md @@ -365,7 +365,7 @@ material: En terminant la Leçon 5, notre DApp zombie est terminée. Maintenant, nous allons créer une page web basique où vos utilisateurs pourront interagir avec. -Pour cela, nous allons utiliser une bibliothèque JavaScript de la fondation Ethereum appelée **_Web3.js_**. +Pour cela, nous allons utiliser une bibliothèque JavaScript de la fondation Ethereum appelée ***Web3.js***. ## Qu'est-ce Web3.js ? @@ -375,7 +375,7 @@ Rappelez-vous, le réseau Ethereum est fait de nœuds, dont chacun contient une 2. La fonction que vous voulez appeler, et 3. Les paramètres que vous voulez donner à la fonction. -Les nœuds Ethereum parlent seulement un langage appelé **_JSON-RPC_**, qui n'est pas vraiment lisible par l'homme. Une requête pour indiquer à un nœud que vous voulez appeler une fonction d'un contrat ressemble à ça : +Les nœuds Ethereum parlent seulement un langage appelé ***JSON-RPC***, qui n'est pas vraiment lisible par l'homme. Une requête pour indiquer à un nœud que vous voulez appeler une fonction d'un contrat ressemble à ça : ``` // Oui... Bonne chance pour écrire toutes vos fonctions comme ça ! // Faire défiler vers la droite ==> diff --git a/fr/6/02.md b/fr/6/02.md index 0ff2d0fc9f..39d2cf4f54 100644 --- a/fr/6/02.md +++ b/fr/6/02.md @@ -385,11 +385,11 @@ material: Bien ! Maintenant que nous avons Web3.js dans notre projet, nous allons pouvoir l'initialiser et communiquer avec la blockchain. -La première chose dont nous avons besoin, c'est d'un **_fournisseur (provider) Web3_**. +La première chose dont nous avons besoin, c'est d'un ***fournisseur (provider) Web3***. -Rappelez-vous, Ethereum est fait de **_nœuds_** qui partagent une copie des mêmes données. Configurer un fournisseur Web3 indique à notre code avec **quel nœud** nous devrions communiquer pour traiter nos lectures et écritures. C'est un peu comme configurer l'URL d'un serveur web distant pour des appels API d'une application web classique. +Rappelez-vous, Ethereum est fait de ***nœuds*** qui partagent une copie des mêmes données. Configurer un fournisseur Web3 indique à notre code avec **quel nœud** nous devrions communiquer pour traiter nos lectures et écritures. C'est un peu comme configurer l'URL d'un serveur web distant pour des appels API d'une application web classique. -Vous pourriez héberger votre propre nœud Ethereum comme fournisseur. Mais il existe un service tiers qui vous facilitera la vie pour que vous n'ayez pas besoin de vous occuper de votre propre nœud Ethereum pour fournir une DApp à vos utilisateurs - **_Infura_**. +Vous pourriez héberger votre propre nœud Ethereum comme fournisseur. Mais il existe un service tiers qui vous facilitera la vie pour que vous n'ayez pas besoin de vous occuper de votre propre nœud Ethereum pour fournir une DApp à vos utilisateurs - ***Infura***. ## Infura @@ -407,7 +407,7 @@ Cependant, vu que notre DApp va avoir beaucoup d'utilisateurs - et que ces utili La cryptographie est compliquée, et à part si vous êtes un expert en sécurité et que vous savez vraiment ce que vous faîtes, ce ne sera sûrement pas une bonne idée de vouloir gérer les clés privées vous-même. -Heureusement, vous n'avez pas besoin - il existe déjà des services qui s'en occupent pour vous. Le plus connu est **_MetaMask_**. +Heureusement, vous n'avez pas besoin - il existe déjà des services qui s'en occupent pour vous. Le plus connu est ***MetaMask***. ## MetaMask diff --git a/fr/6/03.md b/fr/6/03.md index 1bc065f530..1475da94e3 100644 --- a/fr/6/03.md +++ b/fr/6/03.md @@ -863,7 +863,7 @@ material: Maintenant que nous avons initialisé Web3.js avec le fournisseur Web3 de MetaMask, nous allons configurer la communication avec notre smart contract. -Web3.js va avoir besoin de 2 choses pour pouvoir communiquer avec notre contrat : son **_adresse_** et son **_ABI_**. +Web3.js va avoir besoin de 2 choses pour pouvoir communiquer avec notre contrat : son ***adresse*** et son ***ABI***. ## Adresse du contrat @@ -876,7 +876,7 @@ Vous allez avoir besoin de copier cette adresse après le déploiement afin de p ## ABI du contrat -L'autre chose dont Web3.js a besoin pour communiquer avec votre contrat est son **_ABI_**. +L'autre chose dont Web3.js a besoin pour communiquer avec votre contrat est son ***ABI***. ABI veut dire "Application Binary Interface" (Interface Binaire d'Application). Fondamentalement, c'est une représentation des fonctions de votre contrat au format JSON qui indique à Web3.js comment formater les appels aux fonctions pour que votre contrat les comprenne. diff --git a/it/1/arrays.md b/it/1/arrays.md index 58db47b1c3..22a37e1c12 100644 --- a/it/1/arrays.md +++ b/it/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -Quando vuoi raccogliere qualcosa, puoi usare un **_array_**. Esistono due tipi di array in Solidity: array **_fissi_** ed array **_dinamici_**: +Quando vuoi raccogliere qualcosa, puoi usare un ***array***. Esistono due tipi di array in Solidity: array ***fissi*** ed array ***dinamici***: ``` // Array con una lunghezza fissa di 2 elementi: @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -Puoi anche creare una matrice di **_strutture_**. Utilizzando la struttura `Person` del capitolo precedente: +Puoi anche creare una matrice di ***strutture***. Utilizzando la struttura `Person` del capitolo precedente: ``` Person[] people; // array dinamico, possiamo continuare ad aggiungere strutture ``` @@ -59,7 +59,7 @@ Ricordi che le variabili di stato sono memorizzate in modo permanente nella bloc ## Array Pubblici -Puoi dichiarare un array come `pubblico`, Solidity creerà automaticamente un metodo **_getter_** per esso. La sintassi è: +Puoi dichiarare un array come `pubblico`, Solidity creerà automaticamente un metodo ***getter*** per esso. La sintassi è: ``` Person[] public people; @@ -71,4 +71,4 @@ Altri contratti sarebbero quindi in grado di leggere, ma non di scrivere, su que Vogliamo archiviare un esercito di zombi nella nostra app. Vorremmo poi mostrare tutti i nostri zombi ad altre app, quindi dovrà essere pubblico. -1. Crea un array pubblico di **_strutture_** `Zombie` e chiamalo `zombies`. \ No newline at end of file +1. Crea un array pubblico di ***strutture*** `Zombie` e chiamalo `zombies`. \ No newline at end of file diff --git a/it/1/datatypes.md b/it/1/datatypes.md index 3441b309bf..3dac2589fa 100644 --- a/it/1/datatypes.md +++ b/it/1/datatypes.md @@ -25,7 +25,7 @@ material: Ottimo lavoro! Ora che abbiamo una shell per il nostro contratto, impariamo come Solidity gestisce le variabili. -**_Le Variabili di Stato_** vengono memorizzate in modo permanente nella memoria dei contratti. Ciò significa che sono scritti sulla blockchain di Ethereum. Pensa a loro come a scrivere su un DB. +***Le Variabili di Stato*** vengono memorizzate in modo permanente nella memoria dei contratti. Ciò significa che sono scritti sulla blockchain di Ethereum. Pensa a loro come a scrivere su un DB. ##### Example: ``` diff --git a/it/1/events.md b/it/1/events.md index 1b40ac473c..089618f2fd 100644 --- a/it/1/events.md +++ b/it/1/events.md @@ -73,9 +73,9 @@ material: } --- -Il nostro contratto è quasi finito! Ora aggiungiamo un **_evento_**. +Il nostro contratto è quasi finito! Ora aggiungiamo un ***evento***. -**_Gli Eventi_** sono un modo per il tuo contratto di comunicare che è accaduto qualcosa sulla blockchain al front-end dell'app, che può essere in 'ascolto' per determinati eventi ed agire quando essi si verificano. +***Gli Eventi*** sono un modo per il tuo contratto di comunicare che è accaduto qualcosa sulla blockchain al front-end dell'app, che può essere in 'ascolto' per determinati eventi ed agire quando essi si verificano. Esempio: diff --git a/it/1/functions3.md b/it/1/functions3.md index ea01f77c7a..de647240ef 100644 --- a/it/1/functions3.md +++ b/it/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -In questo capitolo impareremo i **_valori di ritorno_** della funzione e i modificatori di funzione. +In questo capitolo impareremo i ***valori di ritorno*** della funzione e i modificatori di funzione. ## Valori di Ritorno @@ -73,13 +73,13 @@ In Solidity, la dichiarazione di funzione contiene il tipo del valore restituito La funzione sopra non cambia effettivamente lo stato in Solidity - ad es. non cambia alcun valore né scrive nulla. -Quindi in questo caso potremmo dichiararla come una funzione **_view_**, il che significa che stai solo visualizzando i dati senza modificarli: +Quindi in questo caso potremmo dichiararla come una funzione ***view***, il che significa che stai solo visualizzando i dati senza modificarli: ``` function sayHello() public view returns (string) { ``` -Solidity contiene anche le funzioni **_pure_**, il che significa che non stai accedendo a nessun dato nell'app. Considera quanto segue: +Solidity contiene anche le funzioni ***pure***, il che significa che non stai accedendo a nessun dato nell'app. Considera quanto segue: ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -Questa funzione non legge nemmeno dallo stato dell'app - il suo valore di ritorno dipende solo dai parametri della sua funzione. Quindi in questo caso dichiareremo la funzione come **_pure_**. +Questa funzione non legge nemmeno dallo stato dell'app - il suo valore di ritorno dipende solo dai parametri della sua funzione. Quindi in questo caso dichiareremo la funzione come ***pure***. > Nota: potrebbe essere difficile ricordare quando contrassegnare le funzioni come pure/view. Fortunatamente il compilatore Solidity è bravo ad emettere avvisi per farti sapere quando dovresti usare uno di questi modificatori. diff --git a/it/1/lessoncomplete.md b/it/1/lessoncomplete.md index 956ecc3100..ff9ad7c4cc 100644 --- a/it/1/lessoncomplete.md +++ b/it/1/lessoncomplete.md @@ -14,9 +14,9 @@ Questo è solo l'inizio. Rilasceremo una nuova lezione di CryptoZombies ogni set ### 1. Accedi per salvare i tuoi progressi -**_Sign in_** to save your progress by clicking the "Save Progress" link at the top of the page. We'll let you know as soon as we add a new lesson. -**_Accedi** per salvare i tuoi progressi facendo clic sul link "Salva Progressi" nella parte superiore della pagina. Ti faremo sapere non appena aggiungeremo una nuova lezione. +***Sign in*** to save your progress by clicking the "Save Progress" link at the top of the page. We'll let you know as soon as we add a new lesson. +***Accedi** per salvare i tuoi progressi facendo clic sul link "Salva Progressi" nella parte superiore della pagina. Ti faremo sapere non appena aggiungeremo una nuova lezione. ### 2. Condividi il tuo zombi con i tuoi amici -**_Condividi_** il tuo zombi su Twitter, blah blah, ecc. (Devi inserire immagini / collegamenti) +***Condividi*** il tuo zombi su Twitter, blah blah, ecc. (Devi inserire immagini / collegamenti) diff --git a/it/1/math.md b/it/1/math.md index 4292f32ccd..a87c94528a 100644 --- a/it/1/math.md +++ b/it/1/math.md @@ -34,7 +34,7 @@ La matematica in Solidity è piuttosto semplice. Le seguenti operazioni sono le * Divisione: `x / y` * Modulo / Resto: `x % y` _(per esempio, `13 % 5` è `3`, perchè se dividi 13 per 5, il resto è 3)_ -Solidity supporta anche un **_operatore esponenziale_** (ovvero "x alla potenza di y", x^y): +Solidity supporta anche un ***operatore esponenziale*** (ovvero "x alla potenza di y", x^y): ``` uint x = 5 ** 2; // uguale a 5^2 = 25 diff --git a/it/1/structs.md b/it/1/structs.md index ce82e4a1a3..a8970941d2 100644 --- a/it/1/structs.md +++ b/it/1/structs.md @@ -32,7 +32,7 @@ material: } --- -A volte è necessario un tipo di dati più complesso. Per questo Solidity fornisce **_structs_**: +A volte è necessario un tipo di dati più complesso. Per questo Solidity fornisce ***structs***: ``` struct Person { @@ -41,7 +41,7 @@ struct Person { } ``` -Le strutture (**_structs_**) consentono di creare tipi di dati più complicati con proprietà multiple. +Le strutture (***structs***) consentono di creare tipi di dati più complicati con proprietà multiple. > Nota che abbiamo appena introdotto un nuovo tipo `string`. Le stringhe vengono utilizzate per dati UTF-8 di lunghezza arbitraria. Es. `string greeting = "Ciao mondo!"` diff --git a/it/1/web3js.md b/it/1/web3js.md index 590373b876..74486e07be 100644 --- a/it/1/web3js.md +++ b/it/1/web3js.md @@ -12,7 +12,7 @@ material: Il nostro contratto di Solidity è completo! Ora dobbiamo scrivere un frontend JavaScript che interagisce con il contratto. -Ethereum ha una libreria JavaScript chiamata **_Web3.js_**. +Ethereum ha una libreria JavaScript chiamata ***Web3.js***. In una lezione successiva esamineremo in dettaglio come distribuire un contratto e configurare Web3.js. Ma per ora diamo un'occhiata al codice di esempio di come Web3.js interagirebbe con il nostro contratto distribuito. diff --git a/it/2/10-interactingcontracts.md b/it/2/10-interactingcontracts.md index 6f3c93e46a..828eb472e1 100644 --- a/it/2/10-interactingcontracts.md +++ b/it/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ Non preoccuparti: il nostro gioco non danneggerà effettivamente i CryptoKitties ## Interagire con altri contratti -Affinché il nostro contratto parli con un altro contratto sulla blockchain che non possediamo, per prima cosa dobbiamo definire una **_interface_**. +Affinché il nostro contratto parli con un altro contratto sulla blockchain che non possediamo, per prima cosa dobbiamo definire una ***interface***. Diamo un'occhiata ad un semplice esempio. Supponiamo che ci fosse un contratto sulla blockchain che assomigli a questo: @@ -131,7 +131,7 @@ Questo sarebbe un semplice contratto in cui chiunque potrebbe memorizzare il pro Ora diciamo che avevamo un contratto esterno che voleva leggere i dati in questo contratto usando la funzione `getNum`. -Per prima cosa dovremmo definire una **_interface_** del contratto `LuckyNumber`: +Per prima cosa dovremmo definire una ***interface*** del contratto `LuckyNumber`: ``` contract NumberInterface { diff --git a/it/2/2-mappings.md b/it/2/2-mappings.md index bd561e6c7b..3d925f1096 100644 --- a/it/2/2-mappings.md +++ b/it/2/2-mappings.md @@ -84,7 +84,7 @@ Per fare questo, avremo bisogno di 2 nuovi tipi di dati: `mapping` e `address`. ## Indirizzi -La blockchain di Ethereum è composta da **_accounts_**, puoi pensarli come dei conti bancari. Un conto ha un saldo di **_Ether_** (la valuta utilizzata sulla blockchain di Ethereum) e puoi inviare e ricevere pagamenti Ether su altri conti, proprio come il tuo conto bancario può trasferire denaro ad altri conti bancari. +La blockchain di Ethereum è composta da ***accounts***, puoi pensarli come dei conti bancari. Un conto ha un saldo di ***Ether*** (la valuta utilizzata sulla blockchain di Ethereum) e puoi inviare e ricevere pagamenti Ether su altri conti, proprio come il tuo conto bancario può trasferire denaro ad altri conti bancari. Ogni account ha un `address`, puoi pensarlo come un numero di conto bancario (IBAN). È un identificatore univoco che punta a quell'account e si presenta così: @@ -98,7 +98,7 @@ Possiamo quindi usarlo come un ID univoco per la proprietà dei nostri zombi. Qu ## Mappature -Nella lezione 1 abbiamo esaminato **_structs_** e **_arrays_**. **_Mappings_** sono un altro modo di archiviare i dati organizzati in Solidity. +Nella lezione 1 abbiamo esaminato ***structs*** e ***arrays***. ***Mappings*** sono un altro modo di archiviare i dati organizzati in Solidity. La definizione di una `mapping` è simile alla seguente: diff --git a/it/2/5-inheritance.md b/it/2/5-inheritance.md index d1aa0da9ec..c7006d3872 100644 --- a/it/2/5-inheritance.md +++ b/it/2/5-inheritance.md @@ -95,7 +95,7 @@ material: Il nostro codice di gioco sta diventando piuttosto lungo. Invece di creare un contratto estremamente lungo, a volte, ha senso dividere la logica del codice su più contratti per organizzare il codice. -Una caratteristica di Solidity che lo rende più gestibile è il contratto **_eredità_** (**_inheritance_**): +Una caratteristica di Solidity che lo rende più gestibile è il contratto ***eredità*** (***inheritance***): ``` contract Doge { @@ -111,7 +111,7 @@ contract BabyDoge is Doge { } ``` -`BabyDoge` **_eredita_** da `Doge`. Ciò significa che se si compila e si distribuisce `BabyDoge`, esso avrà accesso sia a `catchphrase()` che a `anotherCatchphrase()` (ed a qualsiasi altra funzione pubblica che possiamo definire su `Doge`). +`BabyDoge` ***eredita*** da `Doge`. Ciò significa che se si compila e si distribuisce `BabyDoge`, esso avrà accesso sia a `catchphrase()` che a `anotherCatchphrase()` (ed a qualsiasi altra funzione pubblica che possiamo definire su `Doge`). Questo può essere usato per l'eredità logica (come fosse una sottoclasse, un `Gatto` è un `Animale`). Ma può anche essere usato semplicemente per organizzare il tuo codice raggruppando logica simile in contratti diversi. diff --git a/it/2/7-storage.md b/it/2/7-storage.md index 7eefa84170..e662e81db2 100644 --- a/it/2/7-storage.md +++ b/it/2/7-storage.md @@ -71,11 +71,11 @@ material: In Solidity, there are two places you can store variables — in `storage` and in `memory`. -**_Storage_** si riferisce alle variabili memorizzate in modo permanente sulla blockchain. Le variabili **_Memory_** invece sono temporanee e vengono cancellate tra le chiamate di funzioni esterne al contratto. Pensalo come il disco rigido del tuo computer rispetto alla RAM. +***Storage*** si riferisce alle variabili memorizzate in modo permanente sulla blockchain. Le variabili ***Memory*** invece sono temporanee e vengono cancellate tra le chiamate di funzioni esterne al contratto. Pensalo come il disco rigido del tuo computer rispetto alla RAM. Il più delle volte non è necessario utilizzare queste parole chiave perché Solidity le gestisce per impostazione predefinita. Le variabili di stato (variabili dichiarate al di fuori delle funzioni) sono di default `storage` e scritte permanentemente nella blockchain, mentre le variabili dichiarate all'interno delle funzioni sono `memory` e scompaiono al termine della chiamata di funzione. -Tuttavia ci sono momenti in cui è necessario utilizzare queste parole chiave, in particolare quando si ha a che fare con **_structs_** e **_arrays_** all'interno delle funzioni: +Tuttavia ci sono momenti in cui è necessario utilizzare queste parole chiave, in particolare quando si ha a che fare con ***structs*** e ***arrays*** all'interno delle funzioni: ``` contract SandwichFactory { diff --git a/it/3/01-externaldependencies.md b/it/3/01-externaldependencies.md index bc7ab59120..b13755ccc3 100644 --- a/it/3/01-externaldependencies.md +++ b/it/3/01-externaldependencies.md @@ -143,7 +143,7 @@ material: Fino ad ora Solidity era molto simile ad altri linguaggi come JavaScript. Ma ci sono numerose DApp di Ethereum che in realtà sono abbastanza diverse dalle normali applicazioni. -Per cominciare, dopo aver distribuito un contratto su Ethereum, è **_ immutable_**, il che significa che non può mai essere modificato o aggiornato di nuovo. +Per cominciare, dopo aver distribuito un contratto su Ethereum, è *** immutable***, il che significa che non può mai essere modificato o aggiornato di nuovo. Il codice iniziale che distribuisci ad un contratto rimarrà lì, in modo permanente, sulla blockchain. Questo è uno dei motivi per cui la sicurezza è una preoccupazione così grande in Solidity. Se c'è un difetto nel codice del contratto non c'è modo di correggerlo in seguito. Dovresti dire ai tuoi utenti di iniziare ad utilizzare un indirizzo di contratto intelligente diverso contenente la correzione. diff --git a/it/3/02-ownable.md b/it/3/02-ownable.md index 46ff5cfdef..1d37c29a4a 100644 --- a/it/3/02-ownable.md +++ b/it/3/02-ownable.md @@ -223,7 +223,7 @@ Per gestire casi come questo, c'è una pratica comune come quella di rendere i c ## Contratti `di proprietà` OpenZeppelin -Di seguito è riportato il contratto `Ownable` tratto dalla libreria di Solidity **_OpenZeppelin_**. OpenZeppelin è una libreria di contratti intelligenti sicuri e controllati dalla community che è possibile utilizzare nelle proprie DApp. Dopo questa lezione ti consigliamo vivamente di visitare il loro sito per migliorare il tuo apprendimento! +Di seguito è riportato il contratto `Ownable` tratto dalla libreria di Solidity ***OpenZeppelin***. OpenZeppelin è una libreria di contratti intelligenti sicuri e controllati dalla community che è possibile utilizzare nelle proprie DApp. Dopo questa lezione ti consigliamo vivamente di visitare il loro sito per migliorare il tuo apprendimento! Dai un'occhiata al contratto di seguito. Vedrai alcune cose che non abbiamo ancora imparato ma non preoccuparti, ne riparleremo in seguito. @@ -303,7 +303,7 @@ contract Ownable { Ci sono alcune cose nuove che non abbiamo mai visto prima: -- Costruttori: `constructor()` è un **_costruttore_**, che è una funzione speciale opzionale. Verrà eseguito solo una volta, quando il contratto viene creato per la prima volta. +- Costruttori: `constructor()` è un ***costruttore***, che è una funzione speciale opzionale. Verrà eseguito solo una volta, quando il contratto viene creato per la prima volta. - Modificatori di funzioni: `modifier onlyOwner()`. I modificatori sono una specie di mezze funzioni che vengono utilizzate per modificare altre funzioni, in genere per verificare alcuni requisiti prima dell'esecuzione. In questo caso, `onlyOwner` può essere usato per limitare l'accesso, quindi **solo** il **proprietario** del contratto può eseguire questa funzione. Parleremo di più sui modificatori di funzione nel prossimo capitolo e su cosa faccia quello strano `_;`. - parola chiave `indexed`: non preoccuparti di questo, non ne abbiamo ancora bisogno. diff --git a/it/3/04-gas.md b/it/3/04-gas.md index 8cbb3d7c59..936be5e397 100644 --- a/it/3/04-gas.md +++ b/it/3/04-gas.md @@ -221,9 +221,9 @@ Diamo un'occhiata ad un altro modo per cui Solidity è molto diversa dagli altri ## Gas - il carburante Ethereum che funziona con le DApps -In Solidity i tuoi utenti devono pagare ogni volta che eseguono una funzione sulla DApp usando una valuta chiamata **_gas_**. Gli utenti acquistano gas con Ether (la valuta su Ethereum), quindi i tuoi utenti devono spendere ETH per eseguire le funzioni sulla tua DApp. +In Solidity i tuoi utenti devono pagare ogni volta che eseguono una funzione sulla DApp usando una valuta chiamata ***gas***. Gli utenti acquistano gas con Ether (la valuta su Ethereum), quindi i tuoi utenti devono spendere ETH per eseguire le funzioni sulla tua DApp. -La quantità di gas necessaria per eseguire una funzione dipende dalla complessità della logica di tale funzione. Ogni singola operazione ha un **_costo del gas_** basato approssimativamente sulla quantità di risorse di elaborazione necessarie per eseguire tale operazione (ad es. La scrittura in memoria è molto più costosa dell'aggiunta di due numeri interi). Il **_costo del gas_** totale della tua funzione è la somma dei costi del gas di tutte le sue singole operazioni. +La quantità di gas necessaria per eseguire una funzione dipende dalla complessità della logica di tale funzione. Ogni singola operazione ha un ***costo del gas*** basato approssimativamente sulla quantità di risorse di elaborazione necessarie per eseguire tale operazione (ad es. La scrittura in memoria è molto più costosa dell'aggiunta di due numeri interi). Il ***costo del gas*** totale della tua funzione è la somma dei costi del gas di tutte le sue singole operazioni. Poiché l'esecuzione di funzioni costa denaro reale per i tuoi utenti, l'ottimizzazione del codice è molto più importante in Ethereum che in altri linguaggi di programmazione. Se il tuo codice è pessimo, i tuoi utenti dovranno pagare di più per eseguire le tue funzioni — e questo potrebbe aggiungere fino a milioni di dollari in commissioni non necessarie tra le migliaia di utenti. diff --git a/it/4/battle-02.md b/it/4/battle-02.md index 1210257dbc..cc32a937d3 100644 --- a/it/4/battle-02.md +++ b/it/4/battle-02.md @@ -295,7 +295,7 @@ Se ho un nodo, potrei pubblicare una transazione **solo sul mio nodo** e non con ## Quindi come possiamo generare numeri casuali in modo sicuro in Ethereum? -Poiché l'intero contenuto della blockchain è visibile a tutti i partecipanti, questo è un problema difficile e la sua soluzione va oltre lo scopo di questo tutorial. Puoi leggere questo thread StackOverflow per alcune idee. Un'idea sarebbe quella di utilizzare **_oracle_** per accedere ad una funzione di numero casuale dall'esterno della blockchain di Ethereum. +Poiché l'intero contenuto della blockchain è visibile a tutti i partecipanti, questo è un problema difficile e la sua soluzione va oltre lo scopo di questo tutorial. Puoi leggere questo thread StackOverflow per alcune idee. Un'idea sarebbe quella di utilizzare ***oracle*** per accedere ad una funzione di numero casuale dall'esterno della blockchain di Ethereum. Naturalmente, poiché decine di migliaia di nodi Ethereum sulla rete sono in competizione per risolvere il blocco successivo, le mie probabilità di risolvere il blocco successivo sono davvero basse. Ci vorrebbe molto tempo e risorse informatiche per sfruttare questo profitto - ma se la ricompensa è abbastanza alta (come se potessi scommettere $100.000.000 sulla funzione di lancio della moneta), varrebbe la pena attaccare. @@ -303,7 +303,7 @@ Quindi, sebbene questa generazione di numeri casuali NON sia sicura su Ethereum, Poiché in questo tutorial stiamo solo costruendo un semplice gioco a scopo dimostrativo e non ci sono soldi veri sulla linea, accetteremo i compromessi dell'utilizzo di un generatore di numeri casuali che è semplice da implementare, sapendo però che non è totalmente sicuro. -Nella prossima lezione potremo vedere come usare **_oracles_** (un modo sicuro per recuperare i dati al di fuori di Ethereum) per generare una funzione casuale dall'esterno della blockchain. +Nella prossima lezione potremo vedere come usare ***oracles*** (un modo sicuro per recuperare i dati al di fuori di Ethereum) per generare una funzione casuale dall'esterno della blockchain. ## Facciamo una prova diff --git a/it/4/battle-08.md b/it/4/battle-08.md index 20086c8230..f8dc7f5474 100644 --- a/it/4/battle-08.md +++ b/it/4/battle-08.md @@ -290,7 +290,7 @@ Nel capitolo 6 abbiamo calcolato un numero casuale da 0 a 100. Ora usiamo quel n ## Facciamo una prova -1. Crea un'istruzione `if` che controlli se `rand` è **_minore o uguale ad_** `attackVictoryProbability`. +1. Crea un'istruzione `if` che controlli se `rand` è ***minore o uguale ad*** `attackVictoryProbability`. 2. Se questa condizione è vera, il nostro zombi vince! Così: diff --git a/it/4/payable.md b/it/4/payable.md index a3583ce8e4..a63ef96f2e 100644 --- a/it/4/payable.md +++ b/it/4/payable.md @@ -263,7 +263,7 @@ material: } --- -Fino ad ora abbiamo nascosto alcune **_funzioni di modifica_**. Può essere difficile ricordare tutto, quindi passiamo a una breve recensione: +Fino ad ora abbiamo nascosto alcune ***funzioni di modifica***. Può essere difficile ricordare tutto, quindi passiamo a una breve recensione: 1. Abbiamo modificatori di visibilità che controllano da dove e quando la funzione può essere chiamata: `private` significa che è richiamabile solo da altre funzioni all'interno del contratto; `internal` è come `private` ma può anche essere chiamata da contratti che ereditano; `external` può essere chiamata solo al di fuori del contratto; ed infine `public` può essere chiamata ovunque, sia internamente che esternamente. diff --git a/it/5/01-erc721-1.md b/it/5/01-erc721-1.md index 748239ef64..806be15d5e 100644 --- a/it/5/01-erc721-1.md +++ b/it/5/01-erc721-1.md @@ -282,12 +282,12 @@ material: } --- -Parliamo di **_tokens_**. +Parliamo di ***tokens***. -Se sei stato nello spazio di Ethereum per un certo periodo di tempo, probabilmente hai sentito persone parlare di token, in particolare **_token ERC20_**. +Se sei stato nello spazio di Ethereum per un certo periodo di tempo, probabilmente hai sentito persone parlare di token, in particolare ***token ERC20***. -A **_token_** on Ethereum is basically just a smart contract that follows some common rules — namely it implements a standard set of functions that all other token contracts share, such as `transferFrom(address _from, address _to, uint256 _tokenId)` and `balanceOf(address _owner)`. -Un **_token_** su Ethereum è fondamentalmente solo un contratto intelligente che segue alcune regole comuni — ovvero implementa un insieme standard di funzioni condivise da tutti gli altri contratti di token, come `transferFrom(address _from, address _to, uint256 _tokenId)` e `balanceOf(address _owner)`. +A ***token*** on Ethereum is basically just a smart contract that follows some common rules — namely it implements a standard set of functions that all other token contracts share, such as `transferFrom(address _from, address _to, uint256 _tokenId)` and `balanceOf(address _owner)`. +Un ***token*** su Ethereum è fondamentalmente solo un contratto intelligente che segue alcune regole comuni — ovvero implementa un insieme standard di funzioni condivise da tutti gli altri contratti di token, come `transferFrom(address _from, address _to, uint256 _tokenId)` e `balanceOf(address _owner)`. Internamente il contratto intelligente di solito ha una mappatura, `mapping(address => uint256) balances`, che tiene traccia di quanto saldo ha ciascun indirizzo. @@ -311,9 +311,9 @@ Prima di tutto gli zombi non sono divisibili come le valute: posso inviarti 0,23 In secondo luogo, tutti gli zombi non sono uguali. Il tuo zombi di livello 2 "**Steve**" non è del tutto uguale al mio zombi di livello 732 "**H4XF13LD MORRIS 💯💯😎💯💯**". (Nemmeno vicino, *Steve*). -C'è un altro token standard che si adatta molto meglio ai cripto-collezionabili come CryptoZombies — e si chiama **_token ERC721._** +C'è un altro token standard che si adatta molto meglio ai cripto-collezionabili come CryptoZombies — e si chiama ***token ERC721.*** -**_I token ERC721_** sono **non** intercambiabili poiché ognuno è considerato unico e non divisibile. Puoi scambiarle solo in unità intere e ognuna ha un ID univoco. Quindi sono perfetti per rendere negoziabili i nostri zombi. +***I token ERC721*** sono **non** intercambiabili poiché ognuno è considerato unico e non divisibile. Puoi scambiarle solo in unità intere e ognuna ha un ID univoco. Quindi sono perfetti per rendere negoziabili i nostri zombi. > Nota che l'utilizzo di uno standard come ERC721 ha il vantaggio di non dover implementare la logica dell'asta o dell'impegno all'interno del nostro contratto che determina come i giocatori possono scambiare / vendere i nostri zombi. Se ci conformiamo alle specifiche, qualcun altro potrebbe costruire una piattaforma di scambio per asset ERC721 cripto-negoziabili, e i nostri zombie ERC721 sarebbero utilizzabili su quella piattaforma. Quindi ci sono chiari vantaggi nell'utilizzare uno standard token invece di implementare la propria logica di trading. diff --git a/it/5/09-safemath-1.md b/it/5/09-safemath-1.md index e5c4043c2f..89fc46fa99 100644 --- a/it/5/09-safemath-1.md +++ b/it/5/09-safemath-1.md @@ -427,7 +427,7 @@ Volevamo mantenere questa lezione gestibile, quindi siamo andati con l'implement Esamineremo una delle principali funzionalità di sicurezza di cui dovresti essere a conoscenza quando scrivi contratti intelligenti: prevenire overflow e underflow. -Che cosa è un **_overflow_**? +Che cosa è un ***overflow***? Diciamo che abbiamo un `uint8`, che può avere solo 8 bit. Ciò significa che il numero più grande che possiamo memorizzare è il binario `11111111` (o in decimale, 2^8 - 1 = 255). @@ -446,11 +446,11 @@ Anche se non stiamo usando `uint8` qui, e sembra improbabile che un `uint256` tr ### Uso di SafeMath -Per evitare questo, OpenZeppelin ha creato una **_libreria_** chiamata SafeMath che previene questi problemi. +Per evitare questo, OpenZeppelin ha creato una ***libreria*** chiamata SafeMath che previene questi problemi. Ma prima di entrare nel dettaglio... Cos'è una libreria? -Una **_libreria_** è un tipo speciale di contratto in Solidity. Una delle cose per cui è utile è che collega le sue funzioni a tipi di dati nativi. +Una ***libreria*** è un tipo speciale di contratto in Solidity. Una delle cose per cui è utile è che collega le sue funzioni a tipi di dati nativi. Ad esempio, con la libreria SafeMath, useremo la sintassi `using SafeMath for uint256`. La libreria SafeMath ha 4 funzioni: `add`, `sub`, `mul` e `div`. E ora possiamo accedere a queste funzioni da `uint256` come segue: diff --git a/it/5/13-comments.md b/it/5/13-comments.md index fa43b2d8a8..4040bd4ac2 100644 --- a/it/5/13-comments.md +++ b/it/5/13-comments.md @@ -519,7 +519,7 @@ contract CryptoZombies { In particolare è buona norma commentare il codice per spiegare il comportamento previsto di ogni funzione del contratto. In questo modo un altro sviluppatore (o tu, dopo una pausa di 6 mesi da un progetto!) potrà rapidamente scremare e capire ad alto livello cosa fa il tuo codice senza dover leggere il codice stesso. -Lo standard nella comunità di Solidity è quello di usare un formato chiamato **_natspec_**, che assomiglia a questo: +Lo standard nella comunità di Solidity è quello di usare un formato chiamato ***natspec***, che assomiglia a questo: ``` /// @title Un contratto per operazioni matematiche di base diff --git a/it/5/14-wrappingitup.md b/it/5/14-wrappingitup.md index 49ef4c73d2..5f70da51e8 100644 --- a/it/5/14-wrappingitup.md +++ b/it/5/14-wrappingitup.md @@ -33,6 +33,6 @@ In questa lezione abbiamo appreso: Questa lezione conclude il codice di Solidity del nostro gioco! (Per ora — potremmo aggiungere ancora più lezioni in futuro). -Nelle prossime 2 lezioni vedremo come distribuire i tuoi contratti ed interagire con essi usando **_web3.js_** (in modo da poter costruire un front-end per la tua DApp). +Nelle prossime 2 lezioni vedremo come distribuire i tuoi contratti ed interagire con essi usando ***web3.js*** (in modo da poter costruire un front-end per la tua DApp). Vai avanti e rinomina uno dei tuoi zombi, se lo desideri, quindi procedi al capitolo successivo per completare la lezione. diff --git a/it/6/01.md b/it/6/01.md index c892f635d1..5eb1d25d9a 100644 --- a/it/6/01.md +++ b/it/6/01.md @@ -468,7 +468,7 @@ material: Completando la lezione 5, la nostra DApp zombi è ora completa. Ora creeremo una pagina Web di base in cui i tuoi utenti possono interagire con essa. -Per fare questo useremo una libreria JavaScript della Ethereum Foundation chiamata **_Web3.js_**. +Per fare questo useremo una libreria JavaScript della Ethereum Foundation chiamata ***Web3.js***. ## Che cos'è Web3.js? @@ -478,7 +478,7 @@ Ricorda, la rete Ethereum è composta da nodi, ognuno contenente una copia della 2. La funzione che si desidera chiamare, e 3. Le variabili che si desidera passare a quella funzione. -I nodi Ethereum parlano solo una lingua chiamata **_JSON-RPC_**, che non è molto leggibile dall'uomo. Una query per dire al nodo che si desidera chiamare una funzione su un contratto è simile a questa: +I nodi Ethereum parlano solo una lingua chiamata ***JSON-RPC***, che non è molto leggibile dall'uomo. Una query per dire al nodo che si desidera chiamare una funzione su un contratto è simile a questa: ``` // Sì ... Buona fortuna a scrivere tutte le tue chiamate di funzione in questo modo! diff --git a/it/6/02.md b/it/6/02.md index 2abb68bce0..796de9d5a8 100644 --- a/it/6/02.md +++ b/it/6/02.md @@ -488,11 +488,11 @@ material: Grande! Ora che abbiamo Web3.js nel nostro progetto, inizializziamolo e parliamo con la blockchain. -La prima cosa di cui abbiamo bisogno è un **_Provider Web3_**. +La prima cosa di cui abbiamo bisogno è un ***Provider Web3***. -Ricorda, Ethereum è composto da **_nodi_** che condividono tutti una copia degli stessi dati. L'impostazione di un provider Web3 in Web3.js indica al nostro codice **con quale nodo** dovremmo parlare per gestire le nostre letture e scritture. È un po' come impostare l'URL del server Web remoto per le chiamate API in una WebApp tradizionale. +Ricorda, Ethereum è composto da ***nodi*** che condividono tutti una copia degli stessi dati. L'impostazione di un provider Web3 in Web3.js indica al nostro codice **con quale nodo** dovremmo parlare per gestire le nostre letture e scritture. È un po' come impostare l'URL del server Web remoto per le chiamate API in una WebApp tradizionale. -È possibile ospitare il proprio nodo Ethereum come provider. Tuttavia, esiste un servizio di terze parti che semplifica la vita, quindi non è necessario mantenere il proprio nodo Ethereum per fornire una DApp ai tuoi utenti — **_Infura_**. +È possibile ospitare il proprio nodo Ethereum come provider. Tuttavia, esiste un servizio di terze parti che semplifica la vita, quindi non è necessario mantenere il proprio nodo Ethereum per fornire una DApp ai tuoi utenti — ***Infura***. ## Infura @@ -510,7 +510,7 @@ Tuttavia poiché la nostra DApp verrà utilizzata da molti utenti — e questi u La crittografia è complicata, quindi se non sei un esperto di sicurezza e non sai davvero cosa stai facendo, probabilmente non è una buona idea provare a gestire le chiavi private degli utenti nel front-end della nostra app. -Ma per fortuna non è necessario — ci sono già servizi che gestiscono questo per te. Il più popolare di questi è **_Metamask_**. +Ma per fortuna non è necessario — ci sono già servizi che gestiscono questo per te. Il più popolare di questi è ***Metamask***. ## Metamask diff --git a/it/6/03.md b/it/6/03.md index 0d54ea2424..dc1ba2b32d 100644 --- a/it/6/03.md +++ b/it/6/03.md @@ -954,7 +954,7 @@ material: Ora che abbiamo inizializzato Web3.js con il provider Web3 di MetaMask, impostiamolo per comunicare con il nostro contratto intelligente. -Web3.js avrà bisogno di 2 cose per parlare del tuo contratto: il suo **_indirizzo_** ed il suo **_ABI_**. +Web3.js avrà bisogno di 2 cose per parlare del tuo contratto: il suo ***indirizzo*** ed il suo ***ABI***. ## Indirizzo del Contratto @@ -966,7 +966,7 @@ Dopo la distribuzione dovrai copiare questo indirizzo per poter comunicare con i ## Contratto ABI -Web3.js parlerà con il tuo contratto tramite la sua **_ABI_**. +Web3.js parlerà con il tuo contratto tramite la sua ***ABI***. ABI è l'acronimo di Application Binary Interface. Fondamentalmente è una rappresentazione dei metodi dei tuoi contratti in formato JSON che dice a Web3.js come formattare le chiamate alle funzioni in modo che il tuo contratto lo possa interpretare correttamente. diff --git a/jp/1/arrays.md b/jp/1/arrays.md index 36e04be3f7..8b8662beb6 100644 --- a/jp/1/arrays.md +++ b/jp/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -何かのコレクションを作りたければ、**_配列_**を利用するのだ。Solidityには2種類の配列が用意されている：**_固定長_**配列と**_可変長_**配列だ： +何かのコレクションを作りたければ、***配列***を利用するのだ。Solidityには2種類の配列が用意されている：***固定長***配列と***可変長***配列だ： ``` // 2要素の固定長の配列の場合： @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -**_構造体_**の配列も作れるぞ。前のチャプターの `Person` 構造体を例にすると： +***構造体***の配列も作れるぞ。前のチャプターの `Person` 構造体を例にすると： ``` Person[] people; // このように可変長配列で書ける。さらに追加し続けることもできるぞ。 @@ -60,7 +60,7 @@ Person[] people; // このように可変長配列で書ける。さらに追加 ## パブリックの配列 -配列を`public`で宣言すれば、Solidityが自動的に**_getter_**メソッドを作成するぞ。コードの書き方はこうだ： +配列を`public`で宣言すれば、Solidityが自動的に***getter***メソッドを作成するぞ。コードの書き方はこうだ： ``` Person[] public people; @@ -72,4 +72,4 @@ Person[] public people; 私は自分のアプリにゾンビの軍隊を格納したいのだ。そして格納したゾンビを他のアプリに見せてやるために、公開したい。 -1. パブリックな`Zombie`**_構造体_**の配列を作り、名前を`zombies`とせよ。 +1. パブリックな`Zombie`***構造体***の配列を作り、名前を`zombies`とせよ。 diff --git a/jp/1/datatypes.md b/jp/1/datatypes.md index 0abaa35ccc..b69027c5ac 100644 --- a/jp/1/datatypes.md +++ b/jp/1/datatypes.md @@ -25,7 +25,7 @@ material: 見事だ！コントラクトの骨組みを作りあげたから、次はSolidityが変数をどのように扱うかについて教えていくぞ。 -**_状態変数_** はコントラクト内に永遠に保管され続けるものだ。要するにイーサリアムブロックチェーン上に記載されるということだ。まぁDB（データベース）に書き込むようなものだと思って良い。 +***状態変数*** はコントラクト内に永遠に保管され続けるものだ。要するにイーサリアムブロックチェーン上に記載されるということだ。まぁDB（データベース）に書き込むようなものだと思って良い。 ##### 例: diff --git a/jp/1/events.md b/jp/1/events.md index 79d13e82e2..83df13ec8c 100644 --- a/jp/1/events.md +++ b/jp/1/events.md @@ -73,9 +73,9 @@ material: } --- -我々のコントラクトももう直ぐ完成だ！そこで、**_event_**を追加しよう。 +我々のコントラクトももう直ぐ完成だ！そこで、***event***を追加しよう。 -**_Events_** は、ブロックチェーンで何かが生じたときに、コントラクトがアプリのフロントエンドに伝えることができるものだ。しかも特定のイベントを'listening'状態にして、何かあった時にアクションを起こすこともできるのだ。 +***Events*** は、ブロックチェーンで何かが生じたときに、コントラクトがアプリのフロントエンドに伝えることができるものだ。しかも特定のイベントを'listening'状態にして、何かあった時にアクションを起こすこともできるのだ。 例： diff --git a/jp/1/functions3.md b/jp/1/functions3.md index 79aa0296d8..17cf9eed24 100644 --- a/jp/1/functions3.md +++ b/jp/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -このチャプターでは、関数の **_戻り値_**と、修飾子について教えるぞ。 +このチャプターでは、関数の ***戻り値***と、修飾子について教えるぞ。 ## 戻り値 @@ -73,13 +73,13 @@ Solidityでは関数の宣言に戻り値の型を含むから覚えておくよ 上の関数はSolidity上では何も変更されないぞ。例えば値を変更したり、何かを書き込むこともない。 -このケースでは**_view_**関数を宣言できる。これはつまりデータの読み取り専用で編集できないということだ： +このケースでは***view***関数を宣言できる。これはつまりデータの読み取り専用で編集できないということだ： ``` function sayHello() public view returns (string) { ``` -Solidityには**_pure_**関数がある。これを使うとアプリ内のデータにすらアクセスできない。次のコードを考えてみよう： +Solidityには***pure***関数がある。これを使うとアプリ内のデータにすらアクセスできない。次のコードを考えてみよう： ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -この関数はアプリから読み込むことすらできない。つまり戻り値が関数のパラメーターのみに依存することになる。この場合**_pure_**関数として宣言することができる。 +この関数はアプリから読み込むことすらできない。つまり戻り値が関数のパラメーターのみに依存することになる。この場合***pure***関数として宣言することができる。 > 注：どんなときに関数をpure/viewと修飾するか覚えるのは難しいかもしれません。幸い、Solidityのコンパイラは優秀なので、どちらの修飾子を使うべきか警告してくれます。 diff --git a/jp/1/lessoncomplete.md b/jp/1/lessoncomplete.md index bbaa078972..b3ef4b3e50 100644 --- a/jp/1/lessoncomplete.md +++ b/jp/1/lessoncomplete.md @@ -14,8 +14,8 @@ material: ### 1. サインインして進捗を保存 -**_サインイン_** すると画面上の”進捗の保存”リンクで進捗を保存できる。新しいレッスンの準備ができたら直ぐに呼ぶから、それまでおとなしく待つようにな。 +***サインイン*** すると画面上の”進捗の保存”リンクで進捗を保存できる。新しいレッスンの準備ができたら直ぐに呼ぶから、それまでおとなしく待つようにな。 ### 2. ゾンビを友達とシェアする -ツイッターでもなんでも自分のゾンビを**_シェア_** できるぞ。 (画像・リンクを挿入する必要があります。) +ツイッターでもなんでも自分のゾンビを***シェア*** できるぞ。 (画像・リンクを挿入する必要があります。) diff --git a/jp/1/math.md b/jp/1/math.md index 1829ac3050..8e9fafaf52 100644 --- a/jp/1/math.md +++ b/jp/1/math.md @@ -34,7 +34,7 @@ Solidityで使う数式は誰でもわかるような簡単なものだ。他の * 除算（割り算）: `x / y` * 剰余（余り）: `x % y` _(例えば、`13 % 5` は `3`になる。なぜかというと、13を5で割ると、余りが3だからだ.)_ -Solidityは**_指数演算子_**もサポートしている。(例 "xのy乗"、 x^y): +Solidityは***指数演算子***もサポートしている。(例 "xのy乗"、 x^y): ``` uint x = 5 ** 2; // 5^2 = 25 と同様 diff --git a/jp/1/structs.md b/jp/1/structs.md index 1f5b89d24e..df11336c4c 100644 --- a/jp/1/structs.md +++ b/jp/1/structs.md @@ -32,7 +32,7 @@ material: } --- -複雑なデータ型が必要になる場合がある。Solidityはそのために**_構造体_**を用意している: +複雑なデータ型が必要になる場合がある。Solidityはそのために***構造体***を用意している: ``` struct Person { diff --git a/jp/1/web3js.md b/jp/1/web3js.md index 8a21d63d12..87681fe465 100644 --- a/jp/1/web3js.md +++ b/jp/1/web3js.md @@ -12,7 +12,7 @@ material: これでSolidityのコントラクトが完成だ！せっかくだからコントラクトがやり取りできるようにJavaScriptでフロントエンドの作り方も教えてやろう。 -イーサリアムには**_Web3.js_**というJavaScriptライブラリがある。 +イーサリアムには***Web3.js***というJavaScriptライブラリがある。 Web3.jsの設定とかコントラクトに実装する方法とか詳しいことは後で教えてやる。今はとりあえずサンプルコードを見せるから、それをみてWeb3.jsがどういう風にコントラクトとやり取りをするのかを学ぶのだ。 diff --git a/jp/2/10-interactingcontracts.md b/jp/2/10-interactingcontracts.md index baf9de8d3b..00a0cd47b7 100644 --- a/jp/2/10-interactingcontracts.md +++ b/jp/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ CryptoZombiesの大好物はな... ## 別のコントラクトとのやりとり -ブロックチェーン上の他人のコントラクトとやりとりするには、最初に**_interface_**を定義すればいい。 +ブロックチェーン上の他人のコントラクトとやりとりするには、最初に***interface***を定義すればいい。 簡単な例を出すぞ。例としてこんなコントラクトがブロックチェーン上にあったとする。 @@ -131,7 +131,7 @@ contract LuckyNumber { では、ここで仮に我々が外部コントラクトを持っていたとして、`getNum`関数でコントラクトのデータを読みたいとする。 -その場合、まずは`LuckyNumber`コントラクトの**_interface_**を定義するのだ。 +その場合、まずは`LuckyNumber`コントラクトの***interface***を定義するのだ。 ``` contract NumberInterface { diff --git a/jp/2/2-mappings.md b/jp/2/2-mappings.md index 7f9127b281..844e122a74 100644 --- a/jp/2/2-mappings.md +++ b/jp/2/2-mappings.md @@ -84,7 +84,7 @@ material: ## アドレス -イーサリアムのブロックチェーンが銀行口座と同じように**_アカウント（口座）_**で構成されているのは知っているな。このアカウント（口座）には、**_Ether（イーサ）_**の残高が記録されていて、Ether（イーサリアムブロックチェーンで使用される通貨）を送金したり受け取ったり、別のアカウントに支払うこともできるのだ。銀行口座から送金するのと全く同じだと思っていい。 +イーサリアムのブロックチェーンが銀行口座と同じように***アカウント（口座）***で構成されているのは知っているな。このアカウント（口座）には、***Ether（イーサ）***の残高が記録されていて、Ether（イーサリアムブロックチェーンで使用される通貨）を送金したり受け取ったり、別のアカウントに支払うこともできるのだ。銀行口座から送金するのと全く同じだと思っていい。 それぞれのアカウントには`アドレス`がある。これは銀行口座番号だと思えばいい。これはアカウントのためのユニークな識別番号になっていて、次のような番号で表示されるのだ： @@ -98,7 +98,7 @@ material: ## Mappings（マッピング） -レッスン 1では、**_構造体_** と **_配列_**を教えたな。 **_Mappings（マッピング）_**は、それと同じで、データを格納するときにSolidityで使える方法の一つだ。 +レッスン 1では、***構造体*** と ***配列***を教えたな。 ***Mappings（マッピング）***は、それと同じで、データを格納するときにSolidityで使える方法の一つだ。 `mapping`は次のように定義するのだ： diff --git a/jp/2/5-inheritance.md b/jp/2/5-inheritance.md index 6895ccd5aa..acf6fe0ebb 100644 --- a/jp/2/5-inheritance.md +++ b/jp/2/5-inheritance.md @@ -95,7 +95,7 @@ material: ゲームコードがだいぶ長くなってきたな。コードはできるだけ短めにまとめたほうがいい。ロジック毎に分けて、後で見直したときにコードを理解しやすくしておきたい。 -Solidityのコントラクトの**_継承_**:はこういう場合に使える機能の一つだ。下の例で説明するぞ： +Solidityのコントラクトの***継承***:はこういう場合に使える機能の一つだ。下の例で説明するぞ： ``` contract Doge { @@ -111,7 +111,7 @@ contract BabyDoge is Doge { } ``` -`BabyDoge`は`Doge`から**_継承_**した例だ。この場合、コンパイルして`BabyDoge`を実行すれば、`catchphrase()` と `anotherCatchphrase()`の両方（それと`Doge`で定義した場合のpublic関数）にアクセスできるのだ。 +`BabyDoge`は`Doge`から***継承***した例だ。この場合、コンパイルして`BabyDoge`を実行すれば、`catchphrase()` と `anotherCatchphrase()`の両方（それと`Doge`で定義した場合のpublic関数）にアクセスできるのだ。 これは論理的な継承に利用されている（例えば`猫`が`動物`のサブクラスといった具合だ）。しかし、それだけではなく、同じようなロジックを別々のコントラクトにまとめて、コードを整理するときに便利だから覚えておくといいだろう。 diff --git a/jp/2/7-storage.md b/jp/2/7-storage.md index dccaeb4d7b..111aff29c6 100644 --- a/jp/2/7-storage.md +++ b/jp/2/7-storage.md @@ -71,11 +71,11 @@ material: さて、Solidityには変数を格納できる場所が2つ用意されている。`storage` と`memory`だ。 -**_Storage_** はブロックチェーン上に永久に格納される変数だ。それとは対照的に**_Memory_**は一時的な変数で、外部関数をコントラクトに呼び出し終えるたびに消去されるものだ。まぁ、コンピューターのハードディスクとRAMみたいなイメージでいい。 +***Storage*** はブロックチェーン上に永久に格納される変数だ。それとは対照的に***Memory***は一時的な変数で、外部関数をコントラクトに呼び出し終えるたびに消去されるものだ。まぁ、コンピューターのハードディスクとRAMみたいなイメージでいい。 ほとんどの場合にはSolidityが判定して処理するから使う必要はない。状態変数（関数外で宣言された変数のことだ）の場合はデフォルトで `storage`で、ブロックチェーン上に永久に格納される。一方、関数内で宣言された変数は`memory`として扱われて関数の呼び出しが終われば消えるように設定されている。 -そうはいっても、関数で**_structs_** や **_arrays_**を使用するときには必要になるのだ。下に例をあげるぞ： +そうはいっても、関数で***structs*** や ***arrays***を使用するときには必要になるのだ。下に例をあげるぞ： ``` contract SandwichFactory { diff --git a/jp/3/01-externaldependencies.md b/jp/3/01-externaldependencies.md index 7e3e38a5fb..8813f54c3f 100644 --- a/jp/3/01-externaldependencies.md +++ b/jp/3/01-externaldependencies.md @@ -143,7 +143,7 @@ material: 今までやってきてわかっただろうが、SolidityはJavaScriptに似ている言語だ。しかし、イーサリアムのDAppは普通のアプリケーションとはかなり違う点があるから、それを教えていくぞ。 -まず、コントラクトをイーサリアム上にデプロイすると、**_イミュータブル_**になる。つまり編集も更新もできなくなるということだ。 +まず、コントラクトをイーサリアム上にデプロイすると、***イミュータブル***になる。つまり編集も更新もできなくなるということだ。 コントラクトにデプロイした最初のコードは永久にブロックチェーン上に残ることになる。これがSolidityにとってセキュリティが極めて重要になる理由の1つだ。コントラクトに何か欠陥があっても、それをあとで修正する方法はない。その場合は、問題点を直した別のスマートコントラクトを使用してほしいと、ユーザーに伝えるしかないのだ。 diff --git a/jp/3/02-ownable.md b/jp/3/02-ownable.md index b1c7beb84e..721f3e892b 100644 --- a/jp/3/02-ownable.md +++ b/jp/3/02-ownable.md @@ -189,7 +189,7 @@ material: ## OpenZeppelinの `Ownable` コントラクト -一つ例を見せてやろう。これはSolidityのライブラリにある **_OpenZeppelin_** という`Ownable`コントラクトだ。OpenZeppelinは安全でしかもコミュニティで検証を経たスマートコントラクトだ。これをDAppで使うことができる。このレッスンの後で、OpenZeppelinのサイトをチェックしておくように。今後非常に役に立つだろう！ +一つ例を見せてやろう。これはSolidityのライブラリにある ***OpenZeppelin*** という`Ownable`コントラクトだ。OpenZeppelinは安全でしかもコミュニティで検証を経たスマートコントラクトだ。これをDAppで使うことができる。このレッスンの後で、OpenZeppelinのサイトをチェックしておくように。今後非常に役に立つだろう！ 下のコントラクトをよく読むように。まだわからないことがいくつもあるが、あとで教えるから今は気にすることはない。 @@ -233,7 +233,7 @@ contract Ownable { 新しいものがいくつかあるから、解説してやるぞ： -- コンストラクタ： `function Ownable()`は**_コンストラクタ_**だ。これは特別な関数で、コントラクトと同じ名前だ。コントラクトが最初に作成された時に、1度だけ実行されるぞ。 +- コンストラクタ： `function Ownable()`は***コンストラクタ***だ。これは特別な関数で、コントラクトと同じ名前だ。コントラクトが最初に作成された時に、1度だけ実行されるぞ。 - 関数修飾子：修飾子は半分関数のようなもので、他の関数を編集する際に使うものだ。通常は実行する前に要件をチェックするために使用するぞ。この例で言えば、`onlyOwner`は**owner(オーナー）だけ**が関数を実行できるように、制限をアクセスするために使用されているのだ。関数修飾子については次のチャプターで詳しく説明してやろう。`_;` という奇妙なものについてもな。 - `indexed` キーワード：これは無視して良い。必要ない。 diff --git a/jp/3/04-gas.md b/jp/3/04-gas.md index 73ac9e1b8b..70a86d56a0 100644 --- a/jp/3/04-gas.md +++ b/jp/3/04-gas.md @@ -185,11 +185,11 @@ Solidityが他のプログラミング言語と比べて、かなり違う部分 ## ガス — イーサリアムDAppの燃料 -Solidityでは、ユーザーが関数を使用するたびに、**_ガス_**と呼ばれる通貨を支払うことになっている。ユーザーはEther（イーサと呼ぶ。イーサリアムの通貨だ）でガスを買い、アプリの関数を実行するのだ。 +Solidityでは、ユーザーが関数を使用するたびに、***ガス***と呼ばれる通貨を支払うことになっている。ユーザーはEther（イーサと呼ぶ。イーサリアムの通貨だ）でガスを買い、アプリの関数を実行するのだ。 -関数を実行するために必要なガスの量は、関数のロジックの複雑さによるのだ。個々の操作には、その操作を実行するためにどれくらいの計算資源が必要になるのかを計算したものに基づいて、**_ガスのコスト_**が決まっている（例えば、storageへの書き込みは整数の足し算に比べてずっと高いぞ） +関数を実行するために必要なガスの量は、関数のロジックの複雑さによるのだ。個々の操作には、その操作を実行するためにどれくらいの計算資源が必要になるのかを計算したものに基づいて、***ガスのコスト***が決まっている（例えば、storageへの書き込みは整数の足し算に比べてずっと高いぞ） -各操作に必要なガスの価格の合計が、関数の **_ガスのコスト_**になる。 +各操作に必要なガスの価格の合計が、関数の ***ガスのコスト***になる。 ユーザーは実際にお金を使って関数を動かすことになるから、イーサリアムは他のプログラミング言語よりもずっとコードの最適化が重要になるのだ。お主のコードがお粗末だと、ユーザーは余分にお金を支払わなければならなくなる。結果的には数千人のユーザーの数百万ドルを無駄にすることになるのだ。 diff --git a/jp/4/battle-02.md b/jp/4/battle-02.md index 1c39a60a66..7f2f90d2b7 100644 --- a/jp/4/battle-02.md +++ b/jp/4/battle-02.md @@ -244,7 +244,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; ### この方法は、不誠実なノードの攻撃に対して脆弱である -イーサリアムでは、コントラクトの関数を呼び出す際、ネットワーク上の一つまたは複数のノードに **_トランザクション_** として送信し、ネットワーク上のノードはトランザクションの束を集め、Proof of Work (PoW、仕事の証明)として計算集約的数学の問題を一番速く解こうとする。そして彼らのProof of Work (PoW、仕事の証明)も併せたトランザクションのグループを **_ブロック_** としてネットワークの残りのノードに発行する。 +イーサリアムでは、コントラクトの関数を呼び出す際、ネットワーク上の一つまたは複数のノードに ***トランザクション*** として送信し、ネットワーク上のノードはトランザクションの束を集め、Proof of Work (PoW、仕事の証明)として計算集約的数学の問題を一番速く解こうとする。そして彼らのProof of Work (PoW、仕事の証明)も併せたトランザクションのグループを ***ブロック*** としてネットワークの残りのノードに発行する。 一度あるノードがPowを解いてしまうと、他のノードはそのPowを解くのをやめ、トランザクションリストが有効であることを確認してブロックを承認し、さらに次のブロックを解くことに取り掛かる。 @@ -256,7 +256,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; ## ではイーサリアムではどうやって安全に乱数を生成するのだろう？ -ブロックチェーンの全内容が全ての参加者に見えているため、これは難しい問題である。そしてその解決法はこのチュートリアルの範囲を超えている。 このStackOverflowのスレッド を読んでアイディアをいくつか見て見ると良いぞ。 そこに一つ、イーサリアムのブロックチェーン外部から乱数関数にアクセスするために **_oracle_** を使うアイディアがある。 +ブロックチェーンの全内容が全ての参加者に見えているため、これは難しい問題である。そしてその解決法はこのチュートリアルの範囲を超えている。 このStackOverflowのスレッド を読んでアイディアをいくつか見て見ると良いぞ。 そこに一つ、イーサリアムのブロックチェーン外部から乱数関数にアクセスするために ***oracle*** を使うアイディアがある。 もちろん、ネットワーク上の数万ものイーサリアム・ノードが次のブロックを解こうと競っているのだから、わしが次のブロックを解く勝率は極めて低い。これで利益があるようにするには、たくさんの時間と計算リソースが必要だからな。だがその報酬が十分に高ければ（コイン・トス関数に＄100,000,000賭けられたらといったことだ）、わしにとって攻撃する価値が出てくる。 @@ -264,7 +264,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; なぜならこのチュートリアルではデモ目的にシンプルなゲームを作っているだけだし、危険にさらされる実際のお金もない。完全に安全ではないと知っていても、乱数生成関数は実行が簡単だし、これを使うことのトレード・オフを受け入れていこう。 -あとのレッスンでは、**_oracles_** （イーサリアム外部からデータをプルする安全な方法だ）を使って、ブロックチェーン外部から安全な乱数を生成するのもやっていくからな。 +あとのレッスンでは、***oracles*** （イーサリアム外部からデータをプルする安全な方法だ）を使って、ブロックチェーン外部から安全な乱数を生成するのもやっていくからな。 ## さあテストだ diff --git a/jp/4/battle-08.md b/jp/4/battle-08.md index 7b48a41dd7..fc12800f9f 100644 --- a/jp/4/battle-08.md +++ b/jp/4/battle-08.md @@ -246,7 +246,7 @@ material: ## さあテストだ -1. `if`ステートメントを作成し、`rand`変数が`attackVictoryProbability`変数 **_より少ないか同等_** であるかチェックするようにせよ。 +1. `if`ステートメントを作成し、`rand`変数が`attackVictoryProbability`変数 ***より少ないか同等*** であるかチェックするようにせよ。 2. もしこの条件が真であれば、我らがゾンビの勝利だ！従って、 diff --git a/jp/4/payable.md b/jp/4/payable.md index e55a941ff7..877a8c0671 100644 --- a/jp/4/payable.md +++ b/jp/4/payable.md @@ -229,7 +229,7 @@ material: } --- -これまで我々は **_関数修飾子_** をかなりたくさん扱ってきた。だが全部覚えるのは難しいかもしれないから、素早く復習していくぞ。 +これまで我々は ***関数修飾子*** をかなりたくさん扱ってきた。だが全部覚えるのは難しいかもしれないから、素早く復習していくぞ。 1. いつどこで関数を呼び出すかをコントロールする可視性修飾子というものがある。`private`修飾子はコントラクト内の別の関数からのみ呼び出されるという意味だ。`internal`修飾子は`private`修飾子に似ているが、そのコントラクトを継承したコントラクトからも呼び出す事ができる。`external`修飾子はコントラクト外からだけ呼び出す事ができて、最後に`public`修飾子だが、これはコントラクト内部・外部どちらからでも呼び出せるぞ。 diff --git a/jp/5/01-erc721-1.md b/jp/5/01-erc721-1.md index 167242af4a..964dbf5d45 100644 --- a/jp/5/01-erc721-1.md +++ b/jp/5/01-erc721-1.md @@ -242,11 +242,11 @@ material: } --- -**_トークン_** について説明していこう。 +***トークン*** について説明していこう。 -お主がイーサリアムの界隈に足を踏み入れたことがあるなら、トークン、特に **_ERC20トークン_** が話題になってるのを恐らく聞いたことがあるだろう。 +お主がイーサリアムの界隈に足を踏み入れたことがあるなら、トークン、特に ***ERC20トークン*** が話題になってるのを恐らく聞いたことがあるだろう。 -イーサリアム上の**_トークン_** は、基本的にいくつかの共通ルールに従ったスマート・コントラクトだ。具体的に言うと、`transfer(address _to, uint256 _value)` や `balanceOf(address _owner)` といった関数のスタンダードセットを実装しているものだ。 +イーサリアム上の***トークン*** は、基本的にいくつかの共通ルールに従ったスマート・コントラクトだ。具体的に言うと、`transfer(address _to, uint256 _value)` や `balanceOf(address _owner)` といった関数のスタンダードセットを実装しているものだ。 通常スマートコントラクトは、内部に各アドレスにどれだけの残高があるかを記録する `mapping(address => uint256) balances`を持っている。 @@ -270,9 +270,9 @@ ERC20トークンは、通貨のような働きをする非常に素晴らしい 次に、全てのゾンビが同じように出来ていないということもその理由だ。例えば、お主のレベル２のゾンビ"**Steve**"が、わしのレベル732のゾンビ"**H4XF13LD MORRIS 💯💯😎💯💯**"と同じものだなんてことは全くない！(*Steve* よ、わしのゾンビとは程遠いぞ) -なのでそれとは別に、CryptoZombiesのようなクリプト収集物により適したトークン規格がある。 **_ERC721トークン_** と呼ばれるものだ。 +なのでそれとは別に、CryptoZombiesのようなクリプト収集物により適したトークン規格がある。 ***ERC721トークン*** と呼ばれるものだ。 -**_ERC721トークン_** は、それぞれがユニークであると仮定され、分割出来ないので **相互に交換可能でない** 。一つの単位ごとの取引のみ可能で、それぞれが特有のIdを持っている。だからゾンビをトレード可能にするのに完璧に適したものなのだ。 +***ERC721トークン*** は、それぞれがユニークであると仮定され、分割出来ないので **相互に交換可能でない** 。一つの単位ごとの取引のみ可能で、それぞれが特有のIdを持っている。だからゾンビをトレード可能にするのに完璧に適したものなのだ。 > 注: ERC721のような標準を使用するメリットとして、オークション及びプレイヤーがゾンビをトレード/販売するやり方を決定するエスクロー・ロジックをコントラクト内で実装する必要がなくなるという点があります。仕様に準拠すれば、他の誰かが収集可能なERC721クリプト資産の交換プラットフォームを作ることができ、私たちのERC721ゾンビはそのプラットフォームで使用できるようになります。そのため、独自の取引ロジックを展開する代わりにトークン規格を使用するのは明らかにメリットがあります。 diff --git a/jp/5/09-safemath-1.md b/jp/5/09-safemath-1.md index 53102d5150..9947842c51 100644 --- a/jp/5/09-safemath-1.md +++ b/jp/5/09-safemath-1.md @@ -397,7 +397,7 @@ ERC721の実装が完了したぞ、おめでとう！ スマート・コントラクトを書く際、気をつけなくてはならない重要なセキュリティの特徴がある。オーバーフローとアンダーフローの回避だ。 -**_オーバーフロー_** とは? +***オーバーフロー*** とは? 例として、`uint8`は８ビットのみを持つが、つまりここに格納できる最大数値はバイナリの`11111111`ということだ(またはデシマルだと 2^8 - 1 = 255となる)。 @@ -416,11 +416,11 @@ number++; ### SafeMathの使用 -これらの問題をデフォルトで回避するために、OpenZeppelinはSafeMathという **_ライブラリ_** を作成している。 +これらの問題をデフォルトで回避するために、OpenZeppelinはSafeMathという ***ライブラリ*** を作成している。 だがそのテーマに入る前に・・・ライブラリとは何なのか? -**_library_** とは、Solidityにおける特別なタイプのコントラクトだ。便利なことの一つとして、ネイティブデータ型への関数アタッチができることがある。 +***library*** とは、Solidityにおける特別なタイプのコントラクトだ。便利なことの一つとして、ネイティブデータ型への関数アタッチができることがある。 例えばSafeMathライブラリで、`using SafeMath for uint256`のシンタックスを使うとしよう。SafeMathライブラリは`add`、`sub`、`mul`さらに`div`の４つの関数を持つ。そして以下のように、`uint256`からこれらの関数にアクセス可能だ: diff --git a/jp/5/13-comments.md b/jp/5/13-comments.md index 73a4244d1e..b37338f683 100644 --- a/jp/5/13-comments.md +++ b/jp/5/13-comments.md @@ -423,7 +423,7 @@ contract CryptoZombies { 特に、コントラクト中の各関数に期待する働きをコメントして説明するのは良いことだ。こうして他の開発者（またはプロジェクトを6か月休止した後の自分！）が、コード自体を読まずに、コードの働きの概要をさっと理解することができる。 -Solidityのコミュニティでは、 **_natspec_** というフォーマットを用いることがスタンダードとなっている。こんな感じだ: +Solidityのコミュニティでは、 ***natspec*** というフォーマットを用いることがスタンダードとなっている。こんな感じだ: ``` /// @title A contract for basic math operations diff --git a/jp/5/14-wrappingitup.md b/jp/5/14-wrappingitup.md index 95ec8d7b16..6e57a56eff 100644 --- a/jp/5/14-wrappingitup.md +++ b/jp/5/14-wrappingitup.md @@ -33,6 +33,6 @@ material: このレッスンで我らがゲームのSolidityコードは終わりだ！(今のところ、将来さらにレッスンを追加するかもしれない) -今後２つのレッスンで、コントラクトのデプロイ方法と **_web3.js_** を使った対話の方法をやっていくぞ(DAppのフロントエンドも作れるからな)。 +今後２つのレッスンで、コントラクトのデプロイ方法と ***web3.js*** を使った対話の方法をやっていくぞ(DAppのフロントエンドも作れるからな)。 もし希望するならゾンビの名前を変えて、次のチャプターに進んでレッスンを終わりにしよう。 diff --git a/jp/6/01.md b/jp/6/01.md index c5df9c6dcc..d2ddf80484 100755 --- a/jp/6/01.md +++ b/jp/6/01.md @@ -366,7 +366,7 @@ material: レッスン５が終わり、我らがゾンビDAppも完成した。 今度はユーザーがDAppとやり取りできるベーシックなウェブページを作っていこう。 -その際Ethereum FoundationのJavaScriptライブラリ **_Web3.js_** を使っていく。 +その際Ethereum FoundationのJavaScriptライブラリ ***Web3.js*** を使っていく。 ## Web3.jsとは？ @@ -376,7 +376,7 @@ material: 2. 呼び出したい関数。そして、 3. その関数に渡したい変数 -イーサリアムのノードは、人間が読むことができない **_JSON-RPC_** という言語でのみ会話する。コントラクトの関数を呼び出したいとノードに伝えるクエリはこんな感じのものだ: +イーサリアムのノードは、人間が読むことができない ***JSON-RPC*** という言語でのみ会話する。コントラクトの関数を呼び出したいとノードに伝えるクエリはこんな感じのものだ: ``` // うむ...関数呼び出しは全てこうやって書くのだ、頑張れ! diff --git a/jp/6/02.md b/jp/6/02.md index 27d07d97a6..be6b91e232 100755 --- a/jp/6/02.md +++ b/jp/6/02.md @@ -385,11 +385,11 @@ material: よし! Web3.jsがプロジェクトで使えるようになったから、今度はこれを初期化してブロックチェーンにアクセスできるようにしていこう。 -まず必要なのは、 **_Web3プロバイダ_** というものだ。 +まず必要なのは、 ***Web3プロバイダ*** というものだ。 -イーサリアムは **_ノード_** で構成されていて、全ノードが同じデータのコピーをシェアしていることを覚えているだろうか。Web3.jsにおけるWeb3プロバイダの設定は、 **どのノード** に読み書きを処理させるよう働き掛けるかをコードに教えてくれる。これは従来のウェブアプリでAPIコールをするためにリモートのウェブサーバーのURLを設定するようなものだ。 +イーサリアムは ***ノード*** で構成されていて、全ノードが同じデータのコピーをシェアしていることを覚えているだろうか。Web3.jsにおけるWeb3プロバイダの設定は、 **どのノード** に読み書きを処理させるよう働き掛けるかをコードに教えてくれる。これは従来のウェブアプリでAPIコールをするためにリモートのウェブサーバーのURLを設定するようなものだ。 -自分のイーサリアム・ノードをプロバイダとして運営することも可能だが、もっと手軽なサードパーティのサービスがあるから、DAppのユーザーのために自分のイーサリアム・ノードをもつ必要はない。そのサービスとは **_Infura_** だ。 +自分のイーサリアム・ノードをプロバイダとして運営することも可能だが、もっと手軽なサードパーティのサービスがあるから、DAppのユーザーのために自分のイーサリアム・ノードをもつ必要はない。そのサービスとは ***Infura*** だ。 ## Infura @@ -407,7 +407,7 @@ var web3 = new Web3(new Web3.providers.WebsocketProvider("wss://mainnet.infura.i 暗号化の方法は複雑だから、お主がセキュリティの専門家で何を行っているかを本当にわかっているわけでもない限り、アプリのフロントエンドでユーザーの秘密鍵を自ら管理しようとするのは良い考えではない。 -だがラッキーなことに秘密鍵管理の必要はない — すでにこれを行ってくれるサービスがあるのだ。中でももっともポピュラーなサービスは **_Metamask_** だ。 +だがラッキーなことに秘密鍵管理の必要はない — すでにこれを行ってくれるサービスがあるのだ。中でももっともポピュラーなサービスは ***Metamask*** だ。 ## Metamask diff --git a/jp/6/03.md b/jp/6/03.md index 04de1b9087..cf86cbb27d 100755 --- a/jp/6/03.md +++ b/jp/6/03.md @@ -863,7 +863,7 @@ material: Web3.jsをMetamaskのWeb3プロバイダで初期化できたから、今度はスマートコントラクトにアクセスできるように設定しよう。 -Web3.jsがコントラクトにアクセスするため、必要となるものが２つある: コントラクトの **_アドレス_** と **_ABI_** だ。 +Web3.jsがコントラクトにアクセスするため、必要となるものが２つある: コントラクトの ***アドレス*** と ***ABI*** だ。 ## コントラクトアドレス @@ -875,7 +875,7 @@ Web3.jsがコントラクトにアクセスするため、必要となるもの ## コントラクトABI -Web3.jsがコントラクトにアクセスするためにさらに必要となるのは、その **_ABI_** だ。 +Web3.jsがコントラクトにアクセスするためにさらに必要となるのは、その ***ABI*** だ。 ABIとは、Application Binary Interfaceの略である。基本的にこれはコントラクトのメソッドをJSON形式で表していて、関数コールをコントラクトが理解できるようフォーマットする方法を、Web3.jsに教えてくれるものだ。 diff --git a/jp/7/02.md b/jp/7/02.md index 1d66150b9e..1aba27016a 100755 --- a/jp/7/02.md +++ b/jp/7/02.md @@ -483,7 +483,7 @@ Zombie Battlegroundカスタムゲームモードのコントラクトのシェ ### "フック" — カスタムゲームモードの核心 -全てのカスタムゲームモードにとって最初のステップとなるのは、少なくとも１つの **_フック_** を実装することだ。 +全てのカスタムゲームモードにとって最初のステップとなるのは、少なくとも１つの ***フック*** を実装することだ。 コアのゲームロジックは基本的に、コードにあればゲームのある部分においてある関数をコントラクトから探し呼び出す。 diff --git a/jp/8/04.md b/jp/8/04.md index 4a9e87ba94..6f38b14228 100644 --- a/jp/8/04.md +++ b/jp/8/04.md @@ -576,7 +576,7 @@ material: では今度は次のゲームモードをやっていこう: -_**Singleton:** 30枚のカードでデッキを組む場合に、デッキ内で１つのカード名を複数カードが共有することはできない。_ +***Singleton:** 30枚のカードでデッキを組む場合に、デッキ内で１つのカード名を複数カードが共有することはできない。_ まず初めに、`munchkin.sol`をフォーク(コピーを作成)して、`singleton.sol`という名前にしておいたからな。 diff --git a/jp/9/01-erc721x.md b/jp/9/01-erc721x.md index 76879d1d1f..9f3c40acc1 100644 --- a/jp/9/01-erc721x.md +++ b/jp/9/01-erc721x.md @@ -246,7 +246,7 @@ material: ゲーム内アイテムを「トークン」と呼ぶと、やや誤解を招く可能性がある。「トークン」という言葉は、通貨みたいに使われるものを意味しているからな。 -だがEthereumにおける **_トークン_** という言葉は、`transfer(address _to, uint256 _value)`や`balanceOf(address _owner)`といった共通の関数を全て実装したスマートコントラクト基準のことを指している。 +だがEthereumにおける ***トークン*** という言葉は、`transfer(address _to, uint256 _value)`や`balanceOf(address _owner)`といった共通の関数を全て実装したスマートコントラクト基準のことを指している。 もちろん通貨を移転したり残高を保有したりすることは可能だが、剣やカードといったゲーム内アイテムの全てを移転したり保有したりすることもできるのだ。 @@ -256,15 +256,15 @@ material: ## 様々なトークンスタンダード: ERC20とERC721 -最も一般的に知られたトークン基準は **_ERC20トークン_** だ。このトークンは通貨のような働きをするが、トレーディングカードゲームのカードみたいなデジタルアイテムを表すには、あまり便利なものではない。 +最も一般的に知られたトークン基準は ***ERC20トークン*** だ。このトークンは通貨のような働きをするが、トレーディングカードゲームのカードみたいなデジタルアイテムを表すには、あまり便利なものではない。 第一に、カードは通貨みたいに分割不可能だ — カードの５分の２を所有、なんてことはできないからな。 第二に、全てのカードが同等に作られているわけではないから、カードは互いに代替不可である。お主の **Z-Virus** カードを他人の **Ozmoziz** に交換したくはないだろう。 -そこでクリプト収集物により適した別のトークン基準があり、 **_ERC721トークン_** と呼ばれている。 +そこでクリプト収集物により適した別のトークン基準があり、 ***ERC721トークン*** と呼ばれている。 -**_ERC721トークン_** は互いに代替可能 **ではない**。各アイテムはユニークであるという前提で、それぞれに固有のIDを持っている。また分割は不可能だから、丸々１つでのみトレードすることができる。 +***ERC721トークン*** は互いに代替可能 **ではない**。各アイテムはユニークであるという前提で、それぞれに固有のIDを持っている。また分割は不可能だから、丸々１つでのみトレードすることができる。 つまりこのトークンは我らがトレーディングカードゲームを作るのにより適しているというわけだ。 diff --git a/jp/9/03-erc721x.md b/jp/9/03-erc721x.md index cbbf61dcf4..8aaa76cb84 100644 --- a/jp/9/03-erc721x.md +++ b/jp/9/03-erc721x.md @@ -265,7 +265,7 @@ material: } --- -通常のERC20やERC721トークンには、 **_トークンサプライ_** という概念がある。これはそのトークンが合計どのくらいの量存在するかというものだ。 +通常のERC20やERC721トークンには、 ***トークンサプライ*** という概念がある。これはそのトークンが合計どのくらいの量存在するかというものだ。 ERC721xのマルチファンジブルトークンでは、同じコントラクトの中に複数のトークンがあることになる — そしてそれぞれに固有の「サプライ(存在するトークンの数量)」を持つのだ。 diff --git a/jp/9/10-erc721x.md b/jp/9/10-erc721x.md index dc36ae41ef..4a2c3be860 100644 --- a/jp/9/10-erc721x.md +++ b/jp/9/10-erc721x.md @@ -357,7 +357,7 @@ material: もうほとんど出来上がっているからな！さらに１つの関数を作ってコントラクトを完成させて、その後復習をしていこう。 -最後に実装していくのは、トークンの **_バッチ生成_** である。この関数は１回の関数コールで多くのトークンを生成することを可能にする — そしてバッチ生成は、ERC721xがEthereumのガス代を節約することができる理由の１つなのだ。 +最後に実装していくのは、トークンの ***バッチ生成*** である。この関数は１回の関数コールで多くのトークンを生成することを可能にする — そしてバッチ生成は、ERC721xがEthereumのガス代を節約することができる理由の１つなのだ。 これまで書いてきたコードのおかげで、この関数はかなり簡単に実装できるからな。 diff --git a/ko/1/arrays.md b/ko/1/arrays.md index 744f243bd1..8b0a332fdb 100644 --- a/ko/1/arrays.md +++ b/ko/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -어떤 것의 모음집이 필요할 때 **_배열_**을 사용할 수 있네. 솔리디티에는 **_정적_** 배열과 **_동적_** 배열이라는 두 종류의 배열이 있지: +어떤 것의 모음집이 필요할 때 ***배열***을 사용할 수 있네. 솔리디티에는 ***정적*** 배열과 ***동적*** 배열이라는 두 종류의 배열이 있지: ``` // 2개의 원소를 담을 수 있는 고정 길이의 배열: @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -**_구조체_**의 배열을 생성할 수도 있다. 이전 챕터의 `Person` 구조체를 이용하면: +***구조체***의 배열을 생성할 수도 있다. 이전 챕터의 `Person` 구조체를 이용하면: ``` Person[] people; // 이는 동적 배열로, 원소를 계속 추가할 수 있다. @@ -60,7 +60,7 @@ Person[] people; // 이는 동적 배열로, 원소를 계속 추가할 수 있 ## Public 배열 -`public`으로 배열을 선언할 수 있지. 솔리디티는 이런 배열을 위해 **_getter_** 메소드를 자동적으로 생성하지. 구문은 다음과 같네: +`public`으로 배열을 선언할 수 있지. 솔리디티는 이런 배열을 위해 ***getter*** 메소드를 자동적으로 생성하지. 구문은 다음과 같네: ``` Person[] public people; @@ -72,4 +72,4 @@ Person[] public people; 우리 앱에 좀비 군대를 저장하고 싶네. 그리고 우리 좀비들을 다른 앱에 자랑하고 싶네. 그러니 좀비 군대 저장소를 public으로 해야 하네. -1. `Zombie` **_구조체_**의 public 배열을 생성하고 이름을 `zombies`로 한다. +1. `Zombie` ***구조체***의 public 배열을 생성하고 이름을 `zombies`로 한다. diff --git a/ko/1/datatypes.md b/ko/1/datatypes.md index 2bd27cac57..214eb854e3 100644 --- a/ko/1/datatypes.md +++ b/ko/1/datatypes.md @@ -25,7 +25,7 @@ material: 잘했네! 이제 우리 컨트랙트를 위한 뼈대를 갖추게 되었네. 이제 솔리디티에서 변수를 다루는 방법을 배워 보도록 하지. -**_상태 변수_**는 컨트랙트 저장소에 영구적으로 저장되네. 즉, 이더리움 블록체인에 기록된다는 거지. 데이터베이스에 데이터를 쓰는 것과 동일하네. +***상태 변수***는 컨트랙트 저장소에 영구적으로 저장되네. 즉, 이더리움 블록체인에 기록된다는 거지. 데이터베이스에 데이터를 쓰는 것과 동일하네. ##### 예시: diff --git a/ko/1/events.md b/ko/1/events.md index 16b54ef169..e165756bd0 100644 --- a/ko/1/events.md +++ b/ko/1/events.md @@ -73,9 +73,9 @@ material: } --- -우리의 컨트랙트가 거의 완성되어 가는군! 이제 **_이벤트_**를 추가해 보세. +우리의 컨트랙트가 거의 완성되어 가는군! 이제 ***이벤트***를 추가해 보세. -**_이벤트_**는 자네의 컨트랙트가 블록체인 상에서 자네 앱의 프론트 단에서 무언가 액션이 발생했을 때 의사소통하는 방법이지. 컨트랙트는 특정 이벤트가 일어나는지 "귀를 기울이고" 그 이벤트가 발생하면 행동을 취하지. +***이벤트***는 자네의 컨트랙트가 블록체인 상에서 자네 앱의 프론트 단에서 무언가 액션이 발생했을 때 의사소통하는 방법이지. 컨트랙트는 특정 이벤트가 일어나는지 "귀를 기울이고" 그 이벤트가 발생하면 행동을 취하지. 예시: diff --git a/ko/1/functions3.md b/ko/1/functions3.md index e8d860ce79..a7a017ddd4 100644 --- a/ko/1/functions3.md +++ b/ko/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -이번 챕터에서는 함수의 **_반환값_**과 함수 제어자에 대해서 알아보겠네. +이번 챕터에서는 함수의 ***반환값***과 함수 제어자에 대해서 알아보겠네. ## 반환값 @@ -73,13 +73,13 @@ function sayHello() public returns (string) { 위에서 살펴 본 함수 sayHello()는 솔리디티에서 상태를 변화시키지 않는다네. 즉, 어떤 값을 변경하거나 무언가를 쓰지 않지. -이 경우에는 함수를 **_view_** 함수로 선언한다네. 이는 함수가 데이터를 보기만 하고 변경하지 않는다는 뜻이지: +이 경우에는 함수를 ***view*** 함수로 선언한다네. 이는 함수가 데이터를 보기만 하고 변경하지 않는다는 뜻이지: ``` function sayHello() public view returns (string memory) { ``` -솔리디티는 **_pure_** 함수도 가지고 있는데, 이는 함수가 앱에서 어떤 데이터도 접근하지 않는 것을 의미하지. 다음을 살펴보게: +솔리디티는 ***pure*** 함수도 가지고 있는데, 이는 함수가 앱에서 어떤 데이터도 접근하지 않는 것을 의미하지. 다음을 살펴보게: ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -이 함수는 앱에서 읽는 것도 하지 않는다네, 다만 반환값이 함수에 전달된 인자값에 따라서 달라지지. 그러니 이 경우에 함수를 **_pure_**로 선언하지. +이 함수는 앱에서 읽는 것도 하지 않는다네, 다만 반환값이 함수에 전달된 인자값에 따라서 달라지지. 그러니 이 경우에 함수를 ***pure***로 선언하지. > 참고: 함수를 pure나 view로 언제 표시할지 기억하기 어려울 수 있지. 운 좋게도 솔리디티 컴파일러는 어떤 제어자를 써야 하는지 경고 메시지를 통해 잘 알려주네. diff --git a/ko/1/lessoncomplete.md b/ko/1/lessoncomplete.md index 60007cf8c2..2e140291ce 100644 --- a/ko/1/lessoncomplete.md +++ b/ko/1/lessoncomplete.md @@ -14,8 +14,8 @@ material: ### 1. 진도를 저장하려면 로그인하기 -페이지 맨 윗부분에 "진도 저장하기" 링크를 클릭하여 자네의 진도를 저장하려면 **_로그인_**하게. 우리가 새로운 레슨을 추가하면 바로 자네에게 알려 주겠네. +페이지 맨 윗부분에 "진도 저장하기" 링크를 클릭하여 자네의 진도를 저장하려면 ***로그인***하게. 우리가 새로운 레슨을 추가하면 바로 자네에게 알려 주겠네. ### 2. 자신의 좀비를 친구들과 공유하기 -트위터와 같은 SNS에 자네의 좀비를 **_공유_**해 보게. (이미지나 링크를 삽입할 필요가 있네) +트위터와 같은 SNS에 자네의 좀비를 ***공유***해 보게. (이미지나 링크를 삽입할 필요가 있네) diff --git a/ko/1/math.md b/ko/1/math.md index 333c28748b..7cca9d4053 100644 --- a/ko/1/math.md +++ b/ko/1/math.md @@ -33,7 +33,7 @@ material: - 나눗셈: `x / y` - 모듈로 / 나머지: `x % y` _(이를테면, `13 % 5`는 `3`이네. 왜냐하면 13을 5로 나누면 나머지가 3이기 때문이지)_ -솔리디티는 **_지수 연산_**도 지원하지 (즉, "x의 y승", x^y이지): +솔리디티는 ***지수 연산***도 지원하지 (즉, "x의 y승", x^y이지): ``` uint x = 5 ** 2; // 즉, 5^2 = 25 diff --git a/ko/1/structs.md b/ko/1/structs.md index e19242aa9c..a6a6c21087 100644 --- a/ko/1/structs.md +++ b/ko/1/structs.md @@ -32,7 +32,7 @@ material: } --- -자네가 좀 더 복잡한 자료형을 필요로 할 때가 가끔 있을 거네. 이를 위해 솔리디티는 **_구조체_**를 제공하지: +자네가 좀 더 복잡한 자료형을 필요로 할 때가 가끔 있을 거네. 이를 위해 솔리디티는 ***구조체***를 제공하지: ``` struct Person { diff --git a/ko/1/web3js.md b/ko/1/web3js.md index ee5011a0a1..b547413490 100644 --- a/ko/1/web3js.md +++ b/ko/1/web3js.md @@ -12,7 +12,7 @@ material: 우리의 솔리디티 컨트랙트가 완성되었네! 이제 이 컨트랙트와 상호작용하는 사용자 단의 자바스크립트 코드를 작성해야 하네. -이더리움은 **_Web3.js_**라고 하는 자바스크립트 라이브러리를 가지고 있네. +이더리움은 ***Web3.js***라고 하는 자바스크립트 라이브러리를 가지고 있네. 이후 레슨에서 컨트랙트를 구축하고 Web3.js를 셋업하는 방법을 자세히 살펴볼 걸세. 하지만 지금으로선 Web3.js가 구축된 컨트랙트와 어떤 방식으로 상호작용하는지에 대한 샘플 코드를 살펴보도록 하지. diff --git a/ko/2/10-interactingcontracts.md b/ko/2/10-interactingcontracts.md index 6ddbe575cc..a9a204dcc9 100644 --- a/ko/2/10-interactingcontracts.md +++ b/ko/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ material: ## 다른 컨트랙트와 상호작용하기 -블록체인 상에 있으면서 우리가 소유하지 않은 컨트랙트와 우리 컨트랙트가 상호작용을 하려면 우선 **_인터페이스_**를 정의해야 하네. +블록체인 상에 있으면서 우리가 소유하지 않은 컨트랙트와 우리 컨트랙트가 상호작용을 하려면 우선 ***인터페이스***를 정의해야 하네. 간단한 예시를 살펴 보도록 하지. 다음과 같은 블록체인 컨트랙트가 있다고 해 보세: @@ -131,7 +131,7 @@ contract LuckyNumber { 이제 `getNum` 함수를 이용하여 이 컨트랙트에 있는 데이터를 읽고자 하는 external 함수가 있다고 해 보세. -먼저, `LuckyNumber` 컨트랙트의 **_인터페이스_**를 정의할 필요가 있네: +먼저, `LuckyNumber` 컨트랙트의 ***인터페이스***를 정의할 필요가 있네: ``` contract NumberInterface { diff --git a/ko/2/2-mappings.md b/ko/2/2-mappings.md index cfbc6d246b..5dc8c93987 100644 --- a/ko/2/2-mappings.md +++ b/ko/2/2-mappings.md @@ -84,7 +84,7 @@ material: ## 주소 -이더리움 블록체인은 은행 계좌와 같은 **_계정들_**로 이루어져 있지. 계정은 이더리움 블록체인상의 통화인 **_이더_**의 잔액을 가지지. 자네의 은행 계좌에서 다른 계좌로 돈을 송금할 수 있듯이, 계정을 통해 다른 계정과 이더를 주고 받을 수 있지. +이더리움 블록체인은 은행 계좌와 같은 ***계정들***로 이루어져 있지. 계정은 이더리움 블록체인상의 통화인 ***이더***의 잔액을 가지지. 자네의 은행 계좌에서 다른 계좌로 돈을 송금할 수 있듯이, 계정을 통해 다른 계정과 이더를 주고 받을 수 있지. 각 계정은 은행 계좌 번호와 같은 `주소`를 가지고 있네. 주소는 특정 계정을 가리키는 고유 식별자로, 다음과 같이 표현되지: @@ -98,7 +98,7 @@ material: ## 매핑 -레슨 1에서 **_구조체_**와 **_배열_**을 살펴 봤네. **_매핑_**은 솔리디티에서 구조화된 데이터를 저장하는 또다른 방법이지. +레슨 1에서 ***구조체***와 ***배열***을 살펴 봤네. ***매핑***은 솔리디티에서 구조화된 데이터를 저장하는 또다른 방법이지. 다음과 같이 `매핑`을 정의하지: diff --git a/ko/2/5-inheritance.md b/ko/2/5-inheritance.md index 50233c1929..fa7aa42a31 100644 --- a/ko/2/5-inheritance.md +++ b/ko/2/5-inheritance.md @@ -95,7 +95,7 @@ material: 우리의 게임 코드가 꽤 길어지고 있군. 엄청나게 긴 컨트랙트 하나를 만들기 보다는 코드를 잘 정리해서 여러 컨트랙트에 코드 로직을 나누는 것이 합리적일 때가 있지. -이를 보다 관리하기 쉽도록 하는 솔리디티 기능이 바로 컨트랙트 **_상속_**이지: +이를 보다 관리하기 쉽도록 하는 솔리디티 기능이 바로 컨트랙트 ***상속***이지: ``` contract Doge { diff --git a/ko/2/7-storage.md b/ko/2/7-storage.md index ed8abccd11..9ce26d0adc 100644 --- a/ko/2/7-storage.md +++ b/ko/2/7-storage.md @@ -71,11 +71,11 @@ material: 솔리디티에는 변수를 저장할 수 있는 공간으로 `storage`와 `memory` 두 가지가 있지. -**_Storage_**는 블록체인 상에 영구적으로 저장되는 변수를 의미하지. **_Memory_**는 임시적으로 저장되는 변수로, 컨트랙트 함수에 대한 외부 호출들이 일어나는 사이에 지워지지. 두 변수는 각각 컴퓨터 하드 디스크와 RAM과 같지. +***Storage***는 블록체인 상에 영구적으로 저장되는 변수를 의미하지. ***Memory***는 임시적으로 저장되는 변수로, 컨트랙트 함수에 대한 외부 호출들이 일어나는 사이에 지워지지. 두 변수는 각각 컴퓨터 하드 디스크와 RAM과 같지. 대부분의 경우에 자네는 이런 키워드들을 이용할 필요가 없네. 왜냐면 솔리디티가 알아서 처리해 주기 때문이지. 상태 변수(함수 외부에 선언된 변수)는 초기 설정상 `storage`로 선언되어 블록체인에 영구적으로 저장되는 반면, 함수 내에 선언된 변수는 `memory`로 자동 선언되어서 함수 호출이 종료되면 사라지지. -하지만 이 키워드들을 사용해야 하는 때가 있지. 바로 함수 내의 **_구조체_**와 **_배열_**을 처리할 때지: +하지만 이 키워드들을 사용해야 하는 때가 있지. 바로 함수 내의 ***구조체***와 ***배열***을 처리할 때지: ``` contract SandwichFactory { diff --git a/ko/3/02-ownable.md b/ko/3/02-ownable.md index 1a670e5bdb..87a73ef101 100644 --- a/ko/3/02-ownable.md +++ b/ko/3/02-ownable.md @@ -189,7 +189,7 @@ material: ## OpenZeppelin의 `Ownable` 컨트랙트 -아래에 나와있는 것은 **_OpenZeppelin_** 솔리디티 라이브러리에서 가져온 `Ownable` 컨트랙트이네. OpenZeppelin은 자네의 DApp에서 사용할 수 있는, 안전하고 커뮤니티에서 검증받은 스마트 컨트랙트의 라이브러리라네. 이 레슨 이후에, 자네가 레슨 4의 출시를 고대하며 기다리는 동안, 우린 자네가 저들의 사이트를 확인하고 더 학습하기를 추천하네! +아래에 나와있는 것은 ***OpenZeppelin*** 솔리디티 라이브러리에서 가져온 `Ownable` 컨트랙트이네. OpenZeppelin은 자네의 DApp에서 사용할 수 있는, 안전하고 커뮤니티에서 검증받은 스마트 컨트랙트의 라이브러리라네. 이 레슨 이후에, 자네가 레슨 4의 출시를 고대하며 기다리는 동안, 우린 자네가 저들의 사이트를 확인하고 더 학습하기를 추천하네! 아래 컨트랙트를 한번 훑어보게. 우리가 아직 배우지 않은 것들이 몇몇 보이겠지만, 걱정하지 말게. 앞으로 그것들에 대해 차차 살펴볼 것이네. @@ -233,7 +233,7 @@ contract Ownable { 여기에 우리가 아직 본 적 없는 몇몇 새로운 요소가 있네: -- 생성자(Constructor): `function Ownable()`는 **_생성자_**이네. 컨트랙트와 동일한 이름을 가진,생략할 수 있는 특별한 함수이지. 이 함수는 컨트랙트가 생성될 때 딱 한 번만 실행된다네. +- 생성자(Constructor): `function Ownable()`는 ***생성자***이네. 컨트랙트와 동일한 이름을 가진,생략할 수 있는 특별한 함수이지. 이 함수는 컨트랙트가 생성될 때 딱 한 번만 실행된다네. - 함수 제어자(Function Modifier): `modifier onlyOwner()`. 제어자는 다른 함수들에 대한 접근을 제어하기 위해 사용되는 일종의 유사 함수라네. 보통 함수 실행 전의 요구사항 충족 여부를 확인하는 데에 사용하지. `onlyOwner`의 경우에는 접근을 제한해서 **오직** 컨트랙트의 **소유자**만 해당 함수를 실행할 수 있도록 하기 위해 사용될 수 있지. 우리는 다음 챕터에서 함수 제어자에 대해 더 살펴보고, `_;`라는 이상한 것이 뭘 하는 것인지 알아볼 것이네. - `indexed` 키워드: 이건 걱정하지 말게. 우린 아직 이게 필요하지 않아. diff --git a/ko/3/04-gas.md b/ko/3/04-gas.md index eaf8ac85a4..c2b913b6ce 100644 --- a/ko/3/04-gas.md +++ b/ko/3/04-gas.md @@ -185,9 +185,9 @@ material: ## 가스 - 이더리움 DApp이 사용하는 연료 -솔리디티에서는 사용자들이 자네가 만든 DApp의 함수를 실행할 때마다 **_가스_**라고 불리는 화폐를 지불해야 하네. 사용자는 이더(ETH, 이더리움의 화폐)를 이용해서 가스를 사기 때문에, 자네의 DApp 함수를 실행하려면 사용자들은 ETH를 소모해야만 하네. +솔리디티에서는 사용자들이 자네가 만든 DApp의 함수를 실행할 때마다 ***가스***라고 불리는 화폐를 지불해야 하네. 사용자는 이더(ETH, 이더리움의 화폐)를 이용해서 가스를 사기 때문에, 자네의 DApp 함수를 실행하려면 사용자들은 ETH를 소모해야만 하네. -함수를 실행하는 데에 얼마나 많은 가스가 필요한지는 그 함수의 로직(논리 구조)이 얼마나 복잡한지에 따라 달라지네. 각각의 연산은 소모되는 **_가스 비용(gas cost)_**이 있고, 그 연산을 수행하는 데에 소모되는 컴퓨팅 자원의 양이 이 비용을 결정하네. 예를 들어, storage에 값을 쓰는 것은 두 개의 정수를 더하는 것보다 훨씬 비용이 높네. 자네 함수의 전체 **_가스 비용_**은 그 함수를 구성하는 개별 연산들의 가스 비용을 모두 합친 것과 같네. +함수를 실행하는 데에 얼마나 많은 가스가 필요한지는 그 함수의 로직(논리 구조)이 얼마나 복잡한지에 따라 달라지네. 각각의 연산은 소모되는 ***가스 비용(gas cost)***이 있고, 그 연산을 수행하는 데에 소모되는 컴퓨팅 자원의 양이 이 비용을 결정하네. 예를 들어, storage에 값을 쓰는 것은 두 개의 정수를 더하는 것보다 훨씬 비용이 높네. 자네 함수의 전체 ***가스 비용***은 그 함수를 구성하는 개별 연산들의 가스 비용을 모두 합친 것과 같네. 함수를 실행하는 것은 자네의 사용자들에게 실제 돈을 쓰게 하기 때문에, 이더리움에서 코드 최적화는 다른 프로그래밍 언어들에 비해 훨씬 더 중요하네. 만약 자네의 코드가 엉망이라면, 사용자들은 자네의 함수를 실행하기 위해 일종의 할증료를 더 내야 할 걸세. 그리고 수천 명의 사용자가 이런 불필요한 비용을 낸다면 할증료가 수십 억 원까지 쌓일 수 있지. diff --git a/ko/4/battle-02.md b/ko/4/battle-02.md index b77a505986..7a5baf1706 100644 --- a/ko/4/battle-02.md +++ b/ko/4/battle-02.md @@ -245,7 +245,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; ### 이 메소드는 정직하지 않은 노드의 공격에 취약하네. -이더리움에서는 자네가 컨트랙트의 함수를 실행하면 **_트랜잭션(transaction)_**으로서 네트워크의 노드 하나 혹은 여러 노드에 실행을 알리게 되네. 그 후 네트워크의 노드들은 여러 개의 트랜잭션을 모으고, "작업 증명"으로 알려진 계산이 매우 복잡한 수학적 문제를 먼저 풀기 위한 시도를 하게 되네. 그리고서 해당 트랜잭션 그룹을 그들의 작업 증명(PoW)과 함께 **_블록_**으로 네트워크에 배포하게 되지. +이더리움에서는 자네가 컨트랙트의 함수를 실행하면 ***트랜잭션(transaction)***으로서 네트워크의 노드 하나 혹은 여러 노드에 실행을 알리게 되네. 그 후 네트워크의 노드들은 여러 개의 트랜잭션을 모으고, "작업 증명"으로 알려진 계산이 매우 복잡한 수학적 문제를 먼저 풀기 위한 시도를 하게 되네. 그리고서 해당 트랜잭션 그룹을 그들의 작업 증명(PoW)과 함께 ***블록***으로 네트워크에 배포하게 되지. 한 노드가 어떤 PoW를 풀면, 다른 노드들은 그 PoW를 풀려는 시도를 멈추고 해당 노드가 보낸 트랜잭션 목록이 유효한 것인지 검증하네. 유효하다면 해당 블록을 받아들이고 다음 블록을 풀기 시작하지. @@ -257,7 +257,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; ## 그럼 이더리움에서는 어떻게 난수를 안전하게 만들어낼 수 있을까? -블록체인의 전체 내용은 모든 참여자에게 공개되므로, 이건 풀기 어려운 문제이고 그 해답은 이 튜토리얼에를 벗어나네. 해결 방법들에 대해 궁금하다면 이 StackOverflow 글을 읽어보게. 하나의 방법은 이더리움 블록체인 외부의 난수 함수에 접근할 수 있도록 **_오라클_**을 사용하는 것이네. +블록체인의 전체 내용은 모든 참여자에게 공개되므로, 이건 풀기 어려운 문제이고 그 해답은 이 튜토리얼에를 벗어나네. 해결 방법들에 대해 궁금하다면 이 StackOverflow 글을 읽어보게. 하나의 방법은 이더리움 블록체인 외부의 난수 함수에 접근할 수 있도록 ***오라클***을 사용하는 것이네. 물론, 네트워크 상의 수만 개의 이더리움 노드들이 다음 블록을 풀기 위해 경쟁하고 있으니, 내가 다음 블록을 풀 확률은 매우 낮을 것이네. 위에서 말한 부당한 방법을 쓰는 것은 많은 시간과 연산 자원을 필요로 할 것이야 - 하지만 보상이 충분히 크다면(내가 천억 원을 걸 수 있다든지?), 공격할 만한 가치가 있을 것이네. @@ -265,7 +265,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; 이 튜토리얼에서는 시연 목적으로 간단한 게임을 만들고 있고 바로 돈이 되는 게 없기 때문에, 우린 구현하기 간단한 난수 생성기를 사용하는 것으로 타협할 것이네. 이게 완전히 안전하지는 않다는 걸 알긴 하지만 말이야. -향후 레슨에서는, 우린 **_oracle_**(이더리움 외부에서 데이터를 받아오는 안전한 방법 중 하나)을 사용해서 블록체인 밖에서 안전한 난수를 만드는 방법을 다룰 수도 있네. +향후 레슨에서는, 우린 ***oracle***(이더리움 외부에서 데이터를 받아오는 안전한 방법 중 하나)을 사용해서 블록체인 밖에서 안전한 난수를 만드는 방법을 다룰 수도 있네. ## 직접 해보기 diff --git a/ko/4/battle-08.md b/ko/4/battle-08.md index bf1f675cfe..db327a7a26 100644 --- a/ko/4/battle-08.md +++ b/ko/4/battle-08.md @@ -246,7 +246,7 @@ material: ## 직접 해보기 -1. `rand`가 `attackVictoryProbability`와 **_같거나 더 작은지_** 확인하는 `if` 문장을 만들게. +1. `rand`가 `attackVictoryProbability`와 ***같거나 더 작은지*** 확인하는 `if` 문장을 만들게. 2. 만약 이 조건이 참이라면, 우리 좀비가 이기게 되네! 그렇다면: diff --git a/ko/4/payable.md b/ko/4/payable.md index 5e57174904..bf49e85b23 100644 --- a/ko/4/payable.md +++ b/ko/4/payable.md @@ -229,7 +229,7 @@ material: } --- -지금까지 우린 꽤 많은 **_함수 제어자(function modifier)_**를 다뤘네. 모든 것을 다 기억하는 것은 힘들 것이니, 한번 빠르게 복습해보세. +지금까지 우린 꽤 많은 ***함수 제어자(function modifier)***를 다뤘네. 모든 것을 다 기억하는 것은 힘들 것이니, 한번 빠르게 복습해보세. 1. 우린 함수가 언제, 어디서 호출될 수 있는지 제어하는 접근 제어자(visibility modifier)를 알게 되었네: `private`은 컨트랙트 내부의 다른 함수들에서만 호출될 수 있음을 의미하지. `internal`은 `private`과 비슷하지만, 해당 컨트랙트를 상속하는 컨트랙트에서도 호출될 수 있지. `external`은 오직 컨트랙트 외부에서만 호출될 수 있네. 마지막으로 `public`은 내외부 모두에서, 어디서든 호출될 수 있네. diff --git a/ko/5/01-erc721-1.md b/ko/5/01-erc721-1.md index ba585e8290..7d54cb2327 100644 --- a/ko/5/01-erc721-1.md +++ b/ko/5/01-erc721-1.md @@ -242,11 +242,11 @@ material: } --- -**_토큰_**에 대해서 얘기해보지. +***토큰***에 대해서 얘기해보지. -자네가 이더리움 세상을 조금이라도 접한 적이 있다면, 사람들이 토큰에 대해 이야기하는 것을 들어봤을 수도 있을 것이네 - 구체적으로는 **_ERC20 토큰**에 대해서 말이네. +자네가 이더리움 세상을 조금이라도 접한 적이 있다면, 사람들이 토큰에 대해 이야기하는 것을 들어봤을 수도 있을 것이네 - 구체적으로는 ***ERC20 토큰**에 대해서 말이네. -이더리움에서 **_토큰_**은 기본적으로 그저 몇몇 공통 규약을 따르는 스마트 컨트랙트이네 — 즉 다른 모든 토큰 컨트랙트가 사용하는 표준 함수 집합을 구현하는 것이지. 예를 들면 `transfer(address _to, uint256 _value)`나 `balanceOf(address _owner)` 같은 함수들이 있네. +이더리움에서 ***토큰***은 기본적으로 그저 몇몇 공통 규약을 따르는 스마트 컨트랙트이네 — 즉 다른 모든 토큰 컨트랙트가 사용하는 표준 함수 집합을 구현하는 것이지. 예를 들면 `transfer(address _to, uint256 _value)`나 `balanceOf(address _owner)` 같은 함수들이 있네. 내부적으로 스마트 컨트랙트는 보통 `mapping(address => uint256) balances`와 같은 매핑을 가지고 있네. 각각의 주소에 잔액이 얼마나 있는지 기록하는 것이지. @@ -270,9 +270,9 @@ ERC20 토큰은 화폐처럼 사용되는 토큰으로는 정말 적절하네. 둘째로, 모든 좀비가 똑같지는 않네. 자네의 레벨2 좀비 "**Steve**"는 내 레벨732 좀비 "**H4XF13LD MORRIS 💯💯😎💯💯**"와는 완전히 다르지(*Steve*와는 비교할 수가 없지!). -여기에 크립토좀비와 같은 크립토 수집품을 위해 더 적절한 토큰 표준이 있네 - 바로 **_ERC721 토큰_**이지. +여기에 크립토좀비와 같은 크립토 수집품을 위해 더 적절한 토큰 표준이 있네 - 바로 ***ERC721 토큰***이지. -**_ERC721 토큰_**은 교체가 **불가**하네. 각각의 토큰이 유일하고 분할이 불가하기 때문이지. 자네는 이 토큰을 하나의 전체 단위로만 거래할 수 있고, 각각의 토큰은 유일한 ID를 가지고 있네. 그러니 이게 우리의 좀비를 거래할 수 있게 하기에는 아주 적절하지. +***ERC721 토큰***은 교체가 **불가**하네. 각각의 토큰이 유일하고 분할이 불가하기 때문이지. 자네는 이 토큰을 하나의 전체 단위로만 거래할 수 있고, 각각의 토큰은 유일한 ID를 가지고 있네. 그러니 이게 우리의 좀비를 거래할 수 있게 하기에는 아주 적절하지. > ERC721과 같은 표준을 사용하면 우리의 컨트랙트에서 사용자들이 우리의 좀비를 거래/판매할 수 있도록 하는 경매나 중계 로직을 우리가 직접 구현하지 않아도 된다는 이점이 있네. 우리가 스펙에 맞추기만 하면, 누군가 ERC721 자산을 거래할 수 있도록 하는 거래소 플랫폼을 만들면 우리의 ERC721 좀비들을 그 플랫폼에서 쓸 수 있게 될 것이네. 그러니 자네만의 거래 로직을 만드느라 고생하는 것보다 토큰 표준을 사용하는 것이 명확한 이점이 있는 것이지. diff --git a/ko/5/09-safemath-1.md b/ko/5/09-safemath-1.md index 7b117c8e74..6ff9765346 100644 --- a/ko/5/09-safemath-1.md +++ b/ko/5/09-safemath-1.md @@ -396,7 +396,7 @@ material: 이제 스마트 컨트랙트를 작성할 때 자네가 인지하고 있어야 할 하나의 주요한 보안 기능을 살펴볼 것이네: 오버플로우와 언더플로우를 막는 것이지. -**_오버플로우_**가 무엇인가? +***오버플로우***가 무엇인가? 우리가 8비트 데이터를 저장할 수 있는 `uint8` 하나를 가지고 있다고 해보지. 이 말인즉 우리가 저장할 수 있는 가장 큰 수는 이진수로 `11111111`(또는 십진수로 2^8 - 1 = 255)가 되겠지. @@ -415,11 +415,11 @@ number++; ### SafeMath 사용하기 -이를 막기 위해, OpenZeppelin에서 기본적으로 이런 문제를 막아주는 SafeMath라고 하는 **_라이브러리_**를 만들었네. +이를 막기 위해, OpenZeppelin에서 기본적으로 이런 문제를 막아주는 SafeMath라고 하는 ***라이브러리***를 만들었네. 이것을 살펴보기 전에 먼저... 라이브러리가 무엇인가? -**_라이브러리(Library)_**는 솔리디티에서 특별한 종류의 컨트랙트이네. 이게 유용하게 사용되는 경우 중 하나는 기본(native) 데이터 타입에 함수를 붙일 때이네. +***라이브러리(Library)***는 솔리디티에서 특별한 종류의 컨트랙트이네. 이게 유용하게 사용되는 경우 중 하나는 기본(native) 데이터 타입에 함수를 붙일 때이네. 예를 들어, SafeMath 라이브러리를 쓸 때는 `using SafeMath for uint256`이라는 구문을 사용할 것이네. SafeMath 라이브러리는 4개의 함수를 가지고 있네 - `add`, `sub`, `mul`, 그리고 `div`가 있네. 그리고 이제 우리는 `uint256`에서 다음과 같이 이 함수들에 접근할 수 있네. diff --git a/ko/5/13-comments.md b/ko/5/13-comments.md index d688043a3e..c07fdb1e16 100644 --- a/ko/5/13-comments.md +++ b/ko/5/13-comments.md @@ -423,7 +423,7 @@ contract CryptoZombies { 특히, 자네 컨트랙트의 모든 함수에서 예상되는 행동값을 자네의 코드에 주석으로 설명하는 것이 좋네. 그렇게 하면 다른 개발자들(또는 6개월 동안 프로젝트를 멈춘 후 자네 자신!)이 코드 자체를 다 읽어보지 않고 훑어보더라도 큰 맥락에서 그 코드를 이해할 수 있을 것이네. -솔리디티 커뮤니티에서 표준으로 쓰이는 형식은 **_natspec_**이라 불리네. 아래와 같이 생겼지: +솔리디티 커뮤니티에서 표준으로 쓰이는 형식은 ***natspec***이라 불리네. 아래와 같이 생겼지: ``` /// @title 기본적인 산수를 위한 컨트랙트 diff --git a/ko/5/14-wrappingitup.md b/ko/5/14-wrappingitup.md index 1f1e0ba336..ac5a6287e3 100644 --- a/ko/5/14-wrappingitup.md +++ b/ko/5/14-wrappingitup.md @@ -33,6 +33,6 @@ material: 이번 레슨에서 우리 게임의 솔리디티 코드를 완성했네! (지금으로서는 말이야 - 향후에 우리는 더 많은 레슨을 추가할 수도 있네). -다음 2개의 레슨에서는, 자네의 컨트랙트를 배포하고 **_web3.js_**를 사용하여 그 컨트랙트와 상호작용 하는 방법을 다룰 것이네(자네 DApp의 프론트엔드를 만들 수 있도록 말이야). +다음 2개의 레슨에서는, 자네의 컨트랙트를 배포하고 ***web3.js***를 사용하여 그 컨트랙트와 상호작용 하는 방법을 다룰 것이네(자네 DApp의 프론트엔드를 만들 수 있도록 말이야). 어서 자네가 원하는 대로 좀비들의 이름을 바꾸고, 이 레슨을 완료하기 위해 다음 챕터로 진행하게. diff --git a/ko/6/01.md b/ko/6/01.md index b2bc57a881..0414f87ca8 100644 --- a/ko/6/01.md +++ b/ko/6/01.md @@ -365,7 +365,7 @@ material: 레슨 5를 끝내면서, 우리의 좀비 DApp은 완성이 되었네. 이제 우리는 사용자들이 상호작용 할 수 있는 기본적인 웹 페이지를 만들 것이네. -이를 만들기 위해, 우리는 이더리움 재단에서 만든 자바스크립트 라이브러리인 **_Web3.js_**를 사용할 것이네. +이를 만들기 위해, 우리는 이더리움 재단에서 만든 자바스크립트 라이브러리인 ***Web3.js***를 사용할 것이네. ## Web3.js가 뭔가요? @@ -375,7 +375,7 @@ material: 2. 실행하고자 하는 함수, 그리고 3. 그 함수에 전달하고자 하는 변수들 -이더리움 노드들은 **_JSON-RPC_**라고 불리는 언어로만 소통할 수 있고, 이는 사람이 읽기는 불편하네. 컨트랙트의 함수를 실행하고 싶다고 질의를 보내는 것은 이와 같이 생겼네: +이더리움 노드들은 ***JSON-RPC***라고 불리는 언어로만 소통할 수 있고, 이는 사람이 읽기는 불편하네. 컨트랙트의 함수를 실행하고 싶다고 질의를 보내는 것은 이와 같이 생겼네: ``` // 그래... 이런 방법으로 모든 함수 호출을 잘 작성할 수 있길 빌겠네! diff --git a/ko/6/02.md b/ko/6/02.md index b7af26d79b..e5d11066df 100644 --- a/ko/6/02.md +++ b/ko/6/02.md @@ -385,11 +385,11 @@ material: 훌륭해! 이제 우리의 프로젝트에 Web3.js를 넣었으니, 이를 초기화하고 블록체인과 대화를 해보도록 하지. -우리가 처음 필요로 하는 것은 **_Web3 프로바이더(Provider)_**이네. +우리가 처음 필요로 하는 것은 ***Web3 프로바이더(Provider)***이네. -기억하게, 이더리움은 똑같은 데이터의 복사본을 공유하는 **_노드_**들로 구성되어 있네. Web3.js에서 Web3 프로바이더를 설정하는 것은 우리 코드에 읽기와 쓰기를 처리하려면 **어떤 노드**와 통신을 해야 하는지 설정하는 것이지. 이는 전통적인 웹 앱에서 API 호출을 위해 원격 웹 서버의 URL을 설정하는 것과 같네. +기억하게, 이더리움은 똑같은 데이터의 복사본을 공유하는 ***노드***들로 구성되어 있네. Web3.js에서 Web3 프로바이더를 설정하는 것은 우리 코드에 읽기와 쓰기를 처리하려면 **어떤 노드**와 통신을 해야 하는지 설정하는 것이지. 이는 전통적인 웹 앱에서 API 호출을 위해 원격 웹 서버의 URL을 설정하는 것과 같네. -자네는 자네만의 이더리움 노드를 프로바이더로 운영할 수도 있네. 하지만 자네가 편리하게 쓸 수 있는 제3자 서비스가 있네. 자네 DApp의 사용자들을 위해 자네만의 이더리움 노드를 운영할 필요가 없도록 하기 위해 사용할 수 있는 서비스 말이네 - **_Infura_**라는 게 있지. +자네는 자네만의 이더리움 노드를 프로바이더로 운영할 수도 있네. 하지만 자네가 편리하게 쓸 수 있는 제3자 서비스가 있네. 자네 DApp의 사용자들을 위해 자네만의 이더리움 노드를 운영할 필요가 없도록 하기 위해 사용할 수 있는 서비스 말이네 - ***Infura***라는 게 있지. ## Infura @@ -407,7 +407,7 @@ var web3 = new Web3(new Web3.providers.WebsocketProvider("wss://mainnet.infura.i 이런 암호학은 복잡하네. 그러니 자네가 보안 전문가이고 진짜로 무엇을 하고 있는지 알지 못한다면, 우리의 앱 프론트엔드에서 사용자들의 개인 키를 관리하려 하는 것은 아마 좋은 생각이 아닐 것이네. -하지만 운이 좋게도 자네는 그렇게 할 필요가 없네 - 이를 대신 처리해주는 서비스가 이미 있네. 이중 가장 유명한 것은 **_메타마스크(Metamask)_**이네. +하지만 운이 좋게도 자네는 그렇게 할 필요가 없네 - 이를 대신 처리해주는 서비스가 이미 있네. 이중 가장 유명한 것은 ***메타마스크(Metamask)***이네. ## 메타마스크(Metamask) diff --git a/ko/6/03.md b/ko/6/03.md index f87378f164..3379c212b6 100644 --- a/ko/6/03.md +++ b/ko/6/03.md @@ -862,7 +862,7 @@ material: 이제 메타마스크의 Web3 프로바이더로 Web3.js를 초기화했으니, 우리의 스마트 컨트랙트와 통신을 할 수 있도록 만들어보지. -Web3.js는 자네의 스마트 컨트랙트와 통신을 위해 2가지를 필요로 할 것이네: 컨트랙트의 **_주소_**와 **_ABI_**이지. +Web3.js는 자네의 스마트 컨트랙트와 통신을 위해 2가지를 필요로 할 것이네: 컨트랙트의 ***주소***와 ***ABI***이지. ## 컨트랙트 주소 @@ -874,7 +874,7 @@ Web3.js는 자네의 스마트 컨트랙트와 통신을 위해 2가지를 필 ## 컨트랙트 ABI -자네 컨트랙트와의 통신을 위해 Web3.js에서 필요로 하는 다른 하나는 바로 컨트랙트의 **_ABI_**이네. +자네 컨트랙트와의 통신을 위해 Web3.js에서 필요로 하는 다른 하나는 바로 컨트랙트의 ***ABI***이네. ABI는 Application Binary Interface의 줄임말이네. 기본적으로 JSON 형태로 자네 컨트랙트의 메소드를 표현하는 것이지. 자네 컨트랙트가 이해할 수 있도록 하려면 Web3.js가 어떤 형태로 함수 호출을 해야 하는지 알려주는 것이지. diff --git a/ko/7/02.md b/ko/7/02.md index 176f308888..99f838ea18 100644 --- a/ko/7/02.md +++ b/ko/7/02.md @@ -483,7 +483,7 @@ material: ### "훅(Hook)" — 모든 커스텀 게임 모드의 핵심 -모든 커스텀 게임 모드를 위한 첫 번째 단계는 바로 적어도 하나 이상의 **_훅_**을 구현하는 것이네. +모든 커스텀 게임 모드를 위한 첫 번째 단계는 바로 적어도 하나 이상의 ***훅***을 구현하는 것이네. 기본적으로, 핵심 게임 로직에서는 게임의 특정 부분에서 자네의 컨트랙트에 존재하는 특정한 함수들을 찾아 호출할 것이네. 자네의 코드에 그 함수들이 존재한다면 말이지. diff --git a/ko/8/04.md b/ko/8/04.md index 8ec18c52b2..b154e9cae8 100644 --- a/ko/8/04.md +++ b/ko/8/04.md @@ -576,7 +576,7 @@ material: 자, 이제 다음 모드로 넘어가지: -_**Singleton:** 게임 플레이를 위해 30장의 카드가 있는 자네의 덱을 구성할 때, 덱에 같은 이름을 가진 카드가 없는 모드라네._ +***Singleton:** 게임 플레이를 위해 30장의 카드가 있는 자네의 덱을 구성할 때, 덱에 같은 이름을 가진 카드가 없는 모드라네._ 먼저, `munchkin.sol`을 포크(복제본 만들기)하고 `singleton.sol`으로 이름을 바꾸었다네. diff --git a/ko/9/01-erc721x.md b/ko/9/01-erc721x.md index f0748366b5..d61dc00843 100644 --- a/ko/9/01-erc721x.md +++ b/ko/9/01-erc721x.md @@ -246,7 +246,7 @@ material: 게임 내 아이템들을 "토큰"이라 말하는 것이 조금 헷갈릴 수도 있네. "토큰"은 화폐처럼 쓰이는 무언가를 암시하기 때문이지. -하지만 이더리움에서 **_토큰_**이라는 단어는 그저 똑같은 공통 함수들을 구현하도록 하는 스마트 컨트랙트의 표준을 의미할 뿐이네. `transfer(address _to, uint256 _value)`이나 `balanceOf(address _owner)` 같은 함수들 말이지. +하지만 이더리움에서 ***토큰***이라는 단어는 그저 똑같은 공통 함수들을 구현하도록 하는 스마트 컨트랙트의 표준을 의미할 뿐이네. `transfer(address _to, uint256 _value)`이나 `balanceOf(address _owner)` 같은 함수들 말이지. 그래, 자네는 화폐를 전송하거나 화폐의 잔액을 가지고 있을 수 있네 - 하지만 어떤 게임에서 아이템을 전송하거나 아이템 인벤토리를 가질 수도 있지. 검이나 카드 아이템 같은 것들 말이네. @@ -256,15 +256,15 @@ material: ## 다른 토큰 표준들: ERC20과 ERC721 -가장 널리 알려진 토큰 표준은 **_ERC20 토큰_**이네. 이 토큰들은 화폐처럼 쓰이지. 하지만 이들은 디지털 아이템들을 표현하는 데에는 딱 적합하지는 않네. 트레이딩 카드 게임에서의 카드 같은 것들 말이지. +가장 널리 알려진 토큰 표준은 ***ERC20 토큰***이네. 이 토큰들은 화폐처럼 쓰이지. 하지만 이들은 디지털 아이템들을 표현하는 데에는 딱 적합하지는 않네. 트레이딩 카드 게임에서의 카드 같은 것들 말이지. 첫째로, 카드들은 화폐처럼 분할이 되지 않네 - 한 카드의 2/5를 소유한다거나 할 순 없지. 둘쨰로, 모든 카드가 똑같이 만들어지지 않기에, 상호 교환할 수 없네. 자네의 **Z-Virus** 카드를 내 **Ozmoziz** 카드와 교환하고 싶지는 않겠지. -그래서 크립토 수집품들에 더 잘 맞는 다른 토큰 표준이 있네. 이 표준은 **_ERC721_**이라 불리지. +그래서 크립토 수집품들에 더 잘 맞는 다른 토큰 표준이 있네. 이 표준은 ***ERC721***이라 불리지. -**_ERC721 토큰들은_** 상호 교환이 되지 **않네**. 각 아이템은 고유하게 다뤄지고, 고유 ID 값을 가지네. 또 나눠지지도 않지 - 이 토큰들은 하나의 전체 단위로만 거래를 할 수 있네. +***ERC721 토큰들은*** 상호 교환이 되지 **않네**. 각 아이템은 고유하게 다뤄지고, 고유 ID 값을 가지네. 또 나눠지지도 않지 - 이 토큰들은 하나의 전체 단위로만 거래를 할 수 있네. 그러니 이것이 우리의 트레이딩 카드 게임을 만들 때 더 잘 맞겠지. diff --git a/ko/9/03-erc721x.md b/ko/9/03-erc721x.md index 3b144f27fc..cc4dbde884 100644 --- a/ko/9/03-erc721x.md +++ b/ko/9/03-erc721x.md @@ -265,7 +265,7 @@ material: } --- -일반적인 ERC20 또는 ERC721 토큰에는 **_토큰 공급량_**이라는 개념이 있네 - 이는 해당 토큰의 총 개수가 얼마인지는 나타내지. +일반적인 ERC20 또는 ERC721 토큰에는 ***토큰 공급량***이라는 개념이 있네 - 이는 해당 토큰의 총 개수가 얼마인지는 나타내지. ERC721x 다중 대체형 토큰에서, 우리는 실제로 동일한 하나의 컨트랙트에 다양한 토큰을 정의할 수 있네 - 그리고 각 토큰은 자신만의 "공급량"(존재하는 토큰의 개수)을 가지게 되지. diff --git a/ko/9/10-erc721x.md b/ko/9/10-erc721x.md index eee89a914c..c1a58fea25 100644 --- a/ko/9/10-erc721x.md +++ b/ko/9/10-erc721x.md @@ -357,7 +357,7 @@ material: 거의 끝나가는군! 이제 우리의 컨트랙트에 함수 하나를 더 추가해서 마무리한 후 뒤에 복습해볼걸세. -우리가 마지막으로 구현할 것은 토큰 **_일괄 발행_** 이라네. 이 함수는 한 번의 함수 호출로 많은 토큰을 발행할 수 있게 해준다네 — 그리고 이것이 ERC721x가 이더리움의 가스 비용을 많이 절약할 수 있게 해주는 이유이기도 하지. +우리가 마지막으로 구현할 것은 토큰 ***일괄 발행*** 이라네. 이 함수는 한 번의 함수 호출로 많은 토큰을 발행할 수 있게 해준다네 — 그리고 이것이 ERC721x가 이더리움의 가스 비용을 많이 절약할 수 있게 해주는 이유이기도 하지. 이 함수는 우리가 지금까지 짜둔 코드로 꽤 간단하게 구현할 수 있다네. diff --git a/no/1/arrays.md b/no/1/arrays.md index ca09285422..3179f460e2 100644 --- a/no/1/arrays.md +++ b/no/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -Når du vil ta i bruk en kolleksjon av elementer kan du bruke en **_array_**. Det er to forskjellinge typer Array i Solidity: **_fixed_** arrays og **_dynamic_** arrays: +Når du vil ta i bruk en kolleksjon av elementer kan du bruke en ***array***. Det er to forskjellinge typer Array i Solidity: ***fixed*** arrays og ***dynamic*** arrays: ``` // Array med en fastslått lengde på 2 strings: @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -Du kan også lage en array av **_structs_**. Ved å ta i bruk forrige kapittels `Person` struct: +Du kan også lage en array av ***structs***. Ved å ta i bruk forrige kapittels `Person` struct: ``` Person[] people; // dynamisk Array, vi kan fortsette å legge til elementer @@ -60,7 +60,7 @@ Husk at status variabler er lagret direkte på Blockchain-en. Så å lage en dyn ## Offentlige Array-er -Du kan deklarere en array som `public`, og Solidity vil automatisk lage en **_getter_** metode for den. Syntaksen ser slik ut: +Du kan deklarere en array som `public`, og Solidity vil automatisk lage en ***getter*** metode for den. Syntaksen ser slik ut: ``` Person[] public people; @@ -72,4 +72,4 @@ Andre contracts vil da ha mulighet til å lese (men ikke skrive til) denne array Vi kommer til å ville lagre en hel gjeng med Zombier i appen vår. Og vi kommer til å ville vise frem alle zombiene våre til andre apper, så vi vil at det skal være offentlig (public). -1. Lag en offentlig(public) array av `Zombie` **_structs_**, og gi den navnet `zombies`. +1. Lag en offentlig(public) array av `Zombie` ***structs***, og gi den navnet `zombies`. diff --git a/no/1/datatypes.md b/no/1/datatypes.md index 903388c802..bb0d3eb2e3 100644 --- a/no/1/datatypes.md +++ b/no/1/datatypes.md @@ -25,7 +25,7 @@ material: Godt jobbet! Nå som vi har laget et skjellett til kontrakten, la oss lære om hvordan Solidity jobber med variabler. -**_Status variabler_**er permanent lagret i kontrakt-lagringsplass. Dette betyr at de blir lagret i Ethereum blockchain-en. Tenk på dem som om du lagrer til en database. +***Status variabler***er permanent lagret i kontrakt-lagringsplass. Dette betyr at de blir lagret i Ethereum blockchain-en. Tenk på dem som om du lagrer til en database. ##### Eksempel: ``` diff --git a/no/1/events.md b/no/1/events.md index 6bdd358095..5934012ff5 100644 --- a/no/1/events.md +++ b/no/1/events.md @@ -73,9 +73,9 @@ material: } --- -Kontrakten vår er nesten ferdig! La oss legge til et **_event_**. +Kontrakten vår er nesten ferdig! La oss legge til et ***event***. -**_Eventer_** er en måte for kontrakten din til å kommunisere at noe skjedde i blockchain-en til front-end appen din, som kan 'lytte' etter spesielle eventer på blockchain-en. +***Eventer*** er en måte for kontrakten din til å kommunisere at noe skjedde i blockchain-en til front-end appen din, som kan 'lytte' etter spesielle eventer på blockchain-en. Example: diff --git a/no/1/functions3.md b/no/1/functions3.md index 6b06fc40f6..b26031c955 100644 --- a/no/1/functions3.md +++ b/no/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -I dette kapittelets skal vi lære om funksjoners **_return verdier_**, og funksjon modifiseringer. +I dette kapittelets skal vi lære om funksjoners ***return verdier***, og funksjon modifiseringer. ## Return Verdier @@ -73,13 +73,13 @@ I Solidity, når en deklarerer en funksjons retur verdier må en legge til hvilk Funksjonen over endrer egentlig ingenting i solidity — f.eks. endrer den ingen verdier eller skriver ingenting. -Så i dette tilfellet kan vi sette den som en **_view_** funksjon, som betyr at dens verdier bare kan leses og ikke kan endre noe: +Så i dette tilfellet kan vi sette den som en ***view*** funksjon, som betyr at dens verdier bare kan leses og ikke kan endre noe: ``` function sayHello() public view returns (string) { ``` -Solidity har også **_pure_** funksjoner, som betyr at du ikke en gang tar i bruk data i applikasjonen. Ta en titt på det følgende: +Solidity har også ***pure*** funksjoner, som betyr at du ikke en gang tar i bruk data i applikasjonen. Ta en titt på det følgende: ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -Denne funksjonen leser ikke fra statusen til appen engang — den returnerer informasjon som bare blir gitt fra parameterene. Så i dette tilfellet kan vi definere funksjonen som **_pure_**. +Denne funksjonen leser ikke fra statusen til appen engang — den returnerer informasjon som bare blir gitt fra parameterene. Så i dette tilfellet kan vi definere funksjonen som ***pure***. > Noter: Det kan være vanskelig å huske å definere funksjoner som pure/view. Heldigvis er Solidity sin kompilator flink til å gi deg varsler om hvor det kan være lurt å legge til en av disse modifisatorene. diff --git a/no/1/lessoncomplete.md b/no/1/lessoncomplete.md index d9883fc8c4..8568394440 100644 --- a/no/1/lessoncomplete.md +++ b/no/1/lessoncomplete.md @@ -14,8 +14,8 @@ Dette er bare begynnelsen. Vi kommer til å slippe en ny CryptoZombies leksjon h ### 1. Logg inn for å lagre progressjonen din -**_Logg inn_** for å lagre progressjonen din ved å klikke "Save Progress" linken på toppen av siden. Vi lar deg vite når neste leksjon blir tilgjengelig. +***Logg inn*** for å lagre progressjonen din ved å klikke "Save Progress" linken på toppen av siden. Vi lar deg vite når neste leksjon blir tilgjengelig. ### 2. Del zombien din til vennene dine -**_Del_** zombien din via Twitter, blah blah, etc. (Need to insert images / links) +***Del*** zombien din via Twitter, blah blah, etc. (Need to insert images / links) diff --git a/no/1/math.md b/no/1/math.md index 8426ef395f..db0480b1cd 100644 --- a/no/1/math.md +++ b/no/1/math.md @@ -34,7 +34,7 @@ Matte i Solidity er ganske rett frem. De følgende operasjonen er de samme som i * Divisjon: `x / y` * Modulus / rest: `x % y` _(for eksempel, `13 % 5` er `3`, fordi hvis du deler 5 på 13, 3 er resten)_ -Solidity støtter også **_eksponentielle operatorer_** (f.eks. "x til kraften av y", x^y): +Solidity støtter også ***eksponentielle operatorer*** (f.eks. "x til kraften av y", x^y): ``` uint x = 5 ** 2; // er lik 5^2 = 25 diff --git a/no/1/structs.md b/no/1/structs.md index 761f73b689..597549afa8 100644 --- a/no/1/structs.md +++ b/no/1/structs.md @@ -32,7 +32,7 @@ material: } --- -Noen ganger trenger du mer komplekse typer data. For dette, tilbyr Solidity **_structs_**: +Noen ganger trenger du mer komplekse typer data. For dette, tilbyr Solidity ***structs***: ``` struct Person { diff --git a/no/1/web3js.md b/no/1/web3js.md index 6083ad2a9d..8aae6ae48d 100644 --- a/no/1/web3js.md +++ b/no/1/web3js.md @@ -12,7 +12,7 @@ material: Solidity-kontrakten vår er ferdig! Nå trenger vi å skrive en JavaScript frontend som kan samhandle kontrakten vår. -Ethereum har et JavaScript library kalt **_Web3.js_**. +Ethereum har et JavaScript library kalt ***Web3.js***. I en senere leksjon, kommer vi til å gå mer i dybden på hvordan distribuere en kontrakt og sette opp Web3.js. Men for nå la oss se på litt eksempel kode for hvordan Web3.js vil samhandle vår distribuerte kontrakt. diff --git a/no/2/10-interactingcontracts.md b/no/2/10-interactingcontracts.md index f7aa0fc388..59f8c393a7 100644 --- a/no/2/10-interactingcontracts.md +++ b/no/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ Ikke bekymre deg - vårt spill kommer ikke til å skade noen CryptoKitty. Vi les ## Samhandl med andre kontrakter -For vår kontrakt å snakke med en annen kontrakt på blockchain som vi ikke eier, må vi først definere et **_ interface _**. +For vår kontrakt å snakke med en annen kontrakt på blockchain som vi ikke eier, må vi først definere et *** interface ***. La oss se på et enkelt eksempel. Si at det var en kontrakt på blockchainen som så ut som dette: @@ -131,7 +131,7 @@ Dette ville være en enkel kontrakt hvor alle kunne lagre sitt lucky nummer, og La oss si at vi hadde en ekstern kontrakt som ønsket å lese dataene i denne kontrakten ved hjelp av `getNum`-funksjonen. -Først må vi definere en **_interface_** av `LuckyNumber` kontrakten: +Først må vi definere en ***interface*** av `LuckyNumber` kontrakten: ``` contract NumberInterface { diff --git a/no/2/2-mappings.md b/no/2/2-mappings.md index 1695f02883..0ba8d6969a 100644 --- a/no/2/2-mappings.md +++ b/no/2/2-mappings.md @@ -84,7 +84,7 @@ For å gjøre dette trenger vi 2 nye datatyper:`mapping` og `address`. ## Adresser -Ethereum blockchain består av **_accounts_**, som du kan tenke på som bankkontoer. En konto har en balanse mellom **_Ether_** (den valutaen som brukes i Ethereum-blokkkjeden), og du kan sende og motta Ether-betalinger til andre kontoer, akkurat som at bankkontoen din kan overføre penger til andre bankkontoer. +Ethereum blockchain består av ***accounts***, som du kan tenke på som bankkontoer. En konto har en balanse mellom ***Ether*** (den valutaen som brukes i Ethereum-blokkkjeden), og du kan sende og motta Ether-betalinger til andre kontoer, akkurat som at bankkontoen din kan overføre penger til andre bankkontoer. Hver konto har en `address`, som du kan tenke på som et bankkontonummer. Det er en unik identifikator som peker på den kontoen, og det ser slik ut: @@ -98,7 +98,7 @@ Så vi kan bruke den som en unik ID for eierskap av våre zombier. Når en bruke ## Mapping -I Leksjon 1 så vi på **_structs_** og **_arrays_**. **_Mappings_**er en annen måte å lagre organisert data på i Solidity. +I Leksjon 1 så vi på ***structs*** og ***arrays***. ***Mappings***er en annen måte å lagre organisert data på i Solidity. Definere en `mapping` ser slik ut: diff --git a/no/2/5-inheritance.md b/no/2/5-inheritance.md index dba5959849..5be79375b9 100644 --- a/no/2/5-inheritance.md +++ b/no/2/5-inheritance.md @@ -94,7 +94,7 @@ material: --- Vår spillkode begynner å bli ganske lang. I stedet for å lage en ekstremt lang kontrakt, er det noen ganger greit å dele kodelogikken din på tvers av flere kontrakter for å organisere koden. -En egenskap av Solidity som gjør dette mer overkommelig er kontrakt **_arv_**: +En egenskap av Solidity som gjør dette mer overkommelig er kontrakt ***arv***: ``` contract Doge { @@ -110,7 +110,7 @@ contract BabyDoge is Doge { } ``` -`BabyDoge` **_arver_** fra `Doge`. Det betyr at hvis du kompilerer og distribuerer `BabyDoge`,vil den ha adgang til både `catchphrase()` og `anotherCatchphrase()` og eventuelle andre offentlige funksjoner vi kan definere i `Doge`). +`BabyDoge` ***arver*** fra `Doge`. Det betyr at hvis du kompilerer og distribuerer `BabyDoge`,vil den ha adgang til både `catchphrase()` og `anotherCatchphrase()` og eventuelle andre offentlige funksjoner vi kan definere i `Doge`). Dette kan brukes til logisk arv (som med en underklasse, en `katt` er et`dyr`). Men det kan også brukes til å organisere koden din ved å gruppere lignende logikk sammen i forskjellige klasser. diff --git a/no/2/7-storage.md b/no/2/7-storage.md index 1b04255166..68eea83191 100644 --- a/no/2/7-storage.md +++ b/no/2/7-storage.md @@ -71,11 +71,11 @@ material: I Solidity, er det to steder du kan lagre variabler — i `storage` og in `memory`. -**_Storage_** refererer til variabler lagret permanent på blockchain. **_Memory_** variabler er midlertidige, og slettes mellom eksterne funksjonssamtaler til kontrakten din. Tenk på det som datamaskinens harddisk vs RAM. +***Storage*** refererer til variabler lagret permanent på blockchain. ***Memory*** variabler er midlertidige, og slettes mellom eksterne funksjonssamtaler til kontrakten din. Tenk på det som datamaskinens harddisk vs RAM. Mesteparten av tiden trenger du ikke å bruke disse nøkkelordene, fordi Solidity håndterer dem som standard. Status-variabler (variabler deklarert utenfor funksjoner) er som standard `storage` og skrevet permanent til blockchainen, mens variabler som er deklarert inne i funksjonene, er`memory` og vil forsvinne når funksjonsanropet avsluttes. -Men, det er noen ganger du faktisk trenger å bruke disse nøkkelordene, mest når vi håndterer **_structs_** og **_arrays_** inne i funksjoner: +Men, det er noen ganger du faktisk trenger å bruke disse nøkkelordene, mest når vi håndterer ***structs*** og ***arrays*** inne i funksjoner: ``` contract SandwichFactory { diff --git a/no/3/01-externaldependencies.md b/no/3/01-externaldependencies.md index 9c8270b2bb..a6ced88bed 100644 --- a/no/3/01-externaldependencies.md +++ b/no/3/01-externaldependencies.md @@ -143,7 +143,7 @@ material: Hittil har Solidity sett ganske lik ut som andre språk, som JavaScript. Men det er mange måter Ethereum DApps er forskjellig fra normale applikasjoner. -Til å begynne med, etter at du har distribuert en kontrakt til Ethereum, er den **_uforanderlig (Immutable)_**, noe som betyr at den aldri kan endres eller oppdateres igjen. +Til å begynne med, etter at du har distribuert en kontrakt til Ethereum, er den ***uforanderlig (Immutable)***, noe som betyr at den aldri kan endres eller oppdateres igjen. Den opprinnelige koden du distribuerer til en kontrakt er der for å være permanent, i blockchain-en. Dette er en av grunnene til at sikkerhet er en så stor bekymring i Solidity. Hvis det er feil i kontraktskoden din, er det ikke mulig å fikse det senere. Du må få brukerne til å begynne å bruke en annen smart-kontrakt adresse enn den som har feilen. diff --git a/no/3/02-ownable.md b/no/3/02-ownable.md index 039d820b42..2b0f8cc111 100644 --- a/no/3/02-ownable.md +++ b/no/3/02-ownable.md @@ -189,7 +189,7 @@ For å håndtere saker som denne, en vanlig praksises som har oppstått er å la ## OpenZeppelin's `Ownable` kontrakter -Nedenfor er den `Ownable` kontrakten hentet fra **_OpenZeppelin_** Solidity library. OpenZeppelin er et library med sikre og samfunnsmessige smart-kontrakter som du kan bruke i dine egne DApps. Etter denne leksjonen, mens du venter på utgivelsen av leksjon 4, anbefaler vi at du sjekker ut deres nettsted for å lære mer! +Nedenfor er den `Ownable` kontrakten hentet fra ***OpenZeppelin*** Solidity library. OpenZeppelin er et library med sikre og samfunnsmessige smart-kontrakter som du kan bruke i dine egne DApps. Etter denne leksjonen, mens du venter på utgivelsen av leksjon 4, anbefaler vi at du sjekker ut deres nettsted for å lære mer! Gi kontrakten under en gjennomgang. Du kommer til å se ting vi ikke har lært enda, men ikke vær bekymret, vi kommert til å snakke om dem senere. @@ -233,7 +233,7 @@ contract Ownable { Et par nye ting her har vi ikke sett før: -- Constructors: `function Ownable ()` er en **_constructor_**, som er en valgfri spesialfunksjon som har samme navn som kontrakten. Det vil bli utført bare én gang, når kontrakten er først opprettet. +- Constructors: `function Ownable ()` er en ***constructor***, som er en valgfri spesialfunksjon som har samme navn som kontrakten. Det vil bli utført bare én gang, når kontrakten er først opprettet. - Funksjonsmodifikatorer: `modifier onlyOwner ()`. Modifikatorer er en slags halvfunksjon som brukes til å endre andre funksjoner, vanligvis for å kontrollere krav før utførelsen. I dette tilfellet kan `onlyOwner` brukes til å begrense tilgangen slik **kun eieren** av kontrakten kan kjøre denne funksjonen. Vi snakker mer om funksjonsmodifikatorer i neste kapittel, og hva `_;` gjør. - `indexed` nøkkelordet: ikke bekymre deg om dette, vi trenger ikke det enda. diff --git a/no/3/04-gas.md b/no/3/04-gas.md index 9eac40de04..b3d293df59 100644 --- a/no/3/04-gas.md +++ b/no/3/04-gas.md @@ -187,9 +187,9 @@ La oss se på en annen måte Solidity er ganske forskjellig fra andre programmer ## Gas — drivstoffet Ethereum DApps kjører på -I Solidity må brukerne betale hver gang de utfører en funksjon på din DApp ved hjelp av en valuta som kalles **_gas_**. Brukere kjøper gass med Ether (valutaen på Ethereum), så brukerne må bruke ETH for å kunne utføre funksjoner på din DApp. +I Solidity må brukerne betale hver gang de utfører en funksjon på din DApp ved hjelp av en valuta som kalles ***gas***. Brukere kjøper gass med Ether (valutaen på Ethereum), så brukerne må bruke ETH for å kunne utføre funksjoner på din DApp. -Hvor mye gass som kreves for å utføre en funksjon, avhenger av hvor kompleks den funksjonens logikk er. Hver enkelt operasjon har en **_gas cost_** basert på hvor mye databehandlingsressurser som kreves for å utføre denne operasjonen (for eksempel å skrive til storage er mye dyrere enn å legge til to integers). Den totale **_gas cost_**-en av funksjonen din er summen av gasskostnadene for alle sine individuelle operasjoner. +Hvor mye gass som kreves for å utføre en funksjon, avhenger av hvor kompleks den funksjonens logikk er. Hver enkelt operasjon har en ***gas cost*** basert på hvor mye databehandlingsressurser som kreves for å utføre denne operasjonen (for eksempel å skrive til storage er mye dyrere enn å legge til to integers). Den totale ***gas cost***-en av funksjonen din er summen av gasskostnadene for alle sine individuelle operasjoner. Fordi løpende funksjoner koster ekte penger for brukerne, er kodeoptimalisering mye viktigere i Ethereum enn i andre programmeringsspråk. Hvis koden din er slurvete, må brukerne betale en høy pris for å utføre dine funksjoner - og dette kan gi opptil millioner av dollar i unødvendige avgifter over tusenvis av brukere. diff --git a/pl/1/arrays.md b/pl/1/arrays.md index fcd7ac6153..030bca3fe1 100644 --- a/pl/1/arrays.md +++ b/pl/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -Kiedy chcesz zdefiniować kolekcje czegoś, możesz użyć **_array_**. Istnieją dwa typy tablic w Solidity: **_fixed_** oraz **_dynamic_**: +Kiedy chcesz zdefiniować kolekcje czegoś, możesz użyć ***array***. Istnieją dwa typy tablic w Solidity: ***fixed*** oraz ***dynamic***: ``` // Tablica typu fixed o długości dwóch elementów: @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -Możesz również stworzyć tablicę typu **_structs_**. Używająć `Person` struct z pierwszego rozdziału: +Możesz również stworzyć tablicę typu ***structs***. Używająć `Person` struct z pierwszego rozdziału: ``` Person[] people; // Tablica typu dynamic, możemy wciąż do niej dodawać nowe elementy @@ -61,7 +61,7 @@ Pamiętasz, że zmienne stanu (state variables) są zapisane permanentnie w bloc ## Public Arrays -Możesz deklarować tablice jako `public` Solidity automatycznie stworzy **_getter_** dla niej. Składnia wygląda następująco: +Możesz deklarować tablice jako `public` Solidity automatycznie stworzy ***getter*** dla niej. Składnia wygląda następująco: ``` Person[] public people; @@ -74,4 +74,4 @@ Inne kontrakty będą mogły później czytać (ale nie zapisywać) tą tablice. Zamierzamy dodać armię zombi do naszej aplikacji. Chcemy również, aby armia była widoczna dla innych aplikacji. W takim razie będzie musiała być zapisana jako publiczna. -1. Stwórz publiczną tablicę `Zombie` **_structs_**, i nazwij ją `zombies`. +1. Stwórz publiczną tablicę `Zombie` ***structs***, i nazwij ją `zombies`. diff --git a/pl/1/datatypes.md b/pl/1/datatypes.md index b9795a2870..674adeca88 100644 --- a/pl/1/datatypes.md +++ b/pl/1/datatypes.md @@ -25,7 +25,7 @@ material: Dobra robota! Teraz kiedy mamy już podstawowy kontrakt, możemy nauczyć się jak Solidity obchodzi się ze zmiennymi. -**_Zmienne stanu_** są permanentnie zapisywane w pamięci kontraktu. Znaczy to mniej więcej tyle, że są zapisane w blockchainie Ethereum. Możesz myśleć o tym jak o zapisywaniu do bazy danych. +***Zmienne stanu*** są permanentnie zapisywane w pamięci kontraktu. Znaczy to mniej więcej tyle, że są zapisane w blockchainie Ethereum. Możesz myśleć o tym jak o zapisywaniu do bazy danych. ##### Przykład: ``` diff --git a/pl/1/events.md b/pl/1/events.md index d6c38b5cde..5364efe531 100644 --- a/pl/1/events.md +++ b/pl/1/events.md @@ -73,9 +73,9 @@ material: } --- -Nasz kontrakt jest prawie gotowy! Teraz dodajmy jeszcze **_event_**. +Nasz kontrakt jest prawie gotowy! Teraz dodajmy jeszcze ***event***. -**_Events(Zdarzenia)_** pozwalają Twojemu kontraktowi wysłać informacje do frontowej aplikacji. Frontowa aplikacja 'nasłuchuje', czy dane zdarzenie zaszło i jeśli tak jest to podejmuje stosowną akcję. +***Events(Zdarzenia)*** pozwalają Twojemu kontraktowi wysłać informacje do frontowej aplikacji. Frontowa aplikacja 'nasłuchuje', czy dane zdarzenie zaszło i jeśli tak jest to podejmuje stosowną akcję. Przykład: diff --git a/pl/1/functions3.md b/pl/1/functions3.md index 439578e537..91208c509d 100644 --- a/pl/1/functions3.md +++ b/pl/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -W tym rozdziale nauczymy się o tym co zwracają funkcje **_return values_**, oraz o modyfikatorach funkcji. +W tym rozdziale nauczymy się o tym co zwracają funkcje ***return values***, oraz o modyfikatorach funkcji. ## Return Values @@ -73,13 +73,13 @@ W Solidity, w deklaracji funkcji trzeba napisać jaki typ zmiennej będzie zwrac Powyższa funkcja nie zmienia stanu w Solidity — nie zmiania żadnej wartości, ani nie zapisuje niczego. -W takim przypadku możemy zadeklarować ją jako **_view_**. Oznacza to, że funkcja wyświetla tylko dane, ale nie modyfikuje ich: +W takim przypadku możemy zadeklarować ją jako ***view***. Oznacza to, że funkcja wyświetla tylko dane, ale nie modyfikuje ich: ``` function sayHello() public view returns (string) { ``` -Solidity zawiera również "czyste" **_pure_** funkcje. Oznacza to, że nie wykorzystuje się w nich żadnych danych z aplikacji. Rozważmy powyższy przykład: +Solidity zawiera również "czyste" ***pure*** funkcje. Oznacza to, że nie wykorzystuje się w nich żadnych danych z aplikacji. Rozważmy powyższy przykład: ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -Funkcja nie czyta żadnego stanu aplikacji — wartość którą zwraca zależy tylko od jej parametrów. W takim przypadku możemy zadeklarować taką funkcje jako **_pure_**. +Funkcja nie czyta żadnego stanu aplikacji — wartość którą zwraca zależy tylko od jej parametrów. W takim przypadku możemy zadeklarować taką funkcje jako ***pure***. > Notatka: Może to być trudne do zapamiętania kiedy oznaczać funkcje pure/view. Na szczęście kompilator Solidity jest na tyle mądry, że zwraca ostrzeżenia podczas kompilacji. diff --git a/pl/1/lessoncomplete.md b/pl/1/lessoncomplete.md index 1d8ed98388..a28b051c50 100644 --- a/pl/1/lessoncomplete.md +++ b/pl/1/lessoncomplete.md @@ -14,8 +14,8 @@ To dopiero początek. Będziemy wypuszczać nową lekcję CryptoZombies co tydzi ### 1. Zarejestruj się aby zapisać swój postęp -**_Zarejestruj się_** aby zapisać swój postęp klikając przycisk "Zapisz" na górze strony. Poinformujemy Cię, kiedy pojawi się nowa lekcja. +***Zarejestruj się*** aby zapisać swój postęp klikając przycisk "Zapisz" na górze strony. Poinformujemy Cię, kiedy pojawi się nowa lekcja. ### 2. Udostępnij swojego Zombie przyjaciołom -**_Udostępnij_** twojego zombie na Twitterze, blah blah, etc. (Need to insert images / links) +***Udostępnij*** twojego zombie na Twitterze, blah blah, etc. (Need to insert images / links) diff --git a/pl/1/math.md b/pl/1/math.md index 72bdd4f413..787b3ec47c 100644 --- a/pl/1/math.md +++ b/pl/1/math.md @@ -34,7 +34,7 @@ Matematyczne operacje w Solidity są intuicyjne. Poniższe operacje są takie sa * dzielenie: `x / y` * Modulo / reszta z dzielenia: `x % y` _(na przykład, `13 % 5` wynosi `3`, ponieważ jeśli podzielisz 13 przez 5, 3 jest resztą z dzielenia)_ -Solidity również wspiera **_potęgowanie_** (np. "x do potęgi y", x^y): +Solidity również wspiera ***potęgowanie*** (np. "x do potęgi y", x^y): ``` uint x = 5 ** 2; // wynosi 5^2 = 25 diff --git a/pl/1/structs.md b/pl/1/structs.md index efca7eedb4..ed80a6a094 100644 --- a/pl/1/structs.md +++ b/pl/1/structs.md @@ -32,7 +32,7 @@ material: } --- -Czasami potrzebujesz bardziej złożonego typu danych. W tym celu Solidity dostarcza **_structs_**: +Czasami potrzebujesz bardziej złożonego typu danych. W tym celu Solidity dostarcza ***structs***: ``` struct Person { diff --git a/pl/1/web3js.md b/pl/1/web3js.md index 6b84a7ce4e..f319ac4589 100644 --- a/pl/1/web3js.md +++ b/pl/1/web3js.md @@ -12,7 +12,7 @@ material: Nasz kontrakt Solidity jest gotowy! Teraz musimy już tylko napisać frontend w JavaScripcie, który będzie wchodził w interakcje z naszym kontraktem. -Ethereum dostarcza biblotekę JavaScript o nazwie **_Web3.js_**. +Ethereum dostarcza biblotekę JavaScript o nazwie ***Web3.js***. W późniejszych lekcjach pokażemy jak publikować kontrakt oraz jak ustawić Web3.js. Narazie jednak zobaczmy jak wygląda przykładowy kod, który komunikuje się z kontraktem. diff --git a/pt/1/arrays.md b/pt/1/arrays.md index fee9e12c90..9063281d64 100644 --- a/pt/1/arrays.md +++ b/pt/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -Quando você quer uma lista de algo, você pode usar um **_array_** (lista). Existem dois tipos de arrays (listas) em Solidity: **_fixed_** (fixo) arrays e **_dynamic_** (dinâmico) arrays: +Quando você quer uma lista de algo, você pode usar um ***array*** (lista). Existem dois tipos de arrays (listas) em Solidity: ***fixed*** (fixo) arrays e ***dynamic*** (dinâmico) arrays: ``` // Array com tamanho fixo de 2 elementos: @@ -52,7 +52,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -Você também pode criar um array de **_structs_** (Estruturas). Usando a estrutura `Person` do capítulo anterior. +Você também pode criar um array de ***structs*** (Estruturas). Usando a estrutura `Person` do capítulo anterior. ``` Person[] people; // Array dinâmico, podemos continuar adicionando @@ -63,7 +63,7 @@ Você lembra que variáveis de estado são guardadas permanentemente na blockcha ## Arrays públicos -Você pode declarar um array como `public` (público), e Solidity vai automaticamente criar um método **_getter_** para ele. A sintaxe fica assim: +Você pode declarar um array como `public` (público), e Solidity vai automaticamente criar um método ***getter*** para ele. A sintaxe fica assim: ``` Person[] public people; @@ -76,4 +76,4 @@ Outros contracts poderão ler (mas não escrever) este array. Isso é um padrão Nós queremos armazenar um exército de zumbis em nosso aplicativo. E queremos mostrar todos os nossos zumbis para outros aplicativos, então queremos que seja público. -1. Crie um array público de `Zombie` **_structs_**, e nomei-o como `zombies` \ No newline at end of file +1. Crie um array público de `Zombie` ***structs***, e nomei-o como `zombies` \ No newline at end of file diff --git a/pt/1/datatypes.md b/pt/1/datatypes.md index e8bd49906a..6d5ce5e6f4 100644 --- a/pt/1/datatypes.md +++ b/pt/1/datatypes.md @@ -25,7 +25,7 @@ material: Bom trabalho! Agora que temos a casca para os nossos contratos, vamos aprender sobre como trabalhar com variáveis em Solidity. -**_Variáveis de Estado_** são permanentemente gravadas no armazenamento do contrato. Isso quer dizer que são escritas na blockchain do Ethereum. Pense nelas como escrever em um banco de dados. +***Variáveis de Estado*** são permanentemente gravadas no armazenamento do contrato. Isso quer dizer que são escritas na blockchain do Ethereum. Pense nelas como escrever em um banco de dados. ##### Exemplo: ``` diff --git a/pt/1/events.md b/pt/1/events.md index eb4f09d42e..22b7030b00 100644 --- a/pt/1/events.md +++ b/pt/1/events.md @@ -73,9 +73,9 @@ material: } --- -Nosso contrato esta quase terminado! Agora vamos adicionar um **_evento_**. +Nosso contrato esta quase terminado! Agora vamos adicionar um ***evento***. -**_Eventos_** são as maneiras dos seus contratos comunicarem que algo aconteceu na blockchain para o seu aplicativo em um frontend, que pode `ouvir` por certos tipos de eventos e tomar ações quando algo acontecer. +***Eventos*** são as maneiras dos seus contratos comunicarem que algo aconteceu na blockchain para o seu aplicativo em um frontend, que pode `ouvir` por certos tipos de eventos e tomar ações quando algo acontecer. Exemplo: diff --git a/pt/1/functions3.md b/pt/1/functions3.md index fe9f55e37c..03597c925f 100644 --- a/pt/1/functions3.md +++ b/pt/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -Neste capítulo vamos aprender sobre funções que **_retornam valores_**, e sobre modificadores de funções. +Neste capítulo vamos aprender sobre funções que ***retornam valores***, e sobre modificadores de funções. ## Retornando Valores @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -Esta função nem mesmo lê um estado da aplicação - os seus valores retornados dependem somente dos parâmetros da função. Então neste caso nós podemos declarar a função como **_pura_** usando a palavra reservada `pure`. +Esta função nem mesmo lê um estado da aplicação - os seus valores retornados dependem somente dos parâmetros da função. Então neste caso nós podemos declarar a função como ***pura*** usando a palavra reservada `pure`. > Nota: Pode ser um tanto quanto complicado lembrar quando marcar a função como pura/observação (pure/view). Para a nossa sorte o compilador de Solidity faz um bom trabalho em avisar-nos quando devemos usar algum desses modificadores. diff --git a/pt/1/lessoncomplete.md b/pt/1/lessoncomplete.md index 6c2b3e8f33..e0726663ff 100644 --- a/pt/1/lessoncomplete.md +++ b/pt/1/lessoncomplete.md @@ -14,8 +14,8 @@ Isso é só o começo. Nós iremos lançar uma nova lição do CryptoZombies tod ### 1. Cadastre-se para salvar o seu progresso -**_Cadastre-se_** para salvar o seu progresso clicando no link "Save Progress" no topo da página. Nós vamos avisar você logo que uma nova lição for adicionada. +***Cadastre-se*** para salvar o seu progresso clicando no link "Save Progress" no topo da página. Nós vamos avisar você logo que uma nova lição for adicionada. ### 2. Compartilhe o seu zumbi com os amigos -**_Compartilhe_** seu zumbi no Twitter, blah blah, etc. (Need to insert images / links) +***Compartilhe*** seu zumbi no Twitter, blah blah, etc. (Need to insert images / links) diff --git a/pt/1/math.md b/pt/1/math.md index 40132a1296..2a60690c5c 100644 --- a/pt/1/math.md +++ b/pt/1/math.md @@ -34,7 +34,7 @@ Matemática em Solidity é bem fácil. As seguintes operações são as mesmas n * Divisão: `x / y` * Módulo / Resto: `x % y` _(por exemplo, `13 % 5` é `3`, porque se você dividir 5 por 13, 3 é o resto)_ -Solidity também suporta um **_operador exponencial_** (exemplo: "x elevado a potência de y", x^y): +Solidity também suporta um ***operador exponencial*** (exemplo: "x elevado a potência de y", x^y): ``` uint x = 5 ** 2; // o mesmo que 5^2 = 25 diff --git a/pt/1/structs.md b/pt/1/structs.md index 8f19ab451a..53ca98a893 100644 --- a/pt/1/structs.md +++ b/pt/1/structs.md @@ -32,7 +32,7 @@ material: } --- -Algumas vezes você precisa de um tipo de dado mais complexo. Para isso, Solidity fornece **_structs_**: +Algumas vezes você precisa de um tipo de dado mais complexo. Para isso, Solidity fornece ***structs***: ``` struct Person { diff --git a/pt/1/web3js.md b/pt/1/web3js.md index 2e6aa88a46..6aac20bef8 100644 --- a/pt/1/web3js.md +++ b/pt/1/web3js.md @@ -12,7 +12,7 @@ material: Nosso contrato em Solidity esta completo! Agora nós vamos escrever o frontend em JavaScript que interage com o contrato. -Ethereum possui uma biblioteca em JavaScript chamada **_Web3.js_**. +Ethereum possui uma biblioteca em JavaScript chamada ***Web3.js***. Nas lições mais à frente, iremos nos aprofundar em como implantar um contrato e configurar a Web3.js. Mas por enquanto vamos somente ver uma amostra de um código de como a Web3.js irá interagir com um contrato já implantado (deployed). diff --git a/pt/2/10-interactingcontracts.md b/pt/2/10-interactingcontracts.md index ad871a1655..2cc05ea584 100644 --- a/pt/2/10-interactingcontracts.md +++ b/pt/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ Não se preocupe - nosso jogo atual não irá machucar qualquer CryptoKitty. Nó ## Interagindo com outros contratos -Para que o nosso contrato converse com outro contrato na blockchain que não é nosso, primeiro temos que definir uma **_interface_**. +Para que o nosso contrato converse com outro contrato na blockchain que não é nosso, primeiro temos que definir uma ***interface***. Vamos ver um simples exemplo. Digamos que existe um contrato na blockchain que se parece com isto: @@ -131,7 +131,7 @@ Este seria um simples contrato onde qualquer um pode guardar um número da sorte Agora digamos que nós temos um contrato externo que quer ler o dado deste contrato usando a função `getNum`. -Primeiro nós gostaríamos de definir uma **_interface_** para o contrato `LuckyNumber`: +Primeiro nós gostaríamos de definir uma ***interface*** para o contrato `LuckyNumber`: ``` contract NumberInterface { diff --git a/pt/2/2-mappings.md b/pt/2/2-mappings.md index 8bb05ed505..c721fabc2d 100644 --- a/pt/2/2-mappings.md +++ b/pt/2/2-mappings.md @@ -84,7 +84,7 @@ Para fazer isto, nós vamos precisar de 2 novos tipos de dados: `mapping` e `add ## Endereços -O blockchain do Ethereum é feito de **_accounts_** (contas), que você pode imaginar como contas de banco. Um conta tem um saldo **_Ether_** (a moeda usada no blockchain do Ethereum), e você pode enviar e receber pagamentos de outras contas, como a sua conta de banco que você pode enviar uma transferência (DOC/TED) em dinheiro para outras contas. +O blockchain do Ethereum é feito de ***accounts*** (contas), que você pode imaginar como contas de banco. Um conta tem um saldo ***Ether*** (a moeda usada no blockchain do Ethereum), e você pode enviar e receber pagamentos de outras contas, como a sua conta de banco que você pode enviar uma transferência (DOC/TED) em dinheiro para outras contas. Cada conta tem um `address` (endereço), que você pode imaginar como o número da conta bancária. Esse número é um identificador único que indica a conta, e se parece com isto: @@ -98,7 +98,7 @@ Então nós podemos usar este ID único como propriedade dos nossos zumbis. Quan ## Mapeamentos -Na Lição 1 nós vimos as **_structs_** (estruturas) e **_arrays_** (listas). **_Mapeamentos_** são uma outra forma de guardar dados organizados em Solidity. +Na Lição 1 nós vimos as ***structs*** (estruturas) e ***arrays*** (listas). ***Mapeamentos*** são uma outra forma de guardar dados organizados em Solidity. Definindo um `mapping` (mapeamento) se parece com isto: diff --git a/pt/2/5-inheritance.md b/pt/2/5-inheritance.md index 3055003336..4a9675cdcf 100644 --- a/pt/2/5-inheritance.md +++ b/pt/2/5-inheritance.md @@ -95,7 +95,7 @@ material: O código do nosso jogo está ficando um tanto grande. Ao invés de fazer um contrato extremamente grande, as vezes faz mais sentido separar as lógicas em vários contratos para organizar o código. -Umas característica que torna o Solidity mais gerenciável é a **_herança_** de contrato: +Umas característica que torna o Solidity mais gerenciável é a ***herança*** de contrato: ``` contract Doge { @@ -111,7 +111,7 @@ contract BabyDoge is Doge { } ``` -`BabyDoge` **_herda_** de `Doge`. Isso significa que se você compilar e implantar `BabyDoge`, ele terá acesso a ambas `catchphrase()` e `anotherCatchphrase()` (e qualquer outra função pública que nós podemos definir em `Doge`). +`BabyDoge` ***herda*** de `Doge`. Isso significa que se você compilar e implantar `BabyDoge`, ele terá acesso a ambas `catchphrase()` e `anotherCatchphrase()` (e qualquer outra função pública que nós podemos definir em `Doge`). Isto pode ser útil para uma herança lógica (assim como uma sub classe, um `Cat` é um `Animal`). Mas também pode ser usado para uma simples organização em seu código ao agrupar lógicas similares juntas em diferentes classes. diff --git a/pt/2/7-storage.md b/pt/2/7-storage.md index 5aa22f6201..8c5c3c332a 100644 --- a/pt/2/7-storage.md +++ b/pt/2/7-storage.md @@ -71,11 +71,11 @@ material: Em Solidity, existem dois lugares onde você pode guardar as variáveis - na `storage` (armazenamento) e na `memory` (memória). -**_Storage_** (Armazenamento) refere-se as variáveis guardadas permanentemente na blockchain. **_Memory_** (Memória) são variáveis temporárias, e são apagadas entre as chamadas externas para o seu contrato. Imagine como o disco rígido do seu computador vs memória RAM. +***Storage*** (Armazenamento) refere-se as variáveis guardadas permanentemente na blockchain. ***Memory*** (Memória) são variáveis temporárias, e são apagadas entre as chamadas externas para o seu contrato. Imagine como o disco rígido do seu computador vs memória RAM. Na maior parte do tempo você não precisa usar essas palavras-reservadas porque a Solidity cuida disso pra você por padrão. Variáveis de estado (variáveis declaradas fora das funções) são por padrão `storage` e são escritas permanentemente na blockchain, enquanto variáveis declaradas dentro das funções são `memory` e irão desaparecer quando a função terminar. -Porém, haverão momentos em que você precisará usar tais palavras-reservadas, por exemplo quando trabalhar com **_struct_** e **_arrays_** dentro das funções: +Porém, haverão momentos em que você precisará usar tais palavras-reservadas, por exemplo quando trabalhar com ***struct*** e ***arrays*** dentro das funções: ``` contract SandwichFactory { diff --git a/pt/3/01-externaldependencies.md b/pt/3/01-externaldependencies.md index 5df9a4fd18..da66fcc0b2 100644 --- a/pt/3/01-externaldependencies.md +++ b/pt/3/01-externaldependencies.md @@ -143,7 +143,7 @@ material: Até agora, Solidity pareceu bastante similar a outras linguagens como JavaScript. Mas as aplicações distribuídas em Ethereum são um tanto diferentes de aplicações normais em diversas maneiras. -Para começar, após você implantar um contrato em Ethereum, este é **_imutável_**, quer dizer que ele nunca poder ser modificado ou melhorado novamente. +Para começar, após você implantar um contrato em Ethereum, este é ***imutável***, quer dizer que ele nunca poder ser modificado ou melhorado novamente. O código que você implantou para um contrato esta lá permanentemente, para sempre, na blockchain. Esta é uma das razões na qual a segurança em Solidity é uma grande preocupação. Se houver uma falha no código do contrato, não há maneira de remendar depois. Você precisará dizer aos seus usuários para começarem a usar um outro smart contract que tem a correção. diff --git a/pt/3/02-ownable.md b/pt/3/02-ownable.md index 0d258466ee..04c68bf166 100644 --- a/pt/3/02-ownable.md +++ b/pt/3/02-ownable.md @@ -189,7 +189,7 @@ Para lidar com casos assim, uma prática que se tornou comum é tornar o contrat ## Contratos `Ownable` do OpenZeppelin -Abaixo um contrato `Ownable` pego da biblioteca Solidity do **_OpenZeppelin_**. OpenZeppelin é uma biblioteca de contratos seguros e auditados pela comunidade que você pode usar em suas próprias DApps. Após esta lição, recomendamos fortemente que você visite o site deles para maior aprendizado. +Abaixo um contrato `Ownable` pego da biblioteca Solidity do ***OpenZeppelin***. OpenZeppelin é uma biblioteca de contratos seguros e auditados pela comunidade que você pode usar em suas próprias DApps. Após esta lição, recomendamos fortemente que você visite o site deles para maior aprendizado. Leia com atenção o contrato abaixo. Você verá algumas coisas que nós já aprendemos, mas não se preocupe, iremos falar mais sobre isso em seguida. @@ -233,7 +233,7 @@ contract Ownable { Um pouco de novas coisas que não vimos antes: -- Construtores: `function Ownable()` é um **_construtor_**, que é uma função opcional e especial que tem o mesmo nome do contrato. Esta será executada somente uma vez, quando o contrato é criado a primeira vez. +- Construtores: `function Ownable()` é um ***construtor***, que é uma função opcional e especial que tem o mesmo nome do contrato. Esta será executada somente uma vez, quando o contrato é criado a primeira vez. - Funções Modificadoras: `modifier onlyOwner()`. Modificadores são um tipo de meia-função que são usadas para modificar outras funções, normalmente usadas para checar algo requerido antes da execução. Neste caso, `onlyOwner` pode ser usada para limitar o acesso então **only** (somente) o **owner** (dono) do contrato pode executar esta função. Nós iremos falar mais sobre funções modificadoras no próximo capítulo, e o que esse `_;` faz. - Palavra-chave `indexed`: não se preocupe com isso, nós ainda não precisamos. diff --git a/pt/3/04-gas.md b/pt/3/04-gas.md index a7d864e70d..fef3d56ad5 100644 --- a/pt/3/04-gas.md +++ b/pt/3/04-gas.md @@ -185,9 +185,9 @@ Vamos ver outra maneira que Solidity é um tanto diferente de outras linguagens ## Gas — o combustível utilizado por DApps Ethereum -Em Solidity, seus usuários tem que pagar toda vez que executam uma função em sua DApp usando uma moeda chamada **_gas_**. Usuários compram gas com Ether (a moeda no Ethereum), então os seus usuários precisam gastar ETH para executar funções em sua DApp. +Em Solidity, seus usuários tem que pagar toda vez que executam uma função em sua DApp usando uma moeda chamada ***gas***. Usuários compram gas com Ether (a moeda no Ethereum), então os seus usuários precisam gastar ETH para executar funções em sua DApp. -Quanto gas é preciso para executar uma função depende o quão complexo é a lógica desta função. Cada operação individual tem um **_custo em gas_** baseado mais ou menos em quanto recursos computacionais serão necessários para realizar essa operação (exemplo: escrever em storage é muito mais caro do que adicionar dois inteiros). O total de **_custo em gas_** da sua função é soma de todos os custo de todas as operações de forma individuais. +Quanto gas é preciso para executar uma função depende o quão complexo é a lógica desta função. Cada operação individual tem um ***custo em gas*** baseado mais ou menos em quanto recursos computacionais serão necessários para realizar essa operação (exemplo: escrever em storage é muito mais caro do que adicionar dois inteiros). O total de ***custo em gas*** da sua função é soma de todos os custo de todas as operações de forma individuais. E porque executar funções custam dinheiro real para os seus usuários, otimização do código é muito mais importante em Ethereum do que em qualquer outra linguagem de programação. Se o seu código é desleixado, seus usuários terão que pagar muito mais para executar suas funções - e isto pode adicionar milhões de dólares em custos desnecessários através de milhares de usuários. diff --git a/pt/4/battle-02.md b/pt/4/battle-02.md index 17e954b5e7..bf9af4caa6 100644 --- a/pt/4/battle-02.md +++ b/pt/4/battle-02.md @@ -244,7 +244,7 @@ O mesmo iria então usar `keccak` para converter os valores de entrada para o ha ### Este método é vulnerável a um ataque por um nó desonesto -Em Ethereum, quando você chama uma função em um contrato, você transmite o mesmo para um nó ou muitos nós na rede como uma **_transação_**. Os nós na rede então coletam um monte de transações, tentam ser o primeiro a resolver um problema matemático e computacionalmente intensivo como uma "Proof of Work" (Prova de Trabalho), e então publicam este grupo de transações junto com a Proof Of Work (PoW) como um **_bloco_** para o resto da rede da rede. +Em Ethereum, quando você chama uma função em um contrato, você transmite o mesmo para um nó ou muitos nós na rede como uma ***transação***. Os nós na rede então coletam um monte de transações, tentam ser o primeiro a resolver um problema matemático e computacionalmente intensivo como uma "Proof of Work" (Prova de Trabalho), e então publicam este grupo de transações junto com a Proof Of Work (PoW) como um ***bloco*** para o resto da rede da rede. Uma vez que o nó resolveu o PoW, os outros nós param de tentar resolver o PoW, verificam que a lista de transações do outro nó são válidas, e então aceitam o bloco e começam a tentar resolver o próximo bloco. @@ -256,7 +256,7 @@ Se estivéssemos rodando um nó da rede, eu poderia publicar uma transação **s ## Então como podemos gerar número aleatórios de forma segura em Ethereum? -Por que todos os conteúdos da blockchain são visíveis para todos os participantes, este é um problema difícil, e sua solução esta além do escopo deste tutorial. Você pode ler esta pergunta no StackOverflow para ter algumas ideias. Uma ideia seria usar um **_oracle_** (oráculo) para acessar uma função de número aleatório de fora da blockchain do Ethereum. +Por que todos os conteúdos da blockchain são visíveis para todos os participantes, este é um problema difícil, e sua solução esta além do escopo deste tutorial. Você pode ler esta pergunta no StackOverflow para ter algumas ideias. Uma ideia seria usar um ***oracle*** (oráculo) para acessar uma função de número aleatório de fora da blockchain do Ethereum. Claro que uma vez que milhares de nós na rede Ethereum estão competindo para resolver o próximo bloco, minhas chances de resolver o próximo bloco são extremamente baixas. E iria me tomar um monte de tempo ou recursos computacionais para tornar esse _exploit_ lucrativo - mas se as recompensas fossem altas o suficiente (algo do tipo ganhar uma aposta de $100,000,000 no jogo da moeda), então valeria a pena pra mim fazer este ataque. @@ -264,7 +264,7 @@ Então enquanto esta geração de número aleatório NÃO é segura no Ethereum, E por que estamos construindo um jogo simples com o propósito de demonstração neste tutorial e por que não há real dinheiro envolvido, vamos aceitar esse _tradeoff_ de usar um gerador de números aleatórios que é simples de implementar, sabendo que não é totalmente seguro. -Em lições futuras, talvez podemos cobrir os **_oracles_** (uma forma segura de obter dados fora da rede do Ethereum) para gerar números aleatórios seguros fora da blockchain. +Em lições futuras, talvez podemos cobrir os ***oracles*** (uma forma segura de obter dados fora da rede do Ethereum) para gerar números aleatórios seguros fora da blockchain. ## Vamos testar diff --git a/pt/4/battle-08.md b/pt/4/battle-08.md index 70f45bce79..982da583dc 100644 --- a/pt/4/battle-08.md +++ b/pt/4/battle-08.md @@ -246,7 +246,7 @@ No capítulo 6 nós calculamos um número aleatório entre 0 e 100. Agora vamos ## Vamos testar -1. Crie uma declaração `if` que verifica se `rand` é **_menor que ou igual a_** `attackVictoryProbability`. +1. Crie uma declaração `if` que verifica se `rand` é ***menor que ou igual a*** `attackVictoryProbability`. 2. Se esta condição for verdadeira, nosso zumbi venceu! Então: diff --git a/pt/4/payable.md b/pt/4/payable.md index 7e28b51fa8..c3b4387d4e 100644 --- a/pt/4/payable.md +++ b/pt/4/payable.md @@ -229,7 +229,7 @@ material: } --- -Até agora, nós cobrimos algumas **_funções modificadoras_**. Pode até ser difícil tentar lembrar de tudo, então vamos para uma rápida revisão: +Até agora, nós cobrimos algumas ***funções modificadoras***. Pode até ser difícil tentar lembrar de tudo, então vamos para uma rápida revisão: 1. Temos os modificadores de visibilidade que controlam quando em onde a função pode ser chamada: `private` significa que somente pode ser chamada de outras funções dentro do contrato; `internal` é como `private` mas também pode ser chamada por contratos que herdaram este contrato; `external` pode ser chamada somente de fora do contrato; e finalmente `public` que pode ser chamada de qualquer lugar, tanto internamente quando externamente. diff --git a/pt/5/01-erc721-1.md b/pt/5/01-erc721-1.md index fe2797f165..5e36f795ce 100644 --- a/pt/5/01-erc721-1.md +++ b/pt/5/01-erc721-1.md @@ -242,11 +242,11 @@ material: } --- -Vamos falar sobre **_tokens_**. +Vamos falar sobre ***tokens***. -Se você esteve acompanhando o Ethereum por período de tempo, você provavelmente ouviu pessoas falando sobre tokens - especificamente **_ERC20 tokens_**. +Se você esteve acompanhando o Ethereum por período de tempo, você provavelmente ouviu pessoas falando sobre tokens - especificamente ***ERC20 tokens***. -Um **_token_** no Ethereum é basicamente um smart contract (contrato inteligente) que segue algumas regras comuns — isto é, ele implementa um conjunto padrão de funções que todos os outros contratos de token compartilham, como o `transfer(address _to, uint256 _value)` e `balanceOf(address _owner)`. +Um ***token*** no Ethereum é basicamente um smart contract (contrato inteligente) que segue algumas regras comuns — isto é, ele implementa um conjunto padrão de funções que todos os outros contratos de token compartilham, como o `transfer(address _to, uint256 _value)` e `balanceOf(address _owner)`. Internamente o smart contract normalmente tem um mapeamento, `mapping(address => uint256) balances`, que mantêm o registro de quanto em saldo cada endereço tem. @@ -270,9 +270,9 @@ Primeiro, zumbis não são divisíveis como moedas — Eu posso enviar para voc Segundo, todos os zumbis não são criados iguais. Seu zumbi Nível 2 "**Steve**" é totalmente diferente do meu zumbi Nível 732 "**H4XF13LD MORRIS 💯💯😎💯💯**". (Nem mesmo perto, *Steve*). -Há um outro padrão de token que se encaixa bem melhor para cripto-colecionáveis como CryptoZombies – e eles chamados de **_tokens ERC721._** +Há um outro padrão de token que se encaixa bem melhor para cripto-colecionáveis como CryptoZombies – e eles chamados de ***tokens ERC721.*** -**Tokens ERC721_** **não** são intercambiáveis uma vez que cada um é suposto para ser único, e não divisíveis. Você somente pode trocá-los em unidades inteiras, e cada um tem um ID único. Então esses se encaixam perfeitamente para fazer nossos zumbis trocáveis. +**Tokens ERC721*** **não** são intercambiáveis uma vez que cada um é suposto para ser único, e não divisíveis. Você somente pode trocá-los em unidades inteiras, e cada um tem um ID único. Então esses se encaixam perfeitamente para fazer nossos zumbis trocáveis. > Note que usando um padrão como ERC721 tem o benefício que não precisamos ter que implementar uma lógica de leilão ou garantia dentro do nosso contrato que determina como os jogadores devem trocar / vender nossos zumbis. Se obedecer-mos a especificação, qualquer um poderia criar uma plataforma de troca para ativos cripto-colecionáveis ERC721, e nossos zumbis ERC721 seriam utilizáveis nesta plataforma. Então os benefícios são claros de usar um padrão de token ao invés de criar a sua própria lógica de trocas. diff --git a/pt/5/09-safemath-1.md b/pt/5/09-safemath-1.md index fdbe2dafe6..ad9c8289f9 100644 --- a/pt/5/09-safemath-1.md +++ b/pt/5/09-safemath-1.md @@ -396,7 +396,7 @@ Mas queremos manter esta lição manejável, então fomos com a lógica de imple Vamos olhar para um dos principais recursos de segurança que você deve estar ciente ao escrever smart contracts: Prevenção de overflows e underflows. -O que é um **_overflow_** (transbordamento) ? +O que é um ***overflow*** (transbordamento) ? Digamos que você tem um `uint8`, que pode ter somente 8 bits. Isso significa que o maior número que podemos guardar é o binário `11111111` (ou um decimal, 2^8 - 1 = 255). @@ -415,11 +415,11 @@ Enquanto não usamos `uint8` aqui, parece improvável que o `uint256` irá trans ### Usando SafeMath -Para prevenir isto, OpenZeppelin criou uma **_library_** (biblioteca) chamada SafeMath que previne estes erros por padrão. +Para prevenir isto, OpenZeppelin criou uma ***library*** (biblioteca) chamada SafeMath que previne estes erros por padrão. Mas antes de disso... O que é uma biblioteca? -Uma **_biblioteca_** é tipo especial de contrato em Solidity. Uma das coisas que são úteis para anexar funções em tipos de dados nativos. +Uma ***biblioteca*** é tipo especial de contrato em Solidity. Uma das coisas que são úteis para anexar funções em tipos de dados nativos. Por exemplo, como a biblioteca SafeMath, podemos usar a sintaxe `using SafeMath for uint256`. A biblioteca SafeMath tem 4 funções – `add` (adição), `sub` (subtração), `mul` (multiplicação) e `div` (divisão). E como nós podemos acessar essas funções de `uint256` conforme segue: diff --git a/pt/5/13-comments.md b/pt/5/13-comments.md index 47447ebc0e..eea211fab1 100644 --- a/pt/5/13-comments.md +++ b/pt/5/13-comments.md @@ -423,7 +423,7 @@ contract CryptoZombies { Em particular, é uma boa prática comentar o seu código para explicar o comportamento esperado de cada função em seu contrato. Desta maneira outro desenvolvedor (ou você, após seis meses de hiato de um projeto!) pode rapidamente ler e entender em alto nível o que seu código faz sem ter que ler o próprio código. -O padrão na comunidade Solidity é usar o formato chamado **_natspec_**, que se parece com isso: +O padrão na comunidade Solidity é usar o formato chamado ***natspec***, que se parece com isso: ``` /// @title Um contrato para operações básicas de matemática diff --git a/pt/5/14-wrappingitup.md b/pt/5/14-wrappingitup.md index 1b9f61e4ba..4cc07bba41 100644 --- a/pt/5/14-wrappingitup.md +++ b/pt/5/14-wrappingitup.md @@ -33,6 +33,6 @@ Nesta lição aprendemos sobre: Esta lição conclui o código do nosso jogo em Solidity! (No momento – podemos adicionar ainda mais lições no futuro). -Nas próximas duas lições, iremos ver como em como implantar os seus contratos e interagir com eles usando **_web3.j_** (então você pode criar um front-end para a sua DApp). +Nas próximas duas lições, iremos ver como em como implantar os seus contratos e interagir com eles usando ***web3.j*** (então você pode criar um front-end para a sua DApp). Vá em frente e renomeie qualquer um dos seus zumbis se você quiser, então siga para o próximo capítulo para completar a lição. diff --git a/pt/6/01-intro-web3.md b/pt/6/01-intro-web3.md index 18f6628c70..8b5241ce8b 100644 --- a/pt/6/01-intro-web3.md +++ b/pt/6/01-intro-web3.md @@ -365,7 +365,7 @@ material: Ao completar a Lição 5, nosso DApp zumbi está completo. Agora vamos criar uma página web básica onde seus usuários podem interagir com ela. -Para fazer isso, vamos usar uma biblioteca JavaScript da Fundação Ethereum chamada **_Web3.js_**. +Para fazer isso, vamos usar uma biblioteca JavaScript da Fundação Ethereum chamada ***Web3.js***. ## O que é Web3.js? @@ -375,7 +375,7 @@ Lembre-se, a rede Ethereum é composta de nós, cada um contendo uma cópia do b 2. A função que você deseja chamar, e 3. As variáveis que você deseja passar para essa função. -Os nós do Ethereum só falam uma linguagem chamada **_JSON-RPC_**, que não é muito legível por humanos. Uma consulta para informar ao nó que você deseja chamar uma função em um contrato é algo como isto: +Os nós do Ethereum só falam uma linguagem chamada ***JSON-RPC***, que não é muito legível por humanos. Uma consulta para informar ao nó que você deseja chamar uma função em um contrato é algo como isto: ``` // É... Boa sorte escrevendo toda a sua chamada de função desta maneira! diff --git a/pt/6/02-web3-providers.md b/pt/6/02-web3-providers.md index 41296076a4..9ddc9f7775 100644 --- a/pt/6/02-web3-providers.md +++ b/pt/6/02-web3-providers.md @@ -386,11 +386,11 @@ material: Ótimo! Agora que temos o Web3.js em nosso projeto, vamos inicializá-lo e conversar com o blockchain. -A primeira coisa que precisamos é de um **_Web3 Provider_**. +A primeira coisa que precisamos é de um ***Web3 Provider***. -Lembre-se, o Ethereum é composto de **_nodes_** (nós) que compartilham uma cópia dos mesmos dados. Definir um provedor Web3 em Web3.js informa ao nosso código **em que nó** devemos falar para lidar com nossas leituras e escritas. É como definir a URL do servidor da Web remoto para suas chamadas de API em um aplicativo da web tradicional. +Lembre-se, o Ethereum é composto de ***nodes*** (nós) que compartilham uma cópia dos mesmos dados. Definir um provedor Web3 em Web3.js informa ao nosso código **em que nó** devemos falar para lidar com nossas leituras e escritas. É como definir a URL do servidor da Web remoto para suas chamadas de API em um aplicativo da web tradicional. -Você poderia hospedar seu próprio nó Ethereum como um provedor. No entanto, há um serviço de terceiros que facilita a sua vida, para que você não precise manter seu próprio nó Ethereum para fornecer um DApp para seus usuários — **_Infura_**. +Você poderia hospedar seu próprio nó Ethereum como um provedor. No entanto, há um serviço de terceiros que facilita a sua vida, para que você não precise manter seu próprio nó Ethereum para fornecer um DApp para seus usuários — ***Infura***. ## Infura @@ -408,7 +408,7 @@ No entanto, como o DApp será usado por muitos usuários — e esses usuários v A criptografia é complicada, portanto, a menos que você seja um especialista em segurança e realmente saiba o que está fazendo, provavelmente não é uma boa ideia tentar gerenciar as chaves privadas dos usuários no front-end de nosso aplicativo. -Mas, felizmente, você não precisa — já existem serviços que lidam com isso para você. O mais popular deles é **_Metamask_**. +Mas, felizmente, você não precisa — já existem serviços que lidam com isso para você. O mais popular deles é ***Metamask***. ## Metamask diff --git a/pt/6/03-talking-to-contracts.md b/pt/6/03-talking-to-contracts.md index 3b05d50b6b..2bd9b6d74e 100644 --- a/pt/6/03-talking-to-contracts.md +++ b/pt/6/03-talking-to-contracts.md @@ -864,7 +864,7 @@ material: Agora que inicializamos o Web3.js com o provedor Web3 da MetaMask, vamos configurá-lo para conversar com nosso smart contract. -O Web3.js precisará de duas coisas para conversar com seu contrato: o **_endereço_** e o **_ABI_**. +O Web3.js precisará de duas coisas para conversar com seu contrato: o ***endereço*** e o ***ABI***. ## Endereço do contrato @@ -876,7 +876,7 @@ Você precisará copiar esse endereço após a implantação para conversar com ## Contrato ABI -A outra coisa que o Web3.js precisará para falar com o seu contrato é o seu **_ABI_**. +A outra coisa que o Web3.js precisará para falar com o seu contrato é o seu ***ABI***. ABI significa Application Binary Interface (Interface Binária da Aplicação). Basicamente, é uma representação dos métodos de seus contratos no formato JSON que informa ao Web3.js como formatar chamadas de função de uma maneira que seu contrato entenderá. diff --git a/pt/7/02.md b/pt/7/02.md index 45d5250b02..d820b6c2f9 100644 --- a/pt/7/02.md +++ b/pt/7/02.md @@ -483,7 +483,7 @@ Nós abstraímos isso em uma biblioteca, então você não precisará colocar a ### "Hooks" — o coração de cada modo de jogo personalizado -A primeira etapa para cada modo de jogo personalizado é implementar pelo menos um **_hook_**. +A primeira etapa para cada modo de jogo personalizado é implementar pelo menos um ***hook***. Basicamente, a lógica principal do jogo procurará e chamará certas funções de seu contrato em certas partes do jogo, se elas existirem em seu código. diff --git a/ru/1/arrays.md b/ru/1/arrays.md index c803136c07..fb411723cb 100644 --- a/ru/1/arrays.md +++ b/ru/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -Если нужен список из похожих элементов, подойдет **_массив_**. В Solidity есть два типа массивов: **_фиксированный_** и **_динамический_**: +Если нужен список из похожих элементов, подойдет ***массив***. В Solidity есть два типа массивов: ***фиксированный*** и ***динамический***: ``` // Массив фиксированной длины из 2 элементов: @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -Ты можешь создать массив из **_структур_**. Возьми структуру `Person` из предыдущей части: +Ты можешь создать массив из ***структур***. Возьми структуру `Person` из предыдущей части: ``` Person[] people; // Динамический массив позволяет добавлять в него данные @@ -60,7 +60,7 @@ Person[] people; // Динамический массив позволяет д ## Открытые массивы -Можно задать массив как `public` (открытый), и Solidity автоматически создаст для него **_геттер_** (способ получения). Синтаксис: +Можно задать массив как `public` (открытый), и Solidity автоматически создаст для него ***геттер*** (способ получения). Синтаксис: ``` Person[] public people; @@ -72,4 +72,4 @@ Person[] public people; Армию зомби надо где-то разместить. Мы хотим, чтобы другие приложения видели зомби, поэтому сделаем массив открытым. -1. Создай открытый массив **_структур_** `Zombie` и назови его `zombies`. +1. Создай открытый массив ***структур*** `Zombie` и назови его `zombies`. diff --git a/ru/1/datatypes.md b/ru/1/datatypes.md index bf1ef0487e..08dd3c07dd 100644 --- a/ru/1/datatypes.md +++ b/ru/1/datatypes.md @@ -25,7 +25,7 @@ material: Отличная работа! Теперь, когда у нас есть оболочка контракта, мы можем изучить, как Solidity работает с переменными. -**_Переменные состояния_** записываются в хранилище контракта. Это означает, что они сохраняются в блокчейне Ethereum, как в базе данных. +***Переменные состояния*** записываются в хранилище контракта. Это означает, что они сохраняются в блокчейне Ethereum, как в базе данных. ##### Пример: ``` diff --git a/ru/1/events.md b/ru/1/events.md index c8349b286d..50672f3dc2 100644 --- a/ru/1/events.md +++ b/ru/1/events.md @@ -73,9 +73,9 @@ material: } --- -Наш контракт почти готов! Осталось добавить **_событие_**. +Наш контракт почти готов! Осталось добавить ***событие***. -**_Событие_** — это способ, которым контракт сообщает внешнему интерфейсу приложения, что в блокчейне произошло некое событие. Интерфейс может «услышать» определенные события и выполнить заданное действие по его наступлении. +***Событие*** — это способ, которым контракт сообщает внешнему интерфейсу приложения, что в блокчейне произошло некое событие. Интерфейс может «услышать» определенные события и выполнить заданное действие по его наступлении. Пример: diff --git a/ru/1/functions3.md b/ru/1/functions3.md index 9c6fbccb43..39352b0727 100644 --- a/ru/1/functions3.md +++ b/ru/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -В этом разделе мы изучим функцию **_вернуть значение_** и ее модификаторы. +В этом разделе мы изучим функцию ***вернуть значение*** и ее модификаторы. ## Вернуть значение @@ -73,13 +73,13 @@ function sayHello() public returns (string) { Рассмотренная выше функция не модифицирует свое состояние — не изменяет значения и не переписывает что-либо. -Поэтому в данном случае мы можем задать функцию **_просмотр_** – просмотр данных без их изменения: +Поэтому в данном случае мы можем задать функцию ***просмотр*** – просмотр данных без их изменения: ``` function sayHello() public view returns (string) { ``` -Еще в Solidity есть **_чистые_** функции — ты не получишь доступ к данным в приложении. Рассмотрим пример: +Еще в Solidity есть ***чистые*** функции — ты не получишь доступ к данным в приложении. Рассмотрим пример: ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -Функция даже не читает состояние приложения - она возвращает значение, которое зависит только от параметров самой функции. В этом случае мы задаем функцию как **_pure_**. +Функция даже не читает состояние приложения - она возвращает значение, которое зависит только от параметров самой функции. В этом случае мы задаем функцию как ***pure***. > Примечание: не всегда легко вспомнить, когда задать «чистую» функцию или «просмотр». К счастью, компилятор Solidity исправно выдает предупреждения, что нужно использовать тот или иной модификатор. diff --git a/ru/1/lessoncomplete.md b/ru/1/lessoncomplete.md index 1721ef76dc..fdb3eec3c4 100644 --- a/ru/1/lessoncomplete.md +++ b/ru/1/lessoncomplete.md @@ -14,8 +14,8 @@ material: ### 1. Войди, чтобы сохранить прогресс -**_Войди_** и нажми «Сохранить прогресс» вверху страницы. Как только появится новый урок, мы сразу дадим тебе знать. +***Войди*** и нажми «Сохранить прогресс» вверху страницы. Как только появится новый урок, мы сразу дадим тебе знать. ### 2. Поделись зомби с друзьями -**_Поделиться_** зомби в Твитере и все такое (Вставить изображение / ссылку) +***Поделиться*** зомби в Твитере и все такое (Вставить изображение / ссылку) diff --git a/ru/1/math.md b/ru/1/math.md index 64bcebbd2e..a3c51e5016 100644 --- a/ru/1/math.md +++ b/ru/1/math.md @@ -34,7 +34,7 @@ material: * Деление: `x / y` * Модуль и остаток от деления: `x % y` _(например, `13 % 5` будет равно `3`, если разделить 13 на 5, в остатке 3)_ -Solidity поддерживает экспоненциальные операции **_exponential operator_** — возведение в степень (например "x в степени y", x^y): +Solidity поддерживает экспоненциальные операции ***exponential operator*** — возведение в степень (например "x в степени y", x^y): ``` uint x = 5 ** 2; // 5 в квадрате = 25 diff --git a/ru/1/structs.md b/ru/1/structs.md index 55f0fa2890..4afa80502c 100644 --- a/ru/1/structs.md +++ b/ru/1/structs.md @@ -32,7 +32,7 @@ material: } --- -Часто нужны более сложные типы данных. Для этого в Solidity есть **_structs_** (структуры): +Часто нужны более сложные типы данных. Для этого в Solidity есть ***structs*** (структуры): ``` struct Person { diff --git a/ru/1/web3js.md b/ru/1/web3js.md index f039bcc56e..0e024fd7c8 100644 --- a/ru/1/web3js.md +++ b/ru/1/web3js.md @@ -12,7 +12,7 @@ material: Наш контракт Solidity готов! Теперь напишем внешний интерфейс JavaScript, который будет взаимодействовать с контрактом. -В Ethereum есть библиотека JavaScript под названием **_Web3.js_**. +В Ethereum есть библиотека JavaScript под названием ***Web3.js***. В следующем уроке мы подробно изучим, как развернуть контракт и настроить Web3.js. А сейчас просто посмотрим, как Web3.js будет взаимодействовать с развернутым контрактом. diff --git a/ru/2/10-interactingcontracts.md b/ru/2/10-interactingcontracts.md index 387b28de0d..9612740037 100644 --- a/ru/2/10-interactingcontracts.md +++ b/ru/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ material: ## Взаимодействие с другими контрактами -Чтобы наш контракт связался с другим контрактом в блокчейне, которым владеем не мы, сначала нужно определить **_интерфейс_**. +Чтобы наш контракт связался с другим контрактом в блокчейне, которым владеем не мы, сначала нужно определить ***интерфейс***. Посмотрим простой пример. Допустим, в блокчейне существует такой контракт: @@ -131,7 +131,7 @@ contract LuckyNumber { Теперь допустим, что у нас есть другой внешний контракт, который хочет считать данные в этом контракте, используя функцию `getNum`. -Сначала нам надо будет определить **_интерфейс_** контракта `LuckyNumber` (счастливый номер): +Сначала нам надо будет определить ***интерфейс*** контракта `LuckyNumber` (счастливый номер): ``` contract NumberInterface { diff --git a/ru/2/2-mappings.md b/ru/2/2-mappings.md index c5ee8f5cf7..15c86feb1a 100644 --- a/ru/2/2-mappings.md +++ b/ru/2/2-mappings.md @@ -84,7 +84,7 @@ material: ## Адреса -Блокчейн Ethereum состоит из **_аккаунтов_** (счетов), вроде банковских. На аккаунте находится баланс **_Эфира_** (криптовалюты блокчейна Ethereum). Ты можешь отправлять и получать платежи в Эфире на другие счета, также как ты переводишь деньги со своего банковского счета на счета других людей. +Блокчейн Ethereum состоит из ***аккаунтов*** (счетов), вроде банковских. На аккаунте находится баланс ***Эфира*** (криптовалюты блокчейна Ethereum). Ты можешь отправлять и получать платежи в Эфире на другие счета, также как ты переводишь деньги со своего банковского счета на счета других людей. У каждого счета есть `address` (адрес), наподобие номера банковского счета. Это уникальный идентификатор счета, который выглядит так: @@ -98,7 +98,7 @@ material: ## Соответствия -В первом уроке мы рассмотрели **_структуры_** и **_массивы_**. **_Соответствия_** — это еще один способ хранения упорядоченных данных в Solidity. +В первом уроке мы рассмотрели ***структуры*** и ***массивы***. ***Соответствия*** — это еще один способ хранения упорядоченных данных в Solidity. Определение `mapping` (соответствий) выглядит как-то так: diff --git a/ru/2/5-inheritance.md b/ru/2/5-inheritance.md index 459c082adf..0fbbeed62e 100644 --- a/ru/2/5-inheritance.md +++ b/ru/2/5-inheritance.md @@ -95,7 +95,7 @@ material: Код уже довольно длинный! Чтобы не делать один длиннющий контракт и организовать код, можно разбить логику кода на несколько контрактов. -В Solidity есть фича, которая помогает управлять длинными контрактами — **_наследование_**: +В Solidity есть фича, которая помогает управлять длинными контрактами — ***наследование***: ``` contract Doge { @@ -111,7 +111,7 @@ contract BabyDoge is Doge { } ``` -`BabyDoge` (щенок) **_наследует_** `Doge` (Псу!). Если ты скомпилируешь и развернешь `BabyDoge`, он получит доступ и к `catchphrase()` и к `anotherCatchphrase()` (и ко всем остальным открытым функциям, которые мы опишем в `Doge`). +`BabyDoge` (щенок) ***наследует*** `Doge` (Псу!). Если ты скомпилируешь и развернешь `BabyDoge`, он получит доступ и к `catchphrase()` и к `anotherCatchphrase()` (и ко всем остальным открытым функциям, которые мы опишем в `Doge`). Это можно использовать для логического наследования (как с подтипами, `Cat` (кошка) это `Animal` (животное)), или для простой организации кода, группируя вместе одинаковую логику внутри различных классов. diff --git a/ru/2/7-storage.md b/ru/2/7-storage.md index 9c8c60c3af..75e04deb6d 100644 --- a/ru/2/7-storage.md +++ b/ru/2/7-storage.md @@ -71,11 +71,11 @@ material: В Solidity есть два места, где могут сохраняться переменные: в `storage` (хранилище) и в `memory` (памяти). -**_Хранилище_** используют, чтобы сохранить переменные в блокчейн навсегда. **_Память_** используют для временного хранения переменных, они стираются в промежутках, когда внешняя функция обращается к контракту. Это похоже на жесткий диск компьютера и оперативную память. +***Хранилище*** используют, чтобы сохранить переменные в блокчейн навсегда. ***Память*** используют для временного хранения переменных, они стираются в промежутках, когда внешняя функция обращается к контракту. Это похоже на жесткий диск компьютера и оперативную память. В большинстве случаев тебе не придется использовать ключевые слова, потому что Solidity определяет по умолчанию, что куда сохранять. Переменные состояния (заданные вне функции) по умолчанию хранятся записанными в блокчейне. Переменные, заданные внутри функции, пишутся в память и исчезнут, как только вызов функции закончится. -Тем не менее, есть случаи, когда обязательно надо указывать ключевые слова, а именно когда ты работаешь со **_структурами_** и **_массивами_** в пределах функции: +Тем не менее, есть случаи, когда обязательно надо указывать ключевые слова, а именно когда ты работаешь со ***структурами*** и ***массивами*** в пределах функции: ``` contract SandwichFactory { diff --git a/ru/3/01-externaldependencies.md b/ru/3/01-externaldependencies.md index 1acdd7f6e5..46587de8a8 100644 --- a/ru/3/01-externaldependencies.md +++ b/ru/3/01-externaldependencies.md @@ -143,7 +143,7 @@ material: До сих пор Solidity был похож на другие языки программирования, например на JavaScript. Но у Ethereum DApps есть несколько важных отличий от обычных приложений. -Первое — после развертывания на Ethereum контракта он становится **_неизменяемым_**. Это значит, что он никогда не сможет быть модифицирован или обновлен. +Первое — после развертывания на Ethereum контракта он становится ***неизменяемым***. Это значит, что он никогда не сможет быть модифицирован или обновлен. Первоначально развернутый в контракте код останется в блокчейне навсегда. Это одна из самых неприятных проблем с безопасностью в Solidity. Если в коде контракта есть недостаток, позже его не удастся исправить. Тебе придется убедить пользователей перейти на исправленный адрес смарт-контракта. diff --git a/ru/3/02-ownable.md b/ru/3/02-ownable.md index 933f47c58f..7c4e78999e 100644 --- a/ru/3/02-ownable.md +++ b/ru/3/02-ownable.md @@ -189,7 +189,7 @@ material: ## Собственный контракт OpenZeppelin -Ниже пример `Ownable` контракта из библиотеки Solidity **_OpenZeppelin_**. OpenZeppelin - это библиотека безопасных смарт-контрактов сообщества, которыми можно пользоваться для личных DApps. Пока ты будешь ждать Урока 4, посмотри библиотеки на этом сайте. Поможет в дальнейшем. +Ниже пример `Ownable` контракта из библиотеки Solidity ***OpenZeppelin***. OpenZeppelin - это библиотека безопасных смарт-контрактов сообщества, которыми можно пользоваться для личных DApps. Пока ты будешь ждать Урока 4, посмотри библиотеки на этом сайте. Поможет в дальнейшем. Прочитай контракт ниже. Ты увидишь несколько неизученных моментов, не волнуйся, сейчас мы поговорим о них. @@ -233,7 +233,7 @@ contract Ownable { Вот что мы не видели раньше: -- Конструкторы: `function Ownable()` это **_конструктор_**, особая опциональная функция с таким же именем, как контракт. Выполняется только один раз в момент создания контракта. +- Конструкторы: `function Ownable()` это ***конструктор***, особая опциональная функция с таким же именем, как контракт. Выполняется только один раз в момент создания контракта. - Модификаторы функции: `modifier onlyOwner()`. Модификаторы — полуфункции, которые используются для изменения других функций, обычно для проверки некоторых требований до их выполнения. В этом случае `onlyOwner` можно использовать для ограничения доступа, чтобы **только владелец** контракта мог запустить эту функцию. В следующей главе мы подробно поговорим о модификаторах функций, а также о странном `_;` и его назначении. - Ключевое слово `indexed`: пока не нужно, об этом потом. diff --git a/ru/3/04-gas.md b/ru/3/04-gas.md index 10dc772d2b..eef2ee521d 100644 --- a/ru/3/04-gas.md +++ b/ru/3/04-gas.md @@ -185,9 +185,9 @@ material: ## Газ — топливо для DApps на Ethereum -В Solidity пользователи должны заплатить за каждый вызов функции DApp с помощью валюты под названием **_газ_**. Газ покупают вместе с эфиром, валютой Ethereum. Следовательно, пользователи расходуют ETH, чтобы выполнить функцию в приложении DApp. +В Solidity пользователи должны заплатить за каждый вызов функции DApp с помощью валюты под названием ***газ***. Газ покупают вместе с эфиром, валютой Ethereum. Следовательно, пользователи расходуют ETH, чтобы выполнить функцию в приложении DApp. -Количество газа для запуска зависит от сложности логики функции. У любой операции есть **_цена газа_**, она вычисляется, исходя на количестве вычислительных ресурсов, необходимых для выполнения операции (например, запись в хранилище намного дороже, чем добавление двух целых чисел). Общая **_стоимость газа_** функции - сумма затрат газа на все операции. +Количество газа для запуска зависит от сложности логики функции. У любой операции есть ***цена газа***, она вычисляется, исходя на количестве вычислительных ресурсов, необходимых для выполнения операции (например, запись в хранилище намного дороже, чем добавление двух целых чисел). Общая ***стоимость газа*** функции - сумма затрат газа на все операции. Поскольку запуск функций стоит пользователям реальных денег, оптимизация кода в Ethereum гораздо важнее, чем в других языках программирования. Если код написан небрежно, а пользователям придется платить за выполнение функций, в пересчете на тысячи пользователей это может означать миллионы долларов ненужных комиссий. diff --git a/ru/4/battle-02.md b/ru/4/battle-02.md index 11f32d04ce..ab4228410d 100644 --- a/ru/4/battle-02.md +++ b/ru/4/battle-02.md @@ -248,7 +248,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; ### Этот метод уязвим перед типом атаки, известным как «нечестная нода» -Когда ты вызываешь функцию в контракте Ethereum, то транслируешь ее ноде или нодам в сети как **_транзакцию_**. Ноды в сети собирают много транзакций вместе и стараются первыми найти решение сложной математической задачи, чтобы получить «Доказательство работы». Затем они публикуют в сети эту группу транзакций и доказательство работы (PoW) как **_блок_**. +Когда ты вызываешь функцию в контракте Ethereum, то транслируешь ее ноде или нодам в сети как ***транзакцию***. Ноды в сети собирают много транзакций вместе и стараются первыми найти решение сложной математической задачи, чтобы получить «Доказательство работы». Затем они публикуют в сети эту группу транзакций и доказательство работы (PoW) как ***блок***. Как только нода решила задачу и получила PoW, другие ноды перестают решать эту задачу, проверяют валидность списка транзакций решившей ноды, принимают блок и включают его в блокчейн. Затем приступают к поиску решения задачи для следующего блока. @@ -260,7 +260,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; ## Как же решить проблему безопасной генерации случайных чисел в Ethereum? -Поскольку содержимое блокчейна видно всем участникам, это нелегкая задача, и ее решение выходит за рамки данного руководства. Для вдохновения почитай тему на StackOverflow. Одна из идей — использовать **_оракул_** для доступа к функции генерации случайных чисел извне блокчейна Ethereum. +Поскольку содержимое блокчейна видно всем участникам, это нелегкая задача, и ее решение выходит за рамки данного руководства. Для вдохновения почитай тему на StackOverflow. Одна из идей — использовать ***оракул*** для доступа к функции генерации случайных чисел извне блокчейна Ethereum. Разумеется, в условиях десятков тысяч конкурирующих за блок нод в сети Ethereum, шансы на нахождение ответа следующего блока крайне низки. Нужно много времени и вычислительных ресурсов, чтобы воспользоваться уязвимостью - но если вознаграждение было бы достаточно высоким (например, если можно выиграть 100 000 000 долларов в орел-решку), то атаковать целесообразно. diff --git a/ru/4/battle-08.md b/ru/4/battle-08.md index 129e4c1250..b905189d28 100644 --- a/ru/4/battle-08.md +++ b/ru/4/battle-08.md @@ -248,7 +248,7 @@ material: ## Проверь себя -1. Создай оператор `if`, который проверяет `rand` **_меньше или равно_** `attackVictoryProbability`. +1. Создай оператор `if`, который проверяет `rand` ***меньше или равно*** `attackVictoryProbability`. 2. Если условие верно, то твой зомби побеждает! Итак: diff --git a/ru/4/payable.md b/ru/4/payable.md index c56dd5d336..6350605d16 100644 --- a/ru/4/payable.md +++ b/ru/4/payable.md @@ -229,7 +229,7 @@ material: } --- -Мы уже видели множество **_модификаторов функций_**. Сложно сразу все запомнить, поэтому проведем быстрый обзор: +Мы уже видели множество ***модификаторов функций***. Сложно сразу все запомнить, поэтому проведем быстрый обзор: 1. Модификаторы видимости контролируют вызов функции: `private` означает, что функцию могут вызвать другие функции только внутри контракта; `internal` похожа на `private`, но ее помимо функций внутри контракта могут вызывать те, которые наследуют ей; `external` может быть вызвана только извне контракта; и, наконец, `public` функцию можно вызвать откуда угодно — изнутри и извне. diff --git a/ru/5/01-erc721-1.md b/ru/5/01-erc721-1.md index 8b40b18732..a7cba22f16 100644 --- a/ru/5/01-erc721-1.md +++ b/ru/5/01-erc721-1.md @@ -284,11 +284,11 @@ material: } --- -Давайте поговорим про **_токены_**. +Давайте поговорим про ***токены***. -Если вы были в окружении Ethereum какое-то время, вы, вероятно, слышали, как люди говорят о токенах — особенно **_ERC20 токенах_**. +Если вы были в окружении Ethereum какое-то время, вы, вероятно, слышали, как люди говорят о токенах — особенно ***ERC20 токенах***. -**_Токены_** на Ethereum это просто умный контракт, который следует некоторым общим правилам, а именно реализует стандартный набор функций, которые наследуют все остальные контракты токенов, такие как `transferFrom(address _from, address _to, uint256 _tokenId)` и `balanceOf(address _owner)`. +***Токены*** на Ethereum это просто умный контракт, который следует некоторым общим правилам, а именно реализует стандартный набор функций, которые наследуют все остальные контракты токенов, такие как `transferFrom(address _from, address _to, uint256 _tokenId)` и `balanceOf(address _owner)`. Внутри умный контракт обычно содержит соответствие, `mapping(address => uint256) balances`, которое отслеживает баланс каждого адреса. @@ -312,9 +312,9 @@ ERC20 токены действительно хороши для токенов Во-вторых, не все зомби созданы равными. Ваш зомби 2 уровня "**Стив**" совершенно не равен моему зомби 732 уровня "**H4XF13LD Моррис 💯💯😎💯💯**". (Даже не близко, *Стив*). -Существует еще один стандарт токенов, который гораздо лучше подходит для крипто-коллекционирования, таких как КриптоЗомби — и они называются **_ERC721 токены._** +Существует еще один стандарт токенов, который гораздо лучше подходит для крипто-коллекционирования, таких как КриптоЗомби — и они называются ***ERC721 токены.*** -**_ERC721 токены** **не** взаимозаменяемы, поскольку каждый из них считается уникальным и не делимым. Вы можете обменять их только как одно целое, и каждый из них имеет уникальный идентификатор. Так что они идеально подходят для того, чтобы сделать наших зомби удобными для обмена. +***ERC721 токены** **не** взаимозаменяемы, поскольку каждый из них считается уникальным и не делимым. Вы можете обменять их только как одно целое, и каждый из них имеет уникальный идентификатор. Так что они идеально подходят для того, чтобы сделать наших зомби удобными для обмена. > Обратите внимание, что использование такого стандарта, как ERC721, имеет то преимущество, что нам не нужно реализовывать логику аукциона или условного депонирования (escrow) в нашем контракте, определяющую, как игроки могут обменивать / продавать наших зомби. Если мы будем соответствовать спецификации, кто-то другой может создать платформу обмена для крипто-обменных активов ERC721, и наши зомби ERC721 будут использоваться на этой платформе. Таким образом, есть явные преимущества использования стандарта токенов вместо реализации собственной логики для торговли. diff --git a/ru/5/09-safemath-1.md b/ru/5/09-safemath-1.md index 366728e959..f0c5491bc3 100644 --- a/ru/5/09-safemath-1.md +++ b/ru/5/09-safemath-1.md @@ -429,7 +429,7 @@ material: Мы рассмотрим одну из основных функций безопасности, о которой вам следует знать при написании смарт-контрактов: предотвращение переполнений и потери значимости. -Что такое **_переполнение_** (**_overflow_** - переполнение через верхнюю границу)? +Что такое ***переполнение*** (***overflow*** - переполнение через верхнюю границу)? Допустим, у нас есть `uint8`, который может иметь только 8 бит. Это означает, что наибольшее число, которое мы можем сохранить, является двоичным `11111111` (или десятичным, 2^8-1 = 255). @@ -442,17 +442,17 @@ number++; В этом случае мы вызвали его переполнение — так что `number` теперь контринтуитивно равно `0`, хотя мы его увеличили. (Если вы добавляете 1 в двоичному `11111111`, оно сбрасывается в `00000000`, как часы, переходящие с `23:59` в `00:00`). -Потеря значимости (**_underflow_** - переполнение через нижнюю границу) аналогично, когда вы вычитаете `1` из `uint8` равного `0`, теперь оно будет равно `255` (потому что `uint` без знака и не может быть отрицательным). +Потеря значимости (***underflow*** - переполнение через нижнюю границу) аналогично, когда вы вычитаете `1` из `uint8` равного `0`, теперь оно будет равно `255` (потому что `uint` без знака и не может быть отрицательным). Хотя мы здесь не используем `uint8`, и кажется маловероятным, что `uint256` переполнится при каждом увеличении на `1` (2 ^ 256 - это действительно большое число), все же хорошо добавить защиту в наш контракт, чтобы наше DApp никогда не имело неожиданного поведения в будущем. ### Использование SafeMath -Чтобы предотвратить это, OpenZeppelin создал библиотеку (**_library_**) SafeMath, которая предотвращает эти проблемы по умолчанию. +Чтобы предотвратить это, OpenZeppelin создал библиотеку (***library***) SafeMath, которая предотвращает эти проблемы по умолчанию. Но прежде чем мы углубимся в это... Что такое библиотека? -**_Библиотека_** (**_library_**) представляет собой особый вид контракта в Solidity. Одна из вещей, для которой она полезна - это добавление функций к нативным типам данных. +***Библиотека*** (***library***) представляет собой особый вид контракта в Solidity. Одна из вещей, для которой она полезна - это добавление функций к нативным типам данных. Например, с библиотекой SafeMath мы будем использовать синтаксис `using SafeMath for uint256`. Библиотека SafeMath содержит 4 функции — `add`, `sub`, `mul`, and `div`. И теперь мы можем получить доступ к этим функциям `uint256` следующим образом: diff --git a/ru/5/13-comments.md b/ru/5/13-comments.md index 52a477afe8..264be525d7 100644 --- a/ru/5/13-comments.md +++ b/ru/5/13-comments.md @@ -522,7 +522,7 @@ contract CryptoZombies { В частности, рекомендуется комментировать ваш код, чтобы объяснить ожидаемое поведение каждой функции в вашем контракте. Таким образом, другой разработчик (или вы, после 6-месячного перерыва в проекте!) может быстро просмотреть и понять в общих чертах, что делает ваш код, не читая сам код. -Стандарт в сообществе Solidity - использовать формат **_natspec_**, который выглядит следующим образом: +Стандарт в сообществе Solidity - использовать формат ***natspec***, который выглядит следующим образом: ``` /// @title Контракт для основных математических операций diff --git a/ru/5/14-wrappingitup.md b/ru/5/14-wrappingitup.md index 0f231017e6..99a207f2be 100644 --- a/ru/5/14-wrappingitup.md +++ b/ru/5/14-wrappingitup.md @@ -33,6 +33,6 @@ material: Этот урок завершает Solidity код нашей игры! (На данный момент — мы можем добавить еще больше уроков в будущем). -В следующих двух уроках мы рассмотрим, как развертывать ваши контракты и взаимодействовать с ними с помощью **_web3.js_** (чтобы вы могли создать front-end для своего DApp). +В следующих двух уроках мы рассмотрим, как развертывать ваши контракты и взаимодействовать с ними с помощью ***web3.js*** (чтобы вы могли создать front-end для своего DApp). Если хотите, переименуйте любого из ваших зомби, затем перейдите к следующей главе, чтобы завершить урок. diff --git a/sk/1/arrays.md b/sk/1/arrays.md index 6d8c15191d..5110969fcd 100644 --- a/sk/1/arrays.md +++ b/sk/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -Keď chceme vytvoriť kolekciu niečoho, možeme použit **polia**. V solidity existujú dva druhy polí: **_fixné_** polia a **dynamické_** polia: +Keď chceme vytvoriť kolekciu niečoho, možeme použit **polia**. V solidity existujú dva druhy polí: ***fixné*** polia a **dynamické*** polia: ``` // Toto pole ma fixnú dĺžku 2 prvkov: @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -Môžeš taktiež vyvoriť pole **_štruktúr_** (**_structs_**). Napríklad použitím štruktúry `Person` z predošlej lekcie: +Môžeš taktiež vyvoriť pole ***štruktúr*** (***structs***). Napríklad použitím štruktúry `Person` z predošlej lekcie: ``` Person[] people; // dynamické pole, môžeme do neho pridávať nové prvky @@ -60,7 +60,7 @@ Spomínaš si na to, že stavové premenné su permanentne uložené na blockcha ## Verejné (public) polia -Pole môžeš deklarovať ako `public`. V takom prípade pre ne Solidity automaticky vytvorí **_getter_** metódu. Syntax je nasledovná: +Pole môžeš deklarovať ako `public`. V takom prípade pre ne Solidity automaticky vytvorí ***getter*** metódu. Syntax je nasledovná: ``` Person[] public people; @@ -72,4 +72,4 @@ Iné kontrakty by potom mohli dáta z toho poľa čítať (no nie do neho zapiso Chceme aby naša aplikácia udržiavala informáciu o armáde všetkých zombie. Ďalej chceme, aby ostatné aplikácie taktiež mali k našim zombie prístup. Zombie by mali byť verejne prístupní. -1. Vytvor verejné `public` pole `Zombie` štruktúr (**_structs_**) s názvom `zombies`. +1. Vytvor verejné `public` pole `Zombie` štruktúr (***structs***) s názvom `zombies`. diff --git a/sk/1/events.md b/sk/1/events.md index 90babef44e..7582bcc3a2 100644 --- a/sk/1/events.md +++ b/sk/1/events.md @@ -75,7 +75,7 @@ material: Náš kontrakt je takmer hotový. Poďme ešte pridať **udalosti**. -**Udalosti** (**_Events_**) sú spôsob, ako kontrakt môže dať vedieť front endu tvojej aplikácie vedieť, že sa v tvojom kontrakte niečo nastalo. Tvoja aplikácia može sledovať vyvolanie určitých typov udalostí a reagovať keď nastanú. +**Udalosti** (***Events***) sú spôsob, ako kontrakt môže dať vedieť front endu tvojej aplikácie vedieť, že sa v tvojom kontrakte niečo nastalo. Tvoja aplikácia može sledovať vyvolanie určitých typov udalostí a reagovať keď nastanú. Príklad: diff --git a/sk/1/functions3.md b/sk/1/functions3.md index d5233287b0..c371a0222d 100644 --- a/sk/1/functions3.md +++ b/sk/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -V tejto kapitole sa naučíme o **_návratových hodnotách_** funkcie a funkčných modifikátoroch. +V tejto kapitole sa naučíme o ***návratových hodnotách*** funkcie a funkčných modifikátoroch. ## Návratové hodnoty @@ -73,13 +73,13 @@ Deklarácia funkcie v Solidity obsahuje typ návratovej hodnoty (v tomto prípad Funkcie vyššie vlastne ale nijak nemení stav kontraktu. Nemení ani nezapisuje žiadne hodnoty. -V takom prípade deklarujeme funkcie ako funkcie kategórie **_view_**. To značí, že funkcia dáta iba číta, no nemodifikuje ich. +V takom prípade deklarujeme funkcie ako funkcie kategórie ***view***. To značí, že funkcia dáta iba číta, no nemodifikuje ich. ``` function sayHello() public view returns (string) { ``` -Solidity taktiež obsahuje funkcie kategórie **_pure_**, čo signalizuje, že funkcia dokonca ani nepristupuje ku žiadnym dátam kontraktu. Napríklad: +Solidity taktiež obsahuje funkcie kategórie ***pure***, čo signalizuje, že funkcia dokonca ani nepristupuje ku žiadnym dátam kontraktu. Napríklad: ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -Takáto funkcia nemodifikuje a ani žiadne dáta kontraktu nečíta - návratová hodnota tejto funkcie závisí len od jej funkčných parametrov. Takže práve v tomto prípade by sme funkciu deklarovali ako **_pure_** funkciu. +Takáto funkcia nemodifikuje a ani žiadne dáta kontraktu nečíta - návratová hodnota tejto funkcie závisí len od jej funkčných parametrov. Takže práve v tomto prípade by sme funkciu deklarovali ako ***pure*** funkciu. > Note: Môže byť náročné si dať pozor a vždy správne označiť funkcie ako pure/view. Našťastie nás Solidity kompilátor upozorní vždy keď je to nutné, aby sme nejakú funkciu označiť jedným z týchto modifikátorov. diff --git a/sk/1/lessoncomplete.md b/sk/1/lessoncomplete.md index ef863ab078..b1c780cfaa 100644 --- a/sk/1/lessoncomplete.md +++ b/sk/1/lessoncomplete.md @@ -14,8 +14,8 @@ Toto je len začiatok. Budeme nové lekcie CryptoZombies budeme publikovať kaž ### 1. Prihlás sa pre uloženie tvojho postupu -**_Prihlás sa_** aby si uložil svoj postup. Prihlásiš sa tak, že klikneš na "Uložiť" v hornej časti stránky. Dáme ti vedieť vždý ked pridáme novú lekciu. +***Prihlás sa*** aby si uložil svoj postup. Prihlásiš sa tak, že klikneš na "Uložiť" v hornej časti stránky. Dáme ti vedieť vždý ked pridáme novú lekciu. ### 2. Zdieľaj svojho zombie s priateľmi -**_Zdieľaj_** svojho zombie na Twittri, blab blah, atď (Treba pridať obrázky, linky) +***Zdieľaj*** svojho zombie na Twittri, blab blah, atď (Treba pridať obrázky, linky) diff --git a/sk/1/math.md b/sk/1/math.md index c68aa9b3ae..5afc7c7417 100644 --- a/sk/1/math.md +++ b/sk/1/math.md @@ -35,7 +35,7 @@ Matematika v Solidity je celkom priamočiara. Nasledujúce operácie fungujú ro * Delenie: `x / y` * Modulo / zvyšok: `x % y` _(napríklad, `13 % 5` je `3`, pretože keď sa pokúsiš 13 deliť 5timi celočíselne, dostaneš zvyšok 3)_ -Solidity taktiež podporuje **_exponenciálny operátor_** (operáciu "x umocnené na y", ktorú obvykle zapisujeme ako "x^y"): +Solidity taktiež podporuje ***exponenciálny operátor*** (operáciu "x umocnené na y", ktorú obvykle zapisujeme ako "x^y"): ``` uint x = 5 ** 2; // sa rovná 5^2 = 25 diff --git a/sk/1/structs.md b/sk/1/structs.md index 1d3dda13aa..c04315db80 100644 --- a/sk/1/structs.md +++ b/sk/1/structs.md @@ -32,7 +32,7 @@ material: } --- -Občas je potrebné použiť komplexnejšie dátové typy. Na to má pre nás Solidity pripravené **_štruktúry_** ( **_struct_**): +Občas je potrebné použiť komplexnejšie dátové typy. Na to má pre nás Solidity pripravené ***štruktúry*** ( ***struct***): ``` struct Person { diff --git a/sk/1/web3js.md b/sk/1/web3js.md index dfe609e82d..71a70e24cb 100644 --- a/sk/1/web3js.md +++ b/sk/1/web3js.md @@ -12,7 +12,7 @@ material: Náš Solidity kontrakt je hotový. Teraz potrebujeme napísať Javascriptový frontend, ktorý bude prepojený s našim kontraktom. -Ethereum má k dispozícii Javascriptovú knižnicu **_Web3.js_**. +Ethereum má k dispozícii Javascriptovú knižnicu ***Web3.js***. V neskorších lekciách sa pozrieme na to, ako náš kontrakt nasaďiť na blokchain, a ako nastaviť Web3.js. Zatiaľ sa však pozrieme len na ukážkový kód, Ilustrujeme, ako by sme pomocou Web3.js pracovali s nasadeným kontraktom. diff --git a/sk/2/10-interactingcontracts.md b/sk/2/10-interactingcontracts.md index 37bf6b41f9..4cd1aa4d44 100644 --- a/sk/2/10-interactingcontracts.md +++ b/sk/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ Naša hra v skutočnosti neporaní žiadnu mačičku CryptoKitty. Budeme iba *č ## Interakcia s inými kontraktmi -Na to aby náš kontrakt mohol komunikovať s iným kontraktom na blockchain, budeme musieť najrpv definovať **_rozhranie_** (**_interface_**). +Na to aby náš kontrakt mohol komunikovať s iným kontraktom na blockchain, budeme musieť najrpv definovať ***rozhranie*** (***interface***). Poďme sa pozrieť na nasledujúci jednoduchý príklad. Predstavme si, že na blockchaine je nasadený takýto kontrakt: @@ -131,7 +131,7 @@ Toto by bol jednoduchý kontrakt na ukladanie štastné číslo. Ktokoľvek mô Zvážme situáciou kedy by sme mali externý kontrakt, z ktorého by sme chceli čítať dáta z `LuckyNumber` kontraktu pomocou funkcie `getNum`. -Najprv by sme museli definovať **_rozhranie_** (**_interface_** ) v našom kontrakte: +Najprv by sme museli definovať ***rozhranie*** (***interface*** ) v našom kontrakte: ``` contract NumberInterface { diff --git a/sk/2/2-mappings.md b/sk/2/2-mappings.md index b098cf1070..d4db34695f 100644 --- a/sk/2/2-mappings.md +++ b/sk/2/2-mappings.md @@ -85,7 +85,7 @@ Aby sme to dosiahli, budeme potrebovať 2 nové dátové štruktúry `mapping` a ## Adresy ## Addresses -Ethereum blockchain je tvorený **_účtami_**. Môžeš o nich premýšľať podobným spôsobom ako o bankových účtoch. Účet má určitý balans **_Etheru_** (kryptomena na Ethereum blockchaine). Môžeš odosielať a príjmať platby do a z ostatných učtov. Rovnako ako keď sú prevádzané peniaze medzi bankovými účtami. +Ethereum blockchain je tvorený ***účtami***. Môžeš o nich premýšľať podobným spôsobom ako o bankových účtoch. Účet má určitý balans ***Etheru*** (kryptomena na Ethereum blockchaine). Môžeš odosielať a príjmať platby do a z ostatných učtov. Rovnako ako keď sú prevádzané peniaze medzi bankovými účtami. Každý účet má svoju `adresu`. Tu je možné prirovnať k číslu bankového účtu. Je to unikátny identifikátor referujúci na jeden konkrétny účet. Môže vyzerať napríklad takto: @@ -99,7 +99,7 @@ To znamená že môžeme adresu použiť ako unikátny identifikátor vlastníct ## Mapovania -V Lekcii 1 sme sa pozreli na **_štruktúry_** (structs) a **_polia_** (arrays). **_Mapovania_** (**_mapping_**) sú ďalším spôsobom ako v Solidity môžeme pracovať so štrukturovanými dátami. +V Lekcii 1 sme sa pozreli na ***štruktúry*** (structs) a ***polia*** (arrays). ***Mapovania*** (***mapping***) sú ďalším spôsobom ako v Solidity môžeme pracovať so štrukturovanými dátami. Deklarácia mapovania vyzerá takto: diff --git a/sk/2/5-inheritance.md b/sk/2/5-inheritance.md index 6bce570122..47219d7eaa 100644 --- a/sk/2/5-inheritance.md +++ b/sk/2/5-inheritance.md @@ -95,7 +95,7 @@ material: Kód našej hry sa začína celkom predlžovať. Namiesto toho aby sme robili náš kontrakt extrémne dlhým, občas dáva zmysel rozdeliť logiku kódu do niekoľkých kontraktov, a tak lepšie zorganizovať kód aplikácie. -Jedna z vlastností Solidity ktorá zľahčuje prácu s kódom je **_dedičnosť_** kontraktov: +Jedna z vlastností Solidity ktorá zľahčuje prácu s kódom je ***dedičnosť*** kontraktov: ``` contract Doge { @@ -111,7 +111,7 @@ contract BabyDoge is Doge { } ``` -`BabyDoge` **_dedí_** z kontraktu `Doge`. To znamená, že ak skompiluješ a nasadíš na blockchain `BabyDoge`, bude mať k dispozícií oboje `catchphrase()` aj `anotherCatchphrase()` (a taktiež akékoľvek iné funkcie ktoré by sme definovali na `Doge`). +`BabyDoge` ***dedí*** z kontraktu `Doge`. To znamená, že ak skompiluješ a nasadíš na blockchain `BabyDoge`, bude mať k dispozícií oboje `catchphrase()` aj `anotherCatchphrase()` (a taktiež akékoľvek iné funkcie ktoré by sme definovali na `Doge`). Toto môže byť použité pre logickú dedičnost (napríklad v prípade podkategórie, `Mačka` je `Zviera`). Ale inokedy tiež jednoducho na to, aby sme zorganizovali náš kód zoskupením určitej logiky do viacerých kontraktov. diff --git a/sk/2/7-storage.md b/sk/2/7-storage.md index b98f89f5a9..2c753f0fc1 100644 --- a/sk/2/7-storage.md +++ b/sk/2/7-storage.md @@ -71,11 +71,11 @@ material: V Solidity existujú dve miesta kde môžu premenné "sýdliť". Buď v trvalom dátovom úložisku kontraktu, tzv. `storage`, alebo v pamäti `memory`. -**_Storage_** referuje na premenné trvalo uložené na blockchaine. **_Memory_** premenné su dočasné, a sú vymazané medzi jednotlivými externými volaniami funkcii kontraktu. Môžeš o týchto dvoch typoch úložísk premýšlať podobne ako o hard disku a RAMke. +***Storage*** referuje na premenné trvalo uložené na blockchaine. ***Memory*** premenné su dočasné, a sú vymazané medzi jednotlivými externými volaniami funkcii kontraktu. Môžeš o týchto dvoch typoch úložísk premýšlať podobne ako o hard disku a RAMke. Vačsinou nebudeš nutne musieť používať tieto kľučové slova, pretože Solidity vie, ako s premennými zaobchádzať. Stavové premenné (premenné deklarované mimo funkcií) sú automaticky typu `storage` a sú zapísané na blockchain. Naopak, premenné deklarované vo vnútri funkcií sú automaticky typu `memory`. Ich hodnota bude zabudnutá keď bežiaca funkcia dobehne. -Existujú však prípady kedy budeš tieto kľučové slová ručne špecifikovať. Predovšetkým vtedy, keď budeš pracovať so **_štruktúrami_** a **_poliami_** v rámci funkcií: +Existujú však prípady kedy budeš tieto kľučové slová ručne špecifikovať. Predovšetkým vtedy, keď budeš pracovať so ***štruktúrami*** a ***poliami*** v rámci funkcií: ``` contract SandwichFactory { diff --git a/sk/3/01-externaldependencies.md b/sk/3/01-externaldependencies.md index b9297e8086..d359a6facc 100644 --- a/sk/3/01-externaldependencies.md +++ b/sk/3/01-externaldependencies.md @@ -143,7 +143,7 @@ material: Doposiaľ Solidity vyzeralo celkom podobne ako ostatné programovanie jazyky, napríklad JavaScript. Existuje však niekoľko veľkých rozdielov, akými sa decentralizované aplikácie (DApps) na Ethéreu líšia od klasických aplikácií. -Za prvé, po tom čo nasadíš svoj kontrakt na Ethereum blockchain, stane sa **_nemeniteľným_**. To znamená že jeho kód už nikdy nemože byť upravený. +Za prvé, po tom čo nasadíš svoj kontrakt na Ethereum blockchain, stane sa ***nemeniteľným***. To znamená že jeho kód už nikdy nemože byť upravený. Kód kontraktu ktorý nasadíš na blockchain tam zostane navždy, permanentne. Práve to je ale jeden z dôvodov, prečo je bezpečnosť v prípade Solidity kontraktov extrémne dôležitá záležitosť. Ak je v tvojom kód chyba, nie je spôsob ako ju dodatočne napraviť. Musel by si povedať svojim užívateľom povedať, aby začali používať adresu nového smart kontraktu, obsahujúceho opravu chyby. diff --git a/sk/3/02-ownable.md b/sk/3/02-ownable.md index c71ce857cd..941fa0952c 100644 --- a/sk/3/02-ownable.md +++ b/sk/3/02-ownable.md @@ -189,7 +189,7 @@ Na zabezpečenie takýchto situácií sa stalo bežnou praktikou urobiť kontrak ## `Ownable` kontrakty od OpenZeppelin -V bloku kódu nižšie je `Ownable` kontrakt z **_OpenZeppelin_** Solidity knižnice. OpenZeppelin je knižnica bezpečných, komunitou schválených smart kontraktov, ktoré môžeš použiť vo svojich aplikáciách. Keď dokončíš túto lekciu, doporučujeme sa pozrieť na webové stránky OpenZeppelinu pre ďalšie informácie. +V bloku kódu nižšie je `Ownable` kontrakt z ***OpenZeppelin*** Solidity knižnice. OpenZeppelin je knižnica bezpečných, komunitou schválených smart kontraktov, ktoré môžeš použiť vo svojich aplikáciách. Keď dokončíš túto lekciu, doporučujeme sa pozrieť na webové stránky OpenZeppelinu pre ďalšie informácie. Pozri si tento kontrakt. Uvidíš niekoľko vecí, ktoré sme zatiaľ ešte neprebrali. Dostaneme sa k nim za chvíľu. @@ -233,7 +233,7 @@ contract Ownable { Niekoľko vecí ktoré sme doposiaľ nevideli: -- Konštruktory. `function Ownable()` je **_konštruktor_** (**_constructor_**). To je funkcia, ktorú môžeš ale nemusíš definovať, má rovnaký názov ako kontrakt. Bude vykonaná iba raz, a to v čase ked je kontrakt vytvorený. +- Konštruktory. `function Ownable()` je ***konštruktor*** (***constructor***). To je funkcia, ktorú môžeš ale nemusíš definovať, má rovnaký názov ako kontrakt. Bude vykonaná iba raz, a to v čase ked je kontrakt vytvorený. - Funkčné modifikátory: `modifier onlyOwner()`. Modifikátory sú také polovičaté funkcie, použité na modifikáciu chovania iných funkcií. Obvykle na skontrolovanie určitých požiadavok pred vykonaním funkcie. V tomto prípade `onlyOwner` je modifikátor ktorý limituje právo spúštať funkciu iba (only) vlastníkom (owner). Pozrieme sa na ne z blízka v ďalšej kapitole, kde si taktiež vysvetlíme, čo znamená ten podivný kód `_;`. - Kľučové slovo `indexed`: toto zatiaľ riešit nebudeme, zatiaľ ho nepotrebujeme. diff --git a/sk/3/04-gas.md b/sk/3/04-gas.md index e026918170..03c15bdf02 100644 --- a/sk/3/04-gas.md +++ b/sk/3/04-gas.md @@ -185,9 +185,9 @@ Poďme sa pozrieť na ďalší aspekt ktorým sa Solidity líši od ostatných p ## Gas — palivo na ktorom bežia Ethereum DApps -V solidity musia užívatelia zaplatiť zakaždým keď zavolajú nejakú funkciu tvojho kontraktu menou nazývanou **_gas_** (plyn). Užívatelia si môžu kúpiť gas za Ether (Ethéreum kryptomena). Znamená to, že tvoji užívatelia musia utrácať ETH na to, aby mohli volať funkcie tvojej DAppky. +V solidity musia užívatelia zaplatiť zakaždým keď zavolajú nejakú funkciu tvojho kontraktu menou nazývanou ***gas*** (plyn). Užívatelia si môžu kúpiť gas za Ether (Ethéreum kryptomena). Znamená to, že tvoji užívatelia musia utrácať ETH na to, aby mohli volať funkcie tvojej DAppky. -Koľko gasu je na vykonanie funkcie potrebné záleží od toho, aká zložita je logika volanej funkcie. Každá individuálna operácia má určitú **_spotrebu gasu_** (**_gas cost_**). Spotreba gasu operácie je daná tým, koľko výpočtových zdrojov bude potrebných na vykonanie operácie (napríklad zápis dát do blockchain je oveľa drahšia operácia ako sčítanie dvoch čísel). Finálna množstvo gasu potrebné na vykonanie funkcie je vypočítané súčet všetkých výdajov gasu jednotlivých individuálnych výpočtových operácií počas behu funkcie. +Koľko gasu je na vykonanie funkcie potrebné záleží od toho, aká zložita je logika volanej funkcie. Každá individuálna operácia má určitú ***spotrebu gasu*** (***gas cost***). Spotreba gasu operácie je daná tým, koľko výpočtových zdrojov bude potrebných na vykonanie operácie (napríklad zápis dát do blockchain je oveľa drahšia operácia ako sčítanie dvoch čísel). Finálna množstvo gasu potrebné na vykonanie funkcie je vypočítané súčet všetkých výdajov gasu jednotlivých individuálnych výpočtových operácií počas behu funkcie. Pretože vykonávanie funkcií stojí tvojich užívateľov reálne peniaze, optimalizácia kódu je na Ethéreu oveľa dôležitejšie ako v iných programovacích jazykoch. Ak je tvoj kód neporiadny, užívatelia budú musieť utratiť za používanie tvojho kontraktu viac. V prípade tísícok užívateľov je možné, že by ľudia zbytočne premrhali milióny dolárov. diff --git a/sk/4/battle-02.md b/sk/4/battle-02.md index 577d59e28e..ab6e1c5077 100644 --- a/sk/4/battle-02.md +++ b/sk/4/battle-02.md @@ -248,7 +248,7 @@ Potom tento kód použije `keccak` a skonvertuje kombináciu všetkých vstupov ### Táto metóda je zraniteľná útokom nečestného uzlu -Keď v Ethéreu zavoláš funkciu kontraktu, rozpošle sa Ethéreum uzlom (serverom ktoré overujú transakcie) vo forme **_transakcie_**. Uzly v sieti pozbierajú niekoľko takýchto transakcií a pokúsia sa ako prvé vyriešiť výpočtovo náročný matematický problém, známy ako "Proof of Work". Keď ho vyriešia, zverejnia na Ethéreum sieť skupinu transakcií spolu vypočítaným riešením Proof of Work (PoW) vo forme **_bloku_**. +Keď v Ethéreu zavoláš funkciu kontraktu, rozpošle sa Ethéreum uzlom (serverom ktoré overujú transakcie) vo forme ***transakcie***. Uzly v sieti pozbierajú niekoľko takýchto transakcií a pokúsia sa ako prvé vyriešiť výpočtovo náročný matematický problém, známy ako "Proof of Work". Keď ho vyriešia, zverejnia na Ethéreum sieť skupinu transakcií spolu vypočítaným riešením Proof of Work (PoW) vo forme ***bloku***. Po tom čo jeden uzol vyrieši PoW, ostatné uzly sa prestanú počítať atuálny PoW, ale overia že list transakcií ktoré zverejnil úspešný uzol je validný, akceptujú nový blok a začnú sa snažiť vyriešiť PoW pre ďalší blok. @@ -260,7 +260,7 @@ Keby som v Ethéreum sieti bežal svoj vlastný uzol, mohol by som zverejniť tr ## Tak ako bezpečne vygenerujeme náhodné čisla na Ethereum? -Pretože všetok obsah blockchainu je viditeľný všetkým zučastneným, je to náročný problém, a jeho riešenie je nad rámec tohoto tutoriálu. Môžeš sa o tom dočítať viacej v tomto StackOverflow vlákne. Jeden z nápadov je používať tzv. **_oracle_** pre prístup k funkcii generujúcej náhodné čísla mimo Ethereum blockchain. +Pretože všetok obsah blockchainu je viditeľný všetkým zučastneným, je to náročný problém, a jeho riešenie je nad rámec tohoto tutoriálu. Môžeš sa o tom dočítať viacej v tomto StackOverflow vlákne. Jeden z nápadov je používať tzv. ***oracle*** pre prístup k funkcii generujúcej náhodné čísla mimo Ethereum blockchain. Samozrejme že keďže by sme v sieti súťažili v overovaní ďalšieho bloku s desiatkami tísic iných Ethereum uzlov, šanca že by sa nám podarilo vyriešiť nasledujúci blok (ktorý by mohol obstahovať nami zmanipulovanú transakciu) by bola veľmi nízka. Potrebovali by sme veľké množstvo výpočtových zdrojov na to, aby sme z tejto zranitelnosti mohli s výnosne ťažiť. Keby však bola potenciálna odmena dostatočne veľká (keby bolo možné na hádzanie mincov staviť napríklad $100,000,000), stálo by to za pokus o útok. @@ -268,7 +268,7 @@ Náhodná generácia čísel na Ethereu teda NIE JE bezpečná. Pokiaľ ale na n Pretože v tomto tutoriále vytvárame len jednoduchú hru za účelom ukážky, a v stávke nie sú žiadne reálne peniaze, rozhodli sme sa akceptovať riziká ktoré so sebou nesie použitie takéhoto náhodného generátora. Generátor nebude celkom 100% bezpečný, no výhodou je jeho jednoduchá implementácia. -V budúcich lekciách môžno pokryjeme tému **_oracle_** (bezpečný spôsob ako získať dáta z mimo Ethereum siete) na to, aby sme mohli získať náhodné čísla generované mimo blockchain. +V budúcich lekciách môžno pokryjeme tému ***oracle*** (bezpečný spôsob ako získať dáta z mimo Ethereum siete) na to, aby sme mohli získať náhodné čísla generované mimo blockchain. ## Vyskúšaj si to sám diff --git a/sk/4/battle-08.md b/sk/4/battle-08.md index 24eff3d229..fd857663ed 100644 --- a/sk/4/battle-08.md +++ b/sk/4/battle-08.md @@ -255,7 +255,7 @@ V Kapitole 6 sme výpočítali náhodné čislo v rozsahu od 0 do 100. Teraz tot ## Vyskúšaj si to sám -1. Vytvor `if` podmienku, ktorá bude kontrolovať či `rand` je **_menej alebo sa rovná_** `attackVictoryProbability`. +1. Vytvor `if` podmienku, ktorá bude kontrolovať či `rand` je ***menej alebo sa rovná*** `attackVictoryProbability`. 2. Ak je táto podmienka pravdivá, náš zombie vyhrá. Takže: diff --git a/sk/4/payable.md b/sk/4/payable.md index 3f7a47d73a..35c5c444ed 100644 --- a/sk/4/payable.md +++ b/sk/4/payable.md @@ -228,7 +228,7 @@ material: } --- -Doposiaľ sme hovorili o niekoľkých **_funkčných modifikátoroch_**. Môže byť ťažké si všetko zapamätať, poďme si to teda ešte rýchlo zopakovať. +Doposiaľ sme hovorili o niekoľkých ***funkčných modifikátoroch***. Môže byť ťažké si všetko zapamätať, poďme si to teda ešte rýchlo zopakovať. 1. K dispozicií mamé modifikátory viditelnosti, ktoré určujú odkiaľ môže byť funkcia zavolaná. `private` znamená, že môže byť volaná len z ostatných funkcií rovnakého kontraktu. `internal` je ako `private`, ale môže byť volaná taktiež z kódu oddedených kontraktov. `external` funkcie môžu byť volané iba externe, mimo daného kontraktu. Na záver, funkcie `public` môžu byť volané odkiaľkoľvek - interne aj externe. diff --git a/sk/5/01-erc721-1.md b/sk/5/01-erc721-1.md index 7b9df22113..9ef721b09c 100644 --- a/sk/5/01-erc721-1.md +++ b/sk/5/01-erc721-1.md @@ -242,11 +242,11 @@ material: } --- -Poďme sa porozprávať o **_tokenoch_**. +Poďme sa porozprávať o ***tokenoch***. -Ak si sa v oblasti Ethereum pohybuješ už nejakú dobu, pravdepodobne si počul ľudí často spomínať rôzne tokeny - hlavne **_ERC20 tokeny_**. +Ak si sa v oblasti Ethereum pohybuješ už nejakú dobu, pravdepodobne si počul ľudí často spomínať rôzne tokeny - hlavne ***ERC20 tokeny***. -**_Token_** na Ethereu je v podstate smart kontrakt ktorý dodržuje určité spoločné pravidlá - presnejšie, implementuje množinu funkcií ktoré su definované aj na kontraktoch všetkých ostatných ERC20 tokenov, ako napríklad `transfer(address _to, uint256 _value)` a `balanceOf(address _owner)`. +***Token*** na Ethereu je v podstate smart kontrakt ktorý dodržuje určité spoločné pravidlá - presnejšie, implementuje množinu funkcií ktoré su definované aj na kontraktoch všetkých ostatných ERC20 tokenov, ako napríklad `transfer(address _to, uint256 _value)` a `balanceOf(address _owner)`. Interne tieto smart kontrakty obvykle používajú mapovanie `mapping(address => uint256) balances` na to, aby si udržiavali prehľad o tom ktorý Ethereum účet má koľko tokenov. @@ -270,9 +270,9 @@ Za prvé, zombie nie sú delitelný ako meny. Síce niekomu môžeš poslať 0.2 Za druhé, nie všetci zombie sú si rovní. Tvoj Level 2 zombie "**Steve**" absolútne nie je rovný môjmu Level 732 zombie "**H4XF13LD MORRIS 💯💯😎💯💯**". (Nie, ani trošku, *Steve*) -Existuje iný token štandard, ktorý je oveľa vhodnejší pre krypto zberatelské predmety (crypto-collectibles) ako sú CryptoZombies. Sú to **_ERC721 tokeny_**. +Existuje iný token štandard, ktorý je oveľa vhodnejší pre krypto zberatelské predmety (crypto-collectibles) ako sú CryptoZombies. Sú to ***ERC721 tokeny***. -**_ERC721 tokeny_** **NIE SÚ** zameniteľné, pretože každý jeden z nich je považovaný za unikátny a ďalej nedeliteľný. Je možné ich obchodovať v celkoch, každý ma unikátne ID. Sú preto perfektným kandidátom riešenia, ako spraviť našich zombie obchodovateľných. +***ERC721 tokeny*** **NIE SÚ** zameniteľné, pretože každý jeden z nich je považovaný za unikátny a ďalej nedeliteľný. Je možné ich obchodovať v celkoch, každý ma unikátne ID. Sú preto perfektným kandidátom riešenia, ako spraviť našich zombie obchodovateľných. > Uvedom si že používanie štandardu ako ERC721 má výhodu v tom že v rámci našeho kontraktu nemusíme implementovať logiku aukcií a escrow, ktorá by určovala ako môžu hráči so svojimi zombie obchodovať. Miesto toho niekto iný môže vytvoriť platformu na obchodovanie s ERC721 aktívami. Pokiaľ sú potom naši zombíci v súlade s ERC721, budú plne kompatibilný s takouto obchodovacou platformou. Toto je jasná výhoda dodržiavania token štandardov miesto vymýšlania vlastnej obchodovacej logiky. diff --git a/sk/5/09-safemath-1.md b/sk/5/09-safemath-1.md index dfca772a31..a7299bdf34 100644 --- a/sk/5/09-safemath-1.md +++ b/sk/5/09-safemath-1.md @@ -397,7 +397,7 @@ Chceli sme však túto lekciu spraviť ľahko stráviteľnú, preto sme prešli Teraz sa pozrieme na jednu z najdôležitejších bezpečnostných vlastností, ktorých by si si mal byť vedomí pri písani smart kontraktov. Ochrana pred pretečením a podtečením. -Čo je to **_pretečenie_**? +Čo je to ***pretečenie***? Dajme tomu, že máme nejaký `uint8`, ktorý má len 8 bitov. To znamená, že najväčšie číslo, ktoré môže držat je binárne `11111111` (decimálne je to, 2^8 - 1 = 255). @@ -417,11 +417,11 @@ V našom kóde síce nepoužívame `uint8`, a môže sa zdať nepravdepodobné, ### Používanie SafeMath -Na to, aby sme sa tomu vyhli, OpenZeppelin vytvoril **_knižnicu_** (**_library_**) s názvom SafeMath. Tá zabraňuje vyššie spomenutým problémom. +Na to, aby sme sa tomu vyhli, OpenZeppelin vytvoril ***knižnicu*** (***library***) s názvom SafeMath. Tá zabraňuje vyššie spomenutým problémom. Ale než sa k tomu dostaneme... čo je to vlastne knižnica? -**_Knižnica_** (**_library_**), je v solidity špeciálny typ kontraktu. Jeden zo spôsobov, akým sú knižnice užitočné je ten, že môžu rozšíriť natívne dátové typy o nové funkcie. +***Knižnica*** (***library***), je v solidity špeciálny typ kontraktu. Jeden zo spôsobov, akým sú knižnice užitočné je ten, že môžu rozšíriť natívne dátové typy o nové funkcie. Najprv musíme deklarovať v našom kontrakte, že chceme časť knižnice používať takýmto spôsobom `using SafeMath for uint256`. SafeMath knižnica má 4 funkcie - `add`, `sub`, `mul`, and `div`. K týmto funkciám budeme môcť pristupovať z `uint256` takto: diff --git a/sk/5/13-comments.md b/sk/5/13-comments.md index 84a02b7987..c981f9997e 100644 --- a/sk/5/13-comments.md +++ b/sk/5/13-comments.md @@ -493,7 +493,7 @@ contract CryptoZombies { Je dobrou praktikou svoj kód komentovať a vysvetľovať očakávané správanie každej funkcie kontraktu. Tým pádom iný programátor (prípadne ty po 6 mesiacoch) bude schopný rýchlo vstrebať a pochopiť ako sa má kontrakt zhruba správať bez toho, aby musel dopodrobna čítať kód. -Štandardným spôsob v Solidity komunite je používanie dokumentačného formátu zvaného **_natspec_**. Vyzerá nejako takto: +Štandardným spôsob v Solidity komunite je používanie dokumentačného formátu zvaného ***natspec***. Vyzerá nejako takto: ``` /// @title Kontrakt pre základné matematické operácie diff --git a/sk/5/14-wrappingitup.md b/sk/5/14-wrappingitup.md index e71d5735f0..2f51e0e827 100644 --- a/sk/5/14-wrappingitup.md +++ b/sk/5/14-wrappingitup.md @@ -33,6 +33,6 @@ V tejto lekcii sme sa naučili o: Táto lekcia bola zavŕšením písaním Solidity kódu našej hry! (Zatiaľ - možno niekedy v budúcnosti pridáme ďalšie lekcie) -V ďalších dvoch lekciách sa naučís, ako nasadzovať tvoje kontrakty a pracovať s nimi z Javascriptu použitím **_web3.js_** (takže môžeš vytvoriť front-end tvojej DAppky). +V ďalších dvoch lekciách sa naučís, ako nasadzovať tvoje kontrakty a pracovať s nimi z Javascriptu použitím ***web3.js*** (takže môžeš vytvoriť front-end tvojej DAppky). Premenuj svojich zombie ako sa ti páči a pokračuj na ďalšiu kapitolu pre oficiálne ukončenie tejto lekcie. diff --git a/sk/6/01.md b/sk/6/01.md index 7fff33f842..4158b6eb79 100644 --- a/sk/6/01.md +++ b/sk/6/01.md @@ -365,7 +365,7 @@ material: Dokončením Lekcie 5 je naša DApp hotová. Teraz ideme vytvoriť jednoduchú stránku, pomocou ktorej môžu užívateľia interagovať s našou DApp. -Na to budeme potrebovať Javascriptovú knižnicu od Ethereum Foundation nazývanú **_Web3.js_**. +Na to budeme potrebovať Javascriptovú knižnicu od Ethereum Foundation nazývanú ***Web3.js***. ## Čo je to Web3.js? @@ -375,7 +375,7 @@ Drž na pamäti, že Ethereum sieť je tvorená uzlami, a každý z nich si udr 2. Funkciu ktorú chceš volať 3. Premenné ktoré chceš funkcií poslať -Etereum uzly "rozprávajú" len jazykom zvaným **_JSON-RPC_**, ktorý pre ľudí nie je ľahko čitateľný. Dotaz na Ethereum uzol, aby zavolal určitú funkciu kontraktu v ňom vyzerá zhruba takto: +Etereum uzly "rozprávajú" len jazykom zvaným ***JSON-RPC***, ktorý pre ľudí nie je ľahko čitateľný. Dotaz na Ethereum uzol, aby zavolal určitú funkciu kontraktu v ňom vyzerá zhruba takto: ``` // hmmm... veľa šťastia s písaním takýchto funkčných volaní po celý deň diff --git a/sk/6/02.md b/sk/6/02.md index 11c5b09006..258330c910 100644 --- a/sk/6/02.md +++ b/sk/6/02.md @@ -385,11 +385,11 @@ material: Skvelé! Teraz, keď máme Web3.js v našom projekte, poďme ho inicializovať a začat komunikovať s blockchain. -Prvá vec ktorú budeme potrebovať je **_Web3 Provider_**. +Prvá vec ktorú budeme potrebovať je ***Web3 Provider***. -Nezabudni, že Ethereum sieť je vytvorená z **_uzlov_**. Všetky uzly zdieľajú kópiu identických dát. Tým, že nakonfigurujeme naš Web3 Provider vo Web3.js mu povieme s ktorým **Ethereum uzlom** má komunikovať pre čítanie a zapisovanie dát na blockchain. Je to podobné, ako keď v kóde nastavíš URL serveru s ktorým má front end komunikovať v prípade tradičnej webovej aplikácie. +Nezabudni, že Ethereum sieť je vytvorená z ***uzlov***. Všetky uzly zdieľajú kópiu identických dát. Tým, že nakonfigurujeme naš Web3 Provider vo Web3.js mu povieme s ktorým **Ethereum uzlom** má komunikovať pre čítanie a zapisovanie dát na blockchain. Je to podobné, ako keď v kóde nastavíš URL serveru s ktorým má front end komunikovať v prípade tradičnej webovej aplikácie. -Ak chceš, môžeš si rozbiehať Ethereum uzol sám a použiť ho ako svojho providera. Život budeš mať ale jednoduchší ak použiješ niektorú z existujúcich služieb, ktorá sa o takéto Ethereum uzly stará. Takou službou je napríklad — **_Infura_**. +Ak chceš, môžeš si rozbiehať Ethereum uzol sám a použiť ho ako svojho providera. Život budeš mať ale jednoduchší ak použiješ niektorú z existujúcich služieb, ktorá sa o takéto Ethereum uzly stará. Takou službou je napríklad — ***Infura***. ## Infura @@ -407,7 +407,7 @@ Naša aplikácia bude však používaná mnohými užívateľmi - týto použív Kryptografia je komplikovaná, takže pokiaľ nie si bezpečnostný expert ktorý presne vie čo robí, bude lepšie ak nebudeš sám pokúšať spravovať súkromné kľúče užívateľov vo svojom front ende . -Našťastie ani nemusíš. Existujú služby ktoré sa o tieto veci postarajú za teba. Jednou z najpopulárnejších možností je **_Metamask_**. +Našťastie ani nemusíš. Existujú služby ktoré sa o tieto veci postarajú za teba. Jednou z najpopulárnejších možností je ***Metamask***. ## Metamask diff --git a/sk/6/03.md b/sk/6/03.md index 4307673b7a..84fb21163a 100644 --- a/sk/6/03.md +++ b/sk/6/03.md @@ -863,7 +863,7 @@ material: Teraz keď už máme pripravné Web3.js pre použitie s Web3 providerom z Metamasku, môžeme ho nastaviť aby komunikoval s našim kontraktom. -Web3.js potrebuje 2 veci na to, aby mohol s našim kontraktom komunikovať. Jeho **_adresu_** a **_ABI_**. +Web3.js potrebuje 2 veci na to, aby mohol s našim kontraktom komunikovať. Jeho ***adresu*** a ***ABI***. ## Adresa kontraktu @@ -876,7 +876,7 @@ Po tom čo nasadíš svoj smart kontrakt, budeš si potrebovať skopírovať jeh ## ABI Kontraktu -Ďalšia vec, ktorú Web3.js bude potrebovať na to aby mohol s tvojim kontraktom pracovať je jeho **_ABI_**. +Ďalšia vec, ktorú Web3.js bude potrebovať na to aby mohol s tvojim kontraktom pracovať je jeho ***ABI***. ABI je skratka pre Application Binary Interface (Binárne Rozhranie Aplikácie). V podstate je to reprezentácia metód tvojho kontraktu v JSON formáte. Tá Web3.js hovorí, ako s tvojím kontraktom na blockchain pracovať. diff --git a/th/1/arrays.md b/th/1/arrays.md index cdfc8cae62..9697df1df4 100644 --- a/th/1/arrays.md +++ b/th/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -เมื่อคุณต้องการชุดข้อมูลของอะไรบางอย่าง คุณสามารถใช้ **_array_** มาช่วยในการจัดการได้ ซึ่งใน Solidity นั้นเราจะมี arrays อยู่2 ชนิด ได้แก่: **_fixed_** arrays และ **_dynamic_** arrays: +เมื่อคุณต้องการชุดข้อมูลของอะไรบางอย่าง คุณสามารถใช้ ***array*** มาช่วยในการจัดการได้ ซึ่งใน Solidity นั้นเราจะมี arrays อยู่2 ชนิด ได้แก่: ***fixed*** arrays และ ***dynamic*** arrays: ``` // fixed Array จำกัดความยาวให้มีแค่2 elements : @@ -50,7 +50,7 @@ string[5] stringArray ; uint[] dynamicArray; ``` -เราสามารถที่จะสร้าง array ของ **_structs_** โดยใช้ `Person`‘ struct ที่อยู่ในบทก่อนหน้าได้เลย +เราสามารถที่จะสร้าง array ของ ***structs*** โดยใช้ `Person`‘ struct ที่อยู่ในบทก่อนหน้าได้เลย ``` Person[]people; // แปลว่าเป็น dynamic Array ซึ่งเราสามารถเพิ่มค่าลงไปใน array ได้เรื่อยๆ @@ -60,7 +60,7 @@ Person[]people; // แปลว่าเป็น dynamic Array ซึ่งเ ## Public Arrays -เราสามารถประกาศ array ให้มีค่าเป็น `public` และ Solidity ก็จะสร้าง **_getter_** method ขึ้นมาโดยอัตโนมัติสำหรับ array นี้ โดยหน้าตาของ syntax จะเป็นดังต่อไปนี้: +เราสามารถประกาศ array ให้มีค่าเป็น `public` และ Solidity ก็จะสร้าง ***getter*** method ขึ้นมาโดยอัตโนมัติสำหรับ array นี้ โดยหน้าตาของ syntax จะเป็นดังต่อไปนี้: ``` Person[]public people; @@ -72,4 +72,4 @@ Person[]public people; ตอนนี้เรากำลังต้องการที่จะบรรจุค่าของกองกำลังซอมบี้ ลงในแอพพลิเคชั่นของเรา และต้องการที่จะให้จำนวนของซอมบี้ทั้งหมดนั้น ไปปรากฏอยู่ในแอพพลิเคชั่นอื่นๆ เช่นกัน ซึ่งนั่นก็แปลว่าเราต้องการให้กองกำลังของซอมบี้นั้นมีค่าเป็นสาธารณะ(public) -1. สร้าง public array ของ `Zombie` **_structs_** แล้วตั้งชื่อว่า `zombies` +1. สร้าง public array ของ `Zombie` ***structs*** แล้วตั้งชื่อว่า `zombies` diff --git a/th/1/datatypes.md b/th/1/datatypes.md index ad03b5ed84..2e4ec87de4 100644 --- a/th/1/datatypes.md +++ b/th/1/datatypes.md @@ -25,7 +25,7 @@ material: ยอดเยี่ยม! ตอนนี้เราก็จะได้ส่วน shell ของ contractแล้ว ต่อจากนี้เราก็จะมาเรียนรู้กันว่า Solidity จะจัดการกับตัวแปรต่างๆ ได้อย่างไรบ้าง -**_State variables_** จะถูกจัดเก็บถาวรลงในส่วนจัดเก็บของ contract ซึ่งนั่นก็หมายความว่ามันก็จะถูกเขียนลงในบล็อคเชนของ Ethereum เช่นกัน +***State variables*** จะถูกจัดเก็บถาวรลงในส่วนจัดเก็บของ contract ซึ่งนั่นก็หมายความว่ามันก็จะถูกเขียนลงในบล็อคเชนของ Ethereum เช่นกัน ##### ตัวอย่าง: ``` diff --git a/th/1/events.md b/th/1/events.md index eca9b33e65..9c7e312c86 100644 --- a/th/1/events.md +++ b/th/1/events.md @@ -73,9 +73,9 @@ material: } --- -contract ของเราก็จะใกล้เสร็จแล้ว จนถึงตอนนี้ก็ได้ถึงเวลาของการเพิ่ม **_event_** เข้าไป +contract ของเราก็จะใกล้เสร็จแล้ว จนถึงตอนนี้ก็ได้ถึงเวลาของการเพิ่ม ***event*** เข้าไป -**_Events_** คือวิธีหนึ่งสำหรับ contract ของเราที่จะสามารถสื่อสารได้ว่า มีบางสิ่งเกิดขึ้นบนบล็อคเชนของด้านหน้าแอพพลิเคชั่นของเรา (front-end) ซึ่งจะสามารถถูกฟัง (‘listening’) สำหรับบางเหตุการณ์และอาจจะมีการกำหนดให้สร้าง action ขึ้นมาเพื่อนรองรับอีเว้นท์ที่เกิดขึ้น +***Events*** คือวิธีหนึ่งสำหรับ contract ของเราที่จะสามารถสื่อสารได้ว่า มีบางสิ่งเกิดขึ้นบนบล็อคเชนของด้านหน้าแอพพลิเคชั่นของเรา (front-end) ซึ่งจะสามารถถูกฟัง (‘listening’) สำหรับบางเหตุการณ์และอาจจะมีการกำหนดให้สร้าง action ขึ้นมาเพื่อนรองรับอีเว้นท์ที่เกิดขึ้น ตัวอย่าง: diff --git a/th/1/functions3.md b/th/1/functions3.md index ad55a0c9f0..82b632a37b 100644 --- a/th/1/functions3.md +++ b/th/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -ในบทนี้เราจะมาพูดถึงฟังก์ชั่น **_return values_** และ การเข้าถึงฟังก์ชั่น (function modifiers) +ในบทนี้เราจะมาพูดถึงฟังก์ชั่น ***return values*** และ การเข้าถึงฟังก์ชั่น (function modifiers) ## การรีเทิร์นค่าต่างๆ @@ -73,13 +73,13 @@ function sayHello() public returns (string) { ในตัวอย่างของฟังก์ชั่นด้านบนนั้นจะไม่มีการเปลี่ยนค่าสถานะใดๆใน Solidity ยกตัวอย่างเช่น ค่าต่างๆจะไม่มีการเปลี่ยนแปลง หรือไม่มีการเขียนค่าใหม่ใดๆ ลงไป -ทำให้ในกรณีนี้เราสามารถประกาศค่าของฟังก์ชั่นนี้ให้เป็น **_view_** ซึ่งก็หมายถึงฟังก์ชั่นนี้สามารถที่จะดูได้แต่ไม่สามารถเข้าไปปรับเปลี่ยนค่าต่างๆภายในได้: +ทำให้ในกรณีนี้เราสามารถประกาศค่าของฟังก์ชั่นนี้ให้เป็น ***view*** ซึ่งก็หมายถึงฟังก์ชั่นนี้สามารถที่จะดูได้แต่ไม่สามารถเข้าไปปรับเปลี่ยนค่าต่างๆภายในได้: ``` function sayHello() public view returns (string) { ``` -นอกจากนี้ใน Solidity ยังมีฟังชั่น **_pure_** หมายถึงเราไม่สามารถแม้แต่จะเข้าถึงข้อมูลใดๆในแอพพลิเคชั่นนี้ได้ จะมีหน้าตาดังต่อไปนี้: +นอกจากนี้ใน Solidity ยังมีฟังชั่น ***pure*** หมายถึงเราไม่สามารถแม้แต่จะเข้าถึงข้อมูลใดๆในแอพพลิเคชั่นนี้ได้ จะมีหน้าตาดังต่อไปนี้: ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -ฟังก์ชั่นนี้จะไม่สามารถแม้แต่อ่านค่าจากสถานะของแอพพลิเคชั่นได้ นั่นก็คือมันจะรีเทิร์นค่าก็ต่อเมื่อมีพารามีเตอร์ของฟังก์ชั่นเข้ามาเท่านั้น ทำให้ในกรณีนี้เราจะต้องประกาศค่าของฟังก์ชั่นเป็น **_pure_** +ฟังก์ชั่นนี้จะไม่สามารถแม้แต่อ่านค่าจากสถานะของแอพพลิเคชั่นได้ นั่นก็คือมันจะรีเทิร์นค่าก็ต่อเมื่อมีพารามีเตอร์ของฟังก์ชั่นเข้ามาเท่านั้น ทำให้ในกรณีนี้เราจะต้องประกาศค่าของฟังก์ชั่นเป็น ***pure*** > โน้ต : เราอาจจะจำไม่ได้ว่าเมื่อไหร่ถึงจะต้องใส่ค่าของฟังก์ชั่นเป็น pure/view แต่โชคดีที่คอมไพล์เลอร์ของSolidity นั้นสามารถแจ้งเตือนคุณได้เสมอว่า modifier ชนิดใดที่คุณควรจะใช้ สำหรับฟังก์ชั่นที่ได้สร้างขึ้นมา diff --git a/th/1/lessoncomplete.md b/th/1/lessoncomplete.md index 6ea692cf2b..53e1fad730 100644 --- a/th/1/lessoncomplete.md +++ b/th/1/lessoncomplete.md @@ -14,8 +14,8 @@ material: ### 1. ลงชื่อเข้าใช้เพื่อทำการบันทึกความก้าวหน้าของคุณ -**_Sign in_** เพื่อทำการบันทึกความก้าวหน้าโดยคลิกที่ลิ้งค์คำสั่ง “Save progress” ตรงด้านบนของเพจ โดยเราจะแจ้งเตือนคุณเมื่อมีบทเรียนใหม่ออกมา +***Sign in*** เพื่อทำการบันทึกความก้าวหน้าโดยคลิกที่ลิ้งค์คำสั่ง “Save progress” ตรงด้านบนของเพจ โดยเราจะแจ้งเตือนคุณเมื่อมีบทเรียนใหม่ออกมา ### 2. อย่าลืมที่จะแบ่งปันซอมบี้ของคุณให้เพื่อนดู -**_Share_** แบ่งปันซอมบี้ของคุณบน twitter และอื่นๆ (ใส่รูปหรือlink) +***Share*** แบ่งปันซอมบี้ของคุณบน twitter และอื่นๆ (ใส่รูปหรือlink) diff --git a/th/1/math.md b/th/1/math.md index 85b849fb5f..648c59062a 100644 --- a/th/1/math.md +++ b/th/1/math.md @@ -34,7 +34,7 @@ material: * Division (การหาร): `x / y` * Modulus / remainder (การหารเอาเศษ): `x % y` (ตัวอย่างเช่น`13 % 5` จะได้ `3` ออกมาเป็นเศษและคำตอบของโอเปอร์เรชั่นนี้)_ -นอกจากนี้ Solidity ยังรองรับ **_exponential operator_** อีกด้วย (เช่น x ยกกำลังy ,x^y): +นอกจากนี้ Solidity ยังรองรับ ***exponential operator*** อีกด้วย (เช่น x ยกกำลังy ,x^y): ``` uint x = 5 ** 2; // เท่ากับ 5^2 = 25 diff --git a/th/1/structs.md b/th/1/structs.md index b93722167d..21bcc5ba28 100644 --- a/th/1/structs.md +++ b/th/1/structs.md @@ -32,7 +32,7 @@ material: } --- -ในบางครั้งเราอาจจะต้องการชนิดของข้อมูลที่มีความซับซ้อนมากขึ้น โดยใน Solidity ได้เตรียมคำสั่ง **_structs_** ไว้ให้ +ในบางครั้งเราอาจจะต้องการชนิดของข้อมูลที่มีความซับซ้อนมากขึ้น โดยใน Solidity ได้เตรียมคำสั่ง ***structs*** ไว้ให้ ``` struct Person { diff --git a/th/1/web3js.md b/th/1/web3js.md index f0077904f5..d7517f5adc 100644 --- a/th/1/web3js.md +++ b/th/1/web3js.md @@ -12,7 +12,7 @@ material: Solidity contract ของเราก็เสร็จเรียบร้อยแล้ว! ตอนนี้ก็ได้เวลาของการเขียน JavaScript ที่จะไว้ใช้ด้านหน้าเพื่อ interact กับ contract แล้ว -Ethereum นั้นมี JavaScript library ชื่อว่า **_Web3.js_** +Ethereum นั้นมี JavaScript library ชื่อว่า ***Web3.js*** ในบทหลังๆ เราจะทำการเรียนรู้ในเชิงลึกเกี่ยวกับการนำ contract มาปรับใช้และติดตั้ง Web3.js แต่ในตอนนี้จะขอพูดถึงแค่ตัวอย่างของโค้ดว่า Web3.jsนั้น interact กับ contractที่นำมาปรับใช้ของเราอย่างไร diff --git a/th/2/10-interactingcontracts.md b/th/2/10-interactingcontracts.md index b29648f199..450a4f7cf5 100644 --- a/th/2/10-interactingcontracts.md +++ b/th/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ material: ## การมีปฎิสัมพันธ์กับ contract อื่น -หากอยากให้ contract ของเราสามารถสื่อสารกับ contract อื่นบน blockchain ได้ ก่อนอื่นจะต้องทำการ define **_interface_** ขึ้นเสียก่อน +หากอยากให้ contract ของเราสามารถสื่อสารกับ contract อื่นบน blockchain ได้ ก่อนอื่นจะต้องทำการ define ***interface*** ขึ้นเสียก่อน มาดูที่ตัวอย่างง่าย ๆ กันก่อนดีกว่า เช่น หากมี contract หนึ่งบน blockchain ที่มีหน้าตาดังนี้: @@ -131,7 +131,7 @@ contract LuckyNumber { สมมติว่าเรามี contract จากภายนอก (external contract) ที่ต้องการเข้ามาอ่านข้อมูลใน contract นี้โดยจะใช้ฟังก์ชั่น `getNum` -ก่อนอื่นเลยเราก็ต้อง define **_interface_** ของ contract ที่ชื่อ `LuckyNumber` ซะก่อน: +ก่อนอื่นเลยเราก็ต้อง define ***interface*** ของ contract ที่ชื่อ `LuckyNumber` ซะก่อน: ``` contract NumberInterface { diff --git a/th/2/2-mappings.md b/th/2/2-mappings.md index b9ab23121c..6dfcb31eb9 100644 --- a/th/2/2-mappings.md +++ b/th/2/2-mappings.md @@ -84,7 +84,7 @@ material: ## Addresses -blockchain ของ Ethereum ถูกสร้างขึ้นมาจาก **_accounts_** ซึ่งสามารถเปรียบเทียบได้กับบัญชีธนาคารที่เราใช้กันทั่วๆ ไป บัญชีนี้จะมียอดของ **_Ether_** (เป็นค่าเงินที่ใช้ภายใน blockchain บน Ethereum)และสามารถแลกเปลี่ยนการใช้จ่าย Ether payment ไปยังบัญชีอื่น ๆ ได้อีกด้วย ซึ่งเหมือนกับการโอนเงินผ่านบัญชีธนาคารไปยังบัญชีของผู้อื่นในโลกความเป็นจริงนั่นเอง +blockchain ของ Ethereum ถูกสร้างขึ้นมาจาก ***accounts*** ซึ่งสามารถเปรียบเทียบได้กับบัญชีธนาคารที่เราใช้กันทั่วๆ ไป บัญชีนี้จะมียอดของ ***Ether*** (เป็นค่าเงินที่ใช้ภายใน blockchain บน Ethereum)และสามารถแลกเปลี่ยนการใช้จ่าย Ether payment ไปยังบัญชีอื่น ๆ ได้อีกด้วย ซึ่งเหมือนกับการโอนเงินผ่านบัญชีธนาคารไปยังบัญชีของผู้อื่นในโลกความเป็นจริงนั่นเอง แต่ละบัญชีจะมี `address` ที่เปรียบเสมือนกับเลขบัญชีธนาคาร โดยจะมีความจำเพาะต่อบัญชีหนึ่งบัญชี เท่านั้น หน้าตาจะเป็นดังนี้้: @@ -98,7 +98,7 @@ blockchain ของ Ethereum ถูกสร้างขึ้นมาจา ## Mappings -ในบทเรียนที่ 1 เราให้ความสนใจกับ **_structs_** และ **_arrays_** **_Mappings_** เป็นอีกทางหนึ่งในการจัดเก็บข้อมูลที่เตรียมไว้ลงใน Solidity +ในบทเรียนที่ 1 เราให้ความสนใจกับ ***structs*** และ ***arrays*** ***Mappings*** เป็นอีกทางหนึ่งในการจัดเก็บข้อมูลที่เตรียมไว้ลงใน Solidity การให้นิยาม `mapping` จะมีหน้าตาดังนี้: diff --git a/th/2/5-inheritance.md b/th/2/5-inheritance.md index 3c06fcaf37..231dfd0cd8 100644 --- a/th/2/5-inheritance.md +++ b/th/2/5-inheritance.md @@ -95,7 +95,7 @@ material: ณ ตอนนี้โค้ดเกมของเราเริ่มมีความยาวในระดับหนึ่งแล้ว แทนที่เราจะบรรจุโค้ดยาวเหยียดลงใน contract เดียว การแบ่งท่อนโค้ดเพื่อบรรจุลงในหลายๆ contract ก็สามารถทำได้ โดยจะไม่บิดเบือนความหมายใดๆ และยังเป็นการจัดการโค้ดที่ดีอีกด้วย -ยังมี contract ที่เป็น feature หนึ่งใน Solidity ซึ่งช่วยในการจัดการก็คือ **_inheritance_**: +ยังมี contract ที่เป็น feature หนึ่งใน Solidity ซึ่งช่วยในการจัดการก็คือ ***inheritance***: ``` contract Doge { @@ -111,7 +111,7 @@ contract BabyDoge is Doge { } ``` -`BabyDoge` **_inherits_** มาจาก `Doge` หมายถึงหากเรามีการ compile และเรียก `BabyDoge` ขึ้น จะสามารถเข้าถึงได้ทั้งฟังก์ชั่น `catchphrase()` และ `anotherCatchphrase()` (และยังสามารถเข้าถึงฟังก์ชั่นชนิด public ใดๆ ก็ตามที่เราอาจเพิ่มเข้าไปใน `Doge`). +`BabyDoge` ***inherits*** มาจาก `Doge` หมายถึงหากเรามีการ compile และเรียก `BabyDoge` ขึ้น จะสามารถเข้าถึงได้ทั้งฟังก์ชั่น `catchphrase()` และ `anotherCatchphrase()` (และยังสามารถเข้าถึงฟังก์ชั่นชนิด public ใดๆ ก็ตามที่เราอาจเพิ่มเข้าไปใน `Doge`). วิธีนี้สามารถนำไปใช้ใน logical inheritance (อย่างเช่นใช้กับ subclass ว่า `Cat` นั้นเป็น `Animal`) นอกจากนี้ยังสามาถใช้เพื่อการจัดการโค้ดโดยการจัดกลุ่มให้ logic ที่มีความคล้ายคลึงกันให้อยู่ด้วยกันเป็นกลุ่มๆ diff --git a/th/2/7-storage.md b/th/2/7-storage.md index 8c22fe32b6..b47ed11396 100644 --- a/th/2/7-storage.md +++ b/th/2/7-storage.md @@ -71,12 +71,12 @@ material: ใน Solidity มีพื้นที่อยู่ 2 ตำแหน่งในการจัดเก็บตัวแปรต่างๆ — ภายใน `storage` และใน `memory` -**_Storage_** หมายถึงตัวแปรที่ถูกจัดเก็บอย่างถาวรบน blokchain -**_Memory_** หมายถึงตัวแปรที่ถูกจัดเก็บชั่วคราว และจะถูกลบออกไประหว่างที่ฟังก์ชั่นภายเรียกใช้ contract เปรียบเทียบความแตกต่างของ 2 สิ่ง ว่าเหมือนระหว่าง hard disk กับ RAM +***Storage*** หมายถึงตัวแปรที่ถูกจัดเก็บอย่างถาวรบน blokchain +***Memory*** หมายถึงตัวแปรที่ถูกจัดเก็บชั่วคราว และจะถูกลบออกไประหว่างที่ฟังก์ชั่นภายเรียกใช้ contract เปรียบเทียบความแตกต่างของ 2 สิ่ง ว่าเหมือนระหว่าง hard disk กับ RAM โดยทั่วไปแล้วเราไม่จำเป็นต้องมายุ่งกับ keyword พวกนี้เนื่องจาก Solidity จะจัดการให้ตั้งแต่แรกเริ่มแล้ว โดยแรกเริ่มแล้ว State variables (ตัวแปรที่ถูกประกาศค่าจากภายนอกฟังก์ชั่น) จะอยู่ใน `storage` และถูกเขียนอย่างถาวรลงใน blockchain ในขณะที่ตัวแปรที่ถูกประกาศค่าภายในฟังก์ชั่นจะอยู่ใน `memory` และจะหายไปเมื่อการเรียกฟังก์ชั่นนั้น ๆ ได้สิ้นสุดลง -อย่างไรก็ตาม อาจมีบางกรณีที่เราจะต้องมายุ่งกับคำพวกนี้ เช่นเมื่อต้องใช้ **_structs_** และ **_arrays_** ภายในฟังก์ชั่น: +อย่างไรก็ตาม อาจมีบางกรณีที่เราจะต้องมายุ่งกับคำพวกนี้ เช่นเมื่อต้องใช้ ***structs*** และ ***arrays*** ภายในฟังก์ชั่น: ``` contract SandwichFactory { diff --git a/th/3/01-externaldependencies.md b/th/3/01-externaldependencies.md index cb2ef9c0f5..721d30e702 100644 --- a/th/3/01-externaldependencies.md +++ b/th/3/01-externaldependencies.md @@ -143,7 +143,7 @@ material: ถึงตอนนี้ Solidity ก็มีหน้าตาไม่ต่างกับภาษาอื่นๆ เลย เช่น JavaScript แต่จริงๆ แล้วก็มีอีกหลายจุดที่ทำให้ Ethereum DApps ค่อนข้างจะแตกต่างจากแอพพลิเคชั่นทั่วไป -อันดับแรกขอกล่าวถึงการเริ่มต้นด้วย **_immutable_** หลังจากเราได้สร้าง contract ขึ้นมาบน Ethereum แล้ว ซึ่งนั้นก็แปลว่าเราไม่สามารถแก้ไขหรืออัพเดท contract ได้แล้ว +อันดับแรกขอกล่าวถึงการเริ่มต้นด้วย ***immutable*** หลังจากเราได้สร้าง contract ขึ้นมาบน Ethereum แล้ว ซึ่งนั้นก็แปลว่าเราไม่สามารถแก้ไขหรืออัพเดท contract ได้แล้ว โค้ดตัวแรกเริ่มที่ได้บรรจุลงไปใน contract จะอยู่อย่างนั้นแบบถาวร ถือว่าเป็นปัจจัยด้านความปลอดภัยอย่างหนึ่งที่เราจะต้องใส่ใจในการเขียน Solidity เพราะถ้าหากว่ามีข้อผิดพลาดในโค้ดของ contract แม้เพียง 1 จุด แน่นอนว่าคุณไม่สามารถกลับไปแก้ไขอะไรมันได้เลย และอาจจะต้องบอก users ไปตามตรงว่าให้ใช้ smart contract อื่นที่ได้แก้แล้วแทน diff --git a/th/3/02-ownable.md b/th/3/02-ownable.md index d7f49e17b1..6c94c3a358 100644 --- a/th/3/02-ownable.md +++ b/th/3/02-ownable.md @@ -189,7 +189,7 @@ material: ## OpenZeppelin's `Ownable` contract -ด้านล่างนี้คือ contract ชื่อ `Ownable` ที่รับมาจาก library ของ Solidity **_OpenZeppelin_** OpenZeppelin คือ library ของ secure and community-vetted smart contracts ที่สามารถนำมาใช้ใน DApps ของเรา หลังจากบทนี้เป็นต้นไป เราแนะนำว่าให้ลองไปดูเว็บไซต์นี้ได้ในขณะที่รอให้บทเรียนที่ 4 ออกมา เพื่อความเข้าใจที่มากยิ่งขึ้นของตัวคุณเอง! +ด้านล่างนี้คือ contract ชื่อ `Ownable` ที่รับมาจาก library ของ Solidity ***OpenZeppelin*** OpenZeppelin คือ library ของ secure and community-vetted smart contracts ที่สามารถนำมาใช้ใน DApps ของเรา หลังจากบทนี้เป็นต้นไป เราแนะนำว่าให้ลองไปดูเว็บไซต์นี้ได้ในขณะที่รอให้บทเรียนที่ 4 ออกมา เพื่อความเข้าใจที่มากยิ่งขึ้นของตัวคุณเอง! ลองอ่าน contract ด้านล่างคร่าวๆ ดู คุณจะพบบางอย่างที่เรายังไม่ได้ศึกษากัน แต่ไม่ต้องเป็นห่วงไปเพราะเราจะได้เรียนรู้กันแน่ๆ ในอนาคต @@ -233,7 +233,7 @@ contract Ownable { มานั่งไล่เรียงถึงสิ่งใหม่ๆ ที่เราเพิ่งจะเห็นเป็นครั้งแรกกัน: -- Constructors: `function Ownable()` คือ **_constructor_** ซึ่งเป็นฟังก์ชั่นพิเศษทางเลือก(optional special function) สามารถมีชื่อเดียวกับ contract ได้ ฟังก์ชั่นนี้จะถูกรันโค้ด เพียงแค่ครั้งเดียวในตอนที่ contract ถูกสร้างขึ้นมาครั้งแรก +- Constructors: `function Ownable()` คือ ***constructor*** ซึ่งเป็นฟังก์ชั่นพิเศษทางเลือก(optional special function) สามารถมีชื่อเดียวกับ contract ได้ ฟังก์ชั่นนี้จะถูกรันโค้ด เพียงแค่ครั้งเดียวในตอนที่ contract ถูกสร้างขึ้นมาครั้งแรก - Function Modifiers: `modifier onlyOwner()` Modifier จัดว่าเป็นฟังก์ชั่นแบบกึ่ง ที่จะถูกใช้ในการปรับแต่งฟังก์ชั่นอื่น ๆ โดยปกติจะใช้ในการเช็คลำดับของ requirement เวลาจะ execute ออกมา ในกรณีนี้ `onlyOwner` สามารถถูกใช้ในการจำกัดการเข้าใช้เพื่อให้ **เฉพาะ** แค่ **เจ้าของ หรือ owner** ของ contract จะสามารถใช้ function นี้ได้ เราจะกล่าวเพิ่มเติมเกี่ยวกับ function modifier ในบทถัดไป และประเด็นที่ว่าสัญลักษณ์ประหลาด `_;` ทำหน้าที่อะไร - `indexed` keyword: ในตอนนี้เรายังไม่จำเป็นต้องใช้มัน ฉะนั้น ยังไม่ต้องสนใจดีกว่า diff --git a/th/3/04-gas.md b/th/3/04-gas.md index a8c0291e55..5e9e8f5697 100644 --- a/th/3/04-gas.md +++ b/th/3/04-gas.md @@ -185,9 +185,9 @@ material: ## Gas — เชื้อเพลิงที่ Ethereum DApps ต้องใช้ -ใน Solidity ผู้ใช้จะต้องมีการชำระเงินทุกครั้งที่มีการรันโค้ดฟังก์ชั่น โดยเรียกสกุลเงินที่ใช้แลกเปลี่ยนว่า **_gas_** ผู้ใช้ต้องซื้อ gas ด้วย Ether (เป็นสกุลเงินบน Ethereum) นั่นหมายถึงผู้ใช้ของคุณจะต้องจ่าย ETH เพื่อที่จะรันโค้ดฟังก์ชั่นบน DApp +ใน Solidity ผู้ใช้จะต้องมีการชำระเงินทุกครั้งที่มีการรันโค้ดฟังก์ชั่น โดยเรียกสกุลเงินที่ใช้แลกเปลี่ยนว่า ***gas*** ผู้ใช้ต้องซื้อ gas ด้วย Ether (เป็นสกุลเงินบน Ethereum) นั่นหมายถึงผู้ใช้ของคุณจะต้องจ่าย ETH เพื่อที่จะรันโค้ดฟังก์ชั่นบน DApp -จำนวน gas ที่จำเป็นต้องใช้ในการรันฟังก์ชั่นนั้นขึ้นอยู่กับความซับซ้อนของ logic ซึ่งแต่ละโอเปอร์เรชั่นต่างก็มี **_gas cost_** ซึ่งมีค่าโดยคร่าวๆ ขึ้นกับปริมาณ resource ที่ต้องใช้ในการคำนวณของโอเปอเรชั่นนั้นๆ (ยกตัวอย่างเช่น การ write ลงบน storage จะมีค่ามากกว่าเพียงแค่การบวกข้อมูลชนิด integer สองตัว เป็นต้น) จำนวน **_gas cost_** รวมทั้งหมดในฟังก์ชั่นมาจากผลรวมระหว่าง gas cost รวมทั้งหมดของแต่ละโอเปอร์เรชั่น +จำนวน gas ที่จำเป็นต้องใช้ในการรันฟังก์ชั่นนั้นขึ้นอยู่กับความซับซ้อนของ logic ซึ่งแต่ละโอเปอร์เรชั่นต่างก็มี ***gas cost*** ซึ่งมีค่าโดยคร่าวๆ ขึ้นกับปริมาณ resource ที่ต้องใช้ในการคำนวณของโอเปอเรชั่นนั้นๆ (ยกตัวอย่างเช่น การ write ลงบน storage จะมีค่ามากกว่าเพียงแค่การบวกข้อมูลชนิด integer สองตัว เป็นต้น) จำนวน ***gas cost*** รวมทั้งหมดในฟังก์ชั่นมาจากผลรวมระหว่าง gas cost รวมทั้งหมดของแต่ละโอเปอร์เรชั่น เนื่องจากการรันฟังก์ชั่นจะทำให้ผู้ใช้ต้องเสียค่าใช้จ่ายจริงๆ ดังนั้นการเขียนโค้ดอย่างมีประสิทธิภาพ (code optimization) นับว่าเป็นสิ่งสำคัญอันดับต้นๆ บน Ethereum มากกว่าในภาษาโปรแกรมมิ่งอื่นๆ ถ้าหากว่าโค้ดของคุณไม่เป็นระเบียบเละเทะ ผู้ใช้ก็จะต้องเสียค่าใช้จ่ายมากขึ้นในการที่จะรันโค้ดฟังก์ชั่นออกมา — อาจจะมีมูลค่าถึงล้านดอลล่าร์ก็เป็นได้หากมีผู้ใช้จำนวนมหาศาล diff --git a/th/4/battle-02.md b/th/4/battle-02.md index dbc5321073..5229e0d6a1 100644 --- a/th/4/battle-02.md +++ b/th/4/battle-02.md @@ -244,7 +244,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; ### วิธีดังกล่าวจะค่อนข้างเสี่ยงต่อการถูกคุกคามโดย node อื่นที่ไว้ใจไม่ได้ -ใน Ethereum ถ้าหากมีการเรียกใช้ฟังก์ชั่นใน contract จะหมายถึงการ broadcast ออกไปยังหนึ่งหรือหลาย node บนเน็ตเวิร์คในรูปแบบของ **_transaction_** โดย node บนเน็ตเวิร์คก็จะทำการเก็บข้อมูลของ transaction ไว้เพื่อที่จะเป็นหน่วยแรกในการคำนวณต่าง ๆ - ปัญหาทางคณิตศาสตร์ขั้นสูงในรูปแบบของ "Proof of Work" และจากนั้นก็จะปล่อยกลุ่มข้อมูล transaction ออกมาร่วมกันกับ Proof of Work (PoW) นั้น ๆ ของมันซึ่งเป็นในรูปแบบ **_block_** ไปยังเน็ตเวิร์คที่เหลือ +ใน Ethereum ถ้าหากมีการเรียกใช้ฟังก์ชั่นใน contract จะหมายถึงการ broadcast ออกไปยังหนึ่งหรือหลาย node บนเน็ตเวิร์คในรูปแบบของ ***transaction*** โดย node บนเน็ตเวิร์คก็จะทำการเก็บข้อมูลของ transaction ไว้เพื่อที่จะเป็นหน่วยแรกในการคำนวณต่าง ๆ - ปัญหาทางคณิตศาสตร์ขั้นสูงในรูปแบบของ "Proof of Work" และจากนั้นก็จะปล่อยกลุ่มข้อมูล transaction ออกมาร่วมกันกับ Proof of Work (PoW) นั้น ๆ ของมันซึ่งเป็นในรูปแบบ ***block*** ไปยังเน็ตเวิร์คที่เหลือ เมื่อ node หนึ่งได้ทำการแก้ PoW จะทำให้ node อื่น ๆ ไม่เข้ามายุ่งเกี่ยวในการแก้ PoW นั้น ๆ ต่อมาจึงตรวจสอบว่าลิสต์ข้อมูล transaction ของ node อื่น มีความถูกต้องหรือไม่ แล้วสุดท้ายจึงจะทำการรับ block และเข้ามาและทำการแก้ block ถัดไปเรื่อย ๆ @@ -256,7 +256,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; ## แล้วจะทำอย่างไรเพื่อการสุ่มเลขอย่างปลอดภัยใน Ethereum กันดีล่ะ? -เนื่องจากผู้เข้าร่วมสามารถเห็นเนื้อหาทั้งหมดใน blockchain ได้ ทำให้นี่ถือว่าเป็นปัญหาที่ยากพอสมควร และการแก้ปัญหาก็นอกเหนือไปจากขอบเขตเนื้อหาที่เราจะสอนกันอีกด้วย ลองเข้าไปอ่านเนื้อหาใน this StackOverflow thread ดูได้นะ หนึ่งในนั้นจะเป็นไอเดียของการใช้ **_oracle_** ในการเข้าถึงฟังก์ชั่นสุ่มเลขจากภายนอกของ Ethereum blockchain +เนื่องจากผู้เข้าร่วมสามารถเห็นเนื้อหาทั้งหมดใน blockchain ได้ ทำให้นี่ถือว่าเป็นปัญหาที่ยากพอสมควร และการแก้ปัญหาก็นอกเหนือไปจากขอบเขตเนื้อหาที่เราจะสอนกันอีกด้วย ลองเข้าไปอ่านเนื้อหาใน this StackOverflow thread ดูได้นะ หนึ่งในนั้นจะเป็นไอเดียของการใช้ ***oracle*** ในการเข้าถึงฟังก์ชั่นสุ่มเลขจากภายนอกของ Ethereum blockchain และเนื่องจากมีอีกหลาย node บน Ethereum ภายในเน็ตเวิร์คที่ก็พยายามจะเข้ามาแก้ block ต่อไปเช่นกัน ความแตกต่างที่เราจะเข้าไปแก้ block ถัดไปเมื่อเทียบกับ node อื่น ๆ นั้นถือว่าน้อยมาก ซึ่งก็จะกินเวลาหรือทำให้เราสูญเสียกำไรไปในการคำนวณเป็นจำนวนมาก — แต่หากว่าผลลัพธ์ที่ได้มีสูงมากพอ(ยกตัวอย่างเช่นเราสามารถพนัน $100,000,000 ในฟังก์ชั่นโยนเหรียญได้) ก็ถือว่าคุ้มค่าในการที่จะเข้าโจมตี @@ -265,7 +265,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; เนื่องจากตอนนี้สิ่งที่เรากำลังสร้างยังเป็นแค่เกมง่าย ๆ สำหรับจะเป็น demo เท่านั้น และไม่ได้ใช้เงินจริง ๆ จึงอาจจะต้องยอมรับข้อเสียของการใช้ random number generator ซึ่งง่ายต่อการเขียนโค้ดไปก่อน ขอให้เป็นที่รู้กันนะว่าวิธีนี้ยังไม่ปลอดภัยเท่าไหร่นัก -บทเรียนในอนาคตนั้น เราจะสอนไปจนถึงการใช้ **_oracles_** (เป็นวิธีการที่ปลอดภัยในการดึงข้อมูลเข้ามาจากภายนอก Ethereum) ในการที่จะสร้างเลขสุ่มขึ้นมาอย่างปลอดภัยจากภายนอก blockchain +บทเรียนในอนาคตนั้น เราจะสอนไปจนถึงการใช้ ***oracles*** (เป็นวิธีการที่ปลอดภัยในการดึงข้อมูลเข้ามาจากภายนอก Ethereum) ในการที่จะสร้างเลขสุ่มขึ้นมาอย่างปลอดภัยจากภายนอก blockchain ## มาทดสอบกันเถอะ diff --git a/th/4/battle-08.md b/th/4/battle-08.md index 379beb1344..75bc1c5829 100644 --- a/th/4/battle-08.md +++ b/th/4/battle-08.md @@ -247,7 +247,7 @@ material: ## มาทดสอบกันเถอะ -1. สร้าง statement `if` ที่จะเช็คว่า `rand` มีค่าน้อยกว่าหรือเท่ากับ **_less than or equal to_** `attackVictoryProbability`หรือไม่ +1. สร้าง statement `if` ที่จะเช็คว่า `rand` มีค่าน้อยกว่าหรือเท่ากับ ***less than or equal to*** `attackVictoryProbability`หรือไม่ 2. ถ้า condition นั้นเป็นจริงก็แปลว่า ซอมบี้ของเราชนะ! หมายถึง: diff --git a/th/4/payable.md b/th/4/payable.md index f8db202083..2e24512005 100644 --- a/th/4/payable.md +++ b/th/4/payable.md @@ -229,7 +229,7 @@ material: } --- -จนถึงตอนนี้เราก็มีความรู้เล็กน้อยเกี่ยวกับ **_function modifiers_** แล้ว ซึ่งอาจจะยากในการที่จะสามารถจำทุก ๆ อย่างได้ ดังนั้นเรามา review กันแบบรวบรัดก็แล้วกัน: +จนถึงตอนนี้เราก็มีความรู้เล็กน้อยเกี่ยวกับ ***function modifiers*** แล้ว ซึ่งอาจจะยากในการที่จะสามารถจำทุก ๆ อย่างได้ ดังนั้นเรามา review กันแบบรวบรัดก็แล้วกัน: 1. เรามี visibility modifiers ในการควบคุมว่าเมื่อไหร่ หรือที่ไหนที่ฟังก์ชั่นจะถูกเรียกได้: `private` แปลว่าฟังก์ชั่นจะถูกเรียกได้จากฟังก์ชั่นอื่น ๆ ภายใน contract เท่านั้น ; `internal` เป็นเหมือนกัน `private` แต่จะสามารถถูกเรียกได้จาก contract ที่มีการ inherit มาจากตัวมัน; `external` สามารถเรียกฟังก์ชั่นนี้ได้จากภายนอก contract เท่านั้น; และสุดท้ายก็คือ `public` หมายถึงสามารถถูกเรียกจากที่ใดก็ได้ไม่ว่าจากภายในหรือภายนอกก็ตาม diff --git a/th/5/01-erc721-1.md b/th/5/01-erc721-1.md index 9129dd05f6..77156db122 100644 --- a/th/5/01-erc721-1.md +++ b/th/5/01-erc721-1.md @@ -242,11 +242,11 @@ material: } --- -มากล่าวถึง **_tokens_** กันบ้าง +มากล่าวถึง ***tokens*** กันบ้าง -ถ้าหากว่าคุ้นเคยกับการใช้ Ethereum space มาสักพัก เราอาจจะเคยได้ยินเกี่ยวกับ tokens กันมาบ้าง — หากเจาะลึกลงมาอีกหน่อย มันก็คือ **_ERC20 tokens_** นั่นเอง +ถ้าหากว่าคุ้นเคยกับการใช้ Ethereum space มาสักพัก เราอาจจะเคยได้ยินเกี่ยวกับ tokens กันมาบ้าง — หากเจาะลึกลงมาอีกหน่อย มันก็คือ ***ERC20 tokens*** นั่นเอง -**_token_** บน Ethereum จริงๆ แล้วก็คือ smart contract ที่เป็นไปตามกฏทั่วๆ ไป — เป็นการ implement ชุดฟังก์ชั่นพื้นฐานที่รับมาจาก token contracts อื่นๆ เช่น `transfer(address _to, uint256 _value)` และ `balanceOf(address _owner)` เป็นต้น +***token*** บน Ethereum จริงๆ แล้วก็คือ smart contract ที่เป็นไปตามกฏทั่วๆ ไป — เป็นการ implement ชุดฟังก์ชั่นพื้นฐานที่รับมาจาก token contracts อื่นๆ เช่น `transfer(address _to, uint256 _value)` และ `balanceOf(address _owner)` เป็นต้น ภายใน smart contract มักจะมีการ mapping `mapping(address => uint256) balances` ที่จะเป็นต้วเก็บข้อมูลว่าแต่ละ address มียอดคงเหลืออยู่เท่าไหร่ @@ -270,9 +270,9 @@ ERC20 token นั้นเจ๋งมากๆ ในหมวดหมู่ เหตุผลอย่างที่สองก็คือ จำนวนซอมบี้นั้นไม่ได้ถูกสร้างขึ้นมาอย่างเท่าเทียมกันทั้งหมด เช่น เจ้าซอมบี้เลเวล 2 ชื่อว่า "**Steve**" จะไม่ได้มีมูลค่าเท่ากับซอมบี้เลเวล 732 ที่ชื่อ "**H4XF13LD MORRIS 💯💯😎💯💯**" แน่นอน (ไม่ใกล้เคียงเลยด้วยซ้ำนะเจ้า *Steve*) -ยังมี token standard อื่นๆ ที่เหมาะสมมากกว่าทีจะใช้กับ crypto-collectibles ดังเช่น CryptoZombies ของเรา — token standard เหล่านั้นก็คือ **_ERC721 tokens._** +ยังมี token standard อื่นๆ ที่เหมาะสมมากกว่าทีจะใช้กับ crypto-collectibles ดังเช่น CryptoZombies ของเรา — token standard เหล่านั้นก็คือ ***ERC721 tokens.*** -แต่ละ **_ERC721 tokens_** นั้น **ไม่สามารถ** นำมาใช้แทนกันได้ เพราะแต่ละองค์ประกอบของมันล้วนแล้วแต่มีเอกลักษณ์ของตัวเอง นอกจากนี้ยังไม่สามารถแยกร่างได้อีกด้วย ซึ่งเราจะต้องแลกเปลี่ยนมันทั้งหมดเท่านั้น และแต่ละ token ก็จะมี ID ที่ไม่ซ้ำกันเลย นี่จึงเป็นเหตุผลที่ _ERC721 token เหมาะจะถูกนำมาใช้ในการสร้าง zombie ที่สามารถ trade ได้นั่นเอง +แต่ละ ***ERC721 tokens*** นั้น **ไม่สามารถ** นำมาใช้แทนกันได้ เพราะแต่ละองค์ประกอบของมันล้วนแล้วแต่มีเอกลักษณ์ของตัวเอง นอกจากนี้ยังไม่สามารถแยกร่างได้อีกด้วย ซึ่งเราจะต้องแลกเปลี่ยนมันทั้งหมดเท่านั้น และแต่ละ token ก็จะมี ID ที่ไม่ซ้ำกันเลย นี่จึงเป็นเหตุผลที่ _ERC721 token เหมาะจะถูกนำมาใช้ในการสร้าง zombie ที่สามารถ trade ได้นั่นเอง > จำไว้ว่าการใช้ ERC721 มีข้อดีในเรื่องของการที่เราไม่ต้องโค้ด auction หรือ escrow logic ลงภายใน contract ในการคิดวิธี trade / sell ซอมบี้เลยแม้แต่น้อย โดยหากเราสามารถยืนยันสเปคได้ ผู้อื่นก็จะสามารถสร้าง exchange platform ขึ้นมาสำหรับ crypto-tradable ERC721 assets และ ERC721 zombies ก็จะสามารถใช้การได้ใน platform นั้นทันที ซึี่งนี่ก็เป็นข้อดีที่ชัดเจนมากๆ ในการใช้ token standard แทนที่จะมานั่งคิด trading logic ของเราเอง diff --git a/th/5/09-safemath-1.md b/th/5/09-safemath-1.md index cab9a9323f..506d621a6d 100644 --- a/th/5/09-safemath-1.md +++ b/th/5/09-safemath-1.md @@ -396,7 +396,7 @@ material: เราจะมาดู feature เกี่ยวกับความปลอดภัยหลักๆ ที่จำเป็นจะต้องคำนึงถึงในการเขียน smart contract ใดๆ ก็ตาม: นั่นคือการป้องกัน overflows และ underflows -แล้ว **_overflow_** คืออะไรกันล่ะเนี่ย? +แล้ว ***overflow*** คืออะไรกันล่ะเนี่ย? ให้สมมติว่าเรามี `uint8` ซึ่งจะสามารถมีได้เพียง 8 bit แปลว่าหากจำนวนที่สูงที่สุดที่เราสามารถเก็บได้คือเลข binary `11111111` (หากเป็นในรูปของ decimal ก็คือ 2^8 - 1 = 255) @@ -415,11 +415,11 @@ number++; ### การใช้ SafeMath -ในการป้องกันเหตุการณ์ดังกล่าว OpenZeppelin จึงได้สร้าง **_library_** ที่มีชื่อว่า SafeMath ซึ่งช่วยในการป้องกันกรณีต่างๆ ตั้งแต่แรกเริ่ม +ในการป้องกันเหตุการณ์ดังกล่าว OpenZeppelin จึงได้สร้าง ***library*** ที่มีชื่อว่า SafeMath ซึ่งช่วยในการป้องกันกรณีต่างๆ ตั้งแต่แรกเริ่ม แต่ก่อนที่เราจะไปถึงเรื่องราวตรงส่วนนั้น... library นั้นคืออะไร? - **_library_** คือ contract ชนิดพิเศษใน Solidity โดย library จะมีประโยชน์มากๆ ในการ attach ฟังก์ชั่นต่างๆ ให้กับ native data type นั่นเอง + ***library*** คือ contract ชนิดพิเศษใน Solidity โดย library จะมีประโยชน์มากๆ ในการ attach ฟังก์ชั่นต่างๆ ให้กับ native data type นั่นเอง ยกตัวอย่างการใช้ SafeMath library เราจะใช้ syntax `using SafeMath for uint256` SafeMath library มีฟังก์ชั่นอยู่ 4 ฟังก์ชั่น ได้แก่ — `add`, `sub`, `mul`, และ `div` และเราสามารถใช้ฟังก์ชั่นดังกล่าวนี้จาก `uint256` ดังนี้: diff --git a/th/5/13-comments.md b/th/5/13-comments.md index fb5770cf3f..4593a672fd 100644 --- a/th/5/13-comments.md +++ b/th/5/13-comments.md @@ -416,7 +416,7 @@ contract CryptoZombies { โดยส่วนใหญ่แล้วนับว่าเป็นนิสัยที่ดีในการ comment โค้ดบ่อยๆ เพื่ออธิบาย behavior ที่เราคาดว่าจะเกิดจากแต่ละฟังก์ชั่นใน contract ของเรา วิธีนี้จะทำให้นักพัฒนาท่านอื่นๆ (หรือแม้แต่ตัวคุณเองที่อาจจะห่างหายไปจากโปรเจคเป็นเวลา 6 เดือน!) สามารถมองโค้ดผ่านๆ แล้วเข้าใจได้อย่างลึกซึ้งว่าโค้ดของเราได้ทำอะไรไปบางโดยที่ไม่ต้องไปนั่งอ่านตัวโค้ดให้ลายตา -มาตรฐานภายใน Solidity community นั้นคือการใช้ format ที่เรียกว่า **_natspec_** ที่จะมีหน้าตาดังนี้: +มาตรฐานภายใน Solidity community นั้นคือการใช้ format ที่เรียกว่า ***natspec*** ที่จะมีหน้าตาดังนี้: ``` /// @title A contract for basic math operations diff --git a/th/5/14-wrappingitup.md b/th/5/14-wrappingitup.md index 9d2e8cc647..4806b99bba 100644 --- a/th/5/14-wrappingitup.md +++ b/th/5/14-wrappingitup.md @@ -33,6 +33,6 @@ material: ในบทนี้เราได้ครอบคลุมโค้ด Solidity ทั้งหมดสำหรับเกมของเราไปเป็นที่เรียบร้อย! (ในตอนนี้— เราอาจเพิ่มบทเรียนเข้ามาอีกในอนาคตอันใกล้) -ในอีก 2 บทเรียนนับจากนี้ เราจะได้เรียนรู้เกี่ยวกับการ deploy contract และการ interact กับมันโดยใช้ **_web3.js_** (ซึ่งจะทำให้สามารถสร้าง front-end ของ DApp ออกมาได้ในที่สุด) +ในอีก 2 บทเรียนนับจากนี้ เราจะได้เรียนรู้เกี่ยวกับการ deploy contract และการ interact กับมันโดยใช้ ***web3.js*** (ซึ่งจะทำให้สามารถสร้าง front-end ของ DApp ออกมาได้ในที่สุด) เดินหน้าต่อไปและอย่าลืมเปลี่ยนชื่อซอมบี้หากต้องการ จากนั้นก็มุ่งหน้าไปยังบทถัดไปเพื่อจบบทนี้กันได้แล้ว diff --git a/th/6/01.md b/th/6/01.md index 204ef5db46..18d461ebc1 100644 --- a/th/6/01.md +++ b/th/6/01.md @@ -365,7 +365,7 @@ material: หลังจบบทที่ 5 กันไป zombie DApp ของเราในตอนนี้ก็ถือว่าค่อนข้างดูดีพอสมควร ต่อไปนี้จะถึงช่วงของการสร้างเว็บเพจอย่างง่ายเพื่อให้ผู้ใช้สามารถ interact กับมันได้นั่นเอง -ใช่แล้ว เรากำลังจะสร้างมันขึ้นมาโดยการใช้ library ของ JavaScript จาก the Ethereum Foundation ที่เรียกว่า **_Web3.js_** กัน +ใช่แล้ว เรากำลังจะสร้างมันขึ้นมาโดยการใช้ library ของ JavaScript จาก the Ethereum Foundation ที่เรียกว่า ***Web3.js*** กัน ## Web3.js คืออะไรกันล่ะ? @@ -375,7 +375,7 @@ material: 2. ฟังก์ชั่นที่เราต้องการเรียกใช้ 3. ตัวแปรต่างๆ หรือ variable ที่เราต้องการใส่มันลงไปในฟังก์ชั่น -Ethereum node สามารถใช้ภาษา **_JSON-RPC_** ได้เท่านั้น ซึ่งเป็นภาษาที่อ่านได้ง่ายมากๆ (human-readable) การ query อกกมา เพื่อบอก node ที่เราต้องการเรียกใช้ฟังก์ชั่นบน contract ก็จะมีหน้าตาประมาณนี้: +Ethereum node สามารถใช้ภาษา ***JSON-RPC*** ได้เท่านั้น ซึ่งเป็นภาษาที่อ่านได้ง่ายมากๆ (human-readable) การ query อกกมา เพื่อบอก node ที่เราต้องการเรียกใช้ฟังก์ชั่นบน contract ก็จะมีหน้าตาประมาณนี้: ``` // ใช่แล้ว... ขอให้โชคดีกับการเขียนฟังก์ชั่นทั้งหมดด้วยรูปแบบนี้ก็แล้วกัน! diff --git a/th/6/02.md b/th/6/02.md index d385df2b72..406916173b 100644 --- a/th/6/02.md +++ b/th/6/02.md @@ -384,11 +384,11 @@ material: เยี่ยมมาก! ตอนนี้ Web3.js ก็ได้ถูกเพิ่มเข้ามาในโปรเจ็กต์แล้ว ได้เวลาของการกำหนดค่าเริ่มต้นและทำให้มันสามารถสื่อสารกับ blockchain ได้กันเถอะ -สิ่งแรกที่เราต้องมีก็คือ **_Web3 Provider_** +สิ่งแรกที่เราต้องมีก็คือ ***Web3 Provider*** -คงจำกันได้นะว่า Ethereum ถูกสร้างขึ้นจาก **_node หลายๆ node รวมกัน_** ซึ่งทั้งหมดจะแชร์ส่วน copy ของข้อมูลที่เหมือนกัน การตั้งค่า Web3 Provider ภายใน Web3.js จะเป็นเหมือนการบอกโค้ดของเราว่า **node ไหน** ที่เราจะสื่อสารด้วยในการรับมือกับ read และ write ของเรา ซึ่งตรงนี้ก็จะคล้ายๆ กับการตั้ง URL ให้กับ web server ที่อยู่ในระยะไกลเพื่อใช้ใน API calls ของเราใน web app ดั้งเดิมนั่นเอง +คงจำกันได้นะว่า Ethereum ถูกสร้างขึ้นจาก ***node หลายๆ node รวมกัน*** ซึ่งทั้งหมดจะแชร์ส่วน copy ของข้อมูลที่เหมือนกัน การตั้งค่า Web3 Provider ภายใน Web3.js จะเป็นเหมือนการบอกโค้ดของเราว่า **node ไหน** ที่เราจะสื่อสารด้วยในการรับมือกับ read และ write ของเรา ซึ่งตรงนี้ก็จะคล้ายๆ กับการตั้ง URL ให้กับ web server ที่อยู่ในระยะไกลเพื่อใช้ใน API calls ของเราใน web app ดั้งเดิมนั่นเอง -จริงๆ แล้วเราสามารถเป็น host ให้กับ Ethereum node ของเราเองในฐานะ provider ได้เลย แต่ถึงอย่างนั้นก็ยังมีผู้ให้บริการจากภายนอก (third-party service) ที่สามารถช่วยให้งานของเรานั้นง่ายขึ้นตรงที่ว่าเราจะได้ไม่ต้องรักษา Ethereum node เอาไว้กับตัวในการจัดเตรียม DApp ให้ผู้ใช้ของเรายังไงล่ะ — จะกล่าวถึง **_Infura_** นั่นเอง +จริงๆ แล้วเราสามารถเป็น host ให้กับ Ethereum node ของเราเองในฐานะ provider ได้เลย แต่ถึงอย่างนั้นก็ยังมีผู้ให้บริการจากภายนอก (third-party service) ที่สามารถช่วยให้งานของเรานั้นง่ายขึ้นตรงที่ว่าเราจะได้ไม่ต้องรักษา Ethereum node เอาไว้กับตัวในการจัดเตรียม DApp ให้ผู้ใช้ของเรายังไงล่ะ — จะกล่าวถึง ***Infura*** นั่นเอง ## Infura @@ -408,7 +408,7 @@ var web3 = new Web3(new Web3.providers.WebsocketProvider("wss://mainnet.infura.i Cryptography นั้นถือได้ว่ามีความซับซ้อนมากๆ แปลว่าหากเราไม่ได้เป็นปรมาจารย์ในเรื่องของ security และไม่รู้ว่าเรากำลังทำอะไรอยู่ มันก็จะเป็นเรื่องที่ไม่ดีเท่าไหร่หากจะจัดการ private key ของผู้ใช้ด้วยตัวเองบน front-end ในแอพพลิเคชั่นของเรา -แต่ ! โชคดีที่ว่าเราไม่จำเป็นจะต้องลงมือทำเรื่องพวกนี้ด้วยตัวเองอยู่แล้ว — เพราะมี service อีกมากมายที่สามารถให้บริการเราในการรับมือมันได้ ที่นิยมที่สุดก็คือ **_Metamask_** +แต่ ! โชคดีที่ว่าเราไม่จำเป็นจะต้องลงมือทำเรื่องพวกนี้ด้วยตัวเองอยู่แล้ว — เพราะมี service อีกมากมายที่สามารถให้บริการเราในการรับมือมันได้ ที่นิยมที่สุดก็คือ ***Metamask*** ## Metamask diff --git a/th/6/03.md b/th/6/03.md index 3cde729a43..3d9f6ec3fb 100644 --- a/th/6/03.md +++ b/th/6/03.md @@ -861,7 +861,7 @@ material: หลังจากเราได้ทำการ initialized เจ้า Web3.js ด้วย web3 provider ของ MetaMask ไปเป็นที่เรียบร้อย มาทำให้มันสามารถสื่อสารกับ smart contract ของเราได้กันดีกว่า -Web3.js ต้องการ 2 สิ่งในการจะสื่อสารกับ contract ได้ นั่นก็คือ: **_address_** และ **_ABI_** ของมันเอง +Web3.js ต้องการ 2 สิ่งในการจะสื่อสารกับ contract ได้ นั่นก็คือ: ***address*** และ ***ABI*** ของมันเอง ## Contract Address @@ -873,7 +873,7 @@ Web3.js ต้องการ 2 สิ่งในการจะสื่อส ## Contract ABI -อีกสิ่งหนึ่งที่ Web3.js จะต้องใช้ในการสื่อสารกับ contract ก็คือ **_ABI_** ของมันเอง +อีกสิ่งหนึ่งที่ Web3.js จะต้องใช้ในการสื่อสารกับ contract ก็คือ ***ABI*** ของมันเอง ABI ย่อมาจาก Application Binary Interface กล่าวคือมันเป็น representation ของ method ภายใน contract ของเราในรูปแบบของ JSON format ที่จะบอก Web3.js เกี่ยวกับการจัดเรียงรูปแบบส่วนของ function call ต่างๆ ที่ contract ของเราจะสามารถเข้าใจได้ diff --git a/tr/1/arrays.md b/tr/1/arrays.md index be87fb27b5..7fc81ed96b 100644 --- a/tr/1/arrays.md +++ b/tr/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -Bir şeyin bir koleksiyonunu istediğinizde, bir **_sıralama_** (array) kullanabilirsiniz. Solidity'de iki tür sıralama vardır: **_sabit_** sıralamalar ve **_dinamik_** sıralamalar: +Bir şeyin bir koleksiyonunu istediğinizde, bir ***sıralama*** (array) kullanabilirsiniz. Solidity'de iki tür sıralama vardır: ***sabit*** sıralamalar ve ***dinamik*** sıralamalar: ``` // İki öğeli sabit uzunlukta sıralama: @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -**_Yapılar_**'ın bir sıralamasını da oluşturabilirsiniz. Önceki bölümün `Person` yapısını kullanarak: +***Yapılar***'ın bir sıralamasını da oluşturabilirsiniz. Önceki bölümün `Person` yapısını kullanarak: ``` Person[] people; // dinamik Sıralama, ona eklemeyi sürdürebiliriz. @@ -60,7 +60,7 @@ Durum değişkenlerinin blok zincirinde kalıcı olarak saklandığını hatırl ## Genel Sıralamalar -Bir sıralamayı `public` olarak ilan edebilirsiniz ve Solidity otomatik olarak onun için bir **_gaz alıcı_** oluşturacak. Söz dizimi şöyle görünüyor: +Bir sıralamayı `public` olarak ilan edebilirsiniz ve Solidity otomatik olarak onun için bir ***gaz alıcı*** oluşturacak. Söz dizimi şöyle görünüyor: ``` Person[] public people; @@ -72,4 +72,4 @@ Diğer kontratlar daha sonra bu diziyi okuyabilir (ancak yazamaz). Bu genel veri Uygulamamızda bir zombi ordusu depolamak isteyeceğiz. Ve zombilerimizi tüm diğer uygulamalara göstermek isteyeceğiz, böylece onun genel olmasını isteyeceğiz. -1. `Zombie` **_yapıları_**'nın bir genel sıralamasını oluştur ve onu `zombies` olarak isimlendir. +1. `Zombie` ***yapıları***'nın bir genel sıralamasını oluştur ve onu `zombies` olarak isimlendir. diff --git a/tr/1/datatypes.md b/tr/1/datatypes.md index 15f3376cce..9e603f18ed 100644 --- a/tr/1/datatypes.md +++ b/tr/1/datatypes.md @@ -25,7 +25,7 @@ material: Aferin! Şimdi kontratımız için bir iskelet bulduk, hadi Solidity'nin değişkenlerle nasıl iş yaptığını öğrenelim. -**_Hal_değişkenleri_** kontrat deposunda kalıcı olarak depolanır. Bu Ethereum blok zinciri için yazıldığı anlamına gelir. Onları bir veritabanına yazmak gibi düşünün. +***Hal_değişkenleri*** kontrat deposunda kalıcı olarak depolanır. Bu Ethereum blok zinciri için yazıldığı anlamına gelir. Onları bir veritabanına yazmak gibi düşünün. ##### Örnek: ``` diff --git a/tr/1/events.md b/tr/1/events.md index 6f9b4d629d..6614fee802 100644 --- a/tr/1/events.md +++ b/tr/1/events.md @@ -73,9 +73,9 @@ material: } --- -Kontratımız neredeyse bitti! Hadi şimdi bir **_etkinlik_** ekleyelim. +Kontratımız neredeyse bitti! Hadi şimdi bir ***etkinlik*** ekleyelim. -**_Etkinlikler_** kontratınız için blok zincirinde olan birşeyin uygulamanızın başlangıç aşamasına iletilmesi için belirli etkinlikler için ‘dinlenebilen’ ve olduğunda harekete geçebilen bir yoldur. +***Etkinlikler*** kontratınız için blok zincirinde olan birşeyin uygulamanızın başlangıç aşamasına iletilmesi için belirli etkinlikler için ‘dinlenebilen’ ve olduğunda harekete geçebilen bir yoldur. Örnek: diff --git a/tr/1/functions3.md b/tr/1/functions3.md index 91c5b35d6d..d6b48d1849 100644 --- a/tr/1/functions3.md +++ b/tr/1/functions3.md @@ -53,7 +53,7 @@ material: } --- -Bu bölümde, Fonksiyon **_değerleri getirmeyi_** ve fonksiyon değiştiricileri öğreneceğiz. +Bu bölümde, Fonksiyon ***değerleri getirmeyi*** ve fonksiyon değiştiricileri öğreneceğiz. ## Değerleri Getirme @@ -73,13 +73,13 @@ Solidity'de, fonksiyon ifadesi değer getirme türü içerir (bu durumda `string Yukardaki fonksiyon aslında Solidity'de durumu değiştirmez — örn. bir değeri değiştirmez veya hiçbir şey yazmaz. -Yani bu durumda onu, veriyi görüntüleyen fakat değiştirmeyen anlamında **_görüntü_** fonksiyonu olarak ifade edebilirdik: +Yani bu durumda onu, veriyi görüntüleyen fakat değiştirmeyen anlamında ***görüntü*** fonksiyonu olarak ifade edebilirdik: ``` function sayHello() public view returns (string) { ``` -Solidity ayrıca uygulamadaki bir veriye tam erişemediğiniz anlamına gelen **_saf_** fonksiyonlar içerir. Aşağıdaki duruma bakın: +Solidity ayrıca uygulamadaki bir veriye tam erişemediğiniz anlamına gelen ***saf*** fonksiyonlar içerir. Aşağıdaki duruma bakın: ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -Bu fonksiyon uygulamanın durumundan tam okumuyor — getirdiği değer sadece kendi fonksiyon parametrelerine bağlıdır. Yani bu durumda fonksiyonu **_saf_** olarak ifade edebiliriz. +Bu fonksiyon uygulamanın durumundan tam okumuyor — getirdiği değer sadece kendi fonksiyon parametrelerine bağlıdır. Yani bu durumda fonksiyonu ***saf*** olarak ifade edebiliriz. > Not: Fonksiyonların ne zaman saf/görüntü olarak işaretleneceğini hatırlamak zor olabilir. Neyse ki Solidity derleyicisi, bu değiştiricilerden birini ne zaman kullanmanız gerektiğini bildiren uyarıların verilmesi konusunda iyidir. diff --git a/tr/1/lessoncomplete.md b/tr/1/lessoncomplete.md index 4f2e78953b..7d3987edc3 100644 --- a/tr/1/lessoncomplete.md +++ b/tr/1/lessoncomplete.md @@ -14,8 +14,8 @@ Oyunu daha da ileriye götürmek ve zombi ordunuzun büyümesini sürdürmek iç ### 1. İlerlemenizi kaydetmek için oturum açın -Sayfanın üstündeki "İlerlemeyi Kaydet" linkine tıklayarak ilerlemenizi kaydetmek için **_Oturum aç_**. Yeni bir ders eklediğimizde size bildireceğiz. +Sayfanın üstündeki "İlerlemeyi Kaydet" linkine tıklayarak ilerlemenizi kaydetmek için ***Oturum aç***. Yeni bir ders eklediğimizde size bildireceğiz. ### 2. Zombinizi arkadaşlarınızla paylaşın -Zombinizi Twitter falan **_Paylaşın_** (Görüntüler / linkler eklemek gerek) +Zombinizi Twitter falan ***Paylaşın*** (Görüntüler / linkler eklemek gerek) diff --git a/tr/1/math.md b/tr/1/math.md index 7d714ed3ef..38619f9c71 100644 --- a/tr/1/math.md +++ b/tr/1/math.md @@ -34,7 +34,7 @@ Solidity'de matematik oldukça anlaşılırdır. Aşağıdaki işlemler çoğu p * Bölme: `x / y` * Modül / artan: `x % y` _(örneğin, `13 % 5` `3`tür, çünkü 13'ü 5'e bölerseniz, kalan 3'tür)_ -Solidity ayrıca bir **_üstel operatör_** destekler (örn. "x'in y üstü", x^y): +Solidity ayrıca bir ***üstel operatör*** destekler (örn. "x'in y üstü", x^y): ``` uint x = 5 ** 2; // 5^2 = 25'e eşittir diff --git a/tr/1/structs.md b/tr/1/structs.md index f1c2797eb7..e6a92a0799 100644 --- a/tr/1/structs.md +++ b/tr/1/structs.md @@ -32,7 +32,7 @@ material: } --- -Bazen daha karışık bir veri türüne ihtiyacınız olur. Bunun için, Solidity **_yapılar_** sağlar: +Bazen daha karışık bir veri türüne ihtiyacınız olur. Bunun için, Solidity ***yapılar*** sağlar: ``` struct Person { diff --git a/tr/1/web3js.md b/tr/1/web3js.md index 1bbaecc2b9..8d9208c82f 100644 --- a/tr/1/web3js.md +++ b/tr/1/web3js.md @@ -12,7 +12,7 @@ material: Solidity kontratımız tamamlandı! Şimdi kontrat ile etkileşen bir JavaScript ön yüzü yazmamız gerek. -Ethereum **_Web3.js_** denilen bir JavaScript kütüphanesine sahip. +Ethereum ***Web3.js*** denilen bir JavaScript kütüphanesine sahip. Sonraki bir derste, bir kontratın nasıl dağıtılacağının ve Web3.js kurulumunun derinlerine ineceğiz. Fakat şimdilik, Web3.js'nin sevk edilmiş kontratla nasıl etkileşeceğine ilişkin bazı örnek kodlara bakalım. diff --git a/tr/2/10-interactingcontracts.md b/tr/2/10-interactingcontracts.md index f557ca70dd..950acb749e 100644 --- a/tr/2/10-interactingcontracts.md +++ b/tr/2/10-interactingcontracts.md @@ -109,7 +109,7 @@ Endişelenme — oyunumuz aslında herhangi birinin CryptoKitty'sine zarar verm ## Diğer kontratlarla etkileşime girmek -Blok zincirinde sahip olmadığımız başka bir kontratla kontratımızın görüşmesi için, ilk olarak bir **_arayüz_** belirlememiz gerek. +Blok zincirinde sahip olmadığımız başka bir kontratla kontratımızın görüşmesi için, ilk olarak bir ***arayüz*** belirlememiz gerek. Bir basit örneği inceleyelim. Blok zincirinde bunun gibi bir kontratın olduğunu farz edelim: @@ -131,7 +131,7 @@ Bu, herhangi birinin şanslı numarasını depolayabileceği basit bir kontrat o Şimdi `getNum` fonksiyonunu kullanarak bu kontratta verileri okumak istediğimiz harici bir kontrat yaptığımızı farz edelim. -İlk olarak `LuckyNumber` kontratın bir **_arayüzünü_** tanımlamamız gerekirdi: +İlk olarak `LuckyNumber` kontratın bir ***arayüzünü*** tanımlamamız gerekirdi: ``` contract NumberInterface { diff --git a/tr/2/2-mappings.md b/tr/2/2-mappings.md index e356f3e24e..19f6304756 100644 --- a/tr/2/2-mappings.md +++ b/tr/2/2-mappings.md @@ -84,7 +84,7 @@ To do this, Bunu yapmak için, 2 yeni veri türüne ihtiyacımı olacak: `mappin ## Addresler -Ethereum blok zinciri banka hesapları gibi düşünebileceğiniz **_hesaplardan_**. Bir hesabın **_Ether_** (Ethereum blok zincirinde kullanılan para birimi) bakiyesi vardır ve banka hesabınızın diğer banka hespalarına elektronik para transferi yapabildiği gibi diğer hesaplara Ether ödemeleri gönderebilir ve alabilirsiniz. +Ethereum blok zinciri banka hesapları gibi düşünebileceğiniz ***hesaplardan***. Bir hesabın ***Ether*** (Ethereum blok zincirinde kullanılan para birimi) bakiyesi vardır ve banka hesabınızın diğer banka hespalarına elektronik para transferi yapabildiği gibi diğer hesaplara Ether ödemeleri gönderebilir ve alabilirsiniz. Her hesap bir banka hesap numarası gibi düşünebileceğiniz bir `address'`'e sahiptir. O, hesabı işaret eden özel bir tanımlayıcıdır ve bunun gibi görünür: @@ -98,7 +98,7 @@ Yani, zombilerimizin sahipliği için onu bir özel kimlik olarak kullanabiliriz ## Haritalandırmalar -Ders 1'de **_yapılar_** ve **_sıralamalar_**'a baktık. **_Haritalandırmalar_** Solidiy'de organize edilen verilerin depolanmasının başka bir yoludur. +Ders 1'de ***yapılar*** ve ***sıralamalar***'a baktık. ***Haritalandırmalar*** Solidiy'de organize edilen verilerin depolanmasının başka bir yoludur. Bunun gibi bir `mapping` tanımlamak: diff --git a/tr/2/5-inheritance.md b/tr/2/5-inheritance.md index 7302f17247..fa05806225 100644 --- a/tr/2/5-inheritance.md +++ b/tr/2/5-inheritance.md @@ -95,7 +95,7 @@ material: Oyun kodumuz oldukça uzun. Son derece uzun bir kontrat yapmaktansa, bazen kodu organize etmek için kod mantığınızı çoğlu kontratlara bölmek onu anlamlı yapar. -Bunu daha yönetilebilir yapan Solidity'nin bir özelliği de kontrat **_mirası_**: +Bunu daha yönetilebilir yapan Solidity'nin bir özelliği de kontrat ***mirası***: ``` contract Doge { @@ -111,7 +111,7 @@ contract BabyDoge is Doge { } ``` -`Doge`'den `BabyDoge` **_mirasları_**. Bu, `BabyDoge`'u derleyip açarsanız hem `catchphrase()` hem de `anotherCatchphrase()` erişimine sahip olacağı anlamına gelir (ve `Doge`'da belirtebileceğimiz her bir diğer genel fonksiyonlar). +`Doge`'den `BabyDoge` ***mirasları***. Bu, `BabyDoge`'u derleyip açarsanız hem `catchphrase()` hem de `anotherCatchphrase()` erişimine sahip olacağı anlamına gelir (ve `Doge`'da belirtebileceğimiz her bir diğer genel fonksiyonlar). Bu mantıklı miras için kullanılılabilir (bir alt sınıfla olduğu gibi, bir `Cat` bir `Animal`'dır). Fakat ayrıca farklı sınıflar içine benzer mantığı birlikte gruplayarak kodunuzu organize etmek için basitçe kullanılabilir. diff --git a/tr/2/7-storage.md b/tr/2/7-storage.md index f1ce4290f6..1eb7bca93d 100644 --- a/tr/2/7-storage.md +++ b/tr/2/7-storage.md @@ -71,11 +71,11 @@ material: Solidity'de, değişkenleri depolayacağınız iki yer vardır — `storage` ve `memory`. -**_Depolama_** değişkenlerin kalıcı olarak blok zincirinde depolanmasını işaret eder. **_Hafıza_** değişkenleri geçicidir ve kontratınızı çağıran harici fonksiyon arasında silinir. Bilgisayarınızın hard diski ve RAM'i gibi düşünün. +***Depolama*** değişkenlerin kalıcı olarak blok zincirinde depolanmasını işaret eder. ***Hafıza*** değişkenleri geçicidir ve kontratınızı çağıran harici fonksiyon arasında silinir. Bilgisayarınızın hard diski ve RAM'i gibi düşünün. Çoğu zaman Solidity onları varsayılan olarak işlediğinden bu anahtar kelimeleri kullanmanız gerekmez. Durum değişkenleri (fonksiyonların dışında tanımlanmış) fonksiyonların içinde belirlenen değişkenler `memory` iken ve fonksiyon bitir çağırdığında gözden kaybolacakken varsayılan `storage` ve kalıcı olarak blok zincirine yazılır. -Ancak, **_yapılar_** ve **_sıralar_** ile fonksiyon içine yaklaşım zamanı olarak adlandırılan bu anahtarlara ihtiyacınız olmadığında süreler vardır.: +Ancak, ***yapılar*** ve ***sıralar*** ile fonksiyon içine yaklaşım zamanı olarak adlandırılan bu anahtarlara ihtiyacınız olmadığında süreler vardır.: ``` contract SandwichFactory { diff --git a/zh/1/arrays.md b/zh/1/arrays.md index 8157c2d329..f3d37915a7 100644 --- a/zh/1/arrays.md +++ b/zh/1/arrays.md @@ -39,7 +39,7 @@ material: } --- -如果你想建立一个集合，可以用 **_数组_**这样的数据类型. Solidity 支持两种数组: **_静态_** 数组和**_动态_** 数组: +如果你想建立一个集合，可以用 ***数组***这样的数据类型. Solidity 支持两种数组: ***静态*** 数组和***动态*** 数组: ``` // 固定长度为2的静态数组: @@ -50,7 +50,7 @@ string[5] stringArray; uint[] dynamicArray; ``` -你也可以建立一个 **_结构体_**类型的数组 例如，上一章提到的 `Person`: +你也可以建立一个 ***结构体***类型的数组 例如，上一章提到的 `Person`: ``` Person[] people; // 这是动态数组，我们可以不断添加元素 @@ -60,7 +60,7 @@ Person[] people; // 这是动态数组，我们可以不断添加元素 ## 公共数组 -你可以定义 `public` 数组, Solidity 会自动创建 **_getter_** 方法. 语法如下: +你可以定义 `public` 数组, Solidity 会自动创建 ***getter*** 方法. 语法如下: ``` Person[] public people; diff --git a/zh/1/datatypes.md b/zh/1/datatypes.md index 45b9cf679d..ef764e130a 100644 --- a/zh/1/datatypes.md +++ b/zh/1/datatypes.md @@ -25,7 +25,7 @@ material: 真棒！我们已经为我们的合约做了一个外壳， 下面学习 Solidity 中如何使用变量。 -**_状态变量_**是被永久地保存在合约中。也就是说它们被写入以太币区块链中. 想象成写入一个数据库。 +***状态变量***是被永久地保存在合约中。也就是说它们被写入以太币区块链中. 想象成写入一个数据库。 ##### 例子: ``` diff --git a/zh/1/functions3.md b/zh/1/functions3.md index 59b99bb469..c32100262f 100644 --- a/zh/1/functions3.md +++ b/zh/1/functions3.md @@ -73,13 +73,13 @@ Solidity 里，函数的定义里可包含返回值的数据类型(如本例中 上面的函数实际上没有改变 Solidity 里的状态，即，它没有改变任何值或者写任何东西。 -这种情况下我们可以把函数定义为 **_view_**, 意味着它只能读取数据不能更改数据: +这种情况下我们可以把函数定义为 ***view***, 意味着它只能读取数据不能更改数据: ``` function sayHello() public view returns (string) { ``` -Solidity 还支持 **_pure_** 函数, 表明这个函数甚至都不访问应用里的数据，例如： +Solidity 还支持 ***pure*** 函数, 表明这个函数甚至都不访问应用里的数据，例如： ``` function _multiply(uint a, uint b) private pure returns (uint) { @@ -87,7 +87,7 @@ function _multiply(uint a, uint b) private pure returns (uint) { } ``` -这个函数甚至都不读取应用里的状态 — 它的返回值完全取决于它的输入参数，在这种情况下我们把函数定义为 **_pure_**. +这个函数甚至都不读取应用里的状态 — 它的返回值完全取决于它的输入参数，在这种情况下我们把函数定义为 ***pure***. > 注：可能很难记住何时把函数标记为 pure/view。 幸运的是， Solidity 编辑器会给出提示，提醒你使用这些修饰符。 diff --git a/zh/1/lessoncomplete.md b/zh/1/lessoncomplete.md index 5330517417..9a40b7d297 100644 --- a/zh/1/lessoncomplete.md +++ b/zh/1/lessoncomplete.md @@ -13,8 +13,8 @@ material: 这只是开始，我们每周都会发布新的 CryptoZombies 课程, 进一步开发我们的游戏，不断壮大我们的僵尸部队。 ### 1. 登录能保存你的学习进程 -**_Sign in_** 保存学习进程点击页面顶部的 "Save Progress"。 一旦我们发布新的课程，我们会立即通知你。 +***Sign in*** 保存学习进程点击页面顶部的 "Save Progress"。 一旦我们发布新的课程，我们会立即通知你。 ### 2. 和你的朋友分享你的僵尸吧！ -**_Share_** 在微博、Twitter等平台分享(需要插入图像／链接) +***Share*** 在微博、Twitter等平台分享(需要插入图像／链接) diff --git a/zh/1/math.md b/zh/1/math.md index be90b5dfca..c2f3355071 100644 --- a/zh/1/math.md +++ b/zh/1/math.md @@ -34,7 +34,7 @@ material: * 除法: `x / y` * 取模 / 求余: `x % y` _(例如, `13 % 5` 余 `3`, 因为13除以5，余3)_ -Solidity 还支持 **_乘方操作_** (如：x 的 y次方） // 例如： 5 ** 2 = 25 +Solidity 还支持 ***乘方操作*** (如：x 的 y次方） // 例如： 5 ** 2 = 25 ``` uint x = 5 ** 2; // equal to 5^2 = 25 ``` diff --git a/zh/1/web3js.md b/zh/1/web3js.md index 1d777c845a..6fbbd82355 100644 --- a/zh/1/web3js.md +++ b/zh/1/web3js.md @@ -12,7 +12,7 @@ material: 我们的 Solidity 合约完工了！ 现在我们要写一段 JavaScript 前端代码来调用这个合约。 -以太坊有一个 JavaScript 库，名为**_Web3.js_**。 +以太坊有一个 JavaScript 库，名为***Web3.js***。 在后面的课程里，我们会进一步地教你如何安装一个合约，如何设置Web3.js。 但是现在我们通过一段代码来了解 Web3.js 是如何和我们发布的合约交互的吧。 diff --git a/zh/10/00-overview.md b/zh/10/00-overview.md index 045c45dd91..0bf4266b95 100644 --- a/zh/10/00-overview.md +++ b/zh/10/00-overview.md @@ -10,15 +10,15 @@ position: 2 已经有一段时间了，现在就来兑现诺言吧！ -本课中，我们将教你如何使用 **_Truffle_** 部署到 **_以太坊_**。 +本课中，我们将教你如何使用 ***Truffle*** 部署到 ***以太坊***。 当然，不仅限于此。你还会学到如何将智能合约部署到 **Loom** 😎。 -为什么要部署到 **Loom**？毕竟，**_以太坊_** 才是最安全的网络。 +为什么要部署到 **Loom**？毕竟，***以太坊*** 才是最安全的网络。 是的，我们完全同意。但在以太坊上每个事务都要耗费 _gas_, 因此你的用户就必须为每个事务付费。而且，每个事务确认还得等上至少10秒。 -简而言之，**_在以太坊上，所有事务都受益于相同的安全保障_**。对于面向用户的 dapp 或游戏等，往往并不一定需要这种级别的安全性。事实上，它只会破坏用户体验。 +简而言之，***在以太坊上，所有事务都受益于相同的安全保障***。对于面向用户的 dapp 或游戏等，往往并不一定需要这种级别的安全性。事实上，它只会破坏用户体验。 在 **Loom** 上, 用户可以有更快速且零 gas 的事务。这使得 **Loom** 更适合游戏或面向用户的 dapp。 diff --git a/zh/10/01.md b/zh/10/01.md index aec98e601a..f2b33f2ea2 100644 --- a/zh/10/01.md +++ b/zh/10/01.md @@ -23,7 +23,7 @@ material: 但还差很重要的一部分。 -没错……你还需要学下如何**_将智能合约部署到以太坊_**。 +没错……你还需要学下如何***将智能合约部署到以太坊***。 如果你有前端开发的背景，你可能已经习惯了众多的工具，如 *Webpack、Gulp、Browserify*，它们确实让开发过程变得简单很多。 @@ -36,7 +36,7 @@ material: - 轻松编译智能合约 - ABI 自动生成 - 集成智能合约测试 —— 甚至支持 `Mocha` 和``Chai`！ -- 支持多个网络。代码可以部署到 Rinkeby、**_以太坊_**、甚至 **Loom**。 后面我们也会带你了解 😉 +- 支持多个网络。代码可以部署到 Rinkeby、***以太坊***、甚至 **Loom**。 后面我们也会带你了解 😉 如果你的电脑上已经安装了 `npm` 和 `node`，我们希望你安装 `Truffle` 并设置为全球模式。 diff --git a/zh/10/02.md b/zh/10/02.md index 60faae63a5..03f3593902 100644 --- a/zh/10/02.md +++ b/zh/10/02.md @@ -48,14 +48,14 @@ truffle.js 在 `CryptoZombies` 目录里，`truffle init` 会创建几个目录以及一些 JavaScript 和 Solidity 文件。让我们仔细看看: - - **_contracts_**: **Truffle** 会在在这里找到我们所有的智能合约。为了保持代码有序，我们甚至可以创建诸如 `contracts/tokens` 之类的嵌套文件夹。很简洁吧 😉。 + - ***contracts***: **Truffle** 会在在这里找到我们所有的智能合约。为了保持代码有序，我们甚至可以创建诸如 `contracts/tokens` 之类的嵌套文件夹。很简洁吧 😉。 >注意: `truffle init` 会自动添加一个叫 `Migrations.sol` 的合约以及相应的迁移文件。后面我们会对其进行解释。 - - **_migrations_**: 迁移是一个 JavaScript 文件，它告诉 `truffle` 如何部署智能合约。 + - ***migrations***: 迁移是一个 JavaScript 文件，它告诉 `truffle` 如何部署智能合约。 - - **_test_**: 这里我们会放单元测试，它们是 JavaScript 或 Solidity 文件。请记住，合约一旦部署，就不能再更改，因此在部署之前对智能合约进行测试是非常重要的。 + - ***test***: 这里我们会放单元测试，它们是 JavaScript 或 Solidity 文件。请记住，合约一旦部署，就不能再更改，因此在部署之前对智能合约进行测试是非常重要的。 - - **_truffle.js_** 和 **_truffle-config.js_**: 这些是配置文件，用于存储部署所需的网络设置。**Truffle** 需要两个配置文件，因为 Windows 上 `truffle.js` 和 `truffle.exe` 存在于同一个文件夹可能会产生冲突。长话短说 —— 如果你在运行 Windows，建议你删除 `truffle.js` 并使用 `truffle-config.js` 作为默认配置文件。查看 **Truffle** 的官方文件，以进一步了解。 + - ***truffle.js*** 和 ***truffle-config.js***: 这些是配置文件，用于存储部署所需的网络设置。**Truffle** 需要两个配置文件，因为 Windows 上 `truffle.js` 和 `truffle.exe` 存在于同一个文件夹可能会产生冲突。长话短说 —— 如果你在运行 Windows，建议你删除 `truffle.js` 并使用 `truffle-config.js` 作为默认配置文件。查看 **Truffle** 的官方文件，以进一步了解。 但是我为什么要使用这个目录结构呢？我不太习惯，而且它看起来很复杂…… @@ -67,7 +67,7 @@ truffle.js ## truffle-hdwallet-provider -在本课中，我们将使用 _Infura_ 来把代码部署到 **_以太坊_**。这样，我们的用户便可以直接运行该应用程序，他们无需设置自己的 **_以太坊_** 节点或钱包。然而，为了保证安全，_Infura_ 不管理私钥，这也意味着它不能代表我们签署事务易。由于部署智能合约需要 **Truffle** 签署事务，所以我们将需要一个叫做 `truffle-hdwallet-provider` 的工具。它惟一的目的就是处理事务签名。 +在本课中，我们将使用 _Infura_ 来把代码部署到 ***以太坊***。这样，我们的用户便可以直接运行该应用程序，他们无需设置自己的 ***以太坊*** 节点或钱包。然而，为了保证安全，_Infura_ 不管理私钥，这也意味着它不能代表我们签署事务易。由于部署智能合约需要 **Truffle** 签署事务，所以我们将需要一个叫做 `truffle-hdwallet-provider` 的工具。它惟一的目的就是处理事务签名。 >注意: 也许你会问，为什么我们不在上一章安装 `truffle-hdwallet-provider`, 使用像下面这样的命令： diff --git a/zh/10/03.md b/zh/10/03.md index 065526cce3..ee1d1cf1d4 100644 --- a/zh/10/03.md +++ b/zh/10/03.md @@ -27,7 +27,7 @@ material: 你会问，为什么我们需要编译？ -_以太坊虚拟机_ 不能直接理解我们写的 Solidity 源代码。因此，我们需要运行一个编译器，将智能合约“翻译”成机器可读的 **_bytecode_** （字节码）。然后，虚拟机执行字节码，并完成智能合约所需的操作。 +_以太坊虚拟机_ 不能直接理解我们写的 Solidity 源代码。因此，我们需要运行一个编译器，将智能合约“翻译”成机器可读的 ***bytecode*** （字节码）。然后，虚拟机执行字节码，并完成智能合约所需的操作。 好奇字节码长什么样？来看看： @@ -51,7 +51,7 @@ function add(uint16 a, uint16 b) internal returns (uint16) { } ``` -如果我们要编译这个函数，Solidity 编译器会给出 **_警告_**: +如果我们要编译这个函数，Solidity 编译器会给出 ***警告***: ``` safemath.sol:110:11: Warning: Function state mutability can be restricted to pure diff --git a/zh/10/04.md b/zh/10/04.md index 49c3eb6cfa..b4fca91c69 100644 --- a/zh/10/04.md +++ b/zh/10/04.md @@ -18,13 +18,13 @@ material: }; --- -通常在部署到 **_以太坊_** 之前，你需要在本地测试智能合约。你可以使用一个名为 Ganache 的工具来实现，这个工具会设置本地 **_以太坊_** 网络。 +通常在部署到 ***以太坊*** 之前，你需要在本地测试智能合约。你可以使用一个名为 Ganache 的工具来实现，这个工具会设置本地 ***以太坊*** 网络。 然而，尽管测试非常重要，但它需要一整节课来讲解 —— 所以本节课我们会继续讲解部署。如果你非常想了解有关测试的更多知识，建议你学习我们另一课：使用 Truffle 测试智能合约。 -要部署到 **_以太坊_**，我们将需要创建一个叫 **migration（迁移）**的东西。 +要部署到 ***以太坊***，我们将需要创建一个叫 **migration（迁移）**的东西。 -迁移是帮助 **Truffle** 将代码部署到 **_以太坊_** 的 JavaScript 文件。注意，`truffle init` 创建了一个名为 `Migrations.sol` 的特殊合约，它会跟踪你对代码所做的更改。它的原理是将更改记录保存在链上。 因此，你将永远不会两次部署相同的代码。 +迁移是帮助 **Truffle** 将代码部署到 ***以太坊*** 的 JavaScript 文件。注意，`truffle init` 创建了一个名为 `Migrations.sol` 的特殊合约，它会跟踪你对代码所做的更改。它的原理是将更改记录保存在链上。 因此，你将永远不会两次部署相同的代码。 ## 创建一个新的迁移 diff --git a/zh/10/05.md b/zh/10/05.md index 2800c0e2ca..bba5187102 100644 --- a/zh/10/05.md +++ b/zh/10/05.md @@ -57,13 +57,13 @@ material: 在部署之前还有一件事要做。我们必须编辑配置文件，来告诉 **Truffle** 我们想要部署到哪些网络。 -等一下？不是只有一个 **_以太坊_** 网络嘛，是我错过什么了吗/ +等一下？不是只有一个 ***以太坊*** 网络嘛，是我错过什么了吗/ ## 以太坊测试网络 -好几个 **_以太坊_** 公共测试网络允许你在将合约部署到主网之前免费测试（请记住，一旦将合约部署到主网后，就不能再更改了）。这些测试网使用与主网不同的共识算法（通常是PoA），为鼓励全面测试，Ether 免费试用。Ether is free to encourage thorough testing. +好几个 ***以太坊*** 公共测试网络允许你在将合约部署到主网之前免费测试（请记住，一旦将合约部署到主网后，就不能再更改了）。这些测试网使用与主网不同的共识算法（通常是PoA），为鼓励全面测试，Ether 免费试用。Ether is free to encourage thorough testing. -在这节课中，我们将使用 **_Rinkeby_** —— 由以太坊基金会创建的公共测试网络。 +在这节课中，我们将使用 ***Rinkeby*** —— 由以太坊基金会创建的公共测试网络。 ## truffle.js 配置文件 @@ -116,7 +116,7 @@ var mnemonic = "onions carrots beans ..."; ### 为 Rinkeby 和以太坊主网设置 Truffle -接下来，为了确保 **Truffle** “知道”我们想要部署到哪些网络，我们必须创建两个单独的对象 —— 一个用于 Rinkeby，另一个用于 **_以太坊_** 主网: +接下来，为了确保 **Truffle** “知道”我们想要部署到哪些网络，我们必须创建两个单独的对象 —— 一个用于 Rinkeby，另一个用于 ***以太坊*** 主网: ```JavaScript networks: { diff --git a/zh/10/lessoncomplete.md b/zh/10/lessoncomplete.md index d3fbb18e98..d490809b92 100644 --- a/zh/10/lessoncomplete.md +++ b/zh/10/lessoncomplete.md @@ -9,9 +9,9 @@ material: 你已经掌握了使用 **Truffle** 部署智能合约的技能! -请记住，在 **_Loom_** 上构建将为你带来更快速、无 gas 的事务，是你创建区块链游戏和面向用户型 dapp 的完美选择。与此同时，你的用户也将享受到以太坊提供的安全保障! +请记住，在 ***Loom*** 上构建将为你带来更快速、无 gas 的事务，是你创建区块链游戏和面向用户型 dapp 的完美选择。与此同时，你的用户也将享受到以太坊提供的安全保障! -另一点也请记住，部署到 **_Loom_** 与部署到以太网差不多。你已经知道具体怎么实现，下一个项目就请选择使用最适合你的吧 😉。 +另一点也请记住，部署到 ***Loom*** 与部署到以太网差不多。你已经知道具体怎么实现，下一个项目就请选择使用最适合你的吧 😉。 当然，这只是一个示例 —— 我们做了几个决定，简化流程，使课程更容易理解。 diff --git a/zh/11/00-overview.md b/zh/11/00-overview.md index ce21a5d3aa..2ab5373089 100644 --- a/zh/11/00-overview.md +++ b/zh/11/00-overview.md @@ -12,7 +12,7 @@ position: 1 稍等…… 你可能已经想到了 _一些事情_。毕竟，合约一旦部署到主网后，它们将永远存在于那里。即使里面有错误，也依然在那里，就像不死的僵尸。 -每个程序员都会出错误或 _**bugs**_，不管他们技术多厉害。犯大错的可能性虽然不大，比如让攻击僵尸有100%胜算这类的错误，但还是有可能发生的。 +每个程序员都会出错误或 ***bugs***，不管他们技术多厉害。犯大错的可能性虽然不大，比如让攻击僵尸有100%胜算这类的错误，但还是有可能发生的。 很明显，给攻击方100%的胜利意味着你所写的已经不再是游戏了，甚至一点意思都没有。像这样的 bug 会让你的游戏死无葬身之地，就连神仙也救不了你的僵尸。 diff --git a/zh/11/02.md b/zh/11/02.md index 086e6bb820..1b220b4fa3 100644 --- a/zh/11/02.md +++ b/zh/11/02.md @@ -35,7 +35,7 @@ material: const myAwesomeContract = artifacts.require(“myAwesomeContract”); ``` -该函数返回一个叫 **_contract abstraction （合约抽象）_** 的东西。简而言之，_合约抽象_ 隐藏与 **以太坊** 交互的复杂性，并为我们的 _Solidity_ 智能合约提供便利的 _JavaScript_ 接口。我们将在后面的章节中使用到它。 +该函数返回一个叫 ***contract abstraction （合约抽象）*** 的东西。简而言之，_合约抽象_ 隐藏与 **以太坊** 交互的复杂性，并为我们的 _Solidity_ 智能合约提供便利的 _JavaScript_ 接口。我们将在后面的章节中使用到它。 ### contract() 函数 diff --git a/zh/11/04.md b/zh/11/04.md index 50f54fd25f..0c98406149 100644 --- a/zh/11/04.md +++ b/zh/11/04.md @@ -35,12 +35,12 @@ material: 通常，每个测试都有以下几个阶段: - 1. **_设置_**：定义初始状态并对输入进行初始化。 + 1. ***设置***：定义初始状态并对输入进行初始化。 - 2. **_行动_**：对代码进行实际测。始终确保 _只测试一个东西_。 + 2. ***行动***：对代码进行实际测。始终确保 _只测试一个东西_。 - 3. **_断言_**：检查结果。 + 3. ***断言***：检查结果。 来详细看看我们的测试会做什么。 diff --git a/zh/11/06.md b/zh/11/06.md index 956e8968bf..e3c67c8c91 100644 --- a/zh/11/06.md +++ b/zh/11/06.md @@ -95,7 +95,7 @@ beforeEach(async () => { ### 🧟‍♂️这里有…… 各种各样的僵尸! ! !🧟‍♂️ -如果你真的真的想达到 **_精通_**，请继续往下读。否则…… 直接点击下一步，就可以进入下一章了。 +如果你真的真的想达到 ***精通***，请继续往下读。否则…… 直接点击下一步，就可以进入下一章了。 还在吗？😁 diff --git a/zh/11/10.md b/zh/11/10.md index 1e54bf4285..ca9c5dfded 100644 --- a/zh/11/10.md +++ b/zh/11/10.md @@ -120,7 +120,7 @@ material: - Alice 批准 Bob 拿走 ERC721 代币。接下来，Alice 转移 ERC721 代币。 -这两种场景的区别在于 _**谁**_ 来调用实际的转移，是 Alice 还是 Bob。 +这两种场景的区别在于 ***谁*** 来调用实际的转移，是 Alice 还是 Bob。 这样解释就还蛮简单的，对吧？ diff --git a/zh/11/14.md b/zh/11/14.md index 9f5c3ccc9b..c97db58cf9 100644 --- a/zh/11/14.md +++ b/zh/11/14.md @@ -107,11 +107,11 @@ material: 厉害！你肯定有好好练习。 -现在，如果不向你展示如何在 **_Loom_** 测试网上进行测试，本教程就不完整啦。 +现在，如果不向你展示如何在 ***Loom*** 测试网上进行测试，本教程就不完整啦。 -回想一下我们之前的课程，在 **_Loom_** 上，用户可以比在**以太坊**上有更快、更且无 gas 的事务。这使得 DAppChain 更适合游戏或面向用户的 DApp。 +回想一下我们之前的课程，在 ***Loom*** 上，用户可以比在**以太坊**上有更快、更且无 gas 的事务。这使得 DAppChain 更适合游戏或面向用户的 DApp。 -而且，你知道吗？在 **Loom** 上部署和测试没有任何不同。我们已经为你总结了在 **_Loom_** 上测试所需要做的，快来看下吧。 +而且，你知道吗？在 **Loom** 上部署和测试没有任何不同。我们已经为你总结了在 ***Loom*** 上测试所需要做的，快来看下吧。 ## 为在 **Loom** 上测试配置 Truffle diff --git a/zh/2/5-inheritance.md b/zh/2/5-inheritance.md index 51d5517277..e6145f0d65 100644 --- a/zh/2/5-inheritance.md +++ b/zh/2/5-inheritance.md @@ -111,7 +111,7 @@ contract BabyDoge is Doge { } ``` -由于 `BabyDoge` 是从 `Doge` 那里 **_inherits_** （继承)过来的。 这意味着当你编译和部署了 `BabyDoge`，它将可以访问 `catchphrase()` 和 `anotherCatchphrase()`和其他我们在 `Doge` 中定义的其他公共函数。 +由于 `BabyDoge` 是从 `Doge` 那里 ***inherits*** （继承)过来的。 这意味着当你编译和部署了 `BabyDoge`，它将可以访问 `catchphrase()` 和 `anotherCatchphrase()`和其他我们在 `Doge` 中定义的其他公共函数。 这可以用于逻辑继承（比如表达子类的时候，`Cat` 是一种 `Animal`）。 但也可以简单地将类似的逻辑组合到不同的合约中以组织代码。 diff --git a/zh/2/7-storage.md b/zh/2/7-storage.md index c94b984ff1..a1d18cceec 100644 --- a/zh/2/7-storage.md +++ b/zh/2/7-storage.md @@ -71,7 +71,7 @@ material: 在 Solidity 中，有两个地方可以存储变量 —— `storage` 或 `memory`。 -**_Storage_** 变量是指永久存储在区块链中的变量。 **_Memory_** 变量则是临时的，当外部函数对某合约调用完成时，内存型变量即被移除。 你可以把它想象成存储在你电脑的硬盘或是RAM中数据的关系。 +***Storage*** 变量是指永久存储在区块链中的变量。 ***Memory*** 变量则是临时的，当外部函数对某合约调用完成时，内存型变量即被移除。 你可以把它想象成存储在你电脑的硬盘或是RAM中数据的关系。 大多数时候你都用不到这些关键字，默认情况下 Solidity 会自动处理它们。 状态变量（在函数之外声明的变量）默认为“存储”形式，并永久写入区块链；而在函数内部声明的变量是“内存”型的，它们函数调用结束后消失。 diff --git a/zh/3/01-externaldependencies.md b/zh/3/01-externaldependencies.md index 1726a8c9fe..5512e55b6d 100644 --- a/zh/3/01-externaldependencies.md +++ b/zh/3/01-externaldependencies.md @@ -145,7 +145,7 @@ material: 但是，在有几点以太坊上的 DApp 跟普通的应用程序有着天壤之别。 -第一个例子，在你把智能协议传上以太坊之后，它就变得**_不可更改_**, 这种永固性意味着你的代码永远不能被调整或更新。 +第一个例子，在你把智能协议传上以太坊之后，它就变得***不可更改***, 这种永固性意味着你的代码永远不能被调整或更新。 你编译的程序会一直，永久的，不可更改的，存在以太坊上。这就是 Solidity 代码的安全性如此重要的一个原因。如果你的智能协议有任何漏洞，即使你发现了也无法补救。你只能让你的用户们放弃这个智能协议，然后转移到一个新的修复后的合约上。 diff --git a/zh/3/04-gas.md b/zh/3/04-gas.md index f121855189..8ab9edb06b 100644 --- a/zh/3/04-gas.md +++ b/zh/3/04-gas.md @@ -186,13 +186,13 @@ material: ## Gas - 驱动以太坊DApps的能源 -在 Solidity 中，你的用户想要每次执行你的 DApp 都需要支付一定的 **_gas_**，gas 可以用以太币购买，因此，用户每次跑 DApp 都得花费以太币。 +在 Solidity 中，你的用户想要每次执行你的 DApp 都需要支付一定的 ***gas***，gas 可以用以太币购买，因此，用户每次跑 DApp 都得花费以太币。 -一个 DApp 收取多少 gas 取决于功能逻辑的复杂程度。每个操作背后，都在计算完成这个操作所需要的计算资源，（比如，存储数据就比做个加法运算贵得多）， 一次操作所需要花费的 **_gas_** 等于这个操作背后的所有运算花销的总和。 +一个 DApp 收取多少 gas 取决于功能逻辑的复杂程度。每个操作背后，都在计算完成这个操作所需要的计算资源，（比如，存储数据就比做个加法运算贵得多）， 一次操作所需要花费的 ***gas*** 等于这个操作背后的所有运算花销的总和。 由于运行你的程序需要花费用户的真金白银，在以太坊中代码的编程语言，比其他任何编程语言都更强调优化。同样的功能，使用笨拙的代码开发的程序，比起经过精巧优化的代码来，运行花费更高，这显然会给成千上万的用户带来大量不必要的开销。 -## 为什么要用 **_gas_** 来驱动？ +## 为什么要用 ***gas*** 来驱动？ 以太坊就像一个巨大、缓慢、但非常安全的电脑。当你运行一个程序的时候，网络上的每一个节点都在进行相同的运算，以验证它的输出 —— 这就是所谓的“去中心化” 由于数以千计的节点同时在验证着每个功能的运行，这可以确保它的数据不会被被监控，或者被刻意修改。 diff --git a/zh/4/battle-02.md b/zh/4/battle-02.md index 242e265c54..e548b1a047 100644 --- a/zh/4/battle-02.md +++ b/zh/4/battle-02.md @@ -249,7 +249,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; ### 这个方法很容易被不诚实的节点攻击 -在以太坊上, 当你在和一个合约上调用函数的时候, 你会把它广播给一个节点或者在网络上的 **_transaction_** 节点们。 网络上的节点将收集很多事务, 试着成为第一个解决计算密集型数学问题的人，作为“工作证明”，然后将“工作证明”(Proof of Work, PoW)和事务一起作为一个 **_block_** 发布在网络上。 +在以太坊上, 当你在和一个合约上调用函数的时候, 你会把它广播给一个节点或者在网络上的 ***transaction*** 节点们。 网络上的节点将收集很多事务, 试着成为第一个解决计算密集型数学问题的人，作为“工作证明”，然后将“工作证明”(Proof of Work, PoW)和事务一起作为一个 ***block*** 发布在网络上。 一旦一个节点解决了一个PoW, 其他节点就会停止尝试解决这个 PoW, 并验证其他节点的事务列表是有效的，然后接受这个节点转而尝试解决下一个节点。 @@ -261,7 +261,7 @@ uint random2 = uint(keccak256(now, msg.sender, randNonce)) % 100; ## 所以我们该如何在以太坊上安全地生成随机数呢 -因为区块链的全部内容对所有参与者来说是透明的， 这就让这个问题变得很难，它的解决方法不在本课程讨论范围，你可以阅读 这个 StackOverflow 上的讨论 来获得一些主意。 一个方法是利用 **_oracle_** 来访问以太坊区块链之外的随机数函数。 +因为区块链的全部内容对所有参与者来说是透明的， 这就让这个问题变得很难，它的解决方法不在本课程讨论范围，你可以阅读 这个 StackOverflow 上的讨论 来获得一些主意。 一个方法是利用 ***oracle*** 来访问以太坊区块链之外的随机数函数。 当然， 因为网络上成千上万的以太坊节点都在竞争解决下一个区块，我能成功解决下一个区块的几率非常之低。 这将花费我们巨大的计算资源来开发这个获利方法 — 但是如果奖励异常地高(比如我可以在硬币翻转函数中赢得 1个亿)， 那就很值得去攻击了。 diff --git a/zh/4/battle-08.md b/zh/4/battle-08.md index d50a2bb059..d34bfd8839 100644 --- a/zh/4/battle-08.md +++ b/zh/4/battle-08.md @@ -249,7 +249,7 @@ material: ## 实战演习 -1. 创建一个 `if` 语句来检查 `rand` 是不是 **_小于或者等于_** `attackVictoryProbability`。 +1. 创建一个 `if` 语句来检查 `rand` 是不是 ***小于或者等于*** `attackVictoryProbability`。 2. 如果以上条件为 `true`， 我们的僵尸就赢了！所以： diff --git a/zh/4/payable.md b/zh/4/payable.md index d1a4bb77ec..3f11e78118 100644 --- a/zh/4/payable.md +++ b/zh/4/payable.md @@ -229,7 +229,7 @@ material: } --- -截至目前，我们只接触到很少的 **_函数修饰符_**。 要记住所有的东西很难，所以我们来个概览： +截至目前，我们只接触到很少的 ***函数修饰符***。 要记住所有的东西很难，所以我们来个概览： 1. 我们有决定函数何时和被谁调用的可见性修饰符: `private` 意味着它只能被合约内部调用； `internal` 就像 `private` 但是也能被继承的合约调用； `external` 只能从合约外部调用；最后 `public` 可以在任何地方调用，不管是内部还是外部。 diff --git a/zh/5/01-erc721-1.md b/zh/5/01-erc721-1.md index 55c4398f4e..1118a9ebcf 100644 --- a/zh/5/01-erc721-1.md +++ b/zh/5/01-erc721-1.md @@ -244,11 +244,11 @@ material: } --- -让我们来聊聊 **_代币_**. +让我们来聊聊 ***代币***. -如果你对以太坊的世界有一些了解，你很可能听过人们聊到代币——尤其是 **_ERC20 代币_**. +如果你对以太坊的世界有一些了解，你很可能听过人们聊到代币——尤其是 ***ERC20 代币***. -一个 **_代币_** 在以太坊基本上就是一个遵循一些共同规则的智能合约——即它实现了所有其他代币合约共享的一组标准函数，例如 `transfer(address _to, uint256 _value)` 和 `balanceOf(address _owner)`. +一个 ***代币*** 在以太坊基本上就是一个遵循一些共同规则的智能合约——即它实现了所有其他代币合约共享的一组标准函数，例如 `transfer(address _to, uint256 _value)` 和 `balanceOf(address _owner)`. 在智能合约内部，通常有一个映射， `mapping(address => uint256) balances`，用于追踪每个地址还有多少余额。 @@ -272,9 +272,9 @@ material: 其次，并不是所有僵尸都是平等的。 你的2级僵尸"**Steve**"完全不能等同于我732级的僵尸"**H4XF13LD MORRIS 💯💯😎💯💯**"。（你差得远呢，*Steve*）。 -有另一个代币标准更适合如 CryptoZombies 这样的加密收藏品——它们被称为**_ERC721 代币._** +有另一个代币标准更适合如 CryptoZombies 这样的加密收藏品——它们被称为***ERC721 代币.*** -**_ERC721 代币_**是**不**能互换的，因为每个代币都被认为是唯一且不可分割的。 你只能以整个单位交易它们，并且每个单位都有唯一的 ID。 这些特性正好让我们的僵尸可以用来交易。 +***ERC721 代币***是**不**能互换的，因为每个代币都被认为是唯一且不可分割的。 你只能以整个单位交易它们，并且每个单位都有唯一的 ID。 这些特性正好让我们的僵尸可以用来交易。 > 请注意，使用像 ERC721 这样的标准的优势就是，我们不必在我们的合约中实现拍卖或托管逻辑，这决定了玩家能够如何交易／出售我们的僵尸。 如果我们符合规范，其他人可以为加密可交易的 ERC721 资产搭建一个交易所平台，我们的 ERC721 僵尸将可以在该平台上使用。 所以使用代币标准相较于使用你自己的交易逻辑有明显的好处。 diff --git a/zh/5/09-safemath-1.md b/zh/5/09-safemath-1.md index e776d826fa..fb677ecb74 100644 --- a/zh/5/09-safemath-1.md +++ b/zh/5/09-safemath-1.md @@ -398,7 +398,7 @@ material: 我们将来学习你在编写智能合约的时候需要注意的一个主要的安全特性：防止溢出和下溢。 -什么是 **_溢出_** (**_overflow_**)? +什么是 ***溢出*** (***overflow***)? 假设我们有一个 `uint8`, 只能存储8 bit数据。这意味着我们能存储的最大数字就是二进制 `11111111` (或者说十进制的 2^8 - 1 = 255). @@ -417,11 +417,11 @@ number++; ### 使用 SafeMath -为了防止这些情况，OpenZeppelin 建立了一个叫做 SafeMath 的 **_库_**(**_library_**)，默认情况下可以防止这些问题。 +为了防止这些情况，OpenZeppelin 建立了一个叫做 SafeMath 的 ***库***(***library***)，默认情况下可以防止这些问题。 不过在我们使用之前…… 什么叫做库? -一个**_库_** 是 Solidity 中一种特殊的合约。其中一个有用的功能是给原始数据类型增加一些方法。 +一个***库*** 是 Solidity 中一种特殊的合约。其中一个有用的功能是给原始数据类型增加一些方法。 比如，使用 SafeMath 库的时候，我们将使用 `using SafeMath for uint256` 这样的语法。 SafeMath 库有四个方法 — `add`， `sub`， `mul`， 以及 `div`。现在我们可以这样来让 `uint256` 调用这些方法： diff --git a/zh/5/13-comments.md b/zh/5/13-comments.md index b7cf555919..3201002b3a 100644 --- a/zh/5/13-comments.md +++ b/zh/5/13-comments.md @@ -421,7 +421,7 @@ contract CryptoZombies { 特别是，最好为你合约中每个方法添加注释来解释它的预期行为。这样其他开发者（或者你自己，在6个月以后再回到这个项目中）可以很快地理解你的代码而不需要逐行阅读所有代码。 -Solidity 社区所使用的一个标准是使用一种被称作 **_natspec_** 的格式，看起来像这样： +Solidity 社区所使用的一个标准是使用一种被称作 ***natspec*** 的格式，看起来像这样： ``` /// @title 一个简单的基础运算合约 diff --git a/zh/5/14-wrappingitup.md b/zh/5/14-wrappingitup.md index 0013447b2a..c4983f1f5d 100644 --- a/zh/5/14-wrappingitup.md +++ b/zh/5/14-wrappingitup.md @@ -33,6 +33,6 @@ material: 这节教程完成了我们游戏的 Solidity 代码（仅针对当下来说，未来的课程我们也许会加入更多进去）。 -在接下来的两节课中，我们将学习如何将游戏部署到以太坊以及和 **_web3.js_** 交互 （这样你就能为你的 DApp 打造一个界面了 ）。 +在接下来的两节课中，我们将学习如何将游戏部署到以太坊以及和 ***web3.js*** 交互 （这样你就能为你的 DApp 打造一个界面了 ）。 继续玩儿或者重命名你的僵尸，然后就可以点击下一章来结束本节教程了。 diff --git a/zh/6/01.md b/zh/6/01.md index 43738045ea..32492334fa 100644 --- a/zh/6/01.md +++ b/zh/6/01.md @@ -365,7 +365,7 @@ material: --- 完成第五课以后，我们的僵尸 DApp 的 Solidity 合约部分就完成了。现在我们来做一个基本的网页好让你的用户能玩它。 -要做到这一点，我们将使用以太坊基金发布的 JavaScript 库 —— **_Web3.js_**. +要做到这一点，我们将使用以太坊基金发布的 JavaScript 库 —— ***Web3.js***. ## 什么是 Web3.js? @@ -375,7 +375,7 @@ material: 2. 你想调用的方法，以及 3. 你想传入那个方法的参数 -以太坊节点只能识别一种叫做 **_JSON-RPC_** 的语言。这种语言直接读起来并不好懂。当你想调用一个合约的方法的时候，需要发送的查询语句将会是这样的： +以太坊节点只能识别一种叫做 ***JSON-RPC*** 的语言。这种语言直接读起来并不好懂。当你想调用一个合约的方法的时候，需要发送的查询语句将会是这样的： ``` // 哈……祝你写所有这样的函数调用的时候都一次通过 diff --git a/zh/6/02.md b/zh/6/02.md index 71ac2c7005..c89a90d78a 100644 --- a/zh/6/02.md +++ b/zh/6/02.md @@ -386,11 +386,11 @@ material: 太棒了。现在我们的项目中有了Web3.js, 来初始化它然后和区块链对话吧。 -首先我们需要 **_Web3 Provider_**. +首先我们需要 ***Web3 Provider***. -要记住，以太坊是由共享同一份数据的相同拷贝的 **_节点_** 构成的。 在 Web3.js 里设置 Web3 的 `Provider`（提供者） 告诉我们的代码应该和 **哪个节点** 交互来处理我们的读写。这就好像在传统的 Web 应用程序中为你的 API 调用设置远程 Web 服务器的网址。 +要记住，以太坊是由共享同一份数据的相同拷贝的 ***节点*** 构成的。 在 Web3.js 里设置 Web3 的 `Provider`（提供者） 告诉我们的代码应该和 **哪个节点** 交互来处理我们的读写。这就好像在传统的 Web 应用程序中为你的 API 调用设置远程 Web 服务器的网址。 -你可以运行你自己的以太坊节点来作为 Provider。 不过，有一个第三方的服务，可以让你的生活变得轻松点，让你不必为了给你的用户提供DApp而维护一个以太坊节点— **_Infura_**. +你可以运行你自己的以太坊节点来作为 Provider。 不过，有一个第三方的服务，可以让你的生活变得轻松点，让你不必为了给你的用户提供DApp而维护一个以太坊节点— ***Infura***. ## Infura @@ -402,13 +402,13 @@ material: var web3 = new Web3(new Web3.providers.WebsocketProvider("wss://mainnet.infura.io/ws")); ``` -不过，因为我们的 DApp 将被很多人使用，这些用户不单会从区块链读取信息，还会向区块链 **_写_** 入信息，我们需要用一个方法让用户可以用他们的私钥给事务签名。 +不过，因为我们的 DApp 将被很多人使用，这些用户不单会从区块链读取信息，还会向区块链 ***写*** 入信息，我们需要用一个方法让用户可以用他们的私钥给事务签名。 > 注意: 以太坊 (以及通常意义上的 blockchains )使用一个公钥/私钥对来对给事务做数字签名。把它想成一个数字签名的异常安全的密码。这样当我修改区块链上的数据的时候，我可以用我的公钥来 **证明** 我就是签名的那个。但是因为没人知道我的私钥，所以没人能伪造我的事务。 加密学非常复杂，所以除非你是个专家并且的确知道自己在做什么，你最好不要在你应用的前端中管理你用户的私钥。 -不过幸运的是，你并不需要，已经有可以帮你处理这件事的服务了： **_Metamask_**. +不过幸运的是，你并不需要，已经有可以帮你处理这件事的服务了： ***Metamask***. ## Metamask diff --git a/zh/6/03.md b/zh/6/03.md index 98ca386847..5128a5f73b 100644 --- a/zh/6/03.md +++ b/zh/6/03.md @@ -863,7 +863,7 @@ material: 现在，我们已经用 MetaMask 的 Web3 提供者初始化了 Web3.js。接下来就让它和我们的智能合约对话吧。 -Web3.js 需要两个东西来和你的合约对话: 它的 **_地址_** 和它的 **_ABI_**。 +Web3.js 需要两个东西来和你的合约对话: 它的 ***地址*** 和它的 ***ABI***。 ## 合约地址 @@ -875,7 +875,7 @@ Web3.js 需要两个东西来和你的合约对话: 它的 **_地址_** 和它 ## 合约 ABI -另一个 Web3.js 为了要和你的智能合约对话而需要的东西是 **_ABI_**。 +另一个 Web3.js 为了要和你的智能合约对话而需要的东西是 ***ABI***。 ABI 意为应用二进制接口（Application Binary Interface）。 基本上，它是以 JSON 格式表示合约的方法，告诉 Web3.js 如何以合同理解的方式格式化函数调用。 diff --git a/zh/6/09.md b/zh/6/09.md index 7c7ec541ca..a6e3ce51d5 100644 --- a/zh/6/09.md +++ b/zh/6/09.md @@ -1123,7 +1123,7 @@ cryptoZombies.getPastEvents("NewZombie", { fromBlock: 0, toBlock: 'latest' }) ## Web3.js 事件 和 MetaMask -上面的示例代码是针对 Web3.js 最新版1.0的，此版本使用了 **_WebSockets_** 来订阅事件。 +上面的示例代码是针对 Web3.js 最新版1.0的，此版本使用了 ***WebSockets*** 来订阅事件。 但是，MetaMask 尚且不支持最新的事件 API (尽管如此，他们已经在实现这部分功能了， 点击这里 查看进度) diff --git a/zh/7/02.md b/zh/7/02.md index aa662ca998..0ce6d1dde4 100644 --- a/zh/7/02.md +++ b/zh/7/02.md @@ -484,7 +484,7 @@ Since our contract, `ExampleGame`, inherits from `ZBGameMode`, this gives us ac ### "hook（钩子）" — 每个自定义游戏模式的核心 -每个自定义游戏模式的第一步就是实现至少一个**_hook_**。 +每个自定义游戏模式的第一步就是实现至少一个***hook***。 基本上，核心游戏逻辑将在游戏的某些部分中（如果它们存在于你的代码中）寻找并调用合约中的某些功能。 diff --git a/zh/8/04.md b/zh/8/04.md index 5ce3c6fca5..9fcfe76876 100644 --- a/zh/8/04.md +++ b/zh/8/04.md @@ -576,7 +576,7 @@ material: 现在我们继续下一个吧： -_**Singleton:** 当组建30张卡牌的牌组时，任何牌都不能与牌组中的另一张牌名字相同。_ +***Singleton:** 当组建30张卡牌的牌组时，任何牌都不能与牌组中的另一张牌名字相同。_ 首先，我们分叉了（复制了）`munchkin.sol`并将其命名为`singleton.sol`。 diff --git a/zh/9/01-erc721x.md b/zh/9/01-erc721x.md index 22e19e587b..3f17257947 100644 --- a/zh/9/01-erc721x.md +++ b/zh/9/01-erc721x.md @@ -246,7 +246,7 @@ material: 将游戏中的物品称为“代币”可能会让人产生误解，因为“代币”一词暗指像货币一样花费的东西。 -但是，以太坊上的**_token_**一词只是指智能合约的标准，它们都实现相同的通用函数，例如`transfer(address _to, uint256 _value)` 和`balanceOf(address _owner)`。 +但是，以太坊上的***token***一词只是指智能合约的标准，它们都实现相同的通用函数，例如`transfer(address _to, uint256 _value)` 和`balanceOf(address _owner)`。 是的，你可以转移并拥有货币余额 —— 但也可以转移并拥有一些游戏中的物品，如剑或扑克牌。 @@ -256,15 +256,15 @@ material: ## 不同的代币标准: ERC20 和 ERC721 -最常见的代币标准是**_ERC20代币_**。 这些代币的作用类似于货币。但它们在表示数字物品(如集换式卡牌游戏中的卡牌)方面并不是特别有用。 +最常见的代币标准是***ERC20代币***。 这些代币的作用类似于货币。但它们在表示数字物品(如集换式卡牌游戏中的卡牌)方面并不是特别有用。 首先，卡牌不像货币一样是可分割的 —— 你不可能拥有一张卡牌的五分之二。 其次，并非所有卡牌都是平等的，所以它们不可互换。 你不会想将你的Z-Virus卡换成我的Ozmoziz。 -有另一种代币标准更适合加密收藏品 —— 它们被称为**_ERC721代币_**。 +有另一种代币标准更适合加密收藏品 —— 它们被称为***ERC721代币***。 -**_ERC721代币_**是**不可**互换的。每个物品都是唯一的，并且有唯一的ID。它们也不能被分割 —— 你只能将它们作为整体来交易。 +***ERC721代币***是**不可**互换的。每个物品都是唯一的，并且有唯一的ID。它们也不能被分割 —— 你只能将它们作为整体来交易。 所以，这些代币更适合制作我们的集换式卡牌游戏。 diff --git a/zh/9/03-erc721x.md b/zh/9/03-erc721x.md index 8c719accc9..33fd718dfc 100644 --- a/zh/9/03-erc721x.md +++ b/zh/9/03-erc721x.md @@ -265,7 +265,7 @@ material: } --- -对于普通的ERC20或ERC721代币，我们有**_代币供应_**的概念 —— 是指总共存在多少那样的代币。 +对于普通的ERC20或ERC721代币，我们有***代币供应***的概念 —— 是指总共存在多少那样的代币。 对于ERC721x多重同质化代币，我们实际上可以在同一合约中定义多个代币 —— 每个代币都有自己的“供应量”（存在的代币数量）。 diff --git a/zh/9/10-erc721x.md b/zh/9/10-erc721x.md index 35fd20780b..b40ed098b3 100644 --- a/zh/9/10-erc721x.md +++ b/zh/9/10-erc721x.md @@ -357,7 +357,7 @@ material: 快完成了！让我们用另外一个函数来结束我们的合约，然后复习一下。 -我们要实现的最后一件事是**_批量铸造—_**代币。这个函数允许我们在一个函数调用中铸造多个代币 —— 这也是ERC721x让我们在以太坊上节省大量gas费用的原因之一。 +我们要实现的最后一件事是***批量铸造—***代币。这个函数允许我们在一个函数调用中铸造多个代币 —— 这也是ERC721x让我们在以太坊上节省大量gas费用的原因之一。 到目前为止，我们已经完成所有的设置，这个函数的实现就非常简单了。