Vitalik Buterin's websiteWriting by Vitalik Buterin
https://vitalik.ca/
Wed, 22 Jul 2020 07:59:54 -0700Wed, 22 Jul 2020 07:59:54 -0700Jekyll v3.7.2Gitcoin Grants Round 6 Retrospective<p>Round 6 of Gitcoin Grants has just finished, with $227,847 in contributions from 1,526 contributors and $175,000 in matched funds distributed across 695 projects. This time around, we had three categories: the two usual categories of "tech" and "community" (the latter renamed from "media" to reflect a desire for a broad emphasis), and the round-6-special category Crypto For Black Lives.</p>
<p>First of all, here are the results, starting with the tech and community sections:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round6/tech.jpg" style="width:350px" /> <img src="http://vitalik.ca/files/posts_files/round6/community.jpg" style="width:350px" /> <br>
</center>
<h3 id="stability-of-income">Stability of income</h3>
<p>In the last round, one <a href="https://vitalik.ca/general/2020/04/30/round5.html">concern I raised</a> was stability of income. People trying to earn a livelihood off of quadratic funding grants would want to have some guarantee that their income isn't going to completely disappear in the next round just because the hive mind suddenly gets excited about something else.</p>
<p>Round 6 had two mechanisms to try to provide more stability of income:</p>
<ol type="1">
<li>A "shopping cart" interface for giving many contributions, with an explicit "repeat your contributions from the last round" feature</li>
<li>A rule that the matching amounts are calculated using not just contributions from this round, but also "carrying over" 1/3 of the contributions from the previous round (ie. if you made a $10 grant in the previous round, the matching formula would pretend you made a $10 grant in the previous round and also a $3.33 grant this round)</li>
</ol>
<ol type="1">
<li>was clearly successful at one goal: increasing the total number of contributions. But its effect in ensuring stability of income is hard to measure. The effect of (2), on the other hand, is easy to measure, because we have stats for the actual matching amount as well as what the matching amount "would have been" if the 1/3 carry-over rule was not in place.</li>
</ol>
<p>First from the tech category:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round6/techtable.png" />
</center>
<p><br></p>
<p>Now from the community category:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round6/communitytable.png" />
</center>
<p><br></p>
<p>Clearly, the rule helps reduce volatility, pretty much exactly as expected. That said, one could argue that this result is trivial: you could argue that all that's going on here is something very similar to grabbing part of the revenue from round N (eg. see how the new EIP-1559 Community Fund earned less than it otherwise would have) and moving it into round N+1. Sure, numerically speaking the revenues are more "stable", but individual projects could have just provided this stability to themselves by only spending 2/3 of the pot from each round, and using the remaining third later when some future round is unexpectedly low. Why should the quadratic funding mechanism significantly increase its complexity just to achieve a gain in stability that projects could simply provide for themselves?</p>
<p>My instinct says that it would be best to try the next round with the "repeat last round" feature but <em>without</em> the 1/3 carryover, and see what happens. Particularly, note that the numbers seem to show that the media section would have been "stable enough" even without the carryover. The tech section was more volatile, but only because of the sudden entrance of the EIP 1559 community fund; it would be part of the experiment to see just how common that kind of situation is.</p>
<h3 id="about-that-eip-1559-community-fund...">About that EIP 1559 Community fund...</h3>
<p>The big unexpected winner of this round was the EIP 1559 community fund. EIP 1559 (EIP <a href="https://github.com/ethereum/EIPs/issues/1559">here</a>, FAQ <a href="https://notes.ethereum.org/Wjr1SnW-QaST7phX9C5wkg?view">here</a>, original paper <a href="https://ethresear.ch/t/draft-position-paper-on-resource-pricing/2838">here</a>) is a major fee market reform proposal which far-reaching consequences; it aims to improve the user experience of sending Ethereum transactions, reduce economic inefficiencies, provide an accurate in-protocol gas price oracle and burn a portion of fee revenue.</p>
<p>Many people in the Ethereum community are very excited about this proposal, though so far there has been fairly little funding toward getting it implemented. This gitcoin grant was a large community effort toward fixing this.</p>
<p>The grant had quite a few very large contributions, including roughly $2,400 each from myself and Eric Conner, early on. Early in the round, one could clearly see the EIP 1559 community grant having an abnormally low ratio of matched funds to contributed funds; it was somewhere around $4k matched to $20k contributed. This was because while the amount contributed was large, it came from relatively few wealthier donors, and so the matching amount was less than it would have been had the same quantity of funds come from more diverse sources - the quadratic funding formula working as intended. However, a social media push advertising the grant then led to a large number of smaller contributors following along, which then quickly raised the match to its currently very high value ($35,578).</p>
<h3 id="quadratic-signaling">Quadratic signaling</h3>
<p>Unexpectedly, this grant proved to have a double function. First, it provided $65,473 of much-needed funding to EIP 1559 implementation. Second, it served as a credible community signal of the level of demand for the proposal. The Ethereum community has <a href="https://vitalik.ca/general/2017/12/17/voting.html">long been struggling</a> to find effective ways to determine what "the community" supports, especially in cases of controversy.</p>
<p>Coin votes have been <a href="https://www.etherchain.org/coinvote">used in the past</a>, and have the advantage that they come with an answer to the key problem of determining who is a "real community member" - the answer is, your membership in the Ethereum community is proportional to how much ETH you have. However, they are plutocratic; in the famous DAO coin vote, a single "yes" voter voted with more ETH than all "no" voters put together (~20% of the total).</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round6/daocoinvote.png" style="width:350px" />
</center>
<p><br></p>
<p>The alternative, looking at github, reddit and twitter comments and votes to measure sentiment (sometimes derided as "proof of social media") is egalitarian, but it is easily exploitable, comes with no skin-in-the-game, and frequently falls under criticisms of "foreign interference" (are those <em>really</em> ethereum community members disagreeing with the proposal, or just those dastardly bitcoiners coming in from across the pond to stir up trouble?).</p>
<p>Quadratic funding falls perfectly in the middle: the need to contribute monetary value to vote ensures that the votes of those who <em>really</em> care about the project count more than the votes of less-concerned outsiders, and the square-root function ensures that the votes of individual ultra-wealthy "whales" cannot beat out a poorer, but broader, coalition.</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round6/quadraticpayments.png" style="width:600px" /><br><small><i>A diagram from my <a href="https://vitalik.ca/general/2019/12/07/quadratic.html">post on quadratic payments</a> showing how quadratic payments is "in the middle" between the extremes of voting-like systems and money-like systems, and avoids the worst flaws of both.</i></small>
</center>
<p><br></p>
<p>This raises the question: might it make sense to try to use explicit quadratic <em>voting</em> (with the ability to vote "yes" or "no" to a proposal) as an additional signaling tool to determine community sentiment for ethereum protocol proposals?</p>
<h3 id="how-well-are-guest-categories-working">How well are "guest categories" working?</h3>
<p>Since round 5, Gitcoin Grants has had three categories per round: tech, community (called "media" before), and some "guest" category that appears only during that specific round. In round 5 this was COVID relief; in round 6, it's Crypto For Black Lives.</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round6/blacklives.jpg" style="width:350px" />
</center>
<p>By far the largest recipient was Black Girls CODE, claiming over 80% of the matching pot. My guess for why this happened is simple: Black Girls CODE is an established project that has been participating in the grants for several rounds already, whereas the other projects were new entrants that few people in the Ethereum community knew well. In addition, of course, the Ethereum community "understands" the value of helping people code more than it understands chambers of commerce and bail funds.</p>
<p>This raises the question: is Gitcoin's current approach of having a guest category each round actually working well? The case for "no" is basically this: while the individual causes (empowering black communities, and fighting covid) are certainly admirable, the Ethereum community is by and large not experts at these topics, and we're certainly not experts on <em>those specific projects</em> working on those challenges.</p>
<p>If the goal is to try to bring quadratic funding to causes beyond Ethereum, the natural alternative is a separate funding round marketed specifically to those communities; <a href="https://downtownstimulus.com/" class="uri">https://downtownstimulus.com/</a> is a great example of this. If the goal is to get the Ethereum community interested in other causes, then perhaps running more than one round on each cause would work better. For example, "guest categories" could last for three rounds (~6 months), with $8,333 matching per round (and there could be two or three guest categories running simultaneously). In any case, it seems like some revision of the model makes sense.</p>
<h3 id="collusion">Collusion</h3>
<p>Now, the bad news. This round saw an unprecedented amount of attempted collusion and other forms of fraud. Here are a few of the most egregious examples.</p>
<p>Blatant attempted bribery:</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/round6/pic1.jpeg" style="width:480px"/><br>
</center>
<p><br></p>
<p>Impersonation:</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/round6/pic2.png" style="width:480px"/><br>
</center>
<p><br></p>
<p>Many contributions with funds clearly coming from a single address:</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/round6/pic3.png" style="width:480px" /><br>
</center>
<p><br></p>
<p>The big question is: how much fraudulent activity can be prevented in a fully automated/technological way, without requiring detailed analysis of each and every case? If quadratic funding cannot survive such fraud without needing to resort to expensive case-by-case judgement, then regardless of its virtues in an ideal world, in reality it would not be a very good mechanism!</p>
<p>Fortunately, there is a lot that we can do to reduce harmful collusion and fraud that we are not yet doing. Stronger identity systems is one example; in this round, Gitcoin added optional SMS verification, and it seems like the in this round the detected instances of collusion were mostly github-verified accounts and not SMS-verified accounts. In the next round, making some form of extra verification beyond a github account (whether SMS or something more decentralized, eg. BrightID) seems like a good idea. To limit bribery, <a href="https://github.com/appliedzkp/maci">MACI</a> can help, by making it impossible for a briber to tell who actually voted for any particular project.</p>
<p>Impersonation is not really a quadratic funding-specific challenge; this could be solved with manual verification, or if one wishes for a more decentralized solution one could try using <a href="https://kleros.io/">Kleros</a> or some similar system. One could even imagine incentivized reporting: anyone can lay down a deposit and flag a project as fraudulent, triggering an investigation; if the project turns out to be legitimate the deposit is lost but if the project turns out to be fraudulent, the challenger gets half of the funds that were sent to that project.</p>
<h3 id="conclusion">Conclusion</h3>
<p>The best news is the unmentioned news: many of the positive behaviors coming out of the quadratic funding rounds have stabilized. We're seeing valuable projects get funded in the tech and community categories, there has been less social media contention this round than in previous rounds, and people are getting better and better at understanding the mechanism and how to participate in it.</p>
<p>That said, the mechanism is definitely at a scale where we are seeing the kinds of attacks and challenges that we would realistically see in a larger-scale context. There are some challenges that we have not yet worked through (one that I am particularly watching out for is: matched grants going to a project that one part of the community supports and another part of the community thinks is very harmful). That said, we've gotten as far as we have with fewer problems than even I had been anticipating.</p>
<p>I recommend holding steady, focusing on security (and scalability) for the next few rounds, and coming up with ways to increase the size of the matching pots. And I continue to look forward to seeing valuable public goods get funded!</p>
Tue, 21 Jul 2020 17:03:10 -0700
https://vitalik.ca/general/2020/07/21/round6.html
https://vitalik.ca/general/2020/07/21/round6.htmlgeneralExploring Fully Homomorphic Encryption<p><em>Special thanks to Karl Floersch and Dankrad Feist for review</em></p>
<p>Fully homomorphic encryption has for a long time been considered one of the holy grails of cryptography. The promise of fully homomorphic encryption (FHE) is powerful: it is a type of encryption that allows a third party to perform computations on encrypted data, and get an encrypted result that they can hand back to whoever has the decryption key for the original data, <em>without</em> the third party being able to decrypt the data or the result themselves.</p>
<center>
<img src="https://vitalik.ca/files/posts_files/fhe/HomoEncrypt.png?1" !><br>
</center>
<p>As a simple example, imagine that you have a set of emails, and you want to use a third party spam filter to check whether or not they are spam. The spam filter has a desire for <em>privacy of their algorithm</em>: either the spam filter provider wants to keep their source code closed, or the spam filter depends on a very large database that they do not want to reveal publicly as that would make attacking easier, or both. However, you care about the <em>privacy of your data</em>, and don't want to upload your unencrypted emails to a third party. So here's how you do it:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/fhe/HomoEncrypt2.png" !><br>
</center>
<p>Fully homomorphic encryption has many applications, including in the blockchain space. One key example is that can be used to implement privacy-preserving light clients (the light client hands the server an encrypted index <code>i</code>, the server computes and returns <code>data[0] * (i = 0) + data[1] * (i = 1) + ... + data[n] * (i = n)</code>, where <code>data[i]</code> is the i'th piece of data in a block or state along with its Merkle branch and <code>(i = k)</code> is an expression that returns 1 if <code>i = k</code> and otherwise 0; the light client gets the data it needs and the server learns nothing about what the light client asked).</p>
<p>It can also be used for:</p>
<ul>
<li>More efficient <a href="https://ethresear.ch/t/open-problem-improving-stealth-addresses/7438">stealth address protocols</a>, and more generally scalability solutions to privacy-preserving protocols that today require each user to personally scan the entire blockchain for incoming transactions</li>
<li>Privacy-preserving data-sharing marketplaces that let users allow some specific computation to be performed on their data while keeping full control of their data for themselves</li>
<li>An ingredient in more powerful cryptographic primitives, such as more efficient multi-party computation protocols and perhaps eventually obfuscation</li>
</ul>
<p>And it turns out that fully homomorphic encryption is, conceptually, not that difficult to understand!</p>
<h3 id="partially-somewhat-fully-homomorphic-encryption">Partially, Somewhat, Fully homomorphic encryption</h3>
<p>First, a note on definitions. There are different kinds of homomorphic encryption, some more powerful than others, and they are separated by what kinds of functions one can compute on the encrypted data.</p>
<ul>
<li><strong>Partially homomorphic encryption</strong> allows evaluating only a <em>very</em> limited set of operations on encrypted data: either just additions (so given <code>encrypt(a)</code> and <code>encrypt(b)</code> you can compute <code>encrypt(a+b)</code>), or just multiplications (given <code>encrypt(a)</code> and <code>encrypt(b)</code> you can compute <code>encrypt(a*b)</code>).</li>
<li><strong>Somewhat homomorphic encryption</strong> allows computing additions as well as a <em>limited</em> number of multiplications (alternatively, polynomials up to a limited degree). That is, if you get <code>encrypt(x1) ... encrypt(xn)</code> (assuming these are "original" encryptions and not already the result of homomorphic computation), you can compute <code>encrypt(p(x1 ... xn))</code>, <em>as long as</em> <code>p(x1 ... xn)</code> is a polynomial with degree <code>< D</code> for some specific degree bound <code>D</code> (<code>D</code> is usually very low, think 5-15).</li>
<li><strong>Fully homomorphic encryption</strong> allows unlimited additions and multiplications. Additions and multiplications let you replicate any binary circuit gates (<code>AND(x, y) = x*y</code>, <code>OR(x, y) = x+y-x*y</code>, <code>XOR(x, y) = x+y-2*x*y</code> or just <code>x+y</code> if you only care about even vs odd, <code>NOT(x) = 1-x</code>...), so this is sufficient to do arbitrary computation on encrypted data.</li>
</ul>
<p>Partially homomorphic encryption is fairly easy; eg. RSA has a multiplicative homomorphism: <span class="math inline">\(enc(x) = x^e\)</span>, <span class="math inline">\(enc(y) = y^e\)</span>, so <span class="math inline">\(enc(x) * enc(y) = (xy)^e = enc(xy)\)</span>. Elliptic curves can offer similar properties with addition. Allowing <em>both</em> addition and multiplication is, it turns out, significantly harder.</p>
<h3 id="a-simple-somewhat-he-algorithm">A simple somewhat-HE algorithm</h3>
<p>Here, we will go through a somewhat-homomorphic encryption algorithm (ie. one that supports a limited number of multiplications) that is surprisingly simple. A more complex version of this category of technique was used by Craig Gentry to create <a href="https://crypto.stanford.edu/craig/craig-thesis.pdf">the first-ever <em>fully</em> homomorphic scheme</a> in 2009. More recent efforts have switched to using different schemes based on vectors and matrices, but we will still go through this technique first.</p>
<p>We will describe all of these encryption schemes as <em>secret-key</em> schemes; that is, the same key is used to encrypt and decrypt. Any secret-key HE scheme can be turned into a public key scheme easily: a "public key" is typically just a set of many encryptions of zero, as well as an encryption of one (and possibly more powers of two). To encrypt a value, generate it by adding together the appropriate subset of the non-zero encryptions, and then adding a random subset of the encryptions of zero to "randomize" the ciphertext and make it infeasible to tell what it represents.</p>
<p>The secret key here is a large prime, <span class="math inline">\(p\)</span> (think of <span class="math inline">\(p\)</span> as having hundreds or even thousands of digits). The scheme can only encrypt 0 or 1, and "addition" becomes XOR, ie. 1 + 1 = 0. To encrypt a value <span class="math inline">\(m\)</span> (which is either 0 or 1), generate a large random value <span class="math inline">\(R\)</span> (this will typically be even larger than <span class="math inline">\(p\)</span>) and a smaller random value <span class="math inline">\(r\)</span> (typically much smaller than <span class="math inline">\(p\)</span>), and output:</p>
<p><span class="math display">\[enc(m) = R * p + r * 2 + m\]</span></p>
<p>To decrypt a ciphertext <span class="math inline">\(ct\)</span>, compute:</p>
<p><span class="math display">\[dec(ct) = (ct\ mod\ p)\ mod\ 2\]</span></p>
<p>To add two ciphertexts <span class="math inline">\(ct_1\)</span> and <span class="math inline">\(ct_2\)</span>, you simply, well, add them: <span class="math inline">\(ct_1 + ct_2\)</span>. And to multiply two ciphertexts, you once again... multiply them: <span class="math inline">\(ct_1 * ct_2\)</span>. We can prove the homomorphic property (that the sum of the encryptions is an encryption of the sum, and likewise for products) as follows.</p>
<p>Let:</p>
<p><span class="math display">\[ct_1 = R_1 * p + r_1 * 2 + m_1\]</span> <span class="math display">\[ct_2 = R_2 * p + r_2 * 2 + m_2\]</span></p>
<p>We add:</p>
<p><span class="math display">\[ct_1 + ct_2 = R_1 * p + R_2 * p + r_1 * 2 + r_2 * 2 + m_1 + m_2\]</span></p>
<p>Which can be rewritten as:</p>
<p><span class="math display">\[(R_1 + R_2) * p + (r_1 + r_2) * 2 + (m_1 + m_2)\]</span></p>
<p>Which is of the exact same "form" as a ciphertext of <span class="math inline">\(m_1 + m_2\)</span>. If you decrypt it, the first <span class="math inline">\(mod\ p\)</span> removes the first term, the second <span class="math inline">\(mod\ 2\)</span> removes the second term, and what's left is <span class="math inline">\(m_1 + m_2\)</span> (remember that if <span class="math inline">\(m_1 = 1\)</span> and <span class="math inline">\(m_2 = 1\)</span> then the 2 will get absorbed into the second term and you'll be left with zero). And so, voila, we have additive homomorphism!</p>
<p>Now let's check multiplication:</p>
<p><span class="math display">\[ct_1 * ct_2 = (R_1 * p + r_1 * 2 + m_1) * (R_2 * p + r_2 * 2 + m_2)\]</span></p>
<p>Or:</p>
<p><span class="math display">\[(R_1 * R_2 * p + r_1 * 2 + m_1 + r_2 * 2 + m_2) * p + \\
(r_1 * r_2 * 2 + r_1 * m_2 + r_2 * m_1) * 2 + \\
(m_1 * m_2)\]</span></p>
<p>This was simply a matter of expanding the product above, and grouping together all the terms that contain <span class="math inline">\(p\)</span>, then all the remaining terms that contain <span class="math inline">\(2\)</span>, and finally the remaining term which is the product of the messages. If you decrypt, then once again the <span class="math inline">\(mod\ p\)</span> removes the first group, the <span class="math inline">\(mod\ 2\)</span> removes the second group, and only <span class="math inline">\(m_1 * m_2\)</span> is left.</p>
<p>But there are two problems here: first, the size of the ciphertext itself grows (the length roughly doubles when you multiply), and second, the "noise" (also often called "error") in the smaller <span class="math inline">\(* 2\)</span> term also gets quadratically bigger. Adding this error into the ciphertexts was necessary because the security of this scheme is based on the <a href="https://oeis.org/wiki/Greatest_common_divisor#Approximate_GCD_problem">approximate GCD problem</a>:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/fhe/approx_gcd.png" !><br><br>
</center>
<p>Had we instead used the "exact GCD problem", breaking the system would be easy: if you just had a set of expressions of the form <span class="math inline">\(p * R_1 + m_1\)</span>, <span class="math inline">\(p * R_2 + m_2\)</span>..., then you could use the <a href="https://en.wikipedia.org/wiki/Euclidean_algorithm">Euclidean algorithm</a> to efficiently compute the greatest common divisor <span class="math inline">\(p\)</span>. But if the ciphertexts are only <em>approximate</em> multiples of <span class="math inline">\(p\)</span> with some "error", then extracting <span class="math inline">\(p\)</span> quickly becomes impractical, and so the scheme can be secure.</p>
<p>Unfortunately, the error introduces the inherent limitation that if you multiply the ciphertexts by each other enough times, the error eventually grows big enough that it exceeds <span class="math inline">\(p\)</span>, and at that point the <span class="math inline">\(mod\ p\)</span> and <span class="math inline">\(mod\ 2\)</span> steps "interfere" with each other, making the data unextractable. This will be an inherent tradeoff in all of these homomorphic encryption schemes: extracting information from <em>approximate</em> equations "with errors" is much harder than extracting information from exact equations, but any error you add quickly increases as you do computations on encrypted data, bounding the amount of computation that you can do before the error becomes overwhelming. And <strong>this is why these schemes are only "somewhat" homomorphic</strong>.</p>
<h2 id="bootstrapping">Bootstrapping</h2>
<p>There are two classes of solution to this problem. First, in many somewhat homomorphic encryption schemes, there are clever tricks to make multiplication only increase the error by a constant factor (eg. 1000x) instead of squaring it. Increasing the error by 1000x still sounds by a lot, but keep in mind that if <span class="math inline">\(p\)</span> (or its equivalent in other schemes) is a 300-digit number, that means that you can multiply numbers by each other 100 times, which is enough to compute a very wide class of computations. Second, there is Craig Gentry's technique of "bootstrapping".</p>
<p>Suppose that you have a ciphertext <span class="math inline">\(ct\)</span> that is an encryption of some <span class="math inline">\(m\)</span> under a key <span class="math inline">\(p\)</span>, that has a lot of error. The idea is that we "refresh" the ciphertext by turning it into a new ciphertext of <span class="math inline">\(m\)</span> under another key <span class="math inline">\(p_2\)</span>, where this process "clears out" the old error (though it will introduce a fixed amount of new error). The trick is quite clever. The holder of <span class="math inline">\(p\)</span> and <span class="math inline">\(p_2\)</span> provides a "bootstrapping key" that consists of an encryption of <em>the bits of <span class="math inline">\(p\)</span></em> under the key <span class="math inline">\(p_2\)</span>, as well as the public key for <span class="math inline">\(p_2\)</span>. Whoever is doing computations on data encrypted under <span class="math inline">\(p\)</span> would then take the bits of the ciphertext <span class="math inline">\(ct\)</span>, and individually encrypt these bits under <span class="math inline">\(p_2\)</span>. They would then <em>homomorphically compute the decryption under <span class="math inline">\(p\)</span></em> using these ciphertexts, and get out the single bit, which would be <span class="math inline">\(m\)</span> encrypted under <span class="math inline">\(p_2\)</span>.</p>
<center>
<img src="https://vitalik.ca/files/posts_files/fhe/bootstrapping.png" !><br><br>
</center>
<p>This is difficult to understand, so we can restate it as follows. The decryption procedure <span class="math inline">\(dec(ct, p)\)</span> <em>is itself a computation</em>, and so it <em>can itself be implemented as a circuit</em> that takes as input the bits of <span class="math inline">\(ct\)</span> and the bits of <span class="math inline">\(p\)</span>, and outputs the decrypted bit <span class="math inline">\(m \in {0, 1}\)</span>. If someone has a ciphertext <span class="math inline">\(ct\)</span> encrypted under <span class="math inline">\(p\)</span>, a public key for <span class="math inline">\(p_2\)</span>, <em>and</em> the bits of <span class="math inline">\(p\)</span> encrypted under <span class="math inline">\(p_2\)</span>, then they can compute <span class="math inline">\(dec(ct, p) = m\)</span> "homomorphically", and get out <span class="math inline">\(m\)</span> encrypted under <span class="math inline">\(p_2\)</span>. Notice that the decryption procedure itself washes away the old error; it just outputs 0 or 1. The decryption procedure is itself a circuit, which contains additions or multiplications, so it will introduce new error, but this new error <em>does not depend</em> on the amount of error in the original encryption.</p>
<p><small>(Note that we can avoid having a distinct new key <span class="math inline">\(p_2\)</span> (and if you want to bootstrap multiple times, also a <span class="math inline">\(p_3\)</span>, <span class="math inline">\(p_4\)</span>...) by just setting <span class="math inline">\(p_2 = p\)</span>. However, this introduces a new assumption, usually called "circular security"; it <a href="https://link.springer.com/content/pdf/10.1007%2F978-3-642-36594-2_32.pdf">becomes more difficult</a> to formally prove security if you do this, though many cryptographers think it's fine and circular security poses no significant risk in practice)</small></p>
<p>But.... there is a catch. In the scheme as described above (using circular security or not), the error blows up so quickly that even the decryption circuit of the scheme itself is too much for it. That is, the new <span class="math inline">\(m\)</span> encrypted under <span class="math inline">\(p_2\)</span> would <em>already</em> have so much error that it is unreadable. This is because each AND gate doubles the bit-length of the error, so a scheme using a <span class="math inline">\(d\)</span>-bit modulus <span class="math inline">\(p\)</span> can only handle less than <span class="math inline">\(log(d)\)</span> multiplications (in series), but decryption requires computing <span class="math inline">\(mod\ p\)</span> in a circuit made up of these binary logic gates, which requires... more than <span class="math inline">\(log(d)\)</span> multiplications.</p>
<p>Craig Gentry came up with clever techniques to get around this problem, but they are arguably too complicated to explain; instead, we will skip straight to newer work from 2011 and 2013, that solves this problem in a different way.</p>
<h2 id="learning-with-errors">Learning with errors</h2>
<p>To move further, we will introduce a <a href="https://eprint.iacr.org/2011/344.pdf">different type of somewhat-homomorphic encryption</a> introduced by Brakerski and Vaikuntanathan in 2011, and show how to bootstrap it. Here, we will move away from keys and ciphertexts being <em>integers</em>, and instead have keys and ciphertexts be <em>vectors</em>. Given a key <span class="math inline">\(k = {k_1, k_2 .... k_n}\)</span>, to encrypt a message <span class="math inline">\(m\)</span>, construct a vector <span class="math inline">\(c = {c_1, c_2 ... c_n}\)</span> such that the inner product (or "<a href="https://en.wikipedia.org/wiki/Dot_product">dot product</a>") <span class="math inline">\(<c, k> = c_1k_1 + c_2k_1 + ... + c_nk_n\)</span>, modulo some fixed number <span class="math inline">\(p\)</span>, equals <span class="math inline">\(m+2e\)</span> where <span class="math inline">\(m\)</span> is the message (which must be 0 or 1), and <span class="math inline">\(e\)</span> is a small (much smaller than <span class="math inline">\(p\)</span>) "error" term. A "public key" that allows encryption but not decryption can be constructed, as before, by making a set of encryptions of 0; an encryptor can randomly combine a subset of these equations and add 1 if the message they are encrypting is 1. To decrypt a ciphertext <span class="math inline">\(c\)</span> knowing the key <span class="math inline">\(k\)</span>, you would compute <span class="math inline">\(<c, k>\)</span> modulo <span class="math inline">\(p\)</span>, and see if the result is odd or even (this is the same "mod p mod 2" trick we used earlier). Note that here the <span class="math inline">\(mod\ p\)</span> is typically a "symmetric" mod, that is, it returns a number between <span class="math inline">\(-\frac{p}{2}\)</span> and <span class="math inline">\(\frac{p}{2}\)</span> (eg. 137 mod 10 = -3, 212 mod 10 = 2); this allows our error to be positive or negative. Additionally, <span class="math inline">\(p\)</span> does not necessarily have to be prime, though it does need to be odd.</p>
<center>
<table>
<tr>
<td>
<b>Key</b>
</td>
<td>
3
</td>
<td>
14
</td>
<td>
15
</td>
<td>
92
</td>
<td>
65
</td>
</tr>
<tr>
<td>
<b>Ciphertext</b>
</td>
<td>
2
</td>
<td>
71
</td>
<td>
82
</td>
<td>
81
</td>
<td>
8
</td>
</tr>
</table>
<small><i>The key and the ciphertext are both vectors, in this example of five elements each.</i></small><br><br>
</center>
<p>In this example, we set the modulus <span class="math inline">\(p = 103\)</span>. The dot product is <code>3 * 2 + 14 * 71 + 15 * 82 + 92 * 81 + 65 * 8 = 10202</code>, and <span class="math inline">\(10202 = 99 * 103 + 5\)</span>. 5 itself is of course <span class="math inline">\(2 * 2 + 1\)</span>, so the message is 1. Note that in practice, the first element of the key is often set to <span class="math inline">\(1\)</span>; this makes it easier to generate ciphertexts for a particular value (see if you can figure out why).</p>
<p>The security of the scheme is based on an assumption known as "<a href="https://en.wikipedia.org/wiki/Learning_with_errors">learning with errors</a>" (LWE) - or, in more jargony but also more understandable terms, the hardness of <em>solving systems of equations with errors</em>.</p>
<center>
<a href="https://cims.nyu.edu/~regev/papers/lwesurvey.pdf"><img src="https://vitalik.ca/files/posts_files/fhe/lwe.png" !></a><br>
</center>
<p><br></p>
<p>A ciphertext can itself be viewed as an equation: <span class="math inline">\(k_1c_1 + .... + k_nc_n \approx 0\)</span>, where the key <span class="math inline">\(k_1 ... k_n\)</span> is the unknowns, the ciphertext <span class="math inline">\(c_1 ... c_n\)</span> is the coefficients, and the equality is only approximate because of both the message (0 or 1) and the error (<span class="math inline">\(2e\)</span> for some relatively small <span class="math inline">\(e\)</span>). The LWE assumption ensures that even if you have access to many of these ciphertexts, you cannot recover <span class="math inline">\(k\)</span>.</p>
<p><small><i>Note that in some descriptions of LWE, <c, k> can equal <em>any</em> value, but this value must be provided as part of the ciphertext. This is mathematically equivalent to the <c, k> = m+2e formulation, because you can just add this answer to the end of the ciphertext and add -1 to the end of the key, and get two vectors that when multiplied together just give m+2e. We'll use the formulation that requires <c, k> to be near-zero (ie. just m+2e) because it is simpler to work with.</i></small></p>
<h3 id="multiplying-ciphertexts">Multiplying ciphertexts</h3>
<p>It is easy to verify that the encryption is additive: if <span class="math inline">\(<ct_1, k> = 2e_1 + m_1\)</span> and <span class="math inline">\(<ct_2, k> = 2e_2 + m_2\)</span>, then <span class="math inline">\(<ct_1 + ct_2, k> = 2(e_1 + e_2) + m_1 + m_2\)</span> (the addition here is modulo <span class="math inline">\(p\)</span>). What is harder is multiplication: unlike with numbers, there is no natural way to multiply two length-n vectors into another length-n vector. The best that we can do is the <a href="https://en.wikipedia.org/wiki/Outer_product">outer product</a>: a vector containing the products of each possible pair where the first element comes from the first vector and the second element comes from the second vector. That is, <span class="math inline">\(a \otimes b = a_1b_1 + a_2b_1 + ... + a_nb_1 + a_1b_2 + ... + a_nb_2 + ... + a_nb_n\)</span>. We can "multiply ciphertexts" using the convenient mathematical identity <span class="math inline">\(<a \otimes b, c \otimes d> = <a, c> * <b, d>\)</span>.</p>
<p>Given two ciphertexts <span class="math inline">\(c_1\)</span> and <span class="math inline">\(c_2\)</span>, we compute the outer product <span class="math inline">\(c_1 \otimes c_2\)</span>. If both <span class="math inline">\(c_1\)</span> and <span class="math inline">\(c_2\)</span> were encrypted with <span class="math inline">\(k\)</span>, then <span class="math inline">\(<c_1, k> = 2e_1 + m_1\)</span> and <span class="math inline">\(<c_2, k> = 2e_2 + m_2\)</span>. The outer product <span class="math inline">\(c_1 \otimes c_2\)</span> can be viewed as an encryption of <span class="math inline">\(m_1 * m_2\)</span> under <span class="math inline">\(k \otimes k\)</span>; we can see this by looking what happens when we try to decrypt with <span class="math inline">\(k \otimes k\)</span>:</p>
<p><span class="math display">\[<c_1 \otimes c_2, k \otimes k>\]</span> <span class="math display">\[= <c_1, k> * <c_2, k>\]</span> <span class="math display">\[ = (2e_1 + m_1) * (2e_2 + m_2)\]</span> <span class="math display">\[ = 2(e_1m_2 + e_2m_1 + 2e_1e_2) + m_1m_2\]</span></p>
<p>So this outer-product approach works. But there is, as you may have already noticed, a catch: the size of the ciphertext, and the key, grows quadratically.</p>
<h3 id="relinearization">Relinearization</h3>
<p>We solve this with a <strong>relinearization</strong> procedure. The holder of the private key <span class="math inline">\(k\)</span> provides, as part of the public key, a "relinearization key", which you can think of as "noisy" encryptions of <span class="math inline">\(k \otimes k\)</span> under <span class="math inline">\(k\)</span>. The idea is that we provide these encrypted pieces of <span class="math inline">\(k \otimes k\)</span> to anyone performing the computations, allowing them to compute the equation <span class="math inline">\(<c_1 \otimes c_2, k \otimes k>\)</span> to "decrypt" the ciphertext, but only in such a way that the output comes back encrypted under <span class="math inline">\(k\)</span>.</p>
<p>It's important to understand what we mean here by "noisy encryptions". Normally, this encryption scheme only allows encrypting <span class="math inline">\(m \in \{0,1\}\)</span>, and an "encryption of <span class="math inline">\(m\)</span>" is a vector <span class="math inline">\(c\)</span> such that <span class="math inline">\(<c, k> = m+2e\)</span> for some small error <span class="math inline">\(e\)</span>. Here, we're "encrypting" arbitrary <span class="math inline">\(m \in \{0,1, 2....p-1\}\)</span>. Note that the error means that you can't fully recover <span class="math inline">\(m\)</span> from <span class="math inline">\(c\)</span>; your answer will be off by some multiple of 2. However, it turns out that, for this specific use case, this is fine.</p>
<p>The relinearization key consists of a set of vectors which, when inner-producted (modulo <span class="math inline">\(p\)</span>) with the key <span class="math inline">\(k\)</span>, give values of the form <span class="math inline">\(k_i * k_j * 2^d + 2e\)</span> (mod <span class="math inline">\(p\)</span>), one such vector for every possible triple <span class="math inline">\((i, j, d)\)</span>, where <span class="math inline">\(i\)</span> and <span class="math inline">\(j\)</span> are indices in the key and <span class="math inline">\(d\)</span> is an exponent where <span class="math inline">\(2^d < p\)</span> (note: if the key has length <span class="math inline">\(n\)</span>, there would be <span class="math inline">\(n^2 * log(p)\)</span> values in the relinearization key; make sure you understand why before continuing).</p>
<center>
<center>
<img src="https://vitalik.ca/files/posts_files/fhe/relin.png" !><br>
</center>
<small><i>Example assuming p = 15 and k has length 2. Formally, enc(x) here means "outputs x+2e if inner-producted with k".</i></small><br><br>
</center>
<p>Now, let us take a step back and look again at our goal. We have a ciphertext which, if decrypted with <span class="math inline">\(k \otimes k\)</span>, gives <span class="math inline">\(m_1 * m_2\)</span>. We <em>want</em> a ciphertext which, if decrypted with <span class="math inline">\(k\)</span>, gives <span class="math inline">\(m_1 * m_2\)</span>. We can do this with the relinearization key. Notice that the decryption equation <span class="math inline">\(<ct_1 \otimes ct_2, k \otimes k>\)</span> is just a big sum of terms of the form <span class="math inline">\((ct_{1_i} * ct_{2_j}) * k_p * k_q\)</span>.</p>
<p>And what do we have in our relinearization key? A bunch of elements of the form <span class="math inline">\(2^d * k_p * k_q\)</span>, noisy-encrypted under <span class="math inline">\(k\)</span>, for every possible combination of <span class="math inline">\(p\)</span> and <span class="math inline">\(q\)</span>! Having all the powers of two in our relinearization key allows us to generate any <span class="math inline">\((ct_{1_i} * ct_{2_j}) * k_p * k_q\)</span> by just adding up <span class="math inline">\(\le log(p)\)</span> powers of two (eg. 13 = 8 + 4 + 1) together for each <span class="math inline">\((p, q)\)</span> pair.</p>
<p>For example, if <span class="math inline">\(ct_1 = [1, 2]\)</span> and <span class="math inline">\(ct_2 = [3, 4]\)</span>, then <span class="math inline">\(ct_1 \otimes ct_2 = [3, 4, 6, 8]\)</span>, and <span class="math inline">\(enc(<ct_1 \otimes ct_2, k \otimes k>) = enc(3k_1k_1 + 4k_1k_2 + 6k_2k_1 + 8k_2k_2)\)</span> could be computed via:</p>
<p><span class="math inline">\(\color{green}{enc(k_1*k_1) + enc(k_1*k_1*2) }+ \color{red}{enc(k_1 * k_2 * 4) }+\)</span> <span class="math inline">\(\color{blue}{enc(k_2 * k_1 * 2) + enc(k_2 * k_1 * 4) }+\color{orange}{enc(k_2 * k_2 * 8)}\)</span></p>
<p>Note that each noisy-encryption in the relinearization key has some even error <span class="math inline">\(2e\)</span>, and the equation <span class="math inline">\(<ct_1 \otimes ct_2, k \otimes k>\)</span> itself has some error: if <span class="math inline">\(<ct_1, k> = 2e_1 + m_1\)</span> and <span class="math inline">\(<ct_2 + k> = 2e_2 + m_2\)</span>, then <span class="math inline">\(<ct_1 \otimes ct_2, k \otimes k> = <ct_1, k> * <ct_2 + k> = 2(2e_1e_2 + e_1m_2 + e_2m_1) + m_1m_2\)</span>. But this total error is still (relatively) small (<span class="math inline">\(2e_1e_2 + e_1m_2 + e_2m_1\)</span> plus <span class="math inline">\(n^2 * log(p)\)</span> fixed-size errors from the realinearization key), and the error is even, and so the result of this calculation still gives a value which, when inner-producted with <span class="math inline">\(k\)</span>, gives <span class="math inline">\(m_1 * m_2 + 2e'\)</span> for some "combined error" <span class="math inline">\(e'\)</span>.</p>
<p>The broader technique we used here is a common trick in homomorphic encryption: provide pieces of the key encrypted under the key itself (or a different key if you are pedantic about avoiding circular security assumptions), such that someone computing on the data can compute the decryption equation, but only in such a way that the output itself is still encrypted. It was used in bootstrapping above, and it's used here; it's best to make sure you mentally understand what's going on in both cases.</p>
<p>This new ciphertext has considerably more error in it: the <span class="math inline">\(n^2 * log(p)\)</span> different errors from the portions of the relinearization key that we used, plus the <span class="math inline">\(2(2e_1e_2 + e_1m_2 + e_2m_1)\)</span> from the original outer-product ciphertext. Hence, the new ciphertext still does have quadratically larger error than the original ciphertexts, and so we still haven't solved the problem that the error blows up too quickly. To solve this, we move on to another trick...</p>
<h3 id="modulus-switching">Modulus switching</h3>
<p>Here, we need to understand an important algebraic fact. A ciphertext is a vector <span class="math inline">\(ct\)</span>, such that <span class="math inline">\(<ct, k> = m+2e\)</span>, where <span class="math inline">\(m \in \{0,1\}\)</span>. But we can also look at the ciphertext from a different "perspective": consider <span class="math inline">\(\frac{ct}{2}\)</span> (modulo <span class="math inline">\(p\)</span>). <span class="math inline">\(<\frac{ct}{2}, k> = \frac{m}{2} + e\)</span>, where <span class="math inline">\(\frac{m}{2} \in \{0,\frac{p+1}{2}\}\)</span>. Note that because (modulo <span class="math inline">\(p\)</span>) <span class="math inline">\((\frac{p+1}{2})*2 = p+1 = 1\)</span>, division by 2 (modulo <span class="math inline">\(p\)</span>) maps <span class="math inline">\(1\)</span> to <span class="math inline">\(\frac{p+1}{2}\)</span>; this is a very convenient fact for us.</p>
<center>
<img src="https://vitalik.ca/files/posts_files/fhe/table.png" !><br><br>
</center>
<p><small>The scheme in this section uses both modular division (ie. multiplying by the <a href="https://en.wikipedia.org/wiki/Modular_multiplicative_inverse">modular multiplicative inverse</a>) and regular "rounded down" integer division; make sure you understand how both work and how they are different from each other.</small></p>
<p>That is, the operation of dividing by 2 (modulo <span class="math inline">\(p\)</span>) converts small even numbers into small numbers, and it converts 1 into <span class="math inline">\(\frac{p}{2}\)</span> (rounded up). So if we look at <span class="math inline">\(\frac{ct}{2}\)</span> (modulo <span class="math inline">\(p\)</span>) instead of <span class="math inline">\(ct\)</span>, decryption involves computing <span class="math inline">\(<\frac{ct}{2}, k>\)</span> and seeing if it's closer to <span class="math inline">\(0\)</span> or <span class="math inline">\(\frac{p}{2}\)</span>. This "perspective" is much more robust to certain kinds of errors, where you know the error is small but can't guarantee that it's a multiple of 2.</p>
<p>Now, here is something we can do to a ciphertext.</p>
<ol type="1">
<li>Start: <span class="math inline">\(<ct, k> = \{0\ or\ 1\} + 2e\ (mod\ p)\)</span></li>
<li>Divide <span class="math inline">\(ct\)</span> by 2 (modulo <span class="math inline">\(p\)</span>): <span class="math inline">\(<ct', k> = \{0\ or\ \frac{p}{2}\} + e\ (mod\ p)\)</span></li>
<li>Multiply <span class="math inline">\(ct'\)</span> by <span class="math inline">\(\frac{q}{p}\)</span> <em>using "regular rounded-down integer division"</em>: <span class="math inline">\(<ct'', k> = \{0\ or\ \frac{q}{2}\} + e' + e_2\ (mod\ q)\)</span></li>
<li>Multiply <span class="math inline">\(ct''\)</span> by 2 (modulo <span class="math inline">\(q\)</span>): <span class="math inline">\(<ct''', k> = \{0\ or\ 1\} + 2e' + 2e_2\ (mod\ q)\)</span></li>
</ol>
<p>Step 3 is the crucial one: it converts a ciphertext under modulus <span class="math inline">\(p\)</span> into a ciphertext under modulus <span class="math inline">\(q\)</span>. The process just involves "scaling down" each element of <span class="math inline">\(ct'\)</span> by multiplying by <span class="math inline">\(\frac{q}{p}\)</span> and rounding down, eg. <span class="math inline">\(floor(56 * \frac{15}{103}) = floor(8.15533..) = 8\)</span>.</p>
<p>The idea is this: if <span class="math inline">\(<ct', k> = m*\frac{p}{2} + e\ (mod\ p)\)</span>, then we can interpret this as <span class="math inline">\(<ct', k> = p(z + \frac{m}{2}) + e\)</span> for some integer <span class="math inline">\(z\)</span>. Therefore, <span class="math inline">\(<ct' * \frac{q}{p}, k> = q(z + \frac{m}{2}) + e*\frac{p}{q}\)</span>. Rounding adds error, but only a little bit (specifically, up to the size of the values in <span class="math inline">\(k\)</span>, and we can make the values in <span class="math inline">\(k\)</span> small without sacrificing security). Therefore, we can say <span class="math inline">\(<ct' * \frac{q}{p}, k> = m*\frac{q}{2} + e' + e_2\ (mod\ q)\)</span>, where <span class="math inline">\(e' = e * \frac{q}{p}\)</span>, and <span class="math inline">\(e_2\)</span> is a small error from rounding.</p>
<p>What have we accomplished? We turned a ciphertext with modulus <span class="math inline">\(p\)</span> and error <span class="math inline">\(2e\)</span> into a ciphertext with modulus <span class="math inline">\(q\)</span> and error <span class="math inline">\(2(floor(e*\frac{p}{q}) + e_2)\)</span>, where the new error is <em>smaller</em> than the original error.</p>
<p>Let's go through the above with an example. Suppose:</p>
<ul>
<li><span class="math inline">\(ct\)</span> is just one value, <span class="math inline">\([5612]\)</span></li>
<li><span class="math inline">\(k = [9]\)</span></li>
<li><span class="math inline">\(p = 9999\)</span> and <span class="math inline">\(q = 113\)</span></li>
</ul>
<p><span class="math inline">\(<ct, k> = 5612 * 9 = 50508 = 9999 * 5 + 2 * 256 + 1\)</span>, so <span class="math inline">\(ct\)</span> represents the bit 1, but the error is fairly large (<span class="math inline">\(e = 256\)</span>).</p>
<p>Step 2: <span class="math inline">\(ct' = \frac{ct}{2} = 2806\)</span> (remember this is modular division; if <span class="math inline">\(ct\)</span> were instead <span class="math inline">\(5613\)</span>, then we would have <span class="math inline">\(\frac{ct}{2} = 7806\)</span>). Checking: <span class="math inline">\(<ct', k> = 2806 * 9 = 25254 = 9999 * 2.5 + 256.5\)</span></p>
<p>Step 3: <span class="math inline">\(ct'' = floor(2806 * \frac{113}{9999}) = floor(31.7109...) = 31\)</span>. Checking: <span class="math inline">\(<ct'', k> = 279 = 113 * 2.5 - 3.5\)</span></p>
<p>Step 4: <span class="math inline">\(ct''' = 31 * 2 = 62\)</span>. Checking: <span class="math inline">\(<ct''', k> = 558 = 113 * 5 - 2 * 4 + 1\)</span></p>
<p>And so the bit <span class="math inline">\(1\)</span> is preserved through the transformation. The crazy thing about this procedure is: <em>none of it requires knowing <span class="math inline">\(k\)</span></em>. Now, an astute reader might notice: you reduced the <em>absolute</em> size of the error (from 256 to 2), but the <em>relative</em> size of the error remained unchanged, and even slightly increased: <span class="math inline">\(\frac{256}{9999} \approx 2.5\%\)</span> but <span class="math inline">\(\frac{4}{113} \approx 3.5\%\)</span>. Given that it's the relative error that causes ciphertexts to break, what have we gained here?</p>
<p>The answer comes from what happens to error when you multiply ciphertexts. Suppose that we start with a ciphertext <span class="math inline">\(x\)</span> with error 100, and modulus <span class="math inline">\(p = 10^{16} - 1\)</span>. We want to repeatedly square <span class="math inline">\(x\)</span>, to compute <span class="math inline">\((((x^2)^2)^2)^2 = x^{16}\)</span>. First, the "normal way":</p>
<center>
<img src="https://vitalik.ca/files/posts_files/fhe/table2.png" !><br><br>
</center>
<p>The error blows up too quickly for the computation to be possible. Now, let's do a modulus reduction after every multiplication. We assume the modulus reduction is imperfect and increases error by a factor of 10, so a 1000x modulo reduction only reduces error from 10000 to 100 (and not to 10):</p>
<center>
<img src="https://vitalik.ca/files/posts_files/fhe/table3.png" !><br><br>
</center>
<p>The key mathematical idea here is that the <em>factor</em> by which error increases in a multiplication depends on the absolute size of the error, and not its relative size, and so if we keep doing modulus reductions to keep the error small, each multiplication only increases the error by a constant factor. And so, with a <span class="math inline">\(d\)</span> bit modulus (and hence <span class="math inline">\(\approx 2^d\)</span> room for "error"), we can do <span class="math inline">\(O(d)\)</span> multiplications! This is enough to bootstrap.</p>
<h3 id="another-technique-matrices">Another technique: matrices</h3>
<p>Another technique (see <a href="https://eprint.iacr.org/2013/340.pdf">Gentry, Sahai, Waters (2013)</a>) for fully homomorphic encryption involves matrices: instead of representing a ciphertext as <span class="math inline">\(ct\)</span> where <span class="math inline">\(<ct, k> = 2e + m\)</span>, a ciphertext is a matrix, where <span class="math inline">\(k * CT = k * m + e\)</span> (<span class="math inline">\(k\)</span>, the key, is still a vector). The idea here is that <span class="math inline">\(k\)</span> is a "secret near-eigenvector" - a secret vector which, if you multiply the matrix by it, returns something very close to either zero or the key itself.</p>
<p>The fact that addition works is easy: if <span class="math inline">\(k * CT_1 = m_1 * k + e_1\)</span> and <span class="math inline">\(k * CT_2 = m_2 * k + e_2\)</span>, then <span class="math inline">\(k * (CT_1 + CT_2) = (m_1 + m_2) * k + (e_1 + e_2)\)</span>. The fact that multiplication works is also easy:</p>
<p><span class="math inline">\(k * CT_1 * CT_2\)</span> <span class="math inline">\(= (m_1 * k + e_1) * CT_2\)</span> <span class="math inline">\(= m_1 * k * CT_2 + e_1 * CT_2\)</span> <span class="math inline">\(= m_1 * m_2 * k + m_1 * e_2 + e_1 * CT_2\)</span></p>
<p>The first term is the "intended term"; the latter two terms are the "error". That said, notice that here error does blow up quadratically (see the <span class="math inline">\(e_1 * CT_2\)</span>% term; the size of the error increases by the size of each ciphertext element, and the ciphertext elements also square in size), and you do need some clever tricks for avoiding this. Basically, this involves turning ciphertexts into matrices containing their constituent bits before multiplying, to avoid multiplying by anything higher than 1; if you want to see how this works in detail I recommend looking at my code: <a href="https://github.com/vbuterin/research/blob/master/matrix_fhe/matrix_fhe.py#L121" class="uri">https://github.com/vbuterin/research/blob/master/matrix_fhe/matrix_fhe.py#L121</a></p>
<p>In addition, the code there, and also <a href="https://github.com/vbuterin/research/blob/master/tensor_fhe/homomorphic_encryption.py#L186" class="uri">https://github.com/vbuterin/research/blob/master/tensor_fhe/homomorphic_encryption.py#L186</a>, provides simple examples of useful circuits that you can build out of these binary logical operations; the main example is for adding numbers that are represented as multiple bits, but one can also make circuits for comparison (<span class="math inline">\(<\)</span>, <span class="math inline">\(>\)</span>, <span class="math inline">\(=\)</span>), multiplication, division, and many other operations.</p>
<p>Since 2012-13, when these algorithms were created, there have been many optimizations, but they all work on top of these basic frameworks. Often, polynomials are used instead of integers; this is called <a href="https://en.wikipedia.org/wiki/Ring_learning_with_errors">ring LWE</a>. The major challenge is still efficiency: an operation involving a single bit involves multiplying entire matrices or performing an entire relinearization computation, a very high overhead. There are tricks that allow you to perform many bit operations in a single ciphertext operation, and this is actively being worked on and improved.</p>
<p>We are quickly getting to the point where many of the applications of homomorphic encryption in privacy-preserving computation are starting to become practical. Additionally, research in the more advanced applications of the lattice-based cryptography used in homomorphic encryption is rapidly progressing. So this is a space where some things can already be done today, but we can hopefully look forward to much more becoming possible over the next decade.</p>
Mon, 20 Jul 2020 17:03:10 -0700
https://vitalik.ca/general/2020/07/20/homomorphic.html
https://vitalik.ca/general/2020/07/20/homomorphic.htmlgeneralGitcoin Grants Round 5 Retrospective<p><em>Special thanks to Kevin Owocki and Frank Chen for help and review</em></p>
<p>Round 5 of Gitcoin Grants has just finished, with $250,000 of matching split between tech, media, and the new (non-Ethereum-centric) category of "public health". In general, it seems like the mechanism and the community are settling down into a regular rhythm. People know what it means to contribute, people know what to expect, and the results emerge in a relatively predictable pattern - even if which specific grants get the most funds is not so easy to predict.</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round5/tech2.jpg" style="width:350px" /> <img src="http://vitalik.ca/files/posts_files/round5/media2.jpg" style="width:350px" />
</center>
<p><br></p>
<h3 id="stability-of-income">Stability of income</h3>
<p>So let's go straight into the analysis. One important property worth looking at is stability of income across rounds: do projects that do well in round N also tend to do well in round N+1? Stability of income is very important if we want to support an ecosystem of "quadratic freelancers": we want people to feel comfortable relying on their income knowing that it will not completely disappear the next round. On the other hand, it would be harmful if some recipients became completely entrenched, with no opportunity for new projects to come in and compete for the pot, so there is a need for a balance.</p>
<p>On the media side, we do see some balance between stability and dynamism:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round5/media_scatter.png?1" />
</center>
<p><br></p>
<p>Week in Ethereum had the highest total amount received in both <a href="https://vitalik.ca/general/2020/01/28/round4.html">the previous round</a> and the current round. EthHub and Bankless are also near the top in both the current round and the previous round. On the other hand, Antiprosynthesis, the (beloved? notorious? famous?) Twitter info-warrior, has decreased from $13,813 to $5,350, while <a href="https://gitcoin.co/grants/174/defi-educational-videos-by-chris-blec">Chris Blec's YouTube channel</a> has <em>increased</em> from $5,851 to $12,803. So some churn, but also some continuity between rounds.</p>
<p>On the tech side, we see much more churn in the winners, with a less clear relationship between income last round and income this round:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round5/tech_scatter.png?1" />
</center>
<p><br></p>
<p>Last round, the winner was Tornado Cash, claiming $30,783; this round, they are down to $8,154. This round, the three roughly-even winners are <a href="https://gitcoin.co/grants/444/white-hat-hacking">Samczsun</a> ($4,631 contributions + $15,704 match = $20,335 total), <a href="https://gitcoin.co/grants/618/arboreum">Arboreum</a> ($16,084 contributions + $9,046 match = $25,128 total) and <a href="https://gitcoin.co/grants/246/1split">1inch.exchange</a> ($58,566 contributions + $7,893 match = $66,459 total), in the latter case the bulk coming from one contribution:</p>
<center>
<a href="https://gitcoin.co/tgerring"><img src="http://vitalik.ca/files/posts_files/round5/tgerring.png" /></a>
</center>
<p><br></p>
<p>In the previous round, those three winners were not even in the top ten, and in some cases not even part of Gitcoin Grants at all.</p>
<p>These numbers show us two things. First, large parts of the Gitcoin community seem to be in the mindset of treating grants not as a question of "how much do you deserve for your last two months of work?", but rather as a one-off reward for years of contributions in the past. This was one of the strongest rebuttals that I received to my <a href="https://vitalik.ca/general/2020/01/28/round4.html">criticism of Antiprosynthesis receiving $13,813 in the last round</a>: that the people who contributed to that award did not see it as two months' salary, but rather as a reward for years of dedication and work for the Ethereum ecosystem. In the next round, contributors were content that the debt was sufficiently repaid, and so they moved on to give a similar gift of appreciation and gratitude to Chris Blec.</p>
<p>That said, not everyone contributes in this way. For example, Prysm got $7,966 last round and $8,033 this round, and Week in Ethereum is consistently well-rewarded ($16,727 previous, $12,195 current), and EthHub saw less stability but still kept half its income ($13,515 previous, $6,705 current) even amid a 20% drop to the matching pool size as some funds were redirected to public health. So there definitely are some contributors that <em>are</em> getting almost a reasonable monthly salary from Gitcoin Grants (yes, even these amounts are all serious underpayment, but remember that the pool of funds Gitcoin Grants has to distribute in the first place is quite small, so there's no allocation that would <em>not</em> seriously underpay most people; the hope is that in the future we will find ways to make the matching pot grow bigger).</p>
<h3 id="why-didnt-more-people-use-recurring-contributions">Why didn't more people use recurring contributions?</h3>
<p>One feature that was tested this round to try to improve stability was recurring contributions: users could choose to split their contribution among multiple rounds. However, the feature was not used often: out of over 8,000 total contributions, only 120 actually made recurring contributions. I can think of three possible explanations for this:</p>
<ol type="1">
<li>People just don't want to give recurring contributions; they genuinely prefer to freshly rethink who they are supporting every round.</li>
<li>People would be willing to give more recurring contributions, but there is some kind of "market failure" stopping them; that is, it's collectively optimal for everyone to give more recurring contributions, but it's not any individual contributor's interest to be the first to do so.</li>
<li>There's some UI inconveniences or other "incidental" obstacles preventing recurring contributions.</li>
</ol>
<p>In a recent call with the Gitcoin team, hypothesis (3) was mentioned frequently. A specific issue was that people were worried about making recurring contributions because they were concerned whether or not the money that they lock up for a recurring contribution would be safe. Improving the payment system and notification workflow may help with this. Another option is to move away from explicit "streaming" and instead simply have the UI provide an option for repeating the last round's contributions and making edits from there.</p>
<p>Hypothesis (1) also should be taken seriously; there's genuine value in preventing ossification and allowing space for new entrants. But I want to zoom in particularly on hypothesis (2), the coordination failure hypothesis.</p>
<p>My explanation of hypothesis (2) starts, interestingly enough, with a defense of (1): why ossification is genuinely a risk. Suppose that there are two projects, A and B, and suppose that they are equal quality. But A already has an established base of contributors; B does not (we'll say for illustration it only has a few existing contributors). Here's how much matching you are contributing by participating in each project:</p>
<center>
<table>
<tr>
<td>
Contributing to A
</td>
<td>
Contributing to B
</td>
</tr>
<tr>
<td>
Â
</td>
<td>
Â
</td>
</tr>
<tr>
<td>
<img src="http://vitalik.ca/files/posts_files/round5/QF1.png">
</td>
<td>
<img src="http://vitalik.ca/files/posts_files/round5/QF2.png">
</td>
</tr>
</table>
</center>
<p><br></p>
<p>Clearly, you have more impact by supporting A, and so A gets even more contributors and B gets fewer; the rich get richer. Even if project B was <em>somewhat better</em>, the greater impact from supporting A could still create a lock-in that reinforces A's position. The current everyone-starts-from-zero-in-each-round mechanism greatly limits this type of entrenchment, because, well, everyone's matching gets reset and starts from zero.</p>
<p>However, a very similar effect also is the cause behind the market failure preventing stable recurring contributions, and the every-round-reset <em>actually exacerbates it</em>. Look at the same picture above, except instead of thinking of A and B as <em>two different projects</em>, think of them as <em>the same project in the current round and in the next round</em>.</p>
<p>We simplify the model as follows. An individual has two choices: contribute $10 in the current round, or contribute $5 in the current round and $5 in the next round. If the matchings in the two rounds were equal, then the latter option would actually be more favorable: because the matching is proportional to the square root of the donation size, the former might give you eg. a $200 match now, but the latter would give you $141 in the current round + $141 in the next round = $282. But if you see a large mass of people contributing in the current round, and you expect much fewer people to contribute in the second round, then the choice is not $200 versus $141 + $141, it might be $200 versus $141 + $5. And so you're better off joining the current round's frenzy. We can mathematically analyze the equilibrium:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round5/split.png" />
</center>
<p><br></p>
<p>So there is a substantial region within which the bad equilibrium of everyone concentrating is sticky: if more than about 3/4 of contributors are expected to concentrate, it seems in your interest to also concentrate. A mathematically astute reader may note that there is <a href="http://vitalik.ca/files/posts_files/round5/split2.png">always some intermediate strategy</a> that involves splitting but at a ratio different from 50/50, which you can prove performs better than either full concentrating <em>or</em> the even split, but here we get back to hypothesis (3) above: the UI doesn't offer such a complex menu of choices, it just offers the choice of a one-time contribution or a recurring contribution, so people pick one or the other.</p>
<p>How might we fix this? One option is to add a bit of continuity to matching ratios: when computing pairwise matches, match against not just the current round's contributors but, say, 1/3 of the previous round's contributors as well:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round5/QF3.png" />
</center>
<p><br></p>
<p>This makes some philosophical sense: the objective of quadratic funding is to subsidize contributions to projects that are detected to be public goods because multiple people have contributed to them, and contributions in the previous round are certainly also evidence of a project's value, so why not reuse those? So here, moving away from everyone-starts-from-zero toward this partial carryover of matching ratios would mitigate the round concentration effect - but, of course, it would exacerbate the risk of entrenchment. Hence, some experimentation and balance may be in order. A broader philosophical question is, is there really a deep inherent tradeoff between risk of entrenchment and stability of income, or is there some way we could get both?</p>
<h3 id="responses-to-negative-contributions">Responses to negative contributions</h3>
<p>This round also introduced negative contributions, a feature proposed in my <a href="https://vitalik.ca/general/2020/01/28/round4.html">review of the previous round</a>. But as with recurring contributions, very few people made negative contributions, to the point where their impact on the results was negligible. Also, there was <a href="https://twitter.com/evan_van_ness/status/1250152866519621632?s=20">active</a> <a href="https://twitter.com/evan_van_ness/status/1248390335048216576?s=20">opposition</a> to <a href="https://twitter.com/ljxie/status/1250178888946176000?s=20">negative</a> <a href="https://twitter.com/josephdelong/status/1250175753372807170?s=20">contributions</a>:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round5/meme.jpeg" /><br><small><i>Source: honestly I have no idea, someone else sent it to me and they forgot where they found it. Sorry :(</i></small>
</center>
<p><br></p>
<p>The main source of opposition was basically what I predicted in the previous round. Adding a mechanism that allows people to penalize others, even if deservedly so, can have tricky and easily harmful social consequences. Some people even opposed the negative contribution mechanism to the point where they took care to give positive contributions to everyone who received a negative contribution.</p>
<p>How do we respond? To me it seems clear that, in the long run, <em>some</em> mechanism of filtering out bad projects, and ideally compensating for overexcitement into good projects, will have to exist. It doesn't necessarily need to be integrated as a symmetric part of the QF, but there does need to be a filter of some form. And this mechanism, whatever form it will take, invariably opens up the possibility of the same social dynamics. So there is a challenge that will have to be solved no matter how we do it.</p>
<p>One approach would be to hide more information: instead of just hiding <em>who</em> made a negative contribution, outright hide the fact that a negative contribution was made. Many opponents of negative contributions explicitly indicated that they would be okay (or at least more okay) with such a model. And indeed (see the next section), this is a direction we will have to go anyway. But it would come at a cost - effectively hiding negative contributions would mean not giving as much real-time feedback into what projects got how much funds.</p>
<h3 id="stepping-up-the-fight-against-collusion">Stepping up the fight against collusion</h3>
<p>This round saw much larger-scale attempts at collusion:</p>
<center>
<a href="https://twitter.com/owocki/status/1250097472694702080"><img src="http://vitalik.ca/files/posts_files/round5/collusion_tweet.png" /></a>
</center>
<p><br></p>
<p>It does seem clear that, at current scales, stronger protections against manipulation are goingto be required. The first thing that can be done is adding a stronger identity verification layer than Github accounts; this is something that the Gitcoin team is already working on. There is definitely a complex tradeoff between security and inclusiveness to be worked through, but it is not especially difficult to implement a first version. And if the identity problem is solved to a reasonable extent, that will likely be enough to prevent collusion at current scales. But in the longer term, we are going to need protection not just against manipulating the system by making many fake accounts, but also against collusion via bribes (explicit and implicit).</p>
<p><a href="https://github.com/barryWhiteHat/maci/blob/master/specs/01_introduction.md">MACI</a> is the solution that I proposed (and Barry Whitehat and co are implementing) to solve this problem. Essentially, MACI is a cryptographic construction that allows for contributions to projects to happen on-chain in a privacy-preserving, encrypted form, that allows anyone to cryptographically verify that the mechanism is being implemented <em>correctly</em>, but prevents participants from being able to prove to a third party that they made any particular contribution. Unprovability means that if someone tries to bribe others to contribute to their project, the bribe recipients would have no way to prove that they actually contributed to that project, making the bribe unenforceable. Benign "collusion" in the form of friends and family supporting each other would still happen, as people would not easily lie to each other at such small scales, but any broader collusion would be very difficult to maintain.</p>
<p>However, we do need to think through some of the second-order consequences that integrating MACI would introduce. The biggest blessing, and curse, of using MACI is that contributions become hidden. Identities necessarily become hidden, but even the exact timing of contributions would need to be hidden to prevent deanonymization through timing (to prove that <em>you</em> contributed, make the total amount jump up between 17:40 and 17:42 today). Instead, for example, totals could be provided and updated once per day. Note that as a corollary negative contributions would be hidden as well; they would only appear if they exceeded all positive contributions for an entire day (and if even that is not desired then the mechanism for when balances are updated could be tweaked to further hide downward changes).</p>
<p>The challenge with hiding contributions is that we lose the "social proof" motivator for contributing: if contributions are unprovable you can't as easily publicly brag about a contribution you made. My best proposal for solving this is for the mechanism to publish one extra number: the <em>total</em> amount that a particular participant contributed (counting only projects that have received at least 10 contributors to prevent inflating one's number by self-dealing). Individuals would then have a generic "proof-of-generosity" that they contributed some specific <em>total</em> amount, and could publicly state (without proof) what projects it was that they supported. But this is all a significant change to the user experience that will require multiple rounds of experimentation to get right.</p>
<h3 id="conclusions">Conclusions</h3>
<p>All in all, Gitcoin Grants is establishing itself as a significant pillar of the Ethereum ecosystem that more and more projects are relying on for some or all of their support. While it has a relatively low amount of funding at present, and so inevitably underfunds almost everything it touches, we hope that over time we'll continue to see larger sources of funding for the matching pools appear. One option is <a href="https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788">MEV auctions</a>, another is that new or existing token projects looking to do airdrops could provide the tokens to a matching pool. A third is transaction fees of various applications. With larger amounts of funding, Gitcoin Grants could serve as a more significant funding stream - though to get to that point, further iteration and work on fine-tuning the mechanism will be required.</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round5/health2.jpg" style="width:375px" />
</center>
<p><br></p>
<p>Additionally, this round saw Gitcoin Grants' first foray into applications beyond Ethereum with the health section. There is growing interest in quadratic funding from local government bodies and other non-blockchain groups, and it would be very valuable to see quadratic funding more broadly deployed in such contexts. That said, there are unique challenges there too. First, there's issues around onboarding people who do not already have cryptocurrency. Second, the Ethereum community is naturally expert in the needs of the Ethereum community, but neither it nor average people are expert in, eg. medical support for the coronavirus pandemic. We should expect quadratic funding to perform worse when the participants are not experts in the domain they're being asked to contribute to. Will non-blockchain uses of QF focus on domains where there's a clear local community that's expert in its own needs, or will people try larger-scale deployments soon? If we do see larger-scale deployments, how will those turn out? There's still a lot of questions to be answered.</p>
Thu, 30 Apr 2020 17:03:10 -0700
https://vitalik.ca/general/2020/04/30/round5.html
https://vitalik.ca/general/2020/04/30/round5.htmlgeneralA Quick Garbled Circuits Primer<p><em>Special thanks to Dankrad Feist for review</em></p>
<p><a href="https://en.wikipedia.org/wiki/Garbled_circuit">Garbled circuits</a> are a quite old, and surprisingly simple, cryptographic primitive; they are quite possibly the simplest form of general-purpose "multi-party computation" (MPC) to wrap your head around.</p>
<p>Here is the usual setup for the scheme:</p>
<ul>
<li>Suppose that there are two parties, Alice and Bob, who want to compute some function <code>f(alice_inputs, bob_inputs)</code>, which takes inputs from both parties. Alice and Bob want to both learn the result of computing <code>f</code>, but Alice does not want Bob to learn her inputs, and Bob does not want Alice to learn his inputs. Ideally, they would both learn nothing except for just the output of <code>f</code>.</li>
<li>Alice performs a special procedure ("garbling") to encrypt a circuit (meaning, a set of AND, OR... gates) which evaluates the function <code>f</code>. She passes along inputs, also encrypted in a way that's compatible with the encrypted circuit, to Bob.</li>
<li>Bob uses a technique called "1-of-2 oblivious transfer" to learn the encrypted form of his own inputs, without letting Alice know which inputs he obtained.</li>
<li>Bob runs the encrypted circuit on the encrypted data and gets the answer, and passes it along to Alice.</li>
</ul>
<p>Extra cryptographic wrappings can be used to protect the scheme against Alice and Bob sending wrong info and giving each other an incorrect answer; we won't go into those here for simplicity, though it suffices to say "wrap a ZK-SNARK around everything" is one (quite heavy duty and suboptimal!) solution that works fine.</p>
<p>So how does the basic scheme work? Let's start with a circuit:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/garbled/circuit.png" />
</center>
<p><br></p>
<p>This is one of the simplest examples of a not-completely-trivial circuit that actually does something: it's a two-bit adder. It takes as input two numbers in binary, each with two bits, and outputs the three-bit binary number that is the sum.</p>
<p>Now, let's encrypt the circuit. First, for every input, we randomly generate two "labels" (think: 256-bit numbers): one to represent that input being 0 and the other to represent that input being 1. Then we also do the same for every intermediate wire, not including the output wires. Note that this data is not part of the "garbling" that Alice sends to Bob; so far this is just setup.</p>
<center>
<img src="https://vitalik.ca/files/posts_files/garbled/circuit2.png" />
</center>
<p><br></p>
<p>Now, for every gate in the circuit, we do the following. For every combination of inputs, we include in the "garbling" that Alice provides to Bob the label of the output (or if the label of the output is a "final" output, the output directly) encrypted with a key generated by hashing the input labels that lead to that output together. For simplicity, our encryption algorithm can just be <code>enc(out, in1, in2) = out + hash(k, in1, in2)</code> where <code>k</code> is the index of the gate (is it the first gate in the circuit, the second, the third?). If you know the labels of both inputs, and you have the garbling, then you can learn the label of the corresponding output, because you can just compute the corresponding hash and subtract it out.</p>
<p>Here's the garbling of the first XOR gate:</p>
<table border="1">
<tr>
<td>
Inputs
</td>
<td>
Output
</td>
<td>
Encoding of output
</td>
</tr>
<tr>
<td>
00
</td>
<td>
0
</td>
<td>
0 + hash(1, 6816, 6529)
</td>
</tr>
<tr>
<td>
01
</td>
<td>
1
</td>
<td>
1 + hash(1, 6816, 4872)
</td>
</tr>
<tr>
<td>
10
</td>
<td>
1
</td>
<td>
1 + hash(1, 8677, 6529)
</td>
</tr>
<tr>
<td>
11
</td>
<td>
0
</td>
<td>
0 + hash(1, 8677, 4872)
</td>
</tr>
</table>
<p><br></p>
<p>Notice that we are including the (encrypted forms of) 0 and 1 directly, because this XOR gate's outputs are directly final outputs of the program. Now, let's look at the leftmost AND gate:</p>
<table border="1">
<tr>
<td>
Inputs
</td>
<td>
Output
</td>
<td>
Encoding of output
</td>
</tr>
<tr>
<td>
00
</td>
<td>
0
</td>
<td>
5990 + hash(2, 6816, 6529)
</td>
</tr>
<tr>
<td>
01
</td>
<td>
0
</td>
<td>
5990 + hash(2, 6816, 4872)
</td>
</tr>
<tr>
<td>
10
</td>
<td>
0
</td>
<td>
5990 + hash(2, 8677, 6529)
</td>
</tr>
<tr>
<td>
11
</td>
<td>
1
</td>
<td>
1921 + hash(2, 8677, 4872)
</td>
</tr>
</table>
<p><br></p>
<p>Here, the gate's outputs are just used as inputs to other gates, so we use labels instead of bits to hide these intermediate bits from the evaluator.</p>
<p>The "garbling" that Alice would provide to Bob is just everything in the third column for each gate, with the rows of each gate re-ordered (to avoid revealing whether a given row corresponds to a 0 or a 1 in any wire). To help Bob learn which value to decrypt for each gate, we'll use a particular order: for each gate, the first row becomes the row where both input labels are even, in the second row the second label is odd, in the third row the first label is odd, and in the fourth row both labels are odd (we deliberately chose labels earlier so that each gate would have an even label for one output and an odd label for the other). We garble every other gate in the circuit in the same way.</p>
<p>All in all, Alice sends to Bob four ~256 bit numbers for each gate in the circuit. It turns out that four is far from optimal; see <a href="http://web.mit.edu/sonka89/www/papers/2017ygc.pdf">here</a> for some optimizations on how to reduce this to three or even two numbers for an AND gate and zero (!!) for an XOR gate. Note that these optimizations do rely on some changes, eg. using XOR instead of addition and subtraction, though this should be done anyway for security.</p>
<p>When Bob receives the circuit, he asks Alice for the labels corresponding to her input, and he uses a protocol called "1-of-2 oblivious transfer" to ask Alice for the labels corresponding to his own input without revealing to Alice what his input is. He then goes through the gates in the circuit one by one, uncovering the output wires of each intermediate gate.</p>
<p>Suppose Alice's input is the two left wires and she gives (0, 1), and Bob's input is the two right wires and he gives (1, 1). Here's the circuit with labels again:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/garbled/circuit2.png" />
</center>
<p><br></p>
<ul>
<li>At the start, Bob knows the labels 6816, 3621, 4872, 5851</li>
<li>Bob evaluates the first gate. He knows 6816 and 4872, so he can extract the output value corresponding to (1, 6816, 4872) (see the table above) and extracts the first output bit, 1</li>
<li>Bob evaluates the second gate. He knows 6816 and 4872, so he can extract the output value corresponding to (2, 6816, 4872) (see the table above) and extracts the label 5990</li>
<li>Bob evaluates the third gate (XOR). He knows 3621 and 5851, and learns 7504</li>
<li>Bob evaluates the fourth gate (OR). He knows 3621 and 5851, and learns 6638</li>
<li>Bob evaluates the fifth gate (AND). He knows 3621 and 5851, and learns 7684</li>
<li>Bob evaluates the sixth gate (XOR). He knows 5990 and 7504, and learns the second output bit, 0</li>
<li>Bob evaluates the seventh gate (AND). He knows 5990 and 6638, and learns 8674</li>
<li>Bob evaluates the eighth gate (OR). He knows 8674 and 7684, and learns the third output bit, 1</li>
</ul>
<p>And so Bob learns the output: 101. And in binary 10 + 11 actually equals 101 (the input and output bits are both given in smallest-to-greatest order in the circuit, which is why Alice's input 10 is represented as (0, 1) in the circuit), so it worked!</p>
<p>Note that addition is a fairly pointless use of garbled circuits, because Bob knowing 101 can just subtract out his own input and get 101 - 11 = 10 (Alice's input), breaking privacy. However, in general garbled circuits can be used for computations that are not reversible, and so don't break privacy in this way (eg. one might imagine a computation where Alice's input and Bob's input are their answers to a personality quiz, and the output is a single bit that determines whether or not the algorithm thinks they are compatible; that one bit of information won't let Alice or Bob know anything about each other's individual quiz answers).</p>
<h3 id="of-2-oblivious-transfer">1 of 2 Oblivious Transfer</h3>
<p>Now let us talk more about 1-of-2 oblivious transfer, this technique that Bob used to obtain the labels from Alice corresponding to his own input. The problem is this. Focusing on Bob's first input bit (the algorithm for the second input bit is the same), Alice has a label corresponding to 0 (6529), and a label corresponding to 1 (4872). Bob has his desired input bit: 1. Bob wants to learn the correct label (4872) without letting Alice know that his input bit is 1. The trivial solution (Alice just sends Bob both 6529 and 4872) doesn't work because Alice only wants to give up one of the two input labels; if Bob receives both input labels this could leak data that Alice doesn't want to give up.</p>
<p>Here is <a href="https://crypto.stanford.edu/pbc/notes/crypto/ot.html">a fairly simple protocol</a> using elliptic curves:</p>
<ol type="1">
<li>Alice generates a random elliptic curve point, <code>H</code>.</li>
<li>Bob generates two points, <code>P1</code> and <code>P2</code>, with the requirement that <code>P1 + P2</code> sums to <code>H</code>. Bob chooses either <code>P1</code> or <code>P2</code> to be <code>G * k</code> (ie. a point that he knows the corresponding private key for). Note that the requirement that <code>P1 + P2 = H</code> ensures that Bob has no way to generate <code>P1</code> and <code>P2</code> such that he knows the corresponding private key for. This is because if <code>P1 = G * k1</code> and <code>P2 = G * k2</code> where Bob knows both <code>k1</code> and <code>k2</code>, then <code>H = G * (k1 + k2)</code>, so that would imply Bob can extract the discrete logarithm (or "corresponding private key") for <code>H</code>, which would imply all of elliptic curve cryptography is broken.</li>
<li>Alice confirms <code>P1 + P2 = H</code>, and encrypts <code>v1</code> under <code>P1</code> and <code>v2</code> under <code>P2</code> using some standard public key encryption scheme (eg. <a href="https://en.wikipedia.org/wiki/ElGamal_encryption">El-Gamal</a>). Bob is only able to decrypt one of the two values, because he knows the private key corresponding to at most one of <code>(P1, P2)</code>, but Alice does not know which one.</li>
</ol>
<p>This solves the problem; Bob learns one of the two wire labels (either 6529 or 4872), depending on what his input bit is, and Alice does not know which label Bob learned.</p>
<h3 id="applications">Applications</h3>
<p>Garbled circuits are potentially useful for many more things than just 2-of-2 computation. For example, you can use them to make multi-party computations of arbitrary complexity with an arbitrary number of participants providing inputs, that can run in a constant number of rounds of interaction. Generating a garbled circuit is completely parallelizable; you don't need to finish garbling one gate before you can start garbling gates that depend on it. Hence, you can simply have a large multi-party computation with many participants compute a garbling of all gates of a circuit and publish the labels corresponding to their inputs. The labels themselves are random and so reveal nothing about the inputs, but anyone can then execute the published garbled circuit and learn the output "in the clear". See <a href="https://eprint.iacr.org/2017/189.pdf">here</a> for a recent example of an MPC protocol that uses garbling as an ingredient.</p>
<p>Multi-party computation is not the only context where this technique of splitting up a computation into a parallelizable part that operates on secret data followed by a sequential part that can be run in the clear is useful, and garbled circuits are not the only technique for accomplishing this. In general, the literature on <a href="https://eprint.iacr.org/2017/385.pdf">randomized encodings</a> includes many more sophisticated techniques. This branch of math is also useful in technologies such as <a href="https://en.wikipedia.org/wiki/Functional_encryption">functional encryption</a> and <a href="https://en.wikipedia.org/wiki/Indistinguishability_obfuscation">obfuscation</a>.</p>
Sat, 21 Mar 2020 17:03:10 -0700
https://vitalik.ca/general/2020/03/21/garbled.html
https://vitalik.ca/general/2020/03/21/garbled.htmlgeneralReview of Gitcoin Quadratic Funding Round 4<p>Round 4 of Gitcoin Grants quadratic funding has just completed, and here are the results:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round4-files/tech_vertical.jpg" style="width:365px" /> <img src="http://vitalik.ca/files/posts_files/round4-files/media_vertical.jpg" style="width:365px" /> <br><br>
</center>
<p>The main distinction between round 3 and round 4 was that while round 3 had only one category, with mostly tech projects and a few outliers such as EthHub, in round 4 there were two separate categories, one with a $125,000 matching pool for tech projects, and the other with a $75,000 matching pool for "media" projects. Media could include documentation, translation, community activities, news reporting, theoretically pretty much anything in that category. And while the tech section went about largely without incident, in the new media section <strong>the results proved to be much more interesting than I could have possibly imagined, shedding a new light on deep questions in institutional design and political science</strong>.</p>
<h3 id="tech-quadratic-funding-worked-great-as-usual">Tech: quadratic funding worked great as usual</h3>
<p>In the tech section, the main changes that we see compared to round 3 are (i) the rise of <a href="https://tornado.cash/">Tornado Cash</a> and (ii) the decline in importance of eth2 clients and the rise of "utility applications" of various forms. Tornado Cash is a trustless smart contract-based Ethereum mixer. It became popular quickly in recent months, as the Ethereum community was swept by worries about the blockchain's current <a href="https://www.cryptopolitan.com/jeffrey-wilcke-sold-92k-eth/">low levels of privacy</a> and wanted solutions. Tornado Cash amassed an incredible $31,200. If they continue receiving such an amount every two months then this would allow them to pay two people $7,800 per month each - meaning that the hoped-for milestone of seeing the first "quadratic freelancer" may have already been reached! The other major winners included tools like <a href="https://dappnode.io">Dappnode</a>, a software package to help people run nodes, <a href="https://www.sablier.finance/">Sablier</a>, a payment streaming service, and <a href="https://gitcoin.co/grants/235/defizap">DefiZap</a>, which makes DeFi services easy to use. The <a href="https://gitcoin.co/grants/86/gitcoin-sustainability-fund">Gitcoin Sustainability Fund</a> got over $13,000, conclusively resolving my complaint from <a href="https://vitalik.ca/general/2019/10/24/gitcoin.html">last round</a> that they were under-supported. All in all, valuable grants for valuable projects that provide services that the community genuinely needs.</p>
<p>We can see one major shift this round compared to the previous rounds. Whereas in previous rounds, the grants went largely to projects like eth2 clients that were already well-supported, this time the largest grants shifted toward having a different focus from the grants given by the Ethereum Foundation. The EF has not given grants to tornado.cash, and generally limits its grants to application-specific tools, Uniswap being a notable exception. The Gitcoin Grants quadratic fund, on the other hand, is supporting DeFiZap, Sablier, and many other tools that are valuable to the community. This is arguably a positive development, as it allows Gitcoin Grants and the Ethereum Foundation to complement each other rather than focusing on the same things.</p>
<p>The one proposed change to the quadratic funding implementation for tech that I would favor is a user interface change, that makes it easier for users to commit funds for multiple rounds. This would increase the stability of contributions, thereby increasing the stability of projects' income - very important if we want "quadratic freelancer" to actually be a viable job category!</p>
<h3 id="media-the-first-quadratic-twitter-freelancer">Media: The First Quadratic Twitter Freelancer</h3>
<p>Now, we get to the new media section. In the first few days of the round, the leading recipient of the grants was "<span class="citation" data-cites="antiprosynth">@antiprosynth</span> Twitter account activity": an Ethereum community member who is <a href="https://twitter.com/antiprosynth">very active on twitter</a> promoting Ethereum and refuting misinformation from Bitcoin maximalists, asking for help from the Gitcoin QF crowd to.... fund his tweeting activities. At its peak, the projected matching going to <span class="citation" data-cites="antiprosynth">@antiprosynth</span> exceeded $20,000. This naturally proved to be controversial, with many criticizing this move and questioning whether or not a Twitter account is a legitimate public good:</p>
<center>
<a href="https://twitter.com/hitchcott/status/1216548157238079490"><img src="http://vitalik.ca/files/posts_files/round4-files/tweet1.png" /></a> <br><br>
</center>
<p>On the surface, it does indeed seem like someone getting paid $20,000 for operating a Twitter account is ridiculous. But it's worth digging in and questioning exactly <em>what</em>, if anything, is actually wrong with this outcome. After all, maybe this is what effective marketing in 2020 actually looks like, and it's our expectations that need to adapt.</p>
<p>There are two main objections that I heard, and both lead to interesting criticisms of quadratic funding in its current implementation. First, there was criticism of <strong>overpayment</strong>. Twittering is a fairly "trivial" activity; it does not require <em>that</em> much work, lots of people do it for free, and it doesn't provide nearly as much long-term value as something more substantive like <a href="https://ethhub.io/">EthHub</a> or the <a href="https://gitcoin.co/grants/329/zero-knowledge-podcast-2">Zero Knowledge Podcast</a>. Hence, it feels wrong to pay a full-time salary for it.</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round4-files/antiprosynth1.png" style="width:300px" /> <img src="http://vitalik.ca/files/posts_files/round4-files/antiprosynth2.png" style="width:300px" /> <img src="http://vitalik.ca/files/posts_files/round4-files/antiprosynth3.png" style="width:300px" /> <br> <i><small>Examples of <span class="citation" data-cites="antiprosynth">@antiprosynth</span>'s recent tweets</small></i> <br><br>
</center>
<p>If we accept the metaphor of quadratic funding as being like a <a href="https://vitalik.ca/general/2019/12/07/quadratic.html">market for public goods</a>, then one could simply extend the metaphor, and reply to the concern with the usual free-market argument. People voluntarily paid their own money to support <span class="citation" data-cites="antiprosynth">@antiprosynth</span>'s twitter activity, and that itself signals that it's valuable. Why should we trust you with your mere words and protestations over a costly signal of real money on the table from dozens of people?</p>
<p>The most plausible answer is actually quite similar to one that you often hear in discussions about financial markets: markets can give skewed results when you can express an opinion <em>in favor of</em> something but cannot express an opinion <em>against</em> it. When short selling is not possible, financial markets <a href="https://ethresear.ch/t/token-sales-and-shorting/376">are often much more inefficient</a>, because instead of reflecting the <em>average</em> opinion on an asset's true value, a market may instead reflect the inflated expectations of an asset's few rabid supporters. In this version of quadratic funding, <strong>there too is an asymmetry, as you can donate in support of a project but you cannot donate to oppose it</strong>. Might this be the root of the problem?</p>
<p>One can go further and ask, why might overpayment happen to this particular project, and not others? I have heard a common answer: twitter accounts <em>already have a high exposure</em>. A client development team like <a href="https://nethermind.io/">Nethermind</a> does not gain much publicity through their work directly, so they need to separately market themselves, whereas a twitter account's "work" is self-marketing by its very nature. Furthermore, the most prominent twitterers get quadratically more matching out of their exposure, amplifying their outsized advantage further - a problem I alluded to in my <a href="https://vitalik.ca/general/2019/10/24/gitcoin.html">review of round 3</a>.</p>
<p>Interestingly, in the case of vanilla quadratic voting there <a href="http://www.econ.msu.edu/seminars/docs/QuadMultAltshort19.pdf">was an argument</a> made by Glen Weyl for why economies-of-scale effects of traditional voting, such as <a href="https://en.wikipedia.org/wiki/Duverger%27s_law">Duverger's law</a>, don't apply to quadratic voting: a project becoming more prominent increases the incentive to give it both positive and negative votes, so on net the effects cancel out. But notice once again, that <strong>this argument relies on negative votes being a possibility</strong>.</p>
<h3 id="good-for-the-tribe-but-is-it-good-for-the-world">Good for the tribe, but is it good for the world?</h3>
<p>The particular story of <span class="citation" data-cites="antiprosynth">@antiprosynth</span> had what is in my opinion a happy ending: over the next ten days, more contributions came in to other candidates, and <span class="citation" data-cites="antiprosynth">@antiprosynth</span>'s match reduced to $11,316, still a respectably high amount but on par with EthHub and below Week in Ethereum. However, even a quadratic matching grant of this size still raises to the next criticism: <strong>is twittering a public good or public bad anyway</strong>?</p>
<p>Traditionally, public goods of the type that Gitcoin Grants quadratic funding is trying to support were selected and funded by governments. The motivation of <span class="citation" data-cites="antiprosynth">@antiprosynth</span>'s tweets is "aggregating Ethereum-related news, fighting information asymmetry and fine-tuning/signaling a consistent narrative for Ethereum (and ETH)": essentially, fighting the good fight against anti-Ethereum misinformation by <a href="https://blog.ethereum.org/2014/11/20/bitcoin-maximalism-currency-platform-network-effects/">bitcoin maximalists</a>. And, lo and behold, governments too have a rich history of <a href="https://en.wikipedia.org/wiki/State-sponsored_Internet_propaganda">sponsoring social media participants</a> to argue on their behalf. And it seems likely that most of these governments see themselves as "fighting the good fight against anti-[X] misinformation by [Y] {extremists, imperialists, totalitarians}", just as the Ethereum community feels a need to fight the good fight against maximalist trolls. From the inside view of each individual country (and in our case the Ethereum community) organized social media participation seems to be a clear public good (ignoring the possibility of blowback effects, which are real and important). But from the outside view of the entire world, it can be viewed as a zero-sum game.</p>
<center>
<img src="http://vitalik.ca/files/posts_files/round4-files/threelayer.png" /> <br><br>
</center>
<p>This is actually a common pattern to see in politics, and indeed there are many instances of larger-scale coordination that are precisely intended to undermine smaller-scale coordination that is seen as "good for the tribe but bad for the world": antitrust law, free trade agreements, state-level pre-emption of local zoning codes, anti-militarization agreements... the list goes on. A broad environment where public subsidies are generally viewed suspiciously also does quite a good job of limiting many kinds of malign local coordination. But as public goods become more important, and we discover better and better ways for communities to coordinate on producing them, that strategy's efficacy becomes more limited, and properly grappling with these discrepancies between what is good for the tribe and what is good for the world becomes more important.</p>
<p><strong>That said, internet marketing and debate is not a zero-sum game, and there are plenty of ways to engage in internet marketing and debate that are good for the world</strong>. Internet debate in general serves to help the public learn what things are true, what things are not true, what causes to support, and what causes to oppose. Some tactics are clearly not truth-favoring, but other tactics are quite truth-favoring. Some tactics are clearly offensive, but others are defensive. And in the ethereum community, there <a href="https://twitter.com/safetyth1rd/status/1221126919019749376">is</a> <a href="https://twitter.com/wmougayar/status/1192130181445640192">widespread</a> <a href="https://twitter.com/ErikNummer8/status/1220420334962335744">sentiment</a> that there is not enough resources going into marketing of <em>some</em> kind, and I personally agree with this sentiment.</p>
<p>What kind of marketing is positive-sum (good for tribe and good for world) and what kind of marketing is zero-sum (good for tribe but bad for world) is another question, and one that's worth the community debating. I naturally hope that the Ethereum community continues to value maintaining a moral high ground. Regarding the case of <span class="citation" data-cites="antiprosynth">@antiprosynth</span> himself, I cannot find any tactics that I would classify as bad-for-world, especially when compared to outright misinformation ("it's impossible to run a full node") that we often see used against Ethereum - but I am pro-ethereum and hence biased, hence the need to be careful.</p>
<h3 id="universal-mechanisms-particular-goals">Universal mechanisms, particular goals</h3>
<p>The story has another plot twist, which reveals yet another feature (or bug?) or quadratic funding. Quadratic funding <a href="https://arxiv.org/abs/1809.06421">was originally described</a> as "Formal Rules for a Society Neutral among Communities", the intention being to use it at a very large, potentially even global, scale. Anyone can participate as a project or as a participant, and projects that support public goods that are good for <em>any</em> "public" would be supported. In the case of Gitcoin Grants, however, the matching funds are coming from Ethereum organizations, and so there is an expectation that the system is there to support Ethereum projects. But there is nothing in the rules of quadratic funding that privileges Ethereum projects and prevents, say, Ethereum Classic projects from seeking funding using the same platform! And, of course, this is exactly what happened:</p>
<center>
<a href="https://gitcoin.co/grants/324/yazanator-twitter-account-activity"> <img src="http://vitalik.ca/files/posts_files/round4-files/tweet2.png" /></a> <br><br>
</center>
<p>So now the result is, $24 of funding from Ethereum organizations will be going toward supporting an Ethereum Classic promoter's twitter activity. To give people outside of the crypto space a feeling for what this is like, imagine the USA holding a quadratic funding raise, using government funding to match donations, and the result is that some of the funding goes to someone explicitly planning to use the money to talk on Twitter about how great Russia is (or vice versa). The matching funds are coming from Ethereum sources, and there's an implied expectation that the funds should support Ethereum, but nothing actually prevents, or even discourages, non-Ethereum projects from organizing to get a share of the matched funds on the platform!</p>
<h3 id="solutions">Solutions</h3>
<p>There are two solutions to these problems. One is to modify the quadratic funding mechanism to support negative votes in addition to positive votes. The mathematical theory behind quadratic voting already implies that it is the "right thing" to do to allow such a possibility (every positive number has a negative square root as well as a positive square root). On the other hand, there are social concerns that allowing for negative voting would cause more animosity and lead to other kinds of harms. After all, mob mentality is at its worst when it is against something rather than for something. Hence, it's my view that it's not certain that allowing negative contributions will work out well, but there is enough evidence that it might that it is definitely worth trying out in a future round.</p>
<p>The second solution is to use two separate mechanisms for identifying relative goodness of good projects and for screening out bad projects. For example, one could use a challenge mechanism followed by a majority ETH coin vote, or even at first just a centralized appointed board, to screen out bad projects, and then use quadratic funding as before to choose between good projects. This is less mathematically elegant, but it would solve the problem, and it would at the same time provide an opportunity to mix in a separate mechanism to ensure that chosen projects benefit Ethereum specifically.</p>
<p>But even if we adopt the first solution, defining boundaries for the quadratic funding itself may also be a good idea. There is intellectual precedent for this. In Elinor Ostrom's <a href="https://www.onthecommons.org/magazine/elinor-ostroms-8-principles-managing-commmons">eight principles for governing the commons</a>, defining clear boundaries about who has the right to access the commons is the first one. Without clear boundaries, Ostrom writes, "local appropriators face the risk that any benefits they produce by their efforts will be reaped by others who have not contributed to those efforts." In the case of Gitcoin Grants quadratic funding, one possibility would be to set the maximum matching coefficient for any pair of users to be proportional to the geometric average of their ETH holdings, using that as a proxy for measuring membership in the Ethereum community (note that this avoids being plutocratic because 1000 users with 1 ETH each would have a maximum matching of <span class="math inline">\(\approx k * 500,000\)</span> ETH, whereas 2 users with 500 ETH each would only have a maximum matching of <span class="math inline">\(k * 1,000\)</span> ETH).</p>
<h3 id="collusion">Collusion</h3>
<p>Another issue that came to the forefront this round was the issue of collusion. The math behind quadratic funding, which compensates for tragedies of the commons by magnifying individual contributions based on the total number and size of other contributions to the same project, only works if there is an actual tragedy of the commons limiting natural donations to the project. If there is a "quid pro quo", where people get something individually in exchange for their contributions, the mechanism can easily over-compensate. The long-run solution to this is something like <a href="https://github.com/barryWhiteHat/maci">MACI</a>, a cryptographic system that ensures that contributors have no way to prove their contributions to third parties, so any such collusion would have to be done by honor system. In the short run, however, the rules and enforcement has not yet been set, and this has led to vigorous debate about what kinds of quid pro quo are legitimate:</p>
<center>
<a href="https://twitter.com/ricburton/status/1217591449908404225"><img src="http://vitalik.ca/files/posts_files/round4-files/tweet3.png" /></a> <br><br>
</center>
<p><em>[Update 2020.01.29: the above was <a href="https://twitter.com/owocki/status/1222419312851353602?s=21">ultimately a result of a miscommunication from Gitcoin</a>; a member of the Gitcoin team had okayed Richard Burton's proposal to give rewards to donors without realizing the implications. So Richard himself is blameless here; though the broader point that we underestimated the need for explicit guidance about what kinds of quid pro quos are acceptable is very much real.]</em></p>
<p>Currently, the position is that <a href="https://twitter.com/owocki/status/1217993123311177728">quid pro quos are disallowed</a>, though there is a more nuanced feeling that informal social quid pro quos ("thank yous" of different forms) are okay, whereas formal and especially monetary or product rewards are a no-no. This seems like a reasonable approach, though it does put Gitcoin further into the uncomfortable position of being a central arbiter, compromising <a href="https://nakamoto.com/credible-neutrality/">credible neutrality</a> somewhat. One positive byproduct of this whole discussion is that it has led to much more awareness in the Ethereum community of what actually is a public good (as opposed to a "private good" or a "club good"), and more generally brought public goods much further into the public discourse.</p>
<h3 id="conclusions">Conclusions</h3>
<p>Whereas round 3 was the first round with enough participants to have any kind of interesting effects, round 4 felt like a true "coming-out party" for the cause of decentralized public goods funding. The round attracted a large amount of attention from the community, and even from outside actors such as the Bitcoin community. It is part of a broader trend in the last few months where public goods funding has become a <a href="https://medium.com/ethereum-optimism/optimism-cd9bea61a3ee">dominant part</a> of the crypto community discourse. Along with this, we have also seen much more <a href="https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788">discussion</a> of <a href="https://twitter.com/MuteDialog/status/1207249423715229697">strategies</a> about long-term sources of funding for quadratic matching pools of larger sizes.</p>
<p>Discussions about funding will be important going forward: donations from large Ethereum organizations are enough to sustain quadratic matching at its current scale, but not enough to allow it to grow much further, to the point where we can have hundreds of quadratic freelancers instead of about five. At those scales, sources of funding for Ethereum public goods must rely on network effect lockin to some extent, or else they will have little more staying power than individual donations, but there are strong reasons not to embed these funding sources too deeply into Ethereum (eg. into the protocol itself, a la <a href="https://twitter.com/VitalikButerin/status/1220141595846033410">the recent BCH proposal</a>), to avoid risking the protocol's neutrality.</p>
<p>Approaches based on capturing transaction fees at layer 2 are surprisingly viable: currently, there are about $50,000-100,000 per day (~$18-35m per year) of transaction fees happening on Ethereum, roughly equal to the entire budget of the Ethereum Foundation. And there is evidence that <a href="https://arxiv.org/abs/1904.05234">miner-extractable value</a> is even higher. There are all discussions that we need to have, and challenges that we need to address, if we want the Ethereum community to be a leader in implementing decentralized, credibly neutral and market-based solutions to public goods funding challenges.</p>
Tue, 28 Jan 2020 16:03:10 -0800
https://vitalik.ca/general/2020/01/28/round4.html
https://vitalik.ca/general/2020/01/28/round4.htmlgeneralBase Layers And Functionality Escape Velocity<p>One common strand of thinking in blockchain land goes as follows: blockchains should be maximally simple, because they are a piece of infrastructure that is difficult to change and would lead to great harms if it breaks, and more complex functionality should be built on top, in the form of layer 2 protocols: <a href="https://www.jeffcoleman.ca/state-channels/">state channels</a>, <a href="https://ethresear.ch/t/minimal-viable-plasma/426">Plasma</a>, <a href="https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477">rollup</a>, and so forth. Layer 2 should be the site of ongoing innovation, layer 1 should be the site of stability and maintenance, with large changes only in emergencies (eg. a one-time set of serious breaking changes to prevent the base protocol's cryptography from falling to quantum computers would be okay).</p>
<p>This kind of layer separation is a very nice idea, and in the long term I strongly support this idea. However, this kind of thinking misses an important point: while layer 1 cannot be <em>too</em> powerful, as greater power implies greater complexity and hence greater brittleness, layer 1 must also be <em>powerful enough</em> for the layer 2 protocols-on-top that people want to build to actually be possible in the first place. Once a layer 1 protocol has achieved a certain level of functionality, which I will term "functionality escape velocity", then yes, you can do everything else on top without further changing the base. But if layer 1 is not powerful enough, then you can talk about filling in the gap with layer 2 systems, but the reality is that there is no way to actually build those systems, without reintroducing a whole set of trust assumptions that the layer 1 was trying to get away from. This post will talk about some of what this minimal functionality that constitutes "functionality escape velocity" is.</p>
<h3 id="a-programming-language">A programming language</h3>
<p>It must be possible to execute custom user-generated scripts on-chain. This programming language can be simple, and actually does not need to be high-performance, but it needs to at least have the level of functionality required to be able to verify arbitrary things that might need to be verified. This is important because the layer 2 protocols that are going to be built on top need to have some kind of verification logic, and this verification logic must be executed by the blockchain somehow.</p>
<p>You may have heard of <a href="https://en.wikipedia.org/wiki/Turing_completeness">Turing completeness</a>; the "layman's intuition" for the term being that if a programming language is Turing complete then it can do anything that a computer theoretically could do. Any program in one Turing-complete language can be translated into an equivalent program in any other Turing-complete language. However, it turns out that we only need something slightly lighter: it's okay to restrict to programs without loops, or programs which are <a href="https://en.wikipedia.org/wiki/Total_functional_programming">guaranteed to terminate</a> in a specific number of steps.</p>
<h3 id="rich-statefulness">Rich Statefulness</h3>
<p>It doesn't just matter that a programming language <em>exists</em>, it also matters precisely how that programming language is integrated into the blockchain. Among the more constricted ways that a language could be integrated is if it is used for pure transaction verification: when you send coins to some address, that address represents a computer program <code>P</code> which would be used to verify a transaction that sends coins <em>from</em> that address. That is, if you send a transaction whose hash is <code>h</code>, then you would supply a signature <code>S</code>, and the blockchain would run <code>P(h, S)</code>, and if that outputs TRUE then the transaction is valid. Often, <code>P</code> is a verifier for a cryptographic signature scheme, but it could do more complex operations. Note particularly that in this model <code>P</code> <em>does not have access</em> to the destination of the transaction.</p>
<p>However, this "pure function" approach is not enough. This is because this pure function-based approach is not powerful enough to implement many kinds of layer 2 protocols that people actually want to implement. It can do channels (and channel-based systems like the Lightning Network), but it cannot implement other scaling techniques with stronger properties, it cannot be used to bootstrap systems that do have more complicated notions of state, and so forth.</p>
<p>To give a simple example of what the pure function paradigm cannot do, consider a savings account with the following feature: there is a cryptographic key <code>k</code> which can initiate a withdrawal, and if a withdrawal is initiated, within the next 24 hours that same key <code>k</code> can cancel the withdrawal. If a withdrawal remains uncancelled within 24 hours, then anyone can "poke" the account to finalize that withdrawal. The goal is that if the key is stolen, the account holder can prevent the thief from withdrawing the funds. The thief could of course prevent the legitimate owner from getting the funds, but the attack would not be profitable for the thief and so they would probably not bother with it (see <a href="http://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-vaults/">the original paper</a> for an explanation of this technique).</p>
<p>Unfortunately this technique cannot be implemented with just pure functions. The problem is this: there needs to be some way to move coins from a "normal" state to an "awaiting withdrawal" state. But the program <code>P</code> does not have access to the destination! Hence, any transaction that could authorize moving the coins to an awaiting withdrawal state could also authorize just stealing those coins immediately; <code>P</code> can't tell the difference. The ability to change the state of coins, without completely setting them free, is important to many kinds of applications, including layer 2 protocols. Plasma itself fits into this "authorize, finalize, cancel" paradigm: an exit from Plasma must be approved, then there is a 7 day challenge period, and within that challenge period the exit could be cancelled if the right evidence is provided. Rollup also needs this property: coins inside a rollup must be controlled by a program that keeps track of a state root <code>R</code>, and changes from <code>R</code> to <code>R'</code> if some verifier <code>P(R, R', data)</code> returns TRUE - but it only changes the state to <code>R'</code> in that case, it does not set the coins free.</p>
<p>This ability to authorize state changes without completely setting all coins in an account free, is what I mean by "rich statefulness". It can be implemented in many ways, some UTXO-based, but without it a blockchain is not powerful enough to implement most layer 2 protocols, without including trust assumptions (eg. a set of functionaries who are collectively trusted to execute those richly-stateful programs).</p>
<p><small><i>Note: yes, I know that if <code>P</code> has access to <code>h</code> then you can just include the destination address as part of <code>S</code> and check it against <code>h</code>, and restrict state changes that way. But it is possible to have a programming language that is too resource-limited or otherwise restricted to actually do this; and surprisingly this often actually is the case in blockchain scripting languages.</i></small></p>
<h3 id="sufficient-data-scalability-and-low-latency">Sufficient data scalability and low latency</h3>
<p>It turns out that plasma and channels, and other layer 2 protocols that are fully off-chain have some fundamental weaknesses that prevent them from fully replicating the capabilities of layer 1. I go into this in detail <a href="https://vitalik.ca/general/2019/08/28/hybrid_layer_2.html">here</a>; the summary is that these protocols need to have a way of adjudicating situations where some parties maliciously fail to provide data that they promised to provide, and because data publication is not globally verifiable (you don't know when data was published unless you already downloaded it yourself) these adjudication games are not game-theoretically stable. Channels and Plasma cleverly get around this instability by adding additional assumptions, particularly assuming that for every piece of state, there is a single actor that is interested in that state not being incorrectly modified (usually because it represents coins that they own) and so can be trusted to fight on its behalf. However, this is far from general-purpose; systems like <a href="http://uniswap.exchange">Uniswap</a>, for example, include a large "central" contract that is not owned by anyone, and so they cannot effectively be protected by this paradigm.</p>
<p>There is one way to get around this, which is layer 2 protocols that publish very small amounts of data on-chain, but do computation entirely off-chain. If data is guaranteed to be available, then computation being done off-chain is okay, because games for adjudicating who did computation correctly and who did it incorrectly <em>are</em> game-theoretically stable (or could be replaced entirely by <a href="https://vitalik.ca/general/2017/02/01/zk_snarks.html">SNARKs</a> or <a href="https://vitalik.ca/general/2017/11/09/starks_part_1.html">STARKs</a>). This is the logic behind <a href="https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477">ZK rollup</a> and <a href="https://medium.com/plasma-group/ethereum-smart-contracts-in-l2-optimistic-rollup-2c1cef2ec537">optimistic rollup</a>. If a blockchain allows for the publication and guarantees the availability of a reasonably large amount of data, even if its capacity for <em>computation</em> remains very limited, then the blockchain can support these layer-2 protocols and achieve a high level of scalability <em>and</em> functionality.</p>
<p>Just how much data does the blockchain need to be able to process and guarantee? Well, it depends on what TPS you want. With a rollup, you can compress most activity to ~10-20 bytes per transaction, so 1 kB/sec gives you 50-100 TPS, 1 MB/sec gives you 50,000-100,000 TPS, and so forth. Fortunately, internet bandwidth <a href="http://www.circleid.com/posts/20191119_nielsens_law_of_internet_bandwidth/">continues to grow quickly</a>, and does not seem to be slowing down the way Moore's law for computation is, so increasing scaling for data without increasing computational load is quite a viable path for blockchains to take!</p>
<p>Note also that it is not just data capacity that matters, it is also data latency (ie. having low block times). Layer 2 protocols like rollup (or for that matter Plasma) only give any guarantees of security when the data actually is published to chain; hence, the time it takes for data to be reliably included (ideally "finalized") on chain is the time that it takes between when Alice sends Bob a payment and Bob can be confident that this payment will be included. The block time of the base layer sets the latency for anything whose confirmation depends things being included in the base layer. This could be worked around with on-chain security deposits, aka "bonds", at the cost of high capital inefficiency, but such an approach is inherently imperfect because a malicious actor could trick an unlimited number of different people by sacrificing one deposit.</p>
<h3 id="conclusions">Conclusions</h3>
<p>"Keep layer 1 simple, make up for it on layer 2" is NOT a universal answer to blockchain scalability and functionality problems, because it fails to take into account that layer 1 blockchains themselves must have a sufficient level of scalability and functionality for this "building on top" to actually be possible (unless your so-called "layer 2 protocols" are just trusted intermediaries). However, it is true that beyond a certain point, any layer 1 functionality <em>can</em> be replicated on layer 2, and in many cases it's a good idea to do this to improve upgradeability. Hence, we need <a href="https://vitalik.ca/general/2018/08/26/layer_1.html">layer 1 development in parallel with layer 2 development in the short term, and more focus on layer 2 in the long term</a>.</p>
Thu, 26 Dec 2019 02:03:10 -0800
https://vitalik.ca/general/2019/12/26/mvb.html
https://vitalik.ca/general/2019/12/26/mvb.htmlgeneralChristmas Special<p>Since it's Christmas time now, and we're theoretically supposed to be enjoying ourselves and spending time with our families instead of waging endless holy wars on Twitter, this blog post will offer some games that you can play with your friends that will help you have fun <em>and</em> at the same time understand some spooky mathematical concepts!</p>
<h3 id="dimensional-chess">1.58 dimensional chess</h3>
<center>
<br> <a href="https://twitter.com/el33th4xor/status/1138777837320716288"><img src="http://vitalik.ca/files/posts_files/christmas-files/chess_tweet.png" /></a> <br><br>
</center>
<p>This is a variant of chess where the board is set up like this:</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/chess.png" /> <br><br>
</center>
<p>The board is still a normal 8x8 board, but there are only 27 open squares. The other 37 squares should be covered up by checkers or Go pieces or anything else to denote that they are inaccessible. The rules are the same as chess, with a few exceptions:</p>
<ul>
<li>White pawns move up, black pawns move left. White pawns take going left-and-up or right-and-up, black pawns take going left-and-down or left-and-up. White pawns promote upon reaching the top, black pawns promote upon reaching the left.</li>
<li>No en passant, castling, or two-step-forward pawn jumps.</li>
<li>Chess pieces cannot move onto <em>or through</em> the 37 covered squares. Knights cannot move onto the 37 covered squares, but don't care what they move "through".</li>
</ul>
<p>The game is called 1.58 dimensional chess because the 27 open squares are chosen according to a pattern based on the <a href="https://en.wikipedia.org/wiki/Sierpi%C5%84ski_triangle">Sierpinski triangle</a>. You start off with a single open square, and then every time you double the width, you take the shape at the end of the previous step, and copy it to the top left, top right and bottom left corners, but leave the bottom right corner inaccessible. Whereas in a one-dimensional structure, doubling the width increases the space by 2x, and in a two-dimensional structure, doubling the width increases the space by 4x (4 = 2<sup>2</sup>), and in a three-dimensional structure, doubling the width increases the space by 8x (8 = 2<sup>3</sup>), here doubling the width increases the space by 3x (3 = 2<sup>1.58496</sup>), hence "1.58 dimensional" (see <a href="https://en.wikipedia.org/wiki/Hausdorff_dimension">Hausdorff dimension</a> for details).</p>
<p>The game is substantially simpler and more "tractable" than full-on chess, and it's an interesting exercise in showing how in <a href="https://en.wikipedia.org/wiki/Flatland">lower-dimensional spaces</a> defense becomes much easier than offense. Note that the relative value of different pieces may change here, and new kinds of endings become possible (eg. you can checkmate with just a bishop).</p>
<h3 id="dimensional-tic-tac-toe">3 dimensional tic tac toe</h3>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/tic4.png" /> <br><br>
</center>
<p>The goal here is to get 4 in a straight line, where the line can go in any direction, along an axis or diagonal, including between planes. For example in this configuration X wins:</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/tic4_2.png" /> <br><br>
</center>
<p>It's considerably harder than <a href="https://www.quora.com/Is-there-a-way-to-never-lose-at-Tic-Tac-Toe">traditional 2D tic tac toe</a>, and hopefully much more fun!</p>
<h3 id="modular-tic-tac-toe">Modular tic-tac-toe</h3>
<p>Here, we go back down to having two dimensions, except we allow lines to wrap around:</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/tic4_3.png" /> <br><small><i>X wins</i></small>
</center>
<p><br><br></p>
<p>Note that we allow diagonal lines with any slope, as long as they pass through all four points. Particularly, this means that lines with slope +/- 2 and +/- 1/2 are admissible:</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/tic4_4.png" /> <br><br>
</center>
<p>Mathematically, the board can be interpreted as a 2-dimensional vector space over <a href="https://en.wikipedia.org/wiki/Modular_arithmetic">integers modulo 4</a>, and the goal being to fill in a line that passes through four points over this space. Note that there exists at least one line passing through any two points.</p>
<h3 id="tic-tac-toe-over-the-4-element-binary-field">Tic tac toe over the 4-element binary field</h3>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/tic4_5.png" /> <br><br>
</center>
<p>Here, we have the same concept as above, except we use an even spookier mathematical structure, the <a href="https://en.wikipedia.org/wiki/Finite_field#Field_with_four_elements">4-element field</a> of polynomials over <span class="math inline">\(Z_2\)</span> modulo <span class="math inline">\(x^2 + x + 1\)</span>. This structure has pretty much no reasonable geometric interpretation, so I'll just give you the addition and multiplication tables:</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/tic4_6.png" /> <br><br>
</center>
<p>OK fine, here are all possible lines, excluding the horizontal and the vertical lines (which are also admissible) for brevity:</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/tic4_7.png" style="width: 450px" /> <br><br>
</center>
<p>The lack of geometric interpretation does make the game harder to play; you pretty much have to memorize the twenty winning combinations, though note that they are <em>basically</em> rotations and reflections of the same four basic shapes (axial line, diagonal line, diagonal line starting in the middle, that weird thing that doesn't look like a line).</p>
<h3 id="now-play-1.77-dimensional-connect-four.-i-dare-you.">Now play 1.77 dimensional connect four. I dare you.</h3>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/tic4_8.png" style="width: 450px" /> <br><br>
</center>
<h3 id="modular-poker">Modular poker</h3>
<p>Everyone is dealt five (you can use whatever variant poker rules you want here in terms of how these cards are dealt and whether or not players have the right to swap cards out). The cards are interpreted as: jack = 11, queen = 12, king = 0, ace = 1. A hand is stronger than another hand, if it contains a longer sequence, with any constant difference between consecutive cards (allowing wraparound), than the other hand.</p>
<p>Mathametically, this can be represented as, a hand is stronger if the player can come up with a line <span class="math inline">\(L(x) = mx+b\)</span> such that they have cards for the numbers <span class="math inline">\(L(0)\)</span>, <span class="math inline">\(L(1)\)</span> ... <span class="math inline">\(L(k)\)</span> for the highest <span class="math inline">\(k\)</span>.</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/cards1.png" /> <br><small><i>Example of a full five-card winning hand. y = 4x + 5.</i></small>
</center>
<p><br><br></p>
<p>To break ties between equal maximum-length sequences, count the number of distinct length-three sequences they have; the hand with more distinct length-three sequences wins.</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/cards2.png" /> <br><small><i>This hand has four length-three sequences: K 2 4, K 4 8, 2 3 4, 3 8 K. This is rare.</i></small>
</center>
<p><br><br></p>
<p>Only consider lines of length three or higher. If a hand has three or more of the same denomination, that counts as a sequence, but if a hand has two of the same denomination, any sequences passing through that denomination only count as one sequence.</p>
<center>
<br> <img src="http://vitalik.ca/files/posts_files/christmas-files/cards3.png" /> <br><small><i>This hand has no length-three sequences.</i></small>
</center>
<p><br><br></p>
<p>If two hands are completely tied, the hand with the higher highest card (using J = 11, Q = 12, K = 0, A = 1 as above) wins.</p>
<p>Enjoy!</p>
Tue, 24 Dec 2019 17:03:10 -0800
https://vitalik.ca/general/2019/12/24/christmas.html
https://vitalik.ca/general/2019/12/24/christmas.htmlgeneralQuadratic Payments: A Primer<p><em>Special thanks to Karl Floersch and Jinglan Wang for feedback</em></p>
<p>If you follow applied mechanism design or decentralized governance at all, you may have recently heard one of a few buzzwords: <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531">quadratic voting</a>, <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3243656">quadratic funding</a> and <a href="https://kortina.nyc/essays/speech-is-free-distribution-is-not-a-tax-on-the-purchase-of-human-attention-and-political-power/">quadratic attention purchase</a>. These ideas have been gaining popularity rapidly over the last few years, and small-scale tests have already been deployed: the <a href="https://presidential-hackathon.taiwan.gov.tw/en/">Taiwanese presidential hackathon</a> used quadratic voting to vote on winning projects, Gitcoin Grants <a href="https://vitalik.ca/general/2019/10/24/gitcoin.html">used quadratic funding</a> to fund public goods in the Ethereum ecosystem, and the Colorado Democratic party <a href="https://www.wired.com/story/colorado-quadratic-voting-experiment">also experimented with</a> quadratic voting to determine their party platform.</p>
<p>To the proponents of these voting schemes, this is not just another slight improvement to what exists. Rather, it's an initial foray into a fundamentally new class of social technology which, has the potential to overturn how we make many public decisions, large and small. The ultimate effect of these schemes rolled out in their full form <em>could be as deeply transformative as the industrial-era advent of mostly-free markets and constitutional democracy</em>. But now, you may be thinking: "These are large promises. What do these new governance technologies have that justifies such claims?"</p>
<h3 id="private-goods-private-markets...">Private goods, private markets...</h3>
<p>To understand what is going on, let us first consider an existing social technology: money, and property rights - the invisible social technology that generally hides behind money. Money and private property are extremely powerful social technologies, for all the reasons classical economists have been stating for over a hundred years. If Bob is producing apples, and Alice wants to buy apples, we can economically model the interaction between the two, and the results <em>seem to make sense</em>:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/Market1.png" />
</center>
<p><br><br></p>
<p>Alice keeps buying apples until the marginal value of the next apple to her is less than the cost of producing it, which is pretty much exactly the optimal thing that could happen. And if the cost of producing the apples is greater than their value to Alice, then Alice just doesn't buy any:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/Market2.png" />
</center>
<p><br><br></p>
<p>This is all formalized in results such as the "<a href="https://en.wikipedia.org/wiki/Fundamental_theorems_of_welfare_economics">fundamental theorems of welfare economics</a>". Now, those of you who have learned some economics may be screaming, but what about <a href="https://en.wikipedia.org/wiki/Imperfect_competition">imperfect competition</a>? <a href="https://en.wikipedia.org/wiki/Information_asymmetry">Asymmetric information</a>? <a href="https://en.wikipedia.org/wiki/Economic_inequality">Economic inequality</a>? <a href="https://en.wikipedia.org/wiki/Public_good">Public goods</a>? <a href="https://en.wikipedia.org/wiki/Externality">Externalities</a>? Many activities in the real world, including those that are key to the progress of human civilization, benefit (or harm) many people in complicated ways. These activities and the consequences that arise from them often cannot be neatly decomposed into sequences of distinct trades between two parties.</p>
<p>But since when do we expect a single package of technologies to solve every problem anyway? "What about oceans?" isn't an argument against <em>cars</em>, it's an argument against <em>car maximalism</em>, the position that we need cars and nothing else. Much like how private property and markets deal with private goods, can we try to use economic means to deduce what kind of social technologies would work well for encouraging production of the public goods that we need?</p>
<h3 id="public-goods-public-markets">... Public goods, public markets</h3>
<p>Private goods (eg. apples) and public goods (eg. public parks, air quality, scientific research, this article...) are different in some key ways. When we are talking about private goods, production for multiple people (eg. the same farmer makes apples for both Alice and Bob) can be decomposed into (i) the farmer making some apples for Alice, and (ii) the farmer making some other apples for Bob. If Alice wants apples but Bob does not, then the farmer makes Alice's apples, collects payment from Alice, and leaves Bob alone. Even complex collaborations (the <a href="https://fee.org/resources/i-pencil/">"I, Pencil" essay</a> popular in libertarian circles comes to mind) can be decomposed into a series of such interactions. When we are talking about public goods, however, <em>this kind of decomposition is not possible</em>. When I write this blog article, it can be read by both Alice and Bob (and everyone else). I <em>could</em> put it behind a paywall, but if it's popular enough it will inevitably get mirrored on third-party sites, and paywalls are in any case annoying and not very effective. Furthermore, making an article available to ten people is not ten times cheaper than making the article available to a hundred people; rather, <em>the cost is exactly the same</em>. So I either produce the article for everyone, or I do not produce it for anyone at all.</p>
<p>So here comes the challenge: how do we aggregate together people's preferences? Some private and public goods are worth producing, others are not. In the case of private goods, the question is easy, because we can just decompose it into a series of decisions for each individual. Whatever amount each person is willing to pay for, that much gets produced for them; the economics is not especially complex. In the case of public goods, however, you cannot "decompose", and so we need to add up people's preferences in a different way.</p>
<p>First of all, let's see what happens if we just put up a plain old regular market: I offer to write an article as long as at least $1000 of money gets donated to me (fun fact: <a href="https://bitcointalk.org/index.php?topic=28681.msg360909#msg360909">I literally did this back in 2011</a>). Every dollar donated increases the probability that the goal will be reached and the article will be published; let us call this "marginal probability" <code>p</code>. At a cost of $<code>k</code>, you can increase the probability that the article will be published by <code>k * p</code> (though eventually the gains will decrease as the probability approaches 100%). Let's say to you personally, the article being published is worth $<code>V</code>. Would you donate? Well, donating a dollar increases the probability it will be published by <code>p</code>, and so gives you an expected $<code>p * V</code> of value. If <code>p * V > 1</code>, you donate, and quite a lot, and if <code>p * V < 1</code> you don't donate at all.</p>
<p>Phrased less mathematically, either you value the article enough (and/or are rich enough) to pay, and if that's the case it's in your interest to keep paying (and influencing) quite a lot, or you don't value the article enough and you contribute nothing. Hence, the only blog articles that get published would be articles where some single person is willing to <a href="https://en.wikipedia.org/wiki/Patronage">basically pay for it themselves</a> (in my experiment in 2011, this prediction was experimentally verified: in <a href="https://bitcointalk.org/index.php?topic=23934.msg306437#msg306437">most</a> <a href="https://bitcointalk.org/index.php?topic=28681.msg360909#msg360909">rounds</a>, over half of the total contribution came from a single donor).</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/Market8.png" />
</center>
<p><br><br></p>
<p>Note that <em>this reasoning applies for any kind of mechanism that involves "buying influence" over matters of public concern</em>. This includes paying for public goods, shareholder voting in corporations, public advertising, bribing politicians, and much more. The little guy has too little influence (not quite zero, because in the real world things like altruism exist) and the big guy has too much. If you had an intuition that markets work great for buying apples, but money is corrupting in "the public sphere", this is basically a simplified mathematical model that shows why.</p>
<p>We can also consider a different mechanism: one-person-one-vote. Let's say you can either vote that I deserve a reward for writing this article, or you can vote that I don't, and my reward is proportional to the number of votes in my favor. We can interpret this as follows: your first "contribution" costs only a small amount of effort, so you'll support an article if you care about it enough, but after that point there is no more room to contribute further; your second contribution "costs" infinity.</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/Market9.png" />
</center>
<p><br><br></p>
<p>Now, you might notice that neither of the graphs above look quite right. The first graph over-privileges people who <em>care a lot</em> (or are wealthy), the second graph over-privileges people who <em>care only a little</em>, which is also a problem. The single sheep's desire to live is more important than the two wolves' desire to have a tasty dinner.</p>
<p>But what do we actually want? Ultimately, we want a scheme where <em>how much influence you "buy" is proportional to how much you care</em>. In the mathematical lingo above, we want your <code>k</code> to be proportional to your <code>V</code>. But here's the problem: your <code>V</code> determines how much you're willing to pay for <em>one</em> unit of influence. If Alice were willing to pay $100 for the article if she had to fund it herself, then she would be willing to pay $1 for an increased 1% chance it will get written, and if Bob were only willing to pay $50 for the article then he would only be willing to pay $0.5 for the same "unit of influence".</p>
<p>So how do we match these two up? The answer is clever: <em>your n'th unit of influence costs you $n</em> . That is, for example, you could buy your first vote for $0.01, but then your second would cost $0.02, your third $0.03, and so forth. Suppose you were Alice in the example above; in such a system she would keep buying units of influence until the cost of the next one got to $1, so she would buy 100 units. Bob would similarly buy until the cost got to $0.5, so he would buy 50 units. Alice's 2x higher valuation turned into 2x more units of influence purchased.</p>
<p>Let's draw this as a graph:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/Market10.png" />
</center>
<p><br><br></p>
<p>Now let's look at all three beside each other:</p>
<center>
<table>
<tr>
<td>
One dollar one vote
</td>
<td>
Quadratic voting
</td>
<td>
One person one vote
</td>
</tr>
<tr>
<td>
<img src="https://vitalik.ca/files/posts_files/qv-files/Market8.png" />
</td>
<td>
<img src="https://vitalik.ca/files/posts_files/qv-files/Market10.png" />
</td>
<td>
<img src="https://vitalik.ca/files/posts_files/qv-files/Market9.png" />
</td>
</tr>
</table>
</center>
<p><br><br></p>
<p>Notice that only quadratic voting has this nice property that the amount of influence you purchase is proportional to how much you care; the other two mechanisms either over-privilege concentrated interests or over-privilege diffuse interests.</p>
<p>Now, you might ask, where does the <em>quadratic</em> come from? Well, the <em>marginal</em> cost of the n'th vote is $n (or $0.01 * n), but the <em>total</em> cost of n votes is <span class="math inline">\(\approx \frac{n^2}{2}\)</span>. You can view this geometrically as follows:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/qv_triangle.png" />
</center>
<p><br><br></p>
<p>The total cost is the area of a triangle, and you probably learned in math class that area is base * height / 2. And since here base and height are proportionate, that basically means that total cost is proportional to number of votes squared - hence, "quadratic". But honestly it's easier to think "your n'th unit of influence costs $n".</p>
<p>Finally, you might notice that above I've been vague about what "one unit of influence" actually means. This is deliberate; it can mean different things in different contexts, and the different "flavors" of quadratic payments reflect these different perspectives.</p>
<h3 id="quadratic-voting">Quadratic Voting</h3>
<p><em>See also the original paper: <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531">https://papers.ssrn.com/sol3/papers.cfm?abstract%5fid=2003531</a></em></p>
<p>Let us begin by exploring the first "flavor" of quadratic payments: quadratic voting. Imagine that some organization is trying to choose between two choices for some decision that affects all of its members. For example, this could be a company or a nonprofit deciding which part of town to make a new office in, or a government deciding whether or not to implement some policy, or an internet forum deciding whether or not its rules should allow discussion of cryptocurrency prices. Within the context of the organization, the choice made is a public good (or public bad, depending on whom you talk to): everyone "consumes" the results of the same decision, they just have different opinions about how much they like the result.</p>
<p>This seems like a perfect target for quadratic voting. The goal is that option A gets chosen if in total people like A more, and option B gets chosen if in total people like B more. With simple voting ("one person one vote"), the distinction between stronger vs weaker preferences gets ignored, so on issues where one side is of very high value to a few people and the other side is of low value to more people, simple voting is likely to give wrong answers. With a private-goods market mechanism where people can buy as many votes as they want at the same price per vote, the individual with the strongest preference (or the wealthiest) carries everything. Quadratic voting, where you can make n votes in either direction at a cost of n<sup>2</sup>, is right in the middle between these two extremes, and creates the perfect balance.</p>
<br>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/Market7.png?2e" /><br><i><small>Note that in the voting case, we're deciding two options, so different people will favor A over B or B over A; hence, unlike the graphs we saw earlier that start from zero, here voting and preference can both be positive or negative (which option is considered positive and which is negative doesn't matter; the math works out the same way)</small></i>
</center>
<p><br><br></p>
<p>As shown above, because the n'th vote has a cost of <code>n</code>, the number of votes you make is proportional to how much you value one unit of influence over the decision (the value of the decision multiplied by the probability that one vote will tip the result), and hence proportional to how much you care about A being chosen over B or vice versa. Hence, we once again have this nice clean "preference adding" effect.</p>
<p>We can extend quadratic voting in multiple ways. First, we can allow voting between more than two options. While traditional voting schemes inevitably fall prey to various kinds of "strategic voting" issues because of <a href="https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem">Arrow's theorem</a> and <a href="https://en.wikipedia.org/wiki/Duverger%27s_law">Duverger's law</a>, quadratic voting <a href="http://www.econ.msu.edu/seminars/docs/QuadMultAltshort19.pdf">continues to be optimal</a> in contexts with more than two choices.</p>
<blockquote>
<p><strong>The intuitive argument for those interested</strong>: suppose there are established candidates A and B and new candidate C. Some people favor C > A > B but others C > B > A. in a regular vote, if both sides think C stands no chance, they decide may as well vote their preference between A and B, so C gets no votes, and C's failure becomes a self-fulfilling prophecy. In quadratic voting the former group would vote [A +10, B -10, C +1] and the latter [A -10, B +10, C +1], so the A and B votes cancel out and C's popularity shines through.</p>
</blockquote>
<p>Second, we can look not just at voting between discrete options, but also at voting on the setting of a thermostat: anyone can push the thermostat up or down by 0.01 degrees n times by paying a cost of n<sup>2</sup>.</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/tug_of_war.png" /><br><small><i>Plot twist: the side wanting it colder only wins when they convince the other side that "C" stands for "caliente".</i></small>
</center>
<p><br><br></p>
<h3 id="quadratic-funding">Quadratic funding</h3>
<p><em>See also the original paper: <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3243656">https://papers.ssrn.com/sol3/papers.cfm?abstract%5fid=3243656</a></em></p>
<p>Quadratic voting is optimal when you need to make some fixed number of collective decisions. But one weakness of quadratic voting is that it doesn't come with a built-in mechanism for deciding what goes on the ballot in the first place. Proposing votes is potentially a source of considerable power if not handled with care: a malicious actor in control of it can repeatedly propose some decision that a majority weakly approves of and a minority strongly disapproves of, and keep proposing it until the minority runs out of voting tokens (if you do the math you'll see that the minority would burn through tokens much faster than the majority). Let's consider a flavor of quadratic payments that does not run into this issue, and makes the choice of decisions itself endogenous (ie. part of the mechanism itself). In this case, the mechanism is specialized for one particular use case: individual provision of public goods.</p>
<p>Let us consider an example where someone is looking to produce a public good (eg. a developer writing an open source software program), and we want to figure out whether or not this program is worth funding. But instead of just thinking about one single public good, let's create a mechanism where <em>anyone</em> can raise funds for what they claim to be a public good project. Anyone can make a contribution to any project; a mechanism keeps track of these contributions and then at the end of some period of time the mechanism calculates a payment to each project. The way that this payment is calculated is as follows: for any given project, take the square root of each contributor's contribution, add these values together, and take the square of the result. Or in math speak:</p>
<p><span class="math display">\[(\sum_{i=1}^n \sqrt{c_i})^2\]</span></p>
<p>If that sounds complicated, here it is graphically:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/quadratic_funding.png" />
</center>
<p><br><br></p>
<p>In any case where there is more than one contributor, the computed payment is greater than the raw sum of contributions; the difference comes out of a central subsidy pool (eg. if ten people each donate $1, then the sum-of-square-roots is $10, and the square of that is $100, so the subsidy is $90). Note that if the subsidy pool is not big enough to make the full required payment to every project, we can just divide the subsidies proportionately by whatever constant makes the totals add up to the subsidy pool's budget; <strong>you can prove that this solves the tragedy-of-the-commons problem as well as you can with that subsidy budget</strong>.</p>
<p>There are two ways to intuitively interpret this formula. First, one can look at it through the "fixing market failure" lens, a surgical fix to the <a href="https://en.wikipedia.org/wiki/Tragedy_of_the_commons">tragedy of the commons</a> problem. In any situation where Alice contributes to a project and Bob also contributes to that same project, Alice is making a contribution to something that is valuable not only to herself, but also to Bob. When deciding <em>how much to contribute</em>, Alice was only taking into account the benefit to herself, not Bob, whom she most likely does not even know. The quadratic funding mechanism adds a subsidy to compensate for this effect, determining how much Alice "would have" contributed if she also took into account the benefit her contribution brings to Bob. Furthermore, we can separately calculate the subsidy for each pair of people (nb. if there are <code>N</code> people there are <code>N * (N-1) / 2</code> pairs), and add up all of these subsidies together, and give Bob the combined subsidy from all pairs. And it turns out that this gives exactly the quadratic funding formula.</p>
<p>Second, one can look at the formula through a quadratic voting lens. We interpret the quadratic funding as being <em>a special case</em> of quadratic voting, where the contributors to a project are voting for that project and there is one imaginary participant voting against it: the subsidy pool. Every "project" is a motion to take money from the subsidy pool and give it to that project's creator. Everyone sending <span class="math inline">\(c_i\)</span> of funds is making <span class="math inline">\(\sqrt{c_i}\)</span> votes, so there's a total of <span class="math inline">\(\sum_{i=1}^n \sqrt{c_i}\)</span> votes in favor of the motion. To kill the motion, the subsidy pool would need to make more than <span class="math inline">\(\sum_{i=1}^n \sqrt{c_i}\)</span> votes against it, which would cost it more than <span class="math inline">\((\sum_{i=1}^n \sqrt{c_i})^2\)</span>. Hence, <span class="math inline">\((\sum_{i=1}^n \sqrt{c_i})^2\)</span> is the maximum transfer from the subsidy pool to the project that the subsidy pool would not vote to stop.</p>
<p>Quadratic funding is starting to be explored as a mechanism for funding public goods already; <a href="https://vitalik.ca/general/2019/10/24/gitcoin.html">Gitcoin grants</a> for funding public goods in the Ethereum ecosystem is currently the biggest example, and the most recent round led to results that, in my own view, did a quite good job of making a fair allocation to support projects that the community deems valuable.</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/round3.png" /><br><small><i>Numbers in white are raw contribution totals; numbers in green are the extra subsidies.</i></small>
</center>
<p><br><br></p>
<h3 id="quadratic-attention-payments">Quadratic attention payments</h3>
<p><em>See also the original post: <a href="https://kortina.nyc/essays/speech-is-free-distribution-is-not-a-tax-on-the-purchase-of-human-attention-and-political-power/" class="uri">https://kortina.nyc/essays/speech-is-free-distribution-is-not-a-tax-on-the-purchase-of-human-attention-and-political-power/</a></em></p>
<p>One of the defining features of modern capitalism that people love to hate is ads. Our cities have ads:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/ads1.jpg" style="height:300px" /><br><small><i>Source: <a href="https://www.flickr.com/photos/argonavigo/36657795264">https://www.flickr.com/photos/argonavigo/36657795264</a></i></small>
</center>
<p><br><br></p>
<p>Our subway turnstiles have ads:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/ads2.jpg" style="height:300px" /><br><small><i>Source: <a href="https://commons.wikimedia.org/wiki/File:NYC,_subway_ad_on_Prince_St.jpg">https://commons.wikimedia.org/wiki/File:NYC,_subway_ad_on_Prince_St.jpg</a></i></small>
</center>
<p><br><br></p>
<p>Our politics are dominated by ads:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/ads3.jpg" style="height:300px" /><br><small><i>Source: <a href="https://upload.wikimedia.org/wikipedia/commons/e/e3/Billboard_Challenging_the_validity_of_Barack_Obama%27s_Birth_Certificate.JPG">https://upload.wikimedia.org/wikipedia/commons/e/e3/Billboard_Challenging_the_validity_of_Barack_Obama%27s_Birth_Certificate.JPG</a></i></small>
</center>
<p><br><br></p>
<p>And even the rivers and the skies <a href="https://newyork.cbslocal.com/2018/11/13/are-led-boat-advertisements-on-the-hudson-river-going-a-step-too-far/">have ads</a>. Now, there are some places that seem to not have this problem:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/ads4.png" style="height:450px" /><br><br>
</center>
<p>But really they just have a different kind of ads:</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/ads5.jpg" style="height:300px" /><br><br>
</center>
<p>Now, recently there are attempts to move beyond this <a href="https://www.theguardian.com/cities/2015/aug/11/can-cities-kick-ads-ban-urban-billboards">in some cities</a>. And <a href="https://twitter.com/jack/status/1189634360472829952">on Twitter</a>. But let's look at the problem systematically and try to see what's going wrong. The answer is actually surprisingly simple: public advertising is the evil twin of public goods production. In the case of public goods production, there is one actor that is taking on an expenditure to produce some product, and this product benefits a large number of people. Because these people cannot effectively coordinate to pay for the public goods by themselves, we get much less public goods than we need, and the ones we do get are those favored by wealthy actors or centralized authorities. Here, there is one actor that reaps a large <em>benefit</em> from forcing other people to look at some image, and this action <em>harms</em> a large number of people. Because these people cannot effectively coordinate to buy out the slots for the ads, we get ads we don't want to see, that are favored by... wealthy actors or centralized authorities.</p>
<p>So how do we solve this dark mirror image of public goods production? With a bright mirror image of quadratic funding: quadratic fees! Imagine a billboard where anyone can pay $1 to put up an ad for one minute, but if they want to do this multiple times the prices go up: $2 for the second minute, $3 for the third minute, etc. Note that you can pay to extend the lifetime of <em>someone else's</em> ad on the billboard, and this also costs you only $1 for the first minute, <em>even if other people already paid to extend the ad's lifetime many times</em>. We can once again interpret this as being a special case of quadratic voting: it's basically the same as the "voting on a thermostat" example above, but where the thermostat in question is the number of seconds an ad stays up.</p>
<p>This kind of payment model could be applied in cities, on websites, at conferences, or in many other contexts, if the goal is to optimize for putting up things that people want to see (or things that people want other people to see, but even here it's much more democratic than simply buying space) rather than things that wealthy people and centralized institutions want people to see.</p>
<h3 id="complexities-and-caveats">Complexities and caveats</h3>
<p>Perhaps the biggest challenge to consider with this concept of quadratic payments is the practical implementation issue of <a href="https://vitalik.ca/general/2019/04/03/collusion.html">identity and bribery/collusion</a>. Quadratic payments in any form require a model of identity where individuals cannot easily get as many identities as they want: if they could, then they could just keep getting new identities and keep paying $1 to influence some decision as many times as they want, and the mechanism collapses into linear vote-buying. Note that the identity system does <em>not</em> need to be airtight (in the sense of preventing multiple-identity acquisition), and indeed there are good civil-liberties reasons why identity systems probably should <em>not</em> try to be airtight. Rather, it just needs to be robust enough that manipulation is not worth the cost.</p>
<p>Collusion is also tricky. If we canâ€™t prevent people from selling their votes, the mechanisms once again collapse into one-dollar-one-vote. We don't just need votes to be anonymous and private (while still making the final result provable and public); <strong>we need votes to be so private that even the person who made the vote can't prove to anyone else what they voted for</strong>. This is difficult. Secret ballots do this well in the offline world, but secret ballots are a nineteenth century technology, far too inefficient for the sheer amount of quadratic voting and funding that we want to see in the twenty first century.</p>
<p>Fortunately, there are <a href="https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413">technological means that can help</a>, combining together zero-knowledge proofs, encryption and other cryptographic technologies to achieve the precise desired set of privacy and verifiability properties. There's also <a href="https://twitter.com/phildaian/status/1181822995993681921">proposed techniques</a> to verify that private keys actually are in an individual's possession and not in some hardware or cryptographic system that can restrict how they use those keys. However, these techniques are all untested and require quite a bit of further work.</p>
<p>Another challenge is that quadratic payments, being a payment-based mechanism, continues to favor people with more money. Note that because the cost of votes is quadratic, this effect is dampened: someone with 100 times more money only has 10 times more influence, not 100 times, so the extent of the problem goes down by 90% (and even more for ultra-wealthy actors). That said, it may be desirable to mitigate this inequality of power further. This could be done either by denominating quadratic payments in a separate token of which everyone gets a fixed number of units, or giving each person an allocation of funds that can only be used for quadratic-payments use cases: this is basically <a href="https://www.yang2020.com/policies/democracydollars/">Andrew Yang's "democracy dollars"</a> proposal.</p>
<center>
<img src="https://vitalik.ca/files/posts_files/qv-files/Oprah.png" style="height:300px" /><br>
</center>
<p>A third challenge is the "<a href="https://en.wikipedia.org/wiki/Rational_ignorance">rational ignorance</a>" and "<a href="https://en.wikipedia.org/wiki/Rational_irrationality">rational irrationality</a>" problems, which is that decentralized public decisions have the weakness that any single individual has very little effect on the outcome, and so little motivation to make sure they are supporting the decision that is best for the long term; instead, pressures such as tribal affiliation may dominate. There are many strands of philosophy that emphasize the ability of large crowds to be very wrong despite (or because of!) their size, and quadratic payments in any form do little to address this.</p>
<p>Quadratic payments do better at mitigating this problem than one-person-one-vote systems, and these problems can be expected to be less severe for medium-scale public goods than for large decisions that affect many millions of people, so it may not be a large challenge at first, but it's certainly an issue worth confronting. One approach is <a href="https://ethresear.ch/t/quadratic-voting-with-sortition/6065">combining quadratic voting with elements of sortition</a>. Another, potentially more long-term durable, approach is to combine quadratic voting with another economic technology that is much more specifically targeted toward rewarding the "correct contrarianism" that can dispel mass delusions: <a href="https://en.wikipedia.org/wiki/Prediction_market">prediction markets</a>. A simple example would be a system where quadratic funding is done <em>retrospectively</em>, so people vote on which public goods were valuable some time ago (eg. even 2 years), and projects are funded up-front by selling shares of the results of these deferred votes; by buying shares people would be both funding the projects and betting on which project would be viewed as successful in 2 years' time. There is a large design space to experiment with here.</p>
<h3 id="conclusion">Conclusion</h3>
<p>As I mentioned at the beginning, quadratic payments do not solve every problem. They solve the problem of governing resources that affect large numbers of people, but they do not solve many other kinds of problems. A particularly important one is information asymmetry and low quality of information in general. For this reason, I am a fan of techniques such as prediction markets (see <a href="https://electionbettingodds.com/">electionbettingodds.com</a> for one example) to solve information-gathering problems, and many applications can be made most effective by combining different mechanisms together.</p>
<p>One particular cause dear to me personally is what I call "entrepreneurial public goods": public goods that in the present only a few people believe are important but in the future many more people will value. In the 19th century, contributing to abolition of slavery may have been one example; in the 21st century I can't give examples that will satisfy every reader because it's the nature of these goods that their importance will only become common knowledge later down the road, but I would point to <a href="https://www.sens.org/">life extension</a> and <a href="https://intelligence.org/">AI risk research</a> as two possible examples.</p>
<p>That said, we don't need to solve every problem today. Quadratic payments are an idea that has only become popular in the last few years; we still have not seen more than small-scale trials of quadratic voting and funding, and quadratic attention payments have not been tried at all! There is still a long way to go. But if we can get these mechanisms off the ground, there is a lot that these mechanisms have to offer!</p>
Sat, 07 Dec 2019 17:03:10 -0800
https://vitalik.ca/general/2019/12/07/quadratic.html
https://vitalik.ca/general/2019/12/07/quadratic.htmlgeneralHard Problems in Cryptocurrency: Five Years Later<p><em>Special thanks to Justin Drake and Jinglan Wang for feedback</em></p>
<p>In 2014, I made a <a href="https://github.com/ethereum/wiki/wiki/Problems/89fd07ffff8b042134e4ca67a0ce143d574016bd">post</a> and a <a href="https://www.youtube.com/watch?v=rXRtJcNVfQE">presentation</a> with a list of hard problems in math, computer science and economics that I thought were important for the cryptocurrency space (as I then called it) to be able to reach maturity. In the last five years, much has changed. But exactly how much progress on what we thought then was important has been achieved? Where have we succeeded, where have we failed, and where have we changed our minds about what is important? In this post, I'll go through the 16 problems from 2014 one by one, and see just where we are today on each one. At the end, Iâ€™ll include my new picks for hard problems of 2019.</p>
<p>The problems are broken down into three categories: (i) cryptographic, and hence expected to be solvable with purely mathematical techniques if they are to be solvable at all, (ii) consensus theory, largely improvements to proof of work and proof of stake, and (iii) economic, and hence having to do with creating structures involving incentives given to different participants, and often involving the application layer more than the protocol layer. We see significant progress in all categories, though some more than others.</p>
<h2 id="cryptographic-problems">Cryptographic problems</h2>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol type="1">
<li>Blockchain Scalability
</h3>
One of the largest problems facing the cryptocurrency space today is the issue of scalability ... The main concern with [oversized blockchains] is trust: if there are only a few entities capable of running full nodes, then those entities can conspire and agree to give themselves a large number of additional bitcoins, and there would be no way for other users to see for themselves that a block is invalid without processing an entire block themselves.<br />
<strong>Problem:</strong> create a blockchain design that maintains Bitcoin-like security guarantees, but where the maximum size of the most powerful node that needs to exist for the network to keep functioning is substantially sublinear in the number of transactions.
</blockquote></li>
</ol>
<p>Status: <strong>Great theoretical progress, pending more real-world evaluation</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face7.png" style="width:50px; height: 50px" /></p>
<p>Scalability is one technical problem that we have had a huge amount of progress on theoretically. Five years ago, almost no one was thinking about sharding; now, sharding designs are commonplace. Aside from <a href="https://github.com/ethereum/eth2.0-specs">ethereum 2.0</a>, we have <a href="https://eprint.iacr.org/2017/406.pdf">OmniLedger</a>, <a href="https://arxiv.org/abs/1905.09274">LazyLedger</a>, <a href="https://medium.com/@giottodf/zilliqa-a-novel-approach-to-sharding-d79249347a1f">Zilliqa</a> and research papers <a href="https://arxiv.org/pdf/1910.10434.pdf">seemingly coming out every month</a>. In my own view, further progress at this point is incremental. Fundamentally, we already have a number of techniques that allow groups of validators to securely come to consensus on much more data than an individual validator can process, as well as techniques allow clients to indirectly verify the full validity and availability of blocks even under 51% attack conditions.</p>
<p>These are probably the most important technologies:</p>
<ul>
<li><strong>Random sampling</strong>, allowing a small randomly selected committee to statistically stand in for the full validator set: <a href="https://github.com/ethereum/wiki/wiki/Sharding-FAQ#how-can-we-solve-the-single-shard-takeover-attack-in-an-uncoordinated-majority-model" class="uri">https://github.com/ethereum/wiki/wiki/Sharding-FAQ#how-can-we-solve-the-single-shard-takeover-attack-in-an-uncoordinated-majority-model</a></li>
<li><strong>Fraud proofs</strong>, allowing individual nodes that learn of an error to broadcast its presence to everyone else: <a href="https://bitcoin.stackexchange.com/questions/49647/what-is-a-fraud-proof" class="uri">https://bitcoin.stackexchange.com/questions/49647/what-is-a-fraud-proof</a></li>
<li><strong>Proofs of custody</strong>, allowing validators to probabilistically prove that they individually downloaded and verified some piece of data: <a href="https://ethresear.ch/t/1-bit-aggregation-friendly-custody-bonds/2236" class="uri">https://ethresear.ch/t/1-bit-aggregation-friendly-custody-bonds/2236</a></li>
<li><strong>Data availability proofs</strong>, allowing clients to detect when the bodies of blocks that they have headers for <a href="https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding">are unavailable</a>: <a href="https://arxiv.org/abs/1809.09044" class="uri">https://arxiv.org/abs/1809.09044</a>. See also the newer <a href="https://arxiv.org/abs/1910.01247">coded Merkle trees</a> proposal.</li>
</ul>
<p>There are also other smaller developments like <a href="https://github.com/ethereum/wiki/wiki/Sharding-FAQ#how-can-we-facilitate-cross-shard-communication">Cross-shard communication via receipts</a> as well as "constant-factor" enhancements such as BLS signature aggregation.</p>
<p>That said, fully sharded blockchains have still not been seen in live operation (the partially sharded Zilliqa has recently started running). On the theoretical side, there are mainly disputes about details remaining, along with challenges having to do with stability of sharded networking, developer experience and mitigating risks of centralization; fundamental technical possibility no longer seems in doubt. But the challenges that <em>do</em> remain are challenges that cannot be solved by just thinking about them; only developing the system and seeing ethereum 2.0 or some similar chain running live will suffice.</p>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="2" type="1">
<li>Timestamping
</h3>
<strong>Problem:</strong> create a distributed incentive-compatible system, whether it is an overlay on top of a blockchain or its own blockchain, which maintains the current time to high accuracy. All legitimate users have clocks in a normal distribution around some "real" time with standard deviation 20 seconds ... no two nodes are more than 20 seconds apart The solution is allowed to rely on an existing concept of "N nodes"; this would in practice be enforced with proof-of-stake or non-sybil tokens (see #9). The system should continuously provide a time which is within 120s (or less if possible) of the internal clock of >99% of honestly participating nodes. External systems may end up relying on this system; hence, it should remain secure against attackers controlling < 25% of nodes regardless of incentives.
</blockquote></li>
</ol>
<p>Status: <strong>Some progress</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face2.png" style="width:50px; height: 50px" /></p>
<p>Ethereum has actually survived just fine with a 13-second block time and no particularly advanced timestamping technology; it uses a simple technique where a client does not accept a block whose stated timestamp is earlier than the client's local time. That said, this has not been tested under serious attacks. The recent <a href="https://ethresear.ch/t/network-adjusted-timestamps/4187">network-adjusted timestamps</a> proposal tries to improve on the status quo by allowing the client to determine the consensus on the time in the case where the client does not locally know the current time to high accuracy; this has not yet been tested. But in general, timestamping is not currently at the foreground of perceived research challenges; perhaps this will change once more proof of stake chains (including Ethereum 2.0 but also others) come online as real live systems and we see what the issues are.</p>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="3" type="1">
<li>Arbitrary Proof of Computation
</h3>
<strong>Problem:</strong> create programs <code>POC_PROVE(P,I) -> (O,Q)</code> and <code>POC_VERIFY(P,O,Q) -> { 0, 1 }</code> such that <code>POC_PROVE</code> runs program <code>P</code> on input <code>I</code> and returns the program output <code>O</code> and a proof-of-computation <code>Q</code> and POC_VERIFY takes <code>P</code>, <code>O</code> and <code>Q</code> and outputs whether or not <code>Q</code> and <code>O</code> were legitimately produced by the <code>POC_PROVE</code> algorithm using <code>P</code>.
</blockquote></li>
</ol>
<p>Status: <strong>Great theoretical and practical progress</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face1.png" style="width:50px; height: 50px" /></p>
<p>This is basically saying, build a SNARK (or STARK, or SHARK, or...). And <a href="https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6">we've</a> <a href="https://vitalik.ca/general/2018/07/21/starks_part_3.html">done</a> <a href="https://vitalik.ca/general/2019/09/22/plonk.html">it</a>! SNARKs are now increasingly well understood, and are even already being used in multiple blockchains today (including <a href="https://tornado.cash/">tornado.cash</a> on Ethereum). And SNARKs are extremely useful, both as a privacy technology (see Zcash and tornado.cash) and as a scalability technology (see <a href="https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477">ZK Rollup</a>, <a href="https://www.starkdex.io/">STARKDEX</a> and <a href="https://ethresear.ch/t/stark-proving-low-degree-ness-of-a-data-availability-root-some-analysis/6214">STARKing erasure coded data roots</a>).</p>
<p>There are still challenges with efficiency; making arithmetization-friendly hash functions (see <a href="https://starkware.co/hash-challenge/">here</a> and <a href="https://mimchash.org/">here</a> for bounties for breaking proposed candidates) is a big one, and efficiently proving random memory accesses is another. Furthermore, there's the unsolved question of whether the O(n * log(n)) blowup in prover time is a fundamental limitation or if there is some way to make a succinct proof with only linear overhead as in <a href="https://web.stanford.edu/~buenz/pubs/bulletproofs.pdf">bulletproofs</a> (which unfortunately take linear time to verify). There are also ever-present risks that the existing schemes have bugs. In general, the problems are in the details rather than the fundamentals.</p>
<p><a name="numberfour"></a></p>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="4" type="1">
<li>Code Obfuscation
</h3>
The holy grail is to create an obfuscator O, such that given any program P the obfuscator can produce a second program O(P) = Q such that P and Q return the same output if given the same input and, importantly, Q reveals no information whatsoever about the internals of P. One can hide inside of Q a password, a secret encryption key, or one can simply use Q to hide the proprietary workings of the algorithm itself.
</blockquote></li>
</ol>
<p>Status: <strong>Slow progress</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face3.png" style="width:50px; height: 50px" /></p>
<p>In plain English, the problem is saying that we want to come up with a way to "encrypt" a program so that the encrypted program would still give the same outputs for the same inputs, but the "internals" of the program would be hidden. An example use case for obfuscation is a program containing a private key where the program only allows the private key to sign certain messages.</p>
<p>A solution to code obfuscation would be very useful to blockchain protocols. The use cases are subtle, because one must deal with the possibility that an on-chain obfuscated program will be copied and run in an environment different from the chain itself, but there are many possibilities. One that personally interests me is the ability to remove the centralized operator from <a href="https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413">collusion-resistance gadgets</a> by replacing the operator with an obfuscated program that contains some proof of work, making it very expensive to run more than once with different inputs as part of an attempt to determine individual participants' actions.</p>
<p>Unfortunately this continues to be a hard problem. There is continuing ongoing work in attacking the problem, one side making constructions (eg. <a href="https://eprint.iacr.org/2018/615">this</a>) that try to reduce the number of assumptions on mathematical objects that we do not know practically exist (eg. general cryptographic multilinear maps) and another side trying to make practical implementations of the desired mathematical objects. However, all of these paths are still quite far from creating something viable and known to be secure. See <a href="https://eprint.iacr.org/2019/463.pdf" class="uri">https://eprint.iacr.org/2019/463.pdf</a> for a more general overview to the problem.</p>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="5" type="1">
<li>Hash-Based Cryptography
</h3>
<strong>Problem:</strong> create a signature algorithm relying on no security assumption but the random oracle property of hashes that maintains 160 bits of security against classical computers (ie. 80 vs. quantum due to Grover's algorithm) with optimal size and other properties.
</blockquote></li>
</ol>
<p>Status: <strong>Some progress</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face2.png" style="width:50px; height: 50px" /></p>
<p>There have been two strands of progress on this since 2014. <a href="https://cryptojedi.org/papers/sphincs-20141001.pdf">SPHINCS</a>, a "stateless" (meaning, using it multiple times does not require remembering information like a nonce) signature scheme, was released soon after this "hard problems" list was published, and provides a purely hash-based signature scheme of size around 41 kB. Additionally, <a href="https://vitalik.ca/general/2018/07/21/starks_part_3.html">STARKs</a> have been developed, and one can create signatures of similar size based on them. The fact that not just signatures, but also general-purpose zero knowledge proofs, are possible with just hashes was definitely something I did not expect five years ago; I am very happy that this is the case. That said, size continues to be an issue, and ongoing progress (eg. see the very recent <a href="https://arxiv.org/abs/1903.12243">DEEP FRI</a>) is continuing to reduce the size of proofs, though it looks like further progress will be incremental.</p>
<p>The main not-yet-solved problem with hash-based cryptography is aggregate signatures, similar to what <a href="https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105">BLS aggregation</a> makes possible. It's known that we can just make a STARK over many Lamport signatures, but this is inefficient; a more efficient scheme would be welcome. (In case you're wondering if hash-based <em>public key encryption</em> is possible, the answer is, no, you can't do anything with <a href="https://www.boazbarak.org/Papers/merkle.pdf">more than a quadratic attack cost</a>)</p>
<h2 id="consensus-theory-problems">Consensus theory problems</h2>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="6" type="1">
<li>ASIC-Resistant Proof of Work
</h3>
One approach at solving the problem is creating a proof-of-work algorithm based on a type of computation that is very difficult to specialize ... For a more in-depth discussion on ASIC-resistant hardware, see <a href="https://blog.ethereum.org/2014/06/19/mining/" class="uri">https://blog.ethereum.org/2014/06/19/mining/</a>.
</blockquote></li>
</ol>
<p>Status: <strong>Solved as far as we can</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face4.png" style="width:50px; height: 50px" /></p>
<p>About six months after the "hard problems" list was posted, Ethereum settled on its ASIC-resistant proof of work algorithm: <a href="https://github.com/ethereum/wiki/wiki/Ethash">Ethash</a>. Ethash is known as a memory-hard algorithm. The theory is that random-access memory in regular computers is well-optimized already and hence difficult to improve on for specialized applications. Ethash aims to achieve ASIC resistance by making memory access the dominant part of running the PoW computation. Ethash was not the first memory-hard algorithm, but it did add one innovation: it uses pseudorandom lookups over a two-level DAG, allowing for two ways of evaluating the function. First, one could compute it quickly if one has the entire (~2 GB) DAG; this is the memory-hard "fast path". Second, one can compute it much more slowly (still fast enough to check a single provided solution quickly) if one only has the top level of the DAG; this is used for block verification.</p>
<p>Ethash has proven remarkably successful at ASIC resistance; after three years and billions of dollars of block rewards, ASICs do exist but are at best <a href="https://blog.miningstore.com/blog/ethereum-mining-hardware-for-2019">2-5 times more power and cost-efficient</a> than GPUs. <a href="https://github.com/ifdefelse/ProgPOW">ProgPoW</a> has been proposed as an alternative, but there is a growing consensus that ASIC-resistant algorithms will inevitably have a limited lifespan, and that ASIC resistance <a href="https://pdaian.com/blog/anti-asic-forks-considered-harmful/">has downsides</a> because it makes 51% attacks cheaper (eg. see the <a href="https://cointelegraph.com/news/ethereum-classic-51-attack-the-reality-of-proof-of-work">51% attack on Ethereum Classic</a>).</p>
<p>I believe that PoW algorithms that provide a medium level of ASIC resistance can be created, but such resistance is limited-term and both ASIC and non-ASIC PoW have disadvantages; in the long term the better choice for blockchain consensus is proof of stake.</p>
<blockquote style="background-color:#ffeeff">
<h3>
<ol start="7" type="1">
<li>Useful Proof of Work
</h3>
making the proof of work function something which is simultaneously useful; a common candidate is something like Folding@home, an existing program where users can download software onto their computers to simulate protein folding and provide researchers with a large supply of data to help them cure diseases.
</blockquote></li>
</ol>
<p>Status: <strong>Probably not feasible, with one exception</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face3.png" style="width:50px; height: 50px" /></p>
<p>The challenge with useful proof of work is that a proof of work algorithm requires many properties:</p>
<ul>
<li>Hard to compute</li>
<li>Easy to verify</li>
<li>Does not depend on large amounts of external data</li>
<li>Can be efficiently computed in small "bite-sized" chunks</li>
</ul>
<p>Unfortunately, there are not many computations that are useful that preserve all of these properties, and most computations that <em>do</em> have all of those properties and are "useful" are only "useful" for far too short a time to build a cryptocurrency around them.</p>
<p>However, there is one possible exception: zero-knowledge-proof generation. Zero knowledge proofs of aspects of blockchain validity (eg. <a href="https://ethresear.ch/t/stark-proving-low-degree-ness-of-a-data-availability-root-some-analysis/6214">data availability roots</a> for a simple example) are difficult to compute, and easy to verify. Furthermore, they are durably difficult to compute; if proofs of "highly structured" computation become too easy, one can simply switch to verifying a blockchain's entire state transition, which becomes extremely expensive due to the need to model the virtual machine and random memory accesses.</p>
<p>Zero-knowledge proofs of blockchain validity provide great value to users of the blockchain, as they can substitute the need to verify the chain directly; <a href="https://codaprotocol.com/">Coda</a> is doing this already, albeit with a simplified blockchain design that is heavily optimized for provability. Such proofs can significantly assist in improving the blockchain's safety and scalability. That said, the total amount of computation that realistically needs to be done is still much less than the amount that's currently done by proof of work miners, so this would at best be an add-on for proof of stake blockchains, not a full-on consensus algorithm.</p>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="8" type="1">
<li>Proof of Stake
</h3>
Another approach to solving the mining centralization problem is to abolish mining entirely, and move to some other mechanism for counting the weight of each node in the consensus. The most popular alternative under discussion to date is "proof of stake" - that is to say, instead of treating the consensus model as "one unit of CPU power, one vote" it becomes "one currency unit, one vote".
</blockquote></li>
</ol>
<p>Status: <strong>Great theoretical progress, pending more real-world evaluation</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face1.png" style="width:50px; height: 50px" /></p>
<p>Near the end of 2014, it became clear to the proof of stake community that some form of "weak subjectivity" <a href="https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity">is unavoidable</a>. To maintain economic security, nodes need to obtain a recent checkpoint extra-protocol when they sync for the first time, and again if they go offline for more than a few months. This was a difficult pill to swallow; many PoW advocates still cling to PoW precisely because in a PoW chain the "head" of the chain can be discovered with the only data coming from a trusted source being the blockchain client software itself. PoS advocates, however, were willing to swallow the pill, seeing the added trust requirements as not being large. From there the path to proof of stake through long-duration security deposits became clear.</p>
<p>Most interesting consensus algorithms today are fundamentally similar to <a href="http://pmg.csail.mit.edu/papers/osdi99.pdf">PBFT</a>, but replace the fixed set of validators with a dynamic list that anyone can join by sending tokens into a system-level smart contract with time-locked withdrawals (eg. a withdrawal might in some cases take up to 4 months to complete). In many cases (including ethereum 2.0), these algorithms achieve "economic finality" by penalizing validators that are caught performing actions that violate the protocol in certain ways (see <a href="https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51">here</a> for a philosophical view on what proof of stake accomplishes).</p>
<p>As of today, we have (among many other algorithms):</p>
<ul>
<li><strong>Casper FFG</strong>: <a href="https://arxiv.org/abs/1710.09437" class="uri">https://arxiv.org/abs/1710.09437</a></li>
<li><strong>Tendermint</strong>: <a href="https://tendermint.com/docs/spec/consensus/consensus.html" class="uri">https://tendermint.com/docs/spec/consensus/consensus.html</a></li>
<li><strong>HotStuff</strong>: <a href="https://arxiv.org/abs/1803.05069" class="uri">https://arxiv.org/abs/1803.05069</a></li>
<li><strong>Casper CBC</strong>: <a href="https://vitalik.ca/general/2018/12/05/cbc_casper.html" class="uri">https://vitalik.ca/general/2018/12/05/cbc_casper.html</a></li>
</ul>
<p>There continues to be ongoing refinement (eg. <a href="https://ethresear.ch/t/analysis-of-bouncing-attack-on-ffg/6113">here</a> and <a href="https://ethresear.ch/t/saving-strategy-and-fmd-ghost/6226">here</a>) . Eth2 phase 0, the chain that will implement FFG, is currently under implementation and enormous progress has been made. Additionally, Tendermint has been running, in the form of the <a href="https://cosmos.bigdipper.live/validators">Cosmos chain</a> for several months. Remaining arguments about proof of stake, in my view, have to do with optimizing the economic incentives, and further formalizing the <a href="https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363">strategy for responding to 51% attacks</a>. Additionally, the <a href="https://github.com/ethereum/eth2.0-specs/issues/701">Casper CBC spec</a> could still use concrete efficiency improvements.</p>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="9" type="1">
<li>Proof of Storage
</h3>
A third approach to the problem is to use a scarce computational resource other than computational power or currency. In this regard, the two main alternatives that have been proposed are storage and bandwidth. There is no way in principle to provide an after-the-fact cryptographic proof that bandwidth was given or used, so proof of bandwidth should most accurately be considered a subset of social proof, discussed in later problems, but proof of storage is something that certainly can be done computationally. An advantage of proof-of-storage is that it is completely ASIC-resistant; the kind of storage that we have in hard drives is already close to optimal.
</blockquote></li>
</ol>
<p>Status: <strong>A lot of theoretical progress, though still a lot to go, as well as more real-world evaluation</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face2.png" style="width:50px; height: 50px" /></p>
<p>There are a number of <a href="https://en.wikipedia.org/wiki/Proof_of_space">blockchains planning to use proof of storage</a> protocols, including <a href="https://eprint.iacr.org/2017/893.pdf">Chia</a> and <a href="https://filecoin.io/filecoin.pdf">Filecoin</a>. That said, these algorithms have not been tested in the wild. My own main concern is centralization: will these algorithms actually be dominated by smaller users using spare storage capacity, or will they be dominated by large mining farms?</p>
<h2 id="economics">Economics</h2>
<p><a name="numberten"></a></p>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="10" type="1">
<li>Stable-value cryptoassets
</h3>
One of the main problems with Bitcoin is the issue of price volatility ... Problem: construct a cryptographic asset with a stable price.
</blockquote></li>
</ol>
<p>Status: <strong>Some progress</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face2.png" style="width:50px; height: 50px" /></p>
<p><a href="https://makerdao.com/en/">MakerDAO</a> is now live, and has been holding stable for nearly two years. It has survived a 93% drop in the value of its underlying collateral asset (ETH), and there is now more than $100 million in DAI issued. It has become a mainstay of the Ethereum ecosystem, and many Ethereum projects have or are integrating with it. Other synthetic token projects, such as <a href="https://umaproject.org/">UMA</a>, are rapidly gaining steam as well.</p>
<p>However, while the MakerDAO system has survived tough economic conditions in 2019, the conditions were by no means the toughest that could happen. In the past, Bitcoin has <a href="https://fortune.com/2017/09/18/bitcoin-crash-history/">fallen by 75%</a> over the course of two days; the same may happen to ether or any other collateral asset some day. Attacks on the underlying blockchain are an even larger untested risk, especially if compounded by price decreases at the same time. Another major challenge, and arguably the larger one, is that the stability of MakerDAO-like systems is dependent on some underlying oracle scheme. Different attempts at oracle systems do exist (see #16), but the jury is still out on how well they can hold up under large amounts of economic stress. So far, the collateral controlled by MakerDAO has been lower than the value of the MKR token; if this relationship reverses MKR holders may have a collective incentive to try to "loot" the MakerDAO system. There are ways to try to protect against such attacks, but they have not been tested in real life.</p>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="11" type="1">
<li>Decentralized Public Goods Incentivization
</h3>
One of the challenges in economic systems in general is the problem of "public goods". For example, suppose that there is a scientific research project which will cost $1 million to complete, and it is known that if it is completed the resulting research will save one million people $5 each. In total, the social benefit is clear ... [but] from the point of view of each individual person contributing does not make sense ... So far, most problems to public goods have involved centralization Additional Assumptions And Requirements: A fully trustworthy oracle exists for determining whether or not a certain public good task has been completed (in reality this is false, but this is the domain of another problem)
</blockquote></li>
</ol>
<p>Status: <strong>Some progress</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face2.png" style="width:50px; height: 50px" /></p>
<p>The problem of funding public goods is generally understood to be split into two problems: the funding problem (where to get funding for public goods from) and the preference aggregation problem (how to determine what is a genuine public good, rather than some single individual's pet project, in the first place). This problem focuses specifically on the former, assuming the latter is solved (see the <a href="#numberfourteensic">"decentralized contribution metrics" section below</a> for work on that problem).</p>
<p>In general, there haven't been large new breakthroughs here. There's two major categories of solutions. First, we can try to elicit individual contributions, giving people social rewards for doing so. My own proposal for <a href="https://vitalik.ca/general/2017/03/11/a_note_on_charity.html">charity through marginal price discrimination</a> is one example of this; another is the anti-malaria donation badges on <a href="https://peepeth.com/welcome">Peepeth</a>. Second, we can collect funds from applications that have network effects. Within blockchain land there are several options for doing this:</p>
<ul>
<li>Issuing coins</li>
<li>Taking a portion of transaction fees at protocol level (eg. through <a href="https://github.com/ethereum/EIPs/issues/1559">EIP 1559</a>)</li>
<li>Taking a portion of transaction fees from some layer-2 application (eg. Uniswap, or some scaling solution, or even state rent in an execution environment in ethereum 2.0)</li>
<li>Taking a portion of other kinds of fees (eg. ENS registration)</li>
</ul>
<p>Outside of blockchain land, this is just the age-old question of how to collect taxes if you're a government, and charge fees if you're a business or other organization.</p>
<p><a name="numbertwelve"></a></p>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="12" type="1">
<li>Reputation systems
</h3>
<strong>Problem:</strong> design a formalized reputation system, including a score rep(A,B) -> V where V is the reputation of B from the point of view of A, a mechanism for determining the probability that one party can be trusted by another, and a mechanism for updating the reputation given a record of a particular open or finalized interaction.
</blockquote></li>
</ol>
<p>Status: <strong>Slow progress</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face3.png" style="width:50px; height: 50px" /></p>
<p>There hasn't really been much work on reputation systems since 2014. Perhaps the best is the use of token curated registries to create curated lists of trustable entities/objects; the <a href="https://blog.kleros.io/erc20-becomes-part-of-the-token/">Kleros ERC20 TCR</a> (yes, that's a <a href="https://medium.com/@tokencuratedregistry/a-simple-overview-of-token-curated-registries-84e2b7b19a06">token-curated registry</a> of legitimate ERC20 tokens) is one example, and there is even an alternative interface to Uniswap (<a href="http://uniswap.ninja" class="uri">http://uniswap.ninja</a>) that uses it as the backend to get the list of tokens and ticker symbols and logos from. Reputation systems of the subjective variety have not really been tried, perhaps because there is just not enough information about the "social graph" of people's connections to each other that has already been published to chain in some form. If such information starts to exist for other reasons, then subjective reputation systems may become more popular.</p>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="13" type="1">
<li>Proof of excellence
</h3>
One interesting, and largely unexplored, solution to the problem of [token] distribution specifically (there are reasons why it cannot be so easily used for mining) is using tasks that are socially useful but require original human-driven creative effort and talent. For example, one can come up with a "proof of proof" currency that rewards players for coming up with mathematical proofs of certain theorems
</blockquote></li>
</ol>
<p>Status: <strong>No progress, problem is largely forgotten</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face5.png" style="width:50px; height: 50px" /></p>
<p>The main alternative approach to token distribution that has instead become popular is <a href="https://en.wikipedia.org/wiki/Airdrop_%28cryptocurrency%29">airdrops</a>; typically, tokens are distributed at launch either proportionately to existing holdings of some other token, or based on some other metric (eg. as in the <a href="https://help.namebase.io/article/4vchu01mec-handshake-airdrop-101">Handshake airdrop</a>). Verifying human creativity directly has not really been attempted, and with recent progress on AI the problem of creating a task that only humans can do but computers can verify may well be too difficult.</p>
<p><a name="numberfifteensic"></a></p>
<blockquote style="background-color:#ffe4ff">
<h3>
15 [sic]. Anti-Sybil systems
</h3>
A problem that is somewhat related to the issue of a reputation system is the challenge of creating a "unique identity system" - a system for generating tokens that prove that an identity is not part of a Sybil attack ... However, we would like to have a system that has nicer and more egalitarian features than "one-dollar-one-vote"; arguably, one-person-one-vote would be ideal.
</blockquote>
<p>Status: <strong>Some progress</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face2.png" style="width:50px; height: 50px" /></p>
<p>There have been quite a few attempts at solving the unique-human problem. Attempts that come to mind include (incomplete list!):</p>
<ul>
<li><strong>HumanityDAO</strong>: <a href="https://www.humanitydao.org/" class="uri">https://www.humanitydao.org/</a></li>
<li><strong>Pseudonym parties</strong>: <a href="https://bford.info/pub/net/sybil.pdf" class="uri">https://bford.info/pub/net/sybil.pdf</a></li>
<li><strong>POAP</strong> ("proof of attendance protocol"): <a href="https://www.poap.xyz/" class="uri">https://www.poap.xyz/</a></li>
<li><strong>BrightID</strong>: <a href="https://www.brightid.org/" class="uri">https://www.brightid.org/</a></li>
</ul>
<p>With the growing interest in techniques like <a href="https://en.wikipedia.org/wiki/Quadratic_voting">quadratic voting</a> and <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3243656">quadratic funding</a>, the need for some kind of human-based anti-sybil system continues to grow. Hopefully, ongoing development of these techniques and new ones can come to meet it.</p>
<a name="numberfourteensic"></a>
<blockquote style="background-color:#ffe4ff">
<h3>
14 [sic]. Decentralized contribution metrics
</h3>
Incentivizing the production of public goods is, unfortunately, not the only problem that centralization solves. The other problem is determining, first, which public goods are worth producing in the first place and, second, determining to what extent a particular effort actually accomplished the production of the public good. This challenge deals with the latter issue.
</blockquote>
<p>Status: <strong>Some progress, some change in focus</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face6.png" style="width:50px; height: 50px" /></p>
<p>More recent work on determining value of public-good contributions does not try to separate determining tasks and determining quality of completion; the reason is that in practice the two are difficult to separate. Work done by specific teams tends to be non-fungible and subjective enough that the most reasonable approach is to look at relevance of task and quality of performance as a single package, and use the same technique to evaluate both.</p>
<p>Fortunately, there has been great progress on this, particularly with the discovery of <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3243656">quadratic funding</a>. Quadratic funding is a mechanism where individuals can make donations to projects, and then based on the number of people who donated and how much they donated, a formula is used to calculate how much they would have donated if they were perfectly coordinated with each other (ie. took each other's interests into account and did not fall prey to the tragedy of the commons). The difference between amount would-have-donated and amount actually donated for any given project is given to that project as a subsidy from some central pool (see #11 for where the central pool funding could come from). Note that this mechanism focuses on satisfying the values of some community, not on satisfying some given goal regardless of whether or not anyone cares about it. Because of the <a href="https://wiki.lesswrong.com/wiki/Complexity_of_value">complexity of values</a> problem, this approach is likely to be much more robust to unknown unknowns.</p>
<p>Quadratic funding has even been tried in real life with considerable success in the <a href="https://vitalik.ca/general/2019/10/24/gitcoin.html">recent gitcoin quadratic funding round</a>. There has also been some incremental progress on improving quadratic funding and similar mechanisms; particularly, <a href="https://ethresear.ch/t/pairwise-coordination-subsidies-a-new-quadratic-funding-design/5553">pairwise-bounded quadratic funding</a> to mitigate collusion. There has also been work on specification and implementation of <a href="https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413">bribe-resistant</a> voting technology, preventing users from proving to third parties who they voted for; this prevents many kinds of collusion and bribe attacks.</p>
<p><a name="numbersixteen"></a></p>
<blockquote style="background-color:#ffe4ff">
<h3>
<ol start="16" type="1">
<li>Decentralized success metrics
</h3>
Problem: come up with and implement a decentralized method for measuring numerical real-world variables ... the system should be able to measure anything that humans can currently reach a rough consensus on (eg. price of an asset, temperature, global CO2 concentration)
</blockquote></li>
</ol>
<p>Status: <strong>Some progress</strong>. <img src="http://vitalik.ca/files/posts_files/progress-files/happy_face2.png" style="width:50px; height: 50px" /></p>
<p>This is now generally just called "the oracle problem". The largest known instance of a decentralized oracle running is <a href="https://www.augur.net/">Augur</a>, which has processed outcomes for millions of dollars of bets. <a href="https://medium.com/@tokencuratedregistry/a-simple-overview-of-token-curated-registries-84e2b7b19a06">Token curated registries</a> such as the <a href="https://tokens.kleros.io/tokens">Kleros TCR for tokens</a> are another example. However, these systems still have not seen a real-world test of the forking mechanism (search for "subjectivocracy" <a href="https://blog.ethereum.org/2015/02/14/subjectivity-exploitability-tradeoff/">here</a>) either due to a highly controversial question or due to an attempted 51% attack. There is also research on the oracle problem happening outside of the blockchain space in the form of the "<a href="https://www2.cs.duke.edu/courses/spring17/compsci590.2/peer_prediction.pdf">peer prediction</a>" literature; see <a href="https://arxiv.org/abs/1911.00272">here</a> for a very recent advancement in the space.</p>
<p>Another looming challenge is that people want to rely on these systems to guide transfers of quantities of assets larger than the economic value of the system's native token. In these conditions, token holders in theory have the incentive to collude to give wrong answers to steal the funds. In such a case, the system would fork and the original system token would likely become valueless, but the original system token holders would still get away with the returns from whatever asset transfer they misdirected. Stablecoins (see <a href="#numberten">#10</a>) are a particularly egregious case of this. One approach to solving this would be a system that assumes that altruistically honest data providers do exist, and creating a mechanism to identify them, and only allowing them to churn slowly so that if malicious ones start getting voted in the users of systems that rely on the oracle can first complete an orderly exit. In any case, more development of oracle tech is very much an important problem.</p>
<h3 id="new-problems">New problems</h3>
<p>If I were to write the hard problems list again in 2019, some would be a continuation of the above problems, but there would be significant changes in emphasis, as well as significant new problems. Here are a few picks:</p>
<ul>
<li><strong>Cryptographic obfuscation</strong>: same as <a href="#numberfour">#4</a> above</li>
<li><strong>Ongoing work on post-quantum cryptography</strong>: both hash-based as well as based on post-quantum-secure "structured" mathematical objects, eg. elliptic curve isogenies, lattices...</li>
<li><strong>Anti-collusion infrastructure</strong>: ongoing work and refinement of <a href="https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413" class="uri">https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413</a>, including adding privacy against the operator, adding multi-party computation in a maximally practical way, etc.</li>
<li><strong>Oracles</strong>: same as <a href="#numbersixteen">#16</a> above, but removing the emphasis on "success metrics" and focusing on the general "get real-world data" problem</li>
<li><strong>Unique-human identities</strong> (or, more realistically, semi-unique-human identities): same as what was written as <a href="#numberfifteensic">#15</a> above, but with an emphasis on a less "absolute" solution: it should be much harder to get two identities than one, but making it impossible to get multiple identities is both impossible and potentially harmful even if we do succeed</li>
<li><strong>Homomorphic encryption and multi-party computation</strong>: ongoing improvements are still required for practicality</li>
<li><strong>Decentralized governance mechanisms</strong>: DAOs are cool, but current DAOs are still very primitive; we can do better</li>
<li><strong>Fully formalizing responses to PoS 51% attacks</strong>: ongoing work and refinement of <a href="https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363" class="uri">https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363</a></li>
<li><strong>More sources of public goods funding</strong>: the ideal is to charge for congestible resources inside of systems that have network effects (eg. transaction fees), but doing so in decentralized systems requires public legitimacy; hence this is a social problem along with the technical one of finding possible sources</li>
<li><strong>Reputation systems</strong>: same as <a href="#numbertwelve">#12</a> above</li>
</ul>
<p>In general, base-layer problems are slowly but surely decreasing, but application-layer problems are only just getting started.</p>
Fri, 22 Nov 2019 17:03:10 -0800
https://vitalik.ca/general/2019/11/22/progress.html
https://vitalik.ca/general/2019/11/22/progress.htmlgeneralReview of Gitcoin Quadratic Funding Round 3<p><em>Special thanks to the Gitcoin team and especially Frank Chen for working with me through these numbers</em></p>
<p>The next round of Gitcoin Grants quadratic funding has just finished, and we the numbers for how much each project has received <a href="https://gitcoin.co/blog/gitcoins-q3-match/">were just released</a>. Here are the top ten:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/gitcoin-files/round3.png" style="width:750px" />
</center>
<p><br><br></p>
<p>Altogether, $163,279 was donated to 80 projects by 477 contributors, augmented by a matching pool of $100,000. Nearly half came from four contributions above $10,000: $37,500 to Lighthouse, and $12,500 each to Gas Station Network, Black Girls Code and Public Health Incentives Layer. Out of the remainder, about half came from contributions between $1,000 and $10,000, and the rest came from smaller donations of various sizes. But what matters more here are not the raw donations, but rather the subsidies that the <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3243656">quadratic funding</a> mechanism applied. Gitcoin Grants is there to support valuable public goods in the Ethereum ecosystem, but also serve as a testbed for this new quadratic donation matching mechanism, and see how well it lives up to its promise of creating a democratic, market-based and efficient way of funding public goods. This time around, a modified formula based on <a href="https://ethresear.ch/t/pairwise-coordination-subsidies-a-new-quadratic-funding-design/5553">pairwise-bounded coordination subsidies</a> was used, which has the goal of minimizing distortion from large contributions from coordinated actors. And now we get to see how the experiment went.</p>
<h3 id="judging-the-outcomes">Judging the Outcomes</h3>
<p>First, the results. Ultimately, every mechanism for allocating resources, whether centralized, market-based, democratic or otherwise, must stand the test of delivering results, or else sooner or later it will be abandoned for another mechanism that is perceived to be better, even if it is less philosophically clean. Judging results is inherently a subjective exercise; any single person's analysis of a mechanism will inevitably be shaped by how well the results fit their own preferences and tastes. However, in those cases where a mechanism does output a surprising result, one can and should use that as an opportunity to learn, and see whether or not one missed some key information that other participants in the mechanism had.</p>
<p>In my own case, I found the top results very agreeable and a quite reasonable catalogue of projects that are good for the Ethereum community. One of the disparities between these grants and the Ethereum Foundation grants is that the Ethereum Foundation grants (see recent rounds <a href="https://blog.ethereum.org/2019/08/26/announcing-ethereum-foundation-and-co-funded-grants/">here</a> and <a href="https://blog.ethereum.org/2019/02/21/ethereum-foundation-grants-program-wave-5/">here</a>) tend to overwhelmingly focus on technology with only a small section on education and community resources, whereas in the Gitcoin grants while technology still dominates, EthHub is #2 and lower down defiprime.com is #14 and cryptoeconomics.study is #17. In this case my personal opinion is that EF <em>has</em> made a genuine error in undervaluing grants to community/education organizations and Gitcoin's "collective instinct" is correct. Score one for new-age fancy quadratic market democracy.</p>
<p>Another surprising result to me was Austin Griffith getting second place. I personally have never spent too much time thinking about Burner Wallet; I knew that it existed but in my mental space I did not take it too seriously, focusing instead on client development, L2 scaling, privacy and to a lesser extent smart contract wallets (the latter being a key use case of Gas Station Network at #8). After seeing Austin's impressive performance in this Gitcoin round, I asked a few people what was going on.</p>
<p>Burner Wallet (<a href="https://xdai.io/">website</a>, <a href="https://settle.finance/blog/what-is-the-burner-wallet-and-whats-xdai/">explainer article</a>) is an "insta-wallet" that's very easy to use: just load it up on your desktop or phone, and there you have it. It was used successfully at EthDenver to sell food from food trucks, and generally many people appreciate its convenience. Its main weaknesses are lower security and that one of its features, support for xDAI, is dependent on a permissioned chain.</p>
<p>Austin's Gitcoin grant is there to fund his <a href="https://gitcoin.co/grants/122/austin-griffith-ethereum-rampd">ongoing work</a>, and I have heard one criticism: there's many prototypes, but comparatively few "things taken to completion". There is also the critique that as great as Austin is, it's difficult to argue that he's as important to the success of Ethereum as, say, Lighthouse and Prysmatic, though one can reply that what matters is not total value, but rather the marginal value of giving a given project or person an extra $10,000. On the whole, however, I feel like quadratic funding's (Glen would say deliberate!) tendency to select for things like Burner Wallet with populist appeal is a much needed corrective to the influence of the Ethereum tech elite (including myself!) who often value technical impressiveness and undervalue simple and quick things that make it really easy for people to participate in Ethereum. This one is slightly more ambiguous, but I'll say score two for new-age fancy quadratic market democracy.</p>
<p>The main thing that I was disappointed the Gitcoiner-ati did <em>not</em> support more was Gitcoin maintenance itself. The Gitcoin Sustainability Fund only got a total $1,119 in raw contributions from 18 participants, plus a match of $202. The optional 5% tips that users could give to Gitcoin upon donating were not included into the quadratic matching calculations, but raised another ~$1,000. Given the amount of effort the Gitcoin people put in to making quadratic funding possible, this is not nearly enough; Gitcoin clearly deserves more than 0.9% of the total donations in the round. Meanwhile, the Ethereum Foundation (as well as Consensys and individual donors) have been giving grants to Gitcoin that include supporting Gitcoin itself. Hopefully in future rounds people will support Gitcoin itself too, but for now, score one for good old-fashioned EF technocracy.</p>
<p>On the whole, quadratic funding, while still young and immature, seems to be a remarkably effective complement to the funding preferences of existing institutions, and it seems worthwhile to continue it and even increase its scope and size in the future.</p>
<h3 id="pairwise-bounded-quadratic-funding-vs-traditional-quadratic-funding">Pairwise-bounded quadratic funding vs traditional quadratic funding</h3>
<p>Round 3 differs from previous rounds in that it uses a new <a href="https://ethresear.ch/t/pairwise-coordination-subsidies-a-new-quadratic-funding-design/5553">flavor of quadratic funding</a>, which limits the subsidy per pair of participants. For example, in traditional QF, if two people each donate $10, the subsidy would be $10, and if two people each donate $10,000, the subsidy would be $10,000. This property of traditional QF makes it highly vulnerable to collusion: two key employees of a project (or even two fake accounts owned by the same person) could each donate as much money as they have, and get back a very large subsidy. Pairwise-bounded QF computes the total subsidy to a project by looking through all pairs of contributors, and imposes a maximum bound on the total subsidy that any given pair of participants can trigger (combined across all projects). Pairwise-bounded QF also has the property that it generally penalizes projects that are dominated by large contributors:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/gitcoin-files/chart2.png" />
</center>
<p><br><br></p>
<p>The projects that lost the most relative to traditional QF seem to be projects that have a single large contribution (or sometimes two). For example, "fuzz geth and Parity for EVM consensus bugs" got a $415 match compared to the $2000 he would have gotten in traditional QF; the decrease is explained by the fact that the contributions are dominated by two large $4500 contributions. On the other hand, <a href="http://cryptoeconomics.study">cryptoeconomics.study</a> got $1274, <em>up</em> nearly double from the $750 it would have gotten in traditional QF; this is explained by the large diversity of contributions that the project received and particularly the lack of large sponsors: the largest contribution to cryptoeconomics.study was $100.</p>
<p>Another desirable property of pairwise-bounded QF is that it privileges <em>cross-tribal</em> projects. That is, if there are projects that group A typically supports, and projects that group B typically supports, then projects that manage to get support from both groups get a more favorable subsidy (because the pairs that go between groups are not as saturated). Has this incentive for building bridges appeared in these results?</p>
<p>Unfortunately, my code of honor as a social scientist obliges me to report the negative result: the Ethereum community just does not yet have enough internal tribal structure for effects like this to materialize, and even when there are differences in correlations they don't seem strongly connected to higher subsidies due to pairwise-bounding. Here are the cross-correlations between who contributed to different projects:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/gitcoin-files/correlations.png" />
</center>
<p><br><br></p>
<p>Generally, all projects are slightly positively correlated with each other, with a few exceptions with greater correlation and one exception with broad roughly zero correlation: <a href="https://gitcoin.co/grants/120/nori">Nori</a> (120 in this chart). However, Nori did not do well in pairwise-bounded QF, because over 94% of its donations came from a single $5000 donation.</p>
<h3 id="dominance-of-large-projects">Dominance of large projects</h3>
<p>One other pattern that we saw in this round is that popular projects got disproportionately large grants:</p>
<center>
<img src="http://vitalik.ca/files/posts_files/gitcoin-files/ratios.jpeg" />
</center>
<p><br><br></p>
<p>To be clear, this is not just saying "more contributions, more match", it's saying "more contributions, <em>more match per dollar contributed</em>". Arguably, this is an intended feature of the mechanism. Projects that can get more people to donate to them represent public goods that serve a larger public, and so tragedy of the commons problems are more severe and hence contributions to them should be multiplied more to compensate. However, looking at the list, it's hard to argue that, say, Prysm ($3,848 contributed, $8,566 matched) is a more public good than Nimbus ($1,129 contributed, $496 matched; for the unaware, Prysm and Nimbus are both eth2 clients). The failure does not look too severe; on average, projects near the top do seem to serve a larger public and projects near the bottom do seem niche, but it seems clear that at least part of the disparity is not genuine publicness of the good, but rather inequality of attention. N units of marketing effort can attract attention of N people, and theoretically get N^2 resources.</p>
<p>Of course, this could be solved via a "layer on top" venture-capital style: upstart new projects could get investors to support them, in return for a share of matched contributions received when they get large. Something like this would be needed eventually; predicting future public goods is as important a social function as predicting future private goods. But we could also consider less winner-take-all alternatives; the simplest one would be adjusting the QF formula so it uses an exponent of eg. 1.5 instead of 2. I can see it being worthwhile to try a future round of Gitcoin Grants with such a formula (<span class="math inline">\(\left(\sum_i x_i^{\frac{2}{3}}\right)^{\frac{3}{2}}\)</span> instead of <span class="math inline">\(\left(\sum_i x_i^{\frac{1}{2}}\right)^2\)</span>) to see what the results are like.</p>
<h3 id="individual-leverage-curves">Individual leverage curves</h3>
<p>One key question is, if you donate $1, or $5, or $100, how big an impact can you have on the amount of money that a project gets? Fortunately, we can use the data to calculate these deltas!</p>
<center>
<img src="http://vitalik.ca/files/posts_files/gitcoin-files/deltas.png" />
</center>
<p><br><br></p>
<p>The different lines are for different projects; supporting projects with higher existing support will lead to you getting a bigger multiplier. In all cases, the first dollar is very valuable, with a matching ratio in some cases over 100:1. But the second dollar is much less valuable, and matching ratios quickly taper off; even for the largest projects increasing one's donation from $32 to $64 will only get a 1:1 match, and anything above $100 becomes almost a straight donation with nearly no matching. However, given that it's likely possible to get legitimate-looking Github accounts on the grey market for around those costs, having a cap of a few hundred dollars on the amount of matched funds that any particular account can direct seems like a very reasonable mitigation, despite its costs in limiting the bulk of the matching effect to small-sized donations.</p>
<h3 id="conclusions">Conclusions</h3>
<p>On the whole, this was by far the largest and the most data-rich Gitcoin funding round to date. It successfully attracted hundreds of contributors, reaching a size where we can finally see many significant effects in play and drown out the effects of the more naive forms of small-scale collusion. The experiment already seems to be leading to valuable information that can be used by future quadratic funding implementers to improve their quadratic funding implementations. The case of Austin Griffith is also interesting because $23,911 in funds that he received comes, in relative terms, surprisingly close to an average salary for a developer if the grants can be repeated on a regular schedule. What this means is that if Gitcoin Grants <em>does</em> continue operating regularly, and attracts and expands its pool of donations, we could be very close to seeing the first "quadratic freelancer" - someone directly "working for the public", funded by donations boosted by quadratic matching subsidies. And at that point we could start to see more experimentation in new forms of organization that live on top of quadratic funding gadgets as a base layer. All in all, this foretells an exciting and, err, radical public-goods funding future ahead of us.</p>
Thu, 24 Oct 2019 18:03:10 -0700
https://vitalik.ca/general/2019/10/24/gitcoin.html
https://vitalik.ca/general/2019/10/24/gitcoin.htmlgeneral