作者：Shew，極客web3
Author: Shew, Extremist Web3
編輯：Faust，極客web3
Editor: Faust, Extremist Web3
摘要： · CKB團隊提出的RGB++資產協議，提出了「同構綁定」的思想，本質是將CKB和Cardano、Fuel等基於UTXO程式設計模型的區塊鏈，作為承載RGB資產「容器」的功能拓展層。這種同構綁定也適用於Atomical、Runes等具有UTXO特性的比特幣生態資產協議，以便為比特幣搭建鏈下的智慧合約層。
· RGB++協議中，使用者不必運行客戶端親自驗證交易數據，可以把驗證資產有效性、資料儲存等工作移交給CKB和Cardanao等UTXO鏈。只要你「樂觀」的認為，上述公鏈的安全性比較可靠，就無需自己去做驗證；
In the agreement between
· RGB++協定支援使用者切換回客戶端驗證模式，此時你依然可以將CKB當作資料儲存/DA層，不必自行保管資料。 RGB++協議無需資產跨鏈，可透過比特幣帳戶對CKB鏈上資產進行操作，並且可以減少往比特幣鏈上發布Commitment的頻率，也利於支援Defi場景；
RGB++ agrees to support users to switch back to the client validation mode, so you can still use CKB as a data storage/DA layer, without having to keep the data yourself. RGB++ provides for the operation of assets on the CKB chain through a bitcoin account, and reduces the frequency of distributions to the bitcoin chain, as well as to support the Defi scene;
·如果是在EVM合約體系下，RGB++的許多特性並不好支援。綜合來看，適合實現同構綁定的公鏈/功能拓展層，應該具有以下特性:
. Many of the features of RGB++ are not well supported under the EVM system. , taken together, suitable for binding public chain/functional extension, should have the following characteristics:
1.使用UTXO模型或類似的狀態儲存方案；
1. save options using UTXO models or similar states;
2.具有相當的UTXO可程式性，允許開發者編寫解鎖腳本；
2. is sufficiently UTXO-producable to allow developers to write unlocked scripts;
3.存在UTXO相關的狀態空間，可儲存資產狀態；
3. has an UTXO-related status space to store assets;
4.可以透過智能合約或其他手段，支援運行比特幣輕節點；
4. can support the operation of bitcoins lightly by means of intellectual contracts or other means;
·除了CKB以外，Cardano、Fuel也可以支援同構綁定，但後兩者在智慧合約語言及合約設計細節上，可能存在一些包袱，目前看來，CKB比後兩者更適合作為同構綁定的比特幣資產協議功能拓展層。
In addition to the CKB, Cardano and Fuel can also support the `consortium', but the latter two may have some liability in terms of the language of wisdom and the design of the contract. At present, the CKB is more appropriate than the latter to cooperate in the functional extension of the `bit currency agreement'.
正文：在RGB++Protocol LightPaper內，Nervos CKB共同創辦人Cipher第一次提出了同構綁定的產品思路。相較於其他比特幣Layer2方案，同構綁定可以更好的相容RGB、Runes和Atomical等資產協議，並且可以避免資產跨鍊等帶來額外安全累贅的因素。
Text: In RGB+Protocol LightPaper, the co-founder of the Nervos CKB, Cipher, for the first time, put forward the idea of a binding product. Compared to the other Biter2 schemes, such asset agreements as RGB, Runes, and Atomical could be better aligned with the binding, and would avoid extra security complications such as the cross-chaining of assets.
簡單來說，同構綁定是用CKB和Cardano鏈上的UTXO做“容器”，將RGB等UTXO型資產表達出來，進而為其添加可編程性和更多更複雜的場景。在此之前，極客web3曾在《從BTC到Sui、ADA與Nervos：UTXO模型及其相關拓展》總結一系列支援可程式UTXO的區塊鏈，本文將進一步探討這些區塊鏈是否可以適配同構綁定方案。
In short, the same structure is set to use the UTXO on the CKB and Cardano chains as a “container” to capture the UTXO-type assets, such as the RGB, and to add a more programmed and complex scene. Previously, the Veterans Web3 had developed a series of supportable UTXO chains in BTC to Sui, ADA and Nervos: UTXO models and their associated outreach, and this paper will look further at whether these links can fit into the same structure.
在分析不同UTXO鏈對同構綁定的相容程度前，我們要先介紹同構綁定的原理。同構綁定是CKB團隊在RGB++協定中提出的概念，所以這裡我們以RGB++的工作流程，來介紹基於CKB的同構綁定是什麼。
Before analysing the compatibility of different UTXO chains with the binding structure, we should first describe the principles of the same structure. The same structure is the concept proposed by the CKB team in the RGB++ agreement, so here we will describe the same structure based on the CKB with the RGB++ workflow.
在介紹RGB++協定前，我們先簡單了解RGB協定。 RGB是一種運行在比特幣鏈下的資產協議/P2P網絡，有點像閃電網絡一樣。此外，RGB還是一種基於比特幣UTXO的寄生資產協議，所謂寄生，是指RGB客戶端會在比特幣鏈下，聲明某些RGB資產與比特幣鏈上哪個UTXO相綁定，你擁有了這個UTXO，它綁定的RGB資產也歸你差遣。
RGB is an asset agreement/P2P network operating under the Bits Chain, sort of like a lightning network. Moreover, RGB is a parasitic agreement based on the BitcoinUTXO, which refers to the fact that the RGB client will identify under the Bits Chain which UTXO will bind some of the RGB assets to the Bits Chain, and that you own the UTXO.
RGB協議和ERC-20等資產協議的運作方式截然不同。以太坊上的ERC-20合約中，記錄了所有使用者的資產狀態，且以太坊的節點客戶端會同步並驗證所有的轉帳訊息，把轉帳後的狀態更新記錄在資產合約中。這其實早已被人們所熟知，無非是靠以太坊的共識流程，來確保資產的狀態變更沒貓膩。由於以太坊節點們的共識很可靠，用戶就算不運行客戶端，也可以預設基於ERC-20合約的資產託管平台「沒問題」。
The RGB agreement and the ERC-20 deal operate in very different ways. The ERC-20 agreement in the Taiwann records the asset status of all users, and all transfers are synchronized and verified by the Taiyu node clients, and post-transfer status updates are recorded in the property contract. This is already well known, not only through the Etheria consensus process, to ensure that the asset status becomes less problematic. Since the Ether node shares are reliable, users, even if they do not run a client, can pre-empt the EPC platform based on the ERC-20 agreement 'no problem'.
但RGB協定卻很奇葩，它為了增強隱私性，乾脆把節點/客戶端共識這個在區塊鏈世界裡約定俗成的東西刪掉了。使用者要自己運行RGB客戶端，只接收和儲存“與自己相關的資產資料”，看不到別人都乾了啥，不像以太坊和ERC-20那樣，有鏈上全部可見的轉帳記錄。
The RGB agreement, however, is surprising, because in order to enhance privacy, the node/customer shared this custom in the chain world should be deleted. Users are required to run the RGB client on their own and only receive and save their own “property data” and cannot see what others are doing, unlike Ether and ERC-20, with all the visible transfer records on the chain.
這種情況下，如果有人給你轉來一些RGB資產，你事先並不知道這些錢是怎麼造出來的，轉手自哪些人。如果對面那個人憑空宣稱一種資產，然後轉給你一部分，這種造假幣的作惡場景怎麼處理？
In this case, if someone transfers some RGB assets to you, you don't know how this money is made and who it is. If the person across the street claims an asset and transfers it to you part of it, what will happen to the counterfeiting of the money?
RGB協議採用了這樣一種思路：每一筆轉帳生效前，接收者先讓發送者出示該資產的全部歷史記錄，例如從創世階段到現在，這些資產是由誰發行的，中間途經哪些人，在這些人之間發生的每一次資產轉移，是否都不違反會計記帳準則（一人加，一人減）。
The RGB agreement adopted the idea that before each transfer came into effect, the recipient would first ask the sender to show the entire historical record of the asset, for example, from the founding period to the present, by whom, by whom, and by whom, and whether every transfer between them would not violate the accounting standards (one plus one less).
這樣一來，你就能知道對面給你的是不是“有問題的錢”，所以說RGB本質是讓交易當事人自己運行客戶端做驗證，基於客戶端驗證模式，對應著理性人博弈假設，只要當事人理智，客戶端軟體沒問題，就能確保有問題的資產轉移無法生效，或無法被其他人認可。
In this way, you will know whether the opposite side gives you “problem money”, so the RGB essence is to let the trader run the client itself as proof, based on the client-testing model, and on the assumption that the rational person is playing games, so long as the client is reasonable and the client-client software is okay, the transfer of the asset that keeps the problem will not work or be recognized by others.
值得注意的是，RGB協議會把這些比特幣鏈下的交易數據，壓縮為Commitment（本質是個merkle root），上傳到比特幣鏈上，這就讓鏈下的轉帳記錄，與比特幣主網直接產生關聯。
It is worth noting that the RGB Council compressed these transactions under the bits chain to the Committee (which is essentially a merkel root) and uploaded them onto the bits chain, which directly links the chain to the Bits Main Network.
由於RGB客戶端之間沒有共識，RGB資產合約的發布無法「極其可靠」的傳播給所有節點，合約發布者和用戶乾脆就透過電子郵件或是推特等任意形式，自發的獲知RGB資產合約的細節，形式非常隨意。
Since there is no common understanding among the RGB clients, the issuance of the RGB property contract cannot be disseminated to all nodes as “extremely reliable” and both the publishers and users of the contract are aware of the details of the RGB property contract spontaneously, either via e-mail or Twitter, in any form they choose.
下圖中展示了惡意的RGB資產轉移場景，作為RGB用戶，我們要在自己的客戶端本地，儲存RGB資產對應的智慧合約。當其他人向我們轉帳時，我們根據本地儲存的資產合約內容，可以知道目前這筆轉帳是否違反合約中定義好的規則。根據對面提供的資產來源資訊（歷史記錄），可以確認對方的資產來源有沒有問題（是不是憑空聲明出來的）。
Here is a picture of the malignant RGB conversion, which, as RGB users, we want to save the intellectual contract of RGB assets locally on our client base. When others transfer to us, we know whether the transfer is currently in violation of the rules set out in the contract, depending on whether the asset source (historical records) is an open source of information from the opposite side.
複盤上述流程，不難看出，不同的RGB客戶端接收並儲存的資料往往是獨立的，你往往不知道別人有哪些資產，有多少金額。反過來，別人基本上也不知道你的資產狀況。
It is easy to copy the processes described above that different RGB clients tend to receive and store data independently, and you often don't know what other people have and how much money they have. In contrast, people don't know much about your assets.
這就是典型的資料孤島，也就是大家儲存的資料都不一致。理論上雖然可以提高隱私程度，但相應的也帶來了許多麻煩。你必須在自己的客戶端本地維護好RGB資產的數據，這些數據一旦遺失，就會造成嚴重後果（資產不可用）。但事實上，只要你維護好本地數據，RGB協議就可以為你帶來和比特幣主網基本等價的安全性。
This is the typical data-separation island, where the data you store are not consistent. The theory increases privacy, but it also creates a lot of problems. You have to maintain local data on RGB assets on your client base, which, if lost, will have serious consequences. But, in fact, if you maintain local data, the RGB agreement will provide you with security at the basic price of the Bitcoin home network.
此外，RGB客戶端之間通訊用的Bifrost協議，會協助用戶和其他客戶端進行p2p通訊，可以把他的資產數據加密後傳播給其他節點，叫對方幫忙儲存（注意是加密後的數據，對面不知道明文）。只要你不把金鑰也弄丟了，在本地資料遺失時，可以透過網路中其他節點，還原出自己原本擁有的資產資料。
In addition, the Bifrost agreement for communication between RGB clients helps users and other clients with p2p communications, which allows them to encrypt their data and transmit it to other nodes, asking each other for help to save it (note that it is a post-encrypted data, which is not specified on the other side). As long as you do not lose the key, in the event of local data loss, you can return your original assets through other nodes of the Internet.
但原始RGB協議的缺點還是很明顯，首先每筆交易都要求雙方進行多次通訊，接收方要先驗證發送方的資產來源，然後發送回執，批准發送方的轉帳請求。這個過程中，雙方之間至少要產生三次訊息傳遞。這種「互動式轉帳」和大多數人所習慣的「非互動式轉帳」嚴重不符合，你能想像，別人要給你轉錢，還要把交易資料發給你來檢查，得到你的回執訊息後，才能完成轉帳流程嗎？ （流程圖在前文可見）
But it is obvious that the original RGB agreement requires, first, that each transaction requires multiple communications between the two parties, that the recipient verify the origin of the sender's assets, and then send them back to the recipient and approve the sender's request for transfer. In this process, at least three messages are sent between the two parties. This “interactive transfer” and the “non-interactive transfer” used by most people are seriously incompatible.
其次，絕大多數的Defi場景都需要資料透明、狀態可驗證的智能合約，但RGB協定天生不支援此類場景，所以是對Defi非常不友善的；此外，RGB協定裡用戶必須去運行客戶端做自驗證，如果你偶然間接收到一筆轉手自幾萬人的資產，你甚至還要驗證這筆資產的幾萬次轉手記錄。很顯然，所有的事情都讓使用者去自行解決，並不利於產品本身的推廣與採用。
Second, most of the Defi scenes require intellectual contracts that are transparent and state-verifiable, but the RGB agreement does not support the scene, and is therefore very unfriendly to Defi; moreover, the RGB agreement users are required to conduct self-test their clients, and if you occasionally receive a transfer of money from tens of thousands of people, you will even have to verify the records of tens of thousands of transfers. Obviously, everything is left to the users themselves and does not benefit from the promotion and adoption of the product itself.
對於上述問題，RGB++的解決想法是：讓使用者在客戶端自驗證模式，與第三方託管模式之間自由切換，使用者可以把資料驗證與儲存、智慧合約託管等包袱，甩給CKB去承擔，當然使用者要樂觀的信任，CKB這條POW公鍊是可靠的；如果某些對安全和隱私有更高追求的人，比如手握大量資產的大戶，也可以回退到原始的RGB模式。這裡要強調的是，RGB++和原始的RGB協議，理論上是可以彼此相容的，並不是有他無我。
The idea of RGB++ is to allow users to freely switch their client-to-client self-testing models to third-party trust models. Users can take responsibility for data validation and storage, intellectual contract management, etc., and dump CKBs to bear the burden. Of course, the CKB Pow chain is reliable. If some people who are more interested in security and privacy than others, such as large-scale owners holding large amounts of assets, can return to the original RGB model.
在先前的文章《從RGB到RGB++：CKB如何賦能比特幣生態資產協議》中，我們曾簡單科普過RGB++的“同構綁定”，這裡我們再快速的複盤下：
In our previous article, From RGB to RGB++: How CKB can give Bitcoin to Genesis, we had a simple "co-consolidation" of RGB++, and here we have a quick copy:
CKB有自己的拓展型UTXO，叫Cell，它比BTC鏈上的UTXO多出了可程式性。而“同構綁定”，就是將CKB鏈上的Cell作為RGB資產資料的“容器”，把RGB資產的關鍵參數寫入到Cell中。
CKB has its own extension UTXO, Call, which is more programmatic than the UTXO on the BTC chain. Instead, “consorted” means that Cell on the CKB chain is used as a “container” for RGB data, and key parameters for RGB assets are written into Cell.
由於RGB資產和比特幣UTXO之間存在綁定關係，所以在資產的邏輯形式上具備UTXO的特性。而同樣具備UTXO特性的Cell，自然適合作為RGB資產的「容器」。每當RGB資產交易發生時，對應的Cell容器，也可以呈現出相似的特徵，就像是實體和影子的關係一樣，這便是「同構綁定」的精髓。
Since there is a binding relationship between the RGB asset and the Bitcoin UTXO, there is a UTXO feature in the logical form of the asset. Cell, also a UTXO character, naturally cooperates with the RGB asset's 'container'. Every time an RGB asset deals take place, a similar feature can be presented, like the physical and shadow relationship, which is the essence of "consistence."
For example，假如Alice擁有100枚RGB代幣，以及比特幣鏈上的UTXO A，同時在CKB鏈上有一個Cell，這個Cell上標記著“RGB Token Balance：100”，解鎖條件與UTXO A有關聯。
For example, if Alice had 100 RGB coins and UTXO A on the Bit currency chain, there was a Cell on the CKB chain, marked “RGB Token Balance:100”, and the unlocking terms were linked to UTXO A.
如果Alice想把30枚代幣送給Bob，可以先生成一個Commitment，對應的聲明是：把UTXO A關聯的RGB代幣，轉移30枚給Bob，70枚轉給自己控制的其他UTXO。
If Alice wants to deliver 30 coins to Bob, he can turn them into a committee statement stating that the UTXO A-linked RGB currency is transferred 30 to Bob and 70 to other UTXOs under his control.
之後，Alice在比特幣鏈上花費UTXO A，發布上述聲明，然後在CKB鏈上發起交易，把承載100枚RGB代幣的Cell容器消費掉，產生兩個新容器，一個容納30枚代幣（給Bob），一個容納70枚代幣（Alice控制）。在此過程中，驗證Alice的資產有效性與交易聲明有效性的任務，是由CKB網路節點走共識來完成的，不需要Bob介入。 CKB此時充當了一個比特幣鏈下的驗證層與DA層。
After that, Alice spent the UTXO A on the Bit currency chain, issuing the above statement, and then trading on the CKB chain to charge the cell container carrying 100 RGB coins, generating two new containers, one for 30 tokens (to Bob) and one for 70 tokens (to Alice control). During this process, the task of verifying the validity of Alice’s asset and transaction statement was done by an agreement between the CKB network no longer required Bob’s intervention.
這就類似於以太坊ERC-20合約每次狀態變更，不需要用戶去運行客戶端驗證，道理差不多，由共識協議和節點網絡，來取代客戶端驗證。而且，所有人的RGB資產資料都存放在CKB鏈上，具有全域可驗證的特性，這利於Defi場景的實現，例如流動性池和資產質押協議等。
This is similar to every change in the status of the TERC-20 agreement in the Taiku, which does not require users to run a client validation, which is basically replaced by a shared agreement and node network. Moreover, all RGB data are stored on the CKB chain and have proven properties worldwide, which are beneficial to the Defi scene, such as flow pools and asset pledge agreements.
這裡面其實引入了一個重要的信任假設：使用者往往要樂觀的認為，CKB這條鏈，或者說由大量節點靠共識協議組成的網路平台，是可靠無誤的。如果你不信任CKB，也可以遵循原始RGB協定中的互動式通訊與驗證流程，自己運行客戶端。
In fact, an important trust assumption has been introduced: users often have to be optimistic that the CKB chain, or a network platform that is composed of a large number of nodes based on a consensus agreement, is reliable. If you do not trust the CKB, you can also follow the interactive communication and validation process in the original RGB agreement and run the client yourself.
當然，如果有人偏要自己運行RGB++客戶端，驗證別人的資產歷史來源，他可以直接驗證CKB鏈上與RGB資產容器Cell相關的歷史。只要運行一個CKB輕節點，透過接收Merkle Proof和CKB區塊頭，就可以確信自己收到的歷史數據，沒被網路中的惡意攻擊者竄改。可以說，CKB在這裡又充當了歷史資料儲存層。
Of course, if someone wants to run the RGB++ client on his own to verify the origin of someone else’s property history, he can directly verify the history of the CKB chain associated with the Cell of the RGB asset container. By running a CKB light node to receive the Merkele Proof and CKB sections, he can be sure that he has received the historical data and has not been altered by the malignant attacker on the Internet.
簡單來說，同構綁定不但適用於RGB，還適用於Runes、Atomical等各種有UTXO特性的資產協議，它將儲存在用戶客戶端本地的資產狀態、歷史數據，以及對應的智慧合約，全部挪給CKB或Cardano等UTXO型公鏈來儲存和託管。上述UTXO型資產協議，可以把CKB或Cardano的UTXO模型作為“容器”，藉著容器來展現出資產的形態與狀況，便於配合智能合約等場景。
Simply put, the same structure is suitable not only for RGB, but also for various UTXO-specific asset agreements, such as those in Runs and Atomical, which will store local assets, historical data, and corresponding intelligence contracts on client clients, all of which will be transferred to the UTXO public chain, such as CKB or Cardano. The above-mentioned UTXO product agreement will use the UTXO model as a “container” that will be used to demonstrate the shape and state of the asset by means of containers, so as to cooperate with intellectual conformity, etc.
而且在同構綁定協議下，用戶無需跨鏈即可直接用比特幣帳戶，操作自己在CKB等UTXO鏈上的RGB資產容器，只需要藉助Cell的UTXO特性，把Cell容器的解鎖條件設定為與某個比特幣地址/比特幣UTXO相關聯即可。由於在極客web3之前的RGB++科普文中，我們已經對Cell的特性進行過解讀，所以不在此贅述。
Also, under a binding agreement, users can use their own RGB asset containers on the UTXO chain, such as the CKB, without having to cross the chain, directly using the Bit currency account, and simply use the UTXO features of the Cell to set the conditions of the Cell container to be linked to a bitcoin address/bitcorate UTXO. Since in RGB+Civin, before the polar web3, we have been able to interpret the characteristics of the Cell, so we do not describe them here.
如果RGB資產交易雙方信得過CKB的安全性，甚至不必頻繁的在比特幣鏈上發布Commitment，可以在許多筆RGB轉賬進行後，再匯總發送一個Commitment到比特幣鏈上，這被稱為“交易折疊”功能，可以降低使用成本。
If both parties to the RGB transaction are confident of the security of the CKB, even without the need for frequent distribution of the Committee on the Bit currency chain, the cost of use can be reduced by sending a Committee to the Bit currency chain after many RGB transfers have been made.
但要注意的是，同構綁定採用的“容器”，往往需要支援UTXO模型的公鏈，或在狀態存儲上有類似特徵的infra，而EVM鏈顯然不太適合，在技術實現上會遇到很多坑。首先，前文提到RGB++“無需跨鏈即可操作CKB鏈上資產容器”，基本就無法在EVM鏈身上實現；就算強行實現，成本也可能很高；
However, it should be noted that co-structured “containers” for use in binding are often required to support the UTXO public chain, or to have a similar infra on the state memory, which is clearly not appropriate, with many pits encountered in technology. First, the reference to RGB++ in the previous text to “operating the CKB chain without the need to cross the chain” is largely impossible to achieve on the EVM chain; if it is enforced, the costs can also be high;
再者，在RGB++協定中，很多人沒有必要運行客戶端或是把資產資料存放在本地。如果用ERC-20的方式，把所有人的資產餘額都記錄在這個合約中，假如有人要回退到客戶端自驗證的模式，他提出要檢查某個人的資產來源，此時他就可能要把所有和資產合約產生互動的交易記錄，全都掃描一遍，這會帶來巨大壓力。
Moreover, in the RGB++ agreement, many people do not have to run their clients or store their property data locally. If, in the form of the ERC-20, the rest of everyone’s assets are recorded in the contract, and if someone returns to the client self-testing model, he proposes to check the origin of a person’s assets, then he may want to create an interactive record of all the transactions with the property contract, which would put a huge strain on it.
直白的說，ERC-20等資產合約，把所有人的資產狀態耦合在一起存儲，如果你要單獨檢驗其中某個人的資產變更歷史記錄，將會變得很難，就好像在一個公用的聊天室中，你想知道有哪些人給王剛發過訊息，就不得不把整個聊天室裡的消息記錄頂朝天翻一遍。而UTXO就像是一對一的私聊頻道，你要查歷史記錄會很容易。
To put it straight, property contracts such as the ERC-20, which binds everyone's property status together, would be difficult if you were to test the history of one of them alone, as if, in a public chat room, you wanted to know who sent a message to Wang Kong, and you had to record the entire chat room over the sky. And UTXO was like a one-on-one private chat channel, and it would be easy for you to check history.
綜合來看，適合實現同構綁定的公鏈/功能拓展層，應該具有以下特性:
Taken together, a public chain/functional extension layer suitable for contemplation should have the following characteristics:
- 使用UTXO模型或類似的狀態儲存方案；
- 具有相當的UTXO可編程性，允許開發者編寫解鎖腳本；
- 存在UTXO相關的狀態空間，可儲存資產狀態；
- 存在比特幣相關橋或輕節點；
當然，我們也希望用於同構綁定的公鏈具有較強的安全性，另一方面，我們也希望該公鏈上的UTXO解鎖條件，應當是可編程的，如此一來，用戶就可以直接用BTC的簽章方案，解鎖自己在其他公鏈上同構綁定的UTXO，而不需要再更換簽章演算法。
Of course, we want to use the same chain for greater security. On the other hand, we also want the UTXO on the chain to be programmed so that users can use the BTC signature formula directly to unlock their UTXO on the other public chain without changing the signature algorithm.
目前，CKB上UTXO的鎖定腳本是可編程的，官方對此也相容了不同公鏈的簽章方案，對於同構綁定而言， CKB網路基本上符合以上幾個特性，那其他基於UTXO的公鏈呢？我們對Fuel和Cardano進行了初步考察，認為他們在理論上都可以支持同構綁定。
At present, the UTXO lock-in script on CKB is programmed, and the official signature formula for the different public chains is compatible. For the purposes of structuring, the
Fuel是基於UTXO的以太坊OP Rollup，還是把詐欺證明概念引入以太坊Layer2生態的先驅。對於正常的UTXO功能支持，Fuel與BTC是基本一致的。
Fuel is based on the UTXO-based OP Rollup, or introduces the concept of fraud proof into a prelude to the NT-Layer2 ethos. For normal UTXO support, Fuel and BTC are basically consistent.
在Fuel 將其內部的UTXO 分為了以下三類:
divides its inner UTXO into three categories in Fuel: .
Input Coin：標準的UTXO，用於表示使用者的資產，具有原生的時間鎖，同時允許使用者編寫解鎖腳本predicate；
Input Coin: standard UTXO, used to represent the user's assets, with an original time lock, while allowing the user to write a unlocked script;
Input Contract：用於合約呼叫的UTXO，內部包含合約的狀態根和合約資產等資料；
Input Contracting: UTXO, used for contractual calls, contains data on the contractual status and assets;
Input Message：用於傳遞訊息的UTXO，主要包含訊息接受人等欄位；
Input Message: UTXO for the transmission of messages, which includes, inter alia, recipients of messages;
當使用者花費UTXO後會產生以下輸出:
When a user spends UTXO, it produces the following output:
Output Coin：用於標準的資產轉帳；
Output Coin: for standard property transfers;
Output Contract :合約互動產生的輸出，內部包含合約互動後的狀態根；
(a) Output Contract Created :一種特殊的UTXO，是創建合約時產生的輸出，內部包含合約的ID與狀態根； Output Contractor Created: 與CKB的Cell 內部包含所有的合約狀態不同，Fuel的UTXO實際上並不會攜帶所有的與交易有關的合約狀態。 Fuel只在UTXO內，帶著有合約的狀態根Stateroot，也就是狀態樹的root。合約的完整狀態儲存在Fuel的狀態庫內部，由智能合約所擁有。 Unlike CKB’s inner Cell, which contains all the contracts, Fuel’s UTXO does not actually carry all the transactions-related contracts. Fuel is only in UTXO, with the state of the contract statateroot, or the status tree root. 值得一提的是，對於智能合約的狀態處理，Fuel合約與solidity合約在思想上一致，甚至在程式設計的形式上也比較接近。下圖展示了一個用Fuel的Sway語言編寫的計數器合約，該合約包含一個計數器，當使用者呼叫increment_counter函數時，合約內儲存的計數器就自增1。 我們可以看到，Sway合約的編寫邏輯與一般的Solidity合約相似，我們首先給出合約的ABI，然後給出合約的狀態變量，然後給出合約的具體實現。所有的程式碼編寫流程並沒有牽涉到Fuel的UTXO系統。 As we can see, the logic of Sway's writing is similar to the normal Solidity contract, and we give the contract ABI first, then the contract's status change, and then the contract's physical reality. All code-writing processes do not involve the Fuel UTXO system. 所以，Fuel的合約程式設計體驗不同於CKB和Cardanao等UTXO型程式語言，Fuel提供了更接近EVM智能合約程式開發的體驗。開發者也可以使用Sway語言建構解鎖腳本，以實現特殊的簽章演算法驗證邏輯，或複雜的多簽等解鎖邏輯。 As a result, Fuel’s contractual design differs from the UTXO language of CKB and Cardanao, and Fuel provides a closer look to the development of an EVM intelligent program. Developers can also use Sway language to construct lock scripts to validate special signature algorithm logic, or complex multiple signatures, etc. 在Fuel內實現同構綁定是基本可行的，但還是存在以下問題: While Fuel所使用的sway語言，在智能合約設計方面，思想更接近EVM鏈，而不是契合BTC或CKB和Cardano，RGB、Atomicals等UTXO型資產的發行者，要在Fuel上專門構造一種智能合約，在CKB等鏈上用另一種，這是相當複雜的。 The Sway language used by Fuel, in terms of intellectual contract design, is much closer to the EVM chain than to the authors of UTXO-type products such as BTC or CKB and Cardano, RGB, Atomicals, etc., which is rather complicated by creating an intellectual contract on Fuel and using another on the CKB chain. Cardaon是另一個使用UTXO模型的區塊鏈，但不同於Fuel，它是一個Layer1公鏈。 Cardano用eUTXO（拓展型UTXO）來稱呼其係統內的UTXO程式設計模型。相較於CKB， Cardano內的eUTXO包含以下幾部分結構: Cardaon is another chain using the UTXO model, but unlike Fuel, it's a Layer1 public chain. Cardano calls it a traditional UTXO design model with eUTXO (extended UTXO). EUTXO in CKB, Cardano contains the following components: Script:智能合約，用於驗證UTXO是否可以解鎖與執行狀態轉換； Redeemers:用戶提供的解鎖UTXO的數據，一般為簽名數據，類似比特幣的Witness； Redeemers: users provide data to unlock UTXO, usually signature data, similar to Bitcoin Witness; Datum:智能合約的狀態空間，可儲存資產狀態等資料； Datum: intelligent contract space to store data such as asset status; Transaction Context: UTXO交易的上下文數據，如交易的輸入參數和結果（UTXO鏈的交易計算過程在鏈下直接進行，把計算結果提交到鏈上去驗證。若通過驗證，則交易結果上鍊） 開發者可以使用PlutusCore語言在Cardano鏈上進行UTXO的編程，與CKB類似，開發者可以編寫解鎖腳本和一些用於狀態更新的函數。 The developers can program UTXO on the Cardano chain using the PlutusCore language, similar to the CKB, and write unlocked scripts and some functions updated in the state. 我們以基於UTXO的拍賣流程介紹Cardano的UTXO程式設計模式。假設我們需要實現一個資產拍賣DAPP，要求用戶可以在拍賣結束前給予報價，具體來說，就是用戶消費自己的UTXO，與此拍賣合約UTXO，然後產生一個新的拍賣UTXO。當有人給予更高報價時，除了產生新的拍賣合約UTXO，也會產生對上一個人的退款UTXO。具體流程如下圖: We introduce the UTXO program design model based on the UTXO auction process. Assuming that we need to realize a patented DAP that requires users to pay their own UTXO before the auction is over, in particular, users charge their own UTXO, and then create a new auction UTXO. When someone offers a higher price, in addition to creating a new contract UTXO, they also generate a refund of UTXO to a person. 要實現上述拍賣流程，需要在拍賣智能合約UTXO內儲存一些狀態，例如目前拍賣的最高價與給予報價的人。下圖展示了PlutusCore內部的狀態聲明，我們可以看到，bBidder和bAmount展示了拍賣的報價和給出報價的錢包地址。而Auction Params內則包含拍賣的基本資訊。 To realize the auction process, there are situations that need to be stored in the auctioning smart contract UTXO, such as the maximum price of the auction and those who offer it. The following graph shows the state of PlutusCore, as we can see: bBidder and bAmount show the price of the auction and the address of the wallet that gave it. 當使用者花費此UTXO時，我們可以更新合約內的狀態。下圖展示了拍賣合約內一些具體的狀態更新和業務邏輯。例如校驗用戶報價和校驗目前拍賣是否仍在進行的邏輯。當然，由於PlutusCore是Haskell程式語言，這是一種純函數式程式語言，大部分開發者可能無法直接看懂其意義。 When users spend on UTXO, we can update the status of the contract. The following is an illustration of some of the specific status updates and business logic in the auction contract. For example, proof of the user's price and proof of the logic of whether the auction is still going on. Of course, is because PlutusCore is a Haskell program language, which is a pure function, and most developers may not be able to understand it directly. 在Cardano上建構同構綁定具有可行性，我們可以使用Datum儲存資產狀態，並編寫特定的腳本來相容於比特幣相關簽章演算法。但嚴重的問題是，大部分程式設計師可能無法適應使用PlutusCore進行合約編程，而且其編程環境是較難搭建的，對開發者而言並不友善。 But the serious problem is that most designers may not be able to adapt to PlutusCore for contractual programming , and that its programming environment is difficult to construct. 同構綁定要求鏈具有下列屬性: has the following attributes: Fuel由於其智能合約編程思想的特殊性，雖然可以兼容同構綁定，但還是會帶來一些包袱；而Cardaon使用Haskell 編程語言進行合約編程，大部分開發者很難快速上手。基於上述理由，採用RISC-V指令集並在UTXO編程的特性上更平衡的CKB，可能是更適配同構綁定的功能拓展層。 For these reasons, the introduction of the RISC-V command set and a more balanced CKB with the features of the UTXO programming may be better suited to the functional extension layer of the conflation.
注册有任何问题请添加 微信：MVIP619 拉你进入群
打开微信扫一扫
添加客服
进入交流群
发表评论