Skip to content

Commit

Permalink
Correct english
Browse files Browse the repository at this point in the history
  • Loading branch information
AymericBethencourt committed Jul 12, 2020
1 parent 5ebbbc6 commit 2701160
Show file tree
Hide file tree
Showing 36 changed files with 1,009 additions and 1,232 deletions.
6 changes: 0 additions & 6 deletions src/frontend/src/app/App.components/Drawer/Drawer.view.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -50,12 +50,6 @@ export const DrawerView = ({
)
else return <div key={chapter.pathname} />
})}

<DrawerItem className={pathname === '/coming-next' ? 'current-path' : 'other-path'}>
<Link to="/coming-next" onClick={() => hideCallback()}>
What's next?
</Link>
</DrawerItem>
</DrawerStyled>
</>
)
Expand Down
20 changes: 16 additions & 4 deletions src/frontend/src/pages/Chapter/Chapter.data.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -195,27 +195,33 @@ export const chapterData = [
{
pathname: '/pascal/chapter-interop',
language: 'PascaLIGO',
name: '26- Pascal - Interoperability',
name: '26 - Pascal - Interoperability',
data: pascalDataInterop,
},
{
pathname: '/pascal/chapter-preprocessor',
language: 'PascaLIGO',
name: '27- Pascal - Preprocessor',
name: '27 - Pascal - Preprocessor',
data: pascalDataPreprocessor,
},
{
pathname: '/pascal/chapter-fa2',
language: 'PascaLIGO',
name: '28- Pascal - FA2',
name: '28 - Pascal - FA2',
data: pascalDataFA20,
},
{
pathname: '/pascal/chapter-fa2-operator',
language: 'PascaLIGO',
name: '29- Pascal - FA2 Operator',
name: '29 - Pascal - FA2 Operator',
data: pascalDataFA20Operator,
},
{
pathname: '/pascal/chapter-fa2-hook',
language: 'PascaLIGO',
name: '30 - Pascal - FA2 Hook',
data: camelDataFA20Hook,
},

{
pathname: '/camel/chapter-about',
Expand Down Expand Up @@ -488,4 +494,10 @@ export const chapterData = [
name: '29 - Reason - FA2 Operator',
data: reasonDataFA20Operator,
},
{
pathname: '/reason/chapter-fa2-hook',
language: 'ReasonLIGO',
name: '30 - Reason - FA2 Hook',
data: camelDataFA20Hook,
},
]
Original file line number Diff line number Diff line change
@@ -1,13 +1,12 @@
# Chapter 22 : Deploy & Invoke
# Chapter 23 : Deploy contract

<dialog character="admiral"> Time to go live.</dialog>


## Smart contract

A smart contract is code written in Michelson langage (a low-level stack-based turing-complete language).
It contains entrypoints which describe all possible way to interact with a smart contract.
It contains prototype of each entrypoint. What kind of parameters are exepected to execute an entrypoint
A smart contract is code written in Michelson langage (a low-level stack-based turing-complete language).
It contains entrypoints which describe all possible way to interact with a smart contract.
It contains prototype of each entrypoint. What kind of parameters are exepected to execute an entrypoint
It contains the description of storage.

### Storage
Expand All @@ -18,21 +17,20 @@ The description of the storage is done by strongly-typing the data structure.

### Entrypoints

Entrypoints of a smart contract describe how to mutate a storage.
Entrypoints of a smart contract describe how to mutate a storage.
Executing an entrypoint takes some parameters and a state of a storage and returns a new state of storage and some operations

![](/images/contract_in_out.png)


Execution of an entrypoint produces a new state of the storage of the smart contract. If executopn did not throw an exception and did not fail then the new state of storage is applied.

Operations are transactions (smart contract invocation) that will be sent to some other contracts and will trigger an entryppoint of the targeted contract or a tez transfer (no invocation of entrypoint). If execution of an entrypoint produces operations (ordered list of transactions) then they are sent and executed following order of the list of operation.

## Deploy

A smart contract must be deployed to the blockchain in order to be invoked. When deploying a smart contract ot the blockchain , one must specify the initial state of the storage.
A smart contract must be deployed to the blockchain in order to be invoked. When deploying a smart contract ot the blockchain , one must specify the initial state of the storage.
Deployment of a smart contract in Tezos is called "origination".
Here is the syntax of the tezos command line to deploy a smart contract :
Here is the syntax of the tezos command line to deploy a smart contract :

```
tezos-client originate contract <contract_name> for <user> transferring <amount> from <from_user> \
Expand All @@ -47,31 +45,28 @@ tezos-client originate contract <contract_name> for <user> transferring <amount>
<initial_storage> is a Michelson expression. The --init parameter is used to specify initial state of the storage.
<gaz> it specifies the the maximal fee the user is willing to pay for this operation (using the --burn-cap parameter).


## Invoke

Once the smart contract has been deployed on the blockchain (contract-origination operation baked into a block), it is possible to invoke an entrypoint of the smart contract using the command line.

Here is the syntax of the tezos command line to invoke a smart contract :
Here is the syntax of the tezos command line to invoke a smart contract :

```
tezos-client transfer <amount> from <user> to <contract_name> --arg '<entrypoint_invocation>' --dry-run
```

<amount> is the quantity of tez being transfered to the contract.
<contract_name> name given to the contract
<entrypoint_invocation> name of the entrypoint and corresponding parameters. exemple 'Increment(5)'.
<entrypoint_invocation> name of the entrypoint and corresponding parameters. exemple 'Increment(5)'.

⚠️ Notice the --arg parameter specifies an entrypoint call.

⚠️ Notice the --dry-run parameter simulate invocation of the entrypoint.



## Ligo compiler

In order to produce a smart contract, a tool called transpiler (aka LIGO compiler) is used to transform LIGO code into Michelson code.
Michelson smart contract are stored in a file with .tz extension.
Michelson smart contract are stored in a file with .tz extension.

This ligo compiler is also used to transform "Ligo expression" into "Michelson expression" as needed to deploy or invoke a smart contract.

Expand All @@ -82,6 +77,7 @@ Here is how to transform ligo code into Michelson code using the ligo compiler i
```
ligo compile-contract code.mligo mainFunc > code.tz
```

<mainFunc> argument is the name of the "main function" in the .ligo file. (see Chapter "Main Function").

⚠️ Notice the output of the command is the Michelson code. We just redirect the command output into a .tz file.
Expand All @@ -96,7 +92,6 @@ ligo compile-storage [options] code.mligo mainFunc '<expression>'

<expression> is a ligo expression


### Invocation parameter

Here is how to transform ligo expression into Michelson expression using the ligo compiler in command line.
Expand All @@ -107,21 +102,20 @@ ligo compile-parameter [options] code.mligo mainFunc '<expression>'

<expression> is a ligo expression


### Simulating
### Simulating

Here is how to simulate execution of an entrypoint using the ligo compiler in command line.

```
ligo dry-run [options] code.mligo mainFunc '<entrypoint(p)>' '<storage_state>'
```

<storage_state> state of the storage when simulating execution of the entrypoint
<entrypoint(p)> entrypoint of the smart contract that is invoked (parameter *p* of this entrypoint is specified between parantheses).
<storage*state> state of the storage when simulating execution of the entrypoint
<entrypoint(p)> entrypoint of the smart contract that is invoked (parameter \_p* of this entrypoint is specified between parantheses).

### Ligo Expression in command line

Let's see some exemple how to transpile a storage ligo expression into a michelson one.
Let's see some exemple how to transpile a storage ligo expression into a Michelsonone.

Let's consider this smart contract which associate coordinates to a planet name.

Expand All @@ -148,9 +142,9 @@ let main (action,store : parameter * storage): return =

#### Maps

The _Map.literal_ predifined function can be used to initialize a *map*
The _Map.literal_ predifined function can be used to initialize a _map_

The command line *ligo compile-storage* for transpiling a map containg a tuple.
The command line _ligo compile-storage_ for transpiling a map containg a tuple.

```
ligo compile-storage starmap.mligo main 'Map.literal [("earth", (1,1,1))]'
Expand All @@ -160,7 +154,7 @@ ligo compile-storage starmap.mligo main 'Map.literal [("earth", (1,1,1))]'

Initialization of elements of a tuple is specified between _(_ and _)_ separated by comma _,_.

The command line *ligo compile-storage* for transpiling a map containg a tuple.
The command line _ligo compile-storage_ for transpiling a map containg a tuple.

```
ligo compile-storage starmap.mligo main 'Map.literal [("earth", (1,1,1))]'
Expand All @@ -177,10 +171,10 @@ This command returns :
Initialization of elements of a record is specified between _{_ and _}_ separated by comma _;_. Each element is a key/value pair seperated by _=_ and follow the syntax :

```
{ <key1> = <value1>; <key2> = <value2> }
{ <key1> = <value1>; <key2> = <value2> }
```

Let's modify our type *coordinates* to be a record instead of a tuple.
Let's modify our type _coordinates_ to be a record instead of a tuple.

```
// starmap2.mligo
Expand All @@ -198,8 +192,7 @@ let main (action,store : parameter * storage): return =
| DoNothing -> (([] : operation list),store)
```


The command line *ligo compile-storage* for transpiling a map containg a record tuple.
The command line _ligo compile-storage_ for transpiling a map containg a record tuple.

```
ligo compile-storage starmap2.mligo main 'Map.literal [("earth", {x=1;y=1;z=1})]'
Expand Down Expand Up @@ -243,9 +236,6 @@ let main (action,store : parameter * storage): return =
| DoNothing -> (([] : operation list),store)
```



<!-- prettier-ignore -->1- Write _compile-storage_ command and the ligo expression for initializing the *Sol* system containing planet "earth" with coordinates (2,7,1).

<!-- prettier-ignore -->2- Write _dry-run_ command and the ligo expression for adding a planet "mars" with coordinates (4,15,2) in our *Sol* system. Reuse the *Sol* system of step 1.

<!-- prettier-ignore -->2- Write the _dry-run_ command and the ligo expression for adding a planet "mars" with coordinates (4,15,2) in our *Sol* system. Reuse the *Sol* system of step 1.
57 changes: 28 additions & 29 deletions src/frontend/src/pages/Chapters/Camel/ChapterFA12/course.md
Original file line number Diff line number Diff line change
@@ -1,52 +1,51 @@
# Chapter 23 : Fungible Asset 1.2
# Chapter 25 : Financial Application 1.2

<dialog character="mechanics">Captain, why are you trying to change the part yourself? Just write a function on the terminal and send it to a droid.</dialog>

## Definition

A financial asset is a non-physical asset whose value is derived from a contractual claim, such as bank deposits, bonds, and stocks. Financial assets are usually more liquid than other tangible assets, such as commodities or real estate, and may be traded on financial markets.

Financial assets are opposed to non-financial assets, property rights which include both tangible property (sometimes also called real assets) such as land, real estate or commodities and intangible assets such as intellectual property, like copyrights, patents, Trademarks etc.
Financial assets are opposed to non-financial assets, property rights which include both tangible property (sometimes also called real assets) such as land, real estate or commodities and intangible assets such as intellectual property, like copyrights, patents, Trademarks etc.

### Fungible and non-fungible

When talking about *token* or *crypto-currency*, it is a numerical asset emitted on a blockchain.
When talking about _token_ or _crypto-currency_, it is a numerical asset emitted on a blockchain.

Fungible means secable
Fungible means secable

Fungible token is a financial asset where account balance represents the value associated to an _address_. This value can be splitted into smaller parts which can be transfered to another account.

Non-fungible token (NFT) is a financial asset whose balance cannot be splitted into smaller part. Crypto-kitties is an exemple of non fungible token (on Ethereum blcockchain). For exemple, a video game avatar (such as avatar on world of warcraft) is a character having some skills/attributes (strength, dexterity, ...) one can want to sell its avatar , but cannot sell strength property of its avatar separately. It makes sense to keep tha whole avatar into a unsecable set of attributes.
Non-fungible token (NFT) is a financial asset whose balance cannot be splitted into smaller part. Crypto-kitties is an exemple of non fungible token (on Ethereum blcockchain). For exemple, a video game avatar (such as avatar on world of warcraft) is a character having some skills/attributes (strength, dexterity, ...) one can want to sell its avatar , but cannot sell strength property of its avatar separately. It makes sense to keep tha whole avatar into a unsecable set of attributes.

### Standard

A standard is a set of rules commonly accepted by the community.
The rules of financial asset describes how to create currencies (and transfer between accounts, etc).
A standard is a set of rules commonly accepted by the community.
The rules of financial asset describes how to create currencies (and transfer between accounts, etc).

Depending on the usage of the currency, many sets of rules have been commonly accepted :
* Financial asset 1.2 (FA1.2) are rules for fungible token.
* Financia asset 2.0 (FA20) are rules for non fungible token.

- Financial asset 1.2 (FA1.2) are rules for fungible token.
- Financia asset 2.0 (FA20) are rules for non fungible token.

For exemple, the creation of a crypto-currency is equivalent to creating a contract which supports the FA1.2 standard.
All smart contracts supporting the FA12 standard can interact with account and other contracts by transfering coins of our crypto-currency.


Similarily for ethereum, fungible token rules have been specified in a Ethereum forum blog (Ethereum Request Comment) the 20th answer was describing a good rule set and the ERC20 became the name for this standard (rule set).
Similarily for ethereum, fungible token rules have been specified in a Ethereum forum blog (Ethereum Request Comment) the 20th answer was describing a good rule set and the ERC20 became the name for this standard (rule set).
ERC721 is the standard rule set for non-fungible token.

## FA1.2 (Implementation of standard)

This Fungible token standard provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party.

Possible actions :
Appove - Sender can specify an amount of token that can be spent by someone else (from his account)
Transfer - Transfer an amount a token from an account to another account (or third-party on-chain smart contract)
GetAllowance - Return the amount that can be spent by someone from sender's account
GetBalance - Returns sender's account balance
GetTotalSupply - Returns the number total of token

Appove - Sender can specify an amount of token that can be spent by someone else (from his account)
Transfer - Transfer an amount a token from an account to another account (or third-party on-chain smart contract)
GetAllowance - Return the amount that can be spent by someone from sender's account
GetBalance - Returns sender's account balance
GetTotalSupply - Returns the number total of token

Let's see implementation in ReasonLigo of a fungible token (FA1.2)
Let's see implementation in ReasonLigo of a fungible token (FA1.2)

```
type tokens = (address, nat) big_map
Expand Down Expand Up @@ -92,7 +91,7 @@ type action =
| GetTotalSupply of getTotalSupply
let transfer (p,s : transfer * storage) : operation list * storage =
let new_allowances =
let new_allowances =
if Tezos.sender = p.address_from then s.allowances
else
let authorized_value = match Big_map.find_opt (Tezos.sender,p.address_from) s.allowances with
Expand All @@ -102,7 +101,7 @@ let transfer (p,s : transfer * storage) : operation list * storage =
if (authorized_value < p.value)
then (failwith "Not Enough Allowance" : allowances)
else Big_map.update (Tezos.sender,p.address_from) (Some (abs(authorized_value - p.value))) s.allowances
in
in
let sender_balance = match Big_map.find_opt p.address_from s.tokens with
Some value -> value
| None -> 0n
Expand Down Expand Up @@ -151,7 +150,7 @@ let getTotalSupply (p,s : getTotalSupply * storage) : operation list * storage =
([op],s)
let main (a,s:action * storage) =
let main (a,s:action * storage) =
match a with
Transfer p -> transfer (p,s)
| Approve p -> approve (p,s)
Expand All @@ -161,13 +160,11 @@ let main (a,s:action * storage) =
```



## Your mission

Let's assume the *TezosAcamedyToken* has been deployed.
Let's assume the _TezosAcamedyToken_ has been deployed.

Consider your account is *me* (at address tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) which has been granted 1000000 token.
Consider your account is _me_ (at address tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) which has been granted 1000000 token.
Consider alice account (at address tz1NiAGZgRV8F1E3qYFEPgajntzTRDYkU9h7)

<!-- prettier-ignore -->1- We want you to simulate the transfer of 2 TAT (Tezos Academy Token) to *alice*. Write a ligo command line for preparing a simulated storage where you (tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) possess 1000000 of token and no allowances.
Expand All @@ -176,22 +173,24 @@ Consider alice account (at address tz1NiAGZgRV8F1E3qYFEPgajntzTRDYkU9h7)

<!-- prettier-ignore -->3- Write a ligo command line that simulate your invocation of previous *Approval* on storage prepared at step 1. (Don't forget to specify that you are sending this transaction).

<!-- prettier-ignore -->4- Now that ligo compiler ensured us that simulation is good, we will try to simulate it with the tezos-client command line in order to know the right amount of gas needed to run execute *approval*. You can consider that step 2 produced the following michelson expression:
<!-- prettier-ignore -->4- Now that ligo compiler ensured us that simulation is good, we will try to simulate it with the tezos-client command line in order to know the right amount of gas needed to run execute *approval*. You can consider that step 2 produced the following Michelsonexpression:

```
(Left (Left (Left (Pair "tz1NiAGZgRV8F1E3qYFEPgajntzTRDYkU9h7" 2))))
```

<!-- prettier-ignore -->5-Write a tezos command line that simulate your invocation.

<!-- prettier-ignore -->6- Now that approval has been exeucted on blockchain, 2 TAT can be transfered from your address to *alice*. Write a ligo command line for preparing invocation of a *Transfer* of 2 TAT (Tezos Academy Token) from you to *alice*.


<!-- prettier-ignore -->7- Write a ligo command line for preparing a simulated storage where you (tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ) possess 1000000 of token and allowances is initialized with 2 TAT that can be transfered from *me* to *alice* (tz1NiAGZgRV8F1E3qYFEPgajntzTRDYkU9h7).

<!-- prettier-ignore -->8- Write a ligo command line that simulate your invocation of previous *Transfer* on storage prepared at step 7. (Don't forget to specify that you are sending this transaction).

<!-- prettier-ignore -->9- Now that ligo compiler ensured us that simulation is good, we will try to simulate it with the tezos-client command line in order to know the right amount of gas needed to run execute *transfer*. You can consider that step 6 produces the following michelson expression:
<!-- prettier-ignore -->9- Now that ligo compiler ensured us that simulation is good, we will try to simulate it with the tezos-client command line in order to know the right amount of gas needed to run execute *transfer*. You can consider that step 6 produces the following Michelsonexpression:

```
(Right (Pair (Pair "tz1SdT62G8tQp9fdHh4f2m4VtL8aGG6NUcmJ" "tz1NiAGZgRV8F1E3qYFEPgajntzTRDYkU9h7") 2))
```

<!-- prettier-ignore -->10-Write a tezos command line that simulate your *Transfer* invocation.
<!-- prettier-ignore -->10-Write a tezos command line that simulate your *Transfer* invocation.
Loading

0 comments on commit 2701160

Please sign in to comment.