Internet Computer Genesis Launch Event

[Music] [Music] [Music]

The internet, one of humanity's greatest inventions. A public network created by an open, decentralized protocol that combines millions of private networks into a unified global network, connecting everyone and everything. And it all began with just four nodes that connected UCLA, the Stanford Research Institute, UC Santa Barbara, and the University of Utah. The network grew to 29 nodes and then expanded internationally.

Decades later, Marc Andreessen and Eric Bina created Mosaic, the first web browser, which later inspired the development of Netscape.

There is another reason for decentralization, and that reason is what's called permissionless innovation. This is really what the web, the web had going for it like, early on. And what actually, you see, TCP had going for it early on. And actually, even what like Twitter had going, uh, for it early on, which basically is, you could build whatever you want without asking anybody for any permission. Like, to just give an example, to build Mosaic, I never had to ask anybody's permission. I didn't have to go to the phone company and ask for permission. I didn't have to go to, you know, the tech companies, ask for permission. Like, I could just build the code, deploy it, and it just worked.

The open internet was unfinished, and as its commercial potential became clear, a debate emerged: Should this vast network be governed by decentralized protocols or powerful corporations?

In 2009, blockchain technology emerged, a breakthrough that gave rise to governance tokens and smart contracts. Bitcoin became the first cryptocurrency to create digital gold in cyberspace. Soon after, Ethereum introduced smart contracts, which made cryptocurrency programmable and ignited the DeFi revolution.

The DFINITY Foundation follows in the footsteps of these networks. Established in 2016, DFINITY introduced a decentralized world computer, also known as the Internet Computer, a limitless blockchain that runs at web speed and can host all of humanity's software and data. The internet was only a global network until now. Now, the Internet Computer extends the web's functionality into a public compute platform, enabling entrepreneurs and developers to build directly into the public internet. The internet is returning to its free and open roots, which brings us to this moment: the Mercury Genesis launch of the Internet Computer.

Welcome to the Mercury Genesis launch event. It's an honor to be here with you all. Joining me in the studio are Alexa Smith and Liz Yang, and joining us virtually, we have our team of close to 200 of the world's most renowned cryptographers, distributed systems engineers, programming language experts, and operational talent from the DFINITY Foundation. We've been working on the Internet Computer since 2016, which feels like a lifetime ago in the crypto blockchain space. So, this moment has been a long time coming.

In the early days, everyone working on the Internet Computer fit into a small house in Palo Alto. In fact, we used to have our daily stand-ups with our entire team in one tiny room. And now, the DFINITY Foundation has flagship research centers in Zurich, San Francisco, Palo Alto, as well as remote teams around the world. It's really amazing to see how much the team has grown. You know, it's been an honor to help grow our community from just a handful of early rider dies to hundreds of thousands of supporters over the past few years. So, to our community members all around the world, know that your patience and faith in the Internet Computer is being rewarded.

[Music] With [Music] not a day goes by that we don't receive emails from entrepreneurs and developers interested in building on the Internet Computer. The caliber of some of these projects is just astounding, and I personally have been thrilled to see some of our early adopters starting to collaborate with one another. And we're so excited that today we get to showcase a few of the teams that are capitalizing on the emerging open internet boom. You know, in some ways, the Internet Computer journey is just beginning, and it's worth noting that we all have a role to play.

All right, with that said, we have a great show planned for you all today. So, let's get going, everyone. First of all, thank you so much for being here and staying with the DFINITY Foundation on this long quest to launch the Internet Computer. It has taken several years to reach this moment, and now finally, we're at the advent of genesis unlock. So, firstly, I can confirm that the network will switch on full token liquidity at 9:00 AM Pacific Time this Monday the 10th. This means that in a very short time from now, the Internet Computer will transition into a new, fully public mode.

When genesis occurs, the Internet Computer project will take another step forward, and blockchain will take a giant leap forward. The Internet Computer redefines public blockchain as a platform, as one that can now run smart contracts at web speed, that can serve web directly to users, that can increase its capacity with demand as needed, that is efficient, that governs itself, and that can provide better usability than those systems built on traditional technology. Our aim is to support the reimagination of all systems and services in new forms, using smart contracts on infinite public blockchain and nothing else.

What the world now builds to take advantage of blockchain's new capabilities shall be an important and fascinating next chapter. Achieving our goals will take years and redefine the internet ecosystem, how we build, and even perhaps how parts of society function. The network that enables these transformations was once declared infeasible in many quarters, but we are now proving that false, and that the dream can be realized. But the Internet Computer network remains nascent, and we and others shall now expand our research and development efforts ever more eagerly, drawing in more and more brilliant engineers and researchers who share our purpose and who want to work on one of the most complex and fascinating computing technologies in existence today. Blockchain is an earnest endeavor, and we will not cease in our work to improve the Internet Computer network. We have now proven that such a blockchain can be made, but we will not relent from making it more efficient, faster, easier to use, and better, even upon a blockchain singularity when most of our systems and services run on blockchain. DFINITY will continue contributing with the purpose of helping to drive this technology as close to perfection as possible and to help expand network capacity to immense scale.

So, where are we today? The project has traveled a long and storied road to reach this point. It has not always been easy. In the past years, we have redefined our development methodologies many times, pivoted to new ideas when old ones didn't work, developed completely new cryptography, and struggled with the efforts involved building a project of this size. Today, DFINITY is almost 200 people strong, and the Internet Computer Association in Geneva has been newly formed, but we will continue growing even faster than before. The network is running. There are almost 1500 special node machines in data centers either deployed or being configured by independent parties, but this will grow into the tens of thousands by year-end, and then one day into the millions.

Meanwhile, the Internet Computer blockchain is extraordinarily complex, and it will take time before it becomes sufficiently stable that we can declare it out of beta. And although it has been designed to fail-safe and stop to protect tokens and smart contract data, we should expect a few bumps in the road and outages in the coming months. But there are many things that the Internet Computer can be used for now, particularly by entrepreneurs and decentralization projects. Genesis fires a starting gun for those wishing to build the future. Projects that have already been built by those foolhardy enough to try building on an alpha network show what can be done. Please enjoy, please enjoy the demos and technical talks coming up, and join us in our mission to reinvent the internet.

Lastly, I want to tell you what many team members at DFINITY have been through to get us to launch. People around the world have been working around the clock and through many weekends under immense pressure. My sincerest thanks go out to everyone who has made this possible, including all the backers of the project and supporters who have had to wait out many years to see this happen. So, without further ado, welcome to the Internet Computer's Genesis launch event.

[Music]

In this presentation, I'm aiming to provide an Internet Computer primer in around five minutes. So, let's go. The purpose of the Internet Computer project is to extend the internet and make it far more powerful. Today, the internet is a network that connects everybody and everything, but systems and services currently run from private infrastructure, with the exception of DeFi and Ethereum. The Internet Computer blockchain shall enable the public internet to host smart contracts that run at web speed without any limitations on capacity, so that it can host a broad range of systems and services. The Internet Computer extends the public internet so that it can also be the world's compute platform. Clearly, this is a paradigm shift that will change everything.

So, a little bit about the team behind this. The DFINITY Foundation is a not-for-profit organization headquartered in Switzerland, which runs research and development centers from Zurich, Palo Alto, San Francisco, and Tokyo, together with remote teams in places like Germany and the UK. We are almost 200 strong and hire the best from academia, crypto, and the world's leading technology organizations. New organizations are also joining the fray. For example, the Internet Computer Association was recently formed in Geneva to represent the interests of ecosystem participants.

The Internet Computer is the third great innovation in blockchain. First, Bitcoin introduced traditional cryptocurrency, which plays the role of digital gold in 2009. Second, Ethereum added smart contracts so that digital gold could be used in decentralized financial systems. Now, the Internet Computer introduces infinite blockchain with the speed, capacity, and usability required to reimagine everything on-chain. It's a blockchain that provides seamless, limitless capacity for hosted smart contracts and their data.

The Internet Computer is created by the ICP protocol, which stands for Internet Computer Protocol, from where its master governance token gets its name. ICP creates the world's first web-speed, web-serving public blockchain network that can grow its capacity with demand and is self-governing. It combines special node machines run on mass by independent parties in independent data centers around the world. Like all blockchains, it is unstoppable, and the code it hosts is tamper-proof.

The Internet Computer hosts special smart contracts called canisters. A canister is a bundle of WebAssembly bytecode logic, which you can create from any high-level programming language such as Rust or Motoko, and memory pages that the code runs inside. A key breakthrough is that the Internet Computer can host any number of canister smart contracts, and therefore any amount of data, fully on-chain. And moreover, it can run them concurrently, which means that it can process any amount of computation. What this means is that you can create dapps that scale. For example, you might create a tokenized social media service, but the advantages of smart contracts remain. Canisters are unstoppable and tamper-proof.

The internet was designed to withstand a nuclear strike, and so is the Internet Computer. You don't even need firewalls to protect hosted canister systems because smart contracts are tamper-proof, thanks to blockchain mathematics. Many other breakthroughs are present too. Canisters can serve web content directly to end users, and users can interact with blockchain services without having to hold tokens. It's user-friendly, and users can seamlessly authenticate themselves cryptographically using their devices, such as the fingerprint scanner on a MacBook, so that systems and services benefit from end-to-end blockchain security for the first time.

The Internet Computer can be used to build many things better. For example, this platform can be used to build tokenized internet services, pan-industry platforms, decentralized financial systems, and even traditional enterprise systems and websites. What is absolutely incredible is that the Internet Computer elevates blockchain to become a complete alternative to the traditional IT stack. Whereas today, most apps are made from a combination of smart contracts and insecure websites running in the cloud, so users can never be sure they are even interacting with smart contracts. On the Internet Computer, entire systems and services can be built on-chain, and it has the speed, capacity, and usability to support building nearly anything.

For developers, this represents a revolution because they will be able to write canister code on their laptops or even in a web browser and then upload it into cyberspace to create new systems and services from smart contracts, all without the complexity of traditional IT. Of course, they might also apply blockchain tokenization in the design of internet services or leverage other blockchain features. The Internet Computer's purpose is to host humanity's logic and data. If that goal is achieved, it will create a blockchain singularity in which blockchain becomes the internet and the platform upon which everything is built. This will be a wild ride, and we hope you come along.

If the years leading up to this moment have taught us anything, it's that the internet is on the cusp of a radical transformation. Emerging decentralized technologies like the Internet Computer are enabling builders to design a new ecosystem of open internet services. We predict that in the coming years, the open internet will enable new business models, just as technology has done in the past. Before the dot-com boom in the '90s, no one could have imagined the impact of digitally native businesses running on centralized clouds, software-as-a-service business models, and digital advertising. Before the mobile boom in the early 2000s, smartphones were not the ubiquitous mobile computers that they are today. Summoning an Uber through your phone, opening up your home to the world through Airbnb, or connecting with billions of people on social media was enabled by technologies developed specifically for mobile. But with these new capabilities came issues caused by centralized big tech, such as invasion of privacy, misinformation, and bias. Now, new decentralized computing platforms have the potential to course-correct some of these problems and return the internet back to its free and open routes.

Blockchain innovations from Bitcoin to Ethereum to the Internet Computer are pushing the internet into a new era, affecting everyone from legacy internet businesses to early-stage crypto startup founders to consumers. To examine this pivotal moment, Forbes and DFINITY recently partnered on a special virtual event to chat with Joe Lubin, Dominic Williams, and several notable Internet Hall of Famers to revisit what these experts are saying about the opportunities on par with the dot-com and mobile booms. Let's look at some highlights from our event.

[Music]

When the web was stood up, uh, all we could think of was to implement the business model of television and radio. And so, we immediately went to advertising, and that skewed the business model of the web quite significantly. Um, so it ended up being about getting eyeballs, uh, and essentially evolved to addicting people to, um, certain kinds of platforms, on, uh, in the web ecosystem. Decentralized protocol technology, um, enables us to, uh, move value to the internet, uh, and to build these trustworthy collaboration platforms so that people can participate, small companies can participate with full economic agency and full political agency, because these tokens that we're all issuing and firing around, many of them represent somewhere between cryptocurrencies and shares in a company, and many of them have governance rights and the ability for people to step in and democratize the financial infrastructure for the planet or democratize the government infrastructure, potentially. I know some people think we live in democracies, but we can do a lot better.

I want to sort of bring those two stories together and talk about, um, the fundamental role that cryptography plays in our modern-day internet and the fundamental role that the Linux kernel plays in our modern-day internet. And perhaps more importantly, the fact that neither of those projects were closed source. Like, you weren't, you weren't necessarily asking, "How do I monetize this?" You were creating something for the world to use. So, I, I, I'd like to just an open question to you all, um, how do you sort of shepherd that technology once it is out there in the wild? What roles do you play to help ensure that it stays open, stays available to, uh, to businesses and individuals around the world?

I'm a lawyer. EFF works in law and policy. Um, you know, our job is to help the creators, you know, remove the obstacles, um, to ongoing development and creation. And right now, encryption is under really serious threat. It's under threat internationally, and it's under threat in the United States. And so, um, especially for the folks here, I know there's a lot of blockchain folks, um, in this, in this audience, um, there is a fight going on in Congress where your voice is really needed, because I think they think encryption is just something that bad guys use to, you know, plan heists, and they don't realize the deep reliance that all of us have, um, on the kind of security and reliability that encryption gives. So, you know, our job is to get the obstacles out of the way for entrepreneurs. And, um, you know, there are, there are others as well. If we're going to talk more broadly about the distributed web and not just about encryption, there's a, a set of laws that are getting in people's ways right now, and I'd love to talk about those a little later, and some probably some positive things we need to do to try to free things up because we've become so, you know, worshipping of this platform model that we're really locking out the ways that you continue to innovate in this world. But, you know, for us on the encryption side, the science, because encryption is just math, right? It's applied math. So, um, you can't, not, you can't remove it from people's brains, right? You know, so the, the bottom part of encryption, the very end of the, is, you know, kind of applied math. It's not all that hard. Um, so the idea that you could, you know, erase people's brains and they wouldn't know about encryption anymore, just, you know, makes people giggle. Uh, me too. But what we need to do is we need to get all the other obstacles out of the way of people actually using it.

I think the important thing for our organization is whether it's Linux or Kubernetes, which is now the foundation of cloud computing, or Node.js, which is, you know, the world's largest server-side JavaScript, against what people use to create modern web applications, mobile device applications. We want to enable what we think is in human nature, which is empathy, selflessness, cooperation. And I think too often, and Yuval Harari, in his book, "The Penguin and Leviathan," points this out so well, too often we resort to what we know: selfishness, capitalism, you know, punishment, money as a reward, you know. And humans, and what we witness, and I'm fortunate to witness every day, they really want to work together. You know, we, we ask developers all the time, "Why do you participate?" I mean, we're talking hundreds of thousands of developers that build the infrastructure for the internet. Why do you participate? Money is never the top of this list. Cooperation, mastering their craft, the joy of creation. Humans want to do this. We've been fortunate to set up systems so that we can do that on every layer of the important software that runs the internet, that has worked in a, a way that has enabled it financially, and we want to continue to do that. But I think staying out of the way, making sure that we set up systems so that that continues, is certainly something we take seriously.

Can you disrupt the big four, financial, I'm sorry, the big four tech giants, and still make money doing it? Yeah, I mean, again, as an optimist, and I think you have to be in the job I have, I, I think people are inherently innovative. And if we can set up systems where we can build things that allow people to be social and cooperate, you can have your cake and eat it too. You can make money and work, uh, cooperatively and be open at the same time. And, you know, I'm just a first-hand witness to this. You know, we, our organization, in every project that we've been hosting, sees billions of dollars in market cap made through startups that base a new company on an interesting new open-source project. We see this software being used in amazing, innovative ways, and, you know, insurgent companies that come in. I think one of the things that has sort of caused consolidation in the tech sector is when we move to a services economy, CAPEX and optics became a differentiator. You know, when you have a collective 100 billion dollars of CAPEX being invested into cloud services, that's something that a startup can't compete with. I'm confident that people using open source can focus on that small part of innovation that will allow them to make money and give them the joy of cooperating on the software that they use with everybody else.

You know, when you build using traditional IT, uh, you're nearly always building some kind of Rube Goldberg machine. There are all these different components that you have to combine. You know, you've got your cloud service, maybe you've got Kubernetes, you've got databases, web servers, firewalls, middleware. It's extraordinarily complex. And not only is the assembly of components complex and unreliable and insecure, but you're probably engaging with a vast number of different vendors, all of whom want to make you a captive customer. Our proposition is that you abandon all of that, and that you build using smart contracts on the Internet Computer. And actually, smart contracts make things much simpler. It's true that nascent, early blockchain technology has been complex to use, but smart contracts are inherently simpler to use because, for example, they can directly interoperate with each other, they're unstoppable, they're secure by default. And we see a future in which people just write code and push it to the internet to create enterprise systems and internet services and things like DeFi. And it's just much simpler.

So, one of the great advantages, actually, of the Internet Computer, and you can list them. I mean, yeah, sure, you're building on a public compute platform, you're building on the internet, essentially, by writing code to cyberspace. It's secured by default, you don't need firewalls to protect it or anything like that. It's unstoppable. Um, but also, it greatly simplifies the construction of systems and services. And actually, if you look at the costs in IT, the costs really relate to complexity. And for example, if you take a Fortune 500 company, 85% of their IT costs will be IT operations. And you break down those IT operations costs, and 90% plus relate to completely unnecessary complexity. So, uh, you know, one of the most important things we can do is provide people with a much simpler way of building, and that's what the Internet Computer does. And when you build, you also get a lot of things for free. You, you, you're getting a system that's or service that's secure by default. You're getting a system or service that's unstoppable. And, you know, in a kind of interesting twist, you know, the Internet Computer reimagines, uh, smart contracts as a scaling platform. We aim to make it easier to scale.

One other sort of tangent of that that I wanted to ask about is also just the, the sort of the relationship, um, that's been created from the current incarnation of the internet between these major technology companies, the Googles, Amazons, Facebooks, Apples of the world, and and the people, where, uh, many, many individuals around the world feel that there's a disproportionate amount of value accruing to these large companies that have put walled gardens around their data networks, and they're not necessarily doing good, as sometimes they prefer to do. And, and on top of that, sometimes it's even more disproportionate when we talk about more emerging economies that have less choice than, uh, individuals in the United States and Canada and the European Union. Uh, what are your thoughts on on that, uh, Brad, perhaps starting with you first?

It is a challenging question. Now, I think the companies are very different. For example, I'm more afraid of what Facebook has become than what Google has become. And Google is a company that, as huge as it is and as valuable as it is, and by the way, I often refer to Archie as the grandfather of Google when I talk about other things, so that's, that's a good place to be. Um, but they've also done some pretty remarkable things. I mean, uh, they decided not to collaborate with the censorship of China, which Microsoft and and other companies have all agreed to do. So they certainly have their ups and downs. Facebook was of course created to find interesting things to do with your data, and that gives it, unfortunately, the motives. One of the things I actually regret the most about what Google did to the world was that we only really found advertising as a way to monetize activity on the internet. I mean, it's not exclusive. There are some paid systems, and of course, Forbes now has a paywall too, but, uh, most of the vast majority of it is paid for only by advertising because that was the easiest and least friction flow that allowed people to just use it without having to think too much about it and not pay for subscriptions. And that has unfortunately perverted what's gone on as well. It's of course driven the internet to be responsive to the wishes of advertisers than more to the wishes of users.

Now, I have actually worked a little bit at Google on the self-driving car, and I've known the company since before it was founded. I've known the founders of it since before they started it. And I, I actually think that while they, I certainly don't agree with all the things they do, they usually have their hearts in the right place about this sort of stuff. But this is one thing that's, uh, that's distorted everyone. When where your money comes from is going to control what you do. It's hard for private entities to solve that problem. I mean, one of the great ironies is that Google inside was a super open company at the beginning. And after search engine optimization came around, they said, "Oh, we've got to hide how our algorithms work because the SEO people are going to, you know, basically try and and cheat them and move them and game them." And so that created a different culture that was a little more secret, at least around that. They still try and keep an open culture the rest of the place. Uh, so they don't even know exactly how to deal with some of the problems that we're being asked about. Thinking that the regulators or that a public utility regulation commission could figure out is pretty challenging. And I certainly look at what's happened with Facebook recently when everyone's been saying, "Facebook, you've got a sense of yourself, you've got to start shutting down the hate groups, you've got to shut down Donald Trump, the alt-right groups."

It still blows my mind when I think about how much DFINITY has grown in the past few years. It's amazing that the mission of the Internet Computer has resonated with so many. Come to think of it, it's really a global effort. We have team members working in every major time zone, representing over two dozen nationalities. You know, that really reminds me of when we opened up the Zurich office in 2018. Do you remember that, Liz?

How can I forget, Michael? It was so crazy. You know, we had these world-class academics and scientists who were all interested in working at DFINITY, and suddenly our team became so international. But what we found is that we needed a way to keep our team abreast of everything that was happening because we have so many technical developments at DFINITY. So, I've taken great joy in spearheading these internal learning sessions we call the Academy. I think of it kind of like a technical open mic, where our researchers can present every week for an hour to talk about something interesting that's happening in the industry or something that they're working on. And they've been super popular. We even had a researcher tune in at one in the morning.

That's good to listen in. Yeah, super, super cool. You know, I really do enjoy the Academy sessions, and personally, I've learned so much, and I consider myself to be, you know, really lucky to have this as a source of continued education for all of us right here within the DFINITY Foundation. And, you know, it makes me really excited because that got us thinking, you know, well, perhaps we could open these up for the rest of the world too, right?

Absolutely, Michael. And that's why we decided to make a public-facing Academy series for our community to give you a taste of the series. We'll be sharing a few talks on the sophisticated technology behind the Internet Computer. You can access the full library of in-depth technical discussions given by our world-class research team in Zurich at dfinity.org.

[Music]

Hi, I'm Jan Camini from DFINITY, and this presentation is about Chain Key Technology. The Internet Computer is driven by a set of protocols that allow it to scale to a million of nodes and therefore provide like scalable, unstoppable computing powers to canisters. Chain Key Technology is at the heart of these Internet Computer protocols and itself. It's a set of protocols and actually, it is special bleeding-edge cryptography that we have developed. The most visible part of Chain Key Technology is that the Internet Computer has a single public key, and with that single public key, users who interact with the Internet Computer, they can verify messages that come from the Internet Computer with respect to that single public key. So, it's a huge advantage with other protocols. So, for the Internet Computer, all you need to verify messages are a single 48-byte public key, whereas, for instance, for Ethereum, you need to download at least 400 gigabytes of data in order to have the same effect.

Now, let's, uh, explain Chain Key Technology a bit further. So, in order to scale the Internet Computer, actually, not all the nodes can run the same canister, but we have to distribute the canisters over different nodes or over different set of nodes. So, we call this set of nodes like a subnet of the Internet Computer. One of these subnets is special in that it hosts and governs all the rest of the subnets, and that single public key I was talking about is actually the public key of that subnet that governs all the rest. The NNS subnet will generate the keys for all the other subnets. It will generate a public key, it will generate a certificate on public key together with key shares for the individual nodes of that subnet. And like that, with Chain Key Technology, the NNS can infuse other subnets, can start other subnets from scratch.

So, now when users interact with a subnet that does computations with their canister and receive results from that computation, they can verify that by signature on the subnet on these results with respect to the subnet's public key. And then that public key of the subnet can be validated using the certificate that the subnet had obtained from the NNS. So, there's like two parts of Chain Key Technology. The first part is what we have just talked about, where the NNS subnet can generate keys for other subnets. And the second part is how a subnet, once received the keys from the NNS, can manage these keys. Nodes can crash, and they need to replace nodes. Nodes might become compromised and need to be wiped. In both cases, the secret key that these subnets have received need to be re-shared among the new sets of nodes. And so, to maintain that key material that the subnet has received, to this end, we are using threshold signatures.

So, threshold signatures really is itself like a set of algorithms that have to play together. So, first of all, we have like an algorithm to generate keys. So, here's a dealer that generates shares for the different participants along with like a public key of that set of participants. Now, with these shares, the participants can take a message and sign them with using their individual shares, and as soon as sufficiently many parties have produced such partial signatures, these signatures can then be combined into an overall signature that can be verified with respect to the public key that was generated, uh, initially. So, these are the, the three algorithms. Let's see how we use them in Chain Key Technology.

So, what you want to do here for the NNS to generate those keys, we want to have a non-interactive version of this key generation algorithm. The standard key generation algorithm of a threshold signature scheme requires an old trusted dealer, and with the Internet Computer, that wouldn't quite work because we don't want to trust any single party. So, to solve that, we've come up with some new efficient cryptography that allows like two things here. First, it allows a dealer to non-interactively generate those keys. The dealer generates the secret keys and the public keys as in the original algorithm, but now what is different is that the secret keys get encrypted for the individual parties. In our case, the nodes, and then, and that's the, the clue here, is that the dealer also generates non-interactive cryptographic proofs that the encrypted secret key shares actually match to the public key that was generated as well. And with that non-interactive proof, any party can verify that the sharing was done correctly.

The second part is a mathematical property of this sharing scheme, namely that two different sharings can be combined into a single sharing. So, if you have like two or more dealers, the receiving parties can do a mathematical homomorphic operations, as we call it, on the public keys to merge the different public keys into a single public key, and they can also do the same thing on the secret keys, resulting in a new sharing, combined sharing. And as we already know that all the sharings are correct because of the zero-knowledge proofs, this homomorphic combination will actually make sure that as long as a single dealer did that correctly, so it did not leak the secret keys and it did generate those secret keys correctly, the overall combined secret keys will also be secured because they contain enough randomness and will be secret as well. The nice property about this homomorphic operation is that it will ensure that as long as a single sharing was done correctly, namely the keys were generated randomly and did not leak anywhere, then the overall combined secret and public keys are secure as well.

So, this allows the NNS to start a new subnet, to generate the keys for the subnet. More precisely, every node of the NNS will do such a sharing, send the sharing over to the nodes of the that form the new subnets. The subnet nodes will then combine all these individual shares into their final share of the overall combined public key, and the NNS will also supply the subnet with a certificate on the public key. Now, we also were talking about the second part where actually the subnet has to maintain their public keys. Now, we're talking about the second part where the subnet nodes have to maintain the key materials that they have received initially from the NNS. And here we need the second cryptographic tool, well, it's almost to say, but instead of generating a fresh key, we actually re-share the secret keys that the nodes have. So, it's almost the same, but what is different here is that, so the nodes re-share that secret key, and now, as the secret key of course cannot be leaked, it will also make an encryption of that secret key. And now, with the zero-knowledge proof, they will prove that the encryption of their old secret key is consistent with the sharing of that secret key, and then provide that to all the other nodes. Now, all the other nodes that can, can verify the correctness here, and if again, if sufficiently many of the nodes did that correctly, then we're all good. So, we have a fresh re-sharing of these secret keys.

Let's see how non-interactive re-sharing can be used for subnets to recover from failure, for instance. So, here in our example, we have like four nodes, and one of them crashed, lost solid state, lost all the secret key materials. And since we're using a three out of four secret sharing scheme, the remaining nodes can still operate. But of course, if like one more would fail, and then that would be disastrous. So, what, what happens is that the NNS would assign a new node, so stock it up to four nodes again. And now the four nodes, of course, also needs like a secret key share. And to this end, the original nodes will re-share their secret key for the new set of nodes, the four nodes, with the non-interactive re-sharing technology. And after that, each of the four new nodes will have a new sharing of the secret key corresponding to the subnet's public key. And that's how we can recover from subnets where nodes have crashed and replace those nodes and keep them operating.

Now, only the secret key is not good enough yet for the new node to join the subnet because it also needs the state of the canisters in order to execute all the transactions that the subnet should execute. So, it needs to receive the state from all the other nodes as well. The key materials are not yet enough for a node to operate on a subnet. The nodes also need to have the state, the latest state of that subnet, so that they can actually execute the transactions. So, to this end, the node that just joined the subnet needs to have that state from all the other nodes. As individual nodes cannot be trusted, the nodes together have to authenticate the latest state. And then, now with that authenticated state, the new node will be sure that the state it received is actually the real state to write state to start off.

Now, authenticating the state and actually also re-sharing those keys are both expensive operations, and we cannot do them every round. But rather, we do them at the designated intervals. And in these intervals, so we produce the authenticated state and a re-sharing of these secret keys. Both those two together, we call a catch-up package, because it's, it is what allows a node to catch up to the other nodes and operate together with them. And these catch-up packages are actually very powerful because they not only allow us node replacements, as we just have discussed, but they also allow a node to resume. So, if the node has not crashed, but maybe it was offline for some other reasons, if that was for too long, then actually the node cannot just re-execute all the transactions, but it needs to catch up. And to this end, you could just download the latest catch-up package and then unpack that and resume operations. It also allows us to resurrect the subnet in the catastrophic case where like more than one third of the nodes would have crashed or lost their state. As long as we still have a catch-up package, the NNS can take that catch-up package, just add a new sharing of these secret keys because the sharing was is not available anymore, and then sort of start a new subnet from that original catch-up package.

Also, probably even most important is that the catch-up package also allows us to upgrade the protocol because the catch-up package defines a well-defined state of a subnet. We can say that after a certain catch-up package, all the new nodes will download the new protocol versions and run the new protocol versions from that catch-up package.

Non-interactive DKG and key re-sharing are just two ingredients of Chain Key Technology. There's much more, and we will have talks about all of this soon online. At the heart of Chain Key Technology are consensus protocols that orchestrate all the different sub-protocols. Of course, consensus, the main task of it, is to collect and agree messages from users and get them executed, but it also has to orchestrate the non-interactive DKG and the re-sharing between all the different nodes. It ensures that computations are done correctly, and even if some bugs happened because of a hard disk failure or some cosmic glitches that spread that flipped some bits, that these bugs wouldn't spread to other subnets but remain contained. It also orchestrates the resumption and synchronization of state. It orchestrates all the upgrades, starting a new subnet from a given state. And another interesting feature is actually that the consensus protocols also provide secure randomness to applications, that is actually very, very hard to achieve in a correct way. So, we'll have technical talks about all of these details, uh, very soon, and we'll also publish the specs about that.

In summary, Chain Key Technology enables the Internet Computer to have a single public key that the world can use to authenticate messages from the Internet Computer. Chain Key Technology also allows the NNS to add new subnets and scale the network forever. It allows the NNS to revive a subnet if too many nodes have failed. It allows to exchange crashed or compromised nodes, and finally, and probably most importantly, it allows the Internet Computer protocol to upgrade and therefore to fix bugs and add new features. Thank you.

[Music]

Thanks everyone for hanging with us at the Genesis launch of the Internet Computer. I don't think this would be much of a launch event without some giveaways. So, to kick things off, we have a special digital download package for everyone watching. Scan the QR code now to receive your limited edition digital download package as our thank you for joining us today. Okay, let's dive back in.

[Music]

I'm on the drivers, I'm a cryptography researcher and I lead the consensus team at DFINITY. The Internet Computer will allow users to write pieces of software that we call canisters, and these canisters can run on top of the Internet Computer in a very secure and reliable way. Secure meaning that the state of my canister will only change according to the rules of my canister and not can, cannot be tampered with. And very reliable meaning that my canister will not suddenly stop running. We want to achieve these properties while we know that some machines across the world might have connection issues or might even be malicious. Additionally, we want the Internet Computer to scale, meaning we can run more and more canisters on the Internet Computer. It can grow its capacity. Well, to achieve these goals, we have what we call subnets. So, we split the canisters into smaller groups, and each group will run on a subnet. And now we can make sure that we can always add subnets to the Internet Computer, thereby growing its capacity. And if we now zoom into a single subnet, this is where we want to get this security and reliability. We do that by a process called replication. Instead of having a single machine power subnet, if we look under the hood, we see that many machines across the world will power a subnet. Each of them will have the state of all the canisters that run on this subnet, and each of them will process all the changes that come in. This approach of using replication to gain security requires a consensus protocol. The subnet must process different messages, namely messages from users to canisters and from canisters to canisters, and they must all process the same messages in the same order such that they achieve the same state. But each of the replicas that powers the subnet might actually see the messages in a different order. We use a consensus algorithm for all the nodes powering the subnets to agree on ordering of the messages to process such that they can all process the same messages in that order. We're going to reach consensus by using a blockchain. The messages that a subnet processes are grouped together and placed in blocks, and each block points to a previous block, thereby forming a blockchain. And now the security that we want is that all the replicas agree on the blockchain, thereby giving an ordering of the messages to execute. So, more precisely, we want what we call safety, that is, if two honest replicas think they agree on the blockchain up to a certain point, then they must in fact have the same view of the blockchain up to that point. Secondly, we want liveness, meaning that the blockchain keeps growing and we keep agreeing on more and more blocks. Third, we want what we call validity, meaning that all the blocks and the messages in the blocks are actually valid.

So, let's dive into our consensus protocol. First, it's important to note that there are many consensus protocols out there, but we chose to design our own protocol tailored to the needs of the Internet Computer. Our protocol contains four main parts. The first is block making. This creates candidate blocks out of which we can build blockchains. The next is notarization. This is responsible for identifying valid blocks out of which we can build valid blockchains. Next, we're going to add the random beacon. The random beacon will give us some randomness that we can use to further enhance our protocol. And finally, we use finalization, which will tell us when we've actually reached agreement.

So, we'll start with the block maker. A replica on the subnet can serve as the block maker. It will have some messages available that should be processed by the canisters that run on this subnet. It might have a blockchain up to a certain height, let's say 29, and now it gathers messages that it has available, waiting to be processed, groups them together into a block, and proposes an extension to the blockchain by sending it on this gossip network to the other replicas. Here, it's important to remember, we want this protocol to work even if some participants are actually misbehaving. This means that we cannot elect one single block maker to extend the blockchain because this, this one block maker might actually be malicious, and we could be stuck forever, violating our liveness goal. We'll therefore have many replicas.

Serving as block makers in every round now for the same reason. These block proposals may actually be invalid. To deal with that, we have the process called notarization.

And the notarization process ensures that every round we have at least some valid block that can extend the blockchain. It works as follows. Let's look at replica 1. Replica 1 has a notarized blockchain up to height 29. If it now sees a block extending the blockchain at height 30, it will validate that block. And if replica 1 sees that this block is valid, it might place a cryptographic signature on it that we call the notarization share. The notarization share will be sent to the other replicas in the subnet, expressing that replica 1 thinks this is a good block.

Now, maybe replicas 3 and 4 might also create notarization shares on that same block. And now we say that three out of the four replicas is sufficient approval. We combine these three notarization shares into a single artifact, which we call the notarization. And now block 30 is notarized. The notaries will now move on to the next round and start looking for height 31 blocks. For these notarization shares, we use special signatures called multi-signatures. Multi-signatures have the nice property that many signatures on the same message can be compressed into a single constant-size signature that proves that all the nodes actually approved this. This means that even if we have a very large subnet with many notaries, the notarization will still be a small object.

Notarization will not always work as well as I just described. The replica might see a valid block and create a notarization share on that block. However, it might now see another candidate block at the same height, which is also valid. If the replica would only sign one of the blocks, we might actually get stuck because some notaries might support one block while others nowadays support another block, and neither will ever get enough approval. Because we need this liveness property, the notary will now actually sign both of the blocks, making sure that at least one of them will become notarized. This way, we might actually obtain multiple notarized blocks at one height.

Well, we want to finally achieve agreement on the blockchain. And so now we're going to add some things to our protocol to reduce the amount of notarized blocks that we get every round. We're going to introduce the random beacon. The random beacon is a random value shared by the replicas of the subnet, which we will then use to further enhance the protocol. A replica might have a random beacon at high 29 and might decide that it's time to create the next random beacon. To do that, it will create a special signature on the previous random beacon value. And this is another artifact that we share via the gossip network. And this artifact, we call a random beacon share.

If we now get another random beacon share, we can combine the shares to construct the next random beacon value. We do this by using special signatures, namely threshold BLS signatures. Now that we have this common randomness, we're going to use that to rank the block makers every round. So, for example, using the random beacon that we created in round 23, we're going to rank the block makers in round 24. So, perhaps at round 24, we can agree that replica 1 is the top priority block maker, the rank 0 block maker. We still need to have fallbacks because replica 1 might not do its job properly. So, we can say that replica 4 might be chosen as the rank 1 block maker, the first fallback. And if that doesn't work, then replica 3 is the rank 2 block maker, and finally, replica 2 is the last resort.

We're now going to use this block maker ranking to further enhance the notary behavior. More precisely, when a notary enters a round, it starts a timer. And for the first amount of time, it's only looking to create a notarization share for the block by the rank zero block maker. Only if that fails after a certain amount of time, it is willing to fall back to a block proposal from the rank one block maker. And after another timeout, it's willing to fall back even further to the rank 2 or rank 3 block maker. The goal is that we reduce the amount of notarized blocks that we get every round.

Now, we might still in some rounds have multiple notarized blocks, but hopefully, in many rounds, we actually have only one notarized block from the rank zero block maker. If there is only one notarized block in the round, then we have actually already reached agreement. This is because a valid chain must exist of notarized blocks at every round. So, now the challenge is, how do we know that we've actually reached agreement? We have a separate asynchronous finalization process that helps us detect when we have reached agreement. Remember that notaries create notarization shares until they see that one block is fully notarized, at which point they move on to the next round.

Now, we're going to have the notaries share some information about how many blocks they notary signed, which will help us reach agreement. More precisely, if the notary did not create any notarization shares for blocks other than the first notarized block for the round, it will create a different type of signature that we call the finalization share. The finalization share essentially means that I, replica 1, did not notary sign any height 30 block other than this one. This is another artifact that it will gossip to the rest of the subnet. And if sufficiently many other replicas also create finalization shares on the same block, then we can aggregate them into a single finalization. Here again, we need three out of four, or N minus F more generally. And whenever we see such a finalization on a block, we know that we can trust the blockchain up to that point because a finalization is proof that no other notarized block at that height can exist.

If the network behaves well, this means we can actually reach agreement on blocks very quickly because we can very quickly create these finalization shares and reach agreements on the blockchain. But additionally, we are not at risk of these network attacks. So, even if the network does not behave well, we know that we're still safe because we only rely on signatures and not on the assumption that we've seen all messages.

So, in summary, we have a consensus protocol that consists of four components. The block maker creates candidate blocks to extend the blockchain. We have a notarization process that ensures valid blocks are identified. We then add a random beacon that you can use to rank block makers and reduce the amount of notarized blocks we get at every round. And we use an asynchronous finalization mechanism that lets us know when a blockchain is actually agreed upon without needing to rely on networking assumptions. Together, this allows us to use replication within a subnet that gives us the security and the reliability that we want from the Internet Computer.

[Music]

I'm Jens Gold from DFINITY, and I'm going to talk about non-interactive distributed key generation and key re-sharing. So, you may know from earlier presentations of our chain key technology that the Internet Computer certifies its computation and authenticates messages. And I'm going to talk about how we generate the keys and manage the keys for those certifications and authentications.

So, each subnet, which is part of the Internet Computer, has a public verification key. And you should think of this as a long-lived, static public verification key. And that makes key management very easy because we will always know a subnet by a unique and permanent public key. So, the subnet can then create signatures that verify with respect to this public key on behalf of the canisters that are running on the subnet. So, we don't give any single node the secret key that allows you to sign messages. Instead, we actually expect the nodes to collaborate and sign the messages together. So, we all need to be in agreement that this is the message they want to sign, and only if they're in agreement and collaborate can they sign a message.

In order to do that, we use threshold signatures. So, think of the nodes here as having agreed on a message they want to sign, and every node produces then a share of a signature. Once you have enough shares, so we need to meet a threshold of shares, and here the threshold is three, then we can combine those shares of signatures to produce a signature on the message that we wanted. Notice that the threshold doesn't have to be all of the nodes. It's possible that we can have a slightly lower threshold, and that builds resilience in the system. Even if one node has crashed or the internet connection for that node is unstable, the Internet Computer still runs, and we can still, on behalf of the subnet, sign messages. However, if too few nodes provide shares, then it's impossible to combine them to get a signature, and that provides resistance against attacks.

So, the setup now is that the subnet has a public verification key for the threshold signature scheme, and each node has a public share verification key that you can use to verify whether it's producing correct shares of a signature or invalid shares of a signature. And then every node also has a secret share signing key. So, the question now is, how do the nodes get these shares of the secret key? We're going to use something called a publicly verifiable secret sharing. And here, the dealer provides both the public key material, but also provides in public encryptions of the secret shares to every node. So, every node will have a public encryption key, and the dealer encrypts the secret share for that node with the node's public encryption key. So, now everybody can check that there's both public key material and also that there's ciphertext for every node. Finally, the dealer also provides a non-interactive zero-knowledge proof that the whole thing is correct. Right? So, this non-interactive zero-knowledge proof guarantees that what has been encrypted in these ciphertexts are actually valid secret shares that correspond to the public key material. At this point, there's no longer need for extra interaction. You don't need to have acknowledgement that shares are correct or complaints that they're not correct, because everybody can just verify all this public material and see not only that I, as a node, have received the correct share, but also that every node here has received the correct share that has been encrypted under that node's public key. At the same time, we're not revealing what the shares are, right? So, the shares have been encrypted, and therefore we are not revealing what each node's individual secret share is. And the proof is zero-knowledge, which means that the proof also is not revealing anything about the secret shares or these secret plaintexts that have been encrypted.

Now, there's one problem, which is, in real life, we don't have this single trusted third party, right? At this point, the nodes would, from this publicly verifiable secret sharing, the dealing, know that everybody has got a correct secret sharing and that corresponds to the associated public key material. But what they don't know is whether the dealer is honest or not. And therefore, we need a distributed key generation protocol. So, the setup that we have is that we actually have multiple dealers, and each of these dealers provide a dealing. And then we get security if at least one of those dealers is honest. So, we can actually tolerate quite a few bad, malicious dealers.

I want to talk a little about how we do re-sharing as well, okay? So, here, think of a node that already has a share verification key and already has a secret share corresponding to this shared verification key. But now this node wants to re-share that secret key. So, it wants actually to give another set of nodes shares, sub-shares, so to speak, of its secret share that correspond to that share verification key. So, this will be called a re-sharing of an existing share, and it actually works the same way. You can do that with Shamir's secret sharing as well. So, simply think of this secret key that the node has as an existing share that it wants to share to the receivers. So, the node can do that, and in exactly the same way as before, that can also be publicly verifiable.

So, if we scale this up, suppose we have several nodes that together hold a secret sharing of the public verification key, and they each act as dealers in their re-sharing and re-share their secret share signing key. Then what happens is actually that the receivers, perhaps new setup nodes that are supposed to take over the computation on the subnet, they will actually get the same public verification key for the subnet, but they will get fresh and new share verification keys that are public and fresh and new secret shares to match those share verification keys. So, this is something we call distributed key re-sharing. Right? So, the distributed key re-sharing is also a non-interactive protocol, right? It works pretty much the same way as the key generation protocol. You just, instead of taking a fresh random secret to share, you're taking an existing share and re-sharing that. So, this is really nice because it means that a subnet can always have a permanent public verification key, but whenever there's a change of nodes, it can actually re-share the secret shares. So, the new nodes that are coming in and taking over can get a fresh secret sharing of the secret signing key.

So, when a subnet starts out, we have some dealers that will create the public verification key together with a secret sharing of the signing key and give that to the first set of nodes running that subnet. But then, when we change nodes that are running on a subnet, those nodes can actually give the new nodes a new sharing of the same public verification key. And we can continue doing that over and over again.

So, using non-interactive key generation and re-sharing, we get very simple public key management on the Internet Computer. When the governance system wants to create a new subnet, it simply runs the non-interactive distributed key generation protocol to create a public verification key for the signature scheme that that subnet is going to use and a matching secret sharing, right, that will give to the nodes. And then the nodes don't actually have to do anything. They don't have to be involved in the protocol in any way. They can just go and get ciphertexts that contain encryptions of their secret shares, decrypt those, and then they're up and running.

Now, once the subnet is up and running, it can preserve the same public verification key over its entire lifetime of operation. So, maybe there will be a change of nodes, maybe there will be at some point less nodes or more nodes, or exchange of nodes because a node has crashed or whatever. But whenever that kind of change happens, you can just re-share the secret key and preserve the same public verification key for the signature scheme. So, for an outside user, it looks like this subnet always has the same public verification key, and there's no change whether those few nodes or many nodes are changing, threshold, lower threshold, a higher threshold, it all looks the same. You just get a signature on behalf of that subnet.

So, I want to conclude with what all this buys us, right? So, what it buys us is a non-interactive distributed key generation protocol that can create a public verification key for the BLS threshold signature scheme and provide share verification keys and secret shares for the receivers. And then we have the non-interactive distributed key re-sharing protocol that allows us to preserve the public verification key but generate new share verification keys and fresh secret shares to a new set of receivers. And that gives us both the flexibility that we can always change the configuration of a subnet, right, if new nodes come in or new nodes, oh, there's some nodes that leave the subnet, we can re-share and still have the same verification key but have a fresh secret sharing for those new nodes. It also buys us proactive security that we can keep on refreshing the secret sharing and protect ourselves against an attacker that compromises some of the shares within a given epoch.

Hello, my name is Bian Thuckmann, and I'm a cryptography researcher at DFINITY. On our path toward Mercury, I have led the research on topics related to identity and authentication. Let me explain what I mean by identity and authentication, and why we do things differently on the Internet Computer than on the traditional web.

When you log into a website today, you're likely asked for a username and password. Your username, nowadays most often your email address, serves as your identity, the unique identifier that connects all the data on the servers to you. Your password is the means of authentication. It turns out that passwords, despite their wide use, are actually not a good mechanism for remote authentication. If you follow IT news, you've certainly seen lots of headlines about attackers extracting the password databases from company A or service provider B. But even when industry best practices are followed, such as only storing a so-called salted hash of the password, recovering passwords from such a user database is only a matter of computational, and thus monetary, resources that an attacker is willing to invest.

The Internet Computer is designed to provide security against malicious behavior of individual compute providers by replicating data and computation across multiple data centers. Replication, while protecting the integrity of the data, does not protect against leakage of information. And thus, the use of passwords on the Internet Computer would still be subject to the same security issues as on the traditional web. Thus, we replace passwords by proper cryptographic authentication.

The main cryptographic mechanism we use for authentication on the Internet Computer is a digital signature scheme. Digital signatures are a pretty standard concept. They are generally thought of as consisting of three algorithms. The first one is key generation, which you can think of as an analog for choosing a password. Key generation creates a pair of keys: a private key that has to be kept secret, just like a password, and a public key that is derived from the private key but can be made public. The second algorithm is signing. It takes a message and the private key and produces a signature. When we use digital signatures for user authentication, this algorithm is run on the user side, where the private key is held. The third algorithm is verification. It takes the message, the signature, and the public key, and verifies whether the signature matches the message and public key. The crucial property here is that unlike when checking a password, which requires the secret password in clear on the server, the verification of a signature can be performed merely on public information. The server stores a list of public keys, one for each user, and neither the public key nor the signature have to remain secret.

Web Authentication is a recent standard of the World Wide Web Consortium and mainly targets two-factor authentication for web applications. Second-factor authentication means that besides the password, logging into a web application also requires an additional security factor, usually a secure device that the user owns. In practice, that could be a secure USB key or a secured chip that is built into the user's end device and activated via biometrics. The secured chip stores cryptographic keys. As the cryptographic keys never leave the secured chip, they remain secure even if the user's computer or phone is infected with malware.

When Web Authentication is used as a second factor in a web application, the protocol for flow is as follows: After the user initiated the login process by providing username and password, the web server will generate a random challenge and send it to the user's browser. The browser then sends the challenge to the secure device, which requires user interaction before it signs the challenge. The signed challenge is then sent back to the server, which verifies the signature on the challenge relative to the user's registered public key. This ensures that logging into the web application requires holding the secure device in addition to the password.

We build on the fact that Web Authentication is an open standard that uses digital signatures for authentication and is already supported on a broad range of devices. When adapting it for the Internet Computer, though, we had to overcome a few hurdles. Web Authentication assumes the session-oriented client-server model of the traditional web, where a user authenticates once when logging in with the application and sends subsequent messages within the same session. The Internet Computer, by contrast, implements a model where each request is authenticated individually. In particular, there is no server that can generate a challenge to be signed by the secure device, as there is no stateful session between the browser and the Internet Computer.

Recall, however, that in the typical Web Authentication flow, the secure device provides a digital signature on the challenge sent by the server. To implement request authentication using the same protocol, we simply use the request itself as the challenge and have it signed by the secure device, analogous to our general request authentication scheme. While Web Authentication is great for storing keys securely, it binds those keys not only to the device but also to the particular canister. The reason for this is the browser security model, which strictly separates the state accessible to different applications running in the same web browser by their so-called origin. On the web, you can think of an origin as roughly corresponding to one website. On the Internet Computer, each origin corresponds to one canister. This strict state separation is vital for security, but it also makes functions such as key backup or support for accessing the same canisters seamlessly from multiple devices tedious, since all those operations have to be performed separately for each canister.

We resolved this issue by using the identity provider, which is similar to the "Sign in with" functionality that you certainly know from the web. When a user first loads the front end of a given canister, that front end can present a "Sign in with IC" button. When the user clicks that button, the browser is redirected to the Internet Computer Identity Provider, a specific application that allows the user to manage their keys and identities. In the Identity Provider, the user can then decide whether to allow the canister front-end to use the identity. If the user approves, the browser is redirected to the canister front-end and can access the canister under the user's identity.

The Identity Provider mechanism again uses the session key and delegation mechanisms. The canister front-end generates a session key pair and transfers the public key to the Identity Provider. With the redirection, the Identity Provider, if the user confirms, generates a delegation and returns it to the canister front-end. As an additional benefit over "Sign in with," the complete authentication flow in the Identity Provider happens on the user side, so there's much less exposure of private user actions and thus much less tracking. Their mechanisms are described in detail in the Internet Computer Interface Specification that we released recently, and we're looking forward to seeing what else our developer community is going to build from it. Thank you for your attention, and I wish you a lot of fun building on the Internet Computer.

[Music]

The road to Genesis has been quite a ride, and luckily for us, we've had a chance to celebrate with our community and developers at each public release milestone along the way. Hey Alexa, do you remember our very first Copper milestone launch event during SF Blockchain Week in 2019? Absolutely, really good one. Alexa, I mean, you had just started at that time. Oh my gosh, yeah, I was two weeks into joining DFINITY, and I mean, the energy in the office was electric. I mean, everyone was so excited for this event. It was an in-person event, which of course we missed over 2020. I know, tell me about it. But everybody was so excited to see, you know, the release of the SDK and the Motoko programming language. We had some live demos at the event, and everybody was really excited about that. I mean, it's so crazy to think about, but you know, we've been shipping consistently from Copper to Bronze to Tungsten and Sodium, which brings us to today, which is really amazing. Absolutely. And of course, today, which brings us to Genesis. And I have to say that over the last year, there's been such an outpouring of creativity and innovation from the developers that I get to work with daily, ranging from creating novel apps and websites to improving the developer experience through new tools and infrastructure. And on that note, we're going to walk you through a few examples of what you can build on the Internet Computer. Let's take a closer look.

[Music]

Hello everybody. I'm here with Wackenbreitner today, and we're going to demonstrate Internet Identity. Internet Identity is an incredibly important part of the Internet Computer project. It's what end users will use to sign up and log in to hosted internet services, internet services that are built with smart contracts and that need end-to-end cryptographic security. Internet Identity actually has a pretty storied history. Um, at DFINITY, we've been working on it for a while. The version I'm so pleased to have Wacom demonstrate today, um, was really, you know, rolled together pretty quickly starting a few weeks ago to make use of a new cryptographic primitive that the Internet Computer supports called certified variables, which in turn depends on keychain technology. So, first of all, I want you to imagine a world where you can securely authenticate yourself to online services without ever touching a username and password, and without, without ever touching cryptographic key material, using just your devices. I want you to imagine a world where you can log into internet services without ever being tracked across internet services. And I want you to imagine a world where this is happening with a far greater degree of convenience than with any kind of authentication system that you use today. Um, so Internet Identities are actually just these like sort of telephone numbers, just some number that you remember. It doesn't matter if somebody finds out about the number, it's not securely sensitive. The online services see something completely different, and you can add different devices to these numbers, um, and then log in from any of those devices. Okay, over to you, Wacom.

All right, so let's see how that actually works. Logging in with these many devices. So here's one of these devices. This is a fairly standard Android phone, three years old. It's, I think, a Google Pixel 2. And I will use that to log into the Internet Identity. So this is the welcome page, and there's an option there saying, "I want to register as a new user." I have to give it a name, let's call it "Pixel," and I press register. And now it's interacting with the device, giving me login options that I can use. For example, I can use a screen lock. And this means I can now log into the Internet Identity using just my fingerprint. At the back, the fingerprint sensor is a biometric device that's unlocking access to a key pair that's been generated inside a secure TPM chip inside the phone. Right, so the next thing I get to do is I get to confirm that I want to register. So I press it again. I have to touch it a second time. So there's two touches to register. And now it takes a little while while throwing this nice spinner, and it's doing a little proof-of-work capture in a way. So this is just a little bit slowing down the registration so that we're protected against people overrunning us with registrations. And once that's done, uh, it tells me that I now have a user number on the Internet Identity, and that's the number you mentioned, on that I should remember, write down somewhere, keep it around so they can always log in again with my devices. But I don't have to keep it secret, it's not a password. So after remembering that number or writing it down, I can continue, and now I'm logged in. And this is like the main view, and I can see that I have one device so far. So that's a bit boring. So let's add another device.

So here I have a laptop. Uh, it's a Linux laptop, doesn't have any fancy security devices, but I have one of these security tokens, a YubiKey. So let me try to log in there. And I will share my screen here. So you see Firefox on my laptop. I will say I want to register with a new device. So I'm already registered, but I want to add a new device. And this is the point where I have to put in my user number, and I select continue. And now again, a device-dependent dialog pops up where I get to say, "Yes, I really want to allow the YubiKey to be used." And I touch the YubiKey once. And now it's trying to link to my account. It tells me a link that I can use on my other device, on my phone. And I could copy that. It's actually nicer to do that with a QR code. So I'll stop sharing the screen now, and I will use the camera to show what I'm doing. So I'm, I'm opening my, like, the camera of my phone. And after scanning the QR code, I'm now at a login screen for the Internet Identity. I can log in, which I need to confirm using my fingerprint. And now it's asking me if I really want to link a new device. And this is very important because let us scan some random QR code that might now be a problem. But I know that I really scanned a QR code to add the device on, on the device that I want to add. So I confirm that. And as I confirm that, and as I give it a name, we will see in the background that the browser window, once this has registered correctly, will automatically reload. And now we are at the login screen on my laptop. It knows my number. I can say login. And again, to log in, I don't need a password or anything. I just touch my YubiKey, and I'm logged in. And we have two devices now.

So this is me adding two devices to my Internet Identity, and I can add more, I can manage them, I can remove them, and any of these devices now, good enough to log into any of the internet services that are hooked up to the Internet Identity. Yeah, this is so cool. So essentially now, you, let's say you'd already signed up for, say, Open Chat using, um, your, your, your phone, um, and so, you know, you are using Open Chat on your phone because you've now added, uh, your laptop to your Internet Identity, you could now also use Open Chat from your laptop too. Um, and you could go on like this. You could imagine a world where, um, someone might, you know, be using Face ID on their phone to log into services, the fingerprint sensor on their laptops to log into services, and then maybe they're, say, YubiKey 2, which would enable them to log in from any device that they plug the YubiKey into. It gives you complete flexibility using any of your, um, any of the authenticators linked to your identity. You can, um, add new authenticators and remove existing authenticators. And thereafter, you know, you can act, you know, sign up and log into any internet service you like, just using any of, any, any of your devices. So your devices and now the authenticators, and you never have to touch a username and password or any kind of cryptographic key material. Um, you just, you just have to handle devices, which is absolutely revolutionary, not only with respect to improving the usability of online authentication but also with respect to security. So, um, we, we think people are going to be seeing a lot more of this. I think it's a fantastic demonstration too of the power of advanced applied cryptography because behind the scenes, this has been made possible and by something called certified variables, which are in turn made possible by keychain technology. So remember, you, you saw this for the first time today. Um, it's the work of the DFINITY Foundation for the Internet Computer project, and enjoy. I'm sure you'll be trying it out yourself soon. Thanks a lot.

[Music]

Hi, my name is Hamish Peebles. I'm a software engineer, and since the beginning of the year, I have been building Open Chat alongside Matt. He will show you a demo of it shortly. So, what is Open Chat? Well, it's a messaging service much like WhatsApp and Signal. But the key difference is, unlike those systems, Open Chat runs on a blockchain-backed decentralized platform, the Internet Computer. We have designed the architecture of Open Chat to initially scale to thousands of users, with the goal to scale to millions in the not too distant future, all while being free to use for your average user. Never before has it been possible to build such a scalable system on the blockchain while in turn being so cheap to run that we are able to offer it for free. Although this won't be the case initially, Open Chat will eventually become what is called an Open Internet Service. This means there is no backing company tracking and selling your data. Instead, the service is owned and managed by the holders of the service's governance tokens. And in our case, we will be distributing those tokens amongst the users. An Open Internet Service, all changes must be made via proposals which are public, and any users who want to take part in the decision-making can vote on these proposals, and only those proposals which gain enough support will be adopted. Also, once we are ready to convert Open Chat into an Open Internet Service, we will make the code public, and it will be open to contributions from anyone who wants to get involved, and we will reward those who contribute by giving them additional governance tokens. These factors are why we settled on the name Open Chat. Nothing happens behind closed doors. Everything happens out in the open, and everyone is welcome to get involved. And for those who just want to use it as a normal chat app, that's fine too. So, on that note, I'll pass you over to Matt, who will demo what we've built so far.

Hi, my name is Matt Grogan, and I'm a software engineer and a professional community member of DFINITY. I'm going to show you Open Chat. Okay, on with the demo. I'll paste the Open Chat URL into a browser. Unfortunately, this is running on my local Internet Computer replica because, at the time of recording, the Internet Computer mainnet is being bootstrapped, ready for launch. So, first, I'm going to register. I need to register a new identity, a new user with an identity service provided by the Internet Computer. I'm just going to start from scratch and register a new identity. I need to give it a name, just a friendly name, and I'm just going to use the Touch ID, which is the fingerprint scanner. I could use like a hardware security module, a USB dongle, or various, various options. And confirm and touch my fingerprint scanner. Give that a moment or two to register onto the computer. And it's giving me a sort of relatively short user number, which you do need to remember, although it's not a secret. Uh, proceed. This will be a nice Open Chat domain name, um, but for now. So, proceed to Open Chat. And I now need to register a name on the Internet Computer, sorry, on the Open Chat itself. So, for no particularly good reason, I'm going to call myself Jim and start a new chat with an existing user called Johnny. Um, "Hello Johnny, how are you?" Now, as you can see, there's a, like, a single tick appearing against these messages. That means they've been received by the Open Chat services. The second tick will mean that they've been read by the recipient. So, let's just go ahead and add a few more messages. Send an image. And I'm going to, I can also caption an image. So, I'm just going to do that. Safari. And I could send a video, any other file type. So, if it's not a media file, it'll, it'll be just sent as an attachment, which the recipient can download. Right, let's have a look at the other side of that conversation. So, I'm just going to get another window. This isn't a Chrome incognito window so that I get a different session. And this time, I'm going to use an existing user and using Touch ID. Proceed to Open Chat. Give that a moment. Okay, so you can see, let's make this a little bit bigger. So, um, looking back here, you can see these two messages have been marked as being read by the recipient. If I actually go further back, you can see these ones for the back. I still have only got one tick because they've not been read by Johnny yet. So, as I scroll back, you can see the unread count decreasing. I just need to spend a couple of seconds reading the message. Um, now, as I type a message, you can see that it instantly appears on the recipient screen. And just swap them around and vice versa. Let's.

So, yeah, sorry, as you can see, messages are being received instantly, and also typing notifications. So, as I, as I type, you can see that on the, on Johnny's screen, you can see that Jim's typing. And, you know, vice versa, as Johnny types, you can see on Jim's screen, it says Johnny's typing. So, these type of notifications and the messages are being sent using a technology called WebRTC, which is allows you to have a, to create a peer-to-peer connection between the browsers. Now, these are these connections brokered using the Open Chat service running on, um, you know, running on the Internet Computer. Um, all messages instantly go via the Open Chat services, but they also go via WebRTC if that's available. Um, so I thought, yep, if both users are online. Um, so let's have a look at something else. Um, if I go to a previous chat, as you can see, the scroll bar is, you know, takes about a third of that. There are certain number of messages that have been loaded. As I scroll up, you can see that more messages are being loaded dynamically. It's an infinite scroll. Um, that's just another picture. You can, so you can reply to a particular message. This is pretty standard chat functionality. So I can, if I just reply to that, just into a picture. I think I can't find one that's very boring. So if I now click on that, it'll take you back to the actual message you're replying to now. So let's bring a third window into play. Well, first of all, I'm just going to create a new, new group. Give that a moment to be registered. And starting some participants is okay. And now if I start. There we can see in the Poke group, I've received that message. Let me just quickly sign in on a third window. This is Bob. Hopefully, it's Bob. Proceed. Yeah, you can see that Bob's received the message too. Um, so what's going to say next?

Um, so Jim, for some reason, is being coy about this because it's going to reply privately. So typically, if you reply to the whole, you know, anybody can see it, but you can reply privately. Okay, again, a standard chat feature, but this will appear in in Johnny's, you know, in a direct chat with Johnny rather than the group chat. And then if I click on the message, it takes, takes me to that message in the, in the group chat. Um, so now let's try something else. So if I, can I, I can search chats, users, and messages. So that's just try that. If I, so it basically matches on, um, the names of chats, any messages which contain the text, and, um, yeah, any users as well that I know about. So let's just, and again, well, that wasn't particularly interesting because I've just come from there, but so, yeah, it takes me to that particular chat where that message was. And I'm not taking particular message. So search is actually something that Open Chat can do quite well. Other popular chat apps, such as WhatsApp, use end-to-end encryption to secure message data. But that means that search of messaging messages can only be done based on the data stored on the user's mobile device. However, being built on the Internet Computer, Open Chat does not need to use end-to-end encryption to secure users' messages because of the inherent security of the platform. This means the search data is available on the user's own chat canister. As I search over the user's entire chat history, as possible from any device. Now, let me show you something else. So this is a feature unique to Open Chat, well, amongst chat services, which is that you can, you can send cycles to other, um, to other users. So cycles are similar to gas in Ethereum and are used to pay for Internet Computer resources, down to the CPU instruction and byte of memory. As such, the basic unit is in trillions, or T for short. So, as a developer of the, of the Internet Computer, I'll need to, I need to hold, you know, developers need to hold wallets of cycles to pay for the running of apps. Um, now, there's a whole story around voting tokens, token economics, and cycles, but in short, users can buy ICP, Internet Computer tokens, ICP, or in the future, Open Chat tokens, when it becomes an Open Internet Service. Um, and these ICP can be converted into cycles. And potentially Open Chat will give away, um, its, you know, voting tokens to, uh, early adopters or some proportional photographs to their doctors, which users can then convert into, into cycles. So, a trillion cycles can be bought for roughly a dollar's worth of ICP tokens.

And in the demo, we've basically given every user 10 T, 10 trillion cycles to start with. Um, so it's also showing it just happens to show the conversion into the audio into your local currency. Um, this is, you know, how much it would, that would cost, um, in pounds. Um, yeah, so it's getting easier for you to get a feel for the number of cycles your, the amount of cycles you're holding. Um, so let's just send, let's just send Jim 1.5 trillion. Let's do that. And.

So, if we look at yesterday's, sorry, if we look at my balance now, you can see it's Johnny's balance is down to 8.5. If you look at Jim's balance, you can see that's up to 11.5. Um, okay, that's all I'm going to show today. Hope you've enjoyed it and enjoy the rest of the show.

Hi, I'm Brendan Foley, Vice President of Product here at DFINITY. The Internet Computer is the world's first blockchain that runs at web speed and can scale its capacity without bound for any application. In building open apps on the Internet Computer, developers can use tokens to attract and incentivize users and others, creating viral loops that deepen engagement and attract even more users. In this demo, we'll see the power of tokenization through CanCan, a social media app that we've created. This is just one example of the types of apps that you as a developer can build, and which can only be done end-to-end on a scalable blockchain such as the Internet Computer. I'll now hand it over to Andrew, who will walk us through an example of CanCan.

Thanks, Brendan. So, how do you, an entrepreneur, create habit loops and user buy-in? We've given it a shot, and we'd like to show you the latest version of our video sharing app, CanCan. First, let's go through the sign-up flow. Signing up for a new service on the Internet Computer can be as easy as a few clicks and a touch of your fingerprint. Let's go ahead and register as a new user. Here, we give it a name. I'll go ahead and say this is my work laptop. And next, using either a USB security key like YubiKey or a device's biometric sensor, you can create an identity with the Internet Computer. It asks us to confirm, and we're registered. Now, let's go ahead and get back to CanCan. Right now, it's checking to see if it already knows of an identity that is connected to a username in CanCan. These are mapped one-to-one. Since it doesn't find one, I get to create my username and sign up with the application. Great. So, let's go through the upload flow. It's important for users to be incentivized to upload content that contributes to the overall experience. I'm going to select a small video here, add a caption, and upload it to the back end. The video is being chunked into 500 kilobyte segments just to be stored on the back end more efficiently. And then, if we scroll down, we can see our video. We introduced a new concept in this iteration called Super Likes. You incentivize your users to ride the hype train. In CanCan, we've set it up so that each user is allowed 10 Super Likes per 24-hour period, tracked by the CanCan service written in Motoko. The service keeps track of Super Like events and is able to verify if a user has already met their Super Like limit. Users can be rewarded. So, let's go ahead and give a Super Like. Nice. With enough Super Likes, a video can become viral. This status is also tracked in the back end and updated with short polling via the UI. If a video goes viral, you're able to reward early Super Likers by granting them rewards. And of course, we wanted to make it exciting for our users. If you particularly like a user's video, you're welcome to send them reward points via tips too. After a user has accumulated.

A number of award points. Kancan will periodically emit a Dropday event, which will allow those users with reward points to redeem them for unique items. Here, the limit of what you can offer your users is only your imagination.

In the future, we plan to add the ability to receive Can-Can governance tokens, allowing you to become part of not only the community but also the platform itself. And now, Brendan will show you the rest of the rewards experience in CanCan that uses tokenization to incent users, advertisers, and others. Take it away, Brandon.

Thanks, Andrew. I'll give a preview of the Dropday experience and other things that we're working on. We haven't yet built these features into CanCan, but these are the types of things you can easily build in your own Internet Computer app.

So, Jim sees that today is Dropday. And in clicking on this, Jim sees that he has the option of redeeming his rewards for either Can tokens or prizes offered by advertisers. Jim is curious about the Can token, so he clicks on the question mark, and he can see the latest information on Can tokens that trade on crypto exchanges. He decides he wants to redeem some of his rewards for Can tokens. He inputs 100 reward points, uh, hits exchange, and he sees that the exchange rate is for 100 reward points, he would get 1.027 Can tokens. He goes ahead and hits exchange, and he sees that the Can tokens have been deposited into his wallet. He can now choose to either trade these tokens or hold them to participate in Kancan's governance and earn rewards for doing so.

Jim decides to exchange another 100 reward points for a compression zip t-shirt. The advertiser can now use the reward points that they've received from Jim to purchase advertising on the app. So, as Jim and other users browse, they'll see advertisements from the company in their stream, like the one that we see on the screen.

Users can also be incented to moderate content on Kancan. In the profile settings, a user can opt in to receiving newly uploaded but unmoderated content in their feed, so long as they verify that they're 18 years of age or older. When they see content which they consider inappropriate, they can flag it, like we see on the screen. If a threshold of other moderators also flags the content as inappropriate, the user will get a reward for taking action.

We've seen in this demo of CanCan how you can build powerful consumer and other open internet apps end-to-end on the Internet Computer, but also use tokens to attract and incentivize users, advertisers, and other audiences to your app to build and expand on its user base. This is just one example of what you can do on the Internet Computer. We look forward to seeing what you build, and thanks for watching.

[Music]

Hi, my name is Stanley Jones. I'm Director of Engineering for Developer Experience here at Dfinity. In this demo, I'll be showing how developers can start deploying their software onto the Internet Computer. It's really just three steps. First, we'll need some ICP, the utility token of the Internet Computer. Next, we'll convert some of those ICP into cycles, and finally, we'll use those cycles to deploy our software. Three steps: tokens, cycles, software. Let's get started.

Step one is tokens. There are a few different ways to get ICP, and they're all out of scope for this particular demo. So, let's assume that we've already got some and focus more on what we can do with them as a developer. If you haven't installed the Dfinity Canister SDK yet, go ahead and do that now from sdk.dfinity.org, because we're going to need it for our next step.

ICP transactions are recorded on the Internet Computer's ledger. It's a special canister or service running on the Internet Computer. We'll need to transfer our ICP to our developer account, because right now, on the IC ledger, the account that holds our ICP is probably different than the developer account generated for us by the SDK. You can do this using the utility most appropriate for your custody solution, but first, you need to know where you're sending it. On the IC ledger, bundled with the SDK is the command-line utility DFX, and we can use it to get the account ID of our local identity. Great.

Now, once we've transferred some ICP to that developer account, we can confirm the balance also with DFX. Wow, yeah, that's more than enough for our purposes.

Step two is cycles. Cycles are how canisters pay for computation, transactions, and storage. Unlike ICP, which live on the IC ledger, cycles live inside the canister they pay for. We'll want to convert some of our ICP into cycles, but we also need a canister to receive them. To make managing cycles easier, we can store them in a special canister called a cycle wallet. Let's deploy our wallet to the canister that we just created with just a couple DFX commands. We've told the IC ledger to create an empty canister for us, fill it with cycles converted from the amount of ICP we've specified, and installed the cycle's wallet module in it. Let's check our cycle's balance. Yep, looks like we've got, uh, lots of cycles. So now we can use our cycles wallet to pay for other actions on the IC.

Step three: software. All right, we've got tokens, we've got cycles. Let's deploy some software. I'm already in the Hello World example project created by DFX. So, to deploy my software, all I have to do, again, a single command. It's doing a lot for us. Our Motoko source code is compiled into WebAssembly modules. We've told our cycles wallet to create new empty canisters for them. Then it transfers some cycles to the new canisters so that they can pay for their own computation, transaction, and storage. Finally, we install the modules to the empty canisters, upload any static assets, and our app springs to life. So there you have it, from installing the SDK to deploying Hello World. I can't wait to see what you build. Welcome to the Internet Computer.

And we are back with another giveaway. This time, we have 500 Internet Computer genesis-themed backpacks to win. One, scan the QR code on the screen now. Again, only the first 500 community members will snag one of these, so you may want to move quickly. Once you receive your backpack, we'd love to see your photos on Twitter, Reddit, and Instagram, and don't forget to tag us.

Hi, my name is Taylor Hamm, and I'm a front-end engineer here at Dfinity. Today, I'm going to walk you through the simple steps to deploying a static website on the Internet Computer. Static websites are generally websites that every user who visits sees the same content. They're not interacting with APIs or databases much, and they typically are comprised of HTML and CSS with light JavaScript. I'll walk you through how to use our built-in asset canisters to easily deploy these.

Okay, so you can see here that I have built a static site. I'm using Gatsby. It's running on my localhost development server, and the topic at hand is deploying sites to the Internet Computer. How convenient. With that, let's get started.

Okay, so our first port of call is to install DFX. So, let's copy this command into our terminal, paste, and hit enter. It'll ask us if we agree to the license. We'll hit Y for yes and hit enter. And after a few short moments, DFX will be installed.

Now, we'll move on to step two. Create a dfx.json file in the root folder of your project. So, I'll come over here to my file view, and in the root, I will add a new file called dfx.json, and then we'll grab this content and we'll paste it into our file.

Now, what we've done here is instructed DFX that we want to build a canister. That canister is going to have a name, www. You can name it whatever you want, and the real magic happens when we tell it to be of type assets. Now, an asset canister is a special thing on the Internet Computer that has built-in store and retrieve methods for anything that you plop into your source folder. And the source folder is going to point to your build output for your site. And since I'm using Gatsby, that is my public folder. So anything I put in this public folder will be uploaded to the Internet Computer and accessible to my canister.

Now, we'll move on to step three, which is to deploy. So, make sure we're in our project in our terminal window, which we are, and we'll paste this command here. And you'll see a couple things start to happen. First off, a DFX folder was added to our project, and we've started creating canisters, provisioning some space on the Internet Computer for our canister, and we just had a canister_ids.json file pop in because we've created a canister ID. And we actually need this for our next step. It says here we need to check the output and grab the ID on this line. So, right here, we've got our canister ID, and we're going to copy this five-segment alphanumeric code to our clipboard.

And now we're installing our code, authorizing our identity, and finally, we'll upload our assets. All right.

So now that our canister has been deployed, we can move on to step four, and that is to visit our site. All right, let's open up a new tab and let's paste in our canister ID from the last step and add ic0.app and hit enter. And boom, there you go. Look at that. Our website is now live on the Internet Computer, just as it was locally.

And now we can go to the final step, step five: celebrate. Spread this link far and wide and brag to all of your friends about joining the decentralized internet revolution. So now you've seen just how easy it is to deploy static websites to the Internet Computer. And with DFX installed, all you need to follow are steps two and three to repeat the process for any other sites you want to host on the IC. Thanks for following along.

[Music]

Hello, I'm Kyle Peacock, and I'm a front-end engineer on Dfinity's Developer Experience team. In this talk, I'll be going over how to build a front-end application on the Internet Computer. I'll start by creating an application using Gatsby.js, which is a React framework, turn that into a generic static site, which we can then deploy to the Internet Computer. And then, in part two of the talk, I will show how to build some application logic, add a backend service using Dfinity's Motoko language, and then connect the two so that you can have a full-stack application that runs entirely on the Internet Computer using decentralized services and smart contracts.

To begin, let's walk through the steps of how to deploy a simple front-end website to the Internet Computer. I'll start by using the default Gatsby starter, which is a React framework that builds to static HTML, CSS, and JavaScript. Then I can add a file to my folder, name it dfx.json, and configure it to generate an asset canister, which will load the compiled Gatsby site. Now, by running `dfx deploy`, I can build an asset canister with our static website. You can see it here, running on my development environment. Nice and simple.

So, the next step that I would like to have us go through is to show how to take an application that we can develop and make it talk with a backend canister from the front end. So, this is where we go from deploying a static asset to the Internet Computer to now demonstrate how to make dynamic calls using the Internet Computer as your backend. In order to make this happen, we'll need to make a few changes. First, this whole application is not going to be the most complete, um, and obviously it's just branding for Gatsby. So, thanks Gatsby, we're going to move on from your application now.

I'm pasting in an application that I've already written. It's basically going to be a contact card. That's why we named this Contact App. So, it'll have a simple form where you can upload some information, and you can persist that information, obviously, in a number of different ways. If you're doing a prototype, you might want to store that information in local storage. If you want it between sessions, uh, you might also reach to another tool such as Firebase or a MongoDB Atlas instance. Here, we'll be using a simple Motoko canister that will have a key-value store for us.

So, to configure that, we're going to add a backend folder to our source directory, and we'll name this Contact App. Inside of this folder, we'll add our main.motoko file. And here, I also have a pre-written snippet of code, but it's pretty simple, so we can walk through it here. Motoko allows us to declare an actor. This is the basic model of Motoko, and it is our recommended model for interacting with the Internet Computer. That said, there are plenty of other ways that you can write besides Motoko, and we have healthy Rust communities, see demos in C, and we expect that many more languages will be supported over time as the communities attached to them. The only requirement is that your code compiles down to WebAssembly, which is what runs natively on our canisters.

So, here we have a stable var entries. This represents, um, the way that the code is persisted across upgrades. It's really an important and key feature of the Internet Computer that we can allow you to upgrade your contracts and your canisters without losing the information there. And then our store is an interface that will sit on top of our entries of a hashmap. This should be a very familiar format for various languages, and it'll allow us to have a nice set API using the store.replace, key, value, a get query. And then we have two utility functions down here that are around persisting data during an upgrade.

Now that we've added this main.motoko to our source directory, now we need to update dfx.json to be aware about it. So, we'll add a new canister here, Contact App, and we'll just tell it main has an entry point of source/backend, pointing right there at our logic. So now we have our Contact App, which is going to give us a very simple text-based key-value store. And I'm going to use this interface in much the same way that you might use local storage, wrap any code that I've got, put it in a JSON encoded string, and write it to the backend. There's going to be a couple extra steps in order to get this up and running.

So, we've just done our dfx.json. Now we need to tell Gatsby how to interact with our new code that we're adding. So, to gatsby-config.js, I'm going to add this proxy information. This will point to localhost:8000, which is where the DFX replica runs during local development. Let's go ahead and start that now. I start the local development replica by running `dfx start`, and I'll run this in the background.

Now that DFX is running in the background, we can build our Motoko backend by running `dfx deploy`. This is going to read from our Motoko file, and it's going to do several things for us. It's going to create this DFX hidden folder with a bunch of cached information, and it's going to give us environment-specific information such as canister IDs, as well as generating code based off of the types that we used inside of our Motoko file. That is going to give us information that we can then use for our assets canister. The candid file ends up looking like this. So, we have a service that we've generated with a get method and a set method, telling us about the information that it takes to interact with that. And then that turns into a [Music] custom file that we will sort of take from you and abstract into a nice interface that you can use in your codebase.

So, because these files are here, we have a small configuration that we're going to do to extend the webpack config, and we'll do that here with gatsby-node. This is platform-specific, so I won't dwell on it too much, but that code will look like this. The key bits of information are that we are reading from dfx.json and using those values to create an alias of dfx-generated, and then we're attaching that alias into our webpack config, and we're also covering for a dependency that requires us to do this resolve pattern for the moment.

So, with gatsby-node configured, now we can go ahead and add to our source a new file, actor.js. And this is where we will interface with the canister. So, actor is fairly simple. It'll look something like this. So, we start with this import, which we will need to install, and then we'll also take advantage of the new alias that we just added. Next, we will go into at initialize an HTTP agent and pass that to our create actor factory. And this is all the information that we need to create our actor object. This actor will now be something that we can call using actor.get or actor.set, and it will return a promise that we can interact with to store and persist our value on the Internet Computer. The get call is going to make a query call, which should be quite fast, and the update call will probably take a few seconds in order to persist the information. Finally, we export our actor from this file.

Now, to show how we can use this actor, let's take a look at our main logic. So, here in our application, we have a contact card. This is going to simply display the information. And here we have our index page. I'm importing the actor that we just wrote and then storing it. One note, just for anyone who's curious why I would do this instead of a traditional import, is that Gatsby does server-side rendering. So, this is just a way of delaying the import until it's needed. After that, we save the actor. And now we have logic for when we submit. We'll take all of the information out of our application and then to store it, we call actor.set and we pass in the card information, which is going to be a simple object, and then we clear our, do some cleanup. It's going to be very similar here. We have a get card function where we call actor.get, dot then returned card, and then we'll set that into state and displayed on the page. Very straightforward promise-based syntax, also friendly to async await.

And let's see what that looks like now. And here we have our application. And just like that, we've uploaded that contact to the Internet Computer. Now, I'm going to look up that information and do our get using the email address as a key. And with that speed, we've now got our contact. And that is an example of doing front-end development on the Internet Computer. To deploy, we would simply do the same process as we did with the static build, all of the files, and then upload them to an ic0.app where we could use them on the public internet.

Now that we've taken you through what's possible on the Internet Computer, and more importantly, how you can actually build on the IC, we want to hear from you. Michael, do you remember when we first launched our developer forum at the end of 2019? I think at that time, it was just team members and a few OG developers. And now we have over a thousand people in the forum and 600 different threads. Yeah, absolutely. I mean, I'm constantly in awe when I see all of the new faces and threads on the developer forum. Mostly, I'm just reminded that each one of those threads represents someone who, you know, has an idea, they have a dream, pretty much for something they want to build and bring into this world. So, you know, to all the new members, I just want to say welcome. The Dfinity Foundation is here to help. The community is here to help. And there is no time like the present to start building and to connect with other developers building on the Internet Computer or ask questions directly to the Dfinity team. Please visit us at forum.dfinity.org. We can't wait to see the creative and innovative websites and apps that you'll build on the Internet Computer.

[Music]

[Music]

[Music]

I'm Andreas Rossberg, and I'm one of the main designers of Motoko, Dfinity's new programming language for the Internet Computer. And I'm also one of the co-creators of WebAssembly, the new code format that runs in all your browsers nowadays. If you're a programmer who is familiar with the common breed of mainstream programming languages like Java, JavaScript, or C#, then you should feel familiar and at home pretty quickly with Motoko. In particular, we took out all the special knowledge that you might need to have on other blockchain programming languages. None of that is needed with Motoko. You can just use it as if it was an ordinary programming language.

The Internet Computer adopts WebAssembly as its virtual machine, which means that there aren't that many languages available yet that is independent of what the platform actually is, what hardware you're running on. It's like a virtual processor. One central design decision with Motoko was that it's going to be a typed language. Over the last one, two decades, there has been a rise in the popularity of dynamic languages like JavaScript and Python, and these, but it turns out usually this approach doesn't scale well. And we also wanted a language that is perfectly adapted to the environment of the Internet Computer, which, once you write larger programs with larger teams that evolve over a longer period of time, the lack of type system support can really get in the way because it becomes harder to maintain these things. It becomes harder to communicate intent between different programmers on the team and in the documentation. In the case of Motoko, there's no way around the type system that would allow anybody to break these properties, not yourself, but also no library code you might be using or anybody else. So that is a very important factor for us to providing these safety guarantees.

One of the central features that Motoko provides is the notion of an actor. So, an actor is like an object that you can send messages to that is built into the language and maps to the platform nicely. We have built-in syntax for expressing actors, sending messages, defining message receivers, for accessing the context that is available about the message. We also have special language features that allow you to program with this asynchronous messaging in a more natural, direct style, like the notion of a future or an asynchronous computation. For example, the Internet Computer is structured around the notion of a canister. The canister, so you can think of as its own distributed application, but it's not an isolated application on the Internet Computer. These applications can communicate with each other through messaging. And Motoko is designed to map this notion of a canister directly onto the notion of an actor in the programming language. So, you can have multiple actors, which are kind of like multiple applications or servers communicating with each other by sending messages to each other.

The Motoko compiler takes your source code, runs it through a parser, generates some abstract syntax tree, does type checking on that, all the usual things, except that in the end, what it spits out is not machine code, but it is WebAssembly code. And that's very much by design. Since the platform is open, these other canisters are not necessarily actually programs written in Motoko. They all just are based on WebAssembly. That's their basic language. And then on top of that, we have this messaging system where a Motoko canister can communicate with canisters written in any other language. This interface definition language, again, is completely independent of Motoko. So, any language that you use to write an application on the Internet Computer can communicate through it.

One thing that developers will probably find interesting about Motoko is that it supports orthogonal persistence. Orthogonal persistence is an old idea where a program basically stays alive. So, when you write a Motoko program, you don't have to deal with a database or file system to store your data, to save it to. You just imagine that you're working with the data structures that your programming language provides. This is inherent in the Internet Computer platform, and Motoko makes use of that.

When you think about startups, concepts like fundraising, exiting, and equity come to mind. Now that blockchain platforms like the Internet Computer are maturing, founders are electing to build companies on new open internet infrastructure. This shift is changing the narrative arc of company building that Silicon Valley knows and loves. Recently, we organized a Dfinity event called "Exploring Entrepreneurship in the Open Internet Boom." At the event, we interviewed six entrepreneurs who are taking advantage of this opportunity to build big startups without big tech. In fact, these founders have already scored venture capital fundraising for startups created on the Internet Computer. The panelists discussed how startups are navigating concepts such as network scale, geo-agnosticism, self-sovereign identity, and decentralized social media. Let's look at what a few of the founders, technologists, and venture capitalists exploring these uncharted opportunities had to say.

Founders are seeing opportunities on par with the dot-com boom in the '90s and mobile in the early 2000s. When business models don't rely on ads, when revenue doesn't depend on marketing, when fundraising can come from anywhere, and when talent is globally distributed, the startup playbook is flipped on its head. Concepts like fundraising, exiting, and equity are being reframed. The narrative arc of company building that Silicon Valley knows and loves is shifting.

[Music]

How does a pitch deck for a company building on the open internet differ from a traditional startup's pitch deck? So, I think for any founder that's thinking through how to structure their pitch deck for an open web startup or a DAO, which I'll use synonymously with open web startup in this conversation, a lot of the same elements are going to appear in the pitch deck as would in a traditional startup company. So, in any case, the investors are going to want to know the core thesis behind the project, a description of the product, who the team is behind the product, um, some analysis of the market size. And I think all of that will be kind of consistent across the two. Where things start to really differ is around kind of the financial or economic slides, as well as user growth strategy.

So, one way to think of this is in the Web2 world, or the traditional startup world, a pitch deck would sell kind of what the lifetime value of a customer would be, or its LTV. It'll look at stats like the cost of user acquisition and kind of go to these basic business metrics to understand what are the unit economics of this business. Um, broadly, what's being done here is you're trying to convince investors that the ability to develop these network effects in your company are effective, and when you develop these network effects, you're actually going to monetize those effectively as a business. The typical VC model is companies raise a lot of VC money and then effectively give it away to early users as a way to subsidize those users to come onto this network. You can see this in many forms, such as referral fees to users, customer credits, discounts. Sometimes companies even give users cash directly. You could see that in the case of neobanks and fintech businesses.

Now, flipping that to open web companies, you still have the same broad goal of developing network effects, but the interesting thing here is you actually don't need to give away VC money to incent users to a new platform. You can actually build a system which rewards and incentivizes early users in the protocol or DAO itself. And you do this through a crypto mechanism called liquidity mining. Early users that come to a new platform earn a form of equity in that platform.

Some blockchain projects have the potential to completely upend the architecture of the internet and redesign networks and business models that are not hindered by demographics or geography. How should open internet founders explain TAM? I think a great historical example here is when you look at applications like Uber or Airbnb. It was easy in the early days to say the TAM of Uber is the largest taxi company, or the TAM of Airbnb is the largest hotel business. But in fact, that was massively underestimating, um, the true size of that market because those businesses enabled new behaviors that were sort of unprecedented. They actually expanded the size of the market as we know it today.

[Music]

The other thing you mentioned, D-fire, a lot. Well, Silicon Valley became big because it was all about the physical proximity of people. You know, 30-mile radius for VCs. I remember speaking to a VC who would only invest in startups that he could skateboard to. What's, um, what effect do you think this decentralized route is going to have on founders? I mean, you know, we're talking about new kinds of apps and platforms being developed basically anywhere. It's going to have an absolutely tremendous effect and be very impactful in a good way. So, one of my personal tests for the success of the Internet Computer is that it would enable somebody who's smart and determined in a developing world nation, um, such as, you know, a computer nerd based in Lagos, Nigeria, to build, launch, finance, and make successful a mass-market internet service. So, with the Internet Computer, someone is going to be able to build an internet service using, for example, a low-cost Chromebook where they just write smart contract code, push it straight up onto the Internet Computer, and get their prototype internet service going, and convert it into an open internet service. So, start selling the governance tokens to, um, you know, raise funds for development, or using the governance tokens to incentivize other developers, uh, all around the world who are connected to the internet to start participating and building out the internet service. So, I mean, one of the biggest challenges that I hope we can fix is that today, you know, only a small fraction of the world's potential talent is able to have a shot at building an internet service. And for the most part, it's people located here in Silicon Valley. You can do it in Europe, but it's much harder. Um, but in other places, it's, you know, several times even more difficult. And the Internet Computer can help level the playing field so that, you know, the remaining 99% of the world's talent gets a shot at building the internet of the future.

[Music]

So, this concept of an exit is completely flipped on its head. So, you know, a founder is no longer in this infrastructure attempting to develop a technology and then, you know, seven years later, sell it to Google for $50 million, $100 million. An exit in this Web3 space is, you want to exit to your community. Regardless of the platform, regardless of the application or the use case, whether it's a DeFi protocol, or whether it's, you know, a new open version of YouTube or Reddit or whatever, um, the goal in this space for all entrepreneurs should be figuring out a way to eventually be able to exit to your community and early users. And then instead of, you know, you hiring a marketing team and trying to acquire all the users yourself, your users, your community, essentially become your marketing force. It's not like Bitcoin is paying a marketing agency to market Bitcoin. Every single person in the world who holds Bitcoin is the marketing department for Bitcoin. And that is much stronger and much more effective. When we look back 20 years from now and understand like, how did these tech giants go down? It's like, oh, they lost to these new newcomers who actually distributed value fairly to everyone involved who was adding value to that network or platform. Like, oh, well, that seems obvious.

I simply don't think that, I mean, looking at something like a decentralized social network and saying that it's going to have the same adoption as, um, Facebook or Twitter, or Instagram, is basically to me like saying that a vegetarian restaurant is going to have the same allure as McDonald's. Um, I don't think that's necessarily true, and I don't think that's what vegetarian restaurants are setting out to do. I think that they're setting out to offer something that is perhaps healthier for you, perhaps better for the environment. And, uh, if you aren't interested in that, there's no shame in going and getting a Big Mac, right? It's what matters is the choice. If you care about these things, if you think that society is better served, the planet is better served, your social circle is better served by making these choices, you can go down the capsule route, the vegetarian route, I guess. And that can have a significant impact on the way that you write and discuss and share content and interact with people on the internet.

[Music]

Robinhood has been under scrutiny from regulators and users alike. Recent issues have ranged from platform outages to selling order information to high-frequency traders to backlash for restricting trading of certain stocks like GameStop. As founders of a decentralized exchange, what do you think Robinhood could have done better? So, one thing that, as a centralized exchanges have, they have some limitations. If it is a technical problem, then they could have anticipated this demand. They could have architected a little differently, more robustly, so that when the, when there's a lot of people trying to summon order, then there are ways to handle this a little more gracefully. And fundamentally, too, um, decentralized exchanges don't have that problem, right? We are, a lot of these central components are actually running on, say, the Dfinity Internet Computer or on decentralized blockchains. Those are pretty much always up. So, if you architect around more decentralized components, then you offload that to a really resilient system because blockchains aren't just running one exchange, they're running the whole Internet Computer or a ton of different apps, and they all have to run.

Microsoft bought LinkedIn for $26 billion, and LinkedIn has reported that it sees 260 million monthly active users. So, those are both pretty big numbers. Tell us, what is wrong with LinkedIn, and why do we need a decentralized version of a professional social network? What's wrong with LinkedIn is basically, if you look at the core of the issue, what's wrong with all social media networks right now, um, there's obviously data issues, privacy issues. We have a lot of misinformation. We have the platforming going on. It's, it's an ongoing conversation, um, and it all, uh, sums up to the fact that they're centralized and built on this, uh, proprietary systems. There's a need for a platform like Linktop. We need to enjoy social media. There's nothing, uh, a problem with the social networks themselves. We need a place to showcase our talents, to talk about our achievements. There's a lot of positive things that a professional social media network can do for the world. But we don't need to pay for all those benefits with our data and our privacy. We can actually have them enjoy them and, you know, have the dignity of owning our data and the power of controlling those platforms.

From the very beginning, the concept of the Network Nervous System, or NNS, has been one of the most compelling parts of the Internet Computer to our community members. It's also a topic around which I get a lot of questions. Is it an AI? Is this the beginning of Skynet? Who truly controls the network? And the developers I work with often bring up the NNS because they're super interested in this idea of having a say in updating and implementing the parameters of a platform that they build on. So, they're actually, you know, contributing to the code of the Internet Computer, which is so exciting. What I personally think is super interesting about the NNS is that it's one of many ways in which the Internet Computer is actually decentralized. True, true. And, you know, I know Dominic Williams very early on in the history of Dfinity wrote, um, a pretty simple blog post about, I believe at that point it was called the Blockchain Nervousness. That's right. And community members really dug into that, and they really wanted to see that fleshed out more. So, I know I'm really excited for being able to share a little bit more about the Network Nervous System here at the Genesis launch event. Yeah, and Dominic actually just, uh, tweeted recently too about something called the Service Nervous System, which is sort of his vision for how governance at the app level is going to play out. So, I know a lot of the developers that I speak with are really excited about learning more about the SNS. Absolutely. And, you know, I think that's going to be a really important conversation too, because that's going to allow the developers and entrepreneurs out there to really start digging into some of the different business models, um, that they are to be found utilizing something like the Internet Computer. Absolutely. And we have something to share today too on the NNS. Well, let's start by demystifying the NNS a little bit. To put it simply, the NNS is the autonomous software that governs the Internet Computer and manages everything from economics to network structure. And the reality is that we are all stewards of the Internet Computer. Token holders use the NNS to initiate or vote on proposals that can change the very parameters that make the IC tick. They can even earn rewards for voting and being active stewards. Up next, we'll discuss how to participate in governance on the Internet Computer and answer more of your long-standing questions on this topic.

[Music]

I'm Larash Mead. I am a researcher at the Dfinity Foundation, and today I'm going to present to you the Network Nervous System of the Internet Computer. So, on a high level, the Network Nervous System, or also called NNS, is realized by a set of canisters. And we will shortly see this in more detail. Now, for making decisions, mainly two canisters are important. The first one is the governance canister, and the governance canister stores two things. First, it stores proposals, which are basically just suggestions how the Internet Computer should be changed. And these proposals can then be voted on. And second, it stores so-called neurons, which determine who is allowed to participate in governance. The second canister that is important is the registry canister, which basically stores the configuration of the whole Internet Computer that can then be looked up by others. So, it stores, for example, the information that the subnet S3 consists of these four nodes. Next, we will look in more detail what the canisters on the NNS store and how they work. And first, and also as a prerequisite to understand what these neurons are, we will now look at tokens, which are the currency of the governance system.

Tokens are managed by yet another canister on the NNS, the so-called ledger canister. And the ledger canister stores two things. First, it stores accounts, and then it stores transactions. An account record keeps track of how many tokens are in the possession of a given principal, and it also denotes an account address. So, by principal in this context, I just mean an identity by which a user is authenticated on the Internet Computer. Tokens can then be sent from one account to another, and this is recorded in the transactions of the ledger canister, as can be seen here on top.

Now, as already mentioned, the tokens are the currency of the governance system, and in particular, they can be used for three different things. First, the tokens facilitate participation in governance. Second, both those who participate in governance and those who provide compute capacity by operating node machines are rewarded in tokens. And finally, tokens are used for buying cycles, which are basically the fuel for canisters. So, this is the fuel for making computations and storing information. And in the remainder of this talk, we will look at all of these three things in more detail.

So, first, we'll look at how tokens can be used for governance, so how they can be used to add proposals and to vote on them. We have already mentioned that voting is done based on neurons, and the high-level idea is that those who have more tokens have more voting power. So, decisions in the Internet Computer are made based on a stake-based model. However, neurons do not correspond to tokens, but neurons actually contain locked tokens. So, this means that these tokens are not liquid, and they cannot be transferred freely to others.

So, in more detail, a neuron stores the following information. First, it keeps track of how many tokens are associated with the given neuron, and it does so by just referencing an account on the ledger. Second, it specifies a principal ID, which basically just identifies a public key. And finally, it also specifies a neuron ID that is unique. So, actually, there are some other parameters associated with the neuron, and one of the most important ones is an earlier state when the tokens can be unlocked. And the idea of this is that only those neurons who still have their tokens locked for at least six months are actually allowed to participate in governance. And this incentivizes the neuron holders to vote such that the value of their tokens are maximized for a future date. And if the value of the tokens is a rough estimate of the network success, this incentivizes voters to vote in the long-term interest of the Internet Computer. So, apart from the amount of tokens that are locked in the neuron, the voting power actually also depends on some other factors. But let's just assume for the remainder of this talk that roughly the amount of tokens is the voting power.

Controlling a neuron enables users to submit and vote on proposals. And to understand how this works in detail, let's first look at what proposals actually look like. So, this is best done on a concrete example. So, let's consider the example of a proposal where it is suggested that a new subnet is created that initially consists of two nodes, the node with ID 1 and ID 2. So, a proposal specifies first a proposal type, and basically, this just describes what this proposal is all about. But technically, this type describes a method in a canister that is to be called if the proposal is accepted. So, in this example, if this proposal is accepted, the `create_subnet` method of the registry canister will be called. And to call this method, we also need to know its parameters, and this is what is described in the second line. So, here the parameters give the two nodes that should be the initial nodes of this newly created subnet. And also, together with the proposal, the governance canister stores how many votes it has already received. So, in this example, it already received 250 yes and 100 no votes.

Now, let's look at the example where a pink user would like to suggest that a new node should be added to a subnet. Once the user controls a neuron, he can then submit a new proposal by specifying the neuron ID, the type of proposal that he would like to submit, and also the proposal's parameters. So, in this example, the user suggests to add a node. So, the specified method name is `add_node`, and the parameters define which node should be added to which subnet. And upon the receipt of this proposal, the governance canister checks that this user is indeed the controller of the neuron and that this neuron is eligible to vote. And if this is the case, the proposal is added to the governance canister. So, actually, whenever a proposal is added, the number of yes votes are already set to the voting power of whoever submitted this proposal. So, basically, this just means that this proposal already has the support of 100 tokens that are coming from this pink user.

So, after a proposal is then submitted and added to the governance canister, other users that control neurons can vote on it. And we will here look at an example of an orange user that controls the orange neuron. To vote, a user would first ask the governance canister for the pending proposals to learn what she can actually vote on. And let's just assume that the orange user now would like to reject the proposal that we have just added. So, to do so, she would send her neuron ID and a no vote to the governance canister. Again, the governance canister would check that this is the user controlling the neuron and that this neuron is eligible. And since this is the case, it would then add the voting power of the orange user to the no votes. And similarly, other users would also send votes. And let's just assume that at one point, the majority of the voting power is actually in favor of the proposal. So, what would then happen is that the proposal will be executed, which means that the described method will be called. So, in this example, the `add_node` method of the registry canister will be called with the specified parameters, and the effect of this would be that the node would now be added to the subnet.

So, the incentive for voters to lock their neurons is actually not only so they can participate in decisions, but on top of that, participation in governance is also rewarded. So, this brings us to the second use case of tokens. Rewards depend on different parameters, but one of the most important ones is in how many of the possible decisions a neuron has participated in. And to enable rewards, a neuron actually calls a so-called majority, which roughly depicts how many rewards this neuron has already gained. So, this slide only depicts this for the pink neuron, but actually all of the neurons would have such a majority associated with them. And to collect rewards, a user can then do the following: he can send a command to the governance canister to spawn a new neuron.

And the effect of this will be that a new neuron with a new associated account on the ledger will be created. And this new ledger account now contains the rewards. So recall that before, the majority said that the user has already collected rewards worth two tokens. And these two tokens are now contained in the new ledger account.

Technically, what happens if this is done is that new tokens are actually minted and transferred to the new account. And this is also recorded in the ledger canister, as can be seen here. And this new neuron actually has a small dissolve delay, which means that very soon the user is able to unlock the tokens and use them freely for any purpose that he wants.

Now recall that voters want to participate in voting because they get voting rewards. However, it could well be that a user does not have time to participate in all the decisions. And also users might not feel comfortable to make certain decisions. And therefore, the Internet Computer facilitates liquid democracy. So what this means is that a neuron can specify that it would like to follow some other neurons, which are called the followees. And the governance canister would know this. And whenever a majority of the followers would send the same vote, the governance canister would automatically also send this vote for the follower neuron.

So, in the very beginning, I said that besides governance participation and voting rewards, tokens can also be used to pay for cycles. And this is the last use case we will now look at. So cycles are the fuel for computation and storage. And actually, each canister on the Internet Computer, except for those on the NNS, has some cycles stored with it and will use up these cycles, for example, when it performs computations. So the idea why we use cycles for this is that while the tokens' price may vary a lot over time, the goal of the cycles is to keep the price of the computation power roughly the same over time.

So, in summary, the Network Nervous System of the Internet Computer is a tokenized open governance system that manages the Internet Computer. Everyone who has tokens can lock them in neurons to participate in governance and contribute to decisions, for example, whether new subnets should be added. And by participating in voting, even if this is done automatically by following, voters get rewards. And they can then spend their rewards or other tokens to pay for cycles, which they can use to fuel their computations of their canisters. And this is basically how the Network Nervous System manages the whole Internet Computer.

You know, here at the DFINITY Foundation, we believe patience and unwavering support should always be rewarded. So as a special thank you, we have one final giveaway for sure. And I think you'll all appreciate this one. We are giving away 5,000 limited edition shirts from today's long-awaited Genesis launch event. So for those of you who have been patiently waiting, painstakingly wondering when t-shirt, the answer is now. Now t-shirts. Please scan the QR code on the screen to sign up for a chance to receive one of these limited edition shirts. Even though we're giving away 5,000, they're going to go fast. Don't forget to post photos of you wearing your Genesis t-shirt on Twitter, Reddit, and Instagram. Be sure to tag us. And I hope to see you wearing your shirt in the wild.

Hello everyone again. In this talk, we're going to look at the tokenomics of the Internet Computer blockchain. The Internet Computer network has a governance utility token called ICP. This enables you to participate in governance. It is also used to reward those supporting the network and provides the source material for cycles, which provide fuel for computation. ICP has a variable value. The network also hosts cycles, which provide fuel for computation. Cycles have an approximately constant value over the long term. At Genesis, there will be 469,213,710 ICP tokens. Circulating supply depends on the dynamics of the market, but will be approximately 26%. There won't be any cycles because you need ICP to create cycles.

So how are new ICP tokens minted? The decentralized governance system of the Internet Computer network, the Network Nervous System, mints new ICP tokens to reward network participation. ICP are given to neuron operators participating in governance and to the operators of special node machines who participate in creating the physical layer of the network. A daily neurons reward is shared amongst neurons according to their relative claims on an annualized basis. The daily neurons reward that is shared amongst active neurons starts at about 10% of ICP supply and then falls to 5% over eight years. Meanwhile, correctly functioning node machines receive cash equivalent payments. That's because node operators have fixed costs like hosting and hardware depreciation. You can just divide the notional cash amount paid monthly by the price of ICP to get the amount of ICP dispersed each month.

So now we know how ICP are created, but how are ICP tokens utilized and consumed? ICP are consumed when they are converted into cycles, which can be used to power computation by the Network Nervous System. ICP worth one SDR, which is a logical currency unit defined by the International Monetary Fund, can be converted into exactly one trillion cycles. ICP indirectly powers computation. Canister smart contracts must be pre-charged with cycles, which play the role of fuel. And when cycles power computation, they are consumed and burned. Therefore, directly or indirectly, people who run smart contracts must obtain ICP tokens and convert them to cycles, which are eventually burned. The more computation, the more ICP must be converted and burned.

ICP also indirectly powers DeFi, or decentralized finance. Decentralized finance needs more reliable stores of value. For example, if Alice lent Bob 100 ICP to be repaid within a year, and then over that year, the value of ICP increased, Bob would have to pay back Alice more than he expected. In a famous book called "The Denationalization of Money," Nobel Prize winner Friedrich Hayek argued that a currency plays the role of unit of account and medium of exchange better when its value is stable relative to a broad range of economic measures. The Network Nervous System will always convert ICP worth one SDR into one trillion cycles. An SDR is composed from the Chinese Yuan, Euro, Japanese Yen, UK Pound, and US Dollar, and therefore this conversion rate is pegged to the value of the global economy. Meanwhile, cycles always return to their constant maximum value over time.

In this diagram, time runs from left to right. To begin with, the Network Nervous System is converting ICP into cycles at the peg. But then a financier who has accumulated surplus cycles begins to sell them. Naturally, the price of cycles falls because the financier will sell them for less than the Network Nervous System to liquidate his surplus. Since these surplus cycles are cheaper, they are then purchased by those wishing to fuel their computation. These cheaper surplus cycles are thus bought and burned and eventually exhausted, returning the price to its peg over time. This is the first time that raw computation has been applied to create stable value in cyberspace. Of course, the greater the amount of computation being performed on the Internet Computer, the greater its power to return the value of cycles to their peg. The more cycles that are needed by decentralized financial systems, the more ICP must be converted.

Lastly, ICP can also be staked in governance. Users do this by locking up ICP inside the Network Nervous System, which creates voting neurons. Neurons are similar to savings accounts where you have to give notice of withdrawal. A neuron's relative claim to voting rewards is derived from the number of ICP it has locked inside and how long the minimum notice period is configured to be. Every day, the fixed neurons reward is divided amongst voting neurons according to their relative claims. In this way, ICP allows users to contribute both to the governance and management of the network and to network security.

Okay, that's it. Those are the three main ways ICP are used. Thanks for listening. Next, we have a demo of a fantastic dApp running end-to-end from the Internet Computer that helps you manage ICP governance tokens and interact with the Network Nervous System.

The Network Nervous System is a completely open, tokenized governance system that runs within the protocols of the Internet Computer blockchain. The network and the node machines run by independent parties that host the network run under the control of the Network Nervous System, which is incredibly exciting because it makes the Internet Computer the world's first fully adaptive blockchain. Through the Network Nervous System, the Internet Computer can evolve and adapt in real time. By leaning on the Chain Key technology used in the lower layers of the network, it can roll out protocol upgrades to node machines, create new subnet blockchains by combining nodes to increase network capacity, tweak economic parameters, configure cryptography, and perform many other tasks, all without interrupting the network's operation or breaking security. This contrasts with traditional blockchain networks, which can only be updated in meaningful ways by persuading participants to cooperate in highly disruptive and sometimes divisive hard forks.

After Genesis, the Network Nervous System will begin to exert the will of the community, mediated through algorithms, by processing large numbers of proposals every day and executing adopted proposals entirely automatically. You can participate by staking ICP to create new voting neurons, which earn voting rewards, which can be configured to vote automatically by following other neurons in a system of liquid democracy. In the next few weeks, we expect many thousands of you will create neurons, greatly adding to the security of the network.

Let's head over to our Zurich office to take a look at the dApp that provides an easy way to interact with ICP and Network Nervous System neurons, where we'll find David Miller Durant, one of the great engineers working on the project, with Gilbert Jolly in the background joining from Spain. David, hi, over to you.

Thanks, Al Dom, and thank you very much for the introduction. I'm going to jump right into it. This app lets you do everything you want to do with the NNS, with ICP, and with sort of canisters and cycles. When you land, you land in the ICP tab. The ICP is the key to all of this. So as you can see, inside my account, I have 100 ICP. Now, each account has a number of sub-accounts. So you sort of have pops where you can segment your money into different addresses. Your address is here. If you want someone to send you money, you send them this address, and they send you the ICP. So I'm going to create an account name. I'm going to call this my holiday fund because I'm sure people would love to donate to my holiday fund. Okay, so I've got this address here. Just so I can show both sides of the payment system, I'm going to make the payment myself. So you go from this account, uh, you create a new transaction, which is to send to an account. Now, there are these accounts I've already made payments to, or I sort of own. So I can see there is an account called holiday fund. I'm going to send something there. I'm going to say, put 10 ICP in my holiday fund. I think that's sort of a nice down payment to get started. Review the transaction, from, to, confirm, and send. Now, it's just that easy. Each transaction takes a couple of seconds, goes through full consensus on a, uh, on the NNS subnet. Um, in the end, you get a sound. As you can see, I've got 10 ICP in the holiday fund, and I spent just over 10 ICP because you need to include a small transaction fee.

So, I want to get involved in the voting system in the NNS. How do I do it? First thing you do is you stake a neuron. So you go in, you create a new type of transaction, which is the stake. So I want to take 30 ICP because that sort of seems like a good amount. Let's take 30. Now, here we're sort of creating the initial neuron, and in the next step, you get to decide how long you want to lock it up for. Now, the lock-up is basically the minimum amount of time it could take before you can dissolve it again. The higher the lock-up period, the more rewards you get each time you vote. So I'm going to set, I'm going to lock mine up for just under two years. That seems so like sort of a good amount of time. Uh, and as you can see, this gives me a higher voting power than the number of ICP I stake. So I'm going to update the delay. Now, this is sort of a big commitment here to the Internet Computer because I'm saying I'm not going to take my money out of it for the next nearly two years. And, uh, yeah, I'm sure I want to do that. I'll just, um, reiterate that you can always increase the dissolve delay of your neuron up to eight years, but you can only decrease the dissolve delay by dissolving it, which takes, takes place over time. So if you've increased your dissolve delay to eight years to maximize your voting power and voting rewards, it would take eight years, um, from the moment you start dissolving it to recover the ICP staked inside. Yeah, and, uh, the reason we do that is we try and get people to have an investment in the long-term value of the Internet Computer if they get decide about votes that may chair, may influence that future.

So we use a form of liquid democracy here at DFINITY, which is you can follow other neurons. So you may not want to actually actively vote in everything. You may just want to pick people you trust to do the voting for you on certain topics. Uh, so in this case, I don't really want to vote on governance things. So, uh, I'm going to, I'm going to find someone to follow who I will follow automatically, but I can always vote against them if I feel like it. In this case, I'm going to follow the Internet Computer Association because they're sort of a lovely group of guys.

[Music]

And this means that whenever they vote on something, I vote with them, and also I get a voting reward. Now, you can follow multiple people and only vote with them if they all vote in the same way. And you can also manually enter a followee and by select them by neuron ID. You can configure your neuron to follow any number of other neurons on a particular topic, and it will follow a majority of the followers. So, for example, if you follow the Internet Computer Association and the DFINITY Foundation, then both the Internet Computer Association and the DFINITY Foundation will have to vote the same way for your neuron to follow, because it follows a majority of the votes.

Something else else worth mentioning at this this juncture: the DFINITY Foundation, your own, and the Internet Computer Association neuron aren't actually controlled directly by the organizations involved. They're special kinds of neurons that are controlled by their own followers. So in actual fact, for example, the DFINITY Foundation, you look at like 20, 20-plus team members being followed, and it's actually those team members who are able to and remove new followers to the DFINITY Foundation neuron. Yeah, that's exactly right. And this is how you add multiple followers, and you can add extra followers if you feel like it. And this sort of allows them to vote between themselves and to decide the sensible thing to do in each issue. And you can pick different followers for each class of vote. So in this case, network economics, changing sort of the fundamental, uh, cost of things in the network, governance is sort of big decisions about the network, um, and there's all sorts of about half a dozen of these things.

Okay, let's go through what you can configure about your neuron. So this is a neuron ID. This is what you give people if you want them to follow you. Uh, here is the amount you have staked. Here is the period of time it's locked. So this sort of, uh, how long until you can get your money out. So if you press start unlock, that number will gradually decrease down to zero until eventually you can get your money out. Once you've started dissolving your neuron, um, you know, it'll count down day by day until until you can disperse the ICP that's locked inside. But there's no way of accelerating that. And once you've increased the dissolve delay, the only way you can reduce it is by starting the unlock process, and it's, it's going to dissolve day by day. Exactly. So if I started unlocking today, in just under two years, I'd be able to get my money out.

Next up is maturity. Uh, whenever you vote on a proposal, up to three days after that, you'll receive maturity. Once this maturity is sufficiently large, you're able to spawn a new neuron, and that neuron is created with brand new tokens minted by the network, which reward you for taking place in the governance system. Every day, the Network Nervous System has a sort of pot of rewards that it wants to distribute to neuron holders, and that pot of rewards is calculated according to a completely different set of rules, and it divides that pot of rewards amongst neurons that participated in voting according to their relative voting power. And so, of course, you know, many of us, me included, are thinking, well, how are we going to manage our ICP? And, uh, certainly in my case, I'll be locking up, um, a bunch of ICP in eight-year neurons. Yeah, exactly right. And if you lock up your ICP for eight years, you get the maximum voting power and the maximum voting reward through maturity.

Um, so going down below, you can choose who you follow at any point and change that whenever you like, as you see fit. So let's go look at some proposals. So because we haven't yet reached token liquidity, this is running on a test net. So normally you'd see a very large number of proposals going by. They'll be sort of diverse, all sorts of weird and wonderful things members of the community feel like should be happening on the network. But right now, we only have the one. You know, the Network Nervous System completely controls and manages the network, not just the individual devices that host the network, but the overall network configuration that exists, if you like, between the devices in cyberspace. And there's a very broad range of different proposals that this Network Nervous System can process, all of which get executed automatically. And, and so you're looking at a proposal here that would modify the cost of memory provided by the, the Internet Computer to smart contracts. And this is a really, you know, fundamental aspect of this whole kind of system that even these sort of super detailed parameters that the network uses can be configured through proposals. And we expect there to be, you know, many hundreds of proposals going through the system a week. Most users, of course, won't want to vote on them all individually. They'll probably choose a subset of proposals that they, that they want to, you know, vote on manually, and for the rest, they're just going to configure their neurons to vote entirely automatically by following other neurons.

So you can only vote on proposals that, um, have were created after, um, you had, uh, created your neuron. And that stops people sort of getting a big bunch of ICP flooding into neurons and then deciding on a proposal very, very quickly. So this is the voting page. So here you can select the topics that you're interested in. So some of these are more interesting than others and more exciting than others. Um, you can look at the reward status, so sort of whether or not you're actually money out of it, whether or not these things, these proposals been executed, adopted, or failed. So just generally browse them. So here's an open proposal: "Reflect fully hardware prices, reduce smart contract memory costs by five percent." Now, while the value of cycles is fixed, the value of the computation is always falling. So occasionally, I'm going to see proposals that look like this on the main network. In this case, we think the cost of memory has gone down practically by five percent, so we want to decrease the cost. When you think about it, this is just incredible. Um, when, when, or if this this proposal gets executed, the Network Nervous System will change economic and economic parameters, the memory cost parameter right the way across all, all the subnet blockchains in a manner that occurs within the protocol.

Um, so, you know, this is a blockchain that can not only update itself, but, you know, configure itself in, in real time. And we're going to see, you know, hundreds of proposals going through every week. Of course, most users won't want to vote on hundreds of proposals, and they configure their neurons to vote automatically by following other neurons. That this is an example of a, you know, really impactful, uh, proposal that could can be submitted. So right up here, we've got sort of the title, and here someone's given an attached URL where you sort of go into why this is a sensible proposed. You can't just sort of say this is right because I say it's right, you've got to really make a good argument for it. With the proposal, we can look at sort of their history and work out what kind of a voter they are. Uh, the topic, network economics, and here's sort of some relatively unstructured data on what proposal actually does.

Um, I'm going to cast my vote. I have 37.13 votes because I got, get the voting bonus for staking my neuron for a long period of time. Here, if I had multiple neurons, I could select some of them to vote, but in this case, I only have the one. So I'm going to select that to vote, and I'm going to vote to adopt because this is a relatively sensible proposal. Once you've voted for a proposal, you can't take that vote back, but I'm pretty sure it's a good idea. So I'm going to say yes. And boom, just like that, you've added your votes to a proposal. And when a majority of the voting power either votes to adopt or reject, um, the Internet Computer's Network Nervous System decides. If the majority has decided to adopt, that proposal will be automatically executed right the way across the network. And as you can see, uh, shortly after I voted, one of my very, very large followers decided to vote with me, and the proposal has been accepted overwhelmingly. That's, uh, that's just how easy it is to get involved in the decision-making process of the Internet Computer.

Going back, so we've done, we've done ICP, we've done neurons, we've done voting. The last thing is how are you going to create smart contracts on the Internet Computer? Next thing we want to do is we want to deploy a canister into the Internet Computer. Canisters are what we call our smart contracts, and they are, um, how everything runs on the Internet Computer. And I want to get involved. I want to make some software. So what I'm going to do is I'm going to create a canister. Create a new one. Canister name, I'm going to call it my website because I'd quite like to post my website on the Internet Computer. Confirm the name. I'm going to pick where I get my ICP from. In this case, I don't want to take it from the holiday fund, much relatively in my sort of base account. I'm going to put in, uh, 0.1 ICP to charge it up because, uh, 42 trillion cycles is an awful lot of cycles, and that thing will run for quite a long time off the back of that. So this is, if anything, I'm overcharging the thing. I'm going to review the cycles process, double check everything. And this is really cool. So, and by the way, it's not just creating new canisters that are pre-charged with cycles, which of course are fuel for computation, but you can also send, I use the same system to send cycles to pre-existing canisters. And those cycles, of course, are very commonly used to power computation, but they also, because they're constant value, they can also be used in systems like DeFi. So, yeah, potentially you'd use the same mechanism to send out cycles to DeFi systems or even just a wallet you're using for payments. It's just that easy to get a smart contract that is owned by you running on the Internet Computer. The next thing you want to do is you want to change the controller. Go into dfx and just get started building a great developer experience. That's everything on the Network Nervous System.

David, thank you so much for this. I think this, uh, dApp is going to provide a really great way for people to get involved with the Nervous System. And, you know, we expect billions of dollars of value to be staked as neurons in the Network Nervous System, which will not only make governance incredibly secure, but we believe will ensure that proposals are adopted in a manner that drives the success of the Internet Computer network, the world's first fully adaptive blockchain. All right, thanks. Thanks. Thank you for attending our Genesis launch event. Stay with us as we walk you through some next steps to deploy your apps and websites to the Internet Computer. You'll first need to get ICP utility tokens. You can begin acquiring the ICP utility token through approved channels, such as exchanges, very soon. Once you have your tokens, you can convert them to cycles and use them to pay for computation. Please note, when a launch of this magnitude occurs, bad actors and scammers invariably follow. Remain vigilant and verify any information you read online against our official channels of communication.

Now, if you are an airdrop recipient, head to coinlist.com/dfinity and click on the "Check Your Airdrop Registration Status" button to determine whether or not you have completed your registration process. After successfully verifying your status, you'll have access to your ICP utility tokens and can start participating in the network. You can even earn rewards for doing so. If you are a developer, you can find instructions on how to deploy your apps to the beta network at sdk.dfinity.org. And you can check out our developer forum at forum.dfinity.org to find collaborators, talk through technical questions, and showcase your projects. Also, we're super excited to announce the new Internet Computer Grants Program, which directly supports the growth and development of the Internet Computer ecosystem. This program helps our developer community build out tooling and infrastructure and bootstrap open internet services and social impact use cases. To learn more, please visit the website below. And finally, if you're an entrepreneur seeking funding, the Beacon Fund, led by Polychain Capital, wants to hear from you. You can find more information and the application at dfinity.org/ecosystem. For those of you who want to connect and stay in the know on all things DFINITY Foundation and Internet Computer, you can follow us on Twitter and all other social platforms. Also, please be sure to sign up for our monthly newsletter at dfinity.org/newsletter. Finally, if you want to take a deep dive into internet culture, tech policy, and more, visit our new editorial site, The Reboot. We can't wait to chat with newcomers and long-standing community members alike across all of our platforms. The wait is finally over. The Internet Computer is here. Welcome to the dawn of the new open and free internet.

[Music]

[Music]

[Music]

Do

[Music]

You