 Awesome. All right. Well, I guess it's time for us to get started. So thank you, everybody, for coming today. My name is Hartmont Gummary, and I work for Hyperledger, and I'm going to be talking about decentralization and why open source development is essential for blockchain. So let's get started. If we're going to talk about decentralization, we obviously have to define it. So as many of you are probably aware, we define decentralization as the degree to which a single entity or group of entities control something. And you can obviously measure this in a wide variety of different ways, right? It could be measured as the largest proportion of control by any single entity, the number of entities it takes to completely control a system, perhaps, or there are more complicated metrics, like blockchain people are probably familiar with the Nakamoto coefficient or other metrics of decentralization. And if you're looking for an abstraction, you can sort of think of government, right? You could have an absolute dictatorship, which is totally centralized. You could have a representative democracy, which is sort of moderately decentralized. And then you could have a direct democracy, which is totally decentralized. But there are always caveats. And even if your protocol is decentralized in theory, ideal guarantees may not translate to practice due to external factors. If you have a direct democracy where everyone follows an outside opinion, that may not be decentralized. So I'm also going to define distributed ledger. So in the blockchain community, there's a big, I guess, language issue around what's a blockchain, what's a ledger. So I'll just put some definitions forward for now. So I define a blockchain as an append-only system of record or transaction log. So this is the immutability guarantee that you're used to in something like Bitcoin. Then I define a distributed ledger as a distributed database with decentralized trust. And if you think about, again, say Bitcoin, it has that decentralized trust property that we're looking for here. Most popular blockchains are also distributed ledgers. And most popular distributed ledgers are also blockchains. So I tend to use these terms interchangeably. And most people do as well. So if we think about what popular blockchain systems are abstractly, well, they're really just distributed databases with decentralized trust. Bitcoin is sort of a distributed database for what we'll call money with decentralized trust. Ethereum is a distributed database for, I call it programs with fully decentralized trust. And Fabric, for instance, is a distributed database with partially decentralized trust. It's not necessarily as decentralized as Bitcoin or Ethereum. So today, we're going to focus on distributed ledgers rather than necessarily the immutability property of blockchains, although our discussion will certainly apply to pretty much every blockchain that you think of today. So the immutability properties of blockchain can be great for a lot of public applications, but not always for enterprise solutions. For instance, if you have GDPR regulations, immutability can be a very bad thing. So the core property we'll use today is actually decentralized trust. So what is decentralized trust? Again, if we're thinking of a database or a blockchain as sort of a store of records, who gets to decide what records belong in the database? If one person or one entity decides, then we have a very centralized database. And if many different entities decide, we have a decentralized database. And again, trust is a continuum. It's not a yes or no situation. So technically speaking, and we'll go into this in a lot more detail, the consensus algorithm is the most impactful design choice on decentralization, but there are many other choices to make. So if we have our blockchains, we sort of have a continuum of fully decentralized to fully centralized. So the most decentralized systems are things like Bitcoin, Ethereum, Cardano, Ava, these public cryptocurrencies with proof of work or proof of state consensus, slightly less decentralized are distributed ledgers with BFT consensus. And we have several of these in hyper ledger. As we get more centralized, we can think of distributed ledgers with crash fault tolerant consensus. If you're familiar with what that is, it's a little bit less resilient than before. And finally, you know, eventually we reach traditional databases which are fully centralized. So why do we want decentralized trust? What's the reason? Well, there are many possible reasons why we want decentralized trust. For instance, we could have several entities that need to agree on some data, but no single entity trusts any other entity to be the source of truth. You know, we could have a store of information that needs to be made redundant in the case of compromise or attacked by a hacker. We could have a case where the entity that would be the best sort of official source of truth for something doesn't want to or can't be responsible for the upkeep of the data. And this is very common for government applications. And finally, we could have cases where the people responsible for maintaining a data set are dynamic in change very quickly, and we sort of keep track of all the changes. So if you take away anything today, and you know, the blockchain experts in the audience probably, I'm sure already know this, but the question you should be asking is when you ask, do I need a distributed ledger? You should ask, do I need a database with decentralized trust? And you know, if you're new and this is you're just learning blockchain, this is the one point to ask. If you need decentralized trust, you need a blockchain. If you don't, then you probably don't need a blockchain. So when you think about blockchains or whether you want to use a blockchain, you want to consider sort of what's the information being stored in the database, even if it is a programmatic database, and why is having one centralized entity maintain this information a bad idea or impossible or infeasible? And this will make it easy in the future for you to determine cases, whether distributed ledger is just hype or actually necessary. And so of course, people ask all the time, you know, are there real use cases for a database with decentralized trust? And obviously, because, well, you know, the answer is yes. I really, you know, I think this has been borne out by lots of real world use cases. We've seen widespread adoption and hyperledger of applications with real world value added to existing enterprises and, you know, that aren't connected to a lot of the things you see about token speculation. And I also think they're a great real world applications of public chains, too. So I don't want to say, you know, you should ignore public chains. I think they have great use cases, but they also get obfuscated by some of the less good applications connected to token value speculation. And I'm just going to sort of display a couple of slides. Just you don't need to read everything here, but just to sort of show you how widely technology has been adopted in this space. And this is just hyperledger stuff. Obviously, there's an ocean of blockchain applications beyond hyperledger. So one of our big applications is finance. It's a great area where people want distributed databases with decentralized trust. Maybe you've been following the CBDC or the central bank digital currency landscape. And this is sort of taking the world by storm. Supply chain is another big one. And if you want, I'll be happy to explain the rationale for all these use cases after the talk. I don't have time to go into detail about them now, but feel free to ask me afterwards and I'll explain everything. And many of you, well, may know about digital identity. Have people seen digital identity applications before? Yeah, this is another great case for distributed databases with decentralized trust or essentially blockchains. So I just have a slide about distributed ledger. You know, what does it look like? Because a lot of, you know, I get asked this all the time by people who aren't familiar with blockchain. So this is the high level architecture of Beisu. We have a database layer, a smart contract layer, a consensus layer and a networking layer. And I kind of want to go through this quickly because it seems like we have a lot of people familiar in the audience with blockchain. But have people seen this kind of thing before? Are people comfortable with blockchain architecture? Yes, no, maybe? No? Okay. Well, so I'll explain this. So a blockchain is usually sort of modularized into four parts. And there are four essential parts. How the data is stored, how the transactions are handled, which is the smart contract layer, the consensus layer, which is sort of the high level communication platform and the networking layer, which is sort of like how do the blockchain nodes communicate with each other? So before we go any further, you know, I want to emphasize that we should not always use distributed ledgers. A lot of people will try to oversell blockchain and I want to, you know, make sure that you don't come away with the impression that we should use blockchain for everything. So decentralization is a fantastic tool and it gives us a lot of great guarantees in practice. But there are always drawbacks to using powerful tools. And in fact, there are many issues with distributed ledgers, but there are two that I'll sort of talk about today and that's privacy and confidentiality and performance. So these are challenging issues. So does anybody know what this is? Or does anybody want to guess? Go ahead. Yeah, you're right. So this is actually my credit card history from a few days at the end of February, a few years ago. And it's anonymized, right? So, you know, if it were in the blockchain, you might see something like this. But you can learn a lot, right? So I have entries. I have transactions in the South Bay, right, on snack machines. Well, you're probably going to guess that I have some, you know, work scenario in the South Bay, right? You know, there's a Sunnyvale restaurant. There's a corporate catering in Sunnyvale. You know, you've just already, you've probably figured out I work in Sun, I, at this point used to work in Sunnyvale. I'm buying gas and I'm getting groceries in Redwood City. You know, that might give you information on where I lived. Why do I have a payment to Stanford? You can make inferences about that. You know, I have a payment to a gastropub in Redwood City, and then I have Ubers. So just from sort of my transaction history, you know, you learned that in 2018, I worked in Sunnyvale. I probably lived in Redwood City. I had some connection to Stanford, and I enjoy going out for cocktails. And this doesn't totally de-anonymize me. But if we did this over a whole month, or even a period of months, you could probably, you know, completely figure things out. And being anonymous, you know, didn't really buy me much, right? And this is challenging, even in the permission setting. And privacy and confidentiality are tricky. So there are solutions to privacy and confidentiality, but you typically pay for them. So, you know, one of the ones I'll sort of just mention here is we have, you know, fabric private data collections. And the main idea is to limit the data others see on the blockchain by posting hashes rather than the data itself. But you know, this does come at a performance cost, right? You have to keep track of more data, you have to have extra mechanisms for dealing with data. So there's a trade-off. And this sort of gets to the blockchain trilemma. Have people seen this before? How many people have heard of the blockchain trilemma? A couple people? All right. So Vitalik made a reference to this, you know, originally at some point, I guess quite a while back at this point. But the basic idea is that it's very difficult for blockchains to achieve performance, security and decentralization all at the same time. And we have to consider trade-offs. So if we consider trade-offs like things like Bitcoin and Zcash are very decentralized and very security focused, whereas something like AOS, you know, trades some decentralization for scalability. I will encourage you if you are working on blockchain, please don't be here. Please don't sacrifice security. Choose your trade-off between performance and decentralization. And so if we go back to decentralized blockchains, and we think about performance, you know, in general, we do have that more decentralization leads to slower performance. So, you know, Bitcoin, I would say, you know, most people say is about, you know, five to 10 transactions a second. Ethereum is 30. Cardano is about 250, but we have some IOHK guys in the back who can probably give you better numbers than I can. And, you know, it gets more complicated. You know, even assessing the performance of some of these blockchains is very dependent on the network, how you set it up, how you configure it. So it's quite complicated, but it's the generally the more centralized you are, the faster you go. And then, you know, obviously traditional databases can blow blockchains out of the water in terms of performance. So there are trade-offs in distributed ledgers. So if you have decided you need a distributed ledger, it's important to pick where on a decentralization continuum you need to be. So how much decentralization you need, you know, you sort of want to pick that much and not anymore because otherwise you're paying forward in terms of performance. And I will say there are tons of trade-offs in distributed ledgers. We can't really go into all of them. You have to be very careful when you're picking a blockchain that you sort of get the right balance for your application. But again, the main and most universal trade-off is sort of decentralization and performance. And if we think about decentralized trust, there are many different components of decentralized trust. So there's the code layer. So there's who implements and maintains the project. There's the architecture, the specification layer. And oftentimes, this is sort of, you know, combined with the code layer, but sometimes it's not. So who decides the specs? Who sets the roadmap for the project? There's the on-chain consensus layer, which I mentioned before. And there's the governance of the ledger. How do we govern the ledger? You know, what's the legal framework around the distributed ledger? These are all important. And finally, there's the application layer. So sort of all is for not if your application is not actually decentralized. So I kind of felt scooped because, you know, earlier this week, Trail of Bits came out with a very similar categorization and report. I don't know if has anybody seen this? Yeah, it's got a lot of news. And it turns out, you know, that Trail of Bits certainly thinks that many blockchains and applications are not very decentralized. It's hard to disagree with that. And the core point is that if any one of these layers is centralized and sort of controlled by one party, then the entire blockchain is more or less effectively controlled by one party and is centralized. And if you have a centralized part of sort of any one of these layers, you know, you have to ask yourself, why would I not just want to have this single party run the system in a centralized way? So let's talk about some of these. So let's talk about NFTs. So, you know, everybody here is probably seen or familiar with NFTs. Is anybody familiar with this NFT standard EIP 721? Yeah. So basically, EIP 721 explains how a lot of the common NFTs on Ethereum or Ethereum blockchains are stored. So most art NFT projects don't actually store the art itself in the blockchain. They don't even store a hash of the art. They just store a URL pointing to a website, right? So what if the website goes down or changes what the link points to? What happens to the NFT? Well, so there's a famous security researcher, Moxie Marlin Spike. I don't know if you all are familiar with him, but he decided to have fun with this. And he wrote an NFT that changed based on the IP address of the viewer. So sort of wherever the, you know, wherever the user was coming from or sort of, you know, how the website was interpreting it, changed what the NFT did. And he immediately got removed, which he was commenting, like, well, you know, shouldn't my NFT be forever? But the point is, if the website can change what the NFT points to it will, you know, is this just not total centralization? And sort of two paths for this application make much more sense. You know, why would you not say, let the website be the arbiter of who owns the artwork registered on the website and have it store the ownership? And why do we need a blockchain if the website gets to decide what art the owner of the NFT owns anyway? Or we could take a more decentralized approach and we could store the entire bit representation of the artwork in a blockchain, maybe even just a hash. And this would add storage requirements to the blockchain, but it would prevent anyone from sort of changing what the artwork represents itself. So I will say watch out for false decentralization when you're looking at blockchain applications. So this is very recent and I had to change my slides for this. So how many people were following the Solend situation? So very quickly, Solend is a ostensibly defy protocol, so decentralized finance that lets users borrow money and lend money without having to go through intermediaries. It's built on the Solana chain. So this is the claim from the website and I will emphasize that it's algorithmic and decentralized. OK, so what happened? Well, there was this big hullabaloo about you know, emergency powers on the Solana network. And basically Solend's largest single user came dangerously close to a margin call due to the Solana token price going way down. And if this users were, excuse me, if this users positions were liquidated as a result of this margin call, it was going to be chaos for Solend. It might even cause outages on the Solana network. So the Solend community passed a proposal to strip the user of control of their funds and to manually liquidate the user's positions. So this means they're taking this person's money and liquidating it. And after backlash, you know, there was another proposal that mostly canceled the first one. But you know, is the community voting to strip people of control over their funds really a good idea? And even more so, you know, a lot of both of these votes were essentially dominated by one person. So one wallet and for both of these proposals, you know, made the difference between them passing. So, you know, this obviously caused a lot of a lot of outrage on the Internet. There were comparisons to, you know, obviously Jar Jar Binks in episode six. But, you know, it might not have even been sort of an innocuous proposal. There might have been, you know, malice behind it because people stand to gain a lot of money from this liquidation. So in summary, you know, make sure your blockchain governance is designed so that they can't be centralized by malicious parties. And again, if we consider the next layer, right? So, so I already showed you this slide on on chain consensus protocols. But there are a lot of subtleties with consensus algorithms, right? So how many people here are familiar with mining pools? I assume most people, maybe. So you all know how these work. It's hard to successfully mine as an individual. So people come together and form mining pools, less money in the expectation, but you get a steady or stream of payments. So it's it's worth it to reduce the chance. But mining pools are centralized, right? And the mining pool operator controls what transactions the miners and the pool propose, you know, as well as what chain they build. So this is the current distribution of blocks. I think I pulled it a couple of days ago. So it's probably the past three days on like Tuesday. But these are the percentage of blocks mined by various Bitcoin mining pools, right? So essentially three pools have a majority of Bitcoin. So that's three people that essentially get to determine the consensus. It's the same case for Ethereum, too. About three pools, you know, form a majority. And a lot of people ask, you know, what happens when we go to proof of stake? Will it be better? So there are still issues with proof of stake, too. A lot of people have a hard time running their own node with their own ETH. So they join staking pools. And these also present centralization problems. As you can see as well, there are about three staking pools that control close to 51 percent. And I will say mining pools are difficult to fully analyze in terms of what they mean for decentralization. On one hand, users can always leave the mining pool if they disagree with its decisions. But on the other hand, users may be less happy with their financial rewards if they do so, right? If you join a smaller or less good pool, you might make less money. So the question you have to ask is will a rational user that cares mostly about their income be willing to leave a mining pool if the mining pool is a censoring transactions? So, you know, I just want to emphasize that it's necessary to address the full tradeoffs of consensus algorithms when it comes to decentralization, even for permissionless networks. And finally, you know, it's important to make sure that your decentralized protocol can't become centralized. So are people here familiar with the beanstalk attack? I thought this was very clever and it was actually quite legal. It was within the governance of the beanstalk protocol. So an attacker took out a flash loan, a flash loan without getting into the technical details is sort of a very, very fast loan. You get the cash and you repay super quickly. They bought enough of the beanstalk tokens to completely take over the protocol. So they sort of had more than 51 percent of the stake. They created a proposal to send all of the beanstalk protocol funds to their ETH wallet, which they then passed because they had all the stake. They laundered the money and profit it. So it's important to think carefully about whether your decentralized assumptions hold true. So beanstalk assumed that there would never be a single entity in charge of more than half of its voting rights, but that was obviously not the case. So moving on to sort of the next layer in the chain, it's very important that code and architecture design of a blockchain are also centralized. So here I sort of made up a traditional blockchain system this is how most blockchain development works. We have a blockchain foundation that I've called Silly Foundation here. We have Silly Chain and we have Silly Devs that are a part of the ecosystem. And typically the foundation manages the blockchain development, it may manage the chain and the devs are building applications. So what if one entity controls the blockchain development process? In theory, they could push software to the blockchain that maliciously broke the blockchain or try to steal value of the chain and get away with it. In practice, the entity likely has reputation at stake and value tied in their chain. So what we would mostly consider attacks are things that would sort of advance the entity's agenda at the expense of others, preserve their value, make them money. But in summary, you have to completely trust that the code development entity is sane, rational, and to a lesser extent honest, if you want to have a centralized development process, that's a lot of trust. And if Silly Foundation has completely centralized control over development, then the devs have to trust it. And in this case, you have to carefully consider the advantages compared to having this Silly Foundation just run a centralized database. People are probably familiar with this, right? This is a basic code snippet outlining the Ethereum DAO attack, if you are familiar. I think most people have seen that at this point. So the point I want to make here is even using a degree of centralization, right? So when the DAO attack happened, the Ethereum Foundation very quickly pushed out an update and said, hey, OK, everybody, please get on board with this fix. This caused a, you know, a lot of controversy, even though it was arguably doing a good thing and disincentivizing large system attackers. And this did change the governance, but I don't want to get into that right now. So what we sort of want when we have, you know, a foundation or something building blockchain code is we want to incorporate the community. We want it to be as decentralized, you know, as we possibly can. We want openness. And I will state that I think an organization developing blockchain software should be maximally decentralized. We want it to resemble a representative democracy of the stakeholders and people who contribute to the blockchain and its development as much as possible. So this means transparency, right? Decision making should be done in the open and also openness. We want anyone to be able to join and contributors should be able to reach leadership positions on their own merits rather than company affiliations. So we don't want pay to play and we want what's called open development and not just open source. And I think this is a really important point. So lots of people will say, well, open source has already won a blockchain. And almost every substantial blockchain or distributed ledger has decided, you know, correctly, we think, and I hope you all agree, given that where we are today, that open source is the correct model. So it's hard to find a ledger of blockchain that is an open source. It makes very little sense. If you think about the decentralization perspective, you know, even the mass majority of wallets are open source now. So it's really, you know, becoming a more open ecosystem. But while open source is one, true open development has not yet become the most popular ledger development model. And we think it should be. And we think that open development is the only way to develop a ledger because all of the other methods are centralized to a non-trivial degree. And we'll illustrate that with this sort of, you know, some examples of how open source project types work. So there's what we call the dump and run, which is essentially just a code dump. Somebody throws code. There's no roadmap. It's it's not arbitrary. These are just sort of stuck. There's the open company product, which is sort of, you know, a company essentially open sources of product. But it doesn't allow outside contributions. It does keep a roadmap as regular releases and follows best security practices. There's basically no way for any user to have an impact on the project. Some blockchain open sourcing is this open company product kind of thing. There's also the benevolent open dictator model. So this is what an organization open sources their code. They allow contributions, you know, maybe even to the roadmap from external contributors. But the ultimate authority on merging code and the roadmap and everything belongs to the company. And there's no clear there's no path for anyone that's not in the company to have an impact. On the decision making. And unfortunately, this is what many blockchain companies mean when they say they're fully open source. They're open source, but they're not open development. And finally, the model we like is something we call open development or open governance. And this is where you have a code base with transparently documented and meritocratic governments, which is hosted under, you know, a third party entity. Anyone can join and contribute. There's a clear process for how leadership is decided. And this is generally how Linux Foundation projects work. There's no exception for hyper ledger here. So, you know, with all of these principles, this is what we try to bake into hyper ledger, which is, you know, a global consortium of communities working on blockchain together. So what is hyper ledger, right? It's an open development, not for profit, obviously for blockchain technology with real value. It's hosted by Linux. You know that hyper ledger is neutral and collaborative. It's always open to anyone. I get this asked this question all the time. And we've structured it so we try to remain immune to the commercial interests of any single company. So no single company will ever control hyper ledger. So some background. Hyper ledger is about blockchain software, not blockchains. So we provide a community for blockchain software and tools. We do not run blockchains as part of the hyper ledger foundation. I get asked this all the time, like, you know, where's the hyper ledger blockchain? How can I join? We don't do that. And blockchains are run either through separate entities or foundations. So we have a global team of developers. Anyone can join and contribute and even join a leadership role. And we try to be a transparent as possible. Everything is in the open. Pretty much all our meetings are open, our email lists are all open. There are very few that are not open and the ones that are not open, like, you know, the security response list are not open for a very good reason. There's no pay to play. So you can, like other Linux Foundation projects, you can buy a membership membership in hyper ledger. But it's mostly for community and marketing benefits. It doesn't give you, you know, extra participation benefits. We have a wide variety of blockchain projects. I'll just put that up there. Lots of different applications. And, you know, we have quite a bit of momentum. These are just some numbers. We've had some of the fastest growth of any Linux Foundation project ever. And these numbers indicate it. So so finally, I'll conclude with a question I get a lot, which is how do I pick a ledger platform? This this question happens all the time. And my answer is usually the following. Well, first you need to pick a ledger that satisfies the constraints of your application, right? If the ledger doesn't do what you want it to do, then sort of what's the point? And then pick a ledger that has open governance for its development. You want to pick something that's maximally decentralized. And I hope I've explained why that is a good idea. And finally, I pick based on the community, because a community will have the biggest effect on the ledger's success in the long run. And again, transparency, you know, good communities will show everything. So this is, you know, that's the Linux Foundation analytics statistics. Have people here familiar with LFX? If you all used it before. Awesome. So, yeah, you can see all of our contributor statistics. You can find out who's working in the community, where the company's from, you know, all this stuff. It's open, you know, we're transparent, so it's all there. So yeah, thanks. I will say that if you're interested, we have our global forum in September in Dublin. I think it'll be an exciting event and a good program. So if you're interested in blockchain and open blockchain, it's a great thing to go to. If you're interested, you want to join our community, you can ask questions on our discord. And yeah, thanks. That's it. And I'd like to answer any questions. Are there any questions to provide what? So the question, if I understand correctly, is are there any commercial entities that provide services for a Hyperledger Foundation projects or software? And the answer is, yes, of course, there are tons of companies that do that. We have, I think, one hundred and eighty member companies. And I would say probably most of them do that. And there are even companies that aren't members that do that. So I think that's a very popular business model around Hyperledger. So the question was, who are the top three companies? And I guess that my response is, well, how do you want to measure? So I don't know the internal company numbers, and they usually don't tell us. So so this is a hard question for me to answer. I can answer, you know, what companies contribute the most code or, you know, who are most involved in the community. But it's very hard for me to say, you know, who does the most outside stuff because they they don't tell me that. So by a number of like maintainers and contributors, I believe our largest our largest contributor companies are IBM, Consensus and Accenture. That I could be wrong, but I think that's true. And we could look up on we could spend five minutes on LFX and find out exactly. Great question. As a cryptographer, I always love to hear questions about cryptography. And the question was about zero knowledge proofs. Do we have do we have anything around that? So the answer is, yes, our identity projects heavily rely on zero knowledge proofs. So we have some basic zero knowledge code in our Aries Indy Ursa stack. So the actual zero knowledge protocols are an Ursa, which is just a cryptography library. And they're typically called in Aries, which is our wallet library. And the Indy is sort of the blockchain layer for that. We actually have a big PR outstanding in Ursa that has sort of gotten delayed due to the pride. The whole project is doing a big refactoring. But it's about a ZK interface style of protocol where you can write. You can write, you know, zero knowledge proofs and then have them. You have to write them in R1CS if you're familiar with that, which is a bit complicated. But you can write an R1CS statement and compile it down to a number of different ZK proof systems. And I guess that's the extent a lot of our big. So I base you and fabric, for instance, don't have any ZK piece inherently built into them, you know, but you could certainly build on top of them. The what? The CBDC. Yeah, so that's a really interesting topic. And while hyperledger is involved in a lot of people in hyperledger are working on CBDCs and the hyperledger community, you know, people are using it in the outside community. There's been a big announcement. I don't know if you saw there's an announcement between hyperledger Finos, which is a sister Linux Foundation company and the digital dollar program about an effort to investigate and potentially build CBDC software. So if that's something you're interested, I would highly look up that and I would recommend looking up that announcement. There are a bunch of links in there where you can sort of get started and learn all about the CBDC stuff because it really cuts across a lot of different groups in the Linux Foundation. I would love to answer your question, but I think we're out of time. And if you catch me, I will hang around after the talk and you're more than welcome to ask questions. So yeah, thanks everybody for attending and I hope you have a great rest of your conference. Thank you.