ICM Course: add quizzes and certificate (#197)

content/course/interchain-messaging/02-interoperability/02-source-message-destination.mdx

@@ -39,4 +39,6 @@ The message is the data structure that will be sent to to the destination chain.
 
 ## Destination Chain
 
-Conversely, the destination chain is the recipient blockchain where the communicated data, assets, or instructions will be received and processed. Validators, nodes, or protocols associated with the cross-blockchain communication system on the destination chain receive and authenticate the information relayed from the source chain. Once validated, the destination chain processes the data or executes the specified instructions.
+Conversely, the destination chain is the recipient blockchain where the communicated data, assets, or instructions will be received and processed. Validators, nodes, or protocols associated with the cross-blockchain communication system on the destination chain receive and authenticate the information relayed from the source chain. Once validated, the destination chain processes the data or executes the specified instructions.
+
+<Quiz quizId="301"/>

content/course/interchain-messaging/02-interoperability/03-multi-chain-networks.mdx

@@ -28,4 +28,6 @@ Different blockchain networks use different scaling approaches, such as Layer 2s
 
 ![](/common-images/multi-chain-architecture/combined-throughput.png)
 
-While roll-ups may enable a very high-throughput of a single chain, they can never outcompete the combined throughput of a multi-chain system. This is because there's no limit to the number of chains that can run in parallel.
+While roll-ups may enable a very high-throughput of a single chain, they can never outcompete the combined throughput of a multi-chain system. This is because there's no limit to the number of chains that can run in parallel.
+
+<Quiz quizId="302"/>

content/course/interchain-messaging/04-icm-basics/02-recap-bytes-encoding-decoding.mdx

@@ -49,4 +49,6 @@ When we decode data, we convert it from a byte array back into its original form
 ) = abi.decode(message, (string, uint));
 ```
 
-This will give us back the original values that we encoded before. Note that we do need to know the types of the values and their order that we encoded to decode them correctly.
+This will give us back the original values that we encoded before. Note that we do need to know the types of the values and their order that we encoded to decode them correctly.
+
+<Quiz quizId="303"/>

content/course/interchain-messaging/04-icm-basics/03-sending-a-message.mdx

@@ -61,3 +61,5 @@ The `sendCrossChainMessage` function takes `TeleporterMessageInput` struct as an
 - **`requiredGasLimit`:** The amount of gas the delivery of the message requires. If the relayer provides the required gas, the message will be considered delivered whether or not its execution succeeds, such that the relayer can claim their fee reward.
 - **`allowedRelayerAddresses`:** An array of addresses of allowed relayers. An empty allowed relayers list means anyone is allowed to deliver the message. We will look at this later in more detail.
 - **`message`:** The message to be sent as bytes. The message can contain multiple encoded values. DApps using Interchain Messaging are responsible for defining the exact format of this payload in a way that can be decoded on the receiving end. The message can hold multiple values that be encoded in a single bytes object. For example, applications may encode multiple method parameters on the sending side, then decode this data in the contract implementing the receiveTeleporterMessage function and call another contract with the parameters from there.
+
+<Quiz quizId="304"/>

content/course/interchain-messaging/04-icm-basics/05-receiving-a-message.mdx

@@ -89,3 +89,5 @@ contract MessageReceiver is ITeleporterReceiver {
 ```
 
 This contract stores the last `Message` and it's sender of each chain it has received. When it is instantiated, the address of the Interchain Messaging contract is supplied to the constructor. The contract implements the `ITelepoterReceiver` interface and therefore we also implement the `receiveTeleporterMessage` function. 
+
+<Quiz quizId="305"/>

content/course/interchain-messaging/06-invoking-functions/02-encoding-multiple-values.mdx

@@ -90,3 +90,4 @@ Here we are using `abi.decode()` to unpack the three values `(someString, someNu
   address someAddress
 ) = abi.decode(message, (string, uint, address));  // [!code highlight]
 ``` 
+<Quiz quizId="306"/>

content/course/interchain-messaging/06-invoking-functions/06-encoding-function-name.mdx

@@ -248,3 +248,5 @@ cast call --rpc-url myblockchain $RECEIVER_ADDRESS "result_num()(uint)"
 
 </Step>
 </Steps>
+
+<Quiz quizId="307"/>

content/course/interchain-messaging/07-icm-registry/02-how-the-icm-registry-works.mdx

@@ -79,3 +79,5 @@ contract TeleporterRegistry {
 ```
 
 If you are interested in the entire implementation, check it out [here](https://github.com/ava-labs/teleporter/blob/main/contracts/teleporter/registry/TeleporterRegistry.sol).
+
+<Quiz quizId="308"/>

content/course/interchain-messaging/08-securing-cross-chain-communication/02-signature-schemes.mdx

@@ -8,4 +8,6 @@ icon: BookOpen
 
 import SignatureSchemes from "@/content/common/cryptography/signature-schemes.mdx"
 
-<SignatureSchemes />
+<SignatureSchemes />
+
+<Quiz quizId="309"/>

content/course/interchain-messaging/08-securing-cross-chain-communication/04-multi-signature-schemes.mdx

@@ -8,4 +8,6 @@ icon: BookOpen
 
 import MultiSignatureSchemes from "@/content/common/cryptography/multi-signature-schemes.mdx"
 
-<MultiSignatureSchemes />
+<MultiSignatureSchemes />
+
+<Quiz quizId="310"/>

content/course/interchain-messaging/09-avalanche-warp-messaging/02-p-chain.mdx

@@ -9,3 +9,5 @@ icon: BookOpen
 import PChain from "@/content/common/primary-network/p-chain.mdx";
 
 <PChain />
+
+<Quiz quizId="311"/>

content/course/interchain-messaging/09-avalanche-warp-messaging/05-dataflow.mdx

@@ -61,3 +61,5 @@ As you noticed in the `Teleporter Basics` chapter most of the cross-chain commun
 - **Receiving a message:** Being able to be called by the Interchain Messaging on the destination chain
 
 To start, we will assume there is always an AWM Relayer to deliver our messages without any incentives. Let's dive deeper into the sending and receiving of messages in the next sections.
+
+<Quiz quizId="312"/>

content/course/interchain-messaging/09-avalanche-warp-messaging/06-message-pickup.mdx

@@ -55,4 +55,6 @@ For the source Avalanche L1s, the AWM Relayer offers the following configuration
 - **message-contracts:** A map with the address of the Interchain Messaging contract as key and the following config parameters as values:
     - **message-format:** A string specifying the format. Currently, only the format "teleporter" exists, but this field has been added in anticipation of multiple formats in the future
     - **settings:** A dictionary with settings for this Interchain Messaging contract 
-    - **reward-address:** The address rewards are paid out to
+    - **reward-address:** The address rewards are paid out to
+
+<Quiz quizId="313"/>

content/course/interchain-messaging/09-avalanche-warp-messaging/07-message-delivery.mdx

@@ -61,4 +61,6 @@ The BLS public key aggregation has to be done by every validator of the destinat
 
 Even though this would make the verification much faster, there is a security issue here. How can we be sure that the aggregated public key actually represents the public keys of the signing validators? How do we know that the AWM Relayer did not just create a bunch of public keys and an aggregated signature of these?
 
-The only way to verify that is to aggregate the public keys of the signing validators and compare it to the one sent by the AWM Relayer. Therefore, it is pointless to attach it to the message.
+The only way to verify that is to aggregate the public keys of the signing validators and compare it to the one sent by the AWM Relayer. Therefore, it is pointless to attach it to the message.
+
+<Quiz quizId="314"/>

content/course/interchain-messaging/12-incentivizing-a-relayer/02-fee-data-flow.mdx

@@ -49,4 +49,6 @@ We are using the following emoji guide to show the actors of each action:
 
 As you can see, there are just a few actions you as a cross-chain dApp developer need to implement so dApp works smoothly with fees, everything else is being done by the Interchain Messaging contract and the Relayer.
 
-If you run your own relayer, you don't have to attach any fees.
+If you run your own relayer, you don't have to attach any fees.
+
+<Quiz quizId="315"/>

content/course/interchain-messaging/12-incentivizing-a-relayer/03-determining-the-fee-amount.mdx

@@ -59,3 +59,5 @@ Then:
 *Amount = 550,000,000,000,000 weiTLP*
 
 All amounts in Solidity need to be declared in wei, so use a unit converter to convert from nTLP to wei (10^-18).
+
+<Quiz quizId="316"/>

content/course/interchain-messaging/certificate.mdx

@@ -0,0 +1,14 @@
+---
+title: Course Completion Certificate
+updated: 2024-10-11
+authors: [owenwahlgren]
+icon: BadgeCheck
+---
+
+import CertificatePage from '@/components/certificates';
+
+You've made it to the end of the course. Let's check your progress and get your certificate.
+
+<CertificatePage courseId="interchain-messaging"/>
+
+Thank you for participating in this course. We hope you found it informative and enjoyable!

content/course/interchain-messaging/meta.json

@@ -24,6 +24,8 @@
     "---Restricting-the-relayer---",
     "...11-restricting-the-relayer",
     "---Incentivizing a Relayer---",
-    "...12-incentivizing-a-relayer"
+    "...12-incentivizing-a-relayer",
+    "---Conclusion---",
+    "certificate"
   ]
 }