您正在查看: EOS-新手教程 分类下的文章

基于Bancor 算法两种资源互换的算法讲解

场景

BCS Token 购买 FF 资源

算法文字描述

FF Bancor 算法过程中,并不是将 BCS 和 FF 直接用价格曲线进行兑换,而是引入了中间 token——FFCORE,对应于 Bancor 中的 Smart Token。

BCS 到 FF 的兑换过程就涉及了两个公式,所以上文中用一个公式来举例就很不严谨,只是为了定性的说明价格特性。

从代码中可看到BCS与FFCORE的兑换公式为:

其中,E为BCS到FFCORE所能兑换的数量,R是FFCORE的初始发行总量,C1为当前BCS余量,T1为用于购买的FF数量,F为常量参数

将上述公式的进行反向整理设计,即可得到FFCORE与交易额的兑换公式为:

其中,T2是准备购入的FF数量;C2为可分配的FF余量。将中间变量E代入即可得出用于购买的BCS数量(T1)与可兑换到的FF数量(T2)之间的关系。

为方便直观的理解,可以对公式进行简化,得到:

可以看到随着可买FF余量(C2)的降低或者BCS数量(C1)的增多,FF的价格会加速增长(即同样付出T1的BCS下,可换取到的FF数量T2变少了)

EOS dump 以及 ubuntu设置coredump

EOS 编译Debug

./scripts/eosio_build.sh -o Debug

ubuntu设置coredump

sudo sysctl -w kernel.core_pattern=/corefiles/core.%p.%e
sudo mkdir /corefiles
sudo chmod -R 777 /corefiles
ulimit -c unlimited

nodeos异常退出时,就会在/corefiles/生成dump文件

EOS Table 倒序删除

数据库中只保留最新的100条记录,旧纪录删除

// 最多100条
besthistory_tables besthistory_table(_self, _self.value);
total_count = 0;
auto itr_besthistory = besthistory_table.rbegin();
while(itr_besthistory != besthistory_table.rend()){
    if(total_count >= 99){
        auto itr = besthistory_table.erase(--itr_besthistory.base());
        itr_besthistory = std::reverse_iterator(itr);
    } else {
        total_count++;
        itr_besthistory++;
    }
}

EOS nodeos api 中继模式

今天EOSIO官方开发提交的(New options for api nodes - 2.0) 审核通过了。

配置新增加配置

p2p-accept-transactions

允许评估通过p2p 网络接收的事务(如果有效)
默认值true

api-accept-transactions

允许评估和中继API事务(如果有效)
默认值true

配合read-mode一起使用

speculative

在“投机”模式下:数据库包含区块链中的交易状态变化,直到头块以及尚未包含在区块链中的某些交易。

head

数据库仅通过区块链中直到头部的交易包含状态更改; 如果有效,将中继节点接收到的事务。

配合配置
p2p-accept-transactions = false
api-accept-transactions = true

read-only

数据库仅包含区块链中直到主块的事务的状态更改;
通过P2P网络接收到的交易不会被中继,并且无法通过链API推送交易。
(不推荐使用此模式:可使用 p2p-accept-transactions和api-accept-transactions同为false代替)

irreversible

数据库仅包含区块链中直到最后一个不可逆块的事务的状态更改;
通过P2P网络接收到的交易不会被中继,并且无法通过链API推送交易。

配合配置
p2p-accept-transactions = false
api-accept-transactions = false

注意点

read-onlyirreversible模式下,api-accept-transactionsp2p-accept-transactions会强制修改为false.

更新支持

此时 2.0.4 以支持此更新
https://github.com/EOSIO/eos/releases/tag/v2.0.4

在read-only该选项read-mode的参数nodeos已被弃用。这是可能实现与相同的行为read-mode = head,p2p-accept-transactions = false和api-accept-transactions = false

使用read-mode = irreversiblenow需要进行设置p2p-accept-transactions = false并api-accept-transactions = false避免在启动时进行断言

EOS 2.0之VM改进和参数设置

从EOS 2.0发布到现在有段时间了,今天单独研究下EOS VM的改进,以及相关的参数配置

引用官方介绍

借助EOSIO 2,我们将发布一个名为EOS VM的新WASM引擎,该引擎由三个组件组成,每个组件都有自己的功能并提供特定的性能增强。
区块链WebAssembly执行的强大组件三重奏

EOS VM Interpreter (eos-vm)

EOS VM解释器是一个WebAssembly解释器,提供了极快的解析/加载,确定性和高效的时限执行。从头开始设计解释器,使我们能够为将来对智能合约的调试支持腾出空间。

EOS VM Just In Time Compiler (JIT) (eos-vm-jit)

EOS VM即时(JIT)编译器是一种WebAssembly编译器,它采用WASM并即时生成本机代码。与WABT,Binaryen和EOS VM解释器之类的解释器相比,该体系结构能够非常快速地执行WASM智能合约,并提供显着的性能优势。这种JIT解决方案的绝对速度使我们能够在区块链上使用它,而无需其他解决方案进行较长的块编译时间。

EOS VM Optimized Compiler (eos-vm-oc-enable)

EOS VM Optimized编译器是EOS VM的第三个组件,它使用了利用多遍编译架构的专用编译器框架(LLVM)。通过优化编译器生成的本机代码通常比在WABT,Binaryen,EOS VM解释器和EOS VM JIT中执行的相同代码快一个数量级。最重要的是,它甚至比现有的WAVM引擎还要快,但是与WAVM不同,它可以利用我们的分层设计在区块链上安全使用。

参数配置

开启eos-vm-jit

wasm-runtime = eos-vm-jit

对于wasm-runtime还支持以下选项

  • wabt
  • eos_vm
  • eos_vm_jit
  • eos_vm_oc //EOS VM OC is a tier-up compiler and works in conjunction with the configured base WASM runtime. Enable EOS VM OC via 'eos-vm-oc-enable' option

开启 eos-vm-oc-enable

eos-vm-oc-enable = true

还可修改其他参数

  • eos-vm-oc-cache-size-mb // Maximum size (in MiB) of the EOS VM OC code cache
  • eos-vm-oc-compile-threads // eos-vm-oc-compile-threads must be set to a non-zero value

对于出块节点来说,官方意思EOS VM Optimized编译器还没有足够的实际场景测试,防止各BP节点部分开启与未开启的行为之间可能存在差异的风险,官方建议是在生产节点上不使用eos-vm-oc-enable = true 只单独使用eos-vm-jit
并且由于节点开启后处理会更快,也就是TPS会增加很多,将导致每个块的数据猛增,会导致查询慢,以及可能的稳定因素影响。官方建议先不要使用,等待官方更新支持。
可看此贴 https://github.com/EOSIO/eos/issues/8620

参考

https://eos.io/news/introducing-eosio-2/