Corda 3.0 Release Note

原文地址 corda/corda

在corda的原代码库中找到了v3的release note,先翻译了一些,让大家感受一下,注意不一定是最终版本

相对于2.0的不痛不痒来说,Corda3.0 的这次更新不可谓不重量级。包含了很多的改进,所有corda的开发者都应该有所了解。

Release notes

Release 3.0

Corda 3.0的发布带来了线性稳定性和其它一系列令人兴奋的功能,它旨在提升开发人员和用户的体验,它同时提供了已部署Corda实例的长期可用性。 它将提供功能,以确保任何希望转移到R3 Cord的早期版本的用户可以无缝地迁移,并确保保存在钱包中的有效数据在新旧节点之间通用。

3.0 重大变更

• 线性稳定性

线性稳定性给开发者的数据带来了和代码稳定性一致的承诺。

从这一点来看,Corda系统生成的任何state总是可以检索,可以理解的,并且在任何随后发布的版本(版本3.0及以上版本)中都是有效的。

因此,系统部署是安全的,因为通过升级和更改的有价值的重要信息可以保持访问。 实际上,这意味着从这一刻开始,升级Corda网络的全部或部分节点将不需要重置数据; “它会正常工作”。

从Kryo转向Corda自己的基于AMQP的序列化框架,该框架被设计为与state数据进行互操作,并且允许开发人员基于Corda平台编写的智能合约可以随着时间的推移而演进。

○ AMQP Serialization

AMQP序列化现在可用于点对点通信以及将状态写入钱包。 这种序列化格式的改变,可以提高安全性和线性稳定性。 这是使不同版本的Corda节点在同一网络上共存并实现更轻松升级的关键先决条件。

有关AMQP序列化框架的详细信息,请参见:ref:`here <amqp_ref>`。 这提供了框架的介绍和概述,而与序列化有关的更多关于对象演化的具体细节可以分别在doc:`serialization-default-evolution`和:doc:`serialization-enum-evolution`中找到。

注意:

此版本提供了我们从Kryo序列化到AMQP序列化的大部分过渡。 这意味着Corda以前版本中记录的许多约束现在都已实施。

尤其是,建议您查看标题为:ref:`Custom Types <amqp_custom_types_ref>`的部分。 为了帮助转换,我们在本发行版中包含了对默认构建和实例化具有无法访问的私有字段的对象的支持,但不保证此支持将会延续到未来的版本中; 上述链接中记录的限制是规范来源。

虽然这是Corda的重要一步,但这绝不是序列化故事的结束。 我们为将来的版本计划了许多新功能和工具,但认为尽早提供上面讨论的保证更加重要,以使社区更加自信地发展。

重要:

虽然Corda已经稳定了它的用于点对点通信和state持久存储的网络协议和基础设施,但RPC框架对于此版本而言不包含在此保证范围内。 将客户端和服务器上下文从Kryo转移到我们稳定的AMQP实现计划将用于下一版Corda。

○ Artemis and Bridges

Corda现在已经实现了使用AMQP 1.0开放协议标准作为其对等体之间的通信协议的长期目标。 这形成了一个强大且灵活的框架,我们可以通过该框架实现未来的增强功能,从而可以更加顺畅地融合Corda与第三方代理,语言和邮件等系统。 此外,这也是正式定义Corda官方点对点消息协议的重要一步,这是Corda协议更深入安全审核所需的一些内容。

• 新的网络拓扑服务

本版本引入了新的网络拓扑架构。 网络拓扑服务已完全重新设计和实现,以实现未来网络可扩展性和冗余度,减少运行时运维开销,支持多重公证以及管理网络兼容区域(CZ)。

Corda兼容性区域被定义为在运行的Corda网络中配置的参与者和服务(Notaries, Oracles, Doorman, Network map server)的组合,以便彼此可互操作和兼容。

我们引入网络参数的概念来精确地指定网络中的节点需要同意的一组常量(或常量范围),以确保无缝的互操作。 额外的安全控制措施确保所有网络地图数据现在都被签名,从而降低了网络运营商篡改网络信息的能力。

还支持一组节点在本地操作,这是通过将每个节点的签名信息文件复制到其他节点的目录来实现的。 我们添加了一个引导工具来简化这个用例。

重要

这取代了Corda 1.0和Corda 2.0中的Network Map服务。

进一步的信息可以在:doc:`changelog`,:doc:`network-map`和:doc:`setting-a-corda-network`文档中找到。

• 智能合约升级

本次版本的发布大大扩展了智能合约的升级

智能合约的状态表明哪些附加的JAR可以使用_constraints_定义和检查它们。 在旧版本中,唯一受支持的约束是哈希约束。 这提供了与比特币和以太坊这样的公共区块链系统类似的行为,其中代码在部署后完全修复,以后无法更改。 在Corda有一个升级方式,涉及所有相关方的合作(如各个states自己宣传的),但这需要明确的交易适用于所有states,并由各方签署。

提示

这是一个相当重量级的操作。 因此,应考虑在合理的时间执行升级。

通过损失一定的灵活性,散列约束提供了最大限度的分散和最小信任。 在Corda 3.0中,我们添加了一个新的约束,一个_network parameters_约束,它允许兼容区域的操作员维护可接受合同JAR的列表,而不是硬编码。 这允许以集中导入元素为代价的简单升级。

区域限制提供限制较少但更集中的控制机制。 如果您希望升级应用程序,并且您不介意在其他业务原因需要事务处理时“立即生效”的升级,则此功能非常有用。 这些允许您指定兼容性区域的网络参数(请参阅:doc:`network-map`)预计包含类名映射到允许提供该类的JAR的散列。 升级应用程序的过程包括要求区域操作员将新JAR的散列添加到参数文件中,并触发网络参数升级过程。 这涉及每个运行shell命令的节点操作员接受新的参数文件,然后重新启动节点。 没有及时重新启动节点的节点所有者会有效地停止成为网络的一部分。

注意

在以前版本的Corda中,states包括其定义应用程序JAR的哈希(在哈希约束中)。 在这个版本中,事务处理包含智能合约和附加到他们的states的JAR,因此如果接受方缺少应用程序的副本,代码将通过网络复制到接收方。

在运行合同验证码之前,测试合同验证码所在的JAR是否符合合同约束条件:

对于HashConstraint:部署的CorDapp jar的哈希必须与在事务中找到的哈希相同。

对于ZoneConstraint:交易必须附带每个智能合约的白名单附件。

如果此步骤失败,则遵循正常的事务验证方式

Corda 3.0为将来的版本奠定了基础,当合同验证将针对附加的合同JAR,而不是要求本地部署的CorDapp交易指定的确切版本。 该功能的未来愿景是动态下载适当版本的智能合约及其在沙盒环境中的执行。

警告

这一变化意味着您的应用程序JAR现在必须符合10mb附件大小限制。 为了避免在网络上多余地复制不需要的代码并简化升级,可以考虑将你的应用程序分成两个或多个JAR–一个包含状态和合约(我们称之为“内核”app),另一个包含flow,服务,Web 应用程序等。例如,我们的Cordapp模板就是这样构建的。 只有第一个会被附加。 另外请注意,由于Corda 3.0不支持JAR依赖关系,因此应用程序内核所具有的任何依赖项必须捆绑/“分解”为一个JAR。

未来版本的Corda将添加对基于签名的约束的支持,其中由给定身份签名的任何JAR都可以附加到事务中。 这个最终的约束类型提供了所有需求的平衡:平滑的滚动升级可以在没有任何额外的步骤或事务被签名的情况下执行,代价是信任智能合约的开发者更多,并且在管理应用程序签名方面增加了一些额外的复杂性。

• Test API 稳定性

已经进行了大量的工作来完善提供给测试CorDapps的API,使它们更简单,更直观,并且通常更易于使用。 另外,这些API已被添加到我们保证随时间稳定的API的锁定列表中。 这将在不同版本之间进行升级时大大提高生产力,因为您的测试环境将不会发生任何变化。

有关将旧测试转换到新框架的更多信息,请参阅:doc:`upgrade-notes`。

其它功能性改进

• 清理关闭节点

除了用户反馈,我们还得出结论强烈需要有一个干净的转折点,在这个转折点可以关闭一个节点,而不需要进行任何正在进行的事务处理,以便为升级目的提供干净的系统。 因此,增加了流量排空模式。 激活后,节点进入静止状态,确保不会开始新的工作,并且在关闭之前完成所有未完成的工作。

一个节点的清理关闭可以通过下面的方式实现:

○ 订阅状态机更新

○ 通过rpc.setFlowsDrainingModeEnabled触发流量排空模式(true)

○ 等到订阅设置为第一阶段后,并且通知你不再有检查点

○ 你就是想要关闭节点

注意

一旦设置,此模式是一个持久性属性,将在节点重新启动时保留。 必须在节点接受新的RPC流连接之前明确禁用它。

• X.509 证书

它们现在有一个扩展名,用于指定证书所用的Corda角色,现在在验证代码中强制实施角色层次结构。 这只会影响那些与外部PKI解决方案的整合。 在大多数情况下,它由Corda透明地管理。 有关扩展的正式规范,请参阅:doc:`permissioning-certificate-specification`。

• 可配置的授权和认证数据源

Corda现在可以配置为从外部数据库加载RPC用户凭证和权限,并支持基于Apache Shiro框架的密码加密。 有关文档,请参阅:ref:`RPC security management <rpc_security_mgmt_ref>`。

• SSH 服务器

通过CRaSH 远程管理Corda节点现在可以通过SSH获得,请参阅:doc:`shell`获取更多详细信息。

• RPC over SSL

Corda现在允许通过SSL进行RPC调用的配置。 有关详细信息,请参阅:doc:`corda-configuration-file`。

• 增强公证配置

公证员的配置已被简化为一个公证配置对象。 有关更多详细信息,请参阅:doc:`corda-configuration-file`。

注意:

extraAdvertisedServiceIds, notaryNodeAddress, notaryClusterAddresses and bftSMaRt 等配置被删除了

• 数据库表名模式

为了与所有支持的Corda和R3 Corda数据库中的通用约定保持一致,某些表名已更改。

另外,对于从CommonSchemaV1.LinearState或CommonSchemaV1.FungibleState扩展而来的现有合同ORM模式,您需要将参与者集合显式映射到数据库表。 以前这个映射是在超类中完成的,但是这使得不能正确配置表名。 所需的更改是添加覆盖var参与者:MutableSet <AbstractParty>? =空字段添加到您的类,并添加JPA映射。

• 可插入的自定义序列化

随着AMQP的推出,我们引入了要求无缝可序列化的类,特别是Java类(与Kotlin相对),必须使用-parameter标志进行编译。 但是,我们认识到这并非总是可行的,特别是在严格控制的商业环境中处理第三方库。

为了尽可能简单地解决这个问题,CorDapps现在支持为这些类创建可插入代理序列化器。 这些应该写成这样,他们创建一个中间表示,Corda可以直接映射到不可序列化的类和可以直接映射到可序列化的类。

SIMM demo中提供了许多示例

samples/simm-valuation-demo/src/main/kotlin/net/corda/vega/plugin/customserializers

文档可以在doc:`cordapp-custom-serializers`中找到

• 安全审计

这个版本的Corda是R3内部安全团队首先对选定的组件进行了新建安全审查流程的组件。 安全审查将是一个正在进行的过程,旨在确保Corda的安全模型已经达到最高标准,并符合行业最佳实践。

作为此安全审查流程的一部分,对代码中基于HTTP的组件进行了独立的外部安全审计,并对其建议采取了行动。 安全保证流程将与Corda平台并行发展,并将结合代码审查,自动化安全测试和安全开发实践,确保Corda实现其安全保证。

• 安全修复

由于潜在的隐私泄漏,公证服务在尝试消耗同一状态两次时返回的错误对象发生了重大变化:NotaryError.Conflict不再包含发起该状态的第一次花费的一方的身份 ,并为一个状态指定消费事务ID的散列,而不是ID本身。

如果没有这种改变,知道特定状态的参考,攻击者就可以构建一个无效的双重支出交易,并获取有关交易和消耗它的一方的信息。 它可以通过猜测其输出索引来获得具有相关身份的转发事务图,并重新获取新获得的事务id。 当使用匿名身份时,这也可以揭示资产所有者的身份。

内部接口和稳定性保证

内部接口和稳定性保证

开始此章节之前,你应该已经具备了对Corda […]

发表评论

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