Ethereum Blog

Gav’s Ethereum ÐΞV Update V

Introduction

user

Gavin Wood


LATEST POSTS

The last Blog Post 11th January, 2016

Chain Reorganisation Depth Expectations 08th August, 2015

dev update

Gav’s Ethereum ÐΞV Update V

Posted on .

I was woken by Vitalik’s call at 5:55 this morning; pitch black outside, nighttime was still upon us. Nonetheless, it was time to leave and this week had best start on the right foot.

The 25-minute walk in darkness from the Zug-based headquarters to the train station was wet. Streetlights reflecting off the puddles on the clean Swiss streets provided a picturesque, if quiet, march into town. I couldn’t help but think the rain running down my face was a very liquid reminder of the impending seasonal change, and then, on consideration, how fast the last nine months had gone.

Solid Foundations

The last week was spent in Zug by the Ethereum foundation board and ÐΞV leadership: Vitalik, Mihai and Taylor who officially form the founation’s board, Anthony and Joseph as the other official advisors and Aeron & Jutta as the ÐΞV executive joined by Jeff and myself wearing multiple hats of ÐΞV and advisory). The chief outcome of this was the dissemination of Vitalik’s superb plan to reform the foundation and turn it into a professional entity. The board will be recruited from accomplished professionals with minimal conflicts of interest; the present set of “founders” officially retired from those positions and a professional executive recruited, the latter process lead by Joseph. Anthony will take a greater ambassadorial role for Ethereum in China and North America. Conversely, ÐΞV will function much more as a department of the Foundation’s executive rather than a largely independent entity. Finally, I presented the release strategy to the others; an event after which I’ve never seen quite so many photos taken of a whiteboard. Needless to say, all was well received by the board and advisors. More information will be coming soon.

As I write this, I’m sitting on a crowded early commuter train, Vinay Gupta in tow, who recently took on a much more substantive role this week as release coordinator. He’ll be helping with release strategy and to keep you informed of our release process. This week, which might rather dramatically be described as ‘pivotal’ in the release process, will see Jeff, Vitalk and me sit around a table and develop all the PoC-9 changes, related unit tests, and integrations in three days, joined by our indomitable Master of Testing, Christoph. The outcome of this week will inform our announcement which will come later this week outlining in clear terms what we will be releasing and when.

I’m sorry it has been so long without an update. The last 2 months has been somewhat busy, choked up with travel and meetings, with the remaining time soaked up by coding, team-leading and management. The team is now substantially formed; the formal security audit started four weeks ago; the bounty programme is running smoothly. The latter processes are the exceedingly capable hands of Jutta and Gustav. Aeron, meanwhile will be stepping down as the ÐΞV head of finance and operations and assuming the role he was initially brought aboard for, system modelling. We’ll hopefully be able to announce his successors next week (yes, that was plural; he has been doing the jobs of 2.5 people over the last few months).

We are also in the process of forming partnerships with third parties in the industry; George, Jutta and myself managing this process; I’m happy to announce that at least three exchanges will be supporting Ether from day one on their trading platforms (details of which we’ll annouce soon), with more exchanges to follow. Marek and Alex are providing technical supprt there with Marek going so far as to make a substantial reference exchange implementation.

I also finished the first draft of ICAP, the Ethereum Inter-exchange Client Address Protocol, an IBAN-compatible system for referencing and transacting to client accounts aimed to streamline the process of transfering funds, worry-free between exchanges and, ultimately, make KYC and AML pains a thing of the past. The IBAN compatibility may even provide possibility of easy integration with existing banking infrastructure in some future.

Developments

Proof-of-Concept releases VII and VIII were released. NatSpec, “natural language specification format” and the basis of our transaction security was prototyped and integrated. Under Marek’s watch, now helped by Fabian, ethereum.js is truly coming of age with a near source-level compatibility with Solidity on contract interaction and support for the typed ABI with calling and events, the latter providing hassle-free state-change reporting. Mix, our IDE, underwent its first release and after some teethng issues is getting good use thanks to the excellent work done by Arkadiy and Yann. Solidity had numerous features added and is swiftly approaching 1.0 status with Christian, Lefteris and Liana to thank. Marian’s work goes ever forward on the network monitoring system while Sven and Heiko have been working diligently on the stress testing infrastructure which analyses and tests the peer network formation and performance. They’ll soon be joined by Alex and Lefteris to accellerate this programme.

So one of the major things that needed sorting for the next release is the proof-of-work algorithm that we’ll use. This had a number of requirements, two of which were actually pulling in opposite directions, but basically it had to be light-client-friendly algorithm whose speed-of-mining is proportional to the IO-bandwidth and which requires a considerable amount of RAM to do so. There was a vague consensus that we (well.. Vitalik and Matthew) head in the direction of a Hasimoto-like algorithm (a proof-of-work designed for the Bitcoin blockchain that aims to be IO-bound, meaning, roughly, that to make it go any faster, you’d need to add more memory rather than just sponsoring a smaller/faster ASIC). Since our blockchain has a number of important differences with the Bitcoin blockchain (mainly in transaction density), stemming from the extremely short 12s block time we’re aiming for, we would have to use not the blockchain data itself like Hashimoto but rather an artifcially created dataset, done with an algorithm known as Dagger (yes, some will remember it as Vitalik’s first and flawed attempt at a memory-hard proof-of-work).

While this looked like a good direction to be going in, a swift audit of Vitalik and Matt’s initial algorithm by Tim Hughes (ex-Director of Technology at Frontier Developments and expert in low-level CPU and GPU operation and optimisation) showed major flaws. With his help, they were able to work together to devise a substantially more watertight algorithm that, we are confident to say, should make the job of developing an FPGA/ASIC sufficiently difficult, especially given our determination to switch to a proof-of-stake system within the next 6-12 months.

Last, but not least, the new website was launched. Kudos to Ian and Konstantin for mucking down and getting it done. Next stop will be the developer site, which will be loosely based on the excellent resource at qt.io, the aim to provide a one-stop extravaganza of up to date reference documentation, curated tutorials, examples, recipes, downloads, issue tracking, and build status.

Onwards

So, as Alex, our networking maestro might say, these are exciting times. When deep in nitty gritty of development you sometimes forget quite how world-altering the technology you’re creating is, which is probably just as well since the gravity of the matter at hand would be continually distracting. Nonetheless, when one starts considering the near-term alterations that we can really bring one realises that the wave of change is at once unavoidable and heading straight for you. For what it’s worth, I find an excellent accompaniment to this crazy life is the superb music of Pretty Lights.

profile

Gavin Wood

http://gavwood.com/

Comments
user

Author Joshua Davis

Posted at 8:39 pm March 2, 2015.

“ultimately, make KYC and AML pains a thing of the past.” – Sounds good. I’m not saying that I want you to drop what you are doing and explain that statement but if some sort of similar type of integration currently exists can you possibly give us a link to help us better understand how it works? Is this the first technology of its kind to solve KYC, AML issues in this way? If so how? If your claim is true is it only partially true in some instances or absolutely true i.e. all financial transactions passing through Ethereum that senders wish to be made KYC/AML compliant are made compliant by the protocol itself and not by a 3rd party platform?? It sounds like you are saying the protocol itself resolves these issues, is this mentioned in the yellow paper at all? If absolutely true then yes what you are doing is absolutely revolutionary.

Reply
    user

    Author Gavin Wood

    Posted at 10:15 pm March 2, 2015.

    so validating your identity with a institutional validator will still be necessary until the powers that be give us unassailable methods of providing digital signatures.

    however, what we can do is, given a web of trust between such institutions, allow them to easily determine who is trusted between them. e.g. perhaps i’ve gone through the KYC/AML verification with Kraken and have an ICAP account with them: XE69ETHKRAKGAVOFYORK.

    next to my address, in its institutional contract, Kraken could easily point this out.

    new suppose a friend has an account at bittrex, and wants to deposit a large amount of cash with me. also suppose Bittrex is happy to trust Kraken if Kraken says i’m verified. normally bittrex would be exposed regarding the AML/KYC laws, but now it can trivially check kraken’s institution state for my client account (given by the destination IBAN code XE69ETHKRAKGAVOFYORK) and realise i’m sound.

    now suppose i wish to deposit cash into Bittrex; normally Bittrex wouldn’t be able to hold cash for me without breaking a load of AML/KYC laws. i now say i’ve an account at a trusted (by Bittrex) institution; i tell Kraken (i.e. issue a signed transaction to their institutional contract) to associate my client account with my Bittrex ICAP code (e.g. XE42ETHTREXGAVOFYORK), or, for added privacy, the hash of it. now Bittrex can be secure knowing that it’s dealing with a trusted client of a trusted institution and accept my deposit.

    basically, integrated infrastructure to allow institutions to share their trust of individuals.

    eventually, there will probably end up being a few specific providers of AML/KYC trust, rather than forcing everyone to do it as is the case now. and ultimately, this will probably be either completely decentralised or become a function of the government.

    Reply
    user

    Author Gav

    Posted at 10:18 pm March 2, 2015.

    so validating your identity with a institutional validator will still be necessary until the powers that be give us unassailable methods of providing digital signatures.

    however, what we can do is, given a web of trust between such institutions, allow them to easily determine who is trusted between them. e.g. perhaps i’ve gone through the KYC/AML verification with Kraken and have an ICAP account with them: XE69ETHKRAKGAVOFYORK.

    next to my address, in its institutional contract, Kraken could easily point this out.

    new suppose a friend has an account at bittrex, and wants to deposit a large amount of cash with me. also suppose Bittrex is happy to trust Kraken if Kraken says i’m verified. normally bittrex would be exposed regarding the AML/KYC laws, but now it can trivially check kraken’s institution state for my client account (given by the destination IBAN code XE69ETHKRAKGAVOFYORK) and realise i’m sound.

    now suppose i wish to deposit cash into Bittrex; normally Bittrex wouldn’t be able to hold cash for me without breaking a load of AML/KYC laws. i now say i’ve an account at a trusted (by Bittrex) institution; i tell Kraken (i.e. issue a signed transaction to their institutional contract) to associate my client account with my Bittrex ICAP code (e.g. XE42ETHTREXGAVOFYORK), or, for added privacy, the hash of it. now Bittrex can be secure knowing that it’s dealing with a trusted client of a trusted institution and accept my deposit.

    basically, integrated infrastructure to allow institutions to share their trust of individuals.

    eventually, there will probably end up being a few specific providers of AML/KYC trust, rather than forcing everyone to do it as is the case now. and ultimately, this will probably be either completely decentralised or become a function of the government.

    Reply
      user

      Author Joshua Davis

      Posted at 11:14 pm March 2, 2015.

      “validating your identity with a institutional validator will still be necessary” – I thought this was the case. I couldn’t imagine the protocol operating to completely decentralize the collection, storage and retrieval of AML/KYC data not that I believe it is impossible but it seems like too great a leap given the current maturity of the technology.

      The integration between financial institutions based upon an IBAN-compatitible protocol seems like a sound approach. It would be nice to see how Ethereum compares with other cross validation payment platforms that allow you to move between institutions. If Ethereum is better and or cheaper somehow and the integration is effortless would this mean that banks would quickly find integrating with Ethereum to perform cross validation a benefit over existing more costlier methods in the market today?

      This has been one of the greatest questions that I have always had. If Ethereum will create greater efficiencies on a number of different levels what is the primary barrier to adoption? I just assumed that the difficulty integrating with Ethereum as a new technology was the primary barrier to adoption but now you seem to indicate that the payment protocol incorporates existing standards which should make integration easy. So then if Ethereum is better will all banks adopt it for cross platform payment validation in short order?

      Seems like there should be a way to link a passports ICAO biometric identification data to a specific IBAN account but that would assume a method for publishing, storage and retrieval ICAO passport data which has its own unique problems.

      Reply
user

Author MaxcoinOhio

Posted at 10:34 pm March 2, 2015.

This all sounds Great…I’ve been a big fan of Gav from the beginning – he radiates intelligence, work-ethic, and excellence!

Reply
user

Author Donald McIntyre

Posted at 11:18 pm March 2, 2015.

Hi Gav, is there a revised timeline of when Ethereum will be launched?

Reply
    user

    Author Gav

    Posted at 1:47 pm March 3, 2015.

    Our plan is to publish our release schedule at the end of this week. Basically, we’re huddled here in Berlin hacking away and will base the release schedule on the outcome of this work.

    Reply
user

Author Christoph Jentzsch

Posted at 9:09 am March 13, 2015.

Of course it is cited (Section 1.2 in the beginning)

Reply

Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

View Comments (8) ...
Navigation