【速攻解説】「Progmat Coin」、”検討段階”ではなく、マルチチェーン上のスマートコントラクト実装完了段階ですという話（技術ポイントまとめ）
こんにちは、プログラマブルな信頼を共創したい、Progmat(プログマ)の齊藤です。
2024年5月31日に、本年7件目のプレスリリースを発信しました。
タイトルは、「ステーブルコイン事業協業による、標準機能のコントラクト共同開発完了およびテストネット環境における複数ブロックチェーン間の移転取引成功について（Progmat-and-Datachain-Collaborate-on-Stablecoin-Business-Completion-of-Joint-Development-of-Contracts-for-Standard-Features-and-Successful-Transfers-in-Testnet）」です。
プレスリリース等を実施したイベント週では、
情報解禁後いち早く正確に、背景と内容についてこちらのnoteで解説しています。
ということで、通算25回目の本記事のテーマは、
「【速攻解説】「Progmat Coin」、”検討段階”ではなく、マルチチェーン上のスマートコントラクト実装完了段階ですという話（技術ポイントまとめ）」です。
結論
時間のない方向けに、端的に結論をまとめると以下のとおりです。
「Progmat Coin」は、「発行基盤」（as a Service）の名前で、マルチチェーン前提、グローバルな標準規格に準拠するDAppsです。
グローバルでも先進的な「Burn-Mint方式」のクロスチェーン移転を実装しています。
米Circle社が実装している「CCTP」よりもオープンなプロトコルである「IBC」をサポートしています。
”SCの発行を共同検討”といった段階は既に終えており、具体的な”実装段階”であるだけでなく、グローバル目線でも最先端の内容で”実装完了”している段階です。
いま、連名で、発表した意味があります。（伏線です…）
では、順番に解説していきます。
前提、「Progmat Coin」とは改めて。
あらためての前提ですが、「Progmat Coin」に関するポイントは以下のとおりです。
「Progmat Coin」はステーブルコイン(SC)の銘柄/ブランド名ではなく、規制準拠でSCを発行するための「発行基盤」の名前（as a Service）
「発行基盤」≠独自チェーン（ガラパゴスな仕組みをつくらない）
「発行基盤」＝DApps（分散型アプリケーション）
DApps＝以下の3つの構成
各種パブリックチェーン上のスマートコントラクト（スマコン）
発行体が業務を行うためのアプリケーション（業務アプリ）
業務アプリ＜＞スマコンを繋ぐウォレット
対応するパブリックチェーンは、Ethereumだけでなくマルチチェーン前提、グローバルな標準規格に準拠
自社ブランドのSC発行を希望する事業者の皆様は、法的な発行の器となる信託銀行と連携し、JPYだけでなく、USDやEUR建てのSCを発行することが可能
ここらへんは、「よくある誤解と中の人の解説」として公開済みですので、再掲です。
「Progmat Coin」の実装方式と設計思想
実装方式を理解するうえでポイントになるのが、前提となる設計思想です。
つまり、実現方法には様々な選択肢がある中で、何を重視するか（重視しないか）？、その背景にどんな価値観があるか？、が重要です。
ソフトウェアであれ法律であれ、1行ずつコードや条文を読む前に、どんな設計思想の下でアウトプットされているのかを理解すると、行間を含めて理解しやすいといえます。
では、「Progmat Coin」における設計思想（≒価値観表明）はどのようなものでしょうか？
端的にいうと、「流動性を最大化するための最適な設計とする」です。
ステーブルコインの”プログラマブルマネー”としての特徴は過去に再三解説してきたとおりですが、マネーである以上、最大のユーティリティはいつでもどこでも取引できること（＝流動性が高いこと）である点は不変だと考えています。
「この取引では●●マネーは使えないんですよー」
「●●マネーと●●マネーは交換できないんですよー」
「●●マネーは換金するためにXXしてYYしないといけないんですよー」
どれほど高尚なプログラマビリティやセキュアな利用者保護の仕組みを有していたとしても、上記のような”流動性がない”マネーは、そもそも誰も使わないですよね（＊キャンペーン期間を除く）、というシンプルな価値観です。
では、ブロックチェーン上のトークンであるSCにおいて、「流動性を最大化する」ための必要条件は何でしょうか？
色々考えられますが、Progmatチームとしては少なくとも、
「利用者に、ブロックチェーンの違いによる制約を意識させない」
（どんなチェーン上でも制約なくSCを移転できる）
が最低限必要だと考えました。
前提として、
いずれ全てのユースケースが１つのブロックチェーンに収斂するならば別ですが、ブロックチェーンにはトリレンマ（＊分散化、セキュリティ、スケーラビリティの同時実現は困難であること）がある以上、どの要素を強めてどの要素を弱めるかは各チェーンの設計思想により異なり、ユースケース毎に重要視する要素が異なる以上、ユースケースに応じて複数のチェーンが併存する未来が現実的、という考えがあります。
（少なくとも本記事執筆時点の齊藤私見）
こうした前提認識と設計思想の下、「Progmat Coin」の実装方式の中でも特徴的なものが、次の２点です。
「Burn-Mint方式」でのクロスチェーン機能を有していること
「IBC」のプロトコルを用いていること
…だんだんテクニカルになってきましたね。
以下の解説から更にブロックチェーンっぽくなりますが、できるだけ分かりやすく解説します。
「Burn-Mint方式」vs「Lock-Mint方式」
そもそも、”クロスチェーン機能”とは何？ですが、異なるブロックチェーン間でトークンを移転するための機能を指しており、「ブロックチェーンの違いによる制約を意識させない」ために重要な実装です。
代表的な実現方法として、以下の２方式があります。
「Lock-Mint方式」
移転元となるブロックチェーンA上で「トークンX」をLock（＊特定のスマートコントラクト上で使用不可の状態にしておくこと）
移転先となるブロックチェーンB上で同量の「トークンX’」をMint（＊新たに生成されること）
「トークンX’」は”Wrapped Token”と呼ばれ、元のチェーン上でLockされている”Native Token”に基づいて発行される仮トークンであり、必ずしも"Native Token"と同等のユーティリティ等を有しているとは限らない
「Burn-Mint方式」
移転元となるブロックチェーンA上で「トークンX」をBurn（英語的には”焼却”の意味ですが、日本語的には”消却”の文字を当てた方が理解しやすいと思います）
移転先となるブロックチェーンB上で同量の「トークンX」をMint
いずれも”Native Token”であり、特に不自由なく利用可能
では、前述の「Progmat Coin」の設計思想を踏まえると、どちらを採用すべきでしょうか？
私たちは、「Burn-Mint方式」を選択しました。理由は次の２点です。
「Burn-Mint方式」の優位性（＝「Lock-Mint方式」の課題の裏返し）
①利用者にとって利便性が高い
「Lock-Mint方式」でMintされる"Wrapped Token"は"Native Token"ではないため、様々な制約が生じる
例えば、チェーンA→チェーンBに移転した後、さらにチェーンB→チェーンCに移転したいができない、といった状況
「Burn-Mint方式」では、いずれのチェーン上でも”Native Token”が存在することで、上記のような制約は生じない
②利用者にとってリスクが低い
「Lock-Mint方式」では、Lock中の"Native Token"が失われると、連れ立って”Wrapped Token”側の価値も失われるリスクを常に内包している
例えば、Lock中のスマートコントラクトのバグや、当該コントラクトの基にあるチェーンの脆弱性等により、不正な移転（いわゆる流出）が生じる、といった状況
こうしたチェーンやコントラクトの強度の違いにより織り込むべきリスクも異なるため、”Wrapped Token”の価値と”Native Token”の価値が常に正確に一致するのか？という点も論点となり、特に法定通貨との価値連動/ペッグが生命線であるSCにおいては、致命傷になりえる
「Burn-Mint方式」では、Lockされる”Native Token”が存在しないため、上記のようなリスクは生じない
③アセットとしての資本効率が高い
「Lock-Mint方式」では、クロスチェーン移転が生じる量に応じてLockされるアセット量が増大し、資本効率が悪い
「Burn-Mint方式」では、Lockされる”Native Token”が存在しないため、常にアセットを市場で流動的に利用可能であり、資本効率が高い
では、「Progmat Coin」（as a Service）を利用して発行される各種SCが「Burn-Mint方式」でクロスチェーン移転を実現できるとして、”グローバルスタンダード”の目線で見たときに、相対的にどのように評価できるでしょうか？
一言でいえば（手前味噌で恐縮ですが…）、「グローバルでも先進的」といえると考えています。
なぜなら、客観的なファクトは以下のとおりだからです。
（本記事執筆時点の齊藤認識ベース）
数多ある既発のSCの中で、「Burn-Mint方式」でのクロスチェーン移転が可能なSCは「USDC」（米Circle社）のみ
「USDC以外」のSCについては、上記「Lock-Mint方式の課題」を抱えたまま
「USDC」の初回発行（Day1）が2018年9月、「Burn-Mint方式」に対応したのが2023年4月、約4.5年のブランク
「Progmat Coin」を介して発行される各SCは、”Day1からトップクラスのクロスチェーン移転が実現できる世界初のSC”といえます。
「Burn-Mint方式」に「IBC」を用いる
逆にいうと、「USDCと同質」なのでしょうか？
こちらはやや将来含みの話になりますが、「Progmat Coin」では「IBC」を用いたブロックチェーン間通信を想定しており、これは現在「USDC」が実装しているブロックチェーン間の連携方法よりも優位性があります。
Pros-Consを理解するために、まずは「USDC」における実現方法（「クロスチェーン転送プロトコル」＝「Cross-Chain Transfer Protocol」＝「CCTP」）を超ザックリ確認しましょう。
まず「CCTP」を理解する
※詳細に知りたい方は、リンク先の引用元記事をご覧下さい（＊英語です）
「CCTP」におけるブロックチェーン間の連携方法
①ブロックチェーンAからブロックチェーンBに「USDC」を転送したい利用者が、「CCTP-Integrated dApp（CCTP統合アプリ）」 に 「USDC」 を入金し、チェーンB上の転送先アドレスを指定する
「CCTP統合アプリ」 は、チェーンA上で指定された 「USDC」 量をBurnする
Circle社が「CCTP統合アプリ」でのBurnイベントを監視しており、 「CCTP統合アプリ」からの検証要求を受けてCircle社が認証する（Attenstation Service）
Circle社の認証を条件として、「CCTP統合アプリ」 はチェーン B 上で USDC をMintし、指定先ウォレットに移転
図からも明らかなとおり、「CCTP」による価値移転の前提として、認証サービスを提供するCircle社への一定の信頼が前提となります。（いわゆる、”ブリッジおじさん”役）
性善説に立って誤った検証はなされない、と割り切ったとしても、当該認証サービスの運用上の課題で稼働停止期間が発生すると、たちまちクロスチェーン移転も止まってしまうことになるため、少なくともCircle社の運用が止まることはないと信じる必要はあります。
SCを含むRWAトークンは、紐づけられた裏付資産の価値を表章しているデータに過ぎないため（実は裏付資産ありませんでした！となると価値はゼロ）、そもそもトークン発行元へのトラストが前提にはなっています。
とはいえ、ひとたびトークンになった後の移転処理に関しては、極力トラストポイント（単一障害点）を置かずに済む、安全な実現方式が理想である点は、わざわざブロックチェーンを活用する立場からすると異論はないのではないでしょうか。
そこで登場する、”ブリッジおじさん”に頼らない方法の1つが「IBC」です。
「IBC」について、超ザックリ確認しましょう。
次に「IBC」を理解する
※詳細に知りたい方は、リンク先の引用元解説ページをご覧下さい（＊英語です）
「IBC」とは
「Inter-Blockchain Communication」＝「ブロックチェーン間通信」
第三者への新たな信頼を必要とせずにブロックチェーン間通信を実現する、安全性/信頼性の高いプロトコル（インターネットでいうTCP/IP的なイメージ）
クロスチェーンを行う双方のブロックチェーンで検証し合う方式（Light Client & Relay方式）
「Relayer」：転送元のブロックチェーンAの情報をクエリして、転送先のブロックチェーンBにTxを送る通信仲介役
「Light Client」：各BC上で受領データの正当性を検証する役
2021年のローンチから3年間でハッキング被害はゼロ
2024年5月時点で10億超/月の取引利用実績
…素晴らしい。ブロックチェーン間通信の標準にふさわしい。
ではなぜ、世の中の全てのクロスチェーンが「IBC」で統一されていないのか？というと、そのままではいくつか”チャレンジ”もあるから、と理解しています。
「IBC」のチャレンジ
①拡張する難易度が高い
各ブロックチェーンに対応した検証用の「Light Client」を実装する仕組み上、対応するチェーンが増えるとN：Nで組み合わせ爆発が起きてしまい、実装難易度が高い
②検証コストが高い
各ブロックチェーン上で検証コントラクトを動かす仕組み上、Ethereum等のEVMチェーンでGas Costが大きな負担になってしまう
そこで、これらの「IBC」特有のチャレンジを解決するのが、「LCP」です。この「LCP」の開発者が、今回「Progmat Coin」のスマートコントラクトの共同開発者として発表した、Datachain社です。
（こうした背景から、Datachain社はProgmat設立時から株主＝アライアンスパートナーとして参画いただいています）
では、「LCP」について超ザックリ確認しましょう。
最後に「LCP」を理解する
※詳細に知りたい方は、リンク先の引用元解説ページをご覧下さい
「LCP」とは
「Light Client Proxy」
チェーン間の通信プロトコルは「IBC」をサポート
「Proxy（プロキシ）方式」を採用
接続元のチェーンAの代わりに、接続先のチェーンBに対するLight Client検証を行い、検証元のチェーンA側でその妥当性を検証する
”代理検証”を行うのが「LCP node」
「LCP node」から送られてくる検証結果を検証するのが「LCP Client」
「TEE （Trusted Execution Environment）」を用いる
「LCP note」の実行環境として「TEE」を用いる
「TEE」は、OSとは独立したプロセッサ内の隔離された保護領域
例えば、インテルの「SGX（Software Gard Extension）」等
ややテクニカルなので、ハイライトしたキーワードを念頭に置きつつ、順を追ってポイントを解説していきます。
まず、「Proxy（プロキシ）」についてです。
「IBC」のチャレンジの1つが、"対応するチェーンが増えるとN：Nで組み合わせ爆発が起きてしまい、実装難易度が高い"でした。これは上の図表左で「直接検証型」と表現しているものです。
これに対して、「プロキシ型」では、”代理”という名のとおり、各BCの「Light Client」に対応した「ハブシステム」が検証の肩代わりを行い、各BC上の「Light Client」では「ハブシステム」の検証結果の検証を行う、”ハブ＆スポーク型”のネットワーク構成を想定します。
図からも明らかなとおり、この構成により前述の「IBC」の”チャレンジ”2点を解決することが可能です。
①拡張する難易度が下がる
各ブロックチェーンは、ブロックチェーン毎に検証用の「Light Client」を開発する必要がないため、”組み合わせ爆発”が起きない
②検証コストが下がる
各ブロックチェーン上のコントラクトによる検証が軽くなるため、Ethereum等のEVMチェーンでのGas Cost負担が軽減される
「IBC」の「直接検証型」のネットワーク構成を、「ハブ＆スポーク型」の構成に昇華したものが上の図表です。
（ブロックチェーンAとして「Hyperledger Fabric」、ブロックチェーンBとして「Hyperledger Besu」を記載していますがただの例ですので、これらのチェーンに限定されるものではありません、為念。）
次の検討ポイントが、鍵となる「ハブシステム」をどこにどのように構成するか？です。
上の図表のとおり、「ハブシステム」自体をブロックチェーンC上に構築する実装もあり得るところですが、当該チェーンCのセキュリティや性能面の懸念がついて回ります。
そこでもう1つの選択肢が、安全な検証を実行可能な領域である、前述の「TEE」というわけです。
「TEE」の代表例であるインテルの「SGX（Software Gard Extension）」の詳細は、以下のリンク先から確認できます。（＊英語です）
というわけで、「TEE」として「Intel SGX」を搭載した「ハブシステム」にあたる「LCP node」、「Client」にあたる「LCP Client」で構成されるアーキテクチャが下図のような形になります。
”将来含み”と表現したのは、この構成自体も安全ですが、よりセキュリティ面の高度化を行うために、「LCP node」の分散化や、「ZK （Zero-Knowledge） Proof」を用いた検証との組み合わせ等への取り組みを継続しており、まさに最先端の進化中だからです。
（この時点で8,000字のため、別途解説します…）
そして現時点
「Burn-Mint方式」がグローバルでも先進的であること、
「CCTP」よりも「IBC」がオープンなプロトコルであること、
「IBC」のチャレンジ要素を解決するための「LCP」を用いた構成が進化中であること、
を解説してきました。
そして今回発表したのが、「IBC」 ベースで実装したクロスチェーン機能により、EhereumとBNB Chainのパブリック テストネット上で、 両チェーン間の転送が問題なく成功できることを確認済み、という内容です。
つまり、”SCの発行を共同検討”といった段階は既に終えており、具体的な”実装段階”であるだけでなく、グローバル目線でも最先端の内容で”実装完了”している段階である、ということです。
そしてもちろん、対応するBCはEthereumとBNB Chainだけではありません。プレスリリースにも敢えて明記したとおり、「各チェーンの取引コストや取引速度、関連するエコシステムの大きさ等を勘案し、SC利用者のニーズに即して順次対応範囲を拡大していきます。」
さいごに（伏線…）
「Progmat Coin」の現時点の立ち位置について解説してきました。
”実装完了”段階は確かに重要なマイルストーンではありますが、なぜ今あえて情報公開しているのでしょうか？
当然、いま、連名で、発表した意味があります。
プレスリリースに記載した要素を箇条書きで抜き出します。
Progmat社とDatachain社では、
信託銀行等のSC発行体と連携し、2024年内の「Progmat Coin」基盤を用いたSCの発行と、
その後のAUM最大化に向けて追加機能の開発
および国内外の様々な金融機関やSC利用企業との協議を進めてまいります。
個別の取り組みについては、準備が整い次第、発表させていただく予定です。
「なるほど、そう来るか」という取り組みを鋭意準備中ですので、もう少しお待ちいただければと思います。
このような技術的にも最先端の取り組みを、ただの研究開発ではなく具体的なユースケースと合わせて社会実装できる環境が、Progmatにはあります。
一緒に世界に挑む仲間、待ってます！
特にこれらを一緒に爆速で社会実装し、認知を高めてモメンタムを上げていく「Techメンバー」＆「HR/PRメンバー」、絶賛採用継続中です！
（毎月新メンバーJoinな状態）
カジュアル面談のご相談は、Web(☟)からお気軽にできます。皆さまにとって「今かも」というタイミングがきましたら、いつでもどうぞ！
この記事が気に入ったらサポートをしてみませんか？