EOSネットワークCPU「問題」について

EOSネットワークCPU「問題」について

2019年11月1日から、多くのEOSメインネットユーザーたちがトークンの送受信を行うにあたり困難に直面しています。すなわち、EOSネットワーク上のリソースの一つである「CPU」が不足することによってトランザクションを実行できない状況が発生しており、執筆現在(2019年11月14日)においてもその状況は大きく変わっていません。

本記事では、現在進行形で発生しているCPUをめぐる状況について、その内容、ユーザーサイドにおける解決法、この問題がEOSメインネットに対して意味するところなどを、具体的にみていこうと思います。

なお、ユーザーとしての問題解決法のみに興味がある方は、「どうすれば良いのか」セクションを参照してください。

何が起きているのか

問題発生から2週間ほど経過しているので、問題を自身で直接経験したという人もいるかもしれません。問題の趣旨は、前述したように、EOSユーザー/アプリケーションたちがEOSメインネット上でトランザクションを実施できない状況が発生しているということです。トランザクションが実行できないわけですから、ユーザー間におけるEOSの送受信ができないのみならず、各種dAppにおいても、必要な量のCPUが使用可能な状態でない場合にはアプリケーションが機能しなくなってしまい、開発者・ユーザーともに不満の声が挙がっているという状況です。

たとえば、筆者が昨日1EOSを送信するためのトランザクションを実行しようとしたところ、198μs(マイクロ秒)に相当するCPU(昨日のレートでおよそ2EOSに相当)が必要でした。ここで、筆者は2EOSをCPUにステークしていなかったので、トランザクションを実行できませんでした。

billed cpu time

そこで、CPU向けのステーキングを試みたものの、ステーキング実行トランザクションに必要なCPUも不足しており、実質的に身動きの取れない状態となってしまいました。

billed cpu time

なぜ起きているのか – CPUステーク不足

問題が起きている原因は、冒頭でも軽く触れましたが、CPUの「(ステーク)不足」にあります。

EOSネットワークを実行するにあたっては、CPU、NET、RAMが必要となり、CPUとNETはEOSトークンをステークすることによって、RAMはEOSトークンで購入することによって、アクセスすることが可能となります(CPU、NET、RAMに関する詳細は、こちらを参照してください)。

このため、トランザクション実行にあたって、ステークされたCPUキャパシティを超えるCPUが必要となる場合にはCPU不足ということで、トランザクションが実行できなくなります。

今回はまさに、CPUキャパシティを超えるトランザクションを実行しようとしてエラーが発生することによって、多くのEOSユーザーが不満の声をあげているということになります。これまで普通に実行できていたトランザクションが実行できないのですから、困惑するのも無理はないでしょう。

ここで重要なのは、EOSネットワーク自体はデザインされた通りに機能しており、今回の事例はバグやハッキングとは無関係だということです。

実際、これまで私たちEOSユーザーが不自由なくトランザクションを実行できていた背景には、EOSにおいて余剰(使用されていない)リソースをネットワーク全体に平等に振り分けるというメカニズムの存在があります。つまり、私たちはこれまで、自らステークしたCPUキャパを超えるようなトランザクションを実施できていたということになります。

しかし、ある一定の閾値を超えると、この余剰リソースが利用できなくなることによって、私たちが利用できるリソースが、自らステークした分に限定されることになります。

なぜCPUステーク不足なのか – EIDOSエアドロップによるネットワーク混雑

トランザクション実施ができないのは、必要なCPUステークが不足していることが原因だという点についてみてきました。

それでは、なぜCPUステークが不足する状況にあるのでしょうか。

これは、ネットワークが混雑している(通常より多くのトランザクションが実行されている)ということが原因です。実際、混雑したネットワーク内でトランザクションを処理するためには、より多くのCPUが必要となります。

それでは、なぜ通常より多くのトランザクションが実行されているのでしょうか。

これは、「EIDOS」というトークンのエアドロップに大量のユーザーたちが参加した(している)ためです。

EIDOSとは何か

「EIDOS」とは、公式ウェブサイトによると「ENUMIVO IDEAD, OH SHIT!」の頭文字をとって命名されたEOSメインネット上のトークンであり、その名の一部となっている “ENUMIVO” というチェーンを開発した「Aiden Pearce」という匿名人物によって開発されたとされています。用途は現時点では不明です。

そして、11月1日からEIDOSエアドロップが開始されました。仕組みは以下のようになっています。

1. 0.0001 EOS以上のEOSを “eidosonecoin” というアドレスに送信

2. 送信したEOSと同額のEOSを受け取るのに加え、このアドレスで保管されているEIDOSの0.01%を入手できる

sending_eos_to_eidos_contract_address
出典: Coinbaseブログ記事(https://blog.coinbase.com/eos-enters-congestion-mode-due-to-eidos-airdrop-3d3f82081074)

EIDOS公式ウェブサイトによると、このエアドロップは15ヶ月程度続き、トークン総発行量は10億EIDOSとなるようです。そして、その80%(8億EIDOS)がエアドロップ経由で一般ユーザーに、残りの20%(2億EIDOS)はチームに配布されます。公式ブログによると、チーム配布分は10年間ロックされる予定で、チームとしては長期的な視点からうまくプロジェクトをマネージしていくインセンティブが存在するとしています。

なぜ人々がこのような用途不明のトークンに群がるかといえば、このトークンは「ステーブルコイン」であるTether(USDT)と交換できるからです。実際、MXC ExchangeやNewdexなどにおいてEIDOSとUSDTが交換できるようになっています。USDTとフィアットの交換を行うためのインフラはすでに多く存在するので、人々は実質的に「フリーキャッシュ」を入手できるというわけです。

eidos_usdt_trading_pair
出典: Coinbaseブログ記事(https://blog.coinbase.com/eos-enters-congestion-mode-due-to-eidos-airdrop-3d3f82081074)

このような背景から、多くのユーザーたちがEOSを “eidosonecoin” に送信したことで、ネットワークが混雑し、トランザクション実行に必要なCPUステーク量が増加し、多くのユーザーにおいて元々ステークされていたCPUではトランザクションが実行できなくなった、ということになります。

もう一つの問題 – REXにおける流動性不足

不足しているCPUを入手すべく、多くのユーザーやアプリケーション開発者たちは、REXに赴くことになりました。

REXとは「Resource Exchange」すなわち「リソース交換」という発想の元、EOSネットワーク上におけるリソース(具体的にはCPUとNET)のリースを可能とするメカニズムです(REXの詳細に関しては、こちらの記事などを参照してください)。

2019年11月14日現在、1 EOSを支払うことで実質174EOS分のリソースが理論上利用可能になる計算となっています。

EOS REX ratio
出典: EOS Authority統計データ(https://eosauthority.com/rex/statistics)

しかし執筆現在も、貸借は利用不可となっています。

具体的には、EOSトークンを貸したユーザーとしては通常であれば4日間経過後にREXトークンをEOSトークンに交換することで利息とともに回収するのですが、これが不可となっています(REXの仕組みや使用方法についてはこちらの記事などをご覧ください)。

これは、貸し出しに利用されていない部分のEOSトークンプール内のEOSトークンが不足することで発生します(これを “Liquidity Crunch”(いわゆる「信用危機」) といったりします)。

そして、貸し出しに利用されていない部分のプールが不足しているということは、当然、貸し出しに利用されるプールも不足しているということです。

そのため、ユーザーやアプリ開発者たちはREX経由のリソース調達もできないという状態になっています。

なお、REXではトータルの流動性(貸し出しに利用可能なEOS)のうち、80%までしか貸し出せないというルールがプログラムされており、残りの20%は利用不可となっています。この「20%ルール」を廃止して少しでも多くのユーザーに必要リソースがいきわたるようにすべきだとして、Block.oneのCTOであるDaniel “Dan” Larimer氏などをはじめ、EOSコミュニティ内で議論が展開されています。

どうすれば良いのか

私たちユーザーとして気になるのは、いつプラットフォームが11月1日以前のような状態に「復帰」するかということでしょう。

現実的には、REXを利用してCPUを大量に確保した人々が借入期間(30日単位)を更新しない限り、また、EIDOSをUSDTに変換して得られる「利益」がREX上における「借入コスト」(執筆現在、月利約0.1%、年利約1.23%)を上回る限り、人々がEIDOS関連のトランザクションを実行するインセンティブが存在することになります。

しかし、幸いなことに、30日間というローンの期限切れを待たずして(かつ借りている人がローンを更新しない可能性を期待する必要なくして)CPUにアクセスする方法が複数存在します。

本項では、そのうちbloks.ioを用いた方法を紹介します。手順は簡単で、以下の通りです。

1. bloks.ioウェブサイトを訪れる

2. Scatterを起動させる

3. プラットフォーム右上のユーザー名をクリックし、”FREE CPU (5 TX LEFT)” という部分をクリックしてスライダーを右に移動させる(下記スクリーンショットを参照)。

bloks.io free cpu

これによって、アカウント内でステーキングされたCPUが不足していても、1日あたり最大5つのトランザクションを実行できるようになります。

なお、その他の方法については日本EOSコミュニティで積極的に活動されているクロイカラスさんの記事が詳しいので、こちらからぜひ参照してみてください。

今回の「問題」が意味するところ

前述したように、これはEOSメインネットにおける「仕様であってバグではない」のであって、ユーザーが十分な量のステーキングを行なっていなかったことが原因です。そのため、筆者としては、EOSにおける本質的な「問題」を反映しているものではないと考えています。

しかし、十分な量のリソースを確保できない状態となっているのも事実であり、このような状態を「仕様」として片付けてしまうのは「問題」だといえるでしょう。

ビットコイン誕生から10年以上が経過した今、クリプト業界も少しづつ成熟してきているとはいえ、今回のような「想定外」の事例はEOSに限らず今後も発生すると思われます。

そのため、こうした事例を事前に防ぐために注力することも当然重要である一方、事例発生後に、開発者やユーザー、そしてEOSの場合はBlock.oneという「運営組織」を含むコミュニティ全体でどのような対応を行っていくかという点が一層重要になるのではないでしょうか。

そのため、今回の問題をもってして「EOSの欠陥」を嘆くのではなく、いかにコミュニティ全体としてEOSエコシステムを充実させ、ひいてはクリプトエコシステムにおいて業界全体としてあるべき姿を提示していくことで、本事例をポジティブに活用していくことが求められているように思われます。

Leave a Reply

Close Menu