这周开始我们考虑自己做一个DAPP产品，然后开始查阅相关资料，现在写下我们的学习成果。我们会在这里记录我们做这个产品的思考。
首先是我们对以太坊上的智能合约的一些理解：
1. 以太坊是一个已经在运行中的公链，代码公开且固定，所以以太坊上运行的逻辑也是固定的。智能合约是一个可以被自定义的回调函数。
2.智能合约在每次记账时被调用，智能合约没有自定义定时器，所以没有办法在指定时间执行。或者我们可以把每次记账间隔看成是固定计时器。
3.智能合约不能访问链外数据。通常我们要编写一个商用程序还是需要访问各种来源的数据，这时候需要预言机来提供数据源。预言机是一个数据交互网关，一边连着外部数据源，一边连着区块链。比如像Oraclize这样的预言机解决方案。
4.在以太坊上用智能合约开发的软件和BS模式类似，且不存在主动推送的问题。
5. 以太坊上的智能合约不存在死循环的风险，一旦GAS消耗完，智能合约就终止执行。
6.我们经常听到的ERC20、ERC721是智能合约编程规范， 或者可以看出一种基类。无论是继承还是重写，只要具备ERC20固定的这些接口和接口返回值，就可以看成是ERC20。
7.智能合约是函数，不存储任何数据，数据存储在区块链上。智能合约本身也是一种数据，所以也是存储在区块链上。
这些内容的学习对我们开发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有什么好的想法也欢迎和我们交流。
