SSZ Transactions Breakout #2

Transcript

and get started um hello everyone welcome to the SSE transactions breakout room number two um I was offline last week so I unfortunately didn't follow a lot of the things that have happened in the last week or so so it would be great for me and probably for others to get an update I think Eton you've been working pretty hard on doing some analysis on the performance differences between the union SSE format and the unified SSE format do you want to take a few minutes and talk a little bit about what you found

sure um last week essentially in the call we figured that there is no clean answer and both options are viable and both have their own advantages and disadvantages and to avoid having to flip a coin um vitalik essentially requested me to collect as many metrics as possible to see whether one format or the other has advantages especially in light clients and that's essentially what I did I can put the link to 6404 in the chat and when you scroll down there to the

test cases um the union approach is a bit smaller for most transaction types it's about 50 bytes per transaction inside consensus payload so it's about 10 kilobytes per block but it has a couple issues and namely the transaction ID and signature hash and they are not part of this transaction when the transaction originally was an rlp transaction anything besides SSC essentially has this problem

and it doesn't sound like a big problem but it kinda prevents doing useful proofs on those kind of transactions because if you don't have the signature then you cannot recover the signer so you don't know who sent the transaction so even a basic proof like tell me who sent something to this address doesn't work for rlp transactions furthermore the union proofs were mostly bigger in size than the normalized transaction proofs that's a very small difference so

it doesn't really matter that much but um what matters is to verify a proof that with the Union you have to do a lot more operations and that's this SSC proof verification requirements table a bit further down um where you can see that to verify a proof um like a basic proof who sent an amount to someone um you need the SEC p256k1 public key recovery and the Qatar cache to recover designer and you need rlp only some minimal rlp and another ketog cache if you want to know for a transaction that deploys a new

contract where this contract will be located because that one depends on who signed it and its Norms so with every new transaction type this becomes more complex so for example if you want to have a transaction type that uses Ed 25519 instead of SEC p256 K1 suddenly you need that one as well and if you need Poseidon hashes then you need to add that one as well and it just explodes so it also shows a bit for this embedded measurements that I did but uh yeah I essentially made two implementations uh for both the union

and the normalized where I created all the proofs where I created all the verifiers in both python with libraries and in C without libraries except for The cryptographic Primitives and these are linked below the tables and yeah I mean we we just have to decide on one or the other essentially that's awesome it looks like a lot of pretty great work done here does anybody have any comments on the findings of the etons had I actually had a couple questions I was

trying to understand what you mean by for non-sse transactions you need the full transaction to figure out the sender are you saying that in the uh the union transaction format this is the case and it's different for the normalized transaction format yes essentially in the normalized transaction format I create as part of the consensus payload so so when you create a new block um like I put a copy of the transaction hash in there so it is part of this SSC tree you can just clear it directly and the same is the case for the signer and for the address of a new contract so all of these derived computations you

can just fetch directly so that's also why the normalized transaction is a bit bigger so I guess why is that specific for the normalized transaction why is it not possible to say have a the trend Union transaction type that has some inner transaction where the union sits that has a different transaction formats on it on the outer structure you also have this data the sender and maybe the contract created address um you could start doing that um essentially you can put this contract address as well as the sender and the transaction hash outside of this

container but then you kind of start combining the disadvantages because then you need even more storage than the normalized transaction which can store those fields as part of the transaction itself instead of in a wrapper outside and you also have to think about how to structure it inside this tree because the union has this Union selector at the top and you would have to wrap that one with these additional fields and when you do something like give me all transaction IDs inside the block then this answer should not be too big

and so so the transaction ID needs to be on a get another separate layer that's what I have in the normalized the TX hash is at the top so yeah you can do that but um transaction gets bigger and you don't really gain that much with it I just I feel a little bit like especially in this SSE proof verification table it's not quite a fair comparison between the two because in the and even in the normalized case you know we're kind of going into this world now where we're putting derived fields in the consensus objects which I don't think we have generally done and so of course it's much cheaper we don't need

to do the elliptic curve uh checks at the the recovery in the normalized case if you just put the derived values um and so it's not like it's not quite a one-to-one comparison between those two those two things you know yeah sure I mean it is for um for SSC transactions it is because for those um the transaction ID in the union is farther um towards the top but uh and the signed hash is is an intermediate node so for the union for the SSC transactions with the Union that's what you gain is that you save

this extra space um because they don't need the extra notes in the tree for um storing those hashes but I know what you mean it's not one to one um with the normalized you need the fields there because there is no structure where you can derive them otherwise um what do you mean there's not a structure that you could derive them like is there not a trend there's still the idea of the transaction type right or no uh no in a normalized version the transaction type is just like one feel of a transaction that tells you how to recover the original representation but um it it is not a major criteria anymore um if you scroll up to let me let me

just find this real quick it's called uh normalized transaction representation okay there you can see that the transaction type in in this case is inside of this transaction signature type and if you search for that one that one then includes the transaction type but it's it's not really a special field essentially what this does is it gives you the Json RPC um thing that also has like the type in between the other fields it gives you this representation of Json

RPC and adds the ability to prove that the answer is correct I see do any other client teams have thoughts or comments curious to hear especially on this idea of embedding derivable values into consensus object it seems weird to me but I don't mind I mean I will follow whatever you decide anybody else what is the reason why do

we have the right skills there like if it's derived you cannot calculate it when we need it and the reason is with the normalized representation that even if it's an SSC transaction those fields are not part of the tree so to compute them you need to download the entire transaction including all the call data which can be very big and one of my use cases is a device that has 64 kilobytes of ram so the call data doesn't necessarily even fit in there so it's not a really derived Fields like

derived field from a more data so then why it's not a problem for me it is um to be fair this Hardware that I just mentioned it is a very common Bluetooth chip that is used in Internet of Things devices so you could imagine as a use case for example a bicycle lock and you have your rental pass on your phone and you just want to submit the quick proof that you did your payment and that you have your pass so so the bicycle log just needs to verify those things and record who sent it so that it can do the billing later um this is the same chip that is also

used inside Apple Air tags like those those object trackers that you can attach to a key so it's a very common chip for about two dollars so what will this first this verification be done on transaction uh object this kind of verifications I mean I had to construct it in a way um for transactions because we are talking about transactions of course in a real world scenario you also want to verify the receipt so that the so that you know that it was successful and if

it's an nft you also want um approved from the state which right now is is this marker Patricia 3 proof that you need to verify with ketchoc and it's uh like this is get proof response that one will become vertical later but you could already do something simple that says if you send one year to this address then I can get the sender of it and record it that they paid me with trust transaction and receipt any other thoughts on anything related

to The Proposal this like the last part kind of sound sounds to me a bit like over fitting for a very very small use case like when how often do you suspect iot devices to verify the transaction but not verify the storage proof I I I don't think that this should be a consideration uh when when when choosing the the SSC no no sure I mean normally you combine information from all the three tries

that you have receipts transactions and the state but as part of this you may have a transaction proof of course we can say that there is no use case for the transaction three um and then we don't need an SSC representation at all uh it would just mean that we would transition the Merkel Patricia tree to an SSC tree but underneath there would just be the byte vectors I guess that could be an approach as well did you consider adding some of these derived fields to the receipt rather than to the

transaction object um at the start I consider that because then what you gain is that the extra fields are not part of the consensus payload anymore so they are not part of the block they don't make the block bigger anymore but there is a problem when you do the backfill because right now you can backfill the receipts and the transactions separately and if those extra fields are part of the receipts tree you can no longer do that you essentially need to sync all the transactions first and then all the receipts so I'm not sure if that's worth it um as a restriction

sorry I'm not I don't know if I quite follow the rationale for that why do you need to you're saying the problem is is that it becomes like a sequential thing yeah you have to download all transactions why can't you if you download the header chain you have the receipt route so why can you not verify that the receipts just match that why do you need to verify against the transactions too um if the if the transaction ID the signer and the destination is part of the receipts root or or you mean like if it would also be

part of the receipts themselves then it could work I guess that yeah that's what I was referring I don't know what you mean by part of the receiver I meant expanding the receipts because the receipt is kind of a derived object it feels like if I were to put some like more derived elements that it would fit more naturally into the receipt because the receipt comes from executing the transaction so you would expand it to include the from address the contract created yeah those two Fields um could could work there transaction hash uh there there you also have the issue that um I'm not sure if that's a use case but

uh the consent was layer right now it can answer a query about hey give me all the transaction IDs inside the block if the transaction ID is only part of the receipts route um I mean you should be able to compute the transaction ID from the full transaction right yeah if you add catch up sure and if you if you add all the SSC types to the consensus layer right uh for the from address that's true that

one could be moved to the receipts route um to create destination not sure how much that one gains because right now there is this optional destination address in transactions and the address is like 20 bytes so destination like one nice Advantage is that it's no longer optional so you can save this extra wrapper of this optional element but I mean that's yeah it doesn't really matter where it is for that one let's get saved any other thoughts on this

I think we can Circle back in a minute and talk about future steps but I saw there was another proposal that you have Eton this SSE transaction signature scheme did you want to talk about that on the call um I think we should mention it as well uh not sure if it's the right call for it I mean it's SSC based and it sort of affects all the SSC transactions including 4844 um I can briefly mention it after if you want um I mean I guess like you know the only other thing that we should really talk about is what are going to be the next steps for these proposals for um changing the transaction routes and

the other routes so it might be nice just to mention the signature scheme and then we can talk about how to deal with these things in Cancun okay I mean let's move to the signature scheme then because for the other one it seems that there is no more comments on it so um the signature scheme is 6493 this is essentially a way how we can structure SSC transactions um in a way so that hash that is being

signed is based on a SSC route that is part of the transaction tree and also so that it is not malleable if there are multiple transaction types that can encode to the same hash that there is enough information mixed into that hash that they cannot be confused even among different blockchains different forks from different vendors that may have a different understanding of what a specific transaction type is if anyone checked it out I can

answer questions as well yeah any questions guys so is this kind of a prerequisite to sort out for 4844 yes I mean I think you made this PR at some point where you changed the 4-H functions to hashtri root and this is essentially the follow-up of this how could we do that yeah and it's also very close to vitalik's

document about SSC unions just to clarify here you're saying uh in the uip that included in the signature scheme there is the fork where this transaction type was introduced so the fork hash introduced in the fork ID so basically execution clients need to keep track of when each transaction type was introduced in which fork and include the forecast for that and the signature for the transaction exactly yeah that's just uniquely

identifies that what is being signed is really this blob transaction from 4844 and not something else because there was this problem that I think starknet use transaction Type 4 for something and now we can never use for ourselves or and I'm not even sure what happened to three and there is also 25 that is being used for message signatures so we cannot use that for a transaction type anymore um just gets rid of this problem but it doesn't want the Genesis hash and the chain ID uh add enough uniqueness that even if the transaction type for for example matched the transaction type

that's darknet or whatever other chains are doing then chain ID and the Genesis hash will uniquely identify that oh this is in a certain chain in a certain Genesis maybe um I'm not sure about those Forks like East W or um is classic maybe some of them don't change the change chain ID initially or change it later um it could be that I put too much information in there um also there could be different chain IDs

not and it's maybe it's maybe it's all right without that fork hash I'm not uh it's w they I'm pretty sure they changed the chain ID and what Genesis hash is the same for both 8w and ethereum classic on the other hand if we have forecast Genesis has enter an ID kind of a redundant right the other way around sure four questions unique completely per train uh unless there is a three-way Fork but um okay maybe

but Genesis hash can be dropped differently ah Ford uh Ford version includes Genesis hash I guess yes yes so if we're including the fork maybe we can drop the Genesis so if we're a quick question if we're including the fork hash then I like will my transactions just not be valid anymore after a fork no no it's the forecast when the transaction type was introduced on a network oh okay so first action always come cool essentially

six and this is only of course for Trans new transactions like SSD transactions and the coming ones right yes this is only for SSC transactions okay um so one one thing that I try to do here is to keep it as close as possible to consensus where they have Genesis validator root and a fork version um they don't have the chain ID but um maybe like I'm not sure why they have both the Genesis validators root and the

fork version maybe that's just an extra safety thing but if we know who created those specifications maybe we can find out if the fork version is necessary or the Genesis hash is necessary yeah that sounds good any other comments on the signature format um just uh can you clarify domain types a domain type is just a four byte value

that is used to distinguish a kind of signature that is being signed so in consensus there is for example one domain type for signing Beacon blocks there is one domain type for signing attestations there is one domain type for doing soon committee contributions and here I sort of create one domain type per transaction type what's the idea behind this the idea is that if you have a transaction for example that has a

un32 and that's type one and then you have another transaction that has two un 16s for example or or a un64 um they they could both end up having the same same hash in the end yeah the UN 3020 un64 they could have the same hash value and putting in this domain type that contains the transaction type um solves this by giving a separate hash for each of them otherwise when you sign one of the

transactions it could be interpreted as a valid signature for the other transaction type yeah thank you Eton is there anything else that you wanted to mention that we haven't covered or should we start talking a little bit about how we think about making these decisions for Cancun there are a couple minor questions left

like China ID should it Beau in 256 or should it be a un64 or should be a byte Vector 32 um just those minor things I'm not sure if we need to discuss them on the call I guess those can be I think I would say it has to be greater than 64-bit but I don't know about the byte Vector versus un256 that there used to be a proposal where they wanted to create deterministic chain IDs based on some hashes um so if we want to support it it sort of needs to be a u.n256 or by 32.

yeah for un64 as well for legacy transactions because they do arithmetic on on those chain IDs what is the arithmetic video um they for computing the signatures V value they use chain ID times 2 plus 40 plus 35 Plus y parity right and metamask because it's JavaScript based they have an even lower limit like this you win 53 or something that they accept as a value chain ID

issue but yeah I mean that's a detail that we don't need to have everyone any other small details more about this block transactions they are very rare I think one or one to four blobs per block and there was this proposal from protest to even separate the flow of transactions into a separate tree I'm not sure what happened to that one but there is this question whether we want to always include the blob information or keep it as an optional

right now I have it as an optional but it's the only place where we have an optional field inside the entire protocol so it feels a bit off there's not an optional for the two not anymore because it just becomes a union of either it's a regular transfer or it is a create and then you have the destination there so you don't need a optional there right okay I see and for the four eight four four transaction I think our use you preferred if they would not be allowed to also have a

create intent so so you cannot deploy a transaction and have a blob at the same time so it would also get rid of the optional there yes I would love that nice yeah I guess let's talk a little bit about what to do next how to get ready for Cancun obviously we have the awkward devs call tomorrow where I'm sure we'll talk about some of these things you know I personally I feel I'm a little bit behind on what you've been up

to so I will spend some time and try and catch up a bit but I think there is quite a bit here and we're starting to you know really think about everything that can be done like having having some derived fields in the transaction this is kind of a new idea I know there's a little bit of talk about maybe also getting rid of uh the bloom filter changing the receipt format like we're starting to discuss lots of things and I would say one it's like really important that we have more people engaged with it I don't want to get this to get to a point where

Eton you're doing most of the work like writing a lot of proposals and it's not until like two or three months later where people start really engaging with it because I think that this is going to take a lot of work from many different client teams to figure out what the best solution is so we should keep that in mind uh I also think it's sort of difficult to follow all the different things right now like one way one good way of trying to really understand how all these things fit together is just to go and implement this as if we're implementing for Cancun and I don't even know where to start right now so if you had the ability to create some sort of meta spec like here are the three or four or five eaps that we

intend to put in Cancun together that would be pretty useful for myself how do these metal specs work is that another eif that then umbrella or uh the way that it's been done in the past is people will just create a hack MD of sorts it could be like whatever it doesn't have to be any IP it could be whatever document format you like and just write some information like here are four eaps this is how they fit together and you just use that as some sort of tracker to to track like maybe what content no matter what what

are the where can I discuss if I have a question about something like what is the right form to discuss that Etc [Music] so I can create this meta spec I will also have to update the receipts um similarly to the transaction what about this idea of moving the derived Fields into the receipt should I try and explore that as well I I mean I think it would be great to explore it but I think we really need to have more people get eyes on this thing like without getting more commitment from

client teams that this is even a direction that they want to go then you know it's kind of moot if a lot of clients say they don't they think that having to ride Fields inconsensus objects doesn't make sense so I would say like that's something I should we should probably discuss on all core devs just looking at the transaction route EAP there's like a lot going on and I'm not sure the best way to like really engage everybody with the content like I'm sort of looking at it right now and it's hard to it's hard to think about how much this is going to change the client code base

right so without that I think a lot of people will just glaze over this until the very last moment and we really need to get them engaged quite a general question about uh what can be if we've lost on all these uh will it damage the system is it better or not uh I I think you know a lot of the conversations that we're having now sort of came out of the

fact that 4844 is really the next slated big thing to happen for the protocol and because there is this desire to have for four as an SSC transaction it feels like it's the right time to do some of these changes like moving things to SSC otherwise we end up in a similar situation that we have with withdrawals where we shipped withdrawals because it needs to be done or in the process of shipping withdrawals but we are using the miracle Patricia tree and very quickly after we're expecting to change it to SSC and I think that if we do 4844 like we're going to have this hacky format from 4844 where we come up with some weird signature

scheme we come up with some way of like putting in the miracle Patricia tree and then we end up changing it later on or we create a a much harder environment to change it to what we want so I think that's like for me the main reason that this has come up and why it's sort of getting coupled together with 444 I'm sure that you know Eton you can share your perspective but I think like from your perspective we really need a lot of these changes to make like clients viable and that's obviously like a huge a huge part of like the ethereum road map is improving the viability of those things yeah I mean I cannot really add anything here you already said yeah so so the

idea is to put it in Cancun but I don't expect there to be a huge change for um execution layer because um most of these is about the representation as part of consensus there is no new feature or removed feature maybe the blobs maybe there was a Bloom things get removed but whatever and you can always convert between those representations if you don't have the internal code ready yet you can just convert it back to some format process it as usual and then convert it to whatever you need um if you just need to ship something

fast so so the main challenge here is really the design work and and also finding agreements the other client developers have comments on this especially on like how can we move forward and make decisions like there are a lot of different aspects of this proposal and a lot of different ways of comparing them that is very interesting to hear about additional claims I mean like low computation power devices and

so on and uh probably it would be cool to have such example somewhere like who can be a consumer so we can consider it in other assumptions to like check if it fits is there an internal for us execution client developer uh develops for several like reference right and we are not aware a lot about glowing devices for example if you could provide more information about that would be helpful

understand the motivation about some points and so on yeah that's a good point um I wonder if it would be useful to try and you know maybe this is like an easier place to find alignment is to try and discuss like what what are the goals of this proposal and change because I don't know if all of the core developers feel that changing consensus to make it more amenable for proving on low resource environments is an important thing to do it seems like a really useful uh aspect but maybe there's arguments that in the farther future if we're able to create a

snark of the entire protocol that's very small that this should be you know all that like lower power device is needed and it's not necessary to also have like really efficient ways of proving certain values of transactions so I don't know if that would be a useful thing to talk about a little bit tomorrow it's like sort of like what is our alignment on this change in general what are we really trying to achieve with it and then use that as the rubric because it we now have a really good idea of what is the performance considerations of the two things now we need to spend a little bit of time of thinking about like

it you know how do we go on from there what what is the measuring stick to figure out if the unified version or the union version is better yeah also for those snarks even if the verifier has constant um performance like it doesn't matter how complex the proof is for the verifier you have the proving cost obviously and that one depends on things like the branching Factor it depends on the hash functions that are involved I could try and ask a zero knowledge

guide to estimate those two proposals as well so so we have numbers there as well that compare the proving cost if that is relevant I mean I think it's hard because I don't think we're very close to True ZK Circuit of the whole protocol and so the numbers that we would get back are probably pretty far you know unless it's like orders of magnitude difference pretty far from being relevant in the overall scheme more information is obviously better but I don't want to I don't want to drown to

everyone in in the information um all core devs call tomorrow is there I haven't looked at the agenda did you open a uh points on the agenda etons to discuss the sscification of things or not yet I haven't so far I can I can edit uh together with this um whether we want derived fields in the transactions tree or whether we want to force them into the receipt

and and also these sample clients like what clients do we want to optimize for our what clients are there I guess yeah I think that'd be great um it looks like Tim's already put a summary of the SSD transactions breakout room this one on the agenda so we will talk about it but I think it would be useful for you and everyone else on this call to think about what to talk about on the call tomorrow yeah just a small point to mention is this is your based on his calculation actually is a new topic for execution

client and uh probably uh some of execution plans would require more time to implement it if we want to move to other type of tree of root calculation I mean tumerical equation right instead of no competition tree so right it is smooth small uh point about moving Cancun update in further future because of that if we want to switch so maybe it will require more time just

yeah that makes sense I would say that in general if execution and client teams haven't started or are not looking at implementing or using a full SSE library that also does have tree roots they should probably be doing so because I think it's almost certain that the 444 transaction signature hash will be a hash tree root of something so I would keep that on everybody's radar we got 10 minutes left

anything that people want to talk about that we didn't get a chance to discuss any other comments on Cancun or maybe just like we you mentioned this and hmd would be nice to have the list of all the stuff I see like the uh the drawers through transactions route specification and all those other things have a list of what all the things are uh being taught like right now most of them are in traffic so which of them are how close to being Cancun all of them or

maybe some of them or like is there some dependencies between them and like maybe this was yeah I mean that's something we should discuss tomorrow but I wouldn't use the EAP status as How likely it is to go into Cancun at this point I think it's right now pretty likely that we do you know probably all of the changes that we're talking about as a z to find the numerical particular tree roots for transactions receipts yeah I think that's pretty likely at this point but we should continue discussing it anything else that would be useful as a

client developer as an El developer if you were interested in prototyping this is there something that would be helpful for you to get started I would always like to have uh like uh test cases like uh how everything uh example of uh something that somebody considers valid signatures or whatever you know when somebody loves me do you mean for um for the blob like foreign normalized Transaction what does it look

like uh when it's like actually invites so that I can parallelize it myself and see whether my implementations are realized it correctly and so on oh sure yeah can't do that but like uh probably after um after the design work is yeah yeah yeah that makes sense so I will do one in Python great yep that would be great thank you is there anyone who like who has strong feelings about the

Union thing like who thinks that the normalized transaction is bad in a fatal way I don't feel like I've spent enough time understanding the the words that you've done on the normalized transaction formats but I am still apprehensive of it a bit and I need to just spend more time thinking about the differences and trying to implement some of them yeah that would be great also this idea

um moving parts of the fields into the receipt that could be interesting as well we just have to make sure that the zinc can stay flexible as is and uh yeah that we don't over complicate things I mean this is about two two hashes and the destination it's yeah okay guys uh yeah good call any last comments could we close

okay cool have five minutes back to your day I'll see you all tomorrow on Awkward those see you thank you all right bye-bye thanks a lot