📜 [專欄新文章] 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.
👏 歡迎轉載分享鼓掌
常見的design pattern 在 91 敏捷開發之路 Facebook 的最佳貼文
什麼叫做好的程式?
大家的答案都不一樣,甚至在自己不同的職涯階段,答案也都不一樣。
對我現階段來說,就是儘量滿足 “simplicity”,也就是「簡單設計」。
參考:https://martinfowler.com/bliki/BeckDesignRules.html
要設計出很簡單(simple)的作品,一點也不容易(easy),得內化不少技能。
基本原則其實很精要,(留意順序)
* Passes the tests
* Reveals intention
* No duplication
* Fewest elements
1. 針對第一點「通過測試」,也就是不管你的設計多好,都要先確保它執行符合你的預期,要確認你的預期符合需求。
撰寫測試,並通過測試,才能輕鬆的滿足這第一要點。
2 與 3,這兩者的順序有兩派,有些人覺得「理解意圖」要比「消除重複」優先,有些人則覺得要反過來。
我自己覺得這兩者在開發過程中是可以同時滿足的,所以一樣重要。
但在 legacy code 裡面,我會覺得「呈現意圖」要比「消除重複重要」。
原因是,當具備一定的工程實踐技能,搞懂需求、情境、限制時,要消除重複非常容易,但如果容易誤解原本代碼的意圖,或需要很多時間才能猜測代碼意圖,這仍是某種程度的賭注。
4. 第四點是 simplicity 最重要的限制,當能滿足前三點時,用「越少的元素」越好。
越少的元素包括比較少的 class, interface, 參數個數, 回傳的內容, 物件之間的互動次數, 物件之間的相依關係。
通常為了消除重複,(甚至是可測試性),大家容易把單純的東西搞得特別複雜,開始亂套 design pattern 跟胡亂透過繼承來避免重複的過度設計最爲常見。
要解決任何一個依賴,都可以透過新增一層中間層來解決,大家往往更傾向「學習」、達到「低耦合」的設計,卻忽略了「高內聚」其實才是「物件」跟「互動簡單化」的核心。
—
補充一下,我已經兩年避免使用「可讀性」這個字眼,因為你覺得好讀,他不一定覺得好讀。
每個字讀起來都懂,你卻看不出它想幹嘛,它的意圖、流程、目的,都得再經過作者翻譯一次,你才知道程式的意圖。(還要經過翻譯,代表程式本身呈現的意圖跟作者想表達的,中間還有一段落差。)
Intention-driven 的設計還是很重要,避免把代碼層級的東西攤開在 public 的流程中,導致抽象干擾(Abstraction Distraction)的壞味道。
消除重複的目的則是在於「可維護性」,往往一些重構的壞設計,都是基於為了消除重複而把系統以錯誤的方向來重構,常見的例如把重複的代碼放到父類別裡面,來讓子類可以共用,或是 default 的行為放在父類,每個子類可以決定如何加工或覆寫,而延伸出來繼承鏈的大問題。
寫得有些冗長了,想體會簡單設計的挑戰、實作、學習、突破,到實務上的逐漸內化,請參考:https://dotblogs.com.tw/…/201907-evolutionary-development-t…
#七月梯次已額滿,下一梯次還在猶豫是要在十二月,或是2020年二三月。您如歸有興趣先卡早鳥,請您一樣先填七月份的報名表單,待下一梯次確定日期後,我會依序第一時間通知您,以讓您擁有更大的機會取得早鳥的資格。
也可以參考過去學員上完課沈澱之後的心得:https://dotblogs.com.tw/hatelove/2019/06/16/133316
常見的design pattern 在 紀老師程式教學網 Facebook 的最佳貼文
JavaScript 函數庫究竟有多豐富?
持續早上 JavaScript 與 jQuery 的話題...有人問我說,「JavaScript 的函數庫究竟有多豐富?」雖然不至於如佛家說的「如恆河沙數」或「如天上繁星」,但「族繁不及備載」的程度是一定有的。請參考底下這一篇:
20 JavaScript Libraries to Simplify Development Tasks
http://codegeekz.com/javascript-libraries/
其中,最常見的有下列這幾種(我個人接觸經驗認為的啦):
1. jQuery(2006)
- 以「最短程式碼、最大生產力」見長。短短幾行,就能寫出威力十足的網頁特效。
- https://zh.wikipedia.org/wiki/JQuery
2. YUI (Yahoo! User Interface) (2005)
- 提供豐富的使用者介面(表單、導覽列…)
- http://en.wikipedia.org/wiki/YUI_Library
3. ExtJS(2006)
- 基於 YUI 上建立的。
- 提供大量美觀的視覺介面。
- 2010 年改名為 Sencha(日本話的「煎茶」)。
- http://zh.wikipedia.org/wiki/Extjs
4. Prototype (2005)
- 支援標準的物件導向機制,補足 JavaScript 與正規物件導向語言之間的鴻溝。
- 有些次要 Bugs 沒處理,評價兩極化。
- http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework
5. script.aculo.us
- 基於 Prototype 之上而建立的。
- 目前為止,最強的動畫函數庫!
- http://en.wikipedia.org/wiki/Script.aculo.us
6. MooTools (2006)
- 基於 Prototype 之上而建立的。
- 強調「模組化」與「物件導向」,適合拿來開發大型的 JavaScript 程式。
- http://en.wikipedia.org/wiki/MooTools
7. Dojo (2004)
- 用於「跨平台」、「快速開發」等目的的函數庫。
- 可寫出「讓不同瀏覽器,執行效果都相等」的 JavaScript 程式碼。
- http://en.wikipedia.org/wiki/Dojo_Toolkit
8. AngularJS(2009)
- 令人注目的後起之秀,由 Google 主導研發。
- 最早是為了做出「單一網頁架構(Single Page Architecture, 簡稱 SPA)」,就是那種所有東西都放在同一頁,一直捲就會動態載入的網頁。Google 已經將它用在「圖片搜尋」的結果頁,成為目前製作「SPA」時的不二選擇。
- 很強調 JavaScript 與 DOM 的「鬆散耦合(Loosely Coupled)」。認為與 DOM 結合得太緊密不利於程式碼重用,故大量利用 Design Pattern 中的「Dependency Injection(相依注入)」(也就是在 JavaScript 與 DOM 之間多加一層軟體層),降低 JavaScript 與 DOM 之間的耦合程度。
- http://zh.wikipedia.org/wiki/AngularJS
上述這些函數庫,最後都會轉化為 JavaScript 語言,然後丟給瀏覽器去解譯。感覺上,JavaScript 快成了網頁世界的「組合語言(Assembly)」了... XD。
這裡有所有 JavaScript 函數庫、軟體框架的功能比較,請參考:
http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks