
Blockchain-Flavored WASI - annefauvre
https://medium.com/oasislabs/blockchain-flavored-wasi-50e3612b8eba
======
sunsu
"Slow Database"-Flavored WASI

 __Any time you see the word "blockchain" replace it with "Slow Database" in
your head and see if it still makes sense.

~~~
viach
Any time you do a generalization, you are wrong.

~~~
Asmod4n
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.

~~~
yarrel
It was designed to help create a timestamp for blocks of transactions. It's
doing that just fine for Bitcoin.

~~~
nosuchthing
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.

~~~
jobigoud
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.

------
MadSudaca
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”.

~~~
chc
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?

------
guiomie
"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.

~~~
wmf
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.

------
matthewbauer
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.

~~~
fb03
I am still failing to find the reason why they are trying to put 'blockchain'
together with everything else these days.

It is exquisite for ledger/proof-of-work systems, but not much else.

Sounds like they're randomly taking guesses at what fits well with what, and
the building upon.

~~~
pdpi
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.

~~~
acdha
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.

------
reggieband
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.

~~~
_nhynes
> > 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`).

~~~
reggieband
> 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](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.

------
sagichmal
For fuck's sake.

~~~
jacobush
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.

~~~
miohtama
An EVM smart contract bytecode is usually 2kB - 4kB. You can think it as DSL
optimised for its use case.

EOS contracts are 250kB because they suck in C++ stdlib, templates or what
not.

There are benefits of having compact bytecode performance wise: cache
pressure, price of on-chain storage and so on.

~~~
jacobush
But it’s not very optimized. It’s very low level and you have to add defensive
code, taking up space.

