- mining puzzle(挖矿方式)
区块链：计算密集型，导致挖矿设备趋于专业化。
以太坊：为避免挖矿专业化，采用了memory hard(对内存要求高)的方式，在一定程度上限制ASIC芯片的使用。
- Double spending
交易发布者在交易head中维护一个nonce计数器(故参与了签名)，记录了这个交易账户有史以来一共发布过多少个交易。在系统所有全局节点中，维护了每个账户的balance和nonce，当交易确定后更新nonce为交易值，这样通过判断nonce值可以防止双花。 – 怎么防止nonce回退？？
- 以太坊账户分类
- 外部账户：也叫普通账户，类似比特币账户，由公私钥对控制，存在balance+nonce计数器等其它属性；
- 合约账户：也存在balance&nonce，同时存在代码code和状态stage，其不能主动发起一个交易，所有的交易都由外部账户发起，发起后可以调用合约账户，一个合约账户可以通过msg调用另外一个合约账户。
- 以太坊树
- 状态树：提供账户余额等管理。
- 交易树：发布区块时，这些交易会组织成交易树。其提供Merkel Proof。向轻节点证明某个交易是打包在区块中的。
- 收据树：以太坊中的每一笔交易都有对应的收据，收据树的信息是为了方便一些相关账户的查询，向轻节点证明某个交易的执行结果。
- 以太坊布隆过滤器
- 权益证明
通过评估你持有代币的数量和时长来决定你获得记账权的机率。
- 以太坊预挖矿(pre_mining)与预售(pre-sale)
早期预留部分以太币币给开发者(类似创始人持股)，pre-sale则是将预留货币进行销售以获得资金(类似拉风投)
-
智能合约回滚
当一个智能合约调用另外一个时，被调用方出现异常，其自身将会回滚，调用方依据调用方式决定是否进行回滚：直接调用将级联回滚，使用call方式则会得到false返回值。
方法的回滚可以认为是事务式的，方法中整个操作均回滚，相当于没有执行本方法。
-
发布到区块链上的交易是否都是成功的？
不是，失败的交易也是要被扣除gas fee的，而只有发布出来被确认才能真正的扣除，所以失败的交易也会被发布出来。
在交易执行收据Receipt结构中，存在Status域，其标记了交易的执行结果。
-
智能合约支不支持多核并行处理？
智能合约语言（solidity）没有做多线程支持。以太坊是一个交易驱动的状态机，这个状态机必须是完全确定的(故任何导致不确定的操作都不会支持)。给定一个智能合约，给定一个输入，其转移到下一个状态必须是确定的。多个核可能对内存的访问顺序不同，这样最后构造出来的三棵树(状态树、交易树、收据树)根hash值可能不确定。
-
自定义自能合约发布及使用流程？
-
智能合约使用场景
智能合约是一种状态机管理，所以其适用在控制逻辑编写,服务于互不信任的实体之间建立共识的操作才写在智能合约中，对于计算和存储类业务不适用(慢且汽油费贵)，这种场景比较推荐分布式或者云服务。
