Web3.0の基盤言語:MoveはSolidityのどの不足を補っていますか?

国盛証券研究所
2022-12-30 15:15:05
コレクション
Move言語のリソースには四つの属性があります:複製可能、インデックス可能、破棄可能、保存可能。この四つの属性の異なる組み合わせにより、ユーザーは任意のタイプのリソースを簡単に定義できます。Solidityの資産はトークンコントラクトによってユーザーアカウントに付与される数値残高ですが、比較すると、Moveは間違いなく資産の安全性を高めています。

著者:宋嘉吉 任鹤义、国盛証券研究所

なぜSolidity言語に基づくEthereumエコシステムはこれほど巨大でありながら、市場は新しいパブリックチェーンに新たな期待を寄せているのか?Moveは大手(Meta)から生まれ、業界で広く期待されており、初期のMove言語で開発されたパブリックチェーンは市場の注目と資本の追随を受けている。Web3に向けたより豊かなアプリケーションを目指し、基盤となる言語の進化が基本であり、Moveにはどのような利点があり、Solidityのどの不足を補っているのか?これらの特徴に基づき、Moveエコシステムには新しいモデルや新しいアプリケーションが誕生する可能性がある。

既存のプログラミング言語であるSolidityに対して、Move言語は多くの詳細設計において配慮が行き届いており、ライブラリとアプリケーションロジックを分離している。最も際立った特徴はリソース型に関するものであり、リソース指向のプログラミングである。Dappアプリケーションのサポートにおいて、BitcoinのスクリプトとEthereumのスマートコントラクトの利点を取り入れているため、業界全体でこのプログラミング言語に対する期待が高まっている。また、Solidityが外部から批判されているセキュリティ問題に対して、Moveも解決を試みている。

Moveはリソース(resources)指向のプログラミング言語であり、Moveの世界ではリソースは「第一級市民」(first-class resource)である。その重要な特性はカスタムリソース型であり、リソースは決してコピーされたり、暗黙的に廃棄されたりすることはなく、プログラムのストレージ位置間でのみ移動できる。Solidityはリソース指向ではなく、ユーザーのアカウントは特定のトークン資産を所有しているが、それは単にそのトークンコントラクトがユーザーに割り当てた数値に過ぎない。

Moveが作成したトークンアカウント資産は唯一無二のリソース型であり、例えばアカウントAの資産はAアカウントに保存されている。これも数値であるが、コピー、廃棄、再利用はできず、安全に保存および移転できる。同時に、アカウント資産はそのリソースを定義したモジュールによってのみ作成および破棄されるため、同質的な数値型資産が引き起こす可能性のある再入や二重支払い、アカウント残高の不均衡を回避できる。この点において、Moveのアカウント資産はBitcoinのUTXOメカニズムに似ており、トークンは単なる同質的な数値ではなく、区別可能なものである。

より柔軟なビジネスを実現するために、Moveはさらに4つの権限属性を定義している:コピー可能(copy)、廃棄可能(drop)、保存可能(store)、検索可能(key)。これら4つの属性は任意に組み合わせてリソースの属性を定義でき、ユーザーが柔軟に操作できるようにする。例えば、drop+store+keyの組み合わせでは、定義されたリソースはコピーできず、コピーによって引き起こされるトークンの増発や二重支払いの問題を回避できる。この点はNFTやBitcoinのUTXOメカニズムに似ている。

モジュール化とコントラクトの組み合わせに関して、Moveはモジュールとスクリプトの設計を使用し、リソースを渡すことでコントラクト間の相互作用を実現している。Solidity(Ethereumなど)のContractコントラクトはライブラリ(静的ライブラリに相当)を通じてメッセージを伝達し、Contractコントラクト間の呼び出しや相互作用を実現している。一方、Move言語はモジュール(module)とスクリプト(script)の設計を使用し、前者はContractコントラクトに似ており、Move言語のコントラクトの組み合わせはモジュール間の組み合わせを通じてリソースを渡すことによって実現される。組み合わせに関して、SolidityとMoveの違いは非常に明確である。

取引実行に関して、Moveの並行処理はSolidityに対してブロックチェーンの性能を大幅に向上させる。並行実行(PE)は独立した取引を識別し、同時に実行することで、ブロックチェーンの拡張性を大幅に向上させる。Solidityは並行処理をサポートしておらず、Ethereum上の取引は順番に実行され、他の取引は一時停止(並べ替え)状態に置かれるため、mempool(メモリプール)やMEV市場が生じる。Moveに基づくパブリックチェーンAptosは、Block-STM(Software Transactional Memory)エンジンを利用して並行処理を実現し、性能の明らかな向上をもたらしている。

一:核心的な見解

Moveは大手(Meta)から生まれ、業界で広く期待されており、期間中にMove言語で開発されたパブリックチェーンは市場の注目と資本の追随を受けている。なぜSolidity言語に基づくEthereumエコシステムはこれほど巨大でありながら、市場は新しいパブリックチェーンに新たな期待を寄せているのか?Moveが持つ利点は、Solidityのどの不足を補っているのか?これらの特徴に基づき、Moveエコシステムには新しいモデルや新しいアプリケーションが誕生する可能性がある。

この記事では、SolidityとEVMの不足を比較し、Moveの利点と特徴を分析する。

二:なぜMoveを発明したのか:Solidity(Ethereum)のどの問題を補うのか?

MoveはMeta(旧Facebook)社がそのDiemプロジェクト(最初はグローバルステーブルコインプロジェクトLibra)向けに開発した安全で信頼性の高いスマートコントラクト言語であり、Aptos、Suiなどの新しいパブリックチェーンはまさにMoveプログラミング言語を使用している。これらのパブリックチェーンはMoveの利点とその並行処理特性に注目しており、単一のチェーンの限界を拡張することができる。MoveはRustに基づくプログラミング言語であるが、Moveはスマートコントラクトに特化して開発されており、主にリソースを操作するために使用されるため、入門のハードルはRustよりも低い。

スマートコントラクトに特化しているため、Rustの余分な操作を削除し、よりシンプルになっている。SolidityとEVMのいくつかの不足を補うために、Moveはいくつかの最適化を行い、Moveに基づくDappアプリケーションにはより多くの柔軟なプレイが可能となっている。

既存のプログラミング言語であるSolidityに対して、Move言語は多くの詳細設計において配慮が行き届いており、ライブラリとアプリケーションロジックを分離している。最も際立った特徴はリソース型に関するものであり、リソース指向のプログラミングである。Dappアプリケーションのサポートにおいて、BitcoinのスクリプトとEthereumのスマートコントラクトの利点を取り入れているため、業界全体でこのプログラミング言語に対する期待が高まっている。また、Solidityが外部から批判されているセキュリティ問題に対して、Moveも解決を試みている。

image

2.1.第一級リソースとデジタル資産(first-class resource)

その背景にマッチして、Moveはリソース(resources)指向のプログラミング言語であり、リソースはMoveの世界で「第一級市民」(first-class resource)である。その重要な特性はカスタムリソース型であり、リソースは決してコピーされたり、暗黙的に廃棄されたりすることはなく、プログラムのストレージ位置間でのみ移動できる。リソースは従来の型のようにデータ構造に保存でき、パラメータとして渡すこともできる。

簡単に言えば、これは従来のプログラミング言語における随意に破棄できない新しいデータ型である。Solidityで定義された資産と比較すると、Ethereum上の特定のトークンアカウントは、資産は単なる数値であり、2つのアカウント間で送金が行われると、アカウント資産の数値が相応に変化するが、異なるアカウント資産の違いは数値残高に過ぎず、本質的な違いはない(つまり、資産は同質的である)。

また、注意が必要なのは、例えばEthereum上のERC20トークンTokenAは独立したコントラクトアカウントであり、このコントラクトはユーザー(アカウントアドレス)に数値を割り当て、ユーザーが所有するToken Aの数量を表すものである。この点から見て、Solidityはリソース指向ではなく、ユーザーのアカウントは特定のトークン資産を所有しているが、それは単にそのトークンコントラクトがユーザーに割り当てた数値に過ぎない。

一方、Moveが作成したトークンアカウント資産は唯一無二のリソース型であり、例えばアカウントAの資産はAアカウントに保存されている。これも数値であるが、コピー、廃棄、再利用はできず、安全に保存および移転できる。完全に正確ではない比喩を用いると、Aアカウントの資産は他のアカウントの資産とはある意味で完全に同質ではないと考えることができる。

同時に、アカウント資産はそのリソースを定義したモジュールによってのみ作成および破棄されるため、同質的な数値型資産が引き起こす可能性のある再入や二重支払い、アカウント残高の不均衡を回避できる。この点において、Moveのアカウント資産はBitcoinのUTXOメカニズムに似ており、トークンは単なる同質的な数値ではなく、区別可能なものである。

より柔軟なビジネスを実現するために、Moveはさらに4つの権限属性を定義している:コピー可能(copy)、廃棄可能(drop)、保存可能(store)、検索可能(key)。これら4つの属性は任意に組み合わせてリソースの属性を定義でき、ユーザーが柔軟に操作できるようにする。例えば、drop+store+keyの組み合わせでは、定義されたリソースはコピーできず、コピーによって引き起こされるトークンの増発や二重支払いの問題を回避できる。この点はNFTやBitcoinのUTXOメカニズムに似ている。

このように理解できる。Ethereum(Solidity)の資産は対応するコントラクトによって制御されている。もしToken Aコントラクトを金庫に例えるなら、金庫はすべてのユーザーに数値残高を割り当て、ユーザーが所有するToken A資産の数量を表現するが、資産自体はToken Aコントラクトの金庫内に保管されている。一方、Moveのユーザーアカウント自体が独立した大きな金庫であり、ユーザー自身が制御し、すべてのトークン資産がこの金庫内に保管されている。これらのトークンは数値の形で存在するのではなく、コピーできない、ユーザーが制御する権限を持つリソース(型)である。

Move言語におけるリソースの定義と権限は分離されており、リソースの権限はユーザーに属する。Solidityではアカウントリソースの権限はコントラクトに帰属する。例えば、Ethereum上のあるERC20トークンは対応するコントラクトに属し、ユーザーがDEX(分散型取引所)でToken A(Token Aのコントラクトに権限がある)をToken B(Token Bのコントラクトに権限がある)に交換する際、Uniswapコントラクト内で自分のA資産を直接B資産に交換することはできない------なぜならUniswap内の資産の権限はそのコントラクトに属しているからである。

実際のプロセスは少なくとも3つの取引操作を必要とする:i)まずUniswapコントラクトに対して承認(approve)を行い、UniswapコントラクトがユーザーのAコントラクトの資産を引き出すことを許可する;ii)Uniswapコントラクトに入って交換を行い、Aを引き出した後にBをアカウントに保存する;iii)承認を取り消す(revoke)。しかし、ユーザーは一般的に交換を完了した後すぐに承認を取り消すことはなく(後続の交換行為のためにガス費用を節約するため)、一旦Uniswapコントラクトが攻撃を受けたり、脆弱性が発生した場合、ユーザーのAトークンアカウントにリスクをもたらすことになる。承認/取り消しはEthereum上でコントラクト操作を実行する必要があり、そのためにガス費用が発生する。

ここから、Token A、Token B、Uniswap内のLP資産の権限がそれぞれのコントラクトに分かれていることが明確にわかる。ユーザーは1つのアカウントを通じて3つのコントラクト間で自由に切り替えることはできない。一方、Moveの資産大アカウントはコントラクト間の承認を必要とせず、権限はユーザーに属している。ユーザーはDEX内でAを引き出し、Bに交換してアカウントに保存することができ、このプロセスは1つの取引操作で完了し、承認/取り消し操作は不要であり、ある程度セキュリティが向上している。

image

2.2.Move言語のモジュール化と柔軟な組み合わせ性

以前の深層レポート『Web3.0時代:オープン、プライバシー、共創』では、Web3.0とWeb2.0の大きな違いはオープン性と可組み性であると提起した。このようなオープンな呼び出しは、基盤からどのように実現されるのか?Move言語はどのような便利さを提供するのか?

モジュール化とコントラクトの組み合わせに関して、Solidity(Ethereumなど)のContractコントラクトはライブラリ(静的ライブラリに相当)を通じてメッセージを伝達し、Contractコントラクト間の呼び出しや相互作用を実現している。一方、Move言語はモジュール(module)とスクリプト(script)の設計を使用し、前者はContractコントラクトに似ており、Move言語のコントラクトの組み合わせはモジュール間の組み合わせを通じてリソースを渡すことによって実現される。組み合わせに関して、SolidityとMoveの違いは非常に明確である。

トークンコントラクトの展開を例にとると、Solidityのトークンはサービスとして存在し、残高を照会できるが、Moveのトークンはリソースであり、上記のように「決してコピーされたり、暗黙的に廃棄されたりすることはなく、プログラムのストレージ位置間でのみ移動できる」。この2つの違いは、こう比喩できる:Solidityに基づくコントラクト間の呼び出しはメッセージサービスを通じて行われ、各種インターフェースの呼び出しのようなものであり、Solidity上のコントラクトの相互作用は2つの原始的な部族間の貿易交流のようなものである。2つの部族間の往来を便利にするために、製造ツールや製作方法などの標準情報を統一する必要がある------つまり、2つのコントラクト間の状態を同期させ、相互作用を実現する。

A部族が石斧を発明した場合、その石斧の材料基準や製作方法などの情報をB部族に伝え、B部族が自ら生産する(これはToken AとToken Bがそれぞれのコントラクトによって制御されることに相当する)。ここで注意すべきは、安全のためにコントラクトは隔離状態を保ち、メッセージサービスのみを伝達できるが、メッセージサービスは明らかにコピーされたり、廃棄されたりする可能性がある(石刻情報を消去すること)。

もしあるコントラクトがアップグレードされると、EthereumのNFTインターフェース標準ERC 721、ERC 721A、ERC4907などの一連の最適化アップグレードのように、A部族が鉄器を発明した場合、メッセージサービスを通じて相手部族に生産設定の更新を通知する必要がある。あるコントラクトのアップグレードには、そのコントラクトを呼び出した他のコントラクトが状態を同期させ、アップグレードに従う必要がある。この作業フローは間違いなく複雑さを増し、Ethereumコントラクトのアップグレードの反復も同様に複雑であり、EVMのバイトコードの膨張をもたらす。

Moveの世界では、コントラクトの相互作用はより柔軟な組み合わせ性を持つ。上記の比喩を用いると、Moveのモジュール(module)間の相互作用(部族間の取引)はリソースを渡すことによって実現される。この最適化は技術の進化に相当し、A部族はB部族に生産ツールの設定情報を通知するのではなく、必要に応じて生産ツール(石斧でもアップグレードされた鉄器でも)を適切なモデルの標準輸送車に封入し、相手は生産設定をアップグレードする必要はなく、毎回単に車両を受け取るだけで済む。

言い換えれば、Moveのモジュール間の相互作用で伝達されるのはメッセージではなく、単に輸送車両(これはリソースであり、決してコピーされたり、暗黙的に廃棄されたりすることはなく、プログラムのストレージ位置間でのみ移動できるリソース)を伝達する。疑いなく、このモデルはより柔軟な組み合わせ性を持ち、受取人は車両を受け取ると保存することも、他の者(他のコントラクト)に転送することもでき、さらには車両の貨物を降ろして異なる車両に分装することもできる。つまり、あるMoveモジュールのアップグレードは、そのモジュールを使用した他のコントラクトが自動的に最新の状態にアップグレードされる。

2.3.Web3のセキュリティの改善

Move言語がもたらすセキュリティの改善は多方面にわたる。

Move言語のリソースには4つの属性がある:コピー可能、索引可能、廃棄可能、保存可能。これら4つの属性の異なる組み合わせにより、ユーザーは任意のタイプのリソースを簡単に定義できる。Solidityの資産はトークンコントラクトによってユーザーアカウントに与えられる数値残高であるのに対し、Moveは無疑に資産のセキュリティを向上させている。

Solidityの資産は対応するトークンコントラクトによってユーザーに与えられる数値である。一方、Moveはリソースが所有者のアカウントによって制御されるモジュールに保存されることを規定しており、リソースの所有者は最高の決定権を持ち、所有者のみがリソース(Resource)の保存と移転を決定できる。操作権限の分離により、異なるシーンで異なる権限を定義できることが、セキュリティの一面でもある。

Moveのリソース設計により、デジタル資産の移転はアカウント間の残高数値の単純な加減算ではなく、ストレージ位置間の移動(コピー不可、廃棄不可)となり、再入や二重支払い攻撃を回避できる。再入とは、ハッカーがコードの脆弱性を利用し、悪意のあるコントラクトを作成し、ユーザーが送金する際に再度送金関数を呼び出す(再入)ことで、アカウント残高を変更せずに資金を引き出すことを指す。Solidity言語のトークンコントラクトの割り当て方案では、再入攻撃や二重支払いのリスクが非常に高い。

さらに、Moveのモジュール作業モードはシステムリスクを大幅に低下させる------前述のように、Solidityコントラクトのアップグレードには他のコントラクトが相応のアップグレードを行う必要があり、そうでなければセキュリティ上のリスクをもたらすが、Moveのコントラクトのアップグレードは非常に簡単で、対応するコントラクト自身のアップグレードのみで済み、他のコントラクトが更新を行う必要はない。これにより、コントラクトのアップグレードが遅れることによるセキュリティリスクをある程度回避できる。

image

2.4.Moveの並行処理がもたらすより高い拡張性

取引実行に関して、Moveの並行処理はSolidityに対してブロックチェーンの拡張性を大幅に向上させる。並行実行(PE)は独立した取引を識別し、同時に実行することで、ブロックチェーンの拡張性を大幅に向上させる。Solidityは並行処理をサポートしておらず、Ethereum上の取引は順番に実行され、他の取引は一時停止(並べ替え)状態に置かれるため、mempool(メモリプール)やMEV市場が生じる。関連のない2つの取引が並行処理できれば、高効率かつ拡張可能である。

Moveに基づくパブリックチェーンAptosは、Block-STM(Software Transactional Memory)エンジンを利用して並行処理を実現し、性能の明らかな向上をもたらしている。その作業理念はEthereumのレイヤー2ネットワークのOptimistic Rollup(楽観的ロールアップ)に似ており、取引はブロック内で事前に並べ替えられ、取引間に依存関係がないと仮定し、楽観的に並行取引を実行する。

実行後、すべての取引結果を検証し、ある取引が先行取引によって変更されたメモリ位置にアクセスした場合、その取引は無効となる------明らかに2つの取引は関連しているからである。取引結果を更新し、再度取引を実行する。このプロセスを繰り返し、ブロック内のすべての取引が実行されるまで続ける。Block-STMの特徴は、比較的複雑なトランザクションをサポートし、さまざまなアプリケーション負荷条件に適している。

以下の図は、Block-STMとブロックを取引順に実行した場合を比較したものである。各ブロックには1万件の取引が含まれており、アカウント数はブロック処理の取引の競争の複雑さを決定する。低競争と高競争の状況下で、Block-STMは順次実行の方案に対して8-16倍の加速を実現した。取引タスクが順次である場合、Block-STMの消費も少なくなる。このように、Moveがもたらす並行性能は非常に際立っている。

このように、L2(レイヤー2)以前に、メインチェーンの並行処理能力もパブリックチェーンの拡張を積極的に考慮すべき方案である。これにより、Moveエコシステムにはさらなる可能性がもたらされる。 リスク提示 ブロックチェーンビジネスモデルの実現が期待に及ばないリスク:ブロックチェーン、暗号学などの関連技術やプロジェクトは発展初期にあり、ビジネスモデルの実現が期待に及ばないリスクが存在する。

規制政策の不確実性:ブロックチェーンプロジェクトの実際の運営過程で、複数の金融、ネットワークおよびその他の規制政策が関与しており、現在各国の規制政策は研究と探索の段階にあり、成熟した規制モデルは存在しないため、業界は規制政策の不確実性のリスクに直面している。

ChainCatcherは、広大な読者の皆様に対し、ブロックチェーンを理性的に見るよう呼びかけ、リスク意識を向上させ、各種仮想トークンの発行や投機に注意することを提唱します。当サイト内の全てのコンテンツは市場情報や関係者の見解であり、何らかの投資助言として扱われるものではありません。万が一不適切な内容が含まれていた場合は「通報」することができます。私たちは迅速に対処いたします。
チェーンキャッチャー イノベーターとともにWeb3の世界を構築する