Protocol Community Meeting (July '22)

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:10

   well welcome back everyone um to july's protocol meeting today we're going to be talking about ibc in our blockchain communication integration and also bls as an add-on as well and we have several hosts or panelists uh along with us uh maybe we wanna do a quick introduction uh start with yeah yeah uh yeah yeah um yeah hi guys uh i'm working in aurora working as a rainbow bridge team lead so today i will be having some discussions with

2. 0:50

   guys on bls signatures and actually its introduction as near cost functions and where we actually need it awesome thank you soon sorry guys i had a issue with my app no problem yeah i am the bridging lead at composable finance and we're currently working on uh trustless ibc bridge to near that involves the use of on-chain line clients and we will also touch on some like host functions and some other protocols that

3. 1:35

   we think nier should adopt to make this ibc bridge a reality awesome thanks so much george hey everyone my name is george i recently joined pagoda and i'm part of the protocol team i'm working with bowen for for the past month i've been focusing on stakeholders and i'd like to to talk a bit about it today awesome yeah super exciting stuff and marcelo uh hi everyone uh marcelo here from our labs as well working as a

4. 2:20

   protocol team investigating a little bit about how we can uh uh today i will be supporting uh i will be here supporting kill mostly on the discussion about the merge and how we can uh help from the near side to make the bridge uh working after the commercial office cool awesome we have bowen you wanna take away give a update and uh yeah overview of the agenda uh first uh talk about some protocol updates at zero and then george would give us a presentation on stakeholders uh what it

5. 3:00

   is and what we're going to do there and then we'll have discussions for um adding different pre-compilers for uh ibc and and then also bls i think they're i mean they're not obviously not entirely the same but uh a lot of the uh things there are similar because they're all for the um for for some some bridge whether it's to um to to serum or to other chains let's get started awesome and um yeah just just want to um throw out there at any time if you have questions please feel free to write them

6. 3:32

   down as you have them uh we'll either get to them um during the call or we'll save it for the q a portion at the end depending upon uh how it's how relevant it is so yeah at the bottom uh there's a q a button go ahead and click that and ask a question at any time so yeah go ahead okay so yeah just a quick update on the next release the 1.28.0 release is going to mean that uh in about two weeks um and one exciting feature is that the

7. 4:01

   outbn 128 pre-compile is now fully uh stabilized um it's already on test net and if people want to try it out uh feel free to do that so this would enable us to um to build various exciting things including uh private transactions and also other uh zero knowledge proofs and so on um and then on the kind of more client side we we had we had a big refactoring of the current actor uh to to avoid have the trunk processing actually block the entire uh client actor which was the

8. 4:31

   case before uh and this hopefully would give us um more stability as well as some performance gains um and then obviously we're working on the uh um phase one of starting launch uh the engineering a lot of the engineering work has already been done we're basically in the face of uh finalizing that work um and we expect that uh release to uh to go to testnet uh in mid-august and then the the final release would be uh down how may not uh close to the end of

9. 5:03

   september um so that's kind of the uh uh very high level updates and i think george will talk more about uh stakeholders and and and how that relates to the shouting launch as well uh i already saw some questions uh oh no you they were just asking if this was okay youtube or it'll be uploaded okay cool cool yeah so that's the uh quick update on my site uh so now i'll just hand it over to george to

10. 5:32

    present my stickers hey uh thanks bone for continuing the screen share it's a bit easier like that so uh for those of you that have been around the community for for a while you've seen uh stakeholders in the past you've seen it at moments when the protocol went through a number of changes and it was mainly focused at the community and helping the community go through that change uh we have a similar thinking right now as well bowman mentioned that

11. 6:04

    in september we're planning to release the phase one of sharding and that's going to introduce a new type of validator it's called trunk only producer um definitely this is going to be a protocol upgrade and we'll introduce a number of changes one of the most important ones is the fact that we're going to increase the number of validator seats from 100 to more than 300. now exactly how much more

12. 6:29

    we're going to see depending on on the data points we get from now until september to see how the network behaves as we approach those limits but that's the target that we have in mind now with this change um going to happen soon uh what we have what we have planned is to run a program and you brand it as stakehouse because it follows the same uh lines of thinking uh from the past a program that spans for two months it started yesterday and is going to continue until the 9th of september

13. 7:00

    and that that has three main goals which is to help the community become familiar with the chunk only producer and give the chance uh for the community to get an early access to it before testnet we have prepared a dedicated networks specifically um built for um for the chunk only producer it's called sharpnet and that's going to be the playground where you can get an early view of what the chance only producer means also stakeholders wants to

14. 7:31

    to uh create the environment which i just mentioned to battle test the code and i run out any sharp edges that that we have or anything that uh still needs a bit of our attention to to gain uh confidence in the release that we're going to have in september so this is going to help us the whole program is going to help us from this dimension uh iterate uh pretty quickly through a number of fixes that that address any pain points or any issues that the community finds um

15. 8:01

    and the the third dimension which is a very very important one even though i placed it last i place it there is to be able to talk a bit more about it is um assistance to the people who want to become a validator in mainnet i've mentioned that introducing the chunk only producer will increase the number of seats from 100 to more than 300 and we want to to offer support and to help people who want to get one of those

16. 8:25

    seats stakehorse is there too to help with that you can visit near.org stakehouse to to get more information around the program and get all the details around how to join it until then the uh stickers is uh a we see it as a community driven uh initiative we've partnered with metapol with linear with ever stake and open charge alliance to put this program together and to make sure we have the right set of challenges of technical content for the community and also to

17. 8:59

    to have the right uh amount of support for the participants who want to join uh i've mentioned the dates already uh what i didn't mention and i want to detail a bit now is what actually stakehouse is and how structured we um we designed it as a sort of a competition where participants receive challenges technical challenges that they go through and this is the gamification of the learning process as they progress those challenges they get knowledge and they get skills around what it means to to be a validator to run a node to to

18. 9:33

    run it with very good um operational excellence to have monitoring to have everything in place so that you can be a reliable community member uh these challenges are designed to to help you with that to give you something specific that you can play with that you can experiment with and also to give you as the community is going to be around the program to give you the support when things are don't work as you expected

19. 9:56

    and as a new as a newcomer in the community you might hit some um some issues to make it appealing we allocated quite a bit of a budget to reward the participants that complete the challenges so we have a total of 4.5 million near tokens that are plans to be delegated to the participants the ones that complete the challenges at mainnet and also 250 000 in-year tokens that are going to be direct grants for bonuses um or special challenges that are going to

20. 10:27

    be part of this program um that kind of summarizes it i think i've covered um a lot of uh a lot of our thinking around this program uh as i said it started yesterday and it's going to continue until september 9th and it's going to be the best opportunity that that you can have at least in the upcoming period to get a validator seat in mainnet both from a technical perspective and from the perspective of the uh economical support that that you get

21. 10:58

    that you unlock by solving the challenges of um of the stakeholders program there was one question um someone had uh would chunk only producer data be available on explorer under chardonnet it should be available there okay uh just to clarify it it will be available but there would be nothing specific to trunk only producer basically will show up as a regular validator that um the explorer team is going through a

22. 11:33

    redesign of the explorer and i think they may add a separation of between different type of validators later on cool i think that's the only one that we have for right now but yeah if you have any more questions please please drop them and the in the q a box below and uh we'll get to them after the call thank you everyone uh josh can you also add um i see that i see that i'm gonna add them right now

23. 12:28

    is there any is there any action item for me right now uh no i don't believe so okay got it thanks okay so yeah i think we can transition to talk about uh i think pre-compiles for uh for potentially integrating ibc on here and uh yeah so we have uh folks from uh postal finance joining us today uh to talk about this work uh the the uh they are the ones who submit the proposal um and are doing the implementation work so yeah i just want to uh invite both uh

24. 13:10

    strong and uh brush to talk about their work uh yeah feel free to do i'll stop my screen share so that if you guys want to share anything uh feel free to do that yeah sure thing yeah so i just wanted to say that the components for our bridge from uh if you think of our powertrain which lives on polkadot to the near blockchain will consist of first off an airline client that is able to follow the consensus of the near blockchain um then of course the relay sits in between and is not a trusted entity but instead

25. 13:54

    relays state proofs financially proofs of both chains to each other and then the third component is a set of contracts that live on here that basically are able to understand the ibc protocol and will essentially be how we um submit proofs of our park chain data as well as messages from coming from apartheid to near so we have blasts who's actually leading that work and he wrote a set of

26. 14:25

    improvement proposals to this effect sort of host functions that will enable um signature verification of the polkadot authority sets as well as the tendermint authority sets uh in the case where near can also be directly bridged to the closest ecosystem asylum takeover and discuss the nep yes um so we have introduced the first nap that is 364 that is kind of bound to uh signature verification um but we also need another component that we will introduce afterwards that is mostly

27. 15:04

    related to uh certain hashing algorithms and a data structure that also we would like to see whether we can process that on chain or not um that is also a key part of the the ibc framework and essentially so far we have presented and kind of drafted an implementation as well is um two slash three because i i found that the third one is is uh easy to say it's already present as

28. 15:34

    uh with another name so i just put like a comment that's a bit like i'm unsure whether we should pursue that one or not but they're like two yeah signature algorithms um that we we would like to have uh present assault functions because um given the validator set size that we have and that might grow into we are not sure we can process all the computations on one transaction and we made different tests and

29. 16:06

    adding this with native code as it was also suggested uh comparing um different alternatives compiling uh how um you know it is done within the wasm code and how it is introduced us as a host functions we were seeing that we were actually like you know being able to uh kind of manage the the amount of computation that we need if they are introduced as host functions so that's that's the main reason for which we we're asking for for this change um

30. 16:42

    and yes and so far we we've gotten i mean interesting comments from from you guys we're trying to address everything um there's a bit of a of a part where uh some cryptographer on your side was mentioning um a potential issue uh that we would also like to you know support and understand how to how to work around this uh but but yeah we'll be happy to support on this as much as as you you need and and

31. 17:10

    see if we can get this done yeah so i guess yeah a couple of questions um basically you mentioned three types of signature verification function right ed2519 sr2519 and ecdsa should i could you maybe talk a bit about why you need all three of them yes so the um i mean we are we're trying to bridge from from polka dot into near and uh in that way is quite agnostic in certain ways it's like quite open allowing different accounts having different type

32. 17:49

    of keys and so this is uh this is what polka dot allows the type of signatures that you can you can have if you're coming from from polka so when whenever we need to verify uh that certain signatures are correct or not we need to be able to support uh these three schemes oh interesting so for even for visor signatures allows three different type of signatures yes oh okay that's uh it's news to me um i see and and and

33. 18:22

    but i'm imagining in practice it's not like it are all three of them used in practice so the thing is so the the poker authorities are going to be signing ecdsa signatures uh specifically the sccp k25 variants um but then like i said we also want to bridge to um the near blockchain directly from from rather the cosmos blockchains or the cosmos ecosystem directly from near um and those the people over on that side of the camp actually use

34. 19:01

    ed25519 interchangeably with srp5509 okay um i see i see i see uh so so if my understanding is correct um for polka dots we only need ecdsa yes and that's actually already supported right i think actually the actually marcel and kira might notice better they use it more often than other people um i don't i don't think it is actually it's called like i think it's called like ed recover or something like this and i think it is kind of behind the feature flag i was you know not entirely

35. 19:41

    sure uh so that's why i just put it there and with like a comment on you know if it is already done there and we can use it then i'm happy but i just i was 100 sure yeah yeah i used the essay as far as i know it's uh enabled it's it was enabled as a method api extension i think like approximately one year ago and yeah like the signature of the function it should be like easier color um yeah

36. 20:12

    basically it influenced the serum easy recovery i believe and if the polka dots using the same signature in and sync should work the same way right uh so i remember i think that at edwards uh adwords curve is not available as an european compiler right even though it's a validator signature right right yeah i was just going to add that polka dot is also going to be switching to bls soon but it's going to be threshold bls okay we might need to revisit the bls

37. 20:49

    api later on in the future but also commenting on all the other stuff we need i think this one is also pretty useful but it's the support for what are called child tries so i understand that the contracts already have well they are storage as part of the global state try um we're imagining a situation where a contract might need to maintain an on-chain try that is not itself part of the global try but instead only the root hash of that track can be included as part of

38. 21:22

    the global stage right so this is used for ibc where we have to set setting messages under specific key paths um in a trash in the tri structure just so that we can commit to the root hash of this try uh we can run you know verifications try partifications on whether some keys are present signified unless the messages are committed or whether some keys were not present signifying that there is a timeout can be fired for the counterparty chain

39. 21:51

    so i'm open to also like um visually sketching this out if need be but i just want to get your thoughts on this initially i i think um the uh the rainbow bridge uses like a similar uh construction right i think maybe uh kyrie or marcelo can talk more about that uh yeah this actually depends if we talk about bill's signatures what exactly billa's chirper what are you talking about for polka dots i didn't track which one uh are they going to use um so far for the bridge uh we need

40. 22:31

    bls 12 381 which is used by which will be used by ethereum on the merge on the consensus consensus chain like for the validators oh sorry accurate i think i think uh i was more talking about uh maintaining like a try as part of the smart contract ah okay good i think the rainbow bridge uses like a similar construction right ah yeah kind of if we talk about lifelines uh the thing that guys have discussed in uh this is quite similar to what we are crafted but yeah i see um

41. 23:14

    so like how does the the current how does it work for the rainbow bridge uh marcel do you want to wait because uh you were discussing a lot about this three other try optimizations uh yeah sure my internet is great but hopefully it will work uh so right now on the remote we're listening for two things but we are not representing that directly on chain we are only keeping uh the root for state uh

42. 23:55

    state recognition three and we have uh three also built on top of uh dark notes this is useful for making groups on the proof of work algorithm on ethereum but i think this is not completely useful for what you want to achieve for ibc if i understand correctly uh is that correct blast yeah i don't think it is i think it is it's like i said we want to maintain a try on chain um and we could actually do this

43. 24:29

    currently just using the plain smart contract storage to store all the different tri nodes but then in that case we'll be maintaining a try on top of a try which just kills every performance gain to be had there which is why we're pushing for this idea of a child trial that is basically isolated from the main triad but you know the root hash is still committed in the main in the main triad

44. 24:53

    and can you explain the motivation of why do you need to maintain a destroy well this is actually as part of the ibc specification for um ibc commitments so as you can imagine ibc being a message game protocol all it really defines is um you should commit to messages using this special try giving you know giving these custom tripods just so that a counterparty chain can easily verify what messages have been committed to your children

45. 25:25

    um giving by looking at looking out for the specific tripods um and i can put the link for the ics 23 spec in the chats if it's uh if it's very good because i think it's useful reading uh yeah please post a link but here is a suggestion i might be wrong i might not have all the details but it's a possibility that you don't need to have the whole try and train uh if i guess correctly the reason you need the whole trace because you need to build

46. 25:58

    the proofs but uh for the actual contract you only need to make troops and to validate the proof you only need you only need the root so for building the proofs i think you can use some sort of uh archival node or some sort of off-chain data that will help you like you don't need to build proofs on training it's not that we need to build proofs on chain it's that we need to uh how do i put this it the the track

47. 26:29

    itself cannot be off-chain if that makes sense i think marcelo the problem is that they have like uh those ibc messages that need to be committed down chain and the tri is basically built on top of that i haven't looked into that into the details but uh that seems to be the case yeah yeah i got it uh my question is if we actually need to have all the this one changed or not i can also share my screen showing you how we have implemented this on our powertrain because our packaging is also blockchain um

48. 27:12

    and we've basically implemented this uh ics 23 commitment scheme on chain using substrates child try structures which are isolated from the main tribe but and they still give us the ability to basically commit the root task of that tribe back to our majority um maybe uh you guys can give me permissions to share my screen oh hang on let me see what i can do okay try it now

49. 28:13

    uh um so let me know if you can see my screen we don't see anything yet huh it says it's running i can't see there okay okay i should try again then so let me know if you can see my screen now no i don't uh i don't know anybody else seeing anything i'm not no i don't know maybe uh try hopping off and back on the call again um or like maybe maybe i can share the if if there's a link or i mean if it's

50. 29:21

    something only on your laptop then yeah obviously you won't be able to do that if it's some link i can make sure yeah give me a second i will try to join in on my laptop okay okay cool um we have a couple of questions uh maybe we can answer real quick um someone's just asking so basically uh ibc will allow us to bridge uh to polka dot is that correct i mean you can bridge the pocolo without ibc um but we just believe that ibc enables for a more robust messaging

51. 29:55

    protocol in general plus it's already in production across you know the cosmos ecosystem has proven to be very secure awesome is there a github for ibc slash near project or the integration well we have a live client implementation from here that we've already put together our blast will put the link in the chat we've no comments to work on the contract yet because as you can see we're still in the process of researching what host functions we need to make this ibc contract feasible

52. 30:29

    um but yeah i think for now all we have is the like clients okay um and then are you actually building a near cosmos zone um i'm not really sure what that means matthias if you have um follow up to explain that a little bit more uh would be great and then for a message coming from a parent chain how many signatures will be needed to uh verify uh well how many signatures will need to be verified in a bls aggregate

53. 31:10

    um and a bls signature would just be one signature representing some threshold of the relay chain by later set um but currently the bls is not live yet so we're still using ecdsc and what that really means is spring springs yeah it's terrible that's okay uh maybe you can make my um you can make my laptop uh the part of the pilot so i can swap out of my ipod yeah no problem um let's see where um which uh i don't see my hands on my head

54. 31:56

    oh your hands raised ah i see i see you that's why you weren't uh you weren't a enough but a quarter all right now you're a panelist and all right so now i'm gonna allow you to share your screen so yeah i i would say an idea understand the question yeah that was from an anonymous uh person so yeah if you oh maybe this is a follow-up they're building a light client for subject change that can oh this is something different um

55. 32:47

    all right so let me know if you can see my screen yep we can see it perfect so this is one of the key paths for the ibc commitment try it says that whenever you get back acknowledgements and accomplishments are basically like if you think of the tcp protocol you send a message uh you get back in the closeman saying that this message from the counterparty train letting you know that your message was successfully

56. 33:09

    delivered um and so that has to be stored on chain as you can see under this custom path in the try um you can see so i've uh we use the substrates child tree implementation which allows us to do this from this fancy stuff and what that allows us to do is at the end of the day once all the ibc messages have been processed and the try has been mutated we can just simply call a function

57. 33:43

    to say hey give me the child root hash of this try um and then we can now persist this in our head uh as part of like um uh it's kind of like a consensus message so we can get like signature finality proofs for this ibc route so what that means is for instance with this acknowledgments that we've you know we've stored on chain the counterparty chain can know that we've we've actually received the acknowledgement and they

58. 34:15

    cannot time out for instance messages that are sent to our chains and there's other stuff in here we notice acknowledgements we have to store channels open channels just so that the counterparty chain knows what channels are open to them we have to store client states and if you are familiar with like client developments you know that this is the minimal states that a live client needs to verify incoming

59. 34:40

    headers from a counterparty chain um we also need to store connections which are the lower level which channels are built on top of um and maybe i can even open up the ibc spec just so that i can give a brief walkthrough for 24.

60. 35:12

    right so this is the host requirements uh it says that you must have a provable store on chain and it defines the paths these are all the paths these are part of the ads that are the ibc standard um and uh just to scroll a bit see what else they say well i guess that's basically it but uh this is just a general idea of ics-23 you have a try on chain that maintains these keypads and stores these these this pieces of

61. 35:49

    data um just so that we can be sure that like this these are the events happening on chain so any questions uh yeah i got the idea from here so yeah having a try and change makes a perfect sense i still will go with this documentation and make sure that this is the best we can do because if we can do uh something better than that let's strive to do that yeah uh uh just one one thought like the construction of the tri doesn't have to

62. 36:29

    be down on chain right or is it somehow dictated by the ipc protocol um when you see the construction of the try i don't so that i don't think that uh you have to construct a try on train i think that you can construct try off chain but from the context of ibc that tribe must act like a key value store where you can set some keypads with some values and you can but then at the end of the day we're able to get the root hash of this try

63. 37:02

    right so so if i understand the requirement correctly you just need to be able to get the root hash and also provide courage to certain keepers right yeah but that doesn't yeah but that doesn't mean that you need to do all the computation on chain right i believe one of the reasons uh why you're running into for example the smart contract constraint is like you're trying to do all the computation on chain like doing all the hashing and all that stuff um which it doesn't seem to me like that's

64. 37:33

    completely necessary okay maybe you can expand shade a bit more oh um yeah i mean obviously i don't have the full picture but uh you know similar to what marcelo mentioned before like you you can for example take some of the uh computation off chain and then uh you can put the result of the competitive down chain then uh people can can verify that the computation is indeed done correctly and if not maybe there is a way to submit some kind

65. 38:03

    of a challenge um that um to show that this competition is not done correctly like you have all the underlying data on-chain like people can easily verify that uh the competition you've done indeed is correct right so just to be clear in this case the computation we're referring to is basically how this off chain ibc tri is being mutated yep um so you're suggesting we build sort of optimistic system on top of that

66. 38:34

    um yeah kind of i see that uh that is way uh out of our current team possibilities at the moment okay but but i mean to be honest i feel like that's an easier way to do this right like you but i mean well first of all like i'm not sure whether we would be able to introduce all the all the host functions you want and even even if that's the case it sounds like you need um you want to do something even more than that and i i mean you just compare the implementation of complexity and

67. 39:13

    i'm not sure that's actually better like a easier approach yeah no i i get that it's it's definitely not going to be easy to add support for uh some sort of child try to near blockchain but this stuff is not just going to be useful for ibc alone um i think it's because we've not yet seen a lot of developer usage on here but as people start to come up with like very complex stuff they will need more complex apis

68. 39:45

    um and having an unchanged ride like if substrate didn't have this on-chain try we would not be able to uh implement ibc for for our power chain and so i think the same thing goes for for engineer as well like if you want to do complex stuff you're going to have to provide the necessary developer tooling for this um i mean i i i i mean i do agree with the last sentence you said but that but at the same time i feel like it doesn't necessarily imply that

69. 40:18

    uh you have to provide um all the uh all the kind of abstraction out there like i think i still need to understand better like what um like why why exactly you need this um thing to be done outside of the the main trial like our our developer model is at the from the smart contract point of view like it's it's basically operating on like a key value store like it doesn't really care how exactly the underlying content is stored like it from the the smart contract point of view um it is basically just interacting with like a

70. 40:51

    key value store like you have the storage read and write api to do that um and it doesn't really and it shouldn't actually care about how um things are stored on underneath because for example what if we change the uh the try implementation in the future like today uh this it is basically a markov particular trial but doesn't doesn't mean that uh we cannot change the underlying try uh how the how the state is represented in the future and and and

71. 41:17

    have kind of have the smart contract um operate on like a different abstraction level allows us to to do things like that yeah um i was i was going to i was going to say that i forgot knows myself um i mean the the reasoning behind trying to have a try is just so that we can like i said not abstract a try on top of a try i remember if you remember when this call yesterday was two days ago and i asked you if we are able to get the contract

72. 41:56

    storage route and you said that that's impossible unfortunately otherwise the contract key value store would have been perfect for this but the fact that we're not able to get the contract storage routes just makes it impractical for us to use it for uh for this try implementation and then like i said the other the only other alternative is to actually just use the contracts key store to maintain a virtual try which of course will store more intermediate nodes and everything which

73. 42:28

    is not really efficient as like i said in the beginning i see i see um well in that case it it might be an easier approach to add support for the the contract state root hash into the accounts then like then providing like some kind of separate abstract because you need to think about if you want to allow the account to maintain like a separate try uh well that's yeah that's like that'll be a lot of work that needs to change how the entire state works um

74. 43:12

    and i'm not sure whether that would be um well to to make a big change like that obviously needs not only just a lot more work but actually a lot more people looking at it making sure that it doesn't accidentally break other things and it actually makes sense for near as a whole all right i i agree if we're able to get the contract storage routes then we might not need to maintain an external try

75. 43:47

    okay uh yeah i think we're running short on time i do want to just uh still give some time to discussing this uh this bis uh proposal or or probably not proposed at this point but this idea um so yeah i guess kiro could you talk a bit about the necessity of uh supporting uh bis in the context of the upcoming emerge um yeah sure uh so um uh let me let me firstly describe what's

76. 44:20

    exactly needed for the merge and for the rainbow bridge i'll do it shortly because we are quite out of time uh so yeah um basically rainbow bridge uh how it works we use light plants on both of the sites so currently uh light line for ethereum is a lifetime linear which uh makes like work check and so this is the thing that marcelo described uh where we have all these diagonals and with this with the help of this we can actually recover to work

77. 44:54

    and on the other side we have a light client from here on ethereum sites where we optimistically verify signatures of near validators um with the merge uh this thing is required to be changed and we are currently working on this implementation of the light clients of ethereum with the merge so if i shortly describe how it will work so it will work in the following way um now we are going to maintain uh both

78. 45:26

    execution uh which is the same block as we currently have on ethereum and a consensus chain and consensus chain will consist of beacon blocks um so for beacon blocks uh on ethereum uh they have like a set of um uh committee uh which are like uh 512 validators uh that are assigning uh the messages um uh for the blocks like profile blogs uh so we expect to utilize the same thing and uh like the idea will be that

79. 45:59

    we will be submitting the blocks and then we will be verifying um all the internal data it's a conclusion of execution block within the beacon block uh but also we are going to verify the signatures of this committee and this committee is using uh bls uh signatures with a bls 12 381 curve uh and in this case we are talking about the verification of up to 512 um signatures uh but this this could be

80. 46:33

    aggregated due to the nature of the bla signature so we actually need to verify an aggregated signature of um and validators and and could be like from two-thirds up to five hundred well uh regarding uh who is voted and who's not and uh because of that we actually need to have a support of bls signatures so far we have been working a lot on the implementation of bls signatures as near webassembly contracts

81. 47:05

    because we expect that the merge most likely will happen before we have um bls signatures available as a near cost function um so far uh we have been trying uh with two libraries which seems to be like most promising one of them is pronational blast uh this is so far seems to be like um one of the robust libraries uh that we have on russ uh basically the library is implemented in c and it has rough billions and the second library is the malacca

82. 47:43

    bls which is implemented in pure us uh and the blast um the first one seems to be like more of us because it's actually has like a couple photos and a couple of more cryptographical this are ongoing so this is a good sign um also uh both these two libraries they are being used by one of the official uh consensus client reference implementations uh it's called lighthouse it's been developed by sigma prime with the

83. 48:14

    support of ethereum foundation um so yeah this is uh exactly where the choice we are um like striving uh either of these two libraries uh but uh for example uh we were able to successfully compile my live bls um as a near web assembly contracts recently unfortunately our first test showed that we are um not able to verify the aggregated signature because we are not we are actually hitting uh the 300 gas bonds and um

84. 48:45

    it seems that we are not closed at all because um we tried to um to be able to compute at least part of this verification let's say like tens part of it and we are still hitting these limits um for sure we expect that uh these libraries could be optimized uh in terms of um how would work with the memory uh so to adjust it uh more like uh within your uh execution runtime and maybe optimize it a little bit uh but in general it shows that uh it's

85. 49:18

    definitely a huge amount of space for optimization i have if we have this available as a near cost function uh so we will be working on this solution too uh because uh actually without without this bls signature verification that means that we need uh to use some kind uh of other things like either trusted mode uh to submit blocks or some kind of multisig or whatever uh this is to be discussed

86. 49:45

    uh but uh yeah in general the thing like this um and uh if we talk about uh these bls signature supports we are basically talking about multiple things uh so first of all uh i would say that we also need to have perhaps in your community will appreciate if we have like a general support of bls 12 381 uh signatures and then it also makes sense to actually expose uh the bls signature verification interface to zoom

87. 50:17

    uh because uh the difference here if we talk about uh for example this library which is the pronational blast which is implemented in c if we just um implement uh curses in your cost function uh that will that actually needs that uh all the client libraries that are related uh the bls signature on top of bls curve uh it will be needed to be modified uh with the using near those functions

88. 50:47

    and this i think will be quite limited if we talk about that c library with rough buildings um but uh if we do both of the things so both bls curve and bls signature verification uh that would be like uh quite useful and in this case i uh as i say i was not aware of this it's gonna be useful for ibc bridge um with polka dots as guy mentioned that they are going to migrate to bls signatures uh for the thing of um

89. 51:18

    generalization of what kind of behavior uh is required um for bls core uh we can actually utilize the existing ap which is the ap2537 uh so uh this is nip ap was proposed by um ethereum community because um these bls signatures they will be part of their consensus layer uh but they are not yet available on the execution layer as a precompiled uh however this ap was already implemented in uh ethereum it was uh just not applied yet um so yeah um

90. 51:59

    in general like this uh like three minutes left uh guys please uh give your questions and also i think that uh as we are going to work on this uh nap with this availability as a near first functions um as it's also useful for uh the thing that sean and blas are working on uh we would really appreciate your efforts and on this discussion and supporting us on this too yeah as cure like a question is like you

91. 52:32

    mentioned that you're going to maintain both the uh beacon chain that the execution chain on the uh on on the light client how does that actually work like is it possible to to only maintain like some kind the the beacon chain uh a slight client and somehow um submit like two set of proofs similar to what you do on the uh on the server side from here um i i didn't literally get your question uh do you mean why we cannot use the same model as we do within your

92. 53:07

    blockchain oh no i'm no more talking about uh uh how the light client for each serum is maintained on here uh it seems like you're you mentioned you're going to maintain both the the beacon chain and the execution machine uh yeah so basically in this case we need to maintain uh beacon chain because um uh obviously the validators they will sign the beacon chain and uh in this case we are not technically will be uh submitting the execution chain also on top of this uh but um i think how it works we are going to

93. 53:41

    submit beacon blocks uh but inside become blocks so we have a big block body roots and everything there like it's uh is a trees uh it's a tree and um then the beacon black body root it contains uh a hash of the execution block so we are going to build the proof that this is actually uh this execution block has been included in the beacon block um yeah so it's basically similar to how the light client uh only serum for near actually works you have like a

94. 54:15

    kind of two set of proofs um kind of yeah but still a little bit different on here uh the good thing that we can easily use this uh optimistic model that we are currently using because uh we can um reject and challenge and chain if one of the signatures doesn't match uh in this case uh this doesn't work for us because we actually need to verify the aggregated signature oh yeah yeah yeah i understand yeah

95. 54:46

    um okay sounds good i think we are running all the time so thanks everyone for the participation uh it looks like there's no outstanding questions at this moment yeah i think we're i think we're good thanks everyone for joining and uh yeah we'll see you all next month see you bye