From 156db3c4c05acf8a0c1f8034d80f0fc57875aa06 Mon Sep 17 00:00:00 2001 From: Frank Hillard Date: Tue, 13 Oct 2020 14:25:29 +0200 Subject: [PATCH 1/4] rework instructions --- .../Chapters/Camel/ChapterInterop/course.md | 20 ++++++++++++++++++- .../Chapters/Pascal/ChapterInterop/course.md | 19 +++++++++++++++++- .../Chapters/Reason/ChapterInterop/course.md | 20 ++++++++++++++++++- 3 files changed, 56 insertions(+), 3 deletions(-) diff --git a/src/frontend/src/pages/Chapters/Camel/ChapterInterop/course.md b/src/frontend/src/pages/Chapters/Camel/ChapterInterop/course.md index 57a584a..40af6f7 100644 --- a/src/frontend/src/pages/Chapters/Camel/ChapterInterop/course.md +++ b/src/frontend/src/pages/Chapters/Camel/ChapterInterop/course.md @@ -289,4 +289,22 @@ let make_abstract_record (z: string) (y: int) (x: string) (w: bool) (v: int) : t We want you to modify our "inventory" contract. As you can see the storage is mainly composed of an item inventory where each item is a right combed nested pair. The contract possesses a single entry point AddInventory. This _AddInventory_ function adds each element in the inventory (don't worry about duplicates it has already been taken care of). -1- Complete the implementation of the *update\_inventory* lambda function. This function takes a list of items as parameter and must transform each item in a combed pair structure and add this resulting structure in the storage inventory. (When naming your temporary variables, use *acc* for the accumulator name and *i* for the current item) +1- Complete the implementation of the *update\_inventory* lambda function. This function must transform each item in a combed pair structure. + +Take a look at the instruction using the *update\_inventory* lambda function : + +``` +let new_inventory : item_michelson list = List.fold update_inventory item_list s.inventory in +(([] : operation list), {s with inventory=new_inventory}) +``` + +As you can see the *update\_inventory* lambda function is applied to the given list of items and the resulting structure updates the storage inventory. + +(Recall) As you can see the *update\_inventory* lambda function is used in a *List.fold* instruction which implies that the *update\_inventory* lambda function takes 2 parameters : +- an accumulator (conventionnaly named *acc*) +- an item of the given folded list +and produces a new accumulator. + +When naming your parameters, use *acc* for the accumulator name and *i* for the current item. + +(Recall) One can use the *::* operator to add an element in a list. \ No newline at end of file diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterInterop/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterInterop/course.md index a679aae..8c2c666 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterInterop/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterInterop/course.md @@ -321,4 +321,21 @@ function make_abstract_record (const z: string; const y: int; const x: string; c We want you to modify our "inventory" contract. As you can see the storage is mainly composed of an item inventory where each item is a right combed nested pair. The contract possesses a single entry point AddInventory. This _AddInventory_ function adds each element in the inventory (don't worry about duplicates it has already been taken care of). -1- Complete the implementation of the *update_inventory* lambda function. This function takes a list of items as parameter and must transform each item in a combed pair structure and add this resulting structure in the storage inventory. (When naming your temporary variables, use *acc* for the accumulator name and *i* for the current item) +1- Complete the implementation of the *update\_inventory* lambda function. This function must transform each item in a combed pair structure. + +Take a look at the instruction using the *update\_inventory* lambda function : + +``` +s.inventory := List.fold(update_inventory, item_list, s.inventory); +``` + +As you can see the *update\_inventory* lambda function is applied to the given list of items and the resulting structure updates the storage inventory. + +(Recall) As you can see the *update\_inventory* lambda function is used in a *List.fold* instruction which implies that the *update\_inventory* lambda function takes 2 parameters : +- an accumulator (conventionnaly named *acc*) +- an item of the given folded list +and produces a new accumulator. + +When naming your parameters, use *acc* for the accumulator name and *i* for the current item. + +(Recall) One can use the *#* operator to add an element in a list. diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md b/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md index 9943bda..abdfc72 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md +++ b/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md @@ -301,4 +301,22 @@ let make_abstract_record = (z: string, y: int, x: string, w: bool, v: int) : tes We want you to modify our "inventory" contract. As you can see the storage is mainly composed of an item inventory where each item is a right combed nested pair. The contract possesses a single entry point AddInventory. This _AddInventory_ function adds each element in the inventory (don't worry about duplicates it has already been taken care of). -1- Complete the implementation of the *update_inventory* lambda function. This function takes a list of items as parameter and must transform each item in a combed pair structure and add this resulting structure in the storage inventory. (When naming your temporary variables, use *acc* for the accumulator name and *i* for the current item) +1- Complete the implementation of the *update\_inventory* lambda function. This function must transform each item in a combed pair structure. + +Take a look at the instruction using the *update\_inventory* lambda function : + +``` + let new_inventory : list(item_michelson) = List.fold(update_inventory, item_list, s.inventory); + (([] : list(operation)), {...s, inventory:new_inventory}) +``` + +As you can see the *update\_inventory* lambda function is applied to the given list of items and the resulting structure updates the storage inventory. + +(Recall) As you can see the *update\_inventory* lambda function is used in a *List.fold* instruction which implies that the *update\_inventory* lambda function takes 2 parameters : +- an accumulator (conventionnaly named *acc*) +- an item of the given folded list +and produces a new accumulator. + +When naming your parameters, use *acc* for the accumulator name and *i* for the current item. + +(Recall) One can use the *[element, ...list]* pattern to add an element in a list. \ No newline at end of file From a2dd6247ea1c09e133dd9044db6f261c91958c19 Mon Sep 17 00:00:00 2001 From: Frank Hillard Date: Tue, 13 Oct 2020 18:29:37 +0200 Subject: [PATCH 2/4] use case interoperability (reason) --- .../Chapters/Reason/ChapterInterop/course.md | 67 ++++++++++++++++++- 1 file changed, 65 insertions(+), 2 deletions(-) diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md b/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md index abdfc72..04d69a7 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md +++ b/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md @@ -1,9 +1,72 @@ # Chapter 26 : Interoperability with Michelson Captain, some ressources are missing from our inventory, you should investigate. -Tezos smart contracts are written in Michelson language. The LIGO transpiler helps developers to produce Michelson scripts. However LIGO data structures might have different representations in Michelson. For example, LIGO allows to define a record (a structure containing many fields) but once transpiled in Michelson this record is transformed in a pair of pairs, and there can be many pairs of pairs representing the same record. -In this chapter, we will see that some built-in functions are available in LIGO language in order to address this problem. +In this chapter, we will see that some built-in functions are available in LIGO language in order to address interoperability with Michelson. + +## Use case + +Tezos smart contracts are written in Michelson language. The LIGO transpiler helps developers to produce Michelson scripts. However LIGO data structures might have different representations in Michelson. For this reason, some interoperability issues can occur when contracts communicate between each other. + +As seen in previous *chapter 21: Polymorphism*, when contracts communicate between each other they call an entrypoint of contract. This entrypoint requires michelson-typed parameters. + +LIGO allows to define a record (a structure containing many fields) but once transpiled in Michelson this record is transformed in a pair of pairs, and there can be many pairs of pairs representing the same record. + +For example a record containing 3 fields A, B and C could be transpiled into right combed pairs : + + ``` +( pair (int %a) ( pair (int %b) (int %c) ) ) + ``` + +or a left combed pairs : + + ``` +( pair ( pair (int %a) (int %b) ) (int %c) ) + ``` + +These two representations have different structures. + +When interacting with other contracts the representation (left or right combed) must be specified in order to match the required type of the invoked entrypoint. This is done by using some built-in functions of the LIGO language. + +Let's go deeper into the Michelson representation and related LIGO helper functions. + +### Example with FA2 + +In the last chapters we will see in detail the Financial Application standard (called FA2) which allows to create tokens. This standard uses a specific right combed representation of Ligo records. + +All contracts that need to interact with a token contract (buying tokens or selling tokens) must transpile parameters into the required michelson representation. + +Example of a calling contract that has *transfer_param* parameter which must fit with required FA2 interface. So while calling FA2 , parameters must be specified in the right representation. + +example of parameters to be sent + +``` +type transfer_param is [ + buyer: address, + value: nat, + owner: address +] +``` + +example of expected parameters from FA2 interface: + +``` +type transferContents = { + to_: tokenOwner, + token_id: tokenId, + amount: tokenAmount +} +type transferAuxiliary = { + from_: tokenOwner, + txs: list(transferContentsMichelson) +}; +type transferMichelson = michelson_pair_right_comb(transferAuxiliary); +type transferParameter = list(transferMichelson); +type parameter = +| Transfer(transferParameter) +... +``` + ## Annotations From cb003840e8f5a52372f9f378cbbc713fc3924c88 Mon Sep 17 00:00:00 2001 From: Frank Hillard Date: Tue, 13 Oct 2020 22:00:37 +0200 Subject: [PATCH 3/4] BUG FIX: (multisig/pascal) mission description (wrong copy/paste) --- .../pages/Chapters/Pascal/ChapterMultisig/course.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterMultisig/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterMultisig/course.md index 90318fe..1e221ab 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterMultisig/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterMultisig/course.md @@ -217,10 +217,15 @@ Notice that in the _Withdraw_ function : - if a message proposal has no voters then it is removed - the counter (of number of proposals) is updated. This is used to compute the limit of maximum of proposal. + ## Your mission - 1- Notice that the storage contains a property called *reputation* which associates a _nat_ number to a voter. + Modify the existing *Multisig* contract in order to handle reputation level for each voters. We plan to grant reputation points when the message is really executed (one point of reputation for each voters). + + 1- Modify storage to have an additionnal property called *reputation* which associates a _nat_ number to a voter. + + In the *send* function, notice that voters are computed in a variable *new_store*. - 2- Modify the *increment* function to modify the reputation of a given *addr* address by granting one point of reputation. (use *count* as temporary variable for the _switch_ operator). If the voter is not registered yet in the *reputation* registry then add him. Otherwise update its reputation by incrementing by one its actual level. It is recommanded to use Map.add and Map.update when modifying a _map_. + 2- Modify the *send* function (at the specified code location), by iterating on voters (*new_store* variable) with a _for_ loop (use *addr* as temporary variable for the loop). - 3- Modify the *reputation_updated* variable (representing the new state of reputations) by iterating on voters with a _Set.fold_ operation and applying *increment* function on reputation. + 3- For each voter, modify the *reputation* of a given *addr* address by granting one point of reputation. Use a _case_ operator to verify if the voter has already a reputation account (use *count* as temporary variable for the _Some_ operator). If the voter is not registered yet in the *reputation* register then add him otherwise update its reputation by incrementing by one its actual level. It is recommanded to use Map.add and Map.update when modifying a _map_. \ No newline at end of file From 6a267181b5ddf81f3f1716e89d45fea09cec5285 Mon Sep 17 00:00:00 2001 From: Frank Hillard Date: Thu, 15 Oct 2020 12:33:19 +0200 Subject: [PATCH 4/4] rework interoperability intro/usecase --- .../Chapters/Camel/ChapterInterop/course.md | 46 ++++++++++++++++++- .../Chapters/Pascal/ChapterInterop/course.md | 46 ++++++++++++++++++- .../Chapters/Reason/ChapterInterop/course.md | 41 ++++------------- 3 files changed, 98 insertions(+), 35 deletions(-) diff --git a/src/frontend/src/pages/Chapters/Camel/ChapterInterop/course.md b/src/frontend/src/pages/Chapters/Camel/ChapterInterop/course.md index 40af6f7..e2eb745 100644 --- a/src/frontend/src/pages/Chapters/Camel/ChapterInterop/course.md +++ b/src/frontend/src/pages/Chapters/Camel/ChapterInterop/course.md @@ -1,9 +1,51 @@ # Chapter 26 : Interoperability with Michelson Captain, some ressources are missing from our inventory, you should investigate. -Tezos smart contracts are written in Michelson language. The LIGO transpiler helps developers to produce Michelson scripts. However LIGO data structures might have different representations in Michelson. For example, LIGO allows to define a record (a structure containing many fields) but once transpiled in Michelson this record is transformed in a pair of pairs, and there can be many pairs of pairs representing the same record. -In this chapter, we will see that some built-in functions are available in LIGO language in order to address this problem. +In this chapter, we will stress at the interoperability issue with Michelson which occurs when contracts are interacting between each other. We will see some built-in functions provided in the LIGO language in order to address this topic. + +## Use case + +Tezos smart contracts are written in Michelson language. The LIGO transpiler helps developers to produce Michelson scripts. However LIGO data structures might have different representations in Michelson. For this reason, some interoperability issues can occur when contracts communicate between each other. + +### Multiple representations + +LIGO allows to define a record (a structure containing many fields) but once transpiled in Michelson this record is transformed in a pair of pairs, and there can be many pairs of pairs representing the same record. Interoperability issues can occur because of this multiplicity of representation. + +For example a record containing 3 fields A, B and C could be transpiled into right combed pairs : + + ``` +( pair (int %a) ( pair (int %b) (int %c) ) ) + ``` + +or a left combed pairs : + + ``` +( pair ( pair (int %a) (int %b) ) (int %c) ) + ``` + +These two representations have different structures. + +When interacting with other contracts the representation (left or right combed) must be specified in order to match the required type of the invoked entrypoint. This is done by using some built-in functions of the LIGO language. + +### Interacting with an other contract + +In chapters 28 to 30, we will see in detail the Financial Application standard (called FA2) which allows to create a standardized token contract. This FA2 token contract provides a *Transfer* entrypoint for transfering the token ownership between users. This entrypoint requires parameters that must respect a right combed representation of Ligo records. + +For example, if a third-party contract (called *Caller* contract) wants to interact with a FA2 token contract (called *token* contract), it would use the entrypoint *Transfer* which expects parameters with a right combed representation of Ligo records. So, when the *Caller* contract sends a transaction to the *token* contract, it must transform parameters of the called entrypoint into the expected representation. + +The snippet of code below is part of the standard FA2 interface, and defines transfer parameters using *michelson\_pair\_right\_comb* function for specifying the Michelson representation used by the *Transfer* entrypoint. + +``` +type transferMichelson = michelson_pair_right_comb(transferAuxiliary); +type transferParameter = list(transferMichelson); +type parameter = +| Transfer(transferParameter) +``` + +We will see in detail the Financial Application standard in chapters 28 to 30. + +Let's go deeper into the Michelson representation and related LIGO helper functions. ## Annotations diff --git a/src/frontend/src/pages/Chapters/Pascal/ChapterInterop/course.md b/src/frontend/src/pages/Chapters/Pascal/ChapterInterop/course.md index 8c2c666..5ae6c36 100644 --- a/src/frontend/src/pages/Chapters/Pascal/ChapterInterop/course.md +++ b/src/frontend/src/pages/Chapters/Pascal/ChapterInterop/course.md @@ -1,9 +1,51 @@ # Chapter 26 : Interoperability with Michelson Captain, some ressources are missing from our inventory, you should investigate. -Tezos smart contracts are written in Michelson language. The LIGO transpiler helps developers to produce Michelson scripts. However LIGO data structures might have different representations in Michelson. For example, LIGO allows to define a record (a structure containing many fields) but once transpiled in Michelson this record is transformed in a pair of pairs, and there can be many pairs of pairs representing the same record. -In this chapter, we will see that some built-in functions are available in LIGO language in order to address this problem. +In this chapter, we will stress at the interoperability issue with Michelson which occurs when contracts are interacting between each other. We will see some built-in functions provided in the LIGO language in order to address this topic. + +## Use case + +Tezos smart contracts are written in Michelson language. The LIGO transpiler helps developers to produce Michelson scripts. However LIGO data structures might have different representations in Michelson. For this reason, some interoperability issues can occur when contracts communicate between each other. + +### Multiple representations + +LIGO allows to define a record (a structure containing many fields) but once transpiled in Michelson this record is transformed in a pair of pairs, and there can be many pairs of pairs representing the same record. Interoperability issues can occur because of this multiplicity of representation. + +For example a record containing 3 fields A, B and C could be transpiled into right combed pairs : + + ``` +( pair (int %a) ( pair (int %b) (int %c) ) ) + ``` + +or a left combed pairs : + + ``` +( pair ( pair (int %a) (int %b) ) (int %c) ) + ``` + +These two representations have different structures. + +When interacting with other contracts the representation (left or right combed) must be specified in order to match the required type of the invoked entrypoint. This is done by using some built-in functions of the LIGO language. + +### Interacting with an other contract + +In chapters 28 to 30, we will see in detail the Financial Application standard (called FA2) which allows to create a standardized token contract. This FA2 token contract provides a *Transfer* entrypoint for transfering the token ownership between users. This entrypoint requires parameters that must respect a right combed representation of Ligo records. + +For example, if a third-party contract (called *Caller* contract) wants to interact with a FA2 token contract (called *token* contract), it would use the entrypoint *Transfer* which expects parameters with a right combed representation of Ligo records. So, when the *Caller* contract sends a transaction to the *token* contract, it must transform parameters of the called entrypoint into the expected representation. + +The snippet of code below is part of the standard FA2 interface, and defines transfer parameters using *michelson\_pair\_right\_comb* function for specifying the Michelson representation used by the *Transfer* entrypoint. + +``` +type transferMichelson = michelson_pair_right_comb(transferAuxiliary); +type transferParameter = list(transferMichelson); +type parameter = +| Transfer(transferParameter) +``` + +We will see in detail the Financial Application standard in chapters 28 to 30. + +Let's go deeper into the Michelson representation and related LIGO helper functions. ## Annotations diff --git a/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md b/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md index 04d69a7..8a3c771 100644 --- a/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md +++ b/src/frontend/src/pages/Chapters/Reason/ChapterInterop/course.md @@ -2,15 +2,15 @@ Captain, some ressources are missing from our inventory, you should investigate. -In this chapter, we will see that some built-in functions are available in LIGO language in order to address interoperability with Michelson. +In this chapter, we will stress at the interoperability issue with Michelson which occurs when contracts are interacting between each other. We will see some built-in functions provided in the LIGO language in order to address this topic. ## Use case Tezos smart contracts are written in Michelson language. The LIGO transpiler helps developers to produce Michelson scripts. However LIGO data structures might have different representations in Michelson. For this reason, some interoperability issues can occur when contracts communicate between each other. -As seen in previous *chapter 21: Polymorphism*, when contracts communicate between each other they call an entrypoint of contract. This entrypoint requires michelson-typed parameters. +### Multiple representations -LIGO allows to define a record (a structure containing many fields) but once transpiled in Michelson this record is transformed in a pair of pairs, and there can be many pairs of pairs representing the same record. +LIGO allows to define a record (a structure containing many fields) but once transpiled in Michelson this record is transformed in a pair of pairs, and there can be many pairs of pairs representing the same record. Interoperability issues can occur because of this multiplicity of representation. For example a record containing 3 fields A, B and C could be transpiled into right combed pairs : @@ -28,45 +28,24 @@ These two representations have different structures. When interacting with other contracts the representation (left or right combed) must be specified in order to match the required type of the invoked entrypoint. This is done by using some built-in functions of the LIGO language. -Let's go deeper into the Michelson representation and related LIGO helper functions. - -### Example with FA2 - -In the last chapters we will see in detail the Financial Application standard (called FA2) which allows to create tokens. This standard uses a specific right combed representation of Ligo records. +### Interacting with an other contract -All contracts that need to interact with a token contract (buying tokens or selling tokens) must transpile parameters into the required michelson representation. +In chapters 28 to 30, we will see in detail the Financial Application standard (called FA2) which allows to create a standardized token contract. This FA2 token contract provides a *Transfer* entrypoint for transfering the token ownership between users. This entrypoint requires parameters that must respect a right combed representation of Ligo records. -Example of a calling contract that has *transfer_param* parameter which must fit with required FA2 interface. So while calling FA2 , parameters must be specified in the right representation. +For example, if a third-party contract (called *Caller* contract) wants to interact with a FA2 token contract (called *token* contract), it would use the entrypoint *Transfer* which expects parameters with a right combed representation of Ligo records. So, when the *Caller* contract sends a transaction to the *token* contract, it must transform parameters of the called entrypoint into the expected representation. -example of parameters to be sent +The snippet of code below is part of the standard FA2 interface, and defines transfer parameters using *michelson\_pair\_right\_comb* function for specifying the Michelson representation used by the *Transfer* entrypoint. ``` -type transfer_param is [ - buyer: address, - value: nat, - owner: address -] -``` - -example of expected parameters from FA2 interface: - -``` -type transferContents = { - to_: tokenOwner, - token_id: tokenId, - amount: tokenAmount -} -type transferAuxiliary = { - from_: tokenOwner, - txs: list(transferContentsMichelson) -}; type transferMichelson = michelson_pair_right_comb(transferAuxiliary); type transferParameter = list(transferMichelson); type parameter = | Transfer(transferParameter) -... ``` +We will see in detail the Financial Application standard in chapters 28 to 30. + +Let's go deeper into the Michelson representation and related LIGO helper functions. ## Annotations