以太坊代碼解析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()用來提取指定交易的信息，一旦獲得交易信息，就可以存入資料庫供查詢用了。

推薦一個實戰入門，你可以看看：以太坊教程