大家都熟悉了以太坊风格的智能合约。以太坊的智能合约首先是基于账户模型，每个合约有一个自己独立的账户地址，这个账户地址可以存储合约持有的资产，也可以存储合约的状态。 以太坊基于这个持久化的状态存储，把智能合约设计成了命令式编程语言的模式，就像传统客户端服务器编程一样，链下代码调用链上代码暴露的API，对合约状态直接进行修改。

UTxO和账户模型各有特点，这里不一一列举彼此的优劣，但在支持智能合约的状态存储方面，账户模型确实似乎更方便一些。 但UTxO模型也不是无法实现，一方面比特币早就支持了有限的脚本功能（脚本就可以用来创建智能合约），我们需要考虑的是如何扩展比特币风格的脚本能力，使其能和以太坊风格的智能合约在功能上等价。

比特币风格的脚本和以太坊很不一样，比特币的脚本其实只做一个校验的工作。比如说你要花费一个普通UTxO，你需要提供地址对应的公钥以及签名，这笔交易就能被校验通过。当你要花费一个脚本UTxO的时候，你需要提供对应的脚本源码和参数，由脚本运行结果决定你这笔交易的合法性。这里有一个特点就是，链上脚本只提供校验功能，可以理解为一个只返回bool类型的函数，而不像以太坊合约可以直接返回计算结果。所以要利用脚本做一些计算，需要和链下代码有更复杂的配合，比如如果要通过动态计算决定output的value的话，需要先在链下计算好结果，然后构造交易并广播，链上代码再验证你提交的结果的正确性，等于实际逻辑需要在链下和链上各执行一遍。而以太坊模式下面，链下代码和链上代码的关系基本上就是传统的客户端服务器的关系。这个倒只是编程模式上的区别，功能上还是一样的。最主要的还是缺乏状态存储，使得比特币脚本无法用来实现让以太坊大放异彩的ICO和编写Token的能力。

Cardano准备引入一个Extended UTxO的模型，就是在output里面增加一个data script的字段，可以用来给UTxO的脚本提供状态存储的能力。

Cardano本身其实就是个采用PoS的比特币，和比特币一样基于纯粹的UTxO模型，Cardano专门设计了一门函数式编程语言Plutus来代替比特币脚本来做智能合约的开发。 Cardano的脚本UTxO里面会涉及三个脚本字段: validator script, redeemer script和data script。 其中validator script就和比特币脚本的职责一样，校验当前交易的合法性，redeemer script其实对应比特币脚本的参数，在这里表现为一个Plutus表达式， data script是新增的字段，以前output只有地址和Value两个字段，现在增加一个data script字段，也是一个Plutus表达式，可以表达任何值。

举一个ICO的合约为例，对于以太坊来说，大概就是一个map存储每个人的地址及其转入的金额，三个接口：投资(contribute)、融资成功后把钱转走(collect)、融资失败后用相同的地址请求退钱(refund)，不同的角色在不同的时机去调用不同的接口即可。

在UTxO模型下实现这个功能大概流程是这样的：

• 发起人创建一个合约脚本，并公布它的脚本地址。
• 投资人往这个地址转账(contribute)，也就是创建这个脚本的UTxO。
• 这个脚本执行的时候接受一个参数，表示这次调用行为是collect还是refund。
• 发起人发现融资成功条件满足后，构造一笔交易，给脚本传入collect参数，花费该地址所有的UTxO转到自己账户去。 脚本可以检查发起人的身份，融资行为成功的条件等等。
• 如果融资失败后，投资人请求refund，给脚本传入refund参数，花费自己创建的那个UTxO，转到自己账户去。 这个时候脚本要检查调用者身份的时候存在一点问题，UTxO里面的数据只有脚本地址和金额，并没有当时转入人的账户信息。 这个时候我们可以利用前面说的data script字段，在contribute阶段，给自己创建的那个UTxO添加一个共钥数据。脚本就可以校验当前交易发起人和UTxO中保存的共钥是否匹配了。

可以看出UTxO合约的编程模式和以太坊还是挺不一样的，利用data script存储状态就像是函数式编程利用递归来保存中间状态的感觉， 具体优劣可能还需要更多的实践才知道。感兴趣可以看一个完整的 Plutus Tutorial 是什么样的。

有时候用户体验和安全性/去中心化/隐私性等特性是冲突的，比如大家都想要的轻钱包。

不过首先要声明我们这里指的轻钱包不是所谓的交易所钱包或者服务器钱包，我还是认为钱包的底线依然是：私钥必须加密存放在用户的设备上， 并且代码应该开源，使得大家可以验证这一点，具体大家可以参考前一篇： 关于钱包的安全性 。

比特币PoW机制利用SPV机制算是比较好的解决了轻钱包的问题，只需要同步几百M数据，同时可以保留和全节点钱包类似的安全性和隐私性。 其中根本原因还是因为PoW协议的简洁性，共识协议相关的信息（算力）已经包含在哈希值里面了，只需要拿着区块头就可以确认链数据的正确性。 而且比特币一个区块头只需要80个字节。作为对比以太坊的区块头是500多个字节，Cardano是600多个字节，而且Cardano目前的共识协议相关的验证所需要用到的MPC中间数据，还不在区块头中， 意味着类似SPV的轻钱包模型，基本上没有可行性。

protocol magic : n
hash(prev header): 32
body proof
  tx proof
    number : n
    merkle root: 32
    hash(witnesses): 32
  mpc proof
    hash(data): 32
    hash(vss certificate): 32
  hash(delegate payload): 32
  hash(update payload): 32
consensus data
  slotid: (n, n)
  leader public key: 64
  difficulty: n
  signature: 64 * 4
extra block data: 0

当然，在Cardano去中心化之前，不去校验区块数据其实没有太大问题，因为目前数据来源本来也都是官方的服务器，不存在信任问题。 如果Cardano去中心化后能够实现Ouroboros Praos，轻钱包问题很可能还会有更完美的解决方案。

OK，暂时选择不纠结数据校验的问题之后，就只剩下几个问题需要考虑：

• 钱包恢复

  钱包恢复操作的本质就是在链上找出属于这个钱包的所有地址。 目前Cardano官方钱包生成地址的索引不是按顺序来的，这导致恢复钱包需要检查链上所有地址，这个是目前官方钱包恢复钱包操作慢的主要原因。 这个问题可以通过实现 BIP44 规范解决，生成新地址的索引是连续的。在恢复钱包的时候，只要按顺序检查每个地址在链上是否存在， 直到遇到第一个链上不存在的地址时(或者允许少量的空间)，就可以认为恢复完成了。 但是要升级到BIP44规范不是一个向后兼容的操作，所以很可能新钱包不能支持大家直接恢复目前官方钱包里面的钱包。 但是大家依然可以使用原来的助记词创建新钱包，然后在目前官方钱包上做一笔转账，就可以转换到新钱包上来。

• 下载数据

  轻钱包的关键就是要尽量减少需要下载的数据。在放弃校验数据的情况下，我们首先可以把区块中大部分的数据移除，只需要保留区块头中少量数据用于处理可能的分叉和回滚， 以及区块体中的交易数据本身。其次我们希望尽可能只下载我们自己钱包相关的数据，而不是把所有人的交易数据都下载下来。一个naive的实现方式就是， 把自己钱包的地址集合传给服务器，然后让服务器过滤掉不相关的信息，但是这样就彻底破坏了UTxO模型的隐私保护的优势了。

那么有没有可能既保护好隐私，有可以少下载一些数据呢，其实比特币的SPV轻钱包早就有解决方案了，也就是所谓的bloom filter技术(BIP37)。 它会把你的地址集合哈希（哈希表的哈希，而不是密码学的哈希）到一个bitmap的索引，你把这个bitmap传给服务器，服务器下发所有匹配这个bitmap的信息下来， 因为碰撞的存在，里面会有部分来自其他人的信息，本地再做一层过滤就可以了。你还可以调整这个bitmap的大小，在隐私性和数据下载量之间权衡，bitmap越大，隐私保护越好， 但是数据下载量也会增大。

这是我目前能想到的针对Cardano轻钱包最好的实现方式了，官方最近也发布一个开发中的轻钱包项目，目前看代码直接采用上传地址集合的做法， 问题确实简化了，但我认为哪怕是在目前中心化的阶段，也不应该直接放弃隐私性的考虑。

欢迎关注 小艾钱包 的 开发进展 。

由于数字货币相关的一些概念和传统的不太一样，许多不搞技术的同学对于如何有效保护自己数字资产的安全，还是有点搞不清楚。希望本篇可以对非技术同学说清楚钱包的安全问题。

钱包本身只是一个比喻的说法，而且可能是很有害的一个比喻，因为实际情况跟传统世界的钱包隔了十万八千里。

打一个更恰当一点的比方：

• 你的地址就像是一个上了锁的存钱罐，别人可以往里面放钱，但是不能随便拿钱走，谁有钥匙谁就能拿钱走。
• 存钱罐和钥匙是应该离线生成的，并且是一对一的，你生成一对存钱罐和钥匙后，把存钱罐公布给别人，别人就可以给里面转账。谁拥有这个钥匙，谁就能花这个钱。

区块链中除了共识算法以外最重要的可能就是经济系统了，经济系统的设计目的是在大家都追求利益最大化的前提下，让系统进入我们希望达到的目标均衡状态。 Cardano这方面的规则刚出草案，在正式发布之前都还有可能修改，我们可以先大体了解一下。

简单介绍一下Cardano的Ouroboros协议。首先这是一个PoS协议，每个人都可以运行一个核心节点(通俗的说就是矿工节点)，即可获得与自己持有份额等比例的出块奖励。

为了让普通用户不用那么麻烦去维护一个服务器节点，Ouroboros支持委托机制，不想自己维护节点的人可以把自己的份额委托给其他人。 委托是可选的，并且是递归的，也就是说你可以选择自己挖矿，也可以选择委托别人挖矿，如果别人委托给你了，你还可以继续委托给其他人（递归的最大深度会有限制）。 也就是所谓的 Liquid Democracy 。 同时会要求交易所钱包使用不同的地址类型，禁止交易所使用用户的币参与挖矿。

总之，有这么几种角色：独立挖矿者、矿池主、代理给矿池挖矿的普通持币者。

作为一个去中心化自治系统，我们又不希望设置太多硬性规定，尽量只设定最基本的规则，其中一些参数可以交给市场去博弈出具体的值，而另外一些固定的参数也可以在未来的财政系统中由大家投票去决定。

另外，Ouroboros的委托是不需要冻结用户的币的（除了矿池主注册矿池的时候可以主动冻结一些币，后面会提到），系统会在每个epoch开始的时候计算整体份额比例，并在一个epoch过程中保持不变，但是币本身随时都可以自由交易，在目前的设定下一个epoch持续5天。

奖励规则的设计目的主要是为了：

• 安全性

  没有绝对的安全性，最终系统的安全性取决于各个角色攻击协议需要付出的成本，比如PoW系统的攻击成本是51%的算力，PoS系统的理论攻击成本是51%的币，但是因为有了委托的存在，矿池主用来出块的币实际上大于他本身持有的币，那么这种情况安全性上受到多大影响，是需要计算的。

• 去中心化程度和稳定性的权衡

  任何一个去中心化网络要保持稳定高效的运行，需要有稳定高效的矿工节点协同工作。作为一个去中心化系统，我们希望通过规则的设置让系统能够自动达到我们希望的稳定状态。

我们先来看看其中涉及到的几个关键参数：

• k

  系统希望的均衡状态下矿池数量，默认值100。

• cost/margin

  矿池运行需要的成本和利润抽成，矿池主的奖励计算大致逻辑是 cost + margin * reward ，

  如果margin为0，矿池主只拿cost数量的固定奖励，如果margin为1，矿池主拿走全部奖励。这个由矿池主注册矿池的时候设定，大家可以根据矿池主的设定选择代理给合适的矿池。

• s

  矿池主注册矿池的时候主动选择冻结的币的比例，冻结越多，矿池整体奖励越高。

• σ

  矿池整体拥有的stake比例。

• a0

  这个系数是控制矿池主冻结份额数量对矿池整体奖励的影响程度，a0越小，影响程度越低。

• γ

  如果矿池错过了出块，奖励会有减少，这个系数控制具体的减少程度。多出来的奖励并不会分给其他节点，而是全部进入财政系统。这样可以降低矿池之间彼此攻击的动机。

其实从定性的角度大体上就清楚了，具体的定量分析大家可以期待Dr. Wang的分析结果，我这里就截个图大家自己看公式把：

一个矿池在一个epoch中的奖励上限

考虑矿池不出块的惩罚

区块链是一种比较复杂的P2P软件，P2P软件本身也是网络编程中较为复杂的一种，网络编程本身也比传统编程更复杂一点。网络编程的复杂性来自于节点的状态，以及节点之间关系带来的状态空间的爆炸。P2P模糊了客户端服务器角色的界限，而区块链在普通P2P软件基础上则增加了大量的协议。归根结底，复杂性就是来源于状态空间规模的巨大增长。

节点需要保存的状态可以分为本地状态和远程状态，本地状态就是节点自身的数据，通常需要进行持久化保存，远程状态是用来记录一条连接的远端节点的状态，并由网络消息驱动状态的变迁，通常其生命周期和这条连接本身的生命周期绑定。

传统网络编程虽然节点之间关系简单，但使用事件驱动的方式编程的话，也会发现状态空间组合起来还是很头疼的。 这也是为什么微线程技术会成为网络编程的神器，因为线程的模型大大简化了状态之间潜在的组合关系。

用过微线程的朋友会发现，微线程简化了节点的状态组合，代价其实是对连接资源的独占，多条微线程想公用同一个连接的话，往往很容易会回到事件驱动编程的老路上去。

偏偏区块链的项目往往要在节点之间运行多套协议，常见的比如：节点发现、共识算法、区块同步、投票等等，未来专用或通用的MPC模型可能也是一个发展方向，除了节点发现往往会单独开一个UDP的端口以外，其他协议都是跑在一个TCP端口下。 这么复杂的协议如果要用微线程模型来开发的话，每套协议都得要一条甚至多条连接才能来搭配对应的微线程逻辑。然而就像原生线程一样，TCP连接也是成本高昂。

那么很自然的，轻量级连接的概念就可以提出来了。在一条TCP连接上多播大量的轻量级连接，是今天要介绍的重点。轻量级线程要配合轻量级连接才能发挥它完全的潜力。 据我所知，这个模式已经在一些项目中应用了，包括 Cardano 、 libp2p 。

Cardano的实现是基于Haskell的 network-transport 库， 有兴趣的可以看看 教程 。