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是對話者，他們花了很多時間在討論與客戶端驗證，區塊鏈缺陷和無區塊鏈設計有關的問題上。
