#如何开发一个DAPP-1#理解智能合约

#如何开发一个DAPP-1#理解智能合约

这周开始我们考虑自己做一个DAPP产品,然后开始查阅相关资料,现在写下我们的学习成果。我们会在这里记录我们做这个产品的思考。

首先是我们对以太坊上的智能合约的一些理解:

以太坊是一个已经在运行中的公链,代码公开且固定,所以以太坊上运行的逻辑也是固定的。智能合约是一个可以被自定义的回调函数。智能合约在每次记账时被调用,智能合约没有自定义定时器,所以没有办法在指定时间执行。或者我们可以把每次记账间隔看成是固定计时器。智能合约不能访问链外数据。通常我们要编写一个商用程序还是需要访问各种来源的数据,这时候需要预言机来提供数据源。预言机是一个数据交互网关,一边连着外部数据源,一边连着区块链。比如像Oraclize这样的预言机解决方案。在以太坊上用智能合约开发的软件和BS模式类似,且不存在主动推送的问题。 以太坊上的智能合约不存在死循环的风险,一旦GAS消耗完,智能合约就终止执行。我们经常听到的ERC20、ERC721是智能合约编程规范, 或者可以看出一种基类。无论是继承还是重写,只要具备ERC20固定的这些接口和接口返回值,就可以看成是ERC20。智能合约是函数,不存储任何数据,数据存储在区块链上。智能合约本身也是一种数据,所以也是存储在区块链上。

这些内容的学习对我们开发DAPP有什么用呢?通过上面的学习我们知道了以太坊不适合开发哪种类型的应用。

首先我们来看一下DAPP应该具备什么样的条件(来自于Oreilly《去中心化应用》):

1. 开源

2. 内部货币

3. 去中心化共识

4. 没有中心失效点

如果一个DAPP的逻辑是通过区块链上的智能合约实现的,那么1、3、4就实现了。因为能被区块链执行的智能合约一定是开源的且不可修改的,且逻辑是被所有参与者认可的。而且只要只要有一台矿机还在运行,这个程序就能一直跑下去。至于内部货币这个事情,如果是运行在以太坊的智能合约,一定需要ETH才能使系统运行,因此内部货币也一定存在。

如果我们用以太坊和智能合约来开发一个DAPP,那么应该顺着这个思路往下走。

我们的DAPP是BS还是CS,如果是CS模式即需要服务端主动推送消息的,以太坊不大适合这个模型,因为无论是DAPP如何频繁去取数据,也只能等每次记账时执行。后端的数据如何存储问题,如果数据很大,应该考虑存储到IPFS这种区块链上,如果很小可以存在以太坊上。数据来源的问题,如果有外部数据来源,需要选择一个预言机,或者自己实现一个。简单的话就是自己搭个全节点,通过RPC调用把外部数据送到链上。前端展示不是什么问题,JS可以直接调用智能合约,返回什么显示什么即可。以太坊不适合开发交互很频繁的程序,更像早期互联网,开发一些并发量不大的信息展示页面。

PS:以太坊的标准可以查看这个页面:https://eips.ethereum.org/all

再PS:好久没有看技术方面的内容了,怀着忐忑的心情写下这个文章,如有不对欢迎留言指教,如果对DAPP有什么好的想法也欢迎和我们交流。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

Proudly powered by WordPress | Theme: HoneyWaves by SpiceThemes