By Bitcoin पत्रिका - 1 साल पहले - पढ़ने का समय: 9 मिनट
RGB मैजिक: क्लाइंट-साइड कॉन्ट्रैक्ट ऑन Bitcoin
RGB is a method of ownership verification built on Bitcoin that allows for the continuation of Bitcoinके गुण.
This is an opinion editorial by Federico Tenga, a long time contributor to Bitcoin projects with experience as start-up founder, consultant and educator.
छवि स्रोतThe term "smart contracts" predates the invention of the blockchain and Bitcoin itself. Its first mention is in a निक स्जाबो द्वारा 1994 का लेख, who defined smart contracts as a "computerized transaction protocol that executes the terms of a contract." While by this definition Bitcoin, thanks to its scripting language, supported smart contracts from the very first block, the term was popularized only later by Ethereum promoters, who twisted the original definition as "code that is redundantly executed by all nodes in a global consensus network"
एक वैश्विक सर्वसम्मति नेटवर्क के लिए कोड निष्पादन को सौंपने के फायदे हैं (उदाहरण के लिए लोकप्रिय स्वचालित बाजार निर्माताओं जैसे अज्ञात अनुबंधों को तैनात करना आसान है), इस डिजाइन में एक प्रमुख दोष है: मापनीयता (और गोपनीयता) की कमी। यदि किसी नेटवर्क में प्रत्येक नोड को एक ही कोड को अनावश्यक रूप से चलाना चाहिए, तो नोड चलाने की लागत में अत्यधिक वृद्धि किए बिना वास्तव में निष्पादित किए जा सकने वाले कोड की मात्रा (और इस प्रकार विकेंद्रीकरण को संरक्षित करना) दुर्लभ रहता है, जिसका अर्थ है कि केवल कुछ ही अनुबंधों को पूरा किया जा सकता है। निष्पादित।
लेकिन क्या होगा अगर हम एक ऐसी प्रणाली डिजाइन कर सकते हैं जहां अनुबंध की शर्तों को नेटवर्क के सभी सदस्यों के बजाय केवल शामिल पक्षों द्वारा निष्पादित और मान्य किया जाता है? आइए एक ऐसी कंपनी के उदाहरण की कल्पना करें जो शेयर जारी करना चाहती है। जारी करने के अनुबंध को सार्वजनिक रूप से एक वैश्विक बहीखाता पर प्रकाशित करने और स्वामित्व के भविष्य के सभी हस्तांतरणों को ट्रैक करने के लिए उस बहीखाता का उपयोग करने के बजाय, यह निजी तौर पर शेयरों को जारी कर सकता है और खरीदारों को उन्हें आगे स्थानांतरित करने का अधिकार दे सकता है। फिर, स्वामित्व को स्थानांतरित करने का अधिकार प्रत्येक नए मालिक को दिया जा सकता है जैसे कि यह मूल जारी करने के अनुबंध में संशोधन हो। इस तरह, प्रत्येक मालिक स्वतंत्र रूप से सत्यापित कर सकता है कि उसे प्राप्त शेयर मूल अनुबंध को पढ़कर वास्तविक हैं और यह सत्यापित करते हैं कि संशोधनों का सारा इतिहास जो शेयरों को स्थानांतरित करता है, मूल अनुबंध में निर्धारित नियमों के अनुरूप है।
यह वास्तव में कोई नई बात नहीं है, यह वास्तव में वही तंत्र है जिसका उपयोग सार्वजनिक रजिस्टरों के लोकप्रिय होने से पहले संपत्ति को स्थानांतरित करने के लिए किया गया था। उक में, for example, it was not compulsory to register a property when its ownership was transferred until the ‘90s. This means that still today over 15% of land in England and Wales is unregistered. If you are buying an unregistered property, instead of checking on a registry if the seller is the true owner, you would have to verify an unbroken chain of ownership going back at least 15 years (a period considered long enough to assume that the seller has sufficient title to the property). In doing so, you must ensure that any transfer of ownership has been carried out correctly and that any mortgages used for previous transactions have been paid off in full. This model has the advantage of improved privacy over ownership, and you do not have to rely on the maintainer of the public land register. On the other hand, it makes the verification of the seller's ownership much more complicated for the buyer.
स्रोत: अपंजीकृत अचल संपत्ति स्वामित्व का शीर्षक विलेखअपंजीकृत संपत्तियों के हस्तांतरण में सुधार कैसे किया जा सकता है? सबसे पहले, इसे डिजिटाइज्ड प्रक्रिया बनाकर। यदि कोई ऐसा कोड है जो यह सत्यापित करने के लिए कंप्यूटर द्वारा चलाया जा सकता है कि स्वामित्व हस्तांतरण का पूरा इतिहास मूल अनुबंध नियमों के अनुपालन में है, तो खरीदना और बेचना बहुत तेज और सस्ता हो जाता है।
दूसरे, विक्रेता द्वारा अपनी संपत्ति को दोगुना खर्च करने के जोखिम से बचने के लिए, प्रकाशन के प्रमाण की एक प्रणाली को लागू किया जाना चाहिए। उदाहरण के लिए, हम एक नियम लागू कर सकते हैं कि स्वामित्व का प्रत्येक हस्तांतरण एक प्रसिद्ध समाचार पत्र के पूर्वनिर्धारित स्थान पर किया जाना चाहिए (उदाहरण के लिए न्यूयॉर्क के पहले पृष्ठ के ऊपरी-दाएं कोने में स्वामित्व के हस्तांतरण का हैश डालें) टाइम्स)। चूँकि आप एक स्थानान्तरण के हैश को एक ही स्थान पर दो बार नहीं रख सकते हैं, यह दोहरे खर्च के प्रयासों को रोकता है। हालाँकि, इस उद्देश्य के लिए एक प्रसिद्ध समाचार पत्र का उपयोग करने के कुछ नुकसान हैं:
You have to buy a lot of newspapers for the verification process. Not very practical.Each contract needs its own space in the newspaper. Not very scalable.The newspaper editor can easily censor or, even worse, simulate double-spending by putting a random hash in your slot, making any potential buyer of your asset think it has been sold before, and discouraging them from buying it. Not very trustless.For these reasons, a better place to post proof of ownership transfers needs to be found. And what better option than the Bitcoin blockchain, an already established trusted public ledger with strong incentives to keep it censorship-resistant and decentralized?
अगर हम उपयोग करते हैं Bitcoin, we should not specify a fixed place in the block where the commitment to transfer ownership must occur (e.g. in the first transaction) because, just like with the editor of the New York Times, the miner could mess with it. A better approach is to place the commitment in a predefined Bitcoin transaction, more specifically in a transaction that originates from an unspent transaction output (UTXO) to which the ownership of the asset to be issued is linked. The link between an asset and a bitcoin UTXO can occur either in the contract that issues the asset or in a subsequent transfer of ownership, each time making the target UTXO the controller of the transferred asset. In this way, we have clearly defined where the obligation to transfer ownership should be (i.e in the Bitcoin transaction originating from a particular UTXO). Anyone running a Bitcoin node can independently verify the commitments and neither the miners nor any other entity are able to censor or interfere with the asset transfer in any way.
Since on the Bitcoin blockchain we only publish a commitment of an ownership transfer, not the content of the transfer itself, the seller needs a dedicated communication channel to provide the buyer with all the proofs that the ownership transfer is valid. This could be done in a number of ways, potentially even by printing out the proofs and shipping them with a carrier pigeon, which, while a bit impractical, would still do the job. But the best option to avoid the censorship and privacy violations is establish a direct peer-to-peer encrypted communication, which compared to the pigeons also has the advantage of being easy to integrate with a software to verify the proofs received from the counterparty.
This model just described for client-side validated contracts and ownership transfers is exactly what has been implemented with the RGB protocol. With RGB, it is possible to create a contract that defines rights, assigns them to one or more existing bitcoin UTXO and specifies how their ownership can be transferred. The contract can be created starting from a template, called a "schema," in which the creator of the contract only adjusts the parameters and ownership rights, as is done with traditional legal contracts. Currently, there are two types of schemas in RGB: one for issuing fungible tokens (आरजीबी20) और संग्रहणता जारी करने के लिए दूसरा (आरजीबी21), लेकिन भविष्य में, प्रोटोकॉल स्तर पर परिवर्तनों की आवश्यकता के बिना किसी भी व्यक्ति द्वारा अनुमति रहित फैशन में अधिक स्कीमा विकसित किए जा सकते हैं।
To use a more practical example, an issuer of fungible assets (e.g. company shares, stablecoins, etc.) can use the RGB20 schema template and create a contract defining how many tokens it will issue, the name of the asset and some additional metadata associated with it. It can then define which bitcoin UTXO has the right to transfer ownership of the created tokens and assign other rights to other UTXOs, such as the right to make a secondary issuance or to renominate the asset. Each client receiving tokens created by this contract will be able to verify the content of the Genesis contract and validate that any transfer of ownership in the history of the token received has complied with the rules set out therein.
So what can we do with RGB in practice today? First and foremost, it enables the issuance and the transfer of tokenized assets with better scalability and privacy compared to any existing alternative. On the privacy side, RGB benefits from the fact that all transfer-related data is kept client-side, so a blockchain observer cannot extract any information about the user's financial activities (it is not even possible to distinguish a bitcoin transaction containing an RGB commitment from a regular one), moreover, the receiver shares with the sender only blinded UTXO (i. e. the hash of the concatenation between the UTXO in which she wish to receive the assets and a random number) instead of the UTXO itself, so it is not possible for the payer to monitor future activities of the receiver. To further increase the privacy of users, RGB also adopts the bulletproof cryptographic mechanism to hide the amounts in the history of asset transfers, so that even future owners of assets have an obfuscated view of the financial behavior of previous holders.
In terms of scalability, RGB offers some advantages as well. First of all, most of the data is kept off-chain, as the blockchain is only used as a commitment layer, reducing the fees that need to be paid and meaning that each client only validates the transfers it is interested in instead of all the activity of a global network. Since an RGB transfer still requires a Bitcoin transaction, the fee saving may seem minimal, but when you start introducing transaction batching they can quickly become massive. Indeed, it is possible to transfer all the tokens (or, more generally, "rights") associated with a UTXO towards an arbitrary amount of recipients with a single commitment in a single bitcoin transaction. Let's assume you are a service provider making payouts to several users at once. With RGB, you can commit in a single Bitcoin transaction thousands of transfers to thousands of users requesting different types of assets, making the marginal cost of each single payout absolutely negligible.
Another fee-saving mechanism for issuers of low value assets is that in RGB the issuance of an asset does not require paying fees. This happens because the creation of an issuance contract does not need to be committed on the blockchain. A contract simply defines to which already existing UTXO the newly issued assets will be allocated to. So if you are an artist interested in creating collectible tokens, you can issue as many as you want for free and then only pay the bitcoin transaction fee when a buyer shows up and requests the token to be assigned to their UTXO.
Furthermore, because RGB is built on top of bitcoin transactions, it is also compatible with the Lightning Network. While it is not yet implemented at the time of writing, it will be possible to create asset-specific Lightning channels and route payments through them, similar to how it works with normal Lightning transactions.
निष्कर्ष
आरजीबी एक क्रांतिकारी नवाचार है जो पूरी तरह से नए प्रतिमान का उपयोग करके नए उपयोग के मामलों को खोलता है, लेकिन इसका उपयोग करने के लिए कौन से टूल्स उपलब्ध हैं? यदि आप तकनीक के मूल के साथ ही प्रयोग करना चाहते हैं, तो आपको सीधे प्रयोग करना चाहिए आरजीबी नोड. यदि आप प्रोटोकॉल की जटिलता में गहराई तक जाने के बिना RGB के शीर्ष पर एप्लिकेशन बनाना चाहते हैं, तो आप इसका उपयोग कर सकते हैं आरजीबी-लिब लाइब्रेरी, जो डेवलपर्स के लिए एक सरल इंटरफ़ेस प्रदान करता है। यदि आप केवल संपत्ति जारी करने और स्थानांतरित करने का प्रयास करना चाहते हैं, तो आप इसके साथ खेल सकते हैं Android के लिए आइरिस वॉलेट, जिसका कोड भी ओपन सोर्स ऑन है GitHub. यदि आप आरजीबी के बारे में अधिक जानना चाहते हैं तो आप देख सकते हैं संसाधनों की यह सूची.
This is a guest post by Federico Tenga. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin पत्रिका।
मूल स्रोत: Bitcoin पत्रिका