Some correction (#213)

docs/02-basic/01-introduction/actor-model.md

@@ -19,6 +19,6 @@ Essentially, actors are able to independently receive inputs, perform functions,
 
 The Actor Model differs from other methods for program communication in that it passes messages between actors instead of sharing a network state. This contributes to greater program security and robustness, because each actor has its own individual mailbox and cannot change the state of another actor within the chain.
 
-Typically, smart contracts lack the ability to support asynchronous messaging, but as implemented by Gear, the Actor Model provides native arbitrary asynchronous communication for all programs. This allows for the use of design patterns and language constructs enabled by asynchronous programming that are commonly seen in Web 2 contexts today — greatly simplifying both development and testing, whilst unlocking entirely new use cases for smart contracts. Importantly, Gear details design principles and patterns that align concurrent communication inside smart contract logic with program state consistency.
+Typically, smart contracts lack the ability to support asynchronous messaging, but as implemented by Gear, the Actor Model provides native arbitrary asynchronous communication for all programs. This allows for the use of design patterns and language constructs enabled by asynchronous programming that are commonly seen in Web 2.0 contexts today — greatly simplifying both development and testing, whilst unlocking entirely new use cases for smart contracts. Importantly, Gear details design principles and patterns that align concurrent communication inside smart contract logic with program state consistency.
 
-Actor isolation, asynchronous message-passing, and state encapsulation make the Actor Model a very highly fault-tolerant framework because it provides mechanisms that allow systems to recover from failures and continue operating. Combined with the aforementioned improvements to performance, scalability, developer experience, and design choices — Gear’s use of the Actor Model makes it an ideal environment to create the next generation of fast & scalable Web 3.0 dApps using established tools and workflows from the Web 2 world.
+Actor isolation, asynchronous message-passing, and state encapsulation make the Actor Model a very highly fault-tolerant framework because it provides mechanisms that allow systems to recover from failures and continue operating. Combined with the aforementioned improvements to performance, scalability, developer experience, and design choices — Gear’s use of the Actor Model makes it an ideal environment to create the next generation of fast & scalable Web 3.0 dApps using established tools and workflows from the Web 2.0 world.

docs/02-basic/01-introduction/program-state.md

@@ -5,13 +5,13 @@ hide_table_of_contents: true
 
 # Program State
 
-Gear programs are very similar to any other programs in terms of memory usage. They have a stack, static, and heap sections. The main difference is that Gear programs are stateful and their state is persisted in the blockchain’s state. That means that the program’s state is preserved between calls.
+Programs on Vara are very similar to any other programs in terms of memory usage. They have a stack, static, and heap sections. The main difference is that Programs on Vara are stateful and their state is persisted in the blockchain’s state. That means that the program’s state is preserved between calls.
 
 Program memory is organized in pages of 64KB according to the Wasm memory model. These pages are used for static data as well as for heap allocations. The stack is not persisted between calls. If the program needs more memory, it can allocate additional pages. The program can also deallocate pages that are not needed anymore. Each memory block allocation requires a gas fee. Each page (64KB) is stored separately on the distributed database backend, but at the run time, Gear node constructs continuous runtime memory and allows programs to run on it without reloads.
 
 ## Persistent memory
 
-Programs running in Gear Networks don’t use a shared storage but rather their full state is persisted which ensures much less API surface for blockchain context. It avoids domain-specific language features as well as allows using much more complex language constructs — persisted boxed closures, futures compositors, etc.
+Programs running in Vara networks don’t use a shared storage but rather their full state is persisted which ensures much less API surface for blockchain context. It avoids domain-specific language features as well as allows using much more complex language constructs — persisted boxed closures, futures compositors, etc.
 
 The Gear Protocol uses clever memory virtualization techniques (despite vanilla Wasm does not), memory allocation and deallocation are first-class syscalls of the protocol. Memory access is also tracked and only required pages are loaded/stored. That allows heap-allocated frames of smart contracts stored in the blockchain’s state (typically found in futures and their compositors) to be seamlessly persisted and invoked when needed, preserving their state upon request.
 

docs/02-basic/04-usage/upload-program.md

@@ -13,7 +13,7 @@ hide_table_of_contents: true
 
     ![Upload program form](../img/04/interface.png)
 
-3. Sign the program uploading the transaction to the Gear network. Also, sign the program and metadata upload to the Gear demo environment so you could work with the program. It is recommended to set the checkbox `Remember my password for the next 15 minutes` for your convenience.
+3. Sign the program uploading the transaction to the Vara network. Also, sign the program and metadata upload to the Gear demo environment so you could work with the program. It is recommended to set the checkbox `Remember my password for the next 15 minutes` for your convenience.
 
     ![Sign transaction](../img/04/sign-transaction.png)