desukedo.biz

Buy e liquids online coupons

Marliave bitcoin charts

Announcing World Trade Francs: The Official Ethereum Stablecoin 01st April, Ethereum scalability research and development subsidy programs 02nd January, All of these technologies remedy key deficiencies of the blockchain design with respect to centralized servers: However, there is one piece of the puzzle that all approaches so far have not yet managed to crack: Bitcoin brings to its users a rather unique set of tradeoffs with respect to financial privacy.

Although Bitcoin does a substantially better job than any system that came before it at protecting the physical identities behind each of its accounts — better than fiat and banking infrastructure because it requires no identity registration, and better than cash because it can be combined with Tor to completely hide physical location, the presence of the Bitcoin blockchain means that the actual transactions made by the accounts are more public than ever — neither the US government, nor China, nor the thirteen year old hacker down the street even need so much as a warrant in order to determine exactly which account sent how much BTC to which destination at what particular time.

In general, these two forces pull Bitcoin in opposite directions, and it is not entirely clear which one dominates. With Ethereum, the situation is similar in theory, but in practice it is rather different. Bitcoin is a blockchain intended for currency, and currency is inherently a very fungible thing.

There exist techniques like merge avoidance which allow users to essentially pretend to be separate accounts, with their wallet managing the separation in the background. Hence, Ethereum, as it stands today, will in many cases inherit the transparency side of blockchain technology much more so than the privacy side although those interested in using Ethereum for currency can certainly build higher-privacy cash protocols inside of subcurrencies.

Even if we solve scalability and blockchain data assets, will the lack of privacy inherent to blockchains mean that we simply have to go back to trusting centralized servers? Or can we come up with a protocol that offers the best of both worlds: What is this protocol? To skip the fun technical details and go straight to applications, click here. Secret computation networks rely on two fundamental primitives to store information in a decentralized way.

The first is secret sharing. Secret sharing essentially allows data to be stored in a decentralized way across N parties such that any K parties can work together to reconstruct the data, but K-1 parties cannot recover any information at all.

N and K can be set to any values desired; all it takes is a few simple parameter tweaks in the algorithm. The simplest way to mathematically describe secret sharing is as follows. We know that two points make a line:.

To implement 3-of-N secret sharing, we just make a parabola instead, and give people points on the parabola:. Parabolas have the property that any three points on a parabola can be used to reconstruct the parabola and no one or two points suffice , so essentially the same process applies.

And, more generally, to implement K-of-N secret sharing, we use a degree K-1 polynomial in the same way. There is a set of algorithms for recovering the polynomial from a sufficient set of points in all such cases; they are described in more details in our earlier article on erasure coding.

This is how the secret sharing DAO will store data. Instead of every participating node in the consensus storing a copy of the full system state, every participating node in the consensus will store a set of shares of the state — points on polynomials, one point on a different polynomial for each variable that makes up part of the state.

Now, how does the secret sharing DAO do computation? For this, we use a set of algorithms called secure multiparty computation SMPC. The basic principle behind SMPC is that there exist ways to take data which is split among N parties using secret sharing, perform computations on it in a decentralized way, and end up with the result secret-shared between the parties, all without ever reconstituting any of the data on a single device.

SMPC with addition is easy. Thus, we have a rule: Multiplication by a known constant value works the same way: Multiplication of two secret shared values, unfortunately, is much more involved. First, suppose that there exist values a and b , secret shared among parties P[1] … P[n] , where a[i] represents the ith share of a and same for b[i] and b. We start off like this:. The answer is, surprisingly, yes, but with a serious problem: Hence, if we do multiplication more than once, the polynomial would become too big for the group of N to store.

To avoid this problem, we perform a sort of rebasing protocol where we convert the shares of the larger polynomial into shares of a polynomial of the original degree. The way it works is as follows. Thus, P[j] now has c[i][j] for all i. Given this, P[j] calculates c[j] , and so everyone has secret shares of c , on a polynomial with the same degree as a and b.

To do this, we used a clever trick of secret sharing: This allows us to move from a higher-degree polynomial to a lower degree polynomial but avoid revealing the values in the middle — instead, the middle step involved both layers being applied at the same time.

With addition and multiplication over 0 and 1, we have the ability to run arbitrary circuits inside of the SMPC mechanism. Hence, we can run whatever programs we want, although with one key limitation: There are two ways around this problem. Second, as we will see, if we implement if statements inside the EVM, and run the EVM inside SMPC, then we can resolve the problem, leaking only the information of how many steps the EVM took before computation exited and if we really care, we can reduce the information leakage further, eg.

The secret-sharing based protocol described above is only one way to do relatively simply SMPC; there are other approaches, and to achieve security there is also a need to add a verifiable secret sharing layer on top, but that is beyond the scope of this article — the above description is simply meant to show how a minimal implementation is possible.

Now that we have a rough idea of how SMPC works, how would we use it to build a decentralized currency engine? Now, since the blockchain is not transparent, we might expect the need for two kinds of transactions that users can send into the SMPC: We define the two types of requests as follows:.

Essentially, the database is stored as a set of 3-tuples representing accounts, where each 3-tuple stores the owning pubkey, nonce and balance. To send a request, a node constructs the transaction, splits it off into secret shares, generates a random request ID and attaches the ID and a small amount of proof of work to each share.

The proof of work is there because some anti-spam mechanism is necessary, and because account balances are private there is no way if the sending account has enough funds to pay a transaction fee. The nodes then independently verify the shares of the signature against the share of the public key supplied in the transaction there are signature algorithms that allow you to do this kind of per-share verification; Schnorr signatures are one major category.

If a given node sees an invalid share due to proof of work or the signature , it rejects it; otherwise, it accepts it. Transactions that are accepted are not processed immediately, much like in a blockchain architecture; at first, they are kept in a memory pool. At the end of every 12 seconds, we use some consensus algorithm — it could be something simple, like a random node from the N deciding as a dictator, or an advanced neo-BFT algorithm like that used by Pebble — to agree on which set of request IDs to process and in which order for simplicity, simple alphabetical order will probably suffice.

So what does this formula do? It consists of three stages. First, we extract the owner pubkey of the account that the request is trying to get the balance of. Because the computation is done inside of an SMPC, and so no node actually knows what database index to access, we do this by simply taking all the database indices, multiplying the irrelevant ones by zero and taking the sum.

Finally, we use the same database getting primitive to get the balance, and multiply the balance by the validity to get the result ie. First, we compute the validity predicate, consisting of checking that 1 the public key of the targeted account is correct, 2 the nonce is correct, and 3 the account has enough funds to send. Note that all of these can be parallelized. This is once again trivial using boolean logic gates, but even if we use a finite field for efficiency there do exist some clever tricks for performing the check using nothing but additions and multiplications.

In all of the above we saw two fundamental limitations in efficiency in the SMPC architecture. First, reading and writing to a database has an O n cost as you pretty much have to read and write every cell. Doing anything less would mean exposing to individual nodes which subset of the database a read or write was from, opening up the possibility of statistical memory leaks.

Second, every multiplication requires a network message, so the fundamental bottleneck here is not computation or memory but latency. Because of this, we can already see that secret sharing networks are unfortunately not God protocols; they can do business logic just fine, but they will never be able to do anything more complicated — even crypto verifications, with the exception of a select few crypto verifications specifically tailored to the platform, are in many cases too expensive.

Now, the next problem is, how do we go from this simple toy currency to a generic EVM processor? Well, let us examine the code for the virtual machine inside a single transaction environment. A simplified version of the function looks roughly as follows:.

Hence, we can simply store these as records, and for every computational step run a function similar to the following:. Essentially, we compute the result of every single opcode in parallel, and then pick the correct one to update the state. The alive variable starts off at 1, and if the alive variable at any point switches to zero, then all operations from that point simply do nothing. This seems horrendously inefficient, and it is, but remember: Everything above can be parallelized.

In fact, the astute reader may even notice that the entire process of running every opcode in parallel has only O n complexity in the number of opcodes particularly if you pre-grab the top few items of the stack into specified variables for input as well as output, which we did not do for brevity , so it is not even the most computationally intensive part if there are more accounts or storage slots than opcodes, which seems likely, the database updates are.

In an EVM with many participants, the database will likely be the largest overhead. To mitigate this problem, there are likely clever information leakage tradeoffs that can be made. For example, we already know that most of the time code is read from sequential database indices. Hence, one approach might be to store the code as a sequence of large numbers, each large number encoding many opcodes, and then use bit decomposition protocols to read off individual opcodes from a number once we load it.

There are also likely many ways to make the virtual machine fundamentally much more efficient; the above is meant, once again, as a proof of concept to show how a secret sharing DAO is fundamentally possible, not anything close to an optimal implementation. Additionally, we can look into architectures similar to the ones used in scalability 2.

However, blockchain protocols need to theoretically last forever, and so stagnant economic sets do not work; rather, we need to select the consensus participants using some mechanism like proof of stake.

To do this, an example protocol would work as follows:. All of the above handles decentralization assuming honest participants; but in a cryptocurrency protocol we also need incentives. To accomplish that, we use a set of primitives called verifiable secret sharing , that allow us to determine whether a given node was acting honestly throughout the secret sharing process.

Essentially, this process works by doing the secret sharing math in parallel on two different levels: Elliptic curve points are convenient because they have a commutative and associative addition operator - in essence, they are magic objects which can be added and subtracted much like numbers can. By doing the secret sharing math on the number level and the elliptic curve point level at the same time, and publicizing the elliptic curve points, it becomes possible to verify malfeasance.

For efficiency, we can probably use a Schellingcoin-style protocol to allow nodes to punish other nodes that are malfeasant. So, what do we have? If the blockchain is a decentralized computer, a secret sharing DAO is a decentralized computer with privacy. The secret sharing DAO pays dearly for this extra property: