LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 区块链资产 > 智能合约与传统合同有什么不同?

智能合约与传统合同有什么不同?

2019-12-19 梦洁 来源:区块链网络

实际上,比特币问世之前的1994年,Nick Szabo提出了智能合约概念,Nick Szabo是电脑科学家,也是密码学家和前华盛顿大学法学教授。由于当时技术条件不够成熟,所以智能合约没有得到广泛应用。随着比特币提出,区块链概念为大家广泛了解。而以太坊的问世使智能合约有了一个落地环境。比特币相对来说用法比较有限,只是币的转让。比特币中应用的智能合约比较简单,不够智能。以太坊出现以后,人们可针对每一个交易需求,创设一些相应的代码来实现交易,所以真正实现了一定程度的智能处理,这个时候智能合约开始得到广泛应用。智能合约广泛应用就对现有法律一些概念,一些制度也提出了一定挑战,所以我们在这里大家一起共同探讨一下,关于智能合约本质、法律性质、智能合约应用以及怎么在合同法角度进行制度完善的思考。


第一部分,智能合约本质。

首先,智能合约定义,智能合约依靠数字形式定义承诺,包括合约参与方可以在上面进行智能合约定义。智能合约构成要素要有合约主体,有主体才能自动锁定、解开智能合约中的相关商品服务。第二,智能合约涉及条款所有的操作程序,需要有参与者共同认可签署才可以执行。第三,要形成协议,需要有数字签名,通过电子形式实现,所以需要有参与者通过他们的私钥进行认证,智能合约才会被启动。第四,智能合约是数字形式,建立在去中心化区块链平台上,分布于各个节点,等待执行的一段代码。以上是对于智能合约定义。

美国统一法委员会(简称“ULC”)2019年对智能合约做了定义。ULC认为智能合约是预设条件满足的时候,区块链内状态发生改变的计算机代码。根据这个定义就可以理解,我们认为根据之前定义包括分析认为智能合约是通过把传统合同条款,通过一套计算机代码,经过编程然后形成的一套代码,代码可以组合不同代码,把智能合约形成的代码部署于区块链上,交易各方签署以后区块链上自动运行。这样满足条件的时候,智能合约可以自动抓取链上或者是链外信息,预设条件满足,计算机代码就会相应做一些执行,这个执行是自动执行,是必然会发生,而且是不可逆转。根据智能合约设置来运行,所以一旦计算机代码编制好上链,客观情况发生变化也不会做相应修改。

根据这些特点,我们倾向于认为智能合约是一个计算机代码。

智能合约法律性质,传统合同根据中国合同法,合同有成立要件,生效要件。成立要件包括合意由两个或者是两个人以上做出;生效要件包括当事人要有行为能力、意思表示真实、合同内容不违反相关法律,社会公共利益。这是对于合同法构成要件分析。智能合约是什么情况?可以把它看成经过各方当事人大家进行沟通,确定相关交易与合约履行过程当中条款和细节,把条款交给程序员,程序员通过编程转变成计算机代码实现。计算机代码编程以后最后放到区块链上,通过各方电子签名,签署确认。当预设的条件满足时,智能合约自动执行,合约处分的权益将在区块链上进行转移。从分析可以看出来传统合同法对于合同定义强调是一个合意,当事人各方合意,同时是订立合同为目的。对于智能合约关注点是自动执行,智能合约是不是可以自动执行,是不是可以抓取相关信息验证条件是否满足,同时自动执行产生所要的交易执行结果,所以强调是一个自动执行过程。如果这样来看我们就会讲代码是不是我们的法律规则,我们倾向于认为作为计算机代码智能合约,至少不能完全被认为是法律上合同。更多情况下,智能合约可以被视为是合同履行工具,或者视为合同条款补充,这样看待智能合约。

它的法律地位怎么看待?区块链具有去中心化、不可篡改特点、加上共识机制特性,为智能合约执行创造了可信环境,所以这是为什么区块链发展以后智能合约得到广泛应用。可信环境下面,智能合约视为合同履行工具和条款补充,我们就可以认为智能合约是执行代理人角色。合同当事方是智能合约用户,智能合约是独立第三方执行代理人,可以视为独立第三方,就有一点像传统交易里面涉及的监管代理人(escrow)安排,有一点是人为自动执行,预设条件满足,监管代理人判断条件是否满足,人为自动执行,通过人决定自动执行就可以。我们认为作为智能合约编撰方,技术人编写智能合约人可以收取一定技术服务费,通过智能合约落地区块链,这个链也可以收取一定基础设施费用,这个费用不管是币的方式实现或者是怎么样,我们认为如果作为独立于合同当事人的一方,可以有一个费用安排。

智能合约法律地位我们这样认为,智能合约技术出了问题,自动运行失败或者是不当造成合同当事方损失,怎么承担法律责任?智能合约本身是一个计算机代码,代码本身是中立的,不能承担责任。如果履行过程当中有出现问题,我们认为因为不管是基础设施提供者,还是智能合约编撰者,独立第三方无论是否收取相应费用,作为法律地位我们认为实际上是这种时候要承担一定法律责任,包括承担一定赔偿责任,责任承担怎么判断?计算机代码具有一定中立性,我们对于技术智能合约编撰程序员或者是基础设施链的提供方,对他们如果要他承担责任,责任边界在什么地方,是他发生故意或者是重大过失承担责任,还是其他,这是我们将要考虑问题。当然这个基础上我们接下来也还要进一步考虑,如果要他们编撰智能合约方或者是提供基础设施链方,如果承担相应责任,这个举证责任谁来承担,是不是应该按照谁主张谁举证还是编制智能合约这一方本身有能力自证清白,这是基于我们前面分析的智能合约性质,引发的对法律责任一些思考。

第三部分,法律应用。

在座很多是技术方面大咖,大家对于智能合约应用场景比较熟悉,我们传统合同关系里面一方违约另外一方寻求法院或者是仲裁机关强制执行获得救济。智能合约场景里面我们是根据预设条件自动设置,我们看看目前适用最广泛领域是数字资产交易,这个领域也是最容易通过智能合约实现自动执行的领域,尤其是比特币相对交易比较单一,合同比较简单。如果是其他涉及一些变更登记,无形资产一些转移登记,知识产权或者是股权转移登记,实际上通过智能合约也可以实现,要实现有一些条件。包括银行贷款违约,我们跟银行贷款买车,违约之后是不是可以自动设置,一旦发生违约车会被锁定不能开走,这样对于违约成本也可以有所控制,这是对未来一些应用想像。

智能合约也不是万能,具有一定的局限性。它的计算机代码性质,所以涉及到实物交付和提供劳务方面,它是不能自动执行。现行法律框架下对于房屋、机器设备、车辆船舶,需要经过登记机关转移财产所有权,经过登记机关登记生效这一部分实物,智能合约上做一个转移登记不能实现法律上转移。即便是将来如果登记可以在区块链实现,可以被法律认可,但这种情况下实物本身还有一个交付问题,所以智能合约在这一类交易上面不能完全实现整个交易自动执行。又例如提供劳务,通过智能合约也需要通过一些其他设置,配合,提供劳务的实现。比如是不是可以在劳务合同里面设置劳务成果审核制度,通过一些智能合约设置和实现奖惩安排,督促劳务提供者履行劳务合同。但是劳务合同,即便传统合同法里面劳务合同发生违约争议,要求实际履行也有一定困难,所以智能合约不能完全实现我们想要的法律效果。

针对智能合约我们有什么立法上思考?下面介绍一下美国对智能合约的立法。ULC是法官、法学教授组成的组织,美国法律制度是有联邦法州法概念,他们组成组织为各州法律适用提供指引,很多州会使用ULC提供的法律草案。1999年发布的电子交易法案,缩写为UETA,供各州参考。2000年美国联邦层面出台《关于全球和国内商业中电子签名法》,缩写为ESIGN,成为联邦层面法律。2019年1月份,ULC就智能合约法律适用问题出台指引,明确定性智能合约是计算机代码,同时也明确UETA和ESIGN是适用于应用了智能合约的电子交易和电子合同,这使得智能合约完善和电子签名得到一些法律保障。刚才说是指引,各州很可能会把它适用。

中国现行电子交易法律框架,2004年出台《电子签名法》,2015年、2019年两次修正,2005年国务院办公厅发布《国务院办公厅关于加快电子商务发展的若干意见》,2011年商务部发布《商务部“十二五”电子商务发展指导意见》。2014年1月份国家市场监督管理总局发布了《网络交易管理办法》,2018年8月份人大常委会发布了《电子商务法》,这是中国的电子交易法律框架。这样的法律框架下,从刚才一些分析包括智能合约特殊性,我们在思考中国如何对智能合约合同法方面做一些监管设想,比如考虑是不是可以出台相应立法和司法解释,明确智能合约法律适用?是不是有可能在某些登记要求方面,就需要登记生效财产权转移部分,可以逐步把登记业务转移到链上?比如说认证一些链,这样数字化的资产可以通过链做登记,实现财产转移,使得合同可以生效,如果发生争议进行诉讼或者是仲裁的时候,有一个生效的法律合同可以被强制执行。这是一个我们希望未来可以考虑的方向。

我们自己在思考,因为智能合约自动执行特性非常适合相应金融产品的设计,金融产品相对标准化,自动实行层面上可以提高很多效率,确实是可以增加金融产品流动性,对于这样的业务是不是可以推出一定监管沙盒制度,在沙盒里面对于创新项目可以进行实验,成功就可以出来,没有成功就实现有序退出,这样既是保护和鼓励创新,也能防止创新失控造成重大损失。

我们现在展望一下未来,大部分情况下,智能合约只是传统合约执行工具和补充,如果未来数字世界,资产全面数字化,我们交易也会大量的被智能合约取代,那时候智能合约不是传统工具补充,反过来传统合约是智能合约补充,对法律人员而言,编程可能就要像英语一样成为我们的必修课了

—-

编译者/作者:梦洁

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...