Signo sagitario combina com aries
41 comments
Why bitcoin and ethereum will remain
Announcing World Trade Francs: The Official Ethereum Stablecoin 01st April, Ethereum scalability research and development subsidy programs 02nd January, Special thanks to Vlad Zamfir for much of the thinking behind multi-chain cryptoeconomic paradigms. First off, a history lesson. In October , when I was visiting Israel as part of my trip around the Bitcoin world, I came to know the core teams behind the colored coins and Mastercoin projects.
The scheme would generalize savings wallets, contracts for difference, many kinds of gambling, among other features. It was still quite limited, allowing only three stages open, fill, resolve and no internal memory and being limited to 2 parties per contract, but it was the first true seed of the Ethereum idea.
I submitted the proposal to the Mastercoin team. Thus, I decided to go out on my own and simply build the thing myself. Over the next three weeks I created the original Ethereum whitepaper unfortunately now gone, but a still very early version exists here. Once competent developers like Gavin Wood and Jeffrey Wilcke, who did not share my deficiencies in ability to write p2p networking code, joined the project, and once enough people were excited that I saw there would be money to hire more, I made the decision to immediately move to an independent blockchain.
The reasoning for this choice I described in my whitepaper in early January:. The advantage of a metacoin protocol is that it can allow for more advanced transaction types, including custom currencies, decentralized exchange, derivatives, etc, that are impossible on top of Bitcoin itself. However, metacoins on top of Bitcoin have one major flaw: The reason is that while one can use SPV to determine that there is a transaction sending 30 metacoins to address X, that by itself does not mean that address X has 30 metacoins; what if the sender of the transaction did not have 30 metacoins to start with and so the transaction is invalid?
This makes it impossible to have a truly secure client without downloading the entire 12 GB Bitcoin blockchain. Finally, long after that, I realized that by making an independent blockchain allows us to experiment with stronger versions of GHOST-style protocols, safely knocking down the block time to 12 seconds.
Since a number of readers were expecting a response to how Ethereum as an independent blockchain would be useful even in the face of the recent announcement of a metacoin based on Ethereum technology , this is it. If you use a metacoin on BTC, you gain the benefit of having easier back-and-forth interaction with the Bitcoin blockchain, but if you create an independent chain then you have the ability to achieve much stronger guarantees of security particularly for weak devices.
Thus, on the whole, it will certainly help the ecosystem if the same standardized EVM is available across all platforms. However, in the long term, even light clients are an ugly solution.
If we truly expect cryptoeconomic platforms to become a base layer for a very large amount of global infrastructure, then there may well end up being so many crypto-transactions altogether that no computer, except maybe a few very large server farms run by the likes of Google and Amazon, is powerful enough to process all of them.
Thus, we need to break the fundamental barrier of cryptocurrency: Of these strategies, note that only 1 is ultimately compatible with keeping the blockchain in a form anything close to what the Bitcoin and Ethereum protocols support today. We already discussed 1 and 2 in previous blog posts, and so today we will provide an introduction to some of the principles involved in 3.
The model here is in many ways similar to the Bitshares model, except that we do not assume that DPOS or any other POS will be secure for arbitrarily small chains.
The kind of policing required is simple — policing aganist double-spends and censorship attacks from local majority coalitions, and so the relevant guard mechanisms can be implemented entirely in code. However, before we get to the hard problem of inter-chain security, let us first discuss what actually turns out to be a much easier problem: Formally, the phrase can mean one of two things:.
The general idea is that contracts in one chain validate these Merkle tree proofs of contracts in the other chain. A challenge that is greater for some consensus algorithms than others is, how does the contract in a chain validate the actual blocks in another chain? For this mechanism to be viable, at least some quantity of proof of work must exist on each block, so that it is not possible to cheaply produce many blocks for which it is hard to determine that they are invalid; as a general rule, the work required by the blockmaker to produce a block should exceed the cost to the entire network combined of rejecting it.
This is needed to prevent certain classes of unavoidable long-range attacks. Hence, in general interaction is not too difficult. The larger problem, however, is security. Within this framework, there are two major paradigm choices that we can make: A centralized paradigm is essentially every chain, whether directly or indirectly, piggybacking off of a single master chain; Bitcoin proponents often love to see the central chain being Bitcoin, though unfortunately it may be something else since Bitcoin was not exactly designed with the required level of general-purpose functionality in mind.
In general, the way blockchains work is they have some scoring function for blocks, and the top-scoring block becomes the block defining the current state. Assisted scoring functions work by scoring blocks based on not just the blocks themselves, but also checkpoints in some other chain or multiple chains.
The general principle is that we use the checkpoints to determine that a given fork, even though it may appear to be dominant from the point of view of the local chain, can be determined to have come later through the checkpointing process. A simple approach is that a node penalizes forks where the blocks are too far apart from each other in time, where the time of a block is determined by the median of the earliest known checkpoint of that block in the other chains; this would detect and penalize forks that happen after the fact.
However, there are two problems with this approach:. To deal with 2 , we can say that only the valid block of a given block number with the earliest average checkpointing time can be part of the main chain, thus essentially completely preventing double-spends or even censorship forks; every new block would have to point to the last known previous block.
However, this does nothing against 1. For a block to be valid, it must be signed off on by a positive result from one or more external Schelling-vote mechanisms. Note that there are two versions of this strategy. The first is a strategy where participants vote on data availability only ie.
A clever way to force nodes to not be lazy when doing this check is to ask them to recompute and vote on the root hash of the block using a different hash function. Once all the data is available, if the block is invalid an efficient Merkle-tree proof of invalidity can be submitted to the contract or simply published and left for nodes to download when determining whether or not to count the given checkpoint.
The second strategy is less modular: This would make the process somewhat simpler, but at the cost of making it more chain-specific: Thus, you would get fewer voters providing security for your chain automatically. Regardless of which of these two strategies is used, the chain could subsidize the Schelling-vote contract on the other chain s via a cross-chain exchange.
Of course, there are solutions to this problem: However, the solution here is somewhat different: Hence, the cryptoeconomy will naturally gravitate toward schelling-vote contracts that provide better security at a lower price, and the users of those contracts will benefit from being afforded more voting opportunities.
We also need to show that scalability is actually possible. The better of the two algorithms described in the post on hypercubes, jury selection, is simple.
For every block, a random nodes are selected to vote on it. Thus, instead of every node in the network validating the block, only validate the data, and then only a few nodes need to look for actual errors, since if even one node finds an error it will be able to construct a proof and warn everyone else.
So, what is the end result of all this? Essentially, we have thousands of chains, some with one application, but also with general-purpose chains like Ethereum because some applications benefit from the extremely tight interoperability that being inside a single virtual machine offers.
Because security can be taken from all chains, a large portion of the stake in the entire cryptoeconomy would be used to protect every chain. The true benefit of this kind of scheme is just how little needs to be standardized. Each chain, upon creation, can choose some number of Schelling-voting pools to trust and subsidize for security, and via a customized contract it can adjust to any interface. Merkle trees will need to be compatible with all of the different voting pools, but the only thing that needs to be standardized there is the hash algorithm.
Different chains can use different currencies, using stable-coins to provide a reasonably consistent cross-chain unit of value and, of course, these stable-coins can themselves interact with other chains that implement various kinds of endogenous and exogenous estimators.
Services might include data availability checking, timestamping, general information provision eg. The ultimate distributed crypto-economy. Ethereum already is a bitcoin sidechain. BitShares is no longer using the multiple chain model, although alternative DPOS chains will still emerge. Smart Contracts with turing complete scripting environment has been added to the BitShares roadmap to facilitate growth and prototyping of new features. This feature combined with BitAssets should give Ethereum some serious competition in the smart contract market.
You may use these HTML tags and attributes: On Metacoin History and Multichain Introduction. The Official Ethereum Stablecoin 01st April, Ethereum scalability research and development subsidy programs 02nd January, Author BlueMeanie Posted at 3: Author Vitalik Buterin Posted at 1: Author Vlad Posted at 4: Data availability checking to prevent forks is really clever! Author Simon Edhouse Posted at 9: Author Dusty Posted at 5: What about implementing ethereum as a Bitcoin Sidechain?
Author Vitalik Buterin Posted at 9: Author Dusty Posted at Author Gandalf Posted at 5: