Maxim Orlovsky，LNP/BP标准协会
在论文中，我们提出了一种方法，可以升级第1层（区块链/timechain），而无需使用SoftFork。客户端验证的升级利用属性可以是逐渐的，具有无许可的部署选项（即不需要多数支持或矿工合作），并且将具有订单的可扩展性
比特币一词已经获得了多种含义，因此我们使用更具体的术语来区分它们。我们将比特币用作一般表示该系统的通用伞术语，其中可能包括多个层（包括一些未来）以及来自Nakamoto Satoshi的点对点电子现金系统的总体想法。同时，我们使用BTC将比特币表示为数字稀缺，金钱和货币。我们还区分了比特币POW共识（选择下一个块生产商的规则）， Nakamoto共识（包括加密经济的矿工惩罚手段增强的POW共识）比特币协议（BP）作为用于使用比特币交易的一组标准，技术和工具（在任何可能的第1层中）。
Nakamoto Satoshi对比特币的最初实施带来了一个奇怪的想法，每个人都需要验证全世界的交易。这个想法获得了区块链的名称，或者有时是Timechain ，这成为有公众访问的分类帐的委婉语。账本的引入造成了两个问题：缺乏可扩展性和不良隐私性；首先阻止采用和网络效应发生；另一个与比特币的最初的Cypherpunk精神矛盾，代表了一种战略性的文明风险（有关适当的文明和Cyphernox宣言，请参见Cypherpunk的必然性）。
可伸缩性和部分隐私问题通过引入第2层系统（如闪电网络和其他提议的解决方案）解决了。其中，最富有成果的是Sidechain的想法，Sidechain的想法是最初的区块链技术限制的大部分（如果不是全部），同时仅解决了低可编程性的问题，它为实验创造了一个用于实验的沙盒，并部分地是隐私的某些方面。闪电网络 - 一种已经部署和运行的更成功的第2层解决方案 - 由于需要过度集约化，八卦流量吞吐量的局限性（既导致网络集中）以及降低的安全性/无信任/无信任/无信任/无信任/无信任/无限在高基层条件下[..]。其他提议的替代方案，例如方舟，都需要几个基础层变化（一个或两个软叉），这给部署带来了挑战。最后，没有现有或提议的第二层解决方案解决原始的比特币基础层隐私问题 - 其他以隐私为中心的第1层解决方案（如CoinJoin）仍然无法保护法律当局，并引入了其他BTC函数函数问题。
因此，可以得出结论，是基于分类帐的区块链方法的建筑物1，必须完全重新考虑以解决上述问题。这个空间中的第一个想法是彼得·托德（Peter Todd）在2016年和2017年的回到2016年，当时他指出某种州的所有者（例如BTC或任何其他状态合同）需要验证交易历史的一部分 - 该部分是与他们的所有权直接相关 - 并省略其余的。他命名了他的方法客户端验证。 GIACOMO ZUCCO设计的协议能够使用此方法创建资产，名为RGB 。在我以前在LNP/BP标准协会的工作中，我能够进一步开发RGB，并将其转换为具有丰富状态和有限的Turing-Complete计算的第一个通用客户端验证的智能合同系统，提供了足够的功能来运行任何内容可以使用基于区块链的智能合约来完成 - 但是如果没有公共分类账/区块链存储任何用户数据，直接利用比特币POW共识协议的反双重支出属性。该系统是在四年期间公开开发的，并于2023年4月获释。
在当前的建议中，我们证明，如果提供了比特币，则可以将比特币（如RGB）升级到一个系统，而无需公共分类账（区块链）的限制属性，而在保留POW共识协议的同时，则它可以基于新的可扩展的非区块链第1层（代号为Prime ）。由于状态，计算和验证的存储将移至上面的客户端验证层，因此该层将能够托管理论上不确定的交易数量（每分钟至少数十亿美元）。这样的设计不需要闪电网络或其他可扩展性和付款层在最坏的情况下，并且在最坏的情况下
该协议具有三个部署选项（无许可，矿工激活和软叉），前两个不需要任何软叉。选项是独立的，但也可以以此方式部署。
该提案为比特币作为数字现金提供了一些好处：
提出的系统的一些相对缺点是：
拟议的系统（代号为Prime ）由四个主要组成部分组成：
这些组件在其功能上与区块链型分类帐具有共同等效。但是，在我们的设计中，它们被抽象了，比其他任何区块链系统提供了更多的可扩展性和隐私性。
在其基础上，Prime运行了一个时间戳服务，创建了一系列标题，每个标头都承诺要归于外部客户端验证数据的默克尔树根：
classDiagram
方向LR
`标题n` <| - `标题n+1`
类`header n` {
prev_commitment
merkle_root
merkle_tree_height
时间戳
//战场
tlv_extensions
}
类`标题N+1` {
prev_commitment
merkle_root
merkle_tree_height
时间戳
//战场
tlv_extensions
}
每个标头配备了可选的TLV扩展名，可用于将来的协议升级；它的大小独立于客户端验证数据的默克尔树中包含的交易数量，并且订单为100个字节（取决于TLV数据）。
Prime不能提供任何防止双支出的保护；它将由系统的客户端验证部分提供。时间戳系统的唯一部分经过验证（共识规则）是：
主要标题是唯一需要公开和全球可用的信息；这可以通过使用分布式P2P网络来实现。
证明默克尔树（ PMT ）是将客户端验证数据与标题联系起来的中间和短暂结构。 PMT由矿工生产，并通过与标题相同的或其他方式向公众提供；但是，与标题不同，它们不需要坚持。每个网络用户都跟踪所有新的PMT，提取与其拥有的状态相关的信息的一部分，将其保存到自己的客户端验证数据中，并丢弃PMT的其余部分。
由于短暂的性质，缺乏验证，并且不需要了解挖掘下一个标头的PMT内容，因此PMT大小不会影响系统可伸缩性。因此，PMT可能是（多个）千兆字节的大小，承诺进行数十亿美元的交易。
树木的叶子包含目击者关闭一次性封闭：下一节中详细描述的一种机制。 PMT是根据多协议确定性承诺方案LNPBP-4标准构建的，如今在RGB中用于在比特币交易中托管承诺（无论是链接和内部外科方案，例如Lightning）。这意味着每种单使用 - 在PMT中具有独特的预定义位置，因此单个默克尔路径和叶子证人足以证明特定的单使用 - 封闭方式的关闭（或没有关闭）给定标题。用户跟踪尚未关闭的一组一次性单用密封（UTXO集的类似物），并从每个新生产的PMT中提取相对证明。如果他们的密封未关闭，则这些是非操作的证明（因为证人在该路径上表现出了不同的一次性密封）。
这些证明构成了客户端验证历史的时间依赖性的部分。节点的记忆要求将以时间依赖的方式增长为
在哪里
这在对数上比任何区块链节点的可伸缩性都要好
在哪里
在哪里
这
在哪里
单使用 - 密封协议可防止对系统的双重支出攻击。
一次性密封（或密封）是彼得·托德（Peter Todd）提出的一种特殊形式的加密承诺。可以将原始性与其他形式的加密承诺进行比较，该承诺包括哈希功能和时间戳：
有关单使用 - 密封构建的更多信息，请在LNPBP-8标准中提供。 Prime使用一种特殊设计的单使用 - 密封形式，该形式与现有协议（例如RGB）中使用的形式不同。
一次性密封的定义由两个组成部分组成：
unique_id ：全球唯一的用户生成的标识符，可以从合同_ID，合同操作哈希和合同操作输出编号确定生成；spending_conditions_cmt ：将来可以关闭密封的条件的承诺（哈希）（类似于比特币交易输出中的scriptPubkey ）。密封件是在客户端验证的智能合约系统（RGB或类似RGB）中定义的。每个密封件可能具有指定的状态（如RGB中），例如BTC余额或任何其他丰富的数据。当用户喜欢更新该状态时 - 或将其所有权转移给另一个用户时，必须准备一个状态过渡，以定义新的一次性单用途和新状态。接下来，目击者结束了一次单用途的构建，致力于国家过渡数据并提供源脚本，匹配支出条件的承诺以及满足该脚本/条件的数据。提出的提议摘要所使用的特定脚本系统（可以简单起见，如今RGB中的Aluvm，并且希望EVM不要:)；可以使用version字段指定脚本引擎，以便随着时间的推移可以引入新的引擎或操作编码（请参阅升级性部分）：
classDiagram
方向LR
定义<| - 证人：unique_id
类定义{
unique_id
spending_conditions_cmt
}
班级见证{
版本
unique_id
state_transition_cmt
spending_conditions_src
满意度_data
}
证人以明确的形式放置在Ptree的叶子内，并提供给矿工，建造Ptree和标头。叶子必须unique_id地放在默克尔树中，例如，
Merkle匹配unique_id默克尔路径，以及叶子内容（提供见证数据）允许验证每个单一使用式密封是否在智能合约的历史中一次又一次地关闭了一次 - 并且它已关闭以满足脚本状况。请注意，从定义为到关闭时，必须为每个单使用密封的unique_id积累证明，这是证明密封件之间未关闭的要求。只要它们证明了不同的unique_id ，这些证据就可以省略对隐私敏感的支出条件源代码和满意度数据，仅提供其哈希；因此，历史证人可能是固定的。如前所述，出于可伸缩性目的，也可以使用零知识证明进一步压缩证明的历史。
当使用无许可选项部署系统时，该系统将需要其自己的共识协议。协议的安全性并不重要，因为它与以下所述的专用机制挂钩。达成共识的唯一要求是对审查制度，这意味着一套开放的无身份矿工/验证者。仅有的两个共识方案可以满足这些特性，是POW和OUROBOROS CRYPSISISISISISISISISISISISISISISISISISISISISISISISISISISISISISE型号由矿工奖励保证。
时间戳记服务没有任何加密货币，矿工从第1天开始就获得了费用。矿工费用的专用合同由RGB或其他客户端验证的智能合同协议提供，该协议指定了付款方式（BTC（BTC） ，Stablecoin或令牌付款）。矿工必须参加无许可的匿名P2P网络，该协议的用户在其中发布了配备交易的证人，并向“挖掘下一个标题的人”支付费用。矿工将这些交易包括在其客户端验证的历史中，并通过这样的能力在将来使用赚钱的资金。
在系统的那一刻，在比特币区块链上创建了一个专用的“任何can-gend”输出，其固定量的SATS。有关此UTXO的信息成为创世纪的一部分，并作为采矿单使用 - 封装的定义。解决POW挑战的矿工必须花费该输出，而在支出比特币交易内部为采矿标头提供了一个TapRet承诺，并为下一位矿工提供了新的“任何can-can respend”单使用单封装。这以独特的方式将创建的标头固定在比特币区块链上，以使唯一有效的时间戳标头序列是遵循单个单使用式密封序列的序列。
如果一方在不产生承诺的情况下花费当前的矿工单利用 - 或致力于没有足够POW的标头，则这种结束被认为是无效的；在这种情况下，任何一方都可以创建特殊的比特币交易，以提供有关新矿工单使用 - 销售（协议重置）的公开识别OP_RETURN信息（“公告”）；只有第一个使用适当程序关闭的OP_RETURN公告在共识规则下被视为有效。
POW单使用密封锚定代表一个完整的共识协议，该协议可以由系统运行，而无需其他任何其他共识（POW或BFT）。另外，它可以与次要共识结合使用，并具有规则，即除非第二个共识协议的安全性低于比特币POW安全性，比特币POW具有优先级 - 在此时，将自动切换回到次级共识为主要共识。条件未满足。
我们故意在此提案中没有解决P2P网络结构的问题，因为多个替代系统可能以市场驱动的方式共存并竞争。相反，由于网络属性对于项目的目标很重要，因此我们定义了选择P2P网络的一般要求：
在当前时刻，我们看不到符合上述属性的网络；但是，我们看到几个网络有可能向他们发展：
我们计划在RenoSTR项目上工作，利用我们先前的Storm协议中的工作以及使用BIP-324风格的端到端加密。其他项目可能会建立替代解决方案，最佳选择应由市场选择。
我们在如何将提出的解决方案部署到比特币中看到了三个步骤或选项。每个步骤都是可选的；该系统可以在没有任何一个或两个的情况下运行。此外，每个选项都有自己的权衡，但是，如果部署为随之而来的步骤，这些权衡会逐渐解决。
该系统可以独立于比特币TimeChain启动，并通过基于单使用 - 密封的专用机制（我们在论文中描述）将共识固定在比特币POW的安全性上。这不需要在矿工侧或任何比特币软/硬叉上进行任何更改，但是，使用此设置，BTC只能以一种方式将BTC传输到新系统 - 另一种方式需要联邦。
比特币矿工开始处理主要交易，并承诺将时间戳服务标头推向比特币区块链Coinbase，就像在合并采矿的情况下一样。这消除了对专用的主要共识的需求，但很容易受到哈希电力攻击的影响，要求大多数矿工在其部署之前加入该协议。
该提案不需要任何特定的软叉，但是，使用当前的比特币共识规则，它无法为BTC从新的Prime System转移回比特币区块链。尽管我们不认为这是一项要求（主要优势比区块链有太多好处，因此我们认为区块链已经长期死亡），但在短期内，这可能会给平台采用带来挑战。
有很多不同的软叉建议可以实现此类功能。它们分为两个主要类别：
采用这些建议中的任何一个都将允许在Prime平台上对BTC进行无信任的钉子。我们自己的偏好追随零知识的操作编码，因为它们还有许多其他好处，并且不提供不可避免的Drivechains的权衡。
升级客户端验证系统与区块链 - 或P2P网络（如闪电）升级非常不同。这是由于区块链是完全复制状态机的共识协议，而客户端验证使用部分复制。一方面，这使得以与未知状态相关的各个部分升级系统变得更加简单 - 但另一方面，由于网络提供的全球可访问状态上没有非晶体经济驱动的保证，很难协调任何升级。
换句话说，客户端验证升级在根本上与区块链硬叉和软叉有根本不同，并且需要引入新的概念和术语。
如果某事无效，并且在升级后已变得有效（我们称此快速变化为变更），那么所有现有用户都不会受到影响：他们已经拥有并管理有效的状态。但是，他们可能无法与运行该软件较旧版本的用户进行交互 - 如果同行同意升级，则可以解决问题。升级不会给这些同行带来任何风险，因为他们不会使用他们拥有的任何州，并且升级不会触及历史数据。
另一方面，有效的情况 - 在新规则下变得无效 - 大不相同：用户可能会永远失去现有状态，并且必须尽可能地反对升级。我们称这种升级后背的升级，只有在发现关键的错误时，我们才认为它们是可以接受的：升级将通过真诚/非作战用户的愿望“协调”，以避免错误引入问题。
如果将RGB或RGB启发的系统用作智能合约组件，则该部分的升级将具有另一个独特的功能。 RGB将每个程序（“智能合约”）隔离到沙盒中；一旦签发合同，就无法升级到该协议的新版本。升级的唯一方法是在发行人（或发行人委派的当事人（包括社区）的当事人）将州从旧合同转移到新合同时，以及合同的每一份，业主将同意这一点。
作为附带的好处，这种方法允许逐步引入新功能，说明等，而在区块链世界中无法实现：新合同的发行人不取决于先前的协议版本，并且可以提出更高级的解决方案，而无需任何额外的升级风险或社区协调。
作者感谢Giacomo Zucco，他是那个介绍删除比特币依赖受限区块链并将客户端验证视为前进的人的想法的人。多年来，与他和彼得·托德（Peter Todd）进行了多次讨论，有助于设计系统的许多部分。作者还想提及Alex Kravets，Federico Tenga，Olga Ukolova是对话者，他们花了很多时间在讨论与客户端验证，区块链缺陷和无区块链设计有关的问题上。
