DAPPCON 2025: Don't Trust - Verify! Access blockchain data without trusting centralized services
DappCon 2025 · June 2025 · 25:38
Querying and accessing blockchain data without depending on centralized RPC providers or indexers is the focus of this DappCon 2025 talk. It walks through the trust assumptions baked into typical dApp data access and what it takes to verify that data directly instead of taking a third party's word for it. The talk connects this to the broader decentralization goal of reducing reliance on centralized infrastructure across the stack.
Speakers
Topics
From DappCon 2025, hosted by Dappcon Berlin.
Transcript
Hello everyone. It's nice to be here at DepCon 2025 again. Still trusting are verifying already what do you think when this phrase? Maybe some of you my age or older remember on learning he said trust is good control is better. not topic today. Team
about years ago. team was a group of smart italyst developers hackers and came together to build something very very special something which was not existing before so was based on a technology which dece ja the light of the day only some years earlier with bitcoin had this nice white paper vital and do nothing World computer decentralized permissionless trustless unstoppable
sensorship and so on. We all know this was the birthday of Ethereum and right now in age where a lot of systems a lot of ecosystem did grow up until this time and now we see a lot of disrupting apps coming to the world and with this apps we can manage our funds fully selfly we can do payments without central partner intermediate in between products can do very interesting things completely without slied organization we
have games identity and so on when etum was started the idea was very clear so we should have apps running own notes and are connected to this decentralized network manipulation verifiable own application maybe some of you still remember on the mist browser developed in early days was a browser with an embedded
client or client using which was running machine browser run applications. So however what was very easy in the very beginning became more and more complicated when it was possible in the beginning to run a small client which was full note even on small hardware device in web application mobile application was not possible anymore because it way to resources so now came [Musik]
disconnected running client and the application of services came to life which offered information available RPC services our apps des connect services services so look situation now a lot of RBC services more central services also decentralized RBC service networks
but the application itself connects to OBC services and when it receives the data not able to verify it by itself. When I have app running and I need some information from the blockchain, I can get it from services very easily but the app itself has to trust this data provider. So I want to make it very clear that I don't want to bash all RBC services because very important bridge technologies.
e moment inside application how it look like so when our applications need data from decentralized networks not only need information how to what we really want to know the blockchain also needs to verify what is that this information is really the correct information I need in my applications so on the price of cryptographic proofs we can now build stateless cli will talk today about so
that we can get data get proofs and together we have trustless data don't need to trust any centraled partner in between anymore. So let's go back to this picture. There was one guy a little bit hidden in this picture who spoke a lot about this topic. So in one of the papers Vital about the word that fully verifying the chain so computation affordable that every mobile wallet, browser wallet and even smartwatch is doing it by default.
words in the future etherum and other chains provide information even small device like smartwal web application mobile application must be able to verify informations about status client verification describes device Okay.
[Musik] Cuse letc service you are using in application which is used by application you are using is compromised in the one other way it could be a man in the middle attack it could be insider attack on this RBC service it could be DNS hijack some other scenarios application maybe in danger something like happens few examples so what could happen for
instance if are using names for instance to get address connected sending address so you have urent transaction but never into the chain even smart contract code you executing could be changed could be shown in form so that not exact code is running on the blockchain and many more. So we could
extend this list to very long list and we find a lot of scenarios would what could go from in the past we learned that even if there are problems which seem not very likely if there is enough money in the game it will be used it will be done so we need to be very careful in the web free trust data build applications really do what they
are doing decentralized network about trustless permissionless servicent network need to get more trust don't trust verify always and everything now time do Maybe most of you know a lot of different clients available.
So we have full notes which are clients connecting to the PP network synchronizing all the data storing at least parts of state so that all data available that the client can verify all the information to use such fullde very secure because I don't need to rely on anybody just take the information I have verify all run full now depending on implementation how much our state is we need one terabyte even more to store the
information we need to have such verified full note available is not feasible for most of the applications beside the storage of course we also need to be online all the CL great approach reduce amount of data we have to store synchroniz simply just take only the block headers and if we need some additional data we get it from any other full note this makes light much smaller up to
use trust sy application before most of the applications take approach works remote service using a remote client. Remote client means I simply connect to a note or to a provider of the data which gives me information the price for this I have to trust this provider in the client I have no chance no possibility to verify the information.
So when we now talk about stateless clients then we want to combine the good things the light client and the remote client. not much use of resources also don't synchron network store information about what need to build such stats which need very few resources but trustless full client so
client synchronization connected network network it no state also it stores no information from the state but it is able to verify all information by itself when we talk about something to be trustless then actually this is not correct is no like fully trustlessness because I have to trust always something. I can trust the provider who gives to me or I can trust a software which
gives me a proof that something is right. Means when we are talking about trustlessness we are talking about not trusting a provider not trusting transmission channel. So how such stat work our application is dat client and first get information for instance the balance of my account I can use an OBC like I did it before or decent OBC network or I can run node and connect to this node.
information bes informations first execution proof the proof the execution layer and second the proof the consensus layer I will describe it in detail later so when I have proofs then the client can verify information directly in the device in the application very small IT device smart execution consensus layer trust
trust transmission I don't need to trust the provider so what is the execution layerpof doing so wenn wir in der execution information balances other storage information values in state we can interact sm contracts tr actions log event all information we can get from the execution layer we can prove we prove it so that we know that this information belongs to block
characteriz ist nice all execution layer clients provide for instance method defed in 1186 e get proof method can get proofs so that when I get let balance I can get the proof that this balance information belongs block is information blockchain need consensus proof for
ethereum means we have validator set which is currently responsible for this block and we need to prove that the verification transators verify beginning trust checkpoint that all transition correct when I have information I really know this block belongs to the blockchain and I can use it col stateless we are building right stateless
doing all desb now get information we can get the execution so that we can pro that belongs block also chain of transitions in future will that very efficient But who needs such? Die question ist quite easy. application mit B mobile web application which is now using OBC service needs stat needs the ability to verify all information
receives correct and also the IoT world needs so right now we have a lot of IoT devices which are very secure secured by some shady clouds somewhere in the world and if I open my door lock and it would controlled by smart contract I have to trust this cloud that everything is okay not right the device do it by itself we can enable small devices small application to do right now publish MVP you can access it so contact us we can give you
information for this for MVP very easy test replace colibli s webied in future a lot of applications are using that others using protocol to make really secure access to blockchain data ja right now publish mvp productive release test applications to be very trustless in applications
also provide all information public information you can participate invited don't trust verify always in e trcations using blockchain data in the way how thank you much time left questions welcome to Steve few minutes for questions over here in
the midle. Yeah, we have a microphone. Hi, thank you for the talk. You show the slide with the sample code with the RPC call to the proofer. What happens if your proofer sensor the users? provided usation in
Hello for the talk I have also the events are also verifiable only the state of the blockchain also events verif getof Thanks foring something that matters for Ethereum and this ss really good right ss like why is nobody doing it a little bit about the downsides maybe I guess bandwidth and maybe compute can you words
Sorry something about disadvantages more bandw compute overhead right of course how much worse it should not be very strong impact on the latency of course we need some time to build the proofs but execution layer proofs quite simple del consensus lay in the past I have to go this long distance lot of proofs to be done would
ineffective do it every times building proof for so that all transitions mer compressed into one single proof El device goal in noable overhead using such Hey, one thing
is economics behind RPC providers most of them payly expectators would pay So good question. Die question is so we need additional proofs. How do I get? So could be different models could of course some also provides proofs. Could provider as well could special one who only provides proofs. You can run your own proofing service as well. The good thing is you
don't need in this constellation you don't need to trust the data the proof. If you get the proof from somewhere and the data and it fits together, you are sure the correct data. If you don't have it, you not one thing which really important is no way that you can get proof for data and system needs to be constructed way that secure by default. There must be no way to give data.
in future integrated in all data provider services servic