<SYSTEM>This is the full developer documentation for Sunrise</SYSTEM>

# 👋 Sunrise

> Interliquid Networks のベースレイヤー。

危険

Cosmos Sunrise は **2026年10月5日 12:00 UTC**、v2.0.0 アップグレード（ブロック高 **6,504,000**）で終了します。ネットワーク、アプリ、エクスプローラーは停止します。このネットワーク上の保有資産は Sunrise Edge に引き継がれます。終了前に資金を移動したり、現行アプリを操作したりする必要はありません。

詳細は [Sunrise Edge](https://sunriselayer.io/) を参照してください。終了までは以前のサイトが [cosmos.sunriselayer.io](https://cosmos.sunriselayer.io/) で見られます。

**Interliquid Networks のベースレイヤー。**

Sunrise は、高スループットなデータ可用性とネイティブな流動性ハブを組み合わせた次世代 Layer 1 ブロックチェーンです。**Proof of Liquidity（PoL）** と **手数料抽象化** を統合し、ロールアップおよびアプリチェーンに対して即時の流動性と柔軟なガス支払い手段を提供します。バリデーターは RISE および／または vRISE をステークしてネットワークを保護します。流動性提供者はプールに流動性を供給し、vRISE と取引手数料を獲得します。Sunrise は [ロールアップおよび L2 ブロックチェーン](/build/l2-blockchains) と連携し、開発者は少ない統合コストで Sunrise を採用できます。

注意

機能の要望やアイデアがある場合は、[GitHub Discussions](https://github.com/orgs/sunriselayer/discussions) でスレッドを開いてください。

## 主な特徴

[「主な特徴」セクションへのリンク](#主な特徴)

| 機能                          | 説明                                                                                                      |
| --------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Proof of Liquidity（PoL）** | バリデーターは RISE および／または vRISE をステークしてネットワークを保護し、セキュリティと流動性を同時に揃えます。流動性提供者は vRISE と取引手数料を獲得します。             |
| **手数料抽象化**                  | 任意のトークンでガスを支払えます。Sunrise は内部でごく一部を RISE にスワップします。ガス用に複数のトークンを持つ必要はありません。                                |
| **オフチェーンデータ可用性**            | 大きなデータ blob はオフチェーンで伝播・保存し、オンチェーンにはイレージャーコーディング済みデータシェアを指すメタデータ URI のみを残します。高スループットなロールアップ向けに最適化されています。 |

## 高速なデータ可用性

[「高速なデータ可用性」セクションへのリンク](#高速なデータ可用性)

Sunrise のオフチェーンデータ可用性設計は、オンチェーンのセキュリティを犠牲にせず、高いスループットとコスト効率を実現します。

1. **オフチェーンのイレージャーコーディング**\
   → バリデーターの計算とストレージを大幅に削減します。オンチェーンに残るのはコード化されたシャードだけで、完全なデータ再構成はオフチェーンで行われます。
2. **オフチェーンの blob 伝播**\
   → メモリプールを軽量に保ち、**5 MB/s 以上**までスケールします。バリデーターは可用性をサンプリングし、ノードは必要に応じて blob を取得または削除します。
3. **KZG コミットメント**\
   → オンチェーンの暗号学的アンカーにより、サブ秒での証明検証と即座のチャレンジ解決が可能になります。

## データ可用性の機能

[「データ可用性の機能」セクションへのリンク](#データ可用性の機能)

Sunrise は重いデータ処理をオフチェーンに移し、オンチェーンの証明は小さく検証可能なままにします。

1. **オフチェーンのイレージャーエンコーディング**\
   バリデーターの計算とストレージを大幅に削減します。オンチェーンに残るのはイレージャーコーディング済みデータシェアを指すメタデータ URI のみで、完全なデータ再構成はオフチェーンで行われます。
2. **オフチェーンストレージ連携**\
   IPFS や Arweave などの分散ストレージを利用してデータシャードを外部保存します。`MsgPublishData` にはイレージャーコーディング済みデータシェアを指すメタデータ URI だけが含まれ、blob トランザクションのオンチェーンブロックサイズ要件を下げ、スケーラビリティを高めます。

詳細は [データ可用性](/learn/sunrise/data-availability) を参照してください。

## Sunrise 上で構築する理由

[「Sunrise 上で構築する理由」セクションへのリンク](#sunrise-上で構築する理由)

1. **ガスレスなオンボーディング** – 専用のガストークンは不要です。プロジェクトのトークンで支払えます。
2. **即時の流動性** – 流動性を提供し、vRISE のゲージ報酬と取引手数料を獲得できます。
3. **Rollkit / OP Stack 対応** – ソブリンロールアップにも Ethereum 決済のロールアップにも、そのまま使えるアダプターがあります。

## コアモジュール

[「コアモジュール」セクションへのリンク](#コアモジュール)

| モジュール                                                        | 目的                       |
| ------------------------------------------------------------ | ------------------------ |
| [`x/da`](/learn/sunrise/data-availability)                   | データ可用性レイヤーでのデータ公開と証明     |
| [`x/liquiditypool`](/learn/sunrise/liquidity-pool)           | PoL プールと流動性提供            |
| [`x/liquidityincentive`](/learn/sunrise/liquidity-incentive) | vRISE 割り当てのためのゲージ投票とブライブ |
| [`x/swap`](/learn/sunrise/swap)                              | トークンスワップを行う AMM ルーター     |
| [`x/tokenconverter`](/learn/sunrise/token-converter)         | vRISE から RISE への変換       |
| [`x/fee`](/learn/sunrise/fee)                                | 手数料抽象化と収益の分配             |
| [`x/lockup`](/learn/sunrise/lockup)                          | 一定期間の RISE ロック           |
| [`x/shareclass`](/learn/sunrise/shareclass)                  | ネットワーク保護のための RISE ステーキング |

## 収益源

[「収益源」セクションへのリンク](#収益源)

* **トランザクション手数料** – トランザクション送信時に RISE で支払われます
* **スワップ手数料** – 流動性提供者に支払われます

## 次のステップ

[「次のステップ」セクションへのリンク](#次のステップ)

| 操作                | リンク                                                 |
| ----------------- | --------------------------------------------------- |
| **ノードの導入**        | [ノードセットアップガイド](/run-a-sunrise-node/types/consensus) |
| **ロールアップの起動**     | [Rollkit ガイド](/build/l2-blockchains/rollkit)        |
| **バリデーターになる**     | [バリデーターガイド](/build/validators)                      |
| **Discord に参加する** | [Discord コミュニティ](https://discord.gg/sunriselayer)   |

# クライアント

> Sunriseクライアントライブラリを使用すると、カスタムのprotobufツーリングを実行したり、Tendermint JSON-RPCコールを手作業で作成したりすることなく、アプリケーションからチェーンのクエリ、BLOBの送信、トランザクションの署名/ブロードキャストを行うことができます。

Sunriseクライアントライブラリを使用すると、カスタムのprotobufツーリングを実行したり、Tendermint JSON-RPCコールを手作業で作成したりすることなく、アプリケーションからチェーンの**クエリ**、**BLOBの送信**、**トランザクションの署名/ブロードキャスト**を行うことができます。

## 利用可能なSDK

[「利用可能なSDK」セクションへのリンク](#利用可能なsdk)

* **JavaScript / TypeScript** - npmで利用可能なプライマリSDK
* **Rust** - Buf/Prostを使用したgRPC + protobuf型生成
* **Go**および**Python**バインディング - 近日公開予定（貢献を歓迎します）

## JavaScript / TypeScript SDK

[「JavaScript / TypeScript SDK」セクションへのリンク](#javascript--typescript-sdk)

[Sunriseクライアント](https://github.com/sunriselayer/sunrise-client-js)

### インストール

[「インストール」セクションへのリンク](#インストール)

```bash
npm install @sunriselayer/client @cosmjs/proto-signing @cosmjs/stargate
# または
pnpm add @sunriselayer/client @cosmjs/proto-signing @cosmjs/stargate
# または
yarn add @sunriselayer/client @cosmjs/proto-signing @cosmjs/stargate
```

### 基本的な使用法

[「基本的な使用法」セクションへのリンク](#基本的な使用法)

このクライアントは、Cosmos SDKチェーンと対話するための標準ライブラリである[CosmJS](https://cosmos.github.io/cosmjs/)と共に使用するように設計されています。

以下は、集中流動性ポジションを作成する方法の例です。

```typescript
import {
  createEncodeObject,
  sunriseTypesRegistry,
} from "@sunriselayer/client";
// すべてのモジュールのスキーマと型はクライアントからエクスポートされます。
// ここでは、`MsgCreatePosition`メッセージのスキーマをインポートします。
import { MsgCreatePositionSchema } from "@sunriselayer/client/types/liquiditypool";
import { DirectSecp256k1HdWallet } from "@cosmjs/proto-signing";
import { SigningStargateClient, coin } from "@cosmjs/stargate";


const RPC = "https://goldberg-rpc.sunrise.node"; // ノードに置き換えてください
const SENDER_MNEMONIC = process.env.MNEMONIC!;   // 秘密鍵は絶対にコミットしないでください


// これは簡略化された例です。実際のアプリケーションでは、クエリクライアントから
// プールの詳細を取得し、ユーザーが提供した価格からティックを計算します。
const MOCK_POOL_ID = 1n; // 注：uint64フィールドにはBigIntを使用してください
const MOCK_LOWER_TICK = -20000n;
const MOCK_UPPER_TICK = 20000n;


async function main() {
  // 1. ニーモニックからウォレットと署名者を作成します
  const signer = await DirectSecp256k1HdWallet.fromMnemonic(SENDER_MNEMONIC, {
    prefix: "sunrise", // SunriseのBech32アドレスプレフィックス
  });
  const [account] = await signer.getAccounts();
  const senderAddress = account.address;
  console.log("送信者アドレス:", senderAddress);


  // 2. 署名者と型レジストリを使用して署名クライアントを作成します
  const client = await SigningStargateClient.connectWithSigner(RPC, signer, {
    registry: sunriseTypesRegistry, // Sunriseメッセージのカスタム型レジストリ
  });
  console.log("正常に接続しました:", RPC);


  // 3. 「Create Position」トランザクションメッセージを準備します
  // すべてのメッセージフィールドは完全に型付けされ、検証されます。
  const msg = createEncodeObject(MsgCreatePositionSchema, {
    sender: senderAddress,
    poolId: MOCK_POOL_ID,
    lowerTick: MOCK_LOWER_TICK,
    upperTick: MOCK_UPPER_TICK,
    // @cosmjs/stargateの`coin`ヘルパーを使用してCoinオブジェクトを作成します
    tokenBase: coin("1000000", "urise"), // 1 RISE
    tokenQuote: coin("5000000", "uusdc"), // 5 USDC（例）
    minAmountBase: "0", // スリッページ保護
    minAmountQuote: "0", // スリッページ保護
  });


  // 4. 手数料を定義し、トランザクションに署名してブロードキャストします
  const fee = {
    amount: [coin("10000", "uusdrise")],
    gas: "400000", // ガス制限
  };
  const memo = "Created position via @sunriselayer/client";


  console.log("トランザクションをブロードキャストしています...");
  const { transactionHash } = await client.signAndBroadcast(
    senderAddress,
    [msg],
    fee,
    memo
  );


  console.log("正常にポジションを作成しました！");
  console.log("トランザクションハッシュ:", transactionHash);
}


main().catch(console.error);
```

TypeScriptを使用する場合、すべてのメソッドは完全に型付けされます。

## Rust SDK（近日公開）

[「Rust SDK（近日公開）」セクションへのリンク](#rust-sdk近日公開)

Rust SDKは現在、protobuf生成を通じて実装されています。セットアップ方法は次のとおりです。

### プロジェクト構造

[「プロジェクト構造」セクションへのリンク](#プロジェクト構造)

```plaintext
my-sunrise-client/
├── src/
│   └── main.rs
├── buf.yaml
└── buf.gen.yaml
```

### 設定ファイル

[「設定ファイル」セクションへのリンク](#設定ファイル)

1. `buf.yaml`:

```yaml
version: v2
deps:
  - buf.build/cosmos/cosmos-sdk
  - buf.build/cosmos/cosmos-proto
  - buf.build/cosmos/gogo-proto
  - buf.build/protocolbuffers/wellknowntypes
```

2. `buf.gen.yaml`:

```yaml
version: v2
managed:
  enabled: true


plugins:
  - remote: buf.build/community/neoeinstein-prost:v0.4.0
    out: src
    opt:
      - compile_well_known_types
      - extern_path=.google.protobuf=::pbjson_types
  - remote: buf.build/community/neoeinstein-prost-serde:v0.3.1
    out: src
  - remote: buf.build/community/neoeinstein-tonic:v0.4.1
    out: src
    opt:
      - compile_well_known_types
      - extern_path=.google.protobuf=::pbjson_types


inputs:
  - git_repo: https://github.com/sunriselayer/sunrise.git
    branch: main
    subdir: proto
```

### セットアップと生成

[「セットアップと生成」セクションへのリンク](#セットアップと生成)

```bash
# 必要な依存関係を追加します
cargo add tonic tonic-build pbjson-types


# 依存関係を更新し、コードを生成します
buf dep update
buf generate
```

### 使用例

[「使用例」セクションへのリンク](#使用例)

```rust
use tonic::transport::Channel;
use sunriselayer::sunrise::da::v1::query_client::QueryClient;
use sunriselayer::sunrise::da::v1::ParamsRequest;


#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let mut client = QueryClient::connect("http://localhost:9090").await?;
    let resp = client.params(ParamsRequest {}).await?;
    println!("DA params: {:?}", resp.into_inner());
    Ok(())
}
```

## 追加リソース

[「追加リソース」セクションへのリンク](#追加リソース)

* [完全なJavaScriptメソッドリファレンス](https://github.com/SunriseLayer/gitbook/blob/main/build/client/reference/README.md)
* [ロールアップ統合の例](/build/l2-blockchains)
* [データ可用性の証明](/build/validators)

## トラブルシューティング

[「トラブルシューティング」セクションへのリンク](#トラブルシューティング)

| 問題         | 解決策                                                   |
| ---------- | ----------------------------------------------------- |
| 接続が拒否されました | RPC URLを確認し、DAノードが実行されていることを確認してください                  |
| 認証エラー      | アカウントに十分な資金があることを確認してください                             |
| Rustのビルド失敗 | Rust 1.74+に更新し、`cargo clean && buf generate`を実行してください |

# L2ブロックチェーン

> 外部RPCに依存せず、フルコンセンサスノードをローカルで実行することをお勧めします。これにより、L2デプロイメントの信頼性と制御が向上します。

## Sunriseドキュメント

[「Sunriseドキュメント」セクションへのリンク](#sunriseドキュメント)

* [Rollkit](/build/l2-blockchains/rollkit)

  * [Sunriseデータ](/build/l2-blockchains/rollkit/sunrise-data) - Sunrise DAリレーの設定と実行
  * [Rollkit L2チェーン](/build/l2-blockchains/rollkit/rollkit) - RollkitベースのL2の構築とデプロイ

* [Optimism OP Stack](/build/l2-blockchains/optimism)

  * [Sunriseデータ](/build/l2-blockchains/optimism/sunrise-data) - OP Stack用のSunrise DAの設定
  * [OP Stack L2チェーン](/build/l2-blockchains/optimism/op-stack) - Sunriseを使用したOP Stack L2のデプロイ

## L2の作成方法

[「L2の作成方法」セクションへのリンク](#l2の作成方法)

外部RPCに依存せず、フルコンセンサスノードをローカルで実行することをお勧めします。これにより、L2デプロイメントの信頼性と制御が向上します。

[Sunriseコンセンサスノードドキュメント](/run-a-sunrise-node/types/consensus)

### Rollkit

[「Rollkit」セクションへのリンク](#rollkit)

`sunrise-data`と`rollkit`を実行する必要があります。この統合により、以下が提供されます。

* Sunriseを介したネイティブなデータ可用性
* ソブリンロールアップ機能
* カスタマイズ可能な実行環境
* シンプルな設定とデプロイ

### OP Stack

[「OP Stack」セクションへのリンク](#op-stack)

`sunrise-data`、`optimism`、`op-geth`を実行する必要があります。主なポイントは次のとおりです。

* ローカルEVM L1チェーンは、OP Stackの要件を満たすためにのみ使用されます
* 実際のデータ（メタデータ）はSunriseに保存されます
* ローカルL1チェーンにはGanache、Hardhat、Anvilなどを使用します
* Sunriseが実際のデータ可用性を処理します

## 要件

[「要件」セクションへのリンク](#要件)

| タイプ                   | CPU | アーキテクチャ | メモリ   | ディスク     | 帯域幅    | 目的        |
| --------------------- | --- | ------- | ----- | -------- | ------ | --------- |
| Rollkit + Sunriseデータ  | 4コア | x86\_64 | 16 GB | 1 TB SSD | 1 Gbps | 開発とテスト    |
| OP Stack + Sunriseデータ | 6コア | x86\_64 | 32 GB | 1 TB SSD | 1 Gbps | 本番デプロイメント |

追加の考慮事項：

* 本番環境では、SSDはエンタープライズグレードである必要があります
* 帯域幅の要件はトランザクション量に応じて増加します
* メモリ要件は状態サイズに応じてスケールします

## 公式ドキュメント

[「公式ドキュメント」セクションへのリンク](#公式ドキュメント)

* [Rollkit](https://rollkit.dev/learn/intro)

  * [BeaconKit（オプション）](https://rollkit.dev/tutorials/execution/beaconkit): BeaconKitとRollkitを組み合わせることで、EVM互換のL2ブロックチェーンを開発できます。
  * Sunrise DAの利点を維持しながら、完全なEVM互換性を提供します

* [OP Stack](https://docs.optimism.io/stack/getting-started)

  * OP Stackデプロイメントのための包括的なドキュメント
  * さまざまなコンポーネントの統合ガイド

## 統合アーキテクチャ

[「統合アーキテクチャ」セクションへのリンク](#統合アーキテクチャ)

```plaintext
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│                 │     │                 │     │                 │
│  L2ブロックチェーン  │────▶│  Sunrise DA     │────▶│  バリデーター      │
│                 │     │  レイヤー          │     │  ネットワーク        │
└─────────────────┘     └─────────────────┘     └─────────────────┘
        │                       │                       ▲
        │                       │                       │
        ▼                       ▼                       │
┌─────────────────┐     ┌─────────────────┐             │
│                 │     │                 │             │
│  ユーザー           │     │  DA証明       │─────────────┘
│  アプリケーション   │     │  検証   │
└─────────────────┘     └─────────────────┘
```

## 一般的な統合手順

[「一般的な統合手順」セクションへのリンク](#一般的な統合手順)

1. **Sunrise DAノードの設定**

   * Sunriseノードをデプロイするか、テストネットに接続します
   * ネットワークパラメータを設定します
   * 必要に応じてバリデーターを設定します
   * ノードの同期を確認します

2. **L2フレームワークの設定**

   * 必要な依存関係をインストールします
   * 設定ファイルを設定します
   * Sunrise DAレイヤーに接続します
   * ネットワークパラメータを設定します

3. **DA統合の実装**

   * BLOB送信を設定します
   * 証明検証を設定します
   * 手数料処理を実装します
   * 監視を設定します

4. **テストとデプロイ**

   * テストネットでテストします
   * DA証明を検証します
   * 本番環境にデプロイします
   * パフォーマンスを監視します

## 設定例

[「設定例」セクションへのリンク](#設定例)

### Rollkit設定

[「Rollkit設定」セクションへのリンク](#rollkit設定)

```yaml
[da]
rpc_address = "http://localhost:26657"
fee_denom   = "uusdrise"
gas_price   = "0.025"


[rollup]
chain_id = "my-rollup-1"
```

### OP Stack設定

[「OP Stack設定」セクションへのリンク](#op-stack設定)

```bash
# 環境変数
DA_SERVER=http://localhost:8547
BLOB_RPC=http://localhost:26657
```

## ベストプラクティス

[「ベストプラクティス」セクションへのリンク](#ベストプラクティス)

1. **セキュリティ**

   * 常にDA証明を検証します
   * 安全なRPCエンドポイントを使用します
   * 適切なエラー処理を実装します
   * 定期的なセキュリティ監査

2. **パフォーマンス**

   * BLOBサイズを最適化します
   * 適切なキャッシングを実装します
   * ガス代を監視します
   * 定期的なパフォーマンステスト

3. **信頼性**

   * 再試行メカニズムを実装します
   * DA証明のステータスを監視します
   * 適切なロギングを設定します
   * 定期的なバックアップ

## トラブルシューティング

[「トラブルシューティング」セクションへのリンク](#トラブルシューティング)

| 問題          | 解決策                           | 防止策          |
| ----------- | ----------------------------- | ------------ |
| DA証明が検証されない | RPC接続と証明の形式を確認してください          | 定期的な接続テスト    |
| ガス代が高い      | BLOBのサイズと頻度を最適化してください         | ガス設定の監視と調整   |
| 接続の問題       | ネットワーク設定とファイアウォールの設定を確認してください | 定期的なネットワーク監視 |

## 追加リソース

[「追加リソース」セクションへのリンク](#追加リソース)

* [Rollkitドキュメント](/build/l2-blockchains/rollkit)
* [OP Stack統合](/build/l2-blockchains/optimism)
* [データ可用性の証明](/build/validators/data-availability-proof)
* [料金抽象化](https://github.com/SunriseLayer/gitbook/blob/main/learn/sunrise/fee-abstraction.md)

# OPスタック

> Sunriseのデータ可用性レイヤーは、[OP Stack](https://github.com/ethereum-optimism/optimism)を使用して作成されたレイヤー2ブロックチェーンをサポートしています。

Sunriseのデータ可用性レイヤーは、[OP Stack](https://github.com/ethereum-optimism/optimism)を使用して作成されたレイヤー2ブロックチェーンをサポートしています。

これは、OP Stackを使用して作成されたL2チェーンを[Sunrise Data](https://github.com/sunriselayer/sunrise-data)でSunriseチェーンに接続するためのガイドです。データ可用性レイヤーは、Sunrise v0.3.0以降でサポートされています。

## Sunriseデータ

[「Sunriseデータ」セクションへのリンク](#sunriseデータ)

**optimismを開始する前に、sunrise-dataを設定してください。** [Sunriseデータドキュメント](/build/l2-blockchains/optimism/sunrise-data)

外部RPCに依存せず、フルコンセンサスノードをローカルで実行することをお勧めします。[Sunriseコンセンサスノードドキュメント](/run-a-sunrise-node/types/consensus)

## OPスタック

[「OPスタック」セクションへのリンク](#opスタック)

OP Stack L2チェーンを[Alt-DAモード](https://docs.optimism.io/operators/chain-operators/features/alt-da-mode)で開始します。

最新のドキュメントに従ってください。要件を満たすために、ローカルEVMチェーンが必要になる場合があります。

[OPスタックL2チェーンのドキュメント](/build/l2-blockchains/optimism/op-stack)

# OPスタック L2チェーン

> Sunriseのデータ可用性レイヤーは、[OP Stack](https://github.com/ethereum-optimism/optimism)を使用して作成されたレイヤー2ブロックチェーンをサポートしています。

Sunriseのデータ可用性レイヤーは、[OP Stack](https://github.com/ethereum-optimism/optimism)を使用して作成されたレイヤー2ブロックチェーンをサポートしています。 これは、OP Stackを使用して作成されたL2チェーンを[Sunrise Data](/build/l2-blockchains/optimism/sunrise-data)でSunriseチェーンに接続するためのガイドです。データ可用性レイヤーは、Sunrise v0.3.0以降でサポートされています。

このバージョンのOPスタックでは、L1 EVMチェーンの運用が必要です。何らかのテストネットまたはローカルチェーンを使用してください。

## OPスタックの設定方法

[「OPスタックの設定方法」セクションへのリンク](#opスタックの設定方法)

例として、OP Stackを使用してL2チェーンを作成し、Sunriseのデータ可用性レイヤーで実行する方法を以下に示します。

このガイドでは、OPスタックの要件を満たすためにEthereum Sepoliaテストネットを使用していますが、ローカルEVMチェーンでも動作します。

```
sequenceDiagram
   autonumber
   L2 ->> Ethereum Sepolia: トランザクションを送信（例：トークン転送）
   Ethereum Sepolia --> L2: APIとトランザクションの応答
   L2 ->> Sunrise: ブロックデータを送信して保存
```

### 依存関係

[「依存関係」セクションへのリンク](#依存関係)

Ubuntu 22.04の依存関係と一般的なインストール手順。

* node

  ```bash
    curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - && sudo apt-get install -y nodejs
  ```

* [pnpm](https://pnpm.io/ja/installation)

  ```bash
    curl -fsSL https://get.pnpm.io/install.sh | sh -
  ```

* [foundry](https://book.getfoundry.sh/getting-started/installation)

  ```bash
    curl -L https://foundry.paradigm.xyz | bash
  ```

* just

  ```bash
    wget -qO - 'https://proget.makedeb.org/debian-feeds/prebuilt-mpr.pub' | gpg --dearmor | sudo tee /usr/share/keyrings/prebuilt-mpr-archive-keyring.gpg 1> /dev/null
    echo "deb [arch=all,$(dpkg --print-architecture) signed-by=/usr/share/keyrings/prebuilt-mpr-archive-keyring.gpg] https://proget.makedeb.org prebuilt-mpr $(lsb_release -cs)" | sudo tee /etc/apt/sources.list.d/prebuilt-mpr.list
    sudo apt update
    sudo apt install just
  ```

### Optimismロールアップテストネットの設定

[「Optimismロールアップテストネットの設定」セクションへのリンク](#optimismロールアップテストネットの設定)

### Optimism

[「Optimism」セクションへのリンク](#optimism)

1. **optimismリポジトリをクローンします**

   ```bash
   git clone https://github.com/ethereum-optimism/optimism.git
   ```

2. 正しいブランチをチェックアウトします

   ```bash
   cd optimism
   git checkout v1.9.1
   ```

ドキュメント更新時点で最新バージョンでの動作を確認しています。他のバージョンを使用する場合は、差異を確認してください。

1. **すべての依存関係があることを確認するために以下を実行します**

   ```bash
   ./packages/contracts-bedrock/scripts/getting-started/versions.sh
   ```

2. Optimismに関連するすべてのパッケージをビルドします

   ```bash
   make op-node op-batcher op-proposer
   ```

   この手順で問題が発生した場合は、バージョンがoptimismのドキュメントと一致していることを確認してください。具体的には、goのバージョンをダウングレードする必要がある場合があります。

3. op-gethをクローンしてビルドします

   ```bash
   cd ~
   git clone https://github.com/ethereum-optimism/op-geth.git
   cd op-geth
   make geth
   ```

サポートされている`op-geth`の詳細については、optimismリポジトリの[Production Releases](https://github.com/ethereum-optimism/optimism/tree/v1.12.0?tab=readme-ov-file#production-releases)を確認してください。

1. 環境変数を入力します

   ```bash
   cd ~/optimism
   cp .envrc.example .envrc
   ```

   optimismリポジトリで次のコマンドを使用してアドレスを生成するスクリプトを実行します： `./packages/contracts-bedrock/scripts/getting-started/wallets.sh`

   出力は次のようになり、これを環境ファイルに貼り付ける必要があります：

   ```bash
   ##################################################
   #                 はじめに                #
   ##################################################


   # 管理者アカウント
   export GS_ADMIN_ADDRESS=0x82eeB61600f290ce3F9400d345aAEcBe5faF7AEB
   export GS_ADMIN_PRIVATE_KEY=0x7c726817d047ee62cbb060312fe2620ba5462495e34f7e8279ba22faa96bca20


   # バッチャーアカウント
   export GS_BATCHER_ADDRESS=0x7BECbC4C747922d92e4F917951D9D8c3Ada7eb60
   export GS_BATCHER_PRIVATE_KEY=0xc7dfaa7b8449f00480196377da50d29318b2397fd0296d0ab4f11d48ee3cf723


   # 提案者アカウント
   export GS_PROPOSER_ADDRESS=0x773F4527fECc889d6DD3Cd7d044F4AC1Ad765a31
   export GS_PROPOSER_PRIVATE_KEY=0xed6029a5928e83c5d2a28d9574304bae9a825e19f7f18a50d34edc13b505afed


   # シーケンサーアカウント
   export GS_SEQUENCER_ADDRESS=0x2B43c41FCbabc5437A6E1B97F47cA085a4B16f61
   export GS_SEQUENCER_PRIVATE_KEY=0x0a7d4ce467fe4d00b8930215c98335e06c16db34cd501c8c3f3173015487662e


   ##################################################
   #                チェーン情報               #
   ##################################################


   # L1チェーン情報
   export L1_CHAIN_ID=11155111
   export L1_BLOCK_TIME=12


   # L2チェーン情報
   export L2_CHAIN_ID=42069
   export L2_BLOCK_TIME=2


   ##################################################
   #              op-node設定             #
   ##################################################


   # RPCプロバイダーの種類。最適なトランザクションレシートの
   # 取得方法を通知するために使用されます。有効なオプション：alchemy、quicknode、infura、parity、nethermind、
   # debug_geth、erigon、basic、any。
   export L1_RPC_KIND=infura


   ##################################################
   #               コントラクトのデプロイ              #
   ##################################################


   # 対話するL1ネットワークのRPC URL
   export L1_RPC_URL=https://sepolia.infura.io/v3/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   ```

   RPC URLのAPIキーは[Infura](https://www.infura.io/)または他のプロバイダーで見つけることができます。

2. 十分なSepolia ETHでアドレスに資金を供給します。optimismのドキュメントでは以下を推奨しています：

   * 管理者 — 0.5 Sepolia ETH
   * 提案者 — 0.2 Sepolia ETH
   * バッチャー — 0.1 Sepolia ETH

   参照：[Sepolia PoW Faucet](https://sepolia-faucet.pk910.de/)

3. direnvで環境変数をロードします `direnv allow` その後、次のようなものが表示されるはずです：

   ```bash
       direnv: loading ~/optimism/.envrc                                                            direnv: export +DEPLOYMENT_CONTEXT +ETHERSCAN_API_KEY +GS_ADMIN_ADDRESS +GS_ADMIN_PRIVATE_KEY +GS_BATCHER_ADDRESS +GS_BATCHER_PRIVATE_KEY +GS_PROPOSER_ADDRESS +GS_PROPOSER_PRIVATE_KEY +GS_SEQUENCER_ADDRESS +GS_SEQUENCER_PRIVATE_KEY +IMPL_SALT +L1_RPC_KIND +L1_RPC_URL +PRIVATE_KEY +TENDERLY_PROJECT +TENDERLY_USERNAME
   ```

   何も出力されない場合は、試してください

   `nano ~/.zshrc`

   `nano ~/.bashrc`

   bashとzshのどちらを使用するかに応じて、次の行を追加します

   ```bash
   eval "$(direnv hook zsh)"
   ```

   ```bash
   eval "$(direnv hook bash)"
   ```

   変更を保存します

   `source ~/.zshrc`

   `source ~/.bashrc`

4. ネットワークを設定します

   ```bash
   cd ~/optimism/packages/contracts-bedrock
   ./scripts/getting-started/config.sh
   ```

   \*\*`deploy-config/getting-started.json`\*\*ファイルで設定を表示できます 生成された設定の末尾に以下を追加します

   ```bash
   nano deploy-config/getting-started.json
   ```

   ```json
   ...
     "preimageOracleMinProposalSize": 1800000,
     "preimageOracleChallengePeriod": 300,


     "useAltDA": true,
     "daCommitmentType": "GenericCommitment",
     "daChallengeWindow": 160,
     "daResolveWindow": 160,
     "daBondSize": 1000000,
     "daResolverRefundPercentage": 0
   }
   ```

5. L1コントラクトをデプロイします

   ```bash
   just install
   DEPLOYMENT_OUTFILE=deployments/artifact.json \
   DEPLOY_CONFIG_PATH=deploy-config/getting-started.json \
   forge script scripts/deploy/Deploy.s.sol:Deploy \
   --broadcast --private-key $GS_ADMIN_PRIVATE_KEY \
   --rpc-url $L1_RPC_URL --slow
   ```

   L2 Allocs

   ```bash
   CONTRACT_ADDRESSES_PATH=deployments/artifact.json \
   DEPLOY_CONFIG_PATH=deploy-config/getting-started.json \
   STATE_DUMP_PATH=deploy-config/statedump.json \
   forge script scripts/L2Genesis.s.sol:L2Genesis \
   --sig 'runWithStateDump()' \
   --chain 42069
   ```

   `--chain`にL2チェーンIDを使用してください。

   > `EvmError: Revert`と`Script failed`を含む不明なエラーが表示された場合は、`IMPL_SALT`環境変数を変更する必要がある可能性があります。この変数は、[CREATE2(新しいタブで開く)](https://eips.ethereum.org/EIPS/eip-1014)を介してデプロイされるさまざまなスマートコントラクトのアドレスを決定します。同じ`IMPL_SALT`を使用して同じコントラクトを2回デプロイすると、2回目のデプロイは失敗します。**Optimism Monorepoのどこでも`direnv allow`を実行することで、新しい`IMPL_SALT`を生成できます。**

6. L2設定ファイルを生成します

   ```bash
   cd ~/optimism/op-node
   ./bin/op-node genesis l2 \
     --deploy-config ../packages/contracts-bedrock/deploy-config/getting-started.json \
     --l1-deployments ../packages/contracts-bedrock/deployments/artifact.json \
     --outfile.l2 genesis.json \
     --outfile.rollup rollup.json \
     --l1-rpc $L1_RPC_URL \
     --l2-allocs ../packages/contracts-bedrock/deploy-config/statedump.json
   ```

   生成された`rollup.json`の末尾を確認します

   ```json
    "alt_da": {
       "da_challenge_contract_address": "0x0000000000000000000000000000000000000000",
       "da_commitment_type": "GenericCommitment",
       "da_challenge_window": 160,
       "da_resolve_window": 160
     }
   ```

7. 認証キーを作成します

   ```bash
   openssl rand -hex 32 > jwt.txt
   ```

8. genesisファイルをop-gethディレクトリにコピーします

   ```bash
   cp genesis.json ~/op-geth
   cp jwt.txt ~/op-geth
   ```

9. `op-geth`を初期化します

   ```bash
   cd ~/op-geth
   mkdir datadir
   make geth
   build/bin/geth init --datadir=datadir genesis.json
   ```

## L2を開始

[「L2を開始」セクションへのリンク](#l2を開始)

**optimismを開始する前に、`sunrised`と`sunrise-data`などを設定してください。**

[**Sunrise Data**](/build/l2-blockchains/optimism/sunrise-data)

1. `op-geth`を開始します

   ```bash
   ./build/bin/geth \
     --datadir ./datadir \
     --http \
     --http.corsdomain="*" \
     --http.vhosts="*" \
     --http.addr=0.0.0.0 \
     --http.port=9545 \
     --http.api=web3,debug,eth,txpool,net,engine \
     --ws \
     --ws.addr=0.0.0.0 \
     --ws.port=9546 \
     --ws.origins="*" \
     --ws.api=debug,eth,txpool,net,engine \
     --syncmode=full \
     --nodiscover \
     --maxpeers=0 \
     --networkid=42069 \
     --authrpc.vhosts="*" \
     --authrpc.addr=0.0.0.0 \
     --authrpc.port=9551 \
     --authrpc.jwtsecret=./jwt.txt \
     --rollup.disabletxpoolgossip=true
   ```

2. `op-node`を開始します

   ```bash
   cd ~/optimism/op-node
   ./bin/op-node \
     --l2=http://localhost:9551 \
     --l2.jwt-secret=./jwt.txt \
     --sequencer.enabled \
     --sequencer.l1-confs=5 \
     --verifier.l1-confs=4 \
     --rollup.config=./rollup.json \
     --rpc.addr=0.0.0.0 \
     --rpc.port=8547 \
     --p2p.disable \
     --rpc.enable-admin \
     --p2p.sequencer.key=$GS_SEQUENCER_PRIVATE_KEY \
     --l1=$L1_RPC_URL \
     --l1.rpckind=$L1_RPC_KIND \
     --altda.enabled=true \
     --altda.da-server=http://localhost:3100 \
     --altda.da-service=true \
     --l1.beacon.ignore=true
   ```

   —altda.da-serverは、da-sererのhttp URLです

3. `op-batcher`を開始します

   ```bash
   cd ~/optimism/op-batcher
   ./bin/op-batcher \
     --l2-eth-rpc=http://localhost:9545 \
     --rollup-rpc=http://localhost:8547 \
     --poll-interval=1s \
     --sub-safety-margin=6 \
     --num-confirmations=1 \
     --safe-abort-nonce-too-low-count=3 \
     --resubmission-timeout=30s \
     --rpc.addr=0.0.0.0 \
     --rpc.port=8548 \
     --rpc.enable-admin \
     --max-channel-duration=1 \
     --l1-eth-rpc=$L1_RPC_URL \
     --private-key=$GS_BATCHER_PRIVATE_KEY \
     --altda.enabled=true \
     --altda.da-service=true \
     --altda.da-server=http://localhost:3100
   ```

4. `op-proposer`を開始します

   ```bash
   cd ~/optimism/op-proposer
   ./bin/op-proposer \
     --poll-interval=12s \
     --rpc.port=9560 \
     --rollup-rpc=http://localhost:8547 \
     --l2oo-address=$(cat ../packages/contracts-bedrock/deployments/42069-deploy.json | jq -r .L2OutputOracleProxy) \
     --private-key=$GS_PROPOSER_PRIVATE_KEY \
     --l1-eth-rpc=$L1_RPC_URL
   ```

5. 動作

# Sunriseデータ

> [Sunrise Data](https://github.com/sunriselayer/sunrise-data)は、L2チェーンをSunrise DAレイヤーに接続するリレーサーバーとして機能します。

[Sunrise Data](https://github.com/sunriselayer/sunrise-data)は、L2チェーンをSunrise DAレイヤーに接続するリレーサーバーとして機能します。

## Sunriseコンセンサスノード

[「Sunriseコンセンサスノード」セクションへのリンク](#sunriseコンセンサスノード)

動作には、ネットワーク化されたSunriseノードが必要です。Sunrise v0.3.0以降を実行している[ネットワーク](/run-a-sunrise-node/networks)は、データ可用性レイヤーをサポートしています。

コンセンサスノードの作成方法については、[ノードガイド](/run-a-sunrise-node/types/consensus)に従ってください。

### sunrise-dataの設定方法

[「sunrise-dataの設定方法」セクションへのリンク](#sunrise-dataの設定方法)

1. `sunrised`を実行します。設定については、[コンセンサスノード](https://github.com/SunriseLayer/gitbook/blob/main/build/node/types/consensus/full-consensus-node.md)を参照してください。

2. sunrise-dataリポジトリをクローンします。

   ```bash
   cd ~
   git clone https://github.com/sunriselayer/sunrise-data.git
   cd sunrise-data
   make install
   ```

3. `config.toml`を作成して編集します。

   ```bash
   cp config.default.toml config.toml
   nano config.toml
   ```

   ローカルのIPFSデーモンに接続するには、`ipfs_api_url`フィールドを空のままにします。

   `home_path`を`.sunrise`ディレクトリに、`publisher_account`をsunrisedキーの名前に変更します。

   ```toml
   [api]
   port = 8000
   ipfs_api_url = ""
   ipfs_addrinfo = ""


   [chain]
   address_prefix="sunrise"
   home_path="/home/ubuntu/.sunrise"
   keyring_backend="test"
   sunrised_rpc="http://localhost:26657"


   [publish]
   publisher_account="your_publisher_account"
   publish_fees="10000uusdrise"


   [optimism]
   listen_address="127.0.0.1"
   port=3100
   data_shard_count=10
   parity_shard_count=10
   ```

`home_path`、`keyring_backend`、`publisher_account`は、sunrisedキーリングで入力された値でなければなりません。[ローカルキーペアのドキュメント](/run-a-sunrise-node/types/consensus/full-consensus-node#create-or-restore-a-local-key-pair)を参照し、`--keyring-backend test`オプションで設定してください。`home_path`には、sunriseキーリングが存在するパスを入力してください。`sunrised_rpc`については、ローカルでsunrisedを実行することが望ましいですが、不可能な場合は公開されているRPCを使用してください。私たちの[ネットワークドキュメント](/run-a-sunrise-node/networks)を参照してください。このような場合でも、ローカルキーペアは必要です。

その他のフィールドはそのままにしておくことができます。

### ローカルでIPFSを実行する

[「ローカルでIPFSを実行する」セクションへのリンク](#ローカルでipfsを実行する)

1. IPFSを実行します。

   ```bash
   wget https://dist.ipfs.tech/kubo/v0.31.0/kubo_v0.31.0_linux-amd64.tar.gz
   tar -xvzf kubo_v0.31.0_linux-amd64.tar.gz
   cd kubo
   sudo ./install.sh
   ipfs init --profile=lowpower
   ipfs daemon
   ```

2. IPFSノードIDを確認し、オプションでリモートピアを共有して追加します。

   ```bash
   ipfs id
   ```

### 開始

[「開始」セクションへのリンク](#開始)

```bash
sunrise-data optimism
```

# Rollkit

> Sunriseのデータ可用性レイヤーは、[Rollkit](https://github.com/rollkit/rollkit)を使用して作成されたレイヤー2ブロックチェーンをサポートしています。

Sunriseのデータ可用性レイヤーは、[Rollkit](https://github.com/rollkit/rollkit)を使用して作成されたレイヤー2ブロックチェーンをサポートしています。

これは、Rollkitを使用して作成されたL2チェーンを[Sunrise Data](https://github.com/sunriselayer/sunrise-data)でSunriseチェーンに接続するためのガイドです。データ可用性レイヤーは、Sunrise v0.3.1-rc1以降でサポートされています。

## Sunriseデータ

[「Sunriseデータ」セクションへのリンク](#sunriseデータ)

**optimismを開始する前に、sunrise-dataを設定してください。**[Sunriseデータドキュメント](/build/l2-blockchains/rollkit/sunrise-data)

外部RPCに依存せず、フルコンセンサスノードをローカルで実行することをお勧めします。[Sunriseコンセンサスノードドキュメント](/run-a-sunrise-node/types/consensus)

## Rollkit

[「Rollkit」セクションへのリンク](#rollkit)

Rollkit L2チェーンを開始します。

[Rollkit L2チェーンのドキュメント](/build/l2-blockchains/rollkit/rollkit)

# Sunrise Rollkitの実行方法

> 例として、Rollkitを使用してL2チェーンを作成し、Sunriseのデータ可用性レイヤーで実行する方法を以下に示します。

例として、Rollkitを使用してL2チェーンを作成し、Sunriseのデータ可用性レイヤーで実行する方法を以下に示します。

## 依存関係

[「依存関係」セクションへのリンク](#依存関係)

Ubuntu 22.04の依存関係と一般的なインストール手順。

## Sunriseデータの設定

[「Sunriseデータの設定」セクションへのリンク](#sunriseデータの設定)

Rollkitのサポートは、sunrise-dataに含まれるサーバーを介して提供されます。 DAサーバーの役割については、[Rollkitドキュメント](https://rollkit.dev/tutorials/da/overview)を参照してください。

設定方法は[Sunriseデータドキュメント](/build/l2-blockchains/rollkit/sunrise-data)を参照してください。 デフォルトでは、Rollkitサポート用のGRPCサーバーはポート7980でリッスンします。

## Rollkitの実行

[「Rollkitの実行」セクションへのリンク](#rollkitの実行)

1. rollkitリポジトリをクローンします

   ```bash
   cd ~
   git clone https://github.com/rollkit/rollkit.git
   cd rollkit
   git checkout v0.14.1 # 最新のメジャーバージョン
   make install
   ```

2. rollkitチェーンを開始します `--rollkit.da_address`オプションを使用してDAサーバーに接続します。 他のポート指定オプションは、sunrisedをローカルで実行する際の競合を避けるために使用されます。 他のチェーン設定については、[Rollkitドキュメント](https://rollkit.dev/)を参照してください。

   ```bash
   rollkit start --rollkit.aggregator \
   --rollkit.sequencer_rollup_id sunrise \
   --rollkit.da_address grpc://localhost:7980 \
   --p2p.laddr tcp://0.0.0.0:25656 --rpc.laddr tcp://127.0.0.1:25657
   ```

3. 動作

## リンク

[「リンク」セクションへのリンク](#リンク)

* [Rollkit](https://rollkit.dev/learn/intro)

# Sunriseデータ

> [Sunrise Data](https://github.com/sunriselayer/sunrise-data)は、L2チェーンをSunrise DAレイヤーに接続するリレーサーバーとして機能します。

[Sunrise Data](https://github.com/sunriselayer/sunrise-data)は、L2チェーンをSunrise DAレイヤーに接続するリレーサーバーとして機能します。

## Sunriseコンセンサスノード

[「Sunriseコンセンサスノード」セクションへのリンク](#sunriseコンセンサスノード)

動作には、ネットワーク化されたSunriseノードが必要です。Sunrise v0.3.0以降を実行している[ネットワーク](/run-a-sunrise-node/networks)は、データ可用性レイヤーをサポートしています。

コンセンサスノードの作成方法については、[ノードガイド](/run-a-sunrise-node/types/consensus)に従ってください。

### sunrise-dataの設定方法

[「sunrise-dataの設定方法」セクションへのリンク](#sunrise-dataの設定方法)

1. `sunrised`を実行します。設定については、[コンセンサスノード](https://github.com/SunriseLayer/gitbook/blob/main/build/node/types/consensus/full-consensus-node.md)を参照してください。

2. sunrise-dataリポジトリをクローンします。

   ```bash
   cd ~
   git clone https://github.com/sunriselayer/sunrise-data.git
   cd sunrise-data
   make install
   ```

3. `config.toml`を作成して編集します。

   ```bash
   cp config.default.toml config.toml
   nano config.toml
   ```

   ローカルのIPFSデーモンに接続するには、`ipfs_api_url`フィールドを空のままにします。

   `home_path`を`.sunrise`ディレクトリに、`publisher_account`をsunrisedキーの名前に変更します。

   ```toml
   [api]
   port = 8000
   ipfs_api_url = ""
   ipfs_addrinfo = ""


   [chain]
   address_prefix="sunrise"
   home_path="/home/ubuntu/.sunrise"
   keyring_backend="test"
   sunrised_rpc="http://localhost:26657"


   [publish]
   publisher_account="your_publisher_account"
   publish_fees="10000uusdrise"


   [rollkit]
   port=7980
   data_shard_count=5
   parity_shard_count=5
   ```

`home_path`、`keyring_backend`、`publisher_account`は、sunrisedキーリングで入力された値でなければなりません。[ローカルキーペアのドキュメント](/run-a-sunrise-node/types/consensus/full-consensus-node#create-or-restore-a-local-key-pair)を参照し、`--keyring-backend test`オプションで設定してください。`home_path`には、sunriseキーリングが存在するパスを入力してください。`sunrised_rpc`については、ローカルでsunrisedを実行することが望ましいですが、不可能な場合は公開されているRPCを使用してください。私たちの[ネットワークドキュメント](/run-a-sunrise-node/networks)を参照してください。このような場合でも、ローカルキーペアは必要です。

その他のフィールドはそのままにしておくことができます。

### ローカルでIPFSを実行する

[「ローカルでIPFSを実行する」セクションへのリンク](#ローカルでipfsを実行する)

1. IPFSを実行します。

   ```bash
   wget https://dist.ipfs.tech/kubo/v0.31.0/kubo_v0.31.0_linux-amd64.tar.gz
   tar -xvzf kubo_v0.31.0_linux-amd64.tar.gz
   cd kubo
   sudo ./install.sh
   ipfs init --profile=lowpower
   ipfs daemon
   ```

2. IPFSノードIDを確認し、オプションでリモートピアを共有して追加します。

   ```bash
   ipfs id
   ```

### 開始

[「開始」セクションへのリンク](#開始)

```bash
sunrise-data rollkit
```

# 🚀 クイックスタート

> ローカルの Sunrise DA ノード、最小限の Rollkit ベースのソブリンロールアップ、およびサンプル dApp を 20 分以内に実行します。

> ローカルのSunrise DAノード、最小限のRollkitベースのソブリンロールアップ、 およびサンプルdAppを**20分以内**に実行します。

注記

Sunriseでの構築のすべての側面をカバーする包括的なガイド（詳細なモジュールリファレンス、高度な統合パターンなど）については、[Sunrise Builders Kit](https://cauchye.notion.site/Sunrise-Builders-Kit-1e02cd22bc1680f3bebcd4f02f2fbc18?pvs=4)をご覧ください。

このガイドでは、Sunrise Layerで構築するための完全な開発環境を設定する方法を説明します。次のことを学びます。

* ローカルのSunriseデータ可用性（DA）ノードを設定する
* Rollkitを使用して最小限のソブリンロールアップを作成する
* Sunriseクライアントを使用してネットワークと対話する
* 主要な機能を示すサンプルdAppを実行する

Sunriseでの構築のすべての側面をカバーする包括的なガイドについては、[Sunrise Builders Kit](https://cauchye.notion.site/Sunrise-Builders-Kit-1e02cd22bc1680f3bebcd4f02f2fbc18?pvs=4)をご覧ください。

***

## 前提条件

[「前提条件」セクションへのリンク](#前提条件)

開始する前に、次のツールがインストールされていることを確認してください。

| ツール                         | バージョン    | 目的                              |
| --------------------------- | -------- | ------------------------------- |
| **Go**                      | `>=1.22` | Sunriseバイナリとコアコンポーネントをビルドする     |
| **Rust + Cargo**            | stable   | Rollkitデモチェーンとスマートコントラクトをビルドする  |
| **Node.js**                 | `>=20`   | JSクライアント、スクリプト、Webアプリケーションを実行する |
| **Docker + Docker Compose** | latest   | コンテナ化されたサービスと開発スタックを実行する        |
| （オプション）**direnv**           | any      | シェルで環境変数を自動的にロードする              |

```bash
# macOS（brew）の例
brew install go rustup node docker direnv
rustup default stable
```

## 1. リポジトリをクローンする

[「1. リポジトリをクローンする」セクションへのリンク](#1-リポジトリをクローンする)

3つの主要コンポーネントで開発プレイグラウンドを作成します。

```bash
mkdir sunrise-playground && cd $_
git clone https://github.com/sunriselayer/network     sunrise-da
git clone https://github.com/rollkit/rollkit          rollkit
git clone https://github.com/sunriselayer/examples    examples
```

* `sunrise-da`: コアのSunriseネットワーク実装
* `rollkit`: ソブリンロールアップを構築するためのフレームワーク
* `examples`: サンプルアプリケーションと統合の例

## 2. ローカルのSunrise DAノードを起動する

[「2. ローカルのSunrise DAノードを起動する」セクションへのリンク](#2-ローカルのsunrise-daノードを起動する)

Sunrise DAノードはネットワークの基盤であり、ロールアップにデータ可用性サービスを提供します。

```bash
cd sunrise-da
make install             # 'sunrised'をビルドします
sunrised init dev --chain-id goldberg-local
sunrised start
```

ヒント

代わりにDockerで実行したい場合:

```bash
docker compose -f docker/local-da.yml up --build
```

### ポート

[「ポート」セクションへのリンク](#ポート)

| サービス           | ポート   | 目的                         |
| -------------- | ----- | -------------------------- |
| Tendermint RPC | 26657 | トランザクションとクエリのメインRPCエンドポイント |
| gRPC           | 9090  | 高度な操作のためのプロトコルバッファインターフェース |

## 3. アカウントに資金を供給する（フォーセット）

[「3. アカウントに資金を供給する（フォーセット）」セクションへのリンク](#3-アカウントに資金を供給するフォーセット)

ネットワークと対話するためにテストアカウントを作成し、資金を供給します。

```bash
sunrised keys add alice --keyring-backend test
sunrised tx bank mint $(sunrised keys show alice -a) 1000000000urise \
  --from alice --keyring-backend test --yes
```

これにより、「alice」という名前の新しいアカウントが作成され、テスト用に10億マイクロRISEトークン（`urise`）がミントされます。

## 4. 最小限のRollkitソブリンロールアップを起動する

[「4. 最小限のRollkitソブリンロールアップを起動する」セクションへのリンク](#4-最小限のrollkitソブリンロールアップを起動する)

Rollkitは、データ可用性のためにSunriseを使用できるソブリンロールアップを構築するためのフレームワークです。

```bash
cd ../rollkit
make demo                # デモバイナリ'demo-rollup'をビルドします


# BLOBをSunrise DAに保存するようにRollkitを設定します
cat <<EOF > rollup.config.toml
[da]
rpc_address = "http://localhost:26657"
fee_denom   = "uusdrise"
gas_price   = "0.025"
[rollup]
chain_id = "demo-rollup-1"
EOF


./demo-rollup start --config rollup.config.toml
```

ロールアップは、ブロックデータを自動的にSunriseに公開し、DA証明を取得します。

## 5. @sunriselayer/clientでBLOBを投稿して検証する

[「5. @sunriselayer/clientでBLOBを投稿して検証する」セクションへのリンク](#5-sunriselayerclientでblobを投稿して検証する)

Sunriseクライアントは、Sunriseネットワークと対話するためのJavaScript/TypeScriptライブラリです。使用方法は次のとおりです。

```bash
# ルートのプレイグラウンドディレクトリ内
npm create vite@latest js-client-demo -- --template vanilla
cd js-client-demo && npm i @sunriselayer/client


cat <<'JS' > src/index.js
import { SunriseClient } from "@sunriselayer/client";


const rpc = "http://localhost:26657";
const main = async () => {
  const client = await SunriseClient.connect(rpc);


  const { transactionHash } = await client.da.submitBlob(
    "Hello Sunrise!",
    { gasLimit: 200_000, feeDenom: "uusdrise", gasPrice: "0.025" }
  );
  console.log("Blob tx:", transactionHash);


  const proof = await client.da.getBlobProof(transactionHash);
  console.log("Inclusion proof:", proof);
};
main();
JS
node src/index.js
```

この例では、次のことを示します。

* Sunriseノードへの接続
* データBLOBの送信
* 包含のマークル証明の取得

## 6. サンプルdAppを実行する（トークンスワップ）

[「6. サンプルdAppを実行する（トークンスワップ）」セクションへのリンク](#6-サンプルdappを実行するトークンスワップ)

サンプルdAppは、Sunriseの流動性プールモジュールを使用したトークンスワップを示します。

```bash
cd ../../examples/swap-demo
npm i
npm run dev        # http://localhost:5173を開きます
```

デモUI：

* @sunriselayer/clientに接続します
* ロールアップのx/swapモジュールを介してテストトークンをスワップします
* Sunrise DAから取得したライブ残高を表示します

## 7. 次のステップ

[「7. 次のステップ」セクションへのリンク](#7-次のステップ)

| 内容                | 場所                                          | 説明                                |
| ----------------- | ------------------------------------------- | --------------------------------- |
| 完全なクライアントリファレンス   | [クライアントドキュメント](/build/client)               | @sunriselayer/clientの完全なAPIドキュメント |
| 本番用Rollkitチェーンの構築 | [Rollkitガイド](/build/l2-blockchains/rollkit) | 本番用ロールアップのデプロイガイド                 |
| バリデーターとDA証明       | [バリデーターガイド](/build/validators)              | バリデーターのセットアップとDA証明の生成について学ぶ       |
| 概念的な詳細            | [学習セクション](/learn/sunrise)                   | Sunriseのコアコンセプトを理解する              |

## トラブルシューティング

[「トラブルシューティング」セクションへのリンク](#トラブルシューティング)

| 症状                      | 修正                                                     | 説明                                   |
| ----------------------- | ------------------------------------------------------ | ------------------------------------ |
| ポート26657でECONNREFUSED   | `sunrised start`が実行されていないか、RPC URLが間違っている              | Sunriseノードが実行され、アクセス可能であることを確認してください |
| RollkitがBLOBを投稿できない     | `~/.sunrise/config/app.toml`で`min-gas-prices`を確認してください | ガス価格の設定がネットワーク要件と一致していることを確認してください   |
| BLOB txがメモリプールでスタックしている | ガス価格が低い → `--gas-prices 0.025urise`を使用してください           | トランザクション処理を確実にするためにガス価格を上げてください      |

## クリーンアップ

[「クリーンアップ」セクションへのリンク](#クリーンアップ)

```bash
pkill sunrised demo-rollup || true
docker compose -f docker/local-da.yml down -v || true
rm -rf ~/sunrise-playground
```

ハッピーハッキング！🎉

# バリデーター

> ブロックの生成と検証に加えて、Sunriseのバリデーターはネットワークのセキュリティと安定性において重要な役割を果たします。このセクションでは、バリデーターの責任、設定、および関連する操作の概要を説明します。

ブロックの生成と検証に加えて、Sunriseのバリデーターはネットワークのセキュリティと安定性において重要な役割を果たします。このセクションでは、バリデーターの責任、設定、および関連する操作の概要を説明します。

## バリデーターになる方法

[「バリデーターになる方法」セクションへのリンク](#バリデーターになる方法)

Sunriseでバリデーターになるには、最低**1 vRISE**をステークする必要があります。vRISEは、流動性を提供するためのインセンティブとしてのみ取得できる譲渡不可能なガバナンストークンです。

バリデーターの作成と設定の詳細な手順については、次のドキュメントを参照してください。

* [バリデーターになる方法](/build/validators/validator)

## 主な責任と設定

[「主な責任と設定」セクションへのリンク](#主な責任と設定)

### データ可用性の検証

[「データ可用性の検証」セクションへのリンク](#データ可用性の検証)

ブロックの生成を超えて、Sunriseバリデーターは、不正の可能性があるとフラグが立てられたデータ可用性（DA）レイヤー上のデータを確認するという重要な義務を負っています。

この検証プロセスを自動化するために、バリデーターノードは常に次の3つのデーモンを実行する必要があります。

1. `sunrised`（Cosmovisorとの統合を推奨）
2. `sunrise-data validator`
3. `IPFSデーモン`

DA検証メカニズムと設定の詳細については、こちらを参照してください。

* [データ可用性の証明](/build/validators/data-availability-proof)

## RISEの自己委任

[「RISEの自己委任」セクションへのリンク](#riseの自己委任)

バリデーターは、自身のRISE（通常の残高またはロックアップされた残高のいずれかから）を自己委任することができます。この自己委任により、ブロック生成の割り当てが増加し、より多くのステーキング報酬を得ることができます。

自己委任の具体的な方法については、次のドキュメントで詳しく説明しています。

* [自己委任](/build/validators/self-delegation)

# データ可用性の証明

> Sunriseのデータ可用性レイヤーはバリデーターによって検証されます。バリデーターは、無効である可能性のあるデータを検証し、その証明をチェーンに送信する必要があります。

Sunriseのデータ可用性レイヤーはバリデーターによって検証されます。バリデーターは、無効である可能性のあるデータを検証し、その証明をチェーンに送信する必要があります。

このセクションでは、バリデーターがデータを証明する方法について説明します。

## 証明

[「証明」セクションへのリンク](#証明)

証明が必要なデータは、MsgSubmitInvalidityが送信され、ステータスが`CHALLENGING`に変更されたものだけです。

`CHALLENGING`のしきい値は、全シャードの33%（ジェネシスのデフォルト）に対してMsgSubmitInvalidityが送信された場合です。

その後、バリデーターは検証されます。一定数以上のシャードが証明された場合、ステータスは通常通り`VERIFIED`に変わります。そうでない場合、ステータスは`REJECTED`に変わります。

データ可用性レイヤーのステータスとデータの証明については、[データ可用性](/learn/sunrise/data-availability)を参照してください。

## バリデーターのためのSunrise-Data

[「バリデーターのためのSunrise-Data」セクションへのリンク](#バリデーターのためのsunrise-data)

sunrise-dataは、`CHALLENGING`になったデータを監視し、証明する機能をバリデーターに提供します。

### バリデーターの証明代理人を登録する

[「バリデーターの証明代理人を登録する」セクションへのリンク](#バリデーターの証明代理人を登録する)

バリデーターは自分でtxを送信して証明データを送信できますが、キーの漏洩を防ぐために代理人アドレスを使用することをお勧めします。

まず、代理人として機能する新しいアカウントを作成します。

```bash
sunrised keys add your_deputy_account --keyring-backend=test
```

次に、`tx bank send`コマンドを使用して、このアカウントにいくらかの`uusdrise`を送信します。これは、`SubmitValidityProof`トランザクションを送信する際のガス料金の支払いに使用されます。

```bash
DEPUTY_ADDRESS=$(sunrised keys show your_deputy_account -a --keyring-backend=test)
sunrised tx bank send [your_validator_key] $DEPUTY_ADDRESS 1000000uusdrise \
    --chain-id=$CHAIN_ID \
    --gas-prices=0.025uusdrise --gas-adjustment 1.2 \
    --gas=auto \
    -y
```

最後に、バリデーターに代理人アドレスを登録します。このトランザクションは、バリデーターのアカウントから送信する必要があり、一度だけ実行すれば十分です。

```bash
sunrised tx da register-proof-deputy $DEPUTY_ADDRESS \
   --from [your_validator_key] \
   --chain-id=$CHAIN_ID \
   --gas-prices=0.025uusdrise --gas-adjustment 1.2 \
   --gas=auto \
   -y
```

`sunrise-data`で使用する代理人のアドレスを登録します。

### 設定方法

[「設定方法」セクションへのリンク](#設定方法)

1. バリデーターとして`sunrised`を実行します。設定については、[バリデーターノード](/run-a-sunrise-node/types/consensus/validator-node)を参照してください。

2. sunrise-dataリポジトリをクローンします。

   ```bash
   cd ~
   git clone https://github.com/sunriselayer/sunrise-data.git
   cd sunrise-data
   make install
   ```

3. `config.toml`を作成して編集します。

   ```bash
   cp config.default.toml config.toml
   vi config.toml
   ```

   ローカルのIPFSデーモンに接続するには、`ipfs_api_url`フィールドを空のままにします。

   `home_path`を`.sunrise`ディレクトリに、`proof_deputy_account`をsunrisedキーの名前に、`validator_address`をバリデーターアドレスに変更します。

   ```toml
   [api]
   port = 8000
   ipfs_api_url = ""
   ipfs_address_info = ""


   [chain]
   address_prefix="sunrise"
   home_path="/home/ubuntu/.sunrise"
   keyring_backend="test"
   sunrised_rpc="http://localhost:26657"


   [validator]
    proof_deputy_account="your_deputy_account"
    validator_address="sunrisevaloper1a8jcsmla6heu99ldtazc27dna4qcd4jyv75vcz"
    proof_fees="10000uusdrise"
    proof_interval=5
   ```

### ローカルでIPFSを実行する

[「ローカルでIPFSを実行する」セクションへのリンク](#ローカルでipfsを実行する)

1. IPFSを実行します。

   ```bash
   wget https://dist.ipfs.tech/kubo/v0.31.0/kubo_v0.31.0_linux-amd64.tar.gz
   tar -xvzf kubo_v0.31.0_linux-amd64.tar.gz
   cd kubo
   sudo ./install.sh
   ipfs init --profile=lowpower
   ipfs daemon
   ```

2. IPFSノードIDを確認し、オプションでリモートピアを共有して追加します。

   ```bash
   ipfs id
   ```

### データの証明を開始する

[「データの証明を開始する」セクションへのリンク](#データの証明を開始する)

sunrise-dataディレクトリで、

```bash
sunrise-data validator
```

またはサービスとして登録します。

```bash
vi /etc/systemd/system/sunrise-data.service
systemctl enable sunrise-data
systemctl start sunrise-data
```

```ini
[Unit]
Description = sunrise-data validator daemon
After=network-online.target


[Service]
User=ubuntu
WorkingDirectory=/home/ubuntu/sunrise-data
ExecStart = /home/ubuntu/go/bin/sunrise-data validator
Restart=on-failure
RestartSec=3
LimitNOFILE=1400000


[Install]
WantedBy = multi-user.target
```

セットアップが成功すると、表示は次のようになります。

```bash
$ sunrise-data validator
{"level":"info","time":"2025-02-19T18:32:52+09:00","message":"Starting validator task"}
{"level":"info","time":"2025-02-19T18:32:52+09:00","message":"validator: sunrisevaloper1a8jcsmla6heu99ldtazc27dna4qcd4jyv75vcz deputy: sunrise155u042u8wk3al32h3vzxu989jj76k4zcc6d03n"}
{"level":"info","time":"2025-02-19T18:32:52+09:00","message":"On-chain data is checked every 5 sec"}
```

# RISEの自己委任

> バリデーターは、ステーキング報酬を得るためにRISEを自己委任することができます。

バリデーターは、ステーキング報酬を得るためにRISEを自己委任することができます。

注意

**注**: vRISEの委任とは異なり、RISEを委任してもガバナンスの投票権は付与されません。

RISEを委任する方法は、トークンが通常のウォレット残高にあるか、ロックアップアカウントにあるかによって異なります。それぞれの場合で使用するモジュールとコマンドは異なります。

***

## 通常の残高からの委任（`x/shareclass`）

[「通常の残高からの委任（x/shareclass）」セクションへのリンク](#通常の残高からの委任xshareclass)

ウォレットに直接保有されているRISEを委任するには、`x/shareclass`モジュールの`non-voting-delegate`コマンドを使用します。

### 委任方法

[「委任方法」セクションへのリンク](#委任方法)

**使用法:**

```bash
sunrised tx shareclass non-voting-delegate [validator_address] [amount] [flags]
```

**例:**

```bash
# バリデーターアドレスを取得
VALIDATOR_ADDRESS=$(sunrised keys show <your_validator_key> --bech val -a)


# 委任を実行
sunrised tx shareclass non-voting-delegate $VALIDATOR_ADDRESS 10000000urise \
    --from <your_validator_key> \
    --chain-id <your_chain_id> \
    --gas-prices=0.025uusdrise --gas-adjustment 1.2 \
    --gas=auto \
    -y
```

### 報酬の請求方法

[「報酬の請求方法」セクションへのリンク](#報酬の請求方法)

`x/shareclass`モジュールの`claim-rewards`コマンドを使用して、蓄積されたステーキング報酬を請求します。報酬はウォレットに送られます。

**使用法:**

```bash
sunrised tx shareclass claim-rewards [validator_address] [flags]
```

**例:**

```bash
VALIDATOR_ADDRESS=$(sunrised keys show <your_validator_key> --bech val -a)


sunrised tx shareclass claim-rewards $VALIDATOR_ADDRESS \
    --from <your_validator_key> \
    --chain-id <your_chain_id> \
    --gas-prices=0.025uusdrise --gas-adjustment 1.2 \
    --gas=auto \
    -y
```

***

## ロックアップアカウントからの委任（`x/lockup`）

[「ロックアップアカウントからの委任（x/lockup）」セクションへのリンク](#ロックアップアカウントからの委任xlockup)

ロックアップの一部であるRISE（例：エアドロップから）を委任するには、`x/lockup`モジュールを使用する必要があります。

### 1. ロックアップアカウントIDを見つける

[「1. ロックアップアカウントIDを見つける」セクションへのリンク](#1-ロックアップアカウントidを見つける)

まず、委任したいロックアップアカウントのIDを特定する必要があります。`lockup-accounts`クエリを使用して、キーが所有するすべてのロックアップアカウントを一覧表示できます。

**使用法:**

```bash
sunrised query lockup lockup-accounts [owner] [flags]
```

**例:**

```bash
OWNER_ADDRESS=$(sunrised keys show <your_validator_key> -a)


sunrised query lockup lockup-accounts $OWNER_ADDRESS --output json
```

このコマンドの出力から、正しいアカウントを見つけてその`id`をメモします。

### 2. 委任方法

[「2. 委任方法」セクションへのリンク](#2-委任方法)

ロックアップアカウントIDを取得したら、`x/lockup`モジュールの`non-voting-delegate`コマンドを使用します。

**使用法:**

```bash
sunrised tx lockup non-voting-delegate [lockup_account_id] [validator_address] [amount] [flags]
```

**例:**

```bash
LOCKUP_ID="<your_lockup_account_id>"
VALIDATOR_ADDRESS=$(sunrised keys show <your_validator_key> --bech val -a)


sunrised tx lockup non-voting-delegate $LOCKUP_ID $VALIDATOR_ADDRESS 10000000urise \
    --from <your_validator_key> \
    --chain-id <your_chain_id> \
    --gas-prices=0.025uusdrise --gas-adjustment 1.2 \
    --gas=auto \
    -y
```

### 3. 報酬の請求方法

[「3. 報酬の請求方法」セクションへのリンク](#3-報酬の請求方法)

`x/lockup`モジュールの`claim-rewards`コマンドを使用します。

注記

**重要**: ロックアップ委任から請求された報酬は、メインウォレットではなく、ロックアップアカウント自体に送り返されます。報酬のRISE部分は、元のロックアップスケジュールに従います。

**使用法:**

```bash
sunrised tx lockup claim-rewards [lockup_account_id] [flags]
```

**例:**

```bash
LOCKUP_ID="<your_lockup_account_id>"


sunrised tx lockup claim-rewards $LOCKUP_ID \
    --from <your_validator_key> \
    --chain-id <your_chain_id> \
    --gas-prices=0.025uusdrise --gas-adjustment 1.2 \
    --gas=auto \
    -y
```

***

## Sunriseアプリの使用

[「Sunriseアプリの使用」セクションへのリンク](#sunriseアプリの使用)

これらの委任および報酬請求操作は、**Sunriseアプリ**インターフェースを介して簡単に行うこともできます。

詳細については、次のドキュメントを参照してください。

* **通常の委任の場合:** [ガバナンス](/learn/sunrise-app/gov)
* **ロックされた資産の委任の場合:** [ロックアップ](/learn/sunrise-app/lockup)

# バリデーターになる方法

> このドキュメントでは、Sunriseチェーンでバリデーターになるための手順を説明します。

このドキュメントでは、Sunriseチェーンでバリデーターになるための手順を説明します。

## 前提条件

[「前提条件」セクションへのリンク](#前提条件)

バリデーターを運用する前に、[フルコンセンサスノード](/run-a-sunrise-node/types/consensus/full-consensus-node)を設定し、ネットワークと完全に同期している必要があります。

## データ可用性の検証

[「データ可用性の検証」セクションへのリンク](#データ可用性の検証)

注意

Sunriseネットワークのバリデーターは、データ可用性（DA）レイヤーのデータを検証する必要があります。これは重要な責任です。設定方法については、[データ可用性レイヤーの証明](/build/validators/data-availability-proof)ガイドを参照してください。

## Cosmovisorのセットアップ

[「Cosmovisorのセットアップ」セクションへのリンク](#cosmovisorのセットアップ)

メインネットでは、ノードの実行にCosmovisorを使用することを強くお勧めします。Cosmovisorを使用すると、最小限のダウンタイムでチェーンのアップグレードをスムーズに実行できます。

詳細については、[Cosmovisor設定チュートリアル](/run-a-sunrise-node/types/consensus/setup-cosmovisor)に従ってください。

自動アップグレードを有効にするには、次の環境変数を設定することをお勧めします。

```bash
export DAEMON_ALLOW_DOWNLOAD_BINARIES=true
```

## バイナリとジェネシスファイル

[「バイナリとジェネシスファイル」セクションへのリンク](#バイナリとジェネシスファイル)

バリデーターを設定する際には、正しいバージョンのバイナリと`genesis.json`を使用することが重要です。

* **バイナリ:** 最新のバイナリは[GitHubリリース](https://github.com/sunriselayer/sunrise/releases/tag/v1.0.0)からダウンロードできます。
* **ジェネシスファイル:** `genesis.json`ファイルは[ネットワークリポジトリ](https://github.com/sunriselayer/network/tree/main/sunrise-1)にあります。

## バリデーターの作成

[「バリデーターの作成」セクションへのリンク](#バリデーターの作成)

バリデーターを作成するには、ジェネシスで参加する方法と、チェーンが開始した後に参加する方法の2つがあります。

### ジェネシスバリデーターとして参加する（Gentx）

[「ジェネシスバリデーターとして参加する（Gentx）」セクションへのリンク](#ジェネシスバリデーターとして参加するgentx)

ネットワークが開始する前にバリデーターとして参加する（ジェネシスバリデーターとして）には、`gentx`（ジェネシストランザクション）を生成して送信する必要があります。

詳細な手順については、[sunriselayer/networkリポジトリのREADME](https://github.com/sunriselayer/network/blob/main/sunrise-1/gentx/README.md)を参照してください。

### チェーン開始後にバリデーターとして参加する

[「チェーン開始後にバリデーターとして参加する」セクションへのリンク](#チェーン開始後にバリデーターとして参加する)

チェーンがすでに実行されている場合は、次の方法でバリデーターを作成できます。

#### `tx staking create-validator`

[「tx staking create-validator」セクションへのリンク](#tx-staking-create-validator)

これは標準のCosmos SDKメソッドで、`validator.json`ファイルを使用してバリデーターを作成します。このメソッドでは、自己委任のために`vRISE`が必要です。

1. **バリデーターの公開鍵を取得する**

   `sunrised tendermint show-validator`コマンドを実行して、バリデーターの公開鍵（pubkey）を取得します。

   ```bash
   sunrised tendermint show-validator
   ```

2. **`validator.json`ファイルを作成する**

   次の内容で`validator.json`ファイルを作成します。上記で取得した値で`pubkey`を設定します。

   ```json
   {
       "pubkey": {"@type":"/cosmos.crypto.ed25519.PubKey","key":"oWg2ISpLF405Jcm2vXV+2v4fnjodh6aafuIdeoW+rUw="},
       "amount": "1000000uvrise",
       "moniker": "myvalidator",
       "identity": "optional identity signature (ex. UPort or Keybase)",
       "website": "validator's (optional) website",
       "security": "validator's (optional) security contact email",
       "details": "validator's (optional) details",
       "commission-rate": "0.1",
       "commission-max-rate": "0.2",
       "commission-max-change-rate": "0.01",
       "min-self-delegation": "1"
   }
   ```

   * `amount`は`uvrise`で指定します。
   * `min-self-delegation`も`vRISE`の量です。

3. **`create-validator`トランザクションを送信する**

   ```bash
   sunrised tx staking create-validator path/to/validator.json --from <keyname> --chain-id <chain-id> --gas="auto" --gas-prices=<gas-prices> -y
   ```

   **使用法:**

   ```bash
   sunrised tx staking create-validator [path/to/validator.json] [flags]
   ```

## バックアップ

[「バックアップ」セクションへのリンク](#バックアップ)

キーファイルのバックアップは、バリデーターの運用にとって重要です。次のファイルを安全な場所にバックアップしてください。

* `~/.sunrise/config/priv_validator_key.json`
* `~/.sunrise/config/node_key.json`

これらのバックアップファイルを暗号化することを強くお勧めします。

# 💴 $GLU

> $GLU トークンは、Sunrise 上の Gluon ロールアップのネイティブトークンです。以前は UnUniFi レイヤー 1 アプリチェーン上の $GUU トークンでした。

$GLU トークンは、Sunrise 上の Gluon ロールアップのネイティブトークンです。以前は UnUniFi レイヤー 1 アプリチェーン上の $GUU トークンでした。

# 🏦 Gluon

> Gluonは、[Rollkit](https://rollkit.dev/)で構築され、次世代L1であるSunriseによってセキュリティが確保されたオーダーブック型レイヤー2ブロックチェーンです。Sunriseは、データの可用性と流動性を兼ね備えています。\

Gluonは、[Rollkit](https://rollkit.dev/)で構築され、次世代L1であるSunriseによってセキュリティが確保されたオーダーブック型レイヤー2ブロックチェーンです。Sunriseは、データの可用性と流動性を兼ね備えています。\
Interliquid Networksのベースレイヤーです。\
このロールアップは、SunriseのProof-of-Liquidity (PoL)を実装し、IBCを活用してシームレスな資産移動を実現します。

***

## 主な特徴

[「主な特徴」セクションへのリンク](#主な特徴)

| カテゴリ                  | 説明                                                            |
| --------------------- | ------------------------------------------------------------- |
| **オーダーブックDEX**        | 決定論的なマッチングロジック、価格優先・時間優先、オンチェーンでの決済。                          |
| **Web2スタイルのオンボーディング** | OAuth登録により秘密鍵管理を抽象化。ユーザーの鍵はクライアントデバイスから出ません。                  |
| **オフチェーンでのマッチング**     | 高スループットのマッチングエンジンが、オンチェーンで最終決定する前に取引をバッチ処理します。                |
| **二重署名モデル**           | すべての資金移動トランザクションには、ユーザーとオペレーターの両方の署名が必要で、一方的な引き出しを防ぎます。       |
| **IBCによる入出金**         | ネイティブIBCチャネルがGluonを外部のCosmos-SDKチェーンに接続し、信頼性を最小限に抑えた送金を実現します。 |

***

## 開発者概要

[「開発者概要」セクションへのリンク](#開発者概要)

* **ソースコード:** <https://github.com/sunriselayer/gluon>
* **Sunrise Rollkitアダプター:** <https://github.com/sunriselayer/sunrise-rollkit>
* **使用モジュール:** `x/order`、`x/perp`、`x/customauth`（protobuf定義を参照）。

***

## 認証と鍵管理

[「認証と鍵管理」セクションへのリンク](#認証と鍵管理)

Gluonは、ウェブで生成されたECDSAキーとオンチェーンアカウントをペアにする\_CustomAuth\_フローを導入しています。

1. **OAuthサインアップ** → サーバーが決定論的にユーザーアドレスを導出します。
2. **デバイスペアリング** → ブラウザがAESキーとECDSAキーを生成し、後者はAES暗号化されてサーバー側に保存されます。
3. **検証キー**がチェーン上で提出されます（ペアリングトランザクション）。

### サインアップフロー

[「サインアップフロー」セクションへのリンク](#サインアップフロー)

サインアッププロセスは、意図的にシンプルでユーザーフレンドリーになるように設計されています。

* ユーザーは、使い慣れたOAuthプロバイダー（Google、GitHubなど）を使用してサインアップできます。
* アプリケーションは、ユーザーのSunriseアドレスを自動的に導出します。
* 手動でのウォレット設定やシードフレーズの管理は不要です。

```
sequenceDiagram
    autonumber
    User  ->>  App     : OAuthサインアップ
    App   -->  App     : Sunriseアドレスを導出
```

この合理化されたプロセスにより、ユーザーはブロックチェーンの複雑さなしに迅速に取引を開始できます。

### デバイスペアリングフロー

[「デバイスペアリングフロー」セクションへのリンク](#デバイスペアリングフロー)

デバイスペアリングプロセスでは、いくつかのセキュリティ対策が実装されています。

* デバイスごとに一意の暗号化キーを生成します。
* 機密性の高いECDSAキーを暗号化して安全に保ちます。
* 将来のトランザクションのための検証メカニズムを確立します。

```
sequenceDiagram
    autonumber
    User     ->> Browser : ペアリングを開始
    Browser  --> Browser : AESキーを生成
    Browser  --> Browser : ECDSAキーを生成
    Browser  --> Browser : ECDSAをAESで暗号化
    Browser  ->> App     : 暗号化されたキーと検証キーをアップロード
    App      ->> Gluon   : Tx: 検証キーを登録
```

この複数ステップのプロセスにより、ユーザーのコントロールを維持しながら、安全なキー管理が保証されます。

### 注文作成（オフチェーン）

[「注文作成（オフチェーン）」セクションへのリンク](#注文作成オフチェーン)

オフチェーンでの注文作成プロセスにより、高性能な取引が可能になります。

* 注文は、ユーザーの暗号化されたキーを使用してローカルで署名されます。
* 署名は、受け入れられる前に検証されます。
* 注文は、マッチングのためにバッチ処理されるまでオフチェーンのままです。

```
sequenceDiagram
    autonumber
    User     ->> Browser : 注文を発注
    Browser  --> Browser : ECDSAキーを復号
    Browser  --> Browser : 注文ペイロードに署名
    Browser  ->> App     : 注文と署名
```

このアプローチにより、セキュリティを維持しながら、1秒未満での注文発注が可能になります。

### 注文キャンセル（オンチェーン）

[「注文キャンセル（オンチェーン）」セクションへのリンク](#注文キャンセルオンチェーン)

キャンセルプロセスは、注文の整合性を保証します。

* キャンセルは、透明性のためにオンチェーンで記録されます。
* 古い署名のリプレイ攻撃を防ぎます。
* キャンセルの不変の証明を提供します。

```
sequenceDiagram
    autonumber
    User ->> App   : 注文をキャンセル
    App  ->> Gluon : Tx: 注文を登録してキャンセル
```

このオンチェーンレコードは、オーダーブックの整合性を維持するために不可欠です。

### 出金（IBC）

[「出金（IBC）」セクションへのリンク](#出金ibc)

出金プロセスでは、複数のセキュリティレイヤーが実装されています。

* ユーザーとオペレーターの両方からの二重署名が必要です。
* 新しいキーペアには24時間のセキュリティ遅延を実装しています。
* 信頼性を最小限に抑えたクロスチェーン転送にIBCを使用します。

```
sequenceDiagram
    autonumber
    User     ->> Browser : 出金リクエスト
    Browser  --> Browser : ECDSAキーを復号してtxに署名
    Browser  ->> App     : 署名済みの出金
    App      --> App     : オペレーターがtxに署名
    App      ->> Gluon   : 二重署名付きのTx
    Gluon    --> Gluon   : 署名と24時間のキーペアリング遅延を検証
    Gluon    ->> ChainX  : IBC転送
```

この多層的なアプローチにより、チェーン間で安全で信頼性の高い資産移転が保証されます。

> 外部ウォレット（例：MetaMask）は不要です。キーはクライアント側に残り、オンチェーンで失効可能です。

## 取引ライフサイクル

[「取引ライフサイクル」セクションへのリンク](#取引ライフサイクル)

### 注文作成（オフチェーン）

[「注文作成（オフチェーン）」セクションへのリンク](#注文作成オフチェーン-1)

注文は、最初のマッチングトランザクションでバッチ処理されるまでオフチェーンに存在し、1秒未満のUXを実現します。

```
sequenceDiagram
    autonumber
    User     ->> Browser : 注文を発注
    Browser  --> Browser : ECDSAキーを復号
    Browser  --> Browser : 注文ペイロードに署名
    Browser  ->> App     : 注文と署名
```

### 注文キャンセル（オンチェーン）

[「注文キャンセル（オンチェーン）」セクションへのリンク](#注文キャンセルオンチェーン-1)

オンチェーンレコードは、オペレーターが古いユーザー署名をリプレイするのを防ぎます。

```
sequenceDiagram
    autonumber
    User ->> App   : 注文をキャンセル
    App  ->> Gluon : Tx: 注文を登録してキャンセル
```

### 出金（IBC）

[「出金（IBC）」セクションへのリンク](#出金ibc-1)

キーペアリングと資金移動の間に24時間の遅延を設けることで、オペレーターキーの漏洩リスクを軽減します。

```
sequenceDiagram
    autonumber
    User     ->> Browser : 出金リクエスト
    Browser  --> Browser : ECDSAキーを復号してtxに署名
    Browser  ->> App     : 署名済みの出金
    App      --> App     : オペレーターがtxに署名
    App      ->> Gluon   : 二重署名付きのTx
    Gluon    --> Gluon   : 署名と24時間のキーペアリング遅延を検証
    Gluon    ->> ChainX  : IBC転送
```

## 注文モジュール（protobuf）

[「注文モジュール（protobuf）」セクションへのリンク](#注文モジュールprotobuf)

注文サブシステムは`gluon/order/*`で定義されています。コアタイプ：

`BaseOrder`メッセージは、システム内のすべての注文の基本構造を定義します。

* 各注文は、特定のユーザーアドレスと取引ペアに関連付けられています。
* 注文は、指値注文（指定価格あり）または成行注文のいずれかです。
* 有効期限のタイムスタンプは、リプレイ攻撃を防ぎ、注文の鮮度を保証します。
* 金額と価格は、任意の精度を処理するために文字列として保存されます。

```go
message BaseOrder {
  string         address      = 1;  // bech32ユーザーアドレス
  string         denom_base   = 2;  // 例：「uatom」
  string         denom_quote  = 3;  // 例：「uusdc」
  OrderDirection direction    = 4;  // BUY / SELL
  string         amount       = 5;  // 基本金額
  string         limit_price  = 6;  // オプション
  google.protobuf.Timestamp expiry = 7;  // リプレイ攻撃対策
}


enum OrderDirection {
  ORDER_DIRECTION_UNSPECIFIED = 0;
  ORDER_DIRECTION_BUY         = 1;
  ORDER_DIRECTION_SELL        = 2;
}
```

`OrderDirection` enumは、注文サイドをタイプセーフに指定する方法を提供します。

* UNSPECIFIEDをデフォルトとする標準的なprotobuf enum規則を使用します。
* 買い注文と売り注文を明確に区別します。
* コンパイル時のチェックにより、注文サイド関連のバグを防ぐのに役立ちます。

# 💴 RISE

> RISEトークンはSunriseネットワークのネイティブトークンです。手数料はUSDriseで支払われます。USDriseの取引手数料の一部はRISEにスワップされ、[Fee](/learn/sunrise/fee)モジュールで焼却されます。

RISEトークンはSunriseネットワークのネイティブトークンです。手数料はUSDriseで支払われます。USDriseの取引手数料の一部はRISEにスワップされ、[Fee](/learn/sunrise/fee)モジュールで焼却されます。

RISEはSunriseブロックチェーンでは`urise`として保存されます。Sunriseネットワーク上の`1000000urise`は、現実世界では1 RISEに換算されます。

* ティッカー：$SUNRISE
* ブロックチェーン上のデノミネーション：`urise`

RISEは、vRISEを1対1で焼却することでミントできます。

## vRISE

[「vRISE」セクションへのリンク](#vrise)

vRISEトークンは、ステーキング用の譲渡不可能なトークンです。ステークされた量は、ガバナンスの投票力として計算されます。

* ブロックチェーン上のデノミネーション：`uvrise`

vRISEはSunriseネットワークにステークできます。ステークされた量は、ガバナンスの投票力として計算されます。さらに、ステーカーへの報酬は、ステークされた量に比例して分配されます。

vRISEを取得するには、ユーザーは[流動性プール](/learn/sunrise/liquidity-pool)で流動性を提供する必要があります。

## トークンの使用法

[「トークンの使用法」セクションへのリンク](#トークンの使用法)

| 機能        | トークン                                                               | 詳細                               |
| --------- | ------------------------------------------------------------------ | -------------------------------- |
| セキュリティ    | ![RISE](/images/RISE.png) RISE + ![vRISE](/images/vRISE.svg) vRISE | vRISEとRISEの両方をコンセンサスのためにステークできます |
| ガバナンス     | ![vRISE](/images/vRISE.svg) vRISE                                  | vRISEはオンチェーンガバナンスとゲージ投票に使用されます   |
| セキュリティ排出量 | ![RISE](/images/RISE.png) RISE                                     | RISEはコンセンサス報酬としてステーカーに分配されます     |
| LP排出量     | ![vRISE](/images/vRISE.svg) vRISE                                  | vRISEはインセンティブとしてLPに分配されます        |
| 手数料       | 任意（![USDrise](/images/USDrise.png) USDrise にスワップ）                  | USDriseは取引手数料として使用されます           |

**凡例:**\
![RISE](/images/RISE.png) = RISE ![vRISE](/images/vRISE.svg) = vRISE ![USDrise](/images/USDrise.png) = USDrise

## トークノミクス

[「トークノミクス」セクションへのリンク](#トークノミクス)

### 概要

[「概要」セクションへのリンク](#概要)

* `[供給量] = [RISEの供給量] + [vRISEの供給量]`
* 供給上限は1,000,000,000です。
  * これは`[RISEの供給量] + [vRISEの供給量] <= 1,000,000,000`を意味します。
* 初期インフレ率の上限は10%です。
  * インフレ率の上限は年間8%ずつ徐々に減少します。
    * 例えば、2年目のインフレ率は9.2%です。
* 取引手数料（USDriseで支払い）の一部はRISEにスワップされ、焼却されます。
* 供給量は、供給上限とインフレ率の上限に従って増加します。
* 観測されるインフレ率は、インフレ率の上限とは異なります。
* インフレによってミントされたvRISEは、報酬としてステーカー、バリデーター、デリゲーターに分配されます。

### 定式表現

[「定式表現」セクションへのリンク](#定式表現)

* 年：t∈{0, 1, 2, …}
* RISEの供給量：stRISE​
* vRISEの供給量：stvRISE​
* 供給量：st​=stRISE​+stvRISE​
* 初期供給量：s0​=500,000,000
* 初期インフレ率の上限：πˉ\_0=0.1=10%
* ディスインフレ率：δ=0.08=8%
* 供給上限：sˉ=1,000,000,000
  * これは満たされなければなりません：st​≤sˉ
* インフレ率の上限：πˉ\_t
* 取引手数料で焼却されたRISE：bt​
* 供給量の推移：s\_t+1=min{(1+πˉ\_t)(st​−bt​), sˉ}
* インフレ率の上限の推移：πˉ\_t+1=max{(1−δ)πˉt​, 0.02}
  * これは次のことを意味します：mint​πˉ\_t=0.02=2%
* 観測されるインフレ率：π∗t=st​s∗t+1−st​​

#### シミュレーション

[「シミュレーション」セクションへのリンク](#シミュレーション)

このシミュレーションはbt​=0を仮定しています。

これは、取引手数料が焼却されないことを意味します。

* 0年から10年の間、実際のインフレ率は、焼却される取引手数料があるため、このシミュレーションよりも低くなります。
* 観測されるインフレ率がゼロであることは、バリデーターとステーカーへの報酬がゼロであることを意味しません。bt​>0の場合、報酬としてb\_t量のvRISEがミントされます。
* インフレ率の上限は厳密に遵守されるため、観測されるインフレ率が負の値になる可能性もあります。

| 年  | インフレ率の上限 |          総供給量 | 観測されるインフレ率 |
| -- | -------: | ------------: | ---------: |
| 0  |   10.00% |   500,000,000 |     10.00% |
| 1  |    9.20% |   550,000,000 |      9.20% |
| 2  |    8.46% |   600,600,000 |      8.46% |
| 3  |    7.79% |   651,434,784 |      7.79% |
| 4  |    7.16% |   702,161,229 |      7.16% |
| 5  |    6.59% |   752,463,565 |      6.59% |
| 6  |    6.06% |   802,057,048 |      6.06% |
| 7  |    5.58% |   850,690,179 |      5.58% |
| 8  |    5.13% |   898,145,641 |      5.13% |
| 9  |    4.72% |   944,240,170 |      4.72% |
| 10 |    4.34% |   988,823,543 |      1.13% |
| 11 |    4.00% | 1,000,000,000 |      0.00% |
| 12 |    3.68% | 1,000,000,000 |      0.00% |
| 13 |    3.38% | 1,000,000,000 |      0.00% |
| 14 |    3.11% | 1,000,000,000 |      0.00% |
| 15 |    2.86% | 1,000,000,000 |      0.00% |
| 16 |    2.63% | 1,000,000,000 |      0.00% |
| 17 |    2.42% | 1,000,000,000 |      0.00% |
| 18 |    2.23% | 1,000,000,000 |      0.00% |
| 19 |    2.05% | 1,000,000,000 |      0.00% |
| 20 |    2.00% | 1,000,000,000 |      0.00% |
| 21 |    2.00% | 1,000,000,000 |      0.00% |

## 対応ウォレットアプリケーション

[「対応ウォレットアプリケーション」セクションへのリンク](#対応ウォレットアプリケーション)

### Cosmosブロックチェーンをサポートするウォレット

[「Cosmosブロックチェーンをサポートするウォレット」セクションへのリンク](#cosmosブロックチェーンをサポートするウォレット)

* Keplr
* Leap

### コマンドラインインターフェース（CLI）

[「コマンドラインインターフェース（CLI）」セクションへのリンク](#コマンドラインインターフェースcli)

* sunrised

## 上場取引所

[「上場取引所」セクションへのリンク](#上場取引所)

* 近日公開

# アロケーション

> 一部はジェネシスでRISEに変換されます。

| セグメント                    | 総供給量の割合 | リリーススケジュール                                          |
| ------------------------ | ------- | --------------------------------------------------- |
| コミュニティエアドロップ（Kaitoは含まない） | 6.8%    | TGEで25%がアンロック、75%は6ヶ月間完全にロックされ、その後24ヶ月間かけて直線的にアンロック |
| コミュニティ貢献者＆助成金（Kaitoを含む）  | 30%     | TGE後3ヶ月間完全にロックされ、その後24ヶ月間かけて直線的にアンロック               |
| コミュニティラウンド               | 1.5%    | TGEで100%アンロック                                       |
| エコシステム                   | 27.2%   | TGEで25%がアンロック、75%は18ヶ月間かけて直線的にアンロック                 |
| 初期支援者                    | 14.5%   | TGEで5%がアンロック、95%は3ヶ月間完全にロックされ、その後12ヶ月間かけて直線的にアンロック  |
| 初期コア貢献者                  | 20%     | 6ヶ月間完全にロックされ、その後18ヶ月間かけて直線的にアンロック                   |

一部はジェネシスでRISEに変換されます。

# 🌆 Sunrise

> 🌆 Sunrise


# 🌅 アプリ

> Sunriseは、Sunriseブロックチェーンとそのエコシステムと対話するための包括的なツールスイートを提供する分散型アプリケーション（dApp）です。このガイドでは、開始するために必要な主要な概念と機能の概要を説明します。

Sunriseは、Sunriseブロックチェーンとそのエコシステムと対話するための包括的なツールスイートを提供する分散型アプリケーション（dApp）です。このガイドでは、開始するために必要な主要な概念と機能の概要を説明します。

## Sunriseのトークントリオ：RISE、vRISE、USDrise

[「Sunriseのトークントリオ：RISE、vRISE、USDrise」セクションへのリンク](#sunriseのトークントリオrisevriseusdrise)

Sunriseエコシステムは、それぞれ特定の目的を持つ3つの異なるトークンによって支えられています。

* ![RISE](/images/RISE.png) **RISE**: ネットワークの主要な価値蓄積およびコンセンサストークンです。ネットワークを保護し、報酬を得るためにステーキングすることができます。

* ![vRISE](/images/vRISE.svg) **vRISE**: 譲渡不可能なガバナンスおよびユーティリティトークンです。**vRISEは、プロトコルのガバナンスに参加するために不可欠です。**

  * **vRISEの獲得方法**: [**流動性プール**](/learn/sunrise-app/liquidity-pool)で流動性を提供することによってのみvRISEを獲得できます。
  * **vRISEの使用方法**: vRISEをステーキングして、[**ガバナンス**](/learn/sunrise-app/gov)提案の投票権を得たり、ゲージ投票を通じて流動性プールインセンティブを誘導したりします。

* ![USDrise](/images/USDrise.png) **USDrise**: プロトコルのネイティブステーブルコインです。すべての取引手数料の基本通貨として使用されます。

## コア機能

[「コア機能」セクションへのリンク](#コア機能)

アプリの主要セクションの概要は次のとおりです。各機能には、詳細なドキュメントページがあります。

* [**流動性プール**](/learn/sunrise-app/liquidity-pool)
  * さまざまなトークンペアに流動性を提供して、取引手数料と**vRISE報酬**を獲得します。流動性ポジションの管理は、vRISEを獲得するための鍵です。
* [**スワップ**](/learn/sunrise-app/swap)
  * 異なるブロックチェーン間でトークンをシームレスに交換します。
* [**ガバナンス**](/learn/sunrise-app/gov)
  * ステーキングした**vRISE**を使用して、ガバナンス提案と流動性プールインセンティブに投票します。RISEをステーキングしてコンセンサス報酬を得ることもできます。
* [**ロックアップ**](/learn/sunrise-app/lockup)
  * エアドロップやその他のプログラムから受け取ったロックされたトークンを管理します。これらのロックされたトークンをステーキングして、権利確定中に報酬を得ることができます。
* [**ポイントプログラム**](/learn/sunrise-app/point-program)
  * ステーキング、流動性の提供、新規ユーザーの紹介など、エコシステム内のさまざまな活動に参加してポイントを獲得します。

## Sunriseの手数料について

[「Sunriseの手数料について」セクションへのリンク](#sunriseの手数料について)

Sunriseチェーンは手数料抽象化メカニズムを使用しており、ユーザーにとって取引がスムーズになります。

* **USDriseはコア手数料トークン**: ネットワーク上のすべての取引手数料はUSDriseで計算され、支払われます。
* **（ほぼ）すべてのトークンで支払い可能**: 手数料抽象化のおかげで、保有する別のトークンを選択して手数料を支払うことができます。プロトコルは、取引の一部としてオンチェーンでUSDriseへのスワップを自動的に処理します。

手数料の仕組みや希望する手数料トークンの設定方法の詳細については、[**手数料ドキュメント**](/learn/sunrise-app/fee)を参照してください。

## ウォレットの接続

[「ウォレットの接続」セクションへのリンク](#ウォレットの接続)

開始するには、Cosmosウォレットを接続する必要があります。Sunriseは現在、次のウォレットをサポートしています。

* Keplr
* Leap

### 接続方法

[「接続方法」セクションへのリンク](#接続方法)

1. 通常ヘッダーにある\*\*「ウォレットを接続」\*\*ボタンをクリックします。
2. サポートされているウォレット（KeplrまたはLeap）のリストが表示されます。
3. 使用したいウォレットを選択し、ウォレット拡張機能内で接続要求を承認します。

接続されると、アドレスがヘッダーに表示され、クリックしてアドレスをコピーしたり、切断したりできます。

## 設定

[「設定」セクションへのリンク](#設定)

ヘッダーの歯車アイコンからアクセスできる**設定**メニューで、アプリの体験をカスタマイズできます。

* **テーマ**: 好みに合わせてシステム、ライト、ダークモードから選択します。
* **手数料トークン**: 取引手数料の支払いに使用したいトークンを選択します。
* **資産の可視性**: 外部ブロックチェーンのどのトークンをアプリ全体で表示するかを管理します。
* **ノード選択**: 上級ユーザーは、ネットワーク対話のために接続する特定のRPCノードを選択できます。

# 手数料

> Sunriseチェーンでは、取引手数料の支払いに手数料抽象化メカニズムを利用しています。

Sunriseチェーンでは、取引手数料の支払いに**手数料抽象化**メカニズムを利用しています。

## 取引手数料の基本通貨

[「取引手数料の基本通貨」セクションへのリンク](#取引手数料の基本通貨)

Sunriseチェーンの取引手数料の基本通貨は、![USDrise](/images/USDrise.png) **USDrise** です。すべての取引手数料は、内部的にUSDriseで計算および処理されます。

USDriseの詳細については、以下のドキュメントを参照してください。

* [USDriseとは？](/learn/usdrise)

## 手数料抽象化

[「手数料抽象化」セクションへのリンク](#手数料抽象化)

手数料抽象化は、ユーザーがUSDrise以外のトークンで取引手数料を支払うことができる機能です。この機能により、ユーザーは保有しているトークンを直接手数料に使用できます。

この機能を使用してUSDrise以外のトークンを手数料トークンとして設定した場合でも、ウォレット（例：Keplr）に表示される手数料はUSDrise建てになります。取引が実行されると、選択したトークンは現在の手数料レートで自動的にUSDriseにスワップされて手数料が支払われます。

### 手数料に利用可能なトークン

[「手数料に利用可能なトークン」セクションへのリンク](#手数料に利用可能なトークン)

手数料抽象化を通じて手数料トークンとして設定できるのは、流動性プールにUSDriseとの流動性ペアを持つトークンのみです。

***

## 手数料トークンの設定方法

[「手数料トークンの設定方法」セクションへのリンク](#手数料トークンの設定方法)

アプリケーションの設定画面から、取引手数料に使用するトークンを変更できます。

1. **設定を開く**: アプリケーションヘッダーの歯車アイコンをクリックして、設定メニューを開きます。
2. **手数料トークンセクション**: 設定メニューに「手数料トークン」セクションがあります。
3. **トークンを選択**: ドロップダウンメニューから希望の手数料トークンを選択します。USDriseとスワップ可能なトークンのみが表示されます。

選択後、今後の取引では指定したトークンが手数料に使用されます。

***

## USDriseコンバーターガイド

[「USDriseコンバーターガイド」セクションへのリンク](#usdriseコンバーターガイド)

USDriseコンバーターは、対象となるユーザーが一定額のRISEをUSDriseに変換できるユーティリティです。これは、エコシステムの初期参加者向けの1回限りの機会として意図されています。

### 対象者

[「対象者」セクションへのリンク](#対象者)

USDriseコンバーターを使用するには、ウォレットアドレスが公式のホワイトリストに含まれている必要があります。このリストは、エアドロップやパブリックセールなどのイベントの参加者を含む`genesis.json`ファイルのアカウントで構成されています。

接続したウォレットアドレスがホワイトリストにある場合、アプリケーションのヘッダーに「USDriseコンバーター」ボタンが自動的に表示されます。ボタンが表示されない場合、あなたのアドレスは対象外です。

### 使用方法

[「使用方法」セクションへのリンク](#使用方法)

1. **ウォレットを接続**: ホワイトリストに登録されているアドレスを持つウォレットを接続することから始めます。

2. **コンバーターボタンを見つける**: 対象者の場合、ヘッダーメニューに「USDriseコンバーター」ボタンが表示されます。

3. **コンバーターを開く**: ボタンをクリックして変換ダイアログを開きます。

4. **確認と承認**: ダイアログには固定の変換レートが表示されます。

   * **送信**: ![RISE](/images/RISE.png) 0.625 RISE
   * **受信**: ![USDrise](/images/USDrise.png) 0.05 USDrise

5. **リクエストを送信**: 「リクエストを送信」ボタンをクリックして続行します。取引が処理され、ウォレットにUSDriseが届きます。

### 重要事項

[「重要事項」セクションへのリンク](#重要事項)

* **固定レート**: 変換額は固定されており、変更できません。
* **1回限りのアクション**: ホワイトリストに登録された各アドレスは、コンバーターを1回しか使用できません。
* **TGE価格**: この変換レートは、RISEのTGE（トークン生成イベント）価格よりも低い場合があることに注意してください。

# ガバナンス

> Sunriseのガバナンスシステムでは、vRISEまたはRISEトークンをステーキング（デリゲート）することで、ネットワークのセキュリティに貢献し、プロトコルの将来を形作ることに参加できます。

Sunriseのガバナンスシステムでは、vRISEまたはRISEトークンをステーキング（デリゲート）することで、ネットワークのセキュリティに貢献し、プロトコルの将来を形作ることに参加できます。

ガバナンスには主に2つの側面があります。

* **ガバナンス提案**: プロトコルのアップグレード、パラメータの変更、コミュニティプール資金の使用など、チェーン全体での決定。
* **ゲージ投票**: 流動性プールへのインセンティブ（vRISE排出量）の配分を決定するための投票。

注記

**重要**: ガバナンス提案とゲージ投票の両方で投票権を得るには、**vRISE**をステーキングする必要があります。RISEをステーキングしても投票権は付与されませんが、ステーキング報酬は得られます。

## ステーキング（デリゲーション）

[「ステーキング（デリゲーション）」セクションへのリンク](#ステーキングデリゲーション)

トークンをバリデーターにデリゲートすることで、ステーキング報酬を得ることができます。デリゲートの特性は、vRISEとRISEで異なります。

| 特徴           | ![vRISE](/images/vRISE.svg) vRISE | ![RISE](/images/RISE.png) RISE |
| ------------ | --------------------------------- | ------------------------------ |
| **投票権**      | あり（提案とゲージ）                        | なし                             |
| **ステーキング報酬** | あり（自動複利）                          | あり（手動請求）                       |
| **譲渡可能性**    | なし                                | あり                             |
| **再デリゲーション** | あり                                | なし                             |

### ステーキング方法

[「ステーキング方法」セクションへのリンク](#ステーキング方法)

1. ガバナンスページの「ステーク」ボタンをクリックするか、「デリゲート」ページに移動します。
2. 「vRISE」または「RISE」タブを選択します。
3. リストからデリゲートするバリデーターを選択します。
4. デリゲートしたいトークンの量を入力し、取引を承認します。

注意

ロックされたRISEをステーキングするには、このページではなく[**ロックアップ**](/learn/sunrise-app/lockup)ページから行う必要があります。詳細は「ロックアップ」ドキュメントを参照してください。

### デリゲーションの管理

[「デリゲーションの管理」セクションへのリンク](#デリゲーションの管理)

「デリゲーション」ページで、現在のデリゲートポジションを管理できます。

* **vRISE**:

  * **報酬**: 報酬は自動的にステーキングポジションに複利で追加されるため、手動での請求は不要です。
  * **再デリゲート**: アンステーキングせずに、デリゲーションを別のバリデーターに即座に切り替えます。
  * **アンデリゲート**: デリゲーションをアンステークします。トークンが利用可能になるまでには、アンボンディング期間があります。

* **RISE**:

  * **報酬の請求**: 蓄積されたステーキング報酬を手動で請求すると、ウォレットに送金されます。
  * **アンデリゲート**: デリゲーションをアンステークします。vRISEと同様に、アンボンディング期間が適用されます。

「デリゲーション」セクション内の「アンステーク保留中」ページで、アンボンディング中のデリゲーションのステータスを確認できます。

## ガバナンス提案

[「ガバナンス提案」セクションへのリンク](#ガバナンス提案)

チェーンパラメータの変更やコミュニティ資金の使用など、プロトコルの重要な決定は、ガバナンス提案を通じて行われます。

### 提案の表示と投票

[「提案の表示と投票」セクションへのリンク](#提案の表示と投票)

1. 「提案」ページで、現在および過去の提案のリストを表示できます。

2. 提案をクリックすると、詳細、現在の投票状況（賛成、反対、棄権の票の割合）、投票期間が表示されます。

3. 提案が投票期間中の場合、投票権（ステーキングしたvRISEの量に基づく）を使用して投票できます。投票オプションは次のとおりです。

   * **賛成**
   * **反対**
   * **棄権**
   * **拒否権付き反対**: 提案を覆し、デポジットをバーンすることができる強力な「反対」票。

## ゲージ投票

[「ゲージ投票」セクションへのリンク](#ゲージ投票)

ゲージ投票は、次のエポックでさまざまな流動性プールにvRISEインセンティブをどのように配分するかを決定するメカニズムです。

### ゲージ投票の仕組み

[「ゲージ投票の仕組み」セクションへのリンク](#ゲージ投票の仕組み)

* **投票権**: 投票権は、ステーキングしたvRISEの量によって決まります。
* **投票**: 「ゲージ投票」セクションの「あなたの投票」ページで、投票権をさまざまな流動性プールにパーセンテージで配分できます。合計は100%になる必要があります。
* **エポック**: 投票はエポックと呼ばれる期間で行われます。新しいエポックが始まると、各プールのvRISE報酬分配率が投票結果に基づいて決定されます。

### ブライブ

[「ブライブ」セクションへのリンク](#ブライブ)

ブライブは、ユーザーが特定のプールに投票することを奨励するために提供されるインセンティブです。

* **ブライブの提供**: ユーザーは、票を集めるために特定のプールにブライブ（例：RISE）を提供できます。これは、「ブライブ」セクションの「ブライブの登録」ページから行うことができます。
* **ブライブの獲得**: ブライブのあるプールに投票したユーザーは、そのプールに投じられた投票権に比例して、それらのブライブの一部を獲得します。「ブライブ」セクションの「請求可能」ページからブライブを請求できます。

# 流動性プール

> Sunriseの流動性プール（LP）は、分散型取引所（DEX）の中核機能であり、ユーザーはトークンを預けて流動性を提供し、その見返りとして取引手数料やvRISEトークンなどの報酬を得ることができます。

Sunriseの流動性プール（LP）は、分散型取引所（DEX）の中核機能であり、ユーザーはトークンを預けて流動性を提供し、その見返りとして取引手数料やvRISEトークンなどの報酬を得ることができます。

## プールリスト

[「プールリスト」セクションへのリンク](#プールリスト)

流動性プールページでは、利用可能なすべてのプールのリストを確認できます。

各プールには以下の情報が表示されます。

* **ペア**: プールを構成するトークンのペア。
* **ID**: プールの識別番号。
* **TVL**: プールにロックされている総価値。
* **手数料（24時間）**: 過去24時間に発生した取引手数料。
* **出来高（24時間）**: 過去24時間の取引量。
* **vRISE報酬配分**: このプールに割り当てられたvRISE報酬の額。
* **APR（手数料 + vRISE）**: 手数料とvRISE報酬を組み合わせた年換算利率。

ページ上部の「あなたのポジションを見る」ボタンから、あなたが提供しているすべての流動性ポジションを確認できます。

## プールの詳細

[「プールの詳細」セクションへのリンク](#プールの詳細)

リストから特定のプールを選択すると、その詳細ページに移動します。

* **流動性提供者の報酬**: このプールで流動性提供者が得られる報酬の詳細。

  * **手数料率**: プールでのスワップの取引手数料率。
  * **vRISE報酬APR**: vRISEトークン報酬によるAPR。この値はゲージ投票に基づいて変動します。

* **価格チャート**: トークンペアの価格変動を示すチャート。

* **統計**: TVL、24時間出来高、24時間手数料、平均APRなどの統計情報。

* **あなたの流動性**: このプールにおけるあなたの流動性ポジションのリスト。

## 流動性の管理

[「流動性の管理」セクションへのリンク](#流動性の管理)

### 流動性の追加

[「流動性の追加」セクションへのリンク](#流動性の追加)

プールの詳細ページまたはあなたのポジションページで「流動性を追加」ボタンをクリックして、流動性を追加できます。

#### 1. 価格範囲の設定

[「1. 価格範囲の設定」セクションへのリンク](#1-価格範囲の設定)

流動性を提供したい価格範囲を選択します。

* **フルレンジ**: 価格範囲をゼロから無限大に設定します。これにより、価格変動に関係なく継続的に流動性を提供できますが、資本効率は低くなります。
* **カスタム**: 特定の価格範囲を設定します。価格が設定した範囲内にある場合にのみ、流動性が提供され手数料を得られます。これは資本効率が高いですが、価格が範囲外に出ると手数料は得られません。
  * `log±X%`ボタンを使用して現在価格からのパーセンテージに基づいて範囲を素早く設定したり、スライダーで手動で範囲を調整したりできます。

#### 2. トークン量の入力

[「2. トークン量の入力」セクションへのリンク](#2-トークン量の入力)

提供したいトークンの量を入力します。一方のトークンの量を入力すると、選択した価格範囲に基づいてもう一方のトークンの量が自動的に計算されます。

注記

設定した価格範囲が現在価格より完全に上または下にある場合、一方のトークンの量は0に固定されます。

### あなたのポジションの表示

[「あなたのポジションの表示」セクションへのリンク](#あなたのポジションの表示)

「あなたのポジションを見る」ページまたは各プールの詳細ページの下部で、あなたの流動性ポジションを確認できます。

ポジションを選択すると、以下の詳細が表示されます。

* **ポジションステータス**: 現在価格が設定価格の`範囲内`か`範囲外`かを示します。
* **価格範囲**: 流動性を提供するために設定した価格範囲。
* **請求可能な報酬**: あなたのポジションによって生成された未請求の取引手数料。
* **ポジション内の資産**: 現在あなたのポジションにある資産の量。

### 流動性の増加

[「流動性の増加」セクションへのリンク](#流動性の増加)

ポジション詳細ページで「流動性を増加」を選択して、既存のポジションにさらに流動性を追加できます。

注意

**重要**: 流動性を増加させると、既存のポジションは清算され、新しいポジションが作成されます。このプロセスでは、未請求の報酬は自動的にあなたのウォレットに送られます。

### 流動性の減少

[「流動性の減少」セクションへのリンク](#流動性の減少)

ポジション詳細ページで「流動性を減少」を選択して、ポジションから一部またはすべての流動性を引き出すことができます。スライダーまたはボタンを使用して、引き出す割合（25%、50%、75%、100%）を選択できます。

### 報酬の請求

[「報酬の請求」セクションへのリンク](#報酬の請求)

ポジション詳細またはプールの詳細ページの「請求」ボタンから、蓄積された取引手数料を請求できます。複数のポジションがある場合は、すべての報酬を一度に請求することもできます。

# ロックアップ

> ロックアップ機能は、エアドロップやその他のインセンティブプログラムを通じて配布され、特定の期間ロックされているトークンを管理するためのものです。これらのトークンは、設定された期間にわたって徐々にアンロックされます。

ロックアップ機能は、エアドロップやその他のインセンティブプログラムを通じて配布され、特定の期間ロックされているトークンを管理するためのものです。これらのトークンは、設定された期間にわたって徐々にアンロックされます。

## ロックアップの概要

[「ロックアップの概要」セクションへのリンク](#ロックアップの概要)

メインの「ロックアップ」ページでは、すべてのロックアップアカウントのリストを確認できます。各アカウントには、ロックされた資産とロックアップ期間の詳細が表示されます。

リストの項目をクリックすると、そのロックアップアカウントの詳細ページに移動します。

## ロックアップアカウントの詳細

[「ロックアップアカウントの詳細」セクションへのリンク](#ロックアップアカウントの詳細)

詳細ページでは、ロックされた資産の現在の状態を包括的に確認できます。

* **元の/追加のロック**: ロックアップの元の量と追加された量。
* **ロックアップ開始/終了**: ロックアップが開始された日時と完全に終了する日時。
* **現在ロック中/アンロック済み**: 現在ロックされている資産とアンロックされた資産の内訳。
* **デリゲート済み（ロック中/アンロック済み）**: ステーキングされている資産の内訳で、ロックされた部分とアンロックされた部分の両方を表示します。

このページから、ロックアップアカウントに関連する3つの主要なアクションを実行できます。

### 1. ロックされた資産のステーキング（デリゲート）

[「1. ロックされた資産のステーキング（デリゲート）」セクションへのリンク](#1-ロックされた資産のステーキングデリゲート)

ロックされたRISEをバリデーターにデリゲートして、ステーキング報酬を得ることができます。

危険

**重要**: ロックアップアカウントを介してデリゲートすることでステーキング報酬を得ることはできますが、これによりガバナンス提案やゲージ投票での**投票権は付与されません**。

* **操作方法**: ロックアップ詳細ページで「デリゲート」を選択し、バリデーターと金額を選択して資産をデリゲートします。

### 2. デリゲーションの管理

[「2. デリゲーションの管理」セクションへのリンク](#2-デリゲーションの管理)

現在デリゲートされている資産のステータスを確認し、管理します。

* **報酬の請求**: 蓄積されたステーキング報酬を手動で請求し、ロックアップアカウントに戻します。

* **アンデリゲート**: 資産をアンステークします。

  * アンデリゲートされたトークンはすぐには利用可能にならず、**アンボンディング期間**（待機期間）に入ります。
  * 「アンステーク保留中」ページでアンボンディング中の資産のステータスを確認できます。

### 3. アンロックされた資産の引き出し

[「3. アンロックされた資産の引き出し」セクションへのリンク](#3-アンロックされた資産の引き出し)

ロックアップ期間が終了し、メインウォレットにデリゲートされていない資産を引き出すことができます。

* **引き出し条件**: **アンロック済み**かつ**デリゲートされていない**資産のみ引き出すことができます。
* **デリゲートされた資産を引き出すには**: まずアンデリゲートし、アンボンディング期間が終了するのを待つ必要があります。期間が終了すると、資産は引き出し可能になります。
* **操作方法**: ロックアップ詳細ページで「引き出し」を選択し、引き出したいアンロック済み資産の額を入力します。

# ポイントプログラム

> Sunriseエコシステムとの長期的な連携に報いる、持続可能で多層的なポイントシステムです。

Sunriseエコシステムとの長期的な連携に報いる、持続可能で多層的なポイントシステムです。

## プログラム概要

[「プログラム概要」セクションへのリンク](#プログラム概要)

Sunriseポイントプログラムは、複数の側面でユーザーに報酬を与えます。

### 毎日のアクティビティ

[「毎日のアクティビティ」セクションへのリンク](#毎日のアクティビティ)

* vRISEのステーキング
* 流動性の提供（LP）

### 継続中（特定時期まで）

[「継続中（特定時期まで）」セクションへのリンク](#継続中特定時期まで)

* 新規ユーザーの紹介

### 1回限りのアクション

[「1回限りのアクション」セクションへのリンク](#1回限りのアクション)

* EVMウォレットの接続
* X（Twitter）の接続

***

## 毎日: ![vRISE](/images/vRISE.svg) vRISEステーキング

[「毎日: vRISEステーキング」セクションへのリンク](#毎日--vriseステーキング)

24時間ごとにステーキングポイントを請求します。ポイントは現在のステーキング額に基づいて計算されます。

注記

vRISEを取得するには、流動性の提供が必要です。

**式: `1 vRISE = 100 ポイント / 日`**

注記

`Bonded`状態のバリデーターへのデリゲーションのみが対象です。デリゲートしているバリデーターがunbondedになった場合は、別の`Bonded`状態のバリデーターに再デリゲートしてポイントを獲得し続けることができます。

ダッシュボードには以下が表示されます。

* 請求可能なポイント
* 現在のステーキング額
* バリデーターごとのステーキング分布
* 残りのクールダウンタイマー

## 毎日: 流動性提供（LP）

[「毎日: 流動性提供（LP）」セクションへのリンク](#毎日-流動性提供lp)

24時間ごとにLPポイントを請求します。ポイントはアクティブなLPポジションに基づいています。

注記

RISEでのポジション作成は、RISEトークンがトークン生成イベント（TGE）を通じてローンチされた後に可能になります。

注記

LPポジションは、現在価格がポジションに設定した価格範囲内にある場合に`有効`と見なされます。無効なポジションはポイントを獲得できません。

### ポイント計算

[「ポイント計算」セクションへのリンク](#ポイント計算)

ポイントは流動性の米ドル価値に基づいて計算されます。

* **USDrise / USDN LP**: `1米ドル相当額 = 120ポイント`
* **その他のLP**: `1米ドル相当額 = 100ポイント`

ダッシュボードには以下が表示されます。

* 請求可能なLPポイント
* アクティブなLP残高
* 有効なポジションと無効なポジション
* 残りのクールダウンタイマー

***

## 紹介プログラム

[「紹介プログラム」セクションへのリンク](#紹介プログラム)

### 仕組み

[「仕組み」セクションへのリンク](#仕組み)

* 独自の紹介リンクを共有して追加ポイントを獲得します。
* 紹介者が正常に請求を行うたびに、\*\*紹介者のポイントの10%\*\*を獲得します。
* 紹介ボーナスは、各紹介者ごとに個別に計算および授与されます。

### 紹介上限

[「紹介上限」セクションへのリンク](#紹介上限)

注記

招待できるユーザー数には制限があります。この制限を超えて招待されたユーザーからはポイントを獲得できません。上限は定期的に更新されます。

***

## NFT保有者ブースト

[「NFT保有者ブースト」セクションへのリンク](#nft保有者ブースト)

注意

この機能は将来のアップデートで計画されており、まだ有効ではありません。

特定のNFTを保有すると、収益にブーストがかかります。

### NFTあり

[「NFTあり」セクションへのリンク](#nftあり)

* 毎日のポイントが乗算されます: `毎日のポイント × (1 + x%)`
* 紹介ボーナスもこのブーストを受けます。
* **例**: 1,000 vRISEのステーキングポイントと10%のブースト: `1,000 vRISE × 100 pt × 1.1 = 110,000ポイント`

### NFTなし

[「NFTなし」セクションへのリンク](#nftなし)

* 乗数なしで基本レートのポイントを獲得します。
* 紹介ボーナスは、紹介者の基本ポイントからのみ計算されます。

### 紹介ブーストのシナリオ

[「紹介ブーストのシナリオ」セクションへのリンク](#紹介ブーストのシナリオ)

**シナリオ1: あなた（紹介者）も紹介者もNFTを持っていない**

* **あなた（A）**: あなたの基本ポイント + 紹介者（B）の基本ステーキング/LPポイントの10%。
* **紹介者（B）**: 基本報酬のみ。

**シナリオ2: あなた（紹介者）のみがNFTを持っている**

* **あなた（A）**: `(あなたの基本ポイント × (1 + x%))` + 紹介者（B）の基本ステーキング/LPポイントの10%。
* **紹介者（B）**: 基本報酬のみ。

**シナリオ3: あなた（紹介者）と紹介者の両方がNFTを持っている**

* **あなた（A）**: `(あなたの基本ポイント × (1 + x%))` + `(紹介者（B）の基本ポイント × (1 + x%))の10%`。
* **紹介者（B）**: `(彼らの基本ポイント × (1 + x%))`。

***

## 1回限りのボーナス

[「1回限りのボーナス」セクションへのリンク](#1回限りのボーナス)

アカウントを接続すると、1回限りのポイントボーナスを獲得できます。

* **EVMウォレット接続**: `+500ポイント`
  * この接続はNFT保有者ブーストに必要です。
* **X（Twitter）接続**: `+100ポイント`
  * これは、今後のリツイートキャンペーンへの参加にも必要です。

***

## 請求ルール

[「請求ルール」セクションへのリンク](#請求ルール)

* すべてのポイント請求は手動であり、あなたによって開始される必要があります。
* 各カテゴリ（ステーキング、LP）には、請求後に独自の24時間のクールダウン期間があります。
* クールダウン期間中も、ステーキング、流動性の提供、紹介を続けることができます。
* ポイントは、「請求」ボタンをクリックした瞬間に計算されます。

# スワップ

> Sunriseのスワップ機能は、異なるブロックチェーン間でトークンを直接交換するための強力なツールです。IBCやその他のクロスチェーン技術を活用して、シームレスな資産交換体験を提供します。

Sunriseのスワップ機能は、異なるブロックチェーン間でトークンを直接交換するための強力なツールです。IBCやその他のクロスチェーン技術を活用して、シームレスな資産交換体験を提供します。

スワップページには、主に2つの機能があります。

* **ブロックチェーン間スワップ**: 異なるチェーン（例：Cosmos、Ethereum）間で資産を交換します。
* **vRISE**: vRISEトークンをRISEトークンに変換します。

また、過去の取引履歴を確認する機能も提供しています。

## ブロックチェーン間スワップ

[「ブロックチェーン間スワップ」セクションへのリンク](#ブロックチェーン間スワップ)

これはSunriseの標準的なスワップ機能です。サポートされているさまざまなブロックチェーン間で、希望のトークンを交換できます。

### スワップの実行方法

[「スワップの実行方法」セクションへのリンク](#スワップの実行方法)

1. **ソースとデスティネーションの選択**:

   * `From`フィールドで、スワップしたい資産とそのブロックチェーンを選択します。
   * `To`フィールドで、受け取りたい資産とそのブロックチェーンを選択します。

2. **金額の入力**:

   * `From`フィールドにスワップしたいトークンの金額を入力すると、`To`フィールドに受け取るトークンの金額が自動的に計算されて表示されます。
   * 逆に、`To`フィールドに希望の金額を入力して、必要なソース・トークンの金額を計算することもできます。（この逆計算は、EVMチェーンを含む一部のルートでは利用できない場合があります）。

3. **レートと詳細の確認**:

   * 金額を入力すると、現在の交換レートが計算されます。計算が成功すると通知されます。
   * このレートは見積もりであり、トランザクションがブロックに含まれるまでに変更される可能性があることに注意してください。

4. **スワップの確認**:

   * 詳細を確認し、「スワップ」ボタンをクリックしてトランザクションを承認します。ウォレットの接続と承認が必要です。

### 注意事項とエラー

[「注意事項とエラー」セクションへのリンク](#注意事項とエラー)

* **手数料**: スワップには手数料がかかる場合があります。Cosmosエコシステム内のチェーン間の標準的なIBC転送には、通常リレー手数料はかかりません。ただし、EthereumなどCosmos外のチェーンとのスワップでは、[Skip Protocol](https://docs.skip.build/go/general/fee-info)の「IBC Eureka」を使用するため、リレー手数料が発生します。この手数料はレート計算に自動的に含まれます。
* **計算エラー**: 「スワップレートの計算に失敗しました」というエラーが表示された場合、入力した金額が手数料をカバーするには低すぎるか、流動性プールのキャパシティに対して高すぎる可能性があります。別のルートを試すか、金額を調整してください。
* **クリア機能**: 「すべてクリア」ボタンを押すと、入力したすべての情報がリセットされます。

## 取引履歴

[「取引履歴」セクションへのリンク](#取引履歴)

右上隅の「履歴を表示」ボタンをクリックすると、サイドパネルで過去のスワップ取引履歴を表示できます。

* **表示**: ソースとデスティネーションのチェーン、資産、トランザクションハッシュ、タイムスタンプが表示されます。
* **エクスプローラー**: 各トランザクションハッシュは、詳細を確認するための対応するブロックチェーンエクスプローラーへのリンクになっています。
* **履歴のクリア**: ゴミ箱アイコンをクリックすると、ローカルに保存されている履歴を削除できます。（これによりオンチェーンの記録が消去されるわけではありません）。

## vRISEからRISEへの変換

[「vRISEからRISEへの変換」セクションへのリンク](#vriseからriseへの変換)

これは、vRISEトークンをRISEトークンに1対1で変換するための専用機能です。

* **目的**: ステーキングやその他の活動で得たvRISEを、取引可能なRISEに戻すために使用します。
* **使用方法**: 変換したいvRISEの金額を入力し、「vRISEをRISEに変換」ボタンをクリックします。
* **方向**: この変換は、vRISEからRISEへの一方向のみです。

# データ可用性

> Sunriseデータ可用性レイヤーは、高スループットのデータ可用性のために設計されており、アプリケーションに強化されたスケーラビリティと柔軟性を提供します。これを達成するために、SunriseはオフチェーンのBLOBデータを採用し、ブロックデータ全体ではなく、各Blobデータに対してErasure Codingを実行します。

Sunriseデータ可用性レイヤーは、高スループットのデータ可用性のために設計されており、アプリケーションに強化されたスケーラビリティと柔軟性を提供します。これを達成するために、SunriseはオフチェーンのBLOBデータを採用し、ブロックデータ全体ではなく、各Blobデータに対してErasure Codingを実行します。

`x/da`モジュールはこれらの機能を提供します。

## 主な特徴

[「主な特徴」セクションへのリンク](#主な特徴)

SunriseのオフチェーンDA設計は、オンチェーンのセキュリティを犠牲にすることなく、比類のないスループットとコスト効率を実現します。

1. **オフチェーンのイレージャーエンコーディング** バリデーターの計算とストレージを劇的に削減します。オンチェーンには、これらのイレージャーコーディングされたデータ共有を指すメタデータURIのみがあり、完全なデータ再構築はオフチェーンで行われます。
2. **オフチェーンストレージ統合** IPFSやArweaveなどの分散型ストレージソリューションを利用して、データシャードは外部に保存されます。MsgPublishDataには、これらのイレージャーコーディングされたデータ共有を指すメタデータURIのみが含まれ、ブロブトランザクションのオンチェーンブロックサイズ要件を削減し、スケーラビリティを向上させます。

## DAの比較

[「DAの比較」セクションへのリンク](#daの比較)

|              | Sunrise             | Avail DA              | Celestia             | EigenDA   | Ethereum (EIP-4844) |
| ------------ | ------------------- | --------------------- | -------------------- | --------- | ------------------- |
| アーキテクチャ      | オフチェーンブロブを持つL1      | L1ブロックチェーン            | L1ブロックチェーン           | DAサービス    | L1ブロックチェーン（ブロブ）     |
| スループット       | 5+ MB/s             | 0.2 MB/s (4MB/ブロック)   | 1.33 MB/s (8MB/ブロック) | 15 MB/s   | 0.064 MB/s          |
| ファイナリティまでの時間 | 約4分 (7秒+240秒)       | 40秒                   | 6秒 + 10分             | 12分       | 12分                 |
| データストレージ     | オフチェーンブロブ           | オンチェーン                | オンチェーン               | 委員会ストレージ  | オンチェーンブロブ           |
| 証明メカニズム      | オフチェーンストレージによる楽観的証明 | 有効性証明 (KZG)           | 不正証明                 | 有効性証明     | 有効性証明               |
| 長期的な検索可能性    | シームレス               | ネイティブではない             | ネイティブではない            | ネイティブではない | ネイティブではない           |
| コストモデル       | 流動性による手数料の抽象化       | 直接手数料                 | 直接手数料                | 委員会手数料    | オンチェーンガス手数料         |
| コンセンサス       | プルーフ・オブ・リクイディティ     | Babe & Grandpa (NPoS) | Tendermint           | N/A       | Ghost & Casper      |

## 設計概要

[「設計概要」セクションへのリンク](#設計概要)

### 他のDAレイヤーの設計パターン

[「他のDAレイヤーの設計パターン」セクションへのリンク](#他のdaレイヤーの設計パターン)

1. **データ可用性委員会**

   データ可用性委員会（DAC）は、低コストで代替のデータ可用性レイヤーを構築するための従来の方法です。

   しかし、DACでは、クライアントが委員会によって証明されたデータ可用性が真か偽かを、ブロブデータ全体をダウンロードせずに検証することは不可能です。

2. **データ可用性サンプリング**

   データ可用性サンプリング（DAS）を採用するデータ可用性レイヤーでは、ブロックデータはイレージャーコーディングのために処理されます。その後、クライアントはブロックデータの一部をダウンロードするだけでデータ可用性を検証でき、マークルツリー構造を使用してブロック内のブロブデータの包含を検証できます。

   一般的なDASのセットアップでは、フルノードはmempool内のトランザクションデータを転送およびダウンロードする必要があります。

   ブロブデータのサイズが大きくなるにつれて、ネットワークのスループットはこれらのトランザクション転送によって制限される可能性があり、大きなブロブデータを扱うアプリケーションにとって課題となります。

### Sunriseの設計

[「Sunriseの設計」セクションへのリンク](#sunriseの設計)

DACとDASにおけるこれらの問題に対処するために、Sunriseは次の解決策を実装しています。

1. **オフチェーンのイレージャーエンコーディング** バリデーターの負荷を軽減するために、ブロブデータはオフチェーンプログラムでイレージャーコーディングのために処理されます。

2. **ブロブデータのシャーディング** ブロックデータ全体ではなく、各ブロブがイレージャーコーディングのために処理されます。クライアントは、データ全体をダウンロードすることなく、シャードのダウンロードを繰り返すだけで各ブロブのデータ可用性を検証できます。クライアントはまた、マークルツリー構造を使用してブロック内のブロブの包含を検証できます。

3. **外部ストレージ** ブロブデータは、IPFSやArweaveなどの分散型ストレージプラットフォームに保存されます。ブロブデータをオンチェーンに含む代わりに、MsgPublishDataはイレージャーコーディングされたデータ共有を指すメタデータURIを保持します。

   ```protobuf
   message MsgPublishData {
     option (cosmos.msg.v1.signer) = "sender";
     string sender = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"];
     string metadata_uri = 2;
     uint64 parity_shard_count = 3;
     repeated bytes shard_double_hashes = 4;
     string data_source_info = 5;
   }
   ```

   データ可用性は楽観的な方法で証明されます。Sunriseネットワークに十分な無効性の異議が提出された場合、バリデーターは二重ハッシュ化されたシャードデータ（`shard_double_hashes`）を使用してゼロ知識証明（ZKP）を提出し、バリデーターがシャードデータを明らかにすることなくその存在を検証できるようにします。

### 証明のライフサイクル

[「証明のライフサイクル」セクションへのリンク](#証明のライフサイクル)

提出されたデータは、次のいずれかのステータスになります。

* **作成済み** → **異議申し立て期間** → **異議申し立て中** → **検証済み** / **拒否済み**

* **異議申し立て期間:** 提出後、データはこのステータスで一定期間維持されます。十分な無効性の異議が提出された場合、「異議申し立て中」に移行します。それ以外の場合は、「検証済み」になります。

* **異議申し立て中:** バリデーターはデータを検証し、証明を提出します。検証されたシャードが基準を満たす場合、「検証済み」になります。そうでない場合は、「拒否済み」になります。

* **検証済み:** メタデータURIがブロックに含まれ、外部から参照できます。

* **拒否済み:** データは無効と判断され、ブロックには含まれません。

```
graph TD
    A[作成済み] --> B[異議申し立て期間]
    B -->|異議なし| C[検証済み]
    B -->|異議あり| D[異議申し立て中]
    D -->|有効| C
    D -->|無効| E[拒否済み]
```

### 証明の流れ

[「証明の流れ」セクションへのリンク](#証明の流れ)

```
%%{init: {"theme": "default", "themeVariables": {
  "background": "transparent",
  "primaryColor": "#22223b",
  "primaryTextColor": "#22223b",
  "lineColor": "#22223b",
  "textColor": "#22223b",
  "actorBorder": "#22223b",
  "actorTextColor": "#22223b",
  "sequenceNumberColor": "#22223b",
  "messageTextColor": "#22223b",
  "signalColor": "#22223b"
}}}%%
sequenceDiagram
    autonumber
    User->>Publisher Node: ブロブデータ
    Publisher Node->>Publisher Node: イレージャーコーディング
    Publisher Node->>Decentralized Storage: データシャードをアップロード
    Publisher Node->>Sunrise: MsgPublishData
    User->>Sunrise: 必要に応じて不正チャレンジ
    Sunrise->>Validator Set: 異議申し立ての投票を開始
    Validator Set->>Sunrise: ゼロ知識有効性証明
```

## ゼロ知識証明システム

[「ゼロ知識証明システム」セクションへのリンク](#ゼロ知識証明システム)

### 用語と表記

[「用語と表記」セクションへのリンク](#用語と表記)

* ハッシュ関数: H
* バリデーターのセット: V
* データシャードのセット: Sd​
* パリティシャードのセット: Sp​
* シャードのセット: S

S=Sd​∪Sp​

### 概要

[「概要」セクションへのリンク](#概要)

このシステムは、H(si​)を公開せずにデータシャードハッシュH(si​)の所有を検証します。 この回路は、1つのシャードs∈S用です。

1. 公開入力

   H\_public2(s)

2. プライベート入力

   H\_private(s)

3. 回路制約

   Hpublic2​(s)=H(Hprivate​(s))

## データ可用性の条件

[「データ可用性の条件」セクションへのリンク](#データ可用性の条件)

### 表記

[「表記」セクションへのリンク](#表記)

* レプリケーション係数（データシャードのみに基づく）: r
* レプリケーション係数（パリティシャードを含む場合に基づく）: rp​

rp​=r∣Sd​∣+∣Sp​∣∣Sd​∣​

* 各バリデーターが関与するシャードの数: n

n=ceil(rp​∣V∣∣Sd​∣+∣Sp​∣​)=ceil(r∣V∣∣Sd​∣​)

### 各シャードがデータ可用性を証明するための要件

[「各シャードがデータ可用性を証明するための要件」セクションへのリンク](#各シャードがデータ可用性を証明するための要件)

* このシャードに関与するバリデーターからのシャード`s`の有効な証明のセット: Zs​

rp​∣Zs​∣​≥32​

* この条件を満たすシャードのセット: Savailable

### データ可用性を証明するための集計の要件

[「データ可用性を証明するための集計の要件」セクションへのリンク](#データ可用性を証明するための集計の要件)

∣S∣∣Savailable∣​⇒∣Savailable∣​≥∣Sd​∣+∣Sp​∣∣Sd​∣​≥∣Sd​∣​

#### パラメータの例

[「パラメータの例」セクションへのリンク](#パラメータの例)

* 10人のバリデーター: v1​,...,v10​

* 20個のシャード: s1​,...,s20​

  * 10個のデータシャード
  * 10個のパリティシャード

* r=6

* rp​=6×10+1010​=3

* 各バリデーターは6つのシャード証明を提出します
  * 3×1020​=6

#### ケースA：有効なシャード`s_1`

[「ケースA：有効なシャードs\_1」セクションへのリンク](#ケースa有効なシャードs_1)

* バリデーターv1​, v3​およびv9​の証明には、シャードs1​と他の5つのシャードが含まれます

* バリデーターv3​は、証明にシャードs1​の有効性を含めることに失敗しました

* しかし、バリデーターv1​とv9​は証明にシャードs1​の有効性を含めることに成功したため、

  * ∣Z\_s1​∣=2
  * rp​∣Z\_s1​∣​≥32​を満たします

#### ケースB：無効なシャード`s_2`

[「ケースB：無効なシャードs\_2」セクションへのリンク](#ケースb無効なシャードs_2)

* バリデーターv2​, v4​およびv10​の証明には、シャードs2​と他の5つのシャードが含まれます

* バリデーターv2​とv4​は、証明にシャードs2​の有効性を含めることに失敗しました

* バリデーターv10​のみが証明にシャードs2​の有効性を含めることに成功したため、

  * ∣Z\_s2​∣=1
  * rp​∣Z\_s2​∣​≥32​を満たしません

#### ケースX：シャードs\_1、s\_3-s\_11は上記の条件で有効です

[「ケースX：シャードs\_1、s\_3-s\_11は上記の条件で有効です」セクションへのリンク](#ケースxシャードs_1s_3-s_11は上記の条件で有効です)

* ∣Savailable∣=10
* ∣Sd​∣=10
* ∣Savailable∣≥∣Sd​∣を満たします

#### ケースY：上記の条件で有効なのはシャードs\_1、s\_3のみです

[「ケースY：上記の条件で有効なのはシャードs\_1、s\_3のみです」セクションへのリンク](#ケースy上記の条件で有効なのはシャードs_1s_3のみです)

* ∣Savailable∣=2
* ∣Sd​∣=10
* ∣Savailable∣≥∣Sd​∣を満たしません

## パラメータ

[「パラメータ」セクションへのリンク](#パラメータ)

| パラメータ                   | デフォルト     | 単位   | 説明                            |
| ----------------------- | --------- | ---- | ----------------------------- |
| publish\_data\_gas      | 1,000,000 | gas  | データ公開のガス代                     |
| challenge\_threshold    | 0.33      | 比率   | チャレンジ期間に入るために必要な無効性チャレンジのしきい値 |
| replication\_factor     | 5.0       | コピー  | データシャードのレプリカ数                 |
| slash\_epoch            | 120,960   | ブロック | スラッシュ判断のエポック期間（約1週間）          |
| slash\_fault\_threshold | 0.5       | 比率   | バリデーターのスラッシュを引き起こす無効な証明のしきい値  |
| slash\_fraction         | 0.001     | 比率   | スラッシュ中の投票力の削減率                |
| challenge\_period       | 4分        | 時間   | データ公開後のチャレンジ期間                |
| proof\_period           | 10分       | 時間   | チャレンジ後の証明提出期間                 |

## メッセージ

[「メッセージ」セクションへのリンク](#メッセージ)

このモジュールは、さまざまなメッセージタイプを提供します。

* MsgUpdateParams：モジュールパラメータの更新（ガバナンス操作）
* MsgPublishData：メタデータURIとシャード情報を含むデータを公開
* MsgSubmitInvalidity：特定のインデックスのデータの無効性を報告
* MsgSubmitValidityProof：バリデーターから有効性証明を提出
* MsgRegisterProofDeputy：バリデーターの証明代理人を登録
* MsgUnregisterProofDeputy：証明代理人の登録を解除

## クエリ

[「クエリ」セクションへのリンク](#クエリ)

このモジュールは、さまざまなクエリエンドポイントを提供します。

* Params：モジュールパラメータのクエリ
* PublishedData：特定のメタデータURIの公開データの詳細を取得
* AllPublishedData：すべての公開データを一覧表示
* ValidityProof：特定のバリデーターから有効性証明を取得
* AllValidityProofs：特定のメタデータURIのすべての有効性証明を一覧表示
* Invalidity：特定のメタデータURIと送信者の無効性レポートを取得
* AllInvalidity：特定のメタデータURIのすべての無効性レポートを一覧表示
* ValidatorShardIndices：特定のバリデーターのシャードインデックスを取得
* ZkpProofThreshold：特定のシャード数のZKP証明のしきい値を取得
* ProofDeputy：特定のバリデーターの証明代理人を取得

詳細については、[Github](https://github.com/sunriselayer/sunrise/tree/main/x/da)を参照してください。

# 手数料

> x/feeモジュールは、Sunriseブロックチェーンのコアコンポーネントであり、取引手数料の管理を担当します。指定されたステーブルコイン（fee_denom）で手数料を徴収し、これらの手数料の一部をRISE（burned_denom）にスワップして焼却します。このモジュールは、RISEのデフレ型トークノミクスをサポートしつつ、ユーザーに安定した手数料...

`x/fee`モジュールは、Sunriseブロックチェーンのコアコンポーネントであり、取引手数料の管理を担当します。指定されたステーブルコイン（`fee_denom`）で手数料を徴収し、これらの手数料の一部をRISE（`burned_denom`）にスワップして焼却します。このモジュールは、RISEのデフレ型トークノミクスをサポートしつつ、ユーザーに安定した手数料体系を維持します。

## `x/fee`の主な特徴

[「x/feeの主な特徴」セクションへのリンク](#xfeeの主な特徴)

1. **焼却メカニズム:**

   * 徴収された手数料（`fee_denom`）の一部は、RISE（`burned_denom`）にスワップされて焼却され、循環供給量を削減します。
   * 焼却率は`burn_ratio`パラメータによって決定されます（デフォルト：50%）。
   * スワップと焼却の操作はアトミックであり、オンチェーンで検証されます。

2. **手数料のデノミネーション（`fee_denom`）:**

   * 取引手数料に必要なデノミネーションを指定します（デフォルト：**`"uusdrise"`**）。
   * バイパスされない限り、取引はこのデノミネーションで手数料を支払う必要があります。
   * 手数料のデノミネーションの厳密な検証が強制されます。

3. **動的なパラメータ設定:**

   * 開発者は、モジュールによって強制される検証付きで、パラメータを動的に設定できます。
   * パラメータは、ガバナンス提案を通じて更新できます。

## コア機能

[「コア機能」セクションへのリンク](#コア機能)

### 手数料の徴収と処理

[「手数料の徴収と処理」セクションへのリンク](#手数料の徴収と処理)

**手数料徴収プロセス:**

1. 手数料は、`FeeCollector`モジュールアカウントを通じて`fee_denom`で徴収されます。

2. システムは以下を検証します：

   * トランザクションごとに1つの手数料デノミネーションのみ。
   * 手数料デノミネーションが、設定された`fee_denom`と一致すること。
   * 手数料額が有効で、ゼロでないこと。

**手数料処理フロー:**

1. `burn_ratio`によって決定される、徴収された手数料の一部が焼却用に指定されます。
2. この部分は、`x/swap`モジュールを介して`fee_denom`から`burned_denom`にスワップされます。
3. 結果として得られた`burned_denom`トークンは、供給から焼却されます。
4. 残りの`fee_denom`（焼却用に指定されなかった部分）は、他のプロトコル用途のために`FeeCollector`アカウントに残ります。

## パラメータ設定

[「パラメータ設定」セクションへのリンク](#パラメータ設定)

> **注意:** 次のセクションでは、経験豊富なユーザーまたは開発者向けの高度なトピックについて説明します。

| パラメータ          | 説明                   | デフォルト値       | 制約                    |
| -------------- | -------------------- | ------------ | --------------------- |
| `fee_denom`    | 取引手数料に必要なデノミネーション    | `"uusdrise"` | 有効なデノミネーションである必要があります |
| `burned_denom` | 手数料決済時に焼却されるデノミネーション | `"urise"`    | 有効なデノミネーションである必要があります |
| `burn_ratio`   | 焼却する手数料の割合           | `0.5`        | 0から1の間である必要があります      |

## ワークフロー：手数料処理

[「ワークフロー：手数料処理」セクションへのリンク](#ワークフロー手数料処理)

> **注意:** 次のセクションでは、経験豊富なユーザーまたは開発者向けの高度なトピックについて説明します。

```
sequenceDiagram
    participant User as ユーザー
    participant FeeModule as x/fee モジュール
    participant BankKeeper as Bank Keeper
    participant SwapModule as x/swap モジュール
    participant FeeCollector as 手数料徴収者
    participant BribeModule as x/bribe モジュール

    User->>FeeModule: トランザクションを送信
    FeeModule->>BankKeeper: 手数料のデノミネーションを検証
    BankKeeper->>FeeCollector: 手数料を送金（fee_denomで）

    note over FeeModule, SwapModule: 手数料処理
    FeeModule->>FeeModule: スワップ＆焼却する量を計算
    FeeModule->>SwapModule: fee_denomをburned_denomにスワップ
    SwapModule-->>FeeModule: burned_denomを返す
    FeeModule->>BankKeeper: 焼却を実行（burned_denom）

    note over BribeModule, FeeCollector: 未請求のブライブの処理
    BribeModule->>FeeModule: 未請求のブライブを処理
    FeeModule->>FeeCollector: 未請求額を送金
```

詳細および実装の詳細については、[GitHubリポジトリ](https://github.com/sunriselayer/sunrise/tree/main/x/fee)を参照してください。

# 流動性インセンティブ

> x/liquidityincentiveモジュールは、流動性プールへの貢献に基づいて報酬を分配することにより、流動性プロバイダーにインセンティブを与えます。エポックベースの報酬システムとゲージ投票メカニズムを使用して、報酬を動的に割り当てます。このモジュールは、持続可能な流動性供給を保証すると同時に、ユーザーがゲージ投票を通じてガバナンスに参加できるよ...

`x/liquidityincentive`モジュールは、流動性プールへの貢献に基づいて報酬を分配することにより、流動性プロバイダーにインセンティブを与えます。エポックベースの報酬システムとゲージ投票メカニズムを使用して、報酬を動的に割り当てます。このモジュールは、持続可能な流動性供給を保証すると同時に、ユーザーがゲージ投票を通じてガバナンスに参加できるようにします。

ブライブ機能の詳細については、[ブライブ](/learn/sunrise/liquidity-incentive/bribes)を参照してください。

## 主な特徴

[「主な特徴」セクションへのリンク](#主な特徴)

1. **エポックベースの報酬分配**:

   * 報酬は各エポックの終わりに分配されます。
   * 遅延会計は、請求時にのみ報酬を計算することで、計算オーバーヘッドを最小限に抑えます。

2. **ゲージ投票**:

   * ユーザーは、どの流動性プールがインセンティブを受け取るべきかについて投票できます。
   * 投票力は\*\*`vRISE`\*\*トークン（譲渡不可能なステーキングトークン）によって決定されます。

3. **報酬のための遅延会計**:

   * 報酬はアキュムレータを使用して追跡され、ユーザーが請求したときにのみ分配されます。
   * これにより、ネットワークの計算負荷が軽減されます。

4. **動的なインセンティブ配分**:
   * インセンティブは、投票によって決定されたプールの重み（ゲージ）に基づいて割り当てられます。

## **コアコンセプト**

[「コアコンセプト」セクションへのリンク](#コアコンセプト)

### エポック

[「エポック」セクションへのリンク](#エポック)

> **注:** 以下のセクションでは、経験豊富なユーザーまたは開発者向けの高度なトピックについて説明します。

* 2つのエポックが同時に存在します。

  1. **過去のエポック**: 終了したエポック。
  2. **現在のエポック**: 進行中のエポック。

* 各エポックには、以下のパラメータがあります。

  * **`id`**: 一意のエポックID。
  * **`start_block`**: エポックが開始されるブロック。
  * **`start_time`**: エポックが開始されるUnix時間。
  * **`end_block`**: エポックが終了するブロック。
  * **`gauges`**: インセンティブ分配のためのゲージ（プールの重み）のリスト。

### ゲージ

[「ゲージ」セクションへのリンク](#ゲージ)

> **注:** 以下のセクションでは、経験豊富なユーザーまたは開発者向けの高度なトピックについて説明します。

* ゲージは、報酬配分における特定の流動性プールの重みを表します。

* パラメータ:

  * **`pool_id`**: 流動性プールのID。
  * **`voting_power`**: このプールに割り当てられた投票力。

### 遅延会計

[「遅延会計」セクションへのリンク](#遅延会計)

* 報酬はすぐに分配されるのではなく、請求時に計算されます。
* 報酬の計算式:

ClaimAmountij​=PoolUnclaimedAccumulationi​PositionUnclaimedAccumulationij​​×PoolUnclaimedi​

## ワークフロー

[「ワークフロー」セクションへのリンク](#ワークフロー)

```
graph TD
    A{ユーザーA}-->|流動性を提供|B((プールB))
    A-->|ブライブを登録|C((プールBのゲージ))
    D{ユーザー}-->|投票|C
    C-.->|ブライブを分配|D
    C-.->|より多くのvRISEを割り当て|B
    B-.->|vRISEインセンティブを分配|A
```

### BeginBlocker

[「BeginBlocker」セクションへのリンク](#beginblocker)

1. インフレ報酬の一部をFee Collectorアカウントから\*\*`x/liquidityincentive`\*\*モジュールアカウントに転送します。
2. 報酬は\*\*`vRISE`\*\*トークン（譲渡不可能なステーキングトークン）に変換されます。
3. 報酬は各プールの手数料アキュムレータに蓄積されます。

### MsgClaimRewards (`x/liquiditypool`)

[「MsgClaimRewards (x/liquiditypool)」セクションへのリンク](#msgclaimrewards-xliquiditypool)

* ユーザーは、流動性プール内の自分のポジションと対話することで報酬を請求します。

> **注:** ここで説明する報酬は、特に**あなたのvRISE投票力に応じて割り当てられるゲージ投票報酬**です。 これらは、標準のLP報酬とは異なります。 ゲージ投票報酬は、あなたのvRISEでゲージ投票に参加することで請求します。これにより、エポックごとの各プールの報酬のあなたの分け前が決定されます。

## シーケンス図：報酬分配

[「シーケンス図：報酬分配」セクションへのリンク](#シーケンス図報酬分配)

> **注:** 以下のセクションでは、経験豊富なユーザーまたは開発者向けの高度なトピックについて説明します。

```
sequenceDiagram
    participant User as 流動性プロバイダー
    participant LiquidityPool as x/liquiditypool モジュール
    participant IncentiveModule as x/liquidityincentive モジュール
    participant Distribution as x/distribution モジュール

    User->>LiquidityPool: 流動性を提供
    LiquidityPool->>IncentiveModule: ポジションの蓄積を追跡
    IncentiveModule->>Distribution: インフレ報酬を転送
    User->>IncentiveModule: 報酬を請求
    IncentiveModule->>User: 報酬を計算して分配
```

## パラメータ

[「パラメータ」セクションへのリンク](#パラメータ)

| パラメータ                  | デフォルト | 単位   | 説明                          |
| ---------------------- | ----- | ---- | --------------------------- |
| epoch\_blocks          | 4,320 | ブロック | エポックあたりのブロック数（約12日）         |
| staking\_reward\_ratio | 0.50  | 比率   | ステーキングに割り当てられるvRISEの比率（50%） |
| bribe\_claim\_epochs   | 5     | エポック | ブライブを請求できるエポック数             |

### パラメータの詳細

[「パラメータの詳細」セクションへのリンク](#パラメータの詳細)

1. **epoch\_blocks**

   * 各エポックの長さをブロック単位で定義します
   * デフォルト値は約12日です（`DefaultParams().BlocksPerYear/365*12`）
   * エポックの開始と終了を制御し、報酬分配のタイミングを決定します

2. **staking\_reward\_ratio**

   * 新たにミントされたvRISEトークンのうち、ステーキング報酬に割り当てられる比率
   * デフォルト値は50%です（`math.LegacyNewDecWithPrec(50, 2)`）
   * 残りの50%は流動性インセンティブに使用されます

3. **bribe\_claim\_epochs**

   * ブライブを請求できる期間をエポック単位で定義します
   * デフォルト値は5エポックです
   * この期間が終了すると、ブライブは請求できなくなります

これらのパラメータは、ガバナンスを通じて更新できます。パラメータの変更はシステムの動作に大きな影響を与える可能性があるため、慎重に検討する必要があります。

## メッセージ

[「メッセージ」セクションへのリンク](#メッセージ)

このモジュールは、さまざまなメッセージタイプを提供します。

* MsgUpdateParams: モジュールパラメータの更新（ガバナンス操作）
* MsgStartNewEpoch: 新しいエポックを開始
* MsgVoteGauge: 報酬分配のためのプールの重みに投票
* MsgRegisterBribe: 特定のプールとエポックのブライブを登録
* MsgClaimBribes: 蓄積されたブライブを請求

## クエリ

[「クエリ」セクションへのリンク](#クエリ)

このモジュールは、さまざまなクエリエンドポイントを提供します。

* Params: モジュールパラメータのクエリ
* Epoch: 特定のエポックの詳細を取得
* Epochs: すべてのエポックを一覧表示
* Vote: 特定のアドレスの投票情報を取得
* Votes: すべての投票を一覧表示
* Bribe: 特定のブライブの詳細を取得
* Bribes: オプションのフィルター付きですべてのブライブを一覧表示
* BribeAllocation: 特定のアドレス、エポック、プールのブライブ配分を取得
* BribeAllocations: オプションのフィルター付きですべてのブライブ配分を一覧表示
* TallyResult: 次のエポックの集計結果を取得

詳細については、[Github](https://github.com/sunriselayer/sunrise/tree/main/x/liquidityincentive)を参照してください。

# ブライブ

> x/liquidityincentive モジュールは、特定プールへの投票を誘導した vRISE 保有者にアプリケーションが報酬を出せるプロトコルレベルの仕組みを実装しています。

`x/liquidityincentive` モジュールは、特定プールへの投票を誘導した vRISE 保有者にアプリケーションが報酬を出せるプロトコルレベルの仕組みを実装しています。ブライブに基づくインセンティブにより、流動性配分の効率的な市場が生まれます。

## 主な特徴

[「主な特徴」セクションへのリンク](#主な特徴)

1. **プロトコルレベルのブライブ:**

   * アプリケーションは、特定プールへ流動性を集めるためにブライブを出せます
   * vRISE 保有者は、より高いブライブがあるプールへ投票する動機を持ちます
   * 流動性配分の効率的な市場が生まれます

2. **エポックベースのシステム:**

   * ブライブは特定のエポックに紐づきます
   * 期限切れエポックを追跡します
   * 期限切れエポックの未請求ブライブは処理され、手数料コレクターへ送られます

3. **ウェイトに基づく分配:**

   * 投票ウェイトに基づく公平な割り当て
   * 二重請求を防止します
   * オンチェーンで透明かつ検証可能です

4. **経済的な効率:**

   * 流動性配分の市場を作ります
   * vRISE 保有者は投票先を選ぶことでリターンを最大化できます
   * 未請求の報酬は手数料コレクターへリサイクルされます

## コア機能

[「コア機能」セクションへのリンク](#コア機能)

> **注記:** 以降の節は、経験豊富なユーザーまたは開発者向けの高度な内容です。

### ブライブの管理

[「ブライブの管理」セクションへのリンク](#ブライブの管理)

**各ブライブは次のパラメータで定義されます。**

* `id`: ブライブの一意な識別子
* `epoch_id`: ブライブが有効なエポック
* `pool_id`: ブライブの対象プール
* `address`: 送信者のアドレス
* `amount`: ブライブの総額
* `claimed_amount`: 投票者によってすでに請求された額

### ブライブの割り当て

[「ブライブの割り当て」セクションへのリンク](#ブライブの割り当て)

システムは、ブライブが投票者へどう割り当てられるかを追跡します。

* `address`: 投票者のアドレス
* `epoch_id`: 割り当てが有効なエポック
* `pool_id`: 割り当ての対象プール
* `weight`: 投票者の投票ウェイト
* `claimed_bribe_ids`: すでに請求済みのブライブ ID のリスト

***

## ブライブシステムのアーキテクチャとフロー

[「ブライブシステムのアーキテクチャとフロー」セクションへのリンク](#ブライブシステムのアーキテクチャとフロー)

### 主要コンポーネントとフロー

[「主要コンポーネントとフロー」セクションへのリンク](#主要コンポーネントとフロー)

#### ブライブの登録

[「ブライブの登録」セクションへのリンク](#ブライブの登録)

* **ユーザーがブライブを登録する**とき、Liquidity Incentive モジュールの Bribe Account へコインを送ります。
* システムは **Bribe レコードを作成します**（一意な ID、エポック、プール、金額、請求済み金額）。
* エポック開始時に、そのエポックで対象プールに投じられた投票ウェイトに基づき、投票者向けの **ブライブ割り当て** が作られます。

#### ブライブの請求

[「ブライブの請求」セクションへのリンク](#ブライブの請求)

* **ユーザーが** 自分のブライブ割り当てに対して請求を開始します。

* システムは次を行います。

  * ブライブが存在し、そのエポック／プールで有効かを検証します。
  * ユーザーの割り当てを確認し、未請求であることを確かめます。
  * ユーザーの投票ウェイトに基づいて請求可能額を計算します。
  * Bribe Account からユーザーへ該当額を転送します。
  * 請求済み金額と割り当てレコードを更新します。

#### 手数料処理

[「手数料処理」セクションへのリンク](#手数料処理)

* 期限切れエポックの未請求ブライブは **手数料コレクターへ戻されます**。

* 手数料は次のように処理されます。

  * 手数料コレクターからモジュールアカウントへ転送されます。
  * 必要ならボンドデノムへ変換されます。
  * インセンティブとして流動性プールへ分配されます。

#### クリーンアップ（未請求ブライブ）

[「クリーンアップ（未請求ブライブ）」セクションへのリンク](#クリーンアップ未請求ブライブ)

* 各エポックの終了時に、システムは次を行います。

  * 期限切れエポックを処理します。
  * 未請求のブライブ額を計算します。
  * 未請求資金を手数料コレクターへ戻します。
  * 期限切れのブライブと割り当てレコードを削除します。

#### 状態遷移

[「状態遷移」セクションへのリンク](#状態遷移)

* **ブライブ:** 作成 → 有効 → 請求済み／期限切れ
* **割り当て:** 作成 → 有効 → 請求済み／期限切れ
* **資金:** ユーザー → Bribe Account → ユーザー／手数料コレクター

***

### ブライブシステムのフローチャート

[「ブライブシステムのフローチャート」セクションへのリンク](#ブライブシステムのフローチャート)

```
flowchart TD
    User[ユーザー] -->|ブライブを登録| BribeAccount[Bribe Account]
    BribeAccount -->|割り当て| Allocation[ブライブ割り当て]
    User -->|請求| Allocation
    Allocation -->|転送| UserAccount[ユーザーアカウント]
    Allocation -->|未請求| FeeCollector[手数料コレクター]
```

**フローの説明:**

1. ユーザーがブライブを登録し、Bribe Account に入金されます。
2. システムは、投票ウェイトに基づいて適格な投票者へブライブ持分を割り当てます。
3. ユーザーはブライブ割り当てから報酬を請求できます。
4. 請求された報酬はユーザーのアカウントへ転送されます。
5. 請求期間後に残った未請求ブライブは、再分配またはバーンのため手数料コレクターへ送られます。

***

## 連携ポイント

[「連携ポイント」セクションへのリンク](#連携ポイント)

ブライブの仕組みは、次のモジュールと連携します。

* コイン転送のための Bank モジュール
* アドレス処理のための Account モジュール
* vRISE 保有者のための Staking モジュール
* パラメータ更新のための Governance モジュール

システムの詳細は [流動性インセンティブ](/learn/sunrise/liquidity-incentive) を参照してください。

# ゲージ投票

> Sunrise エコシステムにおけるゲージは、vRISE トークンの発行を制御する仕組みです。現在の主要なゲージプロダクトは流動性プールシステムです。

## ゲージとは

[「ゲージとは」セクションへのリンク](#ゲージとは)

Sunrise エコシステムにおけるゲージは、`vRISE` トークンの発行を制御する仕組みです。現在の主要なゲージプロダクトは流動性プールシステムです。

`vRISE` 保有者は、新たにミントされる `vRISE` トークンをどのゲージに割り当てるかを投票で決められます。より多くの投票力を集めた流動性プールほど、新規発行される vRISE の取り分が大きくなり、コミュニティの選好に沿ったインセンティブが生まれます。

## 投票システムの仕組み

[「投票システムの仕組み」セクションへのリンク](#投票システムの仕組み)

> **注記:** 以降の節は、経験豊富なユーザーまたは開発者向けの高度な内容です。

### エポックベースの投票

[「エポックベースの投票」セクションへのリンク](#エポックベースの投票)

ゲージのウェイト投票はエポック制で動作します。

* 各エポックは、あらかじめ決めたブロック数にまたがります（ガバナンスで変更可能）
* 投票の集計は、新しいエポックの開始時に行われます
* 投票ウェイトは、エポック開始時点の投票力で決まります
* 新しいエポックが始まると、投票はクリアされます

```
sequenceDiagram
  participant Voter as vRISE保有者
  participant Module as Liquidityincentiveモジュール
  participant Gauges as 流動性プールのゲージ

  Voter->>Module: 投票を送信（ゲージごとの割当％）
  Note over Module: 投票内容を保存

  Module->>Module: エポック開始
  Module->>Module: 投票を集計

  Module->>Gauges: 投票ウェイトに応じて vRISE を分配
  Gauges->>Voter: LP ポジションに基づく報酬を返す
```

> **注記:**\
> ここで扱う報酬は、**vRISE の投票力に応じて割り当てられるゲージ投票報酬**です。\
> 通常の LP 報酬とは別物です。\
> 報酬はユーザーのポジションに蓄積され、通常の LP 報酬と同じタイミングで `MsgClaimRewards`（`x/liquiditypool`）から請求できます。

### 参加条件

[「参加条件」セクションへのリンク](#参加条件)

ゲージ投票に参加するには、次が必要です。

* **トークン要件**: 主にプールへ流動性を提供することで `vRISE` を獲得する必要があります
* **投票力**: バリデーターへのデリゲーションで投票力を得られます
* **集計タイミング:** エポック開始時点の投票力が適用されます

投票力を持つ前でも投票は送信できます。次のエポック開始時に、その時点で持っている投票力に基づいて投票内容が適用されます。

## 投票方法

[「投票方法」セクションへのリンク](#投票方法)

### ステップ 1: 投票ダッシュボードを開く

[「ステップ 1: 投票ダッシュボードを開く」セクションへのリンク](#ステップ-1-投票ダッシュボードを開く)

**My Votes** をクリックして投票を開始します。

### ステップ 2: ゲージを選ぶ

[「ステップ 2: ゲージを選ぶ」セクションへのリンク](#ステップ-2-ゲージを選ぶ)

1. 「Select Pool」をクリックしてプール選択画面を開きます
2. 支援したいプール／ゲージを選びます
3. 以前の投票内容がある場合は自動的に読み込まれます
4. 不要なゲージは削除ボタンで外せます

### ステップ 3: 投票力を割り当てる

[「ステップ 3: 投票力を割り当てる」セクションへのリンク](#ステップ-3-投票力を割り当てる)

選んだ各ゲージに、投票力の何パーセントを割り当てるかを指定します。

* **パーセント指定:** 絶対量ではなくパーセントで指定します。理由は次のとおりです。

  * エポックのあいだに vRISE 残高が変動する可能性がある
  * パーセント指定なら、エポック開始時の残高に自動で追従する
  * 毎エポック投票し直す必要がなくなる

### ステップ 4: プレビューして送信する

[「ステップ 4: プレビューして送信する」セクションへのリンク](#ステップ-4-プレビューして送信する)

1. 「Preview Vote」で、現在の vRISE 残高がどう分配されるかを確認します
2. 選択内容を確認します
3. Vote をクリックしてトランザクションを送信します
4. 投票内容は変更するまで、以降のすべてのエポックに適用されます

### ステップ 5: 更新する（任意）

[「ステップ 5: 更新する（任意）」セクションへのリンク](#ステップ-5-更新する任意)

投票はいつでも変更できます。

* エポック開始前の最新の投票が適用されます
* 変更は次のエポック境界で有効になります
* 投票手順を繰り返すだけで内容を更新できます

システムの詳細は [流動性インセンティブ](/learn/sunrise/liquidity-incentive) を参照してください。

# 流動性プール

> x/liquiditypoolモジュールは、Sunriseブロックチェーンに集中流動性自動マーケットメーカー（AMM）メカニズムを実装します。このモジュールにより、ユーザーは流動性プールを作成し、特定の価格範囲でポジションを追加し、取引手数料やインセンティブから報酬を得ることができます。

`x/liquiditypool`モジュールは、Sunriseブロックチェーンに集中流動性自動マーケットメーカー（AMM）メカニズムを実装します。このモジュールにより、ユーザーは流動性プールを作成し、特定の価格範囲でポジションを追加し、取引手数料やインセンティブから報酬を得ることができます。

## 主な特徴

[「主な特徴」セクションへのリンク](#主な特徴)

1. **集中流動性AMM:**

   * Uniswap V3と同様のモデルに従い、流動性プロバイダーは特定の価格範囲内に資産を集中させることができます。
   * 従来の定数積AMMと比較して、資本効率が向上します。

2. **ポジションベースの流動性:**

   * ユーザーは、定義された価格範囲（ティック）でポジションを作成します。
   * 各ポジションには一意のIDがあり、流動性プロバイダーの貢献を追跡します。

3. **手数料の生成:**

   * ポジションは、その価格範囲内で発生した取引から手数料を得ます。
   * 手数料は、プールのベースデノミネーションとクォートデノミネーションで徴収されます。

4. **`vRISE`インセンティブ:**

   * 流動性プロバイダーは、追加のインセンティブとしてvRISEトークンを獲得します。
   * 詳細については、[流動性インセンティブ](/learn/sunrise/liquidity-incentive)を参照してください。

## コア機能

[「コア機能」セクションへのリンク](#コア機能)

> **注意:** 次のセクションでは、経験豊富なユーザーまたは開発者向けの高度なトピックについて説明します。

### プール管理

[「プール管理」セクションへのリンク](#プール管理)

**各プールは、いくつかのパラメータによって定義されます:**

* `id`: プールの一意の識別子
* `denom_base` & `denom_quote`: トークンペアのデノミネーション
* `fee_rate`: プール内のスワップで請求される手数料
* `tick_params`: ティックシステムを定義するパラメータ
* `current_tick`, `current_tick_liquidity`, `current_sqrt_price`: 現在の状態変数

### ティックシステム

[「ティックシステム」セクションへのリンク](#ティックシステム)

ティックシステムは、価格比率の式に基づいています。

price(tick)=price\_ratiotick−base\_offset

一般的なケース（`price_ratio = 1.0001`、`base_offset = 0`）では：

price(tick)=1.0001tick

これにより、特定の価格範囲内に流動性を正確に配置できます。

## ワークフロー：ポジションの作成と使用

[「ワークフロー：ポジションの作成と使用」セクションへのリンク](#ワークフローポジションの作成と使用)

> **注意:** 次のセクションでは、経験豊富なユーザーまたは開発者向けの高度なトピックについて説明します。

```
sequenceDiagram
    participant User as ユーザー
    participant LiquidityPool as x/liquiditypool モジュール
    participant SwapModule as x/swap モジュール

    User->>LiquidityPool: MsgCreatePosition
    LiquidityPool->>User: ポジションIDを返す

    User->>LiquidityPool: MsgIncreaseLiquidity
    LiquidityPool->>User: 新しいポジションIDを返す

    User->>LiquidityPool: MsgDecreaseLiquidity
    LiquidityPool->>User: トークンを返す

    User->>SwapModule: スワップを実行（x/swap経由）
    SwapModule->>LiquidityPool: プールの流動性を使用
    LiquidityPool->>LiquidityPool: ポジションの手数料を徴収
    LiquidityPool->>User: スワップされた金額を送信

    User->>LiquidityPool: MsgClaimRewards
    LiquidityPool->>User: 獲得した手数料とvRISEインセンティブを送金
```

## メッセージ

[「メッセージ」セクションへのリンク](#メッセージ)

このモジュールは、さまざまなメッセージタイプを提供します。

* MsgUpdateParams：モジュールパラメータの更新（ガバナンス操作）
* MsgCreatePool：指定されたパラメータで新しい流動性プールを作成
* MsgCreatePosition：プール内の価格範囲内にポジションを作成
* MsgIncreaseLiquidity：既存のポジションに流動性を追加
* MsgDecreaseLiquidity：既存のポジションから流動性を削除
* MsgClaimRewards：ポジションで蓄積された手数料とインセンティブを請求

## クエリ

[「クエリ」セクションへのリンク](#クエリ)

このモジュールは、さまざまなクエリエンドポイントを提供します。

* Params：モジュールパラメータのクエリ
* Pool：特定のプールの詳細を取得
* Pools：すべての流動性プールを一覧表示
* Position：特定のポジションの詳細を取得
* Positions：すべてのポジションを一覧表示
* PoolPositions：特定のプール内のポジションを一覧表示
* AddressPositions：アドレスが所有するポジションを一覧表示
* PositionFees：ポジションで発生した手数料を取得
* CalculationCreatePosition：ポジション作成のプレビュー
* CalculationIncreaseLiquidity：流動性増加のプレビュー

詳細については、[Github](https://github.com/sunriselayer/sunrise/tree/main/x/liquiditypool)を参照してください。

# ロックアップ

> x/lockupモジュールは、トークンのロックアップとデリゲーションを管理する機能を提供します。このモジュールは、ロックアップアカウントの作成、非投票デリゲーション、報酬の請求、トークン転送などの操作をサポートします。

`x/lockup`モジュールは、トークンのロックアップとデリゲーションを管理する機能を提供します。このモジュールは、ロックアップアカウントの作成、非投票デリゲーション、報酬の請求、トークン転送などの操作をサポートします。

## 主な特徴

[「主な特徴」セクションへのリンク](#主な特徴)

1. **ロックアップアカウント管理**:

   * ロックアップアカウントの作成と管理
   * ロックアップ期間の設定（開始時刻と終了時刻）
   * ロックアップされたトークンの追跡

2. **非投票デリゲーション**:

   * ロックアップされたトークンのバリデーターへのデリゲーション
   * アンデリゲーション機能
   * デリゲーション報酬の請求

3. **トークン管理**:

   * ロックアップされたトークンの転送
   * 使用可能額のクエリ
   * ロックアップステータスの追跡

## コアコンセプト

[「コアコンセプト」セクションへのリンク](#コアコンセプト)

### ロックアップアカウント

[「ロックアップアカウント」セクションへのリンク](#ロックアップアカウント)

> **注意:** 次のセクションでは、経験豊富なユーザーまたは開発者向けの高度なトピックについて説明します。

ロックアップアカウントは、次のパラメータによって定義されます。

* **`address`**: ロックアップアカウントのアドレス
* **`owner`**: アカウント所有者のアドレス
* **`id`**: ロックアップアカウントの一意の識別子
* **`start_time`**: ロックアップ開始時刻（Unixタイムスタンプ）
* **`end_time`**: ロックアップ終了時刻（Unixタイムスタンプ）
* **`original_locking`**: 元のロックアップ額
* **`delegated_free`**: 利用可能なデリゲート済み転送額
* **`delegated_locking`**: ロックアップ額のデリゲート済み額
* **`unbond_entries`**: アンボンディングエントリのリスト
* **`additional_locking`**: 追加のロックアップ額

### アンボンディングエントリ

[「アンボンディングエントリ」セクションへのリンク](#アンボンディングエントリ)

アンボンディングエントリは、次のパラメータによって定義されます。

* **`creation_height`**: エントリが作成されたブロック高
* **`end_time`**: エントリの終了時刻
* **`amount`**: アンボンディング額
* **`validator_address`**: バリデーターのアドレス

## ワークフロー

[「ワークフロー」セクションへのリンク](#ワークフロー)

### 1. ロックアップアカウントの初期化

[「1. ロックアップアカウントの初期化」セクションへのリンク](#1-ロックアップアカウントの初期化)

* ユーザーがロックアップアカウントを作成
* ロックアップ期間と金額を設定
* アカウント所有者を指定

### 2. 非投票デリゲーション

[「2. 非投票デリゲーション」セクションへのリンク](#2-非投票デリゲーション)

* ロックアップされたトークンをバリデーターにデリゲート
* アンデリゲーションを実行
* デリゲーション報酬を請求

### 3. トークン転送

[「3. トークン転送」セクションへのリンク](#3-トークン転送)

* ロックアップアカウントからトークンを転送
* 使用可能額を検証
* 転送を実行

## シーケンス図：ロックアップ操作

[「シーケンス図：ロックアップ操作」セクションへのリンク](#シーケンス図ロックアップ操作)

```
sequenceDiagram
    participant User as ユーザー
    participant LockupModule as x/lockup モジュール
    participant Validator as バリデーター
    participant Bank as x/bank モジュール

    User->>LockupModule: ロックアップアカウントを作成
    LockupModule->>Bank: トークンをロック
    User->>LockupModule: 非投票デリゲート
    LockupModule->>Validator: トークンをデリゲート
    Validator->>LockupModule: 報酬を生成
    User->>LockupModule: 報酬を請求
    LockupModule->>User: 報酬を送信
```

## メッセージ

[「メッセージ」セクションへのリンク](#メッセージ)

このモジュールは、さまざまなメッセージタイプを提供します。

* MsgUpdateParams：モジュールパラメータの更新（ガバナンス操作）
* MsgInitLockupAccount：指定されたパラメータで新しいロックアップアカウントを初期化
* MsgNonVotingDelegate：投票権なしでロックアップアカウントからトークンをデリゲート
* MsgNonVotingUndelegate：非投票デリゲーションからトークンをアンデリゲート
* MsgClaimRewards：ロックアップアカウントのデリゲーション報酬を請求
* MsgSend：ロックアップアカウントから別のアドレスにトークンを送信

## クエリ

[「クエリ」セクションへのリンク](#クエリ)

このモジュールは、さまざまなクエリエンドポイントを提供します。

* Params：モジュールパラメータのクエリ
* LockupAccounts：特定の所有者のすべてのロックアップアカウントを一覧表示
* LockupAccount：特定のロックアップアカウントの詳細を取得
* SpendableAmount：特定のロックアップアカウントの使用可能額を取得

詳細については、[Github](https://github.com/sunriselayer/sunrise/tree/main/x/lockup)を参照してください。

# プルーフ・オブ・リクイディティ

> プルーフ・オブ・リクイディティ（PoL）は、ユーザーの流動性提供履歴をネットワークの投票力の基盤として利用する、新しいシビル耐性メカニズムです。このアプローチは、バリデーター、流動性プロバイダー、アプリケーション間の経済的インセンティブを、従来のモデルよりも持続可能な方法で調整します。

プルーフ・オブ・リクイディティ（PoL）は、ユーザーの流動性提供履歴をネットワークの投票力の基盤として利用する、新しいシビル耐性メカニズムです。このアプローチは、バリデーター、流動性プロバイダー、アプリケーション間の経済的インセンティブを、従来のモデルよりも持続可能な方法で調整します。

## コアコンセプト

[「コアコンセプト」セクションへのリンク](#コアコンセプト)

### 理論的基礎

[「理論的基礎」セクションへのリンク](#理論的基礎)

プルーフ・オブ・リクイディティは、確立されたDeFiメカニズムを基盤としながら、主要な問題を解決します。

1. **ve-Tokenomicsを超えて**: Curveのようなve（vote-escrowed）モデルはガバナンス参加を可能にしますが、PoLは流動性提供をネットワークセキュリティと直接統合します。
2. **経済活動の分離**: PoLは、コンセンサスセキュリティ、ガバナンス、取引手数料にそれぞれ異なるトークンを使用します。
3. **持続可能なインセンティブ**: トークン価値を希薄化させる従来のDEXインフレモデルとは異なり、PoLは循環的な経済システムを構築します。

## 実装モデル

[「実装モデル」セクションへのリンク](#実装モデル)

### Berachainの実装

[「Berachainの実装」セクションへのリンク](#berachainの実装)

Berachainは、3つのトークン設計でPoLモデルを開拓しました。

* **$BERA**: 取引手数料とステーキング（セキュリティレイヤー）に使用される譲渡可能なトークン
* **$BGT**: 流動性を提供することで獲得できる譲渡不可能なガバナンストークン
* **$HONEY**: エコシステム内での価値移転のためのステーブルコイン

**主要な技術的コンポーネント:**

* バリデーターは$BERAをステークしてコンセンサスセットに参加します。
* ブロック報酬は、バリデーターの「ブースト」率に基づいて$BGTで支払われます。
* 「ブースト」は、トークン保有者からデリゲートされた$BGTから計算されます。
* バリデーターは、排出量をリワードボールトに向け、リワードボールトは流動性プロバイダーに$BGTを分配します。

**価値の流れ:**

1. バリデーターはセキュリティボンドとして$BERAをステークします。
2. バリデーターはブロック生成の報酬として$BGTを受け取ります。
3. バリデーターは$BGT報酬をプロトコルのリワードボールトに向けます。
4. 流動性プロバイダーは、リワードボールトにレシートトークンをステークして$BGTを獲得します。
5. $BGT保有者はバリデーターにデリゲートして報酬をブーストします。
6. プロトコルは、排出量誘致のためにバリデーターにインセンティブを提供します。

### Sunriseの実装

[「Sunriseの実装」セクションへのリンク](#sunriseの実装)

Sunriseは、独自のアーキテクチャでPoLのコンセプトを基盤としています。

* **vRISE**: ステーキングとガバナンスのための譲渡不可能なトークン
* **RISE**: ガスと手数料として使用される譲渡可能なトークン

**技術的実装:**

* `x/liquiditypool`モジュールの流動性プロバイダーはvRISEを獲得します。
* vRISE保有者は`x/staking`モジュールでステークできます。
* ステーカーは`x/liquidityincentive`モジュールを通じてゲージ投票に参加します。
* ゲージ投票者は、どのプールがvRISEインセンティブを受け取るかを決定します。
* 投票者はプールの利益から報酬を得て、インセンティブを調整します。

## 技術的アーキテクチャ

[「技術的アーキテクチャ」セクションへのリンク](#技術的アーキテクチャ)

### Sunriseモジュール

[「Sunriseモジュール」セクションへのリンク](#sunriseモジュール)

Sunriseの実装は、PoLエコシステムを構築するために相互作用するいくつかの主要なモジュールで構成されています。

|                      | 機能              |
| -------------------- | --------------- |
| x/liquiditypool      | コアAMM機能         |
| x/liquidityincentive | ゲージ投票とインセンティブ分配 |
| x/swap               | トークンスワップ実装      |
| x/staking            | vRISEステーキング管理   |

### ゲージ投票システム

[「ゲージ投票システム」セクションへのリンク](#ゲージ投票システム)

ゲージ投票システムは、PoL実装の礎です。

1. **エポックベースの投票**:

* 投票力は、エポック開始時にステークされたvRISEによって決定されます。
* 各エポックは、事前に定義された数のブロックにわたります（ガバナンスを介して設定可能）。
* 新しいエポックが作成されるたびに、投票はクリアされます。

2. **報酬分配**:

プール報酬=総報酬×全プールの総投票力プールの投票力​ ユーザー報酬=プール報酬×プールの投票力ユーザーの投票力​

* 排出量はブロックごとに計算されます。
* 投票されたゲージの重みと各ユーザーの投票力に基づいて分配されます。
* 報酬はユーザーのポジションに蓄積されます。いつでも請求できます。

### コンセンサス実装

[「コンセンサス実装」セクションへのリンク](#コンセンサス実装)

Sunriseは、次の仕様でコンセンサスにCometBFT（Tendermint）を使用します。

* **最大バリデーターセット**: 100バリデーター
* **ブロックタイム**: 約10秒
* **バリデーター選択**: ステークの重みに基づく

将来の計画には、スループット向上のためのMysticeti統合の調査が含まれます。

## 技術的利点

[「技術的利点」セクションへのリンク](#技術的利点)

### 資本効率

[「資本効率」セクションへのリンク](#資本効率)

ステークされたトークンがアイドル状態である従来のPoSとは異なり、PoLは以下を可能にします。

* 流動性提供による積極的な資本活用
* 二重の収益機会（ステーキング+流動性手数料）
* ネットワークセキュリティのための機会費用が低い

### 経済的整合性

[「経済的整合性」セクションへのリンク](#経済的整合性)

技術設計は、インセンティブを調整する循環的な依存関係を作成します。

* バリデーターは、報酬を最大化するためにデリゲートされたRISE/vRISEを必要とします。
* アプリケーションは、流動性のためにバリデーターの排出量を必要とします。
* ユーザーは、ガバナンストークンを獲得するために流動性を提供する必要があります。
* インフレ報酬は、vRISE（ガバナンストークン）の希薄化につながらないRISEで分配されます。

| 機能        | トークン                                                               | 詳細                               |
| --------- | ------------------------------------------------------------------ | -------------------------------- |
| セキュリティ    | ![RISE](/images/RISE.png) RISE + ![vRISE](/images/vRISE.svg) vRISE | vRISEとRISEの両方をコンセンサスのためにステークできます |
| ガバナンス     | ![vRISE](/images/vRISE.svg) vRISE                                  | vRISEはオンチェーンガバナンスとゲージ投票に使用されます   |
| セキュリティ排出量 | ![RISE](/images/RISE.png) RISE                                     | RISEはコンセンサス報酬としてステーカーに分配されます     |
| LP排出量     | ![vRISE](/images/vRISE.svg) vRISE                                  | vRISEはインセンティブとしてLPに分配されます        |
| 手数料       | 任意（[手数料トークン](/learn/sunrise/fee) にスワップ）                            | RISEは取引手数料として使用されます              |

**凡例:**\
![RISE](/images/RISE.png) = RISE\
![vRISE](/images/vRISE.svg) = vRISE

> **注意:**\
> Sunriseでは、各トークンの役割と報酬が明確に定義されています。\
> この明確な機能分離は、ガバナンスや流動性報酬が分配される際のネットワークセキュリティの希薄化を防ぐのに役立ちます。

### セキュリティに関する考慮事項

[「セキュリティに関する考慮事項」セクションへのリンク](#セキュリティに関する考慮事項)

実装には、いくつかのセキュリティ対策が含まれています。

* **スラッシング条件**: バリデーターは、不正行為に対してステークされた資産を失うリスクがあります。
* **ガバナンスの保護措置**: 加重投票は乗っ取りを防ぎます。
* **インセンティブの互換性**: 経済設計は攻撃を抑制します。

## パフォーマンスに関する考慮事項

[「パフォーマンスに関する考慮事項」セクションへのリンク](#パフォーマンスに関する考慮事項)

PoLの実装は、いくつかのパフォーマンス要素のバランスを取る必要があります。

* **エポックの長さ**: エポックが長いと計算オーバーヘッドは減少しますが、応答性は低下します。
* **バリデーターセットのサイズ**: セットが大きいと分散化は向上しますが、コンセンサス速度に影響を与える可能性があります。
* **投票処理**: ガス代を最小限に抑えるために、エポックの境界で投票をバッチ処理します。
* **レシートトークンの計算**: 流動性ポジションと報酬分配の最適化された追跡。

## 今後の方向性

[「今後の方向性」セクションへのリンク](#今後の方向性)

いくつかの技術的強化が検討されています。

1. **Mysticeti統合**: スループット向上のためのMysticetiコンセンサスの採用を調査
2. **クロスチェーンゲージ**: 接続されたチェーン上の流動性に対する投票を可能にする
3. **動的排出スケジュール**: ネットワークメトリクスに基づく排出量のアルゴリズム的調整
4. **高度な報酬メカニズム**: ボンディングカーブを使用した、より洗練された報酬分配

## 参考文献

[「参考文献」セクションへのリンク](#参考文献)

* [Berachain: Flow of Value](https://blog.berachain.com/blog/flow-of-value-examining-the-differences-between-pos-and-pol-a-case-for-a-new-paradigm-in-sustainable-incentive-alignment-at-the-protocol-layer)
* [ve(3,3) Tokenomics](https://andrecronje.medium.com/ve-3-3-44466eaa088b)
* [Curve Finance ve-Token Model](https://curve.fi/files/CurveDAO.pdf)
* [Mysticeti Consensus](https://sui.io/mysticeti)

# 非投票型デリゲーション

> x/shareclassモジュールは、ユーザーが投票権なしでRISEトークンをデリゲートし、ステーキング報酬を得ることを可能にします。これにより、vRISE（譲渡不可能なステーキングトークン）を保有していなくても、RISEトークンを使用してステーキングに参加できます。

`x/shareclass`モジュールは、ユーザーが投票権なしでRISEトークンをデリゲートし、ステーキング報酬を得ることを可能にします。これにより、`vRISE`（譲渡不可能なステーキングトークン）を保有していなくても、RISEトークンを使用してステーキングに参加できます。

## 主な特徴

[「主な特徴」セクションへのリンク](#主な特徴)

1. **RISEによる非投票デリゲーション:**

   * ユーザーはRISEトークンをバリデーターにデリゲートできます。
   * デリゲーションは投票権を付与せず、ステーキング報酬とガバナンス参加を分離します。

2. **ステーキング報酬の獲得:**

   * デリゲーターは、デリゲートしたRISEの量に基づいてステーキング報酬を得ます。
   * RISEトークン保有者が報酬を得るための代替方法を提供します。

3. **バリデーターの作成:**
   * ネットワーク内での新しいバリデーターの作成をサポートします。

## コアコンセプト

[「コアコンセプト」セクションへのリンク](#コアコンセプト)

### 非投票デリゲーション

[「非投票デリゲーション」セクションへのリンク](#非投票デリゲーション)

ユーザーは、選択したバリデーターにRISEトークンをデリゲートできます。このモジュールは、株式と報酬の計算を処理します。このメカニズムにより、ユーザーは`vRISE`トークンを管理したり、ガバナンスに直接参加したりすることなく、ステーキング報酬の恩恵を受けることができます。

### 報酬計算

[「報酬計算」セクションへのリンク](#報酬計算)

ステーキング報酬は、デリゲートされたRISEの量とモジュールの報酬パラメータに基づいて計算されます。ユーザーは、蓄積された報酬を請求できます。

## ワークフロー

[「ワークフロー」セクションへのリンク](#ワークフロー)

### 1. RISEのデリゲート（非投票）

[「1. RISEのデリゲート（非投票）」セクションへのリンク](#1-riseのデリゲート非投票)

* ユーザーは`MsgNonVotingDelegate`トランザクションを送信し、バリデーターとデリゲートするRISEの量を指定します。
* モジュールはデリゲーションを記録し、対応する株式を計算します。

### 2. 報酬の請求

[「2. 報酬の請求」セクションへのリンク](#2-報酬の請求)

* ユーザーは`MsgClaimRewards`トランザクションを送信して、特定のバリデーターの蓄積されたステーキング報酬を請求します。
* モジュールは報酬をユーザーのアカウントに転送します。

### 3. RISEのアンデリゲート（非投票）

[「3. RISEのアンデリゲート（非投票）」セクションへのリンク](#3-riseのアンデリゲート非投票)

* ユーザーは`MsgNonVotingUndelegate`トランザクションを送信して、デリゲートしたRISEを引き出します。
* モジュールはアンデリゲーション要求を処理し、トークンはアンボンディング期間後に利用可能になります。

### 4. バリデーターの作成（オプション）

[「4. バリデーターの作成（オプション）」セクションへのリンク](#4-バリデーターの作成オプション)

* ユーザーは`MsgCreateValidator`トランザクションを送信して、ネットワークに新しいバリデーターノードを登録できます。

## シーケンス図：非投票デリゲーションと報酬

[「シーケンス図：非投票デリゲーションと報酬」セクションへのリンク](#シーケンス図非投票デリゲーションと報酬)

```
sequenceDiagram
    participant User as ユーザー
    participant ShareclassModule as x/shareclass モジュール
    participant StakingModule as x/staking モジュール
    participant BankModule as x/bank モジュール

    User->>ShareclassModule: MsgNonVotingDelegate (RISE)
    ShareclassModule->>StakingModule: バリデーターへのデリゲート（内部的に）
    ShareclassModule-->>User: 株式と初期報酬を返す（もしあれば）

    loop 報酬期間
        StakingModule-->>ShareclassModule: ステーキング報酬を分配
    end

    User->>ShareclassModule: MsgClaimRewards
    ShareclassModule->>BankModule: ユーザーに報酬を転送
    ShareclassModule-->>User: 報酬請求の確認

    User->>ShareclassModule: MsgNonVotingUndelegate
    ShareclassModule->>StakingModule: アンデリゲーションを開始（内部的に）
    ShareclassModule-->>User: アンデリゲーションと完了時刻の確認
```

## メッセージ

[「メッセージ」セクションへのリンク](#メッセージ)

このモジュールは、さまざまなメッセージタイプを提供します。

* MsgUpdateParams：モジュールパラメータの更新（ガバナンス操作）
* MsgNonVotingDelegate：投票権なしでRISEトークンをバリデーターにデリゲート
* MsgNonVotingUndelegate：非投票デリゲーションからRISEトークンをアンデリゲート
* MsgClaimRewards：非投票デリゲーションから蓄積されたステーキング報酬を請求
* MsgCreateValidator：ネットワークに新しいバリデーターを作成

## クエリ

[「クエリ」セクションへのリンク](#クエリ)

このモジュールは、さまざまなクエリエンドポイントを提供します。

* Params：モジュールパラメータのクエリ
* CalculateBondingAmount：特定の株式に対して結合されるトークンを計算
* CalculateShare：特定のトークンに対して受け取る株式を計算
* AddressBonded：特定のアドレスの結合済み合計額を取得
* ClaimableRewards：バリデーターからアドレスが請求できる報酬を取得
* AddressUnbonding：特定のアドレスのアンボンディングデリゲーションを取得

詳細については、[Github](https://github.com/sunriselayer/sunrise/tree/main/x/shareclass)を参照してください。

# Stable

> x/stableモジュールは、担保資産によって裏付けられたネイティブステーブルコインの発行（ミント）と償還（バーン）を管理します。

`x/stable`モジュールは、担保資産によって裏付けられたネイティブステーブルコインの発行（ミント）と償還（バーン）を管理します。

## 主な特徴

[「主な特徴」セクションへのリンク](#主な特徴)

1. **ミントとバーン:**

   * ユーザーは、承認された担保資産を預けることでステーブルコインをミントできます。
   * ステーブルコインを返却することで、対応する担保を引き出す（バーンする）ことができます。

2. **担保管理:**
   * モジュールは、どの資産が担保として受け入れられるかを定義し、ステーブルコインの供給を裏付けます。

3. **許可制の管理:**
   * ステーブルコインのミントとバーンは、許可されたアドレスまたはコントラクトによってのみ実行でき、管理された供給を保証します。

4. **動的な為替レート:**
   * 為替レートは、担保資産の市場価値に基づいて動的に決定できます。

5. **オンチェーンの監査可能性:**
   * モジュールは、担保と発行されたステーブルコインの透明な追跡を提供し、オンチェーンでの監査を可能にします。

## コアコンセプト

[「コアコンセプト」セクションへのリンク](#コアコンセプト)

### モジュールパラメータ

[「モジュールパラメータ」セクションへのリンク](#モジュールパラメータ)

`x/stable`モジュールは、その動作を制御するいくつかのパラメータによって設定されます。

| パラメータ            | 説明                                   |
| :--------------- | :----------------------------------- |
| `Authority`      | モジュールパラメータを更新する権限を持つアドレス             |
| `Minter`         | ステーブルコインをミントおよびバーンする権限を持つアドレス        |
| `AcceptedDenoms` | ミントの担保として受け入れられるトークンのデノミネーション        |
| `StableDenom`    | ミントされるステーブルコインのデノミネーション              |
| `ExchangeRates`  | 受け入れられるデノミネーションとステーブルデノミネーション間の為替レート |

### 為替レート

[「為替レート」セクションへのリンク](#為替レート)

モジュールは、`AcceptedDenoms`と`StableDenom`間の為替レートを維持します。これにより、ミントおよびバーン操作中に公正な価値の交換が保証されます。

## ワークフロー

[「ワークフロー」セクションへのリンク](#ワークフロー)

### 1. ステーブルコインのミント

[「1. ステーブルコインのミント」セクションへのリンク](#1-ステーブルコインのミント)

* ユーザーは`MsgMint`トランザクションを送信し、ミントしたいステーブルコインの量と、担保として提供する`AcceptedDenom`の量を指定します。
* モジュールは、ユーザーが十分な担保を持っていることを確認し、指定された量のステーブルコインをユーザーのアカウントにミントします。

### 2. ステーブルコインのバーン

[「2. ステーブルコインのバーン」セクションへのリンク](#2-ステーブルコインのバーン)

* ユーザーは`MsgBurn`トランザクションを送信し、バーンしたいステーブルコインの量を指定します。
* モジュールは、ユーザーのステーブルコインをバーンし、対応する量の担保をユーザーのアカウントに返します。

## シーケンス図：ミントとバーン

[「シーケンス図：ミントとバーン」セクションへのリンク](#シーケンス図ミントとバーン)

```
sequenceDiagram
    participant User as ユーザー
    participant StableModule as x/stable モジュール
    participant BankModule as x/bank モジュール

    User->>StableModule: MsgMint (担保付き)
    StableModule->>BankModule: 担保をロック
    StableModule->>BankModule: ステーブルコインをミントしてユーザーに送信
    StableModule-->>User: ミント確認

    User->>StableModule: MsgBurn (ステーブルコイン付き)
    StableModule->>BankModule: ユーザーからステーブルコインをバーン
    StableModule->>BankModule: 担保をアンロックしてユーザーに送信
    StableModule-->>User: バーン確認
```

## メッセージ

[「メッセージ」セクションへのリンク](#メッセージ)

* MsgMint：承認された担保を使用してステーブルコインをミントします。
* MsgBurn：ステーブルコインをバーンして、基礎となる担保資産を償還します。

## クエリ

[「クエリ」セクションへのリンク](#クエリ)

* Params：モジュールパラメータのクエリ。
* ModuleAccountBalance：`x/stable`モジュールの残高のクエリ。これにより、担保準備金の透明性が提供されます。

### 監査可能性

[「監査可能性」セクションへのリンク](#監査可能性)

`ModuleAccountBalance`クエリは、モジュールによって保持されている担保資産の合計量を誰でも検証できるようにするため、監査可能性にとって重要です。この残高は、流通しているステーブルコインの供給を裏付けるはずです。

詳細については、[Github](https://github.com/sunriselayer/sunrise/tree/main/x/stable)を参照してください。

# スワップ

> x/swap モジュールは、x/liquiditypool モジュールの流動性を使ってトークンをスワップする機能を提供します。

`x/swap` モジュールは、`x/liquiditypool` モジュールの流動性を使ってトークンをスワップする機能を提供します。

## インターフェースプロバイダーの手数料報酬

[「インターフェースプロバイダーの手数料報酬」セクションへのリンク](#インターフェースプロバイダーの手数料報酬)

スワップモジュールの上に作られたフロントエンド、ウォレット、dApp、プロトコルは、手数料を得られます。これにより、Sunrise AMM まわりのオープンで組み合わせ可能な基盤が促進されます。

重要なパラメータは 2 つです。

* **interface\_fee\_rate**\
  スワップ総額から取る、パーセント表記の手数料です。
* **interface\_provider**\
  手数料の送金先アドレスです。アドレスが指定されなければ、インターフェース手数料は取りません。

Sunrise AMM 経由でスワップするとき、手数料の受取先を指定することで **インターフェース手数料を得られ**、トランザクションあたりの収益を最大化できます。この機能は、シンプルなフロントエンドから複雑な金融プロトコルまで、**スワップ出来高を仲介する主体** に報酬を出すために設計されています。

***

### スワップのメッセージタイプ

[「スワップのメッセージタイプ」セクションへのリンク](#スワップのメッセージタイプ)

受け取る量、または送る量を指定するメッセージタイプが 2 つあります。

* **MsgSwapExactAmountIn** - 入力額を指定してトークンをスワップします\
  提供したい入力トークンの正確な量を定義してスワップします。対応する出力は、指定した入力に基づいて計算されます。

* **MsgSwapExactAmountOut** – 出力額を指定してトークンをスワップします

  受け取りたい出力トークンの正確な量を定義してスワップします。希望する出力を得るために必要な入力額をシステムが計算します。

***

### ルート

[「ルート」セクションへのリンク](#ルート)

> **注記:** 以降の節は、経験豊富なユーザーまたは開発者向けの高度な内容です。

このモジュールは再帰構造の Swap Route をサポートし、連続（Series）または同時（Parallel）の複数ステップからなる複雑なスワップができます。ルートの各ステップは検証され、入出力が正しく扱われるよう処理されます。

```typescript
message RoutePool {
    uint64 pool_id = 1;
}


message RouteSeries {
    repeated Route routes = 1 [
        (gogoproto.nullable)   = false,
            (amino.dont_omitempty) = true
        ];
}


message RouteParallel {
    repeated Route routes = 1 [
        (gogoproto.nullable)   = false,
            (amino.dont_omitempty) = true
        ];
    repeated string weights = 2 [
        (cosmos_proto.scalar)  = "cosmos.Dec",
            (gogoproto.customtype) = "cosmossdk.io/math.LegacyDec",
            (gogoproto.nullable)   = false,
            (amino.dont_omitempty) = true
        ];
}


message Route {
    string denom_in = 1;
    string denom_out = 2;
    oneof strategy {
        RoutePool pool = 3;
        RouteSeries series = 4;
        RouteParallel parallel = 5;
    }
}
```

***

### ICS20 トークン転送のスワップミドルウェア

[「ICS20 トークン転送のスワップミドルウェア」セクションへのリンク](#ics20-トークン転送のスワップミドルウェア)

スワップは ICS20 トークン転送パケットによって自動的に起動できます。IBC Hooks に似ており、ICS20 を使える任意のチェーン（Solidity IBC Eureka、Sei 上の CosmWasm など）の開発者が、IBC ミドルウェア経由でスワップモジュールと連携できます。

#### メタデータ

[「メタデータ」セクションへのリンク](#メタデータ)

シリアライズした `PacketMetadata` の JSON 文字列を、ICS20 転送パケットの `memo` フィールドに置く必要があります。

```typescript
type PacketMetadata = {
    [namespace: string]: unknown;
    swap?: SwapMetadata;
};


type SwapMetadata = {
    interface_provider: string;
    route: Route;


    forward?: ForwardMetadata;
} & (
    | {
    exact_amount_in: {
        min_amount_out: string;
    };
}
    | {
    exact_amount_out: {
        amount_out: string;
        change?: ForwardMetadata;
    };
}
    );


type ForwardMetadata = {
    receiver: string;
    port: string;
    channel: string;
    timeout: string;
    retries: number;
    next?: PacketMetadata;
};
```

`ForwardMetadata` は [Packet Forward Middleware](https://github.com/cosmos/ibc-apps/tree/main/middleware/packet-forward-middleware) に由来します。

## **シーケンス図**

[「シーケンス図」セクションへのリンク](#シーケンス図)

> **注記:** 以降の節は、経験豊富なユーザーまたは開発者向けの高度な内容です。

### フォワーディングなしの基本スワップ

[「フォワーディングなしの基本スワップ」セクションへのリンク](#フォワーディングなしの基本スワップ)

このシナリオではトークン転送のあとスワップが行われますが、別チェーンへのフォワーディングはありません。

```
sequenceDiagram
    autonumber
    Chain A ->> Sunrise: トークン X を転送
    Sunrise --> Sunrise: recv_packet
    Sunrise ->> Sunrise: トークン X をトークン Y にスワップ
    Sunrise ->> Chain A: ack
```

#### フォワーディング付きスワップ

[「フォワーディング付きスワップ」セクションへのリンク](#フォワーディング付きスワップ)

このシナリオでは、トークンが転送され、スワップされたあと、別チェーンへフォワードされます。

```
sequenceDiagram
    autonumber
    Chain A ->> Sunrise: トークン X を転送
    Sunrise --> Sunrise: recv_packet
    Sunrise ->> Sunrise: トークン X をトークン Y にスワップ

    Sunrise ->> Chain B: トークン Y をフォワード
    Chain B --> Chain B: recv_packet
    Chain B ->> Sunrise: ack
    Sunrise ->> Chain A: ack
```

#### 余剰返金とフォワーディング付きスワップ

[「余剰返金とフォワーディング付きスワップ」セクションへのリンク](#余剰返金とフォワーディング付きスワップ)

正確な出力額を指定したスワップでは、余った入力は自動的に返金されます。スワップ後、残りのトークンは別チェーンへフォワードされます。

```
sequenceDiagram
    autonumber
    Chain A ->> Sunrise: トークン X を転送
    Sunrise --> Sunrise: recv_packet
    Sunrise ->> Sunrise: トークン X をトークン Y にスワップ

    Sunrise ->> Chain A: トークン X の釣りを返す
    Sunrise ->> Chain B: トークン Y をフォワード
    Chain A --> Chain A: recv_packet
    Chain B --> Chain B: recv_packet
    Chain A ->> Sunrise: ack
    Chain B ->> Sunrise: ack
    Sunrise ->> Chain A: ack
```

### 受信アドレスの扱い

[「受信アドレスの扱い」セクションへのリンク](#受信アドレスの扱い)

スワップ後に後続の釣り返金や転送が失敗しても、「トークン X の転送」の確認は常に成功します。スワップ済みトークンは受信者のアカウントに残ります。

## メッセージ

[「メッセージ」セクションへのリンク](#メッセージ)

モジュールは次のメッセージタイプを提供します。

* MsgUpdateParams: モジュールパラメータを更新します（ガバナンス操作）
* MsgSwapExactAmountIn: 入力額を指定してトークンをスワップします
* MsgSwapExactAmountOut: 出力額を指定してトークンをスワップします

## クエリ

[「クエリ」セクションへのリンク](#クエリ)

モジュールは次のクエリエンドポイントを提供します。

* Params: モジュールパラメータを照会します
* IncomingInFlightPacket: 受信中の in-flight パケットの詳細を取得します
* IncomingInFlightPackets: 受信中の in-flight パケットを一覧します
* OutgoingInFlightPacket: 送信中の in-flight パケットの詳細を取得します
* OutgoingInFlightPackets: 送信中の in-flight パケットを一覧します
* CalculationSwapExactAmountIn: 正確な入力額でのスワップをプレビューします
* CalculationSwapExactAmountOut: 正確な出力額でのスワップをプレビューします

詳細は [Github](https://github.com/sunriselayer/sunrise/tree/main/x/swap) を参照してください。

# トークンコンバーター

> x/tokenconverter モジュールは、Sunrise ブロックチェーン上で vRISE と RISE をシームレスに変換します。ステーキングトークンと手数料トークンを等価のまま切り替えられます。

`x/tokenconverter` モジュールは、Sunrise ブロックチェーン上で `vRISE` と `RISE` をシームレスに変換します。ステーキングトークンと手数料トークンを等価のまま切り替えられる点が、このモジュールの役割です。

## 主な特徴

[「主な特徴」セクションへのリンク](#主な特徴)

1. **双方向のトークン変換:**

   * `vRISE`（ボンドデノム）を `RISE`（手数料デノム）へ、またその逆へ変換します。
   * トークン間の 1:1 の等価関係を維持します。

2. **パーミッションレスな操作:**

   * 任意のユーザーがいつでも変換できます。
   * 変換にスリッページや手数料はかかりません。

## コア機能

[「コア機能」セクションへのリンク](#コア機能)

> **注記:** 以降の節は、経験豊富なユーザーまたは開発者向けの高度な内容です。

### トークン変換

[「トークン変換」セクションへのリンク](#トークン変換)

モジュールは `vRISE` と `RISE` のあいだで、単純で直接的な変換を提供します。

* vRISE を RISE に変換するとき、モジュールは vRISE をバーンし、同量の RISE をミントします。
* RISE を vRISE に変換するとき、モジュールは RISE をバーンし、同量の vRISE をミントします。（ユーザーは利用できません）

この処理により、システムの経済的な総価値は保ったまま、用途に合ったトークン種別を選べます。

## ワークフロー: トークン変換の流れ

[「ワークフロー: トークン変換の流れ」セクションへのリンク](#ワークフロー-トークン変換の流れ)

> **注記:** 以降の節は、経験豊富なユーザーまたは開発者向けの高度な内容です。

```
sequenceDiagram
    participant User as ユーザー
    participant TokenConverter as x/tokenconverter モジュール
    participant BankKeeper as Bank モジュール

    User->>TokenConverter: MsgConvert
    TokenConverter->>BankKeeper: vRISE をバーン
    TokenConverter->>BankKeeper: RISE をミント
    TokenConverter->>User: 変換後の RISE を返す
```

## メッセージ

[「メッセージ」セクションへのリンク](#メッセージ)

モジュールは次のメッセージタイプを提供します。

* MsgUpdateParams: モジュールパラメータを更新します（ガバナンス操作）
* MsgConvert: ボンドデノムと手数料デノムのあいだでトークンを変換します

### MsgConvert

[「MsgConvert」セクションへのリンク](#msgconvert)

ボンドデノムと手数料デノムのあいだでトークンを変換します。

```go
type MsgConvert struct {
    Sender  string
    Amount  string
}
```

## 利点

[「利点」セクションへのリンク](#利点)

1. **柔軟なトークン利用:**

   * 好みのデノムでトークンを保有できます。
   * 用途（ステーキングか手数料か）に応じて切り替えられます。

2. **エコシステム連携:**

   * トークン種別の変換により、DA 手数料抽象化を支えます。
   * Sunrise エコシステムの他モジュールの運用を助けます。

3. **シンプルな設計:**

   * 手数料もスリッページもない直接的な変換です。
   * 理解しやすく、アプリケーションへの組み込みも容易です。

詳細は [Github](https://github.com/sunriselayer/sunrise/tree/main/x/tokenconverter) を参照してください。

# 🎓 構想

> ブロックチェーンには 4 つのレイヤーがあります。

## モノリシック vs モジュラー

[「モノリシック vs モジュラー」セクションへのリンク](#モノリシック-vs-モジュラー)

ブロックチェーンには 4 つのレイヤーがあります。

* 実行レイヤー
* 決済レイヤー
* コンセンサスレイヤー
* データ可用性レイヤー

「モジュラーブロックチェーン」とは、これらの分離されたレイヤーを組み合わせ、スケーラブルなブロックチェーンの構築を可能にするパラダイムです。

## データ可用性レイヤー

[「データ可用性レイヤー」セクションへのリンク](#データ可用性レイヤー)

要するに、データ可用性（DA）レイヤーは、L2 トランザクションが L1 ブロックチェーンで確定されるまで、レイヤー 2 ブロックチェーンのトランザクションデータを保存する役割を果たします。

## レイヤーの組み合わせ

[「レイヤーの組み合わせ」セクションへのリンク](#レイヤーの組み合わせ)

### 従来のロールアップ

[「従来のロールアップ」セクションへのリンク](#従来のロールアップ)

Optimism の例：

|            |          |
| ---------- | -------- |
| 実行レイヤー     | Optimism |
| 決済レイヤー     | Ethereum |
| コンセンサスレイヤー | Ethereum |
| データ可用性レイヤー | Ethereum |

### altDA によるスマートコントラクトロールアップ

[「altDA によるスマートコントラクトロールアップ」セクションへのリンク](#altda-によるスマートコントラクトロールアップ)

Eclipse の例：

|            |          |
| ---------- | -------- |
| 実行レイヤー     | Eclipse  |
| 決済レイヤー     | Ethereum |
| コンセンサスレイヤー | Ethereum |
| データ可用性レイヤー | Celestia |

### ソブリンロールアップ

[「ソブリンロールアップ」セクションへのリンク](#ソブリンロールアップ)

Gluon の例：

|            |         |
| ---------- | ------- |
| 実行レイヤー     | Gluon   |
| 決済レイヤー     | Gluon   |
| コンセンサスレイヤー | Sunrise |
| データ可用性レイヤー | Sunrise |

# アプリチェーン構想：モノリシック vs. モジュラー

> アプリチェーン構想は、Web3をスケールさせる最適な方法は、各主要アプリケーションに独自のブロックチェーンを与え、それらのチェーンを相互運用性レイヤー（Cosmosの世界ではIBC）を介して接続することだと主張しています。

**アプリチェーン構想**は、Web3をスケールさせる最適な方法は、各主要アプリケーションに**独自のブロックチェーン**を与え、それらのチェーンを**相互運用性レイヤー**（Cosmosの世界ではIBC）を介して接続することだと主張しています。 説得力はありますが、この構想の元の（「モノリシック」）バージョンには、隠れた運用コストが伴います。ソブリンロールアップと*Rollup-as-a-Service*（RaaS）を搭載した新しい**モジュラー**アプローチは、それらの摩擦のほとんどを排除します。

***

## モノリシックアプリチェーン構想

[「モノリシックアプリチェーン構想」セクションへのリンク](#モノリシックアプリチェーン構想)

> *「すべての本格的なdAppは、独自のL1を持つに値する。」*

### 利点

[「利点」セクションへのリンク](#利点)

* **パフォーマンスの分離** – 無関係なアプリとのガス競争がない。
* **完全なカスタマイズ** – アプリケーション固有のVM、手数料ロジック、ガバナンス。
* **ネイティブな相互運用性** – 信頼できるブリッジなしでのクロスチェーンコールのためのIBCパケット。

### 中心的な弱点 – *バリデーターのブートストラップ*

[「中心的な弱点 – バリデーターのブートストラップ」セクションへのリンク](#中心的な弱点--バリデーターのブートストラップ)

特注のL1を立ち上げるには、以下が必要です。

1. **バリデーターセットの募集**（数十の専門オペレーター）。
2. 正直な行動を奨励するのに十分な時価総額を持つ**ネイティブトークンの配布**。
3. **継続的なDevOps** – チェーンのアップグレード、監視、スラッシングインフラなど。

このオーバーヘッドは採用を遅らせ、多くのチームは単純さのために共有L1にとどまっています。

***

## モジュラーアプリチェーン構想

[「モジュラーアプリチェーン構想」セクションへのリンク](#モジュラーアプリチェーン構想)

> *「主権を保ち、コンセンサスをアウトソースする。」*

**ソブリンロールアップ**は、そのブロックデータを**共有データ可用性（DA）レイヤー**（例：Celestia、Avail、EigenDA、Sunrise）に公開します。 セキュリティはDAレイヤーのバリデーターセットから借用され、ロールアップ自体は**シーケンサー**（または共有シーケンサーネットワーク）とアプリケーションロジックのみを必要とします。

### ブートストラップ問題を解決する理由

[「ブートストラップ問題を解決する理由」セクションへのリンク](#ブートストラップ問題を解決する理由)

* **新しいバリデーターセットは不要** – DAレイヤーがコンセンサスと経済的セキュリティを提供します。
* **トークンはオプション** – アプリトークンはアプリ内ユーティリティに集中でき、コンセンサスを確保する必要はありません。
* **RaaSプラットフォーム** – Rollkit、Dymension、Eclipse、Sovereign SDK、Sagaなどが、展開、アップグレード、監視を自動化します。

### IBCとの互換性

[「IBCとの互換性」セクションへのリンク](#ibcとの互換性)

ソブリンロールアップは、**IBCライトクライアント検証**をステートマシンに直接埋め込むことができ、完全なL1ではないにもかかわらず、Cosmos/IBCメッシュの*ファーストクラス市民*になります。

***

## スマートコントラクト vs. アプリチェーン – ホスティングの類推

[「スマートコントラクト vs. アプリチェーン – ホスティングの類推」セクションへのリンク](#スマートコントラクト-vs-アプリチェーン--ホスティングの類推)

| アーキテクチャ             | インフラの類推      | 運用上の影響                                     |
| ------------------- | ------------ | ------------------------------------------ |
| **スマートコントラクト**      | 共有ホスティング     | 展開は最も安価ですが、隣人の混雑や一般的な手数料モデルの影響を受けます。       |
| **モジュラーアプリ固有チェーン**  | 仮想プライベートサーバー | ほぼ専用のリソース。セキュリティはアウトソース。安価なロールアップブートストラップ。 |
| **モノリシックアプリ固有チェーン** | 専用ベアメタル      | 完全な制御と分離ですが、バリデーターの起動と維持に最も高いコストがかかります。    |

IaaSがVPSから完全管理型プラットフォームへと進化したように、**RaaSはソブリンロールアップの展開をコモディティ化**し、今日スマートコントラクトを展開するのとほぼ同じくらい簡単に専用チェーンを立ち上げることができるようになるでしょう。

***

## モジュラーマルチチェーンの未来へのロードマップ

[「モジュラーマルチチェーンの未来へのロードマップ」セクションへのリンク](#モジュラーマルチチェーンの未来へのロードマップ)

1. **共有シーケンサーとMEV市場** – ロールアップのレイテンシーを削減し、クロスロールアップの原子性を可能にします。
2. **ユニバーサルIBCクライアント** – Tendermint、EthereumスタイルのSSZ、およびZKライトクライアントを再利用可能なモジュールとしてパッケージ化。
3. **許可不要のDA価格設定** – バイトごとの支払い市場（例：AvailのProof-of-Liquidity）が固定費を削減します。
4. **ロールアップ間の構成可能性** – ソブリンロールアップ間でネイティブに実行されるICSアプリケーション（ICS-20、ICS-721、Interchain Accounts）。
5. **ターンキーガバナンス** – オンチェーンアップグレードマネージャーと共有セキュリティ（例：Replicated Security、Babylon BTCステーキング）。

モジュラーアプリチェーン構想は、以前のモデルでは前例のなかった**展開の容易さと経済効率**を達成しつつ、専用チェーンの**主権とカスタマイズ性**を維持します。

# ソブリンロールアップにおける相互運用性

> ソブリンロールアップは、レイヤー2設計における重要な進化を示しています。決済レイヤーのブリッジコントラクトにクロスチェーン検証を委任する代わりに、ソブリンロールアップは対抗チェーンの*独自のライトクライアント検証を実行*し、したがって、アプリケーションレベルで*どのように*、そして*誰と*通信するかを決定します。

ソブリンロールアップは、レイヤー2設計における重要な進化を示しています。決済レイヤーのブリッジコントラクトにクロスチェーン検証を委任する代わりに、ソブリンロールアップは対抗チェーンの*独自のライトクライアント検証を実行*し、したがって、アプリケーションレベルで*どのように*、そして*誰と*通信するかを決定します。 このアーキテクチャは、外部レイヤーでの信頼性を最小限に抑えたデータ可用性（DA）と決済を可能にしながら、ロールアップの自律性を維持します。

***

## 従来のスマートコントラクトロールアップ

[「従来のスマートコントラクトロールアップ」セクションへのリンク](#従来のスマートコントラクトロールアップ)

古典的なオプティミスティック/ZKロールアップでは、すべてのクロスチェーンアクションは、レイヤー1決済チェーン上に存在する**1つのハードコードされた「聖域」ブリッジ**を通過する必要があります。

**実行パス**

1. **L1上のロールアップコントラクト** – 状態ルートとブリッジロジックを保存します。
2. **証明/オプティミスティックウィンドウ** – ロールアップは証明またはルートを投稿します。ブリッジコントラクトは不正/ZK証明を裁定します。
3. **アウトバウンド転送** – ユーザーはブリッジ内に資産をロックします。引き出し証明はコントラクトによって検証されます。
4. **アップグレードの摩擦** – ブリッジのセマンティクスに変更を加えるには、L1コントラクトのアップグレードが必要です（多くの場合、ガバナンスのハードフォークを介して）。

**制限事項**

* **単一障害点** – ブリッジコントラクトはシステムリスクになります。
* **異種ブリッジなし** – アプリケーションはL1ガバナンスなしで新しいチャネルを追加できません。
* **ラップされた資産** – ほとんどのブリッジは、ネイティブ転送の代わりにIOUトークンを発行します。
* **スループットのボトルネック** – すべてのメッセージが同じコントラクトにキューイングされます。ガススパイクはロールアップユーザーに伝播します。

***

## ソブリンロールアップ

[「ソブリンロールアップ」セクションへのリンク](#ソブリンロールアップ)

ソブリンロールアップは、そのデータ（ブロブ、状態ルート）をDAレイヤーに公開しますが、オンチェーンのライトクライアントまたは有効性証明を介して他のチェーンを*自己検証*します。 ブリッジは、許可なく展開およびアップグレードできる通常のモジュールになります。

### 技術的特性

[「技術的特性」セクションへのリンク](#技術的特性)

| 機能               | 実装の詳細                                                                       |
| ---------------- | --------------------------------------------------------------------------- |
| **自己主権検証**       | 各リモートチェーン用の埋め込みライトクライアントまたはZK検証者。外部ブリッジコントラクトへの依存なし。                        |
| **複数プロトコル**      | IBC、カスタムSNARKブリッジ、またはトークン固有のチャネルを並行してサポート。                                  |
| **ネイティブ資産移動**    | ライトクライアント検証により、ロールアップは*元の*トークンのロックを解除でき、ラップされたIOUを回避できます。                   |
| **構成可能なチャネル**    | 各アプリケーションは、カスタム手数料ロジック、レート制限、またはミドルウェアを備えた独立したチャネルをインスタンス化できます。             |
| **分離されたアップグレード** | ブリッジロジックはロールアップモジュールです。アップグレードにはL1ガバナンスは**不要**で、ロールアップガバナンスまたはコード更新のみが必要です。 |

***

## IBC — ソブリン相互運用性の事実上の標準

[「IBC — ソブリン相互運用性の事実上の標準」セクションへのリンク](#ibc--ソブリン相互運用性の事実上の標準)

\*\*Inter-Blockchain Communication (IBC)\*\*プロトコル（Cosmos SDK発祥）は、以下を提供します。

* **クライアント-接続-チャネル抽象化** – 認証（ライトクライアント）とアプリケーションセマンティクスをきれいに分離する階層化されたハンドシェイク。
* **コミットのみのライトクライアント** – 各チェーンは他のチェーンのヘッダーコミットメントを保存し、オンチェーンでマークル証明を検証します。
* **許可不要のリレーヤー** – オフチェーンプロセスがパケットをブロードキャストします。どの俳優も信頼力を得ることなくリレーできます。
* **順序付き/順序なしチャネル** – ファンジブルトークン（ICS-20）と任意のデータ（ICS-27、ICS-721など）の両方に適した決定論的なパケットシーケンス。
* **タイムアウトとアップグレードパス** – 不正行為があった場合、チャネルは閉じることができます。ライトクライアントは、新しいクライアント状態のオンチェーン証明を使用して自律的にアップグレードします。

ソブリンロールアップはすでに自身の状態遷移関数を所有しているため、IBCの統合には以下のみが必要です。

1. IBC*コア*モジュール（クライアント、接続、チャネルロジック）のインポート。
2. 各対抗相手のライトクライアント実装の提供（例：Tendermint-BFT、zkベースのヘッダー証明、Ethereum-SSZ）。
3. パケットをマーシャリングするアプリケーションモジュール（トークン転送、クロスロールアップDEXなど）の定義。

***

## 比較：従来型 vs. ソブリン相互運用性

[「比較：従来型 vs. ソブリン相互運用性」セクションへのリンク](#比較従来型-vs-ソブリン相互運用性)

| 特徴          | 従来のロールアップ       | ソブリンロールアップ           |
| ----------- | --------------- | -------------------- |
| ブリッジ権限      | L1決済レイヤー        | 自己主権検証               |
| ブリッジのカスタマイズ | 限定的またはなし        | 完全にカスタマイズ可能          |
| プロトコルサポート   | 独自、単一ブリッジ       | 複数（IBC、ZKブリッジ、カスタム）  |
| 資産タイプ       | 多くの場合トークンに限定    | トークン、NFT、任意のデータパケット  |
| セキュリティモデル   | L1ブリッジコントラクトを継承 | ライトクライアントまたは有効性証明の選択 |
| アップグレードパス   | L1ガバナンスに依存      | 独立—ロールアップレベルのガバナンス   |

***

## ソブリンロールアップのツーリングとエコシステム

[「ソブリンロールアップのツーリングとエコシステム」セクションへのリンク](#ソブリンロールアップのツーリングとエコシステム)

| フレームワーク/コンポーネント   | 相互運用性機能                                                                                                            |
| ----------------- | ------------------------------------------------------------------------------------------------------------------ |
| **Rollkit**       | プラグアンドプレイのモジュラーロールアップフレームワーク。ネイティブIBC配線。Tendermint、Celestia、Sunrise DAバックエンドをサポート。                                 |
| **Sovereign SDK** | ゼロ知識または不正証明ソブリンチェーン用のRustツールキット。汎用IBCライトクライアントトレイトとリレーヤーフックを同梱。                                                    |
| **Sunrise DA**    | Proof of Liquidity (PoL)によるデータ可用性を提供。ソブリンロールアップがSunrise上に構築されると、より広範なIBCメッシュへの接続性を継承できるようにIBCインターフェースを公開。          |
| **アプリケーションパターン**  | *クロスチェーンDeFi*（オムニ流動性プール）、*相互運用可能なゲーム*（資産のポータビリティ）、*マルチチェーンアイデンティティ*（DIDパケット）、*チェーンに依存しないDAO*（複数のロールアップにまたがるガバナンス）。 |

# 💲 USDrise

> USDriseは、Sunriseプロトコルのネイティブステーブルコインで、nobleのUSDNをラップすることで発行されます。このドキュメントでは、USDriseの概要、その特徴、そしてSunriseエコシステムにどのように統合されるかについて説明します。

USDriseは、Sunriseプロトコルのネイティブステーブルコインで、nobleのUSDNをラップすることで発行されます。このドキュメントでは、USDriseの概要、その特徴、そしてSunriseエコシステムにどのように統合されるかについて説明します。

## 概要

[「概要」セクションへのリンク](#概要)

USDriseは、Sunriseプロトコル内で安定した信頼性の高い交換媒体として設計されています。米ドルとの1:1のペッグを維持することを目指しています。

USDriseを取得するには、主に2つの方法があります。

1. **スワップ:** ユーザーは、Sunriseエコシステム内の`x/swap`モジュールを通じて、USDC、USDN、RISEなどの他のトークンをスワップすることでもUSDriseを取得できます。
2. **ミント:** USDriseの発行と焼却は`x/stable`モジュールによって管理されており、これには承認されたコントラクトを介した対話が必要です。ユーザーは、1 USDN = 1 USDriseの固定為替レートでUSDNをデポジットすることでUSDriseをミントできます。このプロセスにより、トークン供給の透明性と管理が保証されます。

`x/stable`モジュールの詳細については、[x/stableモジュールのドキュメント](/learn/sunrise/stable)を参照してください。

## 主な特徴

[「主な特徴」セクションへのリンク](#主な特徴)

* **取引手数料:** Sunriseプロトコル内のすべての取引手数料はUSDriseで支払われるため、ネットワーク経済の中心的な要素となっています。
* **利回りの生成:** USDriseはUSDNで担保されているため、RISEおよびvRISEのステーカーに分配される利回りを生み出します。

## 手数料の仕組みと分配

[「手数料の仕組みと分配」セクションへのリンク](#手数料の仕組みと分配)

USDriseは、Sunriseエコシステム内の取引手数料の主要なトークンとして機能します。収集された手数料は、原資産であるUSDNからの利回りとともにステークホルダーに分配され、持続可能な経済ループを生み出します。

```
graph TD;
    subgraph 収益の収集
        User -- "USDriseで手数料を支払う" --> Transaction;
        Transaction -- "手数料を収集" --> FeeCollector["FeeCollectorモジュール"];
        USDN_Yield["USDNの利回り"] -- "蓄積" --> FeeCollector;
    end

    subgraph 手数料と利回りの処理
        FeeCollector -- "焼却用の手数料の一部" --> SwapModule;
        SwapModule -- "USDriseをRISEにスワップ" --> Burn[("🔥 RISEを焼却")];
        FeeCollector -- "残りの資金（手数料＋利回り）" --> Distribution;
        Distribution -- "報酬" --> vRISE_Stakers["vRISEステーカー"];
        Distribution -- "報酬" --> RISE_Stakers["RISEステーカー"];
    end

    style Burn fill:#ffcccc,stroke:#333,stroke-width:2px
```

### フローの内訳

[「フローの内訳」セクションへのリンク](#フローの内訳)

1. **収益の収集:** `FeeCollector`モジュールアカウントは、主に2つの資金源から資金を蓄積します。

   * **取引手数料:** ユーザーは**USDrise**で取引手数料を支払います。
   * **USDNの利回り:** USDriseを裏付ける原資産であるUSDNから生じる利回りも`FeeCollector`に向けられます。

2. **焼却メカニズム:** `x/fee`モジュールの`burn_ratio`パラメータに基づき、収集された**手数料**の一部が**RISE**にスワップされ、その後焼却されます。これはRISEのデフレメカニズムとして機能します。

3. **報酬の分配:** `FeeCollector`内の残りのすべての資金（焼却されなかった手数料の一部と、すべてのUSDNの利回り）は、**vRISE**と**RISE**の両方のステーカーに報酬として分配され、ガバナンスとネットワークセキュリティへの参加を奨励します。

このプロセスにより、ネットワークの利用がネイティブトークンの価値に直接貢献し、最もコミットした参加者に報酬が与えられることが保証されます。

`x/fee`モジュールの詳細については、[x/fee](/learn/sunrise/fee)を参照してください。

## USDNについて

[「USDNについて」セクションへのリンク](#usdnについて)

USDriseは、nobleネットワークのステーブルコインであるNoble Dollar (USDN)によって裏付けられています。ユーザーはUSDNに関連する仕組みとリスクを理解することが重要です。情報に基づいた意思決定を行うために、ユーザー自身でUSDNについて調査することを強くお勧めします。

Noble Dollar (USDN)は、構成可能な利回りの基盤の上に構築されたステーブルコインです。USDNはM^0プロトコルを活用して、短期米国財務省短期証券で担保されたステーブルコインの利回りを提供します。USDNはモジュラーエコシステム向けに特別に構築されており、カスタマイズ可能でプログラム可能かつ透明な方法で利回りを向けることができるように構成されています。

詳細については、Nobleの公式ドキュメントを参照してください：[Noble Dollar (USDN)](https://www.noble.xyz/usdn)

## 関連ドキュメント

[「関連ドキュメント」セクションへのリンク](#関連ドキュメント)

* [**x/stableモジュール**](/learn/sunrise/stable)

# Sunriseネットワーク

> このセクションでは、Sunrise Layerチームによって運営されている公式ネットワークの詳細について説明します。

このセクションでは、Sunrise Layerチームによって運営されている公式ネットワークの詳細について説明します。

* [メインネット](/run-a-sunrise-node/networks/mainnet)
* [テストネット](/run-a-sunrise-node/networks/testnet)

# Sunriseメインネット

> Sunrise のメインネットワークです。実価値のあるトークンを使います。

危険

Cosmos Sunrise のメインネットは **2026年10月5日 12:00 UTC**、v2.0.0 アップグレード（ブロック高 **6,504,000**）で終了します。保有資産は Sunrise Edge に引き継がれます。終了前に資金を移動する必要はありません。

詳細: [Sunrise Edge](https://sunriselayer.io/)

Sunrise のメインネットワークです。実価値のあるトークンを使います。

## メインネットの詳細

[「メインネットの詳細」セクションへのリンク](#メインネットの詳細)

[sunrise-1 ネットワーク設定](https://github.com/sunriselayer/network/tree/main/sunrise-1)

[ジェネシスファイル](https://github.com/sunriselayer/network/blob/main/sunrise-1/genesis.json)

[スナップショット（Polkachu 提供）](https://www.polkachu.com/tendermint_snapshots/sunrise)

| 詳細   | 値                                                    |
| ---- | ---------------------------------------------------- |
| RPC  | <https://a.consensus.sunrise-1.sunriselayer.io>      |
| REST | <https://a.consensus.sunrise-1.sunriselayer.io:1318> |

## サードパーティのサービス

[「サードパーティのサービス」セクションへのリンク](#サードパーティのサービス)

公式エンドポイントに加え、複数のサードパーティが Sunrise メインネット向けの公開エンドポイントやその他のサービスを提供しています。RPC、REST、gRPC、エクスプローラーのより包括的な一覧は [Chain Registry](https://github.com/cosmos/chain-registry/blob/master/sunrise/chain.json) を参照してください。

| プロバイダー        | ノードサービス（スナップショット、ピアなど）                             |
| ------------- | -------------------------------------------------- |
| Polkachu      | <https://www.polkachu.com/networks/sunrise>        |
| NodeStake     | <https://nodestake.org/sunrise>                    |
| Krews         | <https://sunrise-services.krews.xyz/sunrise>       |
| MekongLabs    | <https://mekonglabs.tech/services/mainnet/sunrise> |
| Synergy Nodes | <https://www.synergynodes.com/service/sunrise>     |

## フロントエンド

[「フロントエンド」セクションへのリンク](#フロントエンド)

| 名前                 | URL                                 |
| ------------------ | ----------------------------------- |
| APP（Tx ポータル）       | <https://app.sunriselayer.io>       |
| Risescan（エクスプローラー） | <https://risescan.sunriselayer.io/> |

## メインネットソフトウェア

[「メインネットソフトウェア」セクションへのリンク](#メインネットソフトウェア)

提案とコミュニティを確認してください。セットアップは [sunrise-1](https://github.com/sunriselayer/network/tree/main/sunrise-1) を参照してください。 ジェネシスバイナリは `v1.0.0` です。

[リリース済みバイナリ](https://github.com/sunriselayer/sunrise/releases)

### ネットワークアップグレード

[「ネットワークアップグレード」セクションへのリンク](#ネットワークアップグレード)

| 名前                                                                    | 高さ     |
| --------------------------------------------------------------------- | ------ |
| [v1.1.0](https://github.com/sunriselayer/sunrise/releases/tag/v1.1.0) | 234700 |
| [v1.2.0](https://github.com/sunriselayer/sunrise/releases/tag/v1.2.0) | 765000 |

## IBC 設定

[「IBC 設定」セクションへのリンク](#ibc-設定)

| 宛先チェーン        | 宛先ポート      | 宛先チャネル       | 送信元チェーン     | 送信元ポート     | 送信元チャネル   |
| ------------- | ---------- | ------------ | ----------- | ---------- | --------- |
| `noble-1`     | `transfer` | channel-168  | `sunrise-1` | `transfer` | channel-0 |
| `cosmoshub-4` | `transfer` | channel-1421 | `sunrise-1` | `transfer` | channel-1 |

## IBC デノム

[「IBC デノム」セクションへのリンク](#ibc-デノム)

| 名前   | チェーン          | オリジナルデノム                                                               | IBC デノム                                                                | 小数点以下桁数 |
| ---- | ------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------- | ------- |
| USDN | `noble-1`     | `uusdn`                                                                | `ibc/A7AD825A4B48DDA0138D118655E60100D22A4D690C45B95221520B58C9A64B63` | 6       |
| USDC | `noble-1`     | `uusdc`                                                                | `ibc/8E27BA2D5493AF5636760E354E46004562C46AB7EC0CC4C1CA14E9E20E2545B5` | 6       |
| USDY | `noble-1`     | `ausdy`                                                                | `ibc/AAF322A78A0E34B76CDA05BA9AE96DC1521F9E103EC576AB9931116B2AB8C26B` | 18      |
| ATOM | `cosmoshub-4` | `uatom`                                                                | `ibc/C4CFF46FD6DE35CA4CF4CE031E643C8FDC9BA4B99AE598E9B0ED98FE3A2319F9` | 6       |
| USDT | `cosmoshub-4` | `ibc/E7E51FFF94A8B55BE84CEB0345E5CAF0A5DAEB374C6806CE908098B8996C7782` | `ibc/D4FF12988C31AD8E3D2555621F95C7EB2B6FBAAD2F9487FB11A2A8BBB004B4B3` | 6       |
| WBTC | `cosmoshub-4` | `ibc/D742E8566B0B8CC8F569D950051C09CF57988A88F0E45574BFB3079D41DE6462` | `ibc/0E293A7622DC9A6439DB60E6D234B5AF446962E27CA3AB44D0590603DFF6968E` | 8       |
| WETH | `cosmoshub-4` | `ibc/C0B53D3D23827AE38058BED0BDCD554229278AF530A8D265FCF6DFF7C4B2ADFF` | `ibc/694A6B26A43A2FBECCFFEAC022DEACB39578E54207FDD32005CD976B57B98004` | 18      |

## メインネットで USDN から USDrise をミントする

[「メインネットで USDN から USDrise をミントする」セクションへのリンク](#メインネットで-usdn-から-usdrise-をミントする)

USDrise をミントするコントラクトのアドレスは `sunrise14hj2tavq8fpesdwxxcu44rty3hh90vhujrvcmstl4zr3txmfvw9s2v9j75` です。 USDN を使って同量の USDrise をミントできます。

```bash
sunrised tx wasm execute sunrise14hj2tavq8fpesdwxxcu44rty3hh90vhujrvcmstl4zr3txmfvw9s2v9j75 \
    '{"mint":{"amount":"1000000","recipient":"[your-address]"}}' \
--amount 1000000ibc/A7AD825A4B48DDA0138D118655E60100D22A4D690C45B95221520B58C9A64B63 \
--from=[your-account] --chain-id=sunrise-1\
--gas-prices=0.025uusdrise --gas-adjustment=1.5 --gas=auto -y
```

## メインネットで USDrise を USDN に償還する

[「メインネットで USDrise を USDN に償還する」セクションへのリンク](#メインネットで-usdrise-を-usdn-に償還する)

USDrise を USDN に償還するコントラクトのアドレスは `sunrise14hj2tavq8fpesdwxxcu44rty3hh90vhujrvcmstl4zr3txmfvw9s2v9j75` です。 USDrise を使って同量の USDN を償還できます。

```bash
sunrised tx wasm execute sunrise14hj2tavq8fpesdwxxcu44rty3hh90vhujrvcmstl4zr3txmfvw9s2v9j75 \
'{"burn":{"amount":"1000000"}}' \
--amount 1000000uusdrise \
--from=[your-account] --chain-id=sunrise-1 \
--gas-prices=0.025uusdrise --gas-adjustment=1.5 --gas=auto -y
```

# Sunriseテストネット

> 重要: これはテストネットです。このネットワーク上のトークンはテスト目的のみであり、現実世界での価値はありません。ネットワークの状態は、バグ修正やアップグレードのためにいつでもリセットされる可能性があり、その永続性は保証されません。

## Dawnテストネット

[「Dawnテストネット」セクションへのリンク](#dawnテストネット)

注意

**重要**: これはテストネットです。このネットワーク上のトークンはテスト目的のみであり、現実世界での価値はありません。ネットワークの状態は、バグ修正やアップグレードのためにいつでもリセットされる可能性があり、その永続性は保証されません。

このネットワークは、メインネットのいくつかの機能をテストするために使用されます。

### Dawnテストネットの詳細

[「Dawnテストネットの詳細」セクションへのリンク](#dawnテストネットの詳細)

[dawn-1ネットワークの詳細](https://github.com/sunriselayer/network/tree/main/dawn-1)

| 詳細   | 値                                         |
| ---- | ----------------------------------------- |
| RPC  | <https://sunrise-dawn-1.cauchye.com>      |
| REST | <https://sunrise-dawn-1.cauchye.com:1318> |

### Dawnテストネットのフロントエンド

[「Dawnテストネットのフロントエンド」セクションへのリンク](#dawnテストネットのフロントエンド)

| 名前                 | URL                                       |
| ------------------ | ----------------------------------------- |
| Dawn APP（Txポータル）   | <https://dawn-1.app.sunriselayer.io>      |
| Risescan（エクスプローラー） | <https://dawn-1.risescan.sunriselayer.io> |

### Dawnテストネットのソフトウェア

[「Dawnテストネットのソフトウェア」セクションへのリンク](#dawnテストネットのソフトウェア)

私たちの提案とコミュニティを確認してください。設定については[dawn-1 Github](https://github.com/sunriselayer/network/tree/main/dawn-1)を参照してください。

[リリース済みバイナリ](https://github.com/sunriselayer/sunrise/releases)

### Dawnテストネットの Faucet

[「Dawnテストネットの Faucet」セクションへのリンク](#dawnテストネットの-faucet)

RISE と USDrise の Faucet は Dawn テストネットで利用できます。 この Faucet は Dawn APP 内で提供されています。

使用するには、イーサリアムメインネットに少なくとも0.01 ETHを持つウォレットで署名する必要があります。費用はかかりません。

### DawnテストネットでUSDNからUSDriseをミントする

[「DawnテストネットでUSDNからUSDriseをミントする」セクションへのリンク](#dawnテストネットでusdnからusdriseをミントする)

USDriseをミントするためのコントラクトのアドレスは`sunrise1suhgf5svhu4usrurvxzlgn54ksxmn8gljarjtxqnapv8kjnp4nrs4ef8ka`です。 USDNを使用して同量のUSDriseをミントできます。

```bash
sunrised tx wasm execute sunrise1suhgf5svhu4usrurvxzlgn54ksxmn8gljarjtxqnapv8kjnp4nrs4ef8ka \
'{"mint":{"amount":"1000000","recipient":"[your-address]"}}' \
--amount 1000000ibc/A7AD825A4B48DDA0138D118655E60100D22A4D690C45B95221520B58C9A64B63 \
--from=[your-account] --gas-prices=0.025uusdrise --gas-adjustment=1.2 --gas=auto -y
```

### DawnテストネットのIBC設定

[「DawnテストネットのIBC設定」セクションへのリンク](#dawnテストネットのibc設定)

| 宛先チェーン     | 宛先ポート      | 宛先チャネル        | 送信元チェーン  | 送信元ポート     | 送信元チャネル     |
| ---------- | ---------- | ------------- | -------- | ---------- | ----------- |
| `grand-1`  | `transfer` | `channel-554` | `dawn-1` | `transfer` | `channel-0` |
| `provider` | `transfer` | `channel-493` | `dawn-1` | `transfer` | `channel-1` |

`grand-1`は現在のNobleテストネット[Grand-1 Testnet](https://www.noble.xyz/dev-hub)です。 [Noble Testnet chain-registry](https://github.com/cosmos/chain-registry/tree/master/testnets/nobletestnet)

`provider`は現在のCosmosHubテストネット[Cosmos ICS Provider Testnet](https://hub.cosmos.network/main/hub-tutorials/join-testnet)です。 [provider chain-registry](https://github.com/cosmos/chain-registry/tree/master/testnets/cosmosicsprovidertestnet)

## Dawnテストネットの IBC デノム

[「Dawnテストネットの IBC デノム」セクションへのリンク](#dawnテストネットの-ibc-デノム)

| 名前   | チェーン       | オリジナルデノム | IBC デノム                                                                |
| ---- | ---------- | -------- | ---------------------------------------------------------------------- |
| USDN | `grand-1`  | `uusdn`  | `ibc/A7AD825A4B48DDA0138D118655E60100D22A4D690C45B95221520B58C9A64B63` |
| USDC | `grand-1`  | `uusdc`  | `ibc/8E27BA2D5493AF5636760E354E46004562C46AB7EC0CC4C1CA14E9E20E2545B5` |
| ATOM | `provider` | `uatom`  | `ibc/C4CFF46FD6DE35CA4CF4CE031E643C8FDC9BA4B99AE598E9B0ED98FE3A2319F9` |

## 非推奨のテストネット

[「非推奨のテストネット」セクションへのリンク](#非推奨のテストネット)

### DAテストネット

[「DAテストネット」セクションへのリンク](#daテストネット)

注意

`sunrise-test-da-1`、`sunrise-test-da-2`、`sunrise-test-da-3`、`sunrise-test-da-4`、`sunrise-test-da-5`は非推奨です。代わりに`dawn-1`を使用してください。

このネットワークは、メインネットのデータ可用性機能をテストするために使用されます。

### インセンティブ付きテストネット0.2

[「インセンティブ付きテストネット0.2」セクションへのリンク](#インセンティブ付きテストネット02)

注意

**重要**: このテストネットは2025年5月21日0:00 UTCに終了しました。 現在、DA 3テストネットのみが稼働しています。

このネットワークは、メインネットでの操作をテストするために使用されます。通常、メインネットと同じ環境が提供されますが、トークンに価値はありません。

### インセンティブ付きテストネット0.2の詳細

[「インセンティブ付きテストネット0.2の詳細」セクションへのリンク](#インセンティブ付きテストネット02の詳細)

[sunrise-test-0.2ネットワークの詳細](https://github.com/sunriselayer/network/tree/main/sunrise-test-0.2)

| 詳細   | 値                                                |
| ---- | ------------------------------------------------ |
| RPC  | <https://a-node.sunrise-test-1.cauchye.net>      |
| REST | <https://a-node.sunrise-test-1.cauchye.net:1318> |

場合によってはb-dも稼働しています。[RiseScan](https://testnet.risescan.sunriselayer.io/)で確認してください。

### インセンティブ付きテストネット0.2のソフトウェア

[「インセンティブ付きテストネット0.2のソフトウェア」セクションへのリンク](#インセンティブ付きテストネット02のソフトウェア)

私たちの提案とコミュニティを確認してください。設定については[sunrise-test-0.2](https://github.com/sunriselayer/network/tree/main/sunrise-test-0.2)を参照してください。 現在、テストネットはブロックチェーンの互換性のためにv0.2.xバイナリを使用しています。

[リリース済みバイナリ](https://github.com/sunriselayer/sunrise/releases)

# リソース

> cosmos-sdk v0.50.0以降、デフォルトでは内部接続のみが許可されます。 公開するには、必ず次のように書き換えてください。 0.0.0.0:9090, tcp://0.0.0.0:1317, tcp://0.0.0.0:26657

## ポート

[「ポート」セクションへのリンク](#ポート)

### コンセンサス

[「コンセンサス」セクションへのリンク](#コンセンサス)

| ポート   | プロトコル | 詳細   | デフォルト値                  | 場所                              |
| ----- | ----- | ---- | ----------------------- | ------------------------------- |
| 9090  | TCP   | gRPC | `localhost:9090`        | `~/.sunrise/config/app.toml`    |
| 1317  | TCP   | REST | `tcp://localhost:1317`  | `~/.sunrise/config/app.toml`    |
| 26657 | TCP   | RPC  | `tcp://127.0.0.1:26657` | `~/.sunrise/config/config.toml` |

注記

cosmos-sdk v0.50.0以降、デフォルトでは内部接続のみが許可されます。 公開するには、必ず次のように書き換えてください。 `0.0.0.0:9090`, `tcp://0.0.0.0:1317`, `tcp://0.0.0.0:26657`

### データ可用性

[「データ可用性」セクションへのリンク](#データ可用性)

| ポート   | プロトコル   | 詳細         | デフォルトで有効 | フラグ                     |
| ----- | ------- | ---------- | -------- | ----------------------- |
| 2121  | TCP/UDP | P2P        | true     | N/A                     |
| 26658 | HTTP    | RPC        | true     | `--rpc.port string`     |
| 26659 | HTTP    | RESTゲートウェイ | false    | `--gateway.port string` |

# 環境

> これはSunriseソフトウェアを実行するための開発環境です。この環境は、開発、バイナリのビルド、およびノードの実行に使用できます。

これはSunriseソフトウェアを実行するための開発環境です。この環境は、開発、バイナリのビルド、およびノードの実行に使用できます。

## 依存関係のインストール

[「依存関係のインストール」セクションへのリンク](#依存関係のインストール)

### Ubuntu

[「Ubuntu」セクションへのリンク](#ubuntu)

```bash
sudo apt update
sudo apt install -y tar wget aria2 clang pkg-config libssl-dev jq build-essential git make ncdu
```

### Golangのインストール

[「Golangのインストール」セクションへのリンク](#golangのインストール)

Golangをインストールします。

```bash
wget https://go.dev/dl/go1.24.2.linux-amd64.tar.gz
sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.24.2.linux-amd64.tar.gz
rm go1.24.2.linux-amd64.tar.gz
echo "export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin" >> $HOME/.bashrc
source $HOME/.bashrc
```

Goのバージョンを確認します。

```bash
go version
```

# アップグレード

> Sunriseはオンチェーンガバナンスによってアップグレードされます。

Sunriseはオンチェーンガバナンスによってアップグレードされます。

## ソフトフォーク

[「ソフトフォーク」セクションへのリンク](#ソフトフォーク)

ソフトフォークの場合、チェーンIDは変更されず、バイナリのバージョンが変更されます。また、アップグレードハンドラがプロセスを処理します。詳細は各アップグレード提案に記載されます。

Cosmovisorを実行している場合、自動アップグレードが利用可能です。 設定方法については、[Cosmovisorチュートリアル](/run-a-sunrise-node/types/consensus/setup-cosmovisor)を参照してください。

CosmoVisorを使用しない場合は、手動でバイナリを変更してください。

## ハードフォーク

[「ハードフォーク」セクションへのリンク](#ハードフォーク)

ソフトフォークでは対応できない変更を適用するために、ハードフォークが実行される場合があります。

`genesis.json`が変更され、新しいブロックは高さ1から始まります。 多くの場合、チェーンIDが変更されます。

## テストネット

[「テストネット」セクションへのリンク](#テストネット)

ジェネシスからチェーンを同期する場合、このガイドに従い、ジェネシス時点で最新のバイナリバージョンを使用してください。 <https://github.com/sunriselayer/network/tree/main/dawn-1>

## メインネット

[「メインネット」セクションへのリンク](#メインネット)

ジェネシスからチェーンを同期する場合、このガイドに従い、ジェネシス時点で最新のバイナリバージョンを使用してください。 <https://github.com/sunriselayer/network/tree/main/sunrise-1>

現在使用されているバイナリのバージョンについては、[GitHub](https://github.com/sunriselayer/sunrise/releases)の最新リリースを参照してください。

# Sunriseでのノード実行の概要

> Sunrise[ネットワーク](/run-a-sunrise-node/networks)に参加するには、さまざまな方法があります。 Sunriseノードオペレーターは、ネットワーク上でいくつかのオプションを実行できます。

Sunrise[ネットワーク](/run-a-sunrise-node/networks)に参加するには、さまざまな方法があります。 Sunriseノードオペレーターは、ネットワーク上でいくつかのオプションを実行できます。

## コンセンサス

[「コンセンサス」セクションへのリンク](#コンセンサス)

* [バリデーターノード](/run-a-sunrise-node/types/consensus/validator-node): このタイプのノードは、ブロックを作成し、投票することによってコンセンサスに参加します。
* [フルコンセンサスノード](/run-a-sunrise-node/types/consensus/full-consensus-node): ブロックチェーンの履歴を同期するためのsunrise-appフルノード。

## 要件

[「要件」セクションへのリンク](#要件)

| タイプ      | CPU | アーキテクチャ | メモリ  | ディスク       | 帯域幅    |
| -------- | --- | ------- | ---- | ---------- | ------ |
| バリデーター   | 6コア | x86\_64 | 8 GB | 500 GB SSD | 1 Gbps |
| フルコンセンサス | 4コア | x86\_64 | 8 GB | 250 GB SSD | 1 Gbps |

各チュートリアルガイドを参照して、各ノードの設定方法について詳しく学ぶことができます。

# コンセンサスノード

> データ可用性レイヤー: 標準的なコンセンサスタスクに加えて、Sunriseのバリデーターノードはデータ可用性（DA）レイヤーのデータを検証する責任があります。これには、メインのsunrisedプロセスと並行して追加のデーモンを実行する必要があります。詳細は[バリデータードキュメント](/build/validators)を参照してください。

## 概要

[「概要」セクションへのリンク](#概要)

* [バリデーターノード](/run-a-sunrise-node/types/consensus/validator-node): このタイプのノードは、ブロックを生成し、投票することによってコンセンサスに参加します。
* [フルコンセンサスノード](/run-a-sunrise-node/types/consensus/full-consensus-node): ブロックチェーンの履歴を同期するためのsunrise-appフルノード。

注記

**データ可用性レイヤー**: 標準的なコンセンサスタスクに加えて、Sunriseのバリデーターノードはデータ可用性（DA）レイヤーのデータを検証する責任があります。これには、メインの`sunrised`プロセスと並行して追加のデーモンを実行する必要があります。詳細は[バリデータードキュメント](/build/validators)を参照してください。

### 要件

[「要件」セクションへのリンク](#要件)

| タイプ      | CPU | アーキテクチャ | メモリ  | ディスク       | 帯域幅    |
| -------- | --- | ------- | ---- | ---------- | ------ |
| バリデーター   | 6コア | x86\_64 | 8 GB | 500 GB SSD | 1 Gbps |
| フルコンセンサス | 4コア | x86\_64 | 8 GB | 250 GB SSD | 1 Gbps |

# フルコンセンサスノード

> フルコンセンサスノードを使用すると、Sunriseコンセンサスレイヤーでブロックチェーンの履歴を同期できます。

フルコンセンサスノードを使用すると、Sunriseコンセンサスレイヤーでブロックチェーンの履歴を同期できます。

## チェーンのアップグレード

[「チェーンのアップグレード」セクションへのリンク](#チェーンのアップグレード)

チェーンのアップグレードを効率化し、ダウンタイムを最小限に抑えるために、[Cosmovisor](https://docs.cosmos.network/main/build/tooling/cosmovisor)を設定してノードを管理することをお勧めします。

[Cosmovisorチュートリアル](/run-a-sunrise-node/types/consensus/setup-cosmovisor)に従ってください。

オンチェーンアップグレードを自動化するには、次のオプションを設定します。

```yml
DAEMON_ALLOW_DOWNLOAD_BINARIES=true
```

## バックアップ

[「バックアップ」セクションへのリンク](#バックアップ)

最近のバージョンのCosmovisorを使用している場合、デフォルトの設定では、アップグレードを適用する前に状態のバックアップが作成されます。これは[環境フラグ](https://docs.cosmos.network/main/build/tooling/cosmovisor#command-line-arguments-and-environment-variables)を使用してオフにすることができます。

## アラートと監視

[「アラートと監視」セクションへのリンク](#アラートと監視)

アラートと監視も望ましいため、ソリューションを検討し、自分の設定に合ったものを見つけることをお勧めします。Prometheusは標準で利用可能で、さまざまなオープンソースツールがあります。

## ハードウェア要件

[「ハードウェア要件」セクションへのリンク](#ハードウェア要件)

バリデーターノードを実行するために、以下の最低ハードウェア要件が推奨されます。

* メモリ：8 GB RAM（最小）
* CPU：4コア
* ディスク：250 GB SSDストレージ
* 帯域幅：ダウンロード1 Gbps / アップロード1 Gbps

プルーニングを使用しない場合は、アーカイブノードを実行しており、500 GBのSSDストレージを推奨します。

## 依存関係

[「依存関係」セクションへのリンク](#依存関係)

チュートリアルはUbuntu 22.04（LTS）で行われています。[環境チュートリアル](/run-a-sunrise-node/resources/environment)に従ってください。

## フルコンセンサスノードの実行

[「フルコンセンサスノードの実行」セクションへのリンク](#フルコンセンサスノードの実行)

### インストール

[「インストール」セクションへのリンク](#インストール)

[Go](https://go.dev/doc/install) 1.24.2をインストールします。

```bash
git clone https://github.com/sunriselayer/sunrise.git
cd sunrise
git checkout $TAG
make install
```

注記

ジェネシスから同期する場合は、ジェネシス時点のバイナリバージョンを使用してください。 スナップショットを使用している場合は、スナップショットの高さを確認し、その高さのバイナリを使用する必要があります。

詳細は[アップグレードドキュメント](/run-a-sunrise-node/resources/upgrade)を参照してください。

### 初期化

[「初期化」セクションへのリンク](#初期化)

`chain-id`と`moniker`を設定します。`moniker`はノードの名前です。

```bash
CHAIN_ID=sunrise-1 // mainnet
MONIKER="node-name"
sunrised init "$MONIKER" --chain-id $CHAIN_ID
```

これにより、`~/.sunrise/config/`に以下のファイルが生成されます。

* `genesis.json`
* `node_key.json`
* `priv_validator_key.json`

## ジェネシスファイルのダウンロード

[「ジェネシスファイルのダウンロード」セクションへのリンク](#ジェネシスファイルのダウンロード)

[Github](https://github.com/sunriselayer/network)で現在実行中のネットワークの`genesis.json`を確認してください。

例：メインネットの場合：

```bash
rm ~/.sunrise/config/genesis.json
curl -L https://raw.githubusercontent.com/sunriselayer/network/main/sunrise-1/genesis.json -o ~/.sunrise/config/genesis.json
```

### 最低ガス価格の設定

[「最低ガス価格の設定」セクションへのリンク](#最低ガス価格の設定)

RPCノードおよびバリデーターノードについて、以下の最低ガス価格の設定を推奨します。私たちはパーミッションレスのWasmチェーンであるため、この設定はコントラクトスパムや潜在的なWasmコントラクトの攻撃ベクターから保護するのに役立ちます。

`\$HOME/.sunrise/config/app.toml`で、最低ガス価格を設定してください。

```bash
sed -i.bak -e "s/^minimum-gas-prices *=.*/minimum-gas-prices = \"0.025uusdrise\"/" $HOME/.sunrise/config/app.toml
```

注意

ガス価格を高く設定しすぎないでください。バリデーターの場合、提案したブロックにトランザクションが含まれなくなります。これにより、ネットワーク全体が処理できるトランザクションの数が減少します。

### オプション：シードと永続的ピアの設定

[「オプション：シードと永続的ピアの設定」セクションへのリンク](#オプションシードと永続的ピアの設定)

* シード

「シード」は、新しく参加するバリデーターが最初に接続すべき他のバリデーターのリストを提供します。 バリデーターがネットワークに接続すると、主に`persistent_peers`に接続を依存するため、`seeds`の重要性は低下します。

```bash
SEEDS=$(curl -sL https://raw.githubusercontent.com/sunriselayer/network/main/sunrise-1/seeds.txt | tr '\n' ',')
echo $SEEDS
sed -i.bak -e "s/^seeds *=.*/seeds = \"$SEEDS\"/" $HOME/.sunrise/config/config.toml
```

* 永続的ピア

「永続的ピア」は、バリデーターが常に接続を維持すべき信頼できるバリデーターのリストです。 `persistent_peers`にリストされているバリデーターへの接続は、ネットワークの安定性を維持するために優先されます。

```bash
PERSISTENT_PEERS=$(curl -sL https://raw.githubusercontent.com/sunriselayer/network/main/sunrise-1/peers.txt | tr '\n' ',')
echo $PERSISTENT_PEERS
sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$PERSISTENT_PEERS\"/" $HOME/.sunrise/config/config.toml
```

### オプション：追加設定

[「オプション：追加設定」セクションへのリンク](#オプション追加設定)

必要に応じて、`\$HOME/.sunrise/config/app.toml`の設定ファイルを編集してください。

* `enable`は、APIサーバーを有効にするかどうかを定義します。

```bash
sed -i '/\[api\]/,+3 s/enable = false/enable = true/' $HOME/.sunrise/config/app.toml;
```

* `EnableUnsafeCORS`は、CORSを有効にするかどうかを定義します（安全ではないため、自己責任で使用してください）。

```bash
sed -i 's/enabled-unsafe-cors = false/enabled-unsafe-cors = true/' $HOME/.sunrise/config/app.toml;
```

* デフォルトでは、RPCとRESTは公開されていないため、公開ノードにしたい場合は、次のように設定してください。

```bash
sed -i 's/address = "localhost:9090"/address = "0.0.0.0:9090"/' $HOME/.sunrise/config/app.toml;
sed -i 's#address = "tcp://localhost:1317"#address = "tcp://0.0.0.0:1317"#' $HOME/.sunrise/config/app.toml;
sed -i 's#laddr = "tcp://127.0.0.1:26657"#laddr = "tcp://0.0.0.0:26657"#' $HOME/.sunrise/config/config.toml;
```

### ストレージとプルーニングの設定

[「ストレージとプルーニングの設定」セクションへのリンク](#ストレージとプルーニングの設定)

コンセンサスノードをsunrise-nodeブリッジノードに接続する場合は、トランザクションインデックスを有効にし、すべてのブロックデータを保持する必要があります。これは、`config.toml`で次の設定を行うことで実現できます。

#### トランザクションインデックスの有効化

[「トランザクションインデックスの有効化」セクションへのリンク](#トランザクションインデックスの有効化)

```toml
indexer = "kv"
```

#### すべてのブロックデータの保持

[「すべてのブロックデータの保持」セクションへのリンク](#すべてのブロックデータの保持)

そして、`app.toml`では、`min-retain-blocks`はデフォルト設定のままである必要があります。

```toml
min-retain-blocks = 0
```

#### 過去のステートへのアクセス

[「過去のステートへのアクセス」セクションへのリンク](#過去のステートへのアクセス)

過去の特定の高さでのウォレットの残高などを照会したい場合は、`app.toml`で`pruning = "nothing"`に設定したアーカイブノードを実行する必要があります。この設定はリソースを多く消費し、かなりのストレージが必要になることに注意してください。

```toml
pruning = "nothing"
```

ストレージの要件を節約したい場合は、`app.toml`で`pruning = "everything"`を使用してすべてをプルーニングすることを検討してください。

```toml
pruning = "everything"
```

### ローカルキーペアを作成（または復元）する

[「ローカルキーペアを作成（または復元）する」セクションへのリンク](#ローカルキーペアを作成または復元する)

バリデーター用に新しいキーペアを作成するか、既存のウォレットを復元します。

```bash
# 新しいキーペアを作成
sunrised keys add <your-key>
# ニーモニックシードフレーズで既存のsunriseウォレットを復元します。
# ニーモニックシードを入力するように求められます。
sunrised keys add <your-key> --recover
# キーストアで公開アドレスをクエリします
sunrised keys show <your-key> -a
```

`<your-key>`を任意のキー名に置き換えてください。

### RISEトークンを取得する

[「RISEトークンを取得する」セクションへのリンク](#riseトークンを取得する)

バリデーターにボンドするためにいくつかのvRISEトークンが必要になります（手数料のためにいくつかのRISEトークンも必要です）。アクティブセットに入るには、十分なトークンが必要です。

### コンセンサスノードの起動

[「コンセンサスノードの起動」セクションへのリンク](#コンセンサスノードの起動)

Cosmovisorを設定し、ノードを起動するための手順に従ってください。 [Cosmovisorチュートリアル](/run-a-sunrise-node/types/consensus/setup-cosmovisor)を参照してください。

注記

Cosmovisorの使用は完全に任意です。Cosmovisorを使用しない場合は、バリデーターがダウンタイムに陥ったり、ジェイルされたりしないように、ネットワークのアップグレードに必ず対応する必要があります。

Cosmovisorを使用しない場合は、次のコマンドを実行してください。

```bash
sunrised start
```

### ノードの同期

[「ノードの同期」セクションへのリンク](#ノードの同期)

`sunrised`デーモンを起動すると、チェーンがネットワークと同期し始めます。ネットワークとの同期時間は、設定やブロックチェーンの現在のサイズによって異なりますが、非常に長い時間がかかる可能性があります。ノードのステータスを照会するには、次のようにします。

```bash
# RPC経由でクエリ（デフォルトポート：26657）
curl http://localhost:26657/status | jq .result.sync_info.catching_up
```

このコマンドが`true`を返す場合、ノードはまだ同期中であることを意味します。それ以外の場合、ノードはネットワークの最新ブロックに追いついており、バリデーターノードへのアップグレードを安全に進めることができます。

最新のブロックに追いつく時間を短縮したい場合は、他のノードのスナップショットを使用することを検討してください。

### オプション：スナップショットを使用する

[「オプション：スナップショットを使用する」セクションへのリンク](#オプションスナップショットを使用する)

最新のブロックに追いつく時間を短縮したい場合は、スナップショットの使用を検討してください。スナップショットを使用すると、特定の高さからノードをブートストラップできるため、ジェネシスから同期する必要がなくなります。

パートナーの[Polkachu](https://www.polkachu.com/tendermint_snapshots/sunrise)は、Sunriseネットワークの毎日のスナップショットを提供しています。最新のスナップショットURLを取得するには、彼らのWebサイトにアクセスしてください。

# バリデーターノード（ジェネシス）

> バリデーターノードを使用すると、Sunriseネットワークのコンセンサスに参加できます。

バリデーターノードを使用すると、Sunriseネットワークのコンセンサスに参加できます。

注記

この方法でバリデーターとして参加できるのは、ネットワークが開始する（ジェネシス）前のみです。ネットワークがすでに開始している場合は、[こちらのチュートリアル](/run-a-sunrise-node/types/consensus/validator-node)を参照してください。

## ハードウェア要件

[「ハードウェア要件」セクションへのリンク](#ハードウェア要件)

バリデーターノードを実行するために、以下の最低ハードウェア要件が推奨されます。

* メモリ：8 GB RAM（最小）
* CPU：6コア
* ディスク：500 GB SSDストレージ
* 帯域幅：ダウンロード1 Gbps / アップロード1 Gbps

## ノードの実行

[「ノードの実行」セクションへのリンク](#ノードの実行)

まず、[フルコンセンサスノードの設定](/run-a-sunrise-node/types/consensus/full-consensus-node)に関する指示に従ってください。

### オプション：作業ディレクトリのリセット

[「オプション：作業ディレクトリのリセット」セクションへのリンク](#オプション作業ディレクトリのリセット)

過去にsunrisedの作業ディレクトリを初期化したことがある場合は、新しいディレクトリを再初期化する前にクリーンアップする必要があります。次のコマンドを実行することでクリーンアップできます。

```bash
sunrised tendermint unsafe-reset-all
```

### 作業ディレクトリの初期化

[「作業ディレクトリの初期化」セクションへのリンク](#作業ディレクトリの初期化)

[Github](https://github.com/sunriselayer/network)で現在の`chain-id`を確認し、次のコマンドを実行してください。

```bash
CHAIN_ID=sunrise-1
MONIKER="validator-name"
sunrised init "$MONIKER" --chain-id $CHAIN_ID
```

`genesis.json`をネットワークリポジトリのものに変更します。

```bash
wget https://raw.githubusercontent.com/sunriselayer/network/main/sunrise-1/gentx/genesis.json
cp genesis.json $HOME/.sunrise/config/genesis.json
```

### 新しいキーの作成

[「新しいキーの作成」セクションへのリンク](#新しいキーの作成)

```bash
VALIDATOR_WALLET="validator"
sunrised keys add $VALIDATOR_WALLET --keyring-backend test
```

### 新しいチェーンのジェネシストランザクションの作成

[「新しいチェーンのジェネシストランザクションの作成」セクションへのリンク](#新しいチェーンのジェネシストランザクションの作成)

```bash
STAKING_AMOUNT=1000000uvrise
sunrised genesis gentx $VALIDATOR_WALLET $STAKING_AMOUNT --chain-id $CHAIN_ID \
   --pubkey=$(sunrised tendermint show-validator) \
   --moniker=$MONIKER \
   --commission-rate=0.1 \
   --commission-max-rate=0.2 \
   --commission-max-change-rate=0.01 \
   --min-self-delegation=1 \
   --keyring-backend test
```

生成されたgentx JSONファイルは`\$HOME/.sunrised/config/gentx/gentx-*.json`内にあります。

### gentxを登録するためのプルリクエストの作成

[「gentxを登録するためのプルリクエストの作成」セクションへのリンク](#gentxを登録するためのプルリクエストの作成)

gentxを登録するには、[ネットワークリポジトリ](https://github.com/sunriselayer/network/tree/main/sunrise-1/gentx)にプルリクエストを作成してください。

# Cosmovisorのセットアップ

> メインネットでは、ノードの実行にCosmovisorを使用することをお勧めします。

**メインネットでは、ノードの実行にCosmovisorを使用することをお勧めします。**

Cosmovisorの設定は比較的簡単です。ただし、特定の環境変数とフォルダ構造が設定されている必要があります。\
Cosmovisorを使用すると、チェーンのアップグレードのためにバイナリを事前にダウンロードできます。つまり、ダウンタイムをゼロ（またはほぼゼロ）に抑えてチェーンのアップグレードを実行できます。また、ローカルのタイムゾーンによってチェーンのアップグレードが不都合な時間に発生する場合にも便利です。\
夜遅くにストレスの多い運用タスクを実行するよりも、それらを自動化できる方が常に優れています。それがCosmovisorが試みることです。

## インストール

[「インストール」セクションへのリンク](#インストール)

まず、cosmovisorを入手します（推奨されるアプローチ）：

```bash
# 特定のバージョンをターゲットにするには：
go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@v1.0.0
```

### シェルに環境変数を追加する

[「シェルに環境変数を追加する」セクションへのリンク](#シェルに環境変数を追加する)

一部の環境変数は、各ノードと各ネットワークに対して適切な値に設定する必要があります。

```bash
echo "export DAEMON_NAME=sunrised" >> ~/.profile
echo "export DAEMON_HOME=$HOME/.sunrised" >> ~/.profile
echo "export DAEMON_ALLOW_DOWNLOAD_BINARIES=true" >> ~/.profile
echo "export DAEMON_LOG_BUFFER_SIZE=512" >> ~/.profile
echo "export DAEMON_RESTART_AFTER_UPGRADE=true" >> ~/.profile
echo "export UNSAFE_SKIP_BACKUP=true" >> ~/.profile
```

次に、プロファイルをソースして、これらの変数にアクセスできるようにします。

```bash
source ~/.bash_profile
```

### フォルダ構造の設定

[「フォルダ構造の設定」セクションへのリンク](#フォルダ構造の設定)

```bash
mkdir -p $DAEMON_HOME/cosmovisor
mkdir -p $DAEMON_HOME/cosmovisor/genesis
mkdir -p $DAEMON_HOME/cosmovisor/genesis/bin
mkdir -p $DAEMON_HOME/cosmovisor/upgrades
```

### ジェネシスバイナリの設定

[「ジェネシスバイナリの設定」セクションへのリンク](#ジェネシスバイナリの設定)

Cosmovisorは、ジェネシスで使用するバイナリを知る必要があります。これを`$DAEMON_HOME/cosmovisor/genesis/bin`に置きます。

[Github](https://github.com/sunriselayer/network)でジェネシスのバイナリバージョンを確認してください。

```bash
wget https://github.com/sunriselayer/sunrise/releases/download/<version>/sunrised
cp sunrised $DAEMON_HOME/cosmovisor/genesis/bin
```

### サービスの設定

[「サービスの設定」セクションへのリンク](#サービスの設定)

Cosmovisorに送信されたコマンドは、基盤となるバイナリに送信されます。たとえば、`cosmovisor version`は`sunrised version`と入力するのと同じです。それでも、`sunrised`をプロセス管理ツールで管理するのと同じように、エラーや再起動などが発生した場合にCosmovisorが自動的に再起動されるようにしたいと考えています。まず、サービスファイルを作成します。

```bash
sudo vi /lib/systemd/system/cosmovisor.service
```

以下の内容を自分の設定に合わせて変更してください。

```bash
[Unit]
Description=Cosmovisor daemon
After=network-online.target
[Service]
Environment="DAEMON_NAME=sunrised"
Environment="DAEMON_HOME=$DAEMON_HOME"
Environment="DAEMON_RESTART_AFTER_UPGRADE=true"
Environment="DAEMON_ALLOW_DOWNLOAD_BINARIES=true" // 推奨
Environment="DAEMON_LOG_BUFFER_SIZE=512"
Environment="UNSAFE_SKIP_BACKUP=true"
User=$USER
ExecStart=${HOME}/go/bin/cosmovisor start
Restart=always
RestartSec=3
LimitNOFILE=infinity
LimitNPROC=infinity
[Install]
WantedBy=multi-user.target
```

注記

環境変数の説明は[こちら](https://docs.cosmos.network/main/run-node/cosmovisor.html)にあります。設定に応じて変更してください。

### Cosmovisorの起動

[「Cosmovisorの起動」セクションへのリンク](#cosmovisorの起動)

注意

スナップショットから同期する場合は、まだCosmovisorを起動しないでください。スナップショットをダウンロードして`\$HOME/.sunrise/data`に展開します。最後に、サービスを有効にして起動します。

```bash
sudo systemctl daemon-reload
sudo systemctl restart systemd-journald
sudo systemctl enable cosmovisor
sudo systemctl start cosmovisor
```

実行中であることを確認するには、次を使用します。

```bash
sudo systemctl status cosmovisor
```

起動後にサービスを監視する必要がある場合は、次を使用してログを表示できます。

```bash
sudo journalctl -u cosmovisor -f -o cat
```

# バリデーターノード

> バリデーターノードを使うと、Sunrise ネットワークのコンセンサスに参加できます。

バリデーターノードを使うと、Sunrise ネットワークのコンセンサスに参加できます。

## ハードウェア要件

[「ハードウェア要件」セクションへのリンク](#ハードウェア要件)

バリデーターノードを動かすために、次の最低ハードウェア要件が推奨されます。

* メモリ: 8 GB RAM（最小）
* CPU: 6 コア
* ディスク: 500 GB SSD ストレージ
* 帯域幅: ダウンロード 1 Gbps / アップロード 1 Gbps

## ノードの実行

[「ノードの実行」セクションへのリンク](#ノードの実行)

まず、[フルコンセンサスノードのセットアップ](/run-a-sunrise-node/types/consensus/full-consensus-node) の手順に従ってください。

### オプション: 作業ディレクトリのリセット

[「オプション: 作業ディレクトリのリセット」セクションへのリンク](#オプション-作業ディレクトリのリセット)

過去に sunrised の作業ディレクトリを初期化したことがある場合は、新しいディレクトリを再初期化する前にクリーンアップする必要があります。次のコマンドで実行できます。

```bash
sunrised tendermint unsafe-reset-all
```

### 作業ディレクトリの初期化

[「作業ディレクトリの初期化」セクションへのリンク](#作業ディレクトリの初期化)

次のコマンドを実行します。

```bash
CHAIN_ID=sunrise-1 # メインネットの場合
MONIKER="validator-name"
sunrised init "$MONIKER" --chain-id $CHAIN_ID
```

現在の chain-id は [Github](https://github.com/sunriselayer/network) を確認してください。

### 新しいキーの作成

[「新しいキーの作成」セクションへのリンク](#新しいキーの作成)

```bash
VALIDATOR_WALLET="validator"
sunrised keys add $VALIDATOR_WALLET --keyring-backend test
```

### バリデーターの公開鍵

[「バリデーターの公開鍵」セクションへのリンク](#バリデーターの公開鍵)

バリデーターを初期化する前に最後に必要なのは、ノードを最初に初期化したときに作られたバリデーター公開鍵です。バリデーターの pubkey を取得するには次を実行します。

```bash
sunrised tendermint show-validator
{"@type":"/cosmos.crypto.ed25519.PubKey","key":"ZQweivhEkT/akg5RT6RWkElt43rr5cf+qu/QQ5jOpmQ="}
```

### バリデーターの作成

[「バリデーターの作成」セクションへのリンク](#バリデーターの作成)

バリデーターを作成するには、最低 1 vRISE が必要です。vRISE は譲渡できないため、アカウントに残高がない場合は、流動性プールにポジションを作って vRISE を獲得してください。

まず、バリデーター設定ファイル `~/.sunrise/config/validator.json` を作成します。

```json
{
  "pubkey": {"@type":"/cosmos.crypto.ed25519.PubKey","key":"ZQweivhEkT/akg5RT6RWkElt43rr5cf+qu/QQ5jOpmQ="},
  "amount": "1000000uvrise",
  "moniker": "your_validator's_name",
  "identity": "optional identity signature (ex. UPort or Keybase)",
  "website": "validator's (optional) website",
  "security": "validator's (optional) security contact email",
  "details": "validator's (optional) details",
  "commission-rate": "0.1",
  "commission-max-rate": "0.2",
  "commission-max-change-rate": "0.01",
  "min-self-delegation": "1"
}
```

次に、次のコマンドを実行します。

```bash
sunrised tx staking create-validator [path/to/validator.json] \
    --chain-id=$CHAIN_ID \
    --from=$VALIDATOR_WALLET \
    --keyring-backend=test \
    --gas-prices=0.025uusdrise --gas-adjustment 1.2 \
    --gas=auto \
    -y
```

## バックアップ

[「バックアップ」セクションへのリンク](#バックアップ)

何らかの理由でバリデーターが損傷したり失われたりした場合に復元できるよう、特定のファイルをバックアップする必要があります。`~/.sunrise/config/` にある次のファイルを安全にバックアップしてください。

* `priv_validator_key.json`
* `node_key.json`

これらのファイルのバックアップは暗号化することを推奨します。

## バリデーターへの追加インセンティブ

[「バリデーターへの追加インセンティブ」セクションへのリンク](#バリデーターへの追加インセンティブ)

注意

「バリデーターへの追加インセンティブ」の申請期間は 2025 年 10 月 15 日に終了しました。再開日は未定です。すでに chain-registry に登録し、要件を満たしているバリデーターへの委任は完了しています。

プログラムの資金プールが枯渇したため、いま要件を満たしても（例: tx indexer を有効にする）追加委任の対象にはなりません。ご注意ください。

コアチームは、次のサービスを提供するバリデーターへ、より多くの RISE を委任します。

### RPC / API / gRPC

[「RPC / API / gRPC」セクションへのリンク](#rpc--api--grpc)

* **委任量:** 各サービス（RPC、API、gRPC）あたり 250,000 RISE。上限は合計 750,000 RISE です。

* **条件:**

  * エンドポイントを [chain-registry](https://github.com/cosmos/chain-registry/blob/master/sunrise/chain.json) へのプルリクエストで提出し、マージされること。
  * トランザクション indexer と CORS が有効であること。

### エクスプローラー

[「エクスプローラー」セクションへのリンク](#エクスプローラー)

* **委任量:** 25,000 RISE。
* **条件:**
  * エクスプローラーを [chain-registry](https://github.com/cosmos/chain-registry/blob/master/sunrise/chain.json) へのプルリクエストで提出し、マージされること。
* **追加委任:**
  * 公式の Sunrise サービス内でエクスプローラーが使われる場合、追加委任を行います。個別にご連絡します。

参加人数に応じて、これらのインセンティブの内容は変わる場合があります。

# IBCリレーヤー

> IBCリレーヤーを設定することで、Sunriseと他のブロックチェーンとの間にIBCの新しい接続とチャネルを作成できます。

IBCリレーヤーを設定することで、Sunriseと他のブロックチェーンとの間にIBCの新しい接続とチャネルを作成できます。

## Goリレーヤーでのリレーヤー設定（非推奨）

[「Goリレーヤーでのリレーヤー設定（非推奨）」セクションへのリンク](#goリレーヤーでのリレーヤー設定非推奨)

詳細はこちらで確認できます：<https://github.com/cosmos/relayer>。

まず、[Go](https://go.dev/doc/install)をインストールしてください。

## RustリレーヤーHermesでのリレーヤー設定（推奨）

[「RustリレーヤーHermesでのリレーヤー設定（推奨）」セクションへのリンク](#rustリレーヤーhermesでのリレーヤー設定推奨)

詳細はこちらで確認できます：<http://hermes.informal.systems>。

まず、[Rust](https://www.rust-lang.org/tools/install)をインストールしてください。

次に、以下のコマンドを実行します：

```bash
sudo apt update && sudo apt upgrade -y
sudo apt install librust-openssl-dev build-essential git -y


cargo install ibc-relayer-cli --bin hermes --locked
hermes version


echo word1 ... word12or24 > ~/mnemonic.txt
```

### アカウントの設定

[「アカウントの設定」セクションへのリンク](#アカウントの設定)

まず、両方のチェーンで十分な資金を持つウォレットが必要です。 このチュートリアルでは、リレーしたいチェーン上にすでにウォレットが作成されており、それぞれのウォレットに資金が割り当てられていることを前提としています。

```bash
hermes keys add --key-name <user-name> --chain <ibc-0> --mnemonic-file mnemonic.txt
hermes keys add --key-name <user-name> --chain <ibc-1> --mnemonic-file mnemonic.txt
```

### 設定ファイル

[「設定ファイル」セクションへのリンク](#設定ファイル)

`hermes config auto`コマンドは、[chain-registry](https://github.com/cosmos/chain-registry)内のチェーンの設定ファイルを自動的に生成する方法を提供します：

テストネットの場合は、各パラメータを自分で設定する必要があります。詳細については、[ドキュメント](https://hermes.informal.systems/documentation/configuration/index.html)を参照してください。

```bash
hermes config auto --output $HOME/.hermes/config.toml --chain <ibc-0>:<key-ibc-0> <ibc-1>:<key-ibc-1> --chain
```

#### 新しいリレーパスの追加

[「新しいリレーパスの追加」セクションへのリンク](#新しいリレーパスの追加)

以下の設定は、すでに確立されたIBCチャネルを持つメインネットには不要です。新しい接続を開始する場合にのみ従ってください。

* 接続の作成

まず、`ibc-0`の状態を追跡するクライアントを`ibc-1`上に作成します。これには`07-tendermint-0`が識別子として割り当てられます：

```bash
hermes create client --host-chain <ibc-1> --reference-chain <ibc-0>
```

* 接続の作成

両方のチェーンにクライアントを作成した後、それらの間に接続を確立する必要があります。両方のチェーンは、最初の接続の識別子として`connection-0`を割り当てます：

```bash
hermes create connection --a-chain <ibc-0> --b-chain <ibc-1>
```

コマンドが正常に実行されると、`connection ID`が出力されるはずです。

* チャネル識別子

最後に、接続が確立された後、その上に新しいチャネルを開くことができます。両方のチェーンは、最初のチャネルの識別子として`channel-0`を割り当てます：

```bash
hermes create channel --a-chain <ibc-0> --a-connection <connection-id> --a-port transfer --b-port transfer
```

コマンドが正常に実行されると、両方のチェーンのチャネルIDが出力されるはずです。

これらを`.hermes/config.toml`に追加します。

```yml
[chains.packet_filter]
policy = "allow"
list = [[
    "transfer",
    "channel-0",
]]
```

設定が完了したら、次のコマンドでリレーヤーを起動できます。

```bash
hermes start
```

### デーモンの設定

[「デーモンの設定」セクションへのリンク](#デーモンの設定)

再起動後に自動的に実行されるようにSystemDを設定することをお勧めします。

```bash
sudo tee /etc/systemd/system/hermes.service > /dev/null <<EOF
[Unit]
Description=Hermes Relayer Service
After=network-online.target


[Service]
User=ubuntu
ExecStart=/usr/local/bin/hermes start
Restart=on-failure
RestartSec=3
LimitNOFILE=1400000


[Install]
WantedBy=multi-user.target
EOF


sudo systemctl enable hermes
sudo systemctl daemon-reload
sudo systemctl start hermes
```

### デーモンの監視

[「デーモンの監視」セクションへのリンク](#デーモンの監視)

```bash
journalctl -u hermes.service -f
```