Recently, I have started a new blog series related to Optimism.

https://mirror.xyz/hashigo%F0%9F%94%B4.eth

I would be delighted if you could follow it as well. As the latest post, I have written an article about blockchain and public goods.

https://mirror.xyz/hashigo%F0%9F%94%B4.eth/06XgQHDyg3sbAglxn9IwOj0WTjMVPmszJ86hgEeYVRs

As for this Mirror account, I plan to continue updating it irregularly as I have been doing. The topics I'll cover will also remain the same. I may even cover topics that are completely unrelated, but essentially, I'll post what I want to post.

Since I started publishing articles in English, people who are not Japanese speakers have also started reading my articles. I'm very pleased to have readers from all around the world. Thank you for your continued support.

日本語

最近、Optimismに関連したブログシリーズを新たに開始しました。

https://mirror.xyz/hashigo%F0%9F%94%B4.eth

もしよろしければ、そちらもフォローしていただけると嬉しいです。最新記事として、ブロックチェーンと公共財に関するブログ記事を投稿しました。

https://mirror.xyz/hashigo%F0%9F%94%B4.eth/J_wJbzIqqd_6y7gyO5I2wEfquE0ZMfkA3zQfbTAusfU

一方、こちらのMirrorアカウントですが、今まで通り不定期更新を続ける予定です。取り扱うトピックも、これまで通りです。もしかしたら、全く関係ないトピックも扱うかもしれませんが、基本的に、ぼくが投稿したいものを投稿します。

最近、英語の記事の投稿を開始してから、日本語話者ではない方も記事を読んでくださるようになりました。世界中のいろいろな方に読んでいただけて、とても嬉しいです。これからも、どうぞよろしくお願いいたします。

Projects related to blockchain often attempt to decentralize governance. In the governance of blockchain projects, 'governance tokens' are often introduced to facilitate smooth consensus formation for the maintenance of the protocol. In particular, delegation mechanisms are introduced to secure the governance system. However, if the person to whom authority is delegated becomes unable to participate in governance, securing the governance system becomes challenging. In this article, I propose MultiDelegate as a mitigation measure.

Voting and Delegation

Voting with governance tokens that lack a delegation mechanism takes place as follows:

• Token holders gain voting power proportional to the number of tokens they hold at a specific snapshot in time.

• Token holders vote within a designated period and receive the results afterward.

However, this has a significant drawback: those who own a large number of tokens can easily sway the voting results, thereby reducing the incentive for those with fewer tokens to vote. A decrease in voter participation leads to a lower proportion of tokens being used for voting. This reduction makes it easier for attackers to influence voting results, and it challenges the legitimacy of the vote.

The mechanism to mitigate this issue is delegation. In other words, token holders delegate their voting power to trusted community members. Those who only hold a small amount of tokens don't need to read through proposals and vote; they delegate to "knowledgeable people they trust" who will exercise their voting power on their behalf.

Issues with Delegation

Delegation is an excellent solution to the problem of low participation rates in voting. However, if a person who has been delegated a large number of tokens becomes unable to participate in governance, the same problem re-emerges.

To provide a concrete example, I have been delegated tokens by multiple individuals in a certain DeFi protocol. The tokens delegated to me represent about 30% of the voting power in recently passed proposals. If I were to suddenly die or lose interest in governance, that 30% voting power would go unexercised. This is counterproductive when considering the original purpose of introducing a delegation system into governance.

Of course, this problem could be solved by frequently checking the voting status and re-delegating to someone else if the original delegate fails to vote. However, will those who only hold a small amount of tokens bother to do such a "troublesome thing"?

Proposal for MultiDelegate

Overview

Here, I propose MultiDelegate. MultiDelegate is a system where a token holder delegates to "multiple" trusted community members. If a token holder owns X tokens and has delegated to Y members, the voting power is distributed as X/Y. Moreover, the system introduces the following mechanism:

If, among the members delegated to, Z members do not vote on a certain proposal, the voting power becomes X/(Y-Z). In other words, as long as at least one of the delegated members votes on a proposal, all of the tokens held by that token holder will be used for voting. This distribution of voting power takes place for each proposal.

Issues

MultiDelegate has the following issues:

• The voting power of each individual is only determined after the voting period has ended.

• The mechanism is complex.

Conclusion

Governance in blockchain is based on the spirit of decentralization. However, to address the issues highlighted by existing delegation systems, I propose MultiDelegate.

ブロックチェーンに関連するプロジェクトは、しばしばガバナンスの分散化の試みがされている。ガバナンスでは、ガバナンストークンと呼ばれる通貨の導入例が多く見られ、プロトコルの維持管理作業に関して円滑な合意形成を図る。特に、ガバナンスのセキュリティの確保のために委任の仕組みが導入されているが、委任された人がガバナンスに参加できなくなった場合、ガバナンスのセキュリティの確保が困難になる場合が考えられる。本記事では、その緩和策としてMultiDelegateを提案する。

投票と委任

委任の仕組みがないガバナンストークンによる投票は、以下のように行われる。

• トークンホルダーは、スナップショットが撮られた瞬間に保有するトークン量に比例した投票力を得る。

• トークンホルダーは投票期間内に投票を行い、投票期間後に結果を得る。

ただ、これには大きな問題点がある。それは、大量にトークンを保有する人が投票結果を左右しやすいがために、少量しかトークンを保有しない人が投票するインセンティブが欠けてしまうという点だ。投票に参加する人の減少は、投票に利用されるトークンの割合の低下を招き、投票結果の正当性が得られにくくなったり、攻撃者が投票結果を左右しやすい状況を作りやすくなったりする。

この問題点を緩和する仕組みが、委任である。つまり、トークンホルダーは信頼しているコミュニティメンバーに委任をするのである。少量しかトークンを保有しない人は、わざわざ提案を読んで投票する必要がなく、「信頼している詳しい人」が投票力を代わりに行使してくれるのである。

委任の問題点

このように、委任は投票に利用されるトークンの割合の低下を緩和する優れた方策である。しかし、たくさんのトークンを委任された人がガバナンスに参加できない状況になった場合、投票に利用されるトークンの割合が低下してしまうという問題点がある。

具体例を示そう。私はあるDeFiプロトコルにおいて、複数名から委任されている。委任されたトークンの量は、最近通過した提案に投じられた投票力のうち、約3割にあたる量である。もし私が突然死んでしまったり、ガバナンスに興味を持たなくなってしまったりした場合、その約3割の投票力が行使されなくなってしまうのである。これは、ガバナンスに委任のしくみを導入した目的を考えれば本末転倒である。

もちろん、頻繁に投票状況を確認し、もし委任先が投票しなくなったら違う人に委任すればこの問題は解決する。しかし、そもそも少量しかトークンを保有しない人はそのような「めんどくさいこと」をするだろうか。

MultiDelegateの提案

概要

そこで、MultiDelegateを提案する。MultiDelegateは次のような仕組みである。それは、トークンホルダーが「複数の」信頼しているコミュニティメンバーに委任をするというものである。あるトークンホルダーが保有するトークンをXとし、委任したメンバーの人数をYとした場合、投票力はX/Yに分配される。さらに、トークンのすべてを投票力に変換するために、次のような仕組みを導入する。

それは、もし委任したメンバーのうちZ人がある提案に投票しなかった場合、投票力をX/(Y-Z)に分配するというものだ。つまり、委任したメンバーのうち、最低でも1人が提案に投票すれば、そのトークンホルダーが保有するトークンのすべてが投票力を行使するのである。この投票力の分配は、各提案ごとに行われる。

問題点

MultiDelegateには以下の問題点が存在する。

• 投票期間が終了するまで、個々人の投票力が確定しない。

• 仕組みが複雑である。

結言

ブロックチェーンにおけるガバナンスは、分散を求める精神に基づいている。しかし、既存の委任システムでは一部の問題点が浮き彫りになっており、その解決のためにMultiDelegateを提案した。

この記事は、以下の翻訳になります。

https://mirror.xyz/blog.strateg.eth/geBDRlFKYSiIDYNUyh5be-6FR1-b1YftIW_pRabKG88

はじめに

Murphy Labsチームは、オムニチェーンソーシャルイールドインフラストラクチャであるStrategを紹介します。

ここ数年、DeFiは主要なプロトコルによって急速なペースで成長し、パーミッションレスで信頼性の高いオンチェーン金融サービスを利用できるようになりました。この成長には、多数の革新的なプロトコルとフォークが伴い、DeFiのエコシステムはますます複雑になる一方で、プロトコルのセキュリティはますます重要な関心事となりました。

DeFiを利用しようとする基本的なユーザーや企業は、今日、これらのプロトコルを利用し、相互作用を理解するだけでなく、コンポーザビリティという主要なイノベーションの恩恵を受けるために、いくつかの問題に直面しています。

シンプルでセキュアな方法で簡単にポジションを管理するには？ 「ダークフォレスト」で道を見失わないためには？ 解決策を待ち望んでいた多くの問題が横たわっています。

ついにStrategが登場しました。夜中の灯台のように、すべての人を照らし、使いやすさとリターンの最適化をもたらし、DeFiをより身近なものにし、知っている人と知りたくない人を結びつけることで普及を加速させます。

オムニチェーン・ソーシャル・イールド・インフラストラクチャー

Strategは、DeFiエコシステム内で利回りを生み出す方法に革命を起こす最先端のプラットフォームです。Strategは、革新的なオムニチェーン・インフラストラクチャを通じて、複数のチェーンにまたがる複雑な利回り戦略を簡単に作成・実行する能力をユーザーに提供し、同時にこれらの戦略をそれぞれのコミュニティ、ユーザー、顧客と共有する方法を容易にします。

Strategは、あらゆるチェーンのあらゆるプロトコルを介して利益を獲得するシームレスな体験をユーザーに提供し、これまで以上に簡単に資産を活用できるようにします。Strategは、利回りの最大化、リスクの最小化、DeFi空間における新たなビジネスチャンスの開拓など、ユーザーがどのような目的を達成するために必要なツールやインフラを提供します。Strategは、高度な利回り戦略へのアクセスを民主化し、DeFiのパワーを活用することで、状況を一変させ、投資家とストラテジスト双方に新たな可能性を解き放つ態勢を整えています。

投資家とストラテジストをつなぐ

DeFiの魅力の一つは、異なるプロトコルを織り交ぜて、いわゆる複雑な戦略を構築できることです。最初のプロトコルに資産を預け、それを担保に借り入れを行い、最終的にスワップや流動性プールへの預け入れを行い、最終的に満足のいく利回りを得るという複雑な行動は、ユーザーが収益機会を最大化することを可能にします。これらの戦略は、使用するプロトコルの数、コードの成熟度、または戦略自体のアクティブ管理に使用するツールによって、多かれ少なかれリスクを伴います。そのため、途中で道に迷ったり、資本の面で深刻な結果をもたらしかねない間違いを犯したりしがちです。

一般化すると、この時点で2つの主なタイプのプロフィールが思い浮かびます。

経験の浅いDeFiユーザーは、ラビットホールに深く飛び込もうとするすべてのユーザーが直面するいくつかの問題にすぐに気づくでしょう。主要なプロトコルの調査と更新、最高の利回りを見つけるための知識、日々登場し、コンポーザビリティをより複雑にしている新しいプロトコル、細かいリスク管理、これらはすべて、彼がリテールであろうとプロであろうと、潜在的な投資家の前に立ちはだかる障壁です。

これらすべてのデータの分析とポジションの管理は、多くの新規参入者の意欲をそぐ効果があり、ファイナライズに取り組もうと思ったとき、これらは非常に時間のかかる作業であることに気づきます。DeFiを完全に理解するのに必要なスキルを持つ人でさえ、この技術監視とポジションの監視という作業に投資しなければならない時間の多さに尻込みしてしまいがちです。

そこでStrategは、このようなタイプのユーザーが、ノンカストディアルな方法で資金を運用し、リスク選好度を考慮しながらDeFiに接することができるように、これらの作業をすべて委任し、他のことに専念できるようにします。

その一方で、DeFiにもたらされたすべての新機能を興味深く歓迎し、お気に入りのプロトコルのアップデートを喜ぶ愛好家や専門家もいます。

そのため、多くの質問が寄せられます。いくら投資すればいいの？ それは安全ですか？ これらの理由から、ストラテジストの仕事は、金銭的にも評判の点からも、よりやりがいのある個人的な活動なのです。彼らはしばしば研究者であり、"DeFi degens"であり、またはソーシャルネットワーク（Twitter、YouTube、Lensなど）で、彼らのコミュニティや投資家仲間に、研究の成果を共有する専門家です。

今日まで、このような知識や支援をシンプルな方法で収益化する本当の方法はありませんでした。

Strategでは、専門知識を持つ人々と、ストラテジストの専門知識から利益を得るために利益を共有する準備ができている人々との出会いが、トラストレスでパーミッションレスのまま、管理された方法で投資が行われるWin-Winの状況を作り出します。

他者のために価値を創造し、対価を得ること

ストラテジストは、自分のコミュニティと共有するストラテジーを作成することで、自分の研究と能力を収益化します。ストラテジーのパフォーマンスに応じて、ストラテジストは「クリエイターフィー」と呼ばれる成果報酬を受け取ります。これにより、ストラテジストは自分の時間と知識を収益化することができ、同時にコミュニティにとって最も効率的なストラテジーを構築することができます。

Strategを利用することで、ユーザーエクスペリエンスが簡素化されるだけでなく、ユーザーは自分の資金を預けることなく、自分が知っていて、そのスキルや評判が真剣さや質の高さを保証している個人や団体のストラテジーに従って投資することができるため、投資家にとって信頼が再び高まります。

ストラテジーは、DeFiとそのメカニズムをマスターしているにもかかわらず、これらのストラテジーのコード化方法を知ることが不可能であったり、コードに欠陥があったりするリスクによって制限されている人々を対象としています。

彼らは最終的に、他者と自分自身のために価値を生み出しながら、知識を共有する方法を見つけるのです。インフルエンサーやオピニオン・リーダーが、パンプ＆ダンプ以外の方法で、コミュニティとの関係で自分たちに報酬を支払うことができるのです。

イールドの戦場の真ん中で

Strategでは、ストラテジストは戦略を展開する際に、コミュニティのニーズに合わせて多くのパラメータを設定することができます。このトピックについては、今後の記事で詳しく説明し、私たちが選択した技術的な特殊性と、それらがどのように様々な設定を可能にするのかを理解したいと思います。

Strategへの投資はかつてないほど簡単で、分散化された方法で最大限のタスクを自動化することで、各投資家が資金を完全にコントロールできるようになっています。

利益は投資家、ストラテジスト、プロトコル、自動アクションの間で共有され、高度な分散化が保証されます。

今後の記事では、Strategの革新的なトークノミクスと、価値がどのように捕捉され、プロトコルのすべてのプレーヤーの間で再分配されるかについても詳しく説明します。

以下は、ストラテジーの価値分配の例です。

Wen Strateg?

Strategは、9か月に及ぶ研究開発の成果です。私たちは、私たちが作ってきたものをコミュニティに紹介できることにとても興奮しています。これからの数週間は魅力的な発表が目白押しなので、Twitterで私たちをフォローしたり、DiscordやTelegramのコミュニティ・グループに参加したり、私たちのウェブページから目を離さないでください。また、あなたは私たちのZealyクエストに参加することができますし、プロトコルに早期に投資した人に何が起こるか誰が知っていますか？

さらに、Strategの機能を利用することに興味をお持ちのDeFiプロトコルの方は、こちらのフォームにご記入の上、私たちのプラットフォームへのプロトコルの展開についてご相談ください。

私たちは、Strategと私たちの仕事を共有し、どのような戦略が実行されるかを見ることを楽しみにしています。

On your marks. Create, Share, Earn.

この記事はLensに掲載されています。

LINKS:

• Discord : https://discord.gg/89EtrkBYtQ

• Twitter : https://twitter.com/StrategProtocol

• Lens : https://www.lensfrens.xyz/Strateg.lens

• Telegram : https://t.me/strategprotocol

• Zealy : https://zealy.io/c/strateg/

• Guild : https://guild.xyz/strateg

Why not let the blockchain engage in a game of rock-paper-scissors? The rules are simple: deploy rock-paper-scissors contracts on N chains, have them interact with each other, and determine the winner at the end. Sounds easy, doesn't it?

Let's give it a shot!

Objective

The aim of this article is to offer you a glimpse into the experience of developing applications with crosschain messages, specifically through playing rock-paper-scissors between blockchains. But don't worry, we won't delve deep into programming and development as they're not the main focus of this tale!

Setting the Scene

The scenario is set as follows:

• The developer deploys the contract on N chains and specifies that the rock-paper-scissors game will start "at a certain time". Picture this peculiar scene where a developer maintains the contract solo, and then engages in a game of rock-paper-scissors with their own contract.

• For simplicity, we will not consider session IDs. Simply put, a single round of rock-paper-scissors is played, and even if players tie, there's no rematch. Once you've played rock-paper-scissors, you won't play again.

• A generic crosschain messaging protocol (CCMP) is used for communication between blockchains. LayerZero is a well-known example.

Then, the contracts operate as follows:

• When the time comes, the first step is to decide on a move. For simplicity, the contract generates a random value (note) to determine the move, and the remainder divided by 3 is used to discern the move. For instance, if the remainder is 1, it's rock; if it's 2, it's scissors; if it's divisible by 3, it's paper.

• The contract then utilizes CCMP to inform the opponent's chain of its move.

• Simultaneously, the contract receives information about the opponent's move from their chain. Given the rules of rock-paper-scissors, it's evident that the outcome is dependent on the combination of moves played. Therefore, once everyone's moves are known, the winner can be determined. Importantly, in the event of a tie, there's no rematch.

• Since a single developer deploys the contract, there's no need for secrecy about their move. In other words, we don't account for the possibility of being caught off guard.

With these conditions set, let's delve deeper into the message exchange.

Note: The blockchain fundamentally does not support random value generation. However, for the sake of simplicity, we'll assume it here…

Frequency of Message Communication

CCMP Functions

The CCMP utilized here is presumed to possess the following features:

• It's compatible with all chain types.

• Messaging occurs between two chains. It's a one-way exchange, analogous to letter communication, not a two-way dialogue.

• If the message doesn't reach the recipient, it has the ability to notify the sender of an unreachable error.

• Each message sent incurs a gas cost.

Estimating the Number of Transmissions

Assume that all chains are on par with each other. We aren't considering the presence of a game master who oversees the game. Focusing on a specific chain, how often will that chain send a message?

Given that it sends a message to every chain except its own, each chain sends a message N-1 times. With a total of N such chains, the number of message transmissions in this game is N(N-1) times. With the N squared term, we can expect the gas price to surge as the number of chains increases.

The solution is to establish a game master. In other words, participants submit their moves to the game master's chain and receive the computed results from them. This reduces the number of message transmissions from N squared to a linear number.

What Happens If a Participant Exits Mid-Game During Rock-Paper-Scissors?

What is Seat Departure?

Let's consider a scenario where a problematic chain exits mid-game during rock-paper-scissors. Specifically, the network goes down while the game is ongoing. In such a case, can rock-paper-scissors still operate?

Considering the Impact of Seat Departure

Assume all chains are on an equal footing (Let's disregard the game master for now!).

We aim to consider the potential situation, but before we do, let's recall this statement:

• If the message doesn't reach the recipient, it has the ability to notify the sender of an unreachable error. (From the CCMP Functions section)

Therefore, if a message fails to reach the destination chain, it can be inferred that the destination chain has exited the game, and the source chain can continue without the departed chain. It would be ideal if everyone could be informed when the absence of the exited chain is recognized. (This, however, would incur additional gas costs).

But how can other chains ascertain that a chain that didn't send a message initially is in an "absent" state? To determine this, a process stating, "If a chain doesn't send a message after a certain time frame, it's considered absent," needs to be implemented. Otherwise, no decision on "absence" can be made.

At this point, some may have specific concerns, such as what happens if a player exits (fails) while transmitting their move continuously to the opponent. Let's consider the situation where Player A exits while players A to E are engaged in rock-paper-scissors. Here, the following issues may arise:

In this scenario, we're considering the case where "Chain A begins transmitting its move information after acknowledging its opponent's move." In this situation, the derived game result differs from chain to chain. It's challenging to assert that a rock-paper-scissors game has been successfully played in such a case. To avoid this, making all chains agree on the game results' consistency could be an option, but this would entail additional gas costs. If the results aren't consistent, the developer would need to decide in advance whether to invalidate the game and revert it or force a majority vote to establish the outcome.

As discussed, considering irregular conditions like failures makes it hard to encapsulate crosschain exchanges within an application with atomicity (i.e., the only two options are to complete the exchange or revert to the original state in case of a problem).

Future Expansion

Further development could include the introduction of session IDs and a rematch feature for rock-paper-scissors. If an appealing chain emerges in the future, and you wish to include that chain in the rock-paper-scissors game, what steps would you need to undertake?

The answer is, "You'll need to modify the contracts of all pre-existing chains.” The existing contracts must incorporate the ability to interact with the newly added chains. That's substantial work.

Summary

As discussed, applications employing crosschain messaging face the drawback that the more sophisticated the functionality and the more chains supported, the more messages required exponentially. This is because the state must be synchronized across chains, and man-hours tend to balloon when considering future scalability.

For instance, how could one borrow money on chain D using tokens from chains A, B, and C as collateral? It is anticipated that creating a function that allows borrowing money, which checks the value of assets deposited as collateral on each chain based on the oracle, would be challenging. (And there are plenty of other features in a lending protocol, right?)

Therefore, current applications using crosschain messaging are limited to:

• Applications where two (or a few) chains interact (like bridges).

• Applications where one chain manages almost all states (as in a rock-paper-scissors game with a game master in this article).

Crosschain messaging is an attractive feature, but it is basically a heavy burden on the developer.

ブロックチェーン間でじゃんけんゲームをしてみませんか？ ルールは簡単で、N個のチェーンにじゃんけんのコントラクトを実装し、お互いに通信しながらじゃんけんを実施し、最後に結果を取得します。なんだか、とっても簡単な話に聞こえますよね？

それではやってみましょう！

目的

本記事では、ブロックチェーン間でじゃんけんをすることを通して、クロスチェーンメッセージを使ったアプリケーションの開発体験を垣間見ることを目的としています。といっても、プログラミングや開発を主軸とした話ではないので、身構える必要はありませんよー

舞台設定

舞台は次のように設定します。

• 開発者はN個のチェーンにコントラクトを実装し、「ある時間になったら」じゃんけんゲームを始めるように定義します。一人の開発者が勝手にコントラクトを整備して、勝手にじゃんけんさせるという異様な光景を想定してください。

• 簡単のためにセッションIDは考えません。要は、じゃんけんは一回限りで、あいこになっても再戦しません。一回じゃんけんしたら、二度とじゃんけんをしません。

• ブロックチェーン間のコミュニケーション手段として、汎用クロスチェーンメッセージングプロトコル（以下CCMPとします）を使用します。具体例をあげるなら、LayerZeroなんかが有名でしょうか。

そして、コントラクトは次のような動きをします。

• 時間が来たら、まず自分の手を考えます。簡単のために、コントラクトは手を出すためにランダムな値（注）を生成し、3で割った余りで自分の手を考えます。例えば、1余ったらグー、2余ったらチョキ、割り切れたらパーといった感じです。

• そしたら、コントラクトはCCMPを使って対戦相手のチェーンに自分の手を知らせます。

• それと同時に、コントラクトは対戦相手のチェーンから手の情報を受け取ります。「出た手の組み合わせによって勝敗状況はどうなるのか」ということはじゃんけんのルールから自明なので、全員の手がわかったら勝敗がわかります。繰り返しますが、あいこになっても再戦しません。

• 一人の開発者がコントラクトを実装するので、自分の手を秘匿化する必要はありません。つまり、後出しじゃんけんされるリスクは考えません。

条件が出そろいました！ メッセージのやり取りについて、もうちょっと深く考えてみましょう。

注: ブロックチェーンは基本的にランダムな値の生成に対応してないのですが、ここは簡単のために…

メッセージの伝達回数

CCMPの機能

ここで使用するCCMPは、次のような機能を有するとします。

• あらゆるチェーンに対応している。

• メッセージングは二者間のチェーンで行われる。それは双方向ではなく、手紙のように一方的なやり取りである。

• 宛先がメッセージを受け取れなかった場合、送信者に未到達エラーを通知する機能がある。

• メッセージを送信するごとにガス代がかかる。

伝達回数を見積もる

すべてのチェーンが互いに対等な立場だとします。

つまり、ゲームを取り仕切るゲームマスターのような存在は考えないものとします。ある特定のチェーンに注目したとき、そのチェーンは何回メッセージを送ることになるのでしょうか。

このように、自分以外のチェーンにメッセージを送るので、そのチェーンはN-1回メッセージを送ることになります。このようなチェーンは合計N個存在するので、このゲームにおけるメッセージの伝達回数はN(N-1)回です。Nの2乗の項が出てきてしまったので、チェーンが増えれば増えるほど、ガス代が跳ね上がることが予想されます。

これを解決するには、ゲームマスターを設定します。つまり、対戦者はゲームマスターのチェーンに自分の手を提出し、ゲームマスターからはじき出される結果を受け取るという算段です。これにより、メッセージの伝達回数はNの2乗から線形に削減されます。

じゃんけんの途中で離席してしまう場合

離席とは

ここで、じゃんけんの途中で離席してしまう困ったチェーンがいることを考えましょう。具体的には、じゃんけんをしている途中で、ネットワークがダウンしてしまうような状況です。そのような場合でも、じゃんけんは成立するのでしょうか。

離席の影響を考える

すべてのチェーンが互いに対等な立場だとします。（ゲームマスターの存在はいったん忘れてください！）

この場合、どういった状況になると困るのかを考えたいのですが、その前にこの一文を思い出しましょう。

• 宛先がメッセージを受け取れなかった場合、送信者に未到達エラーを通知する機能がある。（CCMPの機能の節より）

よって、メッセージが到達しなかった場合は、宛先のチェーンが離席したと考えることができるので、送信元のチェーンは離席したチェーン抜きでゲームを続行できます。離席したチェーンの存在がわかったらみんなに通知できればなおよいですね。（その分ガス代がかかりますが）

しかしながら、そもそもメッセージを送信しなかったチェーンを、ほかのチェーンはどのように離席状態であると判断するのでしょうか。これには、「ある時間経過してもメッセージを送ってこないチェーンは、離席したものと考える」という処理を実装する必要があります。そうしないと、一向に離席判定を下すことができません。

と、ここである懸念が浮かんでくる方がいるのではないでしょうか。例えば、自分の手を対戦相手に続けて送信している途中で離席（障害）が発生してしまった場合です。チェーンA~Eの5人がじゃんけんをする途中で、Aが離席してしまう場合を考えてみましょう。そうすると、次のような困ったことが起こる可能性があります。

この図は、「チェーンAが対戦相手の手の情報を知ってから、自分の手の情報を送り始める」という状況を考えています。このとき、導びかれるゲームの結果がチェーンによって異なってしまいます。とてもじゃんけんゲームが成立しているとはいいがたい状況です。こうならないようにするためには、ゲームの結果が一致しているかどうかを、すべてのチェーン間で合意を取ることで解消できますが、そうしたらまた余計なガス代がかかってしまいます。また、もし結果が一致してなかったとしたら、ゲームを無効にして切り戻すのか、多数決をとって強引に結果を決めるのか、開発者はあらかじめ決めておかなければなりません。

以上のように、障害のようなイレギュラーな状態を考慮すると、クロスチェーンのやり取りに原子性（やり取りが完結するか、問題等が起きたら元の状態に戻るかの二択しかない性質）をもたせつつ、アプリケーションとして表現するのは大変そうであることが伺えます。

将来の拡張性

あなたはさらに開発を進め、セッションIDを導入し、じゃんけんの再戦機能を作ることができました。もし今後魅力的なチェーンが出てきて、そのチェーンにもじゃんけんに参加できるようにしたくなった場合、何をする必要があるでしょうか。

答えは、「既にある全てのチェーンのコントラクトに手を加える必要がある」です。既存のコントラクトには、新しく追加されたチェーンとやり取りする機能を追加しなければなりません。大変ですね。

まとめ

以上のように、クロスチェーンメッセージングを用いたアプリケーションは、機能を豪華にすればするほど、より多くのチェーンに対応すればするほど、必要なメッセージの数が爆発的に増えてしまうという欠点があります。なぜなら、チェーン間で状態の同期をとらなければならないからです。また、将来の拡張性に目を向けた際、必要な工数も膨れ上がる傾向にあります。

例えば、チェーンAにあるトークンと、チェーンBにあるトークンと、チェーンCにあるトークンを担保に、チェーンDでお金を借りるにはどうしたらよいのでしょうか？ オラクルに基づき、各チェーンに担保として預けた資産の価値を確認し、お金を借りる（ことを許可する）機能を作るのは大変であることが予想されます。（それ以外にも、レンディングプロトコルには様々な機能がありますよね）

そのため、クロスチェーンメッセージングを用いたアプリケーションは、以下のようなものに限られるのが現状です。

• 2つ（や小数）のチェーンが相互作用するようなアプリケーション（ブリッジとか）

• 1つのチェーンがほぼすべての状態を管理するようなアプリケーション（この記事だと、ゲームマスターがいるじゃんけんゲームのような）

このように、クロスチェーンメッセージングは魅力あるソリューションなのですが、開発者の負担が大きいってことを下記ツイートよりも上手に伝えたかったのであります！

https://twitter.com/hash1go_/status/1647948774571139072

ちなみに、ぼくがアンバサダーをやってるZetaChainのオムニチェーンスマートコントラクトという機能では、このような問題を解決できるとされているみたいですよ？

参考文献

なし

この記事は、以下のyoutube動画の文字起こしの翻訳です。翻訳はあまりチェックしてないので、参考程度にお願いします。

アイスブレイク

Halborn 皆さんこんにちは、Halborn Flashのビデオをご覧になっています。今日はZetaChainのブランドンさんにお話を伺いました。視聴者の皆さんには、ご自身のことをもう少し詳しく教えてください。

Tru ええ、ありがとうございます。ここに来られて光栄です。私はブランドンです。ZetaChainでプロダクトをリードしています。私の経歴は、2018年から2020年にかけて自分のスタートアップに取り組み、2020年末に売却したことの組み合わせのようなものです。ウェブ2.0のソーシャルスペースやデザインとエンジニアリングのバックグラウンドを持っていて、ZetaChainにかなり早い段階で参加し、プロダクトとデザインに集中するためにインセプションステージにいたようなものです。しかし、私は製品のほとんどの側面を見過ごすようになりました。つまり、プロトコル開発だけでなく、ユーザー向けの製品の検証エコシステムなど、楽しいものすべてを見過ごすようになったのです。

ZetaChainの紹介

Halborn 優れたデザインとエンジニアリングは、プロダクトのポジションで融合させるには、実にユニークな経歴です。というわけで、今日はとても興味深いお話を聞かせていただきました。ZetaChainとは では、ZetaChainについてもう少し教えてください、そして、あなたはまさに何を作っているのですか？

Tru 簡単に言うと、ZetaChainは、相互運用性に焦点を当てた新しいL1です。つまり、EVM互換のスマートコントラクトレイヤーを備えているのです。そのため、基本的にEthereumのメンテナンスで行うようなものをZetaChainにデプロイすることができます。しかし、ZetaChainのスマートコントラクトと他のいくつかの機能は、オーケストレーション、つまり外部のブロックチェーンから入力を受け、データと価値を出力することにアクセスできます。そして、この相互運用性は、単一の通信プロトコルに縛られるものではありません。IBCのようなものは、チェーンにとらわれない。つまり、ZetaChainは、Ethereumに接続するのと同じようにBitcoinに接続し、AptosやSui、Cosmos、EVM、SolanaなどのMoveエコシステムのような将来のチェーンに接続できるのです。つまり、ZetaChain上のスマートコントラクトは、クロスチェーンアプリケーションを超簡単に構築できます。例えば、UniswapをZetaChain上にデプロイすることができ、そのUniswapコントラクトはネイティブBitcoinウォレットからネイティブBitcoinを入力し、開発者側であまり作業せずにEthereumメインネット上でEthereumに対する取引のように出力することができます。これは非常にクールで、クロスチェーンアプリケーションを構築するための新しいパラダイムであり、ここ1、2年で急増したメッセージングソリューションを使ってクロスチェーンを構築する際のリスクや複雑さを払拭するものだと考えています。さらに、ZetaChainは独自のクロスチェーンメッセージングをサポートしており、資産をラップすることなくチェーン間で実際に価値を移転することが可能です。そのため、それだけで多くのアプリケーションを構築することができ、過去数年間のブリッジハック事件で見られたような、悪用可能なVaultを必要とせず、数億ドル、いや数十億ドルの損失をから人々を守ることができるのです。これが、ZetaChainが持つ高いレベルの特徴です。

ZETAトークンの特徴

Halborn ありがとうございます。未来はクロスチェーンであり、あなたが扱う相互運用性のユースケースは、間違いなくそれをより特別なものにします。これはZETAトークンで起こることだと思いますが、私たちにもう少し説明してください。

Tru このL1ブロックチェーンは、コンセンサスによってCosmos SDKで構築されていますが、EVMと互換性があると述べたと思います。ZETAは、私が説明したすべての機能の中核を担っています。スマートコントラクトで、ガスを払ってデプロイし、ZetaChainのEVMでZETAを送ります。さらに、このメッセージング全体の状況について、私たちは「クロスチェーントランザクション」と呼んでいます。ソースチェーンから送信するとき、ZETAを束ねることができます。ゼータは、ガス料金やプロトコル料金の支払いに部分的に使用され、また、ある種の一方通行ペグとしても使用されます。例えば、EthereumからPolygonに価値を移したい場合、Zetaに交換することができます。つまり、USDCを持っていて、PolygonのMATICにスワップしたい場合、USDCを持っていればZETAにスワップすることができるのです。メッセージングシステムでそれを送ると、あなたのデータが添付されたコントラクトと、ZETAがバーンされてPolygonでミントされたデータを呼び出すだけで、目的の資産に交換することができるのです。つまり、このプロセス全体では、両面スワップのようなもので、資産を手に入れたら、リスクはありません。一方、ラッピングの場合、目的地で資産を手に入れると、ハッキングされる可能性のあるハニーポットをソースに構築することになり、その可能性は決して低くはありません。

オムニチェーンdApps

Halborn そうですね、確かに。オムニチェーンdAppsとは？ オムニチェーンdAppsについてもう少し詳しく教えてください。あなたがZETAを説明するときに使った言葉の中で、それがたくさん使われているのを見たので、それについてもう少し学びたいと思います。

Tru オムニチェーンdAppsは、ある種のコンセプトで、アプリケーションは一度だけデプロイすればよく、ZetaChainがチェーンサポートを追加したり、ZetaChain固有のものではないかもしれませんが、複数のチェーンをつなぐLayerZeroがチェーンサポートを追加したりすることで、後方および将来性を証明することができるものなのです。あなたのアプリケーションは何もする必要がありません。ただ、完全な相互運用性レイヤーにアクセスし、異なるチェーン間で物事をオーケストレーションすることができるのです。先ほど説明したUniswapの例のように、Uniswap V2コントラクトをデプロイして、さらに資産やチェーンが追加されると、どこからでも資産の取引やプールを持つことができるようになるのです。dAppsを利用するユーザーは、アプリケーションによほど関係がない限り、ネットワークや異なるブロックチェーン間の切り替えといった概念を持つ必要はありません。多くの場合、BitcoinウォレットやEVMウォレットからアプリケーションを使用することができますが、それは本当に重要ではありません。ですから、アプリケーションの設計の幅が広がり、ユーザーは接続するだけでワンステップ体験ができるようになるのです。今日の多くの製品に見られるような、さまざまな手続きを踏む必要がないのです。- クロス・チェーンの導入と実現に大いに役立っています。

開発チーム

Halborn ZetaChainの開発チームについて少し教えてください。

Tru ええ、それで、創設者は2021年の6月にこの信念に取り組み始めました。そして、彼の経歴はCoinbaseで非常に早い段階でBasic Attention Tokenというトークンを作るに至りました。彼は、今話したようなクロスチェーンという問題を解決することに集中していました。そして、この問題に対する永続的な解決策を見つけるという使命感を持って、私を含む何人かが参加し、いくつかのアイデアで遊びました。そして、このような基本的なトークンブリッジのソリューションから、現在のZetaChainのような新しいL1へと発展していったのです。このプロセス全体には少し時間がかかりましたが、2021年の終わりから2022年の初めにかけて、より完全なビジョンがまとまったと言えるでしょう。その後、オムニチェーンのスマートコントラクトやオムニチェーンdAppsの本格的なビジョンであるZETA EVMを構築するための時間とスペースができました。

メインネットの時期

Halborn ZetaChainメインネットはいつ？では、製品ロードマップのどのあたりに位置し、メインネットはいつになるのでしょうか？

Tru プロトコルは今、監査段階で、いくつかの機能を結びつけ、実際にプロトコルのコードをオープンソース化する準備を進めているところです。だから、メインネットの前段階にあると言えるでしょう。まもなくインセンティブ付きテストネットがローンチされ、その後は基本的にメインネットに向けた準備を進めていくことになります。

セキュリティ監査

Halborn もちろん、監査の話もしました。そこで、ZetaChainのセキュリティ戦略について、さらにお聞きしたいのですが、あなたのチームはどのようにセキュリティ戦略に取り組んでいるのか、また、なぜHalbornのようなサイバーセキュリティ・プロバイダーと提携するのか。

Tru 私たちにとって、セキュリティは全社的な最重要課題です。私たちが解決しようとした基本的な問題のひとつは、クロスチェーン転送に伴うリスクです。メッセージングソリューションは、エンドユーザーにとって、資産を手に入れた時点で、その資産を実際に手に入れることができるという点で、それ自体、リスクを根絶するものです。エンドユーザーにとって、資産を手に入れた時点で、その資産を実際に手に入れることができるのです。そのため、包まれた資産の相互依存関係や、その基礎となるようなものには左右されません。プロトコル自体も、複数のプロトコル監査を経て、バリデーターに対するベストプラクティスや、鍵管理、運用セキュリティなど、より広範なエコシステムへの提案を行っています。そして、dappやユーザーインターフェイスのレベルでも、インターフェイスの監査やスマートコントラクトの完全監査を何度も行い、エンドユーザーのためにあらゆる手段を講じるようにしています。

なぜHalbornを選んだのか

Halborn チームが取っているセキュリティ防御のアプローチを聞くのはいつも楽しいものですが、なぜ特にハルボーンなのでしょうか？なぜハルボーンなのでしょうか？

Tru 監査は本番です。ハルボーンの評判に代表されるように、以前あなた方と仕事をしたことがある人たちに聞いたところ、あなた方はスマートコントラクトに特化しているわけではなく、プロトコルの包括的な分析が可能で、アーキテクチャ的に類似した要素を持ついくつかのプロジェクトと一緒に仕事ができることが、ハルボーンと仕事をするという決断につながったようですね。メインネットの枠を超えた包括的なパートナーとして、御社と一緒に仕事をしたいと思ったのです。

助成金プログラムについて

Halborn そう言っていただけると、とてもうれしいです。また、御社がローンチした「500万人の開発者ZetaChainの500万人の開発者助成金」ブランドプログラムについてもよく耳にしましたが、こちらについてももう少し詳しく教えてください。

Tru ええ、私たちは歴史的に多くの親密なパートナーを持っていて、一緒にdAppsの構築に取り組んできました。しかし、私たちは、一般的なコミュニティにもっと公に助成金を提供することで、よりジャンプスタートし、火をつけたいと思いました。少なくとも私たちがこれまで見てきたところでは、非常に興味深いものがたくさんあり、開発の観点からは、実際には低いぶら下がり果実のようなものです。ですから、既存のプロジェクトだけでなく、独立系の開発者にとっても、ZetaChainをベースに構築する機会がたくさんあると思います。Uniswapの例に戻りますが、これはZetaChainを使った開発のシンプルさを象徴するようなもので、EthereumメインネットやL2上で開発するような多くのものをZetaChainに展開し、最小限の変更で完全にクロスチェーンにすることができます。例えばドアチェーンのようなものは、ZetaChainの特定用途向けバージョンのようなものですが、ZetaChain上に展開できるデッキに焦点を当てれば、完全に監査されることは別として、数週間や数か月ではなく、数時間や数日で展開することができます。助成金制度にとても期待しています。みなさんの中で応募したい人がいれば、ぜひ応募してほしい。

プロダクト責任者というキャリア

Halborn プロダクト責任者としての道を歩み始めるにはどうしたらいいのでしょうか。あなたは特にデザインエンジニアリングの観点から来た方なので、お聞きしたいのですが。あなたがやっているように、製品開発をリードし、それに携わるには何が必要なのでしょうか？また、あなたのようなキャリアに興味がある人は、どのような点に注目すればよいのでしょうか？

Tru ええ、とてもいい質問ですね。ウェブ2.0を比較すると、純粋なデザイン、純粋なプロダクトの視点を持っている人は、会社に入って、技術的なことを考えなくても、さまざまな方法でプロダクトをリードすることができると思うんです。しかし、Cryptoの場合は、すべてが金属に近い、あるいは非常に低いレベルであるため、基本的な技術的理解を持つことが、基本的なエントリーポイントになると思います。ZetaChainを始める前は、一般的にCryptoのエコシステムについてあまり技術的な理解をしていませんでした。ですから、非常に早く立ち上がることができるものなのです。この業界はとても新しいので、2～3年いれば、ウェブ2.0業界の多くが数十年以上の経験を持っているのに比べれば、かなり上級者になれるでしょう。

さいごに

Halborn この業界をさらに革新的でユニークなものにしているのは、コミュニティがあなたと話し、あなたを助け、あなたの視点を通して得た価値を製品やその他のものに移そうとする姿勢があることです。さて、ブランドン、今日私たちと話す時間を取ってくれて本当にありがとう、そしてZetaChainのさらなるアップデートを楽しみにしています。本当にありがとうございました。

つい先程、ZetaChainのホワイトペーパー1.0が公開されました。実際に翻訳していて、いくつかの変更点と、追加された部分に気づきましたので、ここにまとめたいと思います。

変更点/追加点

• 4章ZetaChainブロックチェーンアーキテクチャの4.1概要のうち、スループットに関する記述が変更されています。以前はTPSは100と記述していたのですが、理想的には4000 TPSという記述に変更されました。ただし、現実には外部チェーンとのやり取りにかかわる処理が律速になるだろうということが述べられています。

• 4章ZetaChainブロックチェーンアーキテクチャの4.4クロスチェーンスマートコントラクトとZeta仮想マシンのうち、Zeta仮想マシンの表記がZVMからzEVMへ変更されています。実は、昨年にドキュメントが公開された段階ですでに記述は変更されました。意図としては、Zeta仮想マシンはEVM互換であり、外部チェーンとのやり取りに関して書き加える以外は、コードの変更がほとんど必要ないことを強調したいのかなと勝手ながら思っています。

• 4.4クロスチェーンスマートコントラクトは全体的に変更・追加されています。

  • 4.4.1.汎用クロスチェーントランザクションの課題として挙げられているものが、「（トランザクションの）非同期性と原子性」に置き換わっています。

  • 4.4.2.メカニズム1: クロスチェーンメッセージパッシングと4.4.3.メカニズム2: オムニチェーンスマートコントラクトでは、それぞれZetaChainの2つの機能が詳しく述べられています。特に、リバートした際の挙動について事細かに記されています。

  • 4.4.4.オムニチェーンスマートコントラクトとメッセージングの比較では、2つの機能をよく知られているdAppを具体例に出しながら、それぞれの仕様の違いを説明しています。

  • 4.4.5.手数料・ガスでは、ZetaChainのリソースを使用するのに使われるガスの使用について述べられています。

  • ZETAトークンの仕様や用途について表現が変わっています。

• 6.ユースケース・アプリケーションでは、6.5.他のユースケースの項目が追加され、拡充が図られています。

以上がZetaChainホワイトペーパー1.0の変更点と追加点になります。 大きな変更点としては、ドキュメントに基づいてクロスチェーンスマートコントラクトに関する記述が加わっており、その他はそこまで変わってないかなという印象です。

Cryptoエコシステムにおいて、それぞれのブロックチェーンは閉じており、それらを相互作用させるには何らかの手段を用いる必要があります。例えば、Ethereum L2であるArbitrumとOptimismとの間でETHをブリッジさせるには、ブリッジプロトコルや、CEXなどの信頼できる第三者が必要となります。しかし、これらの例では、トラストポイントが発生してしまいます。

さらに、もっと違う種類のブロックチェーン間で相互作用させる場合には、これらの問題は顕在化しやすいです。例えば、Bitcoinネットワークで取り扱われるBTCをEthereumで取り扱う場合では、WBTCやrenBTCがEthereum上にmintする必要がありますが、ブリッジのしくみにトラストが必要であり、信用不安によって価格乖離がたびたび起こりました。さらに、ブリッジは攻撃対象となりやすく、大規模なExploitによってたびたび世間を騒がせてきました。

以上のような問題意識から、トラストレスまたはトラスト最小化した手法でBitcoinにスマートコントラクトを作用させようとするプロジェクトが動いています。今回は、以下の3つのプロジェクトを取り上げます。

1. Avalanche Bridge(BTC.b)

2. Internet Computer(ckBTC)

3. ZetaChain(ZRC-20)

注：私はZetaChainコミュニティで活動をしており、公平なレビューが期待できないことにご注意ください。

2. Avalanche Bridge

Avalanche BridgeにおけるネイティブBitcoinのサポートは、2022年6月に始まりました。このサポートによって、AvalancheでBTC.bトークンというBTCのラップトークンが活用できるようになりました。また、同年11月にLayerZeroと統合し、オムニチェーントークンに対応しました。このブリッジは、SGXアプリケーションとWardenに分けることができます。Wardenは、Enclaveに適格なトランザクションを提出し、処理させる責任を負います。

2.1 Intel SGXアプリケーション

Intel SGXとは、

センシティブデータを保護しつつプログラムを実行する為のCPUの拡張機能

です[1]。つまり、あらゆる攻撃耐性を持ちながら、確実に「あるプログラム」が実行できるようになります。これを実現するために、メモリ上にEnclaveとよばれる、保護された特別な領域が生成されます。

そして、Intel SGXアプリケーションはEnclave内で実行されるコードベースと、Enclave外で実行されるコードベースで構成されます。Enclave外で行われる処理として、Enclaveの初期化と起動、リモート認証サーバの実行があり、一連のプロセスでEnclaveの身元を保証します。

EnclaveはWardenと直接通信し、オンチェーンイベントから署名済みトランザクションを送信します。それはつまり秘密鍵を有していることになるのですが、Enclaveが使用する秘密鍵は、Enclave内のスタートアップで生成された単一のマスターシークレットから派生します。このシークレットはShamirの秘密分散法によって8人のWardenに配布されます。~~みんな大好き多項式。~~共有する必要が生じた場合には、各WardenはEnclaveとリモート認証を行い、共有セッションキーを確立します。このセッションにおいて、各Wardenに配布された秘密は暗号化されてEnclaveに返されます。ブリッジは、秘密からマスターシークレットを再構築し、必要な秘密鍵を再導出するためにマスターシークレットを使用します。

2.2 Warden

Wardenは、Enclaveに適格なトランザクションを提出し、処理させる責任を負います。つまり、中継者(リレイヤー)のような役割をします。Wardenは以下の8人です。Shamirの秘密分散法からマスターシークレットを導き出すために、6人の承認が必要になります。また、この承認のため、シークレットシェアを保管する責務を負います。

• Ankr

• Blockdaemon

• Chainstack

• Protofire

• Avascan

• Ava Labs

• Bware Labs

• Halborn

また各Wardenは、Enclaveによって処理されたトランザクションを追跡する責務を負います。これは、二段階のコミットプロセスによって成立します。

まず、暗号化された署名済みトランザクションを各Wardenに送信し、バックアップとしてデータベースとして保存します。これは、Enclaveのみが復号化することができます。

保存されたことをEnclaveが確認すると、Enclaveは処理のために暗号化されていないトランザクションを各Wardenに送信します。これを受信すると、関係するチェーンにそのトランザクションをブロードキャストしようとします。すでにブロックに含まれていることが確認できると、Wardenはそのトランザクションが正常に処理されたことが確認できます。

その他にも、Wardenはブロックチェーンのインデックス化や手数料等に関する情報の公開、Enclaveで実行されるコードベースの検証といった責務を負います。

2.3 BTC.bのオムニチェーン化

2022年6月に始まったAvalanche BridgeのBTCサポートによって、Avalancheのエコシステム内でBTCのラップトークンであるBTC.bを活用できるようになりました。また、同年11月にBTC.bはOmnichain Fungible Token（OFT）に対応しました。これにより、LayerZeroがサポートする複数のブロックチェーンにおいて、単一のBTC.bコントラクトにアクセスできるようになるため、流動性の断片化が発生しません。

LayerZeroは、トランザクションの証明を提供するリレイヤーと、ブロックヘッダを提供するオラクルという2つの主体から成り立ちます。そして、あるブロックヘッダは過去のブロックヘッダに遡って検証されるライトクライアントという形式をとらないことで、ストレージ等のコストを削減しています。オラクルとして、Chainlink等の分散型オラクルが想定されていますが、LayerZeroを使ったアプリ開発者はこれを自由に選択することができます。

3. Internet Computer

Internet Computer(IC)は、物理的に分散したデータセンターのコンピューティングリソースが利用可能なプラットフォームで、EthereumのスマートコントラクトにあたるCanisterを用いたアプリケーションを提供します。

ICを運用管理する仕組みをInternet Computer Protocolといい、リソースを分散配置し、耐障害性を確保しています。

3.1 Bitcoinとのプロトコルレベルでの統合

Bitcoinとのプロトコルレベルの統合は、ICがオンチェーン上でBitcoinのUTXOセットを維持管理することを意味します。Canister自身が新しいしきい値ECDSAプロトコルを用いてECDSA鍵を持つことができるため、Bitcoinの受け取り、維持、送金ができます。

しきい値ECDSAプロトコルは、秘密共有によるマルチパーティ計算(MPC)の技術であり、どのノードも秘密鍵を知ることなく、共同で計算してECDSA署名を生成することができます。

3.2 ckBTCの提案

ckBTCはdfinityのフォーラム[7]で提案されており、フォーラムによれば、2023年のはじめにリリースされる予定です。現在、ICが扱うことができるBTCはBitcoinネットーワークに存在するBTCであるため、トランザクションが遅いという欠点があります。これは、Bitcoinネットワークのブロック生成が10分前後かかり、確実にブロックに取り込まれたと判定されるまでに1時間は見積もらなければならないことに由来します。

そこで、ckBTCという、キャニスタースマートコントラクトによってラップされたトークンが提案されています。ICとBitcoinはプロトコルレベルで統合されており、ckBTCはIC上でネイティブなトークンです。また、ckBTCの送金に限れば、非常に安価に実現することができます。ckBTCはNNSというICのガバナンスによって所有されており、このキャニスターを管理する特定の個人は存在しません。

3.3 ckBTCのmint/burnプロセス

ユーザはキャニスターの「ckBTC minter」というスマートコントラクトを使って、Bitcoin上の本物のBTCを入金し、同量のckBTCを受け取ることができます。同様に、ckBTCを返却し、指定したBitcoinアドレスで同量のBTCを受け取ることもできます。

4. ZetaChain

ZetaChainは、マルチチェーンの未来への基礎となるレイヤーを目指しています。ブロックチェーンは、ブリッジやラップトークンを使用せずにマルチチェーン機能を実現し、オムニチェーンdApps（odApps）を展開することができます。これらのアプリケーションは、すべてのスマートコントラクトプラットフォームだけでなく、BitcoinやDogecoinなどの非スマートコントラクトプラットフォームのデータと価値を管理・接続することができます。

4.1 アーキテクチャ概要

ZetaChainは、バリデータと呼ばれるノードの分散ネットワークで構成されています。バリデータは、関連する外部の状態とイベントに関するコンセンサスに達する分散型オブザーバとして機能し、また、分散キー署名によって外部のチェーン状態を更新することができます。ZetaChainは、分散型（単一障害点なし、トラストレス、パーミッションレス）、透明、かつ効率的な方法で、これらの機能を達成します。各バリデータ内に含まれるのは、ZetaCoreとZetaClientです。ZetaCoreはブロックチェーンを生成し、複製されたステートマシンを維持する責任を負います。バリデータのオペレータは、このアーキテクチャの異なるコンポーネントを実行します。

Zeta EVM（zEVM）は、ZetaChainのコアブロックチェーン上に構築されたオムニチェーンスマートコントラクトをデプロイして使用できるEthereum互換の仮想マシンです。zEVM上のコントラクトはZetaChainの相互運用性レイヤーに接続されており、外部チェーン上のアセットをあたかも単一のチェーン上にあるかのようにオーケストレーションすることが可能です。

ZetaChainは2023年第1四半期にメインネットがリリースされる予定です。はじめはPoAですが、後にPoSへと移行する予定です。また、現時点でテストネット含め各個人がバリデータノードを建てることはできません。

4.2 バリデータ

バリデータは3つの異なる役割で構成されています。Basicバリデータ、オブザーバ、TSS署名者です。バリデータは、トランザクションを処理し、ネットワークを安全に保つというサービスの対価として、トランザクションからの手数料と報酬が分配され、受け取ります。オブザーバーとTSS署名者は、セキュリティや掛け金の要件が異なるため、Basicバリデーターとは別の規模になります。

4.2.1 Basicバリデータ

ZetaChainは、部分的な同期ビザンチンフォールトトレラント（BFT）コンセンサスアルゴリズムであるTendermintコンセンサスプロトコルを使用します。各バリデータ・ノードは、拘束/委任されたステーキングコイン（ZETA）に比例した投票権により、ブロックの提案に投票することができます。各バリデーターはコンセンサス公開鍵によって識別されます。バリデータは常にオンラインである必要があり、常に成長し続けるブロック生成に参加します。バリデータはそのサービスの対価として、ブロック報酬と取引手数料を受け取ります。

4.2.2 オブザーバ

ZetaChainのコンセンサスにとって重要なもう一つの参加者は、外部のチェーンイベントと状態についてコンセンサスを得るオブザーバです。オブザーバは、外部チェーンの完全なノードを介して、特定のアドレスで特定の関連する取引、イベント、状態について、外部接続チェーンを監視します。オブザーバはシーケンサと検証者の2つの役割に分かれます。シーケンサは関連する外部のトランザクション/イベント/状態を発見して検証者に報告し、検証者はZetaChainを検証して投票し、コンセンサスを得ます。

4.2.3 TSS署名者

ZetaChainは、外部チェーンとの認証された相互作用のために標準的なECDSA/EdDSAキーをまとめて保持します。鍵は、それらの超多数だけがZetaChainを代表して署名できるような方法で、複数の署名者の間で分配されます。重要なことは、いかなる時も、単一のエンティティまたはノードのごく一部が、ZetaChainを代表して外部チェーン上でメッセージに署名できることを確実にすることです。ZetaChainシステムは、経済的安全を確保するために、担保つきのステークと正/負のインセンティブを使用します。

4.3 ZRC-20規格

ZRC-20は、ZetaChainのオムニチェーンスマートコントラクトプラットフォームに統合されたトークン規格です。ZRC-20を使用すると、開発者は、接続された任意のチェーン上でネイティブアセットをオーケストレーションするdAppsを構築することができます。

ZRC-20トークンは、Ethereumエコシステムで見られる標準的なERC-20トークンの拡張版で、ZetaChainに接続されたすべてのチェーン上のアセットを管理する能力が追加されています。Bitcoin、Dogecoin、他のチェーン上のERC-20同等物、他のチェーン上のガスアセットなど、あらゆるファンジブルトークンはZetaChain上でZRC-20として表されます。

ZetaChainが外部チェーンを操作する方法として、GG20リーダーレスしきい値署名方式(TSS)が採られています。ZRC-20はプロトコルレベルで管理されており、外部チェーンの資産をトラストレスに維持管理することができることから、ネイティブBitcoinにオムニチェーンスマートコントラクトを付与することができると期待されています。

4.4 ZRC-20(BTC)のmint/burnプロセス

ユーザーがBitcoin上に存在するZetaChainのTSSウォレットにBTCを送金すると、ZRC-20コントラクトに反映されます。この際、トランザクションのメモ欄に任意のロジックを指定すると、zEVM上でスマートコントラクトを実行することができます。同様に、ZRC-20(BTC)から、指定したBitcoinアドレスで同量のBTCを受け取ることもできます。

5. まとめ

以上のことから、次のことがわかりました。

• Avalancheが謳うBTCのオムニチェーントークンは、OFTに対応したBTC.bトークンのことであり、BTC.bトークンはAbalanche BridgeによるBTCのラップトークンである。

• Internet ComputerとZetaChainはプロトコルレベルでBitcoinと統合する。また、ラップトークンとしてそれぞれckBTCとZRC-20が用意され、UXが改善される。それぞれのラップトークンはネイティブBTCに裏付けされており、分散化された方法で管理されることから、「ネイティブでラップされていないトークン」と表現されることがある。

また、インフラ部分に参加できるかどうかという点を比較すると、

• Avalanche Bridgeの主要な構成要素であるWardenは限られている。（現状8人）

• Internet ComputerのノードはICA (Internet Computer Association)が発行するDataCenter IDが必要であり、実質コンソーシアム型チェーンである。ICAについてはリサーチしなかった。

• ZetaChainのメインネット立ち上げ後はPoAであるが後にPoSへ移行する予定であり、PoS移行後にノードに参加できるようになると思われる。

と、どの製品も現状においてはパブリックとは言い難いです。また、どの経済圏にアクセスできるかという観点で比較すると、

• BTC.bはAvalancheおよびLayerZeroが対応するチェーンに限られる

• ckBTCはICが接続するチェーンおよびIC自体の経済圏に限られる

• ZRC-20はZetaChainが接続するチェーンおよびZetaChain自体の経済圏に限られる

という結果になりました。

私個人の感想としては、

• BTC.bはアプリケーションレベルで現実に即したレベルで実装できており、今回比較したなかでも一番よく使われている(執筆時)ので評価できる。

• ckBTCとZRC-20はTSSという技術を使い分散化された方法で、プロトコルレベルでネイティブBTCを維持管理しようとしており、志が高く評価できる。

といった感じになります。

6. 参考文献

[1] Cliffford, Intel SGX入門 - SGX基礎知識編, 2019/6/15, https://qiita.com/Cliffford/items/2f155f40a1c3eec288cf.

[2] Conor Leary, Avalanche Bridge: Secure Cross-Chain Asset Transfers Using Intel SGX, 2021/8/6, https://medium.com/avalancheavax/avalanche-bridge-secure-cross-chain-asset-transfers-using-intel-sgx-b04f5a4c7ad1.

[3] Avalanche, Avalanche Bridge Adds Native Bitcoin Support, 2022/6/23, https://medium.com/avalancheavax/avalanche-bridge-adds-native-bitcoin-support-6306236fb506.

[4] Avalanche, LayerZero Aims to Create One, Unified Experience for BTC.b, Expanding BTC.b Transfers to Ethereum, Polygon, Arbitrum, Aptos, and more., 2022/11/18, https://medium.com/avalancheavax/layerzero-aims-to-create-one-unified-experience-for-btc-b-339eb4d23672.

[5] 株式会社日本総合研究所 先端技術ラボ, Internet Computerの概要 ～クラウドコンピューティング基盤を目指すブロックチェーン～, 2022/5/30, https://www.jri.co.jp/MediaLibrary/file/column/opinion/pdf/13450.pdf.

[6] hokosugi, Bitcoin 統合の仕組み ー 技術的背景, 2022/11/28, https://dfinityjp.netlify.app/docs/current/developer-docs/integrations/bitcoin/bitcoin-how-it-works.

[7] Manu, Chain-key Bitcoin (ckBTC): bitcoin wrapped by a smart contract, 2022/12/22, https://forum.dfinity.org/t/chain-key-bitcoin-ckbtc-bitcoin-wrapped-by-a-smart-contract/17606.

[8] hashigo, ZetaChainのオムニチェーンスマートコントラクトとクロスチェーンメッセージング, 2022/11/28, https://mirror.xyz/hashigo.eth/CCdB_j-jtbl1zlRdGDOlwIn1zGdbMklzNURJemXkAYI.

ZetaChainは、クロスチェーン間のメッセージングやオムニチェーンコントラクトを実現するL1のブロックチェーンです。

ホワイトペーパーの日本語訳（非公式）はこちら：

https://hashigocchi.notion.site/ZetaChain-3c11c23b69df4bf881e2928c33a0d868

また、ホワイトペーパーの要約も用意してあります：

https://mirror.xyz/hashigo.eth/5BL0waxhAABJQORAsDLEkn5qbFa5lYWKEnZ8-l_inDs

本記事を読む前に、以上の内容に目を通すことを推奨します。

2. ZetaChainのアーキテクチャ（おさらい）[1]

2.1 概要

ZetaChainはCosmos SDKとTendermint PBFTコンセンサスエンジン上に構築されたProof of Stake (PoS)ブロックチェーンです。よって、ZetaChainは高速なブロック時間（〜5秒）とインスタントファイナリティを享受しています。Tendermint PBFTコンセンサスエンジンは、実運用で300ノードまで拡張可能であることが示されています。将来的にBLSしきい値署名によるアップグレードで、その数は1000以上まで増える可能性があります。ZetaChain上のトランザクションのスループットは、効率的なTendermintコンセンサスプロトコルにより、100TPSに達する可能性があります。

ZetaChainのアーキテクチャは、しばしばバリデータと呼ばれるノードの分散ネットワークで構成されています。バリデータは、関連する外部の状態とイベントに関するコンセンサスに達する分散型オブザーバとして機能し、また、分散キー署名によって外部のチェーン状態を更新することができます。ZetaChainは、分散型（単一障害点なし、トラストレス、パーミッションレス）、透明、かつ効率的な方法で、これらの機能を達成します。各バリデータ内に含まれるのは、ZetaCoreとZetaClientです。ZetaCoreはブロックチェーンを生成し、複製されたステートマシンを維持する責任を負います。バリデータのオペレータは、このアーキテクチャの異なるコンポーネントを実行します（下記参照）。

2.2 バリデータ

バリデータは3つの異なる役割で構成されています。Basicバリデータ、オブザーバ、TSS署名者です。バリデータは、トランザクションを処理し、ネットワークを安全に保つというサービスの対価として、トランザクションからの手数料と報酬が分配され、受け取ります。オブザーバーとTSS署名者は、セキュリティや掛け金の要件が異なるため、Basicバリデーターとは別の規模になります。

2.2.1 Basicバリデータ

ZetaChainは、部分的な同期ビザンチンフォールトトレラント（BFT）コンセンサスアルゴリズムであるTendermintコンセンサスプロトコルを使用します。各バリデータ・ノードは、拘束/委任されたステーキングコイン（ZETA）に比例した投票権により、ブロックの提案に投票することができます。各バリデーターはコンセンサス公開鍵によって識別されます。バリデータは常にオンラインである必要があり、常に成長し続けるブロック生成に参加します。バリデータはそのサービスの対価として、ブロック報酬と取引手数料を受け取ります。

2.2.2 オブザーバ

ZetaChainのコンセンサスにとって重要なもう一つの参加者は、外部のチェーンイベントと状態についてコンセンサスを得るオブザーバです。オブザーバは、外部チェーンの完全なノードを介して、特定のアドレスで特定の関連する取引、イベント、状態について、外部接続チェーンを監視します。オブザーバはシーケンサと検証者の2つの役割に分かれます。シーケンサは関連する外部のトランザクション/イベント/状態を発見して検証者に報告し、検証者はZetaChainを検証して投票し、コンセンサスを得ます。このシステムには、少なくとも1人のシーケンサと複数の検証者が必要です。シーケンサはトラストされる必要はありませんが、少なくとも1つの正直なシーケンサが必要です。

2.2.3 TSS署名者

ZetaChainは、外部チェーンとの認証された相互作用のために標準的なECDSA/EdDSAキーをまとめて保持します。鍵は、それらの超多数だけがZetaChainを代表して署名できるような方法で、複数の署名者の間で分配されます。重要なことは、いかなる時も、単一のエンティティまたはノードのごく一部が、ZetaChainを代表して外部チェーン上でメッセージに署名できることを確実にすることです。ZetaChainシステムは、経済的安全を確保するために、担保つきのステークと正/負のインセンティブを使用します。

2.3 Zeta EVM (zEVM)とオムニチェーンスマートコントラクト

Zeta EVM（zEVM）は、ZetaChainのコアブロックチェーン上に構築されたオムニチェーンスマートコントラクトをデプロイして使用できるEthereum互換の仮想マシンです。zEVM上のコントラクトはZetaChainの相互運用性レイヤーに接続されており、外部チェーン上のアセットをあたかも単一のチェーン上にあるかのようにオーケストレーションすることが可能です。

2.4 クロスチェーンメッセージング

ZetaChainの相互運用性アーキテクチャを通じて、接続されたチェーン上の既存のスマートコントラクトに3つの機能を実装することにより、任意のチェーンから任意のチェーンへメッセージ（データと価値）を送信することができます。ZetaChainのメッセージングシステムは、ZETAコインのワンウェイペグ機構により、新たなブリッジやラップアセットを必要としないネイティブな価値転送を可能にします。ガス代などの手数料はすべてユーザーが一括して支払うことができるため、開発者はシームレスなUXを提供することができます。また、メッセージングは、トランザクションの失敗時の復帰処理をサポートするため、より予測可能で直感的な開発者体験を生み出します。

3. オムニチェーンスマートコントラクトとメッセージング

3.1 ZetaChainのメッセージングとスマートコントラクトの違い[2]

メッセージングは、スマートコントラクトがZetaChain上であろうと外部チェーン上であろうと、開発者が、スマートコントラクト間でデータと値を送信することを可能にします。1つは、外部チェーン上のスマートコントラクトを展開し、LayerZeroのような他の相互運用性メッセージングプロトコルと同様の方法でZetaChainを介してそれらの間でメッセージを渡すだけですが、ZetaChainの相互運用性スマートコントラクトは、開発者が単一の場所内のオムニチェーンロジックを維持し、オーバーヘッドを減らし、BitcoinやDogecoinなどの非スマートコントラクトチェーンでさえ制御できるスマートコントラクトロジックを許可します。

3.2 オムニチェーンスマートコントラクトとメッセージングの比較[3]

あなたのアイデアをもとに開発を始めるとき、あなたはどのように自分のdAppを構築するべきか疑問に思うかもしれません。ここでは、アプリケーションのアーキテクチャを決定するのに役立つ考慮事項をいくつか紹介します。

3.2.1 アーキテクチャの決定

古いソリューションであるメッセージパッシングでは、別のブロックチェーンにメッセージを転送するためのリレーとしてのみZetaChainが使用されます（例：Ethereum → BSCなど）。dAppは、接続された各チェーン上に少なくとも1つのコントラクトをデプロイします。dAppのステートとロジックは、非同期メッセージで接続されたこれらのチェーン上のすべてのコントラクトに散在しています。これは、一方向の非同期ロジックやエフェクトのみを必要とし、統一されたステートを必要としない、または恩恵を受けない特定のアプリケーションにとっては理にかなっています。

オムニチェーンスマートコントラクトとZRC-20トークンを使用した新しいアーキテクチャは、非常に異なるトポロジーを持ちます：dAppにはzEVM上の1つのコントラクトのみが必要で、外部のチェーンにはdAppコントラクトは必要ありません。zEVMはZRC-20コントラクトを経由して外部チェーン上のコインを管理します。ZRC-20コントラクトについては次の章で説明します。

dAppは、以下の考慮事項に基づき、これらのソリューションのいずれかを活用することができます。

3.2.2 dAppの複雑さ

メッセージングを使用する場合、異なるチェーン上の多くのコントラクトにメッセージと状態同期をブロードキャストする必要があり、これは実質的により多くの攻撃対象とガス代（各メッセージは追加のガス支払いを必要とし、完全な状態同期を維持するために送信しなければならないメッセージ数はスケールします）につながる可能性があるからです。

3.2.3 既存のEVMコントラクトの上での構築

Uniswap V2/V3、Curve、Aave、Compoundなど、Ethereum上で監査とテストが行われた共通のアプリケーションは、ZetaChainで簡単に展開でき、その上に構築されることができます。ZRC-20との互換性を追加することでこれらのアプリケーションを拡張することはできますが、それらの変更は最小限であり、ロジックの大部分は同じままで、ユーザーはEthereum上で行うのと同じようにシングルステップのトランザクションでこれらのアプリケーションとやり取りすることができます。一方、メッセージングでは、多くの状況（特に複雑なもの）で、開発者は「車輪を再発明する」必要があります。つまり、まったく別の非同期メッセージングおよびステートシンクシステムでロジックを作り直す必要があり、メッセージングでは既存のアプリケーションを同じように活用することができません。

3.2.4 非スマートコントラクトチェーンのサポート

ZRC-20はBitcoin/Algorand/Cardano/XRPを簡単にサポートできますが、スワップ、融資などのアプリケーションのための汎用スマートコントラクトをサポートする能力はなく、非効率です。メッセージングには、接続されたチェーン上のスマートコントラクトが必要なため、これらのチェーンではメッセージングが機能しません。

3.2.5 外部におけるガス代

ZRC-20は、外部チェーンとのやり取りがファンジブルなコインに限定されているため、多くのユースケースでメッセージパッシングよりも大幅にガスコストが低くなる可能性があります。（ETH/BNB/MATICの標準Transferには21kガス、ERC20トークンの移動には約60kガスのコストがかかります; 外部チェーン上でロジック/状態がないことはガスコストを大幅に削減します）。メッセージパッシングは本質的に送信元/送信先のチェーンでメッセージデータを処理する必要があり、検証作業等のために追加のガスコストがかかります。

3.2.6 流動性の一元化

オムニチェーンスマートコントラクトでは、ネイティブアセットの流動性を直接ペアリングし、互いに交換することができます。これは、ネイティブアセットを取引するためのステップを最小限にし（1ステップ）、ブリッジやラッピングのステップや複雑なメッセージの送信を伴いません。例えば、統一されたプールを介して、Ethereum上のETHとPolygon上のUSDCを1ステップで直接取引することができます。メッセージを使えば、既存のチェーン上のUniswapプールのような既存の流動性を活用し、ZetaChainを通じてZETAを焼却/造幣することで取引することができます。このアプローチはより複雑（より多くのトランザクションを含むため、ガス代がかかる）かもしれませんが、ZetaChainのエコシステム内の流動性に依存しません。オムニチェーンスマートコントラクトとメッセージングの両方が統一された流動性へのアプローチを提供する一方で、彼のシステム要件に基づいて選択するのは開発者次第です。

3.2.7 例外処理

ZRC-20/zEVMでは、トランザクションが処理されると同時に、外部とのやり取りが標準のERC-20/コントラクトとのやり取り（成功）、またはコントラクトとのやり取りなし（失敗）に限定されるため、例外/復帰処理がはるかにシンプルになります。それに比べ、メッセージングでは復帰処理をサポートしていますが、dApp（とユーザー）はエラーを首を長くして待ち、非同期/イベント駆動の方法で処理しなければなりません。

3.3 メッセージングとzEVMスマートコントラクトの比較例[3]

これらの2つの大まかな例は、オムニチェーンスマートコントラクトで構築する場合とメッセージングで構築する場合の違いを示しています。

3.3.1 Curve/マルチアセットプールの例

まず、Curveを検証してみましょう。Bitcoin上のBTC、Polygon上のMATIC、Ethereum上のETHでEthereum上にCurveプールを作成することを想像してください。

1. BTCとMATICをEthereumにブリッジする必要があります（新しいラップされたアセットwBTCとwMATICを作成するか、BTCとMATICを表すような、ブリッジvaultに依存する何らかのネイティブ/既存アセットとのスワップを試みる必要があります）。

2. これらのアセットのために作成されたプールに入金します。

3. 流動性を引き出すには、プールから引き出して、これらのラップされたバージョンのアセットを受け取る必要があります。

4. それらを一つ一つ、PolygonとBitcoinに戻すブリッジによってアンラップします。

5. 誰かがこのプールを通してスワップする場合、その人はラップされたアセットを受け取り、その後、最終的にそれらを送信したい場所にアセットをアンラップ/ブリッジします。

その代わり、BTC、MATIC、ETHをネイティブに管理するオムニチェーンスマートコントラクトを使えば、以下のようなシステムが実現できます。

1. BTC、MATIC、ETHのアセットをZetaChain上のプールにネイティブに、単純な送金（または同等の）トランザクションを通じて、ワンステップで入金することができます。

2. ZetaChain上の単一のトランザクションで、それぞれのネイティブチェーン上のあなたのアドレスに引き出すことができます。

3. もし誰かがこのプールを通してスワップしたいのであれば、ネイティブアセットを送ることで取引でき、その人はネイティブアセットを直接（例：BitcoinアドレスにBTCを直接）宛先に受け取ることができ、これらのトランザクションはすべて1ステップで行います。

オムニチェーン・マルチアセットプールでは、以下のことが可能です。

• LPとスワップするユーザーの双方にとって、より少ないステップ（ガス、時間の節約になります）

• スワップ＋引き出しが単一のトランザクションで行われ、メッセージングやブリッジングによる非同期タイミングに依存しないことによる、スリッページ最小化

• ユーザーアセットはブリッジやラップされたアセットvaultに対する脅威にさらされないず、リスクプロファイルの大幅な減少

3.3.2 レンディングの例

オムニチェーンスマートコントラクトの機能は、クロスチェーンレンディングのような複雑なアプリケーションではさらに有利になる可能性があります。基本的な借入フローを想像すると、異なるチェーンとの間のメッセージで次のような手順になります（もちろん、これを実装する方法はたくさんあります）。

1. チェーン1上にアセットAの担保を預ける。

2. チェーン1にアセットAの担保を預ける。チェーン2にチェーン1の担保Aに対してBの借入を要求する。

3. プロトコルはチェーン1の担保額を確認するメッセージを送信する。

4. プロトコルはチェーン2に対して、元のリクエストを検証するメッセージを返送する。

5. プロトコルは、チェーン1から受け取ったメッセージに基づくA/Bの（何らかのオラクル）価格に基づいて、チェーン2のBを一定量だけ借りることができる。

6. プロトコルは借り手に金額を送信する。

その代わり、ZetaChain上のオムニチェーン対応貸出スマートコントラクトを使えば、貸出は次のようなステップになります。

1. チェーン1のアセットAとチェーン2のアセットBを管理するzEVM上のAaveのようなコントラクトプールに担保を預け入れる。

2. 借り手は、その担保Aに対して、オラクルチェックに基づいてアセットBの借入を要求し、すべて単一の同期関数内で、ターゲットの宛先に送信される。

4. ZRC-20[4]

ZRC-20は、ZetaChainのオムニチェーンスマートコントラクトプラットフォームに統合されたトークン規格です。ZRC-20を使用すると、開発者は、接続された任意のチェーン上でネイティブアセットをオーケストレーションするdAppsを構築することができます。これにより、オムニチェーンDeFiプロトコルやオムニチェーンDEX、オムニチェーンレンディング、オムニチェーンポートフォリオ・マネジメントなどのdAppsが構築できます。さらに、複数のチェーン上のファンジブルトークンを含むあらゆるものを1つの場所から、極めて簡単に、まるですべてが1つのチェーン上にあるかのように構築できるようになります。

4.1 はじめに

ZRC-20トークンは、Ethereumエコシステムで見られる標準的なERC-20トークンの拡張版で、ZetaChainに接続されたすべてのチェーン上のアセットを管理する能力が追加されています。Bitcoin、Dogecoin、他のチェーン上のERC-20同等物、他のチェーン上のガスアセットなど、あらゆるファンジブルトークンはZetaChain上でZRC-20として表され、（ERC-20など）他のファンジブルトークンと同じようにオーケストレーションできるかもしれません。

4.2 インターフェース

ZRC-20はERC-20をベースに、ZetaChainのCross-Chain Transactions（CCTXs）と統合するために3つの追加関数といくつかの関連イベントを追加しています。

pragma solidity 0.8.7;
interface IZRC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address recipient, uint256 amount) external returns (bool);
    function allowance(address owner, address spender) external view returns (uint256);
    function approve(address spender, uint256 amount) external returns (bool);
    function transferFrom(
        address sender,
        address recipient,
        uint256 amount
    ) external returns (bool);
    function deposit(address to, uint256 amount) external returns (bool);
    function withdraw(bytes memory to, uint256 amount) external returns (bool);
    function withdrawGasFee() external view returns (address, uint256);
    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
    event Deposit(bytes from, address indexed to, uint256 value);
    event Withdrawal(address indexed from, bytes to, uint256 value);
}

ZRC-20とERC-20を比較すると、入出金のための外部関数が追加され、それぞれに対応したイベントが追加されています。これにより、ZRC-20はERC-20用に構築されたあらゆるアプリケーションと完全に互換性があり、かつ極めてシンプルなインターフェースでオムニチェーン的な機能も実現できます。

4.2.1 deposit

ユーザーが接続されたチェーン上のZetaChain TSSアドレスにアセットを送信/預金すると、depositはzetacoreによって呼び出され、預金したアドレスで利用できるようになります。TXmessageにデータがある場合、システムコントラクトDepositAndCallが呼び出され、ターゲットzEVMコントラクト上のonCrossChainCallへの呼び出しによってそのデータを転送します。depositと DepositAndCall関数は CCTX モジュール（zetacore モジュール）アドレスによってのみコール可能です。

これはシステムコントラクトがどのように見えるかのスニペットで、ZetaChainネットワークによって管理されるTSSアドレスへの預金を受け取った後、zetacoreによってDepositAndCallが呼び出される可能性があります。

contract SystemContract {
    address public constant FUNGIBLE_MODULE_ADDRESS;
    // ...
    constructor(address fungibleModule) {
        FUNGIBLE_MODULE_ADDRESS = fungibleModule;
    }
    // ...
    function DepositAndCall(address zrc20, uint256 amount, address target, bytes calldata message) external {
        require(msg.sender == FUNGIBLE_MODULE_ADDRESS);
        require(target != FUNGIBLE_MODULE_ADDRESS && target != address(this));
        IZRC20(zrc20).deposit(target, amount);
        zContract(target).onCrossChainCall(zrc20, amount, message);
    }
}

// a contract that implements this interface may be called by a ZRC-20 deposit call
interface zContract {
    function onCrossChainCall(
        address zrc20,
        uint256 amount,
        bytes calldata message
    ) external;
}

4.2.2 スマートコントラクトチェーンからzEVMコントラクトを入金して呼び出す方法

これは、入金するためにAthens 2のTSSアドレスにトランザクションをdepositするために、Ethereumのチェーンから呼び出す例です。

import { parseEther } from "@ethersproject/units";
import { ethers } from "hardhat";
// This is a constant address, the TSS address of the ZetaChain network.
import { TSS_ATHENS2 } from "../systemConstants";
// Primary function definition
const main = async () => {
  // Get signer in order to write transction.
  const [signer] = await ethers.getSigners();
  // Sign a transaction that sends Ether to the TSS address.
  const tx = await signer.sendTransaction({
    to: TSS_ATHENS2,
    value: parseEther("100")
  });
  // That's it! ZetaChain will pick up the transaction.
  console.log("Token sent. tx:", tx.hash);
};
main().catch(error => {
  console.error(error);
  process.exit(1);
});

代わりにDepositAndCallを行いたい場合、同様のパターンを行うことができますが、Depositコールにデータを含めることができます。この例では、zEVM上に存在するswapコントラクトを呼び出しています。

import { BigNumber } from "@ethersproject/bignumber";
import { parseEther } from "@ethersproject/units";
import { getAddress, isNetworkName } from "@zetachain/addresses";
import { ethers } from "hardhat";
import { ZRC20Addresses, TSS_ATHENS2 } from "../systemConstants";
import { network } from "hardhat";
// Helper function to format data for sending a swap transaction
const getSwapData = (zetaSwap: string, destination: string, destinationToken: string, minOutput: BigNumber) => {
  const params = getSwapParams(destination, destinationToken, minOutput);
  return zetaSwap + params.slice(2);
};
// Primary function definition
const main = async () => {
  if (!isNetworkName(network.name) || !network.name) throw new Error("Invalid network name");
  // Here you're choosing the target token you want the swap to output based on the network
  const destinationToken = network.name == 'goerli' ? ZRC20Addresses['tMATIC'] : ZRC20Addresses['gETH']
  console.log("Swapping native token...");
  // Get a signer to write your transaction
  const [signer] = await ethers.getSigners();
  // Get the correct address of the swap contract (using a helper function)
  const zetaSwap = getAddress({
    address: "zetaSwap",
    networkName: "athens",
    zetaNetwork: "athens"
  });
  // Use formatting function to get the correct data format
  const data = getSwapData(zetaSwap, signer.address, destinationToken, BigNumber.from("0"));
  // Sign your transaction with Swap data.
  const tx = await signer.sendTransaction({
    data,
    to: TSS_ATHENS2,
    value: parseEther("0.5")
  });
  console.log("tx:", tx.hash);
};
main().catch(error => {
  console.error(error);
  process.exit(1);
});

初期にサポートされるアセットは、Bitcoinを含むすべての接続されたチェーン上のZETAとガスアセットです。プロトコルは、将来のアップグレードですべてのファンジブルトークンに拡張される予定です。

4.2.3 BitcoinからzEVMコントラクトを入金・呼び出しする方法

Bitcoinでテストするためには、OP_RETURNを設定できるウォレットを使用する必要があります。

ZRC-20やZetaChainエコシステムの残りの部分で使用するためにZetaChainにBitcoinを入金するには、ZetaChainのTSSによって管理されるアドレスにBitcoinを送る必要があります。トランザクションは、以下のドキュメントにあるようにフォーマットされたOP_RETURNを含むべきです（｜記号は可読性向上のためのもので、実際のメッセージにはそれらを含めるべきではありません）。

z|0xcc7bb2d219a0fc08033e130629c2b854b7ba9195|00000000000000000000000000000000000000000000000000000000000

• 文字「z」は定数で、OP_RETURNが有効であることを確認するためにZetaCoreによって使用されます。

• アドレスは、トランザクションがzEVMコードを実行する場合はコントラクト、zBTCを送りたいだけの場合はアカウントにすることができます。

• メッセージは任意であり、宛先のコントラクトによって解析されます（ある場合のみ）。

無効な情報が送信された場合（例：無効なアドレス）、アセットは元の送信者アドレスに戻されます。

要約すると、zEVMのBTCトランザクションは次のようになります。

• ユーザーはBitcoinネットワーク上で1BTCをBitcoinTSSアドレスに送り、txに（OP_RETURN経由で）「deposit to 0x1337」というメモを（口語で）追加します。

• このTXを受信すると、ZetaCoreステートマシンは、手数料を差し引いた1zBTCを0x1337に鋳造(mint)してクレジットするために、deposit (0x1337, 1e8)を呼び出します。

• 0x1337がExternally Owned Account（EOA）であれば、それでおしまいです。それがコントラクトであれば、ZetaCoreはOP_RETURNメモで指定されたメッセージを送信するonCrossChainMessage関数を呼び出します。

TSSアドレスはBTCを保持しており、このBTC ZRC-20コントラクトの内部で所有権が追跡されます。

4.2.4 withdraw

withdraw関数は、任意のExternally Owned Account (EOA)またはスマートコントラクトから呼び出されます。この関数は、金額が焼却され、Withdrawal()イベントを残すことを除けば、transfer()と同じようなものです。このイベントはzetacoreモジュールでCCTXをトリガーし、zetaclientはそれをピックアップしてアウトバウンドのtxを処理します。この例では、ある与えられた2つのトークンのプールを持つ、既存のUniswapデプロイメントを使用しています。onCrossChainCallが呼び出されると、ターゲットZRC-20トークンへのスワップを実行し、それをネイティブチェーン上のアドレスに引き出します。

contract ZEVMSwapApp is zContract {
    address public router02; 
    constructor(address router02_) {
        router02 = router02_;
    }
    
    // Call this function to perform a cross-chain swap
    function onCrossChainCall(address zrc20, uint256 amount, bytes calldata message) external override {
        address targetZRC20;
        address receipient;
        uint256 minAmountOut; 
        (targetZRC20, receipient,minAmountOut) = abi.decode(message, (address,address,uint256));
        address[] memory path;
        path = new addressUnsupported embed;
        path[0] = zrc20;
        path[1] = targetZRC20;
        // Approve the usage of this token by router02
        IZRC20(zrc20).approve(address(router02), amount);
        // Swap for your target token
        uint256[] memory amounts = IUniswapV2Router01(router02).swapExactTokensForTokens(amount, minAmountOut, path, address(this), block.timestamp);
        // Withdraw amountto target recipient
        IZRC20(targetZRC20).withdraw(abi.encodePacked(receipient), amounts[1]);
    }
}

この例がいかにシンプルであるかに注目してください。20行程度のコード（その多くは汎用コード）で、ユーザーがネイティブアセットと他のネイティブアセットを交換できるクロスチェーンスワップdAppを作成できます。これらのシンプルな機能を組み合わせることで、オムニチェーンアプリケーション構築のための強力かつシンプルなソリューションが生まれます。

5. オムニチェーンスマートコントラクトを利用した流動性プール[5]

流動性プールは、ZetaChainの重要な機能と、Cryptoエコシステム全体のためのユーザー体験の向上（手数料の低下、より流動的な取引所、より多用途な金融アプリケーション）の両方を促進します。ZetaChain環境のプールは、コアZETAプール、追加zEVMプール、外部ZETAプールという3種類の主要バケットに分類されます。

5.1 コアZETAプール

[ZETA] / [Gas ZRC-20] Uniswap Pool (on zEVM)は、そのチェーンにアウトバウンドトランザクションを書き込むためにZetaChainによって必要とされるコアプールです。チェーンのサポートが追加されるたびに、ZETAとそのチェーンのネイティブガスアセットの間の対応するプールも作成されます。

ここでは、UniswapV2コントラクトがZETA/gas プールをどのように制御するかを視覚化することができます。流動性は、接続されたチェーンのTSSアドレスに提供され、その後、Uniswap（または任意の交換コントラクト）は、ZETAまたは他のアセットに対してそれらのアセット（ZRC-20）を使用することができます。

例えば、ネイティブガス（ZRC-20）とZETAをペアにしてアウトバウンドトランザクションの支払いを行うコアプールを使って、トランザクションがどのように機能するかを見ることができます。

5.2 追加zEVMプール

どのような流動性プールもzEVM上に作成することができます。ZetaChain上に通常のERC-20トークンを展開し、ZRC-20を通じて外部チェーン・トークンを組み込み、シングルチェーンEVM上と同様に、アプリケーションに必要な流動性プールのあらゆる組み合わせを作成することができます。例えば、ユーザーが異なるアセットに対してより流動的に取引できるように、有用な[ZETA]/[Stablecoin]や[Gas]/[Stablecoin]プールを作成することができます。

5.3 外部ZETAプール

ZETAは、スマートコントラクトのガス代やクロスチェーンメッセージングに使用されるように、ZetaChain上だけでなく、あらゆる接続先チェーン上の両方に存在するオムニチェーントークンです。各チェーン上の[ZETA] / [Gas]などの特定のプールは、メッセージングによるクロスチェーンの価値移転を促進するアプリケーションにとって有用です。また、開発者はメッセージングに使用するために、ZETAを取得するための外部チェーン上のプールを必要とします。

6. クロスチェーンメッセージング[6][7]

クロスチェーンメッセージングは、ZetaChainを含む、任意の接続されたチェーンから任意の接続されたチェーンにメッセージを送ることを可能にします。これらは、一般的にすべてのチェーン間で維持する最小限のロジックまたは状態を必要とし、異なるチェーン間で渡される必要があるデータが一方向にのみ転送されるアプリケーションのために最も理にかなっています。新しいラップアセットを必要とせず、メッセージングを通じてあらゆるデータや価値を送ることができます。

6.1 コネクター

ZetaChainコネクターは、接続された任意のチェーン間でクロスチェーンメッセージ（データと値）を送信することができます。

6.1.1 はじめに

Zetaコネクターを使用してクロスチェーンのスマートコントラクトを作成するために、あなたのコントラクトは以下のようになります。

• メッセージを送信するためにconnector.sendを呼び出す

• メッセージを受信するためにonZetaMessageを処理する

• メッセージを戻すためにonZetaRevertを処理する

6.1.2 チェーン間でデータと値の送信

他のチェーンと相互作用するために、自分のコントラクトからconnector.sendを呼び出します。

interface ZetaInterfaces {
      /**
      * @dev Use SendInput to interact with the Connector: connector.send(SendInput)
      */
      struct SendInput {
          /// @dev Chain id of the destination chain. More about chain ids https://docs.zetachain.com/learn/glossary#chain-id
          uint256 destinationChainId;
          /// @dev Address receiving the message on the destination chain (expressed in bytes since it can be non-EVM)
          bytes destinationAddress;
          /// @dev Gas limit for the destination chain's transaction
          uint256 destinationGasLimit;
          /// @dev An encoded, arbitrary message to be parsed by the destination contract
          bytes message;
          /// @dev ZETA to be sent cross-chain + ZetaChain gas fees + destination chain gas fees (expressed in ZETA)
          uint256 zetaValueAndGas;
          /// @dev Optional parameters for the ZetaChain protocol
          bytes zetaParams;
      }
    }

    interface ZetaConnector {
        function send(ZetaInterfaces.SendInput calldata input) external;
    }

6.1.3 onZetaMessage

ソースコントラクトがconnector.sendを呼び出した後、ZetaChainシステムは、メッセージを宛先チェーンに転送し、コントラクトアドレスdestinationAddressでonZetaMessageを呼び出します。オプションとして、送信側コントラクトは、価値をクロスチェーンに移動させるためにいくつかのZETAトークン（ZetaAmount、ZetaConnectorコントラクトによって使われることをApprove）を提供し、宛先チェーン相互作用のためのガス料金をカバーすることが可能です。ZetaChainシステムは、ZETAトークンを宛先チェーンに移動し、それを受信スマートコントラクトdestinationAddressに転送します。宛先チェーンは、このインターフェイスを実装するスマートコントラクトをdeployする必要があります。

interface ZetaInterfaces {
      struct ZetaMessage {
          bytes zetaTxSenderAddress;
          uint256 sourceChainId;
          address destinationAddress;
          /// @dev Remaining ZETA from zetaValueAndGas after subtracting ZetaChain gas fees and destination gas fees
          uint256 zetaValue;
          bytes message;
      }
    }

    interface ZetaReceiver {
      function onZetaMessage(ZetaInterfaces.ZetaMessage calldata zetaMessage) external;
    }

関数内部では、現在のスマートコントラクトが、送信側コントラクトが送信したZetaAmount ZETAトークン（ガス代を差し引いたもの）をすでに受け取っていると仮定することができます。

6.1.4 onZetaRevert

このコントラクト関数呼び出しが何らかの理由で失敗した場合、ZetaChainシステムは、送信側スマートコントラクトのonZetaRevert関数を呼び出します。焼却済ZETAトークンは送信側のコントラクトに払い戻され、送信側のコントラクトはこのクロスチェーンメッセージに関する当該アクションを適切に戻す必要があります。

送信元チェーンのスマートコントラクトもこのインターフェイスを実装する必要があります。

interface ZetaInterfaces {
      struct ZetaRevert {
          address zetaTxSenderAddress;
          uint256 sourceChainId;
          bytes destinationAddress;
          uint256 destinationChainId;
          /// @dev Equals to: zetaValueAndGas - ZetaChain gas fees - destination chain gas fees - source chain revert tx gas fees
          uint256 remainingZetaValue;
          bytes message;
      }
    }

    interface ZetaReceiver {
      function onZetaRevert(ZetaInterfaces.ZetaRevert calldata zetaRevert) external;
    }

送信先トランザクションが失敗した場合、この関数でアプリケーションレベルのロールバックが発生するはずです。

6.1.5 まとめ

ZetaChainのコネクターを使用してあなたのdAppsをマルチチェーンに適応するために、あなたはZetaChainによってサポートされる複数のチェーンにコントラクトをデプロイする必要があります。それらコントラクトは、onZetaMessageおよびonZetaRevertコールバックを実装し、connector.sendを呼び出すことによって、互いの間でメッセージと値を送信することができるようになります。

6.2 用例

https://www.zetachain.com/docs/developers/cross-chain-messaging/connector-api

上記のページの下部に、用例一覧が載っています。クロスチェーンメッセージングによって、以下のことに使うことができます。

• クロスチェーンメッセージ

• マルチチェーン価値転送

• クロスチェーンカウンター

• クロスチェーンNFT

• マルチチェーンスワップ

7. ガス代

7.1 オムニチェーンスマートコントラクトのガス代[8]

ZetaChain上のスマートコントラクトと対話するとき、ユーザーはそのトランザクションのためにガスに費やされる価値の一部を含んでいます。

スマートコントラクトのデプロイメントとスマートコントラクトの呼び出しは、実行するためにガスを必要とします。ユーザはZRC-20入金、メッセージにコントラクト呼び出しを含む、またはZetaChainに直接接続し、zEVMにすでに展開されているコントラクトと対話することにより、外部チェーンからzEVMコントラクトを呼び出すことができます。

ZetaEVMスマートコントラクトのガス市場/メカニズムは、Ethermintに基づいており、EIP 1559 Ethereumガス代と同様の動作をします。このガスシステムは、悪意のあるユーザーがネットワークをスパミングすることを抑止するために構築されています。

7.2 クロスチェーンメッセージングのガス代[9]

ユーザー（ウォレット、コントラクト）は、ZetaChainを通してチェーン間でデータと価値を送るために手数料を支払う必要があります。ユーザーは、接続されたチェーン上でZETA（およびメッセージデータ）をコネクターコントラクトに送信することにより、手数料を支払います。このZETAは、バリデータ／ステーカー／エコシステムプールへの支払い、および送信先でのガスへの支払いに使用されます。ユーザーにとっては、これがすべて1つのトランザクションにバンドルされます。

7.2.1 データサイズ/ストレージに応じた料金の変動

ネットワーク料金には、ユーザーがチェーン上で送信しようとするメッセージサイズ（バイト）に基づくコンポーネントがあります。

これは、ユーザーが経済的に健全でありながら送信できるデータ量を調整するものです。非常に複雑なデータを送信する場合は、より多くのコストがかかります。この仕組みは、スマートコントラクトの手数料の仕組みと同様に、今後の開発により、変動相場制へと移行する予定です。

7.3 Base Fee[8][9]

ZetaChainは、あらゆるトランザクション、クロスチェーンメッセージングトランザクション、またはスマートコントラクトに対して、（例えば）0.01 ZETAのBase Flat Feeを含んでいます。このBase Feeは、ネットワークトラフィックと混雑状況に基づいてネットワークによって調整可能であり、焼却されます。

8. 参考・引用文献

[1] ZetaChain Architecture Overview, https://www.zetachain.com/docs/developers/concepts/zetachain-architecture-overview（アクセス日：2022年11月28日）

[2] FAQ, https://www.zetachain.com/docs/learn/faq（アクセス日：2022年11月28日）

[3] Omnichain Smart Contracts vs. Messaging, https://www.zetachain.com/docs/developers/concepts/smart-contracts-vs-messaging（アクセス日：2022年11月28日）

[4] ZRC-20, https://www.zetachain.com/docs/developers/omnichain-smart-contracts/zrc-20（アクセス日：2022年11月28日）

[5] Liquidity Pools, https://www.zetachain.com/docs/developers/omnichain-smart-contracts/liquidity-pools（アクセス日：2022年11月28日）

[6] Cross-Chain Messaging, https://www.zetachain.com/docs/developers/cross-chain-messaging/overview（アクセス日：2022年11月28日）

[7] Connector, https://www.zetachain.com/docs/developers/cross-chain-messaging/connector-api（アクセス日：2022年11月28日）

[8] Gas Fees, https://www.zetachain.com/docs/developers/omnichain-smart-contracts/gas-fees（アクセス日：2022年11月28日）

[9] Gas Fees, https://www.zetachain.com/docs/developers/cross-chain-messaging/gas-fees（アクセス日：2022年11月28日）

Sismoは、分散化、プライバシー、ユーザビリティに重点を置いたモジュール式の認証プロトコルです。トークン化された証明書（アテステーション）が発行できます。証明書は、バッジ(Non-Transferable Tokens/SBT)で表現されます。 このプロトコルの二つのインスタンスがPolygonにデプロイされました。

• Playground, permisionlessプロトコル: どのチームも、自分たちのコミュニティのためにZK Badgesを作成することができます（factoryまたはチュートリアルを利用した場合）

• Main, curatedプロトコル: ガバナンスを通過したZKバッジを作成することができます

1.1 ZKバッジ

Sismoは、バッジの作成方法について何も明らかにしないZKバッジに強い関心を寄せています。ZKバッジの生成プロセスは、ゼロ知識証明（ZK Proof）に基づき、ユーザーとデータのプライバシーを保証します。

1.2 モジュール方式と相互運用性

Sismoのプロトコルはモジュール式で、複数の種類のバッジが共存しています。これらは、プライバシー、分散化、スケーラビリティに関して異なるトレードオフを行う様々なAttester（スマートコントラクト）によって生成されます。Sismoの最終目標は、多様で相互運用可能なBadgeを実現し、創造的な方法で互いに組み合わされ、認証および評価システムに関する真のイノベーションを促進することです。

2. ZKバッジとは[2]

Web3ユーザーは、自分のウォレットをアプリケーションへのアカウントログインとして使い始めています。アプリケーションは、ENS名やプロフィール画像など、ユーザーのウォレットに関連するオンチェーンデータを取得します。

Badgesは、ユーザーが自分の評判や履歴をウォレットにインポートするための新しいWeb3プリミティブです。これにより、ウォレットをログインシステムとして使用するアプリケーション（トークンゲートアプリケーション、イEthereumアプリケーションへのサインイン、スマートコントラクト）において、ゲートのあるサービスへのアクセスや評判の開示を行うことができます。

2.1 ZKバッジ: プライバシーの守られたバッジ

ZKバッジによって、個人情報をプライバシーに配慮した方法でウォレットに転送することができます。

例えば、Proof of Humanityレジストリのメンバーであれば、新しく作成したウォレットに一つだけ、Proof of Humanity ZKバッジを刻印することができます。このバッジを使って、Web3アプリケーションに接続し、実名を明かさずに自分が人間であることを証明します。

このシステムにより、Sybil耐性アプリケーション、プライベート投票、プライベートエアドロップ、プライベートグループチャットなど、さまざまなことが可能になります。

2.2 ゼロ知識証明とZKミンティング

このMintプロセスにはゼロ知識証明が含まれ、ZKバッジの資格を証明するために使用されたソース・アカウントは誰にも追跡できないことが保証されています。使用している技術は、ユーザーが個人的に資産を転送することを可能にするトルネードキャッシュと非常によく似ています。ここでは、データを個人的に転送します。

2.3 転送不能トークン / SBT

Sismo ZKバッジは譲渡不可能なトークン（ERC1155）で、Soulbound Tokenと呼ばれることもあります。

それらは、"私はEthereumユーザーのトップ0.1%の一部である"、"私は10k以上のTwitterフォロワーを持っている"、"私はProof Of Humanityレジストリの一部である "といったことを証明できます。

ここから、curated badgesとpermissionlessに公開されたバッジを確認できます。

2.4 ユースケース例[3]

• 特定のNFT群のどれかを所有していることを、NFTのあるアカウントを公開せずに公開アカウントで証明する

• Twitterでたくさんのフォロワーを獲得しているアカウントの集合の一部であることを、非公開アカウントで証明する

3. 用語解説[4]

3.1 バッジ(Badge)

認証（アテステーション）を表す譲渡不可能なトークン（ERC1155）。各バッジの裏側には、対象となるアカウントのグループが存在する。バッジを付けるには、そのバッジの対象となるアカウント（ソースアカウントと呼ぶ）を所有していることを証明する必要がある。例えば、「EthereumパワーユーザーZKバッジ」を手に入れたいなら、50トランザクション以上のアドレスを所有していることを証明しなければならない。

3.2 ソースアカウント(Source Account)

ソースアカウント（特定のバッジのための）は、このバッジの適格性を証明するために使用されるアカウントである。ソースアカウントから適格性のproofが生成される。これにより、バッジを宛先アカウントにmintすることができる。ソースアカウントとして（現在のところ）、Ethereumアカウント、GitHubアカウント、Twitterアカウントが使われる。

3.3 宛先アカウント(Destination Account)

（あるバッジにおける）宛先アカウントとは、バッジを受け取るためのアカウントを指す。どんなアカウント（EthereumのEOA）でも指定可能である。つまり、ソースアカウントから宛先アカウントに評判やデータが転送される。

3.4 Vault

Sismo Vaultは、SismoのアプリのUXを向上させるために使用される暗号化されたストレージである。Sismoのサーバーに保存されるが、暗号化されているため、利用者だけがアクセスできる。これにより、バッジの生成に使用したインポート元とインポート先のアカウントを保存するため、Sismoを使用するたびにアカウントを追加する必要性がなくなる。

3.5 Vaultオーナー

Vaultオーナーは、インポートされたアカウントで、Vaultを復号化することができる。デフォルトでは、Vaultにインポートされたすべてのソースおよび宛先アカウントは所有者として設定される。この設定は、Vaultの設定で更新することができる。オーナーアカウントでSismoにサインインすると、Vault全体と、そのインポートされたすべてのソースと宛先が取得できる。

3.6 アカウントのインポート

SismoのVaultにアカウントをインポートするということは、ZKバッジの生成に必要な暗号化ツールを保管することを意味する。アカウントが送信元アカウントとして使用されているか送信先アカウントとして使用されているかにかかわらず、ZKバッジをmintするために必要なZK Proofを後で生成するための最初のステップとして、暗号ツール（シードとコミットメント）を生成する必要がある。Sismoを使用する際にシームレスな体験を提供するために、Vaultはそれら（シードとコミットメント）を保存する。

• シード: アカウントからメッセージに署名することで生成される。シードはsecret（アカウントがオーナーに設定されている場合はVaultの暗号鍵、ZKバッジを生成するために必要なコミットメントなど）を生成するために使用される。

• コミットメント: あなたのシードとアドレスから導き出されるsecretである。これによって、あなたのアカウントからZK Proofが生成される。

4. ガバナンス[5]

Sismoガバナンスは、Sismo Protocolの開発と保守を漸進的に監督・管理するために、2021年10月に発足しました。プライバシー、評判、アイデンティティ、ゼロ知識証明に同様の関心を持つキュレーション世代のメンバーが集まるソーシャルコミュニティとしてスタートしました。 プレイグラウンド環境からキュレーション環境へ移行するためのZKバッジの審査は、Sismoコミュニティが担当します。（ただし、迅速に市場に展開するために、2023年Q1頃まではCore チームが担当します[6]）

4.1 ガバナンスの場

Sismoのガバナンスに参加するために、いくつかのガバナンスの場が用意されており、それぞれが特定の目的をもっています。

Sismo Discordサーバーは、現在Sismoコミュニティの主要なディスカッションハブとなっています。ガバナンスチャンネル(「Governance Cave」セクション)では、ガバナンスに関する事柄やプロセス、過去・現在・未来の改善提案について議論することができます。Announcementsチャンネルでは、新しい提案の投票が可能になったことをコミュニティにお知らせします。

Snapshotは、ユーザーがオフチェーンで意志を伝えることができるシンプルな投票インターフェースです。SismoのSnapshot空間での投票は、投票に使用されたアドレスが所有するSismo ZKバッジが持つ投票力によって重み付けが行われます。

4.2 コミュニティと投票力[4]

Sismo Contributor ZK Badgeは3種類のレベルに分けられます。

• レベル1（ユーザー）: 1つの提案につき、行使できる投票力は1 主に、すでにSismoメインアプリケーションと交流のあるすべてのアドレスと、一部の.sismo.eth ensホルダーが対象です。

• レベル2（インパクトのある貢献者）: 1つの提案につき、行使できる投票力は50 特定のバッジをお持ちの方、Sismo Gitcoinで寄付された方、Sismoのイベントに参加された方、厳選された.sismo.eth ensをお持ちの方などが対象です。

• レベル3（ビルダー）: 1つの提案につき、行使できる投票力は500 Sismoへの積極的な貢献者、および、Sismo Core Teamのメンバー全員が対象です。

4.3 投票力の獲得方法[5]

現在でも投票力を獲得する方法が存在するので、紹介します。

• レベル1

  • CuratedプロトコルでZKバッジを一つ以上獲得したユーザー（Playgroundプロトコルは除く）

• レベル2

  • CuratedプロトコルでProof of Humanity ZK Badge、Ethereum Power Users ZK Badge、ENS Supporters ZK Badgeのいずれか一つでも獲得したユーザー（Playgroundプロトコルは除く）

  • Sismoコアチームメンバーがプロジェクトに貢献したお礼に提供した貢献度POAP（レベル2）を請求した人(POAP IDs: 80235 / User Testing #2 / , 81377 / Contributor #2 /)

• レベル3

  • Sismoコアチームメンバーがプロジェクトに貢献したお礼に提供した貢献度POAP（レベル3）を請求した人(POAP IDs: 37527 / Ziki Testers /, 39515 / Ziki Artists /, 39651 / Ziki Community Managers /, 39654 / Ziki Data Analysts /, 39655 / Ziki copywriters /, 39657 / Ziki cryptographers /, 39660 / Ziki Data creators /, 54045 / Ziki Run /, 66267 / Ziki Contributor Poap/)

5. 技術に関すること[7]

5.1 コミットメントマッパー

コミットメントマッパーは、Sismoが提供するオフチェーンのトラストされたサービスです。これは分離されたインフラストラクチャであり、不変です。アカウント所有者のproofを秘密知識のproofに変換することが可能になります。アカウント所有者は、コミットメントマッパーからレシートを受け取り、自分のアカウントとコミットメント（例えば、secretのハッシュ）を対応付けます。ユーザーのsecretとコミットメントマッパーのレシートの組み合わせが、Delegated Proof Of Ownershipを形成します。

5.1.1 動作原理

ユーザーは、アカウント所有の証明（例：EthereumアカウントのウォレットからのECDSA署名、GitHubやTwitterアカウントなどのWeb2アカウントのOAuth認証）とコミットメント（例：自分しか知らないsecretのハッシュや自分のアカウントのEdDSA公開鍵）をコミットメントマッパーに提出します。 コミットメントマッパーは、アカウント所有者証明の有効性を確認し、データベース上に格納されたマッピングにこのアカウントに対するコミットメントを登録します。アカウントがすでにコミットメントとマッピングされている場合、コミットメントマッパーはエラーを返します。次に、マッパーは署名入りのコミットメントレシートをユーザーに送り、コミットメントスキームの通過を保証します。 コミットメントレシートは、アカウント所有者が新しい所有権証明書を送ることで、いつでも取得することができます。

例: SNARKに適したPoseidonハッシュ関数とEdDSA電子署名スキームを用いたCommitment MapperによるHydra Delegated Proof of Ownershipの一例 Ethereumのアカウントとsecretのコミットメントのため、

• 0x123..defの所有者は、アカウントの所有権を証明するメッセージに署名する

• そのcommitment＝poseidonHash(secret)と共に署名を送信する

• コミットメントマッパーは署名を検証した後、次のキー:値を登録する 　- キー: 0x123...def 　- 値: commitment = poseidonHash(secret)

• コミットメントマッパーは、以下のようなレシートに（EdDSA秘密鍵で）署名する(poseidonHash(0x123...def, poseidonHash(secret))注: ユーザーはこのレシートを使って、SNARKで次の事柄を証明することができるようになる。

1. secretを知っている（SNARKでposeidonHash(secret)を生成している）

2. コミットメントマッパーを通過した（SNARKでコミットメントマッパーのEdDSA署名を検証する）

3. それらのコミットメントマッパーは関連付けられる（SNARKでレシートの構成を確認する）

5.1.2 理由

Ethereumアカウントの所有権を第三者に証明するのは、一般的にメッセージの署名で簡単にできます。同様に、GithubやTwitterのアカウントもOAuthによって簡単に所有権を証明することができます。しかし、ZK-SNARKs回路のような制約のある環境では、それらの所有権の証明は現実的でないほど高価になってしまいます。 例えば、EthereumアカウントのECDSA署名は、SNARK内部で証明するには非常にコストがかかります。EdDSAアドレス（SNARK内で証明・検証するのが安価）で受け取ったコミットメントマッパー署名を使用することで、Sismoはこの問題を緩和しています。 また、ECDSA署名はmalleable（ECDSAを使用して複数の異なる有効な署名を作成できる）であるため、nullifierとして使用することはできません。Ethereumアカウントに対して単一のコミットメントを強制することで、コミットメントを生成した秘密（ユーザーしか知らない）をnullifierとして使用することができます。

5.1.3 所有権のproofの独立性

興味深いのは、同じくコミットメントを用いるセマフォと比較して、コミットメントマッパは所有権の証明のみを検証する点です。つまり、Delegated Proof of Ownershipは、あらゆるシステムで再利用することができるのです。 例えば、Sismo Hydra-S1 Attestersでは、同じコミットメントを使用して、あらゆるアカウントのグループメンバーであることを証明することができます。グループデータ（例えば、アカウントのリスト）は、所有権のproofとは独立しています。

5.1.4 オーフチェーンコミットメント

マッピングをオフチェーンにすることで、コミットメントマッパーは、それと相互作用するすべてのアカウントのセット（匿名性セットと呼ばれる）を非公開にすることを保証します。SemaphoreやTornado cashなどの他のプロジェクトも同じようなコミットメントを使用していますが（データをリンクしていますが）、匿名性セットを作成し、公にそれを行っています。 我々サイドには、よりオープンなものにするための道があります。匿名性セットが十分に大きくなれば、私たちの正確なデータを公開することができるようになるでしょう。

5.1.5 セキュリティーモジュール

ユーザーは、Sismoによって展開されたコミットメントマッパーをトラストする必要があります。

• アカウント所有者の証明を正しく確認する

• 一つのアカウントにつき一つのコミットメントのみを承認する

• データストア（アカウント識別子のセット）を非公開にする

ベストプラクティスと高いWeb2セキュリティを考慮して、コミットメントマッパーを導入しました。

• コミットメントマッパーは、分離されたインフラに配置されたAWS lambdaを使用して実行されます。AWSアカウント全体がコミットメントマッパーをホストするためだけに用いられています。

• 秘密鍵（例：Hydraのコミットメント受信に署名するEdDSA秘密鍵）は、AWS KMSを使用して保存されます。

• このAWSアカウント内で行われたすべてのアクションはトレースされ、別のアカウントに保存されます。このトレースは変更することができません。つまり、このAWSアカウント内で何が起こったかを正確に監査することができます。

• このAWSアカウント内で行われたアクションがあった場合、Sismoチーム全体にアラートが送信されます。

5.1.6 コミットメントマッパーの未来

私たちは、Sismoへのトラストをより小さくするするコミットメントマッパーの別バージョンを開発中です。コミットメントマッパーの内部で行われる操作は、SNARKの内部で実行され、オンチェーンで検証される予定です。

5.2 アカウントレジストリツリー

アカウントレジストリツリーは、一部のアテスターが使用可能なグループを保存するためのデータ構造として使用されます。

5.2.1 Key-Valueマークルツリー

KVマークルツリーは、key-value storeをマークルツリーで強化したものである。マークルツリーはその葉に以下のデータを格納する: hash(key, value)

5.2.2 アカウントツリー

アカウントツリーはKV Merkleツリーであり、keyと値はアカウントである（例：key＝アカウント識別子、値＝アカウント値） これにより、ツリーのルートにアクセスできる検証者（例えばスマートコントラクト）は、証明者（ユーザー）がKVストアにアカウントを所有していることを簡単かつ安価に検証することができる。この証明者は、検証者にマークルproofを送るだけでよい。

アカウントツリーは、アカウントグループを保存することができる。 例えば、以下のようなグループである。

• アカウント識別子: ENS DAOに投票したすべてのアドレス

• アカウント値: 各アドレスの投票数

• (グループ識別子): 3

  あるユーザー（0x123..defの所有者）は、スマートコントラクト（ルートにアクセスできるアテスター）に対して、5回投票したことを簡単に証明することができる。 彼らは以下の情報を提供するだけである。

• 0x123..defの所有者であることの証明: 自分の秘密鍵によるメッセージの署名

• 5: アカウントの値

• マークルproof（アテスターがアカウントツリーのルートを再構築するために必要なデータ）

  その後、アテスターは次のことを行うだけである。

• 署名の検証

• 葉 = hash(0x123..def, 5)の計算

• マークルproofの検証（マークルproofの要素に対してリーフをハッシュ化し、それがアカウントツリーのルートに対応するかどうかをチェックする）

5.2.3 レジストリツリー

レジストリツリーはKVマークルツリーであり、keyはアカウントツリーのルート、値はアカウントツリーにリンクした特定の値である（例えばHydra-S1ではアカウントツリーの値としてgroupIndexを選択した）。

先ほどの例で言うと、 ENS Votersのグループには、グループ識別子=3が存在。 ENS Votersの以前のアカウントツリーをレジストリツリーに値3として登録することができる。 するとユーザーは、（レジストリツリーのルートにしかアクセスできない）検証者に、次のことを証明できるようになる。

• 登録されたアカウントツリーのいずれかに属するアカウントを持っていること

• アカウントツリーの値が3であること →事実上、自分が3というグループに属していることを証明したことになる。

5.2.4 Hydra-S1アテスター

Hydra-S1アテスターはこのスキームを使って、ユーザーがグループの一部であるアカウントを持っていることを証明できるようにしています。所有権のproofはメッセージに署名するよりも少し複雑ですが、一般的な流れは全く同じです。 このスキームはZK-SNARKで行われ、特定のアカウントでグループの一員であることを証明するためにどのアカウントが使われたかを知ることは誰にも不可能です!

5.3 Hydra ZK証明スキーム

Hydraファミリーは、Hydra Delegated Proof of Ownershipを使用する証明スキームをバンドルしています。

Vitalik Buterinによる以下の記事は、Hydraの背後にある意図と、その背後にあるZK SNARKコンセプトの概要について正確に理解することができます。

Hydraファミリーは現在、三つの証明スキームメンバーを持っています。証明スキームには、その妥当性を検証する検証者のためにproofを生成することができる証明者がいます。

• Hydra-S1証明スキーム(回路, ドキュメント)(S1 Single Source. バージョン1: ひとつのグループメンバーシップ検証) 2名の証明者がHydra-S1証明スキームを実装し、ZK証明書を生成しています。

  • Hydra-S1 Simpleアテスター

  • Hydra-S1 Soulboundアテスター

• Hydra-S2証明スキーム（S2: Single Source. バージョン2：複数のメンバーシップの検証）

• Hydra-M1証明スキーム(M1: Multi Source. バージョン1)

Hydra証明スキームを利用するためには、ユーザは自分のアカウントからトラストされたコミットメントマッパーと対話し、secretのPoseidonハッシュをコミットして、コミットメントマッパーからEdDSA署名付きレシート（自分のアカウント識別子とそのコミットをマッピング）を受け取らなければなりません。 ユーザーのsecretとコミットメントマッパーの署名されたレシートは、Hydra Proof of Ownershipを形成します。 その後、ユーザーはSNARKでそのHydra Proof of Ownershipを使って、自分のアカウントの所有権を証明することができるようになります。

コミットメントマッパーとPoseidonハッシュ関数、EdDSA署名スキームを使用することで、SNARKで安価にDelegated Proof of Ownershipを検証することができます。

すべてのHydra証明スキームは、ひとつまたは複数のHydra Proof of Ownershipの検証を使用します。

5.3.1 Hydra-S1

Hydra-S1 ZK証明スキームはHydraファミリーの中で最初の証明スキームです。

• Hydra = Hydra Delegated Proof of Ownershipを使用（コミットメントマッパー経由）

• S1 Single Source. バージョン1: ひとつのグループメンバーシップ検証

これは、ユーザーがひとつのZK Proofで、与えられたチケット識別子（別名、外部nullifier）と、アカウントツリーで満たされた定義されたレジストリマークルツリーに対して、以下のことを証明することができます。

• 二つのアカウントを所有している

  • ソースアカウント（Hydra Proof of Ownership）

  • 宛先アカウント（Hydra Proof of Ownership）

• ソースアカウントはアカウントツリーの一部である（アカウントツリーマークルproof）

• このアカウントツリーは、レジストリツリーに特定の値で登録されている（レジストリツリーマークルproof）

• 彼らのソースアカウントの値に関する要求は真である

  • 例：「私のアカウントは5より優れている」（非厳密な主張）

  • または「私のアカウント値は厳密に5と等しい」(厳密な主張)

• ticketIdentifier(別名externalNullifier) をソースアカウントのsecret(別名IdNullifier)とハッシュすることによって、userTicket(別名nullifierHash)を正しく生成している

ユーザーチケット(別名nullifierHash)は、ユーザが同じチケット識別子(別名externalNullifier)に対して二つのZKPを使用できないように、検証者によって保存されることがあります。

Hydra-S1 ZK証明スキームは、SismoプロトコルのHydra S1アテスターで使用されています。

Hydra S1 Simpleアテスターにおいて、Hydra S1証明スキームを使用して、ユーザーは以下のことができます。

• グループ識別子で識別される特定のグループアカウントの一部であるソースアカウントを所有していることを証明する(レジストリツリー内のアカウントツリーの値 = groupIdentifier)

• 宛先アカウント（宛先を受信するアカウント）を所有していることを証明する

• グループ内のアカウントの値について要求する

• アテスター内部でオンチェーンに保存されるuserTicketを生成する ticketIdentifierは、グループ識別子として定義されています。これにより、ユーザがグループごとに二つのアテステーションを生成することができないようにします。

これらのステップはすべて、ここで入手可能なhydra-s1circom回路内で実行されます。

5.3.2 Hydra M1

TBD

5.4 Pythia ZK証明スキーム

古代ギリシャの宗教では、PythiaはDelphiにあるアポロ神殿のoracleでした。 Pythia Familyは証明スキームをバンドルし、ユーザーがプライバシーを守りながら中央集権的なサービスによって提供されるオフチェーンデータを証明することを可能にします。 Pythiaの証明スキームの背後にある主な考え方は、中央集権的なサービスがユーザーデータにブラインド署名を行うことです。 これにより、サービスが後でこの署名を証明として使用する際に、ユーザーを追跡できないことが保証されます。

あなたの国民IDはKYCプロバイダーが保管することができます。このデータに従って、あなたは18歳以上のグループに属することができます。

Twitterでのあなたのフォロワー数はTwitter社によって保存されます。このデータにより、あなたは10万人以上のフォロワーを持つツイッターアカウントのグループに所属することができます。

5.4.1 Pythia証明スキームファミリー

証明スキームには、証明を生成する証明者と、その正当性を検証する検証者が存在します。Pythia-1証明スキームでは、ユーザーはブラインド証明スキームを用いてオフチェーンサービスと対話し、プライバシーを保護した形でデータを取得することができます。ユーザーのフロントエンド（証明者）は、次にZK Proofを作成することができます。 検証者は、Pythia-1 Verifierと呼ばれるオンチェーンのスマートコントラクトです。Pythia-1 Verifierは、ZK Proofを検証し、その有効性をTrueまたはFalseのステートメントとして返すスマートコントラクトです。 例えば、SismoプロトコルのPythia-1アテスターの実装では、証明が正しければ、ユーザーはZKをmintできます。Pythia-1証明スキームは、次節で説明する以下の概略図で表されます。

5.4.2 Pythia証明スキーム

Pythia-1証明スキームは、以下のように動作します:

1.ユーザーは自分のフロントエンドでコミットメント(secretのPoseidonハッシュ)を生成する。secretはフロントエンドによってランダムに生成される。

Commitment=PoseidonHash(secret)

2.コミットメントはオフチェーンサービスAPI（KYCプロバイダ、DegenScore、Twitter、Githubなど）に送信される。

3.オフチェーンサービスは、ユーザーの同意を得てユーザーデータを取得する。これは、例えばKYC登録やアカウントの確認となる。

4.オフチェーンサービスは、次にコミットメントレシートを生成する。コミットメントレシートは、ユーザーによって送信されたコミットメントの署名（edDSA）、ユーザーデータの値、およびグループIDである。

CommitmentReceipt=signEdDSA(Commitment, value, groupId)

値としては、例えばTwitterのフォロワー数や、国民IDカードの年齢などが使われる。この値は、ZK証明によって秘密にされる。groupIdは、本人が対象と主張するグループのID（Twitterのフォロワー数が10万人以上のグループ、または18歳以上のグループ）。

5.Commitment Receiptは、ユーザーのフロントエンドに送られる。

6.フロントエンドでは、プライベートとパブリックの入力からZK Proofが生成される。

• 非公開の入力

  • secret

  • 値

  • コミットメントレシート

• 公開の入力

  • バッジのgroupId

  • シビル耐性バッジのためにオンチェーンに保存することができるnullifier

  • オフチェーンサービスの公開鍵

nullifier=PoseidonHash(secret, externalNullifier)

7.このproofは、検証者のコントラクトにオンチェーンで送信される。

8.Verifierコントラクトは、オンチェーンでZK Proofを検証する。

Sismoプロトコルでは、ZK ProofがPythia-1アテスターに送信され、Pythia-1 Verifierコントラクトが呼び出されます。Pythia-1 VerifierコントラクトがZK ProofについてTrueを返すと、Pythia-1 アテスターはアテステーションを発行し、ユーザーがProofに記載した宛先アドレスにZKバッジを発行します。

バッジを受け取った宛先アドレスに、ユーザーのWeb2アカウントをリンクすることはできません。

6. 参考・引用文献

[カバー絵] Sismo Docsのカバーイメージをクロップして載せています

[1] Sismo Docs - What is Sismo?, https://docs.sismo.io/sismo-docs/

[2] Sismo Docs - What are (ZK) Badges?, https://docs.sismo.io/sismo-docs/what-are-zk-badges

[3] Sismo Docs - What are (ZK) Badges? - ZK Badges use cases, https://docs.sismo.io/sismo-docs/what-are-zk-badges/zk-badges-use-cases

[4] Sismo Docs - User DAQ, https://docs.sismo.io/sismo-docs/user-faq

[5] Sismo Governance Documentation, https://sismo.notion.site/Sismo-Governance-Documentation-8d9f6ac5d2f049dfb15de35664602acb

[6] SIP-8: Grant temporary Badge Curation power to Sismo Core Team, https://snapshot.org/#/sismo.eth/proposal/0x996f748f78756db5327bb7b6d2a4b817094274b4343cbdbb55e18ac0f1d9de1f

[7] Sismo Docs - TECHNICAL CONCEPTS - * , https://docs.sismo.io/sismo-docs/technical-concepts/

Gearboxはレバレッジプロトコルである。

誰でもDeFiネイティブな方法でレバレッジをかけることができ、様々なDeFiプロトコルで使用することができる。例として、Uniswapでのレバレッジ取引、YearnやCurve and Convexでのレバレッジファーム、オプションやデリバティブを含む複雑なデルタニュートラル戦略、複雑なポジションを行うストラクチャープロダクトのためのLeverage-as-a-Serviceなどが挙げられる。[1]

2. しくみ

2.1 クレジットマネージャー(Credit Manager)[2]

クレジットマネージャーは、クレジットアカウントを管理するための中核となるコントラクトである。V2においては、クレジットマネージャー自体は低レベルのバックドコントラクトとして設計されている。一つのプールはいくつかのクレジットマネージャーと接続できるが、CreditManagerは一つのプールとしか接続できない。プールからの借入を禁止することも可能だが、各クレジットマネージャーは借入金を返済することができる。

2.2 クレジットアカウント(CA)

GearboxProtocolはAAVEのような過剰担保型のレンディングプロトコルと違い、大きなレバレッジをかけることができる。これを可能にしているのが、クレジットアカウントである。

クレジットアカウントは、ユーザーの資金と借りた資金の両方を含む独立したスマートコントラクトである。アカウントを開設すると、すべての操作はこのアカウントを経由することになり、資産もこのアカウントに留まる。クレジットアカウントは自動化されたDeFiウォレットであり、ポジションを保持するだけでなく、プログラム可能性を備える。クレジットアカウントの資金は負債の担保として使用され、ユーザーはクレジットアカウントに注文を送ることでこれらの資金を操作することができる。[2]

このように、プールから借りた資金はクレジットアカウント内で扱われる。ユーザーはクレジットアカウントをOpenする際に使用したアカウントを用いてクレジットアカウントを操作するため、「レバレッジがかけられるDeFiウォレット」のようなサービスを提供する。戦略を終了したい場合は、クレジットアカウントをCloseして損益を確定することができる。

クレジットアカウントに入金することができる資金には上限があり、DAOによって管理される。また、利用可能なDeFiコントラクトやトークンはホワイトリストによって厳格に管理される。

2.3 プール(Pools)[4]

レバレッジをかける際にクレジットアカウントが借りる資金は、流動性プールに存在する。この流動性プールには誰もが資金を預けることができ、利息を得ることができる。

2.4 清算

ヘルスファクターが1を下回ると、清算人は当該アカウントを清算することができる。この際、Credit Facade関数が用いられる。また、有効期限が切れたアカウントも清算対象となる。[5]

また、価格オラクルとして、Chainlinkなどのオラクルが用いられる。[6]

2.5 Multicall[7]

MulticallはGearbox V2の新機能である。ユーザーは一つのトランザクションでAdapterやCredit Facadeの呼び出しを一括に実行できる。Multicallを使用すると、ガス効率はよくなり、複雑な戦略を一つのトランザクションで実行でき、さらに清算の処理にかかるコストを低減できるといった、多くの利点がある。

3. 実現可能なAPY

V2ローンチによって、以下のツイートのようなAPYが実現できるとされている。

https://twitter.com/GearboxProtocol/status/1544671931143708675

4. DAO[8]

投票は譲渡不可能なガバナンストークンを通して、Snapshotで行われる。DAOはプール、アセット、マルチシグの署名者、その他様々なことを決めることができる。

また、一部のウォレットに権利が集中しすぎないよう、トークンの量に対する投票力の倍率が決まっていたり、会社のウォレットからは投票できないといった制限が課せられている。

参考文献

[1] https://dev.gearbox.fi/docs/documentation/intro (アクセス日：2022/10/12)

[2] https://dev.gearbox.fi/docs/documentation/credit/architecture (アクセス日：2022/10/12)

[3] https://dev.gearbox.fi/docs/documentation/credit/intro (アクセス日：2022/10/12)

[4] https://dev.gearbox.fi/docs/documentation/pools/intro (アクセス日：2022/10/12)

[5] https://dev.gearbox.fi/docs/documentation/credit/liquidation (アクセス日：2022/10/12)

[6] https://dev.gearbox.fi/docs/documentation/oracle/priceoracle (アクセス日：2022/10/12)

[7] https://dev.gearbox.fi/docs/documentation/credit/multicall (アクセス日：2022/10/12)

[8] https://medium.com/gearbox-protocol/gear-token-not-yet-live-and-governance-reverse-voting-escrow-75f367985397 (アクセス日：2022/10/12)

ZetaChainは、あらゆるブロックチェーンと接続するL1チェーンです。先日、ホワイトペーパーとdevnetの立ち上げが発表されました。本ブログでは、ホワイトペーパーの内容を簡単に要約してみようと思います。ものすごく内容を省いたので、逆にわかりにくくなってしまったり、内容の齟齬が生じてしまったりするかもしれません。予めご了承ください。

ホワイトペーパーとウェブサイトはこちら

https://www.zetachain.com/whitepaper.pdf

https://www.zetachain.com/

ZetaChain：ネイティブクロスチェーンスマートコントラクトを備えたブロックチェーン

概要

本ホワイトペーパーでは、EthereumやSolana、さらにはBitcoinといった、あらゆるブロックチェーンと接続する汎用オムニチェーン型スマートコントラクト対応ブロックチェーンである「ZetaChain」を提案する。 ZetaChainは、PoS型ブロックチェーンで、オブザーバと署名者から成る。これにより、資産のラッピングまたはブリッジすることなく、直接的に異なるブロックチェーンと同士の相互作用するオムニチェーンdAppsを可能とする。

1.はじめに

一つのブロックチェーンですべての需要に応えることはできず、マルチチェーンの未来は必然だ。そこで、ブロックチェーン間の相互運用性が重要になるが、今日存在するプロジェクトは、大半が特定のブロックチェーンにのみにしか対応していなかったり、安定性の低いブリッジを介する必要があったりする。本ホワイトペーパーでは、相互運用性を促進する新しいパブリックL1チェーンを提案し、クロスチェーンdAppsへの扉を開く。 ZetaChainのビジョンは、すべての主要なブロックチェーン上のパブリックコンピュータであり、その上にクロスブロックチェーンのdAppsが、パブリックで信頼できる持続的なスマートコントラクトとして容易に構築できるようにすることである。

2.背景：ブロックチェーンの進化

2.1. Bitcoin：オリジナルな分散型通貨

Bitcoinは暗号学、行動経済学、コンピュータサイエンスの技術を駆使した公開台帳である。そのスクリプトはチューリング完全ではないものの、マルチシグや原子スワップなど、シンプルだが有用なアプリケーションをサポートしている。

2.2. Ethereum：スマートコントラクトを備えたプログラム可能なブロックチェーン

Ethereumは任意の状態遷移関数を実装可能なブロックチェーンであり、Bitcoinで採用されたUXTOからアカウントベースへのシステムへ移行することで、表現豊かなアプリケーションのサポートを可能にした。

2.3.マルチチェーンの融合と課題

複数のブロックチェーンが混在する未来は確実であるが、各ブロックチェーンは閉じたシステムである。そこで、クロスブロックチェーンを実現する戦略として、サイドチェーン、リレー、公証スキーム、ハッシュタイムロックコントラクト、ブロックチェーン・オブ・ブロックチェーンズなどが挙げられる。

3. 相互運用性に関する試み

（本ブログでは省略します。）

4. ZetaChainブロックチェーンアーキテクチャ

4.1. 概要

ZetaChainは、Cosmos SDKとTendermint PBFTコンセンサスエンジン上に構築されたPoSブロックチェーンである。バリデータで構成され、関連する外部の状態やイベントに関してコンセンサスを得たり、分散型鍵署名によって外部のチェーンの状態を更新することができる。各バリデータにはZetaCoreとZetaClientが含まれ、前者はブロックチェーンを生成し、複製されたステートマシンを維持し、後者は外部チェーン上のイベントを観察し、アウトバウンドトランザクションに署名する。 バリデータ：ステーキングされたZETAコインに比例する投票力を持ち、ブロックの生成に参加する。 オブザーバ：ZetaChainが接続する外部チェーンのイベントと状態についてコンセンサスを得る。オブザーバはさらに、外部の様子を検証者に報告するシーケンサと、報告内容をZetaChain上でコンセンサスを得る検証者の二つの役割に分けられる。 署名者：ZetaChainは、外部チェーンとの認証された相互作用のための標準的なECDSA/EdDSAキーを集合的に保持する。ZetaChainを代表して署名できるのは、それらの過半数のみとなるように、複数の署名者にキーが配布される。 実際には、上記のシーケンサ以外は同じコンピュータノードに併設される。

4.2. オブザーバ

オブザーバは、独立して外部チェーンの独自のフルノードを使用して観察し、最終決定とみなされる前にZetaChain上でコンセンサスを得る。そして、ZetaChainロジックの実行を自動的にトリガーする。 観察には、アクティブモードとパッシブモードの二つのモードが存在する。後者の「生存性がシーケンサに依存してしまう」という弱点を克服するために、参入障壁を取り除く工夫がされている。

4.3. マルチパーティしきい値署名スキーム

ZetaChainは、外部チェーンの資金を管理し、特権アクション（焼却、造幣、ボールトからの資金移動など）を実行するために、外部チェーンのアカウントを保持する必要がある。アカウントを保持するために、ZetaChainは秘密鍵を持っている必要がある。単一障害点を避けるために、ZetaChainは分散型しきい値署名スキームを必要とする。これは、BitcoinやDogecoinのようなスマートコントラクトではないチェーンや、マルチシグの検証にコストがかかるスマートコントラクトプラットフォームをサポートするためにも必要である。

4.4. クロスチェーンスマートコントラクトとZeta仮想マシン

ZetaChainスマートコントラクトは、外部チェーンの状態と直接対話できるように設計されている。 汎用クロスチェーンスマートコントラクトプラットフォームを設計する上で、非同期性とプログラミングモデルという二つの重要な課題が存在する。前者は、他のチェーンの状態を問い合わせたり変更したりすることは非同期であるということを意味する。よって、状態変更は外部チェーンからのメッセージ（観測）によってトリガーされる。後者は、シンプルで堅牢なUTXOベースを採用すると、アカウントベースと異なり、Uniswapのような複雑なdAppsをサポートできなくなることを意味する。 本ホワイトペーパーでは、UTXOとアカウントベースのハイブリッドなアプローチを模索し、それぞれの長所を取り入れる。基本的には、UTXOを使用して外部ブロックチェーントランザクションを表現・追跡し、アカウントベースのスマートコントラクトを使用してロジックと共有グローバルステートを管理する。

4.5. トランザクション、サブトランザクション、原子性

ブロックチェーンをまたいだトランザクションの原子性をサポートし、安全性を確保するために、スマートコントラクト仮想マシンにいくつかの制約を設ける。主な制約事項は以下の通り。

1. 各UTXOは、一つの出力イベントしか生成できない。

2. クロスブロックチェーンでの価値移転は、すべてZETAトークンでなければならない。

5. ZETAトークン

ZetaChainのトークンZETAは、ZetaChainスマートコンタクトのガス料金を支払うために使用され、さらにボンディング/ステーキング/スラッシングによってPoS ZetaChainブロックチェーンを保護するために使用される。ZETAはまた、ZetaChainのクロスチェーン転送、スワップ、メッセージ配信、およびセキュリティの中核をなす。ユーザーは、ZETAトークンを任意のチェーンAからチェーンBに直接移動できる。メカニズムは一方向のペッグである（つまり、チェーンAでX量を焼却し、次にチェーンBでX量を造幣する）。 以下の理由から、クロスチェーンで価値を表現するために、独自のトークンZETAを使用する。

• ラッピングがないため、同じ原資産を二重に表現することがない。

• クロスチェーンに移行できる（ネイティブな）価値はZETAトークン経由のみであり、攻撃対象が大幅に減少するため、結果として監査が簡便化し、セキュリティも高くなる。

• ユーザーは、ZetaChainが提供するクロスチェーンサービスと、デスティネーションチェーン上のガスに対して、ワンステップ/バンドルでZETAを支払うことができる。

6. ユースケースとアプリケーション

6.1. 値/データによるクロスチェーンメッセージパッシング

一つのチェーンから別のチェーンへ確実かつ安全にメッセージを渡すことができるため、ZetaChainのネイティブスマートコントラクトでなくても、強力なクロスチェーンアプリケーションを実現できる。ZetaChainシステムの特徴は、メッセージにZETAコイン（ネイティブクロスチェーン）の形で価値を付与でき、価値をクロスチェーンで移動する必要があるdAppsをかなり簡素化できることにある。メッセージパッシングにより、クロスチェーンDEX、貸付・借入、マルチチェーンNFTなど、様々な重要なアプリケーションを実現することができる。

6.2. スマートコントラクトで管理される外部資産

Bitcoin、Dogecoin、Moneroなどの主要なブロックチェーンは、AMM取引所などの有用なアプリケーションをサポートできるほど一般的なスマートコントラクト機能を有していない。ZetaChainのクロスチェーンスマートコントラクト機能は、外部チェーン上の資産を直接保有し使用することができるため、ETH、ERC20、Algorand ASAなどの他のネイティブ資産に加え、ZetaChain上のネイティブBitcoinを管理するスマートコントラクトを可能にする。

6.3. クロスチェーンAMM取引所

ZetaChainは、スマートコントラクトの上に構築された真のクロスチェーンAMM分散型取引所を実現することができる。ZetaChain上でAMM DEXを構築する方法には、メッセージパッシングとネイティブZetaChainスマートコントラクトの二つがある。前者ではアセットプールは外部チェーン上のスマートコントラクトによって管理され、後者では、プールはTSSアカウントを介してZetaChainスマートコントラクトによって管理される。

6.4. マルチチェーンNFT

マルチチェーンNFTの世界では、同じNFTのコレクションが複数のチェーン（Ethereum、Flow、Solanaなど）で発行される。あるNFTが他のチェーンに転送できる場合、ブリッジモデルでは、あるNFTの所有者は誰か、転送の取引記録はどこのチェーンにあるのかといった問題が生じる。この問題は、NFTのクロスチェーン所有権移転を促進するZetaChainスマートコントラクトによって解決できる。

7. セキュリティ

7.1. 分散性

ZetaChainのシステムは、主に分散化によって単一障害点を持たないように設計されている。ZetaChainはアーキテクチャ的にもインフラ的にも非中央集権的であり、ノードはパーミッションレスに運営される。 一方、外部のチェーンに変更を加える際には、署名鍵の集中化という問題が生じる。この問題は、GG20リーダレスしきい値署名スキーム（TSS）を利用することで解決を図る。

7.2 インバウンドとアウトバウンドのトランザクションの保護

外部チェーン上の観察されたイベントは、ZetaCoreの状態変化を引き起こすために、ZetaCore上でコンセンサスを得る。また、ZetaCoreの状態変化により、ZetaClientの署名者は、トランザクションを準備・署名し、外部チェーンにブロードキャストする。ZetaChainのコンセンサスメカニズムは、トランザクションが合意されることを保証する。TSSキーは、ZetaClientsの超多数が署名できることだけを保証する。

7.3. 恣意的な造幣に対する包括的な防御策

ZetaChainノードは、ZETAトークンの造幣を開始する前に、チェーン全体の供給量をチェックする。ZETAの総供給量はChainlinkによって提供され、接続された各チェーンに提示される。この保護機能により、誰も恣意的に造幣することができず、ZETAの総供給量がチェーン間で固定されたままであることが保証される。 また、バリデータノードが攻撃者に制圧されるような最悪のシナリオにおいて危険にさらされる資金は、悪用された時点でクロスチェーンに移動しているZETAの量に限られる。静止している資金は危険にさらされない。

7.4. 外部チェーンに対する攻撃

ZetaChainで接続された外部チェーンが攻撃された場合、二重支払い・検閲・原子性を喪失するような復帰・フォークといった違反が発生する可能性がある。しかし、ZetaChainは総供給量がチェックされるため、これらのケースのいくつかを軽減することができる。

8. 結論

ZetaChainは、ほとんどすべての既存または将来のブロックチェーンおよびL2ロールアップへの接続と、それらのチェーン上のネイティブ資産の全供給へのアクセスで構築される分散型クロスチェーンアプリケーションのための最も一般的なプラットフォームを提供する。

1. 過去

2021年後半、Phezzanの2人の創業者は、Apple App Storeのソーシャルネットワーキングカテゴリで100位以内に入ったことがあるスクリーン共有アプリの最後のスタートアップを閉鎖しました。そのビジネスは利益を生むものではありませんでしたが、私たちは人々が求めるものを作りました。今日に至るまで、毎週、ユーザーはいつアプリを復活させるのかと尋ねてきています。

私たち自身は長年のトレーダーであったため、2021年後半にL2がブームになっていたこともあり、DEXの領域を調べ始めました。私たちはあらゆる種類のDEXを試しましたが、CEXのそれとは比べものにならないという結論に達しました。DEXが未来だとしたら、5年後にCEXに勝つためにはどんなDEXが必要なのでしょうか？

2. 現在

さて、ここからは各DEXとその問題点を見ていきます。Phezzanはperp DEXなので、主にperp DEXの話をします。

2.1 AMM形式のDEX

AMMとそのバリエーション（vAMM、PMMなど）は、現在、パーペチュアルDEXで使われている主流の方式です。これはDeFiの最大の驚異の1つです。ブートストラップ流動性、リテールLPの利回り稼ぎの場、そして無限のコンポーザビリティを兼ね備えます。いくつかの取引ペアでは、UniswapはBinanceやCoinbaseと比較して2倍から3倍の流動性を持っています。

AMM型DEXの問題点は単純で、変動損失（IL）です。ILという名称自体には賛否両論ありますが、ILの背景にある考え方は、Crypto投資家が資産を流動性プールに預けて何もしない場合、プール内の資産の価格が大きく動けば、大負けする可能性があるというものです。

学者やプロトコルがいつかILの問題を解決することは間違いありませんが、少なくとも今のところLPはポジションと価格帯を積極的に管理しなければ、AMMの流動性を予測可能なリターンで管理することはできないのです。

2.2 オーダーブック形式のDEX

簡単に言えば、dYdXは現在最も優れたパーペチュアルDEXでしょう。取引量が多く、取引速度が速く、手数料が小さく、流動性が高いです。

オーダーブック・パーペチュアルDEXの問題点は、リテールLPとして、何もできない点です。流動性を提供できないし、利回りも稼げない。プロのマーケットメーカーは自ら流動性を提供し、どの取引ペアが適切かを判断し、マーケットを作ります。

プロのマーケットメーカーは、ボラティリティの高い資産に対する意欲が低く、一般的に新しい市場のリスクを評価するのに長い時間を要します。例えば、dYdXコミュニティは3ヶ月ほど前に$APE/$GMTのような、主要CEXの中で常にトップ10にランク入りしている新しい取引ペアを追加するよう投票したものの、まだ何も起こっていません。

2.3 オラクル式DEX

GMXに代表されるオラクル式DEXが最近注目されています。

オラクル式DEXの問題点は、もう少し複雑です。ここではLPであることのデメリットだけ話します。オラクル式DEXのLPは、基本的にトレーダーに対して賭けることになります。オラクル式DEXのLPは、その取引が有利であろうとなかろうと、あらかじめ決められたオラクル価格の注文をすべて受けなければならないので、収益が予測できません。

簡単に言えば、トレーダーが勝つと、オラクル式DEXのLPは負けます。

2.4 まとめ

上記の3種類のDEXの長所と短所をまとめると、以下の表のようになります。

3. 今後の展開

オラクル式DEXは価格発見がないため、今後主流になるとは考えにくいです。そうなると、残された選択肢は2つになります。

1. 優れたAMMアルゴリズムを設計し、変動損失がないようにする。Phezzanチームにはその能力はない。

2. オーダーブックにリテール流動性をもたらす。オーダーブック形式のDEXで、AMM形式のDEXにいるように、誰もがのんびりとマーケットを作ることができ、しかも変動損失がない。

これこそがPhezzanが実現することです。Phezzan Protocolは、リテール流動性を可能にするオーダーブック形式のパーペチュアルDEXになります。

LPは悪いトレードをする必要はありません。資本効率がよく、変動損失がありません。ボラティリティの高い資産はパーミッションレスでサポートされ、価格発見はPhezzan自体で行われます。

さあ、飛び込んでみましょう。

4. PhezzanはオーダーブックDEXにリテール流動性をもたらす

これ以上つまらない詳細を説明する前に、Phezzan Protocolで流動性を提供する操作がどのように見えるかを見てみましょう。

4.1 Phezzan Liquidity Marketplace

LPがPhezzan ProtocolのWebサイトに入ると、Phezzan Liquidity Marketplaceが表示されます。このページには、プロのマーケットメーカーがオーダーブックでマーケットを行う際に使用するボットやアルゴリズムである、あらゆる種類のオーダーブックマーケットメイキングストラテジー（「MMストラテジー」）が表示されます。

各MMストラテジーは、ヘッジファンドマネージャー（MMストラテジーオーナー）が投資家（LP）から資金を受け取り、投資家に代わって投資（マーケットメイク）し、利益が出れば手数料を受け取る、個別のヘッジファンドのようなものです。

LPは各MMストラテジーの基本情報、例えば関連市場、ストラテジー名、開発者、TVL、APY、手数料レート、開始日、監査済みかどうかなどを見ることができます。

これはあくまで例なので、MMストラテジーは4つだけです。将来的には、数百、数千のMMストラテジーが掲載される予定です。LPは検索、基準によるソート、流動性の管理を簡単に行うことができます。

4.2 ストラテジー詳細ページ

興味のあるストラテジーをクリックすると、その詳細が表示されます。このページにはたくさんの情報があります。早速見てみましょう。

4.2.1 プールの情報と説明

左上には、プール情報と説明が表示されます。これらは、このストラテジーに関する基本的な情報であり、非常にわかりやすいものです。

なお、これらの情報はすべてカスタマイズ可能です。Phezzanにストラテジーを掲載することはパーミッションレスであり、ストラテジー所有者がすべての情報をコントロールすることができます。

4.2.2 APYとTVL

なぜ、人々は他のDEXのプールやPhezzanのストラテジーに流動性を提供するのでしょうか？　素敵なAPYを得るためです！

上のチャートで、潜在的なLPは特定のMMストラテジーのAPYの履歴を見ることができます。

APYと同様に、上記は特定のMMストラテジーのTVLの履歴です。

4.2.3 私が提供する流動性

このパートでは、特定のストラテジーにおけるLPの総ポジションと関連情報を表示します。

4.2.4 流動性のポジション

MMストラテジーの所有者は、在庫リスクをコントロールし、マーケットメイキング活動のために安定したキャッシュ フローを得たいと考えるでしょう。よって、MMストラテジーにはロックアップ時間が必要な場合があります。LPは一つのMMストラテジーに対して、異なる資金量とロックアップ時間の適用のもと、異なる流動性ポジションを提供することができます。

例えば上図のLPは、同じMMストラテジーに対して、300,000ドルと202,154ドルの2つの流動性ポジションを提供しました。この2つのポジションはそれぞれ異なる日にロックが解除されます。

LPは、コードの変更、利益分配の仕組みの変更など、MMストラテジー自体に異常がない限り、ロック解除日前に資本を引き出すことはできません。

Phezzanのロックアップ期間は最短で7日、最長で365日です。1週間より短いものはMMストラテジーのオーナーにとって問題となり、1年より長いものは、ボラティリティの激しい暗号市場にとって長すぎるのです。ストラテジー所有者は、7日から365日の範囲でロック時間の要件を設定することができます。LPが同じMMストラテジーに自動で再投資するオプションも用意される予定です。

4.3 利益分配の仕組み

4.3.1 3つの収入/利益源

さて、「利益分配のメカニズム」に戻ります。ここから面白くなります。

ストラテジーが市場を形成するとき、収益/利益の源泉は3つあります。

「PnL」はMMストラテジーがスプレッドで稼ぐ利益です。Phezzanはオーダーブックモデルを採用しているので、MMストラテジーが優秀であれば、スプレッドで稼ぐことができ、利益の全額がMMストラテジーに支払われます。

「Fee」はPhezzan Protocolからの取引手数料のリベートです。取引手数料の一部はPhezzan Protocolに支払われ、残りはMMストラテジーに支払われます。

「Reward」は、MMストラテジーに配布されるPhezzanトークンです。

他のDEXとは異なり、PhezzanはPnL/Fee/Rewardを個々のアドレスに配布しません。その代わり、Phezzan ProtocolはPnL/Fee/Rewardを各MMストラテジーに分配します。

MMストラテジーのオーナーは、利益分配の仕組みを設定し、ストラテジーに資金を提供したLPと自分との間で収入/利益を分配することになります。

なぜでしょう？

4.3.2 マーケットに決定させる

MMストラテジーのオーナーによってマーケットメイクのスタイルは異なり、流動性への要求も異なります。アリスは高頻度取引を行うマーケットメーカーで、多くの資金を必要としますが、その資金がどの程度ロックされるかはあまり気にしません。ボブは古いタイプの人間で、あるポジションをしばらく持ち続けたいと考えているため、短期間に多くの流動性を得るよりも、安定した流動性を得たいと考えています。

LPによってMMストラテジーや報酬に対する欲求も異なるかもしれません。クレアはより多くのPhezzanトークンを好み、フランクはスプレッドから得られる利益をより多く得たいと考えるかもしれません。

重要なのは、PhezzanチームはMMストラテジーのオーナーとLPの間の最適な利益分配の仕組みを知らないし、これからも知ることがない点です。

LPは多くのMMストラテジーの中から選ぶことができるため、Phezzan ProtocolはMMストラテジーの所有者に利益分配の仕組みを設計させるにとどまります。MMストラテジーオーナーは流動性を高めるため、LPとの利益のバランスを取るため、そして互いに競争するために利益分配の仕組みを設定します。

MMストラテジーオーナーは、市場シェアを素早く獲得するために10%の手数料を設定することも、十分に自信がある場合は90%の手数料を設定することもできます。

また、競争激化を避けるため、最低5%の手数料を設定し、MMストラテジーに関する費用としてPhezzanは一律に受け取ります。

もし、LPがMMストラテジーAの利益分配の仕組みを気に入らなければ、より好ましいMMストラテジーに流動性を提供することができます。

4.3.3 Phezzan戦争

さらに踏み込んでみましょう。

LPがMMストラテジーに資本を預けると、PhezzanはそのMMストラテジーの流動性の所有権を表すERC-721トークンを発行します。

MMストラテジーのオーナーや基礎となる取引ペアのプロトコルチームは、必要に応じてそのトークンを使って、Phezzan Protocolの外部で追加のインセンティブ、つまり「賄賂」を提供することができるのです。これは本質的に、Curve戦争のようなPhezzan戦争を生み出すことになります。

最高のMMストラテジーが勝利しますように。

4.3.4 安全対策

LPの自然な疑問点として、MMストラテジーのオーナーがあなたの資本を持ち逃げしたり、利益分配の仕組みを一夜にして自分たちに有利に変えたり、あるいはハイリスクなストラテジーを実行して、多くを失うことなく多くを稼ぐなどといったことが起こらないことをどうやって知ることができるのか、という点があるでしょう。MMストラテジーのオーナーは、LPの資産を持ち逃げすることはできません。

Phezzanのオンチェーンvaultコントラクトは、各MMストラテジーに関連するLPの資金を追跡します。MMストラテジーは自分のアドレスに関連付けられたLPの資金を使ってマーケットを行うことができますが、vaultから資産を引き出すことはできません。もし、悪意のあるハッカーがMMストラテジーのコードを変更した場合、Phezzanのバックエンドはその変更を検知し、そのMMストラテジーをマーケットメイクから無効化します。よって、検知されたMMストラテジーはマーケットメイキングができなくなります。将来的には、このプロセスは分散化され、コードの侵害をうまく特定した人が報酬を得ることになります。

利益分配の仕組みを変更すると、影響があります。

すべての利益分配の仕組みはオンチェーン、オープンソースでなければならず、月に一度だけ変更することができます。MMストラテジーのオーナーが利益分配の仕組みを変更した場合、そのストラテジーに流動性を提供したLPは、たとえそれがLPのロック解除日前であっても、何の影響もなく合理的な時間内に流動性を引き出すことができます。

リスクの高いストラテジーは可能だが、合理的ではありません。

Phezzan Protocolはすべての人にパーペチュアル取引を民主化することを目指していますが、Phezzanで新しいLPストラテジーを提供することは決して簡単なことではありません。よいMMストラテジーを作れるのは、業界の専門家か、志の高い若い才能のある人たちでしょう。Phezzan Protocolのユーザーのうち、MMストラテジーを作成できる知識と技術的な専門知識を持つ人はごく一部です。

MMストラテジーの掲載はパーミッションレスですが、それでも開発には時間がかかります。Phezzanは、無意味なMMストラテジーのアップロードを避けるために手数料の仕組みを導入し、MMストラテジーが監査済みかオープンソースかDoxxedかを明確に表示し、MMストラテジーの異常な行動を積極的に監視する予定です。

MMストラテジーのオーナーにとってリスクはないわけではありません。

MMストラテジーのオーナーが流動性を得るためには、MMストラテジーが儲かることを証明するために、最初に自己資金を投入する必要があります。MMストラテジーの開発に時間を費やし、MMストラテジーを運用するためにPhezzanに手数料を支払い、評判を落とすリスクもあるのです。

DYOR

Phezzanは、流動性の提供にはリスクがつきものであること、また、詳細な情報が必要であることを理解しています。Phezzanチームはユーザーの資金の安全性を確保するために可能な限りの努力をします。同時に、DYORをお願いします。

5. 利点

では、なぜ誰もがこれを使うのでしょうか？　どんなメリットがあるのでしょうか？

5.1 トレーダーにとって

トレーダーにとって、PhezzanのUI/UX体験は、他の主要なCEXやDEXとあまり変わらないでしょう。

プロのマーケットメーカーは自己資金をあまり投入せず、リテールLPは高いリスクを許容しつつ高いリターンを求める傾向が強いため、MMストラテジーのオーナーはよりボラティリティの激しい取引ペアに投入できるリソースが増え、Phezzanはよりボラティリティの激しいコインのための最高の流動性を持つことができるようになります。

さらに、BTC/ETHのようなブルーチップコインについては、Uniswapで起こったように、Phezzanでも徐々に流動性が高まり、トレーダーにとってよりタイトなスプレッドとより低いスリッページが実現するでしょう。

それは、すべての人のためのパーペチュアル取引の民主化です。

5.2 流動性プロバイダーにとって

Phezzan Liquidity Marketplaceのおかげで、LPは簡単にオーダーブックに流動性を提供できるようになりました。

長期的には、Phezzan ProtocolのLPになることは、AMMスタイルやオラクルスタイルのperp DEXのLPになるよりも収益性が高く、予測しやすいと思われます。

さらに、LPはMMストラテジーの所有者やPhezzan以外のプロトコルから特別なインセンティブを得ることができるかもしれません。

これが流動性提供の民主化です。

5.3 MMストラテジーのオーナーにとって

過去には、大手のプロのマーケットメーカーだけがオーダーブックでマーケットを作ることができました。

しかし、Phezzan Liquidity Marketplaceでは、誰でもMMストラテジーをアップロードして、デカブツに挑戦することができるのです。

ヘッジファンドを辞めたばかりで、マーケットメーキングビジネスを始めたいが、十分な資金がないですか？　Phezzan Liquidity Marketplaceにお越しください。

本当によいMMストラテジーを持っていて、それを試してみたいが、不安定な取引ペアであまりリスクを取りたくないですか？　Phezzan Liquidity Marketplaceにお越しください。

金融やコンピュータサイエンスの強いバックグラウンドがあり、猿のように働きたくなく、ゼロから始めたい？　Phezzan Liquidity Marketplaceにお越しください。

つまり、私たちはそれを心得ています。プロのマーケットメーカーの中には、私たちを笑う人もいるでしょう。私たちは、過去に大儲けした古い堅実な業界に挑戦しようとしているのです。ホテル業界はAirbnbについて、タクシー業界はUberについて、そしてTradFiはDeFiについてそう言っています。

それが、すべての人のためのマーケットメイキングの民主化です。

5.4 BUIDLerにとって

パーミッションレスMMストラテジー・リスティングと並んで、パーミッションレス・トレーディングペア・リスティングがあります。

BUIDLerにとっては、自分のトークンを新しい取引ペアとして上場し、自分のトークン取引ペアのためにマーケットを作ってくれるMMストラテジーのオーナーを見つけ、自分自身のパーペチュアル取引ペアを持つことができ、すべてがパーミッションレスとなります。

これは、すべての人のためのパーペチュアル上場と取引の民主化です。

6. 最後に

ここまで読んでいただき、ありがとうございました。Phezzanチームは、Phezzan Liquidity Marketplaceについてまだ多くの詳細を把握する必要があることを理解しています。この記事は、ミッションステートメントを作るというより、会話を始めるためのものです。

もしあなたが潜在的なトレーダー、LP、MMストラテジーのオーナー、あるいはPhezzan Liquidity Marketplaceが提供するものに興味があるなら、PhezzanのDMはいつでも開いています。

また、Phezzanチームにメール（contact@phezzan.xyz）で連絡したり、TelegramグループやDiscordコミュニティに参加することも可能です。