Ethereum

"

Ethereum est une plate-forme décentralisée qui exécute des contrats intelligents : des applications qui fonctionnent exactement comme programmées sans aucune possibilité de temps d\'arrêt, de censure, de fraude ou d\'interférence de tiers. Dans le protocole Ethereum et la chaîne de blocs, il y a un prix pour chaque opération. l\'idée générale est que pour que les choses soient transférées ou exécutées par le réseau, il faut consommer ou brûler du gaz. La cryptocurrency est appelée Ether et est utilisée pour payer le temps de calcul et les frais de transaction.

Si vous voulez gagner des récompenses en bloc à partir du réseau, vous pouvez rejoindre le réseau en tant que mineur. Suivez le lien pour un guide on how to mine Ethereum on a Windows Pc. La façon la plus simple mais un peu plus coûteuse est de acheter un contrat d\'exploitation minière d\'Ethereum. 

Ethereum est la façon dont l\'Internet était censé fonctionner. Tant que vous avez assez de fonds pour payer pour que votre code soit géré par le réseau, vos contacts seront toujours opérationnels.

Il a été financé par la foule pendant le mois d\'août 2014 par des fans du monde entier. Il est développé et maintenu par ETHDEV avec la contribution de grands esprits du monde entier. Il y a aussi une fondation Ethereum et de multiples startups travaillant avec la chaîne de blocs Ethereum.

Ethereum est actuellement sur la scène ""Homestead"" et tous ses logiciels associés sont toujours considérés comme Beta jusqu\'à la sortie de l\'étape suivante ""Metropolis"". Si vous cherchez une interface graphique pour votre portefeuille, essayez le Ethereum Wallet DApp. Il est toujours en version bêta, donc soyez prudent lorsque vous l\'utilisez.

Nos données de l\'explorateur de blocs ci-dessous sont librement fournies par etherchain.org et etherscan.io. 

""

Ethereum is a platform that is intended to allow people to easily write decentralized applications (?apps) using blockchain technology. A decentralized application is an application which serves some specific purpose to its users, but which has the important property that the application itself does not depend on any specific party existing. Rather than serving as a front-end for selling or providing a specific party\'s services, a ?app is a tool for people and organizations on different sides of an interaction use to come together without any centralized intermediary.

Contracts generally serve four purposes:

- Maintain a data store representing something which is useful to either other contracts or to the outside world one example of this is a contract that simulates a currency, and another is a contract that records membership in a particular organization.

- Serve as a sort of externally owned account with a more complicated access policy this is called a ""forwarding contract"" and typically involves simply resending incoming messages to some desired destination only if certain conditions are met for example, one can have a forwarding contract that waits until two out of a given three private keys have confirmed a particular message before resending it (ie. multisig). More complex forwarding contracts have different conditions based on the nature of the message sent the simplest use case for this functionality is a withdrawal limit that is overrideable via some more complicated access procedure.

- Manage an ongoing contract or relationship between multiple users. Examples of this include a financial contract, an escrow with some particular set of mediators, or some kind of insurance. One can also have an open contract that one party leaves open for any other party to engage with at any time one example of this is a contract that automatically pays a bounty to whoever submits a valid solution to some mathematical problem, or proves that it is providing some computational resource.

- Provide functions to other contracts essentially serving as a software library.

Contracts interact with each other through an activity that is alternately called either ""calling"" or ""sending messages"". A ""message"" is an object containing some quantity of ether (a special internal currency used in Ethereum with the primary purpose of paying transaction fees), a byte-array of data of any size, the addresses of a sender and a recipient. When a contract receives a message it has the option of returning some data, which the original sender of the message can then immediately use. In this way, sending a message is exactly like calling a function.

""

Sandwich complexity model: the bottom level architecture of Ethereum should be as simple as possible, and the interfaces to Ethereum (including high level programming languages for developers and the user interface for users) should be as easy to understand as possible. Where complexity is inevitable, it should be pushed into the ""middle layers"" of the protocol, that are not part of the core consensus but are also not seen by end users - high-level-language compilers, argument serialization and deserialization scripts, storage data structure models, the leveldb storage interface and the wire protocol, etc. However, this preference is not absolute.

Freedom: users should not be restricted in what they use the Ethereum protocol for, and we should not attempt to preferentially favor or disfavor certain kinds of Ethereum contracts or transactions based on the nature of their purpose. This is similar to the guiding principle behind the concept of ""net neutrality"". One example of this principle not being followed is the situation in the Bitcoin transaction protocol where use of the blockchain for ""off-label"" purposes (eg. data storage, meta-protocols) is discouraged, and in some cases explicit quasi-protocol changes (eg. OP_RETURN restriction to 40 bytes) are made to attempt to attack applications using the blockchain in ""unauthorized"" ways. In Ethereum, we instead strongly favor the approach of setting up transaction fees in such a way as to be roughly incentive-compatible, such that users that use the blockchain in bloat-producing ways internalize the cost of their activities (ie. Pigovian taxation).

Generalization: protocol features and opcodes in Ethereum should embody maximally low-level concepts, so that they can be combined in arbitrary ways including ways that may not seem useful today but which may become useful later, and so that a bundle of low-level concepts can be made more efficient by stripping out some of its functionality when it is not necessary. An example of this principle being followed is our choice of a LOG opcode as a way of feeding information to (particularly light client) dapps, as opposed to simply logging all transactions and messages as was internally suggested earlier - the concept of ""message"" is really the agglomeration of multiple concepts, including ""function call"" and ""event interesting to outside watchers"", and it is worth separating the two.

Have No Features: as a corollary to generalization, the dev team often refuses to build in even very common high-level use cases as intrinsic parts of the protocol, with the understanding that if people really want to do it they can always create a sub-protocol (eg. ether-backed subcurrency, bitcoin/litecoin/dogecoin sidechain, etc) inside of a contract. An example of this is the lack of a Bitcoin-like ""locktime"" feature in Ethereum, as such a feature can be simulated via a protocol where users send ""signed data packets"" and those data packets can be fed into a specialized contract that processes them and performs some corresponding function if the data packet is in some contract-specific sense valid.

Non-risk-aversion: the dev team is okay with higher degrees of risk if a risk-increasing change provides very substantial benefits (eg. generalized state transitions, 50x faster block times, consensus efficiency, etc)

" Visitez le site web open_in_new

Date	Prix	Volume