# [HIP15] Hederaアドレスのチェックサムによる誤送金防止の仕組みを理解しよう！

> Hederaでは、アドレスを「チェックサム付き」と「チェックサムなし」の2種類で表記できます。チェックサムとは、アドレスの後に5文字の英小文字を追加したもので、入力ミスや桁間違いを検出するために用いられます。

- URL: https://cardene.dev/articles/2016225aa200712f7d43
- 公開日: 2025-08-13
- 更新日: 2025-08-13
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、Hederaアドレスに5文字のチェックサムを追加し、入力ミスや類似アドレスによる誤送金を防ぐ仕組みを提案している**HIP15**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://github.com/hiero-ledger/hiero-improvement-proposals/blob/main/HIP/hip-15.md

他にも様々なEIP・BIP・SLIP・CAIPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

Hederaでは、アドレスを「**チェックサム付き**」と「**チェックサムなし**」の2種類で表記できます。
チェックサムとは、アドレスの後に5文字の英小文字を追加したもので、入力ミスや桁間違いを検出するために用いられます。
例えば「`0.0.123`」というアドレスは、チェックサム付きでは「`0.0.123-vfmkw`」のように表記されます。
これにより、送金先アドレスを手動で入力する時のミスを事前に検出し、不正確な取引を防ぐことができます。

## 動機

従来のHederaアドレス形式（例：`0.0.12345`）は短く覚えやすい一方で、手入力時に桁の入れ替え、抜け、追加といったミスが発生しやすいという問題がありました。
誤ったアドレスを指定した場合、送金は不可逆的に完了してしまうため、資金が失われる危険があります。

さらに、悪意のある第三者が高額取引先に似たアドレスを大量に取得し、利用者の入力ミスを利用して資金を奪う可能性もあります。
Hederaではアカウント作成コストが低いため、短時間で数千件の類似アドレスを取得することが可能です。
このような背景から、誤送金防止のためにチェックサムの導入が提案されています。
なお、互換性のためにチェックサムは必須ではなくオプションとして運用できます。

## 補足

Hederaのパブリックレジャーでは、アカウント・ファイル・スマートコントラクト・トピック・トークンなどのエンティティは`0.0.123`のような形式で識別されます。
この形式は多くのウォレットやアプリで利用されてきましたが、ユーザーが手入力する際の誤りを防ぐ機能はありませんでした。

そこで、新しい標準として、アドレスの末尾に5文字のチェックサムを追加した「**チェックサム付きアドレス**」を定義します。
このチェックサムは、アドレス本体とレジャーIDを元に算出され、1〜4桁の数字の追加・削除、数字の変更、隣接する数字の入れ替えといった典型的な入力ミスを必ず検出できるよう設計されています。
また、完全に異なるアドレスやレジャーIDに変更した場合でも、同じチェックサムになる確率は100万分の1以下に抑えられます。

## 仕様

チェックサム付きアドレスは以下の形式で表記します。

* 例：`0.0.123-vfmkw`
* 区切りはハイフン（`-`）で、全て小文字
* アドレス部分の整数に先頭ゼロは付けない
* 空白や追加の記号は許可しない

ソフトウェア側は、表示時には常にチェックサム付き形式で出力し、入力時はチェックサムなし（`0.0.123`）とチェックサム付き（`0.0.123-vfmkw`）の両方を受け付けます。
入力がフォーマットに合わない場合やチェックサムが一致しない場合はエラーとします。

正規表現による入力検証も定義されており、出力時は必ずチェックサム付きの正規表現に一致するよう生成されます。

### チェックサム生成アルゴリズム

1. アドレスを配列化（`.`は10として扱う）
2. レジャーIDに6バイトのゼロを付加した配列を作成
3. 偶数・奇数位置の数字の合計（mod 11）や、全桁の加重和（$mod 26^3$）など複数の要素を算出
4. レジャーID由来の加重和（$mod 26^5$）を計算
5. これらを組み合わせて数値化し、最終的に $mod 26^5$ の範囲で変換
6. 1,000,003という素数で掛け合わせて順序を攪拌（最終置換）
7. base26（a〜z）で5文字に変換して完成

このアルゴリズムにより、小さな変更でもチェックサムが変わり、特に最初の2文字に変化が出るよう設計されています。

## 互換性

このチェックサム機能は、既存のアドレス形式との互換性を保つために必須ではなく、あくまでオプションとして導入されます。
そのため、現在の「**チェックサムなし**」形式のアドレスも引き続き有効であり、既存のシステムやアプリケーションが即座に影響を受けることはありません。
ただし、推奨される運用としては、全てのソフトウェアがアドレスを表示する時にチェックサム付き形式を採用することです。
これにより、利用者はアドレスの視認性と安全性を同時に向上させることができます。

## セキュリティ

この仕組みは、誤ったアドレス入力による資金損失を未然に防ぐという点で、Hederaネットワークのセキュリティ向上に寄与します。
チェックサムは完全に衝突（同じチェックサムを持つ異なるアドレス）を避けることはできませんが、**HIP15**で定義された関数は、暗号学的な擬似乱数関数（PRF）よりも実用上優れた性質を持ちます。

一般的なPRFであれば、`0.0.x` 形式のアドレスを1から順に計算すると、約3,500個目で衝突が発生する可能性があります。
しかし、この関数では衝突が発生するのはその10倍以上後であり、実際には `0.0.39004-gyebe` と `0.0.10690-gyebe` が最初の衝突例です。
さらに、この2つのアドレスは大きく異なるため、入力ミスで片方がもう一方になる可能性は低いと考えられます。
また、より現実的なタイプミス（例：`0.0.3904` と入力する）では異なるチェックサム（`-csury`）が生成されるため、規格準拠のアプリケーションであれば誤りとして検出できます。

## 引用

This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](https://github.com/hiero-ledger/hiero-improvement-proposals/blob/main/LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)

## 最後に

今回は「Hederaアドレスに5文字のチェックサムを追加し、入力ミスや類似アドレスによる誤送金を防ぐ仕組みを提案している**HIP15**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4