關於 linux 自動 source ，我們在網路上蒐集到這些相關的討論、資訊與評價

Ref: https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html

今天要探討的是一個由 Google Blog 於上個月所推廣的軟體安全性框架，該框架名為 SLSA，全名則是 Supply Chain Levels for Software Artifacts，中文部分我不知道該怎麼翻譯才可以精準達到意思，所以建議就唸英文就好了。

該框架的目的是希望於整個軟體生產鏈中能夠進一步的去提升且確保所有產物的完整性(Integrity 這個詞該怎麼翻呢..)。

文章中用了一個很簡易的流程來清楚的解釋到底何謂 Software Supply Chain 以及整個流程中可能會有什麼問題。

Software Supply Chain 一個範例譬如
1. 開發者撰寫程式碼，並且提交到遠方的 SCM Repository
2. SCM Repo 因為程式碼改變，所以觸發相關的 CI/CD 流程
3. CI/CD 建置結束後則需要打包整個程式碼，產生最後的 Package.
4. 產生後的 Packet 則可以正式上場使用

文章認為上述的流程中有兩個不同類別的安全性問題，分別是
1. Source Integrity
2. Build Integrity.

Source Integrity 這邊主要是針對 Source Code 相關的問題，譬如
1. 開發者是否有意的故意塞入一些會不懷好意的程式碼到 SCM Repo 內。
範例: Linux Hypocrite commits, 之前美國某大學研究團隊基於研究嘗試上傳一些不太好的程式碼而影響的討論風波
2. SCM 的管理平台是否可能被惡意攻擊
範例: PHP 事件: 之前自架的 PHP Git Server 被攻擊者惡意攻擊並且塞入兩筆不懷好意的 Commit

而 Build Integrity 本身則是有更多不同的面向，譬如
1. SCM 觸發 CI/CD 過程是否有可能有問題
範例: Webmin 事件，攻擊者去修改團隊的建置系統去使用沒有被 SCM 所記錄的修改檔案。
2. CI/CD 建置系統本身被攻擊
範例: SolarWinds 事件，攻擊者攻破建置系統去安裝一些軟體來修改整的建置流程
3. CI/CD 建置過程中引用到錯誤的 Dependency
4. 攻擊者上傳一些惡意產物到應該只有 CI/CD 系統才可以存取的場所。
... 等

目前來說， SLSA 還處於非常早期階段，經由業界的共識來思考每個領域有什麼好的措施與指引來避免與偵測系統是否被攻破。其最終目標狀態是希望能夠根據環境自動產生出一套可整合到系統中的產物，並且最後可以給出 SLSA 憑證來給平台或是建置後的 Package。

對 SLSA 這個專案有興趣看看的請參考原始連結，內容不長但是頗有趣的

最近稍微接觸了一下所謂的K8s(Kubernetes) 這套Google設計用來管理容器(containerized)應用程式的開源系統 不過GCP(Google Cloud Platform)上面也有提供服務可以方便使用 只是對於部署docker容器的部分似乎就與使用linux建置時有點不同 後來發現其實好像也沒那麼難用, 在此做個紀錄先... 由於使用GCP部署時需要使用Git類的存儲空間 可以使用GCP自家的Cloud Source Repositories, GitHub與Bitbucket 比較之下水哥覺得Github比較方便, 所以建議是使用Github來部署程式碼 首先在Github建立帳號 登入後建立存放區, 已存在的話則不用! 建立後使用專用連結存取上下傳 下載Github客戶端 登入客戶端並選擇存放區 點右邊Show Explorer 可開啟檔案夾 放入需要更新的檔案就會自動跳出新的變更 左下角則是寫註解跟說明等, 確認後按Commit 第一次會跳選擇分支 選完分支後發佈 以後有新的更新 commit後右邊點push就可以 Github存放區重新整理就可以看到放上的檔案 接下來到GCP的管理介面部屬 依據需求選不同的存放區 這裡選Github dockerfile檔案名稱打錯會導致建立容器失敗, 小心不要打錯 下一步設定應用程式名稱與需要部署的叢集 建立需要一點時間, 需要稍等一下 過幾分鐘後就會跳轉到這裡 這代表POD已建立 如果我們要對外服務, 就需要點選公開 左側設定對外PORT, 右側則是容器使用PORT 如果要設定同一個, 就只要輸入左邊的就好 建立完成會產生service 外連資訊會顯示在下方 剛剛設定的外部內部對應PORT則會顯示在下方 若是照剛剛的設定就會呈現這樣, 而展示的nodejs-demo3則是設定了30999 所以測試時使用30999 測試連線...顯示ok! 花了不少時間才搞懂GCP上K8s的用法= = [ 35 more words ]
https://mshw.info/mshw/?p=22463

📜 [專欄新文章] Crosslink Recap —— Design pattern: build your first profitable DApp and smart contract
✍️ Feihu Tang
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

上文 里說到，這幾天我會在臺北的 Crosslink 作為文字組的志願者，此次我負責這個議程的記錄，裡面非常多的 insight，我聽了非常感動。

會後，陳品來和我說，這次有一點遺憾是自己選擇使用英文，但是自己的英文並不足夠流利，使得大概只是介紹 slide 內容本身，如果用中文的話，就可以捕捉到更多的信息了。但是我覺得現在的版本就已經足夠好，會議當天臺下也有很多 foreigners，這種偶爾選擇走出自己舒適區的方法也是非常值得鼓勵！

陳品和我同是 TPE 的演講者，同時又都在去年成立了自己的 Dapp Startup，我們之間 share 著許多共同的觀點，這一次能夠記錄這個議程，也可以從側面描述一些從我的視角出發的補充論據。這里順便吐槽一下，剛從大阪 Devcon 回來，去了北京 Dragonfly，為了參加 Crosslink，中間不得不又回到日本，差點沒累個半死 …

參考資料

Bilibili, 演講回放 | Youtube 分流

Slide, Design Pattern: Build Your First Profitable DApp and Smart Contract.

Slide, Web3 Business Models by @owocki

加密協議的本質已不是「去中心化」，而是區塊鏈的可分叉

Multicoin：论 Layer 1 和 Layer 2 的价值捕获

論開放式金融框架下價值捕獲的重要性

五分鐘概覽 DeFi 當前常見的商業模式

挑戰

回到當天的議程。首先陳品介紹了 Dapp 開發者所面臨的挑戰，他將一個 Dapp 的生命周期，劃分為三個階段：

Bootstrap 冷啟動

Value Capturing 價值捕獲

Sustainability 可持續發展

其中最難的也是最核心的是第二個階段，Remember what has been told by Felix?

緊接著，陳品類比擴容悖論(Scalability Trilemma) 提出了 Dapp 悖論 (Dapp Dilemma)。開發一個 Dapp 非常容易，但是要開發一款可持續盈利的 Dapp 卻非常困難。究其原因，就是 Dapp 合約在默認情況下應當是開源的，而開源則意味著任何人都可以 fork ，然後將手續費設置成更低甚至是免費的版本。然而開源，或者說 「可分叉性」 ，這柄高懸在開發者頭頂的達摩克利斯之劍，又恰恰是她最迷人的地方。開源、自治、可持續，是每一個 Dapp 開發者所追求的極致的目標。

如同擴容悖論 (Scalability Trilemma) 只是 hard to achive 一樣，Dapp 悖論 (Dapp Dilemma) 也並非無解。

月前 Shell Xu 在 Linux Story 群里有一次 關於開源盈利模式的討論。Btw, 我之前在 Github x 平安雲的活動上， 還有幸聽了 Shell 的一節課 。

Shell 認為開源的盈利模式，有很多種，其中包括：

捐助 有很多成功的例子。甚至還有專門的網站 Patreon，ci-en 以及 愛發電。一些比特幣和匿名幣的開發者也依靠這種模式。軟體開源，但是往 AppStore 賣的話，實際也算是捐助，例如 keka 和很多 shareware games。 （這麼說來，itch 里自由定價，其實理論上也算是捐助吧。）

軟體免費，服務收費 代表 Red Hat

雙授權 代表 GhostScript 和 MongoDB

基金會 然後基金會又分為好幾種模式。 其中最成功的要算 Apache 基金會，參見 從用戶成為“股東” — — 在 Apache 基金會的 2600 天（Mozilia 你還好嗎 — — ？）

緊接著我提到，發幣其實也是一種。這一點最好的文章是 Naval 14 年寫下的那篇著名的 《比特幣眾籌模式》。這個觀點 Shell Xu 也非常認同，並且他還特別指出發幣事實上是很成功的一種手段。另外，最後我的觀點，我後來也專門寫了一篇文章， from open source to self hosting … 這是一個 Self hosting 的例子。

案例

EasyDAI

接下來陳品開始分析一些實際的案例，首先從自己的作品開始。

使用者將以太幣存入後，便會透過智慧合約自動執行，將以太幣兌換為美元穩定幣 DAI，隨後把 DAI 存入 Compound 借貸放款平臺，經由智慧合約去中心化地放款給其他有融資需求的用戶來獲得利息。
—— EasyDAI

我們看到 EasyDAI 的一筆交易中，會同時調用經過多個智能合約，這種互通性（Interoperability），也是 DeFi 項目的魅力之一。參見 InstaDApp, Bridge Protocols 。

Bancor VS Uniswap

剛才說到，發幣也是一種商業模式。談及 ICO，雖然我们都知道 Linux 那句著名的 Talk is Cheap，Show me the code，但在區塊鏈的世界，通常的作法則是 You reap, before you sow。但是並不是說，發幣就是解決所有的問題銀彈，可以參見 Gitcoin 的那篇，而一個多餘的 Token 帶來的後果很可能是災難性的。

Why Gitcoin Didn’t Launch With A Token

比較 Bancor 和 Uniswap，Uniswap 勝出已成公論，原因很多。首先 Uniswap 不會被 Bancor 代幣尋租（之前 Bancor 的運營人員有聯絡到我們希望幫我們的 EOS 代幣上 Bancor 交易所，當然代價是 5000 usdt。。。）。

然後更致命的原因 Bancor 的流動性是死的，而 Uniswap 協議的流動性足夠靈活，可以隨著市場的變化，動態調整。

最後 Bancor 協議的前提，假設 cw 是定值看起來也很沒道理。而所有這些原因，導致的結果就是會是 Bancor 錨定的代幣，缺少脫鉤的機制。關於這個論點，我之前在 Dapp Review 專門寫過文章： 重新審視 Bancor 演算法，為什麼 cw 是失效的設計 。

Kybey

接下來列舉了一個中庸的例子，Kybey。他依靠著 offchain 的設計，避免自己過早的遭遇分叉，從而也成功的積累了網路效應。

Raiden Network

而作為失敗例子的代表，相比於 Lightning，Raiden 網路發行了自己的代幣，並且類似以太坊那樣將這種代幣作為手續費，但是這種做法並沒有捕獲到 Layer2 的價值，從而導致項目的失敗。

MakerDAO

最後陳品舉了一個正面的價值捕獲的例子 — MakerDAO，這個觀點也和此前 X-Orde 群里 Tina 的看法一致。

結論

回到 Dapp Dilemma，因為 Smart Contract 默認你就是需要開源的，所以所有開源軟體會遇到的問題，你大概也都會遇到，而解決這一問題的唯一方法，陳品在 slide 里也進行了總結，就是 在被分叉之前，捕獲足夠的價值，從而積累出足夠的網路效應作為你的壁壘 。

QA

Q: 如何實現閉源。
A: 不要在 etherscan 里 verify source code 就可以了。 這里我還有一個小的疑問，因為實際上我們所有的 bytecode 已經上 EVM 了，這里是否有可能被逆向工程？@陳品

Q: 閉源真的有用戶來用嗎？
A: Of course。

Q: How about PollTogether?
A: 這是一個價值捕獲的好的例子，等到他們開源的時候，合約里已經有足夠吸引力的 deposit 了。

Crosslink Recap —— Design pattern: build your first profitable DApp and smart contract was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌