尽管采用EFSM可以部分解决状态爆炸问题，但我们仍然需要对其进行调整以确保高效的硬件实现。 我们需要解决两个问题：
-
状态可伸缩性：标准EFSM对于系统中的每个流程都需要一个单独的过渡表（即EFSM的说明）
-
流并行性：EFSM状态定义不包括流状态的概念，这是我们需要利用流级并行性的概念。
FlowBlaze的机器模型（参见下图）扩展了RMT 描述的MATs管道模型。与RMT一样，FlowBlaze数据包头（包括数据包元数据）通过管道的元素进行处理以定义转发动作，每个元素可以是无状态的或有状态的。无状态元素是MAT，类似于RMT1中使用的元素，有状态元素实现EFSM定义，管道可以结合无状态元素和有状态元素。
有状态元素的体系结构与MAT有两个显着区别：（1）这种元素在通常的匹配部分之前具有流上下文表（2）该元素将动作分为（状态）更新功能和数据包动作。
更详细地，如上图所示（标记为“有状态元素”的框），数据包处理涉及以下顺序步骤：
-
流上下文表：当数据包头进入元素时，它与相应的流上下文相关联。
-
EFSM表：数据包的标头和元数据以及提取的流上下文将传递到EFSM表。该表是传统MAT的扩展，除了支持在打包程序标头字段上进行匹配外，还可以在状态标签s上进行匹配并评估启用功能。
-
更新功能：标头和元数据，更新指令以及状态标签的新值将传递到更新功能块。
-
行动：像在MAT中一样，此块将操作应用于数据包头。与MAT不同的是，流上下文寄存器的值以及全局寄存器的值也可以被使用。
FlowBlaze在NIC中直接部署，其编程类似于对P4设备进行编程。在配置时，程序员必须定义解析器，MAT和EFSM转换表的匹配字段以及操作，这些操作现在还包括状态更新功能，改变这些组件需要对FPGA设计进行新的综合。
幸运的是，这些是函数更改频率较低的部分。在运行时，程序员通过配置有状态元素的流定义，选择已解析的标头字段的子集并将所需的条目写入MAT和EFSM转换表中，来定义其网络功能的逻辑，这类似于P4和OpenFlow设备的运行时编程。实际上，我们扩展了OpenFlow协议，以便从基于python的RYU OpenFlow控制器中写入此类条目。
值得强调的一件事是，程序员可以快速地实验和更新其功能逻辑，因为对网络功能逻辑进行编程就像将表写入条目一样快，与其他的解决方案不一样，这需要更新一个的综合的FPGA设计。
FlowBlaze始终会具有一定的硬盘限制，例如DoS攻击可能会利用这些限制。为了解决这个问题，FlowBlaze提供了一些原语，程序员可以使用它们来明确处理“流上下文表”已满的情况。例如，实现功能之前可以实现带有SYN泛洪检测功能的元素，以便可以丢弃执行SYN攻击的主机的流量，从而避免在Flow中创建大量后续元素的上下文表条目。
