The cryptocurrency 2.0 sector has made significant advancements over the past year in enhancing blockchain technology, including the establishment and, in certain instances, the actual implementation of proof of stake models such as Slasher<\/a> and DPOS<\/a>, various types<\/a> of scalable<\/a> blockchain mechanisms<\/a>, blockchains utilizing “leaderless consensus” strategies derived from traditional Byzantine fault tolerance principles<\/a>, along with economic components like Schelling<\/a> consensus frameworks<\/a> and stable<\/a> currencies<\/a>. Each of these technologies addresses critical shortcomings of the blockchain model in comparison to centralized servers: scalability minimizes size limitations and transaction expenses, leaderless consensus mitigates various types of vulnerabilities, enhanced PoS consensus frameworks lower consensus expenses and bolster security, and Schelling consensus enables blockchains to be “cognizant” of real-world information. Nevertheless, there remains one aspect of the equation that all methodologies thus far have not yet resolved: privacy.<\/p>\n <\/p>\n <\/p>\n Bitcoin offers its users a rather distinctive array of trade-offs concerning financial confidentiality. While Bitcoin performs significantly better than any previous system at safeguarding the actual identities<\/em> associated with each of its accounts – superior to fiat and banking systems due to the absence of identity registration, and better than cash as it can be used in conjunction with Tor to fully obscure physical location, the existence of the Bitcoin blockchain implies that the genuine transactions<\/em> executed by the accounts are more visible than ever – neither the US government, nor China, nor the thirteen-year-old hacker down the block require even a warrant to ascertain precisely which account transferred how much BTC to which recipient at what specific moment. In general, these two opposing forces pull Bitcoin in conflicting directions, and it is not entirely apparent which one predominates. <\/p>\n <\/p>\n In regard to Ethereum, the scenario is theoretically similar, but in practice, it differs considerably. Bitcoin is a blockchain designed for currency, and currency is, by its nature, a highly fungible entity. There are methods like merge avoidance<\/a> that enable users to effectively masquerade as 100 distinct accounts, with their wallet managing the separation behind the scenes. Coinjoin<\/a> can be implemented to “shuffle” assets in a decentralized manner, and centralized mixers are also a viable option, particularly when combining several of them. Ethereum, on the contrary, is meant to store the interim state of any<\/em> type of processes or relationships, and regrettably, it is often the case that many processes or connections that are significantly more intricate than money are intrinsically “account-based”, which results in considerable costs when attempting to obscure one’s actions through multiple accounts. Therefore, Ethereum, in its current form, often embodies the transparency aspect of blockchain technology far more than the privacy aspect (although those keen on using Ethereum for currency can certainly construct higher-privacy cash protocols within subcurrencies).<\/p>\n <\/p>\n Now, the inquiry arises, what happens when individuals genuinely desire privacy, yet a Diaspora-style self-hosting solution or a Zerocash-style zero-knowledge-proof approach is, for any reason, unfeasible – for instance, if we wish to carry out computations that necessitate aggregating multiple users’ private data? Even if we resolve scalability and blockchain data assets, will the absence of privacy inherently linked to blockchains mean that we simply have to revert to relying on centralized servers? Or can we devise a protocol that merges the advantages of both realms: a blockchain-like system that provides decentralized authority not only over the permission to modify the state but also over the entitlement to access the information entirely?<\/p>\n <\/p>\n Interestingly, such a system exists within the realm of possibility, and was even postulated by Nick Szabo in 1998<\/a> under the label of “God protocols” (although, as Nick Szabo has noted, we should avoid using that term for the protocols we are about to outline here since God is generally considered or even defined<\/a> to be Pareto-superior to everything<\/i> else and as we will soon demonstrate, these protocols are quite distant from that); but now with the emergence of Bitcoin-style cryptoeconomic technology, the creation of such a protocol may, for the first time, genuinely be practical. What is this protocol? To assign it a reasonably technically precise yet still comprehensible name, we will refer to it as a “secret sharing DAO”.<\/p>\n <\/p>\n <\/p>\n To bypass the entertaining technical nuances and head directly to applications, click here<\/a><\/i><\/small><\/p>\n <\/p>\n Secret computation networks depend on two core components to store data in a decentralized manner. The first is secret sharing<\/a><\/strong>. Secret sharing fundamentally enables data to be kept in a decentralized manner across N participants in such a way that any K participants can collaborate to reconstruct the information, but K-1 participants are unable to retrieveany details whatsoever. N and K may be adjusted to any preferred values; it merely requires a few minor parameter adjustments in the algorithm.<\/p>\n <\/p>\n The most straightforward way to mathematically represent secret sharing is as follows. We understand that two points define a line:<\/p>\n Thus, to execute 2-of-N secret sharing, we take our secret S<\/span>, produce a random slope m<\/span>, and formulate the line y = mx + S<\/span>. We then provide the N<\/span> participants with the points on the line (1, m + S)<\/span>, (2, 2m + S)<\/span>, (3, 3m + S)<\/span>, etc. Any two of them can reconstruct the line and retrieve the original secret, while a single individual can accomplish nothing; if you obtain the point (4, 12)<\/span>, that could belong to the line y = 2x + 4<\/span>, or y = -10x + 52<\/span>, or y = 305445x – 1221768<\/span>. To implement 3-of-N secret sharing, we simply create a parabola instead, and provide individuals points on the parabola:<\/p>\n Parabolas possess the characteristic that any three points on a parabola can be utilized to reconstruct the parabola (and no one or two points are adequate), so fundamentally the same method is applicable. And, more broadly, to implement K-of-N secret sharing, we employ a polynomial of degree K-1 in a similar manner. There exists a collection of algorithms<\/a> for retrieving the polynomial from a sufficient set of points in all such scenarios; they are elaborated on in our previous article on erasure coding<\/a>.<\/p>\n <\/p>\n This is how the secret sharing DAO will manage data. Rather than having each participating node in the consensus hold a copy of the entire system state, each participating node in the consensus will maintain a set of shares<\/em> of the state – points on polynomials, one point on a different polynomial for each variable that constitutes part of the state.<\/p>\n <\/p>\n <\/p>\n Now, how does the secret sharing DAO conduct computation? For this, we utilize a series of algorithms called secure multiparty computation<\/a><\/strong> (SMPC). The core principle behind SMPC is that there are methods to take data which is distributed among N parties using secret sharing, execute computations on it in a decentralized manner, and ultimately arrive at the result secret-shared among the parties, all without ever reconstructing any of the data on a single device.<\/p>\n <\/p>\n SMPC with addition is straightforward. To illustrate how, let’s revisit the two-points-make-a-line example, but now let’s consider two lines:<\/p>\n Assume that the x=1<\/span> point of both lines A<\/span> and B<\/span> is stored by device P[1]<\/span>, the x=2<\/span> point is saved by device P[2]<\/span>, and so forth. Now, suppose that P[1]<\/span> calculates a new value, C(1) = A(1) + B(1)<\/span>, and B computes C(2) = A(2) + B(2)<\/span>. Now, let’s sketch a line through those two points:<\/p>\n Thus, we obtain a new line, C<\/span>, such that C = A + B<\/span> at points x=1<\/span> and x=2<\/span>. However, the intriguing aspect is that this new line is, in fact, equal to A + B<\/span> at every<\/em> point:<\/p>\n Therefore, we establish a rule: sums of secret shares (at the identical x coordinate) are secret shares of the overall sum. Utilizing this principle (which also extends to higher dimensions), we can transform secret shares of a<\/span> and secret shares of b<\/span> into secret shares of a+b<\/span>, all without ever reconstructing a<\/span> and b<\/span> themselves<\/em>. Multiplication by a known constant value operates in the same manner: k<\/span> times the ith secret share of a<\/span> is equivalent to the ith secret share of a*k<\/span>.<\/p>\n <\/p>\n Multiplication of two secret shared quantities, regrettably, is far more complex<\/a>. The process will entail several steps to elucidate, and since it is fairly intricate in any case, it is advisable to conduct this for arbitrary polynomials right away. Here\u2019s the intriguing part. First, let\u2019s assume there are values a<\/span> and b<\/span>, secret shared among parties P[1]<\/span> … P[n]<\/span>, where a[i]<\/span> signifies the ith share of a<\/span> (and similarly for b[i]<\/span> and b<\/span>). We commence like this:<\/p>\n Now, one approach that you might consider is, if we can simply create a new polynomial c = a + b<\/span> by ensuring every participant tracks c[i] = a[i] + b[i]<\/span>, is it possible to apply the same principle to multiplication? The response is, surprisingly, affirmative, yet it comes with a substantial issue: the resultant polynomial has a degree that is double that of the initial ones. For instance, if the initial polynomials were y = x + 5<\/span> and y = 2x – 3<\/span>, their multiplication would yield y = 2x^2 + 7x – 15<\/span>. Therefore, if we perform multiplication repeatedly, the polynomial would grow too large for the N group to manage.<\/p>\n <\/p>\n To mitigate this issue, we execute a type of rebasing protocol where we transform the shares of the larger polynomial into shares of a polynomial with the original degree. The functioning is as follows. Initially, party P[i]<\/span> produces a new random polynomial, matching the degree of a<\/span> and b<\/span>, which evaluates to c[i] = a[i]*b[i]<\/span> at zero and subsequently distributes points along that polynomial (i.e., shares of c[i]<\/span>) to all participants.<\/p>\n Consequently, P[j]<\/span> now possesses c[i][j]<\/span> for every i<\/span>. Given this information, P[j]<\/span> computes c[j]<\/span>, ensuring that everyone holds secret shares of c<\/span>, based on a polynomial that maintains the same degree as a<\/span> and b<\/span>.<\/p>\n To accomplish this, we utilized a clever technique of secret sharing: since the mathematics of secret sharing itself involves nothing but additions and multiplications with known constants, the two layers of secret sharing are commutative: if we first implement secret sharing layer A and then layer B, we can remove layer A prior to layer B and still maintain protection. This enables us to transition from a higher-degree polynomial to a lower-degree polynomial while concealing the intermediate values – instead, the intermediate phase involved both layers being applied simultaneously<\/em>. <\/p>\n <\/p>\n With operations of addition and multiplication over 0 and 1, we possess the capacity to execute arbitrary circuits within the SMPC framework. We can define:<\/p>\n <\/p>\n <\/p>\n Thus, we can conduct any programs desired, although with one significant limitation: secret conditional branching is not feasible. In other words, if we had a computation if (x == 5) <\/p>\n There are two solutions to this concern. Firstly, we can utilize multiplication as a “poor man’s if” – substitute an expression like if (x == 5) <\/p>\n The secret-sharing based protocol outlined above represents merely one approach to accomplishing relatively straightforward SMPC; alternative methods exist, and ensuring security also necessitates the addition of a verifiable secret sharing<\/a> layer above, but that lies beyond the scope of this article – the preceding explanation aims simply to illustrate how a minimal implementation is feasible.<\/p>\n <\/p>\n <\/p>\n Now that we possess a basic understanding of how SMPC operates, how might we apply it to construct a decentralized currency engine? The conventional description of a blockchain in this blog is as a system that sustains a state, S<\/span>, accepts transactions, reaches consensus on which transactions should be executed at a certain time, and computes a state transition function APPLY(S, TX) -> S’ OR INVALID<\/span>. In this context, we will assert that all<\/em> transactions are deemed valid, and if a transaction TX<\/span> is invalid, then we simply conclude that APPLY(S, TX) = S<\/span>.<\/p>\n <\/p>\n Given that the blockchain lacks transparency, we might anticipate the requirement for two different categories of transactions that users can submit into the SMPC: get requests<\/strong>, inquiring about specific details regarding an account in the present state, and update requests<\/strong>, comprising transactions to enact on the state. We will establish the rule that each account can solely request balance and nonce details pertaining to itself, and can only withdraw from its own balance. We characterize the two types of requests as follows:<\/p>\n <\/p>\n <\/p>\n The information is preserved across the N nodes in the subsequent structure:<\/p>\n In essence, the information is organized as a collection of 3-tuples that symbolize accounts, with each 3-tuple encapsulating the owning pubkey, nonce, and balance. To initiate a request, a node formulates the transaction, partitions it into secret shares, creates a random request ID, and appends both the ID and a minor amount of proof of work to each share. The proof of work is essential due to the requirement for some anti-spam strategies, and since account balances are confidential, there’s no means to ascertain if the sending account possesses sufficient funds to cover a transaction fee. The nodes then autonomously validate the shares of the signature against the portion of the public key provided in the transaction (there exist signature methodologies permitting this sort of share-by-share validation; Schnorr signatures<\/a> represent one significant category). If any specific node encounters an invalid share (due to proof of work or signature issues), it discards it; otherwise, it accepts it.<\/p>\n <\/p>\n Accepted transactions are not executed instantaneously, akin to a blockchain framework; initially, they are stored within a memory pool. Every 12 seconds, we employ a consensus algorithm – it might be a straightforward approach, such as a random node from the N acting as a dictator, or a sophisticated neo-BFT algorithm similar to that utilized by Pebble<\/a> – to reach a consensus on which set of request IDs should be processed and in what sequence (for ease, basic alphabetical ordering will likely be adequate).<\/p>\n <\/p>\n At this point, to fulfill a GET request, the SMPC will perform computations and reconstruct the result of the following operation:<\/p>\n <\/p>\n <\/p>\n What is the purpose of this equation? It is structured in three phases. Initially, we obtain the owner pubkey of the account for which the request seeks to ascertain the balance. Since the calculation occurs within an SMPC, and therefore no node is aware of the specific database index to access, we achieve this by simply collecting all database indices, multiplying the unrelated ones by zero and then computing the total. Following this, we verify if the request is attempting to acquire information from an account that it indeed possesses (recall that we verified the legitimacy of from_pubkey<\/span> against the signature in the initial phase, thus here we merely require to confirm the account ID against the from_pubkey<\/span>). Ultimately, we apply the same database retrieval primitive to obtain the balance, and multiply the balance by the validity to derive the outcome (i.e., invalid requests yield a balance of 0, while valid ones reflect the actual balance).<\/p>\n <\/p>\n Now, let’s examine the process of a SEND operation. First, we calculate the validity condition, which entails verifying that (1) the public key of the targeted account is accurate, (2) the nonce is appropriate, and (3) the account possesses sufficient funds for the transaction. It is important to note that to accomplish this we again employ the “multiply by an equality check and add” protocol, but for simplicity, we will shorten R[0] * (x == 0) + R[3] * (x == 1) + …<\/span> to R[x * 3]<\/span>.<\/p>\n <\/p>\nCurrency, Dapps and Privacy<\/h3>\n
Fundamentals: Secret Sharing<\/h3>\n
\n
\n<\/center>
\n<\/p>\n![\"\"](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/08\/threepoints.png\")
<\/center>
\n<\/p>\nFundamentals: Computation<\/h3>\n
\n![](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/12\/twolines.png\")
\n<\/center>
\n<\/p>\n
\n![](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/12\/twolinesum.png\")
\n<\/center>
\n<\/p>\n
\n![](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/12\/twolinesum2.png\")
\n<\/center>
\n<\/p>\n
\n![](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/12\/secretmultiply.png\")
\n<\/center>
\n<\/p>\n
\n![](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/12\/secretmultiply2.png\")
\n<\/center>
\n<\/p>\n
\n![](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/12\/secretmulitply3.png\")
\n<\/center>
\n<\/p>\n\n
Creating a Currency<\/h3>\n
SEND: <\/span>[<\/span>from_pubkey, from_id, to, value, nonce, sig<\/span>]<\/span>\n<\/span>GET: <\/span>[<\/span>from_pubkey, from_id, sig<\/span>]<\/span>\n<\/span><\/code><\/pre>\n<\/div>\n![](\"https:\/\/blog.ethereum.org\/images\/posts\/2014\/12\/accounts.png\")
\n<\/p>\nowner_pubkey <\/span>=<\/span> R<\/span>[<\/span>0<\/span>]<\/span> * <\/span>(<\/span>from_id <\/span>==<\/span> <\/span>0<\/span>)<\/span> + R<\/span>[<\/span>3<\/span>]<\/span> * <\/span>(<\/span>from_id <\/span>==<\/span> <\/span>1<\/span>)<\/span> + <\/span>..<\/span>. + R<\/span>[<\/span>3<\/span>*n<\/span>]<\/span> * <\/span>(<\/span>from_id <\/span>==<\/span> n<\/span>)<\/span>\n<\/span>\nvalid <\/span>=<\/span> <\/span>(<\/span>owner_pubkey <\/span>==<\/span> from_pubkey<\/span>)<\/span>\n<\/span>\noutput <\/span>=<\/span> valid * <\/span>(<\/span>R<\/span>[<\/span>2<\/span>]<\/span> * <\/span>(<\/span>from_id <\/span>==<\/span> <\/span>0<\/span>)<\/span> + R<\/span>[<\/span>5<\/span>]<\/span> * <\/span>(<\/span>from_id <\/span>==<\/span> <\/span>1<\/span>)<\/span> + <\/span>..<\/span>. + R<\/span>[<\/span>3n + <\/span>2<\/span>]<\/span> * <\/span>(<\/span>from_id <\/span>==<\/span> n<\/span>))<\/span>\n<\/span><\/code><\/pre>\n<\/div>\n