銀行與大企業不得不正視的區塊鏈浪潮,是炒作?還是未來主流?

「暫停,這東西根本不需要區塊鏈!」 — 某企業創新部門主管說。

銀行與大企業不得不正視的區塊鏈浪潮,是炒作?還是未來主流?
參考[1]:GoodFirms,針對50+個區塊鏈開發公司與專家所做的深度研究報告

「暫停,這東西根本不需要區塊鏈!」 — 某企業創新部門主管說。

這是我最常聽到的一句話。我們常常大聊特聊區塊鏈能帶來的好處,它看似可以解決生態系的信任問題、增加企業間數據同步的效率與可信度。但該如何去思考這個必要性?

看著Facebook全力促成Libra的發行,JP Morgan的美金穩定幣JPM Coin也開始讓企業申請試用,IBM、Oracle、SAP、Amazon和Microsoft都有成熟的區塊鏈即服務(BaaS,Blockchain-as-a-Service)平台。今年5月,雲端客戶管理平台Salesforce也推出了企業用的區塊鏈服務產品

是否要導入,看起來已經不是閉門會議中,討論出「需要」與「不需要」這麼簡單。站在企業的立場,我們該如何理性評估要不要投資在區塊鏈技術上呢?

是議題炒作,還是會是產業顛覆呢?我們再來參考大家的一些數據吧。

以下將根據知名調研機構GoodFirms,針對50+個區塊鏈開發公司與專家所做的深度研究報告,與Deloitte 2019 Global Blockchain Research 進行參考。

Deloitte 總結了1,000名企業高管,對於2019年及以後計劃的採訪:

  • 84%的人認為區塊鏈最終是會實現擴展的,並將實現主流採用。
  • 40%的公司計劃投資超過500萬美元
  • 41%的人認為該技術目前被過度炒作

評估1:你所屬的產業,會不會被區塊鏈顛覆?

  • 金融相關 92.3
  • 供應鏈相關 89.3
  • 政府相關 69.2
  • 保險相關 30.8
  • 資安相關 23.1

「金融相關」領域高達 92%。金融產業在現有流程中存在眾多痛點,如耗費大量人力和時間來驗證、審批分散且不透明的交易資訊,許多大銀行都期望區塊鏈能替這些問題解套,組建區塊鏈小組或部門即是第一步;「供應鏈相關」也符合區塊鏈應用場景的條件 — — 供應鏈資料斷點多,加上彼此之間有多種商業模式,但互不完全信任。其他類型也都有不少案例,金融區塊鏈函證、個人健康數據與保險公司……等等,不難發現上述場景的痛點 — — 就是各方都怕拿到假資料,都想要取得「資料的真實性」。

評估2:你可以拿區塊鏈做什麼?

  • 資料驗證:43%
  • 資料存取、共享:40%
  • 支付、數位貨幣:37%
  • 追溯與溯源:32%
  • 認證:30%

延續評估 1 的結論,追求資料的真實性,正是使用區塊鏈技術應用的首要用途之一,但是該如何「合理的使用」區塊鏈呢?

企業與企業間過去的資料交換與傳遞,過去都是你一份,我一份的。區塊鏈帶來的改變,它能確保各方擁有的是「同一套資料」,而且各方都不能篡改的。

文章後面會在資料交換與驗證舉例,點對點的支付、貨幣也是非常的合理的用途,把這份「資料」改成「一套帳本」,省去了大量的清結算、記帳成本;把這份「資料」改成商品資訊或認證資訊,就能更有效率的達到商品溯源和真品防偽的目的。許多上述提及的區塊鏈應用,都可以透過「同一套帳本」來解決驗證成本過高的問題。

評估3:區塊鏈能帶來的好處

  • 透明 61.5%
  • 不可篡改 58.5%

當「同一套帳本」的高透明度解決了數據驗證及徵信成本過高的問題,卻在企業導入時引發隱私性的高度疑慮:

此時就陷入了「隱私悖論」:既要隱私、又要公開透明的矛盾。

現今,這點已經可以放心,已有非常多的技術方案來滿足這個需求。例如PegaSys的私有交易管理器Orion、BSOS 的私帳本技術。這些都是搭配其他機制,來讓「原始資料不上鏈」的做法,還是能確保鏈上有公開透明的存證。

另,也有走硬數學的流派,例如:多方安全計算(Multi-Party Computation)、全同態加密(Fully Homomorphic Encryption)等的方法來打破「隱私悖論」,然而此類技術容易在企業內部與監管機關造成理解及推動上的困難。

想像一下,任何會議之前都要先問「請問在場有沒有數學家?」才能進行下去,只會在無形間堆高企業的導入成本。


區塊鏈撻伐者觀點

「這些不用區塊鏈也能做的到!」

在驗證可行性的階段,大多數的情況的確是這樣,原因為如下:

  • 參與者不多,好處還沒有那麼具體;
  • 有便宜可信的第三方,所以不太需要建立額外的信任基礎;
  • 本來就不一定需要區塊鏈,區塊鏈可以更有效率,卻因導入成本高,評估短期內經濟效益不足。

根據這些反方觀點,以下舉一個例子來表達有無區塊鏈的區別:

資料交換與驗證

我們就「資料交換與確認」的情境,假設這100家公司,若沒有一位老大哥和第三方平台的情況下:

情境一、若用傳統資料庫,不同的公司之間,需要一一去做資料串接(API Integration)。A公司要與B公司串接,B要與C串接,C還要與A串接⋯⋯,那請試想這時有100家公司呢?每家公司要與99家公司進行資料串接。

區塊鏈讓100家公司只串接一次鏈上的資料。

情境二、接續著上述情境,資料在分別各自交換之下,肯定有不一致的情況發生;為了保證資料一致,導入區塊鏈可以確保資料保證同步;一但寫入,就不可更改,這是傳統資料庫也提供不了的價值:資料在各方的「一致性」。
區塊鏈讓100家公司的資料保持一致。

情境三、可信驗證的傳遞:當只有兩家公司,區塊鏈是沒有發揮的空間的。A公司與B公司互相確認一份資料時,這時候還真的不用區塊鏈。但當C公司想要確認這份資料,有什麼方式可以快速的知道這份資料已經由A公司與B公司確認過?

導入區塊鏈之後,每間公司能在區塊鏈上宣告自己「確認」了一份資料,這份確認是無法被他人篡改的,並會到全網同步,讓其他99家公司知道;同樣的,若有第101家公司加入了這個網路,它也能相信這筆資料,上面有誰確認過了。善用區塊鏈,也確保了這100家公司在沒有老大之下,有個可信的基礎。

區塊鏈上的誰、什麼時候、寫入了什麼資料,無法造假,具有可信的基礎。

總結

採用區塊鏈還是有不少難度和挑戰。包含用戶的認知、可不可以銜接現有系統與流程、如何滿足安全性與合規性、如何讓多個參與方達成協議等等技術以外的問題。沒人能站出來準確的預測區塊鏈必定會用在什麼地方,會不會是主流,也的確有不少公司,利用區塊鏈之名做為新聞議題的炒作。

雖然尚未經大規模的商用認可,早期的驗證也已經證明它在一些用途上是非常有潛力。隨著技術面正不斷演進,今年已經比過去更貼近商業與真實場景,區塊鏈的導入將會更有經濟效應。研究報告也指出,越來越多人保持樂觀的看法,尤其是大企業與金融機構,近年的大規模Best Practices就靠你們了!


參考[5]:2025年會成為主流的一份研究報告

參考連結:

[1] https://www.goodfirms.co/resources/blockchain-development-research

[2] https://www2.deloitte.com/content/dam/insights/us/articles/2019-bsoglobal-blockchain-survey/DI_2019-global-blockchain-survey.pdf

[3] https://media.consensys.net/announcing-orion-a-private-transaction-manager-in-java-661a828111cc

[4] https://www.statista.com/statistics/647374/worldwide-blockchain-wallet-users/

[5] https://provide.services/state-of-enterprise-blockchain-study-report/

Read more

掌握幣圈脈動,告別 FOMO 的資訊自動化流程嘗試

掌握幣圈脈動,告別 FOMO 的資訊自動化流程嘗試

幣圈訊息瞬息萬變,是否常常覺得很 FOMO 呢? 常常一個小時不看新聞就可能錯過了新的趨勢或是有用的消息。因此,我嘗試打造一條「獲取資訊自動化流程」。我希望透過以下幾個步驟,將「從 RSS 收集內容 → 摘要與翻譯 → 儲存 → 在發文時快速取得重點資訊」的流程自動化或半自動化,讓我在想要發佈 Twitter (X) 貼文時,能有即時且經過整理過的資訊可供參考。 整體流程概述 目標流程:RSS → Apify → OpenAI → Airtable → Chrome Extension → 快速分享 * 取得 RSS 新聞來源:定期自動抓取最新文章列表。 * 解析並擷取內文(Apify):從原始頁面擷取重點文字段落。 * 整理與生成摘要(OpenAI):運用 AI 將冗長文章化為精簡摘要。 * 儲存到 Airtable:將標題、連結、摘要等資訊結構化存放,方便後續查詢。 * Chrome

最常見的 Git 工作流程 - GitHub Flow

一種簡單的工作流程,適用於快速開發和持續部署的小型專案。 流程 1. 始終從 Main 分支創建功能分支:bashCopy codegit checkout main git checkout -b feature/my-feature 2. 在功能分支中開發,並隨時提交: git add . git commit -m "Implement feature" 3. 開發完成後推送到遠端 git push origin feature/my-feature 4. 發起 Pull Request 並進行代碼審查: * 在 GitHub 上創建 Pull Request。 * 通過代碼審查(Code Review)。 5. 審核完成後合併到

測試驅動開發 (TDD) 與單元測試、整合測試的概念簡述

在現代軟體開發中,測試已成為不可或缺的一部分。不僅能幫助開發者捕捉錯誤,還能促進代碼的模組化和可維護性。本文將深入探討單元測試、整合測試的區別,以及測試驅動開發 (TDD) 的核心流程和實踐技巧,幫助你快速掌握測試的精髓。 也許 AI 程式碼生成工具,最能快速優化寫測試的開發時間。多少來學習一點測試相關的知識。 * 理解單元測試 (Unit Test) 和整合測試 (Integration Test) 的區別。 * 熟悉測試驅動開發 (TDD) 的概念。 單元測試 vs 整合測試 * 單元測試: * 適合測試邏輯簡單且內部不依賴外部資源的功能,例如算法、數據處理函式等。 * 主要用於開發階段,快速檢查某段程式碼的邏輯。 * 整合測試: * 適合測試業務邏輯需要依賴外部模組(例如資料庫、第三方 API)時的交互行為。 * 用於確認系統內部的協作是否無誤,通常在測試環境下執行。 特徵單元測試 (Unit Test)整合測試 (Integration Test)測試範圍單個模組或函式多個模組或系統的整合依賴性獨立,不依賴其他模組或外部資源需要依

PM 加速開發:ChatGPT 到 Cursor 再到 Windsurf 的體驗比較

我是技術背景出身的產品經理,十年前曾是一名寫 Objective-C 的 iOS 工程師。近年來,我利用零碎時間,結合 AI 工具,進行產品發想與概念驗證,並打造一些功能型網站。自 2024 年 6 月起,我的體驗大致可分為三個階段,以下是我的學習與心得分享。 第一階段:ChatGPT 助力,但流程繁瑣 最早是用 ChatGPT 協助產 Code,我一筆一筆貼到我的程式碼下。我要詢問怎麼改動的話,也要將程式碼貼回 ChatGPT,在大量的複製貼上等待的過程,非常慢跟耗時,瀏覽器也會隨著大量的文檔開始變慢。這時候,我從不會到能做出一個聊天機器人網頁,大概花一個禮拜。我也是在這個階段學會了如何用 Vercel 快速部署架站,還有基本的 Git 指令。遇到一點問題常常會卡關很久,要邊做邊學。 第二階段:Claude 加速開發流程 Claude