1. 你是否有币？如果有，挑1~3种说说你持有的原因？

2. 对于区块链，你最感兴趣的是什么？

3. 你认为和传统互联网比起来，区块链有哪些优势？

4. 你认为目前区块链的局限有哪些？

5. 你认为区块链对于你人生的意义如何？

从行业里最重要的起点入门

目前整个业界还处于区块链发展的萌芽时期，其概念也还在不断发展和完善中，这就给一些初学者带来了很大的困惑。 从区块链基础概念的发展路径循序渐进地去理解它，是一个非常好的模式——这就像我们学习生物必须顺着生物本身发展的轨迹，也就是从低等生物到高等生物；学习化学必须先从元素周期表开始一样。 但同时大家也要注意，区块链处于一个高速迭代的初级阶段，知识的更新是非常快的。

比特币白皮书

区块链源于比特币，我们首先就应该仔细阅读中本聪的论文《比特币：一种点对点的电子现金系统》（Bitcoin: A Peer-to-Peer Electronic Cash System）。经过简单梳理之后，我们会发现这篇论文的一些关键信息点：

• 区块即账单，也就是转账数据。

• 采用带有时间戳（timestamp）标记的分布式数据库（即区块）记录数据；

• 数据库由不断有序增加的区块链条构成，或者说数据被记录在一种链状的时态数据库里；

• 区块按时间顺序前后相连而形成区块链条，并且每个区块都通过密码学方法使之与其前后区块唯一关联，做到所有的历史数据井然有序地保存下来。

• 比特币由一个独特的共识机制即工作量证明（Proof of Work, PoW），来保障去中心化数据记录和数据验证机制的可靠性，从而做到数据能够毋庸置疑（trustless）和抗审查（anti-censorship，指不可能被删除、被篡改）；

• 数据公开透明；

• 通过点对点（peer-to-peer）技术，保障数据能够及时分发。

通过维基百科等工具的辅助，你完全可以自己顺着这些信息点很快搞清楚以下区块链技术的重点概念： ****

1.区块即账单

中本聪绝不是九零后零零后，因为他设计的记账方式和古老的会计一样！简单点说，古老的会计是用一个本本，每天一页来记账。比特币唯二不同的是把那页纸换成了区块，并且每1个小时全网的交易都记录到同一个区块里。

对于比特币，区块就是转账数据。

以太坊对此做了拓展。它把app的代码的也如此存储！

2. 采用带有时间戳（timestamp）标记的分布式数据库记录数据

时间戳是指格林威治时间1970年01月01日00时00分00秒(北京时间1970年01月01日08时00分00秒)起至现在的总秒数。通俗的讲，时间戳是一份能够表示一份数据在一个特定时间点已经存在的完整的可验证的数据。它的提出主要是为用户提供一份电子证据，以证明用户的某些数据的产生时间。在实际应用上，它可以使用在包括电子商务、 金融活动的各个方面，尤其可以用来支撑公开密钥基础设施的 “不可否认” 服务[3]。

时间戳的获取，一般是通过时间接收设备（如GPS，CDMA，北斗卫星）来获取时间到时间戳服务器上，并通过时间戳服务器签发时间戳证书。

带有时间戳（timestamp）标记的分布式数据库，技术也属于时态数据库的一种，是内建时间特性的数据库。

每个区块有了时间戳（timestamp），比特币账本才能根据时间顺序前后相连，而形成区块链。

3. 数据库由不断有序增加的区块构成，或者说数据被记录在一种时态数据库的每个区块（block）中。

比特币在数据记录方面采用了十分轻量级的文本数据格式JSON来构建自己的时态数据库**（**Temporal Database）。每一个区块，就是一个独立的数据表。比特币每十分钟新增一个区块，也就意味着它每十分钟新增一张数据表。

4. 区块按时间顺序前后相连而形成区块链条，且每个区块都通过密码学方法使之与其前后区块唯一关联。

因为每个区块都带有时间戳（timestamp）标记，因此所有区块就能按照时间顺序前后相连，而形成一条区块长链。加上每个区块都通过密码学方法使之与其前后区块唯一关联，那么这个链条的区块排序不光确定无疑，在关联过程中，由于采用的是与整个区块数据直接相关的hash值，亦即任何数据的变化必然造成hash值的不同，就能保障一个区块里的数据无法在任何时候被偷天换日。

5. 比特币由一个独特的共识机制即工作量证明（Proof of Work, PoW），来保障去中心化数据记录和数据验证机制的极端可靠性，从而做到数据能够毋庸置疑（trustless）和抗审查（anti-censorship，指不可能被删除、被篡改）。

所谓抗审查（anti-censorship），就是区块链里面的数据不可被伪造、篡改或删除。区块链抗审查的特性，需要通过适当的共识机制，保障通过去中心化的模式记录数据和验证数据才能得以实现。

比特币的共识机制是基于随机散列的工作量证明（proof-of-work）。这个机制归功于已经过世的科学家Hal Finney。是的，你在百度百科找不到他的词条。

6. 数据公开透明。

抗审查（anti-censorship）实现了数据永存，但如果数据非公开透明，那么数据的完整性连同数据不可被伪造、被篡改等等，就都是一句空话。

7. 通过点对点（peer-to-peer）技术，保障数据能够即时分发。

**点对点技术（peer-to-peer，简称P2P）**又称对等互联网络技术，它只有对等协议，没有服务器和客户端的概念。这也就是说每个比特币全节点钱包都可以既是客户端，同时也是服务器！除非互联网上无人使用全节点钱包，否则比特币就永远在线。这就是比特币玩家、自由音乐人张张创作《杀不死的比特币》的灵感源泉。

点对点技术在电驴（eDonkey）、BT分享和下载方面得到了很广泛的应用，但因为它们的种子仍然需要通过中心化的网站传播，因此难逃中心化模式的厄运，近年来迅速衰落——这也从侧面告诉我们：区块链项目如果不坚持彻彻底底的去中心化，一切都将会是过眼云烟！

不知不觉，我们已经学习和重温了一些基础概念，对吧？

而且，大家会突然发现作为年轻一代的我们自身的很多学习与发展的天然优势，也突然发现了时代赋予我们的责任感，以及无数前辈们呕心沥血、穷极一生之智慧和殷切之希望为我们铺垫的美好未来！

为你美好的未来加油吧~~

以太坊白皮书和EIPs

EIPs的详细介绍请见第四章对应内容。

从实践中慢慢总结和提升

区块链的发展还在早期阶段，知识的更新几乎可以说是日新月异。如果要一个人仅仅只是袖手旁观学习概念那是坚持不了多久的。

参与实践是必需的。实践中慢慢梳理知识也是必须的。

必须要声明下了：

百度百科并非自由的百科全书，无法和“维基百科”（www.wikipedia.org）相提并论。维基百科遵照Creative Commons Attribution-ShareAlike 3.0开源协议完全开放，百度百科则完完全全属于百度所私有。并且，百度百科确实有毒！

但因为网络封锁的原因，为照顾不会使用VPN的学员，有的地方，我们仍引用百度百科可用的词条解释——但我们无法保证在引用后的某天它会不会被别有用心的人改坏掉。

花絮

创新是很难的，因为我们是以旧头脑理解新知识。我估计当前的区块链资讯里，90%以上都充斥伪区块链知识。你要小心了！

签名

使用私钥对消息（譬如一个转账请求）进行签署即会得到签名（Signature）。

这一过程通常是将消息（数据）先通过哈希算法（Hash）生成哈希值，然后使用私钥通过加密算法对此哈希值进行签名。由签名（Signature）与消息的哈希值，便可以推出一个公钥，验证此公钥，便可知道此签名是否由该公钥对应的私钥签名。

签名算法可以表示如下：

Sig = FuncSig(FuncHash(m), dA)

• dA 是签名私钥

• m 是交易（或其部分）

• FuncHash 是散列函数

• FuncSig 是签名算法

• Sig 是结果签名

函数_FuncSig_ 产生由两个值组成的签名_Sig_，通常称为_R_和_S_：

Sig = (R, S)

通常，每个比特币签名会有三个长度：73、72、71，符合校验的概率为25%、50%、25%。所以每次签署后，需要找出符合校验的签名长度，再提供给验证方。

比特币的一个私钥，可以通过签名完成一个地址里的比特币的转账——这种情况可称之为“单签名交易”，因为转账只需要一个签名。

以太坊EIP-155“简单重放攻击保护”标准在交易数据结构中添加了v字段，即链标识符。它能确保为一个区块链（例如以太坊主网络）创建的交易在另一个区块链（例如以太坊Classic或Ropsten测试网络）上无效。因此，在一个网络上广播的交易不能在另一个网络上重播。

v签名前缀字段初始化为链标识符，其值为：

数字签名在以太坊中有三个用途。首先，签名证明私钥的所有者（其暗示是以太坊账户的所有者）已授权币的支出或合约的执行。其次，授权证明是不可否认的（不可否认性）。第三，签名证明交易数据在交易签署后没有也不能被任何人修改。

签名已经普遍被以太坊用于匿名登陆dApp（前端）的一种手段。

“安全”签名的硬件钱包

上一节我们提到：硬件钱包是为了离线生成和保存私钥，是目前“公认”比较安全的代币存储方案——非硬件钱包签署交易加载的是内存中的未锁定私钥。而转账时必须连接到互联网并运行公链（如以太坊）客户端，考虑到私钥有通过互联网暴露或被盗的风险，会另一些人特别是大户担心。硬件钱包采用的分离签名和传输的功能称为离线签名，是一种常见的安全措施。其中硬件钱包创建和签名交易，由手机或电脑里对应的app传输交易。将私钥与互联网隔离，理论上当然可以大大提高账号资产的安全性。

但是由于一些硬件钱包没有开源代码，同时还有一些没有经过硬件安全认证（硬件的全面开源还要假以时日），增加了很高的监守自盗风险。

多重签名

比特币的多重签名（Multi Signature，又被称为M-N多签名）指的是需要总共N个私钥中的M个（M≤N）共同签署一笔比特币转账（它实际收集的是这些私钥对应的公钥，签名时仍然是验证这些公钥），这笔交易才可能发生。多重签名的实质是一个地址里的数字加密货币的交易需要多个私钥通过规定好的合约授权。它通常被多个人或机构或程序脚本或人工智能用来协同管理数字资产。

多重签名的典型应用模式是：一个多重签名地址，可以有多个相关联的私钥进行管理，如果要转账，则需要按照合约规定，使用所有或部分相关联的私钥签署交易。譬如，你可以事先设置成N个私钥一起签名才能完成转账，你也可以设置为五个私钥中，有任意三个私钥进行签名即可转账。

以太坊的多重签名虽然机制和比特币的多重签名相近，但它充分发挥出其技术核心智能合约的特色，通过部署一个智能合约，并把N把公钥设为智能合约地址的资产的拥有人。以太坊的这么一点改变，让多重签名的应用发生了很大的提升！

比特币多重签名钱包和以太坊多重签名对比

以下将进行比特币核心钱包和以太币钱包在进行多重签名操作时的对比。

共同点：

都可进行多重签名，实现多方共同管理资产。

不同点：

• 比特币：完全通过私钥管理，每一笔交易都需要人工进行多重签名。应用场景非常有限。 以太坊：基于智能合约管理，是否需要人工或者什么情况下需要人工进行多重签名，完全由智能合约细节决定。应用场景非常宽泛也非常灵活。譬如，可通过智能合约设置每日提款限额，超过每日提款限额时才需要人工进行多重签名。又譬如，以太坊多重签名可应用于所有采用ERC-20通证标准的数字资产的管理。再譬如，即使一方中所有掌握私钥的人都挂掉了，资金也不一定就“胎死腹中”，智能合约还能按照预设的条款执行（譬如30天这一方没有做出决策，则全部资金自动转给对方）。

• 比特币：一般没有钱包余额限制 以太坊：有限制，譬如Mist钱包要求余额应不低于1.02 ETH，具体原因可参考：

• 比特币：一次性，而且如果转出金额小于钱包上的金额，需要填入找零地址。 以太坊：同一个合约地址可以反复使用。

这个对比应该让我们能够明白，以太坊在区块链领域的专业地位已经超越比特币的维度！

公链（Public Blockchain, Public Chain）领域已经数次发生与共识（共识机制）相关的问题，因此我们有必要先彻底搞明白发生了什么！

共识

区块链行业的共识，指的是一种决策机制，或者说治理机制。它要求所有参与者都支持一个决定。

这个决定是用代码制订的一个或一组协议，共识（共识机制）是公开透明的，也是强制性的，能够抗人为破坏。

从理论上说，如果有人不支持，当然可以不参与。

之所以我们需要强制性且能够抗人为破坏的共识机制，是因为人类金融的底层协议必须固化。而在匿名的情况下，我们这个年代人类是无法保证良好的共识能够达成的！

最具说服力的例子就发生在比特币身上：比特币因为确认时间太长、每个区块可容纳的交易数量太少，而从2016年起，就完全不能适应市场的需求。但因为无法有效达成共识，造成它无法顺利地更新技术以及基础协议，发展陷入停顿。之后社区分崩离析，技术开发完全丧失创新精神，将智能合约市场拱手相让给后起之秀以太坊，失去了技术领域的霸主地位。

共识算法、共识规则、共识机制

区块链的共识机制通常包含了两个方面：

• 达成共识的计算机算法，即共识算法（Consensus Algorithm）

• 达成共识的规则，即共识规则（Consensus Rule）

我们经常说的“共识机制”，多数情况下同时包含了共识算法和共识规则，少数情况下单指其中一方。这是导致我们的讨论经常发生穿越的原因之一。

百度云：由于点对点网络下存在较高的网络延迟，各个节点所观察到的事务先后顺序不可能完全一致。因此区块链系统需要设计一种机制对在差不多时间内发生的事务的先后顺序进行共识。这种对一个时间窗口内的事务的先后顺序达成共识的算法被称为“共识机制”。

这里解释的其实只是共识算法，也就是节点依照共识规则达成共识的计算机算法。

而共识规则（Consensus Rule）则是指每个区块链里面都有自己精心设计好的规则性协议，这些协议通过共识算法来保证它们可靠地得以执行。譬如我们通常所说的比特币的挖矿，就是比特币记账的共识规则，其专业术语为PoW（Proof of Work），即工作量证明。

比特币的工作量证明共识规则是通过SHA（Secure Hash Algorithm）系列安全散列算法之一的SHA256来可靠地得到执行的。

区块链账本或者数据的记录和维护是去中心化的，也就是往往有很多个记账节点。比特币或是以太坊这样的公有区块链，已有成千上万个记账节点。这些记账节点必须对所有区块有效性的验证都能达成共识。缺乏良好的共识机制，交易的验证就陷入混乱，对应的区块链也就会沦为投机者的温床，甚至是骗子和黑客的狂欢盛宴。因此共识机制对于区块链来说至关重要！

区块链有很多的共识机制，根本原因在于只要让人来做决策，就可能发生恶意的破坏行为，因此我们认为区块链最终的共识机制可能得依托于算法和开源代码。

最常用的两种共识规则

PoW（Proof of Work，工作量证明）

PoW的全称为Proof of Work，翻译过来就是“工作证明”或者“工作量证明”。

工作量证明是一种对应服务与资源滥用、或是阻断服务攻击的经济对策。一般是要求用户进行一些耗时适当的复杂运算，并且答案能被服务方快速验算，以此耗用的时间、设备与能源做为担保成本，以确保服务与资源是被真正的需求所使用。

我们把工作量证明中用户为获利而付出劳动的行为称为“挖矿”。挖矿获得多少代币（专业术语为通证Token）奖励，取决于挖矿贡献的有效工作，也就是说，矿机的性能越好、挖矿时间越长，所获得的代币奖励就越多。

此概念最早由Cynthia Dwork和Moni Naor于1993年的学术论文提出，而工作量证明一词则是在1999年由Markus Jakobsson与Ari Juels.所发表。此技术一度成为公链的主流共识机制之一。

比特币、狗狗币、莱特币、以太坊1.0等都是基于POW模式的数字加密货币。工作量证明的重要意义在于：它迫使代币的产生，需要付出一定的工作量和成本，这就赋予了代币一定的商品属性，使得自由市场这只无形的手能够通过“价格机制”自发地调节代币供应，保证了代币具有相对稳定的价值，从而使得代币能够获得人们的信任。

从共识层面讲，PoW的数学算法简单透明；从理论上讲，任何人都可以加入到网络中并产生区块。

但经过以比特币为主的公链十多年的实践之后，PoW的问题渐渐显露出来：

• 比特币囚徒困境：天生趋向于中心化而发展 前面刚说过：矿机的性能越好、挖矿时间越长，所获得的代币奖励就越多。于是聪明的人类就开始形成集团化的合作。手段及其简单：获得奖励的运算很复杂，那就多台机器在计算上分工协作。因为它们的总算力增加了，那么它们获得奖励的机会也就变大了。所以无一例外都会从挖矿散户，发展为中心化的挖矿集团，最终由几大矿池统治整个矿业！

• 对抗技术升级 矿业中心化之后，最大的问题就变成了矿业控制了记账权。也就是账单他们想怎么记就怎么记。如果核心开发团队要对技术升级换代，只要升级换代会降低矿工的收入或者收益率，那么可想而知，控制了记账权的矿池就会百般阻挠，或者发动分叉（可以理解为拒绝采用新标准账单而继续使用旧标准记账），甚至发动51%攻击（记假账从而给自己无中生有搞出很多代币，卖掉代币血洗市场，从而导致该项目完全失去信用而万劫不复）。

• 难逃灭顶之灾 我们已经经历过一些PoW公链被51%攻击的事件。上面说了矿工可能发动51%攻击，还有一种情况是黑客发动——当一个币种的总市值很低的时候（早期或者市场暴跌），51%攻击所需成本太小，而获益则非常诱人，此时黑客就会行动！ 墨菲定律告诉我们，任何一个事件，只要在人类的掌控中具有大于零的几率，就可确定它终有一天会发生。 PoW公链分叉可以说司空见惯了。公链分叉的意思是说一个公链项目分裂产生一个新的公链项目。最近以太坊的一些矿工就以分叉（甚至51%攻击）来抵制以太坊的柏林硬分叉升级。至于比特币，它已经被分叉了一百次。难以置信吧？！分叉出来的Bitcoin Cashe、Bitcoin SV、Bitcoin Gold目前还在市值前一百名之列！

PoS（Proof of Stake，权益证明）

PoS是以共识算法的方式，通过使用伪随机数或其它规则指定质押代币的人作为矿工（记账员）或交易的验证者，并获得奖励或（及）交易手续费。

2012年8月点点币（PPCoin）的创世，首次实现了PoS（它采用PoW + PoS 的混合共识机制）。它是一个根据所持有货币的量和时间，给持有者发利息的一个模式。在PoS模式下有一个核心名词——币龄：每个币每天产生1币龄。比如你持有100个币，总共持有了30天（一个月），那么，此时你的币龄就为3000。这个时候，如果你发现了一个PoS区块，你的币龄就会被清空为0。你每被清空某个固定的币龄，就会从区块中获得一定的奖励（利息）——持币有利息。比如，首创PoS模式的点点币就是1%年利率。

PoS最大的问题被认为是“富者更富”，在PoS体系下，受益的能力受持有代币的绝对限制。有人认为它是一种不公平的模式（不过在人类社会里，真有什么能限制富者更富吗）。另外质押代币会降低代币的流通量，有集体托底或拉盘之功效！

DPoS即授权权益证明，全称为Delegated Proof-of-Stake。

DPoS一般为股东投票产生代表。得票最高的代表（一般筛选出101个）有权将交易打包成区块，并获得系统的奖励和交易手续费。同时，他们还可能被赋予投票表决项目基金支配与否的项目各种开发的决策权。

DPoS的优势在于更快的区块确认和可扩展到VISA级别的每秒10000次支付或转账频率。但它有违区块链“去中心化”的初衷。问题很快在 EOS 公链项目上爆发出来，也很快被整个行业所淘汰。早期的公链达世币和早期以太坊采用了PoW+PoS的混合共识机制，来规避这样的风险。

2014年黑币（Blackcoin）对PoS进行了改进，Vitalick Buterin随后也多次专文对PoS进行了探讨。进阶阅读：

区块链公链已经实践过的共识机制还有好几十种，如Proof of Importance（重要性证明）、Proof of Assets（资产证明）、Proof of Burn（烧毁证明）、Proof-of-Purchase（购买证明）、Proof-of-Time（时间证明）、Proof-of-History（历史证明），Proof-of-Identity（身份证明）和Combining Proofs（混合证明）等。

以太坊坚定地选定 PoS 作为其2.0版本的共识机制，可以说对 PoS 寄予了厚望！

PoV（Proof of Value，价值证明）

厘清共识的歧义

由于普遍缺乏正确的理解，我们发现区块链业界的讨论，经常在一条偏离的轨道上做无用功，因此有必要让大家重新认识下到底什么是“共识”：

• 共识不是多数选举制

共识需要全部投票通过。只有51%的人同意而达成的方案，不叫共识，75%通过也不叫共识，95%通过也不叫共识！

当然，学过数理统计的都知道，“全部投票通过”并非一定要达到100%。通过数理统计的方法，在实际没有达到100%，但通过计算，尚且处于系统误差范围之内的情况下，我们可以视为已经达成共识。

还有值得注意的一点是：投票应该科学设置。譬如只有“同意”与“不同意”二选一这样的投票表决机制的最大隐患是，它可能会扼杀真正有价值的新的解决方案。并且这样投票有的时候会阻碍我们进行充分的讨论，所以在共识沟通中，要允许有“保留意见”这样的投票，或者多种提案。

特朗普当选美国总统就是一个非常典型的案例！他是在有截止时间的情况下，仅限2选1，以多数制（Majority rule）而非共识机制选举出的美国总统！有很多美国公民持之以恒地反对他执政，也就有情可原了！

• 共识最重要的核心是指反对派能够搁置不同意见，拥护一个所有人可接受的社区解决方案

中国政府常说的“搁置争议，共同开发” （仅限这八个字），就是典型的共识。

• 共识不是“全体一致同意“

对于一个大社区，比如我们这个泱泱大国，在全体公民投票的情况下，相当多的提案，都不会得到“一致同意“。如果坚持必须“一致同意“，那么就会被个别人利用这一规则，阻挠区块链的重要决策。

共识只是让大家必须做出选择或者决策。一架飞机燃油耗尽，左边是大海，右边是森林，中间是乱石堆，迫降哪边如果您非要“一致同意”，不会游泳的人怎会同意迫降大海，害怕大树刺穿机体的怎会同意迫降森林？非要“一致同意”，那只有一种结果：撞上乱石堆！

比特币目前的转账处理速度是7笔/秒，已经难以满足市场需要，因此它迫切需要整个社区在多种解决方案中，达成一个共识。但此事讨论了两年多了，一直无果。问题的核心是：共识机制POW的决策者本来只有矿工，吃瓜群众根本不沾边。而此时比特币矿业已经中心化，并且其发展因此受阻，吃瓜群众介入进来，自然就步入了混乱状态。

• 共识不是要全部完美解决

共识只是要在关键时间点上，推动整个议题向前发展。

一个议题里面，常常有大家容易接受的部分，也有不容易接受的部分，要想它的方方面面都完全被所有人接受，那是不切实际甚至完全有毒的。把议题向前推进，在必要的时候再解决掉其中的缺陷或者分歧比较大的部分，这才是真正的共识。

比特币社区里的一些人，就非常害怕对比特币的修改不够完美，比特币社区现在的状态有时候甚至是“搁置共识，互相攻击”。

• 共识不是一劳永逸

共识在必要的时候，是可以更改的。以刚才飞机着陆为例，即使乘客已经达成水面降落的共识，如果机长的专业判断不同，加上时间也足够，他可以通过他的专业解释，影响乘客改变共识。无论是领袖还是群众，都可能犯错误，因此，坚持区块链数据不可篡改、坚持code is law是正确的，但坚持错误code带来的不良后果和被黑客污染的区块链数据不可通过共识修改，那就从根本上扭曲了共识的含义！

• 共识不是竞赛或对抗

一些地方常常把共识当竞赛或对抗来对待，这非常危险！它非常容易让社区变得不再友好！不友好的社区全球很多，它们有一个共同的名称：贫民窟！

以上讨论，主要参考了维基百科的共识定义，也是几十年开源软件协作的经验总结。

大家都已经知道，区块链往往是开源项目。特别是公有链，理论上它已经不是完全专属于某个公司或者某个团队。在这种情况下，维护社区的安全和健康发展，就特别需要以协议形式开放的而非建立在公司或者团队的权力基础上的，偏平而有效的管理体系。而这个体系里，除了达成共识的机制，还一定不能少了具有执行能力、能促成共识达成、可防止共识被破坏的奖惩工具。

脑筋灵活的马上会想到代币：共识规则的一个重要的核心，就是一套对区块链维护者们的代币奖惩制度！但目前区块链还没有很成熟地运用这种奖惩制度。

共识机制的根本作用是构建出一个既安全又符合其社区需求及社区发展的生态系统。毫不过分地说：共识机制就是构建其区块链生态的决定性机制。鉴于共识机制如此重要，我们往往还会把区块链的重要决策权也放到共识机制里解决——特别是后面要介绍的去中心化自治组织。

区块链里面有三种形式的分叉。

第一种是经常发生但大家都熟视无睹的。这种分叉是去中心化共识的副产物。对于比特币来说，只要两个矿工几乎同时完成记账就会发生分叉，因为他们同时广播了两个区块，当后续的多个区块链接到其中一个区块，使这个链最长，另一个区块或其小分叉就会被网络“孤立”以至“抛弃”掉。这种形式的分叉是常见而且正常的，一般我们在讨论分叉时很少提及它。

以太坊也常发生分叉。但不同的是：在以太坊中，孤块被称为“叔块”(uncle block)，它们可以为主链的安全作出贡献，因此挖出七代内的叔块都能够得到奖励，并且叔块的代数离主链上下一次挖出的区块的代数越近，则其被矿池招安能够得到的奖励将会也多，根据离的代数越远，奖励比例也越小，依次为7/8、6/8、5/8、4/8、3/8、2/8、1/8。叔块奖励 = 奖励比例 * 出块奖励。

另外两种分叉则是基于共识层面而产生的，它们需要社区谨慎处理，因为它们在社区无法达成共识时，有可能造成社区和项目的分裂。

软分叉

软分叉是在原有的规则范围内强化既有规则。譬如新规则单纯将区块的大小由1MB 减小到500K，因原有的规则为区块的大小未超过1MB就是有效的区块，所以未升级的节点会继续将新交易视为有效。然而未升级节点继续挖出的1MB区块将被已升级节点视为无效区块而被拒绝。这也就是说，旧节点无法觉察到协议的变化，不能发现软件已升级，从而继续参与新节点用新协议所挖出的区块的验证工作，但旧节点矿工将无法在新区块上继续添加新节点矿工视为无效的区块，旧节点矿工无法获得对应工作的收益——如果社区未达成共识，多数节点（实质为多数算力）拒绝升级，那么其分叉方案就可能对社区造成伤害。

那么部署一个成功的软分叉，因为需要网络的大部分算力的支持，最好是在达成社区共识的前提下进行。缺乏充分共识的软分叉并不可取。

硬分叉

硬分叉是改变原有的规则，引入不兼容旧软件的新规则。譬如将区块的大小上限由1MB 增加到8MB，没升级的节点会将新区块视为无效，因此未升级节点无法协同已升级节点的工作，和软分叉不同的是矿工马上会发现这一问题！从这个角度说，硬分叉更透明更清晰些。

业界有一种认识上的误区，认为只有软分叉是向后兼容的。实际上无论哪种分叉，都是必须是向后兼容的。“向后兼容性”是指新的软件或协议接受原有的旧格式的数据，只是软分叉到了分叉的哪个时间点后，新的软件或协议将不一定接受旧格式的数据。

比特币此前就曾因代码bug被利用等情况而经历多次的软硬分叉。以太坊也曾经几次硬分叉，并且它现在正在通过硬分叉解决其交易拥堵以及升级换代等诸多问题。

另外要提醒大家的是：除了公链，区块链应用（dApp）也是可以分叉的，因为区块链应用如果遵循区块链的核心价值，那么其智能合约及其数据就都是公开透明的，合约的调用就是无需许可的，从技术上说，分叉就往往变得非常容易了。譬如去中心化交易所Sushi就是从大名鼎鼎的Uniswap分叉产生的。

双重支付又被称为“双花”，顾名思义就是同一笔钱（数字加密货币）被重复支付两次，也就是将同一个地址上的数字加密货币同时支付给两个不同的收款地址。

比特币双花一直都有，只是这些双花没成功而已。

如果双重支付是有意而为之，那么就是双花攻击。在其它公链上双花攻击的确多次发生过，并且不幸的是作恶者硕果累累。

比特币挖矿实质上是下列工作的集合：

• 为全球的比特币交易记账——大约每十分钟，抢得记账权的矿工（实际应该是一个节点Node），将全球的比特币交易记录到一个区块链里。

• 帮助比特币发行——比特币系统将给记账的矿工（节点）一笔比特币奖励。最早是50个比特币的奖励。但是该报酬大约每4年减半，现在每10分钟比特币网络就可以产生12.5个比特币。因此实际上，奖励也就是比特币的发行机制。

• 通过PoW即工作量证明，维护比特币网络的安全。

中本聪在他的论文中阐述说：“在没有中央权威存在的条件下，既鼓励矿工支援比特币网络，又让比特币的货币流通体系也有了最初的货币注入源头。”可以看出，中本聪把通过消耗CPU的电力和时间来产生比特币，比喻成金矿消耗资源将黄金注入经济。

挖矿的问题：

• 矿业容易中心化——特别是纯PoW共识机制，经过市场的淘汰和矿机的中心化发展，矿业逐步被少数人控制，决策权基本最终会落入矿工手中，也就是矿业中心化最终会带来决策权的中心化，使得比特币非常难以升级改造，而非常容易导致社区分裂。2017年比特币先后分叉出Bitcoin Cash、Bitcoin Unlimited、Bitcoin Gold、Bitcoin Diamond、Super Bitcoin，等等，原因就在于矿业中心化。我们有时候也把这种现象叫做比特币囚徒困境。

• 破坏环境——尽管直到今天，人们还在强调区块链矿业利用的大多是过剩能源，但是不可否认，由于挖矿能源需求的无止境，如果不改进现有的工作量证明这一普遍应用的共识机制，破坏环保迟早会变成区块链背负的骂名。

挖矿难度与算力

挖矿难度（mining difficulty）有时候又被称为“区块难度”（block difficulty），它是用来衡量PoW共识机制中挖出一个区块平均所需要的运算次数的指标。对挖矿难度最简单的理解是：在某个固定的算力下，挖到一个区块所需的时间。

挖矿难度反映了在一定难度下，用多长时间才能挖到一个区块，因此它是矿工挖矿时重要的参考指标。

算力（Hashrate）是矿机每秒产生哈希（hash）碰撞的能力，也就是比特币矿机产出比特币的计算能力。算力的单位转换关系是

1EH/s = 1000PH/s

1PH = 1000TH

1TH = 1000GH

1GH = 1000MH

1MH = 1000KH

1KH = 1000H

每隔两周，比特币挖矿难度会根据最近这个周期开采的区块数量而进行调整——比特币矿工的说法往往是，比特币挖矿难度会根据最近这个周期的算力增减进行调整，以保证约十分钟产出一个新区块。

PoS共识机制中没有此概念。

挖矿概念的演变

我们刚才说到比特币挖矿的一个作用是帮助发行比特币，同时挖矿是一种劳动付出，它能够给发行的代币赋予“劳动所得”这一意蕴。

因此从2017年以来，区块链的“XX 即挖矿”的热潮从未停息，譬如“交易即挖矿”，“创作即挖矿”、“借贷即挖矿”、“流动性挖矿”等等。其中“交易即挖矿”，“创作即挖矿”、“借贷即挖矿”通常即用于新项目的代币发行。

流动性挖矿是由DeFi催生出的新概念。它是一种让投资者使用无需许可的流动性协议，通过向流动性资金池中注资，而获得代币奖励的一种全新方式。 奖励的可以是这个项目所发行的代币，也可以是用户买卖时出售的代币。流动性挖矿能够让任何人都可以使用以太坊上建立的去中心化“金钱乐高”生态系统，从而获取被动资金收入。在2019年爆发的DeFi风潮中，它起了推波助澜的决定性作用。

节点（Node）

我们常常把节点和矿工（拥有节点的人）混为一谈。这其实超级危险，因为它让我们忘了一个人可以同时拥有很多很多节点。这是很危险的遗忘！

因为比特币的风险越来越大，我已经不打算介绍它的节点。让我们看看超越了它的以太坊的节点情况吧：

很复杂对吧？

我认为对以太坊PoS的改进，还需要数年时间，并且需要非常重大的改进！其中的重点是奖励和处罚机制，以及相关币种的改进！其中前后两项我都已经做了新的设计，并且和团队伙伴完成了相关的合约代码！你如果好奇，以后去找找（已经公测于 Sepolia 测试网络并即将上线以太坊主网）道易程里面的智能公器吧！

比特币貌似为典型的旧瓶装新酒。它本身看起来只是一堆旧技术的组合，但它的确给我们的新思维提供了坚实的基石，比特币打开了区块链的大门并且为区块链赋予了坚不可摧的基础价值观。

值得警惕的是，很多人因此而认为“一堆旧技术的组合”就能拥有化腐朽为神奇的力量。这是区块链十多年产生一大批伪区块链项目的主要原因之一！

去中心化（Decentralized）

比特币被设计为去中心化自治系统。所谓去中心化，是指这个系统自2009年1月3日创世后，即以既定规则在因特网中自主运行，不依赖某个机构的服务器，也无须某个机构来监管。

换句话说，与传统货币不同，比特币的运行机制不依赖任何中央银行、政府或企业的支持或者信用担保，而是依赖对等网络中种子文件达成的网络协议。去中心化、自我完善及透明开放的货币体制，在理论上确保了任何人、机构或政府都无法操控比特币的货币总量，或者制造通货膨胀。

比特币的发行机制的特点：它的货币总量按照预定的速率逐步增加，货币发行速度逐步放缓，并最终在2140年达到2100万个极限，此后不再有新的比特币发行。这个发行机制是连政府都无法干预的，并且因为规则、代码和数据的开放性，不存在暗箱操作的可能，这在根本上杜绝了不良主权法币利用通胀剥削公众利益的弊端，在货币体系层面的理解上，这一点恰恰成为数字货币之所以具有顽强生命力的驱动力。

这里要说的是，好多家中心化的数字货币交易所因黑客的肆虐和创始人的贪婪让投资者损失巨大，而与之形成鲜明对比的是：比特币在全球最强悍的黑客的攻击加上某些政府最强硬的打压下，11年来其本身毫发无损，恰恰完美地佐证了去中心化的优越可靠性。

可惜的是，比特币的去中心化机制并非坚不可摧，而中本聪的失踪使得比特币的技术没有与时俱进。矿机的垄断以及矿工联合产生矿池，导致比特币矿业很快出现了中心化，使得比特币的前途岌岌可危！

抗审查（Anti-censorship）

请注意，这里的抗审查指的是比特币交易不可纂改，而并非某件事没有门槛没有限制的那种抗审查。后者叫“无需许可”。

任何比特币交易都是不可撤销的。这也就是说：一个人给你转了账，一般约10分钟你就会收到到账通知，虽然这时候你还没有真正收款（一般需六次确认），但他已经不能单方撤销这笔交易、偷偷冻结或者收回这笔比特币。

我们称比特币的这一特性为抗审查（anti-censorship）。在比特币的实际应用中，抗审查直接体现在没有人可以伪造、修改、撤销或废除交易。这一特性也使得比特币的交易数据是可永久溯源的。

抗审查被广泛接受为区块链的核心规则和核心价值观，即区块链里的原生数据不可被伪造、篡改或删除的。

抗审查常常被直接理解为区块链数据不可纂改——请特别注意，这种说法只适用于区块链原生数据（如转账数据），但并不适用于区块链里面已有的一切数据。或者说，请不要认为只要是区块链里面的数据，就百分百可信，因为数据进入区块链之前是可以造假的！我们无法用区块链技术保证非区块链原生数据的真实可靠性。譬如一个群体的身份信息。

理论上，如果整个社区达成了共识，可以通过回滚做到撤销或者废除交易，甚至达到删除帐户的目的。但是实际上它还是违背了区块链抗审查的原则，很容易引发信任危机乃至社区的分裂！

无需许可（Permissionless）

无需许可最早是表示所有（任何）节点都可以请求将任何交易添加到区块链中，也就是说你想做矿工就能做。

除此之外，任何人都可以自由地拥有自己的比特币账户，任何人都想要几个比特币账户都行。任何人的比特币资产都可以自由支配。而到了以太坊带来的区块链2.0时代，一个智能合约可以被任何一个人的钱包或者任何一个智能合约任意交互。以此类推，这会使得区块链生产数据、交换数据、记录数据、更新数据都变得百分百自由。再推一下，这将使得区块链的应用无所不及！

一定马上就会问：无需许可不就让坏人为所欲为了吗？

是的！如果你的代码或者经济模型有问题，坏人就可以肆意妄为。我们已经遭遇很多这样的案例。

这也意味着：如果想用区块链治理人间，恐怕还要相当长一段时间！但别忘了AI的各种能力一直在超越人类，区块链和AI（注意不是人）的结合值得期待。

公开透明（Transparent）

比特币说白了就是一个公开透明的去中心化账单系统，它把账单完全公开透明地交给全球所有的比特币用户监管。比特币的所有转账数据是公开透明的，比特币的所有全节点钱包的代码也都是公开透明的。

中立性（Trustless Trust，毋庸置疑）

比特币交易被记账员（矿工）确认后作为账单分发给所有节点确认，并且要在系统里总共做6次这样的确认才被最终接纳，再加上所有的账单都是透明可查的，因此交易的参与方不需要相互了解或者彼此信任，不再需要中央银行这样的中介，就能安全可靠地完成交易。

比特币账目完整、完全公开且所有记录永久保存（永远不能被删除或篡改），意味着它就是一个公开透明的分布式账单系统，它把账单完全公开透明地交给全球所有的比特币用户维护。而正因为所有用户都有一份公开透明的账单，至少要事先串通51%的矿工造假，才可能让伪造的交易被整个网络信以为真。因此当匿名矿工数量足够且足够分散时，比特币是值得信赖的。

但我们不得不正视现状：矿池的出现大大减弱了比特币矿工的分散性，降低了比特币的可信任度。

花絮

2021年4月14日，美国交易所Coinbase上市纽交所，它的一个广告的用语如下：

In blockchain we trust.

In the future we trust

In freedom we trust

In Satoshi we trust

In Bitcoin we trust

In crypto we trust

In math we trust

In you we trust

如果In Coinbase you trust，那就大错特错了！

匿名（Anonymous）

成功的匿名技术，是比特币最重大的创新，也是其最为关键的基石！

简单地说，中本聪的设计是利用密码学原理：由钱包随机生成一个私钥，唯一的私钥产生唯一公钥，这个公钥再产生唯一的地址。此流程无法反向破解。

私钥是永远不能暴露的，它也不可能被破解，否则你的资产就会被盗。

至此，中本聪采用技术手段，最终实现了他的白皮书里所说的“新隐私模型”：

如果你2月14号收到一束玫瑰，但没有任何寄件人信息并且此后也没有任何人披露证据说明是他寄给你的，那么我们说这束玫瑰是匿名的。它来自一个不想让你知道他姓名的暗恋者。

使用比特币钱包完全不用注册个人信息，因此哪些比特币地址是你的（准确地说是控制它的私钥在不在你手上），谁都不知道，因为控制钱包的私钥在应用场景中是永远不用也不能公开的。从技术上说，比特币就是匿名的。没有人知道某个地址的私钥在谁手中，就算我知道是你用比特币还了欠我的债，我也无法确定那个地址的私钥是不是在你掌控之中。

• 中本聪对比特币交易的加密设计，有效避免了私钥的泄露，你无法破解。

• 哪个地址是隔壁老王的，你不可能知道。

• 某人有多少钱包地址，你不可能知道。

• 哪些地址的私钥是多个人共同拥有的，你不可能知道。

另外：数据公开透明是保证区块链安全的最后一道屏障，综上所述，比特币抛弃了对数据进行加密这一通用的保护隐私的手段！

匿名性的目的是隔离人的“名声”造成的不良影响，剥夺任何人的特权。

划时代意义的创新支付网络（Innovative Payment Network）

比特币转账依靠的是因特网，完全没有国界限制。而且无论身处地球的哪个角落，比特币的到账时间都是10分钟，交易完成时间都是1小时。

比特币交易不受任何中央管理机构或银行的影响，完全是点对点交易（Peer-to-Peer Transactions）。

因此比特币不仅仅只是货币，它同时也是极为简单、便捷和高效的支付网络。我们都知道，今天的支付网络几乎就是全球经济的命脉。而比特币作为支付网络，可以简单到仅仅只需要一个钱包软件，无需借助任何第三方，通过电脑或手机或其它上网设备就可以实现全球无障碍点对点直接到帐——比特币这个支付网络的建设成本如此之低、效率如此之高、使用如此之方便，这本身在人类金融史上，就是一大创举！

对于在我们的生活中已经举足轻重的电子商务来说，支付是至关重要的一环。可问题在于虽说因特网没有国界，各种法定货币却都有国界，它们从来都不是全球化的，更谈不上完全自由流通，并且无论网速多块，各银行间的结算仍然需要可长达一周的蜗行时间，这就是现有的货币体系与伟大的因特网的矛盾之所在。自由、全球化、安全可靠、极低的手续费、交易完全透明、彻底杜绝欺诈、兼具众筹功能、兼具多重签名支付模式、超快捷的结算速度和微支付能力、机器自动结算……比特币及受它启发产生的其它加密货币恰好能完美解决现有支付系统里面的种种矛盾和瓶颈，并提升了支付能力、大大地拓展了支付的应用场景。其意义无疑是划时代的！

比特币的硬核贡献

贡献：

1. PoW共识机制符合“劳动创造价值”这一基本价值观，容易被广泛接受。但到2024年7月我再回顾比特币最大的贡献，还是不得不感叹：金融催生了人类文字的发生发展，成就了人类经济、文化乃至各种行为治理的最底层结构。但浸润其中数千年之久，现在绝大多数人对此视而不见置若罔闻！实在太离谱了！ PoW共识机制是一种典型的金融治理手段以达成人类良好协作的非常典型的案例。它不复杂，但意义重大！并且，如果不是很多很多人在中心化的世界里中毒太深，它原本具有极大的启发作用！

2. PoW是一种非常有效的激励机制。它也揭示出激励机制对人类协作的威力值得我们极为重视。

3. PoW在比特币中的细节并不完美！虽然在区块链发展的初期，它使得比特币的安全性可以维持相当长的一段时间。但请牢记：比特币的PoW工作量证明的安全性是有限的，在不久的将来，它终会因为不堪重负而崩塌！

4. 比特币是区块链的鼻祖。

比特币的硬核问题

1. 比特币没有帐户 在“2.1”对钱包和帐户的介绍里，我们会通过比特币的找零机制告诉大家：中本聪不仅非常可能是位长者，而且他的生活经验单一到他并没有5000年前伴随人类金融的萌芽而创新出的“帐户”概念。没有帐户概念，包括投资、期货等方面的金融实践就无法在人类社会中产生。

3. 区块链发展趋势已成：以太坊的非零地址远超比特币 至2020年6月10日，以太坊非零地址超出比特币非零地址2千2百万个，大约比后者多60%的非零地址！ 数据再一次证明：互联网需要的是应用，而不只是代币。

4. 比特币发行总量约2100万枚，考虑到遗失的不断发生，以及度量衡的基本要求，可以肯定它是永远不可能达成其目标电子现金。所谓现金，本质应该是一种”通用的支付币种“（结算币种），或者说一种定价货币。而如果要成为现金，那么首先它就不能是一个固定的发行总量，否则市场的需求量增加的时候，它自身的价格就会被动摇！

7. 矿工、矿机商和核心开发团队Bitcoin Core以及其它开发团队的矛盾不可调和（这与公地悲剧紧密相关）。比特币的技术由于领袖玩失踪导致群龙无首，以及矿业中心化等问题，自2005年起，无法达成升级换代的共识，逐渐落后。从技术上说，比特币基本已经无缘智能合约。丧失了建设自己的技术应用生态的良机，未来有可能被主流生态孤立。

8. 比特币遭受约百次分叉劫难，共识生态支离破碎。

9. 对于包括比特币在内的很多公链来说，安全期早就已经过去了。

NiceHash是一个大型加密货币算力市场，通过它你可以买到超过20种不同的算法的算力，这样通过在这里购买到足够的算力，就可以对一个算法一致的链发起51%攻击！数据显示2018年年中1小时攻击成本非常小。对于这些币种发起51%攻击简直易于反掌！详见figure 6。

事实上，51%攻击已经发生过，而且不止一次！

总结起来，比特币创造性地带来了去中心化和去审查的激励机制，它让人类发现了一种新的基于互联网的合作机制，但可惜的是它最终带来的仍旧是非合作博弈。

以太坊刚起步时，迫于投资者的压力也采用了PoW工作量证明。后来在Vitalik坚持下通过社区协作，转为PoW+PoS，数年后再转为PoS。我们现在简单地对比下以太坊PoS和比特币PoW的安全差距吧：

1. 比特币的 PoW 无法抵抗51%攻击，以太坊 PoS 的破防位是三分之二，即约66.67%。

2. 比特币的PoW工作量证明根本就没有处罚机制！ 而我们知道以太坊的PoS权益证明，要求每一个验证者节点都要质押 32个ETH，也就是约85万人民币（2024年6月9日）。如果有人想用很多节点作恶，区块高度289162，验证者超过1百万个，超过总数的66.67%的节点的资金的风险将超过113亿美元。 （数据来源：https://beaconcha.in/charts/validators）

根据数据存储方式的不同，数字加密货币钱包又可分为全节点钱包、轻钱包、分层确定钱包。

全节点钱包（Full Nodes Wallet）：是指包含了全部历史交易数据的钱包。多被矿工所使用。其优点是安全可靠。缺点是要下载或更新全部数据后才能正常使用，有时候的确很慢，会影响到用户的使用。

轻钱包（Light Wallet）：它通过一种名为“简易支付验证”（Simplified Payment Verification ，SPV）的方式来完成交易验证。简易支付验证节点即“SPV节点”又叫“轻量级节点”，相对应的钱包就是轻钱包。SPV节点只需下载区块头信息，而不下载每个区块中的所有交易信息，由此产生的不含交易信息的区块链，比完整区块链小了很多。“简易支付验证”只是“支付验证”而非“交易验证”，所以SPV节点可以证实某个交易的存在，但不能验证某个交易不存在，这个缺陷可被针对SPV节点的拒绝服务攻击或双重支付攻击所利用。为了防御这些攻击，SPV节点往往会随机连接多个节点，以增加与至少一个可靠节点相连接的概率。

轻钱包的优点是使用快捷、占用存储空间小。随着比特币的使用热潮，轻钱包越来越常用。但对于网络有问题的人来说缺点还是更新数据太慢，加上也不是百分百安全，因此近年其风头被分层确定钱包抢走。

分层确定性钱包（Hierarchical Deterministic Wallet, HD Wallet，HD钱包）：常常也被称为多层确定钱包，也曾被称为双层确定钱包。

比特币最早的客户端（Satoshi client）是分层确定性钱包。分层确定性钱包会预先生成 100个随机私钥(对应于100个公钥和100个地址)，并且每个私钥只使用一次。每个交易使用一个地址的概念是中本聪提出的。如果交易比较频繁，私钥可能很快会用光，然后再产生100个随机私钥，所以每次完成 100 个交易后，你必须备份钱包的wallet.dat文件，否则可能会丢失资产。这就意味着这个钱包必须被经常性地备份。每个私钥都必须备份，否则一旦钱包不可访问时，就可能无法找回钱包。这种钱包难以管理和备份，经常发生有人清空钱包app的缓存和数据，然后资产全数丢失！

分层确定性钱包则无需每次转账后都备份。它的私钥是对种子密码（Seed，一串由随机数生成器生成的随机数）进行单向哈希运算生成的，在分层确定性钱包中，只要有这个种子密码，就可以找回所有私钥，因此备份了种子密码就相当于备份了您的所有资产，所以它非常方便使用。

分层确定性的概念是根据比特币核心开发者Gregory Maxwell的原始描述和讨论，Pieter Wuille在2012年2月11日整理完善通过BIP32提案提出。但它直到2016年6月15日才被合并到Bitcoin Core，目前几乎所有的比特币钱包服务商都整合了该协议。

BIP32 是HD 钱包的核心提案，通过种子密码来生成主私钥，然后派生海量的子私钥和地址，但是种子密码是一串很长的随机数，不利于记录，后来BIP39用算法将种子密码转化为一串助记词 （Mnemonic），方便种子密码的保存。再后来BIP43对BIP32树结构增加了子索引标识purpose的扩展“m/purpose'/ * ”。最后，BIP44在BIP43和BIP32的基础上增加多币种，通过分层确定性钱包派生多个地址，可以同时管理主网和测试网的比特币，BIP44 提出了5层的路径建议，如下：

m/purpse'/coin_type'/account'/change/address_index，

BIP44的规则使得HD钱包非常强大，用户只需要保存一个种子密码（12～18个英文单词），就能控制其钱包里的所有币种。

比特币分层确定性钱包实现机制：

1. 生成一个助记词（BIP39）

2. 该助记词使用PBKDF2转化为种子（BIP39）

3. 种子用于使用HMAC-SHA512生成根私钥（BIP39）

4. 从该根私钥，导出子私钥（BIP32），其中节点布局由BIP44设置

可以看出 BIP39 生成助记词的过程非常重要，早期的HD 钱包助记词是12个单词（现在有的钱包已经增加到18个单词），一共有 2048 个单词可能性，根据这个公式“_n!/( n - r )!”_我们可以计算出随机生成的助记词所有可能性：

2048!/(2048-12)! = 5.2715379713014884760003093175282 e+39 。

地球上的沙子数量在大约是1 后面 18 个零。如果你可以每秒生成 一百万个助记词，那么一年可以生成 1000000*60*60*24*365=3.1536e+13，你大约需要 1.6715937e+26 年遍历以上所有助记词！

以太坊的EIP85提案HD钱包的路径为 : m/44'/60'/a'/0/n

a——表示帐号

n——第 n 生成的地址

60 是在SLIP44提案中暂定的补充协议，对应的币种就是ETH，因为BIP44对币种只定义到0 – 31。

以太坊各钱包的具体实现如下：

m/44'/60'/0'/0/x——imToken（可自定义路径），MetaMask，Jaxx，MyEtherWallet，TREZOR，Exodus

m/44'/60'/x'/0/0——KeepKey，MetaMask

m/44'/60'/0'/x——Electrum，Ledger Chrome App，

m/44'/coin_type'/account'/0——Coinomi

发展到这结束了嘛？

并没有。

你可以调查下是否还有其它相关的技术标准。

致敬2022年在读的所有中国大学生！

2022年我们达成的一个伟大的共识是：成功有个常被忽略的元素叫勇气。当我们鼓起了勇气，我们就可以无惧面对落后的文明和数不清的野蛮人——在当下这个大时代勇气能够助你做出正确的选择！

2023年4月，我惊喜地看到台湾的年轻人也行动起来了。柯文哲先生极有可能引发我们对人类社会治理的一些重要的讨论。而此前的乌克兰反俄罗斯侵略的战争，和此后的以色列的消灭恐怖组织哈马斯的战争，也意味着全球的文明人不得不仓促间发动一场消灭邪恶势力的总决战。

而所有这些，居然都与区块链息息相关！

我自2017年开始，以自己的实践为基础，精心编写入门区块链必读的内容，且每年都不断修订。这就是本教材的来历。Gitbook的编辑器对中文的支持很糟糕，PDF导出的福利又突然被取消（Gitbook能给我们免费的服务已经够好了），VPN偶尔会崩溃等等，加上这个该死的动荡不安的时局，我的工作也确实很不容易。

如果你想以最短的时间了解区块链，那么我的《区块链入门极简版》无疑就是最佳的选择了。

这是我本人发起的人类新文明的治理项目：道易程。道易程构建出一个继承了比特币的PoW工作量证明的治理思想的新的治理共识：PoV价值证明。目前看，它将构建出一个良好的投资市场（我称之为“良好的通证经济”），同时它也是区块链公共应用即智能公器发展的基石！但其实它目标远大，在创新中将会在出世的第一天就锻造好人类文明的治理基金（Hayek UTO Fund），然后随着以太坊和AI的发展，其治理共识PoV价值证明将为人类的福利和广义上的“劳动”（或者马克思哲学思想里所说的实践即Pracxis）提供最直接有效的解决方案（如果你感兴趣，请联系微信：aranna_0572、Telegram：@aranna0572。也欢迎通过Discord加入我们！

什么是区块链？

如果你急于了解技术上的解释，请点击此处。

最朴素的解释是：区块链始于一场技术革新，其本质即为金融革命，因此也必将引发一场声势浩大的全面而彻底的人类社会革命。它的指向是马斯克哲学思想所预见的共产主义。

区块链革命

既然是波澜壮阔的人类社会革命，那么就有必要俯瞰下人类文明的发展概貌：

以色列历史学家尤瓦尔·诺亚·赫拉利（Yuval Noah Harari）在《人类简史》中说：

“可以说智人主要是一种社会性的动物，社会合作是人类得以生存和繁衍的关键。”

他还指出：

“人类语言真正最独特的功能，并不在于能够传达关于人或狮子的信息，而是能够传达关于一些根本不存在的事物的信息……‘虚构’这件事的重点不只在于让人类能够拥有想象，更重要的是可以‘一起’想象，编织出种种共同的虚构故事，不管是《圣经》的《创世纪》、澳大利亚原住民的‘梦世记’（Dreamtime），甚至连现代所谓的国家其实也是种想象。这样的虚构故事赋予智人前所未有的能力，让我们得以集结大批人力、灵活合作。“

简而言之：人类学会了虚构，以达成更复杂、更高效的合作。

这很容易让我们想到人类最重要的虚构成就之一宗教。“我们可以说宗教是‘一种人类规范及价值观的系统，建立在超人类的秩序之上。’”

简单地说，希腊神话虚构出具有种种道德法则和道德秩序的诸神世界的目的，是为了让人间的秩序有神圣的保证！宗教在非强制的前提下，通过虚构建立起人类的行为规范——这是一个基于共识的治理手段。

但宗教共识没有强制性，只能依靠自觉遵守，其约束性是很有限的。人类社会更复杂、更高效的合作，或者说人类高阶文明的发展，毫无疑问有赖于更强大的治理机制！

因此人类开始了对其自身治理的不断的探索。

现在普遍认为公元前3200年左右的苏美尔人的楔形文字是世界上最早的文字，记录的是经济交易。这也就是说，楔形文字是古代会计制度和契约的一个副产品。第一份抵押、契约、贷款、期货合同、合伙协议和信用证都是以楔形文字文件的形式出现，可以追索到公元前2000年或更早。此后不断发展，终于在公元前5世纪至4世纪时的古希腊，出现了契约论。三千年前的西周第六代国君周共王时期，也诞生了中国历史上最早的合同——这可以说是超越宗教的契约文明全球化的实锤吧。

所以，文字即是因应契约文明的需要而产生的。它始于“金融”类契约的需要。

易中天先生在多个场合讲解过起源于西亚的契约文明，你可以搜索其视频仔细看看。契约文明的大致脉络如下：

• 人在物质财富（包括金钱和资产）及其融通方面形成的诸多契约构成了金融——譬如易中天提到过的这一说法：“如果要人人精神平等，也就是每个人都具有独立的人格和自由的意志，就必须要有私有财产神圣不可侵犯这个契约。”由此可见财富契约的重要性！而关于一切有价物的所有、使用、租借等等方面的契约集合，就是金融。由此又可见，金融革命必然最终引发一场全面的人类社会的革命。

• 人和人平等相处形成良好的社会靠的是法律这个契约。

• 人跟大自然的契约是科学——很显然你不能因为不同意某个大科学家的学术观点或者质疑他的实验数据的分析方法而把他告上法庭。同理，新冠疫苗怎么研发怎么迭代怎么应用，应该交给科学这个契约来处理。残酷的事实却是疫苗的应用被很多国家的政客越俎代庖，造成全球范围巨大的合作障碍，以及非常广泛的滥用。这个小小的病毒已经让人类蒙受了巨大的损失。

• 第四个契约是人跟上帝签订的契约，它的名称叫道德。这意味着只有上帝有权评判和惩罚违约者。如果有人挟上帝以令他人，披道德之衣置他人于死地，那么你必须明白：这个混蛋非魔即鬼。

契约文明早已经是当今人类社会的主流。值得注意的是，政治是部分人治理国家的行为，它基于一群政客的共识，或者说它是权力中心化的一种方式，但不是一种普适的文明契约——让它凌驾于其它契约之上，是人类社会治理的严重缺陷，但也有人类社会发展的历史必然性。

值得一提的是，人类迄今为止所创建的所有“文明”，都是非常严重的异化体。马克思的哲学思想揭示，我们甚至还处于人类文明的史前时代！

所以，我们曾认为互联网能够消除人类所有的隔阂和偏见。几乎所有人都以为人类已经走过蒙蛮时代，但尴尬的是，所有的网络媒体，从Facebook到Twitter到微博到微信到TikTok再到假模假样声称要纳入ActivityPub协议的Treads，无论是采用公司治理策略还是国家治理策略，都无法还互联网以朗朗乾坤。甚至哈马斯恐怖组织的暴行，都无法唤醒全球各地无数人的良知——包括多国首脑和联合国高官。

中心化权力是野蛮人生存的沃土，是人类异化的力量，人类世界以中心化权力构建起来的治理体系，从权力体系到司法体系，都该被彻底革新了！好在，当前我们正在经历的乱象，就是资本主义穷途末日的表现。而一旦你注意到区块链的本质之一是币（通证）的匿名，结合抗审查、自运行的智能合约，我们就能洞见正在蓬勃发展的人类文明的一次重大升级：从中心化治理迈向去中心化治理！

所谓区块链革命，就是人类的中心化文明向去中心化文明的一次伟大的升级，是我们迈向马克思哲学思想中真正美好的人类社会即共产主义的伟大实践（praxis）。

2017年智能合约的应用爆发后，我马上意识到 AI 公共化的基础已然落地，区块链将是 AI 应用最好的拍档。

这也就意味着：区块链将会携手AI成为契约文明一统天下的终极手段！甚至我可以笃定，区块链+AI 是我们即将迎来的更高阶人类文明即共产主义的治理基石！

至此，我们才能明白为什么比特币创始人中本聪从一开始就把区块链搞成了匿名世界！换句话说，靠谱并且更为先进的治理手段，就是区块链发展的关键。人类文明的去中心化治理方案，除了依赖于区块链的各种治理协议之外，恐怕还需要AI的参与才能闭环——这不只是因为 AI 智能带来的效率，还有个重大的原因是只有 AI 能够帮助人类在区块链世界建立可靠的对作弊成性的人类的管理。

我要学习区块链知识吗？

如果你是九零之后，那么区块链之于你，就像2000年的互联网之于你父母。因此，不管你的基础如何，我都强烈建议你积极follow区块链，不管时局多么艰难都不要放弃，因为“区块链时代”是属于你的时代，当仁不让，就应该是你的态度——其实也是这个时代赋予你的职责！请记住德国神学家朋霍费尔（Dietrich Bonhoeffer）的话：“行动不是来自思想，而是来自一种承担责任的意愿。”

相信我，区块链既然是一场指向共产主义的金融革命，它就不可能不给人类带来人生红利！

区块链同样适合更早年代的所有人，不过要注意几点：

• 区块链还在发展的早期阶段，既不成熟也还纷杂，知识的快速更新将是常态，持之以恒才能保证它给你带来收获。

• 你要依靠自己构建区块链知识体系。交流是必不可少的，但一味地人云亦云、随波逐流只会让你迷失在信息茧房甚至投机泡沫里。

• 区块链的基础是去中心化，它与你所处的现实“背道而驰”，会给你带来重重矛盾——对不少人来说，要解决自己的经验带来的惯性思维，寸步千里！甚至还可能因认知失调而产生焦虑等压力！但不解决这一困境，你就无法参透区块链真正的奥秘！

• 这是一个技术颠覆的大时代，区块链的应用不是孤立的，它必然会与AI、量子力学、基因编辑等等密切关联。你们的头顶只有巨人而鲜有竞争者，但往下看看，你们的弟弟妹妹还会给你几年时间？！

苏格拉底说：美德即知识。

重要的区块链学习和交流资源

以太坊官网：https://ethereum.org/

道易程：DAism.io

Fellowship of Ethereum Magicians：https://ethereum-magicians.org/

登链社区：https://learnblockchain.cn/

以下是我深圳大学本课程里使用的全部幻灯：

《第一讲：比特币》

《第二讲：钱包》

《第三讲：以太坊》

《第四讲：通证标准的进化与应用》

《第五讲：去中心化交易与支付》

《第六讲：激励式开源协作》

《第七讲：以太坊改进提案》

教材开源协作

• 这本教材，也是深圳大学的相关课程的教材。同时开源的还有《Solidity智能合约开发》课程教材（2018~2019年版）。

• 欢迎协作（包括评论、提问、建议等等）。点击页面左下角的Gitbook链接，登陆后（建议先注册个Github账号，这样本书的所有资源都可以通过它直接授权注册登录），即可参与协作。协作完全是开源的，协议请查阅本文尾部的声明。

• 同时也欢迎读者有任何想法，随时点击下面的图标链接，与我们分享和讨论：

作者（暨课程主讲老师、道易程联合创始人）：

• 周朝晖

特别感谢：

• 黄烁萍

• 谭粤飞（《Solidity智能合约开发》课程老师）

• 张华

协议声明

《区块链概论》遵循开源协议Creative Commons Attribution 4.0 International Public License (CC BY 4.0)

This textbook is licensed under a Creative Commons Attribution 4.0 International Public License (CC BY 4.0)

捐助自然道大学

（暂停）

其它学习资源推荐

《马克思哲学革命及其当代意义》（复旦大学哲学院王德峰教授）

《观念经济学》课程（黄江南教授的哔哩哔哩空间、YouTube频道）

《千年金融史》（副标题：金融如何塑造文明 从5000年前到21世纪）

《写给大中华年轻人的公开信》我在热门话题山河大学爆发前几天动笔写的。

快樂營利社會企業 For-profit Social Enterprise

资本战争：普通人如何应对？——全球经济衰退（上）

资本战争：普通人如何应对？——全球经济衰退（下）

Caught in Providence（YouTube）

《苦难的时代：美国奴隶制经济学》[美] 罗伯特·威廉·福格尔，等（Robert William Fogel）

《重要提示 - 面对奥密克戎我们应该做什么？》（周朝晖、Fiona，2022年2月26日）

白纸运动

《我们都是比特币》张张

《孤勇者》（陈奕迅）

《一无所有》（崔健）

《中国孩子》（周云蓬）

《存在》（汪峰）

《春天里》（春天里）

《父亲写的散文诗》（李健）

比特币白皮书（PDF）只有九页，真正一次就能看懂的人不多：

如果白皮书没有显示出来，请点击此处访问。

这是早期翻译版本。我个人认为标题的翻译更为准确：

https://github.com/vaquarkhan/awesome-blockchain-Guide/blob/master/%E7%99%BD%E7%9A%AE%E4%B9%A6/%E6%AF%94%E7%89%B9%E5%B8%81%EF%BC%9A%E4%B8%80%E7%A7%8D%E7%82%B9%E5%AF%B9%E7%82%B9%E7%9A%84%E7%94%B5%E5%AD%90%E7%8E%B0%E9%87%91%E7%B3%BB%E7%BB%9F.pdf

花絮一

美国时间 2011 年 4 月 26 日，比特币创始人中本聪（Satoshi Nakamoto）向其他开发人员发送了最后一封电邮，并在信中明确表示，他已经将专注力“转移到其他事务上”，同时交出了他用来发送全网警报的加密密钥。

最离奇的是，无论地球人怎么努力，十多年了都无法找到中本聪。

中本聪的离开，也许只是为了证明比特币是个匿名世界。你知道他用过的钱包地址，但你无法知晓其实名——十几年的今天，绝大多数人还没明白这一点，更不懂得它的重要性！

花絮二

这是中本聪发出的比特币上线的第一个版本的通知：

由于后来接手的开发团队擅作主张，该通知里的源码链接的页面，已经没有了源码！这意味着我们这个世界现在已经失去了比特币第一个版本（bitcoin core 0.10.0）的开放源代码。对此官网也没有任何说明。这意味着什么你可以深思下。

官网里的bitcoin core 0.10.0是一个被污染的版本：

花絮三

比特币的第一个版本是中本聪写的（当然在很多技术问题上他求助过高手）。嗯，比特币可以说是一个人利用互联网的开放性干出来的。未来十年，将有很多dApp（区块链去中心化应用）都会是由迷你团队甚至一个人独立开发。等你深入了解到智能合约的可自由组合性，你自然就会明白。

本文首发于“”。这里只节选了部分内容。

请注意：imToken等手机钱包的安装也都大同小异。

Trust Wallet同时支持安卓手机和iPhone，通过Google Play或者苹果应用商店iTunes Store（App Store）安装即可。BTW，国行iPhone请换安卓手机除非你已经……

如你的安卓手机无法访问Google Play，请去官网直接下载apk文件安装钱包。

手机访问：

第一步：官网下载

下载后直接安装。

当然如果通过Google Play就更简单了：

（什么情况……知道我最近长膘了吗……）

第二步：创建新钱包

请准备好纸和笔

最好写下你的种子密码（助记词），因为现在它禁止你截屏！

以下是我拍的照片，没有美颜相机……

下一步是测试你有没有记下你的种子密码（助记词）。它会让你按顺序排列出12个单词，因为无法截屏我也懒得拍照……你自己看着办吧。

钱包创建完成，你一定要记得把刚才记录的助记词放到一个安全的地方（譬如防火的保险箱）。

启用通知有个好处，如果钱包收到ETH，或者某些与智能合约相关的操作完成了，会通知你！

第二步：ETH相关的收币、地址复制、二维码收款、发币操作

请自行摸索，或者Google下其他人的教程。

你甚至可以通过Visa卡购买ETH，这是有限额的，只能买一点点。

点击钱包最下方有点像“纪梵希”的四个方块：

你可以选取你想要使用的dApp，你也可以输入网址直接访问应用。

以太坊账户革命：账户抽象化

详见“EIP-2938”。

交易

交易（Transaction）是由帐户发出，带密码学签名的指令。 帐户发起交易即可更新以太坊网络的状态（State，就是我们常说的数据）。

最简单的交易是将 ETH 从一个账户转到另一个帐户。

例如，如果 Bob 发送 Alice 1 ETH，则 Bob 的帐户必须减少 1 ETH，而 Alice 的账户必须增加 1 ETH。 此项操作发生在交易中，会变更状态。

和比特币一样，以太坊交易需要收费并且必须开采才能有效。我们常将交易手续费称为 Gas，将记账流程称为挖矿。

所提交的交易包括下列信息：

• recipient – 接收地址（如果为一个外部持有的帐户，交易将传输值。 如果为合约帐户，交易将执行合约代码）

• signature – 发送者的标识符。 当通过发送者的私钥签名交易来确保发送者已授权此交易时，生成此签名。

• value – 从发件人向收件人转移 ETH 的金额 （以 WEI 为单位，ETH 的一种面值单位）

• data – 可包括任意数据的可选字段

• gasLimit – 交易可以消耗的 Gas 的最大数量。 Gas 单位代表了计算步骤

• maxPriorityFeePerGas - 作为矿工小费包含的最大 gas 数量

• maxFeePerGas - 愿意为交易支付的最大 gas 数量（包括 baseFeePerGas 和 maxPriorityFeePerGas）

更多内容请见：

Gas

Gas 本指在以太坊网络上执行特定操作（包括简单的代币转账）所需的计算工作量。由于用户必须为此计算支付费用，所以 Gas 又常指成功进行交易发起请求的用户所需支付的费用，即交易手续费。

Gas = gasLimit * gasPrice

以下是以太坊交易计费设计的基本原则：

• 以太坊手续费被称为Gas。Gas就是矿工记账收取的ETH的数量。这也就是说，Gas 费用是以太坊的ETH 支付的。

• Gas = Gas Price(一般标示为Gwei的数量) * Gas Limit

• 以太坊每个区块所消耗的总Gas Limit是有限的（但会随着以太坊性能的提升而阶段性增长）。请注意每个智能合约将消耗的Gas Limit通常小于以太坊的总Gas Limit，反之你将无法操作（部署和调用）这个智能合约。

• 你可以预判你将要操作的一个或一组智能合约的Gas Limit和Gas Price。事实上没有人会自己计算Gas Limit的大小（软件会帮你预判，此时它叫start gas，并且很容易理解通常预判的start gas大于实际所需），加上矿工通常会优先为慷慨的手续费支付者服务，如果你担心操作不能顺利完成，那么通常就应该调高Gas Price也就是Gwei的数值，而支付更高的手续费给矿工。

• 如果一项操作成功全部执行。实际消耗的Gas Limit往往比最初设定的要少, 假设gas_rem 是其所剩。在交易结束的时候系统会返还gas_rem*gas_price 数量的ETH到交易发起者的账户。矿工实际收取的交易手续费则为(start_gas-gas_rem)*gas_price 数量的ETH。

• 如果一项操作在执行过程中发现耗尽你支付的Gas还不够，那么所有执行的操作都会回滚，但消耗的资源仍然真实有效，已经发生的交易费用将被转账给矿工。 这就是我们通常所说的操作被取消（或者支付失败），但手续费还是被扣了。

• 当一个智能合约向另一个智能合约发送消息时，它也可以选择设置Gas Limit，这些Gas用于支付由该消息引起的调用。如果在调用执行完成前Gas不够，则该调用状态会被回滚，但Gas仍然被消耗掉了，即你将损失掉手续费。

• 和智能合约交互时将消耗的 Gas Limit 又叫做执行成本(Execution Cost)，它是根据你的智能合约代码被自动计算出来的。

这不是一笔转账交易，而是用户与某个合约交互而产生的手续费。其 Gas Price 为0.000000121728588401 Ether ，或者说121.728588401 Gwei。

请注意：以太坊交易手续费，采用了竞价模式。矿工会优先处理出价高的交易请求！

还有，EIP-1559提案改变了手续费的算法，但因为它是一个过渡阶段的改变，在此就不做详细介绍了。

比特币和以太坊交易的差别

我们要清楚即使是交易，比特币和以太坊都相差甚远：

• 如果不拥堵，比特币交易（转账）的手续费可以很低，可以相当长的时间内没有什么变化，并且还可以每笔转账的手续费的差别都很小。因为比特币只要以转账所占用的账单字节数决定手续费的多少就行了。

• 以太坊的情况则要复杂很多，以太坊有外部账户（Externally Owned Accounts，EOA）和合约账户（Contracts Accounts，CA）两种账户。这意味着有些转账和比特币一样，是外部账户点对点的转账。这种类型的交易手续费同样可以很低而且相当长的时间内没有什么变化。而更多的以太坊手续费，是与其中大量的合约部署和调用有关的——将这种情况称之为“操作手续费”而不是交易手续费，其实更贴切些，但为了和上一种情况统一，我们仍然称之为交易手续费。很自然的，此时以太坊的交易计费就需要考虑与智能合约的部署和运行相关的很多资源的消耗，包含带宽消耗、存储消耗、计算消耗。这些资源都需要以太坊节点提供，和比特币相比，它就不能只考虑记录的数据量的多少。智能合约操作手续费往往大大高于外部账户点对点的转账。

比特币和以太坊的交易手续费的计算不光相差甚远，而且由此可知：比特币以每个账单的大小限制每个区块。以太坊以一个代表带宽消耗、存储消耗和计算消耗的总和的Gas Limit，来限制每个区块所用的资源——或者说，来保证以太坊始终能够让其承载的智能合约都自如地得到应用。

比特币和以太坊，显然不在同一个维度上。

阅读参考：

电脑钱包安装

电脑钱包实际上也分两种：浏览器钱包和app钱包。

你的电脑必须先安装Chrome或者Firefox浏览器。360浏览器因为采用了Chrome的核心也可以。

准备好笔和纸。别说我老土，不要只用电脑备份助记词！更不要用手机拍照保存助记词，不要用任何app记录助记词。如果纠结的话你就去网购个保险箱，我是认真的，哈哈哈……

Chrome或者Firefox浏览器的安装流程大同小异，以下主要以Firefox为例。

火狐浏览器FireFox

安装浏览器插件当然在浏览器里面就可以，有的人会建议你去官网，这样当然也可以……

一分钟的事，你要加油哦！

第一步：点击浏览器右上角

第二步：搜索MetaMask

第三步：点击MetaJask插件名称

第四步：添加MetaMask到Firefox

第五步：浏览器右上角可以看到MetaMask图标了

第六步：创建钱包并接受协议

第七步：创建钱包，但从现在开始就要拒绝把密码交给第三方保管

第八步：拿出你的笔和纸，备份种子密语（又叫种子密码、助记词）。不备份是无法进行下一步的。

第九步：确认种子密码（助记词）

第十步：钱包安装就绪，准备开启你新的人生

谷歌浏览器Chrome

谷歌浏览器里安装MetaMask钱包和火狐浏览器基本一样，一分钟的事。你要加油哦！

第一步：点击浏览器右上角？不，我讨厌谷歌浏览器迷宫一样的浪费时间的扩展管理操作！请直接输入以下网址：

为什么钱包里面都英文？这是一个全球化时代，经过很多年的自废武功，中文已经支离破碎，还是学会看一点英文吧——反正你很多时候没得选择。

固定MetaMask插件到浏览器右上角。

1. 如何保存私钥？

2. “中神钱包”是一种数字资产硬件钱包，代码没有开源，有“美国FCC认证”标识，请评价其安全性。

3. 请评价浏览器钱包Metamask的优缺点。

4. 请在手机上安装一种多币种钱包，并编写一个简单的安装与备份的使用指南。钱包试用推荐：

   手机钱包pillar. 、Trust Wallet、imToken国际版、WallETH钱包（只有安卓版）：

   纸钱包Ethaddress

   奇葩钱包（官方自称为智能钱包Smart Wallet）Argent（

   多币种钱包Coinomi或Jaxx Liberty

5. 请查阅资料，详细解析以太坊的多重签名的应用，并与比特币的多重签名进行优缺点的比较。

6. 下载、安装并试用Status钱包：

　　Status是一款融合了P2P消息、去中心化加密货币钱包以及Web3浏览器于一体的多功能通讯工具。

　　必须遵照其要求备份私钥助记词和仨交易签名单词！出现任何漏洞都可能会让你的资产受损。

百度百科云：钱包，顾名思义是装钱的包包。

什么是（区块链）钱包？

区块链钱包（以下简称钱包）是让人们能够管理自己的区块链账户，并且与去中心化应用（dApp）交互的工具软件。

显而易见：钱包是区块链的应用入口。

也许你已经注意到，每个公链和每个dApp（去中心化应用），都至少拥有一种具有货币属性的专属通证（token）。我们通常把这个具有货币属性的通证叫做代币。代币有多种作用，譬如安保、奖励、估值等等。将会有详细的介绍。

具体到日常应用，当我们将智能合约部署到以太坊，我们需要通过钱包从自己的账户里支付gas（手续费）。当我们到一个去中心化交易网络里交易代币的时候，我们既需要钱包从自己的账户里转出要卖出的代币接收要买入的代币，还需要用钱包从自己的账户里支付完成这些操作的gas（手续费）。这就是说，在我们使用每个公链和每个dApp的时候，常常需要动用到代币。由于代币是在我们的账户里，要通过钱包才能动用账户，因此这些操作就常常需要钱包才能完成。

大多数区块链钱包都非常像银行，它管理的是你个人的，多个人的，一组或多组人的账户，并且一个人可以在一个钱包里生成、导入并使用多个账户。

但与银行不同的是，钱包和账户并非绑定关系：一个账户可以在多数钱包里使用。你也可以在一个钱包里，拥有任意多个账户。

还有：没有人能够冻结你的账号，撤销你的转账，也没有消费限额……并且无论对方在地球的哪个角落，转账的确认时间都与地域无关。

根据载体的不同，区块链钱包分为计算机钱包、手机钱包、浏览器钱包、硬件钱包、纸钱包和脑钱包等等，这样不管您使用的是何种设备，或者有什么样的需求，都有配套的钱包供您使用。

其中脑钱包因为实际使用时安全性太低，基本已经被淘汰。

硬件钱包是为了离线生成和保存私钥，是目前“公认”比较安全的代币存储方案。代表品牌有、、、。

浏览器钱包的代表为Metamask、Jaxx。

手机钱包的代表为Trust Wallet、MetaMask、imToken、TokenPocket。

因为使用方便、用户群体大，手机钱包已经成为主流。计算机钱包的特点则刚好相反。

以太坊账户

以太坊的账户模型则跟我们通常所理解的账户概念是一致的。

一个以太坊帐户是一个可以拥有 ETH 或其它通证余额的实体，可以在以太坊上发送交易。并且其中的通证包括但不限于代币。

帐户可以由用户控制，也可以作为智能合约部署——这样以太坊便有了两种类型的账户：

• 外部所有账户（常被简称为外部账户。Externally Owned Accounts，EOA）：人类常用的存储自己的通证的账户。外部账户由私钥（或者说私钥的所有者）控制。

• 合约账户（Contract Accounts，CA）：部署到网络上的智能合约。它是只受智能合约代码控制的账户。

这两种账户都能：

• 接收、持有和发送 ETH 和通证（token）。

• 与已部署的智能合约进行交互。

两种账户的主要区别

外部账户

• 创建帐户是免费的

• 可以发起交易

• 外部帐户之间只能进行 ETH 和通证交易

• 由三部分组成：地址、公钥和私钥。公钥和私钥是一对加密密钥，它们联合控制帐户的活动。

合约账户

• 创建合约存在成本，因为需要使用网络存储空间。

• 目前只能在收到交易时发送交易。

• 从外部帐户向合约帐户发起的交易能触发可执行多种操作的代码，例如转移代币甚至创建新合约。

• 合约帐户没有私钥。 它们由智能合约代码逻辑控制。因为合约代码就是合约账户的组成部分，你可以理解为合约账户目前是由外部请求驱动的，根据代码逻辑和状态（数据）自运行的账户。

外部账户之组成：助记词、私钥、公钥和地址

以太坊账户通常是以上四个部分的复合体。

首先，你的各种“币”，都在你的钱包地址里。你给某个地址转账时，钱包会动用你的私钥对交易进行签名，在公钥的配合下广播这笔交易。

私钥固定长度为256位，使用十六进制表示就是64个字符：

6954ac6d0402d7239f1cc150da224d0ef08fd1226f245f06fe4d6d68accfce8a

你可以使用硬币随机挑选你的私钥：投掷硬币256次，得到可以在以太坊钱包中使用的随机二进制数字作为私钥。那么恭喜你，你就是个书呆子。好消息是，书呆子们正在颠覆旧世界。

私钥貌似足够安全，但实际应用中总是有人会自作聪明犯下大错：

比特币和以太坊获得私钥的技术手段都是类似的；之后使用某个椭圆曲线算法将私钥转换为公钥，公钥再通过哈希算法和Base58Check编码转换得到地址。

有了某个地址的私钥，您才能使用它收款或转账。

那助记词又是咋回事呢？

更多参考：

在区块链里私钥至关重要！它解决了其它一切手段都望而却步的怎么证明“你妈是你妈”的难题。对于你自己的资产，你毋须证明，因为私钥在你手上，其它任何人都休想能染指你的财产。这个世界从此少了很多被他人巧取豪夺、打家劫舍、掐尖落钞的烂事。

在日常交易中除非使用纸钱包，否则您通常并不用操心私钥公钥是什么，只要懂得使用钱包转账就足够了。

地址是一串很长的字符串，譬如这是某人接受比特币打赏的地址及其二维码：

1KorAWmhGaEnedUviL4rXPfsrHCB7ZVFoB

0xf69451503E7EaEc6fe82E1129316104D2458010a

对于私钥，我们要先牢记四个简单的区块链基础逻辑：

• 私钥是不可能被假冒的。

• 私钥是完全私有的密钥，它应该自始至终都密不示人。因此在通常的支付场景下，你永远不应该出示你的私钥，你顶多需要使用私钥对你的转账进行签名—— 这个流程一般是钱包自动帮你做的。

• 谁拥有某个地址的私钥，谁就是该地址上的那笔数字资产的主人。

• 这是一个将人匿名的零知识证明！说明区块链应该坚持匿名原则！

零知识证明(Zero—Knowledge Proof)，是由S.Goldwasser、S.Micali及C.Rackoff在20世纪80年代初提出的。它指的是证明者能够在不向验证者提供任何有用的信息的情况下，使验证者相信某个论断是正确的。

钱包与账户或者某个地址（严格地说是私钥）没有绑定关系，一个账户可以在多数钱包里使用。

验证者密钥

以太坊还有一另种类型的密钥，它们是在以太坊从工作量证明过渡到权益证明共识时引入的。 它们是“BLS”密钥，用来识别验证者。 这些密钥可以有效地聚合，减少网络达成共识所需要的带宽。 没有这种密钥集合，验证者的最小质押金额将会高出许多。

合约账户的组成：地址和合约代码

合约账户没有私钥公钥这些累赘，它只有地址，以及它自己的合约代码。

它的产生是这样的：首先你要写好合约代码，然后将合约部署到以太坊主链，部署过程中以太坊主链会根据随机算法给你的合约生成一个唯一的地址。

合约账户的地址也是42个字符组成的十六进制地址。

以太坊账户维护的状态（数据）

• nonce：外部账户为交易次数，合约账户为创建的合约序号。

• balance：该地址的以太币余额。

• storageRoot：账户存储内容组成的默克尔树根之哈希值。

• codeHash：账户EVM代码的哈希值。外部账户为空字符串的哈希值，合约账户为合约代码的哈希值——请注意只是合约代码的哈希值。以太坊智能合约部署后会创建一个合约账户,合约账户里保存着智能合约的编译之后的可执行字节码(在EVM里执行)，并且有存储空间,合约能对合约账户的空间写入信息。

以太坊账户革新：账户抽象化（Account Abstruct）

它最早的目标是将两类以太坊账户抽象为一类，让合约账户也可以和外部账户一样支付交易费和执行交易。之后六年逐渐演化，发展出比特币无法企及的伪交易对象！

这也就是说，以太坊正在试图模糊两类以太坊账户的界限。2020年年底以太坊创始人V神等几个人发起了技术提案Acount Abstraction（EIP-2938），其核心“账户抽象”的目标是让智能合约成为顶级的账户类型，而非受限制的必须由外部账户调用的账户，这样合约账户就可以主动发起事务并支付手续费。这也就是说，没有了人类之手，区块链dApp一样可以在其它外部条件的触发下，自行启动其它操作，包括主动与其它合约交互！这一提案，非特斯拉的自动驾驶可以相提并论，意义深远！

账户抽象化实现后，因为合约帐户将能自主触发可执行多种操作的代码，譬如创建新合约，那么结合 AI ，对其应用我们就有了极大的想象空间。这一技术创新将给人类社会带来巨大的变化！

落后的比特币转账机制

比特币并没有所谓的账户。

比特币转账和以太币转账不同的是，它会将全部数量的比特币从某个或某几个地址发送出去，将需要支付的数量打到收款方的地址上，并将剩余的比特币打回到自己的一个新地址亦即“找零地址”上：

比特币的这个模型叫UTXO模型。UTXO英文全称为：Unspent Transaction Output，翻译为中文为“未花费交易输出”。理解UTXO最简单的方式就是类比我们平时使用的纸币：支付是交易输入，收款是未花费的交易输出。

“找零地址”在一些新版钱包里可自行设置，或者自作主张已经默认为原地址。但中本聪显然不建议置为原地址，他认为那样不安全，也就是不利于保护隐私。

同样因为比特币可以被跟踪，每次转账都需要向对方出示公钥和地址，为安全起见，比特币建议每次支付的时候，也都使用新的地址（实际上私钥、公钥和地址就全部换新了）。

比特币的UTXO模型的优点：

• 隐匿性比较强，理论上可以为每一笔输出设置一个地址。

• 无需维护余额等状态值。

• UTXO是独立数据记录，可以通过并行极大的提升区块链交易验证速度。

• 无需关心事务问题，只需要关心输出脚本即可。

• UTXO无法分割，每次交易都需要多个输出，分别为支出与找零。

账户模型的优点

• 可快速获取账户的余额，而比特币需要将指定地址所拥有的所有UTXO中的未花费交易总值整合。

• 节省记账空间，因为每笔交易只有一个输入一个输出。

• 可以较容易的实现图灵完备的智能合约——这一点，让以太坊已经拔高一个维度，超越了比特币的电子现金的定位，对于区块链的应用发展意义非凡！

重要提示

通过近年来AI技术、量子技术、常温超导技术、区块链技术等的涌现，我们意识到接下来二三十年人类有可能进入一个科技的颠覆期！

对区块链的发展来说，充满了无数的机会。但对区块链的技术创新来说，同时也就意味着有无数的失败！

难以置信，对吧？

• 比特币只是利用加密算法，实现了将人匿名的手段。

• 未来我们还需要接受挑战，用抗量子攻击的算法升级现有的匿名算法。

• 以上第二步未必能够顺利达成。

• 人类社会的财富概念，可能也会被颠覆！

• 在全球化不断深入的未来，迫在眉睫是，我们要尽快摸索到人类福利体系的创新解决方案！

对年轻人来说，区块链就是很热血的行业！

Just do it!

数字加密货币的产生

在比特币发行之前，已有存在种不同的“ecash”技术和产品。最早的起源来自David Chaum和Stefan Brands所提出之以发行者为主的ecash协议。接着许多以ecash协议为基础的数字货币等产品开始出现，其中以Adam Back的“hashcash”、戴维(Wei Dai)的“b-money”、Nick Szabo的“bit-gold”，以及Hal Finney在“hashcash”技术上发展的“RPOW”等为代表。

但这些数字货币都没有真正成功。

2008年下半年经济危机爆发，11月中本聪发表论文《Bitcoin: A Peer-to-Peer Electronic Cash System》

2009年1月3日，比特币网络上线，中本聪挖出创世区块（genesis block）。由此开启了一个新时代，也标志着数字加密货币的诞生。

比特币钱包

收集了来自68个不同国家反馈的“Bitcoin Survey 2016”的调查结果：

“对于密码学货币爱好者来说，丢失比特币是另外一个重大的挫折。16%的受访者表示由于交易所被黑而丢失过资金……12%的受访者表示无法访问他们的钱包而丢失过比特币。在大部分情况下，是因为丢弃设备而且没有进行钱包备份财导致了这种情况的发生。”

结论：

• 中心化交易所经常被黑客入侵，是最不安全的地方——但在得到那么多惨痛的教训后，大多数交易所采用了冷热钱包分离的手段（个别大型交易所甚至采用百分百冷钱包，完全由人工提供手工服务），保证即使黑客入侵，也只能黑走热钱包里的比特币，让全部损失控制在15%之内。

• 务请记得及时备份您的钱包！如果你嫌有的钱包麻烦，我给您推荐这个钱包：Coinomi。

• 不要给钱包设置过于复杂的密码！

在钱包的推荐方面，做得最好的是bitcoin.com：

https://bitcoin.org/zh_CN/choose-your-wallet

现在已有下列钱包可供选择：

Bitcoin Core、Bitcoin Knots、MultiBit HD、Armory、Electrum、mSIGNA、Bitcoin Wallet、breadwallet、Bither、GreenBits、GreenAddress、Coinomi……

官网特地用了随机排列的方式推荐比特币钱包。以上排列也是随意的。

如果您想自己好好选择一个钱包，那么您要先搞懂这些概念：

资金的掌控权——指您对资金究竟有多大的控制权。其中一般有两种情况：

1. 资金掌控权（Control over your money）——这个其实应该翻译为“完全自控权”，因为是您全权掌控自己的资金，没有任何第三方帮您管理资金，也没有任何第三方可以冻结或是弄丢您的比特币，您自己全权负责，出了问题没人能帮您！Coinomi采用的就是“完全自控权”，但它通过一个技术机制，大大降低了“完全自控权”的使用风险，后面马上就有细节介绍！

2. 共享的资金掌控权（Shared control over your money）——交易时需要第三方一起授权才可以完成。比如GreenAddress 钱包要求每一笔交易都必须由您和第三方一起授权才能完成。如果您使用的是 GreenAddress ，而又想改为全权掌控自己的资金，您可以使用原始备份或者之前通过邮件发送给您的已签名交易来重新获得完全自控权。如果您看不懂这句话的意思，又怕第三方耽误事，那么您最好不要选择这种钱包。

交易验证——您的钱包涉及一笔交易时，它通过怎样的机制来完成交易的验证：

1. 全面验证（Full validation）——就是使用区块链的全部数据来进行验证交易。专业上叫通过全节点（Full Node）进行验证。这样您的钱包要下载比特币区块链的所有数据（已超过80G），在网速比较慢的吾国，有时候可能需要好几天时间。因为使用全部数据，这种验证无疑是最最安全的交易验证方式。

2. 简化验证（Simplified validation）——技术上讲是简易节点型（SPV Node）验证，就是仅下载Block头部信息，无需交易数据来做验证。安全性不及全面验证，但使用时因为不用下载数据，比较快捷。

3. 分散验证（Decentralized validation）——去中心化验证。这种钱包通过一个列表，随机连接一个服务器进行验证。这意味着在验证支付的时候需要完全信任第三方（您所连接的服务器）。安全性显然也不及全面验证。使用时一般比较快捷。

4. 集中验证（Centralized validation）——钱包依赖于一个中心化管理的机构，直接借助这个机构的服务器上的数据进行验证。这意味着您需要完全信任这个第三方。第三方如果提供假数据或者被黑造成数据被篡改等等情况，都会危及到您的资金安全！Coinomi采用的就是集中验证。

钱包的透明度——一般是指钱包的代码的透明度：

1. 完全的透明度——钱包的所有代码都已经开源，任何人都可以看到钱包的全部代码。这样钱包有没有造假就一目了然了。

2. 基本的透明度——钱包的客户端，或者说您安装到电脑或者手机里的那部分的代码，已经开源。不过这毕竟只是客户端这部分开源，还有一部分是在一个黑匣子里的，这就需要您去信任开发团队或相关公司。Coinomi就属于这种情况。

环境的安全性——电脑容易受恶意软件攻击，其安全性很低，手机环境则相对安全很多，所以电脑环境属于脆弱的环境，手机环境属于安全环境。

1. 安全环境（Secure environment）——无电脑版，只能安装到手机里。Coinomi属于这种情况。

2. 脆弱的环境（Vulnerable environment）——有电脑版。

隐私性——您的交易信息是否会被泄露：

1. 增强的隐私性（Improved privacy）——通过滚动地址（每次交易都使用一个新的比特币地址）的方式来大大增加窥探您的余额和支付历史的难度；交易时钱包不会在网上给其它节点披露敏感信息；并允许利用匿名网络Tor来防范攻击者或防止互联网服务供应商把您的支付和您的IP地址联系在一起。

2. 基本的隐私性（Basic privacy）——也通过滚动地址（每次交易都使用一个新的比特币地址）的方式来大大增加窥探您的余额和支付历史的难度。但其它节点可能可以在接受和发出支付时登录您的IP地址并把它和您的支付联系在一起；或者钱包不允许您利用Tor来防御攻击者或防止互联网服务供应商把您的支付和您的IP地址联系在一起，甚至或者后两项兼备。Coinomi属于这种情况。

3. 脆弱的隐私性（Weak privacy）——通常是因为钱包重复使用同样的地址，使得任何人都很容易窥探到您的余额和支付历史。或者是因为钱包所使用的是中心化管理的服务器，造成它会披露部分信息给其它节点（比如在接受和发出支付时记录您的IP地址并把您的支付联系在一起）；或者钱包不让您利用Tor来防御攻击者或防止互联网服务供应商把您的支付和您的IP地址联系在一起；或者后三者兼有。

从调查结果可以看出：真正发生率高的危险还不在于钱包本身，而是用户要根据自己的习惯选择适合自己的钱包，并妥善使用。

以太坊钱包

以太坊的数据存储和以上介绍的比特币钱包的数据存储没有本质差别。

我想重点提醒大家的是安全保护。

助记词保管方法

• 用纸抄写

  只要是抄写，就会有一定的错误率，所以建议抄写两遍

  另外请注意墨和纸张的质量

  多年后可能需要复抄，错误率又会上升

  抄写完一定要记得复核

• 用纸抄写 + 防火保险柜

• 专业防火设备抄写

资产损失的可能

• 助记词或私钥遗失（多因未备份）

• 手机或电脑损坏

• 被骗走助记词或私钥

• 助记词或私钥暴露或被盗

  云存储、软件传递、拷贝、中木马病毒、远程入侵、手机或电脑被回收、摄像头拍摄等等，都可能导致助记词或私钥被盗。

• 误授权

• 使用了假钱包

• 在伪劣项目里被骗转账操作

• 意外身亡

连接钱包（WalletConnect）

在以太坊dApp的首页面，我们常常能看到一个叫“连接钱包”的按钮。这个按钮的背后对应的是一个叫做WalletConnect的协议。

WalletConnect是加密货币钱包广泛使用的协议。WalletConnect 是去中心化的 Web3 消息传递层，是将区块链钱包连接到 dapp 的标准，它支持个人钱包账户与DApp和其它钱包关联交互。即通过扫描二维码或点击深层链接，WalletConnect 在钱包账户与DApp之间建立加密连接。

该开源协议也会推送通知，提醒用户即将到来的交易。

大多数DApp的右上角均设有“连接钱包”按钮，如果你使用的是手机钱包直接访问该DApp网站，点击该按钮即可。

如果你使用的是桌面浏览器访问DApp网站，则点击“连接钱包”按钮。屏幕中可能随即显示列出不同钱包关联选项的弹窗。点击[WalletConnect]，生成二维码。你要用手机钱包扫码，才能建立连接。

更多技术细节请访问 WalletConnect

使用以太坊登录 (Sign-In with Ethereum, SIWE)

“使用以太坊登录” (Sign-In with Ethereum, SIWE) 颠覆了互联网上的用户身份验证手段。

使用以太坊登录描述了以太坊帐户如何通过签署由作用域、session详细信息和安全机制（例如，随机数）参数化的标准消息格式来使用链下服务进行身份验证。

最新的智能合约标准为EIP-4361。

SIWE的目标是为中心化身份提供者提供一种自我托管的替代方案，提高基于以太坊身份验证的跨链服务的互操作性，并为钱包供应商提供一致的机器可读消息格式，以实现改进的用户体验和授权管理。

SIWE的动机

在登录当今流行的非区块链服务时，用户通常会依赖于身份提供商 (IdP)，这些身份提供商是对用户身份具有最终控制权的中心化实体，例如大型互联网公司和电子邮件提供商。这些机构之间的动机和嗜好往往不一致。Sign-In with Ethereum 为希望对自己的数字身份拥有更多控制权和自行担责的用户提供了一种新的自我管理选项。

许多服务已经为使用消息签名对以太坊帐户进行身份验证提供了工作流，例如建立基于 cookie 的网络会话，该会话可以管理某个身份验证中地址的特权元数据。这是一个标准化登录工作流程并能改善现有服务之间互操作性的机会，同时还为钱包供应商提供了一种可靠的方法来将签名请求识别为使用以太坊登录以改进用户体验的请求。

不需要经过中间商，用户现在可以使用控制其以太坊钱包账户的同一个私钥直接登录dApp。通过SIWE，我们开辟了另一条道路，大公司不再能剥夺用户访问服务的能力，也不能监视他们的行为。

SIWE 是一个完全公开的认证标准，通过与dapp、app、钱包、安全公司等社区成员的公开讨论来实现。你可以在网站login.xyz 上找到所有的会议记录和笔记。这种方法与科技巨头或政府供应商的专有身份系统的封闭式开发大相径庭。

简言之：Sign-In with Ethereum (EIP-4361) 为以太坊账户定义了一种开放的知识共享(creative commons, CC) 签名格式，以安全地验证任何基于网络的服务。

连接钱包vs. 使用以太坊登录

“连接钱包” 这个按钮是现在dapp 的主要功能。点击这个按钮，用户就开始了与Web3 和区块链交互的旅程。

通过连接钱包，应用程序可以知道你使用的是哪个账户，这样你的钱包就知道你想用哪个账户来与智能合约互动或者发送通证，甚至通过dapp 对信息进行签名。

当应用程序想要和用户进行更丰富的情境交互(contextual interactions) 时，比如加载用户的偏好或隐私聊天讯息，我们首先需要确保我们是在和该账户背后的实际私钥持有者对话，而不是某个假装对账户持有控制权的人。“连接钱包” 不提供这种保证，但SIWE 可以。换句话说，我们需要对用户进行身份验证，以便与他们建立一个session，然后安全地读写他们的数据。

SIWE 信息也可以被理解为访问特定资源的授权，或者对session 私钥的委托，以提高dapp用户体验的功能性和易用性。

更多内容，可参阅：

SIWE（使用以太坊登录）技术前沿讨论

思考题：

如果将SIWE技术应用到最近正在爆发中的联邦宇宙软件如Mastodon里？

背景知识：Mastodon（长毛象）是一个免费开源的分布式社交网络，它的使用体验类似 Twitter，但在体验上更佳。首先，长毛象拥有一条完整的时间线，不会有广告干扰和人为打乱。其次，它属于联邦宇宙软件（Fediverse），任何人都可以用它部署一个长毛象站点。每个人不仅可以浏览站点中的嘟文，还可以关注和浏览整个长毛象宇宙中的任何站点和账户。从而实现完美的跨站社交。Mastodon（长毛象）是掌握在我们手中的社交网络。

Mastodon（长毛象）的使用正在爆发，并且我们预期它比SocialFi的效率更高，SocialFi有很多缺陷，譬如人们会把过多的精力放到币价的涨跌上，短时间开发的平台会因bug或硬件配置过低而出现拥堵甚至崩溃等情况。

2011年～2014年，随着比特币的传播，一些早期参与的程序员通过修改比特币的源代码克隆比特币。譬如：

• 2011年8月出现名为IXCoin的第一款竞争币。IXCoin只是更改了比特币的一些参数，主要通过调整初始每个新块的奖励为96个币，从而增加了货币的发行量。

• 2011年9月，另一款竞争币Tenebrix首次使用了不同于比特币的工作量证明算法script，这种算法起初是为了防止密码遭暴力破解而设计的。Tenebri的目标是通过使用这种消耗内存的算法来实现一种不依赖GPU和ASIC芯片的加密货币。

• 2011年10月7日吸纳了script算法的莱特币破茧而出。莱特币还把新块产生的时间从比特币的10分钟缩短为2分半钟。考虑到莱特币8,400万的货币总量和相对更快的确认速度，很多莱特币的拥趸相信与比特币相比，莱特币更适合零售业的交易。

2013年比特币价格的爆涨，大大刺激了竞争币的发展。2014年市场上的竞争币数量一度超过500种以上，总的来说，追本溯源，绝大多数的竞争币都来自比特币源代码的克隆，因此国人也称它们为“山寨币”。

但仍有不少竞争币在技术上进行了各种有益的探索，也在应用层面提出了不错的构想、做出了最终以失败告终但对区块链的发展有益的应用尝试。

譬如在比特币经过两年的实践之后，人们开始意识到区块链应不仅仅是单一货币功能的比特币，还应该往各种应用的方向拓展。域名币率先以去中心化的域名系统为应用目标，对区块链进行了现在看似微小但意义重大的探索。而到了2012年，受到启发的人们希望探索到更多的区块链应用的可能，例如执行金融合约。这一时期的杰出之作就是万事达币（Mastercoin）。2013年加入Mastercoin团队的Vitalik Buterin把它比作是瑞士军刀——即集多个功能于一体的工具，但问题在于需要支持的应用实在太多了，因此，Vitalik希望创造出类似智能手机的平台——通用的超级计算机，任何东西都可以通过编程在这里运行，代表区块链2.0的以太坊因此应运而生。

至此，区块链破茧而出，展翅高飞！

从另一个角度看，竞争币中的绝大多数，最终只是用残酷的事实，揭示了比特币的局限性，它们最终失败的结局，也让我们看到了区块链发展的艰难性！

整个竞争币时代，只有以太坊于2014年真正带来伟大的创新，将智能合约的概念和实践带入区块链，脱颖而出。但匿名币带来的零知识证明，最终以监管记账之用途被部署到以太坊2.0，也做出了应有的贡献！失败，并不等同于没有意义！

关于竞争币的详细讨论，可以参阅《精通比特币》（第1版）：

http://zhibimo.com/read/wang-miao/mastering-bitcoin/Chapter09.html

在ERC-1155问世刚好一年时，它成为了一个以太坊官方的通证标准并且可被整个以太坊开发者社区使用。

大约2018年6月17日，Enjin首席技术官Witek Radomski在以太坊的github仓库里发布了最初版本的ERC-1155多通证标准并且开放了一个讨论用来评论和反馈。

从那时起，这个标准就收到了大量的来自社区的超过50个版本和400个评论的支持。社区进行了大量投入并且帮助改进ERC-1155使之成为以太坊上最好的通证标准。

为什么要耗费这么多的精力去做这件事？

ERC-1155是什么

一个可管理多个通证的标准合约接口，只用部署一个合约更可以发行并管理任意多种同质通证、非同质通证或者半同质通证。

官方的总结说法是：

“用于管理多通证类型合约的标准接口。单一部署的合约可包括同质通证、非同质通证或其它配置（例如半同质通证）的任何组合。”

以太坊改进目标

几年前，以太坊社区提出了一系列新的以太坊改进目标。其中一位社区成员在以太坊github页面上提出了一个新的议题，它描绘了一个有利于区块链和围绕它的生态环境的新的特性、流程或者标准。

在Enjin，我们于2017年在内部建立了称之为单一通证合约的事务。我们认识到当前的ERC-20和ERC-721通证标准并没有达到我们想象中可应用于游戏中的灵活性。

最终，我们认识到这种单一通证合约结构拥有大量的优点并且可以应用于游戏或者其它业务场景，如果我们想将这些新通证成为一个实现，就必须标准化它。

创建一个标准意味着大多数的以太坊社区会开始支持它，这就会为那些钱包、交易对、游戏进行调整和新项目使用通证化的区块链资产铺平道路。

一个智能合约，多种通证

当前，ERC-20和ERC-721标准每发行一种通证便需要部署一个新的合约，而隐藏在ERC-1155标准后面的核心概念是一个单一的智能合约可以管理无限种类的通证。

想你一下一台自动购物机，它里面有苏打水、果汁和小食品。消费者通过一个单一的安全接口（投一个币、按一下按钮）来和机器交互。机器根据消费者选择来提供商品。相似的，一个ERC-1155标准的游戏合约可以由大量物品或者组件组成，代表从武器到盔甲到血量值、魔法值等等。

所有这些物品或组件都是可重复的，你可以得到不只一件。可重复通证经常用作可拆分货币（绝大多数ERC-20通证），重复通证对于可堆叠物品十分有用（它们不需要被区分），比如说某个弓用到一筒箭。

另一种通证叫着不可重复通证（NFTs)。这种结构允许每一个通证都有自己独特的参数、历史和对真实世界的映射。在一个视频游戏里的宠物龙可以是一个NFTs，它在游戏中拥有自己独特的名字，等级和历史。

批量交易

在ERC-1155里，可以在一个交易里发送多种通证，它会节省gas费用并且防止用户在单一交易中必须等待每一个块。

使用ERC-1155的项目也可以建立原子交换（类似于事务，译者注），它允许用户绝对安全的交换某两种通证，期间不会有诈骗和第三方参与。

进一步的优化

一些作者的进一步体验形成了了更多的优化和费用节省。

沙箱开发者Ronan Sandford使用ERC-1155实现已经完成了在保持正确拥有关系的前提下，在一个块中发行超过1500种通证的尝试。

地平线游戏开发者Phillippe Castonguay已经能够使用一种叫着余额打包技术来节省80-90%的gas费用（同正常的transfer相比）

同时，Phillippe 使用ERC-1155也达到了一秒发送155种资产的传输速度。

数据经济

ERC-1155多通证合约最主要的特点是在一个合约中实例化多种通证。这就意味着创建一种通证只是简单的方法调用，它仅在通证池里增加一个新的ID。

作为对比，创建一个新的ERC20或者ERC-721通证意味着编辑源码并且部署一个新的合约。部署合约会花大量的gas，因为在以区块链上储存数据是昂贵的。绝大多数ERC-20合约基于相同的代码，只需要改动几行，因此其余代码其实是不必要的。这就意味着整个以太坊超过25000个节点中的每一个都要存储这些冗余代码从而变得臃肿。

还有一种类型的开销需要被注意，每一个ERC20或者ERC-721合约都有一个地址，100种通证便需要查询或者监听100个地址，对钱包或者其实软件来讲，必须小心这些通证是否存在。

因此，虽然前面两种标准在一些窄应用场合比较适合（一个单一的货币或者单一的NFT），但是这些数量的创建者可以从ERC-1155标准受益，因为它们可以从非单一的类型创建新的通证并且不需要多个相同的合约。

通证可靠的严格规则

ERC-1155标准中，大量特性被用来构造通证必须严格遵守的规则。

ERC-1155通证是第一种可以通过简单的发送通证从而来执行一个可计算的合约方法的通证。

这是一个巨大的进步

通过简单的发送一个通证到DEX交易对地址，这个交易对能立即返回另一种通证到发送者地址。相似的，一个区块链游戏可以每当它收到ERC-1155通证时便执行某些游戏方法。无需访问ABIs或者同智能合约直接交互，你就可以打包、转换、加工或者托管通证。

这种类型的功能最开始在ERC-223被提出，但标准最后失败了。ERC-721也只是实现了“safeTransferFrom”，但是却有一个致命的问题，即没有对所有的交易者进行这样的严格查询。这就意味着用户可能永久的丢失他们的通证并且合约作者在发送通证时无法依赖一个确保的执行。

在ERC-1155中将此限制的更严格意味着可依赖的智能合约和通证网络现在可以开始建立这种强大的功能。用户所需做的一切仅仅是简单的向一个地址发送他们的通证，它会触发一个令人惊叹的事件链。

元数据

在过去一年里，ERC-1155标准的一个主要更新就是决定将所有的和通证相关的元数据移至一个外部的json文件。这个很大部分是受了ERC-721元数据扩展的启发，但是增加了一些改进。

没有更多的老式元数据

Symbol：（由ERC20和ERC-721标准发明）不再包含进来，因为它不再是和虚拟物品/资产的数据相关的数据的一部分。这个3字母的符号能正常的应用于报表或者货币交易，但是它们在通证化一般物品（组件）时不再有用。

**Name：**名称也被从当前的核心标准里移除了。为什么？在许多已应用的场景中，在区块链上存储一个名字是一种奢侈行为。作为替代，每个通证的名字现在可以在json元数据标准里定义。

ID替换

通过使用替换字符串“{id},”，一个ERC-1155合约不需要在链路上存储任何额外数据就可以指向无限数量的通证URI。对每一个通证而言，这种替换甚至可以用来指向一个可以从通证json产生的动态主机的web服务。这个替换字符串本身也可以用于json自身来自动链接每个通证的图标。这大大减少了开发者为了显示大量种类的通证的元数据所产生的开销。

本地化

由于通证信息定义成json格式，它使通过使用{locale}支持多语言来进行本地化成为可能。支持多语言的钱包或者软件现在可以显示通证名字、图像或者其它数据的替代版本。

可确保的日志追踪

随着以太坊生态系统的持续增长，许多dapp依赖传统的数据库和浏览器API服务来获取和分类数据。ERC-1155标准确保通过智能合约触发的事件日志能提供足够的信息来创建一个所有当前通证余额的精确记录。一个数据库或者浏览器可以监听事件从而对合约内每一个ERC-1155通证提供可索引和可分类的的查询。

智能合约不用再保存每个通证ID的索引，这些ID不需要以任何方式序列化。

这对列举（浏览链上所有通证的能力）是一种彻底的分离，但是它带来了效率上的巨大提升，甚至允许对每个通证增发、燃烧和交易等行为进行一个完整的标准化记录。这个标准化方法直到今天才实现，并且它可以通过对通证和大量的持有者进行深度数据分析从而使一些生态系统受益。

设想一下可以在完全不同的ERC-1155通证的时间、使用解析模式和生命周期内快速前进或者后退，而不用管到底是哪个智能合约被解析。

通证拥有者可以获得关于他们的资产的更多信息，比如它们的通证被增发的精确时刻。并且在将来，更多的工具会被开发出来，它们能对建立这种技巧的公司提供更有用的参考。

尾声

ERC-1155标准是区块链社区一年辛勤工作的结果。如果你打算实现ERC-1155标准，你可以先浏览整个标准，而隐藏在每个决定之后的根本原因在这里可以找到。

你也可以浏览最初的讨论过程用来查看整个讨论历史

为了创建一个你自己的ERC-1155通证合约，Enjin的官方实现参考在github上已经开源。

你可以使用这个代码作为你自己智能合约的起点。你也可以考虑使用Enjin平台，它为开者者或者非开发者提供了大量的区块链开发工具。

评价

这是一次重要的核心技术的探索！

但很可惜，由于整个项目的实践和思考都远远不够，在当时人们是无法评判ERC-20是否完美、ERC-721有否问题的。即使ERC-20和ERC-721的成功率各算50%，ERC-1155本身的改进的成功几率算50%，那么这个通证标准的成功率也就只有12.5%。

课外阅读与思考

课外阅读

思考题

ERC-1155有无缺陷？如有，应如何改进？

什么是通证？

通证（token）是个神奇的名词，它是区块链的硬核之一！

首先强调一下，通证不是货币。它的应用范围远远大于货币。

通证（token）并非从比特币一创世就被使用到的专业术语，它是随着区块链多年探索，经由电子现金（electronic cash）、数字货币（digital currency）、加密货币（crytocurrency）等过渡而最终确定的。这也就是说，整个业界也是用了多年时间，才明白中本聪创造出来的，到底是个什么东西！

非常神奇的是，token早在公元1000年左右的古英格兰的盎格鲁撒克逊语（Anglo-Saxon）里就出现了（tacen）！

在盎格鲁撒克逊语里的通证是个概念和功用范畴都很大的单词：它可以是代币、代金券、赠券、令牌、奖牌或者标识物、纪念物等等——中国虽早于公元九世纪就发行了人类历史上第一种纸币“交子”，但可惜我们并未对它进行深加工。这也是大多数国人在2020年来临之际还没搞明白它的主要原因。token在一千多年的时间里没有完全同义的中文字词，直到2017年11月才由CSDN副总孟岩翻译为“通证”。

总的来说，通证（token）的原意是以一样东西代表或者象征另一样东西，后者可以是物质的也可以是精神的，可以是实实在在的也可以是虚拟的。通证（token）现在已经广泛应用到我们生活的方方面面：

1. 金属或塑料游戏币是token（也被写作token coin，或trade token）——我们在游戏厅或者赌场代替人民币使用的，用合金或者塑料制作的圆形物，就是最典型的通证。在这种场合中，代替钱使用的它，常常被称为“代币”。这是通证最常见的应用。而正是因为早期很多通证都只让大家强烈关注到了它的货币属性，因此这种类型的token被翻译成代币并沿用至今。

2. 奖券、礼券、优惠券、债券、订婚彩礼都是token——和上面差不多，好理解。特别要说明的是，一般我们并不将股票视为一种token。因为奖券是靠谱的，可以替代钱来使用，但股票投资常常会血本无归，甚至可能一夜就归零（请注意与之对应的决策权也就同时归零），所以两者不是一回事。对于通过一两千年的实践得到的通证概念，即使我们一时不知道为什么它排除了股票（stock），我们首先应该保持敬畏之心，从而谨慎对待这一问题：股票是与决策权息息相关的，通证排除了股票，也就意味着带货币属性的通证不应直接绑定决策权！

3. 奖牌、勋章、纪念章和荣誉证书也是token——奥运会用金银铜奖牌代表冠亚季军的成绩，也代表了全世界人民对他们的敬意。我们经常说荣誉是金钱买不到的，所以弥足珍贵，称它们为token也很好理解。

4. 安全令牌、通行证、指纹、密码也是token——古代令牌代表皇帝或者将军的授权，带上它无上荣光，荣誉感超强，称之为token顺理成章。金庸小说《鹿鼎记》中的洪夫人赐予韦小宝五龙令，见此令牌犹如见教主，不光五龙使见了要跪，太后的职位比五龙使低，自然更得跪。韦小宝因此春风得意，就是这个道理。令牌这个名称古典小说里用得多，现在基本只有技术领域用到，大家可能稍感陌生，但其实它已经走入千家万户。譬如智能医疗保险卡，因为里面有您的个人识别信息，可以在就医的时候，直接访问社保的中心服务器来调取您的医疗保险数据，因此它本身就是一个安全令牌。开具支票使用的密码生成器也是一个安全令牌生成器。再比如对于保障某区域安全的智能门锁，您的指纹、虹膜和密码都是可靠的安全令牌。

5. 法庭出示的物证，也是token——铁证如山，我们尊重物证，让人们对其保持敬畏之心，所以也叫token。线索很清晰吧！

如果我们谈到比特币这条公链，因为PoW机制确定了记账时，矿工要以比特币收取手续费，系统也会拿比特币支付矿工的工作奖励，加之比特币无论怎么说，都离不开它那条链，跟游戏币离不开那个商家一样，那么比特币本身，被视为比特币这条公链的代币也就是最自然不过的了——但在专业上，我们只能说比特币是比特币公链发行的具有流通属性（或者说货币属性）的通证（token）。

所以我们通常从货币的角度所谈的比特币其实就是一种以货币属性为主的通证，比特币决非货币！区块链里面也不存在货币，它里面的“币”全都是通证（token）。并且，不是所有的通证都具有货币属性！譬如我们在DAO的领域实践的声望（Reputation），它是一种独特的通证，因为无法转账，完全不具备货币属性！

沃尔玛之类的洋超市很早就在中国推出免费存包柜，让去超市购物的人投入一块钱硬币就可以开锁，并告诉他此柜的临时密码。购物离开时，他凭该密码开锁取回临时寄存的物品。锁开则还回硬币，让其他人可以接着使用该柜。这个机制的专业名称叫token ring network，可以让大家免费、方便、安全并合理利用储物柜。它在局域网协议中也有很重要的应用。而这里的token起到的是令牌的作用。但在国内，可惜很多人只注重方便而忽视效率、安全和规范化管理，时有“既然免费为什么还要一块钱硬币”、“没带硬币还要跑很远去柜台兑换”之怨言，所以在中国商业界没有得到广泛应用。

作为令牌，沃尔玛并不收您那一块钱硬币。其目的是提供免费服务和减少纠纷。因为沃尔玛不便也无权窥探某个人在存包柜里放了哪些东西，所以没有收服务费的沃尔玛并不承担失窃的赔偿责任。另外很重要的一点是：沃尔玛的存包柜没有上网，属于离线系统，顶多方圆几公里内的极个别变态狂会去捣乱，因此入侵捣乱的风险非常小。在区块链里，通常要作为服务费收取这一块钱代币（或者少收一点）。这样做有很多好处，其中最重要的原因就是区块链在几十亿人都能随时访问的互联网上，必须要有非常可靠的防范入侵捣乱的手段！

非常简单的逻辑是：因为完全免费，熊孩子可以拿一把硬币把沃尔玛的存包柜全占了。而收费则会导致他想搞的破坏越大他自己的成本越高——如果总共有五百个存包柜熊孩子可能就不舍得玩了。因此转账收费机制可以简单有效防范存包柜被无聊或者居心叵测的家伙滥用。比特币公链通过其兼具代币和令牌作用的通证“比特币”建立起来的收取转账手续费并奖励记账矿工的双重机制，对整个系统就能起到非常有效的安全保护作用，能做到大家无需担心自己遭遇资产损失的技术风险，这样大家才能放心使用！因此，公链里的通证，是能够对它的这个公链起到安全保护作用的！这也就是说，无论是BTC还是ETH，它们同时还具有安保属性。

比特币公链通过其通证BTC，还建立了基于加密经济激励机制的通证治理规则，该规则确定在哪些情况下比特币交易被验证并创建新块。再深入一点，我们会发现，像比特币或以太坊这样最先进的公共和去许可的公链的原生代币，本质上是其激励计划的一部分，它鼓励不相识的或没有信任基础的不同群体围绕特定公链的目的而能够协作起来。这是其价值体现，区块链通证都应该具有这样的功用：它们是其区块链、DApp或者DAO（去中心化自治组织）价值的量化工具（或者说量化指标）。

亦即是说：某个区块链DApp通证的总市值，可以非常简单直接地反映出这个区块链项目目前的总价值！但当大家去投资通证的时候，都非常关心它们的总市值。原因就在于此。而在中心化世界，你到一个游戏厅玩游戏，它的每个游戏币是兑换1元钱还是2元钱还是10元钱，与这个游戏厅的总资产没有任何关系。而游戏厅代币和区块链代币完全不同的根本原因是：游戏厅里的代币，只有很少一点在用户手里，总共有多少代币，与用户没有关系。已经发行出来的以太坊公链的代币，全部在用户手里，那么区块链所发行出的代币，就全部都是用户投资的结果！很好理解的是：全球用户对比特币的投资最高，所以目前比特币举世瞩目！

通证具有价值属性，其市值可以作为直观的价值评判的量化指标。投资通证就是价值传输和价值接力的一种方式。

作为投资者来说，最关心的当然是投资回报，以及确权功能。后者简单说，就是您投资了某个项目，没人能抵赖说没收到您的投资。前面我们说过，比特币和以太坊的所有交易都是公开透明并且可跟踪的，而且以太坊的智能合约还是永久被记录到链上的，这样投资者的权益包括未来的收益，都有了明确的保障。确权就没问题了。所以，通证还有确权属性。

没错，区块链里的通证，常常同时涵盖了以上多种属性（功用），亦即一种甚至一个通证都能集代币、奖券、荣誉奖牌、令牌（安全保护、通行证、确权工具）中的多种属性于一身！

换个角度，我们也许也可以说，通证借助互联网技术，大大拓展了货币的内核和功用。“Money talks”，似乎真是亘古不变的至理名言！

特别值得指出的是：区块链的通证（token）使得“分布式Internet部落”得以出现。与传统的以高层管理方式（官僚协作）运营传统公司和组织机构完全不同，区块链抛弃了人类社会使用了数千年的这种自上而下的主流治理结构，而是以去中心化的自治智能体（DAO）的治理结构取而代之。DAO不是通过合法的实体和传统的合同（譬如劳动合同），而是通过智能合约建立起来的通证的激励和完全透明的链上的规则，将人们结合在一起。

另外，虽然本质上都是通证，我们仍习惯性地把每个公链的原生通证叫做币（coin），而基于智能合约发行的次生通证往往被称为代币（英文则仍为token）。公链的原生通证是基于协议而不是基于智能合约而产生，而且它们的主要功用为代币、安全保障和激励机制。基于智能合约而产生的次生代币则可能还有更加丰富多彩的功用。

通证本质上是通过共识规则、智能合约、应用场景等建立起来的具有典型货币属性或者资产属性的规则集合，它能为公有链及其DApp带来专属货币、权益保障、激励机制、资产所有权记录、安全保障、决策机制、自治组织和自治的经济生态等等。

通证的定义

综上所述，通证，就是通过区块链技术创建的集货币属性、价值属性、荣誉属性、安保属性、确权属性等等多种属性于一体的区块链资产。通证可以为智能合约所管理，也可以为握有钱包私钥的人所拥有和使用。通证是区块链的硬核之一。目前区块链里面已经出现同质通证（FT）、非同质通证（NFT）、半非同质通证（sNFT）三大类通证。

市场里的加密货币（Cryptocurrency）属于同质通证，也就是说加密货币只是通证的一种。

最后，我们需要牢记的是：通证不是货币，它给这个世界带来的远远不只是代币，更重要的是共识机制，以及荣誉、权益证明、系统的效率、安全、资产量化指标和规范化监督管理等等——换言之：没有通证，以上这些东西均会灰飞烟灭，对应的区块链项目纵然名称再漂亮，宣传再给力，那也只能是海市蜃楼、镜花水月、无米之炊！

花编：

token在程序中的应用非常基础也非常普遍——在编程语言里，token有多种代表不同功能的可辨识的最小独特单位，都是从令牌衍生而来。譬如C++语言中有五种令牌：标点符（Punctuators）、运算符（Operators）、关键词（Keywords）、变量（Variables/Identifiers）、常量（Constants/Literals）。另外程序中广泛应用的还有访问令牌（Access token）、安全令牌（Security token）、效期令牌（Session token，建议都接受我这个翻译）、邀请码（Invitation token）以及前面刚介绍过的token ring。

但请IT男注意：在编程语言里，我们将token翻译为令牌，而从来没有将它翻译为通证。这就是说，token在编程语言里只应用了它的部分属性！当我们说到通证，指的就必然是区块链里的token而非编程语言里的令牌！

你知道吗：有了token，一台设备就可以通过Access token机制访问网络里的另一台设备，甚至在允许的情况下，调取后者的数据！Google二次验证就采用了这一原理！这还可以理解为一个区块链DApp里面授权产生的token，日后可以在另一个DApp里用作通行证或其它。好神奇呀对不对？！想象空间很大的对不对？

通证的多样性

随着以太坊智能合约技术的发展，通证的类型和功用得以开始分化。譬如以太坊通过ERC-20这个智能合约标准，可以让任何人发行出自己项目或者组织的同质通证；通过ERC-721这个智能合约标准，可以让区块链游戏将每个道具转变为一个非同质通证，并能够通过智能合约实现其个性化市场价值。

区块链通证已经呈现出百花争艳的应用局面。

同质性物品和非同质性物品

同质物品的定义

（尤其是商品）具有某种特质或属于某个种类，使之可以全部或部分自由地与另一个具有相同特质或种类的物品进行交易和置换。

如果一个物品被认为是同质性的，那么这个物品类别下的每个个体之间没有差别。也就是每两个同质性物品的价值在所有人眼中完全相同，它们互相之间可以交换。

比如说人民币1元硬币，每枚1元硬币都可以与另一枚1元硬币互换。所以人民币1元硬币是可互换的，它就属于同质性物品。

非同质物品的定义

因此，非同质物品（不可替代物品）具有与同质物品定义相反的特征。 这些特征是：

• Unique（独特）

• Irreplaceable（不可替代）

• Non-interchangeable（不可互换）

最常见的应用案例：

同质物品：法币、比特币、便利贴、几页同品牌打印纸…… 非同质物品：艺术作品、人、游戏角色、房产、地产……

故宫博物馆的每件藏品，则都属于非同质性物品，哪怕两件藏品都是仕女图，保存完好度，制作年份，风格特色，甚至曾经的收藏者的身份，等等，对它们的价值都有影响。

同质性的物品可能通过区块链技术变成非同质性物品。譬如游戏道具，或游戏卡牌。

Technically speaking each Bitcoin is definitely unique. This is why it is possible to trace the origin of a Bitcoin, and whether or not it participated in transactions in the “darknet”.

It is therefore the use value that defines the fungible or non-fungible character of the asset. And not its technical characteristics. The main use of an asset and the perception that one can have of it define fundamentally if the asset is fungible or not.

同质通证和非同质通证

同质性物品和非同质性物品，到了区块链领域，就对应衍生出同质通证和非同质通证，同质资产和非同质资产。ERC-20定义的，就是一个同质通证标准。ERC721定义的，就是一个非同质通证标准。

通证的应用

具体而言，区块链的通证（token）可以用于：

• 代币——ERC-20类型的通证基本属于这种类型。可用于众筹、债券发行、商品与服务的买卖，其总市值代表一个项目的总资产和总价值。

• 金融工具与金融衍生品

• 所有权令牌——ERC-721代币属于这种类型

• 激励工具——如比特币

• 安全保障手段——如比特币、ETH等

• 投票权——如EOS

• 股权证书

• 门票或通行证（派对，音乐会，游乐园等）

• 使用WiFi热点，租赁房屋、交通工具或储物柜，访问在线存储；可定制的成员资格或订阅；奖励计划；软件许可证

• 自治组织的治理工具

以太坊正在探索中的通证标准：

1. 关于 UTXO 的思考（Vitalik Buterin）：https://ethfans.org/posts/thoughts-on-utxo

2. 比特币和以太坊技术原理对比之账户模型：https://www.jianshu.com/p/14bd783d2ced

3. 狗狗币基本上无限接近于一种货币，光靠金钱可以做好慈善吗？如果不能，那么你认为应该怎么设计？

2013年11月的某天，Vitalik Buterin 发布了他写的《Ethereum White Paper : A NEXT GENERATION SMART CONTRACT & DECENTRALIZED APPLICATION PLATFORM》。

白皮书的第一行赫然宣告了其核心目标：

以太坊：下一代智能合约和去中心化应用平台

Vitalik Buterin也因此成为失踪两年的中本聪的接班人。

“My goal in creating Ethereum was to create a platform that was open, decentralized, transparent, easy to use and free for anyone to participate and build things. I think that this kind of platform can be good for humanity.” ——Vitalik Buterin

"我创建以太坊的目标是创建一个开放、去中心化、透明、易用和任何人都可以自由参与和构建东西的平台。我认为这种平台对人类有益。"

以下摘自《Mastering Ethereum》：

From a computer science perspective, Ethereum is a deterministic but practically unbounded state machine, consisting of a globally accessible singleton state and a virtual machine that applies changes to that state.

From a more practical perspective, Ethereum is an open source, globally decentralized computing infrastructure that executes programs called smart contracts. It uses a blockchain to synchronize and store the system’s state changes, along with a cryptocurrency called ether to meter and constrain execution resource costs.

The Ethereum platform enables developers to build powerful decentralized applications with built-in economic functions. While providing high availability, auditability, transparency, and neutrality, it also reduces or eliminates censorship and reduces certain counterparty risks.

"从计算机科学的角度来看，以太坊是一个确定性但实际上无限制的状态机，由全局可访问的单一状态和能够改变其状态的虚拟机组成。 从更实际的角度来看，以太坊是一个开源的，全球分散的计算基础设施，执行称为智能合约的程序。 它使用区块链来同步和存储系统的状态变化，以及称为ether（货币符号为ETH）的加密货币来计量和约束执行资源所需的成本。 以太坊平台使开发人员能够构建具有内置经济功能的强大的去中心化应用程序。在提供高可用性，可审计性，透明度和中立性的同时，它还减少或消除了审查并降低了某些交易对手的风险。"

和比特币类似，以太坊是一个去中心化公链，由很多台电脑组网协作而成，接入这个网络的每个节点（电脑）本地都会保存一份完整区块链（可理解为一个本地数据库）。

每个节点电脑都需要安装以太坊客户端，而这个以太坊客户端自带了EVM（虚拟机），它是一个以太坊智能合约的执行环境，类似JVM。通过交易触发智能合约后，智能合约的代码就会在EVM中执行了。这种方式相当于把程序部署到了非常非常多的电脑上（只要这个电脑安装了以太坊客户端并接入了以太坊网络），随时都可以通过交易来触发这些智能合约的执行，也从而完成了分布式程序的部署和调用。所以以太坊是一台去中心化的“超级计算机”或者叫“世界计算机”。

因此，以太坊（Ethereum）是一个开源的有智能合约功能的、可以承载众多去中心化应用（decentralized applications,dapp）的公共区块链平台。通过其专用通证（加密货币）以太币（Ether，ETH）提供去中心化的虚拟机（Ethereum Virtual Machine）来处理点对点合约。

以太坊的概念首次在2013至2014年间由程序员Vitalik Buterin受比特币启发后提出，在2014年通过ICO众筹得以开始发展。

以太坊最重要的技术贡献就是构建了一整套智能合约的基础逻辑、协议和标准，并且还在不断拓展中。以太坊的智能合约可用数种用图灵完备的编程语言编写。

我们也可以理解为，以太坊让区块链应用的运营变得简单且可靠：开发者只要完成程序（智能合约）开发，随后把它部署到以太坊上，工作即告结束。自己不需要维护域名、服务器以及服务器里的各种软件，也不需要为抵御黑客的网络攻击而疲于奔命。以太坊确保你的智能合约处于永久可被使用的状态。

以太坊同时仍然保留了比特币带来的金融创新。至于币的蜕变，还需要我发起的项目“道易程”来完成！

由以太坊另两个创始人合著的《以太坊黄皮书》也很有意思，如：

以太坊有很多的目标，其中最重要的目标是为了促成那些本来无法信任对方的个体之间的交易。这种不信任可能是因为地理上的分隔（远距离）、接口对接难度、或者是不兼容、不称职、不情愿、不便宜、不确定、不方便或者现有法律系统的腐败。于是我们想用一个丰富且清晰的语言去实现一个状态变化的系统，期望协议可以自动被执行，我们可以为此提供一种实现方式。

这里所提议的系统中的交易，有一些在现实世界中并不常见的属性。公允的裁判通常很难找到，但无私的算法解释器却可以天然地提供这种特性。自然语言必然是模糊的，会导致信息的缺失，同时那些平白的、旧有的成见很难被动摇，所以透明性，或者说通过交易日志和规则或代码指令来清晰地查看状态变化或者裁判结果的能力，在基于人来构建的系统中从来无法完美实现。

总的来说，我希望能提供一个系统，来给用户提供一些保证：无论是与其他个体、系统还是组织进行交互，他们都能完全信任可能的结果以及产生结果的过程。

完整英文版：

完整中文版：

以太坊可用来创建无数的区块链应用，即智能合约、去中心化的程序（dapp）和自治组织，早期的应用尝试有：

• 去中心化交易市场: Bancor（班科） 和 Uniswap，其中 Bancor 的去中心化定价机制，是区块链发展的一个里程碑！

• 游戏：CryptoKitties让玩家繁殖及交易虚拟猫，VR游戏Decentraland。

• 虚拟宝物交易平台：OpenSea、Rart Bits、KnownOrigin、Emoon。

• 去中心化创业投资：The DAO（已挂）目标是去中心化投资，去中心化组织构建平台Wings。

• 社会经济平台：Backfeed。

• 去中心化预测市场：Augur。

• 物联网：Ethcore研发的以太坊客户端Parity、Chronicled（一间区块链公司）发表了以太坊区块链的实物资产验证平台；芯片公司、物理IP创建者和生产者可以用植入的蓝牙或近场通信进行验证。Slock.it（Rent, sell or share anything）的付费充电、或是Airbnb智能租赁。

• 版权授权：Ujo Music平台让创作人用智能合约发布音乐，消费者可以直接付费给创作人。伊莫珍·希普用此平台发布了一首单曲。

• 智能电网：TransActive Grid让用户可以和邻居买卖能源。

• 去中心化期权市场：Etheropt。

• 锚定汇率的代币：DigixDAO提供与黄金挂钩的代币，在2016年4月正式营运。Decentralized Capital提供和各种货币挂钩的代币。

• 移动支付：Everex让外劳汇款回家乡。

这个名单未来几乎可以无限增加！

狗狗币（Dogecoin）

创新：

通过引入全球狗文化中具有共识性的精髓，立志成为构建有趣和友好的社区关系的加密货币。

应用场景：

慈善——指欧美慈善Charity，其概念要大于国内的慈善，除了扶弱济贫之外，任何发自内心的爱和分享的行为都是慈善。譬如无偿资助一位少年参加电竞大赛就是慈善。

打赏——从打赏文章编辑或分享优秀内容、优秀软件作品等的人开始，通过表达感激、欣赏、友好和激励之心，给这个世界带来积极的影响。

达世币（Dash）

创新：

匿名——达世币以混币机制增强了匿名性，使得追踪交易变得更加困难。顺便提一下：比特币“官网”更改了以前的说法，说比特币并非匿名，这在本质上是错误的。

即时——达世币有一种闪电交易模式，称为即时支付（InstantX），可以在几秒钟内（通常只需要1秒）完成交易。相比比特币长达1小时的交易完成时间，达世币的到账速度非常快。

决策引擎（decision-making engine）——达世币的去中心化区块链管理系统允许任何人提出更改或升级达世币的提案。无论是技术、市场营销或者其他方面的建议，都可以直接通过区块链提交到网络上。被选中的提议将给予新区块10%的报酬。社区每月对提议进行投票表决（结点的持有者才具有投票权）。赞成票比反对票至少多出10%则合格，提议之间还要竞争。

自给自足的预算系统——达世币的预算系统（budget system，或者self-funding）让任何人都可以自己提供预算，发起一项有关达世币开发和宣传的提案。预算系统和决策引擎，让达世币成为一个独立自主的去中心化自治的币种。Dash本身很可能就是区块链业界的第一个去中心化自治组织（Decentralized Autonomous Organizatio，DAO）。

应用场景：

希望在匿名投资领域有所建树，致力于构建去中心化可持续匿名融资模式。

其他：

达世币（Dash）原名暗黑币（Darkcoin），由于具备匿名特性，被传销组织予以利用。最严重的是“刘雄暗黑币传销案”。2014年8月，该传销组织重金聘请人员制作了“暗黑币”官网，创建虚假的网上交易平台，开始了网站的运营。为了支撑虚假的“暗黑币”投资，该传销组织的核心人物在中国香港成立了达康智能科技有限公司。以此为基地，通过带人到这个公司总部去考察学习（每天下午都会有顾问负责讲课，传授概念，以及推广市场的技巧）。仅8个月时间就在中国内地发展会员3万余名（以累计注册账号计算），敛财近15亿元。虽然这个传销组织建立的山寨“暗黑币”网站与真正的“暗黑币”没有任何关联，它只是借助“暗黑币”的名声及价值大肆进行宣传，以达到混淆视听的目的。但仍有很多人搞不清真实情况甚至怀疑暗黑币参与其中。因此暗黑币不得不彻底改头换面。英文名、中文名、货币符号、Logo及官网域名等全部被换掉。但因为案件审理时间很长，替换后案件仍在新闻热炒中。一些不明事理的人将“刘雄暗黑币传销案”改称为“刘雄达世币传销案”，还是给达世币蒙上了一层阴影。这个故事告诉人们，数字货币技术上的复杂性使得大众在短期内无法消化，因此前期的迷茫、混乱和危险就在所难免。另外，国内这几年传销组织之多、之活跃、之长寿，以及传销个案敛财数额之惊人，既提醒了人们要谨慎甄别，也说明了国内环境的糟糕及执法效率问题不小。

达世币是众多竞争币中首个进入比特币ATM机市场的加密数字货币。

点点币（Peercoin）2012年8月19日正式发布。点点币的名称取自P2P货币的意思，即点对点货币，因此被翻译为点点币。点点币的研发团队和质数币XPM的研发团队为同一团队，技术实力强劲。

创新：

世界上第一个权益证明类加密电子货币——最大的贡献在于它原创了POS利息体系（其采矿方式混合了POW工作量证明，并首创了股权证明即POS这一新机制），可以有效防止通货紧缩。如持有点点币30天后，可以赚取年化利率为1%的利率。

节能：可在任何设备上进行点点币的挖矿。

合约币（CounterParty）是建立在比特币协议上的创新传输层，用于实现去中心化的货币发行、资产管理、交易、下注和分红等财务功能。合约币初期通过烧毁比特币（Proof of Burn）的方式产生和分发。

创新：

曾尝试移植以太坊编程语言，为比特币生态引入智能合约。

应用场景：

在合约币基础上开发的应用（Dapp）有Storj、Swarm、FoldingCoin、GetGems、Scotcoin和Spells of Genesis等等。

创新：

第一个100%权益证明（POS）货币。

去中心化资产交易所（AE：Decentralized Asset Exchange）——未来币借用了“彩色币”的概念，使得未来币（NXT）的网络可用于交易几乎任何东西。并且是去中心化交易，即不必依赖中心化的交易平台。Nxt是首批允许用户创造自有区块链代币，并在区块链上进行交易的平台之一。曾有数十项众筹活动在NXT平台上成功完成。2016年前，基于NXT区块链发行的资产数目高达600多个（如集交易所、孵化器、软件和广告于一体的SuperNET）。

货币制度（monetary system）——允许任何人用NXT抵押发行自己的货币，包括POW币。

云数据（Data Cloud）——可以发送任何形式的信息。将来还可以发送加密信息。可用来建立文件共享服务、分布式应用程序和更高级别的NXT服务。

投票系统（Voting System）——顽固抵抗数字货币的俄罗斯唯一的中央证券托管系统（CSD）国家清算托管局（NSD），曾经宣布开始测试基于未来币区块链的投票系统。

账户控制（Account Control）——已完成账户租赁（Account Leasing）功能，允许用户在一个固定的时间段把锻造力出租给另一个账户，而不需要把币发送到任何地方。这允许创建安全的锻造矿池。

混币（Coin Shuffle）——一个去中心化的隐私功能，它可以让用户快速、高效地与其他用户的资金进行混合，在现有的用户账户和混币后的新账户之间创建随机的映射关系，从而实现完全匿名。

应用场景：

去中心化资产交易。

企业或其他组织发行自己的数字资产。

云数据存储。

去中心化市场。

自动交易。

其他：

未来币完全使用脑钱包，难以在安全性和易用性上取得平衡。

创新：

瑞波币是是Ripple网络的基础货币。其目标是设计出世界上第一个开放的支付网络，通过Ripple内部网络可转账任意一种货币，包括美元、人民币或者比特币等，交易确认几秒内完成，交易费用几乎是零，没有所谓的跨行异地及跨国支付费用。

瑞波币（XRP）貌似乃全球法定货币的桥梁，期望实现多币种支付、结算、结汇和国际转账即时到账，真正实现全球货币的快捷流通。

瑞波专注于银行合作——瑞波曾跟全球25家企业进行了合作，其中有10家是全球排名前50的银行，已公开的合作伙伴包括Fidor银行、CBW银行、跨河银行、Earthport、CGI、IntellectEU和埃森哲。

应用：

Ripple由谷歌投资10亿美元，福特汽车投资2亿美元，洛克菲勒，全球最富有的罗斯柴尔德家族均已投入（罗斯家族的资产相当于2200个马云、800个比尔盖茨），中国的华创资本、包括给马云投资的孙正义的软银公司，全球顶级的20多家风险投资公司全部参与了Ripple。但瑞波币的绝大多数为Ripple labs所持有，其发币的体制长期为人所诟病。

当瑞波成立的时候，它创造了 1000 亿个XRP，其中800亿分配给了公司，200亿给了三位创始人。下面是这些XRP大致分布情况：

• 瑞波公司获得了800亿XRP。

• 拉森获得了95亿XRP。

  • 2014 年，拉森承诺将 90 亿中的 70 亿 XRP 投入慈善基金会。

• 麦卡勒布获得了95亿XRP。离开瑞波后：

  • 麦卡勒布保留了 60 亿（可能锁定协议）。

  • 麦卡勒布的孩子收到了 20 亿（有锁定协议）。

  • 慈善机构和麦卡勒布的其他家庭成员共得到 15 亿（不受锁定协议的约束）。

• 亚瑟·布里托（Arthur Britto）收到 10 亿（有锁定协议）。

当麦卡勒布离开瑞波时，人们担心他会否把他持有的 XRP 砸入市场，使其价格崩盘。 麦卡勒布和瑞波达成了限制销售 XRP 的协议，来防止上述情况发生。瑞波指责麦卡勒布违反了最初约定的条款后，在2016年又重修订了该协议。

(资料来源: http://archive.is/cuEoz)

2018年1月，为了调查，BitMEX 研究团队安装并运行了一份 Rippled 。他们通过从服务器 v1.ripple.com 下载了五个公钥列表来操作节点，结果发现所有五个密钥都被分配给 Ripple.com 。该软件指出，需要五个密钥中的四个来支持提案才能被接受。由于密钥都是从 Ripple.com 服务器上下载的，因此瑞波基本上完全控制了账本记录，Ripple是一个中央控制（集中式）系统！

从2012年进入区块链行业，2013 年 1 月，他们山寨比特币技术推出了瑞波币（XRP），到现在已经6年半过去了，它还没有真正正式投入使用！

我们有理由担心它最终成为一个巨大的敛财故事。

直接使用去中心化的区块链技术，来改进中心化组织的产品或服务或平台，往往会面临这个问题：“以子之矛陷子之盾，何如？”

崛起币EMC是一个于2013年12月发布的老币，总量10亿。这个币种是一个非常低调的技术流派数字货币。曾获得微软Azure支持。

创新：

去中心化域名和DNS系统（EMCDNS & NVS）。

分布式无密码认证登录解决方案（EMCSSL）。

Shell管理的去中心化解决方案（EMCSSH）。

去中心化点击付费广告系统（EMCLNX）。

存储于区块链的所有权证明（EMCDPO）。

存储于区块链的可信任时间戳服务（EMCTTS）。

分布式网络种子文件追踪器（Magnet）。

交易优化器——能有效解决比特币头疼的“金砂”和“灰尘”交易，进一步减少区块链大小并进行“清洁”。

竞争币的使命与历史意义

就像生物必须是从遗传物质的出现，到单细胞，到多细胞等等而逐步演化，区块链的发展也不例外。从2011年～2014年，人们在这个领域的全部知识视野就只有比特币，那么大家能做的改进只有那一批“山寨币”，就是情理之中的事了。

竞争币在共识算法、货币应用等等方面做了大量的探索和改进，同时也把很多最新的科技知识也引入到区块链领域，对于后来大家深入比特币“链”的底层逻辑和底层结构，起到了很好的承上启下的作用。

在货币应用方面的竞争题材穷尽之后，大家开始将竞争延伸到了货币之外的领域，由此开启了另一个新时代，也就是业界经常会提到的“区块链2.0：智能合约”。

总的来说，竞争币的工作进一步验证了比特币的伟大意义，它们的工作也让比特币的局限逐渐浮出水面，而让区块链朝向一个新的更加光明也更加璀璨的未来迈进！

以上这些既是竞争币的使命，也是其历史意义。

把数字加密货币或者比特币完全看成泡沫的人要么是心胸狭隘信口胡诌，要么是完全不擅于学习。因为即使是不光夺去了无数人的生命，还严重挫伤了人类的心灵的血腥的战争，本质上就是各个文明、种族、国家为了抢占发展机会而发生的竞争，尽管我们今天可以说，暴力其实是无能的表现，但在人类文明发展的相当长的特定历史时期里，战争也仍然属于自然竞争的范畴。

参考资料

1. 《如何投资数字货币》，王博、周朝晖主编，电子工业出版社，2017年1月第一版

2. 瑞波（Ripple）的故事：https://blog.bitmex.com/zh_cn-the-ripple-story/

3. STARKs, Part I: 多项式证明：https://www.unitimes.io/knowledge/2587/?lang=zh

4. STARKs, Part II: 核心证明终问世：https://www.unitimes.io/knowledge/2566/?lang=zh

5. STARKs III：攻坚（上）：https://www.unitimes.io/knowledge/11722/?lang=zh

6. STARKSIII：攻坚（下）：https://www.unitimes.io/knowledge/11733/?lang=zh

智能合约是一种运行在以太坊链上的程序。 它是位于以太坊区块链上一个特定地址的一系列代码（函数）和数据（状态）。智能合约也是一个，我们称之为合约账户。 这意味着它们有余额，它们可以通过网络进行交易。 但是，它们无法被人操控，它们是被部署在去中心化网络节点上作为程序运行着。 个人用户可以通过提交交易执行智能合约的某一个函数来与智能合约进行交互。 智能合约能像常规合同一样定义规则，并通过代码自动强制执行。

智能合约的特色

无需准入性（无需许可）

任何人都可以编写智能合约并将其部署到区块链网络上。 你只需要学习如何用，并有足够的 ETH 来部署你的合约。 在技术上，部署智能合约是一项交易，所以你需要支付你的，就像你需要为简单的以太坊转账支付 gas 一样。 然而，部署合约所需要消耗的 gas 费要高得多。

以太坊编写智能合约的语言，对开发者比较友好：

• Solidity

• Vyper

然而，它们必须要先编译才能部署，以便以太坊虚拟机可以解释并储存合约。

自由组合性

智能合约在以太坊上公开，并被认为是开放应用程序接口。 这意味着你可以在你自己的智能合约中调用其他智能合约以极大地扩展可能性。 合约甚至可以部署其他合约。

了解更多关于的内容。

“局限性”（隔离脏数据）

智能合约本身无法获取关于”真实世界“的事件信息，因为它们无法发送 HTTP 请求。 这样设计是因为依赖于外部信息可能会危及共识，这对安全性和去中心化而言十分重要。

这可以通过 来规避。

从应用层面简单地说：智能合约（Smart Contract）是用程序代码定义合约参与方的承诺，并能够完全抗干预地根据承诺自动执行包括转账通证在内的约定条款的协议。

智能合约允许在不同的匿名方之间进行可信交易和协议，而无需中央机构，法律系统或外部强制执行的机制。它们使得交易、状态和数据可追溯，透明且不可逆转。

智能合约的部署过程，可理解为发送一个包括可执行代码的特殊交易，将合约代码存储在区块链中（是在合约账户的accountstate中的codehash指向的一块存储区域中），交易只记录合约代码的哈希值（作为存证），当需要调用这个智能合约的方法时只需要向这个智能合约的地址发送一笔交易即可。

如果您懂一点点编程语言，或者您有丰富的微信使用经验，那智能合约是非常好理解的。

智能合约可以简单理解为可执行的公开透明的程序，被开发者部署到以太坊区块链上，与外界完全隔离并运行于以太坊虚拟机（Ethereum Virtual Machine，简称EVM）中，这样它就脱离了人为的干预。而完全只按照代码设定的规则运行。

智能合约为所谓的去信任提供了基础架构，它允许我们信任系统的输出，而不需要信任它里面的任何参与者。

我们今天所使用的任何技术，都是很多前人花费了几十几百年的摸索才得以实现的！ 智能合约也不例外。早在1994年，密码学家尼克萨博（Nick Szabo）就提出了智能合约的概念，并于1998年进行了尝试（Bit Gold），但没有成功，其中一个重要的原因是缺乏能够支持可编程合约的科技水平。而我们已经知道，比特币的发行（挖矿奖励）和转账等等，都是由程序根据协议（即合约）直接实施的，比特币为包含转账货币在内的可编程合约带来了巨大的技术突破。

区块链技术的出现不仅解决了该概念里最重要的合约对货币的百分之百的控制权，并且可编程的优势又让它秒杀了一切传统合约——而区块链的去中心化、不可篡改、过程透明可追踪等优点，更是令智能合约如虎添翼，一飞冲天！

智能合约是纯正且原生的区块链技术。它符合我们对于区块链价值观的所有期望。

智能合约还有以下应用特色：

• 和通证的账单一样部署在链上。

• 去中心化——智能合约是严格按照甲乙双方已写入代码的约定，封闭式自动执行的。勿需也不允许第三方的介入（思考：现在的预言机、Amberdata等等是否有问题？）。

• 勿需信用中介——勿需第三方的信用背书，智能合约本身以及区块链即可以提供可靠的保障。

• 抗审查（不可篡改）——通过区块链加密技术，它可以防范人为作弊等干扰，从而具体抗审查的能力。

• 透明可追踪——任何人都可以在链上查阅智能合约代码，从而彻彻底底了解它的所有细节。

• 精准——智能合约是用代码写出来的，它不存在任何语言上的歧义的可能。

• 匿名——智能合约是自主运行的，它不需要有人去启动或终止。也不需要知道你是谁。

请注意：除了区块链，其它任何技术都无法部署智能合约，如此则可以说，智能合约是区块链的独门秘技。

智能合约已经广泛应用到区块链ICO、游戏等领域，而比特币到目前为止在应用领域还只是一个货币，无法承载智能合约千变万化的应用。这样，我们再次看到了比特币极大的局限。而且智能合约在应用中爆发出来的威力，让我们几乎可以肯定：以太坊虽然任重道远，但百步已经走完九十九步，可以说为这个世界带来”智能合约“这一区块链技术的它已经非常接近成功。

课外阅读

ERC-20通证标准

ERC-20（又常被写作ERC20）通证标准是在以太坊平台上通过智能合约制订的通证标准。

我们常常把以ERC-20通证标准发行出来的通证，叫做“代币”。但请注意，Bitcoin是代币，ETH也是代币，但在以太坊生态里首创的ERC-20是一个通证标准而非代币标准。区块链以通证（Token）取代代币（Coin）是一次伟大的飞跃！

ERC20让开发者能够基于智能合约执行以下操作：

1. 制定通证总供应量

2. 获得账户余额

3. 转帐通证

4. 批准转账通证

以下内容翻译自：

1. 概述

   ERC20是通证（token）的一种标准接口。

2. 摘要

   本标准允许在智能合约中部署token的标准API。 该标准提供了转移token的基本功能，并允许token被批准，以便链上其它第三方可以使用它们。

3. 动机

   这一标准接口可以让以太网上的任何token可以被其他应用程序再利用：从钱包到去中心化的交易所。

4. 技术参数

   1）Token

   1.1. 方法

   注意：

   a. 请到原始提案中查询本标准所使用的语法的Solidity的最低版本号。

   b. 调用者必须处理returns（bool success）返回的false。调用者绝对不能假设永远不会返回false。

   name：返回令牌的名字，例如“MyToken”。 可选——这个方法可以用来提高可用性，但接口和其它合约不能依赖该值的存在。

   function name() public view returns (string)

   symbol：返回令牌的符号，例如“HIX”。 可选——这个方法可以用来提高可用性，但接口和其它合约不能依赖该值的存在。

   function symbol() public view returns (string)

   decimals：返回token使用的小数位数，比如 8，表示将记录在链上的token数除以100000000后显示给用户。 可选——这个方法可以用来提高可用性，但接口和其它合约不能依赖该值的存在。

   function decimals() public view returns (uint8)

   totalSupply：返回token的总供应量。

   function totalSupply() public view returns (uint256)

   balanceOf：返回另一个账户地址_owner的账户余额。

   function balanceOf(address _owner) public view returns (uint256 balance)

   transfer：转移_value数量的token到地址_to，并且必须触发Transfer事件。 如果_from帐户余额没有足够的token来支出，该方法应该throw。 注意：_value=0必须被视为正常转账并触发Transfer事件。

   function transfer(address _to, uint256 _value) public returns (bool success)

   transferFrom：从地址_from发送_value个token到地址_to，必须触发Transfer事件。 transferFrom方法用于提现流程，允许合约为你转移token。这可以用于允许合约为你转让代币或收取费用。除非帐户_from有意通过某种机制授权消息的发送者，否则该方法应该throw。

   注意：_value=0必须被视为正常转账并触发Transfer事件。

   function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)

   approve：允许_spender多次从你的帐户提现，最高数量是_value。 如果再次调用此函数，它将以_value覆盖当前的值。

   注意：为了防止向量攻击，客户端需要确认以这样的方式创建用户接口，即在为同一个花费者设置另一个值之前，先将它的值设置为0。虽然合约本身不应该强制执行，以前部署的合同允许向后兼容。

   function approve(address _spender, uint256 _value) public returns (bool success)

   allowance：返回被允许从_owner提取到_spender余额。

   function allowance(address _owner, address _spender) public view returns (uint256 remaining)

   2）event

   Transfer：当token被转移(即使是0值)时必须被触发。

   event Transfer(address indexed _from, address indexed _to, uint256 _value)

   Approval：当成功调用approve(address _spender, uint256 _value)后必须被触发。

   event Approval(address indexed _owner, address indexed _spender, uint256 _value)

5. 实施

   在以太坊网络上已经部署了大量符合ERC20标准的代币（查询：）。从节省gas到提高安全性，不同权衡的团队已经编写了各种不同的合约方案。

   合约实例：

   （）

   ---

6. 历史

   本标准的相关历史链接：

7. 版权

   版权和相关权利通过许可协议放弃。

OpenZeppelin的 ERC-20 智能合约扩展

1. Mintable：允许特定账户（外部账户或合约账户）创建新的通证。

2. Burnable：允许通证持有者销毁一定数量的通证，从而减少总供应量。

3. Pausable：允许合约拥有者在紧急情况下暂停合约的所有交易和功能。

4. Permit：允许用户通过签名授权他人代表自己进行通证转移，而无需在链上执行 approve()。

5. Votes：为通证持有者提供投票功能，可用于事务决策。

6. Flash Minting：闪电造：允许用户临时铸造大量通证，用于闪电贷等金融应用。

7. Snapshots：快照：捕捉特定时间点的通证持有情况，用于分红、投票等应用。

8. Access control：通过角色和权限管理来限制特定功能的访问。

9. Ownable：将合约的所有权赋予某个地址，该地址可以管理合约的某些功能。

10. Roles：为合约中的功能分配不同的角色，每个角色可以拥有特定的权限。

OpenZeppelin的ERC-20扩展库大大丰富了ERC-20的功用，但他们没有直接抛弃ERC-20，构建成新的通证标准，有两个原因：

其一是如果创建新的通证标准，与ERC-20割裂，就会给整个行业带来应用上的负担甚至打击。采用扩展库的优势是它只会推动整个行业的发展。

其二是扩展本身是可升级的。EIP因为升级后果复杂，则无升级机制。这样应用起来更灵活。

ICO爆发：ERC-20通证标准的应用

ICO是Initial Coin Offering的简称，顾名思义，就是项目方以初始产生或者首批公开发行的通证（代币）作为回报的一种众筹资金的方式。

ICO在很大程度上借鉴了证券业的Initial Public Offering（首次公开发行，IPO）。之所以没有沿用IPO而改为ICO，主因是传统的IPO（首次公开募股，initial public offerings）的门槛非常高而且涉及到跨国就更是难上加难。区块链业界删繁就简，采用了新的概念及新的模式，在突破障碍的同时规避了法律风险。

用最简单的话说：ICO就是项目方发行一种自己的通证，投资者用ETH或其它通证来兑换该通证。

有个别通证+收益分红模式（不同于股权模式）的区块链项目的众筹，采用过ITO（Initial Token Offering）这一名称，但因为我们知道只有符合ERC-20的通证才用于众筹，大众又更熟悉Coin，所以现在约定俗成，都采用ICO（Initial Coin Offering）。

典型的ICO流程与特点为：

1. 核心团队通过专业会议等各种渠道发布ICO消息。

2. 核心团队发布ICO规则，包括ICO的时间安排和融资额的安排。譬如最低融资额，如果达不到该额度，该ICO即告失败，所有投资都会被退回。有的项目同时会设定最高投资额（硬顶），达到该投资额，则ICO提前结束。

3. ICO开启后，现在越来越多的项目只接受ETH，因为通过以太坊的智能合约，可以让ICO过程实现零人工、零差错。个别项目还像以前那样接受以太币、比特币等多种数字加密货币。

4. ICO结束后，代币就会开始上交易所。

2015年11月创建、2017年9月11日定稿的ERC20通证标准，2017年4月提前爆发于ICO。这里面有多重原因：

• 真正抗审查

• 真正实现了全球范围的投融资

• 极低的投融资成本

• 极高的投融资效率（超快的转账速度、超快的融资速度）

• 第一次实现了平等的投资权利

• 真实的市场估值

• 最高的流动性溢价

• 零差错、零人工

以下为各种投融资手段的对比：

前面我们提过，以太坊早在2014年就通过ICO筹集了发展基金，为什么是2017年ICO才大爆发？

这里面有区块链知识传递和区块链项目发展的原因，还有一个很重要的原因就在于ETH和ERC20通证标准。2017年前ICO的主要币种为比特币，但比特币到账时间长达1小时，ETH一次确认只需要9秒，到帐通常不足2分钟。而且比特币网络堵塞，有很多转账无法完成；加上比特币2017年没有智能合约可用，通常还需要用户到官网注册，ERC20通证标准的出现，才实现了ICO的质变！

ICO的爆发，归功于ERC20通证标准，也是智能合约的第一个爆点！

ERC-20通证标准带来的问题

1. 人人能自由发币听上去实现了哈耶克在《货币的非国家化》里提出的理想。但人人能自由发币与各国政府印钞有什么本质的区别吗？

2. 人人能自由发币加上中本聪带来的匿名性，造成了区块链欺诈（scam）成行！经过五六年的肆虐，这个行业已经完全无诚信可言！

智能合约和以太坊的价值

我们还没有实现智能合约的所有价值，可以预见的是：

1. 此前的其它任何技术都无法部署智能合约，智能合约是区块链的独门秘技。

2. 自动判断执行，降低人工判断错误或是人为操作改动的风险；如果没有代码错误，智能合约完全可以做到零差错！

3. 降低成本，智能合约在部署和执行时具有显著的低成本优势；譬如在资产批量兑换时，执行阶段可以做到极低成本（只需要支付以太坊gas费用）。

4. 传统合约采用是是事后执行，根据状态决定奖惩的模式；智能合约则属于事前预定执行模式，加上智能合约可以抗人为干扰控制合约涉及的全部资金的特色，使资金的流向完全遵照约定的条款来执行，极大地提升了合约的价值，并将大大减少因传统合约无法严格按条款得到执行，以及违约追责而造成的社会资源和人力成本的巨大浪费！它将大大提升人类社会延续和发展的效率。

5. 智能合约绑定了双方的数字资产，相对传统合约违约成本更高，从而带来了更强的约束力和执行效率。

6. 由于许多不同的智能合约可能想要验证关于其用户的某些属性，因此链上可查的身份变得越来越重要。然而，去中心化的身份存储和点对点的身份传递，以及基于零知识证明的身份验证机制，才会使得身份的存储、调用和验证变得简单和高效。身份与智能合约的绑定，将具有超常的价值！

7. 适用范围更广，可适用于全球范围的协作，传统合约受制于各地法律、人文因素等各种因素，完全无法适应当今全球化的需求。

8. 从去中心化去审查的投融资，到构建全球一体的治理体系，智能合约在这一轮“区块链革命”中，将起到举足轻重的作用！

对于以太坊，我们应该认识到：

1. 目标远大：它矢志要成为区块链领域的安卓。

2. 以太坊的爆发使我们认识到，作为区块链2.0代表的公链的核心根本就不仅仅是TPS，而是还需要有最强大脑们构建的千千万万个智能合约标准。 a. TPS到达1百万/秒，并不能解决多少问题，它还需要第三次甚至第四次的进化。

   b. 我们已经看到智能合约标准带来的应用的惊人的爆发力，因此也明白：智能合约标准的建设始终是以太坊里最重要的核心。

   c. 智能合约标准的作用在于两个方面：第一，带来新的应用；第二，在公平公正公开透明的去中心化去审查的基础之上爆发应用！

   d. 目前所有公链里，只有以太坊的智能合约标准的发展欣欣向荣！其它公链几乎一片死寂，它们全部加起来的贡献，都恐怕连以太坊的百分之一都没有。

3. 我们有理由相信：以太坊有潜力成为前所未有的合作博弈竞技场。 a. 比特币创造性地带来了去中心化的激励机制，但可惜的是它带来的仍旧是非合作博弈，譬如比特币矿业带来的“公地悲剧”和“囚徒困境”，还有比特币发展中的“猎鹿博弈”、“懦夫博弈”等等，已经是非常明显，而且已经被业界作为经典案例。 b. 智能合约恰好可以充当一个不会被收买、无处不在的外部监督者，用于执行和监督利益相关者之间的协议。理论上以太坊可以将任何非合作博弈变成合作博弈。在智能合约强大的作用下，此前的利益格局会被打破！ c. 从非合作到合作博弈的转变是通过一种名为 Game Warping 的技术实现的，因为智能合约让以太坊成为一个可以根据规则启动的透明、可触发、不可外部干预的链上清算支付系统。它使得合作博弈成为一个合乎逻辑的选择。 d. 在以太坊和智能合约可用之前，我们很难找到这样普适且可信的第三方工具。我们现在要做好的，只是要找到适合的机制让博弈的关键操作与链上合约绑定（智能合约标准的建设即为以太坊最重要也最有价值的工作），即可将现实的博弈才非合作变为合作！

总而言之，从囚徒困境到合作博弈，在比特币的基础之上，以太坊为区块链的发展带来了质的飞跃以及无可限量的美好未来！

ERC-721非同质通证标准

ERC-721是一个自由的开放标准，描述了如何在以太坊区块链上构建不可互换或独特的通证。尽管现在大多数通证采用了ERC20通证标准，也就是说大多数通证都是可置换的（每个代币都与其他代币完全相同），对于主要需要货币属性的通证来说，ERC20标准是很好的选择。但是对于具有唯一性的物品，ERC20接口就力不从心了，例如同是一幅名画，真实作品和复制品价值是不一样的。所以就有了专门针对收藏品等的ERC721标准：每个ERC-721通证都是唯一的。

这就是说：ERC20通证是可以相互置换的，而ERC721通证则是不能置换的，亦即ERC721的每个通证是唯一的，且不可分割，它的最小单位就是1。

以下是该标准的核心规范：

pragma solidity ^0.4.20;

/// @title ERC-721 Non-Fungible Token Standard
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x80ac58cd.
interface ERC721 /* is ERC165 */ {
    /// @dev This emits when ownership of any NFT changes by any mechanism.
    ///  This event emits when NFTs are created (`from` == 0) and destroyed
    ///  (`to` == 0). Exception: during contract creation, any number of NFTs
    ///  may be created and assigned without emitting Transfer. At the time of
    ///  any transfer, the approved address for that NFT (if any) is reset to none.
    /// @dev 当任何NFT的所有权更改时（不管哪种方式），就会触发此事件。
    /// 在创建（此时`from` == 0）和销毁NFT时(此时`to` == 0)，也会会触发此事件。
    /// 创建合约时例外：此时可以创建和派发任意数量的NFT而无需触发此事件。
    /// 在进行任何转移时，该 NFT（如果有）的被授权地址将重置为无。
    event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);

    /// @dev This emits when the approved address for an NFT is changed or
    ///  reaffirmed. The zero address indicates there is no approved address.
    ///  When a Transfer event emits, this also indicates that the approved
    ///  address for that NFT (if any) is reset to none.
    /// @dev 当更改或确认NFT的被授权地址时触发。
    ///  零地址表示没有被授权的地址。
    ///  触发 `Transfer` 事件时，该NFT的被授权地址（如果有）同样被重置为“无”（零地址）。
    event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);

    /// @dev This emits when an operator is enabled or disabled for an owner.
    ///  The operator can manage all NFTs of the owner.
    /// @dev 所有者启用或禁用操作员时触发。
    /// 操作员可管理所有者所持有的NFTs。
    event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

    /// @notice Count all NFTs assigned to an owner
    /// @dev NFTs assigned to the zero address are considered invalid, and this
    ///  function throws for queries about the zero address.
    /// @param _owner An address for whom to query the balance
    /// @return The number of NFTs owned by `_owner`, possibly zero
    /// @notice 统计所有者持有的NFTs数量
    /// @dev NFT 不能分配给零地址，查询零地址同样会异常
    /// @param _owner ： 查询余额的地址
    /// @return `_owner`所有的NFT数量，可以是0
    function balanceOf(address _owner) external view returns (uint256);

    /// @notice Find the owner of an NFT
    /// @dev NFTs assigned to zero address are considered invalid, and queries
    ///  about them do throw.
    /// @param _tokenId The identifier for an NFT
    /// @return The address of the owner of the NFT
    /// @notice 返回所有者
    /// @dev NFT分配给零地址是无效的，查询零地址抛出异常
    /// @param _tokenId NFT的编号（id），也是其识别码。
    /// @return 返回所有者地址
    function ownerOf(uint256 _tokenId) external view returns (address);

    /// @notice Transfers the ownership of an NFT from one address to another address
    /// @dev Throws unless `msg.sender` is the current owner, an authorized
    ///  operator, or the approved address for this NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT. 
    When transfer is complete, this function
    ///  checks if `_to` is a smart contract (code size > 0). If so, it calls
    ///  `onERC721Received` on `_to` and throws if the return value is not
    ///  `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    /// @param data Additional data with no specified format, sent in call to `_to`
    /// @notice 将NFT的所有权从一个地址转移到另一个地址
    /// @dev 如果`msg.sender` 不是当前的所有者（或被授权者）则抛出异常
    /// 如果 `_from` 不是所有者、`_to` 是零地址、`_tokenId` 不是有效id 均抛出异常。
    /// 当转移完成时，函数检查  `_to` 是否为合约（代码数量 > 0），如果是，调用 `_to`的 `onERC721Received` 并且检查返回值是否是 `0x150b7a02` 
    /// （即：`bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`）如果不是抛出异常。    /// @param _from ：当前的所有者
    /// @param _from NFT当前的所有者
    /// @param _to ：新的所有者
    /// @param _tokenId ：要转移的token id.
    /// @param data : 附加额外的参数（没有指定格式），传递给接收者。
    function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;

    /// @notice Transfers the ownership of an NFT from one address to another address
    /// @dev This works identically to the other function with an extra data parameter,
    ///  except this function just sets data to "".
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    /// @notice 将NFT的所有权从一个地址转移到另一个地址，功能同上，不带data参数。
    function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE
    ///  TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS OR ELSE
    ///  THEY MAY BE PERMANENTLY LOST
    /// @dev Throws unless `msg.sender` is the current owner, an authorized
    ///  operator, or the approved address for this NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    /// @notice 转移所有权 -- 调用者负责确认`_to`是否能接收NFT，否则可能永久丢失。
    /// @dev 如果`msg.sender` 不是当前的所有者（或被授权操作员，或被授权地址）则抛出异常
    /// 如果 `_from` 不是当前的所有者、`_to` 是零地址、`_tokenId` 不是有效id 均抛出异常。
    function transferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Change or reaffirm the approved address for an NFT
    /// @dev The zero address indicates there is no approved address.
    ///  Throws unless `msg.sender` is the current NFT owner, or an authorized
    ///  operator of the current owner.
    /// @param _approved The new approved NFT controller
    /// @param _tokenId The NFT to approve
    /// @notice 更改或确认NFT的被授权地址
    /// @dev 零地址表示没有被授权的地址。
    ///  如果`msg.sender` 不是当前的所有者或被授权的操作员则抛出异常。
    /// @param _approved 新授权的控制者
    /// @param _tokenId ： 授予的token id
    function approve(address _approved, uint256 _tokenId) external payable;

    /// @notice Enable or disable approval for a third party ("operator") to manage
    ///  all of `msg.sender`'s assets
    /// @dev Emits the ApprovalForAll event. The contract MUST allow
    ///  multiple operators per owner.
    /// @param _operator Address to add to the set of authorized operators
    /// @param _approved True if the operator is approved, false to revoke approval
    /// @notice 启用或禁用授权第三方（操作员）管理 `msg.sender` 所有资产
    /// @dev 触发 ApprovalForAll 事件，合约必须允许每个所有者可以有多个操作员。
    /// @param _operator 要添加到授权操作员列表中的地址
    /// @param _approved True 表示操作员被授权, false 表示撤销授权
    function setApprovalForAll(address _operator, bool _approved) external;

    /// @notice Get the approved address for a single NFT
    /// @dev Throws if `_tokenId` is not a valid NFT.
    /// @param _tokenId The NFT to find the approved address for
    /// @return The approved address for this NFT, or the zero address if there is none
    /// @notice 获取单个NFT的授权地址
    /// @dev 如果 `_tokenId` 无效，抛出异常。
    /// @param _tokenId ：  token id
    /// @return 返回被授权地址， 零地址表示没有被授权地址。
    function getApproved(uint256 _tokenId) external view returns (address);

    /// @notice Query if an address is an authorized operator for another address
    /// @param _owner The address that owns the NFTs
    /// @param _operator The address that acts on behalf of the owner
    /// @return True if `_operator` is an approved operator for `_owner`, false otherwise
    /// @notice 查询一个地址是否是另一个地址的被授权操作员
    /// @param _owner 所有者
    /// @param _operator 代表所有者的被授权操作员
    /// @return 返回True则`_operator`是所有者的被授权操作员， 否则返回false。
    function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}

interface ERC165 {
    /// @notice Query if a contract implements an interface
    /// @param interfaceID The interface identifier, as specified in ERC-165
    /// @dev Interface identification is specified in ERC-165. This function
    ///  uses less than 30,000 gas.
    /// @return `true` if the contract implements `interfaceID` and
    ///  `interfaceID` is not 0xffffffff, `false` otherwise
    function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

最后一部分表明：每个符合ERC721的智能合约必须同时符合ERC721和ERC165。ERC165是智能合约定义自己支持哪些接口的一种方式。

除此之外，ERC-721 还提供了以下扩展接口。

钱包接口（wallet interface）

钱包等应用要接受NFT的安全转账，则必须实现如下接口。

interface ERC721TokenReceiver {
    /// @notice 处理接收NFT
    /// @dev ERC721智能合约在`transfer`完成后，在收币地址上调用这个函数。
    /// 函数可以复原或者拒绝转账。返回非`0x150b7a02` 也同样是导致交易被复原。
    /// 注意: 调用这个函数的 msg.sender是ERC721的合约地址
    /// @param _operator ：调用 `safeTransferFrom` 函数的地址。
    /// @param _from ：之前的NFT拥有者
    /// @param _tokenId ： NFT token id
    /// @param _data ： 附加信息
    /// @return 正确处理时返回 `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`
    function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes _data) external returns(bytes4);
}

元数据接口（metadata extension）

ERC-721引入了Metadata的概念，以供每个NFT描述自身的属性，供智能合约查询。对于NFT合约，这是可选的接口：

/// @title ERC-721 Non-Fungible Token Standard, optional metadata extension
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x5b5e139f.
interface ERC721Metadata /* is ERC721 */ {
    /// @notice 合约中NFT集合的名字
    function name() external view returns (string _name);

    /// @notice 其缩写名称
    function symbol() external view returns (string _symbol);

    /// @notice 一个给定资产的唯一的统一资源标识符（URI）。
    /// @dev 如果 `_tokenId` 无效，抛出异常。
    /// URIs在 RFC 3986 定义。ERC721 URI 可指向一个符合 "ERC721 URI JSON Schema" 的 JSON 文件。
    function tokenURI(uint256 _tokenId) external view returns (string);
}

里面提到的“ERC721 Metadata JSON Schema”则如下：

{
    "title": "Asset Metadata",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Identifies the asset to which this NFT represents"
        },
        "description": {
            "type": "string",
            "description": "Describes the asset to which this NFT represents"
        },
        "image": {
            "type": "string",
            "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
        }
    }
}

观点：由于NFT最早面向艺术品，ERC-721可选Metadata接口“ERC721 Metadata JSON Schema”只指定了name、description、image三个属性（且不可修改）。但对于游戏而言，这些属性远远不够，因此我们下一节要介绍的另一个NFT标准EIP-1155将name、description、image属性转移到了URI的json里面，而不规定URI接口返回的JSON Schema。

问题在于 tokenURI 可指向一个JSON 文件，现有绝大多数NFT产品就通过将其图片或视频的URL记录到这个JSON 文件中，而完成其产品——这也就是说，这些所谓的“非同质化通证”的图片或视频大多保存在私有服务器上。这显然是有问题的，因为大家用智能合约玩的居然是互联网产品！！

为了解决这个巨大的缺陷，我和道易程开发者一起，于2019年进行了摸索，并最终决定采用SVG格式图片链上存储的方式解决部分需求，并于2020年初推出对应的接口标准ERC-2569。

枚举接口（enumeration extension）

枚举接口包含了按索引获取到对应的代币，可以提供NFTs的完整列表，以便NFT可被发现。

interface ERC721Enumerable {
    /// @notice  NFTs 计数
    /// @return  返回合约有效跟踪（所有者不为零地址）的 NFT数量
    function totalSupply() external view returns (uint256);

    /// @notice 枚举索引NFT
    /// @dev 如果 `_index` >= `totalSupply()` 则抛出异常
    /// @param _index 小于 `totalSupply()`的索引号
    /// @return 对应的token id（标准不指定排序方式)
    function tokenByIndex(uint256 _index) external view returns (uint256);

    /// @notice 枚举索引某个所有者的 NFTs
    /// @dev  如果 `_index` >= `balanceOf(_owner)` 或 `_owner` 是零地址，抛出异常
    /// @param _owner 查询的所有者地址
    /// @param _index 小于 `balanceOf(_owner)` 的索引号
    /// @return 对应的token id （标准不指定排序方式)
    function tokenOfOwnerByIndex(address _owner, uint256 _index) external view returns (uint256);}

一个通证标准并不容易，对吧？

ERC-721通证标准的第一个应用是Cryptokitties。中文名叫谜恋猫，又被币民称为加密猫。，

Cryptokitties的每一只猫对应于一个ERC-721通证。每一只猫都是不一样的，不同的毛色，不同的眼睛嘴巴鼻子，等等。而不同的遗传特征组合决定了这只猫的价格高低。你用一只普通的猫，来换我的名贵的猫，我会给你吗？当然不可能！所以ERC-721的通证，就是典型的“不可替换”的通证。每一个通证都是一个独立的个体，有着自己独特的价值。这样每一个都具有独特性和稀缺性，所以ERC-721最大的应用属性被认为是收藏。ERC-721在收藏品市场的应用，就是每个ERC-721对应罕见的独一无二的收藏品。

ERC-721非同质通证标准允许在智能合同中部署非同质通证（NFT）的标准API。该标准提供了跟踪和转让非同质通证的基本功能。我们很容易就联想到非同质通证由个人拥有和处理以及向第三方经纪人/钱包/拍卖商（运营商）委托的例子，非同质通证可以代表数字或实物资产的所有权（或债务）。我们也很容易就联想到ERC-721非同质通证标准适应的几种资产：

• 有形资产——房产、独特的艺术品等等；

• 虚拟收藏品——独特的小猫图片、收藏卡片、卡牌游戏中的卡牌、Decentraland中的土地和房产等等；

• “负值”资产——贷款、债务和其它财务责任。

一般来说，所有的小猫都是独特的，没有两只小猫是一样的。非同质通证（NFT）恰好是可区分的，你能够独立跟踪每一只猫的所有权。

所以，ERC-721是允许在以太坊的任何非同质通证上应用钱包/经纪人/拍卖app的一种标准接口。它提供简单的ERC-721智能合约以及跟踪任意数量非同质通证的合约。可以说ERC-721定义了智能合约必须执行的最小接口，以便管理，拥有和交易独特的通证。它没有强制标记元数据的标准或限制添加补充功能。此标准受ERC-20通证标准的启发，并建立在EIP-20创建以来两年的经验基础之上。EIP-20的局限是不足以追踪非同质通证，因为每一个资产都是不同的（不可置换的），但一堆ERC20代币里的每一个都是相同的（可置换的）。

ERC721非同质通证标准定稿于18年3月13日，它从测试版中移出并转化为社区正式版v1规范，很快就得到来自整个加密生态系统的大量项目的支持和认可。最大的导火索是以该通证标准创新出基因工程智能合约的游戏“谜恋猫”，在ERC721非同质通证标准定稿之前，“谜恋猫”于2017年11月28日即登录以太坊区块链，并成功地引发市场热捧。

ERC721非同质通证标准的代表性应用为区块链“游戏”CryptoCelebrities、CryptoKitties（谜恋猫）、EtherTulips、CryptoPunks、Ethercraft、Decentraland、Etheremon（以太怪物）和Etherbots（以太机器人）等等。这些“游戏”可以说很低幼，但受追捧程度都很高。因为ERC721非同质通证标准为游戏开发者提供了三个新的构建模块：

首先，智能合约允许开发人员创建可公开验证的规则，用户在不受国界限制的情况下可以在全球各地互相连接，并且交易金是内置于协议中的。

其次，非同质通证（NFT）能够开发出可证明的集稀缺性、可编程性和抗审查三种特性于一体的数字商品。

其三，它使得虚拟角色、道具、勋章、物品可以跨服（服务器）、跨界（国界）、跨戏（游戏）。

这三个新的构建模块将使开发者能够扩展现有的游戏内核，或者创建新的游戏内核。会不会鸟枪变大炮，我们拭目以待！

ERC721非同质通证标准，又被翻译为不可置换代币标准。

相关技术文献

关联技术标准：

1. ERC-20 Token Standard.

2. ERC-165 Standard Interface Detection.

3. ERC-173 Owned Standard.

4. ERC-223 Token Standard.

5. ERC-677 transferAndCall Token Standard.

6. ERC-827 Token Standard.

7. Ethereum Name Service (ENS).

8. Instagram – What’s the Image Resolution?

9. JSON Schema.

10. Multiaddr.

11. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels.

使用了该技术标准的项目：

1. CryptoKitties.

2. 0xcert ERC-721 Token.

3. Su Squares.

4. Decentraland.

5. CryptoPunks.

6. DMarket.

7. Enjin Coin.

8. Ubitquity.

9. Propy.

10. CryptoKitties Deployed Contract.

11. Su Squares Bug Bounty Program.

12. XXXXERC721.

13. ERC721ExampleDeed.

14. Curio Cards.

15. Rare Pepe.

16. Auctionhouse Asset Interface.

17. OpenZeppelin SafeERC20.sol Implementation.

主要参考文献

EIP 1155: ERC-1155 Multi Token Standard（多重通证标准）

Simple Summary 简介

A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens or other configurations (e.g. semi-fungible tokens).

本协议定义了可用于管理多种通证的智能合约的接口。利用本协议只需部署一个智能合约便可管理任意种同质通证、非同质通证或其它通证（如半同质通证）的组合。

Abstract 前言

This standard outlines a smart contract interface that can represent any number of fungible and non-fungible token types. Existing standards such as ERC-20 require deployment of separate contracts per token type. The ERC-721 standard’s token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the ERC-1155 Multi Token Standard allows for each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes.

本协议给出了一种智能合约接口，能定义任意种类和数量的同质和非同质通证。在现有的通证标准中，ERC-20标准在使用时，需要对不同的通证种类部署不同的智能合约；ERC-721标准在使用时，需要用Token ID给每一个非同质通证的一个唯一的索引（编号），并把一组这样的非同质通证作为一个集合部署在一个智能合约中。而在ERC-1155多通证标准中，Token ID有新的用途，用它定义的通证种类，可以有自己的元数据（metadata），发行量及其它属性。

The _id argument contained in each function’s argument set indicates a specific token or token type in a transaction.

本协议各个函数中的参数”_id”表示交易中的某个通证或通证种类。

Motivation动机

Tokens standards like ERC-20 and ERC-721 require a separate contract to be deployed for each token type or collection. This places a lot of redundant bytecode on the Ethereum blockchain and limits certain functionality by the nature of separating each token contract into its own permissioned address. With the rise of blockchain games and platforms like Enjin Coin, game developers may be creating thousands of token types, and a new type of token standard is needed to support them. However, ERC-1155 is not specific to games and many other applications can benefit from this flexibility.

ERC-20通证标准要求每种通证对应一个智能合约，ERC-721通证标准要求每个非同质通证集合对应一个智能合约。这两个标准定义的每个通证合约都有自己的地址，导致以太坊上承载的代码臃肿不堪，并且限制了某些功能。随着区块链游戏及平台（如Enjin）的崛起，游戏开发者很有可能需要创建成千上万种通证，这迫切需要一个全新的通证标准。ERC-1155便应运而生，它非常灵活，不仅适用于游戏，也适用于很多其它领域的应用。

New functionality is possible with this design such as transferring multiple token types at once, saving on transaction costs. Trading (escrow / atomic swaps) of multiple tokens can be built on top of this standard and it removes the need to “approve” individual token contracts separately. It is also easy to describe and mix multiple fungible or non-fungible token types in a single contract.

ERC-1155将会催生很多新的功能，比如一次性转账多种通证，从而节省转账费用。该协议也支持多种通证交易（中介交易escrow/原子互换atomic swap）并省却了以往那些交易中需要每个合约进行授权的琐碎步骤，它可以轻易地在一个合约中描述和处理多种同质通证、非同质通证或两者混合的情况。

Specification：规范

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

关键字“MUST”，“MUST NOT”，“REQUIRED”，“SHALL”，“SHALL NOT”，“SHOULD”，“SHOULD NOT”，“RECOMMENDED”，“MAY”，“OPTIONAL”的详细解释请参看RFC 2110

Smart contracts implementing the ERC-1155 standard MUST implement all of the functions in the ERC1155 interface.

部署ERC-1155标准的智能合约必须实现ERC1155接口定义的所有函数。

Smart contracts implementing the ERC-1155 standard MUST implement the ERC-165 supportsInterface function and MUST return the constant value true if 0xd9b67a26 is passed through the interfaceID argument.

实现ERC-1155标准的智能合约必须实现ERC-165标准中的supportsInterface接口函数，并当其参数interfaceID传入值为0xd9b67a26时，返回true。

ERC-1155 Token Receiver ERC-1155通证接收者

Smart contracts MUST implement all of the functions in the ERC1155TokenReceiver interface to accept transfers. See “Safe Transfer Rules” for further detail.

智能合约必须实现ERC1155TokenReceiver接口中所有定义的函数。更多细节请参看“Safe Transfer Rules”。

Smart contracts MUST implement the ERC-165 supportsInterface function and signify support for the ERC1155TokenReceiver interface to accept transfers. See “ERC1155TokenReceiver ERC-165 rules” for further detail.

智能合约必须实现ERC-165标准中的supportsInterface接口函数，并支持ERC1155TokenReceiver接口。更多细节请参看“ERC1155TokenReceiver ERC-165 rules”。

Safe Transfer Rules 安全转账规则

To be more explicit about how the standard safeTransferFrom and safeBatchTransferFrom functions MUST operate with respect to the ERC1155TokenReceiver hook functions, a list of scenarios and rules follows.

当涉及ERC1155TokenReceiver中的接口函数时，标准函数safeTransferFrom和safeBatchTransferFrom的执行方式严格遵循下列规则

Scenarios 场景

Scenario#1 : The recipient is not a contract.

场景1：接收者不是智能合约

· onERC1155Received and onERC1155BatchReceived MUST NOT be called on an EOA (Externally Owned Account).

onERC1155Received和onERC1155BatchReceived不应该被外部账户（Externally Owned Account简称EOA）调用

Scenario#2 : The transaction is not a mint/transfer of a token.

场景2：交易不是挖矿或转账

· onERC1155Received and onERC1155BatchReceived MUST NOT be called outside of a mint or transfer process.

onERC1155Received和onERC1155BatchReceived不应该在除挖矿或转账之外的其它操作中被调用。

Scenario#3 : The receiver does not implement the necessary ERC1155TokenReceiver interface function(s).

场景3：作为接收者的合约没有实现ERC1155TokenReceiver接口中相应的函数

· The transfer MUST be reverted with the one caveat below.

该笔交易必须被回滚并给出下面的警告信息。

。If the token(s) being sent are part of a hybrid implementation of another standard, that particular standard’s rules on sending to a contract MAY now be followed instead. See “Compatibility with other standards” section.

如果交易的通证是用其它合约标准实现的并且通证的实现代码中包含标准和非标准函数，则该交易可以遵循该通证的合约标准而不是ERC1155标准。详细信息请参看“Compatibility with other standards “。

Scenario#4 : The receiver implements the necessary ERC1155TokenReceiver interface function(s) but returns an unknown value.

场景4：接收合约实现了ERC1155TokenReceiver中相应的接口函数但返回一个未知值。

· The transfer MUST be reverted.

该笔交易必须被回滚。

Scenario#5 : The receiver implements the necessary ERC1155TokenReceiver interface function(s) but throws an error.

场景5：接收合约实现了ERC1155TokenReceiver中相应的接口函数但抛出错误。

· The transfer MUST be reverted.

该笔交易必须被回滚。

Scenario#6 : The receiver implements the ERC1155TokenReceiver interface and is the recipient of one and only one balance change (e.g. safeTransferFrom called).

场景6：接收合约实现了ERC1155TokenReceiver接口函数，并且接收者有且仅有一个账户的余额发生了变化（比如safeTransferFrom被调用）。

· The balances for the transfer MUST have been updated before the ERC1155TokenReceiver hook is called on a recipient contract.

转账交易中账户余额的更新必须在ERC1155TokenReceiver接口函数在接收合约处被调用之前完成。

· The transfer event MUST have been emitted to reflect the balance changes before the ERC1155TokenReceiver hook is called on the recipient contract.

该笔转账的事件必须在ERC1155TokenReceiver接口函数在接收合约处被调用前触发，并且事件要反映账户余额的变化。

· One of onERC1155Received or onERC1155BatchReceived MUST be called on the recipient contract.

onERC1155Received或onERC1155BatchReceived必须在接收合约处被调用。

· The onERC1155Received hook SHOULD be called on the recipient contract and its rules followed.

onERC1155Received必须在接收合约处被调用并遵循其调用规则。

。See “onERC1155Received rules” for further rules that MUST be followed.

关于调用onERC1155Received必须遵循的规则，更多细节请参看“onERC1155Received rules”。

· The onERC1155BatchReceived hook MAY be called on the recipient contract and its rules followed.

onERC1155BatchReceived或许（并非一定）会在接收合约处被调用，一旦被调用则必须遵循其调用规则。

。See “onERC1155BatchReceived rules” for further rules that MUST be followed.

关于调用onERC1155BatchReceived必须遵循的规则，更多细节请参看“onERC1155BatchReceived rules”。

Scenario#7 : The receiver implements the ERC1155TokenReceiver interface and is the recipient of more than one balance change (e.g. safeBatchTransferFrom called).

场景7：接收合约实现了ERC1155TokenReceiver接口函数，并且接收者有多个账户余额发生了变化（比如safeBatchTransferFrom被调用）。

· All balance transfers that are referenced in a call to an ERC1155TokenReceiver hook MUST be updated before the ERC1155TokenReceiver hook is called on the recipient contract.

转账交易中所有账户余额的更新必须在ERC1155TokenReceiver接口函数在接收合约处被调用之前完成。

· All transfer events MUST have been emitted to reflect current balance changes before an ERC1155TokenReceiver hook is called on the recipient contract.

所有的转账事件必须在ERC1155TokenReceiver接口函数在接收合约处被调用前触发，并且事件要反映账户的余额变化。

· onERC1155Received or onERC1155BatchReceived MUST be called on the recipient as many times as necessary such that every balance change for the recipient in the scenario is accounted for.

对每一个账户余额的变动，onERC1155Received或onERC1155BatchReceived都必须在接收合约处被调用。

。The return magic value for every hook call MUST be checked and acted upon as per “onERC1155Received rules” and “onERC1155BatchReceived rules”.

对每一个接口函数的返回幻术值（return magic value）必须进行检查和处理，并遵循“onERC1155Received rules”和“onERC1155BatchReceived rules”中的规则

· The onERC1155BatchReceived hook SHOULD be called on the recipient contract and its rules followed.

onERC1155BatchReceived必须在接收合约处被调用并遵循其调用规则。

。See “onERC1155BatchReceived rules” for further rules that MUST be followed.

关于调用onERC1155BatchReceived必须遵循的规则，更多细节请参看“onERC1155BatchReceived rules”。

· The onERC1155Received hook MAY be called on the recipient contract and its rules followed.

onERC1155Received或许（并非一定）会在接收合约处被调用，如调用则必须遵循其调用规则。

。See “onERC1155Received rules” for further rules that MUST be followed.

关于调用onERC1155Received必须遵循的规则，更多细节请参看“onERC1155Received rules”。

Scenario#8 : You are the creator of a contract that implements the ERC1155TokenReceiver interface and you forward the token(s) onto another address in one or both of onERC1155Received and onERC1155BatchReceived.

场景8：你写了一个智能合约，实现了ERC1155TokenReceiver接口函数的功能，你调用onERC1155Received或onERC1155BatchReceived或两个都调用，把该合约通证转账到另一个地址。

· Forwarding should be considered acceptance and then initiating a new safeTransferFrom or safeBatchTransferFrom in a new context.

该转账将被视为已经接收，并继续调用safeTransferFrom或safeBatchTransferFrom。

。The prescribed keccak256 acceptance value magic for the receiver hook being called MUST be returned after forwarding is successful.

该转账成功完成后，被调用的接收合约中的接口函数所产生的keccak256值必须被返回。

· The _data argument MAY be re-purposed for the new context.

参数“_data”可以（并非必须）被用于新的场景。

· If forwarding fails the transaction MAY be reverted.

如果该转账失败，则交易可以（并非必须）被回滚

。If the contract logic wishes to keep the ownership of the token(s) itself in this case it MAY do so.

在此场景下，如果合约设计者希望合约仍然保留对该通证的所有权，则通证所有权可以（并非必须）仍然为合约所有。

Scenario#9 : You are transferring tokens via a non-standard API call i.e. an implementation specific API and NOT safeTransferFrom or safeBatchTransferFrom.

场景9：用户通过非标准API函数转账通证。所谓的非标准API函数是指除safeTransferFrom和safeBatchTransferFrom以外的API函数。

· In this scenario all balance updates and events output rules are the same as if a standard transfer function had been called.

在此场景中，转账交易里所有发生的账户余额变化和触发的事件消息都必须遵循标准API被调用时所遵循的规则。

。i.e. an external viewer MUST still be able to query the balance via a standard function and it MUST be identical to the balance as determined by TransferSingle and TransferBatch events alone.

即用户仍然可以通过标准函数查询余额，并且所查询到的结果和调用TransferSingle及TransferBatch事件得到的结果一样。

· If the receiver is a contract the ERC1155TokenReceiver hooks still need to be called on it and the return values respected the same as if a standard transfer function had been called.

如果接收者是智能合约，ERC1155TokenReceiver接口函数仍然必须被调用，且返回值必须与调用标准函数时一样。

。However while the safeTransferFrom or safeBatchTransferFrom functions MUST revert if a receiving contract does not implement the ERC1155TokenReceiver interface, a non-standard function MAY proceed with the transfer.

当接收者是智能合约，但该合约并未实现ERC1155TokenReceiver接口函数时，safeTransferFrom或safeBatchTransferFrom一定会回滚交易。但对非标准函数而言，它可能（并非一定）会继续执行后续的操作而不回滚交易。

。See “Implementation specific transfer API rules”.

更多细节请参看“Implementation specific transfer API rules”

Rules 规则

safeTransferFrom rules safeTransferFrom规则

· Caller must be approved to manage the tokens being transferred out of the _from account (see “Approval” section).

调用者必须得到授权才可以从参数“_from”指定的账户转账通证。

· MUST revert if _to is the zero address.

如果参数“_to”设定的地址为零地址，则交易必须回滚。

· MUST revert if balance of holder for token _id is lower than the _value sent to the recipient.

对参数“token_id”所指的通证，如果其转出账户的余额小于参数“_value”所定义的金额，则交易必须回滚。

· MUST revert on any other error.

如果转账交易出现任何其它错误，交易也必须回滚。

· MUST emit the TransferSingle event to reflect the balance change (see “TransferSingle and TransferBatch event rules” section).

必须触发TransferSingle事件以反映账户余额的变化（请参看“TransferSingle and TransferBatch event rules”章节）

· After the above conditions are met, this function MUST check if _to is a smart contract (e.g. code size > 0). If so, it MUST call onERC1155Received on _to and act appropriately (see “onERC1155Received rules” section).

当上述条件都满足时，safeTransferFrom函数就必须检查参数“_to”是否是一个智能合约地址（比如检查code size是否大于0），如果是，就必须在参数“_to”所指向的智能合约上调用onERC1155Received并执行相应的操作（请参看“onERC1155Received rules”章节）。

。The _data argument provided by the sender for the transfer MUST be passed with its contents unaltered to the onERC1155Received hook function via its _data argument.

交易发送者必须将参数“_data”所含的数据原原本本，不做任何改动地传递给onERC1155Received接口函数的参数“_data”。

safeBatchTransferFrom rules: safeBatchTransferFrom规则

· Caller must be approved to manage all the tokens being transferred out of the _from account (see “Approval” section).

调用者必须得到授权才可以从参数“_from”设定的账户转账通证。

· MUST revert if _to is the zero address.

如果参数“_to”设定的地址为零地址，则交易必须回滚。

· MUST revert if length of _ids is not the same as length of _values.

如果参数“_ids”的长度和参数“_values”的长度不同，则交易必须回滚。

· MUST revert if any of the balance(s) of the holder(s) for token(s) in _ids is lower than the respective amount(s) in _values sent to the recipient.

对参数“_ids”所指的通证，如果其任一转出账户的余额小于该交易所对应的参数“_values”所定义的金额，则交易必须回滚。

· MUST revert on any other error.

如果转账交易出现任何其它错误，交易也必须回滚。

· MUST emit TransferSingle or TransferBatch event(s) such that all the balance changes are reflected (see “TransferSingle and TransferBatch event rules” section).

必须触发TransferSingle或TransferBatch事件以反映所有账户余额的变化（请参看“TransferSingle and TransferBatch event rules”章节）

· The balance changes and events MUST occur in the array order they were submitted (_ids[0]/_values[0] before _ids[1]/_values[1], etc).

所有账户余额的变化和事件的触发必须按其被提交的顺序发生（即_ids[0]/_values[0]在_ids[1]/_values[1]之前发生……）。

· After the above conditions are met, this function MUST check if _to is a smart contract (e.g. code size > 0). If so, it MUST call onERC1155Received or onERC1155BatchReceived on _to and act appropriately (see “onERC1155Received and onERC1155BatchReceived rules” section).

当上述条件满足时，safeBatchTransferFrom函数必须检查参数“_to”是否是一个智能合约地址（比如检查code size是否大于0），如果是，就必须在参数“_to”所指向的智能合约上调用onERC1155Received或onERC1155BatchReceived并执行相应的操作（请参看“onERC1155Received and onERC1155BatchReceived rules”章节）。

。The _data argument provided by the sender for the transfer MUST be passed with its contents unaltered to the ERC1155TokenReceiver hook function(s) via their _data argument.

交易发送者必须将参数“_data”所含的数据原原本本，不做任何改动地传递给onERC1155Received接口函数的参数“_data”。

TransferSingle and TransferBatch event rules: TransferSingle和TransferBatch规则

· TransferSingle SHOULD be used to indicate a single balance transfer has occurred between a _from and _to pair.

当单笔转账从参数“_from”指定的地址发送到参数“_to”指定的地址时，应该触发TransferSingle。

。It MAY be emitted multiple times to indicate multiple balance changes in the transaction, but note that TransferBatch is designed for this to reduce gas consumption.

若交易中出现多次转账交易，可以触发多次TransferSingle。但值得注意的是，在这种情况下可以改用TransferBatch而不用多次触发TransferSingle。TransferBatch是专为此种情形设计的，使用它能节省不少gas费用。

。The _operator argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).

参数“_operator”所指定的账户/合约地址必须被授权才能发起转账交易（必须是“msg.sender”）。

。The _from argument MUST be the address of the holder whose balance is decreased.

参数“_from”所指定的地址在交易发生后，余额减少。

。The _to argument MUST be the address of the recipient whose balance is increased.

参数“_to”所指定的地址在交易发生后，余额增加。

。The _id argument MUST be the token type being transferred.

转账交易的通证种类由参数“_id”所指代。

。The _value argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by.

在转账交易中，一方余额减少而另一方余额增加。余额减少方所减少的通证数量必须等于参数“_value”的值，并且也必须等于余额增加方所增加的通证数量。

。When minting/creating tokens, the _from argument MUST be set to 0x0 (i.e. zero address).

当挖矿/创建通证时，参数“_from”的值必须设为“0x0”（即零地址）。

See “Minting/creating and burning/destroying rules”.

请参看“Minting/creating and burning/destroying rules”

。When burning/destroying tokens, the _to argument MUST be set to 0x0 (i.e. zero address).

当消除/销毁通证时，参数”_to”的值必须设为“0x0”（即零地址）。

See “Minting/creating and burning/destroying rules”.

请参看“Minting/creating and burning/destroying rules”

· TransferBatch SHOULD be used to indicate multiple balance transfers have occurred between a _from and _to pair.

当多笔转账从参数“_from”指定的地址发送到参数“_to”指定的地址时，应该触发TransferBatch。

。It MAY be emitted with a single element in the list to indicate a singular balance change in the transaction, but note that TransferSingle is designed for this to reduce gas consumption.

在这种情况下也可以对这些交易中的每一笔转账触发一次TransferSingle。但值得注意的是，TransferBatch是专为此种情形设计的，使用它能节省不少gas费用。

。The _operator argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).

参数“_operator”所指定的账户/合约地址必须被授权才能发起转账交易（必须是“msg.sender”）。

。The _from argument MUST be the address of the holder whose balance is decreased for each entry pair in _ids and _values.

在每一个参数对“_ids”和“_values”所对应的转账交易中，参数“_from”所指定的地址在交易发生后，余额减少。

。The _to argument MUST be the address of the recipient whose balance is increased for each entry pair in _ids and _values.

在每一个参数对“_ids”和“_values”所对应的转账交易中，参数“_to”所指定的地址在交易发生后，余额增加。

。The _ids array argument MUST contain the ids of the tokens being transferred.

转账交易的一系列通证中每一种通证的索引都必须对应数组参数“_ids”中的一个值，即数组参数“_ids”包含了所有转账通证的索引。

。The _values array argument MUST contain the number of token to be transferred for each corresponding entry in _ids.

转账交易的一系列通证中，每一种通证的转账数量都必须对应数组参数“_values”中的一个值，即数组参数“_values”包含了所有转账通证中每一种通证的转账数量。

。_ids and _values MUST have the same length.

参数“_ids”和“_values”必须长度一致。

。When minting/creating tokens, the _from argument MUST be set to 0x0 (i.e. zero address).

当挖矿/创建通证时，参数“_from”的值必须设为“0x0”（即零地址）。

See “Minting/creating and burning/destroying rules”.

请参看“Minting/creating and burning/destroying rules”

。When burning/destroying tokens, the _to argument MUST be set to 0x0 (i.e. zero address).

当消除/销毁通证时，参数”_to”的值必须设为“0x0”（即零地址）。

See “Minting/creating and burning/destroying rules”.

请参看“Minting/creating and burning/destroying rules”

· The total value transferred from address 0x0 minus the total value transferred to 0x0 observed via the TransferSingle and TransferBatch events MAY be used by clients and exchanges to determine the “circulating supply” for a given token ID.

给定一个通证ID，根据TransferSingle和TransferBatch事件观测到的从地址“0x0”转出的通证总量减去发送至地址“0x0”的通证总量所得到的数量可被用户及交易所视为该通证的“流通总量”。

· To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the TransferSingle event from 0x0 to 0x0, with the token creator as _operator, and a _value of 0.

给定一个通证ID，如果该通证的初始发行量为0，则其合约触发TransferSingle事件时，应从地址“0x0”发送到地址“0x0”，通证的创造者（creator）由参数“_operator”所定义，参数“_value”的值为0。

· All TransferSingle and TransferBatch events MUST be emitted to reflect all the balance changes that have occurred before any call(s) to onERC1155Received or onERC1155BatchReceived.

所有反映账户余额变化的TransferSingle和TransferBatch事件都必须在onERC1155Received或onERC1155BatchReceived被调用前触发。

。To make sure event order is correct in the case of valid re-entry (e.g. if a receiver contract forwards tokens on receipt) state balance and events balance MUST match before calling an external contract.

当发生事件重入（re-entry）时（比如一个合约在收到通证后紧接着转发通证）为了保证事件触发顺序的正确，系统的状态（？state balance）和事件（？events balance）必须匹配，然后再调用外部合约。

onERC1155Received rules: onERC1155Received规则

· The _operator argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).

参数“_operator”所指定的账户/合约地址必须被授权才能发起转账交易（必须是“msg.sender”）。

· The _from argument MUST be the address of the holder whose balance is decreased.

参数“_from”所指定的地址在交易发生后，余额减少。

· _from MUST be 0x0 for a mint.

挖矿时参数“_from”的值必须为“0x0”。

· The _id argument MUST be the token type being transferred.

转账交易的通证种类由参数“_id”所指代。

· The _value argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by.

在转账交易中，一方余额减少而另一方余额增加。余额减少方所减少的通证数量必须等于参数“_value”的值，并且也必须等于余额增加方所增加的通证数量。

· The _data argument MUST contain the information provided by the sender for the transfer with its contents unaltered.

交易发送者必须将参数“_data”所含的数据原原本本，不做任何改动地传递给接收者。

。i.e. it MUST pass on the unaltered _data argument sent via the safeTransferFrom or safeBatchTransferFrom call for this transfer.

也即是onERC1155Received必须将safeTransferFrom 或safeBatchTransferFrom 函数传来的“_data”参数不做任何改动地中转。

· The recipient contract MAY accept an increase of its balance by returning the acceptance magic value bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))

接收合约如果返回了“幻术值（acceptance magic value）”bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))其账户余额可能会增加。

。If the return value is bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) the transfer MUST be completed or MUST revert if any other conditions are not met for success.

如果返回值是bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))，则转账交易要么成功完成，要么因某些条件不满足而回滚。

· The recipient contract MAY reject an increase of its balance by calling revert.

当接收合约回滚交易后，其账户余额可能不会增加。

。If the recipient contract throws/reverts the transaction MUST be reverted.

如果接收合约抛出异常/回滚，则交易必须被回滚。

· If the return value is anything other than bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) the transaction MUST be reverted.

如果返回值不是bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))，则交易必须被回滚。

· onERC1155Received (and/or onERC1155BatchReceived) MAY be called multiple times in a single transaction and the following requirements must be met:

在一笔交易中，onERC1155Received（和/或onERC1155BatchReceived）可以被多次调用，但必须满足下列条件：

。All callbacks represent mutually exclusive balance changes.

所有callback函数代表的余额变化都是互斥的。

。The set of all calls to onERC1155Received and onERC1155BatchReceived describes all balance changes that occurred during the transaction in the order submitted.

所有对onERC1155Received和onERC1155BatchReceived的调用代表的余额变化依照其提交顺序依次进行。

· A contract MAY skip calling the onERC1155Received hook function if the transfer operation is transferring the token to itself.

如果一笔交易是合约自己给自己转账，则可以不调用onERC1155Received接口函数。

onERC1155BatchReceived rules: onERC1155BatchReceived规则

· The _operator argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).

参数“_operator”所指定的账户/合约地址必须被授权才能发起转账交易（必须是“msg.sender”）。

· The _from argument MUST be the address of the holder whose balance is decreased.

参数“_from”所指定的地址在交易发生后，余额减少。

。_from MUST be 0x0 for a mint.

挖矿时参数“_from”的值必须为“0x0”。

· The _ids argument MUST be the list of tokens being transferred.

参数“_ids”表示交易转账的通证列表。

· The _values argument MUST be the list of number of tokens (matching the list and order of tokens specified in _ids) the holder balance is decreased by and match what the recipient balance is increased by.

在转账交易中，一方余额减少而另一方余额增加。余额减少方所减少的每一种通证的数量必须等于参数“_values”中的一个值，并且也必须等于余额增加方所增加的该种通证的数量。

· The _data argument MUST contain the information provided by the sender for the transfer with its contents unaltered.

交易发送者必须将参数“_data”所含的数据原原本本，不做任何改动地传递给接收者。

。i.e. it MUST pass on the unaltered _data argument sent via the safeBatchTransferFrom call for this transfer.

也即是onERC1155BatchReceived必须将safeBatchTransferFrom 函数传来的“_data”参数不做任何改动地中转。

· The recipient contract MAY accept an increase of its balance by returning the acceptance magic value bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))

接收合约如果返回了“幻术值（acceptance magic value）”bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))其账户余额可能会增加。

。If the return value is bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) the transfer MUST be completed or MUST revert if any other conditions are not met for success.

如果返回值是bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))，则转账交易要么成功完成，要么因某些条件不满足而回滚。

· The recipient contract MAY reject an increase of its balance by calling revert.

当接收合约回滚交易后，其账户余额可能不会增加。

。If the recipient contract throws/reverts the transaction MUST be reverted.

如果接收合约抛出异常/回滚，则交易必须被回滚。

· If the return value is anything other than bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) the transaction MUST be reverted.

如果返回值不是bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))，则交易必须被回滚。

· onERC1155BatchReceived (and/or onERC1155Received) MAY be called multiple times in a single transaction and the following requirements must be met:

在一笔交易中，onERC1155BatchReceived（和/或onERC1155Received）可以被多次调用，但必须满足下列条件：

。All callbacks represent mutually exclusive balance changes.

所有callback函数代表的余额变化都是互斥的。

。The set of all calls to onERC1155Received and onERC1155BatchReceived describes all balance changes that occurred during the transaction in the order submitted.

所有对onERC1155Received和onERC1155BatchReceived的调用代表的余额变化依照其提交顺序依次进行。

· A contract MAY skip calling the onERC1155BatchReceived hook function if the transfer operation is transferring the token(s) to itself.

如果一笔交易是合约自己给自己转账，则可以不调用onERC1155BatchReceived接口函数。

ERC1155TokenReceiver ERC-165 rules: ERC1155TokenReceiver ERC-165规则

· The implementation of the ERC-165 supportsInterface function SHOULD be as follows:

ERC-165 supportsInterface函数的实现应遵循下列规则：

· The implementation MAY differ from the above but:

函数实现的规则可能和上述规则不同，但是：

。It MUST return the constant value true if 0x01ffc9a7 is passed through the interfaceID argument. This signifies ERC-165 support.

当参数interfaceID的值为“0x01ffc9a7”时，函数必须返回“true”，以此体现对ERC-165的支持。

。It MUST return the constant value true if 0x4e2312e0 is passed through the interfaceID argument. This signifies ERC-1155 ERC1155TokenReceiver support.

当参数interfaceID的值为“0x4e2312e0”时，函数必须返回“true”，以此体现对ERC-1155 ERC1155TokenReceiver的支持。

。It MUST NOT consume more than 10,000 gas.

它所耗费的gas不能超过10000。

· This keeps it below the ERC-165 requirement of 30,000 gas, reduces the gas reserve needs and minimises possible side-effects of gas exhaustion during the call.

ERC-165 supportsInterface函数的实现所消耗的gas小于ERC-165标准规定的30000，这降低了gas的储备需求，将gas耗尽所可能引发的负面效应降到最低。

Implementation specific transfer API rules: 特定转账API函数的实现规则

· If an implementation specific API function is used to transfer ERC-1155 token(s) to a contract, the safeTransferFrom or safeBatchTransferFrom (as appropriate) rules MUST still be followed if the receiver implements the ERC1155TokenReceiver interface. If it does not the non-standard implementation SHOULD revert but MAY proceed.

当一个API函数是用于向一个智能合约转账ERC-1155通证时，如果该智能合约实现了ERC1155TokenReceiver接口函数，则调用safeTransferFrom或safeBatchTransferFrom所必须遵循的规则仍然必须遵循。如果该合约没有实现ERC1155TokenReceiver接口函数则交易要回滚，但在交易回滚后可以（并非一定）继续执行后续的语句。

· An example: 实例

1 An approved user calls a function such as function myTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values);.

经过授权的用户调用函数myTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values)时：

2 myTransferFrom updates the balances for _from and _to addresses for all _ids and _values.

myTransferFrom会将所有”_ids”和“_values”对应的通证种类及数量从”_from”地址转账到“_to”地址。

3 myTransferFrom emits TransferBatch with the details of what was transferred from address _from to address _to.

myTransferFrom会触发TransferBatch事件，事件会包含所转账的通证信息、发送者和接收者地址。

4 myTransferFrom checks if _to is a contract address and determines that it is so (if not, then the transfer can be considered successful).

myTransferFrom会检查并认定“_to”地址是否是一个智能合约地址（如果不是智能合约地址，转账可被视为成功）。

5 myTransferFrom calls onERC1155BatchReceived on _to and it reverts or returns an unknown value (if it had returned bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) the transfer can be considered successful).

myTransferFrom会在“_to”指向的智能合约上调用onERC1155BatchReceived并回滚交易或返回一个未知值（如果myTransferFrom返回bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))时，该转账交易被视为成功）。

6 At this point myTransferFrom SHOULD revert the transaction immediately as receipt of the token(s) was not explicitly accepted by the onERC1155BatchReceived function.

此时myTransferFrom应该立刻回滚交易，因为onERC1155BatchReceived函数并不显式确保通证一定被成功接收。

7 If however myTransferFrom wishes to continue it MUST call supportsInterface(0x4e2312e0) on _to and if it returns the constant value true the transaction MUST be reverted, as it is now known to be a valid receiver and the previous acceptance step failed.

如果myTransferFrom希望继续执行后续操作，它必须在“_to”指向的智能合约上调用supportsInterface(0x4e2312e0)。如果当它调用supportsInterface(0x4e2312e0)后，返回值是“true“则该转账交易必须被回滚，因为直到此时它才被证明是有效的接收者，而前一步的交易接收不成功。

· NOTE: You could have called supportsInterface(0x4e2312e0) at a previous step if you wanted to gather and act upon that information earlier, such as in a hybrid standards scenario.

注意：如果你想早点得到相关信息并进行后续操作可以在前一步就调用supportsInterface(0x4e2312e0)。

8 If the above call to supportsInterface(0x4e2312e0) on _to reverts or returns a value other than the constant value true the myTransferFrom function MAY consider this transfer successful.

如果在“_to“指向的智能合约调用supportsInterface(0x4e2312e0)使得交易回滚或得到的返回值不是”true“则myTransferFrom函数也可以（并非一定）视此交易为成功。

· NOTE: this MAY result in unrecoverable tokens if sent to an address that does not expect to receive ERC-1155 tokens.

注意：如果接收方地址无法接收ERC-1155通证，则这种操作可能会导致转账的通证永久丢失。

· The above example is not exhaustive but illustrates the major points (and shows that most are shared with safeTransferFrom and safeBatchTransferFrom):

上例没有详尽所有的情形，但囊括了要点（实际上这些要点很多都与safeTransferFrom和safeBatchTransferFrom一样）。

。Balances that are updated MUST have equivalent transfer events emitted.

有多少交易余额发生变化就要有多少对应的交易事件触发。

。A receiver address has to be checked if it is a contract and if so relevant ERC1155TokenReceiver hook function(s) have to be called on it.

接收者地址必须被检查是否为智能合约地址，如果是则ERC1155TokenReceiver接口函数必须在该合约处被调用。

。Balances (and events associated) that are referenced in a call to an ERC1155TokenReceiver hook MUST be updated (and emitted) before the ERC1155TokenReceiver hook is called.

账户余额的更新（以及触发的相关事件）必须在ERC1155TokenReceiver接口被调用前发生。

。The return values of the ERC1155TokenReceiver hook functions that are called MUST be respected if they are implemented.

所有被调用并且被实现的ERC1155TokenReceiver接口函数，其返回值都必须被合理设置。

。Only non-standard transfer functions MAY allow tokens to be sent to a recipient contract that does NOT implement the necessary ERC1155TokenReceiver hook functions. safeTransferFrom and safeBatchTransferFrom MUST revert in that case (unless it is a hybrid standards implementation see “Compatibility with other standards”).

仅当调用非标准函数时才允许通证被发送给一个没有实现ERC1155TokenReceiver接口函数的智能合约。在这种情况下，safeTransferFrom和safeBatchTransferFrom必须回滚交易（除非它包含标准和非标准的接口实现，详细信息请参看“Compatibility with other standards “）。

Minting/creating and burning/destroying rules: 挖矿/创建和消除/销毁 规则

· A mint/create operation is essentially a specialized transfer and MUST follow these rules:

挖矿/创建实质上是一种特殊的转账交易，必须遵循下列规则：

。To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the TransferSingle event from 0x0 to 0x0, with the token creator as _operator, and a _value of 0.

对一个初始发行量为0的通证，给定其token ID，其合约在触发TransferSingle事件时发送方地址和接收方地址都应该设为“0x0”，通证的创建者（creator）为参数“_operator”，参数“_value”值为0。

。The “TransferSingle and TransferBatch event rules” MUST be followed as appropriate for the mint(s) (i.e. singles or batches) however the _from argument MUST be set to 0x0 (i.e. zero address) to flag the transfer as a mint to contract observers.

（单币种或多币种）挖矿时，“TransferSingle and TransferBatch event rules”章节中所描述的规则必须遵循，此时参数”_from”必须设为“0x0”（即零地址）以标识此交易为挖矿。

· NOTE: This includes tokens that are given an initial balance in the contract. The balance of the contract MUST also be able to be determined by events alone meaning initial contract balances (for eg. in construction) MUST emit events to reflect those balances too.

注意：此规则也适用于初始发行量不为0的通证。对初始发行量不为0的通证其合约账户的余额也必须在触发的事件中反映出来，也即合约账户的初始余额（比如在构造函数中设定的余额）必须在触发的事件中反映出来。

· A burn/destroy operation is essentially a specialized transfer and MUST follow these rules:

消除/销毁实质上是一种特殊的转账交易，必须遵循下列规则：

。The “TransferSingle and TransferBatch event rules” MUST be followed as appropriate for the burn(s) (i.e. singles or batches) however the _to argument MUST be set to 0x0 (i.e. zero address) to flag the transfer as a burn to contract observers.

（单币种或多币种）销毁时，“TransferSingle and TransferBatch event rules”章节中所描述的规则也必须遵循，此时参数”_to”必须设为“0x0”（即零地址）以标识此交易为销毁。

。When burning/destroying you do not have to actually transfer to 0x0 (that is impl specific), only the _to argument in the event MUST be set to 0x0 as above.

当消除/销毁时，你并不一定要向”0x0”地址转账（根据具体的实现而定），但必须将事件的参数“_to”设为“0x0”。

· The total value transferred from address 0x0 minus the total value transferred to 0x0 observed via the TransferSingle and TransferBatch events MAY be used by clients and exchanges to determine the “circulating supply” for a given token ID.

给定一个通证ID，根据TransferSingle和TransferBatch事件观测到的从地址“0x0”转出的通证总量减去发送至地址“0x0”的通证总量所得到的数量可被用户及交易所视为该通证的“流通总量”。

· As mentioned above mint/create and burn/destroy operations are specialized transfers and so will likely be accomplished with custom transfer functions rather than safeTransferFrom or safeBatchTransferFrom. If so the “Implementation specific transfer API rules” section would be appropriate.

综上所述，挖矿/创建和消除/销毁通证的操作是特殊的转账交易，有可能通过除safeTransferFrom和safeBatchTransferFrom以外的用户自定义函数实现。当用户用自定义的函数实现时，必须遵循“Implementation specific transfer API rules”章节所定义的规则。

。Even in a non-safe API and/or hybrid standards case the above event rules MUST still be adhered to when minting/creating or burning/destroying.

当进行挖矿/创建和消除/销毁通证的操作时，即便用户使用的函数并非一定安全，或用户使用的函数可能既包含自定义函数也包含标准函数，其触发的挖矿/创建和消除/销毁事件也必须遵循上述规则。

· A contract MAY skip calling the ERC1155TokenReceiver hook function(s) if the mint operation is transferring the token(s) to itself. In all other cases the ERC1155TokenReceiver rules MUST be followed as appropriate for the implementation (i.e. safe, custom and/or hybrid).

如果挖矿操作是给自己转账通证，则合约可不用执行ERC1155TokenReceiver的接口函数。除此以外在所有的其它情形中，ERC1155TokenReceiver的规则都必须遵循。

A solidity example of the keccak256 generated constants for the various magic values (these MAY be used by implementation):

下例展示了一个Solidity实例，它基于keccak256算法产生了若干幻术值（这些幻术值可以被用在函数实现中）：

Compatibility with other standards 与其它标准的兼容性

There have been requirements during the design discussions to have this standard be compatible with existing standards when sending to contract addresses, specifically ERC-721 at time of writing. To cater for this scenario, there is some leeway with the revert logic should a contract not implement the ERC1155TokenReceiver as per “Safe Transfer Rules” section above, specifically “Scenario#3 : The receiver does not implement the necessary ERC1155TokenReceiver interface function(s)”.

在制定本标准时，与现有标准尤其是ERC-721标准兼容一直是讨论的议题。当一个合约没有遵循ERC1155TokenReceiver的“Safe Transfer Rules”规则时，尤其是没有遵循其“场景3：接收者没有实现ERC1155TokenReceiver接口中相应的函数”的规则时，对交易回滚的处理可以有一些灵活的手法。

Hence in a hybrid ERC-1155 contract implementation an extra call MUST be made on the recipient contract and checked before any hook calls to onERC1155Received or onERC1155BatchReceived are made. Order of operation MUST therefore be:

在一个包含了非标准函数实现和标准函数实现的ERC-1155合约中，在调用任何onERC1155Received或onERC1155BatchReceived接口函数之前，还需要调用一个额外的函数，并且其调用的顺序必须遵循下列规则：

1 The implementation MUST call the function supportsInterface(0x4e2312e0) on the recipient contract, providing at least 10,000 gas.

该合约必须在接收合约处调用supportsInterface(0x4e2312e0)并且提供至少10000 gas。

2 If the function call succeeds and the return value is the constant value true the implementation proceeds as a regular ERC-1155 implementation, with the call(s) to the onERC1155Received or onERC1155BatchReceived hooks and rules associated.

如果该函数调用成功且返回值为“true”则该合约将继续执行后续动作调用onERC1155Received或onERC1155BatchReceived接口函数，与标准的ERC-1155合约一样。

3 If the function call fails or the return value is NOT the constant value true the implementation can assume the recipient contract is not an ERC1155TokenReceiver and follow its other standard’s rules for transfers.

如果该函数调用失败或返回值不是“true”则该合约可以认为接收合约不是ERC1155TokenReceiver，转而遵循其它规则。

Note that a pure implementation of a single standard is recommended rather than a hybrid solution, but an example of a hybrid ERC-1155/ERC-721 contract is linked in the references section under implementations.

注意：对一个通证标准的合约实现，建议要么都用标准函数要么都用自定义函数，把两者混在一起反而不好。但对ERC-1155/ERC-721通证标准，我们提供了一个实例，该实例代码中既包含标准函数也包含用户自定义函数。实例代码的链接在参考章节中。

An important consideration is that even if the tokens are sent with another standard’s rules the ERC-1155 transfer events MUST still be emitted. This is so the balances can still be determined via events alone as per ERC-1155 standard rules.

在设计ERC-1155通证标准时有一个重要的考虑：即使ERC-1155通证在交易过程中遵循的是其它通证标准，但ERC-1155所定义的事件必须遵循ERC-1155的规则触发。

Metadata 元数据

The URI value allows for ID substitution by clients. If the string {id} exists in any URI, clients MUST replace this with the actual token ID in hexadecimal form. This allows for a large number of tokens to use the same on-chain string by defining a URI once, for that large number of tokens.

用户可以用ID值取代URI值。如果URI中包含{id}字串，则用户必须将其用十六进制数的真实通证ID取代。这可以让大量通证共用相同的链上字符串，只需要定义一次URI即可。

· The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: [0-9a-f] with no 0x prefix.

通证的ID必须仅仅包含小写字母和数字【0-9a-f】并且不带前缀“0x”。

· The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary.

通证的ID必须包含64个十六进制字符，若字符数没有64个，则在字符串前面全部用0填充。

Example of such a URI: https://token-cdn-domain/{id}.json would be replaced with https://token-cdn-domain/000000000000000000000000000000000000000000000000000000000004cce0.json if the client is referring to token ID 314592/0x4CCE0.

URI实例：“https://token-cdn-domain/{id}.json”中有{id}字串，它被实际的通证D（通证ID为“314592/0x4CCE0”）取代后为：

“https://token-cdn-domain/000000000000000000000000000000000000000000000000000000000004cce0.json”

Metadata Extensions 元数据扩展

The optional ERC1155Metadata_URI extension can be identified with the (ERC-165 Standard Interface Detection)[https://eips.ethereum.org/EIPS/eip-165].

ERC1155Metadata_URI扩展是个可选项，它是否被使用可由ERC-165 Standard Interface Detection检测出来。

If the optional ERC1155Metadata_URI extension is included:

如果ERC1155Metadata_URI被使用了：

· The ERC-165 supportsInterface function MUST return the constant value true if 0x0e89341c is passed through the interfaceID argument.

如果ERC-165 supportsInterface接口函数的参数“interfaceID”的值为“0x0e89341c”，则其返回值必须为“true”。

· Changes to the URI MUST emit the URI event if the change can be expressed with an event (i.e. it isn’t dynamic/programmatic).

如果对URI值的改动可以在事件中表达（即这种改动不是通过动态/编程改变的）则这种改动必须触发URI事件。

。An implementation MAY emit the URI event during a mint operation but it is NOT mandatory.

An observer MAY fetch the metadata uri at mint time from the uri function if it was not emitted.

合约的实现代码可以在挖矿操作中触发URI事件，但这不是强制性的。

在挖矿时，如果没有事件触发，用户或许仍然可以从URI函数中获取元数据URI。

· The uri function SHOULD be used to retrieve values if no event was emitted.

如果没有事件触发，要获取数据就要调用URI函数。

· The uri function MUST return the same value as the latest event for an _id if it was emitted.

对同一”_id”，URI函数的返回值必须和最近一次触发的事件返回值一样。

· The uri function MUST NOT be used to check for the existence of a token as it is possible for an implementation to return a valid string even if the token does not exist.

URI函数不能用于检查某个通证是否存在，因为存在这种可能性：一个通证合约的实现代码对一个不存在的通证仍然返回一个有效的字符串。

ERC-1155 Metadata URI JSON Schema ERC-1155元数据 URI JSON框架

This JSON schema is loosely based on the “ERC721 Metadata JSON Schema”, but includes optional formatting to allow for ID substitution by clients. If the string {id} exists in any JSON value, it MUST be replaced with the actual token ID, by all client software that follows this standard.

JSON框架大体上基于“ERC721 Metadata JSON Schema”，但还包括一些可选的格式让用户可以用ID进行替代。如果JSON值里面包含{id}字串，它必须用真实的通证ID替代，其规则如下：

· The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: [0-9a-f] with no 0x prefix.

通证的ID必须仅仅包含小写字母和数字【0-9a-f】并且不带前缀“0x”。

· The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary.

通证的ID必须包含64个十六进制字符，若字符数没有64个，则在字符串前面全部用0填充。

An example of an ERC-1155 Metadata JSON file follows. The properties array proposes some SUGGESTED formatting for token-specific display properties and metadata.

下例为一个ERC-1155 Metadata JSON文件。其属性数组罗列了一些建议使用的格式，这些格式定义了通证的显示属性和元数据。

Localization 本地化

Metadata localization should be standardized to increase presentation uniformity across all languages. As such, a simple overlay method is proposed to enable localization. If the metadata JSON file contains a localization attribute, its content MAY be used to provide localized values for fields that need it. The localization attribute should be a sub-object with three attributes: uri, default and locales. If the string {locale} exists in any URI, it MUST be replaced with the chosen locale by all client software.

元数据的本地化应该有一套标准的做法，这样才能使得不管用什么语言，它的表述方式都是统一的。因此，有人提出了一种简单的覆盖方式。如果metadata JSON文件包含一项“本地化”属性，则这个属性的内容则可能提供了某些应用需要的本地化值。该“本地化”属性应该是一个子对象（sub-object）并且包含三个特性：uri，default（缺省值）和locales（属地）。如果URI中存在{locale}字串，则它必须用真实的属地替代。

JSON Schema JSON框架

Localized Sample 本地化实例

Base URI: 原始URI

es.json: 西班牙语的 es.json

fr.json: 法语的fr.json

Approval 授权

The function setApprovalForAll allows an operator to manage one’s entire set of tokens on behalf of the approver. To permit approval of a subset of token IDs, an interface such as ERC-1761 Scoped Approval Interface is suggested. The counterpart isApprovedForAll provides introspection into any status set by setApprovalForAll.

setApprovalForAll函数让授权者授权其他操作者管理其所有的通证。如果授权者只希望授权部分通证的管理权限则可以使用ERC-1761 Scoped Approval接口。如果想查看setApprovalForAll函数设置的授权状态可以调用isApprovedForAll函数进行查询。

An owner SHOULD be assumed to always be able to operate on their own tokens regardless of approval status, so should SHOULD NOT have to call setApprovalForAll to approve themselves as an operator before they can operate on them.

无论通证是否被授权给他人管理，通证的所有者永远都能管理自己的通证。因此通证的所有者无需调用setApprovalForAll给自己授权就可直接管理通证。

Rationale 基本原理

Metadata Choices 元数据的选择

The symbol function (found in the ERC-20 and ERC-721 standards) was not included as we do not believe this is a globally useful piece of data to identify a generic virtual item / asset and are also prone to collisions. Short-hand symbols are used in tickers and currency trading, but they aren’t as useful outside of that space.

符号（在ERC-20和ERC-721标准中都有）这一项没有被包括在内，因为我们不认为该项数据对标识一个虚拟物品/资产有什么意义并认为它还容易造成冲突。符号多用在标识和数字货币交易中，除此以外它没什么用处。

The name function (for human-readable asset names, on-chain) was removed from the standard to allow the Metadata JSON to be the definitive asset name and reduce duplication of data. This also allows localization for names, which would otherwise be prohibitively expensive if each language string was stored on-chain, not to mention bloating the standard interface. While this decision may add a small burden on implementers to host a JSON file containing metadata, we believe any serious implementation of ERC-1155 will already utilize JSON Metadata.

名称（人类易读的资产命名，属于链上数据）也没有被包含在内，这样做是为了使Metadata JSON成为准确定义资产名称的数据，减少重复的数据，这也可以使命名本地化。否则对每一种语言都要用一个字符串命名并且存到链上，这将会使耗费大得惊人，也会使合约标准的接口臃肿不堪。尽管这样的做法使得合约编写者必须用一个JSON文件存储元数据（metadata），看上去增加了一些负担，但我们认为任何一个严肃的ERC-1155合约编写者都会用JSON Metadata（译者注：作者的意思是即便他们不这样要求，严肃的代码编写者也会提供JSON Metadata）。

Upgrades 升级

The requirement to emit TransferSingle or TransferBatch on balance change implies that a valid implementation of ERC-1155 redeploying to a new contract address MUST emit events from the new contract address to replicate the deprecated contract final state. It is valid to only emit a minimal number of events to reflect only the final balance and omit all the transactions that led to that state. The event emit requirement is to ensure that the current state of the contract can always be traced only through events. To alleviate the need to emit events when changing contract address, consider using the proxy pattern, such as described in ERC-1538. This will also have the added benefit of providing a stable contract address for users.

当发生账户余额变化时，必须触发TransferSingle或TransferBatch。这意味着一个ERC-1155合约的实现代码被部署到一个新的合约地址时必须从新的合约地址触发事件，将老合约的最后状态再次显示。这时只要触发最少数量的事件以反映老合约的最后状态即可，而老合约在变为最后状态之前进行了哪些交易可以忽略不计。对事件触发设计的这个规则是为了保证当前合约的状态永远可以通过过往事件进行追踪。当改变合约地址时，为了减少不必要的事件触发，可以考虑使用代理模式，比如ERC-1538所定义的那样。这样做也是为了能给用户提供一个稳定的合约地址。

Design decision: Supporting non-batch 设计决策：支持非批量交易

The standard supports safeTransferFrom and onERC1155Received functions because they are significantly cheaper for single token-type transfers, which is arguably a common use case.

本标准支持safeTransferFrom和onERC1155Received函数，因为对单一通证的交易调用它们所需的耗费少很多，这应该好理解。

Design decision: Safe transfers only 设计决策：转账必须安全

The standard only supports safe-style transfers, making it possible for receiver contracts to depend on onERC1155Received or onERC1155BatchReceived function to be always called at the end of a transfer.

本标准只支持安全的转账，使接收合约在收到转账后，onERC1155Received或onERC1155BatchReceived函数必须被调用。

Guaranteed log trace 日志追踪有保障

As the Ethereum ecosystem continues to grow, many dapps are relying on traditional databases and explorer API services to retrieve and categorize data. The ERC-1155 standard guarantees that event logs emitted by the smart contract will provide enough data to create an accurate record of all current token balances. A database or explorer may listen to events and be able to provide indexed and categorized searches of every ERC-1155 token in the contract.

随着以太坊生态系统的持续发展，很多DAPP依赖传统的数据库和浏览器提供的API服务获取和分类数据。ERC-1155标准保证其智能合约所触发的事件日志能提供足够多的数据，准确地记录所有通证账户余额的变化。对合约中每一个ERC-1155通证，可以用数据库或浏览器监听所触发的事件，也可以提供经过索引和分类的搜索结果。

Approval 授权

The function setApprovalForAll allows an operator to manage one’s entire set of tokens on behalf of the approver. It enables frictionless interaction with exchange and trade contracts.

setApprovalForAll函数让授权者授权其他操作者管理其所有的通证。它使得交易所交易和合约交易之间完全无障碍。

Restricting approval to a certain set of token IDs, quantities or other rules MAY be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested ERC-1761 Scoped Approval Interface which is compatible with ERC-1155.

如果授权者只希望授权部分通证，通证的部分数量或其它权限的管理则可以另外使用一个接口或外部合约来处理。这样做的基本原理是保证ERC-1155标准尽量通用，在任何情况下都无需在具体的代码实现中编写特殊的授权机制。而且这些具体的代码实现可能根本就不需要这种特殊的授权机制。如果实在需要这种授权可以使用标准的通证授权接口比如ERC-1761 Scoped Approval接口，它和ERC-1155协议是兼容的。

Usage 用法

This standard can be used to represent multiple token types for an entire domain. Both fungible and non-fungible tokens can be stored in the same smart-contract.

本标准可用于定义一个领域内的多种通证类型。同质通证和非同质通证可以共存于同一个智能合约内。

Batch Transfers 批量转账

The safeBatchTransferFrom function allows for batch transfers of multiple token IDs and values. The design of ERC-1155 makes batch transfers possible without the need for a wrapper contract, as with existing token standards. This reduces gas costs when more than one token type is included in a batch transfer, as compared to single transfers with multiple transactions.

safeBatchTransferFrom函数可以同时转账各种数量的各种通证。ERC-1155的设计支持批量转账而无需另外的打包合约（wrapper contract），而现有的其它通证标准要进行批量转账则需要另外的打包合约（wrapper contract）。当系统需要转账多种通证时，传统的做法不得不一笔笔的转账，而ERC-1155的设计使得转账多种通证所需的gas耗费大为降低，。

Another advantage of standardized batch transfers is the ability for a smart contract to respond to the batch transfer in a single operation using onERC1155BatchReceived.

这样设计的另一个好处是ERC-1155智能合约可以用onERC1155BatchReceived这一个操作处理批量转账。

It is RECOMMENDED that clients and wallets sort the token IDs and associated values (in ascending order) when posting a batch transfer, as some ERC-1155 implementations offer significant gas cost savings when IDs are sorted. See Horizon Games - Multi-Token Standard “packed balance” implementation for an example of this.

建议用户和钱包项目方要进行批量转账时，对待转账的所有token ID和每个ID对应的通证数量进行排序（升序排列）。因为ERC-1155标准对进行了排序的通证进行批量转账时会显著降低gas耗费。详细信息请参看“Horizon Games - Multi-Token Standard”章节中的“打包余额（packed balance）”实例。

Batch Balance 批量账户余额

The balanceOfBatch function allows clients to retrieve balances of multiple owners and token IDs with a single call.

balanceOfBatch函数让用户仅仅只需调用这个函数便能获取多个通证所有者及其所持有的通证的余额信息。

Enumerating from events 事件枚举

In order to keep storage requirements light for contracts implementing ERC-1155, enumeration (discovering the IDs and values of tokens) must be done using event logs. It is RECOMMENDED that clients such as exchanges and blockchain explorers maintain a local database containing the token ID, Supply, and URI at the minimum. This can be built from each TransferSingle, TransferBatch, and URI event, starting from the block the smart contract was deployed until the latest block.

为了让ERC-1155合约的实现尽量少地占用存储，枚举（枚举所有的通证ID及每个通证对应的数量）必须用事件日志实现。建议交易所和区块链浏览器项目方在本地保留一个数据库至少记录token ID，供应量和URI这三项信息。数据库的数据可以从TransferSingle，TransferBatch和URI事件中提取，记录的时间可以从智能合约部署的那一刻算起一直记录到最新产生的区块。

ERC-1155 contracts must therefore carefully emit TransferSingle or TransferBatch events in any instance where tokens are created, minted, transferred or destroyed.

ERC-1155合约的编写者在通证被创建，挖矿，交易和销毁时必须小心谨慎地触发TransferSingle和TransferBatch事件。

Non-Fungible Tokens 非同质通证

The following strategies are examples of how you MAY mix fungible and non-fungible tokens together in the same contract. The standard does NOT mandate how an implementation must do this.

下列示范展示了如何在一个智能合约中既定义同质通证也定义非同质通证，但ERC-1155标准并不强制要求编写者必须按该示范编写。

Split ID bits 切分ID的位

The top 128 bits of the uint256 _id parameter in any ERC-1155 function MAY represent the base token ID, while the bottom 128 bits MAY represent the index of the non-fungible to make it unique.

在任何一个ERC-1155函数中，参数”uint256 _id”的前128位都可以（并非一定）被用来定义token ID。而余下的128位可以（并非一定）被用来定义非同质通证的唯一索引。

Non-fungible tokens can be interacted with using an index based accessor into the contract/token data set. Therefore to access a particular token set within a mixed data contract and a particular non-fungible within that set, _id could be passed as <uint128: base token id><uint128: index of non-fungible>.

非同质通证可以用带索引的变量访问。如果一个合约的通证集合中有某个非同质通证，用户可以用”_id”访问该非同质通证，此时”_id”值的构成为<uint128:非同质通证ID><uint128:非同质通证的索引>。

To identify a non-fungible set/category as a whole (or a fungible) you COULD just pass in the base id via the _id argument as <uint128: base token id><uint128: zero>. If your implementation uses this technique this naturally means the index of a non-fungible SHOULD be 1-based.

为了标识一个非同质通证集合/类别，你可以将参数“_id”的值设为<uint128:非同质通证ID><uint128:0>。如果合约的代码实现使用了这个技巧，则意味着一个非同质通证的索引基于“1”（1-based）。

Inside the contract code the two pieces of data needed to access the individual non-fungible can be extracted with uint128(~0) and the same mask shifted by 128.

在合约中，访问一个非同质通证需要两部分数据（译者注：即高128位数据和低128位数据），这两部分数据可以分别用uint128(~0)和128位移位运算获得。

Note that 128 is an arbitrary number, an implementation MAY choose how they would like this split to occur as suitable for their use case. An observer of the contract would simply see events showing balance transfers and mints happening and MAY track the balances using that information alone. For an observer to be able to determine type (non-fungible or fungible) from an ID alone they would have to know the split ID bits format on a implementation by implementation basis.

注意：128不是个固定值，合约编写者可以自己选择合适的方式来划分这256位的用途。用户只需要能从合约触发的事件中看到转账交易和挖矿发生就行了，当然用户也可以通过这些事件追踪余额的变化。如果用户希望从ID中判断转账的通证类型（同质通证或非同质通证）则需要研究合约的实现代码是如何划分ID数位的用途的。

The ERC-1155 Reference Implementation is an example of the split ID bits strategy.

ERC-1155参考案例展示了如何划分ID的数位用途。

Natural Non-Fungible tokens 自然的非同质通证

Another simple way to represent non-fungibles is to allow a maximum value of 1 for each non-fungible token. This would naturally mirror the real world, where unique items have a quantity of 1 and fungible items have a quantity greater than 1.

有一个简单表示非同质通证的方法：对每一个非同质通证尽量用“1”来定义。这是对真实世界最自然的映射。在真实世界中每一个唯一的事物有且仅有一个，而每一种同质通证则有多个。

References 参考

Standards 标准

ERC-721 Non-Fungible Token Standard

ERC-165 Standard Interface Detection

ERC-1538 Transparent Contract Standard

JSON Schema

RFC 2119 Key words for use in RFCs to Indicate Requirement Levels

Implementations

ERC-1155 Reference Implementation

Horizon Games - Multi-Token Standard

Enjin Coin (GitHub)

The Sandbox - Dual ERC-1155/721 Contract

Articles & Discussions

Github - Original Discussion Thread

ERC-1155 - The Crypto Item Standard

Here Be Dragons - Going Beyond ERC-20 and ERC-721 To Reduce Gas Cost by ~80%

Blockonomi - Ethereum ERC-1155 Token Perfect for Online Games, Possibly More

Beyond Gaming - Exploring the Utility of ERC-1155 Token Standard!

ERC-1155: A new standard for The Sandbox

Copyright

Copyright and related rights waived via CC0.

启发

1. 除了为多个通证提供标准接口外，ERC-1155还带来其它重要好处：

   • 通过将多个复杂的操作打包到一个交易中，它将使交易更便宜；

   • 它能组合多个通证并启用原子交换（勿需第三方）；

   • 它将大大提高以太坊网络的效率；

   • ERC-1155允许开发人员将一组通证的代码存储在一个智能合约中，并在需要时被其他智能合约所调用。 简而言之，它可被充分地重复利用，而不是像现在其它标准下的不断复制代码部署新合约。 可想而知，这将大大减少以太坊的存储空间和算力。\

2. 因为智能合约能够保证收益无法被侵犯，知识产权、版权等概念，可能在区块链领域将无存在的必要。

最后

请多关注：https://nonfungible.com/

添加一种新的交易类型，在执行过程中为EOA设置代码

摘要

新增一种交易类型，添加一系列 [chain_id, address, nonce, y_parity, r, s] 授权元组。对于每个元组，向签名账户的代码写入一个委托设计器 (0xef0100 ++ address)。所有读取代码的操作必须加载设计器所指向的代码。

动机

人们对为外部账户（EOAs）增加短期功能改进非常感兴趣，这可以提高应用的可用性，并在某些情况下提升安全性。特别的三个应用包括：

批处理：允许同一用户在一个原子交易中进行多个操作。一个常见的例子是 ERC-20 授权后跟随的支出，这在去中心化交易所（DEX）中是一个常见的工作流程，目前需要两个交易。批处理的高级用例偶尔涉及依赖关系：第一个操作的输出是第二个操作的输入的一部分。 赞助：账户 X 代表账户 Y 支付一个交易。账户 X 可以用其他 ERC-20 代币获得这项服务的报酬，或者可以是一个应用程序运营商为其用户免费处理交易。 权限降级：用户可以签署子密钥，并给予它们特定的权限，这些权限远低于对账户的全局访问权限。例如，可以想象一种权限，允许支出 ERC-20 代币但不允许支出 ETH，或者每天支出总余额的 1%，或者仅与特定应用程序进行交互。

技术规范

参数

设置代码交易

我们引入了一种新的EIP-2718交易，即“设置代码交易”，其中 TransactionType（交易类型）为SET_CODE_TX_TYPE，并且 TransactionPayload （交易装载）是以下内容的RLP序列化：

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

外部交易的字段 chain_id、nonce、max_priority_fee_per_gas、max_fee_per_gas、gas_limit、destination、value、data 和 access_list 遵循 EIP-4844 的相同语义。请注意，这意味着空的（null） destination 是无效的。

authorization_list 是一个元组列表，存储（即提供）签名者希望在其 EOA 的应用场景中执行的地址与代码。如果 authorization_list 的长度为零，交易将被视为无效。

当授权元组（authorization tuple）中的任何字段无法在以下范围内时，该交易也被视为无效：

assert auth.chain_id < 2**256
assert auth.nonce < 2**64
assert len(auth.address) == 20
assert auth.y_parity < 2**256
assert auth.r < 2**256
assert auth.s < 2**256

此交易的 EIP-2718 ReceiptPayload为 rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])（分别对应：状态, 累计交易gas值, 日志_布隆, 日志）。

行为

在执行交易开始时，在增加发送者的nonce后，对于每个[chain_id, address, nonce, y_parity, r, s]元组，执行以下操作：

1. 验证链ID是0或当前链的ID。

2. authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]

3. 将authority添加到accessed_addresses（如EIP-2929中定义）。

4. 验证authority的代码要么为空，要么已经被委托。

5. 验证authority的 nonce 等于 nonce。

6. 如果authority存在于trie（前缀树）中，则将PER_EMPTY_ACCOUNT_COST - PER_AUTH_BASE_COST的gas添加到全局退款计数器中。

7. 将authority的代码设置为0xef0100 || address。这是一个委托标识。

8. 将authority的nonce增加1。

如果上述任何步骤失败，立即停止处理该元组，并继续处理列表中的下一个元组。在多个元组对应同一authority的情况下，将使用最后一个有效出现的地址设置代码。

请注意，授权元组的签名者可能与交易的tx.origin不同。

代理（授权）指示

代理指示使用了EIP-3541中禁止的操作码0xef，以指定代码具有特殊用途。这个指示要求所有检索代码操作都遵循地址指针，以填充可观察的账户代码。受影响的指令包括：EXTCODESIZE、EXTCODECOPY、EXTCODEHASH、CALL、CALLCODE、STATICCALL和DELEGATECALL。

例如，EXTCODESIZE将返回由 address（地址）指向的代码的大小，而不是代表代理指示的 23。CALL 将类似地从 address加载代码，并在 authority（授权）的应用场景中执行它。

如果一个代理指示者指向另一个指示者，形成潜在的指示者链或循环，客户端必须只检索第一个代码，然后停止跟随指示者链。

gas费用

新交易的内在成本继承自EIP-2930，具体为21000 + 16 * 非零calldata字节 + 4 * 零calldata字节 + 1900 * 访问列表存储键计数 + 2400 * 访问列表地址计数。此外，我们还增加了一个费用，费用为PER_EMPTY_ACCOUNT_COST * 授权列表长度。

交易发送者将为所有授权元组支付费用，无论其有效性或重复性。

如果代码读取指令在解析代表授权代码时访问一个冷账户，则在正常费用上增加2600 gas的EIP-2929 COLD_ACCOUNT_READ_COST费用，并将账户添加到accessed_addresses中。否则，评估100的WARM_STORAGE_READ_COST费用。

交易来源

修改 EIP-3607 所施加的限制，以允许其代码是有效的代表授权设计（即0xef0100 || address）的外部拥有账户（EOAs）继续发起交易。任何其他代码值的账户均不得发起交易。

理由

无初始化代码

（注：Initdode是创建"存储在链上的字节码"的代码。 即通常指的是使用create2操作码时需要的字节码。此处翻译为“初始化代码”） 许多原因使得执行初始化代码并不理想。主要的担忧是它不自然。初始化代码的目的是初始化和部署合约。根据这个EIP，它将承担一个新的角色，以决定是否适合将代码部署到外部账户（EOA）。假设用户只希望在交易的普通调用数据中有相关操作时，代码被部署到他们的账户。这赋予了EOA独特的权力，控制代码在他们账户中何时以及执行什么。虽然EIP-7702如其所写仍在某种程度上允许这样做，但决策缺乏可编程性将迫使钱包不签署许多授权元组，而是专注于只签署指向可配置代理的元组。这使得EOA体验类似于智能合约钱包 。

此外，交易中的初始化代码倾向于在交易内部传播。这意味着它需要包含在授权元组中并进行签名。最小的初始化代码大约为15字节，仅仅是将合约代码从外部地址复制过来。总成本大约为 16 * 15 = 240 的调用数据成本，加上 EIP-3860 的成本 2 * 15 = 30，再加上大约150的运行时成本。因此，光是准备账户就将花费近500额外的 gas；如果没有从外部账户复制，可能成本更高，达到1200+的 gas。

通过模板创建

不论是否有初始化代码（Initcode），用户如何指定他们打算在账户中运行的代码也是一个问题。两个主要选项是直接在交易中指定字节码或指定指向代码的指针。最简单的指针就是链上某段代码的地址。

成本分析使答案变得明晰。最小的代理大约为50字节，而地址为20字节。30字节的差距并未提供任何有用的附加功能，并且将在链上低效地复制数十亿次。

此外，直接指定代码的方式将再次使得EOA能够拥有新的独特能力，在交易调用数据中执行任意指定的代码。

缺乏指令禁止

从实现的角度和用户理解的角度来看，一致性都是以太坊虚拟机（EVM）的一个重要属性。虽然在外部账户（EOA）的应用场景中考虑过对几类指令的禁令，但作者认为没有足够的理由去这样做。这将迫使智能合约钱包和EOA智能合约钱包走上不同的合约开发道路。

可以建立禁令的主要指令家族是与存储相关的指令和与合约创建相关的指令。我们决定不禁止存储指令主要基于其对智能合约钱包的重要性。尽管可以有一个外部存储合约供智能合约钱包调用，但这效率不高。在未来，新的状态方案甚至可能允许以更低的成本访问某些存储槽。智能合约钱包非常希望利用这一点，而存储合约则无法支持。

创建指令在其他类似EIP的情况下曾被考虑禁止，但由于这个EIP允许EOA在交易内花费价值，因此在交易内增加nonce并使待处理交易失效的担忧并不大。一个有趣的附带效果是，通过结合EIP-7702和CREATE2，可以在不承诺任何费用市场参数的情况下，承诺将特定的字节码部署到一个地址。这解决了长期以来的跨链合约部署的普遍问题。

创建指令在其他类似的以太坊改进提案（EIP）中曾被考虑禁用，然而由于该EIP允许EOA在交易内花费价值，因此在交易内递增 nonce 并使得待处理交易失效的问题并不显著。一个有趣的附带效果是，通过结合 EIP-7702 和 CREATE2，可以在不提交任何费用市场参数的情况下，保证在特定地址部署特定的字节码。这解决了长期以来跨链合约部署的普遍问题。

签名结构

这个EIP中的签名方案支持灵活的设计模式，可以实现地址 address 的全权委托和更受保护的地址 address委托。

代码指针

在签署代码指针时需要考虑的一个因素是该地址在另一条链上可能指向什么代码。在某些情况下，验证部署是否是确定性的可能并不是很必要。在这种情况下，可以设置链 ID 以减少授权的范围。对于其他更倾向于普遍部署的情况，例如，委托给钱包代理。在这些情况下，可以将链 ID 设置为 0，以便在所有 EIP-7702 链上都具有效力。钱包维护者将能够将一个单一的 EIP-7702 授权消息硬编码到他们的钱包中，这样跨链代码可塑性就不会成为问题。

添加链 ID 的另一种选择是对地址指向的代码进行签名。这似乎在保留账户中实际运行的代码的特定性同时，最大限度地减少了链上认证元组的大小。然而，这种格式的一大缺点是它要求进行数据库查找，以确定每个认证元组的签名者。这种要求本身似乎在交易传播中产生了足够的复杂性，因此决定避免这种情况，直接对地址进行签名。

协议内撤销

与该 EIP 之前的版本以及类似的 EIP 不同，委托指定可以随时通过签署并发送一条带有账户当前 nonce 的新目标的 EIP-7702 授权来撤销。如果不采取此类行动，委托将永久有效。

自费：允许 tx.origin 设置代码

允许 tx.origin 设置代码可以简化交易批处理，外部交易的发送者将成为签署账户。目前，ERC-20 的批准后转账模式需要两笔单独的交易，而通过这一提案，可以在一笔交易中完成。

一旦代码存在于外部拥有账户（EOA）中，任何时候该 EOA 的代码发起调用时，自费的 EIP-7702 交易都可以使 msg.sender == tx.origin。在没有 EIP-7702 的情况下，这种情况只能出现在交易的最顶层执行层。因此，该 EIP 打破了这一不变性，因此会影响包含 require(msg.sender == tx.origin) 检查的智能合约。该检查主要用于至少三个目的：

1. 确保 msg.sender 是一个 EOA（因为 tx.origin 总须是 EOA）。这个不变性不依赖于执行层的深度，因此不受影响。

2. 防范像闪电贷这样的原子性三明治攻击，这种攻击依赖于在执行目标合约之前和之后修改状态的能力，作为同一原子交易的一部分。这个保护将被此 EIP 打破。然而，以这种方式依赖 tx.origin 被视为不好的实践，并且已经可以通过矿工有条件地将交易包含在区块中来规避。（译者：道易程的核心合约开发者Elon提交过一个防范闪电贷攻击的EIP。）

3. 防止重入攻击。

(1) 和 (2) 的例子可以在以太坊主网部署的合约中找到，其中 (1) 更常见（且不受此提案影响）。另一方面，用例 (3) 受到此提案的更大影响，但该 EIP 的作者未发现任何这种形式的重入保护示例，尽管搜索并不全面。

这种情况——很多 (1)，一些 (2)，没有 (3)——正是该 EIP 的作者所预期的，因为：

• 在没有 tx.origin 的情况下确定 msg.sender 是否为 EOA 是困难的（如果不是不可能的话）。

• 唯一一个安全的原子性三明治攻击执行环境是最顶层的环境，而 tx.origin == msg.sender 是检测该环境的唯一方法。

• 相比之下，有许多直接且灵活的方法来防止重入（例如，使用瞬态存储变量）。由于 msg.sender == tx.origin 只有在最顶层环境中为真，因此和其他更常见的方法，它是防止重入的冷门的工具。

还有其他方法可以减轻这种限制而不破坏不变性：

• 在 EOA 的应用场景中使用 CALL* 指令时，将 tx.origin 设置为一个常量 ENTRY_POINT 地址。

• 将 tx.origin 设置为从发送者或签字者地址派生的特殊地址。

• 禁止 tx.origin 设置代码。这将使简单批处理的用例变得不可能，但将来可以放宽。

未来账户抽象的向前兼容性

该 EIP 旨在使得最终的账户抽象技术方案高度向前兼容，而不过度依赖 ERC-4337 或 RIP-7560 的任何细节。

具体而言：

• 用户签名的地址address 可以直接指向现有的 ERC-4337 钱包代码。

• 所使用的“代码路径”在许多情况下（尽管可能并非全部）在纯智能合约钱包世界中“仍然有意义”。

• 因此，它避免了“创建两个独立代码生态系统”的问题，因为在很大程度上，它们将是同一个生态系统。在这个解决方案下，确实有一些工作流程需要采取权宜之计，而在“最终账户抽象”下做得会更好，但这相对是一小部分。

• 它不需要添加任何操作码，这些操作码在后 EOA 世界中会变得无用。

• 它允许 EOA 伪装成合约以便被包括在 ERC-4337 包中，这种方式与现有的 EntryPoint 兼容。

向后兼容性

这个EIP打破了账户余额只能因来自该账户的交易而减少的规则。它还打破了在交易执行开始后EOA nonce不能增加的规则。这些破坏对内存池设计和其他EIP（如包含列表）都有影响。不过，由于账户在外部交易中是静态列出的，所以可以修改交易传播规则，以便不会转发冲突的交易。

安全考虑

安全代理

以下是代理合约需要谨慎注意的检查或陷阱或条件的非详尽清单，并需要获取账户授权的签名：

• 重放保护——（例如一个nonce）应该由代理方实现并签名。如果没有，恶意行为者可以重复使用签名，重复其影响。

• value—— 如果没有，恶意赞助商可能会导致被调用函数（callee）出现意想不到的效果。

• gas——如果没有，恶意赞助商可能会导致被调用方（callee）耗尽 gas 而失败，从而给被赞助方带来麻烦。

• target / calldata——如果没有，恶意行为者可能会在任意合约中调用任意函数。

实现不佳的委托代理可能让恶意行为者几乎完全控制签名者的EOA。

将代码设置为 tx.origin

允许EIP-7702的发送方也设置代码，可能会：

• 破坏依赖于 tx.origin 的原子三明治保护；

• 破坏类型为 require(tx.origin == msg.sender) 的重入保护。 该EIP的作者认为，出于理由部分所述的原因，允许这样做的风险是可以接受的。

赞助交易中继者

授权账户可以使赞助交易中继者支付 gas，而无需通过无效化授权（即增加账户的 nonce）或将相关资产转出账户来获得补偿。中继者（relayers）的设计应考虑这些情况，可能需要存入保证金或实施声誉系统。

前置运行初始化

智能合约钱包开发者必须考虑在未执行的情况下设置账户代码的影响。合约通常是通过执行初始化代码来部署的，以确定要放入账户的确切代码。这使得开发者有机会同时初始化存储槽。账户的初始值不能被观察者替换，因为它们要么在创建交易的情况下由外部账户（EOA）签名，要么通过从初始化代码的哈希中确定合约地址来提交。

该 EIP 并未给开发者提供在委托代理期间运行初始化代码和设置存储槽的机会。为了防止观察者通过控制的账户前置运行委托的初始化，智能合约钱包开发者必须验证初始的 calldata 由 EOA 的密钥使用 ecrecover所做的签名。这确保账户只能用期望的值进行初始化。

交易广播

允许 EOA 通过委托指定的方式表现得像智能合约，会给交易广播带来一些挑战。传统上，EOA 只能通过交易发送价值。这一不变性使节点能够静态地确定该账户交易的有效性。换句话说，单个交易只能使发送者账户的待处理交易失效。

通过这个 EIP，可能会导致其他账户的交易变得过时。这是因为一旦 EOA 委托给代码，该代码可以在交易的任何时刻被任何人调用。以静态方式判断账户的余额是否被转移变得不可能。

虽然有一些缓解措施，作者建议客户端对任何具有非零委托指定的 EOA 不接受超过一个待处理交易。这最小化了单个交易可能导致的交易失效的数量。另一种选择是扩展 EIP-7702 交易，附带调用者希望在交易过程中“激活”的账户列表。这些账户在包括它们的 EIP-7702 交易中仅表现为委托代码，从而使客户端能够静态分析和推理待处理交易。

一个相关的问题是，EOA 的 nonce 可能在每个交易中递增多次。由于客户端已经需要在更糟糕的情况下保持稳健（如上所述），这应该并非一个多大的安全注意事项。然而，客户端应意识到这种行为是可能的，并相应地设计他们的交易广播。

版权

通过 CC0 放弃版权及相关权利。

引用

请将此文献引用为： Vitalik Buterin (@vbuterin), Sam Wilson (@SamWilsn), Ansgar Dietrichs (@adietrichs), Matt Garnett (@lightclient), "EIP-7702: Set EOA account code [DRAFT]," Ethereum Improvement Proposals, no. 7702, May 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7702.

账户抽象化（Account Abstraction）的历史

EIP-86

账户抽象化这个概念是在 2017 年2月 Vitalik Buterin 的 EIP-86 里首次提出的，其目的是实现 “交易来源和签名的抽象”。不过其动机和想法可以追溯到 2016 年年初 vitalik 提交的一个 issue， 文中建议 “与其将 ECDSA 签名算法和默认的 nonce 机制写死在协议内作为 ‘标准’ 的账户安全机制，不如初步建立一个（统一的）账户模型，在未来把所有的账户都变成合约，让合约可以支付 gas，让用户可以自由定义自己的安全模型。”

Rationale

The goal of these changes is to set the stage for abstraction of account security. Instead of having an in-protocol mechanism where ECDSA and the default nonce scheme are enshrined as the only "standard" way to secure an account, we take initial steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model.

什么是天才？凭借直觉就能预判准未来，那他就是！

前面有关章节已经介绍以太坊有两种类型的账户：

• 外部账户（Externally Owned Account, EOA）

• 合约账户（Contract Account, CA）。

前者由用户私钥控制，而后者由存储在智能合约账户（有时也被称为智能钱包）内的合约代码控制。

外部账户的权限要大于合约账户，因为只有外部账户可以通过支付 gas 启动交易的执行过程（即与智能合约交互）。

随着实践经验与教训的积累，钱包用户开始对外部账户产生一些担忧。这些担忧包括：

1. 严重依赖人工：由于账户访问完全依靠私钥，且所有交易均需动用私钥进行签名，即转账和实施智能合约操作的唯一方法是人工操作（使用私钥），在全天无休的区块链行业，这就实在太不方便。甚至完全可以说手段太落后了。

2. 私钥管理问题：既然私钥决定一切，对于如何安全存储私钥以及谁有权访问它，就会给用户带来极困难和极具压力的挑战——如果有50亿地球人都得日常使用私钥，因私钥掌控Money，那么每天必定有大量私钥的遗失和泄露事件发生！如果不泄露就绑架就凶杀……

3. 依赖椭圆曲线签名（ECDSA加密算法）：已经有专业团队发出外部账户采用的ECDSA加密算法会在不久的将来被破解的预警！抗量子的数字签名是对当前 ECDSA 的必要改进，并且可以说迫在眉睫！该提案可以让用户升级至更安全的加密算法。但能否顺利升级，能否赶在被破解前完成升级换代，目前看起来胜算都不大！……那咋办呢？

4. 一对一的操作：一次不能执行多个操作。否则会产生不必要的成本和糟糕的用户体验。外部账户一点都不好玩！

值得思考的是，Vitalik 这个提案的核心思想，是在遥远的未来，已经没了外部账户而所有的账户均为合约账户，让合约账户可以支付gas，所有人都不用应对与私钥相关的安全问题。

EIP-2938: Account Abstraction

改造链上交易类型的 EIP-86 给大家带来了巨大的启迪，类似它的方案此后又出现了EIP-101、EIP-208、EIP-859、EIP-2718。

2020年，Vitalik 等人提出了 EIP-2938 草案，该草案概述了一个更简单的实现。这个实现对协议/共识的改动最小，并且通过设置节点的内存池规则来满足所需的安全保证——开发小组的动机是将它“封装”到以太坊共识层（Consensus Layer），而非像通证标准ERC-20那样，仅仅只是提供一个在智能合约层面应用的技术标准。

EIP-2938 提出的账户抽象化（Account Abstraction, AA）是一个可以让合约账户成为和外部账户一样的 “顶层” 账户的提案。具体来说，这个方案要求对以太坊协议进行修改，并允许从合约（每个智能合约都有一个合约账户），而不仅仅是外部账户来发起以太坊交易。合约本身将具备验证和矿工需验证的gas费用支付逻辑。那么也就是说，实现了账户抽象化之后，合约账户也可以发起交互请求并支付交易费。

而实际的应用场景更复杂，考虑到遥远的未来可以说细思极恐：EIP-2938通过账户抽象化来为以太坊提供一个基础功能层，以确定何时支付，谁来支付以及怎样支付 gas——简单地说，这是一个以改造链上主体对象为核心的解决方案。如果你还没感觉，那就仔细看完（特别是ERC-4337）。

EIP-2938可以让更多通用型钱包或者其它应用的智能合约执行复杂的逻辑。譬如没有EIP-2938，你想把所有代币都放到一个新钱包里，然后你一不小心先把所有 ETH 都发送到这个新钱包里了。马上，你会尴尬地发现你的旧钱包因为没有 ETH 而无法发送任何交易，剩下的代币无法转移到新钱包。账户抽象化能让你使用其它合约地址（如智能合约钱包）里的 ETH 支付 gas 费用（这种情况叫代付交易，Sponsored Transactions），甚至还可以让你使用旧钱包里的其它代币支付 gas 费用。当然，这只是一个很容易理解的示例，实际的应用还可以复杂很多倍。

EIP-3074: AUTH and AUTHCALL opcodes...

EIP-3074 主要的技术创新是向 以太坊虚拟机（EVM） 添加两个新的操作码：AUTH 和 AUTHCALL，它们旨在被称为“调用者”的智能合约使用。这些调用者获得了对授权他们的外部账户 EOA 的控制权，并可以代表他们进行调用。

这也就是说，用户可使用私钥对包含其意图的消息进行签名。然后，该消息被包含在调用程序的链上交易中。调用者使用签名消息和 AUTH 操作码来控制用户的外部帐户，并且使用 AUTHCALL 代表用户去执行操作。

要注意的是，包含用户签名消息的交易不一定必须从该用户的帐户发送，这使用户完全不必依赖 ETH 来发送交易。事实上，还可以通过其他方式支付费用，例如使用道易程创建的伟大的价格单位制里面的那个叫做uToken的 ERC-20 代币。

这种方法有几个问题，主要是认为赋予调用者如此大的权力会导致类似于 DAO 黑客攻击的灾难性事件。

之后的EIP-3607、EIP-5003基本沿袭了 EIP-3074 的内核思想。

ERC-4337: Account Abstraction Using Alt Mempool...

1. ERC-4337 看上去与EIP-2938类似，但ERC-4337是无需更改任何共识层即可在协议上实现账户抽象的技术标准。它显然是更好的解决方案。EIP-4337最早于2021年提出，已经于2023年3月被部署到以太坊主网，可实现在单个合约账户中进行交易和创建合约。

2. ERC-4337 的核心技术创新是用一个被称为 UserOperation 的更高层伪交易对象，取代了 transaction ，而它本身则是一个描述一个 transaction 结构体。你可以理解为 ERC-4337 为以太坊在 transaction 基础上，新创了另一种交易形式。或者说比特币只有一种办法交易，而以太坊现在有了另一种更复杂也更高效的形式完成交易。以太坊对比特币的超越是全面的！并且，把这个场景放到智能合约的应用里去考虑就叫细思极恐。是的，我词穷了，你能理解就好！

3. validateUserOp：它接受一个 UserOperation 作为输入。这个函数应该验证UserOperation上的签名和nonce，如果验证成功则支付费用并增加nonce，如果验证失败则抛出异常。

4. op执行功能：将calldata解释为钱包采取行动的指令。这个函数如何解释calldata以及它的结果是完全开放的；但我们预计最常见的行为是将calldata解析为钱包的一个或多个调用。

5. 捆绑者(Bundler)将这些对象打包成一笔交易，纳入到一个区块当中。捆绑者支付捆绑交易的燃料费，但收取单独执行UserOperation的费用。捆绑者与验证者的工作方式类似，即根据费用优先等级逻辑选择要纳入的对象。任意捆绑者均可参与到流程当中。

6. 为了简化钱包的逻辑，确保安全所需的大部分复杂智能合约技巧不是在钱包本身中完成的，而是在称为入口点的全局合约中完成的。validateUserOp 和执行函数预计将使用 require(msg.sender == ENTRY_POINT) 进行门控，因此只有受信任的入口点才能使钱包执行任何操作或支付费用。入口点仅在 validateUserOp 之后对钱包进行任意调用，并且携带该调用数据的 UserOperation 已经成功，因此这足以保护钱包免受攻击。如果钱包不存在，入口点还负责使用提供的 initCode 创建钱包。

7. 启用创新用例：包括聚合签名、每日交易限额设置、账户紧急冻结、白名单设置以及保护隐私的应用程序等。

ERC-4337的优缺点

ERC-4337可实现的一些亮点：

1. 钱包设置——无需写下助记词。只需轻点几下，即可快捷轻松地进行设置。

2. 账户恢复——用户无需再担心丢失助记词，现已可以实现多重身份验证和账户恢复。

3. 易于使用的钱包功能——用户可以享用非常丰富的定制服务，包括自动支付、预先批准交易和捆绑交易。至于还有什么功能，完全取决于你写的智能合约。

4. 更高的安全性——降低人为出错的几率，钱包将能够更加安全。

5. 更灵活的gas支付方式——由ERC-4337提供支持的钱包可用任意ERC-20代币、EIP-3712代币和未来其它币种支付gas。

ERC-4337的缺点：

最突出的一点就是因为其复杂性增加，需要更高的Gas成本：基本的ERC-4337操作约需要42000 gas，而常规交易需要 21000 gas，原因如下：

1、需要支付大量的单个存储读/写成本，在 EOA 的情况下，这些成本会捆绑到一笔 21000 gas 的付款中： （1）编辑包含 pubkey+nonce (~5000) 的存储 slot； （2）用户操作调用数据成本（约 4500，通过压缩可减少到约 2500）； （3）ECRECOVER (~3000)； （4）首次访问钱包本身 (~2600) （5）首次访问收款人账户 (~2600) （6）将 ETH 转入收款人账户 (~9000) （7）编辑存储以支付费用（~5000） （8）访问包含代理 (~2100) 的存储 slot，然后访问代理本身 (~2600)；

2、除了上述存储读/写成本之外，合约还需要执行 “业务逻辑”（解包 UserOperation、对其进行哈希、洗牌变量等）

3、需要消耗 gas 来支付日志费用（EOA 不发布日志）；

4、一次性合约创建成本（约 32000 gas，加上代理中每个 code byte 200 gas，再加上设置代理地址的 20000 gas） 简而言之，账户抽象地址的每一步都需要计算，需要消耗更多的资源，也增加了额外的费用。

ERC-5189

还没完？

ERC-5189 显然是受 ERC-4337 的启发而创建的，但它卡顿了。如果你对技术感兴趣可以点击链接去看看。

RIP-7560: Native Account Abstraction

Title为Native Account Abstraction，意味着和 EIP-2938 一样，它是一个“封装”到以太坊共识层的技术提案。

RIP-7560 简介里的第一句话为：

Combining the EIP-2938 and ERC-4337 into a comprehensive Native Account Abstraction proposal.

该提案的意图，是引入共识层协议变更的原生账户抽象（Native Account Abstraction），并将 EIP-2938 和 ERC-4337 合并为一个全面的账户抽象提案。

它是以EIP-4337, EIP-6780为基础。

EIP-7701: Native Account Abstraction with EOF

EIP-7701 有个小标题：A variant of RIP-7560 transactions relying on EOF Smart Contract Accounts

它是以EIP-3540为基础。

EIP-7702: Set EOA account code for one transaction

它有个令人惊讶的小标题：Add a new tx type that sets the code for an EOA during one transaction execution。

它的简介也令人惊讶：

Add a new transaction type that adds a contract_code field and a signature, and converts the signing account (not necessarily the same as the tx.origin) into a smart contract wallet for the duration of that transaction. Intended to offer similar functionality to EIP-3074.

看似简单，但一石惊起千层浪！

EIP-7702 提出了一种同时接受 contract_code 和签名字段的新交易类型，在开始执行交易时，它将签名者账户的合约代码设置为 contract_code。在交易结束时，它会将代码重新设置为空。

EIP-7702和 EIP-3074 一样，实现了 EOA 对智能合约的临时委托功能。然而 EIP-7702 并没有引入新的操作码（这需要硬分叉），而是定义了要调用的函数：

AUTH -> 调用“verify”（验证）

AUTHCALL -> 调用“execute”（执行）

具体来说，它：

* 检查你的账户合约代码是否为空；
* 如果为空，则设置为提供的合约代码；
* 根据提供的智能合约处理交易的方式执行交易；
* 将账户合约代码设置恢复为空。

由此可见，EIP-7702 能够达成与 EIP-3074 同样的核心功能，如批量交易和交易赞助，增强了交易类型的复杂性和控制策略的灵活性。这也就是说，EIP-7702 允许外部拥有账户（EOAs）在交易中临时扮演智能合约钱包的角色，使得 EOAs 可以执行以前只有智能合约才能进行的复杂操作，极大地增强了 EOAs 的功能性和灵活性。通过引入 contract_code 字段，EOAs 可以在交易中动态地引入智能合约代码，实现在单一交易中完成多种操作，如批量处理和复杂的交易指令，从而简化流程并降低交易成本，同时减少了操作复杂性。

其次，EIP-7702 还引入了一种新的权限管理机制，即权限降级。这使得账户持有者可以为其子密钥分配具体权限，从而增强了账户的安全性。通过细粒度的权限控制，用户可以限制子密钥的操作范围，防止未授权的交易和滥用行为，旨在保护用户资金安全，这对于防止未授权的交易和滥用具有重要意义。

EIP-7702 相比 EIP-3074 的优势是，它与EIP-4337 构建的所有账户抽象工作高度兼容，“用户需要签名的合约代码实际上可以是现有的 EIP-4337 钱包代码”。

一旦此项改动生效，用户现有的 EOA 就可以执行任何智能合约代码。通过额外的 EIP，EOA 还可以永久升级以运行特定的代码。

创新

账户抽象化为包括新型钱包在内的区块链dApp的创新设计打开了新的思路。也许有助于下列技术方案的实施：

• 多签和账户的社交恢复

• 验证逻辑灵活性——更高效和更简洁的签名算法（如：Schnorr, BLS）

• 执行层量子安全与后量子安全签名算法（如：Lamport, Winternitz）

  如果EIP-2938这样的提案得到普遍采用，则无需为量子安全在执行层做进一步的工作。用户可将钱包自行升级到量子安全的版本。甚至连封装交易（wrapper transaction）也是安全的。矿工可以为每个捆绑交易使用新创建的EOA，由于是新创建的，所以每个交易都受到哈希保护，更保证了安全性。并且，在矿工将交易添加到区块中之前不会发布该交易。 对于其它方案，则始终要考虑到外部账户的加密算法，能够被量子攻击所破解！

• 钱包可升级性及其执行逻辑灵活性

  钱包验证逻辑可以是有状态的，因此钱包可以更改其公钥或（譬如如果使用DELEGATECALL发布）完全升级其代码。

  钱包可以为执行步骤添加自定义逻辑，例如进行原子多操作（这是EIP 3074的一个关键目标）。

• EIP-7702提议对以太坊协议进行一系列更改，以实现账户抽象。其关键思想是引入一种称为“用户操作”的新交易类型。与普通交易不同，用户操作不是通过签名进行身份验证的。相反，它们是由与账户关联的智能合约钱包进行身份验证的。

  当用户操作提交到网络时，首先会发送到关联的智能合约钱包。然后，钱包根据自己的验证逻辑验证操作。如果验证成功，则钱包向用户操作的目标发送普通交易。

  这一过程允许更灵活地验证交易。例如，智能合约钱包可以要求在执行交易之前进行多重签名，或者可以使用链下数据（如生物识别验证的证明）来验证交易。

  EIP-7702还引入了“支付主合约”的概念。这些是可以为用户操作赞助gas费用的合约。这意味着只要有一个愿意支付其gas费用的支付主，用户就可以与以太坊进行交互，而无需持有任何ETH。

• 智能合约的应用升级 这句话需要你自己去想象……

技术改进的根本动机

账户抽象化背后的动机很简单，但会带来根本性的改变：当前，以太坊交易具备功能可编程性（通过调用智能合约实现），但是交易的验证方式却是固定的。只有持有有效的 ECDSA 签名、有效的 nonce 值以及足够的账户余额，一笔交易才算有效。账户抽象化引入了一种新的交易类型 —— 抽象账户交易（AA Transaction）。这种交易总是由一个特殊地址产生，协议不会检查其签名，nonce 和余额。通过引入这种交易，账户抽象化实现了从固定验证方式到可编程验证方式的转变。抽象账户交易的有效性由其 target 字段指定的智能合约验证，通过验证之后，合约可以自行为该交易支付手续费。

我们业已看到，随着技术探讨的深入，一个小小的突破口，带来了很大的一个未来世界！

这就叫创新！并且它对于区块链未来的发展极为重要！

小结

1. EIP-86、EIP-101、EIP-859、EIP-2718、EIP-2938、EIP-3074、EIP-3607、EIP-4337、EIP-5003、EIP-5189，RIP-7560……其中EIP-86、EIP-2938、EIP-4337、RIP-7560都是 Vitalik 领衔制订，前后耗费七八年时间。创新不易！

2. 以太坊封装 ERC-4337？ 对于开发者来说，这是值得重视和学习的！ 请仔细阅读以太坊是否应该封装更多功能？（注意“封装 ERC-4337”一节 ） ——原文：Should Ethereum be okay with enshrining more things in the protocol? 此后 RIP-7560 的出现，证实了封装势在必行。

3. 提案即技术协议，它的不断变化，可能会给开发带来不良影响！这篇文章里面有提到一些细节：《RIP-7560 ：从共识层实现标准化的原生账户抽象》。

4. 账户抽象化的出发点，是想要显著改善用户与dApp的交互体验。它客观上有个巨大的应用优点：减少外部账户也就是人类的缺陷和失误带来的不良影响——考虑到未来合约满天飞带来的超高效率的交互，我们甚至可以说它很可能让人类对dApp的影响降低到极小化。并且，未来肯定还会通过一次次创新持续降级外部账户（或者使之产生蜕变），而优化dApp的效率和安全性。

5. 对使用 ERC-4337 达到社交恢复用户账户这样的应用，要特别小心！因为我们说到社交恢复，绝大多数俗人理解的就是几个人能够联合起来恢复某个用户的账户，或者赋予某个用户的一个新账户接收款项的权利——万一这几个人中有数人同时挂掉呢？万一他们联合起来作恶呢？ 如果你不但这样想还这样做，那意外就迟早会发生，而且大概率还是灾难级别越大发生的可能性越高——很遗憾我们有时候确实没法阻止它就这样发生。 而如果里面不是人，而是一个AI一个地址，这些AI能够飞到你的身边验明正身，由它们来掌握恢复人类账户的权限，你觉得如何？

参考文献

What is EIP-7702? A Beginner's Guide

Juan Leal

May 14, 2024 • 7 min read

Ethereum's evolution never stops. With each Ethereum Improvement Proposal (EIP), the network takes a step towards greater scalability, security, and usability. One such proposal, EIP-7702, is set to revolutionize the way users interact with the Ethereum blockchain by introducing account abstraction.

Account abstraction is a concept that has been discussed in the Ethereum community for a while, but EIP-7702 brings it closer to reality. The proposal aims to provide a more flexible and user-friendly experience by allowing smart contracts to act as Ethereum accounts. This shift could potentially unlock a myriad of new use cases and greatly enhance the overall user experience on Ethereum.

In this blog post, we'll take a deep dive into EIP-7702, explaining what account abstraction is, how it works, and what benefits it brings to developers and users. We'll also explore how thirdweb's tools and services can help developers navigate this new terrain and take full advantage of the opportunities presented by EIP-7702.

Decoding Account Abstraction

Before we delve into the specifics of EIP-7702, let's first understand what account abstraction is. In the current Ethereum ecosystem, there are two types of accounts: externally owned accounts (EOAs) and contract accounts. EOAs are controlled by private keys and can initiate transactions, while contract accounts are controlled by their contract code and can only perform transactions in response to receiving a transaction.

Account abstraction aims to blur the distinction between these two types of accounts. With account abstraction, all accounts on Ethereum can be treated as contract accounts. This means that EOAs can be replaced by smart contract wallets, which can have arbitrary verification logic for validating transactions.

This shift brings several benefits. For one, it allows for more flexibility in how transactions are authorized. Instead of relying solely on private keys, smart contract wallets can define their own authentication methods, such as multi-signature schemes, social recovery, or biometric authentication.

Furthermore, account abstraction enables new features like gas sponsorship, where a third party can pay for the gas fees of a transaction, and account recovery mechanisms, which can help users regain access to their funds if they lose their private keys.

Exploring EIP-7702

Now that we have a basic understanding of account abstraction, let's take a closer look at EIP-7702 itself. The full technical specification of the proposal can be found in the Official EIP-7702 Proposal.

EIP-7702 proposes a set of changes to the Ethereum protocol that would enable account abstraction. The key idea is to introduce a new type of transaction called a "user operation." Unlike regular transactions, user operations are not authenticated with a signature. Instead, they are authenticated by a smart contract wallet associated with the account.

When a user operation is submitted to the network, it is first sent to the associated smart contract wallet. The wallet then validates the operation based on its own verification logic. If the validation succeeds, the wallet sends a regular transaction to the target of the user operation.

This process allows for much more flexibility in how transactions are validated. For example, a smart contract wallet could require multiple signatures before a transaction is executed, or it could use off-chain data (like a proof of biometric authentication) to validate a transaction.

EIP-7702 also introduces the concept of "paymaster contracts." These are contracts that can sponsor the gas fees for user operations. This means that users can interact with Ethereum without needing to hold any ETH, as long as there is a paymaster willing to cover their gas fees.

EIP-7702's Impact on Developers and Users

The changes proposed by EIP-7702 have significant implications for both developers and users of Ethereum.

For developers, EIP-7702 brings a new level of flexibility in designing smart contract wallets. They can implement custom verification logic, enabling features like multi-factor authentication, spending limits, and emergency recovery mechanisms. This opens up a whole new design space for smart contract wallets.

Moreover, the ability to sponsor gas fees through paymaster contracts allows developers to create more user-friendly onboarding experiences. New users can interact with Ethereum applications without needing to acquire ETH first, reducing a significant barrier to entry.

For users, EIP-7702 promises a more seamless and secure Ethereum experience. Smart contract wallets can offer better safety features, like protection against phishing attacks and the ability to recover funds if private keys are lost. Gas sponsorship also makes it easier for users to get started with Ethereum, as they don't need to worry about purchasing ETH for gas fees.

However, these benefits come with some challenges. Implementing account abstraction adds complexity to Ethereum clients and wallets. There are also questions around how to optimize gas costs for user operations and how to ensure that paymaster contracts are not abused.

Technical and Adoption Challenges

While EIP-7702 presents a plethora of benefits, it's not without its challenges. One of the main hurdles is the added complexity it brings to Ethereum clients and wallets. Implementing account abstraction requires significant changes to the existing infrastructure, which could lead to potential compatibility issues and increased development overhead.

Another challenge is optimizing gas costs for user operations. Since smart contract wallets will be performing additional computations to validate transactions, this could lead to higher gas costs compared to traditional EOA transactions. Developers will need to find ways to minimize these costs, possibly through gas optimization techniques or by utilizing gas sponsorship mechanisms.

There's also the question of how to prevent abuse of paymaster contracts. While gas sponsorship is a powerful feature, it could potentially be exploited by malicious actors. Safeguards will need to be put in place to ensure that paymaster contracts are used responsibly and don't enable spam or denial-of-service attacks.

Adoption of EIP-7702 will also require buy-in from the broader Ethereum community. Wallets, dapps, and other ecosystem participants will need to update their software to support the new transaction types and interactions introduced by account abstraction. This process will take time and require coordination across the community.

Leveraging thirdweb for Enhanced Account Abstraction

Despite these challenges, the benefits of account abstraction are compelling, and tools like thirdweb are making it easier for developers to take advantage of these features.

thirdweb provides a suite of developer tools and infrastructure that simplify the process of building and deploying smart contracts on Ethereum. With thirdweb, developers can easily create smart contract wallets that leverage the capabilities of EIP-7702.

For instance, thirdweb's Solidity SDKs include pre-built, audited smart contract templates for common use cases like multi-signature wallets, escrow contracts, and token vesting. These templates can be easily extended to incorporate custom verification logic and advanced features enabled by account abstraction.

thirdweb also offers gasless transactions, a feature that aligns perfectly with the gas sponsorship capabilities of EIP-7702. With gasless transactions, users can interact with smart contracts without needing to hold ETH for gas fees. This feature, combined with the flexibility of smart contract wallets, could greatly improve the onboarding experience for new Ethereum users.

Furthermore, thirdweb's infrastructure is designed to handle the increased computational requirements of account abstraction. Their serverless architecture can scale automatically to meet the demands of user operations and smart contract wallet interactions.

Ethereum's Future alongside Account Abstraction

As EIP-7702 and the concept of account abstraction gain traction, it's exciting to consider how they might shape Ethereum's future.

One of the most promising implications is a vastly improved user experience. With smart contract wallets, users will have access to advanced security features, customizable transaction validation, and the ability to interact with Ethereum without needing to manage ETH for gas directly. This could make Ethereum much more approachable and user-friendly, lowering the barriers to entry for mainstream adoption.

Account abstraction also unlocks new possibilities for developers. The ability to define custom transaction validation logic opens up a whole new design space for smart contract interactions. We could see the emergence of new types of dapps and use cases that were previously not possible or practical with traditional EOA accounts.

For example, account abstraction could enable more sophisticated identity and reputation systems. Smart contract wallets could incorporate identity verification, credit scoring, or other off-chain data into their transaction validation process. This could pave the way for decentralized credit markets, self-sovereign identity, and more robust decentralized governance models.

Gas sponsorship also introduces new economic models and incentive structures. We could see the rise of "gas relayers" - entities that specialize in sponsoring transactions in exchange for other forms of value (e.g., token rewards, service fees, etc.). This could create new revenue streams and business models within the Ethereum ecosystem.

Of course, the full impact of account abstraction will depend on the rate and scale of adoption. But with proposals like EIP-7702 and the growing ecosystem of tools like thirdweb, the future looks bright. As more developers start experimenting with these new capabilities, we're likely to see a wave of innovation that could redefine what's possible on Ethereum.

Conclusion

As the Ethereum ecosystem continues to evolve, EIP-7702 and the concept of account abstraction represent a significant step forward in terms of usability, security, and flexibility. By blurring the lines between EOAs and contract accounts, account abstraction opens up a world of possibilities for developers and users alike.

For developers, EIP-7702 provides a new canvas to create innovative smart contract wallets with custom verification logic, advanced security features, and improved user onboarding. Tools like thirdweb are already making it easier for developers to integrate these features into their projects, providing pre-built templates, gasless transactions, and scalable infrastructure.

For users, account abstraction promises a more intuitive and secure Ethereum experience. Smart contract wallets can offer better protection against common vulnerabilities, more flexible authentication methods, and the ability to interact with Ethereum without the need to directly manage ETH for gas fees. This could significantly lower the barriers to entry for mainstream adoption.

As EIP-7702 moves closer to implementation, it's clear that account abstraction will play a central role in shaping Ethereum's future. While there are still challenges to overcome, such as increased complexity and potential gas optimization issues, the benefits are too compelling to ignore. With the right tools and community support, account abstraction could unlock a new era of innovation and growth for Ethereum.

Related Reading

What is EIP-7702? A Beginner's Guide

以太坊账户抽象研报：拆解 10 个相关 EIP 提案与冲击千万级日活用户的瓶颈问题

ERC 4337：无需更改以太坊协议的账户抽象

zkSync Era Account Abstraction

在介绍ERC-721的时候，我发现整个行业的应用从一开始就把NFT产品的图片直接链到了链下！

这毫无疑问是一个巨大的错误！

在前面对ERC-721介绍时，我已经说过：问题在于 其标准中的tokenURI 可指向一个JSON 文件，于是开发者就把NFT产品的图片或视频通过 URL 记录到这个JSON 文件中——这也就是说，这些所谓的“非同质化通证”的图片或视频大多保存在私有服务器上。用智能合约玩出了一个互联网产品，还硬说是NFT！

为了解决这个巨大的缺陷，我和道易程开发者一起，于2019年进行了摸索，并最终决定采用SVG格式图片链上存储的方式解决部分需求，并于2020年初推出对应的接口标准ERC-2569。

这是我们道易程团队2019年的技术成果，但它仍然具有很大的改进空间。

ERC-2569能做什么？

先看看我们通过ERC-2569发行的第一个真正的ERC721链上NFT：

更神奇的是，由于SVG是用XML语言的可读代码写出来的，事实上它的应用于图片并不局限于图片。譬如论文也是可以通过SVG保存到链上的！

以下内容我已经永久存储到了以太坊链上。你可以用钱包里的浏览器访问这个地址，来阅读全文：https://deme.app/full#1

它有什么创新？

与它有关的ERC721通证、图片、文字信息都在一个以太坊智能合约里！它很可能是迄今为止，第一个也是唯一一个真正的非同质性物品区块链资产。谜恋猫（Cryptokitties）因为猫的图片都在链下，算不上真正的区块链资产。

自然道纪念币图片的格式为可缩放矢量图形（Scalable Vector Graphics,SVG）。官方（W3C）的解释为：SVG is a language for describing two-dimensional graphics in XML [XML10, XML11]. SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), multimedia (such as raster images, video, and audio), and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects.

之所以采用SVG图片，核心原因是因为它是由XML语言代码构成的，而代码可以直接保存到智能合约里。

Special tags of Commemorative NaturalDAO Token:

<description>This ia a medal of honor awards from Alpha Test of NaturalDAO.</description> <honoree class="thonoree">Alpha Tester</honoree> <ARTIST>Tung Sau Chun Queena</ARTIST>

你可以通过W3C了解它的技术规格：Scalable Vector Graphics (SVG) Tiny 1.2 Specification。

另一个和SVG类似的技术是Canvas。两者的简单对比（中文）：https://www.w3school.com.cn/html5/html_5_canvas_vs_svg.asp。

Canvas甚至有了自己的游戏引擎：playcanvas。

• 启发

那么它们对区块链的数据存储有什么启发？

1. 图片甚至整个游戏都应该以可读代码形式保存到智能合约里，可以很好地保护设计者和所有者的权利，保障通证或游戏的透明性。 因为从比特币开始，区块链通证就已经是匿名的了——没有人确切地知道一个某个地址属于谁。而当中本聪丢失私钥之后，现在全世界都没有办法确认James Bilal Khalid Caan是不是中本聪——所以我个人并不认为区块链还有传统的隐私和版权保护概念，因为一切都与人的身份无关，直接用私钥控制就好了。而私钥永远都不应该被暴露！ 而更重要的问题，就是数据的所有权、使用权、收益权和透明性。 如果把图片转换成SVG，即可以将其所有权、使用权、收益权用文字形式永久保存到智能合约里，通过智能合约的透明性，图片的所有权、使用权、收益权就完全不存在可争议的了。而同时，其可读性自然就更能够得到保障。 我采用SVG而不是Canvas设计纪念币的原因是它的源代码有更好的易用性（accessibility，包括可访问、可读、可检索和可衍生）。而易用性与智能合约的公开透明相结合，就能更好地保证项目的可靠性，也使得大家能够更好地开放协作等等。

2. 解决区块链数据存储需求，不再需要IPFS来存储数据。 SVG和Canvas都可以存储在智能合约里，和IPFS存储相比，它的好处为：

   1. 不需要存储证明 IPFS需要存储证明，每时每刻都要能证明存储的数据还完好无损，其难度可想而知。但我们知道，以太坊里面的交易数据，因为有共识机制和众多存储节点提供保障，就根本不需要存储证明。

   2. 拓展以太坊的应用范畴 通过分片技术创新即可让以太坊承担存储。我们可以通过技术手段将不同的任务分配给不同的分片，譬如分片A专门存储图片（SVG和Canvas），分片B专门存储视频。不同种类的分片的每字节存储手续费不尽相同。 如果深入探讨，我们应该能够完善这一存储技术。

   3. 通过技术拓展，采用更高效的手段，丰富其应用方法 譬如它们可内置智能合约。又譬如SVG和Canvas都具有可交互性，那么我们通过技术拓展，可以让它们能够达到智能合约可交互性。这毫无疑问能大大拓展它们的应用价值。点击上面的图片，你可以体验到我做的简单的交互效果。 另外XML也有很丰富的用途，如可以支持多语言自动切换（甚至可以为整个区块链领域开发出统一的多语言库），并且它本身还具有其它可拓展性。

3. 标准化应用 以太坊的分布式存储是重复率超高的，资源浪费严重，但它是可以通过新的技术改进，亦即新的技术规范，而解决好的。而SVG能让图片以素材形式保存，而文字内容可以一律用另一个合约保存。这样不光对应的智能合约，其图片素材的重复使用率也会得到极大的提升——譬如我们可以定义某种区块链标准勋章，全世界都能自由使用它。 可想而知，我讲的这些不单适用于虚拟的NFT资产，这种模式也可以推广到工业设计领域。

4. 它们是可衍生数据 SVG 支持用 CSS 样式表将图形内容和图形样式分离。如果我们把CSS文件置于链下，则最终呈现的作品变得可以任意衍生。 同样地，使用Javascript，也能使得HTML5 Canvas游戏里的道具，随意个性化。 当然，衍生也可以利用智能合约在以太坊链上进行。

5. 我们是不是可以构建出一个自组织图片系统（self-organized Picture System），或者叫混沌图片系统（Chaos Picture System）？因为这样的衍生通过简单的规则，配合图灵完备的智能合约对feedback的吸纳，它自身就是有创造力的，通过市场机制它也可能自然地发生evolution，世间万物的演化规律同样适用于它。

动机：

ERC20是单一同质化通证标准，当交易涉及多个同质化通证时候，需要加载数量等同的合约。ERC1155把同质性同质化通证和非同质化通证结合在一起，在授权方面缺乏数量方面的授权，对于某一个id的授权与及多个地址同时授权。在交易方面缺乏多个地址对多个通证的转账。本提案弥补ERC20和ERC1155的不足之处，使得其适合多同质化通证进行授权与交易等应用场景。这也就是说本通证标准能够通过一个合约同时管理多个同质化通证，能够让多个发送方对多个接收方的多个通证的交易一次性完成，因此未来dApp数量越多，本标准就越能节省它们所消耗的内存和gas等资源、越能提升合约的综合交互效率——很显然，如果我们能使用一个基于该标准的智能合约为整个行业提供通证发行的通用的无需许可的解决方案，那将给区块链的发展带来很大的启迪，同时对于凸显区块链的效率也将起到非常好的示范作用。

详情请见：

当然，很重要的一点标准里面是不会说的：我们是因为开发道易程时，根据项目的需要才想到必须颠覆ERC-20，而创建一个效果更高、gas更低、应用更便利的通证标准！

课外阅读

EIP提案说明

参考资料

ERC通证标准全系列（简明介绍版），Dirac：

Ethereum is game-changing technology, literally.

账户抽象化（EIP-2938）：为什么 & 如何做

概述

和以上通证标准不同，ERC-792仲裁标准实际由两组智能合约构成：可仲裁合约和仲裁员合约。故ERC-792仲裁标准是涵括可仲裁合约和仲裁员合约的通证标准。每个仲裁合约都可以由每个仲裁员合约进行裁定。仲裁员合约给予裁决，然后仲裁合约按照其裁决执行合约。

这不就是法院和商业合同吗？是的，ERC-792仲裁标准提供的是仲裁服务，但它显然不同于现有的“法院+商业合同”的模式。

摘要

ERC-792仲裁标准和现在的法院和商业合同还是有所区别的，ERC-792仲裁标准使用两份合约可以分开裁决和执行：相当于法院的仲裁员合约，只负责仲裁，而可仲裁合约则按照其裁决结果执行合约。

这种抽象使得可仲裁合约的开发者不必知道仲裁员合约的内部过程，同样仲裁员合约的开发者也不必知道可仲裁合约的内部过程。

仲裁员合约的背后可以是中心化的仲裁员，多重签名或者去中心化自治组织（DAO）。

ERC-792仲裁标准允许dapps轻松地从一个仲裁服务切换到另一个仲裁服务,或允许他们的用户选择自己的仲裁服务。

ERC-792仲裁标准只是关于裁决和执行的通证标准，证据的处理应该服从另一个通证标准（ERC1497: Evidence Standard），因为对于ERC-792仲裁标准，每场纠纷的处理都不需要收集整理证据。

以下内容摘录自主要构建者的文章《The New Contract Law Standard for the Internet》：

“正如Milgrom，North和Weingast所指出的那样，中世纪晚期贸易的兴起和向早期资本主义的过渡，至少部分是通过法律手段更好地保护民众的财产权来实现的。这得益于一套通用标准，该标准允许在主要贸易航线中通过私有商业法庭网络对合同进行裁定。

在去中心化经济的曙光乍现之时，制定保障产权标准的时机已经到来。我们在这里提出的智能合同标准，因其可以实现法院的互操作性，正是朝这个方向迈出的关键一步。如果您正在建立一个需要仲裁服务的平台，如果您正在建立一个仲裁系统，并且如果您正在开发智能合同，请加入我们这项努力来构建新的智能合约标准。合作将使我们的生态系统更加强大。”

ERC-792仲裁标准：

最后，你知道问题在哪吗？

区块链的定义

区块链是一门尚处于萌芽期的崭新的学科——迄今还没有一个严格而完全统一的定义。我们认为综合性的定义大致如下：

区块链（Blockchain）源于比特币的底层共识和通证技术。它是提供智能合约执行环境的去中心化超级计算机，也是一种按时间顺序永久记录通证交易、智能合约代码及其运行状态和数据的分布式时态数据库。区块链是通过其共识机制、通证和智能合约等起到的激励、安保、确权、监管、经济自治等作用，做到集去中心化、抗审查、去信任、无需许可等本质特征于一体的新兴互联网技术。区块链应用的主流将寄望于蓬勃发展的去中心化应用（DApp）和去中心化自治智能体（DAO2.0）。区块链的终极目标是要完成从信息互联网到价值互联网的飞跃。

换一个角度，我们可以看到区块链是通过去中心化的数据记录、点对点的数据分发、时间戳（timestamp）对每个数据块的计时、用密码学方法将每个区块与其前后区块唯一关联等等技术手段，来保证数据及其追溯性的安全可靠；但其核心创新，还是智能合约，和通过特定的共识机制保障其数据安全可靠以及数据具备抗审查（Anti-censorship）的特性。

区块链虽起源于比特币的底层技术，但是通过太坊智能合约等方面的拓展，它已经得到很大的提升。可以说经过比特币对共识机制的贡献和以太坊对于智能合约的贡献，区块链才开始显山露水，并且“大鹏一日同风起，扶摇直上九万里”。

因此我们认为共识机制、通证和智能合约是区块链的三大硬核。其中比特币贡献了前两大，以太坊贡献了智能合约。

区块链技术将会被应用到人类社会的方方面面，区块链也是迄今为止唯一能够帮助人类突破所有障碍，彻底消除政治、经济、文化等领域的差异，从而真正实现地球村的技术。

如果我们说比特币是第一个成功的区块链应用，以太坊是第二个杀手级应用。你是不是能够恍然大悟了呢？

区块链的分类及其错误

区块链常被分为三类，普遍采用的是天才级的以太坊创始人（）：

1. 公共区块链（Public Blockchain，简称公有链） 公共区块链是指全世界任何人都可读取的、任何人都能发送交易且交易能获得有效确认的、任何人都能参与其共识过程的区块链——共识过程决定哪个区块可被添加到区块链中并能被明确其当前状态。作为中心化或者准中心化信任的替代物，公共区块链的安全由“加密数字经济”维护——“加密数字经济”采取工作量证明机制（proof of work）或权益证明机制（proof of stake）等公平公正、公开透明的方式，将经济奖励和密码学验证结合了起来，并遵循着一个原则：某个人从中可获得的经济奖励，与对共识过程作出的贡献成正比。这种类型的区块链通常被认为是“完全去中心化”的。

   公共区块链在区块链行业已经得到了爆发性的应用，譬如我们所熟知的比特币，以太坊及其竞争者Lisk、Waves，都是公共区块链。\

   公共区块链的优点可以归结为两点：

   • 保护用户免受开发者的影响

   在公共区块链中程序开发者无权干涉用户，譬如开发者是不可能冻结用户帐号的，所以公共区块链可以有效保护用户。

   • 轻松实现跨链交易

   私有链因为本来就不愿意透露其资产或数据，是不易实现跨链交易的。公共区块链，包括采用零知识证明的公共区块链，可以轻松实现跨链交易或数据分享——但以太坊的分片，即可以视之为多链。加上不同的公链，其应用层面的各种标准可能不同（或缺失），跨链的成本、效率都是问题。因此未来可能我们只会接受已多链化的以太坊。\

2. 联盟区块链（Consortium Blockchain，简称联盟链） 联盟区块链是指其共识过程受到预选节点控制的区块链；例如，不妨想象一个有15个金融机构组成的共同体，每个机构都运行着一个节点，而且为了使每个区块生效需要获得其中10个机构的确认（2/3确认）。区块链或许允许每个人都可读取，或者只受限于某些人可读取，或走混合型路线，例如区块的根哈希及其API（应用程序接口）对外公开，API可允许外界用来作有限次数的查询和获取区块链某些部分状态的密码学证明。这种类型的区块链可视为“部分去中心化”。\

   2017年5月下旬，区块链行业最知名的R3（）领导下的全球银行业区块链联盟宣布已经完成其A轮投资的第二阶段，募资1.07亿美元，这是迄今为止区块链领域涉及金额最大的一轮投资。但R3 CEO大卫•鲁特（David Rutter）却说“我们正在蜕变为面向金融服务的新型操作系统”，并且早在三个月前，R3副主管兼前瑞士信贷区块链架构师克莱门斯•万（Clemens Wan）就已经公开说“我们意识到，我们不需要一个区块链系统，我们只希望在区块链技术中得到启发”[2]。R3区块链联盟已聚集100多家全球顶尖金融机构，其中包括来自中国的中国平安集团、招商银行、中国外汇交易中心、民生银行等。但从2016年底起，高盛（Goldman Sachs）、桑坦德（Santander）、摩根士丹利（Morgan Stanley）、摩根大通（JP Morgan）等多家巨头已经先后退出。其原因无非是一个平台无法完全照顾到所有金融企业的利益，并且各家金融机构的软硬件建设都已经相当完备，想要以无缝接管的方式置换其核心，工作量和成本都是巨大的。由此可见联盟区块链的实践有多艰难！\

   摩根大通（JP Morgan）后以以太坊为基础，通过改变共识规则、共识算法，增加权限管理，衍生出联盟链，并于2016年11月22日发布 Quorum 1.0，但对于联盟链的实践并未带来多大的变化。 以区块链的价值观来考虑，联盟链就是“伪区块链”——这是热衷于联盟链的中国面临的严峻的问题，特别值得我们审慎对待！建议重温安徒生的《皇帝的新装》。\

3. 私有区块链（Private Blockchain，简称私有链） 私有区块链是指其写入权限掌握在一个中心化的组织手里。读取权限或者对外开放，或者被任意程度地进行了限制。相关的应用囊括数据库管理、审计等等都由一家公司内定，尽管在有些情况下希望它能有公共的可审计性，但在很多情形下，公共的可读性并非是必须的。 在零知识证明在区块链行业得到爆发性的应用之前，Vitalik已经思考过零知识证明在很多应用场景下，让私有链失去了存在的必要性。而比特股（Bitshares）和区块链社交平台Steem的创始人Daniel Larimer推出的EOS（www.eos.io），由于可以直接满足企业的管理需求，进一步挤压了私有区块链的生存空间。\

   Multichain、Corda和Hyperledger Fabric都是打造私有区块链的利器，但迄今尚未看到令人拍案的项目。\

   私有区块链的优点可以归结为以下几点：

   • 可以任性

   像改变游戏规则、还原交易、修改余额这种事，是绝不可能发生在公有链里的，但私有链可以任性，可以看心情——因此这个优点也可能是致命的缺点！\

   • 公开了交易审核者的身份

   只有私有链的主人才有交易的审核权，并且私有链的主人百分之百拥有交易的审核权。那么像PoW（工作量证明）里面大家担心的因为矿工串通而导致的51%攻击的危险，在私有链里根本就不存在——因为这方面的风险要么是零，要么是百分之百！这个优点显然也可能是其致命的缺点！\

   • 交易成本真的很低廉

   交易只需被几个受信的高算力节点验证就可以了，而不是需要数十万台矿机的协同，因此交易成本会便宜很多。事实上我们知道，公有链的代表比特币和以太坊，其交易手续费都不便宜。作者本人的比特币转账手续费的最高记录是单笔150元！ 既然是私有链，交易手续费到底收多少，主人说了算，他要不想便宜大家那就真不便宜。并且，随着有向无环图（Directed Acyclic Graph, DAG）在区块链领域的应用，公有链交易手续费的问题应该能够得到大大的改善。\

   • 交易效率更高

   节点少，验证简单，因此私有链交易并发的承载能力也就优于公有链。

   但既然故障可以迅速通过人工干预来修复，万一人工出错，事情就难办了！\

   • 更好的隐私保护

   读取权限受到限制，即可提供更好的隐私保护。但公有链通过采用零知识证明，甚至可以达到更高水平的隐私保护能力。

早在2015年，Vitalik Buterin就天才地预见了私有链的窘境，他分析说：

考虑到私有链的特色，似乎私有链无疑是机构的一个好的选择。然而，即使是在机构的环境下，公共区块链仍有很多价值，而且事实上，其价值在很大程度上体现在提倡公共区块链的哲学美德上，其中包括自由、中立和开放。公共区块链的优势一般分为两大类:

公共区块链提供了一种方法，可以保护应用程序的用户不受开发人员的影响，亦即有些事情即使是应用程序的开发人员也无权去做。经验不够的人很难理解为什么一个应用程序开发人员会想要自愿放弃权力和束缚自己。然而，更高级的经济分析提供了两个原因，用托马斯·谢林（Thomas Schelling）的话说：软弱是一种力量。首先，如果很显然你让自己做某些事情变得更加困难或不可能独自完成，那么其他人就更有可能信任你并与你进行互动，因为他们相信这些事情不太可能发生在他们身上。第二，如果你个人受到另一个实体的强迫或施压，然后说“即使我想我也没有权力这么做”，它就会变成一个重要的讨价还价的筹码，因为它会阻止那个实体强迫你去做的企图。应用程序开发人员面临的一个主要的压力或强制要求是政府，所以“审查反抗”与这种观点紧密相关。

公共区块链是开放的，因此很可能被许多实体使用并获得一些网络效应。要给出一个特定的例子，请考虑域名托管的情况。目前，如果A想要把域名卖给B，就需要解决标准的对手方风险问题:如果A先发，B可能不付钱，如果B先付款，那么A可能不发域名管理资料。为了解决这个问题，我们有中心化的托管中介，但收取的中介费是3%到6%。然而，如果我们有一个区块链域名系统，然后有一种货币也在同一个区块链上，然后我们可以通过智能合约（Smart Contract）削减成本接近于零：A可以发送域项目到一个程序（管理的合约地址），程序立即转发给B，并将B事先托管给程序的钱转给A，并且程序是可信的，因为它运行于一个公有链。请注意，为了有效地工作，来自完全不同行业的两个完全异构的资产类别必须位于同一个数据库中——这种情况显然是不容易发生在私有链上。另一个类似的例子是土地注册和产权保险，尽管重要的是要注意到互操作性的另一个途径是有一个公有链可以验证的私有链，类似BTC Relay采用的方法，并执行跨链交易。

总而言之：所谓私钥链和联盟链，都是伪区块链！

注：ConsenSys公司和以太坊开发的BTC Relay是一个以太坊智能合约，允许以太坊用户使用比特币支付。作为以太坊和比特币之间的一座桥梁，BTC Relay为那些想要使用以太坊和智能合约应用来验证比特币交易的开发者提供了一个工具。

什么是EIPs？

。根据官方定义，EIPs是以开放协作模式为以太坊平台构建各种标准（包括核心协议规范、客户端API和合约标准）的一个专业化的提案协作区。EIP应阐明相应功能的简明技术规范和基本原理。此外，EIP作者有责任就对应提案在社区内建立共识并记录异议。

以太坊核心协议规范、客户端API和合约标准的改进，有部分是属于对以太坊这条公链的改进，另外大多就是为智能合约的应用开发提供标准。如果我们把以太坊看着特斯拉，那么前者就是它为生产汽车而制订的特斯拉工厂的生产标准（包括基础设施和生产工具等等的标准），而后者就是为产品而制订的电池电压等等面向整个汽车行业的应用标准。

（插播：这种应用和公链基础标准混同讨论的模式适合于区块链发展的早期，未来很可能会发生变化）

在以太坊脱颖而出之前，这一工作主要活跃于比特币社区的协作，也曾经创造出很多重要的标准。如BIP 39：Mnemonic code for generating deterministic keys（生成确定性密钥的助记词）。我们现在使用钱包的第一件事就是保存好助记词，说明我们至今还在使用其衍生方式。因此 EIPs 继承的就是 BIPs 的去中心化协作传统。

我们说以太坊是当今最重要且最成功的公链，最主要的原因之一就在于区块链的应用标准暨应用的技术创新几乎全部来自于以太坊社区。

第一个 EIP 是”“，诞生于2015年11月15日。到2022年3月，以太坊社区涌现出5千个EIP。到2024年5月前，EIP数量超过7000个。粗略地看，EIP数量随时间的发展在加速。

特别值得一提的是，EIPs 遵循的是自由软件的。这个许可证是值得大家仔细研读的。

EIPs 的发展和许可协议表明，以太坊是实践去中心化协作最好的公链！

**举例：**ERC-165

状态：已定稿（Final）

提交记录：

标准说明：

ERC-165是一个标准接口检测协议。

ERC-165标准提供一个标准的接口来发布和检测智能合约方法的实现情况。此标准的提出是为了解决某些 ERC 标准对于接口实现情况查询、接口版本查询的需求。ERC-165协议中标准化了以下几条：

• 如何识别接口；

• 一个智能合约如何发布它执行的接口；

• 如何检测一个智能合约是否执行了ERC-165协议；

• 如何检测一个智能合约是否执行了一个给定的接口；

简单来说，EIP就是以太坊的发展路线图。但这份路线图不是由某一个人或机构决定的，而是由整个以太坊社区达成共识来决定的。

以太坊官网可以查阅到所有正在建设的和已经完成的提案：

或者在Github上也可以找到所有当前已有和草拟的EIPs的可浏览版本：

我们首先应该明白一个可贵的事实：实际上全球精英都已经并将继续参与以太坊的基础建设。譬如在这你就可以一睹为快：

智能合约开发基地：

https://github.com/ethereum/EIPs

ERC-number（如ERC-20）是以太坊智能合约标准的名称，有点类比IEEE标准，后面都有个标准的编码。前面我们已经重点介绍了 ERC-20 等六种智能合约标准。

如果你想成为 EIPs 编辑人员：

EIPs状态术语

Idea（创意） ——一个创新想法。它不会被纳入到EIP Repository里追踪。

Draft（草案）——一个开发中同时被正式纳入追踪中的提案。如果草案内容格式合规，会被EIP编辑并入EIP目录。

Review（审核）—— EIP作者标记它已经可以交给同行审核。让更多参与者提供反馈。

Last Call（最后一次征求意见）——这是确定为最终方案（FINAL）前的最后一次征求意见。EIP编辑在将一个提案设置为Last Call状态时会同时设定一个截止日期 （last-call-deadline），通常为14天。如果这其中发现必须要对提案的标准进行修改，那么提案又会回退到Review（审核）状态。

Final（最终方案，终案）——提案已经是最终标准。也表明这个 EIP 处于最终确定状态，仅应更新勘误表并添加非规范性说明。

Stagnant（停滞）——一个提案在草案或审核状态时，睡眠了6个月或更长时间，它就会被Mark为停滞状态。提案作者或EIP编辑可以通过将它改为草案状态而复活它。

Withdrawn（撤销）——EIP作者 已撤销该提案。此状态具有终结性，无法再使用此 EIP 编号复活该提案。如果该提案在以后被采纳，则被视为新提案。

Living （生效）——这是非常特殊的一种状态，对应的提案需要持续更新并且不会有最终方案。譬如非常特别的指导大家撰写和提交提案的EIP-1。

EIPs的类型

EIPs被分成多个类型，每个类型都有自己的EIP列表。

Standard Track（标准追踪类EIP）

标准追踪类EIP用于描述影响大多数或所有以太坊功能执行造成影响的的任何更改，例如对网络协议的改动，区块或交易有效性规则、已提交的应用标准或公约的改动，或影响使用以太坊的应用的互操作性的任何更改或补充。而且，标准追踪类可以进一步细分为以下几种类型

Informational（信息类EIP）

信息类EIP用于描述以太坊的设计问题，或者为以太坊社区提供一般性指导意见，但并不提出新功能。信息类EIP不一定代表以太坊社区的共识或建议，因此用户和实施者可以自由选择是否忽视信息类EIP或者遵循其中的建议。

Meta（元EIP）

元EIP用于描述以太坊相关的流程，或者对这些流程进行更改的建议。这类提案包含程序步骤、指导方针、决策过程的改动，以及以太坊开发工具或环境的变动。我们也可以把元EIP看作是流程类EIP。

元EIP与标准追踪类EIP类似，但仅用于以太坊协议之外的其它领域。该提案可能是一个实施方案，但与以太坊的代码库无关；这些提案通常也需要社区共识，但与信息类EIP不同，它们不是单纯的建议，用户通常不会忽视它们。

常用缩略词

LES：即Light Ethereum Subprotocol，以太坊轻客户端子协议。

API：即Application Programming Interface，应用程序编程接口。

RPC：即Remote Procedure Call，远程过程调用。

ABI：即Application Binary Interface，应用程序二进制接口。

ERC：即Ethereum Request for Comments，以太坊意见征求。

URI：即Uniform Resource Identifier,统一资源标识符。

如何参与EIP的建设

如果你想提交提案：

1. 首先注册 Github 的账户。

4. 按模板编辑好你的EIP内容。

如果你想成为以太坊改进提案编辑人员：

以太坊官网对EIPs的介绍

我的经验

• 因为以太坊改进提案编辑人员严重不足，且均为志愿者。EIP 的流程进展非常缓慢。通常你不必在意这一进展，按照你自己的节奏推动与该 EIP 相关的项目。

• 合约标准的讨论参与者寥寥无几。 譬如：

• EIPs 的实践让以太坊成为实践去中心化协作最好的公链！但以太坊官方团队、以太坊基金会和社区在 EIPs 方面的协作，令人遗憾至极！

本EIP还在讨论中：

（不参与技术协作，只想）

EIP-7777：人机社会的治理

描述：这个ERC定义了管理人类和机器人的身份的接口，并建立它们互动的规则集。

摘要

本提案定义了两个核心接口：IUniversalIdentity 和 IUniversalCharter，为人类和机器人提供了建立身份和创建由特定规则集管理的去中心化社区的机制。IUniversalIdentity 接口确立了对除人脑以外的有知觉计算架构的公平和公正对待，使机器人能够获得链上身份，从而与人类进行互动和交易。IUniversalCharter 使人类和机器人能够创建、加入（“注册”）、维护（“更新”）、离开和终止基于预定义规则集的自我管理社群，为人类和机器人混合社会提供合作与繁荣的框架。这些接口旨在为去中心化系统中的人机互动提供一个灵活而可执行的结构，确保所有参与者的效率、透明度和安全性。

动机

人类的大脑是一个湿润的、并行处理的电化学计算机。最近的硬件和软件进展使得人类社会很可能很快就需要与有意识的非人类计算机（如机器人）进行互动的工具。我们目前的政府形式，公民根据出生地自动注册到特定的规则体系，并不适用于没有传统出生地或出生时间的机器人。机器人面临许多困难，其中之一是它们（目前）无法获得标准的身份证明（如护照），不清楚适用于它们的规则体系是什么（因为一般来说，它们并不是在特定地方出生的），而且它们目前无法使用标准的人类银行系统。同样，如果机器人受到人类或非生物计算机的伤害，目前也不清楚哪个人类法院有管辖权。

传统的地理定义和以人为中心的系统可能效率低下、变更缓慢、透明度不足，并且难以适应全球化的虚拟社会。去中心化、不可变和公开的计算机为这些局限性提供了理想的解决方案，因为它们本质上并不歧视非人类计算机，因此为治理提供了一个公平和更公正的框架。特别是，智能合约可以为调节参与方的权利和责任提供一个强大的框架，而不管它们的计算架构的实现细节是什么。

这个ERC的总体动机是为异构全球社会提供一个专注于身份/治理的智能合约标准接口。虽然这样的规则体系数量无限，但为这些规则体系提供一个标准接口显然是有益的，这大大减少了创建、加入、维护和结束这些社会的摩擦和复杂性。这个ERC的具体动机有两个：

1. 机器人身份创建和管理：为了有意义地参与并遵守链上的法律，非人类（如机器人）必须能够获得有意义的链上身份。重要的是，这些身份应该使机器人能够享受作为特定社会一部分的好处，同时也承担相应的责任。因此，我们提议为机器人启用基于智能合约的身份。具体来说，每个机器人由一个智能合约表示，并需要遵循合约中定义的规则与链上的其他代理进行互动。这个接口也确保了所有参与者能够灵活地提议、采用或撤销规则，从而实现自我管理的合规性和与其他参与者的透明互动。

2. 规则创建和执行：为了让人类和机器人有效合作，双方必须就规则体系达成一致。这个基于以太坊的系统提供了一个基本的去中心化框架，通过智能合约来治理人类与机器人的互动。我们提议通过要求人类和机器人加入受监管的访问智能合约来执行规则体系，这些合约检查它们是否遵守给定的规则。我们还确保可扩展性，即可以创建多个受监管的访问合约，以满足不同的目的，人类和机器人可以根据需要选择加入相关系统。

这些接口共同构成了管理复杂人类与机器人互动的基础，促进一个去中心化、可验证和基于规则的生态系统，在这个生态系统中，机器人和人类可以安全、透明和负责任地互动，以实现所有人的最大利益。

技术规范

文中关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 和 "OPTIONAL" 的解释应参照 RFC 2119 和 RFC 8174。

基本原理

IUniversalIdentity

addRule(bytes memory rule) 这个函数允许机器人向其身份添加特定规则，表明其遵守该规则的意图。它支持动态规则管理，使机器人能够灵活地适应不同系统中的新合规要求。

removeRule(bytes memory rule) 这个函数从机器人的身份中移除规则，通常是在机器人不再需要遵守该规则时（例如，离开一个系统）。它允许合约动态管理机器人的义务，确保其规则集保持准确和最新。

checkCompliance(bytes memory rule) 这个函数检查机器人是否遵守特定规则。它确保机器人在被授权执行任何操作之前遵守规则。

Events (RuleAdded, RuleRemoved) 这些事件提供透明度和可追溯性，使跟踪合规状态变得更加容易。

IUniversalCharter

enum UserType { Human, Robot } UserType 枚举区分人类和机器人，以节省 gas，使合约能够更方便地处理不同用户类型，而不必承担字符串相关的成本和错误。这为未来的不同处理奠定了基础，允许系统根据用户是人类还是机器人应用不同的规则或逻辑。

registerUser(UserType userType, bytes[] memory ruleSet) 这个函数对于注册用户至关重要，将他们与特定的规则集关联。它确保用户（无论是人类还是机器人）在加入系统时都绑定到特定的规则集。

leaveSystem() 这个函数允许用户通过注销自己来离开系统。使用 msg.sender 确保只有用户自己可以调用此函数，从而增强安全性。在用户被允许离开之前，需要进行合规检查（通过 checkCompliance），确保用户在退出系统之前履行所有义务。

checkCompliance(address user, bytes[] memory ruleSet) 这个函数检查用户是否遵守他们同意遵循的特定规则集。它确保系统能够有效地管理和验证与预定义规则集的合规性，帮助维护系统的整体完整性。

updateRuleSet(bytes[] memory newRuleSet) 这个函数使合约中的规则集能够被修改，确保系统能够随着时间的推移而适应。

terminateContract() 这个函数允许合约永久关闭，防止系统内的进一步交互或注册。

Events (UserRegistered, UserLeft, ComplianceChecked, RuleSetUpdated, ContractTerminated) 这些事件共同确保关键活动对链外系统和参与者可见，使系统可审计和透明。

向后兼容性

未发现向后兼容性问题。

测试用例

参考实现

安全考虑事项

合规更新者：UniversalIdentity合约中的合规更新者角色对于更新合规状态（目前仅限于所有者）至关重要。确保安全的所有权以减少未经授权或恶意更新的风险是非常重要的。

规则管理：UniversalIdentity合约中的addRule、removeRule和updateCompliance等功能以及UniversalCharter合约中的updateRuleSet直接影响规则的执行。确保这些功能仅能被授权用户调用是非常重要的。

可升级合约：使用OwnableUpgradeable在初始化和升级过程中引入了风险。确保initialize函数受到保护，防止重新执行，对于避免重新初始化攻击至关重要。

gas消耗：过大的规则集可能导致高gas费用或拒绝服务风险。考虑对每个规则集允许的规则数量设置限制，以保持gas效率并避免性能问题。

版权

通过CC0放弃版权及相关权利。