 Today I'm going to talk a little bit about Hyperledger Iroha, what it is, how it enables CBDC and fintech use cases and also future plans for DeFi. So just a quick introduction. My name is Makoto Takimia, I'm a naturalized Japanese citizen. I'm co-founder and CEO of Sorry Mitsu, so we're a fintech company specializing in blockchain technology. I'm a computer scientist by background and I got a PhD in interdisciplinary information studies from the University of Tokyo. And my company is Sorry Mitsu, we're one of the contributors to Iroha since 2016. So it's been quite a while. And we're a pretty global and distributed company, but we specialize only on blockchain not on other things. Besides Iroha we do some work also with Ursa as well and in the Polkadot ecosystem we do quite a lot and we do quite a lot of different things. So today I'm going to talk a little bit about Iroha and use cases especially with the National Bank of Cambodia. But we also have other projects we're working on, we're working on a cross-border CSD ITGS linkage prototype. Actually Fujitsu is also here at the event is one of the participants in this and besides this type of enterprise work we do a lot of work in the public cryptocurrency space. So contributing to a cryptocurrency project called Sora and Pocoswap that's in the Polkadot ecosystem. So if you're interested in this feel free to ask me later. Let's talk a little bit about what is Hyperledger Iroha because you may not know. Iroha is a platform that aims to have Byzantine fault tolerance and make it very easy to do common use cases by having robust libraries and core commands that can make it easy to do simple things. In Iroha 1 that was started in 2016 it was written in C++ and rather than having a Turing complete smart contract functionality it just had a library predefined commands that could be used for many financial use cases. So for example CBDC that has its pros and cons of course by not having smart contracts per say Iroha 1 reduce the attack space that you could do. So there's just predefined commands so that's all you can manage. So if you test that you can prove that it's safe. But it is kind of limiting. So in Iroha 2 we expand this to have a Turing complete smart contract functionality using WASM or WebAssembly and Iroha 2 is written in Rust rather than in C++ but it does continue the Iroha version 1 kind of concept or philosophy of having a robust internal library of predefined functions that can be used for simple use cases like minting and transferring assets for instance. So it's great for a payments use case. Also Iroha 2 is really exciting features like event driven triggers that can execute certain code on an event. So I'm going to talk a little bit about this today. But first I'm going to talk about a few of the use cases that we worked on with Iroha version 1. So the first one I'll talk about is a digital identity use case and I'm not going to go into the details but this was actually published in a paper in IEEE called SORA identity and this was I think in 2017 we published this. But for digital identity we experimented with use cases using a decentralized identifiers working with Bank Central Asia in Indonesia to build a prototype identity solution and this was done several years ago but the key point is that we use a blockchain platform that is running Iroha that each of the group companies would run a node in the prototype and then the verifiable claims about a decentralized identifier were written into the blockchain and then all the nodes could get access to this information in a way that stored the provenance of how the data was introduced into the system. So the goal of this was to create kind of standardized group identity because like many large financial groups there is no standard identity for all clients across the group and we built this prototype and I don't have a link to the paper on the slides but we wrote a paper called SORA identity so if you're interested in the digital identity and DID concept you can write this but in Iroha 1 and Iroha 2 we allow metadata to be associated with an account so it's an easy way to add claims about an account directly into the blockchain. Another use case that we explored in Iroha version 1 was weather derivatives for insurance contracts so the use case is like if you have a big concert outside and if it rains it gets canceled and so you have a big financial loss so what you can do is you can hedge against this loss by buying from some point Japan you can buy this weather derivative contract where if it rains you get some amount of money and if it doesn't rain you don't get anything. And so we programmed this in the blockchain in a way similar to Iroha version 2 triggers but Iroha version 1 you know doesn't have this functionality but we added it for this proof of concept and really what it has is we wrote we used an oracle to write weather data about a given location into the blockchain at some fixed time interval and then if there was a rain then some code would be executed automatically on chain that transferred money from an account to the customer so it's an automatic payout. So this was just a way to simplify or optimize the workflow for an insurance contract like this. So that was something that we did back in 2016 so it was quite a while ago 2016-2017 and that used Iroha version 1 it's one of the first use cases of Iroha version 1 in fact but this was also an inspiration for the trigger design in Iroha version 2 which I'll talk about later. Another cool example we did in 2016 was on Moica Moica is an event digital currency that we did in Japan in Izuwakamatsu which is in Fukushima prefecture and what it was it was a cryptocurrency like a cryptocurrency but it was only for a closed event and it only lasted one day and if you meet somebody you can shake your phone and they shake their phone and then there's you know some app that well you get a QR code that then you scan so you have to be in front of the person and it only shows for a couple seconds so you have to do it really fast but if you do that it mints new currency so it's a way to mint a currency through social interaction because if you have like an event you want people to communicate and meet each other and so it was a way to kind of get people to talk to each other especially this was like an anime event in Japan so people are not so not so social usually so so it's actually really successful and people had a lot of fun and then there's stores like a selling popcorn or coffee that you could exchange this cryptocurrency for. Also you could earn this cryptocurrency by picking up trash and cleaning up the event so people did these things to get this token so it was a lot of fun and this was a great use case for Iroha version 1 showing that how simple it was to just create a currency and then exchange it you'd transfer it to other users and this was expanded from this event to be used in the campus of Izu Wakamatsu, University of Izu in Izu Wakamatsu so this is the BIACO app and it launched in production in 2020 and it's been running ever since in the cafeteria and the campus store so it's a prepaid type of system so users would go to the campus store and pay some money and then they get you know these tokens that then they can use at the campus store and the cafeteria to buy food and the motivation for doing this is if you pay with the system you get a slight discount on food that you buy. So this was a replacement for physical like magnetic stripe cards that they used to have so before this system users would have to go get this card and charge that up and if they lose the card they lose it but here they just have it on their phone and it's really simple and fast and this has been running since 2020 with Idoha version 1. And so that's in like the local context but then another great use case I'm going to go into more detail with is BAKON which is a central bank digital currency so the CBDC of course is I mean it's nothing that new because central banks already have digital currencies but the point of this is it allows access to retail customers and also the payment system is not a messaging system like traditional payment systems but it is actually like a payment system that transfers value rather than just a message about value changes. So we've been working on this in Cambodia and it launched in 2019 with real money as a private and then 2020 is a production system so since the system is running today I think it's best to show it just to kind of show that this can actually work in production so yeah we can see my phone here I can be cool like Steve Jobs. So this is this is the wallet and there's two currencies in the wallet there's the US dollar and Kamai Rial because Cambodia is heavily dollarized countries so many transactions actually vast majority of transactions are in US dollar and as a customer even though I'm transacting and I'll talk about the architecture later but the central bank is running the blockchain system even though I'm transacting on the central banks ledger I'm intermediated by a commercial bank so you can see FTP logo up there that's foreign trade bank of Cambodia so it's really a simple app there's just four features send receive scanning QR code and deposit so to send money I can choose one of the users and I can send some small amount of money like one Kamai Rial it's one four thousandth of a dollar and let's hit confirm and then yeah it's sent so yeah it's already done too so that's it so that actually got transaction finality on Iterha version 1 and it yeah it sent it from my account to this user's account at another bank so I'll talk about the architecture in just a moment but it's you know it's pretty fast you can use it to actually buy things in stores which is really cool and recently they they upgraded the system to interlink all the other payment systems in Cambodia through cage QR so it's a standardized QR code and back on kind of acts like the glue between different systems and I will talk about the architecture okay so let's get out of here so I just showed a demo the app so you know how it works there's also some desktop apps so one of the key points of Iterhas we put a lot of emphasis on actually building a self-custodial library so what that means is that if you have like a web app or a mobile app you want to generate the key and do all the transaction signing on the client side you don't want to send any private keys to servers like that's you know that would be bad for many reasons so on the app I just showed the transaction signed on my device and then just the sign transaction is sent to the core system and we have the same type of thing for desktop apps so there are JavaScript libraries libraries for Android libraries for iOS and then it will have version 2 has libraries for Rust that are able to sign generate keys and sign transactions locally so let's talk a little bit about the architecture of a back home because I do think it's potentially interesting so back home is a two-tier architecture so what that means is that even though all the user accounts are on a shared ledger the end users intermediated by the commercial banks and this is done for many reasons one is privacy because the central bank doesn't want to know the personally identifiable information of a user and another is really just you know from operational aspects because the central bank is not providing customer support so so they need to have someone like like a commercial bank or payment service provider that provides the support here's another view of the same architecture so you have at the core of hyper ledger it will hot that is running as the kind of the ground truth of the world state so who has what balance at you know at a given time and every bank sets up a payment gateway that then users like me my device connects to the payment gateway and not to the the core system directly so if I send a transaction it goes to the gateway the gateway then transmits it to eat or ha to one of the peers and then I think it's finality and then that comes back to my device and the commercial bank also as part of the payment gateway stores my personal information like for you know KYC reasons it also integrates with the core banking system so you can do things like like you can withdraw from the back long system or charge up your balance from a traditional bank account because it interoperates with the traditional accounts back home is different from an e-money system because you know most e-money systems at least in Asia most of the time they work like this so you you'd have like a if you had like a prepaid system like in Japan with a suika right I think in London they have oyster here in Ireland they have another analog of the same type of system but you pre pay pre-charge it with some cash usually and then you get some balance from the payment processor on your card but then when you actually go to store and spend the money you're not actually making the payment you're just sending a payment instruction that then maybe two to four weeks later the store actually gets the money in their bank account so there's like a time lag and that's not always convenient for stores because they have to manage cash flow and treasury but with CBDC system like back home if you you're basically digitizing the cash so you can go to a bank charge up your back home balance and you get the back home money and then you make a payment to a store they get the money instantly and they can reuse it or cash it out or do anything they want with it with just a few seconds right so that's that's really exciting and I do think this is the future and it's a way to easily make you know to facilitate payments and make payment infrastructure more convenient in many countries some contextual reasons for those who are interested as to why back home was created so Cambodia is a large unbanked population it's only around 22% of Cambodians have a bank account like a proper bank account but they have a large money-sending markets most of its domestic because people will go out of the country side and go work in the capital and then send money back home so it's it's a payment within the same country but traditionally you know there's no easy way to make this payment so they would go to one of the payment operators and then they would hand them some cash and then you know get like a code that then you message to your friend the friend takes the code and then goes pick up it picks up the cash at one of the stores so it's it's kind of a cumbersome system that had a high transaction fee and so a project like back home is is made to reduce the the fees and costs associated with this and also to enable new use cases in e-commerce because if people don't have credit cards or way to pay digitally it limits the types of transactions you can do we used you offer this mainly I would say because it creates a trust minimize system so it's very highly robust and from operational standpoint it's it's kind of nice to use a blockchain because if one of the core ledger nodes goes down like on a weekend let's say you don't really have to go and set it up again instantly because you've enough redundancy built into the system that it just keeps running and you can go and set it up you know the next working day and this makes operation much easier and from a central bank standpoint you really appreciate the the robustness of the decentralized consensus because you have many different nodes that have to sign off on the data it makes it very hard to hack a system like this because all the transactions are digitally signed so you can't fake you know any kind of transactions just not possible so it does make the system quite quite robust it also kind of distributes the responsibility because like I have my key on my phone but no one else has my key so even the central bank I mean they can they can do other things for legal reasons but they can't they can't sign a transaction on my behalf so it does give some kind of you know mathematically provable property ownership that being said you know it is it is a central bank system so at the end of the day if there is like a legal sanction against somebody they they do have the ability to you know to take action via the court system in the country so that's that's more done on the payment gateway side than on the core ledger though and I mean I'm a libertarian myself so I kind of wish that everyone would just use public blockchains but unfortunately the world we live in you know there are certain rules that that have to be implemented and so we try to work with central bank to design this in a way that doesn't violate anyone's privacy or property rights because you do have this clear separation of the responsibilities of the of the banks which manage their customers and the central bank which is managing just the balance updating infrastructure so yeah the system has been in many articles like I said it pilot launched in 2019 and officially launched in 2020 and it's been yeah just running for several years now we won several awards actually on this so from the journal central banking from the Japan Financial Innovation Award and the Nikkei Asia Award for the system so it's gotten pretty good response this data from last last two years so from the launch and then also in 2021 and in 2021 there are two almost three billion dollars in transaction volume and eight million transactions that were processed in 2021 and this year is much much higher so maybe 10 times this I don't know the exact number so but in between 2020 and 2021 these bars are not to scale but yeah transaction volume in KHR went up 62 times and USD went up 95 times so it's really quite quite exciting and this is getting even back on is getting even more used because the integration to the standardized QR system that launched in July called KHQR and this allows any of the banking apps to scan the standard QR code and behind the scenes it will do the routing and a lot of the interbank payments are going through back home because back home doesn't have any you know the fees are cheaper compared to other systems so if I have like a ABA bank app I can scan the QR code for somebody at let's say VATNAC bank and then behind the scenes it can convert to back home send it to VATNAC and then convert to their you know to their balance because a back home is a central bank money so it can be used in settlement with with no counterparty risk because well people trust the central bank for a system like this there are no negative effects on monetary policy I would say so what we've observed over the past two years is that so I'll just step back and say that a lot of especially European central banks are very scared about competition between CBDC and banks commercial banks and that's because there's a lot of talk about opening up direct accounts on a central bank sludger now that would be competition but in Cambodia it's actually even though I'm opening an account on the central bank sludger I'm intermediated by one of the commercial banks or the PSP right so so really because these are non-interest bearing accounts it it doesn't really give me a big motivation to store a lot of money in this account so it's really more of like just a replacement for pocket change that you would use did a physical cash for anyway so it's for daily payments it's not really for savings I would say people have lots of money they use traditional bank account especially in Cambodia where you can get 5% interest paid on your savings so people people don't really store large amounts of money in back home is what we've observed over the past two years and it's more for you know small transactions and also as a payment rails for wholesale payments between banks so I would say there's no negative effects and there's lots of positive effects too because it acts like the glue to integrate all these different you know payment apps across all the different banks and that's really exciting because users shouldn't have to think about you know what app is the store using you know just signing an app is makes it very easy and what's really exciting is that there's integration work being done with a prompt pay in Thailand so people will be able to then go to Thailand with back home app and make a payment and then it will convert behind the scenes to Thai bot and send it across the prompt pay network so that and because prompt pay is also used in Laos you can kind of use the same app in three countries which is really cool there's also some cool use cases for cross-border use so back home is is used for cross-border payments from Malaysia to Cambodia via Maybank so Maybank has branch offices in both countries so in Kuala Lumpur you can go to Maybank office and you can convert dollar or convert I guess ring it to dollars in back home system then you can send it to somebody in Cambodia so this is really great because you don't just send it to somebody's you know bank account but you can also make a payments directly to any back home user and in theory because KHQR is standardized now you can make a payment to any anyone in the payments network in Cambodia from Malaysia like directly so this has use cases for empowering especially women who go out of Cambodia and go to work in Malaysia like in a hospitality use you know field is very common so instead of sending money to relative having to trust them and then having the money paid for like schools or hospitals or things they could just pay directly to the school or for whatever use case so it gives more empowerment over people's finances and their assets Japanese government is also kind enough to sponsor our research in the law PDR as well and we just finished the first stage of this work and so that's quite exciting and we've been doing CBDC physical feasibility study as well in in Oshinae region so I guess PG Tonga and out to Solomon Islands Vietnam and Philippines so lots of work this is mainly just market research to kind of kind of study to see how would a CBDC fit into the payments infrastructure in these countries as a initial work and then we can make like some specific proposal to the to the central banks in these countries so that's some of the use cases that I've had the pleasure to work on over the last few years and with the remaining time I kind of want to go into some of the specifics of you know how to and why it's kind of cool and to because this is listed in the program is a technical talk I want to go into some details so so you know how version 2 has a very simple object model that same as version 1 really you have the concept of a domain an account and an asset and as you can see in this in this diagram here a domain acts like a box that you can put accounts in you can put assets in and the assets can be owned by accounts so it's a it it's a very simple object model but these are basic primitives that that are important to think about because this helps to standardize the assets in a ledger so if you don't have this then you end up with something like Ethereum where for instance even if you have an ERC 20 token the specific implementation of the contract can be different so like some ERC 20 contracts revert to failed transactions some in that events or some return false and don't admit events so you have to handle all these special cases in Ethereum because there's no asset standardization even though there's like a kind of a loose standard but Iroha actually standardizes how you represent it like an an asset an asset is like you know some kind of point or currency or it could be you know non-fungible token like something like that something that is owned and the way we also have a really robust way to add different metadata and other types of data so this is a little bit small let me zoom in so I can't actually zoom in more than 400 that's too bad okay so in a domain for instance the domain has accounts it has asset definitions and also has this metadata field so you can add other types of metadata associated with the domain this could be you know really anything so some kind of like you know key value model you can add to represent any kind of annotation about what a domain is we also have this logo field too that's to help like data viewers to be able to in a decentralized way show information about the data on chain so sometimes you would want like logo data this is optional of course domain has accounts so what that means is that all accounts on the chain are associated with some domain and they can inherit some properties from the domain too like permissions and accounts have assets and they have signatories so this builds the concept of multi signature account directly into the into the data model so you can have multiple signatories on an account and you can have some threshold of how many of these signatories you need to to make a transaction for example if you have like three keys for signing out of the three keys you can have like requirement for two the keys to have signed a transaction for it to be validated again you can also put metadata on an account so this is really useful for decentralized identity use cases because you can make a verifiable or validable claims about an account and also calculate a decentralized identifiers and put them associated with the account directly on chain then you've got assets and asset definitions asset definitions just you know kind of holding some of the the type data about the asset and then the asset itself is the kind of the quantity information about how many of this asset specific account owns there's lots of options that you can play with it's made it's made to be really robust out of the box so you don't have to write all this logic yourself if you're trying to do common asset use cases one thing that may also make it easy to kind of see how the data model works is taking a look at an example Genesis block so in the Genesis block you can have this optionally you can have a definition of some assets and users right in the first block and I was hoping actually to zoom in more than 400% but anyway it is what it is so I'll just read it through in case you can't read this so what you have in the Genesis block is a very simple definition in Jason where you have a list of transactions that are executed in order and you have eyes eyes which I'll talk about in the next slide actually and so in you know how to we have a list of predefined kind of commands like a library and these are called eyes eyes or your house special instructions the idea is it's similar to a house CPU has a instruction set that is predefined and these are just high-level instructions like a register like like a mint like I think there's a a D mint or burn type of instruction too so here's an example of registering a new domain called Wonderland so there's a lot of wrapping and stuff that hopefully will be simplified in the future but what you have is the register ISI that says register and then you create an object and it's an identifiable answer domain and it has a name Wonderland and at the beginning when you first register it has no accounts or assets but once you register the domain in this transaction you can define the next transaction which is registering a new account called Alice in the domain Wonderland and Alice has the signatory just one signatory here this is a public key so it uses the twist-a-words curve ED and then then has the public key bytes here so you could have actually multiple signatories here if you wanted to have a multi signature account so it's really easy way to make multi-sync accounts and then you can also register an asset definition so here's an asset definition so register object asset definition name is rose and it's in the domain Wonderland and you can just create the asset definition then you can mint some roses so you call the mint instruction and it's for the asset definition rose in domain Wonderland and you give it to an account ID Alice in the domain Wonderland and you mint 13 of these roses so it's a little bit verbose but this is you know the predefined Genesis block that kind of starts up the system and in the future I think it will be a little bit simplified using something like the Python library also makes it easier to write this but this is showing an example of of an of how the ISI's work so the pre this pre-built library is really robust so you can create many different types of accounts and assets right out of the box without having to do anything complex and because it's written right into the core the data flow is really optimized for these so it's can be made very fast here's some more examples of the ISI's so this is using the rest library so I mean I kind of simplified it a little bit but you can create this domain looking glass and then inside of looking glass so once you create the domain you you can build the transaction using the library then submit the transaction so it's really easy to just you know write some code as a client and submit it directly to one of the peers on your network and it just takes a few seconds and once you have this domain looking glass you can register a new account white rabbit at looking glass so this is kind of like an optional well I'm not sure if it's optional yet it will be in the future this this type of named account structure so this was also used in Iroha one where you had a domain and account model and every every count is kind of given some name and but in the future this is going to be an optional name but it can be simple or useful for some use cases to be able to say hey I want to send money to white rabbit at looking glass it's like an email address type of structure but you can also send directly to other types of identifiers in the future or maybe even now I'm not sure if it's finished yet actually so I should check so I size are nice but there's also you know whole universe of possibilities out there so you want to also be able to execute arbitrary code and that's really where wasm helps so wasm is web assembly we use wasm vm to safely run executable code and we have some interfaces so you can you can call the object model inside of your wasm contracts so here's an example of a use case where you you query you find all the domains in the system so you just say give me all the domains and you get this vector and then for each domain you add you add a new account called mad hatter so you basically loop through all the domains you add a new count all the domains and then you register this that's what the register instruction down here does so you can call the ISIs inside of your wasm contracts and this is how you update the world state so this is a silly example but it kind of shows you how it's really easy to do these types of things with the ISI framework and because you can write this code in any language that compiles to wasm like a wasm blob it gives you a lot of flexibility I mean you do have to have the libraries built for it of course and then finally I want to talk a little bit about exciting feature called triggers so triggers are quite complex and I can't go into all the details now but it allows you to execute some some code or an action on an event that's emitted so when you execute certain types of events in Iroha you get an event that's emitted and you can listen to these events so here's an silly example but it allows you to create a trigger so you register a trigger called refresh T and this trigger when it's executed the executable here creates a T asset and of quantity one and transfers it to Alice from the mad hatter so what this does is when the when Alice reduces the well I'll talk about the event here in a moment but what it's supposed to do is when the asset drinks some T she gets more T from the mad hatter so when the asset in her account reduces she gets more sent to her so the way it works is there's it's easier to look on my screen here so when the so you have this trigger that repeats indefinitely that is looking for some event that is asset event filter removed it says by remove so when the asset you're looking for is removed from an account you get this event that's matched and then you send you execute the executable which sends the T from mad hatter to Alice so it's a silly example but it shows you how you can listen to certain events and then execute some action this could be used for paying like automated transaction taxes in CBDC context or doing really any kind of cool things since I have a few seconds left I'm going to say for the future we want to also expand it or how to to work more in the decentralized context so using a nominated proof of stake type of consensus will allow us to set up public blockchain networks that can be used for DeFi apps and I think this model with event triggers and wasm blobs execution can make for really cool apps and we would like to see if this can be used to work on other projects that we contribute to like the SOAR network and the poker swap decks which is an on-chain decentralized exchange because this type of trigger execution model can really open up new possibilities for DeFi and they do cool things and with that I'm out of time but if you want to get started with it or how to please check out the the docs which are at the hyperledger github here and you can also go to github slash hyperledgers for the namespace and then either hot if you can find the either hot github repository so yeah please check it out and I'm happy to take any questions outside of the room right now so we're out of time so thank you for your time and for coming.