[0:00]Hello, everybody. Uh, my name is Maxim Orlovsky and today I would like to talk about the RGB protocol, which is going into the production release this summer, during these days. And I would like to explain, to give a brief introduction, what the protocol actually is, and why it is important for the Bitcoin and Lightning world. As well as describe the recent advancements we brought to the protocol over the last year and explain how people can start using RGB after waiting for its release for quite a few years. So, let's start with what RGB is. RGB is the first client-side validated, uh, technology. And client-side validation actually is about reviving the P2P nature of the regional ideas coming from Satoshi and before him.
[1:13]Such that finally we can reduce the role of centralized players or intermediaries, including miners, and finally get people transacting directly peer-to-peer without the need to send all the transaction details to the miner, without the need to download them from the miner and being able to just send funds without any additional party between them. It is not just a peer-to-peer transactions, it is smart contracts. So, we are talking about universal programmability, something that frequently called Turing completeness, and this programmability is being unlocked for Bitcoin without any soft-forks required. And that's also where the power of client-side validation shines. It is also a very private technology. Its privacy comes from two main things. First, because it is peer-to-peer, you don't have a global ledger. There is no centralized informational centralization anymore, because in fact, blockchains, while they are computationally decentralized, you have a network, it is still informationally centralized thing. Everything is kept in a single ledger. Yes, all the members of peer-to-peer network download all of this ledger, but all the information resides in this single place, in this distributed ledger. And that's why anybody, any party accessing this ledger, can actually track the whole history of the transaction graph and do chain analysis and many, many other things which ultimately breaks privacy. And before the client-side validation, every innovation coming to bring privacy into blockchain had to face the same restriction: there is still a global ledger. Even with Monero, even with Zcash, there is still a transaction graph. What you hide is the details of the transactions. Maybe you can cut through some of the parts of the transaction graph with like Mimblewimble or something of that sort, but still you have a single centralized ledger. And the client-side validation is the first technology that brings this to an end, because you don't have a global ledger anymore. When you send a transaction from a peer-to-peer, nobody else in the world knows about that. You don't publish this information into any ledger, global or partial, and that's where the privacy actually sticks in because it's a bearer rights smart contracts. It's like with a paper world where two parties doing a contract had just two copies of this contract kept at their homes at the safe. They were no centralized registry where they need to bring that to. And that's actually the real decentralized privacy and the power of decentralized technologies which will shine. And the second thing is that client-side validation also comes with a ZK compression. And this ZK compression allows you to hide even this private part of the history such that even though you have the history of your assets from the original issuance of these assets, or genesis of them, you can compress that such that the details, the overall history graph of your on your client side part, is also hidden. And you just can prove that you indeed received this assets without any double spending during the whole route, but you can't explore into the details of the transaction graph. And because of this combination of factors, like compression, peer-to-peer nature, absence of centralized ledger, finally, the main scaling problem of blockchain is solved, because you get rid of blockchain. And that's probably the only proper way of solving the blockchain scalability issue. And at the same time, this technology leverages the existing decentralized technologies like Lightning and Ark, and it's also, for instance, Ark compatible. It is compatible with anything that can be built with a Bitcoin transactions and it runs without putting any information into Bitcoin blockchain information which can be detected or parsed by an independent party not knowing about the contracts. So that's why RGB is a huge thing, and that's also why RGB took so long to develop. And unlike the blockchain, where you have a distributed database, because any blockchain is a distributed database with a number of nodes synchronizing the history log of the transactions. And in blockchain, all the users has to agree on upon this history of transactions, so basically, everybody needs to download and verify everything for everybody else and everything that happened in the world, that is intrinsically not scalable. And for N peers, you need the same amount of effort as the N to check, verify and store. With the client-side validation, this constraint is already removed. They keep only their part of the state, and uh for N peers, you need much less storage requirement, like a logarithm of the number of peers, and even smaller validation requirements, like a second power of the logarithm. And yes, this all operates on top of Bitcoin, as I already said, and also on top of technologies which can run on Bitcoin, including but not limiting Lightning, PayJoin, CoinJoin, Ark or whatever will be, multi-sig, mu-sig, Schnorr signatures or whatever will be invented and brought to Bitcoin in the future. It also extends the capabilities of Bitcoin itself without any soft-fork. Bringing programmability, much better privacy, more assets and finance into Bitcoin blockchain without putting any data and not occupying any space on Bitcoin blockchain. And yes, as I was starting to saying a few slides before, that's why it took quite a long story to build that technology. This technology stands quite apart from the way you usually build a blockchain-based application, and uh in many ways it's a new word in the computer science of distributed systems. So, we passed from to many iterations. We have started in 2016, in 2019 I joined the project and we got three iterations which tried to bring much more powerful and computational powerful power into RGB and client-side validation.
[8:17]And finally here we are here. Uh on the very high level, I can say that we've gone from the idea of just building a better colored coins on top of Bitcoin. To the idea of full-fledged smart contracts compatible, operating on top of Lightning with a full support for ZK-STARKs compression and privacy related technologies. Over these years, there was a lot of companies and individual contributors who were working on RGB, bringing ideas and contributing ideas to RGB. It was more than 100 individual persons and more than 20 companies from pretty much all the world, and that's like, summarizing this, I can say that it was a real global community effort. And the only things which can compare to that, it was probably the Bitcoin itself and Lightning Network. And these days we see that in in Ark to a certain extent, but uh basically these are the only examples of technologies built in such a way. Nothing in the crypto like other blockchains, forked Bitcoin versions or any decentralized blockchains which were created can't compare to this scale of effort. Uh so, what we are going live with is RGB code name V0.12 version, so it's a 12th iteration through all these six years of development. And we believe this is a final iteration because in this iteration we have all the functionality we were striving from the initial version, including the full programmability, necessary level of privacy. And finally, only with the 12 version we've have got ZK-STARK compatibility and ability to compress the history and hide the history on the client side as well. And this 0.12 version which will go into the production with the mainnet assets in in just few weeks is also brings a lot of improvements in terms of performance. It also simplifies many things which have grown up through all these years of development and were hard to understand by developers and people integrating RGB. Now they are much more compactified and simplified and made in a more straightforward way. And as I already said, the probably the most interesting and intriguing part of the 0.12 version is its ZK-STARK compatibility and readiness. Uh so, we've got quite a lot of things in this version, so I will briefly cover the main advantages which happens. First of all, I would like to say that this version, for the first time, we have achieved much simplification without sacrificing any of functionality. Because you know that when you develop for many years a technology, a code base is growing up, you can add more and more features. And this time we did a complete revision such that many redundant features were removed, and many things which can be done in more optimal way were simplified because we received a feedback from people who were trying to use RGB and integrate RGB into their products. So, there was a number of things we made much better at the consensus level, for instance, uh we got rid of some specifics of dichotomy between different types of seals based on Taproot or more legacy-based schema of Op_Return, which is needed for hardware wallets and Lightning Network. We got rid of some old ZK encoding schemes because now we have ZK-STARKs. We don't need Pederson commitments or bulletproofs which is really hard to bring into production. Uh there is uh much less need to write a complex schema for issuing an asset. You just do it in a very simple way. And there is no such thing as an ordering of operation which actually had a very ambiguous because you have now two transaction graphs with Bitcoin transaction graphs and RGB transaction graphs. So, this part is removed and you don't need to try to reorder RGB operations according to the on-chain operation history. We also simplified a standard library which will which should help integration of RGB into wallets and exchanges. And uh basically all this simplification resulted in this thing. So, if you took into the if you look into the number of code lines reported by a service called Codecov, which counts the test coverage of the source code, it also computes the number of lines of the source code. And you will see that basing on this data, there was nearly four times less number of line codes in the new 0.12 version of RGB. So, this can be compared to something of this evolution of Falcon engines from the of Raptor engines from the SpaceX rockets. You see that with the time you can finally get the simplicity which is really important and required for things such as auditability, reduction of attack surface or simplicity of the integration and also the code maintenance over the years. So, four-time reduction of the code base is really significant thing. Uh the same pretty much the same effort was put into the standard library, and here, well, the standard library is not that critical as a consensus layer, I will explain what's the difference because if something goes wrong in the consensus layer, all the assets, all the contracts issued so far will be broken. And if you try to fix it, basically every asset issue, you need to reissue the asset, there should be a migration procedure, so it's a really big thing. Uh on the other hand, standard library makes it easier to use RGB from the software integration perspective, but if something wrong with that, if there is a bug in the standard library, the only thing you need to do is to upgrade your wallets. All existing assets, all existing contracts are safe and nothing has to be changed there. So, it's it's a big difference between these two layers. And in standard library we were able to also reduce the number of code lines nearly two-fold. Which is also significant achievement. And if you think about like, it's just 2,700 lines of code for the consensus and 300 3,200 lines of code for the standard library, it's a very, very tiny and compact thing. Even comparing to Bitcoin core or any other type of that decentralized system. So, it's easier to read, understand and audit, and one of the things we will do after the release, we will do even a book like was done days ago for PGP, when we will publish all the source code as a small booklet for RGB, such that anybody can read it, audit it, and understand it.
[17:21]Other than that, we are also bringing more liquidity, launching the color shift, and color shift is ERC20 to RGB bridge, and this color shift will be issuing the LN-USDT, the USDT bridged to the RGB, able to operate on top of the Lightning Network.
[17:44]And this LN-USDT can be used with a Ray Wallet, a wallet which we also have presented last year in Lugano Plan B. We have upgraded the Ray Wallet to the 0.12 version. It's very easy to use mobile wallet where you can do instant payments from peer-to-peer, just by putting two phones together or scanning a QR code, and this wallet comes from the day one with a Lightning USDT. Uh there are other wallets, as I said, there are a few of them and one of them is Bitlight wallet, which is a web browser based Chrome extension wallet, like MetaMask. There are other wallets being developed by other companies, in total there will this summer when there are launching about five different wallet solutions, Bit for instance, a Bitcoin Tribe from BitHive, uh BitMask from Diba, uh Iris from Bitfinex, uh and so on. There is also another wallet which we are doing for all these years, and which finally gets support for RGB, being fully rewritten from the ground up, MyCitadel. And the difference of MyCitadel from Ray Wallet is that while Ray Wallet for a personal use, using mobile phone paying for your coffee or paying for your lunch or sending funds to a friend, MyCitadel is a professional wallet, which is purely focused on multi-sig environments created for companies, power users, holding funds for a long period of times or asset issuers. Because it helps you to manage the secondary issue of RGB assets, it helps you to manage the corporate accounting with the different assets including Bitcoin, USDT, having a multi-sig between your directors such that when one director creates a transaction, others instantly see it in their wallet and able to add signatures to it, working with a like, you will see there, like, for instance, here in the bottom of the screen the wallet organizer where you can have a multiple companies, and each of these companies may have a multiple wallets, and each of these wallets may have a multiple signers and their own independent history of operations. That's it. That's the overview how we plan to bring RGB to life this summer, and we hope that uh you will all be parties who will be able to use this technology in a very short period of time. And also those who were looking for RGB release for all these years, to issue their assets or starting integrating, you are welcome to join the club. Thank you very much.
[20:47]Thank you very much. Yes. Have a good day.
