We are going to ask Allison, a current Tesla driver and user of its full self-driving Beta 11. How is it? V10 was out about how, I like to describe it as a teenage driver who is also drunk was what it was like, basically terrifying. We just got V11 and V11 is a huge improvement. I would say it's still a teenage driver or an inexperienced driver, but it is definitely not drunk. It's very confident pulling out of intersection into traffic and it's not making mistakes when it does that. It no longer tries to hit physical medians. It always stays in the center of the lane, no matter what. So if you're on a curve to the right, you know how you hug the inside of the curve? Nope, it goes in the center. The child of some friends of mine was killed in an accident recently and I will keep working on this and keep giving all my feedback and trying to help it exist because we need to stop being the ones driving. We are not good at this and we goof around on our phones and we just need to stop.


I tell you what, man, I remember when they arrived to Nashville. The year before they got here was a freshman in high school. Our house caught on fire in North Nashville. We didn't have the means to move from that house, so we had to go stay in that house. We stayed there for about six, seven months. The titans moved here. And going into my sophomore year, we're getting ready to go into Christmas. And like me and my brothers and sisters, the oldest of six, we ain't telling them, come on, man, we got to get gifts, this, that, and other. But I remember Christmas morning. We woke up, there wasn't no toys or anything under the tree. But we ain't tripped. We just went in there, ate breakfast. All of a sudden, there was a knock on the door. My mom go answer the door, and it's the Tennessee Titans, coming over there with gifts. I remember Marcus Robinson. I remember a D-line coach. I can't remember their name. But automatically right then, they became my favorite team. Forget the player. Like, that did it for me. Like, they made something happen as a sophomore with all my brothers and sisters, that we had no earthly idea what we were going to celebrate. So they automatically put life back in us, knowing that like the Music City miracle, miracles can happen. I'll carry that forever.


Hello everyone, and thank you for joining our session about protecting open cloud infrastructure here at the Linux Foundation's open source summit. My name is Kristen A. Comber. I'm a senior analyst with Evaluator Group. I cover data protection and data management related technologies. In our session today, I'll kind of work through kind of some of the data exposure risks related to open infrastructure, including Linux systems for cloud environments. And also provide some tips on kind of how we see customers working to mitigate those risks. I'll also kind of wrap up the conversation by sharing some best practices that we've seen based on our engagement with customers in terms of data protection and compliance for this, again, this open infrastructure that's kind of going to support cloud environments.  We are an analyst firm that is very specifically focused on information storage, information protection and kind of information management related technologies. We do study products very closely at a technical level. And we consult regularly with IT professionals to kind of, again, give them, you know, some guidance regarding how to approach different projects or pain points that they might, that they might be facing. So we do have, again, kind of those services. We also have kind of a whole research library covering various technologies across the product segments that you see here on the slide. And so with that, I would love to jump right in. So we are talking about cloud infrastructure here at a conference with all about Linux. And so I thought it would be a good idea to start with kind of some conversation about why does this make sense, right? Why is Linux popular in cloud environments? And because we do see that it is popular in cloud environments, we see that it's heavily in use by public cloud providers like Amazon, like Google, for example. And really, one of the big reasons is because Linux is open source and it's also very flexible as an operating system. So what that means is that it's very customizable and that it can support a whole host of different use cases, as well as kind of a variety of target systems as well when we begin to start thinking about data protection. And we see that Linux has kind of this very vibrant community, right, of contributors that are just kind of wide ranging in their skill sets and in their requirements. And so again, we do see that Linux serves, you know, kind of smaller scale environments, but also implementations that might span internationally as well, especially when we start thinking about cloud, of course. So I've alluded to kind of the fact that Linux does have this very large base of developers. And so also that means that the code base itself tends to be fairly stable. And that also kind of its capabilities and also some of its bugs are being continuously sort of, you know, fine tuned and addressed and things of that nature. Another kind of characteristic of Linux that makes it popular in cloud environments is that compared to closed source systems, it can be kind of high performance while also being kind of more cost effective as well. So it can have, you know, sort of that acceptable level of performance that is required, but then at the same time be fairly cost effective as well as course being, you know, open source and things of that nature. And then a final characteristic is that Linux is modular and it is scalable as well. So we start to think about cloud environments and some of the exponential growth in traffic that these environments has. It means that Linux can handle, you know, kind of these again the spike in traffic without a huge spike in expenses as well. So of course that's very attractive. So Linux and other open source systems, they do carry a number of unique advantages compared to kind of closed or proprietary systems. And I'll kind of talk through those on the slide. But then as well, some of the risks in terms of data exposure and that's really going to kind of lead us into really the meat of our conversation today. So just taking a little bit of a step back so open source code open source systems.  So this means that, you know, any problems or issues with the code in theory can be detected, you know, possibly more quickly right then, if it were kind of a proprietary system that has a smaller base perhaps as developers that are working on it. You know, an open source software platform that have, you know, 10, 100,000 of contributors, you know, so again, more eyes tends to help detect those problems more quickly. Another advantage is that once those potential issues are found, things like patches and updates, but also new versions of the software as well. They're not tied to a commercial product update or commercial product launch. So this tends to make them be available more quickly and kind of get into the hands of users in theory at least more quickly compared to a proprietary alternative that again maybe is tied to kind of that product cadence. Now, the flip side, you know, of this coin if you will, is that although vulnerabilities in the code can be detected more quickly, they also tend to be more exposed. And also, how these vulnerabilities are going to be corrected tends to be more exposed as well. So, and we find tends to be, especially when we start to think about things like cyber attacks like ransomware, for example, that's a big one that we all tend to hear about regularly. We'll get into that in more detail, but these bad actors, these hackers, they really do tend to keep an eye out for these vulnerabilities and how they're planning to be addressed and try to leverage that as an end, you know, again, for example, to plant ransomware. So again, that is sort of, you know, a risk or a threat, if you will, in terms of using open source infrastructure, especially from the standpoint of data loss, of course. And along that line as well, so we kind of talked about patches and versions and, you know, any bugs or issues or vulnerabilities being fixed. Well, oftentimes there might be a number of different components of open source software that go into, you know, that kind of go into these cloud environments that we're talking about here. So, there is the risk that because there's a number of moving pieces, you know, perhaps there are some practices that are a little bit lack, lack of a better way to put it, in terms of, again, tracking all those components that are being used and also all those vulnerabilities that might be kind of cropping up and really making sure that that those are being addressed. And so the final point I did want to make here from sort of a risk standpoint is that, although there's a much larger base of developers, typically speaking that are working on open source code.  And there are a few, if any repercussions if the software is not found to be, you know, sort of having its own abilities are addressed or really kind of following some good guidelines and good practices in terms of being responsible in terms of how data is being collected and retained. And that becomes a risk from the data protection standpoint. And we'll talk a little bit more about that when we start to discuss issues regarding compliance. So we've just kind of covered some of the major risks for data exposure that are associated with open source infrastructure. And in the next section I did want to talk a little bit more about why data protection is needed, as well as some of the basics, when it comes to protecting data from disasters, and for meeting compliance requirements, which I just alluded to as well. So that's what we'll cover here in the next section. So, of course, the fundamental question, why data protection? Well, one of the big reasons is that data really is at the heart of business lifetime and business value these days. You know, I don't think that's a surprise to anyone on the phone, we tend to hear about that a lot. So really the tolerance for data loss or the tolerance for kind of data exposure just tends to be very minimal these days. So it tends to be important that that data is being protected and that it is being protected effectively. And one of the big things that this data needs to be protected from these days especially is ransomware, which I've already alluded to. You know, it's not only is it all of the headlines, but it's costing big money. And we see that these hackers are just constantly getting smarter and more sophisticated. So the attacks are getting more sophisticated and the attacks are also occurring more frequently as well. So we saw, for example, the colony of pipeline be shut down earlier this year. That is one of the largest oil pipelines here in the U.S. That was shut down due to ransomware earlier this year. We see these organized gangs and essentially businesses having sprung up around ransomware. One of the highest profile ransomware gangs called Reval. I actually just read earlier this month, they've kind of reemerged, right? So, you know, they're certainly not backing down by any means. In ransomware, you know, we tend to think about it in some of these high-profile headlines, but, you know, really it can impact organizations really of all sizes. And some of the smaller companies that maybe are doing business with an MSP that might have been impacted by ransomware, you know, even kind of smaller scale organizations as well becoming targets to a degree. So it's certainly something that is, I think, a consideration for effectively all businesses these days. Another kind of item in terms of why data protection, why does data need to be protected is not only some of these external threats like ransomware, but also internal threats as well.  Well, it's important to be able to have, it's important to be able to not only control the access and the ability for that rogue admin to be able to do that, but also to have, you know, backup copies to be able to recover from in the event that something like that happens.  The legal compliance requirements. So I alluded to this a little bit. You know, I think we're likely all familiar with the European Union's GDPR. We've seen California's CCPA and essentially these pieces of legislation that are cropping up and kind of stipulating how user data needs to be kind of collected and stored and really some of the rights that users have in terms of what data is being collected and stored about them. We'll get into that in more detail, but this certainly requires a lot of very kind of fine brain data protection capabilities to be able to meet these requirements and not have signs or other, you know, of course, negative repercussions. And then finally, I wanted to touch quickly on the shared responsibility model. So, especially when we start to think about moving data off-premises into the cloud, you know, into kind of a public cloud hosting environment. I wanted to bring that up here because we do see a lot of hybrid cloud models or maybe some of the infrastructures on-prem and applications, but maybe there's some infrastructure and applications off-prem as well. So I wanted to touch on this because we do see that a lot of the time there's an assumption that the cloud provider, the cloud service provider is responsible for the data protection and that's actually not true. That responsibility does still lie with the customer. So in the event of ransomware, you know, a piece of legislation that needs to be complied with, for example, it is still the customer's responsibility to make sure that the data and the data protection implementation are helping them to meet those needs. So even with all of this, you know, right, kind of this case for data protection, if you will, these sometimes get asked by customers, well, my system itself is architected for high availability, right, to have that maximum uptime. So why do I need data protection on top of that? So on this next slide here, I thought I would break down some of the differences between high availability, which is HA, and disaster recovery, which is DR. So for me, I tend to think about two fundamental differences between HA and DR. So from the standpoint of HA, it tends to handle problems that occur when a system is running versus DR tends to handle problems after a system has failed.  But it does not address data loss, which is addressed by disaster recovery. And it also doesn't address some of these, you know, more catastrophic events like a natural disaster or ransomware attack or things of that nature. So let's break that down a little bit. So essentially what HA means is to design a system to eliminate any single points of failure. So for example, we see a lot of redundancy in the hardware components like a power supply. So in that example, if something were to happen to one of the power supplies, the other one would be right there, up and running, ready to take over, you know, as instantaneously as possible. And in fact, the system can detect that outage for the primary power supply and switch over to that redundant component. Again, ideally, if not instantaneously, you know, at least very, very close to it, for lack of a better way to put it. We do see software redundancy as well. I did want to mention that, of course, to this audience here today. So that's, you know, for example, clustering to spread an application across multiple systems that way in the event that one system goes down, the application can stay running. And really kind of the concept is always on, always available, or at least having minimal interruptions to that service. It really is as synchronous as possible in terms of some of those failovers. And so that those operations can be ideally continuous and really have no failure. Now, it can and often is, you know, kind of, it can be a component of DR, and often is a component of DR, but that's recovery, or at least true disaster recovery really goes a step further. It's more of a strategy or a more holistic plan to be able to resume more normal operations in the event of some of those, as I kind of described them, catastrophic disasters. So an earthquake takes out a data center or there's a cyber attack that takes down a number of critical systems and wipes out, you know, from some backup data, for example. So it's again, it does include the technology itself. So again, it can be a part of it, but it also looks at people and processes as well. So, in fact, one best practice that we talk about with customers is to have a DR plan. So what needs to happen in the event that an IT system goes down or that, you know, that data, or that there is a data loss event and that there does need to be a recovery operation from a point in time in the back of the environment. And that latter part, that kind of data recovery, that's very important. So with certain technologies like snapshots and backups and replication, which we'll get into in more detail in a few moments. DR does address the ability to recover the data in addition to the systems. And again, that's not something that's factored into HA. And on this next slide I wanted to talk about, you know, a couple other items, you know, maybe kind of break down a few differences as well in terms of. So we talked about disaster recovery, but also kind of looking at disaster recovery alongside what we term is kind of back up in more operational recovery. And so back in recovery and disaster recovery together, they tend to pretty much compose the majority of what we see in terms of data protection, you know, implementations and strategies. So depending on the technology and the environment and the different requirements, DR kind of DR and operational recovery, they're typically going to leverage secondary copies of the production data for that that data recovery. So we see kind of the first sub bullet here we see snapshots being one of those secondary copies that might be used. And what a snapshot is, it is actually kind of you can think of it as like a picture that is taken of a file system at a specific point in time. They're primarily designed for short term storage they actually typically will live on the system itself. And with time older snapshots will be over and by newer ones, just due to the space requirements. And snapshots are used to actually restore that server to the exact state that it was at at the point in time in which the snapshot was taken. So backups are a little bit different, they are actually a duplicate copy of the data that is created, and it's actually stored in a different location than the original or what we call the production copy so there is that geographic isolation. And that tends to become important as an additional safeguard for DR and data recovery, and the event that you know the production environment is compromised so you're not relying just on that one system. You now have this geographic isolation between these two systems, and you have that that secondary copy that's living again on a different system. These are not able to be taken instantaneously like snapshot is in theory, depending on what you're backing up they might take hours or days to complete. But again they do provide that additional safeguards. So, okay, so we've talked about the fact that data copies including backup can be used for DR and or and operational recovery. So, what is the difference here. Well, a DR scenario is typically more of almost a crisis, right that is going to directly impact business uptime. Typically there might be a failure in the primary data center, and then you know you will need to recover to that alternate to an alternate site actually. And again we didn't necessarily talk about this on the previous slide and we're talking about the differences between DR and high availability. But typically in a DR scenario there's a secondary site whether it be in the cloud or whether it be a secondary data center that's maintained by the customer that that recovery operation or that failover can happen to. So again, they are typically more of kind of a crisis if you will. Operational recovery tends to be a little bit more routine and a little bit more smaller scale in its impact to business operations, early and also to it kind of just by nature. So this might be things like an accidental file deletion, a coder, a file that is wrongly saved or things of that nature. So you might ask, well, why wouldn't I want to kind of just always DR and kind of have, you know, a quicker failover and have less data last well there's a price differential. Disaster recovery can be much more expensive than an operational recovery back in recovery. And this is because you do need that secondary site. It's also because of the technologies that are used. So we do see that customers tend to sort of pick and choose when they're going to implement it through DR and that it tends to be for a critical application. So this is really going to be driven by what we call the RPO, the recovery point objective, which is essentially the amount of data loss you can tolerate. The amount of time that you can recover to end the RTO or the recovery time objective. So how long does it take you to recover? And again, those are, you know, essentially the smaller your RPO and the smaller your RPO, the more expensive the technology is going to be because, again, because you're going to have that more limited data loss and you're going to have that more limited downtime. So a couple of other things to mention here, data archiving and long term data retention. So as these data backup copies age, they might still need to be retained, for example, for compliance reasons. But of course, their value from recovery standpoint is going to go down because they are older. So going back to those RPOs that we just talked about. So part of a data protection strategy is also typically to allow for data to be kind of archived or tiered off to data that is less expensive. But, you know, it may not be as high a performance and things of that nature. So the back these archived data copies are still acceptable if they're needed. But it's just going to take longer to recover to them. But again, they're still available if needed. And then one other point I did want to make is that oftentimes we do see data protection technologies be used for data migration initiatives. So, you know, customers are moving their data around all the time these days. And oftentimes they might leverage their data protection solution to do that. So we talked a lot about kind of protection against natural disaster cyber crime. Another element to kind of cover is data privacy and security legislation that must be complied with. And this tends to be typically industry specific, possibly regional specific. I alluded a few minutes ago to the, it's called the general data protection regulation GDPR, which is essentially is in the European Union. And this is one of the strictest regulations that we've seen. So it's actually a good example. It's also quite applicable on a global basis because GDPR governs how data related to people in the EU, in the EU, excuse me, is targeted or collected. So essentially it impacts any business that does business in the European Union. So basically what GDPR and some of these other regulations are aimed at doing is giving individuals insight into and of course ultimately control over how their own personal data is being collected and processed and stored. So we hear about the right to know or the right to be forgotten. And essentially what this means is that the customer has the right to ask what data about them is being generated and stored. And they also have the ability to ask their personal information be either anonymized or deleted, if they so choose. We also see that they have to provide consent and really have the option to understand what data about them is being collected so there needs to be transparency on the part of the business that they're doing business with. As well as of course how that data is kind of being used as well. So that's another point that there really needs to be that business case for collecting the data. And there's this concept of data minimization, which basically means that companies are not going to just companies again need that business case for collecting data, and that they should only try to collect the minimal amount of data that they need. And then data deletion. So we talked about kind of the customer request for their personal information to be deleted. But this also tends to be important as data ages and things of that nature. So the accountability is really on the business or the organization that is actually controlling your processing the user's data to make sure that you know all these situations are met with so that the data does not ultimately fall into the wrong hand. And it's pretty broad spread it actually stands to data life cycle from the initial point when the piece of data is being kind of gathered or collected all the way through when it's being deleted which I think is pretty clear based on what we've talked about. So from a software kind of an open software development and sort of an open source standpoint a couple things that are that are interesting. So some regulations do have a stipulation to avoid known software vulnerabilities, which of course when we think about open software is practically unavoidable. But essentially as long as the business establishes or can prove that they have an appropriate level of security in response to any known vulnerabilities that you know then essentially they're they're meeting their compliance requirements so it's really about avoiding revealing the personal the PII as we call it this personally identifiable information. That is kind of the ticket here if you will versus just kind of the software code itself being publicly visible. This goes back to kind of one other point I did want to talk about which is the concept of privacy by design, which is really that data privacy should be considered upfront and so of course data protection is going to be an important component of that. So we've gone through a lot of fundamentals in this next section I did want to kind of double click down on some best practices and really provide a little bit of guidance regarding what we see in terms of you know kind of customers doing and just some of the learnings from that perspective. So we think about best practices for data protection. I think one of the first things to be cognizant of is actually really just to be cognizant. We're seeing kind of the mentality that just because you're using a Linux system does not mean you won't be the target of a ransomware attack or otherwise have a need to retain and recover your data. You know and hopefully we've kind of gone through a number of the reasons why this is important here, but that's just something kind of that mindfulness there I think is the best practice that we see. Another best practice that we see is to use a variety of technologies to meet those RPO and those RTO commitments without breaking the bank. So we've already kind of covered a little bit around operational recovery, recovering from backups. I did want to talk a little bit more about what we call replication. So replication is often used for disaster recovery and essentially what replication does is a copies data changes from the primary database to a secondary database that is typically located on a different physical server. And then that secondary physical server can then essentially operate as the failover location in the event that a data recovery is needed. There are different types of replication that we see one is called synchronous and what this means is that the data is being righted to that primary or what we call that production database in that secondary database or what we tend to call the replica at the same time. So an implementation like this might be used to support some of those very, very highly available, very, very kind of low RPO, low RTO applications or use cases. Again, because the data is being righted at the same time and it really can be ideally failed over to as quickly as possible. So asynchronous replication, what it does is it writes the data first to that that production database, and then it commits the data to be written to the replica that we talked about. So there tend to be some benefits here compared to synchronous in terms of asynchronous replication tends to be a little bit lower cost. And it also tends to have benefits when we think about physical geographical distances when these are an issue. It's a little bit kind of cost effective and easier to work with from that standpoint. One more technology I didn't want to cover is called continuous data protection. And essentially what this does is it automatically saves a copy of every change that has been made to the data. So it tends to be very, very granular in terms of what can be recovered. But of course that tends to get expensive. So we also see what we call kind of near CDP technologies. For example, that might provide access to files on a file share at intervals of probably 10 minutes, 15 minutes. And it provides a higher level of protection than in some cases that we see a backup of the backups are definitely getting there for sure. But at a lower cost and kind of a true CDP technology. And another important consideration I did want to address is kind of how you recover. So, in other words, what granularity do you have, can you recover individual files can you recover directories. You have to recover the entire virtual machine or container. You know, ideally, of course, you would want the ability to be able to do both. So you'd want to be able to recover a few files as needed, but then also recover the entire application in the form of VMs and containers, if that is what what is needed. However, a lot of data protection tools are optimized around only one of these scenarios. You know, of course, a lot of them are getting there. There's been a lot of development that's been going on. But it's just important to kind of keep in mind and really kind of understand the capabilities and any possible limitations of the particular solution in question again to be able to understand the granularity of the recoveries that are going to be possible. I also wanted to introduce the concept of application consistency. This is important, especially for large and complex applications, because what it does is it allows the backups to be more reliable. And it also allows for a faster way to get the application back online again in the in these cases of having these kind of large complex applications with a whole variety of dependencies that are required to get them back online. So what an application consistent backup does is it actually pauses the application operations and then it allows any pending data rights to be flushed out to the storage disk and sort of captured there. And this is in contrast to what we call a crash consistent backup, which with that what a crash consistent backup does is it takes a snapshot of all of the files at the exact same time. So essentially, it allows the application to be brought back up to that exact point in time. But again, there might be different considerations, depending on the state that the application was at at that point in time, in terms of getting that data back up and running. So I bring this up here, because there are some APIs that can be built into the applications up front, you know, essentially to allow for that consistent copy to be created. So Microsoft has what it calls volume snapshot service VSS VMware has its V storage API for data protection which is the ADP. And again, these allow users to create those consistent point points in time, right in terms of kind of the state of the file system, so that they can then be, you know, copied or backed up and building these in upfront process to happen without then requiring kind of a third party application to come in after the fact and try to do this so it tends to kind of be beneficial from that perspective. A few other odds and ends that I did want to mention regarding best practices across the next couple of slides. And again, these are related to data protection. So the first is thinking about technologies that can help to detect problems in the backup process. Because of course, if there's a problem that occurred with your backup, and it is not a good backup to recover from, you know, then you are going to have problems with, you know, of course, recovering that data to the point in time that you need. So leveraging things like a checksum, which is essentially a very small data block that is used to kind of detect any errors that might have happened during the transmission of the data to the storage. These can be really helpful in terms of verifying the integrity of that backup, for example. Encrypting data in-flight and at rest, definitely best practice. This can help to avoid some of those bad actors from accessing the data backup copies in the first place. Another item is the concept of access control. So we see a lot of data protection software today, you know, using capabilities like multi-factor authentication, role-based access control, to really make sure that only the correct user is able to access, you know, data, backup data, and that they only have the amount of control that they really specifically need to get their job done. So again, this can help kind of that hacker, that bad actor, prevent them from accessing the backup copies. We also do see what's called kind of two-person concurrent. So certain actions like, you know, kind of perhaps changing an immutability setting or deleting a file or deleting, you know, a certain storage volume might require the authenticity authorization from two individuals so that one individual cannot go in and wreak any havoc. And that's, you know, important when we think about some of these, you know, internal bad actors or these hackers as well. Logging and auditing can be very helpful to detecting security vulnerabilities, also giving reading indicators of breaching, you know, breaches to the environment. So for example, a failed login attempt. And then I did want to touch as well on kind of remote login, secure shell is very commonly used to manage kind of Linux servers remotely. So just making sure that there's the proper configurations that it's behind a firewall, you know, really kind of best practices from that standpoint. A few other things to think about. So physical server security, you know, making sure that the environment cannot be physically accessed by, you know, a bad actor, patching, patching, patching, patching. This is very important, including for the Linux kernel. You know, outdated patches are one of the ways that we see these ransomware attackers kind of targeting to go in. So this is very important to keep these upstate. Avoiding unnecessary software and services really keeping the environment to the basics of what is needed. Disabling booting from external devices. That's just another way that a bad actor might be able to penetrate the environment. And that involves right as an additional kind of preventative measure in terms of, you know, again, getting access to the environment also, you know, kind of maybe detecting that an attack is occurring. And that's when we start to think the next bullet here into the virus software. We do see data protection software building in kind of anomaly detection to be able to analyze the back environment for things like large scale encryption activity, for example, that might indicate that a ransomware attack has occurred. We do see kind of more server side software being used to detect an intrusion as it's happening. So these are very complimentary to each other and, you know, really kind of a best practice to be able to use both. And of course, vulnerability scanning. I know we kind of talked a little bit about that earlier. I did want to share a little bit about consign specs practices before we shift to kind of our summary section. So a lot of these you'll see are similar. One of the big ones is just getting visibility into and control over the entire state of backup copies. So the, you know, the customer has responsibility for knowing what data is being created, where it's being stored, how it's being stored. So having that visibility is very important. We do see data protection software vendors are working hard to be able to kind of try to provide that single pane of glass. So making sure that they can, you know, provide that visibility across your various environments is increasingly important these days. We've talked about the value of having those externally stored encrypted backup. As well as I just alluded to the security scanning as well as the auditing and logging and patching. And then again, just, you know, kind of these last few bullets here, really a similar vein. So, you know, essentially sound data protection, you know, having sound data protection implementation and kind of following some of these best practices is also going to help on the compliance side as well. So in summary, I wanted to leave you with a couple of slides. The first is essentially some of the key things to look for that we see any data protection solution. So the first one is making sure that the data protection solution can support all the sources that you need it to from both an on and an off premises perspective. So kind of support any on prime VM support any cloud applications that you're using. Going back to that single pane of glass that we just alluded to, you know, increasing these becoming important for data protection solutions. Frequent backups are important that really is the insurance policy in terms of being able to recover. So of course that's important. Similar search and recovery. This becomes important. You know, especially when like we talked about you might want to recover one specific file you might need to recover a couple of VMs but maybe not the entire VM estate for example because of course what if some of your virtual machines are still impacted with ransomware for example. So having that kind of fine grain capability becomes important. So extended data retention, you know, we did talk about the fact that this might be required for compliance or other reasons. So that's important to look for. And then the ease of use. So we do see data protection teams are spread very thin these days. They're having a complex very complex environment. And they are dealing with all of these, you know, cyber attacks and compliance requirements and things of that nature. So that ease of use becomes important. In fact, for many data protection solutions, we see some self service capabilities being built in for that, for example, the developer might be able to execute their own recovery easily without having to go through it. And so this is something kind of to keep in mind. The cost effectiveness. This is always table takes and data protection, really making sure you're getting the most bang for the buck. Of course is important. Airgap being an immutability we didn't touch on this too much but these are important preventative measures against ransomware. So air gap essentially means having a copy of the data that is not accessible by the host or by the production environment. And really is kind of the final safeguards from a recovery standpoint. And you see the cloud being is for this today. For example, and so this is important. Immutability basically what this means is that the data cannot be deleted or altered until a set period of time. And so for ransomware, this is important because even if the hacker is able to gain access to the back of environment, they're then not able to tamper with the back of data. DR testing we heard a lot about this especially in 2020 with the COVID-19 pandemic customers were looking to switch to remote operations they're looking to try to protect against all this whole kind of insects of ransomware attacks that we saw happening. And they needed to make sure that their DR plans were sound and that they were going to be able to recover so testing just really became top of mind. Analytics machine learning.  And this can become important for identifying that a cyber attack has occurred. Data reuse. So being able to make the data accessible. For example, for test and dev or other kind of business use cases. This is important. And then the data mobility. I mean, we talked a little bit about this a few slides ago, but being able to make that data mobile across heterogeneous environments is becoming a requirement we're seeing today. And then my last slide here is sort of just a number of questions that you might consider asking, you know, as you know when looking at different data protection offerings and solutions. So the first kind of going back to our previous slide is what data needs to be protected? Where is it located? Are they all, you know, are all of the sources protected by the data protection pollution? And then of course the storage target. So this is kind of the storage environment where the backup copy is going to be sent to. You know, there's a variety of options and really just making sure that the proper, you know, storage targets are going to be supported. Of course that's important. I thought this next bullet. I think this one is pretty interesting. People skill sets capital resources, right? Do we have what is needed to be successful? What is lacking? There's, you know, this data protection, you know, really is kind of evolving these days with clouds, containers and things of that nature, you know, open source, I think, certainly. So really just making sure that the organization has all the tools and capabilities to be successful is important. Making sure that the recovery points, recovery times, locations, everything that is needed, making sure that those are, you know, supported and available is important, of course. Understanding any high availability features that might be built in, like those checkpoints we talked about to complement the system architecture, that's important. The data encryption is important. Also, how are those encryption keys managed? What control does the customer have over those? Not becomes important as well because, of course, you know, you want to make sure those encryption keys are protected appropriately. Auditing is the backup solidity. So again, making sure that those backups are good, making sure that there has been no issues with them. This is important. Automating and testing recovery processes, we just talked about data archiving, you know, making sure you understand what capabilities are available. And then the compliance oversight capabilities as well.  So with that, I know I've kind of thrown quite a bit at you today. You know, I do believe we're going to be taking some questions here during this session. I also did want to leave you with my contact information, including my email address and some social media contact as well on the bottom left hand side of the screen.  So please don't hesitate to reach out if there are any follow up questions on this. So with that, I wanted to thank you all again for joining the session today. Really appreciate it and hope you enjoy the rest of the conference. Thank you again so much.


All right, welcome everybody to today's interoperability panel discussion on the hyperledger cactus weaver in U.E. Before I started, I wanted to see how many people attended the interoperability panel yesterday with Takuma, Rama, and Jim? Two? Three? Okay. All right, so it sounds like maybe we need to cover some of the same material that we did yesterday, but we'll see what else we can impart for those three of you who did attend yesterday. So first off, I'm going to start by introducing us. So my name is Tracy Kurt. I work for Accenture. I'm a technology architect there. I've been involved in blockchain interoperability since my first day at Accenture. I got an email from the folks there who were really interested in open sourcing the blockchain integration frameworks that they had created. And so that was really the first kind of task that I was given. How can we open source this? And so we brought that to Hyperledger Labs, which blockchain integration framework eventually became hyperledger cactus. So that's how I'm involved with the interoperability space. Takuma, would you like to introduce yourself? What are you working on? Okay, thank you. So my name is Takuma Takeuchi, and so I am a maintainer of hyperledger cactus and the new name Hyperledger Cacti. And so I'm also working Fujitsu as a blockchain research manager. So with the experience of the hyperledger cactus, Cacti and blockchain interoperability, so that I would like to accelerate the token economy technology beyond the various industry. Yeah. Okay, nice to meet you. Hi, I'm Rama. I've been a researcher with IBM for over a decade. And I've been working on hyperledger technologies mainly fabric since its inception, been interested in interoperability since around the end of 2018 and worked on the Weaver before it was called Weaver. It was an internal IBM research project and you open source it about a year and a half ago and interested in all things interoperability. Okay, so my name is Susumu Toriyumi, VP of Product at Data Chain. Data Chain is the main contributor to the Hyperledger Lab called UE. So we are working on the subject of interoperability for more than three years. And last year we have decided to contribute to Hyperledger under the name of UE. UE currently supports the Hyperledger public, Facebook, Koda, Iroha and Koram. And it aims the trustless interoperability solution for networks or blockchains. Thank you. Alright, so I thought maybe we should start with a definition of interoperability. So Rama, I know you've said your definition a couple times already during the conference, also at Member Summit. Tell us what you think interoperability is. Interoperability to me is the way to, when it comes to decentralized ledger systems, is the way to scale up decentralized trust without forcing the networks to integrate or give up their sovereignty, that is integrate in the sense of having to merge together or coalesce into a single network. Interoperability enables two networks to work together in order to conduct transactions when they need to, as they need to and which are completely under their control, that is in an on-demand manner. And there are several different patterns and several kind of base use cases where two distinct networks need to link in this way because there are transactions that cannot afford or in the real world that cannot, just cannot remain within their network boundaries. So interoperability is an absolute necessity here. Now, what we've been seeing the past few years is people have been building networks, especially permission networks, as sort of a minimum viable ecosystem. They've been going slowly. They've been picking small problems and small, and portions of business workflows to run a smart contract within their respective network. Now that the experiments are over, people are now finding that you can't afford to leave these networks, remain in silos, that is in a fragmented manner, and you cannot have their assets be disturbed within the network boundaries. So interoperation is the way to enable the existing networks to come together to link when they want, as they want safely and in a decentralized manner. So Sumo, would you add anything to that? Yeah, I couldn't agree more. At Data Chain, we have a vision of the many, many blockchain-based system, whether it's public or enterprise, working together and interacting with each other to fulfill the complex tasks without losing consistency. It will include the security token dividend, trade finance, or insurance claim and payouts. And the simplest example of such interoperability would be the delivery versus payment of the digital asset. So we have one party transfer the digital asset to another on one blockchain, and the payment is on the other blockchain. So even in this simple setting, without interoperability solution or careful design inconsistency or double spending may occur. So I think the interoperability is an essential piece for the complex tasks like leveraging DeFi from enterprise systems. So yeah, I would say interoperability would be the must for blockchain to realize its full potential. And Takuma, would you add anything to the definition of... Yeah, so I almost agree with the two definitions, but I'd like to add a short definition. So in my sense, interoperability is exchange formless or intangible value across the multiple industries, multiple industries areas. So traditionally, asset exchange means equal to money exchange, but today in this area is not only money exchange, but also formless value such as NFT or environmental value or something. So interoperability is an essential piece to achieve this exchange formless value. Great. So hopefully now you guys all know what interoperability is, so we can base our kind of future questions and answers based on that. So I know when we at Accenture originally contributed Cactus with Fujitsu, part of the contribution was around the overlay network that we had within the two separate blockchain networks that we were trying to interoperate against. So Takuma, tell me how has Cactus changed and what is Cactus today as we look at the project as it stands? Yeah, thank you. So as you know, the Cactus is... So last month, the Cactus became version one and in three days before, the Cactus became the Cactus with Weaver. And so in my understanding, the version one is not the goal, but only the start point because there is a lot of... There are many blockchain interface today. So I think the interpreter user is very confused because what are you... What two should I use? So in order to break this situation, I think it is the merging of the interoperability project is very important. So firstly, Weaver and Cactus is merged to the one project in this time. Great. And Rama, tell us what Weaver brought to Cactus. Okay, so... Or I should say now Cactus. Can you tell me about it? But what did Weaver bring into Cactus? So the Weaver design philosophy as we envisioned it was involved keeping... Weaver sort of value add to any existing network. So what we wanted to do explicitly was to avoid having... Avoid the networks having to fork the DIT stack that they were building on and to avoid adding any components that would increase the trust footprint because any blockchain network is a really complex beast and there are a lot of... There could be a lot of vulnerabilities in any blockchain network. I think... I don't know how many people have done security analysis, but Fabric Network can be a... For example, can be a security analyst nightmare with ordering servers, with so many peers in different roles and so on. So what we wanted to do explicitly was to avoid adding anything that could increase the vulnerability of a network. So we introduced components called relays, which you can also think of as gateways of the kind that Raphael and Denakaran talked about in the previous session, which act as conduits or ingress and egress points for any network for cross-network communication. Again, when I say cross-network communication, it's communication with any external entity, the other side could just be a centralized entity as well. And second, the protocol units that are behind the relays in the networks, they are engineered according to the native smart contract or distributed application logic of that particular network. So like in Fabric, the end, whatever the network does, it does via chain code. So it does it the same... any transaction processes as part of a cross-network transaction is going to be endorsed and ordered and committed just the way any other Fabric transaction is. And that allows us to have any cross-network transaction be as decentralized and as trustworthy as any of that network's native transaction. And the relays that are going to communicate messages, they need to confirm to some kind of standard that other relays can talk to, but they are not going to be trusted for any other purpose. So in our protocols, the relays are not trusted for confidentiality nor for integrity. So relays cannot mount when the middle attacks, for example, nor can they exfiltrate data. So these were some of the... these two components are what I'll mainly highlight, the relays and the interoperational modules as being a big value add when it comes to maintaining... to performing secure cross-network transactions with adequate level of decentralization. Great. Thanks. So tell us about UE and how it differs from what you've heard of this description here in cacti. Obviously also with the research that you've done previously with the work that's being done in cacti. Yeah. So as I understand it, one of the great features about cactus or cacti is that it has a pluggable architecture. So it adopts any type of interoperability, including notary scheme, hash locking, or relay scheme we've attached. And that goes the same way for the messaging layer as well. So developers can bring their own protocols for messaging layer in cacti. But at Data Chain, we believe the relay and light client method is the most secure and the most feasible option for even in enterprise settings. So there was don't trust, verify, go. So also we adopts the IBC, Interblock Chain Communication Protocol, which has several characteristics like reliable transport, authentication, and ordering, which enable the general cross-chain applications. So I think the cacti conceptually is a very generalized framework for blockchain integration, whereas the UE is putting more focus on the communication with a set of concrete protocols and specifications. So not to put you on the spot, Susumu, but I'm going to anyway. UE, do you ever see it integrating and coming into cacti, right? That's a good question. And as I mentioned before, that cacti is very generalized framework and UE is very specific to communication with a concrete protocol. So one can imagine the combination of two. For example, cacti with plug-in of UE installed. But unfortunately, as far as I know, there is no specific customers who would like to have two technologies into one place. So suddenly I must admit that we are not currently working on cacti integration. But to me, it would be very exciting to see developer communities can work on the UE plug-in for cacti. Great. Thank you for allowing me to put you on the spot. And thank you for the honest answer, right? I think it's important for us to recognize that there are many different ways of doing interoperability and that sometimes they don't interoperate to say that poorly. But anyway, I guess the next question, Takuma, you had mentioned the version 1.0 for cactis. Talk to us about what you see in the roadmap for 2.0 for cacti. Yeah, so cacti version 2.0 is, of course, the version, the technology of cactis and cacti. So to be honest, we are now designing the roadmap of the version 2.0. So we are the merging of the cacti. So I think it is needed to sort of the device in the existing cacti. In cacti, we have architecture and API and some features. So I'd like to go forward too. I'd like to make a better interoperability tool than the current now. So we are now sort of revising the architecture of some things and we are now making the roadmap. So the roadmap is fixed. So we will announce it later. Yeah, thank you. OK. There's still being work done as far as what's going to happen. Any sort of specific work that you'd like to see go into that roadmap when it comes to adding weaver into cacti and the version 2.0 for cacti? I think I'll just be happy with the platform that looks coherent where we can point to, OK, here's the common substrate on which we can provide a spectrum of features for, let's say, the validator modules, which are somewhat different in cactus and weaver. If you can bring them all together and then build a base on which we can then go and have people develop more new features, support relays, and different kinds of plugins, like UE plugins, I'll be happy with that as the next iteration. Apart from that, yeah. I mean, in weaver we have been working on some other features that still remains. I think we will continue to work on those after the merge as part of cacti. You want to tell us about what those features are? Sure. Yeah, actively, I mean, we've been working on adding decentralized identity support as a trust enabler for two permission networks. I think it's more crucial for permission networks to have that. So this is something that we have published in research and there's a grad student who's been working with us on this for a couple of years now. There's a POC build, but we haven't yet fully built this into weaver. So I guess we are working on one portion of that right now. I think we'll get that done before the merge into cacti. But after that happens, I think we will offer a solution involving dead registries. It's sort of a more ambitious thing, because the way we're building it for the solution to work and be adopted in the industry requires a lot of purchase. And I think there have been a lot of presentations on decentralized identity. So it's not quite a settled topic yet. And I think even the W3C recommended the drafts just reached recommendation status just a couple of months ago. So I think both of these things are going to go hand in hand. The evolution of decentralized identity and blockchain interoperability. But I think there's some biases there. Both are crucial to each other. Great. Thank you. Susumu, what interesting and new features are you working on within Ui? Yeah. So light client-to-lead as I mentioned before is arguably the most secure way for interoperability. And at the same time, we see a lot of hacks, especially in a public space with a simple notary scheme. So by the way, that I think represents the difficulty of having trusted third party for exchanging information. Anyway, light client and relay is also said to be difficult. And the on-chain verification process requires computational cost and block size. So we are right now working on the LCP, which stands for light client proxy, which is a combination of Ui, IBC, and security enhanced hardware. So what it basically does is that we substitute the on-chain verification process to the security enhanced hardware. So without sacrificing the trust minimized assumption thanks to remote attestation technology. Currently we are working on LCP to apply to enterprise stablecoin and security token DVP swap later this year. Also we are considering applying LCP to build a bridge between Ethereum 2 to EVM-based public blockchain. So we can provide the interoperability not only within the enterprise blockchains, but also with a combination of public and enterprise blockchains. So I think we can hopefully share more information than the lessons learned in the coming months. Great. So Rama, back to you. Tell us about kind of the process of bringing the Weaver code and merging it with Cactus to create Cacti. What was that like? How challenging was that? Just tell us about the process. The challenge shall continue. We've been having almost weekly meetings for several months and thanks to Peter, Sakuma, and the rest of the Cactus team for being so cooperative. Initially we started just doing a deep dive into each other's designs and code bases. We have a kind of vision and I think we are still aligning with that vision which is that there are cross network communication elements that we can kind of merge together into a sort of communication appliance. I think the Weaver relay which Peter who unfortunately could not be here did some investigation on this and he found that the relay could be embedded into a Cactus connector and that could be used as sort of a communication appliance for network. There's something that we're going to talk more about standards which Dinakar and Rafail talked about. This sort of appliance can and should confirm to standards that I agreed upon by the community. So we have communication elements that we can merge. There are the inter-operation modules that Weaver brings which are really the equivalent to the validators that Cactus provides. They have somewhat different philosophies when it comes to generating data state proofs or validating state proofs. So there are reasons to pick one or the other in a given scenario. There's a spectrum of different solutions that one could envision using in production. Some which involve more security or less trust in particular components. Some which involve better usability or less adaptation required in the network that's already deployed. So we want to offer those kind of features or different kind of validation logics as a factor or a set of possible options. And then we want to merge the APIs and the libraries that Cactus and Weaver have respectively built for developers to exercise or to trigger any crossover transaction. And that we can merge and offer as a single unified API which you can use which any user of Cactus API can use and trigger a particular kind of transaction. And these transactions will come in particular types like asset swaps or transferring of asset from one network to another or the communication of a legislative record from one ledger to another. So there are some things that we are working on merging other things which we are working on aggregating and hopefully that will bring to put together a common coherent platform. Someone's down the line I think. All right, thank you. And shout out to Peter if you're watching either on the recorded video or live. We miss you here. We wish you were up here with us. He was supposed to be here with us. So just wanted to call him out as Ramva did as well. So Takuma, question for you. Is there any business proof of concepts that are currently using Cactus API? So there are several proof of concept cases. So first case is environmental. So this is introduced in today's afternoon session. So now this is using cacti2, the taco, the environmental issue. So the connecting to the environmental value and the CO2 accounting. So this is the POC with IHI, the Japanese heavy industry company. And the second POC is the cross-border financial. So this is POC with Asian Bank and so the four blockchain companies are collaboration. So consensus in R3 and the Soramitsu and Fujitsu. So this is the cross-border banking is the second example. And also the cacti provides some example code on several areas such as the supply chain or carbon accounting and so the cart rate and power trade. So I think this is the key to the considering about the new use case. Thank you. Thank you. So Susumu, it wasn't a question on the piece of paper but any sort of use cases that you can talk about that exist for UE and how it's being used today? Yeah. So as I mentioned before, you can be used for general cross-chain application but the demand is from the token transfer right now, just token transfer. So DPP of digital assets, we did with entity data, Japanese system integrator about the connecting trade platform to the payment platform. So we can change the asset ownership on one side and the payment is done on the other. Also we did some experiment with the JCB, Japanese credit card brand with multiple stable coin platforms and basically we would like to exchange the two different kinds of stable coins via liquidity and atomic swap. So these are the things I can share right now and hopefully we will see the application of general cross-chain application. Thank you. Rama, I think yesterday you said you couldn't share those things that you're working on. Okay, there's one. I don't think I need to talk too much about it because if you plan to attend the token workshop tomorrow, you'll get a much longer and more a bigger exposition of that. So do it in that. Just in a nutshell, there was an experiment done by the Bank of France and HSBC together that involved networks built on both fabric and Corda, either running, one of the networks was running, was managing securities like bonds and another was managing CBDC and there were a variety of use cases that involved the two networks having to interoperate either to do interbank settlements to enable coupons to be redeemed across network boundaries and for, yeah, I mean, the case that Susumu mentioned earlier, DDP, which is a delivery of a bond versus a payment on a different network. So what we've seen in the past year and which has driven interest in Beaver and actually in other platforms like Cactus and Imagine UE is CBDC, Central Bank Digital Currency because the very central banks as well as the other retail banks that are regulated by the central banks are really interested in how they can use how they can adopt CBDC for more efficiency but how also can they make it easy for the different platforms like the wholesale CBDC networks and the retail CBDC networks to work together. So you're going to have different networks, they need to interoperate, so they're shopping for different kinds of solutions and Beaver was part of one such experiment last year. There are a few that are ongoing this year which unfortunately I cannot talk about but hopefully soon. Okay, great. So as far as contributing to these projects, I know for Cacti, there are daily pair programming calls that are held, there's weekly calls that are held with the maintainers, obviously good first issues, those sorts of things, anything else, either Takuma or Ramla, you would add on contributing to Cacti and how the people here in the audience or the people watching on the video could participate in the project. Start with you, Takuma. Anything that you would add as far as ways that people can come in and contribute to Cacti? Yeah, so after becoming Cacti, we are always waiting in Discord and so your contacts, please feel free to contact. Discord. Discord, yeah. Great. Ramla, anything else you'd add? Not really, I think one of the benefits of bringing you with Cacti is we can grow our community otherwise it's been mostly an IBM project so far. So it's great to have the, you automatically gain a bigger community by joining with Cacti. So Sumu, how do we contribute to UE? What is the way to get involved and participate in what you guys are doing there with UE? Unfortunately, we don't have the regular community call or discussion like Cacti, but yeah, we are always open to the contribution from developers so please visit GitHub and I think there is very detailed documents right now so that you can start coding soon. So yeah, please visit the GitHub page. So that's all the questions on my piece of paper. Questions that any of the audience members has. There's a microphone there in the center if you have a question for any of the panelists here. Charles from here. So the question I have is with the Cacti is there any questions that you have about Cacti? No. No. No. No. No. So with the Cacti flexibility, it can do everything. Do you see it staying at that level or do you see a handful of things like UE perhaps different things but more specific applications being developed or do you see that people will just take Cacti and use it, adapt it to their own project and that will be the end of that thing. Rama, you want to start? The question makes sense. Yeah. I think you're asking if Cacti is sort of a jack-of-all-trades and will UE as a specialized project? I mean, yeah. So, okay. The way I see it is when we're building Cacti, we're not offering a very blunt hammer that can hit any nail. It's more like we are clearly defining what use cases we are solving. How the protocols that we are providing or the capabilities we are providing in Weaver solve the problem for you in a way that maintains both decentralization and does not expand your footprint of trust and it's, again, there's usability which we are still working on but assuming you provide that then it should really be quite easy for you to take the Cacti SDK and then import the components that you need to configure them, use the library packages, and then adapt your applications in a very minimal way in order to engineer the application. It's very similar to how you would use, say, Firefly because Firefly offers a good developer experience and but even there, I imagine you have to adapt your client applications to confirm to import the Firefly packages, right? So that will be there and we are going to make our best effort to add all the features at the right granularity that can be used by any distributed application that needs cross-chain communication or cross-chain transactions. So I think I didn't actually express my question very well. I didn't think I did when I was asking. But the question is really, do you anticipate seeing a handful of labs project, perhaps, like UI, three or four things that are... Here is a pre-configured preset up. We've taken the SDKs, we've done the adaptation work, we've set it up for a particular kind of use case or approach and lots of enterprises will pick up that rather than... Or do you see enterprises developing their own solution each time? So will there be patterns that are developed that people can just pick up and use as they exist for their particular use case? So will there be a pattern for interoperability type X or interoperability type Y that people can say, OK, this has already been done once? I can use it again and write out a box. I don't see the difference between a platform on that dimension. I think it's more about... UI is great if your network already is compatible with IBC and you want to be able to interoperable with another network that's also talking IBC. What in Weaver and Cactus we are offering is the ability to be interoperable if you are not. If you have not thought about interoperability at all, suddenly you discover there's a case, there's a reason for you to link to a different network, what kind of solution can you use? You can of course pick, choose to, let's say be part of the Cosmos ecosystem, build importer, run a relayer that talks IBC protocol like UI provides, that's a valid way of doing it. Cactus and Weaver offer a slightly different approach that we don't require you to talk the IBC protocol but you have to install a relay that can talk its own protocol which again we are trying to promote standardization of that API but that's some ways to go now. Thank you. Thanks, Charles. Yeah. It could be a repository of different types of protocols and different use cases using those, in this case the application, the higher level using these protocols. At which point it becomes unmanageable and as a single project there's something you'll have to use. Maybe that's your question, right? Will it be a single hammer that will be used for all interoperability applications or you'll have custom things based on some base layer protocols? Yeah, I think that gets out of it. It's basically we'll cactus. You can use cactus to make a lot of hammers. We'll cactus, you know, provide a hammer shop with a collection of those hammers that have been made. Will you manage those as projects or will you just say no? You go and do your own, someone else can handle that. If someone has done what you need, go find them and copy their work. Yeah. Or will that be managed by cactus as a user? Sorry, I don't want to monopolise this, but... Yeah, yeah, yeah, sorry. Okay. So monorepoise, so based on the NPM structure, so this can be combinations, so not only the type escape, but also the term last or another language. So basically, so cactus is written in type escape and Viva is written in... Viva relay is written in... Sorry, last, but we can coordinate with so the monorepoise structure, yeah. So I think one thing which you alluded to earlier was interoperability among interoperability solutions. So this... And we talked about this in the member summit a couple of days ago. There are several interoperability solutions that sprung up in response to the need for interoperability. Now what do we do? Do we try to make these interoperability solutions interoperable when there's like turtle all the way up or down, right? So what do we do? I think I don't have a good answer to this, but I think there are certain... As long as you have a limited number of such interoperability solutions that all solve the problems, that cover the problem spectrum that anybody needs. And I think both Cosmos and Viva, Cactus, combination, they do... they solve all the range of problems that you need. If not, in practice right now, they will because it's part of their vision. So I think you can use any of those solutions. What you may need is the ability to interoperate with the limited number of such solutions. Like the Susumu mentioned, a UV plugin within cacti or a Polkadot bridge within cacti. So these are the kinds of things. As long as you have them, I think if your network is already using a particular interop solution, you need not fear about being able to interoperate with another network. So I know we're at time. Just to call it out before you ask your question. So feel free to, if you need to, leave. But I do want to say, Charles, just to your question, if you have a hammer you'd like to sell, there is the lab proposals that you can do, obviously, to bring that code to make it open source. And I think that's definitely a worthwhile avenue to approach selling of that hammer. No, I understand. But I want to make sure that everybody is aware. You can contribute to a lab. And then at some point, if we decide that it makes sense to bring that hammer into cacti, then we can do that. And it's just then a discussion of, well, here's the source code, here's how it's going to fit and make that happen. So last question to Rafael. I think the more hammers the better, at least in any initial stage. It probably comes down to the trade-offs between blockchains. There will always be more than one blockchain due to the trade-offs of feature, digitalization, security, scalability that they have. And I believe something similar could happen with interoperability solution, especially if we consider that those are often used for scalability purposes as well. So not really a question, but perhaps a comment. Possibly we'll have interoperability solutions with different trade-offs such as decentralization that are not captured right now by these more generic frameworks like cacti or more specific frameworks like UE. And probably upcoming standards will also have a saying on which ones are more easily adaptable to the market needs and to regulate their needs. So I would also like to have an answer for that or to know an answer for that, but I think it's something we are trying to discover on the way. Thank you, Rafael. Thank you. Thank you to all that attended here, hopefully the three people who raised their hand at the beginning actually did get something different out of this conversation. Thank you to the panelists for participating and we will let you go and have a fun for the rest of the day.


Hello, I am Dr. Bhaskar Shani, Head of the Department of Pediatrics and Chief of Division of Pediatric Infectious Diseases at Manipal Hospital, Bangalore. There are various types of vaccines. For example, there is a killed vaccine, then live attenuated vaccine, then the biological vaccines, then there are some DNA vaccines. The killed vaccine, the bacteria or virus whichever is there, we kill it and that killed the proteins or whatever content of the particular organism will produce, when it is administered to the body will produce immunity. There are other vaccines which are live, live in the sense they are attenuated, attenuated in the sense their disease producing capacity is reduced, but they are able to produce the protective antibodies in the blood. So as a consequence, the baby is protected against the disease, but protected against the doesn't cause any ill effects.


Hello, and welcome back to The Craft Box! My name is Brent and today we're in episode 270 of the Wizard101 Death Walkthrough. Last time, if you haven't checked it out already, we did the Whirlybully, we won, and we did a whole bunch of other stuff, not really actually, it was just Whirlybully and listen to dialogue. So yeah, that's what we're going to do except without the Whirlybully bit. You're back! Did you get the Stormy? Good. Take it over to my hut to wake up the Okie dokie, we wake up and do just a car. Let us discuss matters. We are going to leave a mark here because I know, I just have a feeling we're going to be coming back soon, so we'll do that. Sounds good, I might also just turn that up, just a tad. Hi. Yes, correct. Look after the just a car, you go battle Blue Oxen to draw out their masters. The Ark Anxious, repeat. Hi, I missed that bit. I wasn't expecting there to be dialogue, I completely forgot about it, but it says Oxalarm, Oxalarm. This is your helpful loud Oxalarm, the Oxen Anxious, repeat, smash. So that's the thing, we are following the alarms into this place. Welcome back by the way, my name is Brent and we are still doing the same thing as before, speaking to people and defeating things. Welcome to Wizard101. Let's defeat these dark cloud boys. Hi. Who's that? Kingsile, I think you're using a swear in the game. I don't appreciate this language. This is like a PG-12 game. This is way too high language for this. Anyway, we'll be back in just a bit once we have defeated these frustratingly annoying dark cloud agents. Again, haha. Hello, I'm back. Welcome. We are killing 99.999% sure we are killing. Yup, they're dead. Easy boys, easy, so easy. The one time I tried to blade, they did dissolve me, so that's fun. Shush, shush. We must work together. I don't know why pork's so upset about that. I am kind of confused. Also, what is this? What is this way?  Okay, that's interesting. Well, let's go to the next room. Oh, look, Cabal. That's great to see. I love seeing that. Those banners, they are Cabal, but I thought we defeated them in Sepidias. This poses so many questions. Why is the Cabal here? Are they in league with the dark cloud? Why do secret organizations always have such great branding? That last one is such a good question, like seriously. So intruders like you know who's destroying them. Is that you? What? I'll be back once I've defeated these guys, probably just about the same fight as before, except with pork this time. So yeah, I'll be back in a sec. Okay, I am back. Back again. We are killing with my friend Lulu. Yeah, I tried to blade and they took it away, but that's fine. Just take, take, take all the time. It's whatever though. We killed, it's fine. We won. We got full health basically, so we good for the next fight, which is going to be a bit scary. This is the same voice actor who voiced the prawn, the evil prawn in Pirate 101, can confirm. Okay, well, the boss is just up ahead, so we're going to ask her what she knows. Just kidding, this boss is frustratingly painful and I don't want to fight it, but it's fine. It cheats, which is great. Dr. Demented. No, she will cast a fortify, and if you beguile a minion, she'll cast a minus 80 fortify, which will return back to 60 once beguile ends. Those auras cannot be destroyed by supernova.  Just sometimes, you know, it doesn't actually say when, just occasionally. Whenever she feels like it. Because that is exciting and great, great, great gameplay design, but you know that's fine. Let's put in some of these, we got some prisms. How delightful. And the wizard, ah, we knew you would come, but you are, alas, too late. Hardly too late. We know your diabolical plan. We forced it out of your stuges. We know you're trying to drive the Nimbari crazy with fear. Yes, the admiral's grand scheme. I do hope it's working for him. Truth be told, I just wanted this chance to study the myth and storm chain. Raw creativity entwined with the chaos of destruction. What marvelous horrors it can make. Now I wonder, Captain Bork, what are your fears? Captain Jean-Luc Pencard here, ready to engage.  Oh no, no, no. I'm a rock cat. No, there's something on the thing, wizard. I'm frozen with fear, paralyzed by unspeakable dread trapped. Um, okay, we've got the fear of being surpassed, the fear of the future and fear of gremlins. That's an interesting fear that Pork has. But as I said previously, we need to destroy his fears quickly before, you know, before we can actually do good damage to it.  It doesn't say ice, so that's the thing, but you know, we will see. The myth, I'm assuming, I'm assuming the resist is pretty similar for the fear of being surpassed, which is the ice has a boost to fire, a resist to ice. The myth one has a boost to storm, a resist to death. And the life one has a boost to death and a 40% resist to life. So yeah, and also it can cast pixies, so that's exciting for you. We really need a blade before we head somewhere, we're gonna wait for that. Just hit blade and then deonite is probably the best option for me.  Okay, you don't need anymore, you're gonna kill me.  Do not like that at all. Um, okay, that was not really what I was after. We're gonna deonite anyway. This could do some damage, some. It won't kill, but it'll do some damage.  Plus all of its resist, yeah, 177. Really great damage there. Highly would recommend to get more of that damage there. Would have been great if we had a blade. We do have another deonite, so we can deonite again. Um, I'm probably gonna save up for a mortis on the boss. Or a sign of death as it's actually called. 54 damage. Whoo, so good. So good, look at me go. Look at me go. Wow, just as well I hit before that. Just kidding, we have so many cleanses, it's fine. Is this a shield? Okay. That's just cheeky. That is just cheeky. I do not appreciate that at all. What is this, a shatter? Earthquake. Okay, we don't need to worry about that cleanse anymore. Thank you so much. Thank you so much, game. I appreciate you. Cause this should get off, it does. And all of the traps as well. It's a bit weird how it takes off all of the things that like, the minions will actually use quite a lot. Um, you know, whatever, it's fine. It is fine. Double pip gain and conserve the pip. Wow, you good or something? Jeez. Um, okay, we got a faint, which is interesting. We didn't actually need that. I mean, a potent. Um, we got a shadow pip, which is cool. We got a Lulu now, which is great. However, I would love a, um, a blade. A singular blade, just one blade. So I can blade and then Lulu and everybody should be dead. That would be great. That natural attack is kind of cool. Not gonna lie. Also because I need health as well and want to kill the minions at the same time. So it'd be great if we could get a blade. Yeah, that would be fantastic. Really, really would be appreciative. Um, also I just realized we got Mass Prism, which is probably not the best idea. Um, because it means we cannot do it. And also we would be wasting two. Wasting, um, two pips instead of none. So not the best. Don't. Why are you healing? It's not cool. I do not appreciate this. This is not, why would you crit as well? Stop it. This is no. No. No. No, put it back.  Stop it. Stop it, gremlin. You're not cool. You're bad, mate. You're bad. Um, still waiting for that blade. I just want one blade. Just a singular blade would be great. Would be really, really great to have a singular blade. I don't care if you do. Okay, that's fine. Hopefully, I mean we can always cleanse, so it's whatever, really. It's, it's okay. We can cleanse. Not worried to do that. Um, unless you earthquake me, I would be appreciative of that as well. That would be kind of cool. Except you can't do that now.  Why would you use up all your pips? I'm not an earthquake. I thought myth loved earthquake. Like seriously. And also, why is the future myth? I'm kind of confused about that. Is it because the future's like, not a thing anymore? Like it's like a myth? Like you don't know what the future would be? I don't know. It's weird. Gained two power pips. Okay, that's not cool. Um, hmm, hmm, okay. Okay, we're in a slight pickle. We're going to discard the Lulu, just to draw a cleanse charm. Also, because we need to discard something, because we still haven't got one blade. We have four, and we haven't gotten a single one. It's ridiculous.   Like, just take it away. I don't need to wait five million years for it to take it away. I just want it to be taken away, Kingsile. Why would you change that? It was so nice before. Just took it away, and now you have to have a silly animation. It's not even a cool animation. Like it's a bad animation. It just does nothing. So, I mean, it's just basically the same as before. Except longer. Why? It doesn't make sense. Okay, we're stunned. That's cool. That's whatever. I don't really care. You know what? You stunned me all you want. I don't care. At all. Do not care. Okay. Um, can we get a blade? Finally, a blade. We're going to enchant it as well. Just because I want this thing dead, and also we need health. Because this is going to do, yeah, just a tad. Just a tad. Also, Dr. Demented's now got a Shadowpip, which means it can do, um, it can do either a scorching skimatars, um, or a Lulu. Either one, I don't want to see. I just don't. So, you know, it's just how we're going to have to, like, stop it. Even though we can't, because it's going to happen. It's either going to be a Lulu or a scorching skimatars this round. So, yeah, we are going to blade. Because we can now, finally. Um, and we'll hit with a Lulu next, and all should be good. All should be much better, and we should be alive. Except we may be dead because of scorching. So, who knows? Because scorching does a fricking fric- fric- fric- ton. Does a lot. Does a lot of damage. So, um, okay. Weird. Cleanse, maybe. I don't know. Or Pierce, I don't know. At least, it might be a Lulu that she's going to cast. Or it could still be a scorching. Who knows? We will find out in just a second. Um, because I bet it's going to be this round. Which is lucky it wasn't last. Because really, we were not prepared for last round at all. We were not prepared. We would have died. We would have died. This way, we actually have full health. Probably, right? Right, we have full health. Can we crit at least? That would be so good. That would be so satisfying if we could crit this. Nope, of course not. Okay, that's fine. Whatever. I didn't need to crit anyway. It's still going to kill. It's still going to kill, right? That was close. Maybe not killed. Possibly not killed. Um, hmm. Yup. Did not kill. That's great. I love this. Oh, it was a scorching. Wow. What a surprise. I mean, it was a 50-50 chance. If you get scorching, you get, um, you get a, um, you get, I don't know what you get. You get to feel good about yourself. This could kill me. This legitimately could kill me. Okay, good. It did not kill me. It did half my health, you know? I'm back down to exactly the same amount of health as I was previously. Yeah, okay. And earthquake, of course. I mean, it doesn't really matter. You did it at the wrong point. Sorry, but you're bad. You're bad, mate. You're bad.  Like, seriously. That was the worst idea ever. Like, you ruined that dot as well. Like, if you wanted to kill me, you're doing a bad job at it.  Doing trash, mate. Um, I don't know how big of the absorb is. I really wish you could see how big the absorb is. And we also discarded the, um, yeah, this is not looking, this is not looking good at all. This is not looking good. Well, so where are all our blades? Like, seriously? Why have we not got any blades? And where is my reshuffle? Because I have a feeling that I don't know where things are. And I'm slightly panicking because it looked like there was not nine cards there. Did not look like nine. I could be, I could be miscalculating, but did not look like there was nine. Please die. Thank you. Please die. Please break the absorb at least. Yes, thank you so much. You're dead. So good. So good. Oh, look at that. Did so much. Like, nothing on that absorb. So good. Okay. Well, at least the fortify's off. We can now blade up and faint and stuff until we get a... Oh, there was nine. Okay. Don't worry. Don't worry. We can discard that. We don't need that anymore. Oh, my gosh.  You have overcome your fears. No, never. Except now I'm probably dead. Why would you supernova yourself? Like, what? That's a bit weird. You just do that damage yourself and treat. Why did I do that? Why? I swear I am like bad sometimes. Oh, this is the Lulu. Yep. Okay. It doesn't really matter. This won't do too much. Actually, I mean, with a crit, this could do how much? It doesn't have any outgoing, which is good. It is good when it doesn't have any outgoing, so it won't do too much. Yeah, not too much. And I don't care about the heal. That can do whatever. We nearly did those.   Because Mortis is a god. Because we can actually do that and win. And get the double and do really well. And get all of the health back as well. So it's good. It's good, good, good. Yeah, you pass. We are going to go for one of these into a faint. I really need to save more pips. Legitimately, we need to save pips at this point, but it's fine. We'll do this into probably a faint. Yeah, just keep passing. Don't get a shadowpip. Damn it.  We can hit next, I think. Right? 2, 4, 6, 8, 10. Yeah, we can hit next. We can hit next. And all should be good, right? As long as it doesn't kill me right now. Because a skimatars will kill. As a skimatars.   I don't like you. Dr. Demented, you're bad.  You're trash, mate. I don't appreciate this. I do not appreciate this. Why would you do this to me? And you didn't even need a crit. Just stop. Oh my gosh. We did so well. Oh, I'm mad. I'm salty. Not gonna lie. Okay, I'll be back when I'm actually killing. Okay, I am back. This has been forever since the last time I pressed the record button. This is what, like our sixth try, I swear. Yeah, we're finally doing it. Finally. Only took 5 million years. We even crit. Oh my gosh. Wow, aren't we lucky? Aren't we just so lucky? Yeah. Yeah, the stars kind of aligned in this one. Not gonna lie. But I mean, you deserve that. Heaps of damage that I just did to you. Because you're bad.  I don't like you. Dr. Demented, isn't I?  The jig is up, you devilish wielder of personal demons. Now tell us, what does this admiral character want with the Nimbari? Fine. As you know, we are making them afraid of dark cloud attacks, of miss monsters, etc. Because when they get nervous, they make weapons. Such delightfully fiendish weapons, including a large storm cannon. The admiral has need of it in his newest scheme that is all I care to know. Hmm, hmm, hmm, wizard, let's meet outside. Okay, let's go talk to pork and then we're gonna end off the episode because it's been like two hours nearly for me recording this. So that's great. Yup, god love it. Haha, yup. Love this game sometimes. Pork, please load. Okay. Oh, frick me. Ugh. Ugh, how far away is it? Oh, this is gonna be forever away. Are we gonna have to leave on yet another cliffhanger? Find out what happens when we talk to pork next time because this always happens to me. Is that where we're really gonna have to end? How far away is he? If we go out here, how far away? If he's too far away, we will do it next time. But um, I would prefer not to. You know, I would just prefer not to do that. Would prefer not to do that. 300 away. Is it worth talking to him? I think it is. Even though we probably don't get the XP yet, we're gonna talk to him anyway because that's what I want to do. Um, and you know, it's fine. We can do that and still get this video edited and stuff before I sleep. But that's fine. That's fine. Um, I don't want to get caught by the meows. They're not cool. They're not cool. The meows are evil. I do not like them at all. Not one bit, no. They are bad. Um, where is he? Just over here? Please? Yes, just over here. Look at him. Hello, pork. Speak. Okay, so that's where we'll be going next time. Thank you for watching. Remember to like and subscribe if you haven't already. Press the little bell so you know exactly when I post another video. Remember crafts outside the box.


Everybody for us here been 2022 Spectre intelligence football hobby 4 box mixer number 10. You could check the random results right here any time late sports cars calm as well So let's go ahead and get started. Yeah, I'm not yeah I have the only I've only been on like maybe two or three one roller coasters There is one at Hershey Park that I went on I don't even know the name of it And then there was a what was it glossy before they took it out of a where they took it out of a Wish gardens Tampa. Yeah, which good riddance. See you later. I don't care about wazzy. Don't miss it All right two illusions two Spectre. Good luck Nice black ice to 50 James Conner for the Cardinals of the black ice a steep zappy Right here some Funkadelics What Funkadelic? Yeah, I'll call it what it is rookie patch to 75 Kyle Hamilton for the Ravens Franchise numbers autograph Jonathan Ogden for the Ravens. That's pretty cool Ogden auto Ravens 399 Derek Henry for the Titans Niners Danny Gray rookie endorsements auto to 99 Bill Parcells. There's some crazy autos in this one elusive ink to 25 for the Giants That is a an Ogden and a Parcells auto Very interesting Yellow diamond a 299 Bengals Joe mix it with a Debo Samuel illusionist to that 399 for the Sorry. Yeah, 399 for the Niners there. I was right Aaron Donald to 199 Rams Mystique Tremac bride to 399 Cardinals Illegal sounds like he has sued if I'm using part before Falcons desperate or rookie Jersey Guard Caffrey to 499 Kyle Pitts Falcons Mystique Rikki's a mere white 299 for the Raiders. Yeah, that's a nervous. That's a nervous ha ha That's what that is Kings Dominion, yeah, I'll go there one day maybe 299 AJ Brown the Eagles mystique Isaiah Spiller to 199 chargers It's the places like that aren't Universal or Disney I feel like or like the more dangerous ones Jameson Williams rookie patch for the Lions to 99 Johan Dotson commanders in the auto to 75 nice red card there Cool color match it's a 399 cordial Patterson Falcons illusionist London movies playing shortstop tonight Got an Echler Jersey card for the chargers here that could have had highlights watches It's neither. It's just surprising Rookie to 199 George Pickens for the Steelers Johan Dotson number to 399 commanders Mookie like you do it all kind of player or apparently so cowboys fan Evan Jamal Charles on the patch auto look at that dirty patch to 25 chiefs. Yeah, that's player worn. Maybe I'm thinking that's game one. He has some game one stuff at other things. That just has player worn though nine at 25 chiefs patch auto Some cool hits in the illusions Mark Andrews at 35 Ravens mystique doesn't ridder To 149 sheeps on the rookie vision auto sky more Kenny pick it amazing to 499 Kyle Pitts Falcons and mystique Wanda Robinson to 25 Giants, all right spectrum time Okay Josh Allen Jersey card for the bills. I don't know why I put the base on the back. That's that's dumb I've got a K. Dwork rookie for the For the Browns of 99 a base chase Johan Dotson at 25 on the aspiring pink rookie RPA or rookie patch auto Rookie RPA our RPA is what that would be. There you go. Dotson commanders. Nice card Got Terry McLaurin die cut to 30 for the commanders as well now Smirky Spectres bills James Cook to 25 Brian Robinson junior to 10 triple patch Manders having a great box here and cave on tip it out to 99 rookie auto Giants Phyllis Jones rookie to 60 for the Bears, you know what you sound like 2,500 points Rams everybody at the end. I just I just know it It's a good chunk of points. Oh geez Sam. I'm not I'm not aware Carl at this rookie. No, and it's like what Thornton is 75 rookie patch for the Patriots Got Keenan Allen chargers number to 25 DK silver They all would Ross St. Brown the 99 Jersey card Lions and a son Haskins Titans RPA to 75 Don don't know don't don't know. I don't like that owner of the Don Don's Dale Jimmy just Maybe I have Done I tried the voice a few times beforehand just a few just a few Maybe I only talked to my my family like that. They think it's they think it's my actual voice I may have recorded myself and played it back and tried All right, five to go on Star Wars six series every spot hits Clap clap clap. So that's bulby. That's not that's not that's not uh, that's not Carl. It's bulby Slap slap slap clap clap clap for an exchange student. Oh Okay, he's from whatever European country they say he's from The 75 James Winston Saints Rookie Spectress Alec Pierce Colts to 50 the 75 Kyler Murray Jersey card cardinals and Buccaneers champion signatures Devin white. I'm gonna look it up right now real quick. I'm not gonna say that Yeah, I'm not gonna say You guys Sam Howard Rookie to 64 the commanders Darius Tony To eight Colts Alec Pierce triple patch neon splatter parallel Trey McBride to 99 on the rookie patch auto for the Cardinals Posted them Rookie drum for it for the Browns It is a tough one. They're both pretty they're both free solid. There was more like subliminal subliminal humor in a And Jimmy Neutron for sure Derek Stingley Ricky silver tech since you've got Eckhart to 99 Chargers Jersey card high voltage Inviting rookie out of the 35 Lewis scene very good Charles Woodson to 20 for the Raiders Donnie Phantom Yeah, I was better stretched you Michael Vic. We've got this the 15 rookie dual patch Lions in Hutchinson and when you know we got back-to-back Hutchis here purple Radiance RPA There you go Lions Congrats on that. What is your gap a gap? it's like Alright random time for 25 hundo points, that's a chunk of points right there y'all. That's a good amount Good luck on this one four and three seven times Wherever's up top is taking those taking those home one two three four five six and Seven jets Jets on the top Alright relics you've got hutch Echler Alec Pierce Kyler Murray Josh Allen almond Ross St. Brown Taekwondo Thornton Brian Robinson jr Echler Jamo Desmond Redder and Kyle Hamilton Bismarck he shows up on the cast of what show Yo Gabba Gabba Autos of hutch purple RPA very nice Got lewis scene Trey McBride Devin white Hassan Haskins Johan Dotson of the pink RPA cave on tibetoe Skymore Jamal Charles on the patch auto Johan Dotson a bill Parcells for the Giants Danny Gray and a Jonathan Ogden for the Ravens Thanks again everybody. We are on to