From 3483a9344d97a436998f5c315587e0b039120074 Mon Sep 17 00:00:00 2001 From: MedovTimur <62596970+MedovTimur@users.noreply.github.com> Date: Fri, 19 Apr 2024 16:40:24 +0300 Subject: [PATCH] Minor fix (#231) --- docs/03-intermediate/02-message-receiving/handle_reply.md | 4 ++-- docs/03-intermediate/03-wait-wake-system/wait_wake.md | 2 +- docs/03-intermediate/04-delayed-message/delayed-message.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/03-intermediate/02-message-receiving/handle_reply.md b/docs/03-intermediate/02-message-receiving/handle_reply.md index 6728f9f..392f5c0 100644 --- a/docs/03-intermediate/02-message-receiving/handle_reply.md +++ b/docs/03-intermediate/02-message-receiving/handle_reply.md @@ -9,7 +9,7 @@ In this lesson, you will learn how a program can efficiently handle request mess Imagine a dApp with specific functionality. To update this application, you'd upload a new version to the blockchain, which would cause the dApp's address to change. For a smooth user transition, you need to maintain a consistent address for interaction. A Proxy program lets you achieve this. The Proxy program will act as an intermediary: it will receive messages from users, forward them to the updated version of the application and relay responses back to the users. Each time you update the Target program, you’d only need to update the program address of the Target in the Proxy Program. -Before analyzing program codes in detail, it will be helpful to first present a schematic overview of how Gear programs operate: +Before analyzing program codes in detail, it will be helpful to first present a schematic overview of how programs on Vara operate: ![gif 1](../img/02/handle_reply.gif) @@ -89,7 +89,7 @@ extern "C" fn handle() { } ``` -The Gear program utilizes the `handle_reply()` function to handle replies to messages. Let’s delve into processing the response message from the second program: +The program on Vara utilizes the `handle_reply()` function to handle replies to messages. Let’s delve into processing the response message from the second program: 1. Use the `msg::reply_to()` function to retrieve the identifier of the message for which the `handle_reply()` function was invoked. 2. Ensure that the message identifier matches the identifier of the message sent from the `handle()` function. This step verifies that the response corresponds to the specific message sent earlier. diff --git a/docs/03-intermediate/03-wait-wake-system/wait_wake.md b/docs/03-intermediate/03-wait-wake-system/wait_wake.md index 5f056ae..fa24f5c 100644 --- a/docs/03-intermediate/03-wait-wake-system/wait_wake.md +++ b/docs/03-intermediate/03-wait-wake-system/wait_wake.md @@ -5,7 +5,7 @@ hide_table_of_contents: true # wait() and wake() -To enhance message handling in Gear programs, the `exec::wait()` and `exec::wake()` functions are invaluable tools: +To enhance message handling in programs on Vara, the `exec::wait()` and `exec::wake()` functions are invaluable tools: ## Wait diff --git a/docs/03-intermediate/04-delayed-message/delayed-message.md b/docs/03-intermediate/04-delayed-message/delayed-message.md index fb64741..86f0c57 100644 --- a/docs/03-intermediate/04-delayed-message/delayed-message.md +++ b/docs/03-intermediate/04-delayed-message/delayed-message.md @@ -9,7 +9,7 @@ Conventional approaches by programs on other blockchains rely on external, centr An external transaction acts as a trigger to activate the program and start its logic. For instance, someone can initiate an auction by sending a message to the auction program. After the auction period expires, the program needs to process the auction's outcome. However, this process awaits until someone sends the correct message to the program, triggering this action. -Gear Protocol achieves fully on-chain logic, eliminating reliance on external services by introducing delayed messaging functionality. Programs within Gear-powered networks can execute autonomously over an unlimited number of blocks, provided there is sufficient gas for execution. This advancement eliminates the need for centralized components in dApps, enabling them to operate entirely on-chain. +Vara network achieves fully on-chain logic, eliminating reliance on external services by introducing delayed messaging functionality. Programs within Gear-powered networks can execute autonomously over an unlimited number of blocks, provided there is sufficient gas for execution. This advancement eliminates the need for centralized components in dApps, enabling them to operate entirely on-chain. The `msg::send_delayed` function facilitates sending a message after a specified delay, accepting the following parameters: - `program` - the program (or user) to which the message will be directed;