---

layout: post
title: ‘2020.07 BSV 線上研討會：Bitcoin SV 應用層協議’
date: 2020-10-04 23:00:00
comments: true
status: public
categories: [Bitcoin]
tags: Bitcoin, BSV, 應用層協議
num: Bt-006-2010

(BSV Webinar) Bitcoin SV 應用層協議

概述及內容提要

兩個月前，比特幣協會 (Bitcoin Association) 與 nChain 聯合舉辦了一次線上研討會 (此 Webinar 全系列共 8 節講座，連結見文末)，針對 BSV 的一些技術做了系統而深入的講解。

研討會整體主題梳理

這次研討會的內容全面而豐富，我簡單按照主題列一下：

1. 節點技術 - Bitcoin SV 全節點相關的技術，包括安裝，配置，基礎架構，效能測試 (第 1/6 節)
2. 協議架構 - Bitcoin SV 分層網路，應用層協議，及商戶介面 MAPI (第 2/3/4 節)
3. 可證公平 - Bitcoin SV 可證公平遊戲 (第 5 節)
4. 門限簽名 - Bitcoin SV 上的門限簽名技術，及相應的 Nakasendo SDK (第 7/8 節)

很榮幸，我有機會成為講師中的一員，參與了這 8 節課程中 “Bitcoin SV 應用層協議”(連結見文末) 這一節課程的講解。

本文內容梳理 (應用層協議)

下面是講稿的全部內容，共 26000 餘字，略讀全文需要 20-30 分鐘。

由於全文較長，我將其整理為下面三個小節，併為每部分內容劃分了小節，並新增了小節標題。

1. 協議棧的架構模型 (內容包括 Bitcoin SV 應用層協議棧與 TCP/IP 協議棧之間的模型與架構對比，及其演化及競爭的關係)
2. 應用層協議與實踐 (彙總了 BSV 生態內活躍的絕大部分應用層協議，及對應的開發工具，以及對開發者而言，有價值的原則，技巧與實踐)
3. 課後問答和釋疑 (如何對不同協議做選擇和取捨，協議的演化，等等，及我向 Jack Davies 請教時，Jack 對部分問題的進一步闡釋)

正文部分

(演講正文由此處開始)

〇、 整體介紹及大綱

大家好，歡迎大家參與由比特幣協會和 nChain 聯合主辦的 Bitcoin SV 系列線上研討會，本活動於每週二及週四晚上 8:00~9:00 進行，為期一個月。我是顧露，是比元科技的創始人，也是 Bitcoin SV 上的應用小聰遊戲的開發者。

本期講座的主題是 **Bitcoin SV 應用層協議**，內容包括了 協議棧的架構模型 和 應用層協議與工具概覽 ，也就是說包含了理論和實踐這兩個部分，主要面向對 “Bitcoin SV 應用層協議特性”，以及 “在 Bitcoin SV 上開發應用程式” 感興趣的聽眾，也歡迎其他的開發者。

大家在聽講座的過程中，如果有任何問題可以在評論區提出，助教老師會進行問題收集，我也會在講座結束後統一進行解答。最後希望各位保持課堂的秩序，在接下來的一個小時裡有所收穫。

好，這裡我們展開說一下今天的內容框架。

在這裡可以看到我們剛剛說的兩個部分，一個是協議棧的架構模型，另一個是協議和工具概覽。

那麼在架構模型這一塊，我們會對比應用層協議棧跟傳統網際網路的 TCP/IP 協議棧，做一個他們之間的模型和架構的對比，以及他們演化和競爭的關係。在協議和工具這塊，我們會重點介紹各種協議 (protocols) 主要分為資料協議、支付協議和token協議，我們會逐一地講到它們各自的特點。最後會介紹一下當前有哪些工具可供使用。

那麼對開發者來說，我們這一講既有協議架構的理論的知識，也有很多開發者他們針對自己的需求，定製各自的協議，及相應的探索實踐，這樣整體上來講，可以作為開發應用時的一個比較全面的參考。

一、 協議棧的架構模型

好，我們現在先一起來看一下傳統的網際網路抽象模型。目前已有的抽象模型有兩個，一個是 OSI 模型，一個是 TCP/IP 模型。

1. 傳統網際網路抽象模型 (TCP/IP)

這兩個模型我簡單介紹一下，OSI 是上世紀70年代網際網路形成早期的時候，定義的一個模型，這個模型相對比較繁瑣，從最上面的應用層到最下面的硬體設施一共有7層，那麼反過來 TCP/IP 協議就相對實用一些，他把 OSI 的7層協議簡化成了4層，在右邊就可以看到，我們看右邊的圖它是比較有特點的，從最上面的就是應用程式所在的層開始，那一層裡面應用程式的資料，實際上只是他自己的資料，然後為了被傳輸，加了一個 UDP header，再往下一層為了 IP的定址和路由，又加了 IP header，到最後硬體層，為了讓它在裝置之間可靠的傳輸，又加了資料幀的幀頭，叫 frame header。

那麼我們的疑問是：bitcoin 的模型是什麼樣的？在傳統的網際網路抽象模型裡邊，bitcoin 應該在什麼位置？

好，在回答剛才那個問題之前，我們先簡單的把 TCP/IP 模型裡面，每一層的上下文介紹一下，那麼後續理解 bitcoin 網路模型的時候，就更方便一些。

我們從下往上一層一層地看，首先是物理層，這一層是網路的基礎設施，資料鏈路層，主要是開放網路上的硬體裝置以及這些裝置之間的物理連線。然後到了網路層，這一層提供的功能是定址和路由，也就是幫助不同的參與者找到自己的目標地址，他們所在的位置。網路層是IP協議實現的，我們知道現在網際網路上 IPv4 的地址非常緊張，正在普及 IPv6，這個是大的背景。

那麼在這個之上是傳輸層。這一層為整個網際網路提供了健壯可靠的訊息傳輸，是基於TCP協議實現的。TCP協議通過損失了一部分效率，來保證訊息傳輸的健壯和可靠。如果你想避免或者說減輕這一部分效率損失，可以用 UDP 協議。對大多數的網際網路應用來說，TCP協議是他們構建其他協議的基礎，比如說我們訪問網站，瀏覽網頁需要用到 HTTP/HTTPS，這些協議就工作在 TCP 上。

在最上面的應用層，這一層是直接面向使用者的，通過無數的這種針對特定的具體的情況下面的協議，就可以幫助使用者去實現各種各樣的資料交換，來實現千差萬別的資料服務。我們常見的雲端儲存、視訊直播、網路遊戲、移動支付，這些都是應用層的服務，所以你看這個層，其實它比其他的層佔的面積都大，這是應用層它豐富和複雜性的體現。

那麼我們簡單介紹了一下這4層網路模型，給之後我們理解 bitcoin 的模型，提供一個對比和參照。

2. TCP/IP 與 OSI 的對比

好，在這之前我們先簡單對比一下 TCP/IP 和 OSI。

可以看到左邊的應用層，在 OSI 裡面，實際上是應用層，表示層和會話層，共三層。

這裡我展開介紹一下，(右邊第一項) 應用層裡面，是各種應用層的協議，什麼 HTTP、FTP 這些協議在 OSI 裡也是屬於應用層。 (右邊第二項) 那表示層是什麼？它實際上是各種不同的資料格式，比如說圖片有 JPG、PNG 這種的，然後不同的演算法，不同的加密方式，其實也是表示層的一部分，因為所有的這些資料，實際最終看起來是什麼樣子，實際上就是一種 presentation，是一種表示和呈現。 (右邊第三項) Session 會話層。 會話層是對應到主機的程式裡面，是本地主機跟遠端的主機他們之間進行的會話，以及與會話相關的維護性工作。

那麼除了應用層兩者不一樣之外，還有底下的物理層 (也不一樣)。 在 TCP/IP 協議裡面，底下的物理層在 OSI 模型裡，實際上被拆成了兩層，對應起來說，物理層實際上是跟物理裝置直接相關的，是建立維護斷開物理連線用的。資料鏈路是建立邏輯連線，去處理資料幀用的。(這兩者) 一個是物理性的，一個是邏輯性的，總的來說就是它們的差別其實並不大。

3. MetaNet 模型 (整體演化)

好，那麼講了傳統的模型了之後，我們來看一下 metanet 的抽象模型。

它需要支援各種不同型別的資料，就像傳統網際網路一樣，有非常豐富的資料(處理和呈現能力)。而且我們會去講解為什麼會設計成這樣，他是怎麼工作的，從內到外去理解這個系統。

大家可以看到左邊的圖，為什麼選左邊這張圖？它實際上是 bitcoin 的層次化網路，也就是所謂的 BLN (Bitcoin Layered Network) 這個層次化網路，因為時間關係，在這一講裡是不會展開，但是隨著 Bitcoin SV 的發展，我們可以去觀察和驗證，看看真實世界裡網路的發展會不會像圖上這樣去演化。

好，在開始講之前我先問一下，作為開發者來講，你覺得 bitcoin 應該是在哪一層？

有幾個選項：物理層、網路層、傳輸層、應用層和“都不是”。

我在這裡停留一點時間，大家可以思考一下。

這是一個很有趣的問題，因為這個問題實際上是開放的，目前來說沒有一個嚴格意義上確定性的標準答案。

接下來我們會解釋一下，到目前為止 Bitcoin SV 的實現情況，以及未來在這個基礎上，我們期望去實現的理想的情況。這樣應該就能說明白， bitcoin 是怎麼從根本機制上，去結合並驅動整個系統，在不同層面上去創新的。

好，我們先回到傳統的 TCP/IP 模型，從這裡開始。

按照我們目前的情況來看，bitcoin 的具體位置是在應用層和傳輸層之間。

這是因為，往下看，bitcoin 需要通過下面的傳輸層 TCP 來實現資料的傳遞。TCP 協議是非常穩定的協議。往上看，越來越多的應用程式，開始利用 bitcoin 來提供服務。 bitcoin 所在的位置，目前來說實際上是一個 承上啟下的結合部的位置。

從目前的角度來看，bitcoin 也的確是網際網路上的一個應用，這是目前真實情況的反映。確切的說，在應用層裡面，bitcoin 是屬於偏底層的一個基礎性的服務性質的應用。

但是如果僅僅把 bitcoin 和 metanet 看成是應用層的子集，從協議棧的角度來講，它意義就是非常有限的了。

這裡我們拿微信來打個比方，微信本來只是 App Store 裡一個非常單純的社交應用，但是因為它涉及面越來越廣，後來就有了微信小程式，微信小遊戲，慢慢的你會發現 App Store 可以被它蠶食，甚至是替代了。微信，從一個應用，慢慢地變成了一個作業系統，甚至以後有可能會變成一個終端。那麼 bitcoin 也有可能會經歷這樣的過程。

接下來5~10分鐘裡，我們會探討一下 bitcoin 是如何影響，並且延伸到不同的層次，更進一步，在將來，整個 metanet， 也就是元網，這個模型是怎麼樣演化的。

如果我們把 MetaNet 和 TCP 放到一塊，對比來看的話，我們認為，bitcoin 會開始逐步滲透，透過傳輸層和網路層，直接到達下面的物理層。總的來說，這是由 bitcoin 作為一個經濟系統，強大的經濟激勵模型來決定的。在TCP之外，bitcoin 不僅可以發展出獨特的替代性的方案，而且對物理層也會有相當程度的影響。

舉一個目前已經在發生的例子，10年前的中本聰，也只是推斷網路裡面會出現伺服器叢集，作為大型的專有設施來挖礦，但是後來很快就出現了專屬的礦機，礦池，礦場，這些是跟算力直接相關的 POW 硬體，是很典型的基礎設施。

那麼物理層這個基礎設施，作為現實網路的承載層，很大程度上可以被傳統網際網路和元網共享。

其實網際網路一開始就是這樣的，在90年代網際網路發展的初期，那個時候網際網路大量的複用了已有的電話網路。不知道大家還記不記得，我們那時候都是通過 modem 來撥號上網的。我記得那個時候上網，要是有電話撥進來，網路還會斷線，網路被佔用的時候，有時候還撥不進來。網際網路其實是藉助了當時已經普及的電話網路，走進了千家萬戶。我想如果 bitcoin 發展起來的話，元網實際上同樣也會共享和複用已有的基礎設施，這樣來最大程度地藉助已有的物理層來實現普及。

這裡我們順便說一下，這些物理裝置，在實際使用上可能會非常不一樣，這是元網的性質決定的。

4. MetaNet 模型 (對協議棧每一層的影響)

好，說完了整體上的大形狀，接下來我們從最下面的物理層來講起，向上挨個去分析每一層的具體情況。

首先是物理層。現實網路中，物理層是對原始資料幀的接收和傳送。這是一種很寬泛的封裝，實際處理的是節點跟節點之間資料交換的行為。

為什麼 bitcoin 會改變 TCP/IP 的物理基礎這一層呢？

我們已經知道，礦工之間是通過專門的強化的通道連線，經濟激勵會讓他們不斷改進連線，不斷改進相互溝通的效率，這樣才能儘可能更快地去處理區塊，獲得更多的獎勵，更有競爭力。

這種激勵反過來會改變物理層的模型。舉個例子，在挖礦的演變過程裡面，挖礦產生的能源消耗本來非常大，但是由於有激勵，有挖出的幣來驅動，在真實世界裡，會逐步轉變為對綠色能源的利用，因為這樣是最優解 (這些能源是所謂的 least-useful energy 效用最低的能源)。

具體的說，本地的網路就會用專門的硬體設施去做更大更快更大吞吐量的本地路由，然後通過共同的廣播機制去高效地廣播到其他子區域，那麼這也是 bitcoin 在未來改變整個TCP協議站的方式。

然後是網路層。當前網路層主要是基於 IP 協議的網際網路協議。這一層是網際網路的基礎協議，經過多年的完善，實際上是非常牢固、非常可靠的。如果我們把 IP 協議看成是網路上不同部分的一種定位，定址和路由的方式，那麼比特幣網路實際上提供了一種不同的方式。新的方式是建立在分層網路上，不同的層次會有不同的專門化的方案，通過 Miner ID 來互相識別和溝通，並建立相應的聲譽 (reputation) 。 Minor ID 是礦工的一個標識，當你發起了跟特定事務相關的請求，很有可能你只關心核心的礦工網路上，那些提供特定服務的成員，比如說如果你拉取視訊的話，是專門提供視訊流的資料服務商。那麼有的礦工（以及與他們關聯的服務商）在你關心的這個事情上有特別的積累的聲譽，它通常也能更好的處理你的請求，提供更有競爭力的服務。

這種聲譽，它獨特之處在於，它有持續的 POW 也就是工作量證明來作為背書，與傳統的可以刷，可以作弊的好評系統相比，這種聲譽的累積是更可靠的，很有可能改變我們聚合，訪問，反饋及評價的方式。

接下來是傳輸層。當前的傳輸層是 TCP/IP 來實現的，是主機之間可靠的端對端的傳輸。在這一層，我們可以把 tx 也就是交易，當成一種非常特別的訊息格式，這樣在傳輸層我們可以把我們關心的資料封裝到特定的訊息格式裡面去，通過網路節點去傳播，就像一筆典型的 tx 一樣。這樣的話，交易訊息就是對應用資料的封裝了，我們知道 bitcoin 的交易格式已經有10多年的歷史了，已經被證明是非常可靠，而且非常緊湊。尤其是底層的專門硬體不斷進化了之後，這種訊息格式也會跟著一起進化，這樣 tx 的處理也會變得更加高效。

好，在傳輸層之上，我們可以看到 bitcoin 自己有專門的一層。之前我們一直在說 bitcoin 對其他層會產生影響，然而 bitcoin 作為獨立的一層，它實際上對上面的應用層以及整個架構其實也是有著深遠的影響的。

左邊這些實際上是 bitcoin 能提供的功能，這些功能都是傳統的 TCP/IP 協議裡沒有的。給資料包蓋時間戳，是經由 POW 背書的時間戳，在時間戳的基礎上，會產生一個天然的排序。這個特點非常有價值，也是目前網際網路資料包所沒有的。因為 bitcoin 作為一個時序無關的系統存在，他其實並不關心這個事件是什麼時候發生，以什麼順序發生，只是非常忠實地，按照事件發生的順序把它們坍塌為一個狀態。

當然了，你可以手動地選擇這些交易什麼時候發生，通過你觸發的時機。不過從整個系統的角度來講，非常有價值的是，bitcoin 網路總是會按照單一的原始順序，把所有的事件給逐個坍塌。這個特性影響會非常深遠，作為對比，在傳統的網際網路協議站上，所有這些資料，他們發生的順序是不確定的，它們在網際網路上流動，被路由的順序，從回溯的角度講，也是不一定可靠的。

存在性證明，是往賬本上去新增事件的時候，自動就會生成一個跟它相關的 Merkle 證明，這個證明非常有價值，這也是為什麼 bitcoin 被概念化成獨立的一層的最本質的原因，就是因為有存在性證明。

不知道大家是不是還記得第一頁上的圖，當應用層的資料被傳輸的時候，下面每一層都給這些資料追加一些額外的資訊，而 bitcoin 這一層，追加的就是這些 Merkle Proof，也就是這些默克爾證明。那麼這些證明用來確認，這些資料，在那個時候，是存在並且有效的。上面說的這幾樣，時間戳，順序，存在性證明，他們之間是相互關聯的，都能歸結到這些默克爾證明上來。

這個不變性，最後一條，記錄的不變性 (immutability) ，是 bitcoin 可以提供的最核心的特性。

網際網路上的資料不變性非常重要，這種不變性，有能力確保，當一個事實發生了以後，資料歷史是不可修改的。為很多事情能夠提供線索，提供證據，是非常有價值的。

上面三個特效能匯出不變性，這就使得所有的資料，在應用層下面，都能經過 bitcoin 層，以使用者無感的方式，也就是使用者不需要知道它存在，自動就 “可追溯，不可變” 了。

那麼還有 (這一頁左邊最下面的) 資料層。bitcoin 本身其實是一個資料層，是一個非常通用的，可以處理各種不同型別資料的資料層，同樣這也是在 TCP/IP 裡面是沒有的。

好，那麼最上面的一層是應用層，這一層也是我們今天課程後半段的核心的內容。

應用層，它的特點是跟傳統網際網路是非常融合的，可以延用以前的方式去處理資料，展示資料。在應用層這一層的開發者，還是用他們之前熟悉的工具去處理和展示資料，使用者也用他們熟悉的方式去接收和互動，不需要理解什麼新的東西。那麼這一層其實可以是 bitcoin 無關的，也就不一定要跟比特幣有關，可以作為一個可選項，既可以由傳統的網際網路支撐，也可以由 bitcoin 層支撐。也就是說，bitcoin 提供的默克爾證明這些，都是附加的，不是必須的。

說完了每一層的情況，我想回顧一下整體的情況。我們可以看到，隨著發展，bitcoin 穿透了中間的傳輸層和網路層。這是不是說，有了新機制，老的就可以不要了？不是這樣的，他們是各自發揮各自的作用。

有人可能會問，不通過 TCP/IP 協議，那還怎麼通訊？

實際上這不是什麼新鮮事，比如說我們熟悉的 GPS 就不是 TCP/IP 協議的對吧？我們的 GPS 裝置上面有 GPS 晶片。再比如，我們撥一個電話號碼，打個電話給別人，這個也不是通過 TCP/IP 協議去找到對方的。

我們認為，在未來 bitcoin 會發揮更大的作用，bitcoin
網路上也會有更大的價值轉移。在這之後，會有專門化的網路逐步的出現。這個過程非常自然，就像礦機取代 CPU 挖礦那樣，現在你已經看不到 CPU 挖礦了對吧。到那個時候，metanet 就會成為真正意義上的元網，網際網路也會真成為真正意義上成為元網的子集。

5. 應用層概覽 (ALPs)

好，這個是目前應用層的400個專案的列表。

這個圖其實是有點老的，最底下這個黑的可能看不太清楚，這個是 Bitcoin SV 協議；再往上一層，有一點點灰的是 MetaNet 的協議；然後再往上它分成三個部分，一個是協議層，一個是工具層，一個是應用程式層。那麼每一層都對上面的一層提供支撐，應用是由工具來支撐的，工具是由協議來支撐的。

今天我們不去講具體的某一個應用，也不講某一個工具，主要是在講協議部分，以及這些協議對開發者寫應用有哪些特定的幫助。

應用層協議。那麼，什麼是應用層協議呢？應用層協議需要滿足下面的三個特徵，第一個是有效的利用 bitcoin 交易裡內嵌的資料，第二個是將 bitcoin 交易作為訊息格式來使用。第三個是能夠 (在必要的時候) 通知應用層。只要滿足這三個特性的東西，我們才稱之為應用層協議。這三個特性可以幫我們去標準化，怎麼來使用 bitcoin 來組織應用層的資料，並且在合適的時候，去通知更高層的業務邏輯。

應用層協議對 (頁面左邊) 下面三個角色有什麼影響呢？礦工和節點，他們通常是不關心這個協議的，他們更關注底層規則的執行情況。比如說，我們有大量的資料和行為，在 op_return 裡，礦工對這些資料大部分時候是直接忽略的。服務提供商會考慮現成的協議，或者在沒有合適的協議可用時，制定他們自己的協議，而使用者則從成熟的協議裡面獲益，他們會用腳投票，去決定哪個協議能活得更長一點。

舉個例子，微軟剛出 Win95 的時候，OpenGL 作為圖形學的標準已經發展很多年了，是非常成熟的協議。微軟自己弄了一個 DirectX，花了大量的成本，做了好多年，還是被各種吐槽。這種吐槽到了這樣的地步，就是使用者裝了一個遊戲以後，總是第一時間切到 OpenGL，有的遊戲只支援 OpenGL。但微軟比較厲害的就是，它不計成本不斷投入，一直反覆改進 DX，一直到 DX7 的時候，量變引起質變，然後 DX8 的時候，基本上就統治了圖形渲染這一塊，從那時候起，協議的戰爭就結束了。

那麼，從這個故事你也可以看到，協議的演化是有多方參與的，不同人關心的東西不一樣，到最後會有一個比較厲害的勝出。

6. 簡易支付驗證(SPV) & 可追蹤證據鏈

好，現在我們來看一看使用者資料提供商和礦工他們之間是什麼關係？那麼服務提供商相當於是像 Twetch 這樣的微博應用，他們一方面利用應用層協議去把資料從鏈上給過濾出來處理，並且把區塊裡那些非常緊湊的資料轉換成服務可以直接用的形式，這個過程實際上是一個資料展開的過程。另一方面，使用者發起請求的時候，就把準備好的資料用更方便更可讀的方式返回給使用者。

那麼對於使用者來說，他們隨時擁有去鏈上直接驗證資料有效性的能力。你看就是這樣，利用 SPV，就是簡易支付驗證，來鏈上直接檢視自己關心的資料的默克爾證明。

SPV 服務實際上對資料提供商和使用者都是有用的。

我們拿微信支付來做個比方，微信相當於是礦工，也就是基礎服務層。那麼你掃了披薩店的二維碼來付款的時候，披薩店處理之後，告訴你付款收到，並且在卡包裡給你增加了一些積分優惠券，這一類東西。這個時候，如果你不放心的話，你可以自行去微信錢包裡檢視餘額，去卡包裡檢視你的優惠券。 然而有一點不一樣的是，傳統網際網路應用裡面，上面說的這種消費記錄，積分的變化都是微信在打理，比如說他決定只允許你查6個月之內的，你就只能查6個月之內的。也就是說，核心的業務資料都在微信裡，使用者和商戶其實是很被動的。但是在 bitcoin 的協議棧裡面，所有的資料是天然可以有明確的所有權定義和訪問的授權的。這個是從本質上優於傳統的網際網路的。

我們知道傳統網際網路上資料來來去去，轉瞬即逝，如果商業公司不儲存，不提供，或者是因為時間久遠不可訪問，或者甚至它直接淘汰掉服務的話，這些資料實際上是無跡可循。那 bitcoin 作用就是為所有的這些關鍵的事件，提供一條可以追蹤的證據鏈。 我們叫它 a trail of evidence，可追蹤的證據鏈。

二、 應用層協議與實踐

好，現在我們進入今天的下半段就是應用層協議，它實際上分為資料協議、支付協議和 Token 協議。

我們一個一個來看，首先是資料協議。

這個資料協議，是關於怎麼去建立和組織區塊鏈上的資料的。

1. B協議 / B-CAT - 檔案及流媒體

好，最簡單的是 b-protocol，就是 B 協議。

B 協議是什麼意思？它支援把一個檔案上傳到區塊鏈上。

可以看到，下面是一個例子。我們把有紫色小花的這幅圖，上傳到區塊鏈的1個 op return 裡面。你可以看到它分成4個部分，data，media type，encoding，file name，分別是資料、型別、編碼和檔名。這實際上是跟傳統網際網路上的 B 協議非常像，這個是 unwriter 在早期實現的，這也是最快的把檔案放到區塊鏈上的方式。

實際的應用層，就是實際向使用者提供服務的網頁去取資料的時候，其實是可以做到 bitcoin 無感的，也就是說，你的資料，想在任何一個時間點上把它全部遷移到鏈上，都可以，是否在鏈上其實也不應該影響到實際的訪問。讀取出來後，其實對使用者來說是個熟悉的介面，他也不是那麼關心，你這個資料是不是真的在鏈上。隨著網路承載能力的提升，傳上去的檔案可以越來越大，一開始是KB級別，很快，就可以到 MB 級別。也就是說，我們實際生活當中用到的大多數檔案，理論上都是可以放到鏈上的。

好。在 B 協議的基礎上更進一步，我們有 B-CAT 協議。B-CAT 協議實際上是連續的多個塊。同一個檔案，如果太大，你不想把它放在一個 tx 裡，那麼你可以把它用連續的多個 tx 連線起來，本質上是同一個檔案的多段存放。不僅僅是因為“大”而拆分，也有可能是因為，這個檔案是連續的，有可能在你播放的時候，這個檔案還沒出來，比如說像一些視訊直播，每分每秒都有可能會產生新的tx，所以我們叫它cat，是一個流媒體的形式。下面的類比你可以看到 b-cat 可以用來做資料流，可以用來做直播這一類的流媒體。

(動畫示意) 這是一個例子。 多個 output 實際上是一個檔案的多個不同部分。那麼在最終有一個 concatenation tx，在這個裡面，我們把檔案的多個部分，就是可以看到圖中第一部分，第二部分一直到第n部分，使用他們所有的 txid 拼成了同一個檔案。

2. D協議 - 動態可變內容

好，跟剛才的 B 協議不一樣的是，D 協議實際上針對的是可變的內容。那麼對同一份內容，比如說右邊的狗狗，我們可以支援修改圖片，給它加一個皇冠。那麼會產生一個引用，總是指向最新的內容，這裡的 d 實際上是 dynamic 的意思，就像 DHTML 一樣。我們可以看到，原始的小狗圖片是一筆交易，然後我們修改了這個圖片以後，是另一個交易。那麼通過一個協議，對於原始資料和變化後的資料，我們可以保持一個單一的引用，利用它的先後順序，總是找到最新的引用。

在這個基礎上，我們還可以給 D 協議裡邊的內容，給他們新增kv值，產生KV值的關聯。你可以看到，在最下面的這筆交易裡面，通過一個key和value來指定把哪些資料附加到這個圖上去，比如說他可以設定一個新的 key 為 name，然後指定 value 為小明，只有圖片的主人才能來做關聯，那麼這個是資料所有權的天然體現。

3. BOB 協議 - 多協議組合

好的，BOB，這是一個更復雜的協議。BOB Schema，它實際上是一個多個協議的組合。

有的時候我們的應用程式需要更復雜的資料組織形式，並且希望在複雜的協議之間互動，就用的上這個了。

你可以看到這裡有一個 tape，它這個 tape 就是磁帶的概念。它是多個協議的線性排列，每個協議的資料塊都是裡面獨立的單元。你可以看到這裡有cell 0, cell 1, cell 2，它是分別是不同的協議，每個 cell 有一個獨立的操作，比如說第一個 cell 裡面存了 op_return，然後第二個 cell (也就是 cell 1)，裡面存了 B 協議，cell 2 存了 D 協議，cell 3 存了 B 協議，等等。那麼這是其中的一個輸出，另一個輸出裡面也是一樣，也可以存很多東西。

4. 關於 “實際資料是否應完整存於鏈上” 的討論

這裡面有一個非常關鍵的點，也是一直以來爭論非常大的情況，就是“實際的資料是不是要完整存在於鏈上”這個問題。那麼每個應用需要根據自己的情況去考慮，這裡的重點在於，這些資料全部都流經了 bitcoin 這一層。

考慮到實際情況的複雜性，真實世界裡面資料（按照重要性）可能會有很多層。

我們拿一局足球比賽來打個比方，一場比賽90分鐘打完以後，最關鍵的核心資料是，誰贏了，誰輸了，比分是多少，誰進了球。那麼這些資訊，我們完全上鍊是毫無問題的。更多的資料，比如說有多少觀眾，多少次射門，每個球員跑了多少米什麼的，這一類資訊是是完整的上鍊還是雜湊上鍊呢？就可以考慮一下了。

更進一步，這場球賽的每一分鐘裡，每一個球員的位置，他們的運動，這一類實時的細節，如果你不是專業的針對運動員的資料分析服務，絕大部分情況下是不需要上鍊的。

但是，不管這些資料最終是否上鍊，他們全部都能夠在他們發生的時候，流經協議棧的 bitcoin 層，是可以獲得默克爾證明和時間戳、存在性證明等這些好處的。這是 bitcoin 這一層非常有價值的服務。

5. 元網 (MetaNet) 協議

好，接下來我們看到的是元網協議。

那麼元網協議作為一個資料協議，其實它是一個相對比較複雜的東西。這裡限於篇幅，我們只是簡單的介紹一下，如果深入的話，這一個協議可能就把剩下的時間全部都給佔去了。

元網協議最重要的關鍵點是，它是用來 建立資料之間的聯絡 的。而且通過建立聯絡，它形成了一個層次化的結構，他用 “邊” (Edge) 這個概念來把邏輯相關的 tx 給關聯起來。要是沒有這種關聯呢，tx之間只有先後的關係，也就是基於時間戳的排序。有了這個樹狀結構，最大的好處就是任何一個資料都可以去層次裡面去追溯和定位。這種定位對複雜的資料組織來說是非常必要的。

舉個例子，比較大型的 3D 遊戲裡面，有數以萬計的物體，它們都組織在一個巨大的場景樹上面，這個場景數可以提供各種需求和服務，比如說你哪個物體看不到，需要被裁減了，哪個物體碰撞了，需要被反彈了，這些都依賴樹狀結構去提供快速的篩選，檢索和定位的服務。

好，我們看到這個元網裡面，最重要的一個概念就是“邊”。

“邊” (Edge) 的定義是什麼？它是節點跟節點之間，邏輯上的關聯性。在子節點裡面有父節點的簽名，這一點是非常重要的。你可以看到下面的放大的框裡面，子節點的輸入裡面父節點的簽名。這樣的話就能夠避免假的子節點，也就是別人偽造一個子節點，因為如果沒有父節點的私鑰的話，它是沒法簽名的。在子節點的輸出裡面，是有父節點的 txid 的，這樣的話就構成了一條邊，你通過子節點你可以隨時往上追溯。

6. MetaNet 應用 - 許可權管理 & 版本歷史

好，我們來看看 MetaNet 的資料協議能做些什麼事。

首先是它可以幫我們管理許可權。你可以看到只有根節點就是p0的節點，它能夠去建立p1和p2，而在第二層到第三層裡面，只有p1才能建立 p1.1和p1.2。那麼同理也是 p2 才能建立 p2.1 和 p2.2。

那麼這實際上是比 TCP 要更好的。

這是因為，第一點是 bitcoin 天然會幫你去驗證這些所有的這些交易，也就是這些訊息它的簽名來確保這些資料的有效性，可以節省大量的驗證的工作量。
那麼比特幣的基礎設施，使得你不用自己去驗證哪些資料是有效的，哪些是偽造的。那麼 (第二點)， 在這些資料依賴的關係之外，除了資料本身，還有這些交易，就是 utxo 所定義的支付關係，也就是說誰給誰付了多少錢，這些支付關係也是非常重要的資料，在你需要的時候就可以直接用。

打個比方，比如說我們一個遊戲內的道具，在遊戲裡被別人撿了，實際上你是不需要在資料中去管理這種所有權的轉移。因為通過 utxo 管理， 通過支付關係，它已經轉移給另外一個人了，你不需要在資料裡去再去額外定義一遍，它已經轉移了。

除了許可權之外，MetaNet 還可以有很多其他的應用，比如版本管理。

比如說在這裡同一個 key，建立了多個交易，多個交易源於同一個 key，但是有不同的 data 在這個時候就很自然的能夠形成，關於這個資料的版本歷史，那麼你再通過時間戳很容易就找到最新的版本了。你看就像這樣 (動畫演示)，很容易你就知道 (對於同一個 key 來說) 後面的一定是新的版本。那麼即使在同一個區塊裡面也是一樣可以保證的。

7. MOM - 元網物件模型

好，在元網的協議的基礎上，我們有一個物件的模型，這個物件模型其實是一種基於元網協議的組合。

你可以看到右邊，三種不同的顏色，比如說綠色，綠色是 B-CAT，實際上是一個父節點，然後下面追加了 n 個子節點，那麼通過這種方式，我們可以把元網跟其他的協議相組合，可以形成非常靈活的配置，這也是一種非常有效的方式，去對不同的協議去組合分層 (來應對真實世界裡繁雜的業務需求)。

這些組合既可以是線性的，也可以是遞迴的，也可以是層次化的。在上面我是通過資料流的方式，然後到了下面每一個我又可以做成可變的，這是非常靈活的。

這是 MOM 的一個實際的例子。對於同一組相關聯的資料，在不同的情況下，你可以用不同的協議去解決不同的問題，這樣你實現功能的時候可以非常靈活。同樣，利用前面說到的版本(管理功能)，你可以很容易的去迭代你的協議。

8. MAP / AIP 等

好，還有一些比較小的協議，比如說 map 就是 map，它實際上是 magic attribute protocol。

看起來好像很複雜，但實際上它很簡單，它就是給現在已有的一個資料附加更多的 kv 值，那麼也就是更多的屬性。你上傳了一個檔案，你可以去寫這個檔案是作者是誰，是什麼時候建立的，然後它的標籤有哪些，你可以設定很多的kv值給他。實際上是給一個資料賦予更多的屬性。

那麼另一個是叫 AIP 協議，AIP 協議是關於作者對有版權的作品來署名的。你可以通過這個協議，來簽署一個專門的簽名資訊上去。

也可以用它來做第三方的簽署。比如說你有一筆交易，你需要另外一個公證人來籤一下，他不會出現在 input 裡邊，但是你需要他的簽名，這個時候你就可以用這個協議。或者說有很多人聯名簽署一筆交易，在不關心 utxo 的情況下，也可以做到很多人來簽名同一個檔案，比如說什麼請願書一類的，上面可以收集幾萬個簽名。

9. 協議的共性

好，前面說了一大堆協議，現在我們來歸納一下這些協議有什麼共同的特點，也就是協議的共性。

歸納起來，有這樣兩個特點，第一個特點是：有一個公共的字首，每一個協議有各自的字首，你可以用字首去區分不同的協議。第二條是用 PUSH_DATA 來分割資料。這兩點其實是非常淺顯也非常直白的，你基本上你用過這些協議的一看就懂。

三、 支付協議 & Token 協議

支付協議 - BIP270

好，說完資料協議了之後，我們現在來講，支付這一塊的協議。

首先我們先來看一看最近討論的比較多的 BIP270 協議，這個協議的目的，是用來處理和簡化商家和客戶之間的支付的。

之前我們最經常見到的 (處理方式) 是什麼樣的呢？

是客戶簽名了一筆交易，然後把它廣播給網路，然後商戶你自己去找，找到了你就認為這個人簽了一個有效的交易。

那麼 BIP270 有什麼不一樣呢？

是商戶提供一個模板給客戶簽字，客戶簽了之後由商戶去提交給網路。

那麼這樣做，其實是跟我們比較熟悉的傳統的支付系統是很像的，交易最終是不是完成，商戶自己會對它負責。實際上是簡化了整個流程，商戶需要自己去廣播，需要自己去結跟結算系統同步，從使用者的角度來講是省了很多事情的。

BIP270 內融入了 SPV 的流程，對交易驗證只要很少的運算資源就能完成。 不管是使用者也好，商戶也好，就可以通過 SPV 去驗證，這樣保證了就是大部分的支付場景下面，你想去驗證交易，不需要花費什麼運算資源，也不需要執行全節點。

支付協議 - 掃碼

好，那麼第二種支付協議是掃碼。

掃碼支付，我們其實用微信和支付寶已經很熟悉了。它是使用者提供一個二維碼，商家掃描這個二維碼了之後，向使用者錢包的伺服器發出一個支付請求，然後錢包的伺服器來讓錢包的客戶端去簽名。簽完名之後，跟前面的270是一樣的，仍然是由商戶去廣播這筆交易。那麼由商戶去廣播，對商戶的安全性是有更好的保障。比如說你金額越大，商戶可以等越長的時間，來保證有效的交易儘早的去到多個節點上。不一樣的是，在掃碼這種方式裡面，使用者錢包只顯示一個二維碼，系統裡多了一個錢包伺服器去參與，這個參與者需要去告訴錢包，什麼時候對哪筆交易簽了名。

這裡我們專門講一下，我們前面說的 BIP270 和現在說的掃碼支付，為什麼說他們是可以擴充套件的支付模型 (scalable payment model)。

有這麼幾條原因，一個是，原來的方式裡，使用者去廣播，商戶自己去對應的地址上面查，實際上是很低效的，有很多支付的時候，你會對同一個地址查多次，如果不同的客戶付到不同的地址，你要到不同地址上去監聽，是很低效的。 第二個原因是，(在 BIP270 下) 使用者是可離線的，在特殊的情況下，比如說有時候電梯裡沒訊號，這時候不需要聯網就能產生交易。再比如說有很多裝置他們可能不被允許聯網，比如說攝像頭，它也可以產生有效的交易。 第三條原因是，商戶也可以依賴 SPV 不需要執行全節點。那麼這對商戶來說就省了很多事情。

所以有這麼幾條，那麼這種模型不管對商戶也好，對使用者也好，都是可擴充套件的。

支付協議 - Paymail

好，第三種支付協議是 Paymail。

Paymail 是一種非常有價值的服務，本質上是利用電子郵件來做一個別名。它比 1 開頭的 bitcoin 經典地址好記很多。就好像你用一個域名一樣，如果沒有域名的話，大家都通過 IP 去訪問網際網路，是非常不友好的，而且不太可能記住。

從實現的角度，我們簡單說一下細節。使用者是依賴 Paymail 的服務來做這個地址的決議，就好像我們通過域名的服務 (就是DNS服務) 去確定物件的IP。我們有理由推測，提供這個服務(從別名到具體地址，或者到公鑰的這種查詢，解析和決議這種服務)，它本身也會變成非常有價值的服務。
有了一個明確的協議了以後，任何人都可以進來競爭，促進網路不斷的去進化。

Token 協議

在資料協議和支付協議之後，我們再講一下簡單的講一下 token 的協議。

Tokenized 我簡單提一下，它也是傳統的 request/response 模型，對開發者來說是很熟悉的。

它通過預言機來引入外部的資料，它裡面也內建了一些他自己的合約，有很多合約，比如說什麼電影票什麼的，可以拿起來改一改就能用。 Tokenized 的特點是針對監管是非常友好的，他有很多方式來幫助監管來判斷，這裡時間關係我們就不展開說了。

另外一個 token 協議是 Run (RunOnBitcoin)。

跟 Tokenized 不太一樣，Run 更加專注於現實世界的物品或者虛擬物品，它的數字化和通證化的，一個相對快捷的方案。他這個協議本身要比 Tokenized 更簡潔一些，更好擴充套件一些，他很容易支援自定義的物品，也是支援智慧合約和 Token 了。

四、 應用層工具包 (Toolkits)

好，講完了協議這一塊，我們來簡單的瞭解一下，應用層是怎麼通過工具包來支援的。因為對於應用層開發來說，光有協議是不夠的。

我先問個問題，就是，應用層，具體指的是什麼？

有 ALPs，也就是應用層協議，和開發者工具，商家服務，還有應用 (這些選項)。

那麼應用層具體指的是什麼呢？

這裡的基礎設施是指應用層的基礎設施，那麼協議跟基礎設施有什麼區別？協議其實只是協議而已，基礎設施才能夠讓開發者可用。只有一個單純的協議的話，開發者是沒法上手去直接做自己的事情的，就像我們開發遊戲是不可能拎著 OpenGL 和 DirectX 就直接上了，我們可能還需要什麼 Unreal，Unity這樣的引擎或開發包。

那麼工具包裡面，既包含了協議，也包含了基礎設施，說白了就是一些程式碼，我們可以直接拿來就能開發。那麼我們也能看到，這裡應用層它實際上包含了協議和工具包兩部分。

好，在最後，我們羅列並對比下，所有的應用層協議，和他們對應的這個工具和基礎設施。

你可以看到有三種顏色，藍色的部分是資料協議，深藍色的是支付協議，黑色的是 Token 協議，那麼右邊是它們對應的工具，一般都是一些軟體的 SDK。

在我們做實際開發的時候，我們不一定會完全的符合已有的協議，你可以部分的符合，然後可以擴充套件，甚至你可以演化出你自己的協議。

比如說我們小聰遊戲，打算實現遊戲裡的道具，那一開始用 Tokenized 了，後來發現遊戲裡的道具資產，有各種奇奇怪怪的屬性，而且執行的時候還會不斷變化。這個時候對這些很特定的業務需求，Tokenized 就不是很靈活了，所以後來我們定製了自己的協議，一開始我們叫它 GAP，也就是 game asset protocol，遊戲資產協議，後來我們改了一下名字叫 GAS。

實際上如果你的應用產生了真實的價值，你大概率會定製出你自己業務相關的方案。甚至可以這麼說，你的業務越深入，你就會越來越尋求專門化的方案，畢竟這是業務上的積累，是非常有價值的。

課後問答

好了，以上就是今天這節講座的全部內容，感謝大家的參與。接下來我會對講座的過程當中收集到的一些問題來解答一下。

第一個問題，有朋友問能不能開發一款戰棋遊戲，我要說，這是好主意，歡迎來跟我們一起參與，來設計。

第二個問題，有朋友問，“不上鍊，但是流經 bitcoin，所以可以對這個資料來進行默克爾證明”，這個怎麼理解？

實際上是這個資料的雜湊是可以存在 op_return 裡的，然後 op_return 是隨著交易一起上鍊的。所以這要看具體怎麼用了，可以多層次的去用，可以去把所有的資料坍塌成一個雜湊，也可以坍塌成一個資料流，這就取決於具體對資料的重要性的分析了。

第三個問題，還有同學問，在 MetaNet 裡面是怎麼證明自己拿到的版本是最新的？這個問題是因為所有的所有的 tx 是有一個時間戳排序的，即使是在同一個區塊裡面，實際上是它交易順序也是完全確定的，我們完全可以依賴 bitcoin 系統本身的順序，來拿到最新的版本。

問題：開發應用時怎麼判斷，什麼情況下用哪一個協議？

好，然後第4個問題，就是，這些協議比較零散，在開發一個 APP 的時候怎麼做判斷，什麼情況下用哪一個？

這個問題，最核心的點，其實這是一個很大的問題，但最核心的點是，你要問自己一個問題：我的資料需不需要跟別的應用共享？如果不需要的話，你完全可以用你自己定製的方案，如果需要的話，你就儘量用已有的協議，這樣能顯著的降低你跟別人溝通的成本。

在這個基礎上，我還想提一下，“對協議怎麼去選擇”，其實是反映出來的是，你怎麼看待你自己程式裡的關鍵業務資料，你怎麼判斷，怎麼分析這些資料。這個話是怎麼說呢，因為我們做開發的，就是有一個詞之前比較流行，叫資料驅動開發，也就是 data-driven development。我們發現，凡是這種由資料驅動的程式，就是你一開始就想好你的資料是怎麼來到哪去，這種資料驅動的程式，它整體的複雜度，會比那些就是強調業務邏輯的那種程式，複雜度要低很多，你的程式的流程會清晰很多，可讀性也會好很多，出 bug 機率也會低很多。

那麼再回來看這個問題，就是你選協議的時候，最好的做法是，先思考你的業務，先思考你的業務的核心資料，然後圍繞你的核心資料去做設計，做架構，然後對你自己的核心資料的特點，你明確的理解它了，你知道了明確的資料從哪來往哪去了以後，你再去選對應的協議，那就很顯然了。

問題：這些協議是穩固不變的，還是會隨著時間的推移，隨 bitcoin 體系的演化而變化？

然後是第5個問題——你認為這些協議是穩固的不變的，還是會隨著時間的推移，整個 bitcoin 體系的演化而變化的？

這個問題是這樣的，bitcoin 底層的協議，我們知道它是 set-in-stone，就是我們在下次更新之後不會再變了。但是這是不是說，應用層的協議也都不變了？其實不是這樣的，我覺得如果站在 5~10 年的尺度上去看的話，整個系統，從應用層的角度來講，一定是一個不斷髮展不斷演化的過程。

要是比特幣的分層網路 (BLN)，它能夠向我們期望的方向發展的話，我覺得，可以預見，這個行業應該是會從粗放式的，慢慢的轉向精細化、專業化，對特定的業務會很重視，那個時候就不是看什麼TPS，看峰值的這個時候的業務量。那時候會去關心什麼呢？比如說，平均響應延時，終端的使用者體驗，這一類的問題。就是相當於在特定環境下，解決特定環境的癢點，痛點，這種能力指標了。

到那個時候，我覺得那個時候可能會有更多的專有的定製的協議，甚至是有的私有協議，可能還會產生比較重大的影響。

問題：目前有沒有一個比較全面的支援所有協議的生成 tx？

還有一個問題是，目前有沒有一個比較全面的，支援所有協議的生成tx？ 這個問題比較深，現在目前還沒有。但是可以劇透一下，我自己寫了一個小工具，這個小工具可以給我自己作為一個參考，生成各種不同協議的 tx，我其實是打算把它梳理成一個比較大的條目，在你寫 bitcoin 程式的時候，可以直接三五行程式碼拷過去就能用。這個可能不能作為一個嚴謹的工具，但是可以作為一個個人的小教程或者是示範程式碼，之後我可能會把它放到 GitHub 上去。

問題：bitcoin 是一個基於經濟激勵的系統，這個激勵在開發者層面上如何體現出來呢？

這個問題很有意思，總的來說我認為這是一個機會。

有的同學可能會覺得像 Linux 那樣的開放社群，通過開源作為紐帶來激勵。不是很好嗎？看起來也行之有效地執行快30年了。然而你可能不一定知道的是，社群裡面，中老年開發者的比例每一年都在上升，在他的核心開發者圈子裡更是如此。也就是說，年輕的新鮮血液，越來越不傾向於參與這種開源協作了。

當年大多數開發者在為微軟的Windows作業系統開發應用程式的時候，蘋果公司用 “app store 三七分成” 的簡單口號，開發者們用腳投票，光速構建起來了一個龐大的開發者社群。可見正確的激勵模型是非常重要的。

我相信在不遠的將來，在資料和價值上，一定能找到一個被廣泛應用的商業模式，而這種商業模式是可以被標準化和協議化，並沉澱到應用層協議裡的。這樣一來，那些參與進來的開發者和廠商才能從中獲益，廣大人民群眾才能真正有得花，有得賺。

遊戲的行業有句老話叫做：一流的廠商定標準，二流的廠商做引擎，三流的廠商做遊戲，我希望早日能在BSV生態裡看到這一場景的出現。

---

好，就這些問題的話，各位同學那本次線上研討會到這裡就正式結束了，Bitcoin SV 線上研討會，系列講座將會在每週二及週四晚上8:00~9:00進行，為期一個月。螢幕上方的二維碼是我們系列研討會的報名連結，歡迎大家將課程推薦給身邊的開發者，也希望你們持續關注 CSDN 上的 Bitcoin SV 開發者專區，連結是 bsv.csdn.net，謝謝，我們下期再見。

引用和尾註

視訊地址

1. Bitcoin SV 線上研討會 (全8節) 視訊地址彙總
2. “Bitcoin SV 應用層協議” 講解視訊

Jack 對 BIP270 的擴充套件性的釋疑

本文中關於 BIP270 的擴充套件性的釋疑，來自於我向 Jack Davies 請教時，他詳細回覆的郵件。

關於這一點，我的問題如下：

Questions:

1. (about BIP270) what does it mean by "Payments as we know them" in PPT? (in page 38)
2. (about BIP270) Why & how the method "allows the merchant to scale their own security" (mentioned in the audio without explaining)?
3. (about both BIP270 and Show&Pay) Why & how the method "allows scalable payment model" (mentioned in PPT without further explaining)

I read through BIP270 proposal and I believe I understand the difference between the proposed
method and the original naive method.

for the security, are you referring to the broadcasƟng is done by merchant, so that it eliminates the
possibilty of client double-spending?

Jack 的回覆中，涉及這幾個問題的原文，摘錄如下：

Question 1:

When I say "payments as we know them" I am trying to explain that BIP270 deliberately
mimics/takes inspiration from the way we do payments in the real world, with or without
Bitcoin. In other words, it mirrors the asymmetry between customer and mechant – the
merchant has the responsibility of broadcasting a Bitcoin transaction, in the same sense that a
merchant using an existing physical payment terminal provides a connection to the
Visa/Mastercard etc. clearance and settlement system.

Question 2:

When I mention a merchant being able to "scale their own security", this is referring to the
fact that a merchant can make their own decisions e.g. how long to wait after broadcasting a
transaction to be confident that the Bitcoin transaction will make it onto the blockchain. As an
example (numbers made up, for illustration) if it takes 0.1s for a transaction to propagate to
50% of network hash rate, and 1minute to propagate to 99%, then somebody selling a cup of
coffee might be happy to give the coffee as soon as they have broadcast the transaction, but
somebody selling a car may ask the customer to wait for one minute. Note that in the case of
the car, the 99% propagation minimises possibility of the payment failing, but much faster
than in the existing world. So BIP270/SPV mimics existing payments model, but far more
efficiently, and quickly.

Question 3:

When we refer to the "scalable payment model" we are talking about a couple of things. First,
the fact that we are handing a full transaction to the merchant – this means that the
merchant can query the Bitcoin network to ask if the transaction has been 'accepted', or
request a proof that is in a block. This query is much more efficient/quicker than if the tx was
broadcast by the customer, and the merchant has to 'scan an address' for incoming payments
– this makes BIP270/SPV much more scalable in this sense. Secondly, this method allows for
the customer to be offline, which means payments can 'scale' to many different methods of
use e.g. smart cards/physical devices. Thirdly, this method does not require the merchant to
run a full node – it only requires that they have a copy of block headers and have a
connection (for tx broadcasting and querying) to the Bitcoin network of miners.

Hopefully the above should also address your question about why the method is more secure
(or resilient to situational double-spending), and yes this is in large part because the
merchant broadcasts the transaction, and that we apply Bitcoin's probabilistic security model
regarding how much of the Bitcoin (mining) network the transaction has propagated to.

Jack 的回覆全面，系統，深入，一氣讀下來豁然開朗，令人擊節。

彩蛋

能翻到這裡的同學，可能是真愛了。附送彩蛋兩個吧。

第一個是應用層協議全貌縮圖：

第二個是應用層協議棧的簡易說明：

這兩張圖對應了今天研討會的兩大塊內容，可以作為一個快速的 CheatSheet 以供參考。

[完]

---

• 顧露 (Gu Lu) 於免成居
• 時間: 2020-10-04
• 編號: Bt-006-2010
• 本文遵循 Creative Commons BY-NC-ND 4.0 許可協議。
• 永久連結 https://gulu-dev.com/post/2020/2020-10-04-webinar-app-layer-protocol