Ink & Switch發(fā)布bijou64：每個數(shù)字僅一個字節(jié)表示，解碼速度是LEB128的10倍

“我們不添加更多檢查，而是讓非規(guī)范編碼根本不可能存在。”Brooklyn Zelenka在設(shè)計bijou64時這樣定調(diào)。Ink & Switch這個研究實驗室，正式把這套名為bijou64的可變長度整數(shù)編碼推了出來：每一個整數(shù)只對應(yīng)唯一一種字節(jié)序列，從結(jié)構(gòu)上消滅了一類存續(xù)多年的安全漏洞，同時把解碼速度提至傳統(tǒng)標(biāo)量LEB128的10倍。

要理解這事兒為什么重要，得先看看LEB128留下的爛攤子。

LEB128的“多重宇宙”是怎么撞出安全漏洞的
傳統(tǒng)變長整數(shù)編碼LEB128，把整數(shù)切成7個比特一塊，每個字節(jié)用最高位做“延續(xù)標(biāo)記”。同一個數(shù)字，能寫出好幾種字節(jié)序列——零既可以塞進一個字節(jié)0x00，也能寫成0x80 0x00（前導(dǎo)字節(jié)亮起繼續(xù)位，后面跟著一個零塊）。在需要密碼簽名、內(nèi)容尋址或分布式共識的協(xié)議里，這種冗余編碼等于直接給攻擊者遞上一把鑰匙。只要協(xié)議要求在簽名前做“規(guī)范化檢查”，而開發(fā)者要么忘了寫，要么為了性能故意跳過這些額外驗證，就會出現(xiàn)類似PKCS#1 v1.5填充缺陷、GnuTLS證書偽造、比特幣交易延展性的歷史級漏洞。Zelenka說得很直白：這群bug就是這么來的，規(guī)范寫得再清楚也沒用，實際實現(xiàn)中校驗經(jīng)常被省略或“優(yōu)化掉”。

bijou64的解法：讓歧義從鐵軌上就被拆掉
bijou64沒有在編碼之外另加一層“規(guī)范檢查”，它直接改造編碼格式本身。整個方案靠兩條規(guī)則撐起來：
1. 直接值段（0–247）：字節(jié)落在這個區(qū)間，就直接解釋成整數(shù)，沒有元數(shù)據(jù)，沒有拖延。
2. 標(biāo)簽字節(jié)段（248–255）：這些高值字節(jié)宣告后面跟著幾個字節(jié)的有效載荷，每個長度檔都預(yù)設(shè)了一個固定偏移量，保證短編碼不可能被padding成長編碼。
載荷是一段連續(xù)的大端序整數(shù)，編譯器能直接把它轉(zhuǎn)成一條加載指令加一次字節(jié)交換。這樣一來，根本不存在“零有兩種寫法”這類問題，非規(guī)范編碼在物理上就不成立。

快10倍不靠魔法，靠去掉分支和掩碼
Benchmark數(shù)據(jù)讓標(biāo)量LEB128很難堪。在x86和ARM平臺上，bijou64解碼小數(shù)字的速度大約是LEB128的兩倍，大數(shù)字則可以拉到8到10倍。秘密就在于LEB128的“延續(xù)位掃描”——傳統(tǒng)的解碼器得繞著每個字節(jié)做位掩碼和分支跳轉(zhuǎn)，而bijou64解碼變“一口氣加載+字節(jié)翻轉(zhuǎn)”的連續(xù)操作，CPU流水線不再被分支預(yù)測打亂。編解碼器徹底告別了“查一字節(jié)、看最高位、再查下一字節(jié)”的笨循環(huán)。

社區(qū)聲音：SIMD時代，這個對比夠公平嗎？
Hacker News上的技術(shù)討論馬上揪住了比較基準(zhǔn)。一位評論者搬出BONJSON格式的benchmark懟過來：只對標(biāo)標(biāo)量解碼器是在掩耳盜鈴，高性能解析早就全面擁抱SIMD了；測試證明，一旦換上SIMD指令，ULEB128或者哨兵值永遠(yuǎn)贏，因為并行度完全不在一個量級，“真正的諷刺是，就連SIMD文本解析都可能比你快，SIMD就是這么暴力”。另一位評論者dzaima則瞄準(zhǔn)了最核心的安全宣傳，質(zhì)疑bijou64是否真的堵死了所有攻擊面，指出新格式實際上“縮小了需要檢查的范圍”，安全性可能要打個問號。

bijou64的出現(xiàn)不是要一腳踢開LEB128，而是在某些對規(guī)范唯一性有剛性要求、又受不了軟校驗性能痛感的系統(tǒng)里——比如Ink & Switch自家的Subduction同步協(xié)議——提供一種“構(gòu)造即正確”的選項。至于它能不能成為通用層的默認(rèn)編碼，那得看整個社區(qū)愿不愿意為了絕對安全自洽性，重新審視那些藏在SIMD加速下的舊對比邏輯了。