以太坊源码github

Ⅰ 以太坊C++源码解析（九）区块头

区块头定义位于libethcore\BlockHeader.h文件中，是一个非常简单的类，我们来看看它包含哪些重要数据：

Ⅱ 以太坊交易(tx) 分析

更多请参考: Github: https://github.com/xianfeng92/ethereum-code-analysis

其中 object 和 opcodes 是相对应的，比如 60 对应就是 operation PUSH1,合约编译后的字节码即为一组的 operation 。

合约部署其实就是实例化一个 contract 对象，并将 data 的值设给 Code属性 。

创建合约的tx中，input字段对应的是合约的字节码，即指令数组。

其中 input 字段对应所要调用的函数签名的前四个字节（771602f7）以及对应的参数（1,2）

其中 input 字段为所要调用的合约函数签名的前四个字节（72a099b7）

关于函数调用，Call会把对应的Code读出来，依次解析，Code中会把所有的public签名的函数标志（4字节）push到栈里。然后依据 input 中需要调用函数的签名标志（前4字节）来匹配 Code， 匹配之后跳转到对应的 opcode 。

Ⅲ 以太坊获取测试链代币

发起以太坊交易时需要消耗以太币，开发智能合约做测试时如果在主网做测试成本会很高，并且主网的速度也比较慢，以太坊官方考虑到大家的这个需求提供了几条测试链供大家使用，比较知名的有以下这几个

以太坊的主测试网，环境最接近主网环境，有实际的雷锋矿工在挖矿，只不过难度会比主网低很多，不过由于 Ropsten 采用与主网完全一样的 PoW 共识，有时也就会和主网一样拥堵，在这条链上做测试更容易测试出智能合约或者dapp里潜在的问题

用的是 PoA 机制，无需挖矿，所以出块很快而且很稳定

和Rinkeby同样使用的是 PoA 机制

打开这个网址 https://faucet.metamask.io/

点击 request 1 ether from faucet 按钮会通过web3连接钱包，获取到钱包当前账户的以太坊地址，这个我使用的钱包是MetaMask，如果你没有装支持web3访问的钱包，可以参考这篇文章安装
https://www.jianshu.com/p/a84fe16f1af7

点击连接

连接成功后底部会生成一笔交易，hash值

等交易确认后一个以太坊就到账了

Rinkeby获取测试币相对麻烦些，需要注册twitter账号(需要翻墙)

打开这个网址 https://twitter.com/intent/tweet?text=Requesting%20faucet%20funds%20into%%20on%20the%20%23Rinkeby%20%23Ethereum%20test%20network

把推文中替换成你的地址点击TWEET，发送成功后点击分享图标选择Copy link to Tweet，把推文的链接复制下来

然后打开Rinkeby测试币水龙头网页 https://www.rinkeby.io/#faucet

把刚才那个推文链接复制进输入框，点击Give me Ether

根据你的需要选择要多少个代币，要的越多到账越慢😓，到账时间相对其它的测试链很慢，如果着急就用别的链做测试

打开这个网址 https://faucet.kovan.network/ ，需要使用github账号登陆

登陆成功后输入以太坊地址，点击发送就好了，转账交易就提交到链上了

同样的等待交易确认就能收到一个以太币了

Ⅳ [以太坊源码分析][p2p网络07]：同步区块和交易

同步，也就是区块链的数据的同步。这里分为两种同步方式，一是本地区块链与远程节点的区块链进行同步，二是将交易均匀的同步给相邻的节点。

01.同步区块链
02.同步交易
03.总结

ProtocolManager 协议管理中的 go pm.syncer() 协程。

先启动了 fetcher ，辅助同步区块用的。然后等待不同的事件触发不同的同步方式。

同步的过程调用 pm.synchronise 方法来进行。

ProtocolManager 协议管理中的 go pm.txsyncLoop() 协程。

同步交易循环 txsyncLoop 分为三个部分的内容：

发送交易的函数。

挑选函数。

三个监听协程的 case 。

Ⅳ aBey区块链技术什么东西

希望能帮到你：

网页链接

aBey区块链技术是来自于罗马尼亚蒂米什瓦拉西部大学 数学与信息学院 计算机科学系的两位人工智能系博士：Ciprian Pungila & Vorel Negru的自主研究项目。采用了恒定轻化区块链技术和多层编程及拓展的区块链解决方案。aBey的区块链规模始终保持不变，其规模仅为50个活跃区块。aBey区块链技术适用于利用电子货币在电子商务系统中进行 大批量交易，且具有多层次性、可扩展性和安全性并可进行编程。

官方白皮书声称aBey适用于电子商务系统中利用数字货币进行大批量交易 并可进行多层编程及拓展的区块链解决方案。
aBey区块链技术的具体实行方法：
利用一种多层次且可编程的区块链方法实现数字货币（为简单起见，我们称之为“DC”）。该方法可为执行各种电子商务用途（如：贷款融资、完成可退款交易和不可退款交易等）铺平道路。在区块链的第一层可实现固有的数字货币设计—即我们通常所说的基础层（“FL”）。在基础上建立的各种不同的上层，可用于描述与各种不同商业驱动型应用实例相关的各种附加功能（我们将在下文中予以简要介绍）。所有上述层级均具有完全可编程性，并且极容易经改编后，适用于各种不同的应用实例。
尽管现如今的绝大多数数字货均在区块链中储存交易差额，但aBey的方法更类似于PascalCoin数字货币。该方法使用我们称之为“Vault” 的加密结构。“Vault”结构可在网络中仅保存所有账户的余额，而不是所有已完成交易的完整清单，并可在区块链演变历史中完成重构。鉴于Vault可允许随时删除无用内容，因此可大幅降低区块链的储存成本。与此相比，在作者撰写本文时，下载比特币数据库所需的储存空间为70GB（报警率仍持续增长，预计在2019年达到300GB），因此使用储存空间较小（如，120GB或256GB）的超极本或笔记本实施挖矿操作已处于不可行状态。另一方面，aBey区块链的规模将始终保持不变，其规模仅为50个区块（在撰写本文时，比特币区块链中的区块已超过525,000个）。
Vault完全支持账户之间的数字货币转账。此外，Vault可向每个账户分配所有者界定的名称，而不是像今天的加密货币一样利用哈希算法—这可使账户更容易记忆，并且可向公众公开名称。
Vault有助于防止区块链日常费用过高（特别是与交易历史相关的费用）的重要功能之一是，Vault可通过创建有关区块链状态的安全副本，实现保存此类状态并同时降低区块链自身规模的目的。由于无需交易历史，并且所有账户均可保存其直接余额，因此区块链信息具有可部分擦除的特征。所有可储存的区块链状态均可被视为该区块链的界标。
安全数据共享:
通过区块链结构设计，对于发送到网络中的每次交易，区块链可能均包含经加密的元数据。该元数据仅可由交易接收人解密。对于向网络中发送的交易，通过在此类交易中包含发送人公钥，并由交易接收人利用公钥解密元数据实现这一目的。由于交易接收人持有用于解密的私钥，因此仅可由交易接收人实施数据解密过程。从加密方法角度来说，尽管比特币仅限于使用椭圆曲线密码学，但区块链元数据可使用任何其他加密机制完成加密过程。这不仅可在安全性选择方面提供完全的灵活性，而且不会对区块链的结构或功能造成任何不良影响。
可扩展性：
鉴于aBey区块链支持通过设计创建历史界标，因此从区块链将始终需要不断储存（与现有的最新SL有关）角度来说，网络自身将非常容易实现高扩展性。该方法完全消除了为计算所有账户的余额而储存交易历史的需要，并且可直接储存所有账户余额，进而可确保网络中所有节点提供的特定余额信息，均符合拜占庭一致性要求。
安全性和工作量证明：
根据涉及，在aBey的方法中不可能出现双向支付操作（在指定适当的场景中，现如今的绝大多数主流加密货币在理论上可能存在双向支付操作）。每次交易均意味着按照相对简单的方式更新相应账户的余额，并且无任何可将交易从网络待处理交易队里中还原的特殊方式。对于aBey区块链来说，鉴于所有技术层/功能层均建立在Vault上，因此Vault是我们区块链的基础结构，因此Vault对挖矿操作非常重要。我们提议的区块链模型由一系列区块组成，其中每个区块均由网络中自愿挖矿的节点，通过使用工作量证明模型经挖矿后生成。网络中的所有节点均可根据交易（区块的组成部分）独立更新账户余额，并与其他节点相互独立。挖矿操作将对第一功能层造成影响。除更新余额之外，每个节点还可更新区块链结构组成中，可能属于上层功能层的其他事项。一旦出现更新状况，则将创建一个全新的挖矿奖励区块。该挖矿奖励区块中包含多个全新且已分配给矿工的奖励账户。矿工根据工作量证明作为上述奖励的获得者（目前奖励账户的数量50个）。奖励的方式是向奖励获得者分配所有此类账户的公钥。
区块链技术层:
aBey的数字货币模式中包含多层结构，其中第一层表示实现数字货币自身（有关图形解释，请参阅图7）。相应层级包括：
第1层→数字货币（加密货币）：货币转让，挖矿
第2层→可退款交易和不可退款交易：允许使用数字公正系统完成可退款交易
第3层→关联方和佣金：允许向关联方自动分配佣金
第4层→接触货币：通过借出货币，基于利息获得收入
第5层→可编程：经保留后可供未来实现图灵完整编程模型使用，以便于按照自定义方式处理区块链数据 （如，智能合同等）
第6层→自定义协议：保留以供未来使用
交易类型：
aBey的模式可允许通过设计，在区块链中不同的层级，完成多种交易类型。第欱层中的交易类型如下所述：
1→资金转移：账户之间转移资金（1对1转移）
2→可退款型资金转移：账户之间的可退款交易。使用托管余额代替常规账户余额
3→密钥更改：更改可用于处理账户的密钥
4→恢复账户：从失去的，无效的账户中恢复资金
5→设置账户名称：定义创始人所持帐户的名称
6→销售准备：标记准备销售的账户
7→移出销售队列：去除账户销售标记，并将账户标记为不可销售
可退款交易和调解人：
对于绝大多数实例来说，不可退款交易等同于所有基于区块链的数字货币模式中的欱对欱付款交易。但aBey已在自己的数字货币模式中引入可退款交易概念。在aBey模式中，利用小旗标记交易属于可退款标记或不可退款交易。除此之外，在aBey的区块链网络中，每个账户都包含两种类型的余额：常规且不可变更的余额（用于标记该账户已收到且可立即支出，但支出后不可收回的金额）和托管余额（包含被标记为可退款交易的交易清单，以及每次交易的分钟数）。
8→付款争议：针对已被标记为可退款交易的相应交易，发起付款争议，但仅可由付款人发起。
9→退款请求：针对先前被标记为可退款交易的相应交易，发起退款请求，但仅可由付款人发起。
10→取消托管：取消托管资金，并立即向付款人返还资金。仅可由收款人发起。
11→解除托管：解除托管资金，并立即将金额加至收款人账户余额。仅可由付款人发起。
关联方和佣金：
当今由区块链驱动的金融科技存在的重要缺失之一是，缺乏对销售特定产品或服务的关联方提供奖励的能力。aBey区块链第3层可以解决这一问题。
借出数字货币：
借出数字货币不仅是一种允许人们借入法定货币的简单快捷方法，而且还可保证加密资产的安全。鉴于现如今的有价数字货币同样用于交易，因此借出数字货币可行的原因不仅在于允许借款人抵押其储蓄的任何类型的加密货币，而且其具有吸引力的原因在于，这也是一种可以按照完全安全或极低风险的方式，保留自身数字资产。此外，aBey的模式还通过客户Vault借出网关（VLG）提供内置保护，并使VLG可作为贷款人和借款人之间的缓冲器。
12→借入资金：由借款人在网络内发起交易、宣布借入资金的意图，并指定借入资金的VLG账户。该交易类似于在选定的VLG账户中存入常规/托管账户余额
13→返还抵押品：由VLG自身发起交易。VLG将按照风险处理政策，向借款人返还抵押品。
14→偿还贷款：由借款人发起交易。如果VLG接受以数字货币形式偿还贷款，则借款人可选择利用数字货币偿还贷款。在此条件下，数字货币资金将被转变为VLG常规账户余额。
可编程的区块链：
通过与其相关的元数据有效负荷，区块链的第欵层可被保留为可允许通过执行基于语法的“完全图灵基本编程语言”，按照原始区块链数据处理方式，进一步创建网络中对等方之间的智能合同。对于每个有效负荷，均可实施加密或公众可见处理，并且可在专门的虚拟环境（类似于虚拟机）中执行。该方法可有效保护数据安全并避免遭受数据破坏和安全漏洞的影响。该方法的主要优点是，该层可在无需任何区块链特定编程的条件下，创建并强制执行数字化合同。对于本层面，我们将在未来升级过程中慎重考虑该层的延伸方向，并界定实现相应功能所需的适当语法和语义环境。同时，未来建立的其他层级（第6层、第7层和更高层级）可用于按照需求，扩展适用于更多使用案例的相关协议。但其缺点在于，实现上述功能将需要区块链自身完成“软分叉”或“硬分叉”过程。
实验结果：
aBey当前正在实施相关实验，并将在全球最大的开源平台—GitHub上公布实验结果。

Ⅵ 智能合约solidity项目部署流程

开发环境：vscode
参考： Solidity的Truffle框架实战(手把手)

如果项目已经存在，需在项目内执行 npm install

修改truffle.js

参考： 以太坊开发框架truffle入门指南-01

参考： 【区块链】Truffle 部署和测试

注意：测试和部署前，先启动服务器

源码：
https://github.com/xiaoyifan6/solidityExample

Ⅶ 【深度知识】以太坊数据序列化RLP编码/解码原理

RLP(Recursive Length Prefix)，中文翻译过来叫递归长度前缀编码，它是以太坊序列化所采用的编码方式。RLP主要用于以太坊中数据的网络传输和持久化存储。

对象序列化方法有很多种，常见的像JSON编码，但是JSON有个明显的缺点：编码结果比较大。例如有如下的结构：

变量s序列化的结果是{"name":"icattlecoder","sex":"male"},字符串长度35，实际有效数据是icattlecoder 和male，共计16个字节，我们可以看到JSON的序列化时引入了太多的冗余信息。假设以太坊采用JSON来序列化，那么本来50GB的区块链可能现在就要100GB，当然实际没这么简单。

所以，以太坊需要设计一种结果更小的编码方法。

RLP编码的定义只处理两类数据：一类是字符串（例如字节数组），一类是列表。字符串指的是一串二进制数据，列表是一个嵌套递归的结构，里面可以包含字符串和列表，例如["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]就是一个复杂的列表。其他类型的数据需要转成以上的两类，转换的规则不是RLP编码定义的，可以根据自己的规则转换，例如struct可以转成列表，int可以转成二进制（属于字符串一类），以太坊中整数都以大端形式存储。

从RLP编码的名字可以看出它的特点：一个是递归，被编码的数据是递归的结构，编码算法也是递归进行处理的；二是长度前缀，也就是RLP编码都带有一个前缀，这个前缀是跟被编码数据的长度相关的，从下面的编码规则中可以看出这一点。

对于值在[0, 127]之间的单个字节，其编码是其本身。

例1：a的编码是97。

如果byte数组长度l <= 55，编码的结果是数组本身，再加上128+l作为前缀。

例2：空字符串编码是128，即128 = 128 + 0。

例3：abc编码结果是131 97 98 99，其中131=128+len("abc")，97 98 99依次是a b c。

如果数组长度大于55， 编码结果第一个是183加数组长度的编码的长度，然后是数组长度的本身的编码，最后是byte数组的编码。

请把上面的规则多读几篇，特别是数组长度的编码的长度。

例4：编码下面这段字符串：

The length of this sentence is more than 55 bytes, I know it because I pre-designed it
这段字符串共86个字节，而86的编码只需要一个字节，那就是它自己，因此，编码的结果如下：

184 86 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前三个字节的计算方式如下：

184 = 183 + 1，因为数组长度86编码后仅占用一个字节。
86即数组长度86
84是T的编码
例5：编码一个重复1024次"a"的字符串，其结果为：185 4 0 97 97 97 97 97 97 ...。
1024按 big endian编码为004 0，省略掉前面的零，长度为2，因此185 = 183 + 2。

规则1~3定义了byte数组的编码方案，下面介绍列表的编码规则。在此之前，我们先定义列表长度是指子列表编码后的长度之和。

如果列表长度小于55，编码结果第一位是192加列表长度的编码的长度，然后依次连接各子列表的编码。

注意规则4本身是递归定义的。
例6：["abc", "def"]的编码结果是200 131 97 98 99 131 100 101 102。
其中abc的编码为131 97 98 99,def的编码为131 100 101 102。两个子字符串的编码后总长度是8，因此编码结果第一位计算得出：192 + 8 = 200。

如果列表长度超过55，编码结果第一位是247加列表长度的编码长度，然后是列表长度本身的编码，最后依次连接各子列表的编码。

规则5本身也是递归定义的，和规则3相似。

例7：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
的编码结果是:

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前两个字节的计算方式如下：

248 = 247 +1
88 = 86 + 2，在规则3的示例中，长度为86，而在此例中，由于有两个子字符串，每个子字符串本身的长度的编码各占1字节，因此总共占2字节。
第3个字节179依据规则2得出179 = 128 + 51
第55个字节163同样依据规则2得出163 = 128 + 35

例8：最后我们再来看个稍复杂点的例子以加深理解递归长度前缀，

["abc",["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]]
编码结果是：

248 94 131 97 98 99 248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
列表第一项字符串abc根据规则2，编码结果为131 97 98 99,长度为4。
列表第二项也是一个列表项：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
根据规则5，结果为

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
长度为90，因此，整个列表的编码结果第二位是90 + 4 = 94, 占用1个字节，第一位247 + 1 = 248

以上5条就是RPL的全部编码规则。

各语言在具体实现RLP编码时，首先需要将对像映射成byte数组或列表两种形式。以go语言编码struct为例，会将其映射为列表，例如Student这个对象处理成列表["icattlecoder","male"]

如果编码map类型，可以采用以下列表形式：

[["",""],["",""],["",""]]

解码时，首先根据编码结果第一个字节f的大小，执行以下的规则判断：

1.如果f∈ [0,128),那么它是一个字节本身。

2.如果f∈[128,184)，那么它是一个长度不超过55的byte数组，数组的长度为 l=f-128

3.如果f∈[184,192)，那么它是一个长度超过55的数组，长度本身的编码长度ll=f-183,然后从第二个字节开始读取长度为ll的bytes，按照BigEndian编码成整数l，l即为数组的长度。

4.如果f∈(192,247]，那么它是一个编码后总长度不超过55的列表，列表长度为l=f-192。递归使用规则1~4进行解码。

5.如果f∈(247,256]，那么它是编码后长度大于55的列表，其长度本身的编码长度ll=f-247,然后从第二个字节读取长度为ll的bytes,按BigEndian编码成整数l，l即为子列表长度。然后递归根据解码规则进行解码。

以上解释了什么叫递归长度前缀编码，这个名字本身很好的解释了编码规则。

（1） 以太坊源码学习—RLP编码( https://segmentfault.com/a/1190000011763339 )
（2）简单分析RLP编码原理
( https://blog.csdn.net/itchosen/article/details/78183991 )

Ⅷ 一学就会，手把手教你用Go语言调用智能合约

智能合约调用是实现一个 DApp 的关键，一个完整的 DApp 包括前端、后端、智能合约及区块 链系统，智能合约的调用是连接区块链与前后端的关键。

我们先来了解一下智能合约调用的基础原理。智能合约运行在以太坊节点的 EVM 中。因此要 想调用合约必须要访问某个节点。

以后端程序为例，后端服务若想连接节点有两种可能，一种是双 方在同一主机，此时后端连接节点可以采用 本地 IPC(Inter-Process Communication，进 程间通信)机制，也可以采用 RPC(Remote Procere Call，远程过程调用)机制;另 一种情况是双方不在同一台主机，此时只能采用 RPC 机制进行通信。

提到 RPC， 读者应该对 Geth 启动参数有点印象，Geth 启动时可以选择开启 RPC 服务，对应的 默认服务端口是 8545。。

接着，我们来了解一下智能合约运行的过程。

智能合约的运行过程是后端服务连接某节点，将 智能合约的调用(交易)发送给节点，节点在验证了交易的合法性后进行全网广播，被矿工打包到 区块中代表此交易得到确认，至此交易才算完成。

就像数据库一样，每个区块链平台都会提供主流 开发语言的 SDK(Software Development Kit，软件开发工具包)，由于 Geth 本身就是用 Go 语言 编写的，因此若想使用 Go 语言连接节点、发交易，直接在工程内导入 go-ethereum(Geth 源码) 包就可以了，剩下的问题就是流程和 API 的事情了。

总结一下，智能合约被调用的两个关键点是节点和 SDK。

由于 IPC 要求后端与节点必须在同一主机，所以很多时候开发者都会采用 RPC 模式。除了 RPC，以太坊也为开发者提供了 json- rpc 接口，本文就不展开讨论了。

接下来介绍如何使用 Go 语言，借助 go-ethereum 源码库来实现智能合约的调用。这是有固定 步骤的，我们先来说一下总体步骤，以下面的合约为例。

步骤 01:编译合约，获取合约 ABI(Application Binary Interface，应用二进制接口)。 单击【ABI】按钮拷贝合约 ABI 信息，将其粘贴到文件 calldemo.abi 中(可使用 Go 语言IDE 创建该文件，文件名可自定义，后缀最好使用 abi)。

最好能将 calldemo.abi 单独保存在一个目录下，输入“ls”命令只能看到 calldemo.abi 文件，参 考效果如下:

步骤 02:获得合约地址。注意要将合约部署到 Geth 节点。因此 Environment 选择为 Web3 Provider。

在【Environment】选项框中选择“Web3 Provider”，然后单击【Deploy】按钮。

部署后，获得合约地址为:。

步骤 03:利用 abigen 工具(Geth 工具包内的可执行程序)编译智能合约为 Go 代码。abigen 工具的作用是将 abi 文件转换为 Go 代码，命令如下:

其中各参数的含义如下。 (1)abi:是指定传入的 abi 文件。 (2)type:是指定输出文件中的基本结构类型。 (3)pkg:指定输出文件 package 名称。 (4)out:指定输出文件名。 执行后，将在代码目录下看到 funcdemo.go 文件，读者可以打开该文件欣赏一下，注意不要修改它。

步骤 04:创建 main.go，填入如下代码。 注意代码中 HexToAddress 函数内要传入该合约部署后的地址，此地址在步骤 01 中获得。

步骤 04:设置 go mod，以便工程自动识别。

前面有所提及，若要使用 Go 语言调用智能合约，需要下载 go-ethereum 工程，可以使用下面 的指令:

该指令会自动将 go-ethereum 下载到“$GOPATH/src/github.com/ethereum/go-ethereum”，这样还算 不错。不过，Go 语言自 1.11 版本后，增加了 mole 管理工程的模式。只要设置好了 go mod，下载 依赖工程的事情就不必关心了。

接下来设置 mole 生效和 GOPROXY，命令如下:

在项目工程内，执行初始化，calldemo 可以自定义名称。

步骤 05:运行代码。执行代码，将看到下面的效果，以及最终输出的 2020。

上述输出信息中，可以看到 Go 语言会自动下载依赖文件，这就是 go mod 的神奇之处。看到 2020，相信读者也知道运行结果是正确的了。

Ⅸ 以太坊通俗解释

以太坊（Ethereum）是一个建立在区块链技术之上的、图灵完备的去中心化应用平台。它允许任何人在平台中通过智能合约技术开发、部署和使用去中心化应用。有没有感到和 iOS、Android 平台有点类似？在区块链1.0时代，我们如果需要编写区块链应用需要先从 Github 上 Download 一份比特币源码，然后修改底层代码如网络协议、共识机制、加密算法等等，再发布到网络中。2013、2014年的很多山寨币就是这样产生的，改一改比特币的代码，甚至是调整其中的某些参数就造出了一个新的应用、新的币种。而以太坊平台，是对底层区块链技术进行了封装，让区块链应用开发者可以直接基于以太坊平台进行开发，开发者只需专注于应用本身，而不用关注底层技术的具体实现，从而大大降

Ⅹ 区块链和智能合约，以太坊开发，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开发。

[祈祷]