Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the submission method of Dapp Demo contract transaction in Bytom". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the submission method of Dapp Demo contract transaction in Bytom".

A brief introduction to the savings dividend contract

In order to facilitate understanding, here briefly talk about the content of the savings dividend contract, you can check the details of the savings dividend contract, savings dividend, as the name implies, when a certain period of time, according to the proportion to return the meaning of principal and interest, so demo is divided into saving (savings) and profit (withdrawal) two pages, the content of this chapter is for the submission of contract transactions, so only for savings page description.

Compared to the original official Dapp-demo instructions

Than the original official demo address

1) for access, you need to use chrome to open the original official demo address, install the bycoin plug-in and search in the App Store.

2) after installing bycoin, you need to initialize user information, create or import backup files to restore users

3) enter the specified number of assets and click OK

4) Pop-up the special page for contract transaction, fill in the password, and click OK

5) View the transaction flow

Front-end source code analysis

Source code: the front-end source code of the savings dividend contract (this chapter explains the latest version of the code on July 10, 2019)

The front-end code is based on the front-end framework react, which is easy to read. The structure is as above. Let's take a look at the savings page (saving) Bytom-Dapp-Demo1\ src\ components\ layout\ save\ index.jsx

/ / the submitted method FixedLimitDeposit (amount, address) / / # 1. Then () = > {/ / # 2. This.refs.btn.removeAttribute ("disabled"); this.setState ({error:'', msg: `Submit submission submission examples! You spent ${amount} deposite asset,and gain ${amount} billasset.`}) .catch (catch = > {/ / # 3. This.refs.btn.removeAttribute ("disabled"); this.setState ({error:err, msg:''})})

1) received the amount of the input box and the address of the current user

2) prompt content after success

3) prompt content after failure

Next, come to the FixedLimitDeposit method.

Export function FixedLimitDeposit (amount, address) {const object = {address: address, amount: amount, parameter: [amount, address]} return submitContract (listDepositUTXO, createContractTransaction, updateDatatbaseBalance, object) / / # 1.}

The three method bodies passed in are listDepositUTXO (to find all the UTXO of the current contract), createContractTransaction (to create the contract parameters before submission), and updateDatatbaseBalance (to update the user's submission list)

Enter the submitContract method of Dapp-Demo1\ src\ components\ layout\ save\ action.js

Return new Promise ((resolve, reject) = > {/ / list available utxo return listDepositUTXO () .then (resp = > {/ / # 1. / / create the ContractTransaction return createContractTransaction (resp, amount) Address) .then (object = > {/ / # 2. Const input = object.input const output = object.output const args = object.args const utxo = object.utxo / / Lock UTXO return updateUtxo ({"hash": utxo}) / / # 3. Then () = > {/ / Transactions return window.bytom.send_advanced_transaction ({input) Output, gas: GetContractArgs (). Gas*100000000, args}) / / # 4. Then ((resp) = > {/ / Update Balance return updateDatatbaseBalance (resp) .updateParameters) .then (() = > {/ / # 5. Resolve ()}) .catch (err = > {throw err})}) .catch (err = > {throw err.message}) ) .catch (err = > {throw err})}) .catch (err = > {throw err})}) .catch (err = > {reject (err)})})

First, call listDepositUTXO to get the information of all the UTXO locked by the current savings, which will be explained in detail later.

2) call the createContractTransaction method to assemble the corresponding information parameters of the contract

3) after selecting the UTXO to be used, call updateUtxo to tell bufferserver that the UTXO is already in use and change the state to prevent others from calling

4) execute the window.bytom.send_advanced_transaction method. Refer to the plug-in wallet API, which is the advanced transaction method. This is the native method of the bycoin plug-in. Call up the page that submits the transaction and let the user enter the password.

5) after the transaction is confirmed, call updateDatatbaseBalance to submit the data to the backend

Let's take a look at the listDepositUTXO method of api.js. All interfaces that interact with bufferserver are written into this file:

Function listDepositUTXO () {return listDappUTXO ({/ / * 1. "program": GetContractArgs () .depositProgram, "asset": GetContractArgs () .assetBill, "sort": {"by": "amount" "order": "desc"})} / / Api call from Buffer serverexport function listDappUTXO (params) {let url switch (window.bytom.net) {case "testnet": url = "/ dapptestnet/list-utxos" break default: url = "/ dapp/list-utxos"} return post (url, params) .then (resp = > resp.data)}

Obviously it ends up calling the / list-utxos method of bufferserver, which is very simple, and it's worth mentioning that

1) the structure in it looks for UTXO based on program (contract code) and asset (asset ID). In fact, the bottom layer calls the official blockcenter API, which will be described later.

Go ahead and look at the createContractTransaction method of Dapp-Demo1\ src\ components\ layout\ save\ action.js

Function createContractTransaction (resp, amount, address) {return new Promise ((resolve, reject) = > {/ / utxo pre calculation const limit = GetContractArgs (). Radio * 100000000 / / * 1. If (resp.length = 0) {reject ('Empty UTXO info, it might be that the utxo is locked. Please retry after 60s.')} else if (amount)

< limit) { reject( `Please enter an amount bigger or equal than ${limit}.`) } const result = matchesUTXO(resp, amount) //****** 2. const billAmount = result.amount const billAsset = result.asset const utxo = result.hash //contract calculation if (amount >

BillAmount) {reject ('input amount must be smaller or equal to' + billAmount +'.)} else {const input = [] const output = [] const args = contractArguments (amount, address) / / * 3. Input.push (spendUTXOAction (utxo)) / / * 4. Input.push (spendWalletAction (amount) GetContractArgs () .assetDeposited) / / * 5. If (amount

< billAmount) { //****** 6. output.push(controlProgramAction(amount, GetContractArgs().assetDeposited, GetContractArgs().profitProgram)) output.push(controlAddressAction(amount, billAsset, address)) output.push(controlProgramAction((BigNumber(billAmount).minus(BigNumber(amount))).toNumber(), billAsset, GetContractArgs().depositProgram)) } else { output.push(controlProgramAction(amount, GetContractArgs().assetDeposited, GetContractArgs().profitProgram)) output.push(controlAddressAction(billAmount, billAsset, address)) } resolve({ //****** 7 input, output, args, utxo }) } })} 这个方法比较复杂，我们一步一步来 这里先看看 7），最终返回的内容是 input、 output、 args、 utxo， 跟发送交易页面里面的input、 output、 args对应起来，如 图K (图K) 上一章说过，所有比原链的交易都要存在质量守恒定理，input与output的总和要相对应，合约交易里面执行方法必须需要参数，这里的args就代表传入的参数，utxo是代表 utxo的id 1）做一下限制，设置最少值 2）matchesUTXO ，根据上面的内容，刚刚已经通过listDepositUTXO 拿到所有可用的UTXO列表，这个时候要根据用户输入的数额amount，选择一个起码 大于或等于的 amount 的UTXO出来； 3）contractArguments ，构建args，就是合约里面方法的参数； 4）通常合约交易会有自己资产的input，合约UTXO的input，这里是要解锁的utxo的input； 5）这个是钱包资产的input； 上一章内容说过，解锁合约的交易，必须根据合约里面的逻辑，计算出对应的结果，所以这里的逻辑跟合约里面逻辑是一样的，储蓄分红合约详细说明 如图； 判断逻辑一样，这里插件钱包跟上一章说的pc钱包接口的结构有所不同，但是原理一样。 最后我们看看src\components\layout\save\action.js 的updateDatatbaseBalance 方法 function updateDatatbaseBalance(resp, amount, address){ return updateBalances({ "tx_id": resp.transaction_hash, address, "asset": GetContractArgs().assetDeposited, "amount": -amount }).then(()=>

{return updateBalances ({"tx_id": resp.transaction_hash, address, "asset": GetContractArgs () .assetBill "amount": amount}) .catch (err = > {throw err})} export function updateBalances (params) {let url switch (window.bytom.net) {case "testnet": url = "/ dapptestnet/update-balance" break default: url = "/ dapp/update-balance"} return post (url, params)}

Bufferserver is also called. Here, the update-balance method is called to submit the successful transaction to the backend.

Summary

The above introduces the content of the dapp-demo front-end code, introduces the methods inside, except for the plug-in api call is more complex, the other are ordinary application logic calls, mainly understand the mass conservation theorem, the rest are data audit data, very simple.

The pit encountered

Readers with application development should be able to understand the core of the problem at once. I'm talking about the hole in it now.

1) the UTXO locking interface is easy to be brushed; if one of my developers knows this interface and swipes your interface to lock the UTXO of the application, the application will be paralyzed for a long time.

Solution: this should be considered in terms of application, such as adding some one-time CAPTCHA to the interface, refer monitoring, authorization and so on, and transaction monitoring at the back end to maintain the state of UTXO in various situations, which is abstract and complex, but it is necessary.

2) concurrency problem; like 1), even if I am a normal user and choose a UTXO to unlock, I unexpectedly tell the backend to lock it through the http interface and call up the input password page (figure K). At this time, if the user does not enter the password and does not submit, the UTXO on the original chain is not unlocked, but the bufferserver will be locked.

Solution: the backend source code is locked for a period of time, and if it is not used, it will be unlocked regularly. This situation also requires monitoring judgment of the application to maintain the status of all utxo. It is personally recommended that when issuing contracts, multiple UTXO locking contracts will be issued, and more UTXO will be available. At this time, some students asked, isn't TPS just as low? if you have used hot coins, you will know. Blockchain trading does not pay much attention to TPS, and the trading of hot coins must be more than 60-100 blocks in order to determine a transaction, which depends on how the application developers judge and choose.

3) the user's transaction information interface is easy to be brushed; like 1), after the transaction is completed, the data is submitted directly through the http interface. I am not a billionaire if I browse crazily.

Solution: if you want the user's transaction information and generate the transaction bill, you can directly use the plug-in interface, but you need to filter it out through the contract code. The author monitors all transactions in the blockchain browser and enters the database transaction table. In this way, all transactions can be monitored all the time.

4) easy to produce chain errors Here dapp-demo sends the UTXO of a contract. If a user submits a transaction, a new UTXO will be generated, but the UTXO has not been confirmed yet. The list-utxo interface of bufferserver will send the UTXO that has not been confirmed, thus solving the concurrency problem. But I, a developer, know the code of the contract and casually write a transaction to submit. Although it will certainly fail, it will take time. At this time, bufferserver also returns the UTXO that is certain to fail to the front end, generating a bunch of transactions in a chain, which is easy to cause chain failure.

Solution: 1) here I have discussed deeply with the boss of the original government. The best solution is, of course, to set a password for the contract itself. The input parameters must be encrypted by incode according to this password, and the contract transaction parameters must be passed into the contract. When the contract itself is interpreted, it is decrypted and verified by decode to ensure that the entry and exit parameters are official, so that no one will attack. However, the conclusion is that the contract engine of the original chain does not support it for the time being.

2) be sure to hide the contract logic, so that others cannot use it maliciously, for example, the front-end code is confused, or the args parameter is generated at the back end. In addition, it is recommended to encrypt the contract logic than the build-transaction API parameter of the original blockcenter.

Thank you for reading, the above is the content of "what is the submission method of Dapp Demo contract transaction in Bytom". After the study of this article, I believe you have a deeper understanding of what the submission method of Dapp Demo contract transaction in Bytom is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.