Who Can Turn Off Your Ethereum App? A Full-Stack Walk-Away Test

Transcript

Hi, I am James Carley and I build the Ethereum file system. I want the things we build to remain useful long after we are gone. Today we'll take a highle look at what that ask of your entire application. So, why put the work into making an app that people can keep using without you? Well, imagine that you're a researcher with years of notes, attachments, and shared work inside of an app. The company closes or a new owner alters the deal. Your work still matters, but you lose the tools you need to use it. You might start printing notes just to know that you still have them. Developers

feel this, too. If an app you depend on disappears, part of your app disappears with it. And communities can take years to build. When an app dies, people lose the place where they work together. Many never find each other again. So we can make choices now that give all of them a better future. So we want people to keep their work, choose better tools, and trust software with important parts of our lives. And we need developers to build on top of useful capabilities without worrying about whether the original company will still exist next year or it might rug them. That's why app dependability

matters to me. Each dependable component gives the next developer somewhere to start. Over time, these components support bigger shared projects and institutions. Our communi our communities depend on hypersructures give a name to this ambition. Lasting public protocols that anyone can use and build on without depending on their creators. Different teams provide membership, voting, and treasury components. A DAO app combines them and another independent team builds a social media app using that DAO and a moderation module. Each team adds a useful capability instead of reinventing

everything beneath it. Stable interfaces and dependable operation let their work accumulate. That's the future we need to build. Crops gives us the values we aim for. censorship resistance, open source, privacy, and security. The Walkaway test helps us put those values into practice. So, think of one task that your users rely on. Keep it in mind as we go through the stack. First, imagine your team disappears. Can someone keep working and can others run the changes?

services. Then imagine control becomes hostile. Someone takes the admin keys or changes the rules. Can the users still use your app? We're looking for single points of failure and control. The test boxes below turn each layer into a small exercise that you can try in your own app. So use test accounts and copies of data and see what happens and try to make it better. So here is a map of our app grouped into three chapters. Interface covers finding and running the app and recovering access. Data covers usable records, reliable reads, and the work happening in the background. And rules covers

contract powers and the network beneath them. For each part, we'll look at an improvement you can make and something that you can check. First, can someone still get into your app and do that task? They need to find a way to access the release, run the software, and recover their access if needed. Those are three useful checks before we even reach the app's data. Most web 3 apps are web apps, so people need a way to load the interface into a browser. Traditionally, DNS returns an IP address leading to a specific web server. If that server disappears, users

need another way to get to your release. With the Ethereum name service, EFS points to an interplanetary file system identifier of your app's web bundle for a particular release. Different people can keep copies of those same files. And if even one host your interface, it will stay up. Users can reach a copy through a gateway or their own IPFS node. Their clients also check the files inside of the bundle to ensure they're part of that release and haven't been modified.

So if someone takes over your name and points it to a malicious release, users need a pre can use a previously trusted identifier to bypass that name and open a retained copy. So keep the identifier, independent copies, and clear opening instructions. Block your usual website. Can the user still open that release and do their task? So a saved web page is only useful if people can actually run the client behind it. So on the left we have an index h.html HTML file with assets like the JavaScript or other

things on your web server. If that server goes down, the the client can't start. On the right, everything is bundled together. So, the release contains all the code, styles, assets, configuration, and everything else needed to run. Someone can save that release and serve it on their web server, or the user can serve it off their own local machine. So try to block your team's host in a test environment. Clear the browser cache and reload. Does your client start? Remember to keep the source dependencies and build instructions, too, so another developer can maintain it after you're done.

The previous test showed that the client starts. Now, can the user actually get in? The company's login service can disappear even while the app and the data survive. A user controlled account gives another compatible service an identity it can recognize. Signin with Ethereum standardizes proving control of an Ethereum account. That service also needs permission rules so it knows what that account is allowed to do. So whether you use signin with Ethereum or OOTH, try the same authorized task through another client with the company offline. Check account recovery too. Can users access and use

their data without your services running? Next, could they keep using the data that your task depends on? We need to keep the work usable. That means keeping the files and their meaning, opening them in another app, and making the supporting services replaceable. Your app is a single point of failure. Letting another app understand what your data means gives users choices and allows your service to live on.

This example has a stable identifier, an author, some text, and an attachment and version. Publish the field meanings and the rules for reading and changing the record as well. The Athereum attestation service uses shared schemas to describe structured statements and records who made them. Your existing database can benefit too. So export a documented format with identifiers relationships attachments and the encryption information an authorized reader needs.

Give another developer an export and its documentation. Can they use it without asking you how private files add another requirement, keys that can decrypt the data? Imagine the company closes, but you kept an encrypted copy of an important note. You also need to need a protected key backup and a recovery method that works without the company, plus software that understands that encrypted format. So, in a test, block your company's services, recover the keys, and use the plan method, then reopen the private file in another reader. The user keeps

both their privacy and access to their own work. And where will a file where will a usable copy of the data come from when the main provider disappears? For files and databases, a range independently maintained copies. This might be on an IPFS host to copy an arweave on swarm or a backup that the user controls themselves. Keep the attachment and format information as well so that the work can actually be restored later.

For data on Ethereum, nodes validate and retain the current contract state which can be really useful for small or critical records. So block the primary data provider and recover it through an alternative or a backup and check that the result in your task still works. This is one job that I built the Ethereum file system to help with. I wanted a file reference that different apps could use even when they got the file from different providers. In this example, a readable path leads to an onchain record with file details, retrieval references, and a fingerprint.

And that fingerprint is a cryptographic hash of the file. A contract can read the file details. A web client can retrieve a copy from IPFS or Arweave or even the bytes onchain and check the fingerprint against the record. So, think about your own app. What identifies the accepted version of a file? And can someone obtain and check a copy from another source? The data can survive while your app loses the ability to read it. So this top row reads one onchain record. An RPC provider connects your app to an

Ethereum node. Make sure that RPC provider is replaceable and you run your own node and add it to that list. The response gives us the file reference and version storage supplies the actual file. And if you use something like Helios, it's a light client that can verify some RPC responses from the list instead of trusting all of them. The bottom row reads a list of records and this is generally an index that organizes records for queries like finding all of your notes. The graph is one popular Ethereum example. Another

operator needs the index indexing instructions and the history to recreate that data view in their app. So switch RPCs and check the file records. switch and rebuild the index and look for a known note and its latest change. A contract can stay on chain while the service it depends on needs to send transactions to do important work. The same question applies to background jobs such as updating an index or providing an oracle's inputs. Tornado Cache Classic gives us one focused example. A

relayer submits a user's withdrawal and pays the transactions gas. The pool contract checks the proof. The user can choose any other relayer and generate a proof for that choice as well. The pool doesn't require the original team's relayer to operate. So ask the same question about your workers. Could another operator get your code and inputs, pay the cost, and complete the job? Could the user actually take over and do this themselves? So try replacement in a test environment before your original service disappears.

Finally, can users keep the rules they accepted for that task? Stable contracts give a foundation. Users should be able to choose their own software upgrades and shared systems still need a way to agree upon shared rules. So check who can upgrade, pause or redirect the system and what users can keep using if that power is abused. So remember that saved app release we have.

It works, but a stable contract gives that interface something dependable to call. And I want to encourage everyone in this room to write immutable core contracts. That sounds daunting, but if you keep the Unix philosophy in mind of do one small thing very well, it becomes a lot more manageable. Uniswap version 1 2 3 and 4 provide a useful example for this. Its core exchange code stays fixed so other apps can keep calling the same contracts safely even when newer versions arrive.

Users can choose which version to use. That is a foundation another team can build on without depending on your next release. So deploy a new version of your app and let users choose to migrate. Keep the old version stable for people who want to stay. Fixed code can't be patched in practice, so keep the core small and test it very carefully. Check what happens if your team loses its keys and inspect any powers that can still change behavior in your contracts.

Your app also inherits the chain underneath it. On Ethereum, keep a usable node connection and the history your app needs. Know when a transaction is included and when it's final. on an L2 know who orders the transactions, where the data lives, and how the chain settles on the L1. For many L2s, there is a documented route to submit through the L1 directly. So, use your chain's documented recovery path and your users's actual accounts and see if they can complete the steps that they need. Record the delay cost and anything else they must prepare beforehand and include the bridges, tokens, and oracles your app relies on

as well. So the code might be public, but can someone actually take over? Give an outsider everything they need, the published software, license, inputs, configurations, and instructions, and then stop helping them. They use their own accounts, their own hosting to start a replacement and help the user complete that task. Record every missing instruction, permission, or secret. Include the running cost and how an operator can cover them. Every missing item is something that lives only inside of your team's heads.

The result we want is a service that users can choose without asking the original team for permission. So here's a checklist to take back to your own app. So remember the task for the interfa for the interface. Can the user still find a trusted release, use it and recover their account? Is the data portable? Can someone restore records including attachment and decry decryption keys?

And can they use it in another client? Can they replace the RPC, the index, and keep essential background jobs running? Are the rules stable? Who can change them? What can users keep using, and can they follow the chains recovery or exit path? Remove one team dependency in a test setup, fix what breaks, and try again. You may not pass every test right now, but each improvement makes the app more dependable for its users and the next developer building on top of it.

I envision a future where people can trust software with the important parts of their lives. Where their work remains theirs, they choose their own tools and developers keep adding to the foundations everyone else can dep. This is what draws me to Ethereum and what I'm trying to contribute with EFS. Start with one important task. Make it easier for someone else to keep it working. And every dependable piece gives the next person more to build with. If we do this right, our work can outlive us. Thank you very much, James. James, James, what a talk we had

here. What a playbook we have here. Well, I definitely learned a thing or two. And the first question is highly correlated with uh this introduction. Have you applied your framework to some real D5 applications and what were the results? >> So I haven't tried it with DI applications but I have built my EFS app using these methods. So EFS runs an IPFS web server interface that I don't have to host. The smart contracts are immutable and everything is built so that I don't have to be here to keep it working. So I've everything from this

talk comes from how I build software. >> Okay, great. Uh I will break the format and ask one question for myself. um like those watching us online, those watching us in recording, those watching us right now if I think like not if most of them I think got excited by the thing you've shared and they might have some additional questions or maybe like asking for in practice advices or so. Are you open to help people to share uh the information to educate people about your framework?

>> Of course, I I would love to help anybody build better software, software that is not a corporate walled garden, but that we all share. So, if anybody else thinks this philosophy is the right one, then I hope you do. Feel free to hit me up and I will try my best to help you build the best piece of software you can. >> Amazing. Amazing. I really love that about crypto when people are open to collaborate and to help each other. Moving on to the next question. Are some centralized dependencies uh are some centralized dependencies an unavoidable engineering tradeoff when rebuilding the app? From the community side, >> centralized dependencies make software

easier to build. So they are they are a good trade-off when you actually need to ship software and make a profit. All of the techniques that we are talking about here do require extra effort but that extra effort is worth it if you think Ethereum and public goods and open source is important. So if you want to build better software, put forth the extra effort. And I know that's not always possible, but if we try, we can at least get pretty close. Great. Uh, and a quick reminder that you guys can still ask questions and vote for those on the screen so that I can make an informed decision about which one to write next. But I already do have

a next candidate. And the question is, what and how app owners incentive incentives us incentivize users to run or enhance a copy of the application. I do admit that it might be framed uh in a a bit unusual way, but what would be the incentives again? >> So is to enhance that. >> If your app is good, the users are going to want to run it. And if you all of the techniques listed here are not hard for users to run. You just have to add link or limo to the end of a URL for to make a IPFS website work. Everything else is

the same. It's mainly the developer experience. So that the users will get a better app regardless of what we do on the back end. >> Sounds pretty reasonable to me. And let's move on to the final question so far. How do you prevent spreading malicious applications over the real protocols or warn users not to use particular versions? Well, if you're using traditional DNS websites, it is very hard because your client is controlled by the attacker.

So, it can't really tell the user that something's wrong. Um, the best thing we can do is publish our official frontends. One thing I want to put on a EFS is here's apps and here are their IPFS frontends and the teams can put their official releases in a list users can and can can check. But unless the user has a way to verify the release or go to GitHub and grab it or whatever documented method we have, it is very hard for the user not to get tricked.

>> Okay, got it. Uh I think we are out of time. We had this last question just arrived, but uh I'll suggest those who asked it reach out to our wonderful James after the stage.