Daniel Larimer 刚刚披露了 EOS 的最近开发进展,原文 :https://steemit.com/eos/@dan/ukoxz-eos-io-development-update
为了开发进度,EOS 团队正在夜以继日地工作,很多之前提到的特性已经在 Github 的代码里实现了。
对于计算机来说,BIOS (Basic Input/Output System, 基本输入输出系统) 是系统计算机启动后首先运行的软件,再通过 BIOS 加载操作系统。参考计算机 BIOS 的设计, EOS 启动时会首先进入一个初始状态:
单一账户 (@eosio.system)
单一私钥
单一见证人
eosio.system 账号类似于 Linux 中的 root 账号,拥有最高权限,之后会让位给更高等级的操作系统智能合约。eosio.system 账号会上传操作系统智能合约,操作系统智能合约实现了以下内容:
投票、网络带宽、CPU 带宽、内存、存储权益。
见证人和投票代理人的生成。
这种初始状态类似胚胎干细胞,可以在不硬分叉的情况下修改系统。使得 EOS 的核心更加简洁,更容易进行测试。
之前见证人的数量在代码里被“写死”为 21 个,现在可以通过更新 @eosio.system 合约来修改见证人数量,不过默认还是 21 个。
这样可以方便 EOS 开发者进行本地测试,不需要在本地运行 21 个 eosiod 了。甚至可以只用一个见证人进行测试。
为了激励开发者精简智能合约,节约 CPU 消耗,EOS 系统通过计算 WASM 指令计算智能合约的执行时间,并对智能合约的 CPU 使用进行限制。
见证人会对各个智能合约的 CPU 配额进行动态调整,当系统空闲时,智能合约可以临时使用更多的 CPU 资源。
为了防止计量算法被针对,见证人会在客观 CPU 资源限制的基础上增加人为的主观限制。
之前的更新中,将内存、储存、带宽权益进行了分离,但带宽包括了 CPU 带宽和网络带宽,有些应用可能只需要大量的网络带宽,不需要很多 CPU 带宽资源,也有很多应用正好相反,所以将 CPU 和网络带宽一起授权有时就不太合适。
对于普通用户来说,CPU 和网络带宽仍然是打包在一起的,高级用户可以分离两者,使得成本上更有灵活性。
由于加入了 C++ STL 库的支持,智能合约传输的数据量有时会增加至
200kB,所以 EOS 增加了对 zlib 压缩的支持,使得智能合约传输的数据量能减少 60% 甚至更多。
P2P 网络团队一直致力于改进网络的性能和稳定性,这周又有了很大进展:
精简区块 —— 每个被广播的区块只含有交易 ID,而不需将每个交易内容再次广播,这样能节约接近 50% 的网络带宽。
长消息支持 —— 发送长消息(例如 50kB 的智能合约)需要使用特殊的网络协议。
目前的进度还是比较理想的,之前有人认为多线程的推迟是一个利空,但多线程对于技术实现来说是一个不稳定因素,急于上线肯定会导致不可预料的后果。更何况单线程性能已经足够强大了。
另外,可以通过最近的更新感觉到,EOS 团队对于区块链本身的功能有了新的理解,区块链不再是传输数据的唯一渠道,EOS 应该会将 0.5s 每个的 cycle 作为网络数据传输的主力,而 3s 每个的区块仅作为简报与日志的用途,使得区块链回归了不可篡改数据库的初心,也使得 EOS 的交易确认速度达到了惊人的 1 秒级,以后的文章会详细分析。
End
圆方圆学院汇集大批区块链名师,打造精品的区块链技术课程。
许晓笛老师的CSDN学院视频专栏 https://edu.csdn.net/lecturer/2008
郭金宏老师的csdn学院视频专栏:https://edu.csdn.net/lecturer/2214