EP 2. [ Poseidon 週年回顧 ] 公司發展歷程及創辦人心路歷程 II
以下完整內容皆出自 10.10~10.11 的 LINE 社群活動，由 CEO Light (小光) 親自向各位講述過去一年的發展、團隊心路歷程、目前技術、未來發展
Notion 筆記連結 : 10.10~10.11 | Poseidon 介紹逐字稿總整理
2. 發幣之外的瓶頸 — 產品發展 & 業務銷售 , 重新規劃技術藍圖
除了發幣之外，產品發展和業務銷售也是遇到很大瓶頸；在 IEO 的時候，我們有說當時有不少公司都有試用，這點算是 half truth 吧，因為當時 mike 原本做的產品 QCDN 確實有些公司在用，包含大家可能都聽過的 AV 網站
但是問題在於原本的 QCDN 跟 區塊鏈技術並沒有整合，我們雖然發了幣，但跟服務本身沒有對接；而原本 QCDN 的架構非常缺乏彈性，也改不動，搞了好幾個月，實在沒有辦法
我當時索性放棄第一版的架構，自己想辦法重新讀資料讀論文，自己重新定技術藍圖。所以如果是老礦工的話，可能會記得2019年 11月我們也開放台灣礦工，後來在今年農曆年前停止挖礦；原因就是當時原本是用舊版的架構，就算礦工數很多，但我們沒辦法利用這些節點的資源，但卻一直發點數
我們今年農曆年後新版的架構做好，如果有礦工關注我們的發展的話，應該會看到我們後來有陸續發佈 linux 版和 synology 版的 QLauncher ，從礦工的角度可能沒感覺，但從我們產品發展的角度來講，其實 QLauncher 跟原本 QEdge 的差異非常大
如果要比擬的話，QEdge 就有點像以前 2G 手機時代預載軟體的概念，一旦裝了就沒辦法更新或修改，而 QLauncher 則是比較像 iPhone 之後，有了 App Store，我們可以隨時更新
也就是說，過去只有 QEdge 的時候，我們只有做 CDN，因為預載的功能就是 CDN，沒辦法調整也沒辦法增加，但是改成 QLauncher 之後，我們可以隨時佈署調度各種服務在不同的節點上
所以我們做了很多實驗，包含 IPFS (分散式儲存)、VPN、Web Hosting、Transcoding 等；後來我們也開放海外節點挖礦，也是從零開始，到目前又超過 2000 個節點，聚合了超過 1TBps 的頻寬、10 PB 的存儲空間
技術升級後，目前最成熟的屬分布式儲存應用，已完成 POC
目前我們最成熟的應用應該算是 ipfs ，因緣際會，總之我們現在正在做某個案子。
其實分散式存儲的效率是非常差的，大家稍微想像一下就知道，把檔案切碎，然後存到分散到世界各地的節點，若是要取用檔案的話，必須先去 ipfs server 認證取得分散部分檔案的位址，然後到那些位址去把檔案取回，然後重組、解密
這整個流程，只要中間有一個環節卡住，就不會動了，檔案也要不回來
所以這也是 ipfs 公網上最大的問題，效能低的節點太多，導致整個 ipfs network 效能非常差，所以我們在開發的時候，不得已也只能自己建私有的 ipfs network，避免有這種效能的瓶頸，上述問題需要不斷修改 & 克服
3. 持續探索分散式應用 — VPN , Transcoding …. / 現存難題
每天從大陸流出來的流量超過 100G，我們基本上完全沒宣傳，就是 hugo 之前去大陸的群裡貼一貼 vpn 的連結，後來七月 hugo 去當兵之後就沒推了，但是也一直有人在用，所以這個需求是很明確的，只是我們也沒空去推廣
另外我們也做 transcoding，這樣講大家沒感覺：我舉個例子，也許有些人有聽過 livepeer；他們主打的就是分散式轉檔服務，而這個我們其實也有做實驗 POC，基本上就只是佈署一個轉檔的程式到節點，然後提供 Open API 出來
現有號稱 “分散式” 架構 , 仍基於中心化雲 (AWS, GCP ) 運行
另外，也許有些人聽過 perlin，他們說要做 分散式 CDN，但是到目前為止應該是什麼都沒做；或者也許有些人聽過 ANKR，他們的定位應該是 “instant cloud infra for blockchain”，簡單來說，他們可以 “一鍵佈署 blockchain 節點到雲平台”，用的技術就是 kubernetes，但還是佈署到 cloud 上
對我來說，佈署到 GCP, AWS 上，跟脫褲子放屁一樣，講說想要做分散式架構，但最終其實也還是佈署到集中式的雲平台，而且最終他們還是要付美金給 GCP or AWS 的 (怎麼可能收 ANKR)，所以他們的收費不可能比雲平台還要低
也就是說，現階段所有你們曾經聽過的項目，只要還佈署在雲平台上，就永遠無法脫離 GCP, AWS 的控制，成本結構也永遠會被他們所控制
用戶網路環境百百種，調校起來及其耗時耗神
而我們花最多時間去解決的，就是想辦法把節點裝到用戶家裡，這件事聽起來很單純，但實際上超級困難，因為用戶家裡的網路環境千奇百怪，硬體環境無奇不有
老實說，如果不是我們之前經歷過這麼多用戶環境的調校，我們可能也很難在 1–2 個月之內就搞定公托的 POC ，所以說真的，我每天都覺得很苦啊，看到別人抹奶油吃壽司，賺好多錢，然後我們每天都在修 bug
建立平台的難處 — 建置期長 , 成本高
平台的難處，在於前面的建置期會很長，必須要想辦法累積累積，直到整個平台的使用量達到某個 critical mass point，才會開始創造商業價值，但這個累積的過程，就會是競爭門檻
包含大家所知道的臉書也是如此，或者說，AWS 也是如此，其實先行者優勢是有道理的
關鍵技術之一的重要環節尚待打通，開發 QLauncher v2
目前還有一個最重要的環節還沒打通；我們遲遲還沒辦法按照貢獻度計算用量，所以也就沒辦法按照貢獻度發獎勵，所以也就沒辦法按照服務收費，所以也就沒辦法去做產品行銷推廣
但是為什麼還沒辦法按照貢獻度計算呢？因為必須先從每個節點定期把流量紀錄送回 server，然後再分析、統計、驗算；我們現行的 QLauncher 因為某些技術問題，老實說沒辦法支撐超過 1000 台以上的節點，也不支援 log 收集
所以其實我們正在進行 QLauncher v2 的開發，除了強化 HA 之外，也會加入 log 收集的功能，希望在很短的時間內就可以做到
4. 貢獻度評估很重要 , 光尋找「最適合」就非常困難
其實 contribution 貢獻度是很重要的，因為這代表著每個礦工的工作量，白話講就是代表礦工的收益；像是 bitcoin 最核心的演算法其實就是 PoW (proof of workload)，這代表著礦工的算力 → 收益，而且如何決定某工作量要交由哪一個礦工去完成
（ 我試著用比較簡單的方式說明，不然大家可能會直接睡著 XDD )
最難的其實是如何決定工作量如何分配，舉例來說，我有 1000 個節點，但只有 5個工作量，那照理說我應該就是找最適合的節點來分配工作；但是，這個「最適合」就非常非常的困難
舉例來說，以 VPN 來說，因為從大陸連出來很多 IP 其實都被擋掉，連線品質最好的其實是從香港、澳門出來，所以在 VPN 的工作量我們應該就要分配給香港、澳門節點去處理
分散式服務備援機制 — P2P Network 網路環境不穩是常態 , 目前缺乏適合管理機制
而分散式儲存需要容量大、頻寬品質好、上線時間穩定，這些都需要一定時間累積數據才能夠分析。並且，分散式架構最困難的地方在於，節點不是永遠不會斷線的，如果今天某一個節點斷線，會不會造成服務的中斷？
如果要讓服務不中斷，那麼就必須要有備援機制；用儲存舉例，如果存一份備份不保險，那就存兩份，或者四份、八份，存越多份，風險越低
大家可能都沒有意識到，其實最主要的問題來自於我們是使用分散式的節點架構，而且都是用戶家裡的裝置，網路環境不穩定是常態，過去這種架構叫做 P2P Network，並且沒有適合的管理機制
但現在配合區塊鏈技術，我們可以透過智能合約提供分散式治理的可能性
治理代幣 QAS — 若以 DeFi 項目舉例 , 猶如 Compound (COMP) , Yearn.finence (YFI)
這部分也就跟 QAS 有關係了，之前有提過，我們希望 QAS 作為治理代幣的角色，過去這樣講大家聽不懂，現在如果講說 QAS 就是 Compound 的 COMP，或者 yearn 的 YFI ，也許反而比較容易理解
延伸閱讀：關於 QAS 機制及現狀，目前難題 ? — Light 快閃 AMA ( 08/12 )EP1 創辦人分享自身炒幣經驗，因緣際會發現分散式服務 + 代幣經濟 (Token Economy) 可以打造出前所未有的 P2P Network。初期許多困難，團隊第一年幾乎在失望、絕望中度過
EP2 分享團隊組建、技術開發、向外拓展所遇到的瓶頸。我們如何重新定義架構藍圖，開發 & 優化舊版本軟體，探索分散式應用、技術合作，並發展落地應用場景
EP3 將帶大家更深入的討論 P2P Network ，先從現有的分散式儲存 IPFS + FIL 舉例，再帶到分散式服務的潛在市場及其優勢，最後是未來 Poseidon 整體的戰略方向
EP1. [ Poseidon 週年回顧 ] 公司發展歷程及創辦人心路歷程 I
EP2. [ Poseidon 週年回顧 ] 公司發展歷程及創辦人心路歷程 II (本篇)
EP3. [ Poseidon 週年回顧 ] 公司發展歷程及創辦人心路歷程 III
----
(完整版) Notion 筆記連結 : 10.10~10.11 | Poseidon 介紹逐字稿總整理Poseidon 官方社群 | Facebook , Twitter , Telegram(Ch) , Line (Ch) , Telegram (En)
