NEARアカウントモデル解説：キーとストレージ

NEARアカウントモデルは、オンチェーンの状態とともにアカウントのアイデンティティと権限を管理するための、NEAR Protocolのプロトコルレベルのシステムです。NEAR上のすべてのアカウントは人間が読み取れるアカウントIDを持ち、異なる権限範囲を持つ複数のアクセスキーを保持でき、トークン残高とデプロイされたスマートコントラクトを同時に保持することが可能です。ブロックチェーンは異なるシステムを通じて価値とアイデンティティを管理しますが（Bitcoinは未使用トランザクションアウトプット、すなわちUTXOモデルを使用し、EthereumとNEARは各アカウントが直接状態を保持するアカウントベースのモデルを使用します）、NEARのアカウントベースの設計こそが、ここで説明するアーキテクチャを可能にしています。

NEARプロトコルは、2020年にメインネットをローンチしたプルーフ・オブ・ステーク（PoS）のレイヤー1ブロックチェーンです。NEAR SDKおよびコアプロトコルインフラストラクチャのメンテナンスを継続している開発者ツール組織であるNEAR Inc.（現在はPagodaとして運営）によって作成されました。NEARプロトコルは、ネットワークを並列シャードに分割するナイトシェードシャーディングを使用しており、アカウントIDはシャード割り当てにおいて役割を果たします。これは、クロスコントラクト呼び出しパターンを検討している開発者にとって重要です。

NEARアカウントモデルが他のレイヤー1アカウントシステムと異なる点は、以下の4つの特性にあります。

• アカウントIDは、ランダムな16進数シーケンスではなく、人間が読める文字列です
• 1つのアカウントは、それぞれ独自の権限スコープを持つ無制限の数のアクセスキーを保持できます
• どのアカウントも、トークン残高とデプロイされたスマートコントラクトの両方を保持でき、「ユーザーアカウント」と「コントラクトアカウント」の間にアーキテクチャ上の区別はありません
• アカウントは、オンチェーンストレージの使用量に比例したNEARトークン残高を維持する必要があり、これはストレージステーキングと呼ばれるメカニズムです

この記事では、アカウントIDの種類、アクセスキーの種類、ストレージステーキング、サブアカウント、Ethereumのアーキテクチャ比較、そして実践的な作業例といった各コンポーネントを順に解説します。

• NEARアカウントID：名前付きアカウントと暗黙的アカウント
• NEARアクセスキー：アカウント権限の仕組み
• ストレージステーキング：NEARはトークン残高をオンチェーンストレージにどのように結びつけているか
• NEARサブアカウント：階層型アカウント名前空間
• NEARアカウントモデル vs. イーサリアム：主要なアーキテクチャの違い
• NEARの統合アカウントアーキテクチャが実際には何を意味するか
• NEARアカウントモデルに関するよくある質問
• 主なポイントと次のステップ

NEARアカウントID：ネームドアカウントとインプリシットアカウント

すべてのNEARアカウントは、一意のアカウントIDによって識別されます。パブリックキーから派生した42文字の16進数アドレスでアカウントを識別するEthereumとは異なり、NEARのアカウントIDには、ネームドアカウント（Named Accounts）とインプリシットアカウント（Implicit Accounts）という構造的に異なる2つの形式があります。これらの違いを理解することは、NEARのアカウントシステムを扱う上での基礎となります。

ネームドアカウント：人間が読み取り可能な識別子

名前付きアカウントとは、メインネットでは.near、テストネットワークでは.testnetといったトップレベルドメインの下に登録される、人間が読めるアカウントIDのことです。名前付きアカウントは、インターネットのユーザー名やドメイン名のように機能します。ユニークで、登録者が選択でき、共有しやすく覚えやすいものです。例としては、alice.near、myprotocol.near、nft.myprotocol.nearなどがあります。ユーザー名とは異なり、名前付きアカウントは、NEARトークンの残高を保持し、スマートコントラクトをデプロイでき、暗号化されたアクセスキーを制御するプロトコルレベルのオブジェクトです。

名前付きアカウントの登録には、少額のNEARトークンの入金が必要です。作成するには、MyNEARWalletやMeteor WalletなどのNEAR互換ウォレットインターフェースにアクセスし、アカウントIDを選択して登録用の入金を行ってください。また、名前付きアカウントはそのネームスペース内にサブアカウントを作成することもできます（例：alice.nearはapp.alice.nearを作成可能）。このトピックの詳細については、以下のサブアカウントのセクションで説明しています。

名前付きアカウントは、NEAR Protocolのアカウントモデルに直接組み込まれたネイティブなプロトコル機能です。これらは、イーサリアムにおけるEthereum Name Service (ENS) のように、プロトコルの上に階層化された外部の命名サービスではありません。ENSは独立したスマートコントラクトシステムですが、NEARの名前付きアカウントはプロトコル自体の一級の構成要素です。

インプリシットアカウント：公開鍵から派生

暗黙的アカウント（Implicit account）は、Ed25519パブリックキーから決定論的に導出される64文字の16進数アカウントIDです。暗黙的アカウントIDの例は、98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0のようになります。Ethereumの経験がある開発者にとって、これは最も構造的に馴染みのあるアカウントタイプです。なぜなら、その導出プロセスが、パブリックキーからEthereumアドレスを算出する方法と類似しているためです。

暗黙的アカウントの作成メカニズムは、名前付きアカウントとは1つの重要な点で異なります。登録トランザクションは不要です。暗黙的アカウントは、誰かがそのアカウントIDにNEARトークンを送信した瞬間にアクティブになります。これにより、暗黙的アカウントはプログラムによるアカウント作成、取引所の入金アドレス、および人間による可読性が優先されないシナリオに適しています。

「暗黙的（implicit）」という記述子は、匿名性ではなく、作成メカニズムを指します。暗黙的アカウントは、アカウントIDの派生元となったプライベートキーの所有者によって完全に所有および制御されます。さらなる区別として、暗黙的アカウントIDはパブリックキーから派生しますが、パブリックキーそのものと同一ではありません。アカウントIDは、生のパブリックキー・バイトを小文字の16進数で表現したものです。アドレスの派生に詳しいEthereum開発者であればそのパターンを認識できるでしょうが、2つの表現が同じであると想定すべきではありません。

名前付きアカウント vs. 暗黙的アカウント：並列比較

2種類のアカウントIDは5つの側面で異なります。

Named account（名前付きアカウント）は、読みやすさが重視されるユーザーウォレットやプロトコルのデプロイに適しています。一方、Implicit account（暗黙的アカウント）は、取引所やプログラムによるツール、およびユーザーの操作なしにアカウントを大量作成するようなシナリオに適しています。

NEAR アクセスキー：アカウント権限の仕組み

NEARアクセスキーは、アカウントモデルの認可レイヤーです。各NEARアカウントは複数のアクセスキーを同時に保持でき、各キーはそれぞれ異なる権限スコープを持ちます。NEARアカウントは一度に無制限の数のアクセスキーを保持できます。各キーは独立したEd25519暗号化キーペアであり、新しいアカウントを作成することなくキーの追加または削除が可能です。キーは、既存のフルアクセスキーで署名されたトランザクションを通じて、NEAR CLI（near add-key）を使用するか、SDKを介してプログラム的に追加されます。

これは、1つのプライベートキーが各アドレスを制御するEthereumとは異なります。NEARのマルチキー設計により、アカウントの継続性を損なうことなく、よりきめ細かな権限管理が可能になります。NEARは、フルアクセスキー（Full Access Keys）と関数呼び出しアクセスキー（Function Call Access Keys）の2種類のキータイプをサポートしています。技術仕様の詳細については、アクセスキーに関するNEARプロトコルのドキュメント)を参照してください。

フルアクセスキー：マスタークレデンシャル

フルアクセスキーとは、アカウントに対して無制限の権限を持つアクセスキーです。トークン送金、スマートコントラクトのデプロイ、他のキーの追加または削除、アカウントの削除を承認できます。フルアクセスキーは、あらゆるドアを開けることができるご自宅のマスターキーのようなものだと考えてください。家の鍵とは異なり、フルアクセスキーはNEARブロックチェーン上で取引に署名する暗号鍵ペアであるため、同様のセキュリティ対策が適用されます。Ethereumユーザーがシードフレーズを保護するのと同じ理由で、ハードウェアウォレットやオフラインで保管してください。

NEARアカウントは複数のフルアクセスキーを持つことができます。デバイスごとに1つのキーを持つことが一般的なパターンであり、各キーは同じフル権限レベルを保持します。これは重要なアーキテクチャ上のポイントです。つまり、Ethereumアカウントのような単一の「マスタープライベートキー」は存在しません。複数のフルアクセスキーは、1つのアカウント上に同時に共存させることが可能です。

開発者ノート: 関数呼び出しアクセスキーが侵害されても、フルアクセスキーの権限が付与されることはありません。権限スコープは、プロトコルレベルでアーキテクチャ上分離されています。同じアカウントのフルアクセスキーは、関数呼び出しアクセスキーを失効させても影響を受けず、その逆も同様です。

関数呼び出しアクセスキー：dAppsのためのスコープ付き権限

Function Call Access Key（関数呼び出しアクセスキー）は、特定のコントラクトにおける特定のメソッドのみを呼び出すことができる、スコープが限定されたアクセスキーです。これには、そのキーが消費できるガス量の上限を定めるオプションのNEARトークン許容量（allowance）が含まれます。これはセッショントークンやスコープ指定されたOAuthの権限のようなものと考えてください。これにより、特定のアカウントへの全アクセス権を与えることなく、特定のアプリケーションに対して、あなたに代わって特定のアクションを実行する権利を付与します。OAuthトークンとは異なり、Function Call Access Keyはオンチェーンに保存される暗号化キーペアであり、その権限範囲はアプリケーションではなくプロトコルレベルで強制されます。

NEARアカウントを分散型アプリケーション（dApp）に接続してFunction Call Access Keyを承認すると、dAppは個別にウォレットの確認ポップアップを表示させることなく、特定のトランザクションを自動的に送信できるようになります。これにより、ゲーム、DeFiプロトコル、ソーシャルアプリケーションにおいて、セッションベースのUXが可能になります。Ethereumでは、それらのインタラクションごとに個別のMetaMaskによる確認が必要になりますが、NEARではユーザーが一度キーを承認すれば、dAppはそのセッションの範囲内で動作します。

Function Call アクセスキーは、キーが消費することを許可されている総ガス量を制限する、オプションのNEARトークンによるガス上限を保持できます。この上限に達すると、ユーザーがそれを補充するか新しいキーを発行するまで、そのキーはトランザクションを送信できなくなります。

よくある誤解：dAppにFunction Call Access Keyを付与しても、そのdAppにあなたのアカウントの制御権を与えるものではありません。このキーは、定義されたコントラクトメソッドとガス制限に厳密にスコープされています。NEARトークンの残高を移転したり、コントラクトをデプロイしたり、あなたのアカウント上で他のキーを追加・削除したりすることはできません。

開発者ノート: Function Call Access Keys（関数呼び出しアクセス鍵）は、dAppにおけるセッションキーのパターンを可能にします。ユーザーはゲームセッションやDeFi取引セッション用に鍵を承認することができ、アプリケーションはトランザクションごとの承認を必要とせずに、その範囲内で動作します。これは、NEAR上での構築とEthereum上での構築における、開発者にとって最も重要なUX（ユーザーエクスペリエンス）の違いの一つです。

フルアクセス鍵 vs. 関数呼び出しアクセス鍵：主な違い

フルアクセスキーとファンクションコールアクセスキーは、6つの観点で異なります。

フルアクセスキー（Full Access Keys）はアカウント所有者に属し、オフラインまたはハードウェア内に保管されるべきものです。ファンクションコールアクセスキー（Function Call Access Keys）はアプリケーションに対して発行され、アカウント所有者によっていつでも取り消すことができます。

ストレージステーキング：NEARがトークン残高をオンチェーンストレージに紐付ける仕組み

ストレージステーキングはNEARのアカウント・アーキテクチャの構成要素の一つであり、ほとんどのブロックチェーン教育リソースでは省略されています。しかし、これはNEARで開発を行うすべての開発者、およびアカウントを管理するすべてのユーザーにとって直接的な実務上の意味を持っています。

なぜNEARではストレージにトークン残高が必要なのか

**定義：**ストレージステーキング（NEARの一部のドキュメントではステートステーキングとも呼ばれます）とは、NEARアカウントがオンチェーンで保存するデータ量に比例して、一定のNEARトークン残高を維持しなければならない要件のことです。このロックされた残高は、手数料ではなく、返金可能な入金として機能します。

ストレージステーキングはアパートの敷金のように機能します。NEARトークンは使用しているストレージ量に比例してロックされ、その保存データを削除した際にお手元に戻ります。家賃の支払いとは異なり、トークンが誰かに転送されることはありません。これらはあなたのパスワードを保持するアカウントに残り、利用しているストレージ分として確保されるだけです。

1つ明確にしておくべき違いがあります：ストレージステーキングはバリデーターステーキングと同じではありません。どちらのメカニズムもNEARトークンをロックしますが、目的は全く異なります。バリデーターステーキングは、ブロック生成に参加し、コンセンサス報酬を得るためにトークンをロックします。ストレージステーキングは、オンチェーンストレージの使用量に比例してトークンをロックし、ステートの肥大化を防ぎ、ストレージのコストをそれを消費するエンティティに合わせます。これらは別々の目的を持つ、別々のロックされた残高です。

ストレージステーキングはガス代とは別に扱われます。ガス代は、トランザクションごとに発生する実行コストであり、NEARトークンで支払われ、各トランザクション後にバーン（焼却）されます。ストレージステーキングは、アカウントが保持するデータ量に関連する継続的な残高要件であり、送信するトランザクション数には関係ありません。

ストレージステーキングの実践：アカウントとコントラクトにとっての意味

ストレージステーキングは、3つのレベルでアカウントに影響を与えます：

• アカウント作成: 最低限のNEARトークン残高が必要です。現在のレートは、ステート1バイトあたり約0.00182 NEARです（プロトコルのガバナンスによりこの数値は調整される可能性があるため、開発上の決定を行う前に、公式NEARストレージステーキングドキュメント)で現在のレートを確認してください）。
• コントラクトデプロイ: コンパイルされたコントラクトサイズに応じて、比例してより大きな入金が必要です。コントラクトのWASMバイトコードは、アカウントのステートの一部としてオンチェーンに保存され、ストレージ入金はそのサイズに合わせて調整されます。
• コントラクトステートデータ: コントラクトステートに保存されるデータ（トークンコントラクトのユーザー残高やオンチェーンゲームのゲームステートなど）は、コントラクトアカウントを制御する誰かによって維持される継続的な残高が必要です。

NEARアカウントの残高がストレージ要件を下回った場合、残高が補充されるまで、そのアカウントは送信トランザクションを実行できなくなります。アカウントが削除されたり、データが失われたりすることはありません。十分なNEARトークンが預け入れられるまで、送信トランザクションに関して一時的に非アクティブな状態になるだけです。

開発者向け注記：アプリケーションがオンボーディング時にユーザーのストレージデポジットを立て替えるのか、それともユーザー自身に自身の残高を維持させるのかを早期に決定してください。多くのプロトコルでは、導入の障壁を下げるためにストレージコストを吸収しています。これはユーザー獲得に影響する実際のオンボーディング経済決定ですので、ローンチ前にdAppのコストモデルに組み込んでください。

NEARサブアカウント：階層化されたアカウント名前空間

NEARのサブアカウントとは、親アカウントのIDを接頭辞（プレフィックス）として持つアカウントのことです。例えば、app.alice.nearはalice.nearのサブアカウントであり、alice.nearのみがそのネームスペース内にアカウントを作成できます。

正確を期すために、1つ重要な詳細があります。サブアカウントが作成された後、親アカウントがそれを制御することはありません。サブアカウントは完全に独立しており、独自のアクセスキー、独自のNEARトークン残高、そして独自のオンチェーン状態を持ちます。親アカウントに与えられている唯一の特別な権限は、その名前空間でサブアカウントを作成できることです。その作成行為を超えて、両アカウント間に継続的な管理関係はありません。

名前の階層構造は、ウェブのドメインやサブドメインに似ています。alice.nearはドメインのようなもので、app.alice.nearはサブドメインのようなものです。ドメインを登録しても、そのサブドメインでホストされているコンテンツを継続的に制御できるわけではないのと同様に、サブアカウントを作成しても、親アカウントがその後のサブアカウントの使用方法に対する権限を持つわけではありません。

プロトコルチームの一般的な利用パターンは、以下のようになります。

myprotocol.near → token.myprotocol.near → staking.myprotocol.near → dao.myprotocol.near

各サブアカウントは、作成後に独立して制御されます。それぞれ独自のアクセスキーを持ち、独自の残高を保有し、別個のスマートコントラクトをデプロイできます。作成は、NEAR CLI経由またはプログラムからコントラクトコール経由で、親アカウントによって開始されます。そのトランザクション後、制御は完全に新規サブアカウントのアクセスキーを保持する者に移ります。

よくある誤解：親アカウントは、作成後にサブアカウントを管理することはありません。サブアカウントは、プロトコルレベルで完全に自律したアカウントです。命名規則は、管理主体ではなく、作成者を反映しています。

開発者ノート: サブアカウントは、モジュール型プロトコルアーキテクチャにおける標準的なパターンです。個別のコントラクトを個別のサブアカウントにデプロイすることで、各モジュールに独立したアクセスキー管理、独立したアップグレードパス、そしてより明確な権限分離が可能になります。多くの本番環境のNEARプロトコルでは、トークンコントラクト、ガバナンスモジュール、ステーキングロジックにこのパターンを採用しています。

NEARのアカウントモデル vs. Ethereum：主要なアーキテクチャの違い

NEARのアカウントモデルとEthereumのアカウントモデルは、アカウントの識別、トランザクションの承認、スマートコントラクトのデプロイという同じ課題に対して、異なるアーキテクチャ上のアプローチを採用しています。NEARを構築プラットフォームとして検討している開発者にとって、これらの違いを理解することは、情報に基づいたアーキテクチャの決定を下すための前提条件となります。

Ethereumはアカウントを、外部所有アカウント（EOA）とコントラクトアカウントの2つのタイプに分類しています。EOAは単一のプライベートキーによって制御され、デプロイされたコードを保持することはできません。コントラクトアカウントはコードによって制御され、プライベートキーを持ちません。この分離により、EthereumアドレスでETHの保持とスマートコントラクトのロジックの実行の両方を行いたい場合、連携して動作する2つの別々のアカウントオブジェクトが必要になります。

NEARは統合モデルを採用しています。どのNEARアカウントも、トークン残高の保持とスマートコントラクトのデプロイを同時に行うことができます。独立した「コントラクトアカウント」というタイプは存在しません。alice.nearというアカウントは、NEARトークンの保持、デプロイされたWASMコントラクトの実行、異なる権限スコープを持つ複数のアクセスキーの管理を、すべて単一のプロトコルオブジェクトとして行うことができます。どのNEARアカウントも、スマートコントラクト、トークン残高、および複数のアクセスキーを同時に保持できます。

Ethereumのアカウントは、それぞれ1つのプライベートキーによって制御されています。一方、NEARのアカウントは、異なる権限スコープを持つ複数のアクセスキーをサポートしており、Ethereumのアカウントモデルがプロトコルレベルでネイティブにサポートしていないセッションキーやマルチデバイスのキー管理といったパターンを可能にします。

注記：Ethereum互換のスマートコントラクトは、NEAR上にスマートコントラクトとしてデプロイされたEVM互換レイヤーであるAuroraを介してNEAR上で実行できます。Auroraは別のレイヤーであり、ネイティブなNEAR開発ではSolidityではなく、RustまたはJavaScriptからコンパイルされたWebAssembly（WASM）を使用します。完全なEthereumアカウント仕様については、Ethereumアカウントモデルのドキュメント)を参照してください。

NEARの統合アカウントアーキテクチャが実用面で何を意味するのか

NEARアカウントモデルの構成要素（アカウントID、アクセスキー、ストレージステーキング、およびサブアカウント）は、統合されたシステムを形成しており、アプリケーションの挙動やユーザーエクスペリエンスに具体的な違いをもたらします。

単一のNEARアカウント alice.near を考えてみましょう。アリスのアカウントは、以下のことを同時に行うことができます。

1. NEARトークンの残高を保有している
2. RustからWebAssembly (WASM) にコンパイルされたスマートコントラクトがデプロイされている
3. 3つのアクセスキーを保持している：ハードウェアウォレットに保存されたフルアクセスキー、ラップトップにあるフルアクセスキー、そしてセッションベースの取引のために DeFi dAppに付与された関数呼び出しアクセスキー
4. 2つのサブアカウント（デプロイされたゲームコントラクト用の「app.alice.near」と、ステーキングコントラクト用の「vault.alice.near」）を所有しており、それぞれが独立して制御されている

アリスのアカウントIDは読みやすく、共有も簡単です。彼女はトークンを受け取ったり、コントラクトを操作したりするために、42文字の16進数文字列をコピーすることはありません。

開発者にとって、実用上の意味合いは大きいです。セッションキーパターンにより、ゲームやソーシャルアプリでのトランザクションごとのウォレットの利用における摩擦が解消されます。サブアカウントアーキテクチャにより、プロトコルチームは独立したアップグレードパスを持つモジュール型コントラクトを展開できます。ストレージステーキングは、オンチェーンデータのための予測可能なコストモデルを作成し、オンボーディングのエコノミクスに組み込む必要があります。アカウントは、Rainbow Bridgeと連携してNEARとEthereum間で資産を転送することもでき、MyNEARWalletやMeteor WalletのようなNEAR互換ウォレットインターフェースを通じて管理されます。

エンドユーザーにとって、アカウントモデルは、ユーザー名のように機能する読みやすいアカウントID、ウォレットのポップアップで体験が中断されないdAppセッション、そして単一のシードフレーズに依存せずにアカウントリカバリを可能にするキーローテーションモデルへと変換されます。

NEARアカウントモデルに関するよくある質問

NEARにおける名前付きアカウントと暗黙的アカウントの違いは何ですか？

名前付きアカウントは、トップレベルドメインの下に登録される人間が読み取り可能な識別子（alice.nearなど）であり、登録時に少額のNEARトークンの入金が必要で、ユーザー自身が選択します。インプリシットアカウントは、Ed25519のパブリックキーから派生した64文字の16進数IDであり、登録は不要で、NEARトークンがそのアカウントIDに送金されると自動的に有効化されます。名前付きアカウントは、ユーザーのウォレットやプロトコルのデプロイで一般的であり、インプリシットアカウントは取引所やプログラムによるツールで一般的です。詳細な比較については、上記の名前付きアカウントとインプリシットアカウントの比較表をご覧ください。

NEARアカウントは最大でいくつのアクセスキーを持つことができますか？

NEARアカウントは、無制限の数のアクセスキーを同時に保持できます。各キーは独自の権限スコープを持ちます。それは、無制限の権限を持つフルアクセスキーか、特定のコントラクトメソッドにスコープされた関数呼び出しアクセスキーのいずれかです。これにより、ユーザーは新しいアカウントを作成することなく、異なるデバイスやdApp用に別々のキーを管理できます。個々のキーはいつでも追加または取り消し可能であり、他のキーには影響しません。各キータイプに関する詳細は、アクセスキーのセクションを参照してください。

NEARプロトコルにおけるストレージステーキングとは何ですか？

ストレージステーキングとは、NEARアカウントが、保存するオンチェーンデータの量に比例したNEARトークン残高を維持する必要があることです。トークンは消費されるのではなく入金としてロックされ、保存されたデータが削除された場合には解放されます。このメカニズムは、ネットワーク上のステートの肥大化を防ぎ、ストレージの利用者が占有するリソースのコストを負担することを保証します。ストレージステーキングは、ガス手数料（トランザクションごとにバーンされる）や、バリデーターステーキング（ネットワークコンセンサスを保護する）とは別です。完全な説明については、ストレージステーキングセクションを参照してください。

NEARアカウントはスマートコントラクトを保持できますか？

はい。どのNEARアカウントにもスマートコントラクトをデプロイすることが可能です。外部所有アカウント（コードを保持できないユーザーアカウント）と、プライベートキーを持たないコントラクトアカウント（コードを保持するアカウント）を区別するEthereumとは異なり、NEARは、どのアカウントもNEARトークンの残高保持とコントラクトコードのデプロイを同時に行える統合アカウントモデルを採用しています。NEARのコントラクトは、Solidityではなく、RustまたはJavaScriptのソースコードからWebAssembly (WASM) にコンパイルされます。アーキテクチャの完全な詳細については、Ethereumとの比較セクションを参照してください。

NEARアカウントの残高がストレージ要件を下回るとどうなりますか？

NEARアカウントの残高がストレージ使用量に必要な最小額を下回った場合、残高が補充されるまでそのアカウントは送信トランザクションを実行できなくなります。アカウントが削除されたりデータが失われたりすることはありません。十分なNEARトークンが預け入れられるまで、送信トランザクションに対して非アクティブになるだけです。保存されたデータはオンチェーン上でそのまま維持されます。残高要件の詳細については、ストレージステーキングの実際セクションを参照してください。

NEARのサブアカウントとは何ですか？また、誰がそれを管理しますか？

NEARのサブアカウントとは、親アカウントのIDがプレフィックス（接頭辞）として付くアカウントのことです。例えば、app.alice.nearはalice.nearのサブアカウントであり、alice.nearだけがその名前空間にアカウントを作成できます。作成後、親アカウントがサブアカウントを制御することはありません。サブアカウントは、独自のアクセスキー、独自のNEARトークン残高、および独自のオンチェーンステートを持つ、完全に独立したアカウントです。親の命名権限は、作成行為のみに限定されます。詳細については、サブアカウントのセクションをご覧ください。

アカウントに関して、NEAR ProtocolはEthereumとどのように違うのですか？

アーキテクチャ上の主な違いは、アカウント構造にあります。Ethereumには、2つの異なるアカウントタイプがあります。外部所有アカウント（単一のプライベートキーによって制御され、コードを持たない）とコントラクトアカウント（コードによって制御され、プライベートキーを持たない）です。一方、NEARは統合されたアカウントモデルを採用しており、どのアカウントもトークン残高の保持と、デプロイされたスマートコントラクトの実行を同時に行うことができます。また、NEARのアカウントは異なる権限範囲を持つ複数のアクセスキーをサポートしていますが、Ethereumのアカウントはそれぞれ単一のプライベートキーによって制御されます。さらに、NEARのアカウントIDは人間が読める形式の名前付きアカウントにできますが、Ethereumのアドレスは常に16進数の文字列です。詳細な比較については、比較表全文で項目ごとの内訳を確認してください。

NEARにおけるフルアクセスキーと関数呼び出しアクセスキーの違いは何ですか？

フルアクセスキー（Full Access Key）は、アカウントに対して無制限の権限を持ちます。トークンの転送、コントラクトのデプロイ、他のキーの追加や削除を承認することができます。フルアクセスキーは、アカウント所有者の最高機密の認証情報であり、ハードウェアウォレットやオフラインで保管する必要があります。一方、ファンクションコールアクセスキー（Function Call Access Key）は、特定のコントラクト上の特定のメソッドを呼び出すことに限定されており、ガス代としてオプションのNEARトークン許容量を設定できます。このキーでは、トークン残高を転送したり、他のキーを変更したりすることはできません。フルアクセスキーはアカウント所有者用であり、ファンクションコールアクセスキーは、アカウントへのフルアクセスを必要とせずにセッションのようなやり取りを可能にするため、dAppに対して発行されます。詳細な内訳については、キーの比較表を参照してください。

NEARのアカウントIDはどのような形式ですか？

NEARのアカウントIDには2つの形式があります。名前付きアカウントは、alice.near、myprotocol.near、app.alice.nearのように、読みやすいユーザー名やドメイン名のようになっています。インプリシット（暗黙的）アカウントは、パブリックキーから派生した64文字の16進文字列で、イーサリアムのアドレスと視覚的な形式は似ていますが、より長くなっています（例：98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0）。名前付きアカウントは、メインネットでは.nearサフィックスを使用し、テストネットワークでは.testnetを使用します。詳細な内訳と比較表については、アカウントIDセクションを参照してください。

NEAR Protocolはプルーフ・オブ・ステークですか？

NEAR Protocolはプルーフ・オブ・ステーク（PoS）コンセンサスメカニズムを使用しています。バリデーターは、ブロック生成に参加し、プロトコル報酬を獲得するためにNEARトークンをステーキングします。バリデーターアカウントは、ステーキングコントラクトがデプロイされた標準的なNEARアカウントであり、これにより統合アカウントモデルが実践されていることが示されています。バリデーターステーキングは、ストレージステーキングとは別のメカニズムです。どちらもNEARトークンをロックしますが、目的は全く異なります。

主要なポイントと今後のステップ

NEARのアカウントモデルは、アカウントのアイデンティティ、権限、およびオンチェーンのストレージ管理を単一のアーキテクチャに統合します。ユーザーアカウントとコントラクトアカウントを分離したり、各アカウントを単一のプライベートキーに制限したりするのではなく、NEARは柔軟性とスコープ指定された権限をアカウントレイヤーに直接組み込んでいます。

主な要点:

• NEARアカウントIDは、16進数アドレスではなく、人間が読める形式の名前付きアカウント（例：alice.near）またはパブリックキーから派生した64文字の暗黙的アカウントです。
• 名前付きアカウントは登録時にNEARトークンの入金が必要ですが、暗黙的アカウントは最初のトークン受け取り時に自動的に有効化されます。
• すべてのNEARアカウントは複数のアクセスキーを同時に保持でき、それぞれに異なる権限スコープが設定されています。
• フルアクセスキーはすべてのアカウント操作を承認し、アカウント所有者に帰属します。関数呼び出しアクセスキーは、特定のコントラクトメソッドに限定され、アプリケーションに対して発行されます。
• どのようなNEARアカウントでも、NEARトークンの残高保持とスマートコントラクトのデプロイの両方が可能です。独立したコントラクトアカウント型というものは存在しません。
• ストレージステーキングでは、オンチェーンのストレージ消費量に比例したNEARトークン残高のロックが必要です。これはガス代やバリデータステーキングとは異なり、手数料ではなく返金可能な入金です。
• サブアカウントは階層的な命名規則に従いますが、作成後に親アカウントがサブアカウントを制御することはありません。各サブアカウントは完全に自律しています。

NEARで開発を始める開発者は、技術仕様とSDKリファレンスが記載されているNEAR Protocolアカウントモデルのドキュメント,)から始めることができます。ストレージステーキングの詳細と現在のレートパラメータについては、プロトコルのパラメータはガバナンスを通じて変更される可能性があるため、アーキテクチャの決定を行う前に公式NEARストレージステーキングドキュメント)を参照してください。初めてNEARアカウントを作成するユーザーは、MyNEARWalletやMeteor WalletのようなNEAR互換ウォレットインターフェースを通じて行うことができます。

技術的な正確性に関する注意事項: NEAR Protocolは、活発に進化しているブロックチェーンです。ストレージステーキングのレートやアカウント作成の要件を含む技術仕様は、プロトコルのアップデートに伴い変更される可能性があります。開発に関する決定を行う前に、NEAR Protocolの公式ドキュメントで最新の仕様を確認してください。