NEARアカウントモデル：名前、キー、ストレージ

• NEARプロトコルとは？
• TL;DR：NEARアカウントモデルの概要
• NEARアカウントモデルとは？
• 名前付きアカウントと暗黙的アカウント：NEARでのユーザー識別方法
• サブアカウント：NEARにおける階層的なアカウント構成
• NEARアクセスキー：フルアクセス権限と機能呼び出し権限
• ストレージステーキング：NEARアカウントに最低残高が必要な理由
• NEARアカウントモデルとEthereumの比較：並べて比較
• はじめに：NEARアカウントの作成と管理
• よくある質問：NEARアカウントモデル
• 結論：NEARアカウントモデルが開発者とユーザーにもたらすもの

NEAR Protocolとは？（概要）

NEAR Protocolは、開発者のアクセシビリティを重視して構築された、ステーキングする（プルーフ・オブ・ステーク）レイヤー1ブロックチェーンであり、安価で予測可能な取引手数料と、ユーザビリティを損なうことなく拡張できるように設計されたシャーディング・アーキテクチャを備えています。Illia Polosukhin氏とAlexander Skidanov氏によって共同設立されたNEAR Protocolは、他の目的のために構築されたアーキテクチャに後からユーザビリティを付け加えるのではなく、当初から開発者体験とエンドユーザーのアクセシビリティを主要な目標として設計されました。

NEARは、アカウントのステートと計算を並列処理チェーンに分散させるメカニズムである「Nightshade（ナイトシェイド）シャーディング」を通じてスケーリングを実現しています。これにより、ネットワークは手数料を比例的に増大させることなく、大量のトランザクションを処理することが可能になります。このプロトコルは、WebAssemblyにコンパイルされたスマートコントラクトをサポートしており、手数料の変動が開発者とユーザーの両方に摩擦を生じさせる他のブロックチェーンとは対照的に、設計段階からガス代を低く抑えています。エコシステムの発展は、非営利のガバナンス機関であるNEAR Foundation（NEAR財団）によって監督されています。同財団は以前、公式のNEARウォレットを運営していましたが、現在はコミュニティが維持管理する代替ツールへと移行しています。

この開発者ファーストの思想の最も明確な現れは、ブロックチェーンのIDと権限管理の仕組みをゼロから再考した設計であるNEARのアカウントモデルです。

TL;DR：一目でわかるNEARアカウントモデル

時間がない方向けのまとめ:

• NEARアカウントは、Ethereumの「0x742d35Cc...」のような暗号ハッシュ文字列ではなく、人間が読める名前（例：alice.near）を使用します。
• 各アカウントは、無制限の制御権から範囲を限定したスマートコントラクトとのインタラクションまで、それぞれ独自の権限レベルを持つ複数のアクセスキーを同時に保持できます。
• すべてのNEARアカウントでスマートコントラクトをデプロイできます。Ethereumのように独立したコントラクトアカウントの種類はありません。
• サブアカウントは階層的なネームスペース（例：myapp.near 配下の contract.myapp.near）に従い、ブロックチェーンアカウントのサブドメインのように機能します。
• アカウントは、オンチェーンストレージの使用量に比例した最小限のNEARトークン残高を維持する必要があります。これはストレージステーキングと呼ばれる仕組みです。
• NEAR独自のマルチキー権限システムは、Ethereumがアカウント抽象化（EIP-4337）で目指している目標の多くを達成していますが、これは当初から組み込まれた異なるアーキテクチャアプローチによるものです。

NEARアカウントモデルとは

NEARアカウントモデルは、NEARブロックチェーン上でのアカウントの命名方法、格納されるステート、詳細なキーパーミッションを通じたアクセス管理方法、そしてスマートコントラクトとの関係性を定義する、オンチェーンのIDおよびパーミッションアーキテクチャです。

ブロックチェーンの文脈において、「アカウントモデル」とは、プロトコルがオンチェーン上の参加者を表現するために使用するシステムのことを指します。これには、アカウントに含まれる内容、識別方法、トランザクションの承認方法、およびコードを実行できるかどうかが含まれます。Ethereumはある一つのアカウントモデルを採用していますが、Bitcoinは全く異なるパラダイム（残高をアカウント残高ではなく、未使用のトランザクションアウトプットとして追跡するUTXOモデル）を採用しています。NEARはアカウントベースのモデルを使用していますが、その実装はユーザビリティとアプリケーション開発の両面において重要な点でEthereumとは大きく異なります。

NEARアカウントは、5つの要素を同時に保持します。一意のアカウントID、NEARトークンの残高、アカウントステート（オンチェーンのデータストレージ）、WebAssembly（WASM）にコンパイルされたオプションのデプロイ済みスマートコントラクト（RustまたはJavaScriptで記述可能）、そして異なる権限レベルを持つ1つ以上のアクセスキーです。この統一された構造は、Ethereumのように「ユーザーアカウント」と「スマートコントラクトアカウント」の間に区別がないことを意味します。すべてのNEARアカウントは、別のカテゴリーのオブジェクトになることなく、オプションでスマートコントラクトをホストできます。コントラクトがデプロイされていないアカウントは通常のユーザーアカウントとして機能し、コントラクトがデプロイされているアカウントは、ユーザーアカウントであると同時にコントラクトホストでもあります。

これがなぜ重要なのかを理解するための実際的な文脈は、集権型サーバーではなくブロックチェーンネットワーク上で実行されるソフトウェアアプリケーションである分散型アプリケーション（dApp）です。NEARのアカウントアーキテクチャは、既存のブロックチェーンアカウントモデルでは実現できない、dAppとのやり取りをより安全かつアクセスしやすくするために設計されました。アカウントIDシステムは、この設計思想が最も直接的に見て取れる場所であり、アーキテクチャツアーはそこから始まります。

完全な技術仕様については、NEARプロトコルアカウントモデルのドキュメント docs.near.org/concepts/basics/accounts/model. を参照してください。

--- ## 名前付きアカウントと暗黙のアカウント：NEARがユーザーを識別する方法

NEARは、2つのアカウント形式を通じて、オンチェーンでユーザーとアプリケーションを識別します。それは名前付きアカウント（alice.nearのような人間が読める文字列を使用するもの）と、暗黙のアカウント（パブリックキーから派生した64文字の16進数文字列）です。

名前付きアカウント：人間が読めるブロックチェーンID

名前付きアカウントは、NEAR上の人間が読めるアカウント識別子で、ドメインのような構造に従います。メインネットでは.near、テストネットでは.testnetで終わります。これはEthereumのようなブロックチェーンで使用される暗号学的ハッシュ文字列の代わりとなります。

その違いは一目瞭然です。alice.near と 0x742d35Cc6634C0532925a3b844Bc454e4438f44e。どちらも有効なブロックチェーン識別子ですが、一方は読みやすく、もう一方は慎重なコピー＆ペーストによる確認を必要とします。NEARの名前付きアカウントは、メールアドレスのようなものだと考えてください。検証のために一文字ずつ比較する必要があるランダムな文字列ではなく、読みやすく、アイデンティティに紐付けられています。

名前付きアカウントには特定の命名規則があります。アカウントIDは英数字の文字列で、区切り文字としてドットを使用でき、2文字から64文字の間である必要があります。また、メインネットでは「.near」、テストネットワークでは「.testnet」で終わらなければなりません。ドットで区切られた構造により、ドメインのような階層が作成されます。「myapp.near」はトップレベルの名前付きアカウントであり、「contract.myapp.near」はその下のサブアカウントです（サブアカウントの詳細については、次のセクションで説明します）。

アカウント名を利用するUXの論理性は、単なる見た目以上のものです。読み取り可能な識別子によって、誤ったアカウントへトランザクションを送信するリスクが軽減され、コントラクトアドレスの発見が容易になり、オンチェーンのアイデンティティを管理する際の認知的負荷が下がります。トランザクションを送信する前にMetaMaskのアドレスを3回も確認したことがある人なら、42文字の16進数文字列よりも alice.near の方が抽象的ではなく具体的で魅力的であると感じるはずです。ユーザーは、主要なコミュニティ管理のアカウントインターフェースであるMyNEARWallet（mynearwallet.com）を通じてアカウント名の登録と管理を行います（NEAR Foundationが運営していた元のwallet.near.orgは廃止されました）。

インプリシットアカウント：代替のアカウント形式

**インプリシットアカウント（Implicit accounts）**は、NEARにおける2番目のアカウント形式です。パブリックキーから直接派生した64文字の小文字の16進文字列であり、既存のアカウントからのアクションを必要とせず、そのアカウントIDにNEARトークンが送信された瞬間に生成されます。

主要な実用上の違いは、名前付きアカウントはトランザクションを通じてその登録をスポンサーするために既存のオンチェーンアカウントを必要とするのに対し、暗黙的アカウントは誘導されたアカウントIDに資金が到着すると自動的に生成される点です。これにより、暗黙的アカウントは、ゼロからブートストラップする必要があるコンテキストや、人間が読める名前が不要なコンテキストで役立ちます。暗号資産取引所は通常、ユーザーにNEARデポジットをクレジットする際に暗黙的アカウントを使用し、既存のオンチェーンアカウントを必要とせずに、ユーザーのパブリックキーから一意のアカウントIDを生成します。

一つ明確にしておくべき点があります。インプリシットアカウントは匿名ではありません。これらはパブリックキーから決定論的に導出され、オンチェーン上で完全に透明です。「インプリシット（暗黙的）」という言葉は、アカウントIDがどのように導出されるか（明示的な登録ステップなしに、キー自体から導出されること）を指しており、プライバシーの特性を指すものではありません。

ネームドアカウントと暗黙的アカウント（implicit accounts）は、NEARがオンチェーンで参加者を識別する方法を規定します。アカウントは、自身の名前空間（namespace）の下に他のアカウントを含めることもでき、その階層構造においてサブアカウントが登場します。

NEARにおけるサブアカウント：階層的なアカウント構成

NEARのサブアカウントはウェブのサブドメインのように機能します。docs.myapp.comやapi.myapp.comがmyapp.comドメインの下にある異なるアドレスであるのと同様に、token.myapp.nearやstaking.myapp.nearはmyapp.nearというネームスペースの下にある個別のブロックチェーンアカウントです。

サブアカウントとは、親アカウントの名前空間（Namespace）の下にそのIDが存在するアカウントのことです。たとえば、contract.myprotocol.nearはmyprotocol.nearのサブアカウントにあたります。サブアカウントを作成できるのは親アカウントのみです。myprotocol.nearはcontract.myprotocol.nearを作成できますが、親アカウントの承認なしに他のアカウントがその名前空間の下にアカウントを作成することはできません。

重要： 親アカウントは、サブアカウントの作成後、そのサブアカウントの資金やステータスにアクセスすることはできません。サブアカウントは完全に独立したアカウントであり、名前空間のみを共有するもので、親アカウントによって管理される子会社のような関係ではありません。

この独立性は、よく誤解される点です。親子関係は、作成時にのみ適用されます。contract.myprotocol.near が存在すると、それは独自のアクセスキー、独自のNEARトークン残高、そして独自のオンチェーン状態を持つようになります。親アカウントである myprotocol.near は、それに対して特別な権限を持ちません。

dApp開発者にとって、サブアカウントは実用的なアーキテクチャパターンを提供します。すべてのNEARアカウントは（WASMにコンパイルされた）スマートコントラクトをデプロイできるため、サブアカウントは各コントラクトコンポーネントに読みやすく整理されたアカウントIDを付与する自然な方法となります。たとえば、あるDeFiプロトコルは、トークンコントラクト用にtoken.myprotocol.nearを、ステーキングコントラクト用にstaking.myprotocol.nearを、そしてガバナンスコントラクト用にgovernance.myprotocol.nearをデプロイするかもしれません。それぞれは独自のコントラクト、独自のステート、独自のキー管理を持つ個別のカウントですが、ネームスペースによって、チェーンを閲覧する誰もがコンポーネント間の関係性を即座に理解できるようになります。サブアカウント作成のステップバイステップの手順については、docs.near.org/concepts/basics/accounts/model#named-accountsにあるNEARサブアカウントドキュメント.)を参照してください。

アカウントの名前付けと構成を理解することは、次のアーキテクチャレイヤー、つまりアクセスキーを通じてアカウントを保護し権限を付与する方法の土台となります。

NEAR アクセスキー：フルアクセス対関数呼び出し権限

NEARアクセスキーは、NEARアカウントでどのアクションを実行できるかを制御する権限レイヤーであり、このシステムのアーキテクチャ上の最大の特徴でもあります。1つのNEARアカウントで、それぞれ独自の権限レベルを持つ複数の独立したキーペアを同時に保持することができます。

NEARのマルチキーシステムの仕組み

ほとんどのブロックチェーンアカウントでは1つのプライベートキーがすべてを制御しますが、NEARアカウントでは1つのアカウントで複数の独立したキーペアを保持でき、それぞれに無制限の制御から範囲が限定されたコントラクトの操作まで、特定の権限タイプが割り当てられています。

NEARのアクセスキーはデフォルトでEd25519キーペアを使用します（Ethereumツールチェーンとの互換性のためにsecp256k1もサポートされています）。これらのキーペアの上に構築されたパーミッションシステムこそが、NEARのモデルをアーキテクチャ面で際立たせている要素です。キーリングを想像してみてください。「フルアクセスキー（Full Access Key）」はすべての鍵を開けるマスターキーであり、「ファンクションコールアクセスキー（Function Call Access Key）」は特定のドア1つだけを開けるために作られた専用の鍵です。アカウント上のアクセスキーによって署名されたすべてのトランザクションは、NEARトークンで支払われるガスを消費しますが、歴史的にガス代が変動しやすいEthereumとは対照的に、NEARのトランザクション手数料は設計上、低額かつ予測可能になっています。

プログラムでアクセスキーを追加および管理する詳細については、docs.near.org/concepts/basics/accounts/access-keysにあるNEARアクセスキーの参照ドキュメントをご参照ください (https://docs.near.org/concepts/basics/accounts/access-keys).)

フルアクセスキー：無制限のアカウント制御

NEARにおける「Full Access Key（フルアクセス鍵）」とは、紐付けられたアカウントに対して、トークンの送金、スマートコントラクトのデプロイ、サブアカウントの作成、他の鍵の追加・削除、さらにはアカウント自体の削除など、あらゆるアクションを実行できる鍵ペアのことです。

フルアクセスキーはアカウント全体を制御するため、マスターパスワードと同様のリスクがあります。多額の資産を保管するアカウントでは、フルアクセスキーをサードパーティ製アプリケーションと絶対に共有してはいけません。また、コールドストレージ（ハードウェアウォレットまたはオフラインストレージ）に保管する必要があります。フルアクセスキーが侵害された場合、攻撃者は事前にリカバリメカニズムを設定していない限り、アカウントを完全に制御できるようになります。

ここではEthereumとの比較が参考になります。Ethereumでは、外部所有アカウント（EOA）の単一のプライベートキーがフルアクセスキーとして機能します。これはすべての操作を制御するもので、特定のコントラクト操作に対してdAppに低い権限のキーを付与するネイティブな手法は存在しません。MetaMaskを介したすべてのdApp接続は、トランザクション署名フローにおいてアカウントキー全体を露出させます。その単一キーの制限こそが、EthereumにおいてEIP-4337（アカウント抽象化）が解決するために設計された課題です。NEARでは、この解決策はベースのアカウントモデルに組み込まれています。

ファンクションコールアクセスキー：dAppセキュリティのためのスコープ限定権限

関数呼び出しアクセスキーは、1つの指定されたスマートコントラクト上の特定のメソッドのみを呼び出すことができる制限付きキーであり、総手数料の支出を制限するオプションのガス使用量上限を備えています。

フルアクセスキーが無制限であるのに対し、機能呼び出しアクセスキーは厳密に定義されています。このキーは、呼び出しが許可されている1つのコントラクトアカウントID、そのコントラクト上のどのメソッドを呼び出すことができるか（さらに制限されていない場合は全ての公開メソッド）、そして再補給が必要になる前にキーが消費できるガスの量を上限設定するオプションのNEARトークン割り当てを指定します。割り当てが使い尽くされると、トップアップされるか置き換えられるまで、そのキーはそれ以上のトランザクションに署名できません。

セッションベースの認証ユースケースは、dApp開発においてファンクションコールアクセスキーが実用的な価値を発揮する場面です。dAppをNEARアカウントに接続すると、そのdAppは自身のコントラクトにスコープを絞ったファンクションコールアクセスキーを要求します。このキーはブラウザセッションに保存されます。それ以降、dAppは個々の操作ごとに署名を求めることなく、ユーザーに代わってトランザクション（取引の承認、NFTのミント、ゲームコントラクトとのやり取りなど）を送信できるようになります。フルアクセスキーが安全なウォレットから外部に出ることはありません。もしdAppが侵害されたり悪意があったりした場合でも、被害は限定的です。攻撃者はキーのスコープ内にある特定のコントラクトメソッドしか呼び出すことができず、また、許容額（allowance）の範囲内でしか操作できません。ファンクションコールアクセスキーは、Webアプリケーションにおけるセッショントークンのように機能します。つまり、アカウントの全資格情報を公開することなく、特定のアクションに対して一時的かつ範囲を限定したアクセスを許可するものです。

アクセスキーは、アカウントが実行できるアクションを制御します。ストレージステーキングは、アカウントがオンチェーンに存在し続けるために保持する必要がある資産を規定します。

ストレージステーキング：NEARアカウントに最低残高が必要な理由

NEARのストレージステーキングとは、すべてのアカウントが、そのアカウントが使用するオンチェーンストレージ（ステート）の量に比例した最小限のNEARトークン残高を維持しなければならない仕組みのことです。

その仕組みは次のとおりです。NEARはオンチェーン・ストレージをバイト単位で割り当てます。アカウントに保存されるステート（残高記録、コントラクトコード、保存データ、アクセスキーなど）の1バイトごとに、対応する量のNEARトークンをアカウント残高に保持する必要があります。これらのトークンは消費されたり破棄されたりするのではなく、ストレージの占有面積に対するロックされた残高として予約されます。ステートやコントラクトデータを削除してアカウントのストレージを削減すると、対応するトークンのロックが解除され、利用可能残高に戻されます。ストレージステーキングは払い戻し可能な入金（保証金）のように機能します。アカウントが使用するストレージ量に比例したNEARトークンをロックし、ストレージの使用量を減らせば、それらのトークンを取り戻すことができます。

この設計の目的は経済的なものです。オンチェーンストレージを利用する当事者がそのストレージのコストを負担することを保証することで、ステートの肥大化を防ぎます。このようなメカニズムがなければ、ブロックチェーンネットワークは放棄されたアカウントやコントラクトからの無制限のデッドステートを蓄積し、すべての参加者のパフォーマンスを低下させる可能性があります。

具体的には、ストレージステーキングレートはオンチェーンストレージ10 KBにつき約1 NEARトークンです。また、新規に作成された空のNEARアカウントは、そのベースステートのフットプリントをカバーするために最低約0.00182 NEARの残高を必要とします。プロトコルのパラメータはアップグレードによって変更されるため、開発計画にこれらの数値を利用する前に、docs.near.org/concepts/storage/storage-stakingにあるNEARストレージステーキングのドキュメント)で現在の数値を確認してください。

スマートコントラクト開発者にとって、ストレージステーキングにおける影響は積極的な計画を必要とします。NEARアカウントがコントラクトをデプロイする際、コントラクトコード自体がアカウント状態におけるストレージを占有します。より大きなコントラクトバイナリは、比例してより大きなリザーブドバランスを必要とします。もしあなたのコントラクトが重要なデータ（ユーザー記録、トークン残高、ガバナンス投票）を保存する場合、そのコントラクトをホストするアカウントは、コントラクトコードと蓄積された状態の両方をカバーするのに十分な残高を維持しなければなりません。これはアプリケーションの使用量に応じてスケールする資本要件であり、デプロイ前に経済モデルで考慮する必要があります。

ストレージ・ステーキングは、実質的な資本のロックアップ要件を生み出します。一部の開発者は、リザーブされたストレージ残高を必要としないチェーンと比較して、これを制約であると感じています。このトレードオフは意図的なものです。この制約によってネットワークの状態が無制限に拡大するのを防ぎ、トークンは回収可能となっています。しかし、この制約は現実のものであり、デプロイ後に気づくのではなく、事前に計画を立てておくべきものです。

ストレージステーキング vs. バリデータステーキング: これらはNEARにおける2つの異なるメカニズムです。ストレージステーキングは、アカウントのオンチェーンデータフットプリントに対してNEARトークンをロックします。これらのトークンは、使用されるストレージ量に比例した予約残高として機能します。バリデータステーキングは、コンセンサスメカニズムに対してNEARトークンをロックするもので、バリデータがブロック生成に参加し、ステーキング報酬を得るためにトークンをステーキングします。本記事ではストレージステーキングのみを扱います。これら2つの「ステーキング」という言葉の使い方を混同しないようにしてください。

ガス手数料（トランザクション実行コスト）は、ストレージステーキングとは別個のものです。ガス手数料はトランザクションごとに消費され、署名時にNEARトークンで支払われます。ストレージステーキングは、関連するステート（状態）が存在する限り、アカウントに保持される予約済みの残高です。

ストレージステーキングを理解することで、NEARアカウントが単独でどのように機能するかの全体像が完成します。次の疑問は、このアーキテクチャがEthereumのものと比較してどうであるか、ということです。

NEARアカウントモデル vs. Ethereum：徹底比較

NEARとEthereumは、オンチェーンのアカウントアーキテクチャに対して根本的に異なるアプローチを採用しており、その違いは開発者が分散型アプリケーションを構築する方法や、ユーザーが自身のオンチェーンアイデンティティを管理する方法に重大な影響を及ぼします。

Ethereumの2つのアカウントシステム vs. NEARの統合アカウントモデル

以下の表は、8つのアーキテクチャ次元にわたって2つのアカウントモデルを対比しています。最も重要な違いは、Ethereumがユーザーアカウント（外部所有アカウント、またはEOA）とスマートコントラクトアカウントを2つの異なるタイプに分離しているのに対し、NEARは両方に対して単一の統合されたアカウントタイプを使用している点です。

EthereumのEOAとコントラクトアカウントの分離は、実運用において摩擦を生じさせています。ほとんどのdAppインタラクションでは、コントラクトアカウントを呼び出すためにEOAが必要となるため、ユーザーはこれら両方のタイプを別個のものとして管理しなければなりません。EOAは単一のプライベートキーによって制御されており、権限のスコープ（範囲指定）を行うネイティブな方法がありません。MetaMaskアカウントに接続されているどのdAppも、トランザクションフローに対してアカウントキー全体を公開するような署名を要求することができます。Ethereumのモデルは明確な設計思想を持ち、当初の目標をうまく達成しましたが、dAppインタラクションがより頻繁かつ多様になるにつれて、単一キーの制約が明らかになってきました。

NEARの統一アカウントタイプは、EOAとコントラクトの分離をなくします。すべてのNEARアカウントは潜在的なコントラクトホストとなり、関数呼び出しアクセスキーを備えたマルチキーシステムは、別個のプロトコルレイヤーを必要とせずに単一キーの制限に対処します。NEARとEthereumの両方は、残高がアカウント状態ではなく未使用トランザクション出力（UTXO）として追跡されるBitcoinのUTXOモデルとは対照的に、アカウントベースのパラダイムで動作します。NEARとEthereumの違いは、根本的なパラダイムではなく、それらのアカウントがどのように構造化され、権限が付与されているかにあります。

NEARのアカウントモデルとEthereumアカウント抽象化（EIP-4337）

EIP-4337 (アカウント抽象化) は、NEARのアカウントモデルが当初から備えるように設計されていたプログラマブルな権限やセッションキー機能を、EthereumのEOAに提供するための取り組みです。

EIP-4337は、理論的な提案ではなく、稼働中のイーサリアム標準です。これにより、スマートコントラクトウォレットは、プログラマブルなトランザクション検証、セッションキー、ソーシャルリカバリー、スポンサー付きトランザクションをサポートする、対等な存在として機能することができます。運用には特定のバンダーインフラストラクチャが必要ですが、イーサリアムエコシステム全体で積極的に展開されており、すべてのアカウントに自動的に適用されるユニバーサルなアップグレードではありません。

NEARのFunction Call Access Keysとの類似点は現実的です。どちらのアプローチも、アカウントキー全体を公開することなく、特定のインタラクションのためにdAppsにスコープされた限定的な権限アクセスを付与するという問題に対処しています。EIP-4337のセッションキーに慣れている開発者であれば、NEARのFunction Call Access Keysを概念的に親しみやすいと感じるでしょう。重要なニュアンスは、これらが重複するアイデアのアーキテクチャ的に異なる実装であり、同一のシステムではないということです。NEARのマルチキー権限モデルはベースプロトコルにネイティブですが、EIP-4337はEthereumの既存のEOAモデルの上にスマートコントラクトウォレットロジックをレイヤー化しています。彼らが対処する問題は大きく重複していますが、メカニズムは異なります。完全なEIP-4337仕様については、eips.ethereum.org/EIPS/eip-4337にあるEIP-4337アカウント抽象化仕様.) を参照してください。

NEARを検討しているイーサリアム開発者にとって、注目すべき2つのエコシステムブリッジがあります。NEAR上に構築されたEVM互換環境であるaurora.devのAuroraは、イーサリアム開発者がNEARのインフラ上でSolidityコントラクトをデプロイすることを可能にし、NEARアカウントが基盤となるアイデンティティレイヤーとして機能します。両方のエコシステムにわたって活動する開発者は、rainbowbridge.appのRainbow Bridgeを利用して、集権型カストディに依存することなく、NEARアカウントとイーサリアムアドレスの間で資産を転送できます。

アーキテクチャを理解したところで、NEARアカウントの作成と管理が実際にはどのようなプロセスになるのかを解説します。

はじめに：NEARアカウントの作成と管理

最初のNEARアカウントは、MyNEARWallet (mynearwallet.com) を通じて作成できます。これは、NEARアカウントの登録およびキー管理における、コミュニティによって管理されている主要なインターフェースです。NEARウォレットのエコシステムは進化し続けているため、この情報をご覧になっている時点での公式なウォレット推奨事項をご確認ください。MyNEARWallet以外にも、互換性のあるウォレットアプリケーションが存在します。

イーサリアムとMetaMaskから移行する場合、開始する前に概念的な違いを理解しておく価値があります。MetaMaskウォレットは、主にイーサリアムEOAのキーマネージャーおよびトランザクション署名者であり、プライベートキーを保持し、トランザクション署名のためにdAppsに提示します。NEARアカウントは、読みやすい名前、オンチェーンの状態ストレージ、プログラム可能なキー権限、およびオプションのコントラクトホスティングを備えた完全なオンチェーンIDです。ウォレットアプリケーション（MyNEARWallet）がインターフェースであり、NEARアカウントがオンチェーンオブジェクトです。これらは異なるものであり、キー管理についてどのように考えるかにおいて、その区別は重要です。

NEARアカウントの作成には、基本的なストレージステーキング要件を充当するために、少額の初期NEARトークン残高が必要です（空のアカウントの場合、約0.00182 NEAR。これは上記のストレージステーキングセクションで説明されています）。この初期残高は、新規アカウントの基本的なステートフットプリントを賄います。

開始する前に、知っておくべき3つのリスクがあります。第一に、リカバリメカニズムを設定せずにフルアクセス鍵（Full Access Key）を紛失した場合、そのアカウントを復旧することはできません。フルアクセス鍵はコールドストレージに保管し、必要になる前に、利用可能なあらゆるリカバリ・オプションを設定してください。第二に、ストレージステーキング用に予約されたNEARトークンは、関連するステートが存在する限りロックされます。これは手数料ではなく、資本拘束です。第三に、NEARでのアカウント削除は不可逆的です。ステップバイステップのアカウント作成ガイドの詳細は、docs.near.org/concepts/basics/accounts/modelにあるNEAR開発者ドキュメント. をご覧ください。

NEARアカウントモデルに関するよくある質問への回答を以下にまとめています。

よくある質問：NEARアカウントモデル

以下の質問は、NEARのアカウントモデルについて特によくある混乱点について回答しており、詳細な説明を必要とする読者のために上記の関連セクションへの相互参照を含めています。

NEARのアカウントであれば、誰でもスマートコントラクトをデプロイできますか？

はい。NEARでは、どのアカウントもオプションでWebAssembly (WASM) にコンパイルされたスマートコントラクトをデプロイできます。コントラクトをデプロイするために専用のコントラクト用アカウントを作成する必要があるEthereumとは異なり、個別のアカウントタイプは存在しません。コントラクトがデプロイされていないアカウントは標準のユーザーアカウントとして機能し、コントラクトがデプロイされているアカウントはその両方の機能を同時に果たします。アーキテクチャの全容については、上記のNEARのアカウントモデルとはのセクションを参照してください。

NEARのアクセスキーはどのようにdAppの安全な利用を可能にしますか？

関数呼び出しアクセスキーは、dAppを特定のコントラクトメソッドに制限し、オプションでガス制限キャップを設定できます。そのdAppのコントラクトに限定された関数呼び出しアクセスキーを使用してdAppに接続すると、あなたのフルアクセスキー（およびアカウント残高全体）がサードパーティアプリケーションに公開されることはありません。dAppが侵害された場合、損害は許可された範囲と指定されたコントラクトに限定されます。NEARアクセスキーセクションで詳細をご確認ください。

フルアクセスキーを紛失した場合はどうなりますか？

あらかじめ設定されたリカバリーメカニズムがない状態でフルアクセスキーを紛失すると、アカウントは永久に復旧できなくなります。アカウントを管理する中央機関が存在しないため、パスワードをリセットするようにフルアクセスキーをリセットしたり復旧したりすることはできません。フルアクセスキーは常に安全なコールドストレージに保管し、必要になる前にウォレットアプリケーションを通じて利用可能なアカウントリカバリーオプションを設定してください。一部のウォレットでは、ソーシャルリカバリーやマルチキーリカバリーの設定が提供されています。

ガス代はストレージステーキングと同じですか？

いいえ。ガス代は、トランザクションの署名時に消費されるトランザクションごとの実行コストです。これらはNEARトークンで支払われ、トランザクション完了後には残りません。ストレージステーキングは、関連するオンチェーンの状態が存在する限りアカウントに保持される最小の予約済みNEARトークン残高です。どちらもNEARトークンが関わりますが、完全に別個のメカニズムとして機能します。詳細については、ストレージステーキングのセクションで完全な説明を確認してください。

NEARのアカウントモデルは、イーサリアムのアカウント抽象化（EIP-4337）とどのように関連していますか？

NEARのネイティブなマルチキー権限システムは、dAppインタラクションのためのスコープ付きセッションベースの権限やプログラム可能なキーロジックを含め、EthereumにEIP-4337が追加しようとしている多くの目標を達成しています。これら2つは、重複するアイデアのアーキテクチャ的に異なる実装です。NEARのアプローチはベースプロトコルにネイティブですが、EIP-4337はEthereumの既存のEOAモデルの上にスマートコントラクトウォレットロジックをレイヤー化しています。これらは異なるアーキテクチャを通じて同様の問題を解決します。詳細な分析については、NEAR vs. Ethereum比較セクションを参照してください。

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

名前付きアカウントは、既存のアカウントからのトランザクションを通じて登録される人間が読める識別子（例：alice.near）であり、メインネットでは.near、テストネットでは.testnetで終わります。暗黙的アカウントは、パブリックキーから直接派生する64文字の16進数文字列であり、NEARトークンがそのアカウントIDに送信されたときに、登録トランザクションなしで自動的に生成されます。完全な比較表については、名前付きアカウントと暗黙的アカウントのセクションを参照してください。

1つのNEARアカウントはいくつアクセスキーを保持できますか？

NEARアカウントは、複数のアクセスキーを同時に保持することができます。各キーには独自の権限タイプ（フルアクセスキーまたは関数呼び出しアクセスキー）が割り当てられ、関数呼び出しアクセスキーの場合は独自のコントラクト範囲とガス許容量が設定されます。1アカウントあたりのキーの数に、文書化された明示的な制限はありません。このマルチキー機能こそが、EthereumのEOA（外部所有アカウント）ごとの単一キーというアプローチと、NEARの権限モデルを差別化している点です。詳細はNEARアクセスキーのセクションを参照してください。

ストレージステーキングをすると、NEARトークンを失うことになりますか？

いいえ。ストレージステーキングのために予約されたNEARトークンはロックされていますが、消費されていません。これらはアカウントに予約残高として保持され、状態を削除してアカウントのオンチェーンデータフットプリントを削減した場合、利用可能残高に返還されます。トークンはストレージ使用量に対する入金であり、手数料ではありません。ストレージステーキングセクションで、メカニズムと現在の数値を参照してください。

結論：NEARのアカウントモデルが開発者とユーザーにとって意味するもの

NEARのアカウントモデルは、意図的なアーキテクチャ上の選択を反映しています。人間が判読可能なアカウント名は、参入障壁を下げ、トランザクションエラーを減少させます。マルチキーによる権限システムは、マスターキーを公開することなくサードパーティのアクセス範囲を限定することで、dAppとのインタラクションにおけるセキュリティリスクを軽減します。ストレージステーキングは、リソースの使用量とコストの間に経済的な整合性を生み出します。そして、統一されたアカウント・コントラクト構造により、Ethereum開発における摩擦の原因となっていたEOAとコントラクトの分離が解消されています。

ストレージステーキングの最小残高要件は、単なる補足事項ではなく、計画に組み込むべき本質的な制約です。アプリケーションがオンチェーン上で大量の状態（ステート）を保存する場合、予約される残高の要件はその状態に応じて変動します。導入後ではなく、導入前にアプリケーションの経済モデルの一部として、その予算を確保しておきましょう。

ペルソナ別の次のステップ：

• 開発者: NEAR Protocolでの開発を開始 docs.near.org/develop
• ユーザー: NEARアカウントを MyNEARWallet at mynearwallet.com で作成
• リサーチャー: 完全なアカウントモデル仕様をさらに詳しく調べる NEAR Protocol account model documentation at docs.near.org/concepts/basics/accounts/model

本記事の技術仕様は、執筆時点のNEAR Protocolを反映しています。NEAR Protocolは活発に開発が進められており、開発または運用計画のために特定の数値に依存する前に、docs.near.orgで最新の数値を照合してください。本コンテンツは情報提供のみを目的としており、財務または投資のアドバイスを構成するものではありません。