区块链神吐槽信息安全专业博士，毕业于中国科学院信息安全国家重点实验室，长期从事信息安全研究工作，在P2P网络安全、物联网安全和区块链安全等方面有较深的研究积累。目前为白墨子安全实验室创始人、墨客区块链公司首席安全官，并担任多家区块链公司的信息安全顾问。
信息安全对于区块链行业意味着什么？目前的安全态势如何？
区块链行业是一个比较特殊的行业，最突出的特点就是涉及大量数字资产的管理，动辄千万上亿的资产全部存在链上，通过一个256比特的私钥来确权，谁掌握了这个私钥，谁就是资产的主人。
这使得信息安全在区块链行业的重要性空前提升。可以说对于区块链行业来说，没有安全就没有一切。这不是危言耸听，随着各类安全事件的不断披露，区块链行业对信息安全的重视度也持续升温。
可以说，目前信息安全已经成为区块链产业发展的关键环节。
那么，如何评价目前的安全态势呢？我们同意派盾公司的判断，如果把目前的区块链安全划分为非常安全、安全、令人堪忧、极度危险四个等级的话，现阶段区块链安全是令人堪忧的。
黑客对于攻击区块链兴致持续高涨，主要原因如下：
- 区块链技术带来的资产数字化，使得大量数字资产存储在链上，不光人人都看得见，让黑客还有了摸得着的机会，在巨额资产的诱惑下，黑客的攻击动力几乎是无限的；
- 数字资产变现非常容易，与传统的数据盗窃然后非常费劲的变现不同，数字资产可以直接通过7*24的交易所变现；
- 数字资产的匿名特性使得黑客非常容易逃避追查，安全性更高。
- 区块链技术虽然是去中心化的，但是这个行业存在大量的基础设施是中心化的，并且区块链的实现也依赖于很多传统的IT基础设施，如手机、云主机、web service等，这使得黑客可以借助原先的技术手段和工具，攻击门槛并不高。
高额收益、容易变现、极易逃避追查、攻击门槛低，这四者的叠加，使得区块链安全事件将持续处于高危期。
区块链安全主要涉及哪些方面？有哪些热点问题？核心问题是什么？谈一下墨子安全实验室对区块链安全的理解，以及主要的安全服务内容？
区块链安全防护是一个系统性工作，涉及的环节很多，不但有很多传统安全方面的工作，如云主机防护、通信安全、手机安全、APP防护等，还有大量的特色安全内容，如智能合约安全、矿池风控、交易所安防等。
从墨子安全实验室的角度，我们一般把区块链安全分成两类五方面。
第一类，区块链自身安全，这一类包括两个方面：区块链底层安全和上层智能合约安全。
第二类，区块链配套设施安全，这一类包括三个方面：钱包、交易所和矿池。
这五个方面都属于区块链安全范畴，我们认为其中三个方面是需要特别关注的热点问题，即智能合约、交易所和钱包。这也是安全问题比较多、安全事件比较频发的地方。
如果要说区块链安全的核心是什么？我们认为就目前的区块链发展现状，安全问题虽然很多，但核心只有一个，那就是数字资产安全。区块链安全领域的攻守两方基本上都是围绕着这一点来的。
这也影响到了区块链安全行业对安全漏洞的评级标准的制定。与其他行业不同的是，区块链行业中，凡是威胁到数字资产安全的，一律评定为高危漏洞，否则评定为中危或低危漏洞。
墨子安全实验室的安全服务也主要是围绕我们所认为的区块链安全热点问题开展的。鉴于我们实验室规模有限，所以也一直不断凝练和聚焦我们的工作方向。
目前主要是三方面的工作：
- 区块链安全测评方向：包括区块链底层测评、智能合约安全审计和测评、钱包安全测评、交易所安全测评和矿池安全测评。
- 数字资产安全防护方向：包括事前的风险教育、钱包选择、环境检测，事中的私钥管控、转账管控，事后的私钥缺失找回和丢币追踪、应急响应等。
- 安全数据可视化方向：包括区块链运行态势监测、DAPP运行态势检测与异常行为预警、资金流转检测与异常告警等。
此外，我们也提供安全培训、安全技术咨询、安全开发支撑、真随机数等服务。
智能合约安全问题的本质是什么？智能合约最常见的安全问题有哪些？为什么智能合约安全问题如此频发？2016年年中，以太坊上最大的众筹项目the DAO编写的智能合约出现漏洞，被转走300多万枚以太币，市值近6000万美元，迫使以太坊开发人员执行“硬分叉”将资产找回。请分析这件事的影响和启示。
在我们看来，智能合约安全的本质是合约意图和实际实现之间的差异。换句话说，就是开发人员以为要做的事跟合约实际执行中所做的事出现了不一致。这一定义几乎可以囊括所有的智能合约安全事件，我们认为是比较符合安全本质的。
智能合约常见的安全问题包括：重入攻击、计算溢出、越权访问、交易顺序操纵、拒绝服务等。
合约安全问题的频发，有三个方面的原因：
- 因为智能合约往往涉及数字资产的发放和管理，对于黑客来说，攻击合约的产出投入比是非常可观的，有足够的动机；
- 智能合约是一个非常新的事物，从以太坊提出到现在不过四五年的时间，还存在一些缺陷需要弥补，问题迭出也是成熟过程中不可避免的，这也是促使合约技术成熟必不可少的，合约技术的真正成熟还需要时间；
- 因为现有的一些合约开发人员，对智能合约的本质理解不到位，对智能合约的开发不熟悉，对合约的运行环境理解不清，还是一味地照搬之前的老思路，导致问题频发。
关于DAO事件，先大概介绍一下事件本身。
The DAO安全事件是以太坊发展史上的一次重大安全事件，大概过程是这样的：就是有攻击者利用DAO智能合约可重入攻击的安全漏洞，盗窃了大量DAO募集的资金。具体来说就是攻击者让自己的提现过程反复重入，按照系统限制，同样的取款操作攻击者可以反复执行1024次，这样计算下来，使得存款100的用户可以取现102400。
我们认为The DAO事件是以太坊发展过程中的一个重要里程碑，不能单纯地看作一次安全事件，需要从多个角度来看。从不利的方面来说，一度几乎让以太坊陷入灭顶之灾，实际上也确实导致了以太坊社区的大分裂，以太坊社区元气大伤；从有利的角度来说，通过这次事件，以及对这个事件如何处理的大讨论，让整个社区迅速从幼稚走向成熟，让以太坊后续发展越来越稳健，最终成为无可厚非的区块链2.0代言人。
DAO事件带来的启示，我认为主要有两点：
- 发生安全事件并不可怕，也是难以避免的，重要的是能否采取正确的应对措施，并吸取教训，教育社区，让安全事件成为生态健康发展的养料。对于ETH来说，通过DAO事件的考验并成熟起来了，因此我们成为是以太坊发展史上的里程碑，如果以太坊因为DAO事件折戟沉沙，那只能称为以太坊发展史上的墓碑。
- 处理问题的正确态度应当是原则性和灵活性兼备，极端的原教旨主义并不可取。ETH社区对于DAO事件的处理就有两种截然不同的分歧，一方认为对于这种证据确凿的攻击行为，为避免重大损失，应当回滚账本，另一方认为区块链和智能合约的根本在于可信和不可篡改，因此应当愿赌服输，不应该回滚账本。后者我们称之为区块链的原教旨主义者。最终双方谁也说服不了谁，于是分道扬镳，由此以太坊分裂为ETC和ETH两个币种，相应地，以太坊社区分裂为两个社区。从这几年的后续发展来看，ETH社区的发展明显优于ETC社区，后续处于不断萎缩的状态。实践是检验真理的唯一标准，因此，我们认为，前者处理问题的态度更值得我们借鉴，后者的极端化思路需要警惕。
美图BEC溢出清零事件的影响和启示是什么？
先简单介绍一下计算溢出是怎么回事。所谓计算溢出就是计算结果超出了系统能够正确表示的数值范围的最大上限或者下限。前者称为上溢出，后者称为下溢出。例如以太坊的数值上限是2^256，超过这个数字系统就无法正确表示，也就是说在这个数值范围之外的计算结果是错误的，但合约意识不到，继续使用错误的结果进行后续流程，这样就会导致严重的后果。
计算溢出攻击是区块链安全中最常见的攻击手段，其中美图BEC溢出清零事件是此类攻击的巅峰之作，直接导致一个最高市值一度630亿美元的数字币直接归零。
事件的起因是BEC合约中的转账函数缺乏溢出检测机制，攻击者利用这一点直接赋值实现结果溢出，结果超发天量的BEC币。BEC币的总量是10亿枚，最终超发的结果是总量变成57,896,044,618,658,100,000,000,000,000,000,000,000,000,000,000,000,000,000,000个，直接导致币值崩盘，数亿美元资产灰飞烟灭。
这一事件的发生，让业界对计算溢出问题有了充分的重视，并大量使用safemath库，避免溢出问题的发生。但是在实际工作中，类似的错误依然屡见不鲜，因为计算溢出是一个常见的现象，在其他行业中也很常见，但后果相对较轻。在区块链时代，涉及到数字资产的计算和转账，那么计算溢出的后果就严重多了，BEC就是一个典型的例子。
目前，这个问题虽然可以通过引入safemath库来得到很大程度的缓解，但并没有得到本质的解决。我们认为，溢出问题是底层错误，因此应该从底层解决才是彻底的解决方案，从上层加强检查固然在一定程度上可以缓解，但是只能治标不能治本。同时还带来很多副作用，比如给开发人员带来很多额外的负担，导致开发效率的低下，同时隐患没有彻底排除，随时会有爆发的可能。
因此，我们希望在将来的区块链技术中，可以从底层使这一安全隐患得到彻底解决，从此远离计算溢出的安全阴影。
请分析EOS彩虹攻击事件的原因、影响，以及对从业者的启示。
EOS彩虹攻击事件的本质是随机数问题。问题的根源在于部分私钥生成工具允许用户采用强度较弱的助记词组合，而通过这种方式生成的私钥很容易被“彩虹”攻击，进而导致账户数字资产被盗。
钱包的安全基础是随机数种子，凡是随机性不够的，如使用“12345678”、“123456”等弱口令当助记词，或是使用之前各大网站已泄露的密码库中的密码当助记词的，统统存在账户被盗的风险。
随机数的核心要义是不可预测性，这也是对随机数最基本的底线要求。一旦随机数被人预测到，则基于随机性的安全体系将立刻崩塌。用通俗点的语言来说，随机性的本质是猜不到，如果你使用的随机数可以被人猜到或者推测出来，那么就不是随机数，或者随机性不够。随机数虽然看起来不起眼，但它却是信息安全的基础之一，由于随机数问题导致的安全事件层出不穷。
特别是在区块链世界里，我们的资产安全其实就是依赖于一个随机数来保护。如果这个数字被人猜到了，那么资产也就变成别人的了，如果别人怎么也猜不到，那么资产就是安全的。
随机数在区块链世界中的作用如此重要，承载了数千亿美元的资产，因此对于随机数问题万万不可轻忽。随机数生成器有真随机和伪随机之分，伪随机数生成方便，成本低，但是随机性有限，真随机数生成条件苛刻，要求高，但是可以实现真正的随机性。
普通场景使用伪随机也足以满足使用，但对于区块链这样涉及大额甚至巨额数字资产保护的行业，为了你的资产安全，我们强烈建议使用真随机数。
软件钱包和硬件钱包的主要区别是什么？使用上有什么建议？
软件钱包和硬件钱包最主要的区别在于私钥的保存和使用方式。
软件钱包成本非常低，使用起来非常便利，但是用户的私钥一般是通过加密等方式保存在本地，然后在使用的时候解密。这样就导致一个比较严重的安全问题：至少在某一段时间内，私钥会以明文的方式出现在本地，从理论来说，是可以被攻击者获取或者泄露的，这样就对数字资产的安全造成了直接的不可忽视的威胁。这也是软件钱包在安全上最大软肋。
而硬件钱包则不然，硬件钱包成本较高，使用上相对不便，将私钥保存在加密芯片中，通过特殊设计的控制电路，使得私钥无法给读取出去，只能在芯片内部使用。这样，用户在转账的时候，看不到私钥，只能得到私钥签名之后的密文，这使得私钥的泄漏和被窃取的风险降到最低，这是硬件钱包最大的优点。
结合两者的优缺点，软件钱包和硬件钱包分别有不同的应用场景和使用方式。软件钱包适合数字资产数量有限，使用频度较高，对于便利性要求更高的用户。
硬件钱包适合数字资产额度较大，需要更高安全保护等级的用户。通常的建议是使用软件钱包保存自己的小额资产，供日常使用，硬件钱包保存大额资产，轻易不动，这样可以实现便利性和安全性兼备。
目前已经出现软硬件结合的数字钱包方案，在很大程度上结合了两者的优点，对于用户来说是一个更佳的选择。
私钥保存在常见的错误有哪些？怎样保存私钥才安全？助记词和私钥是什么关系？
私钥保存的常见错误是将私钥保存在云盘、云笔记、邮箱中，或者用手机拍照保存，这都是非常危险的容易泄露私钥的方式。
对于私钥保存，我们建议如下：
1. 用纸笔保存，不要依赖电子设备，因为电子设备容易出安全事件，也存在出现安全故障的可能；
2. 纸笔记录后要反复确认，主要有以下几点：
（1）私钥位数是否正确，是否有遗漏或者重复记录（这种情况我们见到过很多次）
（2）对于私钥中容易混淆的字母、数字要特别加以标记，如w与W，P与p，q与9等。
3. 建议分多份保存，避免因为物理损坏、丢失等造成不可预料的后果。
前面我们说过很多私钥记录的不便之处，因为私钥本身是给计算机使用的，对人来说可读性非常差，上面说得诸多问题很多时候都是由此而起，因此对于纸笔记录，我们更推荐使用助记词的方式。
助记词实际上是二进制的另外一种表现形式，重点突出对于人的可读性。在实践中，助记词一般用来记录密钥种子，从这个种子可以产生出用户使用的私钥。实际上，也完全可以将原始私钥映射为助记词来使用，尽量避免直接记录原始助记词。
区块链应用开发者，特别是智能合约开发者，以及普通用户，在安全方面应当注意哪些问题？
对于基于区块链的应用开发者，特别是智能合约开发者来说，我们提供如下建议：
1. 对于开发人员提供必要的安全培训，提升安全意识，引入SDLC安全开发生命周期管理流程；
2. 开发中建议使用推荐安全框架，多参考成熟的安全范例和安全模板
3. 要尽快转化并习惯“去中心化”思维，时刻提醒自己：你面对的是良莠不齐的纯分布式环境，不是传统的中心化开发环境。
4. 不要轻信，要验证，不要使用自己发明的密码算法，谨慎对待随机数、哈希函数等貌似不起眼的算法，仔细审查使用的每一个第三方库，避免被钓鱼
5. 补齐密码学和信息安全的基础知识，了解基本的安全攻击手法；
6. 不要有依赖心，项目的安全性取决于开发者自身，而不是采用某种平台或某种语言
7. 不要存侥幸心理，发现问题马上纠正，不要嫌麻烦，安全来自长期警惕，事故源于瞬间麻痹。
8. 建立完善的安全审计机制，建议聘请第三方安全顾问，不要因为省小钱损失大钱。核心模块必须经过严格审计
9. 上线前充分的测试和安全审查，因为智能合约一旦部署纠正成本很高
对于普通用户而言，我们的建议只有一件事：保护好自己的私钥。
最近FACEBOOK公司的Libra项目，引起业界高度关注。可否从安全的角度对Libra项目做一个简单点评？
libra的出现对区块链行业来说是一件大好事，所以我觉得在谈Libra的安全问题之前，首先要肯定Libra在安全方面付出的努力，对于后来者具有很好的参考和借鉴价值。就我们目前针对libra的技术调研来看，Libra吸取前期教训，充分意识到安全的重要性，在安全方面付出了很多努力，包括我们看得见和看不见的。
时间有限，我们简单说一下Libra在安全方面所做的一些工作。
首先，架构设计上，采用了可信计算方面的概念。Libra把可信计算基（Trusted Computing Base）的思想用在了核心代码的架构设计和编写中。可信计算基是计算机系统安全领域的一个概念，指计算机系统中对系统安全性最重要的一部分，和其他的部分隔离，以保障这部分核心安全组件的正常运行。
Libra Core中也试图将软件中的重要部分打造成可信计算基，对依赖库和其他代码的依赖性做到最小，节点功能由几个相对独立的组件实现，将重要的部分和其他不太重要的组件实现隔离。
另外，作为区块链系统的底层基础，Libra的P2P网络使用了Noise协议，这个协议也用在国外的Whatsapp中，这是一个社交通信应用，安全性更好。
要加入验证节点池，节点必须通过当前验证节点池里的某个网络公钥进行认证。验证节点池启动阶段需要一些种子节点，种子节点认证新的验证节点。这样可以抵御Ethereum 类的区块链中常见的地址池污染，提高恶意节点加入的门槛。
其次，合约方面。Move 是从迄今为止发生的与智能合约相关的安全事件中吸取经验而创造的一种编程语言，能从本质上令人更加轻松地编写符合作者意图的代码，从而降低了出现意外漏洞或安全事件的风险。
特别值得指出的是四个方面的工作：
一方面，节点的数据和代码隔离，代码叫做Module，数据被视作资源单独存储在另一个模块Resource中。在计算机架构设计中是比较安全的做法。
另一方面，Move的设计更有利于静态验证。因为代码审计领域，静态验证是发展最成熟的领域，如果语言对于静态验证比较友好，那么就很容易发现其中存在的安全问题，有利于安全检测。
为此，Move不支持动态派遣（dynamicdispatch），就是说每个被调用的对象都是可静态确定的，不会产生复杂的控制流图（CFG），也避免产生Ethereum合约中经常出现的重入攻击漏洞。Move中的变量的类型是相对静态固定的，避免类型转换中经常发生的错误。模块化程度高，便于应用静态分析工具。
第三，Move把数字资产不是看作普通的数据，而是视为一等资源（First-Class Resource），设计中考虑到满足一等资源的稀缺性、访问控制，一等资源可以创建、销毁，但是进入Libra后，不能被复制，只能被移动（moved），这也是Move 语言名字的来源。这样让move语言具备了明确的资产程序语言的特性，有效避免了使用普通程序语言处理金融资产所可能带来的各类安全隐患。
最后，代码每次被运行前，都要经过链上的安全验证，类似JVM中的加载时字节码的验证，这在一定程度上保障了被执行代码的安全性。
再次，共识机制安全。
共识机制安全是区块链安全的生命线。Libra 区块链采用了基于LibraBFT共识协议的BFT机制来实现所有验证者节点就将要执行的交易及其执行顺序达成一致。而LibraBFT基于2018年新提出的HotStuff协议，一种基于leader的拜占庭容错复制协议，包括关于安全的投票/提交承诺规则和保活机制，允许恶意节点（即拜占庭容错参数）不超过总数的1/3.
这种协议的特点是几乎不会分叉，实时确定性好，特别有利于Libra未来很可能会重点关注的支付、汇兑和资产交易场景。
第四，实现语言安全。rust语言的特点是注重安全性，在编译环境强调规范的使用和检查，通俗地说，只要编译通过，安全方面就具有了较高的水准。因此rust安全性较高，是一种在安全方面比较有特色的语言。
简单介绍一下Libra在设计和实现上存在的一些不足。
Libra肯定会存在漏洞，它们自己也公布了赏金猎人计划，征集漏洞。但是目前尚无确定性的漏洞被指出。但是，根据我们对区块链安全的测评经验，认为Libra在下面几个方面会存在安全问题有待解决。从目前对Libra的初步研究成果，Libra虽然已经尽力解决前期发现的安全问题，但是距离彻底解决还有不小的距离。
1. 共识机制安全：
Libra的共识机制最近闹得沸沸扬扬，起因是一篇文章指出Libra的共识机制存在严重安全问题，并宣称攻破了核心的LibraBFT共识协议。目前Libra 尚未对该文发表回应，而该文发布6天后被作者自行撤回。我们找到作者发表的相关文章进行了研究，就这一问题大概给大家解读一下。
“AnotherLook at Byzantine Fault Tolerance”指出BFT解决方案里的一些问题，并以HotStuff为例，例如PBFT和HotStuff 需要可靠的广播信道，一旦广播信道不可靠，就不会达成共识，即使这些协议的前提条件“部分同步网络”满足，也不能达到共识。
作者之前发布过对Algorand的分析，指出Algorand在BFT不超过1/3的情况下，可能发生分叉，并且指出BFT解决方案中的一个普遍假设“大多数节点是诚实的”并不合理，因为在利益驱动下，任何节点都可能不遵守事先约定的行为规则，反倒是比特币的假设比较合理，比特币假设任何节点都可能是恶意的，但是假设这些恶意节点被统一到同一个攻击者麾下，协调组织起来联合作恶的概率是很小的。Algorand至今也未对该分析做出回应。
我们认为，共识协议是区块链的核心，共识协议的安全决定了区块链的安全。BFT类的共识协议适合联盟链或私有链，一旦要用于公链，需要非常慎重。Libra也声称自己要从联盟链出发，等成熟后再推出公链。基于Libra的远景目标，Libra的交易会影响各国法币的流通状况，如果在共识协议的安全性不太确定的情况下成为公链，会吸引各国的黑客，甚至有可能导致国家力量介入，那时后果不堪设想。
2. 虚拟机计算溢出处理机制：没有看到libra在这方面有什么建树，如果依然依赖合约的自我约束和代码检查，那么距离理想的解决方案，还有一段距离。
3. 随机数：Libra 使用Rust的rand::rngs::EntropyRng 作为种子生成私钥、密钥。而EntropyRng首选采集操作系统的随机数生成接口OsRng。如果失败，采用JitterRng生成器，基于CPU执行时间、内存访问时间等系统操作的抖动，随机性比OsRng要好，但是性能上比较慢，因为需要等待足够长的时间。
在Secret Service 代码库中使用了Rust的基于流密码算法ChaCha的随机数生成器ChaChaRng, 密钥的导出未来将支持前向安全性（ forward security）, 即当前密钥的泄露不会危及以前使用的密钥的安全性， 后向安全性或泄露后安全性，即当前密钥的泄露不会影响未来可能生成的密钥的安全性、以及增强的熵。
随机数种子的安全性方面和现有的区块链持平或更好，但是并未采用真随机数，可能是项目方认为目前的随机数产生机制已经足以满足要求，或者在未来的升级中再进一步采用真随机数。
4. 第三方库依赖：无较大创新，与之前的区块链项目持平。
5. 实现语言：
选择了一个非常小众但宣称安全性突出的语言RUST。但语言的安全无法确保实现的安全，因为我们知道，安全的关键是人，是设计者、开发者，如果开发者安全意识和水平够高，不安全的语言可以可以开发出安全的产品，反之，程序员不靠谱，再安全的工具和平台也无法阻止他犯错误，甚至很低级的错误。
漏洞常常来自代码实现过程。比如Rust代码，RUST本身的库函数，使用的其他第三方库的安全性。Libra生成随机数的函数就是用的RUST本身的函数，RUST社区也在讨论随机数生成函数的安全升级。所以RUST语言虽然具有安全的特色，但是并不完美。
6. 单一性依赖问题：Libra如果完全依赖RUST语言实现，那么会存在单一依赖问题，如果RUST语言出现安全问题，则会波及整个Libra系统，这一点可能需要时间来解决。
7. 一些想法只提出没实现：
Libra含混的提到当私钥泄露时，可更换公私钥对，而账户地址保持不变，用户也可轮换一个账户里的密钥。这是一个非常好的想法，可以提升用户的便利性。由于传统区块链地址是由公钥变换得到的，而私钥和公钥是一一对应的，不知道Libra采用什么方式实现公钥和地址的脱离。但是我们看目前代码中的账户地址还是公钥的keccak哈希值，不具备更换的能力。我们也很期待看到Libra项目在这里有所突破。
智能合约交易顺序操纵是如何做到的？如何防范？
这是因为矿工在打包交易的时候，有一定的自主权限，他可以确定那个交易放在前面，那个交易放在后面。这个顺序按照惯例，是谁gas费给的高，谁就优先打包。这样，攻击者可以通过设定非常高或者非常低的gas，诱导矿工按照他的意图打包交易，达到操纵交易顺序的目的。
防范措施，建议不要认为同一个区块内交易的先后顺序就是交易实际发生的顺序，不要基于这个假定来设置条件。因为区块中的内容和顺序作为矿工打包的产物，实际产出是可以被操纵或者诱导的，不宜作为可信的信息。
安全数据可视化中的资金流转检测是怎么做到的？可以追踪洗钱的路径吗？
这得益于区块链账本数据的公开透明，通过对原始数据的汇总、清洗和挖掘，是可以追踪每笔资金的转移路径的。我们主要是从安全的角度对资金流转过程进行分析。
区块链中的原始数据无法直接分析，必须要进行整理之后，利用大数据挖掘技术，发现有用的信息。但是对于账本不公开的匿名数字币，目前没有太好的办法追踪。
区块链链行业中的洗钱行为，如果是传统的混币洗钱，相对而言还可以抽丝剥茧，慢慢梳理。但是天生匿名的数字币，如门罗等，就没法监控了。
Libra为什么选择RUST这么小众的语言呢？有没有更优的选择？
我不是Libra官方，按照我们的推测，Libra选择RUST语言的初衷，应该是看中了RUST的安全性。因为对于Libra宣称的跨境汇兑来说，安全性是第一位的，这个选择在某种意义上也是给未来的潜在客户看的，让客户放心地选择Libra。
至于有没有更优选择，这个选择需要放在Libra的整体场景和发展目标下看，是多方权衡妥协的结果，从来就不是一个单纯的技术问题。我相信，Libra选择RUST语言也是这样一种妥协的结果，因为Libra最了解自己要做什么，自己的目标是什么，自己的客户是什么，所以我们无法帮助Libra作出更佳选择，不在其位不谋其政。
但是为了避免单一依赖问题，Libra未来必将会选择多种语言实现，以分散风险，确保系统整体的鲁棒性。
备选语言，我想应该会有Java/C++等老牌劲旅，也会有Go等新锐，Libra的路刚刚开始，未来的路还很长，现在很多地方还存在争议，所以现在很多选择都存在变数。
安全漏洞比例最大的是内存安全问题，（见微软安全响应中心的文章，70%的安全漏洞是内存问题引起的）。而Rust语言的安全性恰恰就是解决内存安全（常见的内存安全问题，当然不完美，也不可能完美）。内存漏洞是跨语言漏洞，多用一种语言就多一份风险，其实并不能改善安全性。
这是一种经典的安全防护思路，安全问题必须从整体上考虑，不能只看局部。区块链作为去中心化的P2P架构，不怕部分节点出问题，担心的是全部节点出问题。因此如果单一使用rust语言实现，谁敢打包票说rust万寿无疆、刀枪不入？万一某天rust爆出系统性漏洞，Libra就全军覆没了。因此为了实现系统级的安全，必须要把风险分散。如果所有的rust部署节点出问题，在解决rust问题期间Go语言节点还可以支撑系统运行，Go语言出问题，在解决Go语言问题期间Java节点也可以让系统正常运行。那么如果rust，go，java同时出问题呢？概率比rust一个出问题的概率小多了啊，这就叫千斤重担万人挑，人人头上有指标。
锌链接
微信号：xinlianjie-
功能介绍：探索产业区块链价值
©本文版权归“锌链接”所有，欢迎加入我们的社群，公众号后台回复"入群"即可。
