debug the world
摘录自官方文档
1 | $ git clone --recursive https://github.com/eosio/eosio.cdt --branch v1.4.1 --single-branch |
It may take up to 30 minutes to clone the repository
1 | $ ./build.sh |
1 | $ sudo ./install.sh |
1 | $ eosio-cpp -o token.wasm token.cpp --abigen |
1 | $ md5 token.wasm |
Compare to deploy transaction https://eosq.app/tx/a53fdf96b1fa6b990f05d7a5f1007476e5f1e2d7848e1e652ecc866db995937d
If I have already launched mysql database service in the host server, and now I want allow the service in a docker container instance to access the host’s mysql service. What should I do?
如果宿主机上已经部署了mysql服务, 怎样才能让docker 得容器实例中的程序访问到mysql服务呢？
I found answer from the stackoverflow:
通过搜索，我找到了以下相关线索：
For example, on my system:
2
3
4
5
6
7
8
>7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
>link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
>inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
>valid_lft forever preferred_lft forever
>inet6 fe80::f4d2:49ff:fedd:28a0/64 scope link
>valid_lft forever preferred_lft forever
>
And inside a container:
2
3
4
>default via 172.17.0.1 dev eth0
>172.17.0.0/16 dev eth0 src 172.17.0.4
>
It’s fairly easy to extract this IP address using a simple shell script:
2
3
4
>hostip=$(ip route show | awk '/default/ {print $3}')
>echo $hostip
>
You may need to modify the iptables rules on your host to permit connections from Docker containers. Something like this will do the trick:
2
>
This would permit access to any ports on the host from Docker containers. Note that:
- iptables rules are ordered, and this rule may or may not do the right thing depending on what other rules come before it.
- you will only be able to access host services that are either (a) listening on INADDR_ANY (aka 0.0.0.0) or that are explicitly listening on the docker0 interface.
REF：https://stackoverflow.com/questions/31324981/how-to-access-host-port-from-docker-container/31328031
使用Gitlab Runner来做CI/CD，从部署gitlab到注册runner都是很顺利，因为官方提供了便捷的安装脚本。当要做CD（持续部署）时，一时没想到怎么做。
我的部署是在宿主机上使用Docker分别跑起了Gitlab Runner和Nginx两个容器，用了hexo工具生成
gitlab runner跑在了docker容器中，而runner执行每个pipline的job也是启动了一个容器实例。如果CI脚本想build一个docker镜像，或者是启动一个容器服务，这里也要运行docker程序。docker in docker in docker?
官方文档给出了三种解决方案：
https://docs.gitlab.com/ee/ci/docker/using_docker_build.html
Use shell executor - 意思就是那就别docker跑runner，在宿主机直接跑runner吧。就变成了 docker in docker
Use docker-in-docker executor - 用一个特殊的docker镜像docker:dind，并开通特殊权限。官方推荐此方法。
Use Docker socket binding - 通过--docker-volumes /var/run/docker.sock:/var/run/docker.sock来把宿主机的docker服务直接分享给容器实例中，这种做法简单，但又安全隐患。
具体步骤我就不复制了，进官方文档直接看吧。
使用eosjs基本都能调用到EOS RPC的所有接口。调用get_actions获取并能筛选到提案记录，下方是get_actions返回的数据
1 | { |
一切看似简单，当想到需要得知这个提案通过后执行什么操作，在哪里查呢？1
action_trace.act.data.trx.actions[0].data = "700c358d4de7a759401d358d4de7a759102700000000000004454f53000000000166"
这到底又是什么鬼呢？直觉告诉我这就是我要找的数据。
我们先看看怎么使用eosjs创建一个提案。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
const _eos = Eos({
httpEndpoint: httpEndpoint,
chainId: chainId,
signProvider: signProvider,
verbose: false
});
_eos.contract("eosio.msig").then(msig => {
_eos
.transfer(
selectedAccount.account_name,
_to,
_amount,
_memo || "transfer",
{ broadcast: false, sign: false }
)
.then(transfer => {
transfer.transaction.transaction.max_net_usage_words = 0;
transfer.transaction.transaction.expiration = new Date(
Date.parse(new Date()) + 1000 * 60 * 60 //60mins expire
);
console.log(transfer.transaction.transaction);
const proposal_name = `tr${randomWord(false, 10)}`;
msig
.propose(
_proposer,
proposal_name,
permissions,
transfer.transaction.transaction,
{ authorization: `${_proposer}@active` }
)
.then(tx => {
onSuccess(tx, _proposer);
}, onError);
});
});
_eos.contract("eosio.msig")通过rpc获取到了eosio.msig合约的abi，之后就可以使用msig.propose方法了。在提案之前要创建一个Transaction，在这个Transaction内可以执行多个Action，这里我就只执行一个Transfer操作，特意声明不广播交易和不做交易签名，创建好后打印出当前的Transaction，打印出来的结果看到同样出现类似"700c358d4de7a759401d358d4de7a759102700000000000004454f53000000000166"的数字串。查阅文档后得知这就是action的data转成16进制的字符串，也就是说这里边就包含了Transfer操作所需的参数from、to、quantity和memo。
通过查看eosjs源代码和调试，定位到了/src/structs.js文件：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22'action.data.toObject': ({fields, object, result, config}) => {
const {data, name} = object || {}
const ser = (name || '') == '' ? fields.data : structLookup(name, object.account)
if(!ser) {
// Types without an ABI will accept hex
result.data = Buffer.isBuffer(data) ? data.toString('hex') : data
return
}
if(forceActionDataHex) {
const b2 = new ByteBuffer(ByteBuffer.DEFAULT_CAPACITY, ByteBuffer.LITTLE_ENDIAN)
if(data) {
ser.appendByteBuffer(b2, data)
}
result.data = b2.copy(0, b2.offset).toString('hex')
// console.log('result.data', result.data)
return
}
// Serializable JSON
result.data = ser.toObject(data, config)
}
这个方法重载了abi定义，强制对数据进行16进制转化。既然有编码那就得有解码呀，在这代码上方就有类似的定义：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17'action.data.fromObject': ({fields, object, result}) => {
const {data, name} = object
const ser = (name || '') == '' ? fields.data : structLookup(name, object.account)
if(ser) {
if(typeof data === 'object') {
result.data = ser.fromObject(data) // resolve shorthand
} else if(typeof data === 'string') {
const buf = Buffer.from(data, 'hex')
result.data = Fcbuffer.fromBuffer(ser, buf)
} else {
throw new TypeError('Expecting hex string or object in action.data')
}
} else {
// console.log(`Unknown Action.name ${object.name}`)
result.data = data
}
}
重点就在于Fcbuffer.fromBuffer(ser, buf)方法给解密了，Fcbuffer就是eosjs作者James Calfee封装的包。那只要传对参数，也就可以调用解密方法了。
引入Fcbuffer1
$ npm install fcbuffer
文件里引用1
const Fcbuffer = require("fcbuffer");
调用方法1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
Helpers.getLatestProposals = name => {
return new Promise((resolve, reject) => {
eos.getActions(name, -1, -100).then(
res => {
resolve(
res.actions
.filter(item => {
return item.action_trace.act.name === "propose";
})
.map(item => {
item.action_trace.act.data.trx.actions = Array.prototype.map.call(
item.action_trace.act.data.trx.actions,
action => {
try {
action.origin_data = Fcbuffer.fromBuffer(
eos.fc.abiCache.abi(action.account).structs[action.name],
Buffer.from(action.data, "hex")
);
return action;
} catch (e) {
// Abi 'eosio.xxxx' is not cached
eos.getAbi(action.account).then(res => {
action.origin_data = Fcbuffer.fromBuffer(
eos.fc.abiCache.abi(action.account).structs[
action.name
],
Buffer.from(action.data, "hex")
);
return action;
});
}
}
);
return item;
})
.sort((a, b) => {
if (a.account_action_seq > b.account_action_seq) return -1;
if (a.account_action_seq < b.account_action_seq) return 1;
return 0;
})
);
},
err => {
reject(err);
}
);
});
};
这样我就得到了从16进制串转回的原数据action.origin_data。使用同样的方法，可以也对data_hex整个transaction的数据进行decode。至于为什么要对提案的Transaction这么存储，这是保证在提案通过后执行的事务是一致的HEX数据，
https://ethereum.stackexchange.com/a/33482
You’ll notice that there some more functions in your basic token contract, like approve, sendFrom and others. These functions are there for your token to interact with other contracts: if you want, say, sell tokens to a decentralized exchange, just sending them to an address will not be enough as the exchange will not be aware of the new tokens or who sent them, because contracts aren’t able to subscribe to Events only to function calls. So for contracts, you should first approve an amount of tokens they can move from your account and then ping them to let them know they should do their thing - or do the two actions in one, with approveAndCall.
AB币交换
A合约 B合约
甲
乙
怎么用openssl创建钱包
摘录自以太坊白皮书，文中前部分从技术角度解析比特币区块链的原理，我只是划重点把比特币部分知识点摘抄下来。
从技术角度讲，比特币账本可以被认为是一个状态转换系统，该系统包括所有现存的比特币所有权状态和“状态转换函数”。状态转换函数以当前状态和交易为输入，输出新的状态。例如，在标准的银行系统中，状态就是一个资产负债表，一个从A账户向B账户转账X美元的请求是一笔交易，状态转换函数将从A账户中减去X美元，向B账户增加X美元。如果A账户的余额小于X美元，状态转换函数就会返回错误提示。所以我们可以如下定义状态转换函数：
1 | APPLY(S,TX) > S' or ERROR |
在上面提到的银行系统中，状态转换函数如下：
1 | APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30,Bob: $70 } |
但是：
1 | APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR |
比特币系统的“状态”是所有已经被挖出的、没有花费的比特币（技术上称为“未花费的交易输出，unspent transaction outputs 或UTXO”）的集合。每个UTXO都有一个面值和所有者（由20个字节的本质上是密码学公钥的地址所定义）。一笔交易包括一个或多个输入和一个或多个输出。每个输入包含一个对现有UTXO的引用和由与所有者地址相对应的私钥创建的密码学签名。每个输出包含一个新的加入到状态中的UTXO。
在比特币系统中，状态转换函数APPLY(S,TX)->S’大体上可以如下定义：
- 交易的每个输入：
- 如果引用的UTXO不存在于现在的状态中（S），返回错误提示
- 如果签名与UTXO所有者的签名不一致，返回错误提示
- 如果所有的UTXO输入面值总额小于所有的UTXO输出面值总额，返回错误提示
- 返回新状态S’,新状态S’中移除了所有的输入UTXO，增加了所有的输出UTXO。
第一步的第一部分防止交易的发送者花费不存在的比特币，第二部分防止交易的发送者花费其他人的比特币。第二步确保价值守恒。比特币的支付协议如下。假设Alice想给Bob发送11.7BTC。事实上，Alice不可能正好有11.7BTC。假设，她能得到的最小数额比特币的方式是：6+4+2=12。所以，她可以创建一笔有3个输入，2个输出的交易。第一个输出的面值是11.7BTC，所有者是Bob（Bob的比特币地址），第二个输出的面值是0.3BTC，所有者是Alice自己，也就是找零。
比特币的去中心化共识进程要求网络中的节点不断尝试将交易打包成“区块”。网络被设计为大约每十分钟产生一个区块，每个区块包含一个时间戳、一个随机数、一个对上一个区块的引用（即哈希）和上一区块生成以来发生的所有交易列表。这样随着时间流逝就创建出了一个持续增长的区块链，它不断地更新，从而能够代表比特币账本的最新状态。
依照这个范式，检查一个区块是否有效的算法如下：
- 检查区块引用的上一个区块是否存在且有效。
- 检查区块的时间戳是否晚于以前的区块的时间戳，而且早于未来2小时。
- 检查区块的工作量证明是否有效。
- 将上一个区块的最终状态赋于S[0]。
- 假设TX是区块的交易列表，包含n笔交易。对于属于0……n-1的所有i,进行状态转换S[i+1] = APPLY(S[i],TX[i])。如果任何一笔交易i在状态转换中出错，退出程序，返回错误。
- 返回正确，状态S[n]是这一区块的最终状态。
区块验证算法的有趣部分是“工作量证明”概念：对每个区块进行SHA256哈希处理，将得到的哈希视为长度为256比特的数值，该数值必须小于不断动态调整的目标数值，本书写作时目标数值大约是2^190。工作量证明的目的是使区块的创建变得困难，从而阻止女巫攻击者恶意重新生成区块链。因为SHA256是完全不可预测的伪随机函数，创建有效区块的唯一方法就是简单地不断试错，不断地增加随机数的数值，查看新的哈希数值是否小于目标数值。如果当前的目标数值是2^192，就意味着平均需要尝试2^64次才能生成有效的区块。一般而言，比特币网络每隔2016个区块重新设定目标数值，保证平均每十分钟生成一个区块。为了对矿工的计算工作进行奖励，每一个成功生成区块的矿工有权在区块中包含一笔凭空发给他们自己25BTC的交易。另外，如果交易的输入大于输出，差额部分就作为“交易费用”付给矿工。顺便提一下，对矿工的奖励是比特币发行的唯一机制，创世状态中并没有比特币。
默克尔树是一种二叉树，由一组叶节点、一组中间节点和一个根节点构成。最下面的大量的叶节点包含基础数据，每个中间节点是它的两个子节点的哈希，根节点也是由它的两个子节点的哈希，代表了默克尔树的顶部。默克尔树的目的是允许区块的数据可以零散地传送：节点可以从一个源下载区块头，从另外的源下载与其有关的树的其它部分，而依然能够确认所有的数据都是正确的。之所以如此是因为哈希向上的扩散：如果一个恶意用户尝试在树的下部加入一个伪造的交易，所引起的改动将导致树的上层节点的改动，以及更上层节点的改动，最终导致根节点的改动以及区块哈希的改动，这样协议就会将其记录为一个完全不同的区块（几乎可以肯定是带着不正确的工作量证明的）。
最近做了一个世界杯比赛日程的小程序，只有查看日程的功能，所以很快就发布上线了。后边想加入用户预测功能，但是时间紧、前后端实现又比较复杂，突然灵机一动想到用webview嵌入FIFA官网的比赛预测页面。
微信小程序支持通过webview来内嵌网页，但是要求业务域名预先审核配置，就是说只能是你自己拥有的并且已经备案的域名。明显，我并不拥有FIFA官网，因而无法配置为业务域名。不过我可以利用Nginx做反向代理（非透明代理，与之相反的是透明代理），利用自己的域名（https://api.wecode.net.cn ），把网页请求转发到FIFA官网（https://www.fifaofficial.cn ），这样我就不用开发就直接展示FIFA官方内容。
一个网页的展示，首先得有HTML内容。把 https://api.wecode.net.cn 页面反向代理到 https://www.fifaofficial.cn ，这时请求就会得到目标网页的HTML内容返回。
1 | location ^~/ { |
这个不仅能处理index页面的请求，因为^~/路由的是所有host为api.wecode.net.cn的所有请求。所以，给请求的返回加入Access-Control-Allow-Origin头，可以避免一些请求数据的跨域问题。
在网页里，通常都会包含很多静态资源的引用，如css、js、font等，同时都是使用cdn加速，所以会是使用不同的域名。
1 | <link href="//cdn.fifaofficial.cn/assets/css/76151aa27c3d7972aa5c.styles.css" rel="stylesheet"> |
第一，把html中的静态资源引用域名替换为自己的域名下，所以刚才的配置中要加入sub_filter(文档)替换声明
1 | location ^~/ { |
第二，反向代理静态资源文件。如
1 | cdn.fifaofficial.cn/assets/.....css ===> api.wecode.net.cn/styles/.....css |
Nginx配置为
1 | location ~* \.(?:css|js|ttf|woff|svg|ico|png|jpg)$ { |
由于css、js等文件内也会引用别的资源，所以也是需要加入sub_filter替换声明的。
微信小程序要求服务器使用SSL协议，所以也需要配置。
1 | server { |
最近我也在学习容器服务，就尝试把Nginx服务部署到一个Docker容器中。安装好Docker后，执行
1 | $ docker container run \ |
上面的Nginx配置文件default.conf就是保存在/conf目录下，所以把文件目录/conf映射到/etc/nginx。/logs目录映射即是存放日志文件，方便查看Nginx服务的日志。另外，-p就是映射端口。
这时就可以访问 https://api.wecode.net.cn 就得到我想要的内容了，轻松把FIFA官方内容嵌入到我的小程序里。
完整代码放到了 https://github.com/fanyinghao/nginx-docker-miniprogram