Confidential Assets — sharing some thoughts
We talked about Confidential Assets in our latest Development Status Update, and it is now a good time to explain a bit more what confidential assets are, review the history and discuss how Confidential Assets will be implemented and used on Beam.
Native Coins and Additional Assets — a Brief History
As the reader undoubtedly knows, Bitcoin was released in 2009 with the goal of serving as a digital currency. Other projects soon followed suit, with Namecoin and Litecoin released in 2011, Peercoin in 2012 and so on.
With the progress of Bitcoin development and the realization of the huge potential of blockchain technology, developers started looking into ways to extend it with multiple types of tokens that can represent various kinds of assets.
The first attempts to do so were related to Colored coins. The basic idea behind Colored Coins is to mark (color) bitcoin outputs in a certain way so that they represent something different — a stock, a unit of another currency etc. In 2012, Meni Rosenfeld released a whitepaper outlining the benefits and disadvantages of Colored Coins approach.
In 2014, Chromaway introduced EPOBC (Enhanced Padded Order-Based Coloring) — the first Colored Coins implementation. Colu was also among the pioneers in the space with their Colored-Coins project released in 2015.
The concept of colored coins did not get too much adoption and was eventually overshadowed by Ethereum’s ERC-20 token standard that allows easy issuance of new assets. The ICO craze of 2017 was largely made possible by this easy-to-use standard, allowing anyone with basic technical knowledge to create and sell new tokens.
Stellar, Eos, Tezos (June 2018), QTUM and Cardano are some of the new platforms that emerged to compete with Ethereum for dominance in distributed computing and in issuance of new tokens.
While those platforms enabled issuance of thousands of different kinds of tokens (some useful, some not so much), at the moment they all lack privacy — the balances and transactions in various kinds of assets can be easily observed by anyone who cares to look.
With the growing need for confidentiality, several notable projects enabling confidential asset trading were recently launched, among them Liquid Securities by Blockstream, powered by Liquid federated sidechain, and Aztec Protocol that enables transactional privacy on Ethereum.
We are now laying the groundwork to extend Beam and allow trading of additional kinds of assets on our blockchain with the same scalability and confidentiality of Mimblewimble protocol.
Confidential Assets on Beam — how it works
In Mimblewimble, each UTXO is represented using a cryptographic commitment scheme, specifically a Pedersen Commitment, which uses Elliptic Curve cryptography to replace the UTXO value with an opaque commitment to that value. This ensures that the value of the UTXO is only known to its owner while at the same time it can not be changed arbitrarily. Pedersen commitment in general looks like this:
C = v* G + r * H
Where G and H are two generators on the same elliptic curve and v and r two scalars — one representing the UTXO value and the other one the blinding factor.
The blinding factor has two purposes. It obscures the value of the UTXO while at the same time serves as a secret key which is used to prove the ownership of that UTXO. It is important that only “Nothing Up My Sleeve” elliptic curve points are used, meaning that the ratio between the points is not known (otherwise the commitment scheme can be easily broken).
In order to create new kinds of assets on the same blockchain, we can add more generator points, thus allowing us to encode additional types of value in the following form:
Here, each G1…Gn are generator points and each one of the commitments C1…Cn represents a different asset. This allows the creation of an arbitrary number of new assets types on the same blockchain, each tagged with a corresponding generator point, thus allowing to distinguish between them during the transaction validation process.
To create a custom asset type, the issuer needs to generate a public/private key pair. The public key serves as an Asset Tag, and the generator point used for this asset type is derived from the Asset Tag via hashing.
In addition, the issuer will be able to specify additional metadata parameters, including the name of the asset, its total supply and emission schedule, certificate of the issuer, address of the Controller Server (more on that later) and more.
The issuer controls the emission and burning of the asset. The total amount of the emission of each asset is known and visible on the blockchain.
It is important to note that in this scheme, the type of the assets traded is visible. Of course, in order to ensure maximum confidentiality, the type of the asset can also be blinded so that a transaction reveals neither the value nor the type of the asset traded. This can indeed be achieved using Asset Surjection Proof proposed by Andrew Poelstra, which has a modest size compared to the bulletproof for a reasonably-small set of asset types. This does however assumes the asset set is known and thus limits the number of different Token types that can be issued without a fork.
While the method presented above allows creating new tokens on top of the Beam blockchain, it does not stop there. Using Scriptless Scripts, it is possible to enforce additional rules of different types of tokens which in turn allows creation of Smart Assets and enables a wide variety of applications.
In more involved cases, Scripless Scripts may not be enough to enable the required functionality. Therefore, we are adding programmable Controller Servers which will enforce custom rules for each specific asset type. Once the transaction is created by the parties, it will be first sent to the Controller Server with all additional metadata (e.g. documentation, KYC certificates, etc.) that is required for this particular asset. The controllers will serve as kind of oracles connected to specific assets via a certificate system as specified in asset metadata. If the issuer chooses so, the transaction will only be considered valid if it is co-signed by the Controller Server, thus enabling complex business logic and rule validation for every asset.
Use Cases
Confidential Assets can represent virtually any kind of digital value. Issuance of STO shares is one example, stable coins is another one, local currencies, utility tokens and more. Naturally, each use case might require a different set of rules and regulations which can be implemented either through Scriptless Scripts or using a Controller Server.
For example, in the case of STO issuance, the issuer’s Controller may be reviewing each transaction to ensure that both the sender and the receiver are whitelisted and allowed to participate in the trade, and that the total number of shareholders does not grow above or below a certain predefined number as the result of this transaction. The Controller will approve the transaction only if the conditions are satisfied.
In other cases, the issuer may just want to receive information about every transaction and the amount traded and automatically validate it.
We are working with different projects in the industry to find the best use cases for the technology and to create practical applications for them. Eventually, it will be possible to issue any kinds of tokens on Beam to hold and exchange value in full confidentiality, and with great scalability of Mimblewimble.
It should be noted that since Confidential Assets use the same transaction scheme as the Beam coin itself, it will be very easy for exchanges to enable trading in those tokens.
Timelines
We are still in the initial stages of the practical implementation of Confidential Assets issuance, so it will take some time. We do not have a specific release date to share yet, so stay tuned.
Come discover Beam and join our community!
Download Beam Android Wallet on Google Play
Download Beam iOS Wallet on App Store
Learn more about Beam on our website and blog
Telegram: t.me/BeamPrivacy
QQ Beam 中国官方社区: https://jq.qq.com/?_wv=1027&k=5Mbs8N4
Reddit: reddit.com/r/beamprivacy/
Twitter: twitter.com/beamprivacy
