📜 [專欄新文章] Unirep介紹: 使用ZKP的評價系統

✍️ Ya-Wen Jeng

📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Unirep是什麼? 怎麼用?

Photo by Raphael Lovaski on Unsplash

UniRep 是一個使用零知識證明(Zero-knowledge Proof)而達到具有隱私保障的評價 (reputation) 系統。使用者有權利享有多個暫時性的身份，但又同時能提出證明，讓其他人可以驗證評價是否符合自己宣稱的數量。此外，使用者也無法拒絕接收對自己不利的評價。

想像一個情境：如果Alice是Airbnb的使用者，Alice常常透過Airbnb租房，且Alice曾經獲得獲得許多Airbnb房東的好評；有一天Alice想透過Booking.com訂房，http://xn--alicebooking-kt4so6lvyab96x7trhi5b54x.com/，所以在Booking.com上沒有任何評價，萬一Booking.com的房東不想把房子租給來路不明的客人，那Alice要如何向Booking.com的房東證明她其實都是用Airbnb租房，且獲得許多好評？

Alice雖然可以透過截圖或公開自己的資訊向Booking.com的房東證明自己擁有這些好評，但這樣Alice的隱私或許會被洩漏，例如Alice不想讓Booking.com的房東知道自己去過哪些地方、住過哪些民宿；或者Alice有可能偽造截圖，或者偽造評價，那Booking.com的房東要如何相信Alice所提供的證明文件是真的來自Airbnb的房東？除此之外有沒有更彈性的方式，Alice可以選擇性地向Booking.com的房東證明，自己至少有10個好評，但不透露自己總共有多少好評？

Photo by Andrea Davis on Unsplash

使用Unirep協定就可以解決這個問題。UniRep 取名自 Universal Reputation，希望透過區塊鏈上智能合約的可互用性 (interoperable，指智能合約容易被多方呼叫且容易透過智能合約與對方互動)，讓不管是Airbnb的房東、Booking.com的房東或是Alice都能很容易地透過Unirep的智能合約與對方互動，且透過零知識證明的方式，讓Alice的評價具有隱私的保障，Alice不用明確地向Booking.com的房東說這些評價是怎麼獲得、是什麼時候獲得，也可以彈性的證明自己至少有多少好評，或者最多有多少差評。

密碼學

Unirep主要用到的密碼學方法有

雜湊函數 hash：若有一個雜湊函數 f(x) = y 則由x可以很輕易的用f算出y，但從y推回x是幾乎不可能的，且要找到兩個不同的x對應到相同的y也是幾乎不可能的(沒有碰撞問題)。

零知識證明 zero-knowledge proof：可以將複雜的運算邏輯轉成容易驗證且具有隱私保障的驗證問題，使用者只要將變數輸入，這個零知識證明的演算法就會產生對應的證明且計算出對應的結果，使用者只要將此證明和運算結果輸入驗證的程序中，其他人就能驗證使用者是不是提出正確的證明，若驗證成功，則驗證者就能相信提出證明者高機率擁有正確的知識，也就是在計算證明時的輸入變數。

ZKP Proof System

ZKP Verification System

Semaphore：semaphore 是設計為可以用零知識證明驗證的身份認證系統。Unirep 中用來產生私鑰 (identity) 和公鑰的 hash 值(identity commitment)，讓使用者不必公開 identity 仍能透過零知識證明驗證其公私鑰的對應性。

雜湊樹 Merkle trees：Unirep 中大量運用雜湊樹的方式確保評價紀錄，而其中用到的雜湊樹又分兩種：Incremental merkle tree 和 Sparse merkle tree

Incremental merkle tree: 從 index 0 開始依序插入雜湊樹中的樹葉。為了使 ZKP 的 circuit 大小固定， Unirep 中使用固定高度的 Incremental merkle tree。

Sparse merkle tree: 在特定的 index i 插入樹葉

Incremental merkle tree and sparse merkle tree

UniRep中用到的名詞定義

Epoch

指一段特定的時間，例如7天

UniRep 的 Epoch 從 1 開始計算，7天過後Epoch數加一，即 Epoch 變為 2

Epoch Key

每個使用者在每個 Epoch 都能產生 n 把 Epoch key，用來收取評價 epoch_key = hash (id, epoch, nonce)

id: 這裡指用 semaphore 產生的 identity

epoch: 表示這是在第幾個 epoch 產生的 epoch key

nonce: 若 Unirep 規定使用者能在一個 epoch 產生 5 把 epoch key，則使用者可以選從 0 到 4 為此 nonce

因為雜湊函數的性質，算出來的 epoch key 很難推回原本的 id, epoch, nonce， 所以看到 epoch key 並不能推回使用者是誰。

以Alice為例，當Alice住完Airbnb，房東會透過 epoch key 給予 Alice 評價，但房東無法知道 Alice 在同個 epoch 的其他 epoch key 是哪一把，也無法知道 Alice 在別的 epoch 獲得的評價，除非 Alice 在這個 epoch 重複使用同一把 epoch key 收取評價。

User 使用者

用 semaphore 產生 identity 並使用此 identity 註冊的使用者

使用者是接收評價、證明評價、或是花費評價的人，用 epoch key 跟其他人互動，因為 epoch key 會隨著 epoch 增加而改變，所以對使用者來說每個 epoch 能產生的 epoch key 都不同，具有保護隱私的效果。

在上面的例子中使用者指的是 Alice, Bob, Airbnb 的房東, Booking.com的房東

Attester 證人

用 Ethereum address 或 smart contract address 註冊的用戶

是會被使用者記錄下來的評價給予者

Unirep 會給這些 address 一個 attester ID，而這個 attester ID 不會隨著 epoch 增加而改變，使用者可以知道這個評價是來自哪一個 attester。

在上面的例子中指的是 Airbnb 跟 Booking.com，因為 attester ID 不變，所以使用者可以證明這些評價是來自於 Airbnb 或是 Booking.com

User State Tree (UST)

是一 Sparse merkle tree

每個使用者都有自己的 User State Tree，其中樹葉表示所收到的評價的hash值，而葉子的 index 表示 attester ID，UST 樹葉的定義為

USTLeaf = hash(posRep, negRep, graffiti)

例如 Airbnb 的 ID 是1，Booking.com 的 ID 是 3，那 Alice 的 User State Tree 中 index 為 1 的地方會有自己在 Airbnb 獲得的總評價的 hash 值，而 index 為三的地方則為空的評價。另一個使用者 Bob 的 User State Tree 亦同，在 index 為 1 的地方會有自己在 Airbnb 獲得的評價，在 index 為 3 的地方會有自己在 Booking.com的評價。

Global State Tree (GST)

是一固定樹高的 Incremental merkle tree

Global State Tree 的葉子到樹根都是公開的資訊，當有使用者註冊或者更新 User State Tree 時會在 Global State Tree 裡新增一個新的樹葉，GST 樹葉的定義為：

GSTLeaf = hash(id, USTRoot)

先送出的樹葉先插入到較前面的 index，之後的樹葉依序插入 GST 中。

以 Alice的例子來說，當 Alice跟 Bob註冊 Unirep時，都會產生一個 GST的樹葉，更新 GST的樹根，若 Alice先註冊，則 Alice的 index會較 Bob前面。注意，這邊的 Airbnb 和 Booking.com 等 attester 並不是用這棵 Global State Tree註冊。

Epoch Tree

是一個 Sparse merkle tree

Epoch Tree 跟 Global State Tree 一樣從葉子到樹根都是公開的資訊，Epoch Tree 中樹葉的 index 為 epoch key，而樹葉的值為該 epoch key 的 sealed hash chain

每個 epoch key 都有一個 hash chain，hash chain 的定義為

hashedReputation = hash(attestIdx, attesterID, posRep, negRep, graffiti)hashChain[epochKey] = hash(hashedReputation, hashChain[epochKey])

此 hash chain 是為了防止使用者漏收了哪一筆評價，如果使用者少收了其中一筆評價，則 hash chain 的結果會完全不同。最後驗證時如果其中一個 epoch key 的 hash chain 改變，會造成 epoch tree 樹根跟原本的 epoch tree 的樹根不同。

而 Sealed hash chain 是在每個 epoch 結束後，Unirep 智能合約會再將這條 hash chain 再 hash 一次

sealedHashChain[epochKey] = hash(1, hashChain[epochKey]) isEpochKeyHashChainSealed[epochKey] = true

需要再把這條 hash chain 封起來的用意是，避免這把 epoch key 過了這個 epoch 之後再繼續接收評價，所以 epoch tree 會用這個 epoch key 最後的 sealed hash chain 去計算樹根。

Nullifier

中文翻譯為註銷符，當我們要防止一件事情重複發生時，就可以使用這個 Nullifier

Unirep 中使用到 Epoch key nullifier：此 nullifier 是用來限制使用者不能在不同的 epoch 使用重複的 epoch key 去收取評價，也不能被其他使用者使用；此外也可以用來檢視使用者是否重複執行 UST 的更新

Nullifier 也用 hash 計算，但多使用一個 domain 變數，避免與 epoch key 產生相同的 nullifier 而洩露自己擁有的 epoch key，也可以用不同的 domain 產生不同用途的 nullifier

epochKeyNullifier = hash(EPOCH_KEY_DOMAIN, id, epoch, nonce)

Epoch Transition

一個 epoch 結束過後，要透過 epoch transition 的步驟，更新 Unirep 及使用者的狀態

其中要做的事包含將智能合約上的 epoch 數加一，還有將所有 epoch key 的 hash chain 封起來

接著使用者就可以執行 User State Transition 更新自己的 UST

User State Transition

到下一個 epoch 後，使用者可以透過自己的 identity，找出自己在前一個 epoch 所有的 epoch key，並根據每把 epoch key 收到的評價更新到自己的 UST，最後計算出最新的評價狀態，產生一個 GST的樹葉，插入 GST 中 (如同註冊時一樣)。

使用者之後如果要花費評價或者產生下一個 epoch 的 epoch key 時，因為必須確認自己的 UST 在當前的 epoch，所以需要經過 User State Transition 確保自己有一個 GST 的樹葉在 GST 中。

Unirep 協定

有了 Unirep 的名詞定義後，接著介紹 Unirep 是如何運作的。

註冊

Unirep 的 user 和 attester 的註冊方式不同：

User signup and attester signup in Unirep

User

User 透過 semaphore 產生 identity 和 identity commitment，identity 就如同私鑰，identity commitment 就如同公鑰

將 identity commitment 和預設的 UST 樹根經由 hash 計算得 GST 的一個樹葉

若使用者要證明自己在某個 epoch 有註冊或者有更新自己的 UST，則證明自己是 GST 的某一個樹葉，利用零知識證明的方法，輸入 identity、UST 樹根，還有 merkle tree 中要計算 hash 值的相鄰節點，則最後可得到一個 GST 的 root，其他人可以驗證這個 GST 的 root 是否符合這顆公開的 GST。

Attester

Attester 則是用自己的錢包，或者用智能合約的地址註冊，呼叫 attester sign up 的 function 後，Unirep 會指定一個 attester ID 給這個地址，往後 attester 用相同錢包或合約地址給予評價時，Unirep 會檢查此地址是否被註冊，若有註冊則可以給予 epoch key 評價。

以 Alice 和 Bob 為例，Alice、Bob、Airbnb的房東、Booking.com的房東會產生 identity 並且透過 Unirep 合約用 user 的註冊方式獲得一個 GST 的樹葉代表自己；
而 Airbnb 和 Booking.com 會透過 attester 的註冊方式，使用特定的錢包地址或是撰寫智能合約呼叫 Unirep 的 attester sign up function。
當然 Alice 或 Bob 如果想用自己的錢包註冊為 attester 也是可以，這時合約就會紀錄 Alice 和 Bob 的錢包地址，並給予一個新的 attester ID。

給予評價

在 Unirep 中評價的接收者是 epoch key，接著介紹 user 和 attester 是如何互動。

How an attester gives reputation to an epoch key

Alice 在 Unirep 註冊過後，就可以產生 epoch key 接收評價

epochKey = hash(identity, epoch, nonce)

但 Airbnb 的房東看到這把 epoch key，要如何知道 Alice 確實是 Unirep 的合法使用者，且 epoch key 的 是合法的，例如 nonce 小於 5，或者 epoch 是當前的 epoch？

如果 Alice 直接提供 epoch 和 nonce，別人沒有 identity 也無法計算此 epoch key，更不用說如果 Alice 提供 identity 會造成 Alice 完全沒有隱私可言，所有人都可以計算出 Alice 收過哪些評價。

因此我們用一個零知識證明，證明此 epoch key 是合法的。細節請參考 epoch key proof，主要是證明使用者有一個合法的 GST 樹葉在 GST 中，並且 epoch 和 nonce 也都符合。

房東得到 Alice 提供的 epoch key 和 epoch key 的證明，並且透過 Unirep 的合約驗證通過之後，就可以給予評價。

獲得空投評價、使用者可以給予評價的限制可以由各個應用自行定義，例如 Airbnb 可以決定空投 30 個正評給使用者， Booking.com 可以決定空投 20 個正評給使用者。

另外，為了確認房東也是合法的使用者，也為了防止房東重複花費 (double spending) 自己的評價點數，Unirep 上的應用也可以用 reputation nullifier 及其 proof 去證明使用者合法使用自己的評價。

例如，此 reputation nullifier 可以用下列計算方式取得：

reputationNullifier = hash(REPUTATION_DOMAIN, id, epoch, nonce)

當 reputation nullifier 及 proof 產生後，就會與房東要給的評價一起發送到 Airbnb 的智能合約上，智能合約會驗證 proof 是否合法，nullifier 是否有被發送過，若檢查都通過的話則 Unirep 會紀錄此評價給 epoch key，並將 hash chain 更新。

接收評價

使用者即使可以證明自己擁有哪一把 epoch key 並且大家都知道這把 epoch key 有多少評價，但這有可能造成使用者故意忽略其他把 epoch key 中對自己不好的評價，因此 Unirep 限制使用者只能在每個 epoch 結束，每把 epoch key 都封起來之後，才能用 User State Transition 更新自己的評價。

User State Transition in Unirep

這裏也是用 User State Transition Proof 去保證使用者是根據正確的方式計算出最新的 UST，且用 epoch tree 限制使用者必須處理每一把 epoch key 的結果。

亦即，需要等到 epoch 結束後，Alice 才能透過 User State Transition 獲得 Airbnb 房東的評價，更新自己的使用者狀態。

證明評價

當使用者通過 User State Transition 之後會有最新的 UST 狀態，此時 Alice 就可以透過 reputation proof 向 Booking.com 她有來自 Airbnb 的評價，在reputation proof 中檢查使用者是否有其宣稱的 UST (例如總共有多少好評、多少差評來自哪一個 attester ID)，並且此 UST 的狀態儲存在當前 epoch 的 GST 中。

在生成 reputation proof 時，即使 Alice 總共有 100 個好評，但 Alice 仍可以產生「至少有10個好評」的證明，Booking.com 的房東若驗證成功，則只能知道 Alice 宣稱的「至少有 10 個好評」而不能知道 Alice 總共有 100 個好評。

常見問題

Alice 能不能給 Airbnb 的房東評價？ Alice 能不能給 Bob 評價？

可以。

Airbnb 的房東和 Bob 也都能產生 epoch key，因此如果 Alice 有兩者的 epoch key 及合法的 proof 則可以給予評價。此時 Alice 可以選擇透過 Airbnb、Booking.com、或甚至自己的 Ethereum account 當作證人給予評價 (也必須選擇一個證人)。

Alice 可以透過 Unirep 給 Airbnb 評價嗎？

如果 Airbnb 也透過 Unirep 註冊為使用者，並且產生 epoch key 的話就可以。但如果 Airbnb 只註冊為證人的話不行。

Alice 可以證明評價來自哪一個 Airbnb 房東嗎？

如果 Airbnb 的房東沒有註冊為證人，則 Alice 不能證明評價來自哪個房東。

若 Airbnb 的房東用自己的 Ethereum account 註冊為證人，則 Alice 只能證明評價來自這個 Ethereum account，但無法知道這個 account 是一個 Airbnb 的房東。

從 Airbnb 獲得的評價可以在 Booking.com 花費嗎？

需看 Booking.com 的智能合約如何定義，但一般來說不行，因為 attester ID不同，但未來可能會開發各個應用程式之間的兌換評價功能。

如果遲遲不執行 User State Transition 會發生什麼事？會不會收不到之前的評價？

若 Alice 在第一個 epoch 註冊，並在第一個 epoch 產生 epoch key 接收評價，但 Alice 到第五個 epoch 才執行 User State Transition，那 Alice 會根據第一個 epoch 的 GST、epoch tree 執行 User State Transition，因此仍然可以在第五個 epoch 收到來自第一個 epoch 的評價；而在第二到第四個 epoch 因為 Alice 無法產生出合法的 epoch key proof，因此無法接收評價。

User State Transition 可以自動執行嗎？

不行。

只有使用者主動給出私鑰，即 semaphore 的 identity，才可以產生合法的 User State Transition proof，若將私鑰交給第三方幫忙執行可能會侵害使用者的隱私。

結論

Unirep 是一個具有隱私保障的評價系統，透過 ZKP 的保護使用者可以在匿名的情況下收取評價、給予評價、並且向他人證明自己的評價。Unirep 可以用於跨應用程式間的評價證明，可以在 A 應用程式中獲得評價，並向 B 應用程式證明在 A 應用程式中獲得多少評價。若想了解更多有關 Unirep ，可以參考 Github、文件或加入 telegram 群組討論。

本文感謝 CC, Nic, Kevin, Doris 協助審稿。

Unirep介紹: 使用ZKP的評價系統 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

2004年，我創作〈小情歌〉，寫下這句歌詞：「我想我很適合／當一個歌頌者」，2019年，我引申創作了〈歌頌者〉這首歌，「歌頌者」三個字我自引〈小情歌〉歌詞。今天，他卻表達「歌頌者」三個字，是他給的建議，讓我不可置信。

從兩年前這件事發生以來，除了法庭上，我從未公開談過此事。我一直不懂為何會發生這樣的事，一直希望是一場誤會，也一直覺得或許不談論，是對心中那位曾視為父親的人，最後的尊重、寬容與一點保護。但事實上，這樣的盼望落空了，一次又一次，我終究心死了，也覺得必須好好對關心我的你們交代一次這些事。
　
　
【事件經過】

我和林先生在2008年有簽署一份詞曲授權合約，原訂2014年底結束，而因我信任對方，一直自動延續到2018年底。

2018年的9月20日，我跟林先生約在他家開會，我向他表示，覺得自己快40歲了，一直以來感受到人生無常，我擔心自己要是突然死掉，家人什麼都沒有，希望詞曲版權拿回來自己處理，他也同意。

我認為依照我們十多年來互相信賴的關係，當面口頭講是比較尊重的方式。我10月26日寄發存證信函提及此事，怕嚇到他，我也先用LINE知會他，他也表示沒問題。

接著在12月6日，我們簽署「合約終止協議書」在雙方律師見證下，確認詞曲合作終止，也將10月26日的存證信函寫進終止書，以「全部遂其所願」表示同意。林先生也親自在電話裡跟環球版權總經理確認以後我會自己處理版權，也發訊息給我「12月31日前這些轉移的對象都會知道你即將自己做」。

原先我想讓一切靜靜落幕，而林先生要求我擬稿，必須在12月31日公開聲明，對外表示以後我將自己處理自己的工作。我記得他一直告訴我要「妥善處理、好聚好散」，並且希望我們能「樹立典範」，告訴大家，不是每一個藝人跟經紀公司結束都要撕破臉。後來也公開聲明結束合作，沒有一點點讓我懷疑我們還有存續任何合約的可能。

一直到2019年4月，我突然收到他的存證信函，我非常錯愕，何況中間我多次在節目上演唱自己創作，他從未有任何反應。收到存函後我不斷跟他聯絡，好幾天他不接電話、我用各種通訊軟體訊息他也不回，最後用email，他才回覆宣稱詞曲授權還在他身上。

沒多久，林先生開始對我提起假處分、民事訴訟、甚至到刑事，還把我所創作的歌名搶註商標。我的律師苦笑地說：「他送給你全餐耶」。

10月，在被告後第一次見到林先生，記得檢察官希望能促成和解而問他「如果要和解，你的條件是什麼？」我記得他表示「我希望他把寫給蘇打綠的所有詞曲都給我，我想keep住我跟蘇打綠的美好回憶！」我記得檢察官當場回應他「這要求已經超出案件範圍，你告『吳青峰』，現在卻要求『蘇打綠』，連我都覺得強人所難，你怎麼能要求他接受，不要講得很漂亮說是美好的回憶，但其實你是想要某些東西。況且現在都告了，也不美好了。」後來我嘗試庭外再約他和解，他提出的條件依然是「繼續授權所有蘇打綠發表過的詞曲，要使用不需經我同意」，並告訴我「只有他知道我的歌怎麼用最好」。當時訴訟的開端是〈歌頌者〉這首歌，和解條件卻是「蘇打綠過去和未來的歌」，過去近百首歌曲，甚至未來我還沒寫的歌？難道不令人懷疑這才是目的嗎？
　
　

【一次又一次的死心】

經過幾次出庭與報導，很多人漸漸發現這件事，但你們不知道的是，你們看到的只是冰山一角。兩年多來，我不斷收到無數書狀，幾週一次，一次動輒數十頁。應該談法律的書狀，卻成為一次比一次荒謬且攻擊性、情緒性的字眼。你們偶然看到報導覺得氣憤的，卻是我的日常心碎。

合意不續約，安分守己唱自己的歌，卻被形容成「無視法紀，不斷膨脹放大自身之權利。」；

為了承接他瞞著我簽的合約，卻被說成「違約在先，企圖霸王硬上弓」；

一個創作者、著作權人反被「被授權人」稱為「不潔之手」；開庭被往事勾動而難過，卻被描述為「其妄尊自大、不可一世的霸道心態與作法，與其前次開庭時的楚楚可憐形象，根本南轅北轍、判若兩人。」；

在高雄演唱會前被觀眾質疑我不能唱自己的歌，卻說我是「利用『創作者不得演唱自己的作品』之悲情訴求，企圖博取大眾之同情，以炒作演唱會熱度之宣傳手法」；

說一個中文系畢業生「曲解電子郵件文字到這種程度」；

連林先生當時委任的律師，都出庭作證所有人都很清楚三份合約皆已結束。對方卻可以寫成是林先生「隱忍退讓，百般之退讓與成全」，說我「令人瞠目結舌」；

當對方提出假處分，要求法院令我四年四個月內不能使用自己作品，他們說凍結我的作品「影響不大」。為了抗辯，我們提出《太空人》的銷售，以及過往歌曲紀錄，這時對方回應「辯稱因為銷售量大所以就應該容忍其侵權云云⋯⋯然還以此沾沾自喜⋯⋯豈非財大氣粗者就可以任意侵權而可以不負法律責任」、「小情歌歌曲並非著名，亦未與『吳青峰』有密不可分的連結。小情歌歌曲僅有1619萬次之觀看次數⋯⋯實難謂其非過於膨脹自身之評價」、「無與倫比的美麗僅有1019萬次之觀看次數」等等辯稱凍結我的作品，對一個創作歌手影響不大。

這樣的言語已歷時兩年，在此所提也只是冰山一角，我真的分不清，到底是寫書狀的林佳瑩律師、張志朋律師的言語，還是林先生本人的意思，但無論如何，就算是律師的意思，肯定也經過林先生同意；就算是林先生的意思，也是律師下筆的。

一次又一次，我真的不敢相信，這些話是從一個，我曾視為父親的人口中說出。一直以來盲目相信他、永遠感恩報答的我，為什麼要這樣被對待？就因為不合作，十幾年的情誼都不重要了嗎？那些他曾說是家人、是partner，口口聲聲的好聚好散，都是假的嗎？

網路上看到許多擷取片段發表意見的法律人說「青峰犯的錯是沒有在三個月前以書面表明不續約」，但他們不知道我的經紀合約包含了著作權條文，2018年12月我與林先生新簽署的〈合約終止協議書〉終止了「詞曲版權、經紀、唱片三份合約，終止書的副本公開聲明即是不續約的書面文件，這點民事判決書也說：「以後約修正或取代前約，致無須在該年12月31日前3個月為之」。

上一次開庭，林先生當時的委任律師有一段證言讓我很驚訝，她說2018年終止合約時，她詢問林先生三份合約，林先生回答她：「版權早就談好了，是沒有爭議的部分，其他兩份因為有工作需要交接，所以要特別寫清楚。」林先生給了她經紀合約與唱片合約，並表示「詞曲合約找不到。」我驚訝的是，我知道林先生全部合約都交給會計張小姐保管，他告訴律師找不到合約的同一禮拜，我也曾向會計張小姐要過詞曲合約來看，不可能找不到。這句話讓我不免驚嚇地懷疑，難道一開始就別有用心？

上一次開庭時，我沒有想到我會哭出來，在證人的證詞中，勾起太多我早已不願回想的往事細節，包括「林先生很擔心我不願意承接騰訊這份合約，他會違約」；但連證人都很訝異我「全盤接受林先生要我承接的」；我曾詢問林先生「是否能聘請你當製作人」卻被林先生拒絕「要斷就斷得乾乾淨淨」；協議結束後我甚至「挽著林先生的手，告訴他：『你不願意一起工作沒關係，我們還可以是家人』」⋯⋯這種種，實在讓我一時沒忍住情緒。

我哭，不是因為我想博取同情，是因為我有真感情。我哭，是因為我至此徹徹底底死心，如同第二次經歷「失去父親」的過程。我哭，是因為我一切都為他著想，但最後換來了什麼，而這一切，竟然是由當時的「對方律師」替我見證的，真是諷刺。
　
　
【我對每一個創作者想說的話】

事件開始時，我正面臨《歌手2019》決賽演唱〈歌頌者〉的掙扎，我沒有告訴周遭的人發生什麼事，自己每天回到飯店默默流淚。

坦白說，最開始我問律師：「我們能不能乾脆認輸？他要錢，就照他說的賠，當花錢學教訓、認清一個人，也就不用浪費生命在他身上了。」我很心痛，但我實在不想花費心思在這件事上，依照我們對他以往與其他對象諸多訴訟的了解，他總是纏訟到底，而對我一個創作者而言，我一開始希望版權在自己身上，就是有感於人生無常，就是因為珍惜生命、珍惜時間，而現在我卻要浪費這麼多生命訴訟，這些時間如果我能拿來寫歌，該有多好？

但律師說：「你是第一個唱自己寫的歌被告的，沒有前例。如果你不力爭到底，你會害到以後有一樣遭遇的創作者。」正因如此，我一直在為了未來我不認識，但可能面對一樣事情的創作者，拼命面對著。同時，一旦看清蘇打綠的歌曲是被搶奪的目標，我也必須為了蘇打綠六個人十多年的心血奮戰。

我們從小的環境、教育，一直被教導要「尊師重道」、「忍耐是美德」，但就是這些教導，讓過猶不及的我，因為懷著感恩，所以一路以來從不懷疑、盲目相信，最後變成這樣。對於「尊師重道」、對於「感恩」，我自認我一直以來都是做到最好，絲毫無愧於心，於情感、於實際收益，我相信我已報恩百倍萬倍。但遇到錯的事，無止境「忍耐」並不是美德，只會縱容、寵壞他人，最終不但會反過來吞噬自己，更有可能害到他人，甚至親眼看著自己最愛的母親、家人陪你難過。

我希望每一個年輕的創作者，記得一開始就要看清楚合約。常懷感恩、努力回報，這些都是理所當然，但一方面，保護自己更理所當然。如果你合作的「長輩」是正直的，就不會因為你「合理」地詢問自己的權益而惱羞成怒。我希望有所有創作者一定要保護好自己，不要像我一樣遭受這樣的打擊，讓生命如此虛擲。

我從未想過會遭逢如此巨變，也驚覺有時法律保護的，並非對的人或善良的人，而是「懂得怎麼利用法律的人」。我沒想到，創作有時變成一種原罪，為了自己的作品不被奪走，需要浪費這麼多生命、花這麼多心力。我也從未想過，其實有時律師會力挺的，不是法律、不是真相，也不是正義，而是付錢給他的客戶，如此而已。
　
　
【結論：我於理、於情都毫無虧欠，更是合理合法、仁至義盡】

我相信我今天一番話，一定會再被對方以各種曲解和利用法律刁難，畢竟對方連我私人臉書的發文都要自行對號入座、要求我登報道歉。但我不怕，因為我沒有一句話是謊言。我也知道這件事還有一段很長的路得走，我相信對方會不斷想辦法繼續纏訟，而閉上眼睛寫寫書狀就有錢領的好差事，亦有很多律師趨之若鶩。我也希望每個要興訟的人多想想自己的家人、孩子，你怎麼忍心讓他們查詢自己的家人，都是這些新聞。

面對這件事到後來，不只是我，書狀中的無端攻擊，從針對我，也變成針對六個個別團員，更沒想到，連馨儀也遭受這樣的對待。看著身懷六甲的馨儀接著被告，跟看到吳媽媽要面對一樣令我心痛不已。

我是一個創作者，還在努力創作著，我深知，音樂一旦失去靈魂，就只剩下技巧；而法律一旦忽略人心，產生漏洞，就只是文字罷了。

蘇格拉底曾言：「不只要活著，還要良善地活著。」活在這世界上，我相信我期許自己擁有的，不只是作品、名字，而是良善。我一向問心無愧，沒有一絲虧欠，於情，於理。

「已經是極限了」只有一個人的照護的悲劇 為何22歲的孫女用雙手了結自己的祖母
把黑髮緊緊束成馬尾。穿著白襯衫，嬌小的她抬起頭來，看起來比實際年齡還年少
9月，神戶地方法院，當時還是幼稚園教師的她第一次站上法庭。她承認自己殺害了同住的90歲祖母，她說「因為要照顧祖母根本沒辦法睡，已經是極限了」。她幾乎只靠一個人從家族那擔下照顧責任，與工作蠟燭兩頭燒的最後就…
為什麼社會人第一年的女性會被逼得以雙手結束最愛的祖母的生命呢。我們去旁聽了開庭，以及採訪了相關人士◇雙親離異，將她拉拔長大的、最愛的祖母
2019年10月8日，這位女性在神戶市須磨區自己家中將毛巾塞入同住的祖母的口中使她窒息而死。患有失智症的祖母，有3個孩子，住在徒步5分鐘可到的地方。就是這位女性的伯父、爸爸、姑姑。然而，在這個家中，照顧責任通通由這位女性一人擔了下來
一路走來變成這樣的原因，跟這位女性的成長經歷有很大的關係 　她3歲時父母離異。一起住的母親在她一年級時因為腦溢血過世。將她從兒童照顧機構接回來的正是爸爸那邊的祖母。祖母想方設法為她籌到了學費以及生活費，也買了鋼琴給她。是幫助她實現成為幼稚園老師這個夢想的，最愛的祖母
但是，祖母也有偏激的一面，她常說「你是被那個只會借錢的母親生下來的」這種否定這位女性的存在的言語。她上了國中後，精神開始失調。常常大量服用安眠藥而被送醫。醫生建議她別再跟祖母同住，而她就寄身於姑姑家中。
進入短期大學後，不再需要服用安眠藥的她決定要成為自己曾經夢想的幼稚園教師。但是，那時祖母的身體狀況開始走下坡，她的生活再度脫離常軌。2019年2月，祖母在自家前坡道摔倒住院。診斷出阿茲海默。被認定為無法自己處理大小便以及照顧自己的4級照護等級。回到自家的祖母，會在深夜不穿鞋跑出家門在外遊蕩，並去按左鄰右舍的門鈴。親戚們決定「把阿嬤一個人丟在家太危險了」◇得不到親戚的協助，與工作蠟燭兩頭燒的哀號 　那是誰要照顧祖母呢。在神戶市內經營清潔公司的伯父工作繁忙，爸爸生病手腳不方便。姑姑也有小孩。姑姑便說「阿嬤都幫你出學費了，那當然是你來顧」這句話就讓這位女性把照顧責任都擔下來了。在幼稚園當了一個月教師後，她開始與7年不見的祖母同住
當時，這位女性對高中同窗的好友表明「開始照顧祖母了，尿布跟餐費也都是自己出錢」也向她傾訴對尚未熟練的工作的不知所措。好幾天都受了上司與同事的氣，在職場提到照顧的事也被當作說謊，沒人願意聽進去
祖母在平日早上都會到日間照護服務中心，但晚上與假日都會待在家中。這位女性在每天下班回家後要餵祖母吃晚餐、每1到2個小時帶去上廁所，如果有大小便的話就要幫她洗澡。晚上也要帶她去散步。一天只能睡兩小時
同住開始兩周後，這位女性發覺自己到極限了，便跟爸爸與姑姑說「我可能沒辦法照顧祖母了」
她與親戚的關係比較特別。她向朋友表示在國中開始到短期大學時寄住的姑姑家中「沒有允許不能出去玩」，為了照顧姑姑的小孩還得常常早退或不能參加社團活動
根據判決中檢察官所讀的證詞，伯父說「這女生是開朗溫柔的孩子，我的兄弟把照顧媽媽的責任全丟給她。希望不要判她重刑」
但，面對表明自己撐不下去的女性，姑姑只說了「這種程度自己能控制的吧」。她也被禁止與照顧祖母的照護人員直接聯絡，不管她說什麼都只回說「妳去顧啦」這樣的生活持續了5個月後便發生了之後的事
案發當天，從早上開始天氣便陰沉沉地。天色尚暗的凌晨五點半，她被睡在身旁的祖母叫醒，要她幫忙擦汗 雖然用毛巾幫她擦了身體，但祖母開始罵她「不把父母當一回事」可能是把孫女與自己的女兒搞錯了。雖然把毛巾用熱水浸濕重新擦了一次，這次又被說了「就是因為有妳在我才活的不開心」　雖然她一再地道歉，祖母的斥責卻沒有停過。等到回過神來，她已經把祖母壓在床上
說著「別再說了」，她邊把手上有史努比與粉紅色愛心圖案的擦臉毛巾塞到祖母的嘴巴。幾分鐘後，祖母就沒在動了。
在試圖自殺不成後，她自己打了110告訴警察自己殺害了祖母，而警察也趕到現場。
◇「無法嚴厲責難」判決3年徒刑，緩刑5年 　2020年9月9日神戶地方法院開始的裁判員判決中，看到了這位女性在照顧祖母的第三個月因為疲勞與壓力過大使腎臟功能失調，有嚴重貧血，以及被診斷出輕微憂鬱症，醫生建議要辭掉工作或留職停薪。另外，作為檢方證人的姑姑在庭上表示「全家都很努力照顧阿嬤」但是，照護中心的女性照護人員作證「自己雖然建議（讓祖母）住院，但被姑姑拒絕了」
爭點不在於事實，而在於這位女性的責任能力。被告方律師主張「這是由於睡眠不足以及照護導致適應障礙而造成的精神耗弱」而檢方指出這是「冷靜的行動」認為她有完全責任能力 對她的判決是3年徒刑，緩刑5年（檢方求刑是4年徒刑）審判長飯島健太郎認為「雖有適應障礙，但對犯行無影響」但結論說到「照護導致的睡眠不足以及工作壓力使其身心俱疲，無法嚴厲責難」。另外，他指出親戚間的關係「無法違反姑姑意願使照護負擔減輕」。而緩刑的理由則是「她自首後有在反省，能夠期待她在社會中更生」
雖然在社會中走上贖罪之路。但她很難得到親戚的支持。她的父親在判決後每日新聞的採訪中放話「她應該進到牢裡的，判決是在『她被迫照護很可憐』的前提下作出。我與妹妹（姑姑）談過後想法跟她一樣。之後不會再跟她連絡了，我對她已經沒有作為親人的愛情」
根據她的律師所說，這位女性透過保護觀察所（譯著：更生機構）找到了住的地方，開始找工作，但詢問過採用的某家幼稚園表示「我們有品牌形象的考量」就拒絕了她。最近好像終於找到事務職的打工，但仍持續著連衣服都不夠穿的日子
記者雖然向律師表明想直接訪問本人，但沒得到回應
她與祖母共住的家在案件發生後，大門深鎖。放在玄關前的盆栽雜草叢生，彷彿傾訴著照料的人已經不在這件事。「祈求阿嬤的冥福，並在社會中重新做人吧」傾耳聽完飯島裁判長的訓誡微頷的她，現在也走在顛簸的道路上◇有其需求的「照護方的照護」
專門處理照護方的照護的NPO法人「照護者支援網絡中心阿拉丁」的牧野史子理事長表示「照護失智症患者非常辛苦。沒做過的人是不會知道的」。根據厚生勞動省統計，照護者使被照護者死亡的數量在這十年以來到了一年20人左右。在厚勞省2005年的調查中，可以看到照護者有四分之一有輕度憂鬱症
在這起事件中，這位女性的周圍有姑姑等人的親戚。也有照護人員，有能夠討論祖母照護的體制，但是，專門研究照護的淑德大學結城康博教授（社會福祉學）推測「周遭的人將她逼到絕路。照護人員最多也是站在『如何照顧祖母』的角度在思考，卻沒人為這位女性著想」
對於負責照護諮詢、自治體與地方整體的支援中心，結城教授指出「全都是『為了被照護者』而運作的機構。照護者的支援只有一部分的NPO在做」
在這起案件中，有人能對這位女性伸出援手嗎 牧野理事長表示「首先需要調查找出為照護所苦的人」埼玉縣在2020年3月，制定了全國第一個支援照護者的條例，首先就開始調查身為年輕照護者的未滿18歲的照護者
牧野理事長說「如果在這位女性鑄下大錯前能發現她，保健師說不定能做到前去幫忙照顧等等的支援。照護是每個人都會遇到的問題。不只是被照護的那方，將目光轉到照護方是更重要的一件事」