EOSIO 官方 testnet

EOS 官方发布了一个测试网
https://testnet.eos.io

特点是把账号创建、资源申请、区块链浏览器、部署代码和Action调用都界面化的放在一起了,方便开发者上手。

使用步骤

1 注册开发者账号,需要验证邮件

2 完成注册后,在右上角【Account Settings】里面可以查看已经自动创建好的测试账号

点击后,可以在里面申请多个账号、申请测试币、购买内存和抵押资源等

3 点击 Deploy 菜单,进入合约部署操作

4 点击 Push Action,可以发起合约交互,这里的界面目前不算友好,还不如bloks.io浏览器做得好

EOSIO 2 简介:提高性能,提高安全性和新的开发人员工具

原文链接:https://eos.io/news/introducing-eosio-2/

EOSIO 2 的构建考虑了开发人员。我们的重点:使其在EOSIO上构建更快,更简单,更安全。

我们认为,区块链开发的最大瓶颈是他们执行智能合约的速度。

EOSIO是第一个使用WebAssembly(WASM)引擎提高性能的区块链软件,但是随着时间的推移,我们超越了现有的通用WASM引擎,你知道的我们可以做得更多。

我们的解决方案是:构建我们自己的解决方案,并从头开始考虑区块链。EOS VM是我们专门构建的区块链WASM引擎,与EOSIO 1.0一起发布的Binaryen相比,运行EOS Mechanics WASM CPU基准的速度最高可快16倍。

接下来,我们想解决新开发人员的入门障碍–那些首次前往#eosio的hackathon或首次在EOSIO上进行开发的开发人员。通常,设置区块链开发环境是一个多步骤的过程,可能需要数小时甚至数天才能完成。这就是为什么我们要构建EOSIO Quickstart Web IDE,这是一个开发工具,它使新开发人员可以在几分钟之内从入门到准备就绪。

最后,对于任何开发人员而言,将新用户加入区块链应用程序的主要痛点之一就是保护私钥和公钥,如果操作不当,则会带来安全风险。通过此版本的WebAuthn对EOSIO的支持,开发人员可以开始在其EOSIO应用程序中使用WebAuthn测试事务签名,从而为当今区块链中不存在的私钥提供一定程度的安全性。

继续阅读以进一步解释EOSIO 2.0 Release Candidate中包含的四个主要组件:

EOS VM

专门用于区块链应用程序的高性能WebAssembly(WASM)引擎,可在处理智能合约和显着提高性能时促进更有效地使用系统资源。
EOSIO快速入门Web IDE:一个功能强大的,新的,自包含的,基于Web的集成开发环境,用于构建EOSIO智能合约和关联的Web应用程序。它可以在几分钟内完成设置,可以在任何浏览器中运行,并有助于降低新的EOSIO区块链开发人员的进入门槛。
WebAuthn支持:一种广泛接受的安全身份验证标准,无需进行浏览器扩展或其他软件即可进行交易签名。
加权阈值多签名块生产支持:块生产者使用不同的密钥在主块和备用块生产硬件上对块进行签名的安全方法。

我们已经开发了一种新的专用WebAssembly(WASM)引擎,称为EOS VM,可以满足EOSIO区块链上安全的确定性执行的不断增长的需求。尽管非常适合它们的目的,但是Binaryen和WABT解释器在内存分配不受限制,加载时间延长和堆栈溢出方面存在问题,并且它们在运行时缺少沙箱。这些问题加在一起,限制了整体性能和可靠性。

作为最初的WASM解决方案,Binaryen解释器于2018年6月发布,带有EOSIO 1.0,同年9月被EOSIO 1.3支持WABT所取代,性能提高了2倍。借助EOSIO 2,我们将发布一个名为EOS VM的新WASM引擎,该引擎由三个组件组成,每个组件都有自己的功能并提供特定的性能增强。

区块链WebAssembly执行的强大组件三重奏

EOS VM解释器是一个WebAssembly解释器,提供了极快的解析/加载,确定性和高效的时限执行。从头开始设计解释器,使我们能够为将来对智能合约的调试支持腾出空间。

EOS VM即时(JIT)编译器是WebAssembly编译器,它采用WASM并即时生成本机代码。与WABT,Binaryen和EOS VM解释器之类的解释器相比,该体系结构能够非常快速地执行WASM智能合约,并提供显着的性能优势。这种JIT解决方案的绝对速度使我们能够在区块链上使用它,而无需其他解决方案进行较长的块编译时间。

EOS VM优化编译器是EOS VM的第三个组件,它使用了利用多遍编译架构的专用编译器框架(LLVM)。通过优化编译器生成的本机代码通常比在WABT,Binaryen,EOS VM解释器和EOS VM JIT中执行的相同代码快一个数量级。最重要的是,它甚至比现有的WAVM引擎还要快,但是与WAVM不同,它可以利用我们的分层设计在区块链上安全使用。

极快的执行性能

我们针对不同组件的基准测试在我们的测试环境中产生了以下性能增强:

以上性能基准显示了各种EOS VM组件的相对优势。EOSIO 2将EOS VM JIT作为大多数智能合约执行的一线编译器,而EOS VM Optimized Compiler尝试在后台编译相同的智能合约,并将其部署以在链上以极快的速度随后执行。这种分层架构使EOSIO 2能够利用快速启动和优化的智能合约代码编译功能。

EOS VM及其组件也可以高度自定义,因此开发人员可以以适合其所需功能的特定方式实现其各个方面。通过参考GitHub上的EOS VM存储库了解更多信息。

网络代码的重大改进

我们向net_plugin添加了多线程支持。现在,net_plugin中的几乎所有处理,包括块传播,事务处理,块/事务打包/解压缩以及其他进程,都由与主应用程序线程不同的单独线程来处理。通过隔离这些过程,我们发现多生产者EOSIO网络上的事务处理和块处理性能有了显着改善。更多详细信息,请参见EOSIO 2.0.0-rc1发行说明。

EOSIO快速入门Web IDE
EOSIO 2的增强功能是针对开发人员的,此新工具将使在EOSIO项目上开始,共享和协作变得更加容易。

为EOSIO 设置开发环境目前需要在开发人员的计算机上本地运行的多步骤过程,这对于刚入职的人来说可能相当复杂。现在处于Alpha支持阶段,EOSIO Quickstart Web IDE打算消除开发人员的入门障碍。它在云中运行,使新开发人员能够建立智能合约和Web应用程序开发环境以及完全集成的单节点个人测试网,因此他们可以在几分钟之内从入门到构建。

EOSIO快速入门Web IDE使新的区块链开发人员可以更轻松地访问EOSIO,从而简化了流程,并使快速而轻松地开始学习EOSIO开发。开发人员可以从演示应用程序开始,无缝地进行更改,并实时查看更新,以及直接从浏览器将代码提交到git存储库。

随着新的开发人员开始使用EOSIO Quickstart Web IDE进行构建,我们期待收到社区的反馈。

对WebAuthn支持

WebAuthn是强大的用户身份验证的标准,由万维网联盟(W3C),在线快速身份验证(FIDO)联盟在Google,Mozilla,Microsoft,Yubico等公司的帮助下进行了协作。WebAuthn允许您使用硬件设备在浏览器中对交易进行身份验证和签名,而无需在设备上安装扩展程序或其他软件。

WebAuthn在诸如YubiKey之类的设备上创建加密密钥对,并通过安全且经过身份验证的通道仅与远程服务器共享公共密钥。通过完全在硬件设备中管理身份验证凭据,WebAuthn已显示出从本质上缓解了整个网络钓鱼等攻击类型。由于硬件设备是必不可少的,并且密码没有存储在中央服务器上,因此实现基于WebAuthn的身份验证甚至可以帮助防止密码被盗的高规格数据泄露。

通过此版本的WebAuthn对EOSIO的支持,开发人员可以开始在其EOSIO应用程序中使用WebAuthn测试事务签名。EOSIO对WebAuthn的支持是迈向安全和无缝事务签名的一步,而无需跟踪私钥或其他帐户信息。我们将继续研究各种机制,以支持希望针对WebAuthn集成调整其应用程序的面向社区的参与者和企业级参与者,并且我们鼓励应用程序开发人员加入第一批尝试采用该技术的私人应用程序的第一批采用者。

加权门限多签名块生产

区块生产者必须能够为其运行区块链的核心服务提供高可用性。实现此目的的常用方法是冗余基础结构,在发生硬件故障或网络问题时,该基础结构可有效地保持块生产。加权阈值多签名块生产是许多功能中的第一个,旨在为块生产者提供完整的高可用性解决方案。

当前的共识规则要求每个块生产者仅需要一个加密块签名密钥。该密钥,无论是存储在磁盘上并通过软件加载还是由硬件钱包保护,都代表了块生产者操作的单点故障。如果该密钥丢失或暂时无法访问包含它的硬件模块,则块生产者别无选择,只能丢弃块,从而影响整个网络的吞吐量。

为了提高块生产的安全性和可伸缩性,加权阈值多签名块支持提供了一个允许层,该许可层允许以灵活方案使用多个块签名密钥,这将使冗余块签名基础结构能够存在而无需共享任何敏感数据。在GitHub上了解有关加权阈值多签名块生产的更多信息。

EOSIO 历史工具 (Alpha 版本)

随着区块链网络数据的不断增长,链上历史状态数据的查询读取越发困难。为了解决这一难题,Block.one 一直在开发一系列历史工具,以让 EOSIO 区块链上的访问数据操作更加简单快捷。

Block.one 之前发布了“状态历史插件”来优化数据访问,“状态历史插件”将区块链状态数据保存为新的平面文件格式,并且暴露一个 websocket 接口来读取区块/状态数据。

在现在的 Alpha 版本历史工具解决方案中,Block.one 通过引入 database fillers 来读取状态数据并且填充 PostgreSQL 和 LMDB 数据库,可以使用特定客户端和服务器wasm进行查询。

更多技术细节文档请阅读 Github 仓库:

https://github.com/EOSIO/history-tools

相关文档说明链接:

https://eosio.github.io/history-tools/

一文读懂 EOSIO 史上最复杂硬分叉升级及未来影响

作者:孤矢,EOS 原力创始人

2019 年年初,一些媒体开始报道 EOS.IO 代码提交次数下降的问题,我们 EOS 原力团队曾经公开回应过:EOS.IO 每天都有多个开发者在提交代码,这些开发内容在不同的分支里提交,并且需要经过测试以后再合并到主线。今天我们要提到的 1.8.0-rc2 就是此类情况,从 2019 年年初甚至更早就开始进行了开发,直到 2019 年 5 月 15 日 1.8.0-rc2 发布。

接下来我们将详细解释此次更新何以如此重要。

一、1.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 并没有应对硬分叉的机制 , 硬分叉的过程会对用户的使用带来很大影响 , 为了使以后的更新不会像这一次一样造成很大影响 , 这次更新中添加了一系列硬分叉升级机制 , 为的是以后的硬分叉更新可以更加平滑和安全。

在 EOS 原力过往的更新中 , 原力团队也遇到了同样的问题 , 所以引入了链配置功能 , 通过这个机制向链添加特性的开启区块高度和链维护状态 , 以此解决硬分叉中的过渡问题 , Block.One 的对策与此类似 , 通过引入 protocol feature 来解决这个问题 , 与原力强调简单通用的解决方案不同 , Block.One 的 feature 设计希望更加完备的解决特性的兼容问题 , 具体的设计可以参见 #6831。

这里可以判断 Block.One 以后的开发过程中会有比之以往更多的硬分叉 , 未来 EOS.IO 的进展会明显快于以往 .

二 EOS.IO 硬分叉影响

EOS.IO 第一次使用硬分叉方式来升级,因此带来的影响也是非常巨大的。

1 节点

大部分节点应该没有经历过硬分叉升级 , 如果严格按照硬分叉的要求来,所有节点需要重放一遍区块,按现在的节点配置,大多数节点最少需要数天才能完成区块重放,当然,还有一种比较偷懒的方法,就是直接使用其他机构提供的快照,但是这样的坏处是如果太多核心节点尤其是 BP 如果这样更新 , 则会影响整个链的安全性。

2 用户

交易所,钱包,区块浏览器,DAPP 等所有的 P2P 节点都会暂停一段时间,其他所有的外部访问数据都会中断,用户感知非常明显。
当然,区块链本身并没有停止,只是为了安全着想,暂停外部和链的交互。

3 DAPP 开发者

理论上链的硬分叉不会影响合约的运行 , 但是考虑到很多 DAPP 采取了半中心化的架构 , 有大量的逻辑在链外运行并与链交互 , 这样一次硬分叉势必带来一定的风险。

三 硬分叉好处和风险

1 好处

在互联网时代,产品迭代是家常便饭,几乎每周开发者都会发布新的版本,用户也习惯第一时间更新升级享受更多的功能和服务。
而此前硬分叉升级在区块链行业几乎非常少见,原因是大部分区块链由去中心化的自由开发者组成,因此开发进度缓慢,节点极其分散,导致硬分叉升级更加麻烦,以比特币为例,2010 年的溢出漏洞导致了导致了 1840 亿的 BTC 凭空创建出来,中本聪第一时间发布了新的版本硬分叉升级,避免了比特币的危机,后来中本聪离开社区后,比特币由社区接管,硬分叉升级很难达成共识,因此很少使用硬分叉升级的方式。

而 Block.One 团队是一个专业开发组织,开发进度比以往的区块链项目得到了指数级的提升,因此快速迭代适应用户需求成为了主流。以目前大多数公有链的技术架构来看,如果要实现大规模的功能升级,硬分叉升级的方式不可避免。

2 风险

如果分叉的过程中超级节点作恶,分叉过程会变得十分危险,如果一部分节点联合起来拒绝升级,那么大概率会出现两个 EOS。

Blockone 做了一定的防范措施:尽管 Block.One 在 2019 年上半年进行了大量的开发,有很多的新功能,但是此次更新只包括一些必要的功能和安全性问题修复 , 等到 feature 上线后硬分叉会变得更加顺利。

四、本次硬分叉注意事项

这是 EOS.IO 面临的第一次硬分叉更新,而且是没有在一个有效的升级机制下进行的硬分叉更新,需要节点和社区付出更多的努力。EOS 原力团队从主网启动开始进行过多次大规模的硬分叉升级以迭代新的功能,这里我们分享一下硬分叉升级中的一些经验:

首先 , 准备越多则更新越顺利 , 在更新之前 , 节点必须做好备份工作 , 当前 EOS.IO 节点数据很大 , 节点备份时也一定要考虑恢复备份数据时的效率 , 备份数据与节点一定要在同一内网中 , 不要依赖于他人的备份 , 否则出现问题时传输备份数据的时间会很漫长 , 最好的方式是直接建立节点的备份节点。

其次 , 需要注意控制节点的交互 , 在更新的过程中 , 整个 EOS.IO 网络会处于一个节点半兼容状态 , 此时如果有人提交触发不兼容逻辑的交易到已经更新过的 BP, 则会导致未更新的 BP 立即分叉 , 虽然这次硬分叉的功能本身就是基于 feature 来管理是否生效的 , 同时执行逻辑出错的交易一般不会在 p2p 网络中传递 , 但是很难排出完全不会出现整个网络分裂的可能性 , 所以在更新过程中节点尤其是超级节点要注意控制交互 , 首先是要控制 http api 的开放 , 可以适当的开启几个 rpc 节点 , 但 rpc 节点与出块几点间不能有直接的 p2p 链接 , 同时重要的节点与其他外部节点间也不要有直接的 p2p 链接 , 这样可以在出现硬分叉时保证关键节点运行。

最后 , 需要控制好更新次序 , 如果基于一个有序的更新次序 , 即使有硬分叉可能 , 多数节点也不会受到影响 , EOS.IO 中的节点往往分为数据节点、出块节点、RPC 节点和同步节点 , 通过控制节点的交互可以很容易的为出块节点门建立一个“绿区”, 屏蔽外部对核心的出块节点的影响 , 此时出块节点可以进行升级 , 在此之后 , 逐步更新出块节点与外部的同步节点 , 同时应该为社区中的数据节点和其他只读节点预留一个更新窗口期 , 社区和开发者的节点可以一次类推 , 先通过建立屏蔽的同步节点建立一个安全区 , 再更新内部节点 , 最后更新同步节点 , 最终当大部分节点以及全部的核心节点更新完毕之后 , 再更新 RPC 节点 , 进而完成整个网络的更新。

其实以上谈到的手段和部署规范早已是老生常谈 , 只不过很多节点的维护者并没有严格的按照规范规划节点的部署 , 可以预见 , 如果节点的维护者还不完善节点部署 , 那么在这次更新中将会是很多问题的一个集中爆发点。

总之 , 越多准备则越加顺利 , 很多问题无法预测 , 所以节点在正式更新之前应当进行一次或者多次演练 , 这样会让 EOS.IO 的这次升级更加稳定。

五、硬分叉的意义是什么

硬分叉本应该是一个再普通不过的技术词汇,然而不同目的的硬分叉会产生不同的结果,因此社区对于硬分叉概念有着非常不同的理解。

从技术角度来讲:硬分叉会导致新的规则不兼容以前的规则,如果获得社区所有人的支持,那么大概率不会有什么影响。

从社区角度来讲:硬分叉时如果出现不同的共识和技术路线,那么大概率社区会分叉成两个公有链,各自支持不同的路线。

2016 年,以太坊(ETH)出现了 DAO 危机,创始人 Vitalik 决定回滚交易,社区有一部分人不同意回滚交易,认为区块链账本不可篡改,拒绝回滚,因此诞生 ETC (以太坊经典)。

2017 年,比特币(BTC)的拥堵使得大区块的支持者迫不及待要改进比特币,但是社区里有不同意见,因此诞生了比特币现金(BCH)。

2018 年,EOS 主网启动时,EOS 原力团队提出了不同的治理路线,随后诞生了 EOS 原力(EOSC)。我们可以看到,Block.one 团队做了大量的准备。

六、本次硬分叉的重要性

本次硬分叉是 EOS.IO 诞生以来最重要的版本,所有基于 EOS.IO 开发的公有链如 EOS,EOSC,ENU,Telos, BOS,Worbli 等均需要采用硬分叉升级。

Block.One 作为业内水平最高的开发组织之一,开发思路都非常大胆,此次添加了硬分叉机制,意味着后半年还会至少有两三次硬分叉。

以往的区块链都非常害怕硬分叉,只有 BCH 社区维持着半年一次的硬分叉升级, EOS 原力也进行过多次硬分叉升级,随着节点和社区认知的发展,硬分叉将不再是一个令人恐慌的词汇,反而会成为区块链进步的方式,即使出现新的分支也是有意义的探索。

此次硬分叉升级将会给 EOS.IO 带来更多的功能和易用性,可以预计,如果想要使得公有链适应时代的发展,未来硬分叉的升级方式将会成为主流。

七、关于近期社区关于 BM 跑路的传言。

近期又有传言称 BM 开发了新的项目,引发了 EOS.IO 社区的恐慌。

从 EOS.IO 的角度来讲,主网启动后 Block.One 在 EOS.IO 上付出了极大的努力,持续高效的开发将 EOS.IO 打造成了最强大的去中心化应用软件平台。同时,社区也有 EOS 原力,EOS Canada BOS Core 这样一直在公链开发一线深耕的团队,即使 BM 离开社区也不会影响 EOS.IO 的发展。

EOS 原力团队追踪着世界上大部分主流公有链的实际开发进展,无论是开发速度还是代码质量,BlockOne 在 EOS.IO 开发上的表现远超其他主流公有链开发团队,和 1.8.0-rc2 一样重要的分支还有多个都在开发中,让我们拭目以待。


EOS原力团队专注 EOSIO 的开发,最近在招聘 C++ 区块链工程师,有意进入EOS区块链开发的小伙伴可以关注下

推荐一个好工具 EOS Studio Web 版

EOS Studio Web 的使命是建立一个简单的、完整的、功能强大的在线合约开发和分享平台,为从新手开发者到大型开发团队提供基础设施和技术服务。这个平台由三个部分组成,它们将共同作用,创造一个更加便捷地合约开发资源网络:
1、即开即用的 Web 端集成开发环境;
2、在线的智能合约分享平台;
3、丰富的在线开发教程和相关资源。
即开即用的 Web 端集成开发环境
我们移植了桌面版所具有的全部核心功能,降低了配置和部署本地环境的门槛,即使是新手小白也能轻松地在线开始学习区块链开发。

主要功能和特点:
  • 在线代码编辑器:支持语法高亮,自动补全,代码错误提醒等常用功能;
  • 云端的合约编译器:为方便您运行早期版本的智能合约,我们支持随时切换 v1.3 – v1.6 版本的 EOSIO.CDT;
  • 云端的 EOSIO 节点托管服务:无需搭建本地开发环境,省去大量初始化时间和硬盘存储空间(感谢 dfuse 团队提供服务);
  • 在开发不同阶段随时切换不同网络:随时切换使用 EOS Studio 专属云托管网络,Jungle / Kylin 测试网,和 EOSIO 主网;
  • 合约调试器和账户查看器:提供和 EOS Studio 桌面版同样强大的合约调试及账户查看功能;
  • 交易签名工具:支持使用 Scatter 和其他移动端钱包进行交易签名。

Web IDE 直达链接:https://app.eosstudio.io/

EOSIO Authenticator APP 测试

基于 B1 钱包的开源代码,已经有团队完成了应用商店的上架

EOS Authenticator – iOS App by EOSLaomao
https://itunes.apple.com/app/eos-authenticator-app/id1466212988?mt=8

EOSIO Authenticator – Chrome 插件 by 麦子钱包
https://chrome.google.com/webstore/detail/eosio-authenticator/nnpajjdpjdjjchhlkndibblhelbdjaio?hl=en-US

目前 EOS 主网尚无 DAPP 支持 EOS Authenticator 协议,可以通过下面的这个 Demo 来进行测试
https://tropical.eoslaomao.com

EOS应用开发视频教程

麦子钱包 CTO 讲的一个 EOS 应用开发视频教程
https://www.youtube.com/playlist?list=PLyM_BB-jMJPrj79ykPNQPgJ5kinwLi8W_

还有一本配套实体书
https://search.jd.com/Search?keyword=EOS%E5%8C%BA%E5%9D%97%E9%93%BE%E5%BA%94%E7%94%A8%E5%BC%80%E5%8F%91%E6%8C%87%E5%8D%97&enc=utf-8&wq=EOS%E5%8C%BA%E5%9D%97%E9%93%BE%E5%BA%94%E7%94%A8%E5%BC%80%E5%8F%91%E6%8C%87%E5%8D%97

和一套开源代码
https://github.com/ericfish/EOS-Dev-Book/

感兴趣的可以看看

从 Steem 看 Voice 的二次开发机会

今天 BlockOne 发布了 Voice 平台 ( https://voice.com ),区块链应用一个很大的机会就是所有数据都是链上的,所以除了官方的应用,有大量二次开发的机会。
Voice 从经济模型逻辑上和 Steem 比较类似,毕竟都是 BM 的产物。
本文就从 Steem 平台的一些二次开发应用看看 Voice 会有哪些相应的机会。

垂直分类的社区

比如下面这个基于Steem平台,专注旅游社交
https://dtrip.app/

数据

专注提供各种数据,比如每日发帖,排行榜等等

https://share2steem.io/

http://steemd.com

社交分析

这个网站输入用户名即可找到你的贵人,就是通过持续点赞给你带来收入的那些用户
http://steemvp.com/

用户的排名

大户排行榜,拉拢大户可以让你的文章权重更高
https://steemwhales.com/

数据库

数据服务,链上数据效率较低,通过缓存,重新提供更高效的接口
https://steemdb.com/

商店

基于社交的电商
https://www.peerhub.com/

特定区域的定制语言版本

定制独立的语言版本,和特定区域的用户
http://cnstm.org/

发布工具

SteemPress是一个WordPress插件,可以将任何博客连接到Steem区块链。

Block.one的通用验证器库(UAL)

随着 EOS 发布开源的钱包代码,以及6月大会即将发布的新产品,UAL会成为EOS DApp开发的新标准,本文对UAL做一个简单介绍。

UAL:Universal Authenticator Library

通用验证器库(UAL)允许应用程序开发人员与各种验证器(钱包、应用程序探索器、密钥管理器等)集成。通过编码到一个单一的,通用的API。它还为开发人员提供了一个可选但保留己见的UI层,以便应用程序用户能够获得一致的外观,并感觉独立于他们正在使用的验证器或他们所在的站点。

一旦集成,应用程序能够为他们的用户提供类似于社交登录或单点登录的体验,只需付出很少的努力。随着越来越多的验证器被开发出来,支持它们就像添加几行代码一样简单。

开源的Library
https://github.com/EOSIO/universal-authenticator-library

DApp使用指引
https://github.com/EOSIO/ual-authenticator-walkthrough

从源代码上理解REX

首先我们要定义八个术语,保证我们理解它们,它们对 REX 讨论都非常重要。
成熟期——当你购买 REX 代币时,在四天内将无法把它们换回 EOS。在此期间,这些代币被称为在成熟期。在同一天的不同时间购买的 REX 都从第二天0点开始计时,所以你最多可以有四个不同的到期日。
4天——如上所述,到期日的计算均从 UTC 时间的第二天00:00开始。因此,如果用户在今天16:00 UTC 购买 REX 代币,那么他们将只能在4天8小时后卖回 EOS(成熟后)。所以每当人们说“四天”时,它实际上是从购买后的 00:00 UTC 计算的四天。
30天——每次借用的 CPU 或网络带宽的有效期为30天。只有借来这些资源的用户才需要注意这个30天的期限。如果你是借出你的代币资源的用户,你只需要注意四天的成熟期。
储蓄桶——你可以选择把 REX 代币放到储蓄桶里,放到储蓄桶里的代不会自动进入成熟期的,直到你提出要取出里面的代币,它才会开始四天的成熟期,成熟后才能移动它们。这是为了让你能保证你的代币安全的一个选项。举一个具体的用例,如果你的活跃权限的密钥被盗,有你的密钥的人就能动用你已经成熟了的 REX 代币,换回 EOS 然后盗走。但是如果你的 REX 在储蓄桶里,你就有时间用拥有者权限更改你的活跃权限,然后取消储蓄桶里代币的成熟期。
REX 基金——要与 REX 交互,你先要在把 EOS 代币存入你的 REX 基金中 ,REX 基金中存的是 EOS 而不是 REX 代币。
投票前提——想用 REX 出租自己资源,有一个前提,他们必须至少投票给21个BP节点或者代理投票。
流动性紧缩——这种情况出现的几率很小,但是我们还是应该有所了解。如果在池中没有足够的EOS 代币来满足提款的数量,这种现象就叫“流动性紧缩”。这意味着所有提款订单会被排队,等有新的 EOS 代币进入 REX 池之后,或者有借用的资源到期。用户赎回 EOS 是没有风险的,他们可能最多需要等待30天,但再强调,这个现象是非常罕见的。
市场价——REX 由 Bancor 支持的,就是说价格不是由用户自己竞价决定的,而是由系统根据池中 EOS 和 REX 代币的比率去计算的。这就是为什么收益率或续约价格是不确定的,因为一切都是在购买时确定的,取决于买卖时间和当时的状况。
我们还想强调一下两件值得注意的事情。EOS:REX 比值的确定方式决定了你卖出REX收回EOS数量不是高于就是等于你投入的EOS数量。这意味着你永远不会因为持有 REX 而失去任何 EOS,你只会获益。
另一点是,在获取帐户快照时,空投可以选择是否考虑你的 REX 余额。就是说你在 REX 中的代币会不会被包含在内取决于该空投的开发者。
我们现在来看一下在与 REX 交互时可调用的所有操作,并作出相关解释。