本文提出了一个用户可定义惩罚的方案，以解决预确认（preconf）的加密经济安全问题。用户可以根据自己的需求，为预确认指定不同程度的惩罚结构，从而让市场自然地确定合适的参数，而不是预先设定。
感谢 Justin Drake 和 [Ryan Sproule](https://twitter.com/sproule) 的帮助。_
简而言之： 允许用户在请求预确认时指定他们偏好的惩罚方式，从而使市场能够自然地建立预确认密码经济安全参数，而不是预先设置参数。
随着社区对预确认的设计达成一致，一个关键的选择出现了：我们如何确保预确认的密码经济安全？具体来说，存在哪些激励措施来防止安全或活性故障？在提出替代方案之前，我将对当前的解决方案进行一个高层次的概述。
以下是当前的机制（它们可以组合使用）：
-
基本罚没： 如果提议者对安全或活性故障负有责任，他们将被罚没。
- 未解决的问题： 应该罚没多少？提议者应该投入多少抵押？
-
冻结： 提议者的抵押被冻结，导致他们损失资金的时间价值。
-
动态声誉罚没： 验证者的每次故障都会导致越来越严格的惩罚；例如，他们可能会被罚没更多或锁定更长时间。
- 未解决的问题： 惩罚曲线应该是什么样的？它应该是基于时间的，并在一段诚实行为后重置吗？
-
保险： 提议者必须赔偿因故障导致预确认失败的用户。实际上，用户的预确认被保险了。
所有这些机制都需要我们事先知道预确认用户想要什么。不可避免地，这将是主观的，并导致无谓损失，因为一些可能想要预确认的用户可能会对设置感到不舒服。此外，一些提议者可能会对参数化感到不舒服，并选择不提供预确认。最好的解决方案是允许用户与提议者合作，就适当的密码经济安全级别达成一致。
我的解决方案：用户定义的惩罚
用户应该能够通过在其预确认中附加惩罚结构来指定他们期望的密码经济安全级别。该结构将详细说明故障的后果。
例如：
// 在这里，用户可以定义与任何特定故障相关的惩罚，
// 并且系统具有足够的通用性，可以允许任意复杂的规则。
struct PreconfAgreement<C: Condition, P: Penalize> {
faults: Vec<Fault<C, P>>,
}
struct Fault<C: Condition, P: Penalize> {
condition: C,
penalties: Vec<P>,
}
trait Condition {
fn should_penalize(...) -> bool;
}
trait Penalize {
fn penalize(...);
}
注意：当评估条件时，与无界计算相关的存在 DoS 向量。应该使用一些 gas 计量，或者应该将条件构造为简洁的语句（例如，SNARK）。
此解决方案是公正的，并允许市场自然地确定适当的参数。用户可以决定他们想要的安全级别，而不是让协议来估计，而提议者可以选择他们的风险回报概况。更重的惩罚可能会导致用户更高的成本。
复杂性问题：
