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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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のメンバー全員が対象です。

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

• レベル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/)

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

ユーザーは、アカウント所有の証明（例：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でレシートの構成を確認する）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 5: アカウントの値

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

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

• 署名の検証

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

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

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

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

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

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

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

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の検証を使用します。

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回路内で実行されます。

TBD

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

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

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

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

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アカウントをリンクすることはできません。

[カバー絵] 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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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のメンバー全員が対象です。

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

• レベル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/)

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

ユーザーは、アカウント所有の証明（例：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でレシートの構成を確認する）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 5: アカウントの値

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

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

• 署名の検証

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

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

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

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

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

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

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

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の検証を使用します。

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回路内で実行されます。

TBD

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

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

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

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

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アカウントをリンクすることはできません。

[カバー絵] 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/