Obsidian: A safer blockchain programming language | Hacker News Reader

Obsidian: A safer blockchain programming language

obsidian-lang.com

67 pointsazhenley31 comments

Sorry, but without even a basic set of easily-accessible examples, you will immediately lose a significant percentage of programmers and engineers.

> Obsidian is currently under development and is not ready for general use. For more details about Obsidian, for now, please read our papers. Want to help? Participate in our user study.

What you are looking for is not in scope for this publication. Keep in mind that this is an academic project.

Even some pseudocode would go a long way - surely the creators have some idea in mind of what that would look like.

The paper does contain code. Why not put it on the project page and Readme.md?

Agreed, they should have put the code from the paper on the front page:

  main contract Policy {
    state Offered {
      int cost ;
      int expirationTime ;
    }
    state Active {}
    state Expired {}
    Policy@Offered ( int c , int expTime ) {
      -> Offered ( cost = c , expirationTime = expTime );
    }
    transaction activate ( Policy@Offered >> Active this ) {
      -> Active ;
    }
    transaction expire ( Policy@Offered >> Expired this ) {
      -> Expired ;
    }
  }

Tezos, which is itself written in OCaml (what originally attracted me to the platform), already has a relatively well design language for writing contracts called Michelson (https://tezos.gitlab.io/master/whitedoc/michelson.html). I say "relatively", compared to the dumpster fire that is Solidity...

Personally, I've always wanted take a look at Liquidity Lang [0] which exists on top of Michelson. At a glance, it seems to solve a large number of issues that have caused bugs in Solidity smart contracts (e.g. liquidity has abstract data types, disallows inline mutation of state, etc)

[0] http://www.liquidity-lang.org/

You might like Cardano's Plutus, which is Haskell-like.

https://cardanodocs.com/technical/plutus/introduction/

Why all these new languages? No one really wants to learn yet another language.

The big 4 public dapp blockchains use C++, Solidity and JavaScript. I can't imagine C++ and Solidity is okay. IOST went with JavaScript and the V8 engine for it's smart contracts. That seems the most reasonable as they can leverage a massive amount of JavaScript code.

Will be interesting once people realize they have a way to monetize webapps with a browser extension/wallet. Just think about all the web based JavaScript games that died because no way to monetize. Someone should be porting those over.

Plus, it took IOST only 8 weeks to passed up ETH in total number of blockchain transactions. ETH was launched back in June 2015. IOST has a fast ass blockchain.

Is there a language spec and examples anywhere? I can only find one example of what the language looks like in their insurance policy case study paper.

I think this is a student project that hasn't really made it to that level yet. It looks pretty neat and they apparently won an award for it.

There are some examples in the repository, e.g. https://github.com/mcoblenz/Obsidian/tree/master/resources/c...

Also see a draft paper: http://obsidian-lang.com/obsidian-oopsla-19-submitted.pdf

Glad to see the interest — thanks! What we'd especially appreciate is if you'd participate in the experiment: http://obsidian-lang.com/experiment.html

Looks promising and is long overdue. This is along the lines of what Ethereum should have been from its inception. It probably would have avoided many of the highly publicized exploits.

Hopefully carefully considered and well-designed technology will prevail. In this industry we are often too eager to endorse the first-mover as the standard.

Safer coding is important, as are better semantics for state machine processing on chain, where a mistake can be really costly. So, yay.

On the other hand, three things make this hard for me to dig into and get a real opinion: no sample code, so I have no idea if I like the way the authors are going at it, no argument as to why this is not just a solidity extension, and the compiler seems to need java.

It’s my day job to track stuff like this, but I will probably pass until one of those three improves

Their papers have a few samples. It looks a little like Bamboo.

http://obsidian-lang.com/publications.html

> the compiler seems to need java.

Looks like it's written in Scala, which is in the realm of ML and quite nice for compilers.

Maybe they could compile w/Scala Native to get rid of the Java dependency? I am not up to speed w/the status of Scala Native or if this project has JVM-specific dependencies though - just a thought :)

If anybody doesn't know about the Mtgox collapse, this man is the reason why creditors haven't seen any money after 6 years and he recently submitted a ~$16b claim against the estate. All the money and coins in the estate are customer deposits yet entitled Mr Vessenes feels he has the right to all of this because he couldn't possibly make money through legitimate business practices.

How bout you recognize customers entitlement to what's left of their deposits?

You are garbage made flesh.

Username checks out, as they say on Reddit ;)

The last line was unnecessary to get your point across and against HN guidelines.

Also, check out Blockstream's Simplicity smart contract programming language.

https://blockstream.com/2018/11/28/en-simplicity-github/

https://github.com/ElementsProject/simplicity

Can anyone explain why a new language is needed, and why we can't just use existing languages for this?

From one of their papers the DSL is geared towards non programmers: "The target user base of Obsidian is business professionals who will use the language to write smart contracts, and its design is thus oriented towards this domain. Obsidian programs consist of contracts – similar to classes in Java – which contain fields, states, and transactions – similar to methods."

"We will target business students and business analysts with limited programming experience, in order to collect data from the intended user base of Obsidian." http://www.cs.cmu.edu/~NatProg/papers/barnaby17%20-%20Obsidi...

In another paper they reveal they're also writing an IDE for this, overseen by some PhDs in 'human-computer interaction' so it should be simple to use though I find piles of complexity added by classes/methods the exact opposite of simple.

> though I find piles of complexity added by classes/methods the exact opposite of simple.

I mean, the model of your objects calling methods on other objects (that you don’t control)—and having your methods called by those same objects in turn—is inherent in the abstract machine being programmed for. You don’t have to use express the internals of your program as classes and methods, but that’s how people are going to see your contract “from the outside”, and that’s also how you’re going to have to interact with other contracts.

IOST uses the V8 JavaScript engine to execute it's smart contracts. Seems like a no brainer given the massive amount of existing JavaScript code, tools, and coders.

https://developers.iost.io/docs/en/2-intro-of-iost/VM.html

Minor bug on the website: on mobile opening the menu brings up a "view on github" link which covers the close button.

Rust. Holochain, Polkadot and others have adopted Rust to solve these issues.

You are talking about implementations of the nodes. This is targeting smart contracts that will be executed by those nodes.

Nope both. Holochain core is written in Rust and you code distributed apps ("DNA") in Rust. Polkadot core ("Substrate") is written in Rust and you code smart contracts in Rust ("Ink"). Both compile down to WASM.

Well color me ignorant. I am going to have to looker deeper into both (esp Polkadot), I have been procrastinating that for too long now.

Rust does provide some help in its type system (via ownership), but it is not nearly as expressive as Obsidian's. Rust, AFAIK, does not support linearity (i.e. will not warn you when you accidentally lose an owning reference to an object). It also does not directly support typestate (although there are ways of shoehorning parts of that in, I believe).

Reply on news.ycombinator.com