この投稿は、Occam.Fiによる、2021年9月に予定されているアロンゾ（Alonzo）ハードフォークのロールアウトに向けて、Occam.fiがカルダノエコシステムが解決している問題や課題に関するシリーズの最初のもので、並行性についての記事です。

以下はOccam PRに掲載された記事「The Occam.fi Technical Series: On Concurrency」を翻訳したものです。

The Occam.fi テクニカル・シリーズ: コンカレンシー（並行性）について

By Occam PR 2021年7月1日

並行性とは、複数の参加者が1つのサービスに同時にアクセスすることだと考えられます。

この投稿は、2021年9月に予定されているアロンゾ（Alonzo）ハードフォークのロールアウトに向けて、私たちカルダノエコシステムが解決している問題や課題に関するシリーズの最初のものです。

この投稿では、同時実行（複数の計算が同時に行われること）の問題について詳しく説明します。まずEthereumの観点からアプローチし、次にそれが現在のCardanoのエコシステムにどのように反映されているかを見ていきます。最後に、潜在的なソリューションのための初期の基盤を探り、将来的にどのような方向に向かうのかを考えます。まず最初に、コンピュータサイエンスの領域における同時実行について紹介します。

並行処理とは？

まず最初に、コンピュータサイエンスの分野にそのルーツを辿り、以下のように表現される「同時実行」の概要を説明します。プログラム、アルゴリズム、または問題の異なる部分やユニットが、最終的な結果に影響を与えることなく、順不同に、または同時に部分的な順序で実行される能力」[1]。[1].
暗号通貨の世界では、特にスマートコントラクト（SC）に関しては、複数の異なるエージェントが同じSCと同時に対話する能力として、コンカレンシーを最もよく理解することができます。

具体的な例としては、標準的な分散型取引所（DEX）のスワップ契約で、ボブとアリスが2つのトークンを交換しようとする場合を考えてみましょう。並行性とは、ボブとアリスがまったく同じ契約に同時にアクセスして、トークンを交換できることです。上の図1に示すように、アリスとボブが同じ自動販売機の別々の列に並び、同じ時間に同じスワップ契約で自分のトークンを別のトークンに交換していることが想像できます。これは額面通りの並行性ですが、次のセクションでは、なぜ水面下ではもっと多くのことが行われているのかについて、さらに詳しく説明します。

イーサリアムのモデル

イーサリアムは、ビットコインのUTXO（unspent transaction output）モデルとは明らかに異なるアプローチをとっており、アカウントベースの暗号通貨の中で最初に作られたものです。イーサリアムのアカウントモデルでは、ブロックチェーンの世界の状態は、採掘されるブロックには保存されません。むしろ、ローカルにノードに保存され、ノードは「StateRoot」、つまりシステムの全体的な状態を比較することで合意に達します[2]。

イーサリアムの仮想マシン（EVM）は、トランザクションをイベントとして解釈し、そのイベントの状態遷移結果を事前の状態に基づいて決定します。これにより、開発者の抽象化が非常に容易になり、イーサリアムの開始以来、Uniswap、AAVE、Curveなどの多くのDAppsの構築が促進されています。

イーサリアムのモデルを簡単に考えるには、エージェントのアカウントを0ドルから∞ドルまでのピッチャーとして理解し、アカウントにお金を追加することで、単にピッチャーに多くのお金を注ぎ込むことになり、それによってその価値を高めることができます。取引をしてガス料金を支払うことで、取引コストとガス料金の両方をかけて、途中でピッチャーを空にします。ピッチャーの中の液体の価値は液体で、取引に合わせて簡単に形を変えることができ、新しいアカウントインフローに合わせて簡単に調整することができます。

イーサリアムのトランザクションは同時進行できるか？

最初に、スマートコントラクトの領域での同時実行のアイデアは、SCが複数の異なるエージェントのトランザクションを一度に処理する能力であると述べました。イーサリアムはこれを実現していますが、注意点があります。SC自体はコンカレント（並行）ですが、実際のトランザクションの順序はシーケンシャルで、コンカレント（並行）ではありません。

つまり、Alice、Bob、Eveの3人がDEXのSCにアクセスしてトークンのペアを交換していても、個々のトランザクションは、マイナーがこれらのトランザクションをすべてブロックにまとめる際に、順番に並べられるということです。それらのブロックはイーサリアムのブロックチェーンに追加され、後にバリデーターによって再実行され、取引が実際に正しいかどうかを確認します。

イーサリアムのSCはコンカレントであっても、実際のトランザクションの発注と承認のプロセスはコンカレントではありません。これは、トランザクションによって引き起こされる多くの状態問題を引き起こすからです。例えば、マイナーがトランザクションの集合を受け取り、すべてのトランザクションを同時に処理し始めたとします。その際、ある取引が以前の別の取引で送受信された資金に依存していた場合、すぐにエラーが発生します。トランザクション処理を同時進行させるためのテストが行われ、全体的な処理速度の向上が確認されているが、それでもなお「競合する」トランザクションに遭遇し、それらを並べ替えて再処理しなければならなりません[3]。

カルダノモデル

カルダノのモデルは、産業の原点に立ち返り、拡張UTXOモデル（eUTXO）を構築しています。ビットコインもUTXOモデルを採用していますが、これを理解するには、ビットコインの取引を現金と同じように考えるのが一番です。現金の場合、10ドル紙幣を持っていて、2ドルのキャンディーバーを購入したいとします。レジ係は 1 ドルの UTXO を 2 つ受け取り、あなたはお釣りとして 5 ドルと 1 ドルの UTXO を 3 つ受け取ります。レジ係は全体で2ドル、あなたは8ドルを持っていますが、個々には複数の異なるUTXOを持っており、それらを合計すると「口座残高」になります。当初の10ドル札は「消費」され、代わりに、あなたは1、5、キャンディバーの集まりを持ち、キャッシャーは1の集まりと1つ少ないキャンディバーを持っています。

これは、ビットコインが実現したUTXOモデルを考えるのに最も適した方法であり、今回のカルダノでは、基本的にUTXOでありながら、コントラクトの状態を維持する機能と、一連の取引で同じコントラクトコードを使用することを強制する機能という2つの機能を追加したeUTXOが登場しました。eUTXOは、トランザクションにカスタムデータと値を追加することで、任意のロジックでこれらのトランザクションを操作することを可能にし、スマートコントラクトへの扉を開きます[4]。

Plutusスマートコントラクト

並行性、イーサリアムのモデルとSCによる並行性、カルダノのeUTXOモデルを新たに理解したことで、いよいよ本題であるカルダノのSCの調査を開始することができます。カルダノ上のスマートコントラクトはUTXOの形で保存されており、エージェントは、エージェントが起こそうとするあらゆるアクションを実行するためのSCロジックスクリプトを含むUTXOと対話する必要があります。

SC記述のためにイーサリアムのSolidityに対抗するカルダノのコーディング言語であるPlutusの展開により、カルダノはついにSC空間に参入し、他のブロックチェーンに存在するDAppsの多くを構築し始めることができるようになりました。同時に、開発者がそれらを改善したり繰り返したりすることができるようになりました。

カルダノのトランザクションは同時進行可能か？

ここで、多くのPlutus開発者の間で懸念されている現在の問題、「Contract-Concurrency」の問題について説明します。この並行性はイーサリアムの並行性とは異なり、現在Plutusにはグローバルな状態や、すべてのPlutus SCが接続されている可能性のある「カルダノ仮想マシン」が存在しません。イーサリアムでは、グローバルステートが共有されているため、さまざまなエージェントがイーサリアムベースのSCにアクセスすることができますが、カルダノのUTXOモデルではそうはいきません。カルダノでは、SC自体がUTXOのコンポーネントであり、基本的にUTXOがどのように利用されるかを規定する条件のように機能します。SCスクリプトの基準が満たされると、UTXOは満たされ、「消費」されます[5]。

開発者が現在問題にしているのは、一度にUTXOやSCを消費できるエージェントが1つしかないことで、いわゆる「同時実行」の問題が発生します。これをDEXの文脈で考えると、Alice、Bob、Eve、Steve、Joeの5人がADAを別のトークンと交換しようとし、全員が所定のブロック内でトランザクションを送信した場合、最初のエージェントだけがトランザクションを承認されます。この時点で、エージェントはブロックが処理されるまで、自分の取引が成立したかどうかを知ることができないため、推測ゲームになってしまいます。

これは、SCのロジックと対話するだけで、状態の変化を検証のためにマイナーに渡すことができるイーサリアムのモデルとは根本的に異なります。スマートコントラクトの「武器競争」に対するカルダノのアプローチは、ネットワークの「将来性」に多くのメリットをもたらしますが、このSCの消費の問題は、今、多くの開発者が直面している差し迫った問題です。DEXや融資、流動性プロトコルなどのプロジェクトの開発者は、システム全体を動かすSCが同時トランザクションを処理できず、一度に数千人とは言わないまでも複数のエージェントがシステムと対話しようとするのをサポートできない場合、どうやってプロジェクトを作成することになるのでしょうか。

イーサリアムのシステムでは、システム全体が流動的であるため、LPトークンを委譲することは非常に簡単です。この概念をカルダノやeUTXOモデルに移行する際には、流動性プールのようなものを未使用の取引出力の領域に変換する方法を見つけなければならなりません。

将来への期待

この問題は、Lars Brunjes氏自身がTwitterのスレッドで取り上げています。
また、Sundaeswap.Financeのチームもホワイトペーパーの中で全く同じ問題を取り上げています。チームは次のように述べています。「eUTXOは1回の取引で1回しか使うことができないため、1ブロックあたり1回のスワップしか起こらないように見えます。カルダノのブロックチェーンでは、およそ20秒に1ブロックの割合でスワップが行われています。これは非中央集権的な取引所としては驚異的なスループットとなるでしょう」。[6].

Lars氏は、IOHKのエンジニアがすでにPlutusのための「コンカレント・ステートマシン」を考えており、それをどのようにコードに組み込むかを考えていると述べています。また、上の写真のような並列化のアイデアも浮かんでいます。

私たちOccam.fiは、他の多くのカルダノプロジェクトと同様に、この問題の解決に向けて取り組んでおり、さまざまな理論や回避策を検証しています。私たちは、この問題の解決を支援し、その解決策を採用した製品のデモを行うことを約束します。6月も終わりに近づき、9月にはAlonzoのハードフォークが予定されています。開発者がこのSC消費のコンカレンシー問題の解決策をまとめるには、限られた日数しかありませんが、これを解決できたチームは、今後数ヶ月の間、優位に立つことができるでしょう。

参考文献

1. https://en.wikipedia.org/wiki/Concurrency_(computer_science)
2. https://medium.com/nervosnetwork/my-comparison-between-the-utxo-and-account-model-821eb46691b2
3. https://www.cs.stevens.edu/~ejk/papers/podc17a.pdf
4. https://iohk.io/en/blog/posts/2021/03/12/cardanos-extended-utxo-accounting-model-part-2/
5. https://ipfs.blockfrost.dev/ipfs/QmRkw1hRfdqPdZMpShDY9oEQQLeAywiY4ZaV9DC7qdDpdh
6. https://www.sundaeswap.finance/papers/SundaeSwap-2021-06-01-Fundamentals.pdf