No serious blockchain relies on proof-of-work. Bitcoin (being forked now) doesn't and ethereum (already forked twice) definitely doesn't.
Blockchains are a social construct and what ultimately protects them are the participants. Exactly like actual currencies they are subject to market forces; people either believe in and want the currency or they don't. It's this confidence that gives the currency strength.
More simply:
"On medium to long time scales, humans are quite good at consensus. Even if an adversary had access to unlimited hashing power, and came out with a 51% attack of any major blockchain that reverted even the last month of history, convincing the community that this chain is legitimate is much harder than just outrunning the main chain’s hashpower. They would need to subvert block explorers, every trusted member in the community, the New York Times, archive.org, and many other sources on the internet; all in all, convincing the world that the new attack chain is the one that came first in the information technology-dense 21st century is about as hard as convincing the world that the US moon landings never happened. These social considerations are what ultimately protect any blockchain in the long term, regardless of whether or not the blockchain’s community admits it (note that Bitcoin Core does admit this primacy of the social layer)." [1]
The subtlety here is making the distinction between confidence and resistance to attack. They're not the same thing at all. And what's interesting here is that, going off the model of real currencies, one could assume market forces will prevail here. Developed nations let their currencies float precisely because on the whole they're confident that the market will ultimately punish any malicious attacker who attempts to destroy the currency by selling large amounts of it.
It's sort of a silly question. It's like asking how telephones can solve a problem. The blockchain is a network not unlike the web, the telephone network, and the highway network. Networks don't solve problems in themselves they enable new collaboration models and collaborators solve the problem. People keep getting hung up on implementation details (BTC is one implementation) and silly hype (the fall of Fed!) which is how these things go. Ignore that.
Go to the source code. This stuff is open-source and well documented. Once you start reading the code this stuff makes sense. Write your own blockchain. In fact it's not that hard and it'll make the basic concepts really sink in.
This is a common error. The blockchain itself doesn't make money. Just like the internet itself doesn't make money. People build collaboration models on top of the communication protocols and they make money.
(You still need to pay the ISPs of course and eventually the ISPs become too powerful and start demanding bigger and bigger fees and then the whole thing turns to shit. See: Bitcoin, the internet.)
It's a public database. That's it. Anybody can write to the database and anybody can read from it.
The problem is that whenever you have a public anything there will be spam. People will come along and they will fill the space up with scam ads and porn and hate speech. See: the internet.
To prevent the database from filling up with spam you need to find a way to make people "pay" for writing to the blockchain. Nothing is free and if you're going to consume resources (storage and cpu) from other's computers then they ought to get something in return. That's what "transaction fees" are and that's why they're measured in costs per byte -- the people who are writing to this public, decentralized, highly resilient database are being charged storage fees.
So blockchains are the solution to spam. And unlike pre-existing spam solutions a blockchain doesn't require storage/delivery nodes to "whitelist" certain certificates or for certificate authorities and CRLs and all that wackiness. This is kinda remarkable.
This innovation enables all sorts of new models of collaboration (read: business models). Just today I saw a very interesting proposal for an Uber-like system built on a blockchain. Everything -- requests for transport, driver availability, driver fees, driver certification, passenger and driver ratings -- gets stored in the blockchain. Anybody can read, anybody can write. Here's the database, here's the type of "transactions" (records) -- go crazy. The interesting thing about this system is that it doesn't rely on huge bureaucracy to protect the database. (And what are many business firms but database maintainers and protectors?) Write whatever you want -- write pics of your cats if you like -- but it's going to cost you.
(There's another element of what's commonly called blockchain which is "block verification." The problem here is that when everybody has a copy of the database how do you decide whose copy of the database is authoritative? This is the concept of consensus and note that it's only a problem if the peers in the database don't trust one another. It's actually not so interesting but it is largely an implementation detail of public blockchains with different strategies proof-of-work, proof-of-stake, electoral-validation etc.)
It's because there is no meaningful parallel. Conversations are not economic transactions. Period. You can try to stretch analogies ("walking is illegal because of traffic lights!1") but that's stupid and unhelpful.
The Constitution doesn't guarantee a right to private communications. This is the problem. Period. The 4th amendment was sacrificed during the anti-drug/anti-black eighties. Right now the moment information leaves your home -- whether its a phone call or a letter or a bitcoin transaction -- the government has the right to intercept that. They don't even need a warrant in practice.
It's going to require a Constitutional amendment, really a new 4th amendment, that will clearly and unambiguously extend privacy to a person's communication and data. Complaining about taxes on barter isn't going to help and is nothing but distraction.
Of course they're different: private communications are not economic interactions, but both are private interactions between mutually consenting parties. So there are parallels.
That people choose to deny any link is not surprising.
Like I said, society has accepted these classes of restrictions on private interaction, and that means it will be very hard to make a coherent argument against prohibiting private communication. Such arguments will be hobbled by arbitrary judgments that this private interaction ought to be free from interference, invasion or censor, while this other private interaction should not. Cognitive dissonance will make a concerted push against prohibitions on private communication difficult.
As for the US Constitution, that only relates to the US. The global question will be decided by the majority's perception of the morality of right to privacy and autonomy.
Mutiny is likely. American officers in particular will tend not to follow orders to commit an obvious war crime. This isn't an extralegal check , it's very much legal.
But the system will fail if "the whole chain is stupid." This is why it's so dangerous to have a President obsessed with loyalty.
Yes, and that's why we have so many obligatory legal oaths. It is kind of astonishing that Americans without the internet developed a pretty rigorous system so long ago - Joe Rogan (sorry) summarized it well when he said that smart people think they're smart, but they're actually just regurgitating things they've learned from truly genius people from past generations
What makes you think mutiny would be likely? It would depend on many factors such as the psychological makeup of the launch & command staff and the circumstances du jour. No doubt they made sure independent-minded soldiers likely to be unreliable were not placed anywhere near any silo.
There's real value here. In a world being overrun with services what's desperately needed is an orchestration language. Such a language is severely focused on consuming services/messages, converting data, and then uploading data/messages. This is the next Unix shell; a tool whose only purpose would be to stitch together services, pipe data, schedule execution, and display results. An integration dsl.
But it's not clear ballerina that can really do that. Would love to see a more real world example that demonstrates it really solves the integration/scripting problem.
Ballerina is designed exactly for that; to be the Unix shell of the Internet basically. Deep understanding of JSON, XML, MIME, SQL etc., networked execution naturally, parallelism naturally, resiliency, etc..
Dealing with JSON objects in Java has been a pain which often caused me to pick Node.js. I always wanted another typed language that supports JSON literals...
There is no easy answer here. Where and when validation happens requires some careful analysis.
I find it helps a lot to think carefully about (1) message validation -- is this a valid message? (2) entity validation -- is this entity in a valid state? and (3) enterprise validation -- is the business system as a whole now in a valid state? These three questions map on to what is often an ACL, domain, and domain services layer. At the end of the day there's going to be corner cases though in which case as a rule of thumb there's something to be said for doing validation at the edges and moving it in closing to the center as needed. In my experience when it's not clear where validation belongs that often means nobody really understands that validation (or that validation is even wrong and is not what the business wants -- it happens!) and so there's something to be said for keeping it out of the core domain.
Clean architecture is just repackaged DDD. I sympathize with what Bob is trying to do though -- for some reason this stuff often doesn't "click" with many developers until they see it and then it seems "obvious."
I think it's hard to really explain why software should be built like this. This is why architects and senior devs and the like often end up ruling by dictat and simply laying down rules like "messages only in the ACL, no messaging in the domain." The problem that Clean Architecture and DDD are trying to solve are architectural and ultimately organizational problems and these problems are not clear to most developers who are just given a story and told to implement some new feature or story. The only hope is to make these these architectural problems everybody's problem. Spread the pain.
Microservices btw are no escape hatch. Microservices that don't get the essential system boundaries right are in fact going to become a horrible mess. If anything microservices make it more important to think carefully about the boundaries and the interfaces of the system.
See my comment below. The language of the business will almost always guide the design in the right direction. There are rare cases where the business is unaware of a more "essential truth." This isn't about OO it's about faithfully capturing the model of the domain which is all DDD is.
Blockchains are a social construct and what ultimately protects them are the participants. Exactly like actual currencies they are subject to market forces; people either believe in and want the currency or they don't. It's this confidence that gives the currency strength.
More simply:
"On medium to long time scales, humans are quite good at consensus. Even if an adversary had access to unlimited hashing power, and came out with a 51% attack of any major blockchain that reverted even the last month of history, convincing the community that this chain is legitimate is much harder than just outrunning the main chain’s hashpower. They would need to subvert block explorers, every trusted member in the community, the New York Times, archive.org, and many other sources on the internet; all in all, convincing the world that the new attack chain is the one that came first in the information technology-dense 21st century is about as hard as convincing the world that the US moon landings never happened. These social considerations are what ultimately protect any blockchain in the long term, regardless of whether or not the blockchain’s community admits it (note that Bitcoin Core does admit this primacy of the social layer)." [1]
[1] https://medium.com/@VitalikButerin/a-proof-of-stake-design-p...
The subtlety here is making the distinction between confidence and resistance to attack. They're not the same thing at all. And what's interesting here is that, going off the model of real currencies, one could assume market forces will prevail here. Developed nations let their currencies float precisely because on the whole they're confident that the market will ultimately punish any malicious attacker who attempts to destroy the currency by selling large amounts of it.