The idea arrived before the puzzle did. In May 2007, two months before
Eternity II went on sale, the mailing list floated a SETI@home-style
community effort, and Brendan Owen's reply was the first clear statement of
the thesis the next fifteen years would keep confirming: piece sets exist
that "will be impossible with the current back tracking algorithms", no
matter how many machines you enlist
(groups.io message 222,
message 226). The community
went ahead and built the distributed projects anyway, more than once and in
two distinct shapes. Both are worth understanding, because one of them
turned out to be genuinely useful. The social history (the rise and fall of
eternity2.net, the contest politics around it) lives in
the history pages; this page is the systems view.
The first shape is the crowd: strangers download a client, donate cycles,
and split any prize by contract.
eternity2.net was the flagship. Dave Clark, author of a distributed
Eternity I solver, launched it on Berkeley's BOINC infrastructure the same
month the puzzle shipped, July 2007
(message 756). Skeptics said at
launch that without algorithmic advances even 100,000 machines had
essentially no chance
(message 763); the crowd came
anyway. Within six weeks it had over 1,300 signed-in members; 160 of them
were in the USA, where the puzzle had not yet been released
(message 2122,
message 2132). The project
submitted a 462-edge partial to Tomy, then a 463
(message 2663), the number
that served as the community's public ceiling for over a year. Five months
after launch, Clark shut it down and published the accounting: over
1.6 TFlops of aggregate compute, over 10¹⁹ CPU operations, best
scores "in the mid 460ish range", and his own verdict that a brute-force
solution "was always clearly going to be impossible"
(message 3511). He
open-sourced his research solver on the way out
(message 3716), and its file
formats became the community's interchange standard.
The Eternity 2 Syndicate added the legalese. Launched in October 2007 at
eternity2syndicate.co.uk, members ran a fast backtracker on partitioned
search space (the same architecture as eternity2.net) but with an explicit
contract: prize money shared in proportion to placements contributed. Within
a week it reported ~20 machines averaging 300 million placements per second;
soon 40 members were running 50 solver instances, with members-only progress
statistics (message 3021,
message 3078,
message 3105). A French
distributed-solving site ran in parallel; Clark welcomed the "competition"
(message 1254). In May 2008
came the micro-scale version: e2dude's "E2@home", one person claiming
scores above 460 per week per PC and recruiting volunteers for a share of
the $10,000 lesser prize
(message 5474).
None of these swarms set a record. The one volunteer campaign that won
money inverted the recipe: instead of a weak client on many machines, Louis
Verhaard released the strongest solver in existence, eii, for anyone to
run, with the prize split 50-50 between him and the best-scoring user
(message 5940). The
community's machines found his 467 more than forty times
(message 6275), and it won
the only prize Eternity II ever paid.
The eii page tells that story in
full; the lesson for this page is blunt: the algorithm was the asset, and
the crowd was just its multiplier.
The second shape is quieter and outlived the first: one researcher, many
machines they personally control, aimed at a finite target.
François Galea's cluster. In 2009 Galea reported solving Brendan Owen's
10×9 benchmark exactly (93 days on a 7-node cluster of dual Pentium 4s)
and having the 10×10 running for ~110 days on a cluster of three
PlayStation 3s, still unsolved (istarinz had given up on the same 10×10
after a month on a quad-core Xeon)
(message 6918). This is the
earliest clean example of the good use case: the 10×9 has a knowable, finite
tree, so more cores buy a real completion date rather than a lottery ticket.
Peter McGavin's scavenged farm.
McGavin built his fleet out of whatever was cheap: ~20 cores at home, three
ODROID XU4s, twenty-five $12 Orange Pi Lites (130+ cores), then borrowed
work servers for 400+ in total. That peak was intermittent, not sustained:
the work was "spread over about 4 years and intermittently using up to about
400 cores at a time" (message 9804),
the borrowed servers only in the last month or so, and by his own note the
server cores "are hyperthreads, strictly speaking"
(message 9753) while the ARM
boards run at about a third of a PC core. In 2017
that farm solved Brendan's set_1 10×10, the community's decade-old communal
benchmark: ~2×10¹⁷ nodes, about 180 core-years, under 0.5% of the
full tree, "no new methods, just systematic persistence and the law of
large numbers"
(message 9686,
message 9688). Three years
later he pointed "about a couple of hundred" cores at Joshua Blackwood's newly released
solver for a few days and landed the 469, then the all-time record on the
real puzzle
(message 10045).
The cloud made cameo appearances: Amazon EC2 was suggested as early as 2010
(message 8106), and David
Barr tried his search program on AWS Lambda in 2016
(message 9642). But rented
fleets never displaced owned ones; the economics of a puzzle with no
deadline favour hardware you can leave running for years.
| Effort | Model | Scale | Outcome | Source |
|---|
| eternity2.net (Dave Clark, 2007) | Volunteer swarm (BOINC) | 1,300+ members, 1.6 TFlops | 462–463 submitted; >10¹⁹ ops; shut down after 5 months | 756, 3511 |
| French distributed site (royale_zerezo, 2007) | Volunteer swarm | unknown | Faded without a result | 1253 |
| Eternity 2 Syndicate (Amos, 2007) | Volunteer swarm + prize contract | ~40 members, 50 instances, ~300M placements/s | No record; faded with the site | 3021, 3078, 3105 |
| E2@home (e2dude, 2008) | Micro-syndicate | A few volunteers | Claims above 460; no verified record | 5474 |
| eii release (Verhaard, 2008–09) | Published binary, 50-50 prize split | Community PCs | 467 found 40+ times; the only prize ever paid | 5940, 6275 |
| Galea's cluster + PS3s (2009) | Owned fleet | 14 CPUs + 3 PlayStation 3s | 10x9 solved exactly in 93 days; 10x10 unsolved | 6918 |
| Top-row reservations (2013) | Mailing-list protocol | A handful of members | 4,318,956 rows listed; known solution verified; petered out | 9164, 9177 |
| McGavin's row farm (2016–17) | Owned fleet (scavenged) | 400+ cores at peak, intermittent over ~4 years (many are hyperthreads) | Brendan's set_1 10×10 solved, ~180 core-years | 9688, 9804 |
| McGavin on Blackwood's solver (2020) | Owned fleet | "about a couple of hundred" cores, a few days | 469/480, the record of its day | 10045 |
| wrapper_blackwood (Bucas, 2021–) | Job server + per-core clients | One worker per core | Parameter maps, not records | repo |
Backtracking looks sequential, but it distributes embarrassingly well: fix
a prefix of the search and every subtree below it is an independent job
needing no communication at all. The community used three concrete recipes.
Prefix bands. Slice the space of early placements into ranges and hand
each range to a worker. This is what eternity2.net and the Syndicate did,
the "partitioned search space" of
message 3021, and it is the
weakest form, because on the full puzzle every band is equally hopeless.
First-row lists. Enumerate every legal completion of the first row,
then treat each row as one job: a bounded backtrack over the remaining
board. In 2013, at McGavin's suggestion, Martin (capiman) enumerated all
4,318,956 legal top rows of Brendan's 10×10 set 1 and posted the list
(message 9164). McGavin
searched the row containing the known solution, row 1,407,888, to
completion in 15,310 seconds, finding exactly that solution
(message 9167), and Michel
Gaillard "reserved" entries 1000002–1000035 by posting to the list
(message 9177). That 2013
effort petered out; the 2017 one added the missing ingredient: ranking.
McGavin scored ~20 million first-row permutations by their
complex-theory chance of solution per
search-tree node and farmed the best rows first. The solution arrived at
row-search ~92,907 against a predicted one-per-~70,000
(message 9688). The ranking
was the difference between a lottery and a schedule. Jobs are wildly
uneven in value; a good static model of which slices are promising is
worth more than any amount of extra hardware.
Parameter sweeps. The modern variant distributes configurations
instead of subtrees. Jef Bucas's
wrapper_blackwood is a small
Python server that hands out jobs over HTTP, where each job is a variation
of Blackwood's solver parameters;
clients (one worker per core) generate the C# source from templates with
that variation baked in, compile it, run it, and report back. The output is
not a record but a map: which colour triples and which quota schedules
reach depth, aggregated across hundreds of runs.
The coordination machinery was strikingly informal. The 2013 reservation
protocol was the honour system: you claimed a range of rows by posting a
message (message 9177), and
it worked because the participants numbered in the single digits.
Verification, by contrast, was taken seriously, and it was always the same
method: independent re-computation. When McGavin verified row 1,407,888,
apal1969 re-ran the same row on separate code and confirmed it with
6.77×10¹¹ nodes
(message 9168); when the
10×10 fell in 2017, Martin independently validated the solution
(message 9725); record boards
were posted with full piece lists and checked in Jef Bucas's online viewer
(message 10045). Nothing
entered the community's ledger on someone's word alone.
The swarm era's real coordination problem was economic, and the contest
made it worse: prize entries could be disqualified if published, so
eternity2.net stopped publishing scores above 463: a distributed project
that could not tell its own volunteers what they had found
(message 3511). The
prize-splitting contracts (the Syndicate's placement-proportional shares,
eii's 50-50, E2@home's share of the lesser prize) were attempts to stop
volunteers from pocketing a find for themselves, and to keep them
motivated, inside that forced secrecy. When the
contest died, the problem evaporated: the modern efforts publish
everything, and trust rides on reproducibility instead of contracts.
Nothing, and the community knew why before it started. The group's own
tree estimates, converging from independent implementations in 2008, put
the full search at roughly 2.2×10⁴³ nodes per solution, on the
order of 10²⁷ CPU-years
(message 5193,
message 5197). Against that,
eternity2.net's lifetime total of 10¹⁹ operations is about
10⁻²⁴ of one solution's worth of work: multiplying your fleet by
a thousand, or a million, moves a number like that not at all. Owen said it
two months before the puzzle shipped
(message 226); Clark's
shutdown letter conceded it in almost the same words
(message 3511).
The deeper point is the one this wiki keeps returning to: hardware
multiplies a search, while pruning re-shapes it.
Prune vs speed makes the general argument,
and complex theory supplies the exact
arithmetic of why the full-puzzle tree dwarfs any conceivable fleet. Every
distributed effort on the full puzzle confirmed the counting argument; none
dented it.
The efforts that worked share one property: the target was finite and the
mathematics said so in advance.
- Exhaustive solving at the feasibility frontier. Galea's 10×9 and
McGavin's 10×10 are trees of ~10¹⁵–10¹⁷ nodes:
monstrous for one machine, tractable for a fleet. Distribution converted
"someday" into 93 days and 180 core-years respectively.
- Measurement. McGavin's 10×10 doubled as the strongest validation
complex theory ever received: the
solution arrived on the predicted schedule, and the published node
histograms matched the model
(message 9688). A core farm
is a fine instrument for measuring a theory.
- Parameter studies. wrapper_blackwood is the modern template: when the
question is "which of these thousand configurations searches deepest?",
the jobs are verifiable, bounded, and independent, which is exactly what
distribution wants.
- Records only downstream of an algorithm. The 469 came from ~200
cores running a solver that was already, by itself, record-class
(message 10045). Cores
multiplied Blackwood's algorithm; at no point in this archive did they
substitute for one.
The one-line summary
Fifteen years of collective compute, distilled: crowds without an
algorithm bought nothing; fleets pointed at finite, well-modelled targets
bought exactly what the model promised. The multiplier is real; it just
multiplies whatever you already have.