コンテンツにスキップ

アカウント

Aptosブロックチェーン上のアカウントは、オンチェーン通貨やNFTを含む一連の資産へのアクセス制御を表します。Aptosでは、これらの資産はアクセス制御と希少性の両方を重視するリソースとして知られるMoveプログラミング言語のプリミティブによって表現されます。

Aptosブロックチェーン上の各アカウントは、32バイトのアカウントアドレスによって識別されます。主要なアカウントを記憶しやすく一意にするために、www.aptosnames.comでAptos Name Serviceを使用して.aptドメインを取得できます。

アカウントとアドレスが暗黙的である他のブロックチェーンとは異なり、Aptos上のアカウントは明示的であり、トランザクションを実行する前に作成される必要があります。アカウントは明示的に作成するか、Aptosトークン(APT)をそこに転送することで暗黙的に作成できます。詳細については、アカウントの作成セクションを参照してください。これは、アドレスがトランザクションを送信する前にガス用の資金を送る必要がある他のチェーンと似ています。

明示的なアカウントにより、他のネットワークでは利用できない一流の機能が可能になります:

  • 認証キーのローテーション。アカウントの認証キーを異なる秘密鍵で制御されるように変更できます。これはWeb2世界でのパスワード変更に似ています。
  • ネイティブマルチシグサポート。Aptos上のアカウントは、認証キーを構築する際にEd25519とSecp256k1 ECDSA署名スキームの両方を使用してk-of-nマルチシグをサポートします。

Aptos上には3種類のアカウントがあります:

  • 標準アカウント - これは対応する公開鍵/秘密鍵のペアを持つアドレスに対応する典型的なアカウントです。
  • リソースアカウント - 開発者がリソースを保存したりモジュールをオンチェーンで公開したりするために使用する、対応する秘密鍵のない自律的なアカウントです。
  • オブジェクト - 単一のエンティティを表す単一のアドレス内に保存されたリソースの複雑なセットです。
Alice: 0xeeff357ea5c1a4e7bc11b2b17ff2dc2dcca69750bfef1e1ebcaccf8c8018175b
Bob: 0x19aadeca9388e009d136245b9a67423f3eee242b03142849eb4f81a4a409e59c

現在、Aptosはアカウントに対して単一の統一された識別子のみをサポートしています。Aptos上のアカウントは、32バイトの16進文字列として汎用的に表現されます。32バイトより短い16進文字列も有効です。そのような場合、16進文字列は先頭にゼロを埋めることができます。例:0x1 => 0x0000000000000...01。Aptos標準では、アドレスから先頭のゼロを削除できることが示されていますが、ほとんどのアプリケーションはそのレガシー動作を避け、0x0から0xaまでの特別なアドレスに対してのみ0の削除をサポートしています。

ユーザーがアカウントの作成を要求する場合、例えばAptos SDKを使用して、以下の手順が実行されます:

  • ユーザーのアカウントを管理するための認証スキームを選択します(例:Ed25519またはSecp256k1 ECDSA)。
  • 新しい秘密鍵と公開鍵のペアを生成します。
  • 公開鍵を公開鍵の認証スキームと組み合わせて、32バイトの認証キーとアカウントアドレスを生成します。

ユーザーは、このアカウントに関連するトランザクションに署名するために秘密鍵を使用する必要があります。

アカウントのシーケンス番号は、そのアカウントから送信され、オンチェーンでコミットされたトランザクションの数を示します。コミットされたトランザクションは、結果の状態変更がブロックチェーンにコミットされるか、状態変更が破棄されてトランザクションのみが保存される中止のいずれかで実行されます。

送信されるすべてのトランザクションには、指定された送信者のアカウントの一意のシーケンス番号が含まれている必要があります。Aptosブロックチェーンがトランザクションを処理する際、トランザクション内のシーケンス番号を見て、オンチェーンアカウント内のシーケンス番号と比較します。シーケンス番号が現在のシーケンス番号以上である場合にのみ、トランザクションが処理されます。現在のシーケンス番号から連続したトランザクションシリーズがある場合にのみ、トランザクションは他のメモリプールに転送されるか実行されます。実行では順序外のシーケンス番号を拒否し、古いトランザクションのリプレイ攻撃を防ぎ、将来のトランザクションの順序を保証します。

初期アカウントアドレスは、アカウント作成時に導出された認証キーに設定されます。ただし、認証キーは後に変更される可能性があります。例えば、新しい公開鍵・秘密鍵ペアを生成してキーをローテーションする場合です。アカウントアドレスは決して変更されません。

Aptosブロックチェーンは以下の認証スキームをサポートします:

  1. Ed25519
  2. Secp256k1 ECDSA
  3. K-of-Nマルチ署名
  4. 専用の、現在はレガシーのMultiEd25519スキーム

Ed25519署名の認証キーとアカウントアドレスを生成するには:

  1. キーペアの生成:新しいキーペア(privkey_Apubkey_A)を生成します。AptosブロックチェーンはRFC 8032で定義されているEd25519曲線上のPureEdDSAスキームを使用します。
  2. 32バイト認証キーの導出pubkey_Aから32バイトの認証キーを導出します:
    auth_key = sha3-256(pubkey_A | 0x00)
    ここで|は連結を示します。0x00は1バイトの単一署名スキーム識別子です。
  3. この初期認証キーを永続的なアカウントアドレスとして使用します。

K-of-Nマルチシグ認証では、アカウントには合計N人の署名者がおり、トランザクションを認証するためにはそのうち少なくともK個の署名が使用される必要があります。

K-of-Nマルチシグアカウントの認証キーとアカウントアドレスを生成するには:

  1. キーペアの生成N個のed25519公開鍵p_1、…、p_nを生成します。
  2. トランザクションの認証に必要な署名の閾値数Kの値を決定します。
  3. 32バイト認証キーの導出:以下に説明するように認証キーを計算します:
    auth_key = sha3-256(p_1 | . . . | p_n | K | 0x01)
    0x01は1バイトのマルチシグスキーム識別子です。
  4. この初期認証キーを永続的なアカウントアドレスとして使用します。

汎用認証はEd25519とSecp256k1 ECDSAの両方をサポートします。以前の認証スキームと同様に、これらのスキームには単一キーとマルチキーでそれぞれ0x020x03のスキーム値が含まれますが、各キーにはそのキータイプを示すプレフィックス値も含まれます:

キータイププレフィックスバイト
Ed25519汎用スキーム0x00
Secp256k1Ecdsa汎用スキーム0x01
Secp256r1Ecdsa WebAuthnスキーム0x02
キーレス0x03

公開鍵pubkeyを使用する単一キーSecp256k1 ECDSAアカウントの場合、認証キーは以下のように導出されます:

auth_key = sha3-256(0x01 | pubkey | 0x02)

ここで

  • 最初のエントリ0x01は、Secp256k1 ECDSAキーの使用を表します;
  • 最後のエントリ0x02は、認証スキームを表します。

単一のSecp256k1 ECDSA公開鍵pubkey_0と単一のEd25519公開鍵pubkey_1を含む1-of-2マルチキーアカウント(1つの署名で十分)の場合、認証キーは以下のように導出されます:

auth_key = sha3-256(0x02 | 0x01 | pubkey_0 | 0x00 | pubkey_1 | 0x01 | 0x03)

ここで

  • 最初のエントリ0x02は、単一バイトとしてのキーの総数を表します;
  • 最後から2番目のエントリ0x01は、単一バイトとしての必要な署名数を表します;
  • 最後のエントリ0x03は、認証スキームを表します。

Aptos上のアカウントには、潜在的に侵害されたキーがアカウントへのアクセスに使用されないようにキーをローテーションする機能があります。キーはaccount::rotate_authentication_key関数を介してローテーションできます。

キーの更新は、セキュリティ分野では一般的に良い慣行とされています。しかし、これは秘密鍵とその関連アカウントの両方を表すニーモニックの使用に慣れているシステムインテグレーターにとって課題を提示します。システムインテグレーターのためにこれを簡素化するために、Aptosはaptos account lookup-addressを介してオンチェーンマッピングを提供します。オンチェーンデータは、現在のニーモニックによって定義される有効なアカウントアドレスを実際のアカウントアドレスにマップします。

詳細については、account.moveを参照してください。

各アカウントの状態は、コード(Moveモジュール)とデータ(Moveリソース)の両方で構成されます。アカウントには任意の数のMoveモジュールとMoveリソースを含めることができます:

  • Moveモジュール:Moveモジュールには、型や手続きの宣言などのコードが含まれますが、データは含まれません。MoveモジュールはAptosブロックチェーンのグローバル状態を更新するためのルールをエンコードします。
  • Moveリソース:Moveリソースにはデータが含まれますが、コードは含まれません。すべてのリソース値には、Aptosブロックチェーン上で公開されたモジュールで宣言された型があります。

トランザクションの送信者は署名者によって表されます。Moveモジュール内の関数がsignerを引数として受け取る場合、Aptos Move VMは、トランザクションに署名したアカウントの身元をMoveモジュールエントリポイント内の署名者に変換します。以下のMove例コードで、initializewithdraw関数内のsignerを参照してください。以下のdeposit関数のように関数でsignerが指定されていない場合、この関数には署名者ベースのアクセス制御は提供されません:

module Test::Coin {
struct Coin has key { amount: u64 }
public fun initialize(account: &signer) {
move_to(account, Coin { amount: 1000 });
}
public fun withdraw(account: &signer, amount: u64): Coin acquires Coin {
let balance = &mut borrow_global_mut<Coin>(Signer::address_of(account)).amount;
*balance = *balance - amount;
Coin { amount }
}
public fun deposit(account: address, coin: Coin) acquires Coin {
let balance = &mut borrow_global_mut<Coin>(account).amount;
*balance = *balance + coin.amount;
Coin { amount: _ } = coin;
}
}