最近EOS版的Fomo 3D狼人杀游戏骗局引发了大家对EOS智能合约的安全性的大讨论。
和以太坊智能合约的不可升级不同，EOS智能合约可升级，因而保存在智能合约中的数据称不上去中心化，因为智能合约的管理员可偷偷的升级智能合约来修改合约里的任何数据。最直接的示例是EOS代币，代币分发给用户后，用户的代币持有量仍旧可以被管理员修改，那这个持有量是不安全的。由于智能合约可升级，开发者往往也没有了开源的动力，因为反正可以升级，开源又有什么意义呢？你此时看到的源码下一刻就可能被修改掉了。所以说目前所有涉及到资金的EOS代币及智能合约大家都要小心。

干掉升级

那智能合约的中心化如何来解决呢？难道EOS的智能合约只是个玩偶？显然不是，解决的方法只有一个，就是“自宫”，开发人员自己禁用掉合约的升级功能，核心就是是更改智能合约账号的权限，就像EOS启动阶段eosio.system智能合约的权限变更一样（具体可看我的文章）将智能合约权限更改为权威多签权限(eosio, eosio.prods)或者未知私钥对应的公钥。所以说其实官方已经给出了示例的，只是开发人员没跟上。

权威多签权限eosio.prods

21个超级节点多签管理权限

未知私钥

比如EOS1111111111111111111111111111111114T1Anm这个公钥，它的公钥是0值加检验数据生成的，任何人都不知道它的私钥。这个公钥在超级节点竞选时临时用过，当时只有genisisblock生产区块，eosio.system智能合约处于临时冻结状态。

组建第三方权威认证机构(DAppStore)

智能合约将权限转交给第三方权威认证机构DAppStore，该机构由顶尖技术和生态大佬组成，采取投票方式是否同意某一智能合约升级。
比如该权限，智能合约拥有者账号拥有100张投票权，第三方权威机构有100张投票权（100个成员），所以必须得到智能合约拥有者同意且50%第三方权威认证机构票数认可(即150张票)才可以升级

代码开源

自宫之后，才能谈开源，目前eospark已经支持智能合约源码验证，开发者可以将源码发布到eospark验证。这样用户能看到合约的代码，且永远是这个代码。

升级功能什么时候用

既然智能合约都要去掉升级功能，那还要升级功能干嘛？其实可以这样用

• 只要服务不涉及到资金的智能合约可以使用
• 测试阶段使用。测试阶段收集反馈，发现有问题通过升级解决。运行一段时间后，固化智能合约。

转载自：blog.csdn.net/itleaks

Live Contracts的想法一直挥之不去。以现存的李嘉图合同概念为例，它非常相似。李嘉图的合同源于20世纪90年代中期区块链技术和加密货币专家Ian Grigg所做的早期工作。

什么是李嘉图合同？

李嘉图的合同被认为是将合法有效和数字连接的文件注册到某个对象或价值的一种方式。Ricardian合同将法律文件中的所有信息以可由软件执行的格式放置。这样，它既可以是协议，也可以是在数字基础设施内安全地集成协议的协议，同时由于加密识别而提供高级别的安全性。

像普通的文本文档一样阅读

因此，李嘉图的合同对机器和人都是可读的。机器在数字基础设施中读取合同，人们将其作为纯文本文档阅读。这允许合同的所有各方正确处理其中所提供的信息。这种类型的合同将计算机语言与常规语言交织在一起，使交易成本更低：它可以有助于更快地解决争议，并且协议可以更容易地执行。

李嘉图合同的目的是什么？

李嘉图合同及其区块链技术的一个特点是其透明度。欺诈的风险可以保持在最低限度，因为使用加密哈希来完成特定数据的出版和参考。因此，代表金融交易（例如支付）的文件的数字化将在不久的将来变得越来越普遍。

李嘉图合同的定义

在20世纪90年代中期，Ian Grigg为数字资产运输的数字基础设施做出了重要贡献。这种模式被称为“里卡多”（以英国经济学家大卫里卡多的名字命名），由Systemics Inc.开发，这是一家专门从事金融交易，电子支付和密码学的美国公司。李嘉图的合同可以描述为：
“由发行人向财产所有人提交的单一文件形式的协议，其中所有者的所有权由文件的发行人管理。该文件必须清晰易读，就像传统的纸上合同一样。此外，协议必须通过程序和软件清晰可读，并使用数字密钥和服务器信息进行数字签名，并结合独特而安全的识别方法“。

英国经济学家大卫里卡多1772-1823

交易的发行和执行之间的严格分离

李嘉图的合同形成了立法与哈希函数创建的数字世界之间的联系。作为协议一部分的所有规则和条件都包含在合同中。在这样做时，交易问题及其执行是严格分开的，这反过来又有助于安全。李嘉图的合同规定了代理方之间达成的协议，因此这些方控制的程序可以执行本协议。

参考李嘉图合同的哈希值

该优惠以常规数字签名签署。通过同意涉及该合同散列的交易来接受合同。如果它涉及支付系统，则安全支付将参考该合同的散列，但也指付支付方和接收方。这种付款可以通过人工交易完成，但也可以通过智能合约进行。通过智能合约，交易的接受将基于智能合约代码进行。

隐藏的签名

有关各方签署的李嘉图合同是通过私钥完成的。合同提供者的签名被添加到文档中，该文档针对文档中描述的信息（例如属性）创建具有法律约束力且易读的提议。如果各方稍后参与李嘉图合同（例如，如果他们想要付款），则从签名的原始文档中覆盖加密“散列识别方法”。使用协议的哈希确保隐藏的签名附加到合同。

李嘉图合同和智能合约有什么区别？

智能合约是指已经达成一致且可以自动执行的一种数字协议。李嘉图合同是一种合同模型，用于记录合同的“意图”以及与合同相关的所有“行动”，甚至在合同执行之前。使用引用外部文档的哈希，Ricardian契约也可以轻松引用代码。毫无疑问，李嘉图的合同与未来的智能合约之间会有更多的交叉，交易可能会在不同的混合形式的基础上进行。

李嘉图的合同可以用于什么？

李嘉图合同可用于任何类型的协议。与智能合约不同，它不仅限于在诸如金融交易之类的简单情况下使用。李嘉道的合同用于确定代理方与另一方交易时的责任（责任）。合同代表某些商品或服务的单位。李嘉图的合同使用双方签署的协议，一旦签订合同，就不能伪造。

BowTie图

李嘉图的合同将各方之间的协议划分为时间和领域，并使用所谓的“BowTie图”。该图表以清晰的时间表显示某些风险。BowTie图表涉及谈判和起草具有法律约束力的合同，并明确了合同的所有目标。

立法

合同自动化的新解决方案可以成功，因为它们解决了法律实践中的实际问题。该技术仍处于全面发展阶段，其法律框架滞后。然而，在现有的立法框架内，李嘉图的合同已经可以接受。

LegalThings One是运行实时合同的平台。Token预售将于2017年12月6日开始。请访问livecontracts.io了解更多信息。

©与Ricardian合同相关的所有版权属于Systemics Inc.的I. Griggs先生。欲了解更多信息，请访问他的网站http://iang.org/并阅读他的白皮书http://iang.org/papers/ricardian_contract。 HTML

英文原文：https://medium.com/legalthingsone/ricardian-contracts-legally-binding-agreements-on-the-blockchain-4c103f120707

交易可以设置delay_sec来指定延迟执行的时间，在合约中也提供了相应的API。

transaction out; //构造交易
out.actions.emplace_back(permission_level{_self, N(active)}, _self, N(test), std::make_tuple()); //将指定行为绑定到该交易上
out.delay_sec = 5; //设置延迟时间，单位为秒
out.send(_next_id(), _self, false); //发送交易，第一个参数为该次交易发送id，每次需不同。如果两个发送id相同，则视第三个参数replace_existing来定是覆盖还是直接失败。

另外需要注意的是可以在合约的某行为中发自身的延迟消息，于是可以达到定时任务的循环执行。
转载自（github）

EOS专门对时间计算进行了封装，在eosiolib/time.hpp中提供了多种关于时间计算的封装，简单介绍一下time_point_sec的用法

auto time_now = time_point_sec(now()/*获取当前区块时间*/);
uint32_t five_minutes = 5 * 60;
five_minutes_later = time_now + five_minutes;
five_minutes_later > time_now;

得到的time_point_sec类型可以与uint32_t类型进行简单的加/减数值运算，同类型间也可以直接用大于/小于等比较符进行运算，满足大多数时间运算需求了已经。
转载自：github

开发的DAPP需要获取另一个帐户的EOS余额，看遍了EOS源码eosiolib下的头文件，觉得只有currency.hpp最靠谱，尝试使用该头文件下的get_balance方法，但是一直没能成功，官方又没有文档，最终放弃。后来又尝试了eosio.token/eosio.token.hpp竟然让我成功了，这里介绍一下用法：
安装eos的时候并不会把eosio.token放到你的依赖库路径下，所以需要我们自己手动链接一下依赖库

ln -s /your-eos-path/contracts/eosio.token /usr/local/include/

用的时候需要额外带上一个头文件

#include <eosio.token/eosio.token.hpp>

用起来还是很简单的

auto eos_token = eosio::token(N(eosio.token)/* 合约账户名 */);
auto balance = eos_token.get_balance(owner/* 要查的账户名 */, symbol_type(S(4, EOS)).name());
print("eos balance: ", balance.amount);

需要注意的是get_balance的第二个参数为symbol_name，而不是symbol，所以需要先symbol_type(S(4, EOS))构造出symbol后调用name()方法获取。否则会一直提示你找不到对应的余额，主要原因是在于S(4, EOS)构造出的64位无符号数中最后八位代表的是精度，而余额表中的键值不需要用到精度，所以存的时候去掉了最后8位，所以如果直接传入S(4, EOS)会查不出来。

转载自：github