已上線
Vercel 正式部署
最新 Turso／R2 版本已推上 private GitHub，正式網址建置成功並穩定回應。
Latest Update · 2026.07.17
第八輪：Base Sepolia 真實 EAS 已上鏈
Vercel、Turso、Cloudflare R2、Resend 與 Base Sepolia EAS 已全部接通並完成真實 E2E。第一筆 PDF Hash 已成功上鏈，下一個主要里程碑是數位憑證皮夾、v2 refUID 與正式營運治理。
已上線服務
5
Vercel · Turso · R2 · Resend · EAS
完整流程步驟
3 / 8
SHA-256、真實上鏈與持久化已完成
部分完成步驟
5 / 8
主要缺皮夾、v2 驗收與法律定稿
已實測
Turso＋R2 持久化
案件與版本進 Turso；加密 PDF 進私人 R2 Bucket，不再依賴 Vercel 暫存磁碟。
已實測
Resend Email OTP
正式環境已成功寄出登入驗證碼，OTP 頻率限制與 Session 流程正常。
已上鏈
真實 EAS E2E 驗收
已完成 PDF Hash 上鏈、交易確認、鏈上解碼與公開驗證查詢；UID 與 Tx Hash 可由第三方瀏覽器查驗。
What Remains
現在還沒完成的六件事
基礎設施與 Base Sepolia 真實 EAS 已經上線；接下來的缺口集中在外部串接、法律確認、v2 修訂驗收與正式營運安全。
數位憑證皮夾沙盒
待資料取得 WALLET_API_BASE、ACCESS_TOKEN 與 VERIFIER_REF，取代目前 Mock 流程。
負責／依賴：外部申請
合作方遺囑產生器串接
待規格確認 PDF 交付方式、API／Webhook、案件識別與錯誤回報格式。
負責／依賴：雙方協作
法律欄位與聲明定稿
待確認由劉律師確認欄位 v3、草稿條文、法定形式提醒及高風險欄位處理。
負責／依賴：法律確認
修訂安全與 v2 鏈上驗收
高優先修訂前要求強本人再驗證，實際建立 v2，並確認 EAS refUID 正確指向 v1。
負責／依賴：技術＋法律
鏈上營運與主網決策
上線前補上交易重試、確認數監控、專用 RPC／錢包與 Gas 告警，並決定何時由 Base Sepolia 切換 Base 主網。
負責／依賴：技術＋營運
監控、備份與金鑰治理
尚未完成補上錯誤告警、Turso／R2 備份演練、MASTER_KEY 離線備份與金鑰輪替程序。
負責／依賴：營運
01 — Complete Flow
完整流程與目前進度
點選任一步驟，下方會展開該步驟的輸入、處理、輸出與目前仍缺少的部分。
● 已完成 ● 部分完成 ● 尚未完成
01 · 本人登入與案件綁定
角色：立遺囑人 × 身分驗證服務
I Input
Email＋OTP，或數位憑證皮夾
使用者提供可驗證的身分憑據。
P Process
驗證身分並建立安全 Session
把登入者與遺囑案件的所有權綁定。
O Output
已驗證的 userId 與案件權限
後續產生、下載與修訂都依此授權。
目前差距：Email OTP 已透過 Resend 在正式 Vercel 實測寄送成功，使用者資料由 Turso 持久保存，十分鐘 5 次的頻率限制也已完成；Production 的 ALLOW_DEMO 與開發測試入口已關閉。尚缺數位憑證皮夾正式沙盒，以及修訂前強制再驗證。
02 · 產生或接收遺囑結果
角色：遺囑產生器 × 本平台
I Input
遺囑欄位資料，或合作方產生的 PDF
目前可由欄位 v3 組成全文草稿；外部串接方式仍待約定。
P Process
產生草稿與 PDF，並鎖定確切位元組
草稿會附於 PDF；鎖定檔案可避免 metadata 改變 Hash。
O Output
Canonical PDF（存證版本）
這份檔案會成為後續所有驗證的基準。
目前差距：欄位 v3、遺囑全文草稿產生器與 PDF 附錄已完成；若要改接協會既有產生器，仍需完成 API／Webhook 介面，草稿條文也要由律師定稿。
03 · 計算 SHA-256
角色：本平台雜湊服務
I Input
Canonical PDF 的完整位元組
必須是使用者實際下載與保存的同一份檔案。
P Process
執行 SHA-256 雜湊演算法
即使只改一個位元組，也會得到完全不同的結果。
O Output
0x 開頭的 64 位十六進位 Hash
供平台資料庫、區塊鏈與驗證頁一致比對。
目前差距：核心功能已完成；正式串接時仍要確保合作方交付的是完全相同的 PDF bytes。
04 · 本人確認與簽署紀錄
角色：立遺囑人 × 本平台
I Input
使用者確認、姓名、PDF Hash
確認目前看到的文件就是準備存證的版本。
P Process
建立簽署與操作紀錄
記錄誰、何時、確認了哪一個 Hash。
O Output
Signature record ＋ audit event
作為上鏈前的操作證據與稽核軌跡。
目前差距：勾選確認、簽署紀錄、audit log、案件證據鏈時間軸與管理後台已完成；尚未定義符合法律需求的電子簽章或再次身分驗證強度。
05 · 鏈上存證
角色：本平台 Attestor × Base Sepolia × EAS
I Input
PDF Hash、版本、上一版 refUID
PDF 全文、姓名與資產內容都不上鏈。
P Process
送出 EAS Attestation 交易
等待交易確認並取得永久可查的鏈上紀錄。
O Output
Tx Hash、Attestation UID、時間
可由第三方區塊鏈瀏覽器獨立查詢。
目前差距：Base Sepolia 真實 EAS 已完成：Schema 已註冊，Production 環境變數已生效，第一筆 PDF Hash 已取得可公開查驗的 Tx Hash 與 Attestation UID，鏈上解碼也與原始 Hash、docType、version 完全一致。接下來是營運強化：交易失敗重試、確認數監控、專用 RPC／錢包與 Gas 告警；是否切換 Base 主網仍待決策。
06 · 保存文件與版本索引
角色：Cloudflare R2 × Turso
I Input
加密 PDF、Hash、UID、userId
同一案件可以有 v1、v2、v3 等多個存證版本。
P Process
加密保存並建立版本關聯
由資料庫判斷哪一版最新、哪一版已被取代。
O Output
可長期查詢的案件與版本資料
支援本人下載、稽核、修訂與公開驗證。
目前差距：Vercel＋Turso＋Cloudflare R2 已正式上線，PDF 會先以 AES-256-GCM 加密再進 R2，案件、金鑰信封與版本索引存進 Turso；正式 E2E 已驗證上傳、下載與 SHA-256 完全一致。剩餘的是監控告警、備份策略與金鑰輪替等營運強化。
07 · 公開驗證 PDF
角色：驗證者 × 瀏覽器 × 區塊鏈
I Input
驗證者手邊的 PDF
PDF 留在瀏覽器，文件內容不必上傳。
P Process
本機算 Hash，查鏈並判讀版本
同時確認是否存在、是否為最新版本。
O Output
相符／不相符＋存證資訊
相符代表檔案與該次存證逐位元組一致。
目前差距：驗證頁、瀏覽器雜湊、Turso 正式查詢與真實 EAS 存證資料回傳已完成，實測可顯示 Base Sepolia 的 UID、Tx Hash 與最新版狀態；尚未在每次公開驗證時直接讀取 Base／EAS，與 Turso 做即時交叉驗證。
08 · 本人修訂與新版存證
角色：立遺囑人 × 版本管理服務
I Input
本人登入、既有案件、修改後內容
只有案件所有者才能建立下一個版本。
P Process
建立 v2，重走 PDF → Hash → 存證
新 Attestation 以 refUID 指向上一版。
O Output
最新版 v2，v1 標記已被取代
舊 PDF 仍可驗證，但會提示已有更新版本。
目前差距：版本機制、所有權檢查、全文草稿與舊版取代提示已有；v1 真實 EAS 已完成且 refUID 正確為空值。尚缺修訂前的強本人再驗證，以及實際建立 v2、用 refUID 指向 v1 的鏈上驗收。
02 — Privacy Boundary
什麼留在系統？什麼寫上區塊鏈？
最重要的隱私界線：遺囑內容不上鏈，公開的只有無法反推內容的 SHA-256 數位指紋。
Off-chain
鏈下：私人資料區
- 完整 PDF 與遺囑內容
- 本人身分、登入與案件所有權
- Turso 案件索引與 R2 加密 PDF
只傳 Hash
On-chain · Live Testnet
鏈上：Base Sepolia EAS
真實 EAS 已上鏈並完成第三方查驗；目前使用 Base Sepolia 測試網，尚未切換 Base 主網。
- PDF 的 SHA-256 數位指紋
- 交易時間與 Attestation UID
- 新版指向上一版的 refUID
03 — Public Verification
驗證頁實際在做什麼？
PDF 留在使用者的瀏覽器中，只送出算好的 SHA-256；目前已能比對 Turso 的正式版本資料並顯示真實 Base Sepolia EAS 存證。下一步是每次驗證時直接讀鏈，與平台資料交叉核對。
選擇手邊 PDF
使用者選擇當初下載保存的文件，檔案不離開裝置。
瀏覽器計算 SHA-256
任何一個字、metadata 或位元組改變，都會產生不同指紋。
比對存證與版本
確認 Hash 是否存在，以及該文件是否仍為最新版本。
驗證一致
這份 PDF 與該次存證逐位元組完全相同；再顯示存證時間、UID 與版本狀態。
驗證不一致
文件曾被修改、尚未完成存證，或不是當初用來存證的那一份 PDF。
04 — Revision Loop
修改不是覆蓋，而是建立新版本
舊版與原存證保留，建立新版後再走一次 PDF、Hash 與存證流程；版本機制已完成，但修訂前的強本人再驗證與真實 refUID 尚未完成。
既有存證
v1 · PDF ＋ Hash A
歷史紀錄保留，不修改、不刪除。
本人驗證
建立修訂
修改內容並產生 v2
產出新的 PDF，重新計算 Hash B。
重新存證
最新存證
v2 · Hash B ＋ refUID
v2 成為最新版；驗證 v1 時提示已被取代。
For Legal Review
給劉律師確認的關鍵界線
雜湊一致只能證明「這份 PDF 與某次存證的位元組完全一致」，以及該存證的時間與鏈上紀錄；它本身不等於確認立遺囑人的意思能力、法定形式或遺囑法律效力。
目前新增的「遺囑全文草稿」也是撰寫參考：若採自書遺囑，仍須由立遺囑人親筆書寫全文、記明日期並親自簽名。草稿條文、身分驗證強度與簽署程序仍應由律師定稿。