eth

ETH 浏览器

ETH 2.0 官方安装文档

eth 开源浏览器

eth社区提供的公共端点列表

特点

允许开发者构建和部署去中心化应用(dApps)和智能合约的平台

节点服务商

Quiknode

Infura

networkid

用于标识特定的以太坊网络

1: 主网(Mainnet) 2: Morden测试网(Morden Testnet) - 弃用 3: Ropsten测试网(Ropsten Testnet) - Proof of work 工作量证明 4: Rinkeby测试网(Rinkeby Testnet) - Proof of authority 权益证明 42: Kovan测试网(Kovan Testnet) - Not supported by geth

客户端类型

区分执行客户端 和 共识客户端

执行客户端

Geth            # go
Nethermind      # .net
Besu            # java
Erigon          # go

共识客户端

Lighthouse      # rust
Lodestar        # typescript
Nimbus          # nim
Prysm           # go
Teku            # java

不同的执行客户端可能的差异

  1. 可用功能: 有些 debug 功能或rpc方法没有做实现
  2. 输出格式: 即使两个客户端支持相同的方法, 结果的 JSON 结构也可能不同;
  3. 性能差异;
  4. 同步方法和修剪: 客户端在从网络同步以及在本地保留的历史状态方面有所不同;

节点

节点的工作

Receive Transactions # 接收来自 DApp, 钱包或其它节点的交易信息
Receive Blocks # 从其它节点接收区块信息同步至最新的区块高度
Validating # 验证新的区块之正确性, 验证待处理交易之有效性
Executing # 处理交易, 进行运算并更改状态值, 打包成新区块
Mining # 挖矿, 计算 nonce 值, 最先找到 nonce 值出块并广播的矿工可以获得区块奖励与所有交易之手续费(Gas)
Consensus # 通过共识机制达成全网帐本之一致性或区块重组(reorg)

节点类型

主要节点类型

  1. 全节点 Full Node
  2. 轻节点 Light Node
  3. 归档节点 Archive Node

其它分类方式

  1. 验证节点 Validator Node
  2. 观察节点 Observer Node
  3. 种子节点 Seed Node
  4. 同步节点 Sync Node

矿工节点 矿工必须要运行全节点才能即时浏览区块链历史资料进行交易验证, 再将验证通过的交易进行打包; 因此, 所有矿工必定是全节点

full node 全节点

具备独立验证的能力来确认交易之有效性

  1. 完整存储所有区块头和区块体
  2. 有足够的近期状态数据, 通常是最近 128 个块

主要在处理下列四件事:

  1. 储存所有历史交易信息, 资料公开透明
  2. 监测矿工挖出来的新区块, 验证其合法性后同步该区块
  3. 监测区块链网络中的新交易信息, 验证每个交易的合法性
  4. 将验证过的「交易/区块信息」广播给全网络节点

一个节点只要下载了完整且最新的区块链资料, 稳定运行验证交易和同步区块信息, 那就是一个全节点

裁剪前的状态数据可以通过重放来恢复, 同步方式可以是全量同步和快照同步(较近的区块开始)

Archive Node 归档节点

在全节点的基础上, 存储有每个区块的状态数据。

归档节点截至 2020/05 的资料大小已经超过 4 TB

通常只有节点运营商或浏览器运营商会部署归档节点;

Light Node 轻节点

  1. 仅存储区块头
  2. 依赖 full 节点来获取其需要的任何其他数据

使用区块头中包含的加密证明来验证该数据, 从而允许它在不保存完整链的情况下确认正确性

轻节点

轻节点 Light Node

不储存或维护完整的区块链副本,只储存最小量的状态来作为发送或传递交易讯息的节点。

特点

  1. 一般只储存每个区块的区块头 Block Header,
  2. 也存储有少量与自己交易相关的状态;
  3. 无法验证大多数交易的合法性, 只能验证与自己相关交易的合法性
  4. 无法验证新区块的正确性
  5. 只能检测到当前的最长链, 但无法知道哪条是最长合法链
  6. 交易验证需要转发到其它全节点进行

工作原理是每隔 1.1 天随机选择一个包含 512 个验证者的子集, 用于充当同步委员会;

Block Header and Body

以太坊的每个区块主要分为 Header 和 Body 两个部分存储,

  1. Body 即是交易列表;
  2. Block Header 则较为复杂, 包含了前个区块的 Hash, 时间戳及挖矿难度等相关参数;

在 Block Header 中采用一种名为 Merkle-Patricia Trie (MPT) 的核心资料结构来储存区块链信息, 可以理解为把帐本分割成无数个小的资料块, 每个资料块像是一棵树中的无数叶片, 而我们把每两个相邻的叶片合并成一个字串, 并算出该字串的 Hash 值; 如此过程经过无数次后, 最终如同所有树枝归向一个树干一般, 会得到一个包含了所有区块资料的 Hash 值, 称为 Merkle Root ;

存储内容

全节点储存了所有区块的 Block Header 与 Body(交易列表),

而轻节点只储存最小量的状态: 即 Block Header , 借此大幅降低储存空间的需求;

轻节点如何验证交易

当轻节点需要验证某个交易的合法性时, 具体做法为:

  1. 向邻近的全节点发起确认请求
  2. 全节点收到请求后提供所需相关信息供验证
  3. 需要向全节点请求的原因是: 假设有一个合约执行的交易, 那么便必须要有该合约部署时的原始码(位在 Contract Created 之交易中); 由于该交易位于某个区块之 Body, 故轻节点必须要向全节点请求该合约之相关信息方能进行交易验证;

由于轻节点必须要向全节点请求与交易验证相关的 Block Body 信息, 那么要怎么知道全节点回传的信息是正确的呢?

自身存有已经验证合法之 Block Header, 需要要透过跟全节点请求相关的 Block Body 信息即可进行验证, 不需要从头验证整个区块;

轻节点如何保障全节点回传的交易验证信息是正确的呢?

Block Header 里面有一个 MPT hash树, 可以用来验证全节点的内容是否正确。

Block Header 与交易验证

轻节点能够利用 Block Header 验证交易的原因为: Block Header 中的 Merkle Root 即是由 Block Body 中的交易信息经由杂凑演算法(Hash Algorithm)生成的「数位指纹(Digital Fingerprint)」, 因此 Block Header 可以充分代表 Block Body 内的信息;

Block Header 中的 Merkle-Patricia Trie 是一个生成 Hash 需要花费大量算力, 但验证非常迅速的结构; 当轻节点收到全节点提供的信息时, 便能够利用已有的 Block Header 相关讯息迅速验证该信息是否正确, 进一步进行交易验证;

其它

质押要求: 最少 32 ETH(2025 年 Pectra 升级后单个验证者最大可质押 2048 ETH)

时间结构: 每 12 秒一个 slot, 32 个 slot 组成一个 epoch

最终确定性: 2 个 epoch 后交易具有最终确定性

wei
以太币的最小单位, 1 个以太币 =10 的 18 次方个 wei

ERC标准

ERC-20

同质化代币(Fungible Token, FT)的标准接口

比如投票代币, 质押代币或虚拟货币

主要功能

  1. 转账: 将代币从一个帐户转到另一个帐户
  2. 查询余额: 获取帐户的当前代币余额
  3. 查询总量: 获取网络上可用代币的总供应量
  4. 代币授权: 批准一个帐户中一定的代币金额由第三方帐户使用

ERC-721

非同质化代币(NFT)的标准接口

每一个 NFT 都有一个 uint256 类型的变量, 名为 tokenId, 这个 tokenId 在合约里面是唯一的; 这个 tokenId 是由链下传入的

通过一个外部的 dApp 来理解这个 tokenId 对标真实的物品

主要功能

转账,查询余额,查询所有者,查询代币总量; 代币授权: 批准帐户中一定数量的代币可以被第三方帐户转移;

ERC-777

一个易于交易的代币标准, 可改进现有的 ERC20 标准

通过代币上创建额外的功能, 例如用于改善交易私密性的混合合约, 或是在您不慎丢失私钥时的紧急恢复功能;

改进点 钩子: 是智能合约代码中描述的一个函数; 钩子将会在代币通过合约发送或者接收时调用; 这将允许智能合约对进出的代币做出互动

小数位数 该标准还解决了在 ERC20 中造成的 decimals 的混乱; 这种清晰度提升了开发者体验

兼容 ERC20

ERC-165

创建了一个标准方法来发布和检测智能合约实现的接口

ERC-1155

用于多种代币管理的合约标准接口, 方便管理多种代币

允许更有效的交易和打包交易, 从而节省燃料成本;

多代币标准的目的是创建一个智能合约接口, 可以代表和控制任何数量的同质化和非同质化代币类型;

这样一来, ERC-1155 代币就具有与 ERC20 和 ERC721 代币相同的功能, 甚至可以同时使用这两者的功能; 而最重要的是, 它能改善这两种标准的功能, 使其更有效率, 并纠正 ERC20 和 ERC721 标准上明显的实施错误

特殊功能

  1. 批量传输: 通过一次合约调用传输多种资产;
  2. 批量余额: 在一次调用中获取多个资产的余额;
  3. 批量授权: 授权同一地址的所有代币;
  4. Hook: 接收代币的钩子函数;
  5. 支持非同质化代币: 如果供应量仅为 1, 将其作为非同质化代币(NFT)处理;
  6. 安全转账规则: 安全转账规则集;

生态项目

TIA(Celestia)

Celestia 一个专注于数据可用性的模块化区块链项目

Manta

模块化区块链领域, 专为零知识证明(ZKP)应用开发而开发

AltLayer (ALT)

一个开放且去中心化的 Rollup 协议, 旨在为现有 Rollup 提供增强的安全性, 去中心化, 互操作性和快速确定性

Restaked Rollup

是一种特殊的 Rollup 架构, 其核心在于利用重新抵押(再质押)的概念来提升 Rollup 的安全性和去中心化特性

ReStaking 再质押协议

ENS(Ethereum Name Service)

以太坊域名服务

基于以太坊区块链的去中心化, 开放和可扩展的命名系统

UNI(Uniswap)

去中心化的 Dex

Curve

是一个去中心化交易所, 在稳定币兑换方面具有很大优势, 治理代币 CRV

LINK (Chainlink )

Chainlink 是一个在以太坊区块链上的去中心化数据预言机网络, 旨在将区块链智能合约与可信任, 防篡改的现实世界数据来源实时连接起来

预言机

原理就是按设定规则获取外部可信的 api 接口数据; 例如赛马结果可以通过外部的 10 个 api 接口获取后, 来确定真实性, 上链后触发合约的特殊交易;

Chainlink 设置奖罚机制, 以最快速提供真确数据的节点, 会得到智能合约付出的费用, 提供更好信息, 拥有更高声誉的节点, 就能收取更高费用;

相反, 如果节点提供的信息有误, 节点质押的 LINK 会被扣减;

最后更新于