您如何强迫一方诚实（服从协议规则）？
我已经看到了一些机制，例如承诺，证明等，但是它们似乎并不能解决整个问题。在我看来，协议设计的结构和这种机制必须能够胜任。有没有人对此有很好的分类。
编辑
在设计安全协议时，如果您强迫一方诚实，尽管这种实施有其自己的收益，但设计会容易得多。我已经看到在设计安全协议时，设计人员会假设某些东西对我来说似乎并不现实，例如，假设所有各方在最坏的情况下都是诚实的，或者是假设维护用户数据的服务器是诚实的。但是，在更严格的模型中查看协议的设计时，您很少会看到这样的假设（至少我还没有看到它-我主要研究协议我认为Canetti的UC框架尚未完全形式化）。我想知道，您是否可以对强迫一方诚实的方式进行很好的分类，或者是否有任何编译器可以将输入协议转换为诚实方？
现在，我将解释为什么我认为这虽然看起来无关紧要，但仍无法完成任务。在受益于理想/实际范例的UC框架中设计协议时，理想模型中的每个通信链接都经过身份验证，在真实模型中并非如此。因此，协议设计者寻求通过PKI假设或CRS（通用参考字符串）来实现此通道的替代方法。但是，在设计身份验证协议时，假设经过身份验证的通道是错误的。假设我们正在UC框架中设计一个身份验证协议，则存在一种攻击，攻击者伪造了一方的身份，但由于在理想模型中假设使用了经过身份验证的链接，因此在此框架中未假定该攻击！您可以参考对组密钥交换协议的内部攻击建模。您可能会注意到，Canetti在他的开创性著作《密钥交换和安全通道的通用组合概念》中提到了以前的安全概念SK-Security，它足以确保身份验证协议的安全。他以某种方式承认（通过陈述，这是技术性问题），在这种情况下，UC定义过于严格，并提供了一个轻松的变体，称为非信息预言（这使我感到困惑，因为我在任何地方都没有看到这种安全模型） ，我无法将此安全模式与任何其他安全模式匹配，可能是我缺乏知识：D）。
[作为旁注，几乎可以将任何Sk-secure协议转换为UC安全协议，而与模拟器时间无关。例如，您可以删除消息的签名，然后让模拟器以虚拟方式模拟整个交互。有关证明，请参见通用组合贡献组密钥交换！现在假设这是一个多方参与的组密钥交换协议，模拟器的效率是多少？这是我在此论坛中提出的其他问题的起源。]
无论如何，由于在普通模型（基于UC）中缺乏承诺，我寻求其他方法通过绕过这种放松的需求来使协议安全。这个想法在我脑海中非常基础，通过研究普通模型中canetti的最新承诺方案而浮现在脑海：从标准假设中研究普通模型中的自适应硬度和可组合安全性。
顺便说一句，我不寻求零知识证明，因为由于我不知道的原因，每当有人在并发协议（通过UC框架）中使用其中一个时，其他人就提到该协议效率低下（可能是由于模拟器倒带）。