Trust Models
vitalik.ca
vitalik.ca
Mechanism design is a subfield of game theory and economics called mechanism design that tackles this directly.
Instead of having a game and figuring out how it works and what is the outcome is when agents play it, the problem is to design a game that creates desired outcomes when selfish agents play it.
It's possible to design mechanisms where utilitarian social-choice function is the best choice even when players are selfish. The most famous result in the field is Vickrey–Clarke–Groves mechanism to achieve a socially-optimal solution in auctions. Quadratic voting and quadratic funding is another interesting mechanism that results good outcomes. Vitalik Buterin is involved with this too.
Curious about if these ideas have been applied to constructing healthy effective companies? With happy employees
Or maybe one could say everyone that comes up with some KPI are doing this?
Links for anyone curious:
Eric Weinstein's The Portal Podcast - https://www.youtube.com/playlist?list=PLq9jO8fmlPee9ezOraOHA...
Lex Fridman's Artificial Intelligence Podcast - https://www.youtube.com/playlist?list=PLrAXtmErZgOdP_8GztsuK...
They are related by questions of society, trust, and incentive design.
They seem largely aligned with Vitalik's assessment of the `0 of N`/`1 of N` assessment
Before clicking through to Goodreads, though, check out this book review of Seeing like a State by Scott Alexander:
https://slatestarcodex.com/2017/03/16/book-review-seeing-lik...
Next, check out both of these books:
- James C. Scott, Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed [0]
- Michael Huemer, The Problem of Political Authority: An Examination of the Right to Coerce and the Duty to Obey [1]
Neither book will disappoint!
[0]: https://www.goodreads.com/book/show/20186.Seeing_Like_a_Stat...
[1]: https://www.goodreads.com/book/show/15794037-the-problem-of-...
Edit: for clarity.
However, I want to caution anyone from thinking that this book says anything about Game Theory. I'm not sure why it's being recommended here, it doesn't have much to say about the current topic, except in that it often points out that authoritarian governments are free to ignore any feedback, feedback of the kind that incentive schemes are usually designed to generate.
> except in that it often points out that authoritarian governments are free to ignore any feedback, feedback of the kind that incentive schemes are usually designed to generate.
A view of the modern state is made more accurate if one views the state as an entity desirous to ignore feedback from citizens, rather than actively responsive to citizen opinion.
Robert Caro has written amazing books. I'm half-way through this two-hour dialog titled "On Power"[0].
He says he essentially stumbled into writing The Power Broker: Robert Moses and the Fall of New York[1] after observing how Robert Moses (an unelected bureaucrat) completely controlled huge "democratic" institutions.
I mention the books because they highlight some of the means and ways in which the state encourages it's people to think it is responsive to them, but this responsiveness is a slight of hand, even as plenty of participants in the system (both as citizens and as representatives of the state) earnestly believe that the state is responsive to public input.
[0]: https://www.audible.com/pd/On-Power-Audiobook/B06XNKVH16
[1]: https://www.goodreads.com/book/show/1111.The_Power_Broker
In the case of the field of trust models Vitalik has illustrated, trust comes down to the questions of: do you have a way to tumble your root of trust, do you leave it static (like an HSM with destroyed keys), or do you federate. The answer is of course, "it depends..." In the case of the balance of consensus, proofs, and anonymity (e.g. ZK) the application defines the needs.
The issue I think is that these problems are all negatively defined and presume a threat model before a use case. They are artifacts of that threat model, in that they wouldn't exist if they weren't a reaction to it. These things (blockchains and their applications) are essentially criticisms that allow people to organize and defect to a certain extent, but they are lacking a quality of essentialness I can't seem to find a name for. It's like they aren't discovered things, but just artifacts of a constraint. Such fun to read his stuff.
Forgive me if I am misunderstanding what you are saying, but it sounds to me like you are suggesting that the consequences of a 1-of-N failure are inherently worse than the consequences of an N-of-N failure, which is not a fundamental truth in any way. It is entirely possible for a 1-of-N system to have better recovery modes than an N-of-N system, in fact it's often much easier to tumble / enhance / improve the root of trust in a 1-of-N system than it is to do so in an N/2-of-N system. (for example, in the case of rolling trusted setup ceremonies vs. multi-party-computation).
You can replace a root of trust, but then you have to re-enroll all parties into it. When you have partial or federated trust, the failure is contained to the N/x group.
I'm thinking there may be a universal trade off between number of trusted parts and the consequence/cost of failure.
The concept being that a trust model is essentially a non-reversible function you iterate from its initial unique "trusted," conditions (like derived keys, or a certificate chain), and if those unique initial conditions are replicated, you have to re-compute the entire function from a new unique initial condition, or risk "fake" branches.
A root of trust is the root node of a tree (or a DAG these days), and a compromise of any of the roots will effectively isolate its downstream branches. Compromising a single N/1 root means you compromise the whole tree, where a federated multi-rooted tree means the damage can be contained - in the model I'm thinking of.
TL;DR: the cost of the recovery mode in the 1-of-N case requires re-instantiating or enrolling all of N, which basically means bootstrapping the whole scheme. Fine for a closed system, Hard for an open one.
In any system, if N out of N participants are down, you are going to have a hard time resetting. Typically it is easiest to reset from this failure in a 1 of N system because you only need one person to recover, and it doesn't matter which person.
I'm oversimplifying a bit, but in most cases a 1 of N system is strictly more robust than a N/2 of N system. (Or any system that requires more than one honest participant).
The system that requires only one honest participant seems stable, except when that one person has a small but non-zero likelihood of compromise. A system that requires N/2 honest people - each of whom have a probability of compromise, it depends on whether that probability is independent or dependent. In the dependent case, you are correct, the more people you need to trust, the higher the likelihood of one bringing whole thing down, but in the independent (e.g. federated) case, the consequences are contained.
I'm saying that the diagram as interpreted from the perspective of the consequences of failure shows that if you turn the 1/N section red instead of green, it indicates the level of catastrophe. We could be running up against the limits of the chart's heuristic analogy, but viewing trust as flowing downstream over time from the root node of a tree , and asking how many root nodes of trust you need for a robust system, shows that the fewer the roots of trust, the greater the impact of a compromise.
I'd considered whether replacing those node keys with multipart keys would change things, but the whole concept of a compromise is an exogenous phenomenon, that is, what this trust tree/graph is made of doesn't change the effect of some super force finding a way to compromise a node. If a trust model is just a graph, then it will be the properties of that graph that determine the qualities of the model - and not what the nodes and relationships themselves are made of.
That final point would be my big-leap conjecture.
Each of these kinds of trust fit relatively neatly into the framework he proposes though. Blockchains are designed to run on tens of thousands of nodes distributed around the world, which naturally insulates them from any one country deciding they don't want cryptocurrencies to be used within their borders. And even if every other country decided to ban Bitcoin, if America still allowed it then Bitcoin the protocol would happily continue to work within America's borders, in that sense it has 1-of-N trust in countries allowing it.
On the other hand, if America or China decided they did not want Bitcoin to exist any more, and they were truly willing to do whatever it takes to shut it down, they have enough tools at their disposal to shut it down. This situation doesn't quite fit into V's framework, I think because some of the N are more important than others?
[1]:
- Do you trust whoever writes your client / mining software to write code without showstopping bugs?
- Do you trust them to use a reliable build process?
- Which websites do you trust to tell you what their public keys are, so you can check the signatures of the binaries you run?
- Do you trust whoever sold you the computer you're running your client / mining software on?
- Do you trust the mining rig manufacturers?
- If your protocol relies on a notion of time, do you trust the time servers?
- Do you trust mining pool operators not to use their hash power maliciously?
- Do you trust that if someone found a way to forge signatures, the rest of the world would know?
Of course that's not to say the problem is ignored by other communities. Many people are well aware of the full set of dependencies of these crypto projects and the ways that external forces might be disruptive. And many people are working on increasingly sophisticated ways to eliminate these dependencies or ensure viable alternatives if worst comes to worst.
[1]: https://github.com/bitcoin/bitcoin/issues/16599
[2]: https://blockstream.com/satellite/#satellite_network-coverag...
[3]: https://www.wired.com/story/cypherpunks-bitcoin-ham-radio/
The security of nakamoto consensus (Bitcoin and co) relies on a level of broadcast which is pretty incompatible with a world where the network is hostile and looking to disrupt your traffic.
It would be prohibitively expensive and difficult to disrupt point-to-point radio (e.g. ham) and satellite communications enough to cripple Bitcoin.
I'm not incredibly familiar with ham, but if you ever broadcast then you're inviting the authorities to find you, and shut you down. If you strictly communicate point-to-point it doesn't seem likely that you'd be able to tell the entire world about new blocks within a reasonable about of time. If you keep the 10 minute block interval then delays longer than, say, 1 minute, would be extremely problematic. I'm not sure how a Ham radio network could reliably tell the world about new blocks within 60 seconds without alerting the authorities.
Oh and FYI the idiom is "worse comes to worst" (analogous to "push comes to shove" -- an intensification past an activation threshold or tipping-point)
It would be odd if the Blockchain / Crypto-currency market came crashing down. Like most nutritionists who do not understand the popularity of sugary drinks or fast food chains, I think, news.yc fails to understand the Crypto-currency / Blockchain market.
But nutritionists also _understand_ that sugary drinks are bad in the long run, and that is why they keep saying that one should drink less of them, over and over. If at least few people get convinced, stop drinking sugary drinks, and avoid diabetes and heart disease, they nutritionists succeeded.
The same logic applies to blockchain/crypto-currency warnings that HN commenters produce.