Background

The progress of blockchain technology has been remarkable, providing new use cases across society in various fields such as finance, entertainment, and supply chain. However, there have been few attempts to leverage public blockchains from the perspective of mobility, and discussions about their applications are just beginning. At Toyota Blockchain Lab, we are conducting research on how to introduce mobility into public blockchains.

Motivation

In Toyota Mobility Concept announced in April 2023, we aim to integrate mobility with social systems in “Mobility 3.0”. In fact, most mobility exists in public spaces and facilitates movement through interactions with other vehicles, people, and external factors such as traffic lights and energy facilities. This means that mobility is not only a personal property but also a semi-public entity. Public blockchains designed to share states with a large number of people could be a powerful option to realize the Toyota Mobility Concept.

Concept

In the real world, we recognize mobility by integrating various information such as vehicle type, color, license plate, emblem, driving style, and driver’s expression. We believe that representing mobility digitally requires an overlay of the states of both the driver and the vehicle.

What are the benefits of interpreting mobility as a smart account on the blockchain?

• The overlay state improves programmability.

• A standard interface connects to various services.

• Tokenizing rights makes a car into a service entity.

The most extreme scenario suggested by these features is fully autonomous driving in the future. Autonomous mobility, which no longer requires human operation, can function as a completely independent service entity, with all rights being handled in the on-chain world.

Imagine a world where a car is almost equivalent to an account. Each car, including the one running in front of you, has its own account, connecting it to users and the world. This digital state mirrors how we interact with cars in the real world.

In this paper, we refer to such an account on the blockchain as a “MOA” (Mobility-Oriented Account). Based on the currently mainstream Account Abstraction standard ERC-4337 in Ethereum, we are exploring how to design MOA.

Design

One conventional approach to creating a blockchain account for a car is to store the private key of an Externally Owned Account (EOA) in it. However, this approach presents a significant challenge: if the private key is lost due to a failure of the in-car device, the account is lost. Additionally, EOAs can only have limited functionality on the blockchain. This requires other contracts to manage information about the car, which adds complexity to the system.

To address these challenges, we propose designing MOA based on ERC-4337. Account Abstraction separates the authentication process from key management, ensuring that the account itself is retained even if the private key is lost. This enables safer and more flexible account management.

Furthermore, by holding states that can be referenced externally, it becomes possible to manage information about the car (e.g., usage history and maintenance records) more transparently and efficiently.

Additionally, MOA allows operations to be executed with the approval of multiple entities, not just one. This enables various stakeholders, including car users, owners, manufacturers, dealers, and administrative agencies, to be involved in the approval process for transactions related to cars.

A unique aspect of ERC-4337 is the use of the CREATE2 opcode defined in EIP-1014, which allows the deterministic setting of an address before the account is deployed. This feature enables the bridging of existing vehicle ID systems with on-chain addresses asynchronously with the manufacturing process.

Architecture

The overall architecture of Account Abstraction, including the MOA contract we designed, is as follows.

Implementation

This section, we explain particularly important part of contracts. These contracts have been deployed on the Ethereum mainnet, so you can check detailed implementations on explorer.

MOA Contract

• Comply with ERC-4337.

• Permissions for each contract call can be configured, as changes to the state may require signatures from multiple stakeholders.

• References KeyToken Contract, a smart contract that represents various permissions related to car operations.

The MOA Contract has the following main properties.

It is distinctive for having the addresses of stakeholders including owners, manufacturers, and the vehicle itself, as well as mapping information for the KeyToken Contract.

Below, we will outline code snippet of distinctive processing code within the MOA contract. You can find our deployed contract here.

Signature Validation

This is ERC4337-compliant code, which derives the address from the transaction signature and verifies if it has execution permissions

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;

Snippet provided is based on ERC4337 core-team’s implementation under GPL3.0 license.

Permission Control

This function checks derived addresses from signature verification to ensure execution permissions for the specified User Operation’s 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;
            }
        }
    }

Key Token Contract

The features of the Key Token Contract are as follows:

• Complies with ERC-721 (NFT standard).

• Represents keys or “usage rights” of cars.

• Holds information about the owner and “usage rights” assigned to that owner.

The following are the main properties held by each KeyToken.

As mentioned above, KeyToken has a simple structure that only represents the usage rights of the car, but by inheriting and extending KeyToken Contract, it can be equipped with functions tailored to the specific use cases of the vehicle. You can find our deployed contract here.

The overall flow of operations, such as locking and unlocking by KeyToken, is illustrated below.

These operations require hardware control. For this purpose, a dedicated device that accesses the on-chain state of MOA and create transactions is necessary. We call this device as MOA-IVD(MOA In-Vehicle Device) in the following discussion.

Scenarios

To digitally represent mobility, it is important to handle basic operations such as unlocking the key and starting the engine digitally. For hardware operations, MOA-IVD refers to the state of MOA on the blockchain, which then sends signals to the car.

Basic Operations

Users use smartphone apps, etc., to present their addresses and rights represented by NFTs to MOA-IVD and perform hardware operations on the car, such as unlocking the key. These NFTs are recorded on the blockchain, and hardware operations of the car are realized through interactions between the user, car, and blockchain. This means that flexible digital rights can be exercised for hardware operations on mobility.

Granting Permissions

By packaging basic hardware operations, they can be expressed and granted as arbitrary permissions. For example, granting all operation permissions allows driving the car, while granting only the permissions to unlock/lock the trunk with an expiration date can enable the car to be used as a delivery receiving location.

Thus, by expressing car access as NFTs tied to MOA, permissions can be controlled simply by transferring NFTs. This allows handling “usage rights” digitally without being conscious of the hardware, making it easier for developers to realize services such as car sharing.

For the Future of Mobility

Mobility has both public aspects as social infrastructure and private aspects as a means of transportation and space. Achieving transparency and accessibility while balancing privacy is crucial to maximizing public benefit. Additionally, optimal decentralization will be required, ensuring a system with security that provides safety and scalability to handle a vast number of mobilities.

The possibilities of smart accounts on public blockchains enabled by Account Abstraction suggest that their applications are not limited to user wallets. MOA is one such application idea, envisioning a future where mobility becomes a service entity and integrates with social systems.

We are excited about new proposals from the Ethereum community, including EIP-7702. While there are many challenges to the mass adoption of practical smart accounts, we are pleased to contribute to their use cases as a mobility company.

About Toyota Blockchain Lab

Toyota Blockchain Lab is a virtual organization established in 2019 within the Toyota Group to promote the use of blockchain. Initially, our focus was on enterprise projects aimed at the traceability of materials and information. In recent years, we have expanded our activities to include public chain-related themes such as web3 and innovative finance.