十分钟带你上手以太坊开发

“比大多数人更早学习区块链开发”

课程预览

—

今晚8点见

今晚8点，静待秭归中第一时间体验直播课程，为您带来《区块链时代，不容错过的机会》。 经销商的疯狂收割，投资者的疯狂宣传，狂欢、焦虑和各种情绪充斥着整个行业。 那么我们的机会在哪里呢？ 如果您不了解区块链，想进入这个行业却不知从何入手； 如果你是一名工程师，还没有在这样一个以工程师为主导的浪潮中找到自己的位置，那么你应该来听听这门课程。 点击课程链接【阅读原文】，扫描二维码加入微信群，联系：等待秭归中-小助手领取高额优惠。

文本

—

几个月前，我负责一个基于 ETH 的区块链项目。 在整个开发过程中，虽然能找到很多中文的区块链资料，但大部分都是国外文档的翻译。 一方面他们都不是特别新，另一方面又缺乏实际应用支持，所以才萌生了这篇文章的想法，希望能帮助到正在参与的同学在以太坊开发中。

01

—

关于区块链

区块链最近很火，但其实区块链的本质并没有那么复杂，BTC也没有解决一个特别神奇的问题。 最重要的是解决了不安全的P2P网络环境下独立系统内的货币流动问题。 （货币生成和双重支出）。

这其实很重要。 我接触过的大部分区块链系统都是一样的。 他们只处理自己系统内部的问题，以单链序列化的方式处理业务逻辑。 即使是智能合约，为了保护智能合约 Trusted，不允许任何外部数据引用，并且因为具体实现的分布，甚至无法在运行时进行与运行节点相关的操作。

至于ETH，它是在BTC的基础上更进一步，是一个超级单线程的计算机。

因为区块链最初的解释是分布式账本，可以理解为分布式可信数据库。 在BTC阶段以太坊技术，这里存储的数据是事先约定好的（货币==），而在ETH阶段，这里可以用来存储任意数据，那么智能合约可以理解为这个分布式数据库中的存储过程，它们公开一组接口来访问和修改各种数据。

所以在ETH中，账户、实例化的智能合约、数据等在这个超级计算机中其实只是一个内存地址。

区块链可信背后的原理是什么？ 其实很简单。 它是通过记账权（记账权）的不确定性来实现的。 每个节点都进行相同的计算，因为不知道谁的结果为准，所以作弊的成本非常高。

02

—

最简单的ETH应用模型

如果把整个 ETH 网络想象成 Facebook 这样的平台，DAPP 和普通 APP 没什么区别。 web3相当于一套平台API接口和智能合约，用于存储需要上链的核心数据和权限控制脚本。 . 剩下的应该用数据库还是应该用数据库，毕竟链上是有成本的（gas和操作延迟）。

下面是我们项目最基本的结构图：

上图是一个简单的ETH应用架构，其中的ETH网络就是现有的ETH网络。 当然，在开发阶段，也可以使用私链或者测试链（如果一开始就直接上公链，gas成本太不划算了））。

ETH节点最好是我们自己部署的ETH节点。 启动时开启RPC就好了，所有使用的域都必须开启。 如果你使用过 geth 控制台，你应该知道这一点。 因为我们的项目其实有一些中心化的部分，需要用到的关键ETH私钥也必须导入，最重要的是ETH余额（很多操作都会有GAS开销）。

DAPP 服务器是我们的主要开发服务器。 前面说了，因为DAPP的特殊性，不可能把所有东西都放在ETH链上，效率和开销都不划算，所以这里规划的时候需要想清楚。 除了通过web3驱动ETH，其他应用与普通应用没有太大区别。 那些应该有自己的中央数据库的应该有缓存，最好有缓存。

与ETH的接口是web3，是一套RPC接口。 界面和其他平台没有什么特别之处。

ETH的每次写操作（消耗GAS）几乎分为两部分。 第一步是发布到链上，这时候会得到一个地址，然后通过查看地址的状态，判断操作是否完成，可能需要很长时间才能完成，这里你需要考虑各种异常，以及服务器进程重启等。

DAPP客户端，这个没什么好说的。 如果是web应用以太坊技术，建议连接MetaMask，这样对用户来说会更安全。

智能合约模块，这部分其实是真正DAPP的核心。 最好只把需要上链的部分放在智能合约模块中，尽量精简。 智能合约虽然是图灵完备的，但是成本和限制都非常高，前期的项目规划非常重要。 还是那句话，搞清楚项目为什么要用区块链，哪些部分必须上链，哪些部分不需要上链。

03

—

ETH开发环境搭建

现在搭建ETH环境很简单，基本上就是安装golang，然后下载geth代码编译即可。

如果是测试，建议自己做一条私链，网上找创世块配置。 需要注意的是，在运行geth的时候，有一个data目录。 如果一台机器既有测试私链又有公链，但是这个目录可以配置不同。 熟悉一下geth的控制台操作，你会发现web3接口基本上就是对这些的封装。

然后是智能合约的开发环境。 我们使用VSCode（带Solidity插件）进行本地编码，然后在开发阶段使用Remix进行测试，最后用Solc编译，通过我们自己的web3接口的服务器进行部署。

IDE是安利Atom下的插件Etheratom，可以在本地编译部署，RPC连接节点。 同学们也可以试试。

在我们的项目中，后端直接使用NodeJS，IDE使用VSCode，ETH的web3库使用web3.js。

前端也是web，也是VSCode，没什么好说的。

04

—

Web3 和稳固性

web3 基本使用RPC 来控制eth 节点的API，大部分命令与geth 控制台命令一致。

虽然ETH社区很活跃，但是版本更新有点快，所以坑还是比较多的。 我们主要使用web3.js，中间遇到了一个bug。 按照github的说法，应该是geth代码改动导致的，但是说实话，web3.js处理的不严谨，快一个月没人管了。 后来我们找到了调用更底层接口的方法来避免这个bug。

链上的所有操作都是两步的，一步是发布到链上，一步是最终确认，所以我们没有直接使用web3.js接口来处理最后的回调，而是在后面记下地址chain，自己维护list查询状态，这样一方面不会阻塞玩家的操作，另一方面也不会因为服务器其他异常重启而影响逻辑。

合约中一般会有一些没有gas开销的只读接口，但是这部分接口的延迟其实是很严重的，而且我们这部分数据也是自己缓存的，所以我们不能在上面调用接口上链而不调用上链接口。

原则上智能合约需要运行在任意一个ETH节点上才能得到相同的结果，所以完全不可能主动从外部获取数据（不安全），而且获取到的时间戳也和当前区块有关。

由于GAS规则的存在，不建议在智能合约中做大的遍历循环（甚至默认的map结构根本不允许遍历），除了自己的逻辑尽量使用外部缓存（screen out参数外部直接传递给智能合约可以省去很多排序和遍历逻辑），因为区块链原则上不支持并行，所以我们也使用大量的索引来简化各种时序关系。

如果有一些非常基础的功能，必须在智能合约中实现，如果基础语法不支持，建议先寻找现成的实现，比如随机数、可遍历映射、排序等。

智能合约实例化后就是一个地址。 只要有它的ABI，就可以调用开放的接口。 因此，Solidity加入了很多限制语法来保证安全性（我在这方面支持ETH，EOS的用C++编译WASM的方案更方便，但也失去了特殊语法层面的防御措施），很多版本的更新Solidity与此类似，所以尽可能遵循最新的语法规范，尽可能把安全控制在语法层面。

一旦部署（实例化）智能合约，代码就不能更改，就像 C++ 对象一样。 实例化后就是一个地址。 如果后面需要调整逻辑怎么办？

目前比较理想的方式是数据和实现分离（类COM机制），控制好权限（各种受限语法支持），在保证安全性的同时保留一定的可扩展性。

事实上，还有一批通用的 ERC 协议。 遵循这些协议规范的开发者将很容易与第三方对接，通过阅读更多他人提交的提案，他们将在自己的开发中获益良多。

05

—

ETH应用最终模型

说了这么多，我们把最简单的模型稍微提炼一下。

大体结构没有变化，但与ETH相关的部分会少很多。 这就是我想传达的。 DAPP开发其实并没有那么特别。

推荐

—

知识星球

呆子归众官方区块链社区——最懂区块链的人都在这里。

过去的建议：