RGB++無需資產跨鏈，就可以實現 BTC—CKB 之間的互操作，且便於 RGB 資產與 Defi 場景結合，極大程度解決了 RGB 協定的易用性問題。
作者：Shew & Faust，極客 Web3
顧問：CyberOrange，Unipass
封面：Photo by Shubham Dhage on Unsplash
摘要（較長）：· 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 协议中实现的场景都会更容易落地。
可能有人第一時間想到了 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，或許能夠在這場模組化區塊鏈的角逐中表現出自己的技術優勢。
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
