私钥存放在哪里

所以，你的数字资产的安全性首先取决于这把钥匙是如何保管的，所以使用钱包时，第一个需要确认的就是钥匙被存放在哪里。 比如有些人把交易所当钱包，这个时候钥匙就是在交易所的手上。还有一些服务器钱包，你的钥匙实际上也是放在钱包服务商的手上。这些情况下，实际上你都是把自己的钱托管给了别人，安不安全就看对方人品了。

还有一些闭源钱包，比如imtoken以及其他一些，虽然他们说钥匙只会存放在你的设备上，但是理论上来说，不检查他的源代码，我们是无法确切地知道他说的是不是事实的。

如果真的想要确保数字资产的安全，首先钥匙要保管在自己手上是最基本的，而且为了确保这一点，你最好使用一个开源的并且有一定声望的钱包。

私钥是如何被盗的

确保钥匙保存在本地的情况下，接下来的风险就是钥匙被盗了。如果保存钥匙的设备（电脑或手机）感染了病毒，那么你的钥匙就有可能被别人拷贝走。

所以大部分钱包都会对钥匙的存储进一步做加密处理，这些钱包会提示你设置一个密码，这个密码就是用来对你的钥匙进行加密，你本地存储的是加密后的版本。就算病毒或黑客盗取了你的密钥文件，在他不知道你密码的情况下，也无法使用你的钱。（所以如果你忘记了这个密码，也不用太担心，只要你备份的助记词还在，依然可以把私钥重新恢复出来）

对密钥做加密有一个微妙的地方需要注意就是，不要在内存里留下明文密钥的痕迹，这一点其实很多钱包可能并没有考虑地这么细致。 因为在钱包运行过程中，当私钥刚创建出来或者被使用的时候，私钥的明文是必然会在内存里出现的，而传统编程的时候，对于不再使用的内存，通常的做法是不管它，这样就很容易把明文的私钥在内存里留下痕迹，给黑客盗取私钥提供了可能性。正确的做法是在使用完后要主动把私钥明文对应的内存区域清零。

其实只要这几点做到位了，你的私钥的安全性就有了基本的保证。就算钱包软件其他地方有漏洞，或者你的系统本身有漏洞导致被病毒或黑客入侵，你的私钥也不会立刻被泄漏出去。 要做到整个软件完全没有安全漏洞可能比较难，但是把上面几点做到位，只要有心，一般还是问题不大的。

冷钱包

但是终极的确保私钥安全性的办法，还是要从一开始就保证私钥不触网，也就是冷钱包的概念。找一台不联网的干净电脑，或者一个开启飞行模式的干净手机，把私钥创建在上面，并且这台设备以后也永远不联网，或者干脆创建后把私钥删掉（如果你只存钱很少花钱并且备份好了助记词的话） 因为查询余额以及收款的操作是不需要私钥的，只有花钱的时候才需要私钥。 这甚至可能比硬件钱包还要安全，毕竟硬件钱包还取决于硬件本身设计有没有bug。

私钥以外的安全性

私钥以外的安全性，主要就是交易数据正确性的风险，也就是双花的风险了。虽然公链项目团队可能花了大力气去设计共识算法保证链上数据的一致性，但是如果钱包这临门一脚撂了挑子，还是白搭。

所谓双花风险就是，虽然你在钱包上看到对方给你转账成功了，但是等你给对方发货后，发现那笔转账是有问题的。

从这个维度来说，又可以把钱包分为几种类型：全节点钱包、轻钱包、连轻都算不上钱包。这几种钱包模式的区别就在于他们如何获取区块链上的交易数据。

• 全节点钱包是最传统最安全的模式，它会把整个区块链数据下载下来，然后从里面找出和你有关的那些交易显示出来，并且数据同步的时候也会同时监听多个节点，只要其中有一个节点是诚实的，你都不会被骗。
• 轻钱包是对全节点钱包的优化，它只需要下载所有区块头，以及和你有关的交易信息，可以忽略链上大部分数据。因为有了区块头就可以验证数据合法性了，再加上多连几个节点交叉确认后，安全性其实并不会打折扣。唯一的弊端是隐私问题，不过鉴于以太坊这么火，估计一般用户对这个问题也没那么感兴趣，就不多说了。
• 还有一些所谓的轻钱包，其实是没有上面的安全性保证的，它连区块头都不下载，直接从服务器获取余额和交易历史等信息，并且通常是只连开发商自己的服务器，这种模式下等于是完全信任钱包开发商服务器提供的数据了，个人认为不能算是去中心化的钱包，虽然它私钥可能还是存放在设备上而不是服务器上。

Cardano的钱包

Cardano的官方钱包因为一些细节的技术决策上的问题导致体验不太好，一直被大家所诟病，不过最近版本更新改进不少。

我自己在阅读Cardano实现的过程中，有时候也会产生一些自己的想法，于是写了一些代码 python-cardano ，目前已经基本能够实现命令行界面的钱包功能，私钥加密部分是直接复用的官方代码，加上目前Cardano本身还没进入去中心化阶段，区块数据都来源于iohk的服务器，所以基本的安全保障还是有的。 不过项目代码整体还处在开发阶段，所以目前只建议用来学习研究，不要实际用它管理资产。

目前这个项目已经能够通过命令行界面提供一些官方钱包还没有的特性，比如：

• 大大降低的磁盘空间占用，目前把整个链数据同步下来只占用2.5G，还没做压缩，加上适当的压缩估计还能进一步降低一些。官方的1.4版本也会对磁盘空间占用过大问题进行优化，到时候可以对比对比 ;D
• 支持sign message功能，也就是可以对任意消息进行签名。这样你可以把签名发送给其他人来证明你确实拥有某个地址的所有权， 比如有些群有持币准入门槛的，这个特性就有点用了。
• 短地址编码格式，通过优化一些编码的开销，可以做到ADA地址的长度非常接近比特币和以太坊地址的长度，比如： 12MM1pbyTk2WuZEnfiicX9gHF4YtFYL8ebUkr1hp ，已和官方沟通，他们也有计划优化地址长度。 另外等delegation上线之后，地址里包含的信息还要增加一些，所以最终还是很难仅仅通过优化编码方式保持这么短的地址。

下一步计划是基于它开发ADA手机钱包，未来这个项目可能也可以作为Cardano侧链生态中的一个开发平台，目前也可以作为大家学习研究的一个基础。有兴趣的朋友可以加电报群一起探讨： Safe ADA Wallet 。

背景知识：UTxO记账法

正常银行转账交易是从一个账户往另一个账户转移资产，比如张三给李四转账100元。 但是Cardano和比特币这种虚拟货币的交易略有不同。 交易的输出大体上差不多，唯一区别是可以有多个目标账号，比如一笔交易可以同时转70元给李四，30元给王五。 交易的输入就完全不同了，一笔交易的输入不是来自某个账户，而是来自其他交易。 举个例子，我们把这笔“给李四70元给王五30元”的交易叫做t1。

t1 输入: ...
   输出: 70元给李四, 30元给王五

现在如果李四想给赵六转50元，他可以创建一笔新交易说：用掉交易t1的第一个输出，然后给赵六50元，剩下20元给自己。

t2 输入: t1的第一个输出
   输出: 50元给赵六, 20元给李四

我们注意到李四需要把20元“找零”转回给自己，因为一个交易输出只能被使用(也就是用作另一笔交易的输入)一次。 这种风格的记账风格就叫做UTxO记账法。UTxO的意思就是未使用的交易输出。

而区块链就是许多这种交易组成的一个列表。对应的形式化定义差不多是这样的：

钱包

虚拟货币的钱包就是一个软件工具，它会监控区块链的状态，跟踪用户的资金（准确的说就是用户的UTxO），也支持往区块链发送新的交易请求。 普通用户主要通过钱包和区块链打交道。至于验证新交易的有效性以及决定是否打包到区块中，这些不是钱包的任务，也就不在本文讨论的范围内了。

钱包的形式规范是一个数学抽象，它只关心钱包最核心的功能，忽略无关的细节。在Cardano钱包的基本模型中，我们把钱包状态简化到只包含UTxO以及在途交易(pending transactions)。 这份规范简单到用一张纸就可以写完：

这个模型很简单，这样才方便进行更深入的研究，也方便提供相关属性的数学证明。 同时又足够精确，可以用来指导钱包的设计，也可以作为单元测试的基础，并驱动真实实现的开发。 他还可以用来研究可能存在的性能问题，以及如何来解决这些问题。

余额

钱包设计中有一些棘手的问题，余额的处理就是其中一个。 你可能觉得在钱包里展示余额应该是一件很简单的事情，但就算在传统银行账户中，也至少存在两种余额。比如张三给李四转100元之后，他的银行账户可能会说：

• 你当前余额为1000元
• 有一笔100元的在途交易，所以你的可用余额为900元

和传统银行交易不同，UTxO风格的交易多了一个找零的概念。 这就会产生三个余额的概念。我们还拿前面的t2交易为例，李四的钱包可能会这么汇报他的余额：

• 你的可用UTxO为1070元
• 有一笔在途交易t2，所以你的可用余额为1000元
• 交易t2会转回20元，所以你的总余额其实是1020元

注意到t2的找零只有当它被打包进区块链之后才可以使用。

目前为止，从钱包设计角度来看，问题还不算复杂，虽然用户界面的展示上可能还需要斟酌一下(要给用户展示哪个余额？)。真正的复杂性来自临时的区块分叉，也就是区块链上对于哪些交易需要被包含进来的分歧（分叉的产生以及如何解决不在本文探讨的范围）。

还是继续上面这个例子，假设t2在途，同时又出现了对t1的争议。争议解决后，钱包发现t1不在区块链中了（可能之后还会被重新包含进来）。 这个时候钱包的可用余额还是1000元，但是总余额如果还是1020元是否合理? 毕竟这样的话，总余额就大于可用UTxO了，倒不是说它一定不对，但总觉得不太舒服。

所以我们在形式规范中又定义了一个最小余额的概念：账户在各种可能出现的情况下，最小的那个余额。 在这个例子中，就是t1和t2都没有被打包进区块链的情况下，余额最小，为1000元 （注意不可能出现t2生效但t1不生效的情况，因为t2依赖t1）。 这个概念在直觉上似乎可行，但是为了让它更加精确并且可以计算，我们还需要引入另一个概念: ‘“预期UTxO”，也就是钱包期望包含进来但还没有被包含进来的UTxO。

当然，就算不通过形式化的方法，我们也可以提出最小余额的概念，并且想出对应的算法。但是有这份形式规范可以让我们对这些问题研究地更加透彻，排除掉真实实现过程中周边的细节问题，专注于最核心的概念。

内部一致性：不变量

当我们引入一个像“预期UTxO”这样的新鲜概念的时候，我们怎么知道它是对的？ 其实，既然新概念是我们自己定义的，再问它是否正确没有太大意义，我们应该问的是，它是否有用？

回答这个问题的一个办法就是找出不变量。不变量就是永远为真的属性。 比如上面展示的基本模型中就有这样一个不变量：

不变量3.4 txins pending ⊆ dom utxo

这个不变量是说，在途交易只能使用UTxO中的输出。这一点在直觉上貌似是显然的：钱包不能让用户使用它自己没有的资金。 然而，就像上面展示的，当我们开始考虑临时分叉的时候，这个不变量就不成立了。 李四提交的t2，使用了t1的一个输出，随后t1被回滚，这个时候他就使用了一个不在当前UTxO中的输出了。

这个时候我们又需要用上“预期UTxO”的概念了，在完整模型中，这个不变量需要改成这样：

不变量7.8 txins pending ⊆ dom (utxo expected)

换句话说，在途交易只能花费UTxO或者预期UTxO。

另一个不变量能够帮助我们巩固对“预期UTxO”这个概念的直觉理解： 一个输出不能既在UTxO中也在预期UTxO中。

不变量7.6 dom utxo 相交 dom expected = ∅

毕竟如果一个预期UTxO出现在当前UTxO里的话就很奇怪了。 列出这样的不变量可以让我们对新概念的直觉理解变得精确， 而证明他们的正确性也能为形式规范的合理性以及内部一致性提供很强的保证。

半形式化开发

形式化地证明上面这样的不变量不光很耗时，还需要专业的数学训练。 如果能够证明他们当然是最完美的，但本文想说的是，尽管我们没有去证明，这个方法依然为我们提供巨大的帮助。 毕竟，我们之所以选择用Haskell编程，就是因为我们可以很容易地在Haskell代码和数学语言之间来回转换。

为了把形式规范中的钱包模型翻译成Haskell，我们使用一个在之前文章中介绍过的方法： Haskell中的面向对象编程 (我们发明这个方法就是用来干这个的)。下面就是把基本模型翻译到Haskell代码的样子：

mkWallet :: (Hash h a, Ord a, Buildable st)
         => Ours a -> Lens' st (State h a) -> WalletConstr h a st
mkWallet ours l self st =
  (mkDefaultWallet (l . statePending) self st) {
      utxo       = st ^. l . stateUtxo
    , ours       = ours
    , applyBlock = \b -> self (st & l %~ applyBlock' ours b)
    }

applyBlock' :: Hash h a
            => Ours a -> Block h a -> State h a -> State h a
applyBlock' ours b State{..} = State {
    _stateUtxo    = updateUtxo ours b _stateUtxo
  , _statePending = updatePending   b _statePending
  }

updateUtxo :: forall h a. Hash h a
           => Ours a -> Block h a -> Utxo h a -> Utxo h a
updateUtxo p b = remSpent . addNew
  where
    addNew, remSpent :: Utxo h a -> Utxo h a
    addNew   = utxoUnion (utxoRestrictToOurs p (txOuts b))
    remSpent = utxoRemoveInputs (txIns b)

updatePending :: Hash h a
              => Block h a -> Pending h a -> Pending h a
updatePending b = Map.filter $ \t -> disjoint (trIns t) (txIns b)

它比形式规范涉及到更多细节；比如它把具体的hash类型和地址类型抽象出去了。虽然它比规范稍微复杂一点，但也很接近了。 它依然是一个模型：没有处理任何网络或者存储方面的问题，可能也不是很高效，等等。也就是说，这个代码还不是真实钱包的设计。 但有这个模型还是有用的，两个原因，一个是我们可以用它来测试真实的钱包，我们会在下一节讨论这个话题； 另一个是我们可以用这个模型来测试不变量。比如下面的代码就是对上面提到的不变量7.8和7.6的Haskell翻译：

pendingInUtxoOrExpected :: WalletInv h a
pendingInUtxoOrExpected l e =
  invariant (l <> "/pendingInUtxoOrExpected") e $ \w ->
   checkSubsetOf
    ("txins pending",
      txIns (pending w))
    ("utxo ∪ expected",
      utxoDomain (utxo w) `Set.union` utxoDomain (expectedUtxo w))

utxoExpectedDisjoint :: WalletInv h a
utxoExpectedDisjoint l e =
  invariant (l <> "/utxoExpectedDisjoint") e $ \w ->
   checkDisjoint
    ("dom utxo",
      utxoDomain (utxo w))
    ("dom expected",
      utxoDomain (expectedUtxo w))

和刚才的钱包实现一样，Haskell代码比对应的形式规范涉及更多细节；比如上面这个代码和形式规范主要区别是可以在不变量不成立时提供详细的错误信息。除此之外，大体上还是对规范的直接翻译。

这样做的好处是，我们可以用QuickCheck来测试这些不变量。 我们为钱包生成随机(但有效)的事件（"应用这个区块"，"提交这笔新交易"，"切换到另一个分叉"），然后检查这些不变量在每一个时间点都成立。 比如规范发布第一个版本的时候就有一个低级错误：当钱包收到一个新区块时，它从预期UTxO里把该区块的输入移除了，而不是输出。一个很蠢的错误，但是如果人工审核的话很容易被忽视。 当然，证明的话可以发现这个问题，但是用QuickCheck也可以：

Wallet unit tests
  Test pure wallets
    Using Cardano model FAILED [1]

Failures:

  test/unit/Test/Spec/Models.hs:36:
  1) Wallet unit tests, Test pure wallets, Using Cardano model
       predicate failed on: Invalid [] InvariantViolation {
           name:     full/utxoExpectedDisjoint
         , evidence: NotSubsetOf {
                 dom utxo: ..
               , dom expected: ..
               , dom utxo `intersection` dom expected: ..
             }
         , events:   {
                 state: ..
               , action: ApplyBlock ..
               , state: ..
               , action: NewPending Transaction{ .. }
               , state: ..
               ..
               , action: Rollback
               ..
             }
         }

它不光告诉我们这个不变量不成立了；它还输出了能重现问题的事件序列以及相应的钱包状态（包括所有的中间状态），并且它还显示UTxO和预期UTxO的domain以及他们的交集是什么(他们的交集应该为空，却不为空)。

测试真实的实现

上面说到Haskell对钱包规范的翻译依然是一个模型，其中忽略了大量真实世界的复杂情况，而这些情况是完整的钱包实现必须处理的。 甚至模型中实现的数据类型也是真实版本的简化：交易中没有包含签名，区块只是一个交易列表而不是真实的区块等等。

尽管如此，我们还是可以用这个模型实现来测试真实实现。我们可以把简化版的类型转换到真实版本。既然我们已经有了针对简化类型的QuickCheck测试数据生成器，并且我们也已经能够对模型实现进行测试，我们就可以用下图的方式对真实实现进行测试：

我们先用QuickCheck生成器生成简化模型的钱包事件，然后：

1. 在简化类型的测试数据上执行模型实现，然后把结果翻译到真实实现
2. 我们先把测试数据翻译到真实类型，然后执行真实钱包的实现

我们可以比对两条执行路径的结果，如果相同的话，我们就可以认为真实钱包正确地实现了这个模型。 我们在每一步都去验证这一点，加上我们前面保证了模型实现中的不变量在每一步都成立，那么我们就能得出结论：不变量在真实实现中也在每一步都成立。

比如，如果真实钱包中有一个bug重复计算了在途交易的找零(比如一笔在途交易使用另一笔在途交易的找零作为输入，这只在分叉的情况下才会出现)，测试用例生成器就会找到一个反例，使得两条执行路径的结果不一致，并且告诉我们导致不一致的具体的钱包事件序列以及相应的钱包状态，以及不一致的具体值。

结论

软件的规范，就算存在，一般也都是些非形式化的文档，使用自然语言描述一下软件预期的功能。 这样的规范不能用来做校验，甚至对测试也用处不大。 另一方面，对所有属性都在数学上加以证明的完整的形式规范，成本很高也很耗时，而且需要相关领域的专家才能搞定。这种做的效果当然是最完美的，但是我们可以有这么一个折中的方案：形式化地描述模型及其属性，然后我们可以用QuickCheck对其属性进行测试。 另外，基于这个模型我们可以对核心功能进行分析，并最终和真实实现进行比对。

IOHK对新钱包的开发是开源的，相关代码可以在 Github 上找到。 有趣的是，IOHK最近还招了人去实现Coq版本的钱包规范，这会把整个规范建立在更加坚实的基础之上。当然，这不代表目前的工作就没有意义，虽然这样的话，在模型实现中去测试不变量不再必要，但是有QuickCheck生成器去测试真实实现还是很有价值的。另外，在实际去证明不变量之前先用QuickCheck测试一遍，如果这个不变量确实不成立的话，可以帮助我们提早发现问题，从而节省宝贵的时间。

编译运行Cardano钱包后端

Windows和Mac系统，直接使用官方发布的钱包安装包即可。

Linux系统需要自己编译，编译过程如下：

1. 安装nix ，在非root账户下运行:

   $ curl https://nixos.org/nix/install | sh
   

   运行后会自动配置当前环境，重新登录当前终端即可生效。

2. 配置IOHK的Binary Cache：

   $ sudo mkdir -p /etc/nix
   $ sudo vi /etc/nix/nix.conf       # ..or any other editor, if you prefer
   

   添加：

   binary-caches            = https://cache.nixos.org https://hydra.iohk.io
   binary-cache-public-keys = hydra.iohk.io:f/Ea+s+dFdN+3Y/G+FDgSq+a5NEWhJGzdjvKNGv0/EQ=
   

3. 取cardano源代码：

   $ git clone https://github.com/input-output-hk/cardano-sl.git
   $ cd cardano-sl
   $ git checkout -b release/1.2.0 origin/release/1.2.0
   

4. 编译：

   $ nix-env -A cardano-sl-wallet-new --install --file .
   

   因为有Binary Cache，应该很快，成功后在目录 ~/.nix-profile/bin/ 中会多一个 cardano-node 的可执行文件，这个目录在安装nix的时候已经加入到 PATH 了。

5. 另外整一个运行的目录，把相关配置拷贝过来：

   $ mkdir ~/cardano-wallet
   $ cd ~/cardano-wallet
   $ mkdir lib
   $ cp /path/to/cardano-sl/lib/{configuration.yaml,mainnet-genesis.json} lib
   $ mkdir scripts
   $ cp -r /path/to/cardano-sl/scripts/tls-files scripts/
   

6. 创建文件 wallet-topology.yaml ，内容如下：

   wallet:
     fallbacks: 7
     valency: 1
     relays:
     - - host: relays.cardano-mainnet.iohk.io
   

7. 运行:

   $ cardano-node --topology wallet-topology.yaml --configuration-key mainnet_wallet_linux64
   

8. 验证钱包V1 API工作正常：

   $ curl --cacert scripts/tls-files/ca.crt https://localhost:8090/api/v1/node-info
   {"data":{"syncProgress":{"quantity":92,"unit":"percent"},"blockchainHeight":{"quantity":1072633,"unit":"blocks"},"localBlockchainHeight":{"quantity":996101,"unit":"blocks"},"localTimeInformation":{"differenceFromNtpServer":{"quantity":-147487,"unit":"microseconds"}}},"status":"success","meta":{"pagination":{"totalPages":1,"page":1,"perPage":1,"totalEntries":1}}}
   

使用V1 API实现冲提

Cardano钱包API是符合swagger规范的，使用任何语言对swagger的封装即可使用，这里提供一个 使用python的pyswagger的示例 。