ETHWarsaw Meetup 0x11 (#17) All things Starknet, Browary Warszawskie (13.06.2024)

[Music] awesome hi everybody uh welcome to e4o x darket uh me up we're co-hosting together with uh with saret team we're foro crew we're hosting biggest ethereum Focus conference in Central and Eastern Europe uh Eastern Europe or somewhere around that and uh we're going to go right into the today's uh topic of the Meetup so uh this time we're going to be deep diving into what's happening on saret ecosystem we have three awesome guests uh tonight so first off we're going to start with Dylan from sarin Foundation who's going to guide us through the culture of building at stet small round of applause for Dylan and then we're going to move on awesome then we're going back to our regular so marshel from Herodotus talking about how uh Cairo is not just starnet um another small round of applause and we're going to be we're going to be wrapping up with um the description of how starnet is getting to decentralization uh done by Miko bitki from never mind see you cut up with the a small round of applause for after after every person um and uh just to remind you why we're doing all of that so e foro is organizing a conference this year um beginning of September 5 to8 uh happening in that particular location so we already know the venue um it's going to be two days of conference and two days of hackaton uh it's if you were last time you know it's fun if you want to come again uh we'll more than happy to host you and for the new ones uh remember that we have the early bird tickets on sale right now so if you go to our website you can get the um T tickets for a lower price and without further Ado because I'm starting to go red which is always uh a sign for me to stop talking we're going to go to the first presentation so a bigger round of applause this time for Dylan come over here and we're going to get you set up we have one normal profile picture um and it's not mine perfect hi everyone it's uh great to be here in Warsaw I'm Dylan from the starnet foundation and I'm here to talk about Stark net uh over the next 15 minutes we'll be talking about what starnet is um how we differentiate and I'll highlight some of the innovation ongoing so people often ask me why they should build on stet and it's pretty simple first thing is cheap call data cheap and Powerful computation and Native account abstraction together these form a highly scalable solution backed by mathematical proofs called Starks that ensure verifiable and correct computation this forms a backbone of what we call the Integrity web in uh resolving the need for inclusivity while enforcing a broad social consensus again all enforced by scalable and transparent proofs but it's not just about the technology our community is a big reason why people build on Stark net it's extremely collaborative it's extremely active and people here love to experiment you're also willing to help especially if you have an idea that's fairly unique before we can get into why Stark net or how Stark net differentiates we do need to understand the core issues on the L one and understand what this uh what ZK rollups are actually trying to solve some of this might be a little basic so bear with me for some people but to get a little idealistic the core issues of a blockchain are about one accountability and two inclusivity that means anyone can join the network and anyone can participate in the network theum has done a pretty good job on that but there has been tension as it tries to scale while managing while enabling users to actively participate centralized entities have it pretty easy they just get bigger and better computers but de centralized entities like ethereum it's quite difficult uh ethereum has tried before the L2 sh has tried increasing gas limits increasing block size but it's costly and it excludes people from the network so how do we solve this we'll get into that soon but the reason why I'm bringing this up is because it's all about cost every interaction between a Dap and a user needs to be verified by every participant on the ethereum L1 so when you do a transaction you are paying for not only your computation but also the computation that comes after you for people to rify and resync the network over time we solve this with validity proofs to scale eum and offer cheap computation so instead of reverifying the entire interaction from scratch saret offers these validity proofs that attest to the Integrity of the computation verifying this proof is significantly easier cheaper and faster than reverifying the original interaction again this is huge because it saves a lot of money for gas and also improves through this is extremely important and an absolute game changer for developers of all projects but particularly for app Developers app developers care about building a cool project but they really care about getting users and users are price sensitive they're not going to go and play around on a new app if they're paying a ridic ulous amount of fees so we open up the door to for cheap computation for more users to test out your app but it goes beyond that with powerful and cheap computation app developers can add more complex features to their applications and actually expand what is possible from an uh from an app development standpoint so not only do they get more users they can build better apps to get more users and I think that is kind of huge to understand that we are taking away the restrictions of the evm on Stark net and we'll get into some of the differentiation a little bit later with Cairo and uh yeah I mean starets we're growing pretty well we're one of the largest ecosystems by full-time developers this is a chart from Electric Capital as of December 31st 2023 um you can see Stark nut's the only only prodject in the top 16 that has a green in the growth for 2023 that's a good thing um it kind of shows the resilience and growth of the Stark Community um you know we've been accused we are very Builder first we've been accused of being too developer focused but the numbers speak for themselves and people like building on Stark net because we have the single best stack we building complex and unique applications period And honestly so like this is just a microcosm of our ecosystem there's a lot here and frankly I can probably name 70 other projects within the stet ecosystem uh literally I've given out 64 grants in the past month and a half we'll get to that soon there's a lot of things building here this is not all of it but this is just some of it this is a lot uh and we have everything from infrastructure to cool and unique applications and that's because of Kyra CET is not evm compatible and it's been purpose built because we are optimizing for performance over compatibility with the EV we use Cairo uh which is a provable programming language um for validity GRS provable program just means uh you create a proof rather than that doesn't need to be re-executed by all the people on the network this proof is basically the validity proof that attest to the Integrity of the computation and kind of in cont to solidity which is built on the evm Cairo is built on the Cairo VM there's a reason for this because ZK rollups require a completely different architecture than is necessary on the L1 with evm based on ZK circuits that means that compatibility with the evm is actually a performance compromise which is why Stark net decided to build an ecosystem completely independent of the uh evm and yeah I mean Cairo is pretty awesome uh you should check it out and it's actually kind of cool because we call this the Cairo filter if you are building on KIRO you are probably a unique and special Dev uh every Dev in saret is unique and special but EV but especially you know the ones that are pretty good at Cairo um because we're not evm compatible it does kind of create this new these kind of side effects and it's been kind of very important for the social identity in in saret um really you know people in saret I would say like our average developer really does think from first principles to actually leverage a powerful and cheap computation that Stark net is actually able to offer I'll get into some of these things because it is quite a fascinating area about the culture that we've built in saret so the first kind of side effect is this motivation filter there's no point in building and learning on learning Cairo if you're just building a lowquality project if you want to copy and paste your product to the hundreds and hundreds of l2s out there and the hundreds more that will be created eventually just there's no point in building on saret so the back the point I'm trying to make is the projects that are actually coming on board the developers that are coming on board are actually building interesting applications um not lowquality projects so that's a motivation filter the second side effect is the fact that the evm on the L1 is not immutable this means evm changes and will continue to change over time so if you are a pro uh uh building on an L2 a ZK rollup that is evm compatible just know that the compati evm side will change because it's not immutable that means you will continue to have to go through maintenance uh update your code base so that you can maintain composability with evm that just adds maintenance burden to what you're building and then finally we have fragmentation so I kind of like to think about ZK rollups on a spectrum so on one side you have extremely compatible with evm and on the one other side you have not compatible at all with evm so start um ZK rollups exist across this spectrum with different projects having different compatibility with EVN so the developers that are launching and pushing it to all these different l2s will have to deal with the fact that there's minor code differences for all these ZK rollups and this fragmentation is going to continue to get worse so these are just a few reasons why it's just better to build your own ecosystem beyond the powerful computation side but reasons to build your own ecosystem independent of the evm and that leads us to freedom to innovate um again Cairo VM is optimized for performance and security whereas Cairo the language is optimized for ergonomic programming uh it wasn't easy building a ecosystem from scratch uh again independent of the evm um but as saret has evolved the tools and infrastructure has matured and stabilized as well and now with the unique features of Cairo on stet specifically we have really amazing developers coming on board to build cool things and really innovate and uh here's some of the Innovation um my Innovation is I create Drake beames um but yeah we'll start off with fully onchain games I was uh chatting a little bit earlier about this um but it's sort we have a ton of games being built up in the stet ecosystem I find this extremely cool not only as a gamer but as a person who loves crypto so historically web 3 games have suffered because of various aspects we can get into all the details on tokenomics but uh from a technical side they all they did was store assets onchain and kept all the game logic offchain in a trusted environment uh now with cheap and Powerful computation afforded by SAR Nets we're seeing developers actually build fully onchain games that means they're not only uh they're pushing the game logic in a smart contract on chain where we can actually manipulate the game data uh the game assets to in a trustless environment this is kind of cool because it solves literally the composability elements that ballic was talking about when he decided to think about a decentralized ecosystem like ethereum for his World of Warcraft weapons uh so that's gaming we are supporting a ton of projects in that space if you are interested feel free to talk to me about any of these sectors too but for defi um okay I did include aubo um aubo is one of the most efficient uh dexes out there uh Avenue is an extremely smooth smooth aggregator um and they actually release his pay Master to abstract away gas fees then we have uh Giza Leading The Way with zkl we have Herodotus uh as well uh for storage proofs to access past current and cross-chain ethereum data we'll have a chat with from him later today uh I think I missed uh open INF open infrastructure um open source code infrastructure for for for app development with Madara Kakarot is building a fully compatible evm rollup leverage and Cairo and then we have our wallets and tooling side which is extremely interesting as well because all of our wallets are smart contract wallets so Argent and braavos can use that and create actual really Innovative use cases within the wallet to allow social recovery or capping of spending limits so I think this is really cool and I'll double click on AA account of action not Alcoholics Anonymous uh on this slide so just very quickly usually you have two types you have externally owned accounts uh which are usually wallets and then you have Smart contracts um on saret all accounts are smart contracts and this is really cool because it allows for increased customization and increased flexibility for the developer what I'm super excited about is what we can do with account abstraction with regards to user experience and actually creating and forming some social constructs that we see in the web 2 design space and then yeah um we as part of the stet foundation I've been kind of very proud to be involved with some of these initiatives uh that we've been releasing over the past few months I think it's been incredibly rewarding for me to work with the teams to support them and get teams to build on stet so just here's a list of just a few of the things that we're doing um we have a lot more in the pipeline but the first one I want to talk about is seed grants these are just small grants of 25k for MVP type projects um then we have Catalyst which is initi an initiative that we released over the past month uh where we actually had a 20 million starc initiative to distribute to our top daps within the Stark Knight ecosystem uh I'm working on this program called propotion uh which is a gaming Initiative for 20 selected saret games for up to $1 million each that they can get based on gas usage um we're going to be announcing something next week on that so keep your eyes peeled it's pretty exciting uh and I just want to double click on the SE grants program that's a lot of money right there so we actually released on May 7th so a little bit over a month ago uh with 20 projects in a pilot program and we actually crossed a 200 applications uh as of yesterday uh with that we have approved 64 of them and distributed $1.6 million in a little bit over a month and this is not going to stop anytime soon uh this cant program is for MVP early stage projects use cases vary but uh it's really about leveraging and you know supporting some of the really experimental and exciting projects building in the Stark net ecosystem at the early stage level these are projects coming from hacker houses hacker th and uh you know we want to support the winners of those um and it's pretty exciting but the key thing to take away from this is if you are an MVP or proof of concept project if you are active in the saret community and you plan to build using existing saret tools then you should apply for a C Grant um and uh oh actually before getting into the thank you slide uh with C grants catalysts and some of the other programs that we mentioned on the I guess two prior slides from now um from here um we will now and major upcoming program which will be more suited for established Builders we will have a program in place to work with any team or any size developer team that wants to build on stet so be on the lookout for all those things we have a lot coming so just come build on startet um you know see what you can do experiment we love to see it and you know if do you have any questions I'll be here after this call after this uh chat thank you we have time for some questions if you want to ask them or you can ask Dylan after the um uh after the Meetup and by the way there's a stark hack happening right now right yeah but I think the submissions are already closed as you can Jo okay so marel come up okay yeah let me [Music] see I find it offensive that this kff has water it looks like a car for whiskey or something and we're going to amend this for next Meetup what I'm just trying make it slightly [Music] funny please work yes [Music] so hello everyone my name is marchalo I'm the co-founder of her auditus and today I want to talk about like why Kyra is different than Stark net and why you know you should not associate the language just with a rollup you can do like much more than just wrm contracts and I want you I want to convince you why you should do this so um for some contacts we use Kyra a lot at her audit for a bunch of good regions um yeah and this is why I wanted to convince you why you also should the same but maybe for context also first off Dylan thanks a lot for this amazing introduction to a lot of topics that I'm going to talk about so what we do at Horus we develop storage proofs that allow you to write smart contracts that access historical data and also like cross chain ethereum data so you can build like amazing stuff such as snapshot X Kyro on the other hand I feel like it's a super Mis used word it means the language virtual machine and a lot of other stuff but today I'm going to explain that and the MiFi a lot of myths all right so where is Cairo and where is stet so CYO is a language that allows you to write SM contracts on starnet but most importantly it it's a language that allows you to write provable programs starnet on the other hand is a zik rollup which is implemented in Cyro to which you can deploy applications also written in I call it a different dialect of Kyra but yeah these are like two separate things and I we'll get into that today so um first off like a mental model behind provable compute for those of you who don't know maybe first um whoever is a developer please raise your hand oo nice um all right so um provable compute the idea is that basically we can make a claim um like a statement which is made of like some computation that we Define with like for example Cairo then we take some inputs we can have like some subset of these input that are private I will explain what are private versus public inputs in a second and finally given this inputs and that com. program we get some outputs this is basically the statement that you want to that the verifier wants to convince the the sorry the approver wants to convince the verifier about given like a proof so inputs um we have public inputs these are like visible to both the prover and the verifier whereas private inputs are visible only to the prover so they're not like leaked to to the verifier which is pretty important especially in the context of like zik roll but we'll get into that awesome so finally we have this protocol where basically the approver generated proof provides it to the verifier most likely the blockchain and we have some checks that are by the way probabilistic um and we can reject or accept the proof that's the that's a mental model you should have behind any provable computation but you can express this computation like many ways so let's talk about it so the OG way just use circuits but there's a lot of reasons why you should not use circuits today um but yeah there are like three main trucks first circuits then Z kvms and then finally transpilers um so circuits circum for example tornado cach is implemented in that you have gar you have Noir Socrates like yeah pretty old stuff and on the spectrum of like Z kvms you have Kyro is a zvm you have P1 from sxin you have risk Zero from risk zero you have erra VM as well and finally uh transpilers um so far I can mention one there is like the one built by Neil Foundation which given some llvm it's going to generate you like a circuit so now why Cyro first off writing circuits is hard and slow like really slow it takes a lot of time it's pretty complex oh perfect writing circuits takes a lot of time it's pretty complex so it's expensive to audit them and the goto Market is like slow so if you don't have to write circuits please don't um so let's talk about Z kvms so virtual machines basically you can have some instruction set that you can execute zkm You just prove the execution of that you can have like commonly known instructions such I don't know risk like jvm um misp misp okay anyways um but the problem with them is that they're not ZK friendly why because they were not designed to be ZK friendly um on the other hand Kyro was designed specifically to be ZK friendly and that said you know the Gap will get bigger and bigger and bigger because Kyro will keep being redesigned to be more and more Z friendly whereas brisk will be just br um now KY as a language uh you have a brass like front end so it's nice it's usable and finally in my opinion it's the most important uh property of CYO you have one owner of the stock like starware is designing you know the language the compiler the VM pretty much everything and this results to be like very good properly property historically uh just I guess a lot of you use like mag books iPhones you know Apple owns pretty much the entire stock and that resulted to be something amazing so um yeah that's a very good reason so now I want to walk you through like the entire pipeline what's happening you know when you use Kyro how you go from the language to to the actual execution and why this is different than Stark and what type of stuff you can do and then what actually stet is from a more technical standpoint so so step number one we write some code we express it in like Kyra so again it's a provable language uh that allows us to wrap our computation like a stark proof and prove its validity in the end so we write that code looks or crust then we pass it through the compiler we get something that is called Sierra Sierra is an intermediate representation but this is like optional this is very specific to Stark net maybe let me explain why the reason is that when you prove some program you want to prove its success uccessful execution but in the context of blockchains you also have reverting transactions right so how do you prove that the transaction is reverting and also why you want to prove that uh well there is a very good reason it's like DS right what if as a sequencer you just keep receiving transactions you execute them and then it turns out that you cannot prove that they're not successful like someone can just attack you on purpose uh it's a huge problem especially if you want if you want to decentralize a network so we have this abstraction layer called Sierra which basically allows you to prove that hey that transaction is is not provable like it's it's just going to fail um this basically gets compiled into car and bite code um yeah so I speedrun this uh this slide where when need Sierra from bite code we just execute it with the Kyo VM um this generates like a trace and finally this Trace needs to satisfy something that we call the the air so alpr intermediate presentation really specific to to the proof system and if these constraints are satisfied okay I think you can see it's pretty much the same the same slide we are able to generate the proof so where's stet but maybe first what are the applications of all of that so application number one back in the starx days you could build stuff like diversify you could build stuff like mutable like the ydx um pretty amazing applications but you have use cases kind of off the purely blockchain use cases one of them is like Giza where you can prove some machine learning like inference um like linear regression and models like XG boost and a lot of other amazing stuff and you can like prove the inference so you can prove that you properly executed some machine learning model pretty pretty cool and also we have uh something that we developed it's called the data processor so you can take arbitrary historical or cross chain data you can express some computation that needs to run over that data and we can just prove it generate a proof and that's it and this can be applied to pretty much any use case where you want to convince someone about some claim you don't want to reveal the information or you don't want the other party to reexecute that and you can use Kyro for that so where is Stark net then so Stark net is pretty pretty much a program that is able to maintain its own state which we also call a rollup um so here what the claim is and I mentioned also previously that they will explain what are private and public inputs so public inputs are these that are visible to both the pro and the verifier um and the private inputs are only visible to like the Prov so how does it apply in the context of like rollups um as probably many of you know we have like ones at post State differences and entire transactions uh to the chain and why we can choose between those it's because maybe specifically to to to to ZK rollups why you can post State differences is because you don't really need to see the entire list of transactions to then be able to reexecute them you can just say hey there was a listed transaction that satisfies this program that represents rollup I executed that correctly and here are the stades you cannot do this type of things outside of ZK rollups so you can prove pretty much this type of claims and you just show that this transition the transition from like this state route to this other state route is valid pretty cool so this is star net you can also run like smart contracts on top of that because again we have a VM which is able to run anything and um yeah that's uh that's it so now our contributions to like the KY ecosystem so we developed storage proofs so again you can WR smart contracts that access historical and also crouching data and on top of that you can build cool stuff such as snapshot X um we also developed a verifier on Stark net Ford so just take any chyro code prove it with stone which is an open source Pro developed by starkware then verify the execution of that with Integrity on stet which has been developed by by Herodotus um you can also do privacy on starnet using like Gaga or finally use the data processor and thank you now time for questions we're going to have time for questions after that as well unless you have a question for yourself then there okay we're good um thank you marello and uh let's move on to our last presentation today uh M stage is yours just to keep you interested for that Stark has provided t-shirts in various different sizes which is not very typical for a conference so we have uh we're going to have nice merch out there in the Foya um after the conference and as usual drinks and pizza and uh fun networking but don't escape just yet and don't steal all the t-shirts [Music] my ha yeah all right good evening everyone and thank you for being here thank you for having me here uh I'm mik biski I am from nethermind um an mind is an organization which has been quite active in the ethereum space since 2017 um we are quite proud of our another mind client which is like the ethereum um client um which by the way for the record has been mostly developed and is being maintained mostly in Poland and we are quite proud of that um but we are also quite active in the Stark net space and um we put a lot of effort into developing components of Stark net from its core components we have a full client implementation um in starnet to developer tools um to um uh user applications like blockchain Explorer etc etc um and well I'm here to be telling you [Music] about actually it's a funny title and so already suggest something and um I was recently rewatching Mad Max the Fury Road and I felt it was quite actually appropriate for um this um this this presentation and so can I draw you into a bit of an interaction and um does anyone know how many nodes are there in Stark net blockchain Network at the moment one any other any other attempt okay 100 any other well I would say zero at the moment and that that is true let's just admit that right um Stark net is is operational um it is a layer two as um we already heard today um it is a validity rollup um but at the moment it is pretty much Central uh the current architecture um includes a I will show it in a second but I'll just list it um quickly it includes a centralized sequencer a centralized prover uh that is maintained by starkware um there is a single mle and well that's really it so the big powerful um set of features already available in starnet are mainly due to its stack which has been um displ described today and the chyo stack and the whole um Stark crypto system these are the functional features of Stark net but Stark net is not yet decentralized so um the idea of the layer two is to uh what we call it recover um such aspects of a blockchain system as liveness sensorship correctness immutability at the moment we have correctness um due to uh due to the validity um uh rollup system we have immutability because the everything that's happening on Stark net blockchain is checkpointed on L1 uh but we don't have liveness we don't have um sensorship resistance so I mean and you can um see that also l2b they are um they are rating it quite aptly um by um rating the the state validation data availability aspects of Stark net as well green we are pretty much there but um the liveness um is pretty much undermined by the ability or the possibility or risk of sequencer Andover failure um and the censorship um they um focus on the exit window um from the from the from the blockchain um that's one of the aspects of of lack of sensorship resistance at the moment so um the fact that starkness development started uh with the functionality first first was a conscious choice and um right now we can say that it is functionally um robust and quite mature um and developer Community seems to confirm that uh but we still have a lot to catch up on when it comes to the decentralization when it comes to liveness uh we will need to get to a point where the stet network will run on a certain level of decentralization the central level of um of multiple notes running in a in a network uh when it comes to sensorship resistance well basically the operation and the composition of the validator set of the network will need to be controlled from L1 and this is where we will say we will have achieved sufficient sensorship resistance so the architecture of stet is pretty much this at the moment um so as I said there is a single mle contrary to that diagram here here there is a single mol there a cal centralized sequencers there a central approver as well all the transaction requests are filed into the mle gets processed by the sequencer the blocks get then proven I.E the proof for the block is generated and then submitted to a verifier um the logic of the verifier is implemented on L1 and the very successful verification will then stamp the outcome come of the um of the block on the start core contract on L1 as well this is where the state divs are stored um as blobs this is where the proofs are sort in the cator so to get to the decentralization uh we will need to I'll just start pointing fingers uh we'll need to get these mles sequencers and provs we need to get them Des well need to get them implemented in the actual full node implementations so we can remove the central um sequencer mle and approver and we can replace them with the network okay um okay so you may actually ask but we have already um full Neal Gateway um against ethereum um and they are at the moment serving the API into St so in fact in order to communicate with Stark net you need in order to integrate with Stark you need to communicate with an RPC interface Expos by a full node client um this also means that in order to submit a transaction in stet you need to send a request into a full note implementation uh but that request will be forwarded to the central sequencer that's really it okay so how do we how do we how do we move on the uh first dependency here is the ability for the nodes to communicate over the P2P Network once we have that uh we'll need to decentralize the sequencer and for that we need to implement a consensus protocol so the first stage or that the next incoming stage is the P2P and the stable P2P implementation the next big stage is the consensus implementation so first we need a consensus protocol to be designed and then implemented um in parallel we are actually working on on scaling which a lot of the scaling improvements can be um done let's say orally to the P2P and consensus uh implementation so I will I'll just say a couple of words about that as well um right anything right so where are we with all that uh in terms of P2P at the moment uh there is an already stable version of the P2P specs for the messages in the P2P Network and the spec also assumed that implementation is based on lip PTP which is a fairly known standard in the crypto space um the implementations of the fulln client are pretty much well advanced in implementing the syncing logic and Juno for the record is now capable of syncing the blockchain content from a network of Juno nodes so so internally Juno can sync uh We've now been working with Pathfinder team to ensure the integration between Juno and Pathfinder and literally last week this has been confirmed in a sense of we are now able to sync Juno and Pathfinder notes on the full of sepolia network on stet um the progress is quite steady and this gives us pretty much the ability to soft commit to being able to launch a P2P test net in somewhere in July hopefully and that would be between between all the um client implementations so that's where we are with with the PTP um by the way uh the syncing algorithm that we are working on is a fairly naive one but it's still effect Ive uh in parallel we are also working on on something which we called Snap sync I mean some of you may know U this is one of the one of the features of another mind client which has the ability of quite high performance internal syncing of ethereum um and we want to implement the same thing in in Juno so Juno will have snaping and hopefully well hopefully well uh once it it works we will probably be proposing to implement the P2P features of the snaps sync into the actual official specs so that other um clients can also use snaping if they want so once we have PTP the consensus is the next big step and this is where we are less Advanced let's say so um the work on the consensus protocol design is pretty much driven by starware um with uh close collaboration with informal systems and never mind um this is where the specs are not yet designed not yet written but a discussion on proposals on for the consens protocol are public I mean can be viewed on the community forum and well it is still quite hot the discussions um but there are some assumptions which I think are valid at the moment so one of them is uh the initial version of the protocol will be based on tender because it is pretty much btle tested and um um we assume that stet will be a fairly small Network so um tender Min consensus will not be a bottleneck um tender Min gives us immediate slot finality which is benefit uh when it comes to like further processing and we are aiming to to um to support me and me on those um let's say single slot final finality enabled protocols is quite well developed and researched for now so um this is in contrast to D based protocols like direct classic graph um where m is not really well researched and not explored so tendam is a conscious choice but we definitely are looking at dag based protocols as an alternative as an subsequent step um So based on vanilla tender we are designing or discussing additional features um there is the need to be able to throttle the blocks that's because I mean going deep deeper into into the details the block execution step is in general different when it comes to computational effort than the block proving step so there may be a mismatch or misbalance when the notes are processing blocks and we may need to be able to control that we may need to be we may need to hold back some of the block propagation so that the approvers can catch up that's that that's the the reasoning behind it um and there's a couple of implications which will still need to be need to be designed let's say so we know that we are discussing proof chaining and parallel proof um um proof computation let's say which will need uh we need to have the proof aggregation mechanism designed etc etc so in all this there is also the discussion about how staking will work uh within this this consensus protocol and again this is quite an open design space at the moment so this is not yet settled not yet not yet decided so when I was studying about the possible timelines for the P2P I was giving July um in here I will not yet commit to any any timelines that's months ahead realistically and when it comes to teams I mentioned uh three teams in like involved in in this design and implementation uh in parallel in NE mind we've uh kicked off like the Baseline implementation in go that's I me of Thunder that's because Juno is written in goang and we want the whole stack to be implemented in Golan for efficiency so that's where we are we are at this stage when it comes to the Juno implementation now few um improvements on this scalability or like the volume of stet at the moment um for uh for convenience U we tend to use the erc20 transfers as the performance met metric so for Stark net this is on average about 40 like transactions per second Max recorded was 52 and we definitely want to go over that and there's a couple of ideas in progress to improve that we are working with with starkware on the parallel transaction execution uh which will pretty much give us Improvement between four to five to to eight times and there is I mean Mel was was telling about the chyo stack um I think he didn't yet mention the Kyo native there's a there's a concept there's a there's a there's a library and a mechanism which assumes and allows for compilation of chiro code to Machin native code ahead of time and that in experiments had shown somewhere between 20 to 200 times in like in efficiency and performance Improvement so we are working on getting that integrated in the actual blockier part of the sequencer and the effects will be uh will be combined with the parel transaction processing um at the moment Stark net is also going through the process of shortening the block times the current block time is 6 minutes per block we will well we will startet will shrink that over the next few months down to 10 to 20 seconds per block on average and that's that should be like no-brainer that should be quite easy with these other improvements implemented uh it should be able to go down to between two to 5 seconds per block and almost like immediate block confirmation on L2 um so if you combine all that well by the end of the year we hope to have about 500 DPS and that's a very conservative assumption um so yeah and guys this is all happening and this is all or most of it is actually open um and open source um so anyone really anyone is U able and you know invited to contribute to it and if you're an individual contributor a developer um these are the ways to to join you can either apply for roles we have a number of open roles in nethermind there are discussions on Telegram and Community forums which you can either read and or contribute to um there is an intership program which in the mind uh runs um and that's again another way of getting exposure on onto this and there is a regular Stark net cordev meeting U online which is open and anyone is invited to observe the progress and discussions um so that's for the individual contributors if you are an organization interested in getting into this space uh probably startet Foundation is the best point of contact I mean we as another mind we are happy to help you in getting um in contact with the foundation um so yeah that's where we are so you've you've seen the numbers you've seen the timelines and yeah thank you for for your patience and thank you for having me we have time for questions okay okay okay yeah hello hello so my name is Stefan you just mentioned uh that you are considering about using transaction uh parallel transactions yeah so like any evm chain like logic in evm chains that uh transaction in evm Chains goes one by one and if you are um considering using parallel transaction you are considering to go in asynchronous model so such for example such a venom venom chain TVM y okay so uh how would you describe your positioning on transaction or on paralleling trans action that you just mentioned uh without without or I'm sorry are you going to became an sronos or still so right right now the design is all around the the concept of transactional memory and it's basically an optimistic polarization we you can execute transactions in parallel as long as they don't interfere with each other one way or another and that way you just need to roll them back roll them back in the in the sequencer and execute them in SE sequence yeah indeed I'm sorry there was another question y so uh how many how many nodes would you aim for when you're trying to decentralize um so we expect to have around 50 active sequencers cool are you trying to decentralize both the sequencers and the provs as well yes that's that's right and would the idea be each each node would run both of those that's correct okay cool and then one mol no no no each of them would be a mol as well mle as well mhm neat cool um so you mentioned uh snap sync right and correct me if I'm wrong but this should be fairly easy to do since you have snapshots on etherum layer one right like State snapshot do can you can you tell us more how how how how do you plan to design this so snaping does require the nodes to be able to respond for certain ranges of that tree right um and this needs to be implemented in the protocol and in the noes themselves we wouldn't be syncing from L1 yeah I get that yeah so so I mean that's about as much as as but uh so snap sync Works in a way that you can sync just a part of the tree that's correct correct okay because also like I assume you could just download the whole tree uh from another node or from ipfs and just compare it with the hash that it's on layer one right that's that's correct yeah that's exactly right and then I have another question because you mentioned the you know the the some ways that you're going to improve the performance of the system but you focus only on the execution part which was surprising to me because uh it seems like it's not the execution that is often the bottleneck but more like you know memory constraint that the state that it's like ever growing right and sure you can have like you know thousand DPSS by the end of the year but in two years it's going to be lower because of like you know memory access uh constraints and and that is a very valid question I mean in my team's research we've been focusing on the execution INF extion first so so the memory performance aspects we've left pretty much um and so thank you for raising this um if you would like to deep into this deeper I'm happy to put you through to people who are smarter than than myself in my team awesome do we have anything else no so so how is how is NE mind L1 client going pretty well and updates last week perfect perfect uh so you were saying that uh the consensus protocol is not designed just yet is there any chance that uh the proof of stake of consensus mechanisms can be used for that uh so I mean okay if I wasn't clear about this so the the consensus protocol that is being designed will be a proof of stake um and there is a discussion on how the staking will work etc etc but again that's fairly early stage and some of that I'm not really to reveal yet but it will be there will be staking there will be the whole um so environment of staking in stet as well thanks one more are you already start to selection the node operators or the validators that's not within my area of of responsibility let me say that thanks cool do we have any more questions okay one more okay but this one is the last one so you mentioned you'll be you'll be using tender for consensus and correct me if I'm wrong but I think with the tender's bft you need two3 of the uh that's correct like validators uh in order to produce a Bo and if onethird of them are offline uh uh the entire chain will actually stop um how big of a risk is that to the entire like say Stark Network and if there's like any kind of book arounds for example is it possible to retrieve the States from some other like da layer or yeah it pretty much is possible to rebuild from L1 um the well so we are taking tender with its security assumptions as it is just to focus our thinking on adding layers on top of Ender so I mean what you said is valid we don't really have any specific um angle of attack to to tackle this we just take theit with its benefits and drawbacks thank you awesome thanks so much uh thank you a big round of applause and nice so that's for that's all for today uh please head now to the little Foya so it's there and to the left you'll find drinks and pizza there and come over Network and remember you can get e foro tickets already at a discount price it's one fit if you want to volunteer for the conference and work with us get like nice fancy t-shirts like that uh come talk to someone in green if you want to apply as Speaker as sponsor or some kind of partner also talk to someone wearing green if that's a different shade of green don't talk to them and that's it we'll see you probably I guess next month for another Meetup and thanks so much for coming and have fun [Music]