那些关注在企业和企业间流程中使用分散式平台的开发人员，您好。我们在该主题上的出版物于2018年初被中断。不，Raiffeisenbank并没有停止朝这个方向努力：现在是时候从方法论计算和熟悉单个技术的功能转变为在工业环境中或尽可能接近特定商业案例的实施。同时这篇文章内容丰富，内容丰富。因此，我们希望您的参与并警告教程格式。
在2016-2017年，我们完成了许多研究项目以构建去中心化贸易融资平台。使用测试以太坊（Rinkeby）作为基础的分布式分类帐平台，并使用以太坊Swarm作为分散的文件共享工具。除了构建去中心化平台的一般问题之外，我们还测试了智能合约的可能性，预言机的使用和仲裁智能合约的使用。其中一些结果是
在有关哈布雷的文章中。
基于这些研究项目，
试点和工业项目。
正如军方所说，这项长期工作的结果是常规分散平台R-Chain的Raiffeisenbank IT的“供应接受”。现在，它已作为各种规模的企业集团的客户服务要素之一提供。
我们共享构建此平台的主要功能，并讨论其中使用各种“技术”组件（区块链平台和分布式文件系统）的演变。
内容
公司和公司间系统的功能
为了使该平台顺利地投入工业运营，并且不会给开发人员带来过多的意外，有必要了解向未来参与者提议的平台必须满足以下要求：
- 该平台必须有一个运营商-一个法律实体，对参与者的功能负责。选项-每个人自己做，一切都将由参与者的共识决定，以此类推，在公共区块链平台上通常不适用。
- , . , - - 15 — , .
- « » , . , , , « » , .
- , , . , — .
- «» . , - — , , . , , — , .
列表中的许多人会惊讶地发现缺少“每秒事务数”和其他性能等级。我们的经验表明，生产力并不是成功实施平台的最重要条件。性能只是必须“足够”，并且有许多数据流体系结构可以显着提高基础平台的吞吐量-从数据寄存器到横向Turbo流。由于不注意上述几点而导致项目死亡的可能性极高。
通用平台架构
软件组件的架构
我们在2016-2017年的研究项目中使用的应用程序是在将对话框界面与分布式平台的“技术”组件（即geth和swarm）直接集成的基础上编写的。但是，在分析了这种方法的可能性和后果之后，我们得出的结论是，有必要在业务后端和“技术”组件之间引入另一层-统一业务对象的适配器。该技术属于用于构建软件体系结构的相当标准的模式，但是，该模式不会降低其有效性。结果，我们平台节点的软件体系结构开始看起来像这样：
在这种体系结构中，业务应用程序不能直接与DLT组件的抽象一起使用，而是与特定的条件“通用业务流程”（以下称为流程）一起使用-它创建一个流程，更改该流程的状态。将通用流程及其上的操作的数据结构简化为DLT客户端中使用的数据和操作，是通过一组称为“业务流程镜像”的组件来实现的。 “镜像”还对从DLT客户端接收到的信息执行反向转换，并通过与参与者（节点的所有者）不相关的过程过滤信息。因此，在每个节点上，该节点所参与的业务流程的数据库都保持为同步状态，并且处于最适合业务应用程序的格式。商业应用与此数据库交互-业务流程的数据库，接收有关流程状态的信息并转移操作以更改这些状态。
一站式业务流程
自然会出现一个问题，即应为通用业务流程赋予哪些属性，以便一方面确保最大程度地利用区块链平台的优势，另一方面确保在业务应用程序中使用的最大灵活性和功能性。另一个条件是能够在大多数常见DLT平台上实现所选属性，其功能在某些方面（以太坊/法定人数/主链，超级账本组织，Corda，EOS，Waves）存在显着不同。根据我们自己和其他人的项目的经验，我们得出以下结论。
通用业务流程应具有以下属性：
- 流程参数（流程的类型，状态，流程的上下文属性）
- 流程参与者的角色列表
- 与流程相关的电子文档清单
- 流程过渡图
同时，平台必须在区块链组件级别为网络中的流程传播提供以下条件：
- 信息的完整性和完整性
- 流程参与者之外的电子文档的机密性
- 遵循流程过渡图的控制
- 存储过程状态变化的历史
为了实现这些功能，已经开发了具有相应属性和方法的“框架”智能合约。
让我们关注列出的一些属性和条件-什么，如何以及为什么。
工艺参数-有条件开放，因为它们是通过智能合约直接传输的。对于某些区块链平台，它们基本上是公共的（以太坊/主链），对于其他区块链平台，可以通过确保数据隐私的标准方式（Quorum-私有智能合约，Hyperledger Fabric-渠道和私有数据）将其关闭。在我们的实现中，流程“核心”中最重要的参数可能是“流程类型”，因为它不仅承载语义，还承载功能负载-根据“流程类型”，DLT适配器选择一个智能合约模板，该流程将是自我介绍。为什么需要这个？显然，有无数类型的交易和相同的业务流程可以确保其实施。在相当多的情况下，业务流程本质上仅在过渡图上有所不同（从平台的角度来看），并且可以使用一个支持任意过渡图的单个智能合约来实现（以下内容中有更多内容）。但是，非常独特的时刻可以与特定的业务流程相关联：
- (, )
- (, )
- (, )
试图将所有这些潜在的多样性形式化，“格式化”并塞入一个智能合约模板中绝对是乌托邦式的。为特定类型的业务流程开发唯一模板是一种更为有效的方法，既提供了高度的灵活性，又具有将硬性的必要流程元素和关键检查直接“硬”刷入区块链组件“核心”的能力。这将排除个别参与者进行操纵的任何可能性。另外，该平台整体上将结合用于业务应用程序与流程交互的接口的统一以及其特定功能的实现的高度模块化。
我们流程的“内核属性”还包括“状态”和“注释”：第一个是流程状态的简短描述（“新建”，“已取消”，“关闭”，“正在审批”），第二个是“长”字符串，带有有关“状态”的更详细说明。我们将票据的长度限制在1000个字符左右（例如，“帐户资金不足”），因为附加到流程中的电子文档旨在转移大量信息（尤其是机密信息）。
流程过渡图-描述具有特定角色的参与者是否可以更改流程的状态以及更改的状态。对过渡的可允许性的控制是由区块链组件的“核心”执行的，并且不能由“无能为力”的参与者伪造。另外，例如，导航图可以由业务应用程序使用，以确定节点所有者在进程的当前状态下可能的动作，以便对对话框组件进行适当的管理。
机密数据的传输。为了传输机密信息，将使用附加在流程中的电子文档。业务应用程序将必要的文档上载到本地文件存储“镜像”，并在操作中指示它们以更改流程状态。从本地存储转移到DFS之前，将使用接收者节点的公共密钥（该过程的参与者）对文档进行加密。将生成的加密容器传输到DFS之后，到它的链接和原始文档的哈希将传输到流程的智能合约。收到有关流程状态变化的信息后，文件详细信息将提取到业务流程数据库中，然后使用链接从DFS中提取加密容器，并使用接收节点的密钥进行解密。进行检查以确保在流程的智能合约中指定的文档的哈希总和匹配，该文档放置在本地文件存储中，并且可用于业务应用程序。因此，业务应用程序仅适用于文档的“开放”版本-有关其安全传输的所有担忧都由“镜像”承担。
过程状态更改的历史记录是一系列“框架”，每个框架对应于过程状态更改的一个操作。在我们的实现中，我们为历史的每个“框架”存储以下数据：
- 状态
- 注意
- 状态更改事务的发起者的标识符
更改历史记录在智能合约级别上，不仅可以跟踪过渡顺序以进行审核，而且还可以使业务应用程序正确处理事件链，即使事件是一次性到达的（例如冻结，功能中断等）。
确保法律意义-一个非常重要的问题，我们在“公司和公司间系统的功能”部分中指出。我们最初从以下概念出发：不应通过区块链平台提供法律意义，而应使用具有监管支持或平台参与者之间适当信任级别的外部PKI。粗略地说，必须为您的行为提供法律依据的电子文档（付款文档，合同，需求等），并随附在流程中，该文档必须以“原始” PKI（在俄罗斯-GOST，在国外某处， SSL或PGP / GPG）。业务线应用程序将验证“外部”签名并采取适当的措施。是否结果取决于结果。有人会说这不是“福音”，“我们需要说服律师注意区块链交易的法律意义。”我们经历了这一旅程的许多步骤，结果始终是相同的。但是，在俄罗斯Masterchain认证在这方面开辟了某些机会-俗话说“快乐狩猎！”
使用一站式业务流程的好处
这种方法最终给我们带来了什么？
- 扩大分散业务应用程序潜在开发人员的圈子。 «» - - , - «» , . . -, Corda, «» Ethereum, Quorum. , - «» - .
- «» . , , , , , - . , «» «» ( ), «- » . , « , ...», . «» -, «» . , «» -, . , - , . , , , , , , «»
insufficient funds for gas * price + valuegas required exceeds allowance or always failing transaction. - «» -. - - , -. -, , 75-95% . , , « , » . , :
>>> - DFS, , , «» -. Ethereum, «» . - (TON!), . , . … , , .
>>> - . , Ethereum — , , , , , — . - . . . , , , , , , . , , , , — .
- . , , « , ». , . — -. , - ( ) — - .
-
在这里，可能是因为在一首著名的歌曲中演唱的歌曲“在他们身后，您可以听到杂音……”-例如，与稍微过于优雅的Solidity不同，Hyperledger Fabric或Corda chaincode允许您实现几乎无限复杂的业务流程逻辑，并且这种方法亵渎了它们的功能。好吧，是的，他们绝对是正确的。对于抱怨的人，我会提醒您一些来自软件工程领域的著名信息：
- 将业务逻辑放在哪里-在数据库的存储过程中或在业务应用程序的代码中？
- 哪个更好-大型机还是专用计算机？
- 您确定所选的基准将在将来的寿命更新中保持兼容性吗？总体而言，它能否在接下来的2年中生存？
答案很简单，如果：
- 您有很多金钱，时间和免费的区块链专家
- 您确定不必将所选的区块链基础从“从不”一词更改
- 您确实需要将平台功能“压缩” 101％
好吧，那么-一个特殊的计算器……在Hyperledger Fabric或Corda的意义上，在其cheyncode上进行了缝合，并进行了其他“凿凿”。如果没有，请自己考虑...
主机网络监控
也许对某些人来说这是一个启示，但是组织良好的监视是企业软件系统成功运行的基础。这个概念不仅包括（甚至不包括）服务器的标准基础架构监视，还包括软件组件的功能监视。您的分布式平台不仅应该正常工作，而且还应该正确地犯错，为支持服务提供足够数量的理智的信息，使您可以快速识别，识别和修复故障。如果监视系统具有主动功能，那就更好了–它使您可以识别潜在的“坏事”，并在“发生”之前阻止它们的可能后果。
如果在任何时候您都不了解网络节点处于什么状态以及网络上正在发生什么，而是“根据用户的信号”工作，那么最好立即释放队列中的空间，而不要花费亲爱的客户的时间。
基于以上所述，从我们平台开发之初开始，便内置了一个主动监控系统。让我们描述其操作原理：
- 在平台的区块链基础上，建立了一个特殊的智能合约，该合约负责收集和分发监视数据（为简便起见，我们将此智能合约称为SCM）。
- , (), « », , . , - .
- - « », — .
- DFS- « », .
- , DFS .
- , , :
>
> «» -
> «» DFS
> - ( Ethereum- )
> «»
> «» — , «»
> «»
> «»
>业务应用程序的审计跟踪
对于某个特定的值或用于监视指标的值组合，Mirror会自动暂停其操作队列的处理，阻止出现潜在的不良后果，例如：
- 如果区块链通道的控制标签出现严重滞后，这被解释为节点退出区块链网络或其功能完全中断
- 在DFS通道的控制标签出现严重滞后的情况下，这被解释为DFS网络中的节点丢失或其功能完全中断
- 如果操作队列中有错误，则会阻止与此业务对象（通用业务流程）关联的所有后续操作
特别注意处理“镜像”所使用的数据库错误。该数据库不仅用作与业务应用程序的接口，而且还用作“镜像”操作队列的状态机的状态堆栈。经验表明，在更改数据库表中的数据时，如果存在特定错误，则循环操作会随着事务和其他乐趣的大量重新发送而发生。一次，由于类似的错误，我们在两天内“制作”了Quorum链上的半年刊。因此，如果检测到此类错误，则“镜像”将完全关闭，并等待支持服务的手动响应。
中央监视节点从SCM提取所有网络节点（包括其自身）的信息并进行分析，从而可以及时检测到以下危险或潜在危险状况：
- - DFS-
- - DFS-
- -
- «»
- «»
下图显示了一个测试网络中最简单的监视程序的示例：
开发并实施了更多的“高级”主动监视方案，包括业务应用程序，但是在这里，我们遇到了特定客户知识产权的不稳定边界。
我们不要掩盖一个事实，在我们的某些区块链网络中，监控流量占总流量的绝大多数。在这方面，甚至想到了使用浮动时间表来“探测包裹”的频率-在工作时间更多，在非工作时间更少。但这是值得的。真。
通常，只要分散的网络带宽允许，就监视您能想到的一切。您会不止一次地赞美编程之神一两次，当然，本文的作者：)
因为正如墨菲定律的一种解释所言：“错误通常在于没人怀疑的位置。”
使用各种技术组件的演变
在考虑了企业分散网络的部署和运营的一般条件以及我们用于构建R-Chain平台的体系结构原理之后，我们现在来看一个故事，即在实施特定项目的过程中其单个技术组件如何以及为何演变。
首先是发布国际担保的项目，我们的合作伙伴是来自白俄罗斯的同事-2018年3月至12月。
我们从以太坊-以太坊群-Crypto-Pro（DLT-DFS-cryptography）配置开始，该配置已在研究项目中得到了很好的证明。代替使用以太坊Rinkeby公共测试PoA网络，提出了以太坊PoA专用网络和以太坊Swarm专用网络。最初，没有技术问题，但我们遇到了“密码”麻烦-白俄罗斯参与者之一断然拒绝使用我们提供的密码工具，这是参考当地有关电子文档管理的法律。当时，不可能“立即”找到高质量的解决方案，但是人们一直对密码术在国际项目成功中的困难和重要作用有持续的了解。
在真实网络基础架构上运行控制事务（每个参与者在其资源上部署了一个节点）的过程中，已经发现以太坊Swarm工作失败-文件丢失的水平为20％。有人提出，丢失是由于并行发送多个文件时Swarm客户端中的问题引起的。总的来说，这一假设得到了证实：通过实验，我们设法在5秒内将单个文件发送到Swarm之间找到了暂停。在过渡到完全战斗的网络配置的过程中，由于Raiffeisenbank基础设施中使用的网络分段的特殊性，需要创建一个传输Swarm节点，出现了一个关键问题-以太坊Swarm允许在通过传输节点工作时最多丢失30％的文件。“分层”的体系结构和良好的监控系统使以“手动抽油”的模式成功地执行保证的真正问题成为可能，但以太坊群的命运却被封杀了。必须说，以太坊群已声明的在没有直接收发器连接的拓扑中工作的能力是选择它作为DFS的技术基础的主要原因之一，并且它无法在这种模式下可靠地工作产生了很多问题。由于无法在这种模式下可靠地工作，因此产生了很多问题。由于无法在这种模式下可靠工作，因此产生了很多问题。
应该注意的是，在该项目中基于以太坊的专用网络对其可恢复性感到满意。项目进度表假定将在发出担保后3个月内关闭已签发担保，在此暂停期间，一些参与者停止了其节点。但是，在1天之内没有铃鼓起舞的情况下重启网络后，它恢复了完整性，并且关闭担保的操作也没有任何抱怨。
下一个项目是为阿斯科纳集团公司创建一个集团内部网络-2018年9月-当前时间。
根据国际担保项目的经验，选择IPFS（行星际文件系统）作为DFS的技术基础。对于并行发送文件，它工作得很好，并且不需要特殊的模式调整。IPFS的唯一弱点也许是无法（指定！）在“传输”拓扑中工作。在建立具有大量参与者的网络时，由每个人实现每个人到每个人的“全明星”访问是一个组织问题。另一方面，所有参与者都在自己和操作员的“支持”节点之间实现访问。因此，为了组织文件的平稳分发，实施了以下机制：
- 将文件附加到某个业务流程的智能合约时，将生成DeliveryFile事件，其中包含指向该文件的链接
- DeliveryFile IPFS. IPFS , , . .
- , , , «» ,
因此，Ascona项目始于以太坊-IPFS-Crypto-Pro配置。
使用Crypto-Pro加密具有法律意义的文件的文件和“外部”签名可确保法律约束的简便性，并且无需信息安全部门的索赔，这反过来对从银行和银行获得必要批准的时间产生了极大的积极影响。阿斯科纳集团公司的公司当事方。总的来说，该项目是按工作顺序开发的，并且已经通过了试点阶段，现在已经进入生产的终点线，这里...
...并在这里同时进行两个项目-有条件的“外星人”，但我们作为专家参加了相似的配置，在其中捕获了成千上万个区块的大型分支，而一部分网络的交易却因此而丢失。对区块链社区的日志和解释的分析得出了令人失望的结论-以太坊PoA（在某些情况下甚至是PoW）在节点数量少的紧凑型网络中使用（公司网络恰恰在此处）对此类怪物的风险很高。此外，当一个节点退出网络并且不再希望与其同步时，一个神秘的错误开始定期出现在我们的测试网络中。即使在重新安装以太坊并完全剥离之后。简而言之，很明显，产品网络需要替代区块链的基础。又快非常快。
结果是Quorum-实际上是Ethereum的兄弟。“镜像”中的改进数量很少，业务应用程序当然根本不需要任何改进。
目前，向Quorum过渡仅带来了以下优势：
- 使用筏共识消除了叉子
- 没有空块会减少链的大小
由于没有分叉，因此我们无需等待交易的条件完成就可以暂停，这是以前为了不处理潜在的交易回退所必需的，并且我们最多有6个块生成周期。首先，这自然会提高平台的性能，其次，它消除了如果分叉超过了计算的停顿，并且所触及的“镜像”业务对象的状态不再与其区块链状态保持一致时会出现的非常棘手的问题。
Quorum唯一可能令人不快的功能是能够在长时间的暂停后重新启动时生成大小为几兆字节的兆块，这在尝试卸载其内容时只会阻塞DLT适配器。但是，严格来说，服务台不应睡那么长时间。
经过如此巨大的发展，我们来到了Quorum-IPFS-Crypto-PRO配置，现在在俄罗斯国内市场上使用。
也许有人会问一个合理的问题：“好吧，您以前没有听说过Quorum，还是什么？”...我们听说过Quorum，Hyperledger Fabric和EOS。本文作者甚至于2017年秋天参加了第一届俄语Corda研讨会。黑格尔可能专门针对此类问题的明智答案而发明了辩证法。这个于2016年开始研究的小团队在开发Windows交互式应用程序方面拥有丰富的经验，而以太坊（测试之一是可以理解的）的最低门槛来自区块链平台。并且由于我们有兴趣专门针对区块链主题进行研究，而不是研究不同的泊坞窗，没有它们，启动“成人” Quorum或Hyperledger Fabric（并非在所有虚拟Windows平台上都是可行的）是不现实的，因此选择很明显随着研究结果开始引起银行各业务部门及其合作伙伴的关注，扩展团队，将靴子委托给制鞋商，将蛋糕委托给蛋糕，获得Linux服务器等成为可能。而且，自然而然，只要保留了开发潜力，就没有人会放弃已开发的解决方案。辩证法与进化。
具有研究和运营企业平台及其进一步发展的经验
本文的作者参加了在Raiffeisenbank，FinTech Association和其他一些地方进行的大量区块链项目-无论是作为开发人员还是作为去中心化平台的专家。其中一些纯粹是研究项目，有些最终成为试验项目，有些则发展成具有数十个节点的相当大的工业网络。
从所有这些经验中可以得出什么主要结论？
1.区块链平台的种类繁多，它们的“消费者”品质差异很大：
- “入门门槛”和易于网络部署
- 带宽
- 智能合约的功能
- 信息关闭选项
- 开发时间和成本
因此，我认为不可能说任何平台都将成为绝对主导。每个人都有其自己的潜在用户和任务圈，在此圈内使用它们是最合理，最经济的。这适用于以太坊，法定人数，超级账本组织和Corda。在这里，与编程语言一样-只有Vasya和Petya（他们各自都懂一种语言）会争论到哪个更好-“ pluss”或“ toad”。而谢苗·彼得罗维奇·阿尔伯特·伊万诺维奇，谁知道一打，将安静地说话-当“加号”是好，当- “蛤蟆”。
2.尽管某些DLT平台（例如Hyperledger Fabric和Corda）提供了传输大型数据项的能力-实际上，文件（很可能是具有智能合约机制的区块链基础和文件传输功能）将保持独立。这是由于以下几点：
- , DLT-. . Hyperledger Fabric Corda 2M « », , IPFS 100M. - - pdf (, ), 50M — , .
- - , ( + ), , .
- , , S3. , , « », , DFS. .
- , , -, «» .
3.当前，分散平台技术支持服务的专家长期短缺。更确切地说，它们根本不存在。绝对。在我所知道的大多数项目中，大部分技术支持工作是由创建这些平台的开发人员或研究工程师完成的，这当然不好。我认为这是由于年轻人的方向，并且正在逐步开发技术说明，响应模板，监控方案和其他组织支持服务高效工作所需的方法论材料。这里的问题之一是在特定的区块链平台上缺乏良好的俄语概述课程。一切都必须相互传递。但是企业中的支持专家不是开发人员，而是专注于其他问题：监控，诊断错误，确保事故发生后系统的可靠性和恢复能力（您认为您不会发生事故吗？当然可以）。而且，坦率地说，由于支持不力而导致公司项目死亡的可能性大大高于由于开发质量不佳而导致的失败。因此，吸引该项目支持和运营企业系统方面的经验丰富的高质量专家是一个重要的因素，即使不是最重要的因素，该项目也将长期存在和发展，并且不会在几个开国元勋离开后立即枯萎。因此，吸引这个在支持和运营企业系统方面具有丰富经验的高素质专家是一个重要的因素，即使不是最重要的因素，该项目也将长期存在和发展，并且在几个开国元勋离开后不会立即消失。因此，吸引该项目支持和运营企业系统方面的经验丰富的高质量专家是一个重要的因素，即使不是最重要的因素，该项目也将长期存在和发展，并且不会在几个开国元勋离开后立即枯萎。
4.最模糊的法律领域之一是运营商与网络参与者之间关系的形式化，这一事实加剧了这一事实，即运营商一方面不是网络及其资源的所有者，另一方面有义务确保其运行，即使该措施与个人参与者的利益相抵触。运营商的权利和义务之间的平衡，它对网络参与者的“影响力”，运营商的财务责任-所有这些现在都是非常棘手的争端的主题。最简单的问题：尽管看似简单，但如何确保所有网络参与者同步替换关键软件却引起了激烈的讨论？基于已经进入产品平台的经验，运营商和网络参与者的职位合法化的例子的出现将大大加速分散网络的引入，因为分散网络是公司和企业间关系的重要组成部分。
如果您走到了尽头，那么还有一个好处：关于去中心化公司平台的当前状态和发展路径的一些问题将反映在本文作者针对一种区块链资源准备的材料中（该材料是为广泛的读者设计的）。