Skip to content
This repository has been archived by the owner on Aug 6, 2023. It is now read-only.

Commit

Permalink
check grammar
Browse files Browse the repository at this point in the history
  • Loading branch information
evilpeach committed Sep 21, 2021
1 parent 1b8bbb4 commit ae6baee
Show file tree
Hide file tree
Showing 3 changed files with 22 additions and 22 deletions.
24 changes: 12 additions & 12 deletions docs/introduction/oracles-and-bandchain.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,43 +25,43 @@ First, BandChain is operated by a globally distributed pool of validators, whose

When a data request is made, it is these validators that will be responsible for fetching the results.

The results reported by the validators are also taken from multiple data sources, which acts as our second layer of redundancy. Further, BandChains delegated proof of stake design further help ensure that these validators have monetary incentives to properly and correctly report the data, or risk losing the capital theyve staked as well as their reputation.
The results reported by the validators are also taken from multiple data sources, which acts as our second layer of redundancy. Further, BandChain's delegated proof of stake design additionally helps ensure that these validators have monetary incentives to properly and correctly report the data or risk losing the capital they've staked as well as their reputation.

Finally, **the entire data request flow itself are also publically available to be viewed**, verified, and audited by anyone.

## Flexibility

Our data source scripts and oracle scripts allow **maximum customization and flexibility** for user to query and compute their desired data feed.
Our data source scripts and oracle scripts allow **maximum customization and flexibility** for the user to query and compute their desired data feed.

![Flexibility](https://i.imgur.com/HATQRq7.png)

Data sources are the most fundamental unit in BandChain's oracle system. It specifies the primary source from which BandChains validators will retrieve data. Here users can freely specify where the datasources come from.
Data sources are the most fundamental unit in BandChain's oracle system. It specifies the primary source from which BandChain's validators will retrieve data. Here users can freely select where the data sources come from.

An Oracle script is then the pieces of code that defines the logic of the data request. In particular, the script specifies two things:
An Oracle script is then the piece of code that defines the logic of the data request. In particular, the script specifies two things:

- the set of data sources that the validators will query data from
- the method in which to aggregate the result from those data sources into the final result

These oracle scripts themselves can be programmed in multiple programming languages, and act very much similar to smart contracts.
These oracle scripts can be programmed in multiple programming languages and act very similar to smart contracts.

## Scalability

Unlike general-purpose blockchains, **BandChain is specifically designed for oracle data request and computation**. This is clearly reflected in the the benefits it provides.
Unlike general-purpose blockchains, **BandChain is designed explicitly for oracle data request and computation**. This is reflected in the benefits it provides.

For one, an average block time of only 3 seconds, compared to Ethereums 10-15 and Bitcoins 10 minutes means that data request transactions are both received and resolved very quickly.
For one, an average block time of only 3 seconds, compared to Ethereum's 10-15 and Bitcoin's 10 minutes, means that data request transactions are both received and resolved very quickly.

![Scalability](https://i.imgur.com/Ck58iXa.png)

Not only that, we are also able to **offload all the heavy oracle computations from the requesters chain and onto BandChain**, which have been specifically optimized for these sorts of computations.
Not only that, but we are also able to **offload all the heavy oracle computations from the requester's chain and onto BandChain**, which have been specifically optimized for these sorts of computations.

All this boils down to the fact that an average data request to BandChains oracle can be expected to resolve in less than 6 seconds.
All this boils down to the fact that an average data request to BandChain's oracle can be expected to resolve in less than 6 seconds.

This allows BandChain Oracle to continuously upgrade throughput capacity with the same base-level infrastructure
This allows BandChain Oracle to continuously upgrade throughput capacity with the same base-level infrastructure.

Having our own chain also means that the oracle core logic and operations does not need to duplicated itself onto a new chain or App for each integration, making integration with DApps scalable and streamlined.
Having our own chain also means that the oracle core logic and operations do not need to be duplicated onto a new chain or App for each integration, making integration with DApps scalable and streamlined.

## Cost

Finally, theres the issue of cost. Bands oracle allows anyone looking to request data to do so only when they need to, and pay the associated fees on a per-request basis. This is significantly more economical than having to say, update the price of an entire set of assets when in fact you might currently only need the latest price of one.
Finally, there's the issue of cost. Band's oracle allows anyone looking to request data to do so only when they need to and pay the associated fees on a per-request basis. This is significantly more economical than having to, say, update the price of an entire set of assets when in fact, you might currently only need the latest price of one.

![Cost](https://i.imgur.com/S0ZK9JM.png)
8 changes: 4 additions & 4 deletions docs/introduction/oracles.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,20 +4,20 @@ order: 2

# The Need for Oracles

Smart contracts are great at immutable storage and verifiable transaction, but their use cases have previously been restricted due to their access to outside data. **Most blockchains are neither aware of anything going on in the real world**, nor can they access any data not native to the chain itself.
Smart contracts are significant at immutable storage and verifiable transaction, but their use cases have previously been restricted due to their access to outside data. **Most blockchains are neither aware of anything going on in the real world**, nor can they access any data not native to the chain itself.

![](https://i.imgur.com/SNgKRyU.png)

The data that they could not previously access includes any data available on the traditional web, as well as those accessible through APIs. When you start to consider just how many of the products and tools we use today rely on these data, the problem becomes apparent.

While there have been a multitude of efforts to solve this issue, most of the solutions have come to meet at least one of three main limitations.
While there has been a multitude of efforts to solve this issue, most of the solutions have come to meet at least one of three main limitations.

![](https://i.imgur.com/cgHTeIb.png)

1. **Centralization**
Existing data solutions such as API feeds, and some other oracle solutions are centralized by design. This not only goes against the ideology of decentralization and trustlessness, but also represents a severe potential security flaw. Relying on a central authority to report data means that you are exposing yourself to the possibility of data manipulation and outages, both of which can have catastrophic implications on any services that depends on it, not to mention on the end users themselves.
Existing data solutions such as API feeds and some other oracle solutions are centralized by design. This not only goes against the ideology of decentralization and trustlessness but also represents a severe potential security flaw. Relying on a central authority to report data means that you are exposing yourself to the possibility of data manipulation and outages, both of which can have catastrophic implications on any services that depend on it, not to mention on the end users themselves.

2. **Network Congestion**
Most of the existing oracle solution of them are constrained by network congestion. This is mostly the result of the solution being on the same blockchain as the application itself -- competing for block order Thus if the blockchain’s network were to become full with pending transactions, the data request transaction themselves will also be delayed.
Most of the existing oracle solution of them are constrained by network congestion. This is mostly the result of the solution being on the same blockchain as the application itself -- competing for block order. Thus, if the blockchain’s network were to become full with pending transactions, the data request transaction themselves would also be delayed.

3. **High Cost** they are expensive. This comes from both the cost to research, develop, and deploy the solution, as well as the various costs associated with operating and maintaining it in the long run.
12 changes: 6 additions & 6 deletions docs/introduction/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,16 +4,16 @@ order: 1

# High-Level Overview

[Band Protocol](https://bandprotocol.com) is a cross-chain data oracle that aggregates and connects real-world data and APIs to smart contracts.
[Band Protocol](https://bandprotocol.com) is a cross-chain data oracle aggregating and connecting real-world data and APIs to smart contracts.

The protocol is built on top of [BandChain](https://cosmoscan.io), a Cosmos-SDK based blockchain designed to be compatible with most smart contract and blockchain development frameworks.
The protocol is built on top of [BandChain](https://cosmoscan.io), a Cosmos-SDK-based blockchain designed to be compatible with most smart contract and blockchain development frameworks.

The network is designed to modularize and offload the heavy and resource-intensive tasks (i.e. fetching data from external sources aggregating them) from the smart contract platforms onto itself. This not only prevent such tasks from congesting or causing high transaction fees on the destination network, but the same data points can be packaged, used, and verified efficiently across multiple blockchains.
The network is designed to modularize and offload the heavy and resource-intensive tasks (i.e., fetching data from external sources aggregating them) from the smart contract platforms onto itself. This not only prevents such tasks from congesting or causing high transaction fees on the destination network, but the same data points can be packaged, used, and verified efficiently across multiple blockchains.

Its flexible design allows developers to query any range of data types including both on-chain data (token balances, transaction data, etc.), real-world events (sport scores, flight status, weather, etc.), and any data that is available through the web or any other mediums (stocks/token prices, random numbers, etc.)
Its flexible design allows developers to query any range of data types, including both on-chain data (token balances, transaction data, etc.), real-world events (sports scores, flight status, weather, etc.), and any data that is available through the web or any other mediums (stocks/token prices, random numbers, etc.)

Since the [launch of our GuanYu mainnet](https://medium.com/bandprotocol/bandchain-phase-1-successful-mainnet-upgrade-and-guanyu-launch-ac2d0334da77) back in October 2020, we have seen exponential increase in adoption in diverse array of use cases. From applications in lending, money markets, gambling, asset and tokenization, to both on-chain and real-world insurance.
Since the [launch of our GuanYu mainnet](https://medium.com/bandprotocol/bandchain-phase-1-successful-mainnet-upgrade-and-guanyu-launch-ac2d0334da77) back in October 2020, we have seen an exponential increase in adoption in a diverse array of use cases. From applications in lending, money markets, gambling, asset, and tokenization, to both on-chain and real-world insurance.

With the **Phase 2 (Laozi) upgrade**, we aim to further expand the scope of what is possible with our oracle through multiple ways. Two in particular includes the option for data providers to receive payment directly on-chain from developers using their services on BandChain, and allowing for cross-chain oracle request through the [Inter-Blockchain Communication (IBC)](https://docs.cosmos.network/master/ibc/overview.html) standard.
With the **Phase 2 (Laozi) upgrade**, we aim to expand further the scope of what is possible with our oracle through multiple ways. Two, in particular, includes the option for data providers to receive payment directly on-chain from developers using their services on BandChain, and allowing for cross-chain oracle requests through the [Inter-Blockchain Communication (IBC)](https://docs.cosmos.network/master/ibc/overview.html) standard.

The new feature also enables a new cohort of products and services that Band oracle can provide to developers. Some examples of these are a more decentralized price oracle, verifiable randomness, and facilitating cross-chain communication.

0 comments on commit ae6baee

Please sign in to comment.