A. 区块链和智能合约,以太坊开发,183位开发者整理,知识体系汇总
在以太坊上开发应用程序的可用工具、组件、模式和平台的指南。
此列表的创建是由 ConsenSys 的产品经理推动的,他们认为需要在新的和有经验的区块链开发人员之间更好地共享工具、开发模式和组件。
开发智能合约
智能合约语言
构架
IDE
其他工具
测试区块链网络
测试以太水龙头
前端以太坊 API
后端以太坊 API
引导程序/开箱即用工具
以太坊 ABI(应用程序二进制接口)工具
以太坊客户端
贮存
Mahuta - 具有附加搜索功能的 IPFS 存储服务,以前称为 IPFS-Store
OrbitDB - IPFS 之上的去中心化数据库
JS IPFS API - IPFS HTTP API 的客户端库,用 JavaScript 实现
TEMPORAL - 易于使用的 API 到 IPFS 和其他分布式/去中心化存储协议
PINATA - 使用 IPFS 的最简单方法
消息传递
测试工具
安全工具
监控
其他杂项工具
Cheshire - CryptoKitties API 和智能合约的本地沙箱实现,可作为 Truffle Box 使用
ERCs-以太坊评论请求存储库
ERC-20 - 可替代资产的原始令牌合约
ERC-721 - 不可替代资产的令牌标准
ERC-777 - 可替代资产的改进令牌标准
ERC-918 - 可开采令牌标准
流行的智能合约库
可扩展性
支付/状态通道
等离子体
侧链
POA桥
POA 桥用户界面
POA 桥梁合同
ZK-SNARK
ZK-STARK
预构建的 UI 组件
以上内容,来自git库:
github.com/ConsenSys/ethereum-developer-tools-list
我是鱼歌,一个在深圳创业的全栈程序员,主攻区块链,元宇宙和智能合约,附加小程序和app开发。
[祈祷]
B. DApp开发入门
本文仅介绍以太坊系列的DApp开发,其他链原理差不太多。
MetaMask安装完成并运行后,可以在Chrome控制台打印 MetaMask注入的window.ethereum对象
关于ethereum对象,我们只需要关心 ethereum.request 就足够了,MetaMask 使用 ethereum.request(args) 方法 来包装 RPC API。这些 API 基于所有以太坊客户端公开的接口。 简单来说钱包交互的大部分操作都是由 request() 方法实现,通过传入不同的方法名来区分。
⚠️ 即使ethereum对象中提供了chainId,isMetaMask,selectAddress属性,我们也不能完全相信这些属性,他们是不稳定或不标准,不建议使用。我们可以通过上面说的request方法,拿到可靠的数据 。
钱包通过method方法名,进行对应的实现 以获取钱包地址为例
调用 ethereum.request({ method: "eth_requestAccounts" }) ,钱包实现了该方法,那么就可以拿到钱包的地址了。
MetaMask注入的 window.ethereum 就是一个Provider,一个RPC节点也是一个Provider,通过Provider,我们有了访问区块链的能力。 在连接到钱包的情况下,通常使用钱包的Provider就可以了, ethers.providers.Web3Provider(ethereum)
如果只需要查询一些区块链数据,可以使用EtherscanProvider 和 InfuraProvider 连接公开的 第三方节点服务提供商 。JsonRpcProvider 和 IpcProvider 允许连接到我们控制或可以访问的以太坊节点。
获取当前账户余额
获取最新区块号
其他RPC操作,可以通过 JSON-RPC 查看。
通过 ethers.js 可以连接ERC20的合约,合约编译后会生成ABI,合约部署后,会生成合约地址,开发者通过 ABI和合约地址 ,对合约发送消息。
合约中的方法大致分为两种: 视图方法(免费),非视图方法(消耗Gas) ,可以通过ABI查看方法类型。
⚠️ ERC20需要多加关注的是 Approve() 方法以及 transfer() 和 transferFrom() 的区别 ,授权过的代币,被授权的那一方,可以通过调用 transferFrom() 方法,转走你授权数量内的代币,所以授权是一个很危险的操作,假设你授权了一个不良的合约,那你会面临授权的token被转走的风险,即使你没有泄露私钥助记词。
便利三方库: web3-react use-wallet
文档: doc.metamask.io ethers
C. 怎么在windows下启动以太坊java客户端ethereumj
以太坊源码go-ethereum怎么运行
安装基于缓卖腔MIPS的linux头文件
$ cd $PRJROOT/kernel
$ tar -xjvf linux-2.6.38.tar.bz2
$ cd linux-2.6.38
在指定路径下创建include文件夹,用来存放相关头文件配高。
$ mkdir -p $TARGET_PREFIX/include
保证linux源码是干扰衫净的。
$ make mrproper
生成需要的头文件。
$ make ARCH=mips headers_check
$ make ARCH=mips INSTALL_HDR_PATH=dest headers_install
将dest文件夹下的所有文件复制到指定的include文件夹内。
$ cp -rv dest/include/* $TARGET_PREFIX/include
最后删除dest文件夹
$ rm -rf dest
$ ls -l $TARGET_PREFIX/include
D. 轻用户是什么意思
什么是轻客户端?为什么你需要了解它
播报文章
在以太坊的案例中,过去只有一种类型的节点,现在称为全节点。这个软件负责验证和转播网络上的交易和区块。由于无信任环境(开放的互联网)和区块链的性质,每个全节点需要下载并验证每个区块,所以就是在每个区块中验证每一笔交易。
Parity Ethereum 和 Geth 这两个最受欢迎的以太坊客户端,今天都可以在一台中等功率的笔记本电脑上运行。然而,下载和验证整个区块链的区块是需要时间和资源的。例如,现在需要使用 SSD 来完全同步以太坊区块链。HDD 无法跟上每秒所需的输入/输出操作。
全节点使用案例
现在,组织和个人运行全节点是因为他们的业务需要。想想矿工、区块浏览器、交易所。个人用户可能希望运行全节点,因为这是与区块链交互的最安全方式。在一个更小的范围内,他们也可能是纯粹的利他主义来帮助网络。7*24 小时全天候的运行一个全节点需要良好的知识和资源水平,大多数用户不愿意投资是可以理解的。除了矿工,没有什么内置的激励来运行一个全节点,尽管这部分基础设施对网络至关重要。
因此,大多数与区块链交互的用户,不管是否自愿,都会使用一个中心的基础设施。最流行的软件钱包默认依赖于第三方托管的节点。这些客户端连接到远程节点,并以非密码验证的方式完全信任其响应。它的积极方面显然是增强了用户体验,因为这些钱包的用户不需要运行自己的节点。但是,它们被迫信任第三方节点。默认情况下,Metamask、MyEtherWallet 和 MyCrypto 连接到远程节点,但如果用户愿意,仍然允许他们连接到自己的本地节点。这不是 Jaxx 或 Exos 钱包的情况,它们默认连接到远程节点,而没有连接到用户自己的本地节点的选项。这里没有提到移动钱包,因为手机无法运行全节点。
像 Infura 这样的公司致力于运行全节点,并免费提供给那些需要它们的人。抽象出同步一个全节点的麻烦,允许任何用户轻松地访问区块链。这样的解决方案有助于让更多用户能够访问以太坊。然而,尽管这一举措是对生态系统的一个重大补充,但它代表了一个中心化的单一失败点,与去中心化的区块链理念背道而驰。直到几个月前,钱包开发商还没有其他选择。
“我们的目标是创建一个兼容不同程度‘轻’的协议,从几乎不存储任何内容的客户端到几乎存储所有内容的客户端。”
— PIP, Parity Light Protocol(https://wiki.parity.io/The-Parity-Light-Protocol-%28PIP%29)
轻量级替代方案:轻客户端
轻客户端或轻节点是连接到全节点与区块链交互的软件。与全节点对应节点不同,轻节点不需要运行 24/7 或读写区块链上的大量信息。事实上,轻客户端并不直接与区块链交互,而是使用全节点作为中介。轻客户端依赖于全节点去执行许多操作,从请求最新的区块头到请求帐户中的余额。
轻客户端协议的设计方式允许它们以最小信任的方式与全节点交互。这是一个需要理解的关键方面,因此让我们回顾一下以太坊区块链的基础知识:
1. 普通用户使用全节点、轻节点或受信任的远程节点在网络上发送交易。
2. 全节点从网络上的对等节点接收交易,检查这些交易的有效性,并将它们广播到网络。
3. 矿工是连接到特定软件的全节点。他们像一个普通的全节点一样从网络上接收和验证交易,但是会额外投入大量的精力来寻找问题的解决方案,才会被允许生成下一个区块。矿工使用的全节点通过应该将哪个区块添加到区块链并构建在其上达成共识。任何在其上构建了至少 10 个块的块都被认为是安全的,因为它包含的交易被还原的概率非常低。
现在,回到我们的轻客户端。作为起点,轻客户端需要下载区块链的区块头。轻客户端不需要为它对全节点的每个请求去信任全节点。这是因为区块头包含一个名为 Merkle 树根的信息。Merkle 树根就是区块链上有账户余额和智能合约存储的所有信息的指纹。如果有任何微小的信息改变,这个指纹也会改变。假设大多数矿工都是诚实的,那么区块头和他们所包含的指纹就被认为是有效的。轻客户端可能需要从全节点请求信息,例如特定帐户的余额。轻客户端知道每个区块的指纹,就可以验证全节点给出的答案是否与其拥有的指纹匹配。这是一个强有力的工具,可以在事先不知情的情况下证明信息的真实性。
由于轻客户端需要发送多个请求来执行简单的操作,因此所需的总体网络带宽高于全节点的带宽。另一方面,所需的资源和存储量比全节点的资源和存储量低几个数量级,同时实现了非常高的安全级别。只需要大约 100MB 的存储空间和较低的计算能力,轻节点就可以在移动设备上运行!这意味着手机可以以去中心化的方式访问区块链。
因为只需要一个全节点的一小部分信息,所以一个轻节点可以更快地与区块链同步。目前,将整个以太坊主网区块链同步,轻客户端大约只需要一个小时,但节点同步超过几秒对任何应用程序来说都太多了。为轻客户端开发的解决方案可以快速与区块链顶部同步,尽管这些解决方案通常需要权衡。目前,轻客户端在其代码中内置了一个可信的区块链检查点。正因为如此,客户端只需要下载最新的区块头文件,就可以在几秒钟内实现同步。轻客户端用户信任客户端开发人员集成有效的检查点。这种折衷被认为是可以接受的,因为用户已经需要信任客户端实现的开发人员。为了以去中心化的方式快速执行同步,Parity Technologie 目前开发了一种替代解决方案,允许轻客户端以与全节点类似的方式执行扭曲同步(https://wiki.parity.io/Warp-Sync)。
未来,轻客户端会遍布各地。 — Marty McFly
轻客户端的挑战
轻客户端非常适合主流应用,例如发送一些交易和验证帐户余额。对轻客户端的主要批评是,轻客户端不能直接帮助网络。它们不验证除自己需要的信息以外的任何其他信息,也不从网络向其他对等节点提供或转播信息,它们使用来自全节点的资源,而不提供任何的回报。
与全节点相比,轻客户端提供了更好的最终用户体验,同时允许最终用户以去中心化的和安全的方式访问区块链。关键是要找到一种激励个人和机构的方式去运行全节点、服务轻节点、惩罚服务坏数据的恶意全节点。使轻客户端可持续发展的一种方法是让他们对全节点发出的每个请求执行小额支付。在不久的将来,轻客户端将在以太坊分片中扮演重要角色,让验证节点快速同步不同的分片。轻客户端还可用于报告恶意参与者(验证节点或 plasma 权限)。轻客户端对全节点的激励是一个活跃的研究领域,因为激励是生态系统稳定的关键。
有一些很有前途的想法可以让轻客户端快速同步,同时避免前面提到的折衷方案。一种想法是允许全节点提供最新的已知区块头的零知识证明(例如,zk-STARK https://eprint.iacr.org/2018/046.pdf)。然后,轻客户端可以验证它并与链的顶部同步,而无需事先知道区块链的状态。
总之,在短期内,轻客户端将成为去中心化应用程序的骨干,这对用户友好的分布式生态系统来说是一个非常好的消息。
E. 选择以太坊客户端
有很多以太坊客户端供我们选择。我们推荐在开发和部署时使用不同的客户端。
我们推荐 Ganache ,它是一个运行在你个人电脑上的私有连客户端。它是 truffle 套种中的一部分,
Ganache 将智能合约和交易放在前台并且中心化,从而简化了dapp的开发。使用 Ganache 你可以
快速查看你们的应用是如何影响区块链的,并且对账户,余额,智能合约创建以及燃料消费进行自省。
Ganache 运行在 http://127.0.0.1:7545 。默认会创建是个账户,重启后账户依然不会变,
当然也可以手动随机账户,你也可以用你自己的账户。
我们同样也推荐使用 truffle develop ,它是 truffle 内置的开发链工具。不需要任何的额外安装,
你要使用它只需要一条命令行即可:
Truffle Develop 运行在 http://127.0.0.1:9545 上。
当你的开发机没有图形界面时就无法直接使用 Ganache ,而 Ganache CLI 就提供了没有图形界面系统的能力。
有很多官方和非官网的以太坊客户端你可以选择。以下是部分:
F. 以太坊源码分析--p2p节点发现
节点发现功能主要涉及 Server Table udp 这几个数据结构,它们有独自的事件响应循环,节点发现功能便是它们互相协作完成的。其中,每个以太坊客户端启动后都会在本地运行一个 Server ,并将网络拓扑中相邻的节点视为 Node ,而 Table 是 Node 的容器, udp 则是负责维持底层的连接。下面重点描述它们中重要的字段和事件循环处理的关键部分。
PrivateKey - 本节点的私钥,用于与其他节点建立时的握手协商
Protocols - 支持的所有上层协议
StaticNodes - 预设的静态 Peer ,节点启动时会首先去向它们发起连接,建立邻居关系
newTransport - 下层传输层实现,定义握手过程中的数据加密解密方式,默认的传输层实现是用 newRLPX() 创建的 rlpx ,这不是本文的重点
ntab - 典型实现是 Table ,所有 peer 以 Node 的形式存放在 Table
ourHandshake - 与其他节点建立连接时的握手信息,包含本地节点的版本号以及支持的上层协议
addpeer - 连接握手完成后,连接过程通过这个通道通知 Server
Server 的监听循环,启动底层监听socket,当收到连接请求时,Accept后调用 setupConn() 开始连接建立过程
Server的主要事件处理和功能实现循环
Node 唯一表示网络上的一个节点
IP - IP地址
UDP/TCP - 连接使用的UDP/TCP端口号
ID - 以太坊网络中唯一标识一个节点,本质上是一个椭圆曲线公钥(PublicKey),与 Server 的 PrivateKey 对应。一个节点的IP地址不一定是固定的,但ID是唯一的。
sha - 用于节点间的距离计算
Table 主要用来管理与本节点与其他节点的连接的建立更新删除
bucket - 所有 peer 按与本节点的距离远近放在不同的桶(bucket)中,详见之后的 节点维护
refreshReq - 更新 Table 请求通道
Table 的主要事件循环,主要负责控制 refresh 和 revalidate 过程。
refresh.C - 定时(30s)启动Peer刷新过程的定时器
refreshReq - 接收其他线程投递到 Table 的 刷新Peer连接 的通知,当收到该通知时启动更新,详见之后的 更新邻居关系
revalidate.C - 定时重新检查以连接节点的有效性的定时器,详见之后的 探活检测
udp 负责节点间通信的底层消息控制,是 Table 运行的 Kademlia 协议的底层组件
conn - 底层监听端口的连接
addpending - udp 用来接收 pending 的channel。使用场景为:当我们向其他节点发送数据包后(packet)后可能会期待收到它的回复,pending用来记录一次这种还没有到来的回复。举个例子,当我们发送ping包时,总是期待对方回复pong包。这时就可以将构造一个pending结构,其中包含期待接收的pong包的信息以及对应的callback函数,将这个pengding投递到udp的这个channel。 udp 在收到匹配的pong后,执行预设的callback。
gotreply - udp 用来接收其他节点回复的通道,配合上面的addpending,收到回复后,遍历已有的pending链表,看是否有匹配的pending。
Table - 和 Server 中的ntab是同一个 Table
udp 的处理循环,负责控制消息的向上递交和收发控制
udp 的底层接受数据包循环,负责接收其他节点的 packet
以太坊使用 Kademlia 分布式路由存储协议来进行网络拓扑维护,了解该协议建议先阅读 易懂分布式 。更权威的资料可以查看 wiki 。总的来说该协议:
源码中由 Table 结构保存所有 bucket , bucket 结构如下
节点可以在 entries 和 replacements 互相转化,一个 entries 节点如果 Validate 失败,那么它会被原本将一个原本在 replacements 数组的节点替换。
有效性检测就是利用 ping 消息进行探活操作。 Table.loop() 启动了一个定时器(0~10s),定期随机选择一个bucket,向其 entries 中末尾的节点发送 ping 消息,如果对方回应了 pong ,则探活成功。
Table.loop() 会定期(定时器超时)或不定期(收到refreshReq)地进行更新邻居关系(发现新邻居),两者都调用 doRefresh() 方法,该方法对在网络上查找离自身和三个随机节点最近的若干个节点。
Table 的 lookup() 方法用来实现节点查找目标节点,它的实现就是 Kademlia 协议,通过节点间的接力,一步一步接近目标。
当一个节点启动后,它会首先向配置的静态节点发起连接,发起连接的过程称为 Dial ,源码中通过创建 dialTask 跟踪这个过程
dialTask表示一次向其他节点主动发起连接的任务
在 Server 启动时,会调用 newDialState() 根据预配置的 StaticNodes 初始化一批 dialTask , 并在 Server.run() 方法中,启动这些这些任务。
Dial 过程需要知道目标节点( dest )的IP地址,如果不知道的话,就要先使用 recolve() 解析出目标的IP地址,怎么解析?就是先要用借助 Kademlia 协议在网络中查找目标节点。
当得到目标节点的IP后,下一步便是建立连接,这是通过 dialTask.dial() 建立连接
连接建立的握手过程分为两个阶段,在在 SetupConn() 中实现
第一阶段为 ECDH密钥建立 :
第二阶段为协议握手,互相交换支持的上层协议
如果两次握手都通过,dialTask将向 Server 的 addpeer 通道发送 peer 的信息
G. 以太坊架构是怎么样的
以太坊最上层的是DApp。它通过Web3.js和智能合约层进行交换。所有的智能合约都运行在EVM(以太坊虚拟机)上,并会用到RPC的调用。在EVM和RPC下面是以太坊的四大核心内容,包括:blockChain, 共识算法,挖矿以及网络层。除了DApp外,其他的所有部分都在以太坊的客户端里,目前最流行的以太坊客户端就是Geth(Go-Ethereum)
H. 怎么接以太坊公链
建立连接以接儒以太坊公链。
一、1、以太坊客户端下载,注意:需翻墙,下载版本为1.8.23-stable,否则可能出现与以太坊钱包客户端存在不匹配问题。
2、以太坊钱包客户端下载。
3、安装以太坊客户端。
二、私有链创建:创建创世区块。
三、安装并启动以太坊钱包客户端。
I. 011:Ethash算法|《ETH原理与智能合约开发》笔记
待字闺中开发了一门区块链方面的课程:《深入浅出ETH原理与智能合约开发》,马良老师讲授。此文集记录我的学习笔记。
课程共8节课。其中,前四课讲ETH原理,后四课讲智能合约。
第四课分为三部分:
这篇文章是第四课第一部分的学习笔记:Ethash算法。
这节课介绍的是以太坊非常核心的挖矿算法。
在介绍Ethash算法之前,先讲一些背景知识。其实区块链技术主要是解决一个共识的问题,而共识是一个层次很丰富的概念,这里把范畴缩小,只讨论区块链中的共识。
什么是共识?
在区块链中,共识是指哪个节点有记账权。网络中有多个节点,理论上都有记账权,首先面临的问题就是,到底谁来记帐。另一个问题,交易一定是有顺序的,即谁在前,前在后。这样可以解决双花问题。区块链中的共识机制就是解决这两个问题,谁记帐和交易的顺序。
什么是工作量证明算法
为了决定众多节点中谁来记帐,可以有多种方案。其中,工作量证明就让节点去算一个哈希值,满足难度目标值的胜出。这个过程只能通过枚举计算,谁算的快,谁获胜的概率大。收益跟节点的工作量有关,这就是工作量证明算法。
为什么要引入工作量证明算法?
Hash Cash 由Adam Back 在1997年发表,中本聪首次在比特币中应用来解决共识问题。
它最初用来解决垃圾邮件问题。
其主要设计思想是通过暴力搜索,找到一种Block头部组合(通过调整nonce)使得嵌套的SHA256单向散列值输出小于一个特定的值(Target)。
这个算法是计算密集型算法,一开始从CPU挖矿,转而为GPU,转而为FPGA,转而为ASIC,从而使得算力变得非常集中。
算力集中就会带来一个问题,若有一个矿池的算力达到51%,则它就会有作恶的风险。这是比特币等使用工作量证明算法的系统的弊端。而以太坊则吸取了这个教训,进行了一些改进,诞生了Ethash算法。
Ethash算法吸取了比特币的教训,专门设计了非常不利用计算的模型,它采用了I/O密集的模型,I/O慢,计算再快也没用。这样,对专用集成电路则不是那么有效。
该算法对GPU友好。一是考虑如果只支持CPU,担心易被木马攻击;二是现在的显存都很大。
轻型客户端的算法不适于挖矿,易于验证;快速启动
算法中,主要依赖于Keccake256 。
数据源除了传统的Block头部,还引入了随机数阵列DAG(有向非循环图)(Vitalik提出)
种子值很小。根据种子值生成缓存值,缓存层的初始值为16M,每个世代增加128K。
在缓存层之下是矿工使用的数据值,数据层的初始值是1G,每个世代增加8M。整个数据层的大小是128Bytes的素数倍。
框架主要分为两个部分,一是DAG的生成,二是用Hashimoto来计算最终的结果。
DAG分为三个层次,种子层,缓存层,数据层。三个层次是逐渐增大的。
种子层很小,依赖上个世代的种子层。
缓存层的第一个数据是根据种子层生成的,后面的根据前面的一个来生成,它是一个串行化的过程。其初始大小是16M,每个世代增加128K。每个元素64字节。
数据层就是要用到的数据,其初始大小1G,现在约2个G,每个元素128字节。数据层的元素依赖缓存层的256个元素。
整个流程是内存密集型。
首先是头部信息和随机数结合在一起,做一个Keccak运算,获得初始的单向散列值Mix[0],128字节。然后,通过另外一个函数,映射到DAG上,获取一个值,再与Mix[0]混合得到Mix[1],如此循环64次,得到Mix[64],128字节。
接下来经过后处理过程,得到 mix final 值,32字节。(这个值在前面两个小节《 009:GHOST协议 》、《 010:搭建测试网络 》都出现过)
再经过计算,得出结果。把它和目标值相比较,小于则挖矿成功。
难度值大,目标值小,就越难(前面需要的 0 越多)。
这个过程也是挖矿难,验证容易。
为防止矿机,mix function函数也有更新过。
难度公式见课件截图。
根据上一个区块的难度,来推算下一个。
从公式看出,难度由三部分组成,首先是上一区块的难度,然后是线性部分,最后是非线性部分。
非线性部分也叫难度炸弹,在过了一个特定的时间节点后,难度是指数上升。如此设计,其背后的目的是,在以太坊的项目周期中,在大都会版本后的下一个版本中,要转换共识,由POW变为POW、POS混合型的协议。基金会的意思可能是使得挖矿变得没意思。
难度曲线图显示,2017年10月,难度有一个大的下降,奖励也由5个变为3个。
本节主要介绍了Ethash算法,不足之处,请批评指正。
J. 以太坊是什么丨以太坊开发入门指南
以太坊是什么丨以太坊开发入门指南
很多同学已经跃跃欲试投入到区块链开发队伍当中来,可是又感觉无从下手,本文将基于以太坊平台,以通俗的方式介绍以太坊开发中涉及的各晦涩的概念,轻松带大家入门。
以太坊是什么
以太坊(Ethereum)是一个建立在区块链技术之上, 去中心化应用平台。它允许任何人在平台中建立和使用通过区块链技术运行的去中心化应用。
对这句话不理解的同学,姑且可以理解为以太坊是区块链里的Android,它是一个开发平台,让我们就可以像基于Android Framework一样基于区块链技术写应用。
在没有以太坊之前,写区块链应用是这样的:拷贝一份比特币代码,然后去改底层代码如加密算法,共识机制,网络协议等等(很多山寨币就是这样,改改就出来一个新币)。
以太坊平台对底层区块链技术进行了封装,让区块链应用开发者可以直接基于以太坊平台进行开发,开发者只要专注于应用本身的开发,从而大大降低了难度。
目前围绕以太坊已经形成了一个较为完善的开发生态圈:有社区的支持,有很多开发框架、工具可以选择。
智能合约
什么是智能合约
以太坊上的程序称之为智能合约, 它是代码和数据(状态)的集合。
智能合约可以理解为在区块链上可以自动执行的(由事件驱动的)、以代码形式编写的合同(特殊的交易)。
在比特币脚本中,我们讲到过比特币的交易是可以编程的,但是比特币脚本有很多的限制,能够编写的程序也有限,而以太坊则更加完备(在计算机科学术语中,称它为是“图灵完备的”),让我们就像使用任何高级语言一样来编写几乎可以做任何事情的程序(智能合约)。
智能合约非常适合对信任、安全和持久性要求较高的应用场景,比如:数字货币、数字资产、投票、保险、金融应用、预测市场、产权所有权管理、物联网、点对点交易等等。
目前除数字货币之外,真正落地的应用还不多(就像移动平台刚开始出来一样),相信1到3年内,各种杀手级会慢慢出现。
编程语言:Solidity
智能合约的默认的编程语言是Solidity,文件扩展名以.sol结尾。
Solidity是和JavaScript相似的语言,用它来开发合约并编译成以太坊虚拟机字节代码。
还有长像Python的智能合约开发语言:Serpent,不过建议大家还是使用Solidity。
Browser-Solidity是一个浏览器的Solidity IDE, 大家可以点进去看看,以后我们更多文章介绍Solidity这个语言。
运行环境:EVM
EVM(Ethereum Virtual Machine)以太坊虚拟机是以太坊中智能合约的运行环境。
Solidity之于EVM,就像之于跟JVM的关系一样,这样大家就容易理解了。
以太坊虚拟机是一个隔离的环境,在EVM内部运行的代码不能跟外部有联系。
而EVM运行在以太坊节点上,当我们把合约部署到以太坊网络上之后,合约就可以在以太坊网络中运行了。
合约的编译
以太坊虚拟机上运行的是合约的字节码形式,需要我们在部署之前先对合约进行编译,可以选择Browser-Solidity Web IDE或solc编译器。
合约的部署
在以太坊上开发应用时,常常要使用到以太坊客户端(钱包)。平时我们在开发中,一般不接触到客户端或钱包的概念,它是什么呢?
以太坊客户端(钱包)
以太坊客户端,其实我们可以把它理解为一个开发者工具,它提供账户管理、挖矿、转账、智能合约的部署和执行等等功能。
EVM是由以太坊客户端提供的。
Geth是典型的开发以太坊时使用的客户端,基于Go语言开发。 Geth提供了一个交互式命令控制台,通过命令控制台中包含了以太坊的各种功能(API)。Geth的使用我们之后会有文章介绍,这里大家先有个概念。
Geth控制台和Chrome浏览器开发者工具里的面的控制台是类似,不过是跑在终端里。
相对于Geth,Mist则是图形化操作界面的以太坊客户端。
如何部署
智能合约的部署是指把合约字节码发布到区块链上,并使用一个特定的地址来标示这个合约,这个地址称为合约账户。
以太坊中有两类账户:
· 外部账户
该类账户被私钥控制(由人控制),没有关联任何代码。
· 合约账户
该类账户被它们的合约代码控制且有代码与之关联。
和比特币使用UTXO的设计不一样,以太坊使用更为简单的账户概念。
两类账户对于EVM来说是一样的。
外部账户与合约账户的区别和关系是这样的:一个外部账户可以通过创建和用自己的私钥来对交易进行签名,来发送消息给另一个外部账户或合约账户。
在两个外部账户之间传送消息是价值转移的过程。但从外部账户到合约账户的消息会激活合约账户的代码,允许它执行各种动作(比如转移代币,写入内部存储,挖出一个新代币,执行一些运算,创建一个新的合约等等)。
只有当外部账户发出指令时,合同账户才会执行相应的操作。
合约部署就是将编译好的合约字节码通过外部账号发送交易的形式部署到以太坊区块链上(由实际矿工出块之后,才真正部署成功)。
运行
合约部署之后,当需要调用这个智能合约的方法时只需要向这个合约账户发送消息(交易)即可,通过消息触发后智能合约的代码就会在EVM中执行了。
Gas
和云计算相似,占用区块链的资源(不管是简单的转账交易,还是合约的部署和执行)同样需要付出相应的费用(天下没有免费的午餐对不对!)。
以太坊上用Gas机制来计费,Gas也可以认为是一个工作量单位,智能合约越复杂(计算步骤的数量和类型,占用的内存等),用来完成运行就需要越多Gas。
任何特定的合约所需的运行合约的Gas数量是固定的,由合约的复杂度决定。
而Gas价格由运行合约的人在提交运行合约请求的时候规定,以确定他愿意为这次交易愿意付出的费用:Gas价格(用以太币计价) * Gas数量。
Gas的目的是限制执行交易所需的工作量,同时为执行支付费用。当EVM执行交易时,Gas将按照特定规则被逐渐消耗,无论执行到什么位置,一旦Gas被耗尽,将会触发异常。当前调用帧所做的所有状态修改都将被回滚, 如果执行结束还有Gas剩余,这些Gas将被返还给发送账户。
如果没有这个限制,就会有人写出无法停止(如:死循环)的合约来阻塞网络。
因此实际上(把前面的内容串起来),我们需要一个有以太币余额的外部账户,来发起一个交易(普通交易或部署、运行一个合约),运行时,矿工收取相应的工作量费用。
以太坊网络
有些着急的同学要问了,没有以太币,要怎么进行智能合约的开发?可以选择以下方式:
选择以太坊官网测试网络Testnet
测试网络中,我们可以很容易获得免费的以太币,缺点是需要发很长时间初始化节点。
使用私有链
创建自己的以太币私有测试网络,通常也称为私有链,我们可以用它来作为一个测试环境来开发、调试和测试智能合约。
通过上面提到的Geth很容易就可以创建一个属于自己的测试网络,以太币想挖多少挖多少,也免去了同步正式网络的整个区块链数据。
使用开发者网络(模式)
相比私有链,开发者网络(模式)下,会自动分配一个有大量余额的开发者账户给我们使用。
使用模拟环境
另一个创建测试网络的方法是使用testrpc,testrpc是在本地使用内存模拟的一个以太坊环境,对于开发调试来说,更方便快捷。而且testrpc可以在启动时帮我们创建10个存有资金的测试账户。
进行合约开发时,可以在testrpc中测试通过后,再部署到Geth节点中去。
更新:testrpc 现在已经并入到Truffle 开发框架中,现在名字是Ganache CLI。
Dapp:去中心化的应用程序
以太坊社区把基于智能合约的应用称为去中心化的应用程序(DecentralizedApp)。如果我们把区块链理解为一个不可篡改的数据库,智能合约理解为和数据库打交道的程序,那就很容易理解Dapp了,一个Dapp不单单有智能合约,比如还需要有一个友好的用户界面和其他的东西。
Truffle
Truffle是Dapp开发框架,他可以帮我们处理掉大量无关紧要的小事情,让我们可以迅速开始写代码-编译-部署-测试-打包DApp这个流程。
总结
我们现在来总结一下,以太坊是平台,它让我们方便的使用区块链技术开发去中心化的应用,在这个应用中,使用Solidity来编写和区块链交互的智能合约,合约编写好后之后,我们需要用以太坊客户端用一个有余额的账户去部署及运行合约(使用Truffle框架可以更好的帮助我们做这些事情了)。为了开发方便,我们可以用Geth或testrpc来搭建一个测试网络。
注:本文中为了方便大家理解,对一些概念做了类比,有些严格来不是准确,不过我也认为对于初学者,也没有必要把每一个概念掌握的很细致和准确,学习是一个逐步深入的过程,很多时候我们会发现,过一段后,我们会对同一个东西有不一样的理解。