master
master
Subscribe to Won Chong
Subscribe to Won Chong
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
Greetings, dear RedStone miners! We are people of action, we put on a helmet and go to mine RSG, gaining knowledge already in the process of work. You can have a diamond pickaxe, but this will not allow you to mine more Gems, since we do not live in Minecraft.
Knowledge is the source of our power, it distinguishes the young miners from the seasoned ones, so let's look at an important chapter in the study of RedStone - its modular design.
The concept of modularity
What is modularity? Modularity is an approach in which a complex system is broken down into separate parts (modules), each of which performs its own task. These modules can be developed, changed or used separately, while the entire system remains integral.
This concept can be easily understood using Lego toys as an example. So, we can buy a Lego set in a store and assemble a boat-shaped toy according to the instructions. But we can also buy a ready-made boat-shaped toy in a store. What is the advantage of the first option? In this case, it is that we can assemble other things we can imagine from a set of Lego blocks.
But the key thing here is that each part, be it a person, glass or a boat motor, is a separate independent module, but if you put them together, they will become part of one large system in the form of a boat.
Structure of Blockchain Oracles
But of course, we are not here to discuss Lego. Let's start with a quick definition. A blockchain oracle is a service that connects the blockchain to the outside world. It provides data from the outside world, namely prices for various assets, tokens, and coins.
At the moment, many oracles, including such a behemoth as Chainlink, work in a monolithic way. They have a basic functionality, which is that they work as a single system, performing all functions within a single architecture.
In turn, RedStone has a modular structure. Let's try to compare 2 different types of oracles.
Flexibility.
Standard oracles. They offer a fixed set of features and architectures, making them difficult to adapt to specific scenarios. For example, adding non-standard data processing methods or unique algorithms to Chainlink is often impossible without significant modifications.
Modular oracles. They provide customization: users can combine different modules (e.g. data processing, verification, transport) depending on their needs.
Scalability.
Standard oracles. Chainlink supports a one-size-fits-all approach, which does not always optimally distribute resources under high loads. As the volume of data or the number of requests increases, performance may drop.
Modular oracles. By dividing tasks between modules, scaling is easier and more flexible. For example, you can allocate separate modules for processing big data.
Centralization of processes.
Standard oracles. Despite their decentralized nature, the mechanisms for collecting, verifying, and transmitting data are often tied to strictly defined platform rules. Chainlink, for example, manages its list of nodes, which can limit the choice of data providers.
Modular oracles. Allow users to choose who participates in the verification process and how it is performed, reducing the risk of centralized points of failure.
Cross-platform compatibility.
Standard oracles. Are initially optimized for specific blockchains. Chainlink, for example, was originally designed for Ethereum, which places limitations on support for other ecosystems.
Modular oracles. Are built with an emphasis on interoperability across different networks, making it easier to integrate data for applications running in the cross-chain space.
Operating costs.
Standard oracles. The user pays for a full range of services, regardless of whether they need them or not. Chainlink has a fixed cost for data transfer, which can be higher than modular approaches.
Modular oracles. Allow you to pay only for the modules and services that you actually use.
Upgradability and resilience to change.
RedStone Oracles Modular Structure
RedStone is rooted in a modular design, where all of its modules can be divided into three main groups:
Data collection and aggregation.
Data Distribution Layer or DDL, which in turn is divided into three additional modules.
Data consumption, which in turn is divided into four modules.
Data collection and aggregation
This module includes Data Sources and RedStone oracle nodes. Initially, data comes from various sources, namely from centralized exchanges (e.g. Binance, Bybit, Gate), decentralized exchanges (e.g. Uniswap, SushiSwap, Pancake), and aggregators (CoinGecko, CoinMarketCap).
In nodes, this data is aggregated, i.e. processed, verified by various methods, then signed by node operators and sent to the next group, namely DDL.
Data Distribution Layer
DDL in turn receives already aggregated data and broadcasts it via Direct Gateways directly to users (managed by the RedStone team) or via Streamr gateways, which also deliver data to consumers, but also has an additional function: temporary storage of data while waiting for a user response. Managed by the decentralized Streamr network.
The last module of DDL is the specially developed Arweave Network, which archives all data in its own network.
Data consumption
This module is the last link in the chain and can be subdivided depending on the model of RedStone integration into the corresponding protocols:
RedStone Pull Model.
RedStone Push Model.
RedStone X model.
It is recommended to use the innovative Pull Model, since it dynamically enters data into user transactions, achieving maximum gas efficiency.
In conclusion, I would like to say that the RedStone modular structure is a universal structure that will suit almost any blockchain. At the same time, the use of this oracle will reduce gas prices for transactions and provide greater security for protocols in case of possible exploits.
Website: http://redstone.finance
Blog: http://blog.redstone.finance
Twitter: https://x.com/redstone_defi
Greetings, dear RedStone miners! We are people of action, we put on a helmet and go to mine RSG, gaining knowledge already in the process of work. You can have a diamond pickaxe, but this will not allow you to mine more Gems, since we do not live in Minecraft.
Knowledge is the source of our power, it distinguishes the young miners from the seasoned ones, so let's look at an important chapter in the study of RedStone - its modular design.
The concept of modularity
What is modularity? Modularity is an approach in which a complex system is broken down into separate parts (modules), each of which performs its own task. These modules can be developed, changed or used separately, while the entire system remains integral.
This concept can be easily understood using Lego toys as an example. So, we can buy a Lego set in a store and assemble a boat-shaped toy according to the instructions. But we can also buy a ready-made boat-shaped toy in a store. What is the advantage of the first option? In this case, it is that we can assemble other things we can imagine from a set of Lego blocks.
But the key thing here is that each part, be it a person, glass or a boat motor, is a separate independent module, but if you put them together, they will become part of one large system in the form of a boat.
Structure of Blockchain Oracles
But of course, we are not here to discuss Lego. Let's start with a quick definition. A blockchain oracle is a service that connects the blockchain to the outside world. It provides data from the outside world, namely prices for various assets, tokens, and coins.
At the moment, many oracles, including such a behemoth as Chainlink, work in a monolithic way. They have a basic functionality, which is that they work as a single system, performing all functions within a single architecture.
In turn, RedStone has a modular structure. Let's try to compare 2 different types of oracles.
Flexibility.
Standard oracles. They offer a fixed set of features and architectures, making them difficult to adapt to specific scenarios. For example, adding non-standard data processing methods or unique algorithms to Chainlink is often impossible without significant modifications.
Modular oracles. They provide customization: users can combine different modules (e.g. data processing, verification, transport) depending on their needs.
Scalability.
Standard oracles. Chainlink supports a one-size-fits-all approach, which does not always optimally distribute resources under high loads. As the volume of data or the number of requests increases, performance may drop.
Modular oracles. By dividing tasks between modules, scaling is easier and more flexible. For example, you can allocate separate modules for processing big data.
Centralization of processes.
Standard oracles. Despite their decentralized nature, the mechanisms for collecting, verifying, and transmitting data are often tied to strictly defined platform rules. Chainlink, for example, manages its list of nodes, which can limit the choice of data providers.
Modular oracles. Allow users to choose who participates in the verification process and how it is performed, reducing the risk of centralized points of failure.
Cross-platform compatibility.
Standard oracles. Are initially optimized for specific blockchains. Chainlink, for example, was originally designed for Ethereum, which places limitations on support for other ecosystems.
Modular oracles. Are built with an emphasis on interoperability across different networks, making it easier to integrate data for applications running in the cross-chain space.
Operating costs.
Standard oracles. The user pays for a full range of services, regardless of whether they need them or not. Chainlink has a fixed cost for data transfer, which can be higher than modular approaches.
Modular oracles. Allow you to pay only for the modules and services that you actually use.
Upgradability and resilience to change.
RedStone Oracles Modular Structure
RedStone is rooted in a modular design, where all of its modules can be divided into three main groups:
Data collection and aggregation.
Data Distribution Layer or DDL, which in turn is divided into three additional modules.
Data consumption, which in turn is divided into four modules.
Data collection and aggregation
This module includes Data Sources and RedStone oracle nodes. Initially, data comes from various sources, namely from centralized exchanges (e.g. Binance, Bybit, Gate), decentralized exchanges (e.g. Uniswap, SushiSwap, Pancake), and aggregators (CoinGecko, CoinMarketCap).
In nodes, this data is aggregated, i.e. processed, verified by various methods, then signed by node operators and sent to the next group, namely DDL.
Data Distribution Layer
DDL in turn receives already aggregated data and broadcasts it via Direct Gateways directly to users (managed by the RedStone team) or via Streamr gateways, which also deliver data to consumers, but also has an additional function: temporary storage of data while waiting for a user response. Managed by the decentralized Streamr network.
The last module of DDL is the specially developed Arweave Network, which archives all data in its own network.
Data consumption
This module is the last link in the chain and can be subdivided depending on the model of RedStone integration into the corresponding protocols:
RedStone Pull Model.
RedStone Push Model.
RedStone X model.
It is recommended to use the innovative Pull Model, since it dynamically enters data into user transactions, achieving maximum gas efficiency.
In conclusion, I would like to say that the RedStone modular structure is a universal structure that will suit almost any blockchain. At the same time, the use of this oracle will reduce gas prices for transactions and provide greater security for protocols in case of possible exploits.
Website: http://redstone.finance
Blog: http://blog.redstone.finance
Twitter: https://x.com/redstone_defi
Standard oracles. Updating features or adding new services requires changes to the entire architecture. Chainlink is not always quick to adapt to new requirements or technologies.
Modular oracles. Each module can be updated individually without affecting other components.
Standard oracles. Updating features or adding new services requires changes to the entire architecture. Chainlink is not always quick to adapt to new requirements or technologies.
Modular oracles. Each module can be updated individually without affecting other components.
No activity yet