diff --git a/docs/debugging/index.md b/docs/debugging/index.md index 55e310b..02b4bce 100644 --- a/docs/debugging/index.md +++ b/docs/debugging/index.md @@ -112,4 +112,4 @@ You will need to disable Smart Transactions in MetaMask: After this, your transactions will go through the regular route and should work correctly. -[More on Smart Transactions →](https://support.metamask.io/manage-crypto/transactions/smart-transactions/) \ No newline at end of file +[More on MetaMask's Smart Transactions →](https://support.metamask.io/manage-crypto/transactions/smart-transactions/) \ No newline at end of file diff --git a/docs/docs/img/reactive-contracts.jpg b/docs/docs/img/reactive-contracts.jpg new file mode 100644 index 0000000..324e82f Binary files /dev/null and b/docs/docs/img/reactive-contracts.jpg differ diff --git a/docs/docs/img/reactive-smart-contracts.jpg b/docs/docs/img/reactive-smart-contracts.jpg deleted file mode 100644 index 709da88..0000000 Binary files a/docs/docs/img/reactive-smart-contracts.jpg and /dev/null differ diff --git a/docs/docs/index.md b/docs/docs/index.md index 8d790a3..ed715e9 100644 --- a/docs/docs/index.md +++ b/docs/docs/index.md @@ -1,12 +1,12 @@ --- sidebar_position: 1 title: Getting Started -description: Explore Reactive Network, an EVM-compatible layer for advanced dApps. Learn about Reactive Smart Contracts that use data flows from multiple blockchains. Get started with setup, development and testing, and our unique architecture. +description: Explore Reactive Network, an EVM-compatible layer for advanced dApps. Learn about Reactive Contracts that use data flows from multiple blockchains. Get started with setup, development and testing, and our unique architecture. slug: / hide_title: true --- -![Reactive Network Docs Image](./img/reactive-docs.jpg) +![Reactive Docs Image](./img/reactive-docs.jpg) ## Overview @@ -20,7 +20,7 @@ Reactive contracts receive event logs from various chains, executing Solidity lo [Hyperlane →](./hyperlane.mdx) Explore an alternative transport system for callbacks like Hyperlane. -[Reactive Contracts →](./reactive-smart-contracts.md) Understand the core concept of reactive contracts. +[Reactive Contracts →](./reactive-contracts.md) Understand the core concept of reactive contracts. [ReactVM →](./reactvm.md) Learn about ReactVM and its purpose. @@ -52,5 +52,7 @@ Reactive contracts receive event logs from various chains, executing Solidity lo [FAQ →](./faq.md) Find answers to common questions. +[Debugging →](../debugging/index.md) Debug errors and issues related to Reactive and beyond. + [Contacts →](../contacts/index.md) Reach out via socials for technical or trading inquiries. diff --git a/docs/docs/reactive-smart-contracts.md b/docs/docs/reactive-contracts.md similarity index 67% rename from docs/docs/reactive-smart-contracts.md rename to docs/docs/reactive-contracts.md index 9d1508f..1d63b13 100644 --- a/docs/docs/reactive-smart-contracts.md +++ b/docs/docs/reactive-contracts.md @@ -1,26 +1,26 @@ --- -title: Reactive Smart Contracts +title: Reactive Contracts sidebar_position: 4 -description: Explore Reactive Smart Contracts, which enable event-driven interactions and transaction creation. Learn their setup, processing, and applications through clear examples. -slug: /reactive-smart-contracts +description: Explore Reactive Contracts, which enable event-driven interactions and transaction creation. Learn their setup, processing, and applications through clear examples. +slug: /reactive-contracts hide_title: true --- -![Reactive Smart Contracts Image](./img/reactive-smart-contracts.jpg) +![Reactive Contracts Image](./img/reactive-contracts.jpg) ## Overview -Reactive smart contracts (RSCs) operate on a standard Ethereum Virtual Machine (EVM) and can be written in any EVM-compatible language, with Application Binary Interfaces (ABIs) particularly customized for Solidity. Their unique capabilities stem from reactive nodes and a specialized pre-deployed system contract. +Reactive Contracts (RCs) operate on a standard Ethereum Virtual Machine (EVM) and can be written in any EVM-compatible language, with Application Binary Interfaces (ABIs) particularly customized for Solidity. Their unique capabilities stem from Reactive nodes and a specialized pre-deployed system contract. ## Key Features -Reactive Smart Contracts (RSCs) monitor blockchains for specific events and respond automatically, unlike traditional contracts that rely on EOAs to trigger actions. This reactivity and their use of Inversion of Control (IoC) — where contracts decide when to act — set them apart. +Reactive Contracts monitor blockchains for specific events and respond automatically, unlike traditional contracts that rely on EOAs to trigger actions. This reactivity and their use of Inversion of Control (IoC) — where contracts decide when to act — set them apart. -RSCs define which blockchains, contracts, and events to watch. When a relevant event occurs, they execute logic, update state, and perform trustless transactions within the Reactive Network. +RCs define which blockchains, contracts, and events to watch. When a relevant event occurs, they execute logic, update state, and perform trustless transactions within the Reactive Network. ### Deployment -RSCs deploy to both the main Reactive Network and a private [ReactVM](./reactvm.md). The main copy interacts with EOAs and manages subscriptions via the system contract. The ReactVM copy handles event processing but is not accessible to EOAs. +RCs deploy to both the main Reactive Network and a private [ReactVM](./reactvm.md). The main copy interacts with EOAs and manages subscriptions via the system contract. The ReactVM copy handles event processing but is not accessible to EOAs. ### State and Separation @@ -28,7 +28,7 @@ The two copies are isolated and don’t share state. Since they use the same byt ### ReactVM Limitations -In [ReactVM](./reactvm.md), RSCs can’t access external systems directly. They receive logs from the Reactive Network and can call destination chain contracts but nothing else. +In [ReactVM](./reactvm.md), RCs can’t access external systems directly. They receive logs from the Reactive Network and can call destination chain contracts but nothing else. ## Contract Verification @@ -126,4 +126,4 @@ Compiler: 0.8.28 The source code will be publicly viewable, with full syntax highlighting and structure, helping others understand and trust the contract logic. -[More on Reactive Smart Contracts →](../education/module-1/reactive-smart-contracts.md) +[More on Reactive Contracts →](../education/module-1/reactive-contracts) diff --git a/docs/docs/reactvm.md b/docs/docs/reactvm.md index ed98245..770c47b 100644 --- a/docs/docs/reactvm.md +++ b/docs/docs/reactvm.md @@ -1,7 +1,7 @@ --- title: ReactVM sidebar_position: 5 -description: Explore ReactVM, a dedicated EVM within the Reactive Network for executing Reactive Smart Contracts. It enables random transactions while maintaining order, serving as a sandbox for contract deployment. +description: Explore ReactVM, a dedicated EVM within the Reactive Network for executing Reactive Contracts. It enables random transactions while maintaining order, serving as a sandbox for contract deployment. slug: /reactvm hide_title: true --- @@ -10,13 +10,13 @@ hide_title: true ## Overview -The ReactVM is a specialized Ethereum Virtual Machine (EVM) within the Reactive Network, designed to execute [Reactive Smart Contracts](./reactive-smart-contracts.md) (RSCs). It allows transactions to occur in random order across multiple threads while maintaining order within each ReactVM. +The ReactVM is a specialized Ethereum Virtual Machine (EVM) within the Reactive Network, designed to execute [Reactive Contracts](./reactive-contracts) (RCs). It allows transactions to occur in random order across multiple threads while maintaining order within each ReactVM. -Technically, ReactVM is an isolated execution environment that activates when an event matches an RSC's subscription. Although this approach introduces some overhead, we've optimized the process by separating the EVM from Geth, reducing ReactVm's boot time to approximately 100 microseconds. This overhead is insignificant relative to the network's processing capabilities. +Technically, ReactVM is an isolated execution environment that activates when an event matches an RC's subscription. Although this approach introduces some overhead, we've optimized the process by separating the EVM from Geth, reducing ReactVm's boot time to approximately 100 microseconds. This overhead is insignificant relative to the network's processing capabilities. ## My ReactVM -When you deploy a Reactive Smart Contract, it is assigned to a ReactVM. The ReactVM's address will match the Externally Owned Account (EOA) address used for the deployment. All smart contracts deployed to the Reactive Network will ultimately reside within your personal ReactVM, enabling shared state and interaction among contracts. Although multiple RSCs can be deployed within a single ReactVM, this practice is generally discouraged. +When you deploy a Reactive Contract, it is assigned to a ReactVM. The ReactVM's address will match the Externally Owned Account (EOA) address used for the deployment. All smart contracts deployed to the Reactive Network will ultimately reside within your personal ReactVM, enabling shared state and interaction among contracts. Although multiple RCs can be deployed within a single ReactVM, this practice is generally discouraged. ### Calling subscribe() @@ -30,7 +30,7 @@ The Reactive Network's state is determined by the collective states of individua The Reactive Network operates within a dual-state environment that supports parallel transaction execution. While the EVM processes commands sequentially in a single-threaded manner, ReactVMs can operate independently and in parallel across different cores or threads. This architecture facilitates the management of various operations, including fund flows and token management, with each contract copy having its own state and execution context. -Each [Reactive Smart Contract](./reactive-smart-contracts.md) has two instances with different states, both initialized in the constructor: +Each [Reactive Contract](./reactive-contracts) has two instances with different states, both initialized in the constructor:      **ReactVM State**: Updates when an event occurs. @@ -44,36 +44,4 @@ The following diagram illustrates a process involving the interaction between an ![Reactive Network Lifecycle](./img/global-processing-flow.png) -### Step-by-step Description - -**New Block in Origin Chain**: The process starts when a new block is created on the Origin Chain. This block contains multiple transactions. - -**Catch Block in Reactive Network**: The Reactive Network catches the newly created block from the Origin Chain. - -**Iterate Transactions**: The system iterates through all the transactions in the newly caught block. - -**Extract Transaction Logs**: Transaction logs are extracted from each transaction. - -**Find Transactions at System SC**: The system identifies specific transactions that need to be processed by the System Smart Contract (System SC). - -**Prepare Transaction and Publish to RVM**: The identified transactions are prepared and published to the ReactVM for further processing. - -**ReactVM Processing**: - -       **ReactVM Exists?**: The system checks if a ReactVM already exists. - -       **No**: If no ReactVM exists, the system sets up a new ReactVM. - -       **Run ReactVM**: The ReactVM is run to process the transaction. - -       **Execute Transaction**: The transaction is executed within the ReactVM. - -       **Stop ReactVM**: After executing the transaction, the ReactVM is stopped. - -**Transaction Receipt**: After the ReactVM completes processing the transaction, a transaction receipt is generated. - -**Prepare Transaction for Destination Chain**: Based on the transaction receipt, a new transaction is prepared for the Destination Chain. - -**Transaction at Mem. Pool in Destination Chain**: The prepared transaction is placed in the memory pool of the Destination Chain, ready to be included in a new block on that chain. - [More on ReactVM →](../education/module-1/react-vm.md) diff --git a/docs/docs/rnk-rpc-methods.md b/docs/docs/rnk-rpc-methods.md index b4becb9..3589640 100644 --- a/docs/docs/rnk-rpc-methods.md +++ b/docs/docs/rnk-rpc-methods.md @@ -624,7 +624,7 @@ Retrieves the bytecode of a deployed contract at a specific transaction or block #### Parameters 1. **rvmId**: `DATA`, 20 bytes — The unique identifier of the RVM. -2. **contract** `DATA`, 20 bytes — The address of the smart contract. +2. **contract** `DATA`, 20 bytes — The Reactive contract address. 3. **txNumberOrHash** `HEX | TAG` — Specifies the state at which the contract code is retrieved. Accepts either a block number (`HEX`) or a tag (`"latest"`, `"earliest"`, `"pending"`). #### cURL @@ -703,7 +703,7 @@ Returns the storage value: ## rnk_call -Performs a read-only simulation of a smart contract function call on a given RVM, without creating a transaction. +Performs a read-only simulation of a Reactive contract function call on a given RVM, without creating a transaction. #### Parameters diff --git a/docs/docs/subscriptions.md b/docs/docs/subscriptions.md index d6fab26..8be0fac 100644 --- a/docs/docs/subscriptions.md +++ b/docs/docs/subscriptions.md @@ -1,7 +1,7 @@ --- title: Subscriptions sidebar_position: 10 -description: Explore how to subscribe to events via Reactive Smart Contracts, allowing for event-driven interactions and transaction creation. +description: Explore how to subscribe to events via Reactive Contracts, allowing for event-driven interactions and transaction creation. slug: /subscriptions hide_title: true --- diff --git a/docs/education/glossary.md b/docs/education/glossary.md index f7ace0b..c899b5b 100644 --- a/docs/education/glossary.md +++ b/docs/education/glossary.md @@ -10,352 +10,242 @@ hide_title: true ## A -**Airdrop** – the distribution of free tokens or cryptocurrencies to wallet addresses, often used by blockchain projects -as a marketing strategy to raise awareness, incentivize participation, or reward existing token holders. Eligibility -typically requires meeting specific criteria like owning a cryptocurrency or belonging to a specific community. +**Airdrop** – the distribution of free tokens or cryptocurrencies to wallet addresses, often used by blockchain projects as a marketing strategy to raise awareness, incentivize participation, or reward existing token holders. Eligibility typically requires meeting specific criteria like owning a cryptocurrency or belonging to a specific community. -**APY (Annual Percentage Yield)** – the annual rate of return on investment, accounting for compound interest, commonly -used in decentralized finance (DeFi) and blockchain-based financial products for calculating and comparing potential -returns. +**APY (Annual Percentage Yield)** – the annual rate of return on investment, accounting for compound interest, commonly used in decentralized finance (DeFi) and blockchain-based financial products for calculating and comparing potential returns. -**Arbitrary Logic** – the implementation of customized rules or conditions within a blockchain smart contract or protocol, -allowing for flexible functionalities beyond standardized operations. +**Arbitrary Logic** – the implementation of customized rules or conditions within a blockchain smart contract or protocol, allowing for flexible functionalities beyond standardized operations. -**ASIC (Application-Specific Integrated Circuit)** – a specialized hardware device designed specifically for mining cryptocurrencies, -offering higher efficiency compared to general-purpose computing devices. +**ASIC (Application-Specific Integrated Circuit)** – a specialized hardware device designed specifically for mining cryptocurrencies, offering higher efficiency compared to general-purpose computing devices. -**Atomic Swap** – a smart contract technology that enables the exchange of one cryptocurrency for another without the need -for a trusted third party or centralized exchange. +**Atomic Swap** – a smart contract technology that enables the exchange of one cryptocurrency for another without the need for a trusted third party or centralized exchange. -**Atomicity** – a property of blockchain transactions that ensures they are indivisible and irreducible, meaning that either -all parts of a transaction are executed, or none are. +**Atomicity** – a property of blockchain transactions that ensures they are indivisible and irreducible, meaning that either all parts of a transaction are executed, or none are. -**Auto-Compounding** – a feature in decentralized finance (DeFi) protocols that automatically reinvests earned yields or -rewards back into the original investment, increasing the overall value and compounding returns over time without -requiring manual intervention from users. +**Auto-Compounding** – a feature in decentralized finance (DeFi) protocols that automatically reinvests earned yields or rewards back into the original investment, increasing the overall value and compounding returns over time without requiring manual intervention from users. -**AMMs (Automated Market Makers)** – algorithmic protocols within decentralized exchanges (DEXs) that determine asset prices -using liquidity pools, enabling direct trading without traditional order books. +**AMMs (Automated Market Makers)** – algorithmic protocols within decentralized exchanges (DEXs) that determine asset prices using liquidity pools, enabling direct trading without traditional order books. ## B -**Beacon Chain** – a central chain in the Ethereum 2.0 upgrade that coordinates the network, manages validators, and facilitates -communication between shards. +**Beacon Chain** – a central chain in the Ethereum 2.0 upgrade that coordinates the network, manages validators, and facilitates communication between shards. -**Block Reward** – the incentive given to a miner for successfully hashing a new block and adding it to the blockchain. The reward -typically consists of newly minted cryptocurrency and transaction fees. +**Block Reward** – the incentive given to a miner for successfully hashing a new block and adding it to the blockchain. The reward typically consists of newly minted cryptocurrency and transaction fees. -**Bridging** – the process of enabling interoperability and transferring assets or data between different blockchain networks -or protocols. +**Bridging** – the process of enabling interoperability and transferring assets or data between different blockchain networks or protocols. -**Burning (Token Burn)** – the process of permanently removing a certain amount of cryptocurrency tokens from circulation, -reducing the total supply, often used to increase scarcity and potentially boost value. +**Burning (Token Burn)** – the process of permanently removing a certain amount of cryptocurrency tokens from circulation, reducing the total supply, often used to increase scarcity and potentially boost value. ## C -**Centralized Point of Control** – a single entity or system within a network that holds authority and decision-making power -over critical functions, data, or resources, contrasting with decentralized models where control is distributed among multiple -participants. +**Centralized Point of Control** – a single entity or system within a network that holds authority and decision-making power over critical functions, data, or resources, contrasting with decentralized models where control is distributed among multiple participants. -**Chainlink Automation** – automating data input/output between blockchain smart contracts and external systems using Chainlink's -decentralized oracle network. +**Chainlink Automation** – automating data input/output between blockchain smart contracts and external systems using Chainlink's decentralized oracle network. -**Cold Wallet** – a cryptocurrency wallet that is not connected to the internet, providing a higher level of security against online -threats. +**Cold Wallet** – a cryptocurrency wallet that is not connected to the internet, providing a higher level of security against online threats. -**Consensus Algorithm** – the protocol through which blockchain network participants agree on the state of the ledger, ensuring -that all copies of the distributed ledger are the same. Common types include Proof of Work (PoW), Proof of Stake (PoS), Practical -Byzantine Fault Tolerance (PBFT), and Proof of Authority (PoA). +**Consensus Algorithm** – the protocol through which blockchain network participants agree on the state of the ledger, ensuring that all copies of the distributed ledger are the same. Common types include Proof of Work (PoW), Proof of Stake (PoS), Practical Byzantine Fault Tolerance (PBFT), and Proof of Authority (PoA). **Cross-Chain Copy Trading** – automatically mirroring trades across multiple blockchain networks without manual intervention. -**Cross-Chain Ownership** – the ability to possess and manage assets that exist on multiple blockchain networks simultaneously, -enabling transfer and utilization across different decentralized ecosystems. +**Cross-Chain Ownership** – the ability to possess and manage assets that exist on multiple blockchain networks simultaneously, enabling transfer and utilization across different decentralized ecosystems. -**Custodial Wallet** – a type of cryptocurrency wallet where a third party holds and manages the private keys on behalf of -the user, offering convenience at the expense of direct control. +**Custodial Wallet** – a type of cryptocurrency wallet where a third party holds and manages the private keys on behalf of the user, offering convenience at the expense of direct control. ## D -**DAO Governance** – the process of decision-making and management within a Decentralized Autonomous Organization, where -stakeholders participate in voting and consensus mechanisms to determine the direction, policies, and actions of the organization -without centralized control. +**DAO Governance** – the process of decision-making and management within a Decentralized Autonomous Organization, where stakeholders participate in voting and consensus mechanisms to determine the direction, policies, and actions of the organization without centralized control. -**dApp (Decentralized Application)** – an application built on a decentralized network that combines a smart contract and -a front-end user interface, operating without centralized control. +**dApp (Decentralized Application)** – an application built on a decentralized network that combines a smart contract and a front-end user interface, operating without centralized control. -**DeFi (Decentralized Finance)** – a financial system built on blockchain technology that aims to recreate traditional financial -services in a decentralized manner, allowing for peer-to-peer transactions, lending, borrowing, and trading without intermediaries. +**DeFi (Decentralized Finance)** – a financial system built on blockchain technology that aims to recreate traditional financial services in a decentralized manner, allowing for peer-to-peer transactions, lending, borrowing, and trading without intermediaries. -**Delegated Proof of Stake (DPoS)** – a consensus algorithm where stakeholders vote for a small group of delegates to validate -transactions and maintain the blockchain. +**Delegated Proof of Stake (DPoS)** – a consensus algorithm where stakeholders vote for a small group of delegates to validate transactions and maintain the blockchain. **Destination Chain** - a designated ecosystem where the state transition (transaction) occurs. -**DEX Swaps** – peer-to-peer transactions of digital assets directly between users on Decentralized Exchange platforms, eliminating -the need for intermediaries and providing greater control over trades and liquidity. +**DEX Swaps** – peer-to-peer transactions of digital assets directly between users on Decentralized Exchange platforms, eliminating the need for intermediaries and providing greater control over trades and liquidity. -**Distribution Fee** – a charge imposed on the transfer or allocation of tokens or assets within a blockchain network, typically -collected to cover transaction processing costs or to fund network development and maintenance. +**Distribution Fee** – a charge imposed on the transfer or allocation of tokens or assets within a blockchain network, typically collected to cover transaction processing costs or to fund network development and maintenance. -**Dummy Smart Contract** – a simplified or placeholder smart contract used for testing, demonstration, or educational purposes, -typically containing basic functionalities and data structures to simulate interactions within a blockchain network without -executing complex operations or real-world transactions. +**Dummy Smart Contract** – a simplified or placeholder smart contract used for testing, demonstration, or educational purposes, typically containing basic functionalities and data structures to simulate interactions within a blockchain network without executing complex operations or real-world transactions. -**Dust Transactions** – very small cryptocurrency transactions that are often considered spam due to their negligible value and -potential to clog the network. +**Dust Transactions** – very small cryptocurrency transactions that are often considered spam due to their negligible value and potential to clog the network. ## E -**Elliptic Curve Cryptography (ECC)** – a type of public key cryptography based on the algebraic structure of elliptic curves, -used in blockchain for securing transactions and generating addresses. +**Elliptic Curve Cryptography (ECC)** – a type of public key cryptography based on the algebraic structure of elliptic curves, used in blockchain for securing transactions and generating addresses. -**Emitting Events** – the process of triggering and broadcasting specific occurrences or actions within a smart contract on -a blockchain network. +**Emitting Events** – the process of triggering and broadcasting specific occurrences or actions within a smart contract on a blockchain network. -**EOA (Externally Owned Account)** – a type of account on the Ethereum blockchain that is controlled by private keys held by -individuals or entities outside the blockchain. EOAs are used for sending transactions, deploying smart contracts, and -managing funds. +**EOA (Externally Owned Account)** – a type of account on the Ethereum blockchain that is controlled by private keys held by individuals or entities outside the blockchain. EOAs are used for sending transactions, deploying smart contracts, and managing funds. -**ERC-20** – a standard for creating and issuing smart contracts on the Ethereum blockchain, specifically for tokens that can -interact with each other seamlessly. +**ERC-20** – a standard for creating and issuing smart contracts on the Ethereum blockchain, specifically for tokens that can interact with each other. -**ERC-721** – a standard for non-fungible tokens (NFTs) on the Ethereum blockchain, allowing the creation and transfer of unique -digital assets. +**ERC-721** – a standard for non-fungible tokens (NFTs) on the Ethereum blockchain, allowing the creation and transfer of unique digital assets. -**Event Sources** - the various origins from which events, such as transactions, smart contract executions, or external data inputs, -are generated within the blockchain ecosystem. +**Event Sources** - the various origins from which events, such as transactions, smart contract executions, or external data inputs, are generated within the blockchain ecosystem. -**EVM Events** – events generated within the Ethereum Virtual Machine when specific conditions are met, typically used to -notify external applications or contracts about state changes or transactions occurring within Ethereum smart contracts. +**EVM Events** – events generated within the Ethereum Virtual Machine when specific conditions are met, typically used to notify external applications or contracts about state changes or transactions occurring within Ethereum smart contracts. -**External Prompt** – an input or trigger from an external source, such as a user or another system, that initiates an action -or process within a blockchain application or smart contract. +**External Prompt** – an input or trigger from an external source, such as a user or another system, that initiates an action or process within a blockchain application or smart contract. ## F -**Fiat Gateway** – a service or platform that enables the conversion between fiat currency and cryptocurrency, allowing users -to buy or sell cryptocurrencies using traditional money. +**Fiat Gateway** – a service or platform that enables the conversion between fiat currency and cryptocurrency, allowing users to buy or sell cryptocurrencies using traditional money. -**Flash Loan** – a type of uncollateralized loan in DeFi that allows borrowers to borrow funds within a single transaction -block without providing collateral, commonly used for arbitrage and trading strategies. +**Flash Loan** – a type of uncollateralized loan in DeFi that allows borrowers to borrow funds within a single transaction block without providing collateral, commonly used for arbitrage and trading strategies. -**Fork** – a change to the protocol of a blockchain network that results in a divergence into two separate paths. A **soft fork** -is backward compatible, while a **hard fork** creates a new blockchain incompatible with the old version. +**Fork** – a change to the protocol of a blockchain network that results in a divergence into two separate paths. A **soft fork** is backward compatible, while a **hard fork** creates a new blockchain incompatible with the old version. -**Front-Running** – the unethical practice where an entity with insider knowledge of a pending transaction executes a similar -transaction ahead of it to profit from the expected price movement. +**Front-Running** – the unethical practice where an entity with insider knowledge of a pending transaction executes a similar transaction ahead of it to profit from the expected price movement. -**Fungibility** – the property of an asset whose individual units are interchangeable and indistinguishable from one another, -such as traditional currencies or cryptocurrencies like Bitcoin. +**Fungibility** – the property of an asset whose individual units are interchangeable and indistinguishable from one another, such as traditional currencies or cryptocurrencies like Bitcoin. ## G -**Gas** – a unit of measure for computational work required to execute operations on the Ethereum network, with associated -fees paid in Ether (ETH). +**Gas** – a unit of measure for computational work required to execute operations on the Ethereum network, with associated fees paid in Ether (ETH). -**Gauge Voting** – a governance mechanism in DeFi protocols where token holders vote to influence parameters or decisions -related to liquidity pools, yield farming rewards, or other protocol functionalities. +**Gauge Voting** – a governance mechanism in DeFi protocols where token holders vote to influence parameters or decisions related to liquidity pools, yield farming rewards, or other protocol functionalities. **Genesis Block** – the first block in a blockchain, serving as the foundation upon which all subsequent blocks are added. ## H -**Halving** – an event in which the reward for mining new blocks is halved, reducing the rate at which new coins are generated. -This is typically programmed to occur at regular intervals in certain cryptocurrencies like Bitcoin. +**Halving** – an event in which the reward for mining new blocks is halved, reducing the rate at which new coins are generated. This is typically programmed to occur at regular intervals in certain cryptocurrencies like Bitcoin. -**Hash** – the output of a hash function, which takes an input and produces a fixed-size string of characters. Used in blockchain -to secure data through encryption. +**Hash** – the output of a hash function, which takes an input and produces a fixed-size string of characters. Used in blockchain to secure data through encryption. -**Hash Rate** – the measure of computational power used in cryptocurrency mining, representing the number of hash operations -performed per second. +**Hash Rate** – the measure of computational power used in cryptocurrency mining, representing the number of hash operations performed per second. -**Hot Wallet** – a cryptocurrency wallet that is connected to the internet, providing easy access for transactions but with -increased vulnerability to cyberattacks. +**Hot Wallet** – a cryptocurrency wallet that is connected to the internet, providing easy access for transactions but with increased vulnerability to cyberattacks. ## I -**Initial Coin Offering (ICO)** – a fundraising method in which a new cryptocurrency project sells tokens to early backers -in exchange for established cryptocurrencies like Bitcoin or Ether. +**Initial Coin Offering (ICO)** – a fundraising method in which a new cryptocurrency project sells tokens to early backers in exchange for established cryptocurrencies like Bitcoin or Ether. **Interoperability** – the ability of different blockchain networks to interact and exchange information or assets with one another. -**Inversion-of-Control** – a programming principle of Reactive Smart Contracts, where control over execution flow is shifted -from external actors to the system itself, allowing autonomous decision-making based on predefined events. +**Inversion-of-Control** – a programming principle of Reactive Contracts, where control over execution flow is shifted from external actors to the system itself, allowing autonomous decision-making based on predefined events. -**Immutable** – a characteristic of blockchain data that prevents it from being altered or deleted once recorded, ensuring -the integrity and permanence of the information. - -## J - -**JOMO (Joy of Missing Out)** – a positive sentiment in the crypto community where individuals are content with not participating -in the hype or speculative investments, focusing instead on informed and strategic decisions. +**Immutable** – a characteristic of blockchain data that prevents it from being altered or deleted once recorded, ensuring the integrity and permanence of the information. ## K -**Keypair** – a pair of cryptographic keys (private and public) used in blockchain transactions. The private key signs transactions, -while the public key verifies them. +**Keypair** – a pair of cryptographic keys (private and public) used in blockchain transactions. The private key signs transactions, while the public key verifies them. -**KYC (Know Your Customer)** – a regulatory requirement for financial services to verify the identity of their clients, -commonly implemented in crypto exchanges to comply with anti-money laundering (AML) regulations. +**KYC (Know Your Customer)** – a regulatory requirement for financial services to verify the identity of their clients, commonly implemented in crypto exchanges to comply with anti-money laundering (AML) regulations. ## L -**L1 (Layer One)** – the primary blockchain layer responsible for executing and validating transactions, typically featuring -its consensus mechanism and native token. +**L1 (Layer One)** – the primary blockchain layer responsible for executing and validating transactions, typically featuring its consensus mechanism and native token. -**L2 (Layer Two)** – secondary frameworks or protocols built on top of an existing blockchain (Layer One) to improve scalability -and speed without altering the base layer's structure. +**L2 (Layer Two)** – secondary frameworks or protocols built on top of an existing blockchain (Layer One) to improve scalability and speed without altering the base layer's structure. -**LayerZero** – an interoperability protocol that connects blockchains, allowing developers to build cross-chain applications, -tokens, and experiences. +**LayerZero** – an interoperability protocol that connects blockchains, allowing developers to build cross-chain applications, tokens, and experiences. -**Lightning Network** – a second-layer solution built on top of a blockchain (such as Bitcoin) that enables fast, low-cost -transactions through off-chain payment channels. +**Lightning Network** – a second-layer solution built on top of a blockchain (such as Bitcoin) that enables fast, low-cost transactions through off-chain payment channels. -**Liquidation Protection** – safeguards implemented within DeFi protocols to mitigate the risk of user positions being -liquidated due to falling asset prices or insufficient collateral. +**Liquidation Protection** – safeguards implemented within DeFi protocols to mitigate the risk of user positions being liquidated due to falling asset prices or insufficient collateral. -**Liquidity Pools** – pools of funds provided by users in DeFi platforms, used to facilitate trading and lending by providing -liquidity to the market. +**Liquidity Pools** – pools of funds provided by users in DeFi platforms, used to facilitate trading and lending by providing liquidity to the market. -**Liquidity Pools Rebalancing** – the process of adjusting the allocation of assets within liquidity pools in DeFi platforms -to maintain optimal liquidity and minimize risks associated with price fluctuations. +**Liquidity Pools Rebalancing** – the process of adjusting the allocation of assets within liquidity pools in DeFi platforms to maintain optimal liquidity and minimize risks associated with price fluctuations. ## M -**Merkle Root** – the top hash of a Merkle tree, summarizing all transactions in a block. It ensures data integrity -and quick verification. +**Merkle Root** – the top hash of a Merkle tree, summarizing all transactions in a block. It ensures data integrity and quick verification. -**Merkle Tree** – a data structure used in blockchain technology to efficiently and securely verify the integrity of data. -It is a binary tree where each leaf node is a hash of a data block, and each non-leaf node is a hash of its children. +**Merkle Tree** – a data structure used in blockchain technology to efficiently and securely verify the integrity of data. It is a binary tree where each leaf node is a hash of a data block, and each non-leaf node is a hash of its children. -**Micropayments** – very small transactions facilitated by blockchain technology, often used for tipping, content monetization, -or microservices. +**Micropayments** – very small transactions facilitated by blockchain technology, often used for tipping, content monetization, or microservices. -**Multisig Protocol** – a blockchain protocol that allows multiple parties to jointly control funds or assets by requiring -the authorization of a predefined number of signatories before a transaction can be executed. +**Multisig Protocol** – a blockchain protocol that allows multiple parties to jointly control funds or assets by requiring the authorization of a predefined number of signatories before a transaction can be executed. ## N -**Node** – a computer that participates in a blockchain network by validating and relaying transactions and maintaining -a copy of the entire blockchain ledger. +**Node** – a computer that participates in a blockchain network by validating and relaying transactions and maintaining a copy of the entire blockchain ledger. -**Nonce** – a random or pseudo-random number used in cryptographic communication to ensure that old communications cannot -be reused in replay attacks. In mining, it's the value miners adjust to find a valid hash. +**Nonce** – a random or pseudo-random number used in cryptographic communication to ensure that old communications can't be reused in replay attacks. In mining, it's the value miners adjust to find a valid hash. ## O -**Oracles** – trusted third-party services or decentralized networks that provide external data to smart contracts on -blockchain platforms, enabling the execution of conditional actions based on real-world events or information. +**Oracles** – trusted third-party services or decentralized networks that provide external data to smart contracts on blockchain platforms, enabling the execution of conditional actions based on real-world events or information. -**Origin Chain** - an event log provider facilitating the processing and delivery of events to Reactive Smart Contracts. +**Origin Chain** - an event log provider facilitating the processing and delivery of events to Reactive Contracts. ## P -**Proof of Authority (PoA)** – a consensus algorithm that relies on a small number of trusted nodes with known identities -to validate transactions and create new blocks, offering high performance and scalability. +**Proof of Authority (PoA)** – a consensus algorithm that relies on a small number of trusted nodes with known identities to validate transactions and create new blocks, offering high performance and scalability. -**Proof of Stake (PoS)** – a consensus mechanism where validators are chosen to create new blocks and confirm transactions -based on the amount of cryptocurrency they hold and are willing to "stake" as collateral. +**Proof of Stake (PoS)** – a consensus mechanism where validators are chosen to create new blocks and confirm transactions based on the amount of cryptocurrency they hold and are willing to "stake" as collateral. -**Public Key Infrastructure (PKI)** – a framework for managing public key encryption, including the creation, distribution, -and verification of digital certificates. +**Public Key Infrastructure (PKI)** – a framework for managing public key encryption, including the creation, distribution, and verification of digital certificates. ## Q -**Quantum Computing** – an emerging field of computing with the potential to solve complex problems much faster than classical -computers, posing both opportunities and threats to current cryptographic methods used in blockchain. +**Quantum Computing** – an emerging field of computing with the potential to solve complex problems much faster than classical computers, posing both opportunities and threats to current cryptographic methods used in blockchain. ## R -**ReactVM** – a specialized EVM within the Reactive Network for executing Reactive Smart Contracts, allowing transactions to -run in random order across multiple threads while maintaining transaction order for each ReactVM. - -**Reactive Network** – a blockchain layer supporting Reactive Smart Contracts, where data-driven execution replaces user input, -allowing conditional state changes across blockchains and efficient computation through parallelized EVM implementation -using event streams from the Relayer Network. +**ReactVM** – a specialized EVM within the Reactive Network for executing Reactive Contracts, allowing transactions to run in random order across multiple threads while maintaining transaction order for each ReactVM. -**Reactive Smart Contract** – a type of contract that autonomously monitors and responds to events on EVM-compatible chains, -enabling decentralized automation without external prompts while extending the operational efficiency of a traditional -smart contract. +**Reactive Network** – a blockchain layer supporting Reactive Contracts, where data-driven execution replaces user input, allowing conditional state changes across blockchains and efficient computation through parallelized EVM implementation using event streams. -**Reactivity** – the ability of Reactive Smart Contracts to autonomously respond to data flows, allowing conditional state -changes and efficient cross-chain computation without relying on user input. +**Reactive Contract** – a type of contract that autonomously monitors and responds to events on EVM-compatible chains, enabling decentralized automation without external prompts. -**Relayer Network** – a decentralized system responsible for the transmission of event streams between different blockchain -ecosystems, enabling Reactive Smart Contracts to execute based on data from other chains. +**Reactivity** – the ability of Reactive Contracts to autonomously respond to data flows, allowing conditional state changes and efficient cross-chain computation without relying on user input. -**Rollups** – a layer two scaling solution that aggregates multiple transactions into a single batch for more efficient -processing on the main blockchain, reducing fees and improving throughput. +**Rollups** – a layer two scaling solution that aggregates multiple transactions into a single batch for more efficient processing on the main blockchain, reducing fees and improving throughput. ## S -**Self-Rebalancing Liquidity Pools** – liquidity pools in DeFi platforms that automatically adjust their asset allocations to -maintain equilibrium and optimize liquidity without requiring manual intervention from users. +**Self-Rebalancing Liquidity Pools** – liquidity pools in DeFi platforms that automatically adjust their asset allocations to maintain equilibrium and optimize liquidity without requiring manual intervention from users. -**Shard** – a smaller partition of a blockchain network that allows for parallel processing of transactions, improving -scalability and throughput. +**Shard** – a smaller partition of a blockchain network that allows for parallel processing of transactions, improving scalability and throughput. -**Sharding** – a scalability method that divides a blockchain into smaller, more manageable pieces (shards) that can process -transactions simultaneously. +**Sharding** – a scalability method that divides a blockchain into smaller, more manageable pieces (shards) that can process transactions simultaneously. -**Sidechain** – a separate blockchain that runs in parallel to a main blockchain, allowing for the transfer of assets between -chains and enabling more complex functionality without congesting the main chain. +**Sidechain** – a separate blockchain that runs in parallel to a main blockchain, allowing for the transfer of assets between chains and enabling more complex functionality without congesting the main chain. -**Soft Fork** – a backward-compatible update to a blockchain protocol that allows for more stringent rules without splitting -the blockchain into two separate networks. +**Soft Fork** – a backward-compatible update to a blockchain protocol that allows for more stringent rules without splitting the blockchain into two separate networks. -**Stateful** – describes a system, protocol, or smart contract on a blockchain that maintains and updates its internal state -over time, typically recording changes in data or conditions. +**Stateful** – describes a system, protocol, or smart contract on a blockchain that maintains and updates its internal state over time, typically recording changes in data or conditions. -**Stop Order** – a trade order automatically executed when an asset's price hits a specified level, commonly used for risk -management in trading. +**Stop Order** – a trade order automatically executed when an asset's price hits a specified level, commonly used for risk management in trading. -**Stop Price** – the predefined price level at which a stop order is triggered, initiating the execution of a trade to buy or -sell an asset. +**Stop Price** – the predefined price level at which a stop order is triggered, initiating the execution of a trade to buy or sell an asset. ## T -**Tokenomics** – the study and design of the economic systems and models surrounding a cryptocurrency token, including its creation, -distribution, and utility. +**Tokenomics** – the study and design of the economic systems and models surrounding a cryptocurrency token, including its creation, distribution, and utility. -**Trading Pools** – pooled funds in DeFi platforms used for trading assets, providing liquidity, and facilitating decentralized -exchange transactions. +**Trading Pools** – pooled funds in DeFi platforms used for trading assets, providing liquidity, and facilitating decentralized exchange transactions. -**Trustlessness** – the property of a blockchain system where participants can interact and transact without needing to trust -intermediaries or counterparties. +**Trustlessness** – the property of a blockchain system where participants can interact and transact without needing to trust intermediaries or counterparties. ## U -**Uniswap** – a popular decentralized exchange protocol on Ethereum that uses automated market making (AMM) to facilitate trading -without the need for a traditional order book. +**Uniswap** – a popular decentralized exchange protocol on Ethereum that uses automated market making (AMM) to facilitate trading without the need for a traditional order book. ## V -**Validator** – a participant in a blockchain network that verifies and confirms transactions, often through staking cryptocurrency -in Proof of Stake systems. +**Validator** – a participant in a blockchain network that verifies and confirms transactions, often through staking cryptocurrency in Proof of Stake systems. -**Vanity Address** – a cryptocurrency address that includes a recognizable pattern or prefix, typically generated through brute force -or specialized software. +**Vanity Address** – a cryptocurrency address that includes a recognizable pattern or prefix, typically generated through brute force or specialized software. ## W -**Whale Moves** – significant transactions or actions executed by large holders of cryptocurrencies or assets, referred to as -"whales", which can have a notable impact on market prices or sentiment due to their substantial size. +**Whale Moves** – significant transactions or actions executed by large holders of cryptocurrencies or assets, referred to as "whales", which can have a notable impact on market prices or sentiment due to their substantial size. -**Wrapped Tokens** – tokens that represent another cryptocurrency on a different blockchain, allowing for interoperability and -use in DeFi applications (e.g., Wrapped Bitcoin (WBTC) on Ethereum). +**Wrapped Tokens** – tokens that represent another cryptocurrency on a different blockchain, allowing for interoperability and use in DeFi applications (e.g., Wrapped Bitcoin (WBTC) on Ethereum). ## Y -**Yield Farming** – a DeFi strategy where users use their assets by providing liquidity to protocols in exchange for rewards, -typically in the form of additional tokens or a share of transaction fees. +**Yield Farming** – a DeFi strategy where users use their assets by providing liquidity to protocols in exchange for rewards, typically in the form of additional tokens or a share of transaction fees. ## Z -**Zero-Knowledge Proof (ZKP)** – a cryptographic method that allows one party to prove to another that a statement is true without -revealing any additional information. Commonly used for enhancing privacy and security in blockchain transactions. +**Zero-Knowledge Proof (ZKP)** – a cryptographic method that allows one party to prove to another that a statement is true without revealing any additional information. Commonly used for enhancing privacy and security in blockchain transactions. -**zk-SNARKs** (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) – a type of zero-knowledge proof that enables one party -to prove possession of certain information without revealing the information itself or requiring interaction between prover and verifier. \ No newline at end of file +**zk-SNARKs** (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) – a type of zero-knowledge proof that enables one party to prove possession of certain information without revealing the information itself or requiring interaction between prover and verifier. \ No newline at end of file diff --git a/docs/education/introduction/index.md b/docs/education/introduction/index.md index 96aea4e..48ea3f0 100644 --- a/docs/education/introduction/index.md +++ b/docs/education/introduction/index.md @@ -1,7 +1,7 @@ --- sidebar_position: 1 title: Introduction -description: Embark on a journey through Reactive Smart Contracts with our educational program. Dive into lectures, GitHub code, and video demos for a hands-on learning experience. +description: Embark on a journey through Reactive Contracts with our educational program. Dive into lectures, GitHub code, and video demos for a hands-on learning experience. slug: /education/introduction hide_title: true --- @@ -10,21 +10,21 @@ hide_title: true ## Overview -To better understand the concept of Reactive Smart Contracts (RSCs), we have developed an educational course featuring detailed lectures, code snippets on [GitHub](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos), and video workshops on [YouTube](https://www.youtube.com/@0xReactive/streams). Our goal is to provide both theoretical knowledge and practical challenges, creating a community where developers can fully explore RSCs. +To better understand the concept of Reactive Contracts (RCs), we have developed an educational course featuring detailed lectures, code snippets on [GitHub](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos), and video workshops on [YouTube](https://www.youtube.com/@0xReactive/streams). Our goal is to provide both theoretical knowledge and practical challenges, creating a community where developers can fully explore RCs. ## Where to Begin -The Introduction chapter provides an overview of Reactive Smart Contracts, highlighting their ability to autonomously react to events on EVM-compatible chains. It also outlines the technical and knowledge prerequisites necessary for mastering these concepts. +The Introduction chapter provides an overview of Reactive Contracts, highlighting their ability to autonomously react to events on EVM-compatible chains. It also outlines the technical and knowledge prerequisites necessary for mastering these concepts. -[Introduction to Reactive Smart Contracts →](./reactive-smart-contracts.md) +[Introduction to Reactive Contracts →](./reactive-contracts.md) [Prerequisites →](./prerequisites.md) ## Module One -[Module 1](../module-1/index.md) is dedicated to the basics of Reactive Smart Contracts, events and callbacks, the ReactVM and Reactive Network environments, subscriptions, and the function of oracles in integrating off-chain data. +[Module 1](../module-1/index.md) is dedicated to the basics of Reactive Contracts, events and callbacks, the ReactVM and Reactive Network environments, subscriptions, and the function of oracles in integrating off-chain data. -[Reactive Smart Contracts →](../module-1/reactive-smart-contracts.md) +[Reactive Contracts →](../module-1/reactive-contracts.md) [How Events and Callbacks Work →](../module-1/how-events-work.md) @@ -36,7 +36,7 @@ The Introduction chapter provides an overview of Reactive Smart Contracts, highl ## Module Two -[Module 2](../module-2/index.md) explores Uniswap V2, focusing on liquidity pools and smart contract operations. It also elaborates on the basic functions of Reactive Smart Contracts that enable autonomous execution. +[Module 2](../module-2/index.md) explores Uniswap V2, focusing on liquidity pools and smart contract operations. It also elaborates on the basic functions of Reactive Contracts that enable autonomous execution. [How Uniswap Works →](../module-2/how-uniswap-works.md) @@ -44,13 +44,13 @@ The Introduction chapter provides an overview of Reactive Smart Contracts, highl ## Use Cases -The [Use Cases](../use-cases/index.md) section explains scenarios where Reactive Smart Contracts can improve blockchain apps. It includes a basic demo for low-latency log monitoring and interaction across different chains, a guide on deploying RSCs using Remix, and a demonstration of a stop order implementation on a Uniswap V2 liquidity pool. +The [Use Cases](../use-cases/index.md) section explains scenarios where Reactive Contracts can improve blockchain apps. It includes a basic demo for low-latency log monitoring and interaction across different chains, a guide on deploying RCs using Remix, and a demonstration of a stop order implementation on a Uniswap V2 liquidity pool. [Basic Demo →](../use-cases/use-case-1.md) [Uniswap V2 Stop Order Demo →](../use-cases/use-case-3.md) -[Deploying Reactive Smart Contracts with Remix →](../use-cases/remix-ide-demo.mdx) +[Deploying Reactive Contracts with Remix →](../use-cases/remix-ide-demo.mdx) ## Glossary diff --git a/docs/education/introduction/prerequisites.md b/docs/education/introduction/prerequisites.md index 05b7ed5..bd2ba92 100644 --- a/docs/education/introduction/prerequisites.md +++ b/docs/education/introduction/prerequisites.md @@ -1,23 +1,23 @@ --- -title: Technical and Knowledge Prerequisites for Mastering Reactive Smart Contracts +title: Technical and Knowledge Prerequisites for Mastering Reactive Contracts sidebar_position: 2 -description: Learn Reactive Smart Contracts (RSCs) with prerequisites like Solidity, EVM basics, Git, and an Ethereum wallet. +description: Learn Reactive Contracts (RCs) with prerequisites like Solidity, EVM basics, Git, and an Ethereum wallet. slug: prerequisites --- -# Technical and Knowledge Prerequisites for Mastering Reactive Smart Contracts +# Technical and Knowledge Prerequisites for Mastering Reactive Contracts ## Overview -Before embarking on your journey, it's crucial to have a solid foundation in several key areas. These prerequisites will ensure you can fully grasp the concepts and practical applications of Reactive Smart Contracts (RSCs). +Before embarking on your journey, it's crucial to have a solid foundation in several key areas. These prerequisites will ensure you can fully grasp the concepts and practical applications of Reactive Contracts (RCs). ## What You Need to Know for This Course -In this course, we aim to equip you with everything you need to grasp the basic use cases of Reactive Smart Contracts, including deploying and interacting with them. While we intend to cover all critical information, a foundational understanding of Ethereum Smart Contracts will greatly improve your learning experience. Below are the prerequisites along with resources to help you get up to speed. +In this course, we aim to equip you with everything you need to grasp the basic use cases of Reactive Contracts, including deploying and interacting with them. While we intend to cover all critical information, a foundational understanding of Ethereum Smart Contracts will greatly improve your learning experience. Below are the prerequisites along with resources to help you get up to speed. ### Solidity and Smart Contract Development -Understanding the syntax and functionalities of Solidity is fundamental. You should be comfortable writing simple smart contracts and familiar with concepts like smart contracts and functions. +Understanding the syntax and functionalities of Solidity is fundamental. You should be comfortable writing simple smart contracts and familiar with their concepts. Educational Resource: [Solidity by Example](https://solidity-by-example.org/) is an excellent place to start, offering hands-on examples to guide you through Solidity's basics to more advanced topics. @@ -41,22 +41,22 @@ Getting Sepolia ETH: Visit the [Sepolia Faucet](https://www.alchemy.com/faucets/ ## What You Don’t Need to Know Beforehand -We recognize that some topics, while not directly related to Reactive Smart Contracts, are essential for a comprehensive understanding of the blockchain landscape. To ensure you have a well-rounded knowledge base, we've included lessons on these broader blockchain concepts and tools. This means you won’t have to look elsewhere to fill in the gaps. +We recognize that some topics, while not directly related to Reactive Contracts, are essential for a comprehensive understanding of the blockchain landscape. To ensure you have a well-rounded knowledge base, we've included lessons on these broader blockchain concepts and tools. This means you won’t have to look elsewhere to fill in the gaps. ### Knowledge of EVM Events -EVM events are a cornerstone for RSCs, serving as triggers for reactive functionalities. An understanding of how events work, how they're logged, and how to interact with them is crucial. +EVM events are a cornerstone for RCs, serving as triggers for reactive functionalities. An understanding of how events work, how they're logged, and how to interact with them is crucial. Educational Resource: Learn about [EVM events](../module-1/how-events-work.md) in detail. ### Decentralized Finance Concepts -Familiarity with DeFi concepts, such as liquidity pools, yield farming, and automated market makers (AMMs), will be helpful, especially for understanding real-world applications of RSCs. +Familiarity with DeFi concepts, such as liquidity pools, yield farming, and automated market makers (AMMs), will be helpful, especially for understanding real-world applications of RCs. Educational Resource: We'll explain some of these concepts in our next articles as we walk you through the corresponding use cases. ## Conclusion -These prerequisites will set you up for success in mastering Reactive Smart Contracts, and fully leveraging their potential in your blockchain projects. Stay tuned for our upcoming article on EVM events that will further solidify your understanding and application of these concepts. +These prerequisites will set you up for success in mastering Reactive Contracts, and fully leveraging their potential in your blockchain projects. Stay tuned for our upcoming article on EVM events that will further solidify your understanding and application of these concepts. Remember, the blockchain space is ever-evolving, so continuous learning is key. These resources are just the beginning; dive deep, experiment, and don't hesitate to engage with the community for insights and assistance. diff --git a/docs/education/introduction/reactive-contracts.md b/docs/education/introduction/reactive-contracts.md new file mode 100644 index 0000000..1e9f26b --- /dev/null +++ b/docs/education/introduction/reactive-contracts.md @@ -0,0 +1,48 @@ +--- +title: "Reactive Contracts: What They Are and Why We Need Them" +sidebar_position: 1 +description: Discover Reactive Contracts (RCs), revolutionizing blockchain interaction with decentralized automation. Join our course to explore their potential, from Uniswap stop orders to NFT synchronization. +slug: reactive-contracts +--- + +# Reactive Contracts: What They Are and Why We Need Them + +## Introduction to Reactive Contracts + +Reactive Contracts (RCs) represent a paradigm shift in how we interact with blockchain technology. Unlike traditional smart contracts that are run by user transactions, RCs actively monitor events on EVM-compatible chains and react to them. They process these events according to the implemented logic and execute further actions on the blockchain autonomously. This innovation introduces a decentralized mechanism for automating responses to on-chain events without manual actions. + +![Basic Reactive Workflow](./img/basic-reactive-workflow.jpg) + +## Why Reactive Contracts + +In the Ethereum world, smart contracts have revolutionized how we conceive of executing trustless agreements. Traditionally, these contracts spring into action only upon a user-initiated transaction. This presents inherent limitations. For one, smart contracts can't autonomously initiate actions or respond to blockchain events without an external prompt — either from a user or an automated script like a trading bot. This requires holding private keys and introducing a centralized point of control. + +Reactive Contracts (RCs) emerge as a solution to this constraint. RCs are designed to autonomously react to events in the Ethereum Virtual Machine (EVM) and trigger subsequent actions across the blockchain ecosystem. This capability for the implementation of complex logic that can source information from multiple chains and enact changes or transactions across various platforms without a central oversight. + +## The Advantages of RCs + +**Decentralization:** RCs operate independently on the blockchain, eliminating centralized points of control and improving security by reducing the risk of manipulation or failure. + +**Automation:** RCs automatically execute smart contract logic in response to on-chain events, reducing the need for manual interventions and allowing for efficient, real-time responses. + +**Cross-Chain Interoperability:** RCs can interact with multiple blockchains, enabling complex cross-chain interactions that enhance versatility and bridge gaps between networks. + +**Enhanced Efficiency and Functionality:** By reacting to real-time data, RCs boost the efficiency of smart contracts, supporting advanced functionalities like complex financial instruments, dynamic NFTs, and innovative DeFi applications. + +**Innovation in DeFi and Beyond:** RCs enable new possibilities in DeFi and other blockchain applications, such as automated trading and dynamic governance, creating a more responsive and interconnected blockchain ecosystem. + +## About This Course + +To equip developers with the skills to harness RCs, we've created a comprehensive course with detailed documentation and hands-on tutorials. Our goal is to foster a collaborative space where developers can explore the full potential of RCs. + +The course offers lectures, GitHub code examples, and video demonstrations for a multi-faceted learning experience. Whether you're interested in theory or practical [use cases](../use-cases/index.md), this course adapts to your needs. + +Throughout the course, we will examine various applications of RCs, including: + +* Implementing Uniswap stop orders through RCs +* Synchronizing NFT ownership over several chains +* Automatically collecting staking rewards from different pools and chains + +## Conclusion + +Reactive Contracts (RCs) represent a major leap in blockchain technology by enabling autonomous execution of complex logic without user intervention. Unlike traditional EVMs, RCs can automatically respond to events from multiple blockchains, allowing for flexible cross-chain interactions. This unique reactivity and versatility make RCs a valuable tool for developers aiming to build more dynamic and interconnected decentralized applications. Join our [Telegram](https://t.me/reactivedevs) group and explore the frontier of blockchain technology, where your creativity and expertise can help shape the future of decentralized applications. diff --git a/docs/education/introduction/reactive-smart-contracts.md b/docs/education/introduction/reactive-smart-contracts.md deleted file mode 100644 index d37faab..0000000 --- a/docs/education/introduction/reactive-smart-contracts.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Reactive Smart Contracts: What They Are and Why We Need Them" -sidebar_position: 1 -description: Discover Reactive Smart Contracts (RSCs), revolutionizing blockchain interaction with decentralized automation. Join our course to explore their potential, from Uniswap stop orders to NFT synchronization. -slug: reactive-smart-contracts ---- - -# Reactive Smart Contracts: What They Are and Why We Need Them - -## Introduction to Reactive Smart Contracts - -Reactive Smart Contracts (RSCs) represent a paradigm shift in how we interact with blockchain technology. Unlike traditional smart contracts that are run by user transactions, RSCs actively monitor events on EVM-compatible chains and react to them. They process these events according to the implemented logic and execute further actions on the blockchain autonomously. This innovation introduces a decentralized mechanism for automating responses to on-chain events without manual actions. - -![Basic Reactive Workflow](./img/basic-reactive-workflow.jpg) - -## Why Reactive Smart Contracts - -In the Ethereum world, smart contracts have revolutionized how we conceive of executing trustless agreements. Traditionally, these contracts spring into action only upon a user-initiated transaction. This presents inherent limitations. For one, smart contracts can't autonomously initiate actions or respond to blockchain events without an external prompt — either from a user or an automated script like a trading bot. This requires holding private keys and introducing a centralized point of control. - -Reactive Smart Contracts (RSCs) emerge as a solution to this constraint. RSCs are designed to autonomously react to events in the Ethereum Virtual Machine (EVM) and trigger subsequent actions across the blockchain ecosystem. This capability for the implementation of complex logic that can source information from multiple chains and enact changes or transactions across various platforms without a central oversight. - -## The Advantages of RSCs - -**Decentralization:** RSCs operate independently on the blockchain, eliminating centralized points of control and improving security by reducing the risk of manipulation or failure. - -**Automation:** RSCs automatically execute smart contract logic in response to on-chain events, reducing the need for manual interventions and allowing for efficient, real-time responses. - -**Cross-Chain Interoperability:** RSCs can interact with multiple blockchains, enabling complex cross-chain interactions that enhance versatility and bridge gaps between networks. - -**Enhanced Efficiency and Functionality:** By reacting to real-time data, RSCs boost the efficiency of smart contracts, supporting advanced functionalities like complex financial instruments, dynamic NFTs, and innovative DeFi applications. - -**Innovation in DeFi and Beyond:** RSCs enable new possibilities in DeFi and other blockchain applications, such as automated trading and dynamic governance, creating a more responsive and interconnected blockchain ecosystem. - -## About This Course - -To equip developers with the skills to harness RSCs, we've created a comprehensive course with detailed documentation and hands-on tutorials. Our goal is to foster a collaborative space where developers can explore the full potential of RSCs. - -The course offers lectures, GitHub code examples, and video demonstrations for a multi-faceted learning experience. Whether you're interested in theory or practical [use cases](../use-cases/index.md), this course adapts to your needs. - -Throughout the course, we will examine various applications of RSCs, including: - -* Implementing Uniswap stop orders through RSCs -* Synchronizing NFT ownership over several chains -* Automatically collecting staking rewards from different pools and chains - -## Conclusion - -Reactive Smart Contracts (RSCs) represent a major leap in blockchain technology by enabling autonomous execution of complex logic without user intervention. Unlike traditional EVMs, RSCs can automatically respond to events from multiple blockchains, allowing for flexible cross-chain interactions. This unique reactivity and versatility make RSCs a valuable tool for developers aiming to build more dynamic and interconnected decentralized applications. Join our [Telegram](https://t.me/reactivedevs) group and explore the frontier of blockchain technology, where your creativity and expertise can help shape the future of decentralized applications. diff --git a/docs/education/module-1/how-events-work.md b/docs/education/module-1/how-events-work.md index e91efbd..e118910 100644 --- a/docs/education/module-1/how-events-work.md +++ b/docs/education/module-1/how-events-work.md @@ -11,13 +11,13 @@ slug: how-events-work In Ethereum, events enable smart contracts to communicate with the external world by logging specific information when certain conditions are met. This allows decentralized applications (dApps) to trigger and respond to occurrences without constantly polling the blockchain. Events are indexed by the EVM, making them easily searchable, which is particularly useful for monitoring blockchain activities like transfers, contract updates, and price changes from oracles. -This lesson focuses on the role of events and callbacks in smart contracts. By learning how to emit, process, and listen to events, developers can create dynamic dApps that respond to blockchain changes in real-time. We will also explore how Reactive Smart Contracts use the `react()` method to handle events and initiate cross-chain transactions through callbacks, enabling improved functionality within the Reactive Network. +This lesson focuses on the role of events and callbacks in smart contracts. By learning how to emit, process, and listen to events, developers can create dynamic dApps that respond to blockchain changes in real-time. We will also explore how Reactive Contracts use the `react()` method to handle events and initiate cross-chain transactions through callbacks, enabling improved functionality within the Reactive Network. By the end of this lesson, you will learn to: * Define and emit events in an Ethereum smart contract. * Listen for and process events using decentralized applications. -* Implement event processing in Reactive Smart Contracts. +* Implement event processing in Reactive Contracts. * Send callbacks to trigger actions on destination chains. ## How EVM Events Work @@ -54,11 +54,11 @@ In this line, `newEthPrice` is the updated price of Ethereum fetched from Chainl ### Listening for the Price Update -A dApp or an investor's portfolio management tool can listen for the `PriceUpdated` event to trigger specific actions such as rebalancing a portfolio or issuing a loan. We will use a Reactive Smart Contract to catch these events in later lessons. +A dApp or an investor's portfolio management tool can listen for the `PriceUpdated` event to trigger specific actions such as rebalancing a portfolio or issuing a loan. We will use a Reactive Contract to catch these events in later lessons. -## Event Processing in Reactive Smart Contracts +## Event Processing in Reactive Contracts -Reactive smart contracts must implement the [`IReactive`](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IReactive.sol) interface to handle incoming events. +Reactive Contracts must implement the [`IReactive`](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IReactive.sol) interface to handle incoming events. ```solidity pragma solidity >=0.8.0; @@ -168,14 +168,14 @@ emit Callback(chain_id, stop_order, CALLBACK_GAS_LIMIT, payload); ## Conclusion -In this lesson, we've explored the fundamentals of events and callbacks in Ethereum and their application in Reactive Smart Contracts. Key takeaways include: +In this lesson, we've explored the fundamentals of events and callbacks in Ethereum and their application in Reactive Contracts. Key takeaways include: - **Understanding Events:** Events allow smart contracts to log information and interact with external applications, providing a powerful way to respond to on-chain activities without directly altering the blockchain state. -- **Reactive Smart Contracts and the react() Method:** RSCs use the `react()` method to autonomously process incoming events based on specified criteria, enabling real-time, decentralized, and responsive contract behavior. +- **Reactive Contracts and the react() Method:** RCs use the `react()` method to autonomously process incoming events based on specified criteria, enabling real-time, decentralized, and responsive contract behavior. -- **Callbacks for Cross-Chain Transactions:** RSCs can initiate actions on different blockchains using callbacks, broadening their functionality beyond single-chain constraints and facilitating more complex decentralized applications. +- **Callbacks for Cross-Chain Transactions:** RCs can initiate actions on different blockchains using callbacks, broadening their functionality beyond single-chain constraints and facilitating more complex decentralized applications. -- **Secure and Controlled Execution:** The ReactVM environment ensures that RSCs operate securely by restricting interactions to contracts deployed by the same deployer, maintaining a controlled execution space. +- **Secure and Controlled Execution:** The ReactVM environment ensures that RCs operate securely by restricting interactions to contracts deployed by the same deployer, maintaining a controlled execution space. -The concepts from this lesson are shown in the [Basic Demo Smart Contract](../use-cases/use-case-1.md) use case. Feel free to explore it and join our [Telegram](https://t.me/reactivedevs) group for additional guidance. +The concepts from this lesson are shown in the [Basic Demo](../use-cases/use-case-1.md) use case. Feel free to explore it and join our [Telegram](https://t.me/reactivedevs) group for additional guidance. diff --git a/docs/education/module-1/how-oracles-work.md b/docs/education/module-1/how-oracles-work.md index 3c41bd6..63e4f15 100644 --- a/docs/education/module-1/how-oracles-work.md +++ b/docs/education/module-1/how-oracles-work.md @@ -1,7 +1,7 @@ --- title: "Lesson 5: How Oracles Work" sidebar_position: 5 -description: Discover the power of oracles in Reactive Smart Contracts (RSCs) and explore their role in integrating real-world data with blockchain applications. +description: Discover the power of oracles in Reactive Contracts (RCs) and explore their role in integrating real-world data with blockchain applications. slug: how-oracles-work --- @@ -9,14 +9,14 @@ slug: how-oracles-work ## Overview -Reactive Smart Contracts are adept at monitoring on-chain events and executing subsequent on-chain actions in response. Yet within the smart contract ecosystem, a distinct category exists specifically for importing off-chain data onto the blockchain. These are known as oracles. Among the myriad events to which Reactive Smart Contracts can respond, those emitted by oracles hold significant importance. This article delves deeper into the concept of oracles, setting the stage for a clearer comprehension of the upcoming use case we'll explore. By unpacking the mechanisms and implications of oracles within the blockchain framework, we aim to equip you with the knowledge needed to fully grasp the potential and utility of Reactive Smart Contracts in interacting with real-world data. +Reactive Contracts are adept at monitoring on-chain events and executing subsequent on-chain actions in response. Yet within the smart contract ecosystem, a distinct category exists specifically for importing off-chain data onto the blockchain. These are known as oracles. Among the myriad events to which Reactive Contracts can respond, those emitted by oracles hold significant importance. This article delves deeper into the concept of oracles, setting the stage for a clearer comprehension of the upcoming use case we'll explore. By unpacking the mechanisms and implications of oracles within the blockchain framework, we aim to equip you with the knowledge needed to fully grasp the potential and utility of Reactive Contracts in interacting with real-world data. By the end of this lesson, you will learn to: * Understand the role of oracles in bridging the gap between blockchain and real-world data. * Address the oracle problem by exploring how oracles bring off-chain data onto the blockchain. * Implement and integrate oracles within smart contracts, using examples like Chainlink to fetch external data. -* Recognize the advantages of combining Reactive Smart Contracts with oracles for real-time interaction with on-chain and off-chain events. +* Recognize the advantages of combining Reactive Contracts with oracles for real-time interaction with on-chain and off-chain events. ## What Oracles Do @@ -84,17 +84,17 @@ This contract demonstrates fetching the latest ETH/USD price using Chainlink's d However, as you may have observed, the smart contract can only request data through the getLatestPrice() function when it's explicitly called. To ensure your contract's data remains current, you should periodically invoke the function that queries the oracle. This challenge isn't insurmountable; one could simply update the price each time someone interacts with the contract, basing this interaction on the most recent price data. Yet this approach falls short of enabling your system to respond to price changes — or other oracle-generated events — in real time. -In the Ethereum ecosystem, while one smart contract can indeed call another, such calls must initially be triggered by an Externally Owned Account (EOA) address. An EOA is an Ethereum address controlled directly by the private key's owner, unlike smart contract addresses, which are governed by contract code. Consequently, each transaction is initiated and signed by a specific EOA, restricting the capacity for smart contracts to operate in real time. This limitation underscores the distinctive advantage of Reactive Smart Contracts. +In the Ethereum ecosystem, while one smart contract can indeed call another, such calls must initially be triggered by an Externally Owned Account (EOA) address. An EOA is an Ethereum address controlled directly by the private key's owner, unlike smart contract addresses, which are governed by contract code. Consequently, each transaction is initiated and signed by a specific EOA, restricting the capacity for smart contracts to operate in real time. This limitation underscores the distinctive advantage of Reactive Contracts. -## Why We Need Reactive Smart Contracts +## Why We Need Reactive Contracts -Our exploration has previously touched upon the Inversion of Control principle, a defining characteristic of Reactive Smart Contracts. Here, it's worth emphasizing again: Reactive Smart Contracts stand out because they react not just to direct user transactions but to events across various EVM chains. Following these events, they execute on-chain actions, potentially on the same or different chains. +Our exploration has previously touched upon the Inversion of Control principle, a defining characteristic of Reactive Contracts. Here, it's worth emphasizing again: Reactive Contracts stand out because they react not just to direct user transactions but to events across various EVM chains. Following these events, they execute on-chain actions, potentially on the same or different chains. -This brings us to the significance of oracles in our discussion: by integrating oracles with Reactive Smart Contracts, we unlock the potential to respond to off-chain events — once brought on-chain by oracles — with predefined on-chain actions as articulated in our Reactive Smart Contracts. This synergy between oracles and Reactive Smart Contracts enables a dynamic, responsive system capable of real-time interaction with both the digital and physical worlds. This broadens the scope and utility of blockchain technology beyond its current constraints. +This brings us to the significance of oracles in our discussion: by integrating oracles with Reactive Contracts, we unlock the potential to respond to off-chain events — once brought on-chain by oracles — with predefined on-chain actions as articulated in our Reactive Contracts. This synergy between oracles and Reactive Contracts enables a dynamic, responsive system capable of real-time interaction with both the digital and physical worlds. This broadens the scope and utility of blockchain technology beyond its current constraints. ## Conclusion -In this article, we’ve talked about the role of oracles within the context of Reactive Smart Contracts (RSCs), highlighting their significance in bridging the gap between on-chain and off-chain data. Key takeaways include: +In this article, we’ve talked about the role of oracles within the context of Reactive Contracts (RCs), highlighting their significance in bridging the gap between on-chain and off-chain data. Key takeaways include: - **Oracle Functionality:** Oracles are essential for importing real-world data onto the blockchain, enabling smart contracts to interact with external information such as price feeds, weather reports, and more. @@ -102,6 +102,6 @@ In this article, we’ve talked about the role of oracles within the context of - **Practical Applications:** Oracles facilitate various use cases, including decentralized finance (DeFi), insurance, and online betting, by providing real-time data to smart contracts and enabling automated, trustless interactions. -- **Integration with Reactive Smart Contracts:** The synergy between oracles and RSCs allows for dynamic, real-time responses to off-chain events. This integration leverages the strengths of both technologies to enhance the functionality and reach of blockchain applications. +- **Integration with Reactive Contracts:** The synergy between oracles and RCs allows for dynamic, real-time responses to off-chain events. This integration leverages the strengths of both technologies to enhance the functionality and reach of blockchain applications. For practical applications and further insights, explore our [use cases](../use-cases/index.md) and join our [Telegram](https://t.me/reactivedevs) group to engage with the community. \ No newline at end of file diff --git a/docs/education/module-1/index.md b/docs/education/module-1/index.md index 1259895..227783f 100644 --- a/docs/education/module-1/index.md +++ b/docs/education/module-1/index.md @@ -1,32 +1,32 @@ --- -title: "Module 1: Beginner — Foundations of Reactive Smart Contracts" +title: "Module 1: Beginner — Foundations of Reactive Contracts" sidebar_position: 1 -description: Learn the basics of RSCs, including their reactive nature, state management, EVM events, and oracles. Ideal for beginners looking to understand and apply RSCs in blockchain projects. +description: Learn the basics of RCs, including their reactive nature, state management, EVM events, and oracles. Ideal for beginners looking to understand and apply RCs in blockchain projects. slug: /education/module-1 --- -# Module 1: Beginner — Foundations of Reactive Smart Contracts +# Module 1: Beginner — Foundations of Reactive Contracts # Overview -Welcome to Module 1: Beginner — Foundations of Reactive Smart Contracts (RSCs)! This module introduces the core concepts and functionalities of RSCs, providing a foundation for applying them in blockchain projects. +Welcome to Module 1: Beginner — Foundations of Reactive Contracts (RCs)! This module introduces the core concepts and functionalities of RCs, providing a foundation for applying them in blockchain projects. -[Lesson 1: Reactive Smart Contracts](reactive-smart-contracts.md) +[Lesson 1: Reactive Contracts](./reactive-contracts.md) -Explore the mechanisms of RSCs, focusing on their reactive nature and Inversion of Control. Learn through use cases such as data collection with oracles and executing stop orders on decentralized exchanges. +Explore the mechanisms of RCs, focusing on their reactive nature and Inversion of Control. Learn through use cases such as data collection with oracles and executing stop orders on decentralized exchanges. -[Lesson 2: How Events and Callbacks Work](how-events-work.md) +[Lesson 2: How Events and Callbacks Work](./how-events-work.md) Understand how EVM events and callbacks enable interaction between smart contracts and external systems. Includes a practical example of Chainlink's price oracle integration. -[Lesson 3: ReactVM and Reactive Network As a Dual-State Environment](react-vm.md) +[Lesson 3: ReactVM and Reactive Network As a Dual-State Environment](./react-vm.md) -Examine the dual-state environment of RSCs within the Reactive Network and ReactVM. Learn about state management and transaction execution across these domains. +Examine the dual-state environment of RCs within the Reactive Network and ReactVM. Learn about state management and transaction execution across these domains. -[Lesson 4: How Subscriptions Work](subscriptions.md) +[Lesson 4: How Subscriptions Work](./subscriptions.md) -Learn about setting up and managing subscriptions in RSCs to streamline event handling and automate contract execution. +Learn about setting up and managing subscriptions in RCs to streamline event handling and automate contract execution. -[Lesson 5: How Oracles Work](how-oracles-work.md) +[Lesson 5: How Oracles Work](./how-oracles-work.md) Discover the role of oracles in connecting blockchain with off-chain data. Explore multisig protocols and practical applications in DeFi, insurance, and online betting. diff --git a/docs/education/module-1/react-vm.md b/docs/education/module-1/react-vm.md index 4d3986c..3dab928 100644 --- a/docs/education/module-1/react-vm.md +++ b/docs/education/module-1/react-vm.md @@ -1,7 +1,7 @@ --- title: "Lesson 3: ReactVM and Reactive Network As a Dual-State Environment" sidebar_position: 3 -description: Understand the dual-state environment of Reactive Smart Contracts. Learn to manage data, identify execution contexts, and handle transactions in both Reactive Network and ReactVM for efficient RSC development. +description: Understand the dual-state environment of Reactive Contracts. Learn to manage data, identify execution contexts, and handle transactions in both Reactive Network and ReactVM for efficient RC development. slug: react-vm --- @@ -9,18 +9,18 @@ slug: react-vm ## Overview -In [Reactive Smart Contracts](./reactive-smart-contracts.md), we discuss one of the basic concepts of reactive contracts (RSCs) — Inversion of Control, and how events and callbacks work in RSCs. This article focuses on another crucial property of RSCs: the fact they exist in two instances with separate states in the Reactive Network and ReactVM. Understanding this idea is necessary for successful reactive contract development. +In [Reactive Contracts](./reactive-contracts), we discuss one of the basic concepts of reactive contracts (RCs) — Inversion of Control, and how events and callbacks work in RCs. This article focuses on another crucial property of RCs: the fact they exist in two instances with separate states in the Reactive Network and ReactVM. Understanding this idea is necessary for successful reactive contract development. By the end of this lesson, you will learn to: * Distinguish both environments where a reactive contract is executed. * Identify the current environment. * Manage data with two separate states. -* Understand the types of transactions RSCs operate with. +* Understand the types of transactions RCs operate with. ## Differences Between the Reactive Network and ReactVM -Each Reactive Smart Contract has two instances — one on the Reactive Network and the other in its separate ReactVM. It is important to note that both instances are physically stored and executed on each network node. Parallelizing RSCs is an architectural decision made to ensure high performance even with big numbers of events. We will talk more about that in one of our next articles. +Each Reactive Contract has two instances — one on the Reactive Network and the other in its separate ReactVM. It is important to note that both instances are physically stored and executed on each network node. Parallelizing RCs is an architectural decision made to ensure high performance even with big numbers of events. We will talk more about that in one of our next articles. ![Reactive Network | React Vm ](./img/reactvm.jpg) @@ -34,7 +34,7 @@ Contracts within a single ReactVM can interact with the external world in two wa * Based on the execution of the code with the inputs from events, the ReactVM sends requests to the Reactive Network for callbacks to destination chains to perform the resulting on-chain actions. -For each RSC deployed, there are two instances of it with separate states but the same code. Each method is expected to be executed in one or both environments and to interact with one or both states. This leads to the question of how we identify, within the code, which state we are currently working with. +For each RC deployed, there are two instances of it with separate states but the same code. Each method is expected to be executed in one or both environments and to interact with one or both states. This leads to the question of how we identify, within the code, which state we are currently working with. ### Identifying the Execution Context @@ -215,7 +215,7 @@ The actual logic (checking liquidity reserves and emitting callbacks) is local t ## Transaction Execution -When working with a Reactive Smart Contract (RSC), there are two primary environments where transactions occur: the Reactive Network and the ReactVM. Each environment has different rules for initiating and processing transactions, as detailed below. The code is taken from [AbstractPausableReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractPausableReactive.sol). +When working with a Reactive Contract (RC), there are two primary environments where transactions occur: the Reactive Network and the ReactVM. Each environment has different rules for initiating and processing transactions, as detailed below. The code is taken from [AbstractPausableReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractPausableReactive.sol). ### Reactive Network Transactions @@ -223,7 +223,7 @@ Transactions on the Reactive Network can be initiated in two ways: directly by a #### User-Initiated Transactions -Users can invoke methods on the Reactive Network’s instance of an RSC to perform administrative functions or update contract state. For instance, pausing event subscriptions is done by calling the `pause()` function: +Users can invoke methods on the Reactive Network’s instance of an RC to perform administrative functions or update contract state. For instance, pausing event subscriptions is done by calling the `pause()` function: ```solidity function pause() external rnOnly onlyOwner { @@ -247,9 +247,9 @@ function pause() external rnOnly onlyOwner { - `onlyOwner` limits the call to the contract owner. - `service.unsubscribe()` removes the contract from listening to specific events (defined by `chain_id`, `topic_0`, etc.). -This `pause()` function prevents the RSC from reacting to events by unsubscribing from them, effectively stopping further event-driven transactions until it is resumed. +This `pause()` function prevents the RC from reacting to events by unsubscribing from them, effectively stopping further event-driven transactions until it is resumed. -The corresponding `resume()` function re-subscribes to those same events so that the RSC can continue responding when new events are emitted: +The corresponding `resume()` function re-subscribes to those same events so that the RC can continue responding when new events are emitted: ```solidity function resume() external rnOnly onlyOwner { @@ -281,7 +281,7 @@ Within the ReactVM, transactions can't be called directly by users. Instead, the - Reactive Network dispatches event - ReactVM receives and processes Event -When an RSC running in the ReactVM receives an event, it typically calls its core reaction function `react()` to handle the event. The `react()` function contains the business logic for: +When an RC running in the ReactVM receives an event, it typically calls its core reaction function `react()` to handle the event. The `react()` function contains the business logic for: - Updating internal state based on the received event. - Emitting callbacks to destination chains, which can then trigger transactions on those chains. @@ -292,13 +292,13 @@ We will consider other examples of `react()` functions for different use cases c ## Conclusion -In this lesson, we've explored how Reactive Smart Contracts (RSCs) function within two distinct environments: the Reactive Network and the ReactVM. Understanding the dual-state nature of RSCs is crucial for their effective development. Key takeaways include: +In this lesson, we've explored how Reactive Contracts (RCs) function within two distinct environments: the Reactive Network and the ReactVM. Understanding the dual-state nature of RCs is crucial for their effective development. Key takeaways include: -- **Dual-State Environments:** RSCs exist in two instances, each with separate states but the same code — one in the Reactive Network and one in the ReactVM. This setup allows for parallel processing and high performance. +- **Dual-State Environments:** RCs exist in two instances, each with separate states but the same code — one in the Reactive Network and one in the ReactVM. This setup allows for parallel processing and high performance. - **Identifying Execution Context:** The environment in which the contract is executing is identified using a boolean variable (`vm`). This allows for precise control over which code and state are accessed, ensuring the correct execution flow. -- **Managing Separate States:** RSCs maintain separate sets of variables for the Reactive Network and ReactVM, which are used according to the environment in which the contract is executed. This helps in maintaining clarity and avoiding conflicts between the two states. +- **Managing Separate States:** RCs maintain separate sets of variables for the Reactive Network and ReactVM, which are used according to the environment in which the contract is executed. This helps in maintaining clarity and avoiding conflicts between the two states. - **Transaction Types:** The Reactive Network handles transactions initiated by users or triggered by events on the origin chain, while the ReactVM processes events and executes the `react()` function, defining the reaction logic and initiating cross-chain callbacks. diff --git a/docs/education/module-1/reactive-contracts.md b/docs/education/module-1/reactive-contracts.md new file mode 100644 index 0000000..4b149b2 --- /dev/null +++ b/docs/education/module-1/reactive-contracts.md @@ -0,0 +1,85 @@ +--- +title: "Lesson 1: Reactive Contracts" +sidebar_position: 1 +description: Learn how RCs autonomously respond to blockchain events, contrasting traditional smart contracts. Understand Inversion of Control (IoC) and discover practical use cases. +slug: reactive-contracts +--- + +# Lesson 1: Reactive Contracts + +## Overview + +In the [introduction article](../introduction/reactive-contracts), we discuss the basics of Reactive Contracts (RCs), what they are, and why we need them. Let's dive deeper into the technical concepts of RCs with some examples to illustrate those concepts. + +By the end of this lesson, you will learn to: + +* Understand the key differences between Reactive Contracts (RCs) and traditional smart contracts. +* Grasp the concept of Inversion of Control and its significance in RCs. +* Recognize how RCs autonomously monitor and react to blockchain events. +* Explore various practical use cases where RCs can be applied, such as data collection from oracles, UniSwap stop orders, DEX arbitrage, and pools rebalancing. + +## How RCs Differ from Traditional Smart Contracts + +The main distinction between RCs and traditional smart contracts lies in reactivity. Traditional smart contracts are passive, only executing in response to direct EOA transactions. In contrast, RCs are reactive, continuously monitoring the blockchains for events of interest and autonomously executing predefined blockchain actions in response. + +## Inversion of Control + +A key concept in understanding RCs is the Inversion of Control (IoC). Traditional smart contracts operate under a direct control model, where the execution of their functions is initiated by external actors (EOA users or bots). RCs, however, invert this control by autonomously deciding when to execute based on the occurrence of predefined events. This IoC paradigm shifts how applications interact with the blockchain, enabling more dynamic and responsive systems. + +![Inversion of Control](./img/inversion-of-control.jpg) + +Without a reactive contract, you would need to set up a separate entity — let's say a bot — to monitor the blockchains using existing, most likely centralized, data solutions. This bot would hold the private keys for the managed funds and initiate transactions on EVM chains from its EOA address. Though such systems prove to be useful, they might be suboptimal for some use cases and not suitable at all for others. + +Inversion of Control allows us to avoid hosting additional entities that emulate humans signing transactions. If you have a predefined scenario outlining the sequence of transactions following on-chain events, you should be able to run this logic in a completely decentralized manner, as both your inputs and outputs remain on the blockchain. The Reactive Network gives smart contracts the property they’ve been missing from the start — the ability to be executed automatically, without a person (or a bot) signing a transaction, just based on other on-chain events. + +## What Happens Inside a Reactive Contract + +When creating a Reactive Contract, the first thing you need to specify is the chains, contracts, and events (topic 0) of interest. The RC will monitor these addresses for the specified events and initiate execution when one is detected. These events can include simple currency or token transfers, DEX swaps, loans, flash loans, votes, whale moves, or any other smart contract activity. + +Once an event of interest is detected, the Reactive Network automatically executes the logic you’ve implemented in your reactive contract. This may involve performing calculations based on the event data. RCs are stateful, meaning they have a state where values can be stored and updated. You can accumulate data over time in the state and then act when the combination of historical data and a new blockchain event meets the specified criteria. + +As a result of the event, the RC updates its state, keeping it up to date, and can initiate transactions on EVM blockchains. The entire process runs trustlessly within the Reactive Network, ensuring automatic, fast, and reliable execution. + +## Use Cases + +Let's take a closer look at several use cases to illustrate the concepts we’ve just discussed. This educational course will be structured around those use cases because we see practical application as the best way to learn about this tech. + +### Collecting Data from Several Oracles + +For RCs to respond to a broader spectrum of events, including off-chain occurrences, they integrate with oracles. Oracles are third-party services that feed trusted external data into the blockchain. A simple example of such data includes exchange rates or sports event outcomes. RCs can use this data to make informed decisions and execute actions based on real-world events, extending their applicability beyond the blockchain. + +Moreover, since an RC can monitor data from different smart contracts across various EVM-compatible blockchains, it can combine data from multiple oracles, resulting in more precise and decentralized information. In this case, the events that RCs will monitor are the updated events from the corresponding oracles. The calculations within the RC will involve combining data from different oracles (for example, by taking the average). The resulting action might be a trustless payout based on the outcome of a basketball game. + +### Uniswap Stop Order + +Another example of a reliable data source on the blockchain is a trading pool, such as a Uniswap pool. It can be even more dependable than oracles since it consists of pure on-chain data and does not rely on third parties. + +In this setup, a reactive contract would monitor the swaps in the specified UniSwap pool, calculating the liquidity and the exchange rate. When the exchange rate reaches a predetermined price, the reactive contract executes a swap transaction, thereby implementing a trustless stop order on top of the existing DEX. + +### DEX Arbitrage + +However, we can take the previous example further by implementing an actual arbitrage using RCs. Our reactive contract will monitor several different pools for price discrepancies and capitalize on them. Both one-chain and cross-chain approaches are possible. In the first case, we can use flash loans; in the second case, we will need liquidity on several chains, but we will gain access to more arbitrage opportunities. + +The beauty of this solution is that it will be decentralized, unlike the traditional approach with bots. This allows for numerous improvements that we have yet to explore — hopefully, together with you. + +### Pools Rebalancing + +While all the previous use cases involve building RCs on top of existing traditional Smart Contracts, the next one requires initially developing a DApp that relies on RCs. If we design our system from the start, knowing that we can leverage the Reactive Network technology, we can build our Ethereum Smart Contracts utilizing the functionality of RCs. + +This approach allows us to potentially create liquidity pools that automatically rebalance across several exchanges. The RC will monitor liquidity on all chains of interest and rebalance them by adding or draining funds as needed. + +## Conclusion + +After reading this lesson, you should have a solid understanding of the foundational concepts and potential applications of Reactive Contracts (RCs). Key takeaways include: + +- **Reactive vs. Traditional Contracts:** Unlike traditional smart contracts, RCs autonomously monitor blockchain events and execute actions without user intervention, providing a more dynamic and responsive system. + +- **Inversion of Control:** RCs invert the traditional execution model by allowing the contract itself to decide when to execute based on predefined events, eliminating the need for external triggers like bots or users. + +- **Decentralized Automation:** RCs enable fully decentralized operations, automating processes like data collection, DEX trading, and liquidity management without centralized intermediaries. + +- **Cross-Chain Interactions:** RCs can interact with multiple blockchains and sources, enabling sophisticated use cases like cross-chain arbitrage and multi-oracle data aggregation. + +- **Practical Applications:** RCs have diverse applications, including collecting data from oracles, implementing UniSwap stop orders, executing DEX arbitrage, and automatically rebalancing pools across exchanges. + +Explore more practical applications in our [use cases](../use-cases/index.md) and join our [Telegram](https://t.me/reactivedevs) group to contribute to the evolving world of Reactive Contracts. diff --git a/docs/education/module-1/reactive-smart-contracts.md b/docs/education/module-1/reactive-smart-contracts.md deleted file mode 100644 index ed5eacd..0000000 --- a/docs/education/module-1/reactive-smart-contracts.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: "Lesson 1: Reactive Smart Contracts" -sidebar_position: 1 -description: Learn how RSCs autonomously respond to blockchain events, contrasting traditional smart contracts. Understand Inversion of Control (IoC) and discover practical use cases. -slug: reactive-smart-contracts ---- - -# Lesson 1: Reactive Smart Contracts - -## Overview - -In the [introduction article](../introduction/reactive-smart-contracts.md), we discuss the basics of Reactive Smart Contracts (RSCs), what they are, and why we need them. Let's dive deeper into the technical concepts of RSCs with some examples to illustrate those concepts. - -By the end of this lesson, you will learn to: - -* Understand the key differences between Reactive Smart Contracts (RSCs) and traditional smart contracts. -* Grasp the concept of Inversion of Control and its significance in RSCs. -* Recognize how RSCs autonomously monitor and react to blockchain events. -* Explore various practical use cases where RSCs can be applied, such as data collection from oracles, UniSwap stop orders, DEX arbitrage, and pools rebalancing. - -## How RSCs Differ from Traditional Smart Contracts - -The main distinction between RSCs and traditional smart contracts lies in reactivity. Traditional smart contracts are passive, only executing in response to direct EOA transactions. In contrast, RSCs are reactive, continuously monitoring the blockchains for events of interest and autonomously executing predefined blockchain actions in response. - -## Inversion of Control - -A key concept in understanding RSCs is the Inversion of Control (IoC). Traditional smart contracts operate under a direct control model, where the execution of their functions is initiated by external actors (EOA users or bots). RSCs, however, invert this control by autonomously deciding when to execute based on the occurrence of predefined events. This IoC paradigm shifts how applications interact with the blockchain, enabling more dynamic and responsive systems. - -![Inversion of Control](./img/inversion-of-control.jpg) - -Without a reactive contract, you would need to set up a separate entity — let's say a bot — to monitor the blockchains using existing, most likely centralized, data solutions. This bot would hold the private keys for the managed funds and initiate transactions on EVM chains from its EOA address. Though such systems prove to be useful, they might be suboptimal for some use cases and not suitable at all for others. - -Inversion of Control allows us to avoid hosting additional entities that emulate humans signing transactions. If you have a predefined scenario outlining the sequence of transactions following on-chain events, you should be able to run this logic in a completely decentralized manner, as both your inputs and outputs remain on the blockchain. The Reactive Network gives smart contracts the property they’ve been missing from the start — the ability to be executed automatically, without a person (or a bot) signing a transaction, just based on other on-chain events. - -## What Happens Inside a Reactive Smart Contract - -When creating a Reactive Smart Contract, the first thing you need to specify is the chains, contracts, and events (topic 0) of interest. The RSC will monitor these addresses for the specified events and initiate execution when one is detected. These events can include simple currency or token transfers, DEX swaps, loans, flash loans, votes, whale moves, or any other smart contract activity. - -Once an event of interest is detected, the Reactive Network automatically executes the logic you’ve implemented in your reactive contract. This may involve performing calculations based on the event data. RSCs are stateful, meaning they have a state where values can be stored and updated. You can accumulate data over time in the state and then act when the combination of historical data and a new blockchain event meets the specified criteria. - -As a result of the event, the RSC updates its state, keeping it up to date, and can initiate transactions on EVM blockchains. The entire process runs trustlessly within the Reactive Network, ensuring automatic, fast, and reliable execution. - -## Use Cases - -Let's take a closer look at several use cases to illustrate the concepts we’ve just discussed. This educational course will be structured around those use cases because we see practical application as the best way to learn about this tech. - -### Collecting Data from Several Oracles - -For RSCs to respond to a broader spectrum of events, including off-chain occurrences, they integrate with oracles. Oracles are third-party services that feed trusted external data into the blockchain. A simple example of such data includes exchange rates or sports event outcomes. RSCs can use this data to make informed decisions and execute actions based on real-world events, extending their applicability beyond the blockchain. - -Moreover, since an RSC can monitor data from different smart contracts across various EVM-compatible blockchains, it can combine data from multiple oracles, resulting in more precise and decentralized information. In this case, the events that RSCs will monitor are the updated events from the corresponding oracles. The calculations within the RSC will involve combining data from different oracles (for example, by taking the average). The resulting action might be a trustless payout based on the outcome of a basketball game. - -### Uniswap Stop Order - -Another example of a reliable data source on the blockchain is a trading pool, such as a Uniswap pool. It can be even more dependable than oracles since it consists of pure on-chain data and does not rely on third parties. - -In this setup, a reactive contract would monitor the swaps in the specified UniSwap pool, calculating the liquidity and the exchange rate. When the exchange rate reaches a predetermined price, the reactive contract executes a swap transaction, thereby implementing a trustless stop order on top of the existing DEX. - -### DEX Arbitrage - -However, we can take the previous example further by implementing an actual arbitrage using RSCs. Our reactive contract will monitor several different pools for price discrepancies and capitalize on them. Both one-chain and cross-chain approaches are possible. In the first case, we can use flash loans; in the second case, we will need liquidity on several chains, but we will gain access to more arbitrage opportunities. - -The beauty of this solution is that it will be decentralized, unlike the traditional approach with bots. This allows for numerous improvements that we have yet to explore — hopefully, together with you. - -### Pools Rebalancing - -While all the previous use cases involve building RSCs on top of existing traditional Smart Contracts, the next one requires initially developing a DApp that relies on RSCs. If we design our system from the start, knowing that we can leverage the Reactive Network technology, we can build our Ethereum Smart Contracts utilizing the functionality of RSCs. - -This approach allows us to potentially create liquidity pools that automatically rebalance across several exchanges. The RSC will monitor liquidity on all chains of interest and rebalance them by adding or draining funds as needed. - -## Conclusion - -After reading this lesson, you should have a solid understanding of the foundational concepts and potential applications of Reactive Smart Contracts (RSCs). Key takeaways include: - -- **Reactive vs. Traditional Smart Contracts:** Unlike traditional smart contracts, RSCs autonomously monitor blockchain events and execute actions without user intervention, providing a more dynamic and responsive system. - -- **Inversion of Control:** RSCs invert the traditional execution model by allowing the contract itself to decide when to execute based on predefined events, eliminating the need for external triggers like bots or users. - -- **Decentralized Automation:** RSCs enable fully decentralized operations, automating processes like data collection, DEX trading, and liquidity management without centralized intermediaries. - -- **Cross-Chain Interactions:** RSCs can interact with multiple blockchains and sources, enabling sophisticated use cases like cross-chain arbitrage and multi-oracle data aggregation. - -- **Practical Applications:** RSCs have diverse applications, including collecting data from oracles, implementing UniSwap stop orders, executing DEX arbitrage, and automatically rebalancing pools across exchanges. - -Explore more practical applications in our [use cases](../use-cases/index.md) and join our [Telegram](https://t.me/reactivedevs) group to contribute to the evolving world of Reactive Smart Contracts. diff --git a/docs/education/module-1/subscriptions.md b/docs/education/module-1/subscriptions.md index 5a76efe..8b28141 100644 --- a/docs/education/module-1/subscriptions.md +++ b/docs/education/module-1/subscriptions.md @@ -1,7 +1,7 @@ --- title: "Lesson 4: How Subscriptions Work" sidebar_position: 4 -description: Understand how to implement subscriptions in the constructor of reactive smart contracts and how to manage subscriptions dynamically using callbacks to destination chains +description: Understand how to implement subscriptions in the constructor of reactive contracts and how to manage subscriptions dynamically using callbacks to destination chains slug: how-subscriptions-work --- @@ -9,13 +9,13 @@ slug: how-subscriptions-work ## Overview -In the previous lesson, we covered the basic differences between the Reactive Network and ReactVM. In this one, we will dive into subscriptions, a key feature that allows RSCs to automatically respond to events emitted by other contracts. When these events occur, the subscribing contract can automatically execute predefined logic. +In the previous lesson, we covered the basic differences between the Reactive Network and ReactVM. In this one, we will dive into subscriptions, a key feature that allows RCs to automatically respond to events emitted by other contracts. When these events occur, the subscribing contract can automatically execute predefined logic. By the end of this article, you will learn to: * Configure and manage subscriptions both statically and dynamically. * Handle subscription and unsubscription events within your smart contracts. -* Recognize the limitations and best practices for using subscriptions in Reactive Smart Contracts. +* Recognize the limitations and best practices for using subscriptions in Reactive Contracts. ## How to Implement Subscriptions @@ -415,13 +415,13 @@ The function processes incoming log records from the ReactVM and executes differ ## Conclusion -In this article, we’ve explored the use of subscriptions in Reactive Smart Contracts, a fundamental feature that enables automatic responses to events from other contracts. Key takeaways include: +In this article, we’ve explored the use of subscriptions in Reactive Contracts, a fundamental feature that enables automatic responses to events from other contracts. Key takeaways include: - **Subscription Setup:** Subscriptions are established using the `subscribe` method from the Reactive Network’s system contract. This can be done statically in the constructor or managed dynamically as needed. - **Subscription Criteria:** Proper configuration is essential for effective subscriptions. Wildcards and specific values are used to define the scope of events to which a contract subscribes. Avoid prohibited subscription patterns to ensure efficient operation. -- **Dynamic Management:** Subscriptions can be dynamically adjusted based on incoming events, with the `react()` method playing a central role in managing these operations. This approach ensures that RSCs can respond in real-time to changes in the network. +- **Dynamic Management:** Subscriptions can be dynamically adjusted based on incoming events, with the `react()` method playing a central role in managing these operations. This approach ensures that RCs can respond in real-time to changes in the network. - **Handling Events:** Contracts must handle events carefully by preparing appropriate payloads for subscription, unsubscription, and approval actions. This ensures accurate and timely updates across the network. diff --git a/docs/education/module-2/basic-reactive-functions.md b/docs/education/module-2/basic-reactive-functions.md index 2656c28..d531855 100644 --- a/docs/education/module-2/basic-reactive-functions.md +++ b/docs/education/module-2/basic-reactive-functions.md @@ -1,7 +1,7 @@ --- title: "Lesson 7: Implementing Basic Reactive Functions" sidebar_position: 2 -description: Learn to implement Reactive Smart Contracts for Uniswap V2, automate stop orders, and understand their execution based on Sync events. +description: Learn to implement Reactive Contracts for Uniswap V2, automate stop orders, and understand their execution based on Sync events. slug: basic-reactive-functions --- @@ -9,11 +9,11 @@ slug: basic-reactive-functions ## Overview -In this lesson, we’ll go through the Reactive Smart Contract (RSC) specifically designed for the Uniswap V2 platform, aimed at executing stop orders based on predefined conditions. By the end of this lesson, you’ll know: +In this lesson, we’ll go through the Reactive Contract (RC) specifically designed for the Uniswap V2 platform, aimed at executing stop orders based on predefined conditions. By the end of this lesson, you’ll know: -* That RSCs are pretty similar to Ethereum smart contracts and thus easy to understand. -* What each part of the stop-order reactive smart contract means. -* How this reactive smart contract is executed and what it does. +* That RCs are pretty similar to Ethereum smart contracts and thus easy to understand. +* What each part of the stop-order reactive contract means. +* How this reactive contract is executed and what it does. ## Contract @@ -198,11 +198,11 @@ If `token0` is selected, the function checks if the ratio of `reserve1` to `rese ## Conclusion -In this article, we’ve examined the implementation of a Reactive Smart Contract (RSC) for managing stop orders on the Uniswap V2 platform. Key takeaways include: +In this article, we’ve examined the implementation of a Reactive Contract (RC) for managing stop orders on the Uniswap V2 platform. Key takeaways include: -- **Similarity to Ethereum Smart Contracts:** RSCs are conceptually similar to Ethereum smart contracts, making them accessible for those familiar with Ethereum's architecture. +- **Similarity to Ethereum Smart Contracts:** RCs are conceptually similar to Ethereum smart contracts, making them accessible for those familiar with Ethereum's architecture. -- **Contract Components:** We reviewed the key elements of the stop-order reactive smart contract, including event declarations, contract variables, and the logic behind the `react()` and `below_threshold()` functions. +- **Contract Components:** We reviewed the key elements of the stop-order reactive contract, including event declarations, contract variables, and the logic behind the `react()` and `below_threshold()` functions. - **Execution Flow:** The contract’s lifecycle involves subscribing to relevant events, monitoring Uniswap V2 pool reserves, triggering stop orders when conditions are met, and capturing completion events to finalize the process. diff --git a/docs/education/module-2/how-uniswap-works.md b/docs/education/module-2/how-uniswap-works.md index 5ca8a2e..61357c3 100644 --- a/docs/education/module-2/how-uniswap-works.md +++ b/docs/education/module-2/how-uniswap-works.md @@ -85,7 +85,7 @@ for more complex interactions like flash swaps. This logic encapsulates the essence of a swap transaction in Uniswap V2, balancing the pool's reserves to maintain the constant product while facilitating token exchanges. -We will be mostly interested in `Swap` events to monitor the blockchain activity and run Reactive smart contracts based on it. Since the code of the pool smart contract does not change, most of the information that is different for every transaction is being logged in the event. So let’s talk a bit more about the two types of events we’ll be most interested in: `Swap` and `Sync`. +We will be mostly interested in `Swap` events to monitor the blockchain activity and run Reactive Contracts based on it. Since the code of the pool smart contract does not change, most of the information that is different for every transaction is being logged in the event. So let’s talk a bit more about the two types of events we’ll be most interested in: `Swap` and `Sync`. ## Events in Uniswap V2 @@ -139,7 +139,7 @@ In this article, we’ve explored the fundamentals of Uniswap V2, a cornerstone - **Constant Product Formula:** The formula (x * y = k) ensures that the product of the quantities of the two tokens remains constant, allowing for dynamic pricing based on trading activity. -- **Swap and Sync Events:** The `Swap` event provides detailed information about trades, including token amounts and addresses, while the `Sync` event keeps track of reserve updates. These events are crucial for monitoring and integrating Uniswap activity with Reactive Smart Contracts. +- **Swap and Sync Events:** The `Swap` event provides detailed information about trades, including token amounts and addresses, while the `Sync` event keeps track of reserve updates. These events are crucial for monitoring and integrating Uniswap activity with Reactive Contracts. - **Code Mechanics:** The provided code example illustrates the core functionality of the `swap` function in Uniswap V2, demonstrating how the contract maintains liquidity and ensures accurate token swaps. diff --git a/docs/education/module-2/index.md b/docs/education/module-2/index.md index ffecae5..48c3640 100644 --- a/docs/education/module-2/index.md +++ b/docs/education/module-2/index.md @@ -1,7 +1,7 @@ --- title: "Module 2: Intermediate - Building Blocks for Reactivity" sidebar_position: 1 -description: Learn the basics of DeFi with Uniswap V2 and Reactive Smart Contracts. Discover how liquidity pools work and see RSCs in action as they autonomously execute trades. +description: Learn the basics of DeFi with Uniswap V2 and Reactive Contracts. Discover how liquidity pools work and see RCs in action as they autonomously execute trades. slug: /education/module-2 --- @@ -9,12 +9,12 @@ slug: /education/module-2 # Overview -Welcome to Module 2: Intermediate - Building Blocks for Reactivity! In this module, we're diving into decentralized finance (DeFi), with a focus on understanding and applying Reactive Smart Contracts (RSCs). +Welcome to Module 2: Intermediate - Building Blocks for Reactivity! In this module, we're diving into decentralized finance (DeFi), with a focus on understanding and applying Reactive Contracts (RCs). -[Lesson 6: Understanding Uniswap V2 Pools and Smart Contracts](how-uniswap-works.md) +[Lesson 6: Understanding Uniswap V2 Pools and Smart Contracts](./how-uniswap-works.md) Gain an understanding of Uniswap V2, a key decentralized finance protocol. Learn how liquidity pools function and explore the smart contracts that drive Uniswap V2, enabling efficient and decentralized trading. -[Lesson 7: Implementing Basic Reactive Functions](basic-reactive-functions.md) +[Lesson 7: Implementing Basic Reactive Functions](./basic-reactive-functions.md) -Explore how Reactive Smart Contracts (RSCs) operate within the DeFi space. Understand how RSCs can autonomously execute trades and respond to specific conditions, improving the capabilities of decentralized applications. \ No newline at end of file +Explore how Reactive Contracts (RCs) operate within the DeFi space. Understand how RCs can autonomously execute trades and respond to specific conditions, improving the capabilities of decentralized applications. \ No newline at end of file diff --git a/docs/education/use-cases/index.md b/docs/education/use-cases/index.md index 9b92b06..9fbeb6f 100644 --- a/docs/education/use-cases/index.md +++ b/docs/education/use-cases/index.md @@ -1,7 +1,7 @@ --- title: "Use Cases" sidebar_position: 1 -description: Discover practical uses of Reactive Smart Contracts with demos on low-latency log monitoring and Uniswap V2 stop orders. Deploy and test these examples to boost your expertise. +description: Discover practical uses of Reactive Contracts with demos on low-latency log monitoring and Uniswap V2 stop orders. Deploy and test these examples to boost your expertise. slug: /education/use-cases --- @@ -9,18 +9,18 @@ slug: /education/use-cases ## Overview -The Use Cases section primarily focuses on analyzing scenarios where Reactive Smart Contracts might be a game changer. +The Use Cases section primarily focuses on analyzing scenarios where Reactive Contracts might be a game changer. -The [Basic Demo Smart Contract](use-case-1.md) is a basic use case of the Reactive Network enabling low-latency event monitoring, capturing logs from origin chain contracts, processing them, and triggering callbacks on the destination chain. +The [Basic Demo](use-case-1.md) is a basic use case of the Reactive Network enabling low-latency event monitoring, capturing logs from origin chain contracts, processing them, and triggering callbacks on the destination chain. -The [Deploying Reactive Smart Contracts with Remix](remix-ide-demo.mdx) article is a guide for deploying a Reactive Smart Contract using the Remix Development Environment. +The [Deploying Reactive Contracts with Remix](./remix-ide-demo.mdx) article is a guide for deploying a Reactive Contract using the Remix Development Environment. -The [Uniswap V2 Stop Order Demo](use-case-3.md) is a demo of a simple reactive smart contract that implements a stop order upon a Uniswap V2 liquidity pool. Study its setup and try deploying and testing it yourself. +The [Uniswap V2 Stop Order Demo](./use-case-3.md) is a demo of a simple Reactive contract that implements a stop order upon a Uniswap V2 liquidity pool. Study its setup and try deploying and testing it yourself. -The [Approval Magic Demo](use-case-2.md) extends reactive and subscription-based concepts to implement an approval-based token exchange across multiple chains. +The [Approval Magic Demo](./use-case-2.md) extends reactive and subscription-based concepts to implement an approval-based token exchange across multiple chains. If you have an idea for another use case, feel free to submit and turn it into a bounty, using our [Unicornization](https://reactive.network/unicornization) program. ## GitHub Repository -Visit the [Reactive Smart Contract Demos](https://github.com/Reactive-Network/reactive-smart-contract-demos) repository on GitHub to clone the project and start exploring! +Visit the [Reactive Contract Demos](https://github.com/Reactive-Network/reactive-smart-contract-demos) repository on GitHub to clone the project and start exploring! diff --git a/docs/education/use-cases/remix-ide-demo.mdx b/docs/education/use-cases/remix-ide-demo.mdx index 7cc65d1..46bf300 100644 --- a/docs/education/use-cases/remix-ide-demo.mdx +++ b/docs/education/use-cases/remix-ide-demo.mdx @@ -1,14 +1,14 @@ --- -title: "Deploying Reactive Smart Contracts with Remix" +title: "Deploying Reactive Contracts with Remix" sidebar_position: 2 -description: Learn how to deploy a Basic Reactive Smart Contract using Remix IDE. Ideal for mastering Reactive Network fundamentals. +description: Learn how to deploy a basic reactive contract using Remix IDE. Ideal for mastering Reactive Network fundamentals. slug: remix-ide-demo --- import LasnaButton from "../../../src/components/lasna-button"; import DownloadButton from "../../../src/components/download-zip"; -# Deploying Reactive Smart Contracts with Remix +# Deploying Reactive Contracts with Remix ## Overview diff --git a/docs/education/use-cases/use-case-1.md b/docs/education/use-cases/use-case-1.md index 86aa252..8602e0d 100644 --- a/docs/education/use-cases/use-case-1.md +++ b/docs/education/use-cases/use-case-1.md @@ -1,7 +1,7 @@ --- title: "Use Case: Reactive Network Demo" sidebar_position: 1 -description: Learn to build and deploy a Basic Reactive Smart Contract. Understand low-latency log monitoring and cross-chain calls using Ethereum testnets. Ideal for mastering Reactive Network fundamentals. +description: Learn to build and deploy a Basic Reactive Contract. Understand low-latency log monitoring and cross-chain calls using Ethereum testnets. Ideal for mastering Reactive Network fundamentals. slug: use-case-1 --- @@ -14,7 +14,7 @@ This article focuses on building and deploying a reactive contract, using the ba * Low-latency monitoring of logs emitted by contracts on the origin chain. * Executing calls from the Reactive Network to contracts on the destination chain. -![Basic Demo Smart Contract](./img/use-case-1.png) +![Basic Demo](./img/use-case-1.png) ## Contracts diff --git a/docs/education/use-cases/use-case-2.md b/docs/education/use-cases/use-case-2.md index 0b64bf0..aa2d075 100644 --- a/docs/education/use-cases/use-case-2.md +++ b/docs/education/use-cases/use-case-2.md @@ -64,4 +64,4 @@ To deploy the contracts to Ethereum Sepolia and Reactive Lasna, [clone](https:// ## Conclusion -The Approval Magic Demo exemplifies the transformative potential of reactive smart contracts by automating token approvals and transfers. By utilizing `ApprovalService` and `ApprovalListener`, the system simplifies complex multi-chain interactions while optimizing gas costs. Client contracts like `ApprovalEthExch` and `ApprovalMagicSwap` further demonstrate its real-world utility in enabling token exchanges and swaps. \ No newline at end of file +The Approval Magic Demo exemplifies the transformative potential of Reactive Contracts by automating token approvals and transfers. By utilizing `ApprovalService` and `ApprovalListener`, the system simplifies complex multi-chain interactions while optimizing gas costs. Client contracts like `ApprovalEthExch` and `ApprovalMagicSwap` further demonstrate its real-world utility in enabling token exchanges and swaps. \ No newline at end of file diff --git a/docs/education/use-cases/use-case-3.md b/docs/education/use-cases/use-case-3.md index c224bc1..ce619e8 100644 --- a/docs/education/use-cases/use-case-3.md +++ b/docs/education/use-cases/use-case-3.md @@ -1,7 +1,7 @@ --- title: "Use Case: Uniswap V2 Stop Order Demo" sidebar_position: 3 -description: Discover how a Reactive Smart Contract executes stop orders on Uniswap V2 pools, automating trade actions based on predefined conditions. Gain practical insights into its setup, functionality, and deployment. +description: Discover how a Reactive Contract executes stop orders on Uniswap V2 pools, automating trade actions based on predefined conditions. Gain practical insights into its setup, functionality, and deployment. slug: use-case-3 --- @@ -9,7 +9,7 @@ slug: use-case-3 ## Overview -This article focuses on the [Uniswap V2 Stop Order Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/uniswap-v2-stop-order) where a reactive contract listens for `Sync` events in a Uniswap V2 pool and triggers asset sales when the exchange rate hits a specified threshold. This demo extends the principles introduced in the [Reactive Network Demo](./use-case-1.md), which provides an introduction to building reactive smart contracts that respond to real-time events. +This article focuses on the [Uniswap V2 Stop Order Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/uniswap-v2-stop-order) where a reactive contract listens for `Sync` events in a Uniswap V2 pool and triggers asset sales when the exchange rate hits a specified threshold. This demo extends the principles introduced in the [Reactive Network Demo](./use-case-1.md), which provides an introduction to building Reactive Contracts that respond to real-time events. ![Uniswap V2 Stop Order](./img/uniswap-stop-order.jpg) diff --git a/docusaurus.config.js b/docusaurus.config.js index 5cf97b2..e54b1d7 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -199,7 +199,7 @@ const config = { }, { from: "/education/getting-started/reactive-smart-contracts", - to: "/education/introduction/reactive-smart-contracts" + to: "/education/introduction/reactive-contracts" }, { from: "/docs/data-origins-and-destinations", @@ -209,10 +209,6 @@ const config = { from: "/category/getting-started", to: "/education/introduction/" }, - { - from: "/docs/kopli-testnet", - to: "/reactive-mainnet" - }, { from: "/system-contract", to: "/economy" @@ -221,37 +217,17 @@ const config = { from: "/docs/getting-started", to: "/" }, - { - from: "/docs/architecture/reactive-smart-contracts", - to: "/reactive-smart-contracts" - }, - { - from: "/architecture/reactive-smart-contracts", - to: "/reactive-smart-contracts" - }, - { - from: "/docs/architecture/react-vm", - to: "/reactvm" - }, - { - from: "/architecture/react-vm", - to: "/reactvm" - }, { from: "/docs/demos", to: "/demos" }, { - from: "/architecture", - to: "/" - }, - { - from: "/compendium", - to: "/" + from: "/docs/reactive-smart-contracts", + to: "/reactive-contracts" }, { - from: "/kopli-testnet", - to: "/reactive-mainnet" + from: "/reactive-smart-contracts", + to: "/reactive-contracts" }, ] } diff --git a/src/components/origins-destinations-testnet.js b/src/components/origins-destinations-testnet.js index b006592..55b740d 100644 --- a/src/components/origins-destinations-testnet.js +++ b/src/components/origins-destinations-testnet.js @@ -2,33 +2,6 @@ import React from 'react'; const TestnetChainTable = () => { const data = [ - { - chain: 'Ethereum Sepolia', - chainId: 11155111, - link: 'https://sepolia.etherscan.io/', - callbackAddress: '0xc9f36411C9897e7F959D99ffca2a0Ba7ee0D7bDA', - rpcUrl: 'https://chainlist.org/chain/11155111', - origin: true, - destination: true - }, - { - chain: 'Binance Smart Chain', - chainId: 97, - link: 'https://testnet.bscscan.com/', - callbackAddress: '', - rpcUrl: 'https://chainlist.org/chain/97', - origin: true, - destination: false - }, - { - chain: 'Polygon Amoy', - chainId: 80002, - link: 'https://www.oklink.com/amoy', - callbackAddress: '', - rpcUrl: 'https://chainlist.org/chain/80002', - origin: true, - destination: false - }, { chain: 'Avalanche Fuji', chainId: 43113, @@ -47,6 +20,24 @@ const TestnetChainTable = () => { origin: true, destination: false }, + { + chain: 'Binance Smart Chain', + chainId: 97, + link: 'https://testnet.bscscan.com/', + callbackAddress: '', + rpcUrl: 'https://chainlist.org/chain/97', + origin: true, + destination: false + }, + { + chain: 'Ethereum Sepolia', + chainId: 11155111, + link: 'https://sepolia.etherscan.io/', + callbackAddress: '0xc9f36411C9897e7F959D99ffca2a0Ba7ee0D7bDA', + rpcUrl: 'https://chainlist.org/chain/11155111', + origin: true, + destination: true + }, { chain: 'Reactive Lasna', chainId: 5318007, @@ -55,7 +46,16 @@ const TestnetChainTable = () => { rpcUrl: 'https://lasna-rpc.rnk.dev/', origin: true, destination: true - } + }, + { + chain: 'Polygon Amoy', + chainId: 80002, + link: 'https://www.oklink.com/amoy', + callbackAddress: '', + rpcUrl: 'https://chainlist.org/chain/80002', + origin: true, + destination: false + }, ]; return ( diff --git a/src/components/origins-destinations.js b/src/components/origins-destinations.js index 125a977..15bd686 100644 --- a/src/components/origins-destinations.js +++ b/src/components/origins-destinations.js @@ -3,20 +3,20 @@ import React from 'react'; const MainnetChainTable = () => { const data = [ { - chain: 'Ethereum', - chainId: 1, - link: 'https://etherscan.io/', - callbackAddress: '0x1D5267C1bb7D8bA68964dDF3990601BDB7902D76', - rpcUrl: 'https://chainlist.org/chain/1', + chain: 'Abstract', + chainId: 2741, + link: 'https://abscan.org/', + callbackAddress: '0x9299472A6399Fd1027ebF067571Eb3e3D7837FC4', + rpcUrl: 'https://chainlist.org/chain/2741', origin: true, destination: true }, { - chain: 'Binance Smart Chain', - chainId: 56, - link: 'https://bscscan.com/', - callbackAddress: '0xdb81A196A0dF9Ef974C9430495a09B6d535fAc48', - rpcUrl: 'https://chainlist.org/chain/56', + chain: 'Arbitrum One', + chainId: 42161, + link: 'https://www.arbiscan.io/', + callbackAddress: '0x4730c58FDA9d78f60c987039aEaB7d261aAd942E', + rpcUrl: 'https://chainlist.org/chain/42161', origin: true, destination: true }, @@ -39,20 +39,20 @@ const MainnetChainTable = () => { destination: true }, { - chain: 'Arbitrum One', - chainId: 42161, - link: 'https://www.arbiscan.io/', - callbackAddress: '0x4730c58FDA9d78f60c987039aEaB7d261aAd942E', - rpcUrl: 'https://chainlist.org/chain/42161', + chain: 'Binance Smart Chain', + chainId: 56, + link: 'https://bscscan.com/', + callbackAddress: '0xdb81A196A0dF9Ef974C9430495a09B6d535fAc48', + rpcUrl: 'https://chainlist.org/chain/56', origin: true, destination: true }, { - chain: 'Sonic', - chainId: 146, - link: 'https://sonicscan.org/', - callbackAddress: '0x9299472a6399fd1027ebf067571eb3e3d7837fc4', - rpcUrl: 'https://chainlist.org/chain/146', + chain: 'Ethereum', + chainId: 1, + link: 'https://etherscan.io/', + callbackAddress: '0x1D5267C1bb7D8bA68964dDF3990601BDB7902D76', + rpcUrl: 'https://chainlist.org/chain/1', origin: true, destination: true }, @@ -65,15 +65,6 @@ const MainnetChainTable = () => { origin: true, destination: true }, - { - chain: 'Abstract', - chainId: 2741, - link: 'https://abscan.org/', - callbackAddress: '0x9299472A6399Fd1027ebF067571Eb3e3D7837FC4', - rpcUrl: 'https://chainlist.org/chain/2741', - origin: true, - destination: true - }, { chain: 'Linea', chainId: 59144, @@ -83,6 +74,24 @@ const MainnetChainTable = () => { origin: true, destination: true }, + { + chain: 'Reactive Mainnet', + chainId: 1597, + link: 'https://reactscan.net', + callbackAddress: '0x0000000000000000000000000000000000fffFfF', + rpcUrl: 'https://mainnet-rpc.rnk.dev/', + origin: true, + destination: true + }, + { + chain: 'Sonic', + chainId: 146, + link: 'https://sonicscan.org/', + callbackAddress: '0x9299472a6399fd1027ebf067571eb3e3d7837fc4', + rpcUrl: 'https://chainlist.org/chain/146', + origin: true, + destination: true + }, { chain: 'Unichain', chainId: 130, @@ -92,15 +101,6 @@ const MainnetChainTable = () => { origin: true, destination: true }, - { - chain: 'Reactive Mainnet', - chainId: 1597, - link: 'https://reactscan.net', - callbackAddress: '0x0000000000000000000000000000000000fffFfF', - rpcUrl: 'https://mainnet-rpc.rnk.dev/', - origin: true, - destination: true - } ]; return (