最近更新EOS代码，由于历史上最伟大的发明qiang,导致编译过程中某些依赖下载失败，so..

ubuntu 18.04

Ubuntu 的软件源配置文件是 /etc/apt/sources.list。将系统自带的该文件做个备份，将该文件替换为下面内容，即可使用 TUNA 的软件源镜像。

#备份
sudo cp -i /etc/apt/sources.list /etc/apt/sources.list.bak
#编辑
sudo vi /etc/apt/sources.list

将文件内容修改为如下

# 默认注释了源码镜像以提高 apt update 速度，如有需要可自行取消注释
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse

# 预发布软件源，不建议启用
# deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse

保存后，重新sudo apt-get update后，重新编译

数据来源

https://mirrors.tuna.tsinghua.edu.cn/help/ubuntu/
http://mirrors.ustc.edu.cn/help/ubuntu.html

EOS Encrypt

github： https://github.com/EOS-Nation/eos-encrypt

Allows to encrypt & decypt a message with an EOS key pair using AES shared key encryption mechanism.

Decryption is achieved by combining the receiver's private key and the sender's public key to create the private key necessary to decrypt the message.

This module uses eosjs-ecc to perform the required cryptographic operations.

Install

npm

$ npm install --save eos-encrypt

Usage

import { encrypt, decrypt } from 'eos-encrypt';

const public_key = "EOS6M...DW5CV";
const private_key = "5KQwr...zkvFD3";

const message = "Private Message, shhhh!";
const encrypted = encrypt(private_key, public_key, message);
// => TO DECRYPT: eos-encrypt
// .1167451677...23460624..862584768Q+h1AeLQbjfzZJD1Nsx6kk3U/jSNStwoWstz9uNCadw=

const decrypted = decrypt(private_key, public_key, encrypted);
// => Private Message, shhhh!

API

Table of Contents

• encrypt
  • Parameters
  • Examples
• decrypt
  • Parameters
  • Examples
• setMemo
  • Parameters
  • Examples

encrypt

Encrypt Message

Parameters

• private_key string EOSIO Private Key
• public_key string EOSIO Public Key
• message string Message to Encrypt
• options object Optional parameters (optional, default {})
  • options.memo string Serialized Memo (optional, default "TO DECRYPT: eos-encrypt\n")
  • options.maxsize number Maximum character message size (optional, default 256)

Examples

const encrypted = encrypt(private_key, public_key, message);

Returns string Encrypted Message

decrypt

Decrypt Message

Parameters

• private_key string EOSIO Private Key
• public_key string EOSIO Public Key
• message string Encrypted Message
• options object Optional parameters (optional, default {})
  • options.memo string Serialized Memo (optional, default "TO DECRYPT: eos-encrypt\n")

Examples

const decrypted = decrypt(private_key, public_key, message);

Returns string Decrypted Message

setMemo

Set Default Memo

Parameters

• memo string Set Memo

Examples

setMemo("TO DECRYPT: my-dapp\n");

Returns void

直接黏贴Readme了，项目需要参考里面的EOS错误代码规范，转贴推荐下

ENGLISH VERSION

关于

EosProxyServer是PocketEOS的完整的后端服务器，由OracleChain团队研发。

目录

• 简介
• 开发和使用环境
• API使用
• 异常捕获
• 对接新币种
• 创建自发交易
• 有关欧链
• 版权

简介

本仓库为PocketEOS的完整后端代码，大家可以自行编译使用。

本项目提供什么：

 1.接入实时汇率：这里我们主要参考了coinmarketcap，该网站对接了多个交易所，相对来说比较值得信赖；

 2.通用EOS错误代码规范：提供基于错误码的国际化标准，可以较大程度提升用户体验，同时便于教育用户了解EOS底层发生了什么；

 3.服务器中配置公司运营账号，通过接口验证后，发出交易，为用户创建账号。

 4.服务器可以发起交易：可以实现比如创建用户、运营转账、空投、各种合约调用等。

开发和使用环境

如何从源码编译EosProxyServer服务器：

1. 准备一个redis服务器用于缓存第三方汇率

2. 安装IntelliJ IDEA + jdk1.8 + maven 4.0.0

3. 下载
    git clone https://github.com/OracleChain/EosProxyServer.git

4. 使用IntelliJ IDEA导入到工程

5. 编辑服务器配置文件 src/main/resources/application.yml.

 host: redis_server_ip

 port: 6379

 password: redis_passwd

6. 编辑服务器主动交易相关参数 src/main/java/com/oraclechain/eosio/constants/Variables.java.

 public static final String eosAccount = "tx_account_name";

 public static final String eosPrivateKey = "tx_private_key";

7. 编译运行.

8. 可以使用POSTMAN或浏览器进行测试：

API使用

异常捕获

为了给客户端提供一个稳定使用环境、平滑的版本切换、统一的错误定位和提示，我们全局捕获了EOS RPC接口中的异常，并且针对各种错误接口调用进行了封装。

通过返回完全可靠的错误代码，客户端就可以根据欧链定制的错误代码集，进行国际化，并且和EOS升级前后版本进行兼容。

EOS代码中，异常主要分为三层：

第一层为FC layer，主要处理graphene FC工具类产生的异常。

第二层为CHAIN layer，主要处理EOS逻辑代码中的异常。

第三层为contract layer，可在合约中形成规范，除了给用户提供统一的错误代码外，还可定制一些适用于特定合约的特定错误代码。如果你定制了合约层错误，可以在我们的统一错误错误抓取类中解析合约错误.

另外，我们发起了一个EOS错误码的国际化项目，提供给客户端使用：EOSIO API ERROR CODE SPECIFICATION。如果你对维护这个项目感兴趣，可以通过telegram联系我们.

FC层异常

EOS的底层框架使用的是graphene，而graphene抛出的错误被统一定制到了FC exceptions文件中。

我们这里为了把错误码统一起来，对FC error code进行了统一偏移.

链层异常

EOS中的主要错误都是CHAIN exception，这里我们对错误代码进行了直接引用

对接新币种

对接新币种

下面以oraclechain token为例，合约地址为octtothemoon，货币符号为OCT

1.修改dto/AccountAssetInfo.java实体，用于下面的接口返回：

private String oct_balance;
private String oct_balance_usd;
private String oct_balance_cny;
private String oct_price_usd;
private String oct_price_cny;
private String oct_price_change_in_24h;
private String oct_market_cap_usd;
private String oct_market_cap_cny;

2.修改controller/QueryTabController.java中的接口get_account_asset，以支持返回更多币种和相应市场汇率等参数：

//获取用户余额，此处传入
BigDecimal oct_balance = blockServiceEos.getBalance(
    Variables.eosChainUrl,
    "octtothemoon",
    "OCT",
    "octgenerator");

//获取第三方汇率，并且加入缓存（此处缓存的刷新方式比较简单粗暴，大家可以在流量更大之后修改）
redis_key = Variables.redisKeyPrefixBlockchain+ Variables.redisKeyEosCoinmarketcapMid+ "oct";
CoinMarketTicker coinMarketTicker_oct = redisService.get(redis_key, CoinMarketTicker.class);
if(coinMarketTicker_oct == null){
    try{
        req_url.append(Variables.COINMARKETCAP_TICKER).append("oct").append("?convert=CNY");
        result = HttpClientUtils.get(req_url.toString(), "UTF-8");
        coinMarketTicker_oct  = JSON.parseArray(result, CoinMarketTicker.class).get(0);
        redisService.set(redis_key, coinMarketTicker_oct, Variables.redisCacheTimeout);
    }
    catch (Exception e)
    {
        throw new ExceptionsChain(ErrorCodeEnumChain.unknown_market_id_exception);
    }
}

//接下来设置需要返回的用户余额
BigDecimal oct_usd_price = new BigDecimal(coinMarketTicker.getPrice_usd());
BigDecimal oct_cny_price = new BigDecimal(coinMarketTicker.getPrice_cny());
double oct_price_change_in_24h = Double.valueOf(coinMarketTicker.getPercent_change_24h());//.doubleValue();
asset_info.setOct_balance(oct_balance.setScale(Variables.precision, RoundingMode.DOWN).toPlainString());
asset_info.setOct_balance_usd(oct_balance.multiply(oct_usd_price).setScale(Variables.precision, RoundingMode.DOWN).toPlainString());
asset_info.setOct_balance_cny(oct_balance.multiply(oct_cny_price).setScale(Variables.precision, RoundingMode.DOWN).toPlainString());
asset_info.setOct_price_usd(oct_usd_price.toString());
asset_info.setOct_price_cny(oct_cny_price.toString());
asset_info.setOct_price_change_in_24h(Double.toString(oct_price_change_in_24h));
asset_info.setOct_market_cap_usd(coinMarketTicker.getMarket_cap_usd());
asset_info.setOct_market_cap_cny(coinMarketTicker.getMarket_cap_cny());

创建自发交易

自发交易

我们可以在src/main/java/com/oraclechain/eosio/constants/Variables.java中指定一个服务器自发交易的用户名和对应active私钥。

然后可以使用push_action/create_account/create_vip_account接口发起交易请求。

有关欧链

OracleChain（欧链）作为全球第一个直面区块链生态Oracle（预言机）需求的基础应用，将区块链技术服务和现实生活中的多种需求场景直接高效对接，深耕这个百亿美金估值的巨大市场。

OracleChain是一个多区块链的去中心化Oracle技术平台，采用自主的PoRD机制，将现实世界数据引入区块链，并将此作为基础设施为其他区块链应用提供服务。
OracleChain将在区块链内提供现实世界数据的Oracle服务，同时还可以提供跨链数据的Oracle服务。基于OracleChain除了能实现Augur、Gnosis等预测市场（Prediction Market）应用的功能之外，还能支撑对链外数据有更高频率访问需求的智能合约业务，比如智能投顾等场景。

OracleChain将改变当前区块链应用的开发模式，建立全新的生态圈，服务于真正能改变现实世界的区块链应用。

OracleChain的使命是“让世界与区块链互联”，立志成为链接现实世界与区块链世界的基础设施，通过把外部数据引入区块链来实现链内链外的数据互通，OracleChian将是未来区块链世界中最高效的获取链外数据的服务提供平台。

版权

发布于 GNU/LGPL Version 3 许可证书下

感谢

椭圆曲线算法及签名工具：EOSCommander，感谢PLAYERONE.ID团队的贡献。

如果您觉得我们的开源项目对您有帮助，请为oraclegogogo投上一票，谢谢。

今天去重新整理了下关于EOS的资料，特别了解了下EOS的增发机制，希望有助于大家更深入的了解EOS

1.EOS介绍

EOS的全称为Enterprise Operation System，即为商用分布式应用设计的一款区块链操作系统。EOS的设计目的在于解决现有的区块链应用性能低、安全性差、开发难度高以及交易手续费高的问题。EOS交易无需手续费。任何团队都可以在EOS上以比较快的速度开发出所需要的Dapp（基于区块链的分布式应用），EOS框架内发生的经济活动用EOS代币完成交易。EOS是区块链3.0的代表。

2.EOS代币发行

EOS代币的初始发行总量共10亿枚，它的发行机制很有趣，1亿留给创始团队，作为开发者的回报。其余9亿对外公募开放，公募阶段分为两个阶段，第一阶段向市场投放2亿枚EOS代币，这个在2017年7月1日完成。前期的2亿枚EOS代币投放，用于激活市场，向投资者介绍EOS的功能和它所具备的价值。第二阶段，2017年7月2日开始每天200万个公开众筹，持续336天，一共7亿个，后期以稳定的增发量逐步释放剩余的7亿枚EOS代币。这个设计很有趣，在这个时间的段，每天都可以参与众筹，同时二级市场也可以买入EOS，这边每天有200万产出，市场还可以消化，也可以搬砖套利，最主要的是，这个价格就完全由市场价格决定了这些新出来的价格。

3.EOS的增发体系及节点奖励分配

针对记账节点所设计的经济激励机制是区块链项目不可缺少的重要组成部分，EOS则是通过增发的方式来给予节点奖励，支付其工资。讲解EOS的增发体系，以及节点奖励分配规则。
主要结论：
1.EOS采用领取时触发的连续增发方式，最高年通胀率近似为5%。
2.增发的EOS主要用于节点奖励和提案基金两方面，其中节点奖励占五分之一，即1%的年通胀率，剩下的即提案基金，约4%。
3.节点（包括超级节点和备用节点）奖励的四分之一，即0.25%的年通胀率为超级节点的出块奖励，剩下的0.75%为所有节点的得票率奖励。
4.备用节点无出块奖励，只有得票率奖励且要求在100个EOS以上，否则便不算备用节点，无法领取奖励。接下来进行详细说明，可以分为增发方式和节点奖励计算及领取（claim）规则两部分进行：

3.1增发方式

1.增发频率

EOSIO并非每年只增发一次，一次性增发完全年所有的EOS，而是采用连续增发方式，即任何节点领取（claim）时都会触发系统的增发动作，这也就意味着，增发是根据流动时间长度不定期发生的。

2.增发数量

每次触发增发时，系统增发的数量按如下公式计算：每次增发数量=年通胀系数（4.879%） 当前EOS总量 上一次增发到本次增发的时间间隔（微秒）/ 每年总时间（5272436001000000微秒）·年通胀系数为什么不是5%？简单来说，5%是每年只增发一次的年通胀率，但EOS采用的是无限次数增发的方式，因此，在这种增发方式下求出来的年通胀系数为4.879%，可使得EOS的年通胀率近似为5%。·设所有BP全年领取的总次数（即增发次数）n为无穷大，单次通胀率为x。那么在EOS初始总量为10亿，一年增发后数量为10.5亿的情况下，可得等式10乘以（1+x）的n次方等于10.5，求极限可得年通胀系数x乘以n等于ln1.05，即4.879%。

3.增发用途

EOS每年增发将近5%，主要用于节点奖励和提案基金两方面：

• BP奖励：增发数量的五分之一，即1%的年通胀率，又分为两部分
• 出块奖励：BP奖励的四分之一，即0.25%的年通胀率
• 得票率奖励：BP奖励减去出块奖励，即0.75%的年通胀率
• 提案基金：增发数量减去BP奖励，即4%的年通胀率

3.2节点奖励计算及领取规则

1. 出块奖励出块奖励只向21个超级节点发放，其中涉及到一个出块奖励池的概念，由于每个节点领取时都会增发部分EOS，所以所有未领取的出块奖励都会放在出块奖励池中等待节点领取。每次单个节点领取（claim）时，能领取到的出块奖励数量计算公式如下：单个节点可领取的数量=出块奖励池里的EOS数量 * 该BP未领取奖励的出块数量 / 所有未领取奖励的区块数量
2. 得票率奖励得票率奖励向超级节点和备用节点发放，其中涉及到一个得票奖励池的概念，由于每个节点领取时都会增发部分EOS，所以所有未领取的得票率奖励都会放在得票奖励池中等待节点领取。每次单个节点领取（claim）时，能领取到的得票率奖励数量计算公式如下：单个节点可领取的数量=得票率奖励池里的EOS数量 * 该BP的得票权重 / 所有BP的总得票权重
3. 领取（claim）条件节点领取奖励需满足以下条件：

• 只有超级节点和备用节点才能领取奖励
• 同一个节点两次claim间隔时间不能少于24小时
• 备用节点无出块奖励，只有得票率奖励且需要在100个EOS以上，否则便不算备用节点，无法领取奖励

转载自：https://www.jianshu.com/p/14e78b0f5a71

投票的分数是怎么计算的

score_of_vote=stake_of_EOS∗2^{current_year−2000}
举个例子，比如现在是2018年7月1号0点，我抵押了100个eos，那么我给超级节点A投了一票的分值就是：100 * 2^{18.5} = 37072760
过了半年，到了2019年1月1号0点，还是抵押了100个eos，那么我再次给超级节点A投了一票，那么节点A的总得分会先减去我前一票的分值37072760，然后再加上我当前的分值：100 * 2^{19}=52428800，详情可参见源码
当减少或者增加自己抵押的eos时，以前的投票的分数也会被即时更新，被投的节点总得分也会相应减少或增加。所以就是为什么你明明已经给某节点投过票，他们还在催你继续给他投的原因了，因为可能尽管你抵押的EOS数量没变，但你不同时刻的每一票的的分数是不一样的，它是随着时间递增的。

投票账户数是什么意思

投票账户数是从另一个维度来描述节点的支持率。表示有这么多个EOS用户来给他们喜欢的节点投票。不过，节点的排名并不是根据投票账户数来的，而是看上面讲的投票的总得分数来排序的。
所以你会经常发现有些节点的投票账户数很少，但是他们的得分却很高，原因就是有很多EOS大户给他们投票了，一个大户的一张票含金量非常高了。
前段时间发现一个很有意思的帐户 bpvoter.one，这个帐户下面创建了600多个小号，然后随便点进一个小号大概率都可以发现他们都抵押了2000到5000不等的EOS，这些小号基本上除了投票之外啥也不干，为啥不直接用一个帐号投呢。嘿嘿，人多热闹嘛，你懂的~

待申领奖励是怎么来的

节点们辛辛苦苦给我们出块、记账，活可不是白干的（每年的服务器成本还是很高的）。再加上EOS通过一些比如竞拍、买卖RAM过程中的手续费等操作会白白烧掉EOS，没有增发的话也会导致通货紧缩，所以有了每年增发不超过5%的EOS。那么这些增发的EOS是怎么分配的呢？
首先，增发的这部分EOS中的80%会打到一个叫 eosio.saving的账户里，可以看到现在为止已经有9百多万个EOS了，据说这账户里的EOS会用于社区建设。
然后，剩下的20%就是奖励给节点的了。这部分奖励又分两部分，其中的25%是作为出块奖励，剩下的75%就是我们这篇文章要介绍的投票奖励了。
那么这每年增发的5%里的20%里的75%的EOS是按什么规则分配给这么多节点的呢？

合约版本1.3.0之前的投票奖励分配规则

之前的分配规则比较简单粗暴，各自按照其得票的分数占比来瓜分这些奖励。以此刻的排名第一的eoshuobipool为例子，此时它的得分占比为2.596%，那么假如从现在开始它保持这个得票比率坚持一百年不动摇，那么它的得票奖励一年获得的奖励大致就是：
1000000000*0.05*0.2*0.75*0.02596 = 194700
每天的得票奖励大约为194700/365=533。不过这并不是一个节点的全部奖励，别忘了上面说过的还有出块奖励的哈。

合约版本1.3.0之后的投票奖励分配规则

终于来到本篇文章的重点了，该版本发布说明在 这里。新的分配规则在New producer pay algorithm章节里有说明，反正我是读不太懂，只能去源码里读全球通用语言了。
首先介绍一下大背景，新版本引入了一个叫做votepay share的概念，通过阅读代码我理解为这个新出的概念是一个类似于 得票分数随着时间成正比增长的股份 ，后面就是依据这个得票股份占比来分配投票奖励。这个得票股份的计算大致如下：
得票股份=得票分数*时间差
这个时间差就是任何两个 涉及到更新得票分数 的操作之间的时间差，比如：投票给某节点、增加/减少抵押的EOS、节点的申领奖励的操作等等。
如果仅仅是这样的话，其实跟旧规则差别不大，只是换个壳而已，但是其中有一个特别的限制：当节点有超过三天没有做claimrewards操作的时候，它就申领不到任何奖励，这些奖励会变相地被别的勤快的节点领走。
那么这个特别的限制会带来什么影响呢？你也许会说，现在的节点基本上都是天天领奖励，有些节点甚至都写了个脚本天天定时领，很少会有超过三天没领的。嗯，对于前21个出块节点来说是这样的，但是备选节点呢？我们知道通常备选节点没有机会出块，所以只有得票奖励，而得票奖励不满100EOS是无法领取的，所以就极有可能会造成三天没有claimrewards操作的尴尬情况。如果这次新版本的目的就是过滤掉垃圾备选节点的话，那我可以悄悄地告诉你一声，这个版本的系统合约是有bug的。
解释这个bug前，得先了解下新版本的逻辑，从两个action来阐述吧，一个是给节点投票的voteproducer，另一个就是节点的申领操作claimrewards。便于后面示例的解释，先给出一个宏定义：

Voteproducer

Claimrewards
因为部署了新版本的系统合约后，还需要节点手动做一次updtrevision才开始走新版本的得票奖励结算逻辑，之后可以手动用regproducer重新更新一次节点，或者在下一次claimrewards的时候自动更新一次。
当updtrevision与regproducer/claimrewards之间无涉及到更新得票分数的操作时

当updtrevision与regproducer/claimrewards之间有涉及到更新得票分数的操作时

示例总结

• 通过示例1、2、6、7可以知道节点超过3天不claimrewards的话，得票奖励会被清0，损失的奖励继续在得票奖励池子里。等于变相的增加了其他节点的奖励。
• 通过示例8、9可以知道节点在做完updtrevision操作后，要尽快执行一次regproducer或者claimrewards操作，否则会丢失这期间的可能的来自用户投票的奖励。这也是原文里最后一句话说可能遗失某些奖励的原因。

关于bug

现在再来解释前面提到的bug，这个bug存在于判断本次claimrewards离上次claimrewards是否已经超过3天。
相关源码如下:

if( producer_per_vote_pay < min_pervote_daily_pay ) {
         producer_per_vote_pay = 0;
}

......

_producers.modify( prod, 0, [&](auto& p) {
   p.last_claim_time = ct;
   p.unpaid_blocks   = 0;
});

在判断完得票奖励不足100EOS时，没有做任何处理，代码会径直走到p.last_claim_time = ct;这一行，个人觉得这应该是个bug，因为备选几点可以写个定时脚本天天做一次claimrewards操作，尽管他们可能并不能申领到任何奖励，但是依旧能成功刷新他们的last_claim_time时间。这样的话，新版本的关于超过3天未做claimrewards的判断就不可能成功了。

原文地址：https://articles.eospark.com/?p=74