hardhat 教程及 hardhat-deploy 插件使用

调用 rxjs 的 ajax 报 'CORS is not supported by your browser'

伦敦升级的测试网 Aleut 将包含 EIP1559 和 EIP3198（BASEFEE 操作码）。EIP3238（难度炸弹推迟）也必须包含在伦敦升级中 伦敦/上海升级 可能纳入的候选 EIP：EIP3403（禁用 Gas 返还）、EIP3074（AUTH 以及 AUTHCALL）和 EIP2537（BLS 预编译）

EIP-3074 提供的是功能强大的基元，能为更多顺滑用户体验打开可能性而无须引入额外的信任假设。

自上一版无状态以太坊的全面 “路线图” 发布以来已经过去了一段时间，现在很多东西都发生了改变。似乎又到了需要 “全都写下来” 的时候了。

以太坊基金会发布针对信标链安全性和测试的提案请求 (RFP)。

社会力量所支撑的各种极其强大的机制远远超过了区块链领域。本文中把这种强大的社会力量称之为：认受性。

演完了狗血家庭伦理剧后的矿工，此时应该开始觉醒复仇了！

本篇聊聊旷工的意见

Beiko 的升级计划进度总结：柏林升级已在测试网激活，1559 计划在 7 月/8 月推出，不确定在关闭 PoW 之前要完成哪些新功能

要根据这个私钥生成一个以太坊地址，我们需要使用椭圆曲线点乘算法

当前的以太坊1.0链最大的问题在于其状态大小。约为 10-100 GB (具体取决于其存储方式)，对于许多节点来说，将其保存在工作内存中是不切实际的，因此会选择慢速固定存储。然而，硬盘速度过慢难以与以太坊区块保持同步 (或是从创世区块开始同步)，因此必须使用更加昂贵的 SSD。这么说吧，当前的状态大小还不是最大的问题，而是状态的增长成本相对较低，并且会一直增长，即时我们提高状态增长的成本，也无法使状态占用者为网络实际受到的影响付费，而该影响是永恒存在的。

自 19 年 3 月了解了 “无状态性” 概念以来，我便认定，无状态性是以太坊最值得研究的底层协议演化方向，唯有它能既解决状态膨胀问题，又维持以太坊的经济属性。今天我仍这么相信。只是，对状态膨胀问题的思考，会不断牵涉到以太坊的底层范式 —— 全局状态和链上计算 —— 最终具象化为一个问题：如何为链上操作制定名义开销比例（gas cost）？无论要对以太坊作什么改进，都绕不开这个问题。最终你也会得到跟我一样的结论：以太坊的设计失衡之处不是一处，而是两处。无状态性之后，我们仍有迢迢长路。

Altair 的预发布已出炉

最近EIP-1559的事情吵得不可开交，于是我也来蹭蹭热点，来给大家讲讲EIP-1559的同时也给大家讲讲谁在争吵，以及究竟在吵什么。

Turbogeth 客户端最新 Alpha 版发布，支持柏林升级

Layer 2 扩容技术可以帮助以太坊实现性能的跃进，长期来看至少两个数量级的吞吐量提升没有问题。但是除了安全性这个不确定性因素之外，退出期的用户体验，以及不同二层网络之间的流动性割裂可能会成为目前最值得关注的话题。

针对近期频繁发生的以太坊三明治套利交易，开发者CodeForcer创建了一种名为“沙门氏菌”（Salmonella）的ERC20诱饵代币，通过这种方式，其在24小时内实现盈利130 ETH，而这也告诉了我们关于以太坊网络Mempool黑暗森林的对抗性。

本文意在讲解 StarkEX 为支持快速取款（Fast Withdrawel）（在一个区块时间内从 Layer-2 中取款到任意 Layer-1 地址）而提出的解决方案。本方案的优点在于，其速度完全独立于 L2 的运营者生成有效性证明的速度。

本文旨在向初学者解释何为 Layer2，因此难免会牺牲一定的完整性和严密性，让读者在基础的水平上更好地理解文章。