蟻地獄

Twitterに書ききれない長めの文とか書くよ

AWS SDKをUnityで使う方法(2020年度版)

AWS SDK Unity」でググると、AWS Mobile SDK for Unityの公式ドキュメントがトップに表示されます。 どこの馬の骨かもわからない個人ブログなんか参考にしなくても公式ドキュメント見ればええやんと思うかもしれませんが、残念ながら公式ドキュメントの内容は古いです。

公式ドキュメントからリンクが貼ってある http://sdk-for-net.amazonwebservices.com/latest/aws-sdk-unity.zip のunitypackageは、 まず同梱のサンプルシーンが動かず、エラーメッセージをググりながらなんとか動かせたとしてもAndroidでエラーが出たりします。

どうしてこうなった

AWS SDK for Unityは元々AWS SDK for .NETをフォークして作成されたもので、リポジトリも分かれていました。 しかし、サポートされる機能が増えるにつれ両方のリポジトリをメンテするのが困難になったため、Unity版は.NET版のリポジトリに吸収され、.NET版の一部として提供されるようになりました。 しかし、この時点ではコードを完全に共通化できたわけではなく、プラットフォーム毎にコードが分かれている部分があり、インタフェースも微妙に違っていました。

その状況を解消したのが.NET Standard 2.0です。 .NET Standard向けのビルドではUnityでも共通のコードが使えるようになり、今までUnityでは一部のサービスのSDKしか提供されていなかったのが全てのサービスをサポートするようになりました。

というわけでUnity向けのAWS SDKは、

  • Unity Custom版
  • .NET Standard版

の2つのバージョンがあり、インタフェースも対応サービスも異なります。 そして公式ドキュメントで説明されている導入方法は、Unity Custom版のものです。 Unity Custom版は既にサポートが終了しており、.NET Standard版への移行が推奨されています。じゃあドキュメント直せよ。

.NET Standard版の導入方法

公式ブログに書かれています。

  1. http://sdk-for-net.amazonwebservices.com/latest/v3/aws-sdk-netstandard2.0.zip からdllをダウンロードしてAssetフォルダにコピー
  2. IL2CPPを使う場合はlink.xmlを書く

コードに関してはUnity独自のおまじないとかは不要になったので、.NET版のドキュメントを参考に書けば大丈夫です。 UnityInitializer.AttachToGameObject(this.gameObject); とかも不要です。

注意点

ただし、こちらの記事で書かれているように、 .NET Standard版はコードを共通化した代償として、Unity Custom版でしか提供されていなかった一部機能も削除されてしまいました。これらの機能を使いたい場合は古いコードを参考に自前で実装する必要があります。

例えば、CognitoはUnity Custom版ではPlayerPrefsをキャッシュとして使用しており、認証されていないユーザーのIDはアプリケーションを再起動しても保持されます。 しかし、.NET Standard版ではPlayerPrefsを使ったコードを入れるわけにはいかないので、デフォルトでは認証されていないユーザーのIDはアプリケーションの起動毎に変わってしまいます。 この動作を変更するには、こちらのコードのコメントに書いてあるように、CognitoAWSCredentialsをオーバーライドしてキャッシュの動作を実装する必要があります。

まとめ

ドキュメントはちゃんと更新しよう。

ソーシャルVR「Hubs Cloud」を立ててみた + 日本語化

2020/5/30追記

維持費が高いのでOffline Modeにしました。Aurora Serverless、400PV/月くらいでも$50くらい掛かるよ!


出来上がったものがこちらです。

f:id:mitomemel:20200530093252p:plain f:id:mitomemel:20200530094253p:plain

Hubs Cloudとは、MozillaのソーシャルVRMozilla Hubs」を自前のAWSアカウントで立てることのできるCloudFormationテンプレートです。あまり詳しくない人向けに説明すると、マストドンVRだと思っとけばだいたいあってます。

Mozilla Hubsはオープンソース化されており、がんばれば自前で1からビルドしてデプロイすることも可能です。しかし、現代のWebサービスのデプロイはなかなか複雑で、Apacheの公開ディレクトリにファイルをコピーすれば終わりというわけにはいきません。Hubs Cloudは、GUIをぽちぽちするだけで冗長化とオートスケーリング対応済みのそのまま本番投入可能なサーバを立ち上げることができます。いい時代になったものですね。

Hubs Cloudをわざわざ立てなくても、本家のMozilla Hubsでも自分のプライベートルームを作って自前アバターやシーンをインポートすることは可能です。ではなぜ人はHubs Cloudを立てるのかというと、自前で立てることでAdmin画面に入ることができるようになります。Admin画面では以下のような項目の変更が可能です。

  • デフォルトで選べるアバター・シーンのラインナップ (Mozilla Hubsのデフォルトアバターはちょっとバタ臭いですよね。アバターだけに)
  • Title・Description・ロゴなどのブランディング
  • トップページのDocs・Communityなどのボタンのリンク先、表示非表示
  • Adminユーザー以外がルームを作れないようにするなどの権限設定
  • UIの配色

逆に言えば、上記のような項目を変えたいわけではなく単に自分のプライベートルームを作りたいだけであれば本家のMozilla Hubsで十分です。Hubs Cloudは最小構成でも$40/月$100/月くらい掛かります。マストドンを立ててみたものの結局Pawooしかアクセスしてないそこのあなた、本当にHubs Cloudを立てる必要があるかはよく考えましょう。私はよく考えずに立てました。勢いって大事だよね。

立て方

こちらのページに従って作業するだけです。レシピをアレンジしないことが重要です。初心者はまずレシピ通りに作ってみましょう。

特に「2. Register a new domain name on Route 53」を下手にアレンジして失敗している人が多いようです。ドメインの構成についてはこちらのページに詳しく書いてありますが、どのパターンにしても、新規ドメインを2個買う必要があります。はい、2個です。「うそやん、うまいことやれば1個でできるやろ?」とか「既に持ってるドメインサブドメインで運用したろ」と思うことでしょう。そう思っていた時期が私にもありました。「Route53で管理されている」「未使用のドメイン」「2個」必要です。ここはあきらめてさっさとドメインをポチりましょう。

日本語化について

私が立てたインスタンスは日本語化されていますが、これはどうやっているのかというと、クライアントのリポジトリをフォークしてコードをいじりました。こちらのページに書いてある通り、既にデプロイフローが用意されておりクライアントを簡単に差し替えることができます。

言語ファイルはhttps://github.com/mozilla/hubs/blob/master/src/assets/translations.data.jsonにあります。現状だとこの"en":{}の中身を直接書き換えてしまうのが日本語化の一番簡単な方法です。"ja":{}というキーを追加してもうまく日本語化されません。というのも、一部言語を"en"決め打ちで書かれているコードがあるからです。決め打ちで書かれている部分を修正するプルリクを投げようかとも思いましたが、現在こちらのIssueで議論されているように、多言語対応についてはライブラリをFluentに変更してPontoonを使ったワークフローでやっていくようです。なので、現在のコードベースのまま多言語対応しても無駄になる可能性が高そうです。

まとめ

早く本家が多言語対応しますように。 Fluentに詳しい人、OSSに貢献できるチャンスですよ!!!

CloudSearchのdomainを複数環境で共有したい

この記事は VALU Advent Calendar 2019 20日目のエントリです。

株式会社VALUのバックエンドエンジニアのMito Memelです。前回のエントリで、渾身のギャグ「これでキューが急に詰まっても安心ですね!」が誰にも拾ってもらえなくて悲しいです。

VALUのサーバインフラはAWSですが、AWS全文検索システムを構築する場合、Elasticsearch ServiceとCloudSearchどちらを使えば良いか迷いますよね。Elasticsearchにしか無い機能を使いたい場合は選択の余地はありませんが、そうでない場合、CloudSearchのオートスケーリングは魅力的です。Elasticsearch Serviceは自動フェイルオーバーはしてくれるものの、インスタンスタイプ・ノード数の計画は自分で立てる必要があります。何も考えずにdomain(CloudSearchクラスタの設定単位)を1個作るだけで良いCloudSearchはとてもお手軽です。

しかし、CloudSearchにも欠点があります。スケールアウトは得意なんですが、性能がそれほど必要では無い場合、スケールダウンしたくても最小構成で1domainにつき$60/月程度(東京リージョンの場合)掛かります。1domainだけならまだ良いんですが、例えば開発環境が複数あったりすると環境ごとにdomainを作らなければならず、リソースは有り余っているのに料金がかさむという状況になりがちです。その点Elasticsearchだと1domain内でもindexで分けることができるので、複数環境でdomainを共有するのも簡単です。残念ながらCloudSearchにはElasticsearchで言うindexのようなものは無いのですが、どうにかして1domainを複数環境で共有できるようにしたいものです。そこで、実際に試してみました。

fieldでがんばる

まず最初に思い付くのは、index みたいな名前のfieldを追加して、検索時に毎回そのfieldを条件に含めるというやり方です。この方法でもできなくは無いのですが、いくつか欠点があります。

idフィールドの被り

CloudSearchにはMySQLで言うauto_incrementのような自動採番は無く、documentのアップロード時にユニークなidを明示的に指定する必要があります。このidは例えばユーザー検索ならRDB側で振っているユーザーIDを使うなどすれば良いのですが、1domainを複数環境で共有する場合、idが被ってしまう可能性があります。なので、idのprefixに環境名を付けるなどの工夫が必要となります。

field名のルールが増える

index みたいな名前のフィールドを追加する」と先ほど書きましたが、documentの検索対象fieldでうっかり同じ名前を使ってしまうみたいな事故が考えられます。なので環境識別のための名前空間として使用するfieldはsuffixに _ を付けて index_ みたいな名前にし、検索対象fieldではそのsuffixを避ける、みたいなルールが必要になります。これでも良いんですが、なんかこう、もうちょっとスマートにやりたいですよね。

idを構造化する

idフィールドの被りを避けるためにidにprefixを付けるなどの工夫が必要なのであれば、いっそのことidフィールドのprefix検索だけで名前空間を分けられないか?と考えました。

idフィールドに使える記号は​ _ - = # ; : / ? @ です。これを使って、例えば {環境名}/{データ種別}/{連番} のような階層構造のidを付ければ、idの被りを防いだ上で、余分なfieldを追加しなくてもidのprefix検索で環境を特定することが可能です。実際のコードは以下のようになります。

documentのアップロード

public function uploadDocuments(CloudSearchDomainClient $client, string $index, string $type, array $documents)
{
    // idを置換
    $formatted_documents = array_map(function($document) use ($index, $type){
        $document['id'] = "{$index}/{$type}/{$document['id']}";
        return $document;
    }, $documents);

    $client->uploadDocuments([
        'contentType' => 'application/json',
        'documents' => json_encode($formatted_documents),
    ]);
}

documentの検索

public function search(CloudSearchDomainClient $client, string $index, string $type, string $query)
{        
    // クエリにidのprefix条件を追加
    $formatted_query = "$query _id:{$index}/{$type}/*";

    $response = $client->search([
        'query' => $formatted_query,
        'queryParser' => 'lucene',
    ]);

    // id部分のみを返す
    return array_map(function($id){
        return explode('/', $id)[2];
    }, array_column(array_get($response, 'hits.hit', []), 'id'));
}

まとめ

idのprefix検索を利用することで、CloudSearchのdomainを複数環境で共有することができました。これで開発環境では料金を抑えつつ、本番環境ではCloudSearchのオートスケールのメリットを享受することができます。

LaravelのキューワーカーをCloudWatchで監視する

この記事は VALU Advent Calendar 2019 5日目のエントリです。

株式会社VALUのバックエンドエンジニアのMito Memelです。FGOの星4配布はぐっちゃん先輩にしました。

皆さん、Laravelのキューワーカーは監視していますか?公式ドキュメントに書いてあるようにSupervisorに登録しただけで監視した気にはなっていないですよね?

Supervisorはプロセスの死活を見ているだけで、実際にキューが消化されているかは見てくれません。キューが詰まってしまってもなかなか気づきにくいのがキューワーカーの怖いところですよね。タイムアウトを設定していていも、そもそもワーカー本体が何らかの原因で固まってしまうこともあり得ます(というか最近本番環境で発生しました)。そこで、実際にキューが消化されているかをCloudWatchで監視してみます。

キューが消化されているかを確認するには、実際にジョブを投げて処理されるかを見るのが確実です。つまり外形監視ですね。というわけで、まずはCloudWatchに値を投げつけるだけのジョブを作成します。

class Heartbeat implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    private $created_at;

    public function __construct()
    {
        $this->created_at = now();
    }

    public function handle()
    {
        $client = App::make('aws')->createClient('cloudwatch');
        $client->putMetricData([
            'Namespace' => config('app.name') . '/' . config('app.env'),
            'MetricData' => [
                [
                    'MetricName' => 'QueueWorkerLatency',
                    'Value' => now()->diffInSeconds($this->created_at),
                    'Unit' => 'Seconds',
                ]
            ],
        ]);
    }
}

__construct()handle()の時間差を測ることで、「ジョブをdispatch()してから実際に処理されるまでの時間」が測れるわけですね。

そしてこのジョブをdispatch()するだけのコマンドを作成してタスクスケジュールに登録します。

class DispatchHeartbeat extends Command
{
    protected $signature = 'heartbeat:dispatch';

    protected $description = 'Heartbeatジョブをキューに積みます';

    public function handle()
    {
        Heartbeat::dispatch();
    }
}

これでCloudWatchでジョブの処理遅延時間をメトリクスとして取得することができるようになりました! f:id:mitomemel:20191204145642p:plain

あとはCloudWatchのアラーム設定でデータの欠落or処理遅延時間の増加を検知してアラートメールを送るなり煮るなり焼くなりしましょう。 これでキューが急に詰まっても安心ですね!

Monappy事件はどうすれば防げたのか

この記事は VALU Advent Calendar 2018 25日目のエントリです。

株式会社VALUのバックエンドエンジニアのMito Memelです。始皇帝が宇宙開発したりガンジーが核撃ってくるシヴィライゼーションっていうゲームが好きです。

今年9月にMonacoinウォレットサービス「Monappy」でホットウォレットに保管されていた全てのMonacoinが不正に出金されるという事件がありましたが、詳細な原因が早期に公開されたことが話題になりました。

medium.com

本エントリでは上記の記事を元に、どうすればMonacoinの多重送金を防げたのかを考えます。

上記の記事では、多重送金の原因が以下のように説明されています。

MonappyからMonacoinを送信する際は、monacoindという別のサーバ上のアプリケーションと通信する仕様になっています。この通信がタイムアウト等で失敗した場合はサーバダウンなどで送金に失敗しているとみなして、取引をロールバックする仕様となっていました。また、ギフトコードの処理に関してはデータベースのトランザクション機能等を利用しており、本来同じギフトコードを二重に使用することはできないようになっていました。しかし、高負荷状態でギフトコードを連続して使用しようとした場合、通信を受け取ったmonacoindの応答に時間がかかり、サイト側ではタイムアウトとなってロールバックされたあとにmonacoind側では送金が行われていました。この結果、一つのギフトコードから複数回送金されたものと考えられます。

中央集権型ウォレットサービスにおけるコインの出金処理とは、単純化すると以下の処理を行うことです。

  • ブロックチェーン上で指定されたアドレスにコインを送金する
  • サービス側のDB(通常はリレーショナルデータベース)上のユーザーの残高を減らす(Monappyの場合はギフトコードを使用済みにする)

ではまずダメな例を考えてみましょう。上記の処理を単純にコード化すると以下のようになります。

function use_giftcode($code, $address)
{
    try{
        DB::statement("START TRANSACTION");
        $giftcode = DB::select("SELECT * FROM giftcodes WHERE code=? AND status='unused' FOR UPDATE", [$code]);
        if(!$giftcode){
            throw Exception("ギフトコードが既に使用されています");
        }
        $tx = send_monacoin($address, $giftcode->mona_amount); // ブロックチェーン上で送金
        DB::update("UPDATE giftcodes SET status='used', tx_id=? WHERE code=?", [$tx->id, $code]);
        DB::statement("COMMIT");
    }catch(Exception $e){
        DB::statement("ROLLBACK");
        throw $e;
    }
}

※実際にはブロックチェーン上での承認数の確認なども必要になりますが、それはまた別レイヤーの話なので省略します。

上記のコードの場合、send_monacoin()より下のDB更新で失敗すると、ブロックチェーン上での送金は成功しているのにギフトコードが使用済みになりません。攻撃者がDB負荷を高めるなどして意図的にDB書き込みの失敗率を上げられるのであれば、ホットウォレットが枯渇するまで出金し放題です。

これを防ぐためには、どの時点で失敗したとしても、

という状態にする必要があります。つまり、ブロックチェーンRDBをまたいだ分散トランザクションが必要になるわけです。はい、胃が痛くなってきましたね。

では次に、上記を考慮したコードにしてみましょう。下記がおそらくMonacoinの多重送金が発生した際のコードに近いと思われます。

function use_giftcode($code, $address)
{
    $giftcode = DB::select("SELECT * FROM giftcodes WHERE code=?", [$code]);
    // ローカルでMonacoinのトランザクションデータを作成
    $tx = build_monacoin_transaction($address, $giftcode->mona_amount);

    try{
        DB::statement("START TRANSACTION");
        $giftcode = DB::select("SELECT * FROM giftcodes WHERE code=? AND status='unused' FOR UPDATE", [$code]);
        if(!$giftcode){
            throw Exception("ギフトコードが既に使用されています");
        }
        DB::update("UPDATE giftcodes SET status='sending', tx_id=? WHERE code=?", [$tx->id, $code]);
        DB::statement("COMMIT");
    }catch(Exception $e){
        DB::statement("ROLLBACK");
        throw $e;
    }

    try{
        // トランザクションデータをMonacoinネットワークにブロードキャスト
        broadcast_monacoin_transaction($tx);
    }catch(Exception $e){
        // 送金が失敗したのでギフトコードを未使用状態にロールバック
        DB::update("UPDATE giftcodes SET status='unused', tx_id=NULL WHERE code=?", [$code]);
        throw $e;
    }

    DB::update("UPDATE giftcodes SET status='used' WHERE code=?", [$code]);
}

まず、ローカルでMonacoinの送金トランザクションを作成し、トランザクションIDをギフトコードのDBレコードに紐付けます。次にMonacoinの送金をブロードキャストし、成功すればギフトコードを使用済みに更新、失敗すれば未使用状態にロールバックします。こうすることで、どの時点で失敗してもMonacoinの送金が成功したかどうかをトランザクションIDで追跡可能になるので、statusが sending のギフトコードを定期監視するバッチがあれば自動リカバリ可能です。

しかし、上記のコードにも問題があります。それは、broadcast_monacoin_transaction()が失敗した際に、エラー種別に関係なく必ずギフトコードを未使用状態にしていることです。例えば、monacoindがブロードキャストに時間が掛かりタイムアウトした場合、broadcast_monacoin_transaction()は失敗扱いになりますが、ブロードキャスト自体は成功している場合があり得ます。その場合、送金が成功したのにギフトコードが未使用状態になります。攻撃者がこの状態を意図的に発生させることが出来れば、ホットウォレットが枯渇するまで出金し放題です。これを防ぐためにはブロードキャストの部分を下記のように修正する必要があります。

    try{
        // トランザクションデータをMonacoinネットワークにブロードキャスト
        broadcast_monacoin_transaction($tx);
    }catch(BeforeBroadcastException $e /*ブロードキャスト前に失敗したことが確実な場合*/){
        DB::update("UPDATE giftcodes SET status='unused', tx_id=NULL WHERE code=?", [$code]);
        throw $e;
    }

エラーの種別を分けて、Monacoinネットワークにブロードキャストする前に失敗したことが確実な場合のみ未使用状態へのロールバックを行います。ブロードキャストが成功したか失敗したか分からない場合はギフトコードを sending 状態のまま保留しておき、後で定期監視バッチにより成否を判定します。

まとめ

以上がMonappyの公開情報から推測した多重送金の仕組みと対策案です。「ブロックチェーンは多重送金が仕組み上不可能で信頼性が高い」というのは取引がブロックチェーン上だけで完結する場合の話です。現実世界でサービスを提供するには多くの場合外部リソースとの連携が不可欠で、上記のような分散トランザクションが必要になります。それを解決するのがスマートコントラクトということなのでしょうが、それはそれでスケーラビリティなど問題が山積みです。

最後に

弊社では一緒に来年のAdvent Calendarを書いてくれるバックエンドエンジニアやその他だいたい全部の職種を募集しています。電話会社を最近退職した分散トランザクションが得意な方などはぜひご応募下さい。

graspy.jp

BIP44が分からなくなる話

この記事はVALU Advent Calendar 7日目のエントリです。

株式会社VALUのバックエンドエンジニアのMito Memelです。 先日、HDウォレットの残高を監視するコードを書いた際にBIP44について無駄に詳しくなりましたので、知見を共有します。

BIP44とは

BIP44はHDウォレットのアドレス階層の仕様です。 HDウォレットのアドレス生成アルゴリズムBIP32で定められていますが、BIP32だけでは「あるHDウォレットのマスターキーを別のメーカーのHDウォレットにインポートしたら残高が復元できる」ということを実現するには足りません。なぜかというと、マスターキーからはアドレスが無限に生成できるので、好き勝手なアドレスに入金してしまうとインポート先のウォレットでどのアドレスに入金されているのかを調べるのに無限時間掛かってしまうためです。

アドレス階層

BIP44では、アドレス階層の使い方を以下の形式に定めています。

m / purpose' / coin_type' / account' / change / address_index

先頭の m はマスターキーのことです。' は強化鍵を使っているかどうかですが、説明すると長くなるのでBIP32を読んでください。各階層の意味は以下の通りです。

purpose

アドレス階層がどのBIPに従っているかを示す番号です。BIP44に従っている場合は 44 になります。

coin_type

Bitcoin0 、Ethereumは 60 、というように通貨種別を表す定数です。定数は https://github.com/satoshilabs/slips/blob/master/slip-0044.md で定義されています。この階層により、複数通貨に対応したウォレットも1つのマスターキーだけで表現可能になります。

account

HDウォレットは通常、1種類の通貨内でも複数の口座に分けて残高を管理することができます。この階層にはどの口座かを示すindexが入ります。

change

BIP44では入金用アドレスとお釣り用アドレスの階層を明確に分けています。この階層が0なら入金アドレス、1ならお釣りアドレスです。

address_index

アドレスの連番です。新しいアドレスを生成する際はここをインクリメントしていくことになります。


以上の階層を使用することにより、例えば以下のようにアドレス階層を一意に決めることができます。

  • Bitcoinの2番目の口座の10番目の入金アドレス: m/44’/0’/1’/0/9
  • Ethereumの5番目の口座の8番目のお釣りアドレス: m/44’/60’/4’/1/7

※indexは0始まりなので、「2番目」のindexは 1 になります。

アカウント探索

さて、前述の「どのアドレスに入金されているのかを調べるのに無限時間掛かってしまう」問題についてですが、これを解決するためにBIP44では gap limitという概念を導入しています。gap limitとは、「この数以上入金履歴がないアドレスが続いた場合、それ以降のアドレスには入金しない」ということを定めた定数です。BIP44ではこの定数は20となっています。また、account の階層では、未使用の口座がある状態で新しい口座を作成することは禁止されています。つまり、「ウォレット内の全てのBTC口座」を列挙する擬似コードは以下のようになります。

function get_accounts($wallet)
{
    $result = [];
    $account = 0;
    $index = 0;

    while(true){
        $address = $wallet->derive_address("m/44'/0'/{$account}'/0/{$index}");
        $transactions = fetch_transactions($address);
        if($transactions->isEmpty()){
            if(++$index == 20){
                break;
            }
        }else{
            $result[] = $account;
            $account++;
            $index = 0;
        }
    }

    return $result;
}

これで account 階層の列挙はできました。各 account の残高を取得する擬似コードは以下のようになります。

function get_balance($wallet, $account)
{
    $balance = 0;
    $index = 0;
    $gap = 0;

    foreach([0, 1] as $change){
        while(true){
            $address = $wallet->derive_address("m/44'/0'/{$account}'/{$change}/{$index}");
            $transactions = fetch_transactions($address);
            if($transactions->isEmpty()){
                if(++$gap == 20){
                    break;
                }
            }else{
                $balance += get_balance($transactions);
                $gap = 0;
            }
            $index++;
        }
    }

    return $balance;
}

account の列挙では change が0のアドレスのみ走査すれば大丈夫でしたが、残高を取得するにはお釣りアドレスも走査する必要があります。ここが罠ポイントで、BIP44には紛らわしい記述があります。

We scan just the external chains, because internal chains receive only coins that come from the associated external chains.

この記述は前述の account 列挙時の話であって、入金アドレスの走査だけだと「複数のoutputのうちどれが出金先でどれがお釣りなのか?」が分からないので残高を出すことはできません。ここで引っかかっている人は多いようで、Stack Exchangeにも複数の質問が上がっていました。

次に問題になるのが、お釣りアドレスにもgap limitが設定されているのか?それとも account 階層のように必ず 0 から順番に使わないといけないのか?という点ですが、実はこれについてはBIP44の記述は曖昧です。gap limitは入金アドレスについての記述しかなく、上記の擬似コードではひとまず入金アドレスと同じ20としています。実際のウォレットではお釣りアドレスにもっと小さいgap limitを使用している場合もありますが、とりあえず大きめに取っておけばアドレスの取りこぼしは防げます。そこ曖昧にしたらあかんやろと思うのですが、完璧な絶望が存在しないように完璧な仕様も存在しないので、適当にうまいことやりましょう。

まとめ

HDウォレットの互換性はわりとふわっとしているので、同じBIPを採用していると謳っている別メーカーのウォレットにマスターキーをインポートしても100%残高が復旧できるとは限りません。が、同じアドレス階層を採用したウォレットで、インポート先でgap limitを大きく取れば大抵はなんとかなると思われます。知らんけど。

株式会社VALUにJOINします

この度、私 @mito_memel は、株式会社フロム・ソフトウェアを退職し、株式会社VALUに入社することになりましたのでご報告いたします。本格的に開発に携わるのはまだ1ヶ月ほど先なのですが、既に内部情報にアクセスできる状態ですのでサクラっぽくなってもアレなのでこのタイミングで公表いたしました。

で、誰?

アスキーアートが立体化するアバターチャット作ったりLingrがサービス終了した時に避難所としてCometを使ったWebチャット作ったりHTML5の黎明期にWebGL+WebSocketで3Dアバターチャット作ったりAmazonガチャの炎上に便乗してAmazonガチャシミュレータ作ったりVALUのパロディとして無を売買できるサービス作ったりしている、CivilizationFactorioをこよなく愛するゆるふわエンジニアです。技術ブロガーとしても無名の名を欲しいままにしており、最近書いた記事はこの辺りです。

最近はVALUのタイムライン上でひたすらVALUをdisっており、たぶんVALUをdisった回数で言うと人類で一番多いんじゃないかと思います。

なんで入ったの?

今さらVALUを取り巻く状況については説明しませんが、ご存知の通りVALUは出来が悪いサービスで、そもそも暗号通貨業界自体、私は以前から懐疑的です。NILUを作ったのがきっかけでオファーをいただいたのですが、VALUのフロントエンドのコードはバグだらけだし、プレスリリースで出てくる文章は下手くそかよだし、正直あまり魅力を感じる会社ではありませんでした。しかし、小飼弾さんがリードエンジニアに就任したというニュースを聞き、考えが変わりました。小飼弾さんが入ったことで優秀なエンジニアを集めやすくなりますし、エンジニアの作業環境や待遇がいい感じになる可能性も高くなります。また、VALUの胡散臭さについては、中の人の話を聞いたところ、どうも悪意があるわけではなく本当に天然でただただ手が足りてないだけということが分かってきまして、エンジニアリングとして見てもクソゲーをまともに遊べるようにするというチャレンジには魅力を感じましたので、お話を受けることにしました。たとえVALUがすぐ潰れたとしても幸い再就職先には困っておりませんので、心置きなくこの機会を目一杯楽しもうと思っています。

今後について

NILUおよびvaluforumについては今後も個人として運営を続けます。NDAの都合上、VALUについての意見の表明は減るかと思いますが、今までVALUをdisることに注いでいた情熱は今後はサービスの改善に注ぐつもりですので生温かく見守っていただければと思います。現在所持している他者のVAについてはそのまま保持しますが、今後は他者のVAの購入は行いません。現在設定してある優待は出来る限り続けるつもりですが、今後のサービスの展開次第では提供をやめる可能性もありますのであらかじめご了承下さい。