[buckie]

Yeah, sounds interesting. Ping us at [e-mail] so we can chat more/keep in touch.

Pact should be O/S Sunday or Monday, we're putting the finishing touches on the web editor now and the Atom plugin is already out there[1] though without a binary to run alongside it there's not much to see.

[1]: https://atom.io/packages/language-pact

[cdetrio]

Btw, small bone to pick with the Pact whitepaper[1]:

> EVM and Solidity have no support for atomic execution. Ethereum contracts simply abort on error, leaving developers with the impossible task of undoing previous writes and contract creates after any possible error condition.

EVM transactions are atomic; all state changes are reverted on aborts (out-of-gas errors and throws). Ethereum state changes are committed only after successful transaction execution, so developers never have to worry about writes from half-executed transactions.

1. http://kadena.io/docs/Kadena-PactWhitepaper-Oct2016.pdf

[spopejoy]

Is this commit from Oct 4 what you're referring to? https://github.com/ethereum/go-ethereum/commit/46a527d014851...

Ethereum is decidedly non-transactional in certain cases, like nested contract creation for instance. I don't know about this commit though.

[cdetrio]

The spec [http://gavwood.com/Paper.pdf] has been to revert on errors since day 1:

> Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. σ).

The Oct 4 commit just optimizes the way that reverts are implemented in go-ethereum (use a journal rather than deep copies).

[buckie]

For the case(s) you've mentioned, you are correct: the state that is built up disappears on error.

However, when last I checked, there are several operations that fall outside of this guarantee, e.g. new account creation, that are not rolled back on error. This would be as easy fix but to my knowledge is still unaddressed. Hopefully, they've changed this and if they have please let me know.

Edit: I stand corrected, thanks!

[cdetrio]

Last time I looked, you guys were developing Hopper, a contract language with a dependent type system. Why the pivot to Pact?

[spopejoy]

Pact is fundamentally different from Hopper, reflecting our goal to create the right database metaphor for blockchain systems. You can see Bitcoin as a single-purpose versioned key-value database with support for authorization with public keys.

Pact generalizes the versioned key-value database to be key-row, maintains a full history, and the rest of the language allows you to enforce whatever invariants you want, with whatever key-based authorization scheme you need.

As such, Pact is really a very simple language, which is really important for business adoption. If people are going to be entrusting code to execute contracts, you have to be able to read that code with some hope of understanding what it means. This is also why Pact is interpreted, not compiled: that way you can easily see what code is stored in the ledger.

[davidgerard]

... and you avoid problems like the Solidity compiler bug, where you could have written perfect, provably correct contract code, and the thing you're running it on could still open an exploit. The exploit could still have happened with interpreted code, but at least then it would be fixable.

[bgibson]

Will do!