# Full Transcript
0:00 Piers: Alright. Let’s jump into the questions because we’ve got quite a few questions on our sli.do. Thank you very much everyone who has done that. We’re going to start off with the topped-rank question. We have 81 questions, the first one is:
Question #1: Usually, engineering in this space involves making tradeoffs (like the scalability trilemma). What are the biggest downsides of the Radix approach?
0:35 Dan: Downsides… well Radix is designed to hopefully not have many of those. It is interesting that the scalability trilema has been quoted in that question. It makes me think a lot about the CAP Theorem. Now CAP Theorem says you’ve got these three things: consistency, availability, and partition tolerance. And it’s another trilemma - you can only have 2 of those 3. But what a lot of people seem to make the mistake of with CAP Theorem is that you can only have 2 of those 3 at any particular moment. So you may have availability and partition tolerance, but your consistency across the network isn’t consistent. But then at a different time depending on what the network is doing you can have consistency and availability but no partition tolerance. So the approach that was taken with Radix was the same kind of approaches with CAP Theorem. OK. So you can’t have all three at any particular moment in time but you can have two of those three and you can make some small trade-offs across the one, depending on what combination you are trying to achieve. For example in Radix, when you have an exotic conflict, we trade off a little bit of the decentralization and a little bit of performance to resolve that conflict, but that doesn’t affect the entire network the way that network is structured with gossip, the mass, which nodes are selected to actually deal with those conflicts. So those three components of the scalability trilemma they’re kind of relevant for each transaction and each transaction can be affected by a combination of those three individually at different time. So that’s kind of about the best you can get. So instead of trying to make the whole network always a hundred percent decentralized and a hundred percent scalable and a hundred percent secure, you can trade off bit of decentralization and a bit of performance on some nodes per transaction, so that you can still maintain a good approach into all three across the network at any one time.
The downsides of radix honestly I still can’t think of any. It’s why it’s taken such a long time to actually build this thing because I try to maximize the upside and mitigate the downside. I’m sure there are some.
3:30 Piers: Probably the best description of the downside is the edge cases of it being probabilistic, right? It’s a probabilistic consensus or probabilistic network and so you need a minimum number of nodes in the network for you to be absolutely sure.
3:48 Dan: Yeah, so if a network is small, then, like all distributed networks, your exposure to attack is more. Yeah it’s strength in numbers, but then any kind of distributed network has that same issue if it’s small and it’s not permissioned then it’s fairly trivial to attack until it starts to get to a few thousand nodes or larger. I suppose like with Bitcoin - the way that Bitcoin operates - if you accept the way that it operates is kind of de-facto, then there aren’t really downsides as long as you accept the limitations that it has. I think that we’re still yet to discover what those limitations are with Radix because everything we try to do so far we’ve been able to do quite easily. But that’s only because we’re still kind of taking traditional use cases and traditional applications and building those first because that’s what we know. I think once we start to get into more complex, more advanced multi-user use cases on the platform I think then we may start to see what some of the downsides may be where maybe have to make some trade-offs in terms of what can and can’t be done. As of right now it’s performing as expected, I’m pleased to report.
Question #2: Do you think you will have enough time to integrate DEX, economic model, and atomic swaps before going live in Q1 2019?
5:10 Dan: Tentatively: Yes. The issue recently has been that we’ve had to make a few changes to the protocol for a number of reasons: 1) Security, 2) A bit of performance and also 3) For longevity of the platform in terms of what we can do functionally that’s easier to build now than later on. That’s taken a little bit more time than expected as these things sometimes do - but the team is growing. We’ve got some really good guys and so I’m confident that we can claw back quite a lot at that time. The R&D on the consensus, the architecture, and the ledger is now officially over. After such a long time that doesn’t immediately feel real, right now. It’s kind of like a bit surreal dream. It’s finally passed all of its tests. To give it a bit of context, I’ve had these particular test cases that I’ve been trying to get the technology that we’ve been developing for the past six years to pass. Some of them are really nasty, complicated exotic double-spends, etc that have never passed. Ever. And, over the past two weeks, it started to pass a few more of the ones that have never passed before. Then as of last week and this morning, the last portion passed every single one! So that kind of draws a line under the R&D. These kind of edge case attacks were basically like running the network with the equivalent of a 50.9999 percent attack on Bitcoin - and it held up. So that kind of proves all the theory. We’ve tried on a network. It’s all been tested and unit tested. We’ve regression tested it against the alpha network as well. So from this point forward you should be able to pick up a bit of speed because when we won’t be bottlenecked by any remaining R&D issues on the platform side of things. So now we can go full steam ahead on DEX, economics, start thinking about how to integrate Scrypto, non-fungible tokens and all these nice things that we’re currently working on. As a growing the team, then I think we can hit everything just about by Q1.
Question 3: If RadixDLT is not going to sell tokens, then how are you going to monetize your years of hard work?
7:48 Dan: Donations! [laugh] Lots and lots of donations. So we’re still kind of trying to figure out actually what our revenue models are going to be like over the long term and there’s a few obvious ones such as consultancy and obviously we’re gonna run some nodes ourselves that take part in transactions and they’ll collect fees and rewards - that kind of stuff. I think the kind of business models that you can apply with this technology, it kind of sits in the same category as the things which we’re currently trying to build on. I mean, it’s such a new tech that there are probably many novel ways to monetize this stuff over the long term but no one’s really figured out what those models are yet. We’re still trying to apply old business models to this kind of new tech. So aside from the obvious I think they will emerge as and when we start to see the developers come on board and interesting applications and maybe there’s some ideas that we have applications in the future that we can build and we can monetize to reward and monetize our years of hard work. But I think that will be an ongoing process much in the same way as it is in any emerging industry.
9:15 Piers: I think our approach here is very much first and foremost how do you ensure the success of the platform and then secondly how do we make sure that we get rewarded for that success - in a proportionate and fair way. So much of our focus to date has been on that first bit. How do you make sure the platform can be successful. How do you make sure that any barriers to entry, for anyone using it, are as low as possible – to reduce the friction for when it drops so that people can kind of use it in all of the wonderful weird and exotic ways that people have already started using DLT technology. So for us that first key piece of making sure the technology is right and making sure that that all works comes first and then the second part how do we monetize it, I think that as we go closer to implementation and as we sort of start to think more about the next level up; everything from governance to how the atom model functions with the fees, to how the DEX functions and then to how we’re going to put the Radix network live, there becomes more and more areas where we’re like okay so here is a fair way of rewarding foundation, here’s a fair way of rewarding the founders of the company. We’re not going: this is how we want to make money and then how do we shoehorn that into the platform. We’re going: how can the platform be successful and then making sure that there are revenue streams out of that to ensure the longevity of the platform and also to make sure that obviously Dan and the team are rewarded for the hard work that’s been put up in to date as well.
Question 4: Do you see any competitors to RadixDLT in terms of scalability (like Ethereum, Zilliqa, Constellation, Hedera Hashgraph, IOTA, Holochain, etc.)
11:00 Dan: Interesting question and there are some quite ingenious ideas out there on how to scale these kind of technologies and honestly I’ve been outside the camp of most of those ideas for quite some time and some of them I even tried them a few years ago and determined the amount of effort to make them succeed outweighed any benefits they would bring. I think that once we start to be able to move a bit faster on our scalability testing which has also been bottlenecked by what we’ve been working on recently and we can actually start to achieve those high numbers I think I can have a lot more confidence in saying: “no”. Hitting a million TPS is hard … really really hard. I spent five years of my life trying to figure out how to not even get to that - originally the goal was to get to Visa scale - now that was back in like 2012-2013. Then with the obvious emergence of IOT devices and all these other connected things that will be around in the future; your fridge, your toaster, your car, whatever… all connected… supply chain and all these kind of things… it became apparent that Visa scale just wasn’t enough. So looking forward I think that for any kind of DLT technology to be really viable in the next decade you’ve got to be hitting a 100K a second at least and to achieve that really is quite difficult. It’s not just a case of: Yeah, I got a blockchain and can put some side chains on it and Bob’s your uncle and everybody’s happy and you can have toasters and they can chat with each other and that kind of stuff.
12:56 Piers: I think that the type of transactions per second what is actually being done needs to be really underlined as well. In some of my talks I talk about the “decentralization ratio” which is the number of nodes that the final arbiters consensus divided by the total number of nodes on the network, or the total number of full nodes on the network. And if you look at systems that use some sort of delegated consensus algorithm or some sort of centralized authority or even like a consortium of authorities, those consortia tend to remain the same size and they can’t get larger purely because very often there is a constraint of the synchronicity of the system. Blockchain is a synchronous system so something like EOS needs to have these these coordinator nodes/validators. And so they need to actually be a small number and stay a small number because you can’t move the information fast enough between the nodes otherwise you come the same problem that you do with a sort of a standard blockchain. So if you take the total number of nodes the final arbiter of consensus divided by the total number of nodes in the network; you get this decentralization ratio and what you see with any coordinator based system is as the network grows you tend towards fragility so that numerator on the fraction doesn’t get much bigger and so it stays about the same time but the denominator ends up being getting larger and larger and larger, so you get this you you end up getting a smaller and smaller ratio and the network ends up being more and more centralized. So when we talk about centralized and decentralized and when we talk about things like side channels and stuff like that, yes you can do a million transactions per second in a side channel but you have a problem as soon as you need to get out to that side channel into another side channel you’ve got your main blockchain problem and then if you look at something like IOTA or any of the DAG based ones, again they have these coordinators or they have these constellations of economic constellations where again you have a small number of nodes that are responsible as the final arbiters of consensus of the network and it’s not really a fully decentralized system. What you really need is to move away from that because if there is ever a sense of the network you have it you have a state of fragility and as it gets bigger and becomes more important to the world it becomes more fragile. So yes there are competitors to Radix in terms of scalability just from the point of view of: are there other projects that are attacking scalability but from our point of view we don’t see any projects who are able to do full scalability and full decentralization. It’s always a hybrid of one and it comes back to the trilemma that Vitalik Buterin first put out.
16:12 Dan: So getting back to the final arbiters of consensus. The best way to think about the way Radix deals with that is that each transaction has a set of final arbiters of consensus, but that’s each transaction for each transaction that would be a different set. So even though you get a particular set of nodes that are responsible for resolving a conflict on a particular transaction the rest of the network is doing other transactions so in essence your division of arbiters versus full nodes, it doesn’t dilute quite as badly as say a vertical blockchain system or a DAG because it’s per transaction. So it’s not like a block where you’ve got a bunch of transactions in there. And because it’s per transaction as well… and each transaction has a different set, it’s very nicely load balanced around the network and so every transaction has a different set of nodes that deal with its consensus and that also makes it, of course, very difficult for an attacker to take control of that consensus algorithm as well because he needs to then have many loads and in the right places and you need to know where those nodes need to be when you’re producing the transaction and he needs to spend a lot of time, money, effort, and logistical work to put his nodes where he needs to be to take the transactions. So yes that’s the background on that interesting tidbit that he brought up.
Question 5: Has the protocol the same problems with forks as bitcoin when new/updated stuff gets implemented?
17:46 Dan: In terms of upgrades, yes you can have the same issues. So I don’t think there’s ever going to be any kind of DLT that solves that because you’re gonna have stakeholders in the network and some of those stakeholders maybe won’t like the changes that have been proposed by the main devs. So you may get a Radix classic at some point if there’s a set of node operators in the network that don’t like the changes that we proposed. I don’t think it’s quite as detrimental as it maybe first appeared way back when – when forks of Bitcoin starts happening you got Bitcoin and Ethereum classic, Bitcoin gold and Bitcoin Diamond and stuff. Because Ethereum and Bitcoin are still the granddaddies of those particular technologies and then you kind of have these niche implementations that’s still a particularly use, which is fine and I don’t think there’s a legitimate way to prevent it even if you wanted to and then you get into the morality of it all while should we prevent it? It is supposed to be an open decentralized system so if you’re forcefully preventing forks – it’s not really decentralized anymore anyway.
Question 6: Are there any circumstances under which the economics system would generate XRD and transact directly on the DEX, bypassing holders and node runners?
19:09 Dan: So there’s a lot of questions about economics in here and I don’t really want to get into too much detail because we’re still ironing out a lot of the bits and pieces. So all I will say regarding the economics and I apologize for everybody here who’s asked all the questions and I don’t want to go into too much detail before its final because then everywhere I go from that point everyone will be like; ‘you said this, you said that’. So there will be times when the DEX or the system will intervene in the economy via the DEX to buy or sell trades based on a supply and demand function algorithmically-- not decided by us. It’s completely decentralized so it undergoes the same process as anything else in the network. The nodes have to agree that this is the action that they agree that the economics has to take. All nodes that take part in that decision will have all the information available: what the DEX has been doing; what does the order book look like; what’s that the demand coming in; the supply; all this kind of stuff. So it undergoes consensus as well isn’t like a big leave that anybody can port to try and influence that because there are times of course let’s say that everybody in the network is hodling and the price is shooting up because no one is selling.If you’re a stable currency or trying to be a relatively stable currency you don’t really want that to happen so you need to have a kind of buyer and last resort that could step in and dampen those price movements, which is what the system will do through the DEX. The reason it bypasses holders and node runners is if it creates more supply and gives it to those individuals and they’re just holding any way because they’re seen the price go up then they’re still not going to put any liquidity into the market, so it’s kind of like well you guys aren’t keeping the market liquid so I’m gonna keep it liquid until you start to actually liquify some of your own assets to feed the device and sales on the market. So it kind of also incentivizes holders of node runners to actually say take profit and put some liquidity into the market but if they don’t the system will take it all instead and they won’t get it.
Question 7: What is your marketing strategy? How do you plan to attract more developers, investors, big companies?
21:40 Piers: Okay, so those are three very different questions: 1) How do you attract more developers? 2) How do you drag more investors? 3) How do you attract big companies? So on the first, on developers, that starts with documentation, how to’s, outreach, hackathons, developer events and meetups. It’s all very grassroots-ish and start small. You don’t want to have a big bang. What you want to do is - you want to identify a small group of people for whom you are addressing a set of problems for. Create great documentation around that. Create great how to’s and information frameworks. And really just make sure that the materials that you’re putting out mean that someone can come cold into Radix; realize that it solves a problem for them; and then get straight on to building something. Because, for us, it’s all about shorting that time frame from hearing about Radix to actually building something meaningful on the network. So our focus on the developer side is how do we do that and then how do we get the feedback. And the feedback comes from meetups which we’re going to be doing more of in various cities that we’re focusing on - as well as virtual hackathons and challenges that we expect to be putting out as well. So all of that flows into our developer strategy. But the most important part of that is basically putting out things that we think help people build and then getting feedback on that, to make sure that it is actually helping people build. And it’s really as simple as that - there’s nothing shiny or ostentatious about it. It’s just really trying to get directly to the people that we’re trying to help and having a real conversation with those people. 2) How do you attract investors? So that actually comes down to the economics discussion. So a lot of what we’ve been talking about in the economics is how do we make sure that people are rewarded for coming in early to the system; and giving incentives for the network to grow; and recognizing the different stages of the cryptographic platform. Again the details of that will be coming out with the economics white paper. And you know, there is a decision of a gap between pushing out the technology and pushing out the economics. Because what we don’t want to happen is the economics to end up drowning out the discussion around the technology. So we are very much delineating that. But we’ve already had 14,000 people express interest in getting tokens in Radix. There is a lot of interest in the investor community and in the grassroots or individual investors and token buyers – we don’t really have a good strategy yet for how to engage with those people. So that is still is pending. And we will be doing that once we’re sure that we’ve got the technology in the hands of the people and that they’re starting to build real things. Then we can start having that conversation about how do you create incentives for more money coming to the system as well. 3) And then big companies. Look, a corporate sales cycle is 9 to 12 months and often has a lot of different interests within a corporation’s structure to contend with. It tends to be quite slow going and can often just be, from the corporation’s point of view, a marketing thing rather than a real use case that solves a real problem. We are in the talks with it with a few different large corporations of how they could use the Radix public infrastructure. And it really is focused on making sure that Radix infrastructure is always first and foremost in our minds when we’re talking with people. Because ultimately the success of the entire Radix technology platform relies on people using the public infrastructure. But big companies are not our primary market now. For us it is looking at a new technology as a breaking point for when people start implementing new systems. And you know, if you looked at the Internet and said what does the Internet do for the companies that were around and were the big companies at the time when the Internet came about - many of them while then may look like really attractive companies to be putting DNS or TCP/IP services and servers and all that kind of stuff. Actually the big companies that ended up being the Goliaths of today were born out of small startups. They were the people who built on the revolution of this new technology and were digital natives of that technology of the Internet - and then grew their companies from there. So for us, our real focus is on the developer entrepreneurship - the startups, people who understand this technology and intrinsic point of view and are starting with a green fields installation and can actually really move quickly and start testing out building things very quickly without having a load of corporate bureaucracy and also having to deal with the load of legacy systems which can make things move incredibly slowly. So with big company sales we’re not adverse to talking to big companies. But a lot of the time you’re looking at a very large amount of resources for potentially not a huge amount of gain. So we always weigh that up in our decisions and where we allocate our resources and who we’re focusing on most.