TEE-enabled Social Games: An Experiment with Bobu’s Magic Show

From flashbots by socrates1024

by Xyn Sun, Ryan MacArthur, Roshan Palakkal and Andrew Miller

This week we used TEEs to help Azuki carry out a  magic show performance livestreamed to Youtube 6  using the  Teleport prototype 14 . This post outlines the technical implementation behind it.

Background: Bobu the Magnificent’s magic show

Azuki has a character called Bobu that is governed by ERC-1155 tokens, where holders can vote on proposals on how to use the character’s IP. Because Bobu is all about community ownership and co-creation, the magic trick was one where audience volunteers acted as both the magician’s assistants and the rabbit in a hat. Each of the volunteers used their delegated twitter credentials to tweet out collectively, the digital equivalent of a “Flash Mob.” This collective tweet was a twist on our  first trick 4  where a Bobu community member was tweeting from Bobu’s account via on-chain interactions (see 2pmflow’s  walkthrough post 4  for details).

|441.37057728119186x299731×497 315 KB

Desiderata

Posting from a bunch of Twitter accounts is, on its own, not too demanding of a magic trick. Like many web2 account providers, Twitter allows users to delegate read/write access to third party applications. Volunteers for the show were explicitly invited to opt-in to the show’s app and offer “Read/Write” access. Users had to specifically click “Authorize Bobu to access your account”, post to their account, follow/unfollow, everything.

695×677 58.7 KB

But, Bobu only needs to post one tweet for his magic trick. We don’t need all the rest of the authority that Read/Write gives you. And users don’t like to give this away! This is an instance of “over-authorizing”, and it’s the main problem we use TEE to address.

What’s the worst that could happen?

In a normal Twitter app web service, the app owner retains raw access to the OAuth credentials. Even though the show only wanted to Tweet once, the app owner could hang on to the oauths after the show. They’d be tempted to use the oauths for just one more purpose. Lose them to malware where they’re sold to unscrupulous advertisers. Bots will shill their scam coins from your account and boot misinformation. Like in the  $OPENAI  hack.

Where do TEEs come in?

Basically we use TEE to proactively show none of those bad outcomes could have happened. We can show a chain-of-custody that explains the entirety of the software that was running, guaranteeing the following:

What is in the notice?

In this case, we create an on-chain event log of everything that happens during the show, including the twitter ID and Bobu’s tweet. This is on the Arbitrum blockchain, which is practically immutable. And that users were given a pointer to further mitigations, e.g., educating them that you can withdraw your consent at any time from the X settings page and tweets can be deleted.

665×592 56.9 KB

How do we ensure the chain of custody?

What’s the threat model?

Our goal is to produce a robust audit log, then the threat model includes malware on the server, the server getting hacked, malicious system administrators on the server. None of these should be able to scoop up all the Oauth codes. The “excessive use,” where we’re tempted to “make just one more post” and stretch the policy, is more of a salient attack than the “nation state misinformation campaign” attacker.

What are the other caveats?

This is just a prototype. We haven’t gone through a security audit yet! The performance is considered low-stakes, so we kept developing close to the demo. Some limitations are clear. There are dependencies on the QuickNode API provider, and the Arbitrum blockchain itself. The finality of this blockchain is responsible for the one-time use. So for example, malicious data from the QuickNode API could also disrupt this. Ideally, the TEE would be running a light client for a chain that’s resistant to re-orgs like what we did in  Sirrah 1 .

Where’s the ZK?

A cool blockchain-native trick with privacy… surely this must be enabled by trendy ZK tech? We frequently get this question, since ZK is a flexible set of privacy enhancing tools. The answer is “No”, and in fact ZK wouldn’t work for this. You simply can’t manage “Write” access to a web2 account with ZK alone. It is a little complicated to unpack. ZK and TEE are often substitutes (you can use either of them for a rollup proof) and usually complements too (if you use both, like multiprover, it’s defense in depth). But here, for handling credentials, ZK isn’t suitable at all (the prover would be able to steal the credentials). Sometimes MPC can split across, but still have to trust them not to collude. In principle “ZK, TEE, and MPC” all fit together in the future. But the present implementation of the Bobu magic show based on Teleport uses just TEE. We can’t rule out nation state attackers, or mistakes. But, we also aren’t using it to store your private keys. It’s appropriate for improved handling of Twitter credentials.

How about zkTLS?

In our view, zkTLS would not have been able to achieve the Bobu stunt. In zkTLS, if you require the user to make a credible commitment to an action, users will need to do a “push” where they perform the action first, and then submit to you a zkTLS proof. This means the user i) has to submit an economic bond, which makes the barrier of entry higher, and ii) can perform a liveness attack where they refuse to perform the action (at the penalty of being slashed). However with TEEs, it becomes a “pull” model, where the user only need to click once and the TEE will automatically perform the credible action. In short, zkTLS is “credible read” and TEEs enable “credible reads AND credible writes.” In the Bobu magic show, this credibility and privacy is only to the extent of the OAuth token (the account is still “owned” by the user, only the OAuth token is fully “owned” by the TEE). This is because magic shows are relatively low-stake, so partial  encumbrance 1  is enough. For other high-stake applications, we may consider full encumbrance 2  of web2 accounts.

What’s next?

Among the caveats like this, one of the most unsatisfying is: what twitter app could users have been shown? We want to make it so the X developer account owner couldn’t do a liveness attack on the show by revoking access to the keys. How can we do this? We could use account-encumbrance to show that only the bobutee.account.link url was the authorized one. It might be a good idea to serve the entire frontend from a website as well. 

So, how did it work out, and how do we critically examine the audit log?

Stay tuned for a follow up retro that digs into what the audit log reveals about how the show and our preparation for it went…… We’ll need another post to unpack it and apply the audit framework above to the actual on-chain and transparency log data sets we produced!