meisw's blog

 go编译的时候默认会将代码和行号包含到gdb调试信息里，使用gdb还是可以看见源码，编译的时候加-ldflags "-s -w"可以去掉调试信息。

 dpkg-reconfigure dash

 通过putty或者securecrt连到linux服务器，使用vi编辑*.php 或*.c文件时，

蓝色的注释很淡，看不清，看起来很费眼

效果如下

我本身有习惯于默认配色，不想修改配色方案，只想把看不清蓝色的注释换掉，修改成目录的蓝色

翻了翻相关资料，大部分都是修改配色方案，最后发现可以通过hi命令来修改注释的颜色。

hi指令使用方法

设置关键字为蓝色非粗体 ：hi Identifier ctermfg =blue cterm =none （bold 就设置成粗体）

那我们的问题就可以通过添加一条hi指令解决了

1. vi ~/.vimrc 加入如下内容

hi Comment ctermfg =blue

2.修改后效果

以下是vim不同关键字字体颜色修改方法

修改字符串颜色

hi String ctermfg =darkred

修改类型颜色

hi Type ctermfg =yellow

修改数字颜色

hi Number ctermfg =darkblue

修改常量颜色

hi Constant ctermfg =blue

修改声明颜色

hi Statement ctermfg =darkyellow

 https://zhuanlan.zhihu.com/p/27574211

内部-优化器

Solidity 优化器是在汇编级别上的操作，所以它也可以同时被其他语言所使用。它将指令的（执行）次序，在JUMP 和 JUMPDEST上分成基本的块。在这些块中，指令被解析 。 堆栈、内存或存储上的每一次修改，都将作为表达式被记录。该表达式包括一条指令以及指向其他表达式的一系列参数的一个指针。现在的主要意思是要找到相等的表达式（在每次输入），做成了表达式的类。优化器首先在已知的表达式列表里找，若找不到的话，就根据constant + constant = sum_of_constants  或 X * 1 = X  来简化。 因为这样做是递归的，如果第二个因子是一个更复杂的表达式，我们也可以应用latter规则来计算。存储和内存位置的修改，是不知道存储和内存的位置的区别。如果我们先写到的位置x，再写到位置y , x,y均是输入变量。第二个可以覆写第一个，所以我们不知道x是存放在y之后的。另一方面，如果一个简化的表达式 x-y 能计算出一个非零常数，我们就知道x存放的内容。

在这个过程结束时，我们知道，表达式必须在堆栈中结尾，并有一系列对内存和存储的修改。这些信息存储在block上，并链接这些block。此外，有关堆栈，存储和内存配置的信息会转发到下一个block。如果我们知道所有的 JUMP 和 JUMPI 指令，我们可以建立一个完整的程序控制流图。如果我们不知道目标块（原则上，跳转目标是从输入里得到的），我们必须清除所有输入状态的存储块上的信息，（因为它的目标块未知）。如果条件计算的结果为一个常量，它转化为一个无条件jump。

作为最后一步，在每个块中的代码完全可以重新生成。从堆栈里block的结尾表达式开始，创建一个依赖关系图。每个不是这个图上的操作将舍弃。现在能按照原来代码的顺序，生成对存储和内存修改的代码（舍弃不必要的修改）。最后，在正确位置的堆栈上，生成所有的值。

这些步骤适用于每一个基本块， 如果它是较小的，用新生成的代码来替换。如果一个基本块在JUMPI上进行分割，在分析过程中，条件表达式的结果计算为一个常数，JUMP就用常量值进行替换。代码如下

使用命令行编译器

一个 Solidity 库构建的目标是solc， Solidity命令行编译器。使用solc –help  为您提供所有选项的解释。编译器可以产生不同的输出，从简单的二进制文件，程序集的抽象语法树（解析树）到gas使用的估量。如果你只想编译一个文件，你运行solc –bin sourceFile.sol ， 将会打印出二进制。你部署你的合约之前，使用solc –optimize –bin sourceFile.sol 来激活优化器。如果你想获得一些solc更进一步的输出变量，可以使用solc -o outputDirectory –bin –ast –asm sourceFile.sol，（这条命令）将通知编译器输出结果到单独的文件中。

命令行编译器会自动从文件系统中读取输入文件，但也可以如下列方法，提供重定向路径prefix=path ：

solc github.com/ethereum/dapp-bin/=/usr/local/lib/dapp-bin/ =/usr/local/lib/fallback file.sol

该命令告诉编译器在/usr/local/lib/dapp-bin目录下，寻找以github.com/ethereum/dapp-bin/  开头的文件，如果找不到的话，到usr/local/lib/fallback目录下找（空前缀总是匹配）。

solc不会从remapping目标的外部，或者显式定义的源文件的外部文件系统读取文件，所以要写成 import “/etc/passwd”;     只有增加 =/ 作为remapping,程序才能工作。

如果remapping里找到了多个匹配，则选择有共同的前缀最长的那个匹配。

如果你的合约使用了  libraries ，你会注意到字节码中包含了 form LibraryName 这样的子字符串。你可以在这些地方使用solc 作为链接器，来插入库地址 ：

Either add –libraries “Math:0x12345678901234567890 Heap:0xabcdef0123456”    提供每个库的地址， 或者在文件中存放字符串（每行一个库）

然后运行solc，后面写 –libraries fileName.

如果solc后面接着 –link 选项，所有输入文件将被解释为未链接的二进制文件（十六进制编码）， LibraryName形式如前所述， 库此时被链接（从stdin读取输入，从stdout输出）。在这种情况下，除了–libraries,其他所有的选项都将被忽略（包括 -o)

提示和技巧

• 在数组中使用delete，就是删除数组中的所有元素。

• 使用较短的类型和结构元素，短类型分组在一起进行排序。sstore操作可能合并成一个单一的sstore，这可以降低gas的成本（sstore消耗5000或20000 gas，所以这是你必须优化的原因）。使用天gas的价格估算功能（优化器 enable）进行检查！

• 让你的状态变量公开，编译器会免费创建 getters 。

• 如果你结束了输入或状态的检查条件，请尝试使用函数修饰符。

• 如果你的合约有一个功能send， 但你想使用内置的send功能，请使用 address(contractVariable).send(amount)。

• 如果你不想你的合约通过send接收ether，您可以添加一个抛出回退函数 function() { throw; }.。

• 用单条赋值语句初始化存储结构：x = MyStruct({a: 1, b: 2});

陷阱

不幸的是，还有一些编译器微妙的情况还没有告诉你。

• 在for (var i = 0; i < arrayName.length; i++) { ... },  i的类型是uint8，因为这是存放值0最小的类型。如果数组元素超过255个，则循环将不会终止。

列表

 以太坊并不存在中心服务器，而是基于p2p协议连接起来的平等节点，在众多节点中存储了全部数据。当用户发起一笔交易，会通过广播通知每一个节点，矿工对此进行验证打包并进一步广播，在区块链确认以后，此操作即认为是不可更改的。

在每个节点上，数据是以区块链来存储的。区块链由一个个块串起来而组成。以太坊被描述为一个交易驱动的状态机。它在某个状态下接收一些输入，会确定的转移到另一个状态。

状态机，包含一组状态集（states）、一个起始状态（start state）、一组输入符号集（alphabet）、一个映射输入符号和当前状态到下一状态的转换函数（transition function）的计算模型。

在以太坊的一个状态下，每个账户都有确定的余额和状态信息，当他接收到新的交易以后就会进入一个新的状态，从创世块开始，不断的收到新的交易，由此能进入到一系列新的状态。

以太坊每隔一段时间就会把一批交易信息打包存储到一个块里，这个块中包含的信息有：

1. ParentHash:父块的哈希值
2. Number:块编号
3. Timestamp:块产生的时间戳
4. GasUsed:交易消耗的Gas
5. GasLimit:Gas限制
6. Difficulty:POW的难度值
7. Beneficiary：块打包手续费的受益人，也称矿工
8. Nonce：一个随机数，使得块头哈希满足POW需求

这些字段我们在上面的web3接口中都可以获取得到。

nonce，整数类型，允许使用相同随机数覆盖自己发送的处于pending状态的交易。

为了防止交易的重播攻击，每笔交易必须有一个nonce随机数，针对每一个账户nonce都是从0开始，当nonce为0的交易处理完之后，才会处理nonce为1的交易，并依次加1的交易才会被处理。以下是nonce使用的几条规则：

• 当nonce太小，交易会被直接拒绝。
• 当nonce太大，交易会一直处于队列之中，这也就是导致我们上面描述的问题的原因；
• 当发送一个比较大的nonce值，然后补齐开始nonce到那个值之间的nonce，那么交易依旧可以被执行。
• 当交易处于queue中时停止geth客户端，那么交易queue中的交易会被清除掉。