Skip to content

Commit

Permalink
actions line for all files + 00 01 & 02
Browse files Browse the repository at this point in the history
  • Loading branch information
antododo committed Mar 5, 2018
1 parent abb21e0 commit 58ad3cd
Show file tree
Hide file tree
Showing 16 changed files with 85 additions and 85 deletions.
12 changes: 6 additions & 6 deletions fr/5/00-overview.md
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
---
title: ERC721 & Crypto-Collectibles
header: "Lesson 5: ERC721 & Crypto-Collectibles"
title: ERC721 et crypto-collectibles
header: "Leçon 5: ERC721 et crypto-collectibles"
roadmap: roadmap5.jpg
---

Whew! Things are starting to heat up in here...
Ouf ! Ça commence à chauffer ici...

In this lesson, we're going to get a bit more advanced.
Dans cette leçon, nous allons voir des choses un peu plus complexes.

We're going to talk about **tokens**, the **ERC721** standard, and **crypto-collectible assets**.
Nous allons parler des **jetons (tokens)**, du standard **ERC721**, et des **actifs crypto-collectibles**.

In other words, we're going to **make it so you can trade your zombies with your friends.**
En d'autres terme, nous allons **faire en sorte que vous puissiez échanger vos zombies avec vos amis.**
54 changes: 27 additions & 27 deletions fr/5/01-erc721-1.md
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
---
title: Tokens on Ethereum
actions: ['checkAnswer', 'hints']
title: Tokens Ethereum
actions: ['vérifierLaRéponse', 'indice']
requireLogin: true
material:
editor:
language: sol
startingCode:
"zombieownership.sol": |
// Start here
// Commencez ici
"zombieattack.sol": |
pragma solidity ^0.4.19;
Expand Down Expand Up @@ -236,54 +236,54 @@ material:
pragma solidity ^0.4.19;
import "./zombieattack.sol";
contract ZombieOwnership is ZombieAttack {
}
---

Let's talk about **_tokens_**.
Commençons par les **_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_**.
Si vous êtes dans la sphère Ethereum depuis un moment, vous avez surement entendu parler des tokens - en particulier des **tokens 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 `transfer(address _to, uint256 _value)` and `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 token partagent, comme `transfer(address _to, uint256 _value)` et `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.
Le smart contract a habituellement un mappage interne, `mapping(address => uint256) balances`, qui permet de connaître de la balance de chaque adresse.

So basically a token is just a contract that keeps track of who owns how much of that token, and some functions so those users can transfer their tokens to other addresses.
Un token est simplement un contrat qui permet de connaître combien chaque personne possède de ce token, et qui a certaines fonctions pour permettre aux utilisateurs de transférer leur tokens à d'autres adresses.

### Why does it matter?
### Pourquoi c'est important ?

Since all ERC20 tokens share the same set of functions with the same names, they can all be interacted with in the same ways.
Puisque tous les tokens ERC20 partagent le même ensemble de fonctions avec les mêmes noms, ils peuvent tous être manipulés de la même manière.

This means if you build an application that is capable of interacting with one ERC20 token, it's also capable of interacting with any ERC20 token. That way more tokens can easily be added to your app in the future without needing to be custom coded. You could simply plug in the new token contract address, and boom, your app has another token it can use.
Cela veut dire que si vous construisez une application qui est capable d'interagir avec un token ERC20, elle sera aussi capable d'interagir avec n'importe quel token ERC20. De cette manière, d'autres tokens pourrons facilement être ajoutés à votre application sans avoir besoin de personnaliser le code. Vous pourrez simplement rajouter la nouvelle adresse du contrat du token, et boom, votre application pourra utiliser un nouveau token.

One example of this would be an exchange. When an exchange adds a new ERC20 token, really it just needs to add another smart contract it talks to. Users can tell that contract to send tokens to the exchange's wallet address, and the exchange can tell the contract to send the tokens back out to users when they request a withdraw.
On pourrait prendre comme exemple un échange. Quand un échange ajoute un nouveau token ERC20, en vérité il a juste besoin d'ajouter un nouveau smart contrat. Les utilisateurs pourront utiliser ce contrat pour envoyer des tokens sur l'adresse de l'échange, et l'échange pourra utiliser ce contrat pour renvoyer des tokens aux utilisateurs quand ils voudront retirer.

The exchange only needs to implement this transfer logic once, then when it wants to add a new ERC20 token, it's simply a matter of adding the new contract address to its database.
L'échange a simplement besoin d'implémenter une fois la logique de transfert, et quand il veut ajouter un nouveau token ERC20, il suffit simplement d'ajouter l'adresse du nouveau contrat à sa base de donnée.

### Other token standards
### Autres standards des tokens

ERC20 tokens are really cool for tokens that act like currencies. But they're not particularly useful for representing zombies in our zombie game.
Les tokens ERC20 sont vraiment pratiques pour servir en temps que monnaies. Mais ils ne sont pas vraiment utiles pour représenter des zombies dans notre jeu de zombie.

For one, zombies aren't divisible like currencies — I can send you 0.237 ETH, but transfering you 0.237 of a zombie doesn't really make sense.
Premièrement, les zombies ne sont pas divisibles comme les monnaies - je peux vous envoyer 0.237 ETH, mais je ne peux pas vous envoyer 0.237 d'un zombie.

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*).
Deuxièmement, tous les zombies ne sont pas égaux. Votre zombie "**Pierre**" de niveau 2 n'est pas du égal à mon zombie de niveau 732 "**H4XF13LD MORRIS 💯💯😎💯💯**". (Tu peux pas test, *Pierre*).

There's another token standard that's a much better fit for crypto-collectibles like CryptoZombies — and they're called **_ERC721 tokens._**
Il y a un autre standard de token qui est beaucoup plus adapté pour les crypto-collectibles comme CryptoZombies — ce sont les **_tokens ERC721._**

**_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.
Les **_tokens ERC721_** **ne** sont **pas** interchangeable puisqu'ils sont supposés être unique, et ne sont pas divisible. 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.

> 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.
> Remarque : En utilisant un standard comme ERC721, nous n'avons pas besoin d'implémenter les logiques qui permettent comment les joueurs vont échanger / vendre les zombies. Si on respecter les spécifications, quelqu'un d'autre pourrait construire une plateforme d'échange pour les actifs crypto-échangeables, et nos zombies ERC721 seraient compatible avec cette plateforme. C'est un avantage évident d'utiliser un standard de token au lieu d'implémenter sa propre logique d'échange.
## Putting it to the Test
## A votre tour

We're going to dive into the ERC721 implementation in the next chapter. But first, let's set up our file structure for this lesson.
Nous allons nous pencher sur l'implémentation ERC721 dans le prochain chapitre. Mais pour l'instant, nous allons mettre en place la structure de nos fichiers pour notre leçon.

We're going to store all the ERC721 logic in a contract called `ZombieOwnership`.
Nous allons stocker toute la logique ERC721 dans un contrat appelé `ZombieOwnership`.

1. Declare our `pragma` version at the top of the file (check previous lessons' files for the syntax).
1. Déclarez notre version `pragma` en haut du fichier (regardez les fichiers des leçons précédentes pour la syntaxe).

2. This file should `import` from `zombieattack.sol`.
2. Le fichier devra importer, avec `import`, `zombieattack.sol`.

3. Declare a new contract, `ZombieOwnership`, that inherits from `ZombieAttack`. Leave the body of the contract empty for now.
3. Déclarez un nouveau contrat, `ZombieOwnership`, qui héritera de `ZombieAttack`. Laissez le corps du contrat vide pour l'instant.
42 changes: 21 additions & 21 deletions fr/5/02-erc721-2.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: ERC721 Standard, Multiple Inheritance
actions: ['checkAnswer', 'hints']
title: Standard ERC721, héritage multiple
actions: ['vérifierLaRéponse', 'indice']
requireLogin: true
material:
editor:
Expand All @@ -10,9 +10,9 @@ material:
pragma solidity ^0.4.19;
import "./zombieattack.sol";
// Import file here
// Declare ERC721 inheritance here
// Importez le fichier ici
// Declarez l'héritage ERC721 ici
contract ZombieOwnership is ZombieAttack {
}
Expand Down Expand Up @@ -256,13 +256,13 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
}
---

Let's take a look at the ERC721 standard:
Regardons de plus prêt le standard ERC721 :

```
contract ERC721 {
Expand All @@ -276,35 +276,35 @@ contract ERC721 {
function takeOwnership(uint256 _tokenId) public;
}
```
C'est la liste des méthodes que nous allons devoir implémenter, c'est ce que nous ferons au cours des prochains chapitres.

This is the list of methods we'll need to implement, which we'll be doing over the coming chapters in pieces.
Cela pourrait paraître beaucoup, mais ne vous laissez pas impressionner ! Nous sommes là pour vous accompagner.

It looks like a lot, but don't get overwhelmed! We're here to walk you through it.
> Remarque : Le standard ERC721 est actuellement une *ébauche*, et il n'y a pas d'implémentation officiellement convenue. Pour ce tutoriel nous allons utiliser la version actuelle de la bibliothèque OpenZeppelin, mais il est possible que cela change dans le futur avant une sortie officielle. C'est donc **une** implémentation possible, mais ce n'est pas le standard officiel pour les tokens ERC721.
> Note: The ERC721 standard is currently a *draft*, and there is no officially agreed-upon implementation yet. For this tutorial we're using the current version from OpenZeppelin's library, but it is possible it will change in the future before its official release. So consider this **one** possible implementation, but don't take it as the official standard for ERC721 tokens.

### Implementing a token contract
### Implémenter le contrat d'un tokens

When implementing a token contract, the first thing we do is copy the interface to its own Solidity file and import it, `import ./erc721.sol`. Then we have our contract inherit from it, and we override each method with a function definition.
Quand on implémente le contrat d'un token, la première chose à faire et de copier l'interface dans son propre fichier Solidity et importer avec `import ./erc721.sol`. Ensuite notre contrat doit en hériter, et nous pouvons réécrire chaque méthode avec une définition de fonction.

But wait — `ZombieOwnership` is already inheriting from `ZombieAttack` — how can it also inherit from `ERC721`?
Mais — `ZombieOwnership` hérite déjà de `ZombieAttack` — comment pourrait-il aussi hériter de `ERC721` ?

Luckily in Solidity, your contract can inherit from multiple contracts as follows:
Heureusement en Solidity, un contrat peut hériter de plusieurs contrats de la manière suivante :

```
contract SatoshiNakamoto is NickSzabo, HalFinney {
// Omg, the secrets of the universe revealed!
// Les secrets de l'univers sont percés à jour !
}
```

As you can see, when using multiple inheritance, you just separate the multiple contracts you're inheriting from with a comma, `,`. In this case, our contract is inheriting from `NickSzabo` and `HalFinney`.
Comme vous pouvez le voir, quand nous utilisons l'héritage multiple, il suffit de séparer les différents contrats avec une virgule, `,`. Dans cet exemple, notre contrat hérite de `NickSzabo` et de `HalFinney`.

Let's give it a try.
Essayons.

## Putting it to the Test
## A votre tour

We've already created `erc721.sol` with the interface above for you.
Nous avons créé `erc721.sol` avec son interface en avance.

1. Import `erc721.sol` into `zombieownership.sol`
1. Importez `erc721.sol` dans `zombieownership.sol`

2. Declare that `ZombieOwnership` inherits from `ZombieAttack` AND `ERC721`
2. Déclarez que `ZombieOwnership` hérite de `ZombieAttack` ET de `ERC721`
8 changes: 4 additions & 4 deletions fr/5/03-erc721-3.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: balanceOf & ownerOf
actions: ['checkAnswer', 'hints']
actions: ['vérifierLaRéponse', 'indice']
requireLogin: true
material:
editor:
Expand All @@ -11,7 +11,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
function balanceOf(address _owner) public view returns (uint256 _balance) {
Expand Down Expand Up @@ -274,7 +274,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
function balanceOf(address _owner) public view returns (uint256 _balance) {
Expand Down Expand Up @@ -329,7 +329,7 @@ Again, this is very straightforward for us to implement, since we already have a
## Putting it to the Test

I'll leave it to you to figure out how to implement these 2 functions.
I'll leave it to you to figure out how to implement these 2 functions.

Each function should simply be 1 line of code, a `return` statement. Take a look at our code from previous lessons to see where we're storing this data. If you can't figure it out, you can hit the "show me the answer" button for some help.

Expand Down
4 changes: 2 additions & 2 deletions fr/5/04-erc721-4.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: Refactoring
actions: ['checkAnswer', 'hints']
actions: ['vérifierLaRéponse', 'indice']
requireLogin: true
material:
editor:
Expand Down Expand Up @@ -72,7 +72,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
function balanceOf(address _owner) public view returns (uint256 _balance) {
Expand Down
6 changes: 3 additions & 3 deletions fr/5/05-erc721-5.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: "ERC721: Transfer Logic"
actions: ['checkAnswer', 'hints']
actions: ['vérifierLaRéponse', 'indice']
requireLogin: true
material:
editor:
Expand All @@ -11,7 +11,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
function balanceOf(address _owner) public view returns (uint256 _balance) {
Expand Down Expand Up @@ -276,7 +276,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
function balanceOf(address _owner) public view returns (uint256 _balance) {
Expand Down
6 changes: 3 additions & 3 deletions fr/5/06-erc721-6.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: "ERC721: Transfer Cont'd"
actions: ['checkAnswer', 'hints']
actions: ['vérifierLaRéponse', 'indice']
requireLogin: true
material:
editor:
Expand All @@ -11,7 +11,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
function balanceOf(address _owner) public view returns (uint256 _balance) {
Expand Down Expand Up @@ -282,7 +282,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
function balanceOf(address _owner) public view returns (uint256 _balance) {
Expand Down
6 changes: 3 additions & 3 deletions fr/5/07-erc721-7.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: "ERC721: Approve"
actions: ['checkAnswer', 'hints']
actions: ['vérifierLaRéponse', 'indice']
requireLogin: true
material:
editor:
Expand All @@ -11,7 +11,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
// 1. Define mapping here
Expand Down Expand Up @@ -284,7 +284,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
mapping (uint => address) zombieApprovals;
Expand Down
8 changes: 4 additions & 4 deletions fr/5/08-erc721-8.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: "ERC721: takeOwnership"
actions: ['checkAnswer', 'hints']
actions: ['vérifierLaRéponse', 'indice']
requireLogin: true
material:
editor:
Expand All @@ -11,7 +11,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
mapping (uint => address) zombieApprovals;
Expand Down Expand Up @@ -284,7 +284,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
mapping (uint => address) zombieApprovals;
Expand Down Expand Up @@ -327,7 +327,7 @@ The final function, `takeOwnership`, should simply check to make sure the `msg.s

## Putting it to the Test

1. First, we want to use a `require` statement to check that `zombieApprovals` for `_tokenId` is equal to `msg.sender`.
1. First, we want to use a `require` statement to check that `zombieApprovals` for `_tokenId` is equal to `msg.sender`.

That way if `msg.sender` hasn't been approved to take this token, it will throw an error.

Expand Down
4 changes: 2 additions & 2 deletions fr/5/09-safemath-1.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: Preventing Overflows
actions: ['checkAnswer', 'hints']
actions: ['vérifierLaRéponse', 'indice']
requireLogin: true
material:
editor:
Expand Down Expand Up @@ -61,7 +61,7 @@ material:
import "./zombieattack.sol";
import "./erc721.sol";
contract ZombieOwnership is ZombieAttack, ERC721 {
mapping (uint => address) zombieApprovals;
Expand Down
Loading

0 comments on commit 58ad3cd

Please sign in to comment.