Indeed, I felt like I was reading an article about how to abuse stored procedures in order to push all of the computation to the database, even the inefficient parts. [0]
The Blockchain is the slowest and at the same time most energy hungry Datastore mankind has ever build. And in the case of bitcoin it's not fit for the job it was developed for.
There's no way for the blockchain to validate time stamping due to fluctuation in hash power and the nature of an adversarial network with untrusted data.
What's been happening is blocktimes wildly fluctuate, anywhere from 20 seconds - 90 minutes + even though the software attempts to calibrate for 10 minutes.
He just means things are unequivoqually ordered in time, so each block is a time stamp. Not necessarily running at constant frequency as our other time keeping tools.
This is a cheap throwaway joke that has absolutely nothing to do with the content of the article. It would have been possible to make this joke by only reading the title.
The level of negativity received by this article only because it’s related to blockchain is almost comical. More so for the fact that the name of the aggregator includes the name “Hacker”.
Is there something about hackers that would make you expect them to like overhyped technologies that have a very limited set of cases where they're actually a good choice in the real world?
Haven’t blockchains become tools of big banks and scam artists nowadays? No part of that is the same as hacker to me at least.
Especially when this is a proposal not a real product, I think it’s very appropriate to tell Oasis Labs this is a dumb idea. At least from a technical perspective, maybe not a scam artist one.
"Bitcoin has UTXO+transactions+proof-of-work, Ethereum has accounts+smart contracts+proof-of-work (soon to be CBC Casper), and Oasis has accounts+confidential smart contracts+BFT"
Love how the author plugs his blockchain in that sentence as if it is in the same league as Bitcoin and Ethereum.
That's content marketing 101: You write about a general trend and you give a few well-known examples plus your own product. It's very common on Medium and LinkedIn.
Putting an experimental systems interface in an immutable blockchain seems like a bad idea. Why not just use linux x86 or Emscripten asm.js or even JVM? That wouldn’t get you as many HN hype points I guess.
I don't know much about _this_ particular project, but "wasm + blockchain" is not that silly an idea.
The ethereum crowd is dead set on making the "Web 3.0" thing take off, and getting smart contracts to evolve into full-fledged distributed applications (dapps in the lingo). In that context, the ewasm project is a pretty damn serious attempt at leveraging the wasm specification as a better VM for dapps than what the current EVM provides.
It’s a better VM, sure, but the core problems are conceptual: there’s no way to fix bugs and programs still have to rely on outside sources for triggers. All a blockchain adds is the ability to get VC funding to expensively reinvent the trusted third party but with less efficiency.
I don't see the benefits of jamming the square peg of language builtins into such a narrow use case.
> the runtime translates WASI args_get and args_sizes_get
> for the zeroth arg to the blockchain address() function.
There is nothing intuitive about that for me.
In most languages, exposing the blockchain interface as a module feels like it would be a significantly cleaner implementation. If I want to compile against different targets I'd prefer to wrap that module as a library behind my own interface. I can then swap out the implementation at compile time.
> > zeroth arg
> There is nothing intuitive about that for me.
It looks a lot like how a command-line program has the program name as the zeroth argument. The address just happens to be the name of the program in a blockchain context.
> exposing the blockchain interface as a module feels like it would be a significantly cleaner implementation
I'm not so sure. I think that the goal here is to allow developers to program "DApps" using their normal toolchain and abstract over the semantics of the blockchain platform. IMHO even the ideas of "block" and "chain" are implementation details in the same way as the journal of a traditional database is an implementation detail. Exposing these details as a library means that the program is tied to not only the blockchain, but a particular blockchain runtime.
> wrap that module as a library behind my own interface
That's always a good idea, but not incompatible with having a lower-level interface (in this case WASI and Rust/C++/AsmScript `std`).
> IMHO even the ideas of "block" and "chain" are implementation details in the same way as the journal of a traditional database is an implementation detail.
The internals of a database are one thing, but the semantics of the language builtins seem like another. It almost feels akin to someone suggesting we change the underlying implementation of "println" (or whatever language builtin outputs to stdout) to automatically write to a new row in a database. I mean, I could adjust to such a weird idea but my initial impression would be we are forcing an existing abstraction onto a problem rather than choosing a truly suitable abstraction.
> Exposing these details as a library means that the program is tied to not only the blockchain, but a particular blockchain runtime.
Not necessarily, I'm considering something more like Go's cloud API: https://github.com/google/go-cloud
You could easily have a "blockchain" API with any number of runtime backends.
I understand what the proposer was suggesting: a single semantic meaning for "print" across all programming languages that will map onto blockchain. I just don't agree that it is a good idea.
I hereby propose to rebrand all marginally blockchain-related products and technologies "hash tree" or "convergent replicated state machine" technologies.
Did you read the article? It's got a lot of good information on how code runs on the ethereum virtual machine. And the benefits of using something like WASI. Even if you hate block chain, it's still fascinating.
The idea of smart contracts or world computer is flawed. A better term would be a scripted financial transaction. They can be done in a trusted environment, but there are a lot of benefits of having a public cryptography secured ledger.
Though the article author omits it, EOS mainnet runs on LLVM and WASM contracts and executes about 1000tx/s today.
A more powerful financial VM is needed e.g. for on-chain order books.
More about use cases vs. databases can be found in my article
"This idea doesn't seem relevant in my tiny corner of software development, therefore it is not relevant in ANY of software development" is the disease of this website.
Agreed, though what's really fucked up is the native Ethereum language and machine. Almost anything is an improvement on that. I still don't know what to use any of that for though. :-/
Edit: yes I mean Solidity. I mean, it's cool that it works, but look at it, it's insane. They could have picked just about any language, including assembler, Lisp, Lua, Javascript, Visual Basic, LLVM bytecode, whatever and would have been better off. But over time there will evolve compilers which can from another input language provably (-ish in most cases) produce safe output.
Any time you see the word "blockchain" replace it with "Slow Database" in your head and see if it still makes sense.