Ethereum (ETH) - POW/POS - Ethash
Ethereum Debit Card
Ethereum debit card is a card that links directly to your Ethereum and keeps your money protected.
Ethereum debit card allows you to pay, simply and securely, in person, online, over the phone or through the mail. UQUID account help you loading money into your card, keep track of your spending and balance.
- Ethereum debit card can be used whether you're home or away, at any time of day or night, so there's no need for cash
- Wherever you use Ethereum debit card, you are fully protected. If, for example, you're unfortunate enough to book a holiday with an airline or travel agent that becomes insolvent, you'll generally get your money back. Similarly, if you order something that is not delivered, not as described, or arrives faulty or damaged, you’ll receive a full refund
- It's a safe, secure way to pay, backed up by proven security technologies like Verified by Visa and Chip and PIN
- It's more versatile than cash, and if you lose it, you can order a replacement
- As millions of VISA customers around the world have found, you can easily use Ethereum debit card everyday, everywhere, for everything
5 Reasons to choose UQUID Ethereum debit card
NO FEE DEPOSIT
Instant load with 0% fee
We do not require for ID or verification.
MULTI CARDS BUY SUPPORT
You can get unlimited cards with only 1 UQUID account
FAST AND FREE DELIVERY
Our card ships free to 178 + countries with no fees. Typically within 2-3 working days
You can link your card with your address information. Get easy for shopping at Amazon, Uber, Skrill ...
An Update on Integrating Zcash on Ethereum (ZoE)
Members of the Ethereum R&D team and the Zcash Company are collaborating on a research project addressing the combination of programmability and privacy in blockchains. This joint post is being concurrently posted on the Zcash blog, and is coauthored by Ariel Gabizon (Zcash) and Christian Reitwiessner (Ethereum).
Ethereum’s flexible smart contract interface enables a large variety of applications, many of which have probably not yet been conceived. The possibilities grow considerably when adding the capacity for privacy. Imagine, for example, an election or auction conducted on the blockchain via a smart contract such that the results can be verified by any observer of the blockchain, but the individual votes or bids are not revealed. Another possible scenario may involve selective disclosure where users would have the ability to prove they are in a certain city without disclosing their exact location. The key to adding such capabilities to Ethereum is zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs) – precisely the cryptographic engine underlying Zcash.
One of the goals of the Zcash company, codenamed Project Alchemy, is to enable a direct decentralized exchange between Ethereum and Zcash. Connecting these two blockchains and technologies, one focusing on programmability and the other on privacy, is a natural way to facilitate the development of applications requiring both.
As part of the Zcash/Ethereum technical collaboration, Ariel Gabizon from Zcash visited Christian Reitwiessner from the Ethereum hub at Berlin a few weeks ago. The highlight of the visit is a proof of concept implementation of a zk-SNARK verifier written in Solidity, based on pre-compiled Ethereum contracts implemented for the Ethereum C++ client. This work complements Baby ZoE , where a zk-SNARK precompiled contract was written for Parity (the Ethereum Rust client). The updates we’ve made involved adding tiny cryptographic primitives (elliptic curve multiplication, addition and pairing) and implementing the rest in Solidity, all of which allows for a greater flexibility and enables using a variety of zk-SNARK constructions without requiring a hard fork. Details will be shared as they are available later. We tested the new code by successfully verifying a real privacy-preserving Zcash transaction on a testnet of the Ethereum blockchain.
The verification took only 42 milliseconds, which shows that such precompiled contracts can be added, and the gas costs for using them can be made to be quite affordable.
What can be done with such a system
The Zcash system can be reused on Ethereum to create shielded custom tokens. Such tokens already allow many applications like voting, (see below) or simple blind auctions where participants make bids without the knowledge of the amounts bid by others.
If you want to try compiling the proof of concept, you can use the following commands. If you need help, see https://gitter.im/ethereum/pri...
git clone https://github.com/scipr-lab/libsnark.git cd libsnark sudo PREFIX=/usr/local make NO_PROCPS=1 NO_GTEST=1 NO_DOCS=1 \ CURVE=ALT_BN128 \ FEATUREFLAGS="-DBINARY_OUTPUT=1 -DMONTGOMERY_OUTPUT=1 \ -DNO_PT_COMPRESSION=1" \ lib install cd .. git clone --recursive -b snark https://github.com/ethereum/cpp-ethereum.git cd cpp-ethereum ./scripts/install_deps.sh && cmake . -DEVMJIT=0 -DETHASHCL=0 && make eth cd .. git clone --recursive -b snarks https://github.com/ethereum/solidity.git cd solidity ./scripts/install_deps.sh && cmake . && make soltest cd .. ./cpp-ethereum/eth/eth --test -d /tmp/test # And on a second terminal: ./solidity/test/soltest -t "*/snark" -- --ipcpath /tmp/test/geth.ipc --show-messages
We also discussed various aspects of integrating zk-SNARKs into the Ethereum blockchain, upon which we now expand.
Deciding what precompiled contracts to define
Recall that a SNARK is a short proof of some property, and what is needed for adding the privacy features to the Ethereum blockchain are clients that have the ability to verify such a proof.
In all recent constructions, the verification procedure consisted solely of operations on elliptic curves. Specifically, the verifier requires scalar multiplication and addition on an elliptic curve group, and would also require a heavier operation called a bilinear pairing.
As mentioned here, implementing these operations directly in the EVM is too costly. Thus, we would want to implement pre-compiled contracts that perform these operations. Now, the question debated is: what level of generality should these pre-compiled contracts aim for.
The security level of the SNARK corresponds to the parameters of the curve. Roughly, the larger the curve order is, and the larger something called the embedding degree is, and the more secure the SNARK based on this curve is. On the other hand, the larger these quantities are, naturally the more costly the operations on the corresponding curve are. Thus, a contract designer using SNARKs may wish to choose these parameters according to their own desired efficiency/security tradeoff. This tradeoff is one reason for implementing a pre-compiled contract with a high level of generality, where the contract designer can choose from a large family of curves. We indeed began by aiming for a high level of generality, where the description of the curve is given as part of the input to the contract. In such a case, a smart contract would be able to perform addition in any elliptic curve group.
A complication with this approach is assigning gas cost to the operation. Yu must assess, merely from the description of the curve, and with no access to a specific implementation, how expensive a group operation on that curve would be in the worst case. A somewhat less general approach is to allow all curves from a given family. We noticed that when working with the Barreto-Naehrig (BN) family of curves, one can assess roughly how expensive the pairing operation will be, given the curve parameters, as all such curves support a specific kind of optimal Ate pairing. Here’s a sketch of how such a precompile would work and how the gas cost would be computed.
We learned a lot from this debate, but ultimately, decided to “keep it simple” for this proof of concept: we chose to implement contracts for the specific curve currently used by Zcash. We did this by using wrappers of the corresponding functions in the libsnark library, which is also used by Zcash.
Note that we could have simply used a wrapper for the entire SNARK verification function currently used by Zcash, as was done in the above mentioned Baby ZoE project. However, the advantage of explicitly defining elliptic curve operations is enabling using a wide variety of SNARK constructions which, again, all have a verifier working by some combination of the three previously mentioned elliptic curve operations.
Reusing the Zcash setup for new anonymous tokens and other applications
As you may have heard, using SNARKs requires a complex setup phase in which the so-called public parameters of the system are constructed. The fact that these public parameters need to be generated in a secure way every time we want to use a SNARK for a particular circuit significantly, hinders the usability of SNARKs. Simplifying this setup phase is an important goal that we have given thought to, but haven’t had any success in so far.
The good news is that someone desiring to issue a token supporting privacy-preserving transactions can simply reuse the public parameters that have already been securely generated by Zcash. It can be reused because the circuit used to verify privacy-preserving transactions is not inherently tied to one currency or blockchain. Rather, one of its explicit inputs is the root of a Merkle tree that contains all the valid notes of the currency. Thus, this input can be changed according to the currency one wishes to work with. Moreover, if it is easy to start a new anonymous token. You can already accomplish many tasks that do not look like tokens at first glance. For example, suppose we wish to conduct an anonymous election to choose a preferred option amongst two. We can issue an anonymous custom token for the vote, and send one coin to each voting party. Since there is no “mining”, it will not be possible to generate tokens any other way. Now each party sends their coin to one of two addresses according to their vote. The address with a larger final balance corresponds to the election result.
A non-token-based system that is fairly simple to build and allows for “selective disclosure” follows. You can, for example, post an encrypted message in regular intervals, containing your physical location to the blockchain (perhaps with other people’s signatures to prevent spoofing). If you use a different key for each message, you can reveal your location only at a certain time by publishing the key. However, with zk-SNARKs you can additionally prove that you were in a certain area without revealing exactly where you were. Inside the zk-SNARK, you decrypt your location and check that it is inside the area. Because of the zero-knowledge property, everyone can verify that check, but nobody will be able to retrieve your actual location.
The work ahead
Achieving the mentioned functionalities – creating anonymous tokens and verifying Zcash transactions on the Ethereum blockchain, will require implementing other elements used by Zcash in Solidity.
For the first functionality, we must have an implementation of tasks performed by nodes on the Zcash network such as updating the note commitment tree.
For the second functionality, we need an implementation of the equihash proof of work algorithm used by Zcash in Solidity. Otherwise, transactions can be verified as valid in themselves, but we do not know whether the transaction was actually integrated into the Zcash blockchain.
Fortunately, such an implementation was written; however, its efficiency needs to be improved in order to be used in practical applications.
Acknowledgement: We thank Sean Bowe for technical assistance. We also thank Sean and Vitalik Buterin for helpful comments, and Ming Chan for editing.
Ethereum swarm start script (German)
Geth V 1.5.8 Released with few bug fixes
- Gas estimation now does binary search to find the right amount of gas even in complex refund conditions where the required gas is higher that the final consumption. (#3587)
- ECDSA signing uses a deterministic nonce. This change affects transaction signing. (#3561)
- A new developer tool,
cmd/wnode, allows testing the Whisper v5 protocol. (#3580)
Binaries and mobile libraries are available on our download page.
Ethereum Wallet and Mist 0.8.9 Release - "The Wizard"
Full fledged Windows Installers: This version includes the new installer for Windows created by @tgerring, which lets you choose the directory to install Mist in, as well as the
data-dirof the ethereum node. It's one installer for both 32 and 64-bit computers.
Note that the
data-diris set as a parameter in Mist shortcut properties, at the installation stage; not in Mist's preferences.
App Signing: Mist for Mac OS X is now signed by the Ethereum Foundation.
Solidity Compiler: Now featuring version 0.4.8.
Remix IDE option on menu
0.8.9 also has a new menu entry to open Remix IDE, so now you have
plenty of room to write your contracts without leaving Mist. Head to
Develop > Open Remix IDE.
A test suite is born: It was about time for Mist to have a solid set of integration tests. Now we're starting to kill this debt with a Spectron#1571.
See the full changelog at Milestone 0.8.9.
Ethereum-Wallet-macosx-0-8-9.dmg a244daa82abd4e607672dc375e5b5060266104f81f12045e199265e92655c8c3 Ethereum-Wallet-linux32-0-8-9.deb 0d37b4710b6eab39467df4dd3587c693c40f54cae919e815693cb14c92836586 Ethereum-Wallet-linux32-0-8-9.zip 9b61e43c0ec1655de04382f67c99f518cf854bc57f89cd7a63d9d93752723d01 Ethereum-Wallet-linux64-0-8-9.deb 53c6a839859c5ba824fbaff427326e05e6b238d05387ff61a83041e9bfb81dfc Ethereum-Wallet-linux64-0-8-9.zip 2ee9a5d3ac0a4eb944f9d397392a77e7fda45439ae787e13684bdef58d29b538 Ethereum-Wallet-win32-0-8-9.zip 7df2f1e8ba097aefe65fe8310024e61ccecc6b91cf34f916d38f396c1ff37fb0 Ethereum-Wallet-win64-0-8-9.zip a46f09c1b63e63c8e42fea96bc184dc508381cfe29672c6417d37230966a6493
mist-installer-0-8-9.exe 959bbe051f63f3a4e2336b69308e9b6a5e8564b68ae361c3aad3d55cb03e6ee3 Mist-linux32-0-8-9.deb 97b2ee47159bf32772fe21704f72333d0a597181282ec546f43494546f48e417 Mist-linux32-0-8-9.zip ab62752d235bafc878bd68e461be45c6d45d7d746883c6b3b79fdddf4ea1c15b Mist-linux64-0-8-9.deb 9657a9261e25173087eda29499db88aed7adcb4344ead914eaa692093c55ba62 Mist-linux64-0-8-9.zip 2d19445afc242b6337c5681627b9a21aca5ba5b7aa60cc7ba683e2f5d9bea6bb Mist-macosx-0-8-9.dmg 3d09306f8e53e315da73571d52adf15adfd4c30e43a8b4251099bc5f7aeda986
- Full fledged Windows Installers: This version includes the new installer for Windows created by @tgerring, which lets you choose the directory to install Mist in, as well as the
Ethereum (ETH) New Exchange:
Ethereum (ETH) New Exchange:
ETH LISTED ON:
Ethereum IoT Project Wins $100k in Dubai Blockchain Hackathon
A startup building an ethereum-based platform for IoT applications has won $100,000 at a blockchain hackathon in Dubai
.For more details log http://www.xbt.money/ethereum-...
Ethereum Parity fast sync for Ropsten testnet
Switch from Geth to Parity
There appears to be a bug with Geth syncing with Ropsten testnet on some systems. This was the case with attempting to sync the full blockchain and with the –fast flag (including using -cache=512, etc) and despite having a high powered computer with a SSD .
After trying various workarounds for several days and getting advice on the Geth Gitter channelParity.
I wish I had done it sooner. Details on the the Parity WikiParity Gitter channel.
$ bash <(curl https://get.parity.io -Lk) $ parity --warp --chain ropsten
or for the live env
$ parity --warp
$ sudo apt-get install nodejs $ npm install web3
$ node > Web3 = require("web3") > web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));
After this point, you’ll be able to use the web3 API from with this environment, e.g.:
> web3.eth.blockNumber 743397
Exit that and create a new file called parityNode.js with the following:
#!/usr/bin/node repl = require("repl"); Web3 = require("web3"); context = repl.start("$ ").context; context.web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));
You can then start node.js using that script and access Parity via web3 immediately:
$ chomd 744 parityNode.js $ ./parityNode.js > web3.eth.blockNumber 743397
Technologist and Entrepreneur on an adventure to see how Blockchain and AI will change the world!
Ethereum R&D Roundup: Valentine’s Day Edition
During the last month and a half, the Ethereum core development and research teams have been building upon the progress made in the last year, and with the specter of last year’s security issues now well behind us, work has begun in full force on implementing the Metropolis hard fork.
First, ongoing progress on the collaboration with the Zcash team and the implementation of zk-SNARKs:
- The full series of “zk-SNARK explainer” posts from myself is now finished, see https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649https://medium.com/@VitalikButerin/exploring-elliptic-curve-pairings-c73c1864e627 and https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6https://blog.ethereum.org/2017/01/19/update-integrating-zcash-ethereum/
On the proof of stake front, myself and Vlad and others have continued to solidify the Casper specification and converge on a roadmap. A key focus of our work has been on a notion of “protocol armor”, which can turn many classes of traditional Byzantine-fault-tolerant consensus algorithms into “attributable-fault consensus algorithms”, where if there is a protocol failure then not only do you know that a large number of validators were faulty, but you also know whom to blame. The work has not yet been fully written out, though it will be further formalized and presented soon, and anyone interested is free to follow along at https://gitter.im/ethereum/casper-scaling-and-protocol-economics.
A post on parametrizing Casper was written here: https://medium.com/@VitalikBut...
We had twomeetings, and have approved the following EIPs for likely inclusion into Metropolis:
- http://github.com/ethereum/EIPs/issues/86http://github.com/ethereum/EIPs/issues/100 (uncle mining incentive fix)
- https://github.com/ethereum/EIPs/issues/196https://github.com/ethereum/EIPs/issues/197 (elliptic curve pairings, the key ingredient for on-chain zk-SNARK verification)
- https://github.com/ethereum/EIPs/issues/198https://github.com/ethereum/EIPs/pull/206 (REVERT opcode, equivalent to the “throw” keyword in Solidity but without burning extra gas)
- https://github.com/ethereum/EI... (blockhash refactoring, serving the triple duty of (i) simplifying consensus logic, (ii) allowing the BLOCKHASH opcode to refer much further back, and (iii) enabling much more efficient and secure light client initial-syncing protocols)
Additionally, there were a few changes to the EIP process itself: https://www.reddit.com/r/ether...
Work on Mist, Swarm, ENS and associated infrastructure is continuing at a rapid pace; Swarm is now at the stage where it can serve the wallet app, though the incentivization logic is not yet in place.
Work on programming languages is also moving forward:
- Solidity is adding a fully specified way to access the compiler input, settings and output: https://solidity.readthedocs.i...
- There are plans (not yet completed) to add an intermediate language to Solidity to help with understanding what the compiler does and auditing compiler output
- In the community, the fp-ethereum functional programming initiative got some attention
- Viper saw another round of improvements, including support for unit types (timestamp, timedelta, wei, wei per second, etc), bytearrays and more builtin functions: https://github.com/ethereum/viper/commits/masterdevelopment environment Remix added much more powerful debugging support
Work on implementations is progressing:
- The cpp-ethereum project is experimenting with the performance of the EVM. Some results suggest that the EVM might be able to get up to a small linear factor close to “raw metal” with the more structured EVM 1.5 modelhttps://github.com/ethereum/go-ethereum/releases/tag/v1.5.9
- Work on integrating the recent pyethereum changes into pyethapp is continuing: https://github.com/ethereum/py...
We wish everyone a happy Valentine’s day!
Ethereum dairy of Week 7
- EVM Fuzzing https://github.com/ethereum/go-ethereum/pull/3672https://github.com/ethereum/go-ethereum/pull/3654
bugcommand to open issues on GH https://github.com/ethereum/go-ethereum/pull/3684https://github.com/ethereum/go-ethereum/pull/3680
- Fix Ledger on OSX, require less fuss on Windows https://github.com/ethereum/go-ethereum/pull/3681https://github.com/karalabe/hid
- Investigating Go 1.8 build issues on ARM64 https://github.com/golang/go/issues/19137
- implemented request distributor & fixed blocking requests https://github.com/ethereum/go-ethereum/pull/3660
StateTests converted to blockchain tests and now running on hive. Found a couple of issues which are now fixed. Metropolis tests are on the way. CPP ropsten node is now on morden.io
- chunk integrity check improvements https://github.com/ethereum/go-ethereum/pull/3665https://github.com/ethereum/go-ethereum/pull/3651
- swarm process catches SIGTERM gracefully shuts down https://github.com/ethereum/go-ethereum/pull/3649https://github.com/ethereum/go-ethereum/pull/3645
- proximity order trees: https://github.com/ethereum/go-ethereum/pull/3644
- Improvement in the internal API
- Breakpoint Manager
- Debugging using source location (and not only bytecode)
- Writing remix tutorial
- integration with geth
European Ethereum Development Conference: Recap
For those of you who were lucky enough to be at EDCON in Paris last week, it was a real pleasure — it never ceases to amaze us the speed at which this ecosystem is developing, and the openness of the Ethereum community.
Jarrad’s talk, entitled “Status: Lowering Ethereum’s Barriers to Entry,” which outlines our roadmap for the year will be available on our YouTube Channel in the coming days.
Product Announcements & Development Updates
Below is a very brief summary of some of the talks at the event. By no means is this a complete list, and unfortunately we could only find slides for a handful of them, so have tried to include links to each project website where applicable.
Intro to Crypto-economics — Vitalik Buterin. View the slides here.
Casper — Vlad Zamfir. View the slides here.
Ethereum Governance Mechanism — Christoph Jentzsch. View the slides here.
Ethereum Name Service — Nick Johnson. “Distributed Naming with ENS”. Set to be released on Mainnet shortly.
Trustlines — Heiko Hees and the Team at Brainbot. Based on the original Ripple idea, and developed the team behind Raiden, Trustlines enables path of trust relationships that can be chained together in such a way to have payments between participants on the network that don’t know each other.
Omise Go — Thomas Greco announced Omise Go, an E-Wallet platform, aimed primarily at the unbanked populations in Asia, and we can expect to see a token-sale to support the platform in Q2.
JAAK Announce MΞTA — Vaughn McKenzie presented MΞTA, a decentralized open network, backed by Ethereum and Swarm, which enables organizations to capture, store, verify and communicate commercial metadata.
Aragon — Luis Cuende and Jorge Izquierdo, the friendly team behind Aragon, gave us a glimpse of how companies and organizations can be formed and governed in the future.
Alice.si —Raphaël Mazet. Hyper-transparent philanthropy, where donors only pay for results. The concept being Alice can help charities raise funds in a way where donors only pay for the successful social programmes.
StabL — Hadrien Charlanes & Vincent Eli. StabL, a Consensys spoke, aims to provide DApps and individuals access to stable values on the blockchain, an important piece of the infrastructure.
SmartContract.com — Sergey Nazarov “Give your smart contracts reliable access to critical data feeds, any web API and widely accepted payments.”
SmartPool — Loi Lee. SmartPool aims to replace the centralized pool operators with smart contracts, resulting in greater decentralization of pools, low fees, and mitigation of the transaction censorship threat. View the slides here.
Akasha — “You are paying free services in Microviolations of your privacy." Mihai Alisie presented updates on Akasha, a decentralized social media network using Ethereum + IPFS.
William Mougayar ‘State of the Ethereum Ecosystem’ — A special thanks to William for letting us do another quick presentation at the Investor Forum Sub-conference! View the slides here.
ETHOn — Johannes Pfeffer presents“EthOn: Introducing Semantic Ethereum.”Read the blog post.
Streamer — Henri Pihkala. “Connecting Ethereum with the real world: How to easily create data-driven smart contracts.”
Ledgys.net — Quentin de Beauchesne.“Ledgys Data Network : A Decentralized Data Marketplace.”
Gnosis — Stefan George. “Fund Security — How to Keep Assets Safe on Ethereum.”
Oraclize — Thomas Bertani. “The Oraclize Oracle Service: Authenticity Proofs.”
ABDK Consulting — Dmitry Khovratovich. “Secure Token Development and Deployment.” View the slides here.
Ledger Labs — Jeff Coleman.“Counterfactual instantiation: an object oriented approach to fully abstracting state channels.”
Parity — Gavin Wood.
“Battling the blackhats” — Joseph Chow.
“The ‘Shanghai’-attacks” — Martin Holst Swende, Ethereum Core.
“Towards an Extensible Blockchain” — Martin Becze & Alex Beregszaszi, Ethereum Core.
“Blockchains: the New Home of Formally Verified Software” — Yoichi Hirai, Ethereum Core.
A Few Photos…
A highlight for us, the PoS Panel which concluded Day 1, moderated by Rick Dudley
Heiko Hees presenting TrustLines
Ethereum Foundation Researcher Loi Lee presenting SmartPool
Stabl is a stable currency project, from Consensys
Join The Status Community
For more details about Exchange Log:http://cryptocentral.info/topi...
Interview :Vitalik Buterin: DAO Lessons, Casper and Blockchain Interoperability
Introduction to Cryptoeconomics - Vitalik Buterin
Ethereum’s Road Map For 2017
Hudson Jameson of the Ethereum Foundation speaks on Ethereum's roadmap, along with details about the ecosystem and community.
At a recent blockchain-focused Bitcoin Conference in 2014. Following this public announcement, the Ethereum blockchain went through two phases:
The initial release of the Ethereum network that went live in January 2014. It was a bare bones beta release that allowed developers to learn, experiment, mine Ether (ETH), and begin building Dapps and tools.
The second major version of the Ethereum platform and the first production release of Ethereum, which was made public in March 2016. It included several protocol revisions and a network change that provided the ability for further network upgrades and sped up transactions.
Jameson made the point that Ethereum is essentially two years old. However, within this timeframe, much has occurred within the ecosystem and community. Light-clients, such as Status, a mobile Ethereum Dapp that will soon be available for iPhone and Android, are advancing consumer adoption by allowing users to access the usage data they need without downloading the entire Ethereum blockchain.
Smart contract safety and formal verification were mentioned as “hot topics” in the blockchain space, due to exploited flaws in blockchain projects that have garnered media attention. Jameson stated that developers within the Ethereum community “are doing groundbreaking cryptographic research on how to secure smart contracts.”
Businesses and enterprise use of Ethereum in banking, energy, and tracking use cases have also exploded onto the scene, with many independent consortiums forming outside of big bank initiatives, such as R3.
Where Ethereum Is Going
ETA: 3-6 Months
The next phase of Ethereum development will be “Metropolis,” which is intended to provide greater flexibility to smart contract developers. According to Jameson, smart contracts will eventually be able to automatically pay their own fees, eliminating the need for users to externally fund smart contracts themselves.
Current Ethereum users must download the Ethereum client that contains the blockchain, logic layer, storage layer, and consensus layer, which are all packaged together. In order to modify any of these components, users must deploy softforks or hardforks, while enterprises must “mutilate the code,” as Jameson put it, to input their own consensus mechanisms.
According to Jameson, “Ethereum abstraction is the ability to swap out consensus protocols within Ethereum – the ability to have different types of account security.”
Currently, users must access the account security mechanisms of the bitcoin and Ethereum blockchains to create public or private keys. In the near future, users will be able to use Lamport signatures or RSA for specific use cases, like private settings or consortium blockchains. According to Jameson, this interconnectedness makes Ethereum incredibly powerful.
zk SNARKs (zero-knowledge Succinct Non-interactive Argument of Knowledge), or “zero-knowledge proofs,” provide a method for anonymous transactions of value. As previously reported by ETHNews:
“The idea of zk-SNARKs is that they allow verification of the correctness of computations, without a verifier having to execute those computations, or even learn what was actually executed. Using zk-SNARKs, a verifier can confirm that a computation happened correctly, with ‘zero-knowledge’ of the computation.”
Because of the public nature of a distributed ledger, many businesses are reluctant to deploy blockchain solutions for fear of exposing confidential or sensitive information. The use of zk SNARKs would essentially solve this dilemma.
Jameson went on to say that Zcash is the first financial system with a widely known public blockchain (zk SNARKs system), and that these features will be included with the release of Metropolis. Ethereum abstraction will help support possibilities surrounding zk SNARKs, as much of the groundwork has already been explored and accomplished by Ethereum developers.
Post-Metropolis And Serenity
ETA: Not Finalized
Although Jameson made no predictions for the release of “Serenity,” he did state, “this is going to be when you know the really big stuff hits.”
A key goal of this phase will include the transition from proof-of-work (mining) to proof-of-stake (virtual mining) using the block times that will speed up transactions exponentially as the technology advances. It is theorized that blockchain sharding will aid in the decreasing of block times and much research is currently being conducted in this field.
Jameson also discussed the various categories of software that have been influenced by or built using the Ethereum blockchain. These categories include enterprise, clients, developer tools, Dapps, and the community.
The final section of the presentation, “What Makes Ethereum Different?” discussed the benefits and unique qualities of Ethereum that have spurred much of the innovation within the blockchain space. Focusing on the growth of developers, alpha testers, and amount of Dapps built on the network, Jameson conveyed his passion and belief that the Ethereum community is both special and inclusive.
“A lot of people in the Ethereum community really like ‘doge.’ To me, that kind of shows a sense of laid-backness, a sense of being able to take humor in things – you can make jokes about state channels and make jokes about silly things going on in cryptocurrency battles and stuff.”
Readers are encouraged to follow ETHNews for developments within the Ethereum ecosystem.
Los Silva is a writer and filmmaker who has collaborated
with tech and design companies. His interest in Ethereum stems from
emerging creative applications that allow artists control of their work
through blockchain technology.
Walkthrough of an Ethereum Improvement Proposal (EIP)
Ethereum, being an open source project, tracks and discusses new ideas for the protocol through the Ethereum Improvement Proposal (EIP) system atGithub. Here we take a look at EIP#155Simple replay attack protection. Before EIP#155, there are 6 inputs to an Ethereum transaction. Namely,
nonce gasPrice gasLimit to value data
From our previous article regarding transactions, we have received quite a number of questions regarding what is the transaction object and exactly what values are hashed. To answer that, the values of the 6 inputs can be stored in an array in order without their names. Recursive Length Prefix (RLP) encoding is then applied to obtain a portable representation of the transaction.Keccak-256 is then used to hash it. Here are some more explanation andimplementation of RLP. In this article we will also directly use the RLP and hash functions instead of convenient functions to better illustrate this point.
One can easily observe that the transaction is not chain specific, meaning if you are on a private Ethereum network, someone could take your transaction on that network and broadcast it to the public network and it will be valid. Thus if you use the same addresses in different networks, it could lead to unintended sending of transactions. A simple fix was used in the Morden public testnet by having all transactions start with a huge nonce instead of 0. EIP#155 aims to fix this issue in a more general way by including a
chainIdin the transaction where the main public network have a
chainIdof 1 and the new Ropsten public testnet have it as 3. Therefore you should use other numbers for your own network. However old transactions are still valid for backward compatibility.
Here we will go through the example given in the EIP. We are using nodejs so we first create a file
tx.jsand require the dependencies.
var Web3 = require('web3'); var web3 = new Web3(); var util = require('ethereumjs-util');
The example given is
var transaction = [ web3.toHex(9), web3.toHex(20000000000), web3.toHex(21000), '0x3535353535353535353535353535353535353535', web3.toHex('1000000000000000000'), '', web3.toHex(1), 0x0, 0x0 ];
contrast this with an old transaction
var transactionOld = [ web3.toHex(9), web3.toHex(20000000000), web3.toHex(21000), '0x3535353535353535353535353535353535353535', web3.toHex('1000000000000000000'), '' ];
Next we will RPL, hash it and print the results
var encoded = util.rlp.encode(transaction); console.log(util.bufferToHex(encoded)); //0xec098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a764000080018080
var encodedHash = util.sha3(encoded); console.log(util.bufferToHex(encodedHash)); //0xdaf5a779ae972f972197303d7b574746c7ef83eadac0f2791ad23db92e4c8e53
Next we sign and add to the
vvalue of the signature as per the EIP
var p = new Buffer('4646464646464646464646464646464646464646464646464646464646464646', 'hex'); var sig = util.ecsign(encodedHash, p); sig.v += 1 * 2 + 8; console.log(util.bufferToHex(sig.v)); console.log(util.bufferToHex(sig.r)); console.log(util.bufferToHex(sig.s)); //0x25 //0x28ef61340bd939bc2195fe537567866003e1a15d3c71ff63e1590620aa636276 //0x67cbe9d8997f761aecb703304b3800ccf555c9f3dc64214b297fb1966a3b6d83
Thus the signed transaction becomes
var signedTransaction = util.rlp.encode([ web3.toHex(9), web3.toHex(20000000000), web3.toHex(21000), '0x3535353535353535353535353535353535353535', web3.toHex('1000000000000000000'), '', sig.v, sig.r, sig.s ]); console.log(util.bufferToHex(signedTransaction)); //0xf86c098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a76400008025a028ef61340bd939bc2195fe537567866003e1a15d3c71ff63e1590620aa636276a067cbe9d8997f761aecb703304b3800ccf555c9f3dc64214b297fb1966a3b6d83
So we have gone through the modifications of this EIP. As mentioned earlier, transactions created by old libraries are still valid, so how many such transactions are still created on the live net? There is a simple way to find out since transactions created by old libraries have a
0x1cwhile transactions created by new libraries have the values of
0x26. Create a new file
find.jsand run the following code to see this.
var Web3 = require('web3'); var web3 = new Web3(new Web3.providers.HttpProvider('https://mainnet.infura.io/')); console.log(web3.eth.getTransaction('0x4b420c328f11bbf4cc0043af7bd8b170026e97ef4261e93354bf080c2d04ea6d').v); //0x26 console.log(web3.eth.getTransaction('0x79fbfd4daa09f7947595f6c1e3d8e78b4032cf64d105292b10f61ebb067d2bcf').v); //0x1b
Using this methodology, we searched through every transaction from block 3,153,001 to 3,159,000, which is 6,000 blocks or about 1 day’s worth of blocks. The results are
blocks: 6,000 transactions: 53,114 0x1b, 0x1c: 6,856 (12.9%) 0x25, 0x26: 46,258 (87.1%)
There is still a significant number of old transactions, so please update your client/library to prevent your transactions from being replayed.
Now we have gotten to know a little bit more about EIP#155!
Ethereum and smart contracts have huge potential to disrupt many industries. There are many resources online and you can find a few below to continue your journey on exploring Ethereum!
If you have any issues regarding this article, you can raise it at our Github under the nightlyHacks repo.
Get to know a little bit of what we are doing by reading our whitepaper!
https://codetract.io/CodeTract is a startup focused on building smart contracts enforced by blockchains
This is a quick resume to learn the very basic concepts, setup your development environment and be able jump quickly into deeper exploration.
Blockchains: distributed systems in which a state/block is shared and computed across all the members of the network.
Bitcoin vs Ethereum: the first was designed as a blockchain network with the specific purpose of sharing a cryptocurrency, the second was designed as a blockchain network to share whatever concepts you want to develop on top of it.
Smart Contracts: Ethereum works based in Contracts that are code defined rules that manage the behavior and limits of your creations and how someone can interact with them.
Dapps: decentralized apps that store a contract in the Ethereum blockchain network in order to reflect some particular state and behavior.
Gas: concept used to define the computing costs that different members use in order to solve the methematical calculations of the operation of the network and its contracts. Payed in Ether, a cryptocurrency defined for that purpose in the context of Ethereum.
TestRPC: Node.js based Ethereum client for testing and development.
Truffle Framework: a development framework that simplifies how contracts are compiled, deployed and tested.
SETUP THE DEMO APP:
Go to the Dapp repo and follow the instructions to make it work, it only takes a couple of minutes: https://github.com/armova/Basic-Truffle-Dapp
You will be running testRPC as a local Ethereum network, using Truffle to compile and deploy the contract to testRPC, building the code with Webpack and finally running the Dapp in your browser and being able to make some basic modifications to the state of the contract. See the transactions being computed in the testRPC simulated Ethereum network.
Now that you have a basic model running check out this additional resources:
Suggested reading: Ethereum Solidity, intro to smart contracts
Entrepreneur, Business and Software Developer, loves Open paradigms,
ancient wisdom, sea & jungle, maker movement and history.
11 Best Ethereum Development Tools to Grow Your Stack
Blockchain tech is getting chief officers hot and heavy. When it’s your turn to show them your stack, will you distress or impress?
Here’s 11 tools for building on the Ethereum blockchain
1. Mist — nothing gets them going like pulling out your wallet
Use Mist to create wallets you won’t lose right when your Uber is pulling up
Store Ether, send transactions, deploy contracts and more with Mist. You can use the native application to play around on the blockchain or testnet while you get the hang of this whole blockchain thing. Super useful for quick transactions.
2. Geth — when it’s time to bust a nodeDrop that GUI down low
When you’re ready to ditch the training wheels, switching to the command line will make you look like a real hacker. Geth can do anything Mist can do plus some important functionality like serving as an RPC endpoint to connect to the blockchain over http.
3. Parity — promote your side client to baeIt’s my parity I can cry if I want to
Parity is an ethereum client written in the new low level language Rust. Formed by Dr. Gavin Wood, the former CTO of Ethereum, this client is a fast, lightweight way to run an Ethereum node. Run Parity and hop over tolocalhost:8080 to play around in their web UI. Honestly, it’s a pain in the ass to install, but once it’s up and running Parity is a big upgrade from Geth.
4. MetaMask — furry fun keeps chrome interestingThe foxy doggo chrome extension is good boy
MetaMask is 🐐 If you’re building a Ðapp you actually want people to use. MetaMask support is a must-have. This little chrome extension drastically improves how easily people can interact with your Ðapp (distributed app). If you haven’t already, go download MetaMaskand try it out for yourself. I’ll wait.
5. Web3.js — introduce your Ðapp to local nodes in your areasend nodes
If you want to build a Ðapp, you’re going to get very personal with the web3 library. Web3.js is going to be the interface you’ll use to interact with blockchain if you’re trying to make something people won’t hate.
6. Truffle — skip right to the good stuffEventually you learn to love the taste
If you’ve got a tool belt full of development tools, Truffle is your sonic screwdriver. Truffle provides the building blocks to quickly create, compile, deploy, and test blockchain apps.
Before you start throwing your ether around like ones in the club 💸 try testing your code in a test blockchain. Since writing to the blockchain costs Ether, it’s a good idea to test out your smart contracts in a test blockchain spending test Ether.
8. Solc — because different languages only makes it more excitingI’ve got a thing for byte-rs
9. Solium — chemical free solidity cleaning solutionYour mom doesn’t live in the blockchain. Don’t expect her to cleanup your mess.
Your mom doesn’t live in the blockchain. Don’t expect her to clean up your mess. Since you pay by the size for all of your writes to the blockchain, contracts included, it’s in your interest to make sure you’re not wasting your money uploading shitty code.
10.Ether.camp — you can do it online now?this one time, at ether.camp
Microsoft has been stepping up their blockchain game. They recently started offering BaaS (Blockchain as a Service)in their Azure cloud suite and they’re bringing more heat with ether.camp, a fully fledged Ethereum IDE.
11. BlockApps — it’s not stalking if they gave you their address, right?Every Ðapp has a fantasy of bringing in a 3rd party
Everything in the blockchain is visible by everyone, so don’t you want to take a peek? BlockApps has some API endpoints that are pretty nifty for things like checking wallet balances, writing transactions, and reading contract states. With just some addresses, you can go all Sherlock Holmes on people’s wallets.
The following are tools not on the original list but still deserve recognition
12. Embark — Hop on for a ride you won’t forgetLogo coming soon
Need some structure in your Dapp? Embark is another popular framework for building, testing, and deploying your app.
[Embark is] a framework for developing Decentralized Applications that is one of the most popular tools to develop Ethereum DApps
Special thanks goes out to Jim Huang for helping me compile the list. And thank you to Tim, Brandon, Lyndon, Casey, and Arjun for driving HappyCha.inforward and inspiring me to work harder every day.❤️
If you found this article useful or entertaining please drop a ❤️ or a share. Please comment with any feedback or tools you’d like to see added to the list.Zane Witherspoon Co-founder of blockchain startup@HappyChainAPI • DevOps for @Brightidea• DJ/Producer • All my social medias:@ZaneWithSpoon
New Ethereum (ETH) mining pool- 0%fee
FEE - 0%
Payments - PPLNS
Location - Europe