EOS Canada believes that the discovery tool used in the EOS BIOS orchestration is ready to start running and go through rounds of heavy testing. Presented by Alexandre, this video is geared towards our fellow Block Producer Candidates. It explains the ` eos -bios` design, a tool to launch the mainnet .

Hello all fellow block producers.

Today I want to expose the new things in EOS BIOS. I think we're at a stage where EOS BIOS is going to be ready for mainstream adoption - mainstream being block producers. And I want to explain right now the new and latest concept. I think it's the final design of the system.

So we'll all be able to start joining and growing the main net. The core of the design of EOS BIOS is to have BPs be autonomous in publishing what we call the "discovery file." And the discovery file publishes information about them. It publishes their public key, the initial authority structure they want on the new main net they're launching.

Ok let me present you quickly the discovery protocol. This is the thing the EOS BIOS brings to the table. It's a decentralized way of having block producers present themselves and link themselves together in an autonomous and decentralized fashion. So we don't need to rely on Google sheets, or other things managed by different entities. Not that it's not good, but it's difficult for people externally to trust that it's not managed by one single group. Having it decentralized and making it a protocol means everyone can join. But we want to have everyone join also, even smaller players. Because at some point, if the big players are all DDoS, maybe it's going to go through the smaller players and we're going to save the network this way. So it's very important that it's very inclusive, that anyone can join. And I think with the discovery protocol, that's what we get. So the discovery file is a small file that indicates to the world and the other producers: who I want to launch the network with. So you're pointing to your peer and you weight them from 0 to 100. And you say, "I think they're very good, I trust them to launch the network."

And also you vote for a boot sequence. So you're saying, "I think this is the series of operations we need for a main network." And then also you're pointing to the contract code you want for the EOS.IO system contract, for the snapshot that we want to honour in there, and if it's in the boot sequence in the snapshot. So this gets all pushed into the chain and then it makes it very clear to everyone what we should verify. What are the exact contents of the chain, smart contracts, accounts, transfer the initial monetary base that we want in the chain. Everyone can then verify that. And also in that file there's the end point: how to connect to your peer when you launch

a network with that protocol, how do any people other people connect. So the EOS BIOS has a meshing algorithm so that when you boot the network, it'll automatically mesh in a fashion that we're sure creates one single network. Otherwise we need to manually PR (pull request) everyone, or everyone connects to everyone. But when we're 150, we need an algorithm so that it's properly meshed, not overly meshed. So this is for the discovery. It's a very simple file.

A little bit of history here. We started by publishing that file on an HTTP server, on github, on keybase, and people put that on Geoctities... No that's a the joke. And so that was linking to other files, but that posed problems. If someone takes down these end points, then it literally blocks the launch. And also a lot of services have caching, like for example github has caching. So BPs might not be aware, but they're blocking the whole network discovery because the service is caching, or whatever. And so it made it less decentralized a little bit also.

Now we tried IPFS, which we are still holding for publishing the content files. We're publishing the contracts, the snapshot... through IPFS. It makes it very easy to distribute. So we're using a default gateway, but you can always use a different gateway if you don't want to be exposed to that single point of failure. So the next stage was using IPFS. And IPFS has a feature called IPNS, and it's a naming service. So you canpublish a file where you can change the content of the file, but you have a stable identity. This way, we were able to connect to one another and say "I vote for that identity, and for that identity." But it was very slow, IPNS is using a distributed consensus algorithm. It's basically trying to do something like a blockchain, without a blockchain. So you see where I'm going.

So last Saturday, that was May 5th, my CEO and I, Marc, we said, "ok, we need to solve that." And we thought through: what was the thing we were missing? We were missing distributed consensus in a very fast way. And it just so happens that blockchains are best atdistributing fast consensus. And you know, EOS is the best blockchain to do that. It just so happens that we're launching an EOS blockchain. So what we decided is that we were going to write a smart contract. And you can easily publish that discovery file in the smart contract on an EOS chain, and then the discovery is just reading the table on that smart contract. So it's very fast, it's atomic, it's decentralized, anyone can join, and the naming of your peers is not some crippled Bitcoin-like address. But the naming of your peer is their EOS account. And the control of the keys is properly done with EOS. So it's dogfooding. I'm super proud of what we did right now.

And so that was Saturday, now yesterday Tuesday we shipped the smart contract and the refactored EOS BIOS to use that, and it works. So what that means is that we're now going to orchestrate. And that's the proposition here, I think it's a very good proposition. I hope you guys join in. So we're going to orchestrate a series of launches. It's going to be a multi-staged main net launch. And it can start today. So we're going to start with a stage 0 node, and everyone is going to register there and publish their discovery file. And through that, we call that a seed network. We'll be able to launch a second stage, and that second stage will have the sequence, and the snapshot, and the contracts that we all agreed on in the seed network, and we're going to launch that network. It's also going to register anyone who was there on the new network. Eventually we can trash that one, and then start from stage 1, and then build stage 2. And more people will join here and we'll be rehearsing deploying an EOS Network many times using the same protocol.

At the end, we'll have stage 27? Main net! So join the telegram channel, we want to chat more about that. Today we want to launch. So we tried stage 0 to stage 1, it works well. There's a few things to learn, a few things to configure. But I think this is a solution that can go down to the main net. We're going to be dogfooding. Trying and trying it again and again. Deploying using the same method and improving along the way. And I think it's ideal if this is public. And as the stage networks grow it can be larger and larger. And what doesn't kill us, makes us stronger. If someone even wants to attack those networks to prevent a main net launch, it will already be very big if all block producers provide two infrastructures; one for main net eventually, and one for those test nets. And they kind of swip-swap, on stage 27, 28, and then 29, 30... eventually this becomes the main net. It will have grown and strengthened before the launch, rehearsing all the way.