2021 年 12 月 1 日
UMA は、ユーザーがイーサリアム ブロックチェーン上で信頼を最小限に抑えた金融契約を締結できるプラットフォームです。以前に監査を行った 分散型オラクル, 特定の金融契約テンプレート, いくつかのアドホックプルリクエスト, 無期限マルチパーティ テンプレート および 長期にわたるエンゲージメントにわたるさまざまな増分プル リクエスト。 この監査では、レイヤー2チェーンからイーサリアムメインネットにトークンをすばやく送信するための新しいメカニズムと、それに関連するOptimisticOracleへの変更を確認しました。 レビューは2週間にわたって3人の監査人によって完了されました。
対象領域
監査されたコミットは次のとおりです f24ad501c8e813cf685f72217e7f13c8f3c366df
範囲には次の契約が含まれます。
- 契約/被保険者ブリッジ/ *(テスト契約を除く)
- 契約-ovm /被保険者-ブリッジ/実装/ *
- 契約/共通/実装/AncillaryData.sol
- 契約/oracle/implementation/SkinnyOptimisticOracle.sol
また、Solidity ファイルへの変更も確認しました。 プルリクエスト 3445.
すべての外部コードとコントラクトの依存関係は、文書化されているとおりに機能すると想定されていました。
システム概要
サポートされているレイヤー2(L2)チェーンであるOptimismとArbitrumは、資金をイーサリアムメインネット(L1)に転送するメカニズムを提供します。 ただし、セキュリティ上の理由から、これらの転送が完了するまでに大幅な遅延が発生します。 これに対処するために、L2トークン所有者は、トークンが最終的にL1 UMA契約であるブリッジプールに(バッチとして)転送されることを知って、UMA契約である貸金庫に資金を預けることができます。 転送されるトークンごとに個別のブリッジプールがあります。
L2デポジットに続いて、誰でも詳細をL1ブリッジプールに中継できます。L2ブリッジプールは、中継された情報に異議を唱えたい場合に備えて、短時間待機します。 すべての紛争は、Skinny Optimistic Oracle(以下で説明)によって処理されます。 リレーを受け入れる前に、流動性プロバイダーはLPトークンと引き換えにブリッジプール契約に事前に資金を提供する必要があります。 議論の余地のないリレーは有効であると見なされ、ブリッジプールは独自の準備金を使用して転送を完了します。転送の一部はリレーに転送され、一部は流動性手数料として保持されます。 LXNUMX預金が確定すると、最終的に資金が補充され、流動性手数料がLPトークン保有者に割り当てられます。
ブリッジプールでは、異議申し立て期間が終了する前に、転送金額の一部と引き換えに、誰でも(ブリッジプールの予備金なしで)転送に個別に資金を提供することもできます。 リレーはまだ争われる可能性があるため、リレーが正しくないと見なされた場合、これらの資金は失われます。 ほとんどの場合、このメカニズムにより、ユーザーはL2からL1へのトークン転送をすぐに体験できるようになると予想されます。
スキニーオプティミスティックオラクルは、概念的には既存のオプティミスティックオラクルと非常によく似ています。 これは、ユーザーがoracleリクエストの結果を単に主張するためのインセンティブメカニズムを提供します。これは、異議が唱えられない場合は正確であると見なされます。 紛争は、以前の監査レポートで説明されている低速のDVMメカニズムに追いやられています。 主な違いは、新しいバージョンでは、ユーザーが関数呼び出しを実行するときにすべての関連情報を提供する必要があるため、値を保存したり、ストレージから取得したりする必要がないことです。 また、リクエスターがアクティブなリクエストの構成パラメーターを変更する機能も削除されます。
以前、さまざまな金融商品を作成するための一般的なメカニズムを提供するロングショートペア契約を確認しました。 これらの契約は、有効期限に達し、決済価格がわかったときに解決できます。 プルリクエスト3445によって導入された変更により、有効期限が切れる前に決済価格がわかっている場合、契約を早期に解決できる可能性があります。
特権ロール
L2貸金庫には、サポートされているトークンや、ブリッジを介してL1にバッチトークンを送信するための最大レートなど、いくつかの構成パラメーターがあります。 また、L1トークンコントラクト、L2トークンコントラクト、および対応するブリッジプール間の整合性を確保するように構成する必要があります。 これらのパラメーターは、L1の管理者契約によって設定され、ブリッジプールの紛争解決プロセスもパラメーター化します。 契約はUMAガバナンスメカニズムによって制御されることが期待されるため、ユーザーはシステムを賢明かつ公正に管理するためにこのプロセスを信頼する必要があります。
生態系の依存関係
レビューされたすべてのコンポーネントは時間ベースのロジックを使用します。つまり、イーサリアムの可用性に依存します。 特に、紛争取引が大幅に遅れた場合、無効な中継や価格提案が誤って確認される可能性があります。
さらに、トークンブリッジは、L2貸金庫に送金されたすべての資金が、最終的に対応するL1ブリッジプールに転送されることを暗黙的に想定しています。 これは、楽観主義と仲裁の橋の正しく継続的な機能と、それらの紛争解決メカニズムに依存しています。
最後に、L2貸金庫に送信されたトークンは、意図された受信者ではなく、L1のブリッジプールに割り当てられます。 プールから資金を取得するには、L1トークン所有者は最初にそれらを追加のトークンと照合する必要があります。 したがって、このメカニズムは、常に流動性があることを保証するために、L1トークンの十分に深い市場に依存しています。
クライアントから報告された問題
監査中に、UMAチームは、強調する価値のあるいくつかの問題と行動を独自に特定しました。
リレーのチャレンジ期間中にOptimisticOracleまたはBridgeAdminパラメータが変更された場合、リレーに異議を唱えると、提案者または異議者のいずれにも追加の手段がなく、リレーが削除されます。 たとえば、リレーが担保トークンに送信されると想像してください
TOKEN_A
、しかしリレーの真ん中でTOKEN_A
担保のホワイトリストから削除されます。 ホワイトリストに載っていない担保の価格要求をOOまたはDVMに送信できないため、紛争は元に戻ります。 有効な異議申し立てリクエストをブロックしたくないので、BridgePool
の保留中のリレーを削除しますTOKEN_A
紛争の場合。 この設計上の決定の結果は次のとおりです。
1.最終料金の値上げにより、次のことが発生します。そのトークンの未処理のリレーは、正しいか間違っているかにかかわらず、論争を通じて「キャンセル可能」になります。 キャンセルはどちらの当事者にも利益をもたらさないため、最終的な料金変更の実行中に発生する(まれな)悪い要求を殺すことをいとわない正直な論争者の存在を前提としています。 これはまた、グリーフィングがガスを使ってリレーをキャンセルし、リレーを強制的に再リレーする可能性があることを意味します。
2.識別子またはトークンのホワイトリスト解除。これは、何か問題が発生しない限り発生しないはずです。
3.いかなる要求も取り消すことができ、論争に対する経済的インセンティブが存在しない、議論の余地のない要求の延長。 これは、紛争を完全にブロックする代替手段よりも優れているように見えますが、グリーフィングはガスを支払うことでリレーを無期限にブロックしたり、罰せずに悪いリレーを送信したりできるため、確かに非常に悪いです(ガス料金を除く)。注:これは、最終料金や担保のホワイトリストなどのパラメータをしばらくの間「フリーズ」するOOを使用する代わりの方法ですが、これにはOOへの追加の呼び出しが必要になり、ハッピーパスにはコストがかかります。
リレーは次の方法で高速化できます
speedUpRelay()
彼らが活気を通過した後。 これによるリスクは見られませんが、フラッシュローン+スピードアップ+活気のある後の決済の可能性が開かれ、フラッシュ借り手に「無料」の即時リレー料金が提供されます。 この提案ではこれを防ぎます PR.
On
settle
、 もしBridgePool
WETH
プールと受信者はそうではない契約ですpayable
(ETHを受け入れることはできません)、その後settle
失敗します。 これを修正し、送信時にフォールバックする予定ですWETH
、しかし、これに関して行われた未解決の作業はまだありません。
In
relayDeposit
、BridgePool
の残高は、提案者の債券に加えて中継する金額よりも大きくなっています。 これは時代遅れのチェックであり、チェック後に提案者のボンドがユーザーから引き出されるため、保守的すぎます。 この提案でこれに対処します PR.
バグを見つけたところ
chainId
inBridgePool
、の一部として含まれていますDeposit
構造体およびリレー関連のすべての機能への機能入力として(つまり、relayDeposit
,speedUpRelay
,settle
)はタイプですuint8
。 これは、たとえばIDが421611のArbitrumを処理するには小さすぎるタイプです。実際にこのバグを検出し、L2側で修正しました。BridgeDeposit
を設定しましたchainId
入力するuint256
。 このPRはchainId
onBridgePool
タイプに一致BridgeDepositBox
: UMAprotocol / protocol#3463
以前は、紛争機能は預金額をから差し引いていませんでした
pendingReserves
(これは、まだ解決されていないリレーが原因でリザーブプールのどれだけがロックされているかを追跡する変数です)。 その結果、各紛争はプール内のリレー量を無期限にロックすることになりました。 LPによって撤回したり、将来のリレーで使用したりすることはできません。 修正はここにあります: UMAprotocol / protocol#3473.
にバグが見つかりました
BridgeDepositBox
コラボレーhasEnoughTimeElapsedToBridge
かどうかをチェックしませんuint256
値はに等しい0
デフォルトでは: PR3484で修正
為替レート方式(状態変更)は、転送されるトークンと、ブリッジプールコントラクトのaddLiquidityメソッドで作成されるLPトークンの間で呼び出されます。 この計算は、メソッドの先頭に移動する必要があります。 これにより、非常に奇妙な状態値が発生します。 PRを参照 こちら 修正します。
ビュー方式
liquidityUtilizationPostRelay
(オフチェーンでのみ使用されます)、誤った使用率を報告します。 上の分母 この行 だけではいけませんliquidReserves
、代わりに、未使用および使用済みの埋蔵量を表す必要があります。 修理済み こちら.
アップデイト
問題の修正に加えて、次の段階的な変更も確認しました。
- PR3500-Reef から冗長トークンパラメータを削除します
BridgePool
イベント。 - PR3478-Reef ローカルにキャッシュされた変数のリストにDVMの最終料金を追加します。
- PR3460-Reef (N04への対応に加えて)潜在的な負の流動性利用エッジケースを説明する
- PR3482-Reef 冗長ファイルを削除し、OVM2.0の変更に従ってOVM定数を更新します。
- PR3585-Reef を更新します
BridgeDepositBox
一貫性のためのインターフェースであり、OpenZeppelinを使用しますSafeERC20
としょうかん。
修正を確認しているときに、別の問題を特定しました。 の値を決定するとき BridgePool
LPトークン、あります 予期せず負のオーバーフローが発生する可能性のある中間計算、流動性の追加と削除を一時的に無効にします。 未分配料金を差し引く前に、使用済み準備金を追加するように計算を並べ替える必要があります。
重大な重大度
[C01]閉じ込められた提案者の報酬
LongShortPair
縮小することはできません。 提案者の報酬を取得します Optimistic Oracleでの価格提案にインセンティブを与えるために使用される、有効期限をトリガーするアドレスから。 しかし LongShortPairCreator
契約も 資金を取得して転送します デプロイヤアドレスから。 これらの追加資金はOptimisticOracleに渡されず、代わりに LongShortPair
契約する。
重複する転送を削除することを検討してください。
アップデート: コミット時点で修正済み 9bab1ff353a417952ba8c96a098773f340d9da17
in PR3523-Reef.
重大度が高い
[H01]コンカレントリレーはリザーブを使い果たします
relayDeposit
の機能 BridgePool
縮小することはできません。 契約に十分な資金があることを確認します 転送を実行します。 ただし、それは考慮されていません 保留中の準備金、アクティブなリレーに割り当てられた資金を追跡します。 したがって、複数の同時リレーが同じ資金に依存している可能性があり、すべてがすぐに解決できるとは限りません。 特に、転送の流れが安定していると、即時のリレーの戻りが無期限に遅れる可能性があります。
保留中の準備金が液体の準備金を超える原因となるリレーを防ぐことを検討してください。
アップデート: コミット時点で修正済み 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR3501-Reef.
[H02]ブリッジングパラメータの境界が一致しません
deposit
function BridgeDepositBox
レイヤ2チェーンに展開されるコントラクトは、L2とL1の間の資金を橋渡しするために使用されます。 特に、中継者は リレー 関連するL1のトランザクションの詳細 BridgePool
。 ただし、貸金庫は 包括的境界 ブリッジプールが使用している間、リレー料金を制限する 排他的境界。 これは、一部の預金(25%の中継手数料が含まれる)を中継できず、両方のレイヤーで資金にアクセスできないことを意味します。
すべての有効なデポジットを確実に中継できるように、両方のレイヤーで検証を同期することを検討してください。
アップデート: コミットで修正 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR3494-Reef。 これは元々重大度として分類されていましたが、UMAチームが資金が厳密にトラップされず、影響を受ける預金の変更されたリレーの説明を受け入れることにDVM有権者が同意した場合に解放される可能性があると指摘したため、格下げされました。
中程度の重大度
[M01]間違ったアドレスへのコールバック
SkinnyOptimisticOracle
価格リクエスターが存在する場合は、コールバック関数を呼び出します。これにより、リクエスターは重要な状態の変化に応答できます。 ただし、コールバックは、の価格リクエスターではなく、価格提案者で誤って呼び出されます。 proposePriceFor
function。 これは、価格要求者が価格提案に応答できないことを意味します。
幸い、この機能は現在のコードベースでは使用されていません。 それでも、を呼び出すことを検討してください priceProposed
リクエスターのコールバック。
アップデート: コミット時に修正 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR3531-Reef.
[M02]追加機能の不具合
appendKeyValueBytes32
function 入力をフォーマット済みに組み合わせる必要があります bytes
配列。 しかし currentAncillaryData
is 誤って破棄された.
補助データ以降 オラクルの解決プロセスに影響を与える、値が正しくないと、Oracleの結果が損なわれる可能性があります。 幸いなことに、 XNUMX回の呼び出し appendKeyValueBytes32
コードベースで、空を使用します currentAncillaryData
バッファなので、バグはこの場合には影響しません。
更新を検討してください appendKeyValueBytes32
機能するように currentAncillaryData
返されるバイト配列に含まれます。
アップデート: コミットで修正 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR3532-Reef.
[M03]不完全な補助データ検証
LongShortPair
コンストラクタ を確認します customAncillaryData
十分に小さい。 ただし、それは考慮されていません 早期呼気フィールド。 これは、楽観的なOracleを意味します 予期せず拒否する可能性があります この機能を無効にする早期満了価格リクエスト。
追加のフィールドを考慮して、検証を更新することを検討してください。
アップデート: コミット時点で修正済み 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR3524-Reef.
[M04]ゼロタイムスタンプの誤った処理
LongShortPair
契約の場合、早期有効期限のタイムスタンプはゼロです。 フラグとして使用 誰も早期呼気メカニズムをトリガーしていないことを示します。 ただし、 そのメカニズムをトリガーする タイムスタンプはゼロです。 このシナリオでは、Optimistic Oracleが呼び出されますが、 その後の価格要求に対する保護 効果がありません。 幸いなことに、一度 決済価格が選択されます、それは上書きされないので、これは一貫性のない決済につながることはありません。 それにもかかわらず、その後の価格要求は可能性があります 記録された早期有効期限のタイムスタンプを変更します、ゼロタイムスタンプを使用して決済価格を決定する場合でも。 それはまた可能性があります 誤解を招くイベントを発行する.
ゼロタイムスタンプを使用して早期期限切れを防ぐことを検討してください。
アップデート: コミット時点で修正済み 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR3526-Reef.
[M05]ゼロボンドの可能性
requestPrice
の機能 SkinnyOptimisticOracle
縮小することはできません。 最終的な料金を保証金として使用します ボンドが指定されていない場合。 しかし requestAndProposePriceFor
function ゼロボンドを使用できます、それと矛盾する @notice
および @param
コメント。 ゼロボンドは、無効な提案や紛争に対するインセンティブを弱めます。
幸いにも、 この関数を呼び出すだけ コードベースで提案者の絆を設定します。 それでも、保証金が指定されていない場合は、最終的な料金を使用することを検討してください。
アップデート: コミット時点で修正済み daaabfc342ba1395a577159b6eb26adb20fcd232
in PR3534-Reef.
[M06]不要な管理者権限
BridgePool
縮小することはできません。 から継承 ExpandedERC20
流動性プロバイダーにLPトークンを発行できるようにします。 これはOpenZeppelinの機能を継承します ERC20
契約も 管理者権限を提供します コントラクトデプロイヤに送信します。これにより、LPトークンを作成して書き込むことができます。 ただし、この権限は必須ではなく、行使された場合、流動性プロバイダーに不当なペナルティを課す可能性があります。
変更を検討する BridgePool
から直接継承する ERC20
ExpandedERC20
.
アップデート: コミットで修正 370e8b21b660543eadbd764fed984a5bdeddce24
in PR3492-Reef.
重大度が低い
[L01]満了時に決済できません
settle
の機能 LongShortPair
縮小することはできません。 決済条件を考慮します 現在の時刻が厳密に有効期限のタイムスタンプの前または後の場合。 ただし、現在の時刻が有効期限のタイムスタンプと一致すると、誤って元に戻ります。
包括的境界を使用して、 postExpiration
修飾子.
アップデート: コミットで修正 f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR3527-Reef.
[L02] requireステートメントにエラーメッセージがありません
にrequireステートメントがあります BridgePool
縮小することはできません。 エラーメッセージなし。
すべてのrequireステートメントに具体的で有益なエラーメッセージを含めることを検討してください。
アップデート: コミット時点で修正済み 67e60faa3a44c842c37211d2e903a983ff192e57
in PR3536-Reef.
[L03] docstringがありません
コードベース全体で、 イーサリアムナチュラル仕様 欠落しているか不完全です。 例は次のとおりです。
コントラクトのパブリックAPIの一部であるすべての関数(およびそれらのパラメーター)を完全に文書化することを検討してください。
アップデート: 強調表示されたコメントはコミットで修正されました e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR3533-Reef。 残りのコードベースでは、NatSpecの完全性を検証しませんでした。
メモと追加情報
[N01]呼び出しの戻り値がチェックされていません
deposit
function L2の BridgeDepositBox
契約への低レベルの呼び出しがあります l2Token
時 l1Token
is l1Weth
。 この低レベルの呼び出しは、 deposit()
に属する関数 WETH インターフェース。 これなら l2Token
WETHとまったく同じように動作し、失敗することはありません。 しかし、この場合 l2Token
動作が異なり、失敗します。この低レベルの呼び出しの成功フラグはチェックされないため、元に戻すことはできません。
すべての低レベル呼び出しの戻り値を確認し、適切に対応することを検討してください。
[N02]イベントでのインデックス付きパラメータの欠如
このコードベースで定義されているイベントの多くには、インデックスを作成する必要のあるパラメーターがあります。
検討 イベントパラメータのインデックス作成 特定のイベントの検索とフィルタリングを行うオフチェーンサービスのタスクを妨げないようにするため。
アップデート: コミットで部分的に修正 d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR3535-Reefを選択します。 chainId
のパラメータ WhitelistToken
更新されませんでした。
[N03]暗黙のキャストの不整合
LongShortPair
一般的に契約 タイムスタンプを次のように扱います uint64
値、暗黙的にキャストされます uint256
の場合の値 OptimisticOracleに渡されました。 しかし、 requestTimestamp
のパラメータ _requestOraclePrice
function に時期尚早にキャストされます uint256
。 これは機能的な影響はありません。
それでも、一貫性を保つために、 uint64
このパラメータの場合、暗黙的ににキャストできるようにします uint256
OptimisticOracleに渡されたとき。
アップデート: コミットで修正 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR3528-Reef。 タイムスタンプが明示的にキャストされるようになりました。
[N04]タイプが正しくありません
sendMessage
の機能 iOptimism_CrossDomainMessenger
インタフェース 使用する uint256
ガス制限 楽観主義は OVM_CrossDomainEnabled
使用する uint32
ガス制限.
一貫性と予測可能性のために、更新を検討してください iOptimisim_CrossDomainMessenger
sendMessage
使用する関数 uint32
ガス制限。
アップデート: コミット時点で修正済み 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR3460-Reef.
[N05]検証の欠如
のすべての機能 BridgeAdmin
その呼び出し _relayMessage
トランザクション値が l1CallValue
パラメータですが、これは強制されません。
正しいことを確認することを検討してください msg.value
設定されています。
アップデート: コミット時点で修正済み f19b8d04c2343051ff2a8145abd41c39bd025063
in PR3537-Reef.
[N06]読みやすさ
_getDepositHash
function BridgePool
契約は展開します depositData
隙間を作るための構造体 l1Token
の構成における議論として keccak256
abi
エンコーディング。 これにより、操作が不必要に冗長になり、他のレイヤーに再実装するとバグが発生する可能性があります。
引数を単純化して、単純に順序対になることを検討してください depositData
および l1Token
.
アップデート: コミット時点で修正済み 31754be4a818109fa12131f854c3f70d6c72dba7
in PR3538-Reef.
【N07】リエントラント機能
requestAndProposePriceFor
function SkinnyOptimisticOracle
契約は信頼できない人に電話をかけます msg.sender
しかし、によって守られていません nonReentrant
修飾子。 この場合、これはセキュリティ上の懸念事項ではないようですが、予期しない動作が発生する可能性があります。
追加することを検討してください nonReentrant
信頼できない可能性のあるコントラクトを呼び出すすべての関数の修飾子。
アップデート: コミットで修正 b744d24e7579b7afa2c778f4dd680f26117b3990
of PR3539-Reef.
【N08】 seqNum
ログに記録されません
relayMessage
function Arbitrum_Messenger
センシティブアクションを実行した後、コントラクトは関連するイベントを発行しません。 The relayMessage
サブルーチンとしての関数呼び出し sentTxToL2NoAliasing
それ自体が uint256
値 seqNum
、ただし、この戻り値はログインしていません relayMessage
機能。
契約の活動に続いてオフチェーンクライアントの追跡と通知を容易にするために、機密性の高い変更が行われた後にイベントを発行することを検討してください。
アップデート: コミット時点で修正済み 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR3541-Reef.
[N09]誤植
コードベースには、次のタイプミスが含まれています。
コードの可読性を向上させるために、これらのタイプミスを修正することを検討してください。
アップデート: コミット時点で修正済み 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR3540-Reef.
[N10]文書化されていないERC20承認要件
requestEarlyExpiration
および expire
機能 LongShortPair
契約はそれぞれ、発信者が契約に許可を与えたことを前提としています 提案者の報酬を引き出す.
予測可能性のために、この要件を関数コメントに文書化することを検討してください。
アップデート: コミットで修正 da3754f50284480df57b90b80002da06a1ce0d02
in PR3529-Reef.
[N11]未使用の修飾子
BridgePool
契約、 onlyFromOptimisticOracle
修飾子 は定義されていますが、コードベースで使用されることはないため、削除する必要があります。
アップデート: コミットで修正 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR3542-Reef.
結論
2つの重大な問題と1つの重大度の高い問題が見つかりました。 ベストプラクティスに従い、潜在的な攻撃対象領域を減らすために、いくつかの変更が提案されました。
- &
- 7
- Action
- アクティブ
- Ad
- NEW
- 住所
- 管理人
- 利点
- すべて
- 許可
- API
- 引数
- 監査
- 賃貸条件の詳細・契約費用のお見積り等について
- さ
- BEST
- ベストプラクティス
- ブロックチェーン
- ボックス
- BRIDGE
- バグ
- バグ
- コール
- 例
- キャッチ
- 原因となる
- 挑戦する
- 変化する
- 点検
- コード
- 注釈
- 含まれています
- 縮小することはできません。
- 契約
- 可能性
- 電流プローブ
- データ
- 分権化された
- 遅らせる
- 設計
- 決定
- DID
- 異議申立て
- そうではありません
- 早い
- 経済
- エッジ(Edge)
- 効果的な
- ERC20
- ETH
- イーサリアム
- エテリアムブロック鎖
- イベント
- イベント
- 例
- 交換
- 予想される
- 体験
- 特徴
- 費用
- ファイナンシャル
- 名
- 修正する
- フラッシュ
- 発見
- function
- ファンド
- 資金
- 未来
- GAS
- ガス代
- 与え
- ガバナンス
- ハッピー
- 持って
- こちら
- ハイ
- 強調表示された
- ホルダー
- 認定条件
- HTTPS
- 奨励します
- 含まれました
- 含めて
- 増える
- 情報
- 関心
- インタフェース
- 問題
- IT
- 既知の
- つながる
- 図書館
- 液体
- 流動性
- 流動性プロバイダー
- リスト
- ローン
- 局部的に
- ロック
- LP
- LPを
- 市場
- 一致
- 最も
- 開いた
- オラクル
- その他
- プラットフォーム
- プール
- プール
- 電力
- 予防
- ブランド
- プロセス
- 提案
- 提供します
- は、大阪で
- 公共
- 理由は
- 減らします
- レポート
- REST
- 結果
- 収益
- レビュー
- リスク
- セキュリティ
- サービス
- セッションに
- 決済
- ショート
- 重要
- 同様の
- 小さい
- So
- 固い
- 誰か
- 何か
- スピード
- 過ごす
- 都道府県
- ステートメント
- ストレージ利用料
- 成功
- サポート
- 表面
- test
- 介して
- 全体
- 時間
- トークン
- トークン
- top
- 追跡
- トランザクション
- 取引
- 信頼
- アップデイト
- 更新版
- UPS
- users
- 値
- 詳しく見る
- ホワイトリスト
- 誰
- 以内
- 無し
- 仕事
- 価値
- ゼロ