編按：本文綜合整理自 GitHub: valimised/ivxv、Hacker News 討論串（224 分 / 96 則留言），以及 State Electoral Office of Estonia 公開說明，並加入 Siami 編輯部觀點與分析。
事件：愛沙尼亞把選舉源碼放上 GitHub
10 月 17 日，Hacker News 用戶 theanonymousone 把一個早就存在、但 2025 年 10 月才剛更新過的 GitHub 倉庫頂上首頁：valimised/ivxv。這個倉庫藏著的是 愛沙尼亞國家網路投票系統 IVXV 的完整 Go + Java 源碼，由國家選舉辦公室（State Electoral Office, valimised.ee）長期維護，分支名稱直接叫做 published，意思是「這份就是選舉當天跑的程式碼」。
這則貼文迅速累積 224 分、96 則留言，引發了資安社群的老問題再起爭論 — 公開源碼究竟能不能解決電子投票的信任問題？
愛沙尼亞的數位選舉實驗：20 年、44% 投票率
愛沙尼亞從 2005 年開始在全國性國會選舉常規使用網路投票（i-voting），是全球唯一在具有法律約束力的選舉中長期常規使用電子投票的國家。ZDNEt 2019 年報導指出，當年國會選舉中 44% 的選票是透過網路投下的，這個數字在歐洲議會選舉與地方選舉中也持續維持在 30-50% 區間。
這次公開的 IVXV 系統並不是單純的「展示版」，倉庫 README 明確寫道：
“The repository is not used for active development, but will be kept up to date, so the code that can be found here is the code that is used for election.”
意思是 — 程式碼不是在其他地方開發、只挑漂亮的部分公開，而是 選舉當天跑什麼，這個 repo 就是什麼。
技術規格：Go + Java、Debian 安裝包、Submodule 管理
從 repo 內容看，IVXV 是個有完整部署流程的系統：
- 投票端 (collector)：Go 1.9 編譯，部署為 Debian 套件 (
.deb) - 管理後台：Java 11
- 外部相依：用 Git LFS + submodule 管理，每次建置前要
make external拉外部依賴 - 模組劃分：
voting/collector-admin/verification/auditor/proxy/processor等 20 個子模組，從投票接收集計到獨立驗證全包 - 分支策略：只有
master跟published，新版本只在選舉週期發布
最新一次 commit 是 2025 年 10 月 3 日的 KOV2025（municipal election），再上一次是 2024 年 5 月的 EP2024（歐洲議會選舉）。HN 用戶 Karliss 整理的時間軸 — 國會選舉每 4 年一次，下一輪 RK2027 預計在 2027 年初，所以「一年沒更新」不是 bug，是設計。
HN 社群爭論的核心：源碼公開 ≠ 系統可信
留言區兩派聲音涇渭分明：
懷疑派的代表是 phtrivier 的關鍵提問：
“假設我用網路投票投給候選人 A，最後 A 以 764 票差距落選。我要怎麼相信我的那一票真的有被算進那 764 票，而不是某個 RNG 隨機挑出來的數字？”
這是電子投票永遠的核心難題 — 即使源碼公開、即使你讀得懂 Go 程式碼，你也無法離開投票機去親自驗算那張選票是否被計入。
chopin 更直接：
“公開源碼不等於可信。這正好說明為何電子投票本質上是個壞主意 — 你被要求信任一個你根本無法驗證的系統。”
辯護派則指出，IVXV 的設計是接受這個限制、改用「可重複驗證的審計流程」補上：
- 投票者可以重複投票多次，以最後一次為準（用來防止「被迫投票」與買票）
- 選舉結束後，獨立機構能用
verification模組驗證計票過程 - 源碼公開讓外部資安研究人員能在事前挖漏洞，而不是被動等出事
為什麼這件事重要
這不只是「程式碼公開」這個動作本身，而是愛沙尼亞用 20 年的持續運作 證明一件事：電子投票不必是黑箱。即使你不信任 IVXV 的具體實作，這個國家堅持每年把「選舉當天跑的程式碼」放在 GitHub 上公開審視，已經為全球電子投票治理立下了一個參考基準。
對 Siami 讀者而言，這個 repo 有三重價值：
- 資安研究的實戰教材：473 stars / 65 forks 還在持續累積，這是少數能拿到「真實在運作的政府系統源碼」的機會。
verification模組的auditor子目錄尤其值得研究。 - 政策面觀察標的：愛沙尼亞選舉辦公室定期更新
published分支的模式（2017 RC → 2019 → 2021 → 2023 → 2024 → 2025 → 2027 預定），是政府 IT 透明度的具體落地範例。 - 對照組：相較於多數國家連「選舉設備型號」都不公開，能拿出完整 Go/Java 源碼 + commit 歷史 + 文件站的 IVXV 仍屬異類。
數據解讀
| 指標 | 數值 |
|---|---|
| HN 分數 | 224（進入首頁前 10 名） |
| HN 留言數 | 96 則 |
| GitHub stars / forks | 473 / 65 |
| 程式碼主語言 | Go（collector）+ Java 11（admin） |
| 最後 commit | 2025-10-03（KOV2025 地方選舉版本） |
| 公開歷史 | 2017 開源以來 7 個 commit epoch，每 2-4 年一次 |
| 主要維護者 | Sven Heiberg（State Electoral Office） |
值得追蹤的後續指標：
- 2027 RK2027 國會選舉後是否如期發布新版（這會是下一個「真實驗證點」）
- Fork 社群是否出現過任何對源碼的公開漏洞揭露（截至目前未見）
- 其他國家（尤其是歐盟成員）是否開始引用 IVXV 作為選舉 IT 透明度的參考
Siami 觀點
愛沙尼亞這套模式的真正價值，不在「程式碼被讀過幾次」，而在於它建立了一個 可被監督的治理流程：版本固定、發布時機明確、誰負責寫都寫在 commit metadata。對一個科技菁英讀者，這比任何「用區塊鏈保證選舉公正」的炒作都更務實 — 政府 IT 透明度的第一步，永遠是把源碼放出來讓人看，而不是保證它完美無瑕。
至於「源碼公開後電子投票是否就安全了」這個更深的問題 — 答案向來不是 yes 或 no，而是「至少我們現在有東西可以吵，而不是吵不出東西」。
網友熱門留言 (5)