All Core Devs - Consensus #19

Transcript

[Music] [Music]

[Music] [Music]

okay stream is being switched over here is the agenda in the chat sharing it with people on the internet they want to follow along people of the internet let me know when you could dress cool welcome everybody we had three weeks since the last one a lots going going down we just released new 0-7 the other day this is generally not a crazy like major semi major release but because it has breaking changes but it's not a major release it's just kind of iterative so that if you do if it helps

you follow along between now and the end of June to have something that you can like fight them to by all means but if you'd rather wait through the end of June do you think the the end of June release is gonna be and the subsequent minor fixes from there is gonna be probably what most people are targeting so this middle one is just for your use if you want it cool so we will get started with testing the b07 vectors are out we've our tests have become even more inefficient and the Python on

mainly due to the tree hashing so we're kind of exploring some some of the caching methods to speed that up but right now it's not a major blocker mainly just makes generating the tests for y'all take longer but that's a isolated one-time thing proto with what else we're going and testing you there Beretta okay there is an ongoing this no sir great planning to reconnect since the life ice flaky so about the state yeah we lost you broke

up yeah cool I will I messaged him outside Channel maybe we can reconnect I will update us but there's been much effort going on the fuzzing primarily the fuzzing of his go specification and getting some machinery in place to fuzz the Python spec implementation as well and do different suppose any things like that but proto will update us if he can reconnect I just I just already did the updates but oh no next event okay cool well proto if you if you will

give him one minute three connect see how that goes and everyone else get ready for my welcome back proto hey it's okay you go first some about something about the missing I just said it's ongoing but if you want to dig in please do okay so there's these two efforts you have the saying and we have coverage testing of trying to find new books and everything that's being missing in the current spec tests and so if this thing we primarily just go for more input books where's the like new

kind of inputs have to be checked so you had more conditions to this back there and then there's these rare occasions where there's actually something really funny happen happening but see trying to tackle this more fundamentally with just the unit testing and covers checking and it brings me to the second point Gophers checking really helps identify a few parts spec that are interested and I want to like complement that with new tests and let me get the three tests back yep and this passing effort right now is pretty isolated the two just implementations of the spec they go and

python but we hope to expand it to clients eventually very now as we did gets the tech spec reason useful if any spec looks cool any other testing updates testing related things one thing which might be is that Guido tried replacing 1956 with xx hash so exits hash is a non cryptographic hash function so we couldn't confuse it in production but it's much faster than sha-256 and what he found with zero at ease that it runs the fuzzing about three times faster so it might be worth

having some sort of a flag in the client implementations to switch over to xx hash so that we can just do three times more fuzzing cool thank you let's move on to client updates how about prismatic yeah hey guys so last time we've talked I mentioned that we aligned on blog process in epub process into zero point search so yesterday we just align that

with zero point seven as well we also reemployment caching the way we catch stuff with zero point seven just last time we had caching everything was zero point two so we had to read it a lot of a caching layer since the shuffling and the way we get meat is are different now I also did some benchmark for the station session with profiler and tracer and then I've done optimize a little bit on the blogging process inside the pins and at the end we're just working on test better alignment and Misha RSS these up-to-date yeah and that's it great thank you how about thirty so so for us so we also

just called 0.7 spanked implemented yesterday has all the test vectors so for us is is that way we decided to deliberately notes implement an equation right now before the package frozen test we don't want to redo any of the works and for next I think for Shatford workers right now it will get a more proper networking implementation I know what we have is really simple floats up which works but what we want to do probably in the really short term is to

reintroduce the chef stress subjects network library and you've said we get a pom for networking communication layer for our cancel lunch some new test nurse so this for us great thanks bye Congrats on the test vectors how about Artemis hey you all hear me yep okay good so we did a lot of profiling in optimizing on our state transition stuff so we like I guess when

we first merged in when we first merged in five one we noticed that at UH none of our optimizations and caching worked anymore so we profile that we implemented the caching were we're starting on the next on the next version of the spec the good news is also that like our our short-lived test X can one be much indefinitely on our white block network we have also broken out our validator client implementation kind of fall in line with the lead of the other clients you know how they made them discrete

from the beacon Ginny so that's good and oh yeah also Joe Wright wrote a pretty cool article about positive tree implementation and I should check out I think it's floating around somewhere on Twitter so a bunch of y'all might have already seen it and I think I think that's it much awesome exciting to hear about indefinite finality yeah the the article Joe just as Joe is figuring out how to handle the proofs coming in from the deposit contract and then handling them on the deccan chain

he just highlighted his thoughts so that other people can get to there faster oh the other thing we're also with harmony and and Raoul from protocol ABS on a minimal JVM implementation of Lib p2p and and then the other thing is that we released a bunch of bounties Joe loop and funded a bunch of bounties because everyone's like wicked busy um you know for a minimal kind of super simple network implementation so that we can test the kind of consensus layer and the kind of multi client a kind of test net

and you know and that hopefully will free teams up you know to continue the work on the real network stack and the testing that needs to be done there and I've spoken to a bunch of y'all on different channels and stuff but I still I still need to talk to I think Jace is really the last one so um yeah that's pretty much it cool thanks Johnny and thanks great how about Trinity right now and the update so recently Alex and stagnate

talking on the day transition update to version and 0.7 and we are using channel works in a factory our testing and implementation before the filters and is finalized and also Kevin it working on the it's fun deposit culture folder and we're going to use it to check the deposit country logs and is one chin that's it also which keep working on the discovery version five implementation

Bionic yes thank you nice thanks are y'all planning on using Trinity as the EP one monitor are you planning on using the eath one implementation of in Trinity as the monitoring or are you just writing it in web three to connect to whatever node currently I'm using work 3.5 right that makes sense cool cool thank you about lodestar pay up so in a branch we are passing the v-0 6 spec tests except for BLS

verification so we're still working through that it's kind of odd because we're passing the BLS spec tests like the ones for BLS specifically interesting we think it has to do with like this the what which private keys were being used I'm not really working on it particular Maron right there was a question about potentially the use of one as the private key yeah that's our best guess right now we've also the past few weeks we integrated gossip sub and implemented the RPC protocol as it exists in the

spec right now so now have a networking layer and we're also toying around with pulling out pieces of our code and rewriting them in assembly script which is a language that looks like time script but it compiles to azam and we're starting with LM with our LM d ghost just to try something out and get used to the tooling and our next steps we're working towards like kinda end shortly of test nets and we have a little bit refactoring to do to make our constants more swappable for test net

configuration and we also need to finish our synching module so you can sync between the network and the chain sounds good who's that a caiman oh yeah that's it cool three and nimbus yeah so regarding the spec we have to pay our spending for 0.7 compatibility and we still have to do more for now we sing the low-hanging fruits we have the

backward sync integrated so that means requesting all blocks up to a point is available on the networking side we have Libby 2p integration in numbers and we are currently working on releasing li p 2p based test net instead of our px that we were using so far and on so this is using the demon on the leap p2p library in pure name so right now we have an issue on mobile because when the mobile phone makes the application sleep it

kills the connection so that's one of the pending issue for the on the if one front we know have an API to watch the very date or contract the goal is to use Nimbus two for that and regarding if one security we have starting to do facing on discovery and fixing bugs on discovery and ROP for a phone implementation and we have an open question with all client we would like to have some data visualization of test

nets and maybe we should add to the interrupt a gender in September some kind of minimal IPC standards to request to clients like the block they are on how many things were processed so that we can have some kind of nice display of what's going on in multiplying test net agree antwuan does any of your work relevant to that the work that you've been doing on standardizing some of the metrics yeah what you just want to know I push this thing to if I am Marie posed

to you if we can't go they cook at the metrics I think they're mostly implemented by nobody at this point there's some good ideas from prism that I recycle to this some finback from the different commenters so feel free to take a look and and get inspired but there is no conformance to this that is required at this point so just if you know about that reports and there I am if - Dada - matrix commander hey guys um put together a really nice documents on the data API I just hosted the name so if you guys in he can do I think a lot

of the information will be there that was a prisoner was one of the we we knew that you had something for that our retrieval so if we can make it so that you don't have to re-implement everything that would be nice as well yeah I have a question about this why why make it an RPC when you know just every slot why don't we just dump it you know to a log file you have to kind of ways for the metrics Ivor you do push so that's what you said we push that to a

database or to a log file and then the consumer will retrieve that all the other way is pool so it requests you what's your state and you just reply in smoking water both are useful basically I don't know it really depends on the the problem with pole is that you have to be like in sync you know you have to know like hey every slot I better ask if I want like continuous data talking some of the like the big data like API consumers like amber data they they want both so having the ability to just kind

of have everything dumped and then to go in and ask for granular information is also valuable so okay let's add that to the spec then the ability to just dump it what do you think or the proposal yeah I think so just to chime in real quick here about the the document that Terrance linked this week I'm putting together a more like for more like the API design so this would have you know like batch request requesting things by slot like it's still a pull method but this supports data providers like Amber data or ether scan or anybody who wants to build some sort of read access consume data remotely you know without

having access to the file system so it supports that use case I'm not saying that we shouldn't do file file based logging but that's what this documents for yeah that actually that makes sense yeah so they can go back in history and be like I want slot you know 6 through 64 or something alright yeah so there's two different things here to what many was talking about is metrics like the kind of developer useful metrics for tracking how your how your system is performing and I think that's what Antoine has been working on too is for me easy stuff and then I think what Preston is talking about is more of like a it's more of like an API for the users of the application we've been thinking

of them as completely different things so the like metrics and logging like Manny was talking about the push or pull I think we've been like it's kind of rough we just leave it for the developers we add as we want and then we've been taking like we appreciate like Preston's approach with the the actual proper API where we you know we think about it and we don't add things that are useless and stuff like yes it is cool sorry guys yunsik here so I wanted to add a little note here that like every one of these services that we add two clients they represent first of all the security sort of surface area and also performance

surface area that we should be evaluating together with like against the utility that they bring so it's easy to like think that we should have like you know Bhushan poll and metrics and logs and and you know a bunch of historical services and everybody should support everything but realistically looking at it like the core functionality of the client remains to vote on blocks the rest is kind of nice to have fluff we're gonna hide our metrics behind a compiler flag the developer stuff yeah that's right but we will have to have an API otherwise it'll just be a black box also

you can also have these or easy for other people to come and build out other tooling using these API you don't necessary have to be included in all of our clients I very much agree I mean a lot of the stuff on the periphery even if it makes it into the specs we go like the validator you know the the general like validator request API that doesn't actually that's not actually part of consensus so like a client does not have to second what McAra says they're like we should really be focusing on building

blocks that others can use maybe for building services rather than trying to build services ourselves yeah yeah I mean you start to expose like data in some capacity yes Joseph clients should conform to some standard mommy were you were you done we can decide gherkin yeah that was the last thing harmony so we have completed our implementation and regular

scene and that's released beacon old version with a custom simple transport a car playing TCP and food sub so so we finally got several node in network which may enter edit and sync with each other so we are now up to date with with o63 spec version and passing all the compatibility tests so currently we are working stopped started work on adoption all the latest spec version

we started working on validated PC interface and also as Johnny mentioned we started to work on a minimum repeatedly GMM presentation lighthouse Hey so we're up to date with spec zero point six point three we're passing all the tests that we haven't raised issues about we've added some Prometheus stuff so we're running a test nets and looking at crafts about what's doing it's

ridiculously easy with the Prometheus and graph on it to get to get like a dashboard going so well them to prison for highlighting that one good lots of progress on dis v5 I think Aaron's testing it now not sure if he's complained we've been fuzzing with our own fastening tools and we found bugs and upstreams which is really good Kirk has been working on metallics optimized VLS signature scheme he's going well with that I believe we got the rest epi will will for the validators motion to master and wear stress testing test nets with one second block x and in trying to see see if we

can break it so we're finding bugs and we're fixing them so it's good how much working are you seeing and test out with one second five times ah not a whole lot because we're we're not adding network latency into it yet so we're saying a little bit but we're mostly just trying to test like if we can sink under really heavy loads but we're gonna add there's this really cool tool called Pumbaa PMBA which adds like Layton sees and it's basically a chaos monkey for docker setups I'm so we're gonna start applying that to our setups and then see see what falls over and see what stands up and so

I have a question so you're fuzzing tool is that specifically for lighthouse or are you gonna generalize it to that other one the one that we are using now is specific to lighthouse and it's kind of it's a it's like kind of part of our package manager system cargo we would consider making it let me rephrase that the reason we haven't made a generic is because there's already efforts on a generic buzzer so we figured that one will be useful and this one we're trying to keep keep it so it's I don't know it doesn't it's a bit easier to wrangle because it doesn't have to be generic but once once the they're like the one exists that everyone can use will

definitely be helping out with that one too I think many many is already part of that effort yeah this is a rough specific one and we're just targeting very specific functions inside and networking stuck in my house specifically but I don't imagine you can't target other functions in other clients cool thanks days and I rather do you know of any update on death Gus has been relatively quiet but I think two are figuring out what to do if mr. spanks but about saying things with the current

generalized forcing efforts is it's primarily like spec focus or consensus focused its first thing the state machine it doesn't first say your performance bottlenecks like storage or networking so it's like mitosis doing buildeth out in for your specific implementation for that part of the of your spec then we can share that consensus forcing right and I know Dean from Leith is planning on picking out back picking back up some work after spec trees hey Dean

cool let's move on next thing is research updates and there's like one on on the phase two friends so the mean update I have from my side is probably the SS head portion stuff that I did over the last couple of weeks so basically the I was finally managed to get the SSD partials implemented in Python and the mean realization I got out of that is that it's just way more

complex at present than it needs to be and the bulk of the complexity comes from the fact that Merkel proof likes in dynamically sized objects like lists or dynamically sides instead of the like and if you remove that property so if you come up with subway so that there is an exact kind of stable one-to-one correspondence between me and paths and I generalize that this is so if some particular object or some particular element if it is that object would always have the exact same sequence of moving left and right down the Merkle

tree to get to it then that would actually removed probably the bulk of the complexity from DSS had partial illumination so from realizing that there are some discussions that I had with dink rat and some other people and [Music] the proposal that we seem to be converging on is basically requiring a list we lost sheep italic but it's requiring list to have a max length so that you can always have them in the same

position entry he sounded out of breath I'm concerned all right I was just walking up stairs I'm up the stairs now oh cool well we can hear you again you said requiring lists you have a maximum length so basically like you basically think of it as being identical at the health types in the piper work we're in Viper like you could have a fixed length list that has n values or you could have a dynamic length list but if you haven't did it look like the list yesterday specify what the maximum length is and then the idea would be that as I said serialization would not change at all um except maybe at some point later in the future we might want to add another

sssaid serialization type for sparse lists but that's like not something we have to discuss today and but for SS Zed hashing the length of a Merkel branch would be AF x value so if for example your list had a maximum length of 20 then 20 gets around it up 32 I guess that's the next power of two so the length of a Merkel branch would always be five so there were just always be a thirty-two item tree yeah regardless of what the quote actual length of the list is and so that way the kind of morkul path needed to get to the say third item in the list will just

always be a gloss left right right left and it doesn't change depending on what what there and if currents add dynamic size of the less toast yep cool I just linked to the issue where this discussion is happening it's generally not a major change to the serialization but it's it's as I said a simplification on the yeah it's rehashing side and the being able to make proofs about things in the treehouse yeah the only thing this requires is that we'd have to run through the block and state data structure is that for every dynamical assess take a maximum on it for the block data structure in phase

zero there's no problem because we already have a natural maximum which is the constant for the maximum number of each objects type in a block the main the one thing in the state that's currently dynamic as the validator set and for the validator said look we just need to have something with a reasonably high maximum like something like through to the 40 and then we'll be okay for a really long time there's another the historic roots is unbounded apparently right roots we can also set that you're in the 40 if we want but is there any other I know we have maybe some phase

two researchers here's an update on that [Music] and so the thing I've been thinking about myself as just how to how abstract it fee markets would work and how like basically how the lot producers could collect years in the context of these different execution of our it's existing so the main design goal here it has just simplified the experience for a block reporter and make it so the block proposers can get a fair amount of revenue without having to personally understand 55 different sub protocols and so I came up with this idea where there would be a standard for

how execution environments pay fees and they would have issue receipts in a standardized format and then basically the execution environment will collect fees from transaction senders the execution environment would issue a receipt the execution environment would have an account at a standard execution environment that's what we call the fee market and block producers would be able to publish receipts and collect fees from there it will have a counterproposal where instead of using receipts you would use synchronous calls and this would involve this proposal of transit transaction base layer transactions being able to call other

base layer transactions inside of themselves so that's interesting too another thing I realized we need to start taking seriously as a kind of sub lot of l2 moving forward is light clients and what up and light client server markets like basically because everyone will be a light client in almost every ish shard like there's going to be heavy reliance on these nodes that have data associated with particular shards and that could provide merkel branches in exchange for payments through a payment channel and if you have that architecture then the light

client servers could also just be the real layers and these a transaction packaging really or markets but like the category of node that specializes in maintaining stage for a particular shard if something that I know needs to exist something we could Pro we probably want to start thinking about more and I know like some of the - developers like jolt spend some time thinking about this in the context of each one so it might make sense to interact more with them to yeah he's currently I don't know if it's public but he has he's working on a proposal for using channels and he's actually looking these and reading to find the light servers on these one yeah I can just give quick update from

Pegasus research the only thing is that the handle paper which is aggregation of the listing which is at large scale is now published on that archive and I've put the link in the chat it's a good read take a look great congratulations going back to phase two one of the things that I try to look at is basically what is the work that has to be done to make f1 execution engine and I guess there's this quite a bit of work to be done but the good news is that a

lot of it can be done incrementally you know some of it is stuff that we want to do anyway even if we don't go with a f1 execution engine and there's also nice intermediate stages that we can reach for example kind of a two-way peg between f1 and e2 which is a nice stepping-stone for a fully native f1 execution engine I guess one thing which might be worth sharing as well is that this seems to be rough consensus that we wouldn't want to launch phase 2 we've just within a without any execution

engine just just the basic logic the very thin layer instead we would want to go with a kind of more controlled launch where we have either f1 and as as an execution engine or and the new execution engine which has all the goodies that we've been looking into in researching for for the last few years I'll call that the if to execution engine or both at the same time um yeah 100% agreed on that like releasing it without anything I think would be silly for the community spec perspective um I'm even interested in potentially

launching with a restricted like you know there's only one or two execution engines at the beginning so that they can be we can work out the kinks rather than having a field day right and in addition to the consensus layer code I think there will be significant and the external infrastructure that needs to be built out and and tested like the fee market that Vitalik was talking about yeah my client servers are the big one I'm worried about right I mean we might also want to test like statelessness I guess the other update that I want to

talk about is about if to Genesis zero so basically one of the things that's been merged and recently is the removal of the if to Genesis log from the deposit contract and we've replaced it in a favor of a custom function which is kind of subjectively run client-side as it were which is both more secure because it allows us to better capture what we want to have as a trigger for the for the if to Genesis and also more flexible so there's basically a few requirements for Genesis we want to make

sure that there's sufficient if at stake you know right now we're thinking two million if but we also don't want to make sure that there's sufficient production level clients you know ideally three but you know if there's only two we we could even not with two so if we were to bake in a you know a a trigger in the deposit contract and for some reason we're not ready to launch then this gives us a flexibility to date the Genesis trigger I guess from a timing perspective I'd say we're still on track for the the phase zero spec freeze on on June 30th so that might be

you know a good opportunity idea at the end of this month to think about new realistic targets and I guess two good milestone to think about is one when we want to launch the deposit contract so the idea here is to try and launch the deposit contract ahead of you know the target Genesis so that we allow time for validators to make deposits and one idea here is to basically do a deposit contract ceremony at Def Con and one of the reasons of having this very public ceremony is so that we can all agree on the exact address of the deposit

contract and avoid scam deposit contracts I guess you know we still have quite a bit of time before the the end of 2019 so I think looking at a target Genesis date towards the end of 2019 could could be realistic one one thing that could work well is the the third of January 2020 so December holidays which are generally quieter and it's it would be the the 11th anniversary of the of the Bitcoin Genesis and that would give

us if assuming that we do the deposit contract ceremony at Def Con that would allow for three months for deposits to accumulate to reach two million if and it will allow for seven months from today for at least two clients to reach production status you mention production status have you thought of criteria for what that means well I guess at the very least that we have a a long running cross client s net which has gone through security or debt that's gone through fuzzing parts of

which have gone through the form of a vacation and potentially you know has hasn't suffered major major issues for a healthy amount of time same same as what we had any one long-running testing at some period of time with no bugs and security auditing on all the clients all right I think that would be good to write down in some post somewhere so that we have some clear criteria and it at least it would be useful for us

client developers as well mm-hmm agree and the I think that launching the deposit contract we should at least have some some target for going to production because otherwise you know we're asking people to put their money into a contract at least if if they do it early for sentence an indefinite amount of time which if we do ask them to put their money in for an end up in amount of time people might not actually show up and might not have a good read on the participation levels that we expect I have another meeting I need to get into so I will say goodbye here but

I do like the idea of the kind of ceremony or the public public nature of making that deposit contract because I'm slightly concerned about scam addresses too um I I had a quick question about the deposit contract so I'm assuming that the changes that you're talking about now are placing the log with the function for each to genesis is that like kind of a make grasping that correctly yes so essentially instead of listening for that log you're running a function locally when you get a new deposit on whether it's time to start it oh okay it's it's a it's a call rather

than a ascend it's gonna be it's gonna be like a some sort of a not a gonna be a like just I'm not gonna execute it's not gonna require gas for execution it's gonna happen no not even not even in the deposit contract so I'm receiving the blog's locally and I have local logic on whether to run whether to start the Genesis okay so I can fail I got it yeah simply I could be like have there been a hundred deposits great I'm gonna start but we can make the logic more sophisticated we can make it have there been a hundred deposits have there been 90 full deposits and is it the state yet so we can just we can more manage it

locally and we can be a little more dynamic with it if you know if we need to postpone things or whatever so we don't we're not beholding to whatever ends up being in that contract I think it ultimately it's a little bit it's just mildly simpler and more flexible yeah we do lose one aspect that we use the aspect of kind of having a shared source of truth for this e to Genesis root for the deposits we lose that but right so but it would be yeah it would that would need to be part of the local calculation as well right like whatever deposit triggered it would also be need to be the state of the contract at that time in terms of the route yes I

do you don't want to make it an actual function on the smart contract so you have the flexibility to change it is that way and we can have more sophisticated logic right now like the calculation of full deposit is doesn't take into account if people send in partial deposits so like if I sent in 16 and then 16 it doesn't count as a full deposit but you could count that locally so you could do a little bit more sophisticated things as well but Justin yeah yeah I mean that was the initial trigger where we realized that people could make just one deposit the minimum and make a bunch of these and then trigger the genesis and sorry attack was that someone makes 32 Eve

deposits or for deposits to the same address repeatedly and then they triggered the the the Genesis basically with a huge asymmetry in in the distribution and then potentially they could withdraw this one address and use that shared source of truth argument is a little bit of an illusion and the reason is that we we need an alternative backup mechanism without a preset kind of source of truth if we if we don't

reach it so if the contract says yes go ahead and we're not ready right on yeah that that makes sense but I do I wonder why then we would calculate the sparks Merkle tree in the contract because essentially that the sparse Merkle tree is useless if we're not never immediate emitting any to genesis value right sorry it's still valuable so the response mccottry for the deposit basically allows for the

the accounting of the deposits and making sure that it's properly reflected right so when you're voting you can still call that mechanism you also but most people will be handling a tree locally so it's a helper it ends up being a helper accessor it gives you a little bit more flexibility like in case say you started running this a year from now as a validator you might use that mechanism and actually have just a more sparse view of the deposits locally instead of having the entire tree so it does it does provide some optionality but you're right it's not a hundred percent necessary anyway yeah I think it

would be great if we could if we could expose get deposit as a public method and that would be no kind of like I'll allow people to you is it private I'm honestly surprised by that I'm not sure actually it may be I believe you but I just it should be public yeah I just take this public ok cool then I guess yeah not emitting you know that is perfectly fine that I think cool any more research updates before move on

we got a quick update there are some good conversations about what a token is going to look like on execution environment Smith 2 at scaling aetherium and still thinking about different ideas there but I wanted to share an idea huh I didn't get some feedback on it it's about removing the need for like two transaction flows for ERC 20s so like the basic idea is like extending message value to support arbitrary tokens and so I've kind of like a ridden up like a short summary here Annie's magicians clothes that I'm going to share cool do you want to tell us more about

an hour do you maybe we'll give you some feedback after the call yeah I can tell it more about it now basically like the idea like I had is that essentially like sending a transaction to any kind of contract since it's already like signed by you or by your contract wallets like you're essentially giving permission to like Cinetopia it's just that right now there's there's not an ability of saying that you want to also send like some VR seats one here some like token other than ether in one transaction it has to be split in two like notifying the token contract and so if we can extend it to where message dog value is some token

contract address in some amount of tokens then we can add like some GI function or opcode essentially that like doesn't delegate call to the token contract assuming it supports like some generic interface that supports transfers and so the message I send her after through that delegate ball will still be the message does sender to the target contract with the user once and so then it can verify that that user wants to send token to that contract and help me understand this is functionality that could be defined in the context of an EU and not protocol would yeah so I mean like the message of value that's gonna be kind of like an ee concept

since it's not going to be like it's not going to live I think at the protocol layer and so if we can just extend that in that context to be an address and a value then as long as that the transaction is introvert and the contract was able to continue executing after it like kind of consumes that value then the carga contract can assume that it was like it had the valid transfer in it now it owns the tokens interesting any feedback on that guys okay take it to thier magicians the link

was shared it is cool because it does it just highlights the kind of extensibility and things that we can play with and execution buttons okay any other research updates before I move on great moving on the networking Felix did say sorry you could not join he has some discovery b5 updates the government ation is progressing still missing integration for the topic stuff but the basic DHT works implement a implementation and Trinity and lighthouse is ongoing rust version is pretty far along

minor spec changes TBD and he is currently negotiating an external protocol audit we have yeah we have Mike here yeah hey yeah it's Mike from would be to be um Raul couldn't make it today he's traveling so I don't think he's on I don't think he's on the call but um yeah actually we have a few quick updates um the last call we did it like three weeks ago you know a bunch of people on the call kinda gave us feedback about let me like some you know production readiness of the implementations that the daemon wasn't a good enough test environments

and so some really useful feedback and we've tried to take action on a lot of those things that came up so here's sort of what's going on as far as the JVM the p2p I think Johnny covered it like there's there's nothing else I really have to add beyond what he said at the beginning of the call well actually I had one thing web 3 lab which is also I don't know if Connor anyone is on this caller attends but they're looking to get involved too so we may get more firepower on on the implementation but even without that it seems to be progressing pretty well on the production readiness for

live p2p we followed up with with the chain safe um specifically folks who had worked odd on the on jail it worked with the Jas live p2p and knew kind of what its flaws and warts work and we're looking at making a grant to kind of fix up some of those things a lot of them are just documentation issues so working on that we now have a full-time writer on us working on specifications for Lupita P so I know that's been a week a weak spot and then everyone who tries to implement it is like what you know how can i implement this with that proper

specification and so we have a we now have a writer who's working on that full-time and he'll continue indefinitely or you know until it's complete what else is it gonna toss out there oh there was a some benchmarking at the scaling etherium event in Toronto were we're working with white block to try to figure out basically to try to iterate on those tests it it's really good a good kind of initial work had done but we think that some of the test results are might be measuring artifacts

of the set up more than the gossips of proto itself so we're kind of working with them to figure out how to improve that and those are all the bullets ahead on my list yeah thanks like there any questions for Mike and I we have there's a telegram channel that we're my controller in where it seems like it's been a good place to at least ask some of the little questions so they can direct you better so please utilize that but yeah any questions for Mike Feuer one yeah I had one I was thinking about

transports and there's been this loose plan to sort of move on from from say Kyoto to may be TLS any thoughts on that or any progress updates yeah it is their intention to move on from SEC I owe to TLS it the status of TLS berries with implementations I mean whether it's complete or not various its implementation so like we have a working TLS 1.3 in the Jo Lukie to be implementation I do not believe we have one in Jas I mean I could go through all the languages but

but the point is not all of them have it and so we're gonna be falling back on psych I hope for quite a while like when two clients connect if one of them only supports that guy oh then they'll have to fall back to that so yeah that's kind of the state of it is that is this is helping address the question or you're looking for something more specific well there's two two aspects to that question right one is like is it finalized how Lippe to be over TLS should look like from from let's say from spec perspective or from a functionality perspective and then obviously you know clients the question there would be do

they have something to implement and the final question is like are there any concerns that would prevent TLS from becoming the defect so transport for Libby to be ones implementations of Cara okay yeah I understand so I'm not a TLS expert but as I'm gonna kind of go in reverse order on your last question I am NOT a tellus expert but our our expert margin from talking to him as far as I know there there's no reason why we would not

eventually go 100% TLS once implementations are caught up we don't know of any theoretical reason not to do that then then kind of winding back through through your earlier questions I started remind me this the second one the middle one so so the second middle one are kind of the same but like from a client from an implementation perspective is this fix is there oh like you're writing right but is it stable like have you decided on what you actually want like yeah I think we're happy with the go implementation and we

want to turn that into a spec that's my I can follow up with Martin seaman who's the RTOS expert and he implemented that I can double check on that but as far as I know like he thinks where we've reached a point where we're satisfied there are a few there's a few issues the rust rust LS which is like rusts main TLS library doesn't support self-signed certificates which we would like to use in some cases so there there are still some some open questions so I guess the true answer to your question is no we're

not fully certain but I think we're extremely close okay because it seems to mean it like that especially javascript like should have the TLS part of TLS done sort of so I wonder how much isn't there somebody working on a TLS implementation condone Jas yeah curious like how much of the TLS Libby to be stuff is written in is easily be Toby's responsibility and how much is offloaded onto you know standardized libraries in environments maybe to his responsibility but he does

have like service vacation for the future people to have a breakfast bar invitation right now I don't know if they say there's gonna be a job one yeah I think what my curious thing is right so it's not our intention to re-implement TLS on in every language we're mostly relying on language standard libraries so you know whether it's go or the node one for Jas yeah okay cool yeah Mike if you can just talk

to your guy and get some clarifications and the details that be just off you sure yeah I'll do that I'll come back next week and and yeah for two weeks great all right thank you everyone seemed like a stupid question but what's the technical reason behind implementing TLS or requiring at all oh that's a good question basically we so we want to support something that is an industry standard and that TLS is the standard um SEC IO is like something that we wrote on our own we do that we are gonna have a

security audit of it done and the people who wrote it are quite knowledgeable about cryptography but we think that for a lot of use cases it may be safer to support TLS 1.3 we couldn't use TLS in the past because prior to version 1.3 TLS didn't have basically it required you to have a notion of a server and a client like you had to designate one side as the server and another as a client that doesn't make sense in period of here 1.3 finally gives us a way to to not make that distinction so but anyway because 1.3 is something

that's recent like this year we didn't when we were first developing Limpy 2p we couldn't use the older versions of T lesson so that's where sec io came from but is that if payloads are inherently cryptographically secured from the application layer what's the point in providing additional encryption on the wire oh I see what you're saying well okay good point it's so it's not mandatory you can use unencrypted transports so if you're doing encryption at the application layer then you could use an unencrypted transport so in which use case would I require or want a an

encrypted wire in terms of e to I I think this question is out of my expertise so I don't have a good answer for it I think maybe we could follow up with with Raul next week okay okay sorry sorry I'm not I some of these things are beyond the scope of my knowledge I don't want to tell you the wrong thing I don't know where's the one reason that we often want to use it is because some networks they simply do packet filtering on anything which they don't recognize this for example you know HTTP and HTTPS traffic so those might be reasons hmm

yeah the the RPC protocol that we're using and gossip sub don't have their own encryption built in as far as I know of so if we have encryption on the transport it covers both of those right but you're just relaying messages through the network and those messages should be encrypted already at the application layer before they even hit the wire so for example if I'm sending a block to somebody through the RPC I'm not actually encrypting that block there's no key to encrypt that but why would it need to be encrypted if the payload is Merkle contains miracle proofs and it's cryptographic in nature and here well that's cryptographic doesn't mean encrypted right so like I can if I see a

Merkel branch I know I can figure out maybe what that Merkel branch is because it's related to a block but adding encryption at the network layer prevents people now just to be clear we have no encryption at the application layer at the moment okay yeah yeah that's the privacy right getting past firewalls getting past anything that inspects packets whether that's your employer or whoever that might be I think it's just a normal precaution nowadays like you even access Wikipedia through HTTP right sure okay

yeah I'm just that's really within the scope of what we're trying to do to like roll out and then BP kids I feel like those additional primitives kind of the staff we have right now well I think that's part of the value proposition of Lippe tube itself the fact that we can support multiple transport and select a suite of transports that we launched with but but also you know I have the capability to move on to or really even support multiple travel at once yeah

well why not just use wire dirt what do you mean exact what is Farber whenever VPN tunnel it's just an open source yeah where what's it like VPN to where like which well between point-to-point between two separate points so I'm not sure I understand in here I mean I mean oh yeah I think it makes sense to have the capability to support encryption of the way we don't encrypt at the application there and it

we nor should we necessarily look into encrypting at the application there so having this an option is good thing Zack do you want to give us any update on what you can okay we wrapped up the additional our initial p2p gossip subtests we just had a call with Mike and Raul and vaso I think it was like a couple days ago so we're just currently in the process of like designing an actual test phase like the next test phases with them I'm drafting something this week and I'll post it up on github

and I would like any feedback from the community in designing these tests and ensuring that the topology is correct based on you know the consensus of the community and yeah that's pretty much where we're at we're rewriting the client to remove the daemon our test client and we started we started working on a discovery v5 implementation and C++ so we can perform similar tests and analysis on discovery v5 we're doing that concurrently each of you teams seems like you'll have at least like the

one networking guy when Zach does post the next plan for tests I'd love if you if you all could take a look before the test implemented another thing that we kind of may need to discuss at some point and this is going to kind of help us move toward multi-client is like the way that key stores are implemented and like how those key pairs are generated like they're using like pls like if we can standardize how the keys are stored it doesn't really matter like how we do it right now in my opinion it just matters for the sake of interoperability and using easy testing that all the clients implement the same

kind of function so we don't have to write individual logic for each specific client like in prism that they use the keystore from gas but we can really kind of just use like a flat Jason file we don't really need anything fancy it's just if we can kind of standardize across clients how that process occurs then it'll be much easier for like testing in future like Interop efforts yeah I'd throw in their key storage is very very platform specific a lot of platforms offer he stores that are supported by hardware which typically

you want at least like just might mean some kind of standardized import exports you would maybe does that make sense yeah it doesn't I don't in my opinion I don't think that it's like super important how we do it it's just what's more important at this stage is just that we can kind of agree and standardize some sort of implementation however basic it doesn't need to be necessarily for production purposes but at least for like these initial R&D and like testing phases that would be a lot easier me and Antoine had a discussion about this and there's kind of like a

lot of is a big it's kind of a pain and like a roadblock for us moving forward and implementing these testing phases yeah yeah so we saw that perceived to tester that maybe this much that you can definitely have one client generate all the validator contract and all the accounts and all that stuff into files that can be read again but it needs to be compliant between the different clients if you want to move a little faster and interrupt otherwise every client its own snowflakes and we're gonna have to just report also different stations of Kyel the different ways the

key stores could be created so if if we can standardize this which is probably easier and standardizing most of the networking or interrupt the clients at that level that would be a good first step yeah yeah I think I I think the import/export would serve that yeah so whatever that is we should just define we should just specify like right aspect that says look this is what we should do you know we can own that oh and we'll implement that and all the clients I mean we just we just need to agree and specify what its gonna look like just because it would be much easier well agreed um

let's move on from networking to we have about 10 minutes left spec discussion I did want to survey how people are thinking about and searching for attestation slashings Jim and I were talking about that and I know that some of you have dug into it so if someone wants to just kind of give us Leyland as they see it that might help well we had it on like yesterday me and I'm prime and we came to the conclusion that like think about it from a client

perspective that just adds complexity and and so on there's no real obligation from a protocol point of view to perform slashings to look for them it almost outsourced that like a third party yeah yeah difficulty lies in the fact that we can't really write conformance tests for it right you can't mandate that people find opportunities for smashings I think because the problem is difficult so you can go with your a sticks and hope for a little right but I don't know yeah yeah we are what still came to do some

slashing even though it's like a bit of a funny thing where you don't necessarily need it in order to work I know Michael put some effort into it when we were doing operations pull so you know trying to fill up blocks with attestations and then you know meeting these edge cases of like oh if we find slashing attestations do we include one of them to include both of them none of them I think he found that it was like np-hard in the worst case or something to sort this out one do you think when you were optimizing for profitability I know that was the acquisition aggregation about gone yeah so that that's kind of like a little little tangental it's it's kind

of like we discovered that as a result of dealing with the operations pull we haven't put a whole lot of effort into detecting slashings I'm not sure we have a full strategy for it we definitely don't actually I part of me is thinking about moving into a separate process but I'm also not sure whether that really should just just so that it's not going to chew up capacity that's needed to just to maintain consensus but I'm not sure that that's actually just more complexity in the long run its kind of my my thoughts at the moment yeah I definitely you and it should definitely be some sort of like at least asynchronous or back my background job

whether it's a song processor or not just because it could you you could probably spend all of your time searching for them so you should probably relegate some portion of time rather than all of it I recently was thinking about how acquisitions generally our view become our view of the block tree and what we want to even consider narrow is every time we have finality which is a good thing but in doing so if we receive an access ation for something that's outside of our block tree or maybe for something in the past

we might not have the we may or may not have the requisite data even calculate see if the attestation is valid and see if it like who is even a part of that Association so say it was from 20 PAC's ago and we finalized and we've like prune things we don't necessarily have the state to go and you can verify the such a station so then and that under that consideration even if it was flashable we might just like discard the abbe station and under that consideration it's probably fine in general because we finalize things but it does limit our ability to find Mewsette for these things so it's not a

fully complete thought because I was I haven't fully thought the but something I think about a little bit yeah it sounds like that's a dos vector for slashes in the in what sense I guess if you just if you just pump out all these old like things that look like slashings yeah then you can lower just a positions for things that are like from old portions of the block tree you know if if we're required to see if they are slash herbal or it's worthwhile to see if they're slash bull then you write it like makes you pull up all sorts of like old states and stuff to verify against which is probably not a good thing yeah

if we wanted to try and incentivize clients to implement slashing one way to do it might be when we released these test notes is to make a bunch of open-source tools that allow it allow people to very easily create malicious blocks and like I'm not sure whether we want a fully open source or give them to specific people but like add the ability for people to cause chaos and then once basically if if your client doesn't support it then you fall off line maybe maybe that's the way we incentivize people it's not really protocol level it's something and something we do we do want to have test nets in which like 50 percent validators go offline and we go through an activity leak and during

those times when I guess your block tree becomes relatively large with respect to your latest violence and those are the times that you'd be most concerned about people you know going back to epochs and signing something new and and attempting to to mess with things so like we should definitely create these scenarios I'd also be interested a little bit in thinking about or really hearing thoughts on slashing protection and they've been talk of clients stashing away you know data in order to ensure that they don't accidentally cause a slash shovel condition for for their

validator and what would be others like how much extra data do we have to store because of that saying that we voted for for a branch that later became unavailable so that so that clients don't create a slash shovel condition by accident because they've forgotten about it stuff like this so the requisite data held is actually can be very narrow pretty much if you remember your latest attestation this is not optimal and in terms of the optionality given but if you remember

your latest set to station you can pretty much always just not vote on something that is from the past at all I need to consider whether that covers all the scenarios all I can add a little bit more to the validator guide him like what's the minimal that you think yeah that was my understanding tool if you like if you as long as you never vote in the future there's always this case where you can choose to just skip a couple of duties and then you're safe

again by that but that but if you do if you have if your clock screws up and you vote in the future you got to wait until that until you say yeah the only case in which that's not true is if your say your your node for so you generally are going to follow the latest justified but if your node sometimes forgets the latest justified and points to a previous justified and wants to a new vork then you could at you could end up doing us around yeah that makes sense so

that's the that particular case and how to prevent that is probably the most that's just a problem the corner case that I'd be concerned about so I'll think about a little bit more out these cool cool yeah slashing is hard but something that we literally cannot launch without so whether it is baked into clients or whether we have some sort of other processes running we as a group need to solve this problem cool

open spec discussion anything people want to have questions about or when I discuss before we close with a couple minutes left great open discussion closing remarks anything not related is back good that you want to say Joseph do you want to give us an update on what you've been working on the interoperative yeah so we got a place and we got the contract sign

it's a place in turn I remember the name it's in north of tehran I've called Muskoka it'll fit like probably 25 people comfortably in like 35 people like really uncomfortably and yeah so September 6 through 13 and yeah are you reining in maintaining any sort of like RSVP so we can get a handle on yeah that's that's forthcoming I'm sorry but I just wanted to make sure that we had the place kind of nailed down before I did that sort of stuff and kind of we iterated through a few different locations because some of them I didn't think they were ideal and so yeah we

settled on this one and so a suit like as soon as we have kind of like the check cut to that place I'll definitely send out RSVPs it's difficult to send because it's kind of like we want eat like typically like in the terms of like only did the workshop before you just kind of advertise it this is going to be have to be different you know we have to kind of like restrict it to basically implementers and researchers though only so if somebody has a good email list of kind of like the e2 implementation teams that would be awesome because then we can send it out that way okay cool I'll get with you

Thanks mm-hmm yeah thanks for organizing things okay we are at an hour and a half any final remarks for close just a reminder that the publication it's opened couple presentations and everyone if you want to stay in speaking and please yep thank you okay cool we're closing thank you everyone their abductor meeting will keep things

going on the spec towards the spec freeze and keep up the great work talk to you all soon thank you thanks guys see you everyone thank you [Music] [Music]

[Music] [Music]

[Music] [Music]

[Music] [Music] [Music] [Music]

[Music] [Music]

[Music] [Music]

[Music] [Music]