概要

• Flows 使同意更新賬本的流程變得自動化
• 節點之間的溝通只能夠在這些 Flows 的上下文中發生，並且是點對點的（point-to-point）
• 內建的 flows 提供了常用的一些任務（tasks）

動機 Motivation

Corda 網路使用點對點的訊息傳輸而不是全域性廣播。也就是說協調一個關於賬本的更新需要網路上的參與者明確的指定需要傳送什麼資訊，傳送給誰，按照什麼順序傳送。

下邊的圖片動態地展示了對於一個簡單在 Alice 和 Bob 之間的同意賬本更新的流程。

The flow framework

Corda 使用了 flows 來使上邊的步驟變得自動化。一個 flow 是一系列有順序的步驟來告訴一個節點應該如何實現一個指定的賬本更新，比如發行一個資產或者結算一筆交易。

下邊是一個上邊圖片所描述的簡單賬本更新所涉及到的順序的流程：

執行 flows

一旦一個業務流程被封裝在了一個 flow 中並且在節點中作為 CorDapp 的一部分被安裝好之後，節點的 owner 可以在任何時間通過使用一個 RPC call 來告訴節點開始這個業務流程。Flow 將所有的網路，I/O 和併發問題都抽象了出來，這個節點 owner 就不需要關注這些了

節點上所有的動作都是發生在這些 flows 的上下文上的。與 contract 不同，flows 不是在 sandbox 裡執行的，也就是說節點可以在執行一個 flow 的過程中來進行一些動作比如 networking，I/O 或者隨機地使用一些資源。

Inter-node communication

節點間是通過在不同的 flows間傳遞訊息來進行溝通的。每個節點有0個或者多個註冊的 flow classes 來回復另外個一個單獨的 flow 的訊息。

假設 Alice 是網路中的一個節點，並且她希望同 Bob（網路中的另一個節點） 一起同意一次賬本的更新。為了跟 Bob 進行溝通， Alice 必須：

• 開始一個 Bob 已經註冊過的 flow（Bob 會回覆這個 flow 發來的訊息）
• Alice 在這個 flow 的上下文中給 Bob 傳送一個訊息
• Bob 會啟動它註冊的這個 conterparty flow

連線已經建立起來了，Alice 和 Bob 就可以來回地溝通關於一個更新賬本的改動並且最終達成一致。

Subflows

作為子流程被啟動的 Flow 被稱為 subflow。父 flow 需要等待所有的 subflow 完成後才會繼續執行。

The flow library

Corda 對於一些常規的任務都提供了一套程式碼庫，所以開發者就不需要自己去定義這些常見流程背後的邏輯了，比如：

• 公正（notarising）和記錄一個 transaction
• 從相關節點蒐集簽名
• 確認一個交易鏈（transactions chain）

併發 concurrency

Flow framework 允許節點可以同時執行多個 flows。這些 flows 可能由於節點的重啟甚至升級會持續幾天。

當然任何時候 flows 進入了一個阻塞狀態的時候（比如他們在等待 I/O 或者是網路的呼叫），這就需要將 flows 進行序列化（serialization）然後儲存在磁碟中。出現這種情況的時候，節點不會等待這個阻塞狀態的 flow變成非阻塞的狀態，而會立即執行其他的 flow，只會在稍後返回到原來這個阻塞的flow。