ETH トランクインターフェイス

ETHリレーが提供できる機能

1. 接受其他服务端脸上的相关服务请求，中继处理请求业务，将处理后的响应返回给用户。如查询余额等
2. 发起交易的功能，包括ETH转账和ERC20转账
3. 用户的钱包创建
4. 对链上区块相关事件的监听，目前可以实现的监听事件包括但不限于如下：
	a. ERC20 Token的授权Approve事件
	b. Token转账Transfer的结果事件
	c. WETH Token置换ETH事件
	d. 新区块生成事件
	e. 遍历一个区块事件
	f. 区块分查事件

ここに画像の説明を挿入

ブロックトラバーサル

リレー開発において、イベント監視は最も難しい開発です。
イベント監視の技術的原理は、主にブロック内のトランザクション情報を取得し、トランザクション情報内の「EventLog」(ログイベント) を解析することによって目的を達成することです。
現在、ETH はブロックイベント監視機能を備えた web.js ライブラリを提供していますが、完全ではなく、次のような欠点があります。

クライアントのプロセスが強制終了されると、監視アクションが失われます
最後に正常にトラバースされたブロックのブロック番号が保存されている場合、その期間内に新しく生成されたブロックのデータは、再起動時に失われます。
完全な監視プロセスは、クライアント側でデバイスリソースを消費し、ユーザーエクスペリエンスに影響を与えます

監視する理由
集中型取引所は、現金の再チャージや引き出しなどのことを行う必要があり、すべてチェーン上のデータを監視する必要があります. チェーン上の転送が成功した後、集中型サーバーのデータベースを変更します. 監視されていない場合は、現金引き出しの条件、チェーン上の取引が失敗した場合、中央集権化におけるユーザーの価値が低下すると、問題が発生します。

ETH メカニズムでは、チェーン上の承認、トランザクション、および契約リリースなどのイベントはすべてトランザクション情報であり、各トランザクション情報は抽出され、さまざまな機能とビジネスに分割できます。

RPC インターフェイス (リモートプロセスコール、リモートプロシージャコール)

ここに画像の説明を挿入

通信プロトコルに基づいて RPC インターフェイスを実装する方法は多数ありますが、主に次の 2 つの方法があります。

「RESTful API」と同様、アプリケーション層のHTTP/HTTPSプロトコルをベースに実装
トランスポート層に基づく TCP プロトコルの実装。Socket (ネストされた単語) の実装とも呼ばれます。

2 つの方法の違いは、要求と応答の場所にあります。1 つはアプリケーション層にあり、もう 1 つはトランスポート層にあります。
RPC インターフェースと「RESTful API」インターフェースは HTTP/HTTPS プロトコルで実装されており、速度にほとんど違いはありませんが、トランスポート層の
TCP プロトコルに基づいて実装されている RPC インターフェースは、データ転送のレベルを除いて異なります。 stream, is less than the "RESTful" interface. それよりも高速であることに加えて、送信中の全体的なデータグラムレベルは、HTTP/HTTPS ヘッダーデータの量とアセンブリの時間消費も削減します。つまり、RPCインターフェースがトランスポート層のTCPプロトコルに基づいて実装されている場合、RPCインターフェースは「RESTful」インターフェースよりもリクエストと応答が高速であるだけでなく、データ量も比較的少なくなります。

一般的な RPC フレームワークは次のとおりです。

JSON-RPC
XML-RPC
Protobuf-RPC
SOAP-RPC

つまり、RPC プロトコルは、クライアントと RPC インターフェースを実装するサーバーとの間の対話のためのデータ形式を標準化することです。

RPC インターフェイス実装の一般的な流れ:

サービス呼び出しスキームは、標準化されたエンコード方法に従って、RPC インターフェイスの関数とパラメーターをシリアル化し、エンコードします。
サービスのプロバイダー、つまりサーバーに送信されます
サーバー側は、逆シリアル化後に対応するパラメーターを抽出します
次に、関連する関数を呼び出して
最後に、結果はサーバー側の呼び出し元に返されます

ETH RPC インターフェイスに付随する 3 つの重要なパラメーター

ETH RPC インターフェイスを理解する前に、まず 3 つのパラメーターを理解してください。これらの 3 つのパラメーターは各インターフェイスに表示されるためです。

初期のソースコードバージョンで最も古いものに相当する最も古いものを表すジェネシス
保留中、待機中または保留中の状態を表します
latest は、最後に完了したものを表します

ETH RPC インターフェイス

1.eth_blockNumber

このインターフェイスは、渡されたパラメーター (ジェネシス、保留中、最新) に従って 3 種類のブロックの高さを取得できます。

ジェネシスブロックを表すジェネシスは、最も早いブロック番号を指定できるため、ジェネシスブロックが必ずしも0であるとは限りません
保留中は、現在マイナーによってマイニングされているブロックを表し、トランザクション用にパッケージ化されているブロックを表します. 特定のトランザクションがパッケージ化されるまで、ブロックはチェーンに完全にアップロードされません.
latest、現在のチェーンで生成された最新のブロックの高さ

2.eth_getBlockByNumber

ブロックの高さに応じてブロックの一部の情報を取得するインタフェースで、主にブロックを横断する際にブロックのデータ情報を取得するために使用されるインタフェースです。このインターフェイスは、次のデータを提供できます。

ブロックヘッダーの部分フィールド
このブロックにパッケージ化されたすべてのトランザクションハッシュ配列

つまり、返されるデータの構造は Block です。つまり、この構造に含まれる情報を取得できます。

// Block表示以太坊区块链中的一个完整的区块。
type Block struct {
    
    
	// block的header指向的是一个的结构体，其中带有该block的所有属性信息
	header       *Header
	// 叔块block的数组
	uncles       []*Header
	// 当前该区块所有打包的交易记录
	transactions Transactions
	// 缓存，应该是该区块的的hash及区块大小
	hash atomic.Value
	size atomic.Value

	// total difficulty，当前区块总共的难度值=前一个区块的td+当前区块header中的difficulty。
	td *big.Int
	// 区块被接受的时间
	ReceivedAt   time.Time
	// 记录区块是从哪个P2P网络传过来的
	ReceivedFrom interface{
    
    }
}

3.eth_getTransactionByHash

このインターフェースは、取引記録のハッシュ値に基づいて、取引の詳細情報を取得できます。
このインターフェースは、トランザクションクエリ機能を提供し、トランザクションブロック情報を取得した後、ブロック情報からパッケージ化されたトランザクションのハッシュ値を取得し、すべてのトランザクション情報を抽出します。保留中 (待機中または保留中) のトランザクションは空を返します. このインターフェースの機能に基づいて、トランザクションが成功したかどうかを判断することもできます.
データを取得するための構造は Transaction です。

// Transaction is an Ethereum transaction.
type Transaction struct {
    
    
	inner TxData    // Consensus contents of a transaction
	time  time.Time // Time first seen locally (spam avoidance)

	// caches
	hash atomic.Value
	size atomic.Value
	from atomic.Value
}

// TxData is the underlying data of a transaction.
//
// This is implemented by DynamicFeeTx, LegacyTx and AccessListTx.
type TxData interface {
    
    
	txType() byte // returns the type ID
	copy() TxData // creates a deep copy and initializes all fields

	chainID() *big.Int
	accessList() AccessList
	data() []byte
	gas() uint64
	gasPrice() *big.Int
	gasTipCap() *big.Int
	gasFeeCap() *big.Int
	value() *big.Int
	nonce() uint64
	to() *common.Address

	rawSignatureValues() (v, r, s *big.Int)
	setSignatureValues(chainID, v, r, s *big.Int)
}

4.eth_getTransactionReceipt

このインターフェースは、トランザクションのハッシュ値に従って、トランザクションの受領情報を取得できます。
このインターフェイスによって返されるデータは、ある程度 eth_TransactionByHash と同じですが、このインターフェイスによって返されるデータは、イベント監視の主要なデータソースでもあるトランザクションログなど、より詳細です。eth_getTransactionByHash と同様に、保留状態のトランザクションは空を返します。返される構造は Receipt です

// Receipt represents the results of a transaction.
type Receipt struct {
    
    
	// Consensus fields: These fields are defined by the Yellow Paper
	Type      uint8  `json:"type,omitempty"`
	PostState []byte `json:"root"`
	// 当这笔交易是成功的，该值为true，即 1 ，否则为 false
	Status    uint64 `json:"status"`
	// 该字段和GasUsed不一样，它所代表的是当前的交易 所在区块的列表中，
	// 当前TransactionIndex之上的包含的其他所有交易的Gas之和。
	// 例如，TransactionIndex = 4，
	// 那么它的CumulativeGasUsed数值就是下标为 01234的交易的GasUsed数值之和
	CumulativeGasUsed uint64 `json:"cumulativeGasUsed" gencodec:"required"`
	Bloom             Bloom  `json:"logsBloom"         gencodec:"required"`
	// 由当前交易生成的事件(Event)日志
	Logs              []*Log `json:"logs"              gencodec:"required"`

	// Implementation fields: These fields are added by geth when processing a transaction.
	// They are stored in the chain database.
	TxHash common.Hash `json:"transactionHash" gencodec:"required"`
	// 合约地址，只有在当前交易是合约创建的情况才会有值
	// 对应的是新创建合约的ETH地址，其他情况为空
	ContractAddress common.Address `json:"contractAddress"`
	GasUsed         uint64         `json:"gasUsed" gencodec:"required"`

	// Inclusion information: These fields provide information about the inclusion of the
	// transaction corresponding to this receipt.
	BlockHash        common.Hash `json:"blockHash,omitempty"`
	BlockNumber      *big.Int    `json:"blockNumber,omitempty"`
	TransactionIndex uint        `json:"transactionIndex"`
}

5.eth_getBalance

このインターフェイスは、ETH アドレスの ETH 値、つまり ETH 残高を取得します。ERC20 トークンまたはその他のトークンの残高を取得することではありません。

6.eth_sendRawTransaction と eth_sendTransaction

詳しくは全取引のトリガー画面へジャンプしてください。eth_sendRawTransaction が完了できるトランザクションタイプには、eth_sendTransaction が含まれます。

7.eth_getTransactionCount

このインターフェイスは、ETH ウォレットアドレスに基づいて、現在のウォレットアドレスのトランザクションシリアル番号 Nonce を取得できます.このインターフェイスの 2 番目のパラメーターは、ジェネシス、ペンディング、最新であり、各パラメーターは次の関数に対応します。

ジェネシスをフェッチするとき: 現在の ETH アドレスが初めてトランザクションを開始するときに、ノンスのシリアル番号を取得します。
フェッチ保留中: 現在の ETH アドレスを取得し、保留状態にあり、ブロックによってパッケージ化されるのを待っているトランザクション注文に対応するノンスシーケンス番号を送信します。現在クエリされているアドレスに保留状態のトランザクションがない場合は、最新と同じナンスシリアル番号が返されます。
最新をフェッチする場合: 現在の ETH アドレスによって送信され、ブロックに正常にパッケージ化されたトランザクション注文に対応する Nonce シーケンス番号に 1 を加えた値を取得します。たとえば、アドレス A の最後に成功したトランザクションに対応する Nonce は 8 であり、呼び出しインターフェイスの着信パラメーターが最新の場合、得られる結果は 9、つまり 8+1 です。
eth_getTransaction では、Nonce クエリは以下を満たす: pending>=latest>=genesis

8.eth_getCode

このインタフェースは、ETH アドレスに基づいて、現在のアドレスが契約アドレスか非契約アドレスかを判断します。そうでない場合、戻り値は「0x」です。それ以外の場合は、スマートコントラクトが最初に作成されたときの 16 進数コードを返します。

9.eth_estimateGas

このインターフェースは、トランザクションが消費する GasLimit の量を推定するために使用され、推定値には GasPrice は含まれません。
入力パラメーターのデータは推定データ量であり、推定結果値はデータ量に比例します。
このインターフェイスは、ウォレットがトランザクションを開始してユーザーがガス料金を選択できるようにするときに使用され、ガス料金の進行状況バーで最大値まで引き出されます。最大値は、通常、このインターフェイスによって返される値です。

10.eth_call

これは、 ETH がスマートコントラクトにアクセスするために使用するユニバーサル RPC インターフェイスです。つまり、このインターフェイスを使用して、任意のスマートコントラクトのパブリック関数にアクセスできます。

eth_getBalance は ETH 残高を照会するために使用されますが、ERC20 トークン残高は eth_call を介して照会する必要があります。このインターフェイスの入力パラメータは、eth_sendRawTransaction/eth_sendTransaction の入力パラメータと同じです。
eth_call インターフェイスは、ブロックチェーン上のデータを変更せず、ETH スマートコントラクトのすべての機能にアクセスできる読み取り専用インターフェイスです。

eth_call の読み取り専用機能は、ソースコードの上位レベルから理解されます
. コントラクトコードを実行するとき、EVM は
最初にブロック番号 blockNumber を使用して対応するブロック情報を見つけ、
次に、status という名前の変数を体系的にインスタンス化します。このブロックのデータ. 、対応する EVM インスタンスがステータスによってインスタンス化され、
次にブロックによって提供される情報に従ってコントラクトコードの変数値がインスタンス化されます。つまり、スマートコントラクトの機能の変数値は、実行前の現在のブロックの高さによって決定されます。
つまり、eth_call が伝達関数を呼び出すと、値をブロードキャストしてデータレベルに変更することなく、コードのメモリレベルで値を直接変更します。

ノードリンク

現在、ノードリンクを取得する方法は 2 つあります。

自分でサーバーを購入し、Geth などの ETH ノードサービスプログラムを起動し、ノードプログラムが提供するインターフェイスリンクを取得します。
サードパーティサービスプラットフォームが提供するノードリンクを使用する

最初の方法の操作プロセスは、最初に対応する ETH ノードバージョンのソースコードをダウンロードし、次にドキュメントのコンパイル方法に従って自己コンパイルし、実行可能なプログラムを生成してから、サーバーに展開します。なお、ETHノードのソースコードには、バージョン番号の異なるバージョンだけでなく、コンピュータ言語の異なるバージョンもあり、公式のGethはGolang言語で開発されたバージョンです。

最初の方法の全体的な実装の長所と短所:
(1) 高度にカスタマイズ可能

ノード起動用の構成ファイルを自分で構成できます
二次開発用に自分でソースコードを修正してからコンパイルすることができます
サービスゲートウェイやノードクラスタなどの関連する動作モードを自分で設定できます
パブリックチェーンマイナーに参加して、ETH 収入を得ることができます

(2) 技術要件の難易度が比較的高い

ユーザーは、構成ファイル内の各属性の意味と影響を習得し、理解する必要があります。
ユーザーは、サーバー側の操作と保守に関する知識をある程度理解している必要があります。
ユーザーは、対応するノードプログラミング言語のコンパイルコマンドを理解し、その言語を使用したことがある必要があります。

(3) 自己運用・保守コストが高い

ノードサービスの動作を監視するために必要です
一部の問題は強制終了後に自動再起動できるため、ノードプログラムの実装が必要です。
クラスタの場合、各サービスの安定性を確保する必要があります

(4) 自己負担のサーバーおよびその他の製品の費用

2番目のオプション

学習段階やオンラインビジネスで高度なカスタマイズを必要としない場合に適しています。

第 1 の方式と比較すると、第 2 の方式には反対の長所と短所があります。
必要なリンクが 1 つだけなので、2 番目のオプションも最も便利で安価です。

2 番目のオプションの実装

リンク獲得

ノードリンクはhttps://infura.io/に従って無料で取得できます。
Infura は、ETH ノードをホストする外部クラスターです. また、開発者は、独自の ETH ノードリンク (メインネットとテストネットを含む) を無料で申請できます. 完全な機能を備えており、便利です.

詳細は153と159へ。