紫云探币
当病毒带来的恐惧在蔓延，区块链可以做些什么？
在灾难面前，人类展现出了脆弱的一面，但同时，我们也展现出了自己强大的一面。
随着武汉疫情的持续发酵和蔓延，与此相关的每一个进展，都在牵动着全国乃至全球人民的心，在新闻里，我们看到的数字每一天都在跳动，而这些数字背后，正是一个个鲜活的生命。
突如其来的疫情，让原本存在的问题被无限放大，而人性的善与恶，也在这一刻显露无疑。
我们惶恐着，我们也期盼着。
是的，人类的身体依旧很脆弱，但我们，可以用不断发展的新技术武装自己，从而战胜眼前的艰难！当下，我们已经拥有了大数据、云计算、AI、物联网、区块链等新兴技术，而在这场灾难中，它们必将会发挥出自己巨大的作用。
而作为区块链行业的一份子，我们会思考它能够为疫情的控制提供什么帮助？
对此，有人提出了疾控预警方案，也有人提供了区块链公益解决方案，诚然，这些提议都是非常好的，但我想，当下我们其实更需要的是能够帮助到医疗的方案。
在新闻上，我们会看到有部分感染者在没有被确诊的情况下，他们选择拒绝被隔离，而这恰恰为疫情的控制带来了巨大的麻烦。
那究竟是什么原因造成的呢？答案其实很简单，源于恐惧。
除了对未知病毒的恐惧之外，人类还对隐私暴露拥有心理恐惧。而早期患者信息的大量泄露，以及现有医疗系统具有的特性，正放大了这种恐惧。
而缺乏信心，害怕尴尬或泄露私人信息可能导致患者不愿提供准确信息，或在某些情况下可能提供虚假信息，从而影响治疗方案，引起公众健康担忧，甚至导致严重的健康并发症和死亡。
本期的分享，我们重点推荐刊登在美国国立卫生研究院(NIH)的研究论文《区块链如何保障数字化医疗》，希望能够帮助人们减轻这种恐惧。
而在硬核技术文章精选部分，我们还会看到私钥恢复方案、Mimblewimble非交互式交易提案、MPC密钥管理方案等内容。
（图片来自：tuchong.com）
一、如何用区块链改善现有的医疗系统
论文作者：来自阿联酋大学以及纽约石溪大学医学院的Khaled Shuaib、 Heba Saleous、Karim Shuaib以及 Nazar Zaki。
原论文链接：https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6789651/
人类会尽可能努力地保持健康，然后充实地生活，因此，医疗保健是每个人生活中的重要组成部分。为了使医护人员能够提供适当的医疗保健，患者病历会保存在诊所和医院当中。这些记录可帮助医生了解患者过去的诊断以及当前的健康状况。直到最近，依然有很多医疗记录是以物理档案保存的。尽管这对于医院或诊所而言可能不是主要问题，但对于患者而言，这构成了负担。纸质记录的其他问题，还包括（由于各种可能原因的）数据丢失，以及与数据恢复相关的困难。
而电子健康记录或电子病历（EHR / EMR）通过使医生更易于存储、查看、共享和更新患者记录，从而改善了医疗基础设施。然而，与任何电子记录系统一样，安全和隐私问题已成为这些系统的一个挑战。另一个问题是采用保存电子记录所需基础设施的费用。初始成本包括运行电子医疗系统所需的硬件和软件成本，维护、更新以及员工培训的成本。使用者必须具备基本的计算机知识，才能使用该系统。否则，在没有培训的情况下，医院工作人员最初会发现很难组织信息，并且很难在没有帮助的情况下生成和格式化报告。在不了解如何使用电子医疗系统的情况下，工作人员可能会存储或更新包含错误信息的记录。这可能导致错误的诊断，错误的医疗程序顺序，以及错误的药物和剂量处方，由此甚至会引发健康并发症，甚至导致患者死亡。这就是在实施电子医疗系统的成本中应包含员工培训这一项的原因。
但是，即使经过培训，引入新系统也可能导致最初的服务中断。
电子病历（EMR）系统的另一个问题是患者数据的碎片化。由于患者可能会去不同的诊所，因此零散的患者数据可能存在于不同的位置。尽管对患者数据进行数字化，已缓解了电子病历共享的问题，但主要问题仍然在于实现医疗信息系统之间的互操作性，因为诊所可能会使用不同的电子病历系统。这意味着患者的数据可能以不同的格式存在，而这或许会导致患者暴露于危险之中，因为将数据重新格式化为可读格式是需要花费时间的，而且可能还会丢失数据，另外，专业人员在数据库中填写信息的方式也不同。而在危险、敏感的环境（例如医院）中，一分钟对于病人而言，可能就是生死之间的区别。这也就是说，医疗专业人员不能因为零碎的记录和互操作性问题而浪费时间！
除了碎片化和互操作性方面的挑战外，电子病历（EMR）系统的使用，还可能会引起一些隐私问题，这是由于医疗保健基础设施并非是以患者为中心的。尽管患者拥有他们提供给专业人员的信息，但他们并不控制电子病历本身。这也意味着患者无法控制谁查看他们的数据，以及数据的发送和存储位置。
为了解决对患者隐私的担忧，一些区域已制定了一些法规，例如美国的《健康保险可移植性和责任法案》（HIPAA）和欧洲的《通用数据保护法规》（GDPR）。尽管这些规定可能会增加对患者数据更多的控制权，但它们并不能完全防止有意或无意泄露私人数据，因此，患者可能会继续对他们的数据被电子存储和交换而感到不安。
而组织内的电子病历（EMR）通常是作为数据库的一部分，集中式地存储在医疗基础架构当中。这种集中化的基础架构可能只有一个攻击点，其如果被网络罪犯成功攻破，可能会阻碍医疗服务。网络罪犯可以从窃取的电子病历数据中获益，要么将其出售给其他相关方，要么用它索要赎金，这就是所谓的“黑客勒索赎金”。此外，网络犯罪分子还可能利用患者的数据来试图为自己或他人获取处方药。
除了窃取和滥用患者的信息外，EHR和EMR系统仍然存在欺诈问题。欺诈有两种可能：处方药和保险。当处方的详细信息被更改或重复，以接收某些通常无法获得的药物时，就会发生处方欺诈。而当保险公司在降低福利的同时提高提供的保险价格时，或者当医疗专业人员为患者提出错误的诊断以提交虚假的保险索赔时，就会发生保险欺诈。这不仅导致患者的医疗保健成本更高，而且还允许医疗专业人员利用优势，将虚假信息描述为事实。
对此，学术界已提出了几种改进典型医疗基础设施的方法，而区块链技术也被纳入了进来。在最近几年，一些研究人员开始提议使用区块链来改善电子医疗系统，尤其是在处理EMR方面。这是由于EMR包含私人信息，而患者希望对未经授权的人员隐瞒信息，而这可通过区块链技术来实现。
1、1 区块链的概念
区块链最初是由中本聪创造的比特币而引入世界的。其对等网络（P2P）中的每个用户都被视为一个节点，发生的交易则被分组成区块。然后，这些区块以链状相互连接，而每个节点至少有一个公私钥对。其中，公钥用于将节点作为发送方或接收方进行寻址，而关联私钥，则被发送方用来对正在发送的交易进行签名，并由接收方来对其进行赎回。除了要求正确的密钥来解密和访问数据外，还需要在参与节点之间达成协议，然后才能进行更改。这确保了区块链账本的所有副本在整个网络中都是同步的。每当链上发生更改时，系统都会通知网络中的每个节点。由于区块是以这种方式链接在一起的，因此区块链是难以篡改的、半匿名的带有时间戳的账本。图1所示的概念，描述了区块如何以链的形式链接在一起，以及它们可能包含的数据类型。
而区块链去中心化、分布式的性质也使得网络攻击变得更加困难。由于账本的副本存在于P2P网络中的每个节点上，因此可实现交易数据的恢复。即便其中一个节点受到威胁或攻击，区块链网络中的信息和连接将依旧保持正常，这是因为它存在于所有其他节点中。由此，区块链也可以防止未经授权的数据修改。
截至目前，区块链主要有三种类型：公链、私链和联盟链，而区块链类型的选择要取决于用例，因为每种用例都有自己的功能要求。
顾名思义，公链是对公众开放的，它们是不需要许可的区块链，这意味着任何人都可以加入区块链网络来参与发生的交易。当一个节点尝试执行某项操作（例如修改或添加值）时，网络上的所有节点都会收到通知，并参与决策过程。公链最流行的一个例子就是比特币，任何人都可以加入比特币网络并参与区块链管理。
而私有链，则可能对组织是更有利的，此类型区块链仅适用于组织内的雇员，前提是他们选择成为节点并参与交易。对于组织外部的用户来说，私链是不可访问的，因此，我们也可以将这种区块链系统视为中心化系统。
而联盟链则要比私有链更开放一些，但由于它们对公众开放的权限有限，它们也可以被视为许可公链。在这种类型的区块链中，一组被选定的实体会参与交易验证以及区块链的管理。而公共用户可能会具有读取权限，但无法参与用于共识的决策过程。
而常见的共识算法有工作量证明（PoW）、权益证明（PoS）、实用拜占庭容错（PBFT）等。
1、2 区块链在医疗保健领域中的应用
虽然区块链最初被用于加密货币和金融交易，但也有其他应用需要用到不可更改、可跟踪的账本系统。而医疗保健，正是区块链可产生积极影响的一个主要领域之一。将区块链与电子病历系统集成，可有效帮助解决当前医疗基础设施中存在的一些问题。例如，患者可以对其数据传输给谁拥有更多的控制权。而当另一方（例如他们所指的医生或保险公司）试图与他人共享数据时，患者就会收到通知。由于被通知，患者将能够决定是否同意与他人共享其数据，并可以选择哪些人可以查看其医疗信息。
区块链为医疗保健带来的另一项改进，是能够保护EMR免受未经授权的查看和修改。按照区块链中交易发生的方式，除非用户持有访问数据所需的凭据，否则他是无权查看数据的。这有助于提高患者的隐私和安全性，因为只有授权方才能在通知患者的同时访问他们的数据。数据完整性之所以得以保留，是因为交易的不变性以及交易在区块链上的存储顺序。除非用户被授权并有权修改数据，否则数据就无法被修改。因此，患者将能够更自信地知道谁查看了他们的个人和机密健康信息。根据区块链的实现，患者可能拥有其数据的加密密钥，因此他们将能够选择哪些人有权查看其医疗信息。
而区块链的去中心化特性，确保了患者数据不仅可免受可能导致停机的攻击，而且还可以实现恢复。在传统的中心化存储环境中，患者记录将存储在可从医院内任何地方访问的数据库中。如果数据库遭到破坏或攻击，则可能会削弱员工访问病历的能力。万一有恶意方决定销毁数据，除非将文件备份到另一个系统上，否则EMR可能就无法恢复。而在区块链中，数据是分布式的，因此它们存在于网络中的所有节点上，从而在丢失或损坏的情况下可以进行恢复。
此外，区块链还允许将医院、保险公司和药店连接在一起，以改进提供的服务。而对当前医疗基础设施有益的一个例子，就是药物处方。当医生为患者开药时，授权药房和保险公司可以对其进行查看。药剂师将可以轻松地与相关的保险公司联系，以发现该药物是否属于患者的保险计划之列。将这些当事方联系在一起，可以减少目前为患者开具处方所需的文书工作和工作量。
图2描绘了如何通过区块链将参与医疗保健的各方进行连接的概念模型。
1、3 区块链在个性化医疗中的应用
随着EHR和EMR的引入，以及医疗系统的不断发展，个性化医疗越来越受欢迎。个性化医疗的概念围绕着根据某些常见因素（如基因组数据、种族、年龄或性别），然后对患者进行分类（例如，可根据测试收集的基因组数据对患者进行分类）。由于基因变异，患者可能面临的任何健康风险都可通过测试显示出来，看护人员也可以根据这些风险对患者进行分类。然后根据每个类别的特点，相应地提供治疗和健康计划。由于群体成员之间可能存在共同的健康问题，患者群体也可能成为药品广告的目标。
尽管个性化医疗为进一步改善医疗保健（尤其是电子医疗保健）铺平了道路，但这种模式可能会产生一些问题。首先要关注的是患者数据隐私的普遍问题。例如，通过基因组测试收集的患者数据可能还包括家庭健康风险。与此相关的一个问题是，有必要告知患者家属可能的家族健康风险，即使患者同意接受测试，他们也可能不同意暴露其基因组。与患者隐私有关的另一个问题是，可能需要患者的健康数据进行另一项研究，而患者有不同意的可能。这些隐私问题阻碍了患者对系统的信心，并可能阻止他们寻求医疗保健。
缺乏信心，害怕尴尬或泄露私人信息可能导致患者不愿提供准确信息，或在某些情况下可能提供虚假信息，从而影响治疗方案，引起公众健康担忧，甚至导致严重的健康并发症和死亡。
另一个问题是从患者那里收集的健康数据的可用性。运行测试的实验室可以将结果和原始数据存储在其服务器上。但是，如果由于任何原因需要另一方访问数据，则可能无法访问。请求访问数据并等待批准可能会花费一些时间，并且给看护者和需要征得他们同意的患者带来诸多不便。
而将区块链集成到个性化医学模型中，可以解决这些问题。只有拥有密钥以对数据进行解密的授权方才可以进行加密交易，从而可以防止其他人查看与其无关的健康数据。这增加了患者对医疗系统的信心，他们可确定只有少数人可以查看他们的私人信息，而每次交易发生时收到的通知以及所有交易的记录，也可以帮助患者放松心情。这种改进的可用性，为患者提供了向研究人员捐赠甚至出售其健康数据的机会，以供未来的患者及实验使用。
图3总结了如何将区块链集成到个性化医疗中。
由患者和现有临床记录生成的数据，在被存储到数据库或数据湖之前会经历加密和数字签名处理，这是因为原始数据量太过庞大的原因。来自临床试验的数据，也能以相同的方式记录和存储，研究人员能够追溯结果以发现数据的模式和相关性。当请求数据时，它会先经过身份验证和解密，然后再将数据透露给患者或看护人。从图3可以看出，区块链可以用作索引，以将用户链接到要查找的数据的实际位置。由于来自多个来源的原始数据（例如图像或实验室结果）可能会导致单个患者的文件很大，因此只能在区块链上传达数据链接。 而实际数据将严格存储在链下数据湖中。MedRec和Stony Brook Oncology项目就是这样的例子。使用此模型，患者不仅可以选择谁可以访问其数据，还可以选择出售数据或将其直接交给研究机构和制药公司。 除此之外，制药和保险公司还可以通过请求和利用存储的数据，以寻找区块链网络的潜在参与者。有关更多详细信息，请参见参考文献：《区块链技术在医学中的应用机会》
1、4 区块链医疗框架的发展
自2016年区块链与医学研究被首次提出以来，研究人员在实施区块链以改善医疗基础设施方面已取得了显著进展。
据信，首个用于医疗保健目的的区块链系统是由麻省理工学院（MIT）完成的，该学院的研究人员开发了一个MedRec项目，其目的是改善EMR的处理和交换。最初，该提案的作者试图解决四个主要问题：数据分散、互操作性、以患者为中心以及数据的研究。研究人员设计了三种合约来处理数据查询并在患者和看护者之间建立联系。然而，关于节点安全性、可扩展性以及来自区块链内连接的患者推断仍然存在着问题。在2018年，MedRec演变成一个可用的系统，并解决了第一次迭代中存在的一些问题。 MedRec 2.0通过引入通信的假名性来解决患者从交易中进行推断的问题，并改变了信息在区块链上的存储方式，以解决一些可扩展性和隐私问题。然而，从以太坊地址的元数据以及节点或提供商数据库的安全性来看，患者推断仍然是一个问题。
MedRec项目详细资料链接：https://medrec.media.mit.edu/technical/
与此同时，越来越多的区块链医疗方案和系统开始涌现，而它们着重讨论的两个主题是：
- 如何将区块链与医疗集成以改善不同领域的服务；
- 如何使用区块链来改善EHR和EMR的处理；
如图4所示，与其他类型的论文相比，在2017年和2018年，我们可以看到更多与区块链医疗基础设施有关的模型提案涌现了出来。该图还显示，2019年的文献综述有所增加，这可能是由于研究者在2017年和2018年发表的模型和理论论文数量过多所致。而根据这些文献，我们就可以回顾这些工作，以确定区块链在医疗领域研究存在的问题，以及未来可能的关注重点。
其中，这些文献特别关注的一个领域是使用区块链技术来改善EHR和EMR服务。图5描述了这种趋势。
而这些模型或理论工作，主要使用的是两种平台：以太坊和超级账本Fabric。
其中，大多数模型和理论（19篇研究论文）建议使用以太坊作为基础平台，而另外有4篇文献则讨论使用超级账本Fabric框架。
而在13个实践项目当中，有10个项目选择使用了以太坊，而其他3个项目则使用了超级账本Fabric，如图6所示：
这些项目当中，大多数都试图遵守HIPAA指定的数据隐私法规，它们还实施了假名技术，以便在链内交易期间掩盖患者的身份。虽然这些项目解决了隐私和安全问题，但仍有一些技术问题有待解决。 例如，某些项目面临着系统可扩展性问题。在测试时，这可能不会造成问题，但在实际应用时就需要考虑到用户数量。
这些项目的时间表可以在图7中看到：
1、5 讨论
在审阅了有关如何使用区块链来改善当前医疗系统的文献之后，我们可以尝试回答以下这些问题：
问题1：如何使用区块链来改善医疗保健信息系统？
答：
通过相关文献，我们可以看出，在医疗保健中使用区块链的初步探索是要解决现有EHR / EMR系统的问题。区块链解决的第一个问题是EMR的风险存储和共享。当前，人们会担心患者信息未经授权就被他人查看，而研究者们则提出将区块链作为保障EMR安全性的唯一解决方案，或者作为现有解决方案的一部分。问题2: 为医疗保健系统实施区块链时，重点关注的领域是什么？
除了保护患者数据免遭未经授权的访问外，医疗区块链的实施，还提高了访问和修改审核的能力。每当区块链上的任何其他实体尝试访问其数据时，系统都会通知患者。而作为EMR的所有者，患者将能够允许或拒绝对其数据的任何访问或修改，其可以选择共享其数据，甚至可以将当事人列入白名单以便于访问。
除了提高EMR安全性，区块链还被用于管理药品供应链。而这是通过将区块链和智能合约集成到IoT设备中实现的。关于药品，还可以考虑使用区块链来检测处方欺诈。
还有一些研究文献，则探讨了将区块链与医疗可穿戴设备一起使用。现如今，一些患者会佩戴医疗设备，这使看护人员可以从远处收集患者的身体状况数据。由于区块链具有自动处理数据的能力，研究者就提出了用区块链来改善远距离的患者监测，这进一步使患者和看护人受益，因为可以在一天中的任何时间实时访问数据。一旦某些阈值或事件发生，将智能合约与区块链一起使用，可以允许将警报发送给所涉及的看护人。
最后，围绕链上通信和数据交换的系统架构已经有了一些改进。医疗保健专业人员需访问数据（例如实验室或扫描结果）的大小可能是很大的，因此，直接在区块链上传输数据可能很慢，甚至不安全。一些文献建议在链外存储实际数据文件，而仅在链上传递元数据和所需数据库的链接。这样，通过区块链进行的交易将更快、更安全。这还将节省用于参与区块链的设备空间，因为每个节点都将拥有这些区块和资产的副本数据。
答：
当考虑将区块链集成到现代医疗保健基础架构中时，研究人员致力于的第一个重点领域是EMR系统的改进。尽管EMR已经比物理文件和纸质记录系统有了很大的改进，但使用中的系统仍然存在隐私和安全风险。问题3: 还有哪些尚待解决的问题？
区块链的安全性以及不可篡改性解决了这些问题，因为只有授权方才能查看和修改患者记录。此前，区块链还可以添加访问控制以分离读写权限。而共识算法和智能合约的存在，使患者可以控制哪些人可以查看其数据。
关于在医疗保健中实施区块链的另一个重点，就是对欺诈企图的检测。区块链被视为真正的账本，这意味着链上存在的数据可以被信任，这可以有效打击欺诈问题。而区块链的不可篡改性使组织能够跟踪任何类型的信息。例如，医疗机构可以跟踪其发放的学位以及医科学生的成就。这可以帮助验证学生声称拥有的文凭是合法的。另外，我们还可以将相同的想法应用于保险采购以及药品供应链，这样就可以记录服务和产品的价格、法律要求、以前的做法，甚至可以跟踪供应信息。
物联网与区块链的集成，则是另一个重点研究领域。由于存在诸如心率或血液含量监测器之类的医疗可穿戴设备，看护人员可以对患者进行评估，而无需经常去医院就诊，而区块链可通过确保患者佩戴的身体传感器收集的数据的通信安全来改善该系统。它还限制了哪些人可以访问收集的数据，并确保不会因数据分发到链上的其他节点而丢失任何数据。而智能合约的附加集成，可根据可穿戴设备收集的实时数据向看护人员警告某些事件。
在考虑利用区块链改善医疗保健系统时，研究人员通常将重点放在隐私和安全性上。患者记录包含非常敏感的个人信息，而恶意方可以利用这些信息。即使使用传统系统，患者也担心其数据发送给哪一方以及谁有能力查看其记录。这可能会阻止他们进行某些治疗，尤其是在向患者提供有关患者数据的同意书以供他们签名时。
当务之急是改善患者的隐私和其数据的安全性，以便让患者对医疗保健系统更有信心。
答：
与任何实施方式一样，在将区块链集成到现代医疗基础架构中时，仍然需要解决一些问题。首先要考虑的就是系统的可扩展性。尽管我们可以控制要存储在链中的数据，但随着时间的流逝，参与区块链的患者和参与方的数量将持续增长。在某些时候，诸如处理能力和存储介质之类的计算资源将变得有限。这可能会阻碍区块链提供的服务。而由于网络的持续增长，系统的可扩展性及基础资源的数量可能会成为一个问题。问题4: 可以将区块链与人工智能相结合，以进一步优化个性化医疗吗？
这就引发了有关实施这种系统的成本问题。尽管由于自动调节的原因，从长远来看，区块链可以节省金钱和资源，但在初期阶段的成本可能会是很高的。例如共识算法的工作方式（尤其是PoW）可能需要大量的处理资源。由于医疗保健中的区块链网络预计会很大，因此实现所需的硬件，以及拥有适当的设备以无缝利用区块链平台可能会变得昂贵。
可能出现的另一个问题是“垃圾进，垃圾出”（GIGO）的概念。这是指与用户输入有关的场景，其中用户可能输入不正确或随机的数据。系统将被迫处理此数据，这可能导致错误的输出。将区块链包含在医疗保健中可能会面临同样的问题。既患者在参与自己的医疗保健时，就有可能输入“垃圾”信息，而看护人或任何其他专业人员也可能发生相同的情况。由于计算机不熟练或对系统的误解，这可能是偶然的，或者在用户输入数据具有恶意意图的情况下，则是故意的。尽管区块链拥有共识算法，但如果区块链用户不注意他们输入到系统中的数据，则“垃圾进，垃圾出”（GIGO）仍然是可能的。而如果由不熟悉区块链及其配置的IT专业人员实施区块链网络，也会出现问题。这可能会导致错误的诊断或错误的处方，从而可能进一步导致健康并发症，甚至在更严重的情况下甚至导致患者死亡。
而在任何系统或服务中，试图利用漏洞窃取数据或造成损害的恶意用户将始终存在。即使区块链可以抵御攻击，节点安全仍然会是一个问题。如果最终用户受到威胁，则攻击者可能会破坏区块链。他们可以根据发生的通信推断有关链上其他用户的信息，窃取有关受害受害者的数据，并提供虚假信息以在链上输入。
而要使区块链成功改善医疗保健系统，以上这些问题都是有待解决的。
答：
数据科学是另一个一直在寻求通过使用人工智能（AI）及其机器学习算法来改善医疗行业的领域。与区块链类似，这些决策是使用特殊算法做出的。不同之处在于，当区块链使用收集到的数据试图保护数据完整性时，人工智能寻求做出预测和明智的决策。在医疗保健领域要做出决定的一些例子是医疗诊断，比如患者可能需要哪种药物或所需的程序。
如本文前面所述，区块链已与云计算和IoT集成在一起以改善现有服务和系统。将区块链与AI结合，可以进一步改善医疗保健基础设施的几个重要部分，例如：
区块链系统已解决了提高数据完整性和防止传统攻击的问题。然而，在不影响系统性能和某些数据安全的前提下，是无法通过区块链直接传输大量数据的。
- 确保数据完整性和有效性；
- 预防和缓解恶意活动；
- 预测分析；
- 实时数据分析；
- 管理数据共享；
但是，将AI算法集成到系统中将允许提前处理数据，从而仅将结果和信息通过区块链传递。因为区块链审核了所有交易，所以医疗专业人员仍然能够理解数据是如何处理的，以及为什么做出了明智的决定。
人工智能做出明智决策的能力，也可能有助于区块的挖掘，减少所需的计算资源量。与使用传统方法相比，使用机器学习算法挖掘区块可以节省时间和资源。例如，如果健康提供者获得适当的权限来访问可信和高度可靠的患者数据，那么，通过使用人工智能，将有可能基于分子图谱、化学反应、基因变异、遗传疾病或任何其他图谱对患者进行分组，这对推进个性化医疗具有极大的帮助。
1、6 结论
为了使患者对医疗专业人员及其诊所更有信心，我们需要解决当前医疗保健系统中存在的安全性和隐私问题。而EMR管理是需要重点关注的一个领域，数字化医疗记录简化了它们的存储和共享。但是，这仍然存在以下问题：未经授权的访问和披露，可以被视为单一攻击点的集中式系统，以及在拜访多名医疗专业人员的情况下存在的，患者医疗信息的碎片化问题。
为了解决这些问题，研究人员正在转向区块链，随着时间的流逝，原始的区块链基础设施已经有了一些发展，因此它不仅可被用于加密货币和金融交易，研究人员已在研究可用于改善当前医疗系统的区块链方法。由于区块链具有不可篡改、透明、去中心化的性质，因此可以将其用作数字账本，以简化患者、护理人员和保险公司之间的通信。
尽管如此，现有的医疗区块链解决方案，也面临着一些需要解决的问题，例如可扩展性问题以及节点安全性问题（尽管区块链是安全的，但受到破坏的单个节点也可能会影响整个链）。由于存在节点受损的风险，还需要解决密钥生成和替换的问题，以便用户可以尽快恢复使用区块链。
总体而言，将区块链集成到医疗基础设施中显示出了巨大的潜力。在这一领域的持续研究，将有利于医疗保健提供者、患者和其他相关方（如研究机构和保险公司）。一旦区块链的剩余问题被克服，医疗系统就可以有效得到发展，从而有利于每个人。
二、硬核技术文章一月精选
2、1 关于错误性证明（Fault Proof）的沉思（一）
编者注：一般而言，我们会将 Fault Proof 认为是与 Layer-2 相关的概念，是 Layer-2 将自己的状态报告给 Layer-1 时采取的模式。但在本文中，作者使用的是广义的错误性证明概念，考虑的是如何设计一种错误性证明模式，使 SPV 节点（近似于所谓的 “轻节点”）获得更高的安全性。
错误性证明（Fraud Proof）是个极为复杂且烦人的概念，但如果你想知道我的一些心得，请耐着性子跟我一起思考吧。
-Benihime Morgan 的河流艺术作品-
简而言之，言而简之
- SPV 节点非常易于运行及扩展；借助错误性证明，SPV 节点（Simplified Payment Verification）可以具备和全节点相同的安全性。
- 我要在此引入 “ SPV+ ” 模式；常规的 SPV 节点只需要保存区块头（存储增量每年约 4MB ），而 SPV+ 节点还需要保存每个区块中的第一笔及最后一笔交易（存储增量每年约 115 MB）。
- “SPV+” 节点必须与一个全节点建立支付通道，或是建立一个 LN 连接。
- 每验证一个区块的正确性，SPV+ 节点都必须向这些全节点支付小额费用；我估计这笔费用不会超过 50 刀/月。
- 后续就是添几个新操作码的事：我们需要一个链下的 rangeproof ，搭配类似 “ SegWit” 的 witness-commitment （见证-承诺）技术，就能方便且低成本地使用 SPV+ 节点了。
1. 背景
A. 如何让比特币更像实体黄金
比特币在设计上对标的是黄金；虽然在很多方面，比特币已远胜于黄金，但是一谈到收款，问题就来了——你怎么知道钱到账了？如果以黄金等实物手段支付，有没有到帐是很简单的——就跟所有一手交钱一手交货的情形一样；但如果使用比特币（数字货币）支付，保障资产所有权就会变成一件很抽象的事。
对于这个问题，中本聪（Satoshi）提出了一个完美的软件解决方案，让你能够知道钱到账没有——它就是 “比特币” 软件。
等会！这不又兜回原点了吗？究竟这个软件是如何运作的
谜底揭晓，比特币软件使用一种特殊的机制与其它运行软件的计算机进行同步；这个机制有点类似 Dropbox ，但不同之处在于，由每个文件自身保证同步性，因此不会有版本控制的问题。换言之，“得知钱已到账” 和 “得知你已实现同步”是一码事。
中本聪在白皮书中提出了两种 “确认钱已到账” 的方法：
- 【正向做法（传统）】运行软件，等待实现完全同步。
- 【反向做法（实验性）】首先，运行一个 “轻客户端”——只会策略性地对某些简单部分进行同步；然后注意是否出现 “alert（警告）”。
B. “alert” 的理论支撑
我个人觉得最有意思的，反向证明机制（即， “alert”）与实际生活中的很多行为方式类似。
试想以下例子：
- 我们不会试图 100% 杜绝凶案发生，而是在凶案发生后尽全力抓捕犯人（通过庭审定罪，给予犯人应得的惩罚）。
- 我们不会试图 100% 杜绝奸商存在，但如果真的出现奸商，我们会期待他被市场淘汰，然后由良商取而代之；如果有太多利益纠葛，我们会通过侵权法或规章制度淘汰我们不想要的商人。
- 我们不会试图保证每一项发布的科研成果是 100% 零错误的，而是最大程度地公开它们，并期待能收到批评或指正。
- 我们不会试图 100％ 防止司法腐败。但是我们确实要求所有法律诉讼环节都必须记录下来，保证庭审的公正性可由公众及法律学者在事后追查。
- 我们不会试图变得 “全知全能”。但是我们希望能够在书籍、网站中找到所需的知识技能，并希望未来会有专家让这些信息变得更准确。
C. “alert” 面临的理论挑战
“alert” 的问题在于， Satoshi（中本聪）实际上并未实现这个想法。上个月，Eric Lombrozo 也在推文中也提到这一点。
- Eric Lombrozo：“许多我聊过的顶尖技术专家都说，错误性证明实在是太难实现了，而且在最糟糕的情况下甚至是不可能的。中本聪似乎认识到了其中的难度，因此从未提出过解决方案。”-
若要实现错误性证明，主要有以下两个难点：
- 抗 DoS 攻击：比特币全节点之所以对 DoS 攻击有很强的抵御能力，是因为工作量证明机制（Proof of Work）所具备的不对称性——每隔 10 分钟才能产出一个新区块，验证这个区块却只要很短的时间。不过这是否适用于“alert”？“alert” 实行 PoW 机制吗？谁来为服务买单？如果没有人买单，如何阻止恶意节点滥发假的 “alert” 来掩盖真的 “alert” ？
- 反向证明：恶意的/粗心的 矿工可能会丢弃区块内的一部分数据，更极端地说，矿工可能会在根本不知晓区块里有什么的情况下，创建出一个区块！如果区块里包含错误交易，我们怎么发现呢？如果没人发现得了，又如何提醒他人呢？
针对第二个问题，我们可以将（非常宝贵的）“审核资源” 放在验证区块的特定部分——简单来说，我们可以让节点声明自己确实知道整个区块（所有部分）所包含的内容，然后让验证者验证该声明并为其背书。
2. 问题
A. SPV 模式
中本聪的 SPV 模式（白皮书第 8 章处）：- 比特币的区块头非常小（每年 4MB 的增量），且易于验证，不受区块所含交易数量的影响。
- 可以很容易地证明，区块中包含了某个东西（某笔交易） “ X ” —— 只要有 “X” 本身、区块头，以及包含两者的有效 Merkle Branch （默克尔分支）即可。
假设我们有三个区块头：headerA、headerB、headerC；每个区块头都分别包含一个 hashMerkleRoot （默克尔根哈希）：hA、hB、hC。
交易 Tx 是否存在于这些区块（ [header A] , [header B] ）的任意一个之中？
是的，因为 h( [tx] ) = ht ，且
h( ht, hs1 ) = hi1
h( hi1, hs2 ) = hi2
h( hi2, hs3 ) = hA
其中：
ht 是交易 Tx 的哈希值；
hs1、hs2、hs3 是由全节点（“Fred”）提供的哈希值。
hi1、 hi2 是 SPV 节点（“Sally”）计算得出的中间哈希值。
上述证明的实际含义是，有一棵以 hA 为根哈希值的默克尔树，它有两个分支 hi2 和 hs3，哈希值为证，别无其它可能；hi2 也只有 hi1 和 hs2 两个分支……层层递推，最终可证，ht 必定存在于这棵默克尔树中，
Merkle Branch（包含了由全节点提供的哈希值，以及这些哈希值在默克尔分支上的数顺序和位置信息）非常小，仅以 log(n) 的速率增长。付款者可以轻松 获得/生成 Merkle Branch，并伴随着交易一起发送给收款者；这种成本是可以忽略不计的。
也就是说，只要有比特币区块头，你就能知道 “钱是否已经到账了”。区块头又很容易获得，因此 SPV 模式似乎很容易就能实现无限吞吐量。
B. SPV 模式的问题
问题在于，我们永远无法确定一个 80 字节的区块头是否真的是 “比特币区块头”。
唯一的方法是检查对应区块的全部信息。如果存在一笔无效交易或双花交易（或者说，该区块存在某种 “缺陷”，详见下文的 “区块错误（Block Flaws）”），整个区块就会被视为无效区块。
C. 好消息
虽然我们无法验证一个 80 字节的区块头是否是比特币区块头，但是好在我们能对照当前出块难度，通过计算区块头的哈希值来验证区块头的工作量证明。（区块头设计得非常友好，本身就包含一组重要信息——出块难度和时间戳信息；二者可以相互验证。）
如此一来，我们就能检验矿工是否真的进行了哈希运算；可惜的是，我们还是无法确定这个区块头是否有价值（译者注：即该区块头所对应的区块是否不包含无效交易）。这就好比你托矿工 Matthew 帮你买一盒巧克力，你很容易就能验证 “Matthew 是否真的花了 300 多刀买了一盒巧克力”，但是你无法确定这些巧克力是否好吃，也无法确定它们是否真的含有巧克力成分。
D. 正向/反向证明回顾
你可以吃掉盒子中的每一颗巧克力，证实每一块巧克力都很好吃，这就是 “正向证明”。
或者你可以顺着以下思路进行反向证明：这盒巧克力是被包装好了的，看起来没有被动过手脚；再加上这盒巧克力有品牌背书，我国又严格执行 品牌法/商标法；已经有很多人买过这个牌子的巧克力，如果质量有问题，我只要随手搜一下就能看到相关新闻/差评（实际上我查了之后，并没有发现任何负面消息）。
另一个采用反向证明的例子是退款承诺。假设你要买辆车（一件不确定质量好坏的商品，就像是新创建出但还未被验证的比特币区块），现在有三款车子（分别为“Car A”、“Car B”、“Car C”），目前你对 Car C 最感兴趣。
若想获得正向证明，你就要把 Car C 开上个数千英里，随行配有一支庞大的机械工程师团队一路检查这辆汽车每个零部件，并汇报问题给你。
如果是反向证明的话：假设 Car A 和 Car B 都提供一个具有法律效力的声明 “里程数不到 40000 英里的车子发生故障，即可退款”；但是 Car C 没有这种承诺，那就反向证明了 Car C 的质量不行。
要实现比特币上的错误性证明，我们需要一样东西——在区块合法的情况下出现；在区块不合法的情况下绝不出现（或者反过来也行）。
在博弈论中，这被称为 “信号博弈（signaling game）”（或更确切地说是 “筛选博弈（screening game）”）中的 “分离均衡（separating equilibrium）”。其中，错误性证明的发送者分为 “诚实” 和 “不诚实” 两类，我们正试图通过低成本的手段淘选掉不诚实的那一类。
E. 我们的需求
我们需要找到一种方法能提醒我们注意 “区块错误”。理想情况下，这种警示要来的又快又准确（即，在“交易结算之前”，或者 “ 6 个区块确认之前“ ，或者（出于安全考量）要在“ 20~30 分钟内”做出响应）。
举个具体的例子，理想情形应该如下：
- “Sally”（SPV 节点）因为某些原因收到了一笔比特币，对方向她展示这笔交易的信息，Sally 也看到这笔交易是合法的。
- Sally 想要在不运行全节点的情况下知道这笔交易是否经过 6 个区块的确认。因此，她先是下载了所有比特币区块头，接着向全节点要了 Merkle Branch （包含【1】她的交易【2】最新区块头）。她得到了一个 Merkle Branch ，然而不幸的是（她根本不知道)：里面的区块头因为某些原因是无效的……
- 就在此时，“Fred“ （全节点）必须意识到出现问题了——有一个区块存在一到多个 “缺陷”（详见下文）。
- 必须通过某种激励措施促使 Fred 向 Sally 发起某种警告（即，“alert”）。
- 在其他正常情况下，不能让 Fred 有动力发起警告（即，在没问题的时候不会出现 “假警告”）。
F. 区块错误的类别
区块可能会出现很多种缺陷（详见 validation.ccp, 特别是 “CheckBlock”）。我将它们分为四类：- “第一类”——不良交易（无效交易、双花交易，或是重复的交易）。
- “第二类”——区块数据缺失（记录 Sally 交易的默克尔树（Merkle Tree）上，与 Sally 交易所在位置相邻的节点数据处于未知或不可见状态 —— 这可能是人为或无意导致的）。
- “第三类”——不良区块（coinbase 错置、版本错误、“见证” 数据丢失、 [drivechain] 大量更新了 Escrow_DB/Withdrawal_DB）。（译者注：drivechain 是作者自己提出的一种侧链架构，可见 Peer-to-Peer Bitcoin Sidechains ）
- “第四类”——不当累加（超过区块大小/ SigOps 限制、coinbase 交易费【必须等于区块内所有交易费之和】、 [drivechain] 侧链的输出—— Escrow DB 的 “CTIP” 字段）。
第一级错误非常好对付。Sally 可以直接通过验证交易并 reversing the outcome (so that "false" validation returens "true") 来检验该交易的有效性，详见下文。在 SPV 模式下，甚至能检验 nLockTime 和 CSV ，因为 Sally 掌握了 Merkle Branch 和所有区块头。只要观察到两笔交易有相同输入，就能轻松检查出双花交易。重复的交易必然无法通过测试，因为它们必然属于双花交易（除非是 coinbase 交易，详见第三类错误）。
第二类缺陷
第二类缺陷与 SPV 用户的相关性最强—— SPV 用户必须假设（除了区块头之外）区块的剩余部分是完整的，但是（根据定义）无法检查是否真是如此。更糟糕的是，矿工可以在不核实区块内容的情况下，创建一个新的区块，他们也确实会这么做。因此，新创建出的区块内可能存在无人知晓的内容，上述假设明显是不合理的。
我将证明，从理论上来说（虽然未经实践证实），只要能向 Sally 提供有效的 “区块头 + Merkle Branch”，就应该存在一个完整的 Merkle Tree（包含 Sally 的交易以及已知一定数量的有效的比特币交易）。因此，所有与区块链数据缺失有关的缺陷（即，第二类缺陷），本质上就是 “Merkle Tree 相关数据缺失” 的问题。可以说，这种缺陷就是未知哈希值原像的问题（易于处理），又或者说的具体点，可以通过对未知哈希原像进行采样来解决这个问题（译者注：一个哈希值的 “原像” 是指被输入某种哈希函数后产生出这个哈希值的原始数据）。
我提出的解决方案是要求 Sally 除了区块头，还需要下载每一个区块的最后一条交易（加上 Merkle Branch） 2。
第三类缺陷
Class III 第三类缺陷
第三类缺陷非常普遍，但我相信这种小毛病可以通过一种特定的简单方法解决。举例来说，区块版本如果出错，SPV 节点可以直接从自己维护的区块头中获得正确的区块版本。
其他大多数的信息缺失，可以从 coinbase 交易中找到；因此除了所有的区块头，SVP 节点还需要保存每个区块的 coinbase 交易（译者注：coinbase 即区块中特殊的增发货币的交易）。有了这些信息，SPV 节点就能知道：【1】coinbase 交易是否只出现一次且出现在正确的位置；【2】“见证数据（witness）” 是否存在及见证的内容；【3】确定所有 Withdrawal_DB 和大多数 Escrow_DB 的正确性。
至于 drivechain 的 Escrow_DB，主链 3上的 SPV 节点必须注意区块中链间交易的累加影响；解决的方法放在第四类缺陷（本文第7章）介绍。
所以我们要增加一些开销 —— 引入 “ SPV + ” 模式（又称为 “ SPV 补丁”）。“ SPV + ” 节点除了要同步比特币区块头（每十分钟增加 80 byte），还要同步每个区块的第一笔和最末尾交易，外加与这两笔交易相关的 Merkle Branch。
- 旧式【中本聪的古典 SPV】：同步区块链中每个区块的区块头（80 byte/区块）；每收到一笔新交易就进行一次汇总（交易 & Merkle Branch）。
- 新式【SPV + 模式】：80 byte/区块 + （coinbase 交易 + 区块中最后一笔交易）/区块 + 两个（不相同的）Merkle Branch /区块；每收到一笔新交易就进行一次汇总（交易 & Merkle Branch）； 与其他几个节点建立支付通道。
按照一年约产出 52596 个区块，因此存储花销会变为约 115 MB/年，不只是 4 MB/年。这看似大幅增加开销，但从全局的角度来看，SPV+ 仍然是非常节省的方案。如果 Sally 想要完整的检查交易有效性，她只需要对每个区块多下载这些数据：（可以是）最近六个月产出的区块，或是那些记录她收到比特币的区块（以及这些区块的前后 ~10 个区块），以及（或是）一些随机的检查信息。
第四类缺陷
第四类缺陷非常有意思。本文第 7 章会介绍如何将第四类缺陷转换成第一类缺陷，不过简单讲，要解决第四类缺陷，我要求交易哈希值不仅仅作为交易自身的保证，还要说明自己对累加指标造成的影响。举例来说，交易不仅要保证自己是 “277 bytes”，还要说明 “加上自己之后，宿主区块大小从 500809 bytes 增加为 501086 bytes”。这样一来，所有的 “假交易” 就能被孤立且识别出来了。也就是说，最末尾交易会提供很重要的信息（交易总数、区块大小、总体交易手续费，等等）。
在我深入更多技术细节之前，为了避免有人因为听不懂而掉队，我将以故事的形式再次说明 “整个逻辑”。
(未完）
注 1：“全节点” 与 “SPV 节点” 的区别也许并不像人们认为的那么清楚。简言之，当一个全节点在下载一个新区块时，相对于再下一个块，它自身是处于 SPV 模式中的。另外，再假设 51% 的算力在秘密运行一个新软件（或者说，是在运行一个新的但兼容的协议），该新软件默认增设区块延展数据（extension）。那么，即便别的节点想成为 “全节点”，也不得不变成部分全节点、部分 SPV 节点的混合模式。如果那些矿工后面又把协议改回去了，去除掉了延展数据要求，那么我们就又成为了 100% 的全节点。但是，在这个过程中可能你都没有意识到节点形态转变了，实际上你也没办法知道。所以，只有假设协议本身固定不变的情况下，使用这些数据才有意义，当然，本文也就是这么假设的。不过，实际上，协议可能变更，也确实会变更，矿工永远可以选择运行定制化的软件。
注 2：准确点说，是对所有她想用 SPV 模式来 “完全验证” 的区块都要这么做（不想验证的就另算了）。
注 3：对于自身是侧链的那些区块链，链间交易出错可以被归类为第一类错误。要得到错误警示，侧链的 SPV 节点需要找出两笔交易，一笔在主链上提供存款的交易，另一笔是在侧链上记录存入金额的交易。因此，侧链上的 Sally 必须检查主链和侧链两条链才能发现错误。
注 4：单块的全部存储成本是：“区块头 + 第一笔交易 + 第二笔交易 + 2 × (32 × log2(n))”，这里的 “log2(n) ” 指的是 “根据区块中交易的数量可得的空间占用上限”。因此，在本例中，单块的存储成本是 “80 + 1000 + 280 + 2 × (32 × log2(5000))”，大概是 2192 bytes。注意，我们不需要 coinbase 交易的位掩码，因为我们已经知道其确切结构，但我们可能需要知道最后一笔交易的。（这个数据应该会比把 self 编码为一个完全由 0 来组成的 branch-hash 要小，我已经在这里估计过了。）
原文链接: http://www.truthcoin.info/blog/fraud-proofs/ 作者: Paul Sztorc 翻译&校对: IAN LIU & 阿剑
来源链接：https://www.8btc.com/article/547929
2、2 私钥丢失也能找回？五分钟了解V神的秘密多重签名恢复方案
丢失钱包密码或私钥是加密货币用户经常会遇到的问题，那能否有方法可在最小化信任的同时，恢复丢失的密钥呢？这正是以太坊联合创始人vitalik等人正在探索的一个方向，而他们已编写了一个新的EIP（以太坊改进提案），并将其命名为秘密多重签名恢复（Secret Multisig Recovery）方案。昨日，知名黄金爱好者兼加密货币怀疑者Peter Schiff 在Twitter上声称自己的钱包丢失了密码，因此无法访问自己的比特币。
Schiff接着补充说：
“所以现在我的比特币在本质上毫无价值，它也没有市场价值。我知道拥有比特币是个坏主意，但我从来没有意识到它是如此糟糕！”
Schiff在推特上公布自己的损失后，加密货币社区很快展开了讨论，例如Morgan Creek Digital 联合创始人兼合伙人Anthony Pompliano就提问他是否自己忘记了密码，而Schiff对此的回答却是：“是我的钱包忘记了密码。”
看不下去的Pompliano只好耐心解释道：
“软件只是执行人类发出的命令，它不能‘忘记’任何事情，给我发邮件吧，我会尽力帮你找回丢失的比特币。”不过根据Schiff的回答，他的比特币基本已无望找回了，他提到说：
“是Eric Voorhees（注：ShapeShift首席执行官）帮我准备的钱包，即便是他也觉得我无能为力。如果你有任何想法，欢迎尝试。”看到这里，读者可能觉得这是一个非常悲伤的故事，一位加密货币怀疑者好不容易尝试了比特币，结果却因为自己忘记了密码而丢失了它们。而倘若他在多处备份好私钥，那么即使他忘记了钱包密码，也可以通过私钥访问自己的钱包。
当然，也有人会认为这是一个深刻的教训，它提醒我们要开发相关的技术，为类似的人群提供安全保障。
比如以太坊联合创始人vitalik就评论称：
“对于人们用‘加密货币就是加密货币，你的工作就是要非常小心地在三个地方写下备份种子’来回答这个问题，我感到失望。我们可以，也应该创造更好的钱包技术，使得安全变得更容易实现。那V神所说的社交恢复提案具体是指什么呢？
例如，这里有一个社交恢复提案：https://t.co/tuSbHhXKgd?amp=1 ”
下面我们就来简单了解一下吧。
EIP 2429：秘密多重签名恢复
作者：Ricardo Guilherme Schmidt（ricardo3@status.im）、Miguel Mota（@Miguel Mota）、Vitalik Buterin（@vbuterin）、naxe（@ngmachado）
状态：草案
类别：ERC
创建日期：2019-12-07
要求：EIP （137, 191, 831, 1271, 1344, 2470）
摘要
一般来说，加密货币的一个糟糕体验是私钥丢失或暴露，这可能导致不可逆转的情况。
社交恢复被视为账户合约去中心化恢复的一种选择，然而社交恢复的使用，带来了人的因素，而人的因素通常是安全系统脆弱性的主要原因。
社交恢复的主要风险是：
- 合谋：如果一些用户知道他们是某个恢复的一部分，他们可能会对恢复攻击的执行感兴趣；
- 目标攻击：外部代理可能了解恢复的所有者，并瞄准执行恢复攻击所需最薄弱的点；
- 一般暴露：攻击者如果设法感染大型用户基础环境依赖项，并获得对多个身份的访问权限，也可能通过恢复对未受影响的用户产生副作用；
- 模拟攻击：针对性攻击可以了解用户的情况，并将该用户模拟到其社交对等方以执行恢复攻击。这变得更加令人关注，因为AI研究能够“深度伪造”其他人的声音和面部动作。
据悉，该标准提出了一种定义存储在Melkle树中的地址列表方法，这些地址连同它们的权重和用户的个人秘密，将组成一个秘密集，而该秘密集可以在不直接危及用户的情况下公开，因为它仍然需要对地址列表中的总阈值进行人工验证。
该秘密集可以保存，例如存储在web2云存储当中，而不会严重影响安全性，这对于一些不信任自己，但也不希望信任某些特定实体的用户而言是非常有用的。
用户秘密永远不会在链中显示，显示的只是一个nonce哈希，每次恢复时它都会增加。恢复设置获取此哈希秘密nonce的哈希值的哈希值（hash of a hash），这种双哈希方法被用于数学证明请求恢复的人知道该秘密，而不会泄露它。
根据提案，用户可通过提供秘密（user_secret_data）以及加权地址列表（address_list）来配置恢复。
user_secret_data可以是用户可猜测的半私有信息。而user_secret_type是可选的随机大整数，并将其与address_list一起导出为private_hash 。
地址列表的总权重必须大于阈值，而阈值是一个常数：THRESHOLD = 100 * 10^18。
而标准定义了生成可预测用户秘密的几种方法。
当生物识别（biometrics，例如指纹、面部和瞳孔）技术可用时，应该使用它们，这是最简单的方法。
而当没有生物识别技术时，一组通常只有用户知道的诸多问题的标准表单，可被用于生成用户的秘密数据。所有可选的默认字段有：Full Name（全名）、Birth Date（生日）、Mother Name（母亲名字）、Mother Birthdate（母亲生日）、Nationality（国籍）、First Love's Name（初恋者姓名）、First Pet's Name（第一只宠物名）、Childhood Nickname（童年昵称）。
而密码派生方法，则类似于详细表单方法，但它只要求用户输入一些内容：Full Name（全名）和Password（密码）。
地址列表
用户将定义监护人账户列表，该列表通过用户的联系人列表进行填充。导入选项和输入一个地址应该是很方便的，如图所示：
选择好监护人后，系统将提示用户定义每个监护人的权重：
这些地址存储在一个标准的merkle树当中，但是每个子叶必须与hash_to_peer进行哈希运算。
merkle_root被哈希为一个标准merkle树，它由keccak256(bytes32(hash_to_peer), uint256(weight), boolean(is_ens), bytes32(ethereum_address))格式的address_list 子叶组成。
方案支持了ENS域名，当监护人拥有一个ENS域名时，应该使用ENS域名。根据EIP-137，如果使用了ENS域名，则is_ens必须为“true”。
列表中的地址可以是账户合约，如果是账户合约，则可以直接调用审批功能，也可以提供EIP-1271签名。而如果是外部拥有帐户，则应用ecrecover逻辑，但它们也可以直接调用approve函数。
weight设置此地址值相对于THRESHOLD常量的批准程度。
用户秘密数据哈希
- 对于多个用户而言，recovery_contract可能是相同的，这是用户正在使用的共享秘密多重签名合约地址；
- user_secret_data是用户数据的纯格式字节数据，它从不暴露，也不会被保存。当private_hash是未知时，应向用户进行请求；
- private_hash是keccak256(user_secret_data)，它从不暴露，可以用秘密集导出。这可以在所有恢复中重复使用；
- merkle_root是通过对普通merkle树进行哈希运算得到的，它在执行时会被揭露；
- weight_multipler定义要达到THRESHOLD需要乘以多少个单独权重；
- hash_to_execute是keccak256(private_hash, address(recovery_contract), recovery_contract.nonce(user_address))，它仅在执行时公开，每次恢复都是唯一的，也被称为“显示哈希”。Nonce和恢复合约地址被用于允许重用private_hash；
- hash_to_peer是keccak256（hash_to_execute），它在恢复授权请求时会公开，其被用于通过揭露public_hash种子来证明用户知道hash_to_execute和merkle_root，这也被称为“部分泄漏哈希”；
- public_hash是keccak256（hash_to_peer，merkle_root，weight_multiplier），它自配置后就是公开的，只能使用一次，这也用于防止执行的重放。执行成功后，必须使用setup(bytes32,uint256)进行重配置；
恢复秘密集URL
恢复所需的所有信息都将存储在url类型标准中：
recovery = erc831_part account_contract [ "@" chain_id ] "/" recovery_contract "/" private_hash | secret_type "/" address_list / weight_multipler [ "?" parameters ] [ "#" notes ] erc831_part = "ethereum:recovery-" account_contract = ADDRESS chain_id = 1*DIGIT recovery_contract = ADDRESS private_hash = "0x" 64*HEXDIG secret_type = UINT address_list = ethereum_address *( ";" ethereum_address ) weight_multipler = UINT ethereum_address = ADDRESS / ENS_NAME "*" weight weight = UINT ADDRESS = "0x" 40*HEXDIG parameters = parameter *( "&" parameter ) parameter = key "=" value key = STRING value = STRING notes = STRING
- account_contract是指要进行恢复的账户合约，可以使用任何账户合约，因为恢复合约可以执行到任何接口或地址（如常规多重签名）；
- chain_id为所有地址定义了以太坊链，如果不存在，则预设为1（主网）；
- recovery_contract 执行恢复合约的逻辑，必须支持此文档中指定的ABI；
- secret_type选择生成user_secret_data时使用的标准，在未给定private_hash时是必需的；
- private_hash是user_secret_data的哈希，如果不存在，恢复将要求使用secret_type所选的标准来获取user_secret_data；
- weight_multipler 是每个weight将乘以的值，以达到THRESHOLD常数；
- address_list是具有个人权重的地址列表，最好是另一个帐户合约，表明它们可用于恢复请求，但任何地址都可以帮助恢复。可以使用ENS域名，并在恢复过程中进行解析。总权重应高于THRESHOLD常数；
- weight默认为Math.ceil(THRESHOLD / address_list.length)，由用户设置自定义；
- parameters可能需要特定的secret_type；
- 如果需要的话，notes可用于密码提示；
恢复程序
当需要恢复时，用户需要将其Recovery Secret Set URL（恢复密钥集URL）加载到支持此标准的电子钱包中。根据配置的不同，当private_hash（私有哈希）不可用时，必须从对用户构成挑战的user_secret_data处生成。
加载有效的密钥集时，它将提示哪些用户请求帮助。一些钱包或许能自动发送请求，而另一些钱包则允许用户共享这个Help Recover Request URL（帮助恢复请求URL）。
该EIP鼓励尽可能使用预签名的消息EIP-191，这一点很重要，因为gas成本是一个常见的障碍。如果监护人选择的地址是帐户合约，则必须是EIP-1271才能使用预签名信息。建议的正常顺序如下：
在特殊情况下，如果账户合约无法签署信息，或者用户的钱包无法按照这个EIP上指定的格式签署信息，则也可以通过使用msg.sender的方法执行常规操作。
在这种情况下，监护人将不得不支付一小部分gas费用。
理论基础
user_secret_data从不公开，在用keccak256算法进行哈希运算一次后，它就成为从不公开的private_hash。理论上，应该使用生物特征技术，因为用户不太可能丢失他们的生物特征。而生物特征通常是不安全的，因为它们并不是真正的秘密，任何高分辨率相机实际上都可以读取大多数生物特征，而且这些信息通常也为政府所知。
当生物特征不可用时，用户数据表单仍然提供相当好的安全性，因为合约中存储的哈希是离源数据非常远的加盐（salted ）哈希，即使只有名字被用作user_secret_data，也是很难发现的。这些数据越不可预测，就越能抵御目标攻击，而目标攻击仍需要发现用户列表并接收足够的授权。
在成功执行之后，需要重新配置以实现安全性保障。在经历一次恢复后，恢复合约必须禁用自身，并等待新的配置。
可能存在的攻击
需要注意的是，支持此EIP的钱包，应考虑用户可能被请求帮助恢复其他账户，而请求可能来自任何知道secret_set的人，包括合法拥有者或以某种方式获取secret_set的攻击者。
因此：
- 钱包必须询问用户请求的合法性，询问请求是否是通过个人验证后进行的；
- 用户必须知道，他们对自己的链上操作负有责任（在某些国家是道德的、合法的），并且必须验证恢复请求的合法性；
- 视频通话可能是通过AI伪造的，但攻击者需要图像和语音样本，例如互联网上的公共演讲内容；
- 为名人进行恢复的用户，永远不要信任视频通话，应该去尝试直接联系周围的人，以检查请求的合法性；
来源链接：https://www.8btc.com/article/548303
2、3 Mimblewimble可实现非交互式交易，莱特币、Grin等将受益
一项技术如果是难用的，或者说对用户不友好的，那么它就很难被广泛采用。而此前的Mimblewimble协议，其交易就要求发送方和接收方同时在线交互才能实现，从而阻碍了相关项目的大规模应用。而在今日，Grin++钱包开发者David Burkett提出了一种支持Mimblewimble非交互式交易的提案，其可适用于莱特币、Grin等区块链项目。
David Burkett在莱特币论坛开发者板块中提到：
一月份最大的消息是，我找到了一种方法来支持Mimblewimble的非交互式交易！使用MW协议最大的困难，是需要发送方和接收方进行通信，这需要双方在线。而新的提议，可消除这种需要，由此可清除掉主要的用户体验障碍，同时支持通过冷存储进行接收，从而使硬件钱包更易于支持。
在开发方面，已经为libmw确定了构建过程，并且本地构建正在为libmw-ltc工作（将libmw-core和libmw-ltc检出到同一父目录，并且你应该能够构建libmw-ltc）。我将在下个月左右设置CI/CD。
另外，我还构建了一个具有交易处理功能的健壮数据库框架，以支持跨多个table的原子更新，并实现了与币无关的区块数据库查询和更新，并且已使用特定于LTC的区块头和区块模型进行了部分测试。
安全审计结果是从Grin++得出的，因此我已将所有修复程序应用于Grin ++和libmw，并将等待审计人员的最终审查。事实证明，C++的实现是非常复杂的，相关的审计给了我教训。作为这个过程的一部分，我学到了很多，因此Grin++& libmw代码库明显变得更好了。再次感谢Grin、Beam和LTC社区的贡献者，他们使审计成为可能。
在Grin++方面，我们已完成了一个成功的计划硬分叉，解决了硬分叉前的同步问题，并且Grin ++ 0.7.5现在已经可用，它是迄今为止最稳定的版本。
而二月份的首要任务，就是实施莱特币扩展区块（EB）的共识规则，包括所有验证和一整套测试。这是代码中最重要的部分，因此要确保所有详细信息正确无误，并且代码具有完整的测试覆盖范围，而这将非常耗时。一旦完成，我将为扩展区块（EB）开发API，这样我们就可以开始将LBMW集成到现有的莱特币代码库中。
我还将集中精力全面审查新的单侧交易提案，如果未发现重大的安全问题，我将创建一个LIP（莱特币改进提议）以供社区反馈。
从这个帖子当中，我们可以看到，目前David Burkett正在为莱特币开发的Mimblewimble应用方案正处于初期阶段，而其中最大的进展就是非交互式交易提案。
那么，这个神奇的方案具体是如何实现的呢？下面我们来看提案译文：
Mimblewimble离线交易提案
Mimblewimble区块链协议通过使用pedersen承诺、schnorr签名和一种称为‘cut-through’的新技术，可提高比特币等加密货币的隐私性和可扩展性。而带来这些好处的同时，也需要付出一些昂贵的代价。到目前为止，构建MW交易需要发送方和接收方之间的交互来创建输出并集体签署交易。本文提出了一种在最小化影响mimblewimble协议可扩展性及隐私性条件下，实现单侧交易的方法。
当前的Mimblewimble协议
和比特币一样，Grin也使用了UTXO模型。交易是通过包含要花费的输入、创建相等或较低价值的新输出，以及签名和构建验证输入所有权的范围证明（range proof）来创建的。
与比特币不同的是，Grin使用了保密交易（CT）技术，因此输入和输出是pedersen承诺（rG + vH）。与添加到输入的签名不同，每笔交易只有一个签名，它是交易内核的一部分。
为了使交易有效，必须满足以下条件（为简单起见，忽略交易费用和交易补偿）：
- 输出承诺的总和减去输入承诺的总和必须等于内核承诺，即(r_out1..n*G +v_out1..n*H) - (r_in1..n*G +v_in1..n*H) = r_kern*G ；
- 对某些已知消息基点G的内核excess value (rk = sum(ro1..n) - sum(ri1..n))的一种签名；
- 一种证明所有输出值都不是负的范围证明（rangeproof）；
而这种协议就要求发送者（Alice）与接收者（Bob）进行交互以构建交易，以避免暴露彼此输入和输出的盲因子。这是一个三步过程：
- Alice用她的输入创建一笔未签名交易，改变输出和范围证明（rangeproof），一个包含输出和输入盲因子差异的中间内核，并提交给schnorr签名的nonce；
- Bob创建他的输出和范围证明（rangeproof），添加他在内核承诺（commitment）中的份额以生成实际的交易内核，提交到nonce，并提供交易内核的部分签名；
- Alice签署她的内核签名，并聚合这两个签名；
建立非交互式交易
长期以来，绝大多数人都认为在mimblewimble协议中不可能实现非交互式交易，因为知情输出盲因子对于创建范围证明（rangeproof）和构建schnorr签名而言是必要的。
而要解决这个问题，我们必须首先找到一种方法，让发送者和接收者都知道盲因子，而不是其他人。而Diffie-Hellman密钥交换算法很适合解决这一问题。发送方只需生成一个密钥对，使用接收方的pubkey（公钥）执行ECDH，并生成一个共享密钥，该密钥可用作盲因子。然后，发送方可以生成接收方的输出、盲因子和签名，以创建有效的交易。
但这种方案，也带来了两个明显的问题。
第一个问题是，发送方仍需要将其公钥和值传递给接收方，因此我们需要在不影响隐私的情况下将其作为输出的一部分包含进来。但是没有明显的方法可提交数据。我们不能将它作为内核的一部分，因为它会将内核链接到输出，从而消除隐私的好处。
第二个问题是Alice和Bob最终都拿到了资金的密钥，这意味着Bob没有成为资金的独家所有人，也不可能解决纠纷。我们需要一种方法来验证只有Bob才能花费输出。
新的提案
事实证明，在范围证明（rangeproof）中可以加密近32字节的数据。例如，如果我们使用一个已知的密钥blake2b(output_commitment)，我们就可以公开提交一些额外的数据。如果我们在范围证明（rangeproof）中“加密”的数据是哈希，那么我们实际上就可以公开提交所需的数据。这允许我们纳入一个新的数据块 (output_data)，其中包含：- 发送人的短暂公钥；
- 接受者公钥；
- 输出值（使用ECDHE(sender's key, receiver's key)加密）；
- 输出的盲因子（使用ECDHE(sender's key, receiver's key)加密）；
- 每个范围证明（rangeproof），通过使用blake2b(output_commitment)都是可重绕（rewindable）的；
- 每个输出都必须包含output_data（其中包括sender_pubkey、receiver_pubkey和一些附加加密数据）；
- ripemd160(blake2b(output_data))必须与重绕的范围证明数据的前20个字节匹配；
- 每个输入都必须包含一个有效的签名：sig(receiver_pubkey, input_commitment)
安全性
因为发送方和接收方都知道输出的盲因子，所以仅仅根据内核验证当前的UTXO集是不够的。这需要验证所有最近输入的签名，我们建议新节点验证最近X区块的所有输入签名，其中X=coinbase成熟值，因为风险是相似的。
而这仍然会留下一个在今天看来不太可能实现的攻击点。这种攻击的工作方式如下（假设过去一天的输入签名经过验证 ）：
- Alice创建一笔包含用于Bob输出的交易；
- Bob将Alice买的东西寄给对方；
- 几天（甚至可能几年）过去了，而Bob仍旧没有花掉他的币；
- Alice强制对过去一天+1个区块进行一次大的重组。然后，她可以将Bob的输出发回给自己，因为她知道盲因子，并且未对超过1天的区块中的交易进行签名验证；
隐私问题
只要密钥对不被重用，上面提到的方案就不会泄露任何额外的隐私。为了确保这一点，我们建议对输出数据进行一个相当小的修改，以支持某种形式的隐秘地址（ISAP或DKSAP）。支付证明
现在，支付可相当容易地进行证明。要证明一笔支付的所有必要条件，是原始输出、范围证明（rangeproof）、output_data以及显示范围证明（rangeproof）MMR成员身份的merkle证明。多重签名钱包
目前，要安全地将资金发送到多重签名钱包，需要发送者和所有接收方进行交互。而新提案消除了这种需要，代价是造成多重签名钱包隐私性方面的损失。其他改进
由于我们现在有一种方法来提交额外的数据，并将其作为输出的一部分，我们可以将费用或者其它数据从内核移到output_data结构当中，这就允许进行修剪，从而减少区块链的大小。致谢
感谢John Tromp对重组攻击的详细描述，感谢Jasper van der Maarel关于防弹证明（ bulletproofs）和多重签名钱包技术方面提供的建议，感谢Phyro提出的将内核细节移动到输出数据结构中的建议。同时，非常感谢Daniel Lehnberg、Antioch Peverell、Phyro以及Vladislav Gelfer对以上设计提供的宝贵反馈意见。
来源链接：https://www.8btc.com/article/551018
2、4 安全多方计算MPC正热，如何通过MPC管理密钥？
来源：链闻，原题《安全多方计算 MPC 正热，如何通过 MPC 管理密钥？》
受访者：谢翔，PlatON 算法科学家
采访 / 撰文：李画
密钥管理是一个正在变得越来越重要的概念，已经成为区块链领域重要的基础设施。当数字货币或 Token 更多的被交易和使用，而不仅仅被一劳永逸地存储时，通过私钥或钱包密码使用资产的方式既不安全，也不友好，更难以满足诸多应用场景的需求。
基于 MPC（安全多方计算）的门限签名方式与多重签名方式是两种不同的密钥管理方法，在这篇文章中，我们采访了 PlatON 算法科学家谢翔博士，他将为我们介绍基于 MPC 的密钥管理，以及这种方式与多重签名方式的本质区别。
谢翔是数学与密码学专业出身，现为 PlatON 算法科学家及 KeyShard 产品负责人，专注于密码算法的研究、实现和产品化。KeyShard 提供的是基于 MPC 的密钥管理服务，为数字货币密钥管理和恢复的痛点提供解决方案。
什么是基于 MPC 的密钥管理
问：为什么我们需要密钥管理？
谢翔：个人可以在区块链或比特币网络上自由地注册账户、转账，不需要任何第三方，这个功能是通过一套数字签名机制来完成的。在数字货币里，最核心的就是如何去管理这个签名，因为所有的东西都会依赖于这个签名。
对于用户而言，管理签名其实就是去管理密钥。因此我们说密钥就是钱，密钥管理很重要。
在传统的行业里，你可以通过银行也好，通过一系列的流程设计也好来管理钱，比如说可以多个人来管，投资经理同意了、投资总监同意了、财务同意了、CEO 同意了，这笔钱才能转出去。但是一旦挪到数字货币这个行业，传统那套是做不了的，为什么？因为谁有私钥谁就能转钱，传统那一套审批流程是形同虚设的，没有任何意义。
所以我们做密钥管理这件事情最初的一个想法，就是说能不能把传统的对于钱的授权管理机制挪到数字货币的世界里面来。这个肯定是需要的，因为现在很多人已经开始用 Token 在投资了，比如说基金，比如说家族的 VC，他们是需要有一种内部管理的机制的，但是传统的那套审批机制在技术上过不来。
问：多签可以解决这个问题吗？
谢翔：多签是基于脚本或智能合约的。它是设计一个规则，比如说三个人同时签了或者两个人同时签了，将这些签名传递给一份智能合约，合约就开始运行，把钱转出去。多签能解决一部分问题，它其实已经用到很多企业里了，但是随着时间的进展会碰到越来越多的问题，问题在哪里呢？
多签针对不同的主链需要实现不同的智能合约，现在的链至少有一千多个了，每个链的智能合约体系不一样，每个人去写合约写得还不一样。拿 VC 来说，VC 可能会投很多链，这些 Token 怎么管？你要他们去写十几个合约，而且都还要经过安全认证？这是一个大的人力成本。
此外，区块链上合约的任何细节都会被看见，这是有一层安全性问题在那里的。任何人都可以来看这个合约有没有漏洞，而且很多新的链不像比特币或以太坊那样经过了时间的验证，它的合约体系本身有没有问题是不知道的。你会发现一些新的 Token 出问题，90% 都是合约出问题，这是一个大的风险。
所以在多链的情况下，多签还能方便地支持密钥管理吗？目前看其实是很难的。用多签通过合约的方式来管理密钥，使用成本高，安全风险高。
问：如果这些不同的链都是基于相同的数字签名算法，比如 Schnorr，那么不同链的密钥管理方法是不是就可以通用？
谢翔：不，逻辑不是这样的，我给你画一下。多签是这样的，最下边是区块链，中间是数字签名，它有个签名算法，可以是 ECDSA，可以是 Schnorr 等等，最上边是智能合约。
多签是怎么做的呢？就是在最上边的智能合约部分来数合法签名的个数，一个、两个、三个……够了，就把钱转出去。这种方式不在乎下边用的是什么签名算法，Schnorr 也好、BLS 也好，对它来说没有半点区别。
这是多签的一个基本原理，也可以说是好处，它能够和底层的签名算法做到一定程度的解耦。但它的问题是要适配不同链系统，一千条链就需要一千个智能合约，多链的兼容性很弱。
问：那基于 MPC 的门限签名是怎样的？
谢翔：我把这张图重新画一下。最下边还是这条链，中间还是数字签名，上边是智能合约。基于 MPC 的门限签名不会去管下边的链，也不会去管上边的合约，两头它都不会管，它只管右边这部分，也就是链下创建签名的部分。
它的思路是说一个签名一定是有一个私钥的，它把这个私钥以某种方式分成很多「碎片」，这些碎片可以被很多人同时拿着，然后通过一套 MPC 协议，保证这些碎片不需要被拼起来就可以直接产生一个合法的签名。「不需要被拼起来」代表着真正的私钥始终没有、而且也不需要出现。
问：签名是在链下完成的？
谢翔：需要签名的时候，比如说我们公司三个人会在链下跑一个协议，生成一个签名，再把签名放到链上。生成签名的逻辑是放在 MPC 里实现的，出来的是一个标准的签名，但怎么跑这个协议别人是不知道的。
把这个签名结果放到链上去，别人分不清它后面是一个人签的还是多个人签的，因为它的形态、样子就是一个签名，和直接用私钥签出来是一模一样的。这一套签名机制可以完全独立于链，部署在企业的内部。
发现了没有，多重签名主要是去数合法签名的个数，它不依赖于签名算法，但要去适配链系统；基于 MPC 的门限签名主要是去产生一个签名，它依赖于签名算法，但不需要去适配合约和链系统。
基于 MPC 的门限签名与合约模块是完全解耦的，合约是怎么写的、链是怎么样的，它完全不在乎。它只要区别签名算法，只要签名算法是链系统支持的，它就能很好地衔接。算法的话现在可能就是 ECDSA、Schnorr、BLS （以太坊 2.0 可能使用 BLS），所以兼容算法就能兼容很多链。基于 MPC 的密钥管理能做到对多链友好，这是一个大的优势。
另外一个优势就是这套签名机制的策略是链下的，因此更加安全，它避免了合约被黑客攻击的风险，而且设计策略可以更加灵活，因为除了验签外的大部分流程都搬到链下了，使用方可以根据场景，制定自己的碎片管理策略。
问：MPC 在这个过程中的作用是什么？
谢翔：MPC 是一种基于密码学的协同计算框架，广义地理解就是多方各自有私密的输入，一起来完成一个计算任务，在成功完成任务的同时，可以保证整个过程中各自的私密输入不会泄露。
比如一个「2-3 模式」的基于 MPC 的密钥管理协议，意味着一共有 3 个碎片，只要任意的 2 个碎片参与执行协议，就可以产生一个合法签名。这里的签名产生过程，包括碎片产生过程，都可以看成一种安全多方计算，因为在协议执行过程中，产生和交换的所有中间数据都不会直接或者间接地造成碎片明文的泄露。
问：基于 MPC 的门限签名为什么要跟签名算法相关？
谢翔：我有多块碎片，怎么去实现这一个签名出来？这和算法结构是强相关的，所以会存在某个算法容易做 MPC，某个算法不容易做 MPC 的问题。比特币要升级到 Schnorr，Schnorr 是非常兼容 MPC 的，ECDSA 不那么兼容 MPC。
问：在基于 MPC 的密钥管理中，真正的那个私钥存储在哪儿？
谢翔：你会发现有个很好玩的事情，就是在整个密钥管理的生命周期里，真正的私钥从来没有出现过，也就没有私钥存储在哪里这个问题了。这是基于 MPC 的密钥管理的精髓所在，它能够保证密钥能用但不存在。
在传统的密钥管理中，密钥是一种确实存在的数据资产，保管它是一件非常难的事情。基于 MPC 的门限签名在物理层面直接从系统里剥离了密钥，这与传统系统在安全理念上是截然不同的。
在传统方式下，黑客盯住一个点就行，因为私钥就存在那个点上；但基于 MPC 的密钥管理将密钥的安全性分散在多个托管节点里，私钥在任何时刻都会被分成多份在多个地方，黑客可能要攻破第一个、第二个、第三个、第四个，要把四个碎片全部搞定才能拿到密钥，而且必须在某一时间范围内同时拿到四个碎片才能得到密钥，因为密钥碎片是在不断刷新的。
比如密钥是 10，把它拆成两个碎片，分在两个地方。你可以把 10 拆成 5+5，但过一分钟后把它拆成 1+9，再过一分钟后把它拆成 2+8。黑客要在一分钟之内把两个点都攻破才能拿到 10，如果第一分钟攻破第一个地方、第二分钟攻破第二个地方，黑客拿到的是 5 和 9，不是正确的密钥。
问：多签是无法做这种刷新的？
谢翔：没有办法。对于多签，比如参与多签的是三个人，其中一个人的私钥被偷了，那对应的方法不是说刷新密钥，而是要赶紧换地址，把钱转到新的地址里，这在很多应用场景里是个痛点；或者比如说现在是三个人参与多签，需要加第四个人，这个时候也要换地址，然后需要一个新的多签的合约，这是很费劲的，而且转钱到新地址还需要手续费。
但这些对于 MPC 来说就很容易，它可以保证对外的地址一直不变，内部刷新就好。这个好处也是我们看重的点。
基于 MPC 的密钥管理的应用
问：基于 MPC 的密钥管理可以降低私钥的使用门槛吗？这或许是最让普通用户头疼的地方。
谢翔：它可以做到与传统的中心化的方式没有区别，做到用户体验一样：使用数字货币时的操作和你使用微信钱包时的操作是一样的，你不需要去记助记词、或者把助记词存硬件、用本子抄写下来等等。
用 MPC 一个好玩的事情是什么呢？比方说 A 和 B 用 MPC 共同管理一个账户，那么他们俩就可以同时来控制这个账户，但同时都不需要记助记词。如果 A 想用的时候，要发一个请求给 B，B 同意后，A 和 B 通过一套既定的规则，在本地利用各自的碎片计算出一些中间变量，通过信息交换，A 就可以在本地生成一个合法的完整签名，验签通过后，A 就可以把账户里的钱转出去。
当然这里还有一个问题，如何为 A 和 B 生成碎片。事实上，利用 MPC 技术可以实现 A 和 B 各自在本地生成一个碎片，这两个碎片可以隐式地拼接成一个私钥，注意，这种拼接只是一种蕴含的数学关系，碎片实际上从未在任何时刻被拼接过。
这个时候，B 那个角色也可以是一个第三方的服务器。服务器确认一下 KYC，核实是不是你发起的，是你发起的之后它就自动通过，也就是自动给出另一个碎片来一起生成签名。KYC 就是通过发短信、人脸识别、发邮件等等方式，这样一来，用户的操作方式就和传统的操作方式一模一样。这就和实际的应用场景很挂钩了。
我们做了一个叫 KeyShard 的 App，是为了告诉用户基于 MPC 的密钥管理可以怎么用，可以试着体验一下，现在只支持以太坊。它就是模拟的传统的权限管理，要两个人同意才能动账户。
问：回到最开始。你说把传统的对于钱的授权管理机制挪到数字货币领域。在传统审批流程里，可能需要 A 先通过，然后 B 签字，然后 C 签字，这是 MPC 现在就可以做到的吗？
谢翔：这其实是一个很关键的问题。在传统的流程里这叫做传签，传签在 MPC 里会有一些障碍，我画一下 MPC 大概的逻辑。
MPC 这个算法协议是要彼此相连和交互的，比如说经理、财务、CEO 三个人参与生成签名，它是要求这三个人必须同时在线的，所以 MPC 纯算法本身很难做到传签。
但我们可以利用工程架构在产品层面实现传签功能，让上层的用户不用去管也不用去想底层是怎么运行的，对于用户而言，产品的操作体验和传统传签是一样的。所以算法和产品之间是有很大差异的，这里有两套东西，除了算法本身，还需要把技术和业务逻辑结合起来。
问：可以这么理解吗，基于 MPC 的密钥管理不仅是为了安全地存储密钥，它更是为了个人或企业能够方便地、满足业务逻辑地使用密钥？
谢翔：它有多个优势，安全存储是一方面；而让个人或者企业更安全便捷地使用密钥是另一方面。前者是指基于 MPC 的密钥管理对密钥或者资产的「托管能力」，体现了静态的安全性；后者是指基于 MPC 的密钥管理可以主动设计出多样化的策略管理，是一种动态的业务赋能。
问：如果有一个需要管理多种 Token 的投资机构，它是不是可以买一套基于 MPC 的密钥管理算法，然后用这套算法实现对不同链的签名，进而实现对不同链上资产的管理？
谢翔：它不太可能直接买算法，它会买产品，比如买一套基于 MPC 的密钥管理软件装在公司内部的服务器上，然后就可以通过一个界面去管理资产。你可以理解为它买了一套基于 MPC 的财务管理系统。
密钥管理的最底层是一套算法，但可以把它包成产品，也可以包成 App、包成SDK（软件开发工具包）。
问：如果有一个钱包公司，希望钱包添加一个让用户能基于 MPC 管理私钥的功能，是不是可以找专业的提供 MPC 解决方案的公司合作？
谢翔：对。你可以理解为这个市场有投资机构、有钱包、有交易所，还有其它的一些业务公司，它们各自有自己的业务，但它们一定都会有怎么管钱这个问题，我们就是提供一套基于 MPC 的密钥管理能力，也就是基于 MPC 的管钱的能力，来跟它们自己现在的这套系统对接。
从公司的定位来说，KeyShard 其实是一个技术提供商或一个基础设施公司，它把自己往下沉得多一点，不碰上面的业务。它主导的是底层的密钥管理的 SDK，希望把授权管理的业务流程揉到 SDK 里面去，当然难点在于要抽象出一套相对来说足够灵活、好用的 SDK。
基于 MPC 的密钥管理面临的挑战
问：基于 MPC 的密钥管理现在碰到的难点是什么？
谢翔：技术的、非技术的都有。非技术的是有人会问为什么它是安全的？给我个证书。传统 KMS （Key Management Service）是有证书的，但因为基于 MPC 的密钥管理时间没有那么长，没有认证。
这是这个学科的特殊性引发的问题。密码学虽然有坚实的理论基础，但是它分理论安全和实际安全，实际安全是不是能达到理论安全这个层面是需要时间检验的。所以一是需要标准机构，二是需要学术研究的推动。我们会积极地去推进类似标准、去推进工业界对这个技术的认可，但需要时间，没那么快。
技术上的难点就是刚才说的，需要把这一套新的技术和复杂的业务逻辑结合起来。此外，MPC 是一套分布式的技术，分布式的话就会有同步，也就是共识的问题。
原来的授权管理是一个纯中心化的东西，业务流程会很好配；但分布式的场景下会有一定的难度，比如使用者在不在线的问题，网络好不好的问题，如果在密钥刷新的时候有延时，是用后面那个碎片还是用前面那个碎片的问题。这种细节会有很多，都要去考虑。
问：基于 MPC 的密钥管理没有可追究性这种说法是准确的吗？就是说不知道谁签了谁没有签，无法追查责任？
谢翔：其实是可以知道的，从算法层面就可以抓到是谁签的。算法底层可以通过引入检查和举报机制，追查到谁没有签，甚至知道是谁在签名过程中给了不遵循规则的错误信息。
来自使用的需求：
密钥管理是一个正在变得越来越重要的概念，它甚至有可能成为区块链领域一类重要的基础设施。因为当数字货币或 Token 更多的被交易和使用，而不仅仅被一劳永逸地存储时，通过私钥或钱包密码使用资产的方式既不安全，也不友好，更难以满足诸多应用场景的需求。
多重签名和基于 MPC 的门限签名都是实现密钥管理的方法，但它们是截然不同的设计路线：前者在链上，依靠智能合约数合法签名的个数；后者在链下，依靠 MPC 用碎片生成合法签名。本文重点介绍的是后者，也就是基于 MPC 的密钥管理，希望能对你了解这种技术和方案有一些帮助。
重新认识「私钥」：私钥不是钥匙
「私钥」这个词带来的直觉反应是，它是一种「钥匙」，作用是打开保管着数字货币的保险柜，想一想也似乎有道理，使用私钥就能拿到币。但实际上，在区块链和数字货币领域，私钥就意味着资产本身。
试想，你的保险柜钥匙丢了，你的钱是依然还在的，你可以再配一把钥匙；但如果私钥被忘了，钱可就永远消失了。你的保险柜钥匙被偷了，你的钱可能依然安全，因为小偷还需要溜进大楼、撬开房间的门锁；但如果私钥被偷了，钱几乎立马就不再属于你。
私钥不是那把打开保险柜的钥匙，它是要被放进保险柜的资产本身。而如何设计一个保险柜系统存放私钥，使得柜中的私钥既安全、又易用，就是密钥管理。届时，交到用户手中的就不是私钥，而是一套打开保险柜的钥匙。
多重签名和基于 MPC 的门限签名都是实现密钥管理的方法，但它们是截然不同的设计路线：前者在链上，依靠智能合约数合法签名的个数；后者在链下，依靠MPC用碎片生成合法签名。本文重点介绍的是后者，也就是基于MPC的密钥管理，希望能对你了解这种技术和方案有一些帮助。
- 免责声明
- 世链财经作为开放的信息发布平台，所有资讯仅代表作者个人观点，与世链财经无关。如文章、图片、音频或视频出现侵权、违规及其他不当言论，请提供相关材料，发送到：2785592653@qq.com。
- 风险提示：本站所提供的资讯不代表任何投资暗示。投资有风险，入市须谨慎。
- 世链粉丝群：提供最新热点新闻，空投糖果、红包等福利，微信：juu3644。
