As I pointed out a while back (https://news.ycombinator.com/item?id=22974882), the "SHARD" system described in that paper didn't actually have anything to do with "sharding" as the term is currently used. It was designed to replicate data, but it didn't do any kind of partitioning; each replica stored a copy of the entire dataset.
For that reason (in addition to the low number of citations), I think it's very likely that the name is a total coincidence. Pretty much any word you can think of has been used by somebody as an acronym for some project.
I'm the person you replied to in that thread, and in support of your point: after that discussion, I spent some time crawling through the proceedings of Very Large Databases (VLDB) and the ACM Digital Library, and I could find no instances of "shard" used to mean the partitioning of a database prior to 2001. (That paper is "Minerva: An automated resource provisioning tool for large-scale storage systems" in Transactions on Computer Systems, free-to-read at https://dl.acm.org/doi/abs/10.1145/502912.502915.)
Other the other hand, I found many papers citing the SHARD paper - more than the official count. That's a difficulty with citation counts of old papers: a lot of the papers citing it are also old papers, and we're not consistent at tracking the citations of old papers. Personally, I don't have a conclusion. The SHARD paper is decently cited, and its usage is close to the modern one. On the other hand, I can't find any smoking gun pre-1997 usage of "shard" in the modern meaning.
Looking at a single academic paper's citation count won't reveal much about a term's historical currency.
For example, there are also papers in Google Scholar (findable via query [database shard], through 1987) mentioning this same SHARD system in 1986 and 1987, with 33 and 97 citations respectively. And further, there's a 1986 MIT technical note that mentions a commercially-in-development version of this SHARD system, but refers back to a 1985 paper, "System architecture for partition-tolerant distributed databases", as an authoritative source about SHARD – though that 1985 paper doesn't declare the name SHARD.
That's suggestive that SHARD was adopted as a catchy name for that particular work around 1985-1986, then becoming more widespread in the 1986-1988 timeframe.
But perhaps more interesting: that original 1985 paper mentions in its acknowledgements Hector Garcia-Molina – a definite 'hub' person in databases/indexing/networked-information for decades, among many other things Google cofounder Sergey Brin's advisor at Stanford from 1993-1997. (See: <https://en.wikipedia.org/wiki/H%C3%A9ctor_Garc%C3%ADa-Molina...)
So it's likely safe to assume that from the late 80s into the 90s, top CS students/researchers around the world discussing partitioned distributed databases would often have this particular sense of SHARD mentioned to them, or appear in their readings.
Notably, that 1985 SHARD involved a system where each replica contained the entire database – so did not capture the modern connotations of 'shard', as horizontal partitions. But that vivid & apropos analogy was "in the air" around partitioned/distributed databases.
Thus I'd strongly suspect uses in the modern, non-overlapping sense in that same era, likely predating Ultima Online's 1996ish use. (I'd especially look around precursor work to the 1997 'Consistent Hashing' paper, & other caching-centric work – because there the idea of partition-by-key was central.)
So UO might have devised, but I'd guess more likely popularized, our modern sense of 'sharding'.
It's interesting to learn more about the history here. When UO came out and used the shards concept I just assumed it was a callback to 1988's Ultima 5 and the shards of Mondain's gem. Linguistic history sure is blurry and organic!
I use to explain it this way: nowadays, bits and bytes are everywhere, most everybody you know has a notion of what a `megabyte` is. But this is a shockingly recent idea.
My grandma was 20 when a guy named Claude Shannon in 1949 invented/popularized the concept of a "bit" and described what information is, the way Newton described matter and how to model physics with mathematics.
Really, "information" was a just vague concept until Shannon and this was just 70 years ago!!1
It's only natural that a lack of generations of craftsmanship in this industry makes it pretty low quality/hard to master. On the other hand, imagination is the limiting reagent, since (arguably) the bottleneck is good ideas, specially with all these decades of Moore's law.
The article is fairly low-quality. It's more focused on fear-mongering around the perils of machine-judges and trying to make a headline around "if there's someone with commit power then in the end, it's not a decentralized system".
It makes a number of errors, most notably, calling the hashing power spent on securing the network "donations" (quotation marks sic).
Bitcoin has one job: securing the network of transactions.
Bitcoin is a mechanism to aggregate hashing power in order to make it possible to semi-objectively measure the risk of a block being reverted, in fact, this is the only formula in bitcoin's white-paper.
The paper examines a system of economic incentives, and somehow dismiss its key activity as an altruistic "donation". The article goes downhill from this statement onwards, and I couldn't feel like it makes a huge (yet ineffective) effort of deconstructing Bitcoin's governance model.
Some quotes that reinforce the superficial understanding of the Author:
> There are times, however, when two miners can find the
correct nonce for a new block within a few seconds of each other and both broadcast their valid block of transactions (nigh on) simultaneously to the network. This causes a split, or fork, where miners go ‘rushing off’ to mine on top of two competing blocks. Because this form of divergence is endemic
to the blockchain’s mechanics it is referred to here as a systematic fork; the discrepancy should be quickly resolved by network mechanisms (this happens, on average, two or three times a week). Systematic forks are temporary glitches...
These forks are essential to maintaining decentralization as a mechanism to make the network secure: trust the info, not the people that delivered the data, trust the signing mechanism (hash power spent), not the people running the machines.
> Furthermore, the political strategy of a user activated soft fork still requires code developers to create a client that reflects the political will of the market and thus demands the obligatory passage point of a Lead Developer found in version control systems.
Not true -- the UASF measures were not merged into the Bitcoin Core branch. Some code was merged to protect users from potentially problematic interactions with Bitcoin Cash fork.
Modeling Bitcoin's governance system is a daunting task. The author essentially confuses the power developers have with regards to miners: developers know there are things that would never fly with miners, and miners are way more powerful than what is described in the paper.
I'm sometimes shocked by the bad quality of browsing through code on GitHub. For example, you can't do a code search on forked repositories! The usability of the search bar is also quite lacking...
Also, "reward" is not appropriate. It has been historically referred to as "miner subsidy": it was intended to be a way to make mining attractive for early adopters.
Yep, storing your bitcoins in a plain web app is definitely a bad idea. The current trend in the bitcoin space is a mixture of:
* Discouraging the use of the webapp (if any available) in favor of a browser application (chrome app, firefox app, etc)
* 2 factor auth to login
* Bitcoin "multisig" transactions: require at least N out of M valid private keys (allowing the storage of these keys to be on different devices/services/media) before releasing funds
I think that the project is a bad idea because you can't impersonate me and take donations in my name without my consent, no matter which currency is being used.
Can you explain how they have given that impression? I still don't fully understand what's going on here, but my first impression (Which seems to be the issue you have, that they are masquarading or implying that they are operating on behalf of the developer) is that they let people put bounties on bugs.
That means they are independent and third party and in no way necessarily affiliated with the project. I understood that right from the start, but I only have a 3rd person perspective on this, are the private messages different?
> Donate bitcoins to open source projects or make commits and get tips for it.
The language used is "donate to projects". If you click the "See projects" button, you get to a page with the header "Supported projects", which suggests some kind of agreement between the project and Tip4Commit.
If you click a project, you get to a page with text like "Project sponsors", and even "No sponsors yet. Be the first to support this project.". The implied "... on Tip4Commit" part is not obvious.
The only thing suggesting that Tip4Commit is not affiliated with the projects is a low-contrast message at the bottom of each page, which was added after this blew up.
I feel like we shouldn't miss the point here: you can't impersonate me and take donations in my name without my consent, no matter the currency (or regulations or whatever) being used. Make it opt-in, not "opted in by default and no way to opt out".
We don't impersonate anybody. We just provide additional way to reward project's contributors and perhaps attract more of them. We'll make it more explicit with https://github.com/tip4commit/tip4commit/issues/136
Firstly, you need to make abundantly obvious and clear promises as to what happens to money left it accounts. There is no reason to trust your escrow, let alone your ability to manage or secure it. I honestly still can't find it spelled out clearly, and even then it'd be hard to trust.
I suggest you pull your site before this PR gets even further out of hand, then reboot. If you continue to pursue your project, partner with a couple projects that opt-in (free publicity for you both) and work to their needs. Once you have things in order, then you can think about something more automated.
Source: https://scholar.google.com/scholar?cluster=14914487445955020...