EIP Editing Office Hour #77 (EIP + ERC)

Transcript

[music] Heat. Heat. [music] >> [music] >> What's up?

Thank you. [music] >> Heat. Heat.

[music] Heat. >> Heat up here.

>> Heat. Heat. Heat. Heat. >> Welcome to EIP editing office hour. This

is meeting number 77 and in this meeting we are going to include EIP plus ERC pull requests. We are joined by editor Victor and he's going to go through the proposals. We are also joined by a few authors who have their proposal listed for agenda today. So Victor welcome and perhaps we can begin with the first PR which is 1158 on ERC repository. Um we have the author joined by that and let's try to answer the questions of the authors first.

>> Okay. Uh this is a ERC20 prince initiate uh initialization extension with uh Sentinel uh storage and I think the intention was to uh include it merge as a draft. Uh let me double check >> that's correct and we are joined by the author German in case you have any question for him or if you want to quickly check anything. >> Hi German, thanks for coming. Hello. Thanks for taking time to review my proposal.

>> Yes. So, um, pre n option function. Okay, let's take a look at what this function is. It's a pre-initialized address. And what is the implementation? What is the reason for that? Uh, okay. Oh, that's an interesting idea. Which means you can preload some of the storage and save a lot of gas.

Nice. And even including the recommendation implementation. Uh, look pretty neat. Let me quickly take a look at the at the specializ specification. This is uh must store balance as mapping address to bind by 32. Okay. Provide a public external function. I I also provided a solidity code already working and made tests with onchain transactions to prove it. And also I provided a calculator to estimate

in real time how how much are you going to h to save in gas and all these links are in the mach post. >> Okay. Nice. I am a big fan of providing reference implementation. Okay, let's take a look at this with what user is for. Okay, it gives user some kind of a magic number.

It's a magic value. >> Number is a is a string. This is very important because for safety and and accountant redundancy we can't use numbers because if not we will have problems if we use one or a high number with a the accountant of the token will be break broken. So it's a it's not a number it's a string that that is the the the the hacky the tricky part here is storing as bytes but representing as you for the interfaces. So it's a standard the the the wallet and the users shouldn't do anything new. Uh just this an internal uh procedure.

>> I see. Cool. Um let me see. So this user will be assigned for a magic number. And what's the relationship between in this particular implementation? What's the relationship between balance by 32 and allowance? Let me see. The the implementation in general is the same. The thing here is that we are pre-initial pre-initializing with a bytes. It's not a magic number. It's it's a bytes. Uh so it's a string. Uh and this is not interpreted never by a

number. That's why this couldn't have a problem with the representation on the accountant of the of the token in general with the balance general balance and issuance and neither with the users balance because this this h string is handled as zero because it's zero on number representation a string but in the interfaces nothing changes. So in the interfaces to know the balance of a user to do transfers or whatever else or mint it goes to a number because a byte 32 can have a number inside and this will work as the same than is if it was a u

int. So the if we in pre-initialize with a zero value we are not saving anything because zero to non zero cost the full gas. So when we pre-initialize with bytes the bytes to a number cost a quarter part of gas because you already have data there and you are just reutilizing the slot. the SS storage will take like 5,000 units of gas in place of 20,000 units. And in the >> in the implementation in Ethereum machines, I I also wrote and publish a calculator uh that you can use to check all these things like

>> calculator. Can you share the calculator? >> The magicians are also magicians. Okay. magicians. Uh there is I can uh should I reshare the link? >> Oh, let me see. This is the ETH position, right? >> Yes, it is. Also, there is some discretion for a user that ask from some security concerns that were answered. Mhm.

>> Would you be worried about overflow data overflow? >> No. No. There will be no no chance in this case. >> So let's say we happen to have a magic number that is that is very large ined by by the implementation. It's not by the user. Yeah. Yeah. Yeah. This is generate. This is uh implement implementation specific, right? I know this is implementation specific. But what I wonder is let's say someone got

initialized with a big number. And then by the way, you're only initializing one user, right? From the interface. I see this function was called with only one user, right? >> For each user. Yes. In the line 19 you have where the the magic value >> yes >> is created and then you use it for every user for every user that wants to pre-initialize they call >> for every user. Okay. So for every user which means if a user let's say I haven't been the ERC20 let's say your token is called German

token [laughter] and uh it's a ERC 803 compliant cont token contract uh and German your your own account already has been [snorts] Now I like I'm a new person. You want to interact with me. You want to transfer a some token to me. Does this function get called again or does the pre-initialized address get called on my account as address again or does it get called um does it not get called? So, I'm I'm a little bit puzzled here because I couldn't see where the pre-initialized

is called for every user. When you say every user, >> the the pre-initialize is optional. So, you are up to pre-initialize. It's an option. It's it's like a let's call it an a a plug-in, an extension, a module that if you add to your ERC20 contract, users can go in advance pre-initialize their addresses prior to uh a potential gas spike. So this is up to each user. It's not mandatory. Users uh doesn't need to pre-initialize to use it. Uh the implementation is optional. is optional for each >> mean some of the user may choose to

pre-initialize their address some may choose not to do so >> exactly and also uh the wallets in example if I have a wallet and wants to give a better performance for my users I can sponsor this pre-initialization h I don't know the I this opens the possibility to many use cases. Uh but also when when we will see every time more sponsoring of gas in the future and for sure this will save a lot of costs for the ones that are sponsoring the token transfers because they will be

able to pre-initialize the addresses of the users that they are going to sponsor the transactions uh when gas is low. So they will be saving a lot. And if you go to the Ethereum machines, if if you let me show you something. >> So >> and let me run a quick um the reason I so as an editor I'm usually not supposed to ask you uh technical review questions. But here I think the technical feedback and editorial feedback is slightly intertwined because we want to prove we want to work together to prove that this ERC is introducing um interfaces and definitions that can

achieve the goal and rationale that this ERC want to achieve for example gas saving. So let me run a quick thought experiment in this reference Assuming German you started out it pre-initialize your address which gives you a magic right now you also get let's say airdrop token let's say happen to be two tokens right >> so let's say someone who already own a token transfer to you um two tokens what will happen then this

address two will be German's address. This number will be two. The sender who happen to have enough balance would be able to give you two. Now you are going to be swapping the sender will be updated to it's at it is balance. We don't care. But let's focus on the presumed German address. balance by 32 German equals to your current balance plus value, right?

>> Okay. And then this is a typical transfer. Now your number becomes magic plus two. This is the the first step. Now the second step when you German want to transfer to me, Victor, you make a transfer. Now I'm going to assume you are able to transfer me more than two tokens maybe three. >> So let's let's try to run this experiment because I I actually don't know how it would play out. So now the the two is Victor's address and the value is three. The sender at this point would be the balance would be >> you will be having a magic

>> but this is this is the point that is interesting magic sorry yes magic magic is treated as zero. Magic is zero. >> Magic is is treated as zero but currently the value is magic plus two. But but when you do the maths magic is zero because it's a string and then disappear. >> So So here's the thing. If I if if I run this uh function at this point, I'm going to read a number of magic plus two, right?

>> No magic number. >> You just read two because magic disappear. Where does it like if I run this function read this function does it read out to? Yes. Yes. Balance is is not h it's not uh when when you do the maths the magic disappears and this start behaving as a unit. So the B 32 when it's taken into mats disappears.

>> I'm not sure I see where it disappear. Can you Yeah. Can you point me to the line of where that magic number get disappeared? >> It could work in solidity. There is already test. This is deployed and there is the testing transactions and also the results. the same contract and is verified on SC >> everything is already >> yes it's here you have the graphs on how you save and in you know in the in the specification if you go there reference implementation in the links a little down I a little up sorry in the in the in the machines forum yes you go a little up this is how you

say but a A little more there. There there down a little down. >> Do you want to Yeah. Do you want to present on your side? >> Real testing results. >> Yeah. Real testing results. >> The these are only testing the gas usage, right? What I want to >> check. >> Yeah. Well, let me let me do this. Uh >> yes, >> assuming can you verify the ERC20 uh token will be able to execute the following transactions.

One mint to address Alice. Let's say address LS20 token to pre-initialize of Bob. Alice transfer 20 to Bob. Now Bob, transfer to uh let's let's use just two because that's making it hard very hard. Uh transfer to uh three to

attempt to transfer three to uh to Charlie. Okay, this is already tested in the in the transactions >> and suppose the so what will happen to in your uh implementation what will happen to uh step four uh >> will will if if Bob try no will fail because Bob doesn't have three have two >> yeah let's uh uh suppose yeah that's what I think too supposedly Bob uh step four will fail and you run these four

app in your transaction in your reference implementation deployment and show the failure. Yeah. So basically that's a that's a technical question I did or if you already have a failure that you can like just show me on in transaction I would be happy to to take. Now, usually, just to clarify, usually I'm not supposed to be giving technical reviews because this is very specifically technical reviews, but we really want to test out that one of the implementation achieve your goal so that this is a um a valid uh ERC definition.

So, can you can you try to do that or do you think it it would take you some more time? You can like we can I can go review another a few DRC's and come back or do you already have a transaction that you can show? >> We we can I can do it but maybe you can go with another uh reviews and to don't lose minutes and we come back in 10 minutes or when you tell me at the end of and I will answer properly in the in the forum. Thank you for for this. >> That's nice. Okay, cool. Um let me just leave a message.

Uh >> how we do right now? >> Yeah, this is this this one over overall look like a really interesting proposal. Just one thing I want to check if the math still works in this new approach left a technical question common in is magi and

yeah please let me know when it's answered. Cool. All right. Thank you very much, German. Uh we will make sure to prioritize once you um are done executing these transactions. >> Thank you. >> Yeah. Okay. So now let me come back to the second one. Uh Puja I I will let you uh lead and decide which EIP I should review next. >> So the next we are joined by the author for PR number 1226. So if we can perhaps take a look >> 1226. Okay.

>> And uh is the author on the call today? >> Yes. Uh it's John and he's on the call. Yeah. >> Hi John. >> Hi. Thank you for the review. Appreciate it. >> Okay. So this was assigned 80033. Supposedly you already added that. I'm considering this as resolved. posit. Oh yeah, I left a message says we want to see if there's community interest someone AI council oracles important validation task.

Cool. Uh let me take a look. Okay. All righty. I would check the ERC commit review and consider. I should know I would do to not choose other ERC's due to increased in complexity and then not to be constrained and missing feed. Take a look with AI agents

foster city. So let me see the rationale. What's specific? What specific ERC? You're not you're saying increasing the complexity complexity would use does not provide a built-in review mechanism. Well, that's up for you to provide. That's intentionally left out, right? like it input adding that doesn't doesn't increase your complexity because you can choose them,

right? Okay. But that's your call. It would uh it would reduce your it would probably reduce uh the the adopability amid review that yes it was also considered but not easily applicable to the text fields and res resolution flow. So okay I will consider that I leave technical feedback but this is answered and addressed. Thank you John.

console based resolution flow must support core flow recruit request create agent commit review judging and uh aggregation and reward distribution. Okay. Um can any one of them be optional? I don't think that any one of the

>> agents optional. >> Yeah. Can an implementation decide to allow free of reward distribution? I mean that's for you to consider. You can say no definitely not. I we will consider it incompliant with our ERC if you don't have it. Um so that's like the the mindset of of ERC definition. You want to allow people to adopt you as easy as possible but also not too flexible that other people don't have the expectation. So yeah, I'm just raising this question. It's uh it's for you to decide. Um >> okay. Yeah, I I think that

>> yeah, this is optional comment. So you don't have to worry about this. >> Uh let me not let me not give it out as a as a suggestion. Let me give out as a question as a quote actually probably this is the best format. Yes. Okay. Now the console consists of two agent rows. Info agent and judge agent. Two rows who aggregate and resolve consoles.

We make this distribution distinction to clarify capability and domains are represented in strings and uh requests were represented in the strct of address reward token And bond amount bond per let me see if this is Clark this decide this discussed and bonded is a stake to defer

spam and actually actual enforcement or amount is implemented specific. I'm not sure if I read this sentence. This this definition is important because it explain what bond is in this context. But it's a little bit hard to understand. Can you kind of help me understand what is what this sentence means?

>> Yeah. So uh whenever the agents are committing their answer there needs to be a bond otherwise you know if the if the uh answer is incorrect you know there's no um negative consequence so the bond acts as a negative consequence. If the answer that they give is wrong then the bond is um taken out. >> It's a slashable stick back. >> Yeah. Yeah. It's Yeah. Essentially it's a slashable stick. Correct. >> Okay. I would advise I would suggest that you rephrase this sentence. It's because this sentence is a little bit hard to understand like >> okay >> or amount is implementation specific. If you want to say bond is supposed to be a

slashable stake so that u submission or mel malicious submission would be penalized then I think it's okay. But if you say that it's also implementation specific I think that is no longer explaining bond it's saying how bond can be imple implement imple implemented right so you basically >> putting two amount >> implementation specific >> right so if I were to make suggestion here I would A uh oh this is so long.

Bon is a slash bowl stake and agent put in to uh and uh if malicious if and be panalyze if how to say that The submission was turned out turns out to be wrong, malicious or

let's see. Yeah. and and the amount of it is implementation specific something like that just to kind of have a comma have a period to separate the definition and the instruction >> I I'll leave it to you basically um I suggesting separ separating that definition of a bond from its from the instruction of how it should can be implemented.

Okay. So, okay, that's the that's about the bond bond amount per agent. And this means you're very specifically saying everyone is paying for the same amount, right? Because you only provide one information, >> right? >> The kai and is that intentional? >> And that is in the discussion of rationale, right?

Let me check the rationale. Bond amount is Oh, because it's the everyone is an equal agent, right? >> Yep. >> Okay, nice. This is [clears throat] going to take a little bit longer because I think this is a long longer ERC and have a lot of details. M deadline deadline time stamp do you want to specify units is it Unix is it uh >> I mean I guess you can leave it open up

>> or block >> the implementation that's being specified >> yeah in that case you have to declare that this is implementation specific and has to be con um consistent across different deadline like the request deadline should be consistent with the unit. define the unit or leave declare that it's left for the uh implementation and that when you leave it to the implementation it means two agent contract that is con and two agent have to figure out agent client have to figure out what the deadline unit is in

order to interact with this er uh in order to interact with one embodiment of your in ERC and therefore you need to have a way to communicate with them. It is okay that you decide to say that hey everyone communicate that outside of the ERC maybe put your website or you can also say here is the thing we you can read it from um from from this ERC like do you know what I'm do you understand? Uh did I make my point clear?

>> Yep. Yeah. No, I I got it. We'll we'll make a change to it. >> Yeah. So that's the definition like in in ERC20 the decim the decimal was like clearly um was decided to be uh left for implementation but then they provide an interface for everyone to say what their decimal is. Okay. So this is the query. This is the specifications. You're going to send a lot of strings here and then a huge nested strct.

It's going to be very fun to to the parse. Okay. A lot of events. Agent requested agent commit. reviewed. Judge selected. How is jud Judge selected? Select randomly from a separate pool.

Recommended distinct. Do you want to assume this is a security risk? And how advise the implementer how you would suggest them to select because it's not very to do random >> we do the the rand out yeah we we actually we go into this into the EIP >> there is definitely discussion on how to select the judges >> okay a random judge our role based approach our role based approach is That an is that a is this approach an ERC level concept

or an uh or an implementation level >> when you say our approach? >> Let me see. >> So it's two different agents. >> So it would be >> the roles of the agents not the ERC. >> Oh the RO. Okay. So this is ERC. Right. is separate the ERC's specifically define different role therefore this approach is ERC level optional rep uh reputation thresholds okay [clears throat] let me see okay judge judge selection is

an important thing resolution has a has a has different stage. It has finalized stage. It has failure stage. I would suggest you swap the swap the the these order if you want. Supposedly resolution finalized and failure can be closer. Okay. This is a reason dispute initiated dispute window opened dispute resolved.

So you're giving it a dispute approach. Now core method you need to implement core method. A lot of time these different parts can be written in the format of different interfaces you know have you have you considered that and then you can say our interface is a union of these three interfaces and the c like when you declare the the request creation agent commit review judging aggregation and reward distribution. By the way, I think you would also need to mention the dispute in this in in here, right? You you have defined

dispute into interfaces. It's probably better to include that in these part in the in the overview. I'm assuming this part is the overview in the specification. >> Yeah, we do go into the this view part, but sure we can put it in the overview. >> I mean uh if it seems like this is quite important in in the in your interface definition.

I would I would I would leave I would also include that. So, and then you have to decide whether that's master or not. And since you put it in uh workflow is it how should I put in the dispute and uh and dispute res resolution

process. So here is distribute. Now review commit. Commit ID. Reveal request ID.

Nons. is your bond is your bonds paid in reward token or is your bond paid in native like ethers. It would be up to the implementation >> and if it you if you want to allow if you want to allow bond amount to be paid in reward token then either [clears throat] you have to

define so here's the thing you have to make that uh decision as a ERC author uh if you want to leave it to the implementation implementtor you have to call out and provide a weight for them to tell for example uh if you say I want to let everyone use their own token for bond then it do they have to be the reward token or not what is what's your call? We would like to make it open enough that if they want to make all of the reward the bond the same token or if they want the reward to be in Ether and the bond to be in another token that

they have the ability to do that. >> That's that's nice. That's very nice. That means that information had to be included in the request, right? Then you'll have to have an address of bond token if you want to make that if you want to allow the implementer to decide that you can also say yeah alternatively you can also say yeah we allow you to use any token but it must be the same one with reward that's also an option right but now when I see the reason why I'm raising that question is because I see the commit

function has a payable mark, right? Which means and then it it the comment says with bond when everyone when most of the contract implementer read this part I think we will think that bond is paid with the native token ethers in in in in maintainance because you want to use the payable. So that's like the that's the kind of a clarity we need um as a reader of your ERC.

So I will leave a message of can we clarify what token does the bond accept? Right. Does it make sense? I think my I I I am giving a verbal comment. I I I I'm a little bit lazy to type them out. >> Yeah. >> Yeah, we can make the change. Thank you. And reveal and Okay, let me see. Because you're distributing rewards. Uh I'm assuming these bonds should also be

distributed back in in the life cycle of this arrangement, right? >> Yeah, that's part of the resolution. >> In the resolution, bonds will be distributed back. Let me make sure that is discussed. Reward distribution. Refund the bond for fed others.

>> By the way, do you assume judge agent to be one single agent or multiple agent? One single agent. >> One single agent then the implementation may forfeit the judge agent in what way? Oh, if they fails to resolve the you know allotted window. So the judge agents are believed to be truthful and honest no matter what. Uh not necessarily and that's why we do have the dispute mechanism but yeah.

>> Oh right. Dispute. Okay. Optional dis extensions. All right. And [clears throat] Yeah, I think that would be a better summary.

No. Okay. I will leave this to uh security selection collusion of bonds fairness of random selection of judge. So rely on the crypto talk crypto strength of randomness in this in the security consideration.

Okay, this is the this is and then a aggregate. There's one request. The aggregate is to aggregate answers. Oh, final answer. How does aggregate work? The judge agent will look at the sorry go ahead.

>> The judge will call the aggregate to submit the final answer and classify winners. Implementation must auto count votes and take maturity. in that case. Does it still need a judge? >> Yeah. Um, you know, the agents could put incorrect information, >> but you also say it must also count. So let's say judge based on the submitted

revealed votes this there is one answer and the judge counted it but decide to override that answer is that a possible implementation in this proposal like is that still considered compliant >> yeah I mean it we'd want to be able to make it possible that if all of the agents were saying something incorrectly, the judge would have the option to override it and say no. So yeah.

So I think I would need I I would suggest clarifying what it means to be must auto count and also can you clarify what it means by must auto count using maybe. solidity code to uh that code demo to show.

Yeah, because I I when I read that I'm a little bit puzzled, right? Like if it's already counted then then you don't need to pass in the clarify how to handle the case when judge agent.

Believe the info agents votes need to be be overridden. Right. Okay. Now we're at what step we are now. We're in aggregate. Let's see what what else does aggregate will do. It will show the winners and the winner must be the info agent.

Winner for reward classification. Okay. So winner winner call distribute this uh rewards to pay out correct in agent which means such rewards must be stored somewhere like this this uh we'll store the winner okay based on config proportional split implemented the specific ratio like judge fees, refund bonds to correct info agents, forfeit others, emit

distributed. No, it must pick it must vote. You must count and pick majority which means the judge will have to pick the majority. So judge cannot overrid override the answer. I think if you if if you say have must also count I'm assuming must the word must also apply to pick right so I guess the question is can judge override

can judge override the the the votes question can judge over judge in agent override Right. The majority of votes. If yes, then why is must also applying to egg?

Maybe decide must decide if to pick. If no, then judge agent cannot override the majority of votes. And why does it need to submit final final answer when such answer can and must be decided based

already submitted votes. So that's my question. Do you have an answer to this? This is pure editorial. This is unclear that can lead to two in two understanding. >> Sorry, give me one second. >> So in this particular this is an important part of your proposal. You specify judge process. Judge must auto count review votes and pick majority.

Now the question is can judge agent override the majority of votes. If yes then must does not apply to pick. Judge can must decide if to pick. If not if judge cannot override the majority of votes then the final answer should not be submitted by judge. the judge the the final answer should be like derived from the state of the contract and there's no point having a a a parameter of final answer in in this aggregate.

>> Yeah. So it also depends too if it's a discreet answer an open-ended answer as well. So we can specify that. >> Okay. I'll leave it to you to just to to this this is a question I think would benefit uh your imple implementer to clarify. Okay, I will move on to I guess we're very close to time. Probably have to come back again. I think I'm like oneird way. Uh I think from the logic side I'm I'm halfway or 2/3 way on. But for the but for the for the rationale I probably wouldn't take that long but

probably would take another time. So um I wonder pad how what how should we proceed? Should we I'm I want to kind of give German some time if he if he's still here >> if if that's okay. >> Yeah that's perfectly all right. We have a couple of minutes left. Um German if you have any updates to be shared. >> Yes. Hello. Yes, I I just posted all the tests and it was successful. So, I think someone has to approve my my reply or my reply is is on the forum already.

>> Uh let me see where is the link. And John, sorry to not being able to finish this review uh in one pass. >> It's okay. Thank you. But yeah, you have a very uh large and comprehensive and important ERC. So, we want to like give it enough in attention it deserves. Uh okay, let me go back to the link that uh Puja post up. Uh let me see.

>> So, we're looking for magician link for that proposal or >> Yeah, I'm I'm trying to look at that magician link. It's uh I've been too deep into the the Asian Council Oracle review. >> I just shared in the chat for your reference. Brain overload. You have too much information in one DRC. Okay. So this is my uh question. Let me So I'm now back to the ERC 303

803 on my question comment. Um German, have you posted your answer here? >> Yes. Yes, I did. But I can't see it was very very extens and with all the tests uh with >> I refreshed I didn't see it. >> I think your test >> can you post your your your uh your Can you post your link? >> I can't see it. Maybe it went to drafts. >> Oh yeah. I maybe you went to draft. Can you share your your your your No, I mean it was for for approval from

someone maybe. >> I'm not seeing your posting again. >> It's on pending. >> Oh, you couldn't you couldn't submit the reply. >> Yes, it's on pending here. Says >> give me a second. I will try to approve that. Do we now need a approval for uh if magician's reply? >> Not really. But I think in this case because they are using some address and it could be flagged by the bot that these may not.

>> So now you should be in a position to see the response. >> That's weird. That's weird. That's the author. It should not be flagged if the if the post is fl Oh, because you're adding you're adding a lot of links. That's possible. >> Yeah. Yeah. So, the bot is designed enough that anything fishy should be flagged here. Yeah. So, that's why it was blocked. >> Bob to Charlie transfer will fail. I made all the steps with the three new accounts and I added an extra step to send two tokens after this failure.

Insufficient. Okay, that's okay. That's uh that's a very interesting approach. I will probably have to study more but that at least um is a valid is is a test I I'm happy to see and uh let let me merge it as a draft uh for for now that you have uh show uh that it it would fail. So there is way to make sure that the math works. I I think you do need to clear up the the some of the bots failure but um I I'm going to give it a thumbs up.

Yes. Yes. The bot that bot is is going every day to show. >> Okay. Cool. All right. Thank you very much. And for whoever else is waiting, I'm sorry that we didn't get a chance to get to you. >> Thank you so much for your time. >> Thank you, Victor. Thank you everyone for joining. And people uh if you could not get your PR reviewed this week, we would be having another meeting on November 4th. So try to leave a comment and we'll try to include it in the agenda. But in in the meantime also editors are taking a look at your PRs.

It's not only editing office hours only. So please feel free to drop in the discord channel, editors channel as well as drop your link here in the agenda. And we are also organizing EIP summit at Dev Connect. So if you are around please stop by. It would be a good opportunity to meet editors, authors, developers and exchange our thoughts. Thank you everyone once again for joining. >> Yep. Bye. Thank you. Oh,

heat, heat. Heat >> up [music] here. up

here.