業務流程建模是任何大中型組織的常見策略 。透過工作流程過程的視覺化可以對其進行分析、改進和自動化 (圖 1) (figure 1)。這些模型人類與計算機都可以理解，與僅使用自然語言或程式語言編寫的過程不同。
對於組織之間的合作，建模不僅是為了改善溝通。各方必須具體說明工作程式，這將作為具有約束力的協議 [8]；這就是 LTO 平臺所謂的 互動合約。
LTO 平臺給每一個互動合約都會建立一條臨時性的私有區塊鏈。此鏈的目的並不是作為不可改變的賬簿，而是保留各方組織都擁有最新的會籤歷史事件和共享狀態。
1. 智慧 vs 互動合約
互動合約與實施於以太坊區塊鏈的智慧合約目標相似。兩者都定義和鞏
固可在無信任和可驗證的情況下施加的邏輯。
但是，這兩種數字化合約背後的理念非常不同。以太坊將智慧合約描述為包含價值的加密“盒子”，而這盒子只有在滿足某些條件時才會解鎖 [10]。互動合約並不直接保留價值，而是描述兩方或多方應如何互動。它們的意圖更接近傳統（紙質）合同的意圖。
1.1 李嘉圖合同
互動合約符合李嘉合同的定義。最值得注意的是，人類和程式都可輕鬆閱讀。這是從定義互動合約的方式獲得的屬性。既沒有用於法律目的的自然語言版本，也沒有用於程式設計執行的程式碼版本。
1.2 執行
鏈上執行不適用於很多現實生活的案例。智慧合約依賴於主動執行，這意味著違反協議必須是不可行的或者得使任何一方必須退出 。
就以保密協議為例。區塊鏈不可能阻止一方透露資訊，也無法強迫一方積極參與解決洩密行為。如果希望這種協議成為自我執行的合約，它必須將全部違約金扣住作為押金。這將確保每一方都會為自己的利益參與決議。
對於大多陣列織而言，將大量資金用作合同的違約金存款是不切實際的。除此之外，罰款和類似措施的有效性僅限於智慧合約所持有的押金。
大多數業務流程都要求透過權威機構鏈下解決爭議。互動合約可以促進爭議的刪除過程。這可能包括衝突談判，調解，甚至仲裁（透過仲裁者或法官）。在 LTO 平臺上執行流程會形成可驗證的事件歷史記錄，從而減少不對稱的資訊。資訊的分配會影響爭議時的談判 ，並影響第三方權威機構進行的評估。
1.3 使用者介面
以太坊提供了一種內建的圖靈完備指令碼語言，程式設計師可以使用它來構造任何數學方式定義的智慧合約或交易。這使它們非常抽象，因正在執行的合約所包含的狀態沒有內在含義。
要與此類合約進行互動的話，必須為特定的智慧合約建立特定的使用者介面，或者說，建立此類合約的介面 。這些介面可以標準化，如 ERC-20與ERC-721，會把使用者介面與合約邏輯分開。缺點是這也限制了設計合約的可能性。
透過互動合約，合約內的資訊確實具有內在意義。雖然這限制了用例，但它確實能夠純粹基於合同及其過程提供的資料生成介面。因此，任何工作流程都可以在 LTO 平臺上進行數字化和執行，而無需為每個工作流程建立特定的介面。
1.4 指令與整合
互動合約包含針對特定人員或節點的指令。一個節點可以根據指令行動或通知使用者某個操作即將被執行。此操作可包括透過 HTTP API 呼叫從網際網路獲取資訊。
在以太坊和 Hyperledger 中實施的智慧合約邏輯只能改變區塊鏈的狀態。智慧合約需要透過預言機將資料從外部源提交到區塊鏈。
這個預言機可以根據智慧合約的狀態行事，但是這預言機的邏輯不會是合約的一部分。不過，這種邏輯在本平臺是互動合約的一部分，因此各方參與者可能會對其進行驗證，並可能引起爭議。
2 有限狀態機
互動合約將工作流定義為 有限狀態機 (FSM)[18]。這使我們可以將其顯為流程圖 (figure 2)。這樣，人類和計算機都可以理解工作流程。
2.1 確定性有限狀態機
任何區塊鏈邏輯都需要是確定性的。計算機程式可能需要額外的努力來符合此標準，但是確定性有限狀態機（DFSM）本身是確定性的。
2.2 擴充套件有限狀態機
圖 2 顯出了需要多數操作到達某個狀態而它們發生的順序是任意時，會出現問題。這可以被建模為每個可能順序的過渡路徑，如圖 2所示。但是，透過這種方案解決，狀態和狀態轉換的數量將隨著操作的數量呈指數增長。這不僅使工作流的圖形不太清晰，而且還會使定義工作流更加困難和容易出錯。
因此，互動合約不使用常規有限狀態機，而使用的是允許條件狀態轉換的(EFSM) 擴充套件有限狀態機。
圖 3 用 EFSM（擴充套件有限狀態機）視出與圖 2 相同的工作流程。
2.3 交流性有限狀態機
有限狀態機僅限於順序行為；而們不支援併發程序。若要表示具有併發性的工作流，每個並行指令序列需要畫為獨立的有限狀態機。
交流性有限狀態機 (CEFSMs) 允許透過組合各個事件序列來建模更復雜的過程。
事件鏈 可以作為兩個 FSM 之間的交流通道。使用不同的事件鏈隔離兩個程序會使整個系統不確定，因為通訊通道是非確定性的。這可以透過確認事件來克服，如 13.1節所示。
2.4 作為自動機的合約
有限狀態機可以作為參與者之間的協議用，透過規範義務，許可權和禁止各方強加於另一方。金融協議等合同和服務合同可以完全數字化為FSM。
然而，在本文章中所提供的表示圖都不足以用作工作流程的條件，因為它們沒有定義流程中的通訊和編排。雖然可以在圖中結合這些因素，它會使有限狀態機成為指數級更復雜。
實際上，FSM 最多僅能代表一份不完整的合同。然而，這不一定是一個問題，因為這些缺口可以用預設規則填充 。該系統允許重新談判互動合約內容，無論是解決特定情況或一般情況。
另一件需要注意的事情是，在某過程中，不是每個操作都會構成一個約束因素。例如，在圖 1 中，接受檔案不會構成具有約束力的協議；這僅在文件簽署時發生。為了促進這種區分，我們可以將行動分類為資訊性或執行性 。
3. 備擇建模方法
交流性有限狀態機通常用於描述電信系統和其他實時系統，而不用於業務流程的描述。在對去中心化的組織之間的流程進行建模時，更常見的工作流注釋會帶來更多的挑戰。
3.1 佩特里網 Petri
佩特里網是一個系統的圖形表示，其中可見到多個獨立活動同時進行。Petri 和 FMS 之間的區別在於 Petri 能夠對多個併發活動進行建模。在 FSM中，始終都存在單個“當前”狀態，該狀態決定下一個可能發生的行動。在 Petri網中，可能存在幾種狀態，其中任何一種狀態都可能透過改變 Petri 網的狀態而發展。某些，甚至所有狀態可以並行發展，導致 Petri 網的一些獨立變化同時發生。
可用於描述業務流程的工作流網（WF-net），是 Petri 網的子集。WF網可以描述整個過程，而不僅僅是一個序列。
EFSM 使用綜合狀態來儲存資訊。此資訊必須按順序被隔離。若失敗將資料化成不可改變可被利用。在 Petri 網是不可能用通用資訊的。
反而，資訊必須流經工作流程。
透過 CEFSM 的方法，每個序列會被定義為單獨的過程。這使將訪問控制應用於一部分過程一項微不足道的任務。不過，當設計整個工作流程時，不能以相同的方式解決這個問題。
Petri 網有一個有趣的註釋。多數研究表明它們可用於表示業務工作流程。鑑於可以將 CEFSM 建模為 petri 網，使用 WF 網可能比使用單個 FSM 更合適。
由於 Petri 網和 FSM 之間的相似性，如本案文所述，切換到 WF 網並本質上不會改變我們的解決方案。
3.2 業務流程模型和標記法
業務流程模型和標記法 (BPMN) 是業務模型處理的行業標準，並且可能成為 LTO 的建模標記法候選之一。可是，BPMN 有多數尤其對於跨組織系統造成不便的限制。
通常與 BPMN 相關聯的業務過程執行語言 (BPEL)，是一種用於 Web 服務的非確定性圖靈完備語言。這使得它不適合區塊鏈的自動化。
建議的替代方案是將 BPMN 模型轉換為 Petri 網，Petri 網又轉換為智慧合約。
雖然（圖靈完備）智慧合約轉換步驟是多餘的，從 BPMN 到 Petri 網（或CEFSM）的轉換還收有意義的，以支援當前的行業標準。
3.3 組織的設計和工程方法 DEMO
“DEMO”是“組織的設計和工程方法”的縮寫。這種用於描述組織及其業務流程的方法基於“交流行為”。它使用四種模型來建立整體檢視，即構造模型（CM），過程模型（PM），行動模型（AM）和事實模型（FM）。
DEMO 會給每一個執行的動作易建立一個通用的工作流程，而不是將過程中的每一步單獨研究。此動作中有兩個角色，就是發起者和執行者。標準序列如下進行：發起者發出請求，執行者做出承諾。執行者然後執行操作並對結果做出宣告; 發起可以麼接受這個，然後完成交易，或者拒絕它 。
其他流程也可以被建模，例如執行者拒絕請求，發起者想要撤銷請求，執行者無法履行承諾等。當使用其他建模方法時，這些替代流程通常不會或僅部分地建模，可在實踐中，它們總是存在。
流程模型（PM）將這些事務組合在一起，以模擬完整的業務流程。這個模型和工作流程模型之間的區別在於，在這個模型中，每個人都儘可能並行工作，在需要的地方指定事務之間的依賴關係。這種設計選擇意味著與其他建模方法相比時，在 DEMO 模型中我們無法清楚地瞭解我們在流程中的位置。此外，互相排斥資訊（不要編輯準備簽名的檔案）並非身臨其境。相反，它需要具體被指定。
DEMO 可能是製作高階模型的好方法，從而產生可以進行微調的工作流程。這應該會產生更完整的合同，減少對派生的依賴。
4. 場景
工作流被定義為資料物件; 場景。它由以下元件組成：
• σx 作為某個操作,
• Σ 作為所有可能行動的集合 Σ = {σ1, ..., σn},
• δ 作為狀態轉移函式 δ : Q × Σ → Q,
• F 作為最終狀態的的集合 F ⊂ Q | F = ∅,
• ¯I 作為所有角色定義,
• A¯ 作為所有資產定義,
• D 作為嵌入資料物件的集合。
4.1 狀態
集合在 Q 中的狀態通常包含以下內容：
• 標題：給某個狀態設定的小標題,
• 帶有交易的操作為 {(−→qx, δ), ...},
• 描述：給狀態的描述,
• 給特定角色的地圖或指令。
每個狀態描述了在此狀態下可以執行的操作，包括狀態轉換。這允許不同操作可在不同的狀態下使用。
4.2 操作
Σ 由場景定義，即可在工作流中執行的所有可能操作。此類操作的示例包括填寫表單，檢視某個文件以及執行 HTTP 呼叫。操作型別與物件屬性是使用JSON 模型定義的。
每個操作都會定義來自 ¯I 套的哪些角色可以執行它而且可選附加的執行約束。這些約束使場景成為一個 擴充套件 FSM。
當執行一個操作時，會觸發狀態轉換。操作可被分類為需要執行人為干擾的手動操作，以及可以由系統自動執行的系統操作。
每個操作也可以下令，使用回覆的資料去更新角色與資產。
4.3 角色
¯I 套定義可以在流程中發揮作用的所有角色。每個角色都使用 JSON 模型被定為一個物件。與程序相關的角色屬性必須定義。
某個場景中的角色只是一個靜態定義，可以在程序中例項化。
4.4 資產
A¯ 定義流程中可用的所有資產。資產是可變資料物件。與流程相關的屬性必須定義。
請注意，場景僅定義資產的結構。資產只能在流程中例項化。
5. 資料物件
除了情景場景，還可以定義其他型別的資料物件。所有資料物件（包括場景）都使用 JSON 模型作為型別定義。常見示例包括表單，文件和模板。資料物件可以嵌入到程序中，也可以獨立連結和儲存。
連結物件由其 JSON 表示的 SHA256 雜湊標識。為了確保 JSON 編碼資料始終產生相同的結果，連結時用到了確定性的 JSON 編碼方法。
5.1 不變性
資料物件是不可變的，當資料物件被修改時，它產生一個新的資料物件。如果此資料物件作為資產嵌入到流程中，則舊物件將被修改後的物件替換。
值得注意的是，如果某一個資料物件在多數程序中用到，其更改將不會自動傳播到其他程序。
實現不了不變性可能導致可利用的情況。在圖 1，我們展示了談判和簽署檔案的過程。很明顯，在簽名過程文件中不應該被修改。
5.2 表格
表格定義使用 JSON 模型來定義填寫表格時應該產生的資料結構。可以使用附加的 UI 模式來指定如何呈現和顯示相應的欄位。
現實已有類似的措施 。我們的目標是與這些專案合作，形成統一的標準。
5.3 檔案
數字工作流程可以大量消除紙質文件的需求。但是，法律合規性，向下相容性和公司政策等可能仍需要使用文件。透過將模板定義為互動合約的一部分，可以使用流程收集的資料生成自然語言文件。
我們建議使用支援欄位和條件部分的開放文件格式來建立模板。
5.4 自定義型別
任何定義物件的 JSON 模型可以當成資料物件引用。自定義型別確實存在工作流無法正常執行的風險，因為其他方可能透過不支援該型別的節點參與。具有未知型別的資料將“按原樣”儲存，並且在該過程的上下文之外不可用。
6.參與方
參與者定義了互動合約中的個人，團隊或組織。參與者始終包含以下資訊：
• 身份標識,
• 節點統一資源標誌符 URI,
• 自定義資訊,
• 簽署金鑰,
• 加密金鑰。
參與方與角色不同。角色是抽象的，例如“學生”; 但是，參與方可能是“Bruce Willis”或“Acme Corp”。
簽署金鑰是具有與身份相關聯的一個或多個公鑰的對映。“使用者”金鑰是屬於參與方的，所以只能由他/她用於簽署任何操作。“系統”金鑰由參與方使用的節點擁有，用於簽署自動操作，除此之外還可以在流程中定義其他金鑰型別。
公鑰可用於加密資料，資料只有目的參與者能夠解密。
6.1 邀請參與方
若希望新增新的參與方到某個流程的話，此場景該定義新增新參與者的操作。如果公鑰在流程內是眾所皆知的新參與者可以直接被新增。
當公鑰是未知的，新參與者需要被邀請 (figure 4)。這可以透過任何足夠安全的方案來完成，包括電子郵件。邀請系統會生成一次性金鑰並將其傳送到受邀方。被邀請方必須透過其自己的安全“使用者”和“系統”金鑰替換它。
在新參與方完全參與流程之前，可能需要進行其他身份驗證。這可能是透過 SMS 驗證到聯合身份驗證甚至公證批准。
6.2 更新參與方
除了身份識別符號外，所有參與者可以自由修改自己的資訊。這也允許某方切換到另一個節點。如果本過程不允許使用者切換節點，則由參與者的節點拒絕該更改。
移除某個參與方可以透過清除簽署金鑰，加密金鑰和節點 URI 來完成。
只有在場景中定義了此類操作並在當前狀態下允許時，才能更新其他參與方。
7. 過程
如果一個場景是工作流的無狀態定義，則該過程是有狀態例項化，包括以下內容：
• θx 作為回覆，則 f : qx 7→ θx
• Θ 作為所有回覆的有序的集合 Θ = {θ0, ...θn}
• qt 作為前的狀態
• I 作為線上的角色
• A 被建立的資產的集合。
7.1 操作
執行操作總是會產生響應。此響應必須由執行者簽署並作為新事件提交。節點基於當前狀態和剛執行的操作獨立地確定新狀態。
該場景被定義為確定性 FSM。然而，這僅涉及狀態轉換和投影。在諸如以太坊和 Hyperledger 之類的系統上，所有邏輯必須是確定性的，因為它由所有節點執行，並且需要在所有系統上產生相同的結果。
使用 LTO，只有單個節點或單個角色執行操作，這意味著操作不需要是確定性的。對於從外部源獲取資料等操作，不需要預言機。
7.2 手動操作
在 LTO 平臺上構建的應用程式必須告知人類參與者他們在當前狀態下可能執行的操作。參與人類在將其提交給他的節點之前將簽署他自己的響應事件，該節點將其分發給所有參與方。
7.3 系統操作
系統操作不需要人為干擾，因為節點會自動執行。因此，由節點簽署響應操作，而不是人類使用者。
這些操作始終由單個系統執行，而不必是確定性的。該流程的其他參與方驗證響應，並可在需要時拒絕。由於系統操作中不涉及人為干擾，操作由系統本身而不是參與者簽署。
系統操作也可以安排稍後執行的。這可以在場景中指定。它允許狀態超時或以預定的頻率輪詢外部資源。
系統操作會自動執行，如果使用不當可能會產生錯誤或失敗。對於這些操作，必須定義兩個狀態轉換。一個用於成功執行的情況，一個用於失敗的情況。
7.4 子程序
基於 FSM 的程序只能同時處於一種狀態。子流程允許互動合約保持多個狀態，並且可以並行執行不同的過程。這些流程共享一個事件鏈，但每個流程的資料仍然是孤立的。
為了促進子流程，互動合約可能包含可以從主場景例項化的子場景。
7.5 投影
除 FSM 狀態外，該過程還包含其他有狀態資料，例如資產和參與者。每個響應的有效負載可用於更新此資料。在場景中定義了有效負載該如何更新資料的規則。更新投影是確定性的，因此，對場景應用一組給定的響應將始終產生相同的投影。
投影可用於設定操作的引數以及為各個操作定義的約束。
7.6 資料運算子
在場景中可能會使用資料運算子來指定投影如何影響過程。這些運算子乃確定性函式，沒有副作用。它們可用於算術或邏輯運算。這些操作的結果可以儲存在投影中，並且可以用作例如狀態轉換的基礎。
7.7 被動測試
包含僅由系統操作組成的迴圈的場景可能會導致無限迴圈，從而導致大量交易。在驗證場景時，如果某個場景有這樣的構造，我們要拒絕它。
確定某個程式是否可以永久執行被稱為停機問題。停機問題在圖靈機上是不可判定問題；但是，停機問題在 FSM 是可以解決的。由於 FSM 具有的轉換路徑數量有限，它們的迴圈可以有效的被檢測到。
由於不可行的路徑的存在，EFSM 模型的被動測試變得複雜，並且是一個開放的研究問題。為了簡單起見，我們忽略所有條件而可以假設透過 FSM的任何路徑都可行。我們承認這可能會導致誤報。
8. 自適應工作流程
場景將模擬流程最常見的案例。提前預見所有情況是不可能，並且無法對每個可能的邊緣情況進行建模。採用程式碼即法律 (code-is-law) 方法會使系統僵化。相反，互動合約支援三種解決此類問題的方法。
• 批註
• 偏離
• 場景更新
8.1 批註
評論用於與求他參與者交流互動。例如，它們可用於解決衝突或在流程之外進行討論。使用評論而不是鏈下溝通方法可確保會話記錄在區塊鏈上。它還讓我們可以回溯檢查在程式中何時發生某些對話。
評論不僅限於文字資訊。也可以使用影象或文件來協助交流。批註不是過程的一部分，這意味著評論不會觸發狀態轉換。因此，鏈上可以討論進行關於在過程中未預定的主題。
8.2 偏離
任何一方都可以透過定義部分場景來建議偏離主流。此子流必須從現有場景的其中一個狀態開始，並以該場景的某個狀態結束。偏差流是一次性的，因為當流程返回到現有狀態時，它們不再可用。
各方需要對偏離達成一致。請注意，偏離可能會導致只能透過手動解決方法來解決的分支。
偏離可用於解決爭議。任何一方都可以建議它對先前事件的正確性提出異議，並對如何糾正這一各事件提出解決方案。
使用偏離的典型情況是進行支付安排。各組織當然都不希望在協議中顯出該選項。預定義的子流程允許授予此類安排，同時保密。
8.3 場景更新
時常，正在執行的程序的場景會需要更改；例如，當協議受到更新或新增新法律時。
一方可以透過偏離流為給某過程提供新場景。此流程將狀態移出過時的場景並進入新場景。
因為更新場景是事件序列的一部分，它不會破壞解決方案的確定性。
9. 事件鏈
為了確定 FSM 和投影的狀態，我們需要按給定的順序處理響應集。插入或刪除事件，更改事件的順序或修改有效負載可能會導致完全不同的狀態。
在中心化方案中，控制方負責資料完整性。各方都依賴這一方，因為它代表了唯一的事實來源。在去中心化的系統中，權力和責任由各方共享。
為了簡化此過程，事件鏈就像一個特殊的私鏈。每個響應都包含在一個事件中，可以將其視為具有單個操作的區塊。這些事件形成一條雜湊鏈，由各方共享。共識演算法確保各方就事件順序達成一致。
9.1 非許可私有鏈
在一個場景中，人員和組織被定義為參與者。參與者可以自由選擇其想要哪個節點參與本過程。
節點參與網路無需任何許可權。啟動任何程式甚至邀請其他參與者也無需任何許可權。資料僅與程序的參與者之間共享。因此，事件鏈可以描述為非許可私有區塊鏈。
9.2 加密簽名
為確保沒有人可以假造或偽造他人的事件，每個事件在使用非對稱加密提交之前都會簽名。簽名事件也可作為收據，允許其他方證明該操作已由簽名身份執行。
該平臺使用 ED25519簽名。這些橢圓曲線數字簽名被 NIST與ENISA等機構廣泛使用，受到充分支援和認可，並被認為是安全的。橢圓曲線加密允許更快速的單簽名驗證和不失安全性的簽名。它而且還減少了金鑰和簽名資料的大小。請注意，此方法本身並不提供完全的安全性，因為各方仍然可以假造或偽造自己的事件。換句話說，加密簽名無法證明某事件有沒有發生。
9.3 雜湊鏈
每個事件都可以使用 SHA-2 256bit 雜湊進行唯一標識。該行業標準演算法可確保快速的可計算與抵抗原像和第二原像攻擊以及碰撞。這是 NIST 推薦的演算法。
將先前事件的雜湊嵌入下一事件的雜湊中會建立雜湊鏈，該雜湊鏈記錄事件的時間順序。當與加密簽名結合使用時，雜湊鏈提供足夠的證據證明特定事件序列導致當前狀態 。
10。 分配
與其要求各方從中心伺服器或彼此提取資訊，每一方負責將事件推送到所有其他參與方的系統。
系統需要始終可用，以便事件不會丟失。解耦和訊息佇列可以減少臨時不可用的問題。在典型情況下，所有各方將連線到他們信任的節點，該節點將接收和處理它們的事件。該節點也是較大系統的一部分。
組織和政府可以自己執行節點。使用者可以連線到其組織的節點或他們選擇的公共可用節點。
CAP 定理意味著在存在網路分割槽的情況下，必須在一致性和可用性之間進行選擇 。透過使用解耦，我們犧牲了一致性，但是實現了更好的可用性。不線上或無法訪問的節點不會中斷其他參與者的程序，並且會在再次可用時同步。
10.1 私鏈
事件鏈是一個私有鏈，僅與參與者選擇的節點之間共享。節點不會意識到他們未參與的私鏈。
節點同時儲存和促進許多事件鏈。事件鏈是完全隔離的，與側鏈不同。鏈不會直接相互影響。鑑於每個事件鏈的活動相當低，這允許水平縮放。
10.2 創始區塊
任何人都可以隨意建立一個新的事件鏈。此鏈的創始區塊包含建立程序的使用者的標識，後續塊將包含場景。作為場景的一部分，其他參與者將被邀請到此私鏈。
11。 共識機制
LTO 是一個分散式系統，所有方都可以透過自己的節點參與。節點將所有事件分發給其對等體，然後這處理這些事件。這意味著過程中存在一個節點之間的過程狀態不同的短暫時刻。最終的一致性保證最終，鑑於沒有提交新事件，所有節點上的程序狀態將是相同的。
但是，有時候，在達到一致性之前會有新事件提交。此時，兩個或更多節點可能會將不同事件附加到事件鏈。在拜占庭故障期間，所有節點都認為他們的資訊是正確的; 但是，整個系統處於不一致狀態。在這種狀態下，節點不再接受彼此的新事件; 他們需要能夠達成共識，而不是停止。
分散式應用程式使用不同型別的共識演算法。通常，這是拜占庭容錯的情況。早期的拜占庭容錯（BFT）方法不可地擴充套件。隨著新的可擴充套件的共識演算法的發明例如 工作量證明 (PoW) ，權益證明 (PoS) 與權威證明 (PoA)，使得具有大量參與者的分散式網路可被建立；這也稱為分散式賬簿技術。
雖然這些共識方法比傳統的 BFT 方法更好地擴充套件，它們還是需要相對大量的參與者（PoW 多於 1000）才安全 。傳統的 BFT 方法依賴於不超過 ⌊n−13⌋參與者是不良行為者的事實 。這意味著如果有少於四個參與者，一個不良行為者可以影響系統，並且至少需要七個參與者保護他們免受兩個不良行為者的影響。
事件鏈是一條私有鏈，參與者相對較少，通常少於 7 個，這意味著這些演算法非常容易受到攻擊。所以各個節點會認為它們的狀態正確，除非另有證明，而不是信任多數投票。
11.1 衝突比率
事件鏈依賴於樂觀性的併發控制; 大量的衝突會對共識演算法造成壓力，演算法可能會相對較慢，因為它可能必須等待生成新的區塊。
我們定義分散式事件鏈如下：
• 由 N 作為對事件鏈有貢獻的實體。{n1, n2, n3, . . . }。
• 由 Cn 作為事件鏈，由屬於 n 實體的事件組成的序列 (e1, e2, e3, . . .)，還由 C 作為事件鏈的所有副本的集合 {Cn|n ∈ N}。
• 由衝突或分支定義為 ∃ i, j ∈ N : i ̸= j, Ci0 = Cj0, Ci ̸⊂ Cj , Cj ̸⊂ Ci.
意外衝突只有在兩方各自，在從其它鏈受到更新之前，在自己的鏈上新增一個區塊的情況下才會發生。
若稱某人將更新傳播到鏈的比率為 P(x)。此比率取決於在給定的時間範圍內被新增到鏈中的區塊數量，將該塊傳播到網路的其餘部分所花費的時間，以及在該時間範圍內對鏈做出貢獻的實體的數量。假設每個人都對網路做出同等貢獻的話，可以推匯出以下函式 (1):
以：
f = 交易總數量 / 時間範圍
n = 活躍參與者總數
t = 將塊傳播到網路的其餘部分所需的時間
這比率可以用來計算髮生衝突的概率。透過從 1 減去不存在衝突的機會來匯出該概率。若沒有衝突的話，意味著當時沒有人為鏈條做出貢獻，其機會是使用以下函式計算的 (2),
LTO 每條鏈上的活躍參與者極少；這減少了衝突的可能性。如果有五個以上活躍參與者，則該數字就此不重要。超過 10 名參與者，基於網路延遲和交易次數，衝突的可能基本上變得線性。
如果使用具有解耦訊息佇列的單獨共享事件鏈，則交易頻率將非常低。這使衝突的可能性邊緣化。
11.2 分支驗證
一個節點只能在某條鏈的最後一個事件以及之前的時間證明另一方知道其鏈的存在。任何方都可以在最後一次提交後進行分支。如果一方試圖從最後一個事件之前的一個點開始分支鏈，那麼所有（其他）方都會自動丟棄該分支，並記錄該事件。
在接受來自衝突分支的新事件之前，它們將像任何收到的事件一樣進行驗證。該事件必須由其中一個參與者正確簽名，並且必須正確錨定。如果事件的時間戳與錨點的時間戳相差超過 300 秒，則可以拒絕該事件。
11.3 錨定順序
節點必須在 global 區塊鏈上錨定事件。區塊的順序是透過挖掘設定的，挖掘區塊內的事務順序也是固定的。
這讓我們可以使用 global 區塊鏈上的錨點順序來確定事件的順序。如果發生衝突，必須接受首先錨定的塊。私鏈的共識是透過公鏈的共識達成的。在公鏈上，共識是透過大量參與者之間的匿名協作使用 PoS 的變體的達成。
11.4 優先
某些情況下可能需要給出一個操作或角色優先權，所以即使它最後被錨定，它也是先排序的。參與者可以在場景中自由設定此類優先順序。
某些事件型別（例如評論）自然具有較低的優先順序。
使用優先順序會啟用搶先交易攻擊，某人可以建立新的分支來回應一個事件，然後廢止此事件。優先順序當只有在沒有問題的情況下才應使用。
11.5 未錨定事件
當收到尚未錨定的區塊時，我們可決定無論如何都接受該塊。當然，是在接受它就不會產生衝突的情況下。若某區塊的錨固僅是被延遲，接受該塊可避免給正在執行的過程帶來多餘的延誤。另一方面，如果永遠不錨定該塊，則不會出現實際問題。如果所有人都接受該塊，則該過程可以正常繼續，並且該塊可以稍後錨定。
11.6 合併分支
當出現分叉時，大多數區塊鏈應用會選擇一條鏈繼續並忽略其他分支上發生的一切。使用像比特幣這樣的區塊鏈，所有交易最終都會包含在每個分支的挖掘區塊中。
在事件鏈上，事件本身構建了雜湊鏈。挑選其中一個分叉會導致丟失有關已執行操作的資訊。相反，當一個節點意識到另一個分叉優先於其自己的分叉時，它必須將它本地擁有的事件基於另一條鏈。這類似於使用 git 時的復位基底（rebase）操作。
11.7 分叉
即使有擔保達成共識的方式，參與方也可能決定忽略其他鏈並保持分叉。對於大多數區塊鏈應用來說，例如以太坊，沒有理由去幹擾分叉，因為價值僅來自參與主鏈。互動合約是一種用於數字化和部分自動化現有流程的工具。即使區塊鏈允許分叉的存在，這些過程通常不會。在分叉的情況下，各方可以啟動一個輔助過程以嘗試手動解決衝突。
12. 隱私
LTO 專為多方之間的執行流程而構建。除了這些參與方之外，沒有人需要了解這個過程甚至是合作。
公有區塊鏈容納匿名帳戶; 但是，這些帳戶充當假名作用。任何交易都可能揭示帳戶的身份，從而暴露完整的交易歷史記錄。智慧合約要求資料是公開的，因為它需要可用於每個節點。在聯盟鏈上，參與者彼此瞭解。
臨時的私有鏈允許隨機分類的參與者進行協作，而無需批准或公開資訊。完成該過程後，可以完全清除這些鏈。
12.1 鏈結資料
每一方透過自己的節點或其信任的節點進行連線。每個節點都有一個私有儲存服務，使用者可以在其中儲存資料。使用者可以完全控制儲存在此的資料，類似於儲存在 DropBox 等服務上的資料。他們可以隨時刪除自己的個人資料。在未經有效協議和使用者明確批准的情況下，資料不會被共享或處理。
當某個操作導致鏈結資料時，該資料不會直接與其他方共享; 只有一個雜湊值會被新增到鏈中。LTO 透過將雜湊與時間戳和一些隨機資料一起放入信封中來防止雜湊被用於驗證接收資料之外的任何其他內容。為了形成信封而建立的雜湊將永遠不會在區塊鏈上出現多次。
當某組織表明它想要執行需要鏈結資料的操作時，該組織的節點將自動發出請求。資料所有者的節點檢查指定的操作是否有效，並且可能由當前狀態的角色執行。
12.2 GDPR 通用資料保護條例
隨著新的 GDPR 在歐洲的到來(通用資料保護條例) ，許多關於區塊鏈應用程式不符合 GDPR 的事實已經引發了爭論 [63]。造成這種情況的兩個主要原因如下：
• 區塊鏈的不變性與修改和刪除資料的權利相沖突，
• 沒有專用資料控制方的事實，因為區塊鏈是一個分散式環境。
鏈結資料意味著參與方選擇的節點將充當該使用者的資料控制器。所有其他方始終充當資料處理器。資料請求自動格式化以建立適當的資料處理協議，其中包括處理資料所需的目的和時間。
臨時區塊鏈可以在需要時清除整個鏈。
簡而言之，LegalThings 的隱私功能使得解決方案無需額外的努力符合 GDPR政策。
12.3 零知識證明
某個場景可能要求一方向另一方證明其知道某個特定值。零知識證明（zkproof）是一種方法，除了證明一方知道該值之外，不傳達任何其他資訊。
LTO 透過互動式證明系統支援 zk 證明。證明方與驗證方兩方互動目的為，證明方對驗證方證實其誠實度（完整性）還有讓驗證方揭露證明方不誠實的證據（健全性）。
互動合約的 zk 證明始終是兩方之間的操作。合約中不需要非互動式的 zk證明，例如 zkSNARKS，它仍然被認為是實驗性的。
13 常用模式
13.1 鏈互動
某些流程可能必須與其他流程互動才能繼續執行；例如，某各程序需要來自另一個程序的允許才能繼續執行檢索衝突解決過程的結果。從另一個程序請求資料是透過遵循 5中所示的模式完成的。
13.2 顯式同步
在某些情況下，如果事件傳播得太晚，則會特別麻煩。當這種情況發生時，我們可以在場景中構建顯式同步。這需要所有各方在繼續該過程之前確認當前狀態。這是 FSM 中的一種模式，旨在防止各方在此事件之前分叉事件鏈。如果發生爭議或衝突，可以使用此類確認方式來決定應該用於繼續該過程的分支。
這種顯式同步僅在所有方都確認當前狀態時才有效。如果某方缺乏繼續的動力或有分叉流程的動力，則需要另一種解決方案。在這種情況下，想要繼續該過程的一方向所有其他方宣佈其意圖。如果收到此公告的任何一方注意到所宣佈的操作在自己的鏈上無效，他們可以傳播此資訊。這意味著鏈已經分叉並且必須應用常規衝突解決方案。為了防止此公告影響網路延遲會在假定沒有人拒絕宣佈的事件之前，等待一定時間。
