Mycelium light client demo, light client summit

[Music] i guess i'll start now hi everyone my name is mihir i'm from the mycelium research team and we're predominantly based in brisbane australia and we're just quickly going to be showcasing the work we've done over the last few months and before i get into all of that i'll just be explaining briefly like why we want to build like lines for the consensus layer theorem so uh basically um last year in november i read this article on coin market cap it was written by matt garnett i'm sure most of you some of you know him he's a core developer for ethereum and in his article he mentions um that ethereum has uh like a few centralized centralization points um these are basically um you know these dap developers they've been using node services like infira into the applications and there's also uh we have bullets like metamask they use inferior by default and um also some of the roll-ups as well like starkiller nodes some they use inferior as well to sync with them to interact with the ethereum network and um yeah this article really opened my eyes as to how big of a problem this is um and the reason why this is happening is because there's only one way to interact with ethereum which is by running your own full node but that itself is very difficult for most users because it requires an understanding of like command prompts typing these commands troubleshooting those errors setting it up it could be quite you need some sort of delaware experience to interact and so uh that's a very bad user experience and there's also financial costs as well um if you want to sync from the uh you think it gets node uh it takes a very long time because the state size over 100 gigabytes and um yeah and what has happened is uh no services like infrared they've just provided they've removed these barriers and they just provided you know a straightforward api that you can use in your application and you can start interacting with ethereum um and so this is why they've been growing um so the long-term so if we don't have you know multiple implementations of life clients and we don't have you know efforts like portal pool network um i think we will eventually start seeing more and more cases where users who cannot afford to run a full node but if they're relying on service like infera to interact they'll be locked out and um locked out is in like they weren't militant type of ethereum and one example was this year in march basically venezuelans were unable to interact with ethereum because they were using inferior and what happened was um inferior is a u.s based service and they have to operate within the rules and regulations of the country and so they cannot really provide the services to countries that are on sanctions and basically some misconfiguration happened on their behalf and that led to some downtime and so users will basically locked out um but i just want to say one thing i'm not condemning inferior or any node service i think they're really great and they're really great that they provide infrastructure to ethereum and they could be great for testing for like you know if you want to test your smart contract application on a test network like um rink b you could just use that that's going to be fine but it would be great if uh would be great to have alternatives um for like uh if people who can run a full node but like if you want to interact with main applications and yeah so the so we want to address this we want to build a production based like client for our theorem for the consensus layer um and that is able to run in resource constrained environments like the browser as an extension on mobile phones and then eventually iot devices like smartwatches and it's obvious the reason we picked these three is because these are highly accessible ways to interact with interact with internet today like for example in the browser you can just type the url and um the web page just loads instantly mobile apps they're really mobile phones they're really portable and you just click on app and uploads and smart watches are even more portable so that's basically our target that we want to create like claim for so the progress so far we made is back in february oh no so this year february we created a prototype black line in c-sharp and it implements the sync protocol specification and basically it has two two functionalities at the moment it can sync to the latest block in the beacon chain and it can verify information from the beacon state object you can verify the mod the mogul proofs and we also like around march when um yeah around march so we also uh worked on like a experiment experiments implementation of the lit peer-to-peer routes defined in the draft github pull request um yeah and we the what what happened was we so the status team they deployed some nodes on the kiln merge test net uh that could serve like line data overlappingpier and i used the the enrs they gave me to connect with those nodes and get the lot of get the data over the p2p and it and it worked but the thing was um the kilometers tester has a lot of other nodes as well like from prism um load star all the client teams that don't yet serve uh like line data over the pdp so discovery was the only issue i had but yeah it's expected like there's only yet so i guess i'll explain now how like quickly how consensual life lines work so you basically need two things a full beacon node that can serve like lane data and you need a checkpoint route and the full beacon node you can run locally on the same machine the like line is running on or you can run on a different machine what you're really interested in is in the api endpoint of that beacon node and then the litecline uses that api endpoint to get data to sync with the network and as for the checkpoint route the checkpoint is just a block route that you can get from a variety of sources like the block explorer um your friends node or if you're running your own node you can just use that so once you have those two things you provided to the likeline and basically the like line sends a request to the full node through the api endpoint and the checkpoint route you provide it requests a snapshot the snapshot the beacon node returns a snapshot containing the the the block header at that checkpoint route and the sync committee that signed that block header and the proof of that sync committee so we only verify if the checkpoint is a valid starting point to sync with the network to sync with the network and then once we verify that information we request a range of sync committee updates now the checkpoint because the sync committee changed every 27 hours and um the checkpoint rule could be it depends it could be multiple days old so in order to get because and the synchrome community would have changed multiple times and so in order to get to the currency committee you request a range of committee updates and yeah you verify those range of updates how the scene can be changed by looking at the proofs in the beginning state and once you verify all those range of updates you basically request a like you pull every 12 seconds the full node for a new header and um because this is because like every 12 seconds a new block is added to the beacon chain so in order to keep track of the latest state route you request the header every 12 seconds and um yeah i'll just quickly show you the demo so um so this is the c sharp implementation it's the user interface and as i mentioned earlier it needs two things it needs a api endpoint so just have it here on the notepad and here's the checkpoint root now i'll be using the beacon chain explorer to get a checkpoint root um so we can just use uh i'll just refresh that just be we could just go to this recent one of the recent epochs and we can pick any block route from the explorer copy that and so the the like line quickly synced with the latest block in the beacon chain but we're always one block behind because the synchrometer signs the block pre the block previous than the current one and so um yeah this is the interface the only utility this like client has right now you can query the balance of validators yeah and um but i'll just type in a random validator index from the beacon chain and this is getting data from the main net as well so okay so when the progress bar reaches the end we'll get the balance of the latest validator and we're verifying this balance by checking the proof multiple proof that we get from the request and so we verified the proof against the state route we're keeping track of here and the state rule keeps changes every 12 seconds and so we have to request a proof every 12 seconds and uh yeah that's um that's basically the utility it has i just want to say uh it's not really like beacon state object has many other fields like finality checkpoints um latest header genesis time you can request all that it's not just restricted to you know validated balances and what's really exciting is um like post merge you'll be able to like post merge they'll be adding a new field execution payload header and you can use that for example to verify if your transaction was you can get some assurance that your transaction one is included in the future block so if you send a transaction to the execution layer and you want some assurance that your transaction wasn't included or not and you can easily you can use the like line to quickly sync with the network and get some confirmation um and we can verify this confirmation through the we can request proofs for that chat with the was included or not and uh yeah that's basically the um demo that was pre-recorded if something went wrong so what's next for us well okay so we we we tried with the lipped appear approach um there are a few challenges now lippy to peer library exists in only three languages at the moment it exists in golang rust and node.js there were attempts by many developers to bring this library on um on c-sharp but the thing was it was too big of a challenge you know to bring this light lit p2p live for one person because the pdp library is quite complex it's a lot of moving parts to it and so you need a full team dedicated to this effort and um the only thing it makes sense so in order to make it work in c sharp what the only logical thing to do is just have the libpeter p instance running and then you have the c sharp instance running and then do have some communication through the apis between those two and just package this together in order to make it work in resource-constrained environments and um one thing i'm really excited for is when portal network is active when all the networks are active we like to use the transaction gaussian network for allowing the like line to send transactions to the execution layer and then those transactions could be processed and in order to make that work we will probably need to implement some libraries in c sharp and then start building portal client implementations on that in order to make this work and obviously with also with the state network as well we could request execution layered data like reading contract balances um that's very exciting and um yeah that's that's pretty much it for me uh thank you [Music]