アカウント
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: 0xeeff357ea5c1a4e7bc11b2b17ff2dc2dcca69750bfef1e1ebcaccf8c8018175bBob: 0x19aadeca9388e009d136245b9a67423f3eee242b03142849eb4f81a4a409e59c
アカウントアドレス
Section titled “アカウントアドレス”現在、Aptosはアカウントに対して単一の統一された識別子のみをサポートしています。Aptos上のアカウントは、32バイトの16進文字列として汎用的に表現されます。32バイトより短い16進文字列も有効です。そのような場合、16進文字列は先頭にゼロを埋めることができます。例:0x1
=> 0x0000000000000...01
。Aptos標準では、アドレスから先頭のゼロを削除できることが示されていますが、ほとんどのアプリケーションはそのレガシー動作を避け、0x0
から0xa
までの特別なアドレスに対してのみ0の削除をサポートしています。
アカウントの作成
Section titled “アカウントの作成”ユーザーがアカウントの作成を要求する場合、例えばAptos SDKを使用して、以下の手順が実行されます:
- ユーザーのアカウントを管理するための認証スキームを選択します(例:Ed25519またはSecp256k1 ECDSA)。
- 新しい秘密鍵と公開鍵のペアを生成します。
- 公開鍵を公開鍵の認証スキームと組み合わせて、32バイトの認証キーとアカウントアドレスを生成します。
ユーザーは、このアカウントに関連するトランザクションに署名するために秘密鍵を使用する必要があります。
アカウントシーケンス番号
Section titled “アカウントシーケンス番号”アカウントのシーケンス番号は、そのアカウントから送信され、オンチェーンでコミットされたトランザクションの数を示します。コミットされたトランザクションは、結果の状態変更がブロックチェーンにコミットされるか、状態変更が破棄されてトランザクションのみが保存される中止のいずれかで実行されます。
送信されるすべてのトランザクションには、指定された送信者のアカウントの一意のシーケンス番号が含まれている必要があります。Aptosブロックチェーンがトランザクションを処理する際、トランザクション内のシーケンス番号を見て、オンチェーンアカウント内のシーケンス番号と比較します。シーケンス番号が現在のシーケンス番号以上である場合にのみ、トランザクションが処理されます。現在のシーケンス番号から連続したトランザクションシリーズがある場合にのみ、トランザクションは他のメモリプールに転送されるか実行されます。実行では順序外のシーケンス番号を拒否し、古いトランザクションのリプレイ攻撃を防ぎ、将来のトランザクションの順序を保証します。
初期アカウントアドレスは、アカウント作成時に導出された認証キーに設定されます。ただし、認証キーは後に変更される可能性があります。例えば、新しい公開鍵・秘密鍵ペアを生成してキーをローテーションする場合です。アカウントアドレスは決して変更されません。
Aptosブロックチェーンは以下の認証スキームをサポートします:
- Ed25519
- Secp256k1 ECDSA
- K-of-Nマルチ署名
- 専用の、現在はレガシーのMultiEd25519スキーム
Ed25519認証
Section titled “Ed25519認証”Ed25519署名の認証キーとアカウントアドレスを生成するには:
- キーペアの生成:新しいキーペア(
privkey_A
、pubkey_A
)を生成します。AptosブロックチェーンはRFC 8032で定義されているEd25519曲線上のPureEdDSAスキームを使用します。 - 32バイト認証キーの導出:
pubkey_A
から32バイトの認証キーを導出します:ここでauth_key = sha3-256(pubkey_A | 0x00)|
は連結を示します。0x00
は1バイトの単一署名スキーム識別子です。 - この初期認証キーを永続的なアカウントアドレスとして使用します。
MultiEd25519認証
Section titled “MultiEd25519認証”K-of-Nマルチシグ認証では、アカウントには合計N人の署名者がおり、トランザクションを認証するためにはそのうち少なくともK個の署名が使用される必要があります。
K-of-Nマルチシグアカウントの認証キーとアカウントアドレスを生成するには:
- キーペアの生成:
N
個のed25519公開鍵p_1
、…、p_n
を生成します。 - トランザクションの認証に必要な署名の閾値数
K
の値を決定します。 - 32バイト認証キーの導出:以下に説明するように認証キーを計算します:
auth_key = sha3-256(p_1 | . . . | p_n | K | 0x01)
0x01
は1バイトのマルチシグスキーム識別子です。 - この初期認証キーを永続的なアカウントアドレスとして使用します。
汎用認証はEd25519とSecp256k1 ECDSAの両方をサポートします。以前の認証スキームと同様に、これらのスキームには単一キーとマルチキーでそれぞれ0x02
と0x03
のスキーム値が含まれますが、各キーにはそのキータイプを示すプレフィックス値も含まれます:
キータイプ | プレフィックスバイト |
---|---|
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
は、認証スキームを表します。
キーのローテーション
Section titled “キーのローテーション”Aptos上のアカウントには、潜在的に侵害されたキーがアカウントへのアクセスに使用されないようにキーをローテーションする機能があります。キーはaccount::rotate_authentication_key
関数を介してローテーションできます。
キーの更新は、セキュリティ分野では一般的に良い慣行とされています。しかし、これは秘密鍵とその関連アカウントの両方を表すニーモニックの使用に慣れているシステムインテグレーターにとって課題を提示します。システムインテグレーターのためにこれを簡素化するために、Aptosはaptos account lookup-addressを介してオンチェーンマッピングを提供します。オンチェーンデータは、現在のニーモニックによって定義される有効なアカウントアドレスを実際のアカウントアドレスにマップします。
詳細については、account.move
を参照してください。
アカウントの状態
Section titled “アカウントの状態”各アカウントの状態は、コード(Moveモジュール)とデータ(Moveリソース)の両方で構成されます。アカウントには任意の数のMoveモジュールとMoveリソースを含めることができます:
- Moveモジュール:Moveモジュールには、型や手続きの宣言などのコードが含まれますが、データは含まれません。MoveモジュールはAptosブロックチェーンのグローバル状態を更新するためのルールをエンコードします。
- Moveリソース:Moveリソースにはデータが含まれますが、コードは含まれません。すべてのリソース値には、Aptosブロックチェーン上で公開されたモジュールで宣言された型があります。
署名者によるアクセス制御
Section titled “署名者によるアクセス制御”トランザクションの送信者は署名者によって表されます。Moveモジュール内の関数がsigner
を引数として受け取る場合、Aptos Move VMは、トランザクションに署名したアカウントの身元をMoveモジュールエントリポイント内の署名者に変換します。以下のMove例コードで、initialize
とwithdraw
関数内の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; }}