翻译笔记:视频讲解 Corda 核心概念 – Flows

翻译整理自 Corda 官方核心概念 Flows 介绍视频,视频如下

常见的 DLT 中的 Flows

  • 大多数分布式账本平台会使用消息广播(message broadcasting)的形式和 gossip network 来分享数据
  • 消息是简单的:不需要指定消息发给谁,所有人都会收到,接收到消息的人只需要忽略重复收到的消息即可
  • 这样做的缺点是:节点不能控制谁会收到他们的数据

Corda 中的 Flows

  • 使用基于点对点消息(point-to-point messaging)来彼此进行沟通
  • 必须指定一个或者多个消息接收者
  • Flow framework 用来定义什么时间(when)要沟通什么(what)和谁沟通(who)
  • 当 transaction 被提交前,会需要在多方之间不断的进行沟通,这就需要 flow 来管理发送消息,签名,确认即其他方面的流程
  • Corda network 中的各方可能会有无数的合作方和成百上千并发的 flows

Flows 能够长时间的存在

  • 完全自我运行的flow 能够在很短的时间里完成,当然也会有一些 flow 会持续几个小时或几天,或者为了等待一个不在的 employee 的签名,会等待更长的时间
  • 正在进行中的 flow 要满足在节点重启之后还是有效的,会被继续执行
  • Flow 一般应该是大多数的时间都是 sleep 的状态(等待其他方的签名确认),只有在很短的一段时间里才是 active 的,它会被 IO 或者从网络中接收到的消息所唤醒
  • 开发者通常会用异步的方式来处理 flow,这样可以避免某一步会将整个流程阻断。但是异步的代码通常都是很糟糕的(很多的回调方法),很难阅读。

Flows 是具有时间点检查(check-pointed)功能的状态机(state machines)

  • 我们可以把 Flow 看成是在不同的轻量级的进程中运行的状态机(State Machines),这种轻量级的进程被叫做 fibres
  • 每个 flow 都会被分配一个 状态机 manager 来跟踪 flow 当前的状态
  • 当一个 flow 在等着其他方的消息的时候,它会被挂起并序列化来进行永久性的存储(这个时候这个 flow 就可看为是某个状态点的数据)
  • 如果一个节点失败或者重启了,那上一个状态点的 flow 数据会从硬盘中(假设上一步的持久化数据被存在了硬盘上)被反序列化,这样这个 flow 就可以接着之前结束的时间点继续执行
  • 整个流程是不会被 block 住的,在等待其他节点的回复的时候,flow 会被挂起,序列化并永久存储起来,等收到恢复的信号之后,可以反序列化 flow 并继续执行
  • 当 flow 第一次启动的时候,后台的 code 会将该 flow 转换成一个异步的状态机
  • Corda 使用 Quasar 来实现上边所讲的功能
  • Flow 中传递的是一个 payload 的数据结构,payload 中包含 transaction 和 签名

子 flows 和 flow 库

  • 因为一些 flow 会被很多人使用,那 flow 就可以被打包并作为 sub flow 被重复调用。这就跟预先定义好一个方法,这样大家都可以调用是类似的道理。
  • Flow 库被提供来是开发者重用常见的 sub flows 比如量子级资产交换,向多个相关方广播数据,发送现金及同意一个多方的交易
  • Sub flow 也节省了程序员的开发时间

Flow framework 还能做什么

  • 跟节点间的沟通
  • 通过一种跟踪机制来反映进度
  • 处理错误和将错误广播
  • 消息路由
  • 消息发送并确保被其他方收到
  • 序列化/反序列化
  • 捕获类型错误

Flows API

  • 在网络上给其他方发送和接收数据
  • 创建 transaction
  • 确认和签名 transaction
  • 可以嵌入 sub-flows
  • 向观察者(observers)表示当前进度状态
  • 跟网络上的节点互动
  • 如果一个 flow 向其他节点发送数据的话,他们应该是成对出现的:通常被称为 Initiator 和 Responder flows

发表评论

电子邮件地址不会被公开。 必填项已用*标注