Liskアドレスの初期化問題と新しいアドレス形式

kplusq
2020/11/12 09:23

最近、ちらほらとアドレス初期化問題が表面化しているみたいですね…

かなり前からこの問題は認識されており、HQもブログ（2017年）で警告したり、walletやexplorerにてアラートを出すようにしています。
また、コミュニティレベルでも、さまざまなチャンネルで注意喚起を行っていました。

なので、本家discordを覗いている限りでは、あくまで自己責任という論調が強いようです。　
新アドレスへの移行にも関係することですので、今のうちにおさらいしておきましょう！

アドレス初期化問題とは

一番大事な点は、
「この被害にあうと、LSKを失ってしまう」
というところ。

この被害に遭わないためには、
「一度でいいから送金処理をしておくこと」
です。

送金処理については、voteでもいいし、自分自身のアドレス宛に送金するのでも大丈夫です。とにかく、自分のパスフレーズを使って署名したトランザクションを送信することで、アドレスは初期化されます。
アドレスが初期化されると、この問題は回避できます。

「送信」であって「受信」ではないことにご注意ください！

なぜこの問題が生じるのか

この問題をバグとして非難する声も（ほんの少し）あるようですが、なぜこのような問題が起こってしまうのか、少しだけ掘り下げてみます。

Liskのアドレス（ex.1710406280801763244L）は

パスフレーズ > 秘密鍵 > 公開鍵 > アドレス

という順番で算出されます。
このとき、公開鍵のパターンは２の256乗あるのに対して、現アドレスのパターンは２の64乗しかありません。アドレスを算出するのには明快なロジックがあるのですが、公開鍵のほうが数が多いので、違う公開鍵から同じアドレスを導き出してしまうわけです。

単純な一例をあげると、
abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789
という公開鍵と
abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345678a
という公開鍵は同じアドレスになります。

とはいえ、「一つのアドレスに対して認められる正式な公開鍵は当然一つだけ」です。
（この正式な公開鍵を記録することを初期化と呼んでいます。）

攻撃者は、正式な公開鍵が登録されていないアドレスを見つけ、そのアドレスに紐付く別の公開鍵を探し出すことで、そのアドレスのなかの資産を奪います！

難しい話はおいておいて、卑近な例でいうと、女子に対して圧倒的に男子が多い状況をイメージするとわかりやすいかもしれません。
アドレス初期化とは、アドレスと公開鍵のペアの婚姻届みたいな…。

新アドレスの形式

上の原因を考えると、なぜアドレスのパターンを２の64乗にしてしまったのか…それはひとえに「わかり易さ」を重視した結果でしょう(桁が大きくなると、その分アドレスが長くなってしまい、扱いにくくなります。)

Liskにとってのこだわりポイントだったともいえます。

とはいえ、２の64乗というのは、実際は「18,446,744,073,709,551,616」というとんでもなく大きな数なので、危険性自体は非常に小さいといえます。少々の危険性は承知の上で、あえてユーザビリティを優先したとしても不思議ではありません。

新アドレスでは、やはり２の64乗パターンでは少ないだろうということになりました。
これからは、２の160乗のパターンとなります。これにより、上の問題が起こる可能性は（現状においては）無視してもいいレベルまで小さくなります。（女子の数が増えたので、スムーズなペアリングが期待されます…ちょっと違うかな笑）

新アドレスの形式については、少しだけ留意点があります。というのも、
①プロトコルレベルアドレス（ex.0xbc998186ce61723b1f250bf3afb751aa3f80bce7）
②Base32アドレス(ex.lskdxc4ta5j43jp9ro3f8zqbxta9fn6jwzjucw7yt)
という2種類のアドレスが存在します。

ユーザーが意識すべきなのは、基本的には②の「lsk」から始まるアドレスです。
ただし、sdkの内部では①のプロトコルレベルアドレスが利用されているので、アプリケーションを作成する技術者は、内部で②から①への変換を行う必要があります。