ETH 2.0 资源汇总（持续更新） August 24, 2020 ## 0 概述 本文整理总结了 ETH 2.0 学习、研究的常用资源，持续更新中。 ETH 2.0 整体介绍：https://hackernoon.com/what-to-expect-when-eths-expecting-80cb4951afcd 国内社区翻译版本：https://www.odaily.com/post/5135663  目前，ETH 2.0 已经启动了 Phase 0 测试网，可以通过质押 GöETH 成为验证节点。 - 阅读剩余部分 -
如何开发一款区块链浏览器？ May 20, 2020 ## 摘要 步入币圈大门后，除了钱包应用之外，用户最先接触的应该还有区块链浏览器。区块链浏览器不同于电脑和手机上浏览网页用的浏览器软件，而是指一个网站可以查询区块链上的具体信息。比如，给定区块高度，可以查询该高度区块的创建时间，包含了多少交易；给定一个地址，可以查询余额，该地址的所有交易记录等。当前以太坊上的数据量级已达亿级，如何进行数据持久化和查询呢？本文以以太坊为例，对区块链浏览器原理及存储细节进行分析总结。 - 阅读剩余部分 -
EOS 提交交易失败分析 February 2, 2020 [TOC] EOS 向节点提交交易时失败，提示 billed CPU time (Y us) is greater than the maximum billable CPU time for the transaction (X us). 本文通过分析源代码来一探这个失败的原因，首先给出结论： - 当前时间窗口内（24小时）用户**最大** CPU 时间 = 全网总 CPU 时间 * 当前用户质押 EOS 数量 / 所有用户质押 EOS 数量 - 当前时间窗口内用户**可用** CPU 时间 = 当前用户**最大** CPU 时间 - 当前用户已经使用 CPU 时间 - 当前用户**已经使用** CPU 时间是实时变化的：(1 - t / 24) * t 时间之前使用的资源大小，直到距离上次 CPU 资源使用 24 小时后（t = 24）完全恢复 - Get Account 接口看到的不是实时可用的资源使用量，而是上一笔交易之后缓存的资源使用量 - 向 RPC 节点提交交易时 RPC 节点会计算出当前交易 CPU 使用量，这个 CPU 使用量和当前 RPC 节点 CPU 使用情况有关，通过系统计时器计算时间，因此，RPC 节点计算出的交易 CPU 使用量不是最终上链时的交易使用量，最终交易时的 CPU 使用量由打包节点决定。 - 因此，当质押 CPU EOS 数量固定时，向 RPC 节点提交交易时，CPU 资源需要满足 交易使用 CPU 资源的大小 - 阅读剩余部分 -
以太坊多重签名原理分析 October 17, 2018 ## 目录 [TOC] ## 0 起源与现状 一般来说一个以太坊地址对应一个私钥，动用这个地址中的资金需要私钥的掌握者发起签名才行。消费这笔资金时，所构造的签名交易被称为“单签名交易”。 而多重签名技术，简单来说，一个以太坊地址对应多个私钥，就是动用一笔资金时需要多个私钥签名才有效。消费这笔资金时，所构造的签名交易被称为“多签名交易”，或者“M-of-N 交易”，对应的比特币地址被称为“多签地址”。 目前，在以太坊中常用的多签钱包有： - [Mist](https://github.com/ethereum/mist) 以太坊官方维护的钱包，支持多签 - [Ethereum Wallet](https://www.ethereum.org/) 以太坊官方维护的钱包，支持多签 - [Parity](https://github.com/paritytech/parity-ethereum) 支持多签 在以太坊中，多签钱包全部都是通过智能合约实现，下面介绍以太坊中的多签实现原理，实例分析。 - 阅读剩余部分 -