以太坊代码解析rpc

⑴ 以太坊的 ChainId 与 NetworkId

ChainId 是 EIP-155 引入的一个用来区分不同 EVM 链的一个标识。如下图所示，主要作用就是避免一个交易在签名之后被重复在不同的链上提交。最开始主要是为了防止以太坊交易在以太经典网络上重放或者以太经典交易在以太坊网络上重放。在以太坊网络上是从 2675000 这个区块通过 Spurious Dragon 这个硬分叉升级激活。

引入 ChainId 后，带来了哪些影响呢？

NetworkId 主要用来在网络层标识当前的区块链网络。NetworkId 不一致的两个节点无法建立连接。

NetworkId 无法通过配置文件指定，智能通过参数 --networkid 来指定。所以我们启动自己私链节点上需要记得加上这个参数。如果不加这个参数也不指定网络类型，默认 NetworkId 的值和以太坊主网一致。

不是。
这个根据上面的介绍可以很明显的看出，两者并没有非常高的关联度。
网上几乎所有提到搭建以太坊私链的文章，都要强调 NetworkId 需要和 genesis 文件里 ChainId 的值相同。事实上是没必要的。
就像下面这张图展示的这样，很多已经在主网运行的 EVM 链，它们的 ChainId 和 NetworkId 并不相同。比如以太经典，它的 ChainId 是 61，但 NetworkId 和以太坊主网一样都是 1。

之所以很多文章强调 ChainId 和 NetworkId 要保持一致，可能因为在某一段时间内，一些开发工具比如 MetaMask，会把 NetworkId 当作 ChainId 来用。不过现在 MetaMask 已经支持自定义 ChainId，以太坊也添加了 “eth_chainId” 这个 RPC API，相信两者误用的情况会越来越少。

⑵ 从 0 到 1：全面理解 RPC 远程调用

作者 | Python编程时光

责编 | 胡巍巍

什么是RPC呢？网络给出的解释是这样的：“RPC（Remote Procere Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议”。

这个概念听起来还是比较抽象，没关系，继续往后看，后面概念性的东西，我会讲得足够清楚，让你完全掌握 RPC 的基础内容。

在 OpenStack 里的进程间通信方式主要有两种，一种是基于HTTP协议的RESTFul API方式，另一种则是RPC调用。

那么这两种方式在应用场景上有何区别呢？

有使用经验的人，就会知道：

首先，给你提两个问题，带着这两个问题再往下看：

1、RPC 和 REST 区别是什么？2、为什么要采用RPC呢？

首先，第一个问题：RPC 和 REST 区别是什么？

你一定会觉得这个问题很奇怪，是的，包括我，但是你在网络上一搜，会发现类似对比的文章比比皆是，我在想可能很多初学者由于基础不牢固，才会将不相干的二者拿出来对比吧。既然是这样，那为了让你更加了解陌生的RPC，就从你熟悉得不能再熟悉的 REST 入手吧。

01、所属类别不同

REST，是Representational State Transfer 的简写，中文描述表述性状态传递（是指某个瞬间状态的资源数据的快照，包括资源数据的内容、表述格式(XML、JSON)等信息。）

REST 是一种软件架构风格。这种风格的典型应用，就是HTTP。其因为简单、扩展性强的特点而广受开发者的青睐。

而RPC 呢，是 Remote Procere Call Protocol 的简写，中文描述是远程过程调用，它可以实现客户端像调用本地服务(方法)一样调用服务器的服务(方法)。

而 RPC 可以基于 TCP/UDP，也可以基于 HTTP 协议进行传输的，按理说它和REST不是一个层面意义上的东西，不应该放在一起讨论，但是谁让REST这么流行呢，它是目前最流行的一套互联网应用程序的API设计标准，某种意义下，我们说 REST 可以其实就是指代 HTTP 协议。

02、使用方式不同

03、面向对象不同

从设计上来看，RPC，所谓的远程过程调用 ，是面向方法的 ，REST：所谓的 Representational state transfer ，是面向资源的，除此之外，还有一种叫做 SOA，所谓的面向服务的架构，它是面向消息的，这个接触不多，就不多说了。

04、序列化协议不同

接口调用通常包含两个部分，序列化和通信协议。

通信协议，上面已经提及了，REST 是 基于 HTTP 协议，而 RPC 可以基于 TCP/UDP，也可以基于 HTTP 协议进行传输的。

常见的序列化协议，有：json、xml、hession、protobuf、thrift、text、bytes等，REST 通常使用的是 JSON或者XML，而 RPC 使用的是 JSON-RPC，或者 XML-RPC。

通过以上几点，我们知道了 REST 和 RPC 之间有很明显的差异。

然后第二个问题：为什么要采用RPC呢？

那到底为何要使用 RPC，单纯的依靠RESTful API不可以吗？为什么要搞这么多复杂的协议，渣渣表示真的学不过来了。

关于这一点，以下几点仅是我的个人猜想，仅供交流哈：

说了这么多，我们该如何选择这两者呢？我总结了如下两点，供你参考：

“远程调用”意思就是：被调用方法的具体实现不在程序运行本地，而是在别的某个地方（分布到各个服务器），调用者只想要函数运算的结果，却不需要实现函数的具体细节。

光说不练嘴把式，接下来，我将分别用三种不同的方式全面地让你搞明白 rpc 远程调用是如何实现的。

01、基于 xml-rpc

Python实现 rpc，可以使用标准库里的 SimpleXMLRPCServer，它是基于XML-RPC 协议的。

有了这个模块，开启一个 rpc server，就变得相当简单了。执行以下代码：

有了 rpc server，接下来就是 rpc client，由于我们上面使用的是 XML-RPC，所以 rpc clinet 需要使用xmlrpclib 这个库。

然后，我们通过 server_proxy 对象就可以远程调用之前的rpc server的函数了。

SimpleXMLRPCServer是一个单线程的服务器。这意味着，如果几个客户端同时发出多个请求，其它的请求就必须等待第一个请求完成以后才能继续。

若非要使用 SimpleXMLRPCServer 实现多线程并发，其实也不难。只要将代码改成如下即可。

02、基于json-rpc

SimpleXMLRPCServer 是基于 xml-rpc 实现的远程调用，上面我们也提到 除了 xml-rpc 之外，还有 json-rpc 协议。

那 python 如何实现基于 json-rpc 协议呢？

答案是很多，很多web框架其自身都自己实现了json-rpc，但我们要独立这些框架之外，要寻求一种较为干净的解决方案，我查找到的选择有两种

第一种是 jsonrpclib

第二种是 python-jsonrpc

先来看第一种 jsonrpclib

它与 Python 标准库的 SimpleXMLRPCServer 很类似（因为它的类名就叫做 SimpleJSONRPCServer ，不明真相的人真以为它们是亲兄弟）。或许可以说，jsonrpclib 就是仿照 SimpleXMLRPCServer 标准库来进行编写的。

它的导入与 SimpleXMLRPCServer 略有不同，因为SimpleJSONRPCServer分布在jsonrpclib库中。

服务端

客户端

再来看第二种python-jsonrpc，写起来貌似有些复杂。

服务端

客户端

调用过程如下

还记得上面我提到过的 zabbix API，因为我有接触过，所以也拎出来讲讲。zabbix API 也是基于 json-rpc 2.0协议实现的。

因为内容较多，这里只带大家打个，zabbix 是如何调用的：直接指明要调用 zabbix server 的哪个方法，要传给这个方法的参数有哪些。

03、基于 zerorpc

以上介绍的两种rpc远程调用方式，如果你足够细心，可以发现他们都是http+rpc 两种协议结合实现的。

接下来，我们要介绍的这种（zerorpc），就不再使用走 http 了。

zerorpc 这个第三方库，它是基于TCP协议、 ZeroMQ 和 MessagePack的，速度相对快，响应时间短，并发高。zerorpc 和 pyjsonrpc 一样，需要额外安装，虽然SimpleXMLRPCServer不需要额外安装，但是SimpleXMLRPCServer性能相对差一些。

调用过程如下

客户端除了可以使用zerorpc框架实现代码调用之外，它还支持使用“命令行”的方式调用。

客户端可以使用命令行，那服务端是不是也可以呢？

是的，通过 Github 上的文档几个 demo 可以体验到这个第三方库做真的是优秀。

比如我们可以用下面这个命令，创建一个rpc server，后面这个 time Python 标准库中的 time 模块，zerorpc 会将 time 注册绑定以供client调用。

经过了上面的学习，我们已经学会了如何使用多种方式实现rpc远程调用。

通过对比，zerorpc 可以说是脱颖而出，一支独秀。

为此，我也做了一番思考：

OpenStack 组件繁多，在一个较大的集群内部每个组件内部通过rpc通信频繁，如果都采用rpc直连调用的方式，连接数会非常地多，开销大，若有些 server 是单线程的模式，超时会非常的严重。

OpenStack 是复杂的分布式集群架构，会有多个 rpc server 同时工作，假设有 server01，server02，server03 三个server，当 rpc client 要发出rpc请求时，发给哪个好呢？这是问题一。

你可能会说轮循或者随机，这样对大家都公平。这样的话还会引出另一个问题，倘若请求刚好发到server01，而server01刚好不凑巧，可能由于机器或者其他因为导致服务没在工作，那这个rpc消息可就直接失败了呀。要知道做为一个集群，高可用是基本要求，如果出现刚刚那样的情况其实是很尴尬的。这是问题二。

集群有可能根据实际需要扩充节点数量，如果使用直接调用，耦合度太高，不利于部署和生产。这是问题三。

引入消息中间件，可以很好的解决这些问题。

解决问题一：消息只有一份，接收者由AMQP的负载算法决定，默认为在所有Receiver中均匀发送(round robin)。

解决问题二：有了消息中间件做缓冲站，client 可以任性随意的发，server 都挂掉了？没有关系，等 server 正常工作后，自己来消息中间件取就行了。

解决问题三：无论有多少节点，它们只要认识消息中间件这一个中介就足够了。

既然讲到了消息队列，如果你之前没有接触过这块内容，最好花几分钟的时间跟我好好过下关于消息队列的几个基础概念。

首先，RPC只是定义了一个通信接口，其底层的实现可以各不相同，可以是 socket，也可以是今天要讲的 AMQP。

AMQP(Advanced Message Queuing Protocol)是一种基于队列的可靠消息服务协议，作为一种通信协议，AMQP同样存在多个实现，如Apache Qpid，RabbitMQ等。

以下是 AMQP 中的几个必知的概念：

Publisher：消息发布者

Queue：用来保存消息的存储空间，消息没有被receiver前，保存在队列中。

Exchange：用来接收Publisher发出的消息，根据Routing key 转发消息到对应的Message Queue中，至于转到哪个队列里，这个路由算法又由exchange type决定的。

Exchange type：主要四种描述exchange的类型。

direct：消息路由到满足此条件的队列中(queue,可以有多个)：routing key = binding key

topic：消息路由到满足此条件的队列中(queue,可以有多个)：routing key 匹配 binding pattern. binding pattern是类似正则表达式的字符串，可以满足复杂的路由条件。

fanout：消息路由到多有绑定到该exchange的队列中。

binding ：binding是用来描述exchange和queue之间的关系的概念，一个exchang可以绑定多个队列，这些关系由binding建立。前面说的binding key /binding pattern也是在binding中给出。

为了让你明白这几者的关系，我画了一张模型图。

关于AMQP，有几下几点值得注意：

前面铺垫了那么久，终于到了讲真实应用的场景。在生产中RPC是如何应用的呢？

其他模型我不太清楚，在 OpenStack 中的应用模型是这样的

至于为什么要如此设计，前面我已经给出了自己的观点。

接下来，就是源码解读 OpenStack ，看看其是如何通过rpc进行远程调用的。如若你对此没有兴趣（我知道很多人对此都没有兴趣，所以不浪费大家时间），可以直接跳过这一节，进入下一节。

目前Openstack中有两种RPC实现，一种是在oslo messaging,一种是在openstack.common.rpc。

openstack.common.rpc是旧的实现，oslo messaging是对openstack.common.rpc的重构。openstack.common.rpc在每个项目中都存在一份拷贝，oslo messaging即将这些公共代码抽取出来，形成一个新的项目。oslo messaging也对RPC API 进行了重新设计，对多种 transport 做了进一步封装，底层也是用到了kombu这个AMQP库。（注：Kombu 是Python中的messaging库。Kombu旨在通过为AMQ协议提供惯用的高级接口，使Python中的消息传递尽可能简单，并为常见的消息传递问题提供经过验证和测试的解决方案。）

关于oslo_messaging库，主要提供了两种独立的API:

因为 notify 实现是太简单了，所以这里我就不多说了，如果有人想要看这方面内容，可以收藏我的博客(http://python-online.cn) ，我会更新补充 notify 的内容。

OpenStack RPC 模块提供了 rpc.call，rpc.cast, rpc.fanout_cast 三种 RPC 调用方法，发送和接收 RPC 请求。

rpc.call 和 .rpc.cast 从实现代码上看，他们的区别很小，就是call调用时候会带有wait_for_reply=True参数，而cast不带。

要了解 rpc 的调用机制呢，首先要知道 oslo_messaging 的几个概念主要方法有四个：

transport：RPC功能的底层实现方法，这里是rabbitmq的消息队列的访问路径

transport 就是定义你如何访连接消息中间件，比如你使用的是 Rabbitmq，那在 nova.conf中应该有一行transport_url的配置，可以很清楚地看出指定了 rabbitmq 为消息中间件，并配置了连接rabbitmq的user，passwd，主机，端口。

target用来表述 RPC 服务器监听topic，server名称和server监听的exchange，是否广播fanout。

rpc server 要获取消息，需要定义target，就像一个门牌号一样。

rpc client 要发送消息，也需要有target，说明消息要发到哪去。

endpoints：是可供别人远程调用的对象

RPC服务器暴露出endpoint，每个 endpoint 包涵一系列的可被远程客户端通过 transport 调用的方法。直观理解，可以参考nova-conctor创建rpc server的代码，这边的endpoints就是 nova/manager.py:ConctorManager

dispatcher：分发器，这是 rpc server 才有的概念

只有通过它 server 端才知道接收到的rpc请求，要交给谁处理，怎么处理？

在client端，是这样指定要调用哪个方法的。

而在server端，是如何知道要执行这个方法的呢？这就是dispatcher 要干的事，它从 endpoint 里找到这个方法，然后执行，最后返回。

Serializer：在 python 对象和message(notification) 之间数据做序列化或是反序列化的基类。

主要方法有四个：

每个notification listener都和一个executor绑定，来控制收到的notification如何分配。默认情况下，使用的是blocking executor(具体特性参加executor一节）

模仿是一种很高效的学习方法，我这里根据 OpenStack 的调用方式，抽取出核心内容，写成一个简单的 demo，有对 OpenStack 感兴趣的可以了解一下，大部分人也可以直接跳过这章节。

注意以下代码不能直接运行，你还需要配置 rabbitmq 的连接方式，你可以写在配置文件中，通过 get_transport 从cfg.CONF 中读取，也可以直接将其写成url的格式做成参数，传给 get_transport 。而且还要nova或者其他openstack组件的环境中运行（因为需要有ctxt这个环境变量）

简单的 rpc client

简单的 rpc server

【End】

热 文 推 荐

☞Facebook 发币 Libra；谷歌十亿美金为穷人造房；第四代树莓派 Raspberry Pi 4 发布 | 开发者周刊

☞WebRTC 将一统实时音视频天下？

☞小米崔宝秋：小米 AIoT 深度拥抱开源

☞华为在美研发机构 Futurewei 意欲分家？

☞老司机教你如何写出没人敢维护的代码！

☞Python有哪些技术上的优点？比其他语言好在哪儿？

☞上不了北大“图灵”、清华“姚班”，AI专业还能去哪上？

☞公链史记 | 从鸿蒙初辟到万物生长的十年激荡……

☞边缘计算容器化是否有必要？

☞马云曾经偶像，终于把阿里留下的1400亿败光了！

你点的每个“在看”，我都认真当成了喜欢

⑶ 怎么用rpc查询以太坊智能合约该笔交易是否out of gas

因为区块链技术对实现智能合约存在天然的优势。比特币、瑞泰币、莱特币、以太坊等数字加密货币都使用了区块链技术。区块链（Blockchain）是比特币的一个重要概念，本质上是一个去中心化的数据库，同时作为比特币的底层技术。区块链是一串使用

⑷ rpc是什么如何处理

远程过程调用 (RPC) 是一种协议，程序可使用这种协议向网络中的另一台计算机上的程序请求服务。由于使用 RPC 的程序不必了解支持通信的网络协议的情况，因此 RPC 提高了程序的互操作性。在 RPC 中，发出请求的程序是客户程序，而提供服务的程序是服务器。 x0dx0aRPC 中处理 TCP/IP 上的消息交换的部分存在一个缺陷。错误地处理格式不正确的消息会导致出现错误。这种特定的错误会影响底层的 DCOM 接口，此接口侦听 TCP/IP 端口 135。通过发送格式不正确的 RPC 消息，攻击者可以使一台计算机上的 RPC 服务出现问题，进而使任意代码得以执行。 x0dx0a远程过程调用 (RPC) 是 Windows 操作系统使用的一个协议。RPC 提供了一种进程间通信机制，通过这一机制，在一台计算机上运行的程序可以顺畅地执行某个远程系统上的代码。该协议本身是从 OSF（开放式软件基础）RPC 协议衍生出来的，只是增加了一些 Microsoft 特定的扩展。 x0dx0ax0dx0aRPC 中处理通过 TCP/IP 的消息交换的部分有一个漏洞。此问题是由错误地处理格式不正确的消息造成的。这种特定的漏洞影响分布式组件对象模型 (DCOM) 与 RPC 间的一个接口，此接口侦听 TCP/IP 端口 135。此接口处理客户端计算机向服务器发送的 DCOM 对象激活请求（例如通用命名约定 (UNC) 路径）。 x0dx0ax0dx0a为利用此漏洞，攻击者可能需要向远程计算机上的 135 端口发送特殊格式的请求。 x0dx0ax0dx0a减轻影响的因素： x0dx0ax0dx0a为利用此漏洞，攻击者可能需要拥有向远程计算机上的 135 端口发送精心编造的请求的能力。对于 Intranet 环境，此端口通常是可以访问的；但对于通过 Internet 相连的计算机，防火墙通常会封堵 135 端口。如果没有封堵该端口，或者在 Intranet 环境中，攻击者就不需要有任何其他特权。 x0dx0ax0dx0a最佳做法是封堵所有实际上未使用的 TCP/IP 端口。因此，大多数连接到 Internet 的计算机应当封堵 135 端口。RPC over TCP 不适合在 Internet 这样存在着危险的环境中使用。像 RPC over HTTP 这样更坚实的协议适用于有潜在危险的环境。 x0dx0a这是一个缓冲区溢出漏洞。成功利用此漏洞的攻击者有可能获得对远程计算机的完全控制。这可能使攻击者能够对服务器随意执行操作，包括更改网页、重新格式化硬盘或向本地管理员组添加新的用户。 x0dx0ax0dx0a要发动此类攻击，攻击者需要能够向 RPC 服务发送一条格式不正确的消息，从而造成目标计算机受制于人，攻击者可以在它上面执行任意代码。 x0dx0ax0dx0a防范来自 Internet 的远程 RPC 攻击的最佳方法是：将防火墙配置为封堵 135 端口。RPC over TCP 不适合在 Internet 这样存在着危险的环境中使用。 x0dx0ax0dx0a此漏洞是由于 Windows RPC 服务在某些情况下不能正确检查消息输入而造成的。如果攻击者在 RPC 建立连接后发送某种类型的格式不正确的 RPC 消息，则会导致远程计算机上与 RPC 之间的基础分布式组件对象模型 (DCOM) 接口出现问题，进而使任意代码得以执行。

⑸ 什么是rpc服务器错误代码2022

rpc服务器是一种远程的调用协议，对于需要使用远程服务的用户，比如远程打印等，禁止后就会出现rpc服务器错误的提示。

rpc服务器不可用解决办法如下：

工具／原料：matebook14、windows11、rpc服务器2022。

1、【win+R】键打开【运行】，输入“services.msc”。

⑹ 以太坊event log查询与解析

从 ethereum json-rpc文档 的文档中找到一个同时指定多个事件以 OR 或者 AND 查询的方法.以下是查询 Approval 或 Transfer 事件的方法：

topics 字段中指定查询条件的语法参考上面链接。

通过 getTransactionReceipt 在ropsten测试网上查询到交易号为 的交易详情

这个交易从 "from": "" 发送到合约地址 "to": "" .这个合约为ERC20代币合约.从 topics 的第一个元素可以看出合约中产生了 Transfer 事件(topics第一个元素一定是事件的keccak哈希). topics 的第二个字段是转出代币的地址，第三个字段是接收者地址.ERC20代币 Transfer 事件的签名为

我们注意到 Transfer 事件的第一个和第二个参数被标记为 indexed , 因此他们的值被放在 topics array 中. 由于tokens参数没有标记为 indexed , 所以他的值被放在 data 字段. 如果事件中有多个字段未标记为 indexed ， 那么他们的值都会被记录在 data 字段中。

⑺ 以太坊是什么丨以太坊开发入门指南

以太坊是什么丨以太坊开发入门指南
很多同学已经跃跃欲试投入到区块链开发队伍当中来，可是又感觉无从下手，本文将基于以太坊平台，以通俗的方式介绍以太坊开发中涉及的各晦涩的概念，轻松带大家入门。
以太坊是什么
以太坊（Ethereum）是一个建立在区块链技术之上， 去中心化应用平台。它允许任何人在平台中建立和使用通过区块链技术运行的去中心化应用。
对这句话不理解的同学，姑且可以理解为以太坊是区块链里的Android，它是一个开发平台，让我们就可以像基于Android Framework一样基于区块链技术写应用。
在没有以太坊之前，写区块链应用是这样的：拷贝一份比特币代码，然后去改底层代码如加密算法，共识机制，网络协议等等（很多山寨币就是这样，改改就出来一个新币）。
以太坊平台对底层区块链技术进行了封装，让区块链应用开发者可以直接基于以太坊平台进行开发，开发者只要专注于应用本身的开发，从而大大降低了难度。
目前围绕以太坊已经形成了一个较为完善的开发生态圈：有社区的支持，有很多开发框架、工具可以选择。
智能合约
什么是智能合约
以太坊上的程序称之为智能合约， 它是代码和数据(状态)的集合。
智能合约可以理解为在区块链上可以自动执行的（由事件驱动的）、以代码形式编写的合同（特殊的交易）。
在比特币脚本中，我们讲到过比特币的交易是可以编程的，但是比特币脚本有很多的限制，能够编写的程序也有限，而以太坊则更加完备（在计算机科学术语中，称它为是“图灵完备的”），让我们就像使用任何高级语言一样来编写几乎可以做任何事情的程序（智能合约）。
智能合约非常适合对信任、安全和持久性要求较高的应用场景，比如：数字货币、数字资产、投票、保险、金融应用、预测市场、产权所有权管理、物联网、点对点交易等等。
目前除数字货币之外，真正落地的应用还不多（就像移动平台刚开始出来一样），相信1到3年内，各种杀手级会慢慢出现。
编程语言：Solidity
智能合约的默认的编程语言是Solidity，文件扩展名以.sol结尾。
Solidity是和JavaScript相似的语言，用它来开发合约并编译成以太坊虚拟机字节代码。
还有长像Python的智能合约开发语言：Serpent，不过建议大家还是使用Solidity。
Browser-Solidity是一个浏览器的Solidity IDE, 大家可以点进去看看，以后我们更多文章介绍Solidity这个语言。
运行环境：EVM
EVM（Ethereum Virtual Machine）以太坊虚拟机是以太坊中智能合约的运行环境。
Solidity之于EVM，就像之于跟JVM的关系一样，这样大家就容易理解了。
以太坊虚拟机是一个隔离的环境，在EVM内部运行的代码不能跟外部有联系。
而EVM运行在以太坊节点上，当我们把合约部署到以太坊网络上之后，合约就可以在以太坊网络中运行了。
合约的编译
以太坊虚拟机上运行的是合约的字节码形式，需要我们在部署之前先对合约进行编译，可以选择Browser-Solidity Web IDE或solc编译器。
合约的部署
在以太坊上开发应用时，常常要使用到以太坊客户端（钱包）。平时我们在开发中，一般不接触到客户端或钱包的概念，它是什么呢？
以太坊客户端（钱包）
以太坊客户端，其实我们可以把它理解为一个开发者工具，它提供账户管理、挖矿、转账、智能合约的部署和执行等等功能。
EVM是由以太坊客户端提供的。
Geth是典型的开发以太坊时使用的客户端，基于Go语言开发。 Geth提供了一个交互式命令控制台，通过命令控制台中包含了以太坊的各种功能（API）。Geth的使用我们之后会有文章介绍，这里大家先有个概念。
Geth控制台和Chrome浏览器开发者工具里的面的控制台是类似，不过是跑在终端里。
相对于Geth，Mist则是图形化操作界面的以太坊客户端。
如何部署
智能合约的部署是指把合约字节码发布到区块链上，并使用一个特定的地址来标示这个合约，这个地址称为合约账户。
以太坊中有两类账户：
· 外部账户
该类账户被私钥控制（由人控制），没有关联任何代码。
· 合约账户
该类账户被它们的合约代码控制且有代码与之关联。
和比特币使用UTXO的设计不一样，以太坊使用更为简单的账户概念。
两类账户对于EVM来说是一样的。
外部账户与合约账户的区别和关系是这样的：一个外部账户可以通过创建和用自己的私钥来对交易进行签名，来发送消息给另一个外部账户或合约账户。
在两个外部账户之间传送消息是价值转移的过程。但从外部账户到合约账户的消息会激活合约账户的代码，允许它执行各种动作（比如转移代币，写入内部存储，挖出一个新代币，执行一些运算，创建一个新的合约等等）。
只有当外部账户发出指令时，合同账户才会执行相应的操作。
合约部署就是将编译好的合约字节码通过外部账号发送交易的形式部署到以太坊区块链上（由实际矿工出块之后，才真正部署成功）。
运行
合约部署之后，当需要调用这个智能合约的方法时只需要向这个合约账户发送消息（交易）即可，通过消息触发后智能合约的代码就会在EVM中执行了。
Gas
和云计算相似，占用区块链的资源（不管是简单的转账交易，还是合约的部署和执行）同样需要付出相应的费用（天下没有免费的午餐对不对!）。
以太坊上用Gas机制来计费，Gas也可以认为是一个工作量单位，智能合约越复杂（计算步骤的数量和类型，占用的内存等），用来完成运行就需要越多Gas。
任何特定的合约所需的运行合约的Gas数量是固定的，由合约的复杂度决定。
而Gas价格由运行合约的人在提交运行合约请求的时候规定，以确定他愿意为这次交易愿意付出的费用：Gas价格（用以太币计价） * Gas数量。
Gas的目的是限制执行交易所需的工作量，同时为执行支付费用。当EVM执行交易时，Gas将按照特定规则被逐渐消耗，无论执行到什么位置，一旦Gas被耗尽，将会触发异常。当前调用帧所做的所有状态修改都将被回滚， 如果执行结束还有Gas剩余，这些Gas将被返还给发送账户。
如果没有这个限制，就会有人写出无法停止（如：死循环）的合约来阻塞网络。
因此实际上（把前面的内容串起来），我们需要一个有以太币余额的外部账户，来发起一个交易（普通交易或部署、运行一个合约），运行时，矿工收取相应的工作量费用。
以太坊网络
有些着急的同学要问了，没有以太币，要怎么进行智能合约的开发？可以选择以下方式：
选择以太坊官网测试网络Testnet
测试网络中，我们可以很容易获得免费的以太币，缺点是需要发很长时间初始化节点。
使用私有链
创建自己的以太币私有测试网络，通常也称为私有链，我们可以用它来作为一个测试环境来开发、调试和测试智能合约。
通过上面提到的Geth很容易就可以创建一个属于自己的测试网络，以太币想挖多少挖多少，也免去了同步正式网络的整个区块链数据。
使用开发者网络(模式)
相比私有链，开发者网络(模式)下，会自动分配一个有大量余额的开发者账户给我们使用。
使用模拟环境
另一个创建测试网络的方法是使用testrpc，testrpc是在本地使用内存模拟的一个以太坊环境，对于开发调试来说，更方便快捷。而且testrpc可以在启动时帮我们创建10个存有资金的测试账户。
进行合约开发时，可以在testrpc中测试通过后，再部署到Geth节点中去。
更新：testrpc 现在已经并入到Truffle 开发框架中，现在名字是Ganache CLI。
Dapp：去中心化的应用程序
以太坊社区把基于智能合约的应用称为去中心化的应用程序(DecentralizedApp)。如果我们把区块链理解为一个不可篡改的数据库，智能合约理解为和数据库打交道的程序，那就很容易理解Dapp了，一个Dapp不单单有智能合约，比如还需要有一个友好的用户界面和其他的东西。
Truffle
Truffle是Dapp开发框架，他可以帮我们处理掉大量无关紧要的小事情，让我们可以迅速开始写代码-编译-部署-测试-打包DApp这个流程。
总结
我们现在来总结一下，以太坊是平台，它让我们方便的使用区块链技术开发去中心化的应用，在这个应用中，使用Solidity来编写和区块链交互的智能合约，合约编写好后之后，我们需要用以太坊客户端用一个有余额的账户去部署及运行合约（使用Truffle框架可以更好的帮助我们做这些事情了）。为了开发方便，我们可以用Geth或testrpc来搭建一个测试网络。
注：本文中为了方便大家理解，对一些概念做了类比，有些严格来不是准确，不过我也认为对于初学者，也没有必要把每一个概念掌握的很细致和准确，学习是一个逐步深入的过程，很多时候我们会发现，过一段后，我们会对同一个东西有不一样的理解。

⑻ 一文读懂以太坊—ETH2.0，是否值得长期持有

这几天一直在看关于ETH伦敦升级方面的资料，简单的聊一下，在加密货币的世界里，无论是投资机构、区块链应用开发者、矿机商，还是个人投资者、硬件供应商、 游戏 行业从业者等等，提起以太坊，或多或少都会有一些了解。

一方面取决于以太坊代币 ETH 本身的造富效应。从 2014 年首次发行以来，投资回报率已经超过 7400 倍。

另一方面，以太坊作为应用最广泛的去中心应用编程平台，引来无数开发者在其之上开发应用。这些应用不仅产生了巨大的商业价值，伴随 DEFI 生态、NFT 生态、DAO 生态蓬勃发展，也给 ETH 带来了更多使用者。

随着“伦敦升级计划”临近，ETH 再次聚集所有人的关注目光。

以太坊 2.0 到底是什么？包含哪些升级？目前进展如何？

以太坊 2.0 到来，会对现有以太坊生态的去中心化应用产生哪些影响？

ETH 是否值得持续投资？看完相信你会有自己的判断。

如果将搭建应用比作造房子，那么以太坊就提供了墙面、屋顶、地板等模块，用户只需像搭积木一样把房子搭起来，因此在以太坊上建立应用的成本和速度都大大改善。以太坊的出现，迅速吸引了大量开发者进入以太坊的世界编写出各类去中心应用，极大丰富人们对去中心应用场景的需求。

以太坊应用开发模型示意

以太坊与ETH

现有市场的加密货币，只是在区块链技术应用在某一场景下的单一代币。

以太坊也不例外，它的完整项目名称是“下一代智能合约与去中心化应用平台”，Ether（以太币）是其原生加密货币，简称 ETH。

ETH 除了可以用来与各种类型数字资产之间进行有效交换，还提供支付交易费用的机制，即我们现在做链上操作时所支付的 GAS 费用。GAS 费用机制的出现，即保护了以太坊网络上创建的应用不会被恶意程序随意滥用，又因为 GAS 收入归矿工所有，让更多的用户参与到以太坊网络的记账当中成为矿工，进一步维护了以太坊网络安全与生态发展。

与 BTC 不同的是，ETH 并没有采用 SHA256 挖矿算法，避免了整个挖矿生态出现由 ASIC（专用集成电路）矿机主导以至于大部分算力被中心化机构控制所带来的系统性风险。

以太坊最初采用的是 PoW（Proof of Work）的工作量证明机制，人们需要通过工作量证明以获取手续费回报。我们经常听说矿工使用显卡挖矿，他们做的就是 POW 工作量证明。显卡越多，算力越大，那么工作量就越大，收入也就越高。

当前，整个以太坊网络的总算力大约为 870.26 TH/s，用我们熟悉的消费级显卡来对比，英伟达 RTX 3080 的显卡算力大约为 92-93 MH/s，以太坊网络相当于 936 万张 3080 显卡算力的总和。

以太坊白皮书内非常明确提到之后会将 PoW 工作证明的账本机制升级为 POS （Proof of Stake）权益证明的账本机制。

ETH经济模型

与 BTC 总量 2100 万枚不同，ETH 的总量并没有做上限，而是在首次预售的 ETH 数量基础上每年增发，增发数量为 0.26x（x 为发售总量）。

但也不用担心 ETH 会无限通胀下去，长期来看，每年增发币的数量与每年因死亡或者粗心原因遗失币的数量大致相同，ETH 的“货币供应增长率”是趋近于零的。

ETH 分配模型包含早期购买者，早期贡献值，长期捐赠与矿工收益，具体分配比例如下表。

现在每年将有 60,102,216 * 0.26 = 15,626,576 个 ETH 被矿工挖出，转成 PoS 后，每年产出的 ETH 将减少。

目前，市场上流通的 ETH 总量约为 116,898,848 枚，总市值约为 2759 亿美元。

以太坊发展历程

1. 边境阶段（2015年）：上线后不久进行了第一次分叉，调整未来挖矿的难度。此版本处于实验阶段，技术并未成熟，最初只能让少部分开发者参与挖矿，智能合约也仅面向开发者开发应用使用，并没有用户参与，以太坊网络处于萌芽期。

边境阶段 ETH 价格：1.24 美元。

2. 家园阶段（2016年）：以太坊主网于 2016 年 3 月进行了第二次分叉，发布了第一个稳定版本。此版本是第一个成熟的正式版本，采用 100% PoW 证明，引入难度炸弹，随着区块链数量的增加，挖矿难度呈指数增长，网络的性能大幅提升，以太坊项目也进入到快速成长期。在”家园“版本里，还发生了著名的”The DAO 攻击事件“，以太坊被社区投票硬分叉为以太坊（ETH）与以太经典（ETC）两条链，V 神站在了 ETH 这边。

家园阶段 ETH 价格：12.50 美元。

3. 都会阶段（2017~2019年）：都会的开发又分为三个阶段，升级分成了三次分叉，分别是 2017 年 10 月的“拜占庭”、2019 年 2 月底的“君士坦丁堡“、以及 2019 年 12 月的“伊斯坦布尔”。这些升级主要改善智能合约的编写、提高安全性、加入难度炸弹以及一些核心架构的修改，以协助未来从工作量证明转至权益证明。

在都会阶段，以太坊网络正式显现出其威力，正式进入成熟期。智能合约让不同链上的加密货币可以互相交易，ERC-20 也在 2017 代币发行的标准，成千上万个项目在以太坊网络进行募资，被称作“首次代币发行（ICO）”，相信很多币圈的老人都是被当时 ICO 造富效应带进来的。到 2019 年，随着DeFi 生态的崛起，金融产品正式成为以太链上最大的产业。

都会阶段 ETH 价格：151.06 美元。

4. 宁静阶段（2020-2023年）：与都会分三阶段开发相同，宁静阶段目前预计分成三次分叉：柏林（已完成）、伦敦（即将到来）、以及后面的第三次分叉。“宁静”阶段又称为“以太坊 2.0”，是项目的最终阶段，以太坊将从工作量证明方式正式转向权益证明，并开发第二层扩容方案，提高整个网络的运行效率。

宁静阶段可以说是以太坊网络的集大成之作，如果说前个三阶段只是让以太坊的愿景展现的实验平台，宁静阶段之后的以太坊，将正式成为完全体，不仅有完备的生态应用，超级快的处理速度，众多网络协同发展，而且 PoS 机制会非常节约能源，真正代表了区块链技术逐渐走向成熟的标志。

宁静阶段 ETH 价格：2021 年 4 月 15 日完成的柏林阶段，当天价格为 2454 美元。

即将到来的伦敦协议升级

以太坊生态

以太坊的生态发展，从属性划可分为两大类：一是以太坊网络生态应用建设，二是以太坊网络扩容建设。两者相互融合，互相成就，应用需要更健壮强大的网络作为承载，网络需要功能完善的应用场景服务用户。

先说应用生态，以太坊的生态我们又可以分为以下几大类：

1. 去中心化自制组织（DAO）生态

什么是去中心化自制组织？还是以我们熟悉的比特币举例：比特币目前市值七千多亿美金，在全球资产市值类排名第九，但比特币并不是某一公司发布的产品，也没有特定公司组织招聘人员进行维护。比特币现有的一切，都源于比特币持有者、比特币矿工自发形成的分布式组织，他们通过投票方式规划比特币发展路线，自发参与维护比特币程序与网络 —这仅仅因为只要拥有比特币，所有人都是比特币网络建设中的受益者，一切维护都源于自身的利益关系。

比特币的发明与成功运行，突破了由荷兰人创建、至今流行 400 多年的公司商业架构，开创出一种全新的、无组织架构的、全球分布式的商业模式，这就是 DAO。

再说回以太坊，以太坊的 DAO 可以由智能合约编写，用户自定义应用场景。简单说就是我们规定出程序执行条件与执行范围，真实世界里只要触发设定好的条件，程序就会自动执行运行，且所有过程都会在以太坊的网络上进行去中心化公开验证，不需要经过人工或者任何第三方组织机构确认。

以太坊 DAO 生态演化出许多商业场景，有慈善机构使用 DAO 建立公开透明的捐款与使用机制，有风投机构使用 DAO 建立公平分配的风险基金。

以太坊生态的很多项目都采用 DAO 自治，代表项目有：Uniswap，AAVE，MakerDAO，Compound，Decred，Dash 等。

2. 去中心化金融（DEFI）生态

在传统商业世界里，我们如果需要借钱、存钱，或者买某一公司股票，或者做企业贷款、融资，只要是进行金融活动，总离不开与银行、证券机构、会计事务所这些金融机构打交道。

而在去中心的世界里，区块链本质就是集合所有人交易记录且公开的大账本，我们可以非常容易的追溯到每一个钱包地址发生过的每一笔交易，查询到任意一个钱包地址的余额信息，从而对钱包地址里的资产做评估。

举个例子：全世界个人贷款最贵的国家是印度，印度的年轻人房贷利率目前是 8.8%，最高曾经到过 20%；与此对应，全世界个人存款利率最低的国家是日本，日本政府为了鼓励民众消费，在很长一段时间里银行存款利率是负值，日本人在银行存款不仅没有利息，还要给银行交保管费。理论上，如果日本人将自己的存款借与印度人，双方都能获得利益最大化，但现实生活中这样的场景很难发生。一是每个国家都有外汇管制，日本人的钱并不容易能给到印度人，二是印度人的信用如何日本人也不好评估，大家没有统一标准，万一借出去的钱无法归还，不能没了收益还要蒙受损失。

但在去中心的世界里，这样的事情就简单的多。

如果印度人的钱包地址里有比特币，我们就可以利用智能合约，印度人将自己的比特币质押进去，根据比特币当时的价格，系统自动给印度人一个授信额度，印度人就可以拿着这个额度去和日本人借款，并规定好还款的周期与利率。如果印度人违约，合约自动将印度人质押进去的比特币扣除，优先保障日本的权利，这样，日本人不用担心安全问题放心享受收益，印度人也有了更多的款项做为流动资金。

这个例子就是去中心金融的简单应用，实际上，这就是我们参与 DEFI 挖矿是质押理财的原理 —— 当然真正应用实现算法与场景要复杂的多。

DEFI 根据场景不同，又可以分为很多赛道，比如稳定币、预言机、AMM 交易所、衍生品、聚合器等等。

DEFI 代表项目有：Dai，Augur，Chainlink，WBTC，0x，Balance，Liquity 等。

3. 非同质化代币（NFT）生态

世界名画《蒙娜丽莎》，只有达·芬奇的原版可以展览在法国卢浮宫博物馆，哪怕现代的技术可以无比精细地复刻出来，仿品都不具备原版的收藏价值。

这就是 NFT 的应用场景。NFT是我们可以用来表示独特物品所有权的代币，它们让我们将艺术品、收藏品甚至房地产等现实事物唯一代币化。虽然文件（作品）本身是可以无限复制，但代表它们的代币在链上可以被追踪，并为买家提供所有权证明。

相比现实中实物版权、物权的双重交割相比，NFT 只需要交割描述此物品的唯一代币。NFT 作品往往存储在如 IPFS 这样的分布式存储网络里，随用随取，永不丢失，加之交割简单方便，很快吸引了大量玩家与投资者收藏转卖，NFT 出现也给艺术家提供了全新的收入模式。

类似 DEFI 生态，NFT 生态根据应用场景不同也产生了不同赛道，目前比较火热的赛道有 NFT 交易平台，NFT 游戏 平台，NFT 艺术品平台， NFT 与 DEFI 结合在一起的金融平台。

NFT 代表项目有：CryptoKitties，CryptoPunks，Meebits，Opensea，Rally，Axie Infinity，Enjin Coin，The Sandbox 等。

4. 标准代币协议（ERC-20）生态

与 NFT 非同质化代币所对应的，就是同质化代币。比如我们使用的人民币就是一种同质化代币，我们可以用人民币进行价值交换，即使序号不同也不影响其价值，如果面额相同，不同的钞票序号对持有者来说没有区别。

BTC，ETH 和所有我们熟知的加密货币，都属于同质化代币。同种类的一个比特币和另一个比特币没有任何区别，规格相同，具有统一性。在交易中，只需关注代币交接的数量即可，其价值可能会根据交换的时间间隔而改变，但其本质并没有发生变化。

以太坊的 ERC-20 就是定义这种代币的标准协议，任何人都可以使用 ERC-20 协议，通过几行代码，发布自己在以太坊网络上的加密货币。

现在，以太坊网络上运行的代币种类有上百万个，上边提到的项目，大多也在以太坊网络中发布了自己的同质化代币。

ERC-20 代表项目有：USDT，USDC，WBTC 等。

以太坊网络扩容性

我们先引入一个概念：区块链的不可能三角，即无论何种方法，我们都无法同时达到可扩展、去中心化、安全，三者只能得其二。

这其实很好理解，如果我们要去中心化和安全，就需要更多有节点参与网络进行验证，从而导致验证人增多、网络效率降低，扩展性下降。网络性能建设就是在三者之间找到平衡点。

用数据举例，目前比特币可处理转账 7 笔 / 秒，以太坊是 25 笔 / 秒，而 VISA 平均为 4500 笔 / 秒，峰值则达每秒上万笔。这种业务处理能力的差别，我们就可以简单理解为是「吞吐量」的差距。而想要提高吞吐量，则需要扩展区块链的业务处理能力，这就是所谓的扩展性。

根据优化方法不同，以太坊网络性能扩容方案可以分为：

1. Layer 1 链上扩展，所有交易都保留在以太坊上的扩展解决方案，具有更高的安全性。

链上扩展的本质还是改进以太坊主链本身，使整个系统拥有更高的拓展性与运行效率。一般的方法有两种，要么改变共识协议，比如 ETH 将从 PoW 转变为 PoS；要么使用分片技术，优化方法使网络具有更高效率。

2. Layer 2 链下扩展，在以太坊协议之上分层单独做各场景解决方案，具有更好的扩展性。

链下扩展可以理解为把计算、交易等业务处理场景拿到以太坊主链之外计算，最后将计算好的结果传回主链，主链只反映最终的结果而不用管过程，这样，无论多么复杂的应用都不会对主链产生影响。

我们并不需要明白具体技术实现，只需知道：相比 Layer 1 方案，Layer 2 方案网络不会干扰底层区块链协议，可以替 Layer 1 承担大部分计算工作，从而降低主网络的负担提高网络业务处理效率，是目前公认比较好的扩容方案。

以太坊2.0

终于讲到以太坊 2.0，回到主题。

通过回顾以太坊的发展 历史 ，以太坊 2.0 并不是新项目，它只是以太坊开发进程的最后一个阶段，它将由整个以太坊生态多个团队协同完成，目标是使以太坊更具可扩展性、更安全和更可持续，最终成为主流并为全人类服务。

ETH2建设目标:

1. 更具可扩展性。每秒支持 1000 次交易，以使应用程序使用起来更快、更便宜。

2. 更安全。以太坊变得更加安全，以抵御所有形式的攻击。

3. 更可持续。提高网络性能的同时减少对能源的消耗，更好地保护环境。

最重要的变化，ETH2 将从 ETH1 使用的 PoW（Proof of Work）工作量证明机制升级为 POS （Proof of Stake）权益证明机制。不再以算力做为验证方式，而是通过质押加密货币的数量做为验证手段。矿工不需要显卡也能挖矿，既节省了时间成本与电力成本，又提高了 ETH 的利用率，非常类似钱存在银行获得利息。

ETH2 主要使用的技术是分片分层技术实现整个网络扩容。

ETH2 升级将分为三个阶段进行：

1. 阶段0（正在进行）：信标链的创建与合并。信标链是 ETH2 的主链，如同人类的大脑，是 ETH2 得以运行的基础。

2. 阶段1（预计2022年）：分片链的创建与应用。当信标链与 ETH1 合并完成后，就进入分片链的开发阶段。分片链可以理解为将 ETH2 主链的整块数据按一定规则拆分存放，单独建立新链处理，用来分担主链上的数据压力，目前规划是建立 64 条分片链。

举个例子，从北京到上海，原来的交通工具只有一条公路，所有的车辆都需要在上边运行，就会非常拥挤；现在通过分片技术，多出来高铁、飞机等交通方式，分流的车辆同时到达速度更快，这就是分片链起到的作用。

分片链与主链交互示意图

3. 阶段2（预计2023年）：整个网络功能的融合。到了此阶段，整个系统的功能全面开始融合，分片链的功能会更加强大，新的处理机制开始支持账户、智能合约、开发工具的创建，新的生态应用等。

此阶段是以太坊网络的最终形态，网络性能得到全面提升，生态应用全面爆发。但要服务全人类，ETH2 每秒 1000 次的交易效率显然还是远远不够，以太坊也会为它的目标持续优化下去。

ETH2对于大家有什么影响？

1. 对于以太坊生态开发者。ETH2 在部署应用的时候，是需要选择应用在哪条分片网络进行部署，造成这种差异的原因是跨分片通信不同步，这就意味着开发者需要根据自己发展计划做不同的组合。

2. 对与 ETH 持币者。ETH2 与 ETH1 数据完全同步，代币也不会有任何变化，你可以继续使用现在的钱包地址继续持有 ETH。

3. 对于矿工。虽然 PoW 与 PoS 还会并行一段时间，可以预计的 PoW 矿机的产出会越来越少，应该开始减少 PoW 矿机的投资，开始转向 PoS 机制。

4. 对于用户。ETH2 速度更快，交易手续费更低，网络体验会非常好，唯一值得注意的是，由于 Dapp 部署在不同的分片网络上，可能需要手动选择应用的网络选项。

ETH是否值得投资？

ETH 是除了 BTC 以外市场的风向标，明确了解 ETH2 非常有助于我们理解其他区块链项目，理解二级市场。

简单总结几个点吧：

1. 通过以太坊的项目分析，我们可以清晰地看到：在比特币之后，以太坊项目的发展史就是目前区块链应用生态的发展史。无论 DEFI 生态，NFT 生态，DAO 生态还是代币、合约、协议生态，其实在以太坊发布白皮书时已有预见，后来出现的项目，都是围绕以太坊做验证。

2. 以太坊的联合创始人里，只有 V 神还在为以太坊事业做贡献，但这并不影响以以太坊繁荣发展。以太坊初始团队只是创建了它，后续的发展是社区、开发者、矿工与用户共同建立的结果，现在的以太坊早已不是某一个人的思维，它是所有以太坊生态参与者共同的结晶，它属于全人类。

3. 以太坊在过去的几年一直沿着既定的开发轨迹发展，虽然中途一度出现过危机，以太坊“被死亡”了好几百次，以太坊还是顽强的发展下来，并且拥有了繁荣生态。ETH2 还要两三年时间才能落地，中间也充满变数，比如其他的公链抢占先机，但可以预见，ETH2 后的以太坊会更加健壮。

4. 不要在抱有任何 BTC 会死亡，区块链行业会消失这样的伪命题。BTC、ETH 让我们看到了突破原有公司组织架构，一种全新无组织架构的商业模式存在，这种商业模式显然更符合这个时代的发展需求，无论项目地发起团队在不在，无论各国政府如何打压，只要技术对人类有贡献，就会由人员自发组织维护，区块链技术是革命。

5. ETH2 的上线，短期看 PoW 奖励与 PoS 奖励并行，可能会让 ETH 总通胀率短期内飙升，长期看 ETH 通胀率始终保持平衡。加上 ETH 本身的生态与应用场景，ETH是值得投资的，目前看不到有其他公链代替以太坊公链的可能性，ETH2 的上线，甚至会对其他公链造成“虹吸效应”，万链归一。

#比特币[超话]# #数字货币#

⑼ 以太坊架构是怎么样的

以太坊最上层的是DApp。它通过Web3.js和智能合约层进行交换。所有的智能合约都运行在EVM（以太坊虚拟机）上，并会用到RPC的调用。在EVM和RPC下面是以太坊的四大核心内容，包括：blockChain, 共识算法，挖矿以及网络层。除了DApp外，其他的所有部分都在以太坊的客户端里，目前最流行的以太坊客户端就是Geth（Go-Ethereum）

⑽ 以太坊如何使用web3.js或者rpc接口获取交易数据交易时间与确认数

如果要查询主网上的交易记录，可以使用etherscan。但是，如果是你自己搭建的私链，应该如何查询交易记录呢？

答案是你需要自己监听链上的日志，存到数据库里，然后在这个数据库中查询。例如：

varaddr=""
varfilter=web3.eth.filter({fromBlock:0,toBlock:'latest',address:addr});
filter.get(function(err,transactions){
transactions.forEach(function(tx){
vartxInfo=web3.eth.getTransaction(tx.transactionHash);
//这时可以将交易信息txInfo存入数据库
});
});

web3.eth.filter()用来监听链上的日志，web3.eth.getTransaction()用来提取指定交易的信息，一旦获得交易信息，就可以存入数据库供查询用了。

推荐一个实战入门，你可以看看：以太坊教程