Japan Smart ChainのMizuhikiを試してみた

Posted at 2025-08-13

はじめに

Japan Smart Chain（JSC）は対象が限定的ですがテストネットを公開しました。

JSCとは

Japan Smart Chain（JSC）は、Ethereum完全互換のレイヤー1（L1）ブロックチェーンであり、日本国内で日本の産業界のリーダーたちによってバリデートされています。また、日本の法規制および消費者保護に最適化されています。

Mizuhiki

JSC で最も注目されているのが、Mizuhiki スイートです。

[Mizuhiki スイートのデモについて］
今回公開したのは、Mizuhiki スイートの主要コンポーネントである「Mizuhiki アイデンティティ」のハンズオンデモです。エンジニアは同デモを通じて、規制対象のオンチェーン活動における「Mizuhiki アイデンティティ」の活用方法を学び、JSC上でコンプライアンスに準拠したアプリケーションを低コストで構築できるようになります。例えば、オンチェーンIDとプログラム可能なポリシー執行を組み合わせることで、ステーブルコインやDeFiをはじめとする規制対象のweb3サービスを、安全かつコンプライアンスに準拠して利用することが可能です。

Mizuhiki スイートのデモ

イベントで行われたデモを再現してみます。

Uniswap（Mizuhiki Verified SBTなし）

JSC の JETH を MJPY という認証が必要なトークンにスワップしてみます。

Mizuhiki Verified SBTを取得していないアカウントなので以下のようにエラーがでます。

Mizuhiki アイデンティティ

スマホのMizuhiki IDアプリにて、Mizuhiki アイデンティティを作成し、アカウントにMizuhiki Verified SBTを取得します。

アプリを起動し
「Sign Up」を押下

メールアドレスを入力し
「Continue」を押下

「Continue」を押下

マイナンバーカードのパスワードを入力し
「Continue」を押下

「Scan」を押下し、
マイナンバーカードを読み取ります。

マイナンバーカードをかざすとスキャンされます。

「Continue」を押下

「Connect Wallet」を押下

ウォレットを選択します。
ここではMetaMaskを選択

Metamask側で「接続」を押下

署名が求められるので、「Sign」を押下

Metamask側で「確定」を押下

承認されたアドレスが表示されます。

左の画像ではテストでやったアドレスが全て出ています。
実際は１つのアドレスが追加されます。

Uniswap（Mizuhiki Verified SBTあり）

Mizuhiki Verified SBT を取得したアカウントを利用して、JSC の JETH を MJPY という認証が必要なトークンにスワップしてみます。

確認画面が出るので、「Confirm Swap」を押下します。

ウォレットの承認待ちとなります。

ウォレット側（Metamask）にてトランザクションの要求に対して、「確認」ボタンを押下します。

トランザクションの確認されます。

ウォレット側にて MJPY にスワップ出来ていることが確認できます。

Mizuhiki Verified SBT

アカウントにMizuhiki Verified SBTを取得した時に何が起こっているのかを確認します。

コントラクトが公開されていないので、エクスプローラーで確認します。

トランザクションデータ

データが以下となります。

0x761c4c4000000000000000000000000005214f3d672e006bc27e80d99a740ba608e72de80000000000000000000000000000000000000000000000000000000000000002

意味は以下となります。

バイトコード	概要
`761c4c40`	関数
`00000000000000000000000005214f3d672e006bc27e80d99a740ba608e72de8`	パラメータ１
`0000000000000000000000000000000000000000000000000000000000000002`	パラメータ２

関数を Ethereum Signature Database で調べると、safeMint(address,uint8) となります。

safeMint(address,uint8) はカスタム関数だと思われます。

ログ（Logs）

ログ（イベント）を見ていきます。
ログは２つ出ていることがわかります。

１つ目のログは以下となります。

Topics
0 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
1 0x0000000000000000000000000000000000000000000000000000000000000000
2 0x00000000000000000000000005214f3d672e006bc27e80d99a740ba608e72de8
3 0x0000000000000000000000000000000000000000000000000000000000000015

Topics の 0 がイベントとなり、Transfer(address,address,uint256) であることがわかります。
これは、ERC-721 の token が mint された時に発生するイベントであると思われます。

２つ目のログは以下となります。

Topics
0 0x135ffb3383e06280e062ac5095bbf8faa98517161e596a2536bd98a9a8b64a88
1 0x000000000000000000000000c5e1b87e4034f76881ec721ab056015f0b87e049
2 0x00000000000000000000000005214f3d672e006bc27e80d99a740ba608e72de8
3 0x0000000000000000000000000000000000000000000000000000000000000015

Data
0x0000000000000000000000000000000000000000000000000000000000000002

Topics の 0 がイベントとなり、Issued(address,address,uint256,uint8) であることがわかります。
これは、ERC-5484 の Soulbound Token が発行された時に発生するイベントであると思われます。

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.0;

interface IERC5484 {
    /// A guideline to standardlize burn-authorization's number coding
    enum BurnAuth {
        IssuerOnly,
        OwnerOnly,
        Both,
        Neither
    }

    /// @notice Emitted when a soulbound token is issued.
    /// @dev This emit is an add-on to nft's transfer emit in order to distinguish sbt 
    /// from vanilla nft while providing backward compatibility.
    /// @param from The issuer
    /// @param to The receiver
    /// @param tokenId The id of the issued token
    event Issued (
        address indexed from,
        address indexed to,
        uint256 indexed tokenId,
        BurnAuth burnAuth
    );

    /// @notice provides burn authorization of the token id.
    /// @dev unassigned tokenIds are invalid, and queries do throw
    /// @param tokenId The identifier for a token.
    function burnAuth(uint256 tokenId) external view returns (BurnAuth);
}

ここで、Data を見ると、2が指定されています。
これは、BurnAuth において Both を指しています。

ドキュメントを確認すると、Credentials であることがわかります。

Burn Authorization
We want maximum freedom when it comes to interface usage. A flexible and predetermined rule to burn is crucial. Here are some sample scenarios for different burn authorizations:

IssuerOnly: Loan record

ReceiverOnly: Paid membership

Both: Credentials

Neither: Credit history

Burn authorization is tied to specific tokens and immutable after issuance. It is therefore important to inform the receiver and gain receiver’s consent before the token is issued.

トレース（Trace）

0xC5e1B87e4034F76881EC721AB056015F0b87E049 というEOAがトランザクションを送信しています。
0x606F72657e72cd1218444C69eF9D366c62C54978 に対して 0x761c4c40 （safeMint(address,uint8)）を CALL しています。

そのまま、0x6Df76797b6593Aeb37B154F03e668DFF3e02354a にたいして、0x761c4c40 （safeMint(address,uint8)）を DELEGATECALL しています。

0x6Df76797b6593Aeb37B154F03e668DFF3e02354a の内部で、0x6dF2F6241D637dB2a48AA289928D653b28A3c7Cb の 0xb7009613 （canCall(address,address,bytes4)）を STATICCALL しています。

このことから、

0x606F72657e72cd1218444C69eF9D366c62C54978 は Proxyコントラクトで、
0x6Df76797b6593Aeb37B154F03e668DFF3e02354a は ERC-721とERC-5484 の実装（implimentation）であると思われます。

0x6dF2F6241D637dB2a48AA289928D653b28A3c7Cb についてはあまり確証はありませんが、EOAがこの動作を実行可能であるかを判定する為に使用しているのではないかと想像します。

まとめ

Japan Smart Chain の Mizuhiki デモを実際に行い、内部を分析してみました。
認証済みの Mizuhiki アイデンティティから EOA を登録すると Consensual Soulbound Tokens（ERC-5484）が発行され、その有無で承認済みであるかを判定する仕組みであることがわかりました。

Consensual Soulbound Tokens の発行まではWeb2的ですが、シンプルな仕組みで良いと感じました。

以上

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up