以太坊相关研究资料
《以太坊的 gas 费率一览表》 《以太坊学习笔记：私有链搭建操作指南》 《以太坊中的账户、交易、Gas和区块Gas Limit》 StackOverflow 上的问答：以太坊主链到底需要多大空间？ StackOverflow 上的问答：怎样提供无限次数的智能合约操作？ 《区块链技术-智能合约-以太坊 （译文）》 《以太坊官方文档》 《以太坊私有链搭建指南》 《以太坊关于搭建私有网络的 wiki》 《预充值以太坊资金的方法》。注意看 carchrae 的回复，这里面也提供了拷贝私钥复用私钥的方法，可以考虑在多节点的情况下使用。 《一本与参数有关的介绍怎样搭建私链的 gitbook》。 StackOverflow 上的问答：以太坊的网络难度是否可以静态锁死？注意看它还有个相关的子问题。如果网络算力的稳定的话，应该不会出现难度增长才对。 值得大读特读的 geth 的文档。特别是挖矿、账户管理的部分。 geth 的命令行选项。注意，有些选项在当前版本中已经消失了，如（gpomin、gpomax）。 StackOverflow...
把 Unix 的 Domain Socket 转成可本地访问的 TCP 端口
使用管道命令的做法：1socat -d TCP-LISTEN:2376,range=127.0.0.1/32,reuseaddr,fork UNIX:/var/run/docker.sock 简洁的做法（使用守护进程而不是使用管道命令）1docker run -d -v /var/run/docker.sock:/var/run/docker.sock -p 127.0.0.1:2375:2375 bobrik/socat TCP-LISTEN:2375,fork UNIX-CONNECT:/var/run/docker.sock 从容器内往外看的主机，对应外部主机就是 127.0.0.1的端口ping docker.for.mac.localhost 通常结果是192.168.65.1。 值得参考的文： http://brieflyx.me/2015/linux-tools/socat-introduction/
Docker in Docker
Why Docker in Docker?最适合的领域应该是持续集成领域，不断地在容器内部产生子容器，加速交付流程。 官方博客里提供的DinD 的解决方案在遥远的年代，需要很多其他的东西来辅助生成一个 docker in docker 的例子，但如今一个 —privileged 的 flag 就搞定一切了。 当前版本正确的 DinD 方案，是这样启动一个 DinD 容器: 12# 我们不能在任意容器里启动子docker，目前都需要dind镜像docker run --privileged -d docker:dind exec 进入这个容器： 1docker exec -it agitated_curran /bin/sh 然后在容器里再跑一个容器： 1docker run -it ubuntu /bin/bash Docker in Docker 为什么难？这有一篇博客《~jpetazzo/Using Docker-in-Docker for your CI or testing environment? Think twice.》，专门解释这个问题。总体看下来， DinD...
银翼杀手
2049没好人。
JVM 与编译优化
Java 的编译分期，至少可以分为两个阶段（有些情况下还有额外的第三种编译过程）： 编译前端（前端编译）：把*.java变成*.class文件的过程。也就是把源语言文件变成中间语言文件的过程。典型的例子有：javac、Eclipse 的 ECJ的工作过程。 编译后端（后端编译）：由 JIT（Just In Time Compiler。我认为应该还要把 Interpreter包括在内）把中间语言（字节码）转换成二进制目标体系结构机器码的过程。典型的例子有，HotSpot 的 C1，C2编译器的工作过程。 AOT（Ahead Of Time）编译器直接把源代码编译成转换成二进制目标体系结构机器码的过程。 早期（编译）优化javac 自从1.3版本已经不再支持什么 -O 的优化了。所有的优化策略集中到后端编译里。这样没有经过 javac 编译的 JRuby、Jython程序，也可以享受到 JVM 的优化福利。 javac的编译过程，大致上是： 解析和填充符号表（Parse and Enter）。 注解处理（Annotation Processing，Java...
基于栈的虚拟机
基于栈的虚拟机，可移植性更好。
Hyperledger Fabric 网络的启动步骤
本文是截至日前（2017.10.27）时对官方教程和自我实验的重新梳理。 Hyperledger Fabric 可以说是 Hyperledger 的拳头项目。虽然同为 Apache 的顶级项目，但大部分其他项目都以 Fabric 为基础。它是顶级项目中的顶级项目，可以认为是0级项目。 docker 要有高于 17.06.2-ce 的版本。docker-compose 要有 1.14.0 及以上的版本。当然当前的高版本的 docker 已经自带了高版本的 docker-compose，这通常不用担心。 安装1.9+ 的 Golang。应该预期这样的结果： echo $GOPATH /Users/xxx/go 如果这个结果出不来，考虑当前 Shell 的环境变量没有正确设置： export GOPATH=$HOME/go export PATH=$PATH:$GOPATH/bin 要用一个很特别的 nodejs 版本。6.9以上，却不能用8.x。npm 也有特别的版本要求： npm install...
思考区块链
区块链是比特币的基础设施。由区块组成链，是为区块链。各个区块链的持有者之间，总是在玩不确定选主的游戏，所以这和所有传统的分布式数据库不同，是一个去中心的数据存储模式。 比特币的区块链是1.0的玩法，以太坊是2.0的玩法。有些人认为 Hyperledger 是3.0的玩法，还有待怀疑。 区块链上的资产，可以是自带的（比特币网络里的比特币，以太坊网络里的以太币），也可以是智能合约定义和约束的。 智能合约是个看起来很美好，实际上只能执行在沙盒里面的东西。曾经在某个IBM程序员的分享里看到过，Hyperledger 的智能合约本质上也是 GO 程序，所以理论上可以做一切事情。但目前没有看到除了调用各种 Shim API 以外的任何用处。比如，如果我们想要用智能合约发出另外一个调用请求，让真实的系统发生转账，如何做到？ 很多人都有热思考，人类再也回不到没有比特币的时代了。也有冷思考，区块链的时代还未到来。就目前而言，现在的计算性能真的不足以支撑真实的行业流量，只能养养鸡，运运肉。 也有观点认为，公有链是真命题，而私有链是伪命题。就目前的观察看来，不管是 Hyperledger 还是...
昂贵的异常
抛出问题 Joshua Bloch 在《Effective Java》的 Item 57 里明确地提到过，不要试图用 Exception 的跳转来代替正常的程序控制流。他列举了很多原因，但特别提到了抛出异常会使得整个程序运行变慢。抛出异常远比普通的 return , break 等操作对控制流、数据流的性能影响要大，它就只适合拿来作异常分支的控制语句，而不能拿来编写正常的逻辑。 Throwing exception is expensive. 这句话在 Java 的程序员世界里面已经成为老生常谈。却很少有人谈及，但到底抛出异常比正常的程序跳转返回慢在哪里，有多慢。“不要滥用异常”好像一个猴子定律，人们忘记了为什么不能这么做，却不明白为什么不能这么做。 这几天读了一位同事写的好文[《Java虚拟机是如何处理异常的》][2]，深入地分析了 JVM 对异常跳转的处理过程: JVM...
系统的弹性
背景介绍 1999年，Dan Kegel 在互联网上发表了一篇文章，首次将 C10K 问题带入软件工程师的视野。在那个互联网勃兴的年代，计算机的运算处理能力，ISP 能够提供的带宽和网速都还十分有限，用户的数量也很少（那时候一个网站几百个人是很正常的事）。Dan Kegel 却已经敏锐地注意到极端的场景下资源紧张的问题。按照他的观察，某些大型的网络站点需要面对高达10000个客户端的并行请求。以当时的通行系统架构，单机服务器并不足以处理这个这个问题（当时绝大部分系统也没有那么大的流量，所以大部分人也没意识到这个问题）。因此，系统设计者必须为 C10K 问题做好准备。在那篇文章之中， Dan Kegel 提出了使用非阻塞异步 IO 模型，和使用各种内核系统调用黑魔法来提高系统 IO 性能的方式，来提高单机的并行处理能力。不得不说，这篇文章在当时很有先驱意义，它使得大规模网络系统的流量问题浮上了水面，也让人们意识到了系统容量建模和扩容提升性能的重要性。在它的启发下，C10K 问题出现了很多变种，从并发 C10K clients，到并发 C10K...
