Smart contracts without blockchains

I’ll cut to the chase: this post is not about a novel breakthrough. This is existing techniques applied in a pretty straight-forward way. But it does work. There’s a v1 that you can run and even a whitepaper draft.

This is about Vitra, model for hosted smart contracts. I’ve traded decentralized consensus (PoW, PoS, etc) for a single “executor” and multiple writers. Consensus can be expanded to multiple executors using closed-group consensus, e.g. Paxos, and I’ll talk about why you might do that in a moment. What remains is strong constraints around the host to enforce a contract on a shared database.

Here’s a quick demo:

Background

Blockchains are (generally) append-only logs of transactions. They use Proof-of-Work or Proof-of-Stake to distribute the execution of transactions across an open network. PoW has energy consumption concerns; PoS is somewhat complex; both techniques have bad throughput; I find the underlying political systems to be under-studied but very interesting (more).

I’m not exactly a detractor. Some folks think it’s past time to put up or shut up or that Web3 may be notionally doomed. I think blockchains deserve a little more time. The work in L2s and light clients is pretty notable, and though it’s unclear if any new L1s will ever gain mindshare there are still some interesting projects underway. Just politely cough and ignore the scams.

I’ve spent a lot of my time working on “individualist” decentralization projects (SSB, Beaker). By individualist I mean everybody owns their own resources, and they publish them for other people to use if interested. Starting in 2021, I took a lot more interest in “collectivist” decentralization — that is, resources with more than one stakeholder. User registries, software repos, software package registries, protocol implementations, search indexes, and arguably push-messaging fall under collectivism to me. These are resources that require collaborative decision-making.

I started thinking more about collective systems because I was hitting scaling limits with the individualist model. Secure Scuttlebutt is notable for being so aggressive about its anarchy; the wire protocol itself uses your social graph to decide what messages to replicate, meaning spam and indexing are all driven by individual choice and only loosely collectivized into local decision making. It does work!

Problem is, I think users tend to think “globally.” They expect all activity within a space or context to be visible to them. If a search for some user can return nothing because the subject is outside your local social graph, then your technology is less useful than other search models. This is why we tend to pool around well-maintained global indexes to give reliable results, but then you have centralized authority emerging.

Blockchains are themselves collective resources. They are global shared databases. Their answer to centralized authority is to distribute execution across the miners and enforce very strict protocols around how they’re executed. Because miners have very little operational discretion, a lot of the decision-making gets moved into the protocol design, which is why I compare blockchains to legislative constitutional governments.

This still leaves you with low throughput and high gas fees, and this might get fixed by L2s like ZK-ROLLUPS, but it’s pretty complex technology. It occurred to me five years ago that if you allowed every smart contract to run on its own ledger and just used hosts, you could still create this model of legislative constitutional shared resources. I decided to finish the idea now because, well, I started to get curious why nobody else had.

Further, I need a solution like this to get past the limits of the individualist protocols. A social network where everybody publishes their tweets on IPFS or Hypercore works great for syncing the individual feeds, but how do you solve search, algorithms, metrics such as like counts, data-schema governance, etc without collectivist resources? You need models for sharing authority among multiple entities.

So for the past couple months, I put in the time to finish a working implementation called Vitra, which is Latin for “glass.” (Shout out to Hexadecibal from Telios for helping me come up with that name.)

How it works

You can read the whitepaper draft, but I’ll summarize here.

Vitra uses signed append-only logs similar to those used by Certificate Transparency. Vitra uses some innovations from the Hypercore Protocol — their log structure and networking mainly, but also their streaming b-tree index which enables efficient key/value stores atop a log.

These logs use a Merkle-tree to efficiently reduce the history to a hash, so you can tell if the owner of a log has published two histories (thus breaking the append-only constraint). If we can prove append-only, then we have confidence that everybody is seeing the same state.

The goal is to ensure that the database follows a “contract,” which in the case of Vitra is a Javascript program. To do that, we publish the contract in the database, and then to watch the logs and ensure that the state-changes match the contract. If the state-changes ever deviate from the contract, we have provable fraud.

Quick example. Suppose we want a database that maintains a counter that only increments. We’d write a contract that looks like this:

Notice there are two functions, get() and increment() , and only one operation, INCREMENT .

Vitra would instantiate a DB around this contract by creating two append-only logs: an “operations log (oplog)” and an “index log.” Each emitted INCREMENT would go into the oplog, and each resulting state-transition would go in the “index log.” Every time an INCREMENT shows up in the oplog, the index log should publish an ack of the op and a single corresponding state update to the counter value.

Anybody can then verify execution by loading the index log. Message 1 is always the contract source. Messages 2 through n are the oplog declarations, and then a genesis “ack” message seals initialization. The verifier loads the contract and then replays the oplogs through the contract to make sure the executor is publishing the correct state changes.

If the protocol or contract is violated, the verifier would capture information about the fault — including the signatures that prove that the executor did indeed create this bad state. This data can then be shared with anybody depending on the contract to show that the executor is dishonest and needs to be replaced.

Here’s a lengthy video demonstrating Vitra in detail:

The point of all this

Why even bother with smart contracts?

Generally it has to do with sharing ownership among people who don’t super-duper trust each other. Some examples:

• Public/community services that need to publish very sensitive data, like user encryption-keys or software packages. Vitra gives clear external auditability of every change that occurs, much like Certificate Transparency does for PKI.
• Decentralized organizations where a database needs to be shared among people who don’t totally trust each other. The smart contract ensures that the operator of the database can’t cheat the community; it effectively protects users from the owners of a service.
• Large multi-org collaborations (think enterprises with multiple vendors) where data-sharing needs to be coordinated and consistent. Vitra protects you from incompetance in the same way it protects you from malice: the system is transparent and self-auditing.

I started thinking about Vitra in the context of social networks. Suppose you wanted a federated network with one user list, saving you from the @bob@foo.com email-like usernames that’s typical to federation. You could use a smart-contract-governed database to share ownership of the users registry among all the nodes. Not only would you get to share a namespace (just @bob ) but you’d also be able to move users from one server to another without relying on redirects.

Whether Vitra takes us there, I’m not sure. You have to be able to encode rules that prevent squatting or abuse by a participating server — perhaps with write limits or resource ticketing similar to rate limiters? You also have to decide which servers get to participate, since it’s not an open system and challenges around abuse indicate at least some trust is needed. The idea of moving users will require some kind of security primitives to ensure the user actually requested the move.

If those kinds of challenges can be solved, then we might have something. I think you could use this approach for sharing search indexes, metrics, moderation decisions, and possibly even data-schemas since agreement on schemas is itself a shared resource.

Tradeoffs

There are a couple notable tradeoffs to Vitra compared to smart-contract blockchains like Ethereum. On the positive side, it’s a very simple model and throughput should be good. You’re also able to create transactions without paying gas fees — though your executor is shouldering the hosting costs instead.

On to the negatives.

If a Vitra contract is violated, it’s basically dead. The recovery process is “create a new database run by somebody we trust not to break things again.” A blockchain would just reject a contract-violating state change, which is much more convenient.

Vitra DBs are hosted, meaning the executor could go down. Blockchains don’t have that problem, though they can’t do private DBs as easily as Vitra can.

Vitra uses 1 “executor” and 1+ “participants,” though it may just be 1 participant who is the executor. Participants are the ones who publish operations; aka they’re the oplogs. That does enable multiple writers, but the transactions all have to be processed by the executor. That hurts through-put somewhat. It also means that participants could collude to censor users by rejecting their operations.

I mentioned earlier that you could potentially have multiple executors which use closed-group consensus such as Paxos. This would help offset some of the problems; uptime and throughput could improve, and censorship collusion would be more difficult. It could also be used as a way to route around poorly-behaving executors that’s better than “contract ded.” Nonetheless, the model being proposed with Vitra is a trade for more centralization in order to gain efficiency and simplicity.

Vitra also does not yet enable cross-contract calls. This is mainly because a cross-contract call expends resources, and without gas-fee metering you run into spam problems. It’s probably solvable?

The shift from open to closed participation is more interesting than the efficiency conversation. As I said, I think the way to view blockchains is as something akin to constitutional legislative governments (again: more on this). The exact nature of political authority is hard to pin down — are the miners essentially the legislators? If so, I’d argue it’s worth looking at how the legislators are being appointed, because both PoW and PoS would correlate power to wealth. Appointed closed sets could at least open the door to democratic or representative systems, though you’re going to have to solve Internet voting. Have fun there.

Further work

Vitra is a research project and it probably has bugs. I wrote tests but you know how it is.

Verification time is linear to the log-length and you have to maintain all history. This is way outside of my expertise but as far as I understand ZK-SNARK circuits can ensure constrained state-changes without having to maintain these append-only logs. I’m curious if anybody has detached a zk rollup implementation from blockchains because that would basically be a zk Vitra. That said, snark circuits seem a little harder to audit and understand than JS contracts, and I’ve read that snarks may not stand up against quantum computers. (I’m just trying to sound smart by saying that.)

If you find this interesting, feel free to DM on Twitter or email me. Frankly I’m just curious to see what Vitra surfaces in the blockchain world. If somebody is already ahead of this idea, I want to know about it! If hosted ledgers are actually a better fit for some use-cases, I want people to try it. The idea’s out there now.

Cheers
— Paul