对于共享的不可变键值和时间序列数据库
今天，我们很自豪地发布最新版本的MultiChain，它实现了一组至关重要的新功能，称为“流”。 流为区块链用例提供了自然的抽象，用例侧重于通用数据检索，时间戳和归档，而不是参与者之间的资产转移。 流可用于在链上实现三种不同类型的数据库：
- NoSQL风格的键值数据库或文档存储。
- 时间序列数据库，其重点是条目的排序。
- 身份驱动的数据库，其中条目根据其作者进行分类。
这些可以被视为共享数据库的“什么”，“何时”和“谁”。
流基础知识
可以在MultiChain区块链中创建任意数量的流，并且每个流都充当独立的仅追加项目集合。 流中的每个项目都具有以下特征：
- 一个或多个 出版商 已经对该项目进行数字签名的人。
- 可选 键 为以后的检索提供方便。
- 有 data，范围从一小段文字到数兆字节的原始二进制文件。
- A 时间戳，从确认项目的块的标题中获取。
在幕后，流中的每个项目都由区块链交易表示，但是开发人员可以在不了解此底层机制的情况下读取和写入流。 （更多高级用户可以使用 原始交易 在单个原子事务中写入多个流，发行或转让资产和/或分配权限。）
流以多种方式与MultiChain的权限系统集成。 首先，只有拥有权限的人才能创建流，就像只能由某些地址发布资产一样。 创建流时，它是打开的还是关闭的。 有权发送区块链交易的任何人都可以编写开放式流，而封闭式流则限于可更改的允许地址列表。 在后一种情况下，每个流都有一个或多个管理员，他们可以随时间更改这些写权限。
每个区块链都有一个可选的“根”流，在其定义 参数 并从创建链的那一刻起就存在。 这使得区块链可以立即用于存储和检索数据，而无需等待流被明确创建。
就像我一样 之前讨论过在许多区块链用例中，机密性是最大的挑战。 这是因为区块链中的每个节点都可以看到整个链内容的完整副本。 流提供了一种自然的方式来支持区块链上的加密数据，如下所示：
- 参与者使用一个流来为任何公共密钥密码方案分配其公共密钥。
- 第二个流用于发布数据，其中每条数据都使用具有唯一密钥的对称密码术进行加密。
- 第三流提供数据访问。 对于应该看到一条数据的每个参与者，将创建一个流条目，其中包含该数据的秘密密钥，并使用该参与者的公共密钥进行了加密。
这提供了一种在区块链上存档数据的有效方法，同时使其仅对某些参与者可见。
从流中检索
流的核心价值在于索引和检索。 每个节点都可以选择要订阅的流，而区块链保证所有订阅特定流的节点将在其中看到相同的项。 （还可以将节点配置为自动订阅创建的每个新流。）
如果节点订阅了流，则可以通过多种方式从该流中检索信息：
- 按顺序从流中检索项目。
- 使用特定键检索项目。
- 检索由特定发布者签名的项目。
- 列出流中使用的键，并列出每个键的项目计数。
- 在信息流中列出发布者，并列出项目数。
如开头所述，这些检索方法允许将流用于 键值数据库, 时间序列数据库 和身份驱动的数据库。 所有检索API提供 开始 和 数 参数，从而可以有效地检索长列表的小节（例如SQL中的LIMIT子句）。 的负值 开始 允许检索最新的项目。
流可以包含具有相同密钥的多个项目，这自然解决了区块链不变性与更新数据库之间的紧张关系。 应该在应用程序中为每个有效的数据库“条目”分配一个唯一的键，并且对该条目的每次更新都由带有其键的新流项目表示。 然后，MultiChain的流检索API可用于：（a）检索给定条目的第一个或最后一个版本，（b）检索条目的完整版本历史，（c）检索有关多个条目的信息，包括第一个和最后一个每个版本。
请注意，由于区块链的点对点架构，流中的项目可能以不同的顺序到达不同的节点，并且MultiChain允许在对项目进行``确认''之前先对其进行检索。 结果，所有检索API都提供了全局（默认）或局部排序之间的选择。 全局排序可确保一旦链条达成共识，所有节点都会从相同的API调用接收相同的响应。 本地排序保证了对于任何特定节点，流项目的排序在API调用之间都不会改变。 每个应用程序都可以根据自己的需求做出适当的选择。
流和MultiChain路线图
随着流的发布，我们已经完成了MultiChain 1.0的最后一项主要工作，并且现在正稳步进入beta版。 我们希望在接下来的几个月中扩展我们的内部测试套件（已经相当大了！），完成Windows和Mac的端口，添加一些更有用的API，更新 浏览器 对于流，调整共识机制的各个方面，发布我们的Web演示，并通常整理代码和帮助消息。 最重要的是，一旦发现任何错误，我们将继续进行修复，以确保我们的错误不会中断您的工作。
从长远来看，多链路线图中的流适合哪些方面？ 退一步，MultiChain现在提供了三个方面的高级功能：
- 权限 控制谁可以连接，交易，创建资产/流，挖掘/验证和管理。
- 办公室文员： 包括发行，再发行，转让，原子交换，代管和销毁。
- 流 使用API来创建流，编写，订阅，索引和检索。
在MultiChain 1.0（和高级版本）发布之后，此列表中的下一步是什么？ 如果你看 API命令 用于创建流，您会注意到一个明显多余的参数，其固定值为 stream。 此参数将允许MultiChain在将来支持其他类型的高级实体。
该参数可能的未来值包括 evm （为 以太坊
兼容的虚拟机）， sql （对于SQL风格的数据库）甚至 wiki （用于协作编辑的文本）。 状态由有序的一系列更改确定的任何共享实体都是潜在的候选者。 每个这样的实体将需要：（a）提供正确的抽象以更新其状态的API；（b）订阅节点跟踪该状态的适当机制；以及（c）有效检索部分或全部状态的API。 我们正在等待了解哪些其他高层实体将最有用，由我们或第三方通过插件体系结构实现。
那么智能合约呢？
从广义上讲，MultiChain采用的方法是 data 被一成不变地嵌入到区块链中，但是 码 用于解释数据在节点或应用程序层中。 这与以太坊（Ethereum）所举例说明的“智能合约”范式有意不同，在该范式中，代码嵌入在区块链中并在虚拟机中运行。 从理论上讲，因为智能合约是 图灵完成，他们可以重现MultiChain或任何其他区块链平台的行为。 然而，实际上，以太坊式的智能合约有许多令人痛苦的缺点：
- 无论是否感兴趣，每个节点都必须执行每个计算。 相比之下，在MultiChain中，每个节点决定要订阅的流，并且可以忽略其他节点包含的数据。
- 与用于给定计算机体系结构本机编译的代码相比，用于智能合约的虚拟机的性能要差得多。
- 智能合约代码一成不变地嵌入到链中，从而防止添加功能并修复错误。 这在 DAO的灭亡.
- 交易已发送至智能合约 无法更新 由于通用计算的本质，直到知道其最终顺序为止，区块链的状态。 这会导致延迟（直到在一个区块中确认交易为止）以及可能的逆转（在链中发生分叉的情况下）。 相比之下，MultiChain可以适当的方式处理每种类型的未确认交易：（a）传入资产立即更新节点的未确认余额，（b）传入流项目立即可用，其全局顺序随后完成，（c）权限更改立即应用，然后在传入的块中重播。
尽管如此，就像我已经 之前说过，当我们看到强大的用例时，我们当然不会排除将智能合约作为区块链应用程序的有用范例。 但是，在MultiChain中，智能合约将在区块链顶部的类似流的层中实现，而不是最低的交易级别。 这将保留MultiChain在资产和流等较简单的区块链实体上的卓越性能，同时在真正需要的地方提供较慢的链上计算。 但是，这种情况比您想象的要少。
请发表任何评论 在LinkedIn.
技术附录
与流相关的所有命令均在文档中完整记录。 MultiChain API页面，但这是一个简短的摘要：
- 使用创建流
create streamorcreatefrom ... stream - 将项目添加到流
publishorpublishfrom - 使用检索流列表
liststreams - 开始或停止跟踪流
subscribe和unsubscribe - 使用检索流项目
liststreamitems,liststreamkeyitems和liststreampublisheritems - 列出流密钥和发布者
liststreamkeys和liststreampublishers - 对于大型流项目，请使用检索完整数据
gettxoutdata（见maxshowndata下面） - 通过类似的调用控制每个流的权限
grant [address] stream1.write - 使用查看流的权限
listpermissions stream1.*
有关流的其他一些开发人员说明：
-
create权限允许一个地址创建流。 - 每个流相关的权限是
write,admin和activate - 全新 区块链参数:
root-stream-name（不留任何内容），root-stream-open,anyone-can-create,admin-consensus-create,max-std-op-returns-count - 全新 运行时参数:
autosubscribe自动订阅创建的新流，并maxshowndata限制API响应中的数据量（请参阅gettxoutdata以上）。 - 流项目数据的最大大小由
max-std-op-return-size区块链参数，以及较小的maximum-block-size和max-std-tx-size值减去几百个字节。 - 使用旧钱包格式的节点无法订阅流，并且 应该升级.
