Schlagwortarchiv für: Ethereum

I’m Vinay Gupta, the newly minted release coordinator for Ethereum. I’ve been working with the comms team on strategy, and have now come aboard to help smooth the release process.

I’ll be about 50/50 on comms and on release coordination. A lot of that is going to be about keeping you updated on progress: new features, new documentation, and hopefully writing about great new services you can use, so it’s in the hinterland between comms and project management. In theory, once I’m up to speed, I should be providing you with the answers to the question: “what’s going on?” But give me some time, because getting up to speed on all of this is nontrivial. We have a very large development team working with very advanced and often quite complex new technology, and keeping everybody up to date on that simultaneously is going to be tricky. To do that well, I have to actually understand what’s going on at quite a technical level first. I have a lot to wrap my head around. I was a 3D graphics programmer through the 1990s, and have a reasonably strong grounding in financial cryptography (I was, and I am not ashamed to admit it, a cypherpunk in those days). But we have a 25-30 person team working in parallel on several different aspects of Ethereum, so… patience please while I master the current state of play, so that I can communicate about what’s changing as we move forwards. It’s a lot of context to acquire, as I’m sure you all know – if there’s an occasional gaffe as I get oriented, forgive me!

I’ve just come back from Switzerland, where I got to meet a lot of the team, my “orientation week” being three days during the release planning meetings. Gav writes in some detail about that week here, so rather than repeat Gav, read his post, and I’ll press on to tell you what was on that release white board.

There is good news, there is bad news, but above all, there is a release schedule.

There will be another blog post with much more detail about the release schedule for the first live Ethereum network shortly – likely by the end of this week, as the developer meeting that Gav mentions in his post winds up and the conclusions are communicated. That’s the post which will give you timelines you can start firing up your mining rigs to, feature lists, and so on. Until then, let me lay out roughly what the four major steps in the release process will look like and we can get into detail soon.

Let’s lay out where we are first: Ethereum is a sprawling project with many teams in many countries implementing the same protocol in several different language versions so it can be integrated into the widest possible range of other systems/ecologies, and to provide long term resilience and future-proofing. In addition to that broad effort, there are several specific applications/toolchains to help people view, build and interact with Ethereum: Mist, Mix, Alethzero and so on. Starting quite soon, and over the next few months, a series of these tools will be stood up as late alpha, beta, ready for general use and shipped. Because the network is valuable, and the network is only as secure as the software we provide, this is going to be a security-led not schedule-led process. You want it done right, we want it done right, and this is one of the most revolutionary software projects ever shipped. 

While you’re waiting for the all singing, all dancing CERN httpd + NCSA Mosaic combo, the “we have just launched the Future of the Internet” breakthrough system, we will be actually be releasing the code and the tools in layers. We are standing up the infrastructure for a whole new web a piece at a time: server first, plus tool chain, and then the full user experience rich client. This makes sense: a client needs something to connect to, so the server infrastructure has to come first. An internet based on this metacomputer model is going to be a very different place, and getting a good interface to that is going to present a whole new set of challenges. There’s no way to simply put all the pieces together and hope it clips into place like forming an arch by throwing bricks in the air: we need scaffolding, and precise fit. We get that by concentrating on the underlying technical aspects for a while, including mining, the underlying network and so on, and then as that is widely deployed, stable and trusted, we will be moving up the stack towards the graphical user interface via Mist in the next few months. None of these pieces stand alone, either: the network needs miners and exchanges, and it takes people time to get organized to do that work properly. The Mist client needs applications, or it’s a bare browser with nothing to connect to, and it takes people time to write those applications. Each change, each step forwards, involves a lot of conversations and support as we get people set up with the new software and help them get their projects off the ground: the whole thing together is an ecology. Each piece needs its own time, its own attention. We have to do this in phases for all of these reasons, and more. 

It took bitcoin, a much less complex project, several years to cover that terrain: we have a larger team, but a more complex project. On the other hand, if you’re following the github repositories, you can see how much progress is being made, week by week, day by day, so… verify for yourself where we are.

So, now we’ve all got on the same page on real world software engineering, let’s actually look at phases of this release process!

Release Step One: Frontier

Frontier takes a model familiar to Bitcoiners, and stands it up for our initial release. Frontier is the Ethereum network in its barest form: an interface to mine Ether, and a way to upload and execute contracts. The main use of Frontier on the launch trajectory is to get mining operations and Ether exchanges running, so the community can get their mining rigs started, and to start to establish a “live” environment where people can test DApps and acquire Ether to upload their own software into Ethereum.

This is “no user interface to speak of” command line country, and you will be expected to be quite expert in the whole Ethereum world model, as well as to have substantial mastery of the tools at your disposal.

However, this is not a test net: this is a frontier release. If you are equipped, come along! Do not die of dysentery on the way.

Frontier showcases three areas of real utility:

  • you can mine real Ether, at 10% of the normal Ether issuance rate, 0.59 Ether per block reward, which can be spent to run programs or exchange for other things, as normal – this real Ether.
  • you can exchange Ether for Bitcoin, or with other users, if you need Ether to run code etc.
  • if you already bought Ether during the crowd sale, and you are fully conversant with the frontier environment, you can use it on the frontier network.
  • we do not recommend this, but have a very substantial security-and-recovery process in place to make it safer – see below 

We will migrate from Frontier to Homestead once Frontier is fully stable in the eyes of the core devs and the auditors:

  • when we are ready to move to Homestead, the release after Frontier, the Frontier network will be shut down; Ether values in wallets will be transferred, but state in contracts is will likely be erased (more information to follow on this in later blog posts)
  • switchover to  the new network will be enforced by “TheBomb”

This is very early release software: feature complete within these boundaries, but with a substantial risk of unexpected behaviours unseen in either the test net or the security review. And it’s not just us that will be putting new code into production: contracts, exchanges, miners, everybody else in the ecosystem will be shipping new services. Any one of those components getting seriously screwed up could impact a lot of users, and we want to shake bugs out of the ecosystem as a whole, not simply our own infrastructure: we are all in this together.

However, to help you safeguard your Ether, we have the following mechanisms planned (more details from the developers will follow soon as the security model is finalised):

  • if you do not perform any transactions, we guarantee 100% your Ether will not be touched and will be waiting for you once we move beyond Frontier
  • if you perform transactions, we guarantee 100% that any Ether you did not spend will will be available to you once we move beyond Frontier not be touched
  • Ether you spend will not fall through cracks into other people’s pockets or vanish without a trace: in the unlikely event that this happens, you have 24 hours to inform us, and we will freeze the network, return to the last good state, and start again with the bug patched
  • yes, this implies a real risk of network instability: everything possible has been done to prevent this, but this is a brand new aeroplane – take your parachute!
  • we will periodically checkpoint the network to show that neither user report nor automated testing has reported any problems. We expect the checkpoints will be around once daily, with a mean of around 12 hours of latency
  • exchanges etc. will be strongly encouraged to wait for checkpoints to be validated before sending out payments in fiat or bitcoin. Ethereum will provide explicit support to aid exchanges in determining what Ether transactions have fully cleared

Over the course of the next few weeks several pieces of software have to be integrated to maintain this basket of security features so we can allow genesis block Ether on to this platform without unacceptable risks. Building that infrastructure is a new process, and while it looks like a safe, sane and conservative schedule, there is always a chance of a delay as the unknown unknown is discovered either by us, the bug bounty hunters or by the security auditors. There will be a post shortly which goes through this release plan in real technical detail, and I’ll have a lot of direct input from the devs on that post, so for now take this with a pinch of salt and we will have hard details and expected dates as soon as possible. 

Release Step Two: Homestead

Homestead is where we move after Frontier. We expect the following three major changes.

  • Ether mining will be at 100% rather than 10% of the usual reward rate
  • checkpointing and manual network halts should never be necessary, although it is likely that checkpointing will continue if there is a general demand for it
  • we will remove the severe risk warning from putting your Ether on the network, although we will not consider the software to be out of beta until Metropolis

Still command line, so much the same feature set as Frontier, but this one we tell you is ready to go, within the relevant parameters.

How long will there be between Frontier and Homestead? Depends entirely on how Frontier performs: best case is not less than a month. We will have a pretty good idea of whether things are going smoothly or not from network review, so we will keep you in the loop through this process.

Release Step Three: Metropolis

Metropolis is when we finally officially release a relatively full-featured user interface for non-technical users of Ethereum, and throw the doors open: Mist launches, and we expect this launch to include a DApp store and several anchor tenant projects with full-featured, well-designed programs to showcase the full power of the network. This is what we are all waiting for, and working towards.

In practice, I suspect there will be at least one, and probably two as-yet-unnamed steps between Homestead and Metropolis: I’m open to suggestions for names (write to vinay[at]ethdev.com). Features will be sensible checkpoints on the way: specific feature sets inside of Mist would be my guess, but I’m still getting my head around that, so I expect we will cross those bridges after Homestead is stood up.

Release Step Four: Serenity

There’s just one thing left to discuss: mining. Proof of Work implies the inefficient conversion of electricity into heat, Ether and network stability, and we would quite like to not warm the atmosphere with our software more than is absolutely necessary. Short of buying carbon offsets for every unit of Ether mined (is that such a bad idea?), we need an algorithmic fix: the infamous Proof of Stake. 

Switching the network from Proof of Work to Proof of Stake is going to require a substantial switch, a transition process potentially much like the one between Frontier and Homestead. Similar rollback measures may be required, although in all probability more sophisticated mechanisms will be deployed (e.g. running both mechanisms together, with Proof of Work dominant, and flagging any cases where Proof of Stake gives a different output.)

This seems a long way out, but it’s not as far away as all that: the work is ongoing.

Proof of Work is a brutal waste of computing power – like democracy*, the worst system except all the others (*voluntarism etc. have yet to be tried at scale). Freed from that constraint, the network should be faster, more efficient, easier for newcomers to get into, and more resistant to cartelization of mining capacity etc. This is probably going to be almost as big a step forwards as putting smart contracts into a block chain in the first place, by the time all is said and done. It is a ways out. It will be worth it. 

Timelines

As you have seen since the Ether Sale, progress has been rapid and stable. Code on the critical path is getting written, teams are effective and efficient, and over-all the organization is getting things done. Reinventing the digital age is not easy, but somebody has to do it. Right now that is us.

We anticipate roughly one major announcement a month for the next few months, and then a delay while Metropolis is prepared. There will also be DEVcon One, an opportunity to come, learn the practical business of building and shipping DApps, meet fellow developers, potential investors, and understand the likely shape of things to come.

We will give you information about each release in more detail as each release approaches, but I want to give you the big overview of how this works and where we are going, fill in some of the gaps, highlight what is changing, both technically and in our communications and business partnership, and present you with an overview of what the summer is going to be like as we move down the path towards Serenity, another world changing technology.

I’m very glad to be part of this process. I’m a little at sea right now trying to wrap my head around the sheer scope of the project, and I’m hoping to actually visit a lot of the development teams over the summer to get the stories and put faces to names. This is a big, diverse project and, beyond the project itself, the launch of a new sociotechnical ecosystem. We are, after all, a platform effort: what’s really going to turn this into magic is you, and the things you build on top of the tools we’re all working so hard to ship. We are making tools for tool-makers.

Vinay signing off for now. More news soon!

 

The post The Ethereum Launch Process appeared first 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.

The post Gav’s Ethereum ÐΞV Update V appeared first on .

 

Ich habe ja bereits vor einigen Tagen über das Ethereum IPO berichtet. Jetzt zeigen sich leider schon erste Probleme. Für das Entwicklerteam um „Wunderkind“ Vitalik Buterin gab es einen herben Rückschlag, als ein …
ethereum – Google Blogsuche

Back in November, we created a quick survey for the Ethereum community to help us gauge how we’re doing, what can be improved, and how best we can engage with you all as we move forward towards the genesis block release in March. We feel it’s very important to enable the community to interact with Ethereum as well as itself, and we hope to offer new and exciting tools to do so using the survey results for guidance.

The survey itself consisted of 14 questions split into two sections; Ethereum as an “Organisation” and Ethereum as a “Technology”.  There was a total of 286 responses. This represents 7.8% of the current Ethereum reddit population, or 2.4% of the current @ethereumproject followers.

What country do you currently reside in?

Ethereum World

So, this is where everybody lives. To sum it up by continent – of the 286 respondents there are 123 (43%) in North America, 114 (40%) in Europe, 30 (10%) in Asia, 13 (5%) in Oceana and 6 (2%) in South America. No surprises there, though it does show how we – and the crypto space in general – have much work to do in areas south of the Brandt Line. One way to go about this is to seed more international Ethereum meetups. You can see a map of all the current Ethereum meetups here (We have 81 in total all over the world from London to New York to Tehran with over 6000 members taking part). If you’d like to start one yourself, please do message us and we can offer further assistance – .

02fixed

It’s understood that our transparency is very important to the community. To that end, we strive to make much of our internal workings freely available on the internet. As indicated in the chart, most people agree that we are doing just that. However, more can always be done. We’re currently working on a refresh of the ethereum.org website ready for the release of the genesis block. Expect much more content and information as we complete this towards the end of January. In the meantime, have a look at the Ethereum GitHub Repository, or head over to the new ΞTH ÐΞV website for a greater understanding of the entity that is delivering Ethereum 1.0, as well as its truly incredible team.

 

03fixed04fixed

We’ve always tried to give the community as much information about our financial situation as possible, and from the results it seems like a lot of you agree. For further information on how Ethereum intends to use the funds raised in the Ether sale as we move forward, check out the Road Map and the ĐΞV PLAN. To learn more about the Ether Sale itself, have a look at Vitalik’s Ether Sale Introduction, the Ethereum Bitcoin Wallet, or the Ether Sale Statistical Overview.

05

Though most people agree Ethereum’s use cases in society are clear, I wouldn’t be so sure we’ve figured them all out just yet. Everyday we’re speaking with developers and entrepreneurs via Skype or on IRC (Join in your browser – #ethereum / #ethereum-dev) who have thought of new and exciting ideas that they are looking to implement on top of Ethereum – many of which are brand new to us. For a brief overview of some of the use cases we’ve encountered, check out Stephan Tual’s recent presentation at NewFinance.

06

We’re doing our best to keep everyone updated with the plethora of changes, updates and general progression of the project that’s been taking place over the recent months. Gavin Wood and Jeff Wilcke especially have written some excellent blog updates on how things are going in their respective Berlin and Amsterdam ÐΞV Hubs. You can see all of the updates in the Project category of the Ethereum blog.

07

ΞTH ÐΞV’s mission statement is now proudly presented on the ΞTH ÐΞV website for all to see. In detail, it explains what needs to be achieved as time goes on, but can be summed up as “To research, design and build software that, as best as possible, facilitates, in a secure, decentralised and fair manner, the communication and automatically-enforced agreement between parties.”

08

Much like the crypto space in general, Ethereum is somewhat difficult to initially get your head around. No doubt about that, and it’s our job to make the process of gaining understanding and enabling participation as easy and intuitive as possible. As mentioned previously, the new look ethereum.org website will be an invaluable tool in helping people access the right information that is applicable to their own knowledge and skill set. Also, in time we aim to create a Udemy/Codacademy like utility which will allow people with skills ranging from none to Jedi Master to learn how Ethereum works and how to implement their ideas. In the mean time, a great place to start for those wanting to use Ethereum is Ken Kappler’s recent Tutorials.

11 Of the following aspects, do you think we should be focusing more or less or about the same on them?

This was an important question as it gave a lot of perspective on what aspects needed to be focused on before genesis, and what (though useful) could be developed afterwards. From a UI point of view, the Go team in Amsterdam is working towards the creation of Mist, Ethereum’s “Ðapp Navigator”. Mist’s initial design ideas are presented by the Lead UI Designer, Alex Van de Sande in this video.

Ease of installation will factor greatly in user adoption – we cant very well have people recompiling the client every time a new update is pushed! So binaries with internal update systems are in the pipeline. Client Reliability (bugs) is being actioned on by Jutta Steiner, the Manager of our internal and external security audits. We expect the community bug bounty project to be live by the middle of January, so stay tuned and be ready for epic 11 figure Satoshi rewards, leaderboards and more “1337” prizes.

Developer tools are on the way too. Specifically, project “Mix”. Mix supports some rather amazing features, including documentation, a compiler, debugger integration for writing information on code health, valid invariant, code structure and code formatting, as well as variable values and assertion truth annotations. It’s a long term project expected to be delivered in the next 12-18 months, right now we are very much focused on completing the blockchain. Once complete, we can reallocate our resources to other important projects. You can find out more in the Mix presentation from ÐΞVcon-0. For now, documentation is constantly being generated on the Ethereum GitHub Wiki.

The blog and social media interaction will continue to deliver Ethereum content on relevant channels with the aim of reaching the widest range of people as possible.

 

10

With more people owning smartphones than computers already, imagine how prolific they’ll will be as time goes on? This will be the case especially in emerging markets such as India and Nigeria, it’s likely they’ll leapfrog computers to some extent and gain wide adoption very quickly.  A mobile light client will be greatly important to the usability of Ethereum. As part of IBM and Samsung’s joint project “Adept” (an IoT platform which is currently being unveiled at CES 2015), an Android version of the Ethereum Java client – ethereumj, is going to be open-sourced on GitHub. This will go a long way to getting Ethereum Mobile!

12

It’s interesting to see a very mixed bag of responses for this question. As was said previously, Ethereum’s use cases are as wide as they are varied, and it’s great to see how many different types of services people are looking to implement on top of Ethereum. The emphasis on governance based Ðapps highlights Ethereum’s ability to facilitate interactions between the digital and physical world and create autonomously governed communities that can compete with both governments and corporations. Primavera De Filippi and Raffaele Mauro investigate this further in the Internet Policy Review Journal.

13 Which would be your favourite OS development environment?

This chart shows a reasonably even spread, we’ve done our best to make the various clients available on different operating systems. You can find the Alethzero binaries here, and the Mist binaries here. These however become obsolete very quickly and may not connect to the test net as development continues, so if you considering using Ethereum before release, it’s well worth while checking the client building tutorials to get the most up to date versions of the clients.

 

15 Which Ethereum clients do you use?

With Mist (Go), Alethzero (C++), Pythereum (Python) Node-Ethereum (Node.js), and Ethereumj (Java), Ethereum already has a plethora of clients available. The Yellow Paper written by Gavin Wood is a great reference for the community to create its own clients, as seen with those still under development such as the Clojure and Objective C iterations.

14 Which Language do you prefer to write contracts in?

As Gavin Wood has mentioned in a previous blogpost, Mutan and LLL as smart contract languages will be mothballed. Serpent will be continued to be developed by Vitalik with his team, and Soldity will continue as the primary development language for Ethereum contracts. You can try Solidity in your browser, or watch the recent vision and roadmap presentation by Gavin Wood and Vitalik Buterin at ÐΞVcon-0.

Thanks to Alex Van de Sande for helping with the implementation of the survey and chart graphics. Icons retrieved from icons8. If anyone would like a copy of the raw survey results, feel free to email .

The post Ethereum Community Survey appeared first on .

First of all, happy new year! What a year it has been. With a little luck we’ll surpass last year with an even more awesome year. It’s been too long since I’ve given an update on my side of things and that of the Go team and mostly due to a lack of time. I’ve been so incredibly busy and so many things have happened these past 2 months I’ve hardly had time to sit down and assess it all.

As you may be well aware the audit is looming around the corner and my little baby (go-ethereum!) will undergo it’s full inspection very, very soon. The audit teams will tear it apart and see if the repo contains anything incorrectly implemented as well as search for any major security flaws in the design and implementation. We’ve been pretty solid on tests, testing implementation details as well as consensus tests (thanks to Christoph) and will continue to add more tests over time. We’ll see how they hold up during the audit (though I’m confident we’ll be fine, it’s still a little bit scary (-:)

Development

PoC-7 has been released now for a about a week and has been quite stable (and growing in size!). We’re already hard at work to finalising PoC-8 which includes numerous small changes:

  • Adjusted block time back to 12s (was 4s)
  • Op code PREVHASH has become BLOCKHASH( N ) and therefore PREVHASH = BLOCKHASH(NUMBER - 1)
  • We’ve added an additional pre-compiled contract at address 0x04 which returns the given input (acts like copy / memcpy)

Ongoing

P2P

Felix has been hard at work on our new P2P package which has now entered in to v0.1 (PoC-7) and will soon already undergo it’s first upgrade for PoC-8. Felix has done an amazing job on the design of the package and it’s a real pleasure to work with. Auto-generated documentation can be found at GoDoc.

Whisper

A month or so back I finished the first draft of Whisper for the Go implementation and it’s now passing whisper messages nicely around the network and uses the P2P package mentioned earlier. The Go API is relatively easy and requires almost zero setup.

Backend

The backend stack of ethereum has also received its first major (well deserved) overhaul. Viktor’s been incredibly hard at work to reimplement the download manager and the ethereum sub protocol.

Swarm

Since the first day Dani joined the team he’s passionately been working on the peer selection algorithm and distributed preimage archive. The DPA will be used for our Swarm tech. The spec is about 95% complete and roughly about 50% has been implemented. Progress is going strong!

Both go-ethereum/p2p and go-ethereum/whisper have been developed in such a way that neither require ethereum to operate. If you’re developing in Go and your application requires a P2P network or (dark) messaging try out the packages. An example sub protocol can be found here and an example on how to use Whisper can be found here.

Ams Hub

Now that the hub is finally set up you’re free to drop by and grab a coffee with us. You can find us in the rather posh neighbourhood of Amsterdam Zuid near Museumplein (Alexander Boerstraat 21).

In my next post I hope I’ll have a release candidate for PoC-8 and perhaps even a draft implementation of swarm. But until then, happy whispering and mining!

The post Jeff’s Ethereum ÐΞV Update II appeared first on ethereum blog.

ethereum blog

One thought on “The Bitcoin Group #40 – New York Regulation Week 2 – Ethereum Pre-Sale – Coinye – Ecuador”. thebitcoingroup. 10/08/2014 at 04:20 · Antworten. Hinterlasse eine Antwort Antworten abbrechen.
ethereum – Google Blogsuche

Beim Ethereum IPO ist wieder einmal Sand im Getriebe. Das Fundraising wurde gestoppt, also man kann nicht investieren ab dem 1. Februar. Es wurde auf einen unbestimmten Zeitpunkt nach hinten verschoben.
ethereum – Google Blogsuche

OK so a minor update about what we are (and are not) doing here at Ethereum DEV.

We are, first and foremost, developing a robust quasi-Turing-complete blockchain. This is known as Ethereum. Aside from having quasi-Turing-completeness, it delivers on a number of other important considerations, stemming from the fact we are developing entirely new blockchain technology including:

  • speedy, through a 12 second blocktime;
  • light-client-friendly through the use of Merkle roots in headers for compact inclusion/state proofs and DHT integration to allow light clients to host & share small parts of the full chain;
  • ÐApp-friendly, even for light-clients, through the use of multi-level Bloom filters and transaction receipt Markle tries to allow for lightweight log-indexing and proofs;
  • finite-blockchain-friendly – we designed the core protocol to facilitate upgrading to this technology, further reducing light-client footprint and helping guarantee mid-term scalability;
  • ASIC-unfriendly – through the (as yet unconfirmed) choice of PoW algo and the threat we’ll be upgrading to PoS in the Not-Too-Distant future.

It is robust because:

  • it is unambiguously formally defined, allowing a highly tractable analysis, saturation tests and formal auditing of implementations;
  • it has an extensive, and ultimately complete, set of tests for providing an exceptionally high degree of likelihood a particular implementation is conformant;
  • modern software development practices are observed including a CI system, internal unit tests, strict peer-reviewing, a strict no-warnings policy and automated code analysers;
  • its mesh/p2p backend (aka libp2p) is built on well-tested secure foundations (technology stemming from the Kademlia project);
  • official implementations undergo a full industry-standard security audit;
  • a large-scale stress test network will be instituted for profiling and testing against likely adverse conditions and attacks prior to final release.

Secondly (and at an accordingly lower priority), we are developing materials and tools to make use of this unprecedented technology possible. This includes:

  • developing a single custom-designed CO (contract-orientated) language;
  • developing a secure natural language contract specification format and infrastructure;
  • formal documentation for help coding contracts;
  • tutorials for help coding contracts;
  • sponsoring web-based projects in order to get people into development;
  • developing a block chain integrated development environment.

Thirdly, to facilitate adoption of this technology, gain testers and spur further development we are developing, collaborating over and sponsoring a number of force-multiplying technologies that leverage pre-existing technology including:

  • a graphical client “browser” (leveraging drop-in browser components from the Chromium project and Qt 5 technology);
  • a set of basic contracts and ÐApps, including for registration, reputation, web-of-trust and accounting (leveraging the pre-existing compilers and development tech);
  • a hybrid multi-DHT/messaging system, codenamed Whisper (leveraging the pre-existing p2p back end & protocols);
  • a simple reverse-hash lookup DHT, codenamed Swarm (also leveraging the pre-existing p2p back end & protocols), for which there is an ongoing internal implementation, but which could end up merging or being a collaboration with the IPFS project.

We are no longer actively targeting multiple languages (LLL and Mutan are mothballed, Serpent is continued as a side project). We are not developing any server technology. And, until there is a working, robust, secure and effective block chain alongside basic development tools, other parts of this overall project have substantially lower priority.

Following on from the release of the Ethereum block chain, expect the other components to get increasingly higher amounts of time dedicated to them.

The post Ethereum ÐΞV: What are we doing? appeared first on ethereum blog.

ethereum blog

Time for another update! So quite a bit has happened following ÐΞVcon-0, our internal developer’s conference. The conference itself was a great time to get all the developers together and really get to know each other, dissipate a lot of information (back to back presentations for 5 days!) and chat over a lot of ideas. The comms team will be releasing each of the presentations as fast as Ian can get them nicely polished.

During the time since the last update, much has happened including, finally, the release of the Ethereum ÐΞV website, ethdev.com. Though relatively simple as present, there are great plans to extend this into a developer’s portal in which you’ll be able to browse the bug bounty programme, look at and, ultimately follow tutorials, look up documentation, find the latest binaries for each platform and see the progress of builds.

As usual I have been mostly between Switzerland, the UK and Berlin, during this time. Now that ÐΞV-Berlin is settled in the hub, we have a great collaboration space in which volunteers can work, collaborate, bond and socialise alongside our more formal hires. Of late, I have been working to finish up the formal specification of Ethereum, the Yellow Paper, and make it up to date with the latest protocol changes in order that the security audit get underway. Together we have been putting the finishing touches on seventh, and likely final, proof-of-concept code, delayed largely due to a desire to make it the final PoC release for protocol changes. I’ve also been doing some nice core refactoring and documentation, specifically removing two long standing dislikes of mine, the State::create and State::call methods and making the State class nicer for creating custom states useful when developing contracts. You can expect to see the fruits of this work in Milestone II of Mix, Ethereum’s official IDE.

Ongoing Recruitment

On that note, I’m happy to announce that we have hired Arkadiy Paronyan, a talented developer originally from Russia who will be working with Yann on the Mix IDE. He’s got off to a great start on his first week helping on the front-end with the second milestone. I’m also very pleased to announce that we hired Gustav Simonsson. Being an expert Erlang with Go experience with considerable expertise in network programming and security reviewing, he will initially be working with Jutta on the Go code base security audit before joining the Go team.

We also have another two recruits: Dimitri Khoklov and Jason Colby. I first met Jason in the fateful week back last January when the early Ethereum collaborators got together for a week before the North American Bitcoin conference where Vitalik gave the first public talk about Ethereum. Jason, who has moved to Berlin from his home in New Hampshire, is mostly working alongside Aeron and Christian to help to look after the hub and looking after various bits of administration that need to be done. Dimitri, who works from Tver in Russia is helping flesh out our unit tests with Christoph, ultimately aiming towards full code coverage.

We have several more recruits that I’d love to mention but can’t announce quite yet – watch this space… (:

Ongoing Projects

I’m happy to say that after a busy weekend, Marek, Caktux, Nick and Sven have managed to get the Build Bot, our CI system, building on all three platforms cleanly again. A special shout goes out to Marek who tirelessly fought with CMake and MSVC to bend the Windows platform to his will. Well done to all involved.

Christian continues to power through on the Solidity project, aided now by Lefteris who focuses more on the documentation side. The latest feature to be added allows for the creation of new contracts in a beautiful manner with the new keyword. Alex and Sven are beginning to work on the project of introducing network well-formedness into the p2p subsystem using the salient parts of the well-proven Kademlia DHT design. We should begin seeing some of this stuff in the code base within before the year-end.

I’m also happy to announce that the first successful message was sent between Go & C++ clients on our messaging/hash-table hybrid system, codenamed Whisper. Though only at an early proof-of-concept stage, the API is reasonably robust and fixed, so largely ready to prototype applications on.

New Projects

Marian is the lucky guy who has been tasked with developing out what will be our awesome web-based C&C deck. This will provide a public website whose back-end connects to a bunch of nodes around the world and displays real-time information on network status including chain length and a chain-fork early warning system. Though accessible by anyone, we will of course have a dedicated monitor on at all times for this page at the hub.

Sven, Jutta and Heiko have also begun a most interesting and important project: the Ethereum stress-testing project. Designed to study and test the network in a range of real-life adverse situations prior to release, they will construct infrastructure allowing the setup of many (10s, 100s, even 1000s of) nodes each individually remote-controllable and able to simulate circumstances such as ISP attacks, net splits, rogue clients, arrival and departure of large amounts of hash-power and measure attributes like block & transaction propagation times and patterns, uncle rates and fork lengths. A project to watch out for.

Conclusions

The next time I write this I hope to have released PoC-7 and be on the way to the alpha release (not to mention have the Yellow Paper out). I expect Jeff will be doing an update concerning the Go side of things soon enough. Until then, watch out for the PoC-7 release and mine some testnet Ether!

The post Gav’s Ethereum ÐΞV Update IV appeared first on ethereum blog.

ethereum blog

Kaum ein Altcoin wurde mit so viel Gedöns und Begeisterung verkündet wie Ethereum. Aber was ist dran an dem System, das, so die Medien, "alles" dezentralisieren will und über das schon gemunkelt wurde, es könne den …
ethereum – Google Blogsuche