モビリティをパブリックブロックチェーンに登場させるには？

技術的な観点から、ブロックチェーンとモビリティの新たな可能性を探求しています。

トヨタ・ブロックチェーン・ラボ　著

本ペーパーの執筆に際し、a42xおよびNTT DATAの技術的なサポートに感謝します。

2024/07/19

背景

ブロックチェーン技術の進歩は目覚ましく、金融のみならず、エンターテイメントやサプライチェーンに至るまで、社会広範に新たなユースケースを提供しています。ただし、モビリティそのものの観点からパブリックブロックチェーンを活かす試みは少なく、その応用については議論が始まったばかりです。私たちはトヨタ・ブロックチェーン・ラボとして、モビリティをどのようにブロックチェーンに登場させることができるか、研究を行なっています。

動機

トヨタは2023年4月に発表したトヨタモビリティコンセプトの中で、Mobility3.0のフェーズにおいてモビリティの社会システムとの融合を目指しています。事実、モビリティはそのほとんどが公共空間に存在し、他のモビリティや人、または信号機やエネルギー設備など、外部環境と相互に作用することでその移動を可能にしています。これはモビリティが個人の所有物であると同時に、半ば公共の存在であることを意味しています。不特定多数と状態を共有することを目的に設計されたパブリックブロックチェーンは、トヨタモビリティコンセプトを実現するための一つの有力な選択肢となる可能性があります。

コンセプト

私たちは実世界において、車種や色、ナンバープレートやエンブレム、運転の仕方や運転手の表情まで、様々な情報を統合してモビリティを認識しています。モビリティのデジタル表現とは、ドライバーがもつ状態と、クルマがもつ状態の重ね合わせであると考えています。

モビリティをブロックチェーン上のスマート・アカウントとして解釈することで、どのようなメリットがあるのでしょうか？

重ね合わせのステートを保持することで、プログラマビリティが向上する。
標準インタフェースにより、多様なサービスとつながるようになる。
権利のトークン表現により、クルマ自体がサービス主体になる。

これらの特徴が示唆する最も極端なケースは、未来の完全自動運転です。人による操作が不要となったモビリティは独立したサービス主体として振る舞うことができ、あらゆる権利はオンチェーン市場の中で流動化されることでしょう。

クルマがアカウントとイコールである世界を想像してください。あなたの目の前の道を走るクルマには１つのアカウントが存在し、アカウントを通じてユーザと、そして世界とつながっています。これは現実世界において私たちがクルマに対して行っていることが、デジタル世界でもより自然に行われている状態です。

以上のような性質をもつブロックチェーン上のアカウントを、本ペーパーではMOA(Mobility-Oriented Account)と呼んでいます。本ペーパーではイーサリアムで現在主流のAccount Abstraction標準であるERC-4337に基づいて、MOAを設計する方法を検討しています。

設計

自動車にブロックチェーン上のアカウントを持たせる従来型のアプローチとしては、自動車の車載器に外部所有アカウント(EOA)の秘密鍵を持たせることが考えられます。しかし、このアプローチには車載器の故障等による秘密鍵の損失時にアカウントが失われるという大きな課題が存在します。また、EOAはブロックチェーン上に限定的な状態しか持つことができず、自動車に関する情報を管理するために別途外部コントラクトの設計を必要とし、システムの複雑性をもたらすという課題もあります。

ERC-4337に基づいて MOAを設計することで、これらの課題を解決できる可能性があります。

Account Abstractionは、アカウントの操作権限と実体を分離し、秘密鍵を失った場合でもアカウント自体は保持され続けるようにすることで、より安全で柔軟なアカウント管理を可能にします。さらに、アカウントが外部から参照可能な状態を保持できるため、自動車に関する情報（例えば使用履歴やメンテナンス記録）をより透明かつ効率的に管理することが可能になります。

加えて、アカウント操作を1つの主体による承認のみならず、複数の主体による承認をもって実行できるようにすることも可能になります。これにより、自動車の利用者、所有者、メーカー、販売店、さらには行政機関など、幅広い関係者が自動車に関連する取引の承認プロセスに参加できるようになります。

最後にERC-4337にユニークな観点からいえば、EIP-1014で定義されているCREATE2 OPCODEによって、アカウントのデプロイ前に決定論的にアドレスが定まることも特徴の一つです。これにより、製造プロセスと非同期に、既存の車両IDシステムをオンチェーンの世界へと橋渡しすることが可能となるでしょう。

アーキテクチャ

今回設計したMOAコントラクトを含む、Account Abstraction全体のアーキテクチャを以下に示します。

実装

特に重要な部分についてその実装を説明します。これらのコントラクトはすでにEthereumメインネット上にデプロイされているため、詳細な実装をエクスプローラで確認することができます。

MOAコントラクト

ERC-4337に準拠。
状態の変更には複数の利害関係者からの署名が必要なため、各コントラクト呼び出しの権限を構成できます。
様々な車両操作に関連する様々な権限を表すスマートコントラクトであるKeyTokenコントラクトへの参照。

MOAコントラクトには次の主なプロパティがあります。

自動車自身を含む、所有者、メーカーの各ステークホルダーのアドレスを持ち、またKeyToken Contractのマッピング情報を持つ点が特徴的です。

以降に、MOAコントラクトにおける特徴的な処理のコードの抜粋を記載します。デプロイ済みのコントラクトはこちらで確認できます。

署名検証部分の抜粋

以下に署名検証部分のコードの一部を記載します。

ERC4337準拠のコードであり、トランザクションの署名からアドレスを導出し実行権限があるか検証しています。

function _validateSignature(PackedUserOperation calldata userOp, bytes32 userOpHash)
       internal
       virtual
       override
       returns (uint256 validationData)
   {
       // Derive the address from the signature
       bytes32 hash = MessageHashUtils.toEthSignedMessageHash(userOpHash);
       address derivedAddress = hash.recover(userOp.signature);

       // Allow only execute or executeBatch
       bytes4 selector = bytes4(userOp.callData[0:4]);
       if (selector == this.execute.selector) {
           // Decode the call data
           (address target,, bytes memory fnCallData) = _decodeExecute(userOp.callData);
           // Check if the user is allowed to call the function
           bytes4 fnSelector = _decodeFnSelector(fnCallData);
           return isAllowedToCall(fnSelector, target, derivedAddress) ? SIG_VALIDATION_SUCCESS : SIG_VALIDATION_FAILED;
       } else if (selector == this.executeBatch.selector) {
           // Decode the call data
           (address[] memory targets,, bytes[] memory fnCallData) = _decodeExecuteBatchCallData(userOp.callData);
           // Check if the user is allowed to call the function
           for (uint256 i = 0; i < targets.length; i++) {
               bytes4 fnSelector = _decodeFnSelector(fnCallData[i]);
               if (!isAllowedToCall(fnSelector, targets[i], derivedAddress)) {
                   validationData = SIG_VALIDATION_FAILED;

このスニペットは、ERC4337 core-teamの実装に基づいており、GPL3.0ライセンスによって管理されています。

権限管理部分の抜粋

以下に権限管理部分のコードの一部を記載します。

MOA Contractにおいては各関数ごとにパーミッションが設定されているため、署名検証によって導出されたアドレスがUser OperationのcallDataで指定された処理の実行権限を持つか検証します。

 function isAllowedToCall(bytes4 selector, address targetAddress, address derivedAddress)
        public
        view
        returns (bool)
    {
        if (targetAddress != address(this)) {
            return hasPermission(derivedAddress, EXTERNAL_CALL_CONTROL);
        } else {
            if (selector == this.setPermission.selector) {
                return hasPermission(derivedAddress, PERMISSIONS_CONTROL);
            } else if (selector == this.setKeyToken.selector) {
                return hasPermission(derivedAddress, KEY_TOKEN_CONTROL);
            } else if (selector == this.setOwner.selector) {
                return hasPermission(derivedAddress, OWNER_CONTROL);
            } else if (selector == this.setVehicle.selector) {
                return hasPermission(derivedAddress, VEHICLE_CONTROL);
            } else if (selector == this.setMaker.selector) {
                return hasPermission(derivedAddress, MAKER_CONTROL);
            } else if (selector == this.recover.selector) {
                return hasPermission(derivedAddress, RECOVERY_CONTROL);
            }
              //and more...
            else {
                return false;
            }
        }
    }

KeyTokenコントラクト

KeyTokenコントラクトの特徴は次のとおりです。

ERC-721（NFT標準）に準拠。
車両の鍵または「利用権利」を表します。
所有者とその所有者に割り当てられた「利用権利」に関する情報を保持します。

各KeyTokenがオンチェーン上で持つ代表的なプロパティを以下に示します。

KeyToken は上記の通り、自動車の利用権のみを表すシンプルな構造ですが、KeyToken Contract を継承・拡張することで車両の利用用途に合わせた機能を持たせることができます。デプロイ済みのコントラクトはこちらで確認できます。

KeyTokenによる施錠・開錠等の操作について全体フローを以下に図示します。

これらの動作では自動車というハードウェアを操作する必要があり、そのためにはオンチェーンのMOAの状態を参照したり、トランザクションを作成する専用デバイスが必要です。以降ではこの存在を仮定しMOA-IVD（MOA In-Vehicle Device / MOA 車載器）と呼びます。

シナリオ

モビリティをデジタル表現するためには、鍵の開錠やエンジンスタートなどの基本的な物理操作をデジタルで扱えるようにすることが重要です。ハードウェアの操作のために、MOA-IVDを通じてブロックチェーン上のMOAのステートを参照し、その結果として自動車への命令を行います。

基本操作

ユーザーはスマートフォンアプリなどを利用して、自身のアドレスと権利を表象するNFTをMOA-IVDに提示し、鍵の開錠など自動車の物理的な操作を行います。このNFTはブロックチェーン上に記録されたものであり、ユーザー/自動車/ブロックチェーンの間のやり取りだけで自動車の物理操作が実現されます。つまり流動性のあるデジタル権利がモビリティへの物理操作を行使できる状態で扱えることを意味しています。

権限の付与

基本的な物理操作をパッケージ化することで任意の権限として表現し、付与することが可能です。例えば、全ての操作権限を付与すれば自動車を運転可能になりますが、有効期限付きでトランクの解錠/施錠の権限のみを付与すれば配達荷物の受取り場所としても利用できます。

このように、自動車の利用権をMOAに紐づくNFTとして表現することで、NFTの移転だけで自動車の利用権を流通させることができます。これにより、ハードウェアを意識せずに利用権をデジタルで扱うことが可能となり、開発者はカーシェアリングなどのサービスをより簡易に実現できるようになります。

モビリティの未来のために

モビリティは、社会インフラとしての公共的な側面、移動手段や空間としての私的な側面の両方を兼ね備えています。透明性とアクセシビリティ、プライバシーの両立は、公益を最大化する上で目指すべき到達点です。また安全性を担保するセキュリティ、膨大な数の自動車を扱えるスケーラビリティをもつシステムを前提に、最適な分散性が求められるでしょう。

Account Abstractionが拓いたパブリックブロックチェーンにおけるスマート・アカウントの可能性は、その応用がユーザウォレットにとどまらないことを示唆しています。MOAはその応用アイデアであり、モビリティがサービス主体となる未来において、社会システムとモビリティが融合していくビジョンの１つです。

私たちはEIP-7702をはじめとする、イーサリアムコミュニティの新たな提案にワクワクしています。実用的なスマート・アカウントが普及するのには多くの課題がありますが、モビリティカンパニーとしてそのユースケースに貢献できることを嬉しく思います。