比原链bytom
TA的个人档案
比原链bytom个人页面-阿里云开发者社区
文章
67
问答
0
个人介绍
比原链（Bytom）是一种多样性比特资产的区块链交互协议。官方QQ群：144860289
擅长的技术
- Java
- Python
- Go
- 前端开发
- 容器
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2019-12-27
社区观点 | 理解比原链MOV链上交换协议
去中心化交换协议的发展 从Bitshare，Stellar到以太坊上的Etherdelta，Bancor，0x协议，去中心化交换协议也经过了好几代发展和很多模式的探索，每一代都通过前面的协议的痛点来进行改进和深化， 主要分为： 链上orderbook，链上结算; 链下orderbook，链上结算; 基于智能合约管理的资金池; 链上orderbook，链上结算 最早的 基于以太坊的去中心化交换协议的成功探索非Etherdelta莫属，曾一度占据去中心化交换市场的半壁江山。Etherdelta是较为完全的去中心化模式，用户充值、挂单、吃单、结算及提现全部在链上完成。 具体运行机制如下： Etherdelta的整个运行都在链上完成，用户保管自己的私钥，平台不会触碰用户资产，保证了资产和交换的安全、透明。但其弊病也较为明显： 1) 由于所有的交换环节都在链上完成，且每一个挂单、撤单、吃单等操作都会消耗GAS费用，导致延时高、成本效益低下。 2) 存在矿工非法预先交换的可能。 链下orderbook，链上结算 为了解决纯链上效率低下，且手续费低廉的问题，0x协议引入了relayer(中继)的概念，所有订单都发给relayer，无需上链，只有成交才会上链。 0x的“链下订单中继、链上最终结算”运作模式如下： 0x协议的主要问题在于，如果需要共享订单，运用0x协议的交易所每一笔成交都需要广播出来，以便其他交易所得知和确认，因此单纯地使用0x协议无法实现瞬时成交；另外，由于需要将ETH转化为WETH，也增加了交换成本。 基于智能合约管理的资金池; 最具典型的资金池模式有Bancor和Kyber。所谓资金池，可以理解为平台利用智能合约建立了一个用于储备各类资产的池子，资金池中资产的提供方可以是普通用户或者做市商。 MOV去中心化交换协议介绍 我们在考察各个交换协议时，其实纯链上交换协议才是最发挥区块链价值的方案，但是因为以太坊等公链性能问题，导致像Etherdelta这样的纯链上方案受挫，才有0x这样的链下orderbook出现，来改善性能的问题。究其根本，是本身的基础设施不完善，导致的迫不得已的改变。所以比原链MOV从一开始就先着手解决区块链性能问题。 高速侧链是保障 MOV采用了高速侧链Vapor pro作为底层的基础设施，Vapor每0.5s出块，每个区块可以容纳8000笔交易，即每秒16000 tps，在增大区块，提升节点服务器的情况下，仍然有进一步提升空间。这个性能能够满足当前非高峰时段的用户需求，可以比肩部分的中心化的方案。 同时MOV采用了DPoS作为共识机制，虽然丧失了一定的去中心化，但是增加了可以进行链上撮合的门槛，提高准入门槛可以更好的防止部分有不良企图的“矿工”进行预先交易，同时因为链上撮合本身具有一定的撮合收入，所以通过这个经济激励可以防止DPoS的出块节点作恶来破坏系统（其作恶的成本高于其不作恶的正常收益）。 订单共享 0x协议为了解决性能问题，所以采用链下orderbook，但带来的问题就是订单的割裂，采用0x协议的各个不同参与方，为了自己的利益，必然不会将自己用户的订单共享出来，从而影响整体的交易深度，而mov采用链上orderbook，所有的用户订单都在链上，公开透明，所有参与撮合的共识节点都可以共享这个深度，从而增强mov上资产的流动性。 磁力合约的优势 因为比原链是基于比特币的UTXO模型，所以在UTXO模型上的磁力合约来做交换协议具有更大的优势，因为UTXO模型本身以资产为基本单位，和账户模型相比，对于资产的操作更加简易和方便，我们来对比两者的流程。 以0x为例，0x整个交互流程： Maker授权DEX合约访问自己的Token A余额 Maker创建订单（订单有固定的格式）并用私钥签名 Maker使用任意通信手段广播订单 Taker接收订单并愿意执行 Taker授权DEX合约访问自己的Token B余额 Taker提交订单给DEX DEX验证订单的合法性，在两个账户之间按照订单上的汇率进行转账 那么磁力合约的整个流程就简易很多： Maker创建一个磁力合约（在磁力合约中放入自己的资产，并指定要兑换的资产和数量） Taker创建一个磁力合约（在磁力合约中放入自己的资产，并指定要兑换的资产和数量） 共识节点根据合约中的价格和数量，触发能够匹配的磁力合约，并交换两者的资产。 不仅在流程上简单，手续费因为流程的简化也会更低，我们只要在用户设置磁力合约的时候收取手续费即可，事实上，我们还可以尝试0手续费，因为使用DPoS的模式，关于手续费，各个节点之间的博弈也不会太复杂。 跨链资产的生态 我们观察现行以太坊上的去中心化交换协议，还停留在以太坊本身的生态上，虽然不能否认以太坊生态的强大，但其实外面才是更大的世界，当然跨链是后续的主旋律，包括Cosmos和Polkdot都是想做跨链的事情，所以MOV在一开始就考虑到了跨链的事情，通过OFMF将比原链之外的资产映射到比原链上来，然后形成囊括所有数字资产的大生态，用户在mov中体验的是跟中心化一样的体验，可以交易多种资产，这些资产也不单独是在某一个链的生态。 MOV磁力合约详解 这里再详细展开一下MOV磁力合约，看它到底是如何实现的。 MOV磁力合约本质上是一个挂单合约，不管是Taker还是Maker都需要生成这样的一个合约，本质上其实并不区分Maker和Taker，只是根据挂单的先后来区分Maker和Taker，两者在相反的交易对上提升了交易深度，实际上也可以认为都是Maker。 挂单交易合约是高级版的币币交易合约，合约的本质目的是锁定任意数量的资产A，愿意以某特定的汇率兑换资产B。合约的内部应该保存有四个常量（资产A的ID不需要存因为合约锁定的是资产A）：期望兑换的资产B的ID, 期望兑换的汇率（使用分子分母方式解决浮点支持问题），和挂单用户的公钥，挂单用户接受资产B的地址。合约可以通过三种模式解锁： 全部解锁：所有合约中的资产A都被兑换成了资产B并转入挂单用户的地址中。 部分解决：部分合约中的资产A被兑换成了资产B并转入挂单用户的地址中，剩余的资产A通过递归合约的模式从新锁定回合约本身（新生成的UTXO）。 取消挂单：挂单用户通过私钥签名将合约中的资产A都转回自己的地址。 磁力合约Equity的代码如下： MagneticContract source code: contract MagneticContract(requestedAsset: Asset, ratioNumerator: Integer, ratioDenominator: Integer, sellerProgram: Program, standardProgram: Program, sellerKey: PublicKey) locks valueAmount of valueAsset { clause partialTrade(exchangeAmount: Amount) { define actualAmount: Integer = exchangeAmount * ratioDenominator / ratioNumerator verify actualAmount > 0 && actualAmount < valueAmount lock exchangeAmount of requestedAsset with sellerProgram lock valueAmount-actualAmount of valueAsset with standardProgram unlock actualAmount of valueAsset } clause fullTrade() { define requestedAmount: Integer = valueAmount * ratioNumerator / ratioDenominator verify requestedAmount > 0 lock requestedAmount of requestedAsset with sellerProgram unlock valueAmount of valueAsset } clause cancel(sellerSig: Signature) { verify checkTxSig(sellerKey, sellerSig) unlock valueAmount of valueAsset } } fullTrade()就是全部解锁方法；partialTrade()是部分解锁，当触发部分解锁时，会讲为解锁的资产放入一个新生成磁力合约中去，从而等待下一次匹配；cancel()方法将用户的资产转回自己的地址，取消这个合约。 我们在看看磁力合约的输入参数： type MagneticContractArgs struct { RequestedAsset bc.AssetID RatioMolecule int64 RatioDenominator int64 SellerProgram []byte SellerKey []byte } RequestedAsset是想要兑换的的资产，RatioMolecule，RatioDenominator是想要兑换资产的汇率（RatioMolecule/RatioDenominator 就是汇率），因为当前BVM不支持浮点型，所以额外采用这个参数作为比例，SellerProgram，SellerKey就是合约创建者自己的合约和地址，目标资产就要锁定到合约创建者自己的账户里面。细心的朋友可能发现，这里面和Equity合约少了一个参数，也就是standardProgram，那么这个参数不用用户自己输入，系统会默认补齐，standardProgram 其实就代表原合约，因为部分匹配会使一部分资产仍然没有使用，就仍然返回到合约中。 最后通过一张图来更直白的描述一下磁力合约： 总结 我们来对比一下当前的几种去中心化交换协议： 交换协议 模式 去中心化程度 成本效益 用户体验 Etherdelta 链上orderbook，链上结算 ★★★★★ ★ ★★ 0x 链下orderbook，链上结算 ★★★★ ★★★ ★★★★ Bancor 基于智能合约管理的资金池 ★★ ★★★ ★★★★ mov 链上orderbook，链上结算 ★★★ ★★★★ ★★★★★ 最早的完全去中心化交换协议Etherdelta对交换的干扰最少，但完全上链的机制使得成本消耗高且体验较差。之后的几类去中心化交换协议可谓都是在鱼和熊掌之间权衡取舍：Bancor和kyber为代表的储备池模式，管理员在整个过程中参与度较高，如果储备池合约中管理员权限较高比如之前Bancor可以提走用户资产，将会对用户的资金安全造成威胁；二者上链过程比较简单，成本控制表现不错，交易效率也比较高，只是功能性与有orderbook的交换协议相比略逊一筹。0x的中继模式，平台不触碰用户资产，相对而言去中心化程度是较高的，但这也导致成本效益相对较低；交体验整体不错，但如果需要共享订单，就无法实现瞬时成交。 mov在结合这几个前人的基础上，通过提升基础设施的性能，通过DPoS提升撮合准入门槛，并实现链上订单共享，还很好的提升了用户体验，除了通过DPoS牺牲了一定去中心化外，在其他方面都得到了一定提升，随着mov的进一步开发和完善，必将发挥该方案的优势，从而让区块链能在资产交换领域发挥巨大的价值，能够让去中心化的资产兑换落地。
-
发表了文章 2019-11-26
比原链CTO James | Go语言成为区块链主流开发语言的四点理由
11月24日，比原链CTO James参加了Go中国举办的Gopher Meetup杭州站活动，与来自阿里、网易的技术专家带来Kubernetes、区块链、日志采集、云原生等话题的分享。James向大家介绍了Go语言特性在区块链中的应用还分析了Go语言成为区块链主流开发语言的原因。 比原链的系统架构 在区块链系统中内核层是最核心的，他承接了区块验证、交易验证、节点维护、打包挖矿等重多职责。通信层掌管了区块链系统的网络服务，区块链的网络更像P2P的网络形式，他呈网状扩散，负责区块同步、交易同步、节点发现等重要的功能。钱包层是直接和用户发生交互的一层，他的职责是资产管理、私钥管理，并与内核层通信验证区块交易。 以Bytom为例，他的内核层分为了五个的模块。我们举例描述几个主要的模块。 孤儿块管理：孤儿块就是由矿工挖出但未成为主链区块的区块（在相同高度产生2个甚至更多的合法区块，一个区块成为主链，剩下的则称为孤儿块），孤儿块管理就是将未成为主链区块的孤儿块存储起来。举个例子，我现在挖到的区块是100，那么下一个区块理论上是101，但是在网络层发生延时的时候，可能会发生先出102再出101的情况，那么孤儿块管理会将这些父块未到的子块先缓存起来。 共识层：确认一个块是否合法。分为区块头验证和交易验证。区块头验证需要验证它的父块和时间戳，同是需要算力来保证记账权利。交易验证比原特别的设计了一层BC层，这层在交易验证时会获得更好的性能，交易验证还和智能合约相关，交易被验证时参数会参入虚拟机验证该交易是否合法。 区块树管理：又称为Block Index，作用是记录全网所有的块，保存了全网所有块的一张镜像图。因为有孤儿块，所有它并不是链式结构的，会有分叉的情况，所以称为区块树。举个例子，区块树管理好比有一个分布式系统，但无法保证每个节点的状态一致，可能会出现同一个高度产生同时参生区块的情况。区块树管理就是具备了在节点状态不一致的情况下让系统回滚到正确的区块这个功能。 数据存储：将区块数据做持久化存储。包含两种数据，第一种是区块数据，会在网络上进行广播的原生区块信息；第二种是UTXO数据，存储UTXO数据是为了更快的验证一笔UTXO是否可以花费，而不需要去遍历所有区块信息。 交易池：维护了所有全网发出的但是还未被确认的交易。跟它关联最大的是挖矿模块，挖矿模块每次要产生一个新区块的时候，它会从交易池拿一些交易打包成块，然后用Tensority共识算法进行工作量验算。举个例子，在节点打包交易之前，交易处在一个未确认的状态之下，交易池会将这些未确认的交易保存起来，分配给后面的矿工用于打包。 WHY GOLANG? 第一点，区块链是多模块异步协同工作的，分成了P2P层、钱包层、内核层。其中内核层、情报层里面都有不同的很多子模块，在负责不同的事情。Go语言做得很出色非常适合做这方面的开发。 第二点，区块链项目有核心团队但是主要还是依赖社区参与，Go语言编译上相对于其他语言稍微严格一点，在制定规范后可以使不同开发者代码风格相近，有利于协同工作的展开。 第三点，Go语言社区完善，有很多非常好的开源库支持，使用起来非常方便用户体验良好。 第四点，主流语言的头部效应，在区块链的项目里面超过85%的项目都是基于Go语言开发的，大部分区块链工程师都擅长Go语言，所以当新的项目开始的时候，会首选Go语言。 对区块链感兴趣的程序员可以投递简历至：james@bytom.io
-
发表了文章 2019-08-28
Bytom Dapp 开发笔记（三）：Dapp Demo前端源码分析
本章内容会针对比原官方提供的dapp-demo，分析里面的前端源码，分析清楚整个demo的流程，然后针对里面开发过程遇到的坑，添加一下个人的见解还有解决的方案。 储蓄分红合约简述 为了方便理解，这里简单说说储蓄分红合约的内容，具体可以查看储蓄分红合约详细说明，储蓄分红，顾名思义就是储蓄之后，当达到一定的时间，按照比例返回本息这样的意思，所以demo中拆分成saving（储蓄）与profit（提现）两个页面，本章内容是针对合约交易的提交，所以只针对储蓄页面说明。 比原官方Dapp-demo使用说明 比原官方demo地址 1）访问的前提需要用chrome打开比原官方demo地址，同时安装bycoin插件，在应用商店搜索就行； 2）安装完bycoin，需要初始化用户信息，新建或者导入备份文件去恢复用户； 3）填写指定资产数量，点击确定； 4)弹出合约交易专用页面，填写密码，点击确认； 5)查看交易流水 前端源代码分析 源码 ： 储蓄分红合约前端源代码 （本章内容讲解的是 2019年7月10号 最新版的代码） 前端代码是基于前端框架react去做的，很容易读懂，结构如上，我们来看看作为储蓄页面（saving）Bytom-Dapp-Demo1srccomponentslayoutsaveindex.jsx //提交后的方法 FixedLimitDeposit(amount, address) //####### 1. .then(()=> { //####### 2. this.refs.btn.removeAttribute("disabled"); this.setState({ error:'', msg:`Submit success!!! you spent ${amount} deposite asset,and gain ${amount} billasset.` }) }).catch(err => { //####### 3. this.refs.btn.removeAttribute("disabled"); this.setState({ error:err, msg: '' }) }) 1)接收了输入框的金额，还有当前用户的地址； 2）成功后提示内容； 3）失败后提示内容； 接下来到FixedLimitDeposit方法 export function FixedLimitDeposit(amount, address) { const object = { address: address, amount: amount, parameter: [amount, address] } return submitContract(listDepositUTXO, createContractTransaction, updateDatatbaseBalance, object) //####### 1. } 1) 传入三个方法体分别是 listDepositUTXO（查找当前合约所有的UTXO）， createContractTransaction（创建提交前的合约参数），updateDatatbaseBalance（更新用户的提交列表） 进入Dapp-Demo1srccomponentslayoutsaveaction.js 的 submitContract方法 return new Promise((resolve, reject) => { //list available utxo return listDepositUTXO().then(resp => { //####### 1. //create the Contract Transaction 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) }) }) 1) 首先调用listDepositUTXO 拿到当前节约锁定的所有UTXO的信息，待会详细说明； 2）调用 createContractTransaction 方法，组装好合约的对应信息参数； 3）选取要使用的 UTXO后，调用updateUtxo 告诉bufferserver ，该UTXO已经被使用，更改状态，防止其他人调用了； 4）执行window.bytom.send_advanced_transaction方法，参考插件钱包API，是高级交易方法，这个是bycoin插件的原生方法，调起 提交交易的页面，让用户输入密码； 5）交易确认后，调用 updateDatatbaseBalance 提交数据到后端； 再来看看api.js的listDepositUTXO 方法，所有与bufferserver交互的接口全部写到这个文件里面： function listDepositUTXO() { return listDappUTXO({//****** 1. "program": GetContractArgs().depositProgram, "asset": GetContractArgs().assetBill, "sort": { "by":"amount", "order":"desc" } }) } //Api call from Buffer server export 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) } 很明显最终是调用bufferserver的/list-utxos方法，非常简单，值得一提的是 1）里面的结构体根据program（合约代码）与asset（资产ID）去查找UTXO，这里其实底层是调用官方的blockcenter接口的，后面会细说； 继续看看Dapp-Demo1srccomponentslayoutsaveaction.js 的createContractTransaction方法 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； 6) 上一章内容说过，解锁合约的交易，必须根据合约里面的逻辑，计算出对应的结果，所以这里的逻辑跟合约里面逻辑是一样的，储蓄分红合约详细说明 如图； 判断逻辑一样，这里插件钱包跟上一章说的pc钱包接口的结构有所不同，但是原理一样。 最后我们看看srccomponentslayoutsaveaction.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，这里是调用update-balance方法，把成功后的交易提交到后端。 小结 上面介绍了dapp-demo前端代码的内容，介绍了里面的方法，除了插件api的调用比较复杂外，其他都是普通的应用逻辑调用，主要理解了质量守恒定理，剩下的都是对数据审核数据的问题，非常简单。 遇到的坑 有应用开发的读者应该一下子就能理解到问题核心吧，我现在在说说里面的坑； 1） UTXO锁定接口容易被刷； 假如我一个开发人员知道这个接口，狂刷你这个接口狂锁应用的UTXO，这样应用长期都会瘫痪状态； 解决方案：这个应该从应用方面去考虑，譬如接口加一些一次性的验证码，加refer的监控，加授权之类的方式，后端加上交易监控，去维持着各种情况UTXO的状态，比较抽象，而且比较复杂，不过这是必须的； 2）并发问题；跟1）一样，就算我是一个正常用户，选择了一个UTXO解锁后，居然通过http接口告诉后端去锁定，调起 输入密码页面 （图K），这个时候如果用户不输入密码不提交，在比原链上该UTXO是没有被解锁，但是bufferserver会却锁住了。 解决方案： 后端源码是锁定一段时间，如果没有使用，则定期解锁出来，这种情况也是需要应用的监控判断，维护所有utxo的状态，个人建议在发合约的时候，发多笔UTXO锁定合约，可用的UTXO就会变多，这个时候有些同学问，TPS岂不是也一样不高，如果用过火币的同学就知道了，区块链交易本来就不太注重TPS，而且火币的交易必须要超过60-100个区块，才确定一笔交易，这个看应用开发者如何去判断，取舍。 3）用户交易信息接口容易被刷；跟1）一样，交易完成后，直接通过http接口去提交数据，我狂刷，岂不是亿万富翁....； 解决方案：想要用户的交易信息，生成交易账单，可以直接用插件的接口，不过要通过合约编码去筛选出来，笔者是通过监控区块链浏览器所有交易，进入数据库交易表的方式，这样可以时时刻刻监控所以交易。 4）容易产生链式错误； 这里dapp-demo发的是一个合约的UTXO，假如用户提交交易之后会产生新的UTXO，但是这个UTXO还没有确认的，bufferserver的list-utxo接口会把还没有确认的UTXO，从而解决并发问题，但是我一个开发人员，知道合约的编码，随便写个交易提交了，虽然肯定会失败，但是需要时间，这个时候bufferserver也把这个肯定失败的UTXO返回过来前端，一直链式产生一堆交易，很容易产生链式失败。 解决方案：1）这里我跟比原官方的老大深深讨论过，最优方案当然是合约本身设置一个密码，输入参数必须要根据这个密码去加incode密过，传入合约交易参数，合约本身在解释的时候，再decode解密验证，保证出入的参数是官方的，这样就不会有人攻击.....不过结论是，暂时比原链的合约引擎不支持。 2）一定要隐藏好合约逻辑，其他人就没办法去恶意调用恶意占用，例如前端代码混淆，或者args参数是后端生成，另外建议比原的blockcenter的build-transaction接口参数可以加密这样，去掩盖合约逻辑。 PS:这是笔者对于以上问题的思考，有更好的解决方案，欢迎一起讨论。 总结 这种内容主要说了前端代码的源码分析，还有设计上的逻辑坑，具体的解决方案应该跟官方的开发人员沟通还有讨论，区块链的交易本来不追求大并发，但是也需要一定的并发性，笔者在第四章才根据bufferserver内容，在针对上面的问题，做出一些个人见解还有建议。
-
发表了文章 2019-08-26
2019比原链全球开发者大会落幕：高举开源旗帜，聚焦区块链应用落地
北京时间8月25日，2019比原链全球开发者大会在美国旧金山Fort Mason Cowell Theater成功举办。会议吸引了来自美国、俄罗斯、印度、比利时、加拿大、巴西、赞比亚、委内瑞拉等多个国家的技术达人，参赛项目涉及稳定币支付系统、供应链金融、合约开发工具、教育科技等多个领域。最终，基于比原链开发的支付平台Paypaw（贝爪）获得2019比原链全球开发者大会一等奖，斩获3万美元等值的BTM奖励。 本次大会是比原链第二次举办区块链全球开发者大会，大会还邀请了Matrixport合伙人Daniel、ETC Labs总监Darin、MATPool CTO金磊、Celer联合创始人董沫、Multiplied创始人Nancy、Algorand工程研究负责人Naveed、Harmony联合创始人Nick、盈信泰资本投资总监Will等多位业内重量级嘉宾。 4个最终入围项目现场路演，6位重量级嘉宾精彩演讲，3场圆桌论坛金句频出，现场掌声不断，20度的旧金山似乎也有着34度杭州的火热。2019比原链全球开发者大会的成功举办，不仅显示比原链生态的日益壮大，区块链应用落地的不断推进，也让我们看到了全球区块链开发者的热情。纵观整场活动，开源精神依然是比原链的坚持，应用落地成为行业参与者聚焦的核心。 区块链与开源精神终将改变世界 比原链创始人& CEO段新星在开幕致辞中首先谈到了创建比原链的初心。他认为数字资产是一个巨大的未来趋势，非常希望建立一个数据资产的互联网，以支持多资产和可编程经济。自2018年4月主网上线以来，为了解决扩容问题，今年比原链将区块链拓展成“一主链多侧链”的架构，主链使用PoW来保证资产安全，在侧链引入DPoS，将TPS从主链的不到100，增加到侧链的约8000，以适应实际应用。目前比原链的Vapor侧链已经拥有大约42个节点，同时团队也在为企业应用创建更多定制化的工具。 “当前，我们正面临一个去全球化的阶段，但比原链依然拥抱开源，依然坚信区块链以及开源运动的力量。这股力量能让我们跨越国界，为用户带来更加实用的服务，创造更多的工作机会，并最终改变世界。” 图为比原链创始人& CEO 段新星 一主多侧架构，比原链加速商业应用落地 区块链技术应用落地是本次全球开发者大会的主基调。比原链技术VP James在演讲中介绍称，Bystack是基于比原链的BaaS服务，主链用于实现资产安全和去中心化，侧链用于实现可扩展性并运行应用。而根据比原链Vapor侧链BBFT共识算法发明者王炜的数据，在BBFT算法下，侧链每秒验证的交易数可达到2万笔，交易确认时间仅仅0.6秒，分叉的可能性仅为0.27%。将区块链“不可能三角”变成可能，Bystack全速助力区块链商业应用。 据段新星介绍，比原链在商业应用方面已经取得巨大进展。在社区成员的支持下，基于比原链的应用和软件已经在中国、欧洲和美国建立起跨链交易、物流、支付等多个领域的应用。举个例子，已经有海运物流公司使用比原链作为跨境结算系统。此次大赛中也有基于侧链的高速支付系统。去中心化交易所、DeFi、硬件钱包应用同样在不断涌现。 会上，James公布了比原链未来一年的路线图。Bystack 将开放BaaS平台，推出开发者中心以及Bystack去中心化身份（DID）。同时，Bystack将持续改善核心数据层和网络协议，推出BBFT共识2.0和迭代和Bytom 1.2.0的升级。基于一主多侧架构的OFMF（开放联邦管理框架）、DApp开放框架、去中心化个人信用（DPC）解决方案也会陆续推出。 图为比原链技术VP James 比原链创始人长铗表示： “区块链技术正在以一种前所未见的速度快速发展，正在对人类社会产生巨大的影响。我衷心希望包括参会者在内的所有区块链行业爱好者可以携手并进，一起构建更安全、更高效的区块链，建设更加美好的未来世界。” 此外，在区块链的应用大潮中，xx即服务也逐渐从区块链本身拓展到挖矿业务中。MATPool CTO金磊在演讲中表示，作为比原链的官方矿池，MATPool正在研究推出MaaS（挖矿即服务），为算力提供方用户提供矿机托管服务，设置简单，接入方便，自动为用户寻找收益率最高的币种；算力需求方用户也可以随时找到所需的算力，统一费率，按分钟计费。MaaS将打破GPU算力供需双方孤立、无法连接的状态，将算力和计算有机地连接起来。 图为MATPool CTO金磊 值得一提的是，应用落地不只是比原链，也是各大公链的发力点。Celer Network联合创始人董沫在演讲中介绍称，Celer Network已经在游戏领域发力，推出C端手机应用CelerX来加速推动区块链游戏的落地。开发者可以利用CelerX Gaming SDK快速简单地创建HTML5游戏，无需任何区块链开发经验。 入围队伍现场路演，Paypaw斩获一等奖 在大会参赛项目的路演环节，2018比原链开发者大会的一等奖项目Bytomswap也来到了现场，率先登场为大家介绍了项目的最新进展。项目代表Anil Kumar介绍称，作为一个基于比原链的去中心化数字资产交易平台，Bytomswap目前已经可以支持跨链资产交换，后续将会推出一个面向比原链资产的标准通证命名注册系统，并在比原链钱包中加入一个用于去中心化交易的钱包插件。从较为基础的Demo到不断完善的产品，Bytomswap也同样在一步步走向落地。 图为Bytomswap项目代表Anil Kumar 在本届大会的最终入围项目中，有基于比原链的人工智能版权注册和保护平台ProofChain（速易证）、基于比原链的支付平台Paypaw（贝爪）、分布式拍卖系统ODIN Swap以及基于比原链的支付通道网络BytomLit。最终，Paypaw（贝爪）获得2019比原链全球开发者大会一等奖，斩获3万美元等值BTM。项目代表Dalin在谈到之所以选择在比原链上开发的原因时表示，比原链的DPoS侧链提供了近乎即时的交易确认，TPS高，安全性好，故而选择基于比原链开发这样一个应用。 图左为比原链创始人& CEO 段新星，图右为Paypaw（贝爪）项目代表Dalin 此外，ProofChain（速易证）获得二等奖，BytomLit、GoAskme、ODIN Swap Tools以及BTMHDW获得优秀奖。比原链团将与获奖团队持续保持沟通，并进行项目交流和检查，帮助项目更好地成长、落地。 思维碰撞，圆桌讨论精彩不断 本次大会一共有3场圆桌论坛。在主题为“公链挑战与趋势”的圆桌上，ETC Labs主管 Darin Kotalik提出，科普教育是未来几年公链面临的巨大挑战，人们必须要对区块链有基本的认识，分清楚公链和私链的区别。Harmony 联合创始人Nick White则表示，技术、监管以及应用是三个最重要的挑战。 从左到右依次为Multiplied CEO Nancy Li、ETC Labs主管 Darin Kotalik、Algorand 工程研究负责人Naveed Ihsanullah、Harmony 联合创始人Nick White以及比原链工程VP James 在PoW和PoS孰优孰劣的问题上，ETC Labs主管 Darin Kotalik认为，不管PoW还是PoS，不同的共识没有高低之分，重点在于你想要解决什么样的问题。比原链工程VP James则认为，对于公链，PoW是最好的共识算法，毕竟它已经在比特币上运行了10年，得到了验证。DPoS中心化程度比较高，可能相对来说危险一些。 面对行业目前非常关注的应用落地问题，Algorand 工程研究负责人Naveed Ihsanullah认为，要实现大规模应用，需要大量、甚至全球的开发者都参与开发，并针对用户的需求和实际用例开发应用。区块链大规模应用发生时就是用户在使用却没有感知的时候，让用户不需要理解应用背后的技术也能非常便利地使用。Harmony 联合创始人Nick White表示，DeFi是区块链的一个很好的用例，但是它在成熟度、安全性以及监管方面还存在问题，目前来看游戏是最佳突破口。游戏可以帮助更多用户了解区块链，在监管方面也没有金融应用方面的问题。 在主题为“数字资产行业的价值创造”的圆桌上，AnChain市场经理Steven Yang发言称，加密货币的早期参与者中，很多都是反对监管的；事实上，为了满足监管要求（KYC），项目却不得不向中心化靠拢。在实际应用方面，用户往往也对中心化的服务更加适应。Infstone商业负责人Sili Zhao则表示，目前很多人对区块链的认识仅限于银行业务和加密货币，从业者应该更多探索区块链在其他领域的应用落地。 从左到右依次为Vera Network & IoTBlock创始人 Denis Lam、Infstone商业负责人Sili Zhao、Anchain市场经理Steven Yang以及Reserve 工程VP Zera 在最后一场主题为“投资未来：如何寻找投资机会”的圆桌上，Matrixport 创始合伙人 Daniel Yan认为香港和新加坡是亚洲开展加密业务的最佳地点。而火币顾问、Ausvic Capital投资主管 Will Wang则从战略角度看待地点的选择，他认为地点的选择还是要看技术力量和人才的聚集。他还指出，一般来说，公司应该秉承“用户在先，技术在后”的理念，很多初创公司往往陷入误区，沉溺技术，反而忽略了用户的需求和体验。 OKcoin 投资/合作关系主管Cecilia Li在发言中表示，任何东西都可以通证化，关键还是资产本身是否有需求和价值，自身没有价值的东西任何手段都行不通。Taxa. Amino capital EIR 创始人TF Guo则为二级市场的投资者提供了一点个人的建议，投资加密资产可以，但是最好不要去交易，“Just build and hold”。 从左到右依次为Monday Capital创始合伙人Yiannis Varelas、OKcoin 投资/合作关系主管Cecilia Li、火币顾问、Ausvic Capital投资主管 Will Wang、Taxa. Amino capital EIR 创始人TF Guo以及Matrixport 创始合伙人 Daniel Yan
-
发表了文章 2019-08-05
Bytom Dapp 开发笔记（二）：开发流程
简介 这章的内容详细分析一下涉及智能合约Dapp的整个开发流程，注意是涉及只能合约，如果你只要一些基本转BTM功能没有太大意义，本内容补充一下官方提供的 比原链DAPP开发流程，详细实践过好踩到的一些坑，还有一些真正具体的技巧还有经验，个人认为非常有用，起码让开发者可以更快速地去操作。 资料说的储蓄分红合约太复杂了，简单说说逻辑，银行发了一笔股份资产，用合约锁定，用户去触发这个合约的方法，付出了钱兑换了对应份额的股份资产，当达到一定的高度，就可以通过用股份资产兑换回本金与分红（钱+利息）。 里面包含了两个合约~~ 整体流程 开发流程分为，1）编写智能合约；2）发合约交易；3）测试解锁合约方法；4）基于插件钱包开发Dapp前端；5）开发后端； 流程貌似非常简单，本人在1，2,3 步浪费了很多时间。其中有些坑踩过接下来介绍一下； 1）编写智能合约，上面提供的 比原链DAPP开发流程，写得很清楚，使用的是equity非常简单，直接下载最新版 用命令 【./equity TradeOffer --instance 】 就能得到一串编译后的合约程序代码，简称智能合约程序。 E:\GoWorks\src\github.com\equity\equity>equity.exe jiedai_6.txt --instance ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 260374 260474 260574 260674 260774 260874 260874 00141ccef16d2ac1ab22baa8acfa1633fdc32df d55aa b1f38553d95177c53755996baf523da006da977008f069792bb6a2c3b6a253fb ======= PartLoanCollateral ======= Instantiated program: 20b1f38553d95177c53755996baf523da006da977008f069792bb6a2c3b6a253fb1600141ccef16d2ac1ab22baa8acfa1633fdc32dfd55aa030afb03030afb0303a6fa030342fa0303def903037af9030316f90320ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffff4d2b015b7a76529c641d010000640c0100005c7900a0695c790500f2052a01947600a0695379cd9f5579cda09a916164380000005a95639a00000054798ccd9f5679cda09a916164500000005895639a00000055798ccd9f5779cda09a916164680000005695639a00000056798ccd 9f5879cda09a916164800000005495639a00000057798ccd9f5979cda09a916164980000005295639a0000005195c3787ca169c3787c9f916164f5000000005e795479515e79c1695178c2516079c16952c3527994c251006079895f79895e79895d79895c79895b79895a79895979895879 895779895679890274787e008901c07ec1696307010000005e795479515e79c16951c3c2516079c169632b010000587acd9f6900c3c2515c7ac1632b010000755b7aaa5b7a8800c3c2515d7ac1747800c0 2）发合约交易， 先解释一下合约的逻辑，储蓄分红合约太复杂，所以我们用币币交易合约去举例子， contract TradeOffer(assetRequested: Asset, amountRequested: Amount, seller: Program, cancelKey: PublicKey) locks valueAmount of valueAsset { clause trade() { lock amountRequested of assetRequested with seller unlock valueAmount of valueAsset } clause cancel(sellerSig: Signature) { verify checkTxSig(cancelKey, sellerSig) unlock valueAmount of valueAsset } } 看看智能合约的交易图，方便小白理解: 所以储蓄分红合约一开始肯定要锁定一部分资产，所以必须部署合约交易。那么如何触发呢？ 本人通过PC钱包的接口方式去部署合约，具体很多例子可以在智能合约学习文档看到。 PC钱包方式，所有交易都必须三部，build-transaction，sign-transaction，submit-transaction，三个接口。 踩过的坑： 调试智能合约很慢，要等到交易确认才能知道是否成功，而且报错不明显，不知道哪里出问题； 解决方案： 本地PC钱包solonet模式调试，更改源码，快速出块 difficulty/difficulty.go func CheckProofOfWork(hash, seed *bc.Hash, bits uint64) bool { compareHash := tensority.AIHash.Hash(hash, seed) return HashToBig(compareHash).Cmp(CompactToBig(bits)) <= 0 } 里面那句添加 ||true 如下 return HashToBig(compareHash).Cmp(CompactToBig(bits)) <= 0 || true 一开始没想到这样做，以为很快调试好，搞了三天晚上10点才调试完。 2.智能合约对于除法的支持很不友好，尽量不要用除法，一开始写了一个很复杂的合约，不知道错误，智能逐步改代码快速调试去定位，最后发现 A/B，如果A=B没问题，否则就直接报错，问过官方没有得到合适的回答,我尝试过是存证这种问题，非常坑。 3.程序必须计算好对应结果utxo 流转action的 input、ouput ；如下 { "base_transaction": null, "actions": [ { "output_id": "13fbd1e5df196a1488e85e3b5983e51444c49ef3695df789c9473abb636e0f5c", "arguments": [ { "type": "integer", "raw_data": { "value": 5500000000 } }, { "type": "data", "raw_data": { "value": "00141ccef16d2ac1ab22baa8acfa1633fdc32dfd55aa" } }, { "type": "integer", "raw_data": { "value": 0 } } ], "type": "spend_account_unspent_output" }, { "amount": 5500000000, "asset_id": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff", "control_program": "0014d470cdd1970b58b32c52ecc9e71d795b02c79a65", "type": "control_program" }, { "amount": 5000000000, "asset_id": "80013f81a66cb99977879e31639bb4fe4b12b4c7050fe518585d3f7f159d26a9", "control_program": "00141ccef16d2ac1ab22baa8acfa1633fdc32dfd55aa", "type": "control_program" }, { "amount": 9999995000000000, "asset_id": "80013f81a66cb99977879e31639bb4fe4b12b4c7050fe518585d3f7f159d26a9", "control_program": "20b1f38553d95177c53755996baf523da006da977008f069792bb6a2c3b6a253fb160014d470cdd1970b58b32c52ecc9e71d795b02c79a6503e1830403e1830403e256040322350403a21e0403e20e040307fb0320ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff4d2b015b7a76529c641d010000640c0100005c7900a0695c790500f2052a01947600a0695379cd9f5579cda09a916164380000005a95639a00000054798ccd9f5679cda09a916164500000005895639a00000055798ccd9f5779cda09a916164680000005695639a00000056798ccd9f5879cda09a916164800000005495639a00000057798ccd9f5979cda09a916164980000005295639a0000005195c3787ca169c3787c9f916164f5000000005e795479515e79c1695178c2516079c16952c3527994c251006079895f79895e79895d79895c79895b79895a79895979895879895779895679890274787e008901c07ec1696307010000005e795479515e79c16951c3c2516079c169632b010000587acd9f6900c3c2515c7ac1632b010000755b7aaa5b7a8800c3c2515d7ac1747800c0", "type": "control_program" }, { "account_id": "0U374V0300A02", "amount": 5500000000, "asset_id": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff", "type": "spend_account" }, { "account_id": "0U374V0300A02", "amount": 20000000, "asset_id": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff", "type": "spend_account" } ], "ttl": 10000 } 一个解锁合约交易要包含action类型有， spend_account_unspent_output (合约的参数)， spend_account (输入的资产描述)， control_program或者control_address （接收者资产描述）， 可以理解成质量守恒。 如上面例子 spend_account_unspent_output 的action里面有个output_id =13fbd1e5df196a1488e85e3b5983e51444c49ef3695df789c9473abb636e0f5c，这个资产的小数位为8（这里没有体现），代表我要解锁这个utxo，他的值为 100000000.00000000 就是1亿。 拆分成两个action，一个 50.00000000，一个 99999950.00000000 只有btm = ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 需要用来等手续费，所以允许不守恒，最后由旷工挖矿拿到手续费。 总结：那么程序相当于要把合约里面的逻辑整合进去，才能计算好真正的input、output~~我理解是交易确认的时候，解锁合约的程序验证现在的input、ouput是否跟合约一样。 3）测试解锁合约方法，2）里面采坑已经说清楚这个问题了，补充一下就是最好一下子不要写太复杂的合约，从简单来开发调试。一定要注意质量守恒定律，只要懂了这个原理其实非常简单。 4）基于插件钱包开发Dapp前端， 这块具体可以看插件钱包API，储蓄分红合约前端源代码，里面说的非常清楚， 涉及到的接口，暂时他们API文档还没有整理出来，来自上一章说的blockcenter的接口 url地址 ：testnet: 'http://app.bycoin.io:3020/', mainnet: 'https://api.bycoin.im:8000/' 核心用到的接口有： 根据合约与资产ID查询UTXO接口 /api/v1/btm/q/list-utxos 参数： { "filter": { "script":"20b1f38553d95177c53755996baf523da006da977008f069792bb6a2c3b6a253fb160014d470cdd1970b58b32c52ecc9e71d795b02c79a6503e1830403e1830403e256040322350403a21e0403e20e040307fb0320ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff4d2b015b7a76529c641d010000640c0100005c7900a0695c790500f2052a01947600a0695379cd9f5579cda09a916164380000005a95639a00000054798ccd9f5679cda09a916164500000005895639a0000798ccd9f5779cda09a916164680000005695639a00000056798ccd9f5879cda09a916164800000005495639a00000057798ccd9f5979cda09a916164980000005295639a0000005195c3787ca169c3787c9f916164f5000000005e795479515e79c1695178c2516079c16952c3527994c251006079895f79895e79895d79895c79895b79895a79895979895879895779895679890274787e008901c07ec1696307010000005e795479515e79c16951c3c2516079c169632b010000587acd9f6900c3c2515c7ac1632b010000755b7aaa5b7a8800c3c2515d7ac1747800c0", "asset":"80013f81a66cb99977879e31639bb4fe4b12b4c7058585d3f7f159d26a9" , "unconfirmed":false }, "sort": { "by":"amount", "order":"desc" } } unconfirmed ，代表是否确认的，这个对后期的并发问题非常有用，第三章我会详细说明。 结果 { "code": 200, "msg": "", "result": { "_links": {}, "data": [ { "hash": "16749b694a9f1bc6a7759cf66baefed4c864b65985e7488e8721184ecc4d6965", "asset": "80013f81a66cb99977879e31639bb4fe4b12b4c7058585d3f7f159d26a9", "amount": 3000000000 }, { "hash": "e5f75036b6f662ff705378b55dd29dc1a43acb23d701dd44a068cdab2c43ad0c", "asset": "80013f81a66cb99977879e31639bb4fe4b12b4c7058585d3f7f159d26a9", "amount": 15000000000 } ], "limit": 10, "start": 0 } } （自己准备参数调用一下，以上是例子而已） 查询用户地址信息与余额接口 /api/v1/btm/account/list-addresses 参数 {"guid":"b414005b-b501-4a0e-8b0f-e1cd762272f4"} 结果 { "code": 200, "msg": "", "result": { "_links": {}, "data": [{ "guid": "b414005b-b501-4a0e-8b0f-e1cd762272f4", "address": "bm1qp4t6thlyktt6sh02scs8dqcpnk3ufk9e9pmq9s", "label": "", "balances": [{ "asset": "80013f81a66cb99977879e31639bb4fe4b12b4c7050fe518585d3f7f159d26a9", "balance": "68900000000", "total_received": "69000000000", "total_sent": "100000000", "decimals": 8, "alias": "", "in_usd": "0.00", "in_cny": "0.00", "in_btc": "0.000000" }, { "asset": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff", "balance": "1329551000", "total_received": "53790000000", "total_sent": "52460449000", "decimals": 8, "alias": "btm", "in_usd": "1.45", "in_cny": "10.10", "in_btc": "0.000142" }] }], "limit": 10, "start": 0 } } ps: guid是专门插件钱包提供的，是唯一的，这个非常有用，第三章我会详细说。 查询交易信息 /api/v1/btm/account/list-transactions 参数 {"address":"bm1qp4t6thlyktt6sh02scs8dqcpnk3ufk9e9pmq9s","start":0,"limit":100} 结果 { "code": 200, "msg": "", "result": { "data": [{ "ID": 111, "Hash": "471e5b267f646546be33505773186ee9d8dde2180a515df67a90d1a5f9d17bd2", "AssetID": "80013f81a66cb99977879e31639bb4fe4b12b4c7050fe518585d3f7f159d26a9", "Amount": 7000000000, "Address": "bm1qp4t6thlyktt6sh02scs8dqcpnk3ufk9e9pmq9s", "BaseID": 5, "Timestamp": "2019-07-08T09:23:12+08:00", "Height": 263728, "TransactionID": "471e5b267f646546be33505773186ee9d8dde2180a515df67a90d1a5f9d17bd2", "InputAmount": 5700000000 }, { "ID": 64, "Hash": "e69631a8d6321d738793646399ffe022ac177a5732f562970e706ee76d49de82", "AssetID": "80013f81a66cb99977879e31639bb4fe4b12b4c7050fe518585d3f7f159d26a9", "Amount": 5000000000, "Address": "bm1qp4t6thlyktt6sh02scs8dqcpnk3ufk9e9pmq9s", "BaseID": 5, "Timestamp": "2019-07-05T16:37:07+08:00", "Height": 262170, "TransactionID": "e69631a8d6321d738793646399ffe022ac177a5732f562970e706ee76d49de82", "InputAmount": 5500000000 }, { "ID": 56, "Hash": "cf74906808a1a6bc6a056c148510d542a10d2cbc350a4d830c670aa5ba973873", "AssetID": "80013f81a66cb99977879e31639bb4fe4b12b4c7050fe518585d3f7f159d26a9", "Amount": 39000000000, "Address": "bm1qp4t6thlyktt6sh02scs8dqcpnk3ufk9e9pmq9s", "BaseID": 5, "Timestamp": "2019-07-03T14:59:22+08:00", "Height": 261006, "TransactionID": "cf74906808a1a6bc6a056c148510d542a10d2cbc350a4d830c670aa5ba973873", "InputAmount": 8900000000 }, { "ID": 54, "Hash": "6aedf609d47b3c06de2ce7dc9f2c99895124c80074573cd29407ac3b34ef8d40", "AssetID": "80013f81a66cb99977879e31639bb4fe4b12b4c7050fe518585d3f7f159d26a9", "Amount": 2000000000, "Address": "bm1qp4t6thlyktt6sh02scs8dqcpnk3ufk9e9pmq9s", "BaseID": 5, "Timestamp": "2019-07-03T12:11:12+08:00", "Height": 260936, "TransactionID": "6aedf609d47b3c06de2ce7dc9f2c99895124c80074573cd29407ac3b34ef8d40", "InputAmount": 5200000000 }] } } 5）开发后端，相当于bufferserver，第三章详细说明顺便我解析一下bufferserver的源码内容，还有里面踩过的坑。 总结： 这一章内容主要比较繁琐强调是调试合约方面，就是最核心的问题，这里抛出一个问题，就是UTXO问题，调试过程中非常繁琐，本来区块链不是做高并发，但是也存在并发问题，应该如何解决？ 有使用过PC钱包的朋友肯定知道，里面PC钱包的UTXO，在交易过程中锁定了，没办法操作下一个，有些很多UTXO还好，如果只有一个，基本上调试跟实用都很麻烦~~~第三章我们基于原有bufferserver基础上根据官方的方案改一下，一定程度解决并发问题，大家期待一下。 参考资料： 比原链DAPP开发流程 储蓄分红合约Demo访问地址 储蓄分红合约后端bufferserver源码 储蓄分红合约前端源代码 储蓄分红合约详细说明 equity 智能合约学习文档 插件钱包API 作者：天才的饭桶
滑动查看更多
暂无更多信息
-
发表了文章
2019-12-27
社区观点 | 理解比原链MOV链上交换协议
-
发表了文章
2019-11-26
比原链CTO James | Go语言成为区块链主流开发语言的四点理由
-
发表了文章
2019-08-28
Bytom Dapp 开发笔记（三）：Dapp Demo前端源码分析
-
发表了文章
2019-08-26
2019比原链全球开发者大会落幕：高举开源旗帜，聚焦区块链应用落地
-
发表了文章
2019-08-05
Bytom Dapp 开发笔记（二）：开发流程
-
发表了文章
2019-08-05
Bytom Dapp 开发笔记（一）：架构设计
-
发表了文章
2019-07-18
Bystack跨链技术源码解读
-
发表了文章
2019-07-18
Bytom 储蓄分红 DAPP 开发指南
-
发表了文章
2019-07-18
比原链DAPP开发流程
-
发表了文章
2019-06-21
Blockmeta api v2使用教程
-
发表了文章
2019-05-27
Bystack的高TPS共识算法
-
发表了文章
2019-04-26
Bytom Kit开发辅助工具介绍
-
发表了文章
2019-04-23
BMIP002协议介绍
-
发表了文章
2019-04-08
调用Bytom Chrome插件钱包开发Dapp
-
发表了文章
2019-03-27
使用Java SDK实现离线签名
-
发表了文章
2019-03-21
Bytom储蓄分红合约解析
-
发表了文章
2019-03-13
BUTXO详解
-
发表了文章
2019-03-11
比原链（Bytom）节点接入文档
-
发表了文章
2019-03-01
Bytom的链式交易和花费未确认的交易
-
发表了文章
2019-02-21
Bytom BIP-32协议和BIP-44协议
滑动查看更多
暂无更多信息