🔑
Lit Protocolを使うための下準備　〜認証編〜

2024/12/26に公開
 認証編LitNodeを使用するために重要なのは、「セッション署名(SessionSigs)」の生成です。
セッション署名は、Lit ノードで認証し、Lit ネットワークへの安全な接続を確立するために使用されます。
特定の Lit リソース (例: PKP) に対して特定のLit 機能(例: トランザクションの署名)を要求する場合は、常にセッション署名の生成が必要です。
セッション署名は、Lit SDKを通じてLitネットワークへの接続を開始したときに生成されるセッションキーを使用して作成されます。これらのセッションキーは、Lit SDKによってローカルに生成されるユニークなEd25519鍵ペアで、現在のセッション中にLitネットワークへのすべてのリクエストに署名するために使用されます。
セッションキーとその署名がセッション中の通信を支援する一方で、AuthSig（認証署名）は、Litノードに対するあなたの身元確認および認証を行うために使用されます。

 AuthSigって何？AuthSigは、ERC-5573に準拠した「Sign-In with Ethereum」機能を持つメッセージであり、セッションで認可されたLitリソースとLit機能を指定します。
AuthSigは、以下のアクションの認可をLitノードに確認させます：
データの復号化

PKPを使用したトランザクションの署名

Lit Actionsの実行
リクエストを行うと、各LitノードはAuthSigをチェックし、そのリクエストが以前に定義された機能に一致していることを確認します。これにより、認可されたユーザーのみがLitネットワーク内で特定のアクションを実行できるようになります。この認証システムは、Litネットワークのセキュリティと整合性を維持します。

 AuthSigの仕組みAuthSigは、ウォレットを利用したデジタル署名によって生成されます。この署名プロセスでは、以下のステップを踏みます：
メッセージの作成

Lit Protocolが指定するメッセージ（例: SIWE - Sign-In with Ethereum メッセージ）をウォレットで署名します。
署名の生成

ウォレットがメッセージに署名し、AuthSigを生成します。このAuthSigには以下の情報が含まれます：

・ウォレットアドレス

・署名データ

・メッセージの内容

・サーバーやLitノードに送信
生成されたAuthSigは、Lit Protocolのノードに送信され、アクセス制御や操作の実行時に使用されます。

 SessionSigsって何？
 SessionSig（セッションシグ）とAuthSigの関係SessionSig（セッション署名）は、AuthSigを利用して生成される一時的な署名です。

 SessionSigの目的・効率的なアクセス管理

AuthSigを使うと、毎回ウォレットで署名を行う必要があります。これを解消するために、SessionSigを作成して一時的に利用することで、同じ認証を効率的に再利用できます。
・有効期限の設定

SessionSigには有効期限が設定されており、期限が切れると再度AuthSigを使った認証が必要になります。

 生成の流れ・AuthSigを使用してセッション署名をリクエスト。

・LitノードがSessionSigを生成してクライアントに返す。

・SessionSigを使用してアクセス制御やLit Actionsを実行。

 SessionSigsの生成セッション署名の生成＝セッション署名内でLitネットワークの利用料を支払うことができます。
セッションキーペアは自動生成されるだけでなく、generateSessionKeyPair()関数を使用して手動で生成することもできます。特にカスタムキー管理が必要な場合（例: サーバーサイドアプリケーション）、これが便利です。
セッションキーペアは、ユーザーのデバイスに固有で、セッションがその環境に安全に保たれるようにします。
ブラウザ環境では、セッションキーはローカルストレージ（lit-session-key）に自動的に保存され、再生成する必要がありません。
セッション署名を生成する関数には、resourceAbilityRequests配列を渡すことができます。この配列で、セッションキーが実行できるアクションの範囲を定義します。
リクエストされたリソースと機能は、AuthSig内で指定された権限と同じか、そのサブセットである必要があります。セッションキーに、AuthSigで元々認可された以上の特権を付与することはできません。
デバッグ時を除き、未指定のアクセス制御条件を許可することはセキュリティ上の脆弱性を引き起こします。

 セッション署名の保存ブラウザ環境の場合、セッションデータはブラウザのローカルストレージに自動的に保存され、追加設定は不要です。

 セッション署名の要素
 SRALitリソースとアビリティは、どのリソースに対してどのアクションを実行するかを指定するために使用される。これをSRAで定義する。

 Litリソース (Lit Resources)Litリソースは以下のいずれかを指します：
アクセス制御条件 (Access Control Condition)

リソースキーは、暗号化された対称鍵またはJWT署名ペイロード（リソースID）のハッシュから派生します。
Programmable Key Pair (PKP) NFT

リソースキーはNFTのトークンIDです。
Capacity Credit NFT

リソースキーはNFTのトークンIDです。
Litアクション (Lit Action)

リソースキーは、LitアクションコードのIPFSコンテンツID (CID) です。
Tips

ワイルドカードリソースキー：

*で表されるリソースキーは、そのカテゴリ内のすべてのリソースを指します（例: すべてのPKP NFTまたはすべてのアクセス制御条件）。

 Litアビリティ (Lit Abilities)Litアビリティは実行されるアクションを指し、以下のいずれかである必要があります：
アクセス制御条件に基づくしきい値復号 (Threshold Decryption)

・アクセス制御条件を満たした場合にデータを復号します。
アクセス制御条件に基づくしきい値署名 (Threshold Signing)

・アクセス制御条件を満たした場合に署名を生成します。
PKP NFTを使用したしきい値署名 (Threshold Signing with a PKP NFT)

・特定のPKP NFTを用いた署名。
Capacity Credit NFTを用いた認証 (Authenticating with an Increased Rate Limit Threshold)

・Capacity Credit NFTを使用して、認証のレート制限を増加させます。
Litアクションコードのしきい値署名 (Threshold Signing of a Piece of Lit Action Code)

・特定のLitアクションコードに署名します。

 Capability Objects（権限オブジェクト）セッション署名は、セッションキーにスコープされた権限を付与することで機能します。このスコープは、内包するAuthSig（認証署名）によって設定されます。権限オブジェクトは、SIWE（Sign-In with Ethereum）ReCapオブジェクトとして定義されます。
デフォルトでは、getSessionSigs()関数呼び出しにセッション権限オブジェクトが指定されていない場合、SDKはカテゴリ内のすべてのリソースに対してワイルドカード権限を持つセッション権限オブジェクトを生成します（例: すべてのアクセス制御条件に対する操作）。以下は、カスタムセッション権限オブジェクトを作成する例です。
アクセス制御条件に対する復号権限の付与
import { LIT_ABILITY } from "@lit-protocol/constants";

// セッション権限オブジェクトを作成
const sessionCapabilityObject = new newSessionCapabilityObject();

// 特定のリソースをキーとするLitリソースを作成
const litResource = new LitAccessControlConditionResource('someResource');

// 指定されたLitリソースに関連付けられた復号権限を追加
sessionCapabilityObject.addCapabilityForResource(
    litResource,
    LIT_ABILITY.AccessControlConditionDecryption
);
アクセス制御条件に対するすべての（有効な）権限の付与
// セッション権限オブジェクトを作成
const sessionCapabilityObject = new newSessionCapabilityObject();

// 特定のリソースをキーとするLitリソースを作成
const litResource = new LitAccessControlConditionResource('someResource');

// 指定されたLitリソースに関連付けられたすべての有効な権限を追加
sessionCapabilityObject.addAllCapabilitiesForResource(litResource);
注意: 認証Lit Ability（Authentication Lit Ability）は、アクセス制御条件には適用されません。
すべてのアクセス制御条件に対する復号権限の付与
// セッション権限オブジェクトを作成
const sessionCapabilityObject = new newSessionCapabilityObject();

// ワイルドカード（*）をキーとするLitリソースを作成
const litResource = new LitAccessControlConditionResource('*');

// 指定されたリソースに関連付けられた復号権限を追加
sessionCapabilityObject.addCapabilityForResource(
    litResource,
    LIT_ABILITY.AccessControlConditionDecryption
);

 Capacity Credits（容量クレジット）Capacity Creditsを活用してLitネットワークの使用量を効率的に管理・拡張
・Capacity Credits は、Litネットワーク上でリクエストを送信する際のリソース割り当てを管理する仕組みです。

・ユーザーはCapacity Creditsを使用して、特定の期間（例: 1週間）におけるリクエスト数を設定できます。

・レート制限は現在、DatilおよびDatil-testネットワークで有効です。
容量クレジットのミント (Minting Capacity Credits)
必要な準備:

Capacity Credits NFTをミントするには、Chronicle（LitのカスタムEVMロールアップテストネット）を使用します。

必要なトークン: tstLPX（テスト用トークン）。

方法:

・Lit Explorer を使用する。

・contracts-sdk を使用する（以下はSDKを使用する例）。
import { LIT_NETWORK } from "@lit-protocol/constants";

const walletWithCapacityCredit = new Wallet("<your private key or mnemonic>");
let contractClient = new LitContracts({
  signer: walletWithCapacityCredit,
  network: LIT_NETWORK.DatilTest,
});

await contractClient.connect();

const { capacityTokenIdStr } = await contractClient.mintCapacityCreditsNFT({
  requestsPerKilosecond: 80, // 1秒間に80リクエスト
  daysUntilUTCMidnightExpiration: 2, // NFTの有効期限: 2日
});
プロパティの設定:

requestsPerKilosecond: 1秒あたりのリクエスト数。

daysUntilUTCMidnightExpiration: NFTの有効期限（日単位）。
容量クレジットの委任 (Delegating Capacity Credits)

概要:

・Capacity Credits NFTの使用権限を他のウォレットに委任可能。

委任プロセスでは、以下のパラメータを設定します：

・uses: 使用回数。

・capacityTokenId: Capacity Credits NFTのトークンID。

・delegateeAddresses: 委任先ウォレットアドレス。
import { LIT_NETWORK } from "@lit-protocol/constants";

const litNodeClient = new LitNodeClient({
    litNetwork: LIT_NETWORK.DatilTest,
    checkNodeAttestation: true,
});

await litNodeClient.connect();

const { capacityDelegationAuthSig } =
  await litNodeClient.createCapacityDelegationAuthSig({
    uses: '1',
    dAppOwnerWallet: walletWithCapacityCredit,
    capacityTokenId: capacityTokenIdStr,
    delegateeAddresses: [secondWalletPKPInfo.ethAddress],
  });
PKPへの委任 (Delegating to a PKP)
const pkpSessionSigs = await litNodeClient.getSessionSigs({
    pkpPublicKey: secondWalletPKPInfo.publicKey,
    expiration: new Date(Date.now() + 1000 * 60 * 60 * 24).toISOString(),
    chain: 'ethereum',
    resourceAbilityRequests: [
      {
        resource: new LitPKPResource('*'),
        ability: LIT_ABILITY.PKPSigning,
      },
    ],
    authNeededCallback: pkpAuthNeededCallback,
    capacityDelegationAuthSig,
});
パラメータ:

pkpPublicKey: 委任対象のPKPウォレットの公開鍵。

capacityDelegationAuthSig: 委任時に生成された署名。

 LitNode使用のための認証プロセス以下の流れに従って、実際にステップバイステップでやってみる
認証編

AuthSigって何？

AuthSigの仕組み

SessionSigsって何？

SessionSig（セッションシグ）とAuthSigの関係

SessionSigの目的

生成の流れ

SessionSigsの生成

セッション署名の保存

セッション署名の要素

SRA

Litリソース (Lit Resources)

Litアビリティ (Lit Abilities)

Capability Objects（権限オブジェクト）

Capacity Credits（容量クレジット）

LitNode使用のための認証プロセス

Discussion
