fibos

fibos 查看完整档案

填写现居城市  |  填写毕业院校FIBOS  |  运营 编辑 fibos.io 编辑
编辑

FIBOS 是基于 EOS 技术架构开发的新型公链,采用 DPOS 共识机制,满足大规模商业应用的要求,它创新性地采用了基于 Bancor 协议的通证模型,实现通证经济体系的快速建立和健康发展,融合了 EOS 和 fibjs 的 JavaScript 运行环境,扩展了 EOS 的可编程能力,并且能够使用 JavaScript 开发智能合约,让智能合约编程变得简单、高效。

个人动态

fibos 发布了文章 · 2019-01-30

使用智能合约实现自动分账

自动分账是很多平台都会用到的支付功能。很多互联网内容售卖平台都会跟内容提供者分账。比如:Apple 的 App Store 跟 App 开发者三七分成。很多平台都使用了支付宝、微信支付作为支付手段,但是要同时实现给内容提供者分账,却是一件不太容易的事。使用 FIBOS 智能合约可以很容易实现这个需求。

文中代码已在 GitHub 上开源。https://github.com/fengluo/fi...

设计思路

在 FIBOS 转账是通过 token 合约的extransfer方法来实现的。extransfer方法在执行的时候会给转账方账户和入账方账户发送通知。所以用户给平台方账户转账的时候,平台账户就会收到通知。所以整体业务逻辑如下:

        quantity: 10 FO
        memo: 内容提供者账户           quantity: 8 FO
用户账户 -------------------> 平台账户 ----------------> 内容提供者账户
            extransfer      2/8 分成   extransfer
  1. 用户给平台方账户转账,memo 中填写内容提供者的账户名。
  2. 平台方的账户合约监听 extransfer 方法的通知,然后做出分账计算,给对应内容提供者的账户转账对应金额。

整体逻辑很简单,整个合约代码逻辑差不多用20行就可以写完。

编写合约

FIBOS 的智能合约分为 ABI 文件和 JS 合约两部分。ABI 相当于合约接口,JS 合约则是功能实现。本案例目前没有接口设计需求,不过 ABI 文件还是合约不可缺少的部分。所以我们简单创建一下就好。

我们先创建一个 contracts 文件夹,合约文件都会放在这里。然后在此文件夹下,创建 subaccount.abi 文件,内容为:

{
    "version": "eosio::abi/1.0"
}

JS 合约部分也没有太复杂。在 contracts 文件夹下创建 subaccount.js 文件,代码为:

exports.on_extransfer = (from, to, quantity, memo) => {
    // 需要在开头做一些判断
    if (to === action.receiver && action.is_account(memo)) {
        const num = parseInt(quantity.quantity.split(' ')[0])
        // 假设我们约定平台方跟内容提供者是2/8分成。
        const subnum = (num * 0.8).toFixed(4);
        trans.send_inline('eosio.token', 'extransfer', {
            from: to,
            to: memo,
            quantity: {
                quantity: `${subnum} ${quantity.quantity.split(' ')[1]}`,
                contract: quantity.contract
            },
            memo: 'sub account'
        },
        [
            {
                // 需要提供合约账户的 active 权限
                actor: action.receiver,
                permission: 'active'
            }
        ]);
    }
}

合约代码开头我们需要做一些验证。

  1. 收款方的账户为合约账户,否则因为下面代码执行给内容提供者转账时,因为转帐方也是合约账号会再次收到通知,造成无限递归,超出最大 send_inline 层数而报错。
  2. 我们用 memo 参数来放内容提供者的账户,所以我们需要对此参数校验一下该账户是否存在防止打错。

合约代码中我们使用 send_inline 调用 eosio.token 合约来执行转帐操作。转帐操作需要对应账户的 active 权限才能执行。为了解决权限滥用问题,FIBOS 定义了一个特殊权限 eosio.code。我们需要在平台合约账户中配置权限,在 active 权限下添加该合约账户的 eosio.code 授权。具体的配置操作会在下面说明。

在 FIBOS TestNet 上注册账号

为方便测试,我们在测试网 http://testnet.fibos.fo 上注册三个账户。

  • 用户账号 helloworld11
  • 内容提供者账号 helloworld22
  • 平台合约账号 helloworld33

我们需要记录这三个账号的账户名以及公私钥。以便下面的开发使用。创建一个统一的配置文件来记录这些数据:

const config = {
    // 平台合约账户的客户端配置
    client: {
        chainId: '68cee14f598d88d340b50940b6ddfba28c444b46cd5f33201ace82c78896793a',
        httpEndpoint: 'http://testnet.fibos.fo',
        keyProvider: 'PRIVATE_KEY_OF_helloworld33'
    },
    // 用户账户的客户端配置
    callClient:{
        chainId: '68cee14f598d88d340b50940b6ddfba28c444b46cd5f33201ace82c78896793a',
        httpEndpoint: 'http://testnet.fibos.fo',
        keyProvider: 'PRIVATE_KEY_OF_helloworld11'
    },
    // 平台合约账户信息
    contractAccount: {
        name: 'helloworld33',
        publicKey: 'PUBLIC_KEY_OF_helloworld33',
        privateKey: 'PRIVATE_KEY_OF_helloworld33'
    },
    // 用户账户信息
    account1: {
        name: 'helloworld11',
        publicKey: 'PUBLIC_KEY_OF_helloworld11',
        privateKey: 'PRIVATE_KEY_OF_helloworld11'
    },
    // 内容提供者账户信息
    account2: {
        name: 'helloworld22',
        publicKey: 'PUBLIC_KEY_OF_helloworld22',
        privateKey: 'PRIVATE_KEY_OF_helloworld22'
    }
}

module.exports = config

配置权限

在合约代码中,我们调用了 trans.send_inline 函数调用合约 eosio.token 来实现转帐操作,但是转帐操作是需要账户的 active 权限。所以我们需要更新一下合约账户的权限,需要添加调用者的 eosio.code 授权到它的 active 权限。这个调用者自然也是这个合约账户。

const FIBOS = require('fibos.js');
const config = require('./config');

const fibosClient = FIBOS(config.client);

let ctx = fibosClient.contractSync('eosio');

var r = ctx.updateauthSync({
  account: config.contractAccount.name,
  permission: 'active',
  parent: 'owner',
  auth: {
    threshold: 1,
    keys: [{
      key: config.contractAccount.publicKey,
      weight: 1
    }],
    accounts: [{
        permission: {
            // 将调用者账号的 eosio.code 授权添加到它的 active 权限下。
            actor: config.contractAccount.name,
            permission: 'eosio.code'
        },
        weight: 1
    }]
  }
},{
    authorization: `${config.contractAccount.name}@owner` //更改账户权限需要使用 owner 权限
});
console.log(r);

部署合约

const FIBOS = require('fibos.js');
const config = require('./config');

const fibosClient = FIBOS(config.client);
const fs = require('fs');

// setcode
const jsCode = fs.readTextFile(`${__dirname}/contracts/subaccount.js`);
fibosClient.setcodeSync(config.contractAccount.name, 0, 0, fibosClient.compileCode(jsCode));

// getcode
const code = fibosClient.getCodeSync(config.contractAccount.name, true);
console.log('code:', code);

// setabi
const abi = JSON.parse(fs.readTextFile(`${__dirname}/contracts/subaccount.abi`));
fibosClient.setabiSync(config.contractAccount.name, abi);

转账测试

我们先来写一个脚本 account.js 来查看三个账户的余额。

const FIBOS = require('fibos.js');
const config = require('./config');

const fibosClient = FIBOS(config.callClient);

const account1 = fibosClient.getTableRowsSync(true, 'eosio.token', config.account1.name, 'accounts');
console.log(config.account1.name);
console.log(account1);

const account2 = fibosClient.getTableRowsSync(true, 'eosio.token', config.account2.name, 'accounts');
console.log(config.account2.name);
console.log(account2);

const contractAccount = fibosClient.getTableRowsSync(true, 'eosio.token', config.contractAccount.name, 'accounts');
console.log(config.contractAccount.name);
console.log(contractAccount);

执行 fibos account.js 来查看三个账户信息。 目前我们的账户还没有 FO,所以大致情况是这样的:

  • 用户账户:helloworld11 金额:0.0000 FO
  • 内容提供者账户:helloworld22 金额:0.0000 FO
  • 平台合约账户:helloworld33 金额:0.0000 FO

测试网会自动给每个账户发放10 EOS 的通证用以测试使用。账户中还并没有 FO 通证。所以我们再来写一个兑换脚本,用1 EOS 换一点 FO 通证。

const FIBOS = require('fibos.js');
const config = require('./config');

const fibosClient = FIBOS(config.callClient);

let ctx = fibosClient.contractSync('eosio.token');

const r = ctx.exchangeSync(
    config.account1.name,
    '1.0000 EOS@eosio',
    '0.0000 FO@eosio',
    'exchange FO to EOS',
    {
        authorization: config.account1.name
    }
);
console.log(r)

再次执行 fibos account.js 来查看账户信息。目前我们的账户金额大致是这样的:

  • 用户账户:helloworld11 金额:146.4245 FO
  • 内容提供者账户:helloworld22 金额:0.0000 FO
  • 平台合约账户:helloworld33 金额:0.0000 FO

下面写个脚本 transfer.js 来执行转帐操作。

const FIBOS = require('fibos.js');
const config = require('./config');

const fibosClient = FIBOS(config.callClient);

let ctx = fibosClient.contractSync('eosio.token');

const r = ctx.extransferSync(
    config.account1.name, // 用户账户
    config.contractAccount.name, // 平台合约账户
    '10.0000 FO@eosio', // 转帐金额
    config.account2.name, // 附言填写内容提供者的账户名,平台合约会给它分账
    {
        authorization: config.account1.name //提供用户账户的授权
    }
)

console.log(r)

我们要从用户账户 account1 给平台合约账户 account3 转帐 10 FO。memo 参数为要分成的内容提供者账户 account2。根据合约中定的2/8分成,平台合约账户 account3 将会分得2 FO,而内容提供者账户 account2 将会获得8 FO。

使用命令 fibos transfer.js 执行该脚本完成转帐操作。

下面我们再来看一下目前三个账户情况。执行命令 fibos account.js。三个账户金额大致如下。

  • 用户账户:helloworld11 金额:136.4245 FO
  • 内容提供者账户:helloworld22 金额:8.0000 FO
  • 平台合约账户:helloworld33 金额:2.0000 FO

结果显示,分账账户和平台合约账户如预期那样获得8 FO2 FO

综上,我们成功使用了智能合约实现了自动分账。平台方还可以继续根据自己业务需要定制自己的合约。

文中的代码请参考:https://github.com/fengluo/fi...

查看原文

赞 6 收藏 2 评论 1

fibos 发布了文章 · 2019-01-28

一文搞懂区块链跨链技术

区块链的跨链技术是什么?

自比特币10年前诞生以来,数以千计的区块链公链被开发出来,基于各种公链的加密货币数量更呈现井喷式增长。客观来看,各条公链都具有自己独特的优势和特征,以 EOS 为代表的公链更是提出了“侧链”的概念。基于“侧链”的概念,EOS 打出了百万级 TPS(系统吞吐量) 的口号。要知道比特币的 TPS 最高值仅有 7,也就是说比特币每秒钟仅支持 7 笔交易。作为区块链 2.0 代表的以太坊的 TPS 也不过才 30~40。而 EOS 号称可以达到百万级 TPS 的技术基础正是“侧链跨链”。

跨链技术可以被理解为一种协议,解决两个或多个不同链上的资产以及功能状态不能互相传递、转移、交换的问题。也就是说,跨链技术能够增加区块链的可拓展性,能够从根本上解决不同公链/侧链之间交易困难产生的”数据孤岛“问题

跨链技术的难点

跨链技术从 Blockstream 提出侧链概念以来,一直是区块链技术的重点攻关方向。目前并没有被普遍认可的跨链机制,原因在于各个公链之间的底层技术实现差异巨大给跨链技术带来了不小的障碍。

跨链需要解决的几个难点问题:

  • 保证跨链信息真实可信

    原链上的交易信息对于另一条链来说是一个外部信息,如何保证这个外部信息进入另一条链时是正确的,是整个跨链机制的重要环节。如果要考虑到使用 POW 机制的区块链上没有终局状态(始终存在分叉的情况,只是随着确认块的增加,概率逐渐变小),这个问题的复杂度会更高。

  • 跨链交易要确保原链上的 Token 总量不会因为跨链而减少或增多

    跨链技术很重要的一个应用方向就是数字资产的跨链转移,如何保证不同链上的数字资产能够安全地从一条链转移到其他链,又可以从其他区块链安全地返回主链是亟待解决的问题之一。

    对于数字资产的跨链转移来说,原链上 Token 总量减少的后果是当 Token 需要跨回原链时,原链无法产生新的 Token ,也就是只能单向跨链。原链 Token 增多是名义上的增多,实际上是本来已经跨链至另一个账本的 Token 在原链上被双重支付了,这种情况违背了精确记账的原则,是在任何时候都无法接受的。因此当 Token 跨出原链时,原链上的 Token 必然需要进入“锁定”的状态,当 Token 跨回原链时,这些 Token 需要被解锁。如何通过去中心化的管理机制完成“锁定”、“解锁“的过程就成为了跨链的关键。

  • 保证整个跨链交易的原子性

    交易的原子性,简单来说是指交易处理的某个环节停止,整个交易能够撤销,而不会存在部分成功,部分失败的情况,无法保证原子性会造成双重支付。在跨链技术中保证原子性的难点在于,跨链双方是两条独立的链,可能具有不同的共识机制、数据结构、交易处理逻辑等等,造成交易最终没有被执行的原因也千差万别。

现有的跨链技术方案

目前主流的区块链跨链技术有公证人机制(Notary schemes)、侧链/中继(Sidechains/relays)、哈希锁定(Hash-locking)。

公证人机制

公证人技术的代表就是瑞波 Interledger 协议。2012年,瑞波实验室提出 Interledger 协议,旨在连接不同账本并实现它们之间的协同。Interledger 协议适用于所有记账系统、能够包容所有记账系统的差异性,该协议的目标是要打造全球统一支付标准,创建统一的网络金融传输的协议。

Interledger 协议使两个不同的记账系统可以通过第三方“连接器”或“验证器”互相自由地传输通证。记账系统无需信任“连接器”,因为该协议采用密码算法用连接器为这两个记账系统创建资金托管,当所有参与方对交易达成共识时,便可相互交易。

侧链

侧链是以锚定某种原链上的通证为基础的新型区块链,正如美金锚定到黄金。侧链是连接各种链,其它区块链则可以独立存在。

侧链技术的代表是 BTC Relay。它被认为是区块链上的第一个侧链。BTC Relay 把以太坊网络与比特币网络通过使用以太坊的智能合约连接起来,可以使用户在以太坊上验证比特币交易。它通过以太坊智能合约创建一种小型版本的比特币区块链,但智能合约需要获取比特币网络数据,因此实现去中心化比较困难。BTC Relay 进行了跨区块链通信的有意义的尝试,打开了不同区块链交流的通道。

中继技术

中继技术的代表是 Polkadot。Polkadot 是由原以太坊主要核心开发者推出的公有链。它主要解决当今两大难题:即时拓展性可扩展性。Polkadot 计划将私有链/联盟链融入到公有链的共识网络中,同时又能保有私有链/联盟链的原有的数据隐私和许可使用的特性。它可以将多个区块链互相连接。

Polkadot的提出者 Gavin Wood 希望用一条中继链(Relay-chain)来实现其他所有链的交易的验证工作, 再通过平行链的创建实现与原链的交易与通信。

具体来说,现在想在链 A 和链 B 间进行跨链转账,他们的中继链为链 C。链 A 先将数据发送到中继链 C 上,然后在中继链 C 上进行数据校验。校验完成后,将一份成功的凭证发送给链 A,同时向链 B 发送数据,链 B 接收数据后,向中继链 C 发送接收凭证。在链 B 操作执行成功后,会向中继链 C 发送成功凭证。

哈希锁定技术

哈希锁定技术的代表是闪电网络。闪电网络底层运用了 HTLC 技术和 RSMC 技术,构建了一个个链下支付通道。这些通道合在一起成为一个网络。交易双方的数目比较小的微支付可以通过一系列的链下协议完成,从而拓展比特币的性能。

什么是 HTLC 哈希时间锁技术?举个例子。A 与 B 达成这样一个协议:协议将锁定 A 的1个比特币,在 T 时刻到来之前,如果 B 能够告诉 A 一个正确的“暗号” R,使得 R 的哈希值等于约定的值(R),B 就能获得者一个比特币。如果 B 在 T 时刻到来时不能提供正确的“暗号” R,那么这一个比特币自动解锁,回归 A 所有。

“不需要记录在区块链上”的闪电网络还应用了 RSMC(可撤销的顺序成熟度协约)技术。具体来看,假设 A 与 B 之间有一个支付通道,二人共同存入一定资金,必须当二人都签名时才能动用这些资金。每次交易时,都要共同确认资金分配,并达成分配合约。当新的分配合约生效后,旧的分配合约失效。一旦有人,比如 A 仍然使用旧的合约来动用资金,作为惩罚这笔钱必须退还给 B 作为补偿。

FIBOS 的跨链思考

哈希锁定作为 FIBOS 跨链技术的选型并不理想。一来哈希锁定无法保证数据来源的可信度;此外,它还需要用户在一定时间窗口完成操作,用户本身也成为了跨链的一部分,提升了用户使用门槛。

公证人机制天然比较契合 FIBOS 的生态,因为 FIBOS 中 BP 节点(Block Producer)恰好可以作为公证人。但这也带来了一定的问题,首先,BP 节点由投票产生,其变动速度较快,公证人列表需要不断的更新,需要考虑如何去中心化的同步公证人列表、以及公证人列表和 FIBOS BP 不一致所带来的数据同步问题;其次,BP 节点的可信度也存在问题,因为 BP 是由 FIBOS 选出,其公信力不能影响到其他链,这会使得跨链数据的真实信被质疑;最后,公证人机制本身存在数据重复发送的问题,降低了效率。同时,得到的数据依靠“多签”机制来判断能否执行,不能在数学层面上验证,这也会产生风险。

侧链方案有一定的可取性。由于其区块状态同步在合约内进行,所以会产生不必要的 CPU,RAM 等资源消耗。同时带来的问题是,由于 FIBOS 出块速度较快(0.5s),在 FIBOS 侧链进行多块的状态同步,容易产生超时问题。使用侧链来解决数据的可信度是一个很好的方案,可是不应该将其放在合约内进行。

中继方案看起来更为可取,因为中继链的存在,不会因同步状态消耗额外资源在源链上。同时,异构链的数据结构不同问题,可以用在中继链内进行数据转换解决。这使得中继方案不仅比较经济,而且能在异构链之间进行转账。唯一的问题在于锁定资产账户由谁来控制,以及状态和数据同步由谁进行,这一点在上述的中继技术方案里并没有给出答案。

对于 FIBOS 生态来说,解决跨链问题是一个战略性的挑战,尤其在谈到和 EOS 之间的跨链转账问题时,跨链技术是必须要攻克的难关之一。对此,融合公证人机制和中继的方案有着较高的可行性。资产锁定账号由公证人共同掌握,公证人同时负责区块状态的初始化和给出一个同步地址。当出现跨链转账操作时,首先由见证人执行多签对跨链资产进行转出,然后进入中继链,进行数据验证。验证成功后,再由多签操作转入目标链。这使得公证人机制能够在数学层面上被验证,同时使得中继链的数据来源较为可信。

区块链从技术上来说是P2P网络、加密技术和分布式账本,从经济上来说,它是价值网络。而目前,由于不同链之间通信壁垒的存在,导致了区块链的价值网络呈割裂的状态。区块链作为价值网络的基础设施部分,不应该只局限于和止步于一个个“价值孤岛”,更不能仅仅将价值圈定于一个个小的生态中。我们需要跨链技术,需要将不同链之间进行连接和拓展,构建价值网络的高速公路。随着区块链技术的高效迭代和创新,我们相信跨链技术终将成熟,区块链价值网络的高速公路也终将会把一个个“孤岛”连接起来。

查看原文

赞 10 收藏 6 评论 1

fibos 发布了文章 · 2019-01-24

高晓松:区块链也可以有诗与远方

2019年1月3日,高晓松的《晓说》在朋友圈刷屏了。

这次高晓松没有谈风花雪月、诗与远方,而是在其母校清华大学的教室里,跟学弟学妹们深入浅出地聊起了区块链在文娱产业的革命。

在传统模式下,文化作品从产出到走向市场要经历许多环节,过程十分繁琐。优秀的艺人都是稀缺资源,很多已经被一些大型公司签约了。当然经纪公司同时也会去发掘新的艺人,通过各种方式打榜推广包装成 IP。制作公司与艺人签合同后,要花费大量资金成本制作出优秀文娱作品,然后通过发行公司将文化产品投放到市场。

发行公司对接各种渠道和发行终端,比如说唱片销售方QQ音乐,爱奇艺,或者是各大电影院。发行方与各种媒体进行议价,讨论如何分成,这又要花费大量的时间和精力,谈成后,文娱产品才会流入市场。如果使用区块链技术则可以降低使用版权的门槛。

消费者通过这些终端购买作品。这其中的环节十分复杂,很容易被寡头垄断。在国外发行唱片大多会被 Applemusic 垄断,导致艺人丧失议价权。有些公司为了避免这种情况,会把签约艺人,制作发行,终端销售合为一体,如netflix——网飞,还有迪士尼,都在尝试自己产出作品并且在自己的终端播放。

我们来分析一下传目前中文娱产业的一些弊端。

文娱产业里的劣币驱逐良币

首先,每个内容创作者都有其自身的独立性和局限性,无法批量化流水线生产。然而现有商业模式下的平均思维导致艺人难以释放自己的创作潜力,形成了互弱环境——个体与个体之间互相影响导致效率低下,高效者反而会被逆向淘汰。

内容同质化现象严重

另外一个则是内容消费中的价格均等,追求整体(传统技术和模式的限制,无法做到针对性投放和生产)以求降低制作和分发难度,则无法针对性的获取差异化收入,也无法满足绝大部分需求——这是网飞类平台出现的最重要原因。内容分发非差异化,高费低效。

粉丝与艺人沟通非常困难

这些问题,除了技术限制、成本限制,也包括了平台和渠道限制。传统模式里都是一大对众小。无论是内容生产、商业服务、信息沟通等等,都必然是一个掌握了单(巨头)对单(个体)绝对优势局面,这会让沟通失衡,让矛盾和问题不会即时反馈(来源纷杂、获取成本高、心理上的轻视),只会积压然后雪崩。这对于巨头和群体都是双输,我们应当随着技术进展而尝试去解决这种情况。要么让巨头群体化,其单个群体对于个体的优势不会那么大;要么让群体的力量能够被整合,就有了对巨头的压制优势。

区块链为文化产业带来新思路

区块链可以将同一生产内容整个环节的所有应用和消费都溯源归集,给予小众群体、大众群体的回报和激励都符合其实际状态。区块链对于版权溯源,完全可以做到收益可归集、分发可控。内容分发平台可能会变成类似滴滴的平台,具体的每一次内容消费,其收益都会被直接的反应到版权源。而在这一过程中,平台可以根据使用量等确定自身的话语权,来和不同的内容生产者确定不同的利润分成。而对于消费者而言,只需要为具体的消费付出相对应的价格,无需承担过多的不必要成本,就像预存制一样的消费。

价值 TOKEN 化,艺人利益得到保证

高晓松在谈到区块链时,也赞成艺人发行 Token 来跳过娱乐公司。首先艺人发行自己的通证,然后通过通证融资来制作自己的娱乐或周边产品,粉丝通过通证来兑换(购买)娱乐,艺人再把娱乐收入的20%分红给粉丝,形成良性循环。

1.艺人将作品上链。在创作早期,IP 尚未建立时艺人通过众筹模式制作文娱作品,这可以参考一些优秀的众筹网站,如国外的 kickstar,国内的“点名时间”,京东金融等。很多一些不错的小众作品都是得益于这样的平台才能出现,但是,粉丝在这种模式下得到的收益是很有限的,如果把这种模式放到链上,比如像高晓松说的歌手把收益的20%分给粉丝,这样会形成更好的良性循环。

2.艺人通过区块链自动实现作品的推广和管理。作品上链后会获得充足资源和关注、流量,支持者获得其预期收益回报。这就可以建立自有的经济体系,包括支持者回馈、互动参与激励等。在有了一定的粉丝基础后,艺人允许用户通过投资享受内容或收益回报,或者通过建立荣誉机制等,增强用户黏度和忠诚度,培养和归集具体的用户群体。

3.艺人通过区块链获得收益并进行商务合作。娱乐所有生产、分发、流通、消费环节数据都由链上保存,艺人可以直观、清楚的获取所有应当获得的回报情况,并且可以根据情况,提前对个人、平台、商用等不同场景设定费率,继而针对性的设置不同费率实现不同目的(回馈粉丝、促成合作等)。这样就可以形成价值在各个环节自由流通。

FIBOS 在价值 TOKEN 化中可以提供的技术支持。在发行通证方面, FIBOS 支持传统通证和基于 Bancor 协议的智能通证的发行,大大降低了发行的门槛。只需要艺人确定好经济模型,设置几个参数就能实现一键发币。在融资方面, FIBOS 可以实现跨链融资, FIBOS 映射了 EOS 和以太坊的资产,包括 EOS 和 稳定币FOD,此外还有 FIBOS 自己发行的通证 FO。

粉丝拥有多重身份

高晓松认为粉丝可以通过以下三种方式获得通证:1.兑换转账(法币购买);2.协助分享推广挖矿;3.艺人分红或发糖果获得。

在各个环节中价值token化,大大降低了粉丝参与门槛,这样粉丝不单纯是传统意义上的粉丝,也会是投资机构,和一些社会群体。

1.粉丝是艺人的早期投资人。粉丝购买艺人发行的通证,支持艺人的创作。

2.粉丝是中期的推广者。粉丝也可以通过向他人推荐作品获得通证。区块链可以将很弱的价值衡量出来,同样为爱豆宣传的人,带来的新粉数量不一样,获得的通证价值也是可以区分的。比如说甲安利并带来了39个新粉,乙只有42个,那么在传统模式下这是无法区分的。但是区块链可以做到把非常弱的价值(衡量出来),因为Token就是联系整个区块链下面的价值交换的一个介质,这个介质就可能叫加密介质,可以细分到无数个细小领域。比如说你39个人,他42个人,你可能获得了0.39个Token,他获得是0.42个Token,这样的模式会更容易调动大家宣传的积极性。

3.粉丝是终端消费者。粉丝通过购买的通证或者是推广而获得的通证在链上兑换艺人的作品。 IP 周边消费品,包括书籍、道具、手办、电子版音视频等等产物,都可以通过兑换获取。

4.粉丝是后期的受益者。艺人和作品的成功会带来通证的价值提升,粉丝在早期购买的通证价格较低,通证升值后粉丝可以用来兑换其他内容消费品或持有分红。不同 IP、内容消费品产出源之间可以开放兑换系统,增加用户联系和绑定。

通过区块链技术艺人可以更加贴合粉丝,创造出更高效的内容推荐和特色化的消费产品与服务体验。

区块链技术打造文娱圈的健康生态

通过区块链我们可以将各环节的价值 Token 化,让版权在上下游之间自由流动,大家都能参与进来。利用Token,区块链可以做到分散版权确权,可以做到把非常弱的价值衡量出来。 Token 将会从底层可以改变整个产业链,未来将会有更多创业机会。

可以想见,如果未来娱乐交易依托于区块链平台,盗版侵权将无处安生。音乐人也可以跨过出版商和发行商,自主管理作品,与粉丝“零距离”接触,形成良好的文化圈生态。

查看原文

赞 5 收藏 2 评论 0

fibos 发布了文章 · 2019-01-22

使用快照启动 FIBOS、EOS 节点

为什么使用快照

1. 快速同步节点

EOS 的日志文件已经达到了 160G,同步一个 EOS 全节点大约需要耗时 10-15 天的时间,时间成本非常高。作为一个普通 Dapp 开发者,我们并不需要之前的区块数据,所以完全不需要浪费大把时间去同步一个 EOS 全节点。通过快照同步的方式能够很好的满足我们的需求,使用最新快照启动的节点,能够在 3~4 分钟内完成节点同步达到主网高度,时间成本大大降低。

2. 节省服务器资源

  快照启动的节点,区块日志 block.log 内只会保存节点启动之后的区块数据,占用的磁盘空间更小。对比全节点和快照方式启动的节点两种方式同步 EOS 主网的结果来看,可以得出的结论是使用快照启动的节点在 CPU 和 RAM 的使用上都要远远小于全节点。这就意味着在一定程度上使用快照同步的节点能够很大程度上的降低我们的服务器成本。

3. 不停机数据备份

传统的区块数据备份步骤:

  1. 停止同步中的节点
  2. 使用压缩工具将区块数据压缩
  3. 重新启动节点

快照备份步骤:

访问对应的接口: /v1/producer/create_snapshot,节点开始数据备份,备份结束后继续同步,无需停掉正在运行的节点。

通过上面的对比可以看出,使用快照方式启动的节点,在数据备份上将更加简单便捷。

快照实现的原理

1. 使用快照启动

相应的源码地址: https://github.com/EOSIO/eos/...,截取部分代码:

auto infile = std::ifstream(my->snapshot_path->generic_string(), (std::ios::in | std::ios::binary));
auto reader = std::make_shared<istream_snapshot_reader>(infile);
reader->validate();
reader->read_section<genesis_state>([this]( auto &section ){
        section.read_row(my->chain_config->genesis);
        });
infile.close();

从源码中可以看出当启动添加参数:snapshot时,会以快照中的数据启动。

2. 实现快照备份

进行快照备份时,服务器资源使用情况稳定。但正在备份中的节点服务将暂时不可用,待数据备份结束后将恢复。所以推荐备份节点和业务节点独立开。
相应的源码如下: https://github.com/EOSIO/eos/...

producer_plugin::snapshot_information producer_plugin::create_snapshot() const {
   chain::controller& chain = my->chain_plug->chain();

   auto reschedule = fc::make_scoped_exit([this](){
      my->schedule_production_loop();
   });

   if (chain.pending_block_state()) {
      // abort the pending block
      chain.abort_block();
   } else {
      reschedule.cancel();
   }

   auto head_id = chain.head_block_id();
   std::string snapshot_path = (my->_snapshots_dir / fc::format_string("snapshot-${id}.bin", fc::mutable_variant_object()("id", head_id))).generic_string();

   EOS_ASSERT( !fc::is_regular_file(snapshot_path), snapshot_exists_exception,
               "snapshot named ${name} already exists", ("name", snapshot_path));


   auto snap_out = std::ofstream(snapshot_path, (std::ios::out | std::ios::binary));
   auto writer = std::make_shared<ostream_snapshot_writer>(snap_out);
   chain.write_snapshot(writer);
   writer->finalize();
   snap_out.flush();
   snap_out.close();

   return {head_id, snapshot_path};
}

从源码中可以看出,当进行快照备份时,会将备份数据写到我们设置的路径下,快照的文件名为当前区块的hash。

下面我们将详细介绍在 FIBOS、EOS 上如何通过快照启动

启动 FIBOS 节点

注意: FIBOS 版本: v1.4.0+

创建快照

配置快照目录

快照生成位置 config.data_dir 为根目录,可以配置为:

config.data_dir = "./blockData/data"

fibos.load("producer", {
"snapshots-dir": "snapshots"
});

根据配置,快照生成的位置为:
./blockData/data/snapshots

载入插件

fibos.load("producer_api");
注意: 开启该插件后,请确保你的节点放置在内网安全。

完整配置文件可参考:

const fibos = require('fibos');
fibos.config_dir = "./blockData/data"
fibos.data_dir = "./blockData/data";

fibos.load("http", {
    "http-server-address": "0.0.0.0:8870",
    "access-control-allow-origin": "*",
    "http-validate-host": false,
    "verbose-http-errors": true
});

fibos.load("net", {
    "p2p-peer-address": [],
    "max-clients": 100,
    "p2p-listen-endpoint": "0.0.0.0:9876"
});

fibos.load("producer", {
    "snapshots-dir": "snapshots"
});

fibos.load("producer_api");

fibos.load("chain", {
    "contracts-console": true,
    "genesis-json": "genesis.json"
});

fibos.load("chain_api");

fibos.start();

相关 p2p 节点地址信息可以去 http://p2pcheck.fibospubg.top... 获取。

生成快照

启动节点后,通过调用接口:/v1/producer/create_snapshot 生成快照,命令如下:

curl http://127.0.0.1:8870/v1/producer/create_snapshot

节点生成完快照后,返回结果如下:

{
"head_block_id":"00003070049e51276829f6d1020fa638e5428fc9f8b0532fc60f680d72359dbe",
"snapshot_name":"./blockData/data/snapshots/snapshot-00003070049e51276829f6d1020fa638e5428fc9f8b0532fc60f680d72359dbe.bin"
}

通过快照启动

配置快照文件路径

fibos.load("chain", {
"snapshot": "./blockData/data/snapshots/snapshot-00003070049e51276829f6d1020fa638e5428fc9f8b0532fc60f680d72359dbe.bin"
});

启动服务

fibos.start();

启动 EOS 节点

注意: nodeos 版本: v1.4.0+

通过快照启动

下载快照文件:

最新的快照文件地址:https://eosnode.tools/snapshots

wget $(wget --quiet "https://eosnode.tools/api/snapshots?limit=1" -O- | jq -r '.data[0].s3') -O snapshot.tar.gz

解压快照文件

tar -xvzf snapshot.tar.gz

目录结构:

├── node-data
│   ├── snapshots
└── config.ini

注意:使用快照备份的方式启动时,需要保证 node-data 文件夹下无日志和状态数据文件。

配置文件:

vim config.ini

agent-name = EOSNODEOS

chain-state-db-size-mb = 10240
reversible-blocks-db-size-mb = 1024

http-server-address = 0.0.0.0:8870

http-validate-host = false
verbose-http-errors = true
abi-serializer-max-time-ms = 2000

access-control-allow-origin = *
allowed-connection = any

max-clients = 2
sync-fetch-span = 3000
connection-cleanup-period = 30
enable-stale-production = false

plugin = eosio::chain_api_plugin
plugin = eosio::chain_plugin

p2p-peer-address = ip:prot

相关 p2p 节点地址信息可以去 https://github.com/CryptoLion... 获取

快照方式启动脚本:

nodeos --config-dir ./ --data-dir ./node-data --snapshot ./node-data/snapshots/snapshot-023e5e8813f687c6c5ffcf6eae853eb24f78d90b475dac4fb94face8c8308e4f.bin

节点启动后目录结构:
├── node-data
│   ├── snapshots
│ ├── blocks
│ ├── state
└── config.ini

验证:

curl  http://127.0.0.1:8870/v1/chain/get_block -X POST -d '{"block_num_or_id":38006282}'

返回结果为高度38006282的区块数据,返回的结果大致如下:

{
    "timestamp": "2019-01-18T02:43:16.500", 
    "producer": "atticlabeosb", 
    "confirmed": 0, 
    "previous": "0243ee09128b14b56f90b3a0288b4b6f34526f53d71f8dc4e56bb89a42b4a93d", 
    "transaction_mroot": "179c0382cf457b63356f733dc93bd3c582419f2b3a64e0d270e9d9238149bae4", 
    "action_mroot": "e83174a2fae3c44777616993e7ba65393805a382bf423b744010873f76beaae8", 
    "schedule_version": 667, 
    "new_producers": null, 
    "header_extensions": [ ], 
    "producer_signature": "SIG_K1_KhkTgB5PHXGmYtiZMGgHVcQKxKFh8uUFVA8Mwic8bpjA6bCFSYnNkbGqYZW23A5zBXWKvb3PnMJGEiS3MHwvPGpZzf95wd", 
    "transactions": [.....]
}

生成快照

添加插件

config.ini 中添加:

plugin = eosio::producer_api_plugin
注意: 开启该插件后,请确保你的节点放置在内网安全。

设置备份目录

启动时完整参数:

nodeos --config-dir ./ --data-dir ./node-data --snapshots-dir ../snapshots-backups

创建快照

curl http://curl http://127.0.0.1:8870/v1/producer/create_snapshot

按照目前 EOS 的大小,这一步大约需要耗时10~15分钟。快照创建结束后,在 snapshots-backups 目录下,生成相应的快照文件。请求返回结果如下:

{
    "head_block_id":"000006a4529a21b72b58c70c262fd3a754930d68b30b0b166f72fc1dbbc376e8",
    "snapshot_name":"./snapshots-backups/snapshot-000006a4529a21b72b58c70c262fd3a754930d68b30b0b166f72fc1dbbc376e8.bin"
}

适用场景

  1. 搭建自己的 EOS、FIBOS API 节点
  2. 只关心当前最新的区块数据、交易,无需溯源
查看原文

赞 12 收藏 4 评论 1

fibos 发布了文章 · 2019-01-16

Ethereum 君士坦丁堡安全漏洞对 FOD 的影响

FOD 与 Ethereum 的前世今生

FOD 是 FIBOS 生态中的稳定币,与 USDC 1:1 锚定,其服务于需要稳定价值衡量的应用场景。FOD 通过跨链网关将 ETH 链上的 USDC 与 FIBOS 链上的 FOD 价值绑定。这相当于 1:1 锁定了流通 FOD 同等数量的 USDC,并提供稳定即时的双向兑换。

Ethereum 君士坦丁堡升级对 FOD 的影响

本次 Ethereum 君士坦丁堡升级是 Ethereum 由大都会转向宁静前的最后一次升级,升级采取的硬分叉模式,为了防止用户在升级时转账出现问题,我们决定暂时关闭 FOD 通道。由于在 2019 年 01 月 16 日凌晨,Ethereum 君士坦丁堡版本被曝出安全漏洞因此 FOD 通道重启只能延期,重启日期需要根据 Ethereum 基金会对这次安全漏洞对处理结果待定。

Ethereum 君士坦丁堡安全漏洞

智能合约中 address.transfer(...)address.send(...) 存在重入攻击漏洞。

漏洞产生的情况

  1. 合约中有一个函数 A,A 中在改变状态后调用了 transfer/send 函数。这种情况有的时候不是很明显,比如二次 transfer 或者内部调用另一个智能合约
  2. 必须存在一个攻击者可访问的函数 B,其中(a)改变状态,(b)状态改变与函数 A 的状态改变冲突。
  3. 函数 B 执行消耗需要小于 1600 gas (2300 gas 限制 - 700 gas(为 call 提供的))

为什么此次升级会产生安全漏洞

在 Ethereum 拜占庭版本每个存储操作需要消耗至少 5000 gas,而 transfer/send 操作 gas 消耗要求小于 2300,在执行上述操作的时候会因为 gas 限制而无法执行。

在 Ethereum 君士坦丁堡版本中,改良了 EVM 机制,从而减少了 gas 的消耗,因此出现了重入攻击的安全漏洞。

Parity 客户端升级方法

在这次安全漏洞之前的 Parity 客户端包含了 Ethereum 君士坦丁堡版本的升级并会在区块高度达到 7080000 时激活。针对这次的安全漏洞,Parity 官方紧急发布了新的 Parity 版本。

Parity 升级方法
升级指令:

bash <(curl https://get.parity.io -L) -r stable

验证是否更新成功

parity -v

得到的结果查看版本是否是 Parity-Ethereum/v2.2.7-stable

Parity Ethereum
  version Parity-Ethereum/v2.2.7-stable-b00a21f39-20190115/x86_64-macos/rustc1.31.1
Copyright 2015-2018 Parity Technologies (UK) Ltd.
查看原文

赞 10 收藏 1 评论 1

fibos 发布了文章 · 2019-01-16

FIBOS 与 Ethereum 技术对比

共识机制

Ethereum 使用的是 PoW 共识机制,未来几年里将会换成 PoS 共识机制。Ethereum 区块是由矿工计算哈希产生,在 PoW 共识机制中区块需要得到全网络超过51%的节点确认才能够正式被区块链认可。在 Ethereum 网路中,任何人都可以成为矿工。

FIBOS 使用的是 DPoS 共识机制。FIBOS 区块的产生是由21个 BP 轮流出块,产生的区块需要2/3以上的 BP 确认才能够被区块链认可。21个 BP 是由 FO 通证持有者投票选举出。

账户/地址

Ethereum 的用户使用的是地址,一个长达40位的的16进制数。

FIBOS 使用的是账户管理,账户名采用12位数字与字母组合,可自定义,方便用户记忆。

权限

Ethereum 的权限是由地址唯一对应的私钥管理,并且这个私钥是随机生成的,在需要使用的权限的时候用户只能通过私钥授权。

FIBOS 账户默认有2种原生权限: owner、active,一个账户必须“关联” owner、active 权限。

  • owner 拥有超级权限,代表着账户的归属者,因为拥有此权限者可以用于操作其他权限配置,该权限常用事务中(转账、合约 action 等)一般不会使用。
  • active 常用业务的权限,比如:转账、投票等。

另外还可以根据自己需求自定义权限。

手续费/资源

Ethereum gas

在 Ethereum 中使用区块链上的资源需要消耗 gas,消耗的 gas 作为区块打包的费用支付给矿工。

FIBOS 资源

FIBOS的资源分为两种类型:

  • 抵押型资源,包括 CPU 和 NET;
  • 消耗性资源,叫做 RAM,也称存储。

开发者发布一个合约必须拥有足够的资源,包括 RAM、CPU 和 NET。

智能合约

编程语言的区别

Ethereum 上开发智能合约使用的语言为 Solidity,这是一门专为 EVM 而开发的语言,对于一般没有接触过 Ethereum 或智能合约的开发者来说,该语言的研发门槛很高。

Ethereum 合约示例:

pragma solidity ^0.4.0;

contract hello {
    function hello(uint i){

    }
}

FIBOS 使用 JavaScript 编写智能合约,开发成本极低。这让开发智能合约的门槛降低了许多。

FIBOS 合约示例:

exports.hi = user => console.error('in contract:', user);

合约的发布和更新

Ethereum 合约发布成功后会得到一个合约地址。合约地址格式长并且没有规律记忆起来十分困难。Ethereum 合约发布后无法更改。

在 Ethereum 中如果合约发布后发现问题,现有两种解决方案:

  • 一个是在合约中预先设置销毁函数,并设置权限只有合约发布者可以调用,在需要的时候调用销毁函数销毁合约。
  • 另一个方法是在合约中预先设置 delegatecall,由于 delegatecall 保留了函数调用的状态,因此可以更新目标合约的逻辑,并且状态将保留在代理合约中以供更新后的目标合约的逻辑使用。

这两种方法都需要预先的设置,以及发布合约的账号丢失后,也将失去对合约的控制权。

FIBOS 合约账户名就是发布账户的账户名。发布合约时需要发布账号的资源,包括足够的 RAM、CPU 和 NET。

在 FIBOS 中开发者可以使用发布账户随时更新合约代码。相较于以太坊的合约,FIBOS 的合约后期的维护和更新在技术上容易很多,在成本上低了很多。

生态支持

Ethereum:

  1. 开发框架: Truffle 具有以下功能:

    • 内置的智能合约编译,链接,部署和二进制文件的管理。
    • 快速开发下的自动合约测试。
    • 脚本化的,可扩展的部署与发布框架。
    • 部署到公网或私网的网络环境管理功能
    • 使用 EthPM&NPM 提供的包管理,使用 ERC190 标准。
    • 与合约直接通信的直接交互控制台(写完合约就可以命令行里验证了)。
    • 可配的构建流程,支持紧密集成。
    • 在 Truffle 环境里支持执行外部的脚本。

在 Truffle 框架中,可以根据需要编译、部署合约,Truffle 也提供一键启动测试链的工具。

  1. 托管节点: Infura
    Ethereum 的合约可以通过使用 Infura 提供的节点发布合约。

FIBOS:

  1. fibos.js 是 FIBOS 区块链的通用库,具有以下功能:

    • 使用 NPM 提供的包管理。
    • 快速开发下的自动合约测试。
    • 提供合约与客户端交互接口。
    • 提供合约内部所需的 API 接口。
  2. 节点: FIBOS 提供一键脚本发布十分简单易用。
  3. FIBOS-tracker 是一个 FIBOS 区块链数据 API 服务框架,基于 fib-app 框架实现。

    • 提供对 FIBOS 区块数据的 emitter 监听事件。
    • 提供 http 服务,支持 GraphQL 调用。
    • 支持使用 ORM 定制自己的数据模型 model,自定义数据表以及自定义 hook 监听数据。
查看原文

赞 0 收藏 0 评论 0

fibos 发布了文章 · 2019-01-14

FIBOS DAPP 应用场景详解

在去年的 10 月, FIBOS 举办的第一季「一念巨浪」DAPP 大赛圆满结束。大赛共收到 80 多个项目咨询,其中 62 个项目报名成功,最终 29 个项目入围进行最后的路演对决!

为了激励更多有梦想、有创意的开发者和项目方,第二季「一念巨浪」DAPP 征集大赛现已启动!

可能有些朋友对 DAPP 还不是很了解,下面就让我们走进 DAPP 的世界。

什么是 DApp

App 我们都知道是客户端应用,是 application 的简称。DApp 就是 D+App,D 是英文单词 decentralization 的首字母,单词翻译中文是去中心化,即 DApp 为去中心化应用。这是从字面上去理解这个概念,要在脑中形成清晰、准确、必要的概念,还需要深度去理解 DApp。

DApp 的发展

一个新技术的发展,一般会经历触发期、期望膨胀期、幻想破灭期、复苏期、价值期。 同样地,DApp 也在不断进化演变,广义地说,从最初的比特币到现在因 ICO 盛行一时的以太坊,再是各路公链崛起强大,然后是公链、联盟链、私有链齐头并进发展,最后是链上的各种应用应运而生蓬勃发展,现在我们经常说的 DApp 更多的是这样一种定义:

客户端 + 智能合约 + token(通证经济)

FIBOS 提供了 Javascript 语言为基础的智能合约引擎,同时提供了以 Bancor 经济模型为基础的 IBO 通证经济。

之前开发一个app需要一家公司招开发人员进行开发然后推广运营,现在开发DApp可能不需要是一家公司,也可以是个人或自媒体,整个流程可以是:

写白皮书

明确共识机制

Token激励机制

智能合约开发

去中心化社区自治

对比APP,两者最大不同就是中心化与去中心化。App先要有钱,所以先融资;然后再有人,所以招齐人后再开发运营。而DApp则是继承传统App并结合区块链的特点所形成的产物,它更像是众筹模式、共享模式和去中心化模式,DApp先有发起人或组织,写好白皮书明确了共识机制和token分配与激励,持有token的人即为股东,直接和DApp的盈利关联(也可以说用户即是股东),持有的token像股票可以买卖,在支持的交易所交易,所以持有该DApp的token相当于拥有所有者权益。可以想象,未来各个领域都会有DApp,每个人都将因token分类、以token群分。

下面让我们聊聊 DAPP 的应用场景

钱包领域

钱包应用每条公链上都必须有,比特币有自己的钱包,以太坊也有自己的钱包,其他公链如国内的neo、qtum都有自己的钱包。

FIBOS 自主研发的 FO 钱包是一个去中心化的通用数字钱包,它可以便捷的帮助用户进行数字资产管理。FO 钱包支持 EOS 跨链转账,支持资源管理、通证兑换、多账号切换等功能,可以使用钱包发红包、转账、投票、购买资源等等。此外,钱包中还集成了多款 DAPP,涉及方方面面,有一些有趣的小游戏,还可以便捷的充话费。还有一些方便开发者使用的开发工具等等。未来 FO 钱包还会不断迭代,大家可以多多关注它的更新和动态。

内容社区

区块链与内容垂直领域耦合性非常好,利用区块链的特性和技术,做内容的平台越来越多,在这赛道上竞争无比激烈,据我了解的有很多,如国外的steemit,国内的币乎、币问、Primas、Pressone等。

币乎侧重于内容分发,创作者发布文章和读者点赞都会有收益,通过内容平台发行的代币来打赏,建立有效的激励机制,作者、读者和平台按比例分成。作者创作优质文章,读者觉得好就点赞或转发,平台根据阅读量标记为热门文章排在前位。

Primas侧重于内容确权,对创造者发布的文章会利用平台的鹰眼检测系统进行检测是否原创,若是原创就会将文章的关键字如标题、作者和发布时间等上链打包进区块;若是抄袭或有过多重复内容,则发布失败。然后Primas愿景是成为下一代价值内容生态圈,使其内容可信化、优质化。

区块链防伪溯源

区块链在溯源领域的应用涉及方方面面,比如说在食物供应链的溯源应用,以及在高档消费品的防伪应用。

据中国防伪材料市场分析报告统计,全世界受假冒伪劣产品影响的市场金额达到了3000亿美元。18年国内消费品零售总额40万亿左右,结合各方数据推算,国内防伪溯源市场预计4000亿元左右。

高档消费品的防伪溯源——源之链

在防伪溯源领域,数据的安全性、真实性是痛点,区块链的去中心化、不可篡改的记账方式,改变了传统模式,让“信任”真正可信。由于区块链具有数据不可篡改的特性,数据一经上传,就无法更改,因此更容易做到来源可查、去向可追,真正实现责任可追溯。

FIBOS 开发的源之链从事消费品类区块链防伪追溯业务。团队拥有洋河、双沟等多家上市公司产品追溯项目经验。技术上利用物联网、防伪码、区块链加密二维码等方案,将商品流通各环节的数据进行区块链加密处理,通过手机应用查验溯源信息。平台链通B端、C端为用户搭建了溯源产品销售、融合防伪追溯查验、扫码送积分、积分购物、积分兑换通证AF等功能。

“家优鲜+区块链”模式打造信任标签

随着消费升级,消费者对食品的要求越来越高。事实上,食物供应链因涉及生产、运输、仓储、销售等多个环节,在食品质量把控上极为复杂,而区块链作为一项以去中心化为核心的技术,相关数据在交易各方间公开透明,从而有效形成一条信息和价值共享的链条。 区块链在食品领域的应用还有家乐福,2018年12月6日,家乐福正式对外宣布,家乐福中国首个区块链应用落地,上链的首个“家优鲜”产品琯溪蜜柚今天正式上市。

作为家乐福身体力行农产品安全高标准的项目,“家优鲜”对农产品生产进行全程追溯,不仅让处于供应链末端的消费者受惠,也向供应链上端的农业生产者提供帮助、改进种植技能、增产创收。相信区块链的使用,可有效帮助消费者重拾信心,重新建立起对食品行业的信任度。家乐福始终将食品安全与品质视为重中之重,希望借区块链推进农产品可追溯的进程,密切关注从田间到餐桌的每一个环节,为行业树立良好典范。

“区块链+金融”

区块链在金融领域的落地让市场变得更加方便和透明,下面来看看几个重要的应用。

FINX打造去中心化银行

基于 FIBOS 开发的金融类应用「FINX」在全球爆发性的无现金社会的浪潮中,对于没有银行账户的区块链银行业里,拥有先发优势,可以让更多的企业和个人用户受益。「FINX」致力于创造出一个区块链银行,可让您随时随地通过内置交易所存储,发送,接收,投资,提取,兑换和交易数码货币。

DDPocket 钱包让信用创造价值

再看看基于 FIBOS 开发的另一个金融类应用——「DDPocket」,「DDPocket」是实现DD货币转换成现金的平台,解除人们对于加密货币无法兑现 的疑虑。透过DD钱包,DD公司可将DD货币转卖/借贷给用户,用户也可以以现 金购入DD货币,或是将钱包里所拥有的DD货币转卖(DD公司购入),换取现金。

同时,「DDPocket」还有专为大专生设计的购物平台。学生可以在DD商城内买卖物品/服务、也可在内置的交流平台寻找需要的物品/服务。DD商城内的所有交易均使用DD货币,模式可分为两项:

1.消费者对消费者(C2C)学生可将自己的二手电脑、自行车、书籍、笔记等出售,亦可提供补习服务、出租房间等。

2.企业对消费者(B2C)DD公司也会与各商家合作,让商家们提供各种过季优惠商品(如:手机、电脑、电单车)、学术研讨会门票、食物套餐固本、影印服务固本等。在提高商家业绩的同时,也让学生可以获得便宜的商品及服务。

蚂蚁金服打造第一个区块链跨境汇款

除了以上的两个应用,区块链在跨境汇款中也发挥着重要的作用。区块链跨境汇款运用了区块链技术最重要的几个能力:智能合约、共识机制、联盟记账,进而具有交易最终性、多机构联盟记账和智能合约三大能力,而这对于跨境汇款十分重要。跨境汇款中有大量的不同国家/地区、不同币种、不同金融机构、不同参与者协作,又涉及到法律监管汇率等问题,是十分复杂的金融场景,现在看来,区块链技术或许是解决这个问题的方向。

在区块链领域,蚂蚁金服的普惠跨境汇款服务走在了世界的前沿。6月25日蚂蚁金服在香港发布了基于区块链技术的普惠跨境汇款服务,最先支持从香港到菲律宾的汇款:支付宝香港版即AlipayHK可向菲律宾当地电子钱包Gcash汇款,渣打银行负责日终的资金清算和货币兑换服务,基于区块链技术,跨境汇款首次进入秒级时代。区块链跨境汇款服务是全球第一个真正基于区块链的跨境汇款服务,也是蚂蚁金服第一个面向公众的基于区块链的金融服务,此前蚂蚁金服区块链技术已在公益捐款、商品正品溯源、保险追踪、租房管理上应用,这一次终于将区块链应用到蚂蚁金服最核心的金融服务最核心的汇款转账场景上。

“区块链+游戏”

目前区块链游戏大多是博彩性质的,前段时间许多博彩游戏被黑客攻击,导致玩家损失惨重。我们希望能出现一些把游戏和区块链生态结合在一起的优质游戏。

众所周知, DAPP 一直与游戏结合紧密,区块链生态系统下的游戏将打破盈利壁垒,让每一位玩家及推荐者与贡献者都能获得收益,让每一个为生态扩张做贡献的节点,他们的付出都有回报。我们把大部分的盈利都返还给有贡献的节点。通过激励与奖励,让所有人自发参与传播和维护实现快速增长。下面就来看看基于 FIBOS 开发的游戏类应用——加密星球吧。

加密星球利用生态激励激活每一个生态节点,让所有参与者与贡献者有奖励,让他们创造的价值被保护。

  1. 让每个传播者,都应该获得理所应当的收入;
  2. 用户真实拥有游戏内资产,并可借助智能合约去信任流通;
  3. 区块链的跨应用账本特性,使同款IP资产可以被复用,大大增加游戏间的交互性及玩法。
  4. 重塑游戏内经济体系。玩家的投资,每天都应该按贡献分红。

“区块链+旅行”

旅行中大家会遇到很多订票问题,不胜烦扰,区块链落地于旅游行业可以让你的出行更加快捷。

区块链旅行项目通过区块链技术的去中心化旅行服务体系,链接全球旅行服务提供者与消费者,构建透明、可信、高性价比的未来旅行生态链,打造一个“省钱又省心的旅游神器”。

“旅游+区块链”打造复合型旅游区块链生态圈

2018年7月26日,区块链旅行平台星牛旅行日前对外推出APP端产品,将于8月27日正式上线。星牛旅行是基于区块链技术的去中介化旅行服务体系,通过链接全球旅行服务提供者(企业或个人)与消费者,构建透明、可信、廉价、去中介化的未来旅行生态链。

星牛旅行前端应用同时由一系列智能合约完成内部的信息交互和指令执行,在后端,将结合底层服务公有、私有链自身属性和旅游生态行业的特点,涵盖不同的消费、金融、内容、社交等场景,对应不同的技术架构,从而达成复合型旅游区块链生态圈。

区块链让旅行更加快捷

之前,旅游市场几乎全部的交易都被OTA垄断,第三方在提供了信息聚合、细分品类、预定保障等服务的同时,也收取了一定比例的佣金,这些成本都转变为用户高昂的出行费用。区块链旅行通过区块链网络去中心化智能合约体系,将能提供比友商平台更低15%~20%的价格,其可追溯、不可篡改性也对买卖双方的权益与隐私进行保护。

物联网+人工智能

DApp 被大多数人看好的方向在于和物联网、共享经济的结合,比如无人驾驶汽车应用。传统上,一辆无人驾驶汽车得到路况信息需要先传输到中心化服务器,然后服务器再传输给另一辆无人驾驶汽车,若出现服务器故障或者传输网络延迟等情况,汽车之间没有及时通信,路况又是随时变化的,所以就很容易出现事故。如果汽车与汽车能直接通信,一辆无人驾驶汽车实时将路况信息写入区块链,其他无人驾驶汽车则可及时获取路况信息并及时调整,这样要好于中心化管理。

除了上面利用区块链技术做到汽车与汽车之间的信息通信,人工智能也可以充分利用区块链技术加智能合约,做到机器与机器之间的通信交流。借用《浪潮之巅》作者吴军老师的说法:

人工智能 + 区块链 + 智能合约=超级智能

欢迎大家报名第二届【一念巨浪】 DAPP 大赛

以上介绍的 DAPP 应用,希望能够对大家开发 DAPP 有所帮助。同时请对 DAPP 有兴趣的开发者参加 FIBOS 举办的第二届【一念巨浪】 DAPP 大赛,本次大赛已获得 20 多家机构、社区、媒体的大力支持,其中包括创世资本、节点资本、BKFUND、拜占庭资本等知名投资机构;HelloEOS、EOSAsia、IMEOS、BCCN 等强影响力社区;慢雾科技、比特派、BeeDApp、ENU 等多个生态合作伙伴;巴比特、币快报等深度合作媒体。同时获得东南大学区块链实验室等高校学术机构的指导。

查看原文

赞 1 收藏 0 评论 0

fibos 发布了文章 · 2019-01-10

如何在 fibos 上创建快照和使用快照启动节点

本文介绍下如何通过快照启动 FIBOS 节点。

快照创建无需停止节点打包数据比备份数据更方便快捷。如果还不清楚如何启动一个 fibos 节点请参考 启动 fibo节点

fibos 版本 v1.4.1+

如何创建快照

1.配置快照目录

快照生成位置 config.data_dir 为根目录,可以配置

例1

config.data_dir = "./blockData/data";

fibos.load("producer", {
    "snapshots-dir": "snapshots"
});

那么快照生成位置为 ./blockData/data/snapshots

例2

config.data_dir = "./blockData/data";
fibos.load("producer", {
    "snapshots-dir": "../snapshots"
});

那么快照生成位置为 ./blockData/snapshots

2. 载入producer_api

fibos.load("producer_api");

3.生成快照

curl http://127.0.0.1:8870/v1/producer/create_snapshot

例1 调用结果

{
    "head_block_id":"00003070049e51276829f6d1020fa638e5428fc9f8b0532fc60f680d72359dbe",
    "snapshot_name":"./blockData/data/snapshots/snapshot-  00003070049e51276829f6d1020fa638e5428fc9f8b0532fc60f680d72359dbe.bin"
}

例2 调用结果

{
    "head_block_id":"000006a4529a21b72b58c70c262fd3a754930d68b30b0b166f72fc1dbbc376e8"
    "snapshot_name":"./blockData/data/./snapshots/snapshot-000006a4529a21b72b58c70c262fd3a754930d68b30b0b166f72fc1dbbc376e8.bin"
}

如何通过快照启动

1.配置快照文件路径

例1

fibos.load("chain", {
    "snapshot": "./blockData/data/snapshots/snapshot-00003070049e51276829f6d1020fa638e5428fc9f8b0532fc60f680d72359dbe.bin"
});

例2

fibos.load("chain", {
    "snapshot": "./blockData/snapshots/snapshot-00003070049e51276829f6d1020fa638e5428fc9f8b0532fc60f680d72359dbe.bin"
});

2.启动服务

fibos.start();
查看原文

赞 2 收藏 0 评论 0

fibos 发布了文章 · 2019-01-04

FIBOS 周报

FIBOS 稳定币的上线

2018年12月21日,FIBOS 发布了稳定币—— FOD,并且成功通过了社区多签。

2018年12月28日, FIBOS 的稳定币 FOD 正式上线。

早在2018年9月,全球市场在一个月时间内爆发出现了十多种稳定币,市场规模达到了30亿美元。

FIBOS 生态中有不少项目在实体经济落地时需要保障项目价值的稳健发展,需要以稳定币作为通证准备金,为满足生态的发展需求,服务于区块链项目落地的稳定币—— FOD 应运而生。

FOD 在 FIBOS 生态中的价值体现

FIBOS 默认提供了以 IBO 为基础经济模型的发币方式。然而,作为 Bancor 准备金的区块链资产价格受市场影响波动大,又不利于实体项目的落地和发展。因此,需要一种价值相对稳定,价格变化幅度小的的区块链资产作为准备金,这也就是常说的“稳定币”。

FOD 在 FIBOS 生态中如何使用

目前市场上有十多种稳定币项目,全球最大也是最早的稳定币 USDT 财务监管不透明,好几次都出现了「脱锚」的现象,所以我们没有选择 USDT 作为我们锚定的稳定币。经过 FIBOS 研发团队研究,最终 FIBOS 选择监管更严、财务更透明的 USDC 作为稳定币来源。通过去中心化的跨链技术生成稳定币 FOD,USDC 与 FOD 是1:1锚定。具体而言,FOD 主要用途如下:

1.以 FOD 作为项目准备金,发行项目的智能通证。

2.基于 Bancor 模型发行的项目稳定币,与 FOD 是1:1锚定。对于项目方来说,可以选择以 FOD 做准备金,发行项目的智能通证,当 cw=100%时,发行的智能通证就是项目自己的“稳定币”。

3.以项目稳定币为准备金,发行项目的智能通证。

目前,基于 FIBOS 平台有多个项目正在规划基于稳定币发行项目通证。比如,全球最大的游戏虚拟资产交易平台,比价器项目;进口美国高端 Jeep 整车改装项目;拥有一万多会员的酒吧众筹项目等等。相信 FDO 的出现会让更多的项目成功落地到实体经济,促进整个生态系统的良性发展!

深圳率先试点区块链电子发票

微信上线开票功能,深圳开出全国第一张区块链发票

2018年7月2日,国家税务总局批复授权深圳成为全国首个试点区块链电子发票的城市。12月11日,许多深圳市民发现,微信支付的菜单中,多了一个“开发票”的选项。只需按动屏幕,短短1分钟,便可完成从付款到完成开票的全过程。

深圳市税务局局长张国钧介绍“这是我们与腾讯公司合作开发的微信支付开具区块链电子发票功能。”,今年下半年,深圳开出了全国第一张区块链发票。此次微信开票功能的上线,意味着区块链电子发票,正式走入了深圳市民的日常生活。

交易数据即发票信息,区块链电子发票方便市民

“交易即开票”是区块链电子发票最大的特点。区块链电子发票是“互联网+税务”的深度融合产物,是完全依靠算法、而非人力开具出来的消费和支付凭证。

区块链电子发票区别于传统电子发票之处,在于其以区块链技术实现加密处理,具有“分布式”存储、可追溯、不可篡改的优势,通过“资金流+发票流”的合二为一,将发票开具与线上支付相结合,实现了“交易数据即发票信息”。

如今,顾客通过微信付款后,“付款通知”下方比往常多了“开发票”按钮。顾客只需点击按钮,便可调取微信“我的发票抬头”功能,完成开票操作,整个过程不到1分钟。

据 FIBOS 团队调研发现,腾讯内部其实有孵化一个联盟链项目 Trust SQL。目前暂未开源,其目标是结合自有的腾讯云来打造一个「区块链 BAAS」服务。跟深圳税务局合作的这个区块链电子发票服务有没有使用到这个项目,也不得而知。

总体而言,对于像腾讯这样的大公司进入区块链领域,并且真正实施一些落地项目,对区块链领域是一个重大利好。

区块链发票渗入209家企业,有助于税务查验

深圳市税务局统计,目前全市已有7家开票服务商及1个报销平台与区块链电子发票系统实现了对接。截至2018年12月12日,已上线的32家试点企业共开具区块链电子发票17570张,现已完成注册接入企业涉及餐饮业、停车服务、零售业、互联网服务、金融业等行业共计209家企业。

2019年1月1日,六大个税抵扣、社会保险费由税务部门统一征收等一批新规正式实施。今年的个税新规受到社会各界的广泛关注,大家普遍反映中产阶级得到了实惠。在未来,相信区块链落地个税查验也将会离我们越来越近,以后大家也可以通过区块链技术更加详细的了解自己的个税情况。

响马畅谈区块链现状及未来

公链未来的演化路径会是怎样的

很多时候我们会从历史的发展来考虑未来。比如说最初的从比特币到以太坊,是去中心化不断演变的一个过程。很多人认为弱去中心化的就不是区块链的,这样先入为主的观念约束了我们对未来发展的想法和判断,以后很多的区块链可能不是公链,可能是联盟链、私有链,共同组合成类似万链的、多级分层网状结构,响马认为这是区块链的未来,公链的需求会越来越小。等再到下一个阶段呢,社会对公链的需求会再次提升。但那个时候对公链的需求和现在又完全不同。

区块链和传统行业如何结合

响马认为区块链的商业化和产业化会很快到来,社会化会更晚一些。商业化和产业化是需要真正在供给侧和产业相结合,创造更多的产能、提高效率,而社会化更多需要挖掘区块链 to C 的特性,如果目前不能在供给侧创造出价值的话,那么面向 C 端现在还是略微早了一些。

区块链的繁荣生态是什么样子?

一个好的互联网生态,一定是用户可以通过互联网享受到更多的服务,比如抖音、淘宝、微信等等;同样,一个好的区块链生态繁荣起来也需要为用户提供足够多的优质服务,至于这些服务是什么,现在还很难想象得到。这个过程是需要我们去摸索的。

未来的公链更像是 to C 的产品,响马认为接下来两年里面,可能区块链对标的应该是 to B 的产品。现阶段如果直接面向大规模用户提供服务,很容易遇到很多问题,因为 to C 对用户的体验要求是很高的,to B 的产品在现阶段是有需求和用户体验忍受能力的,接下来2年,to B 能够解决多少问题,是决定区块链能不能跑出赛道的最根本的方向。

区块链能改善”技术不值钱“的处境吗?

响马表示区块链解决的问题并不会让技术、或者让生产力更值钱,很多人说区块链能改善生产关系。其实我更加认为,区块链能降低价值流通的成本,让价值传递更快、成本更低,将更碎片化的资产传递给对方,如果能实现,受益的不仅仅是程序员,而是整个行业。

区块链安全—— EOS 遭到回滚攻击

2018-12-28凌晨,攻击 BetDice、ToBet 等游戏的黑客团伙再次对 LuckyMe、GameBet 发动攻击,造成数千 EOS 的损失。此次黑客采用的手法有别于上一次的攻击。本次的攻击为针对项目方的重放攻击。

受攻击游戏的列表

游戏类别时间游戏名损失值
竞猜类12.18晚-12.19凌晨EOSMAX55000EOS
竞猜类12.18晚-12.19凌晨ToBet22000EOS
竞猜类12.18晚-12.19凌晨BigGame14903.18EOS
竞猜类12.18晚-12.19凌晨BetDice200000EOS
竞猜类12.18晚-12.19凌晨TRUSTBET11501EOS

据 PeckShield 报道,其中的竞猜类游戏 BetDice 近一周日均活跃度超 5,000 人,交易额也在 5,000 万 EOS 以上。

PeckShield 创始人蒋旭宪表示,这次攻击背后是同一个团伙或个人。攻击 BetDice 的账号 hnihpyadbunv 创建了账号 eykkxszdrnnc,用来攻击 EOSMax 与 BigGame。账号 eykkxszdrnnc 又创建了子账号 kfexzmckuhat 用来攻击 ToBet。攻击成功后,再频繁创建子账户转移所得资产。

回滚攻击手法分析

我们知道 EOS 采用的共识算法是 DPOS 算法,采用的是 21 个超级节点轮流出块的方式。除了 21 个超级节点外的其他全节点,并没有出块的权限。起到的作用是将收到的交易广播出去,然后超级节点将其进行打包。

说到这里,很容易看出,如果一笔交易是发给除了超级节点外的其他全节点,这笔交易会经历两个过程。首先,这笔交易先被全节点接收,然后交易再被节点广播出去进行打包。而一笔交易是需要超级节点中超过 2/3+1 的节点进行确认之后才是不可回滚的,也就是不可逆的。

这个过程大概需要 3 分钟左右,也就是说,交易发到除了超级节点外的全节点的时候,由于全节点没有打包的权利,此时此刻交易仍然处于可逆状态这是一个核心关键点。

每一个 bp(超级节点),都可以在自己的节点的 config.ini 文件内进行黑名单的配置,在黑名单中的帐号是不能进行交易的,也就是说无论怎样,黑名单的交易都会被回滚。

防御建议

1、针对 DApp 的防御建议

(1)节点开启 read only 模式,防止节点服务器上出现未确认的块
(2)建立开奖依赖,如订单依赖,开奖的时候判断订单是否存在,就算在节点服务器上开奖成功,由于在 bp 上下注订单被回滚,所以相应的开奖记录也会被回滚。

2、针对交易所和中心化钱包的防御建议

建议 EOS 交易所及中心化钱包在通过 RPC 接口 get_actions 查询热钱包充值记录时,应检查充值 transaction 所在的 block_num 是否小于 last_irreversible_block(最新不可逆区块),如果 block_num 大于 last_irreversible_block 则表示该区块仍然是可逆的,存在“假充值”风险。

3、项目方在玩家下注的时候校验交易中的 actor 和 from 是否是同一帐号。

4、节点要实时更新黑名单。

查看原文

赞 0 收藏 0 评论 0

fibos 关注了标签 · 2019-01-02

fibos

FIBOS 是基于 EOS 技术架构开发的新型公链,采用 DPOS 共识机制,满足大规模商业应用的要求,它创新性地采用了基于 Bancor 协议的通证模型,实现通证经济体系的快速建立和健康发展,融合了 EOS 和 fibjs 的 JavaScript 运行环境,扩展了 EOS 的可编程能力,并且能够使用 JavaScript 开发智能合约,让智能合约编程变得简单、高效。

关注 5

认证与成就

  • 获得 70 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

  • FIBOS

    FIBOS is a JavaScript runtime that combines EOS and fibjs. It provides programmability to eos and allows the use of JavaScript to write smart contracts.

注册于 2018-11-09
个人主页被 570 人浏览