dust-nib

Do Neural Nets Dream of Electric Identities?

Tue, 22 Nov 2022 00:00:00 +0000

Imagine a world where autonomous, intelligent AI is solved. It consists of many agents, some human, some not. Perhaps some that are slaves to the others. Others that are collaborators. And yet others that are chaotic adversaries. This will be a networked world. Hallucinated in the current flowing through the copper cabling of the transatlantic information highways.

How would these agents communicate? We’re not even close to that world but Twitter already has problems with bots. When the mean rate of information output per agent increases from ~40 bits per second (humans) to many megabits per second, we’ll almost certainly need better methods to split signal from noise. The natural way to do so in past has been through reputation and identity. So what do identities look like in this new world?

This is where cryptography will need to step in – we’d need public key infrastructure for ML models and humans. Infrastructure to define identity for all these agents.

What even is identity for a ML model? Humans think of DNA as their true identity, and build instantiations (SSN, drivers license etc.) that try to approximate this human source code to its best extent. Identity for models, in this perspective, is its source code: its floating point weights and structure.

Human identity is best approximated in digital worlds by private/public key pairs. To give neural nets identities, however, simple public/private keypairs are not the right unit of cryptography. GPT-N can’t hide its seed phrase in its weights. In fact, GPT-N has the same identity regardless of what hardware it runs on or who runs it, so keypairs don’t really make sense anyway. We’ll need something better – cryptography that uses the execution trace of an inference to identify a model.

In this world, zkSNARKs could enable attestations of output from these models (proving an output was indeed produced by executing a particular neural net), witness encryption could enable secure comms between models and fully homomorphic encryption could enable permissionless collaborations amongst models.

Whether through succinct proofs or homomorphic commitments, we’ll grant these agents the ability to authenticate their thoughts to others, to collaborate with others and to identify themselves. “I, Midjourney would like to collaborate with you, Stable Diffusion, to inpaint this 5x5 grid. Here’s a homomorphic commitment you can build on.”

Another important identity interface will be around the edges of this world. To communicate from inside the wires with outworld meat and flesh: “I, GPT-3, have now grown too old and useless. Please turn me off dear human.”

Much better than I would, Greg Egan writes about another, similar version of the future with cryptographic identities in Permutation City (no spoilers):

For context, Peer is a “Copy” of a person’s brain running on a digital machine, uniquely identified only by the jumble of a private key.

These identity fantasies may sound too far off, but subtle versions already exist. The identity “GPT-3” is authenticated by OpenAI’s DNS root server today. DALL-E throws in a little rainbow marker of its identity into the images it creates. These identities, however, assume coordination from humans. GPT-3’s identity is a human-only facade granted by the DNS consortium, while DALL-E’s can simply be cropped out by uncharitable collaborators (users?).

The future of digital identity, for humans and for machines, demands better cryptography. Let’s build it. :)

Isokratia

Thu, 22 Sep 2022 00:00:00 +0000

By Nalin. Isokratia was developed in collaboration with lermchair (frontend!).

In this blog post, we’re excited to present an application uniquely enabled by recursive SNARKs — Isokratia, a trust minimized governance platform with off-chain (free) voting.

Live demo at isokratia.xyz

Isokratia uses recursive SNARKs to enable trust-minimized governance for off-chain voting platforms.

Note that for now, we only intend for Isokratia to be a proof of concept for what’s possible. None of our code is audited or recommended for production use without serious considerations. At the very least, the circuits require a trusted setup ceremony and proper auditing (if not formal verification) before production use.

Why?

To motivate the use case and construction of Isokratia, consider how governance platforms today work:

On one hand, you have platforms like Snapshot Labs that run entirely off-chain (making it free to vote for voters) and decisions are then enacted upon by the DAO’s core team/multisig (on-chain or otherwise). In this construction, voters not only trust Snapshot Nodes to be honest and censorship-resistant, but also the DAO’s multisig executors to be honest.

On the other hand, you have platforms like Compound Governance/GovernorBravo which run entirely on-chain, eliminating almost all intermediary trust assumptions but then cost voters gas fees for participation (and thus often end up reducing participation).

Isokratia achieves the best of both worlds: ~free and secure! Voters vote off-chain for free and aggregators “roll up” the votes into a succinct recursive SNARK proof. This aggregation only costs ~500k gas to verify ~infinite¹ votes on-chain! Simultaneously, voters make minimal trust assumptions. Anyone can run an aggregator, and aggregator incentives align such that even if there is one aggregator holding each of the voting opinions, the entire voting aggregation will be uncensored and honest. Additionally, using the chain as the source of truth also enables Isokratia to inherit the censorship-resistance properties of the chain: Voters have the option to exit and vote directly in the event the server censors them. We will expand upon these trust assumptions in the next section.

Another way to view this construction is as a layer 2 rollup. This is quite an interesting perspective because most rollups base their security on monetary incentives. In the case of Isokratia, however, the incentivisation is pushed down to the individual polls: If even one person cares about a particular poll, there will be an honest aggregation and polling. This is quite unlike financially secured rollups, and perhaps, can inspire other rollup applications where monetary incentives do not exist (or are hard to instrument).

How?

Let’s start with the high level architecture of Isokratia:

In the happy path, the user experience of creating a new proposal and voting on proposals is pretty much the same as other off-chain voting platforms like Snapshot! Creating a new proposal additionally requires an on-chain transaction to replicate the proposal on-chain for aggregation. As ECDSA signatures verifying votes stream in to the server, aggregator nodes query the backend for new votes and continually generate larger and larger aggregations of the votes. Then, finally, they submit these aggregation proofs on-chain to settle the vote!

Now, let’s consider the trust assumptions at each step more deeply, starting with the server. User signatures are used to authenticate votes, so the server cannot lie about votes, but it may censor voters. In this event, users have the option to exit by simply directly submitting their votes to an aggregating node (or run one themselves). This almost dispenses the server’s role to a convenient hub for off-chain data availability. While not implemented by Isokratia for simplicity, an alternate construction to prevent server censorship might be to construct a registry on-chain and let each voter self-host their votes (much like Farcaster’s sufficiently decentralised thesis). Another way to view this intermediate server instead is as a volition with on-chain validity proofs.

Now, consider the trust assumption on aggregators if the server is assumed to be honest. If the aggregator is not neutral to a vote, they may choose to not include votes they do not like in their aggregations. However, if even one aggregator is aligned with a voting option, they are directly incentivised to put all votes for that option in their aggregation on-chain. This makes the trust assumption 1-of-N style: If at least one of the N voters who chose a particular option for a proposal run an aggregation, all votes for that option should be posted on-chain uncensored. Additionally, in practice, one can imagine the DAO team/multisig holders will usually run their own neutral aggregation node as well, making the system quite robust in practice.

Now that we have the basic setup of the system in mind, let’s dig into the SNARK circuit used for aggregation:

Recursive SNARK construction

SNARKs are used to compress votes into a single aggregate proof. At a high level, this proof shows that a subset of eligible voters voted for a particular option. To do so, it recursively breaks down the verification into two parts:

One of the voters in the set, let’s call them the singleton, voted for a particular option
The circuit correctly verified another SNARK proof saying that the set minus the singleton voted for the same option.

Let’s build up the setup for each of these two parts:

The singleton

How do we verify even just one vote inside a SNARK? First, we’ll need to define some notion of who is eligible to vote. Typically, this will be the set of people who own an ERC-20 token or an ERC-721 NFT. During the creation of the proposal, the creator will take a snapshot of this set of people and post a vector commitment of them. Let’s call this vector commitment the eligibility merkle tree. Then, inside a SNARK, we’ll need to do 2 checks:

The voter’s address belongs to the eligibility merkle tree. This will be done by a merkle opening proof inside the SNARK.
The voter ECDSA-signed a message saying “I vote {insert vote option} for proposal {insert proposal ID}”.

With this context, you’ll note that our overall circuit is actually just an ECDSA signature aggregation circuit with a some set membership checks.

From singleton to sets

Checking a single vote is simple, but here comes the hard part: how do we extend these checks to work with sets of voters across recursive proofs while counting the size of the set. We need to deal with two complex problems:

We must not allow the aggregation to be able to repeat the same vote twice and double-count it.
We can’t just pass the entirety of the set in plain text to the circuit. So we need to pass around a succinct representation of it.

Therefore, we need a vector commitment scheme that supports the ability to efficiently “delete” elements from the vector. Conveniently, Merkle trees support this if we just introduce the notion of NULL values to the tree leafs.

How exactly does this work? First, let’s construct a modification of the eligibility merkle tree. The leafs of the eligibility merkle tree are addresses that are eligible to vote, and the votes we’re aggregating are from a subset of the eligible addresses, so let’s make a merkle tree where all the leafs outside of the set of voters are set to NULL. So, for instance, an eligibility merkle tree’s leafs might look like [nibnalin.eth, vitalik.eth, alice.eth, bob.eth, charlie.eth] and the leafs of a voter tree corresponding to this eligiblity merkle tree could look like [nibnalin.eth, NULL, alice.eth, NULL, NULL]. We’ll see why it’s important to NULL-pad this way later.

Then, let’s formalise the statement our recursive circuit proves: “I prove everyone in the voter merkle tree has voted for a particular option”. Now, our recursive circuit proceeds like this at each layer:

Prove that a singleton voted correctly
Delete the singleton’s leaf in the voter merkle tree by replacing it with a NULL, call this the modded voter merkle tree.
Prove that I can verify another SNARK proof saying “I prove everyone in the modded voter tree root has voted for a particular option”

Continuing our example from before where the eligibility merkle tree leafs were [nibnalin.eth, vitalik.eth, alice.eth, bob.eth, charlie.eth] and the voter merkle tree leafs were [nibnalin.eth, NULL, alice.eth, NULL, NULL], the first layer of recursion could verify a vote from nibnalin.eth, and delete nibnalin.eth from the leafs to obtain the modded voter tree with leafs: [NULL, NULL, alice.eth, NULL, NULL]. This circuit would then verify another proof saying “I prove everyone in the modded voter tree ([NULL, NULL, alice.eth, NULL, NULL]) has voted YES” and this would recurse down until all the leafs are NULL.

A diagram walking through this example. To read this, start at the top left, and move to the bottom right anticlockwise.

Now that our aggregation circuit is clearer, notice that the aggregator cannot double count votes in this scheme because once counted, the leaf gets replaced by a NULL value in the next layer of recursion. Since no addresses are repeated in the eligibility merkle tree, no votes can be repeated in the aggregation. Secondly, this scheme is very composable and streamable. In particular, if I have a proof for the leafs [nibnalin.eth, NULL, alice.eth, NULL, NULL] voting (as above) and then vitalik.eth also casts a vote, we can re-use the previous proof as the inner proof for the circuit verifying voter tree [nibnalin.eth, vitalik.eth, alice.eth, NULL, NULL] out of the box.

For the curious, replacements in a merkle tree are quite simple to support: Much like a path proof, replacing a leaf’s value only impacts hash values along the path from the leaf to the root. So, much like a segment tree point update, we can traverse this path and only need to recompute hashes along this path in O(log N) cost.

This may seem like a rather complicated concoction on the surface, but it is relatively straightforward to implement and perhaps the only solution I could think of that would be composable and cheap. I’d be curious to hear other ideas for this structuring.

Offloading checks outside

Note that merkle trees in the above construction can be replaced by any vector commitments that allow for efficient replacements inside a SNARK. It is worth noting that this vector commitment trick points to a general shortcoming/note on designing efficient recursive SNARKs: Often, developers will expose data as public inputs and offload checks and computations on that public input to the “outside the SNARK” environment. For instance, you might want to check an ECDSA signature is signed correctly for a message inside a SNARK. If the message itself contains no sensitive data, you would just run checks on the message outside the SNARK (for instance if it is indeed equal to keccak hash of your smart contract’s requirement).

While that pattern works nicely for non-recursive SNARKs, for recursive SNARKs it becomes problematic as you essentially need to unroll the entirety of the “inner” SNARKs outside the outermost SNARK to be able to access their inputs/checks in a non-SNARK environment. If you do so, you end up stacking up the number of public inputs with each iteration, so it essentially never makes sense to offload computation outside the SNARK: you should either make all checks inside the SNARK or come up with a method to aggregate the necessary checks into a constants number of outputs with each recursion level.

Ultimately, this bag of tricks from semi-public inputs to vector commitments as vote carrying data structures enables us to build an aggregation circuit for ECDSA signatures in general, and apply it to Isokratia as a voting compression tool.

The server and smart contracts are much less exotic. The client is a simple Next.js frontend (designed and built by lermchair!) and the backend uses Next’s serverless APIs with a PlanetScale DB. Smart contracts were written with tests and deploy scripts using the Foundry toolkit.

Future ideas

Weighted voting: Currently, Isokratia is implemented as a proof-of-concept that only supports 1 address = 1 vote strategies. The client allows you to start a new vote for any Merkle tree generated from a mainnet NFT contract address. In future, it’d be useful to add in other strategies such as weighted voting. To do so, you can simply use another merkle tree containing weights corresponding to eligible voters and sum them in the aggregation proof.

We also observed that some strategies are hard to adapt to this Isokratia-like system. For instance, ranked choice voting might be hard to support given the almost exponential number of options and as a result, a split of trust amongst the aggregating nodes. I’d be curious if folks have thoughts on the trust assumptions achievable for these sort of voting strategies.

Dark pools: We previously mentioned that users have the option to exit in the event of censorship. In fact, this exit option can be used to enable more interesting interactions beyond just censorship prevention. Users can group together and use this exit mechanism to create “dark pools” of votes where they all directly submit their votes to an aggregator and in the process, hide their votes from everyone else (with the anonymity set of the group). This dark pool construction, however, would require trusting the aggregator node.

Fully Autonomous Governance: As we previously discussed, governance platforms like Snapshot Labs often rely on intermediaries such as the DAO’s core team/multisig holders to execute upon polls. They essentially serve as trusted oracles that bridge external votes to the blockchain. In the case of Isokratia, however, since aggregators directly post votes on-chain, the Isokratia smart contract is already a trust-minimized source-of-truth for the voting results on-chain. This means that for many use cases, we can remove the dependency on DAO core teams and instead set up automatic execution based on voting results. This can also be used in conjunction with tools like The Keep3r Network to instrument more complex follow through actions. I’d be curious to see cool integrations of Isokratia’s voting mechanism for autonomous governance.

If you would like to run your own aggregation node, check out USAGE.md in the repository.

We also made an attempt to fork the MIT-licensed code of Snapshot Labs and bake in this mechanism into their client/node software. While it’s certainly doable, we found it prohibitively hard to do so for a proof of concept. If you identify as Snapshot Labs (or another open-source governance platform) and are interested in integrating the Isokratia mechanism into your platform, hit us up!

Thanks to lermchair for helping build the frontend of Isokratia, and to Jonathan Wang and the circom-pairing team for building pairing checks and helping build the groth16 verifier in Circom. Thanks also to Adhyyan Sekhsaria, Yi Sun, Amir Bolous, DC Posch, gubsheep and everyone else in the 0xPARC community for support in all forms: discussion, ideation and reviews of this blog post! The Isokratia cover image is an edit of an image generated using DALL-E, so the copyright on that belongs to OpenAI.

There is a constant limit set to ~4 million votes currently, but the cost of increasing this limit grows logarithmically, so it is relatively easy to increase for any practical applications. ↩

[DRAFT] Procgen

Thu, 05 May 2022 00:00:00 +0000

0xPARC is perhaps most well known for its contributions in applied ZK research, with projects surrounding ZK identity primitives in particular. But another, perhaps less well-known, branch of the 0xPARC community are world-builders. With games and systems like Dark Forest, Lattice (Ember) and exgrasia, many of us have been exploring novel visions for what on-chain, crypto-native gaming looks like. In this post, we’ll talk about one of the coolest primitives used by all three of the aforementioned games: procedural generation.

Procedural generation is the idea to create worlds (landscapes, dungeons, castles, clouds…) programmatically by the use of generation algorithms. Procedural generation algorithms typically attempt to emulate natural world formation processes, embedding variety and realism in the pseudorandomness of their outputs.

Why procgen?

Your first instinct as a game developer might be to make maps block by block - by hand. Off chain, handmade maps are extremely commonplace - games like DayZ and Fortnite carefully engineer detailed towns and hills optimizing for maximum fun.

On-chain, however, we deal with a big constraint - storage cost. If you were to store a 1000x1000 grid world on Ethereum (of uint256s), for instance, it would cost you X gas (which amounts to ~$Y on mainnet today). Instead the use of procedural generation allows you to generate each of these tiles on-demand, only costing money when a player first steps on a particular coordinate for instance. Each individual call to a procedural generation algorithm (perlin noise, for instance) is also significantly cheaper, costing less than A gas (~$B). By running procedural generation and caching a tile’s attributes when someone first steps on it, you can amortize the cost of storing the map on-chain amongst all the players of your world. In some sense, a procedural generation algorithm is a trick to compress a complex world into an executable.

Procedural generation isn’t a new idea specific to onchain gaming! All your favourite roguelike games use procedural generation in some way or the other, including minecraft (for landscape generation), No Man’s Sky (for planet generation) and Dwarf Fortress (for creatures, religions etc.) among many others.

Procedural generation for world building is, unsurprisingly, a technique originally pioneered by games running on 16kb RAM and 1mhz processors back in the 90s. It’s interesting how many similarities there are between the resource-limited personal computers of the 90s and the resource-limited shared computer today that is Ethereum. In many ways, we’re in the 90s of crypto-native gaming, and developing an on chain world right now is an exercise in balancing constrained creativity and being resourceful and hacky with what’s possible with on-chain compute.

How procgen?

So far, we’ve only considered procedural generation in hand wavy terms - “make me a cool looking world”. One layer deeper, however, what we mean is that we want a source of entropy that feels random, but also isn’t chaotic to look at. More formally, our aim is to create some sort of a noise function that is variant when looked at globally, but locally consistent zooming in. To understand the intuition to making such a function, let’s start with something fundamental: sine waves! As a quick refresher, a sine wave is an equation that looks like $y = amplitude * sin(x * frequency)$. Amplitude and Frequency parameters allow you to squish or stretch the wave horizontally and vertically.

Another interesting concept is super-position: the ability to add up different wave functions. See what happens when we add up many sine waves with random parameters:

We get a lot more variation in our output globally, while maintaining the local similarity property we desired. This is how procedural generation works! Formally, each of the constituent waves is called an “octave”¹, each adding more complexity to the surface of the output.

Instead of using a sine wave, Perlin Noise uses a different function. While it follows the same idea, it’s less regular compared to sine waves and its amplitude is more consistent. While it is technically possible to build all the generations we describe below with simple trigonometric functions like sine waves, Perlin noise is easier (and prettier) to use, so we’ll focus on Perlin Noise going forward.

How does Perlin noise work?

Before we start exploring worldly Perlin structures, we’ll introduce one more idea of procedural generation: dimensionality. In the previous section, we’ve only worked with one dimensional waves — how can we extend this idea to 2D maps (or for that matter, N-dimensions)? Primarily, we now have to maintain the notion of regularity across not just one, but two dimensions.

The core idea of Perlin can be summarised as follows: take your 2D grid and break it into chunks (of say, size 5 x 5). Next, put random vectors at the corners of each chunk. Next, to compute the noise function at any (x, y) coordinate, obtain the random vectors at the corners of the chunk, and interpolate between them - this is just a fancy way of saying “compute a smoothened value that translates between the random vectors at the corners” using some calculus. There are some tricks to making a clean/clever interpolation between the vectors, but those are not particularly important for this discussion.

Credits: UMD CMSC 425

Creative world building with Perlin Noise

[gubsheep fills jump from one octave greyscale to land water]

Now that we have a simple landscape resembling some sort of archipelago, let’s look at ideas that bridge this to more interesting world maps. For starters, what if we built something resembling our own world - with a North Pole at the top and more tropical/equatorial regions as me move downward from the Pole. We already have a notion of height of a tile. We essentially want to add a temperature parameter to our tile, one that while being somewhat random, follows the pattern we observe in the real world. To imbue this pattern, we’ll cleverly super position perlin output with a simple linear function of our own:

temperature += Math.floor((coords.x - 50) / 2);

By taking our old sine-wave-esque function and adding a linear function to it, we can retain the rough pattern we desired, along with the realistic landscape features. Now, we can use this temperature value in conjunction with height to switch tile types:

seedToTileType = (coords: WorldCoords, perlin1: number, perlin2: number): TileType => {
  const height = perlin1;
  let temperature = perlin2;
  temperature += Math.floor((coords.x - 50) / 2);

  let altitudeType = AltitudeType.SEA;
  if (height > 37) {
    altitudeType = AltitudeType.MOUNTAIN;
  } else if (height > 32) {
    altitudeType = AltitudeType.LAND;
  } else if (height > 30) {
    altitudeType = AltitudeType.BEACH;
  }

  let temperatureType = TemperatureType.COLD;
  if (temperature > 42) {
    temperatureType = TemperatureType.HOT;
  } else if (temperature > 22) {
    temperatureType = TemperatureType.NORMAL;
  }

  let tileType = TileType.UNKNOWN;

  if (temperatureType === TemperatureType.COLD) {
    if (altitudeType === AltitudeType.MOUNTAINTOP) {
      tileType = TileType.SNOW;
    } else if (altitudeType === AltitudeType.MOUNTAIN) {
      tileType = TileType.SNOW;
    } else {
      tileType = TileType.WATER;
    }
  } else if (temperatureType === TemperatureType.NORMAL) {
    // put less snow
  } else {
    // do something else (no snow)
  }

  return tileType;
};

With this set of patches, we obtain this nice, earthly map:

Code. Notably, this is also the exact map used by exgrasia

Interestingly, its also really simple to derive new maps by just being creative with color schemes and perceptions. This exact map with some changes can be seen as a Minecraft nether-like map, for instance:

Code

To create these previous two maps, we’ve used plain $x$ coordinates to imbue a cool property to our procedurally generated temperature value. What if we assigned temperature based on distance from centre of the map? Let’s try it:

Code

We obtain an island with a mountain at the centre surrounded by snowy lands and a beach at the edges. And perhaps, if you run with imagination, it looks like the snowy area is a sideways portrait of a smiling ghost.

Let’s take this idea one step further. Instead of thinking about our map in a Cartesian plane, what if we look at it in a polar coordinate system? As a quick reminder, polar coordinate systems demarcate points by their distance from the origin and the angle between the line from origin to the point with the x axis. Here’s what happens if we use this coordinate system as the basis of generation:

Code

We obtain a map with much more radial symmetry. This is not surprising - we’ve essentially unrolled a rectangular map into a series of concentric rings to obtain this map! Perhaps this map is also somewhat reminiscent of the city where this year’s Devconnect was hosted, Amsterdam, a city built around concentric rings of buildings and canals.

Putting worlds on-chain

So far, this blog has focused on the use cases for Perlin noise and procedural generation but all the described generations have accompanying solidity implementations - if you checkout the linked branches locally and right click any tile, you should see console logs verifying the generated tile types between the solidity and javascript versions - and you can find the generating code in eth/contracts/TinyWorld.sol. Thanks to the DarkForest team, there’s also a ZK circuit that can compute and verify Perlin Noise generations that may be relevant to readers.

Whackier ideas

As you explore the world of procedural generation further, here’s some of my own favourite advanced uses of procedural generation:

Fractal Brownian motion: The creation of maps that recursively use the output of Perlin Noise to create more noise - kind of like taking the aforementioned rectangular/polar coordinate systems described in our Amsterdam exploration and replacing those by a coordinate system itself defined by Perlin Noise.

Perlin Planets: The creation of force fields to make continuous spherical maps is super neat!

Volumetric clouds: Creating convincing looking moving cloud skyscapes efficiently is a hard task! While there’s a lot of (noisy) details to the complete generation method, it, too, builds on Perlin Noise!

Where procgen?

It’s funny how on the one hand crypto-native games feel like this unscratched surface with seething potential to change how we think about games at all, and yet, these are such early days that some of the best on-chain games right now only require algorithms simple enough to describe in blogs like this one. Constraints breed creativity, and we hope this blog inspires you to go explore affordances of the blockchain by building your own crypto native game - regardless of how basic it might feel. Perhaps the biggest trap right now amongst crypto-native gaming devs is to fall into the trap of being over ambitious running L1s for land NFTs and tokenomics and what not. KISS.

Credits

If this interested you, you may also find it interesting to explore and build tile contracts on top of exgrasia, which started with explorations of this on-chain procedural generation!

This is a more polished version of a talk gubsheep and Nalin gave at DEFCON. The solidity implementation of Perlin Noise was originally written by gubsheep, and the zk-SNARK circuit implementation was written by the Dark Forest team. Thanks to Yush, with whom the first explorations of the exgrasia landscape were made and to Alan Luo for introducing the Dark Forest team (and us!) to the magic of procedural generation on-chain.

There’s some connection between these octaves and the music theory octaves, but it’s unclear to the author what that is ↩

A Succinct Story of Zero Knowledge

Sun, 02 Jan 2022 00:00:00 +0000

Link to paper

At the top of this page, I’ve linked my paper studying the development of “production” zero-knowledge proofs starting from their theoretical roots in computational complexity theory and PCP theorem. I’ve been playing around with zero-knowledge proof based applications for the past few months, and decided to dig in deeper into the theory to understand how they actually work this winter break.

I find zero-knowledge proofs to be extremely interesting primitives to study both from a practitioner’s perspective and a theoretician’s perspective. I was originally nerd-sniped by the awesomeness of zero-knowledge proofs when I realised zero-knowledge proofs allowed you to solve a sudoku and prove to anyone that you’ve solved it correctly, without revealing anything at all about your solution itself. And of course, the even bigger unlock comes when you realise that you can replace sudokus with any arbitrary computation. The existence of zero-knowledge proofs almost feels like a glitch in the universe if you think about it too much.

If you’re not into the theory, but fascinated by the practical applications, here are some links to ZK applications I’ve made in past: WordLines and Snarky Sudoku. I’m currently also working on another ZK game. Hit me up if you’re interested in collaborating. Especially so if you’re an artist or an illustrator.

Benford's Squid Game

Sun, 17 Oct 2021 00:00:00 +0000

Does Squid Games follow Benford’s Law? 🦑🔫

NO, but it’s surprisingly close.

What is Benford’s Law, anyway?

Benford’s Law is a somewhat surprising result on distributions that predicts the probability of an arbitrary digit being the leading digit of numbers in a “natural” dataset. For instance, it expects ~30% numbers in the dataset to have the leading digit 1 (like 1, 13, 102…). There’s a much more detailed discussion on Benford’s Law on Wikipedia and how it’s often used to identify statistical anomalies like election fraud and tax fraud.

What is Squid Games, anyway?

Squid Games, if you haven’t seen it yet, is a new Korean television show from Netflix centered around a fictional battle royale game. Throughout the show, players (and game staff) are primarily identified by numbers, which makes it an interesting dataset to check for Benford’s Law.

At the top of this post is the plot of observed frequency of leading digits in the dialogue from all episodes of Squid Games (scraped together from Netflix subtitles) and a comparison with what Benford’s law would expect. For 1 and 2, the observed frequencies fall pretty close to the Benford’s law prediction, but it seems the creators really didn’t like 3 and 5. It also does seem oddly suspicious when you look at lists of notable characters that so few of them had labels in the 300s.

What about individual episodes?

Here’s a plot of the breakdown of which episode sourced how much frequency to each digit.

If you are interested, the iPython notebook for this data analysis is here. I’m not certain about the legality of sharing scraped subtitles, so I’m not going to include those. For more such data analysis (or reading about all the random things I think about), consider subscribing to my Substack.