The DAO soft-fork effort was tough. Not solely did it prove that we underestimated the uncomfortable side effects on the consensus protocol (i.e. the DoS vulnerability), however we additionally managed to introduce a knowledge race in a rapidly carried out implementation that turned out to be a ticking time bomb. It wasn’t supreme, and although it was deferred on the final alternative, the fast-approaching hard-fork deadline was trying extraordinarily disappointing, to say the least. We would have liked a brand new technique…
The stepping stone on this route was an concept borrowed from Google (courtesy Nick Johnson): an in depth write-up publish mortem Goals to evaluate the basis reason for the incident, focusing solely on technical points and taking applicable measures to stop recurrence.
Technical options stay at scale; It’s not proper guilty folks. ~ Nick
From the postmortem, an attention-grabbing discovering emerged from the angle of this weblog publish. The soft-forked code inside (go-ethereum)(https://github.com/ewhereum/go-ewhereum) appeared stable from all factors of view: a) it was lined by unit exams with 3:1 test-to- was lined in a roundabout way. code ratio; b) It has been totally reviewed by six Basis builders; and c) it was additionally manually examined dwell on a personal community… Nonetheless, a deadly information race remained, which may doubtlessly trigger extreme community disruption.
This confirmed that the flaw may solely happen in a community with a number of nodes, a number of miners, and a number of blocks being mined concurrently. Even when all these eventualities had been true, there was solely a slight likelihood of the bug being launched. Unit exams might not catch it, code reviewers might or might not catch it, and it might be not possible to catch it by guide testing. Our conclusion was that improvement groups wanted extra instruments to carry out reproducible exams that will cowl the complicated interaction of a number of nodes in a concurrent community situation. With out such a software, it’s cumbersome to manually test for varied edge instances; And with out doing these checks constantly as a part of the event workflow, it is going to be not possible to detect uncommon errors in a well timed method.
And thus, hive was born…
What’s hive?
Ethereum grew to such an extent that check implementation grew to become an enormous burden. Unit exams are superb for checking varied implementation quirks, however verifying {that a} shopper conforms to some baseline high quality, or verifying that purchasers can play properly collectively in a multi-client atmosphere, is all too easy.
Bee -Hive It’s supposed to function an simply expandable check harness Any You’ll be able to add exams (they are often easy verification or community simulation). Any a programming language they’re comfy with, and Hive ought to have the ability to run these exams concurrently All potential buyer. Thus, the aim of the harness is to carry out black field testing the place no buyer particular inside particulars/circumstances could be examined and/or inspected, however reasonably the emphasis might be on adherence to official specs or behaviors below varied circumstances.
Most significantly, Hive was designed to run as a part of any buyer’s CI workflow!
How does the hive work?
The physique and soul of hive is docker (https://www.docker.com/). Every shopper implementation is a Docker picture; Every verification suite is a Docker picture; And every community simulation is a Docker picture. Hive itself is a ubiquitous Docker picture. It is a very highly effective abstraction…
since ethereum shopper Hive has Docker photographs, builders of purchasers can construct the absolute best atmosphere (dependencies, tooling and configuration smart) to run their purchasers. Hive will spin up as many cases as wanted, all of them operating in their very own Linux methods.
equally, as check suite Validating Ethereum purchasers are Docker photographs, the creator of the exams can use no matter programming atmosphere he’s most acquainted with. Hive will make sure that the shopper is operating when the tester is began, which might then confirm whether or not the actual shopper conforms to some desired habits.
Finally, community simulation These are once more outlined by Docker photographs, however in comparison with easy exams, simulators not solely execute code towards operating purchasers, however can really begin and finish purchasers at will. These purchasers run in the identical digital community and may join to one another independently (or as directed by the simulator container), creating an on-demand personal Ethereum community.
How did the hive assist the thorn?
Hive is neither a alternative for unit testing nor a radical evaluation. All present deliberate practices are important for a clear implementation of any characteristic. Hive can present verification past what is feasible from a mean developer’s perspective: operating intensive exams which will require complicated execution environments; and checking networking nook instances that may take hours to arrange.
Within the case of the DAO hard-fork, past all of the consensus and unit exams, a very powerful factor we have to guarantee is that the nodes are clearly divided into two subsets on the networking stage: one supporting and one opposing the fork. This was needed as a result of it’s not possible to foretell what antagonistic results operating two competing collection in a single community may need, particularly from the angle of minorities.
Thus now we have carried out three typical community simulations in Hive:
-
First To check that miners operating the total ethash DAG generate the proper block extra-data fields for each pro-forkers and no-forkers, even when they’re naively making an attempt to cheat.
-
Second To confirm {that a} community consisting of combined pro-fork and no-fork nodes/miners is accurately break up in two when the fork block arrives, additionally sustaining the break up afterwards.
-
third To check that, given an already forked community, newly becoming a member of nodes can sync, quick sync, and light-weight sync within the chain of their alternative.
Though the attention-grabbing query is: did Hive actually catch any errors, or did it simply function a further affirmation that all the pieces is okay? and the reply is, Each, hive caught three fork-unrelated bug in Geth, however closely assisted within the hard-fork improvement of Geth by offering fixed suggestions on how adjustments affected community habits.
There was some criticism of the go-ethereum group for taking their time on the hard-fork implementation. Hopefully folks will now see what we had been doing, in addition to implementing the fork. Total, I imagine hive Sanitation performed an important position on this transition.
What’s the way forward for the hive?
Some exterior repositories within the Ethereum GitHub group embrace at the least one EVM benchmark software with cooking (4 check instruments already)(https://github.com/ewhereum?utf8=%E2percent9Cpercent93&question=check) . They aren’t being totally utilized. They’ve a variety of dependencies, generate a variety of junk and are very difficult to make use of.
With Hive, we’re aiming to combination all the varied scattered exams into one Common Buyer Verifier It has minimal dependencies, could be prolonged by anybody, and could be run as a part of shopper builders’ every day CI workflow.
We welcome anybody to contribute to the challenge, whether or not it is including new purchasers for verification, validators for testing, or a simulator for locating attention-grabbing networking points. Within the meantime, we’ll attempt to make Hive even higher, by operating benchmarks in addition to including assist for mixed-client simulation.
With just a little work, possibly we’ll even get assist for operating Hive within the cloud, which might enable it to run community simulations at a extra attention-grabbing scale.