Hi, thanks for your reply.

I don’t think anything you’ve said fundamentally contradicts what I’ve said. We only disagree on *where* the application logic lives. However, I’d argue that running the bulk of decentralized Uber off-chain can not only just as decentralized, but is also faster, cheaper, and less risky than trying to implement it as a smart contract.

First, once they’re aware of each other, devices that run this hypothetical Uber app can simply talk to each other point-to-point from the get-go. They’d only need the blockchain to discover one another and establish this awareness — i.e., to discover each other’s public keys and whatever public-use communication channel they’ll need (e.g. an IP address, a Web socket, a STUN server, etc.).

Second, the app doesn’t need to share anything publicly until it needs to (if it needs to at all — in some cases, not sharing is desirable). To use an analogy, running applications off-chain versus on-chain is like proposing “load web pages by asking them from a server directly and post a digest of the sequence loaded somewhere public when the user is done” (offchain), versus “load each web page by sending an HTTP GET request to *everyone*, waiting for the server to notice, and then having it send an HTTP response to *everyone* as well” (onchain). Both get you the same audit transparency, but the latter is much more wasteful and much slower. To expand on this, the sharding proposals I’ve seen from Ethereum are like saying “don’t send and receive from everyone, but just to everyone in this randomly selected group of peers,” which ignores the facts that (1) those peers don’t care about your users, and (2) some of those peers can be extremely slow and unreliable, slowing your app down.

Third, keeping the app’s business logic off-chain means that if you want to fix a bug, you can just send the fix directly to your users. The alternative is hard-forking the blockchain to force your buggy business logic contract to change its behavior (or leaving it running forever, and deploying a new instance of the contract hoping your users and other smart contracts get the message to stop talking to your old contract).