EOSIO SDK for Java的示例可插入签名提供程序，用于使用内存中的密钥对事务进行签名

github:https://github.com/EOSIO/eosio-java-softkey-signature-provider

一个Android RPC提供程序实现，用于在EOSIO SDK for Java中作为插件使用。RPC提供程序负责对nodeos的所有RPC调用以及常规网络处理。

github:https://github.com/EOSIO/eosio-java-android-rpc-provider

SignatureProvider，用于与Ledger设备中的eosjs通信。

github:https://github.com/EOSIO/eosjs-ledger-signature-provider

https://github.com/EOSIO/eos/blob/686f0deb5dac097cc292f735ccb47c238e763de0/libraries/chain/include/eosio/chain/controller.hpp#L87

enum class block_status {
            irreversible = 0, ///< this block has already been applied before by this node and is considered irreversible
            validated   = 1, ///< this is a complete block signed by a valid producer and has been previously applied by this node and therefore validated but it is not yet irreversible
            complete   = 2, ///< this is a complete block signed by a valid producer but is not yet irreversible nor has it yet been applied by this node
            incomplete  = 3, ///< this is an incomplete block (either being produced by a producer or speculatively produced by a node)
         };

版本号：1.8.0
Github：https://github.com/EOSIO/eos/releases/tag/v1.8.0-rc2

1 扩展性提升与代码重构

在这个版本中我们看到了大量的提交 , 主要集中在代码重构和线程安全化两个方面 :

首先的代码重构 , 很多人往往不关心这些既没有增加功能也没有提升性能的代码修改 , 但是从开发的角度看 , 这些其实构成后续开发的重要基础 , 我们可以看到 , 自年初以来 , Block.one 的核心开发者一直在改善 EOS.IO 的代码结构 , 并且从设计层面上逐步在建立一个抽象层 , 最明显的是 EOS.IO.cdt 的完善 , 这些构成了 EOS.IO 的框架 , 不同于很多在一开始就给出了庞大架构的团队 ，Block.one 的开发团队一贯以务实且自低向上的思路开发 EOS.IO。

在 1.8.0 版本中 , Block.one 的开发者拆分了很多之前的巨无霸类型 , 剥离了散落在各处的一些复杂逻辑 , 比如 pending_block_state 相关的状态管理 , 就从 block_header_state 中剥离出来 . 还有之前略带“坏味”的 transaction traces, 也在这次重新整理。

另一个方面是关于多线程 , 在最近一段时间有很多关于线程安全性的提交，为下一步实现多线程相关开发做准备，Block.One 团队在 2019 年的开发中对多线程非常重视，此次重构后将很更好的实现 EOS.IO 白皮书里描述的多线程，届时 TPS 会上升到一个新的台阶。

众所周知 , 中大规模 C++软件的多线程开发一直是一个“深坑”, 为了在引入并行计算的同时保证 EOS.IO 的稳定性 , Block.One 团队并没有急于进行多线程相关新特性的开发 , 而是耐心的排查代码中的线程安全问题 , 完善基础架构支持 , 同时在特定的适合并发的独立模块 , 如 chain api 以及 p2p 模块引入对应的多线程实现

2 提升链安全性

在这个版本中 , Block.One 团队修正了之前遗留的一些资源计算问题 , EOS.IO 中资源相关的逻辑很多 , 并且极为分散 , 为了提升链性能并避免节点进行不必要的计算 , EOS.IO 中添加了很多资源相关的特化逻辑 , 这也造成了很多特定场景下用户资源计算的不明确 , 对于 EOS.IO 链来说 , 这带来了很多起潜在的安全性问题 , 前一阶段暴露的由延迟交易所触发的阻塞交易问题 , 很大程度上就是资源检查不完备的问题。

另外 , 某些场景下资源计算的问题也会导致用户权益上的损失 , 所以这方面的修改势在必行。

3 智能合约安全

智能合约安全困扰了 EOS.IO 社区很久，DAPP 开发者在过去一年的实践中发现了大量的问题，Block.One 团队吸收了这些问题并且做出了极大的改进，此次更新对智能合约开发者更友好。

举例来说 , 对于 DAPP 开发者来说 , 一个好消息就是千呼万唤的 GET_SENDER API 终于要引入 EOS.IO 中了 , DAPP 开发者可以通过这个 API 判定当前 Action 是否是通过 inline action 机制触发的 , 据此可以回避大量的基于合约触发 inline action 的攻击手段 . 这个更新，可以一定程度上部分解决了困扰社区已久的随机数问题，需要注意的是 , 即使通过这个 api 可以屏蔽当前的很多攻击手段 , 固然攻击者的攻击成本会大幅提高 , 但是不意味着 DAPP 开发者可以高枕无忧 , 对于开发者来说安全问题永远需要注意 , 没有什么一劳永逸的银弹。

4 硬分叉升级机制

这方面的更新可以使得未来的硬分叉升级更加高效的同时使得硬分叉升级过程中不影响用户使用体验。

近一段时间 , Block.One 其实开发了非常多的新功能，包括上面提到的几个功能 , 但都没有在过往的更新中出现，一个很大的原因就是开发者必须保证 EOS.IO 的兼容性 , 节点可以选择不升级节点版本 , 显然这会极大的阻挠 EOS.IO 的发展 , 这次 1.8.0 的版本与以往的一个最大区别是这个版本不兼容前面的版本 , 也就是所谓的“硬分叉”, 在这个版本之前 EOS.IO 并没有应对硬分叉的机制 , 硬分叉的过程会对用户的使用带来很大影响 , 为了使以后的更新不会像这一次一样造成很大影响 , 这次更新中添加了一系列硬分叉升级机制 , 为的是以后的硬分叉更新可以更加平滑和安。

转载自：https://www.chainnews.com/articles/083001943204.htm