Merge pull request #20 from bandprotocol/update-onchain

remove request key
bandprotocol · Sep 17, 2021 · 1b8bbb4 · 1b8bbb4
2 parents d5ef93c + a1d7c93
commit 1b8bbb4
Show file tree

Hide file tree

Showing 2 changed files with 5 additions and 24 deletions.
diff --git a/docs/whitepaper/cosmos-ibc.md b/docs/whitepaper/cosmos-ibc.md
@@ -24,7 +24,6 @@ _This section presented an overview of how IBC can be used to make an oracle dat
 | AskCount       | uint64    | The number of validators that are requested to respond to this request                                                                                    |
 | MinCount       | uint64    | The minimum number of validators necessary for the request to proceed to the execution phase                                                              |
 | FeeLimit       | sdk.Coins | The maximum tokens that will be paid to all data source providers                                                                                         |
-| RequestKey     | string    | The key from the request chain which identifies the pool account on Bandchain to process data source fee                                                  |
 | PrepareGas     | uint64    | The amount of gas to pay to prepare raw requests                                                                                                          |
 | ExecuteGas     | uint64    | The amount of gas reserved for executing the oracle script during execution phase                                                                         |
 

diff --git a/docs/whitepaper/on-chain-payment-protocol.md b/docs/whitepaper/on-chain-payment-protocol.md
@@ -20,32 +20,14 @@ After the preparation step is complete, BandChain will obtain all the data sourc
 
 ## IBC request
 
-To make an oracle request via IBC, a communication channel needs to be created between a counterparty chain and BandChain, as stated in [IBC](./cosmos-ibc). The main obstacle when requesting from another chain is that the requester is an address on the other chain which cannot pay the data source fees on BandChain. Hence, a substitute account, called **pool account**, is necessary for paying the fees.
+To make an oracle request via IBC, a communication channel needs to be created between a counterparty chain and BandChain, as stated in [IBC](./cosmos-ibc). The main obstacle when requesting from another chain is that the requester is an address on the other chain which cannot pay the data source fees on BandChain. Therefore, the fees is instead paid by the account of a relayer that the counterparty chain used to send packets.
 
-A pool account is an address account owned by an entity from another chain (can be a specific to a person, or collectively represent a pool of fund from a chain based on the counterparty's design of keyrequest usage) that resides on BandChain.
-
-To identify which pool account to collect datasource fees from, we concatenate three components below and hash the concatenated result to get the pool address
-
-1. Request key that came within `OracleRequestPacketData`
-2. Oracle module's port ID which is `oracle`
-3. Channel ID on BandChain side of the communication with the requesting chain. This BandChain side's Channnel ID is identified from the channel ID of the requesting chain that was sent along with `OracleRequestPacketData`.
-
-Note that the uniqueness of the request key totally depends on the protocol of counterparty chains as stated above. For examples, a counterparty chain may have a single request key for one pool account for all users, or a counterparty chain may secretly generate a unique request key for each of its users.
-
-This ensures that if the very same user makes an oracle request again, the same pool account will be used to deduct the fees.
-
-For more detail regarding IBC channel, please consult Cosmos SDK's [IBC Channels](https://docs.cosmos.network/master/ibc/overview.html#channels).
-
-### Funding a Pool Account
-
-![onchain-request-pool](https://i.imgur.com/i8DHiDy.png)
-
-For the pool account to be able to pay data source fees, a fund provider which can be either a user or a counterparty chain based on the protocol is required to have a Band account. Then the provider uses that account to transfer some tokens into the pool account given the request key, port ID, and channel ID.
+The relayer account is an address account owned by an entity from another chain since the chain has to be the one managing the relayer. Note that the method by which the users fund the relayer account will totally depend on the protocol of counterparty chains.
 
 ### IBC Request Payment Flow
 
-![onchain-ibc](https://i.imgur.com/4j2gxM4.png)
+![onchain-ibc](https://i.imgur.com/GJMo8Df.jpg)
 
-Once the pool account is set up, the payment flow for IBC requests is very similar to that of the direct request. The additional layer is that the flow starts from a user on the counterparty chain. The request is then relayed from the counterparty chain to BandChain via a relayer through a specific port and channel.
+Once the relayer account is funded, the payment flow for IBC requests is very similar to that of the direct request. The additional layer is that the flow starts from a user on the counterparty chain. The request is then relayed from the counterparty chain to BandChain via a relayer through a specific port and channel.
 
-After BandChain receives the request via a relayer, the payment flow is almost identical to the payment flow of direct request, except the account used for paying all the fees now is the pool account.
+After BandChain receives the request via a relayer, the payment flow is almost identical to the payment flow of direct request, except the account used for paying all the fees now is the relayer account.