郑君的学习笔记

要比昨天进步一点点

发表于 分类于 本文字数： 926 阅读时长 ≈ 1 分钟

奇异递归模板模式 CRTP 静态多态

（curiously recurring template pattern，CRTP）
静态多态（static polymorphism）
还是 静态多态这个名字比较好理解，在编译期决定调用函数

优点：
由于静多态是在编译期完成的，因此效率较高，编译器也可以进行优化；
有很强的适配性和松耦合性，比如可以通过偏特化、全特化来处理特殊类型；
最重要一点是静态多态通过模板编程为C++带来了泛型设计的概念，比如强大的STL库。

缺点：
由于是模板来实现静态多态，因此模板的不足也就是静多态的劣势，比如调试困难、编译耗时、代码膨胀、编译器支持的兼容性，不能够处理异质对象集合。

// The Curiously Recurring Template Pattern (CRTP)
template<class T>
class Base
{
    // methods within Base can use template to access members of Derived
};
class Derived : public Base<Derived>
{
    // ...
};
template <class T>
struct Base
{
    void interface()
    {
        // ...
        static_cast<T*>(this)->implementation();
        // ...
    }

    static void static_func()
    {
        // ...
        T::static_sub_func();
        // ...
    }
};

struct Derived : Base<Derived>
{
    void implementation();
    static void static_sub_func();
};

在上例中，Base::interface()，虽然是在struct Derived之前就被声明了，但未被编译器实例化直至它被实际调用，这发生于Derived声明之后，此时Derived::implementation()的声明是已知的。
这种技术获得了类似于虚函数的效果，并避免了动态多态的代价

发表于 分类于 本文字数： 359 阅读时长 ≈ 1 分钟

https://ncase.me/ballot/
https://medium.com/@thomas.cox_39839/why-30-stake-weighted-approval-votes-for-eosio-1402b994bf20
https://plato.stanford.edu/entries/voting-methods/#2

为什么一个用户有三十张选票而不是一张？

EOSIO社区的一位合伙人Todor对基于同意投票机制的投票行为进行了模拟，他分别模拟了每个账户拥有从1到50张选票时候的投票情况。他的数学模拟表明，如果要减小少数人互相勾结控制主链的风险，每个账户拥有30票比一账户一票更好。

于我而言，BitShares以及Steemit在过去几年表现稳定的一大原因就是因为采取了每账户多枚选票的制度。

发表于 更新于 分类于 本文字数： 1.8k 阅读时长 ≈ 2 分钟

注意之前 BM 提案中的 SEOS 在实际实现中并未出现。

简单的业务步骤：

  1. 出借方向 REX 账户存入一定数量的 EOS（比如 1000 个 EOS），同时指定好投票对象或代理
  2. 使用 REX 账户的余额购买 REX 代币，比如 1000 个 REX 代币作为凭证，持有时间需要大于4天，才可以赎回。
  3. 承借方向 REX 账户支付一定数量的 EOS（比如 10 个 EOS）作为租金，来获取相应数量的CPU资源。
  4. 租赁期（最少30天）满后，承借方对 CPU 的使用权限到期，出借者通过将 1000 个 REX 代币归还 REX 账户，拿到本金与利息—— 1010 个 EOS。

主要解决如下问题：

  1. 建立一个市场，可以通过支付一小部分 EOS 价格来租赁相关的资源。
  2. 返还租赁费用，以及网络费用（例如：eosio.ramfee，eosio.names）给出租者
  3. 保护那些在价格波动时需要使用网络资源的账户
  4. 通过投票或者参与到资源市场来提高网络安全

核心是去掉 EOS 随意抵押和不理性抵押行为，只保留那些真正需要使用 CPU 的 EOS 抵押行为，
这样全网 CPU 的 EOS 抵押量就可以真实反映当前 CPU 的需求量，这样反映出的 CPU 价格才是真实的合理的

阅读全文 »

发表于 分类于 本文字数： 62 阅读时长 ≈ 1 分钟

推荐阅读，一本讲我们思维，想法是如何受到化学物质影响的书，挺好玩儿的。看完了，似乎没啥印象了，有时间再看一次吧。
最近比较忙。

aa14c003.png

发表于 分类于 本文字数： 526 阅读时长 ≈ 1 分钟

转载

在官网(https://www.scootersoftware.com/download.php)下载Beyond Compare并安装成功后：

执行如下操作:

1.进入Beyond Compare应用程序MacOS目录下(/Applications/Beyond Compare.app/Contents/MacOS)
2.将主启动程序BCompare重命名为BCompare.real
3.在同级目录下新建一个脚本文件命名为BCompare，文件内容往下看
4.给新建的文件BCompare，授权文件执行权限

1.创建BCompare文件命令如下：

在这个脚本里面写如下代码，第一行是注明解释器，第二行是删除注册信息，第三行是启动真正的主程序。

#!/bin/bash
rm "/Users/$(whoami)/Library/Application Support/Beyond Compare/registry.dat"
"`dirname "$0"`"/BCompare.real $@
chmod a+x /Applications/Beyond\ Compare.app/Contents/MacOS/BCompare

发表于 更新于 分类于 本文字数： 2.8k 阅读时长 ≈ 3 分钟

THE GAME
Elementals Battles is a single player card game set in a fantasy world where you, the player, harness the power of Wood, Fire, and Water to dominate your opponent! The game is played against a smart-contract based AI, and is deployed on a live EOSIO blockchain.

The versions that we used for this tutorial are:

Docker version 17.06 or newer
EOSIO version 1.2.5
eosjs version 20.0.0-beta1

The quickest way to set up a development environment is to use a prebuilt and prepackaged Docker image which can be obtained from: https://hub.docker.com/r/eosio/eos-dev/

阅读全文 »

发表于 更新于 分类于 本文字数： 1.2k 阅读时长 ≈ 1 分钟

参考

Bancor 算法由 Bancor Network 项目提出应用，希望通过数学公式自动调节数字资产之间的兑换价格。
Bancor算法背后有一套数学模型，这个模型纳入了市场需求的因素，以此来决定token的发行数量和单价。

用来解决流通性不足的问题

使用Bancor算法发行的token直接采用人－机（智能合约）交易，不需要传统数字货币交易需要的对手盘，有效解决了绝大部分小币种流通性不足的问题，相当于以智能合约担当了传统金融市场做市商的角色。

为其代币内嵌价格发现和流动机制。这些“智能代币”能把一个或数个代币作为储备金，让任何人随时通过智能合约快速兑换、销毁代币或储备金。
Bancor白皮书指出。

假设一个智能代币ABCCoin 有一个连接器，该连接器持有一定数量的XYZCoin。此外，假设另一个智能代币NEWCoin，其连接器也持有XYZCoin。那么先将ABCCoin 转换为XYZCoin，然后将XYZCoin 转换为NEWCoin，用户就可以把ABCCoin 转换为NEWCoin。用户只需要进行一个操作，以上过程在后台无缝完成。

阅读全文 »

发表于 分类于 本文字数： 96 阅读时长 ≈ 1 分钟

简单的理解就是占比 80% 的不重要的部分因为数量大使得最终的利润超过了占比 20% 的重要的部分。
强调的是那些数量占绝大多数的个体的商业价值，它们单个的值虽然极低，但是这个长长的尾巴，总和不可小觑。

发表于 分类于 本文字数： 1.5k 阅读时长 ≈ 1 分钟

EOS 已经将共识机制从 DPoS 升级为了 BFT-DPoS（Byzantine Fault Tolerance - Deligated Proof of Stake，带有拜占庭容错的委托股权证明）

DPOS

EOS 项目刚刚发布的时候的共识机制是DPoS，类似于 Bitshares 和 Steem，这种共识机制采用随机的见证人出块顺序，出块速度为 3 秒，交易不可逆需要 45 秒。

为什么需要 45 秒呢？因为 DPoS 下，见证人生产一个新区块，才表示他对之前的整条区块链进行了确认，表明这个见证人认可目前的整条链。而一个交易要达到不可逆状态，需要 2/3 以上的见证人确认，在 EOS 里就是 15 个见证人。
也就是 15BP * 3s = 45秒，当第 15 个 BP 产区块的时候就说明大于 2/3 的节点做了确认。

BFT

在传统DPoS共识机制中，我们让每个见证人在出块时向全网广播这个区块，但即使其他见证人收到了目前的新区块，也无法对新区块进行确认，需要等待轮到自己出块时，才能通过生产区块来确认之前的区块。

在新的机制下，每个见证人出块时依然全网广播，其他见证人收到新区块后，立即对此区块进行验证，并将验证签名完成的区块立即返回出块见证人，不需等待其他见证人自己出块时再确认。

从当前的出块见证人看来，他生产了一个区块，并全网广播，然后陆续收到了其他见证人对此区块的确认，在收到2/3见证人确认的瞬间，区块（包括其中的交易）就不可逆了。交易确认时间大大缩短，从45秒缩短至3秒左右（主要为等待生产区块的时间）。这种机制可以称为初级版的BFT-DPoS共识机制。

BFT-DPoS

为了挖掘EOS系统的性能，Daniel Larimer在以上基础上又进行了修改。首先，他将出块速度由3秒缩短至0.5秒，理论上这样可以极大提升系统性能，但带来了网络延迟问题：0.5秒的确认时间会导致下一个出块者还没有收到上一个出块者的区块，就该生产下一个区块了，那么下一个出块者会忽略上一个区块，导致区块链分叉（相同区块高度有两个区块）。

比如：中国见证人后面可能就是美国见证人，中美网络延迟有时高达300ms，很有可能到时美国见证人没有收到中国见证人的区块时，就该出块了，那么中国见证人的区块就会被略过。

为解决这个问题，Daniel Larimer将原先的随机出块顺序改为由见证人商议后确定的出块顺序，这样网络连接延迟较低的见证人之间就可以相邻出块。

比如：日本的见证人后面是中国的见证人，再后面是俄罗斯的见证人，再后面是英国的见证人，再后面是美国的见证人。这样可以大大降低见证人之间的网络延迟。使得0.5秒的出块速度有了理论上的可能。

为了保证万无一失，不让任何一个见证人因为网络延迟的意外而被跳过，Daniel Larimer让每个见证人连续生产 6个区块，也就是每个见证人还是负责3秒的区块生产，但是由最初的只生产1个变成生产6个。最恶劣的情况下，6个区块中，最后一个或两个有可能因为网络延迟或其他意外被下一个见证人略过，但6个区块中的前几个会有足够的时间传递给下一个见证人。

再来讨论BFT-DPoS的交易确认时间问题：每个区块生产后立即进行全网广播，区块生产者一边等待0.5秒生产下一个区块，同时会接收其他见证人对于上一个区块的确认结果。新区块的生产和旧区块确认的接收同时进行。大部分的情况下，交易会在1秒之内确认（不可逆）。这其中包括了0.5秒的区块生产，和要求其他见证人确认的时间。 （TODO 这里有问号？旧块确认如果数量不足，那么新块链接在旧块上也会变为分叉块丢掉。）

EOS系统规定，一旦区块达到不可逆状态（2/3见证人确认），就无法在此之前进行分叉，保证了交易的永久可信。