Robert and I continue with the second part of our Mission Control Q&A. If you have questions that we haven’t been able to clarify yet – feel free to leave them as a comment or post them in our community channels!
All right, and we are back with Part 2 of our Q&A session between Robert and me.
Robert is one of our researchers here in Zurich. We are answering questions that were submitted through Mission Control: our developer community on Telegram.
What are DFINITY’s plans in regards to networking library?
So, the first question we’re going answer today is from Harry. So, Harry’s question’s about a networking or peer-to-peer layer library. He mentions Kademlia, but he also says he is not sure if we’re going to use that or not. He saw a tweet by DOM; and so, he wanted to ask, “What are our plans are in regards to networking library? And whether or not, Kademlia is still part of our potential solutions?”
Great question from Harry. Originally, we started out using or wanted to use a library called LEAP peer-to-peer which is based on Kademlia, but it turned out to be buggy and a bit over engineered; so, we doubted it and, then, we tested multiple overlay networks for the peer-to-peer layer, like Kademlia, Chord, and others. But it turned out just a random gossip network would do the trick: so performance-wise it, doesn’t perform any worse than any sophisticated networks. So, we ended up deciding on building our own peer-to-peer network layer, based on Gossip, which means that the nodes just talk or to randomly talk to other nodes, and the information is spread out by random gossip to the entire network.
There are several like interesting aspects to this layer, which we are working on. One of them is that we have to differentiate between several types of artifacts. By artifact, I mean data, the blocks or signatures, or signature shares, or the transactions, which need separate treatment. So in separate like relay policy which defines on which circumstances should an artifact we relate to other peers or just be dropped. And other aspects which are interesting, in which are working on, are our paralyzed downloads: so, if an artifact is big like a block, you need or we can split it up, so you can download a block for multiple sources at the same time.
Is Kademlia still part of DFINITY’s potential solution?
We are also making use of a system called set reconciliation algorithm that allows two peers or even multiple peers to quickly agree on the common subset of data that is not shared by any two parties. So, if you have two parties: they want, so, Party A wants to send to Party B all the stuff that he owns, but party B doesn’t, and the other way around. And set reconciliation means determining this subset of data or artifacts that are not shared by the two parties. And, we are also looking into spam protection on the peer-to-peer networking layer so that an adversary cannot just flood the network with malicious transactions.
Long answer but in short, what we found is that when Kademlia was not fit for what we needed it to be, and that’s why we decided to build out and roll out our own solution. Robert just talked about a few of the ideas that went into the design process of this library that we’re building right now.
What p2p encrypted messaging library is DFINITY building? Will it be open-sourced?
So, Harry’s second question is about peer-to-peer libraries with encrypted messaging. He made the observation that “There are not too many good ones out there on Get-up or somewhere else where you can just plug and play them. And so he’s asking, “What are we building? And are we planning to open-source our library?”
Eventually, we are planning to make our whole codebase open source but timing is important here; so, we’ll publish our like source code step-by-step, once we progress. I’m not sure if we are planning to create like a library that could be used by any third party or other projects. That would be an interesting idea but we are focusing on our own network now. Given the fact that it will be eventually open source; theoretically, anyone could take code from it and use it in its own project.
Just to sum up Roberts answer, I think that’s 100% correct. So we’re building out our own tech. Obviously, we’re focused first and foremost on the DFINITY and bringing that to market as soon as possible. But as we go to market, as we launch our network, all our code will become public and open source. So, anyone who wants to reuse some of our code can technically do that and study our code. Not only doing this because we want people to share our code, but also because we’re going to be looking for feedback and want to be very transparent with what’s going on behind DFINITY. If you become a miner or developer, you should always have transparency on what you’re running on your machines.
Does a mining process have a copy of the blockchain on disk?
Dylan Miller has another question and he asked us, “Does a mining process have a copy of the blockchain on disk?”
That’s a very good question. In order to be a miner, you will have to run a full nod. By the full nod, it doesn’t necessarily or doesn’t even imply that you need to have a full copy of the blockchain on your disk. What you need is like a full copy of the state of the blockchain, which is not to be confused with the content of the blocks, which are lists of transactions. What you will have to keep – a copy of the state, which means that you will need to know which contracts are currently deployed on the blockchain and which user data is registered on the blockchain.
All the data kept by the decentralized applications on your blockchain that you will need to know in order to be able to validate the transactions as a miner. But you don’t have to keep all the history, so don’t need to know what transaction caused which state changed.
All right. And we’re going to tackle yet another question here. So, this next question was submitted by Wolfgang. And just as we go through this, if you also have questions that you want to have answered and haven’t found an answer to in our FAQ’s or the community so far, join one of our community channels, for example, Mission Control, which is our developer community, and submit your questions there. We have an admin, his name is Moritz, and he collects those questions and then weekly sends them to me. We pick a few questions every week to answer on Inside DFINITY in a few episodes.
Will, for example, only clients ranked higher than slot 10 propose blocks? How is bandwidth overhead minimized?
So, Wolfgang’s question is; it’s a long one so I’m going to read it out. “At the beginning of a round, the random value provided by the random beacon ranks all clients in the current group. In theory, all 400 clients could gossip a block proposal causing extreme network overhead since all but one or two blocks will be discarded at a later stage by the notaries. How does the DFINITY client manage this situation? Will, for example, only clients ranked higher than slot 10 proposed blocks? And how is bandwidth overhead minimized?
It is certainly an important aspect that our system needs to cope with; so, we have to prevent the network from being overwhelmed by like blocks that cannot be used because their rank is so low. What Wolfgang proposed or asked for was whether we will have a system where the clients – only clients with high ranks like 10 top most clients – would create in release or broadcast their blocks. The problem with that approach is that, I mean, we cannot control whether the clients would stick to that rule. So, we need a slightly different approach to that.
Our current thinking is that you know every node that’s part of the relay network will also prioritize the blocks, will only relay the blocks that have a high priority. One way of doing this is by using a timer so you could say that, okay, in the first second after upon entering the round, you will only relay maybe the first top-ranked block, after two seconds you would also relay like the second block; so, then, you would relay the first one and the second and after three seconds you would relay the first three blocks, and so on. So, with that approach you could effectively prevent the network from being flooded with lower rank blocks, which have no chance of becoming part of the chain.
Does a neuron have any part of the blockchain on disk?
So before we get sunburnt out here, though it’s extremely nice, we’re going to move back in. Then, we have another question or two that we’re going to answer and conclude today’s Q&A. All right, and we are back for the last few questions of this part’s Q&A session. And this question is from Dylan Miller, and he asks, “Does a neuron have any part of the blockchain on disk?”
In a previous question, Dylan asked whether a mining process or a miner needs of a copy on the blockchain. That’s not the case because a miner only have has to keep the latest state in order to validate the blocks. So, now the question is whether a neuron needs to keep a copy of the blockchain on this disk. So, no. That’s the same as with the miners; so, it also does need to know the latest state of the blockchain. A neuron theoretically could be a light client that just downloads the state that is interested in, in order to make his decision, in order to follow another neuron.
What happens if the chain weight of two or more chains is the same over multiple rounds (either by an adversary that proposes multiple blocks for the same round or just randomly)? How do replicas decide where to build on?
It’s why we’ve learned this more data need to be kept by the miner the neurons were probably each a very little information saved on disk. And with that we’re getting to our second last question. This one was submitted by no one else but Moritz. And Moritz asks, “What happens if the chain weight of two chains or more are the same over multiple rounds (either by an adversary that proposes multiple blocks for the same round or just randomly)? How do replicas decide where to build on?”
That’s a great question. In our system, the block makers decide based on the chain weight; so, the weight of the whole blockchain on which chain end they want or they should append their block. As more, it said it could theoretically happen that two chains have end up having the same weight. So, probably in that case what a block maker can do is just choose one of them randomly because none of them has a higher priority, so it shouldn’t really matter which one he, like, builds his block on. But another problem that Moritz mentioned is that an adversary could just propose multiple blocks and in extreme cases that an adversary could propose like a million blocks, which would all have the same block weight and that’s a valid concern.
We have already thought about it, and our relay network will take care of such attacks by not relying, like, equivocating blocks, so if an adversary end creates multiple blocks, be it on the same chain and or on different chain ends, you are not allowed to do so. So, the network can easily detect that and can stop such blocks from crawling the network, and it can also penalize you as a malicious miner.
How to be included in the keyframe of the genesis block?
Alright, and with that we get to our very last question for today. It was also submitted by Moritz. And even though we’re not 100% sure if we’re interpreting the question the right way, here’s the question, “How to be included in the keyframe of the genesis block?” Now, I think Moritz, what you mean is “How are you going to be a token holder from the very start so your tokens will be included or you’re going to have an access to tokens in the genesis block?”
That’s how we interpreted the question. And, of course, as many ways you could have been a contributor in our seed round, you could have been part of the team or you could have been a part of one of our private investors that joined over the last few months. And, of course, many of you hopefully were able to join the DFINITY token-holder community as part of our airdrop which happened over the last couple months, or we distributed the equivalent of 35 million Swiss francs to many tens and tens of thousands of our early community members.
All right, that’s it. Robert, thanks so much for your time. We’re going to wrap it up here. This was another Q&A session. If you have questions, as I mentioned earlier, just submit them through one of our community channels; you will either have community admins answering them or forwarding them to us, and we will pick them up in one of those future Q&A sessions. And with that, thanks for watching. And we’ll see you, guys.