Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support ERC20 to Native #138

Merged
merged 54 commits into from
Oct 26, 2018
Merged

Add support ERC20 to Native #138

merged 54 commits into from
Oct 26, 2018

Conversation

patitonar
Copy link

This PR includes the following changes:

  • Get Bridge mode from contract method
  • Add check for fromBlock parameter to be > 0 on getPastEvents method
  • Add support ERC20 to Native mode
  • Add e2e tests for ERC20 to Native mode

Pending:

@ghost ghost assigned patitonar Oct 2, 2018
@ghost ghost added the in progress label Oct 2, 2018
@igorbarinov
Copy link
Member

igorbarinov commented Oct 2, 2018

Deploy preview for kind-kilby-95344f processing.

Built with commit 0ed18c7

https://app.netlify.com/sites/kind-kilby-95344f/deploys/5bcf108a67610c7a9cf926c6

@ghost ghost added the review label Oct 2, 2018
Copy link
Collaborator

@akolotov akolotov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you clarify the process what gas price is set for transactions in both networks? Currently it is possible to configure the speed chosen for the response of the gas price oracle. Will it affect the value on the window presented to the user? What value is used for the network if the gas price oracle is not configured or what will happen if the gas price oracle is not configured. Does it makes sense to introduce parameters to configure a fallback gas price?
This question is due to the fact that gas price in the shard we are creating could be 1000 gwei. I am curious if the legacy code still use the value in 1 gwei for Home network.

@@ -105,8 +100,6 @@ class TxStore {
web3.eth.getTransactionReceipt(hash, (error, res) => {
if(res && res.blockNumber){
if(res.status === '0x1'){
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

consider to compare the number 1 instead of the string in hexadecimal 0x1. The status code is not standardized well that is why some clients could return 0x01 (rskj for example).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@patitonar
Copy link
Author

Currently gas price is fetched from oracle, the same value is used for both networks. You can only configure the speed using REACT_APP_GAS_PRICE_SPEED_TYPE. There are no fallback values if oracle fails. So I think we should:

  • Add ability to use different oracle urls and speed for each network.
  • Get gas price from contracts for each network.
  • Add fallback gas price for each network on .env.

So same as it works on bridge-nodejs, we can use oracle's gas price, if cannot be obtained, use gas price from contract, if it also fails, use fallback gas price from .env.

Does it makes sense @akolotov ?

@akolotov
Copy link
Collaborator

akolotov commented Oct 5, 2018

Thank you for the investigation. This answer is exactly what I looked for. Let's implement this in this version of the Bridge UI.

@fvictorio fvictorio mentioned this pull request Oct 5, 2018
Also: check gas price in contract if oracle fails, and use fallback value
if that fails too.
@ghost ghost assigned fvictorio Oct 8, 2018
@ghost ghost added the in progress label Oct 8, 2018
@fvictorio
Copy link

@akolotov the last commit allows using a different gas price for home and foreign, calls the contract if the oracle fails, and uses a fallback value if that also fails.

The setHomeWeb3Promise is ugly, but it was the only way I found to avoid a circular dependency between stores.

@fvictorio
Copy link

@akolotov Also, notice that much of the logic here duplicates the one in bridge-nodejs. I think this is going to keep happening, and it's problematic. Maybe we should consider how to deal with that. Some options are moving everything (bridge, ui, monitor, contracts) to a monorepo, or creating a bridge-common package. If that sounds like a good idea to you, we can discuss it in an issue.

@@ -1,4 +1,4 @@
import { action, observable } from "mobx";
import { action, computed, observable } from "mobx";
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think computed is not used here, so we can avoid importing it

@patitonar
Copy link
Author

@akolotov I'm having the same issues as you with that chain on validators on status page. The way how validators are retrieved is by listening all ValidatorAdded and ValidatorRemoved events and then filtering only the ones that were added but not removed. In this case, in both cases doesn't find any event. Is validator contract properly set?

@ghost ghost added the in progress label Oct 10, 2018
@patitonar
Copy link
Author

@akolotov for now I added 3 digits after the point on network details you mentioned, I need to investigate best way to implement the logic you suggested after I finish with all of the issues

@ghost ghost removed the in progress label Oct 10, 2018
src/stores/utils/gas.js Outdated Show resolved Hide resolved
@ghost ghost added the in progress label Oct 11, 2018
foreignSymbol={foreignStore.symbol}
foreignSupply={foreignStore.totalSupply} />
</div>
<div className='statistics-transaction-container'>
<div className='statistics-deposit-container'>
<span className='statistics-deposit-title statistics-title'>Network Deposits</span>
<span className='statistics-deposit-title statistics-title'>Tokens Deposits</span>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic when we use erc-to-erc and erc-to-native modes are reversed.

  • native-to-erc: tokens are deposited by sending coins from Home and withdrawn by sending tokens from Foreign
  • erc-to-erc: tokens are deposited by sending tokens from Foreign and withdrawn by sending tokens from Home
  • erc-to-native: tokens are deposited by sending tokens from Foreign and withdrawn by sending coins from Home

The current layout of lables "Tokens Deposits" and "Tokens Withdrawals" confuses.
image
Since the amount of withdrawn tokens cannot be more than the amount of deposited tokens.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

src/stores/TxStore.js Outdated Show resolved Hide resolved
@ghost ghost removed the in progress label Oct 11, 2018
@ghost ghost removed the in progress label Oct 11, 2018
@ghost ghost added the in progress label Oct 11, 2018
@ghost ghost removed the in progress label Oct 23, 2018
@akolotov
Copy link
Collaborator

I think we can merge the changes to develop branch.

@akolotov akolotov merged commit c4ff4b6 into develop Oct 26, 2018
@ghost ghost removed the review label Oct 26, 2018
@akolotov akolotov mentioned this pull request Oct 26, 2018
@akolotov akolotov deleted the add-support-erc20-native branch May 24, 2019 06:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants