Trillion Dollar Security: The Future of Ethereum Security

Transcript

We will now begin the afternoon session. To start uh please welcome our uh first speaker Mr. Thomas Tanzac. The floor is yours. Hi everyone, great to see everyone and today we'll talk about trillion dollar security program and describe a bit the future of Ethereum security through the Ethereum Foundation programs. Um my name is Thomas Stan. I am coexecutive director at Ethereum Foundation since March April this year. And let's review the initiative for the trillion dollar

security is something that we announced uh I think late April this year and through the blog post announcement we said that when we think about the future of Ethereum first of all we think that already nowadays Ethereum is the very robust platform among the blockchain networks considered to be like zero downtime very secure platform with a lots of tooling that evolved over 10 years uh into tools that have some standards have some standardized approaches to smart contract security.

But it's not enough. It's we want to go much further because we expect massive growth of the onchain activity, massive growth of the uh massive growth of the number of assets that will be tokenized and deployed on chain. So whether it'll be stable coins, it'll be equities on new tokens or whatever it is, we think that if we want to talk about billions of users and we want to allow them to safely store assets on chain, uh then let's average this on the $1,000 per per user on average and this gives you a trillion dollar security. But you also want to think about the the largest of the institutions on earth to feel very safe about using Ethereum for whatever they're working on. So if they will

deploy smart contracts for the large tokenized ones then maybe they would hit the1 trillion dollars in a single fund. So, how to think about the new level of threats when the honeypot is so large, the trillion dollar to grab for any attackers, including uh state actors, um many organized crime or maybe even uh other other chains or competitors thinking that uh they want to showcase the any vulnerabilities that can be detected. So all of those are are very heavy threats and the they target potentially any aspects of the Ethereum stack and we want to approach it in a very organized way. Uh reach out to

community ask questions and start addressing the problems that will start appearing as the money goes up. Uh so the three stages mapping of all the security issues uh surving the ecosystem asking questions about what really the problems are. uh the Citrium Foundation and ecosystem. Are is everyone aware of what uh what security threats exist? What security threats caused the attacks and uh money loss in the past and splitting that into six areas in the announcement. mentioned UX, wallet security, smart contract security infrastructure

protocol consensus and the protocol security as the uh the the client and design of the protocol. Then the second stage is executing all the changes suggested or selected changes uh providing grants supporting the teams that build dashboards that build solutions uh that improve Ethereum security and also communicating uh educating and communicating about the changes about the security issues about the new tooling educating developers educating users uh bringing awareness of the security risks of the new paradigm for many of the users that come into to blockchain from the traditional finance world.

Yeah. All right. And uh then we also published after the first survey of uh all the threats, we published a report that splits all the information into and actually six uh six categories. Uh so we adjusted it to user experience, smart contract security, infrastructure and cloud consensus. But then also we pointed out the monitoring incident response and mitigation as very important aspects of this in a decentralized network. How do you communicate with everyone that something bad is happening? You require non-entralized coordination and exchange of information between participants that also should not really trust each other to too much of a extent. So you cannot have um a single coordinator that

everyone will trust because maybe this is an attacker and the social layer governance. So whether it's uh it's Dows or the social consensus aspects uh the reaction of the community when the technology fails and you have to uh you have to resolve issues either through the social consensus or Dowo changes and deployments. Um so some of the things that that happened very naturally and I think they would happen also without this initiative. So nowadays we announced uh 2 million uh back bounty for the security of the Fusaka upgrade. Uh so there is the uh Fuaka audit contest uh for up to $250,000 per bank bounty for the uh security researchers, auditors uh

back bounty hunters that's available and Vaka is starting release on test nets now and very soon and the mainetaka probably around the end of November just after after defcon connect in Argentina. Uh so very important release for us and very big aspect of Ethereum security continue this 10 years of downtime uh no downtime into uh 20 years of no downtime and forever of no downtime. I think it's all about this no downtime culture. uh that it gets really inscribed into Ethereum.

Uh so in the in the report we mentioned the UX challenges some of them more obvious some of them less obvious. The key management you know over many years because key management was has been always mentioned as a as a one important aspect of the term security concerns. So the key management tooling did improve significantly for enterprise users for the custodians through the uh hardware key management solutions and so on. Uh but still we want to see uh how it's how it's solved in all the more advanced scenarios. So when you think about enterprises and they have to do the key rotation when the employees leave the company and you want to replace the keys in multic uh when you have to manage them in the in the corporation in

general some of those edge cases or the change management processes are still not standardized uh blind signing transaction uncertainty. So we know from many cases when we participate in multic sign transactions very often we see hashes no detailed information about transactions we are signing. So that's what we call blind signing. You signed something but you're not certain that's what's really happening. So you would like simulations, you would like the good description of the uh transactions that you're signing and so on. Uh approvals and permissions management somewhat related. We're using applications. We set approvals for spending from our account. We do delegations now also with the account abstraction solutions. How do we manage

standardized way all this approvals, permissions revocations authorizations, uh the web interfaces, UX can be compromised. We see problems with the uh with DNS with cloud infrastructure under attack and so on. Privacy itself delivers security challenges. So the security of the users, the more information that uh leaks about the user activity, the more sophisticated attacks can be executed by the attackers and uh all the problems of the fragmentations of the UX of uh inconsistent usage across the various L2 stacks, bridges, wallets and so on. So there's fragmentation of approaches and the standardization should help with this

uh smart contract security. So continuously we see the risks related to contract upgrades uh famously the re-entry problems that we addressing now with the bayop code most likely in glamsterdam um they any references to external libraries on audited components so not everything is verified on on chain it's uh not automatic verification whether you interacting with audited uh contracts the audits themselves probably auditors require auditors of how we created the dashboards and some kind of auditing of the quality of the audits executed on different protocols, access control failures and authorized access.

So all of the standardization of how you really like control within the organization who can use uh who can use particular smart contracts for managing vaults or uh or larger amounts of money uh bridges and crosschain part of the fragmentation questions. uh the EOA delegation within the account abstraction. Uh so all the standard accounts how they how they get delegated to execute to execution for the smart contracts. Uh and also a novelty uh what we really do if people start getting used to generating code with AI for the smart contract security for the smart contracts. how you can make sure that you not only generate code with AI but also verify code with AI and the verification standards and the training for the LLMs that are used for security

are of high quality. Uh the other aspect of the smart contract security is also developer experience. how easy it is for developers to ensure that the smart contracts that they're deploying are are safe and that they have all the tooling needed for that. So, uh thinking what secular means here uh lack of lack of defaults in popular frameworks. So a sec security defaults uh the uh custom custom code for advanced operation controls once again like some pre-eployed smart contracts that can be reused by uh by smart contract developers uh to not recreate

this advanced code concepts in each organization because we have some basic some standards for maybe more standards tokens but the more and more advanced features are not yet fully standardized. uh inconsistent testing coverage reports the uh formal verification methods getting more and more adoption particularly in the in the ZKVM ZKVMs world. There is a big program from Ethereum Foundation with $20 million funding for verification of ZKVMs and we would expect the propagation of the formal verification uh tools and methods for the smart contracts uh will be gaining some traction. the uh issues related to contract verification compiler risks as well. In the past there were some issues with compiler

compilers that led to the to the loss of money. Uh entire Ethereum community really relies on uh Sy for as a compiler. So any risks that there would be a major issue in a compiler uh would cause major trouble in the ecosystem. Uh so now the question is with the compilers actually compiler diversity it's a different problem right like because you deploying something and you're not doing the compilation with all the different compilers each one will have a different output anyway. Uh so so you don't have the same concept of uh of gaining from diversity. Uh but it introduces at least some concepts of competition to the compilers and and forces people to to make better

optimization. Maybe it leads even to more security risks. Uh programming language diversity and depth. So more tooling for the smart contract developers to feel that uh the programming language like solidity or any alternatives provides them tools for writing more secure code. Um the also for the onchain code that is already deployed many of the organizations that deploy onchain code are not used to the standards with their standards process and requirements. they don't really map into the smart contracts world. So that's why it's so important for the interum foundation and ecosystem players to introduce standards uh new standards for smart contracts or really adapt the existing standards to

smart contracts because many of those existing cannot be used straight uh into the code that is uh having all those assumptions of immutability uh the uh like everything that's related to blockchain release for the infrastructure and cloud security what we've identified so obviously for the L2s, you start to think about asset complexity. What with assets that are breached multiple times that are hopping, how do you really combine the security of the L2s, the exits with uh with assets that are that are routed wrapped multiple times? Uh how we verify the security of the proving systems for the L2s. So this is very often like the formal verification all the bounties related ZKVM ZKVMs

comparisons uh the solutions like two out of three or two out of many for the ZQVM uh for def connect this year we're preparing uh this major goal for the I think six major ZKVMs uh to to publish real-time proving and one aspect is the latency performance nowadays the other aspect will be security and formal verification so in line with that chase case for who publishes the real uh real-time proving we also chase them to do the full formal verification. The thing is these code bases are still evolving and formal verification is particularly expensive time consuming format for the code that is uh that's more set in stone. So we'll always have to have trade-offs of what can we

formally verify. Uh security councils themselves always at risk of being multiigs and uh the the key holders of the security councils can be under attack. uh so this is big risks for the major L2s RPCs and node infrastructure this is aspect of uh many of the RPCs that are being maintained if they would go down then suddenly users are not able to to connect to Ethereum network and that might be uh the case in the past you've uh maybe you remember there was an issue with the G upgrade on the infura network that really uh disabled access for many of the users uh to the Ethereum network and u the case here is we want to improve RPC network through the dashboards, comparison, security

tooling, but also but also provide privacy for users interacting with RPCs. This is a bit of separate track maybe related to security but more to privacy. Uh DNS level vulnerabilities. So all the UX that people use for using smart contracts uh can be hijacked by replacing the website that is being accessed. So DNS hijacking, domain seizures by the governments uh and all the type of fishing by deploying lookalike domains uh software supply chain and libraries.

You probably uh heard recently a few weeks one week ago two weeks ago uh we had this software supply chain uh at risk. So the uh some of the major popular uh libraries and the npm packages were u malicious package injection. Uh so many many of the tools in the Ethereum ecosystem broader blockchain ecosystem were at risk. So questions are if that happens how do we how do we communicate how we monitor those situations how we prevent them by maybe storing the uh the global use packages in in a a particular signed way. Uh so all the all the tools in the blockchain can can refer and check which versions have been used for a longer

time. Um front end delivery by itself like so any any malicious injections through the cloud hosted platforms or content delivery networks um posing risks as well. Uh uh see inter internet service providers on this level we asking really about uh censorship and well any any spying of activity. So you can uh see uh risks to users mostly on fraudling access filtering requests uh geoencing or IP bands and uh the packet inspection all of this just to prevent access to Ethereum network right uh so here we're talking more about the Ethereum network

access and security of uh being able to to access the network uh on the consensus protocol side. So risks related to the consensus itself. Uh so how we continue research towards a very robust protocol that can handle all the different edge cases. Uh there was a post from Vitalic a few months ago I think about how we should really create the teams at Deran Foundation and broader in the ecosystem that will be trying to uh verify the edge case scenarios of the large attacks and recovery. So if we create uh attacks on the on the consensus how quickly the network will recover. Will all the

validators be able to uh to come back to operation? We had in March I believe an issue with Hollleski network where when Hasheski network failed the validators had real trouble to recover. uh the case for heski maybe is less severe much should be much less severe than for mainet in a sense that less people were paying attention and trying to uh make an effort to recover hleski then they would in mainet but at the same time it also raises a lot of concerns and questions uh if people don't have this fire drill of bringing back heski and other test nets devets uh then how they would act in the case when the mainet happens when it's also more stressful and rushed and there is massive massive

amount of value at risk. Uh client diversity typical discussion about the safety of the Ethereum protocol through the execution client and uh and consensus client client diversity. It generally improves the robustness of the network but also incurs a lot of costs on development and uh coordination efforts and also famously uh as we are chased for fast deliveries the client diversity on one side improve security on the other side. sometimes is being claimed to be um the reason for for delays in deliveries. Uh very likely good security uh approach and testing from all the clients together accelerates accelerates deliveries but that's it's hard to create that

impression. Uh any risk to staking centralization pull dominance uh undefined procedures for social slashing. Once again, we want to have uh various largecale testing frameworks for for these type of events. So, we start talking about really huge multi-billion dollar attacks that are coordinated and executed with the network as a target and all the risks to quantum computing long-term road map very clear road map for what we would like to do on quantum side and much of this is coming in the lean Ethereum project that is uh that was initiated by by Justin Drake and it's now coordinated by Tyrion Foundation.

um also the economic gain theoretic attack vector. So everything related to me griefing attacks uh economic activity uh if you remember I think two three years three years ago there was the uh the attack on the uh me setup with three layers and uh builders which was uh which after execution stole $25 million from me bots. uh nowadays uh we have I think there is a trial ongoing uh on the on the case and the ant and the vulnerability in the infrastructure was fixed uh but we see that as we combining infrastructure the protocol with the offchain execution or the offchain components uh those those vulnerabilities can uh can get into the

the broader ecosystem and we should keep looking at how to avoid them. uh once again in monitoring incident response how to re reach affected teams how do we escalate problems. So if we detect that some of the major networks continuously ignore some security issues what are the escalation paths um the generally how we coordinate the response in cases one thing is the reaching out to the teams but if there are more teams and uh it requires all of the teams to execute some actions in a synchronized way how do we execute that coordination in the centralized way uh generally what kind of dashboards we have nowadays for monitoring all the all the security sometimes they are there but it's u like

it requires knowledge of work to find them and just coordination of finding all of those dashboards security dashboards uh is something that foundation can help with uh and finally also how how all the different um affected teams what kind of access to insurance they have. So combining the financial markets insurance with the with the risks of protocol social layer governance uh well the risk of ST centralization that may lead to uh various misbehaviors like malicious actions from the operators. Uh so here you have a link to the pretty recent event I think a few days ago or maybe even more recent uh where the Monero network that is having uh a

a majority uh majority staker operator cubic that goes into the 18 block because of selfish mining. Uh well not stare the minor and uh can it be also executed as part of the uh of the government actions regulatory attacks uh and the other aspect is what can happen with the organization capture of the governance processes. So if you have all core devs and all core devs suddenly uh stops being decentralized and gets into the under the under the control of a single organization what would happen?

How we avoid this situation? I think that in the Ethereum space this particular case is very very far from possibility but we should be always aware of like how what is the sequence of actions and governance changes that would lead to that situation and well why do we do all of this? Why you identify those risks? Why we talk about them openly is because we want to maintain the zero downtime culture. We want people to be obsessed and scared that this a single moment of failure would erase 10 years of zero downtime. So we want developers to when they join the whether it's Ethereum Foundation or client teams uh to think that this is the single worst thing that could happen uh that any security major security

events happening on Ethereum network are losing a lot of this uh the culture and legacy of building for 10 years with appreciation for testing, verifying, checking everything and all of this while we want to maintain a fast delivery processes uh robust and like predictable delivery processes with uh not not never missing uh timelines and deadlines. I mean it it requires really fantastic process. I like to talk about it that whenever whenever I travel with trains in Japan, I expect them to come exactly on the right second and somehow I feel also safer because I think that this is part of the quality process that not only arrive on time but also that

everything everything all the inspection processes are perfect. Um so what we what we bring as part of the uh as part of the support so we look at the wallets and the UX space. Uh so there's one one of the three things that I'll repeat once again at the end uh that we that we're addressing in the first wave of the actions. So wallet bit is now the dashboard that is comparing the security aspects and privacy aspects of all the wallet providers. So this will grow over time. Uh we want to continue building dashboards supporting dashboards. they all dependent like L2 beat, wallet beat and so on. Uh L2 bit itself looks at the risks and security risks and asset risks on different L2s.

Uh so if you have dashboards like this, we can also continue with the RPCs with infrastructure components with the clients comparisons and so on. Uh then we uh start to collaborate with the OASP that is uh that is uh that is used as a framework for uh for the cyber security in uh in the web two and we built the same setup for the smart contract security. Uh what were different suggestions that we received within the survey? All the people from the ecosystem are sending ideas and here is a very quick review of of various ideas that we've received and we're looking at and thinking of how to how to address this. So all the

standards for transaction simulations to avoid blind signing the verification of push notification signatures and maybe trust labels from different repos that can be delivered to wallets or standardization of those more ENS adoption the some kind of uh pause and uh and verification for larger transfers or wallet draining mechanisms. Pas keys adoption here sec 256R1 curve is coming in Fusaka to enable cheaper verification of the pass keys curve the most popular pass keys curves. Uh that's the one that is coming most likely in November.

Uh more UX suggestions. We're looking back at the blind signing solutions that were proposed in the past. Here it is ERC7730. um lots of other solutions around the uh DAPs monitoring, the protocol upgrade alerts for the DAPs, dashboards about the DAPs, uh security of assets in the DAPS, uh the lots of suggestions for the LLM scanners for smart contracts. I think we already see that LLMs are helping to deliver the very secure code. Those secure security checks by LLMs are one more one more tool that developers and security auditors have. uh the pay op code to address re-entry most likely coming in glamsterdam to make sure that you have send send assets without the

risk of of a malicious code execution. Um then further smart contract security. So more more realtime dashboards is what everyone is mentioning. Uh L2B is usually mentioned as a standard of how to create a good dashboard. Not necessarily that L2 beat has to deliver all of the dashboards. This will be coming from independent providers. uh for the cloud suggestion uh there are various solutions suggested for P2P and uh and the approaches more more professional approaches to building infra uh on the consensus side some kind of P2P based slashing as well was suggested quantum readiness uh a lot of decentralization support for security for homestakers

uh more monitoring suggestions again for the LLM and real-time dashboards And on the social layer once again a lot of coordination support from the foundation. Uh the phase two actions so wallet beat support we providing grant for wallet beat and we'll work with them on uh helping to identify those metrics security and privacy metrics. uh working with verify alliance on the blind signing uh standards and also revisiting those proposals from the past around blind signing human readability of what we signing uh and also avoiding cold vulnerability by addressing the developer tooling. We also hiring now the uh developer tooling

coordinator for Ethereum foundation uh and also hiring project manager for this particular project for the trillion dollar security initiative. So please apply. Thank you so much.