太長不看
地址投毒攻擊之所以有效，是因為人們只會驗證地址的前綴/後綴。本文提出了一種僅需錢包/用戶界面即可實現的機制：接收方共享一個短暫的接收代碼，發送方的錢包使用Keccak256(address || code)來生成動態校驗和指紋。如果發送方不小心粘貼了一個被投毒的相似地址，驗證就會失敗，因為攻擊者不知道該代碼。
動機：常見的習慣中毒伎倆
實際上，很少有用戶會逐個驗證 40 個十六進制字符。主要的工作流程（尤其是在複製最近活動時）是：
- 檢查前4-6個字符
- 檢查最後4-6個字符
- 假設中間部分沒問題
投毒攻擊直接針對這一點：
- 攻擊者生成一個與常用收件人地址具有相同可見前綴/後綴的地址
- 攻擊者發送一個值為 0 的/塵埃的轉賬，使仿冒品出現在“最近”歷史記錄中。
- 用戶複製了錯誤的條目，前綴/後綴匹配，資金被髮送給了攻擊者。
這主要是用戶界面/人工驗證方面的失誤，而不是協議漏洞。
直覺：以太坊轉賬缺乏“二次確認”。
在許多傳統的支付流程中，實際上需要確認兩件事：
- 目的地標識符（賬號）
- 獨立的確認信號（收款人姓名/確認提示）
以太坊擁有強大的目標標識符（地址），但當用戶向原始的0x…地址轉賬時，通常缺少第二重確認。因此，我們的目標是添加一個輕量級的第二重驗證因素：
- 鏈下（僅限錢包）
- 便宜（無需額外的鏈式步驟）
- 投毒者很難預料到具體的付款金額。
背景：校驗和大小寫是什麼，以及為什麼它不足以滿足要求。
錢包地址通常會顯示大小寫混合的“校驗和”地址。其基本原理是：
- 根據地址計算哈希值
- 使用哈希值中的部分內容來確定十六進制字母
a–f的大小寫。 - 如果地址發生變化，大小寫規則很可能不再有效，這有助於發現拼寫錯誤。
這裡廣泛使用的以太坊約定是EIP-55校驗和封裝。
投毒限制：此外殼是每個地址固定的，並且可公開計算，因此投毒的類似物也可以顯示為“有效的校驗和”形式。
建議：使校驗和大小寫取決於接收方提供的代碼（動態指紋）
輸入
addr：收件人地址（20 字節）-
code：簡短的接收者代碼（字符串；建議使用一次性或短期代碼）
哈希
我們計算如下：
H = Keccak256(addr\_bytes || code\_utf8)
H = K e c c a k 256 ( a d d r _ b y t e s | | co d e _ u t f 8 )
其中addr_bytes是 20 字節的地址， code_utf8是接收器代碼的 UTF-8 編碼。使用 20 字節的地址可以確保連接邊界清晰明確。
套圈規則
將地址渲染為十六進制（照常）。對於每個字符：
- 數字
0–9保持不變 - 字母
a–f根據H的連續比特位進行大寫/小寫轉換。
（與 EIP-55 精神相同，但使用上述H）
結果：相同的底層地址現在具有特定於代碼的大小寫指紋。
流動
接收者（愛麗絲）
- Alice 生成一個接收代碼（建議使用錢包生成的代碼），例如
lamp-snow-47。 - 錢包顯示地址，其大小寫源自
H - Alice 與發件人共享（地址，代碼） 。
發件人（鮑勃）
- 鮑勃粘貼了地址。
- 鮑勃輸入接收器代碼。
- 錢包重新計算並驗證外殼指紋：
- 匹配→ 已驗證
- 不匹配→ 警告/阻止（錯誤代碼、錯誤地址或可能存在惡意代碼）
其目的是讓用戶依靠清晰的已驗證/未驗證狀態，而不是通過目視檢查外殼。
為什麼這樣做可以減輕中毒風險（針對目標場景）
當用戶不小心從歷史記錄中選擇了相似的前綴/後綴時，投毒攻擊就會成功。使用接收代碼：
- 攻擊者仍然可以偽造相似的地址，並將其添加到用戶的歷史記錄中。
- 但攻擊者無法使被汙染的地址在接收方的代碼下驗證通過。
- 因此，“從歷史記錄中複製錯誤地址”不再是悄無聲息的成功，而變成了確定性的驗證失敗。
期待您的反饋——特別是關於用戶體驗方面的權衡取捨，以及我可能忽略的威脅模型或實現中任何潛在的缺陷。提前感謝您的反饋！
