Mission Control Q&A Part 1

Robert and I sat down to answer some community questions. If you have questions you’d like us to answer – leave them in the comments or in our community channels!

Answered questions:
[0:37] What measures does DFINITY take in order to prevent miners running on AWS?
[3:34] Is there going to be something similar to the ERC20 standard on DFINITY?
[5:09] Will the Haskell to WASM compiler support GC?
[6:15] Will DFINITY allow for private on-chain computation?
[8:30] How running a website from DFINITY actor/web-canister would work?

Video Transcript:

Hello, and welcome to another Episode of Inside DFINITY.

Today I’m joined by Robert, and we are is going to answer some Q&A that we got from the Mission Control community. Without too much ado, let’s jump in first question from Jack Winters. So, Jack says, “Recently, we’ve noticed that large majority of the miners in EOS are using AWS infrastructure to run their miners; kind of, defeats the purpose of having a decentralized network?” So, he asks: “What measures does DFINITY take in order to prevent a similar situation to happen for DFINITY? Robert, what insights do we have?

What measures does DFINITY take in order to prevent miners running on AWS?

This is a very good question. It is, indeed, the problem if everyone uses the same infrastructure to host the remaining equipment; and there are different approaches to this issue and one of them is incentivizing people economically not to use the same hosting provider. And one way of doing so is you can have a penalty system where your individual penalty depends on how many or which fraction of all nodes failed. This way, if like 10 percent of the people are using the same infrastructure, the same hosting provider and it like goes offline, then, your penalty would be higher because, then, 10% of all the nodes failed.

Then, in a case where just you, maybe as a small node, just went offline, in that case your penalty would be lower. Failures that only effect like a small fraction of the nodes are much less risky for the health of the whole network and failures that effect a bigger fraction of nodes. So, that’s one approach based on the economic incentives and penalties. There are other approaches. Once, we have introduced sharding, then, it would be possible to have shardes where people are required to run their own hardware enclave. So, they would have to run hardware with SGX and that also means that you could not outsource your computation to hosting providers. And that stays, at leas,t as long as there’s no AWS for Hardware if SGX chips.

A third way of how DFINITY is working against this and that I want to point out is that we’re also actively reaching out to a wide variety of people who are interested in mining already, including data centers and hosting providers. Right now, it’s part of my role at DFINITY. So that we can guarantee at the launch of the network that there’s a pretty wide and broad support network and not just individual miners who host their hardware on AWS or one of the big cloud providers.

Thus, three things: sharding of specialized hardware, a large number of different hosting providers at the network launch, and, third, economic incentives that discourage you from using a large cloud provider, which could result in a failure of a big chunk of the total infrastructure for the network at any one point.

And one more idea that Robert just had right now. Discourage people from outsourcing data by using or applying a scheme where you are forced to combine your private key with the data that you’re outsourcing: which means that you would have to trust the provider, the cloud or hosting service, not to abuse your private key. So, that could be partial solution which would like, at least, excursion for outsourcing their mining to non-trusted trusted third parties.

Great. So, there’re total four ways of how we’re trying to deal with that problem. Thanks a lot for the question, Jack.

Is there going to be something similar to the ERC20 standard on DFINITY?

Moving on, so we have another question from a first-timer: his name is Fulco. Fulco asks: “Is there going to be something similar to the ERC20 standard on DFINITY?” So, ERC stands for Ethereum Request for Comment and has basically established itself as THE standard for tokens on top of the Ethereum blockchain. Ethereum 20 is just the number 20; it just means that it was request number 20 that was submitted or proposed. And when you go and look on Wikipedia or any other source that shows you what the ERC 20 token standard means, it’s basically a number of methods and events that a smart contract has to provide in order to be compliant with this ERC 20 standard. Robert, what’s our plan for anything like an ERC 20 token on DFINITY?

We have this vision of creating an internet computer, which can do much more than just allowing you to create tokens. It doesn’t mean that we are opposed to or we are not in favor of having the standardized token systems on our platform. I think it’s open to anyone to propose a framework which could become a standard for tokens; so, we are not actively pursuing that way but we are open to suggestions.

DFINITY’s each team currently has their hands full pretty much with building the underlying technology for the internet computer; so we’re not even thinking about all these different application standards yet. And the way we see it as the DFINITY will do much, much more than just being a token network. So, we’re not focusing too much energy on providing such a standard. If someone wants to provide a protocol that is very close to ERC 20 but works with DFINITY, they’re open to do so, and we’ll see in the future if that’s going to become a popular use case of the DFINITY blockchain or not.

Will the Haskell to WASM compiler support GC?

And with that, onto our third question for today which comes from Christo. “Will the Haskell to WASM compiler support GC? Maybe, Robert, before we answer the question, “What does GC mean in this context?”

In Haskell, garbage collection is very important; it means that the compiler needs to remove old data from the memory, which are not used anymore or for any purpose, because if that’s not done, then, the amount of data can quickly become untreatable or untrackable. And it’s particularly important in Haskell, because Haskell, as a functional programming language, uses like immutable data. That means that if you have some recursive call or some function that calculates a value in multiple steps or iterations, then, for every step of your calculation there would be a new entry or a new data point in your memory because your Pascal doesn’t change the value of one variable; because that’s not the philosophy or not the way how Haskell works. So, garbage collection means that the compiler offers an automatic way to remove unused data from memory. And it is very important in Haskell, even more important and in imperative programming languages.

Will DFINITY allow for private on-chain computation?

All right, our next question comes from Jordan, “Will DFINITY allow for private on-chain computation? By that I mean, will DFINITY allow smart contracts to execute they’re called privately? Will I be able to execute and store private information in and around smart contracts?” Maybe, before we answer the question, let’s talk about where this could be handy. “What’s an example for an application where this will be helpful to have?”

Basically, any kind of application that uses private data or personal data should have some system that guarantees privacy. This is not only useful, but it’s also prescribed by law: by the Data Protection Laws of European Union, at least. So, I think it’s very important to have systems that allow you to keep your data private on a blockchain. Generally, a blockchain is an open system which means the data that you store on chain is transparent and can be viewed by anyone. But that doesn’t mean that your data cannot be encrypted, and it’s also possible to do the computations based on your encrypted data insecure enclaves like SGX.

Where do we stand with the DFINITY app? To which degree do we already have an idea for how this will be possible at DFINITY? Will it be possible for everyone? Will it be possible for potential subsets? What’s our strategy as of today?

In DFINITY, there will be shards that will use SGX, enclaves; which means that your smart contracts execution could be done all in private on such shards, it’s our plan for the future.

I think I’ve mentioned it in a previous video, so we definitely have to sort our roadmap but it’s probably not going to be something that we will release in version 0.1 – the first public release. And, therefore, we have not figured out all the details, what we are going to do, and how we are going to do it, but we do understand the need of our users and developers.

How running a website from DFINITY actor/web-canister would work?

Let’s jump on to the next question. So, Dylan Miller, who is also frequently active in the mission control group, asks the following question. He’s watched the videos from October of the last with Dominic, where Dominic describes our first test. In there, Dominic talks about the use case where you could run a website from DFINITY actor or smart contract, or whatever you want to call it, web-canister. And Dominic mentions that this canister can hold all the data HTML, Javascript, and all the relevant execution code, and could make it available to a browser. Dylan asks, “Can we explain in a bit more detail how this would work both on a technical side and also how updates would work? How would you update the front-end of such a web service?”

Our web-canister model allows you to connect your web-canisters with the outside world, which means that you can have like a front-end application in your browser that communicates with some actor running on-chain. And it’s also possible to have the code of your front-end own chain, and you can download it from the chain that should be possible. So when it comes to updates, the owner of a contract who originally deployed the code on the blockchain, could foresee for the case of updates. He could add functionality to that contract, which allows him, i.e. the owner, to upload new functions or to replace the code of existing functions. That should be possible.

And, of course, theoretically the BNS could also update the code of any contract even if it doesn’t include this possibility, but, normally, you as an owner would take the appropriate measures and include such functions that allow you to change the code later on. So, there shouldn’t be a problem technically.

Costs of Updating

The question about the costs with regard to updates: when you upload data to a blockchain or when you deploy a contract, you will have to pay gas for the transaction which registers the data on-chain. Probably, or maybe in future we will also consider storage rent, which means that whenever you add new data to the chain that needs to be stored in a persistent storage, you would also pay for the storage. But currently we are not focusing on that.

So, basically when you update your code, you will just have to pay the regular transaction fees for executing this transaction.

Good stuff. And with that I think that that’s a great point to take a break and conclude this Part One. Tune in tomorrow for the second part of our Q&A session and with questions for our Mission Control. And with that, we’ll talk to you soon.

Comments


Cédric Waldburger

Cédric Waldburger

Founder of Sendtask.io 🚀. I'm passionate about startups 👨‍🚀. I live out of a carry-on 💼. I own 64 things. They're all black.

Get tips & advice on essentialism delivered straight to your inbox