All Core Devs - Consensus #76

Transcript

[Music] so [Music] [Applause] [Music] so

so [Music] [Music] [Music] great welcome to the call stream stream

should be transferring over if you're on youtube give me a holler in the chat okay we have officially moved over to the ethereum pm repo which you've potentially noticed so the the merge calls moved over here a while ago the consensus layer calls are now there the e2o repo is deprecated and archived join me in ethereum pm the issue today is 4 18 this is call 76 making progress so we'll start today with kitsuki office hours thank you for those from the

execution there that have joined us then we'll do some other client updates any other discussion items and close it out let's see so i wanted to start with merge devnet zero which i believe is actually in progress perry can you give us an update here hey hey everyone um so yes merge.net zero was launched a couple hours ago we haven't hit total difficulty yet but um the consensus clients are merged ready they're on the mud fork um i have already

yeah so danny just shared the configs over there um expect things to still change because it's one of the first um merged nets we're trying and yeah otherwise you should be able to join i have a bunch of extra validators there's a non-zero deposit contract so once the merge is done you should be able to try the onboarding validators as well there is an explorer but there's an issue with the explorer currently and i'm trying to um to figure that out and i will link any other debugging tools in a bit that's about it

great and i think we'll probably get into this in the in the client updates the next section but i would presume things will we might have a successful transition hopefully uh but things might be a bit brutal with respect to the state of optimism seeing optimistic sink so if things fall out of lockstep um or people try to sink from genesis that might fail so especially if we don't have an ability to distinct from genesis post-transition transition we might not advertise to throw on validators from external parties but we still do have those 100 validators which yeah that would also fail but let's get into it client updates just general uh uh progress on on the um the kinsuki sprint how are things going

any issues you run into state of things who wants to kick us off i i quickly have a question for perry uh do you mind if we if i if i mine a bit during the transition uh yeah go ahead cool we're much ready so it should be no problem at all i'm like i'm going to i'm going to like mine past merge so ah okay yeah um feel free to create as much chaos as you want sweet okay cool i just linked the milestones

in there obviously a lot of y'all hanging out on that dock these days um does anybody want to give us some updates on where things stand just bring us all together yeah okay um i'm looking at the milestone document looks like a number of clients are hitting that m2 which means um we have have this devnet coming up and i expect a bunch of m3 this week uh any anything relevant people want to share no

no big deal if not we have things to talk about yeah so we finished uh so for lighthouse we finished implementing the uh on merge block consensus test this week mark's been working on m3 with a mix of implementations um it's been a bit slow getting all the different client configurations running but he's been making great progress lately um yeah paul's started finalizing some parts of the optimistic sync implementation uh this week and he's expecting to have something running late next week and so what is running is just lockstep so someone wouldn't be able to sync from genesis post transition on this devnet right yeah yeah that's right cool good to know

yeah i can go next so on the prism side um pretty similar to lighthouse um we have large step working with get what we're going to try and have in mind today and then mostly just focus 100 optimism just um it's pretty non-trivial changes and yeah i want to thank like paul lighthouse team and then uh and then um adrian thank you team they've been doing great um work on there so we've been just following along uh learning from their license and yeah thank you guys thank you for lovestar we have integrated both

together mine in ci so every commit we guarantee that we we can run m1 and the two and optimistic thing in our case it is would be not hard to implement um we already have a pr for that so it should be merged soon all right nimbus side we have the latest text we reach them two with get another mind but we are a little bit behind on optimistic thing hope to get there soon cool um from from taco um we are working in parallel on optimistic sync and also on the

all the consensus in the engine api is called because the the changes from around the merge interrupt was not uh was quite significant on our side so we are we are still working on everything to make some integration tests yet so we are a bit late got it anybody on the execution layer want to give us some updates i can i can start with the execution layer thank you uh so for us um we are

i created a branch um it's called beacon on top of uh 4399 which is the branch that should be used for the for the merge test net so if you want to join the merge test net uh from uh like like you want to run your own client to like verify everything and so on uh just use that um and we're trying to get the amphora specs into master um this is of course like it's it's not easy to get stuff into geth master because uh um yeah we have to be very careful

like not touching or not modifying uh current code um but yeah uh that should be done this week and the changes from m4 are already lined up and for 399 is already lined up so yeah look looking good on our side and what's the state of sync under um proof-of-stake paradigm um so the the beacon on top of 4399 branch i know i should have named it something different um that one has uh the normal sync till tdd and afterwards

now once it gets the signal from the from from the execution from the consensus layer it will uh jump into a reverse addressing so that's that's should be working okay hey so on another mine side we do have the first clients on the m2 so this is uh the lighthouse lotstar nimbus and uh we started verifying so there's the work on prism as mentioned before

so hopefully that will be resolved soon as well and uh we also thinking now of using the the merge mark and wrap like the whole thing together uh so i might be slightly wrong here marek malek is off today um but generally he's uh working with sarah for time on this uh so yeah they're progressing nicely and i'll be verifying this testnet that was launched from our side if everything looks promising it will continue with all the next steps thank you oh uh i

um mario from mario vega who recently joined the the foundation to work on testing has created a really nice test tool for execution layers and he he wrote a lot of really really nice tests that do things like reorg and and and stuff like this and one thing um that he actually uh noticed is that uh there's still some confusion about the timestamp and how much the execution layer should check the timestamp um because right now like i made a

mistake and we're currently accepting blocks with the same timestamp as the parent which like should never happen but yeah so i think it would be nice to have a bit of discussion around what uh what are the rules for the consensus layer for the execution layer regarding regarding the time step in the and execute payload [Music] okay we can talk about that a bit after um

override issues okay um light client you've also been working on testing tool this is different than mario's testing tool yes would you like to give us an update and where this might the two things might fit together yeah the testing tool that i'm working on is a little bit more focused on allowing people to write full feature tests in python where mario's is a little bit more about just executing these static tests have been generated by usually by hand i think

this is working pretty well right now because his tool is mainly supporting i think only engine api directives but maybe it also has blocks whereas this tool will not only support engine api directives but it will support defining transitions of blocks and so we'll be able to provide both of those but either way this is just like generating the fixtures and there will still be a runner that will execute them and merge mock is likely to be that runner but also what mario has could potentially be expanded to provide those to clients those packages fixtures got it

got it and are people is merge mock in a state in which people are currently using it anyone using it like client you know if anyone's using it i think nethermine was using it for a little bit but i think they were having some trouble because it doesn't support click i don't know if anyone else is wanting it to support click i could add it sorry which one was it i missed it merge mock are you guys still using ridgemonk so we're using it uh at the at interrupt

and only at the beginning we need that uh click i believe what you mean the domain does support click but you said the birthmark didn't support click but later we switched to to it was it maybe it was more about it yeah and i wanted i was just discussing it yesterday with like bringing three people to the table of getting merged mock because we wanted also to use the use it for testing a movie boost and wrapped undermined around the movie boost and launch everything together with merge mob so we'll be looking at it probably tomorrow nice okay yeah

message me if you have any issues or things that you guys are looking to add okay fantastic thank you okay any other updates on client software testing software before we talk about the ttd stuff okay um peter dropped into the discord chat the other day and let us know that the modifications in 3675 for the kinsuki sprint around ttd and

how ttd can be overridden on consensus layer without the execution layer knowing until they get a signal is kind of untenable with respect to how consensus rules are generally done in geth and likely in other execution layer clients instead of having some discrete value that triggered consensus changes across all branches at that value is essentially a signal 3675 required a essentially white listing a a branch as okay the consensus rules are different on this branch um with with the signal from fortress updated this was to attempt to minimize where overrides needed to happen but

likely induced too much complexity on the execution layer to handle that and would require a lot of custom logic to be able to do for changes on that type of branch logic so ttd is fine in that in that respect uh but mikhail has an issue up on the options on where overrides and how overrides might be done um if we do go back to both sides knowing it in lock step pick aisle do you want to discuss the options here yeah sure um so the options basically we may have no override option

like override settings which can be done via the command line interface so this is like a hard option and the implication of this of doing it this way is that we in case of emergency merge in case of when we will need to reset ttd or um like fork or make an upgrade of a particular block by specifying this hash which is the terminal block hash feature then we'll just have to make release of cl and dl clients and

um what what's the downside of this it may delay the our reaction by some hours because it may it it might be the case that releasing the new binary uh delays the upgrade of the nodes in the network and that's been confirmed by peter from from the comment in this issue um so right we might accept this you know delay and go with it right so we might need say 24 hours to release all clients and then

36 hours for everyone to upgrade rather than 36 or 48 hours just for everyone to upgrade if they had a command line and again i mean those those are aggressive timelines even even then i would say the ttd override generally would be to accelerate ttd because um hash power is falling off the network and so that is not like as as a timely of a concern but a tbh override would be because we're under very active attack and attempting to pick a block that has already happened to be the merge block so that timeliness is is of the essence there

right so ttd override is not that time sensitive as dbh or override um also bear in mind that even with this option it might be that a user up upgrades its cl client software but forgets to do this on the l side and we fall into inconsistency between these uh values um anyway so and we have to do something with that like one of the potential way to handle this case is to is el checking um checking these conditions uh per execute payload and choice updated and respond with the corresponding error

so if cl tries to to force the transition at the ttd which is not expected by l client it may respond with error and say that this is wrong um like this this transition is uh attempted to happen on the wrong ttd so i give up that's just to you know hate um investigating into this x kind of accident if it happens um the like okay so the next option is just to have the override settings in cli arg events for both uh cl and dl so it might worse doing it this way if we consider that tph

override uh which is time sensitive is can be like boosted can benefit from from this kind of way um from from the command line arguments um so otherwise uh yeah there is an option number three which i don't think is think viable because yeah the problem also one thing to consider one complexity to consider here if we have a tba terminal block hash override we will have to set the epoch the certain epoch when the transition to proof of stake takes over on the cl side so

everything can there was like a thought in the direction that execution layer may handle all of this transition stuff and consistently a client will just pull the state of transition and react accordingly but it appears that with this thermal block cache override option and it's not like it's not possible to be done by only el so it's not enough so cl should also have some options to to be over in so that that this is why you handle handling all this transition stuff by el doesn't seem viable

um in case if we have to have this terminal block hash and i think we really want to do to have this option so that's that's all regarding options and in my opinion it's just you know um also uh peter proposed to to have both options to have like of course we have command line arguments that override those settings also we would give users an option to either um use this overwritten sentence or wait for the release with the new values and update in their

software and i think if we give this option we will have to consider the worst case scenario in terms of time of updating uh the nodes so we will these options uh will not in this in this scenario these options will not buy us any um you know time boost so it will be just as uh in the worst case because uh in the worst case uh user will have to just wait for release and update their clients so yeah right in this case yeah okay i also think it's um even if we do have the manual overrides

in most scenarios i would presume that uh clients cut releases as well um yep just because that's kind of the simple path to modify the the configuration um okay do do people have particular opinions on option one or two to discuss here or do people want to take it to the issue i will note that these are exceptional cases that we won't see on the devnets in the next few weeks where the consensus layer and execution layer will

have the same tdd for the next three devnets so this does not really accept logic changes that we need to work through don't really affect the standard path opinions on overrides if not whoever shows up to that issue is going to have an impact in the next few days because we're going to work through the spec changes there

any questions about this anything that's not clear okay mikhail i i'd say that we prioritize in the next couple of days just getting the change on 36.75 uh done which essentially just the logic change of like you do know ttd um and then we can uh either add the client settings or subtract the client settings depending on discussions on this issue yeah right so it's basically to revert

one of the changes all right i mean yeah okay yeah it makes sense i mean it means that yes we will have like ttd is like the only trigger for for the transition on the other side and and the terminal block hash will also be like um will also mean that ttd has reset and the block cache and yeah there is a white listed block hash that we want to see on the proof of work branch that we have working off that we are upgrading that's how it's supposed to be

implemented cool thank you um other kinsuki discussion items for today how's our difficulty look perry on the devnet we're about 85 to 86 percent there okay so probably in the next half hour um and the intention is to do another devnet one week from today so um

we'll keep doing that through november great any other kenzugi related items perfect thank you moving on to consensus layer stuff um i know generally people had client updates if you have non merged non kinzugi related updates that you'd like to share go for it great

yeah maybe just maybe on lighthouse uh paul's still been working on the flashback stuff um i'll share with you all a link to a nice document he put together detailing the changes to the consensus clients that would be needed to support the flashback system the intention is to get a safe multi-client flashback solution for post-managing ethereum um yeah that document is quite thorough inviting everyone to take a look and provide feedback if you have some time michael's been working on the standard valley data client api we have an implementation and finalizing the details before we push it into review on our end and we also spent some time working on an edge case with fork choice and danny you've uh opened the spec issue i

believe yep yeah that's about it for us yeah thank you lion and michael sproul for managing the key manager api repo much appreciated yeah okay uh research spec etc we'll move on to that

uh there is an edge case identified um as an issue on the fork choice this is 2727 it's a pr this has been i think identified as something that smells funny by many in the past and finally when the lighthouse team brought this to my attention again at the beginning of this week or maybe the end of last week we did finally work through the problem and identify the bug and fortunately it's incredibly simplifying the justification should always be atomically updated with finality the exceptional case where it's not puts you in a

kind of irrecoverable state the only way to do so is if you slash one third or more so i don't this is not a uh an issue i expect to see in the next couple of months so we're going to clean it up in public and just get the get the release it out rolling that is we're going to get that merged in and then get the proposer boost rebased on top of this uh the current fork choice and get proposer boosting out next day next couple of days and get that released along with some additional merge transition test vectors and as discussed in previous calls

proposer boosts getting proposer boost out prior to the merge so getting it tested over the next couple of months and in in test nets and to be released prior to or at the merge is on the critical path check out 2727 if you're interested it will be in the next release other research spec or other related items to talk about today uh

i did put in the agenda at least i did a plug for pr 2649 which is historical batches we considered it for altair but decided there was not enough time to get it done properly there what those discussions led me to was basically that there exists a very much more simple way of introducing it so there's now a pr up that demonstrates what that very much one simple world would look like and it's basically just swapping a field not caring about any backfills or anything

just taking the feature um just taking the current code really and splitting it up into two fields it's it's not that much what's cool about it is that once we do that there's been talks about all kinds of archival nodes and offloading ethereum data off the peer-to-peer protocol and so on and this is really just a small step to towards that world where uh verifying data that comes from random sources on the internet it's important like becomes more important and with that patch we can do so very elegantly

so i kind of feel that the benefits are there and the effort is not so much so it might be a good idea to get this merged um as like before the merge as well i kind of like that idea because then the execution data is also covered by this simple way to verify blocks i think given where we're at in the state of the merge that that's and development progress and intentions on attempting to get releases done early next year i think that we should probably put this off for shanghai

um and if it is simple the only thing on the consensus layer for shanghai is withdrawals which is relatively complicated there's probably two operations and there's an accumulator and a new state for validators but this in addition to that i think would be very tractable with respect to the consensus layer updates i'm not saying it's not an option i'm saying that this one feels attractive now it's small enough but anyway if anybody else feels that it's a good idea to do now then feel free to put it in the ticket and then we can reopen the discussion otherwise we'll i

guess postpone it again um if you're actually speaking about uh you know storing um execution payloads in cl uh i kind of like this idea today if you are speaking also about this and this is something that i really would like to have um you know basically to reduce a lot of space in cl and actually the data belongs to el and we should not actually try to store that um you know i think that will make cl more simpler so this is two different issues

right yes yes and yeah it's two issues um they're a little bit related in the sense that um the first one sorry i'm talking about the first one yeah please go ahead now what i was going to say was that we need a solution to the duplicate storage problem but there's been a couple of approaches discussed there one would be like get rid of the duplicate storage by just storing a hash in the cl basically of that data

but it doesn't really matter i mean the way the spec is structured right now the cl data is a superset of the execution data no matter how you look at it so if you have the cl data you can always verify the execution data kind of if you trust the cl data right um so if we do the historical batches we can verify both cl and el data from the get go that's nice that said a separate issue is like where do we actually store the data and um currently both and and that's a bit sad as well

and there are ways to work this through and kyle has uh one proposal that i would actually have him present because i don't want to mess it up one proposal was that geth already has a way to fetch execution data from from the rpc api so we will basically promote that into an official api so to speak so that when cl's talk to each other they can get access to to the full data and feed it to their own els i mean there's there's a few design options there and i put it in the agenda that one today mainly so that people could take a

look at it i think it deserves a write-up and a discussion in an issue so i consider the current one just to preview right and so the one of the primary concerns here are not one of the primary things that uh cl needs to be able to handle is serving beacon blocks in their fullness um through um i think it's something like a five-month period as specified by the p2p spec and so the ability to prune right now consensus layer has to have

duplicate execution payloads for the execution layer on at least that range of blocks and we could which i don't know the size of that but that is just additional requirements in the node purely duplicate um yeah i just wanted to say that that's how the two that's how my two little proposals fit together as well like one makes the other easier to

one gives more options for for the other one basically how you deal with it it's just easier from client perspective to write good good user experience features when when that kind of verifiability is available i was just going to say that one of the ideas regarding querying payloads over engine api is that el clients already serving block bodies via eth protocol on the network so

we may like work off of this assumption so it's like basically um the pruning will prune transactions from execution pillow on sale side and this is what can be um like outsourced to the execution of a client of course there are implications of uh like um should it be like when this pruning should be done um but in general like this kind of stuff may plug in to the functionality that the l already has but it should be exposed on the on the engine api so that's the idea

that's the idea i have just written i thought about i would also say that like probably the current duplication it comes from the fact that it's just slightly easier to not have that complexity during the whole bootstrap cycle where you're doing the initial sync and the optimistic sync and so on and suddenly you have a lot of talking to do with the el in in

[Music] particular orders and so on i think that's why right now it's just duplicated because it's easier to do um but yeah that that's one solution for sure i'm not disagreeing here it feels like with the execution belt here you maybe strap the same process on the outside so um like bodies or transactions not necessary each time i don't know if it's beneficial in any way but just a thought gotcha

yeah so i i think that the path would be to take the ideas that are floating around and uh put a put on a concrete proposal on de-duplication and requisite methods to gather them back or if there are no no methods to gather the back justification on why but i don't think unless we change the p2p spec i don't think that we can do that okay other discussion points for today

so this relates a bit with the topic that was just discussed uh we had this question here that maybe it makes sense at some point to move deposit contracts logic back to uh not back but to to execution layer instead of the client layer was there consensus player was there a discussion for that um most discussions i've seen around modifications is essentially you still use the deposit contract but to shorten the eth1 voting and to even one block and if a bad vote

essentially comes in that that's an invalid block so that you can do very fast deposits but not have to change the logic what what are you proposing uh well my my main i would say not proposal but just an idea is as it feels that the deposit stuff could be handled in the execution layer instead of having this um extra part in the client layer so i was just wondering um you know maybe there was a discussion about that before that i missed handled the execution layer as in there's more of a native op code or way to elect rather

than sending into a contract yes yeah so yeah so basically i'm saying is th was there a general discussion to to handle this deposit uh thing at uh at execution layer which seems that it's a good place to be there um no no and i i i think the the the default is an attempt to not have to rewire that logic if it works just because there's 10 million other things on the docket but i haven't seen like a solid proposal to alter that logic in a simplification way

okay other atoms i have a question related to uh the pm repo i see the new agenda is in the ethereum pm and the old one is archived but unfortunately i do not find the folder where the notes for meeting 76 would go right i have not done that um

tim trent and i can figure out where to put things um i guess we'll make a new a new folder mirroring all core devs we'll just call it consensus layer meetings and drop them in there or the first person to make notes can do that as well um if you want to give them a just tell them do that uh so we have to uh take all the earlier notes uh from the consensus spec and the uh the 8th 2pm and bring it back here the entire folder think that that'd be that makes sense yeah if you all want a spirit that'd be awesome

okay and i see the message from tim that he'll be creating a new one so i will sync with him thank you perfect and anything else um yes uh just a comment on the crawlers uh a few weeks ago i mentioned the issue of um notewatch showing multiple four digests uh in their stats just after that the next day to release a batch in which they filter appears by the client version this is better

however i think this is still not enough because you could run a alter ready client in another testnet and so i think we're still seeing statistics that relate to multiple networks not only the mainnet so we have uh we have put a a pull request uh i'm sharing on the chat um to fix this issue so yeah just wanted to mention that nice i can knock on their door and make sure they're taking a look at it okay this is the past four hours cool thanks thank you and other items

um hello i'd like to check if we have some consensus about the codename of the merge upgrade like what like we had some offline discussion on discord and what do people think about like we can open an issue and call devs can propose some options and then we can maybe design the next course or do a pop vote the community vote something like that like the status we have right now with the idea to name it

a b star and pick my story i would vote for that right and paul had mentioned the name for calling things the merge um there's the merge fork there's the actual merge uh there are pr's to be merged it's actually kind of difficult to communicate and write about um so if we call the whole thing a meta name that might be useful tim we need names for the el ncl upgrades are we saying that we need two names are

we saying that we can call the whole thing one name the releases will have like a name i'm yeah i don't i don't really have a strong opinion at this point but uh because the the cl releases need to come first and whatnot so like yeah i i don't know if it helps or hinders clarity to have separate names on the ill or the cl just call it serenity serenity includes uh scalability upgrades i think we should have two separate names for eons hell but in terms of

updating the node client software it should be better probably one name certainly and yeah the uh the name on the execution layer is not so obvious when we've pretty much said that the fork after the merge is called shanghai so there's not a not a city to slot in there perry asked if someone can buy a star and name it the same as a city merging both the naming schemes uh yeah i think that's probably a good idea stardow star fork named dell

yes seems to be all the rage nowadays we can buy anything who do you buy stars from does somebody own them it's usually just random companies that claim to be naming authorities nice isn't it isn't it whoever discovers them can name them and basically yeah you influence how they name it probably well that's that they're like multiple competing people or entities that try to name things so yeah sure that's that's one thing that who's got the authority to actually know

bit of foundation yeah theory foundation should have a grand program for finding a star in the space to solve this difficult problem okay um there are there's a lot of a lot of interesting problems to tackle there anything else we'll close the meeting today okay

thank you everyone um i believe that we have an attempted kingsugi devnet go through the transition process very soon so we'll chat about it on discord as it happens care talk to y'all soon thank you bye-bye [Music] [Music]

[Music] [Music] [Music] so

[Music] [Applause] [Music] so

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

do [Music] [Music] do [Music] [Music]

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

[Applause] [Music] so

[Music] [Music] so [Music] [Music]

[Music] do [Music] [Music] so

[Music] [Music] [Music]

[Music] [Music] [Applause]

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] so

[Music] [Music] [Music]

so [Music] [Music] [Music] [Applause]

[Music] [Music]

[Music] [Music] so [Music]

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

[Music] [Music] [Music]

[Music] [Music] [Applause]

[Music] so

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

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

[Music] so [Music] [Music] [Music]

[Applause] [Music] so

so [Music] [Music] so [Music] [Music]

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

so [Music] [Music] [Music]

so [Music] [Music] [Applause]

[Music] so

so [Music] [Music] [Music]

[Music] [Music] [Music] so

[Music] so [Music]

[Music] [Music] [Applause]

[Music] [Music]

so [Music] [Music]

[Music] [Music] do [Music] [Music]

[Music] [Music] so [Music] [Music] [Music]

[Applause] [Music] [Music]

[Music] [Music] [Music]

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

[Music] so [Music] [Music] [Music]

[Applause] [Music] so

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

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

so [Music] [Music] so [Music]

[Music] [Music] [Applause]

[Music] so

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

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

so [Music] [Music] [Music]

[Music] [Music] [Applause]

[Music] so

[Music] so [Music] [Music] [Music]

[Music] do [Music] [Music]

[Music] so [Music] [Music] [Music]

you [Music] [Applause] [Music] so

so [Music] [Music] [Music] [Music]

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

[Music] so [Music] so [Music] [Music]

[Applause] [Music] so

so [Music] [Music] [Music] [Music]

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

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

[Applause] [Music] so

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

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

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

[Applause] [Music] so

[Music] so [Music] [Music] [Music]

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

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

[Applause] [Music] [Music]

[Music] [Music] [Music]

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

so [Music] [Music] [Music]

[Music] [Applause] [Music] so

[Music] [Music] [Music] so [Music] [Music]

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

[Music] so [Music] [Music] [Music]

so [Music] [Applause] [Music] so

[Music] [Music] [Music] so

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

[Music] so [Music] [Music]

[Music] [Music] [Music] [Applause]

[Music] so

so [Music] [Music] [Music]

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

so [Music] so [Music] [Music] [Music]

[Music] [Music] [Applause]

[Music] [Music]

[Music] [Music] you