Development Updates: Ream Client

Transcript

Um, hi everyone. So, my name is Anna Wood. Uh, you can call me by my Thai nickname as well. Um, that's O. Um, so I represent RE team today. So, I'm the coordinator for RE team. Uh, we have a few members uh, Kobe, Jihun, and Jun in the audience as well. So, feel free to to come up to us to to discuss more. Um, just quick update. So, basically we are labs. So, we are globally distributed rust based. um main like primarily focus are is on uh building the beep client. Um we have three tracks of work. I'll mention a bit a bit more later on. Uh we are globally distributed as I mentioned uh because we are living in five countries across all most most continents. Um Jun and Jun are in in

South Korea. Kaden, Kovi, Chi and Patilius are in Canada. I'm based in Bangkok, Thailand. Verun is based in India. Para is based in UK. So very like globally distributed. Um there's a few channels that we you can follow us um GitLab um Twitter uh hackmd and also telegram. Um so yeah so I just want to start off with our road map when we started off our team um early 2025. Um so we basically thought that you know beam spec is coming up um it's a year um from from having a beam spec. So maybe we start off something sim simple and you know something that is manageable.

So we were focusing on okay maybe our first milestone would be P2P second milestone would be CK transition proving and so on and so on right pretty basic pretty straightforward uh but after getting a few months into the into the the the progress um the scope got much bigger um so we are now basically doing about like three tracks the first track is bu basically building a a minimum ream beacon client um implementation um the second track is um prototyping beam features and our Third track is basically creating beam awareness and go go to resources and also like talent building in terms of like protocol engineers. Um so track one I think our main output here is our ream client. So

it's a rustbased minimum beacon client. Um our objective here um three prongs. First is uh we use this codebase to train up new consensus client um engineers. Um it's also the test bed for beam chain features. So a lot of things that we are experimenting with you know the the beam specs or or the research that are coming out will actually require some code base to to test against. So so this this um beacon code base helps a lot. And thirdly we could potentially use this during the actual transition or the actual hard fork that could happen. Um we could potentially use uh this code base as as the one that has been running as well. U our progress so far. So we have developed the full

beacon STFs um up to PCRA uh a lot of the P2P code are in place not complete of course but you know a lot most of it are are in place right now. The validator progress is also uh uh mostly done. I think we are aiming to actually try to run the validator uh but connecting to other other um CL clients uh in the next probably like month a month or so. Um and the near goal is basically to build this beacon client so that we can run it on defnet and test net uh as soon as possible. Um and you can see all the code base here uh in in in that link below.

Um the second track is uh beacon beam feature prototyping. Um basically the objective for this track is doing early engineering experiments with beam chain features feature candidates. Um our progress so far so we have been able to do per operation beam SDF on SP1. So uh by what I mean by per operation is like you know you have process block but under process block you have like process attestation process block header and so on. So we are actually able to run those like process attestation uh process block header inside uh CKVMs and those are SP1 zero. Um we have also implemented three SFS implementation in rust. Um hopefully we are able to kind

of convert those like stression functions into CKVM as well. So potentially we can do a kind of like a startify 3SF version as well. Uh there another progress is that as we build the beacon validator client we figured out like oh there's a lot of components that need to be hashed out for the uh beam chain for example like we are drafting an an ERC for quantum secure key store format because uh I think current keyword format uses um you know like not not quantum secure encryption. So we are working on a draft on that ERC. Um some of other near goals is that uh we want to run the complete beacon STF on SP1 and R zero. We have already benchmarked those sub operations as well. Um and yeah so basically the other thing is

three SF mini in CKVM. Um all all of our work are open source. So you can find out all the implementations for CKVM for SP1 for V zero also the three SF mini and also we are also um maintaining developer notes. So for whatever challenges we we we stumble upon or took like quite some time to to fix or find a workar around we also write our death notes here. So you can find you can follow all of our progress here. Um our third track is basically beam chain awareness and and talent building. Um so basically we want to attract new talents to protocol engineering in general. You know having more people um uh pay attention to the consensus layer uh help

build new things. Um we want to build up open and comprehensive knowledge base for the beam chain. Um so we built this beam roadmap.org. I think it's being used uh pretty frequently and also we want to maintain the goal resource for onboarding new engineers to be chain therefore. Um so the progress so far in terms of like the code base so for ream we are actually having 28 contributors so it it expands a lot beyond our core team members. Um and if we count all our repos including like all the CKVM benchmark uh study group and so on we have 38 contributors so far. Um and in terms of like the beam road mapap itself um this is the first time I share the the numbers. Um so we so far we we have launched this for 70 days. Um we have

had 1,000 unique visitors so far about 1.1k total visits. So that's around 16 visitors per day. It's not a lot by you know if you compare it to like big websites but you know knowing that there are like 16 people who are interested in beam chain and coming to to visit and actually use this resource is uh is I'm yeah I'm very happy with that. Um so near goals is keep growing the interest here and also keep the website up to date uh especially from all the content uh from this event. Yeah. And these are some of numbers. So our re repo we had 96 stars so far. Uh we have opened over 338 pull requests. I think it's more by now. U 38

contributors and also 200 issues closed. And these are all of the members that uh we well all the contributors have contributed to to re and all the repost that we have. Um so I think that's about it our updates. So to find out more about us um all our code is on GitHub. Uh you can follow our status updates. We have weekly status updates. Um that's the summary is on Twitter. Um all dev notes are in hackmd and if you want to chat more in uh in the group we have a public group uh in telegram there. Um yeah thank you.

[Applause] It it sounds like for both teams um building a a beam client is not enough, right? You you're one is kind of tackling the execution here and you guys are tackling the the beacon chain. Um how much work would you say is being allocated to the the beam product specifically? Right. Um so I think we can go by like the number of people working on it. Um our team is roughly more or less like six people right now. I think we have about four people working on the the Bcline implementation and then two are

more on like the CKVM stuff. And actually just to add on to a bit to that I think like there are some interesting stuff that at least for for us is is interesting to do both like the beacon client and like more beam chain stuff together. For example, like for in order to do these like CKVM stuff, like we figure out like there's a few engineering challenges that we need to answer. Um for example, um let's say like you have you have host and guest machine for for the CKVM, right? And you have like this like really huge state. Um where do you actually decide to serialize and derialize you know the data from from native rust trucks into uh SSC, right? Um and that impacts the performance, right? you can either like dialize in the in the host um or

decentral decentralized in the dialize in the the guest itself. There's some pros and cons. So being able to figure that out I think is is important for us. for example like we figure out oh actually DC serializing inside the the guest machine itself is more useful because then you know in order to verify like the micro tree doing the proofs and all that you'll require the SSC format not just like the the the R stuff right so doing that inside the CKVM even though like there's some performance difference um the the benefits is is a lot more um some other stuff as well for example like there's uh on the SSC level um there are multiple libraries uh in Rust that are you you can use like SSC inside but it turns out that they all

kind of like prime for beacon chain and so and beacon chain doesn't have CKVM right so all like some of the assumptions for example like if you are going to do like the hash the the micro tree hash route um I think all the client implementations right now basically just rehash or reameralize everything every time there's a state transition function and that's like that's not possible to do inside the CKVM because that's a big preference and string. Um so um we could use like SSC like partial updates um and a few more tricks but then those are actually part of like some of them are actually part of the SSE specs but I think no one actually took care of like actually implementing those parts. Um so finding

those um things and actually deciding to whether you know are we going to have a workar around around that or are we going to um reuse something I think that's uh you know some of the engineering questions that we actually discovered by actually implementing the beacon client and plug it into like be chain features. I mean rest zero was able to to snify a beacon client and my guess is that it's not even using the partial update. So maybe there's a a massive speed up that Vzero could get uh just by doing partial updates.

Okay, any last questions? If not, thank you so much.