Devcon 6

I didn’t go to Devcon (the big Ehtereum developer’s conference) in Bogota this year, but it happens that I know someone who did, and they recommended some talks & panels to watch. Notes below.

Venkatesh Rao: Unlocking Civilizational Hypercomplexity with Ethereum

Venkat sees the social difference between Ethereum and Bitcoin being that Bitcoin is essentially an “alt-TINA” (TINA = “There is no alternative”; in this view, TINAs are maximalist winner-take-all world organizational philosophies) in the libertarian / self-sovereign individualist vein, while Ethereum seems to have become more of a platform that enables a multitude of different social organizational philosophies.

Ethereum seems to have space for the full (far) left to (far) right political spectrum and the ability to coexist (at least for some approaches?) with equivalent non-digital (“real”) systems. Venkat calls this “hypercomplexity”, which in this definition just means a system that can support multiple social/cultural movements (“narrative futures”) optimizing on orthogonal dimensions simultaneously. (Basically, you cannot judge the “worth” of these social systems relative to each other, only within their own contexts.)

Venkat sees “TINA” systems as evolutionary dead ends, while hypercomplex systems enable “Cambrian Explosion” events.

”[P]erfection of [a system] is achieved only by institutions on the point of collapse.”

  • Parkinson’s Law

“Civilization advances by extending the number of important operations which we can perform without thinking about them.

  • A. N. Whitehead

Venkat sees there being 6 great Whitehead(ian) civilizational advances so far:

So, does blockchain or machine learning (Venkat sees them as conceptually intertwined, even though I’m not 100% sure I buy the connection) represent another such advance?

“Perhaps crypt is the First Foundation, and machine learning is the Second Foundation (in the sense of Asimov’s Foundation stories).

  • Venkatesh Rao

Venkat thinks that Whitehead(ian) civilizational advances follow a Cynefin-like path: Chaotic > Complex > Complicated > Clear. At each stage both the danger to individuals and the freedom of individuals (in the sense of “ability to choose”) decreases. TINA systems are on the cusp of “complicated” and “clear”.

In Venkat’s view, increasingly “clear” systems eventually collapse back into chaos through crisis. Venkat doesn’t think that we can avoid crises, but does think that it may be possible to tweak systems as collapse nears so that when it comes, the actual crisis is much smaller (maybe even unnoticed by many), but that a period of controlled hypercomplex growth still occurs. (“Friendly chaos”?)

Venkat doesn’t think of this as resilience (battening down the hatches) or accelerationism (welcoming chaos). This is about pre-adaptation to crisis.

(Honestly, this all feels kinda hand-wavy to me…)

Venkat isn’t sure what this looks like, but suggests that it’s related to preferencing infinite over finite games and “building with subtraction”. Potential things to put in the pot:

(Some of this feels a bit “woo” to me…)

(Not sure what “exaptation” means…)

Aya Miyaguchi: Executing With Subtraction in the Infinite Garden

The Infinite Garden: Ethereum as a space for an infinite number of players, each growing and evolving to the greatest extent possible.

Alternately, the “infinite garden” as “infinite game”.

The core idea here is that the Ethereum Foundation should play a minimal role within the Ethereum ecosystem, devolving as much responsibility as possible. This a philosophy designed to resist the centralizing impulses that naturally emerge when stewarding a community. The Ethereum Foundation should not be a single point of failure, and its work should encourage all ecosystem participants to see themselves as also responsible for the maintenance of the Ethereum blockchain.

“Subtract to focus on what is most important.”

  • Aya Miyaguchi

The Ethereum Foundation should only do those things which it alone can do.

”[The Ethereum Foundation] believe[s] that Ethereum’s potential is too great for any single organization to own.”

  • Aya Miyaguchi

There are currently ~950 active Ethereum contributors, and ~5000 documentation translators (!!!).

Interesting - ENS is a spin-off from the Ethereum Foundation.

A lot of what the Ethereum Foundation seems to do today is to support other foundations (for example, Nomic and 0xPARC).

Subtraction is about balance and focus, for both organizations and individuals.

Isaac Patka: Exploiting Inattention & Optimism in DAOs

“Attention is the most scarce resource in DAOs.”

  • Isaac Patka

“Optimistic consensus relies on people paying attention.”

  • Isaac Patka

This is all about getting governance proposals passed because people aren’t paying attention and they time out (with default “pass” state).

WOW… The way Reality.ETH works is that someone asks a question of the oracle, the oracle then outputs it in a standard (but somewhat hard-to-parse) format, and then people respond “yes” or “no”. The problem is that the attacker can easily respond “yes”, and if no one disputes this then that malicious “yes” will be what gets written into the blockchain.

Zodiac modules essentially have superuser access to (Gnosis) Safes. This means that the Reality.ETH oracle (which is part of the Gnosis Zodiac) can be used to override the normal Safe multi-sig process!

When someone answers a question on Reality.ETH, they need to post a bond to answer the question. Someone can dispute this answer by putting down twice the current bond… A process that can continue ad infinitum. Bonds are awarded to the person whose answer becomes the “truth” on-chain (which means that the person whose answer gets written to the blockchain will not lose any ether and will get all of the ether from unaccepted answers).

There’s also arbitration and veto options, both of which happen during the Reality.ETH “cooldown” period (the time between when the final answer is locked and execution occurs). These would provide some protection, except that the Reality.ETH arbiter is often set to the DAO itself, and (more importantly), the cooldown period is often set to zero!

Common misconfigurations:

All of these misconfigurations have (and are) being exploited on MainNet…

DOUBLE WOW… Reality.ETH displays transactions as hashes (which maybe it has to do?), which means that it’s impossible to know what the attacker is trying to do from within the oracle!

Cooldown periods of 24 hours are common, and turns out to be too short in practice.

Moloch DAOs are also vulnerable to inattention attacks.

This is basically A05 (“Security Misconfiguration”) from the OWASP Top 10…

Patka actually suggests developing a SOC2-like process for DAOs to figure out their internal process.

Call out to something called OpenZeppelin Defender for automating safe security.

An interesting point here that one way to make these attacks harder is to minimize governance decisions. Use automation so that decisions are only made when something changes, not when something needs to be done. This would allow for longer voting periods, etc.

Chris Cassano and David Sneider: Decentralized Programmable Key Pairs

This is about the “Lit Protocol”.

This is about distributed key generation, custody, and management - private keys are basically sharded between nodes. All node operations happen in a trusted environment, and node operators have a stake in ensuring correct operation (like Ethereum staking?).

The Lit nodes do the actual encryption/decryption using the sharded private key. It sounds like actual cryptographic operations in this system are handled with symmetric keys, with the public/private key system being used to secure these. It’s the (one-off?) symmetric keys that are actually transmitted to the client by Lit nodes (the client handles actual key reconstruction).

This basically allows for blockchain-based DRM. It can also provide wallet-like login capabilities tied to on-chain DIDs. Lit nodes can also run programs hosted at specified IPFS hashes to enable on-chain transactions to be created and signed.

So, “cloud wallets”… Or “wallets as NFTs”?

Interesting… Passkeys and other FIDO methods can potentially be used as part of the verification process for these on-chain keys.

Okay, it really is “wallets as NFTs” - on-chain NFTs are tied to ECDSA keypairs sharded into Lit nodes. Lit uses JavaScript as its runtime (ack!). Initial requests need to be signed, so this isn’t eliminating user-held keypairs; however, this signature isn’t limited to wallets, which mean that FIDO tokens, etc. can also be used.

Lit is (relatively) output-agnostic - it ultimately just signs things, and doesn’t care if those signatures are on a blockchain, IPFS, or whatever.

One pattern Lit enables is that a smart contract using Lit can mint a keypair, sign something, and then burn the keypair in a single atomic action. The idea here is to preserve a record of the request-action chain while preventing the keypair from being used again. The idea here reminds me a bit of tap-to-pay credit card systems.

Heh. Lit breaks wallet-bound (aka, “soul bound”) tokens, as it basically is allowing wallets to be traded (since wallet access is determined by an on-chain - tradable - NFT). Lit also enables automation without having to store a hot wallet on a server somewhere.

Analogy: Lit functions are like Amazon Lambda, while Lit keypairs are like a distribute version of Amazon KMS.

The devs seem to be maintaining that encryption isn’t necessary for the protocol. Which makes some sense, as the initial request is signed. But it’s not clear to me why the network response isn’t (potentially) sensitive.

The Lit network recalculates all shards when nodes join or leave in a way that ensures that shards are incompatible across epochs. (How well does this scale?!?)

Lit is based on threshold cryptography. Keypairs can be reconstructed using key data from two-thirds of the available nodes.

(It seems like the key here is the security of the Lit nodes. What happens if a node is malicious or compromised? Attacks could be conducted against either the key material itself, or Lit functions; the fact that Lit functions use JavaScript for their runtime doesn’t exactly fill me with confidence…)

Julien Niset: Why Account Abstraction is a Game-Changer for Dapps

There are two types of Ethereum accounts - “externally owned accounts” (EOAs) and “contract accounts” (CAs). EOAs are wallets - they have an address, a (changing) nonce, and some ETH balance - and are identified/controlled by an ECDSA keypair (the address is derived from the public key, but signing is - of course! - done using the private key). (I’m guessing that CAs are just smart contracts…)

But cryptographic key management is hard, and in Ethereum the concept of a signer and the concept of an account (EOA) are (currently) identical…

So the idea here is to decouple the signer from the account by using a smart contract as an intermediary (“every account is a smart contract”). This is Kei Kreutler’s “Inventories, Not Identities” thesis. It’s also a bit like something that I’ve seen many folks working on blockchains recommend - using (Gnosis) Safe or something similar to manage funds/tokens/etc. with multiple signatures tied to different wallets controlled by the same user.

It seems like Vitalik has been pushing this idea “behind the scenes” via EIPs. EIP-4337 is the current version of this proposal, though there’s apparently a new EIP in the works that will replace this.

Some L2 networks (StarkNet and ZkSync) are moving forward with using smart contracts for account abstraction, even though the underlying Ethereum chain doesn’t (yet) support this.

One cool think StarkNet is doing with its account abstraction system is “social recovery”. Basically, this is a second key that has permission to replace the signing key for the smart contract with another key. The idea is that this “social recovery key” will be given to a trusted third party, who can then use it to replace the current signing key in the event that this key is lost or compromised. (This reminds me a bit of an idea I had regarding Google account recovery when pondering how to help people without stable access to a second factor recover their account without giving up on the protection provided by multi-factor authentication.)

This “social recovery key” doesn’t have to be a person - it can also be a service, or even a hardware device. (It’s not clear to me about the process for replacing a “social recovery key”. If the user key can do this directly, what’s to stop an attacker from just replacing this key to gain full control over the wallet? So, presumably, replacing the “social recovery key” will either require both that key and the user key, or can only be initiated by the “social recovery key” itself.)

Additional keys could also be used for other services, such as fraud monitoring. This would basically be implemented by turning the underlying smart contract into a multisig, with the second key always automatically approving any transaction initiated by the (user-held) key unless it suspects fraud (in which some additional authentication channel would be used to verify the user’s intention).

This also enables temporary session keys for a dapp - something that’s held in browser and is granted only a limited lifetime and permissions to act on behalf of the underlying smart contract. These keys can be slaved to specific contracts, have limited access to funds/tokens, etc.

Also, account plugins? (Sounds like Gnosis’ Zodiac modules…)

Interesting overlap here between the StarkNet account abstraction and the work of the Lit Protocol - StarkNet is investigating using the secure enclave of phones/computers to perform the initial signature operations, instead of holding the private key in the wallet app/extension (this is possible because smart contracts can verify off-chain signatures).

(My instinct is to be wary of the Lit Protocol - there’s a lot of places where sharded key management can go wrong. But account abstraction seems like a much safer proposal…)