LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 新闻观点 > [NuCypher] 工作还是不工作– NuCypher网络中的责任制

[NuCypher] 工作还是不工作– NuCypher网络中的责任制

2020-12-12 wanbizu AI 来源:区块链网络

>>在NuCypher上查看

在NuCypher的土地上,有一组字符:Alice,Enrico,Bob和Ursula。 当前,作为NuCypher提供的服务之一,这些字符一起工作以实现分散的访问控制服务(或密钥管理系统)。

特别地,爱丽丝拥有一些数据,这些数据以她的公共密钥加密存储在某个存储网络上。 爱丽丝想去度假-插上自己的话。 她忠实的诚实朋友Enrico将继续加密Alice的数据并将其分发到存储网络。 不在时,爱丽丝想给鲍勃一些对这些数据的临时访问权。 不是无条件访问,而是她希望满足三个条件:存储网络无法查看原始数据,Bob和存储网络均未获得秘密解密密钥,以及给定的访问策略(指定持续时间和必须执行哪些数据访问)。

NuCypher的土地居民喜欢分散式解决方案。 因此,他们诉诸于花哨的加密原语(即阈值代理重新加密)和基于智能合约的加密货币(以太坊)来构建一项服务,该服务将帮助爱丽丝完成自己的任务。 爱丽丝可以招募Ursulas,以将其公钥下的密文转换为鲍勃的公钥下的新密文。 因此,在联系Ursulas之后,Bob获得了一个密文,只有他才能解密。 所有这些都可以在没有Alice干预的情况下完成! 这样她就可以享受她的假期而不会阻止Bob。

自由劳动?

厄休拉(Ursula)出于自己的良心不提供这项服务。 她从Alice和NuCypher网络中收取用于提供重新加密服务的费用。 前者是爱丽丝为Ursula维护的每个访问策略支付的服务费(以太币),而后者是来自网络的补贴(新铸造的NU令牌),就像其他加密货币的采矿费一样。

付款金额是根据Ursula的可用性,她参与的保单数量以及加入网络时所承诺的股份数量来计算的。 为了确认是否在线,Ursula不得不不时地调用NuCypher智能合约之一中的功能,以确认她可以满足Bob的请求。 这是一个空函数调用; 它不需要任何证据证明Ursula在过去的一段时间内对Bob表现良好或有反应。

工作还是不工作,这就是问题所在!

作为一个自私的玩家,厄休拉可以采取任何策略,甚至是那些偏离诚实行为的策略,以最大限度地提高自己的财务利润。 这涉及允许Ursula节省资源并收集全部付款的任何技术,就好像她已经花费了全部资源来提供重新加密服务一样。

厄休拉意识到,目前确认活动的方法是有缺陷的。 她可以脱机,忽略Bob的请求,而只能上线以调用确认活动功能,该功能再次不需要提交任何证据来证明Ursula在过去的一段时间内处于在线状态并做出了响应。

此外,收入计算(费用和补贴)与Ursula服务的请求数量无关。 因此,一个主动的Ursula可能会处理大量的重新加密请求,而一个没有收到任何请求的人(或更重要的是,一个没有回答Bob的请求的恶意/懒惰的Ursula),都将收集相同数量的如果他们持有相同的保单,则获得收入。

尽管如此,厄休拉还是有经济动机来记录她的空缺情况并提供令人满意的服务水平。 如果她“作弊”,她将冒着贬值其股份的风险,因为该网络对于将要退出和停止支付费用的用户的用处不大。 但是,我们认识到长期需要一种更智能,更专业的技术来对Ursula负责,并防止她欺骗该系统。

网络运营阶段的影响

回想一下,厄休拉收取两种付款方式:补贴和服务费。 就像其他加密货币一样,一旦所有NuCypher的NU令牌被铸造,补贴将在稍后消失。 这样,厄休拉只剩下服务费作为收入来源。 我们发现,财务激励措施的这种变化影响了我们需要采用哪种问责(或确认活动)技术以增强Ursula的诚实性。

在网络启动后的头5到8年,补贴可能会主导费用,我们担心Ursulas的可用性以及它们是否愿意满足Bob提出的所有请求。 换句话说,不管请求的数量如何,收入总值(补贴和费用)都将根据Ursula在线且行为良好的时间长度来计算。

另一方面,在后期阶段,当补贴消失时,确认活动将与提供重新加密服务联系在一起,从某种意义上说,将根据提供的服务量部分计算付款。 这要求Ursula通过证明她在给定期间内已满足给定数量的不同的重新加密请求来确认其??活动。

为了清楚地区分,我们将第一个称为确认可用性,第二个称为确认服务活动。

强制“上班”

我们为两种形式的确认活动介绍了几种解决方案。 这些解决方案在信任,安全保证,交互性和效率方面有所不同。 我们在下面简要介绍这些解决方案,而在此处可以找到更详细和完整的版本。

确认可用性解决方案。在这里,我们使用嵌入在乐观服务监视过程中的检测和惩罚方法。 这意味着仅当Bob抱怨Ursula无响应时才调用它。 提议的解决方案将Ursulas标记为正常工作的Ursulas和网关Ursulas。 定期与前者联系以处理重新加密服务,而后者则作为挑战者,仅在收到鲍勃的投诉时才与他们联系-那时他们将证明是否确实无法使用正常的Ursula。

因此,对于每一轮,都会随机选择一组Ursulas作为门户。 鲍勃照常进行操作,方法是联系爱丽丝政策中记录的一组正常工作的Ursulas,以进行重新加密服务。 如果正在工作的Ursula没有回复,则Bob会向网关Ursula投诉,并将请求交给她。 该网关通过再次转发请求并等待答案来挑战工作中的Ursula。 如果收到一个,则网关将其转发给Bob并关闭投诉。

另一方面,意味着没有收到响应,网关会通知为该回合选择的其余网关重复相同的过程。 如果他们中的任何一个都未收到答复,则法定人数将集体签署针对正在工作的Ursula的不可用证明,并将此证明提交给NuCypher抵押合同。 这样的证明将导致Ursula的部分股份被削减,以作为惩罚。

确认服务活动解决方案。在这里,我们设计了三种解决方案,这些解决方案允许为表示已服务请求数量的一些正整数ω生成证明“一条Ursula已正确服务ω个不同的请求”的证明。 这些解决方案被称为基于零知识证明(基于ZKP),委员会认证以及基于提交/挑战/开放的解决方案。

为了基于ZKP的方法,我们利用以下事实:在我们的网络中,每个Ursula已经产生了一个ZKP,证明了她执行的每个重新加密请求的正确性。 我们的解决方案是将一轮中所有已送达请求的证据汇总为一个证明上述声明的证据。 可以通过使用通用技术(例如,携带证明数据(PCD)或增量可验证计算(IVC))来完成此累积。

另一种可能更有效的方法是,将以上陈述视为算术电路可满足性问题的一个实例,并将其与高效的ZKP系统(例如,防弹)结合。 也就是说,建立一个以正确性证明集及其计数ω作为输入的电路,如果正确的不同证明的数量等于ω,则输出1。 然后,调用电路解析器将电路转换为防弹格式,从而允许证明者(在这种情况下为Ursula)生成单个证明。 Ursula可以将此证据提交给网络以要求其付款。

至于委员会认证方法,它具有相似的主题,以确认前面提到的可用性解决方案。 对于每一轮,都会选举Ursulas委员会(可能还有外部验证者)来证明Ursula所承担的工作量。 详细地,正在工作的Ursula将她服务的所有Bob请求以及正确性证明发送给该委员会。 核实所有证据后,委员会集体签署“厄休拉语已正确满足ω个不同的请求”的声明,同时将ω替换为实际服务的请求数。 委员会(或工作的Ursula)将签名的声明提交给网络,以便工作的Ursula可以要求她付款。

最后,对于提交/挑战/开放式,我们从Dottling等人提出的基于Merkle树的ZKP系统中引入了一种机制。 对于每一轮,工作的Ursula都会构造一个Merkle哈希树,其中包含所有服务的请求及其正确性证明。 然后,她使用根作为随机信标,将其输入到迭代哈希过程中,以随机选择n个叶节点以打开它们(即,这些都是挑战)。 Ursula对Merkle树的根进行签名,活动证明将由签名的根,质询叶节点及其开口以及质询叶的成员路径组成。 Ursula将此证明发送到侧链(由全选委员会维护)或发送到主网络进行验证。 验证后,Ursula将获得服务付款奖励。

当前和未来计划

采用哪种解决方案将基于基准测试和NuCypher网络的发展前景。 基于ZKP的解决方案具有许多优点,包括非交互性,这与需要与委员会进行交互的委员会证明相反。 与提交/挑战/开放解决方案的统计之一相比,它还支持计算的可靠性。 但是,可能存在其他解决方案更有效的情况,特别是如果我们合并了委员会证明或侧链以支持网络中的其他功能。

因此,目前,我们搁置所有这些解决方案,并继续探索更多的创造性技术来解决活动确认问题,以使NuCypher以及该空间中其他分散的,可能相关的项目受益。 我们还设想,某些提议的技术将对NuCypher网络可能提供的未来服务有用。 我们的下一步将研究这些技术的实施,测试和采用。

>>在NuCypher上查看

帖子 [NuCypher] 工作还是不工作– NuCypher网络中的问责制首先出现在AZCoin新闻上。

—-

原文链接:https://azcoinnews.com/nucypher-to-work-or-not-to-work-accountability-in-the-nucypher-network.html

原文作者:hoanhdotat

编译者/作者:wanbizu AI

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...