您正在查看: Surou 发布的文章

合约数据表字段升级

有些时候,由于前期考虑不周,或者后期设计升级,导致合约table 字段需要增加,或者类型需要更改,所以需要数据迁移,
下面举例我常用的升级方法
假设目前合约内有个table xxxinfo

struct [[eosio::table("xxxinfo"), eosio::contract("eosxxx.game")]] xxxinfo{
        uint64_t id;
        uint64_t test; // 为测试添加的字段
        uint8_t test1; // 为测试添加的字段

        auto primary_key() const { return id; }
    };

typedef eosio::multi_index<"xxxinfo"_n, xxxinfo> xxxinfo_tables;

现在升级需要解决的问题是test 当初设计字段类型过大,导致ram 浪费,test1 选型过小,增加 test2字段{uint32_t}.

在合约中增加新的表结构xxxinfo1 及其对象,并修正上面问题

struct [[eosio::table("xxxinfo1"), eosio::contract("eosxxx.game")]] xxxinfo1{
        uint64_t id;
        uint32_t test; // 为测试添加的字段
        uint16_t test1; // 为测试添加的字段
        uint32_t test2; // 为测试添加的字段

        auto primary_key() const { return id; }
    };

typedef eosio::multi_index<"xxxinfo1"_n, xxxinfo1> xxxinfo1_tables;

此时合约内同时存在 xxxinfo1 和 xxxinfo1两张表.

增加 迁移执行的action 接口

//.h
ACTION migratexxx();
//.cpp
void migratexxx(){
    xxxinfo1_tables xxxinfo1_table(_self, _self.value);

    xxxinfo_tables xxxinfo_table(_self, _self.value);
    auto itr = xxxinfo_table.begin();
    while(itr != xxxinfo_table.end()){
        xxxinfo1_table.emplace( _self, [&]( auto& h ) {
            h.id = xxxinfo1_table.available_primary_key();
            h.test = itr->test;
            h.test1= itr->test1;
        });
        itr ++;
    }
}

停止Dapp,避免迁移期间数据改变,然后执行action
cleos -u https://api.eoslaomao.com push action 合约账户 migratexxx '{}' -p 合约账户

如果数据较多,且数据是累计增长(不修改历史数据),可以分区间执行迁移,迁移过程中,可以不停止dapp,等迁移差不多追上旧表了,再暂停dapp,然后等数据全部迁移完.

修正合约中的新表为

struct [[eosio::table("xxxinfo1"), eosio::contract("eosxxx.game")]] xxxinfo{
        uint64_t id;
        uint32_t test; // 为测试添加的字段
        uint16_t test1; // 为测试添加的字段
        uint32_t test2; // 为测试添加的字段

        auto primary_key() const { return id; }
    };

typedef eosio::multi_index<"xxxinfo1"_n, xxxinfo> xxxinfo_tables;

将旧表修改为

struct [[eosio::table("xxxinfo"), eosio::contract("eosxxx.game")]] xxxinfo_bak{
        uint64_t id;
        uint64_t test; // 为测试添加的字段
        uint8_t test1; // 为测试添加的字段

        auto primary_key() const { return id; }
    };

typedef eosio::multi_index<"xxxinfo"_n, xxxinfo_bak> xxxinfo_bak_tables;

修正前后端调用的table名,重新上线,并运行dapp, 建议等 运行一段时间,在删除旧表
增加清理旧表的action

//.h
ACTION clearxxxbak();
//.cpp
void clearxxxbak(){
    xxxinfo_bak_tables xxxinfo_bak_table(_self, _self.value);
    auto itr = xxxinfo_bak_table.begin();
    while(itr != xxxinfo_bak_table.end()){
        itr = xxxinfo_bak_table.erase(itr);
    }
}

然后执行action
cleos -u https://api.eoslaomao.com push action 合约账户 clearxxxbak '{}' -p 合约账户
最后再删除 合约内旧表及对象 就完成了此次合约表升级过程.

EOS 新型攻击手法之 hard_fail 状态攻击

前言

昨日(2019 年 3 月 10 日)凌晨,EOS 游戏 Vegas Town (合约帐号 eosvegasgame)遭受攻击,损失数千 EOS。慢雾安全团队及时捕获这笔攻击,并同步给相关的交易所及项目方。本次攻击手法之前没有相同的案例,但可以归为假充值类别中的一种。对此慢雾安全团队进行了深入的分析。

攻击回顾

根据慢雾安全团队的持续分析,本次的攻击帐号为 fortherest12,通过 eosq 查询该帐号,发现首页存在大量的错误执行交易:

查看其中任意一笔交易,可以发现其中的失败类型均为 hard_fail:

这立即就让我想起了不久前的写过的一篇关于 EOS 黑名单攻击手法的分析,不同的是实现攻击的手法,但是原理是类似的,就是没有对下注交易的状态进行分析。

攻击分析

本次攻击的一个最主要的点有两个,一个是 hard_fail,第二个是上图中的延迟。可以看到的是上图中的延迟竟达到了 2 个小时之久。接下来我们将对每一个要点进行分析。

(1)hard_faild:

参考官方开发文档(https://developers.eos.io/eosio-nodeos/docs/how-to-monitor-state-with-state-history-plugin

可以得知 fail 有两种类型,分别是 soft_fail 和 hard_fail,soft_fail 我们遇见的比较多,我们一般自己遇到合约内执行 eosio_assert 的时候就会触发 soft_fail,回看官方对 soft_fail 的描述:客观的错误并且错误处理器正确执行,怎么说呢?拿合约内 eosio_assert 的例子来说

{
    //do something
    eosio_assert(0,"This is assert by myself");
    //do others
}

这种用户自己的错误属于客观错误,并且当发生错误之后,错误处理器正确执行,后面提示的内容 This is assert by myself 就是错误处理器打印出来的消息。

那么 hard_fail 是什么呢?回看官方对 hard_fail 的描述:客观的错误并且错误处理器没有正确执行。那又是什么意思呢?简单来说就是出现错误但是没有使用错误处理器(error handler)处理错误,比方说使用 onerror 捕获处理,如果说没有 onerror 捕获,就会 hard_fail。

OK,到这里,我们已经明白了 hard_fail 和 soft_fail 的区别,接下来是怎么执行的问题,传统的错误抛出都是使用 eosio_assert 进行抛出的,自然遇到 hard_fail 机会不多,那怎么抛出一个 hard_fail 错误呢?我们继续关注下一个点—延迟时间。

(2)延迟时间:

很多人可能会疑惑,为什么会有延迟时间,我们通过观察可以知道 fortherest12 是一个普通帐号,我们惯常知道的延时交易都是通过合约发出的,其实通过 cleos 中的一个参数设置就可以对交易进行延迟,即使是非合约帐号也可以执行延迟交易,但是这种交易不同于我们合约发出的 eosio_assert,没有错误处理,根据官方文档的描述,自然会变成 hard_fail。而且最关键的一个点是,hard_fail 会在链上出现记录。

攻击细节分析

根据 jerry@EOSLive 钱包的讲解,本次的攻击发生和 EOS 的机制相关,当交易的延迟时间不为 0 的时候,不会立马校验是否执行成功,对延迟交易的处理是 push_schedule_transaction,而交易的延迟时间等于 0 的时候,会直接 push_transaction。这两个的处理机制是存在区别的。

攻击成因

本次攻击是因为项目方没有对 trx 的 status 状态进行校验,只是对 trx 是否存在作出了判断。从而导致了本次攻击的发生。

防御手法

项目方在进行线下开奖的时候,要注意下注订单的执行状态,不要只是判断交易是否存在,还要判断下注订单是否成功执行。如下图

相关参考

引起 object fail 的错误类型参考:

https://eos.live/detail/16715
官方对交易执行状态的描述:

https://developers.eos.io/eosio-nodeos/docs/how-to-monitor-state-with-state-history-plugin

by yudan@慢雾安全团队

数字身份,Scatter 与 RIDL简介

Scatter 目前是 EOS 生态之中不可缺少的一部分,尽管,你可能并不知道它是什么。

你每日使用MeetOne、TP等 EOS 手机钱包玩游戏、访问dApps的时候,就是得益于 Scatter 这一项目所提供的协议。另外,Scatter 也创建了桌面版应用和Chrome插件形式的钱包(已经下架),也是 EOS 社区之中所推崇的最安全的 EOS 钱包之一。

不过,Scatter 的野心不止于成为EOS生态中使用最广的钱包而已,在数字身份领域的探索,也值得关注。自从EOS主网启动之前,Scatter 团队就发布了他们的设想,而如今看来,在数字身份和信任网络领域的探索,他们正在一步一步走来。

当然,值得一提的是,项目与代币的价格,并不会一一对应,本文不构成任何投资建议,仅供希望了解RIDL的朋友参考。另外,在数字身份领域,除了Scatter之外,也有包括IBM、MyKey Lab团队在内的国内外多个公司团队在进行探索和实验,也期待未来更多的成果出现,找到数字身份ID和可信网络这一圣杯。

数字身份有什么用?

对这一赛道,我现在所做的有限的了解,并不足以支撑我作出更为全面的判断,因此,此部分所谈仅供参考,如有错误,欢迎随时指正批评。
在互联网初兴起之时,有个段子:你不知道屏幕另外一侧的聊天者,是人还是狗。

在去中心化的网络之中,增加了数字化资产这一层,在交易之时,如何确认对方的身份?如果你使用一个dapp,除了在网络上搜索相应信息之外,是否有方法可以快速了解到这个dapp靠不靠得住?
如果你使用某个交易所,在使用之前对此一无所知,是否会恶意拔网线?是否会暴露你的隐私?…
另外,如何证明你是你?

如上的种种问题,都是涉及到两个事情:

  • 交易参与的实体(网站,账号,地址,公钥,dapps,合约等等)是否是你所预想的交易对象?
  • 交易实体,是否可信?

安全和可信,降低交易风险,不需要借助于信念或者运气来参与交易,是可信网络和数字身份这一领域所重点关注的问题之一。

圣杯

咕噜曾于2018年9月发文,提到区块链领域的圣杯之一:
基于密码学的身份体系,例如自主身份(Self-soveignein Identity),以及衍生出来的信任网络(Web-of-Trust)
而对于加密身份体系,咕噜认为,“是今后web3.0的入口,是每个人的必需品”。他主要看好两个部分:

加密身份体系的成熟,有助于加密资产在互联网用户中的渗透,以及区块链应用的普及
基于加密身份体系所形成的信任网络(network of trust), 通过信息交叉验证的方式,对于当前误解的新闻和信息造假的问题,提供了最可靠的方式。
在加密身份体系(数字身份)和可信网络的领域,已经有许多的玩家。除了所提到的IBM、scatter团队和MyKey团队以外, BitPortal的创始人在一次访谈之中也提到了他个人所关注的几个团队:

  • ETH上的ERC-725
  • 国内的Ont
  • 国内的BTM
  • 国外的Sorvin

其中Ont和Sorvin都会提供去中心化的KYC系统,对合规和一些落地的应用比较有益,BTM的身份方案基于ODIN,主要用于标识资产

Scatter 团队发文提到说即将发布RIDL,不过按照实际情况看来,上线仍然要等1~2个月。
在RIDL实际上线之前就写文章谈论,难免因为资料有限理解有误,不过,好奇心趋势下,我仍然试着聊聊 RIDL。也随时欢迎朋友们一起交流和指正。
昨天谈到了数字身份和信任网络这一领域的概况,今天就整体聊聊 RIDL 这一EOS社区中的数字ID产品,谈谈它的设计思路。
我所写的任何文章,都不构成投资建议,本文也不例外,仅为提供信息参考之用。

RIDL 方案:为区块链添加声誉和数字身份层

RIDL是什么?


RIDL 的全称有些拗口:声誉与身份层(Reputation and Identity Layer)。
用来解决:

  • 在区块链上的数字身份问题(主要是基于EOSIO的区块链,也会支持其他链)
  • 某个身份实体的信誉问题,公开可见,为安全交易提供参考

RIDL 有两重含义:

  • RIDL是产品,通过RIDL 可以对网站/用户/合约等实体进行评级,使用者也可以根据对应的评级来得到
  • RIDL 也是代币名称,在RIDL中使用该代币进行评级

RIDL的运行机制

这个RIDL上线后,围绕声誉和数字身份,是怎么运行的?这部分简单一聊。主要分为三个过程:

  • 注册一个数字身份,由RIDL所承载,全网唯一
  • 通过“大众点评”方式,形成对于数字身份实体的综合评价。评分会消耗RIDL
  • 得到的评级,链上可查,供交易时参考。

展开聊聊。

1. 注册数字身份(Identity)

简单来说:在RIDL中,引入了身份(Identity)这一概念. 对身份的一个通俗解释:

什么是身份?身份是一个“壳”,壳里装的是“我”。
—- MyKey 白皮书

在 RIDL 中,一个网站、app、合约、用户等实体,都可以注册来绑定一个身份,并接受评价。
你可能留意到: Scatter 桌面版中有一个设置为:Identity,即身份。这是为RIDL所设计的。

目前,其实没多少用处。我们用Scatter 去与dApp交互的时候,不会见到身份的存在,而是要选择对应的EOS 账号。

而在RIDL发布之后,这一身份就派上用场了。 可以将这个身份理解为对账号的一层封装,该身份可以关联多个 EOS 账号。
有几个特点:

  • 付费获得, 年费 $25
    按照Scatter团队说法, 是为了避免羊毛党或者刷评价者恶意占用。如果次年不续费,则身份所积累的信誉会清零,任何人都可以付费去注册该身份.
    此前在EOS上线前 Scatter 曾经做过预注册的方式,可以通过MetaMask 来预留身份 100年。在 RIDL 上线后,可以支付100 RIDL代币,领取所预留的身份。
  • 名称全网唯一
  • 网站、app、合约、用户等实体,都可以绑定身份
  • 可以对身份进行评价,并且该评价是在区块链上公开可查询的,下文会详述
  • 注册了身份之后,可以使用 RIDL Defender,在存在欺诈和恶意行为可能时会提供预警,保护交易的安全

2. 对身份的评级

这部分我认为是RIDL的重点:如何对实体进行评价?评分系统是否可信?
并且,需要在两者之间进行权衡综合:

  • 激励用户参与对某个主体的评价
  • 避免用户恶意刷评价,且消除恶意负面评价的影响

这里,RIDL 采用了评级挖矿的方式来设计。下面会展开聊一聊。先看看身份评级这部分功能的一些特征。

设想如下场景:
你在玩某个dApp游戏,感觉体验很不好,想对此进行评价。

  • 首先,只有注册了身份之后,才能够对其他对身份进行评级。注册身份需要消耗代币,门槛不低,Scatter 团队是希望以此打压羊毛党恶意注册。是否会有效?还需观察。
  • 其次,评价会分为多个维度,最多五个维度。如下图所示,可以从多个角度去打分:


评价需要消耗RIDL代币

看白皮书中的例子:

这是给某个身份(比如,一个交易所)的评分,总计的评级是 10 个RIDL代币,意味着,这一次评级,消耗了你10个代币。
许多人肯定会疑问:对我有什么好处?为何要花费代币去评价?
看看Scatter团队的回复:

Rami 给出的理由是:

  • 用户参与了一个系统,允许我们定义在线安全性。这本身是个卖点。
  • 如果你是第一个评价者,或者在前一个评价者的矿工资格过期(3个月)后,你可以成为“评级矿工”,获得RIDL的代币收益。
  • 你评价之后,会成为“最后评价者”。如果有个人在你之后评价成为了评价矿工,你能够分到一部分的评级RIDL代币。
  • 参与评级,也能够增加你的身份中的RIDL额度。(注:你能够得到的评级是有限的,如果额度扩大,意味着你可以得到更多的RIDL)使用越多,投票得到更多的尊重。

简单说来:
参与评价,可以以挖矿的方式,分得 RIDL 代币奖励;并且,每个月 RIDL 会进行空投,给符合一定标准的评价者(至少评价了10个不同的身份实体)从RIDL的保留代币池中空投一部分RIDL代币给参与评价者。
被评价的身份主体会累积 REP
你花费了 10 个RIDL 代币,评级了某个交易所;那么,在RIDL系统中,这个交易所绑定的身份,会立即得到10个REP。
REP 不可以转账,不能够交易,只是一个标记工具,用来表示评价该身份实体所消耗的RIDL总量。

3. 获取评级信息,供安全交易参考

RIDL上线后,会提供两个工具:

  • RIDL网页
  • RIDL的浏览器插件


通过这些入口,可以查看某个身份主体的评分详情。并且,在 Scatter 内部,还会通过 RIDL Defender 的方式,来对于交易进行预警。比如,如果你准备发起交易的对象,是被RIDL系统中标记为诈骗,则会提示你。

Scatter 发了一个视频,演示插件的效果,可以看看:

https://twitter.com/i/status/1096053747766226944

RIDL 代币机制

最后,顺带聊下RIDL的代币发行情况。

值得一提的是,Scatter 团队没有选择直接给自己留代币份额,而是选择了类似 EOS 发行的众筹方式(他们称之为捐赠),拿出来了16.6% 的代币,即2.5亿 RIDL,用于 Scatter 开发基金。

如果参加”捐赠”,则可以按照参与当期EOS的比例,分得一定的 RIDL 代币作为酬谢。

为期两年共730天,每期12个小时,每期的上限为2千个EOS,释放17万 RIDL。
下图可以看到,当前的 RIDL “捐赠”是第428期。预计还有10分钟结束。


通过这种方式,使得RIDL的价格维持相对平衡的水平。交易所中价格高,可以通过“捐赠”方式得到更多的RIDL代币,拿去交易所卖掉;交易所价格低,则会刺激RIDL的购买者放弃“捐赠”方式得到代币,而直接去交易所购买。

链接为: https://ridl.get-scatter.com/#/

参考信息来源

上周 Scatter 发文: Scatter即将发布RIDL,剑指三大圣杯之一——数字身份ID

RIDL 白皮书: 阅读白皮书

转载自:https://mp.weixin.qq.com/s/egoWhoYN0yRWUv2l9arH0A (EOS42)

简单停机迁移mongo数据

最近在做一个dapp,由于服务器所在地原因,导致内陆用户访问不稳定,所以更换下服务器,做个简单的停机迁移记录

停止原服务器Dapp程序,备份数据库

mkdir dmp
cd dmp
mongodump  -d 需要备份的数据库的名字 -o ./数据名.dmp

等待结束后,会将备份的数据库写到/dmp/数据库名/各种表名

将备份文件下载到本地

scp -P 远程服务器端口 -r 登录名@远程服务器ip:/data/dmp/* /Users/surou/Downloads

将备份上传到新服务器

scp -r 数据库.dmp/* 登录名@远程服务器ip:/data/dmp -P 远程服务器端口

导入备份

登陆新服务器

mongorestore -d 数据库名 ./dmp
参考

https://www.jianshu.com/p/d60691bdc72f
https://www.cnblogs.com/zhaofeng555/p/8075279.html

js Date 传参给合约 eosio::time_point

合约

void xxx_contract::updatetime(eosio::time_point timestamp){
    require_auth( _self.value );
    system_tables system_table(_self, _self.value);
    auto itr = system_table.begin();
    if(itr == system_table.end()){
        system_table.emplace( _self, [&]( auto& s ) {
            s.id = system_table.available_primary_key();
            s.zero_time = timestamp;
        });
    }else{
        system_table.modify( itr, _self, [&]( auto& s ) {
            s.zero_time = timestamp;
        });
    }
}

Js

push action 参数为 new Date().getTime() * 1000