Casper Community Calls, 4 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CasperLabs Community Call

Description

Engineering update, Roadmap update, Contract Governance

A

B

Implementing uh senior distribution.

A

All right, you're in the code, I love.

A

A

All right we'll get started good morning good afternoon good evening. Everyone uh welcome to the community, call I'm meta parlocar, the cto of casper labs and today we're going to do a engineering update status, update on the project.

A

We're also going to talk about d5. The community really wants to know about how casper labs is going to participate in the d5 boom. That is happening, so lots of excitement around d5. I also be talking at the global defy summit put together by draper golderhorn golden horm um or golden home uh this week uh this thursday morning. That is a free seminar, so feel free to register online. I think it's defy globalsummit.com and check out some incredible speakers.

A

We've got some really great speakers on stage for that, so very excited to be participating in that conversation, and uh so, let's get started with engineering status. So we do this every tuesday morning at 9 00 a.m. Pacific, the information. If you want to join the call itself you're most welcome to join the call. You can ask me questions. If you want is available on telegram and our discord, you can check us out at casperlabs.io for that information.

A

If you want to join the calls, no problem- and it's also of course here in github- I'm sharing it up on my screen. So it's live stream. Then there's a zoom call, let's talk about uh where we're at so the team has entered the fourth and final sprint of the 20.08 release cycle. This is sprint 4.4.

A

The focus here is to get to a minimum 20 node network, with the new rust node and certain economic features like bonding and bonding senior edge, et cetera, so um oh noor is talking, uh was just telling me before we started that he's actually actively involved in the senior edge implementation, which is kind of cool uh release. Dot 20.1 was cut on friday of last week and this fixes some bugs.

A

We found on the contract, runtime and clarity and python client early in the week, we're also uh having a hot debate about accounts in the pro in the system. Right now we did a. We did a feature that unifies the notion of account across a variety of different public uh private keys, a public key story. So we can support any number of public key types by representing them internally, as account hash. But we had a lot of validators get confused because of the way that information is presented in the clarity interface.

A

So we will likely be rebalancing the test net here after we get the process of communica of identifying and communicating public keys to us uh cleaned up.

A

So once we get that cleaned up and rationalized, we'll probably bounce the network, because there were about six or seven validators that had errors in their public key that they communicated to us, which was unfortunate. We want to get as many in as possible.

A

So this uh this needs to be updated, but this is basically beta phase. Two of the test that was launched on monday. It went live yesterday at noon, and this involves uh this test net has uh is code complete for all the smart contracting features. So we completed our work in the contract runtime by adding support for contract, headers and macros.

A

That will make it very easy for you to specify headers in your contract and um we are going to be pushing forward with engaging with developers and the dev dow, uh which is an independent entity, focused on developer adoption in the blockchain space, but they are uh have a you know, a partnership with casper labs, and we will be allocating a large portion of our token pool to this independent entity to support the ecosystem of casper. The casper allows protocol development on the protocol startups and core development and governance.

A

Current focus uh highway protocol so we're building highway core with the liveness test with and without uh equivocation, and we're implementing senior edge, as owner said on on the node rust side, we're building out the bonding auctions piece and we're implementing validator set rotation. Validator set rotation comes with the bonding auctions.

A

Node scala is in maintenance mode. We're not doing any work except critical fixes for test net contract. Runtime is mostly feature complete.

A

We are likely going to make a change to the runtime that involves simplifying and rationalizing accounts and contracts into a single type, and what that means is everything in the casper labs protocol will be a contract. Even an account will be a contract and I'll dig into a little bit more about. Why that's important when we talk about.

A

D5 we're going to be moving clarity into a separate repo. We have created um the casper labs ecosystem, uh github organization, which we'll be turning over to devdao. This is going to be a completely excuse me completely open organization for building uh in the casper ecosystem, building tools, products apps, whatever you wish, and the clarity explorer will go there as a separate repository, we're also extending the solidity transpiler.

A

This is a very exciting uh piece of technology that we're building, which allows us to transpile solidity contracts into rust and then subsequently wasm, and this will enable solidity developers to continue building contracts in salinity, a language that they're familiar with and they have expertise in. But the really cool thing about this is because it compiles down to webassembly and runs on our engine. It runs an rvm you get access to all of the smart contracting features that casper has. That means you know upgrades contract packages versioning account.

A

uh Basically, all the cool, very cool account features you get access to, that. You also get access to the uref. The unforgeable references and purse model, as well as some of the higher order. D5 features that we're also going to talk about later um yeah and we're updating some contracts with the dsl.

A

So you can uh very easily see how the contract logic is expressed, and this will help new developers in terms of setting up patterns for them to use right. So they can use these contracts as a way to bootstrap their development.

A

Economics, research, you're working on the token vintage model. This token vintage model basically says: if you bond into the network and you stay bonded, you receive more rewards for being a long-term validated bonder. I mean long-term bonded validator, sorry, um so uh token, vintages basically gives you more uh incentive to stay bonded into the network and then, of course, uh works continue to work in our chain link integration to help stabilize gas fees and express them in terms of fiat.

A

So that's the core development update. um We are we'll be looking at setting up spinning up another test net net network in about four weeks. At this time, we're going to open up participation in more validators to work with the rust node. We will probably work with the validators that have been participating with us since alpha to work with the rust node in the early days of the rust implementation, um because it's going to be pretty buggy and we're going to need them to do a lot of work with us and work closely with us.

A

But then we will open up participation for more folks into the proper beta test net, um so they can get their introduction to casper labs and casper labs technology and then eventually we'll be moving everybody over to the rust node as part of the delta test that time frame so onur alex did you have anything to present before I do my talk on d5.

A

Oh actually, no I'm not needy.

B

A

B

Anything substantive I mean technically, it is my turn. I don't have anything substantive, but uh I mean I could talk about a few, the design decisions that could uh use. uh You know sort of public feedback. If anybody has any feedback.

A

Okay, so why don't I do my d5 talk first and then we'll go into uh going to your piece and we can talk about pieces, public feedback yeah. So we got you know we were asked by the community. uh They wanted to really hear about.

A

How are we going to? What are we going to do for d5 and is casper labs going to be.

A

A pretty big heavy hitter in the d5 space for a few reasons, so let's kind of talk about what those big reasons are right, so one um the cbc casper protocol is going to be a fault, tolerant, highly secure protocol right. So it's going to be permissionless to the extent where we will optimize for consensus overhead. We will make the protocol as accessible as possible for anyone that comes into the network right that that procures your stake goes through the bonding auction process and bonds onto the network.

A

So that's going to bring uh about a lot of security, and you know I've been asked in terms of what the original like the the initial validator set size is going to be. We suspect it's going to be somewhere between 250 to 300 validators, and we hope that over time, as you know, network latency goes down and cpu processing goes up. We can safely continue to increase the validator set size in a manner that it will not dramatically affect performance and latency to finalization right. We don't want the user experience for fine.

A

You know time to finality to become so large that, because we're waiting for a lot of messages to land right, so the more messages you're waiting to land the longer it takes to finalize blocks. So there's like it or not, there's there's a balance there right. um We it's going to be faster than you know. We can have block times about 15 seconds, but it's definitely going to be faster than what you would typically expect in.

A

You know bitcoin or ethereum in terms of block finalization, and we will actually not have probabilistic finalization but provable finalization right. So the cbc casper protocol is provably safe and the highway protocol is provably live, and so we want to step away from statistical finality or probabilistic finality or probabilistic liveness and really get to provable, liveness and provable finality. We think that these are important things. So that's the first thing. The second thing that we'll do for dfi that will be super important.

A

Is we offer very very strong, so we offer great governance tools right, so we're a touring complete platform. So if you want to think about having programmable money, that's what dfi is really all about. The casper protocol isn't just about rote transactions right, so there are many protocols out there that they purely just focus on payments.

A

Casper protocol isn't about payments, but it's a touring complete platform. That means anytime, a transaction goes through. The vm is going through a full state transition um and it means it's more like a computer than it is a ledger right. There is a ledger associated with the computer, but what goes on to the ledger is actually a state transition, not just a set of transactions.

A

The transactions are represented, the straight transitions are represented as a series of transactions, but really you're. Updating the internal state of a virtual machine um and those uh those state transitions get recorded on the on the global ledger and that's the global state of the blockchain.

A

So that's. The second thing is that it's actually a full turing complete system where you can have programmable money.

A

The third thing is: is we provide governance tools for the governance of contracts? And I think this is really really important and you know the funny thing. Is you hear a lot about governance in the blockchain space, because we've now decentralized the governance of software and that's why it's a really big deal on blockchain? But if you really step back and you think about it, every single piece of software that's ever been released is governed in some manner.

A

There are governance protocols for linux, there's governance protocols for the software that microsoft releases, those governance protocols for the software that amazon releases they just aren't decentralized, they're, not publicly known they're internally known to all those organizations right. I can tell you that if you happen to release a patch to salesforce and you bring down the salesforce service for 30 minutes, heads will roll in the company. I mean I'm speaking figuratively, but there will definitely be consequences for you to if there's out, uh downtime right, so there's very, very stringent protocols within all these organizations.

A

Governance rules around how software is specified, developed, tested and released, and what we have done is. We have provided tools at layer, one that enable protocols to govern themselves transparently on the blockchain, and I think this is really important, that it be done transparently and on the blockchain um to you know, protocols that don't provide the tooling or make it easy and flexible and powerful for contract authors to govern their on-chain code are going to have challenges with that governance.

A

Right um people are creative, they find ways to work around it, but they're either going to have to do it off-chain, which means it's no longer transparent, and it's up to a certain number of people to make decisions about the software, which means now you're, centralizing it or complete power corrupts completely, and so we have tools such as multi-key signatures, account delegation, contract upgrades contract packages, protocol right contract protocol uh supported protocol versions, as well as contract versions. All of these tools really are things that you need, even in a private enterprise.

A

I have to be able to specify who can run my contract. I have to be able to specify how my contract is upgraded. I have to be able to specify who gets to upgrade my contract. I have to be able to specify things like uh which version of an operating system, my contract, my software, runs on that's a protocol version. These are all things that I saw as really essential in software development period. It's the way software has been built for 20 years.

A

It seems silly to not have this kind of functionality on the blockchain right. um Blockchain software will need to be governed like anything else. So that's one reason why we're going to be there's another reason why we're going to be real heavy hitters in d5 and we've already validated. This we've had conversations with some of the big d5 protocols out there and their number one concern is governance right? How can we be? How can we govern ourselves? How does this happen transparently on chain really really important?

A

um So that's that's a big piece, another big piece. Why, I think we'll be a heavy hitter in d5? Is we provide the tools for developers to test their contracts?

A

I just had a call with one of our advisors yesterday and he said well we're trying to build a testing framework for a company and they have multiple smart contracts in their application and they want to test the dependencies between these smart contracts. How do we do that? Well, the really cool thing is in the casper protocol.

A

Our tooling enables you to basically pre-populate your global state within the test, harness that you run and this test harness can actually run on a build server and for those of you that know how software is built. You know that you use things like travis and drone and jenkins.

A

These are open source tools that have been used for a really really long time and not being able to do this with your smart contracts is crazy right. These are financial applications are going to have potentially billions of dollars locked in on them massively important right now, because of what's happening in d5 there's over what four billion, maybe more, um maybe more than four billion dollars locked in you can actually imagine what would happen if there's a bug right and you can do- definitely do formal verification to help that process.

A

That's absolutely something that needs to be done, but the idea that the first version of your software is going to be perfect, really has only ever worked at nasa right and that that code is very, very expensive to develop, takes a long time to harden, and I just don't see that and they they use unit testing extensively.

A

So to think that we can do this without extensive unit testing, it really doesn't make sense to me. So here you can see. This is an example. Solidity project called the little flipper project, but inside here this is our test framework here and you'll see this integration. Test.Rs is really the engine that runs the integration test for you and you'll see here. This thing called testcontextbuilder.new with account my account u512.

A

What this is basically doing is it is creating an account in the global state so that when you build your session code, you build it with your address and your authorization keys, so you can run it, but there's other things you can do here. This just builds your initial global state with an account, but you can build your initial global state with other contracts.

A

You can build your initial global state with any other pre-population variables you want to use if you have a user interface for your smart contract and you want to make changes to your user interface. How do you know you're not going to introduce a bug there? That is then going to affect your on-chain code?

A

Well, you don't, but here you can put it all under continuous integration and every time the developer makes a change, you will have a set of assertions or tests that will run to validate that you're, not getting data into your smart contract. That would make it do bad things right, and this is an extremely powerful way to test this and to use computers to test your software. This is the only way you can scale out testing I've been testing code for almost 20 years.

A

I've been a professional quality assurance director and there really isn't any way to sustainably and scalably test your code uh with you know, without using computers to do it, you will lose competitive advantage in the marketplace right, so it's it's absolutely required. So this is another reason why I believe that we're going to have a play, a major role in d5 in the coming coming years.

A

I believe what we've built is extremely compelling and, more importantly, you can choose to build a very simple contract on casper labs and govern it in the way you wish. But more importantly, you can take that very simple contract and you can build on top of it and you can iterate and you can grow and you can make that functionality more complicated and more rich over time, because you can upgrade it.

A

You can test it and our testing framework and our system and our protocol will allow you and I'll give you the space to grow your your product to grow your smart contracts and to grow your business and grow your opportunity.

A

So um the last, but not least, and probably the most compelling reason why I think we're going to dominate the d5 space is in our protocol.

A

D5 contracts will also be able to stake the token that's locked within them, and uh this is uh hugely important because it enables d5 protocols to participate in consensus in a very meaningful way by deciding which validators they want to stake their token with it also enables them to participate in in rewards in a reward scheme like anyone else and provides higher yields. So this is the last and most uh compelling reason. Now we still have to make some changes to account and contract, but this is being scoped and planned as we speak.

A

We are becoming increasingly convinced that once we make this change that we'll be able to enable this- and so I think this provides all of this together- provides an extremely compelling reason why we believe that d5 is going to really thrive on casper labs.

A

So if you have questions about this, don't hesitate to hit me up on discord or on telegram and alex. If you want to take it over, you can talk a little bit about some of the things you want to bounce off the community.

B

Oh certainly, let me actually share my screen one second, okay. There we go all right so uh well. uh Well, you might want to zoom in a little bit uh so uh well. As a matter already mentioned, we are in the process of actually implementing uh our validator option system uh and in fact we are quite far along with it. Currently we are even implementing uh signage uh to go along with it, uh but uh there remain a few points, uh whereas there isn't really.

B

You know like peripheral points that relate to the system where there isn't really a firm decision. Yet right- and I have collected about three of these here and there might be others and I'll circulate this document internally, so that people cannot do it and comment on it. But uh the first most important thing is the adjustment of option slots right. So uh we have uh talked about it many times. So there is a you know there is a you know: speed security trade-off.

B

You want as many validators uh as you uh can for security, but you want as few validators as you can get away with for speed right and so basically you know over time, as presumably the platform is improved as hardware improves. We want to slowly let in more and more and more uh new validators right to increase. You know to take advantage of increased speed to also increase uh security, uh and ideally we don't want to do this. You know, let's see manually or through some sort of governance process.

B

We really want this to happen on chain. The chain should detect its own speed essentially and make a decision right so the well. There are a few major decisions here right, so the first one is basically, we want the number to only go up and sort of be optimistic and never exclude anyone who's already in or do you want it to go up and down? Perhaps you know with some: you know threshold right so, like you know, you couldn't go below 10 or something like that, but otherwise it would just float freely right.

B

So this is something that I believe meta actually favors. Only up. uh I mean I think I prefer up and down, but again, there's no firm decision on this uh and the other uh things that really needs to be decided here, and this is less amenable to public feedback. Unfortunately, is that we need some, you know we need to clarify exactly how we're going to measure the speed. uh I think uh it was mentioned some presentations that we have as a concept of validator exponents, which essentially indicate validator speed.

B

uh We have a notion, although very vague one of an optimal exponent right, the one that would actually like the system to operate at, uh but it's not entirely clear. You know how should we measure the speed right, because we first of all need to clarify exactly what we mean by the optimal exponent uh right uh we need to, uh and uh you know, and after we clarify that you need to determine the level given that definition, you know which exponents do we use to measure the speed you know like?

B

Do you use, as uh uh you know, the measured exponents with the validators in some way, do we rely on this uh optimal system? Exponent know how the system exponent actually determined.

B

So there are a few there's a whole number of design decisions there, although the big one that really probably needs public feedback is, like you know, do you only go up in the number of validators or do we allow to you know? Are we allowed to go up and down all right? So this is the first thing. uh The second thing is this tricky matter of slashing right. So uh well, slashing is what occurs when you know, obviously validator equivocates.

B

This is currently the only form of slash in the tv envision uh and what we envision is going to be a hundred percent uh slash, although you know I mean we will probably design it in the ways that you could. You know, specify some percentage of principle.

B

uh So well, here's the thing I mean this validator is slashing. Them is very easy. You know who the offender is you go and you you know. Basically they delete all of his tokens right. You delete the things that still remain in his stake or his bid. You know whatever he hasn't bonded.

B

That also goes away and that's the end of story right, there's no difficulty, but uh there is some difficulty with slashing delegators uh and the difficulty is that it's conceivable that uh you know if you're, not careful, you might slash an innocent delegate right so delegator, whose tokens probably never contributed uh to the weight of a validator who provocated at the time of uh equivocation.

B

So now there is an argument for, like you know, for basically also slashing all the associated delegators. He knows the ones that are still active once it turns on bond and queue uh you know, but on the basis uh you know, for you know what andreas actually said was you know?

B

Well, if you, you know, delegate your tokens, you vouch for their honesty right, that's fair enough, and if you do that, which I also favor, you know we would amply warn people that this is what it means that, if you're associated with a validator, then you know that the validator equivocates and you are still in the systems and all your tokens are also slashed right.

B

But uh you know in principle: you know if uh you know there is uh pushback to this right, and this is you know, with the public feedback part, uh you know we could probably design some sort of a system to at least you know, I mean avoid some of these cases right. I don't think that it's possible to entirely avoid this problem, but it's probably possible to design your way to a place where it's you know mitigated, although it's going to be fairly ugly internally right.

B

So this is the part where I need the public feedback. You know it's like the question is: is it fair to slash delegators for association with uh a validator? Now note note is that if you're not in like, for example, if you're delegating to multiple validators, only the tokens associated with offending validators get slashed, not all of your tokens right. So but that's uh so. This is the thing which we probably need.

B

Some feedback on uh and the final thing is, you know the if you've presented options to the public, and this is actually something that was a big surprise to me when renault told me about it, which is that well, it turns out that there is. Actually surprisingly, you know like not so much. You know negative perception with the word options, but, uh let's say somewhat uh ambivalent right, because some people associated with you know luck. You know it's associated with scarcity.

B

You know they're associated with like luxury options, uh and you know this is understandable, though it was personally surprising to me, because you know I mean you know, I'm an economist. So for me you know, auctions are things like cause they're like wholesale electricity options or their spectrum auctions or their timber auctions. You know like they're, all sorts of things in real life, which you know, options are used for. We use options all the time.

B

Every time you you know, search for something on google, you just ran an option because that's how the you know, positions with ads- and you know, selections ads that you see is determined right, but uh we recognize that. There's potential perception issues, so maybe we can, you know either improve our presentation or you know uh you know, maybe improve our terminology, so I think it would be useful to have some public feedback on this point as well and then, of course you know whatever other issues.

B

People may think up, uh you know, whereas they think we didn't design something with these options that we should have designed. But that's it for me for today.

A

That's great terrific yeah, so we should you know one of the things um we're going to be putting up a public blog here pretty soon so we'll be able to push push this all out on our website and have people interact with it. It would be great to get feedback from the community, at least by the blog, and we can figure out how we want to set up our proposal process.

A

I think the dev dow is ultimately going to be the arm that will help us set up our governance and and our uh proposal process over time. So this is great. Thank you so much so everyone, if you have questions hit us on telegram, hit me on discord and thanks a bunch for tuning in talk to you next week. Cheers bye.

B

Thank you, bye.