Norton and I sat down to talk about where he’s from, how he first learnt about crypto and what he works on for DFINITY. We finish with a quick view into the state of the DFINITY SDK.
Cédric: Hey, Norton. Hey, how’s it going? Thanks for taking the time.
Cédric: Another episode of Inside DFINITY, where we are going to give you a bit of a look behind the scenes or specifically in this episode of the people that work on DFINITY.
What are you working on?
Norton: Right now I’m working on some of the system actors – system actors are the set of smart contracts that live in the system that manage things like user identities; various registries for minors, for neurons; governance stuff and some of the DKG stuff as well.
Term Actor vs. Smart Contract
Cédric: You mentioned a term actor or smart contract – what’s the difference between the two.
Norton: They’re both sort of conceptual entities – an actor is just an object that can receive messages and then process those messages, and it’s just a way to handle concurrency in systems. A smart contract really is just a code that people trust and can do things. So in the DFINITY programming model we use actors and I like the term actors instead of smart contracts, because generally when people write programs in any blockchain, they’re not really smart and they’re not really contracts; so for me personally I don’t like the term smart contracts so I just call them actors.
Cédric: We’ve also heard the term web canisters in some of Dom’s presentations before. Are web canisters the same as actors or is there a conceptual difference?
Norton: I guess web canisters will use actors underneath and web canisters are really just a high level thing; it’s a collection of actors that can store data and perform operations and allow users to interact with them outside of the system.
Cédric: So an actor is just the business logic, right? Or is there some data?
Norton: Yes. Actors have a private state that they can manipulate; so let’s say you have your actor that adds two numbers together and stores that in private state so it would expose a function called add-in and then you would grab a reference to that function and then send a message to that function. So here add these two numbers together, then the actor is going to perform the operation and update the state.
Cédric: Where do we need to innovate when it comes to building these actors?
Norton: Something like DKG, for example, which Easwar was working on and I’m assisting there – there’s a lot of message overhead; so let’s say in one round of DKG with like 400 different entities, different mining entities – that’s like four hundred times two or three messages that need to get send back and forth on-chain. So it’s just building these actors efficiently to do things fast and with the least amount of message overhead possible. That’s a challenge.
And also like another thing with the actor model is that when you’re reading data from another actor – so let’s say you had actor X wants to read from actor Y in something like Solidity, you can just say, “Hey. Give me the contract at address Y and just get me these values and that’s it. Super easy. Whereas in the actor model everything is done via asynchronous message passing – so X would have to send a message to Y, and then Y would… X would have to provide a call back inside that function, and Y would basically call that call-back with the data that X wants. So you have to think about it differently. You can’t just assume that you’ll be able to read data immediately.
Benefits of the Actor-Model
Cédric: Hearing data it sounds like complication, right? So what are the benefits that the actor model provides over?
Norton: It is a bit tricky I guess. It takes some getting used to but the benefits are just in terms of benefits versus something like EVM, where EVM is done synchronously; and you have X calls Y and Y’s call calls back to X and you have these weird data races that you can’t have the in the actor model because X can never be processing multiple messages at once. It has a message queue so if X calls Y and Y calls back to X, X has to finish processing the first message before it starts processing the next message – so you just avoid a whole class of issues.
What did you do before joining DFINITY?
Cédric: In a broader term, you’re one of our engineers, ‘What did you do before joining DFINITY? And how did you get in touch with us?
Norton: I started at a Bitcoin OTC software company back in 2013. And, then, during the whole private blockchain crazy-phase of 2014 or 2015, we switched gears and worked on private blockchain stuff – in the financial derivatives space – and so I was there for a couple years doing Solidity-related things. How I got in touch with DFINITY is pretty funny. I was just in town for a conference earlier this year and I just sent a cold email to email@example.com, and Arthur responded and he was like, “Hey. Come visit the office. And I was all right. Great. So I came here, met a bunch of the team members; I thought it was super cool. I was already following the DFINITY project for a couple months and I thought it was just a very good solution in general and just a good project to follow. So I got a job offer and I took it. So here I am.
Cédric: It’s easy as that.
Cédric: Something else that you’re working on amongst others is the SDK, right? It’s the software that we want to publish and distribute amongst our developers that
allows them to build actors, deploy them, and work with them. How far are we with that? And what other things that it’s capable of right now and what are some of the things that we’re currently working on?
Norton: The SDK is a way to develop applications without the actual blockchain, without consensus – so it’s similar to Truffle, where it doesn’t actually have a blockchain but it just allows you to write and compile programs. The SDK will allow you to write C and compile that into WASM and run that inside DFINITY’s
Cédric: You mentioned Truffle. What is Truffle?
Norton: Truffle is a command-line tool for Ethereum, which allows you to compile Solidity, run tests, run migrations, and connect different networks. Eventually, SDK will offer you the exact same functionality, but right now it only has just simple compiling and testing of actors.
Cédric: Cool. Let’s move over and have a quick look at that and see what the state of the SDK is right now. All right. Cool.
State of DFINITY SDK
Norton: I’m just going to run through some test scripts that use the SDK to compile a bunch of the system actors and just run some basic tests. So it’s a bit hard to see what’s going on but basically this is just creating a bunch of actors so the test basically initializes the BNS actor, which is the main actor that coordinates all the other actors – things like the minor registry, the epic, the keyframe, the DKG, essentially the BNS actor is triggered every block and the BNS actor knows when each epoch happens so then on each epoch it should trigger the DKG to perform a round of DKG.