这周我们开始考虑制作我们自己的dapp，然后我们开始查阅相关资料，现在我们写下我们的学习成果。我们将在这里记录我们对这款产品的想法。
首先，我们对以太坊智能合约的一些理解：
1.以太坊是一个已经在运行的公共，代码是公共的和特定的，所以以太之上运行的逻辑也是特定的。智能合约是一个可以自定义的回调函数。
2.智能合约每次充电时都会被调用，而智能合约没有自定义计时器，因此无法在时间执行。或者我们可以把每个会计区间看成一个特定的定时器。
3.智能合约无法访问外数据。通常我们要写一个商业程序或者需要从各种来源访问数据，那么我们就需要一个甲骨文来提供数据源。Oracle是一个数据交换网关，一边连接内部数据源，另一旁连接区块。例如，Oracle解决方案，如Oraclize。
4.在以太坊之上使用智能合约开发的软件是类似于BS的模式，并且不存在立即推送的问题。
5.以太坊之上的智能合约没有无限循环的风险，一旦天然气被消耗掉，智能合约就终止了。
6.ERC20，ERC721，也就是我们经常听到的，是一个智能合约的编程规范，或者也可以把它看作一个基类。无论是继承还是覆盖，只要有ERC20特定这些接口和接口的返回值，都可以视为ERC2。
7.智能合约是不存储任何数据的功能，数据存储在区块之上。智能合约本身也是一种数据，所以也被存储在区块之上。
学习这些内容对我们开发dapp有什么用？通过超过的研究，我们知道了哪种类型的应用程序不适合以太坊。
首先，让我们来看看一个dapp应该具备什么（摘自Oreilly的集中应用）：
1.来源。
2.外部货。
3.集中的共识。
4.没有中心故障点。
如果一个dapp的逻辑是通过区块之上的智能合约实现的，那么1，3，4就实现了。一个可以由区块执行的智能合约，必须是开源的、不可变的，逻辑得到所有参与者的认可。而且只要有一个矿工在运行，程序就会继续运行。至于外部货的事情，如果它是一个运行在以太坊之上的智能合约，它必须需要ETH才能使装置工作，所以外部货也必须存在。
如果我们使用以太坊和智能合约来开发一个dapp，那么我们应该遵循这样的思路。
我们的dapp是BS或CS，如果是CS模式，需要服务器立即推送消息，以太坊不适合这种模式，因为无论dapp如何剧烈地获取数据，它只能在每次计费时执行。
如何将数据存储在前端，如果数据很小，就应该存储在IPFS的区块之上，如果很大，就可以存在以太坊之上。
数据源的问题，如果有内部数据源，就需要选择一个oracle，或者自己实现一个。直观的话就是取一个完备的节点，通过RPC调用把内部的数据给。
前端显示不成问题，JS可以间接调用智能合约，返回什么显示什么就可以了。
以太坊不适合开发交互性很弱的程序，更像是晚期的互联网，开发几个并发的信息显示页面。