Development Updates: Lantern Client

Transcript

Hi everyone, nice to meet you. My name is Mi and I'm from the P2 team. In this presentation, I would like to provide an overview of the progress we've made so far with the development of C libraries that we will be using for creating the beam chain client named Lantern. I would also like to provide more information on what project we plan to focus on next. So in early Q1 of this year, we finished developing simple serialized NC as it was a good starting point and this type of serialization format will be reused in the consensus layer of Ethereum after the beam fork has happened. The

implementation has been open sourced on our GitHub uh under the MIT license. We also made sure to test the library across uh different operating platforms to ensure compatibility. This includes Linux, Mac OS and Windows. In terms of the features supported by the library, it includes serialization and deserialization of all basic and composer types. Support for union type is also implemented but it is experimental at the moment as like from what I can remember it is currently not being used by the beacon chain. Support for localization is implemented as well as the library can generate a local

proof for any single item in an SC object. The ability to generate multiom proofs is a feature we plan to add as an enhancement to the library. Currently the implementation passes all required generic and static tests which were generated using the Python test generators available in the consensus specs. For static tests, we use the phase zero beacon state object as uh it is a very complex type and it covers all the basic and composer types in its fields which will ensure sufficient test coverage.

We definitely have some improvements in mind alongside adding support for multi-item proofs which includes easy to use SSE generators using macros. This will make the library more friendly in C because it will abstract away the low-level complexities involved in defining serialization and deserialization logic. So once SS was completed, we worked on developing lip P2P in C which was completed in May this year. This implementation as well has been made public on our GitHub under the MIT license.

I would also like to provide more context as to why we chose to develop the PerpC. Before starting this project, we had the option to create an FFI for the Rust implementation which would expose low-level functions that could be used for creating highle protocols in C. But we decided not to use this approach because we wanted to avoid potential incompatibility issues on certain types of IoT devices. Also, the lip library has a lot of different components and it would have made the design of the FFI a lot more difficult to implement correctly.

In terms of the library status, it currently supports the following protocols. In our local testing, our implementation was able to correctly connect with the JavaScript LP2P library for ping and identify protocols by dialing a load stock client. In our testing, both dialing and listening were working correctly. But we only tested the MLX multiplexer. For testing Yamix, our focus is to implement interrupt test plans and then test it by connecting with other implementations. More on that in the upcoming slide.

So our ultimate goal with the lipid library is to achieve feature par with all other implementations. To achieve that, we're working on integrating the transport interrupt test plans and use that to align any differences. Once that has been implemented, we'll be able to implement support for quick transport as it has been gaining a lot of support in other implementations for the beam chain client. Having proper support for gossip sub protocols will be necessary and that will be our main priority once support for quick has been added. We also have a lot of improvements in mind for the libraries API and plan to iterate on them over the course of time.

Now I would like to provide an overview of the next project we want to make progress on. So we already have the C implementation for SSE and we would like to extend it by adding support for proving using ZKVMs. A good starting point for us would be to integrate SP1, but we also plan to add support for others including risk zero and zkips. What we want to accomplish with this project is to have a library that abstracts away the integration complexities between ZKVMs that can be used for proving changes in SSC encoded objects. To achieve that, we will need to make sure our implementation does not

depend on a single ZKVM. It would be ideal to have a redundancy model where once several mature ZKVMs are available in the ecosystem, users can set a quorum for example having n of m proofs that must be met before any state change is accepted as valid. Another important target would be to make it work across differing operating platforms as we want to make sure our beam chain client has compilability with as many devices as possible.

So this concludes our presentation on the progress we made so far and our focus for the next phase of our project. We also look forward to learning about the progress being made in other areas of the beam road map and are excited to collaborate on anything that helps accelerate our collective efforts. Thank you for your time.