Add section on Evaluating Competing Considerations.#799
Conversation
jandrieu
left a comment
jandrieu
left a comment
There was a problem hiding this comment.
I'm surprised to see this PoW attack resurface in the guise of "resource usage".
I've rewritten as a generic pointer to the Rubric for evaluating competing considerations.
None of the existing VDRs that use PoW actually require PoW. Rather, they leverage existing PoW networks, to which they each add negligible marginal energy consumption.
Please stop amplifying this thread of disinformation. It's not doing anyone any good.
I am in line with @jandrieu on this one. DID-CORE is a data model spec and is agnostic to any of the underlying mechanisms that may or may not be used by a particular DID method. The impl guide deals with guidance to developers of the data model spec, and the rubric provides mechanism to evaluate various methods for a particular use case. The data model itself doesn't have any horse in this race, and nor should it, otherwise i would have opened pr #27 here instead of against the impl guide. |
mprorock
left a comment
mprorock
left a comment
There was a problem hiding this comment.
Requesting changes in line with those suggested by @jandrieu until this appropriately acts as a pointer to the rubric for evaluating various methods, and perhaps also to the impl guide for those wishing to implement or develop on a particular did method with all the various considerations around ethics and trade offs in implementation considered.
There was a problem hiding this comment.
I'd like to see W3C create a policy for applying EWP, consistently to all specs.
Allowing big companies to leverage these documents to obstruct specs selectively should not be reinforced by applying a policy of appeasement.
See also:
- w3ctag/ethical-web-principles#52
- w3ctag/ethical-web-principles#5
- w3ctag/ethical-web-principles#42
- w3ctag/design-principles#338
I agree with @jandrieu's suggestions and the spirit of this PR, but the correct thing for us to do here is fix the W3C process that led to the inclusion of this section in the first place.
Just because you can implement a JSON parser in an energy wasteful language on energy wasteful hardware, doesn't mean JSON wastes energy.
|
@jandrieu -- Does every possible future PoW-based DID solution use existing PoW deployments, and so cost only the marginal, rather than the initial (ahem) burn? If not, then how about rewriting a little bit more, dropping your knee-jerk defense in the same way you're asking others to drop their knee-jerk condemnation, and making plain what's being treated as having negligible impact, and what could (new PoW networks could be built with care for all such impacts, but it's very easy to just plug a bunch of machines into the wall and pay no attention to the generation method of those electron circuits) have significant impact? |
And vice versa. Nothing's perfectly bad, and nothing's perfectly good. The human ideal is to ethically and carefully balance all the competing factors, not to declare once-and-for-all that anything is the be-all-and-end-all of good nor evil. |
@TallTed what is the other side of this? Are you arguing that because some bad programs exist all languages that support them should have EWP disclaimers? I could agree with that... we should start with JavaScript since developers have already written lots of malware that is indistinguishable from ad tech, and which violates user privacy... Also turing machines... I have yet to see a turing machine implementation that was not an environmental catastrophe ; ) I'm not opposed to the section, I am opposed to selective enforcement of moral / ethical arguments which cannot be proved formally or "won" or "lost"... such arguments really ought to happen somewhere... and an appendix, implementation guide, or rubric are all fine places... perhaps W3C should formalize this as a requirement. |
+1 This i think is part of the issue. Objections of this nature are just now popping out in the wild in a real way, and unfortunately are blocking progress on this work item. That does not mean that it is not a real concern, it very much is, but we as a community need to identify the right place, format, and policies, for how to cite and think about items such as environmental impacts on a consistent basis across the various outputs of working groups. My bigger issue on this case, and why i think it needs some re-wording, is that this particular item is very much a data model spec, and that is very different than a specific method or implementation that might indeed have some highly negative impacts around environment, privacy, or key ethical items of note. |
|
@TallTed thanks for spelling it out :) So to generalize your argument, we SHOULD (MUST?) consider ESE regardless of spec type (data model, protocol, concrete implementation)? |
Co-authored-by: Joe Andrieu <joe@andrieu.net>
|
+1 from me. Balanced. |
|
I think Joe's rewrite, as currently applied, makes it tolerable. Another way of saying the issue is that you're not incentivizing more than you're paying for. Let's take a pass on the struggle session that is being offered. |
peacekeeper
left a comment
peacekeeper
left a comment
There was a problem hiding this comment.
Very good.. Yes, there are trade-offs depending on the use case and requirements.
Your comment is an good illustration of why this PR as initially proposed is inappropriate: there is no justifiable argument for calling out resource usage or PoW as a particularly problematic issue. The PR itself doesn't say anything about PoW, yet you perceive that it is, despite no legitimate arguments about actual resource use by actual DID methods. As long as the language triggers anti-PoW responses, it's ceases to be a technical conversation and moves into political posturing. Note that in the implementation guide text, I proposed language that does exactly what you propose (explaining the nuance of marginal use of existing infrastructure). This PR, however, is a different matter. As a pointer to the Rubric, it should, IMO be simply an introduction to the inevitable tradeoffs due to different considerations. It should not take a position that prioritizes any particular tradeoff as better or worse than any other. In particular, there is no valid argument that any known DID Method, on its own, is a significant problem wrt resource usage. As such, calling out resource usage is inappropriate, regardless of whether or not you like cryptocurrencies or think they may bring the end of civilization as we know it. The spec doesn't require any particular approach and none of the known approaches actually have the flaw that is being attacked. It's like advocating that people evaluate automobile manufacturers based on the environmental harms of railroads just because sometimes cars are transported by train. Blame car makers for the impact of cars (including those few trains with cars on them), not trains as infrastructure. Blame DID Method creators and users for the marginal impact of their DID Method, not the totality of harms that might be associated with any underlying infrastructure. As such, the inclusion of language implying that resource usage is a problem is at best erroneous, and it is more aptly described as disinformation, intentional or otherwise. Bad science shouldn't be used to justify political attacks in a technical specification. |
Note that I was replying to you, to your comments about the PR, where you raised PoW! To wit:
In other words: I did not perceive the PR to be about PoW. You did, and should perhaps take the rest of your latest comment into your own heart. |
TallTed
left a comment
TallTed
left a comment
There was a problem hiding this comment.
A few tiny wording and punctuation tweaks.
| trade-offs. For example, trade-offs between computation (energy usage), trust | ||
| (deference to authority), coordination (network bandwidth), or memory (physical | ||
| storage) might or might not be appropriate, for any given use case. Other use cases | ||
| might not make the same trade-offs. Those that need to consider different criteria |
There was a problem hiding this comment.
| might not make the same trade-offs. Those that need to consider different criteria | |
| might not make the same trade-offs. Those that need to consider different factors |
There was a problem hiding this comment.
Skipping this suggestion (applied all of your other suggestions) since the DID Rubric calls these things "criteria": https://www.w3.org/TR/did-rubric/#categories-of-criteria
There was a problem hiding this comment.
I'll live with it. Constructions like "those that need x should look at y which provides x" just make me itch. You can mark this as resolved if Github lets you. (It doesn't give me that option.)
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
msporny
changed the title
|
To address any concerns about DID methods which utilize Ethereum wasting energy, we would like to point out that Ethereum is in the process of transitioning from Proof of Work to Proof of Stake. This will reduce its energy consumption by roughly 99.95%. The transition has been in the works for a long time, and is expected to be completed within the next 6 months. We believe that POS is the future for public blockchains, and POW chains will eventually become obsolete. Tas Dienes, Andreas Freund, and Dan Shaw - Ethereum Foundation |
|
Proof of Stake is 1) not nearly as decentralized a foundation for these systems, 2) introduces a much larger attack/vulnerability surface, and 3) shifts its 'work' to mechanisms that lead to oligarchical capture/centralization that can't be unseated by unilateral operator competition. There is no free lunch, regardless of how many Rube Goldbergian cogs and widgets one attempts to bolt on.
|
I think any free to join network suffers from the "rich sybil attack"... its a fact of life. The difference between having unlimited money to spin up PoW nodes and unlimited money to leverage PoS nodes... is pure energy savings... but the rich guys still own the network ; ) |
@OR13 <sigh> there is so much to say about this. |
|
@rxgrant at least we can agree that more money, less problems, amirite? ;) From a cyber security perspective, its a fact that the "cost of an attack" is a factor in pulling it off... sometimes that cost is pure compute, sometimes its compromising a hardware supply chain, sometimes its joining a consortium and threatening folks... or tricking your opponent into overspending... attacking free to join networks is always a thing, and always costs money... sometimes it has other costs, environment or political, etc... It's also a fact that winning a fight against an adversary with more money, power etc... involves indirect conflict.
I suppose the question is: is decentralization a standing army or a guerrilla unit? |
over 270k+ validators on the beacon chain https://beaconscan.com/ -> that is quite a few clients running. How is that not decentralized?
While the game-theoretic security analysis of Casper FFG is not trivial, it is sound and turns out to be not less safe than Bitcoin aka both PoS and PoW suffer from the same type of long-range attacks.
Where is your evidence? Check this out https://beaconscan.com/validators ... biggest validators all have ~ 66 Eth and the smallest ones have ~30 Eth (minimal stake) across 270k+ validators. That looks like a very flat distribution to me. Granted, one or few individuals could control tens of thousands of validators ... but since each validator is its own stack that is a non-trivial server farm, and a significant capital investment and given the node distribution, it is geographically localized (US and EU but loads of non-clustered nodes in those geos). So, it would be awesome, if you could produce data that refutes what I just posted. |
msporny
added
the
class 2
|
Class 2, editorial, multiple reviews, changes requested and made, no objections, merging. |
14 participants
This PR adds a non-normative appendix section on resource usage trade-offs and points readers to the DID Rubric for further evaluation criteria.
💥 Error: connect ETIMEDOUT 128.30.52.89:443 💥
PR Preview failed to build. (Last tried on Oct 6, 2021, 12:46 AM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.