摘要（較長）：RGB 協議是比較有潛力的 BTC 拓展協議，本質是一種鏈下計算系統，它採用了和閃電網路類似的思想：用戶親自驗證並授權和自身相關的資產變動事宜（Verify by yourself），把交易發起者認可的結果/承諾提交到比特幣鏈上。

RGB 協議利用了與染色幣及 Mastercoin 部分類似的思想，在比特幣 UTXO 上關聯着「寄生資產」。它把鏈下交易數據的 Commitment「承諾」，存放到比特幣鏈上，而不是像 Ordinals 協議那樣發布完整的 DA 數據。根據比特幣鏈上記錄的承諾值，RGB 客戶端可以驗證，其他客戶端提供的 RGB 歷史數據是否有效。

同時，單憑 hash/Commitment 無法還原背後的原像，外界不能直接觀測到鏈上承諾值對應的鏈下數據，這樣可以保護隱私，且相比於銘文，只把承諾上鏈能節省空間。從第三者的視角看，他其實不知道 RGB 客戶端到底幹了什麼。

RGB 還利用了比特幣 UTXO 一次性花費的特性，通過名為「一次性密封」的思路，把 RGB 資產所有權，和比特幣 UTXO 關聯起來。這樣可以藉助比特幣強大的安全性，避免 RGB 資產被「雙花/雙重支付」（只要比特幣 UTXO 不被雙花，RGB 資產就不會被雙花）。

但 RGB 作為一個在比特幣鏈下實現的智能合約系統，依賴於不同的客戶端在本地存放歷史數據，且不同客戶端（用戶）只存放與自己相關的數據，看不到別人的資產狀況。這種「數據孤島」雖然保護了隱私，但也使得 RGB 在大規模採用上面臨麻煩，更像一個由 OTC 交易者組成的 P2P 網路。

RGB++的思路是，用 CKB 鏈上的 Cell，表達 RGB 資產的所有權關係。它把原本存放在 RGB 客戶端本地的資產數據，挪到 CKB 鏈上用 Cell 的形式表達出來，與比特幣 UTXO 之間建立映射關係，讓 CKB 充當 RGB 資產的公開數據庫與鏈下預結算層，替代 RGB 客戶端，實現更可靠的數據託管與 RGB 合約交互。對於其他基於 UTXO 的 Layer2 而言，這種」同構綁定」是一種趨勢。

RGB 協議本身只支持交互式的轉賬流程，交易雙方要頻繁通信，這種模式難以支持 Defi 場景，也不利於 RGB 資產發行。CKB 替代了獨立客戶端之後，可以實現非交互的 RGB 交易，利於 Defi 落地和空投等功能，且支持 BTC 資產無需跨鏈的與 CKB 鏈上資產交互。

RGB++本質是用隱私換易用性，同時帶來 RGB 協議無法實現的場景。如果用戶看重產品的簡單好用和功能完備性，就會青睞 RGB++，如果追求隱私和 Verify by yourself 的安全，就會青睞傳統的 RGB 協議，一切看用戶自己的取捨。（理論上 RGB++也可以通過 ZK 等方法解決隱私問題）

RGB 協議的原理及其優缺點

RGB 協議本身是一種比較複雜的方案，我們以一筆具體的 RGB 資產轉賬為例，為大家解釋 RGB 協議是如何工作的。

假設有一種符合 RGB 協議要求的代幣，叫 TEST。Alice 希望 Bob 將 100 個 TEST 代幣轉給自己，換句話說，希望生成一筆 Bob—>Alice 的代幣轉賬。

這裡先解釋下，RGB 協議採用了稱為「一次性封裝」的思路，表面上說是 Bob 給 Alice 轉賬，實際是指，Bob 控制着比特幣鏈上的 UTXO A，而 UTXO A 通過某些方法，關聯了一些 RGB 資產。

如果 Bob 聲明，要把 UTXO A 關聯的部分 RGB 資產轉讓給 Alice，它可以如此聲明：把 UTXO A 關聯的 30 枚 TEST 代幣，轉讓給 UTXO B 來關聯。由於 Alice 是 UTXO B 的所有者，所以她就擁有了關聯的 30 枚 TEST 代幣。

實際上比特幣鏈上的所有權記錄方式，都是通過 UTXO 來實現的，聲明 UTXO B 有資格控制 xx 數額 RGB 資產，就等價於說 UTXO B 的主人可以控制 xx 數額 RGB 資產，這與我們所習慣的帳戶地址模型並不一致，是比特幣等 UTXO 公鏈的獨特屬性。

理解了這裡後，我們再考察 RGB 協議的工作流程，可以感受到他與染色幣及 Mastercoin 等比特幣 UTXO 寄生資產的差異：

1. 按照 RGB 協議的原理，Alice 要先為轉賬交易開具發票 (issues an invoice)，指明自己的意圖。

發票中包含以下資訊:

合約 id：Alice 聲明要與哪個 RGB 資產合約交互

接口：讓 Bob 了解合約的所有交互接口

操作：Alice 讓 Bob 去調用的合約接口名

狀態：Bob 需要修改的合約狀態，此例中就是 Bob 轉給 Alice 的代幣數量

Seal（密封條）：用於一次性密封的 UTXO，可以簡單理解為，Alice 用來接受 Bob 的 RGB 資產授權的 UTXO。

最後，Alice 會獲得一個如下的發票內容:

上述發票遵循如下格式：

2.Alice 需要將上述發票發送給 Bob。Bob 會檢查發票資訊，按照 Alice 的意圖來生成新的 RGB 交易，把 RGB 資產轉讓給 Alice。

但這裡要格外注意，Bob 必須設法證明，自己的確有部分 TEST 資產所有權。至於為何要這麼做，是因為 RGB 協議默認「沒有全局可見的資產狀態記錄」，不會像以太坊那樣用一個公共託管合約來記錄並處理所有人的資產。

RGB 協議下，不同的客戶端只記錄和自身相關的資產數據，包括這些資產的當前餘額、歷史來源等，每個客戶端記錄的數據基本都不一致。這樣一來，每個人都無法確認其他人的資產狀況，所以在 P2P 交易時要出示資產證明。

用一句生動的比喻就是，你和對面在用紙鈔進行交易，但你不知道對方的紙鈔是不是自己印的假幣，你便要求他說清楚，這些紙鈔是從哪裡弄來的，經過多少人轉手，以此來判斷對方是否在用假幣糊弄你。

雙方互相認可後，就可以放心大膽的交易，每一筆 RGB 交易也只需要參與方彼此認可就行，是完全 P2P 的（類似於 OTC）。

顯然，這種模式可以保護隱私，因為每個人的資產狀況、交易記錄，都不會被外界輕易獲知，你和交易對手方做了什麼，外人很難知道。道理就好比，紙幣可以比銀行轉賬更好匿蹤。但顯然，這也會在用戶體驗上造成不便。

在前面談到的 Alice 和 Bob 案例中，Bob 收到 Alice 的發票並獲知其意圖後，要從本地客戶端的歷史數據中，選出和 TEST 資產相關的歷史轉賬記錄，連同新生成的 Bob -> Alice 轉賬，一起交給 Alice 去校驗，證明新的 RGB 交易/所有權變更，背後對應的資產所有權來源是有效無誤的。

一般而言，客戶端本地存放的數據稱為 Stash「藏品」，包含了 RGB 資產的過往數據。我們可以把 Stash 當做 RGB 資產合約的日誌記錄。

3. 當 Alice 從 Bob 那裡收到數據，以及新聲明的 Bob—>Alice 交易後，會驗證其有效性，如果驗證通過，Alice 便會生成一個「確認簽名」，返回給 Bob。

4.Bob 收到 Alice 的確認簽名後，便把 Bob—> Alice 交易對應的 Commitment（承諾）廣播到 BTC 網路內，最終寫入 BTC 鏈上，使其具備「最終性」。

如果 Bob—>Alice 轉賬中，聲明 UTXO B 的主人將擁有 30 枚 TEST 代幣，則 Alice 只要證明自己是 UTXO B 的主人，就可以使用這些 TEST 代幣。

5. 如果未來 Alice 要把 TEST 代幣轉給別人，當出示這些 TEST 的歷史來源時，對方可以根據比特幣鏈上的 commitment 承諾值進行核驗，看 Alice 提供的數據能否和鏈上的承諾值對應。這樣可以防止偽造數據。

RGB 協議的好處在於，可以在鏈下支持複雜的智能合約計算。它本質上把計算步驟挪到了 BTC 鏈下，僅在鏈上記錄 Commitment，在保護隱私的同時，在鏈下聲明比特幣 UTXO 和 RGB 資產所有權之間的關聯，藉助比特幣來刻錄並實現 RGB 資產的所有權變更。

由於所有的交易聲明都需要由當事人驗證並授權，所以其安全模型基於「理性人假設」，只要當事人是理智的，只要比特幣是安全的，RGB 資產所有權就「基本安全」。

但 RGB 協議的缺陷也很明顯（前文有提及數據孤島與碎片化儲存問題）。首先，要給其他人轉賬，甚至要先得到對方的同意和確認，雙方基本要同時在線；

其次，因為缺乏全局可見的數據記錄方式，RGB 的合約發布甚至都採用了非常奇葩的形式，合約使用者要事先從合約發布者處，獲知合約包含的接口功能，具體的獲知方式可以是通過電子郵件或是掃二維碼。（看官方目前的說辭，估計把合約代碼掛官網首頁、推特置頂也可以）

我們再來探討一下 RGB 協議的合約狀態。在 RGB 協議內，合約的初始狀態 (Genesis) 由創建者在合約創建時就設置好，比如 RBG-20 合約中的代幣名稱、總量等。而後，合約的狀態伴隨著 RGB 交易的持續遞進而變化，但這種合約狀態演進是非線性的，構成了一個有向無環圖 DAG。

比如 Bob 給 Alice 轉賬時，僅出示從合約初始化，到 Bob 獲得代幣的部分轉賬記錄，包含的數據路徑比較狹隘。而 Alice 也僅能獲知此路徑分支包含的交易資訊，難以獲知其他人的轉賬資訊。這雖然保護了 RGB 用戶的隱私，但也帶來了不良後果：用戶很難獲知 RGB 合約的全局狀態，比如每個人有多少 RGB 資產。這會帶來很多麻煩。

比如，當 Bob—> Alice 轉賬進行到最後步驟，其承諾值被寫入 BTC 鏈上且不可逆轉後，Bob 可以在本地刪掉部分數據——假如 Bob 將自己全部的 TEST 代幣都給了別人，可以直接把本地存放的 TEST 代幣相關數據刪掉，以減輕儲存壓力。

而作為代幣接收方的 Alice，則要在本地記錄此次交易所涉及的全部數據。（假如 Bob 刪掉了本地的 TEST 代幣數據，Alice 的客戶端節點又因為事故徹底損壞了，那麼此時，Alice 的資產是不是就永久凍結了？因為沒有其他地方存放 Alice 的 TEST 資產數據，除非事先就備份好。）

這本質上可以歸結為 DA 和數據儲存問題，即 RGB 協議的新增數據無法以一種可靠、全局可見的方式傳播出去，最終會使得不同的客戶端成為「數據孤島」。此前曾在以太坊生態如日中天，但後來遭到廢棄的 Plasma 方案，也是因為無法解決 DA 問題，最終胎死腹中。

此外，RGB 協議還需要交易雙方進行大量通信，很多通信步驟都要依賴中心化設施，在這塊的細節描述還不成熟，官方甚至說可以通過郵件來通信。

比較顯然的是，RGB 協議的設計對於追求易用性的長尾用戶不太友好，雖然擁有較多資產且對隱私有較高追求的大戶會樂於做數據備份和客戶端維護，但對於長尾用戶而言，這些包袱還是太重了，會對大規模採用造成嚴重阻礙。甚至於到目前，人們大多認為沒有出現什麼現象級的 RGB 資產。

下圖中，我們給出了 RGB 資產轉賬的流程圖，讀者可以基於此圖更加深刻理解轉賬的整體流程。

簡而言之，RGB 協議藉助比特幣 UTXO，實現 RGB 資產的所有權變更，並通過在 BTC 鏈上發布承諾值（Commitment），確保鏈下數據無法被客戶端私自篡改。實際上，RGB 所謂的「一次性密封」，就是通過鏈下的 RGB 交易聲明，把比特幣 UTXO 和 RGB 資產所有權關聯起來，以此藉助比特幣強大的安全性，來保障 RGB 資產安全。但由於 DA 和數據儲存問題，原始 RGB 協議的可用性及 UX 比較差，且資產容易因為數據丟失而凍結（不可用）。

RGB++：基於 CKB 的加強版 RGB 協議

在上文中，我們總結了 RBG 系統的優點與缺點，其中，客戶端數據孤島、合約狀態無法全局可見，構成了影響 RGB 協議易用性的最主要因素。

實際上，RGB 協議的優點和缺點都很明顯，對隱私和安全有較高追求的人會傾向於自己運行客戶端，並做好數據備份，但長尾用戶顯然沒這個耐心（比如，大多數閃電網路用戶會依賴於第三方節點，而不是自己去運行客戶端）。

基於這個理由，Nervos 聯創 Cipher 提出了名為 RGB++的方案，嘗試將 RGB 的資產狀態、合約發布與交易驗證，委託給 CKB 公鏈來進行。CKB 充當了第三方的數據託管與計算平台，不再需要用戶自己運行 RGB 客戶端。

由於 CKB 本身是拓展的 UTXO 模型（Cell），可以將 RGB 資產的鏈下資訊寫入到 Cell 中，並在 Cell 和比特幣 UTXO 之間建立 1 對 1 的映射關係，實現基於 CKB 的 RGB 資產數據託管與驗證方案，以此解決易用性問題，作為 RGB 原始方案的一種強化補充。

這段話讀起來可能有點繞，對此我們再展開解釋一下：

文章前面提到，RGB 協議本質是通過發布鏈上承諾與鏈下聲明，把比特幣 UTXO 和 RGB 資產所有權關聯起來。但 RGB 資產合約的數據是碎片化存放在不同客戶端本地的，沒有一個全局可見的視圖。

RGB++通過 CKB 的拓展版 UTXO——Cell，把比特幣 UTXO 與對應的 RGB 資產之間的映射關係，直接在 CKB 鏈上展示出來，並且由 CKB 公鏈替代用戶的 P2P 客戶端，驗證每一筆 RGB 轉賬的有效性。有了這樣一個全局可見的 RGB 數據記錄後，很多難以在 RGB 協議中實現的場景都會更容易落地。

（RGB++的交易流程，把 RGB 資產資訊寫入 Cell，再將 Cell 與比特幣 UTXO 建立關聯，最後把 CKB 上發生的 RGB++交易，以及與 RGB++資產關聯的比特幣 UTXO，一併包含在承諾里，再把承諾值寫到比特幣鏈上）

可能有人第一時間想到了 EVM。我們是否可以用 EVM 承載 RGB 的狀態與驗證？答案是：很麻煩，因為 RGB 資產本質上寄生於比特幣 UTXO，與比特幣 UTXO 存在 1 對 1 的映射關係。如果要把比特幣 UTXO 與 EVM 合約數據建立映射關係，在技術實現上並不順暢，還不如直接選擇一條 UTXO 公鏈。

而且，以太坊上的「資產」往往是點對池的公共物品，一個合約上記錄無數人的資產數據，合約控制者擁有絕對權力，這種資產處理方式與比特幣 UTXO 以及 RGB 協議嚴重衝突，後兩者的設計思路，是徹底實現資產的私有化，每個人完全控制自己的資產（想想紙幣和微信支付的區別），不必考慮以太坊和 EVM 鏈一貫存在的：資產合約 owner 濫用職權、合約出 bug 導致資金受損、資產合約的數據要遷移時很麻煩等問題。

所以，如果要將比特幣 UTXO 與鏈下 RGB 資產之間的映射關係表達的較為順暢，最好的選擇還是通過 UTXO 鏈。而 CKB 支持的是拓展型 UTXO——Cell，且 CKB VM 的指令集基於 RISC-V，比起 EVM 更容易兼容不同的密碼學算法，包括比特幣的公私鑰驗證算法，所以更利於實現 RGB++提出的技術方案。

RGB++的技術實現

RGB++用到了 CKB 的拓展型 UTXO——Cell。而一個 Cell 包含以下字段:

Capacity 代表此 Cell 擁有的鏈上空間大小，data 指 Cell 內包含的數據集，可以被讀取或修改。

Type 是這個 Cell 綁定的程序代碼，限制了 data 數據的修改條件。比如，你的 Cell 里有 100 枚 TEST 代幣的數據，但你聲明將 110 枚 TEST 轉給別人，這不符合 Type 里規定的限制條件，會被拒絕。

而 Lock 則代表 Cell 的所有權驗證邏輯，類似於比特幣 UTXO 的解鎖腳本。

我們可以把 Cell 理解為升級版的 UTXO，多出了 Type 和 Capacity 這兩個字段，且 data 可以自定義數據類型，至於 Cell 的所有權變更方式，和比特幣 UTXO 差不多，都是通過解鎖腳本來實現。

而 RGB++的思路是，用 CKB 鏈上的 Cell，表達 RGB 資產的所有權關係。它把原本存放在 RGB 客戶端本地的資產數據，挪到 CKB 鏈上用 Cell 的形式表達出來，讓 CKB 充當 RGB 資產的公開數據庫。而表示 RGB 資產的 Cell，會和比特幣鏈上的 UTXO 存在 1 對 1 的映射關係，這種映射關係會在 Cell 的 Lock 字段里直接展示出來。

比如說，假設某個 RGB 資產關聯着比特幣 UTXO A，則對應的映射版 Cell，可以把自己的所有權驗證條件，設置為和比特幣 UTXO A 一致（就是把 Lock 腳本設置為比特幣 UTXO A 的解鎖條件）。如果你是 UTXO A 的控制者，你就能直接操作 CKB 上的映射 Cell，當然，CKB 會驗證你是不是 UTXO A 的主人。

CKB 鏈上會實現比特幣輕節點，同步比特幣區塊頭。當你聲明 RGB 交易，要對 RGB 資產對應的 Cell 進行操作時，要先證明自己是比特幣 UTXO A 的控制者，證明步驟分兩步：

1. 向 CKB 鏈上實現的比特幣輕節點證明，UTXO A 存在於比特幣鏈上，需要出示 Merkle Proof；

2. 出示數字簽名，證明自己是 UTXO A 的所有者。

在 RGB++方案中，用戶在前端聲明一筆 RGB 資產轉賬後，會在 CKB 鏈上觸發一筆交易，對記錄 RGB 資產數據的 Cell 進行改寫，變更其所有權。原本可能是比特幣 UTXO 1 的控制者擁有這個 Cell，所有權變更後，比特幣 UTXO 2 的控制者成為了 Cell 的新主人。這一切都在 CKB 鏈上可見。

這裡要注意的是，與 BTC 鏈上承諾相關的工作流程，依然在 BTC 主網進行，就是說 RGB++仍然要在比特幣鏈上發布 Commitment，與 CKB 上發生的 RGB 資產交易記錄關聯起來。這一步與傳統 RGB 協議並無不同。

但不同的是，傳統 RGB 協議中由客戶端在鏈下自己負責的工作，都由 CKB 來負責，比如交易對手方要驗證資產來源、客戶端要在本地儲存資產來源數據、RGB 合約發布要通過第三方渠道等，這些繁瑣的包袱都可以由 CKB 負責解決，不需要用戶自己運行客戶端。

這樣解決了 RGB 客戶端數據孤島問題，也解決了合約狀態無法全局可見的缺陷。同時，RGB 合約可以直接部署在 CKB 鏈上，全局可見，供 RGB Cell 來引用，這樣就避免了 RGB 協議合約發布時的一系列奇葩操作。

概括來講，CKB 利用 Cell 腳本的可編程性，先確定 RGB 轉賬發起者 的確擁有 RGB 資產關聯的比特幣 UTXO，若驗證通過，則允許用戶通過轉賬，將記錄 RGB 資產數據的 Cell 轉讓給別人。

簡而概之，CKB 充當了 RGB 資產的公開數據託管平台，提供了數據儲存與全局可見的合約發布功能，也提供了所有權驗證與計算功能。更加精簡一點來說，就是 CKB 替代了 RGB 中的客戶端，並且順帶解決了其他的問題。

當然，RGB++既然實現了全局可見的數據發布，隱私性相比於 RGB 協議必然是降低的，但好處是易用性得到了極大幅度提升。

所以 RGB++本質是用隱私換易用性，同時能帶來 RGB 協議無法實現的場景。如果用戶看重產品的簡單好用和功能完備性，就會青睞 RGB++，如果追求隱私和 Verify by yourself 的安全，就會青睞傳統的 RGB 協議，一切看用戶自己的取捨（思路就和 Vitalik 評論以太坊 Layer2 時表達的差不多，追求安全就去用 Rollup，追求低成本就去用 Validium 和 Optimium 等非 Rollup 方案）。當然，按照 RGB++白皮書中的說法，後續也可以在 CKB 鏈上實現隱私交易方案，隱藏用戶的身份與轉賬金額。

RGB++的附加特性

交易的非交互性（非常重要）

原始 RGB 協議的一個重要問題在於，收款方要先向付款方發送一條消息（就是前文說過的支票），指明把自己的一個 UTXO 與 RGB 資產綁定，RGB 轉賬才能順利實施。這就要求收款方與付款方之間經過多道交互式通信，才能完成一筆普通交易，顯然增加了用戶的理解難度和產品複雜度。而 RGB++利用了 CKB 作為數據託管與計算平台的特性，允許對手方之間通過異步、非交互的方法來完成轉賬。

A 向 B 轉賬時，只需要事先知道 B 的地址，聲明向該地址轉賬，不需要收款人在線通信或提供數據。之後，收款人可以自己去領取資產，CKB 鏈上的腳本代碼，會驗證收款人是否是付款人指定的那個。顯然，這種模式更貼近大多數人的習慣，諸如空投、獎勵分發等原本在 RGB 協議中不支持的模式也可以跑的通，這樣也有利於 RGB 資產發行。

此外，RGB 協議的工作模式天然不利於 Defi 場景的展開，比如 Uniswap 這種典型的多對多、非交互式的交易池，在原始 RGB 協議中幾乎無法展開，而 RGB++實現了非交互式交易、狀態全局可見可驗證，只要借用 Cell 來實現一個「所有滿足條件的人都可以修改其狀態的「無主合約」，就可以把很多 Defi 場景落地。

當然，所有人都可以修改其狀態的無主合約，很容易出現狀態爭用/讀寫衝突，就是好幾個人想同時修改合約狀態，這樣會導致混亂。為了解決這個問題，RGB++計劃用一個鏈上實現的 Intent Cell 作為「排序器」，對不同的請求進行排序。

交易摺疊（聚合多筆交易的承諾發布）

交易摺疊比較好理解，就是把 CKB 作為一個「鏈下預結算層」，等多筆 RGB 轉賬發生後，把一批交易聚合起來，生成一個對應批量交易的 Commitment，一次性發布到比特幣鏈上。具體表現為以下流程圖：

BTC 資產無需跨鏈直接與 CKB 鏈上資產交互

RGB++ 實現了比特幣 UTXO 與 CKB Cell 之間的關聯映射後，可以直接實現無需資產跨鏈的互操作。你可以通過 RGB++交易聲明，把自己的比特幣 UTXO 轉移給別人，對方可以把自己的 CKB 資產所有權轉讓給你。這種模式擁有很大的想象空間，結合前面提到的交易摺疊（批量交易），理論上可以實現無需 BTC 資產跨鏈的 BTC——CKB 鏈上資產互操作。

總結

RGB++把存放在不同 RGB 客戶端本地的資產數據，直接用 CKB 鏈上的 Cell 表達出來，再把 Cell 與比特幣鏈上的 UTXO 關聯起來。用戶可以通過比特幣帳戶/資產，與自己在 CKB 鏈上的 RGB++資產進行交互。這種方式比較簡潔，且解決了 RGB 協議中 轉賬需要雙方事先通訊、難以支持全局可見的狀態、數據儲存碎片化、智能合約及 Defi 不友好等問題。

RGB++無需資產跨鏈，就可以實現 BTC—CKB 之間的互操作，且便於 RGB 資產與 Defi 場景結合，極大程度解決了 RGB 協議的易用性問題。但對於追求高度隱私的 RGB 小眾玩家而言，RGB++本質是以隱私換易用性，一切還要看用戶的取捨。但理論上來講，隱私問題可以在 CKB 鏈上通過引入 ZK 等方法來解決。

整體而言，RGB++展示了 CKB 作為一個比特幣鏈下結算層/計算層的潛力，而這種思路會在未來，被越來越多的比特幣 Layer2 或資產協議所採納，可以預見的是，比特幣鏈下的第三方結算層間的角逐，或許不久後就會展開。而主打 POW 和 UTXO、有著多年技術積澱的 CKB，或許能夠在這場模塊化區塊鏈的角逐中表現出自己的技術優勢。

原文連結