Enzo and I got together to answer the questions we received in Mission Control. If you’d like us to answer your questions in the next Q&A session, please submit them here: https://goo.gl/forms/qOQgEaLzZOgKJcx92.
Hi. Welcome to yet another episode of Inside DFINITY. Today we’re having another Q&A; episode; we’re going to be answering questions that were submitted to us through some of our community channels. Today I’ll be joined by Enzo, who is one of our senior engineers here at DFINITY.
Cédric: All right. Enzo, thanks for coming back – this time for a Q&A; session again. These questions are submitted to us through Telegram, the Mission Control channel, for example, or other community channels and every week we try to answer a few of them. Today, I grabbed Enzo for a few minutes to help us answer some of these questions and we’re going to go jump right in.
So, the first question is from user Carbosix, that’s his username on Telegram. I’m just going to read it out.
What would be your main message towards developers? Why should they build on DFINITY versus any other competitor or similar platform? How are you planning to get the message out?
Cédric: He hopes that we have a strategy to attract developers on the idea of “Why should they invest time and energy into learning Haskell, and WebAssembly, to choose DFINITY as the platform of their choice?”
Enzo: Awesome. Well, I’m so glad actually that question was asked because I really wanted to clear up. I think what is a very common misconception and that’s somehow that developing on DFINITY is somehow predicated on the knowledge of Haskle, WebAssembly. The reality there is that it is not. So, while transactions on DFINITY network are WebAssembly binaries – there are many high level programming languages that can compile down to WebAssembly, namely you know C and C++, Rust and, then, other, obviously less more, you could characterize them, as more esoteric languages, like Haskel. We have tried to create the simplest programming model that includes the widest variety of programming languages – WebAssembly is a build target of many different compilers that can that can support this now.
What are we doing to attract developers?
Enzo: It’s another good question to. I mean the main thing for us is engagement – actually just really get talking with as many developers as possible about what their exact use-cases are and, then, why working on DFINITY is going to be a lot simpler for them than many other competing platforms.
I mean I’ll give you give you an example. Tomorrow morning, for example, I’ve got a meeting with IoT company that’s building on-chain autotrail for IoT device registration, and most of their code is written in C and C++. They have libraries that are written in C++ functions that are implemented in those libraries to do things like device registration. Just walking them through this example of how do you take this code in this existing codebase and be able to compile it down to WebAssembly and, then, be able to deploy that on the network in the form of an actor, a web canister.
I think for us we’ve created this environment, in which with that we’re really trying to streamline and pipeline that process and make it as painless as possible and, then, be able to really migrate a lot of existing codes and existing infrastructures onto this network in a way that provides all these new great properties that you get with using DFINITY as computing resources as opposed to some of the other things that are out there.
On-chain Autotrail for Device Registration.
Cédric: So, I think in some ways to say that, “Our goal is to exact opposite of what the misconception is where people think they have to learn a new language or they have to learn Haskel or anything that might sound very complicated. We’re really building infrastructure that is to some degree, language agnostic because we use WebAssembly as a build target, but whatever language you use to write your applications in, it’s up to you and up to the eco system.”
Enzo: Yes, exactly! In the context of this particular person’s usecase, which was, like I said, to build this on-chain autotrail for device registration. The existing code is already in a language that compiles down to WebAssembly. There isn’t anything new for them to learn – they’re already familiar with the same, you know they can use, most likely, the same compiler that they already use.
They just maybe they need to add a couple of extra flags into their built-process in order to generate the code in the correct format, but a lot of the tools are already there for developers. So, really this provides the developers with the resources that they need in order to be successful.
Cédric: All right. Let’s move on. We have another question from Jordan on Telegram.
Does DFINITY have any plans for natively supporting GraphQL interfaces to the network?
This might have been discussed earlier, but a GraphQL interface for interacting with the network would be very nice in addition to or perhaps instead of a JSON-RPC interface. If there is no GraphQL interface, the community will just have to build one themselves.
Enzo: Yes. Well, it’s to the point. That question has actually been raised before, and it’s something we’ve discussed internally. I can tell you on the implementation side that we haven’t gone to create the interface for that. That is something we’re looking at supporting, but I can’t say definitively right now if we can guarantee that we’re going to provide support for it at launch.
Cédric: Carbosix had one more question.
What is the (UID) Unique ID for the record of the Genesis block called? Is it possible to update/modify this record and/or its values?
Enzo: I mean anyone could swap out the content of the Genesis block with anything else. The Genesis block is just a .json file that has some actors encoded in it. That .json file is designed by the foundation and distributed at launch so everyone has a copy of the Genesis block. That is the Genesis block that most genesis minors will build on top of so I don’t think that substituting the contents of that Genesis block will do much good. Definitely, it is possible; in particular, maybe it’s useful actually if you’re doing development or testing locally certain features.
Cédric: So, we’ve also collected some questions from earlier Q&A; sessions that we were not yet able to answer and so we’re just going to go through them now and see if we can add some more shine some more light on them. So, the question was submitted by Harry on Telegram reads.
I wonder how does DFINITY chain (e.g., random beacon chain in the consensus whitepaper, without validation tower since it seems a little far in the future) comparing to the other best performing consensus protocol? As far as I know the best out there is delegated proof of stake. And how will validation tower change the equation?
Cédric: So, I think it’s a very big question.
Enzo: It’s a big question; there are a couple of points there. So, I’ll only to speak to a couple of them. The first being that somehow that DFINITY’s consensus algorithm is too far off in the future.
It’s been implemented for seven or eight months now.
Cédric: It was before the start of the year.
Enzo: You’re right. Maybe since I guess the October of last year. It’s been implemented for some time now and we have what we have – uses consensus mechanisms in our test net that we have here in the office, which is not public; but on our internal network we’ve been using it for a very long time. It’s been highly reliable and the paper itself has had many peer reviews as has the implementation. So I challenge the notion that it is somehow futuristic because it’s been used for a while now.
How is that different from delegated proof of stake?
Enzo: That’s another good question too. This is really an ideological difference that, I think, is between us and many other projects and that’s what we believe – that every validator should be the same. We believe that every person should have the same chances of minting the block as anyone else on the network. We don’t believe in special nodes with special privileges in our network. Everyone has the same opportunity as everyone else and, I think it’s a huge distinguishing factor between us and a lot of other pojects.
Cédric: Maybe to Harry’s point, “I don’t know when this question was submitted. So, maybe, he submitted just like a couple of months ago and definitely things looked further off. Then, we also talked about web canisters in the past. Maybe you could just speak about the concept of web canister and specifically about what it contains. I know it’s going to be application logic and probably it’s going to be state data. How these canisters could be accessed through ports from other actors and off-chain.
What is the concept of the web canister and what does it contain?
Enzo: The idea is that it has a collection of libraries internally that can be bundled up into sort of single actor; whereby, the development of that actor could happen locally on your laptop, for example. Just like, maybe you’re trying to configure a container locally, and at some point though you decide that with whatever you’re comfortable with what you have locally and that you want to take that code into production. There should be a process of seamlessly migrating if you will, what you’ve created for yourself locally to exist on this network that you can interact with in a programmable way. In the same kind of way that you imagine that you could communicate with the rest of the API, for example and for other types of Web services. I think that it add a lot of clarity.
Cédric: So last one but not the least, one last question by Jack that probably we received a few weeks ago.
Is there any plan to unify with Swarm/IPFS or provide an equivalent native DFINITY storage system. And if so, will this allow canisters to consume IPFS/Swarm data?
Enzo: There’s no immediate plan to integrate with IFPS.
Cédric: Cool. Short and sweet with the last question. Perfect. Well, thanks a lot Enzo for spending the time.
Cédric: You guys, if you enjoy this and if, maybe, more questions came up where you have some questions and that are on your mind, you’d like us to answer, go ahead and submit those in one of our community channels and we’ll make sure to pick them up during one of the upcoming Q&A; sessions. Perfect.
With that, Talk soon.