sudo apt-get install libncurses5

调研背景

公司有个针对比特币的资产使用场景，

一个比特币的账户有5个多签见证人控制，满足3个人签名就可以修改其中一个人的签名权限，和转移50%的资产，满足5个人同时签名就可以转移100%的资产。

之前一直All in EOS,所以先查下相关的资料吧。

参考资料

https://www.qunfengshe.com/articles/QXJ0aWNsZTo4MA==
https://zhuanlan.zhihu.com/p/25461051
https://m.8btc.com/article/350625
https://juejin.im/post/5aa60e65518825557005a7f6
https://en.bitcoin.it/wiki/Script#Opcodes
https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp
https://gist.github.com/gavinandresen/3966071
https://siminchen.github.io/bitcoinIDE/build/editor.html

对比EOS

按需求我们等价到EOS链图灵完备的智能合约实现方式，需要以下几步

1. 准备一个资产账户，5个管理账户，并将资产账户active和owner的权限按权重（5）和阈值（3）设置成5个管理账户（set account permission），且能满足达到3/5权重，再次修改账户权限。
2. 编写智能合约，Table中记录当前资产总额和已转出的资产，合约“监听”转账通知 [[eosio::on_notify("eosio.token::transfer")]],当有新转入，累加到资产总额。当已转出的资产超过50%时，验证当前执行是否同时有5个账户的签名 require_auth(1) - require_auth(5)，如果不满足则失败assert,没超过50%前，无需合约判断，链本身会在第一步设置的资产账户的权重和阈值那里自行判断，也就是至少满足3/5才会执行到此合约里。
3. 将上面的合约部署到资产账户，就能满足需求场景了。

调研针对比特币的需求结论

1. 针对权重和阈值分配，比特币多重签名可以支持。但相对EOS权限管理，只能等份分割，某个人想拥有多大比例的权重，就拥有对应个数的私钥。
2. 比特币脚本不是图灵完备的，无法实现数据存储，只能做一些简单的堆栈方式的运算，且当合约执行时，它没办法指定被影响到的比特币金额，要么全部解锁，要么就完全不解锁，因为比特币上的智能合约只是一个锁定脚本，成功解锁前后，没有中间状态，导致实现复杂协议很困难。

考虑到使用场景，比特币简单粗暴临时方案

使用权重和阈值 分别是5-5，以及5-3，创建两个比特币地址。5-5账户地址存放100%资金，由5个人同时签名后将资金的 50%转移到 5-3账户地址。这样能满足 5-5可使用100%资金，5-3使用50%资金。相对资产单一账户来说，超过单个账户余额边界时，会导致2笔手续费。

问题

老同事今天问我，A合约inline调用B合约的action（B合约的action中的逻辑会修改B合约的某个Table）,A合约中执行完inline后，立刻查B合约中的Table数据，数据未更新，怎么处理。

解决方案

A合约inline调用B合约的action后，B再内联调用A合约的另一个新加的action（在这个action中再查B合约的Table数据）

先暂时记录下，等下再跟下链代码，详细分析下为什么合约是同步执行的，然而inline action 出现了“异步的效果”

场景

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变少了）

当get table索引是name 时，无法精准查询
因为cleos 传入的参数默认是字符串，需要对应的转换参数
--key-type name

例如

cleos -u https://api.eosnewyork.io:443 get table eosio eosio voters --key-type name -L 111111111122 -l 1

参考

https://github.com/EOSIO/eos/issues/5019