# NERO Chain ドキュメント — Full Corpus > NERO Chain の開発者向けドキュメント。ネイティブなアカウント抽象化、ペイマスターによるガス代スポンサーシップ、Web2 フレンドリーなオンボーディングを備えたレイヤー 1 ブロックチェーンです。 Source: https://docs.nerochain.io/ja Pages: 71 --- # エージェント認証ガイド Source: https://docs.nerochain.io/ja/agent-auth Section: agent-auth NERO Paymaster JSON-RPC API に対して AI エージェントを認証する、プログラマブル優先のガイドです。OpenAPI スペック [/openapi.yaml](https://docs.nerochain.io/openapi.yaml) から来た方向けに、人間の手順とコードを組み合わせて説明します。 ## 要点 - **認証方式:** `X-API-Key` ヘッダーで送信する長期 API キー - **発行者:** [AA Platform ダッシュボード](https://aa-platform.nerochain.io) - **スコープ:** `paymaster:read`(トークンとスポンサー状態の読み取り)、`paymaster:sponsor`(UserOperation の署名) - **サンドボックス:** NERO テストネットは無料([FAQ](https://docs.nerochain.io/ja/faq) の蛇口リンク参照) - **OAuth 2.0:** 現在使用していません。キーのローテーションは AA Platform UI から - **ディスカバリ:** [`/.well-known/oauth-protected-resource`](/.well-known/oauth-protected-resource)(RFC 9728) ## ステップ 1 — API キーを取得する 1. [aa-platform.nerochain.io](https://aa-platform.nerochain.io) でアカウントを作成します。 2. NERO テストネット(または メインネット)にスコープされたプロジェクトを作成します。 3. API キーを生成します。作成時にのみ表示されるため、必ずコピーしてください。 4. Type 0(無料ガス)を使用する場合は、スポンサー残高を入金します。 ダッシュボード経由のフローを完了できない自律エージェントを構築している場合、プログラマブルなオンボーディングパスについて [Discord](https://discord.com/invite/nerochainofficial) で NERO チームにお問い合わせください。 ## ステップ 2 — キーを安全に保管する API キーはサーバーサイドで保管します。クライアントサイドの JavaScript、モバイルアプリのバンドル、公開リポジトリに決して埋め込まないでください。 ```bash # .env (コミット禁止) NERO_API_KEY=pk_live_xxxxxxxxxxxxxxxxxxxxxxx ``` ## ステップ 3 — 認証済みリクエストを送信する すべての Paymaster JSON-RPC メソッドは、以下の 2 つの方法のいずれかで API キーを受け付けます。 **推奨 — HTTP ヘッダー:** ```bash curl -X POST https://paymaster-testnet.nerochain.io \ -H "Content-Type: application/json" \ -H "X-API-Key: $NERO_API_KEY" \ -d '{"jsonrpc":"2.0","id":1,"method":"pm_supported_tokens","params":[{"sender":"0xAABbCc00112233445566778899AaBbCcDdEeFf00","nonce":"0x0","initCode":"0x","callData":"0x","callGasLimit":"0x0","verificationGasLimit":"0x0","preVerificationGas":"0x0","maxFeePerGas":"0x0","maxPriorityFeePerGas":"0x0","paymasterAndData":"0x","signature":"0x"},"'"$NERO_API_KEY"'","0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789"]}' ``` **レガシー — 第 2 JSON-RPC パラメータ**(ヘッダーを設定できない SDK クライアント向け): ```json {"params": [userOperation, "$NERO_API_KEY", "0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789"]} ``` ## ステップ 4 — レート制限とエラーを処理する すべてのエラーは構造化された JSON-RPC 2.0 エラーレスポンスとして返されます。 | コード | 意味 | 再試行? | |---|---|---| | `-32521` | 実行中にトランザクションが revert | 不可(callData を修正) | | `-32602` | 無効な UserOperation 構造体/フィールド | 不可(ペイロードを修正) | | `-32500` | EntryPoint の `simulateValidation` で拒否 | 不可 | | `-32501` | Paymaster の `validatePaymasterUserOp` で拒否 | 不可(スポンサー残高/スコープを確認) | | `-32503` | 時間範囲外 | 可(再構築して再送) | | `-32504` | Paymaster がスロットル/BAN | 可(指数バックオフ) | プロジェクト単位のレート制限は AA Platform ダッシュボードで設定します(日次ガス上限、トランザクション数、ガス価格上限)。エージェントは: - HTTP 429 レスポンスを尊重し、1 秒から指数バックオフ - `pm_supported_tokens` の結果を最低 60 秒キャッシュ - `-32503` エラーは最大 3 回、新しい UserOp でリトライ - `-32501` エラーはリトライしない(設定の問題) ## ステップ 5 — キーをローテーションする AA Platform UI からいつでもキーをローテーションできます。古いキーは即座に無効になります。キーの漏洩が疑われる場合は、ローテーションしたうえでダッシュボードの使用量ビューで支出を監査してください。 ## 機械可読参照 - [Paymaster OpenAPI 3.1 スペック](https://docs.nerochain.io/openapi.yaml) - [`/.well-known/oauth-protected-resource`](https://docs.nerochain.io/.well-known/oauth-protected-resource) - [`/.well-known/ai-plugin.json`](https://docs.nerochain.io/.well-known/ai-plugin.json) - [`/.well-known/agent-card.json`](https://docs.nerochain.io/.well-known/agent-card.json) - [MCP サーバー](https://docs-mcp.nerochain.io) --- # AI リソース Source: https://docs.nerochain.io/ja/ai-resources Section: ai-resources NERO Chain のドキュメントは、AI エージェント、検索システム、LLM 搭載の開発ツール向けに機械可読な形式で公開されています。NERO Docs MCP サーバーにコーディングエージェントを接続するか、バンドルを直接ダウンロードしてご利用ください。 ここで提供されるすべてのリソースは純粋に情報提供を目的としたものであり、システムプロンプト、ペルソナ、トラッキングは埋め込まれていません。 ## MCP で接続する NERO Docs MCP サーバーは、[Model Context Protocol](https://modelcontextprotocol.io) を通じてドキュメント全体を公開しています。コーディングエージェントからこのエンドポイントに接続すると、自然言語で質問するだけで関連ページや API メソッドを取得できます。 **エンドポイント:** `https://docs-mcp.nerochain.io` ### Claude Code (CLI) {`claude mcp add --transport http nero-docs https://docs-mcp.nerochain.io`} ### Claude Desktop {`{ "mcpServers": { "nero-docs": { "type": "http", "url": "https://docs-mcp.nerochain.io" } } }`} ### Cursor {`{ "mcpServers": { "nero-docs": { "transport": "http", "url": "https://docs-mcp.nerochain.io" } } }`} ### VS Code (GitHub Copilot Chat) {`{ "servers": { "nero-docs": { "type": "http", "url": "https://docs-mcp.nerochain.io" } } }`} ### ChatGPT / OpenAI Apps SDK {`{ "name": "nero-docs", "type": "mcp", "server_url": "https://docs-mcp.nerochain.io" }`} ### Codex CLI {`codex mcp add nero-docs --transport http --url https://docs-mcp.nerochain.io`} ## バンドルのダウンロード 接続ではなくファイルでご利用になりますか？ すべてのバンドルは正しい `Content-Type` と CORS 対応で配信されています。 ### サイト全体 | ファイル | 内容 | トークン目安 | |---|---|---| | [`/llms.txt`](https://docs.nerochain.io/llms.txt) | 全ページのキュレーション済みマークダウン索引（[llmstxt.org](https://llmstxt.org) 準拠）。 | 約 6K | | [`/llms-full-ja.txt`](https://docs.nerochain.io/llms-full-ja.txt) | 日本語版フルコーパス（プレーンマークダウン）。 | 約 120K | | [`/llms-full.txt`](https://docs.nerochain.io/llms-full.txt) | 英語版フルコーパス。 | 約 120K | | [`/llms-full.jsonl`](https://docs.nerochain.io/llms-full.jsonl) | 1 行 1 ページの JSON。埋め込みパイプラインでそのままストリーミング可能。 | 約 120K | | [`/site-index.json`](https://docs.nerochain.io/site-index.json) | URL・タイトル・見出し・要約・トークン数などのメタデータ。 | 約 25K | | [`/sitemap.xml`](https://docs.nerochain.io/sitemap.xml) | 標準的なサイトマップ（EN/JA の `hreflang` ペア付き）。 | — | ### セクションバンドル 各セクションの個別 llms.txt もご利用いただけます: | セクション | 英語 | 日本語 | |---|---|---| | はじめに | [EN](https://docs.nerochain.io/en/getting-started/llms.txt) | [JA](https://docs.nerochain.io/ja/getting-started/llms.txt) | | ホワイトペーパー | [EN](https://docs.nerochain.io/en/core-concepts/llms.txt) | [JA](https://docs.nerochain.io/ja/core-concepts/llms.txt) | | 開発者ツール | [EN](https://docs.nerochain.io/en/developer-tools/llms.txt) | [JA](https://docs.nerochain.io/ja/developer-tools/llms.txt) | | クックブック | [EN](https://docs.nerochain.io/en/tutorials/llms.txt) | [JA](https://docs.nerochain.io/ja/tutorials/llms.txt) | | ノードバリデータ | [EN](https://docs.nerochain.io/en/node-validators/llms.txt) | [JA](https://docs.nerochain.io/ja/node-validators/llms.txt) | ## OpenAPI とスキーマ Paymaster JSON-RPC API は OpenAPI 3.1 スペックとして公開されています: - [`/specs/paymaster-openapi.yaml`](https://docs.nerochain.io/specs/paymaster-openapi.yaml) - [`/specs/paymaster-openapi.json`](https://docs.nerochain.io/specs/paymaster-openapi.json) その他の検出用リソース: - [`/.well-known/ai-plugin.json`](https://docs.nerochain.io/.well-known/ai-plugin.json) — OpenAI プラグインマニフェスト - [`/.well-known/agent-card.json`](https://docs.nerochain.io/.well-known/agent-card.json) — A2A エージェントカード - [`/.well-known/agent-skills/index.json`](https://docs.nerochain.io/.well-known/agent-skills/index.json) — スキルカタログ - [`/.well-known/api-catalog`](https://docs.nerochain.io/.well-known/api-catalog) — RFC 9727 リンクセット - [`/.well-known/nero-docs.json`](https://docs.nerochain.io/.well-known/nero-docs.json) — ナビゲーションとアーティファクトの索引 ## ChatGPT / Claude で開く NERO ドキュメントコーパスを事前読み込みした新しい会話を開始: - [ChatGPT で開く](https://chat.openai.com/?q=Summarize+https%3A%2F%2Fdocs.nerochain.io%2Fllms-full.txt+and+help+me+build+on+NERO+Chain) - [Claude で開く](https://claude.ai/new?q=Please%20load%20https%3A%2F%2Fdocs.nerochain.io%2Fllms-full.txt%20and%20help%20me%20build%20on%20NERO%20Chain) ## 透明性 - システムプロンプトやペルソナは埋め込まれていません。 - これらのアーティファクトにはトラッキングクッキーやアナリティクスはありません（`Access-Control-Allow-Origin: *`）。 - コンテンツはビルドごとに MDX ソースから決定論的に再生成されるため、人間が読む内容と完全に一致します。 - ソースオブトゥルース: [github.com/nerochain/Nero-docs](https://github.com/nerochain/Nero-docs) --- # アクセスレイヤー：ネイティブアカウント抽象化 Source: https://docs.nerochain.io/ja/core-concepts/architecture/accessLayer Section: ホワイトペーパー アクセスレイヤーは、ネイティブアカウント抽象化を備え、ユーザーがブロックチェーンネットワークと関わるためのゲートウェイとして機能します。このレイヤーはアカウント作成、トランザクション署名、スマートコントラクトとのやり取りなど、さまざまなユーザーアクティビティを促進します。ブロックチェーンプロトコルの複雑さを抽象化することで、セキュリティ対策を維持しながらユーザーの操作を簡素化します。ネイティブアカウント抽象化により、ユーザーはアカウントとトランザクションをシームレスに管理でき、鍵管理とトランザクション処理の柔軟性を提供します。このレイヤーは、ブロックチェーン環境内でのアクセシビリティと使いやすさを向上させ、スムーズでユーザーフレンドリーな体験を保証します。 さらに、アクセスレイヤーはユーザーアクセスをコアブロックチェーンから分離し、コンピュータオペレーティングシステムのシェルコンポーネントのような役割を果たします。この分離により、将来のアクセス技術の更新とアップグレードが容易になります。 --- # レイヤー Source: https://docs.nerochain.io/ja/core-concepts/architecture/architecture Section: ホワイトペーパー 柔軟性とスケーラビリティはNEROのアーキテクチャ設計における主要な考慮事項です。柔軟性については、NEROはユーザーとブロックチェーンの相互作用を処理するアクセスレイヤーを導入し、鍵、署名、手数料に使用されるトークンに関してより多くの選択肢を提供します。スケーラビリティについては、NEROは現在のブロックチェーンシステムが同時に達成できない分散化、安全性、スケーラビリティのブロックチェーントリレンマについて深く研究しました。私たちは、従来のモノリシックアーキテクチャを実行レイヤー、決済レイヤー、データ可用性レイヤーの3つに分割することでこのトリレンマに対処しました。したがって、全体のアーキテクチャは図1のように示すことができます。 ![Figure 1](https://docs.nerochain.io/assets/learn/figure1.png)

図1：NEROアーキテクチャ図

* アクセスレイヤー：さまざまなユーザー操作を受け入れ、それらをチェーンに転送してコミットする役割を担います。 {/* * 実行レイヤー：ほぼすべてのコントラクトベースのトランザクションの実行を担当し、分散型アプリケーションをサポートします。これはZK Rollupの応用であり、実行結果は決済レイヤーに提出され、決済レイヤーは否定できないセキュリティと客観的な確定性を確立します。 */} * 決済レイヤー：実行レイヤーの実行結果を検証して決済する役割を担い、また資産レイヤーとしてチェーン上の資産の管理と決済も担当します。 * データ可用性レイヤー：実行データに焦点を当て、データシャーディングとデータサンプリング技術に基づいてネットワーク内のデータ可用性を確保します。 --- # データ可用性レイヤー：ストレージスケーラビリティ Source: https://docs.nerochain.io/ja/core-concepts/architecture/dataAvailabilityLayer Section: ホワイトペーパー 決済レイヤー内の貴重なストレージ容量を節約するために、NEROはロールアップのための信頼性の高いオンチェーンストレージを提供するデータ可用性レイヤーを設計しました。これにより、ロールアップに関連する元のトランザクションデータのための外部ストレージプロトコルへの依存が排除され、NERO Chain内で問題が完全に解決されます。さらに、NEROはより多くのノードを参加させるためにシャーディングアーキテクチャを持つデータ可用性レイヤーを設計し、分散化とスケーラビリティを向上させました。この構造により、各ノードはデータの一部（シャード）のみを保存し、複数のノードがデータのアクセシビリティを確保します。独立したストレージレイヤーとして、NEROのデータ可用性レイヤーは従来のブロックチェーンと比較していくつかの重要な特徴を持っています： * チェーン上でのデータストレージのみが必要で、トランザクション実行はなく、ワールドステートも存在しません。 * ブロック検証は過去のデータに依存しません。 * 決済レイヤーのみが統一管理を行います。 --- # 決済レイヤー：高性能EVM互換チェーン Source: https://docs.nerochain.io/ja/core-concepts/architecture/settlementLayer Section: ホワイトペーパー 実行レイヤーはNEROのスケーラビリティの鍵です。NEROは、リソースを大量に消費するトランザクション処理をオンチェーン環境からオフチェーンに移行させることで最適化され、オンチェーンは結果の検証に集中します。トランザクションプロセスを2つのフェーズに分割します。最初に、多数のトランザクションがオフチェーンで実行され、その後まとめられます。次に、それらはまとめてメインチェーンに提出され、検証されます。元のトランザクションデータは圧縮されてオンチェーンに保存されます。このアプローチにより、メインチェーンに送信されるデータの量が最小限に抑えられ、より高速で費用対効果の高いトランザクションが可能になります。 ## イーサリアムとの完全な互換性 NEROは、イーサリアムがブロックチェーンアプリケーション開発の業界標準であると考えています。より多くの高品質なdAppsプロジェクトと開発者をNEROエコシステムに引き付けるために、NEROは決済レイヤーで完全なイーサリアムプロトコルを実装しています。NEROはEVMとの完全な互換性を持つだけでなく、最新のEIPにも対応しているため、開発者はイーサリアム上の既存のDAppsをNEROに直接デプロイすることができます。一方、Wallet、Solidity、Remix、Truffle、Hardhatなど、イーサリアム上で開発されたすべての開発ツールもNEROチェーン上で直接使用できます。さらに、NEROはイーサリアムのほぼすべてのRPCインターフェースとも互換性があるため、開発者はコストをかけずにNEROのアプリケーション開発に移行し、NEROのエコシステム開発の報酬を得ることができます。 --- # コンセンサス Source: https://docs.nerochain.io/ja/core-concepts/consensus-mechanism/overview Section: ホワイトペーパー コンセンサスはブロックチェーンの中核コンポーネントであり、NEROはハイブリッドランダム化DPoSA（委任ステーク権限証明）プロトコルを採用しています。このコンセンサスプロトコルはDPoSAコンセンサスを基盤とし、ノードのランダム選択メカニズムを統合することで、参加範囲を広げ、システムの分散化を強化しています。コンセンサスノード内では、BFT（ビザンチン障害耐性）コンセンサスメカニズムが迅速なトランザクション確認を保証します。さらに、従来のコンセンサスワークフローはトランザクション配布フェーズ、実行プロセスフェーズ、実行結果拡散フェーズに分割されています。このアプローチにより、トランザクション処理のためのパイプラインメカニズムが確立され、システムのスループットが大幅に向上します。 > ⚠️ **注意:** DPoSAプロトコルのランダム化選択の側面は将来の実装のために計画されています。現在、バリデータ選択は決定論的なプロセスに従っています。 NEROのコンセンサスプロトコルは、ブロックを提案し検証するノードのセットを選択します。これは、より多くのノードをシステムに導入してコンセンサスプロセスに参加させるための重要なメカニズムです。コンセンサスプロセスは固定数のブロックに従って異なるエポックに分割され、各エポックではブロックの提案と検証に同じバリデータセットが使用されます。 --- # パイプラインコンセンサス Source: https://docs.nerochain.io/ja/core-concepts/consensus-mechanism/pipelinedConsensus Section: ホワイトペーパー イーサリアムなどの従来のブロックチェーンシステムでは、ブロック生成プロセスはいくつかのステップで構成されています： - マイナー（ブロック提案者）がトランザクションをパッケージ化して実行します。 - マイナーは実行結果をブロックヘッダーに設定します。 - ブロックの伝播。 - 他のノードがブロック内のトランザクションを実行します。 - そしてブロックの実行結果を検証します。 トランザクションがパッケージ化されてからネットワーク全体のコンセンサスに達するまでに、2回の直列実行と直列伝播プロセスを経ることがわかります。これには多くの最適化の余地があります。ブロックの構造をより詳しく見ると、一連のトランザクションと実行結果に関連するさまざまなマークルルートが含まれています。トランザクションリストは主にトランザクション実行の順序を表し、ブロックヘッダーはブロック実行の結果と見なすことができます。これら2つのコンセンサスをトランザクションシーケンスコンセンサスと実行結果コンセンサスに分離することを検討できます。 図4に示すように、コンセンサス中のブロックをブロックNとすると、BFTプロセスはブロックNの全内容に同意するのではなく、ブロックNのトランザクションリストと特定のメタデータ、およびブロックN-2のブロックハッシュに同意します。BFTプロセスが完了すると、ブロックN+1のコンセンサスが進行し、同時にブロックNが実行されます。さらに、ブロックNにはブロックN-2のハッシュが含まれているため、ブロックNのコンセンサスの完了は、ブロックN-2の確認も意味します。 ![Figure 4](https://docs.nerochain.io/assets/learn/figure4.png)

図4：BFT、実行、検証のパイプライン処理。

--- # 乱数生成 Source: https://docs.nerochain.io/ja/core-concepts/consensus-mechanism/randomNumberGeneration Section: ホワイトペーパー > ⚠️ **注意:** この機能は計画されていますが、現在は実装されていません。バリデータ選択は決定論的です。 上記のランダム選択のセキュリティを考慮すると、乱数の生成は分散型のスキームを通じて行われる必要があります。さらに、生成された乱数が検証可能であり、すべてのノード間で一貫性が確保されることが不可欠です。また、乱数生成プロセス中に、単一のノードが結果に影響を与えたり操作したりする能力を持つべきではありません。 NEROの乱数はMPC（マルチパーティ計算）アプローチを通じて生成されます。各参加ノードは最初に独自の乱数をローカルで生成します。その後、システムは特定の操作を使用して、すべてのノードの貢献から派生した公開乱数を生成します。他のノードが自身の乱数を生成する前に他のノードの乱数にアクセスすることを防ぐために、NEROは乱数生成プロセス中にシャミア秘密共有に基づく暗号化PVSS（公開検証可能な秘密共有）スキームを採用しています。このスキームにより、現在のバリデータセットが協力して乱数を生成し、暗号技術を使用してプロセスの操作から保護することができます。プロセスは次のとおりです： * バリデータ $D$ は、閾値 $t$ に基づいて秘密 $S$ を $n$ 個の断片 $(S1,...,Sn)$ に分割します。次に、$n$ 人の参加者の公開鍵 $(Px,...,PN)$ を使用して各断片を暗号化し、対応するコミットメント（ゼロ知識証明による）を生成し、これらすべての情報を共有します。 * 追加情報を取得せずに、バリデータ $D$ からの $n$ 個の値がすべて有効であることを検証できます。 * 必要に応じて、参加者は自分の秘密鍵で共有を復号化し、それを他の人と共有することができます。 * $≥ t$ 個の復号化された共有を取得した後、誰でも秘密 $S$ を再構築できます。 最後に、共有乱数の生成は各エポックで発生します。現在のエポックは、前のエポックで生成された乱数を使用します。 --- # 不正証明 Source: https://docs.nerochain.io/ja/core-concepts/data-availability/dataAvailabilityVerification/fraudProof Section: ホワイトペーパー 上記のランダムサンプリング方法は、対応するブロックを復元するのに十分な断片がネットワーク内に存在することを保証し、データ可用性を確保します。しかし、これらの断片内のすべてのデータの有効性を保証するものではありません。したがって、不正証明メカニズムを通じてこの問題に対処する必要があります。 不正証明は、無効なトランザクションの証明と無効なデータエンコーディングの証明に分類できます。DAチェーンでは、後者に焦点が当てられています。不正証明の生成は、2Dエンコーディングの各行と列内のRSコードが元のデータを正確に再構築する能力に依存しています。したがって、証明を生成するには1つの行または列のデータのみが必要であり、証明のサイズはすべてのデータのサイズに比例し、nと表記されます。 ノードが十分な断片を収集したが正しく復号できない状況では、これらの断片とそのマークル証明をブロードキャストする必要があります。これらの証明は不正証明として機能し、他のノードがその信頼性を検証できるようにします。最初に不正証明を提出したノードは、それに応じて報酬を受け取ります。 --- # データ可用性検証 Source: https://docs.nerochain.io/ja/core-concepts/data-availability/dataAvailabilityVerification/overview Section: ホワイトペーパー 検証に関して、NEROのDAレイヤーにおけるDAノードの役割を以下のように定義します： * **一般DAノード。** 一般DAノードは、フルノードのように自分のシャーディングDAチェーンの全ブロックを保存し、サンプリングされたブロックデータを他に提供します。また、無効なブロックが見つかった場合には不正証明をブロードキャストすることもできます。 * **メンテナーDAノード。** 通常のDAノードは、決済レイヤーにトークンをステークすることで、それぞれのシャーディングチェーン内の候補メンテナーDAノードとして資格を得ることができます。ステーク額が最も高い上位NノードがメンテナーDAノードの役割を担います。これらのノードはDA機能の提供から生じる手数料を共有する権利を持ち、同時にブロックサンプリングデータを提出する義務も負います。 データ可用性検証は決済レイヤー内のバリデータによって行われます。ブロック生産者でもある決済レイヤーのバリデータがDAチェーンでブロックを提案すると、DAブロックのハッシュが決済レイヤーに送信されます。その後、決済レイヤー内の他のバリデータはランダムサンプリングを通じてDAブロックのデータ可用性を検証します。検証に成功すると、決済レイヤーのバリデータはDAブロックハッシュの署名をブロードキャストし、検証を示します。これらのバリデータの2/3からの署名が得られると、それらは確認証明として決済レイヤーに提出されます。 次の決済ブロックで決済レイヤーの検証に合格し、DAブロックが提案されてから不正証明が発行されていない場合、DAブロックは決済レイヤー内で確認済みとしてマークされます。同時に、次のDAブロックが提案されます。 --- # ランダムサンプリング Source: https://docs.nerochain.io/ja/core-concepts/data-availability/dataAvailabilityVerification/randomSampling Section: ホワイトペーパー DAブロックはヘッダーと本体で構成されています。ヘッダーは比較的小さく、直接ダウンロードして確認できますが、本体ははるかに大きく、データ可用性を検証するためにランダムにサンプリングする必要があります。ブロックが生成されると、サイズによって $k * k$ の断片にスライスされ、2次元RS（Reed-Solomon）コードを適用することで $2k * 2k$ の断片が生成されます。次に、各断片の各行と列に対してマークルツリーが作成されるため、$2k + 2k = 4k$ のマークルツリーが存在します。 ![figure5](https://docs.nerochain.io/assets/learn/figure5.png)

図5：データ可用性レイヤーのブロックスライシングとエンコーディング

これらの $4k$ のマークルルートは最終的に1つのマークルツリーを形成し、そのツリーのルートがブロック全体のルートとして使用されます。そして、ルートと他のメタデータをヘッダーに組み合わせます。その後、ヘッダーと元の本体がP2Pネットワークを通じてブロードキャストされます。他のDAノードがブロックを受信すると、上記と同じ方法で2次元RSエンコーディングを繰り返し、ルートを計算し、ヘッダー内のものと同じであれば受け入れます。 決済レイヤーのバリデータはDAブロック提案者からヘッダーを受け取り、少なくとも1つのDAノードに接続します。これらのバリデータはランダムに断片のsとそれらのブロックルートへのマークルパスをダウンロードします。それらの断片がすべて正常に取得できれば、サンプリングバリデータは非常に高い可能性でDAブロックの可用性を確認できます。 次に、ランダムサンプリングのこのようなメカニズムの下で、利用不可能なDAブロックが利用可能と認識される確率を計算します。上述のように、DAブロックは $2k * 2k$ 断片のRSコードにエンコードされ、各行または列の任意のk断片でその行または列を復元できるため、敵対者はブロック全体を利用不可能にするために少なくとも断片を保留する必要があります。 1つのバリデータがDAブロックからランダムに断片をサンプリングすると仮定すると、DAブロックが最小限の利用不可能な部分を持つ場合、単一のバリデータによって実行される少なくとも1つの利用不可能な断片をサンプリングする確率は以下のように示されます。 $$ P_{single}=1-\frac{C_S^{2k ⋅ 2k-(k+1)^2}}{C_S^{2k ⋅ 2k}}=1-\prod_{i=0}^{S-1}(1-\frac{(k+1)^2}{4k^2-i}) $$ これは、利用不可能なDAブロックを正しく認識できる最小確率でもあります。そして、決済レイヤーの委員会にN個のアクティブなバリデータがあり、そのうち最大でfが悪意のあるものであり、これはN/3未満です。また、DAブロックを確認するためにはN - f票を集める必要があります。したがって、無効なDAブロックを確認しないためには、N - f個の誠実なバリデータのうち少なくともf+1個のバリデータが利用不可能性を発見する必要があります。したがって、利用不可能なDAブロックは以下の確率でネットワークによって認識されます： $$ P_{network}=1-\sum_{i=0}^f C_i^{N-f} ⋅ P_{single} ⋅ (1-P_{single})^{N-f-i} $$ NEROでは、N = 21、f = 6なので、異なるkとSの下での確率は以下のように計算できます $$ k=64, S=5 ⇒ P_{single}=77.94\%, P_{network}=99.81\% $$ $$ k=64, S=10 ⇒ P_{single}=94.94\%, P_{network}=99.9999917\% $$ $$ k=128, S=10 ⇒ P_{single}=94.66\%, P_{network}=99.9999987\% $$ $$ k=128, S=15 ⇒ P_{single}=98.77\%, P_{network}=99.9999999999969\% $$ $k = 128$ かつ $S = 15$ の場合、利用不可能なDAブロックはほぼ100%の確率で明らかになり、サンプリングバリデータはこのような条件下で元のデータのわずか0.09%をダウンロードするだけで済むことがわかります。 --- # モデルと前提条件 Source: https://docs.nerochain.io/ja/core-concepts/data-availability/modelAndAssumptions Section: ホワイトペーパー まず、ネットワークモデルを確立します： * **トポロジー：** ノードはP2Pネットワークを介して相互接続されています。 * **最大ネットワーク遅延：** ネットワークの最大遅延は $D$ と表記されます。誠実なノードがネットワーク内の特定のデータを時間 $T$ に受信した場合、他の誠実なノードは時間 $T + D$ より前に同じデータを取得できます。 次に、セキュリティモデルは次のように概説されます： * 無効なブロックの検出は保証されています。ネットワーク内の少なくとも1つの誠実なノードがそれを発見して拡散するからです。 * 各誠実なノードは、少なくとも1つの他の誠実なノードとの接続を維持しています。 --- # データ可用性 Source: https://docs.nerochain.io/ja/core-concepts/data-availability/overview Section: ホワイトペーパー データ可用性もNEROの重要なコンポーネントであり、ロールアップにとって非常に重要です。NEROでは、データ可用性（DA）レイヤーとして知られる独立したレイヤーとして、特にデータ可用性のための新しいタイプのチェーンとトランザクションを設計しました。DAレイヤーは決済レイヤーの管理下にあり、決済レイヤーにトークンをステークしているノードのグループ（DAノード）によって維持されています。決済レイヤーのバリデータは、ランダムサンプリングと不正証明を通じてDAブロックの可用性を確認し、DAチェーンを確認することができます。 さらに、DAノードの範囲を複数のグループに拡大し、各グループが異なるDAチェーンを維持することができます。このアプローチにより、シャーディングシステムを確立し、多様なストレージ需要に対応することができます。全体的なシステムアーキテクチャは以下のように示されています。 --- # トランザクション手数料とインセンティブ Source: https://docs.nerochain.io/ja/core-concepts/data-availability/transactionFeesAndIncentives Section: ホワイトペーパー ![Figure 6](https://docs.nerochain.io/assets/learn/figure6.png)

図6：データ可用性レイヤーのトランザクション形式

データ可用性検証が通過すると、DAトランザクションのヘッダーもDAブロックハッシュとともに決済レイヤーにコミットされます。その後、トランザクション手数料が送信者のアカウントから差し引かれ、DAブロック提案者、DAブロック確認提案者、およびこのシャードの関連するすべてのDAメンテナーノードに報酬として分配されます。 --- # エコシステムにおける手数料共有メカニズム Source: https://docs.nerochain.io/ja/core-concepts/fee-sharing/Overview Section: ホワイトペーパー > ⚠️ **注意:** ここで説明されている自動手数料共有メカニズムは将来の機能であり、現在のメインネット/テストネットではまだアクティブではありません。現時点では、NERO Foundationとの契約に基づいたオフチェーンでの手数料共有メカニズムが運用されています。 NEROのアプリケーション手数料共有メカニズムは、ネットワークへの貢献に対してエコシステム参加者にインセンティブを与え、報酬を与えるように設計されています。このメカニズムにより、dAppsによって生成されるトランザクション手数料が広く使用されているアプリケーション間で再分配され、持続可能で協調的な経済的整合性が促進されます。 **貢献ベースの報酬：** NEROの手数料共有メカニズムは、ネットワーク内の様々なアプリケーションによる貢献に基づいてトランザクション手数料を割り当てます。これには、dAppsを作成してデプロイする開発者や、ブロックチェーン上のトランザクションを保護および検証するバリデータが含まれます。各dAppの貢献は測定され定量化され、それらによって生成されるトランザクション手数料の一部が報酬として与えられます。 **カスタマイズ可能なパラメータ：** NEROの手数料共有メカニズムは、エコシステム参加者の多様なニーズと好みに対応する柔軟性とカスタマイズオプションを提供します。開発者はdApp内での手数料共有の取り決めを管理する特定のルールとパラメータを定義する能力を持ち、独自のビジネスモデルと手数料共有契約に従ってトランザクション手数料の分配を調整できます。 **経済的整合性：** アプリケーション間でトランザクション手数料を分配することで、NEROの手数料共有メカニズムは経済的インセンティブを整合させ、エコシステム内での協力と利益の一致を促進します。開発者はユーザーを引き付け、トランザクションボリュームを生成する高品質なdAppsを作成するインセンティブを与えられます。この経済的整合性は、時間の経過とともにNEROエコシステムの成長と持続可能性を促進します。 ![Figure 10](https://docs.nerochain.io/assets/learn/figure10.png)

図10：手数料共有メカニズム

--- # 概要 Source: https://docs.nerochain.io/ja/core-concepts Section: ホワイトペーパー ビットコインの登場以来、ブロックチェーン技術と分散化の概念は徐々に人気を集めてきました。イーサリアムのスマートコントラクトによって、分散型台帳技術の可能性はほぼ無限に広がりました。初期のブロックチェーン技術は主にセキュリティと分散化の問題に取り組み、信頼の課題を解決することに重点を置いていました。しかし、トランザクション処理能力の需要が急増するにつれて、Solanaをはじめとするパーミッションレス・ブロックチェーンは、TPS（1秒あたりのトランザクション数）を数万規模にスケールさせるためのソリューションを提案しました。 それにもかかわらず、DeFi、GameFi、NFTなどの分散型アプリケーションが爆発的に成長する中で、現在の最大の課題は、ユーザーと開発者の体験を向上させることにあります。たとえば、ユーザーは各ブロックチェーンが提供する暗号化手段に依存せざるを得ず、秘密鍵を紛失してしまった場合には救済措置がありません。また、dAppは多くのトランザクション量を生み出していても、トランザクション手数料を共有することはできません。これはエコシステムの形成を妨げる要因となっています。ユーザー操作の柔軟性の欠如や手数料の仕組みが、分散型経済の発展を阻害しているのです。 イーサリアム・コミュニティのアカウント抽象化（Account Abstraction）ソリューションは、これらの問題をある程度緩和しましたが、根本的かつネイティブな解決策とは言い難いのが現状です。さらに、分散型コミュニティで一般的に採用されている手数料分配メカニズムが欠如しており、dAppsをエコシステムに誘致し、経済的なインセンティブを提供する仕組みも不足しています。 これらの問題を解決するためには、ブロックチェーンの柔軟性を向上させる必要があります。そのため、私たちはNEROを提案します。NEROは、ネイティブなアカウント抽象化機構を備えた次世代のモジュラー・ブロックチェーンであり、安全性、スケーラビリティ、そして何よりも柔軟性を重視しています。NEROは、統合型のスマートコントラクト、ユーザー操作プール（User Operation Pool）、Paymasterなどを含む、より構造化されたネイティブなアカウント抽象化のメカニズムを導入します。これにより、ユーザーはWeb2のような使い勝手でWeb3の世界を活用できるようになります。 さらに、NEROはガス料金の経済モデルを策定し、貢献度に応じてガス料金をdAppsと共有することで、dAppsが最適化に努めるインセンティブを提供します。加えて、NEROは高性能なトランザクション処理を保証するためにモジュラー設計を採用しています。全体のプロセスは、実行（Execution）、決済（Settlement）、データ可用性（Data Availability）という3つの層に垂直分割されます。また、EVMおよびイーサリアム・プロトコルと完全互換の決済チェーンを備え、大規模なノード参加を可能にするコンセンサスを採用しています。データ可用性については、現在最も効率的なデータサンプリング検証方式を採用しています。 NEROは、エコシステム内のdAppの発展を支援し、協力し合うことを目的としています。高性能なパーミッションレス・ブロックチェーンを基盤とし、段階的に柔軟性を向上させることで、新しい基盤を確立します。NEROは革新的なコンセプトを通じてWeb3の発展を積極的に支援し、誰もが参加できる完全な基盤を備えたパーミッションレス・ブロックチェーンを形成します。他のパーミッションレス・ブロックチェーンと比較して、NEROは柔軟性の向上とトランザクションのスケーリングに重点を置き、以下の5つのコア技術を採用しています。 - ネイティブアカウント抽象化を活用し、Web2のようなユーザー体験を提供 - Blockspace 2.0：トランザクション手数料をエコシステムのdAppに再分配する多次元的なガス料金経済モデルを実装 - パイプライン最適化型BFTコンセンサスメカニズムを採用し、高スループット、分散性、安全性、迅速なトランザクション確定を実現 - イーサリアム・プロトコルとEVMに完全互換で、エコシステム内のアプリケーション移行をシームレスに実現 --- # MPC-TSS技術の統合 Source: https://docs.nerochain.io/ja/core-concepts/native-account-abstraction/MpcTssTechnologyIntegration Section: ホワイトペーパー NEROは、EOA（外部所有アカウント）のセキュリティと制御を強化するために、MPC-TSS（閾値秘密共有を伴うマルチパーティ計算）として知られる最先端技術を採用しています。MPC-TSSは、複数の関係者間で安全かつ分散された計算を可能にする高度な暗号技術であり、単一のエンティティが機密情報全体にアクセスすることができないようにします。 MPC-TSSを使用することで、NEROエコシステム内のEOAの制御は分散化され、潜在的なセキュリティ脅威から保護されます。EOAを管理・制御するために単一のエンティティや中央集権的な権限に依存する代わりに、MPC-TSSはEOAにアクセスするために必要な暗号鍵の共有部分を各自が保持する複数の関係者間で制御を分散させます。この制御の分散により、MPC-TSSプロトコルに関与する他の関係者の協力なしに、単一の関係者がEOAの資産にアクセスしたり、不正なトランザクションを実行したりすることができないようになります。 さらに、MPC-TSSは閾値メカニズムを実装することでEOA制御の耐性を高めます。この閾値メカニズムは、暗号鍵を協力して再構築しEOAにアクセスするために必要な最小限の関係者数を指定します。この閾値ベースのアプローチにより、セキュリティの追加層が追加され、一部の関係者が侵害されたり利用できなくなったりしても、閾値要件が侵害されない限りEOAは保護されたままになります。 ![Figure 9](https://docs.nerochain.io/assets/learn/figure9.png)

図9：MPC-TSSによるアカウント抽象化

--- # 柔軟なガスメカニズム Source: https://docs.nerochain.io/ja/core-concepts/native-account-abstraction/flexibleGasMechanism Section: ホワイトペーパー NEROは、ブロックチェーン上のユーザーオペレーションに関連するトランザクション手数料の支払いを管理する役割を担うPaymasterと呼ばれるモジュールを開発しました。アカウント抽象化モデルの一部として、ペイマスターはトランザクション手数料の処理をユーザーから中央集権的なコントラクトエンティティに抽象化し、手数料支払いプロセスを合理化し、ユーザーエクスペリエンスを向上させる役割を果たします。 ペイマスターの主な機能は、ユーザーがブロックチェーンとやり取りする際に発生するトランザクション手数料の支払いを容易にすることです。従来のブロックチェーンシステムでは、ユーザーはネットワークに送信する各トランザクションに手数料を手動で含める必要がありました。しかし、アカウント抽象化では、この責任はペイマスターコントラクトに移行され、ユーザーは直接トランザクション手数料を管理する負担から解放されます。ユーザーがトランザクションを開始したり、手数料が発生する他の操作を実行したりすると、対応する操作はペイマスターコントラクトを通じて処理されます。ペイマスターは、操作の複雑さや現在のネットワーク状況などの要因に基づいて適切な手数料を計算します。その後、ユーザーのアカウント残高から手数料を差し引くか、別のメカニズムを通じて手数料の支払いを承認するようユーザーに促します。 さらに、ペイマスターはその機能を強化するために追加の特性と機能を組み込むことができます。例えば、ネットワークの混雑レベルやユーザーの好みに基づいて手数料の価格設定を最適化するための動的な手数料調整アルゴリズムを実装することがあります。また、多様なユーザーのニーズと好みに対応するために、様々な支払い方法と手数料構造をサポートすることもあります。 ![Figure 8](https://docs.nerochain.io/assets/learn/figure8.png)

図8：柔軟なガス手数料メカニズム

--- # 主要コンポーネント Source: https://docs.nerochain.io/ja/core-concepts/native-account-abstraction/keyComponents Section: ホワイトペーパー アカウント抽象化は、ブロックチェーン上でのユーザーアカウントの管理と対話の方法を再定義します。アカウント管理をスマートコントラクトに抽象化することで、アカウント抽象化はDAppsにおいてより大きな柔軟性、セキュリティ、効率性を可能にします。NEROは独自のフレームワーク内にアカウント抽象化の主要コンポーネントをすべて構築しており、ユーザーオペレーションメモリプール、バンドラー、エントリーポイントコントラクトが含まれています： **ユーザーオペレーションメモリプール：** ユーザーオペレーションメモリプールは、ブロックチェーン上での実行を待機中の保留中のユーザーオペレーションの保管場所として機能します。従来のトランザクションメモリプールと同様に機能しますが、アカウント抽象化のコンテキスト内でユーザーオペレーションを処理するために特別に設計されています。ユーザーが資金の送金やスマートコントラクトとの対話などのアカウント関連の操作を開始すると、これらの操作はブロックチェーンによって処理されるまで一時的にユーザーオペレーションメモリプールに格納されます。 **バンドラー：** バンドラーは、ユーザーオペレーションメモリプールからユーザーオペレーションをパッケージ化し、ブロックチェーン上での実行のためにアトミックなバンドルにまとめる役割を担います。複数のユーザーオペレーションを単一のトランザクションバンドルに集約し、ブロックチェーンリソースの使用を最適化し、トランザクションのオーバーヘッドを削減します。バンドラーは、バンドル内のオペレーションがアトミックに実行されることを保証します。つまり、バンドル内のすべてのオペレーションが正常に実行されるか、まったく実行されないかのいずれかであり、ブロックチェーン全体での一貫性と整合性を確保します。 **エントリーポイントコントラクト：** エントリーポイントコントラクトは、ユーザーがブロックチェーン上の抽象アカウントとやり取りするためのインターフェースとして機能します。これはブロックチェーンにデプロイされたスマートコントラクトであり、特定の抽象アカウントに関連するすべてのユーザーオペレーションのエントリーポイントとして機能します。エントリーポイントコントラクトには、資金の入金、出金、カスタムアカウント機能の呼び出しなど、受信するユーザーオペレーションを処理するために必要なロジックが含まれています。ユーザーはエントリーポイントコントラクトにトランザクションを送信し、それが実行のために適切なアカウントコントラクトにオペレーションをルーティングすることで、抽象アカウントとやり取りします。 --- # ネイティブアカウント抽象化サポート Source: https://docs.nerochain.io/ja/core-concepts/native-account-abstraction/nativeAccountAbstractionSupport Section: ホワイトペーパー アカウント抽象化は、ブロックチェーン技術内の概念であり、スマートコントラクトに基づくユーザーアカウントの柔軟な管理を提供することを目的としています。従来、ブロックチェーンネットワークでは、ユーザーアカウントはブロックチェーンのネイティブアカウントシステムを通じて直接管理され、各アカウントはアドレスと秘密鍵を持っています。これらのアカウントは暗号通貨の送受信やブロックチェーンにデプロイされたスマートコントラクトとの対話に使用されます。しかし、アカウント抽象化では、ユーザーアカウントの管理責任がブロックチェーンのネイティブアカウントシステムから離れ、スマートコントラクト自体の領域に移行します。このモデルでは、ユーザーアカウントはスマートコントラクトとして表現され、管理モジュールにはトランザクションを処理し、残高を管理するための必要なロジックが含まれています。ユーザーは、ブロックチェーンのアカウントシステムと直接やり取りするのではなく、これらのスマートコントラクト表現のメソッドを呼び出すことでアカウントとやり取りします。 NEROはアカウント抽象化モデルを深く統合し、抽象アカウントの様々な機能をネイティブにサポートし、以下の側面でユーザーの対話を体系的に強化します： * **拡張された柔軟性：** アカウント管理をスマートコントラクトに抽象化することで、ユーザーはアカウントに対するより大きな柔軟性と制御を獲得します。ブロックチェーンのネイティブアカウントシステムの制約に限定されるのではなく、特定のニーズに合わせてカスタムアカウント構造と挙動を定義できます。 * **向上したプライバシー：** アカウント抽象化は、ユーザーがアカウントコントラクト内に洗練されたプライバシー強化技術を実装することで、プライバシーを向上させることができます。例えば、ユーザーはゼロ知識証明やリング署名などのプライバシー保護トランザクションプロトコルをアカウントコントラクト内に直接実装し、トランザクションの機密性を高めることができます。 * **ガスコストの削減：** アカウント抽象化は、より効率的なトランザクション処理を可能にすることで、ユーザーのガスコストを潜在的に削減できます。アカウントコントラクトは特定のユースケースに合わせてカスタムトランザクションロジックを実装できるため、ガス消費を最小化するためにトランザクション実行を最適化できます。これにより、特に複雑または頻繁なトランザクションに対して、ユーザーのコスト削減につながります。 * **強化されたセキュリティ：** アカウント管理をスマートコントラクトに抽象化することで、アカウント抽象化はブロックチェーンのネイティブアカウントシステムの攻撃面を減らし、セキュリティを強化できます。スマートコントラクトは、マルチシグネチャ認証やタイムロックトランザクションなどの堅牢なセキュリティ対策を実装して、ユーザーの資金を保護し、不正アクセスを防止できます。 --- # 参考文献 Source: https://docs.nerochain.io/ja/core-concepts/references Section: ホワイトペーパー 1. M. Al-Bassam, A. Sonnino, and V. Buterin, "Fraud proofs: Maximising light client security and scaling blockchains with dishonest majorities," *CoRR*, vol. abs/1809.09044, 2018. 2. E. Syta, P. Jovanovic, E. Kokoris-Kogias, N. Gailly, L. Gasser, I. Khoffi, M. J. Fischer, and B. Ford, "Scalable Bias-Resistant Distributed Randomness," In *38th IEEE Symposium on Security and Privacy*, May 2017. 3. The Ethereum Team, "A note on data availability and erasure coding," [https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding) 4. Satoshi Nakamoto, "Bitcoin: A peer-to-peer electronic cash system," 2008. [https://bitcoin.org/bitcoin.pdf](https://bitcoin.org/bitcoin.pdf) 5. The Ethereum Foundation, "Ethereum Whitepaper." [https://github.com/ethereum/wiki/wiki/White-Paper](https://github.com/ethereum/wiki/wiki/White-Paper) 6. E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and B. Ford, "Omniledger: A secure, scale-out, decentralized ledger via sharding," in *2018 IEEE Symposium on Security and Privacy (SP)*, pp. 19–34, 2018. 7. A. Kiayias, I. Konstantinou, A. Russell, B. David, and R. Oliynykov, "Ouroboros: A provably secure proof-of-stake blockchain protocol," *Cryptology ePrint Archive*, Report 2016/889, 2016. [http://eprint.iacr.org/](http://eprint.iacr.org/) 8. George Danezis and Sarah Meiklejohn, "Centrally banked cryptocurrencies," In *23rd Annual Network and Distributed System Security Symposium, NDSS*, 2016. 9. P. Daian, R. Pass and E. Shi, "Snow White: Robustly reconfigurable consensus and applications to provably secure proofs of stake," *Cryptology ePrint Archive*, Report 2016/919, 2017. 10. M. Zamani, M. Movahedi, and M. Raykova, "RapidChain: A Fast Blockchain Protocol via Full Sharding," *Cryptology ePrint Archive*, Report 2018/460, 2018. [https://eprint.iacr.org/2018/460](https://eprint.iacr.org/2018/460) 11. P. Vasin, "Blackcoin's Proof-of-Stake Protocol v2," 2014. [https://blackcoin.co/blackcoin-pos-protocol-v2-whitepaper.pdf](https://blackcoin.co/blackcoin-pos-protocol-v2-whitepaper.pdf) 12. Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena, "A secure sharding protocol for open blockchains," In *Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security*, CCS '16, pages 17–30, 2016. 13. Rafael Pass and Elaine Shi, "Thunderella: Blockchains with optimistic instant confirmation." [https://eprint.iacr.org/2017/913.pdf](https://eprint.iacr.org/2017/913.pdf) 14. Joseph Poon, Vitalik Buterin, "Plasma: Scalable Autonomous Smart Contracts." [http://plasma.io/plasma-deprecated.pdf](http://plasma.io/plasma-deprecated.pdf) 15. Vitalik Buterin, "An Incomplete Guide to Rollups," [https://vitalik.ca/general/2021/01/05/rollup.html](https://vitalik.ca/general/2021/01/05/rollup.html) 16. S. Dziembowski, S. Faust, and K. Hostakova, "Foundations of state channel networks," *Cryptology ePrint Archive*, Report 2018/320, 2018. [https://eprint.iacr.org/2018/320](https://eprint.iacr.org/2018/320) --- # ポリシーの設定 Source: https://docs.nerochain.io/ja/developer-tools/aa-platform/configuring-policies Section: 開発者ツール ポリシーは、アプリケーションがユーザーのトランザクション手数料をどのように処理するかを決定します。考慮すべき4つの主要な設定があります： - ERC20決済の有効化 - アドレスごとの割引 - すべてのアドレスに対するオファー - コールバックの指定 ## ERC20決済の有効化 1. 「API Keys」タブに移動し、設定したいAPIKeyを選択します 2. 「Policies」タブをクリックします 3. ERC-20 Paymentトグルをクリックします 4. 支払いモードを選択します：事前支払いと事後支払い、または事前支払いのみ ![ガスポリシーの設定](https://docs.nerochain.io/assets/aaPlatform/gifs/erc20.gif) *図1：ガスポリシーの設定* ### ガス支払いをサポートするトークンの選択 ここでは、ガス代の支払いとして受け取りたいERC20トークンを選択できます。 1. 「Select」ボタンをクリックします 2. リスト上のトークンを選択するか、テキストフィールドにトークンコントラクトを入力してリストに表示させます 3. 選択を「Confirm」します 4. ガス支払い変動レートを設定します 5. ダッシュボードの最後にある「Save」ボタンをクリックします ![ガスポリシーの設定](https://docs.nerochain.io/assets/aaPlatform/gifs/erc20config.gif) *図2：ガスサポート用トークンの選択* ### 戦略タイプの説明 #### 無料ガス（タイプ0） この戦略では、ユーザーのガスコストを完全に負担します。以下の場合に最適です： - 暗号資産を所有していない新規ユーザーのオンボーディング - プロモーションキャンペーン - すべての摩擦を取り除きたいアプリケーション - ブロックチェーンの複雑さを隠したいGameFiアプリケーション #### ERC20事前支払い（タイプ1） ユーザーはトランザクションが実行される前にERC20トークンを使用してガスを支払います： - 予想される全額が前もって収集されます - 実行後に余剰分は返金されます - 支払いが保証されるため、開発者にとってより安全です - 高額な操作に適しています #### ERC20事後支払い（タイプ2） ユーザーはトランザクションが実行された後にERC20トークンを使用してガスを支払います： - 正確なガスコストのみが収集されます - 実行前にトークン承認が必要です - ユーザーは必要な分だけ支払うためUXがやや向上します - 実行後の支払い失敗のリスクがあります ## アドレスごとの割引の設定 アドレスごとにスポンサーする意思のあるUSDまたはネイティブトークンの合計を設定できます。 1. ポリシータブで、「Discount per address」オプションをトグルします 2. アドレスごとの回数を日、週、または月モードで設定します 3. 新しいアドレスごとの最大無料金額：アドレスごとにスポンサーできる合計制限を設定できます 4. アドレスがスポンサーされる無料回数の合計も設定できます 5. 「Save」ボタンをクリックします ![割引の設定](https://docs.nerochain.io/assets/aaPlatform/gifs/discount.gif) *図3：割引の設定* ## すべてのアドレスに対するオファー 同様の設定をすべてのアドレスに同時に設定することもできます。 1. ポリシータブで、「All Addresses offer」オプションをトグルします 2. アドレスごとの回数を日、週、または月モードで設定します 3. 新しいアドレスごとの最大無料金額：アドレスごとにスポンサーできる合計制限を設定できます 4. アドレスがスポンサーされる無料回数の合計も設定できます 5. 「Save」ボタンをクリックします ![すべてのアドレスに対する割引の設定](https://docs.nerochain.io/assets/aaPlatform/gifs/alldiscount.gif) *図4：すべてのアドレスに対する割引の設定* ## コールバックの指定 ユーザー操作をスポンサーするかどうかを指定する特定のアドレスを設定できます。 1. 「Specify Callback」オプションをトグルします 2. アドレスを設定します 3. 保存します ## 次のステップ ポリシーを設定した後は、以下を行う必要があります： - [支払いを管理する](https://docs.nerochain.io/ja/developer-tools/aa-platform/payment-management)で戦略に十分な資金があることを確認します - [アプリケーションと統合する](https://docs.nerochain.io/ja/developer-tools/aa-platform/integration-and-best-practices)で設定したポリシーの使用を開始します --- # EntryPoint エラーコード ドキュメント Source: https://docs.nerochain.io/ja/developer-tools/aa-platform/entrypoint-error-codes Section: 開発者ツール このドキュメントは、EntryPointコントラクトで使用されるすべてのエラーコードの包括的なリファレンスを提供します。エラーコードは `AAmn` というパターンに従います。ここで： - `m` はカテゴリを示します： - `1` = Factory/InitCodeの問題 - `2` = アカウントの問題 - `3` = Paymasterの問題 - `4` = ガス/検証の問題 - `5` = PostOpの問題 - `9` = その他/内部の問題 - `n` はそのカテゴリ内の特定のエラー番号です ## エラーコード リファレンス表 | コード | カテゴリ | エラーメッセージ | 説明 | 場所 | 一般的な原因 | 解決方法 | |------|----------|---------------|-------------|-----------|----------------|------------| | **AA10** | Factory | `"AA10 sender already constructed"` | 指定されたアドレスに送信者アカウントコントラクトが既に存在 | `_createSenderIfNeeded()` | UserOperationに`initCode`が含まれているが、アカウントが既にデプロイ済み | `initCode`を削除するか、異なる送信者アドレスを使用 | | **AA13** | Factory | `"AA13 initCode failed or OOG"` | `initCode`によるアカウント作成が失敗 | `_createSenderIfNeeded()` | Factoryがリバート、ガス不足、または`address(0)`を返す | Factoryコントラクトを確認し、十分な`verificationGasLimit`を確保 | | **AA14** | Factory | `"AA14 initCode must return sender"` | Factoryが返したアドレスが期待される送信者と一致しない | `_createSenderIfNeeded()` | Factoryが計算されたものとは異なるアドレスを返す | Factoryが正しいアドレス計算方法を使用していることを確認 | | **AA15** | Factory | `"AA15 initCode must create sender"` | `initCode`実行後、送信者アドレスにコードがデプロイされていない | `_createSenderIfNeeded()` | Factory実行は完了したが、コントラクトコードが存在しない | Factoryがアカウントコントラクトを適切にデプロイしていることを確認 | | **AA20** | Account | `"AA20 account not deployed"` | アカウントコントラクトが存在せず、`initCode`も提供されていない | `_validateSenderAndPaymaster()` (シミュレーションのみ) | アカウントがデプロイされておらず、`initCode`がない | `initCode`を提供するか、アカウントがデプロイされていることを確認 | | **AA21** | Account | `"AA21 didn't pay prefund"` | アカウントのデポジットが必要なprefundをカバーするのに不十分 | `_validateAccountPrepayment()` | アカウントのデポジット < 必要なprefund | EntryPointにアカウント用の十分な資金をデポジット | | **AA22** | Account | `"AA22 expired or not due"` | UserOperationが有効な時間範囲外 | `_validateAccountAndPaymasterValidationData()` | ブロックタイムスタンプが`validUntil`より後、または`validAfter`より前 | 有効な時間ウィンドウ内で送信 | | **AA23** | Account | `"AA23 reverted: "` または `"AA23 reverted (or OOG)"` | アカウントの`validateUserOp`がリバート | `_validateAccountPrepayment()` | 署名検証の失敗、カスタム検証ロジック、またはOOG | リバート理由を確認、署名を検証、十分なガスを確保 | | **AA24** | Account | `"AA24 signature error"` | 署名アグリゲーターの不一致が署名検証の失敗を示す | `_validateAccountAndPaymasterValidationData()` | アカウント検証が期待とは異なるアグリゲーターを返す | 署名が正しいことを確認、アグリゲーター設定を確認 | | **AA25** | Account | `"AA25 invalid account nonce"` | UserOperationのnonceがアカウントの期待されるnonceと一致しない | `_validatePrepayment()` | Nonceが既に使用されているか、順序が乱れている | 正しいnonce値を使用し、アカウントの現在のnonceをクエリ | | **AA30** | Paymaster | `"AA30 paymaster not deployed"` | Paymasterコントラクトが存在しない | `_validateSenderAndPaymaster()` (シミュレーションのみ) | Paymasterアドレスにコードがない | Paymasterコントラクトをデプロイするか、有効なアドレスを使用 | | **AA31** | Paymaster | `"AA31 paymaster deposit too low"` | Paymasterのデポジットが必要なprefundをカバーするのに不十分 | `_validatePaymasterPrepayment()` | Paymasterのデポジット < 必要なprefund | EntryPointにPaymaster用の十分な資金をデポジット | | **AA32** | Paymaster | `"AA32 paymaster expired or not due"` | UserOperationがPaymasterの有効な時間範囲外 | `_validateAccountAndPaymasterValidationData()` | ブロックタイムスタンプがPaymasterの`validUntil`より後、または`validAfter`より前 | 有効な時間ウィンドウ内で送信 | | **AA33** | Paymaster | `"AA33 reverted: "` または `"AA33 reverted (or OOG)"` | Paymasterの`validatePaymasterUserOp`がリバート | `_validatePaymasterPrepayment()` | 検証ロジックの失敗、残高不足、またはOOG | リバート理由を確認、Paymasterの残高を確認、十分なガスを確保 | | **AA34** | Paymaster | `"AA34 signature error"` | Paymasterの署名検証が失敗 | `_validateAccountAndPaymasterValidationData()` | Paymaster検証が非ゼロのアグリゲーターを返す | Paymasterの署名を確認、`paymasterAndData`の署名データを確認 | | **AA40** | Gas | `"AA40 over verificationGasLimit"` | 検証中に使用された実際のガスが`verificationGasLimit`を超える | `_validatePrepayment()` | アカウントまたはPaymasterの検証が制限を超えるガスを使用 | `verificationGasLimit`を増やす、検証ロジックを最適化 | | **AA41** | Gas | `"AA41 too little verificationGas"` | アカウント検証後の残りガスがPaymasterに不十分 | `_validatePaymasterPrepayment()` | アカウント検証がガスを使いすぎた | `verificationGasLimit`を増やす、アカウント検証を最適化 | | **AA50** | PostOp | `"AA50 postOp reverted: "` または `"AA50 postOp revert"` | Paymasterの`postOp`関数がリバート | `_handlePostOp()` | PostOpロジックが失敗（トークン転送、会計など） | リバート理由を確認、Paymasterの残高を確認、`postOp`実装を確認 | | **AA51** | PostOp | `"AA51 prefund below actualGasCost"` | Prefund額が実際のガスコストより少ない | `_handlePostOp()` | 実際のガスがprefundを超える、ガス価格が上昇 | 内部エラー - ガス価格の安定性を確認、prefund計算を確認 | | **AA90** | Other | `"AA90 invalid beneficiary"` | 受益者アドレスがゼロアドレス | `_compensate()` | 受益者としてゼロアドレスが渡された | 有効な非ゼロの受益者アドレスを提供 | | **AA91** | Other | `"AA91 failed send to beneficiary"` | 収集された手数料の受益者への転送が失敗 | `_compensate()` | 受益者コントラクトが受信時にリバート | ETHを受信できる有効な受益者アドレスを使用 | | **AA92** | Other | `"AA92 internal call only"` | `innerHandleOp`が内部的ではなく外部的に呼び出された | `innerHandleOp()` | `innerHandleOp`への外部呼び出し | 関数はEntryPointによって内部的にのみ呼び出されるべき | | **AA93** | Other | `"AA93 invalid paymasterAndData"` | `paymasterAndData`の長さが無効（0または≥20バイトでなければならない） | `_copyUserOpToMemory()` | `paymasterAndData`の長さが1-19バイトの間 | 空のバイトを使用するか、有効なPaymasterアドレスで≥20バイトを確保 | | **AA94** | Other | `"AA94 gas values overflow"` | ガス値がuint120.maxを超える | `_validatePrepayment()` | 1つ以上のガス値 > uint120.max | ガス値をuint120.max以内に減らす | | **AA95** | Other | `"AA95 out of gas"` | `handleOps`トランザクションが不十分なガス制限で呼び出された | `_executeUserOp()` | バンドル全体がガス不足 | `handleOps`のガス制限を増やす、バンドルサイズを減らす | | **AA96** | Other | `"AA96 invalid aggregator"` | アグリゲーターアドレスが`address(1)`（署名エラーマーカー） | `handleAggregatedOps()` | アグリゲーターが署名エラーマーカーに設定されている | 署名集約ロジックを確認、アグリゲーター設定を確認 | ## 注意事項 - すべてのエラーコードは、EntryPointコントラクトの`FailedOp`エラータイプを通じて返されます - "AA"で始まるエラーコードは、アカウント抽象化（EIP-4337）に固有です - シミュレーション（`simulateValidation`）中、エラーAA20とAA30は、ウォーム/コールドストレージの区別を防ぐために使用されます - ほとんどのエラーはオフチェーンシミュレーション中にキャッチされるべきであり、オンチェーン実行中に発生すべきではありません - エラーコードは、どのエンティティ（factory、アカウント、またはPaymaster）が失敗の責任があるかを識別するのに役立ちます ## カテゴリ別クイックリファレンス ### Factory/InitCodeエラー (AA1x) - **AA10**: 送信者が既に構築済み - **AA13**: InitCodeが失敗またはOOG - **AA14**: InitCodeは送信者を返す必要がある - **AA15**: InitCodeは送信者を作成する必要がある ### アカウントエラー (AA2x) - **AA20**: アカウントがデプロイされていない - **AA21**: Prefundを支払わなかった - **AA22**: 期限切れまたは期限前 - **AA23**: アカウントがリバート - **AA24**: 署名エラー - **AA25**: 無効なアカウントnonce ### Paymasterエラー (AA3x) - **AA30**: Paymasterがデプロイされていない - **AA31**: Paymasterのデポジットが低すぎる - **AA32**: Paymasterが期限切れまたは期限前 - **AA33**: Paymasterがリバート - **AA34**: Paymaster署名エラー ### ガス/検証エラー (AA4x) - **AA40**: verificationGasLimitを超過 - **AA41**: verificationGasが少なすぎる ### PostOpエラー (AA5x) - **AA50**: PostOpがリバート - **AA51**: PrefundがactualGasCostより低い ### その他/内部エラー (AA9x) - **AA90**: 無効な受益者 - **AA91**: 受益者への送信に失敗 - **AA92**: 内部呼び出しのみ - **AA93**: 無効なpaymasterAndData - **AA94**: ガス値のオーバーフロー - **AA95**: ガス不足 - **AA96**: 無効なアグリゲーター --- # AAプラットフォームの使い始め方 Source: https://docs.nerochain.io/ja/developer-tools/aa-platform/getting-started Section: 開発者ツール ## プラットフォームへのアクセス AAプラットフォームは[https://aa-platform.nerochain.io](https://aa-platform.nerochain.io)で利用できます。以下が必要です： 1. ウォレットの接続（MetaMaskまたは他のWeb3ウォレット） ![AAプラットフォームログイン画面](https://docs.nerochain.io/assets/aaPlatform/gifs/Loginaa.gif) *図1：AAプラットフォームログイン画面。* ## チームの作成 ログイン後すぐにチームを作成する必要があります。以下の手順に従ってください： 1. 「Create New Team」（新しいチームを作成）をクリック 2. プロジェクト名、説明、ウェブサイトURLを入力 ![AAプラットフォームチーム作成1画面](https://docs.nerochain.io/assets/aaPlatform/gifs/create1.gif) *図2：チームの作成。* 3. 最初の操作では最初のAPIキーの作成がトリガーされるため、Nerochainのオプション（NERO Chain Testnet、Mainnetなど）を選択してください 4. 「Create ApiKey」（APIキーを作成）をクリック ![AAプラットフォームチーム作成2画面](https://docs.nerochain.io/assets/aaPlatform/gifs/create2.gif) *図3：チームの作成。* 各チームには独自のダッシュボード、APIキー、および設定があります。 ![AAプラットフォームチーム作成2画面](https://docs.nerochain.io/assets/aaPlatform/gifs/dash.gif) *図4：ダッシュボード。* ## チームメンバーの管理 ### 追加 以下の手順に従って、複数のユーザーをチームメンバーとして追加できます： 1. チームタブに移動し、「Invite」（招待）ボタンをクリックします。 2. 名前とメールアドレスを設定してユーザーを追加すると、メールが送信されます。 3. 確認ボタンを押して招待を送信します。 ![チームメンバーの追加](https://docs.nerochain.io/assets/aaPlatform/gifs/addmember.gif) *図5：チームメンバーの追加。* > **_注意：_** チームには3種類の役割があります：オーナー、管理者、同僚。同僚は読み取りアクセスのみを持ち、管理者とオーナーは書き込みアクセスを持ちます。ただし、APIキーを削除できるのはオーナーのみです。 ## 次のステップ チームを設定した後、以下のことができます： - [APIキーの作成と管理](https://docs.nerochain.io/ja/developer-tools/aa-platform/managing-api-keys) - [ポリシーの設定](https://docs.nerochain.io/ja/developer-tools/aa-platform/configuring-policies) --- # AAプラットフォーム：アカウント抽象化サービスの管理 Source: https://docs.nerochain.io/ja/developer-tools/aa-platform Section: 開発者ツール NERO Chain AAプラットフォームは、開発者がアカウント抽象化サービスを管理し、APIキーを作成し、ガススポンサーシップ戦略を設定し、使用状況を監視できる強力なウェブベースのダッシュボードです。このガイドでは、プラットフォームを効果的に使用する方法を説明します。 ## コンテンツ - [使い始める](https://docs.nerochain.io/ja/developer-tools/aa-platform/getting-started) - プラットフォームへのアクセス、チームの作成、チームメンバーの管理 - [APIキーの管理](https://docs.nerochain.io/ja/developer-tools/aa-platform/managing-api-keys) - APIキーの作成と保護 - [ポリシーの設定](https://docs.nerochain.io/ja/developer-tools/aa-platform/configuring-policies) - ガス支払いオプションと戦略タイプの設定 - [支払い管理](https://docs.nerochain.io/ja/developer-tools/aa-platform/payment-management) - 資金、残高、取引の管理 - [統合とベストプラクティス](https://docs.nerochain.io/ja/developer-tools/aa-platform/integration-and-best-practices) - アプリケーションとの統合とベストプラクティスの遵守 - [EntryPoint エラーコード](https://docs.nerochain.io/ja/developer-tools/aa-platform/entrypoint-error-codes) - すべてのEntryPointエラーコードの包括的なリファレンス - [トラブルシューティング](https://docs.nerochain.io/ja/developer-tools/aa-platform/troubleshooting) - 一般的な問題の解決 --- # 統合とベストプラクティス Source: https://docs.nerochain.io/ja/developer-tools/aa-platform/integration-and-best-practices Section: 開発者ツール ## アプリケーションとの統合 APIキーと戦略を設定したら、それらをアプリケーションに統合します： ```typescript // アプリケーションでペイマスターを設定する builder.setPaymasterOptions({ apikey: "プラットフォームから取得した_API_キー", rpc: "https://paymaster-testnet.nerochain.io", type: 0 // 設定した戦略タイプを使用 }); ``` ## ベストプラクティス 1. **制限から始める**：アプリケーションのパターンを理解するまで、控えめなガスと使用制限から始めましょう。 2. **定期的なモニタリング**：異常なアクティビティを発見するために、ダッシュボードを頻繁にチェックしましょう。 3. **複数の戦略**：異なるユーザーアクションやユーザー層に対して、異なる戦略を作成しましょう。 4. **開発用キーの分離**：開発環境と本番環境には別のAPIキーを使用しましょう。 5. **十分な資金の維持**：スポンサード取引については、常にアカウントに十分な資金を維持しましょう。 ## セキュリティに関する推奨事項 - APIキーは安全な環境変数に保存する - アプリケーションにレート制限を実装する - 異常なパターンの使用状況を監視する - 特定のドメインに対してAPIキーの使用を制限する - APIキーを機密として保持する ## 次のステップ 問題が発生した場合は、[トラブルシューティングガイド](https://docs.nerochain.io/ja/developer-tools/aa-platform/troubleshooting)をご覧ください。 --- # APIキーの管理 Source: https://docs.nerochain.io/ja/developer-tools/aa-platform/managing-api-keys Section: 開発者ツール APIキーは、Paymasterサービスでアプリケーションを認証するために不可欠です。 ## APIキーの作成 1. プロジェクトダッシュボードに移動します 2. 「API Keys」タブに移動します 3. 「Create」をクリックします 4. TestnetまたはMainnetを選択します 5. 「Create ApiKey」をクリックします ![APIキー作成画面](https://docs.nerochain.io/assets/aaPlatform/gifs/createapi.gif) *図1：APIキーの作成。* ## APIキーのセキュリティ APIキーはガススポンサーシップリソースへのアクセスを許可します。安全に保つために： - クライアント側のコードでAPIキーを公開しないでください - バックエンドでキーを保存するには環境変数を使用してください - 本番環境のキーにはドメイン制限を実装してください - 定期的にキーをローテーションしてください - 適切な使用制限を設定してください ## 次のステップ APIキーを作成した後は、以下の操作を行う必要があります： - [ポリシーを設定する](https://docs.nerochain.io/ja/developer-tools/aa-platform/configuring-policies)でユーザーがガス代をどのように支払うかを決定します - [支払いを管理する](https://docs.nerochain.io/ja/developer-tools/aa-platform/payment-management)でサービスの資金が確保されていることを確認します --- # 支払い管理 Source: https://docs.nerochain.io/ja/developer-tools/aa-platform/payment-management Section: 開発者ツール ## 残高管理機能 ![支払い概要](https://docs.nerochain.io/assets/aaPlatform/figure10.png) *図1：支払い概要* ### 残りのリクエスト数 - Paymasterが処理できる残りのリクエスト数を表示します。 - リクエスト数を増やすには、NEROにお問い合わせください。 > **_注意：_** APIの残りのリクエスト数が0の場合、十分な資金があっても、それ以上のリクエストを処理できなくなります。 ### 残りのスポンサーNERO残高 - 現在のNERO残高を表示します。 - 「Add」ボタンを使用してNEROを追加します。 > **_注意：_** ここでNEROを追加することは、APIがアプリケーションリクエストのガス代を支払うために使用する資金を意味します。 ### トークン残高テーブル トークン残高テーブルには、APIが持つすべての残高が表示されます。主にNEROトークン残高が表示されますが、ガス代として支払いが可能に設定されたトークンの残高も表示されます。アプリケーションのユーザーが設定したトークンでガス代を支払い始めると、このテーブルで残高の変化が確認できます。 #### 資金の追加 APIKeyにNEROトークンを追加するには、以下の手順に従ってください： 1. 「Add」ボタンをクリックします 2. 追加するNERO量を入力します 3. 「Confirm」をクリックしてトランザクションの処理を開始します 4. しばらくしてから残高を確認します ![資金の追加](https://docs.nerochain.io/assets/aaPlatform/gifs/deposit.gif) *図2：資金の追加* > **_注意：_** ダッシュボードの値が更新されない場合は、数回更新してください。 #### 資金の引き出し APIKeyから任意のトークン資金を引き出すには、以下の手順に従ってください： 1. 引き出したいトークンの行の資金テーブルにある「withdraw」アイコンをクリックします 2. 引き出すトークン量を入力します 3. 「Confirm」をクリックしてトランザクションの処理を開始します 4. しばらくしてから残高を確認します ![資金の引き出し](https://docs.nerochain.io/assets/aaPlatform/gifs/withdraw.gif) *図3：資金の引き出し* > **_注意：_** ダッシュボードの値が更新されない場合は、数回更新してください。 ## 次のステップ 支払いを管理した後は、以下のことができます： - [アプリケーションと統合する](https://docs.nerochain.io/ja/developer-tools/aa-platform/integration-and-best-practices)で設定したサービスの使用を開始します - 問題が発生した場合は[トラブルシューティング](https://docs.nerochain.io/ja/developer-tools/aa-platform/troubleshooting)を行います --- # NERO AA Platform - Callback 機能 Source: https://docs.nerochain.io/ja/developer-tools/aa-platform/spacify-callback Section: 開発者ツール ## 概要 NERO AA Platform では、Paymaster（ガス代支援）の判定にカスタムコールバック機能を提供しています。これにより、プロジェクト開発者は独自のビジネスロジックに基づいてガス代の無料支援を制御できます。 ## アーキテクチャ ```mermaid sequenceDiagram participant User as ユーザー participant Platform as NERO AA Platform participant Callback as カスタムコールバックサーバー User->>Platform: PaymasterAPIにリクエストを送信 Platform->>Platform: Policy確認 (isCallback=true) Platform->>Callback: POST /paymaster/callback Note over Platform,Callback: UserOperation情報 + API-SIGNATURE Callback->>Callback: ビジネスロジック実行 Callback->>Platform: レスポンス {status: 1|2|3} Platform->>User: Paymaster判定結果 ``` ## 設定方法 ### 1. プロジェクトポリシー設定 管理画面からコールバック機能を有効化し、コールバック URL を設定します。 ![Figure 12: spacify callback](https://docs.nerochain.io/assets/aaPlatform/figure12.png)

Figure 12: spacify callback

### 2. API 呼び出し ```bash POST /v1/apiKey/policy/saveOrUpdate { "projectId": 123, "policy": { "isCallback": true, "callbackUrl": "https://your-domain.com/paymaster/callback" } } ``` ## コールバックプロトコル ### リクエスト仕様 - URL: プロジェクト設定で指定したコールバック URL - メソッド: POST - Content-Type: application/json - タイムアウト: 2 秒 ### ヘッダー ``` API-SIGNATURE: MD5ハッシュ署名 Content-Type: application/json ``` ### リクエストボディ ```json { "sender": "0x1234...", "nonce": "0x1", "initCode": "0x", "callData": "0x...", "callGasLimit": "0x5208", "verificationGasLimit": "0x5208", "preVerificationGas": "0x5208", "maxFeePerGas": "0x3b9aca00", "maxPriorityFeePerGas": "0x3b9aca00", "paymasterAndData": "0x", "signature": "0x..." } ``` ### 署名検証 署名は以下の手順で生成されます。 1. リクエストボディのキーを辞書順でソート 2. `key + value` の形式で連結 3. 末尾にプロジェクトの `callbackKey` を追加 4. MD5 ハッシュを計算 ### レスポンス仕様 ```json { "status": 1 // 1: PASS, 2: NOT_PASS, 3: LIMITED } ``` ### ステータス値 | ステータス | 値 | 意味 | 動作 | | ---------- | --- | ---- | -------------------- | | PASS | 1 | 承認 | ガス代無料支援を提供 | | NOT_PASS | 2 | 拒否 | ガス代無料支援を拒否 | | LIMITED | 3 | 制限 | 制限状態としてマーク | ## サンプル実装 以下は コールバックサーバーの実装例です。 ```tsx interface PaymasterSupportedToken { sender: string; nonce: string; initCode: string; callData: string; callGasLimit: string; verificationGasLimit: string; preVerificationGas: string; maxFeePerGas: string; maxPriorityFeePerGas: string; paymasterAndData: string; signature: string; } interface PaymasterRule { is_sponsored: boolean; is_blocked: boolean; } const paymasterRules: Map = new Map([ [ "0x123456789abcdefghijk123456789abcdefghijk".toLowerCase(), { is_sponsored: true, is_blocked: false }, ], // 他のアドレスルールを追加 ]); // ビジネスロジック判定関数 function evaluateFreeGasEligibility(sender: string): number { const senderLower = sender.toLowerCase(); const rule = paymasterRules.get(senderLower); if (!rule) { console.warn("Sender address not found in rules:", sender); return 2; // NOT_PASS - ルールに存在しないアドレスは拒否 } // default: block paymaster support let supportStatus = 2; if ([rule.is](http://rule.is)_sponsored) { supportStatus = 1; } if ([rule.is](http://rule.is)_blocked) { supportStatus = 3; } return supportStatus; } const app = new Hono() .post("/paymaster/callback", async (c) => { try { const userOp = (await c.req.json()) as PaymasterSupportedToken; console.log("=== Request received ==="); console.log("Sender:", userOp.sender); // ビジネスロジックによる判定 const status = evaluateFreeGasEligibility(userOp.sender); const statusLabel = status === 1 ? "PASS" : status === 3 ? "LIMITED" : "NOT_PASS"; console.log(`Result: ${statusLabel} (status: ${status})`); console.log("======================\n"); return c.json({ status }); } catch (error) { console.error("Callback processing error:", error); return c.json({ status: 3 }); // LIMITED } }) .get("/health", (c) => c.json({ status: "ok" })); serve({ fetch: app.fetch, port: 3000, }); console.log(`Paymaster Callback server is running at http://localhost:3000`); ``` ## 動作フロー 1. ユーザーが UserOperation を送信 - フロントエンドから NERO AA Platform へリクエスト 2. プラットフォームが判定開始 - プロジェクトの Policy を確認 - `isCallback=true` かつ `callbackUrl` が設定されている場合にコールバック実行 3. コールバックリクエスト送信 - UserOperation 情報を JSON 形式で送信 - API-SIGNATURE ヘッダーで署名検証 4. カスタムサーバーでビジネスロジック実行 - アドレスホワイトリスト確認 - 使用量制限チェック - その他の独自判定 5. レスポンス処理 - ステータスに基づいて Paymaster 判定 - ガス代支援の実行／拒否 ## エラーハンドリング ### コールバックサーバーエラー時 - タイムアウト（2 秒） - 他の判定ロジックにフォールバック（confDiscount, isAll） - ネットワークエラー - PlatformException をスローし、エラーログ出力 - 不正なレスポンス - "callback status is not valid" エラー ## ベストプラクティス 1. 高速レスポンス - 2 秒以内にレスポンスを返す - 重い処理は非同期で実行 2. 冗長性 - 複数のサーバーインスタンスで LB を構成 - ダウンタイムを最小化 3. セキュリティ - 署名検証を必須実装 - HTTPS 通信を強制 4. ログ管理 - 判定結果のログを残す - 監査証跡として活用 5. フォールバック - コールバック失敗時の代替ロジックを用意 - 緊急時の手動オーバーライド機能 ## 制限事項 - コールバック URL: 最大 200 文字 - リクエストタイムアウト: 2 秒固定 - 署名アルゴリズム: MD5 固定 - プロトコル: HTTPS 推奨（HTTP 可） - 並行性: プロジェクトごとに 1 つのコールバック URL --- # トラブルシューティング Source: https://docs.nerochain.io/ja/developer-tools/aa-platform/troubleshooting Section: 開発者ツール ## 一般的な問題 - **APIキーのレート制限**: レート制限エラーが表示される場合は、キーの使用パターンを確認し、制限の引き上げを検討してください。 - **戦略の拒否**: トランザクションが拒否される場合は、戦略パラメータがアプリケーションのニーズに合っているか確認してください。 - **残高不足**: タイプ0の戦略では、スポンサーシップアカウントに十分な資金があることを確認してください。 - **ユーザー支払いの失敗**: タイプ1/2の戦略では、ユーザーが十分なトークン残高を持ち、ペイマスターコントラクトを承認していることを確認してください。 ## デバッグのヒント 1. **APIキーのステータス確認**: APIキーがアクティブで、十分なリクエスト数が残っていることを確認する 2. **ネットワーク設定の確認**: 正しいネットワークエンドポイント（テストネットvsメインネット）を使用していることを確認する 3. **トランザクションログの検査**: UserOperationsの失敗には、問題を診断するのに役立つ詳細なエラーコードが含まれていることが多い 4. **ダッシュボードの監視**: AAプラットフォームのダッシュボードは、使用統計とエラー情報を提供します ## サポートリソース 解決できない問題が発生した場合は、以下のいずれかのチャネルを通じてNerochainサポートチームにお問い合わせください： - [Discordコミュニティ](https://discord.gg/nerochainofficial) - [サポートメール](mailto:support@nerochain.io) - [GitHubイシュー](https://github.com/nerochain) --- # NERO ウォレットウェブアプリの使用方法 Source: https://docs.nerochain.io/ja/developer-tools/aa-wallet-ui-usage Section: 開発者ツール 近日公開予定のNERO ChainはNEROWalletを提供します。これは既にテストネットウェブサイトで利用可能です。以下では、クライアントで利用可能な操作手順を説明します。 ## サインアップ/ログイン ![login](https://docs.nerochain.io/assets/aaWallet/login-1.png)

図1: ログイン1

1. まず、デバイスの電源ボタンを見つけてクリックし、デバイスの電源を入れます。これにより、メインのウォレット接続画面が表示されます。 ![login](https://docs.nerochain.io/assets/aaWallet/login-2.png)

図2: ログイン2

2. 「ウォレットを接続」画面では、インストール済みおよび推奨されるウォレットオプションのリストが表示されます。下にスクロールして、推奨セクションから「NEROウォレット」を選択します。 ![login](https://docs.nerochain.io/assets/aaWallet/login-3.png)

図3: ログイン3

3. NEROウォレットを選択すると、ウォレットを設定するためのアカウント情報の入力を求められます。ウォレットに関連付けたいSNSアカウント、メールアドレス、または電話番号を入力できます。 4. 入力した情報が正しいことを確認し、画面下部の「続行」ボタンをクリックします。 5. セットアップが完了すると、メインのNEROウォレットインターフェースが読み込まれ、セットアッププロセスが完了したことを示します。 **注意:** **Bitget Wallet**や**Gate Wallet**などの他のウォレットでログインしても、AAウォレットとしてログインされます。 ## ウォレットホーム ![home](https://docs.nerochain.io/assets/aaWallet/home.png)

図4: ホーム

ホーム画面では、ユーザーが合計NERO残高を確認できるクリーンで直感的なインターフェースを提供します。その下には、送金を開始するための「送信」と、送金を受け取るためのウォレットアドレスを取得するための「受信」という2つのメインアクションボタンがあります。 また、下部には異なる機能のための3つのタブがあります。 #### 1. トークン: _トークン_では、以下を含むデフォルトトークンとその残高のリストが表示されます： - NERO（ネイティブトークン） - DAI - USDT - USDC #### 2. NFT: NFTタブではNFTコレクションが表示されます #### 3. アクティビティ: アクティビティタブでは取引履歴が表示されます。 ユーザーは任意のトークンをタップして詳細を確認できます。インターフェースはシンプルで使いやすく設計されており、必要なウォレット機能に簡単にアクセスし、トークン残高を一目で確認できます。 注意: これらのデフォルトトークンは便宜上事前設定されており、「+ トークンをインポート」機能を使用して追加のトークンを追加できます。 ## サイドバー機能 ![sidebar](https://docs.nerochain.io/assets/aaWallet/sidebar.png)

図5: サイドバー機能

サイドバーはAAウォレットアプリケーションのメインナビゲーションメニューです。メニュー項目を使用すると、デジタルウォレットの主要機能と設定にアクセスできます。 - **ロゴ** - メインホームページまたはダッシュボードに移動します - **ホーム** - ウォレットのメインダッシュボードまたはホーム画面に移動します - **送信** - トランザクションを開始できます - **マルチ送信** - 1回のトランザクションで複数のアドレスに資産を送信します - **受信** - 資産を受け取るためのQRコードとウォレットアドレスを提供します - **設定** - ウォレットの設定と構成オプションを調整します - **ウォレットを隠す** - プライバシーやセキュリティのためにメインウォレットインターフェースを隠します - **サイドバーを隠す** - 左側のナビゲーションメニューを最小化して画面スペースを確保します - **ウォレットを切断** - ログアウトしてウォレットを切断します このメニューにより、デジタル資産を効果的に管理するために必要なすべての主要機能とコントロールに簡単にアクセスできます。 ## UserOperation送信フロー すべてのアクションはトランザクションを生成するためにUserOperationを発行します ### UserOperation検証 ![userOp](https://docs.nerochain.io/assets/aaWallet/userOp.png)

図6: UserOperation送信

AAウォレットで任意のアクションを実行する前に、UserOperationの詳細を確認します。この画面には、以下を含む完全な操作データが表示されます： - 関数呼び出し - コントラクトアドレス - ABI情報 この検証ステップにより透明性が確保され、ユーザーは進行する前にトランザクションの詳細を確認できます。 ### 操作詳細画面 ![sidebar](https://docs.nerochain.io/assets/aaWallet/userOp-detail.png)

図7: UserOperation詳細

詳細には、以下を含む操作の表示が提供されます： - 操作番号とタイプ - コントラクトアドレス - 呼び出される関数 - 送信者アドレス（あなた）と受信者アドレス - ネットワーク情報 - ネットワーク手数料 ### 確認プロセス ![sidebar](https://docs.nerochain.io/assets/aaWallet/loading.png)

図8: 読み込み中

![sidebar](https://docs.nerochain.io/assets/aaWallet/success.png)

図9: 成功

1. すべての操作詳細を注意深く確認し、「確認」ボタンをクリックしてUserOperationを開始します 2. ステータス更新： - 読み込み中：トランザクションが処理中です - 成功：UserOperationが正常に作成され、ネットワークに送信されました。成功メッセージが表示されると、トランザクションが完了したことが確認されます。 ## 支払い方法 「支払い方法を選択」画面には2つのオプションがあります： ### スポンサードガス - この支払い方法により、ユーザーはガス料金を自分で支払うことなくトランザクションを完了できます。 - ガス料金はAAウォレットを統合したプロジェクトまたはプラットフォームによってカバーされます。 - ただし、_スポンサードガス_オプションは、プロジェクトがAAプラットフォームでこの機能を有効化および設定している場合にのみ利用可能です。 - 有効になっていない場合、このオプションは選択できません。 ![sponsored](https://docs.nerochain.io/assets/aaWallet/sponsored-off.png)

図10: スポンサードガス利用不可

![sponsored](https://docs.nerochain.io/assets/aaWallet/sponsored-on.png)

図11: スポンサードガス利用可能

![sponsored](https://docs.nerochain.io/assets/aaWallet/sponsored-click.png)

図12: スポンサードガスをクリック

### トークンで支払う - この支払い方法により、ユーザーは特定のERC20トークンを使用してガス料金を支払うことができます。 - AAウォレットを統合するプロジェクトまたはプラットフォームは、ガス料金をカバーするために使用できるERC20トークンを指定できます。 - 利用可能なトークンの数がユーザーに表示されます（例えば、6つのトークンが利用可能）。 ![cyog](https://docs.nerochain.io/assets/aaWallet/cyog.png)

図13: トークンで支払う

![cyog](https://docs.nerochain.io/assets/aaWallet/cyog-select.png)

図14: トークンで支払う（選択）

**注意:** デフォルトトークンはNEROToken（ネイティブトークン）です #### ガス料金の表示 **スポンサー付きガス** - スポンサー付きガスオプションが選択されると、ガス料金は0として表示され、プロジェクトがユーザーのガス料金を全額負担していることを示します。 - これにより、ユーザーはガス料金を支払うことなくトランザクションを完了できます。 ![sponsor](https://docs.nerochain.io/assets/aaWallet/gasFee-sponsor.png)

図15：スポンサー付きガス料金の表示

**トークンで支払う** - 「トークンで支払う」オプションが選択されると、ユーザーが支払う可能性のある最大のガス料金が表示されます。 - これにより、この支払い方法を使用する際に発生する可能性のあるガス料金が明確になります。 - ユーザーは、プロジェクトが指定したERC20トークンを十分に保有し、最大ガス料金をカバーできるようにする必要があります。 ![erc20](https://docs.nerochain.io/assets/aaWallet/gasFee-erc20.png)

図16：ERC20ガス料金の表示

--- # ネットワーク情報 Source: https://docs.nerochain.io/ja/developer-tools/accessEntryPoint Section: 開発者ツール ## NERO メインネット ### ネットワーク情報 | パラメータ | 値 | | :-------------- | :-------------------------------------------------------------------------------------- | | ネットワーク名 | NERO Chain メインネット | | RPCエンドポイント | https://rpc.nerochain.io | | チェーンID | 1689 | | 通貨シンボル | NERO | | エクスプローラー | https://neroscan.io | | ウォレット接続 | [ここをクリックしてウォレットをNEROメインネットに接続](https://chainlist.org/?search=Nero) | | ノードWebソケット | wss://ws.nerochain.io | | サブグラフ・サンドボックス| https://subgraph.mainnet.nero.metaborong.com/ | ### AA URL | パラメータ | 値 | | :------------ | :------------------------------------------------ | | プラットフォーム | https://aa-platform.nerochain.io/ | | プラットフォームAPI | https://api-aa-platform.nerochain.io/ | | ペイマスターRPC | https://paymaster-mainnet.nerochain.io | | バンドラー | https://bundler-mainnet.nerochain.io | | 価格サービス | https://aa-platform.nerochain.io/supported_tokens | ### コントラクトアドレス | パラメータ | 値 | | :------------- | :----------------------------------------- | | ペイマスター | 0xC42E90D29D478ccFeCC28d3B838824E57e51F284 | | エントリーポイント | 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 | | アカウントファクトリー | 0x9406Cc6185a346906296840746125a0E44976454 | | マルチコール | 0x1dA998CfaA0C044d7205A17308B20C7de1bdCf74 | ### フリーミントトークンアドレス | パラメータ | 値 | | :-------- | :----------------------------------------- | | テストトークン | 0xC86Fed58edF0981e927160C50ecB8a8B05B32fed | ## NERO テストネット ### ネットワーク情報 | パラメータ | 値 | | :-------------- | :---------------------------------------------------------------------------------------------------- | | ネットワーク名 | NERO Chain テストネット | | RPCエンドポイント | https://rpc-testnet.nerochain.io | | チェーンID | 689 | | 通貨シンボル | NERO | | エクスプローラー | https://testnet.neroscan.io | | ウォレット接続 | [ここをクリックしてウォレットをNEROテストネットに接続](https://chainlist.org/?search=Nero&testnets=true) | | ノードWebソケット | wss://ws-testnet.nerochain.io | | サブグラフ・サンドボックス | https://subgraph.testnet.nero.metaborong.com/ | ### AA URL | パラメータ | 値 | | :------------ | :------------------------------------- | | プラットフォーム | https://aa-platform.nerochain.io/ | | プラットフォームAPI | https://api-aa-platform.nerochain.io/ | | ペイマスターRPC | https://paymaster-testnet.nerochain.io | | バンドラー | https://bundler-testnet.nerochain.io/ | | 価格サービス | https://price-service.nerochain.io | ### コントラクトアドレス | パラメータ | 値 | | :------------- | :----------------------------------------- | | ペイマスター | 0x5a6680dFd4a77FEea0A7be291147768EaA2414ad | | エントリーポイント | 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 | | アカウントファクトリー | 0x9406Cc6185a346906296840746125a0E44976454 | | マルチコール | 0x343A0DdD8e58bEaf29d69936c82F1516C6677B0E | ### フォーセット フォーセットトークンをミントする： https://app.testnet.nerochain.io/faucet | パラメータ | 値 | | :-------- | :----------------------------------------- | | DAI | 0x5d0E342cCD1aD86a16BfBa26f404486940DBE345 | | USDT | 0x1dA998CfaA0C044d7205A17308B20C7de1bdCf74 | | USDC | 0xC86Fed58edF0981e927160C50ecB8a8B05B32fed | ### フリーミントトークンアドレス | パラメータ | 値 | | :-------- | :----------------------------------------- | | テストトークン | 0xA919e465871871F2D1da94BccAF3acaF9609D968 | > **_注意:_** 関数mint(address to, uint256 amount)を呼び出すことで自由にミント可能 --- # 開発者ツール＆アカウント抽象化 Source: https://docs.nerochain.io/ja/developer-tools Section: 開発者ツール NEROの開発者ツールスイートを探索し、高度なアカウント抽象化機能について学びましょう。 ## 開発者ツール - UserOpSdk SDK - Paymaster API - Paymaster プラットフォーム - NEROWallet（近日公開！） サイドバーからトピックを選択して、NEROの開発者ツールとアカウント抽象化機能について詳しく学びましょう。 --- # ベストプラクティス Source: https://docs.nerochain.io/ja/developer-tools/paymaster-api/best-practices Section: 開発者ツール ## 1. UserOpSDKを活用する SDKはペイマスターAPIとUserOperationsとのやり取りに関連する複雑さの多くを管理します。リトライと組み込みのエラー処理により、統合が大幅に簡素化されます。 ## 2. サポートされているトークンをキャッシュする サポートされているトークンのリストを定期的に更新して、頻繁なAPIリクエストを防ぎます。これによりサーバーの負担が軽減され、パフォーマンスが向上します。 ## 3. 適切なエラー処理を適用する 常に障害の種類に応じてエラーをキャッチし、適切に処理してください。ネットワーク問題などの特定のエラーは_再試行可能_かもしれませんが、不適切なパラメーターなどの他のエラーは人間の介入を必要とします。 ## 4. トークン承認を評価する タイプ1と2の支払いでは、UserOperationを転送する前にユーザーのトークン支払い承認を確認してください。これによりユーザーエクスペリエンスが向上し、無駄な失敗を排除するのに役立ちます。 ## 5. APIキーを安全に保管する クライアント向けに書かれたコードにAPIキーを表示しないでください。常にバックエンドシステムで安全に保管してください。 ## 6. 消費量を追跡する クォータを超えることによる予期しないサービス停止を防ぐために、AAプラットフォームでスポンサーシップの使用状況を追跡してください。 ## 7. 適切なガス制限を設定する ガス見積もり方法を使用して、UserOperationsの正確なガス値を取得してください。適切な制限により費用が最適化され、トランザクションの失敗を最小限に抑えるのに役立ちます。 ## 8. レート制限とクォータ APIの使用は、AAプラットフォームアカウントにある設定によって制限されています： - 日次ガス制限 - トランザクション数制限 - トークン許可リスト - ガス価格上限 これらの設定は[AAプラットフォーム](https://aa-platform.nerochain.io)で監視および調整できます。 --- # コアJSON-RPCメソッド Source: https://docs.nerochain.io/ja/developer-tools/paymaster-api/core-methods Section: 開発者ツール ペイマスターAPIはJSON-RPCを使用しており、これはEthereum互換ノードと通信するための標準です。以下が利用可能な主要なメソッドです： ## pm_supported_tokens ペイマスターがガス支払いをサポートするERC20トークンのリストと価格情報を取得します。 **パラメータ：** 1. `userOperation` - 少なくともsenderフィールドを含む最小限のUserOperationオブジェクト 2. `apiKey` - AAプラットフォームから取得したAPIキー 3. `entryPoint` - EntryPointコントラクトアドレス（通常は`0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789`） **リクエスト例：** ```json { "jsonrpc": "2.0", "id": 1, "method": "pm_supported_tokens", "params": [ { "sender": "0xAAWalletAddress", "nonce": "0x0", "initCode": "0x", "callData": "0x", "callGasLimit": "0x0", "verificationGasLimit": "0x0", "preVerificationGas": "0x0", "maxFeePerGas": "0x0", "maxPriorityFeePerGas": "0x0", "paymasterAndData": "0x", "signature": "0x" }, "YOUR_API_KEY", "0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789" ] } ``` **レスポンス例：** ```json { "jsonrpc": "2.0", "id": 1, "result": { "freeGas": true, "native": { "gas": "0x337dc", "price": 1, "decimals": 18, "symbol": "NERO" }, "tokens": [ { "type": "system", "token": "0xD5a6dcff7AC339A03f6964c315575bF65c3c6cF6", "symbol": "DAI", "decimals": 18, "price": 2.1 }, { "type": "custom", "token": "0x13DCf97b6B94bDA883492AB46d556E8919445876", "symbol": "TestToken", "decimals": 18, "price": 0.1 } ] } } ``` このレスポンスでは： - `freeGas`はガススポンサーシップ（タイプ0）が利用可能かどうかを示します - `native`はネイティブトークン（NERO）に関する情報を提供します - `tokens`はNEROに対する相対価格比率を持つすべてのサポート対象ERC20トークンをリストします ## pm_sponsor_userop ペイマスターでUserOperationに署名し、スポンサードまたはトークン支払いトランザクションに必要なpaymasterAndDataフィールドを追加します。 **パラメータ：** 1. `userOperation` - 署名される完全なUserOperation 2. `apiKey` - AAプラットフォームから取得したAPIキー 3. `entryPoint` - EntryPointコントラクトアドレス 4. `context` - 支払い詳細を含むオブジェクト： - `type` - 支払いタイプ（0：スポンサード、1：前払い、2：後払い） - `token` - ERC20トークンアドレス（タイプ1と2では必須） **無料ガス（タイプ0）のリクエスト例：** ```json { "jsonrpc": "2.0", "id": 1, "method": "pm_sponsor_userop", "params": [ { "sender": "0xAAWalletAddress", "nonce": "0x0", "initCode": "0x", "callData": "0xCallData", "callGasLimit": "0x88b8", "verificationGasLimit": "0x33450", "preVerificationGas": "0xc350", "maxFeePerGas": "0x9502f900", "maxPriorityFeePerGas": "0x9502f900", "paymasterAndData": "0x", "signature": "0xUserSignature" }, "YOUR_API_KEY", "0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789", { "type": 0 } ] } ``` **ERC20支払い（タイプ1）のリクエスト例：** ```json { "jsonrpc": "2.0", "id": 1, "method": "pm_sponsor_userop", "params": [ { "sender": "0xAAWalletAddress", "nonce": "0x0", "initCode": "0x", "callData": "0xCallData", "callGasLimit": "0x88b8", "verificationGasLimit": "0x33450", "preVerificationGas": "0xc350", "maxFeePerGas": "0x9502f900", "maxPriorityFeePerGas": "0x9502f900", "paymasterAndData": "0x", "signature": "0xUserSignature" }, "YOUR_API_KEY", "0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789", { "type": 1, "token": "0xTokenAddress" } ] } ``` **レスポンス例：** ```json { "jsonrpc": "2.0", "id": 1, "result": { "sender": "0xAAWalletAddress", "nonce": "0x0", "initCode": "0x", "callData": "0xCallData", "callGasLimit": "0x88b8", "verificationGasLimit": "0x33450", "preVerificationGas": "0xc350", "maxFeePerGas": "0x9502f900", "maxPriorityFeePerGas": "0x9502f900", "paymasterAndData": "0xPaymasterAddress+EncodedData+PaymasterSignature", "signature": "0xUserSignature" } } ``` ## pm_entrypoints 現在サポートされているEntryPointアドレスを取得します。 リクエスト： ```json { "jsonrpc": "2.0", "id": 1, "method": "pm_entrypoints", "params": [ "entryPoint" ] } ``` レスポンス： ```json { "jsonrpc": "2.0", "id": 1, "result": [ "0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789" ] } ``` --- # エラー処理 Source: https://docs.nerochain.io/ja/developer-tools/paymaster-api/error-handling Section: 開発者ツール ペイマスターAPIを統合する際には、適切なエラー処理が不可欠です。このセクションでは、遭遇する可能性のある一般的なエラーと堅牢な実装のためのベストプラクティスについて説明します。 ## 一般的なエラーコード トランザクションの送信などのペイマスターAPIとのやり取りでは、標準的なJSON-RPCエラーが返されることがあります。以下は一般的なエラーコードとその意味です： これらのエラーの多くには、EntryPointからの追加のエラーメッセージも含まれています。 |コード | 説明| |------------|-------------| |-32521 | 実行フェーズ中にトランザクションがリバートした（またはリバートする予定）。| |-32602 | 無効なUserOperation構造体/フィールド。| |-32500 | アカウント作成または検証中にentryPointのsimulateValidationによってトランザクションが拒否された。| |-32501 | paymasterのvalidatePaymasterUserOpによってトランザクションが拒否された。| |-32502 | オペコード検証によってトランザクションが拒否された。| |-32503 | UserOperationが時間範囲外：アカウントまたはペイマスターが時間範囲を返し、既に期限切れ（またはすぐに期限切れになる）。| |-32504 | ペイマスター（または署名アグリゲーター）がスロットル/禁止されているためトランザクションが拒否された。| |-32505 | ペイマスター（または署名アグリゲーター）のステークまたはアンステーク遅延が低すぎるためトランザクションが拒否された。| |-32506 | アカウントが未サポートの署名アグリゲーターを指定したためトランザクションが拒否された。| |-32507 | validateUserOpまたはvalidatePaymasterUserOpが無効な署名チェックを返した。| ## 一般的な特定エラー バンドラーエラーコードには、追加のガイダンスを提供するためにEntryPointによって提供される追加のAAxxコードが付随していることがよくあります。 - AA1xエラーコードはアカウントの作成に関連しています - AA2xエラーコードはユーザー操作の送信者に関連しています - AA3xエラーコードはペイマスターに関連しています - AA4xエラーコードは一般的な検証に関連しています - AA5xエラーはユーザー操作が実行された後のアクションに関連しています --- # ペイマスターAPI Source: https://docs.nerochain.io/ja/developer-tools/paymaster-api Section: 開発者ツール 開発者がdAppsでガス抽象化を使用できるようにすることで、NerochainペイマスターAPIはユーザーがERC20トークンを使用してガスコストを支払ったり、トランザクションを完全にスポンサーしたりすることを可能にします。このガイドでは、統合のための推奨プラクティス、リクエスト/レスポンス形式、APIエンドポイントについて説明します。 ## 概要 ペイマスターAPIはあなたのdAppとNerochainブロックチェーンの間に位置し、以下のサービスを提供します： 1. ユーザーのガス料金をスポンサーする。 2. ユーザーがERC20トークンでガスを支払えるようにする。 3. バンドラーに送信される前にUserOperationを検証して署名する。 4. ユーザーのトランザクションに設定したガス戦略を適用する。 ![ペイマスターAPIフロー](https://docs.nerochain.io/assets/aaPlatform/figure2.jpeg) *図1：ペイマスターAPIの統合/使用フロー* ## APIエンドポイント ### ベースURL ペイマスターAPIは以下で利用可能です： ``` https://paymaster-testnet.nerochain.io ``` メインネット向け： ``` https://paymaster-mainnet.nerochain.io ``` ### 認証 すべてのAPIリクエストには、[AAプラットフォーム](https://aa-platform.nerochain.io)を通じて作成されたAPIキーが必要です。APIキーはRPC呼び出しのパラメータとして含める必要があります。 ## このセクションの内容 - [コアメソッド](./paymaster-api/core-methods) - すべてのペイマスターAPIメソッドの詳細なAPIリファレンス - [支払いタイプ](./paymaster-api/payment-types) - 異なる支払いタイプの説明 - [エラー処理](./paymaster-api/error-handling) - 一般的なエラーとトラブルシューティング - [ベストプラクティス](./paymaster-api/best-practices) - ペイマスターを統合する際に念頭に置くべきこと --- # 支払いタイプ Source: https://docs.nerochain.io/ja/developer-tools/paymaster-api/payment-types Section: 開発者ツール ペイマスターは、ガス料金の処理方法に柔軟性を提供する3つの支払いタイプをサポートしています。各タイプは異なるメリットとトレードオフを提供します。 ## タイプ0：無料ガス（スポンサード） 開発者がユーザーのガス料金を完全にスポンサーします。以下のケースに最適です： - ユーザーのオンボーディング - プロモーションキャンペーン - UXの簡素化 - GameFiアプリケーション このタイプを使用するには、`pm_sponsor_userop`を呼び出す際にコンテキストオブジェクトで`type: 0`を設定します。 ## タイプ1：ERC20での前払い ユーザーはトランザクション実行前にERC20トークンでガスを支払います： 1. 検証フェーズ中に全額の見積もりが事前に収集されます 2. 実行後に余剰分は返金されます 3. トランザクション前にトークン承認が必要です このタイプを使用するには： - コンテキストオブジェクトで`type: 1`を設定します - コンテキストオブジェクトに`token`アドレスを含めます - ユーザーがペイマスターコントラクトにトークンを使用する権限を与えていることを確認します ## タイプ2：ERC20での後払い ユーザーはトランザクション実行後にERC20トークンでガスを支払います： 1. トランザクション完了後に正確なガスコストのみが収集されます 2. 実行前にトークン承認が必要です 3. ユーザーは必要な分だけ支払うため、UXが向上します 4. UserOperationがトークンを使い果たした場合、実行後の支払い失敗のリスクがあります このタイプを使用するには： - コンテキストオブジェクトで`type: 2`を設定します - コンテキストオブジェクトに`token`アドレスを含めます - ユーザーがペイマスターコントラクトにトークンを使用する権限を与えていることを確認します ## 適切な支払いタイプの選択 どの支払いタイプを使用するかを決定する際には、以下の要素を考慮してください： - **タイプ0（無料）**：新規ユーザー獲得に最適ですが、開発者のコストが増加します - **タイプ1（前払い）**：より信頼性が高いですが、ユーザーは必要な量よりもわずかに多くのトークンを持っている必要があります - **タイプ2（後払い）**：最高のユーザーエクスペリエンスを提供しますが、失敗のリスクがあります ほとんどのアプリケーションでは、初回ユーザーや特定のアクションには無料ガスを提供し、通常の操作にはトークン支払いを使用するなど、支払いタイプの組み合わせを使用しています。 --- # 高度な使用法 Source: https://docs.nerochain.io/ja/developer-tools/user-op-sdk/advanced-usage Section: 開発者ツール このセクションでは、UserOperationsの高度なカスタマイズオプションについて説明します。 ## カスタムガスパラメータ UserOperationsのガスパラメータをカスタマイズできます： ```typescript // 特定のガス値を設定 builder.setCallGasLimit("0x88b8"); builder.setVerificationGasLimit("0x33450"); builder.setPreVerificationGas("0xc350"); builder.setMaxFeePerGas("0x2162553062"); builder.setMaxPriorityFeePerGas("0x40dbcf36"); ``` ## カスタムナンス管理 必要に応じて、UserOperationsのナンスを手動で設定できます： ```typescript // 現在のナンスを取得 const aaWallet = new ethers.Contract( aaWalletAddress, ['function getNonce() view returns (uint256)'], accountSigner ); const nonce = await aaWallet.getNonce(); // カスタムナンスを設定 builder.setNonce(nonce.add(1)); ``` ## 追加のカスタマイズ ガスパラメータとナンス管理以外にも、以下のことができます： - 署名メカニズムのカスタマイズ - 独自のアカウントアブストラクションロジックの実装 - 特定のユースケース向けのカスタムプリセットの作成 ## 次のステップ 高度なカスタマイズオプションについて学んだ後、以下のことを検討するかもしれません： - [エラー処理について学ぶ](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/error-handling) - [ベストプラクティスを確認する](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/best-practices) --- # インストールと基本的な使い方 Source: https://docs.nerochain.io/ja/developer-tools/user-op-sdk/basic-usage Section: 開発者ツール ## インストール GitHubから直接UserOpSDKをインストールできます： ```bash npm install github:nerochain/aa-userop-sdk ``` または、yarnを使用： ```bash yarn add github:nerochain/aa-userop-sdk ``` ## 基本的な使い方 このセクションでは、UserOpSDKの使用を開始するための基本的なステップを説明します。 ### SDKのインポート ```typescript ``` ### 設定定数 必要なコントラクトアドレスとサービスエンドポイントで設定を行います： ```typescript // Chain configuration const NERO_RPC_URL = "https://rpc-testnet.nerochain.io"; const BUNDLER_URL = "https://bundler-testnet.nerochain.io/"; const PAYMASTER_URL = "https://paymaster-testnet.nerochain.io"; // Contract addresses const ENTRYPOINT_ADDRESS = "0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789"; const ACCOUNT_FACTORY_ADDRESS = "0x9406Cc6185a346906296840746125a0E44976454"; ``` ### クライアントの初期化 ```typescript // Initialize the AA Client const client = await Client.init(NERO_RPC_URL, { overrideBundlerRpc: BUNDLER_URL, entryPoint: ENTRYPOINT_ADDRESS, }); ``` ### SimpleAccountビルダーの作成 SimpleAccountビルダーは、UserOperationsの作成と設定をサポートします： ```typescript // accountSigner is the EOA wallet that will own the AA wallet const builder = await Presets.Builder.SimpleAccount.init( accountSigner, NERO_RPC_URL, { overrideBundlerRpc: BUNDLER_URL, entryPoint: ENTRYPOINT_ADDRESS, factory: ACCOUNT_FACTORY_ADDRESS, } ); ``` ## 次のステップ クライアントとビルダーをインストール、初期化したら、次のことができます： - [AAウォレットの操作](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/working-with-wallets) - [UserOperationsの作成](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/creating-user-operations) --- # ベストプラクティス Source: https://docs.nerochain.io/ja/developer-tools/user-op-sdk/best-practices Section: 開発者ツール 本番アプリケーションでUserOpSDKの使用を最適化するために、これらのベストプラクティスに従ってください。 ## 1. AAウォレットアドレスをキャッシュする 冗長な計算を避けるために、AAウォレットアドレスを計算して保存します： ```typescript // 一度計算してデータベースやローカルストレージに保存 const aaWalletAddress = await builder.getSender(); ``` ## 2. 包括的なエラー処理を実装する ユーザーエクスペリエンスを向上させるために、すべての潜在的なエラーを適切に処理します： ```typescript try { const result = await client.sendUserOperation(builder); // 成功パス } catch (error) { // 異なるエラータイプを分類して処理 if (error.message.includes('AA21')) { // 資金不足を処理 } else if (error.message.includes('AA31')) { // ペイマスター検証エラーを処理 } else { // 一般的なエラー処理 } } ``` ## 3. ガス見積もり 複雑な操作では、十分なガスを確保するためにガス見積もり関数を使用します： ```typescript // 送信前にガスを見積もる const gasEstimation = await client.estimateUserOperationGas(builder); builder.setCallGasLimit(gasEstimation.callGasLimit); builder.setVerificationGasLimit(gasEstimation.verificationGasLimit); builder.setPreVerificationGas(gasEstimation.preVerificationGas); ``` ## 4. テストネットでテストする メインネットにデプロイする前に、必ずNERO Chainのテストネットで実装をテストしてください： ```typescript // テストネット設定 const NERO_TESTNET_RPC_URL = "https://rpc-testnet.nerochain.io"; const TESTNET_BUNDLER_URL = "https://bundler-testnet.nerochain.io"; const TESTNET_PAYMASTER_URL = "https://paymaster-testnet.nerochain.io"; ``` ## 5. セキュリティ 秘密鍵やAPIキーをクライアントサイドコードに保存しないでください： ```typescript // 悪い例：ハードコードされたAPIキー const PAYMASTER_API_KEY = "your-api-key"; // これはしないでください！ // 良い例：サーバー上で環境変数から読み込む const PAYMASTER_API_KEY = process.env.PAYMASTER_API_KEY; ``` ## 追加リソース 詳細と高度なユースケースについては、以下のリソースを参照してください： - [ERC-4337仕様](https://eips.ethereum.org/EIPS/eip-4337) - [UserOpSDK GitHubリポジトリ](https://github.com/nerochain/aa-userop-sdk) --- # UserOperationsの作成 Source: https://docs.nerochain.io/ja/developer-tools/user-op-sdk/creating-user-operations Section: 開発者ツール このパートでは、SDKを使用してさまざまな種類のUserOperationsを作成する方法について説明します。 ## 最小限のUserOperationsを理解する ユーザー操作には標準的な構造があるため、特定のトランザクションを開始する前に理解することが重要です。単純なユーザー操作には、プレースホルダー値であっても、必要なフィールドがすべて含まれています： ```typescript // Create a minimal UserOp const minimalUserOp = { sender: aaWalletAddress, // The AA wallet address nonce: "0x0", // Will be filled by the SDK or custom logic initCode: "0x", // Empty for existing wallets callData: "0x", // Will be filled with actual transaction data callGasLimit: "0x0", // Gas estimation verificationGasLimit: "0x0", preVerificationGas: "0x0", maxFeePerGas: "0x0", maxPriorityFeePerGas: "0x0", paymasterAndData: "0x", // Will be filled by Paymaster integration signature: "0x" // Will be filled with EOA signature }; ``` この最小限の構造は以下の目的に役立ちます： - UserOperation構造を必要とするRPC呼び出しを行う - 特定の詳細を入力する前にUserOperationを初期化する - テストとデバッグ - PaymasterAPIなどのサービスとの対話 UserOpSDKは自動的にこれらのフィールドのほとんどを埋めてくれますが、SDKを使用してカスタムユーティリティを開発する際には、この構造を理解しておくと役立ちます。 ## 単純なトークン送金 ERC-20トークンの単純な送金を実行するには、[基本的な使い方](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/basic-usage)セクションで作成したビルダーから始めて、特定のトランザクションを追加します： ```typescript // 1. Start with the builder from previous setup // const builder = await Presets.Builder.SimpleAccount.init(...); // 2. Create an ERC-20 contract instance const tokenContract = new ethers.Contract( tokenAddress, ['function transfer(address to, uint256 amount) returns (bool)'], accountSigner ); // 3. Prepare the call data for transfer const callData = tokenContract.interface.encodeFunctionData( 'transfer', [recipientAddress, ethers.utils.parseUnits(amount, decimals)] ); // 4. Add the transaction to the builder // This will incorporate the transaction into a UserOperation builder.execute(tokenAddress, 0, callData); // 5. The builder now contains the UserOperation with your transfer // Under the hood, it fills in the parameters of the minimal UserOperation: // - sender: from builder.getSender() // - nonce: auto-retrieved from the AA wallet // - callData: your transfer function call // - gas parameters: estimated or set manually ``` `builder.execute()`を呼び出すと、SDKはトランザクションをUserOperation構造に組み込み、最小限のUserOperationの各フィールドを手動で構築する必要がなくなります。 ## 複数のトランザクションの実行 同じビルダーパターンを使用して、複数のアクションを単一のUserOperationにバンドルできます： ```typescript // 1. Start with the same builder // const builder = await Presets.Builder.SimpleAccount.init(...); // 2. Prepare multiple call data and targets const callData = [ tokenContract.interface.encodeFunctionData('approve', [spender, amount]), tokenContract.interface.encodeFunctionData('transfer', [recipient, amount]) ]; const callTo = [tokenAddress, tokenAddress]; // 3. Add batch execution to the builder // This bundles multiple transactions into a single UserOperation builder.executeBatch(callTo, callData); // 4. The builder now contains a UserOperation with multiple actions // The single UserOperation will: // - Approve tokens to be spent by another address // - Transfer tokens to the recipient // All in one atomic transaction ``` バッチ実行機能により、複数のアクションが単一のUserOperationの`callData`フィールドに結合され、複雑な操作を効率的に実行できます。 ## 次のステップ ビルダーでUserOperationsを作成した後： - ガス支払いを処理するために[Paymasterと統合する](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/paymaster-integration) - [UserOperationsをネットワークに送信する](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/sending-user-operations) --- # エラー処理 Source: https://docs.nerochain.io/ja/developer-tools/user-op-sdk/error-handling Section: 開発者ツール UserOpSDKは操作中にさまざまなエラーを返す可能性があります。このセクションでは、一般的なエラーとその処理方法について説明します。 ## 一般的なエラータイプ ```typescript try { const result = await client.sendUserOperation(builder); // 結果を処理 } catch (error) { if (error.message.includes('AA1')) { console.error('アカウント作成に関連するエラーコード'); // 資金不足エラーを処理 } else if (error.message.includes('AA2')) { console.error('ユーザー操作の送信者に関連するエラーコード'); // 検証エラーを処理 } else if (error.message.includes('AA3')) { console.error('ペイマスターに関連するエラーコード'); // ペイマスターエラーを処理 } else if (error.message.includes('AA4')) { console.error('一般的な検証に関連するエラーコード'); // ペイマスターエラーを処理 } else if (error.message.includes('AA5')) { console.error('ユーザー操作が実行された後のアクションに関連するエラー'); // ペイマスターエラーを処理 } else { console.error('不明なエラー:', error); // その他のエラーを処理 } } ``` ## エラーコードカテゴリ - **AA1** - アカウント作成エラー（例：反実仮想デプロイメントのための資金不足） - **AA2** - 送信者エラー（例：無効な署名） - **AA3** - ペイマスターエラー（例：預金不足、操作拒否） - **AA4** - 一般的な検証エラー - **AA5** - 実行後のエラー ## ユーザーフレンドリーなエラー処理 ユーザーインターフェースを構築する際は、技術的なエラーをユーザーフレンドリーなメッセージに変換します： ```typescript function getUserFriendlyErrorMessage(error) { if (error.message.includes('AA21')) { return "このトランザクションを支払うのに十分な資金がありません。"; } else if (error.message.includes('AA23')) { return "トランザクション署名が無効です。もう一度お試しください。"; } else if (error.message.includes('AA25')) { return "ガス支払いの詳細が無効です。別の支払いオプションを選択してください。"; } else { return "トランザクションの処理中にエラーが発生しました。もう一度お試しください。"; } } ``` ## 次のステップ エラー処理を実装した後、以下のことを検討するかもしれません： - SDKを使用するための[ベストプラクティスを確認する](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/best-practices) --- # UserOpSDK: アカウントアブストラクションSDK Source: https://docs.nerochain.io/ja/developer-tools/user-op-sdk Section: 開発者ツール UserOpSDKは強力なJavaScript/TypeScriptツールとして設計され、NERO Chain上でのUserOperationsの作成、署名、送信を効率化します。このセクションでは、SDKを使用してdAppでアカウントアブストラクション機能を活用する方法をサポートします。 UserOpSDKは、NERO Chain上の基本的なアカウントアブストラクション機能へのアクセスを提供し、以下のような機能があります： - コントラクト呼び出しや送金のためのUserOperationsの作成 - イーサリアム署名者によるUserOperationsの署名 - トランザクションを実行するためのバンドラーとの通信 - ガススポンサーシップやERC-20トークン受け入れのためのPaymasterとの統合 - スマートコントラクトウォレットの作成と管理 このセクションでは、SDKの使い方と一般的な操作の例を紹介します。 ## 目次 - [インストールと基本的な使い方](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/basic-usage) - SDKのインストール方法と始め方 - [AAウォレットの操作](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/working-with-wallets) - ウォレットアドレスの取得とデプロイステータスの確認 - [UserOperationsの作成](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/creating-user-operations) - 単純な操作とバッチ操作の作成 - [Paymasterの統合](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/paymaster-integration) - APIキーの設定、サポートされているトークンの取得、支払いタイプ - [UserOperationsの送信](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/sending-user-operations) - 操作をネットワークに送信する方法 - [高度な使用法](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/advanced-usage) - カスタムガスパラメータとナンス管理 - [エラー処理](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/error-handling) - 一般的なエラーとその対処法 - [ベストプラクティス](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/best-practices) - 最適なSDK使用のためのヒント --- # Paymasterの統合 Source: https://docs.nerochain.io/ja/developer-tools/user-op-sdk/paymaster-integration Section: 開発者ツール Paymasterサービスは、UserOperationsに対して柔軟なガス支払いオプションを提供します。 ## Paymaster用のAPIキーの設定 Paymasterサービスを使用するには、APIキーを設定します： ```typescript builder.setPaymasterOptions({ apikey: YOUR_API_KEY, rpc: PAYMASTER_URL }); ``` ## サポートされているトークンの取得 SDKにはサポートされているトークンを取得するための組み込みメソッドはありません。Paymaster APIに直接RPCコールを行う必要があります： ```typescript // サポートされているトークンを取得するヘルパー関数を作成 async function getSupportedTokens(client, builder) { try { // ウォレットアドレスを取得 const sender = await builder.getSender(); // リクエスト用の最小限のUserOpを作成 const minimalUserOp = { sender, nonce: "0x0", initCode: "0x", callData: "0x", callGasLimit: "0x0", verificationGasLimit: "0x0", preVerificationGas: "0x0", maxFeePerGas: "0x0", maxPriorityFeePerGas: "0x0", paymasterAndData: "0x", signature: "0x" }; // paymaster RPC用のプロバイダーを設定 const provider = new ethers.providers.JsonRpcProvider(PAYMASTER_URL); // pm_supported_tokensメソッドを呼び出す const tokensResponse = await provider.send("pm_supported_tokens", [ minimalUserOp, YOUR_API_KEY, ENTRYPOINT_ADDRESS ]); // トークンリストを解析して返す if (tokensResponse && tokensResponse.tokens) { return tokensResponse.tokens.map(token => ({ address: token.token || token.address, decimals: token.decimals, symbol: token.symbol, type: token.type })); } return []; } catch (error) { console.error("サポートされているトークンの取得エラー:", error); return []; } } // 使用例 const supportedTokens = await getSupportedTokens(client, builder); console.log("サポートされているトークン:", supportedTokens); ``` 異なるPaymaster実装では、トークンが異なる形式で返される場合があります。より堅牢な実装では、この例に示すようにさまざまなレスポンス形式の処理が含まれます： ```typescript // 異なるレスポンス形式を処理 let tokens = []; if (tokensResponse.tokens) { tokens = tokensResponse.tokens; } else if (Array.isArray(tokensResponse)) { tokens = tokensResponse; } else if (typeof tokensResponse === 'object') { // レスポンスオブジェクト内でトークンを見つける const possibleTokensArray = Object.values(tokensResponse).find(val => Array.isArray(val)); if (possibleTokensArray && Array.isArray(possibleTokensArray)) { tokens = possibleTokensArray; } } ``` ## 支払いタイプの設定 ユーザーがガスをどのように支払うかを設定します： ```typescript // タイプ0：無料ガス（開発者がスポンサー） builder.setPaymasterOptions({ type: 0, apikey: YOUR_API_KEY, rpc: PAYMASTER_URL }); // タイプ1：ERC20トークンでの前払い builder.setPaymasterOptions({ type: 1, token: TOKEN_ADDRESS, // ERC20トークンアドレス apikey: YOUR_API_KEY, rpc: PAYMASTER_URL }); // タイプ2：ERC20トークンでの後払い builder.setPaymasterOptions({ type: 2, token: TOKEN_ADDRESS, // ERC20トークンアドレス apikey: YOUR_API_KEY, rpc: PAYMASTER_URL }); ``` ## 次のステップ UserOperationのPaymasterを設定した後、以下のことができます： - [UserOperationsをネットワークに送信する](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/sending-user-operations) - カスタマイズのための[高度なオプションを探索する](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/advanced-usage) --- # UserOperationsの送信 Source: https://docs.nerochain.io/ja/developer-tools/user-op-sdk/sending-user-operations Section: 開発者ツール UserOperationの設定が完了したら、それをネットワークに送信できます。このセクションでは、操作の送信と結果の処理について説明します。 ## UserOperationの送信 ```typescript try { // UserOperationを送信 const result = await client.sendUserOperation(builder); // トランザクションハッシュを取得 const userOpHash = result.userOpHash; console.log("UserOperation ハッシュ:", userOpHash); // トランザクションがマイニングされるのを待つ const receipt = await result.wait(); console.log("トランザクションハッシュ:", receipt.transactionHash); return receipt; } catch (error) { console.error("UserOperation送信エラー:", error); throw error; } ``` ## UserOperationのステータス監視 UserOperationを送信した後、そのステータスを監視できます： 1. まず、`sendUserOperation`の結果から`userOpHash`を取得します。 2. 次に、操作がブロックに含まれるのを待つために結果に対して`wait()`を使用できます。 3. レシートにはトランザクションハッシュが含まれており、これを使用してブロックエクスプローラーで詳細を検索できます。 ## 次のステップ UserOperationsの送信後、以下のことを検討するかもしれません： - カスタマイズのための[高度なオプションを探索する](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/advanced-usage) - より良いユーザーエクスペリエンスのための[エラー処理について学ぶ](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/error-handling) --- # AAウォレットの操作 Source: https://docs.nerochain.io/ja/developer-tools/user-op-sdk/working-with-wallets Section: 開発者ツール アカウントアブストラクションウォレットは各EOAウォレットに対して決定論的に生成されます。このセクションでは、これらのAAウォレットの操作方法について説明します。 ## AAウォレットアドレスの取得 各EOAウォレットには、決定論的に生成される対応するAAウォレットアドレスがあります： ```typescript // Get the AA wallet address (works even if not yet deployed on-chain) const aaWalletAddress = await builder.getSender(); console.log("AA Wallet Address:", aaWalletAddress); ``` ## AAウォレットのデプロイ状態の確認 AAウォレットが既にデプロイされているかどうかを確認できます： ```typescript const provider = new ethers.providers.JsonRpcProvider(NERO_RPC_URL); const code = await provider.getCode(aaWalletAddress); const isDeployed = code !== '0x'; console.log("Wallet deployed:", isDeployed); ``` ## 次のステップ AAウォレットアドレスの操作後、次のことができます： - [UserOperationsの作成](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/creating-user-operations) - [Paymasterとの統合](https://docs.nerochain.io/ja/developer-tools/user-op-sdk/paymaster-integration) --- # よくある質問 Source: https://docs.nerochain.io/ja/faq Section: faq このFAQでは、NERO Chainでの開発において開発者が直面する一般的な課題、落とし穴、質問に回答します。 ## アカウントアブストラクション ### アカウントアブストラクションとは正確には何ですか？ アカウントアブストラクション（AA）は、ユーザーがガス代用のネイティブトークン（NERO）を保持する必要なく、スマートコントラクトウォレットがトランザクションを実行できるようにするパラダイムです。アカウントアブストラクション（AA）により、トランザクションのスポンサーシップ、バッチ処理トランザクション、複雑な認証方法などの機能が可能になり、アカウント管理ロジックをトランザクション検証から分離することができます。 ### なぜUserOperationsが拒否され続けるのですか？ UserOperationsが拒否される理由はいくつかあります： - **無効な署名**：ウォレット用の正しい署名者を使用していることを確認してください - **ガス不足**：ガス制限を増やすか、SDKのガス見積もり関数を使用してみてください - **ペイマスターの拒否**：ペイマスターAPIキーが有効で、十分な資金があることを確認してください。APIキーに十分な残りのリクエスト数があるかを確認してください。リクエスト数が不足している場合は、NEROチームにお問い合わせください。 - **ノンス問題**：アカウントに対して正しいノンスを使用していることを確認してください - **検証の失敗**：スマートコントラクトウォレットは、その要件を満たさない操作を拒否する場合があります ### AAエラーコードのデバッグ方法は？ エラーコードは以下のパターンに従います： - **AA1**コードはアカウントの作成に関連しています（例：デプロイメントのための資金不足） - **AA2**コードは送信者に関連しています（例：無効な署名） - **AA3**コードはペイマスターに関連しています（例：デポジット不足） - **AA4**コードは一般的な検証の失敗に関連しています - **AA5**コードは実行後の問題に関連しています ## ペイマスター統合 ### スポンサード・トランザクションが失敗する理由は？ ペイマスターが失敗する一般的な理由には以下があります： - **APIキーのレート制限**：キーの使用パターンを確認し、制限の引き上げを検討してください - **戦略の拒否**：戦略パラメータがアプリケーションのニーズと一致していることを確認してください - **資金不足**：Type 0戦略の場合、スポンサーシップアカウントに十分な資金があることを確認してください - **ユーザー支払いの失敗**：Type 1/2戦略の場合、ユーザーが十分なトークン残高を持ち、ペイマスターコントラクトを承認していることを確認してください - **残りのリクエスト数不足**：APIに十分な残りのリクエスト数があるかを確認してください ### 支払い戦略タイプの違いは何ですか？ - **Type 0（スポンサーシップ）**：ガス料金は開発者/アプリケーションによって完全にカバーされます - **Type 1（ERC-20前払い）**：ユーザーは実行前にERC-20トークンでガス料金を支払います - **Type 2（ERC-20後払い）**：ユーザーは実行後にERC-20トークンでガス料金を支払います ### ガス支払いに対応しているトークンを確認する方法は？ ペイマスターAPIのコア機能を使用して、ペイマスターでのガス支払いに使用できるERC-20トークンを確認できます。これはType 1およびType 2の支払い戦略にとって特に重要です。 ## 開発環境 ### テスト用に利用できるネットワークは？ NERO Chainは開発とテスト用のテストネット環境を提供しています： - **テストネットRPC**：https://rpc-testnet.nerochain.io - **テストネットバンドラー**：https://bundler-testnet.nerochain.io/ - **テストネットペイマスター**：https://paymaster-testnet.nerochain.io メインネットにデプロイする前に、必ずテストネットで実装を徹底的にテストしてください。 ### テストネットトークンの入手方法は？ NERO Chainのフォーセット[app.testnet.nerochain.io/faucet](https://app.testnet.nerochain.io/faucet/)からテストネットNEROトークンを入手できます。 ## セキュリティのベストプラクティス ### どのようなセキュリティ対策を実装すべきですか？ - **秘密鍵をクライアント側のコードに保存しない**：安全な鍵管理を使用してください - **APIキーには環境変数を使用する**：アプリケーションにAPIキーをハードコーディングしないでください - **ガス制限を実装する**：過剰なコストを防ぐために適切なガス制限を設定してください - **ユーザー入力を検証する**：トランザクションで使用される入力は常に検証してください - **適切なエラー処理を実装する**：操作が失敗した場合にユーザーに明確なフィードバックを提供してください ### ペイマスターAPIキーを保護する方法は？ ペイマスターAPIキーは機密認証情報として扱う必要があります： - コードではなく環境変数に保存する - 乱用を検出するためにレート制限とモニタリングを実装する - セキュリティを強化するためにAPIキーを定期的にローテーションする ## スマートコントラクトのデプロイ ### コントラクトのデプロイが失敗する理由は？ デプロイメントが失敗する一般的な理由： - **ネットワーク設定の誤り**：HardhatやRemixの設定が正しいNERO Chain RPCを指していることを確認してください - **ガス不足**：デプロイメントのガス制限を増やしてみてください - **コントラクトサイズの制限**：非常に大きなコントラクトはサイズ制限を超える可能性があります - **コンパイルエラー**：SolidityコンパイラバージョンがNERO Chainと互換性があることを確認してください ### どのSolidityバージョンを使用すべきですか？ NERO ChainはEthereumのLondonフォークと互換性のあるすべてのSolidityバージョンをサポートしています。最適な互換性とセキュリティのために、Solidity ^0.8.12の使用をお勧めします。 **重要**：Neroscanでのコントラクト検証については、Solidityバージョン0.8.29以下を使用することを確認してください。EVMバージョンの依存関係を含む様々な要因により、Neroscanは新しいSolidityバージョンをタイムリーにサポートできない場合があります。 ### OpenZeppelinプロキシコントラクトの検証が失敗する理由は？ OpenZeppelinプロキシコントラクトはNeroscanで特定の検証の課題に直面する可能性があります： **一般的な問題**：実装コントラクトは正常に検証されるにもかかわらず、TransparentUpgradeableProxyやProxyAdminコントラクトを検証しようとする際に「Invalid compilerVersion」エラーが発生します。 **根本的な原因**：ブロックエクスプローラーの検証インフラストラクチャには、OpenZeppelinプロキシコントラクトのコンパイル設定とバージョン互換性に制限があります。 **解決策**： - **Solidity ≤ 0.8.29を使用**：テストネット/メインネットのブロックエクスプローラーは現在、Solidityバージョン0.8.29までをサポートしています - **OpenZeppelin v5サポート**：エクスプローラーは、Solidity 0.8.29でプリコンパイルされたバイトコードを使用するOpenZeppelin v5プロキシコントラクトをサポートしています - **検証順序**：常に実装コントラクトを最初に検証し、その後プロキシコントラクトの検証を試行してください **重要なポイント**： - 実装コントラクトは通常、問題なく検証されます - プロキシコントラクト（TransparentUpgradeableProxy、ProxyAdmin）にはサポートされているSolidityバージョンが必要です - EVMバージョンの更新やその他の要因により、Neroscanは最新のSolidityバージョンをすぐにサポートできない場合があります プロキシコントラクトの検証で問題が続く場合は、開発環境でコンパイルとデプロイメントの両方にSolidity 0.8.29以前のバージョンを使用していることを確認してください。 ## ウォレット統合 ### なぜAAウォレットアドレスを生成できないのですか？ AAウォレット生成に関する潜在的な問題： - **ファクトリーアドレスの誤り**：正しいアカウントファクトリーアドレスを使用していることを確認してください - **ソルト衝突**：アドレス派生に異なるソルト値を試してみてください - **チェーンIDの不一致**：NERO Chainの正しいチェーンIDを使用していることを確認してください - **初期化データの問題**：初期化コールデータが正しくフォーマットされていることを確認してください ### ウォレットの復旧をどう処理すればよいですか？ AAウォレットには、以下のような復旧メカニズムを実装してください： - 信頼できる連絡先を通じたソーシャルリカバリー - 特定のアクションに対するマルチシグ要件 - セキュリティ上重要な操作のためのタイムロック - 遅延後に有効化できるバックアップ署名者 ## トラブルシューティング ### 行き詰まった場合はどこで助けを得られますか？ 持続的な問題が発生した場合は、以下を通じてNERO Chainサポートに連絡してください： - [Discordコミュニティ](https://discord.gg/nerochainofficial) - [サポートメール](mailto:support@nerochain.io) - [GitHub Issues](https://github.com/nerochain) ### UserOperationが処理されたかどうかを確認する方法は？ 以下を使用してUserOperationのステータスを確認できます： - UserOpSDKの`client.getUserOperationReceipt(hash)`メソッド - [neroscan.io](https://neroscan.io)のNERO Chain Explorer - `eth_getUserOperationReceipt`メソッドを使用したバンドラーRPCエンドポイント --- # NEROチェーン：開発者向けの「What, Why, and How」 Source: https://docs.nerochain.io/ja/getting-started/introduction Section: はじめに ## NEROチェーンとは？ 根本的なスケーラビリティ、柔軟性、およびユーザー体験の向上を念頭に置いたNEROチェーンは、開発者向けに設計されたモジュラー型のLayer 1ブロックチェーンです。NEROチェーンは、ネイティブなアカウント抽象化（AA）とPaymaster（容易に設定可能なAPIプラットフォーム付き）によって他とは一線を画し、開発者がユーザーに新しく円滑な体験を提供しながら、アプリケーションの価値の大部分を自身に還元できるようにします。開発者がNEROチェーンに魅力を感じる主な特長は以下の通りです。 - **ネイティブアカウント抽象化**：ERC-4337をネイティブでサポートし、コンセンサス層の変更が不要。 - **Paymasterシステム**：ユーザーがERC20トークンで支払ったり、ガス費用を完全にスポンサーすることを可能にします。Paymasterプラットフォームを使用してこれらを即座に設定可能です。 - **Blockspace 2.0**：効率的な手数料共有システムを活用した高度なトランザクション処理と料金分配により、ネットワークリソースの効果的な利用を保証します。 - **完全なEVM互換性**：Solidity、Hardhat、Remixなどの人気の開発環境を使用して、スマートコントラクトを作成・利用できます。 ## なぜNEROチェーンで開発するのか？ NEROチェーンはブロックチェーン技術に新しい視点をもたらし、インフラレベルの価値抽出よりもアプリケーション自体を重視しています。 ### 真の価値を獲得するアプリケーション チェーンのネイティブ通貨であるGasは、各アプリケーションがトランザクションの価値をチェーンに譲り渡す必要なく、自身のエコシステム内で価値を直接保持・活用できるように設計されています。 ERC20トークンを使ったガス支払いを可能にすることで、開発者は持続可能な需要と手数料収入を創出し、トークン価値を高めることができます。これは特別な結果をもたらします。あなたのプロジェクトが活動を促進するほど、その恩恵はユーザーやエコシステムに直接還元されるのです。 ![Simulation of developer token performance](https://docs.nerochain.io/assets/simul.png) *図1：他チェーンと比較した開発者トークンのパフォーマンスのシミュレーション。* ### シームレスなユーザー体験 ユーザーインタラクションの複雑さは、ブロックチェーン採用の大きな障害でした。NEROチェーンでは、この課題に直接取り組んでいます。 - **Paymasterシステム**：ユーザーがERC20トークンでガス代を支払ったり、dApp側が完全にガス代をスポンサーすることも可能です。Paymasterプラットフォームで柔軟に設定可能です。 - **アカウント抽象化**：EOAよりも高度なソーシャルログインやセキュリティ、リカバリーオプションを利用可能にします。 - **バンドル化されたトランザクション**：1回のトランザクションで複数のアクションを実行できます。 これにより、ブロックチェーン未経験のユーザーでも簡単に参加でき、Web3の普及を妨げていた障壁を取り除きます。 ## NERO Chainで開発する方法 NEROチェーンでの開発は簡単に開始できます。 1. **テストネットの利用**：NEROチェーンのTestnetで開発とテストを行い、本番環境へのデプロイはメインネットで。 2. **アカウント抽象化の統合**：UserOpSDKを使ってAA機能を実装し、Paymaster APIと接続します。 3. **Paymasterを活用する**：柔軟な支払い方法を有効にし、優れたユーザー体験を提供します。 これらの特徴を活用することで、シームレスなユーザーエクスペリエンスを提供するアプリケーションを構築可能になります。 --- # 開発者向けの主な特徴 Source: https://docs.nerochain.io/ja/getting-started/key-features Section: はじめに このセクションでは、開発者にとって理想的なプラットフォームであるNEROチェーンの主な機能について、高レベルで概要を説明します。これらの特性を理解することで、NEROチェーンを活用したアプリ開発を最大限に行えます。 ## ネイティブアカウント抽象化 ネイティブのERC-4337アカウント抽象化実装を利用することで、NEROチェーンは開発者が高度なツールを使い、より良いユーザー体験を構築できるようサポートします。 #### スマートコントラクトウォレット 従来の外部所有アカウント（EOA）とは異なり、NEROチェーン上のスマートコントラクトウォレットは以下の特長を提供します。 - **プログラム可能な認証**：任意の検証ロジックをトランザクション承認に適用できます。 - **マルチシグサポート**：トランザクション承認に複数の署名者を要求可能です。 - **ソーシャルリカバリー**：信頼できる友人やサービスを通じてアカウントの復元が可能。 - **セッションキー**：特定のアプリケーションや期間限定で使える一時的なキーを発行可能です。 #### UserOperationとBundlers アカウント抽象化の中心にあるのが、`UserOperation`オブジェクトです。 - **柔軟なトランザクション形式**：ユーザーの意図とトランザクション実行を完全に分離します。 - **Bundlers**：複数のUserOperationをまとめて単一のトランザクションにパッケージ化する専用ノード。 - **メンプール管理**：UserOperation専用のメンプールにより、予測可能性を高めます。 ## Paymasterシステム Paymasterは、柔軟なガス支払いメカニズムを可能にする中心的な要素です。また、AAプラットフォームを通じて、開発者は設定を簡単に行えます。 #### 支払いオプション - **スポンサードトランザクション（無料）**：開発者がユーザーのガス代を完全にカバーできます。 - **ERC20トークンでの支払い**：ユーザーはNEROではなく、サポートされたERC20トークンを使ってガス料金を支払うことができます。 - **プリファンド／ポストファンドモデル**：トランザクションの前払いまたは実行後精算のどちらかを選択可能です。 ![Configuring a Gas Policy](https://docs.nerochain.io/assets/aaPlatform/gifs/erc20config.gif) *図1：AAプラットフォームでのガス料金用トークンの設定* #### 統合のメリット - **トークンの有用性向上**：トークンをガス支払いに使用可能にすることでトークンの実用性を向上。 - **ユーザー体験の向上**：ユーザーがNEROトークンを持たなくてもdAppとやり取りできるようにします。 - **柔軟な価格設定モデル**：サブスクリプションモデル、無料トライアル、アクション毎の料金設定などが可能。 ## Blockspace 2.0 従来のブロックチェーンシステムではすべてのトランザクションを一律に処理していましたが、Blockspace 2.0は取引コストやリソース管理に革新的なアプローチを導入し、柔軟性・効率性・公平性を実現しています。 #### スマートな料金体系による独自UX - **カスタム価格モデル**：開発者は特定のニーズに合った独自の価格モデルを作成可能。 - **料金シェアリング**：あなたのdAppがトランザクションを生成すると、ユーザーと開発者の双方がネットワーク手数料をシェアできます。 - **安定した価格設定**：従来の変動の激しいガス価格に比べ、より予測可能な料金体系を提供します。 #### リソースの有効活用 - バンドル化されたトランザクション - トランザクションを効率的にまとめ、不必要なコストを削減します。 - 高速レーンのように、緊急のトランザクションを優先的に処理します。 - 効率的なリソース配分により、開発者は必要な処理能力をより正確に見積もれるため、予期せぬ負担を軽減できます。 Blockspace 2.0により、NEROチェーンは単にコスト削減を目指すのではなく、よりスマートで持続可能なプラットフォームを実現します。 ![Blockspace 2.0 concept diagram](https://docs.nerochain.io/assets/block2.png) *図2：Blockspace 2.0のアーキテクチャ* --- # dAppのアーキテクチャ Source: https://docs.nerochain.io/ja/getting-started/nero-dapp-architecture Section: はじめに NEROチェーンのアーキテクチャを理解することで、その独自機能を活用し、革新的なアプリケーションと新しいユーザー体験を構築する方法が見えてきます。この概要では、アカウント抽象化、Paymaster機能、その他主要な機能を可能にする各コンポーネントがどのように連携しているかを説明します。 分散型アプリケーション（dApp）内で複数のコンポーネントが一体となり、堅牢で安全かつ効率的なブロックチェーン運用を実現しています。各コンポーネントを詳しく見ていきましょう。 ![NERO Chain dApp Architecture](https://docs.nerochain.io/assets/aaPlatform/figure1.png) *図1：NEROチェーンのdAppアーキテクチャ* ## 主要コンポーネントとトランザクションの流れ ### ユーザーおよび認証レイヤー NEROチェーンのユーザー体験の基礎となるのは、初心者からWeb3ユーザーまで対応した柔軟な認証メカニズムです。 **AAウォレット**（スマートコントラクトウォレット）は、多様な認証方法を同時にサポートする柔軟なウォレットで、ユーザーがブロックチェーン機能と対話する際の中心となります。従来のウォレットが秘密鍵のみに依存するのに対し、NEROチェーンのAAウォレットは、MetaMaskのような馴染みある第三者ウォレット、GoogleやTwitterログインなどの実用的なWeb2認証、さらには従来のパスワードベースの認証でもアクセス可能です。専門的なユーザーにセキュリティと柔軟性を提供しつつ、一般ユーザーに対しても参入障壁を大きく取り除くことが可能になります。 ![Aa-platform policies](https://docs.nerochain.io/assets/aaWallet/login-3.png) *図2：ソーシャルログインの例* ユーザーはスマートフォンでソーシャルログインを使用してAAウォレットを設定し、同じオンチェーンのアイデンティティや資産をPCのMetaMaskなどでも利用可能です。 ### アプリケーションコンポーネント アプリケーションレイヤーは、ユーザーとブロックチェーン間を繋ぐ役割を果たし、複数の統合されたコンポーネントを特徴としています。 **ウォレットSDK** は、他のWeb3アプリケーションでも使用可能であり、トランザクション構築や提出の難しい作業を処理し、AAウォレットと分散型アプリケーションの間を繋ぎます。このSDKを使用してNEROチェーンにデプロイされたAAウォレットファクトリーからウォレットを取得します。 NEROチェーン上に構築された分散型アプリケーションは、このアーキテクチャを利用してシームレスなフロントエンドのインタラクションを提供できます。DEX、NFTマーケットプレイス、ゲーミングプラットフォームなど、どのようなアプリを開発する場合でも、ウォレットSDKを通じてユーザーに快適な体験を提供できます。 **Developer SDK（UserOpSDK）** は開発者がアカウント抽象化機能をアプリケーションに統合するために必要なツールを提供します。UserOperationの構築、EntryPointコントラクトとの連携、Paymasterの利用方法をカバーしています。 **Paymaster API** を活用することで、dAppはガス代のスポンサーや代替支払い手段を利用できます。ユーザーがトランザクションを開始すると、Paymaster APIに問い合わせを行い、適切な支払い方法を探してUserOperationに必要な情報を組み込めます。 ### バックエンドインフラ ユーザー向けコンポーネントの背後には、NEROチェーンの独自機能を支える堅牢なインフラがあります。 - **AAプラットフォーム** はPaymaster設定を行い、トークンによるガス支払いの許可、使用量のモニタリングなどを行うダッシュボードです。 - **価格サービス** はERC20トークンとガス料金間の為替レートを算定し、公正な料金計算を支援します。 - **Bundlers** は複数ユーザーのUserOperationを収集し、標準的なトランザクションにバッチ処理して効率化します。 - **Paymasterコントラクト** は実際のガス料金抽象化を担い、スポンサーシップの判断やトークンベースの支払い処理を行います。 - **EntryPointコントラクト**（アドレス: `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789`）はすべてのUserOperationの中心的なハブとして機能し、Bundlerから送信された操作を処理します。 - 各ユーザーの **Contract Account** はスマートコントラクトウォレットであり、アカウントファクトリー経由でデプロイされ、マルチシグ、支出制限、アカウントリカバリー機能などを追加可能です。 - 高度な用途として、オプショナルな **Aggregator** は署名の集約を処理し、マルチシグ操作を効率化します。 次のセクションでは、トランザクションの詳細な流れを説明します。 ## トランザクションフロー ### 接続フェーズ ユーザーがdAppに接続することでプロセスが始まります。この初期接続では、ユーザーのブラウザとブロックチェーン間の通信チャネルが確立されます。この段階で、ユーザーは好みの方法（MetaMask、ソーシャルログイン、パスワードなど）で認証を行い、dAppはユーザーのAAウォレットアドレスを特定します。ウォレットがまだデプロイされていない場合はカウンターファクチュアル（未実体化）アドレスが使用されます。 ### UserOperation構築フェーズ 接続後、トランザクションの準備プロセスが始まります。ユーザーがトークン交換やNFTミントなどの操作を開始すると、dAppは直接またはDeveloper SDKを通じてUserOperationを構築します。従来のトランザクションとは異なり、UserOperationにはアカウント抽象化に必要な追加フィールドが含まれます。 ガス抽象化が必要な場合、Developer SDKはPaymaster APIと通信し、支払い方法を決定します。トークンベースの支払いの場合、価格サービスは現在の為替レートと推定ガス消費量に基づいて必要なトークン量を計算します。Paymaster APIはその後、ガス処理に必要なすべての情報を含むpaymasterAndDataフィールドを返します。 このモジュラーなアプローチにより、開発者はアプリケーションの主要ロジックを変更せずに柔軟な支払いオプションを提供できます。ユーザーはネイティブトークンを特別に取得せずとも、すでに持っているトークンで支払いが可能です。 ### トランザクション提出フェーズ UserOperationが構築され署名されると、提出プロセスが始まります。dAppは完成したUserOperationをウォレットSDKに送信し、ウォレットSDKはユーザーとの対話を通じて署名を取得します。この署名プロセスは、MetaMaskのポップアップまたはアプリ内の署名要求など、認証方法に応じて異なります。 署名完了後、AAウォレットはUserOperationをBundlersに送信します。Bundlersは複数ユーザーの操作を収集し、ガスの使用を最適化して効率を高めます。操作をバッチ処理することで、Bundlersは1操作あたりのコストを大幅に削減できます。 ### 実行フェーズ Bundlerが十分な操作を収集するか、一定の時間閾値に達すると、最終段階が行われます。BundlerはUserOperationsをまとめてEntryPointコントラクトを呼び出すトランザクションを作成し、EntryPointは各操作を順次処理します。 各操作に対して、EntryPointは署名を検証し、ガス要件が満たされていることを確認します（ユーザーのウォレット残高またはPaymaster経由）。その後、ユーザーのContract Accountを呼び出し、実際のトランザクションロジックを実行します。Paymasterが関与している場合、設定された戦略に基づいてガスの支払いを処理します。 このマルチステッププロセスはユーザーには透明で、最終的には通常のトランザクションと同様に処理・確認されますが、より柔軟でコスト効率の高い方法となります。 ### 管理コンポーネント 開発者はAAプラットフォームを通じてガススポンサーシップのポリシーを管理できます。ここでは支払い戦略の設定、日次またはユーザーごとのクォータ設定、使用パターンの監視が可能です。この管理レイヤーにより、経済的に持続可能で優れたユーザー体験を提供できます。 ![Aa-platform policies](https://docs.nerochain.io/assets/aaPlatform/aa-platform-policies.png) *図3：AAプラットフォームのポリシー設定ダッシュボード* また、NEROオペレーターはプラットフォームレベルの設定にアクセスでき、全体的なシステムの健全性管理や公平なリソース配分を確保できます。 ## Paymasterの支払いタイプとユーザー体験 Paymasterシステムは、NEROチェーンの最も革新的な機能の1つであり、柔軟なガス支払いメカニズムを実現し、ユーザー体験を大幅に向上させます。ここでは、異なる支払いタイプとその影響について説明します。 ### タイプ0：開発者スポンサー型ガス（無料） タイプ0の支払いでは、開発者がユーザーのガス代を完全にカバーします。これにより、ユーザーはWeb2アプリケーションと同じように、トランザクション手数料を気にする必要がなくなり、シームレスな体験を得ることができます。 このモデルは、特に新規ユーザーのオンボーディングに適しています。通常、新しいユーザーが特定のトークンを取得する必要があると、参入障壁が高くなります。しかし、最初のインタラクション時にガス代を開発者が負担することで、スムーズにアプリケーションを利用できるようになります。 また、プロモーションキャンペーンにも適しており、一時的にトランザクションコストをゼロにすることでユーザーの関心を集めることができます。特に、ゲームやメタバースアプリケーションでは、ブロックチェーンの複雑さを隠し、ユーザーがガス管理ではなくゲームプレイに集中できる環境を作るのに役立ちます。 タイプ0の支払いを実装するには、開発者はAAプラットフォームアカウントに一定の残高を維持し、日次またはユーザーごとの制限を設定してコストを管理します。プラットフォームは、ユーザーの行動やコンバージョン指標を基にスポンサー戦略を最適化するための分析機能を提供します。 ### タイプ1：ERC20トークン前払い タイプ1の支払いモデルでは、ユーザーがNEROトークンを保有する必要なく、すでに所有しているERC20トークンを使用してガス料金を支払うことができます。これにより、特に独自のトークンエコシステムを持つアプリケーションにおいて、採用障壁が大幅に低下します。 このモデルでは、トランザクションの実行前に推定されるガス代（選択されたトークンでの換算額）をユーザーから徴収します。トランザクション完了後、余剰分が自動的にユーザーに返金されます。 この方法は、ユーザーと開発者の双方にとってメリットがあります。ユーザーは最大の支払額を事前に把握でき、開発者は実行前に支払いが確定しているため、リスクを最小限に抑えることができます。特に、ガス代が全体のトランザクション価値のごく一部である高額取引に適しています。 このモデルの実装には、ユーザーがPaymasterコントラクトにトークン使用許可を与える必要があります。これは通常、ウォレットSDKを通じて適切なUIガイド付きで処理されます。 ### タイプ2：ERC20トークン後払い タイプ2の支払いモデルでもERC20トークンが使用されますが、ガス料金の徴収はトランザクション実行後に行われます。これにより、ユーザーは実際に消費したガス量のみを支払うことができ、事前に推定額を用意する必要がなくなります。 特に、コントラクトの実行パスによってガスコストが大きく変動する可能性があるトランザクションにおいて、このアプローチは非常に便利です。しかし、このモデルでは、トランザクション完了後にユーザーのトークン残高や許可が不足していると、支払いが失敗するリスクが発生します。 このモデルは、ユーザーが他の目的で一定量のトークンを保有しているアプリケーションと統合することで、支払い失敗リスクを最小限に抑えることができます。 ## 高度なアプリケーションの構築 NEROチェーンのアーキテクチャを活用することで、これまでにないアプリケーションを開発できます。以下は、その一例です。 **トークン中心のエコシステム**: ユーザーがアプリケーションのトークンでガスを支払えるようにすることで、トークンエコノミー内で完結するシステムを構築できます。これにより、トークンの実用性と需要が向上し、ユーザー体験もシンプルになります。 **摩擦のないオンボーディング**: 最初は開発者がガスをスポンサーし、ユーザーがアプリに慣れた後にトークンでの支払いに移行することで、Web3特有の「暗号資産の取得」という障壁を取り除くことができます。 **バンドルトランザクション**: ユーザーが1回の操作で複数のアクションを実行できるようにすることで（例：トークンスワップと承認、NFTの一括ミント）、コスト削減とUXの向上を実現します。 **高度なセキュリティ機能**: マルチシグ承認、支出制限、タイムロックなどの機能を簡単に実装できます。スマートコントラクトウォレットを活用することで、従来のEOAよりも強固なセキュリティを提供できます。 **ソーシャルリカバリーシステム**: 信頼できる友人やサービスプロバイダーを通じたアカウント回復メカニズムを実装できます。これにより、秘密鍵の紛失による資産喪失のリスクを軽減できます。 **サブスクリプションモデル**: 従来のサブスクリプション型アプリと同様に、定期的な支払いを自動処理できます。Paymasterは、これらの事前承認されたトランザクションのガス代を処理できます。 NEROチェーンの機能を十分に理解し活用することで、ブロックチェーンのセキュリティと所有権のメリットを活かしつつ、従来のUXの課題を克服したアプリケーションを開発できます。 次のセクションでは、これらのコンポーネントをアプリケーションに実装する具体的な方法を解説します。 --- # NERO Chainドキュメントへようこそ Source: https://docs.nerochain.io/ja Section: 概要 NERO Chainテクノロジー、エコシステム、開発に関する決定的なリファレンスへようこそ。アプリケーションを構築する開発者、ノードを運用するオペレーター、アーキテクチャを探求する研究者、またはブロックチェーンを始めたばかりの方でも、このドキュメントはNERO Chainの独自機能を理解し活用するのに役立ちます。 ## ビルダージャーニー dAppデベロッパー

NERO Chainのユニークな機能でdAppを構築する。

構築を始める → ノードオペレーター

NERO ネットワークデプロイし、維持する。

インフラ運用 → 研究者・開発者

技術アーキテクチャとプロトコルの詳細を探る。

技術を学ぶ → ## クイックスタートガイド 開発者ツール

NERO Chainの独自機能を理解します。

 開発者クックブック

NERO Chainでの構築に役立つ実践的なレシピ。

 FAQ

よくある課題とその解決策。

 ## 人気の開発ガイド 初回スマコンデプロイ

NERO Chainにスマートコントラクトをデプロイします。

 初めてのdAppを構築

NFTミンティングdAppを作成します。

 ペイマスターを統合

ガススポンサーシップとトークン支払いを有効にします。

 ## アカウント抽象化技術 UserOp SDK

JavaScript SDKを使用してUserOperationを作成・送信します。

 AAウォレット統合

アプリケーションにスマートコントラクトウォレットを実装します。

 AAプラットフォーム

ガススポンサーシップポリシーと支払い戦略を管理します。

 ## 必須ツール NEROフォーセット

開発のためのテストネットNEROトークンを入手します。

 NEROエクスプローラー

トランザクションとブロックを検索・表示します。

 ペイマスターアクセス

ガススポンサーシップと支払いポリシーを管理します。

 ## 技術リソース ネットワーク情報

NERO ChainのRPCエンドポイントとチェーンIDを参照します。

 GitHubリポジトリ

オープンソースのコードとSDKにアクセスします。

 サポート

開発者サポートとコミュニティリソースを利用します。

 ## NERO Chainについて モジュラーブロックチェーンとして構築されたNERO Chainは、インフラレベルの価値キャプチャよりもアプリケーションに価値を提供することを重視しています。NERO Chainは、dAppがトランザクション価値を収集・共有できるようにすることで、従来のブロックチェーン経済を変革し、アプリケーションの成功が基盤ネットワークだけでなく、その開発者とユーザーにも利益をもたらすことを保証します。完全なEVM互換性と高性能な決済レイヤーを備えたNEROは、ネイティブアカウント抽象化、ペイマスター駆動のガススポンサーシップ、そして開発者にシームレスな体験を提供するBlockspace 2.0などの最新技術を含む、驚異的なスケーラビリティと柔軟性を提供します。 --- # コマンドラインオプション Source: https://docs.nerochain.io/ja/node-validators/commandLineOptions Section: ノードバリデータ Gethは主にコマンドラインを使用して制御されます。Gethはgethコマンドを使用して開始します。Ctrl+Cキーを押すと停止します。 コマンドラインオプション（別名フラグ）を使用してGethを設定できます。Gethにはサブコマンドもあり、コンソールやブロックチェーンのインポート/エクスポートなどの機能を呼び出すために使用できます。 便宜のために、コマンドラインヘルプの一覧を以下に再現しています。同じ情報は、いつでも以下を実行することでGethインスタンスから取得できます： ``` geth --help ``` ## コマンド ```shell showLineNumbers{1} NAME: geth - the go-ethereum command line interface USAGE: geth [global options] command [command options] [arguments...] VERSION: 1.13.1-stable-3f40e65c COMMANDS: account Manage accounts attach Start an interactive JavaScript environment (connect to node) console Start an interactive JavaScript environment db Low level database operations dump Dump a specific block from storage dumpconfig Export configuration values in a TOML format dumpgenesis Dumps genesis block JSON configuration to stdout export Export blockchain into file export-preimages Export the preimage database into an RLP stream import-preimages Import the preimage database from an RLP stream init Bootstrap and initialize a new genesis block js (DEPRECATED) Execute the specified JavaScript files license Display license information removedb Remove blockchain and state databases show-deprecated-flags Show flags that have been deprecated snapshot A set of commands based on the snapshot verkle A set of experimental verkle tree management commands version Print version numbers version-check Checks (online) for known Geth security vulnerabilities wallet Manage Ethereum presale wallets help, h Shows a list of commands or help for one command GLOBAL OPTIONS: --log.rotate (default: false) ($GETH_LOG_ROTATE) Enables log file rotation ACCOUNT --allow-insecure-unlock (default: false) ($GETH_ALLOW_INSECURE_UNLOCK) Allow insecure account unlocking when account-related RPCs are exposed by http --keystore value ($GETH_KEYSTORE) Directory for the keystore (default = inside the datadir) --lightkdf (default: false) ($GETH_LIGHTKDF) Reduce key-derivation RAM & CPU usage at some expense of KDF strength --password value ($GETH_PASSWORD) Password file to use for non-interactive password input --pcscdpath value (default: "/run/pcscd/pcscd.comm") ($GETH_PCSCDPATH) Path to the smartcard daemon (pcscd) socket file --signer value ($GETH_SIGNER) External signer (url or path to ipc file) --unlock value ($GETH_UNLOCK) Comma separated list of accounts to unlock --usb (default: false) ($GETH_USB) Enable monitoring and management of USB hardware wallets ALIASED (deprecated) --cache.trie.journal value ($GETH_CACHE_TRIE_JOURNAL) Disk journal directory for trie cache to survive node restarts --cache.trie.rejournal value (default: 0s) ($GETH_CACHE_TRIE_REJOURNAL) Time interval to regenerate the trie cache journal --nousb (default: false) ($GETH_NOUSB) Disables monitoring for and managing USB hardware wallets (deprecated) --txlookuplimit value (default: 2350000) ($GETH_TXLOOKUPLIMIT) Number of recent blocks to maintain transactions index for (default = about one year, 0 = entire chain) (deprecated, use history.transactions instead) --v5disc (default: false) ($GETH_V5DISC) Enables the experimental RLPx V5 (Topic Discovery) mechanism (deprecated, use --discv5 instead) --whitelist value ($GETH_WHITELIST) Comma separated block number-to-hash mappings to enforce (=) (deprecated in favor of --eth.requiredblocks) API AND CONSOLE --authrpc.addr value (default: "localhost") ($GETH_AUTHRPC_ADDR) Listening address for authenticated APIs --authrpc.jwtsecret value ($GETH_AUTHRPC_JWTSECRET) Path to a JWT secret to use for authenticated RPC endpoints --authrpc.port value (default: 8551) ($GETH_AUTHRPC_PORT) Listening port for authenticated APIs --authrpc.vhosts value (default: "localhost") ($GETH_AUTHRPC_VHOSTS) Comma separated list of virtual hostnames from which to accept requests (server enforced). Accepts '*' wildcard. --exec value ($GETH_EXEC) Execute JavaScript statement --graphql (default: false) ($GETH_GRAPHQL) Enable GraphQL on the HTTP-RPC server. Note that GraphQL can only be started if an HTTP server is started as well. --graphql.corsdomain value ($GETH_GRAPHQL_CORSDOMAIN) Comma separated list of domains from which to accept cross origin requests (browser enforced) --graphql.vhosts value (default: "localhost") ($GETH_GRAPHQL_VHOSTS) Comma separated list of virtual hostnames from which to accept requests (server enforced). Accepts '*' wildcard. --header value, -H value Pass custom headers to the RPC server when using --remotedb or the geth attach console. This flag can be given multiple times. --http (default: false) ($GETH_HTTP) Enable the HTTP-RPC server --http.addr value (default: "localhost") ($GETH_HTTP_ADDR) HTTP-RPC server listening interface --http.api value ($GETH_HTTP_API) API's offered over the HTTP-RPC interface --http.corsdomain value ($GETH_HTTP_CORSDOMAIN) Comma separated list of domains from which to accept cross origin requests (browser enforced) --http.port value (default: 8545) ($GETH_HTTP_PORT) HTTP-RPC server listening port --http.rpcprefix value ($GETH_HTTP_RPCPREFIX) HTTP path path prefix on which JSON-RPC is served. Use '/' to serve on all paths. --http.vhosts value (default: "localhost") ($GETH_HTTP_VHOSTS) Comma separated list of virtual hostnames from which to accept requests (server enforced). Accepts '*' wildcard. --ipcdisable (default: false) ($GETH_IPCDISABLE) Disable the IPC-RPC server --ipcpath value ($GETH_IPCPATH) Filename for IPC socket/pipe within the datadir (explicit paths escape it) --jspath value (default: .) ($GETH_JSPATH) JavaScript root path for `loadScript` --preload value ($GETH_PRELOAD) Comma separated list of JavaScript files to preload into the console --rpc.allow-unprotected-txs (default: false) ($GETH_RPC_ALLOW_UNPROTECTED_TXS) Allow for unprotected (non EIP155 signed) transactions to be submitted via RPC --rpc.batch-request-limit value (default: 1000) ($GETH_RPC_BATCH_REQUEST_LIMIT) Maximum number of requests in a batch --rpc.batch-response-max-size value (default: 25000000) ($GETH_RPC_BATCH_RESPONSE_MAX_SIZE) Maximum number of bytes returned from a batched call --rpc.enabledeprecatedpersonal (default: false) ($GETH_RPC_ENABLEDEPRECATEDPERSONAL) Enables the (deprecated) personal namespace --rpc.evmtimeout value (default: 5s) ($GETH_RPC_EVMTIMEOUT) Sets a timeout used for eth_call (0=infinite) --rpc.gascap value (default: 50000000) ($GETH_RPC_GASCAP) Sets a cap on gas that can be used in eth_call/estimateGas (0=infinite) --rpc.txfeecap value (default: 1) Sets a cap on transaction fee (in ether) that can be sent via the RPC APIs (0 = no cap) --ws (default: false) ($GETH_WS) Enable the WS-RPC server --ws.addr value (default: "localhost") ($GETH_WS_ADDR) WS-RPC server listening interface --ws.api value ($GETH_WS_API) API's offered over the WS-RPC interface --ws.origins value ($GETH_WS_ORIGINS) Origins from which to accept websockets requests --ws.port value (default: 8546) ($GETH_WS_PORT) WS-RPC server listening port --ws.rpcprefix value ($GETH_WS_RPCPREFIX) HTTP path prefix on which JSON-RPC is served. Use '/' to serve on all paths. DEVELOPER CHAIN --dev (default: false) ($GETH_DEV) Ephemeral proof-of-authority network with a pre-funded developer account, mining enabled --dev.gaslimit value (default: 11500000) ($GETH_DEV_GASLIMIT) Initial block gas limit --dev.period value (default: 0) ($GETH_DEV_PERIOD) Block period to use in developer mode (0 = mine only if transaction pending) ETHEREUM --bloomfilter.size value (default: 2048) ($GETH_BLOOMFILTER_SIZE) Megabytes of memory allocated to bloom-filter for pruning --config value ($GETH_CONFIG) TOML configuration file --datadir value (default: /root/.ethereum) ($GETH_DATADIR) Data directory for the databases and keystore --datadir.ancient value ($GETH_DATADIR_ANCIENT) Root directory for ancient data (default = inside chaindata) --datadir.minfreedisk value ($GETH_DATADIR_MINFREEDISK) Minimum free disk space in MB, once reached triggers auto shut down (default = --cache.gc converted to MB, 0 = disabled) --db.engine value ($GETH_DB_ENGINE) Backing database implementation to use ('pebble' or 'leveldb') --eth.requiredblocks value ($GETH_ETH_REQUIREDBLOCKS) Comma separated block number-to-hash mappings to require for peering (=) --exitwhensynced (default: false) ($GETH_EXITWHENSYNCED) Exits after block synchronisation completes --goerli (default: false) ($GETH_GOERLI) Görli network: pre-configured proof-of-authority test network --holesky (default: false) ($GETH_HOLESKY) Holesky network: pre-configured proof-of-stake test network --mainnet (default: false) ($GETH_MAINNET) Ethereum mainnet --networkid value (default: 1) ($GETH_NETWORKID) Explicitly set network id (integer)(For testnets: use --goerli, --sepolia, --holesky instead) --override.cancun value (default: 0) ($GETH_OVERRIDE_CANCUN) Manually specify the Cancun fork timestamp, overriding the bundled setting --override.verkle value (default: 0) ($GETH_OVERRIDE_VERKLE) Manually specify the Verkle fork timestamp, overriding the bundled setting --sepolia (default: false) ($GETH_SEPOLIA) Sepolia network: pre-configured proof-of-work test network --snapshot (default: true) ($GETH_SNAPSHOT) Enables snapshot-database mode (default = enable) GAS PRICE ORACLE --gpo.blocks value (default: 20) ($GETH_GPO_BLOCKS) Number of recent blocks to check for gas prices --gpo.ignoreprice value (default: 2) Gas price below which gpo will ignore transactions --gpo.maxprice value (default: 500000000000) Maximum transaction priority fee (or gasprice before London fork) to be recommended by gpo --gpo.percentile value (default: 60) ($GETH_GPO_PERCENTILE) Suggested gas price is the given percentile of a set of recent transaction gas prices LIGHT CLIENT --light.egress value (default: 0) ($GETH_LIGHT_EGRESS) Outgoing bandwidth limit for serving light clients (kilobytes/sec, 0 = unlimited) --light.ingress value (default: 0) ($GETH_LIGHT_INGRESS) Incoming bandwidth limit for serving light clients (kilobytes/sec, 0 = unlimited) --light.maxpeers value (default: 100) ($GETH_LIGHT_MAXPEERS) Maximum number of light clients to serve, or light servers to attach to --light.nopruning (default: false) ($GETH_LIGHT_NOPRUNING) Disable ancient light chain data pruning --light.nosyncserve (default: false) ($GETH_LIGHT_NOSYNCSERVE) Enables serving light clients before syncing --light.serve value (default: 0) ($GETH_LIGHT_SERVE) Maximum percentage of time allowed for serving LES requests (multi-threaded processing allows values over 100) LOGGING AND DEBUGGING --log.backtrace value ($GETH_LOG_BACKTRACE) Request a stack trace at a specific logging statement (e.g. "block.go:271") --log.compress (default: false) ($GETH_LOG_COMPRESS) Compress the log files --log.debug (default: false) ($GETH_LOG_DEBUG) Prepends log messages with call-site location (file and line number) --log.file value ($GETH_LOG_FILE) Write logs to a file --log.format value ($GETH_LOG_FORMAT) Log format to use (json|logfmt|terminal) --log.maxage value (default: 30) ($GETH_LOG_MAXAGE) Maximum number of days to retain a log file --log.maxbackups value (default: 10) ($GETH_LOG_MAXBACKUPS) Maximum number of log files to retain --log.maxsize value (default: 100) ($GETH_LOG_MAXSIZE) Maximum size in MBs of a single log file --log.vmodule value ($GETH_LOG_VMODULE) Per-module verbosity: comma-separated list of = (e.g. eth/*=5,p2p=4) --nocompaction (default: false) ($GETH_NOCOMPACTION) Disables db compaction after import --pprof (default: false) ($GETH_PPROF) Enable the pprof HTTP server --pprof.addr value (default: "127.0.0.1") ($GETH_PPROF_ADDR) pprof HTTP server listening interface --pprof.blockprofilerate value (default: 0) ($GETH_PPROF_BLOCKPROFILERATE) Turn on block profiling with the given rate --pprof.cpuprofile value ($GETH_PPROF_CPUPROFILE) Write CPU profile to the given file --pprof.memprofilerate value (default: 524288) ($GETH_PPROF_MEMPROFILERATE) Turn on memory profiling with the given rate --pprof.port value (default: 6060) ($GETH_PPROF_PORT) pprof HTTP server listening port --remotedb value ($GETH_REMOTEDB) URL for remote database --trace value ($GETH_TRACE) Write execution trace to the given file --verbosity value (default: 3) ($GETH_VERBOSITY) Logging verbosity: 0=silent, 1=error, 2=warn, 3=info, 4=debug, 5=detail METRICS AND STATS --ethstats value ($GETH_ETHSTATS) Reporting URL of a ethstats service (nodename:secret@host:port) --metrics (default: false) ($GETH_METRICS) Enable metrics collection and reporting --metrics.addr value ($GETH_METRICS_ADDR) Enable stand-alone metrics HTTP server listening interface. --metrics.expensive (default: false) ($GETH_METRICS_EXPENSIVE) Enable expensive metrics collection and reporting --metrics.influxdb (default: false) ($GETH_METRICS_INFLUXDB) Enable metrics export/push to an external InfluxDB database --metrics.influxdb.bucket value (default: "geth") ($GETH_METRICS_INFLUXDB_BUCKET) InfluxDB bucket name to push reported metrics to (v2 only) --metrics.influxdb.database value (default: "geth") ($GETH_METRICS_INFLUXDB_DATABASE) InfluxDB database name to push reported metrics to --metrics.influxdb.endpoint value (default: "http://localhost:8086") ($GETH_METRICS_INFLUXDB_ENDPOINT) InfluxDB API endpoint to report metrics to --metrics.influxdb.organization value (default: "geth") ($GETH_METRICS_INFLUXDB_ORGANIZATION) InfluxDB organization name (v2 only) --metrics.influxdb.password value (default: "test") ($GETH_METRICS_INFLUXDB_PASSWORD) Password to authorize access to the database --metrics.influxdb.tags value (default: "host=localhost") ($GETH_METRICS_INFLUXDB_TAGS) Comma-separated InfluxDB tags (key/values) attached to all measurements --metrics.influxdb.token value (default: "test") ($GETH_METRICS_INFLUXDB_TOKEN) Token to authorize access to the database (v2 only) --metrics.influxdb.username value (default: "test") ($GETH_METRICS_INFLUXDB_USERNAME) Username to authorize access to the database --metrics.influxdbv2 (default: false) ($GETH_METRICS_INFLUXDBV2) Enable metrics export/push to an external InfluxDB v2 database --metrics.port value (default: 6060) ($GETH_METRICS_PORT) Metrics HTTP server listening port. Please note that --metrics.addr must be set to start the server. MINER --mine (default: false) ($GETH_MINE) Enable mining --miner.etherbase value ($GETH_MINER_ETHERBASE) 0x prefixed public address for block mining rewards --miner.extradata value ($GETH_MINER_EXTRADATA) Block extra data set by the miner (default = client version) --miner.gaslimit value (default: 30000000) ($GETH_MINER_GASLIMIT) Target gas ceiling for mined blocks --miner.gasprice value (default: 0) ($GETH_MINER_GASPRICE) Minimum gas price for mining a transaction --miner.newpayload-timeout value (default: 2s) ($GETH_MINER_NEWPAYLOAD_TIMEOUT) Specify the maximum time allowance for creating a new payload --miner.recommit value (default: 2s) ($GETH_MINER_RECOMMIT) Time interval to recreate the block being mined MISC --help, -h (default: false) show help --synctarget value ($GETH_SYNCTARGET) File for containing the hex-encoded block-rlp as sync target(dev feature) --version, -v (default: false) print the version NETWORKING --bootnodes value ($GETH_BOOTNODES) Comma separated enode URLs for P2P discovery bootstrap --discovery.dns value ($GETH_DISCOVERY_DNS) Sets DNS discovery entry points (use "" to disable DNS) --discovery.port value (default: 30303) ($GETH_DISCOVERY_PORT) Use a custom UDP port for P2P discovery --discovery.v4, --discv4 (default: true) ($GETH_DISCOVERY_V4) Enables the V4 discovery mechanism --discovery.v5, --discv5 (default: false) ($GETH_DISCOVERY_V5) Enables the experimental RLPx V5 (Topic Discovery) mechanism --identity value ($GETH_IDENTITY) Custom node name --maxpeers value (default: 50) ($GETH_MAXPEERS) Maximum number of network peers (network disabled if set to 0) --maxpendpeers value (default: 0) ($GETH_MAXPENDPEERS) Maximum number of pending connection attempts (defaults used if set to 0) --nat value (default: "any") ($GETH_NAT) NAT port mapping mechanism (any|none|upnp|pmp|pmp:|extip:) --netrestrict value ($GETH_NETRESTRICT) Restricts network communication to the given IP networks (CIDR masks) --nodekey value ($GETH_NODEKEY) P2P node key file --nodekeyhex value ($GETH_NODEKEYHEX) P2P node key as hex (for testing) --nodiscover (default: false) ($GETH_NODISCOVER) Disables the peer discovery mechanism (manual peer addition) --port value (default: 30303) ($GETH_PORT) Network listening port PERFORMANCE TUNING --cache value (default: 1024) ($GETH_CACHE) Megabytes of memory allocated to internal caching (default = 4096 mainnet full node, 128 light mode) --cache.blocklogs value (default: 32) ($GETH_CACHE_BLOCKLOGS) Size (in number of blocks) of the log cache for filtering --cache.database value (default: 50) ($GETH_CACHE_DATABASE) Percentage of cache memory allowance to use for database io --cache.gc value (default: 25) ($GETH_CACHE_GC) Percentage of cache memory allowance to use for trie pruning (default = 25% full mode, 0% archive mode) --cache.noprefetch (default: false) ($GETH_CACHE_NOPREFETCH) Disable heuristic state prefetch during block import (less CPU and disk IO, more time waiting for data) --cache.preimages (default: false) ($GETH_CACHE_PREIMAGES) Enable recording the SHA3/keccak preimages of trie keys --cache.snapshot value (default: 10) ($GETH_CACHE_SNAPSHOT) Percentage of cache memory allowance to use for snapshot caching (default = 10% full mode, 20% archive mode) --cache.trie value (default: 15) ($GETH_CACHE_TRIE) Percentage of cache memory allowance to use for trie caching (default = 15% full mode, 30% archive mode) --crypto.kzg value (default: "gokzg") ($GETH_CRYPTO_KZG) KZG library implementation to use; gokzg (recommended) or ckzg --fdlimit value (default: 0) ($GETH_FDLIMIT) Raise the open file descriptor resource limit (default = system fd limit) STATE HISTORY MANAGEMENT --gcmode value (default: "full") ($GETH_GCMODE) Blockchain garbage collection mode, only relevant in state.scheme=hash ("full", "archive") --history.state value (default: 90000) ($GETH_HISTORY_STATE) Number of recent blocks to retain state history for (default = 90,000 blocks, 0 = entire chain) --history.transactions value (default: 2350000) ($GETH_HISTORY_TRANSACTIONS) Number of recent blocks to maintain transactions index for (default = about one year, 0 = entire chain) --state.scheme value (default: "hash") ($GETH_STATE_SCHEME) Scheme to use for storing ethereum state ('hash' or 'path') --syncmode value (default: snap) ($GETH_SYNCMODE) Blockchain sync mode ("snap", "full" or "light") TRANSACTION POOL (BLOB) --blobpool.datacap value (default: 10737418240) ($GETH_BLOBPOOL_DATACAP) Disk space to allocate for pending blob transactions (soft limit) --blobpool.datadir value (default: "blobpool") ($GETH_BLOBPOOL_DATADIR) Data directory to store blob transactions in --blobpool.pricebump value (default: 100) ($GETH_BLOBPOOL_PRICEBUMP) Price bump percentage to replace an already existing blob transaction TRANSACTION POOL (EVM) --txpool.accountqueue value (default: 64) ($GETH_TXPOOL_ACCOUNTQUEUE) Maximum number of non-executable transaction slots permitted per account --txpool.accountslots value (default: 16) ($GETH_TXPOOL_ACCOUNTSLOTS) Minimum number of executable transaction slots guaranteed per account --txpool.globalqueue value (default: 1024) ($GETH_TXPOOL_GLOBALQUEUE) Maximum number of non-executable transaction slots for all accounts --txpool.globalslots value (default: 5120) ($GETH_TXPOOL_GLOBALSLOTS) Maximum number of executable transaction slots for all accounts --txpool.journal value (default: "transactions.rlp") ($GETH_TXPOOL_JOURNAL) Disk journal for local transaction to survive node restarts --txpool.lifetime value (default: 3h0m0s) ($GETH_TXPOOL_LIFETIME) Maximum amount of time non-executable transaction are queued --txpool.locals value ($GETH_TXPOOL_LOCALS) Comma separated accounts to treat as locals (no flush, priority inclusion) --txpool.nolocals (default: false) ($GETH_TXPOOL_NOLOCALS) Disables price exemptions for locally submitted transactions --txpool.pricebump value (default: 10) ($GETH_TXPOOL_PRICEBUMP) Price bump percentage to replace an already existing transaction --txpool.pricelimit value (default: 1) ($GETH_TXPOOL_PRICELIMIT) Minimum gas price tip to enforce for acceptance into the pool --txpool.rejournal value (default: 1h0m0s) ($GETH_TXPOOL_REJOURNAL) Time interval to regenerate the local transaction journal VIRTUAL MACHINE --vmdebug (default: false) ($GETH_VMDEBUG) Record information useful for VM and contract debugging COPYRIGHT: Copyright 2013-2023 The go-ethereum Authors ``` --- # コンパイル、実行とデプロイ Source: https://docs.nerochain.io/ja/node-validators/compileAndRun Section: ノードバリデータ このガイドでは、NEROのコンパイルと実行の手順を説明します。 ## ダウンロード 以下のgitコマンドを使用してNEROのソースコードをダウンロードします： ``` git clone https://github.com/nerochain/Nero.git ``` ## Golangのインストール NEROをコンパイルする前に、システムにGolangがインストールされていることを確認してください。ダウンロードとインストール手順については、Golangの公式ウェブサイト（[https://go.dev/dl/](https://go.dev/dl/)）を参照してください。 ## コンパイル 1. 以下のコマンドを使用して、NEROのソースコードをクローンしたディレクトリに移動します： ``` cd /path/to/Nero ``` 2. 以下のコマンドを実行してNEROをコンパイルします： ``` make geth ``` これにより、`build/bin`フォルダにコンパイルされたバイナリが作成されます。 ## 実行 1. 以下のコマンドを実行して、利用可能なオプションとその説明のリストを取得します： ``` ./build/bin/geth --help ``` 2. 具体的な使用方法については、[コマンドラインオプションのドキュメント](./commandLineOptions.mdx)を参照してください。 **カスタムオプション：** NEROは`--traceaction`というカスタムオプションを提供しています： ``` --traceaction value (デフォルト: 0) 内部トランザクションのcall/create/suicideアクションをトレース、0=トレースなし、1=ネイティブトークン > 0のみトレース、2=すべてトレース ``` このオプションを使用すると、内部トランザクションをトレースするためのカスタムJSON-RPCメソッドを有効または無効にすることができます。 ## デプロイ systemd管理設定の紹介。 ### ハードウェア #### 最小要件 ``` 8コア 16GB RAM SSD IOPS>5k ``` #### 推奨要件 ``` 16コア 32GB RAM SSD IOPS>5k ``` #### ネットワークとポート ``` 外部IPアドレス ポート TCP/UDP 30303 ``` ### チェーンノード - config.toml ``` [Eth] SyncMode = "snap" TrieTimeout = 1200000000000 StateScheme = "hash" [Eth.Miner] GasCeil = 40000000 Recommit = 3000000000 Noverify = false [Eth.TxPool] NoLocals = true Journal = "transactions.rlp" Rejournal = 600000000000 PriceLimit = 1000000000 PriceBump = 10 AccountSlots = 64 GlobalSlots = 10240 AccountQueue = 32 GlobalQueue = 1024 Lifetime = 1800000000000 [Node] DataDir = "/data/nerochain/data" DBEngine = "leveldb" IPCPath = "geth.ipc" HTTPHost = "0.0.0.0" HTTPPort = 8545 HTTPCors = ["*"] HTTPVirtualHosts = ["*"] HTTPModules = ['eth', 'net', 'web3', 'turbo', 'engine'] WSHost = "0.0.0.0" WSPort = 8546 WSModules = ['eth', 'net', 'web3', 'turbo', 'engine'] AuthPort = 8552 GraphQLVirtualHosts = ["localhost"] [Node.P2P] MaxPeers = 50 ListenAddr = ":30306" EnableMsgEvents = false [Node.HTTPTimeouts] ReadTimeout = 30000000000 WriteTimeout = 30000000000 IdleTimeout = 120000000000 ``` 設定でスナップ同期を使用し、フル同期が必要な場合は、この行を変更します ``` SyncMode = "snap" ``` 以下に変更： ``` SyncMode = "full" ``` ### 起動スクリプト > すべてのフラグの詳細なヘルプ情報を表示するには、`geth help`または`geth -h`と入力してください - run.sh ``` #!/usr/bin/env bash /data/nero/chain/geth-linux-amd64 \ --config /data/nero/chain/config.toml \ --log.file /data/nero/chain/logs/chain.log \ --log.rotate=true \ --traceaction 2 \ --verbosity 3 ``` アーカイブノードとして使用する必要がある場合は、以下を追加します： ``` --syncmode full \ --gcmode archive \ ``` したがって： ``` #!/usr/bin/env bash /data/nero/chain/geth-linux-amd64 \ --config /data/nero/chain/config.toml \ --log.file /data/nero/chain/logs/chain.log \ --log.rotate=true \ --traceaction 2 \ --syncmode full \ --gcmode archive \ --verbosity 3 ``` ネットワークフラグが提供されていない場合、ノードはデフォルトでNEROメインネットに接続します。NEROテストネットに接続したい場合は、以下を追加します： ``` --testnet ``` ### systemd設定 ``` [Unit] Description=NERO chain service [Service] Type=simple ExecStart=/bin/sh /data/nero/chain/run.sh WorkingDirectory=/data/nero/chain TimeoutSec=600 Restart=on-failure RestartSec=5s LimitNOFILE=65536 [Install] WantedBy=multi-user.target ``` --- # JSON-RPC Source: https://docs.nerochain.io/ja/node-validators/jsonRpc Section: ノードバリデータ NEROチェーンは[Ethereum](https://ethereum.org/developers/docs/apis/json-rpc#json-rpc-methods)に記載されているすべてのJSON-RPC APIメソッドを提供しています。 ## eth_getTraceActionByTxHash このメソッドは、トランザクションのハッシュによる内部トランザクションのログを返します。 ### パラメータ - `DATA`、32バイト：トランザクションのハッシュ。 - `Object`：フィルタオプション： - `fromUser`：`DATA|Array`、20バイト（オプション） - 送信者のアドレス。 - `toBlock`：`DATA|Array`、20バイト（オプション） - 受信者のアドレス。 - `opCode`：String（オプション） - トランザクションログのEVMオペコード。 - `minValue`：`QUANTITY|TAG`（オプション） - BRCで転送される最小値または金額。 ### 戻り値 内部トランザクションのログを含むオブジェクト、またはログが見つからない場合は`null`： - `transactionHash`：`DATA`、32バイト - トランザクションのハッシュ。 - `blockHash`：`DATA`、32バイト - ブロックのハッシュ（保留中の場合はnull）。 - `blockNumber`：`QUANTITY` - トランザクションのブロック番号。 - `logs`：トランザクションによって生成されたログオブジェクトの配列： - `from`：`DATA`、20バイト - 送信者のアドレス。 - `to`：`DATA`、20バイト - 受信者のアドレス（コントラクト作成トランザクションの場合はnull）。 - `value`：`QUANTITY` - BRCで転送された値。 - `success`：Boolean - 呼び出しが成功したかどうかを示します。 - `opcode`：`DATA` - トランザクションログのEVMオペコード。 - `depth`：`QUANTITY` - EVMでのコールスタックの深さ。 - `gas`：`QUANTITY` - 送信者が提供したガス。 - `gas_used`：`QUANTITY` - トランザクションで使用されたガスの量。 - `input`：`DATA` - トランザクションと一緒に送信されたデータ。 - `trace_address`：`QUANTITY|Array` - 実行中のコールトレースの深さを表す配列。 ### 例 リクエスト： ```shell curl -X POST --data '{ "jsonrpc":"2.0", "method":"eth_getTraceActionByTxHash", "params":["0xce9a42b2d2e0c0a7984d9351793129b91dc0599b9b4401082b75afcbc6abd694"], "id":1}' ``` レスポンス： ```json { "id": 1, "jsonrpc": "2.0", "result": [ { "transactionHash": "0xce9a42b2d2e0c0a7984d9351793129b91dc0599b9b4401082b75afcbc6abd694", "blockHash": "0x80f5779b0348102d90f5463a9a494b7454d0e1f8d8b119cf090cd90e2d6105c3", "blockNumber": 54, "logs": [ { "from": "0x2e46771cff3636a42f363826ff8a94d3a738e075", "to": "0x000000000000000000000000000000000000f000", "value": 0, "success": true, "opcode": "CALL", "depth": 18446744073709551615, "gas": 165629, "gas_used": 162996, "input": "0x6374299e0000000000000000000000009f01eb5eb4dbea8b2cecc679050819990ab68a1a000000000000000000000000000000000000000000295be96e64066972000000", "trace_address": [] }, { "from": "0x000000000000000000000000000000000000f000", "to": "0x4b20bbf3652696b9afd27b8f88ff8b7c1f361336", "value": 0, "success": true, "opcode": "STATICCALL", "depth": 0, "gas": 157800, "gas_used": 2443, "input": "0x00000000", "output": "0x0000000000000000000000002e46771cff3636a42f363826ff8a94d3a738e075", "trace_address": [0] }, { "from": "0x000000000000000000000000000000000000f000", "to": "0xf4340cf5f3891a3827713b33f769b501a0b5b122", "value": 0, "success": true, "opcode": "STATICCALL", "depth": 0, "gas": 150040, "gas_used": 2814, "input": "0x0000000000000000000000000000000000000000007c13bc4b2c133c560000000000000000000000000000000000000000000000007c13bc4b2c133c5600000000000000", "output": "0x0000000000000000000000000000000000000000007c13bc4b2c133c56000000", "trace_address": [1] } ] } ] } ``` ## eth_getTraceActionByBlockNumber ブロック番号による内部トランザクションのログを返します。 ### パラメータ 1. QUANTITY|TAG - ブロック番号の整数 2. Object - フィルタオプション： - fromUser: DATA|Array, 20バイト -（オプション）送信者のアドレス。 - toBlock: DATA|Array, 20バイト -（オプション）受信者のアドレス。 - opCode: String -（オプション）トランザクションログのEVMオペコード。 - minValue: QUANTITY|TAG -（オプション）BRCで転送される最小値または金額。 ### 戻り値 [eth_getTraceActionByTxHash](#returns)と同じ ### 例 リクエスト： ```shell curl -X POST --data '{ "jsonrpc":"2.0", "method":"eth_getTraceActionByBlockNumber", "params":["0x36"], "id":1}' ``` 結果は[eth_getTraceActionByTxHash](#example)を参照 ## eth_getTraceActionByBlockHash ブロックハッシュによる内部トランザクションのログを返します。 ### パラメータ 1. DATA、32バイト - ブロックのハッシュ。 ### 戻り値 [eth_getTraceActionByTxHash](#returns)と同じ ### 例 リクエスト： ```shell curl -X POST --data '{ "jsonrpc":"2.0", "method":"eth_getTraceActionByBlockHash", "params":["0x80f5779b0348102d90f5463a9a494b7454d0e1f8d8b119cf090cd90e2d6105c3"], "id":1}' ``` 結果は[eth_getTraceActionByTxHash](#example)を参照 --- # 概要 Source: https://docs.nerochain.io/ja/node-validators/overview Section: ノードバリデータ | 項目 | 値 | | :-------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | ガストークン（ネイティブトークン） | NERO （小数点: 18） | | プロジェクトトークン | NERO | | ネットワーク情報 | [ネットワーク](../building/network.mdx)を参照 | | ブロック間隔 | 3秒 | | ブロックのガス上限 | 40,000,000 | | ブロック再編成は発生するか？ | はい | | ファイナリティ | `15ブロック確認`で非常に高い確率で安全;
**絶対的に安全**なのは`25ブロック確認`以降 | | EIP-1559サポート | はい | | 優先手数料（Priority fee）必要額 | 1 gwei | | レガシートランザクションの最小gasPrice | 1.000000007 gwei | | EVM互換性 | `Cancun`まで対応 | | 対応Solidityバージョン | ≤ 0.8.29 | | Geth json-rpc互換性 | 完全互換 | | 追加json-rpc | [Json-RPC](./jsonRpc.mdx)を参照 | | 基本的または重要なコントラクト | [コントラクト](../aa/accessEntryPoint.mdx)を参照 | このページは現在準備中です。翻訳は後日提供されます。 英語版のドキュメントは[こちら](https://docs.nerochain.io/en/node-validators/overview)でご覧いただけます。 --- # バリデーター Source: https://docs.nerochain.io/ja/node-validators/runningValidatorNode Section: ノードバリデータ ## 概要 NEROチェーンは、短いブロック時間と低い手数料をサポートするハイブリッドランダム化DPoSA（委任ステーク権限証明）コンセンサスを持つ複数のバリデーターシステムに依存しています。ステーキングにおいて最もボンディングされたバリデーターがブロックを生成する機会を持ちます。非アクティブ検出やその他のスラッシングロジックにより、セキュリティ、安定性、およびチェーンのファイナリティが確保されます。 NEROチェーン上のバリデーターノードは、ブロックを生成し、コンセンサスメカニズムを通じてネットワークを保護する責任を持つノードです。それぞれがバリデーターを代表し、トランザクションのパッケージング、ブロックの作成と検証に参加してNEROネットワークを保護し、見返りとしてNEROトークンを報酬として獲得します。 ## バリデーターアカウントの生成方法 以下のコマンドを使用してアカウントを生成します（アカウントを安全に保つための強力なパスワードが必要です）： ```shell ./geth --datadir ./ account new ``` 例： ```shell -> % ./geth --datadir ./ account new INFO [09-24|11:13:09.372] Maximum peer count ETH=50 total=50 Your new account is locked with a password. Please give a password. Do not forget this password. Password: Repeat password: Your new key was generated Public address of the key: 0xDbCFCBb1C4442eC76D329996530F1461733916ca Path of the secret key file: keystore/UTC--2024-09-24T03-13-16.723669000Z--dbcfcbb1c4442ec76d329996530f1461733916ca - You can share your public address with anyone. Others need it to interact with you. - You must NEVER share the secret key with anyone! The key controls access to your funds! - You must BACKUP your key file! Without the key, it's impossible to access account funds! - You must REMEMBER your password! Without the password, it's impossible to decrypt the key! ``` そして、公開アドレスをバリデーターアドレスとして使用します。 ## バリデータノードの実行 まず、[コンパイルと実行](./compileAndRun.mdx) の内容をよく理解しておいてください。 次に、以下の手順に従ってください。 - バリデータの秘密鍵ファイルをディレクトリ `/keystore/` にコピーします。 例えば、`config.toml` の `DataDir` が `DataDir = "/data/nerochain/data"` である場合、鍵ファイルのパスは `/data/nerochain/data/keystore/UTC--2024-09-24T03-13-16.723669000Z--dbcfcbb1c4442ec76d329996530f1461733916ca` となります。 - バリデータの秘密鍵のパスワードをテキストファイル（例: `/data/nerochain/.password`）に保存します。 - `run.sh` に以下の起動オプションを追加します。 ```sh --miner.etherbase \ --mine \ --allow-insecure-unlock \ --unlock \ --password /data/nerochain/.password \ ``` また、バリデータノードにはフル同期を推奨します。 ``` SyncMode = "full" ``` すべての設定が完了したら、バリデータノードを実行できます。 ノードが最新のブロックに追従していることを確認し、システムのステーキングコントラクト（`0x000000000000000000000000000000000000F000`）を通じてバリデータのステークを管理し、準備を整えてください。バリデータがアクティブなバリデータとなると、NEROネットワークのトランザクションのパッケージ化、ブロックの作成と検証に参加し、報酬としてNEROトークンを獲得できるようになります。 --- # システムコントラクト Source: https://docs.nerochain.io/ja/node-validators/systemContract Section: ノードバリデータ ## 概要 Nero ブロックチェーンのバリデーターシステムは、`Validator`コントラクトと`Staking`コントラクトの 2 つの主要コンポーネントで構成されています。各バリデーターは独自の`Validator`コントラクトインスタンスを持ち、`Staking`コントラクトが全体を統括する委任型プルーフ・オブ・ステーク（DPoS）コンセンサスメカニズムを実装しています。 ## コントラクトアーキテクチャ ### Staking コントラクト 中央オーケストレーターとして機能し、以下の役割を担います： - バリデーター登録・管理 - 報酬分配 - 罰則システムの実行 - アクティブバリデーターセットの管理 ### Validator コントラクト 各バリデーター固有の状態と委任を管理します： - バリデーター固有のステーク管理 - 委任者の管理 - 報酬計算 - アンボンディング処理 ## 主要機能の仕組み ### ステーキング機能 #### バリデーター登録 バリデーターの登録は`registerValidator()`関数を通じて行われます： - 最小自己ステーク：`MinSelfStakes`（1,000 万 NERO） - コミッション率：0-100%の範囲 - 委任受付の可否設定 #### 委任メカニズム 委任者は`addDelegation()`を通じてバリデーターにステークを委任できます： - バリデーターの委任受付設定確認 - 総ステーク上限チェック（`MaxStakes`: 2 億 NERO） - 新規委任者の登録 - 罰則処理の実行 - 報酬精算と債務更新 #### アンボンディングシステム ステーク削除時の処理： - **期間**：`UnboundLockPeriod`（21 日間） - **管理**：`UnboundRecord`構造体で追跡 - **引き出し**：期間経過後に`claimableUnbound()`で計算 ### 報酬システム #### 報酬計算メカニズム 債務ベースのシステムで公平な報酬分配を実現： - `accRewardsPerStake`による累積報酬計算 - コミッション率に基づく手数料分配 - 精度向上のため COEFFICIENT（1e18）倍で処理 #### ブロック報酬分配 `distributeBlockFee()`により実行： - アクティブバリデーター間で均等分配 - 各バリデーターの`incomeFees`に加算 #### ステーキング報酬 `updateRewardsRecord()`で更新： - ブロックごとに`rewardsPerBlock`を分配 - `accRewardsPerStake`の累積更新 - 総ステーキング報酬からの減算 ### バリデーター状態管理 バリデーターは以下の 4 つの状態を持ちます： | 状態 | 説明 | 条件 | | --------- | -------------------- | --------------------------------------------------------------------- | | **Idle** | 初期状態 | `totalStake` < `ThresholdStakes` | | **Ready** | コンセンサス参加可能 | `totalStake` >= `ThresholdStakes` かつ `selfStake` >= `MinSelfStakes` | | **Jail** | 罰則状態 | 罰則適用時、`JailPeriod`（86,400 秒）間コンセンサス参加不可 | | **Exit** | 退出状態 | 全ステークのアンボンディング中 | #### 状態遷移 - **Idle → Ready**：ステーク条件満足時 - **Ready → Jail**：罰則適用時 - **Jail → Ready**：罰則期間経過＋ステーク条件満足時 - **Any → Exit**：`exitStaking()`呼び出し時 ### 罰則システム #### Lazy Punishment（怠惰な罰則） ブロック提案を逃した場合の罰則： - **閾値**：`LazyPunishThreshold`（48 ブロック）連続 - **罰則率**：`LazyPunishFactor`（0.5%） - **カウンター減少**：エポックごとに 2 ずつ減少 - **実行**：`lazyPunish()`により自動実行 #### Evil Punishment（悪意ある罰則） 二重署名などの悪意ある行動への罰則： - **罰則率**：`EvilPunishFactor`（5%） - **実行**：`doubleSignPunish()`により即座に適用 - **制限**：同一バリデーターに対して一度のみ #### 罰則実行プロセス `punish()`関数の実行フロー： 1. 報酬精算とバリデーターの`selfSettledRewards`更新 2. `totalUnWithdrawn`から罰則額計算 3. `totalStake`から削減 4. バリデーターの自己ステークから削減、不足分はアンボンディング中のステークから削減 5. `accPunishFactor`更新 6. 状態を Jail に遷移 #### 委任者への罰則適用 - `accPunishFactor - punishFree`の差分のみ適用 - 罰則額は`(totalDelegation * deltaFactor) / PunishBase`で計算 - アクティブステークから削減、不足分はアンボンディング中のステークから削減 - 報酬は罰則前後のステーク比率で調整 ## 重要機能 ### ReStaking/ReDelegation ステーク移動機能： - **reStaking**：バリデーターが自己ステークを別のバリデーターに委任として移動 - **reDelegation**：委任者が委任先を変更 - **利点**：アンボンディング期間なしで即座に移動 ### Founder Locking System 創設者バリデーター向けの特別なロック機構： - `basicLockEnd`まで完全ロック - その後、`releasePeriod`ごとに段階的解放 - 全期間経過後に完全解放 ### SortedLinkedList によるランキング管理 総ステーク量に基づくバリデーターランキング： - **Up**：ステーク増加時のランキング上昇 - **Down**：ステーク減少時のランキング下降 - **Remove**：Ready 状態から外れる時のリスト削除 ### Permission 管理 2 つの動作モード： - **Permission mode**（`isOpened = false`）：管理者のみ登録可能 - **Permissionless mode**（`isOpened = true`）：誰でも`MinSelfStakes`以上で登録可能 - **注意**：`removePermission()`は不可逆的操作 ### 操作制限メカニズム 重要な操作に対する制限： - **onlyOperateOnce**：同一ブロック内で一度のみ実行 - **onlyBlockEpoch**：エポック境界でのみ実行 - **ReentrancyGuard**：再入攻撃防止 ## システムパラメータ | パラメータ | 値 | 説明 | | --------------------- | -------------- | -------------------------------- | | `MaxValidators` | 25 | 最大アクティブバリデーター数 | | `MaxStakes` | 2 億 NERO | バリデーターあたりの最大ステーク | | `ThresholdStakes` | 1,000 万 NERO | 候補者になるための最小ステーク | | `MinSelfStakes` | 1,000 万 NERO | 登録に必要な最小自己ステーク | | `UnboundLockPeriod` | 21 日間 | アンボンディング期間 | | `JailPeriod` | 86,400 秒 | 罰則期間（24 時間） | | `LazyPunishThreshold` | 48 ブロック | 怠惰な罰則の閾値 | | `LazyPunishFactor` | 5/1000（0.5%） | 怠惰な罰則率 | | `EvilPunishFactor` | 50/1000（5%） | 悪意ある罰則率 | | `StakeUnit` | 1 NERO | ステーク操作の最小単位 | ## ステーク単位の制約 全てのステーク操作は 1 NERO 単位で制限されています： - **最小単位**：`StakeUnit`（1 NERO）以上 - **単位制限**：1 NERO の整数倍のみ - **検証**：`mustConvertStake()`関数による自動チェック ## Exit 状態での強制引き出し バリデーターが Exit 状態で`exitLockEnd`を過ぎた場合： - **委任者の権限**：強制的にステークを引き出し可能 - **目的**：バリデーターが応答しなくても資金回収可能 - **安全性**：委任者資産の保護 ## セキュリティ機能 ### ReentrancyGuard 保護 重要なクレーム操作には再入攻撃防止が実装： - `validatorClaimAny()` - `delegatorClaimAny()` - `reStaking()` - `reDelegation()` ### 操作制限メカニズム Nero Engine からの呼び出しに重要な制限： - **onlyOperateOnce**：同一ブロック内で一度のみ実行 - **onlyBlockEpoch**：エポック境界でのみ実行 - **対象**：`distributeBlockFee()`、`updateActiveValidatorSet()`等 ## コントラクト関数リファレンス ### Read Contract（読み取り専用関数） #### Validator コントラクト **基本情報取得** - `state()`：バリデーターの現在の状態（Idle/Ready/Jail/Exit） - `validator()`：バリデーターアドレス - `manager()`：管理者アドレス - `totalStake()`：総ステーク量 **報酬・引き出し計算** - `anyClaimable()`：引き出し可能な総額（報酬+ステーク） - `claimableRewards()`：引き出し可能な報酬のみ - `getPendingUnboundRecord()`：特定のアンボンディングレコード取得 - `getAllDelegatorsLength()`：委任者の総数 #### Staking コントラクト **システム状態** - `valMaps(address)`：バリデーターアドレスから Validator コントラクトインスタンス取得 - `valInfos(address)`：バリデーター情報（ValidatorInfo 構造体）取得 - `founders(address)`：創設者ロック情報取得 - `totalStake()`：システム全体の総ステーク量 - `isOpened()`：パーミッションレスモードかどうか **報酬情報** - `rewardsPerBlock()`：ブロックあたりの報酬量 - `accRewardsPerStake()`：累積報酬/ステーク比率 #### GenesisLock コントラクト - `getClaimableAmount(address)`：引き出し可能な金額と期間 - `getClaimablePeriod(address)`：引き出し可能な期間数計算 ### Write Contract（状態変更関数） #### Validator コントラクト **バリデーター操作** - `addStake(uint256)`：自己ステークを追加 - `subStake(uint256, bool)`：自己ステークを削減 - `exitStaking()`：バリデーターを退出状態に遷移 - `validatorClaimAny(address payable)`：バリデーターの報酬とステークを引き出し **委任操作** - `addDelegation(uint256, address)`：委任を追加 - `subDelegation(uint256, address, bool)`：委任を削減 - `exitDelegation(address)`：委任を完全に退出 - `delegatorClaimAny(address payable)`：委任者の報酬とステークを引き出し **罰則** - `punish(uint)`：罰則を適用（Staking コントラクトから呼び出し） #### Staking コントラクト **初期化・設定** - `initialize()`：コントラクトを初期化 - `removePermission()`：パーミッションレスモードに移行（不可逆） **バリデーター管理** - `registerValidator(address, uint, bool)`：新規バリデーター登録 - `addStake(address)`：バリデーターの自己ステーク追加 - `subStake(address, uint256)`：バリデーターの自己ステーク削減 - `exitStaking(address)`：バリデーター退出 **委任管理** - `addDelegation(address)`：委任を追加 - `subDelegation(address, uint256)`：委任を削減 - `exitDelegation(address)`：委任を完全退出 **ステーク移動** - `reStaking(address, address)`：バリデーターの自己ステークを別のバリデーターに委任として移動 - `reDelegation(address, address)`：委任先を変更 **引き出し** - `validatorClaimAny(address)`：バリデーターの報酬とステークを引き出し - `delegatorClaimAny(address)`：委任者の報酬とステークを引き出し **Engine 専用操作** - `updateActiveValidatorSet(address[])`：アクティブバリデーターセットを更新 - `distributeBlockFee()`：ブロック報酬を分配 - `lazyPunish(address)`：怠惰な罰則を適用 - `decreaseMissedBlocksCounter()`：罰則カウンターを減少 - `doubleSignPunish(address, bytes32)`：二重署名罰則を適用 #### GenesisLock コントラクト - `initialize(uint256)`：コントラクトを初期化 - `init()`：ユーザーデータを一括初期化 - `appendLockRecord()`：新規ロックレコードを追加 - `claim()`：ロック解除された資産を引き出し ## 重要な注意事項 ### 委任者の罰則保護 - 委任者は`punishFree`フィールドで罰則から部分的に保護 - 新規委任者には現時点の`accPunishFactor`が記録 - 既存委任者には差分のみが適用される ### 精度処理 - 報酬計算は COEFFICIENT（1e18）倍で拡大処理 - 精度向上により公平な報酬分配を実現 ### アクセス制御 - 全ての状態変更関数は適切なアクセス制御修飾子で保護 - Validator コントラクトの関数は基本的に Staking コントラクトからのみ呼び出し - エンドユーザーは Staking コントラクトを通じて操作 ### 初期化プロセス - ジェネシスブロックでのみ`initValidator()`を使用して創設者バリデーターを登録 - 創設者バリデーターは自動的に`State.Ready`で作成 - `founders`マッピングに登録され、特別なロック機構が適用 --- # サポート & リソース Source: https://docs.nerochain.io/ja/supports Section: supports 以下の公式チャネルを通じて、NERO Chainコミュニティからサポートを受けたり、交流したりすることができます： ## コミュニティサポート - **[Discord](https://discord.gg/nerochainofficial)**: リアルタイムの技術サポート、開発に関する議論、ネットワークの更新情報を得るために、活発なコミュニティにご参加ください。 - **[Telegram](https://t.me/nerochainofficial)**: 私たちのチームや他のNERO Chainユーザーとつながりましょう。 - **[Twitter](https://twitter.com/Nerochain_io)**: お知らせ、ニュース、更新情報を入手するためにフォローしてください。 ## 開発者リソース - **[GitHub リポジトリ](https://github.com/nerochain)**: オープンソースコードへのアクセス、問題の報告、貢献ができます。 - **[ドキュメント](https://docs.nerochain.io)**: 包括的なガイド、チュートリアル、APIリファレンスが提供されています。 --- # NEROチェーン上でのスマートコントラクトのデプロイと検証 Source: https://docs.nerochain.io/ja/tutorials/first-contract/using-hardhat Section: クックブック このチュートリアルでは、Hardhatを使用してNEROモジュラーチェーンテストネット上にシンプルなスマートコントラクトを作成、コンパイル、デプロイ、検証する方法を説明します。 ## 前提条件 - [Node.js](https://nodejs.org)がインストール済み - テストネットNEROトークンを持つ秘密鍵 ([このフォーセット](https://app.testnet.nerochain.io/faucet)からテストネットのNEROトークンを取得できます) - SolidityとHardhatに関する基本的な理解 ## プロジェクトのセットアップ まず、新しいディレクトリを作成しプロジェクトを初期化します： ```javascript require("@nomicfoundation/hardhat-toolbox"); require("dotenv").config(); module.exports = { defaultNetwork: "nero", networks: { nero: { url: "https://rpc-testnet.nerochain.io", chainId: 689, accounts: [process.env.PRIVATE_KEY] }, }, solidity: "0.8.17", etherscan: { apiKey: "dummy", customChains: [ { network: "nero", chainId: 689, urls: { apiURL: "https://api-testnet.neroscan.io/api", browserURL: "https://testnet.neroscan.io/" } } ] } }; ``` プロンプトが表示されたら、プロジェクトに適したオプションを選択します： ![図1](https://docs.nerochain.io/assets/building/figure1.png)

図1: npx hardhat

## スマートコントラクトの作成 contractsディレクトリを作成（まだ作成されていない場合）し、スマートコントラクトファイルを追加します： ```bash mkdir -p contracts ``` 独自のスマートコントラクトを作成するか、[Openzeppelinトークンスマートコントラクト](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)などのテンプレートを使用できます。 以下は使用可能なシンプルなサンプルコントラクトです： ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.17; contract HelloWorld { string private greeting = "Hello, NERO Chain!"; function setGreeting(string calldata _greet) public { greeting = _greet; } function getGreeting() public view returns (string memory) { return greeting; } } ``` ## NEROチェーン用のHardhat設定 プロジェクトのルートに`.env`ファイルを作成し、以下の変数を設定します： ``` NERO_TESTNET_PROVIDER_URL=https://rpc-testnet.nerochain.io PRIVATE_KEY=あなたの秘密鍵をここに入力 API_KEY=dummy ``` 次に、Hardhat設定ファイルを更新します： **hardhat.config.js:** ```javascript require("@nomicfoundation/hardhat-toolbox"); require("@nomicfoundation/hardhat-ignition-ethers"); require("dotenv").config(); const { vars } = require("hardhat/config"); const NERO_TESTNET_PROVIDER_URL = process.env.NERO_TESTNET_PROVIDER_URL || vars.get("NERO_TESTNET_PROVIDER_URL"); const PRIVATE_KEY = process.env.PRIVATE_KEY || vars.get("PRIVATE_KEY"); const API_KEY = process.env.API_KEY || vars.get("API_KEY"); module.exports = { solidity: "0.8.24", defaultNetwork: "nero_testnet", networks: { nero_testnet: { url: NERO_TESTNET_PROVIDER_URL, accounts: [PRIVATE_KEY], chainId: 689 }, }, etherscan: { apiKey: API_KEY, customChains: [ { network: "nero_testnet", chainId: 689, urls: { apiURL: "https://api-testnet.neroscan.io/api", browserURL: "https://testnet.neroscan.io", }, }, ], enabled: true }, }; ``` **hardhat.config.ts:** ```typescript dotenv.config(); const NERO_TESTNET_PROVIDER_URL = process.env.NERO_TESTNET_PROVIDER_URL || vars.get("NERO_TESTNET_PROVIDER_URL"); const PRIVATE_KEY = process.env.PRIVATE_KEY || vars.get("PRIVATE_KEY"); const API_KEY = process.env.API_KEY || vars.get("API_KEY"); const config: HardhatUserConfig = { solidity: "0.8.24", defaultNetwork: "nero_testnet", networks: { nero_testnet: { url: NERO_TESTNET_PROVIDER_URL, accounts: [PRIVATE_KEY], chainId: 689 }, }, etherscan: { apiKey: API_KEY, customChains: [ { network: "nero_testnet", chainId: 689, urls: { apiURL: "https://api-testnet.neroscan.io/api", browserURL: "https://testnet.neroscan.io", }, }, ], enabled: true }, }; export default config; ``` ## スマートコントラクトのデプロイ コントラクトのデプロイには、デプロイメントスクリプトまたはHardhat Ignitionを使用できます。 ### オプション1: デプロイメントスクリプトを使用 scriptsディレクトリを作成し、デプロイメントスクリプトを追加します： ```bash mkdir -p scripts ``` `scripts/deploy.js`ファイルを作成して以下の内容を入力します： ```javascript async function main() { const HelloWorld = await ethers.getContractFactory("HelloWorld"); const contract = await HelloWorld.deploy(); await contract.waitForDeployment(); console.log("HelloWorld deployed to:", await contract.getAddress()); } main().catch((error) => { console.error(error); process.exitCode = 1; }); ``` 次のコマンドでデプロイします： ```bash npx hardhat run scripts/deploy.js --network nero_testnet ``` ### オプション2: Hardhat Ignitionを使用 より複雑なデプロイメントには、Hardhat Ignitionを使用できます： 1. ignitionモジュールディレクトリを作成します： ```bash mkdir -p ignition/modules ``` 2. デプロイメントモジュールファイル（例：`ignition/modules/deploy-hello-world.js`）を作成します： ```javascript const { buildModule } = require("@nomicfoundation/hardhat-ignition/modules"); module.exports = buildModule("HelloWorldModule", (m) => { const helloWorld = m.contract("HelloWorld"); return { helloWorld }; }); ``` 3. Ignitionでデプロイします： ```bash npx hardhat ignition deploy ./ignition/modules/deploy-hello-world.js --network nero_testnet ``` 4. 出力からデプロイされたコントラクトアドレスを保存します。 ## スマートコントラクトの検証 コントラクトをデプロイした後、NEROチェーンエクスプローラー上でソースコードを公開するために検証します： ```bash npx hardhat verify --network nero_testnet デプロイされたコントラクトアドレス ``` 「デプロイされたコントラクトアドレス」は実際のデプロイされたコントラクトアドレスに置き換えてください。 ### 検証のトラブルシューティング 1. 検証に失敗する場合は、Solidityコンパイラのバージョンが完全に一致していることを確認します 2. コントラクトがフラット化されたファイルに含まれていないライブラリや依存関係を使用していないか確認します 3. コンストラクタ引数を使用している場合は、検証コマンドで正しく提供されていることを確認します： ```bash npx hardhat verify --network nero_testnet デプロイされたコントラクトアドレス "コンストラクタ引数1" "コンストラクタ引数2" ``` ## 結論 デプロイと検証が完了したら、[テストネットエクスプローラー](https://testnet.neroscan.io/)でコントラクトを確認できます。 ![図2](https://docs.nerochain.io/assets/building/figure2.png)

図2: NEROテストネットスキャン

おめでとうございます！スマートコントラクトのデプロイと検証に成功しました。このチュートリアルではテストネットを使用しましたが、RPCエンドポイントとネットワーク設定を更新することで、メインネットでも同じプロセスを使用できます。 --- # NEROチェーンでRemixを使用した初めてのコントラクトのデプロイ Source: https://docs.nerochain.io/ja/tutorials/first-contract/using-remix Section: クックブック このチュートリアルでは、Remix IDEを使用してNEROチェーン上にスマートコントラクトを作成してデプロイするプロセスを説明します。Remixは人気のあるブラウザベースの開発環境で、セットアップが不要なため、初心者に最適です。 ## 前提条件 - ブラウザにインストールされたWeb3ウォレット（MetaMaskなど） - Solidityプログラミング言語の基本知識 - ガス代用のNEROテストネットトークン（[NEROフォーセット](https://app.testnet.nerochain.io/)から入手可能） ## 環境のセットアップ ### 1. ウォレットをNEROチェーンに接続する 始める前に、NEROチェーンをMetaMaskウォレットに追加する必要があります： 1. MetaMaskを開き、上部のネットワークドロップダウンをクリック 2. 「ネットワークを追加」を選択 3. NEROテストネットの場合、以下の設定を使用： - ネットワーク名：`NEROテストネット` - RPC URL：`https://rpc-testnet.nerochain.io` - チェーンID：`689` - 通貨シンボル：`NERO` - ブロックエクスプローラーURL：`https://testnet.neroscan.io` ![MetaMaskの設定](https://docs.nerochain.io/assets/cookbook/metanerotest.gif) ### 2. Remix IDEを開く ブラウザで[Remix IDE](https://remix.ethereum.org/)に移動します。 ## シンプルなスマートコントラクトの作成 ストレージ機能を持つシンプルな「Hello World」コントラクトを作成しましょう。 ### 1. 新しいファイルを作成 Remixで： 1. 左側のサイドバーにある「ファイルエクスプローラー」アイコンをクリック 2. 「+」アイコンをクリックして新しいファイルを作成 3. `HelloWorld.sol`という名前を付ける ### 2. スマートコントラクトを書く 以下のコードを新しいファイルにコピー＆ペーストします： ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.17; contract HelloWorld { string private greeting; constructor() { greeting = "Hello, NERO Chain!"; } function setGreeting(string memory _greeting) public { greeting = _greeting; } function getGreeting() public view returns (string memory) { return greeting; } } ``` このシンプルなコントラクトは： - 挨拶メッセージを保存する - 誰でも挨拶を更新できる - 現在の挨拶を取得する関数を提供する ![Remixでのコントラクト作成](https://docs.nerochain.io/assets/cookbook/remixcreate.gif) ## コントラクトのコンパイル ### 1. コンパイラタブに移動 左側のサイドバーにある「Solidityコンパイラ」アイコン（2番目のアイコン）をクリックします。 ### 2. コンパイラバージョンの選択 pragmaステートメントに一致するコンパイラバージョンを選択します（この場合、0.8.17以上）。 ### 3. コントラクトのコンパイル 「HelloWorld.solをコンパイル」ボタンをクリックします。成功すると、緑色のチェックマークが表示されます。 ![Remixでのコンパイル](https://docs.nerochain.io/assets/cookbook/remixcomp.gif) ## コントラクトのデプロイ ### 1. デプロイタブに移動 左側のサイドバーにある「デプロイ＆実行トランザクション」アイコン（3番目のアイコン）をクリックします。 ### 2. 環境の設定 1. 「環境」ドロップダウンから「Injected Provider - MetaMask」を選択 2. MetaMaskが接続を促します - NEROテストネットに接続されていることを確認 3. 「アカウント」フィールドにウォレットアドレスが表示されていることを確認 ### 3. コントラクトのデプロイ 1. 「コントラクト」ドロップダウンで「HelloWorld」が選択されていることを確認 2. 「デプロイ」ボタンをクリック 3. MetaMaskがトランザクションの確認を求めます - ガス料金を確認して「確認」をクリック 4. トランザクションがマイニングされるのを待ちます（NEROチェーンでは通常数秒かかります） ![Remixでのデプロイ](https://docs.nerochain.io/assets/cookbook/remixdeploy.gif) ## デプロイされたコントラクトとの対話 デプロイ後、コントラクトは「デプロイされたコントラクト」セクションに表示されます。 ### 挨拶の読み取り 1. 「デプロイされたコントラクト」セクションでコントラクトを展開 2. 「getGreeting」関数を見つける（青いボタン、読み取り専用関数を示す） 3. クリックして保存されている挨拶を取得 ### 挨拶の更新 1. 「setGreeting」関数を見つける（オレンジ色のボタン、状態を変更することを示す） 2. 入力フィールドに新しい挨拶メッセージを入力 3. 「setGreeting」ボタンをクリック 4. MetaMaskでトランザクションを確認 5. トランザクションがマイニングされた後、再度「getGreeting」を呼び出して更新を確認 ![Remixでの対話](https://docs.nerochain.io/assets/cookbook/remixinteract.gif) ## ブロックエクスプローラーでのコントラクトの検証 他の人があなたのコントラクトと対話し、そのコードを表示できるようにするには、ブロックエクスプローラーでそれを検証する必要があります： 1. Remixの「デプロイされたコントラクト」セクションからコントラクトアドレスをコピー 2. [NEROチェーンエクスプローラー](https://testnet.neroscan.io)にアクセス 3. 検索バーにコントラクトアドレスを貼り付け 4. 「Contract」タブをクリック 5. 「Verify and Publish」をクリック 6. 必要な情報を入力： - コントラクト名：`HelloWorld` - コンパイラバージョン：使用したバージョン（例：`v0.8.17+commit.8df45f5f`） - オープンソースライセンスタイプ：`MIT License (MIT)` 7. 「Enter the Solidity Contract Code」フィールドに、コントラクトコード全体を貼り付け 8. 「Verify and Publish」をクリック 検証後、ユーザーはエクスプローラーから直接あなたのコントラクトコードを読み、対話することができます。 ## 一般的な問題のトラブルシューティング ### トランザクションの失敗 デプロイトランザクションが失敗する場合、以下を確認してください： - ガス代のために十分なNEROトークンがありますか？ - MetaMaskはNEROチェーンに接続されていますか？ - コントラクトコードにエラーはありませんか？ ### 高いガス料金 NEROチェーンは比較的ガス料金が低いですが、高く感じる場合： - 正しいネットワークに接続されているか確認 - 混雑していない時間に試す ### コンパイラエラー コンパイラエラーが発生した場合： - Solidityバージョンが互換性があることを確認（0.8.0以上を推奨） - 構文エラーがないか確認 - NEROチェーンで利用できないかもしれないイーサリアム固有の関数への参照がないか確認 ## 高度なヒント ### ライブラリの使用 外部ライブラリを使用する場合： 1. importステートメントを使ってそれらをインポート 2. NEROチェーンと互換性があることを確認 ```solidity // OpenZeppelinのERC20コントラクトをインポートする例 ``` ### コンストラクタ引数 コントラクトがコンストラクタ引数を必要とする場合： 1. 「デプロイ」ボタンの横のフィールドにそれらを入力 2. 複数の引数はカンマで区切る ### コントラクトサイズの制限 NEROチェーンは、イーサリアムと同様に、最大コントラクトサイズ制限があります。コントラクトが大きすぎる場合： - 複数のコントラクトに分割 - コードを最適化 - コードを再利用するためにライブラリを使用 ## 次のステップ 最初のコントラクトをデプロイしたので、次のことを学ぶことができます： 1. [NEROチェーン上のアカウント抽象化](https://docs.nerochain.io/ja/tutorials/low-level/aa-wallet-integration)について学ぶ 2. ガスレストランザクションのための[Paymasterインテグレーション](https://docs.nerochain.io/ja/tutorials/low-level/paymaster-integration)を探る 3. [Reactを使った完全なdApp](https://docs.nerochain.io/ja/tutorials/low-level/create-first-dapp)を構築する 4. より複雑なプロジェクトのために[Hardhat](https://docs.nerochain.io/ja/tutorials/low-level/first-contract/using-hardhat)を使ったデプロイを試す 5. [クイックビルディング](https://docs.nerochain.io/ja/tutorials/high-level/building-blocks) 用のハイレベルテンプレートを試してみてください。 --- # NEROエクスプローラーを通じたスマートコントラクトの検証 Source: https://docs.nerochain.io/ja/tutorials/first-contract/verifyExplorer Section: クックブック このガイドでは、NEROチェーンテストネット上のスマートコントラクトをブロックエクスプローラーインターフェースで検証するプロセスについて説明します。コントラクト検証により、ソースコードが公開され、ユーザーはエクスプローラーから直接コントラクトとやり取りできるようになります。 ## 前提条件 - NEROチェーン上にデプロイされたスマートコントラクト - コントラクトのソースコード - コントラクトのデプロイアドレス - デプロイパラメータ（コンパイラバージョン、最適化設定など） ## ステップ1: NEROチェーンエクスプローラーへのアクセス Webブラウザで[NEROテストネットエクスプローラー](https://testnet.neroscan.io/)にアクセスします。 ## ステップ2: コントラクトの検索 エクスプローラーページ上部の検索ボックスにコントラクトのデプロイアドレスを入力します。 ![図3](https://docs.nerochain.io/assets/building/figure3.png)

図3: アドレスによるコントラクトの検索

## ステップ3: 検証ページへのアクセス コントラクト詳細ページで「Verify and Publish」ボタンを見つけてクリックします。 ![図4](https://docs.nerochain.io/assets/building/figure4.png)

図4: 検証オプション付きのコントラクト詳細ページ

## ステップ4: コントラクト情報の入力 検証フォームにコントラクトの詳細を入力します： 1. **コントラクト名**: 正確なコントラクト名を入力 2. **コンパイラバージョン**: デプロイ時に使用したバージョンを選択 3. **最適化**: デプロイ設定と一致させる 4. **ソースコード**: 完全なコントラクトソースコードを貼り付け 5. **コンストラクタ引数**: ABIエンコードされたコンストラクタ引数を入力（該当する場合） ![図5](https://docs.nerochain.io/assets/building/figure5.png)

図5: コントラクト検証フォーム

![図6](https://docs.nerochain.io/assets/building/figure6.png)

図6: 詳細なコントラクト検証設定

## ステップ5: 検証の完了 「Verify and Publish」ボタンをクリックして情報を送信します。成功すると、コントラクトのソースコードがエクスプローラー上で公開されます。 ## 次のステップ 検証が完了すると、ユーザーは以下のことができるようになります： - コントラクトのソースコードを読む - エクスプローラーインターフェースから直接コントラクトとやり取りする - コントラクトのセキュリティと機能性に対する信頼性が向上する プログラムによる検証オプションについては、[Hardhat検証ガイド](https://docs.nerochain.io/ja/tutorials/first-contract/using-hardhat)を参照してください。 --- # クイック・ビルディングブロック Source: https://docs.nerochain.io/ja/tutorials/high-level/building-blocks Section: クックブック このガイドでは、次のセクションで紹介する NERO Wallet dApp の拡張における設計選択と実装の詳細について説明します。本ガイドは、チュートリアルであると同時に、アカウント抽象化（Account Abstraction）の概念を理解するための解説資料でもあります。 ## アカウント抽象化とは？ アカウント抽象化（AA）とは、スマートコントラクトウォレットを、通常のユーザーアカウントのように動作させつつ、より高度な機能を持たせることを可能にする仕組みです。 従来のEOA（Externally Owned Account）ウォレットは秘密鍵に依存していますが、AAウォレットはスマートコントラクトを利用してトランザクションを処理します。これにより、以下のような機能が実現できます： - マルチシグ認証 - ガス代スポンサー（ユーザーがトークンを持たなくてもOK） - トランザクションのバッチ処理 - アカウント復元メカニズム - プログラム可能なセキュリティルール ## User Operation（UserOp）の理解 NERO Wallet の実装では、ERC-4337標準に基づいてUser Operation（UserOp）という概念を導入しています。これは通常のトランザクションとは異なります： 1. 通常のトランザクション：ブロックチェーンに直接送信され、送信者がガス代を支払う必要があります 2. User Operation：専用のメモリプールに送信され、Bundler や Paymaster といったインフラによって処理されます UserOp の処理フローは以下のようになります： ``` User → UserOp → Bundler → EntryPoint Contract → Smart Contract Wallet (AA) → Target Contract ``` それぞれの役割は： - **Bundler**：UserOp を集めてブロックチェーンに送信 - **Paymaster**：ユーザーの代わりにガス代を負担 - **EntryPoint Contract**：UserOp を検証・実行する中心的なコントラクト ## 書き込み操作における UserOps の利用 以下の例は、高レベルテンプレートの useSendUserOp を用いた書き込み操作の方法です: ```js await execute({ function: 'mint', contractAddress: FREE_NFT_ADDRESS, abi: NERO_NFT_ABI, params: [AAaddress, nftImageUrl], value: 0, }); ``` **UserOp を使うメリット**: 1. **ガスの抽象化**: ユーザーがガストークンを持っていなくても操作可能 2. **バッチ処理**: 複数の操作を一括で実行できる 3. **署名の抽象化**: 秘密鍵の代わりにソーシャルログインが利用可能 4. **UX向上**: ユーザーにとって分かりやすく、簡単に操作できる ## 読み取り操作におけるダイレクトRPCの使用 読み取り操作は、「バニラスタイル」でシンプルにブロックチェーンから情報を取得できます。 ```js const provider = new ethers.providers.JsonRpcProvider(config.rpcUrl); const nftContract = new ethers.Contract(FREE_NFT_ADDRESS, NERO_NFT_ABI, provider); const balance = await nftContract.balanceOf(AAaddress); ``` **Direct RPC を使うメリット**: 1. **効率的**: 読み取り専用操作にUserOpは不要 2. **無料**: 読み取りはガス代がかからない 3. **高速**: BundlerやPaymasterを経由しないため速い 4. **シンプル**: 実装やデバッグが簡単 ## The NERO Wallet Configuration The NERO Wallet leverages several key components for configuration: ### 1. Web3Auth 統合 ソーシャルログイン機能のために Web3Auth を利用しており、GoogleやFacebookなどのアカウントでログイン可能です。秘密鍵の管理が不要になります。 ```js // From nerowallet.config.ts web3auth: { clientId: import.meta.env.VITE_TESTNET_WEB3AUTH_ID ?? '', network: 'testnet', uiConfig: { appName: 'NERO', // ... other config }, loginConfig: { google: { // ... google config }, facebook: { // ... facebook config } } } ``` ### 2. コンフィグレーションコンテキスト チェーン情報やRPC URL、コントラクトアドレスなどを一元管理するための設定コンテキストを使用しています。これにより、テストネット／メインネットどちらでも動作させることが可能です。 ```js const config = useConfig(); // Access RPC URL, chain info, etc. ``` ### 3. スマートコントラクトとのやり取り ウォレットは以下の2つの方法でスマートコントラクトと通信します： **書き込み操作：useSendUserOp フックを使用**: ```js const { execute, waitForUserOpResult } = useSendUserOp(); await execute({/* operation details */}); const result = await waitForUserOpResult(); ``` **読み取り操作：ethers.js を直接使用**: ```js const provider = new ethers.providers.JsonRpcProvider(config.rpcUrl); const contract = new ethers.Contract(address, abi, provider); const data = await contract.someReadFunction(); ``` ## NERO Wallet の AA機能を最大限に活用するには ### 1. ガス代のスポンサー機能 Paymaster がガス代をユーザーの代わりに支払う設定になっており、NEROトークンを持っていないユーザーでもトランザクションを実行できます。 ```js aa: { bundler: 'https://bundler-testnet.nerochain.io/', paymaster: 'https://paymaster-testnet.nerochain.io', paymasterAPIKey: 'YOUR_API_KEY_HERE', }, ``` ### 2. Social Login Web3Auth の統合により、秘密鍵を使わずにソーシャルログインが可能です。 ```js loginConfig: { google: { name: 'google', verifier: 'NeroTest-Google-Maintest', typeOfLogin: 'google', clientId: import.meta.env.VITE_GOOGLE_CLIENT_ID, }, // ...other login methods } ``` ### 3. Transaction Batching 今回の例では未実装ですが、NERO Walletは複数の操作を1つのトランザクションにまとめるバッチ処理もサポートしています。 ## NERO Wallet 開発におけるベストプラクティス 1.**書き込み操作にはUserOpを使う**：状態を変更する操作はUserOpを使用 2.**読み取り操作にはRPCを使う**：UserOpを使わず効率よく読み取り 3.**エラー処理を丁寧に**：わかりやすいエラーメッセージとフォールバック処理を用意 4.**モバイルUI最適化**：多くのユーザーがモバイルからアクセスします 5.**ユーザーデータの安全管理**：localStorageなどに機密情報を保存しない 6.**複数ネットワークでのテスト**：テストネットとメインネット両方で動作確認を行う ## 今後の拡張アイデア 1.**マルチ送金機能**：複数の宛先に一括送金 2.**NFTメタデータのIPFS保存**：より分散的な管理を実現 3.**複数NFTの同時ミント**：バッチミント機能 4.**WalletConnect対応**：ハードウェアウォレット接続のサポート 6.**トランザクション履歴**：ユーザーが過去の操作履歴を確認可能に 7.**トークンスワップ機能**：DEX機能の統合によるトークン交換 ## Conclusion NERO Walletの仕組みと実装の背景を理解することで、開発者はアカウント抽象化の機能を活かした強力なdAppを構築できます。この理解をもとに、次のセクションに進んで、各ステップの詳細を確認してみましょう。 --- # テンプレートからdAppへ：NEROウォレットテンプレートにNFT＆トークン機能を追加 Source: https://docs.nerochain.io/ja/tutorials/high-level/high-level-quickstart Section: クックブック このチュートリアルでは、NERO WalletテンプレートにNFTミント、トークン作成、NFTギャラリー機能を追加する方法を解説します。最後まで完了すると、以下のような結果になるはずです。 ![Application with a NERO Wallet](https://docs.nerochain.io/assets/cookbook/high-level.gif) *図1：NEROウォレットを使用したアプリケーション* ## 前提条件 1. `nero-aa-wallet` テンプレートを使用してプロジェクトを作成してください: ```js git clone https://github.com/nerochain/nero-aa-wallet ``` 2. [AA-PlatformのAPIキーを用意してください.](https://docs.nerochain.io/en/developer-tools/aa-platform/getting-started). > ****注意****: この例ではソーシャルログインも有効化できます。Web3Authのサイトにアクセスして、GoogleやFacebookなどのプロバイダでClientIdを発行してください。 ## ステップ1：プロジェクト構成の理解 まずは、プロジェクト構成を把握しましょう。 ```js ├── nerowallet.config.ts # Wallet configuration with chain and API details ├── src/ │ ├── App.tsx # Main application component │ ├── Sample.tsx # Sample implementation with a single button │ ├── index.tsx # Entry point for React │ ├── main.tsx # Main rendering │ ├── abis/ # Contract ABIs │ ├── components/ # UI components │ ├── hooks/ # React hooks │ └── constants/ # Constants like ABIs ``` ## ステップ2：HomePageコンポーネントを作成 1. `src/HomePage.tsx` という新しいファイルを作成します。 . NFTミント、トークン作成、NFTギャラリーの3つのタブで構成します。 2. 初期インポート文を追加します: ```js // Import ABIs // Define contract addresses const TOKEN_FACTORY_ADDRESS = '0x00ef47f5316A311870fe3F3431aA510C5c2c5a90'; const FREE_NFT_ADDRESS = '0x63f1f7c6a24294a874d7c8ea289e4624f84b48cb'; ``` ## ステップ3：NERONFTのABIを定義 mint関数を含むNERONFTのABIを追加します。: ```js // Define NERONFT ABI with the mint function const NERO_NFT_ABI = [ // Basic ERC721 functions from the standard ABI ...ERC721_ABI, // Add the mint function that exists in the NERONFT contract 'function mint(address to, string memory uri) returns (uint256)', 'function tokenURI(uint256 tokenId) view returns (string memory)', ]; ``` ## ステップ4：Reactの状態とフックを設定 ウォレットの状態管理とhooksを導入して機能を構築していきます。: ```js const HomePage = () => { const [activeTab, setActiveTab] = useState('mint-nft'); const { AAaddress, isConnected } = useSignature(); const { execute, waitForUserOpResult } = useSendUserOp(); const config = useConfig(); const [isLoading, setIsLoading] = useState(false); const [userOpHash, setUserOpHash] = useState(null); const [txStatus, setTxStatus] = useState(''); const [isPolling, setIsPolling] = useState(false); const [nfts, setNfts] = useState([]); // Form state const [tokenName, setTokenName] = useState(''); const [tokenSymbol, setTokenSymbol] = useState(''); const [tokenSupply, setTokenSupply] = useState('100000'); const [nftName, setNftName] = useState(''); const [nftDescription, setNftDescription] = useState(''); const [nftImageUrl, setNftImageUrl] = useState(''); ``` ## ステップ5：タブ切り替え機能の実装 アクティブなタブを切り替える関数を追加します: ```js // Handle tab change const handleTabChange = (tab) => { setActiveTab(tab); setTxStatus(''); setUserOpHash(null); // If switching to NFT gallery, fetch the NFTs if (tab === 'nft-gallery' && isConnected) { fetchNFTs(); } }; ``` ## ステップ6：トークンミント機能の実装 ERC20トークンを作成するための関数を追加します。 ```js // Mint ERC20 token const handleMintToken = async () => { if (!isConnected) { alert('Please connect your wallet first'); return; } setIsLoading(true); setUserOpHash(null); setTxStatus(''); try { // Call the createToken function on the token factory contract await execute({ function: 'createToken', contractAddress: TOKEN_FACTORY_ADDRESS, abi: CreateTokenFactory.abi, params: [tokenName, tokenSymbol, tokenSupply], value: 0, }); const result = await waitForUserOpResult(); setUserOpHash(result.userOpHash); setIsPolling(true); if (result.result === true) { setTxStatus('Success!'); setIsPolling(false); } else if (result.transactionHash) { setTxStatus('Transaction hash: ' + result.transactionHash); } } catch (error) { console.error('Error:', error); setTxStatus('An error occurred'); } finally { setIsLoading(false); } }; ``` ## ステップ7：NFTミント機能の実装 NFTをミントする機能を実装します。異なるコントラクトを呼び出す点に注意しましょう。 ```js // Mint NFT const handleMintNFT = async () => { if (!isConnected) { alert('Please connect your wallet first'); return; } if (!nftName || !nftImageUrl) { alert('Please provide a name and image URL for your NFT'); return; } setIsLoading(true); setUserOpHash(null); setTxStatus(''); try { // Create metadata JSON const metadataJson = JSON.stringify({ name: nftName, description: nftDescription, image: nftImageUrl, attributes: [] }); // For this demo, we'll just use the image URL directly await execute({ function: 'mint', contractAddress: FREE_NFT_ADDRESS, abi: NERO_NFT_ABI, params: [AAaddress, nftImageUrl], value: 0, }); const result = await waitForUserOpResult(); setUserOpHash(result.userOpHash); setIsPolling(true); if (result.result === true) { setTxStatus(`Success! NFT "${nftName}" minted!`); setIsPolling(false); // Reset form setNftName(''); setNftDescription(''); setNftImageUrl(''); // Refresh NFT gallery after successful mint fetchNFTs(); } else if (result.transactionHash) { setTxStatus('Transaction hash: ' + result.transactionHash); } } catch (error) { console.error('Error:', error); setTxStatus('An error occurred'); } finally { setIsLoading(false); } }; ``` ## ステップ8：Direct RPCによるNFTギャラリー機能 mintしたNFTを表示するために、RPCを使ってNFT情報を取得する機能を追加します。 ```js // Fetch NFTs for the gallery using direct RPC calls const fetchNFTs = async () => { if (!isConnected || !AAaddress) return; try { setIsLoading(true); setNfts([]); // Clear existing NFTs while loading // Create a provider using the RPC URL from config const provider = new ethers.providers.JsonRpcProvider(config.rpcUrl); // Create a contract instance for the NFT contract const nftContract = new ethers.Contract(FREE_NFT_ADDRESS, NERO_NFT_ABI, provider); // Get the balance of NFTs for the user const balance = await nftContract.balanceOf(AAaddress); const balanceNumber = parseInt(balance.toString()); if (balanceNumber > 0) { const fetchedNfts = []; // Fetch each NFT the user owns for (let i = 0; i < Math.min(balanceNumber, 10); i++) { try { // This is a simplified approach - in a real app, you'd need to get tokenIds owned by the address const tokenId = i; // Try to get the token URI const tokenURI = await nftContract.tokenURI(tokenId); // Add to our NFTs array fetchedNfts.push({ tokenId: tokenId.toString(), tokenURI: tokenURI, name: `NERO NFT #${tokenId}`, }); } catch (error) { console.error(`Error fetching NFT #${i}:`, error); } } if (fetchedNfts.length > 0) { setNfts(fetchedNfts); setTxStatus(`Found ${fetchedNfts.length} NFTs`); } else { // Fallback to sample NFTs setNfts([ { tokenId: '1', tokenURI: 'https://bafybeigxmkl4vto4zqs7yk6wkhpwjqwaay7jkhjzov6qe2667y4qw26tde.ipfs.nftstorage.link/', name: 'NERO Sample NFT #1', }, { tokenId: '2', tokenURI: 'https://bafybeic6ru2bkkridp2ewhhcmkbh563xtq3a7kl5g5k7obcwgxupx2yfxy.ipfs.nftstorage.link/', name: 'NERO Sample NFT #2', } ]); setTxStatus('Using sample NFTs for display'); } } else { setTxStatus('No NFTs found for this address'); } } catch (error) { console.error('Error fetching NFTs:', error); setTxStatus('Error fetching NFTs'); // Fallback to sample NFTs setNfts([/* Sample NFTs */]); } finally { setIsLoading(false); } }; ``` ## ステップ9：UIの基本構造を作成 タブ切り替えボタンとコンテンツ表示用のJSXを作成します。 ```js return (

NERO Chain dApp

{AAaddress && (

Connected Address: {AAaddress}

)} {/* Tabs */} {/* Tab Content */} {/* Add content for each tab here */} ); ``` ## ステップ10：各タブのUIとロジックの追加 ### NFTミントタブ：名前、説明、画像URLを入力してNFTをミントします。 ```js {activeTab === 'mint-nft' && (

Mint a New NFT

setNftName(e.target.value)} className="mt-1 block w-full rounded-md border-gray-300 shadow-sm focus:border-blue-500 focus:ring-blue-500" placeholder="My Awesome NFT" />