1

我想在我的 dapp 中实现一个流程，我会很感激一些意见。

流动：

用户看到一个产品列表并选择一个来购买它。用户的元掩码已解锁并有足够的余额。

设置：

后端的 Rails，前端的 React，ganache-cli，truffle，metamask (web3js)。

数据库结构：

在应用程序的内部 PostgresDB 中，有一个products表。在区块链中，有一个动态数组products，如下所示：

内部 Postgres：

products
  name
  price
  owner_id

owners
  name
  id
  address

区块链（合约存储）

Product[] products
struct Product {
  name
}
mapping(uint => address) public productIdToOwner;
mapping(uint => uint) public productIdToPrice;

onBuy当用户单击“购买此产品”按钮时，将运行以下函数：

onBuy = (product) => {
  const { id, external_id, name, price, meta } = product

  this.ContractInstance.methods.buy(external_id).send({
    from: this.state.currentUserAddress,
    gas: GAS_LIMIT,
    value: web3.utils.toWei(price.toString(), "ether"),
  }).then((receipt) => {
    // What to do before getting a receipt?
    console.log(receipt)
  }).catch((err) => {
    console.log(err.message)
  })
}

问题：

  • 在主网上，我需要多长时间才能获得交易收据？onBuy单击带有加载轮的按钮直到收据到达后让用户在同一页面上等待是否明智？如果不是，那么处理这个问题的常规方法是什么？

  • 我的数据库结构是连接区块链的合理方式吗？我担心数据完整性（即必须address在我的内部数据库和区块链之间同步字段），但我发现将区块链数据存储在内部数据库中很有用，并且主要从内部数据库而不是区块链读取。

4

1 回答 1

0

On the mainnet, how long does it take for me to get the receipt for the transaction? Is it sane to make the user wait on the same page after clicking the onBuy button with a loading wheel until the receipt arrives? If not, what's the conventional way to deal with this?

When you send a transaction, you will get the transaction hash pretty quickly. However, the receipt is only returned once the transaction is mined. The length of time it takes to have your transaction mined varies greatly depending on how much you're willing to pay for gas (can be several seconds for very high gas prices or can be several hours if you're paying < 10 Gwei). You can get an idea by using Ropsten/Rinkeby (the test networks will probably be faster than MainNet). Chances are (and based on the system you're describing), it won't be reasonable to have your user wait.

I don't know if there is a "conventional" way to deal with this. You can provide the user with your own confirmation number (or use the transaction hash as the confirmation number), send an email when the transaction is mined, push a notification if on a mobile app, etc. If you present the user with some sort of confirmation number based on the transaction hash, you'll have to decide how you want to resolve cases when the transaction fails.

Is my DB structure a reasonable way to connect to the blockchain? I am worried about data integrity (i.e. having to sync address field between my internal DB and the blockchain) but I find it useful to store the blockchain data inside the internal DB, and read mostly from the internal DB instead of the blockchain.

This is purely an opinion, so take this with a grain of salt. I try to avoid having duplicate data, but if you're going to have multiple persistence layers you'll probably need to maintain some sort of referential integrity between them. So, it's certainly ok to store ids and addresses.

The part of your question that confuses me is why do you prefer to read mostly from the DB? Have you tried measuring the latency of using a fully sync'ed node on your server and retrieving data from your contract through constant functions? I would test that first before duplicating my data. In your case, I would look to use the blockchain to store purchases while using the DB just for inventory management. But, that's based on very little knowledge of you business case.

于 2018-02-05T06:54:04.593 回答