為何會有人發明「演算法穩定幣」(algorithm-based stablecoins)?

發布於 2022-05-12 | 最後更新時間 2022-05-12 | 分類: Daily Why

之前沒有特別思考過這個問題,但現在值得問問看。

有種說法是,與美元資產綁定的穩定幣更有可能被監管,而 algo-based 則有機會跳脫這樣的框架,成為一種「crypto-native」的資產。這樣的資產會更適合 De-Fi 的願景。

看起來是基於某種去中心化的情懷,但它真正比 asset-based stablecoin 好的地方在哪呢?

有個比較合理的說法是「成本低」,換句話說是進入門檻較低。

我自己的幾個猜想:(這些猜想都還未被我自己驗證或研究)

  • 這樣的系統初期建構成本比資產支撐型的穩定幣低廉。(低成本類型的創新)
  • 這樣的類型感覺更容易主張去中心化,因此可能被認為更有機會脫逸監管(但真的有人這樣主張嗎?為什麼?)
  • 因為系統較複雜,就多了利用資訊落差牟利的機會。

嘗試把這問題丟到 Twitter 發問,不知會否有人提出有意思的答案。

#Algorithm-based   #Stablecoins


為何 Luna 會崩潰?

發布於 2022-05-11 | 最後更新時間 2022-06-01 | 分類: Daily Why

今天最大的幣圈新聞應該就是 Luna 以及其穩定幣 UST 的崩潰了

有個說法是這是一場精心策劃的狙擊,如 8400万美元撬动400亿金融帝国,UST崩盘始末 - 律动BlockBeats

也有人認為這種崩潰本來就是預料之中遲早會發生的事情,因為 Terra/Luna 系統以高額利率誘使人進場的模式很像是龐氏騙局。

但也有一種說法是,許多東西都是 Ponzi ,只是倒了還是沒倒的區別而已。

對於這類的說法我比較沒感覺,我好像更喜歡那種「明確指出哪些是 Ponzi ,為什麼?;哪些不是 Ponzi ,為什麼?」的論述方式。


2022.06.01 Wednesday 看到的 DeFi 穩定幣的過去與未來:寫在 Terra UST 崩盤後 有提到, Terra UST 的弱點與失誤在於:

  1. 雙幣設計本來就較難防守,卻又直接使用內生變數「鑄幣稅代幣」LUNA 作為主要支撐,容易觸發死亡螺旋。

  2. 沒有足夠的應用場景;UST 180 億美元的發行量中,有 110 億美元存放於 Anchor 中孳息,如此過度集中且價值無法當下實現的應用場景,加速 UST 使用者於危機時做出拋售的決策,且市場沒有任何接盤買進的誘因。

  3. 30 億美元的 BTC 儲備,無法有效保護 180 億美元的 UST 發行量(僅 17%)。

  4. 雖然 Terra 後來另外增加了 BTC 作為其儲備,但這並不是一個最佳的選擇。Terra 應該選擇抵禦力更強大的 USDC、USDT 等作為第一道防線。就如同任何央行的第一道防線,都會是外匯存底,而不是黃金儲備。

  5. 被大戶砸盤的 UST 剛剛開始脫鉤時,發行商在流動性操作上太過生疏輕率,錯失護盤的黃金時機,UST 與 Luna 都在一週內全數崩盤,加起來超過 500 億美元市值憑空蒸發。

#Stablecoins


為什麼有些客戶會晚回覆?

發布於 2022-05-10 | 最後更新時間 2022-05-10 | 分類: Daily Why

專案能否如期交付,取決於我們自己能否準時製作完成,以及客戶能否如期回覆、而回覆的內容是否可控。

但客戶一但拖延交付,就會讓整個專案的進度延宕,甚至影響其他專案的進度,也會造成產能的空轉。

但客戶為什麼會晚回覆?

我想到的可能原因有:

  1. 客戶就是這樣拖延的個性。
  2. 客戶有更重要的事情要處理,因此延宕了委託我們做的事情的回覆。
  3. 我們給的東西太多,工作時程內處理不完回覆。
  4. 我們給的東西太糟,有太多點必須回覆,所以無法如期回覆。

那麼,對於這樣的狀況,可以怎麼做較好?

目前會嘗試的做法是:

  1. 逾期後,再詢問客戶,是否有已經確定的部分?而沒確定的部分,是否有需要直接約會議討論?
  2. 跟客戶提到若遲不回覆,可能會延宕後續的專案進展。
  3. 單純提醒一下,請對方要記得回覆。

這三種做法目的不一,視客戶類型與性格而定。 第一種是有更明確的推動意圖,通常會用在對時程或品質有明確要求的客戶。 第二種對我來說比較像是轉移談判的主客優勢,藉由這樣的留底,讓客戶未來必須要接受我們的時程規劃與安排。 第三種是那些比較沒有明確時間目標的客戶,那就是單純提醒一下,讓對方重新將「回覆」這件事情的優先序提高。

不過,這些做法有解決客戶「為什麼會晚回覆」的本質原因嗎?有沒有更好的做法呢?

#Customer Relationships   #Project Management


使用生產力工具有讓我更有效率嗎?

發布於 2022-05-09 | 最後更新時間 2022-05-09 | 分類: Random Thoughts

這好像是個很常見到的質疑:

使用那麼多生產力工具,真的比較有生產力嗎?

我的回答是:有的。

甚至即使是「亂嘗試各種生產力工具」,對我來講都是很有生產力的事,因為透過這過程也可以釐清自己喜歡什麼、對什麼感到興奮、對什麼感到好奇,以及對哪些工具無感。這些想法累積起來就有機會提煉出一些更有價值的想法。

#Productivity Tools


為什麼我一直在換工具?

發布於 2022-05-09 | 最後更新時間 2022-05-09 | 分類: Daily Why

在旁人眼中,我可能是那種一直在變換工具的人,一下 DEVONthink, Obsidian, Workflowy, Logseq, Heptabase, Dendron ... 好像每隔一兩個月,就會把自己的系統大改一番,跑到別的地方去。

但我覺得這些轉換是漸進的,也是一個嘗試找出自己對於工具最在意的重點的必經過程。

從這條產品線可以看到,有幾個元素是我特別重視的:

  1. markdown based
  2. local first (workflowy 跟 heptabase 沒有,但我信任他們)
  3. backlinks

邊打邊發現,這些想法沒有回應到原本的問題。

嘗試重新回答一次:

  1. 因為我對不同工具的差異點,以及他們嘗試提出的解決方案很感興趣。
  2. 每次讓我想嘗試的工具,都有在某一方面解決我之前無法被解決的需求。

換句話說,只要我有需求尚未被滿足,那就存在著換新工具的可能性。

那我還有哪些需求呢?

#Productivity Tools


Dendron 的優點 - 兼顧層級化的架構以及彈性

發布於 2022-05-08 | 最後更新時間 2022-05-09 | 分類: Random Thoughts

層級化的優點可以參考 Dendron 創辦人 Kevin S Lin 在A Hierarchical Tool for Thought裡面的這段文字:

  1. You can create, find, update, search, and remove information by looking up their hierarchies.
  2. You can remember your hierarchies with schemas, custom metadata to describe and enforce the shape of your hierarchies.
  3. You can transform your hierarchies, either a single note or an entire hierarchy at a time.
  4. You can combine hierarchies with other constructs like tags, backlinks, and note references.
  5. You can capture chronological as well as ad-hoc information using Dendron's builtin hierarchies
  6. You can visualize your hierarchies through hierarchical graph views
  7. You can share any subset of your hierarchy as a published site.
  8. You can move your notes and their hierarchy to any other tool.

但層級化架構的問題在:一個筆記不一定只出現在一個地方,因此過早思考他的「層級」與「位置」可能會讓使用者感到阻力。

對於這種是否選擇層級化的兩難,我覺得透過「Daily Journal/notes」這種固定的格式來紀錄是個好方法。

從整個筆記庫的架構來看,Daily Journal 本身就是一個僵固的類別,層級與位置不需要動腦就可以產生。

但以個別筆記來說,Journal 裡的內容仍可以擁有彈性,並且可以透過 tags, backlinks 以及 embed notes (在 Dendron 裡面叫做 note references)來達成交互參照以及讓同一筆記出現在不同地方的需求。

#Dendron


我會對怎樣的人提問?為什麼?

發布於 2022-05-08 | 最後更新時間 2022-05-08 | 分類: Daily Why
  • 對知道我不知道的事情的人,例如在嘗試新工具或學習新技術時,詢問有分享過經驗或想法的人,因為我覺得向他們學習更有效率。(但這些比較屬於 How 的問題)
  • 針對我在意的事情向人提問,通常會在這件事的發展與我預期不符時發生(超出預期時會問怎麼辦到的,低於預期時會問「為什麼會這樣」)
  • 但問「為什麼會這樣」容易有責罵感,可能需要換個方式問,例如:「是發生了什麼意料之外的狀況嗎?」

#Ask


如何將 Dendron 輸出成靜態網站並部署到 Netlify?

發布於 2022-05-07 | 最後更新時間 2022-05-07 | 分類: Daily How
  • 今天一整天都在嘗試使用 Dendron 建構我的 wiki site,詳細的步驟之後再來分享,中間遇到了好幾次障礙,差點想放棄。
  • 在這邊簡單描述一下整件事的概念,其實跟之前在部落格寫的 Pin 起來改版了!從 Wordpress 搬家到 Zola! Zola 部署概念很像。
  • 在 Dendron 資料的根目錄裡面,配置好 Netlify.toml 以及依照官網教學文件建立的 dendron-publish-site.sh 文件後,就可以在 Netlify 裡面直接抓取整個 repository ,並且進行自動部署。
  • 換句話說,未來的自動部署也不一定要透過桌面版的 Dendron 進行,只要 repository 有變動, Netlify 就會自動部署差異的內容。
  • 這點跟 Zola 的部署方式很像,差異可能在客製化程度以及部署的時間,但兩者類似的流程讓我可以用類似的工具來經營,覺得這是很棒的事。

#Dendron   #Static Websites   #Netlify


為何技術文件很容易過時?

發布於 2022-05-07 | 最後更新時間 2022-05-07 | 分類: Daily Why
  • 今天在透過 Dendron 的官方文件學習 publish 功能時,走了不少彎路,一直卡在一個 bug 裡面,後來我幾乎是逐步驟測試,才發現出現問題的步驟是什麼。
  • 想起之前在學習透過 Zola 部署網站時,也發現文件上的內容看起來已經有點過時了。
  • 我還沒有維護過面向客戶的技術文件,所以不確定這件事的本質原因可能會是什麼。表層的原因可能是資源不足,或者覺得這件事沒那麼重要,但流程上是否有改善的空間?現行的工具有沒有適合拿來處理這個問題的?
  • 希望以後的自己有能力回答這些問題。

#Technical Documents


建構我的 wiki site

發布於 2022-05-06 | 最後更新時間 2022-05-06 | 分類: What I Tried Today
  • 上週透過 Logseq 內建的 export 功能,很順利地把頁面整個輸出成靜態頁面,並且上傳到自己的網域裡面,開始建立自己的小小 wiki page。
  • 不過這個方式以目前少少的測試頁面內容量來說,打開就需要一點載入時間,而且也無法自訂各種內容(包含 logo 、metadata 等),有點不滿意。
  • 所以就開始思考&研究其他的解決方案,此時看到一篇文章提到可以把 Tiddlywiki 輸出成靜態頁面,就嘗試研究了一下,但研究一晚下來覺得, Tiddlywiki 學習曲線感覺頗高,而且整體編輯或維護的流程有點...繁瑣(可能是我還不太會用),好像也沒有很符合需求。
  • 還有一個選項是透過 Logseq 的 Schrödinger 插件,把 Logseq 頁面直接轉成 Hugo 的靜態頁面。
  • 但這個方案感覺起來,反而是以「文章」為主了,不像 Logseq 內建的 Export 功能,在輸出後,還是可以在頁面上面操作它的大綱型介面以及雙向連結。
  • 感覺一時之間好像找不太到好的解決方案,需求:
    1. 每月低於 $5 的費用( Obsidian Publish 好貴)
    2. 能在本機迅速編輯,並且迅速匯出成靜態網頁
    3. 要有雙向連結功能(被連的頁面能看到誰連到它)
    4. 輸出的網頁有辦法自訂一些 metadata
  • 結論:我再研究(慢慢等)看看好惹

#Personal Wiki


為何想每天分享 book quotes?

發布於 2022-05-05 | 最後更新時間 2022-05-05 | 分類: Daily Why
  1. 覺得大家都喜歡看書的精華內容,覺得這種內容或許會有市場。
  2. 為了要分享這些內容,會逼自己去看書。
  3. 覺得能持續做一件事是很棒的事

#Book Quotes


如何讓 Twitter 增長? by madawei

發布於 2022-05-04 | 最後更新時間 2022-05-04 | 分類: Daily How
  • madawei 的Twitter 增長分享這篇提到幾個 Twitter 增長的關鍵:
    • 多寫簡單、直白、有價值的資訊,例如個人經驗總結、資料分享
    • 多關注有價值的帳號,他們寫的都是你感興趣的領域,而每天在刷推的過程中就可以找到發推的機會
    • 個人的部落格有圖盡可能配圖,並寫一段總結性的推文
    • 少即是多,和個人關注領域無關的資訊可以少發。

#Twitter


Why ask why?

發布於 2022-05-04 | 最後更新時間 2022-05-04 | 分類: Daily Why

今天看了發現問題思考法後,決定開始嘗試每天問自己一個 Why,並且嘗試回答看看。藉此找出更多上位的概念。第一天的 Why 就來問 「Why ask why?」

書中提到:

  • Why 所表示的並非「單發性事象」,而是事象間的關係性。總之,Why 是用來畫關係性這一條線的疑問詞。只有透過這樣的疑問,才能夠探究關係性的疑惑,進而察覺更進一步的未知。
  • 透過重複問為什麼,就能逼近本質,重新定義更好的問題,進而發現真正應該解決的新問題。
  • 透過問 Why 可以思考「目的」而非「手段」,藉此改變擂台、改變遊戲規則,這樣就能去思考「不必執行原本的手段也可以達到目的」的做法。

所以持續問「Why」的原因是,探究某件表象事物背後真正的本質是什麼,藉此定義出更好的問題、更應該被解決的問題。以 哈佛這樣教談判力 的概念來說,就是要關注利益而非立場,才有機會找到雙贏的解決方案。

#Good Questions


如何透過自己不同意的論點發展想法?

發布於 2022-04-26 | 最後更新時間 2022-04-26 | 分類: Daily How
  • 今天看了 David Perell 的 Tweet,他寫說,練習把那些你不同意的論點寫下來,然後嘗試著站在他們的角度去讓論點變得更好,這樣的練習是很好的事。
  • 這個想法看起來是來自 Tyler Cowen 的文,裡面有一句提到 "Much of my writing time is devoted to laying out points of view which are not my own."
  • 我想到以前我很喜歡的一個老師曾說過,他在思考一個論點時,都會思考反對者可能會怎麼想,接著他再想,可以怎麼破解對方的論點,接著又再想,對方可能會怎麼反擊,這樣想個幾輪下來,自己的論點就會越來越強壯了。

#David Perell   #Writing


選擇 Second Brain 的標準

發布於 2022-04-24 | 最後更新時間 2022-04-24 | 分類: Random Thoughts
  • 看了 Moving to Obsidian as a Public Second Brain ,作者提到選擇 Second Brain 標準的那段跟我的想法很像,標準如下:
    • Markdown based
    • Git
    • Offline-ready Mobile app
    • Bidirectional Linking
    • Publish with Search
    • (Nice to have) Image and File storage
  • 我的話應該是:
    • Markdown based
    • Outliner
    • Bidirectional Linking (要有 transclusion 的效果)
    • Daily Journal mode
    • Mobile app
    • (Nice to have) Publish

#Second Brain


關於 Eugene Wei 寫的一小段話

發布於 2022-04-24 | 最後更新時間 2022-04-24 | 分類: Random Thoughts
  • 看了 Eugene Wei 網站的 My archives ,這已經是 2012 年的文了,寫著他搬遷網站後,有些舊文沒有空整理,就都放在這個頁面。裡面有一段話很喜歡:

  • Going back through my old posts is often embarrassing, like hearing a recording of my own voice or seeing a photo of how I used to dress or comb my hair. But mostly it's like reading letters from past versions of myself. It amuses me.」

  • 我也常常因為看到過去寫的東西而覺得有點尷尬,但又會覺得,那就是曾經的我,也是為了變成現在的我而必經的我。

#Eugene Wei   #Quotes


Mess with DNS

發布於 2022-04-23 | 最後更新時間 2022-04-23 | 分類: What I Found Interesting
  • 今天發現 mess with dns 這個網站,覺得很有趣,隨機分配給使用者一個 domain ,然後使用者就可以照著旁邊的指示去增加 A record 與 CNAME record ,進而了解這些設定是怎麼運作的。
  • 也喜歡它簡單的介面設計,整個體驗很流暢。因此看了一下 about ,發現還有 wizard zines 這個網站,好像是透過漫畫介紹這些複雜的網路&程式相關概念。不過我還是更喜歡單純的文字內容。

#DNS