AutoDapp: a proposal to decentralize existing web apps

great point! This was about as simple as it got in order to ship something quickly that was minimally intrusive. So the prototype as it is now buys you sequential consistency, but I want to detangle some great points you made.

1. Performance: The performance is probably going to be limited. In the sense that most databases have better performance than most blockchain implementations. So you're arbitrarily bottlenecking your writes. There are a ton of really great papers that show you can do WAY better if you are more careful with your distributed design. They usually involve getting into the weeds of redesigning the internals database. Just for fun, I really liked these papers: http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf https://irenezhang.net/papers/tapir-tocs18.pdf https://www.usenix.org/system/files/conference/nsdi17/nsdi17...

So there is a ton of space to improve the performance here, I just wanted to build something quickly.

2. Authentication: Definitely an interesting technical challenge here. Most web apps are written assuming they are one-of-many servers accessing the database, but honest and has root authority. So how do we make sure that a validator has the authority to write to a particular table/row? Right now, this is still an open challenge and would love to engage the community on ideas here. There might be some way to tag/sign all tables/rows with creator, and do some write access control based on that? I'm not sure how many web apps would break though.

3. Write-conflicts: Even without good access control as specified above, most web apps are written assuming they are not the only web server to be accessing the database concurrently. So I would anticipate honest servers would have either good failover logic or be wrapping operations in SQL transactions if they really needed them to be atomic. Either way, I don't see any issues being serialized and appended to the log.

Hi all! I just wanted to say thanks for the awesome questions. I can't say I have the answers to these questions, but I can lay out some of my intuition and would love to work together with anyone that also finds these questions interesting!

1. Will this scale? Blockchains vary from the order of ~10^0 tps (PoW) to ~10^4 tps (PoS). https://decentralizedthoughts.github.io/2019-06-23-what-is-t...

Wikipedia sees 50K HTTP requests/second and 80K SQL queries/second. https://www.datacenterknowledge.com/uptime/data-center-provi...

But it is also read-heavy. Let's say if 10% of the workload includes writes (probably too conservative), we barely squeak by... I'm willing to guess the number is way lower than that. They saw 10M page edits for the entire month of Dec 2018. https://stats.wikimedia.org/EN/TablesDatabaseEdits.htm

My guess is, this might be doable :-D

2. Who runs this? and who pays? Great question. The blog completely skips the question about incentives which in my opinion will vary depending on the app. For creating an censorship-resistant Wikipedia, it'll be different than a communications app. Some apps might be better off permissioned (e.g. enterprise settings)

Wikipedia is 43GB of text and 23TB of rich media (images and video). https://en.wikipedia.org/wiki/Wikipedia:Size_of_Wikipedia

If we limit ourselves to just Wikipedia text, it might be reasonable to do this permissionless!

Hoping to write a blog post about that soon after we get more built to show.

Wouldn't any such apps used for anything beyond toy experimentation quickly re-centralize around maximal cliques? At scale, the demand for responsiveness tends to drive out the demand for everything else.

Let's say you implement a Facebook-like social network (think something like Elgg). If you really need the benefits of decentralization, is waiting a few minutes for your post, profile update, file upload, etc. to go through that big of a deal?

Decentralized systems that use append-only logs (which includes but is not limited to blockchain stuff) need the equivalent of a 'git rebase' to purge history.

Like lwalton says, this is very difficult to do without centralizing authority, as a rebase is a fork, and so you need the whole community to rebase/fork simultaneously. This is a big deal if all data is in the same place.

One approach is to break these logs apart, e.g. per-user, like Cabal does it. Instead of replicating one giant log, you replicate many small logs. As a user, you can choose which logs you want to store, replicate, and which contribute to your materialized view. Or, you can delegate this work to a moderator you trust, who in turn may subscribe to other moderators or blacklists to inform their moderation.

In this way, there's no centralized authority - everyone is their own authority. Writing the user-facing moderation tools is important work, but is a relatively well-understood problem.