精华内容
下载资源
问答
  • ICS 备案号 DBXX 湖 南 省 地 方 标 准 DBXXXX XXXX 信息安全技术 区块链合约安全技术要求 - - 发布 - - 实施 湖 南 省 市 场 监 督 管 理 局 发 布 DB 目 次 目 次 I 前 言 I II 引 言 I V 区块链合约安全技术测评...
  • 一、什么是合约交易 合约交易是指买卖双方对约定未来某个时间按指定价格接收一定数量的某种资产的协议进行交易。 合约交易的买卖对象是由交易所统一制定的标准化合约,交易所规定了其商品种类,交易时间,数量等标准...

    一、什么是合约交易

    合约交易是指买卖双方对约定未来某个时间按指定价格接收一定数量的某种资产的协议进行交易。 合约交易的买卖对象是由交易所统一制定的标准化合约,交易所规定了其商品种类,交易时间,数量等标准化信息。合约代表了买卖双方所拥有的权利和义务。简单点说就是,现在约好未来某个时间地点交易一定数量的某种商品。

    合约交易是一种金融衍生品,相对于现货市场的交易,用户可以在期货合约交易中通过判断涨跌,选择买入做多或卖出做空合约,来获得价格上涨或者下跌带来的收益。

    二、合约交易的作用

    标准化合约设计的初衷是为了对冲现货风险而设计的,为了锁定收益成本,对冲现货价格大幅波动的风险,从事大宗商品买卖的公司或个人会在期货市场下相同头寸的空单(多单),用来抵御风险。

    比特币为代表的数字资产合约交易通常采取价差交割,在合约到期时,系统会对所有没有平仓位以交割价格进行交割结算。

    三、合约交易的规则

    1. 交易时间

    合约交易是7*24小时交易,只有在每周五16:00(UTC+8)结算或交割期间会中断交易。合约在交割前最后10分钟,只能平仓,不能开仓。

    1. 交易类型

    交易类型分为两类,开仓和平仓。开仓和平仓,又分买入和卖出两个方向:

    买入开多(看涨)是指当用户对指数看多、看涨时,新买入一定数量的某种合约。进行“买入开多”操作,撮合成功后将增加多头仓位。

    卖出平多(多单平仓)是指用户对未来指数行情不再看涨而补回的卖出合约,与当前持有的买入合约对冲抵消退出市场。进行“卖出平多”操作,撮合成功后将减少多头仓位。

    卖出开空(看跌)是指当用户对指数看空、看跌时,新卖出一定数量的某种合约。进行“卖出开空”操作,撮合成功后将增加空头仓位。

    买入平空(空单平仓)是指用户对未来指数行情不再看跌而补回的买入合约,与当前持有的卖出合约对冲抵消退出市场。进行“买入平空”操作,撮合成功后将减少空头仓位。

    1. 下单方式

    限价委托:用户需要自己指定下单的价格和数量。开仓和平仓都可以使用限价委托。

    对手价下单:用户如果选择对手价下单,则用户只能输入下单数量,不能再输入下单价格。系统会在接收到此委托的一瞬间,读取当前最新的对手价格(如用户买入,则对手价为卖1价格;若为卖出,则对手价为买1价格),下达一个此对手价的限价委托。

    1. 仓位

    用户开仓成交后,即拥有了仓位,同种合约同一方向上的仓位会合并。在一个合约账户中,最多只能有6个仓位,即当周合约多仓、当周合约空仓、次周合约多仓、次周合约空仓、季度合约多仓、季度合约空仓。

    1. 下单限制

    平台对单个用户某个周期合约的持仓数量、单笔开仓/平仓的下单数量会做出限制,防止用户操纵市场。

    当用户的持仓数量或委托数量过大,平台认为可能对系统和其他用户产生严重风险时,平台有权要求用户采用包括但不限于撤单,平仓等风控措施。平台有权采用包括但不限于限制总仓位数量,限制总委托数量,限制开仓,撤单,强行平仓等措施进行风险控制。在这里插入图片描述

    比链科技(www.bitchain8.com)致力于全球领先的区块链技术服务提供商,面向全球提供数字资产金融衍生品系统、交易所开发、钱包服务系统、区块链交易所开发、数字货币开发、智能合约开发、公链私有链联盟链等区块链技术解决方案,为广大金融机构提供安全、稳定、可靠的技术服务。

    展开全文
  • DB PAGE 湖南省市场监督管理局 发布--实施 湖南省市场监督管理局 发布 --实施 --发布 信息安全技术 区块链合约安全技术要求 DBXXXXXXXX DBXX 湖南省地方标准 ICS 备案号 PAGE PAGE I 目 次 TOC \o "1-3" \h \u TOC \...
  • 行业分类-物理装置-一种基于区块链合约技术的私钥保管方法及装置.zip
  • 按照国家标准和行业...区块链应用的安全需求、 区块链安全体系参考架构和指标体系、 区块链安 全测评技术要求等内容, 技术要求又包括加密安全、 共识安全、 合约安全、 数据安全、 网络安全、 应用安全等六个方面。
  • 区块链永续合约

    2019-11-20 09:49:59
    区块链永续合约 区块链永续合约简单来说就是带杠杆,无交割期,可以永久持仓。永续合约是传统的期货合约的升级延续。数字货币交易才有的,相对来说风险小点,灵活把控。 区块链永续合约开发 首先,从设计机制上而言...

    区块链永续合约

    区块链永续合约简单来说就是带杠杆,无交割期,可以永久持仓。永续合约是传统的期货合约的升级延续。数字货币交易才有的,相对来说风险小点,灵活把控。
    区块链永续合约开发

    首先,从设计机制上而言,最大的区别在于永续合约没有交割日,合约永远不会到期结算,只要合约不被爆仓,用户可以一直持有。
    由于没有交割日期限制,永续合约可以避免因交割带来的重复开仓步骤,也避免了重复建仓手续费。
    永续合约通过自动减仓,减少对手盘仓位,降低市场风险,不存在穿仓分摊的情况。

    永续合约价格设计机制也不同,永续合约不容易被恶意“插针”(价格受到盘口“买一价”和“卖一价”的影响。在合约交割期前,价格有时会突然大幅拔高或降低,价格走势图酷似一根“针”)爆仓。

    林嘉鹏说过“要想投机,永续合约才是更好的。”
    在这里插入图片描述

    展开全文
  • 区块链智能合约实施规范,包括智能合约构建、触发、运行和评估过程。 区块链智能合约实施框架、合约接口调用、合约事件约束
  • 区块链智能合约

    2018-12-20 00:06:03
    智能合约代码!
  • 区块链已经对多方业务流程产生了深远的影响。 使用区块链的组织依靠可信的自动交易。 它提供了一个信任框架,您可以使用该框架来安全地自动化直到现在仍是手动的流程。 传统上,在商业交易中,当两方交换价值时,...

    区块链已经对多方业务流程产生了深远的影响。 使用区块链的组织依靠可信的自动交易。 它提供了一个信任框架,您可以使用该框架来安全地自动化直到现在仍是手动的流程。

    传统上,在商业交易中,当两方交换价值时,他们需要共享交换后的价值以及交易条款和条件的表示。 如果他们不能完全相互信任,则各方将维护自己的交换记录-交易分类帐。 他们还保留自己管理合同交换价值的规则和流程的副本。

    复制这些记录可能会导致错误和欺诈。 最重要的是,交易过程也被复制,并且手动且低效地执行。 关于分类账副本和合同副本之间差异的争议可能需要在法庭上解决,从而导致大量成本,并最终导致交易延迟。

    区块链通过将加密技术与分布式计算和存储技术一起使用来解决传统流程中固有的问题,从而为交易方提供一种共享交易和资产的可信表示的方式。

    价值交换遵循交易双方事先通过具有法律约束力的合同达成的规则,例如在买卖交易中,交易双方将资产的所有权交换为约定的金额。 但是,规则通常更复杂,包括对交易具有管辖权的当局的法律和法规。

    借助区块链技术,各方可以使用智能合约来编码和封装管理交易的交易规则和流程。 处理交易后,智能合约将根据其定义的规则自动执行操作和合规性检查。

    整合决策管理平台

    如果通过使用决策管理平台支持的规则引擎来实现智能合约,则可以使它们更加智能。 使用IBM®Operational Decision Manager(ODM),您可以在智能合约定义级别添加信任。 这种方法使业务涉众可以为智能合约决策逻辑的实施做出贡献。 通过将其插入Hyperledger®Fabric™的分布式交易系统中,它完全符合区块链的技术信任模型。

    本文介绍了IBM ODM与Hyperledger Composer的集成, Hyperledger Composer是一个开源的区块链开发框架,该框架在Hyperledger Fabric (一个区块链平台)上运行。 Hyperledger Composer和Fabric是Linux Foundation托管的Hyperledger项目中的两个。 了解如何在区块链解决方案中使用IBM ODM,为不信任的业务网络中的所有参与者带来价值。

    车辆生命周期样本

    为了说明IBM ODM如何为区块链网络带来价值,以下示例考虑了车辆的生命周期。 插图说明了从生产到回收再利用的车辆,并已在车辆监管部门进行了注册,并在出售车辆时转移了所有权。

    区块链网络的车辆生命周期插图

    该示例基于Hyperledger Composer附带的示例。 该样本将IBM ODM业务决策逻辑(规则)集成到在Hyperledger Fabric上运行的智能合约中。 GitHub上提供了Hyperledger Composer示例和集成IBM ODM的示例:

    车辆的生命周期涉及多个方面,包括制造商,汽车经销商,车辆监管机构,保险公司,所有者和废品经销商。 业务网络中的所有各方都将从拥有关于车辆历史和所有权的可信的,分布式的真理源中受益。

    必须使用对每个参与者都重要的特性来描述车辆本身,例如其技术和商业特性,所有者识别和保险状态。

    与车辆有关的交易包括初始采购订单,制造订单,注册请求和所有权转让。 这些交易在车辆生命周期的不同阶段受不同规则的约束。 最初从汽车经销商处购买汽车时,业务规则可能适用于销售过程。 所有权变更可能需要遵守与车辆相关的贸易法律,具体针对每个国家/地区。 参与者希望检测不合规车辆或其他逃税方式上的欺诈交易。

    嵌入在智能合约中的某些交易处理本质上是技术性的,可以调整和转换数据结构,以及创建,更新和销毁资产。 智能合约逻辑的其他部分与控制双方之间或政府监管机构之间的基础合约的法律规则更为接近。

    本示例中的代码需要IBM ODM V8.9.x和Hyperleger Composer V0.11.1或更高版本。 有关所有其他要求,请参见README文件中的示例代码。

    该示例代码包括下图所示的项目,提供示例应用程序和必要的基础结构代码,这些代码可启用区块链基础结构中的IBM ODM运行时组件。

    组成车辆生命周期样本的项目的图示

    要部署和运行示例,请参阅GitHub中的README文件。

    智能合约

    智能合约是区块链平台的基础。 使用智能合约,您可以在处理交易时安全地应用规则。 您可以使用它们来自动执行验证步骤并编码过去签订的有形合同上的条件。

    为了建立智能合约,区块链平台的参与者就如何表示交易及其数据以及管理这些交易的规则达成共识。 该协议包括精确表达这些规则,探索所有可能的例外情况以及定义解决争端的框架。 它通常是一个涉及开发人员和业务利益相关者的迭代过程。

    该过程还包括审查规则,在各方之间注册协议,测试交易数据规则,模拟方案以了解其业务影响并以安全透明的方式存储它们。 此外,必须同样注意数据模型及其代表的业务领域模型。 各方还必须定义规则的管理方式:谁可以定义规则,谁可以部署规则以及更改规则的过程。

    智能合约可操纵价值,因此至关重要的是,您必须使用正确的工具和实践来开发可信任的安全,有保障,透明和逻辑–平台内部全部自动化以加快交易速度并实现自动化的承诺。

    管理智能合约的流程类似于在诸如IBM ODM之类的决策管理平台中找到的流程,在该平台上,业务决策被表示,自动化并作为业务资产进行管理,并由业务涉众进行处理。

    本文探讨了如何在IBM ODM中表示智能合约业务规则,如何通过广泛的IBM ODM工具集对其进行管理,以及如何在区块链平台内使用规则引擎来运行它们。

    具有Hyperledger Fabric,Hyperledger Composer和IBM ODM的区块链网络的拓扑

    本节探讨如何将规则引擎插入到区块链网络架构中,以向智能合约添加规则执行功能。

    有关区块链网络的一般体系结构的信息,请参见Hyperledger Fabric文档Hyperledger Composer文档

    下图显示了区块链业务网络的典型架构。 每个对等节点都有其自己的IBM ODM Rule Execution Server实例,该实例为其上部署的所有区块链应用程序运行规则。

    包括运行规则的Rule Execution Server实例的区块链业务网络的典型体系结构插图

    区块链网络运行在一组节点上。 每个节点都有一个事务分类帐和资产的副本,该副本存储在数据库中,在Hyperledeger Fabric术语中称为世界状态 。

    在一个节点内,多个进程实现了区块链协议和功能。 此拓扑中的对等节点是处理区块链节点上的交易所需的一组过程。

    商业网络中的每个Hyperledger Composer应用程序均由链码流程表示。 链码具有JavaScript解释器,该解释器执行用于处理事务的逻辑。 链码是在HyperLedger Fabric区块链实现中定义智能合约的机制。

    对等节点进程可以物理上运行在不同的机器上,以确保给定区块链节点的高可用性。 如果对等节点之一发生故障,第二个对等节点仍可以验证传入的事务。

    业务网络节点必须由强大的隔离安全性方案保护,因此您需要为每个对等节点部署一个IBM ODM Rule Execution Server实例。 多个对等节点使应用程序和规则执行功能都高度可用。

    使用Hyperledger Fabric和Hyperledger Composer的Docker镜像,通过Docker Compose部署区块链节点。

    下图显示了服务于多个区块链应用程序的对等节点的典型架构:

    服务几个区块链应用程序的对等节点的典型架构的图示

    部署Hyperledger Fabric和Hyperledger Composer

    作为区块链应用程序开发框架,Hyperledger Composer提供了必要的脚本来建立Hyperledger Fabric和Hyperledger Composer区块链基础架构。 该基础结构被部署为一组Docker容器,这为您部署业务网络基础结构提供了很多灵活性。

    有关如何在您自己的机器或一组机器上设置正在运行的区块链基础结构的信息,请参见Hyperledger Composer文档

    部署IBM ODM规则执行服务器

    本文中的示例使用两个新组件补充了Hyperledger Fabric和Hyperledger Composer基础结构:IBM ODM Rule Execution Server和Deployer流程。 Rule Execution Server在智能合约中执行决策(业务规则),而Deployer支持通过区块链部署业务规则。

    部署程序与Rule Execution Server管理API进行交互。 您可以将其视为Rule Execution Server的专用外观,它提供智能合约调用的A​​PI。

    要在基于Docker的Hyperledger Fabric基础架构中运行Rule Execution Server,请将其打包为Docker映像。 请参阅使用Docker Compose部署IBM Operational Decision Manager拓扑

    Vehicle Lifecycle示例的odm-runtime组件包含用于构建IBM ODM Docker映像的Docker文件,以及有关如何将Rule Execution Server部署到Hyperledger Fabric和Hyperledger Composer默认基础结构的说明。

    Vehicle Lifecycle示例的odm-deployer组件包含此部署外观的Node.js实现。 智能合约使用它来部署Java可执行对象模型(XOM)和智能合约所引用的决策服务所使用的规则。

    在区块链业务网络中部署并运行Rule Execution Server Docker映像和Deployer Docker映像之后,可以实施利用IBM ODM功能的基于规则的智能合约。

    Hyperledger Composer中的车辆生命周期数据模型

    Hyperledger Composer具有用于表示数据和定义事务处理逻辑的几个概念:

    • 参与者代表通过交易与区块链应用程序进行交互的参与者 。
    • 资产对要存储在区块链中的项目进行建模。 它们通常代表由交易操纵的有价值的东西。
    • 交易代表从参与者发起的与一项或多项资产相关的在区块链分类账上注册的实际交易。
    • 当在区块链上发起交易并且区块链的所有节点都对其进行验证并产生副作用时,将使用交易处理器 。 在Hyperledger Composer中,交易处理器回调在区块链的所有节点中被调用。 共识算法检查所有节点是否以相同的方式处理事务,从而确保分类账和世界状态数据库的更新一致。

    Hyperledger Composer中使用专用的高级语言描述了参与者,资产和交易。 事务处理器被实现为可操纵资源JavaScript函数。

    有关Hyperledger Composer应用程序的更多信息,请参阅Hyperledger Composer文档中的业务网络定义

    Hyperledger Composer Playground Web用户界面使您可以浏览不同资源的数据模型以及事务处理器JavaScript代码。

    参加者的例子

    以下代码描述了Person的模型,在此示例中,该模型是可以购买或出售Vehicle

    描述人员模型的代码段的屏幕截图

    您可以使用REST API或通过特定交易在区块链数据库中创建Person实例。 它们存储为JavaScript Object Notation(JSON)文档。 例如,以下文档描述了一个名为Dan的Person

    描述一个名为Dan的Person的JSON文档的屏幕截图

    资产示例

    此示例操作的主要资产是Vehicle ,如以下屏幕截图所示。 描述车辆的对象模型非常复杂,因为它需要考虑涉及车辆的各种交易范围中使用的所有属性。

    描述车辆资产的代码段的屏幕截图

    Vehicle的实例表示为JSON文档。 Hyperledger Composer Playground的以下屏幕截图中对此进行了描述,其中显示了Vehicle注册表:

    Composer Playground的屏幕截图,显示了Vehicle注册表的JSON文档

    交易范例

    Vehicle所有权从一个Person到另一个Person转移是作为在区块链上注册的交易执行的。

    如以下屏幕截图所示, PrivateTransferTransaction类在Hyperledger Composer中表示此事务:

    屏幕快照,描述了Hyperledger Composer中的PrivateTransferTransaction类的代码段

    以下JSON文档表示此事务的一个示例:

    JSON文档的屏幕截图,显示了所有者转让交易的示例

    您可以在车辆生命周期示例model文件夹中找到此示例的数据模型,在不同的.cto文件中.cto进行了描述。

    IBM ODM中的Vehicle Lifecycle数据模型

    您还需要对数据建模,以便IBM ODM中的业务规则可以使用它。 IBM ODM表示三层数据:

    • Java可执行对象模型(XOM),在此示例中作为一组Java类实现。 该模型表示规则引擎内部用于应用决策逻辑的数据。
    • 业务对象模型(BOM),它以更抽象的级别表示数据模型。 通常,BOM反映XOM,但是您可以定义更多对业务友好的概念和方法,以支持业务涉众用来指定决策逻辑的自然语言。
    • 商业词汇。 该特定于语言的层允许您定义业务术语以及引用业务规则中数据的短语。

    您可以在IBM ODM Rule Designer中定义不同的层。 请参阅IBM ODM文档以获取更多信息。 设计业务对象模型描述了XOM,BOM和词汇表概念。

    例如, Vehicle由XOM中的以下Java类表示:

    该代码段的屏幕截图显示了XOM中的Vehicle表示为Java类

    Vehicle由以下BOM类及其英语语言表示:

    BOM的车辆表示形式(带英语口语)的屏幕截图

    通常,数据模型是在Hyperledger Composer中创建的,并且Java开发人员会创建基于Java的实现,并将其用作XOM。 Java开发人员与Rule Designer中的业务分析师合作,从基于Java的XOM开始创建BOM和词汇表。

    请注意,Hyperledger Composer提供了一种从域模型的cto文件生成Java表示的工具(这可能是构建XOM的良好起点)。

    有关此功能的更多信息,请参见示例的vehicle-lifecycle-xom目录中的README文件。

    IBM ODM V8.9.x支持Jackson从JSON序列化和反序列化Java对象模型。 JSON用作HyperLedger Composer智能合约和IBM ODM决策服务之间的数据交换格式。

    为了确保Hyperledger Composer事务处理器和IBM ODM决策服务可以轻松交换数据,在Hyperledger Composer中实现的数据模型必须与决策服务中使用的XOM相匹配,这一点至关重要。

    请参阅vehicle-lifecycle-xom的Java实现以了解应如何实现XOM,以允许Hyperledger Composer与IBM ODM之间的数据平滑交换。

    所有权转让交易的生命周期

    为了说明区块链应用程序和IBM ODM如何协同工作,请考虑两个Person之间的买卖交易的情况。

    要执行此业务交易,系统需要将VehicleTransferTransaction与关于Vehicle ,卖方和买方的所有信息一起发布到VehicleTransferTransaction链。

    假定交易受检查交易是否欺诈的规则支配。 这些规则的逻辑很复杂,由专家定义。 当发现新的欺诈模式时,专家(业务利益相关者)希望快速更改规则,以在将欺诈性交易提交到区块链后立即自动识别。

    交易过程如下图所示:

    通过区块链网络进行交易的过程示意图
    • 外部系统可以是业务流程或应用程序,它使用Hyperledger Composer为该区块链应用程序生成的REST API来推动PrivateVehicleTransfer事务。
    • 交易由Hyperledger Fabric分发到区块链中的所有节点。
    • 每个对等节点触发此区块链应用程序的链码(智能合约)以检查交易并应用由智能合约实现的逻辑。
    • 链码触发在区块链应用程序中定义的Hyperledger Composer事务处理器回调。
    • 事务处理器JavaScript代码对Rule Execution Server进行外部REST调用,该规则执行服务器将业务规则保存在决策服务中,并传递决策所需的数据。
    • 业务规则将应用于事务并由规则引擎执行。
    • 响应将发送回Hyperledger Composer回调。
    • 回调根据响应执行操作,拒绝交易或验证交易,并在发生可疑交易时提供额外的信息。

    请注意,本文重点介绍Hyperledger Composer JavaScript回调之间的交互,该回调将所有以业务为中心的逻辑委托给IBM ODM。 有关如何向Hyperledger Fabric提交事务或如何由区块链处理事务的信息,请参阅Hyperledger Composer和Hyperledger Fabric文档。

    致电决策服务

    Hyperledger Composer链代码与IBM ODM规则引擎不在同一进程中运行,因此这两个进程通过REST调用进行通信。

    Hyperledger Composer提供了一个API,您可以使用该API在链代码外执行POST REST调用,传递当前事务以及所需的任何其他资产或参与者数据。 Hyperledger Composer将作为参数传递给REST调用的资源转换为JSON文档。

    IBM ODM将决策服务作为REST API公开,可以采用描述请求有效负载的JSON有效负载。

    例如,下面的Hyperledger Composer事务处理器使用决策服务来确定给定的事务是否是欺诈性的,如以下代码所示:

    /**
     * Transfer a vehicle to another private owner
     * @param {org.vda.PrivateVehicleTransfer} privateVehicleTransfer - the PrivateVehicleTransfer transaction
     * @transaction
     */
    function privateVehicleTransfer(privateVehicleTransfer) {
      ...
    }

    JavaScript代码知道哪个决策服务实现了需要执行的决策。 作为对等节点执行环境的一部分,Rule Execution Server正在运行,准备通过REST API接收请求。

    在回调中使用以下代码来调用决策服务:

    var rulesetPath = ruleappName + "/" + currentRuleappVersion + "/" + rulesetName + "/" + currentRulesetVersion;
            // this is where we're calling out to a Decision Service to determine of the transaction is suspicious or not
            // The Decision Service returns a 'status' and a 'message'. 'status' could be ACCEPTED, REJECTED, SUSPICION.
            // If REJECTED, the transaction should abort with the 'message' indicating why. If SUSPICION, the 'message'
            // should be assigned to the Vehicle.suspiciousMessage field
            // The Decision Service receives all the data about the current transaction: buyer, seller and the vehicle
    
            var url = 'http://odmruntime_odm-runtime_1:9060/DecisionService/rest/' + rulesetPath;
    
            var dsCallObject = factory.newResource(NS_DECISION, 'IsSuspiciousTransferDecisionService', "isSuspiciousTransfer");
            dsCallObject.transaction = privateVehicleTransfer;
    
            print("Calling ODM Decision Service: " + url);
            return post( url, dsCallObject, {permitResourcesForRelationships: true, deduplicateResources: true});

    您可以在vda.js看到此示例的代码。

    此回调处理的事务包装在专用对象中,并传递给调用。 引入包装器对象是为了使Hyperledger Composer发送的JSON有效负载与决策服务期望的请求有效负载匹配,这取决于IBM ODM中指定的决策服务签名。 例如,决策服务签名可以具有多个输入参数,所有输入参数都必须是请求有效负载中的条目。

    以下有效负载中的transaction条目与IBM ODM的决策操作中指定的transaction输入参数匹配。

    PrivateVehicleTransfer交易指向买方,卖方和车辆时,整个对象图被序列化为JSON文档。 调用Hyperledger Composer post() API时,它将发送到决策服务。 对于此事务,将生成以下JSON代码:

    {
        "$class": "org.acme.vehicle.lifecycle.decision.IsSuspiciousTransferDecisionService",
        "$id": "resource:org.acme.vehicle.lifecycle.decision.IsSuspiciousTransferDecisionService#isSuspiciousTransfer",
        "dsId": "isSuspiciousTransfer",
        "transaction": {
            "$class": "org.vda.PrivateVehicleTransfer",
            "$id": "resource:org.vda.PrivateVehicleTransfer#4302c409-96f1-4660-9772-400875e5e2e2",
            "seller": {
                "$class": "composer.base.Person",
                "$id": "resource:composer.base.Person#dan",
                "ssn": "dan",
                "firstName": "Dan",
                "lastName": "Selman",
                "gender": "MALE",
                "nationalities": [
                    "French",
                    "UK"
                ],
                "contactDetails": {
                    "$class": "composer.base.ContactDetails",
                    "email": "dan@acme.org",
                    "address": {
                        "$class": "composer.base.Address",
                        "city": "Winchester",
                        "country": "UK",
                        "region": "England"
                    }
                }
            },
            "buyer": {
                "$class": "composer.base.Person",
                "$id": "resource:composer.base.Person#anthony",
                "ssn": "anthony",
                "firstName": "Anthony",
                "lastName": "Smith",
                "gender": "MALE",
                "nationalities": [
                    "French"
                ],
                "contactDetails": {
                    "$class": "composer.base.ContactDetails",
                    "email": "anthony@acme.org",
                    "address": {
                        "$class": "composer.base.Address",
                        "city": "Paris",
                        "country": "France",
                        "region": "IDF"
                    }
                }
            },
            "specialNotes": "Dan selling a car to Anthony Smith",
            "vehicle": {
                "$class": "org.vda.Vehicle",
                "$id": "resource:org.vda.Vehicle#156478954",
                "vin": "156478954",
                "vehicleDetails": {
                    "$class": "org.vda.VehicleDetails",
                    "make": "Arium",
                    "modelType": "Nova",
                    "colour": "white",
                    "vin": "156478954",
                    "taxationClass": "PETROL_CAR"
                },
                "vehicleStatus": "ACTIVE",
                "owner": "resource:composer.base.Person#dan",
                "logEntries": [
                    {
                        "$class": "org.vda.VehicleTransferLogEntry",
                        "vehicle": "resource:org.vda.Vehicle#156478954",
                        "buyer": "resource:composer.base.Person#dan",
                        "timestamp": "2017-07-30T13:57:13.652Z"
                    }
                ]
            },
            "transactionId": "4302c409-96f1-4660-9772-400875e5e2e2",
            "timestamp": "2017-07-30T13:57:23.121Z"
        }
    }

    决策服务的XOM应该支持此有效负载。 Hyperledger Composer首先对对象进行序列化,然后引用已通过ID序列化的对象。 XOM中的特定JSON批注允许处理对象图反序列化。 请参阅vehicle-lifecycle-xom项目的代码。

    确保您调用正确版本的决策服务,因为决策逻辑可能会独立于智能合约中的代码而发展。 区块链网络的所有节点必须使用相同版本的决策逻辑。 生命周期说明中介绍了一种管理决策逻辑版本的方法。

    决策服务返回描述该决策操作的JSON文档。 如果输入的JSON文档的格式由Hyperledger Composer驱动,并且由Blockchain应用程序的数据模型的形式驱动,则答案的格式是免费的,并由IBM ODM决策服务控制。 在本文的示例中,如果存在可疑事务,则决策服务将返回JSON有效负载,如以下代码所示:

    {
        "status": "SUSPICION",
        "message": "Cross Border Suspicious Transfer: please double check buyer regulation"
    }

    交易处理器使用该响应来根据决策服务已采取的业务决策对交易进行处理。 在以下示例中,决策结果被写入Vehicle资产。

    .then(function (response) {
      if (response.body.result['status'] != null) {
        if (response.body.result.status === "REJECTED") {
    vehicle.suspiciousMessage = "REJECTED: " + response.body.result.message;
        } else if (response.body.result.status === "SUSPICION") {
          vehicle.suspiciousMessage = response.body.result.message;
        }
      }
    }

    实施决策逻辑

    决策逻辑被实现为常规的IBM ODM决策服务。 您可以为决策服务定义多个入口点,以适应需要在智能合约中委派给IBM ODM的不同业务决策。 入口点(对应于IBM ODM中的决策操作)是专用规则集,它具有签名并包含表示为业务规则的决策逻辑。

    决策的输入参数通常是Hyperledger Composer的事务,指的是您需要为决策完成的资产,参与者或历史事务。 如果需要传递更多数据,则需要在Hyperledger Composer(资产或概念)中为专用资源对象建模,然后在调用决策服务之前将其填充在事务处理器中。

    输出参数是一个对象,用于保存决策和返回智能合约所需的所有数据。

    在本文的示例中,入口点由以下屏幕截图中的决策操作定义:

    该可疑交易的决策操作的屏幕截图

    通过此决策操作创建的REST API在调用post API时支持Hyperledger Composer序列化的JSON输入。

    输出参数是具有statusmessage的数据结构,该数据结构由业务规则填充,并作为JSON文档返回给调用方。

    该示例中的决策逻辑很简单:规则流,业务规则和决策表,如以下三个屏幕截图所示。

    IBM ODM Rule Designer中的规则流:

    IBM ODM Rule Designer中的规则流的屏幕截图

    IBM ODM Rule Designer中的业务规则:

    IBM ODM Rule Designer中的业务规则的屏幕截图

    IBM ODM Rule Designer中的决策表:

    IBM ODM Rule Designer中的决策表的屏幕截图

    IBM ODM允许您所需的复杂决策逻辑。 由成千上万个规则组成的决策逻辑是常见的,并且IBM ODM易于支持。 本文中的示例主要使用Rule Designer编写决策逻辑,但是您也可以使用Decision Center定义和管理业务逻辑。 寻找有关利用Decision Composer实施决策逻辑和协作管理业务规则生命周期的未来内容。

    注意,可以在IBM ODM BOM编辑器中完全指定规则中使用的业务词汇。 例如,在此示例中,Hyperledger Composer提供的数据模型非常冗长,具有多个嵌套级别。 BOM适用于实施快捷短语以隐藏这种复杂性。 在示例中, Person概念具有一个额外的getCountry()方法,该方法隐藏了查找国家/地区信息的潜在复杂性,如以下屏幕截图所示:

    添加了BOM表方法的屏幕截图,以简化规则中与国家/地区的合作

    决策逻辑生命周期

    区块链是一种运行时环境,在这种环境中,通过设计,分配和控制机制来确保通过智能合约进行的交易处理能够确保账本的一致性和安全性。

    当交易提交到Hyperledger Fabric时,它被分派到区块链网络的所有节点,并且智能合约的多个实例适用于处理交易。 这些智能合约的所有实例必须返回其控制的资产的相同更新集,并且它们必须对交易的有效性做出相同的决定。 因此,所有节点都必须具有委派给IBM ODM的相同版本的决策逻辑,这一点很重要。 同样,就像智能​​合约代码在区块链内部是防篡改一样,重要的是没有人可以篡改业务规则。

    由于这两个原因,无法通过通常与IBM ODM一起使用的典型部署过程来处理部署决策逻辑的新版本。 由于所有节点都有自己的Rule Execution Server的隐藏实例和私有实例,因此从Rule Execution Server控制台,Rule Designer或Decision Center(或通过IBM ODM API中的任何其他集中管理的API)进行的部署不适用于区块链案件。

    vehicle-lifecycle示例具有专用的部署机制,该机制使用区块链的功能来确保所有节点具有相同版本的逻辑。

    特定资产和交易将添加到应用程序中以存储和管理规则集。 您可以在vehicle-lifecycle项目的odm.ctoodm.js中看到它们的实现。

    决策逻辑的更新被视为区块链交易。 当决策逻辑更改时,IBM ODM会生成新版本的规则集归档文件。 该归档文件的二进制文件及其版本号通过事务提交到区块链,如以下代码所示:

    transaction RuleAppUpdated identified by transactionId
    {
      o String transactionId
      o String resDeployerURL
      // ruleapp name should be of the form <ruleapp>/<ruleset>
      o String ruleAppName
      o String ruleapp_version
      o String ruleset_version
      o String archive
      o String managedXomURI
    }

    专用交易处理器处理每个区块链节点上的交易。 它执行以下三个操作:

    • 它将档案存储在由区块链控制的世界状态数据库中:
    asset RuleApp identified by ruleAppId
    	{
    	  o String ruleAppId
    	  // ruleapp name should be of the form <ruleapp>/<ruleset>
    	  o String ruleAppName
    	  o String ruleapp_version
    	  o String ruleset_version
    	  o String archive
    	}
    • 它编写用于特定资产中特定决策服务的RuleApp或规则集的当前版本( RuleAppCurrentVersion ):
    asset RuleAppCurrentVersion identified by ruleAppName
    	{
    	  // ruleapp name should be of the form <ruleapp>/<ruleset>
    	  o String ruleAppName
    	  o String ruleapp_version
    	  o String ruleset_version
    	}
    • 它通过Deployer外观将RuleApp或规则集部署到该节点的Rule Execution Server中,同时传递Archive二进制文件和版本信息。

    为了知道要使用哪个版本的规则集,事务处理器在调用决策服务时会从该特定资产中查找此信息,并使用它来对REST API进行参数化。

    如果出了什么问题,并且需要回滚RuleAppUpdated事务,则还会回滚“ Current Version资产,并且仍使用决策服务的先前版本。 然后,将最新版本的规则集部署到Rule Execution Server,但从不使用它。

    该机制可以避免在分类帐中直接存储大型二进制RuleApp。 分类帐可以使用哈希码签名存储对Ruleapp的引用,智能合约可以使用哈希码签名来检查二进制文件是否被修改。

    请注意,决策逻辑高度依赖于支持业务规则的XOM。 该示例中说明了一种类似的机制,用于将XOM部署到在区块链中运行的各种Rule Execution Server。

    决策逻辑管理与治理

    使用IBM ODM进行智能合约的一个主要优势是广泛的工具,业务涉众可以使用这些工具来管理和管理智能合约的决策逻辑。 根据市场每周甚至每天的变化或其他因素,决策逻辑通常比应用程序的其余部分发展得更快。

    重要的是,有关各方的代表可以控制智能合约中的逻辑。 如果智能合约执行具体的合同来规范当事方如何交换资产和价值,则他们必须就规则和生命周期达成共识。

    例如,当事方可能决定一起审查规则,协商内容,并商定何时应部署这些规则。 该协议可能需要一个定义明确的治理流程,并需要各方进行不同级别的审查和批准。

    IBM ODM excels in this area with the Decision Center and its business console, shown in the following screen capture:

    Screen capture of a decision table in the business console of the IBM ODM Decision Center

    Even though rule execution is necessarily distributed for a blockchain platform, you can centralize the management environment, which makes it easier for the business stakeholders of each party to collaborate on defining and managing the decision logic of their blockchain application.

    One of the core principles of IBM ODM is bringing together business stakeholders (including policy managers, analysts, lawyers, accountants, auditors) by giving them tools to express and govern the decision logic of their applications in terms they are comfortable with.

    Look for an upcoming article that focuses on how you can use Decision Center, coupled with a specific DevOps process, to manage and deploy the logic of smart contracts implemented with IBM ODM.

    结论

    IBM ODM is ideal for expressing and governing the rules in a smart contract. When you define a smart contract, the business stakeholders are necessarily involved, and by separating the rules of the smart contract from the application code, the business stakeholders from both parties can use tools like Decision Center to collaborate to define and govern them. They can also respond quickly to change and avoid the time-consuming processes of updating code bases.

    The Vehicle Lifecycle sample illustrates how you can use IBM ODM with Hyperledger Fabric to execute the smart contract decision logic "in-chain" and take advantage of the enterprise-class rule engine of IBM ODM.

    For your next blockchain project, consider IBM ODM for your smart contracts. It is a natural fit with Hyperledger Composer and the blockchain environment. The strengths of IBM ODM become particularly important as you bring the business stakeholders closer to the process, and look for ways to quickly respond to change.

    We are eager to hear about your experiences and any additional requirements you might have for integrating IBM ODM and blockchain. You can connect with us on Twitter or email, or add a comment at the bottom of this article.

    致谢

    Many thanks to the Hyperledger Composer team members for their extraordinary help and responsiveness in supporting this integration. Special thanks to Simon Stone on the IBM Blockchain team for his continuous support.

    We also would like to thank Laurent Grateau, Philippe Bonnard, and Jeremy Pichon for their contribution to the sample supporting this article, and Peter Gilliver and Nicolas Sauterey for their attentive reviewing of this article.


    翻译自: https://www.ibm.com/developerworks/library/mw-1708-mery-blockchain/1708-mery.html

    展开全文
  • 区块链 智能合约应用.pdf
  • 区块链 智能合约 简介.pdf
  • 区块链智能合约介绍

    千次阅读 2020-08-05 11:12:19
    作者:qinyutong、chengyueqiang智能合约 (smart contract) 是一种由事件驱动的、具有状态的代码合约和算法合同 [11],随着以比特币为代表的区块链技...

    作者:qinyutong、chengyueqiang

    智能合约 (smart contract) 是一种由事件驱动的、具有状态的代码合约和算法合同  [11],随着以比特币为代表的区块链技术的蓬勃发展, 区块链技术已经开始逐步超越可编程货币时代而进入智能合约时代。智能合约作为区块链的核心部分,在技术中得到广泛应用,也是令区块链成为具有一定颠覆性技术的原因之一。本文通过对智能合约的背景知识以及流程介绍,总结出当前智能合约的特点和应用领域,从而为区块链智能合约技术的发展提供一定参考。

     

    1   引言

    区块链利用分布式节点共识算法对数据进行生成和更新,使用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算范式[10],本身具有去中心化的特性。

    区块链的发展主要分为三大阶段[6],第一阶段为以比特币为首的可编程货币,第二阶段为以智能合约为首的可编程金融,第三阶段为以去中心化应用为首的可编程社会。比特币发展迅速,区块链发展阶段逐渐向第二阶段过渡,以以太坊为首的智能合约技术得到了广泛关注。

    1995 年,由密码学家 Szabo 提出智能合约这一概念,由于当时缺少可信的执行环境,智能合约并没有被应用到实际产业中。比特币诞生后,由于比特币的底层技术区块链具有去中心化的特性,满足智能合约所需的可信的执行环境,区块链可以提供参与的各个节点的互信。

    智能合约是一种计算机协议,在协议制定和部署后,不需要外加人为干预,即可实现自我执行和自我验证[4]。从技术角度来说,智能合约可以被看作一种计算机程序,这种程序可以自主地执行全部或部分和合约相关的操作,并产生相应的可以被验证的证据,来说明执行合约操作的有效性。在部署智能合约之前,与合约相关的所有条款的逻辑流程就已经被制定好了。智能合约通常具有一个用户接口,以供用户与已制定的合约进行交互,这些交互行为都严格遵守此前制定的逻辑。得益于密码学技术,这些交互行为能够被严格地验证,以确保合约能够按照此前制定的规则顺利执行,从而防止出现违约行为。

    表 1: 传统合约和智能合约的比较

     智能合约是在传统合约基础上对安全性、唯一性进行改进的一种合约,用数字形式定义的承诺来保障合约参与者的协议安全可靠。

    区块链的智能合约最早建立在以太坊,用一段代码来实现条款在处理硬件和软件中的应用,这段代码运行在以太坊的虚拟机中,按照特定程序执行操作,在相应的时间节点完成条款内容。

    以太坊是一个开源的具有智能合约功能的公共区块链平台,以太坊项目借鉴了比特币区块链的技术,对它的应用范围进行了扩展。如果说比特币是利用区块链技术的专用计算器,那么以太坊就是利用区块链技术的通用计算机。简单地讲,以太坊 = 区块链 + 智能合约。

    与比特币相比,以太坊最大的不同点是:它可以支持更加强大的脚本语言,即使用一套图灵完备的脚本语言来建立应用,允许开发者在上面开发任意应用,实现任意智能合约,这也是以太坊的最强大之处。作为平台,以太坊可以类比于苹果的应用商店,任何开发者都可以在上面开发应用,并出售给用户。

     

    2         智能合约类型

    智能合约分为广义智能合约和狭义智能合约。广义的智能合约是指运行在区块链上的计算机程序,适用范围较广。狭义的智能合约是运行在区块链基础架构上,基于约定规则,由事件驱动、具有状态、能够保存账本上资产,利用程序代码来封装和验证复杂交易行为,实现信息交换、价值转移和资产管理,可自动执行的计算机程序[9]。

    2.1       脚本型智能合约

    将比特币中的智能合约称为脚本型智能合约。由于比特币中的脚本仅包含指令和数据两部分,其中涉及到的脚本指令只需要完成有限的交易逻辑,不需要复杂的循环、条件判断和跳转操作,功能有限但编写较为容易,支持的指令不到 200 条。

    2.2       图灵完备型智能合约

    将主要运行在以太坊和超级账本中的智能合约称为图灵完备型智能合约。脚本语言被设计成为仅在有限范围内执行有限功能的简单执行语言,是非图灵完备的语言。使用脚本语言编写的交易指令虽然能够满足比特币应用,但无法适应以太坊平台的开发需求。目前,以太坊主要使用 Solidity 和 Serpent 两种智能合约开发语言。

    2.3       可验证合约型智能合约

    将正在研发中的 kadena项目中的智能合约称为可验证合约型智能合约。可验证语言的语法类似于 Lisp语言,用于编写运行在区块链 Kadena上的智能合约,可实现合约的数据存储和授权验证等功能。为防止在复杂合约的编程过程中可能存在的安全漏洞以及因此而带来的风险,可验证合约型语言采用非图灵完备设计,不支持循环和递归。该语言编写的智能合约代码可以直接嵌入在区块链上运行,不需要事先编译成为运行在特定环境(如以太坊 EVM)的机器代码。

     

    3         智能合约语言

    3.1       Solidity

    Solidity 可以用来开发合约并编译成以太坊虚拟机字节代码,运行在Etheream 虚拟机(EVM)之上。是静态类型语言,支持继承、库和复杂的用户定义类型等特性。虽然 Solidity 语法与  Javascript 较为接近,是一种面向对象的语言,但是两者又有许多不同:

    1. 由于语言内嵌框架是支持支付的,所以可以提供如payable之类的关键词,实现在语言层面直接支持支付,更为简便;

    2. 由于以太坊底层是基于账户而非 UTXO,故存在特殊类型Address,可以用于定位用户和合约,并定位合约的代码;

    3. 由于智能合约是将原来的一个简单函数调用变成了网络节点中的代码执行,故在去中心化的网络运行环境中,会更加强调合约或函数执行的调用方式;

    4. 由于为了保证合约执行的原子性,以避免中间状态出现的数据不一致,Solidity的异常机制一旦出现异常,所有执行都会被回撤。

    常用的 Solidity  集成有  Remix、Visual studio  Extension  等。以编译器  Remix  为例,Remix  是基于浏览器的IDE,集成了编译器和 Solidity运行时的环境,不需要额外的服务端组件。这里用 Solidity开发“HelloWorld”。

    可以看到,在 decoded output 中返回 HelloW orld ! 。

    图1: 使用Solidity 开发“Hello World”

    3.2       Serpent

    Serpent和Python 类似,使用用 LLL 编译,最终会被编译为 EVM 字节码。可以用于开发合约编译成以太坊虚拟机字节代码。Serpent 是一种分组加密算法,更加简洁,将低级语言在效率方面的优点和编程风格的操作简易相结合,同时合约编程增加了独特的领域特定功能。

     

    3.3       Lisp LikeLanguage

    LispLikeLanguage(LLL)是和 Assembly类似的低级语言。更为简单,本质上只是直接对以太坊虚拟机的一点包装。是一门 Lisp风格的底层编程语言,持续更新,并且与 Solidity同属一个资源库。

     

    4         智能合约运行机制

    以以太坊开发平台为例,智能合约运行机制主要包含以下阶段:

    1. 生成代码:智能合约一般具有值和状态两个属性,代码中用If-Then和What-If语句预置了合约条款的相应触发场景和响应规则,在合约各方面内容都达成一致的基础上,评估确定该合同是否可以通过智能合约实现,即“可编程”,然后由程序员利用合适的开发语言将以自然语言描述的合同内容翻译为成为可执行的机器语言;

    2. 编译:利用开发语言编写的智能合约代码一般不能直接在区块链上运行,而需要在特定的环境(以太坊为 EVM, 超级账本为 Docker容器)中执行,所以在将合约文件上传到区块链之前需要利用编译器对原代码进行编译,生成符合环境运行要求的字节码。;

    3. 提交:智能合约的提交和调用是通过“交易”完成,当用户以交易形式发起提交合约文件后,通过  P2P  网络进行全网广播,各节点在进行验证后存储在区块中;

    4. 确认:被验证后的有效交易被打包进新区块,通过共识机制达成一致后,新区块添加到区块链的主链。根据交易生成智能合约的账户地址,之后可以利用该账户地址通过发起交易来调用合约,节点对经验证有效的交易进行处理,被调用的合约在环境中执行。

     

    图 2: 合约运行机制

    5         智能合约项目

    最简单的合约是:信息上传区块链——双方签字确认——双方达成共识——合约被存储。

    图 3: 合约基本模型

    Language   Language  是一种安全稳定的分布式语言,符合  Szabo  对智能合约设计理念的特点,所有的远程通信会被加密。

    Hawk Hawk 是一种去中心化的智能合约系统,是一个用智能合约构建隐私保护的框架[2],在这个系统中不会以明确的方式将金融交易存储在区块链中,Hawk 编译器负责将程序编译为区块链和用户之间的加密协议。

    OpenBazzar    OpenBazzar  平台是一家利用比特币进行交易的去中心化电商平台,是一个开源平台,直接将用户与用户连接开展交易,实现点对点交易网络,买卖双方可以直接进行交易,不需要借助中心化平台,保证了隐私。

    Ethereum    Ethereum  是具有图灵完备编程语言的区块链平台,包含了公有链和私有链,可以创建任何应用。使用共识机制中的 PoW 机制,拥有更高的处理速度和精度,可以在没有处理所有交易的情况下验证应用状态,目标成

    为分布式应用平台的脊梁。但区块的构造时间受到交易处理速度的影响,建块速度受到很大影响。

    Codius  Codius 是由 Ripple 实验室发布的智能协议,具有去中心化、安全性高等特点,可以实现点对点交易网络,是一种开源平台,应用于 Ripple 平台上,实现的功能是引导货币流通。

    Hyperledger Hyperledger是一种 Linux 基金会下的区块链开源平台,以容器的形式运行智能合约,具有较高安全性。

     

    6         智能合约基本特点

    6.1       优势

    可信性 智能合约的承诺包含两方面,一是自动,无需信任和公正地执行合约;二是直接,在合约执行的各个环节中取消中间人这一角色[5]。智能合约的所有条款和执行过程是提前制定好的,并由计算机绝对执行。因此所有执行的结果都是准确无误的,不会出现不可预料的结果。

    交易无需第三方  智能合约不需要中心化的权威来仲裁合约是否按规定执行,合约的监督和仲裁都由计算机来完成[1]。在一个区块链网络中一般不存在一个绝对的权威来监督合约的执行,而是由共识机制来判断合约是否按规定执行,监督方式通常由PoW 或 PoS 技术实现。由于智能合约的数字化特点,数据被存储在区块链中,使用加密代码强制执行协议,保证交易可追踪和不可逆转。

    高效的实时更新  由于智能合约的执行不需要人为的第三方权威或中心化代理服务的参与,其能够在任何时候响应用户的请求,大大提升了交易进行的效率。用户只需通过网络对业务进行办理,节省了人力、物力。

    更低成本 智能合约具有去人为干预的特点,其能够大大减少合约履行、裁决和强制执行所产生的人力成本,要求合约制定人能够将合约的各个细节在合约建立之初就确定下来。

    6.2       目前存在的问题

    不可撤销性 智能合约自动履行合约内容,但在现实生活中,合同可能会因为一些不可抗力、违法等原因解除。合同法中,对于合同的要求是避免律师预测和协商可能出现结果的灵活性。但由于区块链的不可修改性,智能合约一旦触发就会自动履行,不可撤销,具有一定的僵化特性。

    法律效力 智能合约的起草需要通过第三方计算机程序员,而在合约出现问题时若判定是第三方计算机程序员的责任,那么对于错误的算法应该如何追究责任。在法律管辖权问题上,智能合约作为一种新兴合约方式,哪些法院可以受理诉讼、现有的法律条款应该如何修改等问题都是亟待解决的。

    安全漏洞 智能合约的漏洞分为交易顺序依赖漏洞、时间戳依赖漏洞、处理异常漏洞和可重入缺陷漏洞 [3],依赖性漏洞是由于智能合约的执行正确与否与以太坊的状态有关,而有效的交易可能会影响以太坊的状态。当一个新的区块含有两笔交易时,交易的先后顺序可能会引起以太坊的最终状态不同,而交易的顺序取决于矿工,从而导致智能合约的执行依赖于矿工的操作 [8]。时间戳依赖漏洞是由于某些智能合约是根据区块中的时间戳所执行的,而时间戳是由矿工根据自身的时间所设置的,若时间被攻击者所修改,可能会导致产生一定风险。在不同的智能合约相互调用时可能出现处理异常漏洞,若被调用的合约产生错误返回值却没有被正确验证时,可能会遭受到攻击。若一个函数在执行完成前被调用了数次,导致发生意料不到的行为时,可重入漏洞就可能出现,可重入缺陷漏洞是指攻击者可以利用调用了智能合约而状态未改变的中间状态对合约进行反复的调用。

     

    7         智能合约应用场景

    7.1       法律方面

    在法律层面,区块链智能合约可以被看作为智能合同[10],即运用区块链技术来实现法律合同,将书面化的法律语言转化为可被自动化执行的技术。

    以数字版权保护为例,类似于自由文化影响下的知识共享协议的开放式版权协议不断出现,如何保证版权的实用行为,是数字版权保护的核心问题。由于传统的版权保护具有时间、空间的限制,在版权登记、监管机制等方面容易受到影响,而数字版权保护的出现极大改善了这一问题,更好适应了数字资产形式变化多样、易传播的特点。

    在版权登记方面,利用区块链技术原理中计算值的唯一性和不可篡改性,对不同的作品生成不同的计算值,将计算值视为作品的一种代表方式进行关联,可以减少作品追溯和存储的成本,简化作品查询流程。

    在署名方式方面,使用数字身份对计算值对应的作品进行署名,使用加密技术对数字作品进行保护,保障作品不会被篡改。

    根据合约代码和自然语言的比例,智能合约有以下几种表现形式:1、完全以代码形式编写的合约;2、以代码和自然语言两种形式书写的合约。如果法律认为无论是以自然语言书写还是以计算机语言编写,都视为合同的书面形式,法律效力是相同的,那么两种语言编写的合约构成了完整的合同。

    智能合同可能面临的问题有,第2 种合同是以两种语言表现的,如果这两个版本合约内容上有冲突,以哪一个版本为准,无论是以自然语言版本为准还是以代码语言为准,都需要法律进一步明确并给出司法解释。

     

    7.2       金融方面

    在金融层面,因为智能合约可以在区块链中运作,从而充当很多角色。智能合约可以作为经济参与者,接受信息、存储信息,消除人工参与,降低成本,保证合约交易的高效。

    以物联网为例,当前社会物联网包括数十亿个通过互联网共享数据的节点,通过物联网、区块链以及智能合约技术的融合应用,物联网支持的物理设备或财产,如公寓、汽车、停车场、自行车等,都可以允许人们在没有中间商的情况下出租、出售或共享[7]。

    当前租房市场在押金方面存在很多争议,一些不良房东在收到押金后就卷钱跑路。将智能合约引入到租房押金中, 在所有者设定出租房屋的金额后,用户通过交易向区块链支付押金,从而触发许可,获得房屋的智能锁权限。与此同时,押金被锁定在区块链中,直到用户决定向区块链发送另一个交易来返回虚拟密钥(如支付租金),智能合约自动执行,在扣除押金中的租金后将剩余金额发送给所有者,交易完成。这一过程将缩减不必要的时间,只需要通过手机进行操作,提高效率的同时降低风险。

    但智能合约可能会带来新的金融犯罪行为和风险,例如机密信息泄漏、加密密钥被盗等犯罪行为,而当前的法院和监管机构暂时很难跟上这一技术的发展步伐,由于智能合约具有一定的复杂性,在一些消费者眼里是难以理解的,这也是智能合约实施中需要解决的问题之一。

     7.3       公益慈善

    在公益慈善层面,当前面临的最大问题是资金流向不透明,导致很多人并不会使用众筹平台来进行慈善捐款。众筹是一种通过互联网方式发布筹款项目并筹集资金的方式,众筹更为开放,具有门槛低、依靠大众力量等特点。如何解决资金信息公开透明,加强监管和监督,成为当前公益慈善的热点讨论之一。

    区块链是遗传使用密码学方法产生关联的数据块,每一个数据块中都涵盖了一定时间的交易信息,每个数据块都包含上一个块的哈希值,以用于验证其信息的有效性 [12]。智能合约可以通过代码合约实现对众筹系统价值流的控制,将众筹业务流转换为智能合约代码。区块链的不可更改和共识机制保证了数据的真实和可靠性,可以提高众筹平台的公信力。

     图4: 子系统节点部署

    众筹区块链总体设计包含双数据系统、双私有链设计、高速与信誉机制、智能合约设计、审计与监督设计、可扩展链式设计。

    由于区块链的分布式存储架构,可以在不同用户处放置不同权限的节点,让不同用户参与到管理中,对于发布的消息实现可追踪和不可修改。通过不断互联,使区块链形成互联链、链中链,按照统一标准进行管理监管,解决慈善公益的监管和监督问题。

     

    参考文献

    [1]     Bartoletti, M.,and Zunino, R.  Bitml:  A calculus for bitcoin smart contracts.  pp.83–100.

    [2]    Kosba, A., Miller, A., Shi, E., Wen, Z., and Papamanthou, C. Hawk: The blockchain modelof cryptographyandprivacy-preservingsmartcontracts.pp.839–858.

    [3]    Luu, L., Chu, D.-H., Olickel,  H.,  Saxena, P.,  and  Hobor, A.  Making smart contractssmarter.  pp.254–269.

    [4]     Mourouzis, T., and Tandon,  J. Introduction to decentralization and smart contracts, 03    2019.

    [5]     Pfitzmann,  B.,  Schunter, M.,  and  Waidner,  M. Optimal efficiency of optimistic contractsigning.

    [6]     V.Buterin.  Anext-generation smart contract and decentralized application platform.  white paper     (2014).

    [7]     刘德林.  区块链智能合约技术在金融领域的研发应用现状、问题及建议. 海南金融 000, 10(2016),27–31.

    [8]    张杰. 区块链安全综述. 西安文理学院学报 (自然科学版)(2020),42–55.

    [9]    王群, 李馥娟, 王振力, 梁广俊, and 徐杰. 区块链原理及关键技术. 计算机科学与探索, 1–24.

    [10]    贺小苗. 区块链技术的应用: 智能合约及法律问题前瞻. 现代商业000, 16(2018),153–154.

    [11]    贺海武, 延安, and陈泽华. 基于区块链的智能合约技术与应用综述. 计算机研究与发展55, 11(2018),112–126.

    [12]    黄洁华, 高灵超, and许玉壮. 众筹区块链上的智能合约设计. 信息安全研究 (2017).

    *点击图片阅读《区块链共识机制介绍

    展开全文
  • 区块链与智能合约

    2019-03-15 10:00:35
    区块链与智能合约 联盟链场景中的智能合约应用 solidity 语言的常见问题
  • 就是在调用deploy()方法部署合约的时候,会弹出Metamask付款,可能出现2个问题: 第一:你的gas不够,可以参考send方法的gas设置(我是设置默认,付款的时候,修改大点)...
  • 区块链智能合约安全研究 金融安全 渗透测试 安全测试 安全建设 大数据
  • 针对传统代币中存在的公信力不足、监管困难等问题,结合区块链和智能合约技术,设计了一种去中心化的区块链代币系统。以此区块链代币系统为基础,通过部署代币合约、众筹合约,构建了一个基于区块链的众筹系统,实现...
  • 时尚智能合约 时尚区块链智能合约示例
  • 本文研究区块链智能合约的缺陷检测问题,即检测合约中是否存在部分合约方无论选择什么动作,均无法避免损失的状态。将智能合约问题转换成合约状态迁移图上的博弈策略选择冋题,提岀了基于纳什均衡理论的合约缺陷自动...
  • 智能合约安全开发 相关概念 安全事件 审计之路 常见漏洞 常用工具
  • 区块链实现智能合约

    千次阅读 2018-07-03 11:45:57
    区块链实现智能合约一、制定生成智能合约1、首先参与智能合约的用户必须先注册成为区块链的用户,区块链返回给用户一对公钥和私钥。公钥做为用户在区块链上的账户地址,私钥做为操作该账户的唯一钥匙。2、两个以两个...
  • 区块链智能合约自动化安全审计介绍   近期,区块链技术比较火,并在不同的行业有所应用,如金融、游戏、版权、溯源等,其中出现过不少的安全问题,尤其是区块链的智能合约发展至今,暴露出的问题不少,智能合约的...
  • 区块链长时间的发展过程中,区块链智能合约是一个非常重要的里程碑产物。所谓智能合约即能将参与者双方指定的条款传输到智能合约上,参与方可直接在合约上执行承诺的协议。但是要注意的是智能合约和法律条约不能划...
  • 面向大数据融合共享的区块链智能合约技术研究
  • 请问如何在一个新合约中调用上面这个拍卖合约的 leadingBid 这个变量的结果(在上面合约执行之后)?如果不能,能不能从区块中读取这个变量?很急很急,回答的好可以追加,谢谢。是调用变量,不是函数调用。就算调用...
  • 区块链是一种快速破坏性的技术,成为股票经济中的关键工具。 近年来,区块链已受到许多... 本文旨在介绍特定领域的区块链和智能合约,即房地产。 提出了智能合约的详细设计,然后研究了租赁住宅和商业建筑物的用例。
  • 针对现有的检测方法大部分为本地运行,并且存在数据封闭、单点故障、检测过程不透明等问题,考虑使用区块链技术和智能合约对网络中存在的恶意节点进行检测。所提方法基于区块链技术的去中心化和多地备份特性实现了...
  • 智能合约 (smart contract) 是一种由事件驱动的、具有状态的代码合约和算法合同 [11],随着以比特币为代表的区块链技术的蓬勃发展, 区块链技术已经开始逐步超越可编程货币时代而进入智能合约时代。智能合约作为...
  • Vitalik-在台湾的演讲:区块链、智能合约和以太坊 讲述关于区块链、智能合约和以太坊的关系

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 46,934
精华内容 18,773
关键字:

区块链合约地址